李 翔

(中遠(yuǎn)海運科技股份有限公司， 上海 200135)

0 引 言

隨著微服務(wù)架構(gòu)的不斷發(fā)展，各應(yīng)用服務(wù)之間的數(shù)據(jù)交互越來越多地采用應(yīng)用程序編程接口(Application Programming Interface，API)完成。API可完成系統(tǒng)內(nèi)部各組件和各系統(tǒng)間的數(shù)據(jù)交換。以API的方式進(jìn)行服務(wù)調(diào)用，可避免重復(fù)開發(fā)代碼，從而提高系統(tǒng)集成的效率；同時，各應(yīng)用系統(tǒng)間的數(shù)據(jù)孤島可被打破，數(shù)據(jù)資源可得到更加高效的利用。公司或組織(即API提供者)通過API的方式將其數(shù)據(jù)資產(chǎn)或服務(wù)提供給內(nèi)部或第三方(即API消費者)，能更好地開發(fā)和提升其業(yè)務(wù)價值[1]。目前，除了企業(yè)內(nèi)部，越來越多的互聯(lián)網(wǎng)企業(yè)開始采用API提供公共服務(wù)，即開放API(OpenAPI)。因此，企業(yè)內(nèi)部應(yīng)用系統(tǒng)可很好地利用OpenAPI為企業(yè)創(chuàng)新應(yīng)用賦能，提高系統(tǒng)的處理能力，擴大其業(yè)務(wù)范圍。

某大型集團(tuán)公司在信息化系統(tǒng)建設(shè)過程中形成了大量內(nèi)部API，如何便捷高效地對這些接口進(jìn)行管理，是該公司未來提升整體信息化服務(wù)能力需考慮的重點問題之一。對此，該公司通過對行業(yè)內(nèi)流行的商業(yè)和開源方案進(jìn)行比較，綜合考慮功能完整性、性能、定制開發(fā)能力和運營成本等多方面因素之后，最終選擇由WSO2開源的API-Manager(APIM)搭建API管理平臺，并在試運行期間針對原生平臺存在的不足進(jìn)行完善和二次研發(fā)，從而實現(xiàn)對API生成、管理和集成的全面管控，實現(xiàn)對應(yīng)用系統(tǒng)、數(shù)據(jù)庫和已存在的業(yè)務(wù)API的統(tǒng)一整合，提供連接各信息孤島的數(shù)據(jù)通路，進(jìn)而為數(shù)據(jù)融合、應(yīng)用重組和業(yè)務(wù)重構(gòu)奠定技術(shù)基礎(chǔ)。

1 平臺架構(gòu)設(shè)計

API管理平臺采用由WSO2開源的構(gòu)建于輕量企業(yè)服務(wù)總線(Enterprise Service Bus, ESB)組件Apache Synapse上的APIM設(shè)計。整個管理平臺采用微服務(wù)架構(gòu)，各組件可實現(xiàn)動態(tài)伸縮，保證平臺不存在性能瓶頸。平臺提供完善的API管理能力，具有限流、分項授權(quán)、后端負(fù)載均衡和故障轉(zhuǎn)移等功能。整個API管理平臺由開發(fā)者門戶、API發(fā)布組件、API網(wǎng)關(guān)、身份信息服務(wù)和統(tǒng)計服務(wù)等5部分組成，其架構(gòu)見圖1。

圖1 API管理平臺系統(tǒng)架構(gòu)

圖2 API生命周期管理流程

1.1 發(fā)布工具

API管理平臺通過API發(fā)布工具對API進(jìn)行生命周期管理，包括開發(fā)、發(fā)布、管理和監(jiān)控。在API管理平臺中，SOAP(Simple Object Access Protocol)風(fēng)格接口和Restful風(fēng)格接口都能得到良好的支持。

1) 對于Restful風(fēng)格的接口，API管理平臺通過集成Swagger工具提供支持。目前，基于Swagger YAML/JSON的API描述定義已成為Restful風(fēng)格API的事實性標(biāo)準(zhǔn)。在業(yè)務(wù)系統(tǒng)的接口開發(fā)中，通過Swagger相關(guān)工具包，可自動生成API的描述文檔。接口開發(fā)人員可通過將描述定義粘貼到發(fā)布工具中，完成對API的定義。

2) 對于SOAP風(fēng)格的接口，在發(fā)布工具中，可直接通過提供WSDL(Web Services Description Language)接口定義的方式完成對API的定義。

在完成接口定義之后，接口發(fā)布人員可指定接口后端服務(wù)的測試環(huán)境地址和生產(chǎn)環(huán)境地址，便于接口使用者對接口進(jìn)行測試和正式調(diào)用?？紤]到對分布式大規(guī)模系統(tǒng)的支持，發(fā)布工具中允許對各類地址定義多個后端，通過負(fù)載均衡提供更大的吞吐量和更強的并發(fā)性。

整個API的生命周期包含創(chuàng)建、原型、發(fā)布、阻止、棄用和下線等6個階段。各階段的轉(zhuǎn)換關(guān)系見圖2。

API生命周期各階段的含義如下。

1) 創(chuàng)建：API已在平臺中定義，但還沒有發(fā)布，此時API用戶無法看到對應(yīng)的API。

2) 原型：API以原型方式發(fā)布，已定義相關(guān)的接口，且通過平臺的簡單模擬實現(xiàn)對接口的反饋，該階段可與API用戶進(jìn)行接口原型設(shè)計。

3) 發(fā)布：API接口正式發(fā)布，服務(wù)上線。此時用戶可在開發(fā)者門戶中看到對應(yīng)的API。

4) 棄用：當(dāng)API接口后端服務(wù)被棄用，或有新版本的接口上線時，可棄用老版本的接口。此時，新用戶無法看到該API，但原用戶可繼續(xù)調(diào)用。

5) 下線：API接口終止服務(wù)，無法繼續(xù)調(diào)用。

6) 阻止：調(diào)用被臨時禁止，一般用于接口后端服務(wù)需進(jìn)行臨時維護(hù)的場景。

1.2 開發(fā)者門戶

開發(fā)者門戶為API的調(diào)用者提供API瀏覽和測試的支持。在開發(fā)者門戶中，API調(diào)用者可直接瀏覽API接口的定義，包括描述信息、參數(shù)定義和相關(guān)接口文檔等。同時，通過繼承Swagger工具，調(diào)用者可直接在頁面中對API接口進(jìn)行調(diào)用測試。

在瀏覽API的同時，API調(diào)用者可對API接口進(jìn)行訂閱，API接口只有在被訂閱之后才能調(diào)用。在訂閱時可選擇不同的并發(fā)等級，例如300次/s、500次/s等。不同的訂閱等級可對應(yīng)不同的費用級別，為后期API管理平臺實行計費提供支持。

1.3 API網(wǎng)關(guān)

API網(wǎng)關(guān)可看作一個復(fù)雜的反向代理，在API管理平臺中，所有的API調(diào)用都由網(wǎng)關(guān)完成。API調(diào)用者的調(diào)用請求到達(dá)網(wǎng)關(guān)之后，由網(wǎng)關(guān)完成身份認(rèn)證、調(diào)用并發(fā)限制和請求內(nèi)容檢查等操作，在滿足相關(guān)要求之后，數(shù)據(jù)被轉(zhuǎn)發(fā)至接口的后端服務(wù)中，完成接口調(diào)用。在完成請求轉(zhuǎn)發(fā)的同時，整個調(diào)用過程被完整地記錄下來，相關(guān)流水信息被發(fā)送至統(tǒng)計服務(wù)中進(jìn)行后續(xù)分析處理。

1.4 身份信息服務(wù)

身份信息服務(wù)提供對平臺整個用戶信息體系的管理。API管理平臺在調(diào)用接口過程中，其身份驗證采用的是OAuth2協(xié)議。Token的產(chǎn)生和生命周期管理等均由身份信息服務(wù)提供。同時，平臺支持對單獨API Endpoint進(jìn)行授權(quán)，相關(guān)的權(quán)限檢查也由身份信息服務(wù)完成。

1.5 統(tǒng)計服務(wù)

API的調(diào)用流水?dāng)?shù)據(jù)由網(wǎng)關(guān)產(chǎn)生之后被發(fā)送至統(tǒng)計服務(wù)中。統(tǒng)計服務(wù)采用流式計算框架Siddhi，在接收到調(diào)用流水?dāng)?shù)據(jù)之后，在內(nèi)存中進(jìn)行實時聚合，并定期寫入后臺數(shù)據(jù)庫中，形成各種維度的報表。

同時，各API接口的健康狀況由統(tǒng)計服務(wù)進(jìn)行分析。通過對得到的流水?dāng)?shù)據(jù)進(jìn)行分析，統(tǒng)計服務(wù)可獲得各API接口的運行情況，當(dāng)出現(xiàn)異常(例如1 min內(nèi)調(diào)用量發(fā)生急劇變化)時，能通過郵件等方式及時通知相關(guān)人員。

1.6 平臺部署

結(jié)合目前業(yè)界流行的容器管理技術(shù)，整個API管理平臺以微服務(wù)的方式部署在集團(tuán)內(nèi)部的Kubernetes容器平臺中。通過充分利用容器平臺高可用、高冗余的管理能力[2]，API管理平臺能根據(jù)負(fù)載進(jìn)行高效彈性伸縮和自動故障恢復(fù)的部署。同時，平臺擁有一定的“自愈”能力，當(dāng)某個微服務(wù)因出現(xiàn)故障而失效時，容器云會自動對其進(jìn)行重啟，實現(xiàn)快速恢復(fù)。在重啟期間，流量會定向至其他正常運行的微服務(wù)，保證服務(wù)不中斷。

2 平臺二次集成研發(fā)

通過使用APIM已有組件，整個API管理平臺能滿足企業(yè)內(nèi)部的大部分功能需求，但隨著平臺的部署實施和上線使用，已有組件逐漸無法滿足部分管理需求，如調(diào)用流水記錄、終端授權(quán)、用戶信息透傳和大數(shù)據(jù)監(jiān)控等。對此，還需引入其他組件，并進(jìn)行二次集成研發(fā)，對平臺的功能進(jìn)行完善和增強。

2.1 API調(diào)用流水記錄

在已有的功能組件中，API調(diào)用的流水記錄僅用于產(chǎn)生統(tǒng)計匯總數(shù)據(jù)，原始流水記錄并沒有保存，這對于服務(wù)于整個集團(tuán)的API管理平臺而言是一個較大的功能缺失項。

從使用的便捷性和功能的完整性的角度來說，日志管理平臺首推ELK(Elastic Search、Logstash、Kibana)。通過查閱統(tǒng)計分析服務(wù)的相關(guān)手冊得知，Siddhi支持RDBMS、KAFKA、ES和HTTP等方式的數(shù)據(jù)輸出。對此，參考已有的統(tǒng)計分析應(yīng)用，直接將API的流水記錄發(fā)送給Elastic Search集群。

上線運行一段時間之后，發(fā)現(xiàn)該方案存在以下不足：

1) 無法對數(shù)據(jù)的格式進(jìn)行調(diào)整。由于是直接從統(tǒng)計分析服務(wù)中寫入ES集群，中間沒有任何數(shù)據(jù)處理，無法利用Logstash強大的filter插件。

2) 穩(wěn)定性有一定的欠缺。由于統(tǒng)計分析服務(wù)中對流水記錄不作任何緩存，當(dāng)因某些外部原因?qū)е逻B接中斷時，流水記錄會丟失。

參考文獻(xiàn)[3]，引入KAFKA組件對消息進(jìn)行暫存，借以減輕Logstash的壓力，避免日志在處理之前丟失。新的消息傳輸機制見圖3。

圖3 新的消息傳輸機制

消息發(fā)送到KAFKA中暫存，由Logstash消費KAFKA獲取流水記錄，經(jīng)過Filter調(diào)整格式之后，發(fā)送至ES集群中進(jìn)行保存和后續(xù)查詢分析。

2.2 單個API Endpoint的授權(quán)

APIM發(fā)布工具可對整個API接口進(jìn)行授權(quán)，實現(xiàn)不同角色的人員查看不同的API。但是，在平臺運維過程中可能會出現(xiàn)一些特殊的權(quán)限管理要求，如API調(diào)用對象是一個系統(tǒng)而不是開發(fā)者，需分別對API中的Endpoint單獨授權(quán)。對此，采用XACML實現(xiàn)。

可擴展訪問控制標(biāo)記語言(eXtensible Access Control Markup Language，XACML)定義一種基于屬性的聲明性細(xì)粒度訪問控制策略語言、體系結(jié)構(gòu)和處理模型，描述如何根據(jù)策略中定義的規(guī)則評估訪問請求[4]。通過XACML，可描述如何控制某個具體API Endpoint的訪問權(quán)限，如要求調(diào)用者屬于某個角色，或角色名符合某個表達(dá)式等。

在身份信息服務(wù)中，采用內(nèi)置的XACML編輯器編寫相應(yīng)的業(yè)務(wù)控制規(guī)則，如某個API Endpoint需用戶屬于特定的角色。在規(guī)則發(fā)布之后，API網(wǎng)關(guān)將在調(diào)用API時按對應(yīng)的規(guī)則檢查。若符合規(guī)則要求，則正常轉(zhuǎn)發(fā)請求至后端服務(wù)，否則返回Http Code 403(Forbidden)，禁止用戶調(diào)用該API Endpoint。

XACML編輯器界面見圖4。

圖4 XACML編輯器界面

2.3 用戶信息透傳

由于API管理平臺具有透明性，在后端接口的服務(wù)中，默認(rèn)無法獲取當(dāng)前調(diào)用的用戶信息。一般的API對接流程是，API的后端服務(wù)不進(jìn)行身份驗證，由API管理平臺實現(xiàn)用戶管理，對于后端系統(tǒng)而言，所有的接口調(diào)用均匿名。在部分接口發(fā)布過程中，后端系統(tǒng)明確要求將當(dāng)前用戶的信息傳輸至后端系統(tǒng)中。對此，需對API管理平臺的傳輸機制進(jìn)行調(diào)整改造。

APIM平臺采用OAuth 2.0的身份認(rèn)證機制，在默認(rèn)配置下，采用Access Token進(jìn)行身份信息交互，簡單將該Token傳輸至后端系統(tǒng)中無法滿足需求。由此，對身份驗證服務(wù)的配置進(jìn)行調(diào)整，使其在傳輸調(diào)用信息至后端接口時生成一個包含當(dāng)前用戶信息的JWT Token，附加在Header中。后端接口通過對應(yīng)的Header字段獲取JWT Token，經(jīng)過解碼之后即可獲得相關(guān)的用戶信息。

在APIM平臺中，已存在相關(guān)的內(nèi)置類(DefaultClaimsRetriever)實現(xiàn)Token的生成和注入。由于此內(nèi)置類提供的用戶屬性較少，不滿足業(yè)務(wù)需求，需自行編程實現(xiàn)其他屬性的注入。編寫相應(yīng)的Java代碼，繼承APIM框架的AbstractJWTGenerator類，通過populateStandardClaims方法實現(xiàn)用戶指定屬性的注入。相關(guān)代碼如下：

public Map populateStandardClaims(TokenValidationContext validationContext) throws APIManagementException {

long currentTime = System.currentTimeMillis();

long expireIn = currentTime + getTTL() * 1000;

String applicationId = validationContext.getValidationInfoDTO().getApplicationId();

String tier = validationContext.getValidationInfoDTO().getTier();

String endUserName = validationContext.getValidationInfoDTO().getEndUserName();

String keyType = validationContext.getValidationInfoDTO().getType();

String applicationTier = validationContext.getValidationInfoDTO().getApplicationTier();

if (endUserName.endsWith("@carbon.super")) {

endUserName = endUserName.replace("@carbon.super", "");

}

Map claims = new LinkedHashMap(20);

claims.put("applicationid", applicationId);

claims.put("applicationtier", applicationTier);

claims.put("enduser", endUserName);

claims.put("exp", String.valueOf(expireIn));

claims.put("keytype", keyType);

claims.put("tier", tier);

claims.put("version", validationContext.getVersion());

return claims;

}

2.4 API管理平臺監(jiān)控大屏

在發(fā)布工具中，API管理平臺提供對API情況的分析，可從API調(diào)用次數(shù)、API調(diào)用者和我的API調(diào)用等維度進(jìn)行統(tǒng)計分析。但是，從API管理平臺管理的角度出發(fā)，已有的分析數(shù)據(jù)還不足以反映整個API管理平臺的運行情況。

為獲取已有API的統(tǒng)計數(shù)據(jù)和實時調(diào)用數(shù)據(jù)，從系統(tǒng)文檔出發(fā)，仔細(xì)對API管理平臺的開發(fā)者門戶和統(tǒng)計服務(wù)提供的相關(guān)API進(jìn)行梳理。針對2個方面的需求，逐一對照整理，形成以下結(jié)論：

1) 對于API數(shù)量和分類等靜態(tài)信息，可調(diào)用開發(fā)者門戶的接口；

2) 對于API調(diào)用次數(shù)和最近調(diào)用API等動態(tài)信息，可調(diào)用統(tǒng)計分析服務(wù)的接口。

統(tǒng)計分析服務(wù)使用的Siddhi組件采用的是類似大數(shù)據(jù)的處理方式，通過調(diào)用接口提交一個類SQL語句，可根據(jù)要求對統(tǒng)計數(shù)據(jù)進(jìn)行匯總計算，實現(xiàn)監(jiān)控大屏的數(shù)據(jù)源獲取。

例如，對于最近調(diào)用的API數(shù)據(jù)，可通過發(fā)送以下請求到統(tǒng)計分析服務(wù)中來獲取。

{

appName: "APIM_ACCESS_SUMMARY",

query: "from ApiLastAccessSummary on lastAccessTime > 1590984000000L select apiName, lastAccessTime order by lastAccessTime DESC;"

}

API管理平臺監(jiān)控大屏采用eCharts作為前端開發(fā)組件，采用Node.js開發(fā)后端服務(wù)，與統(tǒng)計分析和開發(fā)者門戶等服務(wù)進(jìn)行數(shù)據(jù)交互。最終的API管理平臺監(jiān)控大屏見圖5。

圖5 API管理平臺監(jiān)控大屏

通過一系列的功能完善，API管理平臺已能滿足整個公司內(nèi)部的API管理需求。通過引入Kafka并結(jié)合ELK，使得API管理平臺對API調(diào)用流水記錄的保存能力明顯增強，為后續(xù)基于流水?dāng)?shù)據(jù)的統(tǒng)計分析奠定了基礎(chǔ)。APIM組件提供了完整的API，可實現(xiàn)與其他應(yīng)用的數(shù)據(jù)集成。

3 結(jié) 語

目前，API管理平臺已正式服務(wù)于該公司，共發(fā)布API 100多個，接入的相關(guān)用戶和系統(tǒng)超過60個，累積調(diào)用次數(shù)已接近4 000萬次。通過建設(shè)API管理平臺，各業(yè)務(wù)系統(tǒng)間的數(shù)據(jù)和能力交換得以順利、高效進(jìn)行，各業(yè)務(wù)系統(tǒng)的開發(fā)效率得到明顯提升。通過引入外部的語音識別和文字識別等OpenAPI，業(yè)務(wù)系統(tǒng)的服務(wù)能力也得到明顯增強。

API管理平臺以微服務(wù)架構(gòu)部署在公司內(nèi)部的容器云上，平臺的可用性得到了較好的保障，為公司內(nèi)各關(guān)鍵應(yīng)用提供了高質(zhì)量的數(shù)據(jù)服務(wù)。得益于APIM的開放性，API管理平臺可根據(jù)業(yè)務(wù)需求進(jìn)行一系列的增強完善。通過對API管理平臺各組件的數(shù)據(jù)流進(jìn)行分析，并結(jié)合行業(yè)中的最佳實踐，平臺的整體服務(wù)能力得到了進(jìn)一步提升。