大型网站技术架构：核心原理与案例分析-第1篇 概述

内容简介

《大型网站技术架构：核心原理与案例分析》通过梳理大型网站技术发展历程，剖析大型网站技术架构模式，深入讲述大型互联网架构设计的核心原理，并通过一组典型网站技术架构设计案例，为读者呈现一幅包括技术选型、架构设计、性能优化、Web安全、系统发布、运维监控等在内的大型网站开发全景视图。

作者李智慧，曾在阿里巴巴担任技术专家，参与阿里巴巴基础技术平台开发和架构设计。

第一篇 概述

• 1　大型网站架构演化
  • 1.1　大型网站软件系统的特点
  • 1.2　大型网站架构演化发展历程
    • 1.2.1　初始阶段的网站架构
    • 1.2.2　应用服务和数据服务分离
    • 1.2.3　使用缓存改善网站性能
    • 1.2.4　使用应用服务器集群改善网站的并发处理能力
    • 1.2.5　数据库读写分离
    • 1.2.6　使用反向代理和CDN加速网站响应
    • 1.2.7　使用分布式文件系统和分布式数据库系统
    • 1.2.8　使用NoSQL和搜索引擎
    • 1.2.9　业务拆分
    • 1.2.10　分布式服务
  • 1.3　大型网站架构演化的价值观
    • 1.3.1　大型网站架构技术的核心价值是随网站所需灵活应对
    • 1.3.2　驱动大型网站技术发展的主要力量是网站的业务发展
  • 1.4　网站架构设计误区
    • 1.4.1　一味追随大公司的解决方案
    • 1.4.2　为了技术而技术
    • 1.4.3　企图用技术解决所有问题

• 2　大型网站架构模式
  • 2.1　网站架构模式
    • 2.1.1　分层
    • 2.1.2　分割
    • 2.1.3　分布式
    • 2.1.4　集群
    • 2.1.5　缓存
    • 2.1.6　异步
    • 2.1.7　冗余
    • 2.1.8　自动化
    • 2.1.9　安全
  • 2.2　架构模式在新浪微博的应用
• 3　大型网站核心架构要素
  • 3.1　性能
  • 3.2　可用性
  • 3.3　伸缩性
  • 3.4　扩展性
  • 3.5　安全性

传统的企业应用系统主要面对的技术挑战是处理复杂凌乱、千变万化的所谓业务逻辑，而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理；前者的挑战来自功能性需求，后者的挑战来自非功能性需求；功能性需求也许还有“人月神话”聊以自慰，通过增加人手解决问题，而非功能需求大多是实实在在的技术难题，无论有多少工程师，做不到就是做不到。

能够比较全面地从理论和实践两个视角去看待和描述网站架构。书中的技术内容基本都从为什么（Why）要这么做和如何去做（How）两个层面进行表述。读者可知其然并知其所以然。

阅读本书也许不能使你就此掌握大型网站架构设计的屠龙之术，但至少使你对网站架构的方法和思维方式能有全面了解。

机械制图的时候，通常使用三视图描述一个机械零件，从正视、侧视、俯视三个角度对一个零件绘图，从而全面描述一个零件的结构。软件架构设计中常用的4＋1视图模型，也是一种多角度描述软件系统设计的手段。

好的设计绝对不是模仿，不是生搬硬套某个模式，而是对问题深刻理解之上的创造与创新，即使是“微创新”，也是让人耳目一新的似曾相识。山寨与创新的最大区别不在于是否抄袭，是否模仿，而在于对问题和需求是否真正理解与把握。

1  大型网站架构演化

如何打造一个高可用、高性能、易扩展、可伸缩且安全的网站？如何让网站随应用所需灵活变动，即使是山寨他人的产品，也可以山寨的更高、更快、更强，一年时间用户数从零过亿呢？

1.1 大型网站软件系统的特点

1)、高并发、大流量：需要面对高并发用户，大流量访问。

2)、高可用：系统7×24小时不间断服务。

3)、海量数据：需要存储、管理海量数据，需要使用大量服务器。

4)、用户分布广泛，网络情况复杂：许多大型互联网都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别。

5)、安全环境恶劣：许多大型互联网都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别。

6)、需求快速变更，发布频繁：和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率是极高的。

7)、渐进式发展：几乎所有的大型互联网网站都是从一个小网站开始，渐进地发展起来的。好的互联网产品都是慢慢运营出来的，不是一开始就开发好的。

1.2 大型网站架构演变发展历程

1)、初期阶段的网站架构：应用程序、数据库、文件等所有的资源都在一台服务器上。

2)、应用服务和数据服务分离：应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘盒更大的内存；文件服务器需要存储大量用户上传的文件，因此需要更大的硬盘。不同服务器承担不同的服务角色。

3)、使用缓存改善网站性能：网站访问特点和现实世界的财富分配一样遵循二八定律，80%的业务访问集中在20%的数据上。

4)、使用应用服务器集群改善网站的并发处理能力：使用集群是网站解决高并发、海量数据问题的常用手段。通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群中的任何服务器上。

5)、数据库读写分离：主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新到两一台服务器上。

6)、使用反向代理和CDN加速网站响应

CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。

7)、使用分布式文件系统和分布式数据库系统：分布式数据库是网站数据库拆分的最后手段，只有单表数据规模非常庞大的时候才使用。

8)、使用NoSQL和搜索引擎

9)、业务拆分：根据产品线划分，一个网站拆分成许多不同的应用，每个应用独立部署维护。

10)、分布式服务：通过分布式服务调用共同业务服务完成具体业务操作。

1.3 大型网站框架演化的价值观

网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的，所以在网站还很小的时候就去追求网站的架构是舍本逐末，得不偿失的。小型网站最需要做的就是为用户提供好的服务来创造价值，得到用户的认可，活下去，野蛮生长。

1)、大型网站框架技术的核心价值是随网站所需灵活和应对。

2)、驱动大型网站技术发展的主要力量书网站的业务发展：业务成就了技术，事业成就了人。

1.4 网站架构设计误区

1)、一味追随大公司的解决方案：大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。

2)、为了技术而技术：网站是为了业务而存在的：网站技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将网站技术发展引入崎岖小道，架构之路越走越难。

3)、企图用技术解决所有问题

12306真正的问题其实不在于它的技术架构，而在于它的业务架构：12306根本就不应该在几亿中国人一票难求的情况下以窗口售票的模式在网上售票（零点开始出售若干天后的车票）。

12306需要重构的不仅是它的技术架构，更重要的是它的业务架构：调整业务需求，换一种方式卖票，而不要去搞促销秒杀这种噱头式的游戏。

后来证明12306确实是朝这个方向发展的：在售票方式上引入了排队机制、整点售票调整为分时段售票。其实如果能控制住并发访问的量，很多棘手的技术问题也就不是什么问题了。

技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。

2　大型网站架构模式

也许互联网产品不是随便复制就能成功的，创新的产品更能为用户创造价值。但是网站架构却有一些共同的模式，这些模式已经被许多大型网站一再验证，通过对这些模式的学习，我们可以掌握大型网站架构的一般思路和解决方案，以指导我们的架构设计。

2.1 网站架构模式

1)、分层：分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。

2)、分割：网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

3)、分布式：分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作；分布式意味着可以使用风多的计算机完成同样的功能。

4)、集群

服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

因为服务器集群有更多服务器提供相同服务，因此可以提供更好的并发特性，当有更多用户访问的时候，只需要向集群中加入新的机器即可。同时因为一个应用由多台服务器提供，当某台服务器发生故障时，负载均衡设备或者系统的失效转移机制会将请求转发到集群中其他服务器上，使服务器故障不影响用户使用。所以在网站应用中，即使是访问量很小的分布式应用和服务，也至少要部署两台服务器构成一个小的集群，目的就是提高系统的可用性。

5)、缓存

使用缓存有两个前提条件，一是数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；二是数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性。

网站应用中，缓存除了可以加快数据访问速度，还可以减轻后端应用和数据存储的负载压力，这一点对网站数据库架构至关重要，网站数据库几乎都是按照有缓存的前提进行负载能力设计的。

6)、异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，就越少被彼此影响，越可以独立发展。大型网站架构中，系统解耦合的手段除了前面提到的分层、分割、分布等，还有一个重要手段是异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

使用异步方式处理业务可能会对用户体验、业务流程造成影响，需要网站产品设计方面的支持。

7)、冗余：访问和负载很小的服务也必须部署至少两台服务器构成一个集群，其目的就是通过冗余实现服务高可用。数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。

8)、自动化

发布对网站都是头等大事，许多网站故障出在发布环节，网站工程师经常加班也是因为发布不顺利。通过减少人为干预，使发布过程自动化可有效减少故障。发布过程包括诸多环节。自动化代码管理，代码版本控制、代码分支创建合并等过程自动化，开发工程师只要提交自己参与开发的产品代号，系统就会自动为其创建开发分支，后期会自动进行代码合并；自动化测试，代码开发完成，提交测试后，系统自动将代码部署到测试环境，启动自动化测试用例进行测试，向相关人员发送测试报告，向系统反馈测试结果；自动化安全检测，安全检测工具通过对代码进行静态安全扫描及部署到安全测试环境进行安全攻击测试，评估其安全性；最后进行自动化部署，将工程代码自动部署到线上生产环境。

此外，网站在运行过程中可能会遇到各种问题：服务器宕机、程序Bug、存储空间不足、突然爆发的访问高峰。网站需要对线上生产环境进行自动化监控，对服务器进行心跳检测，并监控其各项性能指标和应用程序的关键数据指标。如果发现异常、超出预设的阈值，就进行自动化报警，向相关人员发送报警信息，警告故障可能会发生。在检测到故障发生后，系统会进行自动化失效转移，将失效的服务器从集群中隔离出去，不再处理系统中的应用请求。待故障消除后，系统进行自动化失效恢复，重新启动服务，同步数据保证数据的一致性。在网站遇到访问高峰，超出网站最大处理能力时，为了保证整个网站的安全可用，还会进行自动化降级，通过拒绝部分请求及关闭部分不重要的服务将系统负载降至一个安全的水平，必要时，还需要自动化分配资源，将空闲资源分配给重要的服务，扩大其部署规模。

9)、安全

通过密码和手机校验码进行身份认证；登录、交易等操作需要对网络通信进行加密，网站服务器上存储的敏感数据如用户信息等也进行加密处理；为了防止机器人程序滥用网络资源攻击网站，网站使用验证码进行识别；对于常见的用于攻击网站的XSS攻击、SQL注入、进行编码转换等相应处理；对于垃圾信息、敏感信息进行过滤；对交易转账等重要操作根据交易模式和交易信息进行风险控制。

2.2 架构模式在新浪微博的应用

1)、微博发布从早期的同步推模式（用户发表微博后系统会立即将这条微博插入到数据库所有粉丝的订阅列表中）改为现在的一步推拉结合的模式（用户发发表微博汇系统将微博写入消息队列后立即返回，用户响应迅速，消息队列消费者任务将微博推动给所有当前在线粉丝的订阅列表中，非在线用户登录后再根据关注列表拉取微博订阅列表）。
2)、多级缓存策略，热门微博和明星用户的微博缓存在所有的微博服务器上，在线用户的微博和近期微博缓存在分布式缓存集群中。

但是模式受其适当场景限制，对系统的要求和约束也很多，不恰当地使用模式只会画虎不成反类犬，不但没有解决原来的老问题，反而带来了更棘手的新问题。

好的设计绝对不是模仿，不是生搬硬套某个模式，二是对问题深刻理解之上的创造与创新，即使是“微创新”，也是让人耳目一新的似曾相识。山寨与创新的最大区别不在于是否抄袭，而在于问题和需求是否真正理解与把握。

3　大型网站核心架构要素

关于什么是架构，一种比较通俗的说法是“最高层次的规划，难以改变的决定”，这些规划和决定奠定了事物未来发展的方向和最终的蓝图。

3.1 性能

网站性能问题是网站架构升级优化的触发器。

也正是因为性能问题几乎无处不在，所以优化网站性能的手段也非常多，从用户浏览器到数据库，影响用户请求的所有环节都可以进行性能优化。

在浏览器端，可以通过浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等手段改善性能。

还可以使用CDN，将网站静态内容分发至离用户最近的网络服务商机房，使用户通过最短访问路径获取数据。

可以在网站机房部署反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力。

在应用服务器端，可以使用服务器本地缓存和分布式缓存，通过缓存在内存中的热点数据处理用户请求，加快请求处理过程，减轻数据库负载压力。

也可以通过异步操作将用户请求发送至消息队列等待后续任务处理，而当前请求直接返回响应给用户。

在网站有很多用户高并发请求的情况下，可以将多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能。

在代码层面，也可以通过使用多线程、改善内存管理等手段优化性能。

在数据库服务器端，索引、缓存、SQL优化等性能优化手段都已经比较成熟。

而方兴未艾的NoSQL数据库通过优化数据模型、存储结构、伸缩特性等手段在性能方面的优势也日趋明显。

衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等，通过测试这些指标以确定系统设计是否达到目标。这些指标也是网站监控的重要参数，通过监控这些指标可以分析系统瓶颈，预测网站容量，并对异常指标进行报警，保障系统可用性。

3.2 可用性

网站高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失。

对于应用服务器而言，多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务，任何一台服务器宕机，只需把请求切换到其他服务器就可实现应用的高可用，但是一个前提条件是应用服务器上不能保存请求的会话信息。否则服务器宕机，会话丢失，即使将用户请求转发到其他服务器上也无法完成业务处理。

除了运行环境，网站的高可用还需要软件开发过程的质量保证。通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能，避免故障范围扩大。

衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。

3.3 伸缩性

衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。

对于应用服务器集群，只要服务器上不保存数据，所有服务器都是对等的，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。

3.4 扩展性

衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。不同产品之间是否很少耦合，一个产品改动对其他产品无影响，其他产品和功能不需要受牵连进行改动。

网站可伸缩架构的主要手段是事件驱动架构和分布式服务。

3.5 安全性

衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。

性能、可用性、伸缩性、扩展性和安全性是网站架构最核心的几个要素，这几个问题解决了，大型网站架构设计的大部分挑战也就克服了。