《微服务架构设计模式》之逃离单体地狱

六边形架构

微服务之法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bnPdfQAA-1622119926408)(/Users/hhaip/Library/Application Support/typora-user-images/image-20210527201718506.png)]

单体地狱

单体项目随着业务发展，代码越来越膨胀，单体项目规模越来越大，参与团队人员越来越多，沟通成本也随之不断增高，耦合性复杂性越来越强。不利于维护、扩展，代码变更不可靠，开发会变得缓慢和痛苦，开发周期变长，敏捷开发和部署已经不可能。

单体应用带来的问题

案例：大型FTGO开发团队将代码提交到生产环境的路途漫长而艰巨，并且涉及手工测试。FTGO应用程序庞大、复杂、不可靠、难以维护。

1. 过度复杂性吓退开发者

业务耦合性极强、代码膨胀、个人任务无法聚焦、开发团队风格不一导致代码不规范。更糟糕的，这种极度复杂性还会进一步恶性循环，由于代码难以理解，开发变得更困难，代码越来越难懂且更复杂。

2. 开发速度慢周期长

3. 从代码提交到实际部署周期很长，而且很容易出问题（对于测试来说，测试复杂度更高，测试周期更长）

   （1）单体应用敏捷开发过程中，众多开发者向同一个代码库提交修改，这样会导致提交过程中可能出现各种冲突合并问题而无法交付

   （2）若采用功能分支，则最后的合并代码痛苦而漫长

   案例：

   （1）坤同SCMS和KAETL服务就因为项目过于膨胀，上线后依然会出现问题

   （2）由于KAETL和SCMS过于庞大，所有开发者可能在同一个分支开发或采用功能分支，提交代码或合并分支均出现过类似问题

4. 难以扩展

5. 维护可靠的单体应用是一项挑战（单体可能需要一个开发团队维护）

   （1）单体应用的模块之间对资源相互竞争，无法资源隔离，这会导致因资源的相互争抢而导致程序崩溃，甚至一个模块出现问题导致整个应用无法使用。（内存泄漏、CPU资源被某个模块耗尽、死锁）

   （2）不定期出现问题（半夜），让开发者惧怕，同时也让客户失去对我们的信任

6. 需要长期依赖某个已经过时的技术栈

拯救之道：微服务架构

什么是微服务架构？尺寸大小（代码行数）？发布周期？耦合度？

为什么使用微服务架构？

Netflix，Adrian C ockcroft：微服务架为面向服务的架构，由松耦合和具有边界的上下文元素组成。

作者对微服务架构定义：把应用程序功能性分解为一组服务的架构风格。每个服务的由一组专一的、内聚的功能职责组成。

微服务架构特性：

• 微服务架构是一种更严格的模块化的形式

• 每个服务都拥有自己的数据库

扩展立方体模型

X轴扩展：在多个实例之间进行负载均衡

需要一个负载均衡器，如：nginx、haproxy、kong、阿里SLB、网关

Z轴扩展：根据请求的属性路由请求

该扩展强调数据分区路由：可一个自定义路由器

Y轴扩展：根据功能把应用拆分成服务

微服务架构以服务作为模块化单元，API作为外界通信的边界，外界无法越过API直接访问内部程序，可理解为服务隐藏了内部复杂性，暴露了简单接口。

微服务架构关键特性，服务之间松散耦合，即数据之间也松耦合，这使得每个服务都有自己的数据库（服务数据库修改数据模型不用同其他服务开发者协调，服务不会因为其他服务锁住了数据库而进入阻塞）

微服务和SOA的区别

1. SOA的技术栈相当于微服务架构较重量级，如：服务之间通信一般采用SOAP、WS* 等，通常还会使用ESB总线作为业务和消息处理的智能通道

2. SOA一般会使用共享数据库也即是全局数据库，而微服务架构中每个服务都会有自己的专属数据库

3. SOA服务善于集成大型复杂的单体应用，而微服务架构中服务的规模相对来说比较小，业务复杂度也比较简单的尺寸（规模）

4. 每个服务都相对较小并容易维护

   业务比较简单且业务聚合，这样比较容易维护

5. 每个服务可以独立部署

6. 每个服务可以独立扩展（如：横向扩展）

   按扩展立方体模型，可按X轴进行横向扩展

7. 每个服务可以由独立的团队治理

   如：每个服务可由独立的个人或某个小团队独立负责，而不需要多个人或多个团队交叉管理

8. 可自定义服务所采用的技术

9. 更好的容错性

   微服务架构可以实现更好的故障隔离，某个服务出现故障，不会影响其他服务的正常运行

微服务架构好处和弊端

微服务架构好处

1. 使大型的复杂应用程序可以持续交付和持续部署

   • 微服务拥有持续交付和持续部署所需要的可测试性（使自动化测试更容易）

   • 微服务拥有持续交付和持续部署所需要的可部署性（使得频繁将更改部署到生产更容易）

   • 它使开发团队能够自主且松散耦合

   

2. 每个服务都相对较小并容易维护

   业务比较简单且业务聚合，这样比较容易维护

3. 每个服务可以独立部署

4. 每个服务可以独立扩展（如：横向扩展）

   按扩展立方体模型，可按X轴进行横向扩展

5. 每个服务可以由独立的团队治理

   如：每个服务可由独立的个人或某个小团队独立负责，而不需要多个人或多个团队交叉管理

6. 可自定义服务所采用的技术（技术更新更方便）

7. 更好的容错性

   微服务架构可以实现更好的故障隔离，某个服务出现故障，不会影响其他服务的正常运行

微服务架构弊端

1. 微服务拆分和定义是一项挑战

   如果对系统的服务拆分出现了偏差，你很可能会构建出一个分布式的单体应用：一个包含了一大堆互相之间紧耦合的服务，却又必须部署在一起的所谓分布式系统。这将把单体架构和微服务架构两者的弊端集于一身。

   思考坤同SCMS改造？

2. 分布式系统带来的各种复杂性，使开发、测试和部署变得更困难

   如：分布式事务、分布式系统数据一致性、跨服务聚合查询，微服务部署相对单体应用对部署技术和部署方案运维成本要求更高

3. 当部署跨越多个服务的功能时需要谨慎的协调更多开发团队

4. 开发者需要思考到底应该在应用的什么阶段使用微服务架构

模式和模式语言

模式是针对特定上下文中发生问题的**可重用解决方案**（源于建筑架构模式）。如：策略模式、观察者模式都可用于解决特定场景问题

微服务架构的模式语言是一组模式，可以帮助架构师使用微服务架构快速构建应用程序

微服务架构不是“银弹”，它同样也会带来各种问题，如何解决？

图示展示了不同的模式组解决的不同问题领域。右边模式组是解决单体架构转换为微服务架构所产生的问题

模式三个重要组成

1. 需求（需要解决的问题）

2. 结果上下文（采用模式后可能带来的后果）

   带来的可能结果包含三种

   • 好处（这个模式的好处和它解决了哪些问题）
   • 弊端（这个模式的弊端和它解决不了的问题）
   • 问题（使用这个模式所引入的新问题）

3. 相关模式

   指的是这个模式与其他模式之间的关系，有5种关系

   • 前导（前导模式是催生这个模式的需求模式）
   • 后续（后续模式是指用来解决当前模式引入的新问题模式）
   • 替代（当前模式的替代模式，提供了另外的解决方案）
   • 泛化（针对一个问题的一般性解决方案，如：一个问题存在多种常规性解决方案）
   • 特化（针对特殊问题的具体解决方案）

模式分组

模式可以按照解决问题的相关类型进行分组

1. 基础设施相关模式组（这些模式解决通常是在开发环节跟基础设施有关的问题）
2. 应用基础设置相关模式组（这些模式解决应用层面的基础设施相关问题）
3. 应用相关模式组（这些模式解决开发人员面对的具体技术和架构问题）

根据模式所解决的问题不同进一步分组：

4. 服务拆分相关模式
   

5. 通信相关模式

上图通信模式分为5组：

• 通信风格：使用何种进程间的通信方式（RPC、REST、MQ、GRPC等）
• 服务发现：客户端如何获取服务端实例的调用地址（IP地址）
• 可靠性：客户端调用失败如何保证服务之间的可靠通信（失败降级措施）
• 外部API：客户端如何与服务端进行通信
• 事务性消息：如何将消息发送、事件发布这样的动作与更新业务数据的数据库事务集成（如上图中如果发送消息，则必须保证消息和某个业务的变更保证原子性）

6. 实现事务管理的数据一致性相关模式
   

   微服务架构不可避免的微服务之间的数据一致性问题，saga模式和阿里的seata都可以解决，一致性区分：最终一致性和实时一致。

7. 在微服务架构中查询数据的相关模式

微服务架构里由于每个服务有自己的库，通常需要调用多个服务API来组合数据。微服务架构里可以使用命令查询隔离方式（CQRS）来解决数据聚合查询问题

9. 服务部署的相关模式

   传统单体部署：将应用程序打包成jar或war后复制到服务器即可

   微服务架构部署：由于服务较多，传统不是模式已不适合。服务的开发不尽语言相同，需要一种高度自动化部署基础设施（部署平台），服务的部署一般是基于容器、Serverless或虚拟机技术

10. 可观测性的相关模式

健康检查API、日志聚合（ELK）、链路追踪、异常跟踪、审计日志（记录用户的行为）、应用指标

11. 实现服务自动化测试的相关模式

12. 解决基础设施和边界问题的相关模式

13. 安全相关的模式

    如：用户信息认证

    微服务架构中，用户信息认证一般放在API Gateway中完成，然后它将有关用户的信息传递给调用它的服务。

    常用认证方案：令牌模式（JWT、JSON Web令牌），坤同当前使用JWT，在网关认证令牌

以上各种模式即是采用微服务架构后所产生问题的各种解决模式。架构不是唯一关注的领域，流程和组织也需考虑

微服务之上：流程和组织

架构流程组织关系

大型复杂应用程序快速、频繁和可靠交付需要具备几项DevOps关键能力：

大型应用应该支持频繁快速迭代以适应不断变更的需求和修改（不可能一两周一次迭代）

1. 持续交付（可随时交付）
2. 持续部署
3. 小型自治团队
4. 微服务架构

团队如果太大，则沟通成本可能会过高，往往会导致团队效率降低。如：早会有20人会怎样？

解决方法：

大团队拆分成小团队，人员规模控制在8-12人，每个团队的业务职责不同。开发尽可能负责一个或多个服务，这些服务实现了一个或多个业务能力。团队是跨职能的，可以独立完成开发测试部署，而无需频繁的与其他团队沟通，若某个服务出现问题则对应负责人会很清楚（坤同改造前则做不到，问题可能和多个人有关）。这样每个小团队则实现了自治，团队实现了松耦合（相互影响较小），进而大大降低了沟通成本。

组织扩展：可通过添加新团队的方式扩展组织，团队的人员增减对其他团队影响较小

逆向的康威定律

**问题：**康威定律设计系统的组织，往往被组织的架构所限制，最终设计的结果是这些组织的沟通结构的副本

逆向康威定律：应用程序的架构往往反映了开发它的组织架结构，应用康威定律反向设计企业的组织架构，使其结构与微服务的结构一一对应，这样可以确保开发团队与服务一样松耦合。

持续交付和持续部署（DevOps）

持续交付

Jez Humble 定义：持续交付能够以持续的方式安全、快速地将所有类型的更改（包括新功能、配置更改、错误修复和实验）交付到生产环境或用户手中

DevOps目标特征：软件总是可以随时交付

传统交付和持续交付对比

1. 在传统组织中，部署的频率低，交付的时间很长。特别是开发人员和运维人员通知都会在交付期间熬夜到最后一刻。

2. devops组织经常发布软件，通常一天会多次发布软件，生产的问题反而少的多。（如：亚马逊 11.6秒部署一次，netflix 11分钟一次）

持续交付依赖于自动化测试，紧接着依托于自动化部署将应用部署到生产环境

软件开发四个有用评估指标

1. 部署频率：软件部署到生产环境中的频率
2. 交付时间：从开发人员提交变更到变更被部署的时间
3. 平均恢复时间：从生产问题中恢复的时间
4. 变更失败率：导致生产问题的变更的百分比（提到到生产功能中出现问题的功能百分比）

持续交付和持续部署为业务带来的价值

• 缩短了产品（或新功能）的上市时间，使企业能够快速响应客户的反馈
• 使企业能够提供当今客户所期望的可靠服务
• 员工满意度更高，因为开发人员可以因此话费更多时间来提供有价值的功能，而不是四处担任救火员

成熟的自动交付持续部署技术

• 阿里云平台持续部署工具

• netflix Spinnaker 自动化部署工具

• 产品化的PaaS平台（例如：Pivotal Cloud Foundry）

• Docker容器编排工具 如：Docker Swarm或Kubernates

总结

1. 越复杂的系统越容易失控，越不可维护，服务的治理挑战大，长期的运维成本更高
2. 微服务架构好处弊端，以及针对使用微服务架构所带来的问题提出各种解决的设计模式
3. 微服务架构让应用由繁变简
4. 采用微服务架构，不仅改变了技术架构，也改变了组织架构和开发流程，归根结底是对工作开发中的人进行的一系列改变

问题

是否需要架构师？（解决复杂软件的架构设计工作，比如：建筑架构师设计好复杂建筑的架构）

为什么要从单体转换至微服务架构？

1. 单体架构已不能满足业务迭代需要
2. 需要适应当前业务的最合适的新架构：微服务架构

SO：架构随着业务不断变通（没有一成不变）