问微服务中的公共逻辑

EN

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

我们已经确定了以下“共同”的地方。当然，这份清单并不满，只是想给出一个想法：

• 消息传递基础设施(生产者/消费者、pub-sub)，与您的情况类似。
• 计量基础设施(我们已经用于千分尺的一些扩展)
• 日志配置(相同的附加程序、模式、windows/linux/mac os机器的略有不同的行为等)
• 弹簧致动器扩展部分(附加端点)
• 错误处理
• 关系数据库配置扩展(执行器健康检查，一些驱动程序扩展，等等)

我们提供的解决方案是从maven的角度提供一种不同类型的工件。这将有包装罐，并将不依赖于弹簧引导(除了必要的部件，如执行器的API，如果需要)。

我们已经从上面提到的列表中创建了一个maven模块，它本身就有一个能够加载所有所需bean的@Configuration。如果您希望使用“自动配置”来解决这个问题，请考虑使用"spring工厂“。我们使用过这种方法，它对我们非常有用。或者，如果您希望更显式，您可以创建一个注释，比如@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。

我们还发现有两种类似的公共库。与所有微服务(如日志记录、计量等)相关的内容，以及与一个微服务相关、与另一个微服务完全无关的内容。

因此，作为一种解决方案，我们已经将所有的微服务类型jars (带有spring引导插件、集成测试等等)从一个“公共-微服务”pom.xml中扩展出来，它实际上定义了所有这些公共依赖项。

因此，如果每个微服务与所有服务相关，就没有必要重新定义它们的依赖关系。

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

正如@harkesh kumar所建议的那样，您可以提供所有微服务都可以在general.The依赖项中使用的依赖关系，该依赖关系的体系结构应该具有灵活性，以便采用依赖关系的不同微服务能够根据它们的需要进行更改。

例如，您可以将ActiveMQ配置作为要添加的独立依赖项提供，同时通过application.yml键提供自定义，或者重写配置( manually.That )方式--所有不需要默认配置的微服务都可以这样做。

朗读