無服務(wù)器計算的4大弊端
- 作者:新網(wǎng)
- 來源:新網(wǎng)
- 瀏覽:100
- 2018-05-08 11:05:41
供應(yīng)商控制、多租戶問題、供應(yīng)商鎖定以及安全缺陷等,都有可能是由第三方API所導(dǎo)致的問題。在實施API時放棄系統(tǒng)控制可能會導(dǎo)致系統(tǒng)宕機、強迫性API升級、功能缺失、意外限制以及成本變更等后果。此外,多租戶問題也存在于其他云計算框架之中。
1. 第三方API系統(tǒng)導(dǎo)致的問題
<
div>
供應(yīng)商控制、多租戶問題、供應(yīng)商鎖定以及安全缺陷等,都有可能是由第三方API所導(dǎo)致的問題。在實施API時放棄系統(tǒng)控制可能會導(dǎo)致系統(tǒng)宕機、強迫性API升級、功能缺失、意外限制以及成本變更等后果。此外,多租戶問題也存在于其他
云計算框架之中。
Salesforce(PaaS)就因其多租戶云結(jié)構(gòu)而施加了部分監(jiān)管限制,開發(fā)人員在使用Salesforce時必須要盡可能避免相關(guān)問題。具體而言,多租戶
解決方案往往會在安全性、穩(wěn)定性以及性能層面存在問題。
2. 操作工具缺失
開發(fā)人員依賴供應(yīng)商為其提供調(diào)試與監(jiān)控工具。一般來說,調(diào)試分布式系統(tǒng)的任務(wù)非常困難,通常需要訪問大量的相關(guān)指標才能確定產(chǎn)生問題的根本原因。
3. 架構(gòu)的復(fù)雜性
開發(fā)人員通常需要花費大量時間來評估、實施和測試具體功能,才能最終決定這些功能應(yīng)該如何進行細分。一次應(yīng)用程序調(diào)用操作中所涉及的功能數(shù)量應(yīng)該保持平衡。管理太多功能無疑將使問題變得更加復(fù)雜化,而忽略粒度將最終導(dǎo)致微服務(wù)架構(gòu)變?yōu)?ldquo;迷你整體”架構(gòu)。
目前,Lambda已經(jīng)對用戶能夠在所有l(wèi)ambda表達式上運行的并發(fā)執(zhí)行總數(shù)作出了限制。其中的問題在于,這個限制是適用于整體AWS帳戶的。一些組織會使用相同的AWS帳戶進行生產(chǎn)及測試。這就意味著,如果組織中的某位工作人員著手進行一項新的負載測試,并嘗試執(zhí)行1000個并發(fā)Lambda函數(shù),那么生產(chǎn)應(yīng)用程序?qū)⒘⒓丛庥鼍芙^服務(wù)(DoS)狀況。
4. 實施的困難性
集成測試無
服務(wù)器應(yīng)用程序的難度非常高。與其他體系機構(gòu)相比,無服務(wù)器FaaS(即每項功能)的集成單元要小得多,因此我們需要將大量單元加以集成,方能正常完成測試。此外,也存在一些與部署、版本控制和打包相關(guān)的問題。大家可能需要為整體邏輯應(yīng)用程序中的每項功能單獨部署一項對應(yīng)的FaaS組件。這也就意味著,您不能以原子性方式對一組功能進行統(tǒng)一部署,而由于不存在版本化應(yīng)用程序的概念,所以原子回滾(atomic rollback)也無法實現(xiàn)。這樣的話,您可能需要關(guān)閉任何觸發(fā)相應(yīng)功能的事件源、部署整體功能組,然后再重新啟動事件源。
無服務(wù)器架構(gòu)是架構(gòu)領(lǐng)域出現(xiàn)的一種激動人心的新變化,隨著開發(fā)人員積極采用 AWS Lambda 等計算服務(wù),這種架構(gòu)會更為迅速地發(fā)展起來。如今,一些無服務(wù)器應(yīng)用程序支持成千上萬個用戶,并執(zhí)行復(fù)雜的操作,包括處理繁重任務(wù),比如視頻編輯和數(shù)據(jù)處理。在許多情況下,無服務(wù)器架構(gòu)可獲得比傳統(tǒng)模式更好的效果,而且實施起來成本更低、速度更快。但是對于上文所述的有關(guān)這種架構(gòu)的弊端也必須予以高度重視,并努力尋找解決方案應(yīng)對上述弊端,以推動無服務(wù)器架構(gòu)更加安全、穩(wěn)定的發(fā)展。