所谓分布式系统，是指硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。我们从这个定义中可以看出分布式系统包含两个区别于单块系统的本质性特征，一个是网络，分布式系统的所有组件都位于网络之中，对于互联网应用而言，则位于更为复杂的互联网环境中；另一个是通信和协调，与单块系统不同，位于分布式系统中的各个组件只有通过约定、高效且可靠的通信机制进行相关协作才能完成某一项业务功能。这是我们在设计和实现分布式系统时首先需要考虑的两个方面。下图展示的就是从软件开发视图出发得到的一个典型的分布式系统，包含了分布式服务、消息中间件和分布式缓存等常见的用于构建分布式系统的技术实现方式。显然，这些工具位于一个封闭或开放的网络环境中，相互之间通过服务的注册和发现、消息传递、数据的缓存共享等机制完成协作。

在分布式系统中，我们为了打破单块系统中集中式的系统架构，引入系统拆分的思想和实践。拆分的需求来自组织结构变化、交付速度、业务需求以及技术需求所引起的变化，一般认为系统拆分的基本思路有两种，即纵向（Vertical）拆分和横向（Horizontal）拆分。

所谓纵向拆分，就是将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的应用系统即可。如下图中，我们可以将移动医疗系统中的预约挂号业务拆分成订单、医院和用户等独立业务子系统。纵向拆分关注于业务，通过梳理产品线，将内聚度较高的相关业务进行剥离从而形成不同的子系统。

相较纵向拆分的面向业务特性，横向拆分更多关注于技术。通过将可以复用的业务拆分出来并独立部署为分布式服务，只需调用这些分布式服务即可构建复杂的新业务。所以，横向拆分的关键在于识别可复用的业务，设计服务接口并规范服务依赖关系。横向拆分的的基本实现方式是构建分布式服务体系，下图是对上图中的预约挂号业务进行横向拆分的结果。可以看到，当我们把订单、医生、号源和用户等业务抽象成独立的垂直化服务，并在各个服务上层实现分布式环境下的调用和管理框架，系统的业务就可以转变为一种排列组合的构建方式。如基于订单和支付服务，我们可以构建出业务1，而业务2可能只依赖于医院和用户管理服务。分布式服务框架提供了一种按需构建的机制，在保证各个分布式服务的技术、团队、交付独立发展的前提下，确保业务整合的灵活性和高效性。

然而，分布式系统相较于集中式系统而言具备优势的同时，也存在一些我们不得不考虑的特性，包括但不限于：

1. 网络传输的三态性

构建分布式系统依赖网络通信，而网络通信表现为一个复杂且不可控的过程。相比与单机系统中函数式调用的失败或者成功，网络通信会出现“三态”的概念，即成功、失败与超时。由于网络原因，消息没有成功发送到接收方，而是在发送过程就发生了丢失现象；或者接收方处理后，响应给发送方的过程中发生消息丢失现象。这些问题都会增加通信的代价，如何使通信的代价降到用户可以忍耐的层次是分布式系统设计的重要目标。

2. 异构性

相较单块系统，分布式系统由于基于不同的网络、操作系统、软件实现技术体系，必须要考虑一种通用的服务集成和交互方式来屏蔽异构系统之间的差异。异构系统之间的不同处理方式会对系统设计和开发带来难度和挑战。

3. 负载均衡

在集中式系统中，各部件的任务明确。但是分布式系统是多机协同工作的系统，为了提高系统的整体效率和吞吐量，必须考虑最大程度发挥每个节点的作用。负载均衡是保证系统运行效率的关键技术。

4. 数据一致性

在分布式系统中，数据被分散或者复制到不同的机器上，如何保证各台主机之间的数据一致性将成为一个难点。因为网络的异常会导致分布式系统中只有部分节点能够正常通信，从而形成了网络分区（Network Partition）。

5. 服务的可用性

分布式系统中的任何服务器都有可能出现故障，且各种故障不尽相同。而运行在服务器上的服务也可能出现各种异常情况，服务之间出现故障的时机也会相互独立。通常，分布式系统要设计成允许出现部分故障而不影响整个系统的正常可用。

以上问题是分布式系统的基本特性，我们无法避免，只能想办法进行利用和管理，这就给我们设计和实现分布式系统提出了挑战。

如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型，或扫描下面的二维码。

我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流