什么是分布式系统?

形形色色的分布式系统

近些年来，各种高大上的系统架构图越来越频繁地出现，你的眼前充斥着各种主流、非主流的眼花缭乱的技术框架。你不由得肃然起敬一番，心中呐喊着：“对，这就是我想去的地方，我想参与甚至实现一个这样牛逼的分布式系统，再也不想每天只是增删改查了。”

分布式系统等于SOA,ESB,微服务这些东西吗?

如果提到分布式系统,你一下子想到的是上面这类技术,那么你把服务化的模式和分布式系统做了错误的联系

服务化就像企业当中将相同岗位的人员划分到同一个部门管理,以提高人员利用率和劳动成果的复用度。服务化的本质是“分治”，而“分治”的前提是先要拆，然后才谈得上如何治。这时，高内聚、低耦合的思想在拆分过程中起到了一个非常重要的作用，因为这可以尽可能地降低拆分后不同组件间进行协作的复杂度。所以重要的是“怎么拆“，还有如何循序渐进地拆，而这个过程中你究竟是采用了何种服务化模式（比如 SOA、ESB、微服务等）并不是关键。

可以看到服务化体现了“分治”的效果，这也是分布式系统的核心思想，因此从“分治”这个本质上来看，服务化的确是分布式系统，但分布式系统不仅仅停留在那些服务化的模式上。

分布式系统是各种中间件吗?

听到分布式系统，你可能还会想到了某某 MQ 框架、某某 RPC 框架、某某 DAL 框架，把运用中间件和分布式系统错误地划上了等号。

这里需要搞清楚的是，中间件起到的是标准化的作用。中间件只是承载这些标准化想法的介质、工具，可以起到引导和约束的效果，以此起到大大降低系统复杂度和协作成本的作用。我们来分别看一下：

• MQ 框架标准化了不同应用程序间非实时异步通信的方式。
• RPC 框架标准化了不同应用程序间实时通讯的方式。
• DAL（Data Access Layer，数据访问层）框架标准化了应用程序和数据库之间通讯的方式。

所以，虽然分布式系统中会运用中间件，但分布式系统却不仅仅停留在用了什么中间件上。你需要清楚每一类中间件背后是对什么进行了标准化，它的目的是什么，带来了哪些副作用，等等。只有如此，你才能真正识别不同技术框架之间的区别，找到真正适合当前系统的技术框架。

列举这些现象只是想说，我们在认知一个分布式系统的时候，内在胜于表象，掌握一个扎实的理论基本功更为重要。不要因追逐“术”而丢了“道”。没有“道”只有“术”是空壳，最终会走火入魔，学得越多，会越混乱，到处都是矛盾和疑惑。

分布式系统

维基百科的定义

分布式系统是一种其组件位于不同的联网计算机上的系统，然后通过互相传递消息来进行通信和协调。为了达到共同的目标，这些组件会相互作用。

所以,“单程序 + 单数据库”就是一个最简单的分布式系统。因为我们所编写的程序运行时所在的进程，和程序中使用到的数据库所在的进程，并不是同一个。“一分为二”和“一分为 N”本质上并没有区别。所以，很多小项目或者大型项目的初期所搭配的基础套餐“单程序 + 单数据库”，同样可以理解为分布式系统，其中遇到的问题很多同样也存在于成熟的分布式系统中。比如 :

• log 记录执行成功，但是数据库的数据没发生变化；
• 进程内的缓存数据更新了，但是数据库更新失败了。

分布式系统会碰到的几个典型的问题(坑):

• 网络并不是可靠的
• 不同节点之间的通信是存在延迟的
• 带宽是有上限的
• 分布式并不直接意味着是“敏捷开发”了
• 数据由一份冗余成多份后如何保持一致
• 整个系统的不同部分可能是异构的

网络并不是可靠的

光缆被挖断的事件相信你也看到过不是一两次了。除此之外，网卡异常、交换机故障、遭受恶意攻击等导致的网络拥塞、网络中断、报文丢失的种种迹象皆意味着网络随时可能无法正常运作，是不可靠的。

系统设计中，尽可能地考虑到：当前节点所依赖的其他节点由于各种原因无法与之正常通信时，该如何保证其依然能够提供部分或者完整的服务。

不同节点之间的通信是存在延迟的

不同节点之间的通信是需要经过一段时间的，也就意味着会存在延迟。具体的延迟是由所用的传输介质、节点当前的负载大小所决定的。不能以调用本地方法一样的认知去理解远程调用。

并不是将一个集中式系统拆分得越散，系统就越快。

带宽是有上限的

1. 实际环境中的传输速率大小，是由服务商所提供的带宽大小，以及网卡、网卡、交换机、路由器所支持的传输速率中的最小值决定的。
2. 内网与外网传输速率是不同的，一般都是内网大于外网。因为服务商所提供的带宽成本更高。
3. 同一个局域网内的节点是公用外网出入口的，所以尽可能的缩小在外网传输的数据，以降低占用“独木桥”外网的空间。

分布式并不直接意味着是“敏捷”了

很久以前曾经有过这样的想法，当在规模较大的集中式系统中工作的时候，每次和许多人在一个代码库里提交代码，老是遇到冲突、排队等待上游模块先开发等等。这时你会想，如果改造成分布式系统，这些问题都没了，工作效率高多了。

拆分后需要做的额外工作如果没做好，可能会导致不是更快，而是更慢。最典型的现象如：

• 发布更麻烦了。
• 排查问题更难了。

建设协作相关的辅助性工作与分布式系统同时进行。比如：监控告警系统、配置中心、服务发现，以及批量部署、持续集成，甚至 DevOps 等。

数据由一份冗余成多份后如何保持一致

这点其实是由于前面提到的网络因素产生的连带效应。

当遇到数据库压力增大，响应开始变慢的时候，你可能会很容易想到，让 DBA 来做个主从啊。但是，由于网络不可靠、存在延迟、带宽有上限这一系列因素。所以，这个看似只是 Copy 一下工作，需要我们花大量的精力去解决如何保证在使用不同副本上的数据的时候，都是符合应有的预期的。