《微服务设计》11、12章笔记

第十一章 规模化微服务

11.1 故障无处不在

问题

硬盘挂载，软件崩溃，网络不可靠。。。
==》难以避免
==》拥抱故障，计划停机总比意外停机好吧
==》或者是如何优雅地处理

11.2 多少是太多

1. 你可以容忍多少故障呢？
2. 系统需要有多快呢？

指标：

1. 延迟
2. 可用性
3. 数据持久性
4. 功能降级
5. 某个辅助服务不可用的时候，去除了也不影响主业务。
   ==》思考一下这个服务挂载了，会有什么后果。

架构安全性

1. 服务响应缓慢是一个很糟糕的故障（占满所有worker）
2. 「断路器」设置超时时间

11.5 反脆弱的组织

1. 事物实际上收益于失败和混乱。
2. 混乱的猴子，在一天的特定时间破坏系统。（开发人员不得不做好准备）
3. 在失败中学习，而不是一味地指责。

解决：

• 超时
• 断路器（当失败到了一定阈值，拒绝请求）
• 手动使用比较安全。
• 工具：Hystrix
  • 舱壁（故障隔离），保护级联系统【最重要的】
  • 越是依赖就越需要隔离

11.6 幂等

多次执行=一次执行（存钱的操作）

11.7 扩展（避免失败）

• 更强大的主机
• 拆分负载（分开多个服务）
• 分散风险（多个虚拟机，虚拟化，或者多个数据中心）
• 负载均衡
  • vlan
• 基于worker 的系统
  • hadoop（共享作业队列）
• 重新设计（拆分+新技术）==》有危险

11.8 扩展数据库

1. 服务的可用性和数据的持久性
2. 扩展读取（加缓存）
3. 扩展写（分片）
   难点在查询，你也可以使用一些中间件
4. 共享数据库基础设施（服务）

CQRS(命令查询职责分离)

存储和查询的替代模型

执行

1. 收到命令-->有效-->应用到模型（允许扩展模型）
2. 处理命令和查询模型本身是相互独立的
3. 命令和查询可能在不同的机器上，不同服务上。
4. 查询也可以不同返回格式

缓存（性能优化的一种方式）

• 客户端(改变较难)，代理（cdn）和服务器缓存
• http缓存
• cache-control
• expires
• Etag（url还是一样，但是Etag变就会重新获取数据）
• 为写使用缓存
• 弹性使用缓存（确保有一个可用的版本）

隐藏源服务

• 当缓存区都被清了，就要适当写入新的缓存
• 外部请求适当减少，保证系统正常
• 缓存不要太多
• 失效时间+主动失效

11.10 自动伸缩

预测伸缩，响应伸缩（谨慎）

11.11 CAP定理

• 一致性
• 可用性
• 分区容忍性

牺牲一致性（ap系统）==》后期不得不做同步
牺牲可用性（数据不能同步，系统断开不可用）
牺牲分区容忍性（没有分区容忍就没有跨网络调用了）

AP还是CP（CP的挑战较大）

不是所有服务都需要这样去做

11.12 服务发现

怎么找到你？

• dns
  • 某个机器有问题的时候，怎么主动拒绝呢？
• 动态服务注册
  • zk(通用)
  • Consul（比zk更先进）
    • 提供现成的DNS服务器，并支持SRV
    • 节点健康检查（高容错设计）
    • 故障管理和报警
• Eureka
  • 负载均衡

别忘了人

数据是给人看的

11.14 文档服务

明显清晰的API

1. Swagger(作者推荐)
2. HAL和HAL浏览器（使用超媒体）

11.15 自描述系统

• UDDI （描述，发现，服务集成）
• 系统当前运行情况

推荐书籍：

• 《反脆弱》
• 《发布！软件的设计与部署》

CH12 总结

1. 制定原则，作为决策的依据
2. 什么时候不应该使用微服务
3. 难免会有一些错误

缩小决策的范围，影响一小部分。
拥抱演进式的架构