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

背景

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

初版

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

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

再版

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

这个版本的方案确实遵守了“DRY”原则。但是，它仍然存在一些问题。 最主要的是：是它做了两次重定向。上图中实线、虚线（按从左到右的时序发生），以从移动端访问PC端的情况，说明了这一问题。

两次客户端的重定向降低了响应性能、降低了用户体验。

并且这样会将一个内部系统暴露了在公网上，增加了系统的安全性风险。

终版

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

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

后记

当时讨论方案的几位同事，其实都知道地址服务是怎么回事。但是为什么，在再版方案之后，大家讨论了很久都没有进展？

我们讨论设计模式时也常提出一个问题：我们已经把每一种设计模式都背得滚瓜烂熟了，为什么在实际工作中却不知道怎么应用？

我觉得，学设计有三种思路。一种是学设计如何应用；第二种是学设计是什么；第三种是学设计的核心思想。

以设计模式来说，第一种思路是学哪种设计模式适用于哪种业务场景；第二种思路则是学这种模式与那种模式有什么区别；第三种思路则是从设计模式中学习开闭、里氏替换等设计原则。

过于专注“是什么”的人，也许更适合做科学而非技术。做技术的思路是优先“怎么用”、而后再“是什么”。而知道“怎么用”、“是什么”、并且还知道“为什么”，才能把技术做精、做专、做高。