现今，全球有近一半的人口在使用互联网，人们的生活因互联网而发生了巨大的改变。
在互联网跨越式的发展历程的背后是不堪重负的网站架构，某些 B2C 网站逢促销必宕机似乎成为一种必然的规律，最著名的例子就是早期的铁道部的电子客票售卖平台O(∩_∩)O~
1 大型互联网应用的特点
- 高并发，大流量：面对的是高并发的用户以及大流量的访问。
- 高可用：系统 7 * 24 小时不间断服务。
- 海量数据：需要存储并管理海量的数据，这会用到大量的服务器。
- 用户分布广泛，网络情况复杂：许多的大型互联网应用都是为全球用户服务的，但用户分布范围广，而且各地的网络情况千差万别。
- 安全环境恶劣：由于互联网的开放性，会使得网站很容易收到黑客的攻击。
- 需求快速变更，发布频繁：大型网站每周都会有新版本发布，而中小型网站可能一天会发布几十次。
- 渐进式发展：几乎所有的大型互联网网站都是从小网站起步，然后渐进发展的。
2 架构演化发展历程
因为庞大的用户，高并发的访问量以及海量的数据，所以任何简单的业务都要处理以 P（10 的 15 次方，1000 T = 1 P）级的数据，以及面对数以亿计的用户。我们的架构就是为了解决这些问题。
2.1 初始阶段
小型网站没有太多人访问，所以只需要一台服务器就够咯：
应用程序、文件、数据库都部署在一台服务器上，通常是使用 LAMP（Linux/Apache/MySQL/PHP）。
2.2 应用服务和数据服务分离
随着业务的发展，越来越多用户的访问导致性能越来越差，而越来越多的数据也会耗尽存储空间。这时，我们就需要将应用与数据分离：
这里使用三台服务器：应用服务器、文件服务器和数据库服务器。它们对硬件资源的要求不同。
| 服务器 | 对硬件资源的要求 | 说明 |
|---|---|---|
| 应用服务器 | 更快的 CPU | 要处理大量的业务逻辑 |
| 文件服务器 | 更大的硬盘 | 要存储大量用户上传的文件 |
| 数据库服务器 | 更快的硬盘和更大的内存 | 需要快速的磁盘检索和数据缓存 |
不同特性的服务器可以承担不同的服务角色，使得网站的并发处理能力和数据存储空间都有了很大的改善。
但随着用户数量的再次增长，发现数据库的压力太大而导致的网站访问延迟问题，所以需要再次优化。
2.3 使用缓存改善性能
网站访问的特点遵循经典的二八定律：80% 的业务访问集中在 20% 的数据上。所有我们把这一小部分数据缓存在内存中，就能减少数据库的访问压力。
缓存可分为两种。在应用服务器上的本地缓存和在分布式缓存服务器上的远程缓存。
| 缓存类型 | 优点 | 不足 |
|---|---|---|
| 本地缓存 | 访问数据相对快 | 受应用服务器内存限制，可缓存的数据量有限 |
| 远程缓存 | 理论上可不受内存容量的限制 | 访问数据相对慢 |
远程分布式缓存使用集群，而且可以使用安装了大内存的服务器作为专门的缓存服务器。
使用缓存后，数据库的访问压力得到缓解，但单一的应用服务器能够处理的请求连接有限，所以在网站访问的高峰期，有可能成为整个网站的瓶颈。
2.4 应用服务器集群
使用集群是解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，最恰当的做法是增加新的服务器，让它来分担原有服务器的访问和存储压力。
我们可以通过持续地增加服务器，来不断改善系统的性能，从而实现系统的可伸缩性：
通过负载均衡调度服务器，我们可以将用户的访问请求分发到应用服务器集群中的任何一台服务器上。如果有更多的用户，我们就可以在集群中加入更多的应用服务器咯O(∩_∩)O~
2.5 数据库读写分离
使用了缓存后，使得绝大多数数据的读操作可以不通过数据库就能完成。但仍然有部分的读操作（因为缓存访问没有命中或者缓存过期）和全部的写操作需要访问数据库，所以在用户量达到一定规模时，数据库还是会因为负载过高而成为瓶颈。
目前的主流数据库都提供了主从热备功能，可以通过配置两台数据库的主从关系，把一台数据库服务器的数据同步到另一台服务器上。我们可以利用这个功能，实现数据库的读写分离，进一步提高数据库的负载能力：
为了便于应用程序访问读写分离的数据库，一般会在服务器端使用专门的数据访问模块，让数据库的读写分离机制对应用程序透明，这样做不仅降低了代码编写的复杂度，还提高了可维护性，可谓两全其美O(∩_∩)O~
2.6 使用反向代理和 CDN 加速响应
网站的访问延迟与用户的流失率正相关！因为网站访问的越慢，用户就越容易失去耐心而离去哦。
反向代理和 CDN 都是依赖缓存。区别是，CDN 是部署在网络供应商的机房，用户请求服务时，会从距离他最近的网络供应商机房获取数据；而反向代理是部署在网站的中心机房，所以用户请求服务式，会先访问反向代理服务器，如果它缓存着用户所请求的资源，就会直接把资源返回给用户！
使用反向代理和 CDN 的目的都是为了尽早地把数据返回给用户，这样不仅加快了用户的访问数据，而且也减轻了后端服务器的负载压力。
2.7 使用分布式文件系统和分布式数据库系统
如果之前的架构仍然不能满足需求，那么就要使用分布式的文件系统和数据库系统啦O(∩_∩)O~
注意：一般情况下是对业务数据进行分库，即将不同业务的数据库部署到不同的物理服务器上。只有在单表的数据规模非常庞大时，才使用分布式数据库！
2.8 使用 NoSQL 和搜索引擎
随着业务变得越来越复杂，对数据存储和检索的需求也会变得复杂起来，这时候就会用到 NoSQL 和搜索引擎啦：
应用程序通过数据访问模块来访问搜索引擎与 NoSQL 服务器，这样就可以减轻应用程序管理多数据源的麻烦啦O(∩_∩)O~
2.9 业务拆分
为了应对日益复杂的业务场景，通常使用分而治之的手段，把业务划分为不同的产品线。
每个应用独立部署维护，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，更通常的做法是通过访问同一个数据存储系统来构建一个完整的关联关系。
2.10 分布式服务
随着业务被拆分的越来越小，存储系统变得越来越大，应用系统的整体复杂度呈指数级增长，部署和维护变得越来越困难。
这时候，我们可以把某些共用的服务提取出来，独立部署。而应用系统只需要管理用户界面，然后通过分布式服务调用共用的服务，来完成业务操作啦：
架构演化到了这里，大多数的技术问题都可以解决啦O(∩_∩)O~
这些解决方案甚至可以应用到网站自身业务之外，目前有许多大型网站都建设了云计算平台，将计算作为一种基础资源出售出去，这样中小网站就可以不必在关心架构问题，只要按需付费，就可以享受更大的存储空间和更多的计算资源啦。
3 架构演化的价值观
大型网站都是从小型网站发展而来的。关键是这个网站能够为用户提供什么价值。如果在网站还很小的情况下，就去追求架构是舍本取末的表现，得不偿失。小型网站需要为用户提供好的服务来创造价值，获得用户的认可，这才是正途。
所以中小网站大多使用 LAMP 技术（Linux + Apache + MySQL + PHP），因为它们即便宜又简单，而且对于中小网站来说，已经是绰绰有余得啦O(∩_∩)O~
3.1 架构技术的核心价值
架构技术的核心价值是应需而变，灵活应对。通过业务的逐步发展，慢慢演化成为一个大型网站。
3.2 驱动技术发展的力量
驱动技术发展的力量是业务的发展。
记住：是业务成就了技术，事业成就了人。
4 设计的误区
4.1 一味追求大公司的解决方案
大公司的经验与成功模式值的学习借鉴，但如果因此变得盲从，迟早会迷失方向。
4.2 为了技术而技术
技术是为了业务而存在的。如果一味追求时髦的技术，很有可能会把网站的技术发展引入歧途。
4.3 企图用技术解决所有问题
技术不是银弹，它不是万能的！比如之前的 12306 的售票网站，之所以出现故障，真正的问题其实不是它的技术架构，而是出在业务架构上！它根本不该像淘宝那样，搞促销秒杀的手段（让几亿人在零点买十几天后的车票），买车票是刚需，所以搞促销干嘛呀O(∩_∩)O~
后来的 12306 换了一种卖票方式，它引入了排队机制、整点售票改为分时段售票。所以如果能够控制并发访问的量，很多棘手的技术问题自然迎刃而解啦。
技术可以解决业务问题，而业务问题也可以通过业务的手段来解决哦O(∩_∩)O~
