分布式架构演进之路

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 本章总结

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

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

至此，一个还算合理的高可用、高并发体系的基本雏形已显。注意，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要办理，大概可能先到达瓶颈的是另外的方面，这时间就应该按照实际问题实际办理。如在当局类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点办理的问题，此时优先需要的可能会是丰富需求的办理方案。
对于单次实施并且性能指标明确的体系，架构设计到能够支持体系的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不绝发展的体系，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不绝的迭代升级架构，以支持更高的并发和更丰富的业务。
末了，所谓的 “大数据” 其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景办理方案的一个统称，在每一个场景都包罗了多种可选的技能。总的来说，大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式盘算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。

---

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。