常见的微服务故障

背景

微服务架构指的是将大型复杂系统按功能或者业务需求垂直切分成更小的子系统，这些子系统以独立部署的子进程存在，它们之间通过轻量级的、跨语言的同步（比如REST，gRPC）或者异步（消息）网络调用进行通信。

现象

在微服务生态系统堆栈的顶层是各个微服务。对于开发团队来说，因为它们完全依赖于良好的开发实践、良好的部署实践以及开发团队构建、运行和维护其单个微服务的方式。

假设微服务层下面的基础设施相对稳定，微服务经历的大多数事件和中断几乎都是自行造成的。应该让的开发人员针对其微服务中，自己发现完整的根本原因和故障，即他们收到的告警，将来自其微服务的关键指标的变更触发（有关监视、日志记录、告警和微服务密钥指标的详细信息）。

如是一个服务失败示例， 通常需要隔离它

还有一些情况是，服务之间有依赖的，其有一个服务失败导致多个服务失败。这时你需要多个故障转移Failover

代码审查Code Review不完整、缺乏适当的测试覆盖率以及不规范开发流程（具体来说，缺乏标准化开发流程）会导致将错误代码部署到生产环境中，而通过跨微服务团队标准化开发流程是可以避免故障。如果没有一个稳定可靠的部署管道，其中包含Staging、金丝雀和生产阶段的设置，在将任何错误完全部署到生产服务器之前捕获任何错误，在开发阶段测试未捕获的任何问题都可能导致微服务本身、其依赖项以及依赖于它的微服务生态系统的任何其他部分出现严重事件和中断。

当我们平台缺少微服务应用层监控时，不能及时收到告警，做出决策，最终可能会引起大规模的微服务实例失败。

那些本身模块或服务设计有问题，如不规范的程序重试逻辑，不正确的缓存使用场景。这些都会导致某个微服务的失败，这些需要在测试过程时需要发现与解决，包括架构设计评审。

任何特定于微服务体系结构也可能失败，包括任何数据库、消息中间件、任务处理系统等。这也是微服务中的常规和特定代码错误会导致故障以及不正确的错误和异常处理：当微服务失败时，未处理的异常是经常被忽视的罪魁祸首。最后，如果服务未做好突发增长做好准备，流量的增加可能会导致服务失败。

总结

一些最常见的微服务故障包括：

• 不完整的代码审查 • 糟糕的架构和设计 • 缺乏适当的单元和集成测试 • 部署错误 • 缺乏适当的监控 • 错误和异常处理不当 • 数据库故障 • 可伸缩性限制

注意：我们不能依赖容器编排平台Kubernetes来解决以上问题，很多时候是研发流程的问题，通过事前过程来预防微服务的失败，而不是通过事后控制。

作者：Petter Liu 来源: http://www.cnblogs.com/wintersun/