Designing a Microservices Architecture for Failure

为服务架构可以定义明确的边界来隔离故障,就像每一个分布式系统一样,发生在网络、硬件、应用层级的错误是很常见的。为了优雅的处理这些错误,我们需要设计一种可容错的微服务架构。

微服务架构的风险

微服务架构将程序的逻辑移动到服务,并使它们在网络层进行通信,这回带来额外的延迟,需要多个模块的协作才能完成。分布式系统的复杂性也必将导致更高的故障率。但它最大的优势在于全生命周期、独立设计,但要记住,微服务的提供者可能会临时不可用。

核心概念

  1. 优雅的服务降级 系统中一些部分出了故障之后,仍旧能够保证其它部分不受影响。
  2. 变更管理 当需要对系统进行变更时,需要分步变更,每次变动一小部分,且能够快速回滚。
  3. 健康检查与负载均衡 需要实时统计节点的可用性,并在节点不可用时,通过负载均衡器将流量转移到可用节点。
  4. 自我修复 自我修复通常由外部系统实现,在服务故障时重启服务,这在大多数情况下是有效的,但如果服务是因为过负荷导致的故障,那么重启服务只会使情况更糟糕。
  5. 故障转移缓存 当在服务使用过期的数据比没有数据强的情况下,可以使用缓存来进行临时服务。
  6. 重试逻辑 如果我们预期服务将在一定时间后恢复,可以采用重试的方式来进行自我恢复,但大量的重试容易导致灾难。为了避免级联效应,应该严格控制重试的次数。并且在一些核心领域需要避免重复操作。
  7. 限流器与负载降级 流量限制可以限定一段时间内可以服务的次数,这能够有效的避免峰值流量。负载降级可以保证在核心服务在高峰期的可用性,自动屏蔽低优先级服务。
  8. 快速失败与独立性 我们不应该等到超时之后,才知道服务故障,在微服务中使用超时达到快速失败的目的是反模式的,你应该尽量避免。取而代之应该使用断路器模式,根据成功和失败的次数来决定。
  9. 舱壁模式 为了保证一个服务出现故障时,资源不至于被快速耗尽。比如两个服务都连接数据库,应该使用两个数据库连接池。
  10. 断路器模式 当特定的错误在短时间内出现多次时,断路器就会被断开,来让服务进行恢复。
  11. 测试故障 应该经常测试故障,让团队具备故障测试、处理能力。

    原文连接:Designing a Microservices Architecture for Failure