关于golang:API-编排的应用及痛点

51次阅读

共计 2916 个字符,预计需要花费 8 分钟才能阅读完成。

作者:戴泽军

前言

随着微服务架构成为业界支流,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 能力,反对企业存量业务与全象云业务交融。平台还蕴含丰盛的开发接口和弱小的插件机制,开发者可依据须要一直拓展平台的利用能力。

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

正文完
 0