分布式的几件小事（一）为何要把系统拆分红分布式的

1.为何进行拆分

①项目过于庞大维护困难。
若是系统过去庞大，那么代码会有不少，达到几十万行上百行，这样就须要不少人一块儿来维护一份代码，这样就很容易形成各类冲突，这样光合并代码就会浪费大量的时间在上面。

②项目发布复杂。
一个小bug的修改发布须要整个系统所有进行从新发布，这样就很麻烦，不但发布后须要大量的测试，无论这个bug和本身负责的模块是否有关系，上线以后都要去检查，防止本身的模块被改出bug或者由于对方修改某个配置致使本身处错。

③项目技术升级变动麻烦。
必须本身须要升级某个依赖的版本，那么就须要考虑到其余全部模块的依赖版本问题，几乎成为灾难。

④上线以后bug定位麻烦。
因为全部的模块都在一块儿，bug排除会比较麻烦。

⑤系统没法承受高并发。
系统单块部署，高并发没法支撑。

2.如何进行拆分

大部分的系统，是要进行多轮拆分的，第一次拆分，可能就是将之前的多个模块该拆分开来了，好比说将电商系统拆分红订单系统、商品系统、采购系统、仓储系统、用户系统，等等。

可是后面可能每一个系统又变得愈来愈复杂了，好比说采购系统里面又分红了供应商管理系统、采购单管理系统，订单系统又拆分红了购物车系统、价格系统、订单管理系统。

核心意思就是根据状况，先拆分一轮，后面若是系统更复杂了，能够继续分拆。

3.拆分后怎么通讯

①直接基于spring mvc，纯http接口通讯。

②使用dubbo这种rpc框架