# sidecar模式

## Sidecar模式是什么

Sidecar模式是一种单节点、多容器的应用设计形式。Sidecar主张以额外的容器来扩展或增强主容器,而这个额外的容器被称为Sidecar容器

sidecar 模式也符合当前微服务的以下特点:

* 隔离(separation of concerns):让每个容器环境不需要相互依赖而独立运行,也就意味着sidecar程序可以和任何语言的应用服务一起运行。
* 单一责任原则(single responsibility principle),各个容器负责自己的处理逻辑,各司其职
* 内聚性/可重用性(Cohesiveness/Reusability)

## sidecar模式原则

* 考虑部署服务、进程或容器时所用的部署和打包格式。容器特别适合用于sidecar模式。
* 在设计sidecar服务时,请慎重决定进程间通信机制。除非达不到性能要求,否则请尽量使用不区分语言或框架的技术。
* 在将功能放入sidecar之前,请考虑该功能是作为独立的服务还是更传统的守护程序运行更有利。

此外,请考虑是否能够以库的形式或使用传统扩展机制实现功能.特定于语言的库可能提供更深度的集成和更少的网络开销。

## 什么时候适合使用sidecar

在以下情况下使用此模式:

* 主应用程序使用一组异类语言和框架.使用不同框架以不同语言编写的应用程序可以使用sidecar服务中的某个组件。
* 某个组件由远程团队或不同的组织拥有。
* 某个组件或功能必须共置在应用程序所在的同一台主机上
* 希望某个服务与主应用程序具有相同的整体生命周期,但同时又能独立更新该服务。
* 需要精细控制特定资源或组件的资源限制.例如,想要限制特定组件使用的内存量.可将组件部署为sidecar,然后独立于主应用程序管理内存用量。

此模式可能不适用于以下情况:

* 当进程间通信需要优化时.父应用程序与sidecar服务之间的通信会产生一定的开销,执行调用时存在明显的延迟。频繁通信的接口可能无法接受这种弊端。
* 在某些小型应用程序中,为每个实例部署sidecar服务所产生的资源开销会抵消隔离所带来的优势。
* 当服务需要以不同于或独立于主应用程序的方式缩放时.如果存在这种情况,将功能部署为独立的服务可能更好。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://rocdu.gitbook.io/deep-understanding-of-istio/1/4.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.