API 资源隔离系统设计与实现

指导 09-03 阅读: 评论:
后台-系统设置-扩展变量-手机广告位-内容正文顶部
Part 1 背景

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

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

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

Part 2 设计原则

图形化操作,提供管理后台,对开发和测试同学的交互要友好。

对业务无侵入,无需修改业务系统代码,保证测试的代码和发布的是一致的。

业务关联,这个系统是为业务服务的,需要提供必要的业务关联性。

支持丰富的匹配规则,可以用于绝大部分使用场景。

所配即所得,管理规则可以即时生效。

请求响应可追溯,提供详细的日志记录和查询功能。

Part 3 设计与实现 整体思路

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

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

Config Center:主要实现业务线、环境、供应商、供应商 API 和 API 对应的 MOCK 规则的配置管理。

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 后续路线图

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

供应商接口管理,实现接口 Schema 的定义与管理,并实现对请求参数和响应内容校验。

增加模版化响应,减少人工配置,提高使用效率。

完善统计系统,实现资源使用情况的可视化。

易用性优化,收集大家在使用过程中遇到的问题进行持续改进,做到可用、易用、好用。

Part 6 结语

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

后台-系统设置-扩展变量-手机广告位-内容正文底部
版权声明

本文仅代表作者观点,不代表Flashempire闪客帝国立场。
本文系作者授权Flashempire闪客帝国发表,未经许可,不得转载。

分享:

扫一扫二维码

扫一扫在手机阅读、分享本文

评论

留言与评论(共有 0 条评论)
   
验证码:

相关推荐