开发者学堂课程【2022阿里云云原生中间件开发者大会集锦：微服务治理技术白皮书重磅发布】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1053/detail/15298
微服务治理技术白皮书重磅发布
内容介绍：
一、微服治理技术白皮书简介
二、全书目录导读
三、微服务治理技术原理介绍
四、P Java Agent 治理技术
五、如何构建生产级的微服务架构
六、《微服务治理技术白皮书》研读班和音频版发布
一、微服治理技术白皮书简介
提到微服治理，可能大家都感觉并不陌生，在微服务已经大行其道的今天，大家也越来越更加认同这一点，那就是微服在生产落地的时候，离不开微服治理。
但是大家对微服务治理的认知确实五花八门，各不相同，并没有一个统一的标准和共识。历经了半年多的筹备，在2022的4月13日发布了这本长达379页的微服务治理技术白皮书。
1.特点
这也可能是业内手本聚焦于微服治理业务领域的白皮书。希望通过这本书，能够对高效的解决原生架构下的微服治理难题起到一点点的作用。
（1）、这本白皮书里面的内容，它不仅包含了阿里巴巴电商体系十余年的为辅自理经验.
（2）、同时，也是吸收了很多阿里云微服引擎mse产品.
（3）、它所服务的各行各业云上客户所沉淀下来的经验，可以说是一本集大成者书.
（4）、不同于一些警句教育微服务治理技术原理的书籍，这本白皮书还难过了业务场景解决方案最佳实践。
（5）、这些微服务落地的全流程，不仅仅是一本深度分析微服务治理技术的书，更是一本解决微服务落地生产相关难题的书。
（6）推荐从事微服务领域的这些开发。运维。测试，稳定性以及产品设计的同学都去阅读此白皮书，
2.主要内容
今天分享的内容主要包含四个部分。首先是全书目的导读，然后是微服务治理关键技术的分析，以及如何构建生产级别微服务，最后是微服务治理的两个典型场景的详细分析。
二、全书目录导读
首先看全书目录，这一部分全书主要包含了六章。
1.微服务治理背景和趋势
第一章主要介绍了微服务治理技术的概念，从一家企业的it发展历程视角阐述的微服务治理的必要性，同时，也分析了微服务在云原生时代下的发展趋势和新的挑战。
2. 微服务治理发展历史
第二章，主要是介绍微服治理的底层技术的发展和变迁，详细的阐述的恢复治理是如何向透明化和业务无侵入方向发展的。
3. 微服务场景解决方案
在第三章中整理和归纳了微服务架构中常见的这些痛点场景，首先描述了这些痛点产品什么情况下会出现，以及它出现之后的影响面是什么，然后再去深入分析可以通过哪些技术方案去解决这些问题，最后，才详细的介绍，该解决方案一下的底层技术实现。
4. 解决方案最佳实践及客户实践案例
那第四第五章，，主要是基于说，阿里云的微服务引擎mse产品，云上的客户它去解决这类微服务治理技术难题的时候一些最佳实践，以及一些标杆客户的案例分享。
三、微服务治理技术原理介绍
再来看一下微服务治理技术的发展与变迁，下面这张图片，它展现的是阿里巴巴集团内部的一些微服务治理技术的变化的历程。
1.2008
最开始，阿里内部也是使用时独立开发各种中间件SDK的方案去推进微服务，在阶段，经常遇到的问题就是各种SDK的依赖冲突非常严重，甚至还会出现因为依赖冲突，而是导致无法启动的情况。
而且在时候，因为SDK是在业务代码里面去引入的，所以说当出现这些依赖冲突问题时，需要去升级SDK去解决这些问题，这时候升级的成本也是非常的高。
2.2013
后来，阿里内部是使用了潘多拉（pandora）轻量级容器来实现类的隔离和类的导出，解决了依赖冲突的问题，从而提升了运维和治理的效率。反正这里面。
提一下潘多拉的一些基本原理，就是当使用潘多拉之后，中间件代码并不是直接由业务开发包引入的，而是从潘多拉容器里面导出业务代码里面，只需要引入一个空实线的SDK就可以引入中间件的逻辑。
在时候，一些小的变更其实只需要去直接升级潘多拉的版本即可，但是在中间件出现重大升级的时候，这时候还是会需要去升级这些SDK的，同样这也需要修改代码逻辑，会影响到开发和运维整个流程。
3.2019-
于是，在2019年的时候，推出了基于One Java Agent这样的微服务治理技术。把微服务治理的关键逻辑都是放在了Java Agent中，是在应用的运行时，去动态的修改恢复的框架的关键类的一些字节码，这样的就能实现微服治理逻辑和业务开发完全隔开，不需要去修改任何业务代码就能够享受完整的微服务治理技术。
四、Java Agent 治理技术
再来详细看看Java Agent的微服务治理是如何实现的，前面已经提到过，将微服治理下沉到Java Agent之后，在应用开发实施完全无需感知微服务治理技术的。
只需要使用开源框架的标准用法，比如说spring cloud，或者说dubbo标准的方式去开发应用即可，那么在运行时只需要使挂载上Java Agent就可以直接实现微服务治理，其实在过程中，就是挂上Java Agent之后，内在加载的过程中可以去动态的修改这些框架的关键字节码，比如说服务注册，服务发现，运营选址，运营均衡这些关键的过程。
举个例子，比如说在服务注册的时候，可以去加上一些额外的信息，或者说是在服务路由的时候，可以加流量特征和路由规则进行一个比对等等，通过方式来去实现一些维护治理的功能。
同时Java Agent还可以通过一些监听配置，上报数据的方式去动态的获取服务治理的规则或者是上报一些max关键事件等信息，从而实现提到的像无损伤下线，离群实例摘除，限流降级，服务鉴权等这一系列的治理逻辑。
这里提一下，就是one Java Agent项目其实是已经开源了，可以去登录github。在阿里巴巴github下可以找到one Java Agent项目去了解更多的详情。
那综上所述其实就已经了解了 Java Agent是如何去实现完全无业务侵入。开发零感知，而且是零升级成本的这么一个微服务治理。
五、如何构建生产级的微服务架构
在介绍完微服务治理的关键技术和发展历程之后，相信已经更加深刻的了解到微服务的生产落地是离不开微服务治理的保驾护航的。围绕云原生下的微服务趋势，认为微服务治理应该更加专注于提升开发迭代效率以及增强稳定性，其中增强稳定性的又包含了变更式的稳定性和偶发异常下稳定性，还有业务安全。
由于时间的原因，没有办法在这一次的分享把所有能力都一一展开叙述。据统计百分之九十以上的线上故障的都是因为变更引起的，所以主要介绍的是变更手稳定性的重要功能无损上下线，还有全链路灰度。其它功能更多的详情请大家直接去阅读微服务治理技术白皮书。
1. 无损下线解决方案
（1）、下线问题
首先来看一下无损上下线功能详细的分析，在分享无损上下线之前，先提一个问题，是不是在业务代码完全没有问题的情况下，只是发布就一定不会出现任何问题？很遗憾的告诉大家，答案是否定。即使是在业务代码，没有任何问题的情况下发布的过程中，也还是有可能会出现影响业务的报错的，这也是为什么经常在变更的时候一定是要选择大半夜的方式去变更的一个原因。
（2）、下线过程
无损下线，其实就是在过程中，一个非常典型的场景，在微服务的框架中，服务提供者从开始下线到服务，消费者最终感知到节点已经下线，不再去发起调用，是有一个过程的。过程持续的时间虽然会因为微服务框架本身的实现有不同的的差异，但是基本都是比较漫长，比如极端的情况下，是spring cloud，meetup ，再加上demo负载均衡。最差的情况下要90秒，这里面一些详细的分析，比如说有karaka的注销动作，它的最长延迟是30秒，与karaka服务资源的中心之间的相互同步，最长情况下也是30秒，而ribbob缓存默认的刷新时间也是30秒，加起来一共就是90秒。而在这90秒的过程中，服务消费者都会持续不断地去调用已经下线的节点，从而导致一些出现的影响业务的一些报错，这也是为什么很多人都只能是在半夜发布。
（3）、推荐方案
在微服务治理技术白皮书推荐的解决方案中，是提供了一个afround命令。可以在真正的停止之前去执行一下afround命令，那么服务提供者在收到afround 命令之后，它首先是会提前去注册中心，把自己注销掉，同时，还会去跨过注册中心，直接点对点去通知服务消费者，已经进入下线流程了，很快就要下线了，消费者这边尽快去刷新自己的消费者列表，并且剔除掉，这样，其实就实现了无损下限中非常关键的一点，即尽早地摘除掉所有流量。
（4）、注意
除了点之外，其实还有一点是比较容易被忽视的，那就是如何确保在途的请求都处理完毕。这里面其实主要的考量是怎么通过库克方式来进行一个智能的等待，比如说还有请求没有处理完，那再停止之前的，需要等待更长的时间，等到所有的赞同请求都处理完毕之后，并且是已经返回了，这时进入真正的销毁流程。
这样就是说结合一个无损下限的方式。那在发布的过程中，老的应用节点在停止的过程中，是不会出现影响业务的报错。
2. 无损上线
那说好了无损下线，再来看一下无损上线。其实上线和下线在发布过程中，它都是一个连贯一起的动作。同样，上线的过程中，其实也是有很多坑的。
（1）、屏蔽报错
首先相信很多人可能遇到过问题，就比如说有一些readiness的连接词或者数据库的连接词，在刚启动的时候，连接词还没有建立好的，这时候流量就已经打过来了，那时候就会直接出现影响业务的一些报错。
方式，可以通过无损上线解决方案，去提前把数据库的连接词也好，readiness接连词也好，去通过Java Agent技术直接扫描出来，去提前进行一个预建连接的动作。连接的动作从而去屏蔽了第一次请求过来一定出现报错，问题。
（2）、小流量预热
当然这里面也有人会提到说，只知道拥有一起来浏览过来有很多报错但是没有办法找到具体是哪个原因导致它报错，这时候还有就是另外一个方式，可以看到下面图里面的，右边的倒数第二个小流量预热方式。
就是说在微服务治理技术中，可以通过Java Agent技术去对新起来的一个服务的权重进行一个调节。新起来应用，它的权重是比较小，然后经过一段时间预热之后，它才到了一个是和老节点是同样比重的状态，这样可以选择一个流量曲线，比如说是一个二次曲线，这样慢慢的上来，从而达到一个小流量预热方式。那刚启动的时候k8s可能只有只有一不到，然后最终才慢慢到一个平稳的状态，这个时候是通过这种方式，小流量预热方式就是一个比较通用化的方案。
比如刚才其它连接词，或者说一些JAVA的类加载的一些没有开启并行类加载导致的延迟，或者说jvm本身的一个jit编译优化这么一个流程。
（3）、k8s的readiness和微服务系统打通
都是可以通过小流量运动的方式来去解决的，现在已经进入了云原生的时代，其实k8s的readiness的检查和微服务框架的ready其实默认情况下是没有打通的。
举个例子，如果说没有配置一个k8s的readiness，是进程启动之后。认为已经是ready会进行滚动发布，直接进入下一批了，但这时候微服务其实并没有启动成功，这样会造成一个什么后果？就是说新起的节点还没有注册到注册中心，那老的节点，就直接被停掉了，这就会导致在过程中，注册中心是没有任何服务提供的节点存在的，这也是一个比较严重的情况，需要做到一个k8s的readiness和微服务的readiness进行一个打通。
当然微服务本身的readiness打通，其实它也是一个非常复杂的流程，比如说这里面会涉及到服务有没有注册到注册中心？或者说自己写的readiness是健康检查？
甚至是刚才提到的服务预约，有没有预热完毕，这样一个非常繁琐的一个过程。在微服务治理技术白皮书推荐的解决方案中，是通过Java Agent技术，然后去实现了这么一个controller，controller逻辑它是会去自动检测原有的readiness接口是否OK，以及的服务是不是真的已经注册了注册中心，包括的tomcat服务提供者它的端口是不是已经都是在监听的状态，以及上面提到也可以跟服务预热的状态进行一个挂钩。这样就说实现了这无损上线。
在无损上限和无损下限相结合的情况下，是解决了一个大问题。或者说已经得到一个保证，保证就是如果说这一次新发布的代码没有任何问题的话，那就可以放心的去进行这次发布了，不会因为应用的停止或者启动过程中导致出现问题，那这样的话，也可以不需要说是等到到大半夜去发布及时白天发布的话，也不会对用户的体验产生多大的影响，当然，这里面需要保证的是写的代码没有任何问题。
2. 全链路灰度解决方案
（1）、逻辑异常影响
现实依旧是残酷的，没有有人敢拍着胸脯说，这次写的代码一定没有任何问题，所以说新发布的业务代码中存在一些逻辑异常是常态。如果说没有任何技术做保证的话，假设一个应用有四个节点，那发布其中一个节点，那这一次如果是出现了问题，那对业务的影响面就是25%的流量，甚至有可能是直接影响25%的用户，影响面是常大的。那有没有办法去控制新版本发布所有的影响面？
（2）、全链路灰度解决方案
在这里面需要借助的技术就是全链路灰度解决方案。因为现在都是云原生时代，这里就以云原生时代的k8s去部署一个新的应用为例，详细说明全链路灰度的解决方案是怎么实现的？
在发布一个新版本的时候，给新版本打上一个它的版本标签，那么在微服务的提供者在注册到注册中心的时候，会把它的版本标签直接注册到注册中心中。这时候服务消费者去获取服务提供的列表的时候，是可以直接从注册中心不仅获取了IP和端口，还可以获取到这些IP和端口对应的服务提供者它所被打上的标签，那时候再结合Java Agent的技术，它可以去从治理中心的，配置下发方式去获取到灰度的规则，比如说这里面举的例子就是说hav请求它的header里面是user ID字段除以100等于20的，这些用户它才会遇到新版本。那时候可以说是用一个特殊的方式引了1%的流量进来，而且这1%的流量还是固定的，就是user ID字段除以100等于20这一批用户可以进来。如果说没有配置任何的灰度规则的话说。所有的流量，它一定会去没有打标的稳定版本，也就是说如果没有配置的规则的话，那么不会有任何的流量去新版本，只有在配置规则，并且规则是打开的情况下，这些符合规则的流量才会到新版本，所以这个情况下，新版本发布流量，是非常可控的。
比如说咱们可以进行一个设置，就是只有内部的用户它才会被录入到那个新版本，随着发布的时候可以做一个非常灵活的验证。
如果验证不通过怎么办？那也比较简单，只需要简单的把路由规则给关闭，那么时候就不会有任何的流量去灰度的版本，所有流量都去稳定的机械版本，如果是验证成功的，后面的就可以去把原来稳定的depioyment去换成新的景象。这时候就可以做到一个非常可控的方式了，就是说只要不配规则，新版本不会影响任何用户。
如果发现的规则有问题，影响的部分用户，那只需要简单的对规则进行一个关闭动作，所有的用户又会到一正常的稳定版本的流量中去。这时候，通过全链路灰度方式，就做到新版本发布是完全可控的，这里面推荐给大家推荐一个最佳实践，一开始的时候规则配的一些内容就是一些内部用户，它才能访问的新版本，当新版本之后，内部用户才能访问新版本，内部用户已经验证通过了，那可以对规则进行一个修改。不仅是内部用户，这时候还可以引入固定的1%的用户的流量进来。在这个过程中，如果验证通过了，根据业务需要，开始继续扩大灰度范围，还是直接进行一个全量发布，那时候就是一个非常稳定的状态了，可以做到即使白天也可以放心的发布，因为发布一个新版本只是影响内部的用户，内部用户通过之后，逐步的扩大运营量，即使出现任何问题，也可以做一个秒级的回滚。
所以说，结合上全链路灰度和无损上下线这两个方案在一起的时候，基本上是已经可以消除变更过程中的稳定性风险。因为时间的原因，这里并没有对全链路灰度，全链路这点做一个非常深入详细的介绍，这里面其实指导的，全链路也就是说如果调研练是从网关过来到a到b到c，这么一条链路的话不只是说一个灰度流量过a的灰度版本，它在到b到c的时候也应该去灰度版本，甚至是发现b如果它没有进行一个灰度，只有一个稳定版本的情况下，A的灰度流量可能先去b的稳定版本，但是它去下一跳，去c的情况下，它还是要重新进入灰度的c的版本，这样才是一个全链路的解决方案。
3.全链路灰度应用场景
当然全链路它是一个非常基础的技术。除了可以用在发布中的全链路灰度化，其实也可以把它放在其它场景。
（1）、开发/测试环境隔离
比如说开发测试环境的隔离，都知道在敏捷开发的过程中，一个迭代可能是由多个功能是在并行开发的，而且在过程中，是很多不同的同学分别去开发不同的功能，那时候，抢环境一定是很多同学都遇到过的一个问题。那如何解决抢环境这个问题？
那最简单的方式当然就是大家都有一套完全独立的环境，最简单的实验方式，就是物理隔离，当然大家也知道物理隔离成本是非常的高的。
（2）、全链路灰度
那这时候如果说结合到刚才提到的全链路灰度应用，那可以做一个逻辑上的隔离。对于这些开发小的来说，是可以用一个非常低成本的方式让每一个开发小额都有一套属于治理的独立的环境，那这时候是用一个第低成本的方式去实现敏捷开发。
（3）、全链路压测
那再来看一下另外一个场景，就是全链路压测，如果想要直接用线上的环境进行压测的话，风险是非常高的。那如果使用测试的环境进行压测，也会存在另外一个问题，测试环境跟生产环境，毕竟还是有区别的压出来的结果的还是可能偏差比较大，那这时候可以通过全链路压测，结合全链路灰度这两个方式去做一个整合，让压测流量都是去到数据库的影子表，然后缓存是比如说redis有一个影子key，消息可能有一个影子topic。通过方式直接使用线上环境去做一个非常安全的压测，可以被实现不仅是零成本机器，零成本维护，而且是一个非常真实有效的压测数据。
4.全链路灰度解决方案
当然，刚才提到全链路，它其实涉及的还是很多的，不仅是刚才提到的数据库，缓存消息，还有一些像前端，网关，分布式任务调度，这些都是有着需要去做全，那才是全链路。包括提到的还是需要有一个完整的配套设施，比如说规则配置，规则同步，一个秒级的可观测能力，以及留控大盘，通过方式完整的整合在一起，那才是一个真正的全链路完整的解决方案。
六、《微服务治理技术白皮书》研读班和音频版发布
1.交流群
以上就是关于无损上下线和全链路灰度两个解决方案的一些详细介绍，当然还是那句话，因为时间的原因，很可惜没有办法去进行一个更多的详细介绍。可以去访问分享中的链接去直接下载微服务治理技术白皮书，对更多的场景进行一个阅读和了解，也欢迎后续通过钉钉群或者是其它方式找到来一起进行交流。
2. 研读班和音频板
微服治理技术白皮书于4月13日发布之后，在短短的两个月内下载量就突破了一万，这也是开发者对这本电子书的质量的认可，也有更多的动力去提供更好的阅读体验，因此今天正式发布微服之力，技术白皮书的研读班和音频板，通过微服自理技术白皮书的研读班，可以以线上训练营的方式去分步骤按重点的进行打卡，利用碎片化的时间参与班主任伴学和同学们，一起共同讨论，共同晋级成长，在训练营结束后还将颁发阿里云官方的结业证书，从现在开始，就可以扫描屏幕中的二维码，参与进阶班了，同时除了阅读电子书，也联合喜马拉雅对微服务治理技术白皮书进行一个有深化的运营，推出了白皮书的音频版，可以更沉静的方式，去学习微服务治理技术，只需要下载打卡喜马拉雅APP扫描上图中的二维码，或者搜索微服务治理技术白皮书，就可以直达音频版的界面了。
