[[430234]]

實施微服務架構，我們一直在遵循一個實踐原則：每個微服務要有自己獨立的數據庫，避免數據庫層面的耦合。這種理所當然感覺好像不需要多加思考，就是應該這樣做；

圖片來源：James Lewis 和 Martin Fowler 的文章《Microservices》

　　那么到底為什么每個微服務都需要獨立的數據庫，數據放在一個數據庫有問題嗎？要回答這個問題，我們還是要回歸到微服務的定義 （參見 James Lewis 和 Martin Fowler 的文章《Microservices》，地址：
https://martinfowler.com/articles/microservices.html）：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

　　這個定義中指明了微服務架構風格的典型特征，如：技術異構（每個服務可以采用不同的編程語言或不同的數據存儲技術）、獨立部署和圍繞業務能力構建，等等。我們可以從微服務架構風格的幾個典型特征入手，看看獨立數據庫可以帶來哪些好處，或者共享數據庫會帶來哪些問題。

微服務支持技術異構

　　為了更好的解決特殊場景的問題，微服務架構并不提倡使用適合所有場景的標準化技術，而是針對每個服務的特點，選擇更合適的技術。

　　這個技術不僅包括編程語言、技術框架，當然也包括數據存儲技術；紐曼(Sam Newman)在《微服務設計》一書中舉了一個例子很好的解釋了數據存儲技術異構帶來的好處：

　　對于社交網絡來說，圖數據庫能夠更好的處理用戶之間的交互操作，但對于用戶發布的帖子而言，文檔數據庫可能是一個更好的選擇

圖片來源：《微服務設計》第 1 章圖1-1

　　技術異構很自然讓我們為每個微服務選擇了獨立的數據庫，但杠精附體的同學可能緊接著會問：那如果服務不需要采用異構的技術，那是不是就可以使用同一個數據庫了呢，比如都使用 MySQL 數據庫？

微服務是自治的

　　微服務是小而自治的，自治性的一個非常重要的特性就是獨立部署，一個服務的修改和部署不應該對其他服務產生影響，但如果多個服務共享數據庫，在數據庫層的耦合讓不確定性變大，一個服務對數據庫結構的變更很有可能影響其他服務，即破壞了自治性。

　　自治性的好處體現在整個系統的彈性上，當一個服務發生故障時，不會造成整個系統的不可用。然而，如果多個服務共享數據庫，數據庫的異常會導致多個服務同時故障，也就大大增加了整個系統不可用的概率。

　　自治性還體現在服務的可擴展性上，不同的服務因業務不同其需要滿足的性能和并發量要求也不同。當請求量增加時只需要對部分服務進行擴展，而不是所有服務；同樣當數據庫性能無法滿足需求時，只需要對部分服務的數據庫進行擴容升級，而如果多個服務共享數據庫，擴容升級的影響就會作用到多個服務，一方面破壞了服務的自治性，另一方面當其他服務對數據庫沒有那么高要求時，資源是浪費的。

　　繼續杠精附體，那是不是可以把并發量和性能要求相近的業務合并為一個服務，而共享同一個數據庫呢？

微服務是圍繞業務能力構建的

　　這個問題其實是微服務架構實施落地的一個非常熱點問題：如何劃分微服務？

　　劃分微服務要遵循高內聚、低耦合這個原則的，這也是微服務架構優勢所在；《領域驅動設計》引入了限界上下文（bounded context）的概念，通過對業務的梳理找到不同業務上下文之間的邊界，幫助我們找到了劃分微服務的方法，這里的重點在業務邊界。James Lewis 和 Martin Fowler 在微服務的定義中也強調微服務是構建在業務能力之上的，可見微服務的小而自治是建立在獨立的業務能力基礎之上的。

　　因此，簡單的將并發量和性能要求相近的業務合并到一個服務中，無法達到微服務期望的效果，也就沒法獲得微服務所具有的好處。一方面不同的業務對數據庫的要求除了要考慮并發量和性能，還應該包括數據量的大小、讀寫的比例、實時性要求等等，共享數據庫的方式一般情況下也很難滿足不同業務服務對這些指標的要求，將所有服務的數據都存放在一個數據庫中本身也是一種非常大的挑戰。另一方面用動態的視角看這個問題，業務是發展的，隨著市場的不斷變化，不同的業務隨時間而演進出來的需求可能是完全不同的，對數據庫的需求也會有所不同，共享數據庫的方式很可能變成瓶頸限制業務的發展。

微服務架構要不斷演進

[[430237]]

微服務架構風格還有一個非常重要的特征，就是支持架構的演進；不論是互聯網企業，還是在數字化轉型過程中的傳統企業，市場的變化和不確定性是不可避免的，當接到一個新的需求，如果需要用新的技術手段來解決，微服務架構就體現出了獨特的優勢，在不對其他服務產生影響的情況下，可以隨意變更一個服務內部的技術框架或數據存儲技術，共享數據庫明顯做不到這一點。

最后

　　每個微服務擁有獨立的數據庫作為微服務架構風格提倡的實踐之一，和其他實踐一起，像魯班鎖中的積木一樣巧妙組合在一起，共同支撐了微服務架構風格所具備的優點，在軟件開發實踐過程中，只有遵守微服務架構風格所推薦的這些實踐，才能最大化的發揮微服務架構的優勢。

　　每個服務擁有獨立數據庫并不是只有優點，數據的分散管理給數據一致性帶來了很大的挑戰，考慮到分布式事務的高昂代價和實現成本，微服務提倡服務之間的無事務協調，通過最終一致性來保證業務流程的正常推進。