中立觀點：無伺服器架構的特點 | ThoughtWorks

1. 進入門檻低
2. Hostless
3. 無狀態
4. 彈性
5. 分散式
6. 事件驅動

進入門檻低
開始在無伺服器架構中執行程式碼是相對簡單的。您可以按照任何教程開始，讓您的程式碼在生產級生態系統中執行。在許多方面，無伺服器架構的學習曲線不如典型的DevOps技能那麼令人生畏 - 當您採用無伺服器架構時，DevOps的許多元素都不是必需的。例如，您不必學習伺服器管理技能，例如配置管理或修補。這就是為什麼低障礙進入是無伺服器架構的特徵之一。
這意味著，最初，開發人員的學習曲線比許多其他架構風格要低。這並不意味著學習曲線將保持低水平，實際上，隨著開發人員繼續他們的旅程，整體學習曲線變得更加陡峭。
由於這種架構特徵，我看到許多新開發人員很快就加入了專案，他們已經能夠有效地為專案做出貢獻。開發人員快速達到速度的能力可能是無伺服器專案更快上市時間的一個原因。
正如我們所指出的那樣，事情確實變得更加複雜。例如，基礎設施作為程式碼，日誌管理，監控以及有時網路等仍然是必不可少的。而且您必須瞭解如何在無伺服器的世界中實現它們。如果您來自不同的開發背景，那麼您需要了解許多無伺服器架構特徵（本文將介紹這些特性）。

儘管最初進入門檻較低，開發者不應該認為他們可以忽略重要的架構原則。

我注意到的一件事是，一些開發人員傾向於認為無伺服器架構意味著他們不必考慮程式碼設計。理由是他們只是進行功能處理，因此程式碼設計無關緊要。實際上，設計原則（如SOLID）仍然適用 - 您無法將程式碼可維護性外包給無伺服器平臺。即使您可以將程式碼捆綁並上傳到雲端以使其執行，但我強烈反對這樣做，因為持續交付實踐仍然與無伺服器架構相關。

Hostless
無伺服器架構的一個明顯特徵是您不再直接處理伺服器。在這個時代，您可以在其中安裝和執行服務的各種主機 - 無論是物理機器，虛擬機器，容器等等 - 只需一個單詞來描述它就很有用。為了避免使用已經名不副實的術語：Serverless，我將在這裡使用hostless。
無主機hostless的一個優點是，您在伺服器維護上的運營開銷將大大減少。您無需擔心升級伺服器，並會自動為您應用安全補丁。無主機也意味著您將在應用程式中監控不同型別的指標。發生這種情況是因為您使用的大多數底層服務都不會發布傳統指標，如CPU，記憶體，磁碟大小等。這意味著您不再需要解釋架構的低階操作細節。
但是，不同的監控指標意味著您必須重新學習如何調整架構。AWS DynamoDB為您提供了監視和調優的讀寫容量，這是您必須瞭解的概念 - 並且學習不可轉移到其他無伺服器平臺。您使用的每項服務也都有其侷限性。AWS Lambda具有併發執行限制，而不是您擁有的CPU核心數。為了使它有點奇怪，更改Lambda的記憶體分配大小將改變您獲得的CPU核心數。如果您為效能測試和生產環境共享一個AWS賬戶，那麼如果效能測試意外地消耗了整個併發執行限制，則可能會降低生產。AWS很好地記錄了每種服務的限制：

當安全補丁自動應用於底層伺服器時，無伺服器應用程式更加安全，這是一種常見的誤解。這是一個危險的假設。
傳統的安全保護不適用，因為無伺服器架構具有不同的攻擊向量。您的應用程式安全實踐仍然適用，並且在程式碼中儲存機密仍然是一個很大的禁忌。AWS在其共享責任模型中概述了這一點，例如，如果資料包含敏感資訊，您仍需要保護資料。我強烈建議您閱讀OWASP Serverless Top 10，以獲得有關此主題的更多見解。雖然您的運營開銷顯著降低，但值得注意的是，在極少數情況下，您仍需要管理底層伺服器更改的影響。您的應用程式可能依賴於本機庫，並且您需要確保它們在升級基礎作業系統時仍然可用。例如，在AWS Lambda中，作業系統最近已升級到AMI 2018.03。

無狀態
作為服務或FaaS的功能是短暫的，因此您無法在記憶體中儲存任何內容，因為執行程式碼的計算容器將由您的平臺自動建立和銷燬。因此，無狀態是無伺服器架構中的特徵。
無狀態是橫向擴充套件應用程式的一個很好的特性。無狀態的想法是不鼓勵你在應用程式中儲存狀態。透過不在應用程式中儲存狀態，就能夠在不擔心應用程式狀態的情況下啟動更多例項，以便水平擴充套件。我覺得這裡有趣的是你實際上被迫無狀態，因此錯誤的空間大大減少了。是的，有一些注意事項：例如，計算容器可能會被重複使用，您是可以儲存狀態，但如果採用這種方法，請務必小心。
在應用程式開發方面，您將無法使用需要狀態的技術，因為狀態管理的負擔被強制給呼叫者。例如，不能使用HTTP會話，因為您沒有具有持久檔案儲存的傳統Web伺服器。如果要使用需要WebSockets 等狀態的技術，則必須等到相應的Backend即服務支援，或者應用自己的解決方法。

彈性
由於您的架構是無主機的，因此您的架構也具有彈性的特性。您使用的大多數無伺服器服務都是高度靈活的，您可以從零到最大允許，然後回到零，大多數是自動管理。彈性是無伺服器架構的特徵。
彈性的好處對於可擴充套件性來說是巨大的。這意味著您不必手動管理資源擴充套件。資源分配的許多挑戰消失了。在某些情況下，彈性可能只意味著您只需支付使用的費用，因此如果您的使用率較低，您將降低運營成本。
您可能需要將無伺服器架構與不支援此類彈性的舊系統整合。發生這種情況時，您可能會破壞下游系統，因為它們可能無法像無伺服器架構一樣擴充套件。如果您的下游系統是關鍵系統，那麼考慮如何緩解此問題非常重要 - 可能透過限制AWS Lambda併發或利用佇列與下游系統進行通訊。
雖然具有如此高彈性的“拒絕服務”將變得更加困難，但您將容易受到“denial of wallet”的攻擊。這是攻擊者試圖透過強制您的資源分配來強制您超過雲帳戶限制來破壞應用程式的地方。為了防止此類攻擊，您可能會發現在您的應用程式中使用DDoS保護（例如AWS Shield）會很有幫助。在AWS中，設定AWS預算也很有用，這樣當雲賬單暴漲時您就會收到通知。如果高彈性不是您期望的那樣，那麼再次對您的應用程式設定約束是有用的 - 例如透過限制您的AWS Lambda併發性。

分散式
由於無狀態計算是一種特性，因此您擁有的所有永續性要求將作為服務（BaaS）儲存在後端中，通常是它們的組合。一旦您更多地接受FaaS，您還會發現您的部署單元（功能）比您習慣的要小。因此，預設情況下會分發無伺服器架構 - 您必須透過網路整合許多元件。您的體系結構還包括將服務連線在一起，如身份驗證，資料庫，分散式佇列等。正如我們之前討論的那樣，分散式系統有很多好處，包括彈性。分散式也會為您的架構帶來單一區域，高可用性。在無伺服器環境中，當您的雲供應商所在區域中的一個可用區域出現故障時，您的架構將能夠利用仍處於執行狀態的其他可用區域 - 從開發人員的角度來看，所有這些區域都是不透明的。您選擇的架構總是需要權衡。在這個特性中，您透過可用來交易一致性。通常在雲中，每個無伺服器服務也有自己的一致性模型。例如，在AWS S3中，您將獲得S3儲存桶中新物件的PUTS的讀寫後一致性。對於物件更新，S3最終是一致的。您必須決定使用哪種BaaS，這是很常見的，因此請注意其一致性模型的行為。
另一個挑戰是讓您熟悉的是分散式訊息傳遞方法。您需要熟悉並理解一次交付的難題例如，因為分散式佇列的公共訊息傳遞方法至少是一次傳遞。由於此交付方法，AWS Lambda可以多次呼叫，因此您必須確保您的實現是冪等的（瞭解您的FaaS重試行為也很重要，AWS Lambda可能會在失敗時執行多次）。您需要了解的其他挑戰包括分散式事務的行為。然而，隨著微服務的普及，用於構建分散式系統的學習資源一直在不斷改進。

事件驅動
您的無伺服器平臺提供的許多BaaS自然會支援事件。對於為使用者提供可擴充套件性的第三方服務，這是一個很好的策略，因為您無法控制其服務的程式碼。由於您將在無伺服器架構中使用大量BaaS，因此您的架構是由特徵引發的事件驅動。我也確實認識到，即使您的體系結構是由特徵引發的事件驅動，但這並不意味著您需要完全接受事件驅動的體系結構。但是，我觀察到團隊傾向於採用事件驅動的架構，當它自然地提供給他們時。這是一個類似的想法，彈性作為一種特性，你仍然可以把它關閉。事件驅動帶來許多好處。您的架構元件之間的耦合程度較低。在無伺服器架構中，您可以輕鬆地引入一個偵聽blob儲存中的更改的新函式：

注意新增功能B時如何更改功能A（參見圖1）。這增加了功能的凝聚力。具有高度內聚功能有很多好處，其中之一就是您可以在失敗時輕鬆重試單個操作。在失敗時重試功能B意味著您不需要執行昂貴的功能A. 
特別是在雲中，雲供應商將確保您的FaaS易於與其BaaS整合。FaaS可以透過設計事件通知觸發。事件驅動架構的缺點是您可能開始失去整個系統的整體檢視。這使得對系統進行故障排除具有挑戰性。分散式跟蹤是您應該研究的領域，即使它仍然是無伺服器架構中的成熟領域。AWS X-Ray是一種可以在AWS中開箱即用的服務。X-Ray確實有它自己的限制，如果你已經超越它，你應該看看這個空間，因為有第三方產品正在出現。這就是記錄關聯ID的做法至關重要的原因，尤其是在事務中使用多個BaaS的情況。因此，請確保實施關聯ID。

結論
我在本文中介紹了無伺服器架構的六個特徵：低入門級，無主機，無狀態，彈性，分散式和事件驅動。我的目的是儘可能廣泛，以便您可以很好地採用無伺服器架構。無伺服器架構帶來了一個有趣的正規化轉換，這使得許多軟體開發方面變得更好。但它也帶來了技術專家必須適應的新挑戰。還有關於如何應對每個特性帶來的挑戰的簡短建議，所以希望這些挑戰不會阻止您採用無伺服器架構。

感謝James Andrew Gregory和Troy Towson對本文的全面回顧。感謝Gareth Morgan對本文進行校對和複製編輯。

點選標題見原文。