1、總DB的架構設計

1.1、優點：  

在軟體開發的初期，所有微服務的開發只需要進行一次資料庫的開發，大幅提高開發速度。單一資料庫的開發、維護都易於操作。

1.2、缺點：

開發時間耦合——例如，一個負責訂單服務的開發者需要和其他服務的開發者協調模式發生的變化，因為其他服務也要訪問同樣的表。這種耦合和額外的協調工作會拖延開發工作的進展。

執行時間耦合——由於所有的服務訪問同一資料庫，他們便可能會互相干擾。例如，如果長時間執行的客戶服務事務鎖定了訂單表，那麼訂單服務就會被阻塞。

系統容錯性下降——由於只有一個數據庫，整個系統的所有資料互動都要通過這個資料庫進行，一旦某個微服務發生錯誤，資料庫發生了阻塞，那麼其他沒有錯誤的微服務都將因為資料庫阻塞從而無法正常執行。

單一資料庫可能滿足不了所有服務的資料儲存和訪問需求。

穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉。

擴充套件性不夠：無法滿足高併發情況下的業務需求。

2、分DB的架構設計

2.1、優點：  

資料庫服務簡單，每個專用資料庫只關注一個業務功能。

每個微服務可由不同團隊開發。每個微服務配套一個數據庫，因此可由不同的開發團隊進行開發，可大大提升開發效率。

資料庫可根據不同的微服務型別進行選擇，例如需要大型的資料管理時使用oracle資料庫，若只管理少許資料時可使用Mysql資料庫，甚至是SQLlite資料庫，根據需求去選擇資料庫。

各個服務之間相互獨立，若某一個或者幾個服務發生阻塞時，不會對其他的服務造成影響，在一定程度上保證系統全域性大部分功能的正常執行。

2.2、缺點：  

運維開銷

更多的服務也就意味著更多的運維，產品團隊需要保證所有的相關服務都有完善的監控等基礎設施，傳統的架構開發者只需要保證一個應用正常執行，而現在卻需要保證幾十甚至上百道工序高效運轉，這是一個艱鉅的任務。

DevOps要求

使用微服務架構後，開發團隊需要保證一個Tomcat叢集可用，保證一個數據庫可用，這就意味著團隊需要高品質的DevOps和自動化技術。而現在，這樣的全棧式人才很少。對於一個完整的系統有若干個微服務對應的資料庫，會大量需求這類人員。

隱式介面

服務和服務之間通過介面來“聯絡”，當某一個服務更改介面格式時，可能涉及到此介面的所有服務都需要做調整。

重複勞動

在很多服務中可能都會使用到同一個功能，而這一功能點沒有足夠大到提供一個服務的程度，這個時候可能不同的服務團隊都會單獨開發這一功能，重複的業務邏輯，這違背了良好的軟體工程中的很多原則。

分散式系統的複雜性

微服務通過REST API或訊息來將不同的服務聯絡起來，這在之前可能只是一個簡單的遠端過程呼叫。分散式系統也就意味著開發者需要考慮網路延遲、容錯、訊息序列化、不可靠的網路、非同步、版本控制、負載等，而面對如此多的微服務都需要分散式時，整個產品需要有一整套完整的機制來保證各個服務可以正常運轉。

事務、非同步、測試面臨挑戰

跨程序之間的事務、大量的非同步處理、多個微服務之間的整體測試都需要有一整套的解決方案，而現在看起來，這些技術並沒有成熟。

3、通用DB與分DB結合的結構設計

3.1、優點：  

這種結構將上文中提到的兩種方法進行結合，對於比較基礎和通用的資料將他們放入通用資料庫中，可以減少使用這些基礎資料時的重複開發，並且在後期的運維開銷也會相應降低。

3.2、缺點：  

共用一個數據庫的微服務之間會具備上文提到的單一DB架構設計的缺點。

分DB的微服務之間，會具有分DB架構設計的缺點。

總結： 單一DB與總DB的優缺點與微服務的屬性和數量息息相關，因此不能簡單地斷定哪個方法是比較出色的，應該與實際開發相結合。

4、通用DB加上負載均衡與分DB結合的結構設計

4.1、優點：

這是對多個微服務共用一個數據庫的改良，當某個服務發生錯誤引起DB阻塞時，其他的服務可以通過後備資料庫進行正常執行。

4.2、缺點：

後備資料庫與通用資料庫之間的資料一致性需要保證，這將會消耗一定的硬體資源。

原文：https://blog.csdn.net/qq_31147397/article/details/81034037