微服務真的不挑資料庫嗎？如何選擇？

微服務架構的應用具有很好的擴充套件性，因此似乎微服務並不挑資料庫，在微服務中使用哪種資料庫問題都不是很大。事實真的如此嗎?

微服務架構的應用具有很好的擴充套件性，因此似乎微服務並不挑資料庫，在微服務中使用哪種資料庫問題都不是很大。事實真的如此嗎?也許對於一些研發能力很強的隊伍來說，為微服務選擇資料庫是很容易的事情，因為選擇的資料庫無論存在哪方面的缺陷，他們都有辦法透過應用方面的最佳化去解決它。而對於一些普通的研發隊伍來說，有時候還真的搞不定。

很多企業剛剛轉向微服務架構的時候也是交了大量的學費的，很多企業的微服務架構轉型是：“開發一時爽，運維兩眼淚”。實際上很多設計和開發的缺陷最後都是讓運維來想辦法填坑的。與傳統的集中架構不同，微服務的坑，運維填起來難度大多了。如果微服務應用將一個大資料庫拆分成多個小型的領域資料庫，那麼一條重要的原則就是要永遠確保這些資料庫是小型資料庫，其資料量的增長是緩慢的，隨著每年業務的增長率稍微增長一點點的，歷史資料一定是能夠及時歸檔的。這樣的小型資料庫才會在長期執行的時間裡保證較好的效能，不會給運維人員帶來太大的負擔。

從另外一個角度來講，微服務的資料應該儲存到適當的資料庫中，而不是在沒有掌握資料存取特點的情況下，隨意選擇一個資料庫。目前資料庫可選擇的種類太多了，以阿里雲等雲廠商為例，他們就已經為微服務開發者提供了眼花繚亂的選項。

不同的應用場景選擇不同的資料庫產品，才能讓專案今後的發展路徑更為順暢。這麼多的資料庫產品，我們該如何來選擇呢?雖然微應用已經弱化了資料庫的很多特性，大大減少了跨服務的資料融合計算，不過針對不同型別的微服務，我們仍然需要十分謹慎的來選擇資料庫產品。

我們該如何為自己的微服務選擇適當的資料庫產品呢?這就需要從幾個方面去考慮了。

首先要考慮的是你的微服務中對資料的訪問方式。選擇資料庫的最重要的因素是你的查詢的模式是什麼樣的。如果你只需要儲存某些鍵值，那麼KV資料庫可能是比較好的選擇，比如你可以選擇Redis;如果你的應用基本上都是基於主鍵查詢，附加一些主鍵關聯的其他欄位，那麼一些寬列資料庫可能很適合你的微服務，比如Cassandra;如果你的應用主要是訪問一些單表中的資料，不過檢索條件可能會比較豐富，模式不是十分固定，那麼使用文件資料庫可能比較好，MongoDB、CouchDB等可能比較對你的胃口;如果你的應用經常有一些多表關聯的關係型訪問，那麼關係型資料庫，比如PostgreSQL、MySQLl等可能更適合;如果你的應用主要是根據主鍵做模糊查詢，全文檢索，那麼ES可能會優於其他資料庫。

如果有一個場景有多種資料庫適合，那麼可以根據資料一致性等要求來做出進一步的篩選，比如你的場景中MySQL和MongoDB都比較適合，那麼如果在要求強一致性的情況下，傾向於選擇MySQL，否則可以考慮MongoDB。

實際上，在你的應用系統中，不同的微服務可以選擇不同型別的資料庫，從而最大限度的最佳化資料訪問。比如你的有很多影片要儲存，那麼選擇S3物件儲存來儲存影片肯定比把影片儲存到關係型資料庫的LOB欄位中要好得多，在關係型資料庫中只需要儲存物件的ID就可以了。

在一個應用系統中使用多種資料庫也不是多多益善，資料庫種類太多會導致系統架構變得臃腫，運維的成本也會大大增加。因此適當的選擇幾種資料庫才是較好的設計方案。這種情況下，一些多模資料庫就比較具有優勢了。比如說在系統中以RDBMS為主，稍微有一些JSON資料儲存、還有少量應用會使用一些時序資料和一些GIS資料，那麼選擇PostgreSQL就可以滿足這些綜合要求。

實際上為微服務選擇資料庫產品不僅僅要考慮這些因素，開發團隊的經驗、運維能力、成本等因素也是要考慮的。因為微服務架構的特點，我們透過領域建模會將一個大型系統的資料拆分為多個不同的子領域，因此高併發支援能力，效能，大資料量下的複雜SQL效能等方面需要考慮的因素相對少一些。不過對於一些稍微極端一些的應用場景，可能我們需要考慮的會更為複雜一些。

另外一點就是聚合計算的問題，任何應用都有聚合計算的問題，特別是一些實時聚合計算的需求，我們也必須滿足。因此在領域建模將資料拆分之後我們依然需要將這些資料匯聚起來進行計算。雖然我們也可以使用ShardingSphere這樣的資料庫閘道器來實現一定的聚合計算，不過大資料量的分散式環境的聚合計算在效能上往往會遇到一些問題。解決此類問題的方法不外乎兩個，一個是在微服務層面，對明細資料進行準實時彙總，這樣聚合計算不需要針對明細資料進行。另外一種方法就是使用ODS或者資料中臺作為聚合計算的平臺，從而減輕微服務資料層的負擔。

原本一個大型資料庫拆分為很多個小庫後會不會給運維帶來壓力呢?答案是肯定的，因此微服務的架構師應該對這些小型資料庫做一個很好的架構設計，包括高可用、災備，資料歸檔，資料自動清理，這些工作運維人員可以參與設計，但是必須在應用中實現自動化的管理，否則這一堆堆的小庫上來，運維人員平時要是去監控巡檢，平時也沒啥事，還浪費時間，一旦出了問題，還不太好處置。

如果你的應用是託管在公有云上的，並且你的每個庫的容量、負載都可以比較好的控制，那麼採購公有云的RDS是比較省事的做法，不過公有云的特點是入門很便宜，一旦你的庫變大了，服務要升級了，那麼價錢絕對不是簡單的乘以某個倍數的問題。公有云上，大的主機和資料庫服務價格會有一個跳躍式的提升，應用架構師要十分注意這一點。私有云對費用相對沒有那麼敏感，使用私有云的RDS服務可以大大的降低運維的壓力。在這方面，微服務的架構師一定要先和雲平臺部門做好溝通。

如果你不希望管理碎片化的小型資料庫(無論是RDS還是執行在容器中的資料庫)，那麼帶有多租戶、多模儲存能力的分散式資料庫也許是你喜歡的選擇。運維一個大型的雲資料庫可能比運維幾十個小資料庫更合你的胃口。這種選擇也是合適的，只要和你的企業的整體IT政策與IT基礎架構相吻合，那也是不錯的選擇。