开发者学堂课程【Dubbo 3.0服务治理最佳实践：Dubbo 3.0 服务治理最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/967/detail/14888
Dubbo 3.0 服务治理最佳实践
6、邻近路由（同可用区的优先路由）
分别有两个作用：当出现某个可用区故障时，可以将故障的报障范围局限在当前的可用区内，同时可以做到流量的快速切流。另一个能力是当进行可优区优先调用，会对服务的RT会有所降低，从而提高服务的性能。
7、服务测试
使用场景:服务提供者开发完成，想要验证功能是否符合预期，本地写段代码，如果不止是阿里云上还有网络上的问题，导致测试成本非常高。
8、服务测试还提供了云上Consumer的方式，基于函数计算的能力，函数计算提供了秒级的执行能力，同时服务测试函数跑在安全容器中中，提供了安全性。同时具备细粒度权限控制。
9、服务 Mock
使用场景:
1.某段业务逻辑依赖某个服务，日常开发过程中，该服务应该不够稳定，需要一个稳定的mock数据供开发使用
2.链路压测时mock一些接口
Mock类型:
l 静态mock
l 异常mock
动态mock
三、Demo
下面将会通过开源的Dubbo3的Demo来演示开源的Dubbo3应用如何快速的具备服务治理的能力。
1、Demo部署架构
可以看出，从Ingress到DubboA再到DubboB再到DubboC。
应用如图：
可以看到这是Dubbo a, Dubbo b, Dubbo c，因为要演示，在这个过程中，对于B应用准备了两个deployment，Dubbo B Tag1和,Dubbo。对于C应用，是Dubbo tag2和Dubbo标签。一个是报异常服务的C应用。通过应用简单观察，提供的是如下：
[Hello, pswfrom ServiceA ip=172.22.0.220] -> [Hello, pswfrom ServiceB ip=172.22.0.218] -> (Hello, pswfrom ServiceC ip=172.22.0.109)
从上面可以看到，从A调到B应用调到C应用。
如何快速具备服务治理能力？
只需要在MSE的控制台，假设我们的应用是部署在K8s集群上，需要到MSE控制台，首先是选择集群，选择微服务治理，接着安装，安装微服务治理的plict；只需要在MSE控制台找到对应的命令空间，点击开启服务治理，然后当部署在K8s上的应用重启后就会自动的接入到MSE中，从而具备完整地服务治理能力。首先在MSE上找到已经接入Dubbo3的应用，可以看到Dubbo3的a,b,c三个应用，点击进入，可以看到Dubbo3-a是一个consumer，提供了Hello-b的服务，消费者是Dubbpo3-a的应用，同时提供了完整的原数据，Dubbo的一些mate date信息，以及接口的原数据。同时可以直接在控制台对于相关的服务直接配置超时时间。
接着演示全链路的标签路由的能力，看Dubbo3的应用，首先应用是如何打标签的？
首先tag1只需要选择deployment ,spec，templote，metadata， annotations中加入tag1，加上标签就可以在MSE控制台看到对应的标签以及它的实例，可以对其配置一些规则。比如：现在要配置一些规则，通过是否链路透传按钮，可以实现全链路灰度的能力，可以配置方法，比如，选择Service, say Hello方法，选择第一个参数等于tag1，当请求参数中，第一个参数等于tag1，就会走tag1的服务。tag1是161节点，
当输入47.100.253.16117080/sayHiello/psw，可以发现是随机调的，当输入47.100.253.16117080/sayHiello/psw是不满足条件，运行的是未达标的节点，是218和45；当输入tag1时，流量就是满足tag1的流量，运行的是161。
有报错是因为注入了一个服务，后面在进行解决。可以看出这样会使得服务质量低下，可以看出当输入是tag1时运行的都是tag1的机器。同理，对Dubbo-c 配上tag2的规则，就会运行tag2的服务。
总结：首先在应用上打上标签，在annotation上加上对应的tag，就可以在对应的控制台看到对应标签的分布，接着添加规则。预期是，当流量符合预期时走tag1，配置规则后就能进行验证，这就是标签路由的能力如下：
47.100.253.161:17080/sayHello/tag1
运行结果：
[Hello, tag1from ServiceA ip=172 22.0.220] -> [Hello, tag1from ServiceB ip=172.22.0.161]->[Hello,tag1from ServiceC ip=172.22.0.109]
在这一过程中不需要修改任何代码和配置，只需将应用接入MSE服务治理即可。
第二块，47.100.253.161:17080/sayHello/psw，由于后端节点返回异常，导致整体链路服务质量低下。通过脚本如下：
while:
do
result=’curl $1 -s’
if [[‘$result’==*”500”*;then
ecno ‘date +%F-%T’$result
else
ecno ‘date +%F-%T’$result
fi
sleep 0.1
上面的代码执行的情况，可以看到每次调用都会有30%的概率报错，假象如果只有Dubbo C服务的某个节点出现问题，某个应用的某个节点出现问题就会影响链路的成功率，并且影响非常大。当规模过大时，这种情况是在所难免的。
当情况在恶劣些，比如Dubbo a 或Dubbo b或者更多地方出现了单点问题，服务成功率是如何保证。MSE提供了离群服务摘除的能力，所有的能力无需任何代码的修改，只需在控制台配置规则即可。打开规则，观察原理规则，是配置在Dubbo3上，调用下一个应用中就会检测成功率。如果当某个节点的成功率达不到预期，就将其进行摘除，也有许多参数进行配置。
当客户端调的过程中，发现某些节点的服务质量不符合预期，就会对它进行摘除。接着观察监控，可以看到，这过程中发生了离群实例摘除的动作，这过程中有许多异常，但当功能生效后就会异常就会下去。将配置规则后，故障的节点就会被离群摘除自动识别，然后隔离掉。当关闭后，就会恢复调用，错误率就会马上回来，回到原来的30%，这就是离群实例摘除功能。
标签路由以及离群路由等摘除治理能力，下面讲解开发态一些相关的能力。比如：服务契约、服务测试；
2、服务测试
MSE除提供了以上的能力还提供了测试态的能力。演示：先找到Dubbp3的服务，找到应用，可以在服务应用平台中搜索Dubbo3相关的服务应用，选择一个减量进行测试，可以看到，对于Dubbo的Plotvadou，只需在控制台就能测试，返回预期的结果。可以选择换个IP，可以看出跟云上的ploysmen很相似，还有历史的执行结果。
代码如下：
Array [1]
0:psw
同时这一块还有完整的Dubbo监控数据如下：
同时，监控也支持Dubbo的服务，都是无缝兼容，无缝支持的，提供了一系列完整的一些监控，
四、 钉钉 Dubbo3.0 的实践与云原生网关内部落地案例
1、Dubbo3 在网关场景下的金丝雀发布
这块能力其实内部已经是在钉钉落地，并且，云上是支持的。
（1）可以看到云原生网关加Ingress与API网关二合一，从而降低了整体的成本。
（2）通信协议使用Dubbo3.0的Triple协议，网关转发性能高，无协议转换开销
（3）云原生网关为接入网关的Dubbo3.0的服务提供金丝雀发布能力，提升用户发布的稳定性
（4）云原生网关治理中心与MSE服务治理中心打通的，只需在MSE服务治理中配置金丝雀发布的规则，整个网关都是支持的，都是打通的。可以提升整体的用户体验。
2、
3、从上面可以看出，云原生网关支持流量按照百分比规则的方式来路由，后面这块是无侵入的服务治理能力的增强，金丝雀发布的能力，所有的Dubbo使用的注册能力使用的是MSE的注册中心。
4、钉钉Dubbo3.0实践&云原生网关内部落地案例
背景
l 钉钉的公共服务部署在公有云VPC ，部分依赖的数据服务部署
在内部，内部与云上服务存在RPC互调的诉求，即属于混合云的典型场景
钉钉核心诉求
l 采用开源方案，方便后续业务推广
l 网络通信保障安全性
业务升级改造成本低
方案核心点
l 全链路采用开源Dubbo3.0 ，云原生网关默认支持Dubbo3.0，
实现透明转发，网关转发RT小于1ms
l 利用Dubbo3.0支持HTTP2特性，云原生网关之间采用mTLS
保障安全
l 利用云原生网关默认支持多种注册中心的能力实现跨域服务发现
对用户透明，业务侧无需做任何额外改动
l 业务侧升级SDK到支持Dubbo3.0, 配置发布Triple服务即可，
无需额外改动
相关的服务治理能力是通过MSE无侵入的方式来支持的。
