如何分析無服務(wù)器架構(gòu)及其4大主要弊端

本篇文章給大家分享的是有關(guān)如何分析無服務(wù)器架構(gòu)及其4大主要弊端，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

 背景介紹

2009年，業(yè)界提出DevOps理念。維基百科上給出的定義為“DevOps是軟件開發(fā)、運(yùn)維和質(zhì)量保證三個(gè)部門之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個(gè)集合?！?/p>

2011年，F(xiàn)orrester發(fā)布報(bào)告“擴(kuò)大DevOps至NoOps”，預(yù)測(cè)在不久的將來，一些企業(yè)將越來越多的依賴于云，開發(fā)者將能更加自動(dòng)地進(jìn)行程序構(gòu)建（building）、測(cè)試與部署等運(yùn)維操作，最終達(dá)到NoOps。

雖然該術(shù)語表示這些公司將不再需要運(yùn)維人員，但是報(bào)告本意談?wù)摰膮s是開發(fā)者將使用更加自動(dòng)化的工具，而這些工具需要更少的人工干預(yù)。隨后PaaS被視為是實(shí)現(xiàn)NoOps的***方式。

2014年，云廠商AWS推出了“無服務(wù)器”的范式服務(wù)。

最初，“無服務(wù)器”意在幫助開發(fā)者擺脫運(yùn)行后端應(yīng)用程序所需服務(wù)器設(shè)備的設(shè)置和管理工作。這項(xiàng)技術(shù)的目標(biāo)并不是為了實(shí)現(xiàn)真正意義上的“無服務(wù)器”，而是指由第三方供應(yīng)商負(fù)責(zé)后端基礎(chǔ)結(jié)構(gòu)的維護(hù)，以服務(wù)的方式為開發(fā)者提供所需功能，例如數(shù)據(jù)庫、消息以及身份驗(yàn)證等。這種服務(wù)基礎(chǔ)結(jié)構(gòu)通?？梢越凶龊蠖思捶?wù)（Backend-as-a-Service，BaaS），或移動(dòng)后端即服務(wù)（MobileBackend-as-a-service，MBaaS）。

但Amazon在2014年發(fā)布的AWS Lambda讓“無服務(wù)器”這一范式提高到一個(gè)全新的層面，為云中運(yùn)行的應(yīng)用程序提供了一種全新的系統(tǒng)體系結(jié)構(gòu)。至此再也不需要在服務(wù)器上持續(xù)運(yùn)行進(jìn)程以等待HTTP請(qǐng)求或API調(diào)用，而是可以通過某種事件機(jī)制觸發(fā)代碼的執(zhí)行，通常這只需要在AWS的某臺(tái)服務(wù)器上運(yùn)行一個(gè)簡單的功能。一些人將這種模式叫做功能即服務(wù)（Function-as-a-Service，F(xiàn)aaS）。

無服務(wù)器架構(gòu)（又稱FaaS）是指企業(yè)或個(gè)人無需購買、租賃或配置用于支持后端代碼運(yùn)行的物理或者虛擬服務(wù)器。無服務(wù)器解決方案通常由Web服務(wù)器、FaaS層、安全令牌服務(wù)（STS）、用戶驗(yàn)證以及數(shù)據(jù)庫等要素組成。

無服務(wù)器代碼可以與傳統(tǒng)服務(wù)器風(fēng)格的代碼（例如微服務(wù)）結(jié)合使用。例如，我們可以將一款Web應(yīng)用中的部分代碼編寫成微服務(wù)形式，而另一部分則可以編寫成無服務(wù)器代碼形式?；蛘?，在編寫中完全不需要任何服務(wù)器配置要素的應(yīng)用程序也可以實(shí)現(xiàn)無服務(wù)器化。

FaaS提供了一個(gè)平臺(tái)，允許開發(fā)人員能夠響應(yīng)事件執(zhí)行代碼，而無需構(gòu)建和維護(hù)復(fù)雜的基礎(chǔ)架構(gòu)，只需要經(jīng)由第三方應(yīng)用程序或服務(wù)來管理服務(wù)器端的邏輯和狀態(tài)。

無服務(wù)器計(jì)算的4大弊端

1. 第三方API系統(tǒng)導(dǎo)致的問題

供應(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)椤懊阅阏w”架構(gòu)。

目前，Lambda（亞馬遜網(wǎng)絡(luò)服務(wù)AWS提供的一種計(jì)算服務(wù)，其能夠以一種大規(guī)模并行方式執(zhí)行代碼，以響應(yīng)事件）已經(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)及其4大主要弊端，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。