开发者学堂课程【2022阿里云云原生中间件开发者大会集锦：云原生分布式应用治理综述】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1053/detail/15297
云原生分布式应用治理综述
内容介绍：
一、分布式应用治理是微服务化深入的必经之路
二、中间件开源项目
三、微服务开源-构建应用治理生态
四、阿里微服务治理演进路线
五、OpenSergo 开源规划
六、OpenSergo 里程碑
七、Sentinel
八、服务治理趋势
九、业内首本微服务治理技术白皮书
十、AppActive
十一、ChaosBlade
本课程是分布式应用治理专场。分享的题目叫分布式应用治理的综述，在云原场景下分布式应用治理的综述。
一、分布式应用治理是微服务化深入的必经之路
都知道就是分布式应用治理它是一个在微服务深化进行到一定程度之后，必然要经历的一个阶段，就是为什么要分分布式应用治理和分布式基础架构两个专场。认为分布式应用治理在分布式技术架构之上构建更高级的一个特性，所以它应用治理是分布式微服务发展到一定阶段的一个必经之路，所以从这个过程上来讲一讲为什么需要分布式应用治理。
1. 云上部署
这里面也分了好几个阶段，首先在第一阶段的微服务架构体系上，可能最开始了是把业务和应用从自建的机房部署到云上，这个阶段叫做云上部署，也就是cloud hosting阶段，这个阶段主要面向的是一机器把通过云计算来释放计算红利。
2.云原生部署
那第二阶段希望应用更加的云原生化，那么会以容器化为核心，把应用架构通过容器化云原生做一定的改造，那这个阶段称之为cloud native。云原生部署的阶段。
3.微服务化
那第三阶段是属业务，当业务发展规模达到一定程度上，需要作微服务拆分，这个时候需要做微服务的改造，这个阶段叫做微服务化。这个阶段，核心目标实际上以应用为核心，让应用的开发更加的便捷，更加的敏捷。
4.分布式应用治理
那当微服演进到一定阶段之后，通常推荐的是在数十个节点，这样的一个规模是需要做服务治理的，那这个时候就是依赖关系更加复杂，这个分布式如果不做治理团的，会面临一系列的困难。那就是需要做应用治理。那也就是以业务为核心去fox在这个研发体校以及稳定性的保障上面，让业务更加的稳定，安全，迭代更加的高效，这是做应用治理的一个核心目标支持。这是四个阶段。
二、中间件开源项目
从中间件的开源项目来讲，把这些开源项目的划分了两个部分。
1. 分布式应用架构
也就是前面讲到的一个是分布式基础的应用架构，它解决的是分布式应用微服务应用场景下所。需要的基础的应变能力，那这里面包括了哪些？像微服框架，rbc框架，常说的dubbo 。然后以及spring cloud alibaba，这两款项目就是主要在解决这样的微服务框架的构建的技术问题。
那么有了这些问题？可能还需要到一些异部的调用，那前面的那些rpc框架可能是更多的同步调用为主，所以需要像rocketmq这样的消息开源框架。
然后像服务注册和发现也是在微服体系下面非常重要的一块。有在中间件里面有nacos这样一个非常开源有影响力的一个辅助的发现和配置中心，然后另外，还需要向分布式事务在构建分布事物的时候，需要一个框架。像seata它就解决这方面的问题。还有在应用诊断时的时候需要一些工具，去快速的诊断问题，这个时候有arthas 来承担这部分的功能。arthas也是整个阿里这个案例开源原项目里面，微服务的那个仨数最高的一个项目。这是认为的分布式基础的应用架构，
2. 分布式应用治理
那在这之上需要什么？在刚才介绍过微服务里面需要治理的，那这个阿里巴巴这边也有一个开源项目叫opensergo，它解决的就是跨微服务系统，不同的微服务框架之间能够进行统一的管控，统一的调用，统一的服务发现。做这样的一些事情，微服务的恢复治理，开源的一个规范，以及它的标准实现。
另外也有sentinel，sentinel是流量控制的一个开源项目。也是阿里内部一个双11非常重要的一个组件，然后把它开源。
然后也包括了最近新开元的，像应用的多火容灾架构appActive以及混沌工程chaosblade（CNCF）这两个项目。这些项目认为是在微服务体系，分布式体系下，当它需要规模决定一定规模的情况下，需要一个更高阶的分布式应用治理的接线能力，那归类为分布式应用治理能力。
三、微服务开源-构建应用治理生态
治理主要分为两个部分，那这两个部分之间，它们之间的关系又是什么样子？
简单来介绍一下，就是前面讲到了每一个分布式基础的架构都有一个核心的领域，像微服领域。有消息领域，分布式事务的领域。在这块面中间件都有一个相对于它自己的一个开源的一些软件。也有些演进是捐献给了不同基金会，包括像dubbo和rocketmq都已经捐献给阿帕奇基金会，另外像chaosblade已经在cncf基金会contributors项目。在不同领域有不同的一个开源的项目，也包括甚至是跟一些跟阿里一起合作的一个多运形式的开始项目diver，这也是目前在cnCF的项目。
这些构成了分布式拆分过程中它依赖的一些技术组件，那解决的问题是从0到1的一个内容落地的一个问题。这最上层是刚才提到的rocketmq，opensergo，appActive，chaosblade它们解决的是为分布式应用规模化过程中。解决它需要规模化使用过程中需要处理到像流量治理，流量访问，流量的防控，以及多活容灾，以及这种混沌工程等等。解决的使用好以及管好分布式应用的问题，从1到100的一个问题。是这样一个关系。
四、阿里微服务治理演进路线
简单介绍一下阿里这边的内部对微服务治理演进路线。
1.2008自研微服务
这里从一开始的话，最开始在做微服务改造的时候，是做了微服务的拆分，有了rpc框架，消息系统以及分部分表三个组件，那这些自研的微服务的中心线，它都是通过SDK的方式去依赖的，但是。对每个微服务都要依赖一遍，那它的升级和管理的成本是非常高的。
2.2013 fat-SDK Pandora
那在08年到13年的时候，推出了基于一个隔离容器的一个类似于将所有的中间件能给打包成一个整体，那么给整体提供业务，这个内部要求的搬拖拉通过这种方式。使得个个中间件单独升级，变成了整体升级，整体的这个服务治理跟业务就已经有很大的一个结偶。这个代表着中间件和业务的运维治理效率有了非常大的提升。但是发现，在这种形态下，升级的成本依然非常高，就是说中间件每年发布一个稳定的版本需要经过一年，甚至更多的时间才能够完全在整个集团内部进行推广。
3.2019 one java ageng
在19年的时候，也希望能够通过更加紧张化的方式跟业务治理的方式，去服务质量跟业务治理的方式去结偶，所以推出了就java ageng
的方案，也就是说如果自己把增强的方式完全跟业务完全脱离了，在ageng相关的升级里面的也完全不需业务来感知到，所以它们是无侵入的，没有也没有任何的升级成本。所以在这里认为是一个非常好的一个体验。
但是也有一些其它的非java体系的微服务。它们没有办法享受到这样的一种技术，所以也在推动通过side看的方式，通过面试的方式去实现无侵入的。针对多元，其实无侵入的的服务治理能力，所以，大致分为了这四个阶段。
可以看到，现在所有的这服务治理越来越朝着像无侵入。0升级成本这样的一种方向逼近。
五、OpenSergo 开源规划
1.开源 OpenSergo 原因
这些服务治理能力针对不同的框架，也觉得有非常多的一些知识成本，因为阿里内部虽然说，基本上已经统一了服务框架，类似于dubbo3.0已经完全在集团内完成的落地，但是其实发现在其它的这个云上的客户来说，它们有很多很多依赖各种框架，但这些框架之间怎么去统一的实现服务治理能力。
这摆在面前的一个非常大的一个问题，而且有很多是非java体系，这些东西也没法通过一些内部的一些java in的技术去实现，所以才有了OpenSergo这个项目，OpenSergo这个项目解决问题就是说想要针对微跨服务框架，异构微服务框架以及异构的语言之间能够进行统一的管理，及统一的治理，能够把服务发现，流量治理，可观测这些领域能够完全的拉通，所以开源了OpenSergo项目。
2. OpenSergo简介
所以简单介绍一下OpenSergo的这样一个开源的大图。
（1）、管控面
所以首先在最上层，有一个管控面。通过这种kubemetes的云原生的方式，通过crd的方式去描服务治理的一些能力，并且通过原生的方式去下发，同时提供控制台的方式。看一下，控制台可以对这部分进行管理。另外，也支持第三方的企业去自建，通过这个标准去实现它自己的一个控制台。
（2）、Spec
在Spec之间，会有构建OpenSergo的Spec，可去规定好这些在服务治理领域的一些概念，把它们标准化。
（3）、实现
那也有不同的实现，在实践层面上会有不同的实现，首先有很多个领域，子领域，定义了服务发现，事物以及任务调度流量治理，可观测等等一系列的领域，然后每个领域，都有它的规范Spec以及它的实现。比如说在流量治理的阶段，会有一些不同针对不同语言，也有它的一些实现java的go语言，也有这种java agent的实现，也有不同的像sidecar的实现，然后也有一些其它的社区像mosn，它也提供了，再接入对接OpenSergo这个工作，它也会对接一个规范，提供它自己的实现。
所以，通过统一的标准，不同的框架，就通过不同的形式，也不同的形态能够接受到这个规范，并且被统一的管理起来。
那在可观测试上，也会对一些标准的开源的那个规范，比如说telemetry。还有一些类似于入口的网关也会通过统一的方式去管理起来，现在已经在对接的像dubbo-go的一个pixiu的网关,以及shenyu网关还有spring cloud gateway等等，想都已经在对接了。
（4）、框架&基础设备
然后在框架基础设备，也有很多的各种各样的微服务框架在对接，像目前正在做的spring cloud alibaba开源的一个微服务框架，Kratos的微服务框架，以及cloudwego是由字节跳动开源的一个微服务框架，也是go语言的。所以有不同的框架，有不同的介入方式，然后有统一的规范。这是一个开源的一个规划。
六、OpenSergo 里程碑
那简单介绍一下OpenSergo的一个里程碑。OpenSergo的话，从这个三个层面，一个是spec制定,数据面建设是第二个，第三个就是管控面建设，下面在未来的一年里面会有一些阶段性的目标，大致分为四个大的层面，一个是流量治理。第二个是服务发现领域，第三是可观测性领域，第四个是互联互通的领域。
1.2022Q2
所以在近期已经发布了一个1.0的spec，在q2的季度，会发布一个0.2的版本，同时支持这个全身的灰度流量打标，以及灰度能力的标准化建设，那么在这个基础上，会把一些像kratos，还有cloudwego，以及spring cloud阿里巴巴跟OpenSergo进行对接。
2.2022Q3
然后在q3的话，主要会把服务发现领域服务标准化掉，会发布一个0.5版本的spec。支持服务发现，无损上下线的这样一些能力，同时会跟dubbo社区，envoy社区，还有mosn社区进行对接，
3.2022Q4
在Q4会进行一个可观测里面的一个建设发布。真实版本的1.0spec，同时加入这个可观测性的一些标准。同时跟更多的一些社区做一些对接，最后理想是期望能够个框架事件互联互通，包括像spring cloud和dubbo之间能够互通。同时进行网关的一些对接等等。这是一个大致的一个里程碑。
七、Sentinel
下面介绍一下，简单介绍一下Sentinel的未来的一些规划。Sentinel的话，未来会重点投入流量治理的领域，因为会在Sentinel和OpenSergo进行一个全面的整合。
Sentinel2.0版本，认为就是一个流量治理的一个标准实现，OpenSergo它是一个流量整个治理领域的一个规范，那Sentinel就是一个在流量治理这个层面的一个标准实现。所以会把品牌升级为整个流量治理的一个品牌，提供的各种流量调度，流量控制，以及隔离，自愈等等一些在流量这里面非常关键时段的一个标准事项。
同时会提供各种各样的形态，包括了SDK方式，agent的方式以及服务化组件方式的这种实现。
同时会继续扩大这个多语言的能力建设，包括像一些go语言。一些生态的一些建设，同时，也在跟一些数据库治理做一些探索，也跟一些其它的社区在联合的去做这方面的一些规范和实现了一些探索，在数据库治理的这个领域。那么，也会跟OpenSergo去结合，把相关的流量治理技术进行真正的标准化，提供非常通用的crd，去给社区进行一些使用。
八、服务治理趋势
1.治理管控
简单的总结一下服务治理的一个趋势，就是可以看到前面讲到了，无论是OpenSergo还是Sentinel，Java agent其实可以看到微服务的各种实现是非常多，非常复杂，但是需要的是一个统一的控制面，那所以控制面会一定会进行一个标准化，以OpenSergo为规范进行一个标准化的动作，同时会提供多种多样的数据语言，因为不同的框架，不同语言，它的实现可能是不一样的，所以会有SDK方式，java agent的方式，service方式，甚至将来有一天还会有一些探索，包括像一些ebpf的那些通过一个ebtf来进行服务治理的一些实现等等，那么这些不同的数据面，认为它是针对不同场景是有它的存在的价值的，所以数据面多样化，控制面标准化是一个趋势和一个判断。
2. 服务治理的领域
在服务治理的领域的话，也总结出了几个子的领域。包括开发态，包括了像服务的契约，服务的测试，服务的mock，还有一些日常环境隔离等等一些能力。
（1）、测试态，开发态
测试态，开发态，包括了这种自动化回归，流量的录制回放等等。
（2）、发布态
像还有发布这个过程，也认为是非常重要的一个指令，需要进行精细化治理的包括金丝雀发布，无损上下线，还全链路灰度等等。
（3）、高可用，安全态
还有高可用，安全。高可用提供了像一些离群实例摘除，就近容灾路由，限流降级，同az优先路由等等。
安全态也提供了这种服务鉴权，漏洞防护等等一些安全相关的一些治理措施。这是整个服务治理里面的一个趋势。
九、业内首本微服务治理技术白皮书
下面的话简单介绍一下阿里发布的一个微服治理技术白皮书，这本书，也是微服务治理团队经过了半年多以上的一个总结。它整理出来的一本非常有价值的书，把整个微服务治理的一个背景以及解决方案原理。场景化解决方案以及最佳实践都囊括在这本书里，以前目前已经在阿里云的开发社区上上线，供大家免费下载。且目前已经突破了一万加的下载。里面也有非常多的这种业界，就是一些客户的一些落地的实践，也有一些这种原理的介绍。
大概这里面内容已经有多达300多页，所以非常多的干货。欢迎大家去下载和观看。
十、AppActive
1.设计理念
接下来的话，简单介绍一下。在分布式应用治理领域非常重要的有另外一个模块。就是多应用多活容灾。我们也知道其实灾难是常态化发生的，近期会看到很多的这种云场上都会有，不论是国内的，国外都会有各种各样的一些不可预见的一些故障出现,那么当面临这样的灾难情况出现的时候。
是否有能力在非常短的时间内把应用的业务从某一个地方，迅速的切到另外一个地方，从而避免因为单个机房的在那造成整个业务宕机，那未来的话非常重要的一个能力。
所以在阿里内部，也在历年的双11打做的支持的过程中。也富化出来非常非常多的这样的多活容灾的理念架构，以及实践。所以通过AppActive这个开源项目，把这些最佳实践都通过开源的项目形式给释放出来了，也是今年一月份刚开始那个非常新的项目。
2.入口层
那么，在这个项目里面，也把其实多活容灾里面非常重要的几个组件都已经分开了，像入口层如何做到一个非常精准的流量的一个切换以及流量的隔离，就是会根据不同的切分原则，把不同流量引入的不同的机房，这是入口层。
3. 应用层
那么在应用层的话，也提供了非常多的切流的方案，就是说当一个在那发生的时候，通过中心化的控制台。把切流指令下发之后，在同一个机房内容可以迅速的把流量从a机房切换到b机房，那在应用内部也需要做快速的流量收敛，这个是针对不同框架，也做了一点实现支持，包括维护框架常见的 dubbo, spring cloud ,还有像消息还有数据库，这些在基础组件里面有非常重要的能力，帮助更快的把流量进行收敛。
4.底层
那在这个底层的话，也支持数据库之间的这种同步，所以不论是从网关入口到中间层以及到最后数据层都做了非常多的，这样的一些实践，把这些能力开放出来，开源的方式放出来也。也能够更好的构建业务的稳定性，这是AppActive。
十一、ChaosBlade
最后，也简单介绍一下ChaosBlade，ChaosBlade是一个故障演练的开源项目，是2019年开源的一个项目，目前在csa和cf那个3 boss的一个项目。
那ChaosBlade解决什么，解决的是在不稳定的环境下，知道那个系统都是不稳定的，如何通过一些提前的方式来发现一些问题，就是通过混沌工程这样一种技术的一种理念去常态化的去构建出一些不可知的问题，例如，常常会遇到各种各样的网络问题，系统的资源增长的问题，自盘满的一些问题，会针对在阿里内部的每年的是双11备战的时候都会进行这样的故障，各种故障的一些演练，然后把这样的一些场景模拟出来，再观察系统是否有问题，是否能够正确的应对，才能的一些场景。所以，这个项目是把这这部分非常丰富的一些场景。它进行了一个开源，同时，也支持了非常多的一个环境，包括非常多的一些语言，包括一些像java，golang以及虚拟机kubernetes 等多种环境下都能够进行非常方便的，进行故障演练，也可以通过很简单的一些命令行，能够实现这样的一些故障的模拟，同时，这些项目现在也跟非常多的开源生态做了一些结合，像下图右边的这些。
这些开源项目都有非常多的一些结合点，所以通过ChaosBlade把这样一个混沌工程的理念从开源的形式，结合起来。
把整个应用分布式应用治理的这个领域就更加的丰富了，所以刚才讲到了。跟OpenSergo，ChaosBlade，AppActive，以及Sentinel这四个开源组建了个分布式应用治理的一个核心能力。
