dubbo从入门到实战
一、简介
Dubbo用起来就和EJB、WebService差不多，调用一个远程的服务（或者JavaBean）的时候在本地有一个接口，就像调用本地的方法一样去调用，它底层帮你实现好你的方法参数传输和远程服务运行结果传回之后的返回，就是RPC的一种封装
1、特点
- 它主要是使用高效的网络框架和序列化框架，让分布式服务之间调用效率更高。
- 采用注册中心管理众多的服务接口地址，当你想调用服务的时候只需要跟注册中心询问即可，不用像使用WebService一样每个服务都得记录好接口调用方式。
- 监控中心：实现对服务方和调用方之间运行状态的监控，还能控制服务的优先级、权限、权重、上下线等，让整个庞大的分布式服务系统的维护和治理比较方便。
- 高可用：有个服务宕机了？注册中心就会从服务列表去掉该节点。还是调用到了？客户端会向注册中心请求另一台可用的服务节点重新调用。注册中心宕机？注册中心也能实现高可用（ZooKeeper）。
- 负载均衡：采用软负载均衡算法实现对多个相同服务的节点的请求负载均衡。
2、为什么要用Dubbo
内部使用了 Netty、Zookeeper，保证了高性能高可用性。
- 使用Dubbo可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用
灵活扩展，使前端应用能更快速的响应多变的市场需求。 - 分布式架构可以承受更大规模的并发流量。
3、Dubbo 和 Spring Cloud 有什么区别
- 通信方式不同：Dubbo 使用的是 RPC 通信，而Spring Cloud 使用的是HTTP RESTFul 方式。
- 组成不一样：
dubbo的服务注册中心为Zookeerper，服务监控中心为dubbo-monitor,无消息总线，服务跟踪、批量任务等组件；
spring-cloud的服务注册中心为spring-cloud netflix enruka，服务监控中心为spring-boot admin,有消息总线，数据流、服务跟踪、批量任务等组件；
4、SpringCloud和Dubbo的RPC相关比较
| 微服务技术 | Spring Cloud | Dubbo |
|---|---|---|
| 分布式管理 | Git、Consul、Zookeeper | Zookeeper、Redis |
| 服务发现 | Eureka、Consul、Zookeeper | Zookeeper、Redis、Multicast |
| 路由 | Zuul | Router |
| 服务调用 | Feign / REST | 多种实现（长连接) |
| 负载均衡 | Zuul、Ribbon | LoadBalance |
| 服务熔断 | Hystrix | Fallback, Failover |
| 服务安全 | Security | Token |
| 分布式跟踪 | Zipkin | 无 |
5、Dubbo服务注册与发现的流程图
节点角色说明
| 节点 | 角色说明 |
|---|---|
| Provider | 暴露服务的服务提供方 |
| Consumer | 调用远程服务的服务消费方 |
| Registry | 服务注册与发现的注册中心 |
| Monitor | 统计服务的调用次数和调用时间的监控中心 |
| Container | 服务运行容器 |
那么，整个发布-订阅的过程就非常的简单了。
- 启动容器，加载，运行服务提供者。
- 服务提供者在启动时，在注册中心发布注册自己提供的服务。
- 服务消费者在启动时，在注册中心订阅自己所需的服务。
如果考虑失败或变更的情况，就需要考虑下面的过程。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
二、服务引用大致流程
服务的引入时机有两种，第一种是饿汉式，第二种是懒汉式。
- 饿汉式是通过实现 Spring 的InitializingBean接口中的 afterPropertiesSet方法，容器通过调用 ReferenceBean的 afterPropertiesSet方法时引入服务。
- 懒汉式是只有当这个服务被注入到其他类中时启动引入流程，也就是说用到了才会开始服务引入。
默认情况下，Dubbo 使用懒汉式引入服务，如果需要使用饿汉式，可通过配置 dubbo:reference 的 init 属性开启。
1、服务引入的三种方式
服务的引入又分为了三种，第一种是本地引入、第二种是直接连接引入远程服务、第三种是通过注册中心引入远程服务。
- 本地引入不知道大家是否还有印象，之前服务暴露的流程每个服务都会通过搞一个本地暴露，走 injvm 协议（当然你要是 scope = remote 就没本地引用了），因为存在一个服务端既是 Provider 又是 Consumer 的情况，然后有可能自己会调用自己的服务，因此就弄了一个本地引入，这样就避免了远程网络调用的开销。所以服务引入会先去本地缓存找找看有没有本地服务。
- 直连远程引入服务，这个其实就是平日测试的情况下用用，不需要启动注册中心，由 Consumer 直接配置写死 Provider 的地址，然后直连即可。
- 注册中心引入远程服务，这个就是重点了，Consumer 通过注册中心得知 Provider 的相关信息，然后进行服务的引入，这里还包括多注册中心，同一个服务多个提供者的情况，如何抉择如何封装，如何进行负载均衡、容错并且让使用者无感知，这就是个技术活。
三、常见问题
1、什么是RPC
RPC 就是 Remote Procedure Call，远程过程调用，它相对应的是本地过程调用。
2、为什么要有 RPC，HTTP 不好么
- RPC 和 HTTP 就不是一个层级的东西，所以严格意义上这两个没有可比性，也不应该来作比较
- HTTP 只是传输协议，协议只是规范了一定的交流格式，而且 RPC 是早于 HTTP 的，所以真要问也是问有 RPC 为什么还要 HTTP。
- RPC 对比的是本地过程调用，是用来作为分布式系统之间的通信，它可以用 HTTP 来传输，也可以基于 TCP 自定义协议传输。
3、过程小结
- 首先服务提供者 Provider 启动然后向注册中心注册自己所能提供的服务。
- 服务消费者 Consumer 启动向注册中心订阅自己所需的服务。然后注册中心将提供者元信息通知给 Consumer， 之后 Consumer 因为已经从注册中心获取提供者的地址，因此可以通过负载均衡选择一个 Provider 直接调用 。
- 之后服务提供方元数据变更的话注册中心会把变更推送给服务消费者。
- 服务提供者和消费者都会在内存中记录着调用的次数和时间，然后定时的发送统计数据到监控中心。