Translator|Bugatti设计良好的微服务应该遵循单一职责原则，因此分离架构中应该被其他服务重用的公共功能很重要。Sidecar模式提倡通过识别每个服务中的通用功能、将它们组合到库中或将它们移动到单独的服务中来增强模块化。顾名思义，Sidecar模式提倡分离横切关注点，将横切关注点从实际服务中移除，将它们推入单独的模块、库或服务中，然后可以被架构中的其他服务复用。本文讨论了微服务架构中哪些功能可以作为候选功能或者可以看作是Sidecar，以及Sidecar的实现方式和优缺点。SidecarCandidatesforAspect-OrientedProgramming带来了值得注意的横切关注点分离概念；简而言之，从代码中去除通用功能并只关注业务逻辑，即在服务中的每个方法/功能中重复相同的代码有什么意义。Sidecar模式在本质上是相似的；唯一的区别是Sidecar模式从微服务端进行对话。抽象代码的公共部分变得更加重要。一些最重要的候选功能包括：?日志聚合?安全性?在发布错误日志或将错误事件推送到Kafka主题或监控队列后进行错误处理并采取必要的措施。?项目中的通用功能，如实体（数据库模型）或其他服务也使用的特定业务逻辑。?其他服务正常运行所需的服务或数据库配置、Kafka配置、队列配置等配置变更。?缓存要求（如果有）。所有这些通用功能/Sidecars都可以像Sidecars附加到摩托车上一样附加到服务上。ProsandCons?Pros实现这种模式的最大优势是架构中的所有服务都可以使用所有通用功能，并且通过将通用功能抽象到不同的层中大大降低了架构的复杂性。微服务本质上是多语言的，可以使用最适合特定操作的技术或编程语言来开发这些通用功能。模式隐含地避免了代码重复，因为我们不需要在每个服务中都编写这种代码重复。服务和sidecar候选函数之间存在松耦合关系。?缺点Sidecars具有单独的可维护性，可以是一个库或一个单独的服务。如果我们在应用程序中有很多边车，那么它会影响服务的性能。需要确定sidecar功能是否需要独立于主服务进行扩展；如果是这样，这些边车需要作为单独的服务托管。实现方式?将sidecars保存在单独的库中最常见的方法是将sidecars保存在单独的库中，并将这些库分别导入微服务，例如将数据库模型保存在单独的库中，然后通过库将这些模型导入所有微服务，以及各种构建工具（如Maven、Gradle或SBT等）可用于配置。这种方式有以下缺点：Sidecar过载：想象一下在一个项目中维护多个sidecar，比如架构中的日志、缓存、配置、安全等，这可能会导致所有微服务出现sidecar过载问题。版本不一致：维护每个库的正确版本对开发人员来说将是一场噩梦，想象一下cache-libSidecar拥有服务A正在使用的最新版本1.1，但我们忘了提及cache-lib版本仍在使用中服务B的正确版本为1.0，这会在应用程序中造成明显的不一致，难以调试和识别。解决这个问题的一种方法是创建一个包含所有这些sidecar库的Uber库，然后我们需要做的就是在微服务中维护Uber库的正确版本，我们需要确保更新Uber库以使用最新版本的Sidecars，Saycache-lib1.1应该在Uber库中可用。?将sidecar保持为单独的服务另一种方法是在单独的服务中维护每个sidecar。但是为每个操作调用服务调用可能会导致严重的性能问题，但理想情况下我们通常不会为日志记录或通用功能创建服务。安全或缓存可能是理想的独立服务候选功能。这种方法的最大缺点是服务间通信总是需要优化以获得更好的性能。在这种情况下，它就像架构中的另一个微服务，总是需要扩展，监控这违背了sidecar的目的。结论Sidecar模式是一种非常有用且简洁的模式，它使横切关注点远离实际的服务实现。设计良好的微服务应始终遵循单一职责原则(SRP)，Sidecar模式通过避免重复功能来补充SRP原则。每个设计原则都有利有弊，在库中维护边车和保留最重要功能的混合方法应该在单独的服务中维护。原标题：MicroservicesPatterns:Sidecar，作者：SameerShukla链接：https://dzone.com/articles/microservices-patterns-sidecar
