微服务的行为和状态应该是可观测的。不管在什么时候，开发者都应该能够判断服务是否健康以及处理请求是否符合预期。如果某些内容影响到了某个关键指标——比如，订单提交到市场的时间过长——那么系统应该向工程师团队发送告警——这个告警需要有足够的理由才能发送。
SimpleBank公司曾出现过一次故障。有位客户打电话说她不能提交订单了。经过快速检查之后，工程师发现这个问题已经影响到所有客户了：所有发给order服务进行订单创建的请求都超时了。该服务可能的故障点如图所示。
开发者有一个很大的操作问题：缺乏用来判断到底是谁出错了以及具体哪里出错了的日志。所以，开发者只能通过手工测试进行验证，最终成功地将问题排查了出来：account transaction服务没有响应。而这时，客户已经好几个小时不能下单了，他们非常生气。
为了避免未来发生这种问题，开发者需要为微服务添加一套全面的工具。收集应用各个层面的活动数据对于了解微服务应用当前以及过去的运行表现是至关重要的。
首先，SimpleBank公司要搭建一套对微服务产生的基础日志进行聚合的基础系统，同时还要将这些数据发送到某个服务便于开发者进行查询和标记。
开发者为每台虚拟机安装一个日志收集的代理应用。这个应用会将应用日志数据传到一个中心化的日志仓库中。开发者可以为日志创建索引、搜索，并能对其做进一步分析。
有了该方案，下次有服务出现故障时，工程师团队就可以使用这些日志来确定系统哪里出现了故障，并进一步排查出问题发生的具体位置和情况。
但是，日志记录不充分还不是唯一的问题。令人尴尬的是，SimpleBank公司在客户打电话投诉以后才发现了问题。公司还应该有一套告警方案来确保所有服务都符合响应要求和服务目标。
在这种场景中，最简单的方式就是，开发者应该有一套作用于每个微服务的反复执行的心跳检测机制，一旦服务完全没有响应，心跳检测就可以向团队发送告警。除此之外，团队还应该对每个服务做出服务保证的承诺，比如，对于关键服务，开发者会保证在99.99%的可用性基础上，95%的请求能够在100毫秒内返回。如果没有达到这些阈值，就应该向服务所有者发送告警。
为微服务应用开发完整的监控系统是一项很复杂的任务。开发者所采用的监控深入度会随着服务的数量和复杂度的提升而演化。除了我们所介绍的运维指标和日志，一套成熟的微服务监控方案还会处理业务指标、服务间链路追踪和基础设施指标。如果开发者想要信任自己的服务，就需要不断地研究这些数据的含义。后续学习如何用Prometheus之类的微服务工具来触发告警以及如何搭建一套健康监控仪表盘。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论