博客

第1篇

大型网站架构演化

大型网站架构技术的核心价值是随网站所需灵活应对

驱动大型网站技术发展的的主要力量是网站的业务发展

网站架构设计误区

• 一味追随大公司的解决方案，一句话“淘宝就是这样做的”…
• 为了技术而技术，网站架构是因业务而存在，除此之外毫无意义。技术选型和架构设计中，
  
脱离网站业务发展的实际，一味追求时髦新技术

  ，可能会将网站技术发展引入崎岖小道，架构之路越走越难。
• 企图用技术解决所有问题，业务的问题，也可以考虑用业务手段去解决

大型网站架构模式

网站架构模式

• 分层（横向）
• 分割（纵向）
• 分布式
  • 分布式应用和服务
  • 分布式静态资源
  • 分布式数据和存储
  • 分布式计算（map-reduce等）
• 集群
• 缓存
  • CDN
  • 本地缓存
  • 分布式缓存
• 异步
• 冗余
• 自动化
• 安全

大型网站核心架构要素

• 性能
  
  衡量网站性能有一系列指标，重要的如：响应时间、TPS、性能计数器等
• 可用性
  
  包括：部分服务器宕机是否可用；开发、发布过程的高可用（通过
  
预发布验证

  、自动化测试、自动化发布、
  
灰度发布

  等手段，减少bug流入线上的可能性，避免故障范围扩大）
• 伸缩性
  
  主要标准：是否可以用多台服务器构建集群，是否容易向集群中添加服务器。
• 扩展性
  
  主要标准：网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不同产品之间是否耦合，其他产品的功能不受牵连被迫进行改动
• 安全性

第2篇 架构

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

1 网站性能测试

性能测试指标

• 响应时间
  
  主要是平均响应时间，请求总响应时间/请求总次数

• 并发数
  
  指系统能够同时
  
正常

  处理请求的数目。
  
  推算在线用户数和各功能场景的并发用户数很重要，这些指标将成为系统非功能设计的重要依据。
  
  测试并发请求可以增加随机等待时间，称为思考时间。

• 吞吐量
  
  指单位时间内系统处理请求的数量，体现系统的整体处理能力。
  
  如：“请求数/秒”、“访问人数/天”、“TPS（每秒事务数）”、“HPS（每秒HTTP请求数）”、“QPS（每秒查询数）”

2 应用服务器性能优化

分布式缓存

网站性能优化第一定律：优先考虑使用缓存。

• 基本原理
  
  将热数据存储在
  
相对

  较高访问速度的存储介质中，以供系统使用。
  
  一方面访问速度快，另一方面，节省数据计算时间，不用每次查询都计算一次。
• 合理使用缓存
  
  缓存带来的好处很多，但不合理使用造成的问题可能会更大。
  
  1）频繁修改的数据勿用缓存
  
  读写比至少大于2，否则缓存没有意义，只会徒增服务器压力
  
  2）非热数据勿缓存
  
  缓存数据要遵循“二八原则”，缓存空间有限，需要合理利用；防止无价值数据排挤掉有价值的数据
  
  3）数据不一致与脏读
  
  开发时要考虑业务场景，是否能接受数据“最终一致”
  
  4）
  
  缓存可用性
  
  
  现实中，很可能大量应用缓存，
  
  数据库相关服务已经“习惯”了有缓存顶在前面的日子，当缓存服务奔溃时，数据库可能因不能承受如此大的请求压力而宕机。
  
  这种情况称为
  
缓存雪崩

  ，发生这种故障时，甚至不能简单重启缓存和业务服务器恢复网站访问。
  
  实践中，有的网站利用缓存双写热备等手段来提高缓存服务的可用性，但这种解决方案显然有违缓存的设计初衷（特性），
  
  缓存根本不应该当做一种可靠的数据源来使用。
  
  
  通过分布式缓存服务器集群，将缓存数据分布到集群中多台服务器上，一定程度上改善了缓存的可用性。当其中一个节点宕机时，只有部分缓存数据丢失，重新计算、加载这部分数据并不会对数据库造成”雪崩”的影响。
  
  5）缓存预热
  
  热点数据
  
warm up

  
  6）缓存穿透
  
  如果因不恰当的业务代码、或恶意攻击持续高并发的请求某个不存在的数据，由于缓存中没有保存该数据，所有请求都落到数据库上，会对数据库造成较大压力，甚至崩溃。简单的应对策略是，将这种“无效数据”也存入缓存。（这里更多可能性是业务方面的问题）

异步操作