在基于微服务的架构中，提供给用户的功能会涉及多个不同的服务。在一个不具备中心化的入口统一访问数据时，很难了解每个请求的执行情况。这些服务临时性地分布在不同的服务器节点上，并且为了满足运行的需要会被反复地部署和扩容。
单个应用所实现的出售订单用例
如果要检查系统中某个特定请求的生命周期，则可以登录到机器然后检查存储在硬盘上的日志数据。但是为了保证冗余度和可用性，很可能在多台机器上运行应用，这时，事情就不再是登录到一台机器上那么简单了。一旦确定了所关注的请求，就必须确定执行该请求的是哪台机器，然后检查这台机器。浏览这台机器的日志将加深对该请求的理解。
这并不意味在单台机器上维护日志就是一件容易的事情——服务器同样可能崩溃而不可用。目的并不是讨论如何降低日志数据安全存储的复杂度，而是想说明为所有保存的数据提供单一入口能够简化和方便执行查询操作。
多服务情形下出售股票订单，有5个独立运行的服务，每个服务有3个正在运行的实例。意味着这些pod都运行在不同物理机上。请求到达系统后很可能会在不同物理机上的多个pod之间流转，想要通过访问日志来追踪请求并不是一件容易的事。即便能做得到，谁又能保证在需要访问这些数据时，这些pod都还在运行中呢？
即便有一些持久化方案能够将pod调度前的日志数据保留下来，但在整个系统中找到一条请求也并不是一件容易的事情。需要一种更好的方式来记录系统的运行情况。为了能够全面了解系统的运行方式，需要做的是：确保持久化保存日志数据，这样，在服务重启和扩容时日志数据继续存在；确保将不同服务以及不同服务实例中的所有日志数据聚合到一个集中的地方；确保所存储的数据可用、易于检索并支持进一步处理。
为了有效地存储日志数据并保持数据可搜索，首先需要使整个工程团队在所使用的日志格式上达成一致。一致的日志格式有助于保证开发者能够高效地存储和处理数据。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论