引子：今天面試一位候選人，候選人描述他做的專案，使用了微服務化的設計理念，業務差分成多個微服務，但是服務之間共享一個資料庫，于是就有了這樣的一個問題探討，
所謂多個服務共享資料庫，其實有兩種型別：共享資料庫結構和共享資料庫實體，下面分別進行探討，
關注公眾號：Java架構師聯盟，每日更新技術好文
共享資料庫結構——所有的表，在一個資料庫中，
共享資料庫結構
在實際的作業中，很多同學對這種模型比較推崇，理由就是寫代碼簡單，可以用資料庫的連接查詢，完成復雜的業務邏輯，由企業級應用開發經驗的同學，對此模型的推崇更甚，這是為什么呢？我嘗試分析企業應用和互聯網應用的不同特點，進行解答，
企業應用的特點是：業務復雜，并發小，研發投入有限，在這種情況下，就要求以較少的代價完成業務功能，通過復雜SQL做業務操作是不錯的選擇，資料庫雖然執行了復雜的查詢，因為并發小，并沒有太大的壓力，企業級應用的開發者，傾向于寫復雜的查詢，不太用考慮復雜的應用架構和程式運行效率，
互聯網應用的特點是：大并發，業務復雜，一般研發投入較大，一方面，資料庫如果是性能瓶頸，擴容機制復雜，雖然有一些擴容方案，例如讀寫分離、快取、分表分庫等等，都需要程式配合，同時很難做到熱擴容，另一方面，執行效率和并發能力成反比，只有盡可能的縮短單操作的執行時間，才能做大大并發，所以，互聯網應用的開發者，傾向于寫簡單的查詢，通過應用架構優化和程式優化，提升應用的并發能力，
架構的很多理念，沒有對錯，只有合適不合適，對于小規模的企業應用開發，采用這種模式是合適的，但是對于比較大規模的應用和互聯網應用就不合適了，主要的理由如下：
- 服務邊界不清晰，有些代碼寫在服務A可以，寫在服務B也可以，總之是一種很混亂的狀態，
- 難以維護，由于服務邊界不清晰，代碼混亂，代碼的維護成為難題，
- 難以優化，主要業務在SQL里，不能通過優化代碼提升性能，SQL的優化非常復雜，大量的關聯查詢，牽一發而動全身，
- 性能瓶頸，資料庫是業務的性能瓶頸，不容易擴容，
共享資料庫實體——表按照業務分成多個庫，這些庫存盤在一臺實體上
共享資料庫實體
通過上面的分析，對設計做了優化，服務之間沒有了資料庫表依賴，也不寫復雜的查詢，為了節省成本，把這些資料庫建在同一個實體上，就進化成了現在這種模式，探討這個模式的不足，就要聊聊雪崩效應，
假設訂單服務有一個復雜的查詢，正常查詢需要200ms，有一天因為某個錯誤，導致頻繁查詢，資料庫的CUP被占用到100%，這時候資料庫的查詢都會變慢，100ms回傳的查詢，可能耗時超過10秒，甚至更夸張，用戶服務和庫存服務，很快就不能對外提供服務了，這種現象就是雪崩效應，共享的資源，一旦被耗盡，就會傳播給其他共享方，共享資料庫實體的風險很高，這種風險不是增加資料庫的實體配置就能解決的，既然采用了服務化的設計理念，就要考慮資源隔離，
總結：我當時問他的問題是共享有什么缺點嗎？候選人只是從設計的角度進行了解答，沒有從性能、并發能力方面解答，也沒有提到雪崩效應，也就很明顯的看出，候選人大規模、大并發應用的設計能力是有待提高的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/238870.html
標籤：Java
上一篇：精盡Spring MVC原始碼分析 - RequestToViewNameTranslator 組件
下一篇：mybatis 自定義分頁