? ? ? ?微服務(wù)是一個(gè)軟件架構(gòu)模式，對(duì)微服務(wù)的討論大多集中在容器或其他技術(shù)是否能很好的實(shí)施微服務(wù)這些方面。

? ? ? 本文將從以下幾個(gè)角度來和大家分享在微服務(wù)架構(gòu)下進(jìn)行數(shù)據(jù)設(shè)計(jì)需要關(guān)注的地方，旨在幫助大家在構(gòu)建微服務(wù)架構(gòu)時(shí)，提供一個(gè)數(shù)據(jù)方面的視角:

• 什么是微服務(wù)

• 微服務(wù)的優(yōu)勢(shì)及架構(gòu)特點(diǎn)

• 微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計(jì)

• 一個(gè)適合微服務(wù)架構(gòu)的數(shù)據(jù)庫(kù)

什么是微服務(wù)

? ? ? 按照 Martin Fowler 的定義，微服務(wù)是一個(gè)軟件架構(gòu)模式，通過開發(fā)一系列的小型服務(wù)的方式來實(shí)現(xiàn)一個(gè)應(yīng)用。每一個(gè)這樣的小服務(wù)通常都是運(yùn)行在自己的進(jìn)程里面，并且通過輕量級(jí)的HTTP API 方式進(jìn)行通訊。

? ? ? 這些服務(wù)通常會(huì)以業(yè)務(wù)模塊為界限，能夠被單獨(dú)開發(fā)部署，往往都會(huì)用自動(dòng)化的部署工具來進(jìn)行產(chǎn)品的發(fā)布。通過使用微服務(wù)方法，大公司可以更快推出新產(chǎn)品和服務(wù)，使得開發(fā)團(tuán)隊(duì)與業(yè)務(wù)目標(biāo)保持一致。

微服務(wù)的優(yōu)勢(shì)

? ? ? 微服務(wù)方法體現(xiàn)出許多優(yōu)勢(shì)，包括更快的上線時(shí)間、靈活性、彈性、一致性以及相對(duì)更低的成本。

• 更快的上線時(shí)間

? ? ? 實(shí)施微服務(wù)架構(gòu)可以使組織更快地將應(yīng)用程序推向市場(chǎng)。對(duì)整體應(yīng)用程序的更改(即使很小)需要重新部署整個(gè)應(yīng)用程序堆棧，從而引入風(fēng)險(xiǎn)和復(fù)雜性。

? ? ? 相反，服務(wù)的更新可以立即提交、測(cè)試和部署，對(duì)個(gè)別服務(wù)的更改不會(huì)影響系統(tǒng)的其他部分。

• 更好的靈活性和可擴(kuò)展性

? ? ? 微服務(wù)方法在擴(kuò)展應(yīng)用程序時(shí)也提供了靈活性。單片應(yīng)用程序要求整個(gè)系統(tǒng)(及其所有功能)同時(shí)擴(kuò)展。

? ? ? 使用微服務(wù)，只需要縮放需要額外性能的組件或功能。可以通過部署更多微服務(wù)實(shí)例來擴(kuò)展服務(wù)范圍，從而實(shí)現(xiàn)更有效的容量規(guī)劃并降低軟件許可成本，從而降低總體擁有成本。

• 彈性

? ? ? 使用單體應(yīng)用程序時(shí)，組件的故障可能會(huì)危及整個(gè)應(yīng)用程序。在微服務(wù)中，每項(xiàng)服務(wù)都是隔離的，以防止級(jí)聯(lián)失敗導(dǎo)致整個(gè)系統(tǒng)崩潰。如果單個(gè)微服務(wù)的所有實(shí)例均失敗，則整體服務(wù)可能會(huì)降級(jí)，但其他組件仍可提供有價(jià)值的服務(wù)。

• 更容易的規(guī)模化

? ? ? 微服務(wù)使技術(shù)團(tuán)隊(duì)能夠與組織需求保持一致，并且可以調(diào)整團(tuán)隊(duì)的大小以匹配所需的任務(wù)。通常，微服務(wù)團(tuán)隊(duì)規(guī)模較小，但是跨部門(如一般涵蓋Ops、Dev、QA)，并專注于整個(gè)應(yīng)用程序的單個(gè)組件。

? ? ? 通過提供對(duì)個(gè)人服務(wù)的所有權(quán)，而不是功能區(qū)域，微服務(wù)還可以打破團(tuán)隊(duì)之間的孤島，并改善協(xié)作。這種方法對(duì)于分布式和遠(yuǎn)程團(tuán)隊(duì)尤其強(qiáng)大。 例如，不同地點(diǎn)的團(tuán)隊(duì)可以獨(dú)立發(fā)布和部署功能。

微服務(wù)的技術(shù)特點(diǎn)

? ? ? 讓我們通過一個(gè)例子來了解微服務(wù)架構(gòu)的技術(shù)特點(diǎn)。聯(lián)邦銀行的架構(gòu)師 Jonnathan 非常不喜歡他的產(chǎn)品經(jīng)理 Mandy，因?yàn)樗X得 Mandy 永遠(yuǎn)有無窮無盡的想法要實(shí)現(xiàn)，搞得他成天就在不斷地修改代碼。

? ? ? 但是 Mandy 是老板的紅人，而且用戶對(duì)產(chǎn)品的反響也不錯(cuò)，所以很多時(shí)候他只能默默的服從。這一天 Mandy 又成功的說服了老板要在他們的客戶體驗(yàn)提升項(xiàng)目中增加輿情分析和 AI 客戶服務(wù)模塊，希望通過對(duì)社交媒體上有關(guān)聯(lián)邦銀行的所有評(píng)論進(jìn)行實(shí)時(shí)的監(jiān)控和分析來及時(shí)發(fā)現(xiàn)聯(lián)邦銀行的產(chǎn)品反饋或者用戶體驗(yàn)問題。

? ? ? Jonnathan已經(jīng)預(yù)感到了這樣前所未有的應(yīng)用場(chǎng)景，會(huì)有太多的未知和太多的改變，于是這次決定嘗試使用 Microservices 來構(gòu)建這個(gè)應(yīng)用。這個(gè)是 Jonnathan 設(shè)計(jì)的架構(gòu)，系統(tǒng)要求對(duì)客戶的社交賬號(hào)，如 Facebook、Twitter、Google+ 及 Snapchat 公開的信息及評(píng)論進(jìn)行收集，并在某些合適的時(shí)候使用 AI 技術(shù)直接和用戶通過社交工具進(jìn)行互動(dòng)。

? ? ? 在上圖這個(gè)架構(gòu)里面，Jonnathan 把4個(gè)不同社交媒體的數(shù)據(jù)采集和交互用 4 個(gè)獨(dú)立的模塊進(jìn)行實(shí)現(xiàn)。并用一個(gè) Feed Merge 服務(wù)，一個(gè) Aggregate Service 把 4 個(gè)類似功能的微服務(wù)模塊的數(shù)據(jù)和功能進(jìn)行整合，提供給分析平臺(tái)使用。

? ? ? 這里面每一個(gè)服務(wù)按照微服務(wù)的架構(gòu)，每一個(gè)都是單獨(dú)部署，在一個(gè)獨(dú)立的容器內(nèi)執(zhí)行，并使用自己的一個(gè)數(shù)據(jù)庫(kù)。

? ? ? 果不其然，系統(tǒng)上線一段時(shí)間后，Mandy 說 Google+ 上面幾乎沒有什么活動(dòng)，不值得繼續(xù)維護(hù)這樣的一套系統(tǒng)。Jonnathan 這次毫無抱怨，直接把負(fù)責(zé) Google+ 的容器停了，沒有需要任何代碼改動(dòng)，甚至完全沒有需要對(duì)整個(gè)系統(tǒng)進(jìn)行停機(jī)。

? ? ? 剛下線 Google+，Mandy 又來提需求說最近合并了另一家銀行，客戶很多使用 Whatsapp。二話不說，Jonnathan 直接上了一個(gè)新的模塊來處理 Whatsapp ，如下圖。

?

? ? ? 又過了一段時(shí)間，這一次是他自己要對(duì)系統(tǒng)做調(diào)整了，原來 Snapchat 最近大火，他部署的系統(tǒng)頻受壓力，性能下降。為了解決這個(gè)問題，Jonnathan 果斷增加了額外 2 臺(tái)容器來同時(shí)支撐 Snapchat 信息的采集和處理。?

? ? ? 感謝微服務(wù)架構(gòu)，Jonnathan 在一系列的產(chǎn)品需求變化以及系統(tǒng)擴(kuò)容需求下，可以從容應(yīng)付。要實(shí)現(xiàn)微服務(wù)架構(gòu)，需要你銘記以下幾個(gè)微服務(wù)架構(gòu)的應(yīng)用設(shè)計(jì)原則。

解耦

? ? ? 在微服務(wù)架構(gòu)中，應(yīng)用程序被分解為小型的獨(dú)立服務(wù)。服務(wù)通常專注于特定的離散目標(biāo)或功能，并沿著業(yè)務(wù)邊界解耦。按業(yè)務(wù)界限分離服務(wù)可讓團(tuán)隊(duì)專注于正確的目標(biāo)，并確保服務(wù)之間的自主性。

? ? ? 每項(xiàng)服務(wù)都是獨(dú)立開發(fā)，測(cè)試和部署的，服務(wù)通常是作為獨(dú)立的進(jìn)程或軟件容器分開的，通過網(wǎng)絡(luò)和商定的 API 進(jìn)行通信，盡管在某些情況下，網(wǎng)絡(luò)可能在本地。通常部署相同微服務(wù)的多個(gè)實(shí)例，從而提供冗余和可擴(kuò)展性。

輕量級(jí) API

? ? ? 微服務(wù)之間的通信要使用輕量級(jí) API，如 HTTP RESTful API。這樣可以使得服務(wù)對(duì) API 通信方案的依賴減到最小。

? ? ? 復(fù)雜的通信處理要在服務(wù)端進(jìn)行，而不是像 ESB 或者 Data Pipeline 處理總線那樣在數(shù)據(jù)傳輸過程中引入非常多的邏輯，導(dǎo)致微服務(wù)模塊緊緊的綁定在這個(gè)數(shù)據(jù)管道上。

持續(xù)發(fā)布

? ? ? 微服務(wù)架構(gòu)帶來的一個(gè)非常顯著的負(fù)面性就是眾多實(shí)例的測(cè)試發(fā)布及管理。傳統(tǒng)應(yīng)用雖然開發(fā)復(fù)雜，但是部署和運(yùn)維相對(duì)比較集中，一臺(tái)數(shù)據(jù)庫(kù)，2-4 個(gè)應(yīng)用服務(wù)器就差不多了。但是微服務(wù)架構(gòu)下單獨(dú)服務(wù)的數(shù)量輕則 10-20，多則上百個(gè)，所以微服務(wù)架構(gòu)一般需要配套的 CI/CD 方法來支撐。

數(shù)據(jù)與治理

? ? ? 數(shù)據(jù)的管理在微服務(wù)架構(gòu)下也是和傳統(tǒng)單體有很大的不同考量。大部分時(shí)候我們希望數(shù)據(jù)就和服務(wù)一樣，要有充分的獨(dú)立性，可以和某個(gè)服務(wù)一起部署，一起擴(kuò)展，或者一起重構(gòu)。

? ? ? 這通常意味著我們可能要在一個(gè)微服務(wù)架構(gòu)應(yīng)用內(nèi)使用多個(gè)數(shù)據(jù)庫(kù)實(shí)例。但是同樣需要考慮到數(shù)據(jù)分布在多實(shí)例之間以后，往往還需要一些冗余，以及如何保持這些數(shù)據(jù)在這些系統(tǒng)中的一致性等問題。下面我們就著重來討論微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計(jì)的一些考量因素。

微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計(jì)

? ? ? 從來沒有一個(gè) one-size-fits-all 的架構(gòu)，所以在微服務(wù)架構(gòu)下面，我們需要了解的，一樣是幾個(gè)關(guān)鍵的架構(gòu)考量點(diǎn)。然后針對(duì)自己的實(shí)際應(yīng)用，選擇哪些考量點(diǎn)是更加重要的。

? ? ? 這篇文章的目的，主要就是跟大家來討論從哪幾個(gè)角度著手，來設(shè)計(jì)一個(gè)符合微服務(wù)架構(gòu)原則的數(shù)據(jù)架構(gòu)。比如說，我們可以從一系列的問題來開始這個(gè)討論。

• 這么多微服務(wù)之間，我是否可以用一個(gè)數(shù)據(jù)庫(kù)，還是多個(gè)數(shù)據(jù)庫(kù)來支持多個(gè)微服務(wù)？

• 如果是多個(gè)數(shù)據(jù)庫(kù)，我是否為每一個(gè)微服務(wù)挑選一個(gè)最合適的數(shù)據(jù)庫(kù)，還是選擇同一種類型的數(shù)據(jù)庫(kù)？

• 我如何在微服務(wù)架構(gòu)下擴(kuò)展我的數(shù)據(jù)庫(kù)？

• 當(dāng)一個(gè)我依賴的服務(wù)需要修改數(shù)據(jù)庫(kù) Schema 的時(shí)候，是否會(huì)影響到我？

• 當(dāng)微服務(wù)應(yīng)用不斷衍變的時(shí)候，我的數(shù)據(jù)庫(kù)是否可以快速的響應(yīng)應(yīng)用需求變化？以上這些就是我們?cè)谖⒎?wù)數(shù)據(jù)架構(gòu)時(shí)候要關(guān)注的地方。

一庫(kù)一服還是一庫(kù)多服

? ? ? 無論是單體應(yīng)用，還是微服務(wù)應(yīng)用，有一點(diǎn)是肯定的：應(yīng)用的各個(gè)模塊之間都需要進(jìn)行較為頻繁的通信，通過一起協(xié)同合作，來實(shí)現(xiàn)應(yīng)用的整體價(jià)值。

? ? ? 在單體應(yīng)用中，這種通信是通過方法調(diào)用來完成的。在微服務(wù)中，則通過 API 調(diào)用來完成。這些模塊或者服務(wù)間調(diào)用，大部分時(shí)候是為了共享數(shù)據(jù)。

? ? ? 共享數(shù)據(jù)最賤的方式當(dāng)然就是采用一種共享數(shù)據(jù)庫(kù)的模式，也就是單體應(yīng)用常用的方式。應(yīng)用可以有多個(gè)系統(tǒng)模塊，但一般都是只有一個(gè)數(shù)據(jù)庫(kù)。如下圖左邊，3 個(gè)微服務(wù)模塊，后面共享一個(gè)數(shù)據(jù)庫(kù)，簡(jiǎn)稱一庫(kù)多服務(wù)。

? ? ? 這種架構(gòu)模式通常會(huì)被認(rèn)為是微服務(wù)架構(gòu)下的反范式，它的問題在于:

• 單點(diǎn)故障：一個(gè)數(shù)據(jù)庫(kù)倒下，整批服務(wù)全部停止。何來的服務(wù)獨(dú)立性？

• 數(shù)據(jù)在同一個(gè)地方，會(huì)給貪圖方便的開發(fā)或者 DBA 工程師編寫很多數(shù)據(jù)間高度依賴的程序或者工具。

• 無法針對(duì)某一個(gè)服務(wù)進(jìn)行精準(zhǔn)優(yōu)化或擴(kuò)展，如上文所講的 Snapchat 的例子。

? ? ? 所以一般推薦的做法，是為每一個(gè)微服務(wù)準(zhǔn)備一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)，也即一庫(kù)一服(Database per Service)模式。如上圖右側(cè)所示。這種模式更加適合微服務(wù)架構(gòu)，它滿足每一個(gè)服務(wù)是獨(dú)立開發(fā)、獨(dú)立部署、獨(dú)立擴(kuò)展的特性。

? ? ? 當(dāng)需要對(duì)一個(gè)服務(wù)進(jìn)行升級(jí)或者數(shù)據(jù)架構(gòu)改動(dòng)的時(shí)候，不會(huì)影響到其他的服務(wù)。需要對(duì)某個(gè)服務(wù)進(jìn)行擴(kuò)展的時(shí)候，也可以手術(shù)式的對(duì)某一個(gè)服務(wù)進(jìn)行局部擴(kuò)容。另外，如果某些服務(wù)對(duì)數(shù)據(jù)庫(kù)有特殊的需求，這種模式也為下文所講的混合持久化(Polyglot Persistence)提供了可能性。

混合持久化 vs 多模數(shù)據(jù)庫(kù)

? ? ? 混合持久化在大型互聯(lián)網(wǎng)公司是一個(gè)比較風(fēng)行的模式。它秉承的原則就是為特別的任務(wù)提供最好的工具。比如說，如果我希望提供一個(gè)高并發(fā)低延遲的共享用戶會(huì)話方案(Shared Session Storage)， Redis 可能是一個(gè)非常理想的選擇。

? ? ? 如果我是在實(shí)現(xiàn)一個(gè)產(chǎn)品目錄，涉及到大量不定結(jié)構(gòu)的商品數(shù)據(jù)及屬性的建模管理，我可能會(huì)采用模式靈活，動(dòng)態(tài) Schema 的 MongoDB 來作為我的數(shù)據(jù)庫(kù)解決方案。如果我希望支持非常強(qiáng)大的全文搜索，ElasticSearch 則是行業(yè)中的佼佼者。

? ? ? 微服務(wù)的功能分塊獨(dú)立部署為這種架構(gòu)模式提供了非常好的基礎(chǔ)，如上圖左側(cè)所示就是個(gè)典型的混合持久化的案例:

• 混合持久化：Polyglot Persistence

• 多模數(shù)據(jù)庫(kù)：Multi- model Database

? ? ? 當(dāng)然，有句話說的是架構(gòu)師的工作就是每天做不斷的取舍(Trade Off)，因?yàn)檫x擇往往是讓人很糾結(jié)。混合持久化的優(yōu)勢(shì)很明顯，可以讓每個(gè)單獨(dú)的服務(wù)使用到最佳的工具和技術(shù)。

? ? ? 但是它的弊端也是不容忽視：部署、監(jiān)控、備份、升級(jí)等數(shù)據(jù)庫(kù)管理工作從來都是一件困難但是重要的任務(wù)。引入多個(gè)不同的數(shù)據(jù)庫(kù)，也意味著對(duì)系統(tǒng)管理維護(hù)的復(fù)雜度和成本提高了很多。

? ? ? 這種情況下可能需要比較有資源的公司或者團(tuán)隊(duì)才可以使用。這也解釋了這個(gè)模式為何在大型互聯(lián)網(wǎng)公司得到較多的采用與推廣。

? ? ? 針對(duì)于其他小型規(guī)模的用戶，或者是缺乏足夠掌握各種新型技術(shù)人才的公司來說，另一種更為可行的模式可能是多模數(shù)據(jù)庫(kù)(Multi-model)。如上圖右側(cè)所示，多模數(shù)據(jù)庫(kù)的特征是:

• 依然是一庫(kù)一服務(wù)(為一個(gè)服務(wù)部署一個(gè)單獨(dú)的數(shù)據(jù)庫(kù))。

• 但是使用的是同一種類型，支持多種場(chǎng)景的數(shù)據(jù)庫(kù)，如 NoSQL 中間為功能最全面的 MongoDB。

• 雖然是多實(shí)例，但是只需維護(hù)一種類型的數(shù)據(jù)庫(kù)，管理上和人員配備上都較為簡(jiǎn)單。

? ? ? 如果你在開發(fā)的應(yīng)用是一款企業(yè)級(jí)產(chǎn)品，會(huì)交付到客戶環(huán)境部署安裝，則運(yùn)維管理的簡(jiǎn)單性將在技術(shù)選型中占據(jù)非常重要的一個(gè)比重，無疑這種情況下多模數(shù)據(jù)庫(kù)更加適用。

微服務(wù)擴(kuò)展你的數(shù)據(jù)

? ? ? 微服務(wù)架構(gòu)的一大裨益是其靈活的擴(kuò)展性。以上面的 Snapchat 為例，如果需要采集或處理的數(shù)據(jù)量快速增長(zhǎng)，在我們?cè)黾討?yīng)用服務(wù)實(shí)例的同時(shí)，支撐數(shù)據(jù)存儲(chǔ)的模塊也要相應(yīng)擴(kuò)充。

? ? ? AFK Partners 在他們的 Scale Cube 一文里對(duì)性能擴(kuò)展提出了這樣的觀點(diǎn)，要設(shè)計(jì)一個(gè)真正意義上的可擴(kuò)展系統(tǒng)，我們必須考慮3個(gè)維度，如上圖所示:

• X 軸，系統(tǒng)復(fù)制(橫向擴(kuò)展)

• Y 軸，非重疊功能的拆分(微服務(wù))

• Z 軸，數(shù)據(jù)的分區(qū)(Sharding)

? ? ? 一個(gè)好的數(shù)據(jù)架構(gòu)，在微服務(wù)體系內(nèi)，應(yīng)該具有同樣的可擴(kuò)展、易擴(kuò)展性質(zhì)，從而不給微服務(wù)架構(gòu)拖后腿。關(guān)于數(shù)據(jù)分區(qū)擴(kuò)展有兩種做法:

• 應(yīng)用數(shù)據(jù)分區(qū)

• 數(shù)據(jù)庫(kù)分區(qū)

? ? ? 應(yīng)用數(shù)據(jù)分區(qū)，顧名思義，就是在應(yīng)用端對(duì)數(shù)據(jù)的存儲(chǔ)進(jìn)行分區(qū)管理。比如說，一個(gè)社交應(yīng)用可以按國(guó)家或地區(qū)為界把用戶的數(shù)據(jù)分發(fā)到不同數(shù)據(jù)庫(kù)實(shí)例里面。這樣的話每個(gè)數(shù)據(jù)庫(kù)實(shí)例只需要存儲(chǔ)一部分?jǐn)?shù)據(jù)，從而實(shí)現(xiàn)海量的數(shù)據(jù)管理能力。

? ? ? 數(shù)據(jù)庫(kù)分區(qū)，就是由數(shù)據(jù)庫(kù)的路由節(jié)點(diǎn)來完成數(shù)據(jù)分區(qū)的任務(wù)。數(shù)據(jù)庫(kù)分區(qū)的優(yōu)勢(shì)是顯然的，它對(duì)應(yīng)用透明、擴(kuò)展快速、無須下線等。如果你的應(yīng)用有潛在擴(kuò)充的需求，選擇一個(gè)能夠自動(dòng)擴(kuò)展的分布式數(shù)據(jù)庫(kù)是一個(gè)比較明智的選擇。

動(dòng)態(tài)模式支持及快速開發(fā)能力

? ? ? 這是一個(gè)很多架構(gòu)師可能會(huì)忽略，但是非常重要的關(guān)注點(diǎn)。我們?cè)诘介_發(fā) DevOps 微服務(wù)上的很多努力，都是為了快速開發(fā)，快速上線，以及快速響應(yīng)變化的需求。

? ? ? 從數(shù)據(jù)架構(gòu)師的角度來看，如何不成為在這個(gè)快速開發(fā)方法模式中的一個(gè)瓶頸，有一個(gè)很重要的環(huán)節(jié)就是是否有一個(gè)能夠及時(shí)響應(yīng)變化的數(shù)據(jù)模型。

? ? ? 傳統(tǒng)的數(shù)據(jù)庫(kù)都是強(qiáng)模式，需要對(duì) Schema 進(jìn)行清晰定義, 在需求修改導(dǎo)致模型修改的時(shí)候需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行模式升級(jí)，是一個(gè)需要下線、耗時(shí)并且是高成本的運(yùn)維操作。

? ? ? 在新一代的 NoSQL 數(shù)據(jù)庫(kù)產(chǎn)生之前，我們并不需要考慮這個(gè)問題，但是以 MongoDB、Cassandra 等為代表的 NoSQL 代表的是靈活建模。

? ? ? 動(dòng)態(tài)支持模式變化的特征使得它們成為敏捷開發(fā)和微服務(wù)體系內(nèi)一個(gè)有力的競(jìng)爭(zhēng)者，在選型的時(shí)候也是一個(gè)重要的考量因素之一。我們說一庫(kù)一服的架構(gòu)使得對(duì)一個(gè)服務(wù)的數(shù)據(jù)庫(kù)模式修改不會(huì)影響到其他服務(wù)。

? ? ? 但是如果使用一個(gè)動(dòng)態(tài)模式(有時(shí)候有人會(huì)說無模式)的數(shù)據(jù)庫(kù)，則在該服務(wù)本身模式修改的時(shí)候也可以最小化運(yùn)維成本。

一個(gè)適合微服務(wù)架構(gòu)的數(shù)據(jù)庫(kù)

? ? ? 紅杉資本的合伙人 Matt Miller 是公認(rèn)的微服務(wù)技術(shù)領(lǐng)域?qū)＜?。他廣被傳播的“微服務(wù)生態(tài)圖”詳盡的列出了微服務(wù)架構(gòu)的相關(guān)技術(shù)棧。在這里他推薦了 MongoDB 作為主要的數(shù)據(jù)管理方案。

? ? ? MongoDB 是一個(gè)分布式文檔型數(shù)據(jù)庫(kù)，它有以下特性使它非常適合于微服務(wù)架構(gòu)，其主要特點(diǎn)包括:?多模數(shù)據(jù)庫(kù)(Multi-model)、原生 JSON 數(shù)據(jù)結(jié)構(gòu)API、動(dòng)態(tài)模式、無模式(Dynamic schema)、數(shù)據(jù)變化流(Change Stream)、橫向擴(kuò)展能力(Sharding)。

多模數(shù)據(jù)庫(kù)

? ? ? MongoDB 從 3.4 版本起在多模數(shù)據(jù)庫(kù)場(chǎng)景上提供了不少功能模塊，比如說，使用聚合框架?，F(xiàn)在開發(fā)者可以使用:

• $graphLookup 來實(shí)現(xiàn)類似于圖數(shù)據(jù)庫(kù)的查詢。

• $facet 來實(shí)現(xiàn)分面搜索。

• 內(nèi)存引擎功能，用于支持類似于 Redis 的高速緩存。

• 全文檢索，用于實(shí)現(xiàn)搜索類型場(chǎng)景。

動(dòng)態(tài)模式

? ? ? 這一點(diǎn)一直是 MongoDB 獲得開發(fā)者青睞的主要原因之一。MongoDB 無須顯式的定義數(shù)據(jù)模式即可讓你開始往數(shù)據(jù)庫(kù)寫入。

? ? ? 當(dāng)數(shù)據(jù)模型有變化時(shí)候，比如說在迭代式開發(fā)中非常常見的就是增加一些字段，MongoDB 數(shù)據(jù)庫(kù)不需要對(duì)其進(jìn)行修改 Schema 操作，而是可以直接在同一個(gè)集合(表)里直接寫入新版本的文檔。這個(gè)對(duì)于需要實(shí)現(xiàn)快速迭代，快速交付的微服務(wù)應(yīng)用開發(fā)是一個(gè)非常重要的特性。

數(shù)據(jù)變化流

? ? ? 微服務(wù)架構(gòu)中由于其分布特性，傳統(tǒng)的強(qiáng)事務(wù)機(jī)制不再適用。數(shù)據(jù)的一致性一般需要通過一些基于 Event Sourcing 或者事件驅(qū)動(dòng)模型的解決方案。Mongo DB 3.6 版本推出的數(shù)據(jù)更改流，可以用來實(shí)現(xiàn)一個(gè)類似于 Kafak 一樣的 Message Queue，為各個(gè)微服務(wù)間的數(shù)據(jù)協(xié)調(diào)提供一個(gè)簡(jiǎn)單易用的線程方案。

橫向擴(kuò)展能力

? ? ? MongoDB 一向以其強(qiáng)大的橫向擴(kuò)展能力著稱。不少 MongoDB 用戶遷移的主要原因就是使用 MongoDB 的 Sharding 技術(shù)可以突破關(guān)系型數(shù)據(jù)庫(kù)在數(shù)據(jù)量和性能上的瓶頸。

? ? ? MongoDB 的 Sharding 有幾個(gè)特征使得其非常適合微服務(wù)架構(gòu)使用:

• 彈性擴(kuò)展：可以擴(kuò)容也可以縮容。

• 無縫擴(kuò)展：無須停機(jī)，就可在線擴(kuò)容。

• 自動(dòng)均衡：無須應(yīng)用參與即可實(shí)現(xiàn)數(shù)據(jù)的自動(dòng)均衡，完全透明。一個(gè)基于 MongoDB 的微服務(wù)參考架構(gòu)圖。

  
  

作者：唐建法

出處：Mongoing中文社區(qū)

總結(jié)

以上是生活随笔為你收集整理的一文详解微服务架构的数据设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。