dubbo+springboot技术开发

■一、框架的演进

1.单体框架

例如(SpringMVC+Mybatis+MySQL)，项目的结构很简单，对于开发人员要求掌握技术技能较少。对于开发，测试的工作量都交少。

2.集群框架

随着项目的使用量越来越大，单体架构就不能满足访问需求。这个时候集群架构就产生了。简单的集群架构就是在单体架构的基础上做项目的负载均衡。比如我们常用的硬件负载均衡F5，以及软件负载均衡Nginx。像硬件负载均衡器一般价格都比较昂贵，对于一些资金有限的项目来说，成本压力比较大。对Nginx这样的软件负载均衡来说，我们也需要搭建多台服务器来对应软件负载均衡的使用，从一个侧面来说我们的硬件成本也是响应的提高了，但是其比硬件负载均衡还是要经济的多的。

3.dubbo框架

随着项目访问量爆发式增加以后，单纯的靠堆机器的复杂均衡已经解决不了我们项目的并发访问问题。另一方面单纯的堆机器也是不科学不经济的。对于我们的项目来说，其中各个模块的访问频率是不一致的，比如用户管理模块访问的频率可能并不高，而核心业务模块访问量是十分巨大的。面对这种情况，服务治理框架dubbo就应运而生了。Dubbo的核心思想是把模块服务化，然后对服务进行集群。这样我们的集群就更有针对性，对不同的业务模块它的集群规模可以随访问量而随时调整。

■二、dubbo框架

节点角色说明

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

 

看了这几个概念后似乎发现，其实 Dubbo 的架构也是很简单的（其实现细节是复杂的），为什么这么说呢，有没有发现，其实很像生产者-消费者模型。只是在这种模型上，加上了注册中心和监控中心，用于管理提供方提供的url，以及管理整个过程。
那么，整个发布-订阅的过程就非常的简单了。
  ■启动容器，加载，运行服务提供者。
  ■服务提供者在启动时，在注册中心发布注册自己提供的服务。
  ■服务消费者在启动时，在注册中心订阅自己所需的服务。
如果考虑失败或变更的情况，就需要考虑下面的过程。
  ■注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
  ■服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
  ■服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

■三、dubbo项目实践

1.各组件版本

  A:dubbo(2.6.2)

  B:springboot(2.0.4.RELEASE)

  C:mybatis(3.5.0)

  D:zookeeper(3.4.10)

  E:MySQL(5.1.7)

2.项目体系结构本

  工程包含3个项目

  A:服务提供方项目

  B:服务使用方项目

  C:服务接口项目

依赖关系如图:

【服务接口项目(api)】是一个jar项目，将生成的jar打包到maven仓库，作为【服务提供方项目(provider)】和【服务使用方项目(consumer)】的依赖导入。

■四、项目代码

★dubbo-服务接口项目

■一、项目结构(本项目由于只需要定义接口即可，所以建一普通maven项目即可)

■二、各部分代码

1.pom.xml

2.UserService.java

3.UserRequest.java

★dubbo-服务提供方项目

■一、项目结构(本项目为Springboot项目)

■二、各部分代码

1.pom.xml

2.application.properties

3.AlpUserProviderApplication.java

4.UserServiceImpl.java

5.CfpsUserUserMapper.java、CfpsUserUser.java、CfpsUserUserExample.java、CfpsUserUserMapper.xml为数据库表反向生成代码，不做赘述。

★dubbo-服务使用方项目

■一、项目结构(本项目为Springboot项目)

■二、各部分代码

1.pom.xml

2.application.properties

3.AlpClientApplication.java

4.UserController.java

5.UserService.java