前言

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

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

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

API編排引擎，免費(fèi)在線體驗(yàn)>https://www.cloudtogo.cn/PaaS/API.html.

API 編排應(yīng)用

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

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

API 編排的優(yōu)勢(shì)

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

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

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

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

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

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

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

API 編排的痛點(diǎn)

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

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

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

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

我們的編程啟蒙老師一定都講過，編程無非就是順序+選擇+循環(huán)。可見，編程所需所有元素，在 API 編排中皆有需求。然而，在我們的用戶是沒有編程基礎(chǔ)的普通用戶的情況下，如何讓他們理解和描述要進(jìn)行的操作，是另一個(gè)難題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

編排第三方 API 的身份認(rèn)證問題

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

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

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

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

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

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

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

總結(jié)

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

API編排引擎，免費(fèi)在線體驗(yàn)>https://www.cloudtogo.cn/PaaS/API.html.

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

行云創(chuàng)新API編排引擎平臺(tái)

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

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

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

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

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

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

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

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

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

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

4、工具不夠靈活

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

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