作者：戴泽军
前言
随着微服务架构成为业界支流，API 网关作为拜访微服务集群内所有 API 的惟一出入口，位置显得尤为重要。
集群内微服务性能拆分越来越细，对后端而言，模块在独立性、复用性、可维护性方面的劣势显而易见。但对前端而言，复杂性却随之而来。一个前端页面，往往须要从数个甚至数十个 API 中申请数据，而这些 API，很可能还存在如下异构个性：托管 host 不同、实现语言不同、调用形式不同。
面对这样的难题，API 网关的需要应运而生：对立进口、暗藏实现、安全控制、流量管制、负载平衡、权限管制、API 治理等等。这些问题及其解决方案将在后续的文章中一一介绍。本期咱们重点探讨 API 网关的另一个重要性能：API 编排。
API 编排的利用
所谓 API 编排，就是通过 API 网关实现一种机制，能够灵便调用和组装后端原生 API，使前端可能依据业务需要，定制化页面所需的聚合 API。其位置和作用，可相较于“Shell 之于 *nix”。
一个典型的 API 编排利用案例如下：
图注：图中方框大小示意调用时数据量大小
能够看出，与后端微服务 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 能力，反对企业存量业务与全象云业务交融。平台还蕴含丰盛的开发接口和弱小的插件机制，开发者可依据须要一直拓展平台的利用能力。
全象云的愿景是：在企业生产经营的各个象限、各个环节提供软件构件或反对服务。