关于大型网站

大型网站是相当于企业级应用来说的，特点有

• 高并发，大流量
• 高可用
• 海量数据
• 用户分布广泛，网络情况复杂
• 安全环境恶劣
• 需求快速变更，发布频繁
• 渐进式发展
  
  

核心要素

架构是“最高层次的规划，难以改变的规定”。主要关注五个要素：

• 性能
• 可用性(Availability)
• 伸缩性(Scalability)
• 扩展性(Extensibility)
• 安全性
  
  

大型网站追求的性能指标

可用性 availability

在服务器宕机时，服务和应用是否依旧可用。网站使用的商用服务器硬件的设计目标本身并不保证高可用性。必须在系统设计层面予以考虑。

伸缩性 scalability

定义：往集群中加入服务器的手段，缓解并发访问压力的难易程度

扩展性 extensibility

满足功能需求的难易程度。一般使用事件驱动的架构或分布式服务实现。

安全性 security

大型网站的演化发展历程

任何大型网站都是从小网站进化出来的：

阶段 1

应用程序、文件、数据库都在同一台服务器上

阶段 2

应用和文件、数据分离。使用三台专职服务器：

• 文件服务器：执行大量业务逻辑，需要CPU优化的硬件

• 数据库服务器：磁盘读写和缓存读写，需要快速的硬盘和内存

• 文件服务器：大硬盘
  

阶段 3

数据库成为瓶颈。加入对最hot的20%的数据缓存：

• 应用服务器上的本地缓存（大小受限）

• 专门的分布式缓存服务器集群上的远程缓存
  

阶段 4

应用服务器成为瓶颈。将应用服务器扩展为集群。
此时的问题：

• Session管理：4种方式
  • 复制：服务器之间同步所有session。资源利用率太低。
  • 绑定：利用load balancer的源地址Hash，确保同一IP的请求被分发到同一服务器。可用性目标很难达到，一旦某台服务器宕机，它维护的所有session就会丢失
  • Cookie记录：不少网站采用。但受限cookie的大小，并且如果用户关闭浏览器的cookie功能，session就将无法工作。
  • 专用session服务器：将应用服务器分为有状态和无状态部分。有状态的部分用专门的session服务器来维护。一般来说redis是一个很好的选择。
    

阶段 5

对数据看的写操作和未命中缓存的读操作，在用户达到一定规模后使得数据库再次成为瓶颈。这时启用主从备份功能：

1.写数据直接写到主数据库
2.主数据库通过主从备份机制把写数据更新到从数据库
3.读操作读取从数据库

阶段 6

随着网站用户群扩散，特定地区的用户访问网站会遇到性能问题。此时开始对前端性能进行优化，启用CDN和反向代理

阶段 7

单机数据库和文件系统不能满足性能和高可用性需求，启用分布式数据库和分布式文件服务器：

• 分布式存储系统的三类故障：

  • 瞬时鼓掌：网络中断、服务器GC等，可重试后自行恢复
  • 临时故障：交换机宕机、网卡松动、内存损坏、CPU过热等，需要人工干预，持续几十分钟到几个小时
  • 永久故障：硬盘损坏

• 使用备份和冗余

• 服务器宕机下的失效转移：确认失效 -> 访问转移 -> 数据恢复

• CAP原理：可用性、某种程度上的数据一致性、伸缩性之间的权衡

  • 强一致：各个副本数据总是一致的，对更新和读操作的响应也是一致的
  • 用户一致：各个副本的数据可能是不一致的，但是用户一旦访问数据，就会通过纠错和校验机制确保用户得到的数据是一致正确的
  • 最终一致：各个副本的数据可能是不一致的，用户得到的数据也可能是不一致的（同一个用户连续访问，或者多个用户同时访问，结果不同）。但是系统经过一段时间的自我恢复和修正，数据最终达到一致。

阶段 8

网站业务越来越复杂，对搜索和存储的需求也越来越复杂。此时引入NoSQL和非数据库查询技术，如搜索引擎。

阶段 9

业务场景复杂度与日俱增，此时开始采取分而治之的手段把网站业务拆分成不同的产品线。技术上网站被拆分成多个独立维护的应用。应用之间通过如消息队列等手段通信。

阶段 10

随着业务拆分越来越小，应用系统的整体复杂程度急剧上升，部署和维护越来越困难。此时采取分布式服务架构，把公共的可复用业务提取出来独立部署