前言

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

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

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

API 编排应用

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

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

API 编排的优势

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

1、简化前端逻辑，一次 API 调用即可获取所有所需数据；

2、减少传输数据量，仅向前端发送需要展示的数据；

3、灵活的动态组合扩展特性，后端只需要实现“原子 API”，把业务需求交给消费方去自助配置，组合扩展；

4、同化调用方法，由 API 编排服务兼容异构实现的后端 API 的调用过程；

5、统一的身份认证和权限管理；

6、向前端隐藏第三方 API 的身份认证过程，由 API 编排服务兼容不同平台的 API 认证方法。

API 编排的痛点

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

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

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

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

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

3、没有现成的编程语言可用

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

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

4、后端 API 实现上的异构特性

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

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

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

5、原子化的描述 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编排引擎平台

API调用流程编排引擎（后端低代码产品），通过拖拉拽的可视化操作，将原子API或数据源操作组装成新的API，不写一行代码实现API，极大降低后端开发门槛，极大提升后端研发效率。主要帮助解决以下四大难题：

1、后端开发门槛高

传统后端研发门槛很高？要学编程语言、各种部署方式？

行云API编排引擎，拖拉拽操作将原子API、数据源操作组装成新的API，无需编码。技术人员只需要懂API、懂数据源操作即可“写”后端。

2、后端开发速度慢

传统开发，从代码编写、调试、编译、构建、部署、测试到上线，整个过程拉得很长？

行云API编排引擎，拖拉拽操作，免去传统开发代码编写、编译、构建、部署、测试，一键上线，快速发布。API声明、设计、发布、运维等直接一键完成，完全省掉coding和CI过程。

3、后端开发质量差

传统后端开发出来API质量差？需要经常返工，且一个小修改需要等一个迭代周期？

行云API编排引擎，免代码编写，降低犯错概率；API编排可视化，逻辑可视化，可以直接与研发主管、测试工程师、产品经理一起review，快速修改。

4、工具不够灵活

市面上大部分的研发工具不支持可插拔，必须捆绑销售，不利于企业选择，且部署周期长。

行云API编排平台支持以插件方式与企业的各种数据源对接，快速实现业务；支持与企业认证中心对接，实现API的认证；与API测试产品、API市场无缝集成。

API编排工具，免费在线体验>

API编排引擎，了解更多详情>