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

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

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

無服務(wù)器的批判

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在Dashbird中設(shè)置冷啟動警報(作者提供)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

分享標(biāo)題：為什么許多工程師不了解無服務(wù)器
當(dāng)前鏈接：http://www.rwnh.cn/news39/202639.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、App設(shè)計、企業(yè)網(wǎng)站制作、品牌網(wǎng)站建設(shè)、網(wǎng)站設(shè)計公司、定制開發(fā)

廣告

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