架构师训练营第 1 期 - 第 10 周学习总结

本周学习了微服务架构，包括微服务介绍、微服务落地、微服务网关技术、领域驱动设计、软件组件设计原则

一、微服务介绍

巨无霸系统带来的问题

• 编译、部署困难 - 有时候仅仅是改了一行代码，就需要花费很多的时间进行编译、运行，反复尝试，会白白浪费很多时间

• 代码分支管理困难 - 复用的代码模块由多个团队共同维护和修改，代码merge经常发生冲突，导致解决冲突花费大量时间，又影响网站的发布

• 数据库连接耗尽 - 因为巨无霸应用经常需要集群发布，每个应用都连接着相同的数据库，这样集群部署的话数据库连接成规模的增加，容易导致数据库连接耗尽

• 新增业务困难 - 代码耦合严重，模块之间相互依赖，新增业务涉及到改造既有模块，难度可想而知



一般解决方案就是拆分：

• 纵向拆分 - 将一个大应用拆分成多个小应用，如果是新增业务，就直接独立部署成一个应用

• 横向拆分 - 将复用的业务拆分出来，部署成微服务，新增业务只需要调用这些微服务即可

微服务框架

1. 企业级分布式服务ESB

服务提供者通过WSDL向注册中心描述服务接口，注册中心使用UDDI发布服务提供者的服务，服务请求者从注册中心获取服务接口信息，通过SOAP协议和服务提供者通信，调用相关服务。但是ESB的缺点也很明显：

• 臃肿的注册与发现机制

• 低效的XML序列化

• 开销相对较高的HTTP远程通信

• 复杂的部署与维护手段

所以ESB难以满足大型互联网应用高性能、高可用、易部署、易维护的要求。

1. 微服务框架需求

微服务框架除了要满足服务注册与发现，服务调用等功能外，还需要支持：

• 失效转移 - 微服务需要集群部署，微服务框架可以在集群中实现失效转移，以满足服务的高可用

• 负载均衡 - 服务请求者可以通过负载均衡技术访问集群部署的服务提供者

• 高效的远程通信 - 大型互联网应用会有大量的请求，所以高效的远程通信是必然的要求

• 对应用侵入最少 - 微服务本身需要支持可集中式部署，也可分布式部署

• 版本管理 - 微服务进行升级的时候，可以兼容老的服务请求，这个支持应该是微服务本身提供的

1. Service Mesh服务网格

Service Mesh是一个基础设施层，用于处理服务间的通信，通常表现为一组轻量级网络代理，他们与应用程序部署在一起，而对应用程序透明

二、微服务落地

微服务架构落地

需要注意以下几点：

• 业务先行，技术为业务服务，技术只是手段，先理顺业务边界和依赖

• 先有独立的模块，后有分布式服务

• 业务耦合严重、逻辑复杂的系统进行微服务重构要谨慎

• 要搞清楚实施微服务的目的是什么，业务复用，还是开发边界清晰，还是分布式提升性能？

CQRS

在服务接口层面将查询（读操作）与命令（写操作）隔离，实现服务层的读写分离

• 更清晰的领域模型

• 针对读写分别优化，实现更好的性能

• 查询服务不会修改数据，更好地保护数据

Event Sourcing

将用户请求过程中的每次状态变化都记录成事件，并按照时间顺序保存到持久化存储中

• 利用事件溯源，可以复现任何用户状态，进行复核审计

• 利用事件溯源，可以监控任何用户状态变化，并在此基础上实现分布式事务

断路器

当某个服务出现故障、响应延迟或者失败增加，那么继续调用这个服务会导致调用者请求阻塞，资源消耗增加，可以使用断路器阻断故障服务的调用，一般断路器有三种状态：关闭、打开、半开

服务重试与调用超时

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

三、微服务网关技术

基于网关的微服务架构

一般会有一个API GATEWAY服务，所有前段的请求都会发送到API GATEWAY服务，网关服务负责转发请求到具体的微服务，如果微服务是不同的请求协议，那么网关会负责转换具体的协议并请求不同的微服务。

网关有以下作用：

• 统一接入，实现高性能、高并发、高可用、负载均衡

• 安全防护，防刷控制，黑白名单控制

• 流量监控与容错，可以实现限流、降级、熔断

• 协议适配，可以适配不同的协议，包括http、dubbo、grpc、hessian

网关微服务本身也是一个服务消费者，会注册到服务注册中心，调用服务提供者的服务

网关本身没有什么业务，主要职责是做各种校验和拦截，通过管道技术也就是责任链模式将这些职责链接起来

四、领域驱动设计

贫血模型 VS 充血模型

• 在事务脚本中，service、dao等对象只有方法，没有变量，所以事务脚本也叫贫血模型

• 领域模型是合并了行为和数据的领域对象模型。通过领域模型对象的交互完成业务逻辑，设计好了领域模型对象，就设计好了业务逻辑实现。领域模型也叫充血模型

DDD战略设计

领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。

1. 领域

领域是一个组织所做的事情以及包含的一切

1. 子域

把整个领域拆分多个子域进行设计。比如电商下面的子域就有用户、商品、订单、库存、物流、发票等。

1. 限界上下文

限界上下文是指在领域边界中，任何领域对象都只表示特定于该边界内部的确切含义。限界上下文和子域具有一对一的关系，用来控制子域的边界，保证子域内的概念统一性。

1. 上下文映射图

不同的限界上下文，会有各种交互。DDD使用上下文映射图来设计关联和交互。

DDD战术设计

1. 实体

领域模型对象也称做实体，每个实体都是唯一的，具有一个唯一标识。实体设计是DDD的核心所在，首先通过业务分析，识别出实体对象，然后通过相关的业务逻辑设计实体的属性和方法。

1. 值对象

并不是领域内的对象都应该设计为实体，DDD推荐尽可能的使用值对象。值对象的一个特点就是不变性，一个值对象创建以后就不能再改变了。

1. 聚合

聚合是一个关联对象的集合，每个集合都有一个根和一个边界。边界定义了聚合内部的内容，根是聚合中包含的单个特定实体。



DDD战略设计有领域、子域、限界上下文、上下文映射图，DDD战术设计有实体、值对象、聚合、CQRS、Event Sourcing。通过战略设计，划分模块和服务的边界以及依赖关系，是微服务架构的关键。

五、软件组件设计原则

组件内聚原则

组件内聚原则讲的是哪些类应该聚合在同一个组件中，以便组件能提供相对完整的功能，而又不过于臃肿

• 复用发布等同原则

• 共同封闭原则

• 共同复用原则

组件耦合原则

组件耦合原则讲的是组件之间的耦合关系应该如何设计

• 无循环依赖原则

• 稳定依赖原则

• 稳定抽象原则