，

(西南科技大學 計算機科學與技術學院,四川 綿陽 621010)

0 引言

開放是目前互聯(lián)網的發(fā)展趨勢，自2007年5月FaceBook正式開放其應用程序編程接口以來，各大平臺也相繼逐漸的開放了各自的API(Application Programming Interface)，建立了自己的開放平臺。通過開放平臺，不僅釋放了平臺的創(chuàng)造力，還能吸引第三方應用的用戶，同時又豐富了用戶體驗，實現(xiàn)了三方共贏。SaaS(Software as a Service，軟件即服務)服務作為一種新興的軟件模式在不斷的發(fā)展和壯大，服務供應商提供給客戶的服務種類也變得越來越豐富，其多租戶(Multi-tenancy)[1-2]的特性，對于SaaS服務開放平臺的安全性、并發(fā)性以及穩(wěn)定性等方面也提出了越來越高的要求。

國內外著名的互聯(lián)網企業(yè)都開放了其自己的開放平臺，Google的OpenSocail就是其開放的第一步，F(xiàn)aceBook提出的F8開放標準，阿里巴巴集團的“大淘寶戰(zhàn)略”也推出TOP開放平臺，百度的“百度搜索開放平臺”也開放了其搜索引擎，從技術架構上看，這些企業(yè)的開放平臺都有其各自的技術特點和不同的框架。學術上也對開放平臺的解決方案進行了許多的研究，朱蔚恒和周偉等人提出了一種開放平臺架構模型，但是并未對穩(wěn)定性和并發(fā)性作出深入的研究[3]。周巧也對開放平臺系統(tǒng)進行了設計[4]，但是側重于安全方面，對于性能及穩(wěn)定性則沒有深入討論。雖然，現(xiàn)有開放平臺有一些成熟的框架，但是在身份認證授權、靈活可擴展性及并發(fā)性能的處理方面，仍有待完善的地方，同時對于一些特定應用類型的開放平臺框架，并不適用于SaaS服務開放平臺。

由于不同業(yè)務類型對應的開放平臺有其自身的架構特點，對于SaaS服務來說，常見的開放平臺框架并不適用，需要提供一個適用于SaaS服務的開放平臺框架。因此，基于SaaS服務對開放平臺的需求，結合SaaS服務的特點，提出了一個安全可擴展的SaaS服務開放平臺框架，并對其在安全性、穩(wěn)定性等方面進行了分析。

1 開放平臺技術研究

開放平臺就是通過把網站的服務封裝成一系列計算機易識別的數(shù)據(jù)接口開放出去，提供給第三方開發(fā)者使用，這種行為就叫做OPEN API，提供OPEN API的平臺本身就被稱為開放平臺。SNS領域最具代表性的開放平臺就是FaceBook的F8標準[5]，而國內電商平臺中最具代表性的開放平臺則是阿里巴巴的TOP(Taobao Open Platform)[6]，國內搜索服務最具代表性的開放平臺則是百度搜索開放平臺[7]。通過研究發(fā)現(xiàn)，它們雖然在技術架構上差異很大，但是涉及到的核心技術，則都包含了如下兩個方面：

1)Oauth2.0[8]協(xié)議授權，主要是為應用提供一種標準的方式去訪問受保護的資源。對于開放平臺來說，這里的授權訪問包括兩個方面，一是客戶端直接與服務端進行交互，沒有用戶參與的授權；另一種則是需要用戶授權，客戶端才能訪問用戶受保護的資源。Oauth協(xié)議為不同情況下的授權都提供的解決方案。

2)OPEN API架構風格，主要包含了RPC(Remote Procedure Call)和RESTful(Representational State Transfer)[9]。RPC即遠程過程調用，它是一種通過網絡向遠程計算機程序請求服務，像調用本地服務一樣調用服務。RESTful則是一種資源定位及資源操作輕量級的WEB服務架構風格，基于這個風格設計的軟件更加簡潔，更有層次，也更利于實現(xiàn)緩存等機制，所以這也是目前最流行的API風格。

由于開放平臺是將服務接口直接對第三方的開發(fā)者提供，接口都是暴露在公網上，同時開發(fā)者的數(shù)量和API的調用頻率等都有差異，開放平臺在架構設計的時候，需要關注以下兩個方面：

1)安全性。開放平臺的開放API由于是對外提供給第三方開發(fā)者調用，所以必須是暴露在公網上，這導致的直接的問題就是開放平臺的安全性問題，谷歌的開放API就曾經因為安全問題而在發(fā)布不久后就下架[10]。Oauth2.0自出現(xiàn)后，得到廣泛關注，研究表明其框架在執(zhí)行過程中存在令牌泄露，釣魚攻擊等威脅[11-13]，采用該協(xié)議的服務端存在 63.6%存在安全漏洞，作為客戶端的網站也有 90.2%存在安全漏洞[14]。

2)穩(wěn)定性。開放平臺為不同的商家提供服務，API被大量不同的第三方進行調用，所以開放平臺的穩(wěn)定性直接決定了為第三方提供的服務質量。如果因為某一方的調用而影響其他用戶的調用，對用戶而言是不合理的。隨著用戶數(shù)量的增長，開放平臺還必須支撐高并發(fā)情況下的API調用，保證在高并發(fā)情況下服務的穩(wěn)定，對于并發(fā)超過平臺上限的時候，還必須具備一定的限流策略，從多個方面保證平臺的穩(wěn)定性。

2 框架設計

通過對開放平臺的研究，再結合SaaS服務對開放平臺的需求，在保證安全性和性能以及穩(wěn)定性的前提下，設計了一種安全可擴展的SaaS服務的開放平臺框架，并對其做了性能和穩(wěn)定方面的改進，為SaaS服務在搭建開放平臺的時候提供一個參考依據(jù)。

2.1 整體框架結構

安全可擴展的開放平臺框架由平臺核心模塊，輔助可配置的獨立模塊，及服務注冊表和服務群組成，框架整體結構如圖1所示。

圖1 開放平臺框架結構

平臺核心模塊主要由安全管理，流量管控，服務熔斷，服務路由，負載均衡以及靜態(tài)響應模塊和可插拔的自定義模塊組成，相較于傳統(tǒng)的開放平臺，提高了其擴展性，模塊之間的松耦合也使得系統(tǒng)變得靈活可變。

其中安全管理模塊負責開放平臺的安全把控，通過對Oauth2.0授權流程的改進，增強了系統(tǒng)的安全性；流量管控模塊負責在高并發(fā)情況下根據(jù)一定的策略對外部請求進行限流，保證了系統(tǒng)在高并發(fā)下達到系統(tǒng)上限時的穩(wěn)定性；服務熔斷模塊的功能類似于電路總的保險絲，對下游的服務起到保護作用；服務路由模塊負責對外部合法的請求進行轉發(fā)，根據(jù)負載均衡模塊提供的負載策略轉發(fā)到下游服務；靜態(tài)響應模塊則負責在下游服務掛掉之后進行及時的響應。輔助可配置的獨立模塊則包含webhook響應，監(jiān)控日志和授權組成，為核心模塊提供安全保障和日志審計等功能。服務注冊表用于維護下游API服務的基本信息，下游服務啟動時，通過向開放平臺發(fā)送自身的基本注冊信息存儲在注冊表中，服務路由模塊根據(jù)注冊表中服務的信息，來對外部的請求進行轉發(fā)。可擴展的后端服務群則是SaaS實際對外提供的服務Restful API集合，為租戶提供實際的服務。

通過該框架設計，對于SaaS服務來說，第三方應用不用直接與具體服務的API進行通信，而是首先通過開放平臺這個中間層，按照一系列的校驗規(guī)則和路由策略，最終才到達后端服務，進行具體的業(yè)務處理。

2.2 關鍵模塊及流程

開放平臺自身通過維護一個注冊表，來保證和后端的服務連接，當外部的HTTP/HTTPS請求進入開放平臺后，根據(jù)請求的URL去注冊表中找到對應的可用服務，然后將請求轉發(fā)到具體的服務中。在轉發(fā)以前，開放平臺還會對請求進行一系列的安全校驗以及管控，從而對內部服務達到一種保護和隔離的作用。

2.2.1 改進的Oauth2.0授權設計

如圖1所示，系統(tǒng)的安全管理模塊中設計獨立授權服務模塊，通過對Oauth2.0的研究，在標準Oauth2.0的基礎上對其進行了改進，來對客戶端進行授權，當客戶端通過服務器的身份驗證之后，為客戶端頒發(fā)訪問資源的令牌。客戶端帶著已授權的訪問令牌，對API進行請求訪問，開放平臺首先會對請求進行安全性的校驗，包括驗證調用者的身份，訪問資源的權限。對于不符合條件的請求，直接返回，不進行路由，避免攻擊者惡意調用API。同時對于安全級別要求較高的資源，校驗調用者是否有足夠的權限對其進行訪問?？蚣苤邪藘煞N類型的授權:

1)沒有用戶參與，只對客戶端訪問API的情況進行授權。在Oauth2.0的客戶端授權模式(client_credentials)的基礎上，對其做了改進，引入了HMAC[15-16]摘要計算，避免了客戶端在申請訪問令牌token的時候在信道中直接傳輸客戶端密鑰SecretKey，有效的解決了密鑰泄露的風險，增加了授權流程的安全性，改進后的授權流程如下圖2所示。

圖2 改進后的客戶端授權流程

客戶端想要訪問開放平臺的資源之前，需要到開放平臺申請應用，開放平臺對其進行身份認證，信息檢查等之后，為客戶端頒發(fā)應用ID和密鑰，也就是AppKey和SecretKey。當客戶端想要申請令牌的時候，就對AppKey和SecretKey以及其他附加參數(shù)做HMAC摘要計算，并以“算法”+“空格”+“AppKey”+“：”+“摘要值”的形式傳遞給授權服務器(Authorization Server)進行令牌申請。授權服務器通過解析出AppKey，再去尋找其對應的SecretKey，并以相同的方式計算出HMAC摘要，如果比較兩個值一致，則頒發(fā)令牌，否則不頒發(fā)。由于在傳輸過程中傳遞的是hamc值，并不是客戶端密鑰，所以即使信息被截取，對于攻擊者而言也是沒有意義的，提高了授權流程中的安全性。

2)有用戶參與的授權，當客戶端需要訪問用戶受保護的資源時,需要得到用戶自己的授權，從而授權服務器才能給客戶端頒發(fā)令牌，也就是標準Oauth2.0中的授權碼模式(authorization_code)。通過對標準授權碼模式的授權流程的安全性分析，采用了基于信任機制的改進授權流程[17]，其授權流程如圖3所示。

圖3 改進的授權碼模式授權流程

相比于Oauth2.0中的標準授權碼模式流程中，圖3中的授權流程引入了資源服務器(Resource Server)和授權服務器(Authorization Server)之間的同步信任機制，也就是在原有流程中增加了同步信任表，該信任表與安全節(jié)點相互配合可以防止客戶端與授權服務器端，用戶通信時被監(jiān)聽盜取令牌。當客戶端申請資源的時候，資源服務器為其頒發(fā)一個pre-token令牌，同時授權服務器也會同步得到這個pre-token。當客戶端得到用戶授權后，去授權服務器申請資源的時候，會先去訪問安全節(jié)點，安全節(jié)點檢查是否存在pre-token 與用戶對應,如果存在，則表明這個用戶確實有資源請求的要求，允許該客戶端訪問授權節(jié)點，進而頒發(fā)訪問令牌token。

2.2.2 高并發(fā)限流及熔斷機制的設計

系統(tǒng)中流量管控模塊設計了基于令牌桶算法[18]的限流策略，來實現(xiàn)對高并發(fā)下外部請求的流量控制。具體的設計思路就是根據(jù)令牌桶算法的特點，以一個恒定可配置的速度往桶里放入令牌，當HTTP請求到達時，如果該請求需要被處理，就從桶中取出一塊令牌，路由的時候首先判斷當前請求是否具有令牌，有則路由到下游API服務，沒有則不進行路由。如果桶里沒有令牌可取，那么后面的請求則需要排隊等待，直到桶里有令牌才能進行后續(xù)操作。其流程圖如圖4所示。

圖4 基于令牌桶算法的限流策略

如圖4所示，令牌桶中當前持有的令牌數(shù)量為x，并且以每秒n個令牌的速率往桶中放入令牌，這個速率支持自定義配置。當每個外部請求到達流量控制模塊，需要從令牌桶中取出一塊令牌，然后路由模塊才會將這些持有令牌的請求路由到下游API服務中。如果沒有令牌，則不進行路由，直接返回。

在諾內特看來，“如果統(tǒng)治政權傾向于不顧被統(tǒng)治者的利益或者否認它們的正統(tǒng)性，那么它就是壓制性的?！盵2]因為，在這種法制模式下，最受關注的是權力的權威性及其形成的統(tǒng)治、管理秩序，為了實現(xiàn)這種秩序性核心價值，“刑法是法律官員關注的中心，是表現(xiàn)法律權威的典型方法?！盵2]整體來看，中國古代歷朝法制狀況均系“言法必刑”“以刑為主”，由于其固有的強大威懾性，刑法成為治理手段的首選，其他的社會規(guī)范則退居其后，以致長期形成了社會治理刑法化的路徑依賴。

當開放平臺某個API請求過于集中而導致無法響應或是響應緩慢，如果沒有設計合理的處理機制，最終將會導致整個下游API不可用。本框架中服務熔斷模塊設計了熔斷保護機制，在外部請求和下游API之間起到了“保險絲”的作用，也提升了系統(tǒng)的穩(wěn)定性。其工作流程如圖5所示。

圖5 服務熔斷處理機制

圖中外部請求進入開放平臺對API-1，API-2，API-3進行訪問時，API-2由于多次調用均失敗(出現(xiàn)超時或者無法響應)，這時系統(tǒng)就會對API-2進行服務熔斷，及時返回預設的靜態(tài)響應結果。API-1和API-3由于沒有被熔斷，則返回正常的響應結果。為了保證服務熔斷后能夠重新連接并正常訪問，該模塊還設計了心跳檢測機制，每隔一個時間間隔對API-2進行檢測，如果能夠正常響應，那么就關閉熔斷，以保證API-2能夠重新進行訪問。

在負載均衡模塊中，設計多組合方式的負載策略，該策略通過可配置的一個或者多個負載均衡策略的組合，選擇相對合適的服務實例，對請求進行轉發(fā)，實現(xiàn)平臺內部的二級軟負載。設計中默認的負載均衡策略包括：

1)選擇一個并發(fā)請求最小的Server進行轉發(fā)。

2)根據(jù)響應時間為每個服務的實例分配一個權重，響應時間越長，權重越小，被選中的可能性也越小。

3)以輪詢的方式進行選擇，對于同一個服務的每個實例，分配一個索引index，然后對index進行輪詢，選擇對應索引的服務進行轉發(fā)。

配置多種負載均衡策略，為開放平臺自身提供負載能力，降低了平臺外部一級負載的壓力，同時還支持設計自定義的負載策略，擴展負載均衡策略庫，提高開放平臺的性能。

2.2.3 基于注冊表的可擴展性設計

可擴展性主要通過兩個方面的設計來實現(xiàn)，一個是核心模塊的可擴展性，另一個則是API服務的橫向可擴展性。通過這兩個方面的靈活設計，保證了開放平臺在后續(xù)迭代和升級中可以靈活的進行擴展。

根據(jù)設計模式中單一職責的原則，每一個模塊僅負責一個功能，各個模塊之間沒有相互依賴關系，它們都是獨立的存在，降低了模塊之間的耦合程度。通過各個模塊的聚合，使得它們之間又相互協(xié)作，實現(xiàn)開放平臺對于不同情境下的不同需求，保證了核心模塊的可擴展性。另一方面，設計了一個長度可變的注冊表，由于注冊表中包含了每個API服務的名稱，地址，多實例部署模式下各個實例對應的索引等信息，通過維護這個注冊表，開放平臺就能將外部請求路由到具體的服務中去。其中同步下線服務(cancel()方法)，同步注冊服務(register()方法)，同步續(xù)約服務(renew()方法)三個方法代表了三個交互行為，通過這三個方法來維護后端服務和開放平臺關聯(lián)關系。當開放平臺需要新增后端服務的時候，通過register()方法即可將服務添加到注冊表中進行維護即可；當需要從注冊表中解除關聯(lián)關系，通過cancel()方法就能從開放平臺注冊表中下線該服務；同時還采用了心跳機制通過renew()方法來檢測服務是否續(xù)約，以決定其是否滿足繼續(xù)存留在注冊表中的條件。注冊表的動態(tài)可變特性，滿足了API服務的橫向可擴展性。

3 安全可擴展開放平臺安全性及性能分析

3.1 安全性分析

開放平臺將一系列的服務數(shù)據(jù)接口對外開放，接口暴露在外部導致會存在諸多的安全性問題。因此，為保證開放平臺安全性，本框架設計了安全管理模塊，用于過濾那些惡意的無效的請求，防止惡意調用API造成平臺接口的安全問題。對于外部請求做了嚴格的權限控制，只有當?shù)谌秸{用者被授權之后，開放平臺才會對這些請求進行路由。

在安全管理模塊的基礎上，設計了獨立的授權模塊，通過改進Oauth2.0中的一些安全問題,針對客戶端授權和用戶授權兩種類型的授權流程進行了安全改進。在客戶端授權流程中，根據(jù)HMAC算法的特點，加入了HmacSHA512摘要算法，對請求token時候的敏感數(shù)據(jù)做了加密處理，以“算法”+“空格”+“AppKey”+“：”+“摘要值”最為最終進行傳遞的數(shù)據(jù)，保證了客戶端在申請token的時候不會暴露密鑰，避免了客戶端密鑰被竊取的風險；在用戶授權流程中，采用改進的Oauth2.0授權流程，引入了信任機制和安全節(jié)點，實現(xiàn)可信授權及節(jié)點的安全控制，防止了釣魚攻擊和信道監(jiān)聽而導致的安全隱患。

同時，實現(xiàn)監(jiān)控模塊，對第三方的調用記錄進行實時的審計與監(jiān)督，一旦發(fā)現(xiàn)異常的調用，可以及時采取相應的措施進行限制和禁用。因此，本框架從授權認證、接口信息加密處理及審計記錄多個維度保證了開放平臺的安全性問題。

3.2 穩(wěn)定性與性能分析

為保證高并發(fā)的開放平臺系統(tǒng)穩(wěn)定性，從外部請求和內部服務兩個方面來進行了改進。對于外部采取了限流的措施，通過限流管理模塊，設計了基于令牌桶算法的限流策略，當外部請求的速率大于放入令牌桶中令牌的速率，導致桶中無令牌可用時，就進行流量限制，避免因過載而導致平臺崩潰。為了防止個別API響應緩慢或無法提供服務時，由于大量的超時等待而導致整個開放平臺堵塞，以及后端API來不及處理和響應大量的請求的情況出現(xiàn)，設計了服務熔斷模塊和負載均衡模塊。多服務實例部署的方式能防止個別服務實例down掉的時候其他實例可以正常運行，以保證平臺內部服務可以穩(wěn)定的運行。

熔斷機制在外部請求和API之間起到了保險絲的作用，對下游API進行保護的同時，當API無法響應或者響應超時的時候，實時的為客戶端返回預設的靜態(tài)響應，避免了客戶端一直等待，對系統(tǒng)造成堵塞，影響開放平臺整體的性能。載均衡模塊設計了策略庫，提供了默認的幾種負載均衡策略，同時還支持擴充策略庫。當外部請求進入的時候，負載均衡模塊選擇合適的負載策略，將請求分發(fā)到下游API服務實例上，避免了由于壓力過大而出現(xiàn)某個服務實例崩潰的情況。

3.3 平臺擴展性分析

對于一個SaaS服務的開放平臺來說，必須要具備良好的擴展性，才能更好的支撐面向多租戶的SaaS服務。針對傳統(tǒng)SaaS開放平臺擴展性不強的缺陷，在設計開放平臺框架的時候，充分考慮了平臺的可擴展性。根據(jù)設計模式中低耦合高內聚的設計原則，設計了多模塊可組合的開放平臺功能組件，保證了開放平臺基礎功能的可擴展性。通過自定義模塊，可以根據(jù)實際需求，豐富開放平臺的基礎模塊；為保證下游API能夠方便的進行橫向擴展，設計了注冊表來維護下游API服務實例與開放平臺的關聯(lián)，使得下游API服務可以自由的進行擴展，這為SaaS擴展自身的業(yè)務提供了極大的便利。

4 總結

根據(jù)SaaS服務的特點和對開放平臺的需求，設計了一個安全可擴展的OPBG框架，為SaaS服務搭建開放平臺提供一個可參考的解決方案。兼顧了開放平臺所需要的穩(wěn)定性和高并發(fā)性，同時根據(jù)Oauth2.0標準授權流程中存在的安全隱患，對授權流程做了改進，提高了開放平臺的安全性保障，松耦合的模塊設計也提高了開放平臺的靈活性與可擴展性。為SaaS服務開放平臺提供一個基礎的解決方案，還有一些有待改進的地方，比如對于一些熱點數(shù)據(jù)進行特殊的處理，提高系統(tǒng)的效率。安全管理方面，對于訪問控制策略和其他的安全限制及保障都有待提高和研究。