读-李智慧-大型网站技术架构：核心原理与案例分析

先写了大型网站的架构演化路线，给出相关的架构模式，提出从几个方面关注架构的要素，后面给出了一些案例。这本书的名字，我觉得改成架构最佳实践可能更为合适一点。
之前读过这本书，当时没带着自己的想法，走马观花，没有体会到这本书的妙处。这次带着问题，结合所经历的已有系统的架构模式，与书中所写相互印证，获益良多。
总之，这本书时一本好书，可以买本实体书。

网站构架演进

大型网站的特点

1. 高并发、大流量；
2. 高可用；
3. 海量数据；
4. 用户分布广泛、网络情况复杂；
5. 安全环境恶劣；
6. 需求快速变更，发布频繁；
7. 渐进式发展：大型网站的发展是从小网站发展而来。

今年看双11晚会，外行看明星，内行看门道，想想一过12点的流量，能抗住这冲击，保证大部分人都能正常下单购物，就感觉ztm牛。再想想之前搞的抽奖活动，就那么点人，怎么就不能分点流量给我们了。

架构演化历程

• 初始阶段
  

• 应用和数据服务器分离
  

这一步主要还是把数据库服务器独立出去。

• 使用缓存
  

本地缓存和分布式缓存，这一步主要还是使用本地缓存的多点，一般不会一下子就用到分布式缓存，当然有些系统会直接使用分布式缓存。将一些配置信息、热点数据缓存本地，降低数据库压力。

引申：缓存穿透、雪崩，缓存失效，一致性hash。

• 集群
  

使用负载均衡通过集群减轻应用服务器的访问压力。

引申：会话管理。需要关注session是统一管理还是分配到集群中的某台机器。如果是某台那就可能有会话粘滞，如果随机一台，就可能需要需要会话统一管理。

• 数据库读写分离
  

这一步应该细分下为主备-分离，我们现在的系统就是也只是主从备份，没做分离。现在的系统开发，上面这几步都会一步到位，不会慢慢来了。

引申：分离后数据的一致性。

• cdn和反向代理
  
  做这一步主要还是把一些请求资源如图片和js往客户端推。缓解后端压力的同时，加速客户端响应。

• 使用分布式文件系统和分布式数据库系统
  
  感觉使用分布式文件系统主要是处理一些小文件存储。数据库数据量大了后一般都会对业务分库，服务器独立部署，各业务库再独立演化拆分分库分表等。

引申：数据库分布式后，就需要统一的数据访问组件隔离底层，其实在数据库主从后就需要，只是到这一步后需求更迫切。

• 使用nosql和搜索引擎
  
  搜索功能对于互联网系统尤其电商业务重要性不言而喻。使用nosql做离线分析和日志等，我们之前是利用hbase做订单的二次营销。

• 业务拆分
  
  不同的业务，不同产品线，然后应用的独立部署。
  从系统的新建到后期的数据库的读写分离等过程，业务的拆分应该是一直都存在的，只不过到一定时期后，这个需求更加迫切而已。

引申：系统间，走消息还是rpc等。

• 分布式服务
  
  将一些基础性的业务操作，提取出来独立部署，供其他业务系统调用。

引申：分布式调用。

价值观

• 业务发展驱动了架构技术的发展

业务驱动了架构技术的发展，而不是技术驱动业务。

架构模式

分层

逻辑分层，物理上可以集中部署也可以分布式。禁止跨层条用和反向调用。
1. 应用层；
2. 服务层；
3. 数据层。

分割

业务切分。

分布式

分层分割是为了更好的分布式。常用的分布式方案：
1. 分布式应用和服务；
2. 分布式静态资源：js、css、图片等资源独立分布式部署，独立域名，动静分离；
3. 分布式数据和存储；
4. 分布式计算；
5. 分布式配置，分布式锁，分布式文件等。

集群

1. 减轻负载压力；
2. 冗余。

缓存

1. cdn；
2. 反向代理；
3. 本地缓存；
4. 分布式缓存。

异步

分层、分割、分布式后的不同产品线和应用间的交互，有些业务可以铜鼓异步消息交互，走消息队列异步处理。

冗余

数据和应用的冗余。灾备、同城双活，异地多活。

自动化

自动化代码管理，自动化测试，自动化部署、监控等等吧。

安全

这个范围太大了，风控、权限、网络攻击等。

性能

性能测试

• 性能测试时优化的基础，对于不同人员来说，关注的视角不一样

  1. 用户来说，更多的是关注响应延迟;
  2. 开发人员来说，吞吐量，并发，响应延迟；
  3. 运维，基础资源的利用率，网络带宽等。

• 测试指标

  1. 响应时间；
  2. 并发数；
  3. 吞吐量：tqs、qps；
  4. 性能计数器：描述服务器或操作系统性能的一些数据。

• 测试方法

  1. 性能测试；
  2. 负载测试；
  3. 压力测试；
  4. 稳定性测试。

web前端性能优化

• 浏览器访问优化

  1. 减少http请求：并发请求数有限，所以可以讲图片独立域名部署，一些js压缩合并；
  2. 浏览器缓存：对一些静态资源合理设置缓存时间；
  3. 启用压缩：这个没做过，感觉对文本文件效果会很好；
  4. css放在最上面，js放在最下面；
  5. 减少cookie传输。

• cdn加速
  

• 反向代理

跟正常代理的区别：正常的是帮你跳出去，反向是帮你跳进来。也可以用来缓存静态资源和热点数据。

应用服务器性能优化

• 分布式缓存

优先使用缓存优化性能。合理使用缓存：
1. 频繁修改的数据：2:1；
2. 没有热点的数据；
3. 数据不一致与脏读；
4. 缓存可用性；
5. 缓存的预热：LRU，最近最少使用；
6. 缓存预热；
7. 缓存穿透：将不存在数据也缓存起来；

缓存架构：
1. JBoss Cache的分布式缓存在集群中所有服务器保存相同的缓存；
2. Memcached：缓存集群间不相互通讯，现在比较流行这种。我们用的是redis。

• 异步操作

感觉异步操作需要业务的妥协，而且也不是所有业务都适合异步操作。当然有些数据分发或者发个短信、邮件什么的利用消息队列使用异步操作没什么问题。

使用原则就是，任何可以晚点做的事情都应该晚点再做。

• 集群

• 代码优化

必须了解jvm。
1. 多线程：感觉能不用就最好不用，用不好都不知道怎么死的，有次用了线程池pc模式处理数据，20W数据最后老是丢几十条，查了好久，才发现，线程不同步，有的线程没有正确关闭；
2. 资源的复用；
3. 垃圾回收；

存储性能优化

• 机械硬盘 vs 固态硬盘

• B+树 vs LSM树

• RAID vs HDFS

可用性

可用性度量和考核

• 可用性度量

最经常听说的4个9，3个9。
网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
网站年度可用性指标=（1-网站不可用时间/年度总时间）* 100%

• 考核

故障定级和故障分。

高可用的应用

• 通过负载均衡进行无状态服务的失效转移

• 应用服务器集群的session管理

  1. session复制；
  2. session绑定：hash，整个会话期间，由同一台服务器处理业务，会产生会话黏滞；
  3. cookie记录session；
  4. session服务器；
     

将应用服务器的状态分离，分为有状态的session服务器和无状态的应用服务器。

高可用的服务

主要是RPC的服务治理的东西，如果用过RPC的东东，应该都有所了解。

1. 分级管理：主要是针对不同服务分级，不同优先级不同线程池运行，分级主要是为了大促时做降级，隔离服务；
2. 超时管理；
3. 异步调用：调用方式支持同步、异步、回调；
4. 幂等性设计。

高可用的数据

1. CAP原理：传统关系数据库CP，牺牲A，现在互联网应用大都为AP，牺牲部分C，利用其它补偿做到数据最终一致；
   

2. 数据备份：热备，同步，异步热备；

3. 失效转移：流程：失效确认-转移-数据恢复。

高可用的软件质量保证

1. 网站发布：分批次；
2. 自动化测试；
3. 预发布验证：准生产环境验证；
4. 代码控制：主要是代码版本控制；
5. 自动化发布；
6. 灰度发布：部分发布，AB测试。

网站运行监控

1. 监控数据采集：用户日志、服务器性能、运行数据报告；
2. 监控管理：报警，转移，服务降级等；

伸缩性

网站伸缩性是指不需要改变网站的软硬件的设计，仅仅通过部署服务器的数量改变来改变处理能力。想想大促前的机器扩容。

网站架构的伸缩性设计

• 不同功能物理分离实现伸缩：主要是分层、分割后的业务和模块独立部署

  1. 纵向分离，将业务处理上的不同部分分离部署；
  2. 横向分离，将不同的业务模块分离部署。

• 单一功能通过集群实现伸缩：将单一服务集群部署提供服务

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

主要是通过负载均衡实现集群的伸缩。

负载均衡技术：

• http重定向
  

• DNS解析
  

• 反向代理
  

• IP负载
  

• 数据链路层负载
  

• 负载均衡算法：

  1. 轮询；
  2. 加权轮询；
  3. 随机；
  4. 最近最少连接；
  5. hash。

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

搜索了解下分布式hash算法，的确开阔眼界。

数据存储服务器集群的伸缩性

• 传统数据库集群：搜索mysql的集群方案，常用的2种方式：

  1. client维护分片信息；
  2. proxy维护信息，client直跟proxy联系；
     

• nosql，天生支持。

扩展性

网站架构的扩展性是指扩展系统功能时，对现有系统影响最小，主要还是降低系统应用间的耦合。通过2种方式：分布式消息队列降低耦合、可复用的分布式服务。

分布式消息队列：mq

感觉mq还是处理非实时业务或者分布数据，其他的实时的调用还是算了吧。

分布式服务：rpc

分布式框架dubbo的架构原理：

安全性

网站应用的攻击与防御

• xss脚本攻击：特殊字符转义

• sql注入：sql参数绑定

• csfr跨站请求伪造：关键环节2次验证

• 其他攻击：

  1. 错误回显：配置常用errorCode如404,500等错误页面；
  2. html注释：外网系统不注释；
  3. 文件上传：文件类型等校验；
  4. 路径遍历：资源文件单独部署；

• web应用防火墙；

• 安全扫描：有一些工具和平台可以做漏洞扫描，最好不要对生产做一些数据清除修改的操作。有次公司的url扫描就改了用户数据，坑爹。

加密

• 单向散列加密：md5，sha；

• 对称加密：加解密同一个秘钥，des；

• 非对称加密：公私钥（私钥加密，公钥解密），RSA；

• 秘钥管理：作者写的2种方式，没见过，感觉很少这么做，我们公司是申请服务器资源的时候，秘钥同时下发，然后定期更新密码。

  1. 秘钥和算法独立部署服务器，申请和使用时校验；
  2. 加解密算法放在应用中，秘钥独立服务器中，秘钥切片存放。

信息过滤与反垃圾

• 文本匹配：敏感词过滤，trie算法；

• 分类算法：以反垃圾邮件为例：
  

• 黑名单：布隆过滤器；

风控

前2天刚听的风控讲座，很多内容，例如风险就可以发分为欺诈、商户、法规、结算风险等，可以单独搜索学习。主要是利用规则引擎和统计模型训练。在业务流程中将风控前置，在后期可以利用统计模型，机器学习算法等进行风险预测。

推荐吴军博士的《数学之美》这本书，介绍了好多分类、搜索方面统计模型类应用。

后面还有2部分内容

1. 一部分讲了几个案例，对前面架构部分做了具体的阐述，有些宽泛，案例部分，还是改天重看淘宝技术10年的时候再好好学习把；
2. 另一部分讲了架构师的划分，以及作者对架构师这一工作的理解，不是架构师，虽有体会，但不深。

总结

1. 业务需要推动了架构技术的演化，一个日活10来个人的网站，有必要上 一个高大全的分布式的系统嘛？非要上一个，完全自寻死路，没那需求，也没那必要；
2. 传道受业解惑，这本书属于架构传道类吧。很多公司死在了通往大型网站的路上，作者写出这本书分享自己的经历，让我们能够了解学习大型网站演化过程中的架构演进，获益良多；
3. 从性能、可用、伸缩、扩展性和安全性几个方面考虑网站架构并给出了优化方案，但是因为是传道类的书籍，所以广度够了，深度不够，如果能各点都给出一个够深度的难点，可能会更好；
4. 看这本书，一定要带着问题，结合自身的经历去思考，如果是自己应该怎么办，这样才能学有所获，之前第一次读的时候没有注意，白白浪费了一次机会，幸好这次有时间重读一次。