在微服务架构中，创建一个代表消费者服务或应用程序发送网络请求的辅助服务，被称为“大使模式”。大使服务可以被视为与客户端位于同一位置的外部代理进程。
这种模式可以用来卸载常见的客户端连接任务，如监控、日志记录、路由、安全性（如TLS）和弹性模式，以一种与语言无关的方式进行。它通常与遗留应用程序或其他难以修改的应用程序一起使用，以扩展其网络功能。此外，它还可以使专门的团队实现这些功能。
背景和问题
基于云的弹性应用程序需要诸如断路器、路由、计量和监控等功能，以及进行与网络相关的配置更新的能力。更新遗留应用程序或现有代码库以添加这些功能可能很困难或不可能，因为开发团队不再维护或无法轻松修改代码。
网络调用可能还需要对连接、身份验证和授权进行大量配置。如果这些调用跨多个应用程序使用，使用多种语言和框架构建，则必须为这些实例中的每一个配置调用。此外，网络和安全功能可能需要由组织内的中央团队管理。拥有庞大的代码库，该团队更新他们不熟悉的应用程序代码可能会有风险。
解决方案
将客户端框架和库放入一个外部进程中，该进程充当您的应用程序和外部服务之间的代理。将代理部署在与您的应用程序相同的主机环境中，以允许控制路由、弹性、安全功能，并避免任何与主机相关的访问限制。您还可以使用大使模式来标准化和扩展检测。代理可以监控延迟或资源使用等性能指标，并且这种监控发生在与应用程序相同的主机环境中。
卸载给大使的功能可以独立于应用程序进行管理。您可以在不影响应用程序的旧功能的情况下更新和修改大使。它还允许独立的专业团队实施和维护已转移给大使的安全、网络或身份验证功能。
大使服务可以部署为边车，以伴随消费应用程序或服务的生命周期。或者，如果大使由公共主机上的多个单独进程共享，则可以将其部署为守护程序或 Windows 服务。如果消费服务是容器化的，则应在同一主机上将大使创建为单独的容器，并为通信配置适当的链接。
问题和考虑
代理增加了一些延迟开销。考虑由应用程序直接调用的客户端库是否是更好的方法。考虑在代理中包含通用特征的可能影响。例如，大使可以处理重试，但这可能不安全，除非所有操作都是幂等的。考虑一种机制，允许客户端将一些上下文传递给代理，以及返回给客户端。例如，包括 HTTP 请求标头以选择退出重试或指定重试的最大次数。考虑如何打包和部署代理。考虑是为所有客户端使用单个共享实例还是为每个客户端使用一个实例。
何时使用此模式
在以下情况下使用此模式：
- 需要为多种语言或框架构建一组通用的客户端连接功能。
- 需要将跨领域的客户端连接问题转移给基础设施开发人员或其他更专业的团队。
- 需要支持遗留应用程序或难以修改的应用程序中的云或集群连接要求。
这种模式可能不适合：
- 当网络请求延迟至关重要时。代理会引入一些开销，虽然很少，并且在某些情况下这可能会影响应用程序。
- 当客户端连接功能被单一语言使用时。在这种情况下，更好的选择可能是作为一个包分发给开发团队的客户端库。
- 当连接功能无法泛化并需要与客户端应用程序进行更深入的集成时。
例子
下图显示了一个应用程序通过大使代理向远程服务发出请求。大使提供路由、断路和日志记录。它调用远程服务，然后将响应返回给客户端应用程序：
相关指导
边车模式
