大型网站架构：前言

1. 概要

大型网站的技术架构是什么？

1. 业务子系统拆分？
2. 服务化拆分？
3. …

常见问题：

1. 大型网站，关于并发的处理？
2. 大型网站，跟小的业务系统，有差异吗？有什么特殊的处理？
3. 大型网站，完整的技术架构，核心模块都有哪些？数据？订单？账户？服务？监控？有哪些衡量维度？

2. 讨论

2.1 讨论形式

• 内容来源：一方面要有自己的思路、另一方面借鉴别人的总结（xx等）
• 形式：
  • 侧重典型场景，避免过于牵扯细节
  • 一图胜千言，多使用图片
  • 讨论之前，明确问题：什么问题？怎么解决的？什么原理？不做糊涂的讨论
  • 每次讨论，单独准备 keynote、wiki，方便问题聚焦，避免无谓的切换
  • 不指定主讲人，谁想讲谁讲，每次主持 2 人
  • 做好前期计划、后期总结：问题、资料整理
  • 学习小组最终结束时，讨论出一个汇总、定稿
• 时间：
  • 25mins 场景介绍 + 15mins 自由讨论
  • 力求简短

2.2 整体汇总

整体的讨论主题和核心问题：

1. 大型网站，要讨论哪些问题？
   1. 明确讨论的核心内容
   2. 做好前期热身、统一思路、聚焦问题
2. 高性能：网站极速响应
   1. 实际意义？业务价值？
   2. 如何监控：响应速度？
   3. 如何优化：响应速度？
   4. 影响响应速度的因素？
   5. 高并发对网站响应速度的影响？
   6. 汇总：工作中，可采用的措施？
3. 高可用：服务万无一失
   1. 实际意义？业务价值？
   2. 如何监控？
   3. 如何改进？
   4. 原理？
   5. 汇总：工作中，可采用的措施？
4. 伸缩性：能屈能伸
   1. 实际意义？业务价值？
   2. 什么时候伸缩？
   3. 基本原理？
   4. 汇总：工作中，可采用的措施？
5. 扩展性：随机应变中间件
   1. 什么场景下，引入哪些中间件？
   2. 常见的中间件，带来的收益？引入的成本？

3. 详细讨论

3.1 主题：高性能

具体：

1. 目的：达到高性能
   1. 如何量化高性能
      1. 用户角度：响应时间（服务器处理时间+网络传输+浏览器渲染, TP50, TP90, TP99）
      2. 开发人员：服务器处理时间，吞吐量（QPS, TPS, HPS），并发量，性能计算量（CPU, MEM等）
      3. 运维人员：资源利用率
   2. 常见的时间
      1. CPU执行时间：ns~us
      2. 内存读取时间：us?
      3. 网络读取时间：us~ms?
      4. 机械磁盘读取：ms?
      5. 数据库索引：ms?
   3. 并发数：【正在处理】和【等待处理】的线程数量（就绪态和执行态，不包括阻塞状态）
   4. 吞吐量：TPS，QPS，HPS的具体含义？？？
   5. 并发数 和 吞吐量的关系：非完全正相关，资源的最大限度等影响因素
      1. 以响应时间为参考：最佳运行点(调优点)，最大负载点，崩溃点
   6. 性能计数器
      1. 系统负载：（正在执行+等待执行的线程）/ CPU核心数目；也包括其他应用的并发数；0.3， 0.5， 0.7， 1，最好运行在0.5附近
      2. CPU, 内存，磁盘IO等
   7. 大的方面分为：APP级别的指标 和 系统级别的指标
2. 监控
   1. APP级别
   2. OS和JVM级别
   3. 压力测试
3. 途径：改进方案
   1. Web前端性能优化：合并请求，缓存，数据大小，渲染机制，CDN加速，……
   2. Server后端性能优化：缓存，消息队列，集群，优化代码，……
      1. 多线程衡量：（CPU执行时间+IO执行时间）/CPU执行时间
   3. 存储性能优化：固态硬盘，数据结构，RAID，HDFS

3.2 主题：高可用

具体：

• 概要：
  • 系统不可用的因素：
    • 自然力量
    • 软硬件
    • 外部攻击：DDOS、DNS劫持
  • 系统高可用的实际意义：
    • 用户服务体验
    • 业绩考核
    • 对外承诺：产品质量
• 度量：如何判断是否为「高可用」？
  • 可用性指标：调用成功的次数/所有调用的次数，可用时间/总时间
  • 故障等级：CaseStudy
• 监控：如何监控「指标」？
• 优化：
  • 高可用架构：水平分层、垂直分割
  • 应用层的高可用：
    • 无状态服务器，负载均衡
    • 集中的 Session 服务器
    • 负载均衡：
      • DNS 负载均衡：DNS 信息同步延迟，不实用
      • LVS 四层负载均衡：在第 4 层（传输层）进行负载均衡
      • Nginx 七层负载均衡：在第 7 层（应用层）进行负载均衡
  • 服务层的高可用
  • 分布式服务框架：演变 rpc→ SOA，开源服务框架
    • 阿里 dubbo
    • 淘宝 hsf
    • coral service
    • 腾讯 MSEC
    • google ？twitter？facebook？网易？
    • 其他参考： http://o9l56z0kf.bkt.clouddn.com/image/blog/distributed-system.jpg

问题：

• Session 中，记录用户状态？要记录哪些数据？为什么要记入 Session？写入 DB 不行么？
  • Session基础作用记录：SessionID 跟 userId 之间的绑定关系
  • 现在采用 Token 类似，Session
  • Servlet 规范支持，如果 cookie 被浏览器禁用，则，自动添加到 url 后缀中，Servlet 能够自动识别
• 长连接的实现细节：是否涉及所有链路？

3.3 主题：伸缩性

具体：

• 概要
• 维度：横向、纵向
  • 各种负载均衡：HTTP、重定向、DNS、反向代理、IP层、数据链路层
  • 复杂均衡算法：轮询、加权轮询、随机、最小连接、源地址散列（一致性 hash）
  • 分布式缓存集群
    • 算法：余数Hash，一致性Hash
      • 一致性Hash定义，优点：影响较少的已有数据（一致性 hash 的详细过程）
      • 一致性Hash的问题：节点不均匀，改进方案：虚节点
    • 实现方式：Proxy、Client SDK、Server proxy
  • 数据存储
    • 关系型数据库
      • 读写分离：读、写、分析，分离
      • 业务分割：跨库事务、join
      • 分表

3.4 主题：扩展性

具体：

• 概要
• 可扩展性
  • 思路
    • 模块化（思想）
    • 分层分隔（软件）
    • 分开部署（硬件）
  • 方式
    • 分布式消息队列：事件驱动、分布式消息队列（MQ）
    • 分布式服务：横向拆分、纵向拆分
    • 可扩展的数据结构（什么含义？）
    • 开放平台

4. 参考资料

• 《大型网站技术架构：核心原理与案例分析》
• Software Architecture Patterns
• 软件架构入门 阮一峰