从单体项目到分布式架构的演进

在以前绝大多数的公司的项目都是单体项目。如下图所示：

图片.png

就是所有的业务模块都打在一个war包里。
这种单体应用的架构方式有以下几种缺点：
1.项目庞大，每次发布必须所有模块都重新发版
2.维护困难，很容易会员模块的开发人员不小心动了促销模块的代码，导致可能几十万行的代码十几个人维护。
3.上线复杂且可能互相影响，每次迭代，可能会员跟促销的都已经把代码合到基准分支，然后基准又合到发版分支上了，但是突然发现促销有个bug。而且还不太好改，这个时候促销的问题导致会员也无法上线了。
4.耗费资源，不同模块的流量不同，比如会员模块流量就比员工模块高，但是同时都在一个tomcat里，导致横向扩容的时候，明明员工模块不需要的，单还是扩容的时候带上了。
5.无法进行很好的扩展。

基于以上几点。渐渐演进了微服务架构

图片.png

各个模块都有自己的java进程，有自己所示的数据库。
这种方式跟单体应用相比有如下几种优势
1.各个业务模块拆分的干净，项目的代码降低了很多，不会发生业务模块代码被其他团队修改的后果。
2.其中一个业务模块的代码出了问题，不会影响其他的模块。
3.一个项目代码量小了很多，发版速度比以前快很多
4.扩展能力大大加强
但是也带来了如下几个缺点：
1.原来的进程内通信变成了进程间的通信，效率降低了，但是复杂度极具升高，需要考虑各种网络问题引起的代码调用问题
2.无法使用本地事务，只能使用分布式事务，难度大了很多。
3.各个模块之间需要通过指定的通讯协议进行通信。