西安网站建设价格低,wordpress有趣插件,wordpress 产品 相册插件,wordpress搬迁数据库连接失败一、前言
1、微服务关联复杂性
在当前云原生与DevOps、PaaS技术应用背景下#xff0c;微服务化是一个显著的特征。所谓微服务#xff0c;简单来说就是将过去的大型单体应用按照功能职能#xff0c;划定交互边界#xff0c;拆分为一个个小型的微服务汇总而成最终的产品交付…一、前言
1、微服务关联复杂性
在当前云原生与DevOps、PaaS技术应用背景下微服务化是一个显著的特征。所谓微服务简单来说就是将过去的大型单体应用按照功能职能划定交互边界拆分为一个个小型的微服务汇总而成最终的产品交付。
微服务带来的好处自不必多说例如敏捷性、灵活扩展、轻松部署等。但是当整个云服务愈发复杂、架构愈发繁琐时我们发现微服务的模式也存在一些缺陷其中之一就是海量微服务的交互与关联问题。
以笔者的实践为例一些普通的单体工具服务其分拆的微服务可能有30-50个之多而对于综合交互的工具平台服务最终的微服务数量可能会达到上千个这其中微服务之间彼此关联、相互依赖形成一种繁杂的网状交织结构。发现、分析具体微服务的关联关系迫在眉睫。
2、告警信息获取与展示
除了复杂的微服务关联关系外海量的微服务所涉及的故障与告警也愈发难以观测和处理。
诚然随着技术的进步各种监控工具、观测维度愈发成熟但同样带来了数据越来越多、越来越分散负责的问题。例如对于一个微服务而言
基础设施层可能有对应的CPU、内存、数据库等指标监控中间件层可能会有对应的Kafka队列、Redis等监控与告警应用层可能会有调用链、接口异常调用状态码、日志关键字等监控告警业务层可能会有诸如URL拨测、健康巡检等类型的监控与告警各个环节还存在服务自定义的相关监控与告警例如Prometheus监控与定义告警
以笔者的实践看来即使有告警智能汇聚于压缩的帮助服务每天依旧要面对着成百上千、来自各个监控告警平台的告警提示如何能直观的观测告警的来源、分布以及具体影响爆炸半径同样是一个需要重视和解决的问题。
二、服务拓扑构造
基于上述的论点首先需要做的就是尝试找出繁杂的微服务之间的关联关系。这里我们主要通过以下几个维度做判断与构造并最终做数据层面的融合。
1、基于架构设计
首先服务的关联关系应该在最初的产品定义与设计时就应该有相应的规划与确定这里主要是 “41视图”分别为逻辑视图、物理视图、处理流程视图、开发视图以及最后的场景视图。
逻辑视图 用于描述系统的功能需求即系统给用户提供哪些服务以及描述系统软件功能拆解后的组件关系、组件约束和边界反映系统整体组成与系统如何构建的过程。在UML中由类图来表示。 物理视图 物理视图也成为部署视图开发出的软件系统最终是要运行在物理或软件环境上。物理环境可能是服务器、PC机、移动终端等物理设备软件环境可以是虚拟机、容器、进程或线程。部署视图就是对这个部署信息进行描述。在UML中通常由部署图表示。 处理视图 处理视图又称过程视图、运行视图、行为视图。用于描述系统软件组件之间的通信时序数据的输入输出。在UML中通常由时序图和流程图表示。运行视图的设计最常见的是逻辑架构元素之间的交互关系比如消息交互、服务调用或API调用。 开发视图 开发视图关注软件开发环境下实际模块的组织反映系统开发实施过程。一个设计良好的开发视图应该能够满足以下要求通过逻辑架构元素能够找到它所有代码和所有的二进制交付件 每一个代码源文件都能够找到它所属的逻辑架构元素 每一个二进制交付件都能够找到它集成了哪些逻辑架构元素。 场景视图 场景视图也成为用例视图即41中的1。从前面的图可以看到41中的4个视图都是围绕着场景视图为核心的。它用于描述系统的参与者与功能用例间的关系反映系统的最终需求和交互设计。在UML中通常由用例图表示。 系统边界有了边界才能够确定系统的设计范围同时通过边界能够识别出系统需要与用户或其它系统进行交互系统用户明确的用户定义是系统需求分析的先决条件功能和场景通过识别出系统与用户或其它系统的交互可以分析出系统需要提供哪些功能以及这些功能存在哪些应用场景
在完成上述41视图的设计过程中其中的关键点之一就是确定系统功能与边界、并定义不同系统间的交互形式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、定界与影响分析
在服务发生故障、产生告警时除了及时通知到服务外我们还有对故障的定界与具体影响做相关分析的诉求。
对于故障定界而言
所谓故障定界即在故障发生时尝试找到故障发生的根源服务与根源点所在通过告警信息渲染的服务关联拓扑图以及服务的上下游关系我们能够直观识别故障的具体产生点借助调用链的数据分析也能为定界提供信息参考需要注意的是故障定界是一个业界难题拓扑渲染仅能作为参考很多情况下故障根因未必是拓扑故障根节点
对于影响分析而言
所谓影响分析即在故障产生时具体影响面情况影响服务与影响用户等方便控制爆炸半径、及时故障降级通过服务接口故障传播调用链数据、接口被调用情况来确定机机场景下故障影响的服务数通过故障产生时接口错误日志中对应的用户信息来确定人机场景下故障具体影响的用户数通过全局服务关联与故障拓扑图直观呈现故障影响面范围
四、小结
云原生背景下的海量微服务带来的不仅是基于更多的还有挑战。通过设计态与运行态的不同视角对服务间关联关系进行挖掘发现有利于化繁为简、识别真正重要的问题与潜在风险。同时将各层级告警映射到服务关联拓扑之中能够让我们快速发现与处理海量的微服务所涉及的故障与告警。
