微服務是一個軟件架構模式，對微服務的討論大多集中在容器或其他技術是否能很好的實施微服務這些方面。

本文將從以下幾個角度來和大家分享在微服務架構下進行數據設計需要關注的地方，旨在幫助大家在構建微服務架構時，提供一個數據方面的視角：

• 什么是微服務
• 微服務的優勢及架構特點
• 微服務架構下的數據設計
• 一個適合微服務架構的數據庫

什么是微服務

按照 Martin Fowler 的定義，微服務是一個軟件架構模式，通過開發一系列的小型服務的方式來實現一個應用。

每一個這樣的小服務通常都是運行在自己的進程里面，并且通過輕量級的 HTTP API 方式進行通訊。

這些服務通常會以業務模塊為界限，能夠被單獨開發部署，往往都會用自動化的部署工具來進行產品的發布。

通過使用微服務方法，大公司可以更快推出新產品和服務，使得開發團隊與業務目標保持一致。

微服務的優勢及架構特點

微服務的優勢

微服務方法體現出許多優勢，包括更快的上線時間、靈活性、彈性、一致性以及相對更低的成本。

更快的上線時間

實施微服務架構可以使組織更快地將應用程序推向市場。對整體應用程序的更改（即使很小）需要重新部署整個應用程序堆棧，從而引入風險和復雜性。

相反，服務的更新可以立即提交、測試和部署，對個別服務的更改不會影響系統的其他部分。

更好的靈活性和可擴展性

微服務方法在擴展應用程序時也提供了靈活性。單片應用程序要求整個系統（及其所有功能）同時擴展。

使用微服務，只需要縮放需要額外性能的組件或功能。可以通過部署更多微服務實例來擴展服務范圍，從而實現更有效的容量規劃并降低軟件許可成本，從而降低總體擁有成本。

彈性

使用單體應用程序時，組件的故障可能會危及整個應用程序。在微服務中，每項服務都是隔離的，以防止級聯失敗導致整個系統崩潰。

如果單個微服務的所有實例均失敗，則整體服務可能會降級，但其他組件仍可提供有價值的服務。

更容易的規模化

微服務使技術團隊能夠與組織需求保持一致，并且可以調整團隊的大小以匹配所需的任務。

通常，微服務團隊規模較小，但是跨部門（如一般涵蓋 Ops、Dev、QA），并專注于整個應用程序的單個組件。

通過提供對個人服務的所有權，而不是功能區域，微服務還可以打破團隊之間的孤島，并改善協作。

這種方法對于分布式和遠程團隊尤其強大。 例如，不同地點的團隊可以獨立發布和部署功能。

微服務的技術特點

讓我們通過一個例子來了解微服務架構的技術特點。

聯邦銀行的架構師 Jonnathan 非常不喜歡他的產品經理 Mandy，因為他覺得 Mandy 永遠有無窮無盡的想法要實現，搞得他成天就在不斷地修改代碼。

但是 Mandy 是老板的紅人，而且用戶對產品的反響也不錯，所以很多時候他只能默默的服從。

這一天 Mandy 又成功的說服了老板要在他們的客戶體驗提升項目中增加輿情分析和 AI 客戶服務模塊，希望通過對社交媒體上有關聯邦銀行的所有評論進行實時的監控和分析來及時發現聯邦銀行的產品反饋或者用戶體驗問題。

Jonnathan 已經預感到了這樣***的應用場景，會有太多的未知和太多的改變，于是這次決定嘗試使用 Microservices 來構建這個應用。

這個是 Jonnathan 設計的架構，系統要求對客戶的社交賬號，如 Facebook、Twitter、Google+ 及 Snapchat 公開的信息及評論進行收集，并在某些合適的時候使用 AI 技術直接和用戶通過社交工具進行互動。

在上圖這個架構里面，Jonnathan 把 4 個不同社交媒體的數據采集和交互用 4 個獨立的模塊進行實現。

并用一個 Feed Merge 服務，一個 Aggregate Service 把 4 個類似功能的微服務模塊的數據和功能進行整合，提供給分析平臺使用。

這里面每一個服務按照微服務的架構，每一個都是單獨部署，在一個獨立的容器內執行，并使用自己的一個數據庫。

果不其然，系統上線一段時間后，Mandy 說 Google+ 上面幾乎沒有什么活動，不值得繼續維護這樣的一套系統。

Jonnathan 這次毫無抱怨，直接把負責 Google+ 的容器停了，沒有需要任何代碼改動，甚至完全沒有需要對整個系統進行停機。

剛下線 Google+，Mandy 又來提需求說最近合并了另一家銀行，客戶很多使用 Whatsapp。

二話不說，Jonnathan 直接上了一個新的模塊來處理 Whatsapp，如下圖：

又過了一段時間，這一次是 Jonnathan 自己要對系統做調整了，原來 Snapchat 最近大火，他部署的系統頻受壓力，性能下降。

為了解決這個問題，Jonnathan 果斷增加了額外 2 臺容器來同時支撐 Snapchat 信息的采集和處理。 

感謝微服務架構，Jonnathan 在一系列的產品需求變化以及系統擴容需求下，可以從容應付。

要實現微服務架構，需要你銘記以下幾個微服務架構的應用設計原則：

解耦

在微服務架構中，應用程序被分解為小型的獨立服務。服務通常專注于特定的離散目標或功能，并沿著業務邊界解耦。

按業務界限分離服務可讓團隊專注于正確的目標，并確保服務之間的自主性。

每項服務都是獨立開發，測試和部署的，服務通常是作為獨立的進程或軟件容器分開的，通過網絡和商定的 API 進行通信，盡管在某些情況下，網絡可能在本地。通常部署相同微服務的多個實例，從而提供冗余和可擴展性。

輕量級 API

微服務之間的通信要使用輕量級 API，如 HTTP RESTful API。這樣可以使得服務對 API 通信方案的依賴減到最小。

復雜的通信處理要在服務端進行，而不是像 ESB 或者 Data Pipeline 處理總線那樣在數據傳輸過程中引入非常多的邏輯，導致微服務模塊緊緊的綁定在這個數據管道上。

持續發布

微服務架構帶來的一個非常顯著的負面性就是眾多實例的測試發布及管理。傳統應用雖然開發復雜，但是部署和運維相對比較集中，一臺數據庫，2-4 個應用服務器就差不多了。

但是微服務架構下單獨服務的數量輕則 10-20，多則上百個，所以微服務架構一般需要配套的 CI/CD 方法來支撐。

數據與治理

數據的管理在微服務架構下也是和傳統單體有很大的不同考量。大部分時候我們希望數據就和服務一樣，要有充分的獨立性，可以和某個服務一起部署，一起擴展，或者一起重構。

這通常意味著我們可能要在一個微服務架構應用內使用多個數據庫實例。但是同樣需要考慮到數據分布在多實例之間以后，往往還需要一些冗余，以及如何保持這些數據在這些系統中的一致性等問題。

下面我們就著重來討論微服務架構下的數據設計的一些考量因素。

微服務架構下的數據設計

從來沒有一個 one-size-fits-all 的架構，所以在微服務架構下面，我們需要了解的，一樣是幾個關鍵的架構考量點。然后針對自己的實際應用，選擇哪些考量點是更加重要的。

這篇文章的目的，主要就是跟大家來討論從哪幾個角度著手，來設計一個符合微服務架構原則的數據架構。

比如說，我們可以從一系列的問題來開始這個討論：

• 這么多微服務之間，我是否可以用一個數據庫，還是多個數據庫來支持多個微服務？
• 如果是多個數據庫，我是否為每一個微服務挑選一個最合適的數據庫，還是選擇同一種類型的數據庫？
• 我如何在微服務架構下擴展我的數據庫？
• 當一個我依賴的服務需要修改數據庫 Schema 的時候，是否會影響到我？
• 當微服務應用不斷衍變的時候，我的數據庫是否可以快速的響應應用需求變化？

以上這些就是我們在微服務數據架構時候要關注的地方。

一庫一服還是一庫多服

無論是單體應用，還是微服務應用，有一點是肯定的：應用的各個模塊之間都需要進行較為頻繁的通信，通過一起協同合作，來實現應用的整體價值。

在單體應用中，這種通信是通過方法調用來完成的。在微服務中，則通過 API 調用來完成。這些模塊或者服務間調用，大部分時候是為了共享數據。

共享數據最賤的方式當然就是采用一種共享數據庫的模式，也就是單體應用常用的方式。應用可以有多個系統模塊，但一般都是只有一個數據庫。

如下圖左邊，3 個微服務模塊，后面共享一個數據庫，簡稱一庫多服務：

這種架構模式通常會被認為是微服務架構下的反范式，它的問題在于：

• 單點故障：一個數據庫倒下，整批服務全部停止。何來的服務獨立性？
• 數據在同一個地方，會給貪圖方便的開發或者 DBA 工程師編寫很多數據間高度依賴的程序或者工具。
• 無法針對某一個服務進行精準優化或擴展，如上文所講的 Snapchat 的例子。

所以一般推薦的做法，是為每一個微服務準備一個單獨的數據庫，也即一庫一服（database per service）模式。

如上圖右側所示。這種模式更加適合微服務架構，它滿足每一個服務是獨立開發、獨立部署、獨立擴展的特性。

當需要對一個服務進行升級或者數據架構改動的時候，不會影響到其他的服務。需要對某個服務進行擴展的時候，也可以手術式的對某一個服務進行局部擴容。

另外，如果某些服務對數據庫有特殊的需求，這種模式也為下文所講的混合持久化（Polyglot Persistence）提供了可能性。

混合持久化 VS 多模數據庫

混合持久化在大型互聯網公司是一個比較風行的模式。它秉承的原則就是為特別的任務提供***的工具。

比如說，如果我希望提供一個高并發低延遲的共享用戶會話方案（shared session storage）， Redis 可能是一個非常理想的選擇。

如果我是在實現一個產品目錄，涉及到大量不定結構的商品數據及屬性的建模管理，我可能會采用模式靈活，動態 Schema 的 MongoDB 來作為我的數據庫解決方案。

如果我希望支持非常強大的全文搜索，ElasticSearch 則是行業中的佼佼者。

[[231119]]

微服務的功能分塊獨立部署為這種架構模式提供了非常好的基礎，如上圖左側所示就是個典型的混合持久化的案例：

• 混合持久化：Polyglot Persistence
• 多模數據庫：Multi-model Database

當然，有句話說的是架構師的工作就是每天做不斷的取舍（trade off），因為選擇往往是讓人很糾結。

混合持久化的優勢很明顯，可以讓每個單獨的服務使用到***的工具和技術。

但是它的弊端也是不容忽視：部署、監控、備份、升級等數據庫管理工作從來都是一件困難但是重要的任務。引入多個不同的數據庫，也意味著對系統管理維護的復雜度和成本提高了很多。

這種情況下可能需要比較有資源的公司或者團隊才可以使用。這也解釋了這個模式為何在大型互聯網公司得到較多的采用與推廣。

針對于其他小型規模的用戶，或者是缺乏足夠掌握各種新型技術人才的公司來說，另一種更為可行的模式可能是多模數據庫（Multi-model）。

如上圖右側所示，多模數據庫的特征是：

• 依然是一庫一服務（為一個服務部署一個單獨的數據庫）。
• 但是使用的是同一種類型，支持多種場景的數據庫，如 NoSQL 中間為功能最全面的 MongoDB。
• 雖然是多實例，但是只需維護一種類型的數據庫，管理上和人員配備上都較為簡單。

如果你在開發的應用是一款企業級產品，會交付到客戶環境部署安裝，則運維管理的簡單性將在技術選型中占據非常重要的一個比重，無疑這種情況下多模數據庫更加適用。

微服務擴展你的數據

微服務架構的一大裨益是其靈活的擴展性。以上面的 Snapchat 為例，如果需要采集或處理的數據量快速增長，在我們增加應用服務實例的同時，支撐數據存儲的模塊也要相應擴充。

AFK Partners 在他們的 Scale Cube 一文里對性能擴展提出了這樣的觀點：要設計一個真正意義上的可擴展系統，我們必須考慮 3 個維度，如上圖所示：

• X 軸，系統復制（橫向擴展）
• Y 軸，非重疊功能的拆分（微服務）
• Z 軸，數據的分區（Sharding）

一個好的數據架構，在微服務體系內，應該具有同樣的可擴展、易擴展性質，從而不給微服務架構拖后腿。

關于數據分區擴展有兩種做法：

• 應用數據分區
• 數據庫分區

應用數據分區，顧名思義，就是在應用端對數據的存儲進行分區管理。比如說，一個社交應用可以按國家或地區為界把用戶的數據分發到不同數據庫實例里面。

這樣的話每個數據庫實例只需要存儲一部分數據，從而實現海量的數據管理能力。

數據庫分區，就是由數據庫的路由節點來完成數據分區的任務。數據庫分區的優勢是顯然的，它對應用透明、擴展快速、無須下線等。

如果你的應用有潛在擴充的需求，選擇一個能夠自動擴展的分布式數據庫是一個比較明智的選擇。

動態模式支持及快速開發能力

這是一個很多架構師可能會忽略，但是非常重要的關注點。我們在迭代式開發 DevOps 微服務上的很多努力，都是為了快速開發，快速上線，以及快速響應變化的需求。

從數據架構師的角度來看，如何不成為在這個快速開發方法模式中的一個瓶頸，有一個很重要的環節就是是否有一個能夠及時響應變化的數據模型。

傳統的數據庫都是強模式，需要對 Schema 進行清晰定義, 在需求修改導致模型修改的時候需要對數據庫進行模式升級，是一個需要下線、耗時并且是高成本的運維操作。

在新一代的 NoSQL 數據庫產生之前，我們并不需要考慮這個問題，但是以 MongoDB、Cassandra 等為代表的 NoSQL 代表的是靈活建模。

動態支持模式變化的特征使得它們成為敏捷開發和微服務體系內一個有力的競爭者，在選型的時候也是一個重要的考量因素之一。

我們說一庫一服的架構使得對一個服務的數據庫模式修改不會影響到其他服務。

但是如果使用一個動態模式（有時候有人會說無模式）的數據庫，則在該服務本身模式修改的時候也可以最小化運維成本。

一個適合微服務架構的數據庫

紅杉資本的合伙人 Matt Miller 是公認的微服務技術領域專家。他廣被傳播的“微服務生態圖”詳盡的列出了微服務架構的相關技術棧。在這里他推薦了 MongoDB 作為主要的數據管理方案。

MongoDB 是一個分布式文檔型數據庫，它有以下特性使它非常適合于微服務架構：

• 多模數據庫（Multi-model）
• 原生 JSON 數據結構 - API
• 動態模式、無模式（Dynamic schema / Schemaless）
• 數據變化流（Change Stream）
• 橫向擴展能力（Sharding）

多模數據庫

MongoDB 從 3.4 版本起在多模數據庫場景上提供了不少功能模塊，比如說，使用聚合框架（Aggregation Framework）。現在開發者可以使用：

1. $graphLookup 來實現類似于圖數據庫的查詢。
2. $facet 來實現分面搜索。
3. 內存引擎功能，用于支持類似于 Redis 的高速緩存。
4. 全文檢索，用于實現搜索類型場景。

JSON 數據結構

由于 MongoDB 原生就是 JSON 數據模型，正好是微服務架構中用于模塊間通信的 HTTP RESTful API 調用的主要數模型。

事實上，你可以使用一些開源中間件，快速的來構建起微服務之間的 API 服務。

動態模式

這一點一直是 MongoDB 獲得開發者青睞的主要原因之一。MongoDB 無須顯式的定義數據模式即可讓你開始往數據庫寫入。

當數據模型有變化時候，比如說在迭代式開發中非常常見的就是增加一些字段，MongoDB 數據庫不需要對其進行修改 Schema 操作，而是可以直接在同一個集合（表）里直接寫入新版本的文檔。

這個對于需要實現快速迭代，快速交付的微服務應用開發是一個非常重要的特性。

數據變化流

微服務架構中由于其分布特性，傳統的強事務機制不再適用。數據的一致性一般需要通過一些基于 Event Sourcing 或者事件驅動模型的解決方案。

MongoDB 3.6 版本推出的數據更改流，可以用來實現一個類似于 Kafak 一樣的 Message Queue，為各個微服務間的數據協調提供一個簡單易用的線程方案。

橫向擴展能力

MongoDB 一向以其強大的橫向擴展能力著稱。不少 MongoDB 用戶遷移的主要原因就是使用 MongoDB 的 Sharding 技術可以突破關系型數據庫在數據量和性能上的瓶頸。

[[231121]]

MongoDB 的 Sharding 有幾個特征使得其非常適合微服務架構使用：

• 彈性擴展：可以擴容也可以縮容。
• 無縫擴展：無須停機，就可在線擴容。
• 自動均衡：無須應用參與即可實現數據的自動均衡，完全透明。

一個基于 MongoDB 的微服務參考架構圖：