Dubbo的入门实战

一、为什么要用Dubbo

在互联网发展的过程，我们不能将程序只部署在一个服务器上面，为的就是防止该服务器死机导致我们的服务不能正常使用，就不能使用常规的垂直应用架构。采用分布式架构来解决这一问题。下面的是Dubbo官方的问题：

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

如下图所示，Dubbo的架构

 下面是几个角色的功能

节点	角色说明
Provider	提供服务的服务方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行服务器

看完角色功能，发布-订阅的过程就非常的简单了。

• 启动容器，加载，运行Provider。
• 服务提供者在启动时，向注册中心提供自己提供的服务。
• 服务消费者在启动时，在注册中心找到自己所需的服务。

 如果失败了，就另说。

下面是一个简单的例子。

下面是服务方配置的Dubbo

#spring\u9879\u76EE\u540D
spring.application.name=heaboy_provider
#Dubbo provider configuration
#\u914D\u7F6E\u5E94\u7528\u540D\u79F0
dubbo.application.name=dubbo_provider
#\u914D\u7F6E\u6CE8\u518C\u4E2D\u5FC3
dubbo.registry.protocol=zookeeper
dubbo.registry.address=zookeeper://127.0.0.1:2181
#\u7528dubbo\u534F\u8BAE\u572820880\u66B4\u9732\u670D\u52A1
dubbo.protocol.name=dubbo
dubbo.protocol.port=20881
#\u626B\u63CF\u6CE8\u89E3\u5305\u901A\u8FC7\u8BE5\u8BBE\u7F6E\u5C06\u670D\u52A1\u6CE8\u518C\u5230zookeeper
dubbo.scan.base-packages=com.heaboy.provider.**.service

放在

 下面是provider的service层

下面是consumer的controller层

在 我们前端发起请求的时候

后端会打印service的类，由网络来请求服务。

下面是安装Zookeeper