微服务模式：Sidecar

 

合理设计的微服务应遵循单一职责原则，因此分离应该被架构中的其他服务重用的通用功能很重要。Sidecar模式提倡通过识别每个服务中的通用功能来增强模块性，将它们组合到库中，或将它们移到单独的服务中。

顾名思义，Sidecar模式提倡分离横切关注点（cross-cutting concern），将横切关注点从实际服务中移除，推送到单独的模块、库或服务，然后这些功能可被架构中的其他服务重用。

本文讨论了微服务架构中哪种功能可以作为候选功能或可以被视为Sidecar，以及Sidecar的实现方法和优缺点。

Sidecar候选功能

面向切面编程带来了分离横切关注点这个值得关注的概念；简而言之，从代码中移除通用功能，只关注业务逻辑，这就是在服务内的每个方法/函数中重复相同代码的意义所在。

Sidecar模式本质上相似；唯一的区别是，Sidecar模式从微服务方面进行对话。将代码的通用部分抽象出来变得更重要了。

一些最重要的候选功能包括如下：

•日志聚合

•安全

•错误处理，并在发布错误日志或将错误事件推送到Kafka主题或监控队列之后采取必要的动作。

•项目中的通用功能类似于实体（数据库模型）或其他服务也使用的特定业务逻辑。

•其他服务正常运行所需要的服务或数据库配置、Kafka配置、队列配置等方面的配置更改。

•缓存需求（如果有这种需求的话）。

所有这些通用功能/Sidecar可以附加到服务上，就像边车附加到摩托车上那样。

优缺点

•优点

实施这种模式的最大优点是，所有通用功能都可供架构中的所有服务使用，它通过将通用功能抽象到不同的层，大大降低了架构的复杂性。

微服务本质上是多语言的，这些通用功能可以使用最适合该特定操作的技术或编程语言来开发。

模式隐式避免了代码重复，因为我们不需要在每个服务中编写这种重复的代码。

服务和Sidecar候选功能之间是松散耦合的关系。

•缺点

Sidecars具有单独的可维护性，这可能是库或单独的服务。如果我们在应用程序中有大量的Sidecar，那么它会影响服务的性能。需要确定Sidecar功能是否需要独立于主服务进行扩展；如果是，需要将这些Sidecar作为单独的服务来托管。

实施方法

•将Sidecars保存在单独的库中

最常见的方法是将Sidecars保存在单独的库中，并将这些库单独导入到微服务中，比如将数据库模型保存在单独的库中，然后通过该库将这些模型导入到所有微服务，有各种构建工具（比如Maven、Gradle或SBT等）可用用于配置。

这种方法有以下缺点：

Sidecar过载：设想一个项目中维护多个Sidecar，比如架构中存在的日志、缓存、配置和安全都可能会在所有微服务中带来Sidecar过载的问题。

版本不一致：维护每个库的正确版本对于开发人员来说将是一场噩梦，想象一下cache-lib Sidecar拥有服务A在使用的最新版本1.1，但我们忘了提及仍在使用cache-lib版本1.0的服务B的正确版本，这会在应用程序中产生明显的不一致，而这种不一致很难调试和识别。

解决这个问题的一种方法是创建一个含有所有这些Sidecar库的Uber库，然后我们需要做的就是在微服务中维护Uber库的正确版本，我们需要确保Uber库经过更新，使用最新版本的Sidecars，比如说cache-lib 1.1应该在Uber库中可用。

•将Sidecars保留为单独的服务

另一种方法是在单独的服务中各自维护Sidecar。但是为每个操作调用服务调用会带来严重的性能问题，但理想情况下，我们通常不为日志或通用功能创建服务。安全或缓存可能是理想的独立的服务候选功能。

这种方法的最大缺点是，始终需要优化服务间通信以获得更好的性能。在这种情况下，它就像架构中的另一个微服务，总是需要扩展，监控哪种有悖Sidecar的用途。

结论

Sidecar模式是一种非常有用且简洁的模式，它使横切关注点远离实际的服务实现。合理设计的微服务应该始终遵循单一职责原则（SRP），而Sidecar模式通过远离重复功能来补充SRP原则。每个设计原则都有优缺点，在库中维护Sidecar以及保留最重要功能的混合方法应该在单独的服务中加以维护。