大使模式(Ambassador)
创建代表消费者服务或应用程序发送网络请求的帮助服务。可以认为大使服务是与客户端共处的进程外代理。
此模式可用于以语言无关的方式卸载常见的客户端连接任务，如监视，日志记录，路由，安全性（如TLS）和弹性模式。它常常与传统应用程序或其它难以修改应用程序一起使用，以便扩展其网络功能。也可以让专门的团队实现这些功能。
背景和问题
基于云的弹性应用程序需要断路器，路由，计量和监控等功能，以及进行网络相关配置更新的功能。遗留应用程序或现有代码库可能难以或不可能添加这些功能，因为代码缺乏维护，或者开发团队无法轻易修改。
网络调用也可能需要大量配置来进行连接，认证和授权。如果这些调用在多个使用不同语言和框架构的建应用程序中使用，必须为每个实例配置调用。此外，网络和安全功能可能需要由组织内的中央团队进行管理。对于很大的代码库，该团队更新他们不熟悉的应用程序代码可能会有风险。
解决方案
将客户端框架和库放入外部进程，作为应用程序和外部服务之间的代理。在与应用程序相同的主机环境中部署代理，从而增加路由控制，弹性，安全功能，并避免任何与主机相关的访问限制。还可以使用大使模式来标准化和扩展仪表。代理可以监视性能指标，例如延迟或资源使用情况，以及监控应用程序运行主机环境。
卸载到大使的功能可以独立于应用程序进行管理。更新和修改大使不会影响应用程序的旧功能。单独的专门小组可以来实现和维护移交给大使的安全性，网络或认证功能。
大使服务可以作为挎斗部署，陪伴在消费应用程序或服务的整个生命周期。 或者，如果大使由公共主机上的多个独立进程共享，则可以将其部署为守护程序或Windows服务。如果消费服务是容器化的，那么大使应该被创建为同一个主机上的一个单独的容器，并配置相应的链接进行通信。
问题和注意事项
代理增加了一些延迟开销。考虑应用程序直接调用客户端库的方式是否更好。
- 考虑在代理中包含泛化特征的可能影响。 例如，大使可以处理重试，但这可能不安全，除非所有操作都是幂等的。
- 考虑一种允许客户端将某些上下文传递给代理的机制，以及返回给客户端。 例如，包括HTTP请求头部以选择不重试或指定重试的最大次数。
- 考虑如何包装和部署代理。
- 考虑是否为所有客户端使用单个共享实例或为每个客户端使用实例。
何时使用该模式
在以下场景适用于该模式：
- 需要为多种语言或框架构建一套通用的客户端连接功能。
- 需要将交叉客户端连接问题卸载给基础架构开发人员或其他更专业的团队。
- 需要支持遗留应用程序或难以修改的应用程序上云或集群连接。
该模式可能不适合以下场景：
- 当网络请求延迟要求较高。代理会引入一些时延开销，虽然开销不高，但在某些情况下可能会影响应用程序。
- 客户端连接功能由单一语言使用时。 这种情况下更好的选择可能是作为依赖库以包的形式分发给开发团队的客户端。
- 连接功能无法泛化，需要与客户端应用程序进行更深入的集成。
案例
下图显示了通过大使代理向远程服务发出请求的应用程序。大使提供路由，断路和日志记录。它调用远程服务，然后将响应返回给客户端应用程序：
