朱哥的架构师修炼之路----1.大型系统架构演化历程

1大型系统架构演化历程

从集中式到分布式。在很长的一段时间内，伴随着大型主机的集中式系统架构成为了主流。在那个时候，由于大型主机卓越的性能和良好的稳定性，其在单机处理方面的优势非常明显。集中式系统具有明显的单点问题，并且单一大型主机上难以进行系统扩容。随着PC机性能的不断提升和网络技术的快速普及，很多企业开始放弃原来的大型主机，改用小型机和普通PC服务器来构建分布式系统。最典型的就是阿里巴巴的“去IOE”运动。

大型系统的技术挑战主要来自庞大的用户，高并发的访问和海量的数据，任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户，问题会变得很棘手。大型系统架构主要就是解决这类问题。

1.1初始阶段系统架构

随着业务规模的增长，小型网站逐步发展为大型网站，伴随着小型架构逐步演化为大型系统架构。刚开始没多大访问量，也没架构可言，一般一台服务器就绰绰有余，这时的系统架构如图。



应用程序、文件、数据库等所有资源都集中在一台廉价的PC服务器上。通常服务器操作系统用Linux，应用程序用PHP开发，然后部署在Apache上，数据库使用MySQL。淘宝最初的架构也是这么开始的。

1.2应用、数据和文件分离

业务发展，系统访问量和数据存储压力不断增大，单台服务器逐渐不能满足需求。需要将应用、数据和文件分离。这时的系统架构如图。



服务器分离后，不同特性的服务器承担不同的角色。应用服务器需要处理业务逻辑，配予更强大CPU；数据库服务器需要更快的磁盘检索和数据缓存，配予更快的硬盘和更大的内存；文件服务器需要存储大量用户文件，配予更大硬盘。

1.3使用缓存

业务继续发展，用户进一步增多，频繁的数据库访问，导致数据库压力大增，进而导致访问延迟，影响整个网站性能和用户体验。这时需要对访问比较集中的数据在内存中进行缓存，从而减少数据库的访问压力。这时的系统架构如图所示。



可以缓存在应用服务器本地，也可以采用远程分布式服务器缓存。本地缓存访问速度更快，但缓存数据量受本地内存限制，远程分布式缓存使用集群方式，可以不受内存容量限制。

在实现技术上，通常采用memcache或redis来对关系型数据库的数据进行缓存。

1.4应用服务器集群和负载均衡

使用缓存后，数据库访问压力得到缓解，然单一应用服务器能够处理的请求连接有限，在网站访问高峰期，应用服务器成为整个网站的瓶颈。可以采用应用服务器集群和负载均衡技术升级系统架构。这时的系统架构如图所示。



应用服务器集群是系统可伸缩性架构设计中较为简单成熟的一种方式。通过负载均衡手段，多台服务器可以共同分担访问请求。

在技术实现上，通常采用LVS/Nginx/HAproxy等负载均衡软件。

1.5数据库读写分离

系统使用缓存后，大部分读操作不再到达数据库，然而仍有部分读操作和全部的写操作需要访问数据库，当系统用户达到一定规模后，数据库负载过高问题再次回归。这时，采用主流数据库都提供的主从热备功能来解决，系统架构如图所示。



写操作访问主数据库，读操作访问从数据库。压力主要集中在高频次的读操作上，可以配置多个从数据库，分担数据库的读压力。数据库的复制机制，会保证主从数据的一致性。

读写分离后，可视为数据库实现了集群，解决了单点故障导致业务数据丢失的问题。

1.6使用CDN和反向代理加速响应

为加快响应，提供更好的用户体验，采用CDN和反向代理。原理上也是缓存。这个时的系统架构如图所示。



CDN部署在网络提供商的机房，用户可以从自己最近的网络提供商机房获得数据。反向代理将静态文件存储在中心机房的前端，如果缓存着用户请求的资源，就会直接返回数据，加快访问的同时又减轻了后方服务器压力。

在技术实现上，通常采用Squid/Lighttpd/Apache等软件来实现反向代理。

常见的负载均衡软件，也都支持反向代理的配置。因此实际架构中，经常把反向代理和负载均衡部署在同一个节点上，用同一个软件。

1.7使用分布式数据库和分布式文件系统

数据库经过读写分离，从一台服务器拆分为多台服务器，服务器数据均相同。随着业务规模发展，单表数据变得非常庞大的时候，依然不能满足需求。这时，需要对数据库和文件系统进行分布式部署。这时的系统架构如图所示。



数据分片（单表的数据拆分后部署在不同的物理服务器上）是数据库拆分的最后手段，不到不得已，更常用的是数据分库（将不同业务的数据库部署在不同的物理服务器上）。

1.8使用NoSQL和搜索引擎

随着业务越来越复杂，对数据存储和检索的需求也变得复杂，必要时采用一些非关系型数据库如NoSQL和搜索引擎，这时的系统架构如图所示。

1.9应用按业务拆分，部署分布式消息队列

为了应对日期复杂的业务，拆分成多个产品线，划分到不同的应用中，独立部署维护。应用之间通过分布式消息队列通信。这时的系统架构如图所示。



在技术实现上，通常采用ActiveMQ等软件来实现分布式消息队列。

1.10分布式服务

业务越拆越细，存储系统越来越大，不同子应用需要执行许多相同的业务操作来访问同一块数据库资源，导致数据库连接资源不足，拒绝服务。可以将共用的业务服务提取出来，部署分布式服务。这时的系统架构如图所示：



在技术实现上，需要借助简单高效的分布式服务框架来构建SOA。如Fackbook的Thrift（未开源），和Alibaba开源的Dubbo。

1.11分布式一致性

当服务越来越多，规模越来越大，对应的机器数量也越来越庞大。单靠人工来管理和维护服务及地址的配置信息，越来越困难。并且，依赖单一的负载均衡设备或LVS、Nginx等软件方案进行负载均衡调度，单点故障的问题也开始凸显，一单服务器路由或负载均衡服务器宕机，依赖它的所有服务将失效。

Zookeeper是一个典型的分布式数据一致性的解决方案，除了负载均衡外，分布式应用还可以基于它实现诸如数据发布/订阅、命名服务、分布式协调/通知、集群管理、Master选举，分布式锁和分布式队列等功能。是一个通用的无单点问题的分布式协调框架。Alibaba开源的SOA框架Dubbo就采用了Zookeeper作为服务发现的底层机制。

大型网站架构演化到这，基本上大多数技术问题都得以解决。既然大型网站架构解决了海量数据的管理和高并发事务的处理，那么就可以把这些解决方案应用到自身以外的业务上去。因此许多大型网站开始建设云计算平台，将计算作为一种资源出售，中小网站不再需要关注技术架构问题，只需按需付费。云平台的出现，极大地降低了技术成本和复杂度，在一定程度上促成了互联网行业的大众创业万众创新。