经典面试题：为何要把系统拆分红分布式的，为啥要用Dubbo？

参考：https://mp.weixin.qq.com/s/HFVlJoBrM9BW9wSCQY0fRw

一、面试题

为何要进行系统拆分？如何进行系统拆分？拆分后不用dubbo能够吗？

二、面试官内心分析

从这个问题开始就进行分布式系统环节了，好多同窗给我反馈说，如今出去分布式成标配了，没有哪一个公司不问问你分布式的事儿。你要是不会分布式的东西，简直这简历无法看，没人会让你去面试。

其实为啥会这样呢？这就是由于整个大行业技术发展的缘由。

早些年，我印象中在2010年初的时候，整个IT行业，不多有人谈分布式，更不用说微服务，虽然不少BAT等大型公司，由于系统的复杂性，很早就是分布式架构，大量的服务，只不过微服务大多基于本身搞的一套框架来实现而已。

可是确实，那个年代，你们很重视ssh2，不少中小型公司几乎大部分都是玩儿struts二、spring、hibernate，稍晚一些，才进入了spring mvc、spring、mybatis的组合。那个时候整个行业的技术水平就是那样，当年oracle很火，oracle管理员很吃香，oracle性能优化啥的都是IT男的大杀招啊。连大数据都没人提，当年OCP、OCM等认证培训机构，火的不行。

可是确实随着时代的发展，慢慢的，不少公司开始接受分布式系统架构了，这里面尤其对行业有相当重要影响的，是阿里的dubbo，某种程度上而言，阿里在这里推进了行业技术的前进。

正是由于有阿里的dubbo，不少中小型公司才能够基于dubbo，来把系统拆分红不少的服务，每一个人负责一个服务，你们的代码都没有冲突，服务能够自治，本身选用什么技术均可以，每次发布若是就改动一个服务那就上线一个服务好了，不用全部人一块儿联调，每次发布都是几十万行代码，甚至几百万行代码了。

直到今日，我很高兴的看到分布式系统都成行业面试标配了，任何一个普通的程序员都该掌握这个东西，其实这是行业的进步，也是全部IT码农的技术进步。因此既然分布式都成标配了，那么面试官固然会问了，由于不少公司如今都是分布式、微服务的架构，那面试官固然得考察考察你了。

三、友情提示

若是有个同窗看到这里说，我天，我不知道啥是分布式系统？我也不知道啥是dubbo？那你赶忙百度啊，搜个dubbo入门，去里面体验一下。

分布式系统，我用一句话给你解释一下，就是原来20万行代码的系统，如今拆分红20个小系统，每一个小系统1万行代码。本来代码之间直接就是基于spring调用，如今拆分开来了，20个小系统部署在不一样的机器上，得基于dubbo搞一个rpc调用，接口与接口之间经过网络通讯来请求和响应。就这个意思。

四、面试题剖析

（1）为何要将系统进行拆分？

网上查查，答案极度零散和复杂，很琐碎，缘由一大坨。可是我这里给你们直观的感觉：

1）要是不拆分，一个大系统几十万行代码，20我的维护一份代码，简直是悲剧啊。代码常常改着改着就冲突了，各类代码冲突和合并要处理，很是耗费时间；常常我改动了个人代码，你调用了我，致使你的代码也得从新测试，麻烦的要死；而后每次发布都是几十万行代码的系统一块儿发布，你们得一块儿提心吊胆准备上线，几十万行代码的上线，可能每次上线都要作不少的检查，不少异常问题的处理，简直是又麻烦又痛苦；并且若是我如今打算把技术升级到最新的spring版本，还不行，由于这可能致使你的代码报错，我不敢随意乱改技术。

假设一个系统是20万行代码，其中小A在里面改了1000行代码，可是此时发布的时候是这个20万行代码的大系统一起发布。就意味着20万上代码在线上就可能出现各类变化，20我的，每一个人都要紧张地等在电脑面前，上线以后，检查日志，看本身负责的那一起有没有什么问题。

小A就检查了本身负责的1万行代码对应的功能，确保ok就闪人了；结果不巧的是，小A上线的时候不当心修改了线上机器的某个配置，致使另外小B和小C负责的2万行代码对应的一些功能，出错了。

几十我的负责维护一个几十万行代码的单块应用，每次上线，准备几个礼拜，上线 -> 部署 -> 检查本身负责的功能。

最近从2013年到如今，5年的时间里，2013年之前，基本上都是BAT的天下；2013年开始，有几个小巨头开始快速的发展，上市，几百亿美金，估值都几百亿美金；2015年，出现了除了BAT之外，又有几个互联网行业的小巨头出现。

BAT工做，在市值几百亿美金的小巨头工做

有某一个小巨头，如今估值几百亿美金的小巨头，5年前刚开始搞的时候，核心的业务，几十我的，维护一个单块的应用

维护单块的应用，在从0到1的环节里，是很合适的，由于那个时候，是系统都没上线，没什么技术挑战，你们有条不紊的开发。ssh + mysql + tomcat，可能会部署几台机器吧。

结果不行了，后来系统上线了，业务快速发展，10万用户 -> 100万用户 -> 1000万用户 -> 上亿用户了。

2）拆分了之后，整个世界清爽了，几十万行代码的系统，拆分红20个服务，平均每一个服务就1~2万行代码，每一个服务部署到单独的机器上。20个工程，20个git代码仓库里，20个码农，每一个人维护本身的那个服务就能够了，是本身独立的代码，跟别人不要紧。再也没有代码冲突了，爽。每次就测试我本身的代码就能够了，爽。每次就发布我本身的一个小服务就能够了，爽。技术上想怎么升级就怎么升级，保持接口不变就能够了，爽。

因此简单来讲，一句话总结，若是是那种代码量多达几十万行的中大型项目，团队里有几十我的，那么若是不拆分系统，开发效率极其低下，问题不少。可是拆分系统以后，每一个人就负责本身的一小部分就行了，能够随便玩儿随便弄。分布式系统拆分以后，能够大幅度提高复杂系统大型团队的开发效率。

可是同时，也要提醒的一点是，系统拆分红分布式系统以后，大量的分布式系统面临的问题也是接踵而来，因此后面的问题都是在围绕分布式系统带来的复杂技术挑战在说。

（2）如何进行系统拆分？

这个问题说大能够很大，能够扯到领域驱动模型设计上去，说小了也很小，我不太想给你们太过于学术的说法，由于你也不可能背这个答案，过去了直接说吧。仍是说的简单一点，你们本身到时候知道怎么回答就好了。

系统拆分分布式系统，拆成多个服务，拆成微服务的架构，拆不少轮的。上来一个架构师第一轮就给拆好了，第一轮；团队继续扩大，拆好的某个服务，刚开始是1我的维护1万行代码，后来业务系统愈来愈复杂，这个服务是10万行代码，5我的；第二轮，1个服务 -> 5个服务，每一个服务2万行代码，每人负责一个服务。

若是是多人维护一个服务，<=3我的维护这个服务；最理想的状况下，几十我的，1我的负责1个或2~3个服务；某个服务工做量变大了，代码量愈来愈多，某个同窗，负责一个服务，代码量变成了10万行了，他本身不堪重负，他如今一我的拆开，5个服务，1我的顶着，负责5我的，接着招人，2我的，给那个同窗带着，3我的负责5个服务，其中2我的每一个人负责2个服务，1我的负责1个服务。

我我的建议，一个服务的代码不要太多，1万行左右，两三万撑死了吧！

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

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

扯深了实在很深，因此这里先给你们举个例子，你本身感觉一下，核心意思就是根据状况，先拆分一轮，后面若是系统更复杂了，能够继续分拆。你根据本身负责系统的例子，来考虑一下就行了。

（3）拆分后不用dubbo能够吗？

固然能够了，大不了最次，就是各个系统之间，直接基于spring mvc，就纯http接口互相通讯。可是这个确定是有问题的，由于http接口通讯维护起来成本很高，你要考虑超时重试、负载均衡等等各类乱七八糟的问题，好比说你的订单系统调用商品系统，商品系统部署了5台机器，你怎么把请求均匀地甩给那5台机器？这不就是负载均衡？你要是都本身搞那是能够的，可是确实很痛苦。

因此dubbo说白了，是一种rpc框架，就是本地就是进行接口调用，可是dubbo会代理这个调用请求，跟远程机器网络通讯，给你处理掉负载均衡了、服务实例上下线自动感知了、超时重试了，等等乱七八糟的问题。那你就不用本身作了，用dubbo就能够了。