張 虎，張秋萍

(齊魯工業(yè)大學(xué)(山東省科學(xué)院)山東省計(jì)算中心(國(guó)家超級(jí)計(jì)算濟(jì)南中心)山東省計(jì)算機(jī)網(wǎng)絡(luò)重點(diǎn)實(shí)驗(yàn)室，山東 濟(jì)南 250000)

1 概 述

隨著云計(jì)算平臺(tái)[1]功能的不斷豐富，用于支撐云計(jì)算平臺(tái)功能的子系統(tǒng)也在不斷增加。當(dāng)前的云平臺(tái)支持物理資源的虛擬化[2]功能、應(yīng)用的自動(dòng)化部署功能、物理資源的監(jiān)控功能、消息隊(duì)列功能、對(duì)象存儲(chǔ)[3]功能、短信郵件通知功能等等。

這些功能往往是通過(guò)不同的子系統(tǒng)來(lái)完成的。例如，物理資源的虛擬化功能由Openstack[4]系統(tǒng)支撐，應(yīng)用的自動(dòng)化部署由Cloudfoundry系統(tǒng)支撐，物理資源的監(jiān)控功能由Zabbix[5]系統(tǒng)支撐，消息隊(duì)列功能由RabbitMQ[6]系統(tǒng)支撐，對(duì)象存儲(chǔ)功能由Swift[7]系統(tǒng)支撐，短信和郵件通知功能分別由騰訊云服務(wù)支撐。

這只是列舉了云計(jì)算平臺(tái)的常用功能，就已經(jīng)涉及到這么多的子系統(tǒng)，而且每一個(gè)子系統(tǒng)都有其獨(dú)立的API系統(tǒng)，這就導(dǎo)致了云計(jì)算平臺(tái)需要分別調(diào)用不同子系統(tǒng)的API。平臺(tái)架構(gòu)如圖1所示。

圖1 傳統(tǒng)云計(jì)算平臺(tái)框架

由于子系統(tǒng)的開發(fā)團(tuán)隊(duì)和開發(fā)風(fēng)格的不同，導(dǎo)致了每個(gè)子系統(tǒng)的API格式也不相同。如果由云計(jì)算平臺(tái)來(lái)調(diào)用不同子系統(tǒng)，不同格式的API，不僅增加了云計(jì)算平臺(tái)的開發(fā)工作量，也為云計(jì)算平臺(tái)的日常維護(hù)和排除增加了困難。因此，如何使用統(tǒng)一的方式來(lái)調(diào)用不同系統(tǒng)的API是亟待需要解決的問(wèn)題。

針對(duì)上述需求，文中提出了通過(guò)接口網(wǎng)關(guān)Kong來(lái)集成不同子系統(tǒng)API的方法。具體來(lái)說(shuō)，KONG統(tǒng)一接收云計(jì)算平臺(tái)發(fā)送給不同子系統(tǒng)的請(qǐng)求，通過(guò)url路徑的不同來(lái)轉(zhuǎn)發(fā)給不同的子系統(tǒng)。在轉(zhuǎn)發(fā)的過(guò)程中還會(huì)根據(jù)每個(gè)子系統(tǒng)的不同，轉(zhuǎn)換請(qǐng)求的格式，以匹配不同子系統(tǒng)的API格式。通過(guò)這種方式，能夠?qū)崿F(xiàn)云計(jì)算平臺(tái)使用統(tǒng)一的格式調(diào)用不同子系統(tǒng)的API。加入API集成系統(tǒng)后的云計(jì)算平臺(tái)架構(gòu)，如圖2所示。

圖2 改進(jìn)云計(jì)算平臺(tái)框架

文中描述的API集成系統(tǒng)，不僅適用于云計(jì)算平臺(tái)，而且適用于任何多子系統(tǒng)調(diào)用的平臺(tái)。

2 接口網(wǎng)關(guān)Kong簡(jiǎn)介

Kong是Mashape公司的開源API網(wǎng)關(guān)。Kong是在客戶端和(微)服務(wù)間轉(zhuǎn)發(fā)API通信的API網(wǎng)關(guān)。其底層是由NGINX[8]驅(qū)動(dòng)的，所以性能方面與NGINX相同。

Kong原生支持主流數(shù)據(jù)庫(kù)的讀寫操作，包括Cassandra[9]、PostgreSQL[10]等。Kong可以將用戶的自定義路徑與訪問(wèn)路徑寫入數(shù)據(jù)庫(kù)，在轉(zhuǎn)發(fā)請(qǐng)求時(shí)動(dòng)態(tài)改變請(qǐng)求的目的地址。這有利于用戶靈活地添加轉(zhuǎn)發(fā)地址，并且可以靈活地設(shè)計(jì)不同功能的插件。而NGINX只能通過(guò)配置文件的方式來(lái)完成這些功能，而且配置好之后需要重啟NGINX的服務(wù)，這是很多長(zhǎng)期服役的服務(wù)所不能接受的。

Kong支持多節(jié)點(diǎn)的集群[11]，這可以使Kong支持更多的訪問(wèn)流量，同時(shí)保證極低的網(wǎng)絡(luò)延時(shí)。一個(gè)集群中的所有節(jié)點(diǎn)配置都是相同的，并且共用一個(gè)數(shù)據(jù)庫(kù)。出于性能的原因，在轉(zhuǎn)發(fā)請(qǐng)求時(shí)避免頻繁數(shù)據(jù)庫(kù)的訪問(wèn)，集群中的每個(gè)節(jié)點(diǎn)都會(huì)在本地緩存一部分?jǐn)?shù)據(jù)，并且緩存的數(shù)據(jù)也是每個(gè)節(jié)點(diǎn)都相同的。

Kong具有模塊性：它可以與新的插件協(xié)同運(yùn)行，擴(kuò)展基本功能?？蓪PI與許多不同的插件進(jìn)行整合，以增強(qiáng)安全、分析、驗(yàn)證、日志及/或監(jiān)測(cè)機(jī)制。并且Kong的插件可以訪問(wèn)Kong系統(tǒng)的數(shù)據(jù)庫(kù)。本API接口集成系統(tǒng)，就是使用Kong的這一特性，開發(fā)出不同API格式轉(zhuǎn)換的插件，并且將這些插件分別綁定到不同子系統(tǒng)的API接口上，實(shí)現(xiàn)統(tǒng)一格式調(diào)用不同格式API的功能。

目前很多公司都在使用Kong，例如CISO、Aol、Intel、Expedia等。本API集成系統(tǒng)也是基于開源版KONG設(shè)計(jì)和實(shí)現(xiàn)的。

3 API集成系統(tǒng)

文中主要介紹API集成系統(tǒng)的工作方式，并將API集成系統(tǒng)應(yīng)用于集成Openstack和Zabbix接口。其中Openstack是主流的IaaS[12]開源管理平臺(tái)；而Zabbix則是功能強(qiáng)大的主機(jī)監(jiān)控平臺(tái)。這兩個(gè)平臺(tái)應(yīng)用廣泛，而且兩個(gè)平臺(tái)的接口格式不同。Openstack接口是標(biāo)準(zhǔn)的RestfulAPI[13]接口，而Zabbix系統(tǒng)的API接口則采用的是JSON-RPC 2.0[14]規(guī)范，所以通過(guò)API集成系統(tǒng)集成這兩個(gè)平臺(tái)的接口能夠很好地說(shuō)明API集成系統(tǒng)的工作方式和優(yōu)點(diǎn)。需要說(shuō)明的是，文中方法不僅可以集成Openstack和Zabbix的接口，只要是API格式不統(tǒng)一的系統(tǒng)，都可以使用該方法進(jìn)行集成。

4 API集成系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

4.1 在Kong中創(chuàng)建需要轉(zhuǎn)發(fā)的API

Kong提供了完善的管理接口，用來(lái)完成對(duì)Kong的管理功能。默認(rèn)情況下，Kong服務(wù)的8001端口用于管理API的響應(yīng)；8000端口用于接收需要轉(zhuǎn)發(fā)的請(qǐng)求。下面就是用Kong的管理接口來(lái)新建Openstack和Zabbix的轉(zhuǎn)發(fā)API。

創(chuàng)建Openstack的轉(zhuǎn)發(fā)API的形式如下：

POST:http://KONG_HOST:8001/apis/

Body：{"name": "openstack_api", "uris": "openstack","upstream_url":"http://OPENSTACK_HOST","strip_uri":"true"}

這樣創(chuàng)建Openstack轉(zhuǎn)發(fā)API后，用戶請(qǐng)求http://KONG_HOST:8000/openstack，Kong就能夠?qū)⒄?qǐng)求自動(dòng)轉(zhuǎn)發(fā)到http://OPENSTACK_HOST。其中KONG_HOST和OPENSTACK_HOST分別表示Kong和Openstack的請(qǐng)求地址。

該請(qǐng)求Body中的參數(shù)含義如下：name為轉(zhuǎn)發(fā)API的名稱；uris為用戶情況Kong的API路徑；upstream_url為請(qǐng)求轉(zhuǎn)發(fā)的路徑；strip_uri為是否在轉(zhuǎn)發(fā)過(guò)程中隱藏uris中設(shè)置的路徑。

創(chuàng)建Zabbix的轉(zhuǎn)發(fā)API的形式如下：

POST：http://KONG_HOST:8001/apis/

Body:{"name":"zabbix_api","uris":"zabbix", "upstream_url":"http://ZABBIX_HOST", "strip_uri":"true"}

Openstack和Zabbix轉(zhuǎn)發(fā)API創(chuàng)建成功后，Kong可以根據(jù)用戶請(qǐng)求的路徑不同，將用戶的請(qǐng)求分別轉(zhuǎn)發(fā)給Openstack和Zabbix。

4.2 Zabbix API轉(zhuǎn)發(fā)處理插件的設(shè)計(jì)并實(shí)現(xiàn)

上一節(jié)創(chuàng)建了用于轉(zhuǎn)發(fā)的API。但是Zabbix能夠接收的請(qǐng)求并不是常用的restfulAPI請(qǐng)求。Zabbix接收的請(qǐng)求方法、URL、Headers和Body體形式如下：

POST http://zabbix /zabbix/api_jsonrpc.php

Headers：Content-Type: application/json-rpc

Body:{"jsonrpc":"2.0","method": "apiinfo.version","id":1,"auth":null,"params":{}}

Openstack接收的請(qǐng)求方法、URL、Headers和Body體形式如下：

POST http://openstack.com/openstack/api

Headers：Content-Type: application/json；X-Auth-Token: TOKEN-ID

Body：{“task_id”: null}

通過(guò)Zabbix和Openstack的接口調(diào)用方式可以看出，兩個(gè)系統(tǒng)的API系統(tǒng)有很大的差別。主要體現(xiàn)在Headers和Body信息中。如果想要使用統(tǒng)一的方式來(lái)完成兩個(gè)系統(tǒng)的API接口調(diào)用，可以對(duì)其中一個(gè)系統(tǒng)的API系統(tǒng)進(jìn)行改進(jìn)。但是改進(jìn)API系統(tǒng)的工作是非常復(fù)雜和繁重的，需要花費(fèi)大量的人力，而且還不一定能夠做到穩(wěn)定。

使用Kong可以很好地解決這個(gè)問(wèn)題。Kong提供了插件(Plugin)的功能。Kong的插件能夠綁定到不同的轉(zhuǎn)發(fā)API上，并且能夠?qū)τ脩舻恼?qǐng)求和服務(wù)的響應(yīng)做修改。通過(guò)Kong的插件，可以修改請(qǐng)求和響應(yīng)的url、headers和body。所以，在該系統(tǒng)中主要設(shè)計(jì)了針對(duì)修改Zabbix請(qǐng)求的Kong插件，并且綁定在Kong轉(zhuǎn)發(fā)Zabbix的接口上，將Zabbix的接口調(diào)用方式改為Openstack的接口調(diào)用方式，實(shí)現(xiàn)了兩個(gè)系統(tǒng)API請(qǐng)求的統(tǒng)一。

通過(guò)比較Openstack和Zabbix的接口調(diào)用方式可以看出，要想使用Openstack接口調(diào)用的方式調(diào)用Zabbix的接口，Kong的插件所需要做的工作為：

(1)請(qǐng)求Zabbix接口時(shí)，在Body中添加“jsonrpc”和“id”參數(shù)。

(2)請(qǐng)求Zabbix接口時(shí)，讀取Header中的X-Auth-Token數(shù)據(jù)，并寫到Body的auth中。

(3)請(qǐng)求Zabbix接口時(shí)，將Header中的Content-Type改為application/json-rpc。

(4)在請(qǐng)求返回的body中去除“jsonrpc”和“id”參數(shù)。

Kong的插件是lua[15]語(yǔ)言書寫，并且基于lua-nginx-module模塊，所以必須熟悉lua語(yǔ)言、lua-nginx-module模塊和Kong的環(huán)境才能完成Kong插件的編寫工作。

一個(gè)簡(jiǎn)單的Kong插件，必須包含兩個(gè)文件：schema.lua和handler.lua。其中schema.lua文件是用于插件的用戶配置，允許用戶在使用插件時(shí)根據(jù)不同的需求做出不同的配置。下面schema.lua的內(nèi)容設(shè)置了插件沒(méi)有消費(fèi)者：

return {no_consumer=true}

handler.lua文件是插件的核心，所有的API處理流程和邏輯都在這個(gè)文件中完成。在該文件中，將一個(gè)完整的請(qǐng)求拆分為七個(gè)過(guò)程，并將七個(gè)過(guò)程使用七個(gè)函數(shù)來(lái)表示。在不同的Kong插件中可以重寫這七個(gè)函數(shù)來(lái)完成不同階段所執(zhí)行的工作。這七個(gè)函數(shù)及其代表的執(zhí)行階段分別是:

(1)init_worker():初始化的工作階段執(zhí)行；

(2)certificate():SSL握手的階段執(zhí)行；

(3)rewrite():重寫階段時(shí)執(zhí)行；

(4)access():轉(zhuǎn)發(fā)之前對(duì)請(qǐng)求處理的階段執(zhí)行；

(5)header_filter():接收到所有的響應(yīng)頭時(shí)執(zhí)行；

(6)body_filter():接收到所有的響應(yīng)body時(shí)執(zhí)行；

(7)log():將響應(yīng)信息發(fā)送給請(qǐng)求端之后執(zhí)行。

因此，需要在access()函數(shù)中完成添加“jsonrpc”和“id”參數(shù)的功能；在access()函數(shù)中完成修改Header的功能；在body_filter()函數(shù)中完成去掉“jsonrpc”和“id”參數(shù)的功能。

在access()函數(shù)中完成讀取Header的“X-Auth-Token”參數(shù)，“X-Auth-Token”、“jsonrpc”和“id”參數(shù)的功能代碼如下：

localcjson=require "cjson"

localngx=ngx

localget_headers=ngx.req.get_headers

localset_headers=ngx.req.set_headers

set_header("Content-Type","application/json-rpc")

token_id=get_headers()["X-Auth-Token "]

ngx.req.read_body()

body=cjson.decode(ngx.req.get_body_data())

iftoken_id!=nil then

body[“auth”]=token_id

end

body[“jsonrpc”]=“2.0”

body[“id”]=1

ngx.req.set_body_data(cjson.encode(body))

以上這段代碼通過(guò)lua-nginx-module提供的功能，將X-Auth-Token的數(shù)據(jù)從Header中取出，并且填入Body中；然后在Body中添加jsonrpc和id的參數(shù)。

在body_filter()函數(shù)中完成去掉響應(yīng)body中的“jsonrpc”和“id”參數(shù)，其功能代碼為：

local chunk, eof=ngx.arg[1], ngx.arg[2]

ifeof then

body=ngx.ctx.buffer

fori,v in ipairs(body) do

if table[i]==“jsonrpc” then

table.remove(body, i)

end

end

ngx.arg[1]=body

else

ngx.ctx.buffer=ngx.ctx.buffer..chunk

ngx.arg[1]=nil

end

在Kong中，body可能很大，需要多次接收才能全部接收完。所以以上代碼塊就是循環(huán)接收body的分塊數(shù)據(jù)，組裝成完整的body，并且將body中的“jsonrpc”和“id”參數(shù)刪除，最后返回到請(qǐng)求端。

通過(guò)handler.lua中的兩個(gè)函數(shù)，就能夠?qū)崿F(xiàn)將Zabbix的接口調(diào)用形式與Openstack的接口調(diào)用形式統(tǒng)一。下面需要使插件生效，并且綁定到Zabbix的轉(zhuǎn)發(fā)API上，使其處理Zabbix的請(qǐng)求。

4.3 插件發(fā)布并生效

發(fā)布插件非常簡(jiǎn)單，只需要將插件的文件存放在./kong/plugins下，并在Kong的配置文件中增加custom_plungins字段，添加插件的名稱，具體格式如下：

custom_plugins=zabbix-api-plugins

配置文件修改完成后，重啟Kong，插件發(fā)布完成。

將zabbix-api-plugins插件綁定到4.1節(jié)中創(chuàng)建的Zabbix的轉(zhuǎn)發(fā)API上，使其生效。綁定的操作為：

POST：http://KONG_HOST:8001/apis/ zabbix_api/zabbix-api-plugins/

Body：{"name":"zabbix-api-plugins"}

將插件綁定的Zabbix轉(zhuǎn)發(fā)到API上后，Kong在轉(zhuǎn)發(fā)請(qǐng)求Zabbix的API時(shí)，就能夠自動(dòng)完成4.2節(jié)中設(shè)置的格式轉(zhuǎn)換。

5 結(jié)束語(yǔ)

通過(guò)curl[16]命令來(lái)進(jìn)行測(cè)試，驗(yàn)證該系統(tǒng)能夠根據(jù)Openstack的格式來(lái)正常請(qǐng)求Zabbix的API，測(cè)試結(jié)果如圖3所示。

圖3 測(cè)試結(jié)果

圖3是通過(guò)curl對(duì)Zabbix登錄接口的調(diào)用。在這次調(diào)用過(guò)程中，沒(méi)有使用Zabbix的原始調(diào)用方式，但是能夠正常返回調(diào)用結(jié)果，實(shí)現(xiàn)了Zabbix與Openstack的接口調(diào)用方式的統(tǒng)一。

以上介紹了基于接口網(wǎng)關(guān)Kong的云計(jì)算平臺(tái)API集成系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。通過(guò)API集成系統(tǒng)轉(zhuǎn)發(fā)所有云計(jì)算平臺(tái)子系統(tǒng)的API請(qǐng)求，實(shí)現(xiàn)了地址的隱藏和統(tǒng)一調(diào)用的功能。而且通過(guò)給不同的轉(zhuǎn)發(fā)API綁定不同的插件，可以完成使用統(tǒng)一的格式來(lái)調(diào)用不同的子系統(tǒng)API。減少了開發(fā)人員和接口使用人員的工作量，也減少了二次開發(fā)人員的學(xué)習(xí)成本。而且Kong支持多節(jié)點(diǎn)的擴(kuò)展，能夠保證多并發(fā)下的響應(yīng)速度。

因此，通過(guò)該系統(tǒng)在不損失響應(yīng)速率的基礎(chǔ)上，解決了不同系統(tǒng)API的集成，也實(shí)現(xiàn)了調(diào)用API接口的格式統(tǒng)一。