关于API Management的一些想法

发表于 | 分类于 | 阅读次数: |
字数统计: 1,091 | 阅读时长 ≈ 4

API Management产品必要的功能

最近由于工作的关系，试用了几款API Management的产品， 包括Tibco Mashery和MS Azure API Management。两款产品各有千秋，其中我觉得MS的设计的会科学一点。通常这样的的产品会包括以下功能:

  • API Publisher
    • API的发布, swagger是常用的方案
    • API的package, 把业务相关的多个API组合成一个套餐，让用户subscribe
    • 访问量的定制，用户权限的管理
  • API Gateway
    • API的代理设置
    • API的访问路径设
    • API前后的data transformation配置
    • API的访问验证机制，Access Key的来源位置设定，调用时的变量管理
    • API调用时的一些定制化hooks配置
    • API的访问量、响应时间、调用参数和结果的记录
  • API平台的监控
    • 访问量统计
    • 响应时间统计, 包括：中间件、数据查询、数据转换分别损耗的时间 （目前还没发现外面的产品有这个颗粒度的统计）
    • API和相应的package统计
    • 用户subscription的统计

我们团队也做了一个内部的API Management的项目，对比起来我觉得我们的项目可以有以下几点的优化：

  1. API的Acces Key最好跟API的业务参数分开，如：放到header里头；
  2. API的入口要尽量灵活，可定制化，像管理交通路线一样，有traffic route的概念；
  3. 系统监控的指标要充足, 如：调用次数、调用结果、代理损耗时间、API管理记录等；
  4. 最好提供OAuth的功能和数据存储的接口，让用户专注于做自己的数据处理和数据展现就好。

自己做，还是买现成的新产品？

以上提到的两款产品，还有Google的Apigee, 它们都能为企业快速搭建起API的平台 ，但价格都不菲，而且很庞大，还有一个关键的是性能。由于这些产品都给API的调用注入很多中间过程，如:权限认证、数据转换、使用量登记等，而且这些功能都是通用的，这些产品都期待用户不用写代码，而是直接在页面上拖、拉、拽来实现，这样很显示不是以性能优先的。我们曾经在一些测试场上粗略地测过经过中间件损耗的时间，发现有700ms~1秒左右的损耗，对响应时间要求高的API还是有点堪忧的。

相比起直接买产品，我觉得自己做有以下优势：

  • API的性能可以得到有效的控制和优化
  • API的输入输出格式可以有效的统一控制
  • 回归需求，如果只是想有个统一平台来管理企业内部系统的接口，并且对性能又比较敏感的话，还是自己实现来得实在；重量级的API Management产品，感觉偏向于针对做一个多商户的系统接口接入平台，并且接口的数量和复杂度都不是一个团队所能控制的情况下所提供的解决方案。然而有多少企业有这样复杂的需求，愿意为这种方案买单呢？我目前还不清楚。我只是觉得这些核心的业务接口和API平台，自己设计并结合好业务的实际需求，更能发挥真正的价值。像国家物流平台，他们的目标也是做一个给多商户接入的API平台。设计得不错，他们也是自己实现了，没有借用外部的产品。而且我觉得自己的团队做一遍后，对公司的核心数据和接口都会有一个更清晰的认识，更值得这样的投资。

关于一些云存储和后台接口

目前，我们项目中运用的API主要以数据查询为主，如果有需求的话，可以尝试加入数据增、删、改这些类型的API。最近发现Lean Cloud，是个很有意思的云存储和接口平台, 它为移动开发提供方便的后端接口，是个很好的想法。我觉得如果API Management的产品往这个云存储的方向发展，也一定很有意思。

0%