【探索Spring Cloud】SpringCloud与RPC

前言

最近想把Dubbo跟SpringCloud整合，但是总觉得有些别扭。总是纠结在一个问题上：到底是SpringCloud整合到Dubbo里面了，还是Dubbo整合进SpringCloud了？归根结底，这个问题，其实就是谁适配谁，按照谁的风格/标准来整合的问题。因此，有必要先来缕缕SpringCloud的设计。

RPC

Remote Procedure Call，远程过程调用。什么意思呢？我们来解读一下：
1. 远程：意味着服务可能不在同一个进程内。
2. 过程：完成特定目的的一段服务程序。
3. 调用：存在两个参与者：调用方、被调用方。
合起来，就是，调用方所在的程序发起一个请求，让被调用法完成特定目的的一个服务。

• 但请注意，这并不是RPC的完整含义，RPC还要求要想调用本地代码一样方便的执行调用。就好像调用本地的服务方法一样简单。

怎么实现RPC

我们从一个问题入手：完成RPC调用，需要做什么？

1. 我们需要知道远程服务的URL
2. 如果调用失败了，应该怎么处理

现在再加上我们刚才提醒大家注意的一点：像本地调用一样简单方便。这意味着我们需要进行封装，把众多的调用细节藏起来。于是我们可以想象一下：

是不是可以自动的寻找服务地址 —— 服务发现

如果找到有多个服务实例，是不是可以自动选择服务实例 —— 负载均衡

如果调用失败，是不是可以指定处理失败的逻辑 —— 服务降级->断路器

除此之外，我们得有超时机制吧？是不是失败重试也得跟上？那要不要在运行过程中直接改这些配置呢？例如改超时时间？重试次数？==> 配置中心

诶，大家有没有发现，这些问题/需求都是从RPC调用长出来的？SpringCloud推出的恰巧推出了对应的工具给我们使用。

Spring Cloud

先看看官方自己的声明

Spring Cloud 为开发者提供工具，在分布式系统快速构建一些常用模式。（例如，配置管理，服务发现，断路器，智能路由，微服务代理，控制总线，一次性动态令牌，全局锁，领导选举，分布式session，集群状态管理）。
分布式系统的协同导致了锅炉板模式，开发者可以通过使用Spring Cloud，快速建立实现这些模式的服务和应用。在分布式环境中，包括开发者的笔记本电脑、裸金属数据中心，以及像Cloud Foundry这样的管理平台，都能很好地工作。

重点解读：

• 为微服务提供一系列工具，解决微服务中的各种问题。注意，不仅仅是RPC。RPC只是微服务的一部分。

再来看Features，来看看主打的特性：

特性	描述	提供者
Distributed/versioned configuration	分布式/版本配置	Spring Cloud Config and Spring Cloud Alibaba Nacos
Service registration and discovery	服务注册与发现	Spring Cloud Netflix Eureka and Spring Cloud Alibaba Nacos
Routing	路由	Spring Cloud Gateway
Service-to-service calls	服务调用	Spring Cloud Open Feign
Load balancing	负载均衡	Spring Cloud Loadbalancer
Circuit Breakers	断路器	Spring Cloud Circuit Breaker and Spring Cloud Alibaba Sentinel
Global locks	全局锁	Spring Integration
Leadership election and cluster state	领导选举和集群状态	Spring Cloud Cluster
Distributed messaging	分布式消息	Spring Cloud Bus and Spring Cloud Stream and Spring Cloud Alibaba RocketMQ

题外话：
Spring Cloud Netflix原本有丰富的组件：Eureka, Hystrix, Ribbon,Zuul, Archaius. 在Spring Cloud的Main Project可以看到描述。但跳转到Spring Cloud Netflix之后，只剩下Eureka了。就连Feign，也是Spring Cloud捡起来自己维护，整出来OpenFeign。倒也算不幸中的万幸，毕竟之前Spring Cloud Netflix全部陷入维护状态，挺糟心的。

Spring Cloud Alibaba

官方声明

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

解读：愿景与Spring Cloud一样，并且背靠阿里，还提供了Spring Cloud没有能力：

• Seata:分布式事务解决方案
• SchedulerX: 分布式任务调度
• Cloud SMS：阿里云短信服务

然鹅，有意思的是，Spring Cloud Alibaba 2022.x的介绍里，没有服务调用。即使是组件一节，也看不到阿里系的Dubbo。
关于Dubbo的去留，社区是有讨论过的：
Spring Cloud Dubbo组件去留问题讨论#2398
我的个人看法是，Dubbo本身就是要打造成为一款微服务框架。不管是将Dubbo适配到Spring Cloud还是将Spring Cloud适配到Dubbo，虽然都能够实现，但是维护成本是个问题。相当于同一个项目，要维护两份代码。而心中有更大天空的Dubbo都已经全面接入Istio了，难道还要考虑那些功能可以整合到Spring Cloud？想了解更多关于Dubbo与其他框架的区别的同学，可以自己参考文章：与 gRPC、Spring Cloud、Istio 的关系

PS: 虽然Spring Cloud与Dubbo是在同一个层面的东西，但是不妨碍Spring Cloud整合Spring Boot。

Spring Cloud的抽象

众所周知，Spring以良好的可扩展性著称，这得益于Spring强大的抽象能力。Spring Cloud也不例外。

Spring Cloud Commons

SpringCloud的抽象都定义在这个包下

于是，我们找到了RPC常用的几个组件的抽象：

1. 断路器：org.springframework.cloud.client.circuitbreaker.CircuitBreaker
2. 服务发现客户端：org.springframework.cloud.client.discovery.DiscoveryClient
3. 服务注册：org.springframework.cloud.client.serviceregistry.ServiceRegistry
4. 负载均衡客户端：org.springframework.cloud.client.loadbalancer.LoadBalancerClient
   额，总感觉少了什么。对，服务调用客户端。为什么呢？以Feign为例，他可是要为所有FeignClient的接口生成代理对象的。因此，如果要制定标准，那可太复杂了。怎么发现PRC接口、怎么生成代理对象、怎么发起远程调用。这简直不亚于定义一个框架的标准。从这个角度看，Spring Cloud有点为RPC调用提供工具的意思。

总结

1. 不管是Spring Cloud还是Spring Cloud Alibaba，愿景都是做微服务框架。而Spring Cloud Alibaba针对Spring Cloud的这些功能/抽象能力提供具体实现。
2. 微服务必然是建立在RPC的基础之上构建的，必然包括RPC。但注意，微服务不止RPC，因此Spring Cloud也会提供除了RPC以外的，与微服务相关的工具。例如：路由网关、分布式任务调度等等。

后记

今天算是开了个头吧。下次，咱们从OpenFeign来看看，他是怎么整合loadbalance + circuitbreaker + discoveryclient的。如果你嫌弃OpenFeign基于Http协议太慢，想自己开发RPC组件，并利用Spring Cloud的这些抽象组件，整合这些能力。那你不容错过。 下次咱聊聊服务发现。