基于Dubbo Spring Cloud的架构分享

基于Dubbo Spring Cloud的架构分享

前言

在采用Spring Cloud+Dubbo的技术体系以后，几种架构方案和大家讨论下。

普通Spring Cloud采用Feign作为微服务调用

上图是采用Spring Cloud Feign微服务调用的简单架构图。流量网关负责分流通常采用Nginx或其他API网关，不在我们今天讨论的范围内。微服务网关负责将不同的Http流量转发到对应的微服务中，同时处理安全认证等方面的事情，一般采用Spring Gateway 或者 Zuul。下游的服务1,2,3则按照MVC写法，Controller 、Service、 Dao。对外提供Feign接口。下游服务之间的调用也采用Feign调用。

接入Dubbo后的Spring Cloud调用关系

上图，接入Dubbo协议以后微服务网关往下调用的时候还是Http协议，只不过下游的微服务之间的调用改为了Dubbo调用。这种架构看似没什么问题，但是只在微服务间采用Dubbo协议，感觉没什么必要，1、微服务间的调用在某些场景可能并不是那么频繁。2、微服务网关到下游服务依旧采用http协议，这样RPC的优势并没有完全发挥出来。

所以产生一种想法，微服务网关可否对上承接HTTP协议，对下转到DubboService上，同时为了兼容扩展，也可以转到Feign的微服务上。

Dubbo网关引入

上图，微服务网关对上承接Nginx来的HTTP流量，将流量转化成Dubbo协议，再调用下游的DubboService。这样RPC的优势可以最大化发挥出来，下游的服务A，服务B，只需要出DubboService即可，Controller也不用写了，Service直接对外暴露对象，微服务之间的调用返回对象也不用像Feign一样写 XXXResult<?>。

要解决的技术难点：

1、微服务网关的技术选型

Java技术栈，做网关，最合适的应该采用响应式编程，在考虑Spring体系，那就只能是采用Reactor的Spring WebFlux,Spring Gateway 同样也是基于WebFlux的。所以这里大胆直接用Spring Gateway。

2、Http协议转Dubbo协议技术问题

在解决这个问题之前，我们对比下Http和Dubbo协议的调用要求

协议

资源定位

调用方法

参数传递

Http

URL

GET/POST/等

form/json/param/file 等

Dubbo

Interface#method 接口和方法

只可invoke

单一对象

所以将Http的**URL和Dubbo的Interface#method**做一个映射，然后调用的时候吧GET/POST等参数转为Dubbo中的方法参数，即可完成调用

弊端：

1. 有些Http行为，比如上传文件可能就不适用。（ps：大流量数据不适合用Dubbo协议）
2. Dubbo调用没有GET/POST一说，对HTTP Method不友好。下游的DubboService并没有GET/POST的概念，换句话说，同一个接口GET/POST都能通。
3. HTTP协议的PathVariable处理起来可能比较困难

笔者这里由于是新的项目，所以上述弊端有些可以从程序规范上避免。

3、Dubbo泛化调用

参考使用泛化调用

关键代码：

// 引用远程服务 
// 该实例很重量，里面封装了所有与注册中心及服务提供方连接，请缓存
ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>(); 
// 弱类型接口名
reference.setInterface("com.xxx.XxxService");  
reference.setVersion("1.0.0");
// 声明为泛化接口 
reference.setGeneric(true);  

// 用org.apache.dubbo.rpc.service.GenericService可以替代所有接口引用  
GenericService genericService = reference.get(); 
 
// 基本类型以及Date,List,Map等不需要转换，直接调用 
Object result = genericService.$invoke("sayHello", new String[] {"java.lang.String"}, new Object[] {"world"}); 
 
// 用Map表示POJO参数，如果返回值为POJO也将自动转成Map 
Map<String, Object> person = new HashMap<String, Object>(); 
person.put("name", "xxx"); 
person.put("password", "yyy"); 
// 如果返回POJO将自动转成Map 
Object result = genericService.$invoke("findPerson", new String[]
{"com.xxx.Person"}, new Object[]{person}); 

基于Dubbo泛化调用逻辑，我们只需要做好URL和 Dubbo Interface#Method以及Interface的ParamType的映射，上述理论即成立！

写在最后

本文所述均为笔者所想，若有错误请不吝赐教。期待看到更多思路。