大型网站技术架构笔记

为了解决大型网站面临的高并发访问、海量数据处理、高可靠运行等一系列问题与挑战,大型互联网公司在实践中提出了许多解决方案,以实现网站高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标。这些解决方案又被更多网站重复使用,从而逐渐形成大型网站架构模式。在地铁上的时间把这本书读完了,虽然此书是2013年出版,但是好的思想是永远不会过时,看完后,还是有很大的收获。

  • 4.1 网站性能测试:
    • TPS(每秒事务数)是吞吐量的一个常用量化指标,此外还有HPS(每秒HTTP请求数)、QPS(每秒查询数)等。
    • 排查一个网站的性能瓶颈和排查一个程序的性能瓶颈的手法基本相同:检查请求处理的各个环节的日志,分析哪个环节响应时间不合理、超过预期;然后检查监控数据,分析影响性能的主要因素是内存、磁盘、网络、还是CPU,是代码问题还是架构设计不合理,或者系统资源确实不足。
  • 4.2 Web前端性能优化:
    • 通过设置HTTP头中Cache-Control和Expires的属性,可设定浏览器缓存,缓存时间可以是数天,甚至是几个月。
  • 4.3 应用服务器性能优化:
    • 网站性能优化第一定律:优先考虑使用缓存优化性能。
    • 如果因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据,由于缓存没有保存该数据,所有的请求都会落到数据库上,会对数据库造成很大压力,甚至崩溃。一个简单的对策是将不存在的数据也缓存起来(其value值为null)。
  • 4.4 存储性能优化:
    • 数据在从内存缓冲区写入磁盘时,根据磁盘数量将数据分成N份,这些数据同时并发写入N块磁盘,使得数据整体写入速度是一块磁盘的N倍。读取时也一样,因此RAID0具有极快的数据读写速度,但是RAID0不做数据备份,N块磁盘中只要有一块损坏,数据完整性就被破坏,所有磁盘的数据都会损坏
  • 5.1 网站可用性的度量与考核:
    • 网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点网站年度可用性指标=(1-网站不可用时间/年度总时间)×100%
  • 5.5 高可用的数据:
    • 所以在大型网站中,通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),而在某种程度上放弃一致性(C)。一般说来,数据不一致通常出现在系统高并发写操作或者集群状态不稳(故障恢复、集群扩容……)的情况下,应用系统需要对分布式数据处理系统的数据不一致性有所了解并进行某种意义上的补偿和纠错,以避免出现应用系统数据不正确。
    • 判断服务器宕机是系统进行失效转移的第一步,系统确认一台服务器是否宕机的手段有两种:心跳检测和应用程序访问失败报告
  • 6.2 应用服务器集群的伸缩性设计:
    • 如果HTTP请求分发装置可以感知或者可以配置集群的服务器数量,可以及时发现集群中新上线或下线的服务器,并能向新上线的服务器分发请求,停止向已下线的服务器分发请求,那么就实现了应用服务器集群的伸缩性。
  • 6.3 分布式缓存集群的伸缩性设计:
    • 具体算法过程为:先构造一个长度为0~232的整数环(这个环被称作一致性Hash环),根据节点名称的Hash值(其分布范围同样为0~232)将缓存服务器节点放置在这个Hash环上。然后根据需要缓存的数据的KEY值计算得到其Hash值(其分布范围也同样为0~232),然后在Hash环上顺时针查找距离这个KEY的Hash值最近的缓存服务器节点,完成KEY到服务器的Hash映射查找。
  • 8.2 信息加密技术及密钥安全管理:
    • 另一种方案是将加解密算法放在应用系统中,密钥则放在独立服务器中,为了提高密钥的安全性,实际存储时,密钥被切分成数片,加密后分别保存在不同存储介质中,兼顾密钥安全性的同时又改善了性能
  • 9.2 淘宝网技术架构演化:
    • 业务快速发展,宝贵的开发资源应该投入到新业务开发上,而不是解决这些可以用付费产品搞定的基础技术问题上;成熟的付费产品和售后支持令业务和市场没有后顾之忧,可以全力以赴地拓展市场;对于一个快速发展的网站,特别是电子商务网站而言,严重宕机、重要用户数据丢失可能会极大地打击消费者信心,令网站发展平生波澜,而这些业界领先的产品经过多年的洗练,有较强的可用性保证。
  • 10.2 Wikipedia性能优化策略:
    • Wikipedia CDN缓存的几条准则为:
    • ●内容页面不包含动态信息,以免页面内容缓存很快失效或者包含过时信息。
    • ●每个内容页面有唯一的REST风格的URL,以便CDN快速查找并避免重复缓存。
    • ●在HTML响应头写入缓存控制信息,通过应用控制内容是否缓存及缓存有效期等。
  • 11.1 分布式存储系统的高可用架构:
    • 保证高可用的主要手段是冗余:服务器热备,数据多份存储
    • 一般而言,服务器之间通信越少,就越少依赖,发生故障时互相影响就越少,集群的可用性就越高。
  • 13.2 高并发访问数据库引发的故障:
    • 首页不应该访问数据库,首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。
    • 首页最好是静态的。
  • 13.4 缓存引发的故障:
    • 当缓存已经不仅仅是改善性能,而是成为网站架构不可或缺的一部分时,对缓存的管理就需要提高到和其他服务器一样的级别。
  • 13.6 大文件读写独占磁盘引发的故障:
    • 存储的使用需要根据不同文件类型和用途进行管理,图片都是小文件,应该使用专用的存储服务器,不能和大文件共用存储。批处理用的大文件可以使用其他类型的分布式文件系统。
  • 13.8 不规范的流程引发的故障:
    • ●代码提交前使用diff命令进行代码比较,确认没有提交不该提交的代码。
    • ●加强code review,代码在正式提交前必须被至少一个其他工程师做过code review,并且共同承担因代码引起的故障责任。
  • 13.9 不好的编程习惯引发的故障:
    • ●程序在处理一个输入的对象时,如果不能明确该对象是否为空,必须做空指针判断。
    • ●程序在调用其他方法时,输入的对象尽量保证不是null,必要时构造空对象(使用空对象模式)。
  • 13.10 小结:
    • 软件设计有两种风格,一种是将软件设计得很复杂,以使其缺陷没那么明显;一种是将软件设计得很简单,以使其没有明显的缺陷”。
  • 14.1 关注人而不是产品:
    • 寻找一个值得共同奋斗的目标,营造一个让大家都能最大限度发挥自我价值的工作氛围。
  • 15.2 提出问题,寻求支持:
    • 给上司提封闭式问题,给下属提开放式问题