微服务架构设计模式学习文档

微服务架构设计模式学习文档

PS：图源网络，侵删勿扰

微服务不在于“微”，而在于单一职责。

——引自《微服务架构与实践》王磊

特点：

• 单一职责
• 轻量通信（无关平台语言、通过轻量级通信机制互联）

采用xml或json格式达到通用，可以基于http协议或rpc协议达到服务间的轻量级通信

• 业务独立（开发、测试、部署）

• 进程隔离

• 持续交付
• 技术的可扩展性（接口不依赖于特定语言和平台）

劣势：

• 网络通信：进程内调用比进程间调用用时短，分布式调用严重依赖网络可靠性与稳定性。
• 自动化测试条件严苛（测试难度大）

• 分区数据库架构（需要使用基于最终一致性的方法）
• 跨越多服务变更（服务之间可能有依赖关系）

难点：

• 性能（跨进程、跨网络、跨数据库）：考虑通信成本、网络延迟、带宽、多服务交互的响应时间

• 可靠性：服务数量节点增多可能带来潜在故障点，防止单点故障

• 异步：同步通信造成阻塞，异步通信缺增加功能实现的复杂度，出现故障时的链路追踪、定位、调试有难度。
  

• 数据一致性：保持数据一致性需要使用saga或者什么cqrs视图查询什么的

• 联表查询：

尝试使用微服务架构改造遗留系统：

改造策略/原则：

• 最小修改（停止挖掘）
  

• 功能剥离
  

• 数据解耦

• 数据同步
  

——引自《微服务:从设计到部署》Oposguy翻译与排版

每个微服务拥有自己的数据库，这将导致部分数据冗余，但这样可以实现松耦合。

进程间通信：

服务中使用了通知、请求/响应和发布/订阅组合。

必须要加入熔断处理机制（或者设置超时、限制未完成的请求数量或提供回滚操作），否则将会造成线程堵塞无法响应。

使用异步基于消息的通信，例如使用rabbitmq、amqp等等

如何维护多个服务之间的业务事务一致性，传统的两阶段提交2pc已经不能使用

如何从多个服务中检索数据（利用事件驱动架构作为解决方案，首先发布一个事件，让与其相关的数据库所属的微服务订阅该事件，这样就导致：某个微服务内的事件被触发时，订阅该事件的微服务模块进一步触发，导致更多的事件被发布）

中间层次是消息代理

事件驱动的架构能够跨越多服务并提供最终一致性事务，另外就是能够生成和维护物化视图。

微服务重构策略：

• 停止挖掘
  

以上需要两个组件，第一个为api网关，提供负载均衡、请求分发、路由控制；第二个是粘合代码，用于与单体集成，毕竟一个服务很少孤立存在，通常需要访问单体的数据库。这就需要粘合代码来负责数据集成。

• 提取服务
  
  

——引自《.NET微服务与容器化.NET应用架构指南》Cesar de la Torre,Bill Wagner,Mike Rousos

创建微服务的重点是要创建低耦合的微服务，只要他们之间没有太多的直接依赖，就应该尽可能小，重要的还是要有内部一致性和对其他服务的依赖。

优势：长期敏捷性、独立部署、细粒度、高扩展、可维护、独立进行横向扩展以便节约成本。

然而，微服务架构的数据访问会变得更加复杂。即使在一个微服务或限界上下文里能够或者应该做到ACID事务一致，但每个微服务的数据是独立的，所以只能通过微服务的API来访问。将数据进行封装确保了微服务是松耦合且能独立变化的。如果多个服务访问相同数据，数据的更新就要求协调同步到所有服务，这会破坏微服务生命周期的自治性。这就表示，当业务流程跨越多个微服务时，最终一致性是唯一的办法。这比写一个简单的SQL连接要复杂得多。同理，很多其他关系型数据库功能也不支持跨微服务使用。

分布式数据管理的挑战与解决方案

• 如何定义微服务边界（DDD领域驱动设计及界限上下文）

• 如何创建从多个微服务获取数据的查询（聚合信息提高效率，1.使用api网关，但是可能会成为单点故障或者系统瓶颈，所以要尽可能使用多个细粒度的api网关，2.使用CQRS查询，即使用物化视图模式）

• 如何在多个微服务之间实现一致性（应该使用基于异步通信，或者说是基于事件的通信，即异步事件驱动通信）

• 如何在多个微服务之间通信（http同步本质，会带来http调用链条，造成阻塞和性能低下甚至雪崩式宕机，会有这样一种争议：实际上是一种单体式应用，进程间是基于http的，没有进程内通信机制。因此我们建议，使用基于消息或时间的异步通信，或者使用http轮询方式）