Dubbo

RPC 基本原理

1. 调用方 client 要使用右侧 server 的功能（方法），发起对方法的调用
2. client stub 是 PRC 中定义的存根，看做是 client 的助手。stub 把要调用的方法参数进行序 列化，方法名称和其他数据包装起来
3. 通过网络 socket(网络通信的技术)，把方法调用的细节内容发送给右侧的 server
4. server 端通过 socket 接收请求的方法名称，参数等数据，传给 stub
5. server 端接到的数据由 serverstub(server 的助手)处理，调用 server 的真正方法，处理业务
6. server 方法处理完业务，把处理的结果对象（Object）交给了助手，助手把 Object 进行序 列化，对象转为二进制数据
7. server 助手二进制数据交给网络处理程序
8. 通过网络将二进制数据，发送给 client
9. client 接数据，交给 client 助手
10. client 助手，接收数据通过反序列化为 java 对象（Object），作为远程方法调用结果
11. rpc 通讯是基于 tcp 或 udp 议 序列化方式（xml/json/二进制）

 dubbo 概述

1. 是一款高性能、轻量级的开源 Java RPC 框架
2. 面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

基本架构

• 服务提供者（Provider）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。
• 服务消费者（Consumer）: 调用远程服务的服务消费方，服务消费者在启动时，向注册 中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一 台提供者进行调用，如果调用失败，再选另一台调用。
• 注册中心（Registry）：注册中心返回服务提供者地址列表给消费者，如果有变更，注册 中心将基于长连接推送变更数据给消费者
• 监控中心（Monitor）：服务消费者和提供者，在内存中累计调用次数和调用时间，定时 每分钟发送一次统计数据到监控中心

直连方式 dubbo

创建服务提供者

配置文件

创建服务消费者

dubbo 服务化最佳实践

分包

建议将服务接口、服务模型、服务异常等均放在公共包中。

粒度

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤， 否则将面临分布式事务问题，Dubbo 暂未提供分布式事务支持。 服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。 不建议使用过于抽象的通用接口，如：Map query(Map)，这样的接口没有明确语义， 会给后期维护带来不便。

版本

每个接口都应定义版本号，为后续不兼容升级提供可能，如： 。 建议使用两位版本号，要变更服务版本。先升级一半提供者为新版本，再将消费者全 部升为新版本，然后将剩下的一半提供者升为新版本。

注册中心-Zookeeper

注册中心概述

对于服务提供方，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也 不断膨胀；对于服务消费方，它最关心如何获取到它所需要的服务，而面对复杂的应用系统， 需要管理大量的服务调用。 而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即需要提供 服务，有需要消费服务。 通过将服务统一管理起来，可以有效地优化内部应用对服务发布 /使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一

1. Multicast 注册中心：组播方式
2. Redis 注册中心：使用 Redis 作为注册中心
3. Simple 注册中心：就是一个 dubbo 服务。作为注册中心。提供查找服务的功能
4. Zookeeper 注册中心：使用 Zookeeper 作为注册中心

注册中心工作方式

Zookeeper 注册中心

Zookeeper 是一个高性能的，分布式的，开放源码的分布式应用程序协调服务。简称 zk。 Zookeeper 是翻译管理是动物管理员。可以理解为 windows 中的资源管理器或者注册表。他 是一个树形结构。这种树形结构和标准文件系统相似。ZooKeeper 树中的每个节点被称为 Znode。和文件系统的目录树一样，ZooKeeper 树中的每个节点可以拥有子节点。每个节点表 示一个唯一服务资源。Zookeeper 运行需要 java 环境。

配置文件

关闭检查

dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初 始化完成，以便上线时，能及早发现问题，默认 check=true。通过 check="false"关闭检查， 比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

重试次数

消费者访问提供者，如果访问失败，则切换重试访问其它服务器，但重试会带来更长延迟。 访问时间变长，用户的体验较差。多次重新访问服务器有可能访问成功。可通过 retries="2" 来设置重试次数(不含第一次)。

超时时间

由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时 导致客户端资源（线程）挂起耗尽，必须设置超时时间。

版本号

每个接口都应定义版本号，为后续不兼容升级提供可能。当一个接口有不同的实现，项目早 期使用的一个实现类， 之后创建接口的新的实现类。区分不同的接口实现使用 version。 特别是项目需要把早期接口的实现全部换位新的实现类，也需要使用 version. 可以用版本号从早期的接口实现过渡到新的接口实现，版本号不同的服务相互间不引用

监控中心

dubbo 的使用，其实只需要有注册中心，消费者，提供者这三个就可以使用了，但是并不能 看到有哪些消费者和提供者，为了更好的调试，发现问题，解决问题，因此引入 dubbo-admin。 通过 dubbo-admin 可以对消费者和提供者进行管理。可以在 dubbo 应用部署做动态的调整， 服务的管理。