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

1 大型网站架构演化

1.1 大型网站软件系统的特点

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

1.2 大型网站架构演化发展历程

• 1：初始阶段的网络架构：应用程序、数据库、文件等所有资源在一台服务器；
• 2：应用服务和数据服务分离：CPU,磁盘； -> 数据库压力大访问延迟
• 3：使用缓存改善网站性能：二八定律：80%的业务访问集中在20%数据上；
• 4：使用应用服务器集群改善网站的并发处理能力：负载均衡服务器
• 5：数据库读写分离：主备、主从复制
• 6：反向代理和CDN加速网站的响应：缓存，CDN部署在网络提供商，反向代理部署在网站的中心机房；
• 7：分布式文件系统和分布式数据库系统；
• 8：使用nosql和搜索引擎；
• 9：业务拆分；
• 10：分布式服务；公用服务提取出来；

1.3 大型网站架构演化的价值观

• 核心价值不是从无到有搭建一个大型网站，而是能够伴随小型网站业务的逐步发展、慢慢演化成一个大型网站；
• 业务成就了技术、事业成就了人；

1.4 误区

• 一味追求大公司的解决方案
• 为了技术而技术
• 企图用技术解决所有问题；

2 大型网站架构模式

2.1 分层

• 横向维度的切分，上层对下层的依赖；
• 应用层（视图层、业务逻辑层）、服务层（数据接口层、逻辑处理层）、数据层；
• 挑战：严格遵循分层架构的约束，禁止跨层调用、逆向调用

2.2 分割

• 分割是纵向的切分
• 功能模块，高内聚低耦合，有助于软件的开发和维护，提高并发处理能力和扩展能力；

2.3 分布式

• 分层和分割目的为了切分后的模块便于分布式部署，不同模块远程调用协同工作；
• 分布式意味着，更多的计算机完成同样的功能，计算机多，CPU、内存、存储资源更多；
• 弊端：1 网络影响性能 2 服务器多，宕机的概率大，可用性降低 3 数据一致性；
• 常用方案：分布式应用和服务； 分布式静态资源； 分布式数据和存储； 分布式计算；

2.4 集群

• 独立部署的服务集群化，负载均衡设备堆外提供服务；

2.5 缓存

• CDN
• 反向代理
• 本地缓存
• 分布式缓存

2.6 异步

• 降低软件的耦合性，异步架构师典型的生产者消费者模式
• 消息传递；
• 提供系统可用性；消息堆积；
• 加快网站的响应速度
• 消除并发访问高峰；

2.7 冗余

• 服务器冗余
• 数据冗余，冷备份，热备份
• 容灾数据中心

2.8 自动化

• 发布过程自动化、自动化代码管理、自动化测试、自动化安全检测、自动化部署；
• 自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化分配资源

2.9 安全

• 密码和手机校验码、各种加密；

3 大型网站核心架构要素

• 架构：最高层次的规划，难以改变的决定；
• 有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计；
• 性能、可用性、伸缩性、扩展性、安全性

3.1 性能

• 衡量：响应时间、TPS、系统性能计数器等
• 性能符合仅仅是必要条件；
• 前端：
  • 浏览器缓存、也没压缩、减少cookie传输
  • CDN、反向代理
• 应用服务器：
  • 本地缓存和分布式缓存；
  • 异步操作发送至消息队列；
• 代码
  • 多线程
  • 改善内存管理等；
• 数据库服务端
  • 索引、缓存、sql优化；

3.2 可用性

• 目标：当服务器宕机后，服务或者应用依然可用；
• 衡量：假设系统一台多台机器宕机、系统是否整体依然可用；
• 冗余
  • 应用服务器部署在多台服务器； 负载均衡
  • 数据存储在多台服务器互相备份； 实时备份
  • 软件开发过程的质量保证： 预发布验证、自动化测试、发布、灰度；

3.3 伸缩性

• 通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求；
• 衡量：是否可用多台服务器构建集群，添加新服务器，是否无差别服务；
• 应用服务器集群，服务器不保存数据、无状态的，负责均衡设备即可添加机器；
• 缓存服务器集群，缓存路由算法，新增加服务器保证缓存数据的可访问性；
• 关系数据库：数据复制，主从热备，路由分区等；

3.4 可扩展性；

• 目标: 架构使其能够快速响应需求变化；
• 衡量：新增业务，对现有产品是否透明无影响，耦合度低；
• 事件驱动架构和分布式服务
  • 消息队列；
  • rpc调用，业务和可复用服务分离；

3.5 安全性

• 对现有的各种攻击和手段，是否有可靠的应对策略；

4 瞬时响应：网站的高性能

4.1 网站的性能测试

• 不同视角的网站性能: 用户视角（前端优化）、开发视角（缓存，集群，异步）、运维视角（优化骨干网，高性价比定制服务器，虚拟化优化资源利用率）
• 性能优化指标： 响应时间、并发数、吞吐量、性能计数器；
  • TPS 秒事务数，QPS 秒查询数， HPS 秒HTTP请求数；
  • 吞吐量、并发数、rt：通过高速的车辆总数，高速正在行驶的数，车速；-> （并发车少，RT快，吞吐量少，反之）
  • 性能计数器：负载，线程数，内存使用，cpu使用，磁盘等；
  • 系统负载：当前正在被CPU执行和等待被CPU执行的进程数目总和，反应系统闲忙程度；Load理想数据是CPU的数目，最近1、5、15分钟运行平均数；
• 性能测试方法： 性能测试-> 负载测试 -> 压力测试 -> 稳定性测试

4.2 web前端性能优化

• 浏览器访问优化
  • 减少http请求数：合并CSS，合并javasript，合并图片
  • 使用浏览器缓存：静态资源
  • 启用压缩：文件
  • CSS放在也没最上面，javascript放在最下面；
  • 减少Cookie传输
• CDN加速
  • 内容分发网络；静态资源；
• 反向代理
  • 配置缓存加速web请求
  • 负载均衡

4.3 应用服务器性能优化

• 分布式缓存

  • 缓存速度快； 经过计算处理的；hash表k-v对
  • 合理使用缓存：
    • 频繁修改的数据；
    • 没有热点的访问；
    • 数据不一致与脏读；
    • 缓存可用性；（雪崩）
    • 缓存预热；LRU最近最久未使用；
    • 缓存穿透；不存在的数据也缓存；
  • 架构
    • JBoss Cache需要更新同步的分布式缓存；
    • Memcached未代码的不互相通信的分布式缓存；

• 异步操作

  • 消息队列很好的削峰作用
  • 任何可以晚点做到事情都应该晚点再做；

• 使用集群

  • 负载均衡技术

• 代码优化

  • 多线程： IO阻塞和多CPU；
  • 线程安全问题：
    • 将对象设计为无状态对象；
    • 局部对象；
    • 并发访问资源时加锁；
  • 资源复用：
    • 单例和对象池：复用对象实例，减少对象创建和资源损耗； 线程池
  • 数据结构
    • 程序就是数据结构加算法；
  • 垃圾回收
    • 堆（对象的内存空间）和堆栈（线程上下文信息，方法参数，局部变量）；
    • 年轻代（Eden区，from区，to区），老年代；
    • 1 对象在eden区创建，eden区满，触发youngGC
    • 2 将还被使用的对象，复制到 from区；
    • 3 eden区再被用完，再触发young GC，将eden区和from区还用的对象复制to区；
    • 4 下次from区；
    • 5 多次young GC对象多次复制，达到一定阈值，对象复制到老年代，老年代空间也用完，触发Full gC, 全量回收；

4.4 存储性能优化

• 机械硬盘和固态硬盘；
• B+树和LSM树
• RAID HDFS；

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

5.1 网站可用性的度量与考核

• 网站的可用性度量：网站的不可用时间，可用性指标，2个9基本可用年度不可用小于88小时，3个9年度9小时，4个9具有自动恢复能力53分钟，5个9小于5分钟；
• 网站可用性考核：故障分，是进行分类甲醛计算故障责任的方法；故障时间*故障权重（100，20，5，1）；

5.2 高可用的网站架构

• 主要手段：数据和服务的冗余分贝及失效转移；
• 应用层：负载均衡，集群服务，心跳检测；
• 服务层：集群方式服务可用用，分布式服务调用框架负载均衡，服务注册中心对外提供服务；
• 数据层：数据同步复制，冗余备份；

5.3 高可用的应用

• 无状态的应用：应用服务不保存业务的上下文信息；
• 通过复制均衡进行无状态服务的失效转移；
• 应用服务器集群的session管理：多次请求修改使用的上下文对象成为会话session：
  • session复制：每台机器都保存，大量的通信进行复制；不适用；
  • session绑定：负载均衡设备固定的ip，session绑定在特定的服务器，会话粘滞，单机宕机，不适用；
  • cookies记录session:浏览器支持的cookies保存session，受cookie大小限制，用户关闭cookies访问不正常；
  • session服务器：独立部署的几圈统一管理，利用分布式缓存、数据库存储；

5.4 高可用的服务

• 分级管理：核心应用和服务优先使用更好的硬件；服务进行必要的隔离；
• 超时设置：服务器宕机、死锁，失去响应，超时设置后，异常，可通过重试或转移到其他服务器；
• 异步调用：消息队列
• 服务降级：
  • 拒绝服务：拒绝低优先应用，减少服务调用次数，限流或者随机拒绝请求的策略；
  • 关闭服务；关闭不重要的服务，减少系统开销。提前禁写；
• 幂等性设计：服务幂等性；

5.5 高可用的数据

• 数据备份和实效转移，缓存的高可用
• CAP原理：
  • 数据持久性、可访问性、一致性；系统只能满足其中2个条件；
  • 数据强一致性（物理存储一致）、数据用户一致性（物理不一致、用户访问一致）、数据最终一致性（系统经过一段时间自我修复和修正最终达到一致）
• 数据备份：
  • 冷备：定期同步到存储设备，不能保证数据最终一致性
  • 热备：同步、异步
• 失效转移：
  • 失效确认：心跳检测、应用程序访问失败报告
  • 访问转移：
  • 数据恢复：自动扩容或置换

5.6 高可用的软件质量保证

• 网站发布：自动化发布
• 自动化测试；
• 预发布验证
• 代码控制：codereview，主干开发，分支发布； 分支开发，主干发布；
• 自动化发布：CI，提前集成，小火车发布模型，周四
• 灰度发布：

5.7 网站运行监控

• 不允许没有监控的系统上线；
• 监控数据采集
  • 用户行为日志收集
  • 服务器性能监控
  • 运行数据报告：业务相关；
• 监控管理
  • 系统报警
  • 失效转移
  • 自动优雅降级；

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

• 仅仅通过改不部署的服务器数量就可以扩大或者缩小网站的服务处理能力；

6.1 网站架构的伸缩性设计

• 纵向分离：将业务处理流程是哪个的不同部分分离部署；层级分
• 横向分离：将不同业务模块分离部署，业务分；
• 单一功能通过集群规模实现伸缩；

6.2 应用服务器集群的伸缩设计

• http 重定向复制均衡
• DNS域名解析负载均衡
• 反向代理负载均衡
• IP负载均衡：源地址转换SNAT
• 数据链路层负载均衡：通信协议的数据链路层修改mac地址进行负载均衡，三角专属模式，不修改IP，只修改mac地址； LVS，使用最广；
• 负载均衡算法
  • 轮询：
  • 加权轮询：配置了权重
  • 随机：加权随机
  • 最少链接；
  • 源地址散列

6.3 分布式缓存的伸缩性设计

• 集群部署，需要找到有缓存数据的服务器，才能访问，新加入服务器，应使已经缓存的数据尽量访问到；
• memcache分布式缓存集群的访问模型：
• 新加入缓存服务器，降低数据库的负责压力；访问量最小时候扩容，预热缓存；
• 分布式缓存的一致性hash算法：
  • 一致性hash环：构造 2^32的整数环，根据节点的hash只，放置在环上，顺时针寻找距离这个key近的服务器；二叉树查找；问题：新加入的可能之影响一台机器，其他两台的负责是现加入的2倍；
  • 计算机任何问题可以增加一个虚拟层；新加入的影响->虚拟的->散列->物理的；一台物理虚拟为150个虚拟经验值；

数据存储服务器的伸缩性设计

• 数据的持久性和可用性；
• 关系数据库
  • 分库、主从复制，避免事务或利用事务补偿机制、避免jion；
  • nosql数据库；先设计数据库设计，关系模型绑架对象模型，贫血、涨血模型；HBASE、HDFS；

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

• 扩展性：系统功能可持续扩展或提升的能力
• 伸缩性：系统能通过增加或减少自身资源规模的方式增强或减少自己计算处理事务的能力，线性伸缩性；

7.1 构建科扩展架构

• 低耦合的系统更容易扩展，低耦合的模块更容易复用；
• 软件架构师的价值不在掌握多少先进的技术，而是具有将一个大系统切分成N个低耦合的模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块，这一部源自专业的技术和经验，还有一分部源自架构师对业务场景的理解，对人性的把握，甚至对世界的认知；

7.2 分布式消息队列降低系统的耦合性

• 事件驱动架构：发送消息，不依赖；
• 分布式消息队列：

7.3 分布式服务打造可复用的业务平台

• 分布式服务降低系统耦合性；
• 大系统的危害
  • 编译部署困难
  • 代码分支管理困难
  • 数据库连接耗尽
  • 新增业务困难
• 解决方案就是拆分：纵向，大应用拆分成小应用，业务独立； 横向，复用的业务拆分，独立部署分布式服务；
• web service企业及分布式服务
  • 服务提供通过WSDL向注册中心Broker发布，注册中心用UDDI统一描述发布提供，服务请求者从注册中心检索服务，通过SOAP 简单对象访问协议通信；
• 大型分布式服务的特点
  • 负载均衡
  • 失效转移
  • 高效的远程通信
  • 整合异构系统
  • 对应用最少侵入；
  • 版本管理;
  • 实时监控；
• 分布式服务框架设计
  • SOA 面向服务的体系架构
  • Dubbo；

7.4 可扩展的数据结构

• nosql的 columnfamily列族

7.5 利用开发平台建设网站生态圈

• 开发平台： API接口，协议转换，安全，审计，路由，流程；

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

8.1 网站的应用攻击和防御

• XSS攻击

  • 跨站点脚本攻击，通过篡改网页，注入恶意HTML脚本，当用户浏览网页，控制用户恶意操作；
  • 反射性，诱使用户点击嵌入的链接；
  • 持久性，黑客提交含有恶意脚本的请求，保存在被攻击的web站点数据库中。
  • 手段： 消毒，对某写html危险字符转义； httponly：浏览器禁止页面JavaScript访问带有httponly属性的cookies。

• 注入攻击

  • SQL注入和OS注入；
  • 开源搭建，错误回显，盲注；
  • 消毒，sql过滤可能注入的sql； 参数绑定；

• CSRF攻击：跨站点请求伪造，攻击者通过跨站请求，以合法用户的身份进行非法操作；核心是利用了浏览器cookie或服务器session策略，盗取身份；

  • 防御：识别请求者身份；表单token；验证码；referer check请求来源检查；

• 其他

  • ERROR code
  • HTML 注释
  • 文件上传
  • 路径便利；

• web应用防火墙

• 网站的安全漏洞扫描

8.2 信息加密技术及秘钥管理

• 单向散列加密：单向，md5，sha
• 对称加密：加密和解密使用同一密钥；DES,RC
• 非对称加密: 公钥、密钥； 信息安全传输、数字签名； RSA
• 密钥安全管理：源码、配置文件；
  • 密钥服务器，服务加密解密；
  • 加解密算法放在应用脚骨，密钥放在独立服务器，切分成数片，保存在不同存储介质中；

8.3 信息过滤与反垃圾

• 文本匹配
  • trie树，多级hash表匹配，降噪处理；
• 分类算法
  • 贝叶斯分类算法，训练；特征值概率；
• 黑名单:布隆过滤器

电子商务风险控制

• 风险：账户、买家、卖家、交易
• 风控：规则引擎、统计模型

9-13 案例演示

• 软件设计的风格：一种是软件设计的复杂，以使其缺陷美那么明显； 二是将软件设计得很简单，以使其没有明显的缺陷；

14 架构师领导艺术

• 关注人而不是产品
  • 一群优秀的人做一件他们热爱的事，一定能取得成功；
  • 项目管理不是制定计划，组织资源，跟踪项目进展，对成员进行激励和惩罚，而是发掘项目组每个成员的优秀潜能，让大家理解并热爱软件产品最终蓝图和愿景；
  • 自我驱动，自觉合作，虚招达成目标的最优解；
• 发掘人的优秀
  • 是事情成就了人，而不是人成就了事；指望优秀的人来帮自己成事，不如做成一件事让自己和参与的人都变得优秀；
• 共享美好的蓝图
  • 蓝图应该是表达清楚的；
  • 蓝图应该是形象的；
  • 蓝图应该简单的；
  • 蓝图应该在项目首页，邮件的签名档；
  • 架构师保持对目标蓝图的关注；
• 共同参与架构
  • 不要只有架构师一个人拥有架构；
  • 然跟其他人维护架构与架构文档；
• 学会妥协
  • 不要对意见过于敏感；
  • 架构组越早被人遗忘，越成功；
• 成就他人

15 架构师职场攻略

• 发现问题，寻找突破
  • 习惯问题的存在，记录问题，主动发现；
  • 问题，体验-期望，不满足出现问题；
  • 消除问题的手段：改善体验或降低期望；
• 提出问题，寻求支持
  • 让问题的拥有者知道问题的存在；
  • 提出问题：
  • 1 把我的问题改成我们的问题
  • 2 给上司提封闭式问题，给下属提开放式问题
  • 3 指出问题而不是批评人
  • 用赞同的方式提出问题：非常赞同你的方案，不过我有一个小小的建议；
• 解决问题，达成绩效
  • 解决问题
  • 1 在解决我的问题之前，先解决你的问题；先解决别人问题的好处：礼尚往来；熟悉了情况；
  • 2 适当的逃避问题；1 我去开个会，回来再谈； 2 这个idea非常好，我们改天组织一个会议好好讨论一下；

16 架构师

• 作用划分
  • 设计系架构师，救火型_，布道型，geek~；
• 效果划分
  • 夏尔巴人~，技术难度和挑战性；
  • 斯巴达人~，必胜的信念，依赖的对象
  • 达官贵人~，傲人履历
• 职责
  • 产品_{，基础服务（平台）}，基础设施~（中间件）；
• 关注层次
  • 只关注功能；
  • 关注非功能；
  • 关注团队组织与管理；
  • 关注产品运营；
  • 关注产品未来；
• 按口碑
  • 最好的，打成一片；
  • 好的，敬重和信任；
  • 一般的，技术工作；
  • 差的，无技术实力，人际关系差；
  • 最差的，制造压力驱动努力无价值的工作；
• 非主流
  • 普通，架构师中的普通青年；
  • 文艺，一些更前瞻的思考和别出心裁的设计；
  • 1+1，喜欢设计中堆砌概念和模式，设计文档宏大不着调，面面俱到不解决问题；说起来头头是道不知如何落地，根源是不了解真正的问题或不掌握正确的方法； 做架构纯为了炫耀自己知道这么多术语；