無伺服器隻是事件驅動架構的一小塊兒嗎？

最近，筆者回顧了SlashData的雲原生發展報告，該報告顯示了從2020第一季度到2021季度第一季度的雲原生技術的下降。如果他們在2022年第一季度進行類似的調查，會發現無伺服器的使用最多是保持穩定，而且占整體開發者的百分比下降。

這讓筆者覺得關于無伺服器的炒作已經平息，盡管這并不意味着它不會繼續存在。

或許正如CNCF首席技術官Chris Aniszczyk表示的那樣，“這一趨勢反映了人們越來越擔心無伺服器技術缺乏廣泛采用所需的靈活性，以及組織不願意鎖定于特定的技術或供應商。”

這讓筆者思考了幾年前的另一個雲趨勢，平台即服務（PaaS）。有一段時間，AWS Elastic Beanstalk、Heroku和Cloud Foundry被吹捧為應用程式部署的未來，但它們也受到模闆化方法的影響，缺乏滿足企業更廣泛需求的靈活性。

這與今天非常相似，無伺服器本身可能是事件驅動架構大趨勢的一個很有限的子模式。

無伺服器是實作細節

無伺服器應用在早期發展非常迅速，在Node.js使用者間的應用也非常廣泛——他們希望在雲中快速部署應用程式，主要是在AWS Lambda上。此後不久，Lambda和其他功能即服務提供商提供了更多的運作時，幾乎任何現代代碼，甚至一些長期部署的遺留代碼都可以在無伺服器架構中執行。

無伺服器确實展示了許多可取的特性。它很容易放大和縮小。它由推送的事件觸發，而不是通過輪詢機制觸發。功能僅根據該作業的需要消耗資源，然後退出并釋放資源用于其他工作負載。開發人員受益于基礎設施的抽象，可以通過CI/CD管道輕松部署代碼，而不必擔心如何提供資源。

然而，Aniszczyk提到的一點是，無伺服器并不是為包括長時間運作的應用程式在内的許多情況而設計的。對于最終使用者來說，它們實際上可能比在容器、虛拟機或裸金屬上運作專用應用程式更昂貴。它迫使開發人員使用由供應商提供的模型。此外，無伺服器沒有一種簡單的方式來處理狀态。

最後，盡管無伺服器部署主要部署在雲中，但它們不容易跨雲提供商部署。管理無伺服器的工具和機制非常特定于雲，盡管可能Knative被捐贈給CNCF，可能會出現一個無伺服器平台，可以在行業的支援下開發和部署，就像Kubernetes一樣。

關鍵是，許多讓無伺服器成功的因素實際上适用于雲計算領域一個更有趣、更大的趨勢：事件驅動架構（EDA）。

雲計算中的事件驅動架構

筆者相信無伺服器的成功更多地與應用于超越無伺服器的廣泛用例集的好處有關。首先，系統能夠基于實時變化對資料進行操作的想法是遺留批處理應用程式的一大優勢。異步生成事件的消耗是非阻塞的，允許應用程式繼續工作，而無需等待響應。也沒有必要輪詢應用程式，因為它們是資料的訂戶，缺乏聊天會導緻網絡I/O的減少。

筆者花了大量時間思考這個。我們的第一個想法是，跨雲提供商缺乏一緻的工具将導緻鎖定。現在就是這樣。不僅如此，并不是所有無伺服器運作時都是平等建立的，這會阻止功能的遷移。此外，這些雲提供商中很少有機制能夠觸發一個雲中的服務或内部到另一個雲中的服務。我們最初研究了如何将無伺服器功能釋出到不同的雲，但這很麻煩，需要将運作時從一個雲移植到另一個雲。我們發現，能夠建立資料管道，使資料可操作，而不是簡單地将其付諸實施，這才是最終使用者的真正需求。

除了可移植性之外，我們還看到觸發這些功能是一場噩夢——當你想要使用來自無伺服器提供商之外的系統的輸入來觸發功能時。我們意識到，像Google EventArc和AWS EventBridge這樣的工具在建立更廣泛的事件驅動應用程式時缺乏靈活性。是以，我們開發了一種替代EventBridge的開源産品，它不僅可以向任何無伺服器平台發送資料流，還可以用于更輕松地建構資料管道，以淹沒資料湖，并執行其他類型的資料同步。

事件驅動的資料同步和工作流

我們正在朝着一個事件和資料驅動的未來邁進，在這個未來，實時處理資料的能力正在成為開展數字業務的一項要求。第一步要求資料流技術類似于AWS Kinesis，但不特定于單個供應商。Apache Kafka和Apache Pulsar符合，因為它們是開源的、雲不可知論的資料運動方式。下一步是采用跨微服務的釋出—訂閱通信，而不是對API進行REST調用。

雲的未來不一定是all in one供應商。我們以前也經曆過這樣的情況，使用者犧牲了選擇同類最佳解決方案的自由，以友善從一家供應商那裡獲得預裝配的堆棧，該供應商提供了一站式的解決方案。未來是由同類最佳技術組成的可組合系統，而不是由單一供應商提供的堆棧。針對雲原生使用者的新設計模式是可組合的基礎設施，以及由此産生的可組合的應用程式，這些應用程式是各種供應商的合并，并通過用于建立自動化工作流的事件流進行連接配接。

在Coleman Parkes進行的名為《Great EDA Migration》的調查中，大多數組織（85%）認識到采用事件驅動架構的商業價值，但采用仍處于早期階段，隻有13%的組織聲稱已經實作了完全的EDA成熟。根據這項研究，實時資料的三個最常見的應用是：應用程式內建——無伺服器用例屬于這一類；跨應用程式共享資料；以及連接配接物聯網裝置進行資料攝取和/或分析。

由于許多原因，考慮建構事件驅動架構的時間已經到了。如果你希望增加資料的新鮮度并改善數字互動，EDA可以帶來改進，而且實作這一點的工具比以往任何時候都更好。首先，越來越多的免費開源工具允許企業建立資料流，Apache Kafka和Apache Pulsar位居榜首。此外，雲原生開發的應用程式可以提供從本地資料到幾乎任何提供Kubernetes的雲的可移植性。最後，還有其他工具，比如TriggerMesh的開源雲原生內建平台，提供了建立和管理資料管道的多雲功能，可用于從AWS複制“EventBridge”功能。筆者相信，随着企業對實時資訊的渴求和需要使用這些資料的系統數量的增加，向事件驅動架構模式的遷移也會增加。幸運的是，有越來越多的替代方案可以避免鎖定在專有雲服務或軟體供應商中。