微服務是一個軟體架構模式，對微服務的讨論大多集中在容器或其他技術是否能很好的實施微服務這些方面。
本文将從以下幾個角度來和大家分享在微服務架構下進行資料設計需要關注的地方，旨在幫助大家在建構微服務架構時，提供一個資料方面的視角:
●
什麼是微服務● 微服務的優勢及架構特點
● 微服務架構下的資料設計
● 一個适合微服務架構的資料庫
1 什麼是微服務
按照 Martin Fowler 的定義，微服務是一個軟體架構模式，通過開發一系列的小型服務的方式來實作一個應用。每一個這樣的小服務通常都是運作在自己的程序裡面，并且通過輕量級的HTTP API 方式進行通訊。
這些服務通常會以業務子產品為界限，能夠被單獨開發部署，往往都會用自動化的部署工具來進行産品的釋出。通過使用微服務方法，大公司可以更快推出新産品和服務，使得開發團隊與業務目标保持一緻。
2 微服務的優勢
微服務方法體
現出許多優勢，包括更快的上線時間、靈活性、彈性、一緻性以及相對更低的成本。
更快的上線時間
實施微服務架構可以使組織更快地将應用程式推向市場。對整體應用程式的更改(即使很小)需要重新部署整個應用程式堆棧，進而引入風險和複雜性。
相反，服務的更新可以立即送出、測試和部署，對個别服務的更改不會影響系統的其他部分。
更好的靈活性和可擴充性
微服務方法在擴充應用程式時也提供了靈活性。單片應用程式要求整個系統(及其所有功能)同時擴充。
使用微服務，隻需要縮放需要額外性能的元件或功能。可以通過部署更多微服務執行個體來擴充服務範圍，進而實作更有效的容量規劃并降低軟體許可成本，進而降低總體擁有成本。
彈性
使用單體應用程式時，元件的故障可能會危及整個應用程式。在微服務中，每項服務都是隔離的，以防止級聯失敗導緻整個系統崩潰。如果單個微服務的所有執行個體均失敗，則整體服務可能會降級，但其他元件仍可提供有價值的服務。
更容易的規模化
微服務使技術團隊能夠與組織需求保持一緻，并且可以調整團隊的大小以比對所需的任務。通常，微服務團隊規模較小，但是跨部門(如一般涵蓋Ops、Dev、QA)，并專注于整個應用程式的單個元件。
通過提供對個人服務的所有權，而不是功能區域，微服務還可以打破團隊之間的孤島，并改善協作。這種方法對于分布式和遠端團隊尤其強大。 例如，不同地點的團隊可以獨立釋出和部署功能。
3 微服務的技術特點
讓我們通過一個例子來了解微服務架構的技術特點。聯邦銀行的架構師 Jonnathan 非常不喜歡他的産品經理 Mandy，因為他覺得 Mandy 永遠有無窮無盡的想法要實作，搞得他成天就在不斷地修改代碼。
但是 Mandy 是老闆的紅人，而且使用者對産品的反響也不錯，是以很多時候他隻能默默的服從。這一天 Mandy 又成功的說服了老闆要在他們的客戶體驗提升項目中增加輿情分析和 AI 客戶服務子產品，希望通過對社交媒體上有關聯邦銀行的所有評論進行實時的監控和分析來及時發現聯邦銀行的産品回報或者使用者體驗問題。
Jonnathan已經預感到了這樣前所未有的應用場景，會有太多的未知和太多的改變，于是這次決定嘗試使用 Microservices 來建構這個應用。這個是 Jonnathan 設計的架構，系統要求對客戶的社交賬号，如Facebook、Twitter、Google+ 及 Snapchat 公開的資訊及評論進行收集，并在某些合适的時候使用 AI 技術直接和使用者通過社交工具進行互動。
詳情了解
https://dwz.cn/uTp9HTyM
在上圖這個架構裡面，Jonnathan 把4個不同社交媒體的資料采集和互動用 4 個獨立的子產品進行實作。并用一個 Feed Merge 服務，一個 Aggregate Service 把 4 個類似功能的微服務子產品的資料和功能進行整合，提供給分析平台使用。
這裡面每一個服務按照微服務的架構，每一個都是單獨部署，在一個獨立的容器内執行，并使用自己的一個資料庫。
果不其然，系統上線一段時間後，Mandy 說 Google+ 上面幾乎沒有什麼活動，不值得繼續維護這樣的一套系統。Jonnathan 這次毫無抱怨，直接把負責 Google+ 的容器停了，沒有需要任何代碼改動，甚至完全沒有需要對整個系統進行停機。
剛下線 Google+，Mandy 又來提需求說最近合并了另一家銀行，客戶很多使用 Whatsapp。二話不說，Jonnathan 直接上了一個新的子產品來處理 Whatsapp ，如下圖。
又過了一段時間，這一次是他自己要對系統做調整了，原來 Snapchat 最近大火，他部署的系統頻受壓力，性能下降。為了解決這個問題，Jonnathan 果斷增加了額外 2 台容器來同時支撐 Snapchat 資訊的采集和處理。
感謝微服務架構，Jonnathan 在一系列的産品需求變化以及系統擴容需求下，可以從容應付。要實作微服務架構，需要你銘記以下幾個微服務架構的應用設計原則。
解耦
在微服務架構中，應用程式被分解為小型的獨立服務。服務通常專注于特定的離散目标或功能，并沿着業務邊界解耦。按業務界限分離服務可讓團隊專注于正确的目标，并確定服務之間的自主性。
每項服務都是獨立開發，測試和部署的，服務通常是作為獨立的程序或軟體容器分開的，通過網絡和商定的 API 進行通信，盡管在某些情況下，網絡可能在本地。通常部署相同微服務的多個執行個體，進而提供備援和可擴充性。
輕量級 API
微服務之間的通信要使用輕量級 API，如 HTTP RESTful API。這樣可以使得服務對 API 通信方案的依賴減到最小。
複雜的通信處理要在服務端進行，而不是像 ESB 或者 Data Pipeline 處理總線那樣在資料傳輸過程中引入非常多的邏輯，導緻微服務子產品緊緊的綁定在這個資料管道上。
持續釋出
微服務架構帶來的一個非常顯著的負面性就是衆多執行個體的測試釋出及管理。傳統應用雖然開發複雜，但是部署和運維相對比較集中，一台資料庫，2-4 個應用伺服器就差不多了。但是微服務架構下單獨服務的數量輕則 10-20，多則上百個，是以微服務架構一般需要配套的 CI/CD 方法來支撐。
資料與治理
資料的管理在微服務架構下也是和傳統單體有很大的不同考量。大部分時候我們希望資料就和服務一樣，要有充分的獨立性，可以和某個服務一起部署，一起擴充，或者一起重構。
這通常意味着我們可能要在一個微服務架構應用内使用多個資料庫執行個體。但是同樣需要考慮到資料分布在多執行個體之間以後，往往還需要一些備援，以及如何保持這些資料在這些系統中的一緻性等問題。下面我們就着重來讨論微服務架構下的資料設計的一些考量因素。
4 微服務架構下的資料設計
從來沒有一個 one-size-fits-all 的架構，是以在微服務架構下面，我們需要了解的，一樣是幾個關鍵的架構考量點。然後針對自己的實際應用，選擇哪些考量點是更加重要的。
這篇文章的目的，主要就是跟大家來讨論從哪幾個角度着手，來設計一個符合微服務架構原則的資料架構。比如說，我們可以從一系列的問題來開始這個讨論。
● 這麼多微服務之間，我是否可以用一個資料庫，還是多個資料庫來支援
多個微服務？● 如果是多個資料庫，我是否為每一個微服務挑選一個最合适的資料庫，還是選擇同一種類型的資料庫？
● 我如何在微服務架構下擴充我的資料庫？
● 當一個我依賴的服務需要修改資料庫 Schema 的時候，是否會影響到我？
● 當微服務應用不斷衍變的時候，我的資料庫是否可以快速的響應應用需求變化？以上這些就是我們在微服務資料架構時候要關注的地方。
一庫一服還是一庫多服
無論是單體應用，還是微服務應用，有一點是肯定的：應用的各個子產品之間都需要進行較為頻繁的通信，通過一起協同合作，來實作應用的整體價值。
在單體應用中，這種通信是通過方法調用來完成的。在微服務中，則通過 API 調用來完成。這些子產品或者服務間調用，大部分時候是為了共享資料。
共享資料最賤的方式當然就是采用一種共享資料庫的模式，也就是單體應用常用的方式。應用可以有多個系統子產品，但一般都是隻有一個資料庫。如下圖左邊，3 個微服務子產品，後面共享一個資料庫，簡稱一庫多服務。
這種架構模式通常會被認為是微服務架構下的反範式，它的問題在于:
● 單點故障：一個資料庫倒下，整批服務全部停止。何來的服務獨立性？
● 資料在同一個地方，會給貪圖友善的開發或者 DBA 工程師編寫很多資料間高度依賴的程式或者工具。
● 無法針對某一個服務進行精準優化或擴充，如上文所講的 Snapchat 的例子。
是以一般推薦的做法，是為每一個微服務準備一個單獨的資料庫，也即一庫一服(Database per Service)模式。如上圖右側所示。這種模式更加适合微服務架構，它滿足每一個服務是獨立開發、獨立部署、獨立擴充的特性。
需要對一個服務進行更新或者資料架構改動的時候，不會影響到其他的服務。需要對某個服務進行擴充的時候，也可以手術式的對某一個服務進行局部擴容。另外，如果某些服務對資料庫有特殊的需求，這種模式也為下文所講的混合持久化(Polyglot Persistence)提供了可能性。
混合持久化 vs 多模資料庫
混合持久化在大型網際網路公司是一個比較風行的模式。它秉承的原則就是為特别的任務提供最好的工具。比如說，如果我希望提供一個高并發低延遲的共享使用者會話方案(Shared Session Storage)， Redis 可能是一個非常理想的選擇。
如果我是在實作一個産品目錄，涉及到大量不定結構的商品資料及屬性的模組化管理，我可能會采用模式靈活，動态 Schema 的 MongoDB 來作為我的資料庫
解決方案。如果我希望支援非常強大的全文搜尋，ElasticSearch 則是行業中的佼佼者。
微服務的功能分塊獨立部署為這種架構模式提供了非常好的基礎，如上圖左側所示就是個典型的混合持久化的案例:
混合持久化：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)、資料變化流(Change Stream)、橫向擴充能力(Sharding)。
多模資料庫
MongoDB 從 3.4 版本起在多模資料庫場景上提供了不少功能子產品，比如說，使用聚合架構。現在開發者可以使用:
● $graphLookup 來實作類似于圖資料庫的查詢。
● $facet 來實作分面搜尋。
● 記憶體引擎功能，用于支援類似于 Redis 的高速緩存。
● 全文檢索，用于實作搜尋類型場景。
動态模式
這一點一直是 MongoDB 獲得開發者青睐的主要原因之一。MongoDB 無須顯式的定義資料模式即可讓你開始往資料庫寫入。
當資料模型有變化時候，比如說在疊代式開發中非常常見的就是增加一些字段，MongoDB 資料庫不需要對其進行修改 Schema 操作，而是可以直接在同一個集合(表)裡直接寫入新版本的文檔。這個對于需要實作快速疊代，快速傳遞的微服務應用開發是一個非常重要的特性。
資料變化流
微服務架構中由于其分布特性，傳統的強事務機制不再适用。資料的一緻性一般需要通過一些基于 Event Sourcing 或者事件驅動模型的解決方案。Mongo DB 3.6 版本推出的資料更改流，可以用來實作一個類似于 Kafak 一樣的 Message Queue，為各個微服務間的資料協調提供一個簡單易用的線程方案。
橫向擴充能力
MongoDB 一向以其強大的橫向擴充能力著稱。不少 MongoDB 使用者遷移的主要原因就是使用 MongoDB 的 Sharding 技術可以突破關系型資料庫在資料量和性能上的瓶頸。
MongoDB 的 Sharding 有幾個特征使得其非常适合微服務架構使用:
● 彈性擴充：可以擴容也可以縮容。
● 無縫擴充：無須停機，就可線上擴容。
● 自動均衡：無須應用參與即可實作資料的自動均衡，完全透明。一個基于 MongoDB 的微服務參考架構圖。