福州仓山区网站建设,邯郸卓匠网络科技有限公司,页面设计模板怎么写,一级服务器二级服务器作者#xff1a;涯海
最近一年#xff0c;小玉所在的业务部门发起了轰轰烈烈的微服务化运动#xff0c;大量业务中台应用被拆分成更细粒度的微服务应用。为了迎接即将到来的双十一大促重保活动#xff0c;小玉的主管让她在一周内梳理出订单中心的全局关键上下游依赖#…作者涯海
最近一年小玉所在的业务部门发起了轰轰烈烈的微服务化运动大量业务中台应用被拆分成更细粒度的微服务应用。为了迎接即将到来的双十一大促重保活动小玉的主管让她在一周内梳理出订单中心的全局关键上下游依赖提前拉通各方对齐重保方案。这个任务可愁坏了小玉平时她只与直接上下游业务方打交道现在要梳理出订单中心完整的依赖路径头发愁掉了一大把仍然不知道该如何下手。无奈之下小玉再次求助于万能的小明。
针对小玉的问题小明提出了一个想法首先调用链可以追踪一次请求的完整调用路径但是单条调用链无法反映出所有的调用分支也无法通过流量大小体现出依赖的强弱而逐条分析调用链的成本又太高。那么是否可以通过程序将一批具有相同特征比如经过某个应用或者调用了某个接口的调用链聚合成一颗树通过分析这棵树的形态与流量就可以快速梳理出关键节点与依赖路径而这就是链路拓扑功能的雏形。 如上图所示入口应用 A 依赖了多个不同深度的下游应用并且每次调用的路径并不相同。为了梳理出应用 A 的完整调用依赖可以将多条调用链聚合成一棵树从根节点到叶子节点的每条路径都代表着一种流量流转路径而节点的状态反映了流量的特征比如次数、耗时、错误率等。通过调用链聚合综合分析端到端流量路径与状态的方法就是链路拓扑。 链路拓扑与调用链的关系就好比样本集与离散样本点前者反映了整体的分布情况可以有效避免单个样本随机性对评估结果的影响。
01 链路拓扑的经典应用场景
链路拓扑最核心的价值就是通过分析节点间依赖路径与状态提供强弱依赖梳理、瓶颈点分析、影响面分析、故障传播链分析等能力下面我们来深入了解下这些经典用法。
一强弱依赖梳理
链路拓扑最典型、最被人熟知的应用场景就是依赖梳理特别是在一个大型分布式系统中数以万计的应用间依赖关系复杂到令运维同学怀疑人生。下图展示了 2012 年的淘宝核心链路应用拓扑密密麻麻如蛛网般的依赖关系已经远远超出了人工梳理的范畴而这种情况在微服务迅猛发展的当下并不少见。 在复杂业务环境中不仅需要梳理出依赖关系图还需要识别哪些是影响核心业务的强依赖哪些是“无伤大雅”的弱依赖。针对强依赖要投入更多的人力与资源建立更加完善的保障体系比如电话告警联合压测等。针对弱依赖可以考虑是否能够移除或者建立次一级的保障措施。
区分强弱依赖的方式主要有以下几种 根据流量大小进行区分。这是一种简单粗暴的区分方式大于一定流量阈值或比例的就识别为强依赖否则视为弱依赖。这种判断方式的好处是简单清晰可以由链路追踪平台自动识别无需人力干预。缺点是不够准确一些特殊的关键依赖虽然流量不大但是却会直接影响业务的稳定性。 根据同步/异步调用类型进行区分。这种区分方式的好处也是简单、易操作减少了异步非阻塞如消息调用的干扰。缺点是在同步调用为主的业务中筛选效果不佳而在异步调用为主的业务红包、热点推送可能造成误判。 人工标注。鉴于业务的差异性由业务 Owner 对自身依赖的直接下游的强弱性进行人工标注识别可靠性会更高。但是这种方式对于人员经验和时间成本要求很高并且无法自适应业务的变化。 半人工标注。首先由链路追踪平台根据流量大小、同步/异步进行初步的强弱依赖识别再通过有经验的同学进行人工标注修正。这样既节省了人力成本也能有限度的自适应未来的业务变化。 强弱依赖梳理是相对低频的工作通常发生在在大促或重保活动准备阶段、新应用上线或老应用下线、上云搬站等场景。比如阿里在每年双十一大促前都会梳理核心业务的强弱依赖并与往年进行对比以便更好的进行针对性保障。
二瓶颈点/影响面分析
链路拓扑在问题诊断领域最常见的用法就是瓶颈点分析与影响面分析。前者是从当前节点向下游寻找导致问题发生的原因主要用于问题定位而后者是从问题节点向上游分析被影响的范围主要用于业务风险定级。
接下来我们通过一个数据库异常的案例对比下这两种用法与视角的区别如下图所示。 某天上午应用 A 的管理员收到用户反馈服务响应超时通过查看链路拓扑状态发现 A 应用依赖的 D 应用接口变慢而 D 应用调用数据库接口也出现异常。因此小 A 通知小 D 即刻排查数据库连接等状态尽快恢复可用性。这就是一个瓶颈点分析的过程。 由于小 D 业务不熟练半小时过去了还没有完成有效的恢复动作并且触发了数据库服务端异常。负责 DB 运维的同学收到数据库服务端告警后通过链路拓扑向上回溯业务影响面发现直接依赖的 D、E 两个应用均出现了大量慢 SQL并导致间接依赖的应用 A、B 出现不同程度的服务响应超时。果断执行了数据库扩容最终恢复了全部应用的正常访问。这就是通过影响面分析辅助运维决策的过程。 瓶颈点与影响面分析主要是基于一段时间内的静态拓扑数据并没有体现时间变化对拓扑节点状态的影响无法回溯故障传播的过程。如上图右侧所示如果只看这一张拓扑我们难以判断出导致数据库服务端异常的应用到底是 D 还是 E。那么是否能够动态回放链路拓扑的变化更直观的分析问题源与传播趋势答案无疑是肯定的请看下文介绍。
三故障传播链分析
抛开时间的维度问题源与影响面的边界并不是很清晰。一个被影响方可能会成为新的问题源引发更大的故障。因此为了能够更加真实的还原故障演变过程我们需要观察并对比一组时间线连续的静态链路拓扑快照集通过不同快照之间节点状态的变化还原故障传播链。这就好比通过监控视频还原凶案发生过程要比单独的一张照片更加可靠。
以上一小节的数据库故障为例一开始应用 D 由于请求缓存未命中从而大量请求数据库导致慢 SQL进而影响上游应用也出现响应超时。随着情况继续恶化数据库服务端也开始过载进而影响了应用 E 的正常调用。最后应用 A、B 均出现大量响应超时API 网关由于连接不足开始拒绝访问引发更大面积的服务不可用。 在真实生产环境中拓扑依赖与故障传播的过程可能会更加复杂为了简化分析过程可以根据一定规则将节点状态提取为各类异常事件观察不同时刻的异常事件数量也可以辅助判断故障发生、传播与恢复的过程如下图所示。 02 链路拓扑聚合维度
链路拓扑的聚合维度决定着拓扑节点的类型面向不同的用户角色提供了差异化的分析视角。在实际应用中最典型的三种链路拓扑聚合维度分别是应用、接口与自定义维度分别对应着应用拓扑、接口拓扑和业务拓扑。 应用拓扑 顾名思义就是根据应用名称进行链路聚合反映了应用间的依赖关系与总体流量状态。由于数据聚合粒度较粗局部异常会被平均值掩盖不适合精细化的问题诊断更适合全局依赖梳理与重大故障定界用户角色偏向于 PE 运维或 SRE 稳定性负责人。 接口拓扑 是在服务接口这一维度进行的链路聚合相比于应用拓扑更贴近研发视角因为日常迭代的对象通常是某个具体的服务接口无论是新接口上线、老接口下线或核心接口重保接口粒度的链路拓扑更符合研发测试流程与职责划分习惯。应用与接口都是链路追踪领域的基础对象对应的拓扑可以由链路追踪平台自动生成无需过多的人工干预使用起来较为方便。 业务拓扑 是根据自定义维度聚合生成的偏业务视角的链路拓扑通常比接口维度要更深一级比如某个下单接口可以根据商品类目维度进一步细分为女装或家电如下图所示。业务拓扑一般无法由链路追踪平台自动生成需要用户结合业务特性定制聚合规则。此外自定义维度的来源比较广泛可以是手动添加的 Attributes 自定义标签也可以是 HTTP 请求出入参或者是所在机器的环境标签。在这方面开源社区缺乏相应的标准而各大厂商的商业化实现差异也比较大。 综上所述不同聚合维度生成的链路拓扑具备不同功能定位与特性如下表所示 03 链路拓扑生成方式
为了最大程度的保留链路数据的端到端关联信息链路拓扑通常是基于调用链明细数据直接聚合生成而不是基于指标数据的二次聚合。细心的读者可能会发现这里隐藏着一个颇具挑战的技术难题就是如何平衡海量链路数据聚合的实时性、准确性与灵活性。理想情况下我们希望基于符合条件的全量调用链明细数据快速生成最真实的链路拓扑实现“又快又准又灵活”。但在实际应用中鱼与熊掌不可兼得我们只能在“快”、“准”、“灵活”之间进行抉择也因此衍生出了不同的链路拓扑生成流派。 一实时聚合
实时聚合是根据用户指定查询条件动态筛选调用链并生成拓扑图的一种方式。这种方式的好处是实时性较高使用非常灵活可以指定任意条件比如查看大于 3S 的调用链生成的拓扑或者仅包含异常调用的拓扑。缺点是当满足条件的调用链明细数据量超过一定阈值后可能会打爆实时聚合计算节点因此通过会设定一个聚合条数上限比如5千条牺牲一定的数据精确度换来极高的灵活度与实时性。 二离线聚合
离线聚合是根据一组事先定义好的聚合规则周期性生成拓扑数据的一种方式。例如不包含任何筛选条件的应用、接口这种基础拓扑数据就可以通过离线聚合生成。这种聚合方式的好处是可以利用离线计算的水平扩展性支撑海量链路数据的聚合计算生成结果会更加准确。缺点是实时性较差聚合规则变更到新拓扑生成的周期较长。离线聚合通常用于全局拓扑数据的精确计算。
三预聚合
预聚合是一种理论上可行的拓扑生成方式它的思路是从入口节点开始不断向下透传全链路的完整调用路径信息并在端侧生成相应的预聚合指标。不考虑透传信息的长度限制与端侧预聚合开销这种方式的好处就是节省了在服务端将明细数据转化为拓扑数据的过程实现又快又准的目标。但是缺陷就是不支持自定义规则否则透传与预聚合的开销会直线上升影响业务进程的性能与稳定性。预聚合的原理示意图如下所示。 04 3D 拓扑
流量与资源是一对“好兄弟”二者密切相关。流量影响着资源分配而资源反过来又约束着流量状态。大部分流量异常归根结底是资源配额不足或分配不合理导致的比如峰值流量瞬间耗尽资源或者流量不均导致的“热点”等。我们在定位流量异常根因的过程中往往需要结合相对应的资源状态进行分析反过来当一个资源节点出现异常时我们也希望知道它会影响其上运行的哪些流量因此在代表流量的链路拓扑上关联相对应的资源数据形成更加完整的 3D 拓扑貌似是个不错的选择。
如下图所示3D 拓扑不仅包含 PaaS 层的应用、接口流量节点状态与依赖还可以下钻查看相对应的 IaaS 层进程、实例等资源状态。3D 拓扑为流量与资源建立了一个连接帮助我们更直观的定位资源瓶颈引发的流量异常问题。 3D 拓扑以一种巧妙的方式传递了更多的信息但是它也有一个非常致命的缺陷就是信息密度过于集中。在复杂拓扑环境下表现可能还不如 2D 拓扑来的直观大大降低了它的实用价值。如下图所示当实例规模达到数百接口数量达到上千时3D 拓扑交互上的复杂性显著降低了诊断排查的效率更多用于大屏展示。 为了降低 3D 拓扑的交互成本一种可能的思路是结合智能诊断技术自动突出异常链路精准收敛展示数据范围。不过这对于技术与产品的要求较高实用性还有待大量真实生产环境的检验。
