Dubbo实战经验分享与源码分析

第一次将分布式技术应用到实际项目中就遇到分布式事务的问题，好在不是那种严格要求双写一致性的事务问题。我了解的分布式事务解决方案有两种，分别是XA和TCC，今天要分享的是，我如何使用TCC处理项目中分布式事务问题。

服务雪崩，听到这个词就能想到问题的严重性。是的，整个项目，整条业务线都挂了，从该业务线延伸出来的下游业务线也跟着凉了。

项目不断新增需求，难免不会出现问题，特别是近期新增的增加请求处理耗时的需求。以及一些配置的修改而忽略掉的问题，如dubbo工作线程数调增时，忽略了redis连接池的修改。由于redis可用连接远小于工作线程数，就会出现多个线程竞争redis连接，影响性能。

线上某服务一直运行很稳定，最近突然就`cpu`百分百，`rpc`远程调用全部失败，并走了`mock`逻辑。重启后，一个小时后问题又重现。于是`dump`线程栈信息，但不仔细看也看不出什么问题。于是就有了一番排查历程。

笔者最近的一次重构项目选择用dubbo去实现服务间的调用，选择dubbo作为分布式的RPC远程服务调用框架，但笔者在使用的过程中遇到了很多疑难问题，网上搜不到一篇能解决我疑问的文章，无奈，只能选择自己从源码中寻找答案。

SPI全称是Service Provider Interface，直译就是服务提供者接口，是一种服务发现机制，是Java的一个内置标准，允许不同的开发者去实现某个特定的服务。Dubbo的SPI并非使用Java提供的SPI，完全是自己实现的一套SPI机制，并对其进行了增强，如通过字节码实现动态代理类。

dubbo通过BeanFactoryPostProcessor与BeanPostProcessor分别完成ServiceBean的注册与被@Reference注释的属性的依赖注入，通过BeanPostProcessor完成配置文件与相关配置类bean的属性绑定。

dubbo随机负载均衡的权重很少会用到吗？之前我想给随机负载均衡策略配置权重，各种搜索都找不到答案，包括翻阅官方文档。而且我们项目中用的还是最新的Nacos注册中心，非常无奈，最后只能在源码中寻找答案。

Dubbo默认使用随机负载均衡策略，据笔者了解，目前Dubbo一共提供了四种可选的负载均衡策略，有关于负载均衡策略的实现，如果不怕阅读源码枯燥的，笔者推荐阅读官网的源码导读部份的文档。

服务注册与发现是Dubbo核心的一个模块，假如没有注册中心，我们要调用远程服务，就必须要预先配置，就像调用第三方http接口一样，需要知道接口的域名或者IP、端口号才能调用。

由于我在实际项目中并未使用Redis作为服务注册中心，所以一直没有关注这个话题。那么，使用Redis作为服务注册中心有哪些缺点，希望本篇文章能给你答案。

本篇继续分析服务提供者发起一个远程RPC调用的全过程，也是跳过信息交换层和传输层，但发起请求的逻辑会复杂些，包括负载均衡和失败重试的过程，以及当消费端配置与每个服务提供端保持多个长连接时的处理逻辑。

在前面分析Dubbo注册中心层源码的文章中，我们知道，服务的导出与引入由RegistryProtocol调度完成。对于服务提供者，服务是先导出再注册到注册中心；对于服务消费者，先将自己注册到注册中心，再订阅事件，由RegistryDirectory将所有服务提供者转为Invoker。

Dubbo框架的传输层默认使用dubbo协议，这也是一种RPC远程通信协议。学习Dubbo，我们有必要了解dubbo协议长什么样，最好的办法就是从源码中寻找答案。

灰度发布是实现新旧版本平滑过渡的一种发布方式，即让一部分服务更新到新版本，如果这部分服务没有什么问题，再将其它旧版本的服务更新。而实现简单的灰度发布我们可以使用版本号控制，每次发布都更新版本号，新更新的服务就不会调用旧的服务提供者。