Part 1 背景

大交通业务需要对接机票、火车票、租车、接送机等业务的外部供应链，供应商的数据接口大部分通过 HTTP、HTTPS 等协议进行通信。

为了保证开发进度并支持集成测试时进行多场景支持，我们往往需要对供应商接口进行 MOCK。之前我们在开发环境和测试环境对外部接口的调用没有统一管控，无法实现调用开关，也无法对调用量进行统计和限制。

为了解决这些问题，我们设计了接入 API 资源隔离系统 JARVIS（Join Api Resource Virtual Isolation System），希望它可以像钢铁侠中的 Jarvis 一样帮我们解决资源的管控问题。

Part 2 设计原则

1. 图形化操作，提供管理后台，对开发和测试同学的交互要友好。
2. 对业务无侵入，无需修改业务系统代码，保证测试的代码和发布的是一致的。
3. 业务关联，这个系统是为业务服务的，需要提供必要的业务关联性。
4. 支持丰富的匹配规则，可以用于绝大部分使用场景。
5. 所配即所得，管理规则可以即时生效。
6. 请求响应可追溯，提供详细的日志记录和查询功能。

Part 3 设计与实现

整体思路

供应商资源管控系统位于内部接入网关和外部供应商接口之间，在开发和测试环境对外部供应商资源提供了全局的代理，在系统中的位置如下：

资源管控系统系统分两大部分：

1. Config Center：主要实现业务线、环境、供应商、供应商 API 和 API 对应的 MOCK 规则的配置管理。
2. API Server：主要负责请求的接受、MOCK 规则匹配、MOCK 规则的响应和日志记录。

关键功能

• 采用配置中心和 API 服务器分离的结构，支持集群部署
• 同时支持模拟响应和代理访问两种响应方式
• 支持 Mock 规则修改后即时生效
• 自动适应上游服务的环境隔离
• 同一 API 在同一环境下支持多种场景，并且有优先级区分
• Mock 规则会关联业务系统，如业务线、环境、供应商、供应商的 API 等
• 会进行 Mock 请求调用次数的计数，并且支持超量熔断和超量报警
• 支持 Mock 调用的日志记录和可视化查询。

规则配置与管理

主要包含业务线信息配置、环境配置、供应商配置、供应商所属 API 配置、Mock 规则配置。业务信息之间的关系如下 ：

1. 「业务线」指的是如国内机票、国际机票、火车票、租车、接送机等业务类型

2. 「环境」包含两层含义：

• 一为部署环境，分为 dev 开发环境、qa 测试环境、sim 预发环境、prod 生产环境四种，可以理解为以下四个互相隔离的集群。
• 二为在 qa 环境下为了区分多个项目进行了环境隔离，如开放平台代号为 kfpt，乘机人代号为 cjr。

3. 「供应商」是指业务接入的各种商家，商家可以归属到某条业务线

4. 「供应商」 API 是指供应商提供的一系列基于 HTTP 或 HTTPS 的接口

5.「 MOCK 规则」是指为了对供应商接口进行仿真或代理而配置的规则，用于后续的规则匹配和返回响应信息。MOCK 规则会归属某个供应商 API，同时归属于某个环境。

6.「 场景」是用来区分同一供应商 API 且在同一环境下面不同场景的区分，分为通用场景和具象场景两大类，在规则匹配时优先匹配具象场景，如果具象场景未匹配成功则进行通用场景匹配。

响应规则的匹配和响应过程

规则匹配和内容响应的流程如下：

1. 规则加载和刷新，接收到内部系统的调用后，会判断当前的规则缓存是否为空，如果为空则会加载全部可用的 MOCK 规则加载到缓存中。

2. 环境隔离标识自适应， 内部的服务通常是采用环境隔离方式部署，环境隔离标识（envTag）会影响到规则的匹配。

3. 规则匹配 ，根据请求的 URL 对规则进行匹配，最终可能匹配多条规则。将匹配到的规则分为具象场景规则和通用场景规则两组。对具象场景的 MOCK 规则根据请求参数进行匹配，如果命中则返回。对通用场景的 MOCK 规则根据请求参数进行匹配，如果命中则返回。

4. 结果响应，如果没有匹配到 Mock 规则，直接返回默认的错误信息。如果匹配到 Mock 规则，先判断是 Mock 类型还是 Proxy 类型，对于 Mock 类型会按照规则的配置返回状态码和响应内容，如果是 Proxy 类型则先调用供应商的真实接口再将获取到的内容返回给调用方。对接口当日的调用次数进行显示，如果超过阈值则会触发报警并进行服务熔断。

主要 Feature

1. 多种匹配条件

支持根据 header、param、JsonPath、body 等多种方式进行参数提取和匹配。

2. Mock 规则热生效

Mock 规则新增或修改后会热生效，实现所配即所得。在消息新增和修改后会触发规则变更的切面，进而通过 RocketMQ 发送规则变更消息，消息以广播的形式进行发送，API Server 会监听该消息，收到后会触发规则的刷新。

3. 环境隔离支持

内部的网关服务通常是采用环境隔离方式部署，我们采用在 HttpHeader 中增加 envTag 属性来传递环境标识。会判断 envTag 是否为空，如果为空则不进行 URL 的重新组装，如果为空则会将上述 URL 中的 {env} 部分替换为实际对应的 envTag。

环境隔离主要是分为两步来实现：

• 在我们接入网关层面，通过 join-common 自动提取并传递来自上游的环境隔离标识 envTag，并将其写入到 HTTP Header 中。
• 在 API Server 我们接收到请求后会判断请求是否携带 envTag 标识，如果携带会将 URL 中的 {env} 部分替换为实际对应的 envTag，最终匹配到环境对应的规则上面。如果没有携带 envTag 则会去匹配默认的环境规则。

4. 多场景支持

• 每个规则对应一个环境和一个供应商接口，但是会分为请求成功、请求失败等场景
• 多个人在同一个项目中进行开发和测试的时候会产生冲突

为应对这种问题，我们提出了「场景」的概念，分为通用场景和具象场景：

• 通用场景故名思义就是用来应对正常的请求，一般会放开 Proxy 开关，直接请求到供应商的接口
• 具象场景用于对应某个具体的 Case，比如北京飞上海 1 成人 1 儿童的查询，我们通过更加详细的参数进行匹配

在匹配层级上面优先匹配具象场景的规则，如果匹配失败才会继续匹配通用场景的规则。

5. 超限熔断与报警

根据在供应商 API 层面设置的请求上限进行校验，如果当日的请求超限，会进行规则的降级，并通过企业微信发送报警信息。

6. 报文自动加密与解密

有些供应商的报文传输是密文的形式，我们在 JARVIS 系统中根据对应的供应商在编辑时是明文，在保存的时候会根据协议加密为密文。

7. 请求日志记录与查询

对所有的请求都会记录请求报文、响应报文、命中规则等信息，由于报文体积较大且调用量较大，我们使用 ElasticSearch 进行存储。

Part 4 项目实战

目前已经在开发和测试环境代理了全部的供应商接口:

1. 国内开放平台开发支持

近期我们在国内机票开放平台，前期由我方提供标准接，口由供应商接口并没有完全实现，我们根据文档生成了全部的 Mock 数据并针对每个接口的各种场景定制了 Mock 规则，保障了项目的开发进度并且实现了多场景的覆盖。

2. 暑期压力测试支持

近期进行了暑运压力测试，测试时通过 Mock 功能隔离了对外部供应商的访问，并通过设置响应延迟时间模拟了供应商接口不同状况下的响应时间。

Part 5 后续路线图

后续主要计划在以下方向进行改进和优化：

1. 供应商接口管理，实现接口 Schema 的定义与管理，并实现对请求参数和响应内容校验。
2. 增加模版化响应，减少人工配置，提高使用效率。
3. 完善统计系统，实现资源使用情况的可视化。
4. 易用性优化，收集大家在使用过程中遇到的问题进行持续改进，做到可用、易用、好用。

转自：https://www.cnblogs.com/mfwtech/p/11445467.html