架构并不是被发明出来的，而是持续演进的结果。以古为镜，可以知兴替。

一、原始分布式时代

1、背景
2、历史意义
从过程来看，这个阶段的探索称得上成绩斐然
3、失败的原因
从结果来看，历史局限决定了它不可能一蹴而就地解决分布式的难题
4、历史教训

二、单体系统时代

三、SOA时代

中心化架构，ESB中即有业务逻辑也有控制逻辑ESB作为一个万能中间件可以进行服务注册发现、路由、限流、熔断、重试、监控、 认证、协议转换……

1、背景

为了对大型的单体系统进行拆分，让每一个子系统都能独立地部署、运行、更新，开发者们进行了长时间的探索。这里里列举以下三种较有代表性的架构模式：

• 烟囱式架构（Information Silo Architecture）：信息烟囱又名信息孤岛（Information Island），它指的是一种完全不与其他相关信息系统进行互操作或者协调工作的设计模式。
• 微内核架构（Microkernel Architecture）

微内核架构也被称为插件式架构（Plug-in Architecture）。

• 事件驱动架构（Event-Driven Architecture）

为了能让子系统互相通信，在子系统之间建立一套事件队列管道（Event Queues），各个子系统从管道里获取自己感兴趣的事件消息并进行处理，也可以发布一些新的事件到管道队列中去，如此，每一个消息的处理者都是独立的，高度解耦的，但又能与其他处理者通过事件管道进行互动。

2、标志

• 事件驱动架构（Event-Driven Architecture）的出现。
• SOAP 协议的诞生，标志着“面向服务的架构”（Service Oriented Architecture，SOA）已经具备登上软件架构舞台所需要的全部前置条件。

3、历史意义

面向服务的架构是第一个系统性地、具体地成功解决分布式服务主要问题的架构模式。服务之间松散耦合、注册、发现、治理、隔离、编排等这些在今天微服务中耳熟能详的名词概念或思想被提出并进行了相关实践，同时SOA 针还对“软件工程”进行了系统性的探索。

• 更具体：SOA不能简单视为一种架构风格，而是可以称为一套软件设计的基础平台了。它拥有领导制定技术标准的组织 Open CSA和清晰的软件设计指导原则，譬如服务的封装性、自治、松耦合、可重用、可组合、无状态，等等。同时提供了一整套成体系可以互相精密协作的技术组件，如明确了采用 SOAP 作为远程调用的协议，依靠 SOAP 协议族（WSDL、UDDI 和一大票 WS-*协议）来完成服务的发布、发现和治理；利用一个被称为企业服务总线（Enterprise Service Bus，ESB）的消息管道来实现各个子系统之间的通信交互，令各服务间在 ESB 调度下无须相互依赖却能相互通信，既带来了服务松耦合的好处，也为以后可以进一步实施业务流程编排（Business Process Management，BPM）提供了基础；使用服务数据对象（Service Data Object，SDO）来访问和表示数据，使用服务组件架构（Service Component Architecture，SCA）来定义服务封装的形式和服务运行的容器，等等，若仅从技术可行性这一个角度来评判的话，SOA 可以算是成功地解决了分布式环境下出现的主要技术问题。
• 更系统：SOA 理想宏大，它的终极目标是希望总结出一套自上而下的软件研发方法论，希望做到企业只需要跟着 SOA 的思路，就能够一揽子解决掉软件开发过程中的全部问题，譬如该如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发测试部署新的功能，等等。这里面技术问题确实是重点和难点，但也仅仅是其中的一个方面，SOA 不仅关注技术，还关注研发过程中涉及到的需求、管理、流程和组织。如果这个目标真的能够达成，软件开发就有可能从此迈进工业化大生产的阶段，试想如果有一天写出符合客户需求的软件会像写八股文一样有迹可循、有法可依，那对软件开发者来说也许是无趣的，但整个社会实施信息化的效率肯定会有大幅的提升。

4、失败的原因

SOA 在 21 世纪最初的十年里曾经盛行一时，有 IBM 等一众行业巨头厂商为其呐喊冲锋，吸引了不少软件开发商、尤其是企业级软件的开发商的跟随，最终却还是偃旗息鼓，沉寂了下去。
SOAP 协议被逐渐边缘化的本质原因在于过于严格的规范定义带来过度的复杂性。而构建在 SOAP 基础之上的 ESB、BPM、SCA、SDO 等诸多上层建筑，进一步加剧了这种复杂性。开发信息系统毕竟不是作八股文章，过于精密的流程和理论也需要懂得复杂概念的专业人员才能够驾驭。SOA 诞生的那一天起，就已经注定了它只能是少数系统阳春白雪式的精致奢侈品，它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广。SOA 最终没有获得成功的致命伤与当年的EJB如出一辙，尽管有 Sun Microsystems 和 IBM 等一众巨头在背后力挺，EJB 仍然败于以 Spring、Hibernate 为代表的“草根框架”，可见一旦脱离人民群众，终究会淹没在群众的海洋之中，连信息技术也不曾例外过。

5、历史教训

只有具备广泛普适性的软件架构风格才能被大众接受，才具备真正的生命力。

四、微服务时代

微服务架构，控制逻辑反过来入侵业务逻辑每个微服务都有一个SDK完成服务注册发现、路由、限流、熔断、重试、监控、认证、协议转换……

1、背景

“微服务”这个技术名词最早在 2005 年就已经被提出，它是由 Peter Rodgers 博士在 2005 年度的云计算博览会（Web Services Edge 2005）上首次使用，当时的说法是“Micro-Web-Service”，指的是一种专注于单一职责的、语言无关的、细粒度 Web 服务（Granular Web Services）。“微服务”一词并不是 Peter Rodgers 直接凭空创造出来的概念，最初的微服务可以说是 SOA 发展时催生的产物，就如同 EJB 推广过程中催生了 Spring 和 Hibernate 那样，这一阶段的微服务是作为一种 SOA 的轻量化的补救方案而被提出的。
微服务的概念提出后，在将近十年的时间里面，并没有受到太多的追捧。作为对现有 SOA 架构的修补，
并没有唤起广大技术人员的更多激情。

2、标志

• 《Microservices - Java, the Unix Way》：2012 年，在波兰克拉科夫举行的“33rd Degree Conference”大会上，Thoughtworks 首席咨询师 James Lewis 做了题为《Microservices - Java, the Unix Way》的主题演讲，其中提到了单一服务职责、康威定律、自动扩展、领域驱动设计等原则，却只字未提 SOA，反而号召应该重拾 Unix 的设计哲学（As Well Behaved Unix Services），与“初心与自省”遥相呼应。微服务已经迫不及待地要脱离 SOA 的附庸，成为一种独立的架构风格，也许，未来还将会是 SOA 的革命者。
• 《Microservices: A Definition of This New Architectural Term》： 2014 年，James Lewis 与 Martin Fowler 合著《Microservices: A Definition of This New Architectural Term》，给出了现代微服务的概念，并列举了微服务的九个核心的业务与技术特征，标志着微服务真正意思上的崛起。

  UNIX 的分布式设计哲学 Simplicity of both the interface and the implementation are more important than any other attributes of the system — including correctness, consistency, and completeness 保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。

3、定义

微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
微服务追求更加自由的架构风格，摒弃了几乎所有 SOA 里可以抛弃的约束和规定，提倡以“实践标准”代替“规范标准”。

3.1、特征

• 围绕业务能力构建（Organized around Business Capability）。这里再次强调了康威定律的重要性，有怎样结构、规模、能力的团队，就会产生出对应结构、规模、能力的产品。这个结论不是某个团队、某个公司遇到的巧合，而是必然的演化结果。
• 数据去中心化（Decentralized Data Management）。微服务明确地提倡数据应该按领域分散管理、更新、维护、存储，在单体服务中，一个系统的各个功能模块通常会使用同一个数据库，诚然中心化的存储天生就更容易避免一致性问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。
• 分散治理（Decentralized Governance）。这是要表达“谁家孩子谁来管”的意思，服务对应的开发团队有直接对服务运行质量负责的责任，也应该有着不受外界干预地掌控服务各个方面的权力，譬如选择与其他服务异构的技术来实现自己的服务。
• 通过服务来实现独立自治的组件（Componentization via Services）。尽管远程服务有更高昂的调用成本，但这是为组件带来隔离与自治能力的必要代价。
• 强终端弱管道（Smart Endpoint and Dumb Pipe）。如果服务需要上面的额外通信能力，就应该在服务自己的 Endpoint 上解决，而不是在通信管道上一揽子处理。微服务提倡类似于经典 UNIX 过滤器那样简单直接的通信方式，RESTful 风格的通信在微服务中会是更加合适的选择。弱管道（Dumb Pipe）几乎算是直接指名道姓地反对 SOAP 和 ESB 的那一堆复杂的通信机制。ESB 可以处理消息的编码加工、业务规则转换等；BPM 可以集中编排企业业务服务；SOAP 有几十个 WS-*协议族在处理事务、一致性、认证授权等一系列工作，这些构筑在通信管道上的功能也许对某个系统中的某一部分服务是有必要的，但对于另外更多的服务则是强加进来的负担。
• 容错性设计（Design for Failure）。不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实，要求在微服务的设计中，有自动的机制对其依赖的服务能够进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。所以“断路器”这类设施，对实际生产环境的微服务来说并不是可选的外围组件，而是一个必须的支撑点，如果没有容错性的设计，系统很容易就会被因为一两个服务的崩溃所带来的雪崩效应淹没。可靠系统完全可能由会出错的服务组成，这是微服务最大的价值所在。
• 基础设施自动化（Infrastructure Automation）。由于微服务下运维的对象比起单体架构要有数量级的增长，使用微服务的团队更加依赖于基础设施的自动化，人工是很难支撑成百上千乃至成千上万级别的服务的。基础设施自动化，如 CI/CD 的长足发展，显著减少了构建、发布、运维工作的复杂性。
• 演进式设计（Evolutionary Design）。承认服务是有生命的，一个设计再良好的服务最终也会报废淘汰，无法永生。服务可以通过组合、拆分、升级、替换等方式进行进化，从而延续生命。
• 产品化思维（Products not Projects）。避免把软件研发视作要去完成某种功能，而是视作一种持续改进、提升的过程。譬如，不应该把运维只看作运维团队的事，把开发只看作开发团队的事，团队应该为软件产品的整个生命周期负责，开发者不仅应该知道软件如何开发，还应该知道它如何运作，用户如何反馈，乃至售后支持工作是怎样进行的。

3.2、架构模式语言

微服务架构模式语言，即一系列微服务架构模式集合，其主要有两个目标：

• 用于决策应用系统是否需要采用微服务架构
• 采用微服务架构的话，具体如何设计

Application architecture patterns

• Monolithic architecture
• Microservice architecture

Decomposition

• Decompose by business capability
• Decompose by subdomain
• Self-contained Service
• Service per team

Refactoring to microservices

• Strangler Application
• Anti-corruption layer

Data management

• Database per Service
• Shared database
• Saga
• API Composition
• CQRS
• Domain event
• Event sourcing

Transactional messaging

• Transactional outbox
• Transaction log tailing
• Polling publisher

Testing

• Service Component Test
• Consumer-driven contract test
• Consumer-side contract test

Deployment patterns

• Multiple service instances per host
• Service instance per host
• Service instance per VM
• Service instance per Container
• Serverless deployment
• Service deployment platform

Cross cutting concerns

• Microservice chassis
• Service Template
• Externalized configuration

Communication style

• Remote Procedure Invocation
• Messaging
• Domain-specific protocol
• Idempotent Consumer

External API

• API gateway
• Backend for front-end

Service discovery

• Client-side discovery
• Server-side discovery
• Service registry
• Self registration
• 3rd party registration

Reliability

• Circuit Breaker

Security

• Access Token

Observability

• Log aggregation
• Application metrics
• Audit logging
• Distributed tracing
• Exception tracking
• Health check API
• Log deployments and changes

UI patterns

• Server-side page fragment composition
• Client-side UI composition

4、历史意义

微服务作为一种丰满、独立且普适的架构风格，赢得了广大的群众基础，开启了崭新的分布式时代篇章。微服务不再是 SOA 的变体或衍生品，撕掉了 SOA 的标签，明确地与 SOA 划清了界线，几年时光微服务便如明星一般崛起闪耀于技术舞台。
微服务促进了软件工程的蓬勃发展，伴随着微服务的发展，DevOps、智能运维、链路追踪、混沌工程等工程实践也迎来了春天。

Microservices and SOA This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA , perhaps service orientation done right. Either way, the fact that SOA means such different things means it’s valuable to have a term that more crisply defines this architectural style 由于与 SOA 具有一致的表现形式，这让微服务的支持者更加迫切地拒绝再被打上 SOA 的标签，尽管有一些人坚持认为微服务就是 SOA 的一种变体形式，也许从面向服务方面这个方面来说是对的，但无论如何，SOA 与微服务都是两种不同的东西，正因如此，使用一个别的名称来简明地定义这种架构风格就显得更有必要。

五、后微服务时代

服务网格架构，控制逻辑与业务逻辑分离每个微服务都有一个边车，并由Kubernetes 进行管理和调度，完成服务注册发现、路由、限流、熔断、重试、监控、认证、协议转换……企业服务化架构的演进。

1、背景

分布式服务架构中的核心问题，如注册发现、跟踪治理、负载均衡、传输通信等，从原始分布式时代到微服务时代在软件层面进行了长久的探索，这些问题大多有了专职化的基础设施去解决，而之所以人们选择在软件的代码层面去解决这些分布式问题，很大程度上是因为由硬件构成的基础设施，跟不上由软件构成的应用服务的灵活性的无奈之举。
软件定义网络（Software-Defined Networking，SDN）、软件定义存储（Software-Defined Storage，SDS）、容器运行时（Container runtimes）等基础设施虚拟化技术，弥补了由硬件构成的基础设施与由软件构成的应用服务之间的差速比。同时以Kubernetes为代表的容器编排技术，正式开启了虚拟化基础设施去解决分布式架构问题的篇章，一个新的时代到来——云原生。

如果不局限于采用软件的方式，分布式问题都有对应的硬件解决方案。譬如，某个系统需要伸缩扩容，通常会购买新的服务器，部署若干副本实例来分担压力；如果某个系统需要解决负载均衡问题，通常会布置负载均衡器，选择恰当的均衡算法来分流；如果需要解决传输安全问题，通常会布置 TLS 传输链路，配置好 CA 证书以保证通信不被窃听篡改；如果需要解决服务发现问题，通常会设置 DNS 服务器，让服务访问依赖稳定的记录名而不是易变的 IP 地址，等等。经过计算机科学多年的发展，软件可以只使用键盘命令就能拆分出不同的服务，只通过拷贝、启动就能够伸缩扩容服务，硬件难道就不可以通过敲键盘就变出相应的应用服务器、负载均衡器、DNS 服务器、网络链路这些设施吗？

2、标志

• Kubernetes 成为容器编排的事实标准：2017 年是容器生态发展历史中具有里程碑意义的一年。在这一年，长期作为 Docker 竞争对手的RKT 容器一派的领导者 CoreOS 宣布放弃自己的容器管理系统 Fleet，未来将会把所有容器管理的功能移至 Kubernetes 之上去实现。在这一年，容器管理领域的独角兽 Rancher Labs 宣布放弃其内置了数年的容器管理系统 Cattle，提出了“All-in-Kubernetes”战略，把 1.x 版本时就能够支持多种容器编排系统的管理工具 Rancher，从 2.0 版本开始“反向升级”为完全绑定于 Kubernetes 这单一种系统。在这一年，Kubernetes 的主要竞争者 Apache Mesos 在 9 月正式宣布了“Kubernetes on Mesos”集成计划，由竞争关系转为对 Kubernetes 提供支持，使其能够与 Mesos 的其他一级框架（如HDFS、Spark 和Chronos等）进行集群资源动态共享、分配与隔离。在这一年，Kubernetes 的最大竞争者 Docker Swarm 的母公司 Docker，终于在 10 月被迫宣布 Docker 要同时支持 Swarm 与 Kubernetes 两套容器管理系统，也即在事实上承认了 Kubernetes 的统治地位。这场已经持续了三、四年时间，以 Docker Swarm、Apache Mesos 与 Kubernetes 为主要竞争者的“容器编排战争”终于有了明确的结果，Kubernetes 登基加冕是容器发展中一个时代的终章，也将是软件架构发展下一个纪元的开端。

3、定义

从软件层面独力应对分布式架构所带来的各种问题，发展到应用代码与基础设施软、硬一体，合力应对架构问题的时代，现在常被媒体冠以“云原生”这个颇为抽象的名字加以宣传。云原生时代与此前微服务时代中追求的目标并没有本质改变，在服务架构演进的历史进程中，可称其为“后微服务时代”。

3.1、特征

• Service Mesh 演进模式

• Service Mesh 架构模式

• Service Mesh 技术标准

4、历史意义

上帝的归上帝，凯撒的归凯撒，业务与技术完全分离，远程与本地完全透明，也许这就是最好的时代了吧！

• 软、硬一体，合力应对分布式架构问题：当虚拟化的基础设施从单个服务的容器扩展至由多个容器构成的服务集群、通信网络和存储设施时，软件与硬件的界限便已经模糊。
• 分布式能力下层到基础设施：一旦虚拟化的硬件能够跟上软件的灵活性，那些与业务无关的技术性问题便有可能从软件层面剥离，悄无声息地解决于硬件基础设施之内，让软件得以只专注业务，真正“围绕业务能力构建”团队与产品。如此，DCE 中未能实现的“透明的分布式应用”成为可能，Martin Flower 设想的“凤凰服务器“成为可能，Chad Fowler 提出的“不可变基础设施”也成为可能，

六、无服务时代

1、背景

2、标准

3、定义

4、历史意义

七、总结