小道仙的后宫

本文探讨了在UAT环境下实现Dubbo灰度调用的实践方案。通过parameters参数标记服务版本，利用Servlet Filter从HTTP请求头获取灰度标签并存入ThreadLocal。自定义Dubbo Filter实现标签在消费者和生产者间的透传，最后通过自定义Router基于标签选择服务。关键点在于：1) 服务打标区分环境；2) HTTP到RPC的标签传递；3) 调用链路的标签上下文管理；4) 基于标签的服务路由。该方案实现了UAT环境调用本地服务(DubboA→DubboB1→DubboC)的灰度

本文探讨了Dubbo与Nacos集成的关键机制，重点分析了服务注册和发现的过程。在服务注册方面，Dubbo通过自定义监听器触发注册流程，并建立了客户端心跳检测机制维护服务可用性。服务发现部分详细阐述了消费者如何通过接口定义获取提供者URL并创建Invoker的过程，包括服务URL匹配、Invoker生成及更新等核心步骤。文章通过源码分析揭示了Dubbo与Nacos集成时应用级注册的具体实现，为理解微服务间通信机制提供了实践参考。

Dubbo底层通讯是基于Netty，请求第一步肯定是从Netty收到消息开始的。Netty收到消息也肯定是不是明文的，这一节要解决如下问题Netty接收消息的入口如何把消息解析成明文怎么通过消息找到对应的服务

基于@EnableDubbo > @EnableDubboConfig 找到每一个@DubboReference 生成代理对象生产的代理对象是一个嵌套对象，里面有两个重要的对象分别是 MigrationInvoker、CallbackRegistrationInvoker。

最近在做配置文件升级，服务比较多，之前的Dubbo配置各个服务写的比较乱，有的用Nacos上的 data-id，有的又是在自己的服务引入配置遂准备统一了，全部都用Nacos上的配置，同时修改了Dubbo服务名发到线上的时候，线上崩了，部分服务出现如下错误注： IP和服务名做了隐藏处理。

对于Dubbo用的最多的就是@DubboService、@DubboReference，与之对应的就是服务的提供方、调用方。之所以加上注解就可以运行，定是生成了代理对象，这篇文章就来讲讲如何基于这两个注解生成代理对象。不管是服务端还是客户端，在使用Dubbo的时候都会先使用，比如下面的demo@EnableDubbo 是一个组合注解，它头上还有@DubboComponentScan和@EnableDubboConfig，它们就是分别来解析@DubboService、@DubboReference。

Dubbo是支持多协议的，它默认的Dubbo协议已经很好了，正常情况下，使用Dubbo是做服务之间的通信是不需要更换协议的。比如有两个服务的提供者提供相同的服务，可以给它们打上A、B标签，请求的时候可以根据标签去固定请求对应的服务。默认的协议就是 dubbo，所以在使用的时候不需要指定协议，如果使用其它协议需要指定对应的协议。Dubbo不只是作为服务间的通讯，它还涉及服务治理，今天就来一起学习下Dubbo的控制台使用。原本的dubbo协议是不需要提供路径的，现在的HTTP需要提供路径，改造如下。

基于Dubbo3.2.9、Nacos2.3.0、SpringBoot 2.7.17、Dubbo-Admin 0.6.0、Jdk1.8 搭建的Dubbo学习Demo。