Ambassador pattern

（https://learn.microsoft.com/en-us/azure/architecture/patterns/ambassador）

简单描述

1. 创建一个助手服务，这个服务代表消费服务或者应用程序发送网络请求。大使服务可以看做是与客户机同一个位置的进程外代理。

2. 这种设计模式可以用于承担常见的连接任务，例如监控，日志，路由，安全。并且可以以语言无关的方式进行弹性扩展。它经常用于历史遗留应用或者那些很难去修改的应用，用于扩展他们的网络功能，它同样可以由专门的团队去实现特性。

背景和问题 

1. 弹性云应用需要一些特性，例如熔断机制，路由，统计和监控，并且具有更新网络相关配置的能力，可能很难或者不可能去更新历史遗留应用或者在已有代码库上增加特性，因为这些代码很久没有维护或者开发团队很难去修改。

2. 网络调用需要对连接、身份验证和授权进行大量的配置，如果这些调用使用在跨多个应用中，用多种语言和框架构建，这些调用必须在每个实例中都要配置。此外，网络和安全功能需要由组织内的中心团队去管理。对于大型代码库，团队成员去修改他们不熟悉的代码可能有风险。

 

解决办法 

1. 在另外一个进程中放入框架和库，在你的应用和其他服务之间作为一个代理。在应用所在的环境中部署一个代理，用以允许控制路由，弹性和安全特性，并且避免任何与主机有关的访问限制。你同样可以使用大使模式去标准化和扩展工具。代理可以监控性能指标，例如延迟、资源消耗，并且这种监控发生在与应用相同的环境中。

2. 

3. 特性从大使卸载后也可以被应用单独管理，您可以在不影响应用程序遗留功能的情况下更新和修改大使。同样也可以考虑专门的团队去实现和维护已经被移动到大使中的安全、网络或者身份验证特性。

4. 大使服务可以作为辅助工具部署，伴随消费应用程序或服务的生命周期。或者大使被一个公共主机的多个不同进程使用，它同样可以部署为一个守护进程或者windows服务。如果消费服务是容器化部署，大使应该在同一个主机上作为一个单独的容器创建，使用适当的链接配置去通信。

 

问题和考虑 

1. 代理增加了一些延迟开销。考虑应用程序直接调用客户端库是一个更好的方法。

2. 考虑到代理包含的普遍特性可能产生的影响。例如，大使可以处理重试，但不是很安全，除非所有操作都是幂等的。

3. 考虑一种机制，允许客户端将一些上下文传递给代理，以及返回给客户端。例如，包括HTTP请求头以选择不重试或指定重试的最大次数。

4. 考虑如何打包和部署代理。

5. 考虑是否使用单例或者每个客户端使用一个实例。

 

什么时候使用 

1. 需要为多语言或者框架构建一组通用的客户端连接特性。

2. 需要将横切客户端连接问题卸载给基础设施开发者或者其他专业团队。

3. 需要在历史遗留应用或者很难修改的应用中支持云或者集群连接需求。

 

不适合的场景 

1. 当网络延迟非常严重时，代理会有开销 ，虽然很小，在有些场景会影响到应用程序。

2. 当客户端连接特性是由单一语言使用的。这种情况下，更好的办法是作为客户端库作为包分发给开发团队。

3. 当连接特性不能通用化，并且需要和客户端应用程序深度集成。

 

示例 

下面的图展示了应用程序经过了大使代理进行了一段远程请求。大使提供了路由，熔断和日志。它调用了远程服务并且给客户端机器返回了应答。

欢迎大家留言沟通