Spring 社群大家好！

希望您們最近喜歡 Spring One Essentials。 對我來說，最令人興奮的功能是 可觀察性 (Observability)， 現在已遍及整個 Spring 產品組合。 儘管如此，今天我想分享一個自假期以來我一直在進行的項目，其中提到的可觀察性也具有完美的意義。

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

現在回到正題。 對於我來說，我每天都在使用和開發的工具和框架，當然是 Spring Integration，它已經是眾所周知的 企業整合模式 (Enterprise Integration Patterns) 的參考實作。 同時，作為該專案核心功能的訊息模型，允許在服務之間，甚至在一個應用程式上下文中，輕鬆實現可擴展的鬆耦合架構。 此外，它還帶有許多現成的組件和實用程式，例如重試建議、SpEL 評估和腳本語言支持。 或者分散式鎖和領導者選舉。 當然，我可以繼續談論各種通道適配器、DSL 甚至 Reactive Streams 支援。 但是，這篇部落格文章的目的是與您分享一些東西，當您已經熟悉 Spring Integration 時，它可以使您更容易地開發現代雲端和微服務應用程式。

所以，請認識一下 Microservices Patterns with Spring Integration 專案，它本質上是一組（目錄） 微服務架構 (Microservice Architecture) 上描述的微服務模式的工作範例。 此外，由於 Spring Integration 完全基於可以分散的訊息傳遞，因此我們還包含一些 事件串流模式 (Event Streaming Patterns) 實作。 該專案的每個模組都是一個獨立的 Spring Boot 應用程式，在大多數情況下，應通過提供的測試進行驗證，因為某些功能可能需要真實的環境。 本專案中提供的解決方案不能作為現成組件移動到任何框架（Spring Integration、Spring Cloud Stream 等），因為它們需要根據您開發的目標專案進行一些程式碼調整。 例如，目前的 Normalizer 模式只有 HTTP 和目錄輪詢器作為入口點，並且只能從有限數量的類型進行轉換； Outbox 模式處理 JDBC 和 Apache Kafka，等等。

該專案還處於早期階段，當我閱讀 Microservices patterns 和 Streaming Systems 書籍時，我將會回到它。 請與我們聯繫並提供任何回饋，如果您有一些適用於微服務或串流系統架構的用例（水印？），請隨時分享您的想法和 Spring Integration 的可能解決方案！ 還有：我正在考慮添加的下一個模式是基於前面提到的 Micrometer Observation 的 分散式追蹤 (Distributed Tracing)。

乾杯， 
Artem