微服务架构思想

目录

康威定律

马尔文·康威与 1967 年提出了康威定律（Conway’s Law）—— 设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。

简而言之：系统设计本质上反映了企业的组织机构，系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。

康威定律被认为是微服务架构思想的原点。James O. Coplien 与 Neil B. Harrison 在《敏捷软件开发的组织模式》中写道：“如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系，那么项目将会遇到麻烦。因此，应该确保组织结构兼容于产品架构。”

软件架构的演进

微服务架构的本质是一种软件应用的构建方式，所以我们不妨先回顾历史，看看软件架构的演变方向。

单体（Monolithic）架构

单体架构适合小型项目，开发简单直接，集中式管理，基本不会重复开发，而且功能都在本地，没有分布式的管理开销和调用开销；但它的缺点也非常明显：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断。
• 代码维护难：代码功能耦合在一起，新人不知道何从下手。
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长。
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉。
• 扩展性不够：无法满足高并发情况下的业务需求。

SOA 架构

2004 年 IBM 建立了 SOA（Service-oriented Architecture，面向服务的体系结构）全球设计中心。当时企业 IT 所面临的首要挑战就是整合企业中大量的竖桶型（silo-ed） IT 系统，支撑日益复杂的业务流程，进行高效的业务决策和支撑业务快速变化。

SOA 架构的核心思想是：将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业 IT 资产复用，提高了系统的适应性、灵活性和扩展性，解决 “信息孤岛” 问题。

SOA 提出了一系列构建分布式系统的原则，这些思考直到今天的微服务架构也依然适用：

• 服务应该具备明确定义的标准化 API。通过服务定义描述，将服务消费者（Service Consumer）和服务提供者（Service Provider）的实现进行解耦。服务间通信采用面向文档的消息而非面向特定语言 RPC 协议，一方面可以解决服务与实现语言的解耦，另一方面可以灵活选择同步或者异步的通信实现，提升系统可用性和可伸缩性；

• 服务应该是松耦合的。服务之间不应存在时间、空间、技术、团队上的依赖；

• 服务应该是无状态的。使得服务调用与会话上下文状态实现解耦；

• 服务应该是自治和自包含的。服务的实现是可以独立进行部署、版本控制、自我管理和恢复；

• 服务是可发现、可组合的。比如可以通过 Service Registry 进行服务发现，实现了服务消费者和服务提供者的动态绑定。业务流程中可以对来自不同系统的的业务服务进行编排组装。

在最初构建 SOA 系统的时候，大多采用的是点对点的通信连接，服务调用和集成逻辑被内嵌在应用实现中。这种方式在服务数量比较少的时候，确实是一种简单和高效的开发方式。但其最大的问题是，随着服务规模的增长，服务之间通信愈发复杂，连接路径和复杂性会剧增，给服务治理带来巨大的挑战。

为了解决上述问题，SOA 架构引入了 ESB（Enterprise Service Bus，企业服务总线）的概念。ESB 提供了服务之间的连接（Connection），转换（Transformantion）, 以及中介处理（Mediation）的能力。可以将企业内部和各种服务连接到 Bus 上，实现信息系统之间的松耦合架构，屏蔽了系统集成的复杂性，提高了 IT 系统架构的灵活性，降低企业内部信息共享的成本。

然而，在技术上 ESB 架构虽然实现了业务逻辑与服务集成的解耦，可以更好地进行中央化的服务治理，但也具有时代的局限性：

• 由于过度强调业务系统的可复用性，而不是对企业 IT 架构的治理和重构。大量服务集成的实现逻辑被下沉到 ESB 内部（如下图最右侧所示），这些逻辑非常难以维护，难以移植和扩展，成为 ESB 不可承受之重。我们必须在合适的地点合理地处理复杂性，而非将其简单转移；
• ESB 基于一个中心化的消息处理系统，但随着互联网的高速发展，ESB 已经无法应对企业 IT 规模化成长的挑战；
• ESB 这样的 Smart Pipes、Dumb Endpoints 的系统架构是一个无法适应快速变化和大众创新的一个架构。

微服务（Microservice）架构

随着互联网的发展，尤其是移动互联时代的到来，整个世界的经济形态发生了巨大的变化改变。企业 IT 的重点从传统的 System of Record（交易系统，如：ERP、SCM 等）演化到 System of Engagement（互动系统，如全渠道营销）。这些系统需要应对互联网规模的快速增长，并且能够快速迭代，低成本试错。

于是，以 Netflix、阿里为首的一系列互联网公司主导了企业架构新的变革 —— 微服务架构。微服务架构继承了 SOA 的架构原则，但是在实现层面，它倾向于通过构造智能端点和哑管道的去中心化分布式架构风格来替代 ESB。

微服务架构的核心思想是：强调将应用功能拆解为一组松耦合的微服务，每个服务遵守单一责任原则（Single Responsibility Principle），有着自己的处理逻辑和轻量通讯机制（REST/RPC）。而微服务框架，就是将这些微服务管理起来，对外提供的一套完整服务。

相比于传统的单体式架构和 SOA 架构，微服务架构的主要特点是：组件化、松耦合、自治、去中心化，体现在以下几个方面：

• 服务粒度要小：每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。
• 独立部署运行和扩展：每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
• 独立开发和演化：每个服务的技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。
• 分布式：每个服务之间采取语言无关的 API 进行集成。
• 独立团队和自治：团队对微服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

微服务架构解决了两个固有问题：

1. 每个服务可以独立部署和交付，大大提升了业务敏捷性；
2. 每个服务可以独立横向扩展/收缩，应对互联网规模的挑战。

简而言之，微服务架构思想就如当今社会的垂直分工体系一般：通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。相对单体架构，微服务架构是更面向业务创新的一种架构模式，让业务系统尽可能快地响应变化。

微服务架构的优势

• 微服务粒度小，聚焦一个指定的业务功能或业务需求。所以，微服务易于被一个开发人员理解，修改和维护。一个微服务通常由 2-5 人的小团队（两块披萨原则）单独开发，并且团队的新成员能够更快投入生产。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务可以使用不同的语言开发。
• 微服务可以简易的融合新技术。
• 微服务可以通过灵活的方式完成 CI/CD。
• 微服务完全由标准化 API 驱动，易于和第三方集成激发 API 经济。

微服务架构与敏捷宣言

如何让我们的系统尽可能快地去响应变化？其实几十年来我们一直在尝试解决这个问题。如果一定要在前面加个限制的话，那就是：低成本的快速响应变化。

上世纪 90 年代 Kent Beck 提出要拥抱变化，在同期出现了诸多轻量级开发方法，例如：XP、Scrum 等。2001 年敏捷宣言诞生，之后又出现了精益、看板等新的管理方式。如果说，这些是为了尽快的响应变化，在软件开发流程和实践方面提出的解决方案，那么微服务架构就是在软件技术和架构层面提出的应对之道。

微服务架构与容器

当我们将大型的单体应用拆解为多个微服务，也一定会增加 IT 系统研发协同、交付、运维的复杂性。容器与容器平台，就在于帮助微服务解决生命周期管理以及运维管理难题。

• 容器之于微服务：不同微服务之间可能存在一些异构，为了让每一个团队在微服务体系下发挥最大效能，我们允许不同团队采用不同的编程语言，甚至不同的运行环境来去运行这些微服务。因此，我们在运维和管理微服务时，最初其实并没有一套统一的标准去处理的异构环境，这也是为什么后来容器技术变得流行起来，它的一个重要作用就是通过一层标准的封装以及标准的运行时，来标准化微服务部署。这样从生命周期管理的角度来看，每一个微服务之间的差异就会变少，共同点变多。
  

• 容器平台之于微服务：容器平台，例如：Kubernetes，它的作用是帮助把已经标准化的微服务最便捷地运行到底层资源上面。我们讲到的存储、计算、网络都通过 Kubernetes 这层进行了统一抽象和封装，让已经被容器统一的微服务能够直接运行到 Kubernetes 平台。因此，运维人员不用再苦恼如何去把某个微服务分配到具体的某一个资源或计算单元上去。通过容器和容器平台，大大简化了微服务本身的生命周期管理，简化了微服务自身的运维管理问题，也促进了微服务更多地被企业所采用。
  

此外，Kubernetes 具有一个 Pod 的概念。一个 Pod 实际上是一组容器的集合，在一个 Pod 中可以运行一个或多个容器。一般来讲，当我们采用微服务架构时，会把微服务的主体运行在主容器中，主容器的生命周期跟 Pod 自身的生命周期是一个耦合的状态。

除了主容器之外，在同一个 Pod 中还会运行一些边车容器（Sidecar 容器），为主容器提供一些辅助功能，比如：日志采集、网络代理、身份鉴权等，这样微服务除了自身提供的核心业务服务以外，通过 Kubernetes 我们还可以动态添加一些额外的辅助能力，让微服务管理变得更健壮。

另一方面，Pod 还提供了一些非常有用的功能：

• 状态信息：Pod 会提供一个标准接口显示运行状态。例如，是否已经准备好接收流量，如果准备好接收流量，那么从 Ingress 流量就可以打到微服务上。如果运行状态不良，我们可以尝试对这个容器进行修理、重启或删除，甚至是换到另一个计算单元上去运行，为微服务整体的稳定性提供了保障。

• 地址服务：每一个 Pod 都有一个标准化的 DNS 地址服务，可以被统一的寻址。这样对于需要统一暴露出来 API 的日志、监控、追踪能力都有着非常大的帮助，可以根据这个 DNS 的地址来访问 Pod 所暴露的可观测性信息，便捷及时的发现运行时问题。

所以我们可以看到容器平台及容器其实在微观上也帮助了微服务具有更多能力、具有更强的健壮性以及具有更好的可观测性。

微服务架构与 DevOps

因为微服务的数量非常多，部署、管理的工作量很大。

• 开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作。
• 测试方面：服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。

而随着 CI/CD 概念推广以及容器技术普及，微服务将这两种理念和技术结合起来，形成新的：“微服务 + API + 平台” 的开发模式，提出了容器化微服务的持续交付概念。

• 传统单体架构 DevOps 开发方式，要求产品队伍横跨产品管理、开发、QA、DBA 以及系统运维管理。
  

• 微服务架构 DevOps 开发方式，将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍，以及一个大的整体的平台队伍负责运营管理，两者之间通过 API 交互，做到了松耦合隔绝。
  

在测试方面，微服务架构下的测试分为三个层次：

1. 端到端（集成）测试：覆盖整个系统，一般在用户界面进行测试。由于端到端测试实施难度较大，一般只对核心功能做端到端测试。一旦端到端测试失败，则需要将其分解到单元测试，分析失败原因，然后编写单元测试来重现这个问题，这样未来我们便可以更快地捕获同样的错误。
2. 服务（功能）测试：针对服务接口进行测试。服务测试的难度在于服务会经常依赖一些其他服务。这个问题可以通过 Mock Server 解决：
3. 单元测试：针对代码单元进行测试。我们一般会编写大量的单元测试（包括回归测试）尽量覆盖所有代码。

三种测试从上到下实施的容易程度递增，但是测试效果递减。端到端测试最费时费力，但是通过测试后我们对系统最有信心。单元测试最容易实施，效率也最高，但是测试后不能保证整个系统没有问题。

参考资料

《从 SOA 到微服务，企业分布式应用架构在云原生时代如何重塑？》
《一文详解微服务架构》