地址服务器是软负载的一种实现方式。除了单纯做软负载,它还能做一点其它的事情。

背景

     当时我们有两套系统和对应的首页,一套适用于PC端,一套适用于移动端。但是,总难免出现用户进错系统,例如使用PC版微信时打开了分享的链接。因此我们讨论了几版方案。

初版

     起初的解决方案是在PC端和移动端分别做判断,如果用户进错了首页,那么将会重定向另一套系统上。就像这样:
p_w_picpath
    这个版本的问题很明显:同一套代码重复出现在了两个地方。这个版本一定会在以后的扩展中,被“Don't Repeat Yourself”原则狠狠地打脸。

再版

    这个方案显然有问题。因此我们改了一版:我们把判断逻辑放到了一个独立系统中。然后,PC端和移动端都先重定向到这个系统中,再重定向到对应的系统上。就像这样:p_w_picpath

    这个版本的方案确实遵守了“DRY”原则。但是,它仍然存在一些问题。最主要的是:是它做了两次重定向。上图中实线、虚线(按从左到右的时序发生),以从移动端访问PC端的情况,说明了这一问题。两次客户端的重定向降低了响应性能、降低了用户体验。并且这样会将一个内部系统暴露了在公网上,增加了系统的安全性风险。

终版

    终版的方案借鉴了地址服务器的思路。PC或移动端在接到客户端的请求后,通过内网的服务调用,从Judger上获取到正确的首页地址之后,再向客户端返回。如果是自己的首页,则直接返回;如果是另一个系统的地址,则向客户端发送重定向请求。如下图所示:
p_w_picpath
    上图重现了一次再版方案中的流程。与再版方案不同,PC端访问Judger时是内网访问,这样就解决再版方案中的三个问题:性能、用户体验、安全风险。

后记

    当时讨论方案的几位同事,其实都知道地址服务是怎么回事。但是为什么,在再版方案之后,大家讨论了很久都没有进展?
    我们讨论设计模式时也常提出一个问题:我们已经把每一种设计模式都背得滚瓜烂熟了,为什么在实际工作中却不知道怎么应用?
    我觉得,学设计有三种思路。一种是学设计如何应用;第二种是学设计是什么;第三种是学设计的核心思想。
    以设计模式来说,第一种思路是学哪种设计模式适用于哪种业务场景;第二种思路则是学这种模式与那种模式有什么区别;第三种思路则是从设计模式中学习开闭、里氏替换等设计原则。
    过于专注“是什么”的人,也许更适合做科学而非技术。做技术的思路是优先“怎么用”、而后再“是什么”。而知道“怎么用”、“是什么”、并且还知道“为什么”,才能把技术做精、做专、做高。