标签：响应 read sid 概率 参数 信息 联网 代码 设计
随着互联网的发展和网站规模的扩大，系统架构也从单点的垂直结构往分布式服务架构演进，如下图所示：
当服务比较少时，可以通过 RMI 或 Hession 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址来调用，通过F5等硬件负载均衡
当服务越来越多时，服务配置URL变的困难，F5硬件负载均衡的单点压力越来越大。此时需要服务注册中心，动态的注册和发现服务，使服务的位置透明。服务调用实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖
当服务间关系越来越复杂时，此时需要自动画出服务间的依赖关系图，来帮助架构师理清服务关系
当服务调用量越来越大时，服务需要多少台机器支撑，服务容量的问题就暴露出来了，此时需要统计服务每天的调用量、响应时间等性能指标作为容量规划的参考。其次，还可以动态调整权重，将某台机器权重一直加大，直到响应时间到阀值，按照此时的访问量反推服务的总容量
以上是Dubbo的基本需求，如下图所示：
Dubbo的整体架构设计如图所示：
Dubbo框架一共分10层，各层单向依赖。最上面的 Service 和 Config 为API，其他均为 SPI。左边淡蓝色的为 consumer 使用的接口，右边淡绿色的为 provider 使用的接口，中间的为双方都用到的接口。
黑色箭头代表层之间的依赖关系；蓝色虚线为初始化过程，即启动时组装链；红色实线为方法调用过程；紫线为继承关系。线上的文字为调用的方法。
1、接口服务层（Service）：该层与业务逻辑相关，根据 provider 和 consumer 的业务设计对应的接口和实现
2、配置层（Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心
3、服务代理层（Proxy）：服务接口透明代理，生成服务的客户端 Stub 和 服务端的 Skeleton，以 ServiceProxy 为中心，扩展接口为 ProxyFactory
4、服务注册层（Registry）：封装服务地址的注册和发现，以服务 URL 为中心，扩展接口为 RegistryFactory、Registry、RegistryService
5、路由层（Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中心，以Invoker 为中心，扩展接口为 Cluster、Directory、Router和LoadBlancce
6、监控层（Monitor）：RPC调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory、Monitor和MonitorService
7、远程调用层（Protocal）：封装 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocal、Invoker和Exporter
8、信息交换层（Exchange）：封装请求响应模式，同步转异步。以 Request 和 Response 为中心，扩展接口为 Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer
9、网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为Channel、Transporter、Client、Server和Codec
10、数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool
各层关系说明：
Dubbo核心领域模型：
Dubbo主要包括以下几个节点：
Consumer, Provider, Registry, Monitor代表逻辑部署节点。图中只包含 RPC 层，不包含 Remoting层，Remoting整体隐藏在 Protocol 中。
蓝色方框代表业务有交互，绿色方框代表只对Dubbo内部交互。蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用
0、服务在容器中启动，加载，运行Provider
1、Provider在启动时，向Registry注册自己提供的服务
2、Consumer在启动时，想Registry订阅自己所需的服务
3、Registry给Consumer返回Provider的地址列表，如果Provider地址有变更（上线/下线机器），Registry将基于长连接推动变更数据给Consumer
4、Consumer从Provider地址列表中，基于软负载均衡算法，选一台进行调用，如果失败，重试另一台调用
5、Consumer和Provider，在内存中累计调用次数和时间，定时每分钟一次将统计数据发送到Monitor
将上面的服务调用流程展开，如下图所示：
蓝色虚线为初始化过程，即启动时组装链；红色实线为方法调用过程，即运行时调用链；紫色实线为继承
Invoker 是 Dubbo 领域模型中非常重要的一个概念，很多设计思路都是向它靠拢，这就使得 Invoker 渗透在整个实现代码里。下面用一个精简的图来说明最重要的两种 Invoker：服务提供 Invoker 和服务消费 Invoker：
① 定义服务接口：
public interface DemoService { String sayHello(String name); }
② 服务提供者代码：
public class DemoServiceImpl implements DemoService { public String sayHello(String name) { return "Hello " + name; } }
ServiceConfig 类拿到对外提供服务的实际类 ref（如：DemoServiceImpl）通过 ProxyFactory.getInvoker 方法使用 ref 生成一个 AbstractProxyInvoker 实例，然后 通过 Protocol.export 方法新生成一个 Exporter 实例
当网络通讯层收到一个请求后，会找到对应的 Exporter 实例，并调用它所对应的 AbstractProxyInvoker 实例，从而真正调用了服务提供者的代码
③ 服务消费者代码：
public class DemoClientAction {
private DemoService demoService;
public void setDemoService(DemoService demoService) {
this.demoService = demoService;
}
public void start() {
String hello = demoService.sayHello("world");
} }
首先通过 ReferenceConfig.init 方法调用 Protocal.refer 方法生成 Invoker 实例，接下来通过 ProxyFactory.getProxy 方法将 Invoker 转换为客户端需要的接口（如：DemoService）
DemoService 就是 consumer 端的 proxy，用户代码通过这个 proxy 调用其对应的 Invoker，通过 Invoker 实现真正的远程调用
Dubbo可以采用全Spring的配置方式，基于Spring的Schema扩展进行加载，接入对业务透明，无API侵入。配置项可参考：schema 配置参考手册
除了Spring配置，也可以使用API配置、属性配置和注解配置方式。
配置之间的关系，如下图所示：
provider side：
<dubbo:protocol/>：协议配置。用于配置提供服务的协议信息，协议由provider指定，consumer被动接受<dubbo:service/>： 服务配置。暴露一个service，定义service的元信息，一个service可以用多个协议暴露，也可以注册到多个注册中心<dubbo:provider/>：提供方配置【可选】。当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值consumer side：
<dubbo:reference/>：引用配置。用于创建一个远程服务代理，一个引用可以指向多个注册中心<dubbo:consumer/>：消费方配置【可选】。当 ReferenceConfig 某属性没有配置时，采用此缺省值application shared：
<dubbo:application/>：应用配置。配置应用信息，包括provider和consumer<dubbo:registry/>：注册中心配置。配置连接注册中心相关信息<dubbo:monitor/>：监控中心配置【可选】。配置连接监控中心相关信息sub-config：
<dubbo:method/>：方法配置。用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息<dubbo:argument/>：参数配置。用于指定方法参数配置
服务调用时的过程如下图：
Invoker：是Provider的一个可调用Service的抽象，封装了Provider地址和Service接口信息
Directory：代表多个Invoker，可将它看为List<Invoker>，它的值是动态变化的，比如注册中心推送变更
Cluster：将Directory的多个Invoker伪装为一个Invoker，对上层透明。伪装过程中包括容错逻辑，例如：一个Invoker调用失败后重试另一个Invoker
Router：从多个Invoker中按路由规则选出子集，例如：读写分离、应用隔离等
LoadBlance：从多个Invoker中选出具体的一个Invoker用于本次调用，选的过程包括负载均衡算法，调用失败后需要重选
当Cluster集群调用失败时，Dubbo提供了多种容错方案：
路由规则决定一次dubbo服务调用的目标服务器，分为脚本路由规则和条件路由规则，支持可扩展。向注册中心写入路由规则的操作通常由治理中心的页面完成
如上图 LoadBlance 模块所示：在集群负载均衡时，Dubbo提供了不同的策略：
如果事件处理的逻辑能迅速完成，并且不发生新的IO请求（例如在内存中记个标识），则在IO线程上处理更快，因为减少了线程池调度
如果事件处理的逻辑较慢，或需要发起新的IO请求（例如需要查询数据库），则必须派发到线程池，否则 IO 线程阻塞，将导致不能接受其他请求
因此需要不同的派发策略和不同的线程池组合来应对不同的场景：
Dispatcher：
ThreadPool：
上下文中存放着当前调用过程中所需的环境信息。RpcContext 是一个 ThreadLocal 的临时状态记录器，当接收或发起 RPC 请求时，RpcContext 都会发生变化。比如：A调用B，B调用C，在B调C之前，B机器上 RpcContext 记录的是A调用B的信息。
通过 RpcContext 的 setAttachment 和 getAttachment 可以在 provider 和 consumer 之间进行参数的隐式传递
基于NIO的非阻塞实现并行调用，客户端不需要启动多线程即可完成多个远程服务的并行调用，相对比多线程开销较小
对于 provider，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；对于 consumer，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用
服务注册中心通过特性协议将服务统一管理起来，有效的优化内部应用对服务发布/使用的流程。Dubbo提供的注册中心有如下几种类型可供选择：
① ZooKeeper注册中心
ZK是一个树形的服务目录，支持变更推送，适合作为Dubbo服务的注册中心。流程如下：
当 provider 出现断电等异常停机时，注册中心能自动删除 provider 信息。当注册中心重启、或会话过期时，能自动恢复注册数据和订阅请求
② Multicase注册中心
Multicast注册中心不需要启动任何中心节点，只要广播地址即可互相发现
组播受网络结构限制，只适合小规模应用或开发阶段
③ Redis注册中心
使用 redis 的 Key/Map 结构存储数据结构：
调用过程：
标签：响应 read sid 概率 参数 信息 联网 代码 设计
原文地址：https://www.cnblogs.com/butterfly100/p/9260731.html
