微服务中的通用逻辑

Question

根据微服务原则，我们开发了 5 到 6 个微服务，彼此独立，拥有自己的数据库。

现在我们正在重构服务，遇到以下困境。

1. 所有微服务都从 ActiveMQ 发送和接收消息。
   • ActiveMQ（ JmsListenerContainerFactory ， Handlers 等）的配置细节 Boilerplate 代码在所有这些服务中重复。
2. 所有微服务都具有审计功能，例如：对订单创建、更新和删除的审计。- AOP Logic 相关配置也在所有这些微服务中重复。

将这些通用逻辑移动到库或通用服务中是否是一个好习惯。请建议。

谢谢，

Answer 1

当我开始在工作中使用微服务时，我也在同一条船上。

我们已经确定了以下“常见”位置。当然，这个列表并不完整，只是提供一个想法：

• 消息基础设施（生产者/消费者，发布 - 订阅）就像你的情况
• 计量基础设施（我们用于千分尺的一些扩展）
• 日志配置（相同的 appender、模式、windows/linux/mac os 机器的行为略有不同等）
• 弹簧执行器扩展（附加端点）
• 错误处理
• 关系数据库配置扩展（执行器健康检查、一些驱动程序扩展等）

我们提出的解决方案是提供一种与 Maven 的观点不同的工件。这将有包装罐，并且根本不依赖于弹簧靴（除了需要的部分，如执行器的 API，如果需要的话）。

我们为上述列表中的每个项目创建了一个 maven 模块，该模块本身具有@Configuration能够加载所有必需 bean 的内容。如果您希望通过“自动配置”解决它，请考虑使用“弹簧工厂”。我们已经使用了这种方法，它对我们很有用。或者，如果你想更明确，你可以创建一个注释，这样@EnableXYZ基本上会导入 jar 模块的配置：

 @Target(ElementType.TYPE)
 @Retention(RetentionPolicy.RUNTIME)
 @Import({CommonErrorHandlingConfiguration.class})
 public @interface EnableErrorHandling {

 }

 ...

 @Configuration 
 public class CommonErrorHandlingConfiguration {
   // beans relevant for error handling appear here
 }

在这个例子中，有一个模块被调用common-error-handling，它包含上述两个类。

现在您的微服务将其作为依赖项，并且可以使用此@EnableErrorHandling注解来激活CommonErrorHandlingConfiguration

我们还发现有两种这样的公共库。与所有微服务相关的东西（如日志记录、计量等），以及与一个微服务相关但与另一个微服务完全无关的东西。

因此，作为一种解决方案，我们将所有微服务类型 jar（带有 Spring Boot 插件、集成测试等）都从一个“common-microservice” pom.xml 扩展，该 pom.xml 实际上已经定义了所有这些公共依赖项。

因此，如果它们与所有服务相关，则无需为每个微服务重新定义依赖项。

还值得一提的是，这种方法只有在所有微服务共享相同技术的情况下才能起作用，否则在相同情况下使用side-car容器可能更合适。