Dubbo使用教程

1 单一应用架构

2 应用和数据库单独部署

3 应用和数据库集群部署

4 数据库压力变大，读写分离

5 使用缓存技术加快速度

6 数据库分库分表

7 应用分为不同的类型拆分

发展到这个阶段的时候，我们发现，应用与应用之间的关系已经十分的复杂了，就会出现以下几个问题（以下摘录于官网）：

① 当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。
② 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
③ 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

为了解决这由于架构的演变所产生的问题几个问题，于是，dubbo 产生了。当然，解决这个问题的技术不止 dubbo 。

二Dubbo技术架构

Dubbo架构图

从图中我们可以看到，Dubbo架构很想生产者-消费者模型，只是在上面这个模型基础上，加了注册中心和监控模块，分别用于管理服务提供方的url，以及监控管理整个流程。

整个发布，订阅流程：

• 启动容器，加载，运行服务提供者
• 服务提供者在启动时，在注册中心发布注册自己提供的服务
• 服务消费者在启动时，在注册中心订阅自己所需的服务。

如果存在服务失败或者变更的情况，Dubbo就进行如下的操作：

• 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

三Dubbo实例教程

3.1服务端