嘿，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