云设计模式之: 代表模式

1. 缘由

基于云的弹性应用一般需要具有断路器、路由、计量和监控功能，但是对一些遗留应用来说，要更改它们使得具备这些特性却很困难，因为很多应用都没有人继续维护了，或者你没有权限修改源代码。如果非要加入这些特性的话怎么办呢？答案是，你可以使用代表模式(Ambassador pattern)。

2. 解决方案

代表模式可以解决这个问题，它的结构图大致如下：

上面图中的Application是主应用程序，也可以看成是遗留应用。Ambassador就是添加的代理，一般部署在独立的进程中，但是和遗留应用部署在同一台机器(Host)上。代理实现的功能主要有：请求重试、断路保护、计量监控、安全保护。如果有多个Application，也可以共享使用一个代理，这时候代理往往以Windows服务或 Linux 后台进程的形式部署。添加代理后，可以起到分担应用程序负载的一个作用，而且还可以将工作量分派出去，让其它团队来维护代理的更新和部署。

3. 需要考虑的问题

添加代理后，也会有一些问题存在。首先是性能问题，如果是应用性能极为敏感的应用，可能就不适合添加代理。还有就是，某些逻辑功能是否要加进代理需要认真考虑，比如重试逻辑，在请求非幂等的情况下可能会破坏原有程序的逻辑。此外，还有考虑代理的部署方式，以及多个应用是否共享一个代理还是每个应用一个代理。

4. 具体示例

上面说的都是理论，我们要看一下，添加代理后，具体的请求流程是怎样的，如下图所示：

上面的流程中，应用发起远程请求后，首先进入到代理进程，代理进程具有路由、断路、日志等功能，并将请求转发到远程服务，最后再将结果数据返回给应用程序。

微信扫码，进入【技术人成长】社群逛逛。