為什么許多工程師不了解無服務器

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

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

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

無服務器的批判

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

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

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

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

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

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

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

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

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

冷啟動是配置和預算的問題

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

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

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

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

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

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

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

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

你的工作負載可接受多少延遲?

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

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

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

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

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

從無服務器中受益匪淺的案例

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

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

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

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

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

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

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

與其他云服務的無縫集成

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

YouTube視頻中未考慮到的無服務器弊端

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

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

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

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

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

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

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

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

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

分享標題：為什么許多工程師不了解無服務器
當前鏈接：http://www.muchs.cn/news39/202639.html

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

廣告

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