雪鹰领主,小说阅读网,完美世界国际版下载

后端低代碼：API編排引擎的優(yōu)勢與挑戰(zhàn)

2022-07-27

1221

前言

隨著微服務(wù)架構(gòu)成為業(yè)界主流，API 網(wǎng)關(guān)作為訪問微服務(wù)集群內(nèi)所有 API 的唯一出入口，地位顯得尤為重要。

集群內(nèi)微服務(wù)功能拆分越來越細，對后端而言，模塊在獨立性、復用性、可維護性方面的優(yōu)勢不言而喻。但對前端而言，復雜性卻隨之而來。一個前端頁面，往往需要從數(shù)個甚至數(shù)十個 API 中請求數(shù)據(jù)，而這些 API，很可能還存在如下異構(gòu)特性：托管 host 不同、實現(xiàn)語言不同、調(diào)用方式不同。

面對這樣的難題，API 網(wǎng)關(guān)的需求應(yīng)運而生：統(tǒng)一出口、隱藏實現(xiàn)、安全控制、流量控制、負載均衡、權(quán)限控制、API 管理等等。這些問題及其解決方案將在后續(xù)的文章中一一介紹。本期我們重點討論 API 網(wǎng)關(guān)的另一個重要功能：API 編排。

API編排

API 編排應(yīng)用

所謂 API 編排，就是在 API 網(wǎng)關(guān)中實現(xiàn)一種機制，用于靈活調(diào)用和組裝后端原生 API，使前端能夠根據(jù)業(yè)務(wù)需求，定制實現(xiàn)頁面所需的聚合 API。其地位和作用，可相較于“Shell 之于 *nix”。

與后端微服務(wù) API 以“高內(nèi)聚”為目標不同，聚合 API 以業(yè)務(wù)需求為導向，通過簡單組合已有的原生 API，在后端代理調(diào)用多個API，并對輸出數(shù)據(jù)進行重新剪裁組裝。

API 編排的優(yōu)勢

與前端直接調(diào)用多個異構(gòu)的后端 API 相比，聚合 API 具有很明顯的優(yōu)勢：

1、簡化前端邏輯，一次 API 調(diào)用即可獲取所有所需數(shù)據(jù)；

2、減少傳輸數(shù)據(jù)量，僅向前端發(fā)送需要展示的數(shù)據(jù)；

3、靈活的動態(tài)組合擴展特性，后端只需要實現(xiàn)“原子 API”，把業(yè)務(wù)需求交給消費方去自助配置，組合擴展；

4、同化調(diào)用方法，由 API 編排服務(wù)兼容異構(gòu)實現(xiàn)的后端 API 的調(diào)用過程；

5、統(tǒng)一的身份認證和權(quán)限管理；

6、向前端隱藏第三方 API 的身份認證過程，由 API 編排服務(wù)兼容不同平臺的 API 認證方法。

API 編排的痛點

1、面向沒有編程基礎(chǔ)的普通用戶服務(wù)

由于 API 編排具有“用戶自助”的特性，注定了其用戶“既是生產(chǎn)者又是消費者”。而任何網(wǎng)絡(luò)平臺的用戶，都必須假定為“沒有編程基礎(chǔ)”，即面向沒有編程經(jīng)驗的普通用戶服務(wù)。

2、功能需要覆蓋完備的編程元素

API 編排需要構(gòu)造多個 API 調(diào)用，捕獲和剪裁輸出數(shù)據(jù)，同時也可能存在分支和根據(jù)條件重復處理等需求。

我們的編程啟蒙老師一定都講過，編程無非就是順序+選擇+循環(huán)?？梢姡幊趟杷性?，在 API 編排中皆有需求。然而，在我們的用戶是沒有編程基礎(chǔ)的普通用戶的情況下，如何讓他們理解和描述要進行的操作，是另一個難題。

3、沒有現(xiàn)成的編程語言可用

站在程序員的角度，在各種高級編程語言百家爭鳴的今天，描述和實現(xiàn)“ API 編排”需求的方法有千萬種。

靜態(tài)語言有 C、C++、C#、JAVA、GO 等供我們選擇，動態(tài)腳本語言有 Python、Lua、Perl、JavaScript、Ruby、Lisp 等多種選擇?？梢哉f任意組合一門靜態(tài)語言+一門動態(tài)語言，都可以完美勝任我們的“動態(tài) API 編排”任務(wù)。然而，當我們的用戶被定義為“沒有編程基礎(chǔ)”，該問題就開始變得撲朔迷離。

4、后端 API 實現(xiàn)上的異構(gòu)特性

由于微服務(wù)拆分的原則是讓每個服務(wù)足夠獨立，對服務(wù)的實現(xiàn)語言和使用的技術(shù)，并不會做嚴格的限制，所以微服務(wù)天生就有異構(gòu)的特性。

如果是同一個 team 開發(fā)各個子服務(wù)，可能會在 API 提供方式、調(diào)用方法上做一些簡單約定。如果是由不同的 team 開發(fā)這些子服務(wù)，甚至還會存在 HTTP/RPC、RESTful/非 REST 這些可選項。如果需要兼容第三方 API，則還會存在編程語言差異，使用的技術(shù)差異等。

因此，對于一個對兼容性有足夠考慮的 API 編排系統(tǒng)而言，承認和處理后端 API 的異構(gòu)問題，是必然繞不過去的彎。

5、原子化的描述 API 的調(diào)用方法及構(gòu)造輸入輸出參數(shù)

雖然 API 編排不是直接由程序員編寫代碼來構(gòu)造一個 HTTP/RPC 調(diào)用來完成 API 訪問，但其最終要實現(xiàn)的效果與前者高度一致。由于后端 API 天生的異構(gòu)特性，使我們必須提供一種準確且易懂的描述方式，讓用戶告訴我們?nèi)缦聠栴}的答案：

· API 的訪問地址在哪？采用何種調(diào)用協(xié)議？

· 是否需要身份認證？采用什么方法構(gòu)造這個身份認證參數(shù)？構(gòu)造身份認證參數(shù)的 API 私鑰是什么？

· 輸入數(shù)參數(shù)從哪里來？放到哪里去？是否需要做簡單的算術(shù)運算？

· 輸出數(shù)據(jù)是否需要進行加工？多個 API 的輸出如何重新組裝輸出？

因此，描述和實現(xiàn)構(gòu)造 API 調(diào)用參數(shù)的過程和方法，成為設(shè)計 API 編排系統(tǒng)中最關(guān)鍵的一環(huán)。

編排第三方 API 的身份認證問題

由于一般對外提供 API 服務(wù)的系統(tǒng)，都會加入身份認證功能，來保證 API 不會被非法調(diào)用，以此保證服務(wù)器安全與穩(wěn)定。對于需要兼容第三方 API 的 API 編排系統(tǒng)而言，需要采用一種通用的描述方法，讓實現(xiàn) API 的第三方可以準確的描述自己實現(xiàn)的 API 所使用的身份認證方法。

常見的身份認證方法有：OIDC、 JWT、 bearer Tokens、Basic Auth、Signature 等等。其中 Signature 認證方法只是使用“簽名”認證方式的一種統(tǒng)稱。實際上采用何種算法，使用什么步驟來構(gòu)造這個“簽名字符串”，都需要有統(tǒng)一的方法來詳細描述。

說明：

常見的“簽名”構(gòu)造方法有：參數(shù)排序方法、追加字符串、計算 HASH 值、計算 HMAC HASH、AES/RSA 加密解密、hex/base64/url 編碼解碼等等。

由于第三方所使用的身份認證方法的多樣性，且沒有統(tǒng)一的標準，因此對 API 編排系統(tǒng)而言，如何原子化的定義和描述這些身份認證方法，也是一個不容忽視的大課題。

API 及 API 私鑰的權(quán)限問題

API 私鑰（如：登錄網(wǎng)絡(luò)平臺的用戶名密碼）是用戶訪問第三方 API 平臺的唯一身份證明數(shù)據(jù)，對用戶數(shù)據(jù)安全有著至關(guān)重要的作用。因此，用戶是不會輕易將此數(shù)據(jù)泄露給任何不可信的第三方的。API 編排需要代理用戶向第三方 API 服務(wù)器發(fā)起 API 調(diào)用請求，所以必須由用戶提供此私鑰才能完成該操作。

那么，問題的核心即變?yōu)?，我們需要設(shè)計一套嚴密的安全體系，讓用戶信任我們的系統(tǒng)，將 API 私鑰托管在平臺是安全可信的。安全托管這些 API 私鑰的必要環(huán)節(jié)包括：加密上傳，加密存儲，任何第三方用戶使用需要授權(quán)，后端透明使用，內(nèi)容對任何用戶不可見。

總結(jié)

本期簡單介紹了 API 網(wǎng)關(guān)在微服務(wù)架構(gòu)下的必要性。重點介紹了 API 網(wǎng)關(guān)的核心功能，API 編排的應(yīng)用范圍和設(shè)計上面臨的諸多難題和挑戰(zhàn)。由于 API 編排需要面對無編程基礎(chǔ)的普通用戶服務(wù)，使得設(shè)計 API 編排服務(wù)變得像實現(xiàn)“沒有編程語言”的編程體驗一樣有趣。

API編排工具，免費在線體驗>

-----------------

kaiyun開云創(chuàng)新API編排引擎平臺

API調(diào)用流程編排引擎（后端低代碼產(chǎn)品），通過拖拉拽的可視化操作，將原子API或數(shù)據(jù)源操作組裝成新的API，不寫一行代碼實現(xiàn)API，極大降低后端開發(fā)門檻，極大提升后端研發(fā)效率。主要幫助解決以下四大難題：

1、后端開發(fā)門檻高

傳統(tǒng)后端研發(fā)門檻很高？要學編程語言、各種部署方式？

行云API編排引擎，拖拉拽操作將原子API、數(shù)據(jù)源操作組裝成新的API，無需編碼。技術(shù)人員只需要懂API、懂數(shù)據(jù)源操作即可“寫”后端。

2、后端開發(fā)速度慢

傳統(tǒng)開發(fā)，從代碼編寫、調(diào)試、編譯、構(gòu)建、部署、測試到上線，整個過程拉得很長？

行云API編排引擎，拖拉拽操作，免去傳統(tǒng)開發(fā)代碼編寫、編譯、構(gòu)建、部署、測試，一鍵上線，快速發(fā)布。API聲明、設(shè)計、發(fā)布、運維等直接一鍵完成，完全省掉coding和CI過程。

3、后端開發(fā)質(zhì)量差

傳統(tǒng)后端開發(fā)出來API質(zhì)量差？需要經(jīng)常返工，且一個小修改需要等一個迭代周期？

行云API編排引擎，免代碼編寫，降低犯錯概率；API編排可視化，邏輯可視化，可以直接與研發(fā)主管、測試工程師、產(chǎn)品經(jīng)理一起review，快速修改。

4、工具不夠靈活

市面上大部分的研發(fā)工具不支持可插拔，必須捆綁銷售，不利于企業(yè)選擇，且部署周期長。

行云API編排平臺支持以插件方式與企業(yè)的各種數(shù)據(jù)源對接，快速實現(xiàn)業(yè)務(wù)；支持與企業(yè)認證中心對接，實現(xiàn)API的認證；與API測試產(chǎn)品、API市場無縫集成。

API編排工具，免費在線體驗>

下一篇：web3.0時代，云原生將是重要的技術(shù)底座