安全可擴展的SaaS服務(wù)開放平臺框架設(shè)計

，

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

0 引言

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

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

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

1 開放平臺技術(shù)研究

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

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

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

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

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

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

2 框架設(shè)計

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

2.1 整體框架結(jié)構(gòu)

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

圖1 開放平臺框架結(jié)構(gòu)

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

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

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

2.2 關(guān)鍵模塊及流程

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

2.2.1 改進的Oauth2.0授權(quán)設(shè)計

如圖1所示，系統(tǒng)的安全管理模塊中設(shè)計獨立授權(quán)服務(wù)模塊，通過對Oauth2.0的研究，在標(biāo)準Oauth2.0的基礎(chǔ)上對其進行了改進，來對客戶端進行授權(quán)，當(dāng)客戶端通過服務(wù)器的身份驗證之后，為客戶端頒發(fā)訪問資源的令牌?？蛻舳藥е咽跈?quán)的訪問令牌，對API進行請求訪問，開放平臺首先會對請求進行安全性的校驗，包括驗證調(diào)用者的身份，訪問資源的權(quán)限。對于不符合條件的請求，直接返回，不進行路由，避免攻擊者惡意調(diào)用API。同時對于安全級別要求較高的資源，校驗調(diào)用者是否有足夠的權(quán)限對其進行訪問。框架中包含了兩種類型的授權(quán):

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

圖2 改進后的客戶端授權(quán)流程

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

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

圖3 改進的授權(quán)碼模式授權(quán)流程

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

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

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

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

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

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

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

圖5 服務(wù)熔斷處理機制

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

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

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

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

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

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

2.2.3 基于注冊表的可擴展性設(shè)計

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

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

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

3.1 安全性分析

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

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

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

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

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

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

3.3 平臺擴展性分析

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

4 總結(jié)

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