基于 dubbo 的分布式架构 (2)

但是需要注意一点的是:
需要将其中的dubbo.properties的zk地址修改为自己的即可。

dubbo.registry.address=zookeeper://127.0.0.1:2181 dubbo.admin.root.password=root dubbo.admin.guest.password=guest

到时候登陆的话使用root,密码也是root。
使用guest,密码也是guest。

登陆界面如下图:

QQ20170407-001924@2x.jpg

其中我们可以看到有两个服务以及注册上去了,但是没有消费者。

消费服务

为了能够更直观的体验到消费服务,我新建了一个项目:
https://github.com/crossoverJie/SSM-CONSUMER。

其中在SSM-CONSUMER-API中我也定义了一个接口:

/** * Function:薪资API * @author chenjiec * Date: 2017/4/4 下午9:46 * @since JDK 1.7 */ public interface SalaryInfoApi { /** * 获取薪资 * @param userId * @return * @throws Exception */ public SalaryInfoRsp getSalaryInfo(int userId) throws Exception; }

因为作为消费者的同时我们也对外提供了一个获取薪资的一个服务。

在SSM-CONSUMER-SERVICE模块中进行了实现:

/** * Function: * @author chenjiec * Date: 2017/4/4 下午9:51 * @since JDK 1.7 */ @Service public class SalaryInfoApiImpl implements SalaryInfoApi { private static Logger logger = LoggerFactory.getLogger(SalaryInfoApiImpl.class); @Autowired UserInfoApi userInfoApi ; /** * 获取用户信息 * * @param userId * @return * @throws Exception */ @Override public SalaryInfoRsp getSalaryInfo(int userId) throws Exception { logger.info("薪资查询Id="+userId); //返回对象 SalaryInfoRsp salaryInfoRsp = new SalaryInfoRsp() ; //调用远程服务 UserInfoRsp userInfo = userInfoApi.getUserInfo(userId); salaryInfoRsp.setUsername(userInfo.getUserName()); return salaryInfoRsp; } }

其中就可以直接使用userInfoApi调用之前的个人信息服务。

再调用之前需要注意的有点是,我们只需要依赖SSM-BOOT这个模块即可进行调用,因为SSM-BOOT模块已经为我们配置了消费者之类的操作了:

<dependency> <groupId>com.crossoverJie</groupId> <artifactId>SSM-BOOT</artifactId> </dependency>

还有一点是在配置SSM-BOOT中的spring-dubbo-cosumer.xml配置文件的时候,路径要和我们初始化spring配置文件时的路径一致:

QQ20170407-005850@2x.jpg

<!-- Spring和mybatis的配置文件 --> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath*:spring/*.xml</param-value> </context-param>

接下来跑个单测试一下能否调通:

/** * Function: * * @author chenjiec * Date: 2017/4/5 下午10:41 * @since JDK 1.7 */ @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = { "classpath*:/spring/*.xml" }) public class SalaryInfoApiImplTest { @Autowired private SalaryInfoApi salaryInfoApi ; @Test public void getSalaryInfo() throws Exception { SalaryInfoRsp salaryInfo = salaryInfoApi.getSalaryInfo(1); System.out.println(JSON.toJSONString(salaryInfo)); } }

消费者.jpg


消费者

提供者.jpg


提供者
可以看到确实是调用成功了的。

接下来将消费者项目也同时启动在来观察管理控制台有什么不一样:

QQ20170407-003413@2x.jpg


会看到多了一个消费者所提供的服务com.crossoverjie.consumer.api.SalaryInfoApi,同时
com.crossoverJie.api.UserInfoApi服务已经正常,说明已经有消费者了。

QQ20170407-003456@2x.jpg


点进去便可查看具体的消费者。

总结

这样一个基于dubbo的分布式服务已经讲的差不多了,在实际的开发中我们便会开发一个大系统中的某一个子应用,这样就算一个子应用出问题了也不会影响到整个大的项目。

再提一点:
在实际的生产环境一般同一个服务我们都会有一个master,slave的主从服务,这样在上线的过程中不至于整个应用出现无法使用的尴尬情况。

谈到了SOA的好处,那么自然也有相对于传统模式的不方便之处:

拆分一个大的项目为成百上千的子应用就不可能手动上线了,即需要自动化的部署上线,如Jenkins。

还有一个需要做到的就是监控,需要一个单独的监控平台来帮我们实时查看各个服务的运行情况以便于及时定位和解决问题。

日志查看分析,拆分之后不可能再去每台服务器上查看日志,需要一个单独的日志查看分析工具如elk。

以上就是我理解的,如有差错欢迎指正。

项目地址:https://github.com/crossoverJie/SSM.git

个人博客地址:。

GitHub地址:https://github.com/crossoverJie。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpwxxd.html