面試奪命三問之《爲何微服務不能共享數據庫？》

引子：今天面試一位候選人，候選人描述他作的項目，使用了微服務化的設計理念，業務差分紅多個微服務，可是服務之間共享一個數據庫，因而就有了這樣的一個問題探討。

所謂多個服務共享數據庫，其實有兩種類型：共享數據庫結構和共享數據庫實例，下面分別進行探討。

關注公衆號：Java架構師聯盟，每日更新技術好文

共享數據庫結構——全部的表，在一個數據庫中。

共享數據庫結構

在實際的工做中，不少同窗對這種模型比較推崇，理由就是寫代碼簡單，能夠用數據庫的鏈接查詢，完成複雜的業務邏輯。由企業級應用開發經驗的同窗，對此模型的推崇更甚，這是爲何呢？我嘗試分析企業應用和互聯網應用的不一樣特色，進行解答。

企業應用的特色是：業務複雜，併發小，研發投入有限。在這種狀況下，就要求以較少的代價完成業務功能，經過複雜SQL作業務操做是不錯的選擇。數據庫雖然執行了複雜的查詢，由於併發小，並無太大的壓力。企業級應用的開發者，傾向於寫複雜的查詢，不太用考慮複雜的應用架構和程序運行效率。

互聯網應用的特色是：大併發，業務複雜，通常研發投入較大。一方面，數據庫若是是性能瓶頸，擴容機制複雜，雖然有一些擴容方案，例如讀寫分離、緩存、分表分庫等等，都須要程序配合，同時很難作到熱擴容。另外一方面，執行效率和併發能力成反比，只有儘量的縮短單操做的執行時間，才能作大大併發。因此，互聯網應用的開發者，傾向於寫簡單的查詢，經過應用架構優化和程序優化，提高應用的併發能力。

架構的不少理念，沒有對錯，只有合適不合適。對於小規模的企業應用開發，採用這種模式是合適的。可是對於比較大規模的應用和互聯網應用就不合適了，主要的理由以下：

1. 服務邊界不清晰，有些代碼寫在服務A能夠，寫在服務B也能夠，總之是一種很混亂的狀態。
2. 難以維護。因爲服務邊界不清晰，代碼混亂，代碼的維護成爲難題。
3. 難以優化。主要業務在SQL裏，不能經過優化代碼提高性能。SQL的優化很是複雜，大量的關聯查詢，牽一髮而動全身。
4. 性能瓶頸。數據庫是業務的性能瓶頸，不容易擴容。

共享數據庫實例——表按照業務分紅多個庫，這些庫存儲在一臺實例上

共享數據庫實例

經過上面的分析，對設計作了優化，服務之間沒有了數據庫表依賴，也不寫複雜的查詢。爲了節省成本，把這些數據庫建在同一個實例上，就進化成了如今這種模式。探討這個模式的不足，就要聊聊雪崩效應。

假設訂單服務有一個複雜的查詢，正常查詢須要200ms，有一天由於某個錯誤，致使頻繁查詢，數據庫的CUP被佔用到100%。這時候數據庫的查詢都會變慢，100ms返回的查詢，可能耗時超過10秒，甚至更誇張。用戶服務和庫存服務，很快就不能對外提供服務了。這種現象就是雪崩效應，共享的資源，一旦被耗盡，就會傳播給其餘共享方。共享數據庫實例的風險很高，這種風險不是增長數據庫的實例配置就能解決的。既然採用了服務化的設計理念，就要考慮資源隔離。

總結：我當時問他的問題是共享有什麼缺點嗎？候選人只是從設計的角度進行了解答，沒有從性能、併發能力方面解答，也沒有提到雪崩效應。也就很明顯的看出，候選人大規模、大併發應用的設計能力是有待提升的。