新闻中心

  • 首页
  • 新闻中心

马蜂窝大交通接入 API 资源隔离系统设计和与实现

时间:2019-11-19 21:31

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

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

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

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

  API Server:主要负责请求的接受、MOCK 规则匹配、MOCK 规则的响应和日志记录。

  Mock 规则会关联业务系统,如业务线、环境、供应商、供应商的 API 等

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

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

  一为部署环境,分为 dev 开发环境、qa 测试环境、sim 预发环境、prod 生产环境四种,可以理解为以下四个互相隔离的集群。

  二为在 qa 环境下为了区分多个项目进行了环境隔离,如开放平台代号为 kfpt,乘机人代号为 cjr。

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

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

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

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

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

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

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

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

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

  在我们接入网关层面,通过 join-common 自动提取并传递来自上游的环境隔离标识 envTag,并将其写入到 HTTP Header 中。

  在 API Server 我们接收到请求后会判断请求是否携带 envTag 标识,如果携带会将 URL 中的 {env} 部分替换为实际对应的 envTag,最终匹配到环境对应的规则上面。如果没有携带 envTag 则会去匹配默认的环境规则。

  每个规则对应一个环境和一个供应商接口,但是会分为请求成功、请求失败等场景

  通用场景故名思义就是用来应对正常的请求,一般会放开 Proxy 开关,直接请求到供应商的接口

  具象场景用于对应某个具体的 Case,比如北京飞上海 1 成人 1 儿童的查询,我们通过更加详细的参数进行匹配

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

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

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

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

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

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

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

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

  最后,大交通团队正在招聘 Java 架构师,有兴趣的同学欢迎发送简历至: