转载和引用,请注明原文出处! Fork me on GitHub
结局很美妙的事,开头并非如此!

Dubbo分布式服务子系统的划分

一、划分子系统的策略

按照系统的业务模块的独立性划分

二、划分时服务子系统的数量的控制

过多:可能划分过细,破坏业务子系统的独立性,部署维护工作量大,独立进程占用内存多

过少:没能很好的解耦,开发维护不好分工,升级维护影响面大

三、服务子系统划分要注意的地方

3.1 不要出现A服务中的SQL需要链接查询到B服务中的表等情况,这样在A服务与B服务进行垂直拆库时就会出错

      eg:服务虽然拆分了,但是还是用的同一个数据库

3.2  服务子系统间避免出现环状的依赖调用

       eg:A服务调用B服务,B服务调用C服务,C服务调用A服务;出现这种情况说明服务划分得还是不够细,没有完全的解耦,需要考虑出现环状调用的几个服务之间是否还有能合并得模块

3.3 服务子系统间的依赖关系链不要过长

      eg:A服务——>B服务——>C服务——>D服务——>E服务;出现这种情况说明服务子系统划分过细,需要考虑几个服务之间是否能向上合并

3.4 尽量避免分布式事务,如果不能避免,需要考虑使用消息中间件来保证事务的一致性

四、总结

Dubbo分布式服务子系统的划分是一个不断优化的过程,刚开始的时候可以只划分几个子系统,随着业务量的变化不断的增多

 

posted @ 2017-09-24 17:59  小不点啊  阅读(852)  评论(0编辑  收藏  举报