微服务转型绕不开的坑——日志记录这样做就对了

在如今企业纷纷转型微服务的过程中，微服务架构中日志记录的重要性时常会被忽略。本文作者十分关注微服务日志记录，提出了独到的观点，并与大家分享关于微服务日志记录的各种技巧的最佳实践。

微服务架构是一种软件架构类型，着重于利用大量细分组件进行应用开发，其中每个组件都负责整体业务中的一小部分。这些组件彼此独立，支持在自己的进程之上，且能够相互通信以实现业务目标。

为什么要关注日志记录？

很多企业都开始将整体型应用拆分为微服务形式。而在拆分大型应用时，我们需要建立松散耦合的模块，从而保证其便于测试并降低变更风险。另外，这些模块亦可独立部署以实现横向规模扩展。然而，这也会带来一些初看并不严重，但长远影响极其重大的问题——其中的典型代表就是日志记录。

日志记录存在于一切应用当中，无论其属于整体还是微服务架构。关键在于，当我们将应用拆分为微服务形式时，我们需要投入大量时间来思考业务边界并找寻最理想的应用逻辑拆分方式——但很少有人会对日志记录给予应有的重视。

当然，大家可能会问：日志记录的方式一直没有变化过，为什么现在倒成了需要关注的问题？

理由在于，整体应用内的事务追踪往往比较困难，有时候我们只能依靠日志记录来理解当前状况。另外，当业务逻辑运行在多项服务中时，监控与日志记录的难度也会相应增加。这意味着如果我们没有明智地规划出微服务记录机制，那么最终可能根本无法理解应用的当前运行状态。

正因为如此，我想与大家分享我的个人经验以及作为软件开发者积累到的一点心得。近年来我一直在使用微服务方案，希望大家能够在读完本文后意识到日志记录的重要性与实现难点。

心得一——设立应用实例标识符

在使用微服务时，整套体系往往会同一时间运行同一组件的多个实例。最重要的就是在日志条目中设立实例标识符，从而区分各条目的具体来源。其ID的具体生成方式其实并不重要，只要保证惟一即可，这样我们才能借此回溯到特定服务器/容器以及生成该条目的应用处。在微服务架构中，大家可以利用服务注册表轻松为每项服务分配惟一的标识符。

心得二——坚持使用UTC时间

这项心得不仅适用于微服务架构，在其它场景下也同样值得坚持。任何使用过分布式应用程序——或者组件分散在各处——的朋友，都会意识到各组件使用不同时区进行计时有多么令人头痛。而在微服务架构中，以本地时间记录的日志条目会带来更严重的问题。如果大家确实需要使用本地时间，请在日志条目中以字段形式添加时区，从而简化信息的检索方式。但更重要的是一定要为UTC时间设立时区，并利用它在聚合工具内进行信息排序。
下面来看示例日志信息：

第一部分是由一项运行在新西兰的服务所生成。第二部分则由运行在巴西的服务生成。由于我们使用本地日期，因此由巴西服务生成的信息会早于新西兰信息——但其实际生成时间却恰恰相反。

现在，让我们看看使用UTC时间与时区后的示例信息：

现在两条信息已经得到正确的时间排序，如果大家希望了解信息的本地生成时间，则可将其由UTC转换为特定时区。

心得三——生成请求标识符

在将业务逻辑拆分为多个不同组件时，我们的逻辑最终需要由一个或者多个组件构成。而在追踪这些事务时，我们往往很难对其加以识别。因此，大家应当为每个事务生成一个惟一标识符，并利用其关联事件以及追踪各项事务。

想象一下，如果我们需要利用以下请求序列在某电子商务网站上购买产品：

那么我们对于操作的分组方法，显然取决于事务的实际定义（毕竟其也能够进行嵌套）。最重要的是确保在事务开端，我们为其创建一个能够传递下去的标识符，并借此在事务结束之前全程记录日志条目。

一般来讲，我倾向于使用人工生成的ID来区分自己的事务。大家也可以使用user_id或者session_id处理与用户相关的事务。而在进行结算与支付时，大家可以使用order_id来追踪结算与付款操作。不过其前提是大家已经进行了用户登录，或者创建了拥有order_id的订单——但实际情况往往并非如此。在使用手动ID时，大家可以将事务ID从业务逻辑流中解耦出来。

另外需要注意的是，这些ID需要拥有足够的信息以对系统中的各项事务进行区分。有时候事务识别符可能在日志条目中体现为一整套字段组合。

心得四——利用聚合工具进行日志分组

如果大家没有对来自全部微服务的日志条目进行聚合，那么以上提到的心得将毫无意义。要实现这一目标，我们需要使用一款能够轻松实现条目分组与查询的工具。我个人使用ELK堆栈，其效果相当出色。如果大家之前没听过ELK，这里可以稍微解释几句。ELK是三款应用的集合体，由此构成的完整解决方案能够调度日志条目、实现条目存储与索引，而后对信息进行聚合与可视化处理。

我们可以利用ELK对应用程序日志进行多种规模伸缩与分发处理，但这里就不讲太多了。感兴趣的朋友可以查看Logz.io博客上的Logstash教程，其中提到了多项相关使用技巧。另外，我们也可以使用Logz.io等企业服务处理日志基础设施的设置与维护工作，从而确保自己的微服务体系采用最理想的日志记录实践方案。

总结

这篇文章的目的是向大家强调在微服务架构中重视日志记录的必要性，同时分享一些在实际应用当中积累到的最佳实践。但这仅仅是个开始，相信大家能够采用多种其它方式解决日志记录难题。

文章来源：Logz.io 作者 Lucas Saldanha