搜索

回答

Sidecar pattern和哈雷车类似原理：把一个应用的不同组件部署到不同的进程或容器中，以提供隔离和封装，应用的各个组件各自维护更新。这种模式还可以使应用由异构组件和技术组成，比如java服务和consul注册中心（如果公司采用了k8s技术会一般会使用）。

在现实开发中我们会遇到什么问题呢：

（1）为一个应用添加其他功能：监控、日志、配置中心、路由及熔断等功能；

这样避免了在应用本身利用aop技术或其他添加代码的方式让应用的体积变大。

（2）为一个遗留的应用，升级为https访问。这时候这个应用使用的技术太老，没人熟悉；

避免了对老应用动手术；其实这种与适配器设计模式相同的目的，已存在的不是我们希望的，但是可以添加一个中间层解决。

sidecar pattern的优点：

（1）低耦合：为应用容器添加增强功能，而对其不变动；

（2）单一职责：每个容器的职责不同；

（3）即使sidecar容器失败，应用容器不受影响；

（4）复用

(5) 各自更新，不相互影响

什么时候不要考虑sidecar pattern？

（1）应用容器比较小，使用sidecar pattern容易导致复杂性和其它耗费；

（2）sidecar容器和应用容器之间的通信耗时太过敏感

网友回复

我知道答案，我要回答

我有问题