為什么許多工程師不了解無(wú)服務(wù)器

2022-10-06    分類: 網(wǎng)站建設(shè)

最近,我在YouTube上看了一個(gè)非常出色的開發(fā)人員的視頻。 它的標(biāo)題是“無(wú)服務(wù)器毫無(wú)意義”。 雖然我非常喜歡該視頻,但也不敢確定作者關(guān)于無(wú)服務(wù)器的觀點(diǎn)是否完全正確,因此我想在本文中進(jìn)行討論。

為什么許多工程師不了解無(wú)服務(wù)器

在引言中,作者開了個(gè)玩笑:“這個(gè)世界上有兩件事我不明白——女生和無(wú)服務(wù)器。”

我不知道他與女生的關(guān)系,但是對(duì)于無(wú)服務(wù)器的觀點(diǎn),他是對(duì)的嗎? 讓我們看看他的批評(píng),并討論潛在的對(duì)立論點(diǎn)。 劇透:我認(rèn)為無(wú)服務(wù)器確實(shí)有意義,前提是你知道何時(shí)以及如何使用它。

無(wú)服務(wù)器的批判

YouTube視頻上提到的最主要爭(zhēng)論是速度問題。 更具體地說(shuō),從作者的角度來(lái)看,無(wú)服務(wù)器應(yīng)用程序的主要缺點(diǎn)是(眾所周知的)冷啟動(dòng)問題——增加的延遲,你的代碼只有在底層云服務(wù)完成分配計(jì)算資源,拉取代碼或容器鏡像,安裝額外的程序包并配置環(huán)境之后才能開始執(zhí)行。

優(yōu)先考慮執(zhí)行速度的工程師給人的印象是,整個(gè)應(yīng)用程序生命周期管理的最終成功指標(biāo)是我們的代碼完成所需執(zhí)行任務(wù)的速度。

作為一個(gè)在IT行業(yè)工作多年的人,我看到的實(shí)際問題卻是更多關(guān)注維護(hù)性以及利用技術(shù)來(lái)快速可靠的提供商業(yè)價(jià)值的能力,我不確定這種指標(biāo)是否正確地衡量了最重要的因素——評(píng)估時(shí)間, 開發(fā)周期的速度,易于維護(hù),為最終用戶降低成本,通過促進(jìn)無(wú)縫的IT運(yùn)營(yíng)來(lái)降低運(yùn)營(yíng)中的風(fēng)險(xiǎn),最后,分配我們的大部分工程時(shí)間來(lái)正確解決實(shí)際業(yè)務(wù)問題而不是在配置和管理服務(wù)器上。

一些工程師錯(cuò)過了什么?無(wú)服務(wù)器的真正好處

如果你對(duì)執(zhí)行速度這點(diǎn)特別關(guān)心并且偶爾的200毫秒(在AWS上能達(dá)到一秒)的延遲在你的工作負(fù)載中是不可接受的,那么無(wú)服務(wù)器確實(shí)不是你的選擇,這點(diǎn)完全可以接受。 但是,我們不能因?yàn)闊o(wú)服務(wù)器的延遲就說(shuō)它毫無(wú)用處。 每個(gè)人都需要自己決定用例中可接受的延遲時(shí)間。

無(wú)服務(wù)器是管理IT基礎(chǔ)架構(gòu)的一種極具成本效益和高效的方式,對(duì)于可能沒有很多錢用于閑置資源的IT部門以及一支專門7×24小時(shí)的支持工程師的維護(hù)團(tuán)隊(duì)特別有利。

無(wú)服務(wù)器的低成本可能勝過任何弊端

在我看到的大多數(shù)用例中,僅在考慮實(shí)際計(jì)算成本的情況下,無(wú)服務(wù)器就比自托管資源便宜幾個(gè)數(shù)量級(jí)。 如果再考慮無(wú)服務(wù)器顯著減少了操作,擴(kuò)展和維護(hù)基礎(chǔ)架構(gòu)所需的時(shí)間(總擁有成本,簡(jiǎn)稱TCO),那么這時(shí)你才真正認(rèn)識(shí)到成本的節(jié)省。事實(shí)上維護(hù)基礎(chǔ)架構(gòu)的全職工程師團(tuán)隊(duì)比任何無(wú)服務(wù)器資源的成本都要高得多。

我并不是說(shuō)對(duì)于所有用例無(wú)服務(wù)器選項(xiàng)總是更便宜。 如果你持續(xù)收到數(shù)億個(gè)請(qǐng)求,如果你的工作負(fù)載非常穩(wěn)定,并且如果你有足夠的工程師可以監(jiān)控和擴(kuò)展所有這些資源,那么使用自托管的基礎(chǔ)架構(gòu)確實(shí)可能會(huì)更好。

冷啟動(dòng)是配置和預(yù)算的問題

回到成本問題上來(lái),冷啟動(dòng)問題在很大程度上取決于你愿意花費(fèi)多少以及如何配置無(wú)服務(wù)器資源。

如果你愿意支付額外的費(fèi)用,那么有許多緩解冷啟動(dòng)的方法,例如利用預(yù)熱的實(shí)例(提供并發(fā)性)或故意發(fā)出更多的請(qǐng)求(虛假請(qǐng)求)以確保你的環(huán)境保持在線。 通過使用諸如Dashbird的監(jiān)控平臺(tái),你甚至可以收到發(fā)生在函數(shù)中的任何冷啟動(dòng)的通知,從而幫助你優(yōu)化無(wú)服務(wù)器資源。 在下圖中,你可以看到在29個(gè)調(diào)用中,我們可以觀察到一個(gè)冷啟動(dòng),這使總執(zhí)行時(shí)間增加了大約180毫秒的延遲。

為什么許多工程師不了解無(wú)服務(wù)器

Dashbird的可觀察性功能有助于識(shí)別和防止冷啟動(dòng)(作者提供的圖片)

你可以為任何冷啟動(dòng)配置Slack或電子郵件警報(bào),以了解它們發(fā)生的頻率。

為什么許多工程師不了解無(wú)服務(wù)器

在Dashbird中設(shè)置冷啟動(dòng)警報(bào)(作者提供)

改善Lambda函數(shù)延遲的技術(shù)

你可以通過適當(dāng)利用上下文重用功能來(lái)減少無(wú)服務(wù)器函數(shù)的延遲。 AWS凍結(jié)并存儲(chǔ)Lambda的執(zhí)行上下文,即在函數(shù)處理程序(handler)之外發(fā)生的所有事情。如果在相同的15分鐘內(nèi)執(zhí)行了另一個(gè)函數(shù),則可以重用凍結(jié)的環(huán)境。這意味著,如果你做了耗時(shí)的操作(例如連接到Lambda處理程序外的關(guān)系數(shù)據(jù)庫(kù)),那么能夠獲得明顯更好的性能。 這篇文章非常詳細(xì)地解釋了該主題。

有許多精彩的文章討論如何緩解甚至完全消除冷啟動(dòng)問題,例如這篇還有這篇。 Dashbird已開源名為xlambda的Python庫(kù),該庫(kù)可以讓基于Python的Lambda函數(shù)保持在線狀態(tài)(warm)。 同樣,杰里米·戴爾(Jeremy Dale)為JavaScript開源了一個(gè)類似的Lambda加熱器程序包。 最后,這個(gè)無(wú)服務(wù)器框架也包括了提供相同功能的插件。

你的工作負(fù)載可接受多少延遲?

最終還是要問問自己,用例可接受的延遲時(shí)間是多少。 當(dāng)談到冷啟動(dòng)引起的延遲時(shí),我們通常爭(zhēng)論的是毫秒。 在我作為數(shù)據(jù)工程師的工作中遇到的所有用例(也構(gòu)建后端API)中,日常業(yè)務(wù)中的延遲都不明顯。

最后,諸如AWS的無(wú)服務(wù)器Kubernetes服務(wù)(在Fargate上也稱為EKS)之類的平臺(tái)使你可以在單個(gè)Kubernetes集群中混合無(wú)服務(wù)器和非無(wú)服務(wù)器數(shù)據(jù)層。這種混合使你能夠在非無(wú)服務(wù)器EC2數(shù)據(jù)層上運(yùn)行關(guān)鍵任務(wù)的低延遲工作負(fù)載,而其他工作負(fù)載(例如批處理)可以由無(wú)服務(wù)器數(shù)據(jù)層處理,從而獲得這兩個(gè)不同數(shù)據(jù)層的好性能。 你可以在這篇文章中找到有關(guān)此內(nèi)容的更多信息。

無(wú)服務(wù)器是關(guān)于“無(wú)運(yùn)維”和可擴(kuò)展性

無(wú)服務(wù)器可以讓你更專注業(yè)務(wù),因?yàn)樵铺峁┥虝?huì)幫你處理IT運(yùn)維,例如配置和擴(kuò)展計(jì)算集群,安裝安全補(bǔ)丁和升級(jí),以及解決硬件崩潰和內(nèi)存問題。這會(huì)讓你有更多的時(shí)間用來(lái)為終端客戶提供服務(wù)。為客戶提供更好的服務(wù)不就是我們的最終目的嗎?

無(wú)服務(wù)器背后的自動(dòng)化節(jié)省了高技能工程師的時(shí)間,因此他們可以專注于解決業(yè)務(wù)問題,而不是管理集群。它允許將IT運(yùn)維的工作分擔(dān)給AWS的DevOps專家,他們可能比該星球上的其他任何公司都擁有更多的管理計(jì)算相關(guān)的知識(shí)。

從無(wú)服務(wù)器中受益匪淺的案例

想象一下,你剛剛成立了一家初創(chuàng)公司。 最初,你可能不需要大量的資源,并且可能只有一個(gè)開發(fā)人員。無(wú)服務(wù)器模式允許你從小規(guī)模開始,并且可以使用按需付費(fèi)模式,自動(dòng)擴(kuò)展資源。

同樣,可以從無(wú)服務(wù)器中受益的另一個(gè)群體是可能沒有大型IT部門的小型企業(yè)。 只需一名專業(yè)的DevOps工程師(而不是整個(gè)DevOps團(tuán)隊(duì))就可以管理整個(gè)應(yīng)用程序生命周期,這是無(wú)服務(wù)器的巨大優(yōu)勢(shì)。

如果你的工作量天然具有季節(jié)性,那么無(wú)服務(wù)器也是一個(gè)很好的選擇。例如,如果你經(jīng)營(yíng)一家電子商務(wù)公司,則可能會(huì)在黑色星期五和圣誕節(jié)期間遇到季節(jié)性高峰。無(wú)服務(wù)器基礎(chǔ)架構(gòu)可以讓你在這種情況下適應(yīng)相應(yīng)的工作量。

另外,某些事件是無(wú)法預(yù)測(cè)的。想象一下,你一直在網(wǎng)上商店出售洗手液,消毒劑,口罩以及類似物品。然后發(fā)生了全球性流行病,現(xiàn)在每個(gè)人都需要你的產(chǎn)品。無(wú)服務(wù)器基礎(chǔ)架構(gòu)可以在任何情況下為你提供任何規(guī)模的擴(kuò)展。

代碼速度vs開發(fā)周期速度

除了代碼執(zhí)行速度外,我們還應(yīng)該考慮開發(fā)速度。 在許多情況下,無(wú)服務(wù)器微服務(wù)模式可以加快開發(fā)周期,因?yàn)閺脑O(shè)計(jì)上講,它鼓勵(lì)使用更小的單個(gè)組件,并讓你能夠彼此獨(dú)立地部署每個(gè)服務(wù)。

如果無(wú)服務(wù)器能夠讓你快速的向利益相關(guān)者(stakeholders)交付應(yīng)用程序的第一個(gè)版本,并在開發(fā)周期中加快迭代速度(同時(shí)降低成本),那么由于偶爾的冷啟動(dòng)而導(dǎo)致的幾毫秒的延遲增加似乎是一個(gè)很小的問題。

與其他云服務(wù)的無(wú)縫集成

以AWS為例,每個(gè)無(wú)服務(wù)器服務(wù)都與CloudWatch集成在一起以進(jìn)行日志記錄,與IAM集成以管理訪問權(quán)限,并與CloudTrail集成以收集度量指標(biāo)和跟蹤,等等。除此之外,無(wú)服務(wù)器平臺(tái)通常為你提供基本的構(gòu)建塊,以構(gòu)建更大的,解耦的微服務(wù)體系結(jié)構(gòu),例如與無(wú)服務(wù)器消息隊(duì)列(SQS),無(wú)服務(wù)器發(fā)布-訂閱消息總線(SNS),無(wú)服務(wù)器NoSQL數(shù)據(jù)存儲(chǔ)(DynamoDB)以及對(duì)象存儲(chǔ)(S3)集成。

YouTube視頻中未考慮到的無(wú)服務(wù)器弊端

視頻中還存在一些未提及的缺點(diǎn),我想列出來(lái),以便給你提供完整的認(rèn)識(shí),而無(wú)需添加任何糖衣。

即使在許多用例中,無(wú)服務(wù)器在成本,可伸縮性和維護(hù)方面似乎都像是一個(gè)天堂,但這并不是每個(gè)用例的銀彈。

面臨供應(yīng)商鎖定的風(fēng)險(xiǎn):云提供商使他們的服務(wù)使用起來(lái)非常方便并且具有成本效益,以至于你天然的面臨被鎖定在其特定平臺(tái)中的風(fēng)險(xiǎn)。

從某種程度上看,無(wú)服務(wù)器資源相比較自托管資源,你能夠?qū)τ?jì)算資源的控制會(huì)比較弱一些。 例如,你不能通過SSH到底層的計(jì)算實(shí)例上手動(dòng)執(zhí)行某些配置,并且在實(shí)例類型方面你的自由度也較小。例如,你無(wú)法在具有GPU的計(jì)算實(shí)例上運(yùn)行無(wú)服務(wù)器函數(shù)或容器(目前)。

如果你有一些特定的合規(guī)性要求,讓你無(wú)法在云上的共享租戶上處理數(shù)據(jù),那么無(wú)服務(wù)器可能不是你的選擇。

盡管將你的IT基礎(chǔ)架構(gòu)拆分為獨(dú)立的微服務(wù)有助于管理依賴并能夠加快發(fā)布周期,但這也帶來(lái)了對(duì)于獨(dú)立服務(wù)管理方面的挑戰(zhàn)。盡管監(jiān)控解決方案(例如Dashbird)在很大程度上解決了此特定問題,但你也需要意識(shí)到這些。

無(wú)服務(wù)器批判的總結(jié)

總體而言,當(dāng)我們想要像建立自托管的本地技術(shù)一樣使用無(wú)服務(wù)器或云服務(wù)之類的新模式時(shí),常常會(huì)遇到問題。這根本不是使用它的好方法。 在將工作負(fù)載移至云上時(shí),如果直接遷移,那么你將失去云服務(wù)的許多好處,甚至?xí)`解其目的。沒有一個(gè)萬(wàn)能的解決方案,因?yàn)槲覀儾荒芷谕魏渭夹g(shù)都能在所有用例中使用,成為世界上最快的技術(shù),并且在沒有任何不利方面(例如偶爾的冷啟動(dòng))的情況下幾乎還沒有額外的成本。

從我的角度來(lái)看,在談?wù)摕o(wú)服務(wù)器(坦率地說(shuō),是與IT相關(guān)的任何內(nèi)容)時(shí),我們不應(yīng)只考慮一個(gè)方面而不檢查其他關(guān)鍵方面,尤其是那些在各自技術(shù)的設(shè)計(jì)中至關(guān)重要的方面。從這個(gè)意義上說(shuō),無(wú)服務(wù)器確實(shí)有其存在的道理,前提是你知道何時(shí)以及如何使用它。

網(wǎng)站標(biāo)題:為什么許多工程師不了解無(wú)服務(wù)器
本文地址:http://muchs.cn/news/202639.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站收錄、搜索引擎優(yōu)化、網(wǎng)站營(yíng)銷、虛擬主機(jī)、云服務(wù)器、軟件開發(fā)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

h5響應(yīng)式網(wǎng)站建設(shè)