海量微服务关联关系挖掘与告警拓扑展示

一、前言

1、微服务关联复杂性

在当前云原生与DevOps、PaaS技术应用背景下,微服务化是一个显著的特征。所谓微服务,简单来说就是将过去的大型单体应用按照功能职能,划定交互边界,拆分为一个个小型的微服务汇总而成最终的产品交付。

微服务带来的好处自不必多说,例如敏捷性、灵活扩展、轻松部署等。但是当整个云服务愈发复杂、架构愈发繁琐时,我们发现微服务的模式也存在一些缺陷,其中之一就是海量微服务的交互与关联问题

以笔者的实践为例,一些普通的单体工具服务,其分拆的微服务可能有30-50个之多,而对于综合交互的工具平台服务,最终的微服务数量可能会达到上千个!这其中微服务之间彼此关联、相互依赖,形成一种繁杂的网状交织结构。发现、分析具体微服务的关联关系迫在眉睫。

2、告警信息获取与展示

除了复杂的微服务关联关系外,海量的微服务所涉及的故障与告警也愈发难以观测和处理。

诚然,随着技术的进步,各种监控工具、观测维度愈发成熟,但同样带来了数据越来越多、越来越分散负责的问题。例如,对于一个微服务而言:

  • 基础设施层可能有对应的CPU、内存、数据库等指标监控;
  • 中间件层可能会有对应的Kafka队列、Redis等监控与告警;
  • 应用层可能会有调用链、接口异常调用状态码、日志关键字等监控告警;
  • 业务层可能会有诸如URL拨测、健康巡检等类型的监控与告警;
  • 各个环节还存在服务自定义的相关监控与告警(例如Prometheus监控与定义告警);

以笔者的实践看来,即使有告警智能汇聚于压缩的帮助,服务每天依旧要面对着成百上千、来自各个监控告警平台的告警提示,如何能直观的观测告警的来源、分布以及具体影响(爆炸半径),同样是一个需要重视和解决的问题。

二、服务拓扑构造

基于上述的论点,首先需要做的,就是尝试找出繁杂的微服务之间的关联关系。这里,我们主要通过以下几个维度做判断与构造,并最终做数据层面的融合。

1、基于架构设计

首先,服务的关联关系应该在最初的产品定义与设计时就应该有相应的规划与确定,这里主要是 “4+1视图”:分别为逻辑视图、物理视图、处理流程视图、开发视图,以及最后的场景视图。

  • 逻辑视图
    • 用于描述系统的功能需求,即系统给用户提供哪些服务;以及描述系统软件功能拆解后的组件关系、组件约束和边界,反映系统整体组成与系统如何构建的过程。在UML中由类图来表示。
  • 物理视图
    • 物理视图,也成为部署视图,开发出的软件系统,最终是要运行在物理或软件环境上。物理环境可能是服务器、PC机、移动终端等物理设备;软件环境可以是虚拟机、容器、进程或线程。部署视图就是对这个部署信息进行描述。在UML中通常由部署图表示。
  • 处理视图
    • 处理视图,又称过程视图、运行视图、行为视图。用于描述系统软件组件之间的通信时序,数据的输入输出。在UML中通常由时序图和流程图表示。
    • 运行视图的设计,最常见的是逻辑架构元素之间的交互关系,比如消息交互、服务调用或API调用。
  • 开发视图
    • 开发视图关注软件开发环境下实际模块的组织,反映系统开发实施过程。一个设计良好的开发视图,应该能够满足以下要求:通过逻辑架构元素,能够找到它所有代码和所有的二进制交付件 每一个代码源文件,都能够找到它所属的逻辑架构元素 每一个二进制交付件,都能够找到它集成了哪些逻辑架构元素。
  • 场景视图
    • 场景视图,也成为用例视图,即4+1中的1。从前面的图可以看到,4+1中的4个视图都是围绕着场景视图为核心的。它用于描述系统的参与者与功能用例间的关系,反映系统的最终需求和交互设计。在UML中通常由用例图表示。
      • 系统边界:有了边界,才能够确定系统的设计范围;同时,通过边界能够识别出系统需要与用户或其它系统进行交互;
      • 系统用户:明确的用户定义是系统需求分析的先决条件;
      • 功能和场景:通过识别出系统与用户或其它系统的交互,可以分析出系统需要提供哪些功能,以及这些功能存在哪些应用场景;

在完成上述4+1视图的设计过程中,其中的关键点之一就是确定系统功能与边界、并定义不同系统间的交互形式:API、数据流等
因此,在设计态我们能够完成服务间依赖关系的基本确定。

2、基于接口调用

除了设计态的关联关系外,我们还会从运行态的视角、以接口调用来判断。一般而言,设计态是较为理想的情况,实际使用时会根据现实情况做很多新接口的开放与使用,因此运行态的关联一般是更贴合实际的。

这里,假若服务A通过接口b调用了服务B,那么我们人为服务A和B是存在关联关系的,并且服务A依赖于服务B。

  • 接口网关注册
    • 在云的背景下,服务之间的接口对外暴露提供原则上均需要通过APIG网关来实现;
    • 对于服务A,假如其希望使用服务B的开放接口b,那么需要在APIG平台申请该接口的授权
    • 当服务B的接口b开放给服务A时,这些均在APIG平台操作与记录,逻辑抽象上看一条接口依赖就完成了;
    • 因此,基于整个网关的接口开放暴露于接口授权访问信息,就能够形成完整的服务依赖关系网;
  • 接口实际调用
    • 除了基于网关调用与授权的模式外,还存在不少直接调用接口的访问形式,这些信息通过调用链数据记录;
    • 对于服务A与服务B,若服务完成APM探针的配置,那么A与B之间所有的后台调用均在APM平台完成汇总与统计;
      • 这里,由于接口调用数据是海量的,因此通常会用到一些大数据分析工具,以完成单条调用到聚合调用的整理;
      • 聚合分析后,可以得到以服务视角的接口调用与被调用者,还能知悉接口本身调用量等信息;
    • 完成服务间的接口调用关系提取后,与网关注册信息做并集,即可得到更为正确与完成的关联关系网;
      • 这里还有一些质量改进专项:本身跨服务的接口访问是需要走网关的,直接调用存在很多安全、过载流控等风险;
      • 因此,对于这类接口,我们还可以反向推动服务去完成开放接口的规范授权与使用。

3、关联重要等级

通过架构设计与接口调用的方法,我们虽然能获取较为全面的服务间依赖关系网络,但是对于一个服务而言可能会有十几个关联依赖服务、上百条依赖关系,如何找出其中具体重要的依赖于被依赖关系

  • 服务A与服务B在设计时考虑了某种依赖关系,但实际应用落地时却发现该依赖属细枝末节,并不重要;
  • 服务B虽然给服务A授权了接口b,但可能出现两种情况:
    • 服务A调用量非常低,近乎为0;
    • 服务A调用量比较高,但接口b对于A而言并不重要(例如普通的健康检查接口),即使挂了对A的核心特性并无影响;
  • 服务A和B均依赖于服务C,但服务A是普通内部服务,服务B是核心对外服务;

上述的问题旨在说明:服务之间的关联关系是有权重之分的,识别判断这种权重也非常重要。对于权重等级的判断,我们一般通过如下几种方法:

  • 服务重要程度
    • 对于服务而言,一般会根据重要程度不同从高到低分级为T0-T4,依赖等级同样可以按照T0-T4进行划分;
    • 假如服务A通过接口b依赖于服务B:
      • 如果A的重要程度较高,接口b挂了对A会造成影响,那么此时的依赖b我们会认为是重要依赖;
      • 如果服务A只是一个低级别服务,即使整个服务A挂了也无妨,那么依赖b我们只会认为是一般依赖;
  • 接口重要程度
    • 核心接口定义
      • 对于接口而言,本身在做需求分解、API设计时,就会对接口的一系列形式、参数、属性与功能做完整定义;
      • 根据接口职能的不同,API本身也会按照T0-T4的等级进行划分;
      • 对于类似鉴权、核心数据查询等类型接口,如果失效了会造成非常严重的影响,对于这类接口我们会认为是核心依赖;
      • 对于类似健康度巡检类型的接口,即使挂了对调用方而言也不会影响核心功能,此时我们会认为是一般依赖;
    • 调用次数判断
      • 通过调用次数的多少,我们在某种程度上也可以判断接口的重要程度;
      • 调用次数多,一般而言就越重要;调用次数少,则不是很重要;
      • 当然,这里也一定存在例外,例如上面的健康检查类接口,可能1分钟就要调用多次,但本身重要程度并不高,因此这里还需要具体问题、具体分析,做进一步的人为标定;
  • 人为标定
    • 除了上述自动定义服务关联依赖等级外,我们一般也会从设计态做人为的依赖创建于等级标定;
    • 通常是一些非接口类依赖(例如数据面依赖),以及一些调用次数少、但重要程度较高接口等;

在完成了关联关系重要等级的确定后,对于繁杂的服务关联关系,我们在做展示与渲染是就可以很方便地突出重点,将其中的强依赖加粗、换用其他颜色进行呈现

三、告警关联展示

在完成服务关联关系的识别、构造与重要依赖标定后,我们对繁杂的微服务网便有了一个较为清晰的观测视角,也对整体的架构有了较为明确的认知。

除了上述的优势外,告警在服务关联关系图上的拓扑映射,能够很好地解决我们“海量的微服务所涉及的故障与告警也愈发难以观测和处理”问题,同时进阶的一些辅助定界与影响分析的手段也是提升质量看护的。

由于整体服务关联关系图本质上是一种有向图,因此对于图中的边与节点,其故障发生的告警映射分别对应“接口级别故障”以及“服务级别故障”。

同时,面对服务外部依赖可能失效的问题,我们需要有相应的依赖降级措施,避免故障进一步严重化、降低影响范围。

最后,除了故障告警的直接渲染展示外,我们还需要有一些故障定界与影响分析的手段,二者是很大的课题,这里仅做简单介绍。

1、接口级故障展示

  • 故障告警来源:日志、调用链状态码、拨测
  • 主要用来快速展示服务之间的连接故障情况
  • 渲染要点:
    • 根据告警发生与恢复情况,动态进行告警展示;
    • 根据告警等级,选择不同的颜色做提示标记;
    • 点击正在告警的有向边,能够进行数据下钻、展示具体告警内容(故障接口详情、状态码情况、返回值等)

2、服务级故障展示

  • 服务级故障本质上是接口级故障的父集,因为接口本身也一定属于该服务;
  • 故障告警来源:涉及服务问题的所有类型——基础监控、应用层监控、接口级故障等等;
  • 主要从来标记当前拓扑关系网中的所有故障点
  • 渲染要点:
    • 根据告警发生与恢复情况,动态进行告警展示;
    • 根据告警等级,选择不同的颜色做提示标记;
    • 点击正在告警的服务节点,能够进行数据下钻、展示当前服务相关信息(OnCall责任人、架构部署形式、所有故障告警详情等)

3、依赖降级

顾名思义,服务间依赖不可避免,但是对于某些核心业务的强依赖而言,并不能假定下游依赖是100%可靠的,在依赖发生时如何降低故障对自身服务的影响、避免故障持续升级,是需要关注的核心问题之一。

这里,我们以鉴权故障为例。
在笔者的实践中,曾亲历过由于中央鉴权服务的故障、导致上百个服务同时故障的现网事故发生,其中故障等级随着影响面的扩大、故障等级最终被定在了P1。

在分析复盘后,相关核心服务均要求对于鉴权认证服务须具备依赖降级能力:

  • 所谓鉴权服务,本质上就是根据用户角色、服务应用APPID等信息,提供机机场景或人机场景下对于资源访问的权限校验所需的Token;
  • 当鉴权服务故障时,在没有依赖降级的情况下,所有涉及到鉴权的服务请求均会报错、造成连锁反应;
  • 引入依赖降级后,服务会即使发现依赖的鉴权接口产生故障,此时:
    • 服务本身会对已有机机和人机鉴权token保留一段时间在缓存,维持访问的可用性;
    • 对于新增访问请求,在无鉴权token缓存的情况下,会做访问请求限流拦截、并做提示与用户安抚,避免报障激增升级;
  • 需要注意的是,此降级非彼降级,主要是一种“去依赖”、避免故障持续升级的手段;

4、定界与影响分析

在服务发生故障、产生告警时,除了及时通知到服务外,我们还有对故障的定界与具体影响做相关分析的诉求。

对于故障定界而言:

  • 所谓故障定界,即在故障发生时,尝试找到故障发生的根源服务与根源点所在;
  • 通过告警信息渲染的服务关联拓扑图,以及服务的上下游关系,我们能够直观识别故障的具体产生点;
  • 借助调用链的数据分析也能为定界提供信息参考;
  • 需要注意的是,故障定界是一个业界难题,拓扑渲染仅能作为参考,很多情况下故障根因未必是拓扑故障根节点;

对于影响分析而言:

  • 所谓影响分析,即在故障产生时,具体影响面情况(影响服务与影响用户等),方便控制爆炸半径、及时故障降级;
  • 通过服务接口故障传播调用链数据、接口被调用情况,来确定机机场景下故障影响的服务数;
  • 通过故障产生时接口错误日志中对应的用户信息,来确定人机场景下故障具体影响的用户数;
  • 通过全局服务关联与故障拓扑图,直观呈现故障影响面范围;

四、小结

云原生背景下的海量微服务带来的不仅是基于,更多的还有挑战。通过设计态与运行态的不同视角,对服务间关联关系进行挖掘发现,有利于化繁为简、识别真正重要的问题与潜在风险。同时,将各层级告警映射到服务关联拓扑之中,能够让我们快速发现与处理海量的微服务所涉及的故障与告警。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/665814.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

QEMU源码全解析 —— 内存虚拟化(2)

接前一篇文章: 本文内容参考: 《趣谈Linux操作系统》 —— 刘超,极客时间 《QEMU/KVM》源码解析与应用 —— 李强,机械工业出版社 QEMU内存管理模型 特此致谢! QEMU内存初始化 1. 基本结构 在开始介绍内存初始化…

H12-821_230

230.在VRP系统中,当在广播网络中的两台路由器互联接口的MTU不匹配,且接口配置了ospf mtu-enable时,则关于两台路由器邻居关系状态变化描述,正确的是以下哪一项? A.两台路由器的邻居关系可以进入Fu11状态 B.两台路由器的邻居关系状…

springboot153相亲网站

简介 【毕设源码推荐 javaweb 项目】基于springbootvue 的 适用于计算机类毕业设计,课程设计参考与学习用途。仅供学习参考, 不得用于商业或者非法用途,否则,一切后果请用户自负。 看运行截图看 第五章 第四章 获取资料方式 **项…

预充电阻原理作用,直流预充电电路设计指南

最初将电池连接到具有容性输入的负载时,当负载电容充电至电池电压时,会出现电流涌入。 对于大型电池(具有低源电阻)和强大的负载(输入端具有大电容器),浪涌电流可以很容易地达到 1000 A 的峰值。…

Ps:自动对齐图层

Ps菜单:编辑/自动对齐图层 Edit/Auto-Align Layers 自动对齐图层 Auto-Align Layers命令通过分析选中图层上的图像,识别出图像间的共同特征点(如边缘、纹理或特定标记等),然后基于这些特征点变换(移动、旋转…

阻塞队列(超详细易懂)

目录 一、阻塞队列 1.阻塞队列概述 2.生产者消费者模型 3.阻塞队列的作用 4.标准库中的阻塞队列类 5.例子:简单生产者消费者模型 二、阻塞队列模拟实现 1.实现循环队列(可跳过) 1.1简述环形队列 1.2代码实现 2.实现阻塞队列 2.1实…

探索前端开发框架:React、Angular 和 Vue 的对决(一)

🤍 前端开发工程师、技术日更博主、已过CET6 🍨 阿珊和她的猫_CSDN博客专家、23年度博客之星前端领域TOP1 🕠 牛客高级专题作者、打造专栏《前端面试必备》 、《2024面试高频手撕题》 🍚 蓝桥云课签约作者、上架课程《Vue.js 和 E…

webpack配置

一、很多基础方面的配置被vuecli所集成一般项目都是使用vuecli,不会真正的去从0-1进行webpack配置: 1、vuecli中的webpack基础配置: (1)入口文件默认在src/main;输出在dist; (2)集成了大量的插件和加载器:babel-loader 处理 JavaScript 文件、使用 css-loader 和 style-load…

基于控制台的购书系统(Java 语言实现)

📚博客主页:爱敲代码的小杨. ✨专栏:《Java SE语法》|《数据结构与算法》 ❤️感谢大家点赞👍🏻收藏⭐评论✍🏻,您的三连就是我持续更新的动力❤️ 🙏小杨水平有限,欢…

C++棋类小游戏2

今天给大家带来我花了1周时间自创的小游戏的升级版,博主还是一名小学生,希望大家提提意见。这是我写的最长的C代码,希望大家喜欢,不要抄袭,任何编译器都可以。 以前版本——C自创棋类小游戏-CSDN博客 C内容提示&…

苹果CMS挖片网升级版视频主题模版源码

自适应视频站正版高级挖片网收录模板,模板不错,是挖片网的升级版。 源码下载:https://download.csdn.net/download/m0_66047725/88799583 更多资源下载:关注我。

解决maven 在IDEA 下载依赖包速度慢的问题

1.idea界面双击shift键 2.打开setting.xml文件 复制粘贴 <?xml version"1.0" encoding"UTF-8"?> <settings xmlns"http://maven.apache.org/SETTINGS/1.0.0"xmlns:xsi"http://www.w3.org/2001/XMLSchema-instance"xsi:sc…

深度学习实战 | 卷积神经网络LeNet手写数字识别(带手写板GUI界面)

引言 在深度学习领域&#xff0c;卷积神经网络&#xff08;Convolutional Neural Network, CNN&#xff09;是一种广泛应用于图像识别任务的神经网络结构。LeNet是一种经典的CNN结构&#xff0c;被广泛应用于基础的图像分类任务。本文将介绍如何使用LeNet卷积神经网络实现手写…

Transformer实战-系列教程4:Vision Transformer 源码解读2

&#x1f6a9;&#x1f6a9;&#x1f6a9;Transformer实战-系列教程总目录 有任何问题欢迎在下面留言 本篇文章的代码运行界面均在Pycharm中进行 本篇文章配套的代码资源已经上传 4、Embbeding类 self.embeddings Embeddings(config, img_sizeimg_size) class Embeddings(nn.…

(已解决)spingboot 后端发送QQ邮箱验证码

打开QQ邮箱pop3请求服务&#xff1a;&#xff08;按照QQ邮箱引导操作&#xff09; 导入依赖&#xff08;不是maven项目就自己添加jar包&#xff09;&#xff1a; <!-- 邮件发送--><dependency><groupId>org.springframework.boot</groupId><…

vite打包原理

vite 工程化开发&#xff1a;打包工具 启动速度很快 核心原理还是webpack 把webpack封装了&#xff0c;把webpack对象封装了 和vue2整体结构几乎一致 webpack两种模式&#xff1a;开发&生产 代码打包编译&#xff0c;本地起一个web服务器实时预览编译后的结果 build 命令模…

2024.2.3

单向循环链表的头插 头删 尾插和尾删 //头结点插入 Linklist insere_element(Linklist head,datatype element) {Linklist screat();s->dataelement;if(NULLhead){heads;}else{Linklist phead;while(p->next!head){pp->next;}s->nexthead;heads;p->nexthead;}r…

太强了,AI数字人从制作到变现一次搞定

AI数字人从制作到变现 如果说GPT类大模型是我们人类的第二大脑&#xff0c;数字人就是我们人类在互联网上的第二个身体。随着 AI 的迅速发展&#xff0c;2024 年 AI 模型开始从大型语言模型向大型视觉模型转变。数字人技术作为其分支之一&#xff0c;正日益成为科技、娱乐、教…

Unity项目从built-in升级到URP(包含早期版本和2023版本)

unity不同版本的升级URP的方式不一样&#xff0c;但是大体流程是相似的 首先是加载URP包 Windows -> package manager,在unity registry中找到Universal RP 2023版本&#xff1a; 更早的版本&#xff1a; 创建URP资源和渲染器​​ 有些版本在加载时会自动创建&#…

ProcessSlot构建流程分析

ProcessorSlot ProcessorSlot构建流程 // com.alibaba.csp.sentinel.CtSph#lookProcessChain private Entry entryWithPriority(ResourceWrapper resourceWrapper, int count, boolean prioritized, Object... args)throws BlockException {// 省略创建 Context 的代码// 黑盒…