使用 Spring Cloud Stream 的开发妥协
Development compromises in using Spring Cloud Stream
- event-driven 微服务（例如 Spring Cloud Stream）的案例是它们的异步性质，我同意这使它们更具可扩展性
- 但我有一个问题，关于如何以一种不会丢失我可以使用同步服务访问的某些关键功能的方式对其进行编码
- 在 servlet-based MS 中，我充分利用了 servlet 上下文变量和 servlet-based Spring 自动装配函数
- 例如，我大量利用 HTTP headers 在微服务之间传输元数据，而不必影响负载。但是在使用 Kafka 的 Spring Cloud Stream 中，Kafka 不支持任何类型的消息 header！如果我使用 SCS，我会立即丢失它。如果我清楚地定义属性，将它们放入有效载荷会导致我的模型发生各种变化 类。是的，我可以使用一个简单的 Hashmap 来模拟 HTTP header object 但对我来说这真的像是在重新发明轮子。
- 在 auto-wiring 方面：我维护每个请求的审计日志记录，我通过声明一个 request-scoped Hashmap bean 并将其自动装配到 Servlet 的调用堆栈中需要的任何方法来实现将数据附加到审计日志。基本上它只是一个全局变量，用于在单个请求中保存一些数据。但是在 SCS 中，我再次忘记了利用 servlet 的 cos bean 范围不可用。
- 到目前为止，为了让 Spring Cloud Stream 为我工作，我似乎需要做很多 trade-offs。
- 我想到了另一种方法，我使用 SCS 只是创建一个入口点，但 Source 方法只会获取事件，使用处理器构建 HTTP 请求并将请求发送到 HTTP 端点。但是，为什么要经历那么多麻烦呢？
希望一些更有经验的开发者能够阐明他们如何利用 SCS。
@feicipet 感谢您的详细问题。让我尝试按照您列出的顺序解决您的一些问题：
+1
+1
我不确定您为什么将其称为 servlet-based 而不是 Spring-based？这些是由 Spring 提供的功能，但请继续阅读。 . .
Spring Cloud Stream 不使用 Kafka，最终用户使用，而 Spring Cloud Stream 提供 Kafka binder 允许 Spring Cloud Stream 与 Kafka 集成.此外，虽然 Kafka 在 0.11 版本之前确实不支持 headers，但 Spring Cloud Stream 始终支持并将继续支持 headers 即使是 Kafka 0.11 之前的版本，将它们嵌入到 Message 和然后在消费者端将它们提取到正确的 Message headers 中，对最终用户完全透明。换句话说，人们会假设 Kafka 确实通过简单地使用 Spring Cloud Stream 来支持 headers。 Kafka 0.11+ headers 是本地支持的，我们已经调整到具有相同透明度的水平。
因此，您无需在有效负载中放置任何内容。只需创建一个合适的 Message<payload, headers>，SCSt 将负责其余的工作，而不管代理（Kafka、Rabbit、Foo 等）如何。
是的，你这样做只是因为你之前没有注意到 SCSt 提倡异步和无状态架构。但是，我不同意您要完成的是 un-accomplishable。相反，它可以按照您描述的方式完成，但还有其他方法可以保持上下文，我很乐意将其作为一个单独的主题进行讨论。
我不会称它们为 trade-offs，而是架构上的差异，这有其好处，但它不是 one-size-fits-all 架构，因此应该讨论其可行性在具体用例的上下文中。
+1。您不必将其分离为源和处理器。您可以简单地创建一个带有公开的 REST 端点和自定义处理逻辑的自定义源应用程序。然而，我们目前正在努力改进框架，以确保您可以对现有的入门应用程序执行相同的操作。
显然我们在这里谈到了很多要点，其中一些可能需要进一步讨论，但我希望这能消除您的一些顾虑。
干杯
- event-driven 微服务（例如 Spring Cloud Stream）的案例是它们的异步性质，我同意这使它们更具可扩展性
- 但我有一个问题，关于如何以一种不会丢失我可以使用同步服务访问的某些关键功能的方式对其进行编码
- 在 servlet-based MS 中，我充分利用了 servlet 上下文变量和 servlet-based Spring 自动装配函数
- 例如，我大量利用 HTTP headers 在微服务之间传输元数据，而不必影响负载。但是在使用 Kafka 的 Spring Cloud Stream 中，Kafka 不支持任何类型的消息 header！如果我使用 SCS，我会立即丢失它。如果我清楚地定义属性，将它们放入有效载荷会导致我的模型发生各种变化 类。是的，我可以使用一个简单的 Hashmap 来模拟 HTTP header object 但对我来说这真的像是在重新发明轮子。
- 在 auto-wiring 方面：我维护每个请求的审计日志记录，我通过声明一个 request-scoped Hashmap bean 并将其自动装配到 Servlet 的调用堆栈中需要的任何方法来实现将数据附加到审计日志。基本上它只是一个全局变量，用于在单个请求中保存一些数据。但是在 SCS 中，我再次忘记了利用 servlet 的 cos bean 范围不可用。
- 到目前为止，为了让 Spring Cloud Stream 为我工作，我似乎需要做很多 trade-offs。
- 我想到了另一种方法，我使用 SCS 只是创建一个入口点，但 Source 方法只会获取事件，使用处理器构建 HTTP 请求并将请求发送到 HTTP 端点。但是，为什么要经历那么多麻烦呢？
希望一些更有经验的开发者能够阐明他们如何利用 SCS。
@feicipet 感谢您的详细问题。让我尝试按照您列出的顺序解决您的一些问题：
+1
+1
我不确定您为什么将其称为 servlet-based 而不是 Spring-based？这些是由 Spring 提供的功能，但请继续阅读。 . .
Spring Cloud Stream 不使用 Kafka，最终用户使用，而 Spring Cloud Stream 提供 Kafka binder 允许 Spring Cloud Stream 与 Kafka 集成.此外，虽然 Kafka 在 0.11 版本之前确实不支持 headers，但 Spring Cloud Stream 始终支持并将继续支持 headers 即使是 Kafka 0.11 之前的版本，将它们嵌入到 Message 和然后在消费者端将它们提取到正确的 Message headers 中，对最终用户完全透明。换句话说，人们会假设 Kafka 确实通过简单地使用 Spring Cloud Stream 来支持 headers。 Kafka 0.11+ headers 是本地支持的，我们已经调整到具有相同透明度的水平。 因此，您无需在有效负载中放置任何内容。只需创建一个合适的
Message<payload, headers>，SCSt 将负责其余的工作，而不管代理（Kafka、Rabbit、Foo 等）如何。是的，你这样做只是因为你之前没有注意到 SCSt 提倡异步和无状态架构。但是，我不同意您要完成的是 un-accomplishable。相反，它可以按照您描述的方式完成，但还有其他方法可以保持上下文，我很乐意将其作为一个单独的主题进行讨论。
我不会称它们为 trade-offs，而是架构上的差异，这有其好处，但它不是 one-size-fits-all 架构，因此应该讨论其可行性在具体用例的上下文中。
+1。您不必将其分离为源和处理器。您可以简单地创建一个带有公开的 REST 端点和自定义处理逻辑的自定义源应用程序。然而，我们目前正在努力改进框架，以确保您可以对现有的入门应用程序执行相同的操作。
显然我们在这里谈到了很多要点，其中一些可能需要进一步讨论，但我希望这能消除您的一些顾虑。
干杯