單一資料庫拆分成幾十個資料庫的意義

我經歷過很多專案，從前就一個資料庫支援上萬併發，儲存上百億行資料的級別是非常容易得。現如今的玩法不是這樣了，而是將一臺資料庫能解決的事情，拆分成幾十個資料庫。有一次我的群裡有人說有個專案將一個Oracle拆了100個MySQL，每個MySQL一主兩從。也就是2比300的這樣的比例。(因為Oracle也是主從，算兩個吧)。這技術難度和成本上都陡增。這和最近幾年流行的微服務和中臺有一定的關係。以下之言代表我個人的愚見。如有冒犯請見諒。

我和多個業內頂級大師的認同一樣：架構師 喜歡 重複 造輪子。我特意分開寫，這樣突出一下 喜歡 和 重複，造輪子也就算了，有的時候為了生活被迫。但是如果是主觀就不對了。而且還是重複。為此有些經驗豐富的人不僅感慨“一臺一體機能搞定的事，有些人強行拆成幾百臺x86，不知道圖的啥，收益是啥，投入產出比高不高?”答案是一定是比原來成本高的。不僅僅是硬體，還有人工。本來可能開發人員30人，現在每個300人根本搞不下來。接下來運維也要加人。由於資料庫一堆，沒法出報表了，來Hadoop做大資料吧。別人都有，我們也要有。有了Hadoop資料要加工，做主題，再來30-50人。從促進就業的角度是積極的。不過如今全國都是降薪裁員不知道還有多少企業還是能這樣搞下去?那回答剛才的提問，這是在圖什麼?

餘竊以為：想想天龍八部中慕容博為什麼要鼓動宋遼開戰，就明白了。這是一個意思。原文如下：慕容博道：“不錯，其時我慕容氏建一支義旗，兵發山東，為大遼呼應，同時吐蕃、西夏、大理三國一時並起，我們五國瓜分了大宋，亦非難事。你看不亂我怎麼有機會? 如果一個系統一個資料庫再加幾十個tomcat。10個人搞定了。那麼我還怎麼凸顯我的能力?根本沒機會。迴歸到工作中來，我經歷過三個典型的縮容架構。給大家說說。

案例1：某公司要做一個登入系統，用到了Oracle、MongoDB、Redis、Memcache、Cassandra。我開始不明白這是為什麼?答：說要承載每秒1000個的使用者登入需求，怕扛不住。我一聽就笑了。如果懂資料庫的就知道任何一個關係型資料庫，如果使用者登入這種資訊採用關係型資料做的話，就是一個點查的場景，建立好索引。每秒幾萬都不是問題。為什麼1000都擔心?其實質就是全表查呀。我問到如果你擔心登入?那麼登入以後得瀏覽和下單等動作任何一個都比登入驗證使用者密碼的動作要複雜，你不擔心嗎?而且據我瞭解，這個方案的架構是把以上5個序列的，不知道那個架構師是不是培訓機構出來的。估計是想一層層減緩衝擊，但是不懂資料庫就這樣設計了。結果任何一個環節的問題都導致整個不能用。在我的建議下，去掉了MongoDB、Memcache、Cassandra。其實Redis也可以不用。但是領導說留下吧。再去掉實在是太丟臉了。一個Oracle能每秒1000次嗎? 我搭建了模型給他演示了一下，每秒3萬。領導尷尬的說，嗯，夠用就行。Redis還是留著吧。我知道如果這個再去掉，就實在太打臉了。為此係統穩定性急劇上升。該公司還省了一筆錢。

案例2：某公司有幾十個業務系統，希望使用者系統打通。結果各個系統之間要對使用者的註冊、登出、變更做同步。接下來就是開發人員喜歡的介面了。大量的介面。結果是不是丟了，就是慢了。同步慢導致這裡能登入那裡不能立即生效。丟了導致過了一天，都登入不上去。為此運營和運維壓力都大。我瞭解了以後說你們幾十個系統都是一個資料庫例項，就是不同的schema，甚至有的還是一個schema。為什麼要做介面?最後一個開發組長受不了了。搞毛線啊，直接訪問吧。不做介面了。最後就直接走表與表之前的訪問，所有系統都訪問一個使用者會員表。效果是，系統穩定性急劇上升。資料永遠一致，而且訪問效率提升1000倍以上。其實介面這個是針對外部是不得不做的，為了是保護資料。比如支付寶對銀行，這是不同的企業。但是一個企業內部，其實沒有必要。

案例3：某公司有三個業務系統。分了3個開發團隊，分別用了Oracle、MySQL和SQLServer資料。結果流程是緊耦合的。一個公司業務的必然是耦合啊。結果是一個需求下來，三個開發團隊都要做，之間還有介面，每個團隊都說人力不足。結果最後該公司領導受不了了。三個資料庫合併。結果是穩定性急劇上升。原來說人力不夠的，現在夠了。因為同樣事情只做一次了，介面統統沒有了。

但是如果都是這樣做，天下太平了，那慕容博沒機會了。你身邊有這樣的嗎?