大型网站技术架构-第1篇 概述

读书笔记 摘自：《大型网站技术架构：核心原理与案例分析-李智慧》

---

推荐序一

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

1 大型网站架构演化

上世纪90年代初CERN正式发布Web标准和第一个Web服务的出现当做互联网站的开始

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

• 高并发，大流量
• 高可用：系统7×24小时不间断服务
• 海量数据
• 用户分布广泛，网络情况复杂
• 安全环境恶劣
• 需求快速变更，发布频繁
• 渐进式发展

好的互联网产品都是慢慢运营出来的，不是一开始就开发好的，这也正好与网站架构的发展演化过程对应。

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

大型网站的技术挑战主要来自于庞大的用户，高并发的访问和海量的数据

1. 初始阶段的网站架构
2. 应用服务和数据服务分离
3. 使用缓存改善网站性能
   网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。
   缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。
   远程分布式缓存可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务
4. 使用应用服务器集群改善网站的并发处理能力
   增加一台服务器分担原有服务器的访问及存储压力。
   应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种
   负载均衡调度服务器
5. 数据库读写分离
   目前大部分的主流数据库都提供主从热备功能
6. 使用反向代理和CDN加速网站响应
   CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。
   使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
7. 使用分布式文件系统和分布式数据库系统
   分布式数据库是网站数据库拆分的最后手段
   网站更常用的数据库拆分手段是业务分库
8. 使用NoSQL和搜索引擎
9. 业务拆分
   大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线，如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。
10. 分布式服务
    而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作

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

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

LAMP技术（Linux＋Apache＋MySQL＋PHP）

大型网站架构技术的核心价值不是从无到有搭建一个大型网站，而是能够伴随小型网站业务的逐步发展，慢慢地演化成一个大型网站。

驱动大型网站技术发展的主要力量是网站的业务发展

1.4 网站架构设计误区

1. 一味追随大公司的解决方案

2. 为了技术而技术
   网站技术是为业务而存在的，除此毫无意义。

3. 企图用技术解决所有问题
   12306需要重构的不仅是它的技术架构，更重要的是它的业务架构
   技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。

2 大型网站架构模式

模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复使用。

2.1 网站架构模式

高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标

2.1.1 分层

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

应用层、服务层、数据层

通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。

禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）。

三层结构分别部署在不同的服务器上，使网站拥有更多的计算资源以应对越来越多的用户访问。

分层结构对网站支持高并发向分布式方向发展至关重要

2.1.2 分割

如果说分层是将软件在横向方面进行切分，那么分割就是在纵向方面对软件进行切分。

将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块

2.1.3 分布式

对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。

首先，分布式意味着服务调用必须通过网络，这可能会对性能造成比较严重的影响；其次，服务器越多，服务器宕机的概率也就越大，一台服务器宕机造成的服务不可用可能会导致很多应用不可访问，使网站可用性降低；另外，数据在分布式的环境中保持数据一致性也非常困难，分布式事务也难以保证，这对网站业务正确性和业务流程有可能造成很大影响；分布式还导致网站依赖错综复杂，开发管理维护困难。

• 分布式应用和服务
• 分布式静态资源
• 分布式数据和存储
  为网站应用而生的各种NoSQL产品几乎都是分布式的。
• 分布式计算
  目前网站普遍使用Hadoop及其MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。

2.1.4 集群

独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。因为服务器集群有更多服务器提供相同服务，因此可以提供更好的并发特性，当有更多用户访问的时候，只需要向集群中加入新的机器即可。

即使是访问量很小的分布式应用和服务，也至少要部署两台服务器构成一个小的集群，目的就是提高系统的可用性。

2.1.5 缓存

缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存

CDN：即内容分发网络，部署在距离终端用户最近的网络服务商

如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN。反向代理：反向代理属于网站前端架构的一部分，部署在网站的前端

反向代理：缓存网站的静态资源，无需将请求继续转发给应用服务器就能返回给用户。

本地缓存：在应用服务器本地缓存着热点数据

分布式缓存：将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。

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

2.1.6 异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。

业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署。

使用异步消息队列还有如下特性：

• 提高系统可用性。
• 加快网站响应速度。
• 消除并发访问高峰。
  使用消息队列将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力。
  使用异步方式处理业务可能会对用户体验、业务流程造成影响，需要网站产品设计方面的支持。

2.1.7 冗余

一定程度的服务器冗余运行，数据冗余备份，这样当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上。访问和负载很小的服务也必须部署至少两台服务器构成一个集群，其目的就是通过冗余实现服务高可用。

对数据库进行主从分离，实时同步实现热备份。

2.1.8 自动化

目前大型网站的自动化架构设计主要集中在发布运维方面。

对网络通信进行加密

对于常见的用于攻击网站的XSS攻击、SQL注入、进行编码转换等相应处理；

对交易转账等重要操作根据交易模式和交易信息进行风险控制

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

LAMP（Linux+Apache+MySQL+PHP）架构

新浪微博的核心服务是微博、关系和用户

现在网站应用中常见的将物理机虚拟化成多个虚拟机后，在虚拟机上部署应用的方案跟新浪微博的MPSS方案异曲同工，只是更加简单，还能在不同虚拟机上使用相同的端口号。

由于微博频繁刷新，新浪微博使用多级缓存策略，热门微博和明星用户的微博缓存在所有的微博服务器上，在线用户的微博和近期微博缓存在分布式缓存集群中

2.3 小结

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

3 大型网站核心架构要素

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

系统的各个重要组成部分及其关系构成了系统的架构，这些组成部分可以是具体的功能模块，也可以是非功能的设计与决策，他们相互关系组成一个整体，共同构成了软件系统的架构。

软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素，架构设计过程中需要平衡这5个要素之间的关系以实现需求和架构目标

3.1 性能

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

对于网站而言，性能符合预期仅仅是必要条件，因为无法预知网站可能会面临的访问压力，所以必须要考察系统在高并发访问情况下，超出负载设计能力的情况下可能会出现的性能问题。网站需要长时间持续运行，还必须保证系统在持续运行且访问压力不均匀的情况下保持稳定的性能特性。

3.2 可用性

高可用设计的目标就是当服务器宕机的时候，服务或者应用依然可用。

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

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

3.3 伸缩性

伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。

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

关系数据库虽然支持数据复制，主从热备等机制，但是很难做到大规模集群的可伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。

3.4 扩展性

不同于其他架构要素主要关注非功能性需求，网站的扩展性架构直接关注网站的功能需求。网站快速发展，功能不断扩展，如何设计网站的架构使其能够快速响应需求变化，是网站可扩展架构主要的目的。

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

大型网站为了保持市场地位，还会吸引第三方开发者，调用网站服务，使用网站数据开发周边产品，扩展网站业务。

3.5 安全性

互联网是开放的，任何人在任何地方都可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。
衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls