嗨，Spring 社区！

希望您最近在享受 Spring One Essentials。对我来说，最令人兴奋的功能是 可观测性，它从现在开始贯穿整个 Spring 产品组合。尽管如此，今天我想与大家分享一个我从假期就开始着手的一个项目，其中提到的可观测性也发挥了完美的作用。

我将从远处开始。假设我们正在学习一门新的编程语言！例如，我学习 Go 以更好地理解 Kubernetes。当然，我们首先会处理一些基本类型和基本结构。然后，我们实现一些众所周知的算法，例如冒泡排序、斐波那契数或平方根函数，以适应语言风格和预期。然后呢？我们有一些实际的用例，其中某些功能可以通过某些模式来涵盖。因此，我们去学习这些模式（或者我们已经知道它们）并尝试自己实现它们以满足我们的项目需求。但大多数情况下（像我一样），我们一直在寻找我们一直在使用的框架和工具的现有解决方案，以最大限度地减少我们自己的代码库和维护负担。此外，这样的现成模式实现目录（或库）有助于开发人员以相同的简洁语言进行沟通。

现在回到现实。我每天使用和开发的工具和框架当然是 Spring Integration，它已经是众所周知的 企业集成模式 的参考实现。同时，作为该项目核心功能的消息模型允许轻松实现不仅服务之间，甚至在单个应用程序上下文内都能轻松扩展的松耦合架构。此外，它还附带了许多现成的组件和实用程序，例如重试建议、SpEL 评估和脚本语言支持。或者分布式锁和领导者选举。当然，我可以继续谈论各种通道适配器、DSL 甚至 Reactive Streams 支持。但这篇博文的目的是与您分享一些内容，当您已经熟悉 Spring Integration 时，它将使您在现代云和微服务应用程序开发方面的体验变得更容易。

因此，请了解 使用 Spring Integration 的微服务模式 项目，它本质上是一组（目录）用于 微服务架构 上描述的微服务模式的工作示例。此外，由于 Spring Integration 完全基于可以分布式部署的消息传递，因此我们还包含了一些 事件流模式 实现。此项目的每个模块都是一个自包含的 Spring Boot 应用程序，在大多数情况下应通过提供的测试进行验证，因为某些功能可能需要真实的运行环境。此项目中提供的解决方案不能作为现成的组件移动到任何框架（Spring Integration、Spring Cloud Stream 等），因为它们需要根据您开发的目标项目进行一些代码调整。例如，当前的 Normalizer 模式仅具有 HTTP 和目录轮询作为入口点，并且可以从有限数量的类型进行转换；Outbox 模式处理 JDBC 和 Apache Kafka，等等。

该项目处于早期阶段，当我阅读 微服务模式 和 流式系统 书籍时，我将重新回到它。请提供任何反馈，如果您有一些用例（水印？）适合微服务或流式系统架构，请随时分享您的想法和使用 Spring Integration 的可能解决方案！再说一遍：我正在考虑添加的下一个模式是基于前面提到的 Micrometer Observation 的 分布式跟踪。

干杯！ 
Artem