|
进入21世纪以来，我们见证了企业分布式应用架构从SOA（Service-Oriented Architecture）到微服务架构，再到云原生应用架构的演化。 为了说明企业架构演化背后的思考，我们先谈一些“玄学”： l 企业IT系统的复杂性（熵）符合热力学第二定律。随着时间的推演，业务的变化，企业IT系统的复杂度会越来越高。 l 在计算机交互设计中有一个著名的复杂性守恒定律：应用交互的复杂性不会消失，只会换一种方式存在。这个原理也同样适用于软件架构，即引入新的软件架构，不会降低IT系统的整体复杂性。 听到这里，是否让生命不息、折腾不止的我们感到一丝凉凉？ 现代软件架构的核心任务之一就是定义基础设施与应用的边界，合理切分复杂性，减少应用开发者需要面对的复杂性。换句话说，就是让开发者专注于核心价值创新上，而把一些问题交给更合适的人和系统来解决。 我们就从图I-1开始，探究企业分布式应用架构演进。  蜕变之痛—SOA 2004年，IBM建立SOA全球设计中心，我作为研发TL和架构师参与了一系列全球客户的pilot项目，帮助PepBoys、Office Depot等国际企业利用SOA优化企业内部和企业间的业务流程，提升业务敏捷性。 当时的大背景是，随着经济全球化逐渐深入，企业面对的竞争加剧，商业变革也开始提速。在大型企业内部的IT系统已经经过了数十年的演化。整个技术体系变得异常复杂，并存着诸如主机系统上的CISC和Cobol交易应用、小型机AS/400中的RPG业务系统、X86或Power等分布式系统的C、J2EE、.Net应用。大量应用系统由3方供应商提供，一些系统甚至已经无人维护。而且随着业务迭代，一些新的业务系统被持续构建出来，由于缺乏合理的方法论指导，系统之间缺乏有机的链接，形成了若干个“信息孤岛”，持续加剧了IT架构的复杂性，无法支撑业务发展的诉求。这就仿佛各派高手为了帮助受伤的令狐冲，把异种真气输入体中，虽然短时间可以缓解伤势，可是多道真气无法融合，互相激荡，长时间下来会伤上加伤。 因此，企业IT所面临的首要挑战就是整合企业中大量竖桶型（siloed）IT系统，支撑日益复杂的业务流程进行高效的业务决策和支撑业务快速变化。在这种背景下，IBM等公司提出了SOA（面向服务的架构）理念，将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业IT资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。 SOA提出了一系列构建分布式系统的原则，这些原则直到今天也依然适用： 1） 服务具备明确定义的标准化的接口，通过服务定义描述，将服务消费者（consumer）和服务提供者（provider）的实现进行解耦。并且服务应该采用contract-first而非code-first方式进行开发。服务间通信采用面向文档的消息而非特定语言RPC协议，一方面可以解决服务与实现语言的解耦，另一方面可以灵活选择同步或者异步的通信实现，提升系统可用性和可伸缩性。 2） 服务应该是松耦合的，服务之间不应存在时间、空间、技术、团队上的依赖。 3） 服务应该是无状态的，使得服务调用与会话上下文状态实现解耦。 4） 服务应该是可复用的，业务逻辑切分为一系列可复用服务。 5） 服务应该是自治和自包含的，服务的实现可以独立进行部署、版本控制、自我管理和恢复。 6） 服务是可发现、可组合的。比如可以通过Service Registry进行服务发现，实现了服务消费者和服务提供者的动态绑定。业务流程中可以对来自不同系统的的业务服务进行编排组装。 在初始构建SOA系统的时候，大多数系统采用点对点的通信连接，服务调用和集成逻辑被内嵌在应用实现中。这种方式在服务数量比较少的时候，确实是一种简单和高效的开发方式。但其最大的问题是，随着服务规模的增长，服务之间通信愈发复杂，连接路径和复杂性会剧增，给服务治理带来巨大的挑战。 为了解决上述挑战，企业服务总线(Enterprise Service Bus，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的基本原理与开发实战，包含大量精选案例和参考代码可以下载，可快速入门Istio开发。Gartner认为，2020年服务网格将成为所有领先的容器管理系统的标配技术。本书适合所有对微服务和云原生感兴趣的读者，推荐大家对本书进行深入的阅读。 本文作者简介：易立，阿里云容器服务负责人，资深技术专家。 |
|
|
