《持续演进的Cloud Native》读书笔记

《持续演进的Cloud Native: 原原生架构下的微服务最佳实践》
王启军/著 （公众号：奔跑中的蜗牛）
电子工业出版社
2018.10出版

Cloud Native的组成

Cloud Native需要从架构、研发流程和团队文化三个角度来实现，三者需要相互配合，缺一不可。

• 架构
  Cloud Native是以云和微服务架构为基础，云包含了敏捷基础设施及公共基础组件。同时还需要考虑架构的质量属性。

• 研发流程
  自动化的研发环境是Cloud Native的基础。尽量减少测试及运维对开发的协助，最好由全栈工程师独自快速交付。

• 团队文化
  一切以人为主，需要建立自由开放的环境。高度信任，增强自我驱动。微服务架构要求小团队具有自主决策的权力，避免无论大事小事都要拿到会议上讨论，造成决策瓶颈。

Cloud Native成熟度模型

Cloud Native的原则

• 为失败设计原则
  接受出问题是必然的这个现实，架构中能够容忍故障的发生，最小化故障的影响范围。
• 不变性原则
  每个服务或组件在安装、部署完成后将不会发生更改，如果更改在丢弃老的部署新的。
• 去中心化原则
  不会因为一个节点的故障导致整个系统不可用，研发流程上做到关注点分离。
• 标准化原则
  一旦系统规模变大，做到标准化是无法避免的。所谓独立自主是在一定的标准下实现。
• 速度优先原则
  当速度和效率发生冲突时，速度优先。
• 简化设计原则
  如果你发现设计满足了所有的要求，说明你一定过度设计了。
• 自动化驱动原则
  只有真正拥抱自动化才能做到持续发布，才能做到更好的用户体验。
• 演进式设计原则
  架构是持续演进的，不要一蹴而就。

可用性设计

可用性和可靠性的关系

• 可用性（Availability）是关于系统可以被使用的时间的描述，以丢失的时间为驱动（Be Driven by Lost Time）
• 可靠性（Reliability）是关于系统无失效时间间隔的描述，以发生的失效个数为驱动(Be Driven by Number of Failure)

计算公式

• Availability = Uptime / ( Uptime + Downtime )
• Reliability = MTBF / (MTBF + MTTR)
  MTFB: Mean Time Between Failure 平均无故障工作时间，指上一次故障恢复后开始正常运行到这次故障的时间平均值。
  MTTR: Mean Time To Repair 平均故障恢复时间，指从初心故障到完全恢复的这段时间。

可用性的衡量标准

可用性通常以N个9的方式来量化。

可用性等级	可用性百分比	年度停机时间	可能会用到的技术
基本可用	99%	87.6小时	简单的负载均衡
较高可用	99.9%	8.8小时	灰度发布、自动化发布、自动化测试、快速回滚
高级可用	99.99%	53分钟	微服务、中间件自动扩展、容错、监控、弹性伸缩
极高可用	99.999%	5分钟	异地多活、智能运维

什么降低了可用性

• 发布
• 故障
• 压力
• 外部强依赖

大型网站典型故障案例

• 写日志过多
• 高并发访问数据库
• 缓存故障
• 应用启动不同步
• 大文件读写独占磁盘
• 滥用生产环境
• 不规范的流程
• 不好的编程习惯

发布方案

• 影子测试：在生产环境通过流量复制、回放和比对的测试方法。
  • 负载均衡日志回放
  • TCPCopy

ngx_http_mirror_module、tcpcopy、GoReplay 原名gor、滴滴 rdebug

• A/B Testing: 业务场景并行
• 蓝绿部署：系统群并行
  在生产环境额外冗余一份相同的环境。测试通过后，可用把负载均衡/反向代理/路由从蓝色环境指向绿色环境。需要回退直接切整体环境。
• 灰度发布/金丝雀发布：部署实例新旧版本并行
  在原有版本可用的情况下，同时部署一个新的版本作为“金丝雀”，测试新版本的性能和表现，以保证在整体系统稳定的情况下，尽早发现问题并解决问题。

容错设计

• 消除单点
• 特性开关
• 服务分级
• 降级设计
• 超时重试
• 隔离策略
• 熔断器

降级设计

• 关闭功能
• 请求短路
• 简化流程
• 延迟执行

超时重试技术考虑点

• 超时时间
• 重试次数
• 间隔时间
• 间隔时间衰减度

超时重试技术方案

• 简单重试模式：try-catch-redo
• 策略重试模式：try-catch-redo-retry strategy
  • 基于spring-retry:
  • 基于Guava-retrying

服务隔离策略

• 线程池隔离
• 进程隔离
• 集群隔离
• 用户隔离
• 租户隔离

限流算法

• 固定窗口算法 （fixed window）
• 漏桶算法（Leaky Bucket）
• 令牌桶算法（token bucket）

漏桶算法和令牌桶算法的对比

漏桶算法	令牌桶算法
不依赖令牌，不保存令牌	依赖令牌
如果桶满了，则丢弃数据包	如果桶满了，则丢弃令牌，不丢弃数据包
不允许突发，恒定速率	允许突发

限流技术方案

• Guava限流
• Nginx限流
• waf限流

性能设计

常见的性能问题

• 内存泄漏：内存耗尽
• 过载：突发流量，大量超时重试
• 网络瓶颈
• 阻塞：无尽的等待
• 锁：通过限制
• IO繁忙：大量的读写
• CPU繁忙
• 长请求拥塞：连接耗尽

性能目标

• 响应时间 latency
• 吞吐量 throughput: QPS
• 负载敏感度
• 可伸缩性

性能目标案例

• 响应时间：99%<1s
• 吞吐量大于10万TPS
• 系统数据量：10亿>订单表>1亿
• 数据增长速度：1亿/年
• 资源限制：服务器、配置、网络

如何定位瓶颈

• 压力测试
• 日志分析
• 监控工具

性能优化方向

• 服务通讯优化
• 消息中间件
• 缓存
• 数据库优化

服务通讯优化

• 同步转异步
• 阻塞转非阻塞
• 序列化

可扩展性设计

AKF扩展立方体

	描述	场景	优势	挑战
X轴	通常称为水平扩展，通过复制实例，前端对流量进行负载均衡，从而分摊整体压力	产品初期	架构简单，只需要负载均衡	有状态的服务不容易扩展
Y轴	根据服务或者资源扩展，即从单体服务演进到微服务架构	业务逻辑复杂，代码规模大	故障隔离性好，容易实现业务复杂性分解	对工具环境依赖高、运维复杂、一致性实现成本高
Z轴	根据查询或者计算结果进行拆分。即分片	大型分布式系统	突破单张表的数据规模	架构复杂、数据迁移负载

微服务的缺点

• 增加了服务调用的开销
• 分布式系事务
• 调试与服务治理

如何扩
展数据库

• X轴扩展：主从复制集群，Master-Slave读写分离。
• Y轴扩展：分库、垂直分表
• X轴扩展：分片(sharding)
  • 区间法（Range-Based）：一个月一张表
  • 轮流法（Round-Robin） ：n = K mod N
  • 一致性哈希（Consistent Hash）

一致性设计

事务之间的关系可以通过happen-before表达为如下四种：

• 读写
• 写读
• 读读
• 写写

ANSI SQL92标准定义的四种事务隔离级别如下：

• 未提交读（Read uncommitted）
• 提交读（Read committed）
• 可重复读（Repeatable reads）
• 可串行化（Serializable）

Mysql默认事务隔离级别：可重复读

隔离级别	发生脏读	不可重复读	发生幻读	加锁读
未提交读	✓	X	✓	X
提交读	X	✓	✓	X
可重复读	X	X	✓	X
可串行化	X	X	X	✓

分布式事务理论

• Quorum机制
• 租约机制 Lease
• 状态机 Replilcated state machine

状态机故障时节点切换算法

• Paxos算法
• Raft算法

Raft算法

Raft算法将Server分为三种类型：Leader、Follower和Candidate。

• Leader处理所有的查询和事务，并向Follower同步事务。
• Follower会将所有的RPC查询和事务转发给Leader处理，它仅从Leader接受事务的同步。数据的一致性以Leader中的数据为准实现。

Raft把一致性问题，分解成三个比较独立的子问题，并给出每个子问题的解决方法：

• 选举：描述Raft是如何选择一个leader的，这个部分很受容易理解了。
• 日志复制：描述Raft的leader是如何把日志复制到集群的各个节点上的。
• 安全性：描述Raft是如何保证“State Machine Safety Property”。

分布式系统的一致性分类

以数据为中心的一致性模型

• 严格一致性 strict consistency
• 顺序一致性 sequential consistency
• 因果一致性 causal consistency
• FIFO一致性

以用户为中心的一致性模型

• 单调读一致性 Monotonic-read consistency
• 单调写一致性 mono-write consistency
• 写后读一致性 read-your-writes consistency
• 读后写一致性 write-follow-reads consistency

业界常用的一致性模型

• 弱一致性
• 最终一致性 Eventual consistency
• 强一致性 strong consistency

如何实现强一致性

• 两阶段提交 2PC
• 三阶段提交 3PC

如何实现最终一致性

• 重试机制
• 本地记录日志
• 可靠事件模式
• Saga事务模型
• TCC事务模型

分布式锁

• 基于DBMS： 乐观锁CAS，悲观锁 select for update
• 基于Zookeeper
• 基于Redis： Set if not exists

如何保证幂等性

• 幂等令牌 Idempotency Key
• 写前检查

多版本并发控制(MVCC)