微服务应用架构与微服务架构应用的集成

微服务架构作为一种软件开发架构，这些年越来越热。那微服务应用架构的优缺点有哪些？它是否适合我呢？以及如何做微服务架构应用的集成？

这里我谈谈自己的看法。

1. 传统应用架构的挑战

目前市场上多数仍是单体架构的应用，例如典型的三层架构应用。它开发和运维相对简单，但有以下缺点：

• 模块/组件间强依赖，某个模块的问题可将整个系统击垮
• 单体架构应用很难满足快速迭代、快速交付的业务需求
• “拆除-替换”的应用升级模式，成本太高
• 无法满足大规模、细颗粒度弹性的部署需求——尤其是互联网+的场景
• 通常基于单一技术栈组合，技术栈选择上缺乏弹性

应对单体架构挑战的是面向服务架构(SOA)，它把应用拆成一系列高内聚(High cohesion)、低耦合( Low coupling)的小应用(服务)，它们可以由不同团队，使用不同的技术开发、部署在不同的软件平台上，因此具有较好的敏捷性、灵活性和弹性。

率先发展出的服务协议是Web Service，它是一个协议栈，包含了传输协议——如HTTP/HTTPS、消息协议——主流的是基于XML格式的SOAP、服务描述协议——WSDL、服务发现协议——例如UDDI。

应用拆开为服务，是把双刃剑：服务化提高了架构的灵活度和可扩展性，但需要大量的服务间通讯，而且这些服务需要额外的协同和管理。要协同管理服务，企业服务总线(ESB)技术随即发展起来。但ESB是一个中心化的、需要高性能和高可靠性的组件，它有较高的成本和较低的弹性，因此ESB并没有辅助SOA成为主流的应用架构，反而由于其服务协同能力成为应用集成技术的首选。

Web Service并没有解决单体架构的所有问题，其很重的协议，以及中心化的ESB和单体架构应用一样无法提供细颗粒度弹性。尤其是Web Service在互联网应用的时代有太多局限性。微服务架构应运而生。

2. 什么是微服务架构？

微服务架构并非这两年提出来的，它是2005年就被提出的应用架构，本质上是面向服务架构的一种，是一种分布式应用架构。相较于Web Service，它使用轻量级的服务协议（如RESTful、gRPC）、更简单高效的数据序列化结构（如JSON、Protocol Buffers），服务间协同上避免中心化的架构，更适合互联网时代面向高业务规模弹性和要求快速迭代的业务需求场景。

为什么最近会特别火？

在需求侧，各行业数字化转型要求面向客户的更快速业务创新和更具弹性的服务能力。例如被新冠疫情推动的互联网医疗需求。

在供给侧，则是因为这些年能配合微服务发挥其能力的技术成熟起来了 – DevOps、容器化部署…

这也解释了为什么最近才火起来 – 因为它解决的是特定需求、而且架构复杂！

3. 微服务架构有多复杂？

经过微服务架构改造的系统会变得更加复杂，这种复杂性体现在应用软件的全生命周期的所有环节。

交付模式

在应用交付模式上，传统的应用交付模式是4个合作的纵向团队：研发团队+测试团队+实施团队+运维团队，谁离开谁都无法交付。而微服务架构应用开发，为了微服务的功能独立和快速迭代，需要打破这种纵向的团队协同，建立一系列以业务线为单位的横向小团队——即业务主题域驱动设计(Domain-Driven Design (DDD) )。这种交付模式上，横向的小团队要完成研发、测试、实施、运维的所有工作，他们更熟悉自己一小块的业务、能无障碍反馈从而得到更快的业务能力迭代。

平台架构

要保证微服务的独立性和细颗粒弹性，对微服务的部署方式是有要求的。目前最佳的是容器化部署，容器将服务封装成一个个可以独立运行在任何容器平台上的“集装箱“ – 实现自治。如果需要某个服务更多的副本（规模），只需要启动更多的容器实例；对异常的服务，直接让其运行的容器实例停止并删除，就释放了硬件资源。

考虑到服务（容器）间的互相调用与协同，以及服务（容器）的快速迭代，仅有容器还不够，还需要Kubernetes这样的容器协同平台。

因此，业界大师Martin Fowler建议微服务要基于一个基础平台，最好是一个PaaS平台。而且要保持微服务架构应用的持续迭代，这个平台还需要是DevOps平台。

微服务协同与管理

微服务化之后，业务的功能模块和流程被拆得很破碎。如何高效地再将它们管理和协同起来，面临一系列艰巨的挑战：

• 性能：原来在一个内存空间即可完成的运算被拆开后，面临大量的服务间调用和服务间数据交换和加载，显然会降低单机性能。
• 网络延迟：大量的服务间调用也对网络造成巨大压力，造成更大的网络延迟。
• 安全：服务间频繁调用还涉及到安全问题。
• 负载均衡：既然单机性能不可避免的下降，就要通过“群狼”战术解决，这又要考虑服务实例间的负载均衡问题。
• 监控和可视化：如何监控多实例、不同网络空间和数据空间的服务健康状态和相互调用的结果和异常？在服务集群下怎么可视化地得到这些信息？
• 服务更新：既然服务快速迭代更新，如何管理服务集群的更新？如何控制潜在的服务缺陷对整个应用的影响？

因此，微服务架构要有效地用起来，需要一系列的协同与管理工具。主要包括：

• 服务发布、路由与流量控制
• 服务编排
• 服务注册与发现
• 服务配置管理
• 服务追踪
• 服务熔断/降级/分流等容错能力
• 服务负载均衡
• 服务监控

这其中大部分是保障微服务应用内部正常运作的，还有一些是微服务应用向外提供的服务抽象和服务编排。

下图列出了目前市面上对上述微服务管理能力的一些流行的开源技术产品，可以一窥其复杂程度。

领先的商业化微服务架构厂商因此提出了服务网格(Service Mesh)产品来统一提供微服务管理能力。

那服务网格是不是又回到了企业服务总线(ESB)这种中心化的老路上了？为了避免中心化，服务网格里的组件都是分布式部署的。当然这也增加了系统的复杂程度和对管理的要求。

从上面的分析，可以看出要使用微服务架构应用，需要从团队、平台、管理等众多领域做好准备，最终用户更需要为服务网格这类基础投资做好准备。

4. 我需要微服务架构吗？

微服务架构解决了很多问题，也带来了很多新问题，因此不能神化微服务架构。它不是为解决所有问题创造的，而是为解决特定问题创造的。作为最终用户，需不需要微服务架构，取决于需求及迫切程度，如果下面3项都是迫切需求，那么微服务是合适您的：

1. 需要应用具有业务规模上的超级弹性
2. 需要业务快速迭代
3. 需要部署到容器&云上

同时，需要对面临的投资和改变做好准备：

基础设施投资上：容器与容器协同平台、微服务管理平台(服务网格)都是必须投资的基础设置。而且还需要考虑采购/开发的微服务架构应用对这些基础设施的兼容性。

团队建设上：如果是自己开发微服务架构应用，需要把纵向的传统开发/交付/运维团队改造成小的、按业务域组建、包含业务专家和开发运维团队的横向团队。如果是外采的微服务架构应用，则需要考虑如何保持微服务架构应用持续迭代（DevOps）：是自己的团队接手、还是购买厂商的持续服务？否则不能持续迭代的微服务架构应用，只是有“形”，无“神”。

同样，要利用微服务架构的细颗粒度弹性来应对业务量激增，先要知道哪些微服务需要扩容及如何扩容，团队必须懂微服务和微服务管理架构！

管理上：需要形成快速反馈业务需求、快速开发迭代的闭环管理体制。

5. 如何集成微服务架构应用？

当前的企业环境中，基本面临着多架构的应用 – 为数众多的单体架构应用、少数的微服务架构应用。如何将这些不同架构的应用集成、整合到一起？

在微服务应用内部，各个微服务本身就是小型应用，互相之间需要解决集成问题。如果企业的所有应用都是微服务架构的，那么可以用服务网格来管理和协同整个企业微服务池。不过服务网格并不是为解决微服务应用与其它架构应用间的集成构建的。

要有效集成不同架构的应用，传统集成平台依然可用，但需要一些能力扩展。

在应用接入上，传统基于ESB的集成平台技术已经提供了各类适配器，因此接入微服务架构的应用 – 或者说接入微服务 – 并不是问题。但微服务架构应用并不需要向外暴露所有微服务，也不应该这么做。因此哪些微服务要暴露（发布）出来，是需要管理的。

尤其是有多个微服务架构的应用时，对其它应用来说，不应该看到一系列无意义的微服务，而是应该建立一个发布统一语义微服务的抽象层。

所以，第一个需要扩展的能力就是能发布统一语义的微服务抽象层，它通常可由API网关完成。API网关(在这里可以称之为微服务发布网关)，将后台微服务池中的特定的微服务组合并按业务抽象后，重新发布出来，并且可以控制权限、流控、容错。因此这些服务可以用在跨应用的业务流程上。

当然，微服务发布网关不应该是一个中心化的组件，而是一个可以分布式部署的独立组件。

应用集成的重点在跨应用的业务流程协同上。主流的应用集成平台是基于ESB的，本身封装的就是服务，业务流程协同其实是在编排一系列的服务。因此第二个需要扩展的能力就是服务编排能力。

可以考虑的服务编排方式主要有两种：协奏(Orchestration) 与 编舞(Choreography)。

协奏(Orchestration)是一种中心化的流程编排。可以理解为交响乐团，里面的每个乐手都是由指挥家指挥的，指挥家就是这个“中心”。集成平台中的业务流程管理(BPM)就是协奏方式，这种中心化的编排方式的好处是编排简单、流程直观，缺点是中心化、缺乏弹性。

但既然有其它架构的应用参与集成，或许弹性并不是主要矛盾。

编舞(Choreography)是一种去中心化的流程编排。可以理解为一组舞蹈演员，她们的动作并不需要有人指挥，而是基于表演角色和表演节奏自己控制的。表演节奏是一系列特定的事件，例如上一位舞者的动作完成触发下一位舞者的动作。

在编舞方式下，每个服务都需要知道自己的角色和发生的事件。这里的角色就是上面说的具有语义的服务。同时，事件驱动架构（基于发布/订阅）是必须具备的能力；而其去中心化通常要求分布式消息引擎或流式引擎。

当然它也有缺点：因为去中心化，整个的业务流程并不直观，缺乏可视化能力。

微服务架构，尤其是其管理架构部分，仍处在快速发展的战国时代。在行业中广泛应用微服务架构，除了需求的推动和管理架构的成熟，我想还是要让微服务本身具有行业适用和通用的语义。后面我还想写一篇卫生信息行业FHIR标准和微服务的感想，希望有机会和大家一起讨论。

参考阅读—

从微服务转为单体架构、成本降低 90%！是的，你没看反！

Even Amazon can't make sense of serverless or microservices