从十多年前研发各种分布式系统到现在的容器云，从支撑原有业务到孵化各种新业务，企业的发展离不开与时俱进的统一技术架构时代。本文从企业分布式应用架构的角度介绍云原生计算架构带来的变革，希望能帮助更多企业进行IT转型，利用云计算技术推动其成为市场竞争中的敏捷力量。进入21世纪以来，我们见证了企业分布式应用架构从SOA（Service-orientedArchitecture），到微服务架构，再到云原生应用架构的演进。为了说明企业架构演进背后的思考，我们先说一些玄学。首先，企业IT系统的复杂性（熵）符合热力学第二定律。随着时间的推移和业务的变化，企业IT系统的复杂性会增加；其次，在计算机交互设计中有一个众所周知的复杂性守恒定律[1]。应用交互的复杂性不会消失，只会以不同的方式存在。这个原则也适用于软件架构。引入新的软件架构并不会降低IT系统的整体复杂性。听到这里，是不是让我们觉得活着折腾的有点爽？现代软件架构的核心任务之一就是定义基础设施和应用的边界，合理划分复杂度，减少应用开发者需要面对的问题。复杂。换句话说，就是让开发者专注于核心价值的创新，把一些问题留给更合适的人和系统去解决。让我们从下图开始，探寻企业分布式应用架构演进背后的逻辑。此图来自BilginIbryam的推特[2]转型之痛：SOA2004年，IBM成立了SOA全球设计中心。作为研发TL和架构师，我参与了一系列针对全球客户的试点项目，帮助Pepboys和OfficeDepot等国际公司使用SOA优化企业内部和企业之间的业务流程，提高业务敏捷性。当时的背景是：随着经济全球化的逐步深入，企业面临的竞争加剧，业务转型也开始加速。大型企业中的IT系统经过几十年的演进，整个技术体系变得异常复杂，如大型机系统上的CISC/COBOL事务应用、小型机AS400上的RPG业务系统、X86/C/JEE/.分布式系统的Net应用程序，例如Power。大量应用系统由第三方供应商提供，部分系统甚至无人维护。而且，随着业务的迭代，不断构建了一些新的业务系统。由于缺乏合理的方法论指导，系统之间缺乏有机联系，形成了几个孤岛，不断加剧IT架构的复杂性，无法支撑业务。发展需求。仿佛是各路高手，将不同的真气注入体内，为的是帮助令狐冲受伤的身体，虽然可以短暂的缓解伤势。但是，多道真气不能融合在一起，它们会相互激荡，时间长了，伤势就会更大。因此，企业IT面临的首要挑战是整合企业中大量孤立的IT系统，支持日益复杂的业务流程，做出高效的业务决策，支持快速的业务变化。在此背景下，IBM等公司提出了SOA（Service-OrientedArchitecture）的概念，将应用系统抽象为粗粒度的服务，构建松耦合的服务架构，通过业务流程灵活组合服务，提高企业IT资产的重用提高了系统的适应性、灵活性和可扩展性，解决了“信息孤岛”问题。SOA提出了一组构建分布式系统的原则，这些原则至今仍然适用：服务具有明确定义的标准化接口。通过服务定义描述，将服务消费者（ServiceConsumer）和服务提供者（ServiceProvider）的实现解耦，以契约优先而非代码优先的方式开发服务。服务之间的通信使用面向文档的消息而不是特定于语言的RPC协议。一方面可以解决服务和实现语言的解耦。另一方面，可以灵活选择同步或异步通信实现方式，提高系统的可用性和可扩展性；服务应该是松耦合的，服务之间应该没有时间、空间、技术、团队依赖；服务应该是无状态的，以便服务调用与会话上下文状态分离；服务应该是自治和自包含的，服务的实现可以独立部署、版本控制、自我管理和恢复；该服务是可发现和可组合的。例如，可以通过ServiceRegistry进行服务发现，实现服务消费者和服务提供者的动态绑定。在业务流程中，可以编排和组装来自不同系统的业务服务。在SOA系统的初始构建中，多采用点对点的通信连接，在应用实现中嵌入服务调用和集成逻辑。这种方式在服务数量比较少的情况下确实是一种简单高效的开发方式。但其最大的问题在于，随着服务规模的增长，服务之间的通信变得越来越复杂，连接路径和复杂度都会急剧增加，这给服务治理带来了巨大的挑战。为了解决上述挑战，引入了企业服务总线（EnterpriseServiceBus，ESB）。企业服务总线提供服务之间的连接、转换和中介功能。可以将企业内部和各种服务连接到服务总线上，实现信息系统之间的松耦合架构，屏蔽系统集成的复杂性，提高IT系统架构的灵活性，降低企业内部信息共享的成本.SOA方法论的目标就像易筋经一样，可以帮助梳理和聚集不同的气，整合它们，为我所用。然而，培训过程绝非易事。大量雄心勃勃的SOA项目未能取得预期成果的背后原因是什么？任何IT架构的成功都离不开与业务目标、技术基础和组织能力的相互对齐。在业务方面，当时SOA主要解决企业IT的存量问题。这使得SOA方法论在很大程度上缩小到企业应用程序集成（EAIEnterpriseApplicationIntegration）。在SOA理念中，打通信息系统之间的经脉只是第一步。还需要努力重构和迭代企业IT架构，保持企业IT架构的敏捷性和灵活性，持续支持业务发展和变化。在组织架构上，由于大部分企业的IT部门仍然是业务的成本中心和附属支撑部门，因此大部分企业缺乏长期的IT战略规划，IT团队也缺乏成长性认同。SOA被简化为基于项目的操作。没有组织保障和持续投入。随着时间的推移，复杂性逐渐减弱，即使是当时成功的项目也会失去活力。一位住在美国的朋友去年发来了一张照片。我们15年前为客户打造的业务系统，至今仍在支撑着他们在全国现有门店的业务。这是科技项目的成功，却反映出企业科技战略的缺失。从技术上讲，ESB架构虽然实现了业务逻辑与服务集成的解耦，能够更好地进行集中式服务治理，但也暴露出一些严重的问题：由于过分强调业务系统的可重用性，而不是对业务系统的治理和重构。企业IT架构。大量服务集成的实现逻辑被下沉到ESB中（如上图最右），这些逻辑非常难以维护，难以移植和扩展，成为ESB难以承受的负担.我们必须在正确的地方合理地处理复杂性，而不是简单地转移它；ESB基于集中式消息处理系统，但随着互联网的飞速发展，ESB已经无法应对企业IT大规模增长的挑战；ESB此类SmartPipes和Dumbendpoints的系统架构是一种无法适应快速变化和大规模创新的架构。以此类推，电信运营商曾希望将视频通讯、电话会议等复杂功能纳入电信基础设施，只需要一个Dummy电话终端即可享受丰富的通信服务。然而，随着智能手机的普及，微信、钉钉等分布式协作工具的创新彻底颠覆了人们的沟通方式，电信网络又回到了管道的宿命。羽化之美：微服务随着互联网的发展，尤其是移动互联网时代的到来，整个世界的经济形态发生了翻天覆地的变化。企业IT的重心已经从传统的SystemofRecord（交易系统，如ERP、SCM等）发展到SystemofEngagement（交互系统，如全渠道营销）。这些系统需要能够应对互联网规模的快速增长，并且能够快速迭代，低成本试错。企业IT已经成为驱动创新的引擎之一，技术拓展业务边界的理想也让IT团队有了更大的使命感，进一步加速了企业IT的演进。以Netflix、阿里为首的一系列互联网公司，引领了企业架构的新变革——微服务架构。ApacheDubbo、SpringCloud等微服务框架得到广泛应用。微服务的核心思想是对应用功能进行拆分和解耦，降低业务系统实现的复杂度。微服务强调将应用功能拆解成一组松耦合的服务，每个服务都遵守单一职责原则（SingleResponsibilityPrinciple）。微服务架构解决了传统单体架构的几个固有问题：每个服务都可以独立部署和交付，极大地提高了业务敏捷性；每个服务都可以独立地横向扩展/收缩，以应对互联网规模的挑战。原图来自MartinFowler对微服务架构的定义[3]当然，将一个大型单体应用拆解成多个微服务，势必会增加IT系统研发协作、交付、运维的复杂度。这时候，微服务架构、DevOps和容器自然而然地结合在一起，形成了云原生应用架构的雏形。微服务架构继承了SOA的架构原则，但在实现层面，倾向于通过构建智能端点和哑管道的去中心化分布式架构风格来替代ESB。微服务架构首先要面对分布式架构的内生复杂性，请参考分布式计算的误区[4]。微服务框架需要能够解决服务通信和服务治理的复杂性，例如服务发现、熔断、限流、全链路跟踪等挑战。HSF/Dubbo或SpringCloud等微服务框架以代码库的形式封装了这些能力。这些代码库内置于应用程序本身，随应用程序一起发布和维护。原图来源：[5]服务通信和治理的本质是一个横向的系统级关注点，与业务逻辑正交。但是在微服务架构中，它的实现和生命周期是和业务逻辑耦合在一起的。微服务框架的升级会导致整个服务应用的重构和部署。此外，由于代码库通常与特定语言绑定，难以支持企业应用的多语言（polyglot）实现。LightofEvolution：云原生SOA采用集中式服务总线架构，将业务逻辑和服务治理逻辑解耦；牺牲了业务逻辑和服务治理逻辑解耦带来的灵活性。为了解决上述挑战，社区提出了服务网格（ServiceMesh）架构。它将服务治理能力再次下沉到基础设施，作为一个独立的进程部署在服务消费者和提供者的两边。这样既达到了去中心化的目的，又保证了系统的可扩展性；也实现了服务治理和业务逻辑的解耦。两者可以独立演进，互不干扰，提高了整体架构演进的灵活性。同时，服务网格架构减少了对业务逻辑的侵入，降低了多语言支持的复杂度。原图来源：[5]由Google、IBM、Lyft牵头的Istio项目是服务网格架构的典型实现，也成为新的现象级“网红”项目。上图为Istio的架构图，逻辑上分为数据平面和控制平面：数据平面由一组以sidecar方式部署的智能代理组成，负责拦截应用网络流量，收集遥测数据，执行服务治理政策；在控制面，Galley负责配置管理，Pilot负责配置下发，Mixer负责策略校验和遥测数据聚合，Citadel负责通信中的安全证书管理。Istio提供了一系列高层次的服务治理能力，例如：服务发现与负载均衡、渐进式交付（灰度发布）、混沌注入与分析、全链路追踪、零信任网络安全等，可以利用通过上层业务系统编排到自己的IT架构和发布系统中。但ServiceMesh并不是灵丹妙药。它的架构选择是通过增加部署复杂度（sidecar）和损失性能（增加两跳）来换取架构的灵活性和系统的可演化性。为了解决部署复杂性的挑战，社区和云服务商正在共同努力：一方面，简化服务网格的自动化运维水平（比如阿里云大大简化了升级运维）Istio和通过operator跨K8s集群部署的复杂性）；另一方面，它提供托管服务网格服务，帮助用户专注于业务层面的服务治理，而不是基础设施实施。关于性能问题：一方面，ServiceMesh需要降低自身控制平面和服务平面的性能开销，比如尽可能卸载mixer负载，将治理策略的执行下沉到数据平面完成;另一方面，也需要重新思考应用在整个通信栈中与网络基础设施的边界。为了实现容器应用之间的互联互通，Kubernetes社区提出了CNI网络模型，将容器网络连接与底层网络实现解耦。同时，K8s提供了Service、Ingress、Networkpolicy等基础原语来支撑应用层。服务通信和访问控制。但这些能力远远不能满足应用对服务治理的需求。服务网格新增流量管理、全链路可观测、L4/L7安全互联等功能。这些都是通过引入运行在用户空间的Envoy代理来实现的，这在提高性能开销的同时不可避免地增加了灵活性。为了系统地解决这个问题，社区正在进行有趣的探索。例如在Cillium容器网络中，可以通过eBPF/XDP等操作系统和底层网络能力，将应用层的服务控制能力（比如Kube-Proxy提供的服务和网络策略）下沉到操作系统内核层和网络层。它还优化了ServiceMesh数据链路，减少了上下文切换和数据拷贝，有效降低了性能开销。目前，ServiceMesh技术还处于技术成熟度曲线的早期阶段。除了在L4/L7层提供灵活的服务通信功能，社区也在探索通过网络ServiceMesh[6]实现灵活的L2/L3组网能力。我们相信它将成为未来企业分布式应用的通信基础设施。在这个过程中，会不断产生一些新的想法和项目，我们需要能够理性地分析它们的商业价值和技术局限性。我们应该避免把ServiceMesh当成万能药，不要把应用集成、应用侧安全等业务逻辑下沉到ServiceMesh中，以免我们重蹈复杂化的覆辙。可以参考ApplicationSafetyandCorrectnessCannotBeOffloadedtoIstioorAnyServiceMesh[7]。回望历史大势，分久必合，分久必分。企业分布式应用架构也经历了一条分裂与组合的演进之路。在新技术层出不穷的今天，我们不仅要拥抱新技术带来的架构变革，更要关注其背后的演进逻辑和核心价值，系统地控制复杂性。相关链接：[1]https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity[2]https://twitter.com/bibryam/status/1026429379587567616[3]https://martinfowler.com/articles/microservices。html[4]https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing[5]https://philcalcado.com/2017/08/03/pattern_service_mesh.html[6]https://networkservicemesh.io/[7]]https://blog.christianposta.com/microservices/application-safety-and-correctness-cannot-be-offloaded-to-istio-or-any-service-mesh/
