(马蜂窝技术原创内容，公众号 ID：mfwtech)

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. 易用性优 化，收集大家在使用过程中遇到的问题进行持续改进，做到可用、易用、好用。

Part 6 结语

目前国际机票、国内机票、接送机等业务全部接入了 JARVIS 系统，也经历了几个大项目开发和测试过程的检验，在性能和可用性方面也做了多次优化，目前还存在很大的改进空间，我们也会持续进行完善。

最后，大交通团队正在招聘 Java 架构师，有兴趣的同学欢迎发送简历至：anzidong@mafengwo.com

本文作者：安自东，马蜂窝大交通团队研发技术专家。