还有一点是在配置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。
以上就是我理解的，如有差错欢迎指正。
个人博客地址：crossoverjie.top。
GitHub地址：github.com/crossoverJi…。
