本篇文章給大家分享的是有關(guān)如何分析無服務(wù)器架構(gòu)及其4大主要弊端,小編覺得挺實(shí)用的,因此分享給大家學(xué)習(xí),希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。
創(chuàng)新互聯(lián)技術(shù)團(tuán)隊(duì)10年來致力于為客戶提供網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站設(shè)計(jì)、品牌網(wǎng)站建設(shè)、全網(wǎng)營銷推廣、搜索引擎SEO優(yōu)化等服務(wù)。經(jīng)過多年發(fā)展,公司擁有經(jīng)驗(yàn)豐富的技術(shù)團(tuán)隊(duì),先后服務(wù)、推廣了近千家網(wǎng)站,包括各類中小企業(yè)、企事單位、高校等機(jī)構(gòu)單位。
背景介紹
2009年,業(yè)界提出DevOps理念。維基百科上給出的定義為“DevOps是軟件開發(fā)、運(yùn)維和質(zhì)量保證三個(gè)部門之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個(gè)集合?!?/p>
2011年,F(xiàn)orrester發(fā)布報(bào)告“擴(kuò)大DevOps至NoOps”,預(yù)測在不久的將來,一些企業(yè)將越來越多的依賴于云,開發(fā)者將能更加自動(dòng)地進(jìn)行程序構(gòu)建(building)、測試與部署等運(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請求或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ì)算框架之中。
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í)間來評估、實(shí)施和測試具體功能,才能最終決定這些功能應(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)對用戶能夠在所有l(wèi)ambda表達(dá)式上運(yùn)行的并發(fā)執(zhí)行總數(shù)作出了限制。其中的問題在于,這個(gè)限制是適用于整體AWS帳戶的。一些組織會(huì)使用相同的AWS帳戶進(jìn)行生產(chǎn)及測試。這就意味著,如果組織中的某位工作人員著手進(jìn)行一項(xiàng)新的負(fù)載測試,并嘗試執(zhí)行1000個(gè)并發(fā)Lambda函數(shù),那么生產(chǎn)應(yīng)用程序?qū)⒘⒓丛庥鼍芙^服務(wù)(DoS)狀況。
4. 實(shí)施的困難性
集成測試無服務(wù)器應(yīng)用程序的難度非常高。與其他體系機(jī)構(gòu)相比,無服務(wù)器FaaS(即每項(xiàng)功能)的集成單元要小得多,因此我們需要將大量單元加以集成,方能正常完成測試。此外,也存在一些與部署、版本控制和打包相關(guān)的問題。大家可能需要為整體邏輯應(yīng)用程序中的每項(xiàng)功能單獨(dú)部署一項(xiàng)對應(yīng)的FaaS組件。這也就意味著,您不能以原子性方式對一組功能進(jìn)行統(tǒng)一部署,而由于不存在版本化應(yīng)用程序的概念,所以原子回滾(atomic rollback)也無法實(shí)現(xiàn)。這樣的話,您可能需要關(guān)閉任何觸發(fā)相應(yīng)功能的事件源、部署整體功能組,然后再重新啟動(dòng)事件源。
以上就是如何分析無服務(wù)器架構(gòu)及其4大主要弊端,小編相信有部分知識點(diǎn)可能是我們?nèi)粘9ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
本文標(biāo)題:如何分析無服務(wù)器架構(gòu)及其4大主要弊端
瀏覽路徑:http://jinyejixie.com/article28/ggshjp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供營銷型網(wǎng)站建設(shè)、電子商務(wù)、做網(wǎng)站、網(wǎng)站設(shè)計(jì)、網(wǎng)站內(nèi)鏈、標(biāo)簽優(yōu)化
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)