《大型网站技术架构》读书笔记

第一篇 概述

1. 大型网站架构演化

大型网站软件系统特点

• 高并发，大流量: 以P计的数据
• 高可用：系统7*24小时不间断服务。
• 海量数据：需要存储、管理海量数据
• 用户分布广泛，网络情况复杂
• 安全环境恶劣
• 需求快速变更，发布频繁
• 渐进式发展

大型网站架构演化历程

• 初始阶段网站架构：单机，liux+apache+php+mysql
• 应用服务和数据服务分离
  • 应用服务器需要处理大量的业务逻辑，需要更快更强大的CPU
  • 数据服务器需要更快速磁盘检索和数据缓存，需要更快的磁盘和更大的内存
  • 文件服务器需要存储大量用户上传文件，需要更大的硬盘
• 使用缓存改善网站性能
  • 本地缓存
    • 访问更快
    • 缓存数据量有限，受服务器限制
    • 多台服务器一致性
    • 与应用服务器争用内存
  • 分布式缓存
    • 不受服务器内存限制
• 使用应用服务器集群改善网站并发处理能力
  • 通过负载均衡调度服务器，可将来自用户请求分发到应用服务器集群中的任意一台服务器上。
• 数据库读写分离
  • 利用数据库主从热备功能，实现读写分离
• 使用反向代理和CDN加速网站响应
  • CDN和反向代理基本原理都是缓存
  • CDN 部署在网络提供商的机房，可根据最近距离提供数据给用户
  • 反向代理则部署在网站的中心机房，如果反向代理缓存着用户资源就直接返回用户。
  • 加快访问速度、改善用户体验、减轻后端服务器压力
• 使用分布式文件系统和分布式数据库系统
  -常用 业务分库
• 使用NoSQL和搜索引擎
  • NoSQL对可伸缩的分布式特性具有更好的支持
• 业务拆分
  • 网站通过超链接建立联系
  • 通过消息队列进行数据分发
  • 通过访问统一数据库系统构成关联的完整系统
• 分布式服务

演化原则

• 随网站所需灵活应对
• 业务驱动技术发展

网站架构设计误区

• 一味追求大公司解决方案
• 为了技术而技术，而脱离业务
• 企图用技术解决所有问题

2. 架构模式

• 分层
  • 将网站系统分成应用层、服务层、数据层
  • 严格遵循分层架构约束，禁止跨层次调用（应用层直接调用数据层）及逆向调用（数据层调用服务层）
  • 应用层可以再细分视图层、业务逻辑层
  • 服务层也可以细分数据接口层和逻辑处理层
• 分割
  • 将不同功能和服务分割开来，包装成高内聚低耦合的模块单元。
• 分布式
  • 对应大型网站，分层和分割的一个最主要目的是为了切分后的模块便于分布式部署。
  • 分布式带来问题
    • 服务间通过网络调用影响性能
    • 服务器越多，服务器宕机概率增大
    • 保持数据一致性困难
    • 网站依赖错综复杂，开发维护难
    • ....
  • 分布式方案
    • 分布式应用和服务
    • 分布式静态资源:
      • 将静态资源独立分布式不是，并采用独立域名，实现动静分离（独立域名可加快浏览器并发加载速度）
    • 分布式数据和存储
    • 分布式计算
• 集群
  • 多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务
• 缓存
  • 缓存是改善软件性能第一手段
  • 缓存类别
    • CDN
    • 反向代理
    • 本地缓存
    • 分布式缓存
  • 使用缓存前提：
    • 数据访问热点不均衡
    • 数据在某个时间点有效不会很快过期，否则缓存数据就会因为已经失效而产生脏读，影响结果正确性。
• 异步
  • 异步实现方式
    • 多线程共享内存队列
    • 分布式消息队列
  • 异步作用
    • 降低软件耦合性
    • 提高系统可用性
    • 加快网站响应速度（不需要等待消费者服务器处理完毕就可以返回，响应延迟减少）
    • 消除并发访问高峰
• 冗余
  • 服务冗余，构建集群
  • 数据库冗余
    • 定时备份，存档保存，实现冷备份
    • 数据库进行主从分离，实时同步热备份
    • 全球部署灾备数据中心
• 自动化
  • 自动化代码管理
  • 自动化测试
  • 自动化安全检查
  • 自动化部署
  • 自动化监控、报警
  • 自动化失效转移及失效恢复
  • 自动化降级
  • 自动化分配资源
• 安全
  • 通过密码、手机校验码进行身份认证
  • 使用验证码等识别机器人程序
  • 对网站通信进行加密
  • 敏感数据进行加密存储
  • 常见XSS攻击、SQL 注入、进行处理
  • 对垃圾信息、敏感信息进行过滤
  • 对重要的操作根据交易模式和交易信息进行风险控制。

3. 大型网站核心架构要素

• 性能
• 可用性
  • 衡量系统架构是否满足高可用目标，就是系统任何一台或者多台服务器宕机时，以及出现各种不可预期问题，系统整体是否依然可用
  • 高可用主要手段是冗余
  • 通过负载均衡组成集群共同对外提供服务。
• 伸缩性
  • 所谓的伸缩性是指不断向集群加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求
  • 衡量架构伸缩性主要标准：
    • 是否可以用多台服务器构建集群，
    • 是否容易向集群中添加新的服务器
    • 加入的新服务器后是否可以提供和原来服务器无差别的服务
    • 集群可容纳的总服务器数据是否有限制。
• 扩展性
  • 网站扩展性直接关注网站功能需求，能迅速响应需求变化
  • 衡量标准：
    • 增加新业务产品，是否可以实现对现有产品透明无影响，无需或者很少改动
    • 不同产品之间是否很少耦合
• 安全性
  • 衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略

第二篇 架构

4. 瞬时响应：网站高性能架构

性能优化主要工作是改善高并发用户访问情况下网站响应速度，最终目的就是改善用户体验，使用户感觉很快。即可使用技术手段，也可以通过优化交互体验改善。

网站性能指标

• 响应时间
  • 注意如果测试目标花费时间极少，那测试程序占用时间多，那测试很难测试出系统响应时间。可以重复执行求平均。
• 并发数
  • 网站并发数，指同时提交请求的用户数目
  • 网站系统用户数>> 网站在线用户数>>网站并发用户数
• 吞吐量
  • 吞吐量指单位时间内系统处理请求的数量，提现系统的整体处理能力
  • 常用的指标还有TPS(每秒事物数)、HPS(每秒HTTP请求数)、QPS(每秒查询数)等
  • 系统并发量增大过程中，系统吞吐量先是逐渐增加，达到极限后，反而下降，达到系统崩溃点后，吞吐量为0
• 性能计数器
  • 描述服务器或操作系统性能一些数据指标，包括System load(系统负载)、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标
  • 系统负载，指当前被CPU执行和等待被执行的进程数目总和，最完美的system load是负载值等于CPU值。

性能测试方法

• 性能测试
• 负载测试
• 压力测试
• 稳定性测试

性能优化策略

• 性能分析
• 性能优化

Web前端性能优化

• 浏览器访问优化
  • 减少http 请求
    • 合并css、js、合并图片
    • 合并接口，减少接口请求
  • 使用浏览器缓存
    • 使用Cache-Control、Expires属性，设置缓存时间，缓存静态资源
    • 更新静态资源,采用变更文件名实现，并更新引用，而不是仅仅更新内容
  • 启用压缩
    • 采用Gzip压缩可以减少80%以上流量传输，但是对服务器及浏览器有一定的压力
  • css 放在页面最上面、js 放在页面最下面
    • 浏览器下载完全部css之后才对整个页面进行渲染，最后将css放置最上部
    • 如果页面解析需要用到js,js也放置底部就不合适。
  • 减少cookie传输
    • 静态资源使用独立域名访问，避免请求静态资源发送cookie
    • 减小cookie传输内容
• CDN 加速
  • cdn能够缓存的都是一些静态资源，如图片、文件、css、静态网页等
  • cdn部署在网络运营商机房，而这些运营商又是终端用户网络服务提供商，离用户链路近
• 反向代理
  • 使用反向代理，在系统服务器之前建立屏障，可加强安全保障
  • 反向代理服务上缓存静态资源，加速web响应请求，减轻服务器负载压力
  • 可将动态内容也缓存在代理服务器上，当动态内容有变化时，通过内部通知机制通知反向代理缓存失效，然后重新加载最新动态内容。
  • 反向代理还可实现负载均衡功能，构建应用集群，提高性能

应用服务器性能优化

• 分布式缓存
  • 网站性能优化第一定律：优选考虑使用缓存优化性能
  • 缓存原理：将数据存储相对较高访问速度的存储介质中，提高访问速度。
  • 不适合缓存
    • 频繁修改的数据
    • 没有数据热点访问
    • 数据要求强一致，容忍不了短时间不一致
  • 缓存可用性
    • 采用集群、缓存预热等手段提高缓存可用性
  • 缓存预热，最好在缓存系统启动时就把热点数据加载好，进行缓存预热，然后再接入系统
  • 缓存穿透，缓存没有保存该数据，请求落到数据库上，就是缓存穿透。当缓存穿透过多，数据库也承受不来会发生崩溃，最好将不存在也缓存起来（其值为空值）
  • 分布式缓存架构
    • 以JBOSS为代表的需要同步更新的分布式缓存
      • 所有服务保存相同数据，当某一台数据更新，通知集群其他机器更新或清除数据
      • 容量受单台内存空间限制
    • 以Memcached为代表的互不通信的分布式缓存
      • 通过一致性Hash等路由算法选择缓存服务器远程访问路径
      • 缓存集群规模容易扩容，具有良好可伸缩性
      • Memcached使用TCP(UDP也支持)协议通信，其序列化协议则基于文本的自定义协议，非常简单，以一个命令关键字作为开头，后面是一组命令操作数，例如 get <Key>。
• 异步操作
  • 使用消息队列快速返回应答
  • 使用消息队列削峰平谷。
  • 在高并发业务处理中，任何可以晚点做的事情，尽量晚点做
  • 异步处理完成记得使用邮件、sms消息等通知用户
• 使用集群
  • 使用负载技术构建多台机器组成的服务器集群。
• 代码优化
  • 多线程
    • 使用多线程主要原因：IO阻塞与多CPU
    • 最佳启动线程数=[任务执行时间/（任务执行时间-IO等待时间）]*CPU内核数
    • 注意线程安全
  • 资源复用
    • 尽量减少那些开销很大的系统资源的创建和销毁，比如数据库连接、网络通信、线程、复杂对象等
    • 复用主要方式
      • 单例
      • 对象池
  • 使用合适数据结构
  • 垃圾回收
    • 堆是主要存储对象的内存空间，对象的创建和释放、垃圾回收就在此进行
    • 栈存储线程上下文信息，如方法参数、局部变量等
    • JVM分代垃圾回收机制，将堆空间分为年轻代（Young Generation)和年老代，又将年轻代分为Eden区、From区和To区
    • 当Old Generation空间也用完，就会触发Full GC，即所谓的全量回收，全量回收对系统性能会产生较大影响
    • 应根据系统业务特点，合理设置Young Generation 和Old Generation大小，尽量减少Full GC。

存储性能优化

• 使用固态硬盘代替机械硬盘
  • 机械硬盘在数据连续访问（要访问的数据在连续的磁盘上)和随机访问（要访问的数据存储在不连续的磁盘空间）时，由于移动磁头臂的次数相差巨大，性能表现非常大
  • 固态硬盘，没有机械装置，数据存储可持久记忆的硅晶体上，可以像内存一样快速随机访问，具有更小功耗、更少的磁盘震动与躁动。但是SSD可靠性、性价比待提升。
• B+树 vs LSM 树
  • 目前数据库多采用两级索引的B+树，树层级最多三层。因此可能需要5次磁盘访问才能更新一条记录（三次磁盘访问获取数据索引及行Id,然后再进行一次数据文件读操作及一次数据文件写操作）
  • 目前很多NoSQL产品采用LSM 树作为主要数据结构
  • LSM可以看做N阶合并树。数据写操作都在内存中进行，并且创建一个新记录，如果数据量超过设定的内存法制，会将这棵排序树与磁盘最新排序树合并。在进行读操作，总是从内存排序树中开始搜索，如果没有找到，就从磁盘上的排序树顺序查找。LSM 更新不需要访问磁盘，在内存即可完成，速度远快于B+树，而如果读操作几种最近写入的数据，使用LSM可以极大程度减少磁盘访问次数，加快速度
• 使用RAID技术加速磁盘访问
  • RAID(廉价磁盘冗余阵列)主要改善磁盘访问延迟，增强磁盘可用性和容错性。
  • 服务器上插入多块磁盘，使用RAID技术实现数据在多块磁盘上并发读写和数据备份
  • RAID技术目前有RAID0、RAID1、RAID01、RAID3、RAID5、RAID6
  • RAID6,数据只写入N-2块磁盘，并螺旋地在两块磁盘中写人校验信息。
• 使用HDFS
  • HDFS以块为（block)单位管理文件内容，一个文件被分割为若干block ，当程序写文件时，每写完一个Block,HDFS就将其自动复制到另外两台机器。
  • 数据库（block)默认为64M，不适合存储小文件

5. 万无一失：网站的高可用架构

网站可用性指 网站可有效访问。

高可用架构设计的主要目的就是服务器硬件故障时，服务依然可用、数据依然保存并能够被访问。

实现高可用架构主要的手段是数据和服务的冗余备份和失效转移。

高可用架构设计需要考虑硬件宕机，还需考虑升级发布引起的宕机。

影响网站可用性

• DNS 被劫持
• CDN 挂掉
• 网站服务器宕机
• 网络交换机失效
• 硬盘损坏
• 网卡松动
• 机房停电
• 空调失灵
• 程序bug
• 黑客攻击
• 促销引发大量访问
• 第三方合作伙伴服务不可用.....

服务器高可用方案

• 通过负载均衡进行无状态的失效转移
• 分级管理
  • 服务器分级管理，核心应用和服务使用好设备，运维响应更迅速
  • 服务部署进行隔离
• 超时设置
• 异步调用
  • 不影响主流程的服务，可以通过消息队列或者异步线程执行
• 服务降级
  • 拒绝服务
    • 拒绝低优先级应用调用，减少服务调用次数，确保核心应用正常使用
    • 或者随机拒绝请求调用，节约自然，让一部分请求得以成功。
  • 关闭服务
    • 关闭不重要服务，或者服务内部关闭部分功能，以节约系统开销，为重要服务和功能让出资源

高可用服务问题

• 应用集群session 管理
  • session 复制
    • 集群中服务器同步不sessio对象，使每台服务器保存所有用户的session 信息
    • 适合小集群，加重服务器网络、及内存资源
  • session 绑定
    • 通过负载均衡，将来源同一IP的请求分发到同一台服务器上，该机器保存该用户session。
    • 或者通过cookie信息将同一用户请求分发到同一台服务器，
  • 利用cookie记录session
    • 将session 记录在客户端，每次请求将session 发送给服务器，服务器处理完请求后再修改session响应给客户端。
    • session容量受cookie大小限制
    • 每次都需要传输cookie影响性能
    • 用户关闭cookie访问不正常。
  • session 服务器
    • 独立部署session服务器，统一管理session
    • 应用每次读写session 都需要访问session 服务器
• 幂等性设计
  • 失效转移可能是虚假的失败，导致服务被重复调用，必须保证服务重复调用和调用一次产生结果相同，即具有幂等性。
  • 特别注意 事务性操作的幂等性。

高可用数据

保证数据存储高可用的手段是数据备份和失效转移机制

• 数据备份
  • 冷备份
    • 定时将数据复制到存储介质上物理存档保存。
  • 热备份
    • 异步热备份
      • 应用写入一份，然后存储系统将异步写入其他副本。
    • 同步热备份
      • 多分数据副本写入同步完成
      • 存储没有主从之分，完全对等，便于管理和维护
      • 数据延迟是响应最慢的那台服务器
• 失效转移
  • 失效确认
    • 心跳检测
    • 应用程序访问失败报告（控制中心还需要再一次发送心跳包检测进行确认）
  • 访问转移
  • 数据恢复
    • 宕机后，从健康服务器中复制数据，将副本数目恢复设定值

网站质量保证方式

• 保证发布用户不可感知，不影响服务使用
• 自动化测试
• 预发布验证
• 代码控制
• 自动化发布
• 灰度发布

网站运行监控

不允许没有监控的系统上线

• 监控数据采集
  • 用户行为日志收集
    • 服务器端日志收集
    • 客户端浏览日志收集
  • 服务器性能监控
    • 系统load、内存占用、磁盘IO、网络IO等
    • 对性能指标作出预警
  • 运行数据报告
    • 监控与具体业务场景相关的技术和业务指标，比如响应延迟、缓存命中率、待处理任务总数
• 监控管理
  • 监控数据收集后，除用作系统性能评估、集群规模伸缩性预测等，还可以进行监控数据进行风险预警、对服务器进行失效转移，自动调整负载，最大化利用集群机器资源
  • 系统报警
  • 失效转移
  • 自动优雅降级

6. 永无止境：网站伸缩性架构

网站的伸缩性是指不需改变网站的软硬件设计，仅仅通过改变部署服务器数量就可以扩大或者缩小网站的服务器处理能力。

网站伸缩性设计

• 根据功能进行物理分离实现伸缩性
  • 不同服务部署机器，提供不同功能
  • 纵向分离：将业务处理流程不同部分分离部署，实现系统伸缩性，比如数据库、缓存、静态资源、基础服务等分离部署
  • 横向分离：将不同业务模块分离部署，实现系统伸缩性
• 单一功能通过集群实现伸缩
  • 集群多台机器部署相同服务，提供相同功能
  • 应用服务器集群伸缩性
  • 数据服务器集群伸缩性
    • 缓存数据服务器集群
    • 存储数据服务器集群

应用服务器集群伸缩性设计

• 应用服务设计为无状态
• Http 重定向负载均衡（少见不推荐）
• dns 域名解析负载均衡
  • 通过负载均衡算法返回不同ip地址
  • dns 还支持基于地理位置域名解析，加快用户访问速度。
  • 缺点是 dns 控制权在域名服务商哪里，修改dns A 记录，使其生效需要较长时间，容易解析到已经下线服务器上
  • 常见是域名解析作为第一级负载均衡手段。解析地址也是内部负载均衡服务器地址。
• 反向代理负载均衡
• IP 负载均衡
• 数据链路层负载均衡
  • 在linux 平台最好的链路层负载均衡开源产品为LVS(Linux Virtual Server)
  • 负载均衡服务器ip地址，与集群服务器的虚拟ip相同，通过通信协议数据链路层修改mac地址进行负载均衡（这种传输方式也叫三角传输方式
  • 这种方式大型网站使用最广的一种负载均衡手段

负载均衡算法

• 轮询
• 加权轮询
• 随机（加权随机）
• 最少连接
• 源地址散列

分布式缓存集群伸缩性设计

• 目的： 必须让新加入的缓存服务器对整个分布式缓存集群影响最小
• 通过一致性hash 环的数据结构实现key到服务器hash 映射，一致性hash 使用二叉树实现
• 增加虚拟层，实现缓存负载均衡，将每台物理缓存服务器虚拟为一组虚拟缓存服务器，然后映射到hash环上。（实践中一般服务器虚拟为150个节点。

数据库存储服务器集群伸缩性设计

• 数据存储服务器必须保证数据可靠存储，任何情况下都必须保证数据的可用性和正确性
• 关系数据库集群伸缩性设计
  • 读写分离
  • 业务分割进行分库
  • 比较成熟支持数据库分片开源产品 Amoeba、Cobar
  • Cobar伸缩有两种：Cobar服务器集群伸缩和Mysql 集群伸缩
  • Cobar利用mysql 数据同步功能进行数据迁移，迁移单位为schema，迁移完修改Cobar服务器路由配置，将这些schema的IP修改为新机器ip，然后删除原机器中的相关schema，完成mysql 扩容。
• nosql数据库伸缩性设计
  • 应用最广泛nosql 为apache Hbase，他伸缩性依靠可分裂的HRegion及可伸缩的分布式文件系统HDFS 实现。

7. 随需应变：网站的可扩展架构

扩展性： 指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。

构建可扩展的网络架构

• 开发低耦合系统是软件设计的终极目标之一
• 设计网站可扩展架构的核心思想是模块化，并在此基础上，降低模块间耦合性，提高模块复用性
• 分层和分割是模块化设计的重要手段
• 模块化分布式部署以后聚合方式主要有分布式消息队列和分布式服务。
  • 分布式消息队列
  • 分布式服务
    • 横向拆分：将复用的业务拆分出来，独立部署为分布式服务
    • 纵向拆分：按照业务独立，设计部署为独立的应用系统
    • 分布式服务具有如下特性
      • 负载均衡
      • 失效转移
      • 高效远程通信
      • 整合异构资源
      • 对应用最少侵入
      • 版本管理
      • 实时监控
    • 国内实施最常见的分布式框架为Dubbo

8. 固若金汤：网站的安全架构

常见攻击手段

• XSS 攻击： 跨站点脚本攻击，黑客篡改网页，注入恶意html脚本，用户在浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式
  • 主要攻击类型：
    • 反射型：攻击者诱使用户点击一个嵌入恶意脚本的链接，达到攻击目的
    • 持久型：攻击者提交含有恶意脚本的请求，保存在被攻击web站点数据库中，用户浏览网页时，恶意脚本被包含正常页面中，达到攻击目的
  • 处理手段
    • 消毒：对某些html危险字符转义，比如>转义为&gt
    • httponly： 禁止js访问cookie
• 注入攻击
  • 常见攻击方式
    • SQL 注入： 攻击者在http请求中注入恶意sql命令，服务器请求sql命令时候，恶意sql被构造并执行。
      • 可以进行消毒
      • 参数绑定，使用开源IBatis、Hibernate等框架，处理sql命令，攻击者sql命令，仅仅成为sql参数，而不是命令直接执行
    • OS 注入： 注入os命令被程序执行
• CSRF攻击： 跨站点请求伪造（cross site request forgery),攻击者通过跨站请求，以合合法身份进行非法操作。
  • 其核心就是利用浏览器cookie或者session策略，盗取用户身份。
  • 解决方法：
    • token
    • 验证码
    • referer check
• 其他被利用的漏洞
  • 错误页面、错误信息过于详细
  • http 注释
  • 文件上传没有设置白名单，上传文件类型控制
  • 可以路径遍历系统未开放的目录和文件

安全措施

• web 应用防火墙，常见modsecurity
• 网站安全漏洞扫描
• 信息加密和密钥安全管理

信息加密技术

• 单项散列加密
  • 单项散列加密不同输入长度信息，得出固定长度输出
  • 不可对输出进行计算从而获取输入内容
  • 由于人设置密码具有一定模式，可以使用彩虹表等手段进行猜测式破解
  • 可以加盐，增加破解难度。
  • 输入细微变化会导致输出完全不同
  • 常见单项散列算法有md5、sha等
• 对称加密
  • 加密与解密使用相同密钥
  • 算法简单，加解密效率高，系统开销小，适合大量数据加密
  • 常见算法有des、rc等
• 非对称加密
  • 使用一组密钥
  • 公钥加密的信息只有私钥解开，反之私钥加密的信息只有公钥才能解开
  • 理论上不可能通过公钥计算获得私钥
  • 常见算法为RSA

信息过滤及反垃圾手段

• 文本匹配
  • 正则：效率低，适合提交文本长度短。
  • Trie算法：
  • 多级hash表进行文本匹配，及过滤树
• 分类算法
  • 根据不同单词在垃圾邮件的概率，通过大量算法训练，得到可识别模型
• 黑名单
  • hash 表： 适合黑名单比较小
  • 布隆过滤器：

风控技术

机器识别出高风险交易和信息发送给风控人员进行人工审核。

• 规则引擎：
  • 设置规则，当交易满足指标一定条件，就认为是高风险交易
  • 业务规则和规则处理逻辑分离，运营人员通过编辑规则，无需更改代码，更新风控规则，实现风控
• 统计模型
  • 规则引擎简单，但是规则增多，会逐步出现规则冲突及难以维护状态
  • 使用分类算法或者机器学习算法进行智能统计
  • 通过充分训练的统计模型，准确率不低于规则引擎

第三篇 案例

9. 淘宝架构演化案例分析

10. 维基百科高性能架构设计分析

• wikipedia 架构组成
  • geodns: 可以解析到离用户最近的服务器
  • LVS
  • squid: 基于linux 反向代理
  • Lighttpd: 较apache服务器更轻量、更快速
  • PHP
  • Memcached
  • Lucene: java开发的开源全文搜索引擎
  • Mysql
• wikipedia 前端性能优化
  • DNS 服务： 基于地址位置解析最近服务器
  • CDN 服务： 热点词条缓存在CDN服务器，且离用户浏览器最近的地方。
  • 反向代理LVS
  • 反向代理Squid 集群:通过LVS 负载均衡分发到每台Squid 服务器。并缓存热点数据，减轻服务器压力，词条信息更新，应用服务器使用invalidation Notification 服务通知squid 缓存失效
• 服务端性能优化
  • 使用缓存，将热点数据缓存在分布式缓存系统中
  • Mysql 优化
    • 使用较大的内存的服务器
    • 使用RAID0磁盘阵列以加速磁盘访问
    • 将数据库事务一致性设置在较低水平，加速宕机恢复速度
    • Master宕机，立即将应用切到salve数据库，同时关闭写服务，关闭词条编辑功能。

11. 海量分布式存储系统Doris 高可用架构设计分析

不同故障情况下高可用解决方案

• 分布式存储系统故障分类
  • 瞬时故障： 网络通信瞬时中断、线程过多停止访问数据库
    • 增加重试机制
    • 增加机器仲裁（数据库抢占）
  • 临时故障： 交换机宕机、网卡松动等、系统升级、停机维护等、内存损坏、cpu过热等
    • 发生故障，需要将数据写入临时存储机器，恢复后迁移数据
  • 永久故障： 硬盘损坏、数据丢失等
    • 从其他服务器复制全部数据

12. 网购秒杀系统架构设计案例分析

秒杀挑战

• 对现有的网站业务造成冲击
• 高并发下应用、数据库负载
• 突然增加的网络及服务器带宽
• 直接下单

秒杀应对策略

• 秒杀系统单独部署，可以采用单独域名，完全隔离正常业务
• 秒杀页面静态化
• 租借秒杀活动网络带宽
  • 可升级或购买带宽
  • 可缓存CDN上，减轻服务器压力
  • 新增CDN出口带宽
• 动态生成随机下单页面URL
  • 秒杀下单URL 动态化，秒杀开始才生成，才让前端访问获取。

秒杀系统设计

• 如何控制秒杀商品页面购买按钮点亮
  • 增加js脚本控制，秒杀开始生成新的js,控制按钮点亮
• 如何只允许第一个提交订单发送到订单系统
  • 可以控制让少数用户进入下单页面入口，其他用户直接进入秒杀结束页面
  • 秒杀故障，不提故障，直接显示秒杀活动结束

13. 大型网站故障案例分析

故障实例分析

• 日志等级设置过低，记录大量日志，消耗磁盘空间，从而导致磁盘不足
  • 设置好日志输出级别
  • 应用输出日志与第三方组件日志需要分别配置
  • 有些开源组件输出太多不恰当的error 日志，需要关掉
• 首页系统直接查询数据库，发布后用户量过大，数据库load 居高不下
  • 首页系统不应直接访问数据，可以从缓存服务器或者搜索引擎数据库
  • 首页最好是静态
• 耗时过程被加锁，导致进程被等待
• 发布系统忽视对缓存系统压力，导致系统崩溃
• 系统为apache+Jboss模式，apache启动好，接入用户请求，但是jboss 还未启动好，大量请求导致jboss 崩溃
  • 内部系统完整启动准备好，才能接入用户请求
• 少数用户上传大文件，占用大量服务器资源，导致其他用户不能使用，
  • 限制用户上传文件大小、文件类型
  • 不同大小文件使用不同存储系统
• 进行生产环境压力测试，导致系统变慢
  • 访问生产环境需要规范
  • 进行生产环境压力、性能测试，必须商量好时间，尽量不影响用户
• 上线系统遗留调试代码
  • 规范codeview

第四篇 架构师

14. 架构师领导艺术

架构师功能

• 技术工作
  • 架构设计
  • 软件开发
• 管理功能
  • 规划产品路线
  • 估算人力资源和时间资源
  • 安排人员职责分工
  • 计划里程碑点
  • 指导工程师工作
  • 过程评估与控制
• 沟通工作
  • 项目组外工作角色沟通协调

架构师要求

• 关注人而不是产品
  • 寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。
• 发掘人的优秀
  • 让做成一件事，让自己和参与的人变得优秀
• 共享美好蓝图
  • 架构师要和项目组全体人员共同描绘一个蓝图，这个蓝图是整个团队能够认同的，是团队共同奋斗的目标
  • 蓝图是表达清楚、形象、简单的
  • 项目过程中，保持对目标蓝图的关注，对偏离蓝图保持警惕
• 共同参与架构
  • 让项目组充分参与架构设计中，不要只有架构师一个人拥有架构
  • 让其他人维护框架和架构文档
• 学会妥协
  • 对技术细节争论应该立即验证而不是继续讨论
• 成就他人
  • 通过工作的挑战，发掘自我的潜能，重新认识自我和世界

架构师职场功能

• 发现问题，寻求突破
• 提出问题，寻求支持
  • 提出问题tip
    • 把我的问题，表述成我们的问题
    • 给上司提封闭式问题，给下属提开放式问题
    • 指出问题而不是批评人
    • 用赞同的方式提出问题
• 解决问题，达成绩效

第五篇 附录

15. 大型网站架构技术一览

• 前端架构
  • 浏览器优化技术
    • 常见有页面缓存、合并请求、使用页面压缩
  • CDN
  • 动静分离，静态资源独立部署
  • 图片服务
  • 反向代理
  • DNS
• 应用层架构
  • 开发框架
  • 页面渲染
  • 负载均衡
  • Session管理
  • 动态页面静态化
  • 业务拆分
  • 虚拟化服务器
• 服务层架构
  • 分布式消息
  • 分布式服务
  • 分布式缓存
  • 分布式配置
• 存储层架构
  • 分布式文件
  • 关系数据库
  • NoSQL数据库
  • 数据同步
• 后台架构
  • 搜索引擎
  • 数据仓库
  • 推荐系统
• 数据采集与监控
  • 浏览器数据采集
  • 服务器业务数据采集
  • 服务器性能数据采集
  • 系统监控
  • 系统报警
• 安全架构
  • web 攻击
  • 数据保护
• 数据中心机房架构
  • 机房架构
  • 机柜架构
  • 服务器架构