轮子除了开车，还能摊大饼——地址服务器的一个“另类”用法

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

背景

     当时咱们有两套系统和对应的首页，一套适用于PC端，一套适用于移动端。可是，总不免出现用户进错系统，例如使用PC版微信时打开了分享的连接。所以咱们讨论了几版方案。

第一版

     起初的解决方案是在PC端和移动端分别作判断，若是用户进错了首页，那么将会重定向另外一套系统上。就像这样：

    这个版本的问题很明显：同一套代码重复出如今了两个地方。这个版本必定会在之后的扩展中，被“Don't Repeat Yourself”原则狠狠地打脸。

再版

    这个方案显然有问题。所以咱们改了一版：咱们把判断逻辑放到了一个独立系统中。而后，PC端和移动端都先重定向到这个系统中，再重定向到对应的系统上。就像这样：

    这个版本的方案确实遵照了“DRY”原则。可是，它仍然存在一些问题。最主要的是：是它作了两次重定向。上图中实线、虚线（按从左到右的时序发生），以从移动端访问PC端的状况，说明了这一问题。两次客户端的重定向下降了响应性能、下降了用户体验。而且这样会将一个内部系统暴露了在公网上，增长了系统的安全性风险。

终版

    终版的方案借鉴了地址服务器的思路。PC或移动端在接到客户端的请求后，经过内网的服务调用，从Judger上获取到正确的首页地址以后，再向客户端返回。若是是本身的首页，则直接返回；若是是另外一个系统的地址，则向客户端发送重定向请求。以下图所示：

    上图重现了一次再版方案中的流程。与再版方案不一样，PC端访问Judger时是内网访问，这样就解决再版方案中的三个问题：性能、用户体验、安全风险。

后记

    当时讨论方案的几位同事，其实都知道地址服务是怎么回事。可是为何，在再版方案以后，你们讨论了好久都没有进展？
    咱们讨论设计模式时也常提出一个问题：咱们已经把每一种设计模式都背得倒背如流了，为何在实际工做中殊不知道怎么应用？
    我以为，学设计有三种思路。一种是学设计如何应用；第二种是学设计是什么；第三种是学设计的核心思想。
    以设计模式来讲，第一种思路是学哪一种设计模式适用于哪一种业务场景；第二种思路则是学这种模式与那种模式有什么区别；第三种思路则是从设计模式中学习开闭、里氏替换等设计原则。
    过于专一“是什么”的人，也许更适合作科学而非技术。作技术的思路是优先“怎么用”、然后再“是什么”。而知道“怎么用”、“是什么”、而且还知道“为何”，才能把技术作精、作专、作高。