【上海校区】分布式服务那点事（三）

Dubbo的通信协议及序列化

1.为什么进行拆分
①项目过于庞大维护困难。
如果系统过去庞大，那么代码会有很多，达到几十万行上百行，这样就需要很多人一起来维护一份代码，这样就很容易造成各种冲突，这样光合并代码就会浪费大量的时间在上面。
②项目发布复杂。
一个小bug的修改发布需要整个系统全部进行重新发布，这样就很麻烦，不但发布后需要大量的测试，不管这个bug和自己负责的模块是否有关系，上线之后都要去检查，防止自己的模块被改出bug或者因为对方修改某个配置导致自己处错。
③项目技术升级变更麻烦。
必须自己需要升级某个依赖的版本，那么就需要考虑到其他所有模块的依赖版本问题，几乎成为灾难。
④上线之后bug定位麻烦。
由于所有的模块都在一起，bug排除会比较麻烦。
⑤系统无法承受高并发。
系统单块部署，高并发无法支撑。
2.如何进行拆分
大部分的系统，是要进行多轮拆分的，第一次拆分，可能就是将以前的多个模块该拆分开来了，比如说将电商系统拆分成订单系统、商品系统、采购系统、仓储系统、用户系统，等等。
但是后面可能每个系统又变得越来越复杂了，比如说采购系统里面又分成了供应商管理系统、采购单管理系统，订单系统又拆分成了购物车系统、价格系统、订单管理系统。
核心意思就是根据情况，先拆分一轮，后面如果系统更复杂了，可以继续分拆。

3.拆分后怎么通信
①直接基于spring mvc，纯http接口通信。
②使用dubbo这种rpc框架

本文摘自博客园

【上海校区】分布式服务那点事（三）

Dubbo的通信协议及序列化

1.为什么进行拆分
①项目过于庞大维护困难。
如果系统过去庞大，那么代码会有很多，达到几十万行上百行，这样就需要很多人一起来维护一份代码，这样就很容易造成各种冲突，这样光合并代码就会浪费大量的时间在上面。
②项目发布复杂。
一个小bug的修改发布需要整个系统全部进行重新发布，这样就很麻烦，不但发布后需要大量的测试，不管这个bug和自己负责的模块是否有关系，上线之后都要去检查，防止自己的模块被改出bug或者因为对方修改某个配置导致自己处错。
③项目技术升级变更麻烦。
必须自己需要升级某个依赖的版本，那么就需要考虑到其他所有模块的依赖版本问题，几乎成为灾难。
④上线之后bug定位麻烦。
由于所有的模块都在一起，bug排除会比较麻烦。
⑤系统无法承受高并发。
系统单块部署，高并发无法支撑。
2.如何进行拆分
大部分的系统，是要进行多轮拆分的，第一次拆分，可能就是将以前的多个模块该拆分开来了，比如说将电商系统拆分成订单系统、商品系统、采购系统、仓储系统、用户系统，等等。
但是后面可能每个系统又变得越来越复杂了，比如说采购系统里面又分成了供应商管理系统、采购单管理系统，订单系统又拆分成了购物车系统、价格系统、订单管理系统。
核心意思就是根据情况，先拆分一轮，后面如果系统更复杂了，可以继续分拆。

3.拆分后怎么通信
①直接基于spring mvc，纯http接口通信。
②使用dubbo这种rpc框架

本文摘自博客园