供應(yīng)商控制、多租戶問題、供應(yīng)商鎖定以及安全缺陷等，都有可能是由第三方API所導(dǎo)致的問題。在實(shí)施API時(shí)放棄系統(tǒng)控制可能會(huì)導(dǎo)致系統(tǒng)宕機(jī)、強(qiáng)迫性API升級(jí)、功能缺失、意外限制以及成本變更等后果。此外，多租戶問題也存在于其他云計(jì)算框架之中。

 

Salesforce(PaaS)就因其多租戶云結(jié)構(gòu)而施加了部分監(jiān)管限制，開發(fā)人員在使用Salesforce時(shí)必須要盡可能避免相關(guān)問題。具體而言，多租戶解決方案往往會(huì)在安全性、穩(wěn)定性以及性能層面存在問題。

 

2. 操作工具缺失

 

開發(fā)人員依賴供應(yīng)商為其提供調(diào)試與監(jiān)控工具。一般來說，調(diào)試分布式系統(tǒng)的任務(wù)非常困難，通常需要訪問大量的相關(guān)指標(biāo)才能確定產(chǎn)生問題的根本原因。

 

3. 架構(gòu)的復(fù)雜性

 

開發(fā)人員通常需要花費(fèi)大量時(shí)間來評(píng)估、實(shí)施和測(cè)試具體功能，才能最終決定這些功能應(yīng)該如何進(jìn)行細(xì)分。一次應(yīng)用程序調(diào)用操作中所涉及的功能數(shù)量應(yīng)該保持平衡。管理太多功能無疑將使問題變得更加復(fù)雜化，而忽略粒度將最終導(dǎo)致微服務(wù)架構(gòu)變?yōu)?ldquo;迷你整體”架構(gòu)。

 

目前，Lambda已經(jīng)對(duì)用戶能夠在所有l(wèi)ambda表達(dá)式上運(yùn)行的并發(fā)執(zhí)行總數(shù)作出了限制。其中的問題在于，這個(gè)限制是適用于整體AWS帳戶的。一些組織會(huì)使用相同的AWS帳戶進(jìn)行生產(chǎn)及測(cè)試。這就意味著，如果組織中的某位工作人員著手進(jìn)行一項(xiàng)新的負(fù)載測(cè)試，并嘗試執(zhí)行1000個(gè)并發(fā)Lambda函數(shù)，那么生產(chǎn)應(yīng)用程序?qū)⒘⒓丛庥鼍芙^服務(wù)(DoS)狀況。

 

4. 實(shí)施的困難性

 

集成測(cè)試無服務(wù)器應(yīng)用程序的難度非常高。與其他體系機(jī)構(gòu)相比，無服務(wù)器FaaS(即每項(xiàng)功能)的集成單元要小得多，因此我們需要將大量單元加以集成，方能正常完成測(cè)試。此外，也存在一些與部署、版本控制和打包相關(guān)的問題。大家可能需要為整體邏輯應(yīng)用程序中的每項(xiàng)功能單獨(dú)部署一項(xiàng)對(duì)應(yīng)的FaaS組件。這也就意味著，您不能以原子性方式對(duì)一組功能進(jìn)行統(tǒng)一部署，而由于不存在版本化應(yīng)用程序的概念，所以原子回滾(atomic rollback)也無法實(shí)現(xiàn)。這樣的話，您可能需要關(guān)閉任何觸發(fā)相應(yīng)功能的事件源、部署整體功能組，然后再重新啟動(dòng)事件源。

 

無服務(wù)器架構(gòu)是架構(gòu)領(lǐng)域出現(xiàn)的一種激動(dòng)人心的新變化，隨著開發(fā)人員積極采用 AWS Lambda 等計(jì)算服務(wù)，這種架構(gòu)會(huì)更為迅速地發(fā)展起來。如今，一些無服務(wù)器應(yīng)用程序支持成千上萬個(gè)用戶，并執(zhí)行復(fù)雜的操作，包括處理繁重任務(wù)，比如視頻編輯和數(shù)據(jù)處理。在許多情況下，無服務(wù)器架構(gòu)可獲得比傳統(tǒng)模式更好的效果，而且實(shí)施起來成本更低、速度更快。但是對(duì)于上文所述的有關(guān)這種架構(gòu)的弊端也必須予以高度重視，并努力尋找解決方案應(yīng)對(duì)上述弊端，以推動(dòng)無服務(wù)器架構(gòu)更加安全、穩(wěn)定的發(fā)展。