从SOA到微服务，云原生时代企业分布式应用架构如何重塑？

大家好，今天来为大家分享从SOA到微服务，云原生时代企业分布式应用架构如何重塑？的一些知识点，和的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！

阿里巴巴介绍：从十多年前各种分布式系统的研发到现在的容器云，从支撑原有业务到孵化新业务，企业的发展离不开统一的、与时俱进的技术架构。本文从企业分布式应用架构的角度介绍了云原生计算架构带来的变化，希望能够帮助更多的企业进行IT转型，利用云计算技术推动其成为市场竞争中的敏捷力量。

进入21世纪以来，我们见证了企业分布式应用架构从SOA（面向服务的架构），到微服务架构，再到云原生应用架构的演变。

为了解释企业架构演进背后的思考，我们先讲一些玄学。

首先，企业IT系统的复杂性（熵）符合热力学第二定律。随着时间的推移和业务的变化，企业IT系统的复杂度会越来越高；其次，计算机交互设计中有一个众所周知的复杂性守恒定律[1]。应用程序交互的复杂性不会消失，只会以不同的方式存在。这个原则也适用于软件架构。引入新的软件架构并不会降低IT系统的整体复杂性。

听到这里，是不是让不断为生活奋斗的我们感到一丝清凉呢？

现代软件架构的核心任务之一是定义基础设施和应用程序之间的边界，合理分割复杂性，降低应用程序开发人员需要面对的复杂性。换句话说，它让开发者能够专注于核心价值创新，而把一些问题留给更合适的人和系统去解决。

我们先从下图开始，探究一下企业分布式应用架构演进背后的逻辑。

这张图来自Bilgin Ibryam的推特[2]

转型之痛：SOA

2004年，IBM成立了SOA全球设计中心。作为研发TL和架构师，我参与了一系列面向全球客户的试点项目，帮助Pepboys、Office Depot等国际公司利用SOA优化企业内部和企业间的业务流程，提高业务敏捷性。性别。

当时的大背景是：随着经济全球化逐渐深入，企业面临的竞争加剧，商业变革开始加速。大型企业的IT系统经过数十年的发展，整个技术体系变得极其复杂，主机系统上有CISC/COBOL交易应用，小型机AS400上有RPG业务系统，X86/C/JEE/.Net应用等并存。用于电力和其他分布式系统。

大量的应用系统是由第三方供应商提供的，有的系统甚至无人维护。而且，随着业务迭代，一些新的业务系统不断构建。由于缺乏合理的方法论指导，系统之间缺乏有机联系，形成众多孤岛，不断增加IT架构的复杂性，无法支撑业务。发展要求。就好像各门高手，为了帮助受伤的令狐冲，将异能注入体内，虽然伤势可以在短时间内缓解。但多股气不能融合，互相搅动，时间长了就会造成更多的伤害。

因此，企业IT面临的首要挑战是整合企业内大量孤立的IT系统，以支持日益复杂的业务流程，做出高效的业务决策，并支持快速的业务变更。

在此背景下，IBM等公司提出了SOA（面向服务的架构）的概念，将应用系统抽象为粗粒度的服务，构建松耦合的服务架构。可以通过业务流程灵活组合服务，增强企业IT资产的复用性，提高系统的适应性、灵活性和可扩展性，解决“信息孤岛”问题。

SOA提出了一系列构建分布式系统的原则，这些思想至今仍然适用：

服务具有定义明确且标准化的接口。通过服务定义描述，将服务消费者（Service Consumer）和服务提供者（Service Provider）的实现解耦，并且应该以契约优先而非代码优先的方式开发服务。服务之间的通信使用面向文档的消息而不是特定于语言的RPC 协议。一方面可以解决服务与实现语言的解耦。另一方面，可以灵活选择同步或异步通信实现方式，提高系统可用性和可扩展性；服务应该是松耦合的，服务之间不应该存在时间、空间、技术、团队上的依赖；服务应该是无状态的，将服务调用与会话上下文状态解耦；该服务应该是自主且独立的。实现可独立部署、版本控制、自我管理和恢复；该服务是可发现和可组合的。例如，可以通过服务注册中心来执行服务发现，从而实现服务消费者和服务提供者的动态绑定。在业务流程中，来自不同系统的业务服务可以被编排和组装。

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

为了解决上述挑战，企业服务总线（ESB）开始被引入。企业服务总线提供服务之间的连接、转换和中介能力。它可以将企业和各种服务连接到服务总线上，实现信息系统之间的松耦合架构，屏蔽系统集成的复杂性，提高IT系统架构的灵活性，降低企业内部信息共享的成本。

SOA方法论的目标就像《易筋经》一样，能够帮助人们理清、汇聚诸气，融汇为我所用。然而，培育的过程却绝非易事。大量雄心勃勃的SOA项目没有达到预期效果的原因是什么？

任何IT架构的成功都离不开与业务目标、技术基础和组织能力的配合。

从业务上来说，SOA当时的重点是解决企业IT现有的市场问题。这在很大程度上将SOA方法论缩小为企业应用集成（EAI Enterprise Application Integration）。

在SOA理念中，打通信息系统之间的经脉只是第一步。还需要苦练内功，不断重构、迭代企业IT架构。只有这样，企业IT架构才能保持敏捷、灵活，持续支持业务的发展和变化。

从组织架构上看，由于当时大多数企业的IT部门仍然是成本中心和业务的附属支撑部门，大多数企业缺乏长期的IT战略规划，IT团队也缺乏成长的认知。 SOA 被简化为基于项目的操作。没有组织保障和持续投入。

即使当时很成功的项目也会随着时间的推移在复杂性的侵蚀下逐渐失去活力。去年，一位住在美国的朋友给我发了一张照片。我们15年前为客户建立的业务系统仍然支撑着其现有的全国门店的业务。这是技术项目的成功，却反映出企业技术战略的缺失。

从技术上来说，ESB架构虽然实现了业务逻辑和服务集成的解耦，可以更好地实现中心化的服务治理，但也暴露了一些严重的问题：

由于过于强调业务系统的复用性而不是企业IT架构的治理和重构。大量的服务集成实现逻辑已经下沉到ESB中（如上图最右侧所示）。这些逻辑非常难以维护、移植和扩展，已经成为ESB难以承受的负担。我们必须在正确的地方合理地处理复杂性，而不是简单地转移它； ESB基于集中式消息处理系统，但随着互联网的快速发展，ESB已经无法应对企业IT规模增长的挑战； ESB这样的智能管道和哑端点的系统架构是一种无法适应快速变化和大规模创新的架构。

以此类推，电信运营商曾经希望将视频通信、电话会议等复杂功能融入到电信基础设施中，只需要一个Dummy电话终端就可以享受丰富的通信服务。然而，随着智能手机的普及，微信、钉钉等分布式协作工具的创新彻底颠覆了人们的沟通方式，电信网络又回到了管道的命运。

羽化之美：微服务

随着互联网的发展，特别是移动互联网时代的到来，整个世界的经济结构发生了巨大的变化。企业IT的重点已经从传统的记录系统（事务系统，如ERP、SCM等）发展到参与系统（互动系统，如全渠道营销）。

这些系统需要能够应对互联网规模的快速增长，并且能够以低成本进行快速迭代和试错。企业IT已成为创新驱动的引擎之一。技术拓展业务边界的理想也让IT团队有了更大的使命感，进一步加速企业IT的演进。

以Netflix、阿里巴巴为首的一系列互联网公司引领了企业架构的新变革——微服务架构。 Apache Dubbo、Spring Cloud等微服务框架已得到广泛应用。

微服务的核心思想是对应用功能进行拆分和解耦，以降低业务系统实现的复杂度。微服务强调将应用程序功能分解为一组松散耦合的服务，并且每个服务都遵循单一职责原则。微服务架构解决了传统单体架构的几个固有问题：每个服务可以独立部署和交付，大大提高业务敏捷性；每个服务可以独立地水平扩展/收缩，以应对互联网规模的挑战。

原图来自Martin Fowler对微服务架构的定义[3]

当然，将大型单体应用拆解为多个微服务，势必会增加IT系统研发协作、交付、运维的复杂度。这时，微服务架构、DevOps和容器自然地走到了一起，形成了云原生应用架构的雏形。

微服务架构继承了SOA的架构原则，但在实现层面，它倾向于通过构建智能端点和哑管道的去中心化分布式架构风格来取代ESB。

微服务架构首先要面对分布式架构固有的复杂性。请参考分布式计算的误区[4]。微服务框架需要能够解决服务通信和服务治理的复杂性，比如服务发现、熔断、限流、全链路跟踪等挑战。

HSF/Dubbo 或Spring Cloud 等微服务框架以代码库的形式封装了这些能力。这些代码库内置于应用程序本身中，并与应用程序一起发布和维护。

服务通信和治理本质上是水平系统级关注点，并且与业务逻辑正交。但在微服务架构中，其实现和生命周期是与业务逻辑耦合的。

微服务框架的升级将导致整个服务应用的重构和部署。此外，由于代码库通常与特定语言绑定，因此很难支持企业应用程序的多语言（多语言）实现。

进化之光：云原生

SOA采用集中式服务总线架构，解耦业务逻辑和服务治理逻辑；微服务架构回归到去中心化的点对点调用方式，以牺牲业务逻辑和服务为代价来提高敏捷性和可扩展性。治理逻辑解耦带来的灵活性。

为了解决上述挑战，社区提出了Service Mesh（服务网格）架构。它将服务治理功能重新下载到基础设施，并将它们作为独立的进程部署在服务的消费者和提供者端。

这样既达到了去中心化的目的，保证了系统的可扩展性，又实现了服务治理与业务逻辑的解耦。两者可以独立演进，互不干扰，提高整体架构演进的灵活性。同时，服务网格架构减少了对业务逻辑的侵入，降低了多语言支持的复杂度。

由Google、IBM、Lyft主导的Istio项目是服务网格架构的典型实现，也成为新现象级“网红”项目。

上图是Istio的架构，逻辑上分为数据平面和控制平面：

数据平面由一组以sidecar模式部署的智能代理组成，负责拦截应用网络流量、收集遥测数据和执行服务治理策略；在控制平面中，Galley负责配置管理，Pilot负责下发配置，Mixer负责策略检查和遥测数据聚合，Citadel负责通信中的安全证书管理。

Istio提供了一系列高层服务治理能力，例如：服务发现与负载均衡、渐进式交付（灰度发布）、混沌注入与分析、全链路追踪、零信任网络安全等，可以用于上层业务系统编排到您的IT基础设施和发布系统中。

然而，Service Mesh 并不是灵丹妙药。它的架构选择是增加部署复杂性（sidecar）并损失性能（增加两跳）来换取架构灵活性和系统可进化性。

为了解决部署复杂性的挑战，社区和云服务提供商正在共同努力：

一方面简化了自动化服务网格运维的水平（例如阿里云通过算子大大简化了Istio升级运维和跨K8s集群部署的复杂度）；另一方面，它提供托管服务网格服务，帮助用户专注于业务层面的服务治理而不是基础设施实现。

关于性能问题：

一方面，Service Mesh需要降低自身控制平面和服务平面的性能开销，比如尽可能卸载mixer负载，将治理策略执行移至数据平面；另一方面，也需要重新思考整个通信堆栈中的应用程序和网络基础设施。边界。

为了实现容器应用之间的互联，Kubernetes社区提出了CNI网络模型，将容器网络连接与底层网络实现解耦。同时，K8s提供了Service、Ingress、Network策略等基础原语来支持应用层。服务通信和访问控制。但这些能力还远远不能满足应用程序对服务治理的需求。

服务网格增加了流量管理、全链路可观测、L4/L7安全互联等新功能。这些是通过引入在用户空间运行的Envoy 代理来实现的。在提高灵活性的同时，也不可避免地增加了性能开销。

为了系统地解决这个问题，社区正在进行有趣的探索。例如，在Cillium容器网络中，可以利用操作系统和eBPF/XDP等底层网络能力，将应用层的服务控制能力（如Kube-Proxy提供的服务和网络策略）下沉到操作系统内核层和网络层。 Service Mesh数据链路经过优化，减少上下文切换和数据复制，有效降低性能开销。

目前，Service Mesh技术仍处于技术成熟度曲线的早期阶段。除了在L4/L7层提供灵活的服务通信功能外，社区还在探索通过网络Service Mesh实现灵活的L2/L3组网能力[6]。我们相信它将成为未来企业分布式应用通信基础设施。

在这个过程中，一些新的想法和项目会不断产生，我们需要能够理性地分析它们的商业价值和技术局限性。我们一定要避免把Service Mesh当作万能药，不要将应用集成、应用端安全等业务逻辑下沉到Service Mesh中，以免重蹈复杂性的覆辙。请参阅应用程序安全性和正确性无法卸载到Istio 或任何服务网格[7]。

回顾历史

世界的总趋势是，久分必合，久合必分。企业分布式应用架构也经历了分裂与融合的演进路径。在新技术不断涌现的今天，我们不仅要拥抱新技术带来的架构变革，更要更加关注其背后的演化逻辑和核心价值，系统性地控制复杂性。