云设计模式之: 代表模式

1. 缘由

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

2. 解决方案

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

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

3. 需要考虑的问题

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

4. 具体示例

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

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

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