分布式架构演进之路

1 相关概念

在正式引入架构演进之前，我们对其中一些比较重要的概念做前置介绍。

1.1 基本概念

应用（Application）/ 系统（System）

为了完成一整套服务的一个程序或者一组相互配合的程序群。

生活例子类比：为了完成一项任务，而搭建的由一个人或者一群相互配的人组成的团队。

模块（Module）/ 组件（Component）

当应用较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。

生活例子类比：军队中为了进行某据点的攻克，将人员分为突击小组、爆破小组、掩护小组、通信小组等。

分布式（Distributed）

系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如 Web 服务器与数据库分别工作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。

生活例子类比：为了更好的满足现实需要，一个在同一个办公场地的工作小组被分散到多个城市的不同工作场地中进行远程配合工作完成目标。跨主机之间的模块之间的通信基本要借助网络支撑完成。

集群（Cluster）

被部署于多台服务器上的、为了实现特定目标的一个/一组特定的组件，整个整体被称为集群。比如多个 MySQL 工作在不同服务器上，共同提供数据库服务目标，可以被称为一组数据库集群。

生活例子类比：为了解决军队攻克防守坚固的大城市的作战目标，指挥部将大批炮兵部队集中起来形成一个炮兵打击集群。

分布式vs 集群：通常不用太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即工作在不同服务器上并且通过网络通信配合完成任务；而集群更在意逻辑形态，即是否为了完成特定服务目标。

主（Master）/ 从（Slave）

集群中，通常有一个程序需要承担更多的职责，被称为主，其他承担附属职责的被称为从。比如 MySQL 集群中，只有其中一台服务器上数据库允许进行数据的写入 (增/删/改)，其他数据库的数据修改全部要从这台数据库同步而来，则把那台数据库称为主库，其他数据库称为从库。

中间件（Middleware）

一类提供与业务无关的服务（功能更通用的服务），比如数据库、缓存（Redis 通常扮演的角色）、消息队列等。

生活例子类比：一家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变大，成立一个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁。

1.2 评价指标

可用性（Availability)

考察单位时间段内，系统可以正常提供服务的概率/期望，即系统整体可以提供服务的时间 / 系统总的时间。例如: 年化系统可用性 = 系统正常提供服务时长 / 一年总时长。

这里暗含着一个指标，即如何评价系统提供无法是否正常，我们就不深入了。平时我们常说的 4个9 即系统可以提供 99.99% 的可用性，5个9则是 99.999% 的可用性，以此类推。我们平时只是用高可用(High Availability HA) 这个非量化目标简要表达我们系统的追求。

可用性是一个系统最重要的评价指标，我们平时用高可用 (High Availability HA) 这个非量化目标简要表达我们系统的追求。

响应时长（Response Time RT）

指用户完成输入到系统给出用户反应的时长，用于衡量服务器的性能。

例如：点外卖业务的响应时长 = 拿到外卖的时刻 - 完成点单的时刻。通常我们需要衡量的是最长响应时长、平均响应时长和中位数响应时长。这个指标原则上是越小越好，但很多情况下由于实现的限制，需要根据实际情况具体判断。

吞吐（Throughput）&& 并发（Concurrent）

吞吐考察单位时间段内，系统可以成功处理的请求的数量。并发指系统同一时刻支持的请求最高量。

例如：一条辆车道高速公路，一分钟可以通过 20 辆车，则并发是2，一分钟的吞吐量是 20。实践中，并发量往往无法直接获取，很多时候都是用极短的时间段 (比如1秒) 的吞吐量做代替。我们平时用高并发 (Hight Concurrnet) 这个非量化目标简要表达系统的追求。

2 架构演进

2.1 单机架构

单机架构是指公司所有的服务都部署在一台服务器上，包括应用服务和数据库服务。公司在创业初期，需要利用精干的技术团队，快速将业务系统投入市场进行检验，并且可以迅速响立变化要求。但好在前期用户访问量很少，没有对我们的性能、安全等提出很高的要求，而且系统架构简单，无需专业的运维团队，所以选择单机架构是合适的。

服务访问：用户在浏览器中输入 www.github.com，首先经过 DNS 服务将域名解析成 IP 地址 10.102.41.1，随后浏览器访问该 IP 对应的应用服务。

现在的计算机硬件飞速发展，单台主机的性能也十分客观，能够支持很高的并发以及大容量的存储，因此大多数中小型公司的产品使用的就是单机架构，我们目前接触到的基本也都是单机架构。

相关软件：

• Web 服务器软件: Tomcat、Netty、 Nginx、Apache等。
• 数据库软件: MySQL、Oracle、PostgreSQL、SQL Server等。

2.2 应用数据分离架构

应用数据分离架构是指将应用服务与数据库服务分别部署到不同的服务器上。随着系统的上线，我们不出意外地获得了成功。市场上出现了一批忠实于我们的用户，使得系统的访问量逐步上升，逐渐逼近了硬件资源的极限，同时团队也在此期间积累了对业务流程的一批经验。面对当前的性能压力，我们需要未雨绸缪去进行系统重构、架构调整，以提升系统的承载能力。但由于预算仍然很紧张，我们选择了将应用和数据分离的做法，可以最小代价的提升系统的承载能力。

服务访问：和之前架构的主要区别在于将数据库服务独立部署在同一个数据中心的其他服务器上，应用服务器需要通过网络来访问存储服务器中的数据。

2.3 应用服务集群架构

我们的系统受到了用户的欢迎，并且出现了爆款，单台应用服务器已经无法满足需求了。我们的单机应用服务器首先遇到了瓶颈，摆在我们技术团队面前的有两种方案，大家针对方案的优劣展示了热烈的讨论：

• 垂直拓展/纵向拓展 Scale Up：通过购买性能更优、价格更高的应用服务器来应对更多的流量。这种方案的优势在于完全不需要对系统软件做任何的调整，但劣势也很明显 – 硬件性能和价格的增长关系是非线性的，意味着选择性能2倍的硬件可能需要花费超过4倍的价格，其次硬件性能提升是有明显上限的。
• 水平拓展/横向拓展 Scale Out：
• 通过调整软件架构，增加应用层硬件，购买多台应用服务器，将用户流量分担到不同的应用层服务器上，来提升系统的承载能力。这种方案的优势在于成本相对较低，并且提升的上限空间也很大。但劣势是带给系统更多的复杂性，需要技术团队有更丰富的经验。

经过团队的学习、调研和讨论，最终选择了水平扩展的方案来解决该问题，但这需要引入一个新的组件，即负载均衡 – 为了解决用户流量向哪台应用服务器分发的问题，需要一个专门的系统组件做流量分发。

实际中负载均衡不仅仅指的是工作在应用层的，甚至可能是其他的网络层之中。同时流量调度算法也有很多种，这里简单介绍几种较为常见的：

• Round-Robin 轮询算法：即非常公平地将请求依次分给不同的应用服务器。
• Weight-Round-Robin 轮询算法：为不同的服务器 (比如性能不同) 赋予不同的权重 (weight) 能者多劳。
• 一致性哈希散列算法：通过计算用户的特征值 (比如 IP 地址)得到哈希值，根据哈希结果做分发，优点是确保来自相同用户的请求总是被分给指定的服务器。也就是我们平时遇到的专项客户经理服务。

关于应用服务器集群架构，这里有几个需要注意的地方：

• 一旦引入多台主机（水平拓展），就可以将我们的系统称为是 “分布式系统” 了，但引入分布式系统是单机架构无法满足业务需求背景下的无奈之举，因为这会使得系统的复杂程度大大提高。
• 负载均衡器的作用是将用户流量按照某种规则分发到不同的应用服务器上，以保证系统能够正常提供服务。那么首先的问题是负载均衡器如何能抗住这么大的流量？ 其实这是因为负载均衡器只负责分发任务，不负责执行任务，而执行任务一般比分发任务所耗费的资源是要多得多的，因此负载均衡器对于请求的承担能力是要远超于应用服务器的。这就像公司中专业组的领导一样，领导负责团队的管理工作，以及团队任务的分发工作（当然实际工作中领导也会负责部分开发业务）。 那如果用户请求实在太多导致负载均衡器都扛不住了怎么办？此时只需要引入多个负载均衡器即可，即引入多个机房。

相关软件：负载均衡软件，比如 Nginx、HAProxy、LVS、F5 等。

2.4 读写分离/主从分离架构

上面提到，我们把用户的请求通过负载均衡分发到不同的应用服务器之后，可以并行处理了，并且可以随着业务的增长，可以动态扩张服务器的数量来缓解压力。但是现在的架构里，无论扩展多少台服务器，这些请求最终都会从数据库读写数据，到一定程度之后，数据的压力称为系统承载能力的瓶颈点。

那么我们可以像扩展应用服务器一样扩展数据库服务器么? 答案是否定的，因为数据库服务有其特殊性 – 如果将数据分散到各台服务器之后，数据的一致性将无法得到保障。所谓数据的一致性在此处是指：针对同一个系统，无论何时何地，我们都应该看到一个始终维持统一的数据。想象一下银行管理的账户金额，如果收到一笔转账之后，一份数据库的数据修改了，但另外的数据库没有修改，则用户得到的存款金额将是错误的。

针对上面的问题，我们引入了读写分离/主从分离架构，即保留一个主要的数据库作为写入数据库，其他的数据库作为从属读数据库。从库的所有数据全部来自主库的数据，经过同步后，从库可以维护着与主库一致的数据。然后为了分担数据库的压力，我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中。

由于大部分的系统中，读写请求都是不成比例的，例如 100 次读1次写，所以只要将读请求由各个从库分担之后，数据库的压力就没有那么大了。当然这个过程不是无代价的，主库到从库的数据同步其实是由时间成本的，但这个问题我们暂时不做进一步探讨。

服务访问：应用中需要对读写请求做分离处理，所以可以利用一些数据库中间件，将请求分离的职责托管出去。

相关软件：MyCat、TDDL、Amoeba、Cobar 等类似数据库中间件等。

2.5 冷热分离架构（缓存）

随着访问量继续增加，发现业务中一些数据的读取频率远大于其他数据的读取频率，我们把这部分数据称为热点数据，与之相对应的是冷数据。针对热数据，为了提升其读取的响应时间，可以增加本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的 html页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。

其中涉及的技术包括：使用 memcached 作为本地缓存，使用 Redis 作为分布式缓存，还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。

二八原则：

经济学中有一个很出名的 “二八原则”，即 20% 的人掌握着 80% 的财富。在计算机中，“二八原则” 同样使用，它的含义是 20% 的数据可以支持 80% 的访问量。

相关软件：Memcached、Redis 等缓存软件。

2.5 分库分表

引入分布式系统后，除了要能够应对更高的请求量/并发量，也需要能够应对更大的数据量。随着请求量的不断增多，就有可能出现数据太多，一台存储服务器存不下的情况（注意：我们前面提到的读写分离架构只能提高数据的读写速度，而每台服务器中都保存着所有的数据）。

针对这种情况，我们就需要使用多台服务器来存储数据。我们可以按照业务对数据库进行拆分，原本一台数据库服务器中存在多个数据库（指的逻辑上的，create database 语句创建的数据库），现在我们可以引入数据库集群，每个数据库服务器存储一个或一部分数据。

比如，我们可以将用户表数据、商品表数据、交易表数据分别存储在一个数据库服务器/数据库集群中，从而降低单台数据库服务器的存储压力。同时，如果数据库中某个表非常大，我们还可以针对表进行拆分，比如我们可以将交易表数据存储在不同服务器上。

具体分库分表要不要操作？如何操作？完全取决于业务，业务决定技术，技术仅仅为业务提供支持。

2.6 微服务架构

在之前的架构中，所有的业务都在应用服务器中，随着业务的不断增加，会导致一个服务器的代码越来越复杂，比如修改一个bug/新增一个功能牵涉到代码。为了更方便于代码的维护，我们可以把一个复杂的服务器拆分成更多的、功能更单一的，但是更小的服务器，这就是所谓的微服务了。

微服务本质上是在解决 “人” 的问题：

当应用服务器复杂后，势必就需要更多的人来维护，人多了就需要配套的管理，划分组织结构，将这些人划分为不同的组。将服务器按照功能拆分成多组微服务，有利于上述人员的组织结构的分配。

引入微服务的优势在于解决了人的问题，同时可以将一些公共的功能拆分出来，便于功能的复用，我们也可以对不同的微服务进行不同的部署，定制化开发。劣势在于系统性能的下降（以及业务在一台服务器上，使用进程间通信；现在业务在不同服务器中，需要通过网络进行通信）以及系统复杂程度提高，可用性受到影响，因此需要更丰富的监控报警机制以及配套的运维人员。

3 本章总结

分布式系统架构演进路径如下：

1. 单机架构：应用服务和数据库服务部署在同一台服务器上，适用于大部分中小型公司。
2. 应用数据分离架构：将应用服务和数据库服务分离，分别部署在一台服务器上，提高系统承载能力。
3. 应用服务器集群架构：购买多台应用服务器，并引入负载均衡服务器，通过其将客户端请求分发给不同的应用服务器，以提高系统吞吐量/并发量/可用性。
4. 读写分离/主从分离架构：购买多台存储服务器，其中一台作为写数据库，其他服务器作为读数据库，提高数据的读写速度。
5. 冷热分离架构：使用缓存来存储热点数据，从而大幅度提高数据读写速度（按照 Google 给出的各层级硬件执行速度表，内存的读写速度大概是硬盘读写速度的 10万 倍）。
6. 分库分表：引入存储集群，将数据分别存储到不同的存储服务器集群中，从而提高可存储的数据量。
7. 微服务架构：按照业务将整个系统划分为多个子系统集群，同时分离出公共服务模块，从而降低系统的复杂度，便于业务组开发。

至此，一个还算合理的高可用、高并发系统的基本雏形已显。注意，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。

对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。

最后，所谓的 “大数据” 其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术。总的来说，大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。