Sidecar pattern和哈雷车类似原理:把一个应用的不同组件部署到不同的进程或容器中,以提供隔离和封装,应用的各个组件各自维护更新。这种模式还可以使应用由异构组件和技术组成,比如java服务和consul注册中心(如果公司采用了k8s技术会一般会使用)。
在现实开发中我们会遇到什么问题呢:
(1)为一个应用添加其他功能:监控、日志、配置中心、路由及熔断等功能;
这样避免了在应用本身利用aop技术或其他添加代码的方式让应用的体积变大。
(2)为一个遗留的应用,升级为https访问。这时候这个应用使用的技术太老,没人熟悉;
避免了对老应用动手术;其实这种与适配器设计模式相同的目的,已存在的不是我们希望的,但是可以添加一个中间层解决。sidecar pattern的优点:
(1)低耦合:为应用容器添加增强功能,而对其不变动;
(2)单一职责:每个容器的职责不同;
(3)即使sidecar容器失败,应用容器不受影响;
(4)复用
(5) 各自更新,不相互影响
什么时候不要考虑sidecar pattern?
(1)应用容器比较小,使用sidecar pattern容易导致复杂性和其它耗费;
(2)sidecar容器和应用容器之间的通信耗时太过敏感
网友回复