輪子除了開車，還能攤大餅——地址服務器的一個「另類」用法

     地址服務器是軟負載的一種實現方式。除了單純作軟負載，它還能作一點其它的事情。

背景

     當時咱們有兩套系統和對應的首頁，一套適用於PC端，一套適用於移動端。可是，總不免出現用戶進錯系統，例如使用PC版微信時打開了分享的連接。所以咱們討論了幾版方案。

第一版

     起初的解決方案是在PC端和移動端分別作判斷，若是用戶進錯了首頁，那麼將會重定向另外一套系統上。就像這樣：

    這個版本的問題很明顯：同一套代碼重複出如今了兩個地方。這個版本必定會在之後的擴展中，被「Don't Repeat Yourself」原則狠狠地打臉。

再版

    這個方案顯然有問題。所以咱們改了一版：咱們把判斷邏輯放到了一個獨立系統中。而後，PC端和移動端都先重定向到這個系統中，再重定向到對應的系統上。就像這樣：

    這個版本的方案確實遵照了「DRY」原則。可是，它仍然存在一些問題。最主要的是：是它作了兩次重定向。上圖中實線、虛線（按從左到右的時序發生），以從移動端訪問PC端的狀況，說明了這一問題。兩次客戶端的重定向下降了響應性能、下降了用戶體驗。而且這樣會將一個內部系統暴露了在公網上，增長了系統的安全性風險。

終版

    終版的方案借鑑了地址服務器的思路。PC或移動端在接到客戶端的請求後，經過內網的服務調用，從Judger上獲取到正確的首頁地址以後，再向客戶端返回。若是是本身的首頁，則直接返回；若是是另外一個系統的地址，則向客戶端發送重定向請求。以下圖所示：

    上圖重現了一次再版方案中的流程。與再版方案不一樣，PC端訪問Judger時是內網訪問，這樣就解決再版方案中的三個問題：性能、用戶體驗、安全風險。

後記

    當時討論方案的幾位同事，其實都知道地址服務是怎麼回事。可是爲何，在再版方案以後，你們討論了好久都沒有進展？
    咱們討論設計模式時也常提出一個問題：咱們已經把每一種設計模式都背得倒背如流了，爲何在實際工做中殊不知道怎麼應用？
    我以爲，學設計有三種思路。一種是學設計如何應用；第二種是學設計是什麼；第三種是學設計的核心思想。
    以設計模式來講，第一種思路是學哪一種設計模式適用於哪一種業務場景；第二種思路則是學這種模式與那種模式有什麼區別；第三種思路則是從設計模式中學習開閉、里氏替換等設計原則。
    過於專一「是什麼」的人，也許更適合作科學而非技術。作技術的思路是優先「怎麼用」、然後再「是什麼」。而知道「怎麼用」、「是什麼」、而且還知道「爲何」，才能把技術作精、作專、作高。