欢迎回到我们的系列。在第一部分中,我们谈到了微服务和容器的最近兴起。我们介绍了这种类型的体系结构引起的日志记录问题以及可能的解决方案 - 聚合。既然之前我们已经介绍了这些,现在让我们来看看服务架构中的一些不同的聚合模式。
第一个问题是,我们是否应该汇总 数据的 来源 - 在服务方面。答案显然是不唯一的。
没有 源聚合的聚合服务框架的最大好处 是简单。但是,简单的代价是:
现在我们来看看源端聚合的另一面。
在源头上聚合有一个缺点:这是一个更多的资源密集型。它需要每个主机上有一个额外的容器。但是这个额外的资源带来了几个好处
无论我们是否在源端聚合,我们也可以选择在目的端分别有聚合器。我们是否应该这样做,又是一个折中的问题。避免目标聚合限制节点的数量,从而导致更简单的配置。
但是,就像在资源方面一样,避免在目标方面的聚合带来了成本:
最佳配置是在源和 目标端都进行聚合 。 再一次地,折中的是,我们最终得到更多的节点和稍微更复杂的配置。但好处很明显:
源端汇聚的另一个主要优势是 容错性。 在现实世界中,服务器有时候会停下来。处理在一个大型的微服务系统中产生的服务日志的不断,重负载使得服务器崩溃的可能性更大。当发生这种情况时,停机期间发生的事件可能会永远丢失。如果系统停留时间足够长,甚至源端缓冲区(如果您正在使用带有源端缓冲区的日志平台 - 一分钟内会更多)将会溢出并导致永久数据丢失。
目标端聚合通过增加冗余来提高容错能力 。通过在容器和数据库之间提供最后一层,可以将相同的数据副本发送到多个聚合器,而不会使用并发连接压倒数据库。
负载平衡 是另一个重要的数据基础架构考虑 处理负载平衡有上千种方法,但是我们关心的重要因素是放大之间的权衡 ,即使用单个HTTP / TCP负载均衡器来处理比例大小的队列和大量工作人员,或者 向外扩展,在负载平衡许多客户端汇聚节点分布,以循环的方式,和规模管理通过简单地添加更多的聚合。
哪种类型的负载均衡最好?再次,这取决于。您使用的方法应该取决于系统的大小,以及是否使用目标端聚合。
至少在概念上,放大比放大略显简单。正因为如此,它可以适合初创公司。但是,在最坏的时候,企业倾向于粉碎的规模有限。当你的服务每天增加到50亿个事件,并且每次需要做垃圾收集时突然开始崩溃,你不觉得讨厌 吗?
扩展比较复杂,但是(理论上)提供了无限的容量。您始终可以 添加更多聚合节点。
因此,我们介绍了微服务和容器可以创建的日志记录问题,以及聚合模式如何帮助解决这些问题。留意系列的最后一集,我们将在这里详细介绍Fluentd以及它在缓解这个过程中扮演的角色。