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