集装箱时代的分布式记录(第二部分)

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

源端聚合模式

第一个问题是我们是否应该汇总 数据的  来源 - 在服务方面。答案是权衡的问题。

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

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

现在我们来看看源端聚合的折衷。

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

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

目标端聚合模式

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

仅来源聚合

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

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

源和目标聚合

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

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

冗余

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

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

缩放模式

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

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

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

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

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

本文的版权归 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

如何实现系统的可扩展性和高可用性

概述 可扩展性,高可用性和性能 可扩展性,高可用性,性能和关键任务这些术语对不同组织或组织内的不同部门来说意味着不同的事情。它们经常被互换,造成混乱,导致管理...

45010
来自专栏Hadoop数据仓库

HAWQ技术解析(十八) —— 问题排查

(原文地址:http://hawq.incubator.apache.org/docs/userguide/2.1.0.0-incubating/trouble...

1957
来自专栏杨平安的专栏

微信 PaxosStore:海量数据冷热分级架构

导语 本文整理自笔者在“腾讯大讲堂”的演讲。 作者介绍:杨平安,来自广州的微信事业群,在腾讯已经工作五年。 主要分享内容: 为何公司卓越研发金奖花落PaxosS...

1.2K6
来自专栏大数据和云计算技术

阿里HBase的数据管道设施实践与演进

摘要:第九届中国数据库技术大会,阿里巴巴技术专家孟庆义对阿里HBase的数据管道设施实践与演进进行了讲解。主要从数据导入场景、 HBase Bulkload功能...

1042
来自专栏韩伟的专栏

高性能服务器架构思路:缓冲清理策略(二)

虽然使用缓存思想似乎是一个很简单的事情,但是缓存机制却有一个核心的难点,就是——缓存清理。我们所说的缓存,都是保存一些数据,但是这些数据往往是会变化的,我们要针...

9K0
来自专栏互联网技术栈

微服务系列-Spring Cloud优质项目推荐

Spring 配置管理工具包,让你可以把配置放到远程服务器,集中化管理集群配置,目前支持本地存储、Git以及Subversion。

916

我与Apache Storm和Kafka合作的经验

对于这个学派的新手来说,我会尝试用非常简单的方式去解释。基于海量写入的扇出架构尝试在写入时使用所有业务逻辑。初衷是为了给每个用户及用例准备好视图;当有人想要读取...

2062
来自专栏IT大咖说

基于Go的MongoDB实时同步工具及 Docker 化实践

摘要 讯联数据高级软件工程师马艳云分享了基于Go的MongoDB实时同步工具Magisync及 Docker化实践。 ? Magisync是什么 Magisyn...

3554
来自专栏.NET技术

正确理解CAP定理

  CAP的理解我也看了很多书籍,也看了不少同行的博文,基本每个人的理解都不一样,而布鲁尔教授得定义又太过的简单,没有具体描述和场景案例分析。因此自己参考部分资...

912
来自专栏数据和云

性能优化:MySQL 性能提升之降龙十八掌

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

1453

扫码关注云+社区