嘿，Spring 社群！

希望大家最近都在享受 Spring One Essentials。對我來說，最令人興奮的功能是現在已經貫穿 Spring 產品組合的 可觀察性 (Observability)。儘管如此，今天我想分享一個我從假期開始就在做的專案，其中提到的可觀察性也發揮了絕佳的作用。

我將從宏觀層面開始。讓我們想象一下我們正在學習一門新的程式語言！例如，我正在學習 Go 語言，以便更好地理解 Kubernetes。當然，首先我們會處理一些基礎的原始型別和基本結構。然後，我們會實現一些眾所周知的演算法，比如氣泡排序、斐波那契數列或平方根函式，以熟悉語言的風格和預期。那麼接下來呢？我們會遇到一些實際用例，其中某些功能可以透過某些模式來實現。因此，我們會去學習這些模式（或者我們已經知道了它們），並嘗試自己實現它們來滿足我們的專案需求。但大多數時候（就像我一樣），我們會搜尋我們一直在使用的框架和工具的現有解決方案，以最大程度地減少我們自己的程式碼庫和維護負擔。此外，這樣一個現成的模式實現目錄（或庫）可以幫助開發人員用同一種簡潔的語言進行交流。

現在回到具體層面。對我來說，我每天都在使用和開發的工具和框架無疑是 Spring Integration，它已經是眾所周知的 企業整合模式 的參考實現。同時，作為一個核心功能的的訊息模型，這個專案可以輕鬆地實現不僅服務之間，甚至在一個應用程式上下文中的可伸縮的松耦合架構。此外，它還附帶了許多現成的元件和實用程式，例如重試建議、SpEL 評估和指令碼語言支援。或者分散式鎖和領導者選舉。當然，我可以繼續詳細介紹各種通道介面卡、DSL 甚至響應式流支援。但這篇文章的目標是與您分享一些內容，這些內容可以讓您在熟悉 Spring Integration 的情況下，在現代雲和微服務應用程式開發方面獲得更輕鬆的體驗。

所以，請允許我向您介紹 Microservices Patterns with Spring Integration 專案，它本質上是一組（目錄）針對 微服務架構 中描述的微服務模式的工作示例。此外，由於 Spring Integration 完全基於可分佈的訊息傳遞，我們還包含了一些 事件流模式 的實現。該專案的每個模組都是一個獨立的 Spring Boot 應用程式，在大多數情況下，應該透過提供的測試進行驗證，因為某些功能可能需要真實的環境。本專案提出的解決方案不能作為“開箱即用”的元件遷移到任何框架（Spring Integration、Spring Cloud Stream 等），因為它們需要根據您開發的目標專案進行一些程式碼調整。例如，當前的 Normalizer 模式只有 HTTP 和目錄輪詢器作為入口點，並且可以從有限數量的型別進行轉換；Outbox 模式涉及 JDBC 和 Apache Kafka，等等。

該專案仍處於早期階段，我將在閱讀完 Microservices patterns 和 Streaming Systems 這兩本書後，再回到這個專案。請隨時給我們提供任何反饋，如果您有一個適用於微服務或流媒體系統架構的用例（Watermarks？），請不要猶豫，分享您的想法和可能的 Spring Integration 解決方案！對了：我接下來要新增的模式是基於之前提到的 Micrometer Observation 的 分散式追蹤。

祝好， 
Artem