《microservices》论文笔记|微服务|整体架构|分布式与微服务的区别|SOA

《microservices》论文笔记

–Martin Fowler

---

前记：

• 原文：https://martinfowler.com/articles/microservices.html
• 汉化：https://www.cnblogs.com/liuning8023/p/4493156.html
• 微服务的概念最早由Martin Fowler与James Lewis于2014年共同提出
• 下面的内容仅仅是我个人的理解，限于水平经验等，可能有些理解不准确，欢迎批评指正。

---

基本内容

1. 定义：微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。

2. 整体架构的缺点：（你也可以使用横向扩展，通过负载均衡将多个应用部署到多台服务器上。）

   • 任何对系统的改变都涉及到重新构建和部署一个新版本的服务端应用程序
   • 扩展就需要整个应用程序的扩展，而不能进行部分扩展。

3. 模块边界：可以理解为接口，是一种强标准规范

4. 微服务风格不是什么新东西，它至少可以追溯到 Unix 的设计原则：即程序的组件库（library）。

   **思考:**在链接阶段，组件库可以是本地，还可以是从外部下载而来的（公共库）。这在一定程度上已经体现了“模块化”“服务拆分”的特点。但其还是一个整体，不是真正意义上的“服务拆分”，而是组件拆分，即模块化思想。

5. 组件与服务的区别与联系：

   • 组件：
     • 是一个可独立替换和升级的软件单元。
     • 某个组件的改变，必须重新部署整个应用
   • 服务：
     • 是进程外组件，用某个机制通信如webAPI等与应用交流
     • 服务可以独立部署
     • 不足：远程调用比进制内调用更消耗资源

6. 团队与项目：

   1. 传统拆分基本原则：设计一个系统的任何组织（广义上）都会产生这样一种设计，其结构是组织交流结构的复制。

      • 也就是说，软件开发体系的划分，其本质是根据人员的职责划分的。

        设计一个系统时，将人员划分为 UI 团队，中间件团队，DBA 团队，那么相应地，软件系统也就会自然地被划分为 UI 界面，中间件系统，数据库。

      • **思考：**从这点出发，我最早接触到的职责拆分？

      前后端分离。在早期JSP时代，后端程序员即要负责前端逻辑，又要负责后端逻辑，职责划分混乱。

      以前一直认为，前后端分离是技术上的进步而导致的现象。而现在一看，本质还是由前端职责和后端职责的不同产生的。是现象驱动了技术上的进步。

   2. 微服务架构下的拆分原则：

      • 它倾向围绕业务功能的组织来分割服务。这些服务实现商业领域的软件，包括用户界面，持久化存储，任何的外部协作

      拆分优缺点：

      • 优：好的模块边界，可以使团队边界更加清晰
      • 缺：如果模块边界做得不好，那么维护起来是非常困难的。

7. 产品与项目：

   • 理念：Amazon 理念是“你构建，你运维（you build, you run it）”。而不是像传统的整体架构那样，那么运维和开发分开来看。
   • 一个产品在微服务架构下的拆分原则指导下，自然地被拆分成许多相对独立的服务。
   • 每个服务都可以作为一个独立的项目来发展
   • 而针对每个项目，可以设计出更加独立、有针对性的工具来帮助开发、解决项目内比较通用的问题。
   • 而如果是一个整体架构下的项目，这些工具也许就不是那么地通用了，每个企业之间甚至每个版本之间都可能出现变更

8. 强化终端及弱化通道Smart endpoints and dumb pipes

   1. 传统：如企业服务总线(EnterpriseServiceBus，ESB)，在消息传递的过程中提供更有效的方式改进通信过程中的路由、编码、传输、以及业务处理规则。即通信通道的处理逻辑过于多。

   2. 微服务下原则和规范：

      • 第一种做法：基于互联网（广义上，包含Unix系统）构建系统。这样经常使用的资源几乎不用什么的代价就可以被开发者或者运行商缓存。

        引发的问题：从整体式风格到微服务框架最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用，产生的大量的不可靠通信。因此，你需要把粗粒度的方法成更加细粒度的通信。

      • 第二种做法是通过轻量级消息总线来发布消息。这种的通信协议非常的单一（单一到只负责消息路由），像RabbitMQ或者ZeroMQ这样的简单的实现甚至像可靠的异步机制都没提供，以至于需要依赖产生或者消费消息的终端或者服务来处理这类问题。

      思考：MQ不是有很多的备份、容灾等功能吗？为什么也属于“轻量级消息总线"?

      MQ本质上是与业务无关的，不提供业务相关的处理逻辑。

      而其本身提供的如消息备份、容灾等逻辑，是针对消息本身的，而不是针对对消息的处理逻辑。

      MQ的任务就是以业务需要的方式来路由、转发消息。

9. 分散治理（和上述的产品与项目问题思考差不多，同一类的。正是产品被拆分成不同项目，才有分散治理的问题）

   • 分散治理理念：亚马逊：“编译它，运维它”
   • 一个产品在微服务架构下的拆分原则指导下，自然地被拆分成许多相对独立的服务。
   • 每个服务都可以作为一个独立的项目来发展。项目中甚至可以用不同的语言
   • 而针对每个项目，可以设计出更加独立、有针对性的工具来帮助开发、解决项目内比较通用的问题。
   • 而如果是一个整体架构下的项目，这些工具也许就不是那么地通用了，每个企业之间甚至每个版本之间都可能出现变更

10. 分散数据管理

    • 由服务拆分，引发出数据拆分
    • 引发出的严重问题：数据不一致问题。而数据的一致性又是关系型数据库中特别强调的
    • 服务架构强调服务间事务的协调，并清楚的认识一致性只能是最终一致性以及通过补偿运算处理问题。

11. 基础设施自动化

    • 由于不同的服务发布时间可能不同，因此需要一个统一的管理中心来协调。
    • 这个统一的管理中心重要的一个功能就是：自动化部署

12. 容错性设计

    • 任务服务可能因为供应商的不可靠而故障，客户端需要尽可能的优化这种场景的响应。跟整体构架相比，这是一个缺点，因为它带来的额外的复杂性
    • 必须要为每个应用的服务及数据中心提供日常故障检测和恢复

13. 设计改进：

    • 从整体构架开发，做模块化开发，然后当整体构架出现问题是再把模块化拆分成服务。
    • 这种建议不是好主意，因为一个好的进程内接口并不是一个好的服务接口。

---

扩展思考

1. 区别概念:

   • 分布式：
     • 一种部署方式。
     • 不论是整体架构还是微服务架构，都可以用分布式的方式进行部署
   • 集群：
     • 在单点部署多台机器，提高容错性
   • SOA service-oriented architecture：
     • 在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务
     • 面向服务的风格是这么的拙劣：从试图使用ESB隐藏复杂性
     • 架构：APP -> ESB（服务组件） -> APP
   • 微服务：
     • 软件的架构方式
     • 可以全部在本地部署，也可以用分工式的方式进行部署

2. 微服务的四个基本问题：

   • 这么多服务，客户端该如何去访问（路由网关)
   • 这么多服务，服务之间如何进行通信（HTTP）
   • 这么多服务，如何治理（服务注册中心）
   • 服务挂了，怎么办（熔断机制）

3. 总结优缺点:

   优:

   • 单一职责
   • 开发简单，效率高，专注
   • 松偶合
   • 微服务可以使用不同的的语言开发，用轻量级的通信机制如http通信即可
   • 每个微服务有自己的存储能力，可以有自己的数据库。如Mysql和redis

   缺：

   • 要考虑分布式系统的复杂性，如数据一致性，系统部署依赖，服务通信成本
   • 运维难度大
   • 系统集成测试，性能监控

4. 微服务最大的挑战?

   从整体式风格到微服务框架最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用，产生的大量的不可靠通信