WEEK-10 笔记心得

微服务架构

巨无霸系统带来的问题：

打包非常慢；

测试内容庞大；

修改一行代码，或改个配置需要重新打包；

数据库连接耗尽：

新增业务困难：



解决方案：

就是拆分，将模块独立部署，降低系统耦合性



服务独立部署，远程调用：

面向服务的体系架构：90年代；

服务启动，在注册中心注册；

UDDI记录什么服务运行在什么服务器上；

服务调用方通过WSDL描述去



请求和返回大部分都是XML格式；

这套体系架构的问题：

1、协议规范复杂

2、传输这么多XML的数据需要消耗大量的性能；



关键角色：

服务注册中心

服务生产者

服务消费者



微服务框架吸取了这些思维

服务的失效转移：某个服务节点异常，可以自动转移到其它节点上；

集群部署；

负载均衡：对于集群部署的服务提供者，服务请求者可使用加权轮询等手段访问，使服务提供者集群实现负载均衡；

高效的远程通信：对于大型网站，核心服务没提调用次数达到上亿次，如果有没有高效的远程通信手段，远程调用通信会成为瓶颈；

对应用最少侵入：对于应用程序不需要知道服务是本地还是远程；

版本管理：系统需求变更，服务也要变更，如果涉及到接口变更，请求者调用接口会失败 。

那么服务需要保留新老两套版本的接口，微服务控制的时候要对服务带上版本号；

部分客户端调用老接口；部分客户端调用新接口；



微服务的框架（Dubbo）架构

三个重要的角色：

--服务注册中心

--服务消费者服务器

--服务提供者服务器



1、服务提供者在服务管理容器内启动服务；

2、服务器容器根据配置将服务提供者的服务到服务注册中心注册服务；

3、服务注册中心收到注册信息，将哪个服务运行在哪个服务器上进行记录；

一个服务可以在多个服务器的容器上运行；

4、服务的消费者程序，通过服务接口进行调用（Dubbo是个JAVA接口）

5、服务接口通过接口代理将请求转发给服务框架客户端；

6、服务框架客户端到服务器列表中查找，如果本地列表没有就到注册中心查询；

7、服务框架客户端根据最新的列表，根据负载算法获取列表中一台服务提供者服务器；

8、服务框架客户端，通过远程通讯模块将请求发给算出的服务提供者服务器；

9、服务提供者收到请求后，计算结果，返回值是个对象CLASS，包装响应的数据包，返回给调用方框架的客户端；

10、调用方的服务框架客户端收到返回后反序列化后恢复这个对象CLASS，然后通过接口代理返回给服务消费者程序



SERVICE MESH 服务网格



微服务架构落地：

业务先行，先理顺业务边界和依赖，技术是手段而不是目的；

现有独立的模块，后有分布式的服务；

业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎；



命令与查询职责隔离（CQRS）

读写分离



事件溯源



断路器：

某个服务出现故障，响应延迟或失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务 级联失效，这种情况下使用断路器阻断对故障服务的调用；



服务重试及调用超时：

上游调用者超时时间要大于下游调用者超时时间之和；

EDGE SERVICE

GOOD SERVICE

BAD SERVICE



最重要的是需求：

NEEDS VALUES principles

practices

tools



RPC 协议实现原理：

RPC是远程过程调用，HTTPS也算RPC的一种；

远程过程调用 RPC



通信协议

一个完整的应用层通信协议通常包括两个部分：

网络通信协议： TCP UDP

编码传输协议：二进制、文本；



为什么设计私有通信协议：



常见的私有协议模式：

定长协议，特殊结束符协议，变长协议（协议头+协议体）



DUBBO通讯协议

DUBBO利用requestID避免对头阻塞

REQUESTID 请求和响应是同一个ID ；



SOFA-RPC 通讯协议 BOLT协议



DUBBO协议和HTTP协议关系

HTTP是文本协议；

DUBBO是个框架的私有协议；



DNS 不能做服务发现，DNS不能识别后面的路径

总结：

微服务框架的核心功能：（dubbo springcloud 基本都是一样）

1、服务注册与发现

2、失效转移；

3、负载均和；

4、高效的远程通信；（长连接复用，二进制的序列化的数据，协议可定制）

5、减少对应用的侵入：框架（dubbo）来完成是远程部署还是本地部署；

6、版本管理：（保留半年的历史版本）



微服务的拆分原则，先大后小；先拆大的，再继续变小；

根据业务粒度来拆分



领域驱动设计 （DDD）

DDD domain-driven design



领域模型

领域就是业务的一切，需要把领域分析清楚。

设计是统一的。



为什么需要DDD

很多项目的实际情况：

用户或产品经理需求零零散散，不断变更

工程师在各处代码种寻找实现需求变更的代码，修修补补；

软件只有需求分析，没有真正的设计，系统没有一个统一的领域模型维持其内在的逻辑一致性；

功能特性并不是按照领域模型内在的逻辑设计，而是按照各色人等自己的主观想象设计；

网公司的几乎不会做这些设计



项目时间一长，各种困难重重，需求不断延期，线上BUG不断；管理者考虑是不是要推到重来；

而程序员则考虑是不是要跑路；



在DDD 还没有出现之前



事务脚本方式 （20年前就是这种方式）

controller ->service -> DAO



领域类：

contract ->product->recognitionStrategy->revenuRecongnition

如果 每一种合同、商品、策略都有自己的类



其实就是面向对象。

贫血模型 VS 充血模型

事务脚本有被称为贫血模型

领域模型的对象包含了对象的数据和计算逻辑



领域 ：组织所做的事情以及保包含的一切，这个范围太大了

子域：其实就是微服务

子域根据业务判断是否要进一步的细分。



DDD 战略设计师业务

DDD和业务架构设计很像



实体:就是领域模型对象；每个实体是唯一的

DDD分层架构

接口层 应用层 领域层



DDD战略设计

DDD重构的实践过程

当前系统设计与问题汇总讨论

数据和方法放在领域对象中去做，在每次需求迭代的时候逐步去重构做；



需要理清问题和解决方案；



DDD 的案例

目前 DDD 在战略建模中更有实际意义些。



APP电商的组织和系统

卖货->收钱->发货 ->算账

订购 收钱 发货

订单 支付记录 权益记录

严格匹配

电商的基本业务模型：

付钱 订单 收钱

买方 合同 卖方 卖货

交易物 算账



总结：

DDD 不是一门技术，DDD是方法论，DDD必须是以业务为基础；架构师需要对这个行业的业务领域非常熟悉，结合实际的业务需求基于DDD方法论来设计软件系统的，DDD没有标准答案，需要结合实际的业务需求给出合适的方案。