一、背景

随着网易支付各大系统逐步的拆分，各个系统之前调用越来越复杂，各系统要在不断的有新需求、系统重构或技术改进，使系统的复杂度要在不断的加剧。

基于上面的原因，如果不对这些复杂的依赖进行治理，系统的稳定性将面临很大的挑战。因此才有了对系统内外部服务依赖治理调研方案。

二、目标

通过对核心链路内外部服务依赖治理，达成非核心业务故障不影响核心业务；提高系统的稳定性。最终达成目标：

1. 输出服务、应用及场景依赖关系，以及强弱依赖关系，通过定期全量强弱依赖验证，确保核心服务、应用及场景相关上下游依赖强弱合理清晰；

2. 弱依赖出现各类异常（包括但不限于超时、失败等）场景时均有容错逻辑，针对弱依赖故障场景都有准备应急预案，预案经过验证能有效避免弱依赖故障影响核心业务；

3. 针对核心业务场景中相关的下游弱依赖，实现分钟级预案自动执行；

4. 输出完整长效发现不合理依赖及依赖改进的规范流程机制。

三、调研方案

3.1、阿里云依赖治理

3.1.1、强弱依赖治理方案

https://help.aliyun.com/document_detail/181717.html，强弱依赖治理概述

强弱依赖治理主要包含以下步骤：

1. 应用接入（需要安装探针）。

2. 依赖分析。

3. 依赖预判。

4. 依赖验证（通过演练进行验证）。

5. 方案归档。

3.2、云音乐依赖治理

云音乐依赖治理的整体处理流程：链路数据采集 -> 链路数据分析得到服务及应用的依赖信息 -> 针对服务及场景进行强弱依赖诊断分析及治理 -> 落地故障处理预案。

3.2.1、全链路数据采集

全链路数据采集后构建起应用、集群、链路的拓扑关系，基于关系拓扑，在绘制可视化架构；

3.2.2、服务、应用及场景依赖分析

完成服务、应用及场景依赖分析，三种依赖说明：

1. 服务间的依赖：如核心接口对下游RPC的依赖；

2. 应用间的依赖：如核心应用对下游应用的依赖；

3. 场景对服务依赖：如客户端某个场景/页面，对后端服务接口的依赖。

聚合查询链路数据并保存，可从多维度进行依赖关系的查看。

• 应用信息，查询当前应用与下应用的依赖关系列表；以及下游应用被当前应用依赖的服务信息；

• 链路信息，查询当前应用所有链路以及链路与下游服务的依赖关系；

• 场景信息，查询当前应用下所有场景

3.2.3、服务及场景依赖治理

依托磐石平台结合服务故障注入，进行服务强弱依赖判别；磐石平台实现了依赖自动化检测。

依赖治理从功能上主要分为两个部分，服务强弱依赖和场景强弱依赖，如下

通过平台进行自动化分析服务上下游的强弱依赖关系、沉淀强弱依赖关系数据、强弱依赖治理【服务依赖治理、场景依赖治理】。

最终根据服务或场景依赖治理，达到强弱依赖优化治理。

3.2.4、预案及执行计划

强弱依赖梳理及治理完成后，可针对下游各依赖故障，总结并沉淀出各种的故障处理预案；然后产生出执行计划；在故障产生时，进行预案及执行计划的下发，做到及时的故障处理。针对故障的处理方案：限流、降级、静态化。

3.3、方案总结

两种方案对于服务依赖的执行路径是一致的，主要流程为：链路数据采集 -> 链路数据分析得到服务及应用的依赖信息 -> 针对服务进行强弱依赖诊断分析及治理。

四、落地方案

依赖治理整体架构

4.1、服务依赖治理

4.1.1、链路聚合数据查询

通过应用层记录日志，然后通过聚合/分析/清洗日志，保存链路数据到ES

通过ES提供查询服务：按应用聚合应用入口服务信息列表，按服务名称聚合下层服务及应用信息。

4.1.2、强弱依赖标记

得到完整的服务调用依赖关系之后，按服务的依赖关系进行强弱依赖的预判。

4.1.3、服务强弱依赖验证

测试人员针对服务，通过故障注入方式进行强弱依赖的验证，确保标记的依赖关系与系统表现一致。自动化验证如下：

• 核心服务自动化执行获取Case对应的链路信息，对两者做关联。

• 验证某个服务的链路时，通过链路信息查询匹配的自动化用例，执行自动化用例来验证服务强弱依赖。

4.1.4、强弱依赖改进

• 针对与标记不符合的依赖关系，开发人员进行改进后，重新提给测试人员验证。

• 针对可能发生的故障，通过故障演练，沉淀出故障临时解决步骤与流程。可能容错手段有：限流、降级或熔断。

4.2、场景依赖治理

4.2.1、场景梳理录入

• 确定核心场景范围；

• 列出每个场景调用的服务步骤，并记录到平台。

4.2.2、依赖预判

按场景对服务的依赖关系进行强弱依赖的预判。

4.2.3、依赖验证

针对每个场景依赖的服务在API网关下发故障，验证故障对功能是否有影响，有影响则判为强依赖。

验证方式：

• UI自动化用例

• 手工验证

4.2.4、依赖改进

• 针对与标记不符合的依赖关系，开发人员进行改进后，重新提给测试人员验证。

• 针对可能发生的故障，通过故障演练，沉淀出故障临时解决步骤与流程。可能容错手段有：限流、降级或熔断。

4.3、长效处理流程

4.3.1、服务分级标准

P0: 核心服务，核心场景覆盖到且是强依赖的服务

P1: 非核心服务

4.3.2、服务变更处理流程

系统定时全量服务依赖信息同步；进行变更通知及处理。

4.3.3、场景分级标准

P0: 核心场景

P1: 非核心场景

4.3.4、场景处理流程

在需求阶段确立场景，提测后进行场景依赖治理的初始化以及后续的验证。

五、成果及规划

5.1、成果

1. 通过核心场景及功能流程确认，发现不合理依赖9个；

2. 完成核心场景依赖、服务依赖的验证；通过验证发现不符合预期的服务依赖11项，不符合预期的链路依赖274项；

3. 形成服务链路依赖自动识别、验证机制，做到及时发现及处理核心业务的依赖合理性。

5.2、规划

1. 完善服务依赖可验证的范围，覆盖消息等其它类型；

2. 服务强弱依赖治理的RT强弱依赖治理（对依赖服务的响应时间的影响）；

3. 针对场景或服务，保存可验证、可执行的预案及策略；

4. 验证方式从自动化用例方式改进成流量回放方式，解决自动化用例的验证方案，存在执行效率偏低、准确性不高的问题。

-- End --