大型网站架构

架构模式

目标

• 高内聚、低耦合。便于开发和维护、不同模块分布式部署提高并发能力。
• 大型网站除了功能性的需求，更需要关注非功能性需求，包括性能、可用性、扩展性、伸缩性、安全性

分类

1. 分层。应用的横向切分，做到分散关注、松散耦合、逻辑复用、标准定义。
   • 应用层：具体业务和视图展示，和用户直接交互。
   • 服务层：提供服务支持。
   • 数据层：提供存储服务，如数据库、缓存、搜索引擎、文件。
2. 分割。应用的纵向切分，通常按照不同业务划分，专人做专事、不同等级保障。
3. 分布式。网络稳定性、数据一致性需要考虑。
   • 包括服务应用、静态资源、数据存储、计算、配置、锁、文件的分布式。
4. 集群。负载均衡和失效转移提供并发特效和可用性。
5. 缓存。在数据热点不均匀、数据有一定有效期的情况下使用。
6. 异步。堆积消息避开故障时刻提高可用性、减少rt、削峰。
7. 冗余。包括集群备份、冷热备份、灾备数据中心。
8. 自动化。发布过程、代码管理、安全监测、监控、失效转移恢复、降级、分配资源都可以自动化。
9. 安全。密码、验证码、加密、过滤、风控等。

核心架构要素

性能

What：
- 包括响应时间（rt）、并发数（同时处理的请求）、吞吐量（QPS TPS HPS）、服务器参数（load CPU等）。
- 吞吐量=并发数/响应时间
Why：打开缓慢的网站容易导致用户流失。
How

• 应用层：
  • 浏览器访问优化。
    • 减少http请求。合并js,css,图片。
    • 浏览器缓存。
    • 文件压缩。服务端压缩，浏览器解压，时间换空间。
    • css在上，js在下。防止阻塞页面加载：加载完所有css之后渲染，加载js后立刻执行。
    • 减少cookie传输量。
  • CDN缓存。缓存静态文件，如css,js,html,图片,视频等。
  • 反向代理。安全、缓存静态内容、负载均衡，缓存信息。
• 服务层：
  • 缓存：
    • 分布式缓存。减少访问时间和计算时间。
      • 缓存的数据不应频繁修改（读写比>2），有热点访问。
      • 需要处理实时问题带来的不一致和脏读。
      • 对于缓存穿透、击穿、雪崩的应对方案。
      • 需要提高缓存命中率。
      • 读写分离和代理缓存 解决热key问题。
    • 本地缓存。项目中使用高性能的Caffeine。深入理解caffeine，高性能 Java 缓存库 — Caffeine，深入解密来自未来的缓存-Caffeine
  • 异步。消息队列，异步dubbo等。
  • 响应式编程。请求->响应式流程编排->回调。
  • 集群。负载均衡，提升整体的qps。
  • 代码优化。
    • 多线程。由于IO阻塞和多CPU，提高资源利用率。可以用贫血模型对象、局部对象，注意并发资源处理线程安全问题。
    • 资源复用。单例和对象池（线程池、数据库连接池等）。
    • 垃圾回收。合理设置GC参数，尽量减少Full GC，或者G1避免。
• 数据层：
  • 固态硬盘。随机读取速度提高一个数量级。
  • LSM树。追加式存储，适合写为主，读操作集中在最近写入数据上。
    • hbase写入流程。
  • HDFS。管理block，每个block至少两个备份。
    • NameNode提供元数据服务，管理block分配，相当于FAT。DataNode提供数据服务。
    • 基于HDFS的Hbase。Hbase的region，Hbase的rowkey。

可用性

What：总时间扣除故障时间的总可用时间，大型网站通常要做到99.99%以上的可用性。
Why：故障代表用户损失、资金损失、PR风险。
How：

• 应用层
  • 无状态性：不保存业务的上下文，只根据请求参数响应。通过session服务器管理状态。
  • 负载均衡，实现无状态服务的失效转移。
• 服务层
  • 负载均衡。
  • 服务分级。高优先级的服务占用更好的硬件资源，部署在不同的宿主机上，甚至异地容灾。
  • 超时设置。服务方挂掉，超时重试或者使用降级策略。
  • 异步调用。隔离的基础上解耦。不影响调用方，需要调用结果进行下一步操作的不适合异步。
  • 重试。幂等性设计。保证多次调用和一次调用结果相同。
  • 限流。
  • 熔断。
  • 降级。
    • 拒绝服务。按照优先级或者随机拒绝，降低并发数，保证部分请求成功。
    • 关闭功能。关闭不重要的功能，减少开销。
    • 故障发生后补偿。
• 数据层。根据CAP原理，需要牺牲强一致。CAP
  • 数据备份。
    • 异步热备。例如mysql主从。
    • 同步热备。存储服务器没有主从之分。
  • 失效转移。失效确认、访问转移、数据恢复（从健康的服务器复制数据）。
• 软件质量把握
  • 版本管理。分布式服务场景下，分支开发、主干发布。可并行需求且主干代码永远是最新的状态可快速定位问题。
  • 自动化发布、自动化测试。
  • 预发布验证。预发机器不配置在对外的负载均衡服务器，或者需要带特定header才能访问。
  • 灰度发布。
• 监控。如cat监控告警，日志平台等。

伸缩性

What：不改变软件和硬件设计，只改变服务器的数量，扩大和缩小服务能力。
Why：如果不注意伸缩性，应对流量、数据的增长很难快速做出响应。
How：

• 架构上：
  • 不同功能进行物理分离实现伸缩。
    1. 水平方向：按照业务处理流程分离，比如API层、编排层、原子能力层、中间件层、存储层。
    2. 垂直方向：按照业务模块分离，比如商品、订单等。
  • 单一功能通过集群规模实现伸缩。分为无状态的应用层服务器集群、有状态的存储层数据服务器集群。
• 应用层：
  • 负载均衡。
    • 方式：http重定向、DNS域名解析、反向代理（典型如nginx）、IP负载均衡、链路层负载均衡。
    • 算法：轮询、加权轮询、随机、连接数、原地址hash（同一个ip来源同一个server处理）
• 存储层：通过元数据服务器、路由算法识别到数据在哪个分片上
  • 缓存：一致性hash+虚拟节点(少量节点增减时影响的数据量相对直接hash少的多)。如客户端分片的redis集群。
  • 存储：hbase的region分裂，redis cluster的槽迁移。

扩展性

What：能较小的影响现有系统，满足功能性需求。
Why：保障新功能开发成本较低，能够快速上线。
How：

• 架构上：
  • 模块化设计，降低耦合，提高复用性。
  • 设计符合开闭原则。
• 分布式消息队列：通过事件驱动架构（EDA）、队列（消息中间件、db实现的消息队列）等异步交互。
• 分布式服务：通过rpc、http等同步交互。
• 可扩展数据结构：json、hbase的列族等。
• 开放平台。

安全性

What:包括XSS攻击（跨站点脚本攻击）、注入攻击（SQL,OS注入）、CSRF攻击（跨站点请求伪造）等。

• SQL注入、XSS。对攻击字符用&nbsp替换消毒

How:

• 加密：
  • 算法有：单向hash加密（MD5、SHA），对称加密（DES、RC），非对称加密（RSA）
  • 密钥可以封装在server保存一份，也可以使用meta+shard的方式分片保存，减少算法被猜中的概率。
• 风控。规则引擎+统计模型。

参考

• 大型网站技术架构
• 李智慧 · 高并发架构实战课