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