观察者效应对微服务架构的影响

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

应用程序可用性不仅仅是“正在运行”的衡量标准。许多应用程序都可以声明该状态。从技术上讲,它们正在运行并响应请求,但用户肯定会认为其速度下降。这是因为加载时间过长可能(并且将会)被解释为“不可用”。这就是为什么将确保 应用程序可用性视为需要关注其所有复合部分的重要性:可伸缩性、性能和安全性。

当我们考虑如何确保规模、性能和安全性时,悖论就开始了:监控和测量。也就是说,我们 观察 有关网络、计算和应用程序资源的某些特征,以了解应用程序的状态。这必然意味着我们必须与那些需要监控和测量的组件进行交互,因此我们进入了物理世界。

观察者效应简单地说,观察某物必然会改变被观察的事物。当它是有知觉的生物时,这通常表现为霍桑效应,即当有知觉的生物知道自己被观察时,他们会改变自己的行为。来吧,在你的孩子身上试试看。如果他们知道他们正在被监视,他们就是天使。但是一分钟后转过身去,砰!他们毁掉了游戏室,爆米花散落一地。

在 IT 领域,效果同样活跃:

信息技术 中, 观察者效应 是在流程运行时观察流程输出的行为的潜在影响。例如:如果进程使用日志文件来记录其进度,则进程可能会变慢。此外,在进程运行时查看文件的行为可能会导致进程中出现 I/O 错误,进而导致进程停止。

另一个例子是通过在同一个 CPU 上运行被观察程序和被观察程序来观察 CPU 的性能,这将导致不准确的结果,因为观察程序本身会影响 CPU 性能(现代、大量缓存和流水线 CPU 尤其受到这种观察)。

-- https://en.wikipedia.org/wiki/Observer_effect_(information_technology)

测量系统容量和性能的行为*——比如一个应用程序或一个单独的微服务——通过消耗资源来改变它的状态,这反过来会增加总负载,根据操作公理 #2 所说,最终会降低容量和性能。这是基于代理的监控一直不是 APM 首选的原因之一,因为代理在系统上的存在必然会降低容量和性能。

由于数学原因,观察者效应将对由微服务组成的应用程序产生特别的影响。如果测量和监控一个整体应用程序的行为会使性能降低 X,那么测量和监视基于微服务的应用程序的行为将使性能降低更多 X。可以说对基于微服务的应用程序的影响是实际上不是每项服务 X,而是 X 的一部分,因为重点是以这样一种方式分发服务,即并非 所有 服务都以与整体应用程序相同的税率征税。如果微服务被用作单个应用程序的一部分,那将是正确的,但微服务的好处和目标用途之一是 重用 。这意味着多个应用程序或 API 将使用每项服务,从而增加了衡量和监控每项服务的容量和性能的需求。

这就是架构和技术的重要性所在。微服务性能和负载的测量和监控的设计和实现成为确保可用性的重要部分。虽然每个控制点——API 网关或服务发现系统或负载 平衡器或代理 - 可以测量它为其执行分配任务的每个微服务,它可能会不必要地增加观察者效应对微服务的影响。这是因为大多数控制点都采用 主动 方法来监视和测量负载和性能。也就是说,他们有目的地轮询系统以查询系统的状态和响应能力。他们使用 ICMP ping,他们使用 TCP 半开放,他们使用 HTTP 内容请求来收集他们需要的数据。

这些方法中的每一种都与所讨论的系统相互作用,从而实现了观察者效应的预测。收集这些数据的系统越多,发生的交互越多,观察者效应的影响就越大。

这意味着必须更加关注微服务监控和测量的方式——包括用于实现它的技术。

被动的测量和监控方法提供了一种避免观察者效应的方法。这是因为它们——顾名思义——被动地观察状态和衡量性能,而不主动探测系统以获取此数据。这通常是通过利用负载均衡器和代理等中间系统来实现的,请求和响应必须通过这些中间系统来捕获状态信息。

当然,中介使用这些测量值来管理负载分配,但也通过 API 公开以供其他系统收集。从中介收集的那些统计数据很可能*对性能没有影响,因为它们由独立于中介实时执行的系统管理。

在构建基于被动监控和测量技术的解决方案时,重要的是要考虑通过 API 向外部系统提供统计数据的可用性。如果执行监视和测量的系统可以使用它收集的数据,那么其他系统就不需要直接测量每个服务的状态和性能,并进一步减少观察者效应对整个系统的影响。

这是 DevOps 的协作方面可以提供重要价值的方式之一。随着运维和网络运维共同努力建立一种更有效的方法来衡量和监控微服务等系统的可用性,他们可以提供有价值的输入,直接使用 API 或通过与其他已建立的系统集成来开发这些统计数据。

在运营层面,这项工作还建立了一个更集中的位置,从中可以(实时)检索与性能相关的数据并用于触发其他操作,例如自动缩放(向上和向下)——这是迁移到在微服务架构中,使用和服务的数量和可变性需要比其单一的前辈更自动化的操作方法。

* 这不太适用于虚拟网络设备,因为它们专门设计用于分离可操作和可操作的系统,以确保管理(测量、监视、修改)系统不会影响可操作系统的性能。这是从他们在硬件中的根基继承而来的,其中“熄灯”管理是一项要求。