X

曜彤.手记

随记,关于互联网技术、产品与创业

吉 ICP 备10004938-2号

《大型网站技术架构 - 核心原理与案例分析》读书笔记


一本介绍网站架构演进的书。这本书中很少涉及具体的编程或者系统设计方案细节,而是以一个更加宏观的角度讨论了大型网站的架构演进方案。短短不到两百页,将一些基本的架构方案和设计要素娓娓道来。

第 1 章 - 大型网站架构演化

  1. (Page:3)大型互联网应用系统具有的特点:
  1. (Page:5)网站的访问特点符合二八定律,即:80% 的业务访问集中在 20% 的数据资源上。因此,对于这部分“热”资源,可以考虑使用缓存来加速访问。
  2. (Page:12)大型网站架构的“最终”演化结构:

- 基本演化流程

  1. (Page:14)网站架构常见误区:

第 2 章 - 大型网站架构模式

  1. (Page:17)常用的大型网站架构模式:

第 3 章 - 大型网站核心架构要素

  1. (Page:28)网站高可用的主要手段是:冗余
  2. (Page:30)网站可伸缩架构的主要手段是:
  1. (Page:31)大型网站核心架构要素:

第 4 章 - 瞬时响应:网站的高性能架构

  1. (Page:36)常见系统操作响应时间:

  1. (Page:36)常见性能指标:
  1. (Page:39)性能测试方法:

- 性能测试曲线

  1. (Page:45)缓存

- 缓存优化相关问题

系统的正常运行不应该依赖于缓存系统,初始的缓存系统可以先进行“缓存预热”,比如 Redis 在初始化时会从硬盘中读取数据放到内存。如果在日志中发现大量的无法命中缓存的请求,这可能是发生了“缓存穿透”,恶意用户持续高并发的访问系统不存在的资源,这些资源无法被缓存下来导致了穿透问题,一个简单的对策是将不存在的数据也缓存起来(设置其 value 值为 null)。

- 分布式缓存架构

  1. (Page:52)其他常见的应用服务器优化方式:
  1. (Page:58)存储性能优化:使用 SSD 硬盘、NoSQL 数据库(LSM 树的数据更新速度较 B+ 树更快)、根据需求使用 RAID 磁盘阵列和 HDFS(RAID 可以在一定程度上改善磁盘的访问延迟同时增强可用性。但对于大量数据的存储需求,基于 MapReduce 可以进行并发任务处理的 HDFS 可能更加合适)。
  2. (Page:61)RAID(廉价磁盘冗余阵列),用于改善磁盘的访问延迟,增强磁盘的可用性和容错能力。

第 5 章 - 万无一失:网站的高可用架构

  1. (Page:67)网站可用性度量(全年):
  1. (Page:69)高可用架构设计:

- 基本分层结构

应用层负责业务逻辑处理,通常服务器通常为了应对高并发的请求,会通过 LB 组成集群来对外透明地提供服务。LB 会通过“心跳检测”来监控服务器状态,当发现不可用机器时将其从集群中剔除,并将该机器的路由设置为不可用,同时所有请求将转发到集群内的其他机器。

服务层的机器与应用层类似。这些服务器被上层通过分布式服务调用框架访问,框架会在应用层中实现软件负载均衡,并通过服务注册中心对提供服务的机器进行心跳检查,发现有服务不可用,会立即通知客户端程序修改服务访问列表,剔除不可用的服务器。

数据层的服务器比较特殊,为了保证数据不丢失,需要在数据写入时同时对集群内的其他服务器同步复制数据,以保证数据的一致性和可用性。

  1. (Page:71高可用应用

- 基于 LB 的失效转移

由于该层的无状态性质,可以利用 LB 服务器通过心跳检测及时发现失去响应的服务器,然后将请求转移到其他机器上;

- Session 管理

由于业务总是有状态的,单机情况下,会话信息可以交由服务器上的 Web 容器来管理。但对于集群环境来说,由于 LB 会将请求发送到集群中任意的服务器,所以通常使用以下几种方式来保证每次请求仍能获取正确的 Session:

  1. (Page:76)高可用服务:高可用的服务一定是独立的可复用的。服务的设计同样需要遵循几个原则:
  1. (Page:78高可用数据

- CAP 原理

根据 CAP 原理,一个数据服务的存储系统是无法同时满足以下这些性质:

一般为了保证数据高可用,会牺牲“数据一致性”。而由于 A 和 P 两个指标较 C 更为重要,在放弃了“数据强一致性”情况下,退而求其次可以在不影响用户体验时,选择保障“数据用户一致性”

- 数据备份

- 失效转移

  1. (Page:85)高可用软件质量保证

- 预发布验证

- 灰度发布

一段时间内只发布线上集群中的一部分机器,待观察一段时间没有问题后,再逐渐发布集群内的其他机器。在进行“灰度发布”的同时,我们甚至可以进行“A/B测试”,以新发布的机器作为对照组,查看新旧软件使用用户的反馈情况。

第 6 章 - 永无止境:网站的伸缩性架构

  1. (Page:99)常见负载均衡模式

- HTTP 重定向负载均衡

- DNS 域名解析负载均衡

- 反向代理负载均衡

- IP 负载均衡

- 数据链路层负载均衡(直接路由方式):

  1. (Page:105)常见负载均衡算法
  1. (Page:106分布式缓存集群的伸缩性设计:

- 基于 Memcached 的分布式缓存集群访问模型

- 分布式缓存的一致性 Hash 算法

先构造一个长度为 0~2^32 的整数环(一致性 Hash 环),根据节点名称的 Hash 值将缓存服务器节点放置在这个环上。根据需要缓存数据的 KEY 值计算得到其 Hash 值,然后在环上顺时针(递增)查找距离这个 KEY 的 Hash 值最近的缓存服务器节点,完成 KEY 到服务器的 Hash 映射查找。

当缓存服务器集群需要扩容时,只需将新加入的节点名称的 Hash 值放入一致性 Hash 环中,由于 KEY 是顺时针查找距离其最近的节点,因此新加入的节点只影响环中的一小段。一致性 Hash 环通常使用“二叉查找树”实现,查找过程实际上是在树中查找不小于查找数的最小数值。树的最右边叶子节点和最左边的叶子节点相连接,形成环。

可以通过使用“虚拟节点”的方式来解决物理节点资源分配不均的问题。每个物理节点对应的虚拟节点越多,各个物理节点之间的负载越均衡。通常,一台物理服务器被虚拟为 150 个虚拟服务器会较为合适

  1. (Page:113)数据存储服务器集群的伸缩性设计:

- 关系数据库集群(以 Cobar 为例):

- NoSQL 数据库(以 HBash 为例):

第 7 章 - 随需应变:网站的可扩展架构

  1. (Page:123)使用分布式消息队列降低系统耦合性:

- 事件驱动架构(EDA):

通过在低耦合的模块之间传输事件消息,以保持模块的松散耦合,并借助事件消息的通信完成模块间合作。常见的架构就是操作系统中的“生产者-消费者”模式。网站架构中,常用的是“分布式消息队列”。

- 分布式消息队列

  1. (Page:126)分布式服务:

- 拆分

- 需求和特点

  1. (Page:131)可扩展的数据结构:ColumnFamily。创建表时只需要指定 ColumnFamily 的名字,无需指定字段,可以在数据写入时再指定。

第 8 章 - 固若金汤:网站的安全架构

(略)



这是文章底线,下面是评论
  暂无评论,欢迎勾搭 :)