引言：本文向您介绍如何为微服务应用收集有意义的日志，并妥善保存的一些最佳实践。
微服务架构（http://microservices.io/）是一种全新的应用结构，它能够帮助您通过松耦合的系统，开发、测试、部署和发布彼此相互独立的各种服务。因此微服务背后的理念是：将大型系统分解成多个独立的小部分。通常情况下，每个服务都能通过HTTP的端点与其他服务交互。它们在隐藏技术栈细节的同时，会暴露自己的契约（contract）给其对应的消费者（consumer）角色。例如：服务A可以在调用服务B的同时，也去调用服务C，而只要整个请求链是完整的，那么服务A就能够对发起请求的客户端做出响应。
微服务架构能够给我们的系统带来很多方面的好处，其主要能力包括：使用不同的技术栈、独立地进行部署、一次只解决一个小问题等。但是，由于它在通信和管理上的复杂性，一般使用微服务的成本会比较高。而且在一个或多个服务出现问题时，微服务则会变得更加复杂。如果没有掌握良好的、且有意义的日志的话，你都无法回答诸如：哪个服务、为什么、和在什么情况下失败了等问题。
老实说，我本人最憎恨那些由于糟糕的日志策略，所导致的一些“未知”的系统错误。下面我们和您分享一些，自己在与微服务打交道时总结出的各种最佳实践。
用唯一性ID来关联各个请求
请回想一下我们上面提到的服务A、B、C之间的请求调用链。在实践中，我们应当给每一个调用分配一个唯一性的ID，以便标识出每一个请求。
设想您正在记录每个服务的访问与错误日志。如果您发现在服务B上有错误，那么您就能知道该错误是来自于服务A、还是服务C。
如果错误信息足够详细的话，您也许不必去重现错误。但是多数情况并非如此，您必须通过正确的方式，将各个服务（如服务B）中的所有请求进行错误重现。因此，如果您发现了某个与之相关联的请求，那么您只需要在日志中寻找出它所对应的ID便可。随后，您可以顺藤摸瓜地从系统中将那些主要请求的某个部分，从服务的全量日志中截取出来。接着，您就可以知道是哪项服务的主请求花费了最多的时间。其可能性包括：可能是某项服务使用到了缓存、或是某项服务不止一次调用了其他服务、以及其他有趣的细节。
在响应中包含唯一性ID
微服务的用户可能会不止一次地碰到同一个错误。面对这样情况，您应该乘机对客户端可能接收到的响应进行编码，以便它能够将一个唯一性的ID，连同与该错误相关的任何其他有用的信息都传递出来。当然，这个唯一性的ID完全可以和我们在上面所提到的相关请求保持一致。
因此，在响应的有效载荷中包含与请求相关的唯一性ID，将有助于您和您的客户更迅速地发现各类问题。同时，您也可以获悉请求日期、时间和其他细节上的参数，以便您能够更好地理解自己所碰到的问题。另外，您还可以将请求的ID，添加到诸如“请联系服务管理员，并报告该问题。”之类的常见补充性错误信息之中，以便深入了解到底是什么原因引起该错误，进而防止它在未来再次发生。
发送日志到集中的位置
在此，让我们假设您已经对各种有用的日志信息进行了分类。下一步，我们就需要将各类日志发送到一个集中化的位置。
试想一下：如果您每次都需要登录到各个相互单独的服务器上，以来读取不同的日志信息，那么您将不得不花费更多的时间去试图关联这些问题。这远不如您登录到某一个位置，并一站式地访问到所有的日志，以定位问题。此外，您的系统通常会随着时间的推移，而变得日趋复杂，而各项微服务的数量也会节节攀升。同时，您的各种服务可能会分处不同的服务器或提供商，这都会让形势变得更为复杂。
因此，集中式存放日志正在成为业界的常规方法，特别是当您的服务工作在云端、容器、或其他混合环境之中，而某些服务器可能会在无任何通知的情况下下线的时候。例如，在出现异常错误，或是内存的消耗水平已经达到100％时，某些容器就会被终止运行。
您可以在服务器中断之前，通过设置代理，每五分钟推/拉一次日志，来解决此类问题。您也可以在服务器上配置一个cronjob（定时任务）、sidecar container、或是一个与其他进程共享的文件位置，来集中化各种日志。为了避免日志被篡改，您还可以自行构建一套解决方案，具体请参见链接：https://blog.scalyr.com/2017/11/log-management-need/。
可见，将所有服务的日志都集中到一处，会有助于您更容易、且有效地定位各种关联问题。
结构化您的日志数据
在具体实践中，我们很难为所有的日志数据预先定义好格式。有些日志可能需要比其他日志更多的字段，相反这些字段可能会对那些不需要的日志来说不但多余、而且浪费字节数。微服务架构是通过使用不同的技术堆栈，来解决此类问题的。不过，这会影响每个服务的日志格式。例如：某一个服务可能是用逗号来分隔不同的字段，而其他日志则使用的是管道或命名空间。
上述方法显然比较复杂。因此，我们可以通过将自己的日志数据构建成一套标准的格式，如：JavaScript Object Notation（JSON，https://www.json.org/），来简化解析日志的过程。JSON允许您拥有多层次的数据。在必要的时候，您可以在单个日志的事件中获取更多的语义信息。
同时，此法也使得对于特定日志格式的解析更加直接。通过对数据采取结构化，就算您的日志里有各种不同的字段，其格式也会变得更加标准。籍此，您也可以在集中化的位置上创建各种搜索，例如：检索包含有500条及以上，“HTTP_CODE”字段的日志信息。可以说，使用结构化的日志方式既能让您的微服务日志实现标准化，又不失灵活性。
