面试官们“爱不释手”的分布式系统架构到底是个什么鬼?

2019-10-08 02:06

  假设原来我们有一个系统,代码量30多万行。现在拆分成20个小系统,每个小系统1万多行代码。

  原本代码之间都是直接基于Spring框架走JVM内存调用,现在拆开来,将20个小系统部署在不同的机器上,然后基于分布式服务框架(比如dubbo)搞一个rpc调用,接口与接口之间通过网络通信来进行请求和响应。

  所以分布式系统很重要的特点就是服务间要跨网络进行调用,我们来看下面的图:

  比如hadoop hdfs(分布式存储系统)、spark(分布式计算系统)、storm(分布式流式计算系统)、elasticsearch(分布式搜索系统)、kafka(分布式发布订阅消息系统)等。

  分布式业务系统,把原来用java开发的一个大块系统,给拆分成多个子系统,多个子系统之间互相调用,形成一个大系统的整体。

  举个例子,假设原来你做了一个OA系统,里面包含了权限模块、员工模块、请假模块、财务模块,一个工程,里面包含了一堆模块,模块与模块之间会互相去调用,1台机器部署。

  现在如果你把他这个系统给拆开,权限系统,员工系统,请假系统,财务系统,4个系统,4个工程,分别在4台机器上部署。

  然后一个请求过来,完成这个请求,员工系统去调用权限系统,调用请假系统,调用财务系统,4个系统分别完成了一部分的事情。

  最后4个系统都干完了以后,才认为是这个请求已经完成了。这就是所谓的分布式业务系统。

  有的同学可能要问了,我一台服务器跑的好好的,所有系统一个工程全部搞定,多好。为啥一定要去搞什么分布式系统架构,互相调用还要走远程,似乎还增加了不少工作量?

  很多年前,在没有走分布式架构的时候,我待的这家公司的各个业务线都是垂直的 “烟囱式” 项目。

  随着互联网的快速发展,公司的业务也在不断的发展,注册用户增加、网站应用的功能、规模不断扩大,特别是移动互联网的发展,APP、微信、自助终端机等访问渠道的增加,各种新业务,新需求不断涌入,系统遇到了各种各样的问题。

  首先是项目工程无节制的变得臃肿庞大,系统复杂度增加,大几十万行代码,几十个开发人员,service层,dao层代码大量被copy使用,经常各种代码合并冲突问题要处理,非常耗费时间。

  经常是我改动了我的代码,别人调用了我的接口,导致他的代码也出现问题,需要重新测试,麻烦的要死。

  然后每次发布都是几十万行代码的系统一起发布,大家得一起提心吊胆准备上线,几十万行代码的上线,每次上线都要做很多的检查,很多异常问题的处理,每个人都高度紧张,被搞得几乎崩溃。

  而且如果我现在有个新业务,打算把相关依赖升级一下,比如升级到最新的spring版本,还不行,因为这可能导致别人的代错,不敢随意乱改技术。并且一个web工程每次启动都需要好分钟的时间,本地IDE里面调试一次代码都很痛苦。

  其次,随着用户访问流量的增加,系统负载压力变大,变得不堪重负,通过增加实例数,增加硬件扩容能够带来的效果已微乎其微,故障频发,效率低下。系统质量也越来越难以保证,测试周期也变得越来越长,无法满足公司业务发展的需要。

  以上就是以前待过的公司一些 “不堪回首” 的往事,总得来说,问题主要体现在以下几个方面:

  好,既然我们已经深刻体会到了系统耦合的痛苦,那么现在就来看看,系统拆分后带来的好处:

  几十万行代码的系统,假设拆分成20个服务,平均每个服务就1-3万行代码,每个服务部署到单独的机器上。20个工程,就用20个git仓库代码,20个开发人员,每个人维护自己的那个服务就可以了。

  技术上想怎么升级就怎么升级,保持接口定义不变,输入输出内容不变就可以了,爽!

  总结起来一句话,分布式系统拆分之后,可以大幅度提升复杂系统大型团队的开发效率。三、系统如何进行拆分?

  一般来说,将系统进行拆分,首先需要对系统整体比较熟悉。可以走多轮拆分的思路,第一次拆分就是将以前的各个大的模块粗粒度的拆分开来。

  比如一个电商系统可以拆分成订单系统、商品系统、店铺系统、会员系统、促销系统、支付系统等等。

  后面可能每个系统又变得越来越复杂了,比如说订单系统又可以进一步拆分出来购物车系统,库存系统,价格系统等。

  总得来说就是基于领域驱动设计的思想以及实战经验总结,同时参考业界一些常规做法,大家讨论着来进行拆分,逐步优化,多轮拆分,小步快跑,最终达到一个比较好的状态。

  首先就是分布式服务框架的选用,目前国内来讲主流的还是dubbo与spring cloud。

  我们来思考一下,使用服务框架主要用来解决什么问题呢?如果不用dubbo或者spring cloud是否可以做分布式架构呢?

  不用dubbo或者spring cloud等服务框架当然也是可以的,但是这就需要自己处理很多事情了。

  比如,各个子系统走restful接口调用,那么就是http调用,这时比如传送过去一个对象,就要自己搞成一个json,然后一次调用失败后重试怎么做?

  另外,一般来说都是集群部署,目标系统有多个实例,那么自己还要写一个负载均衡算法,如何每次随机从多个目标机器中挑选一个来调用?

  还有,如果目标系统扩容新部署了一个实例,或者服务器故障下线了一个实例,如何动态让调用方感知到呢? 诸如此类的很多问题,如果不用服务框架的话,自己这么瞎搞,会遇到各种各样的问题。

  如果选用了某一个分布式服务框架,就需要深入的掌握这个框架的使用与底层原理,比如 dubbo 就需要搞明白以下的一些问题:

  dubbo服务接口的幂等性如何设计(比如不能重复扣款,不能重复生成订单,不能重复创建卡号)?

  使用spring cloud也是一样,比如eureka的工作原理?feign声明式调用的原理?等等各种底层原理要搞懂。

  以上这些问题,往深了说,每一个点都需要可能 N 篇文章来详细阐述,这里没法逐一展开,后面我们会继续通过一些文章,聊一聊这些分布式架构下的各种技术问题。国内原创令人期待国际大戏极具吸引力,香港广州卓振智能科技有限公司