API 编排的应用及痛点

作者:戴泽军

前言

随着微服务架构成为业界主流,API 网关作为访问微服务集群内所有 API 的唯一出入口,地位显得尤为重要。

集群内微服务功能拆分越来越细,对后端而言,模块在独立性、复用性、可维护性方面的优势不言而喻。但对前端而言,复杂性却随之而来。一个前端页面,往往需要从数个甚至数十个 API 中请求数据,而这些 API,很可能还存在如下异构特性:托管 host 不同、实现语言不同、调用方式不同。

面对这样的难题,API 网关的需求应运而生:统一出口、隐藏实现、安全控制、流量控制、负载均衡、权限控制、API 管理等等。这些问题及其解决方案将在后续的文章中一一介绍。本期我们重点讨论 API 网关的另一个重要功能:API 编排。

API 编排的应用

所谓 API 编排,就是通过 API 网关实现一种机制,可以灵活调用和组装后端原生 API,使前端能够根据业务需求,定制化页面所需的聚合 API。其地位和作用,可相较于“Shell 之于 *nix”。

一个典型的 API 编排应用案例如下:
API 编排的应用及痛点_第1张图片

图注:图中方框大小示意调用时数据量大小

可以看出,与后端微服务 API 以“高内聚”为目标不同,聚合 API 以业务需求为导向,通过简单组合已有的原生 API,在后端代理调用多个 API,并对输出数据进行重新剪裁组装。

API 编排的优势

与前端直接调用多个异构的后端 API 相比,聚合 API 具有很明显的优势:

  • 简化前端逻辑,一次 API 调用即可获取所有所需数据;
  • 减少传输数据量,仅向前端发送需要展示的数据;
  • 灵活的动态组合扩展特性,后端只需要实现“原子 API”,把业务需求交给消费方去自助配置,组合扩展;
  • 同化调用方法,由 API 编排服务兼容异构实现的后端 API 的调用过程;
  • 统一的身份认证和权限管理;
  • 向前端隐藏第三方 API 的身份认证过程,由 API 编排服务兼容不同平台的 API 认证方法。

API 编排的痛点

面向没有编程基础的普通用户服务

由于 API 编排具有“用户自助”的特性,注定了其用户“既是生产者又是消费者”。而任何网络平台的用户,都必须假定为“没有编程基础”,即面向没有编程经验的普通用户服务。

功能需要覆盖完备的编程元素

API 编排需要构造多个 API 调用,捕获和剪裁输出数据,同时也可能存在分支和根据条件重复处理等需求。

我们的编程启蒙老师一定都讲过,编程无非就是顺序+选择+循环。可见,编程所需所有元素,在 API 编排中皆有需求。然而,在我们的用户是没有编程基础的普通用户的情况下,如何让他们理解和描述要进行的操作,是另一个难题。

没有现成的编程语言可用

站在程序员的角度,在各种高级编程语言百家争鸣的今天,描述和实现“ API 编排”需求的方法有千万种。

静态语言有 C、C++、C#、JAVA、GO 等供我们选择,动态脚本语言有 Python、Lua、Perl、JavaScript、Ruby、Lisp 等多种选择。可以说任意组合一门静态语言+一门动态语言,都可以完美胜任我们的“动态 API 编排”任务。然而,当我们的用户被定义为“没有编程基础”,该问题就开始变得扑朔迷离。

后端 API 实现上的异构特性

由于微服务拆分的原则是让每个服务足够独立,对服务的实现语言和使用的技术,并不会做严格的限制,所以微服务天生就有异构的特性。

如果是同一个 team 开发各个子服务,可能会在 API 提供方式、调用方法上做一些简单约定。如果是由不同的 team 开发这些子服务,甚至还会存在 HTTP/RPC、RESTful/非 REST 这些可选项。如果需要兼容第三方 API,则还会存在编程语言差异,使用的技术差异等。

因此,对于一个对兼容性有足够考虑的 API 编排系统而言,承认和处理后端 API 的异构问题,是必然绕不过去的弯。

原子化的描述 API 的调用方法及构造输入输出参数

虽然 API 编排不是直接由程序员编写代码来构造一个 HTTP/RPC 调用来完成 API 访问,但其最终要实现的效果与前者高度一致。由于后端 API 天生的异构特性,使我们必须提供一种准确且易懂的描述方式,让用户告诉我们如下问题的答案:

  • API 的访问地址在哪?采用何种调用协议?
  • 是否需要身份认证?采用什么方法构造这个身份认证参数?构造身份认证参数的 API 私钥是什么?
  • 输入数参数从哪里来?放到哪里去?是否需要做简单的算术运算?
  • 输出数据是否需要进行加工?多个 API 的输出如何重新组装输出?

因此,描述和实现构造 API 调用参数的过程和方法,成为设计 API 编排系统中最关键的一环。

编排第三方 API 的身份认证问题

由于一般对外提供 API 服务的系统,都会加入身份认证功能,来保证 API 不会被非法调用,以此保证服务器安全与稳定。对于需要兼容第三方 API 的 API 编排系统而言,需要采用一种通用的描述方法,让实现 API 的第三方可以准确的描述自己实现的 API 所使用的身份认证方法。

常见的身份认证方法有:OIDC、 JWT、 bearer Tokens、Basic Auth、Signature 等等。其中 Signature 认证方法只是使用“签名”认证方式的一种统称。实际上采用何种算法,使用什么步骤来构造这个“签名字符串”,都需要有统一的方法来详细描述。

说明:
常见的“签名”构造方法有:参数排序方法、追加字符串、计算 HASH 值、计算 HMAC HASH、AES/RSA 加密解密、hex/base64/url 编码解码等等。

由于第三方所使用的身份认证方法的多样性,且没有统一的标准,因此对 API 编排系统而言,如何原子化的定义和描述这些身份认证方法,也是一个不容忽视的大课题。

API 及 API 私钥的权限问题

API 私钥(如:登录网络平台的用户名密码)是用户访问第三方 API 平台的唯一身份证明数据,对用户数据安全有着至关重要的作用。因此,用户是不会轻易将此数据泄露给任何不可信的第三方的。API 编排需要代理用户向第三方 API 服务器发起 API 调用请求,所以必须由用户提供此私钥才能完成该操作。

那么,问题的核心即变为,我们需要设计一套严密的安全体系,让用户信任我们的系统,将 API 私钥托管在平台是安全可信的。安全托管这些 API 私钥的必要环节包括:加密上传,加密存储,任何第三方用户使用需要授权,后端透明使用,内容对任何用户不可见。

总结

本期简单介绍了 API 网关在微服务架构下的必要性。重点介绍了 API 网关的核心功能,API 编排的应用范围和设计上面临的诸多难题和挑战。由于 API 编排需要面对无编程基础的普通用户服务,使得设计 API 编排服务变得像实现“没有编程语言”的编程体验一样有趣。

后期文章,我们将继续探讨 API 网关和 API 编排设计和实现上的一些思考和探索。敬请期待。

关于全象云

全象云是青云科技自主研发的工具和平台,是基于云原生、解耦的、可插拔的开放生态系统,用于辅助构建企业各类数字化应用。

平台目前提供云上无代码和低代码两种应用开发模式,屏蔽了技术的复杂度。支持可视化设计器,让开发人员和业务用户能够通过简单的拖拽、参数配置等方式快速完成应用开发。同时集成了身份认证能力、容器 DevOps 能力,支持企业存量业务与全象云业务融合。平台还包含丰富的开发接口和强大的插件机制,开发者可根据需要不断拓展平台的应用能力。

全象云的愿景是:在企业生产经营的各个象限、各个环节提供软件构件或支持服务。

API 编排的应用及痛点_第2张图片

你可能感兴趣的