为什么要将系统进行拆分
如果不拆分
一个大系统几十万行代码，20个人维护一份代码，代码经常改着改着就冲突了，各种代码冲突和合并要处理，非常耗费时间；
自己改动代码后，可能影响别人的。
每次上线都要做很多的检查，很多异常问题的处理。
拆分了之后
几十万行代码的系统，拆分成20个服务，平均每个服务就1~2万行代码，每个服务部署到单独的机器上。
每个人维护自己的那个服务就可以了，是自己独立的代码，跟别人没关系。
每次就测试我自己的代码，每次就发布我自己的一个小服务。
但是同时，系统拆分成分布式系统之后，大量的分布式系统面临的问题也是接踵而来。
如何进行系统拆分
系统拆分分布式系统，拆成多个服务，拆成微服务的架构，要拆很多轮的。
拆好后的小服务，如果代码量变多了，就继续拆。
保持1-3人维护一个服务，一个服务代码量在3W以下。
比如说将电商系统拆分成订单系统、商品系统、采购系统、仓储系统、用户系统，等等吧。
但是后面可能每个系统又变得越来越复杂了，比如说采购系统里面又分成了供应商管理系统、采购单管理系统，订单系统又拆分成了购物车系统、价格系统、订单管理系统。
拆分后不用dubbo可以吗
当然可以了，最简单的就是各个系统之间，直接基于spring mvc，就纯http接口互相通信。
但是这个肯定是有问题的，因为http接口通信维护起来成本很高，你要考虑超时重试、负载均衡等等各种问题，比如说你的订单系统调用商品系统，商品系统部署了5台机器，你怎么把请求均匀地甩给那5台机器？
dubbo是一种rpc框架，就是本地进行接口调用，但是dubbo会代理这个调用请求，跟远程机器网络通信，帮你处理掉负载均衡、服务实例上下线自动感知、超时重试，等等乱七八糟的问题。
转自：中华石杉Java工程师面试突击