Spring 社群的朋友們，大家好！

我希望您這些天享受 Spring One Essentials。對我來說，最令人興奮的特性是 可觀察性，它現在遍佈整個 Spring 產品組合。儘管如此，今天我想分享一個我從假期開始一直在做的專案，其中提到的可觀察性也很有意義。

我將從遠處開始。讓我們想象一下我們正在學習一門新的程式語言！例如，我正在學習 Go，以便更好地理解 Kubernetes。當然，我們首先處理一些原語和基本結構。然後，我們實現一些眾所周知的演算法，例如氣泡排序、斐波那契數或 sqrt 函式，以適應語言風格和期望。現在怎麼樣？我們有一些真實的用例，其中這個或那個功能可以被某些模式覆蓋。因此，我們去學習這些模式（或者我們已經知道它們），並嘗試自己實現它們以滿足我們的專案需求。但大多數情況下（像我一樣），我們搜尋一直在使用的框架和工具的現有解決方案，以最大限度地減少我們自己的程式碼庫和維護負擔。此外，這種現成模式實現的目錄（或庫）有助於開發人員以相同的簡潔語言相互交流。

現在開始正題。對我來說，我每天都在使用和開發的工具和框架當然是 Spring Integration，它已經是眾所周知的 企業整合模式的參考實現。與此同時，作為該專案的核心功能的訊息傳遞模型允許實現易於擴充套件的鬆散耦合架構，不僅在服務之間，甚至在一個應用程式上下文中。此外，它還附帶許多現成的元件和實用程式，例如重試建議、SpEL 評估和指令碼語言支援。或者分散式鎖和領導者選舉。當然，我可以繼續談論各種通道介面卡、DSL 甚至 Reactive Streams 支援。但此部落格文章的目的是與您分享一些東西，如果您已經熟悉 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 書籍時，我會回來繼續開發。請隨時與我們聯絡並提供任何反饋，如果您有一些適合微服務或流系統架構的用例（水印？），請不要猶豫分享您的想法以及使用 Spring Integration 的可能解決方案！還有：我正在考慮新增的下一個模式是基於之前提到的 Micrometer Observation 的 分散式追蹤。

乾杯！
Artem