欢迎回到我们的系列。在第一部分中，我们谈到了微服务和容器的最近兴起。我们介绍了这种类型的体系结构引起的日志记录问题以及可能的解决方案 - 聚合。既然之前我们已经介绍了这些，现在让我们来看看服务架构中的一些不同的聚合模式。

源端聚合模式

第一个问题是，我们是否应该汇总 数据的 来源 - 在服务方面。答案显然是不唯一的。

没有 源聚合的聚合服务框架的最大好处 是简单。但是，简单的代价是：

• 修正了聚合器（端点）地址。 如果您更改聚合器的地址，则必须重新配置每个收集器。
• 许多网络连接。 还记得我们说我们需要小心不要超载我们的网络？这就是网络过载发生的原因。在源端聚合我们的数据要比在目的端聚合更有效的网络效率 - 导致网络支持的套接字和数据流更少。
• 聚合器中的高负载。 源端聚合不仅会导致网络流量过大，而且会导致聚合器中的CPU过载，造成数据丢失。

现在我们来看看源端聚合的另一面。

在源头上聚合有一个缺点：这是一个更多的资源密集型。它需要每个主机上有一个额外的容器。但是这个额外的资源带来了几个好处

• 更少的连接。 较少的连接意味着较少的网络流量。
• 较低的聚合器负载。 由于此资源成本分散在整个数据基础架构中，因此您将不会有任何单个聚合器超载的机会，从而减少数据丢失的机会。
• 容器中的配置较少。 由于每个收集器的聚合器地址是“本地主机”，所以配置被大大简化。目标地址只需要在一个节点（本地聚合容器）中指定。
• 高度灵活的配置。 这种简化的配置使您的数据基础架构高度“模块化”。您可以将服务交换到您的内心。

目标端聚合模式

无论我们是否在源端聚合，我们也可以选择在目的端分别有聚合器。我们是否应该这样做，又是一个折中的问题。避免目标聚合限制节点的数量，从而导致更简单的配置。

仅来源聚合

但是，就像在资源方面一样，避免在目标方面的聚合带来了成本：

• 目标端的更改会影响源端。 这是我们在源端没有聚合器时所看到的配置问题。如果目标地址更改，则必须重新配置源上的所有聚合器。
• 更糟的表现。 目标端没有聚合器会导致许多并发连接和写入请求到我们的存储系统。取决于您使用哪一个，几乎总是会对性能产生重大影响。事实上，这是系统中最经常发生的部分，即使是最强健的基础设施也是如此。

源和目标聚合

最佳配置是在源和 目标端都进行聚合 。** 再一次地，折中的是，我们最终得到更多的节点和稍微更复杂的配置。但好处很明显：

• 目标端更改不会影响源端。 这导致整体维护少得多。
• 更好的性能。 通过在Source方面使用单独的聚合器，我们可以对聚合器进行微调，并且在Store上的写请求更少，从而使我们能够使用标准数据库，而且性能和缩放问题更少。

冗余

源端汇聚的另一个主要优势是 容错性。 在现实世界中，服务器有时候会停下来。处理在一个大型的微服务系统中产生的服务日志的不断，重负载使得服务器崩溃的可能性更大。当发生这种情况时，停机期间发生的事件可能会永远丢失。如果系统停留时间足够长，甚至源端缓冲区（如果您正在使用带有源端缓冲区的日志平台 - 一分钟内会更多）将会溢出并导致永久数据丢失。

目标端聚合通过增加冗余来提高容错能力 。通过在容器和数据库之间提供最后一层，可以将相同的数据副本发送到多个聚合器，而不会使用并发连接压倒数据库。

缩放模式

负载平衡 是另一个重要的数据基础架构考虑 处理负载平衡有上千种方法，但是我们关心的重要因素是放大之间的权衡 ，即使用单个HTTP / TCP负载均衡器来处理比例大小的队列和大量工作人员，或者 向外扩展，在负载平衡许多客户端汇聚节点分布，以循环的方式，和规模管理通过简单地添加更多的聚合。

哪种类型的负载均衡最好？再次，这取决于。您使用的方法应该取决于系统的大小，以及是否使用目标端聚合。

至少在概念上，放大比放大略显简单。正因为如此，它可以适合初创公司。但是，在最坏的时候，企业倾向于粉碎的规模有限。当你的服务每天增加到50亿个事件，并且每次需要做垃圾收集时突然开始崩溃，你不觉得讨厌 吗？

扩展比较复杂，但是（理论上）提供了无限的容量。您始终可以 添加更多聚合节点。

因此，我们介绍了微服务和容器可以创建的日志记录问题，以及聚合模式如何帮助解决这些问题。留意系列的最后一集，我们将在这里详细介绍Fluentd以及它在缓解这个过程中扮演的角色。

翻译人：Shedray大数据专栏，该成员来自云+社区翻译社

原文链接：https://dzone.com/articles/distributed-logging-in-the-container-era-part-2-1

原文作者：Glenn Davis