《大型网站技术架构-核心原理与案例分析》学习笔记（一）：大型网站架构演化

一、大型网站软件系统的特点

• 高并发、大流量：需要面对高并发用户，大流量访问；

• 高可用：需要系统7x24小时不间断服务；

• 海量数据：需要存储、管理海量的数据；

• 用户分布广泛，网络情况复杂：用户分布全国，甚至全球，各地网络差异大、各运营商网络互通难；

• 安全环境恶劣：黑客攻击；

• 需求快速变更，发布频繁：快速的产品更新迭代；

• 渐进式发展：网站从小到大的发展，功能模块逐渐增加；

二、大型网站架构发展历程

1，初始阶段

应用程序、数据库、文件等所有资源部署在同一台服务器上

2，应用服务和数据服务分离

遇到的问题：
随着业务发展，用户增多，服务器性能、空间等都不能满足需要；

处理办法：
将应用和数据分离出来

• 应用服务器：强大的cup，处理大量业务逻辑；
• 数据库服务器：大内存，快速磁盘检索和数据缓存；
• 文件服务器：更大的硬盘，存储用户上传的文件；

3，使用缓存改善网站性能

遇到的问题：
数据库访问压力大导致访问延迟；

处理办法：
网站访问特点遵循二八定律：80%的业务访问集中在20%的数据上；
把经常访问的数据缓存起来，减少数据库访问，提高数据访问速度；

• 本地缓存：缓存在应用服务器上，速度快，但内存有限；
• 远程缓存：缓存服务器，集群；

4，应用服务器集群改善网站并发

遇到的问题：
单一应用服务器处理请求有限，高并发访问成瓶颈；

处理办法：

• 增加应用服务器分担压力，负载均衡；

5，数据库读写分离

遇到的问题：
没有被缓存的数据或缓存过期、缓存访问不命中需要访问数据库，用户量大，数据库负载压力大成瓶颈；

处理办法：

• 数据库主从，读写分离；

6，反向代理和CDN加速网站响应

遇到的问题：

用户规模逐渐增大，各地区、各营业商网络情况复杂，速度差别大；

处理办法：
CDN和反向代理基本原理都是缓存；

• CDN部署在网络提供商机房，用户就近访问；
• 反向代理部署在网站中心机房；

7，分布式文件系统和分布式数据库系统

遇到的问题：
文件服务器和数据库服务器都无法满足网站持续增长的业务需求；

处理办法：

• 分布式文件系统，如Hadoop 的HDFS，MFS(moosefs)等
• 分布式数据库（如MySQL Cluster）是数据库拆分的最后手段，只有在表单数据规模庞大时才使用；更常用的手段是数据库业务拆分；

8，使用NoSQL和搜索引擎

遇到的问题：
网站业务越来越复杂，对数据检索也越来越复杂

处理办法：

• 非关系型数据库如NoSQL
• 非数据库查询技术如搜索引擎（如sphinx）

9，业务拆分

遇到的问题：
大型网站将整个网站业务分成不同的产品线，分归不同的业务团队负责

处理办法：

• 根据业务划分，把网站拆分成不同应用独立部署维护；
• 通过消息队列进行数据分发，最多的还是通过访问同一个数据存储系统来关联；

10，分布式服务

遇到的问题：
业务划分越来越小，存储系统越来越庞大，应用系统整体复杂度呈指数及增加，部署维护越来越困难；数据库连接资源不足，拒接访问

处理办法：

• 将共同业务（如用户管理、商品管理）提取出来独立部署，
• 通过分布式服务调用公共业务；

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

1，架构随网站所需灵活应对
不是从无到有搭建一个大型网站，演化过程也不是放弃、推翻、剧烈革命，而是润物无声的转变、完善

2，驱动技术发展的主要力量是业务发展
创新的业务发展模式对网站架构逐步提出更高需求，是业务成就了技术，需要技术人员努力提高技术回馈业务；在业务问题还没理清时照搬成功互联网公司打造技术平台无疑是南辕北辙，缘木求鱼。

四、架构设计误区

1，一味追求大公司解决方案
大公司的经验和成功模式值得借鉴，但不能盲从，而应结合自身业务发展需要，找到适合自己的解决办法；

2，为了技术而技术
技术是为业务而存在，如果脱离业务发现的实际，一味追求时髦新技术，只会给自己造成困扰，结构之路越走越难；

3，企图用技术解决所有问题
比如12306网站，几亿中国人在同一时间点以同一窗口售票模式在网上售票，需要重构的不仅是它的技术架构，更重要的是他的业务架构；
比如售票方式上引入排队机制、整点售票改成分时段售票等等，后来证明12306确实是再朝这个方向发展；
技术是解决业务问题的一个手段，而业务问题有时候也可以通过业务手段来解决；