《微服务架构设计模式》-学习总结01

最近，新的启动项目准备考虑采用微服务架构来设计和开发。知乎文章推荐了一本好书《微服务架构设计模式》，该书是微服务架构大牛Chris Richardson亲笔力作。刚看完前几章就觉得书中提到的问题和解决方案，真的是非常契合很多小软件公司的现实情况。如果你们公司有遇到下面的问题（特别是从事移动互联网APP或企业Web应用开发的）强烈推荐本书：

• 所有后端功能都集中在一个或少数几个非常庞大、错综复杂、历史悠久且技术过时的后端服务中。
• 总是不能按时交付。开发团队效率低下，从代码提交、测试到正式部署上线经常需要几天甚至一周的时间。
• 版本更新是个苦差事，费力又不讨好。每个软件版本更新过程都要半夜进行，过程战战兢兢，出现更新问题不能及时解决，有时候不得不回滚更新，即使更新成功也要进行连续一天或者十几个小时的救火。
• 团队经常扯皮。前后端开发相互甩锅，开发和测试相互甩锅，运维和开发相互甩锅。

企业应用程序架构设计的基础知识

本书第一章从讨论单体地狱的问题出发，引出微服务架构的解决方案。首先，你需要企业应用程序架构设计的基础知识：

1.三层架构

• 表示层（UI）：展现给用户的界面
• 业务逻辑层（BLL）：对数据业务逻辑的处理
• 数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、改动和查询等。

2.Web应用程序设计

3.使用面向对象设计来开发业务逻辑

4.关系型数据库：SQL和ACID事务的概念

• Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务，不可分割，不可约简。
• Consistency（一致性）：事务开始之后和事务结束之后，数据库的完整性没有被破坏。写入的数据必须完全符合所有以预设约束、触发器、级联回滚等。数据库事务的一致性就规定了事务提交前后，永远只可能存在事务提交前的状态和事务提交后的状态，从一个一致性的状态到另一个一致性状态，而不可能出现中间的过程态。
• Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括 未提交读、提交读、可重复读和串行化。
• Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即使系统故障也不会丢失。

5.使用消息代理和REST API进行进程间通信

6.安全，包括身份验证和访问授权。

微服务架构

把应用程序功能性分解为一组服务的架构风格。每个服务都是由一组专注的、内聚的功能职责组成。服务之间是松耦合的，仅通过服务通过API提供外部访问，每个服务都拥有自己的私有数据库。

1.微服务架构与SOA的区别：

	SOA	微服务
服务间通信	智能管道，例如Enterprise Service Bus，往往采用重量级协议，例如SOAP	使用哑管道，例如消息代理，或者服务之间点对点通信，使用例如REST或gRPC类的轻量级协议
数据管理	全局数据模型并共享数据库	每个服务都有自己的数据模型和数据库
典型服务的规模	较大的单体应用	较小的服务

2.微服务的优势和不足：

Good:

• 持续交付和持续部署：使大型的复杂应用可以持续交付和持续部署。
• 易维护：每个服务都相对较小并容易维护
• 独立扩展：服务可独立扩展，不论是采用X轴扩展的实例克隆，还是Z轴扩展的流量分区方式。
• 容错性：更好的容错性，可以实现更好的故障隔离。
• 更容易实验和采纳新的技术：消除对某项技术栈的长期依赖。

Bad:

• 服务的拆分和定义是一项挑战
• 分布式系统带来的各种复杂性，使开发、测试和部署变得更加困难。进程间通信机制，使用Saga来维护服务之间的数据一致性。
• 当部署跨越多个服务的功能时，需要谨慎地协调更多开发团队
• 开发者需要思考到底应该在应用的什么阶段使用微服务架构

微服务架构的设计模式

为解决微服务架构引入的新问题，也为微服务开发者讨论问题提供一个共同的语义空间，作者定义了适用于微服务架构的各种设计模式。

学习总结

1. 软件架构是一种取舍。

• 微服务是解决大型项目陷入单体地狱问题的方法。但是项目初期采用微服务的成本可能过高，为了快速出产品，往往采用单体的方式先满足需求解决问题。

2. 没有银弹，微服务也不是万能的。辩证的看，微服务架构带来各种好处的同时，也伴随着各种问题。

• 核心好处是为持续交付和持续部署提供了可能性，以及由此引发的组织结构的优化和团队的能力提升。
• 带来的主要问题是分布式系统的各种复杂性，在开发、测试和部署各个环节都更加困难，需要研发团队有掌握更多的分布式系统相关的知识、技能和常用工具以克服分布式系统的复杂性。

3. 微服务架构模式语言，解决微服务架构带的新问题。这些模式包括：

• 服务拆分：解决如何把系统拆分成一组服务的问题
• 通信：解决微服务架构分布式系统下，服务之间以及与外部世界进行通信的问题。
• 数据一致性：解决每个服务都有各自的数据库后，如何确保事务的数据一致性的问题。
• 数据查询：解决每个服务都有各自数据库后，从多个服务的数据源查询聚合数据的问题。
• 服务部署：解决大量微服务的部署的问题。
• 可观测性：解决大量微服务下的故障诊断排错的问题。
• 自动化测试：解决微服务架构下端到端的自动化测试的问题。
• 安全：解决微服务架构下，用户认证和授权的问题。
  

4. 与微服务架构匹配的组织架构和开发流程

微服务架构虽然为持续交付和持续部署提供了可能性，但是如果研发团队没有在组织架构和开发流程方面做配套的改造升级，那么并不能发挥微服务的这些优势。

与之匹配的组织架构：小而自治的跨功能性团队。

团队的职责明确，可以独立完成开发、测试和部署。仅与其他团队进行项目开发必要的沟通和协调；而将很多研发的细节过程在团队内部解决。

与之匹配的流程：Scrum这类敏捷开发流程，积极实践持续交付和持续部署。

• 持续交付的关键特征是软件随时都处于可交付状态，这依赖于高度的自动化，包括自动软件打包，自动部署，自动化测试等。
• 持续部署，依赖于持续交付能力和部署环节的高度自动化，以及支持持续部署的微服务架构。

5. 软件交付和部署的四个指标：

• 部署频率：软件部署到生产环境的频率
• 交付时间：从开发人员提交变更到变更被部署的时间
• 平均恢复时间：从生产环境问题中恢复的时间
• 变更失败率：导致生产环境问题的变更提交百分比