大使模式

创建代表使用者服务或应用程序发送网络请求的帮助程序服务。 可以将大使服务视为与客户端并置的进程外代理。

此模式可用于以与语言无关的方式卸载常见的客户端连接任务，例如监视、日志记录、路由、安全性（如 TLS）和 复原模式 。 它通常与旧版应用程序或其他难以修改的应用程序一起使用，以扩展其网络功能。 它还使专用团队能够实现这些功能。

上下文和问题

可复原的基于云的应用程序需要诸如 断路器、路由、计量和监视等功能，并且能够进行与网络相关的配置更新。 更新旧应用程序或现有代码库以添加这些功能可能很困难或不可能，因为代码不再维护或无法由开发团队轻松修改。

网络调用还可能需要对连接、身份验证和授权进行大量配置。 如果这些调用用于多个应用程序（使用多种语言和框架生成），则必须为每个实例配置调用。 此外，网络和安全功能可能需要由组织中的中心团队管理。 对于大型代码库，团队更新他们不熟悉的应用程序代码可能会有风险。

解决方案

将客户端框架和库放入充当应用程序和外部服务之间的代理的外部进程。 在应用程序所在的同一主机环境中部署代理，以允许控制路由、复原能力、安全功能，并避免任何与主机相关的访问限制。 还可以使用大使模式标准化和扩展检测。 代理可以监视性能指标，例如延迟或资源使用情况，此监视发生在与应用程序相同的主机环境中。

卸载到大使的功能可以独立于应用程序进行管理。 无需干扰应用程序的旧功能，即可更新和修改大使。 它还允许单独的专用团队实施和维护已移至大使的安全、网络或身份验证功能。

可以将大使服务部署为 Sidecar ，以随附使用的应用程序或服务的生命周期。 或者，如果大使由公共主机上的多个单独进程共享，则可以将其部署为守护程序或 Windows 服务。 如果消耗服务已容器化，则应将大使创建为同一主机上的单独容器，并配置相应的链接进行通信。

问题和注意事项

• 代理增加了一些延迟开销。 请考虑由应用程序直接调用的客户端库是否是更好的方法。
• 考虑在代理中包括通用功能可能产生的影响。 例如，大使可以处理重试，但这可能是不安全的，除非所有作都是幂等的。
• 请考虑一种机制，允许客户端将一些上下文传递给代理，并返回到客户端。 例如，包括 HTTP 请求标头以选择退出重试或指定重试的最大次数。
• 请考虑如何打包和部署代理。
• 考虑是对所有客户端使用单个共享实例，还是为每个客户端使用一个实例。

何时使用此模式

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

• 需要为多种语言或框架构建一组常见的客户端连接功能。
• 需要将跨客户端连接问题卸载给基础结构开发人员或其他更专业化的团队。
• 需要在旧版应用程序或难以修改的应用程序中支持云或群集连接要求。

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

• 当网络请求延迟至关重要时。 代理引入了一些开销，尽管开销很小，但在某些情况下，这可能会影响应用程序。
• 当客户端连接功能由单个语言使用时。 在这种情况下，更好的选择可能是作为包分发到开发团队的客户端库。
• 如果连接功能无法通用化，并且需要与客户端应用程序进行更深入的集成。

工作负荷设计

架构师应评估大使模式在工作负荷的设计中如何用于解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

示例：

下图显示了通过大使代理向远程服务发出请求的应用程序。 大使提供路由、断路器和日志记录。 它调用远程服务，然后将响应返回到客户端应用程序：

相关资源

• Sidecar 模式