dubbo入门与基础 rpc请求过程图解

Dubbo为了解决什么问题

随着业务发展，应用的功能和涵盖的业务越来越大，造成复杂度越来越高，代码量跟着加大，开发人员在发布环节会遇到前后端协调和代码冲突导致发布失败，在开发过程中由于代码的臃肿而不得不背负较大的负担降低开发效率，每个开发人员没有具体分工不能够做到业务模块责任到人，单个应用包含了不同业务一方业务出现问题影响其他业务的正常服务，大量业务柔和在一起无法有效做到容量规划，造成数据库连接和分布式缓存的浪费。

因此，将应用拆分，并抽取出核心服务来解决上述问题，还要考虑负载均衡、服务监控、高可用性、服务隔离与降级、路由策略、完善的容错机制、序列化方案的选择、通信框架的选择、开发人员对底层细节无感知、服务升级兼容性等问题生产上怎么使用实例。

RPC请求的过程

有什么功能

远程通信：提供基于多钟长连接的NIO框架抽象封装，包括多线程，序列化，和“请求-响应”模式的信息交换方式

集群容错：提供基于接口方法的透明远程服务调用，包括多协议支持，软负载均衡，失败容错，地址路由，动态配置等集群支持。

自动发现：基于注册中心，消费方可以动态查找服务提方，使地址透明，使服务提供方可以平滑增加或减少机器。

 

具体实现

服务注册和订阅的过程详解：

（1）系统角色
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。1
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。

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