微服务架构 — Overview-CFANZ编程社区

康威定律

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

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

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

微服务架构 — Overview_微服务

软件架构的演进

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

微服务架构 — Overview_架构_02

微服务架构 — Overview_松耦合_03

单体（Monolithic）架构

微服务架构 — Overview_解耦_04

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

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

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 的系统架构是一个无法适应快速变化和大众创新的一个架构。

微服务架构 — Overview_microservices_05

微服务（Microservice）架构

微服务架构 — Overview_架构_06

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

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

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

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

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

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

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

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

微服务架构 — Overview_松耦合_07

微服务架构的优势

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

微服务架构与敏捷宣言

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

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

微服务架构 — Overview_架构_08