大型分布式服务器架构原理详解

引言

一个成熟的大型网站的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随业务扩展而完善出来的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同，一般都是由简单到复杂，从单一服务器到集群服务器进行开发。故可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段

一.初始阶段:网站架构

一般来讲，大型网站都是从小型网站发展而来，一开始的架构都比较简单，随着业务复杂和用户量的激增，才开始做很多架构上的改进。当它还是小型网站的时候，没有太多访客，一般来讲只需要 一台服务器就够了，这时 应用程序、数据库、文件等所有资源都在一台服务器上，网站架构如下图所示：

二.第二阶段:应用服务和数据服务分离

随着 业务的扩展和 用户量的增加，一台服务器已经 不能满足性能需求，大量用户访问导致 访问速度越来越慢，而逐渐增加的数据也会导致 存储空间不足，这时就需要将 应用和数据分离，应用和数据分离后整个网站使用 3 台服务器： 应用服务器、文件服务器和数据库服务器，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果，服务器配置要求如下：
1. 应用服务器业务逻辑，需要 强大的CPU
2. 数据库服务器对磁盘读写操作很多，需要 更快的磁盘和 更大的内存
3. 文件服务器存储用户上传的文件，因此需要 更大的磁盘空间
此时，网站系统的架构如下图所示：

三.第三阶段:使用缓存改善网站性能

随着用户再增加，网站又会一次面临挑战： 数据库压力太大导致整站访问效率再此下降，用户体验受到影响。大部分网站访问都遵循28原则（即80%的访问请求，最终落在20%的数据上），比如微博请求量最多的肯定是那些***粉丝的大 V 的微博。既然大部分业务访问集中在一小部分数据上，那就把这一小部分数据先提前缓存在内存中，而不是每次都去数据库读取，这样就可以减少数据库的访问压力，从而提高整个网站的访问速度,减少这些数据的访问路径，提高用户体验。 网站使用的缓存一般分为缓存到应用服务器的 本地缓存或者缓存在专门的 分布式缓存服务器，当然还有CDN、反向代理等。缓存到应用服务器自己的访问速度快很多，但是受自身内存限制，往往不太适用。远程分布式缓存使用一个集群专门负责缓存服务，可以 缓存海量的数据，当内存不够可以轻松得 动态扩容，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是 Memcached、 Redis,这时的网站系统架构如下图所示：

四.第四阶段:使用应用服务器集群改善网站的并发处理能力

使用缓存后，数据访问压力得到了缓解，应用服务器作为网站的入口，会 承担大量的请求，但是单一应用服务器能够处理的请求连接是有限的，在 网站访问高峰期， 应用服务器就成了整个网站的效率瓶颈。往往可以通过 应用服务器集群(分布式集群: 在应用服务器前面部署 负载均衡 服务器调度用户请求，根据分发策略将请求分发到多个应用服务器节点)来解决 高并发、 海量数据。当一台服务器的处理能力和存储空间不足时，不要尝试去更换更强大的服务器，对大型网站而言，多么强大的服务器，都满足不了网站持续增长的业务需求。这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。 对网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性
常用的负载均衡技术硬件的有 F5，价格比较贵，软件的有 LVS、Nginx、HAProxy，LVS是四层负载均衡，根据目标地址和端口选择内部服务器，Nginx是七层负载均衡和HAProxy支持四层、七层负载均衡，可以根据报文内容选择内部服务器，因此LVS分发路径优于Nginx和HAProxy，性能要高些，而 Nginx和HAProxy则更具配置性，可以用来做 动静分离（根据请求报文特征，选择静态资源服务器还是应用服务器）。应用服务器实现集群是网站可伸缩架构设计中较为简单成熟的一种，这时的网站系统架构如下图所示：

五.第五阶段:数据库读写分离和分库分表

网站在使用缓存后，使对大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作（ 缓存访问不到、缓存过期）和 全部的写操作都需要访问数据库,随着用户量的增加，数据库因为 负载压力过高而成为网站的瓶颈，改善数据库性能常用的手段是进行 读写分离以及 分库分表。分库分表分为 水平分表和 垂直分表，水分表则是对一个数据库特大的表进行拆分，例如用户表。垂直分表则是根据业务不同来切换，如用户业务、商品业务相关的表放在不同的数据库中。读写分离顾名思义就是将数据库分为 读库和 写库，通过主 备功能实现数据同步，目前大部分的主流数据库都提供 主从热备功能，通过配置两台数据库主从关系，可以将 一台数据库服务器的数据更新同步到另一台服务器上，网站利用数据库的这一功能，应用服务器在 写数据的时候，访问主数据库，主数据库通过 主从复制机制将数据更新 同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据，实现数据库读写分离，从而改善数据库负载压力,现阶段的网站系统架构如下图所示：

六.第六阶段:使用CDN和反向代理提高网站性能

随着网站业务不断发展，用户规模越来越大，由于中国复杂的网络环境， 不同地区的用户访问网站时，速度差别也极大,假如服务器都部署在成都的机房，对于四川的用户来说访问是较快的，而对于北京的用户访问是较慢的，这是由于四川和北京分别属于电信和联通的不同发达地区，北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器，返回路径也一样，所以数据传输时间比较长。有研究表明，网站访问延迟和用户流失率正相关，网站访问越慢，用户越容易失去耐心而离开,为了提供更好的用户体验，留住用户，网站需要加速网站访问速度,对于这种情况，常常使用 CDN和 反向代理解决。 CDN将数据内容缓存到运营商的机房，用户访问时先从最近的运营商获取数据，这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。而 反向代理，则是部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有没有缓存数据才会继续走应用服务器获取，也减少了获取数据的成本。反向代理有Squid，Nginx
现阶段的网站系统架构如下图所示：

七.第七阶段:使用分布式文件系统和分布式数据库系统

任何强大的单一服务器都满足不了大型网站持续增长的业务需求，数据库经过读写分离后，从一台服务器拆分成两台服务器，但是随着网站业务的发展依然不能满足需求，这时需要使用 分布式数据库。文件系统也一样，用户一天天增加，业务量越来越大，产生的文件越来越多，单台的文件服务器已经不能满足需求，需要使用 分布式文件系统(常用的分布式文件系统有NFS)。分布式数据库只有在单表数据规模非常庞大的时候才使用，不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据部署在不同的物理服务器上，现阶段的网站系统架构如下图所示：

第八阶段：使用 NoSQL 和搜索引擎

随着网站业务越来越复杂，对 数据存储和 检索的需求也越来越复杂，对于 海量数据的查询,网站需要采用一些非关系数据库技术如 NoSQL 和非数据库查询技术如 搜索引擎以达到更好的性能。常用的NOSQL有 mongodb和redis，搜索引擎有 lucene,spinx,ElasticSearch 等。NoSQL 和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持,应用服务器则通过一个统一数据访问模块访问各种数据， 来减轻应用程序管理诸多数据源的麻烦。现阶段的网站系统架构如下图所示：

九. 第九阶段:将应用服务器进行业务拆分

随着业务进一步扩展，应用程序变得非常臃肿，为了应对日益复杂的业务场景,这时我们需要将 应用程序进行业务拆分，将整个网站业务分成 不同的产品线,如大型购物交易网站都会将首页、商铺、订单、买家、卖家等拆分成不同的产品线,每个业务应用分归不同的业务团队负责, 每个业务应用独立部署，业务之间可以通过一个超链接建立关系（在首页上的导航链接每个都指向不同的应用地址），也可以通过 消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。现阶段网站系统架构如下图所示：

十. 第十阶段:搭建分布式服务

随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。由于所有应用要和所有数据库系统连接，在数万台服务器规模的网站中，这些连接的数目是服务器规模的平方，导致数据库连接资源不足，拒绝服务。这里发现：每一个应用系统都需要执行许多相同的 基础业务服务，比如 用户服务、订单服务、支付服务、安全服务等，那么可以将这些共用的业务提取出来，利用 分部式服务框架搭建分布式服务独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作.现阶段网站系统架构如下图所示：

大型网站的架构演化到此完结