《持续演进的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默认事务隔离级别:可重复读

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

分布式事务理论

  • 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)

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值