云原生分布式应用治理综述
——张乎兴
阿里云高级技术专家
分布式应用治理是微服务进行到一定程度之后的必经之路，也是在分布式基础架构之上构建的更高级特性。
分布式应用治理主要经历了以下几个阶段发展而来：
云上部署阶段：将业务和应用从自建机房部署到云上，主要面向机器通过云计算来释放计算红利。
云原生部署阶段：期望应用更加云原生化，因此以容器化为核心，将应用架构通过容器化云原生做一定的改造。
微服务化：业务发展达到一定规模达后，需要做微服拆分和改造，目标是以应用为核心，让应用开发更敏捷。
分布式应用治理：微服务化演进到一定阶段之后，需要进行微服务治理。此时的依赖关系更复杂，会面临一系列困难。进行分布式应用治理，目标是将业务核心侧重在研发提效以及稳定性保障上，让业务更加稳定安全，迭代更加高效。
中间件开源项目可以划分为两个部分，分别是分布式应用架构和分布式应用治理。
分布式应用架构提供了分布式微服务应用场景下所需的基础能力，包括以下几部分：
①微服务 RPC 框架：比如Dubbo 和 Spring Cloud Alibaba ，主要解决微服务框架构建的基础问题。
②消息平台：负责异步调用的 RocketMQ；
③注册中心和配置管理；
④分布式事务：Seata 负责解决分布式事务方面的问题；
⑤应用诊断：由 Arthas 负责应用诊断，快速诊断问题。
基础应用架构之上还需要服务治理，主要包括以下几部分：
①微服务治理：阿里巴巴的开源项目 OpenSergo用于解决跨微服务系统的不同微服务框架之间统一管控、统一调用、统一服务发现、统一微服务治理开源规范以及标准的实现；
②应用多活架构：AppActive；
③应用流量管控：Sentinel；
④混沌工程：ChaosBlade；
分布式应用架构提供了应用分布式拆分过程中依赖的基础组件，解决分布式应用落地的问题（0-1）；而分布式应用治理提供了分布式应用规模化过程中需要的治理能力和解决方案，解决了用好、管好分布式应用的问题（1-100）。
上图展示了阿里微服务治理的演进路线。
微服务起始阶段主要做微服务拆分，产生了 RBC 框架、消息系统以及分库分表三个组件。自研的微服务中间件通过 SDK 方式依赖，但是每个微服务都要进行一次依赖，升级和管理成本非常高。
2013年，阿里推出了基于隔离容器的方案，将所有中间件能力打包成整体提供给业务方，内部代号是潘多拉。通过这种方式使各个中间件单独升级变为整体升级，服务治理与业务解耦，中间件和业务运维治理效率也得到了非常大的提升。
但是这种形态下的升级成本依然非常高，中间件发布稳定版本往往需要经过一年甚至更久才能完全在整个集团内部推广。
19 年，我们希望能够通过更精良的方式将微服务治理与业务解耦，因此推出了 Java Agent 方案。Agent 升级可以做到业务无感知、无侵入，没有任何升级成本，提供了非常好的用户体验。
然而，一些非 Java 体系的微服务依然无法享受到 Agent 带来的便利，因此我们也在推动通过 mesh 的方式针对多元实现无侵入的微服务治理能力。
从以上进程可知，微服务一直朝着无侵入、零升级成本的方向演进。微服务治理能力针对不同框架，依然存在非常高的知识成本。虽然在阿里内部已经基本统一了微服务框架，但很多云上客户依旧依赖各种框架，框架之间如何统一实现微服务治理能力，也是非常棘手的问题。因此，我们将 OpenSergo 项目进行开源。
OpenSergo 项目主要针对跨微服务框架、异构微服务框架以及异构语言之间能够进行统一管理、统一治理，能够将服务发现、流量治理、可观测领域完全拉通。
上图为 OpernSergo 开源架构大图。
最上层为管控面，通过kubernetes 云原生的方式和 CRD 的方式描述微服务治理的能力，并通过云原生的方式下发。同时也提供控制台针对不同服务进行管理。另外，还能够支持第三方企业通过自建标准实现自己的控制台。
OpernSergo-spec层规定了微服务治理领域的概念，将其标准化。
实现层分为多个领域，有服务发现、分布式事务、任务调度、流量治理、可观测等，每个领域都有规范的 spec 以及实现。比如在流量治理阶段，会有针对不同语言的实现，包括Java、Go 语言等。通过统一的标准，不同框即可以不同的形态接入到规范中，并被统一管理。
框架和基础设层也提供了很多微服框架供对接，比如 Spring Cloud、Apache Dubbo、Bilibili 开源的 Kratos、字节跳动开源的CloudWeGo 等。
后续 OpenSergo 将从 Spec 制定、数据面建设、管控面建设三个层面持续发展，未来一年的阶段性目标分为四个大层面，分别是流量治理、服务发现、可观测性以及互联互通。
2022年 Q2 季度将发布 Spec 0.2 版本，同时支持全程灰度流量打标，进行灰度能力标准化建设。在此基础上，还会将Kratos、CloudWeGo以及Spring CloudAlibaba 与 MySQL 进行对接。
2022年 Q3 季度 ，计划对服务发现和注册发现领域完成标准化，发布 Spec 0.5 版本 ，并支持服务发现、无损上线等能力，同时会与Dubbo、Envoy 以及 Mosn 社区对接。
2022年 Q4 季度，将进行可观测领域建设，发布真实版本的 Spec 1.0 ，加入可观测性的标准，并与更多社区对接。
最终，我们期望实现各个框架互联互通。
未来，Sentinel 会重点投入流量治理领域，与 OpenSergo 进行全面整合。 OpenSergo 是服务治理领域的规范，而Sentinel 2.0 就是流量治理层面的标准实现。因此，我们将升级为流量治理品牌，提供各种流量调度、流量控制以及隔离自愈等流量治理里关键手段的标准实现。
此外，我们会提供各种各样的形态，包括 SDK 方式、Agent 方式等，同时继续扩大多语言能力的建设，探索数据库治理，与其他社区联联动，将流量治理能力全方位覆盖到云原生生态。
在数据库治理领域，Sentinel 将与OpenSergo 结合，将流量治理技术真正标准化，提供通用的 CRD 供社区使用。
微服务治理的主要趋势是数据面多样化，控制面板标准化。
微服务治理的实现非常复杂，因此更需要统一控制面，控制面必须进行标准化，我们将以OpenSergo 为规范进行标准化动作。此外，因为不同框架、不同语言的实现不一样，我们将提供多种多样的数据面，包括 SDK 方式、Java Agent 方式以及 Service Mesh 方式，甚至将来也许会探索通过eBPF 来进行微服务治理的实现等，不同的数据面针对不同场景都有其存在价值。
服务治理可以细分为几个子领域，主要包括开发态、测试态、发布态、高可用以及安全态。
阿里云发布的微服治理技术白皮书，是阿里云微服治理团队经过半年多的总结，整理出来的一本非常有价值的书。微服务治理背景、解决方案原理、场景化解决方案以及最佳实践都囊括在这本书里。目前此书已在阿里云开发者社区上线，提供免费下载。
应用多活容灾是分布式应用治理领域非常重要的一个模块。灾难往往是常态化发生的，灾难出现时，在短时间内将应用业务迅速切换到另外机房，从而避免因为单个机房灾难造成整个业务宕机，是非常重要的能力。
阿里经历了历年双 11 大促，孵化出非常多的多活容灾理念架构以及实践，并通过 AppActive 开源项目将最佳实践通过开源项目的形式释放。
项目涵盖了多活容灾里非常重要的几个组件，比如入口层能够实现非常精准的流量切换以及流量隔离，能够根据不同的切分原则，将不同流量引入到不同机房。
应用层也提供了很多切流方案，灾难发生时，通过中心化控制台将流量切流指令下发，同机房内部可以迅速将流量从 A 机房切换到 B 机房，此时，在应用内部也需要做快速的流量收敛。因此我们针对不同框架做了实现支持，包括微服务框架常见的 Dubbo、Spring Cloud、消息、数据库等，帮助更快收敛流量。
底层主要负责支持数据库之间的同步。
从网关入口到中间层再到最后数据层，AppActive 都做了非常多实践，希望将能力开放出来后能够帮助企业更好地构建业务稳定性。
ChaosBlade 是故障演练开源项目，于 2019 年开，主要解决在不稳定环境下，如何通过一些方式提前发现问题，即通过混沌工程的技术理念，常态化地构建出未来可能会出现的问题。
比如每年双 11 大促备战时，我们都会进行故障演练，模拟一些场景，观察系统是否存在问题，能否正确地应对故障。
项目面向多集群、多语言（ Java、Go、node.js ）、多环境（虚拟机、kubernetes等），能够非常方便地进行故障演练，也可以通过简单命令行实现故障模拟。它将混沌工程理念与很多开源生态做了结合，使分布式应用治理领域更加丰富。
OpenSergo、Sentinel、AppActive和 ChaosBlade 四个开源组件共同构成了分布式应用治理的核心能力。
