说明

讲师：李智慧



阿里早期微服务架构重构

单体应用，所有的服务都在一个War包里面发布，体积大约1.2G。

巨无霸应用系统带来的问题

编译、部署困难：

• 对于网站开发工程师而言，打包构建一个巨型应用是一件痛苦的事情。

• 也许只是修改了一行代码，输入 build 命令后，抽完一支烟，回来一看，还在 building；

• 又去喝了一杯水，回来一看，还在building；

• 又去了一次厕所，回来一看，还在building；

• 好不容易build 结束，一看编译失败，还得重来...

• 想砸了显示器有木有？

代码分支管理困难：

• 复用的代码模块由多个团队共同维护修改，代码 merge 的时候总会发生冲突。

• 代码 merge 一般在网站发布的时候，和发布等问题互相纠结在一起，顾此失彼，每次发布都要半夜三更。



数据库连接耗尽：

• 巨型的应用、大量的访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用与数据库的连接通常使用数据库连接池，以每个应用10个连接计，一个数百服务器集群的应用将需要在数据库上创建数千个连接，数据库服务器上，每个连接都会占用一些昂贵的系统资源，以至于数据库缺乏足够的系统资源进行一般的数据操作。



新增业务困难：

• 想要在一个已经乱如麻般系统中增加新业务，维护旧功能，难度可想而知。

• 一脚踩进去，发现全都是雷，什么都不敢碰。许多新工程师来公司半年了，还是不能接受业务，因为不知道水有多深。

• 于是就出现这种怪现象：熟悉网站产品的“老人” 忙得要死，加班加点干活；不熟悉网站产品的信任一帮忙就出乱，跟着加班加点；

• 整个公司热火朝天，加班加点，却还是经常出故障，新产品迟迟不能上线。



解决方案就是拆分，将模块独立部署，降低系统耦合性：

解决方案就是拆分，将模块独立部署，降低系统耦合性：

• 纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。

• 横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。



微服务框架

Web Service 与企业级分布式服务

• Service Provider: 服务提供者

• Service Requester：服务消费者，客户端

• Service Broker：服务注册中心。服务提供者注册服务到服务注册中心；服务消费者从服务注册中心请求服务，服务注册中心调用*服务提供者*，最终把结果返回给服务消费者。



数据格式是：XML，XML一半的数据都是冗余的，性能比较低下。



服务提供者通过 WSDL （Web服务描述语言，Web Services Description Language）向注册中心（Service Broker）描述自身提供的服务接口属性，注册中心使用 UDDI (Universal Description, Discovery, and Integration, 统一描述、发现和集成)发布服务提供者提供的服务，服务请求者从注册中心检索到服务信息后，通过 SOAP (Simple Object Access Protocol, 简单对象访问协议) 和服务提供者通信，使用相关服务。



Web Service 虽然有着成熟的技术规范和产品实现，以及在企业应用领域有许多成功的案例，但是也具有一些固有的缺点：

• 臃肿的注册和发现机制；

• 低效的 XML 序列化手段；

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

• 复杂的部署和维护手段；



这些问题导致 Web Service 难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。



微服务框架需求

对于大型互联网系统，除了 Web Service 所规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持：

• 失效转移(Fail Over): 对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。

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

• 高效的远程通信： 对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统性能的瓶颈。

• 对应用最少侵入： 网站技术是为业务服务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署。

• 版本管理：为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务器调用失败。企业应用系统可以申请停机维护，同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。（阿里的对升级以后服务维护半年，半年以后就下线。）



微服务架构 (Dubbo)

1. 服务提供者 注册到 服务注册中心，把服务映射到服务提供者列表；

2. 服务消费者程序，调用服务接口；

3. 接口访问代理获取到服务消费者调用的接口；

4. 服务框架客户端，调用服务提供者列表找到服务提供者；

5. 负载均衡策略分配一个服务给服务框架客户端；

6. 远程通讯模块与客户端建立连接；

7. 远程通信模块，调用 服务调用线程；

8. 服务调用线程 请求服务提供者程序， 服务提供者程序返回服务的 class 给服务调用线程；

9. 服务调用线程 返回 class 给远程通讯模块；

10. 远程通讯模块 返回 class 给 服务框架客户端， 服务框架客户端 用 class 创建对象，调用里面的方法即可。



Service Mesh 服务网格

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

Service Mesh的Sidecar模式



火过一阵子，实际应用收益不是很大。



微服务架构实践

微服务架构落地

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

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

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

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



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

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

• 更清晰的领域模型；

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

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



事件溯源

将用户请求处理过程中的每次状态变化都记录到事件日志中，并按时间序列进行持久化存储。

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

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



断路器

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

• 断路器三种状态：关闭，打开，半开。

服务重试及调用超时

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

最重要的是需求

最重要的是需求。



RPC 协议实现原理

远程过程调用 (RPC)

通信协议（Communications Protocol）

通讯协议在电信领域中是指任何物理介质中允许两个或多个在传输系统中的终端之间传播信息的系统标准，也是指计算机通信或者网络设备的共同语言。



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

• 网络通信协议：TCP、UDP

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



为什么设计私有通讯协议？

• 充分并有效利用通讯协议里的每个字段，减少冗余数据传输。

• 灵活满足自定义通讯需求，例如 CRC 检验、Server Fail-fast、自定义序列化器。

• 最大程度满足性能需求：IO 模型和线程模型的充分利用。



常见的私有协议模式

Dubbo 通讯协议

org.apache.dubbo.remoting.exchange.codec.ExchangeCode



Dubbo 通讯协议-解码 Response 对象

org.apache.dubbo.rpc.protocol.dubbo.DubboCodec

Dubbo 通讯协议 - 解码 Request 对象

Dubbo 利用 requestId 避免对头阻塞

requestId：请求 ID，该字段主要用于异步请求时，保留请求存根使用，便于响应回来时出发回调。另外，在日志打印与问题调试时，也需要该字段。



SOFA-RPC 通讯协议 （Bolt 协议）- 请求命令

SOFA-RPC 通讯协议 （Bolt 协议）- 响应命令

SOFA-RPC 通讯协议 （Bolt 协议）

com.alipay.remoting.rpc.protocol.RpcCommandEncoderV2

序列化协议



总结

有些团队加班特别狠，最终整个项目失败了。



不要<font color='red'>用战术上的勤奋，掩盖战略上的懒惰。</font>



微服务的关键点不在技术，搞不清楚业务，搞不清楚模块的边界，就只有死路一条。先把逻辑关系，耦合关系理顺了，业务开发人员、微服务维护人员、产品经理职责要理顺，目标不清楚，就不要搞微服务。