189 8069 5689
这篇文章主要介绍“API资源隔离系统的设计和实现”，在日常操作中，相信很多人在API资源隔离系统的设计和实现问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”API资源隔离系统的设计和实现”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名申请、雅安服务器托管、营销软件、网站建设、迎泽网站维护、网站推广。
大交通业务需要对接机票、火车票、租车、接送机等业务的外部供应链，供应商的数据接口大部分通过 HTTP、HTTPS 等协议进行通信。
为了保证开发进度并支持集成测试时进行多场景支持，我们往往需要对供应商接口进行 MOCK。之前我们在开发环境和测试环境对外部接口的调用没有统一管控，无法实现调用开关，也无法对调用量进行统计和限制。
为了解决这些问题，我们设计了接入 API 资源隔离系统 JARVIS（Join Api Resource Virtual Isolation System），希望它可以像钢铁侠中的 Jarvis 一样帮我们解决资源的管控问题。
图形化操作，提供管理后台，对开发和测试同学的交互要友好。
对业务无侵入，无需修改业务系统代码，保证测试的代码和发布的是一致的。
业务关联，这个系统是为业务服务的，需要提供必要的业务关联性。
支持丰富的匹配规则，可以用于绝大部分使用场景。
所配即所得，管理规则可以即时生效。
请求响应可追溯，提供详细的日志记录和查询功能。
供应商资源管控系统位于内部接入网关和外部供应商接口之间，在开发和测试环境对外部供应商资源提供了全局的代理，在系统中的位置如下：
资源管控系统系统分两大部分：
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 类型则先调用供应商的真实接口再将获取到的内容返回给调用方。对接口当日的调用次数进行显示，如果超过阈值则会触发报警并进行服务熔断。
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 进行存储。
目前已经在开发和测试环境代理了全部的供应商接口:
1. 国内开放平台开发支持
近期我们在国内机票开放平台，前期由我方提供标准接，口由供应商接口并没有完全实现，我们根据文档生成了全部的 Mock 数据并针对每个接口的各种场景定制了 Mock 规则，保障了项目的开发进度并且实现了多场景的覆盖。
2. 暑期压力测试支持
近期进行了暑运压力测试，测试时通过 Mock 功能隔离了对外部供应商的访问，并通过设置响应延迟时间模拟了供应商接口不同状况下的响应时间。
后续主要计划在以下方向进行改进和优化：
供应商接口管理，实现接口 Schema 的定义与管理，并实现对请求参数和响应内容校验。
增加模版化响应，减少人工配置，提高使用效率。
完善统计系统，实现资源使用情况的可视化。
易用性优化，收集大家在使用过程中遇到的问题进行持续改进，做到可用、易用、好用。
目前国际机票、国内机票、接送机等业务全部接入了 JARVIS 系统，也经历了几个大项目开发和测试过程的检验，在性能和可用性方面也做了多次优化，目前还存在很大的改进空间，我们也会持续进行完善。
到此，关于“API资源隔离系统的设计和实现”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！