微服务架构设计模式

逃离单体地狱

单体架构的弊端

• 项目复杂度高时，团队开发效率严重低下。主要体现在以下几个方面：

• • 项目太过庞大复杂，本地编译运行慢，线上环境部署也慢；
  • 变更影响的范围大，导致不同模块的负责团队之间沟通成本上升；
  • 变更影响的范围大，导致测试需要覆盖的范围也大，测试时间漫长，存在大量的重复测试；

• 系统可靠性无法保证。因为系统过于庞大复杂，且运行在一个进程中，无法做到故障隔离，任何一个错误发生都将导致程序崩溃。

• 系统性能下降，不利于进行扩展。

• 限制所有开发人员必须使用相同的技术栈，无法尝试新的技术。

微服务

微服务定义概括为：

将应用程序功能性地分解为一组服务的架构风格。重要的是，每个服务是由一组功能内聚、相同的实例组成。

该微服务定义来源于三维可扩展模型。三维可扩展模型，就是在X、Y和Z轴三个维度上进行扩展的模型。其中，在每个维度上进行扩展的含义为：

• X轴：水平复制，创建多个相同的实例来处理从负载均衡器分发过来的请求；
• Y轴：数据分区，在特定属性上实现某种策略，使得请求被路由到不同的实例，说白了，就是路由算法、负载均衡；
• Z轴：功能分解，将单体应用在功能维度上分解成一组服务；

X和Y轴都是目的在于提升服务的吞吐量和可用性，并没有解决开发和应用复杂度问题。所以，Z轴的目标就是按功能对应用进行分解，达到解耦，降低复杂性的目的。

PS：此处描述与文中不符，基于个人喜好，将Y轴与Z轴功能进行了交换

微服务与SOA（Service-Oriented Architecture）的区别：

• 进程间通信方式。SOA采用比较重量级的智能管道通信，微服务采用轻量级的、开源的通信框架（哑管道），比如REST、gRPC。
• 数据处理方式。SOA采用全局数据模型，共享数据库，而微服务架构每个服务都有一个数据库。
• 服务规模。SOA善于集成大型、复杂的单体服务，服务尺寸相对于微服务的要大。

微服务不是“银弹”，我们要理性地认识它的优势和弊端。

人的思维就像大象和骑大象的人。大象代表了人情绪化的部分，而骑大象的人代表了人理性化的部分，但冲动的时候，骑大象的人往往驾驭不了大象。

难点

• 服务调用导致的网络延迟（解决办法：保证每个服务响应速度）；
• 如何保证数据一致性问题（解决办法：分布式事务技术）；
• 上帝类问题（解决办法：每个服务都定义自己的领域模型，只取上帝类中部分相关的属性，并取带有本服务特点的命名）；

上帝类：在整个应用中的全局类，将应用程序中很多状态和行为绑定在一起，对应数据库中的很多字段。说白了，就是很多领域里都用到了这个类，但其他领域可能用不上该类的所有属性信息。比如订单、账户等。

服务拆分策略

逻辑视图

1.分层架构

主要包括三层：表示层、业务逻辑层、数据持久层，每层可以依赖紧邻的下一层或下面任何层。

优点：条理清晰，层次分明

缺点：业务逻辑依赖数据持久，导致无法单独测试

2.六边形架构

以业务逻辑为中心，应用程序有入站和出站两类适配器，入站适配器调用业务逻辑来处理外部请求，出站适配器被业务逻辑调用来调用外部应用程序。

优点：业务逻辑可以单独测试

架构设计流程

1. 将应用程序的需求提炼为各种关键请求；

2. 1. 创建领域模型
   2. 定义系统操作

3. 确定如何分解服务；

4. 1. 根据业务能力分解服务，比如供应商信息管理、订单管理、履约管理和会计管理，这些都是顶层业务，每个顶层业务可能还包括子能力。一个顶层能力映射一个服务，还是下面的多个子能力映射多个服务，这是一个非常主观的过程，并且随着以后对业务领域的了解和项目发展，还会对服务进行调整。
   2. 根据子域分解服务，基于DDD思想将领域模型分解成多个子域，这样每个子域就对应一个服务；

5. 确定每个服务的API；