如今,许多公司已经在软件开发中采用了快速迭代的新规范,并以马克扎克伯格的著名格言“快速行动,打破常规”为生。这种心态导致软件设计中面向服务的架构 (SOA) 方法越来越流行。特别是,我们看到了微服务的兴起,这是一种 SOA 风格的软件开发方法,公司将业务逻辑部署在小型独立服务中。
虽然微服务方法有几个优点,例如降低风险、部署速度和可扩展性,但它也带来了一系列独特的挑战。
由于软件开发团队通常每天部署数十、数百甚至数千个功能,微服务的主要运营挑战之一是确保新功能不会破坏微服务中的任何内容,更重要的是,要确保对一个微服务的更改不会破坏其他依赖的微服务。
在本文中,我们将讨论用于解决这种复杂性的一种技术:服务网格的异常检测。
什么是服务网格?
面向服务的架构需要专门的工具来控制服务到服务的通信。特别是,随着微服务之间的网络通信规模和复杂性的增长,手动管理部署、解决问题和维护集群安全变得不可能。服务网格技术为您提供了额外的洞察层,并提高了可观察性、流量管理和部署管理,并增强了网格内的安全性。创建了许多工具和标准来解决服务网格的复杂性;这些总结在第 5 层网站. 如今,OpenTelemetry、Envoy 和 Prometheus 等 CNCF 项目变得非常流行。
开放遥测:开放遥测将自己描述为一个开源的可观察性框架。特别是,它提供了一组 API、库、代理和收集器服务,以从您的应用程序中捕获分布式跟踪和指标。
Envoy Proxy:最初由 Lyft 公司构建,使者是专为云原生应用程序设计的开源边缘和服务代理。他们着手解决我们讨论过的微服务的两个主要问题:网络和可观察性。
普罗米修斯:普罗米修斯是另一个用于事件监控和警报的开源解决方案。它从配置的目标收集实时指标,评估规则表达式,显示结果,并可以触发警报。
Service Mesh 监控范式的缺点
服务网格监控工具的主要问题之一是,当您拥有大量微服务时,可观察性是不切实际且不切实际的。
在当前的服务网格监控范式中,这些工具有一些组件负责满足服务级别协议。例如,服务网格Istio收集以下类型的测量以提供整体服务网格可观察性:
指标:这些是根据 Envoy 代理统计信息生成的。有些被 Istio 定义为监控的“黄金信号”(延迟、流量、错误和饱和度)
分布式跟踪: Istio 还为每个服务生成分布式跟踪跨度
像 Istio 这样的开源项目在收集允许开发人员创建仪表板的指标方面非常有用。如果您正在处理较小的应用程序,并且有专门的团队监控和调整警报,则此过程很有效。但是,如果您正在处理具有大规模部署的项目,则这些手动过程的效率要低得多。
没有可视化监控多个集群的能力,服务网格技术需要超越“观察”,转向自动化异常检测。
服务网格异常检测
与传统监控方法相比,采用
机器学习的异常检测有很多好处,例如自动学习每个新微服务的行为模式,并在检测到重大变化时自动发送警报。这些功能使您可以减少检测异常所需的时间,并有助于防止进一步分布。
基于 AI 的异常检测与整个服务网格集成,以跟踪高级 KPI 以及来自每个微服务的最细粒度的信号。
服务网格监控的异常检测仍然是一个新兴领域,但如果您正在查看可用的解决方案,请记住以下几个注意事项:
完全自治:如前所述,大规模部署的服务网格无法手动监控,因此首先要考虑的是确保解决方案能够实时独立跟踪和学习数据。
误报率:接下来,您要寻找误报率低的解决方案,否则会导致不必要的噪音并造成警报疲劳。
相关性:最后,基于 AI 的异常检测解决方案应该能够自动学习网格的拓扑结构并连接点。
使用异常检测解决方案,您不仅可以收到有关严重事件的警报,还可以查看已纠正异常的按时间顺序排列的列表。这意味着您可以轻松追溯异常的根源,以确保它不会再次发生。
正如我们所讨论的,服务网格监控已成为管理微服务的重要组成部分,因为它们提供了对服务到服务通信的洞察。然而,随着微服务的部署开始增长,可观察性变得越来越不切实际。
将服务网格技术与基于 AI 的异常检测解决方案结合使用,您可以检测实时事件并可靠地缩短解决问题的时间,从而解决了这一挑战。
相关帖子DA内容精选
- 大厂数据分析面试指南!来自亚马逊、谷歌、微软、头条、美团的面试问题!
|