前言
互联网时代，分布式是一个绕不过去的话题。本文将谈谈个人对分布式的理解。
何为分布式
维基百科上对分布式系统（Distributed System）的定义如下：
A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system. The components interact with one another in order to achieve a common goal.
简单翻译一下：分布式系统内部会包含多个组件，它们位于不同的机器之上。这些机器之间会通过传递消息来进行通信协作，整个系统像一个整体一样对外界提供服务。
为什么需要分布式
与分布式系统相对应的是单体系统。何为单体系统？即所有组件 / 模块都位于同一台机器之上系统。试想一下，如果有一台理想的机器，算力无限，内存无限，带宽无限，存储空间无限且永不宕机，那我们还会引入分布式吗？显然不会，这台机器已经能满足我们所有的需求。理想很丰满，现实很骨感：不可能存在这样的机器，单机资源无法无限制的扩充。业务不断发展，应用体量不断扩大，单机性能无法支撑超大流量时，无奈，分布式是我们唯一的选择。如果一台机器资源有限，多增加几台机器不就行了吗？单台机器有宕机风险，多找几台机器做备份不就行了吗？
高可用 / 灾备
高可用（High Availability）是应用系统的永恒追求。这里说的高可用不仅仅要求服务“活着”，而是要求对于每个请求，服务都能在给定时间内返回正确的结果。分布式系统通常以集群（Cluster）的形式出现。集群可以分为几类：
- 服务型集群：比如通过负载均衡（load balance）将多台
API机器挂在同一个vip下面，便组成了一个服务集群。当其中某台机器宕机，并不影响整体的服务。 - 存储型集群：备份是分布式存储的一个重要模块，比如
Master - Slave模式，避免因为数据丢失导致服务不可用。
集群是高可用的一大保障，但是毕竟它也是由一台台单独的机器组成的。单台机器的宕机，或者网络环境异常的抖动，可以通过集群来应对；但如果遇上了天灾，整个集群都挂了呢？这要求应用有一定的容灾能力，通常采取的方案是，将整套系统在不同的数据中心分别部署一套来做灾备。不过理论上来说，就算有了灾备，依然无法保证应用的百分百可用（极端点的例子是地球毁灭了，部署在地球上的系统当然全挂了），所以很多公司的运维人员对可用性要求都是“几个九”，如“四个九”表示应用需要在 99.99% 的时间内都是可用的，即每年允许的服务不可用时间小于 365 * 24 * 60 * 0.01% = 52 分钟。
易扩容
单台机器的资源–或者说能被操作系统识别的资源，是有限的，如 Windows 10 能支持的硬盘最大容量是 16TB。随着科技的发展，未来或许可以突破某些限制，不过纵向扩容终归有一个极限。相比之下，横向扩容就显得容易得多。特别是当服务容器化等技术的成熟，服务的扩展变得异常容易。分布式系统本质上是对单机系统的资源扩充，如数据库分库分表是对硬盘的扩充，大数据领域的 Hadoop 是对硬盘（HDFS / Hive）和 CPU 的扩充，而 CDN 可以看成是对带宽 / 网卡的扩充。一般来说，当集群性能达到瓶颈时，只需要适当添加机器即可。
微服务化
随着应用体量的增大，如何将其“分布式化”，理论上来说其实有两个方案。举个耳熟能详的商城系统的例子，给你10台机器来部署服务，我们可以选择在每台机器上分别部署一份几百兆的大而全的商城服务；也可以选择将商城服务切分，选择2台机器部署用户服务，2台机器部署订单服务，2台机器部署支付服务…为了“可持续发展”，相信没人会选择第一套方案吧。第二套方案，即微服务化（Micro Service）拆分，也就成了“分布式化”的必经之路。一般来说各个微服务之间应该是相互独立的，彼此之间通过网络通信，这样有很多好处：
- 各个微服务可以采用自己合适的架构 / 语言，只需要保持对外的接口一致或遵循相同的通信协议即可。
- 每个微服务体量相对较小，可以有自己独立的团队运维，面向
DevOps模式。 - 单个微服务出现错误，在熔断机制的保护下，不会对整体服务的可用性造成太大的影响。
流行的微服务框架有 Dubbo，Spring Cloud，所以在分布式盛行的今天，这两个框架既是基础，也是重中之重。
分布式的问题
分析下来，似乎分布式系统的好处非常多啊，那为什么我们只有在应用太庞大之后，无奈之下才选择分布式呢？因为分布式的引入，会使得问题的复杂度提高几个量级。根据CAP定理，在分布式系统中，可用性，一致性不可得兼，这点就需要应用设计者做好权衡。同时分布式锁，分布式事务，分布式全局ID，分布式Session，分布式一致性问题等等都是面试中的常客。究其原因在于分布式环境中，网络状况是不稳定的，每台机器都有宕机风险，当前机器无法知道其他机器的准确状况。所以简单的应用，应当尽量避免引入分布式。
总结
广义上来说，任何由不同机器来协作提供共同服务的系统，都可以称作是分布式系统。就像多细胞生物是生命发展的必经途径一样，分布式是应用发展的必然选择，不过它也带来了更高的复杂度，对人们的架构设计和编程能力有了更高的要求。
参考
Windows 10 Size and Hard Drive Size
