分布式系统并不是什么新鲜词，在上个世纪七八十年代就已经有各种分布式系统出现。只是在互联网时代，分布式系统才大放异彩，尤其是Google更是把分布式系统运用到了极致。Google整个的软件构架都是基于各种各样的分布式系统，诸如Borg、 MapReduce、BigTable等。正是这些分布式系统，使得Google可以处理高并发请求响应以及海量数据处理等。Apache旗下的 Hadoop、Spark、Mesos等分布式系统，把大数据处理相关技术变得非常亲民，让更多企业客户体会到了分布式系统的便利。
分布式系统的特点
分布式系统最大的特点是可扩展性，它能够适应需求变化而扩展。
企业级应用需求经常随时间而不断变化，这也对企业级应用平台提出了很高的要求。企业级应用平台必须要能适应需求的变化，即具有可扩展性。比如移动互联网2C应用，随着互联网企业的业务规模不断增大，业务变得越来越复杂，并发用户请求越来越多，要处理的数据也越来越多，这个时候企业级应用平台必须能够适应这些变化，支持高并发访问和海量数据处理。分布式系统有良好的可扩展性，可以通过增加服务器数量来增强分布式系统整体的处理能力，以应对企业的业务增长带来的计算需求。
分布式系统的核心理念是让多台服务器协同工作，完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务。
分布式系统由独立的服务器通过网络松散耦合组成的。每个服务器都是一台独立的PC机，服务器之间通过内部网络连接，内部网络速度一般比较快。因为分布式集群里的服务器是通过内部网络松散耦合，各节点之间的通讯有一定的网络开销，因此分布式系统在设计上尽可能减少节点间通讯。此外，因为网络传输瓶颈，单个节点的性能高低对分布式系统整体性能影响不大。比如，对分布式应用来说，采用不同编程语言开发带来的单个应用服务的性能差异，跟网络开销比起来都可以忽略不计。因此，分布式系统每个节点一般不采用高性能的服务器，而是性能相对一般的普通PC服务器。提升分布式系统的整体性能是要通过横向扩展(增加更多的服务器)，而不是纵向扩展(提升每个节点的服务器性能)。
分布式系统最大的特点是廉价高效。
由成本低廉的PC服务器组成的集群，在性能方面能够达到或超越大型机的处理性能，在成本上远低于大型机。这也是分布式系统最吸引人之处。成本低廉的PC服务器在硬件可靠性方面比大型机相去甚远，于是分布式系统由软件来对硬件进行容错，通过软件来保证整体系统的高可靠性。
分布式系统最大的好处是实现企业应用服务层面的弹性扩展。
应用服务层面的弹性扩展是相对计算资源层面的弹性扩展而言的。一般公有云服务(IaaS)厂商都会提供计算资源层面的弹性扩展，比如可以很方便地增加或删除虚拟主机、提升或降低虚拟主机的性能配置等等。但是企业客户真正需要的是应用服务层面的弹性扩展，即随着业务量的涨落，后台应用服务的实例能动态变化，这是IaaS厂商还做不到的。比如，某移动互联网短视频分享应用，在晚间11点到凌晨1点是访问高峰，同时在线人数高达几十万，这时后台应用服务要扩张到数千个实例才能应付这么高并发的访问请求;过了高峰时段，后台应用服务可以收缩到几十个实例。有了分布式系统，就可以很方便地调度应用服务实例，从几十个到几百个甚至上千个，真正实现应用服务的弹性扩展。
分布式系统的设计理念
上面简单介绍了分布式系统的基本情况，下面详细阐述笔者理解的几个分布式系统设计理念：
分布式系统对服务器硬件要求很低
这一点主要现在如下两个方面：
对服务器硬件可靠性不做要求，允许服务器硬件发生故障，硬件的故障由软件来容错。所以分布式系统的高可靠性是由软件来保证;
对服务器的性能不做要求，不要求使用高频CPU、大容量内存、高能存储等等。因为分布式系统的性能瓶颈在于节点间通讯带来的网开销，单台服务器硬件性能再好，也要等待网络IO。
一般而言，互联网公司的大型数据中心都是选用大量廉价的PC服务器而不是用几台高性能服务器搭建分布式集群，以此来降低数据中心成本。比如，Google对于数据中心的成本控制做到了极致：所有服务器一律不要机箱;主板完全定制，只要最基本的组件，早期的定制主板连电源开关和USB接口都不要;在主板上加装隔离带把CPU单独隔出来，让冷风只吹CPU，不吹内存、硬盘等不需要降温的组件，最大限度降低冷却电力消耗。
分布式系统强调横向可扩展性
横向可扩展性(Scale Out)是指通过增加服务器数量来提升集群整体性能。纵向可扩展性(Scale Up)是指提升每台服务器性能进而提升集群整体性能。纵向可扩展性的上限非常明显，单台服务器的性能不可能无限提升，而且跟服务器性能相比，网络开销才是分布式系统最大的瓶颈。横向可扩展性的上限空间比较大，集群总能很方便地增加服务器。而且分布式系统会尽可能保证横向扩展带来集群整体性能的(准)线性提升。比如有10台服务器组成的集群，横向扩展为100台同样服务器的集群，那么整体分布式系统性能会提升为接近原来的10倍。
互联网公司的数据中心，一般一个分布式系统横向扩展的上限在万台服务器左右。Google数据中心的基本单元，CELL，由两万台左右服务器组成，每个CELL由一套分布式管理系统，BORG，统一管理，每个数据中心都由多个CELL组成。
分布式系统不允许单点失效(No Single Point Failure)
单点失效是指，某个应用服务只有一份实例运行在某一台服务器上，这台服务器一旦挂掉，那么这个应用服务必然也受影响而挂掉，导致整个服务不可用。例如，某网站后台如果只在某一台服务器上运行一份，那这台服务器一旦宕机，该网站服务必然受影响而不可用。再比如，如果所有数据都存在某一台服务器上，那一旦这台服务器坏了，所有数据都不可访问。
因为分布式系统的服务器都是廉价的PC服务器，硬件不能保证100%可靠，所以分布式系统默认每台服务器随时都可能发生故障挂掉。同时分布式系统必须要提供高可靠服务，不允许出现单点失效，因此分布式系统里运行的每个应用服务都有多个运行实例跑在多个节点上，每个数据点都有多个备份存在不同的节点上。这样一来，多个节点同时发生故障，导致某个应用服务的所有实例都挂掉、或某个数据点的多个备份都不可读的概率大大降低，进而有效防止单点失效。
通常情况，不要让服务器满负荷运行，服务器长时间满负荷运行的话，出故障的概率显著升高。所以分布式系统采用一大堆中低性能的PC服务器，尽可能把负载均摊到所有服务器上，让每台服务器的负载都不高，保证集群整体稳定性。
分布式系统尽可能减少节点间通讯开销
如前所述，分布式系统的整体性能瓶颈在于内部网络开销。目前网络传输的速度还赶不上CPU读取内存或硬盘的速度，所以减少网络通讯开销，让CPU尽可能处理内存的数据或本地硬盘的数据，能显著提高分布式系统的性能。典型的例子就是Hadoop MapReduce，把计算任务分配到要处理的数据所在的节点上运行，从而避免在网络上传输数据。
分布式系统应用服务最好做成无状态的
应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。分布式应用服务最好是设计成无状态。因为如果应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上，这样应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后恢复应用服务。
比如，在设计网站后台的时候，对于用户登陆请求，可以把登陆用户的session相关信息保存在Redis或Memcache等缓存服务中，这样每个网站的后台实例不保存用户登录状态，这样即使重启网站后台程序也不丢失用户的登录状态信息;如果把用户的session相关信息保存在网站后台程序的内存里，那一旦受理用户登录的网站后台程序实例挂掉，必然有用户的登录状态信息会丢失。
总而言之，分布式系统是大数据时代企业级应用的首选平台，它有良好的可扩展性，尤其是横向可扩展性(Scale Out)，使得分布式系统非常灵活，能应对千变万化的企业级需求，而且降低了企业客户对服务器硬件的要求，真正能做到应用服务层面的弹性扩展(auto- scaling)。
