Sidecar pattern          

                                             

                                                        

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

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

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

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

                                                    

                            

                                                   配置文件  Sidecar pattern

                                                              日志收集Sidecar pattern

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

                                                  

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

 

 

sidecar pattern的优点：

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

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

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

（4）复用

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

 

什么时候不要考虑sidecar pattern

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

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

 

 

任何设计都有适合的场景，只能根据当前环境选择。

 

参考：

https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar

https://tachingchen.com/tw/blog/desigining-distributed-systems-the-sidecar-pattern-concept/

https://www.beautifulcode.co/blog/55-what-is-sidecar-pattern

https://dzone.com/articles/sidecar-design-pattern-in-your-microservices-ecosy-1

Designing Distributed Systems.pdf