單機是最好的架構之一集中部署

自己原文公眾號： https://mp.weixin.qq.com/s/dwgB4pwqhahTdRan_sKQWQ

我以前一直說單機是最好的架構。這裡的單機是指的一套資料庫比如PG的叢集，oracle的RAC、MySQL的MGR。我反對分庫分表，不管別人怎麼說我始終堅定這麼認為。今天開始一個系列來說明。後續我打算有資料同步篇章、分庫篇章、融合篇章等等等等

      多年前在一家公司有這麼一個場景。一個入口網站下屬N多子平臺。希望在任何一家平臺註冊，在所有平臺可以登入。

     這裡有幾種方案。

     方案1，各家獨立自己會員資料庫，你們想想一下就是N個平臺的資料庫會員要進行註冊同步，登出同步，狀態同步等等。這個最終的問題就是總是有資料不同步，不是這裡少了，就是那裡少了。因為一個要對N-1個傳送和接收。而且由於開發水平有限介面效率又低。其實介面底層幾乎都是SQL，本來是透明的，包裝了一下穿了一個馬甲大家不知道里面是什麼。

      方案2，建立一個資料庫大家都到一個地方統一去。當時N個平臺就是一個資料庫上的N個schema。也就是說授權一下select就行。這個方案獲得了所有開發的贊同。理由是所有介面都不用做了，耶。工作量減輕。而且效率比之前的介面高了至少100倍。因為大家都用一個一模一樣的SQL，不會因為不同團隊水平不同效率不同。

     最重要的之前很多問題都沒有了，使用者也不抱怨了。以前總說技術為業務服務的。業務哪裡懂技術，用簡單的解決了問題。不必要高大上的，比如微服務或者中臺，有的時候可能還解決不了問題，結果製造了問題。關鍵是中臺一直是一道送命題。

     一次是偶然，兩次是必然。又有一次一個領導下屬N個團隊，各個團隊相互協作。因為每個團隊都是其他團隊的上下游。每個團隊都是流程一個環節。說到這裡大家可能猜到了。對，每個環節一個獨立的資料庫。重點還是都是異構資料庫。一個流程所有團隊都要參與才能走得通，每個異構資料庫要走通必然要經過介面啊。一個需求變更，N個團隊一起動。而且每個團隊都說人手不足。

      最後不得已所有異構資料庫都變成同構，而且合在一個資料庫例項裡面。又回到上面說的：所有介面都不用做了，耶。工作量減輕。而且效率比之前的介面高了至少100倍。流程也短了，甚至有些表都合了。資料和功能都整個了，然後開發人員也整合。人手也不至於不夠了。一舉多得。看到這裡其實發現了，很多不應該分開的資料庫，是為了分而分，結果最好對自己形成了反噬。

      其實一個需求來了，把控需求的人算算開發人員薪酬X幾個月然後這個成本和需求帶來的價值比比，就知道有些需求不上才是最好的。