API资源隔离系统的设计和实现
这篇文章主要介绍“API资源隔离系统的设计和实现”,在日常操作中,相信很多人在API资源隔离系统的设计和实现问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”API资源隔离系统的设计和实现”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名申请、雅安服务器托管、营销软件、网站建设、迎泽网站维护、网站推广。
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 系统,也经历了几个大项目开发和测试过程的检验,在性能和可用性方面也做了多次优化,目前还存在很大的改进空间,我们也会持续进行完善。
到此,关于“API资源隔离系统的设计和实现”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!
网站题目:API资源隔离系统的设计和实现
分享地址:http://myzitong.com/article/ggjisc.html