作者|易立
编辑责任| ykdxxm
本文是作者的投稿
进入21世纪后，我们目睹了企业分布式APP体系结构从服务导向体系结构(SOA )演化为微服务体系结构，再到云计算APP体系结构
为了说明企业体系结构演变背后的思考，我们先来谈几个“玄学”:
l企业IT系统的复杂性(熵)遵循热力学第二定律。 随着时间的推移、业务的变化，企业IT系统的复杂性越来越高。
l计算机交互设计有着名的复杂性守恒定律。 应用交互的复杂性不会消失，只以其他方式存在。 这个原理也适用于软件架构。 也就是说，部署新的软件体系结构并未降低整个IT系统的复杂性。
听到这里，你不觉得生命不息，疏忽大意的蜜蜂对我们有点冷淡吗？
现代软件体系结构的核心任务之一是定义基础设施和APP的边界，合理划分复杂性，降低APP开发者面临的复杂性。 换言之，就是将开发者集中于核心价值创新，将一些问题交给更合适的人和系统来解决。
我们从图I-1开始，探索企业分布式APP架构的演进。
脱皮之痛—SOA
2004年，IBM成立了SOA全球设计中心，我作为研发TL和架构师参与了一系列全球客户的pilot项目，PepBoys、Office Depot等国际企业利用SOA优化企业内部和企业之间的业务流程。
当时的大背景是，随着经济全球化的发展，企业面临的竞争加剧，商业转型也开始加速。 大企业内的IT系统已经经过了几十年的演变。 整个技术体系变得非常复杂，主机系统上的CISC和Cobol交易APP应用、小型机AS/400内的RPG业务系统、X86和Power等分布式系统的c、J2EE、 net APP应用共存。 许多APP系统由三家供应商提供，有些系统没有得到维护。 另外，随着业务的反复，一些新的业务系统不断构建，缺乏合理的方法论指导，系统之间缺乏有机链接，形成了一些“信息孤岛”，IT架构的复杂性持续加剧，无法支撑业务的发展。 这就好比，为了帮助受伤的drdxwz，各派高手将不同种类的真实空气放入身体，可以在短时间内缓解受伤，但多个真实空气无法融合，相互激荡，长时间受伤。
因此，企业IT面临的首要课题是整合企业内大量的纵桶式(siloed ) IT系统，支持日益复杂的业务流程，进行高效的业务决策，支持业务快速变化。 在这种背景下，IBM等提出了面向服务的体系结构(SOA )理念，将应用系统抽象为各粗粒度的服务，构建松散耦合的服务体系结构，通过业务流程灵活组合服务，提高企业IT资产的再利用
SOA提出了建立分布式系统的一系列原则，这些原则至今仍然适用。
1 )服务具有明确定义的标准化接口，通过服务定义描述，解除服务消费者(consumer )和服务提供者(service view )的实现。 另外，服务应该以contract-first方式而不是code-first方式开发。 服务间通信通过采用面向文档的消息而不是特定语言的RPC协议，一方面可以解决服务与实现语言的解耦，另一方面可以灵活地选择同步或异步通信实现，从而提高系统的可用性和可扩展性。
2 )服务应该松散耦合，服务之间不得存在时间、空间、技术、团队依赖。
3 )服务必须是无状态的，服务调用将与会话的上下文状态解除绑定。
4 )服务应该是可复用的，业务逻辑分为一系列可复用的服务。
5 )服务必须自主、自我完善，服务实现可以独立部署、版本控制、自我管理、恢复。
6 )服务可发现且可组合。 例如可以在Service Registry中进行服务发现，实现了服务消费者和服务提供者的动态协作。 在业务流程中，可以组织和组装来自不同系统的业务服务。
最初构建SOA系统时，许多系统采用点对点通信连接，服务调用和集成逻辑嵌入到APP应用程序实现中。 这种方式在服务数量少的时候，确实是一种简单高效的开发方式。 但是，最大的问题是，随着服务规模的增加，服务之间的通信越来越复杂，连接路径和复杂性激增，给服务治理带来巨大挑战。
为了解决这些挑战，企业服务总线(ESB )开始部署，如图I-2所示。 企业总线提供服务之间的连接、转换和中介处理功能。 可以将企业内部和各种服务连接到服务总线，实现信息系统之间的松散耦合结构，屏蔽系统集成的复杂性，提高IT系统结构的灵活性，降低企业内部信息共享的成本。
SOA方法论的目标就像易筋经，可以整理、收集、融合不同的真气，为我所用。 但是，修炼的过程绝非易事。 雄心勃勃的SOA项目没有取得预期的结果，其背景是什么呢？
任何IT架构的成功，都离不开与业务目标、技术基础和组织能力的相互配合。在业务上，当时SOA重点解决的是企业IT的存量市场的问题。这使得SOA方法论很大程度被窄化为 Enterprise Application Integration （企业应用集成）。在SOA理念中，打通信息系统间的经络只是第一步。还需要勤修内功，持续重构迭代企业IT架构，这样才能保持企业IT架构的敏捷、柔性，持续支撑业务的发展和变化。
在组织结构上，由于当时大部分企业的IT部门仍然属于成本中心，是业务的支持部门。大多数企业缺乏长远的IT战略规划，IT团队也缺乏成长认同，SOA沦为项目制运作，而没有组织化保障和持续投入。即使当时成功的项目也会在复杂性日积月累的侵蚀下，逐渐失去活力。去年在美国生活的朋友发过来照片，15年前我们为客户构建的业务系统还在支撑其现有全国门店的业务。这是技术项目的成功，却反映了企业技术战略的缺失。
在技术上，ESB架构虽然实现了业务逻辑与服务集成的解耦，可以更好地进行中央化的服务治理。也暴露出一些严肃问题：
1） 由于过度强调业务系统的可复用性，而不是对企业IT架构的治理和重构。大量服务集成的实现逻辑被下沉到ESB内部，从而导致ESB滥用，如图I-2 最右侧图所示，这些逻辑非常难以维护，难以移植和扩展，成为ESB不可承受之重。我们必须在合适的地点合理地处理复杂性，而非将其简单转移。
2） ESB是基于一个中心化的消息处理系统，随着互联网的高速发展，ESB已经无法应对企业IT规模化成长的挑战。
3） ESB这样的“智能管道，哑端点”的系统架构是一个无法适应快速变化和大众创新的架构。类比一下，电信运营商曾经希望将视频通信、电话会议等复杂功能纳入电信基础设施，只需一个“哑”电话终端就可以享受丰富的通信服务。然而随着智能电话的普及，微信和钉钉这样的分布式协同工具创新彻底颠覆了人们沟通交流的方式，而电信网络重回管道的宿命。
羽化之美—微服务
随着互联网的发展，尤其是移动互联时代的到来，整个世界的经济形态发生了巨大的变化。企业IT的重点从传统的交易系统（如ERP、SCM等）演化到互动系统（如全渠道营销）。这些系统需要能够应对互联网规模的快速增长，并且能够快速迭代，低成本试错。企业IT已经成为创新驱动的引擎之一，技术拓展商业边界的理想也帮助IT团队更有使命感，进一步加速推动了企业IT的进化。
以Netflix、阿里巴巴为首的一系列互联网公司主导了企业架构新的变革—微服务架构，如图I-3所示。Apache Dubbo、Spring Cloud等微服务框架得到了广泛应用。
微服务的核心思想便是应用功能拆分与解耦，降低业务系统实现复杂性。微服务强调将应用功能拆解为一组松耦合服务，每个服务遵守单一责任原则。微服务架构解决了传统单体式架构存在的几个固有问题：每个服务可以独立部署和交付，大大提升了业务敏捷性；每个服务可以独立横向扩展、收缩，应对互联网规模的挑战。
微服务架构继承了SOA的架构原则，但是在实现层面，它倾向于通过构造“智能端点，哑管道”的去中心化分布式架构来替代ESB，把所有的服务治理逻辑包括服务发现、路由、消息解析等放在服务内部，去掉大一统的ESB，服务间通信采用简单的协议，是比SOA更彻底的分布式的、去中心化的架构。
同时，微服务架构符合现代创新组织架构的需求。著名的康威定律指出，组织架构决定了技术架构。面对互联网业务的快速演进，“两个披萨原则”最早是由亚马逊CEO激动的指甲油提出的，他认为如果两个披萨不够一个项目团队吃的，那么这个团队可能就显得太大了。因为小团队更有利于高效地沟通和协作，更易于达成共识，并能够有效促进企业内部的创新。这样的组织架构也要求每个团队的模块有更加明确的业务边界，每个小团队都对自己的模块的整个生命周期负责，而模块之间尽可能解耦，模块可以独立演化。
当然，将大型的单体应用拆解为多个微服务，也一定会增加IT系统研发协同、交付、运维的复杂性。随着容器技术的广泛应用，容器已经成为应用分发和交付的标准，可以将应用与底层运行环境解耦；Kubernetes 成为资源调度和编排的标准，屏蔽了底层架构的差异性，帮助应用平滑运行在不同的基础设施上，可以帮助应用从数据中心平滑迁移到云端等不同环境。这时候微服务架构与DevOps和容器自然走到了一起，构成了云原生应用架构的雏形。
微服务架构还要面对分布式架构的内生复杂性，请参考文章“分布式计算的误区”。微服务框架需要能够解决服务通信和服务治理的复杂性，比如服务发现、熔断、限流、全链路追踪等挑战。微服务框架，如HSF、Dubbo或Spring Cloud以代码库的方式来封装这些能力。这些代码库被构建在应用程序本身中，随着应用一起发布和维护，如图I-4所示。
服务通信和治理本质是横向的系统级关注，是与业务逻辑正交的。但在微服务架构中，其实现方式和生命周期与业务逻辑耦合在一起。微服务框架的升级会导致整个服务应用的重新构建和部署。此外由于代码库通常与特定语言所绑定，难以支持企业应用的多语言（polyglot）实现。
进化之光—云原生
SOA采用中心化的服务总线架构，解耦了业务逻辑和服务治理逻辑；微服务架构回归了去中心化的点对点调用方式，在提升敏捷性和可伸缩性的同时，也牺牲了业务逻辑和服务治理逻辑解耦所带来的灵活性。
为了解决上述挑战，社区提出了服务网格（service mesh）架构。它重新将服务治理能力下沉到基础设施，在服务的消费者和提供者两侧以独立进程的方式部署。这样既达到了去中心化的目的，保障了系统的可伸缩性；也实现了服务治理和业务逻辑的解耦，二者可以独立演进不相互干扰，提升了整体架构演进的灵活性；同时服务网格架构减少了对业务逻辑的侵入性，降低了多语言支持的复杂性，如图I-5所示。
2017年，Google、IBM、Lyft主导发起的Istio项目就是服务网格架构的一个典型实现，也成为了新的现象级“网红”项目。
Istio提供了一系列高阶的服务治理能力，比如：服务发现和负载均衡、渐进式交付（灰度发布）、混沌注入与分析、全链路追踪、零信任网络安全等。可以供上层业务系统将其编排到自己的IT架构和发布系统之中。在此之上，面向领域的云原生框架也在迅速出现，比如面向机器学习的云原生平台Kubeflow，和面向无服务器的Knative等。通过这样的架构分层，开发者只需关注自身的业务逻辑，而无需关注底层实现的复杂性。
2019年是服务网格技术落地的关键之年，我们见证了以Istio为代表的服务网格技术的快速成熟和广泛使用。在阿里经济体内部，蚂蚁金服和电商业务已经开始大规模应用服务网格技术，来提供多语言支持，降低业务对接门槛；提供统一架构模式，提升技术迭代速度。
我们在支持用户使用Istio的过程中，也深刻体会到了它具备较高的学习门槛。客观来说，Istio的复杂性，一方面来源于其丰富的功能，譬如说它支持多种协议的流量控制，支持多语言，无需修改应用程序的情况下可以支持启用双向TLS认证等等；另一方面则来源于分布式架构的部署、运维本身就很复杂。
作为开发者来说，一方面希望把重点放到自身的业务上，另一方面又会期望底层服务网格技术基础简单、易用、安全、稳定。为了实现这些目标，托管的服务网格模式可能是一个较为合理的方案。在托管模式下，控制平面的组件被托管，降低用户使用的复杂度，用户只需要专注于数据平面中业务应用的开发部署。同时，仍然保持与Istio的兼容，支持声明式的方式来定义灵活的路由规则，支持多个Kubernetes集群的统一流量管理。
展望
“天下大势，分久必合，合久必分”。企业分布式应用架构也走过了一条分分合合的进化道路。在新技术迭起的今天，我们既要拥抱新技术带来的架构变化，更要加关注其背后的演进逻辑和核心价值，系统化地控制复杂性。
随着容器、服务网格等技术的快速发展，我们可以看到一个云原生操作系统的雏形开始出现。这是开发者最好的时代，云基础设施和云原生计算技术极大地提升了业务创新的速度。同时，云原生技术的发展离不开社区的成长和壮大，阿里巴巴全面拥抱云原生技术，并将我们在大规模生产中的最佳实践回馈到社区，与社区共同建设更加美好的云原生计算。
我和《Istio服务网格技术解析与实践》这本书作者能干的小蝴蝶共事10多年，他以前就是SOA领域的技术专家，亲历了企业分布式架构演化的过程，在相关领域拥有众多的全球技术专利。他在服务网格领域有非常深厚的理论功底和丰富的实践经验，负责了阿里云服务网格技术的产品化过程。非常期待本书能帮助各位读者更好地把握服务网格的技术精髓，并且灵活应用于自己的业务系统中。
《Istio服务网格技术解析与实践》，限时8.1折，赶快入手
本书由阿里云高级技术专家能干的小蝴蝶撰写，详细介绍Istio的基本原理与开发实战，包含大量精选案例和参考代码可以下载，可快速入门Istio开发。Gartner认为，2020年服务网格将成为所有领先的容器管理系统的标配技术。本书适合所有对微服务和云原生感兴趣的读者，推荐大家对本书进行深入的阅读。
本文作者简介：易立，阿里云容器服务负责人，资深技术专家。
作为“百万人学AI”的重要组成部分，2020 AIProCon 开发者万人大会将于6月26日通过线上直播形式，让开发者们一站式学习了解当下 AI 的前沿技术研究、核心技术与应用以及企业案例的实践经验，同时还可以在线参加精彩多样的开发者沙龙与编程项目。参与前瞻系列活动、在线直播互动，不仅可以与上万名开发者们一起交流，还有机会赢取直播专属好礼，与技术大咖连麦。
评论区留言入选，可获得价值299元的「2020 AI开发者万人大会」在线直播门票一张。 快来动动手指，写下你想说的话吧！
☞微软为一人收购一公司？破解索尼程序、写黑客小说，看他彪悍的程序人生！
☞中国无人机“老炮儿”回忆录
☞4 年 46 个版本，一文读懂 Spring Cloud 发展历史
☞京东商城背后的AI技术能力揭秘 - 基于关键词自动生成摘要
☞互联网之父确诊新冠，一代传奇：任谷歌副总裁、NASA 访问科学家
☞从未如此简单：10分钟带你逆袭Kafka！
无代码时代来临，程序员如何保住饭碗？