网络问题最有可能影响服务的运行。如果只在服务层面上收集度量指标，那么所能知道的也就只能是这个服务现在没有请求可处理。除此之外，对于问题出现的原因一无所知。如果同时还收集了基础设施层的度量指标，就可以了解到那些极有可能影响其他众多组件的问题。一个产品从架构上分为客户端、边界层、服务层和平台层，如果仅仅监控某一个特定组件的运行情况，显然是不够的，这4层架构都应该监控起来。
订单发布功能所涉及的服务及通信协议
由多个服务共同协作以实现了客户端发布股票买卖订单的功能。涉及的服务非常多；有些服务之间的通信通过RPC或者HTTP是同步的；而有些通信则是异步的——利用事件队列。为了能够了解这些服务是如何执行的，需要收集许多来源的数据，以进行系统监控和问题诊断或者在问题发生之前阻止其发生。
监控单个服务几乎是没有什么用处的，虽然服务提供了隔离性，但服务并不是和外部世界相互隔离而独自存在的。各个服务之间通常是相互依赖的，并且这些服务还依赖于底层基础设施（比如，网络、数据库、缓存和事件队列）。
如何监控服务获取到大量有价值的信息，需要了解所有架构层上当前的执行情况。
监控系统应该知道哪部分系统出现了问题或者服务质量出现下降以及相应的原因。这样就能够快速发现问题征兆，并使用已有的监控系统来确定原因。
如果market服务在和股票交易服务通信时出现问题，可以通过衡量服务调用的响应时间或者HTTP状态码来进行诊断。在这种情况下，开发者基本上可以确定订单提交功能运行不正常。
如果是服务与事件队列之间的连接出现问题了呢？服务将不能发布消息，那么下游服务也就不能消费消息了。在这种情况下，没有服务出现故障，因为没有服务在执行和处于工作状态。如果有合适的监控，可以发送告警消息通知吞吐量有异常减少的情况。可以对监控系统进行设置，当指定队列中消息数小于某个特定阈值时，系统会自动发送通知。
消息短缺并不是表明系统有问题的唯一标志。如果指定队列中的消息积压得越来越多呢？这种消息积压表明队列中消费这些消息的服务可能没有正常工作，或者在满足不断增长的需求时出现了一些问题。监控能够帮助发现问题乃至预测负载的增加，进而采取相应的措施来维持服务质量。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论