微服务演进

What is Microservices

A microservice architecture – a variant of the service-oriented architecture structural style – is an architectural
pattern that arranges an application as a collection of loosely-coupled, fine-grained services, communicating through
lightweight protocols.

—— Wikipedia，Microservices

微服务架构——面向服务架构（SOA）结构风格的一种变体——是一种架构模式，它将应用程序安排为松耦合、细粒度服务的集合，通过轻量级协议进行通信。

从维基百科的的描述中，看出微服务与SOA有密切的关系，虽然现在主流的一些说法会说两者有比较明确的立场边界，
但是从SOA开始理解微服务演进也是有意义的。

SOA

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services
instead of a monolithic design.

—— Wikipedia，Microservices

面向服务的架构( SOA )，是一种专注于 discrete 服务而不是整体设计的架构风格。discrete service 可以理解为局部的，模块的服务，
从传统的单体架构系统中逐步的研究其中的模块。比如系统拆分出订单服务，产品服务，库存服务。那订单侧会更关注订单创建，sku售卖相关，产品服务关注产品目录结构，管理产品上下架，
库存服务则关注库存进货录入，库存数据。同时订单也会结合产品服务，库存服务进行业务逻辑处理。

SOA原则

标准化服务合同 服务遵循标准通信协议，由一组给定服务中的一个或多个服务描述文档共同定义。
服务引用自治（松散耦合的一个方面）服务之间的关系被最小化到他们只知道它们存在的水平，而不知道怎么实现的，底层又是什么，都是不知道的，只知道有这个东西。
服务地点透明度（疏松耦合的一个方面）无论网络位于何处，都可以从网络中的任何位置调用服务。
服务长寿 服务应该设计为长期存在的。在可能的情况下，如果您不需要新功能，服务应该避免强迫消费者进行更改。如果您今天调用服务，您明天应该能够调用相同的服务。
服务抽象 服务类似黑盒一样，他们的内在逻辑对消费者是隐藏的。
服务自治 服务是独立的，从设计期和运行期的角度控制它们封装的功能。
服务无状态 服务本身是无状态的，即返回请求的值或抛出异常，从而最大限度地减少资源使用。
服务粒度 确保服务具有足够规模和范围的原则。服务向用户提供的功能必须是相关的。
服务规范化 服务被分解或合并（标准化）以最小化冗余。在某些情况下，这可能无法完成，这些是需要性能优化，访问和聚合的情况。
服务可组合性 服务可用于组成其他服务。
服务发现 服务补充了交流元数据，通过它可以有效地发现和解析它们。
服务可重用性 逻辑分为各种服务，以促进代码的重用。
服务封装 许多最初未在 SOA 下计划的服务可能会被封装或成为 SOA 的一部分。

通过基础的原则，让复杂软件架构，推向更具体，更系统的方向。从广义的面向服务架构来讲，基本是没有什么太多的问题的，但是在SOA实践层面，明确了采用
SOAP 作为远程调用的协议，
依靠 SOAP 协议族（WSDL、UDDI 和一大票 WS-*协议）来完成服务的发布、发现和治理，过于严格的规范定义带来过度的复杂性，使开发者在使用起来需要具备非常复杂的概念，逐渐被开发者抛弃。

微服务

“微服务”这个技术名词最早在 2005 年就已经被提出，它是由 Peter Rodgers 博士在 2005 年度的云计算博览会（Web Services Edge
2005）上首次使用，
当时的说法是“Micro-Web-Service”，指的是一种专注于单一职责的、语言无关的、细粒度 Web 服务（Granular Web Services）。
这一阶段的微服务是作为一种 SOA 的轻量化的补救方案而被提出的，所以维基百科上说微服务是面向服务架构（SOA）结构风格的一种变体，也不无道理。

微服务真正崛起是在 2014 年，Martin Fowler 与 James Lewis 合写的文章《Microservices: A Definition of This New Architectural Term》
中首次了解到微服务的，在此文中，首先给出了现代微服务的概念：“微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。
各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。”
此外，文中列举了微服务的九个核心的业务与技术特征:

围绕业务能力构建 (Organized around Business Capability）

明确了微服务的拆分是围绕业务能力，当拆分一个大型系统时，管理层容易想到的就是按照技术能力去划分，比如UI，服务端，数据库方向拆分，
但是这种拆分模式，是不利于业务模块独立发展的，一个功能相同的功能，可能分布在不同的产品团队中，各个团队很难对一个概念达成共识，需要频繁地跨团队沟通。
或者就是每个团队自己独立维护，造成企业资源浪费。而按照业务能力去划分，此类服务针对该业务领域采用广泛的软件实现，包括用户界面、持久存储和任何外部协作。
因此，团队是跨职能的，包括开发所需的全部技能：用户体验、数据库和项目管理。

产品化思维（Products not Projects）

软件交付后就认为完成，这个是微服务不推荐的态度，微服务团队应该有产品化思维，需要对微服的整体生命周期负责，就像对待一个产品一样，需要具备用户思维，
与用户更多的沟通，思考该服务如何为用户提供更好的业务能力。

强终端弱管道（Smart Endpoint and Dumb Pipe）

在不同进程之间构建通信结构时，我们看到许多产品和方法都强调将重要的智慧融入通信机制本身。这方面的一个很好的例子是企业服务总线 (
ESB)，其中 ESB 产品通常包括用于消息路由、编排、转换和应用业务规则的复杂设施。
而微服务理念表明，业务的逻辑规则应该由服务自身去实现，而不应该将逻辑交给大而全的总线。管道只需要满足基础的数据交互逻辑，类似rabbitmq之类，只负责数据传递给对应的服务，
该服务去完成对应的业务逻辑。

分散治理（Decentralized Governance）

不同的服务可以根据自己的特性，团队有权利掌握该服务的各方面权利，比如选择一个更适合的编程语言去开发，微服务和SOA在理念上并不会限制该服务的具体实现，
当然通常情况会尽量选择比较统一的技术栈，方便团队的统一管理和组织层面的调整。另外权利和责任是相互绑定的，负责该服务的团队，也需要准备好凌晨3点去处理线上问题。

数据去中心化（Decentralized Data Management）

在一个大型系统的数据持久化层面，通常是同一个数据库实例，同一种持久化技术。在微服务理念中，与上面的分散治理一样，微服务的数据管理也是分散的，
团队也可以根据业务特性选择不同的持久化技术，微服务管理自己的数据维护和查询，其他服务不应该绕过服务访问到对应的数据。
同时也提到DDD理念，通过数据自治，服务对于数据模型的设计可以更加地聚焦，例如订单层面的产品和供应链层面的产品虽然可能会描述同一个物体，但是在不同的业务领域，他们关注的数据模型是不一致的。
这里引出的一个问题，在细粒度的微服务架构下，一个复杂的业务逻辑，可能需要不同的服务参与，服务之间由于数据方案都不一致，很难从持久化技术层面保证事务性。
众所周知，分布式事务难以实现，因此微服务架构强调服务之间的无事务协调，并明确认识到一致性可能只是最终一致性，问题通过补偿操作来处理。

通过服务来实现独立自治的组件（Componentization via Services）

通过服务来实现独立自治的组件表明了与使用类库的形式引入客户端不同，服务处于进程外，可以独立进行升级迭代，而不需要客户端重新去加载编译，
客户端通常只拥有对该服务的远程调用sdk，这部分应该是稳定的且又客户端选择的。这里引出的一个问题，服务自治，也需要考虑向下兼容的问题，不能对在使用的约定合同有影响。

基础设施自动化（Infrastructure Automation）

随着服务的拆分，数量逐渐上升，再结合敏捷、MVP的思想，服务的发布频率也逐渐上升。能够将集成发布流程自动化是至关重要的，当然这里要警惕自动化流程仅限于构建和部署，更为关键的是自动化测试。
没有经过严格自动化测试的服务，发布效率再高，也会被用户吐槽的一无是处。不过自动化测试通常也是最复杂的部分，需要开发者投入大量的时间编写测试用例，也要求开发者的代码是方便测试的。

容错性设计（Design for Failure）

虽然服务划分之后，对应的团队需要保证该服务的稳定性，但是在复杂的运行环境下，还是要保持服务是可能出现问题的。比如流量突增、网络波动等。这个特性会引出很多需要治理的方向，比如增加动态伸缩、熔断降级，
增加服务监控、服务日志等

演进式设计（Evolutionary Design）

系统的演进有两种方向，一种是对业务功能新增和下线，一种是对已有业务功能的重新设计。演进式设计需要尽量早期就识别出架构风险，这里说的不是设计一个非常完美的架构，而是在设计层面上，是方便迭代升级的。
服务组件化后的关键属性是可替换可升级，能够方便的迭代该服务，而不会影响协作者。这里其实也是一个抽象的思想，服务组件应该是抽象化的，并且边界清晰的，互相协作依赖业务抽象。当然也有其他方式可以方便系统演进，比如引进版本化，
但是版本化往往是最后的手段，版本化会给整个服务架构带来更多的治理问题。

微服务的整个架构设计方向就是，功能层面系统按照抽象边界拆分成多个组件服务，服务自治，技术层面就是需要关注组件拆分后如何更好地治理。经常与微服务一起被提起的设计是领域驱动设计，领域驱动设计讲的是如何划分业务边界，
并且在讨论该领域边界内的问题时，从用户、产品、研发各方都能够保持统一的理解，使用领域驱动设计去划分微服务是比较常用的方式。

对于微服务大家也要想明白一点，为什么这么多大公司会推崇微服务架构，毕竟商业层面都是无利不起早的。

这里其实思考一下原先的单体系统，比如一个公司同时有财务系统，供应链系统，电商系统，每个系统都需要用户管理，权限管理，甚至不同系统之间还需要一定的数据交互。
比如财务系统会需要关注供应链平台的财务支出情况，需要关注电商系统的收入情况，电商系统会需要供应链侧的产品库存信息等。如果完全独立团队开发，相互之间协调的部分就会尤为复杂。企业引进微服务后，就变成了各种服务组件化的问题，
供应链侧的产品库存服务独立成标准组件，电商系统也可以通过产品库存服务拿到需要的信息，明确服务职责，也不需要重复开发设计。甚至后面比如公司再上一个批发系统，能够很好地利用现有的组件快速上线。这种思路在国内也被称为中台化思想。

微服务架构实战

前面讲了微服务的设计理念，从2014年正式提出来之后，基本没有太多的变化。接下来我们看看从技术层面，如何落地微服务架构

API Gateway

服务拆分后，虽然每个服务都具有独立的边界，但是通常每个服务都需要配备适当的治理策略，如访问日志，限流，超时控制，负载均衡，熔断降级等。同时还需要一定的业务控制，如身份认证和权限控制。
如果这些仍然需要各个服务自行管理，那么服务需要处理的不仅仅是业务问题。
尽管API Gateway在微服务出现之前就已经存在，但是结合微服务架构后，它的作用和意义变得更加明显。在微服务架构的实践中，API Gateway几乎是必不可少的。

Service Mesh

在API Gateway 的实践方案中，架构解决了客户端到服务端的问题，但使用API Gateway 并不能很好地处理服务间调用的问题，在Service Mesh 理念没有提出来之前，基本上两种方案解决服务间治理。

服务间的调用，也通过网关转发至远程服务
二是部署多个API Gateway，区分内部网关和外部网关之类。

前者一个很显然的问题就是，会造成单点问题比较严重，网关容易成为整个系统的瓶颈，即使网关可以水平扩展。后者其实和Service Mesh理念比较接近了，但是同样还有一定的单点风险。

而Service Mesh概念中，将服务间调用的问题绑定在单个服务副本上，每个服务副本进行远程调用的时候，都会经过一个称为Sidecar的程序，这个程序与服务副本伴生，提供重试/超时、监控、追踪和服务发现等能力。
Service Mesh分为数据平面和控制平面，Sidecar处理的部分就是数据平面，控制平面是类似一个控制中心，统一管理Sidecar相关的配置并下发给Sidecar，同时收集Sidecar上报的注册、监控、日志等信息。

Istio 是比较流行的Service Mesh 实践方案，使用网络代理的方式实现Sidecar，无侵入式实现服务间治理。

Dapr

Service Mesh 是在2015年提出来的，现代微服务架构基本是按照Service Mesh理念落地的。然而Service Mesh 目前只解决了服务间的调用问题，特别是Istio这种通过网络代理的形式实现的Sidecar，
很难解决服务与中间件调用的问题。比如Mysql、Redis、MQ通常是比较常用的中间件，Istio想要接入就需要分析各种复杂的私有协议，大大的增加了Sidecar的复杂度。2020年Dapr理念由微软提出，一下子就
将服务间治理推向更抽象的方向。

Dapr（分布式应用程序运行时）在传统Sidecar理念上，增加了组件的概念，包括常见用的状态存储、服务发现、中间件、Pub/Sub 代理等，其实就是将常用的一些基础组件抽象，例如状态存储组件，
就代表了具备数据存储的一系列中间价，如Mysql、MongoDB、Redis。开发者通过组件绑定的API，像访问远程服务一样去访问存储，而Sidecar程序则会在其中提供关键的能力。

虽然Dapr官方认为，Dapr并不是Service Mesh的下一代架构，他们有自己的职责范围(Dapr与Service Mesh ))，
因为微软的Dapr是以一个实践产品提出的，即提供了成熟的开箱即用的解决方案，但其组件抽象设计理念，笔者认为是可以作为下一代微服务架构的方向的。

Ending

通过以上的几个阶段演进，微服务架构的实践方案，基本已经包含了方方面面，当然架构是随着问题解决的方向不断演进的，永远没有最完美的架构。架构师能做的只是在当前技术背景和环境背景下，选择一个更合适的方案。