爲什麼微服務要有獨立的數據庫
實施微服務架構，我們一直在遵循一個實踐原則：每個微服務要有自己獨立的數據庫，避免數據庫層面的耦合。這種理所當然感覺好像不需要多加思考，就是應該這樣做；
圖片來源：James Lewis 和 Martin Fowler 的文章《Microservices》那麼到底爲什麼每個微服務都需要獨立的數據庫，數據放在一個數據庫有問題嗎？要回答這個問題，我們還是要回歸到微服務的定義。（見參考資料）
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 在微服務的定義中也強調微服務是構建在業務能力之上的，可見微服務的小而自治是建立在獨立的業務能力基礎之上的。因此，簡單的將併發量和性能要求相近的業務合併到一個服務中，無法達到微服務期望的效果，也就沒法獲得微服務所具有的好處。一方面不同的業務對數據庫的要求除了要考慮併發量和性能，還應該包括數據量的大小、讀寫的比例、實時性要求等等，共享數據庫的方式一般情況下也很難滿足不同業務服務對這些指標的要求，將所有服務的數據都存放在一個數據庫中本身也是一種非常大的挑戰。另一方面用動態的視角看這個問題，業務是發展的，隨着市場的不斷變化，不同的業務隨時間而演進出來的需求可能是完全不同的，對數據庫的需求也會有所不同，共享數據庫的方式很可能變成瓶頸限制業務的發展。
微服務架構要不斷演進
最後
每個微服務擁有獨立的數據庫作爲微服務架構風格提倡的實踐之一，和其他實踐一起，像魯班鎖中的積木一樣巧妙組合在一起，共同支撐了微服務架構風格所具備的優點，在軟件開發實踐過程中，只有遵守微服務架構風格所推薦的這些實踐，才能最大化的發揮微服務架構的優勢。每個服務擁有獨立數據庫並不是只有優點，數據的分散管理給數據一致性帶來了很大的挑戰，考慮到分佈式事務的高昂代價和實現成本，微服務提倡服務之間的無事務協調，通過最終一致性來保證業務流程的正常推進。
- 參考資料：
James Lewis、Martin Fowler《Microservices》
https://martinfowler.com/articles/microservices.html
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/lyI25_WAgNASrQvCKoIpyQ