www.ydisp.cn/oss/202207/13/810d10916a974e0b22f960aeb34d4d017c7810.jpg"style="width:643px;能见度：可见；height:429px;"data-type="inline">译者|Bugatti合理设计的微服务应该遵循单一职责原则，所以在架构中分离应该被其他服务重用的公共功能很重要。Sidecar模式提倡增强模块化，通过识别每个服务中的公共功能，将它们组合到库中，或者将它们移动到单独的服务中。顾名思义，Sidecar模式提倡分离横切关注点（cross-cuttingconcerns），从中去除横切关注点将实际的服务推送到单独的模块、库或服务中，这些功能可以被架构中的其他服务复用。本文讨论微服务架构中哪些功能可以作为候选功能，或者可以看作是Sidecar，如以及Sidecar的实现方式和优缺点，Sidecar候选函数是面向aspec的t编程带来了值得注意的横切关注点分离概念；简而言之，从代码中删除通用功能并只关注业务逻辑，这与在服务内的每个方法/功能中重复相同的代码意味着与sidecar模式在本质上是相似的；唯一的区别是sidecar模式从微服务端进行对话。抽象代码的公共部分变得更加重要。一些最重要的候选功能包括：?日志聚合?安全性?错误处理，并在发布错误日志或将错误事件推送到Kafka主题或监控队列后采取必要的操作。?项目中的通用功能，如实体（数据库模型）或其他服务也使用的特定业务逻辑。?其他服务服务或数据库配置、Kafka配置、队列配置等方面的配置更改需要正常运行。?缓存要求（如果有这样的需要）。所有这些通用功能/Sidecars都可以附加到服务，例如摩托车上的Sidecar附件。ProsConsPros实现这种模式的最大优点是架构中的所有服务都可以使用所有通用功能，并且通过将通用功能抽象到不同的层来大大降低架构的复杂性。微服务本质上是多语言的，这些通用功能可以使用最适合该特定操作的技术或编程语言进行开发。模式隐含地避免了代码重复，因为我们不需要在每个服务中都编写这种重复代码、服务和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
