dubbo服务治理架构与原理( 二 ) _dubbo

信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer 。

网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec 。

数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool 。

各层之间关系总结：

Protocol是核心层，简单组合只需要Protocol,Invoker,Exporter就能完成远程方法调用。Filter是在Invoker过程中增加的拦截层
Registry和Monitor属于独立角色， Registry属于注册中心层
Consumer和Provider属于抽象概念，因为一个节点在提供服务的同时调用了别的服务，那么他既属于Consumer又属于Provider
Proxy层封装过了所有接口了透明代理，但是其他层都以Invoker为中心，只有暴露接口时才用Proxy将Invoker转换为接口（接口转换为Invoker）
Remoting是dubbo协议的实现，内部分为Transport传输层和Exchange信息交换层， Transport只负责单向数据传输（Netty ， Mina的抽象，也可以扩展使用UDP协议传输）， Exchange是在Transport上定义了 Request-Response的模型

3.调用链路在看源码之前，先看一下dubbo服务调用链路过程。如下图：

文章插图
【dubbo服务治理架构与原理】

首先服务消费者通过代理对象 Proxy 发起远程调用，接着通过网络客户端 Client 将编码后的请求发送给服务提供方的网络层上，也就是 Server 。Server 在收到请求后，首先要做的事情是对数据包进行解码。然后将解码后的请求发送至分发器 Dispatcher ，再由分发器将请求派发到指定的线程池上，最后由线程池调用具体的服务。这就是一个远程调用请求的发送与接收过程。
3.1.调用方式dubbo支持同步和异步两种调用方式，其中异步调用分为“有返回值”的异步调用和“无返回值”的异步调用。所谓“无返回值”异步调用是指服务消费方只管调用，但不关心调用结果，此时 dubbo 会直接返回一个空的 RpcResult 。若要使用异步特性，需要服务消费方手动进行配置。默认情况下， Dubbo 使用同步调用方式。
异步调用方式如下：

/* 异步方法配置 */<dubbo:reference id="asyncService" check="false" interface="com.alibaba.dubbo.demo.AsyncService" url="localhost:20880"> <dubbo:method name="sayHello" async="true" /></dubbo:reference>Consumer端调用方式如下：

调用直接返回null

String result = asyncService.sayHello("world");

通过RpcContext获取Future对象，调用get()阻塞直到返回结果

asyncService.sayHello("world");Future<String> future = RpcContext.getContext().getFuture();String result = future.get();

通过ResponseFuture设置回调，执行完成调用done() ，异常调用caught()

asyncService.sayHello("world");ResponseFuture responseFuture = ((FutureAdapter)RpcContext.getContext().getFuture()).getFuture();responseFuture.setCallback(new ResponseCallback() { @Override public void done(Object response) { System.out.println("done"); } @Override public void caught(Throwable exception) { System.out.println("caught"); }});try { System.out.println("result = " + responseFuture.get());} catch (RemotingException e) { e.printStackTrace();}
4.Dubbo VS SpringCloud VS Other

文章插图

Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些。所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud ，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求。