Azure 设计模式之大使模式

大使模式


为消费者服务或应用程序创建发送请求的辅助服务。大使服务可被认为是与客户端协同工作的进程外代理。


该模式可用于完成常见的客户端连接相关的任务，如监视，日志记录，路由，安全性（如TLS）和弹性模式(https://docs.microsoft.com/en-us/azure/architecture/patterns/category/resiliency) 。它常与较传统的或难以修改的应用程序一起使用，以便扩展其网络相关功能。这些功能也可以由专门的团队来完成。


问题背景
弹性良好的应用程序（https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker）可能需要如断路，路由，统计和监控等功能，以及相关配置的更新。要添加以上功能，对版本老旧的应用程序或现有代码库进行更新比较困难，因为代码已经不再被维护，或者开发团队不能对其轻易修改。


网络调用也可能需要大量的配置进行连接，认证以及授权。如果这些调用在多个应用程序之间发生，这些应用使用多种语言和框架构建，则必须为每个这些实例的调用进行逐个配置。此外，网络和安全功能可能需要由专门团队进行统一管理。由于代码库很大，该团队可能会更新到他们所不熟悉的应用程序代码，这样做是有风险的。


解决方案
将客户端框架和库放入外部进程中，作为应用程序和外部服务之间的代理。将代理部署到与应用程序相同的主机环境中，以完成路由控制，系统弹性，安全相关功能，并避免任何与主机相关的访问限制。您还可以使用大使模式来标准化和扩展这些服务。代理可以监视性能指标，例如延迟或资源使用情况，并且此监视与应用程序在同一主机环境中进行。




由代理完成的功能可以独立于应用程序进行管理。可以单独更新代理，而不会影响应用程序的功能。也可以由专门团队来维护代理中的安全性，网络或认证等功能。


代理服务可以部署为一个sidecar模式(https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar) ，伴随应用程序或服务的整个生命周期。或者如果代理被公共主机上的多个进程共享，则可以将其部署为守护程序或Windows服务。如果服务是容器化的，那么代理应该被放在一个单独的容器中，并使用适当的链接进行通信。




问题和思考
代理的使用增加了一些延迟的开销。需要考虑应用程序直接调用类库是否是更好的方法。


思考代理中包含的泛化功能可能的影响。例如，执行重试，这可能不是安全的，除非所有操作都是幂等的。


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


考虑如何封装和部署代理。


考虑是否为所有客户端使用单个共享实例还是为每个客户端各自使用实例。


何时使用这种模式
需要为多种语言或框架构建一套通用的客户端连接功能。
需要将客户端连接问题交给基础架构开发人员或其他更专业的团队。
需要在陈旧或难以修改的应用程序中支持云或集群连接。




这种模式可能不适用于：
网络请求延迟至关重要。代理将引入一些开销，尽管能够最小化，在某些情况下依然会影响应用程序。
当客户端连接功能被单一语言使用时。在这种情况下，更好的选择是做一个包分发到开发团队的客户端。
当连接功能无法被泛化并需要与客户端应用程序进行更紧密集成时。


实例
下图显示了通过代理向远程服务发请求的应用程序。代理提供路由，断路和日志记录功能。它调用远程服务并返回给客户端应用程序：