什么是分布式架构

一、分布式架构定义

什么是分布式架构

分布式系统（distributed system） 是建立在网络之上的软件系统。

内聚性：是指每一个数据库分布节点高度自治，有本地的数据库管理系统。

透明性：是指每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程。

在分布式数据系统中，用户感觉不数据是分布的，即用户不须知道关系是否分割，有无副本，数据存在于那个站点以及事物在哪个站点上执行。

简单来说：在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。

假设原来我们有一个系统，有100万行代码。现在拆分成20个小系统，每个小系统仅剩5万行代码。

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

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

此外，分布式系统大概可以分成两类。

1.底层的分布式系统

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

2、分布式业务系统

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

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

现在你将这个系统拆分为，权限系统、请假系统、员工系统、财务系统，4个系统，4个工程，分别在4台机器上部署。

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

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

同样，我们画一张图，感受一下上述过程：

二、分布式架构的意义 

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

        下面我要以我曾经待过一个公司的血泪经历为例，来聊聊这个问题。

很多年以前，在没有走分布式架构的时候，我待的这家公司的整个业务都是垂直烟囱似的的项目。

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

        首先是项目工程无节制的变得臃肿庞大，今天增加一个业务，明天扩展一个模块，系统复杂度增加，大几十万行代码，几十个开发人员，service层，dao层代码大量被copy使用，经常有各种代码合并冲突要处理，非常耗时间。经常是我改动了自己的代码，但别人调用了我的接口，导致他的代码也出现问题，需要重新测试，麻烦的要死。

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

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

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

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

        1、应用代码耦合严重，功能难以扩展;

        2、新需求开发交付周期延长，测试工作量大；

        3、新加入团队的成员需要很长时间才能熟悉系统；

        4、升级维护也很困难（改动任何一点地方都需要升级整个系统）

        5、系统性能提升艰难，可用性低，不稳定

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

        百万行代码拆分成20个服务子系统，平均每个服务也就5万行代码，每个服务部署到单独的机器上，20个工程就用20个git仓库代码，20个开发人员，每个人维护自己那个服务就可以。

        1、自己维护自己的代码，再也不需要考虑代码冲突，爽；

        2、每次只需要测试自己的代码就好了，爽；

        3、每次修改后只需要发布自己的服务就可以，爽；

        4、技术上可以随心所欲的升级，保持接口定义不变，输入输出不变就好，还是爽；

        总结起来就一句话，拆分成分布式系统之后，可以大幅度提升复杂系统大型开发团队的效率。

三、系统如何拆分

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

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

        后面可能每个系统又变的复杂，比如说订单系统又可以拆分成购物车系统，库存系统，价格系统等。

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

四、分布式之后带来的技术挑战

        首先就是分布式框架的选用，目前国内主流的还是dubbo和spring cloud。

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

        不用dubbo和spring cloud等服务框架当然也是可以的，但是这就需要自己处理很多事情了。比如，各个子系统走restful接口调用，那么就是http调用，这时比如传送过去一个对象，就要自己搞成一个json，然后一次调用失败后重试怎么做？

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

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

俗话说的好站在巨人的肩膀上才能看的更远，有现成的技术不用白不用。

        上述过程，用一张图给大家呈现一下：

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

        1、dubbo的工作原理

        2、dubbo支持的序列化协议

        3、dubbo的负载均衡和高可用策略，动态代理策略

        4、dubbo的SPI思想

        5、如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试

        6、dubbo服务接口请求的顺序性如何保证

        7、dubbo服务接口的幂等性如何设计（比如不能重复扣款、不能重复生成订单、不能重复创建卡号）

        8、如何自己设计一个类似dubbo的rpc框架

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

        还有其他一些走分布式框架后常见的要解决的问题：

       分布式会话、分布式锁、分布式事务、分布式搜索、分布式缓存、分布式消息队列、统一配置中心、分布式存储、分库分表、限流、熔断、降级等。