《凤凰架构：构建可靠的大型分布式系统》读后感

---

第一部分 演进中的架构

第一章 服务架构演进史

1. 什么是SOA?
   Service Oriented Architecture面向服务架构，为了对大型的单体系统进行拆分，让每个子系统都能独立的部署、运行、更新。
2. 什么是微服务？
   微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

第二部分 架构师的视角

第二章 访问远程服务

1. 远程服务的作用？
   远程服务将计算机程序的工作范围从单机扩展到网络，从本地延伸至远程，是构建分布式系统的首要基础。
2. 为什么要使用远程服务？
   让计算机能够跟调用本地方法一样去调用远程方法。
3. 幂等性是什么？
   服务被重复执行多次的效果与执行一次是相等的。

• 乐观锁：update tab_account set count = ? and version = version + 1 where version = ?；
• 防重表：执行操作前，先在防重表插入订单号，如果插入失败，则表示已执行；
• 分布式锁：用redis作为防重表。

第三章 事务处理

1. 事务的隔离级别？

• 读未提交： 现象：一个事务读取到另一个事务未提交的数据。原因：对事务涉及的数据只加写锁，以无锁的方式读取。结果：脏读；
• 读已提交： 现象：两次完全相同的查询结果不一样。原因： 由MVCC决定，每次都读取最新的版本号来获取数据快照。结果：不可重复读；
• 可重复读： 现象：两次完全相同的范围查询得到了不同的结果集。原因：由MVCC决定，只读取第一次select时生成的版本号来获取数据快照，但是当有插入时会导致查询最新版本号。结果：幻读；
• 串行访问： 现象：结果正确，但效率低下。原因： 对事务所有读、写的数据全都加上读锁、写锁。结果：正确。

2. 事务隔离依靠哪些锁实现的？

• 写锁（Write Lock，也叫作排他锁，eXclusive Lock，简写为 X-Lock）：如果数据有加写锁，就只有持有写锁的事务才能对数据进行写入操作，数据加持着写锁时，其他事务不能写入数据，也不能施加读锁；
• 读锁（Read Lock，也叫作共享锁，Shared Lock，简写为 S-Lock）：多个事务可以对同一个数据添加多个读锁，数据被加上读锁后就不能再被加上写锁，所以其他事务不能对该数据进行写入，但仍然可以读取。对于持有读锁的事务，如果该数据只有它自己一个事务加了读锁，允许直接将其升级为写锁，然后写入数据。
• 范围锁（Range Lock）：对于某个范围直接加排他锁，在这个范围内的数据不能被写入。如下语句是典型的加范围锁的例子：

SELECT * FROM books WHERE price < 100 FOR UPDATE;

3. 产生脏读、不可重复读和幻读的原因？
   一个事务在读数据过程中，受另外一个写数据的事务影响而破坏了隔离性。
4. 三段式提交的流程？

• 询问阶段（canCommit）：协调者会询问每个参与事务的数据库，根据自身状态，评估能否顺利完成本次事务；
• 准备阶段（preCommit）：协调者统计所有事务的参与者是否准备好提交了（对于数据库，会在重做日志中记录全部事务提交操作所要做的内容，只是缺少最后一条 Commit Record记录），已经准备好的协调者回复Prepared ，未准备好的回复Non-Prepared ；
• 提交阶段（doCommit）：当所有的参与者都提交回复Prepared ，协调者首先在本地持久化Commit指令，接着通知所有的参与者执行Commit指令并持久化。

5. 三段式提交的缺陷？

• 单点故障；
• 性能问题：三次持久化；
• 一致性风险。

6. 基于可靠事件队列实现的最终一致性？
   将一个完成的分布式事务拆分成多个本地式事务来完成，越容易出错的事务越先执行，采用不断轮询重试的方式确保后续的事务一定能执行成功。
   
7. TCC 事务？

• Try：尝试执行阶段，完成所有业务可执行性的检查（保障一致性），并且预留好全部需用到的业务资源（保障隔离性）。
• Confirm：确认执行阶段，不进行任何业务检查，直接使用 Try 阶段准备的资源来完成业务处理。Confirm 阶段可能会重复执行，因此本阶段所执行的操作需要具备幂等性。
• Cancel：取消执行阶段，释放 Try 阶段预留的业务资源。Cancel 阶段可能会重复执行，也需要满足幂等性。
  
  缺点：业务侵入式较强，要求业务处理过程必须拆分为“预留业务资源”和“确认/释放消费资源”两个子过程。

8. 分布式事务参考？
   分布式事务
9. 分布式锁参考？
   分布式锁

第四章 透明多级分流系统

1. 客户端缓存？

• HTTP 协议的无状态性决定了它必须依靠客户端缓存来解决网络传输效率上的缺陷。
• http请求客户端的命中过程：http请求 ⇒ 强制缓存 ⇒ 协商缓存 ⇒ 服务端。
  • 强制缓存：http请求首先会检查强制缓存是否过期（Cache-Control和Expires，Cache-Control优先级更高），如果命中成功则直接从本地返回信息（200 from memory cache）；
  • 协商缓存：如果强制缓存命中失败，则在请求头中携带协商缓存信息（ETag和Last-Modifued，ETag是响应资源的唯一标识，优先级更高）向服务端发送请求。服务端判断协商缓存是否命中，如果命中则返回304但不返回资源内容，命中失败则返回200并返回资源内容。
    

2. 域名解析？
   使用DNS预取（dns-prefetch；当浏览器加载页面时，就会提前对DNS预取指定的域名进行解析缓存）技术，减少用户等待时间，但要慎用。
3. 传输链路？

• 连接数优化：TCP/1.1 时代 浏览器为每一个域名维护了6个TCP连接；TCP/2.0 时代 浏览器为每个域名维护1个TCP持久连接；
• 传输压缩：传输压缩能节省文本数据的大小，但是传输压缩与用于节约 TCP 的持久连接机制是存在冲突；
• 快速 UDP 网络连接。

4. 内容分发网络？

• CDN路由解析的流程：
  • 架设好“.huawei.test.com”的服务器后，将服务器IP地址在CDN服务商注册为源站，并获得一个CNAME；
  • 将CNAME在购买“.huawei.test.com”这个域名的DNS服务商上注册为一个CNAME记录；
  • 当用户访问服务时，将首先命中DNS服务器，将域名解析为CNAME，并返回给用户本地DNS；
  • 由于能解析出这个CNAME的只有CDN服务商部署的权威DNS服务器，因此本地DNS会再去请求解析CNAME，CDN服务商部署的DNS服务器根据负载均衡、拓扑结构等原则，在全国各地搜索一个最合适的CDN缓存节点代替源站节点返回给用户端。
• 如何保证CDN的内容和源站同步？
  • 设置缓存规则，针对不同的内容设置不同的缓存刷新规则，对更新频繁的内容，可以设置较短的缓存时间；对于不经常更新的内容，可以设置较长的缓存时间，从而减小源站压力；
  • 登录CDN服务商控制台，手动刷新CDN缓存；
  • 在URL上拼接自增标识来保证回源。
    
• 内容分发分为主动分发和被动回源。

5. 负载均衡？

• 四层负载均衡：维持着TCP连接，主要工作于第二层（数据链路层）和第三层（网络层）上，特点：性能高，如：NAT。
• 七层负载均衡：主要工作于第七层（应用层），特点：功能强大，如：应用网关。

6. 服务端缓存?

• 采用多级缓存，即：Ehcache（进程内缓存，一级缓存） + Redis（分布式缓存，二级缓存）。
• 缓存的风险：
  • 缓存穿透：请求的数据根本不存在，导致每一次都无法从缓存中获得数据，最终请求到数据库。解决：对请求的key值做校验（布隆过滤器）、对空返回值也进行定时缓存；
  • 缓存击穿：热点Key失效，导致同一时间内多个请求到达数据库。解决：对请求Key进行加锁处理、热点Key不需要过期；
  • 缓存雪崩：同一时间内大量的Key失效，导致所有请求到达数据库。解决：增加多级缓存并设置不同的过期策略、将过期时间改为随机值；
  • 缓存污染： 缓存数据与真实数据不一致。解决：写数据时，先更新数据源，然后直接把缓存失效（仍存在问题，但实现简单且成本低）。

第五章 架构安全性

1. 认证：

• 常用框架：Shiro、Spring Security（推荐使用）；
• JAAS（Java Authentication and Authorization Service，Java 认证和授权服务）：一般把用户存放在“Principal”之中、密码存在“Credentials”之中、登录后从安全上下文“Context”中获取状态等常见的安全概念规范。

2. 授权：

• 认证授权的方式：
  • 基于session认证：用户认证成功后，将用户信息保存在session中，客户端的下次访问通过cookie中的JSESSIONID到服务端查询用户信息；
  • 基于token认证：JWTToken；
  • 客户端请求携带Authorization: Bearer XXXX，网关通过认证服务器将请求头解析成JWT，然后通过ZuulFilter将JWT传递给下游服务，下游服务在OncePerRequestFilter中将JWT重新组装成用户对象并保存在安全上下文中。
• OAuth2协议的模式：
  • 授权码模式：客户端向授权服务器请求授权码，授权服务器将客户端重定向到授权页面，用户确认授权后，授权服务器返回授权码给客户端，客户端携带授权码请求access_token。
  • 简化模式：与授权码模式类似，请求授权码时，授权服务器直接返回access_token给客户端，不需要再去请求/oauth/token接口。
  • 密码模式：客户端直接向授权服务器申请access_token。
  • 客户端模式：第三方服务器申请访问资源服务器时使用。
• access_token的作用：客户端获取到access_token后，再次去访问资源服务器时（携带access_token作为请求头：Authorization:Bearer access_token），资源服务器会调用授权服务器/oauth/check_token接口，完成对用户身份的认证授权。缺点：每次客户端请求资源服务器，都需要请求授权服务器完成校验。（解决方案：JWT，但JWT本身携带用户信息，占用带宽较大）。

3. 保密：
   为每一个密码（客户端传来的哈希值）产生一个随机的盐值（动态盐值），并把客户端传来的哈希值和动态盐值在做一次哈希，把动态盐值和最终的哈希值存入数据库。
   server_hash = SHA256(client_hash + server_salt);
   DB.save(server_hash, server_salt);
4. 传输：

• CA：数字证书认证中心（Certificate Authority）；
• 证书：权威CA对特定公钥信息的一种公证载体。由于客户端已经预装了权威CA的根证书，因此可以在不依靠网络的情况下，使用权威CA的根证书中的公钥对其所颁发的证书进行验证；
• SSL握手流程（两轮四次握手）：
  • 客户端向服务端请求加密通信；
  • 服务器接收到客户端的通信请求后，如果客户端声明支持的协议版本和加密算法组合与服务端相匹配的话，就向客户端发出回应（包括服务端的X.509证书）。如果不匹配，将会返回一个握手失败的警告提示；
  • 客户端收到服务器应答后，先要验证服务器的证书合法性。如果证书不是可信机构颁布的，或者证书中信息存在问题，譬如域名与实际域名不一致、或者证书已经过期、或通过在线证书状态协议得知证书已被吊销，等等，都会向访问者显示一个“证书不可信任”的警告，由用户自行选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的公钥；
  • 服务端向客户端回应最后的确认通知。

5. 验证：
   请求参数合法性的校验行为在Bean中处理。

第三部分 分布式的基石

第六章 分布式共识算法

第七章 从类库到服务

第八章 流量治理

第九章 可靠通讯

第十章 可观测性

1. 分布式链路追踪：
   sleuth + zipkin + MQ + mysql

• sleuth：为从客户端发起请求到微服务完成响应的整个调用过程追加调用记录，为整个调用过程生成一个TraceId，为微服务中的每次调用生成一个SpanId；
• zipkin：
  • 客户端：使用收集器组件收集各个服务器上的请求链路追踪信息，并通过REST接口发送到服务器；
  • 服务器：提供可视化页面展示链路追踪信息，并对该信息进行持久化（推荐使用ES持久化）。
• MQ：将zipkin客户端的REST接口发送数据改成通过MQ发送数据到服务器。
• mysql：为zipkin服务端的持久化功能提供存储空间。

第四部分 不可变基础设施

第五部分 技术方法论