你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
将应用程序组件部署到独立于主应用程序的进程或容器中，以提供隔离和封装。 此模式使你能够基于各种组件和技术生成应用程序。
与摩托车侧车一样，这些组件附加到父应用程序并共享其生命周期，因此你可以一起创建和停用它们。 此模式也称为 Sidekick 模式 ，并支持应用程序分解。
上下文和问题
应用程序和服务通常需要相关功能，例如监视、日志记录、配置和网络服务。 可以将这些外围任务实现为单独的组件或服务。
紧密集成的组件在同一进程中运行，并有效地使用共享资源，但它们缺乏隔离。 一个组件中的中断可能会影响整个应用程序。 它们还需要在父应用程序的语言中实现，从而创建相互依赖。
如果将应用程序分解为服务，则可以使用不同的语言和技术生成每个服务。 此方法提供更大的灵活性。 但每个组件都有自己的依赖项，需要特定于语言的库才能访问平台和共享资源。 将这些功能部署为单独的服务时，将添加延迟。 特定于语言的代码和依赖项也增加了托管和部署的复杂性。
解决方案
在单独的进程或容器中将一组任务与主应用程序一起部署。 此方法为跨语言的平台服务提供一致的界面。
挎斗服务无需成为应用程序的一部分即可与其连接，并与其一起部署。 每个应用程序实例都有一个与其生命周期相同的挎斗实例。
Sidecar 模式具有以下优势：
语言独立性： sidecar 独立于主应用程序的运行时环境和编程语言运行。 可以在使用不同编程语言编写的应用程序中采用一个挎斗实现。
共享资源访问： sidecar 可以访问与主应用程序相同的资源。 例如，挎斗可以监视两个组件使用的系统资源。
低延迟：挎斗靠近主应用程序可最大程度地降低通信延迟。
增强的扩展性： 可以通过将 sidecar 附加为同一主机或子容器上的单独进程来扩展缺少本机扩展机制的应用程序。
此模式的最常见实现使用容器，这些 容器也称为 sidecar 容器 或 sidekick 容器。
问题和注意事项
实现此模式时，请考虑以下几点：
考虑部署和打包格式以部署服务、进程或容器。 容器适用于 Sidecar 模式。
考虑平台如何相对于主应用程序管理 sidecar 的生命周期。 Kubernetes 提供原生边车容器，能够确保边车在主应用程序容器之前启动，并在主应用程序容器之后终止。 此行为无需自定义启动顺序逻辑，并可避免在应用程序仍依赖边车容器时边车容器退出而导致的关闭竞态。 有关更多信息，请参阅 适用于 AKS 的基于 Istio 的服务网格加载项的本机边车模式。
在设计挎斗服务时，请慎重选择进程间通信机制。 除非性能要求使这种方法不切实际，否则使用与语言无关或与框架无关的技术。
在向挎斗添加功能之前，请评估它能否更好地用作独立服务或传统的守护程序。
考虑是将功能实现为库还是通过传统的扩展机制实现。 特定于语言的库提供更深入的集成和更少的网络开销。
何时使用此模式
在以下情况下使用此模式：
主应用程序使用不同的语言和框架。 Sidecars 提供一致的界面，无论其语言或框架如何，不同的应用程序都可以使用。
独立团队或外部合作伙伴拥有一个组件。
必须在与应用程序相同的主机上部署组件或功能。
你需要一个服务，该服务共享主应用程序的整个生命周期，但你可以独立更新。
需要对特定资源或组件的资源限制进行精细控制。 例如，可以将组件作为 sidecar 部署，从而独立于主应用程序来限制和管理其内存使用情况。
在以下情况下，此模式可能不适用：
需要优化进程间通信。 挎斗增加了开销，尤其在延迟方面，因而其不适合用于组件之间频繁通信的应用程序。
应用程序很小。 为每个实例部署挎斗的资源成本可能会削弱其隔离优势。
你需要单独缩放组件。 如果必须以不同于主应用程序的方式缩放组件，请改为将其部署为单独的服务。
你的平台提供等效的功能。 如果应用程序平台已在本机提供所需功能，挎斗会增加不必要的复杂性。
服务网格提供满足要求的无侧排数据平面。 无侧线数据平面可避免每个实例的代理的资源开销。
工作负荷设计
评估如何在工作负荷设计中使用挎斗模式来实现 Azure 架构良好的框架支柱中涵盖的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 安全设计决策有助于确保工作负荷数据和系统的机密性、完整性和可用性。 | 当你将这些任务封装并部署到独立的进程中时，可以将攻击面减少到仅包括必要的代码。 还可以使用挎斗为缺乏这些功能本机支持的应用程序组件添加横切安全控制。 - SE:04 分段 - SE:07 加密 |
| 卓越运营通过标准化流程和团队凝聚力帮助交付工作负载质量。 | 此模式使你可以灵活集成可观测性工具，而无需向应用程序代码添加依赖项。 可以独立于应用程序来更新和维护挎斗。 - OE:04 工具和流程 - OE:07 监视系统 |
| 通过缩放、数据和代码的优化，性能效率可帮助工作负荷高效地满足需求。 | 此模式允许你在随多个应用实例扩展的挎斗中集中管理横切任务。 无需为每个应用程序实例部署重复功能。 - PE:07 代码和基础结构 |
如果此模式在某个支柱中引入权衡取舍，请将它们与其他支柱的目标进行对比。
Example
可以将 Sidecar 模式应用于许多方案。 请考虑以下示例：
依赖项抽象： 与每个应用程序一起部署自定义服务，以通过一致的 API 提供对共享依赖项功能的访问权限。 此方法用挎斗取代特定于编程语言的客户端库，挎斗负责处理日志记录、配置、服务发现、状态管理和运行状况检查等任务。
服务网格数据平面：将挎斗代理与每个服务实例一起部署，以处理横切网络问题，例如流量路由、重试、相互传输层安全性 (mTLS)、策略强制和遥测。
Istio 等服务网格使用 sidecar 代理来实现这些功能，而无需更改应用程序代码。
大使挎斗：将大使服务部署为一个挎斗。 应用程序通过中介传递调用，该中介处理请求日志记录、路由、熔断机制和其他连接功能。
协议适配器： 部署辅助模块以在不兼容的协议或数据格式之间进行转换，或桥接消息系统。 此方法允许应用程序使用更简单的接口或旧接口。
遥测扩充：在将数据转发到外部监视系统之前，部署挎斗来预处理或扩充遥测数据，例如指标、日志和跟踪。 OpenTelemetry 收集器等组件可以独立于应用程序作为挎斗运行，以规范化、扩充或路由遥测数据。
后续步骤
使用 Dapr 的微服务 API：了解 Azure 容器应用如何使用 Dapr sidecars 来帮助你构建简单、可移植、可复原和安全微服务。
Azure Kubernetes 服务（AKS）中基于 Istio 的服务网格功能的原生 sidecar 模式：了解 AKS 的 Istio 服务网格功能如何使用 Sidecar 模式来解决分布式架构挑战。