摘要：由于容器是无法改变和一次性的，所以存储在容器中的日志会随着容器的失效而删除。收集节点存在于容器中，同时将结构化好的日志数据实时或者小批量的传输到合并节点。
微服务与大问题
容器服务和微服务已经越来越多的被现代科技公司所采用。当你需要提供支持跨平台和多应用的服务时，采用微服务的服务架构是非常重要的。.像Docker一样的容器服务，因为可以提供高效的统一资源管理和让服务保持更好的独立性，并且有比虚拟机（Virtual Machines）更好的便携性（portability），所以更适合微服务的开发。
但是引入微服务和容器服务的同时也带来了各种问题。下图我们来看一下微服务架构和现在并不怎么流行的前辈，“统一型架构”（monolithic architecture）
。
统一型架构虽然没有足够的灵活性和可扩展性，但是，它是一个整体（unity）。为了了解它的重要性，我们来从业务需求的角度了解一下我们需要收集（collect）和整合（aggeregate）多少种不同的日志。你可能想知道你的用户最常访问的网页有哪些，或者哪个按钮和广告最容易被点击。你也可能想对比从移动应用端获取的销售数据，或者作为一个游戏开发者，你想了解用户玩儿游戏时候的数据。你也可能需要收集用户手机上的操作日志。假设你的团队在做流式分析或者事件影响力分析，这时就需要对比计算结果和历史数据。IoT数据，SaaS数据，公共开放数据……等等等等。
统一型架构产生的数据，理论上来说，是很容易被跟踪和收集的。由于系统在定义的时候就是中心化的，它所产生的日志可以通过定义相同的格式规则来定义。相反，微服务却不是这样。日志又不同的服务产生，它们都有着各自的格式，或者有些根本没有格式！由于这些原因，收集并“消化”这些来自于不同服务的日志，并转换成一个可读的格式，是一个非常复杂并且难以解决的数据工程问题。
容器时代，我们必须重新考虑如何记日志
“如何记日志？“ ，这是我们开始讨论容器服务必须先讲的。 “容器化（Containerization）”，是一项可以使基于微服务架构开发的服务更高效的利器。容器会使用比虚拟机（VM）更少的资源，更不用说实体机了。容器可以是使我们的服务更接近我们的客户，提高操作速度。并且由于容器之间相互独立，各服务之间的依赖问题也减少了（并没有完全消除）。
但是，这些使容器服务更适合微服务架构的有点却在记日志和数据整合的过程中带来了更多的麻烦。通常来说，日志都会有标记IP地址，来表明它来自于哪台服务器。这种情况在容器服务中并不存在，容器服务切断了服务器和用户之间的固定映射关系。另外一个问题是日志的存储问题。由于容器是无法改变（immutable）和一次性（disposable）的，所以存储在容器中的日志会随着容器的失效而删除。你可以选择把日志都存在主机端而不是在容器里，但是你可能会同时启动多个容器和服务。如果服务器存储空间满了怎么办？那么我们该如何获取这些日志？用控制台直接看？太棒了，又得安装一个新组件（翻白眼）。或者我们通过rsync、ssh或者tail来查看日志。那么我们要确定我们这些常用的工具是在容器里都安装过的……
突破日志瓶颈：智能数据架构这个问题是没办法绕开的。在容器化微服务的世界里，我们必须重新思考如何记日志。
日志必须要以下特征:
在源头就完成标记（labeled）和解析（parsed）
以最快的速度推到目标存储落地
让我们来看看智能数据架构是如何工作的。
像我们之前提到的，来自于不同地方的日志可能都有着不同的日志结构和格式。对于数据分析来讲，处理原始日志就是一场噩梦。收集节点（Collector Nodes）通过将原始日志转换为结构化数据来解决这个问题。例如：JSON中的KV数据，信息包（MessagePack）或者其他标准的数据格式。
收集节点存在于容器中，同时将结构化好的日志数据实时（或者小批量）的传输到合并节点（Aggregator Nodes）。合并节点的工作是将小量的数据合并成一个容易被处理的数据流到存储层（Store），在存储层的数据是被持久化存储的。
如上所述的是一种数据架构，不是所有人都清楚他们的数据也需要一个架构，但是在容器微服务的角度，我们必须这样做。
如果想要你的数据架构有更好的弹性扩展能力（scalable and resilient），下面几点是必须要考虑的：
网络情况。当我们有这么大量的数据在网络中进行交换的时候，我们需要一个虚拟的“网络交警”来保证我们的网络不会超载，不会丢失数据。
CPU负载。在源头解析数据和在合并节点格式化数据是一项CPU密集型工作。再次强调，我们需要一个稳定的系统来管理这些资源，来保证我们的CPU不会超载。
冗余性。弹性扩展意味着冗余储备。我们需要保证我们的合并节点是冗余的（多余实际需求的），从而能保证我们遇到节点失败时可以快速切换避免数据丢失。
控制延迟。我们没办法避免系统可能产生的延迟。如果我们没法逃避这个问题，我们必须尝试把潜在的延迟放在可控的范围。
现在我们了解了我们应该做什么了，那我们来看看不一样合并方式对于服务架构的影响。
数据源侧合并模式（Source-Side Aggregation Pattern）首先我们要问的问题时，我们如何据定是在服务端做数据合并还是在数据源做数据合并？答案是，视情况而定（译者注：废话）。
服务端数据合并框架带来的好处是简洁，但同时也付出了很大的代价。
数据合并位置固定。如果你改变了你合并节点的位置，你必须重新调整所有的独立收集节点的配置。
无法控制的网络连接数量。还记得我们提到要谨慎控制网络流量不要超载么？这种架构就会导致网络超载。我们在数据源侧做合并是网络效率更优的选择，因为减少了大量的网络通讯和数据传输。
合并节点高负载。不仅仅网络会超载，这种架构也会导致合并节点CPU超负荷，导致宕机造成数据丢失。
现在我们来看看另一种方案。
源头聚合的方式有一个缺陷：就是会导致资源紧张。它需要在每个主机上都存在一个额外的容器，但是这个额外的资源也有很多好处：
更少的链接数。意味着更少的网络传输。
更低的合并节点负载。由于资源消耗被发散到了你的整个的数据架构上，你遇到多带带合并节点超载的几率大大减少，也会带来更多的数据稳定性。
更少的配置项。由于每个合并节点的地址对于每个采集节点来说都是“localhost”，配置起来就变得非常简单。目标地址只需要在本地合并容器声明一次就够了。
高度灵活配置项。简化的配置项让你的数据架构高度“模块化”。你可以随意改变你架构中的核心内容。
目标侧合并模式（Destination-Side Aggregation Pattern）我们来换种思路，不仅仅选择在源头侧做数据合并，还可以选择在目标侧做同样的事情。为什么要这么做呢？就是在实际业务中的一种权衡之举。
仅源头侧合并就像在源头端做合并一样，会有以下几点问题：
目标端做的改变会同时影响到源头段。这里同样会遇到我们之前的问题，当我们在源头段没有合并节点的时候，配置项就会变的非常复杂。如果目标端IP地址变化，所有的配置都需要重新生成。
更差的性能。在目标侧没有合并节点会导致我们的存储系统有很多链接并发的问题。
源头侧和目标侧合并最优化的配置方式是同时在源头侧和目标侧都存在合并节点。再次重申，我们的妥协会导致需要复杂的配置来控制多个节点，但是有点也是显而易见的：
目标侧和源头侧分离，没有互相影响。
更好的性能。当把源头侧的合并节点分离，我们可以更好的调试合并节点并且减少对于存储层的请求量，使我们在使用标准的数据库的时候避免遇到性能和扩展的问题。
冗余性源头侧聚合带来的最大一点的好处就是容错性。在真实业务场景中，服务器会时不时的宕机。导致宕机的原因就是，大量持续的处理由微服务架构构成的大型系统的日志。当遇到这种情况的时候，在宕机时产生的数据会被永久的丢失。如果你的服务很久没有恢复，即使你在源头端留有缓存（大部分日志平台都会在源头侧留有至少一分钟的缓存），这些缓存也会溢出并造成永久的数据丢失。
目标侧合并由于增加了冗余性从而提高了容错性。因为在容器和数据库之间增加了一层，多次拷贝的数据可以发送给多个合并节点，从而减少了并发链接导致数据库过载的可能性。
扩展模式负载均衡是数据架构需要认真考虑的一个重要特性。处理负载均衡的方法有很多种，但是我们在这里需要关注的是如何判断我们是该向上扩展（scaling up），比如，使用单一的HTTP/TCP的负载均衡器的时候，它通过控制大量的worker和一个超长队列来做负载均衡。还是该横向扩展（scaling out）当处理多个客户端合并节点做负载均衡的时候，只能简单的增加节点来控制规模。
那种负载平衡的方式更好？再次强调，要视情况而定。需要根据你的系统规模来确定该使用哪种方法。至少从概念上来说，向上扩展比横向扩展要简单的多。因为如此，很多创业公司都会这样做。但是向上扩展的在业务量急剧上升的时期，会更加频繁的在GC阶段出问题 （your service scales to 5 billion events per day and suddenly starts crashing every time it has to do garbage collection?）。
横向扩展更加复杂，但是理论上讲提供了无限的存储空间，你可以一直增加合并节点。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/28005.html
摘要：消息队列技术介绍后端掘金一消息队列概述消息队列中间件是分布式系统中重要的组件，主要解决应用耦合异步消息流量削锋等问题。的内存优化后端掘金声明本文内容来自开发与运维一书第八章，如转载请声明。 消息队列技术介绍 - 后端 - 掘金一、 消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系...
摘要：应用的研发上线运维运营形成闭环，顺利完成从对内服务到公共平台的升级。从功能角度，只能支持静态方式设置反向代理，然后，而平台有服务对应的后端服务和端口是有动态调整需求。架构上是基础组件需要进行升级，数据访问层日志监控系统等。 介绍 MaxLeap早期是一家研发、运营移动应用和手机游戏公司，发展过程中积累了很多通用组件。这些组件很大程度帮公司在移动研发过程中节省了时间和成本，...
摘要：阿里云上领域各个产品最终目标是为了对以上各个组件进行有效监控。阿里云的解决方案地图基于今天的云上的应用架构，阿里云的解决方案地图如下所示。其他阿里云服务包括缓存，等。阿里云解决方案地图以下表格对阿里云解决方案进行总结。 摘要： PM是近5年来伴随着云技术、微服务架构发展起来的一个新兴监控领域。在国内外，无论是云厂商(如AWS, Azure，等)还是独立的公司(Dynatrace, Ap...
摘要：容器云将支持应用的一键式部署交付，提供负载均衡，私有域名绑定，性能监控等应用生命周期管理服务。本容器云平台，对接持续集成发布系统。 前言 在移动互联网时代，新的技术需要新技术支持环境、新的软件交付流程和IT架构，从而实现架构平台化，交付持续化，业务服务化。容器将成为新一代应用的标准交付件，容器云将帮助企业用户构建研发流程和云平台基础设施。缩短应用向云端交付的周期，降低运营门槛。加速向互...
摘要：容器云将支持应用的一键式部署交付，提供负载均衡，私有域名绑定，性能监控等应用生命周期管理服务。本容器云平台，对接持续集成发布系统。 前言 在移动互联网时代，新的技术需要新技术支持环境、新的软件交付流程和IT架构，从而实现架构平台化，交付持续化，业务服务化。容器将成为新一代应用的标准交付件，容器云将帮助企业用户构建研发流程和云平台基础设施。缩短应用向云端交付的周期，降低运营门槛。加速向互...
阅读 1986·2021-09-22 15:25
阅读 3450·2019-08-30 12:48
阅读 1953·2019-08-30 11:25
阅读 2220·2019-08-30 11:05
阅读 591·2019-08-29 17:28
阅读 3146·2019-08-26 12:16
阅读 2474·2019-08-26 11:31
阅读 1481·2019-08-23 17:08
