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

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

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

無服務器的批判

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

改善Lambda函數延遲的技術

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

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

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

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

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

無服務器是關于“無運維”和可擴展性

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

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

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

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

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

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

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

代碼速度vs開發周期速度

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

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

與其他云服務的無縫集成

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

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

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

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

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

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

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

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

無服務器批判的總結

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

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

本文標題：為什么許多工程師不了解無服務器
網頁路徑：http://www.js-pz168.com/news39/202639.html

成都網站建設公司_創新互聯，為您提供網站維護、網站排名、微信小程序、響應式網站、App設計、靜態網站

廣告

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