這個問題是我在知乎上看到的，答案并不是一邊倒，還是存在爭議性的。

其中，一些持反方觀點同學(xué)的理由如下：

（1）從硬件成本和維護(hù)成本上看，反而應(yīng)該多個微服務(wù)盡可能地共用中間件和數(shù)據(jù)庫。

（2）微服務(wù)的獨立數(shù)據(jù)庫是指邏輯獨立，而不是物理獨立，在物理層面上是可以共用數(shù)據(jù)庫的。

btw：有點兒像《非誠勿擾》中葛優(yōu)對舒淇說的話：“那你能允許我心在你這，身體上開點兒小差嗎”？

（3）你把數(shù)據(jù)庫也看做一個微服務(wù)就好理解了，微服務(wù)之間本身就是多對多的關(guān)系，公用有何不可呢？

拋出我的觀點吧，我完全支持每個微服務(wù)都要有自己獨立的數(shù)據(jù)庫，但每個數(shù)據(jù)庫是否使用獨立的服務(wù)器，這個需要視業(yè)務(wù)情況而定。

具體原因請見下圖：

圖片

系統(tǒng)可用性

說說我當(dāng)年的情況吧，當(dāng)時我在一個在線教育公司，該公司早期的系統(tǒng)是一個單體架構(gòu)，一個大的后端工程，并對應(yīng)一個大的數(shù)據(jù)庫。

后來人越招越多，業(yè)務(wù)也越來越復(fù)雜，幾十人的研發(fā)團(tuán)隊共同在一個大的單體服務(wù)中進(jìn)行開發(fā)，這是明顯不現(xiàn)實的。

于是，研發(fā)團(tuán)隊便按照組織結(jié)構(gòu)進(jìn)行服務(wù)拆分，將那個大的單體服務(wù)拆分為學(xué)生端服務(wù)、教師端服務(wù)、管理端服務(wù)和銷售端服務(wù)。

圖片

隨后，我們的學(xué)生端服務(wù)又按照業(yè)務(wù)領(lǐng)域，拆分出來了學(xué)生課表、積分商城和學(xué)生運營活動服務(wù)。

其中，學(xué)生課表服務(wù)的重要等級是P0（最重要的），因為學(xué)生是以課表為入口進(jìn)入教室上課的，也就是說，如果課表服務(wù)掛了就會導(dǎo)致無法上課，會給公司帶來重大經(jīng)濟(jì)損失。

積分商城服務(wù)，是學(xué)生通過積分兌換學(xué)習(xí)用品的，如果服務(wù)掛了會影響用戶體驗，但不會造成經(jīng)濟(jì)損失，因此重要等級為P1。

而運營活動服務(wù)的主要功能為，公司的運營人員會創(chuàng)建一些活動來增加學(xué)生在平臺上的活躍度，比如：學(xué)生將自己創(chuàng)作的作品，發(fā)到朋友圈中收集點贊，被點贊最多的學(xué)生獲得小禮品，等等。

但當(dāng)時的情況是，學(xué)生課表、積分商城和學(xué)生運營活動這三個服務(wù)拆出來了，還是共用了一個學(xué)生端的數(shù)據(jù)庫。

有一天晚上，正好是學(xué)生上課的高峰期，忽然收到一通報警，學(xué)生端數(shù)據(jù)庫的負(fù)載竟然達(dá)到了200多，CPU使用率也被干到了100%。

緊接著，公司的大群中就有好幾個業(yè)務(wù)同事發(fā)消息說，學(xué)生投訴說課表看不到了，不能進(jìn)入教室上課了。

我們聽了之后，趕緊登錄監(jiān)控系統(tǒng)去查看學(xué)生課表服務(wù)的相關(guān)接口，發(fā)現(xiàn)由于不顯示課表學(xué)生反復(fù)刷新頁面的原因，接口的QPS確實比正常情況下高了好幾倍，但都被Sentinel限流掉了，不應(yīng)該造成影響才對。

正在一籌莫展之際，我忽然發(fā)現(xiàn)在監(jiān)控系統(tǒng)上，學(xué)生運營活動服務(wù)的接口QPS和TPS同樣高得離譜，比平時高十幾倍，且彪高的起始時間要比學(xué)生課表接口早一兩分鐘。

這就證明了，很大可能是學(xué)生運營活動服務(wù)的流量彪高，且學(xué)生運營活動服務(wù)上的接口沒有做限流保護(hù)，造成了服務(wù)共用的學(xué)生端數(shù)據(jù)庫扛不住了，從而影響了學(xué)生課表服務(wù)。

圖片

于是，我們趕緊啟動降級機(jī)制，關(guān)閉了所有的學(xué)生運營活動服務(wù)的接口。沒過一會兒，學(xué)生課表可以正常訪問了。

接下來，我們和DBA連夜把學(xué)生課表服務(wù)所對應(yīng)的數(shù)據(jù)表單獨拆分出來，遷移到一個新的數(shù)據(jù)庫服務(wù)器上進(jìn)行獨享。

嗯，重要等級高的微服務(wù)不但要有自己獨立的數(shù)據(jù)庫，且必須是獨立的數(shù)據(jù)庫服務(wù)器，通過鏈路隔離的方式提升系統(tǒng)可用性。

當(dāng)然，一些重要等級不高的服務(wù)獨立數(shù)據(jù)庫即可，并不需要獨立數(shù)據(jù)庫服務(wù)器，這樣可以節(jié)省硬件成本。

架構(gòu)貫徹性

我們都知道，微服務(wù)架構(gòu)之間是通過RPC調(diào)用來進(jìn)行業(yè)務(wù)串聯(lián)的。

以常見的電商場景舉例，需要給用戶展示他所購買的訂單列表，此時訂單中心會調(diào)用商品中心的API獲取商品數(shù)據(jù)，然后再跟訂單數(shù)據(jù)進(jìn)行merge，返回給前端用戶。

如果此時商品中心和訂單中心所對應(yīng)的數(shù)據(jù)表放在一個數(shù)據(jù)庫中，可以預(yù)見的情況就是，研發(fā)人員會把訂單表和商品表進(jìn)行多表關(guān)聯(lián)的方式來代替RPC調(diào)用+ 數(shù)據(jù)merge，因為這樣做非常省事。

如下圖所示：

而一旦破了這個口子，就會形成“破窗效應(yīng)”，系統(tǒng)架構(gòu)就變成分布式單體架構(gòu)。

有人說，可以靠口頭約束的方式來規(guī)避這種情況，我并不認(rèn)同。

想象一種場景，如果一個同學(xué)趕項目工期，半夜12點還在那挑燈夜戰(zhàn)呢。此時，如果有一種方式讓他快速寫完代碼回家睡覺，他會毫不動心一絲不茍地“按照規(guī)律辦事”？

研發(fā)效率

微服務(wù)獨立數(shù)據(jù)庫的另一個好處就是，讀寫入口收斂，這樣是可以提升研發(fā)效率的。

舉個例子，如果我們把商品表進(jìn)行垂直拆分，拆分成商品表 + 商品詳情表，如果按照標(biāo)準(zhǔn)的獨立數(shù)據(jù)庫方式，只需要商品中心來進(jìn)行對應(yīng)的代碼變更就可以了，這對依賴商品中心的其他服務(wù)來講是透明的。

而非獨立庫模式就比較蛋疼了，每個去直接查詢商品表的服務(wù)都需要改一遍。

如下圖所示：

圖片

上述例子屬于讀入口收斂的范疇，而寫入口不收斂，在多個服務(wù)中對一張數(shù)據(jù)表進(jìn)行寫入的話，則帶來的問題同樣不少。

問題包括：

（1）表結(jié)構(gòu)變更問題，如果增加一個非空字段，那么所有寫入口的代碼全部需要變更，且這種“散彈式”修改非常容易遺漏。

（2）問題排查難，一旦發(fā)現(xiàn)寫入了問題數(shù)據(jù)，那各個寫入口全部需要進(jìn)行排查，工作量大且復(fù)雜。

除了讀寫入口收斂問題，再有就是，如果形成了上文中所說的“分布式單體架構(gòu)”，那接下來再想進(jìn)行優(yōu)化改善的話，將會是一件工作量極大的事情，所以不如一次做好。

結(jié)語

綜上所述，我認(rèn)為如果選擇了微服務(wù)架構(gòu)，那每個微服務(wù)獨立數(shù)據(jù)庫完全是個必選項，獨立數(shù)據(jù)庫服務(wù)器則是個可選項，需要兼顧可用性和硬件成本。