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

1、 詳解微服務(wù)架構(gòu)的數(shù)據(jù)設(shè)計(jì) 微服務(wù)是一個(gè)軟件架構(gòu)模式，對(duì)微服務(wù)的討論大多集中在容器或其他技術(shù)是否能很好的實(shí)施微服務(wù)這些方面。 本文將從以下幾個(gè)角度來(lái)和大家分享在微服務(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)模式，通過(guò)開(kāi)發(fā)一系列的小型服務(wù)的方式來(lái)實(shí)現(xiàn)一個(gè)應(yīng)用。每一個(gè)這樣的小服務(wù)通常都是運(yùn)行在自己的進(jìn)程里面，并且通過(guò)輕量級(jí)的HTTP API 方式進(jìn)行通訊。 這些服務(wù)通常會(huì)以業(yè)務(wù)模塊為界限，能夠

2、被單獨(dú)開(kāi)發(fā)部署，往往都會(huì)用自動(dòng)化的部署工具來(lái)進(jìn)行產(chǎn)品的發(fā)布。通過(guò)使用微服務(wù)方法，大公司可以更快推出新產(chǎn)品和服務(wù)，使得開(kāi)發(fā)團(tuán)隊(duì)與業(yè)務(wù)目標(biāo)保持一致。微服務(wù)的優(yōu)勢(shì) 微服務(wù)方法體現(xiàn)出許多優(yōu)勢(shì)，包括更快的上線(xiàn)時(shí)間、靈活性、彈性、一致性以及相對(duì)更低的成本。更快的上線(xiàn)時(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ò)展。 使用

3、微服務(wù)，只需要縮放需要額外性能的組件或功能?？梢酝ㄟ^(guò)部署更多微服務(wù)實(shí)例來(lái)擴(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ī)模較小，但是跨部門(mén)(如一般涵蓋Ops、Dev、QA)，并專(zhuān)注于整個(gè)應(yīng)用程序的單個(gè)組件。 通過(guò)提供對(duì)個(gè)人服務(wù)的所有權(quán)，而不是功

4、能區(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) 讓我們通過(guò)一個(gè)例子來(lái)了解微服務(wù)架構(gòu)的技術(shù)特點(diǎn)。聯(lián)邦銀行的架構(gòu)師 Jonnathan 非常不喜歡他的產(chǎn)品經(jīng)理 Mandy，因?yàn)樗X(jué)得 Mandy 永遠(yuǎn)有無(wú)窮無(wú)盡的想法要實(shí)現(xiàn)，搞得他成天就在不斷地修改代碼。 但是 Mandy 是老板的紅人，而且用戶(hù)對(duì)產(chǎn)品的反響也不錯(cuò)，所以很多時(shí)候他只能默默的服從。這一天 Mandy 又成功的說(shuō)服了老板要在他們的客戶(hù)體驗(yàn)提升項(xiàng)目中增加輿情分析和 AI 客戶(hù)服務(wù)模塊，希望通過(guò)對(duì)社交媒體上有關(guān)聯(lián)邦銀行的所有評(píng)論進(jìn)行實(shí)時(shí)

5、的監(jiān)控和分析來(lái)及時(shí)發(fā)現(xiàn)聯(lián)邦銀行的產(chǎn)品反饋或者用戶(hù)體驗(yàn)問(wèn)題。 Jonnathan已經(jīng)預(yù)感到了這樣前所未有的應(yīng)用場(chǎng)景，會(huì)有太多的未知和太多的改變，于是這次決定嘗試使用 Microservices 來(lái)構(gòu)建這個(gè)應(yīng)用。這個(gè)是 Jonnathan 設(shè)計(jì)的架構(gòu)，系統(tǒng)要求對(duì)客戶(hù)的社交賬號(hào)，如 Facebook、Twitter、Google+ 及 Snapchat 公開(kāi)的信息及評(píng)論進(jìn)行收集，并在某些合適的時(shí)候使用 AI 技術(shù)直接和用戶(hù)通過(guò)社交工具進(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è) Aggr

6、egate Service 把 4 個(gè)類(lèi)似功能的微服務(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)上線(xiàn)一段時(shí)間后，Mandy 說(shuō) Google+ 上面幾乎沒(méi)有什么活動(dòng)，不值得繼續(xù)維護(hù)這樣的一套系統(tǒng)。Jonnathan 這次毫無(wú)抱怨，直接把負(fù)責(zé) Google+ 的容器停了，沒(méi)有需要任何代碼改動(dòng)，甚至完全沒(méi)有需要對(duì)整個(gè)系統(tǒng)進(jìn)行停機(jī)。 剛下線(xiàn) Google+，Mandy 又來(lái)提需求說(shuō)最近合并了另一家銀行，客戶(hù)很多使用 Whatsapp。二話(huà)不說(shuō)，Jonnathan 直接上了一個(gè)新

7、的模塊來(lái)處理 Whatsapp ，如下圖。 又過(guò)了一段時(shí)間，這一次是他自己要對(duì)系統(tǒng)做調(diào)整了，原來(lái) Snapchat 最近大火，他部署的系統(tǒng)頻受壓力，性能下降。為了解決這個(gè)問(wèn)題，Jonnathan 果斷增加了額外 2 臺(tái)容器來(lá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ù)通常專(zhuān)注于特定的離散目標(biāo)或功能，并沿著業(yè)務(wù)邊界解耦。按業(yè)務(wù)界限分離服務(wù)可讓團(tuán)隊(duì)專(zhuān)注于正確的目標(biāo)，并確保服務(wù)之間的自主

8、性。 每項(xiàng)服務(wù)都是獨(dú)立開(kāi)發(fā)，測(cè)試和部署的，服務(wù)通常是作為獨(dú)立的進(jìn)程或軟件容器分開(kāi)的，通過(guò)網(wǎng)絡(luò)和商定的 API 進(jìn)行通信，盡管在某些情況下，網(wǎng)絡(luò)可能在本地。通常部署相同微服務(wù)的多個(gè)實(shí)例，從而提供冗余和可擴(kuò)展性。輕量級(jí) API 微服務(wù)之間的通信要使用輕量級(jí) API，如 HTTP RESTful API。這樣可以使得服務(wù)對(duì) API 通信方案的依賴(lài)減到最小。 復(fù)雜的通信處理要在服務(wù)端進(jìn)行，而不是像 ESB 或者 Data Pipeline 處理總線(xiàn)那樣在數(shù)據(jù)傳輸過(guò)程中引入非常多的邏輯，導(dǎo)致微服務(wù)模塊緊緊的綁定在這個(gè)數(shù)據(jù)管道上。持續(xù)發(fā)布 微服務(wù)架構(gòu)帶來(lái)的一個(gè)非常顯著的負(fù)面性就是眾多實(shí)例的測(cè)試發(fā)布及管理。

9、傳統(tǒng)應(yīng)用雖然開(kāi)發(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 方法來(lái)支撐。數(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èn)題。下面我們就著重來(lái)討論微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計(jì)的

10、一些考量因素。微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計(jì) 從來(lái)沒(méi)有一個(gè) one-size-fits-all 的架構(gòu)，所以在微服務(wù)架構(gòu)下面，我們需要了解的，一樣是幾個(gè)關(guān)鍵的架構(gòu)考量點(diǎn)。然后針對(duì)自己的實(shí)際應(yīng)用，選擇哪些考量點(diǎn)是更加重要的。 這篇文章的目的，主要就是跟大家來(lái)討論從哪幾個(gè)角度著手，來(lái)設(shè)計(jì)一個(gè)符合微服務(wù)架構(gòu)原則的數(shù)據(jù)架構(gòu)。比如說(shuō)，我們可以從一系列的問(wèn)題來(lái)開(kāi)始這個(gè)討論。這么多微服務(wù)之間，我是否可以用一個(gè)數(shù)據(jù)庫(kù)，還是多個(gè)數(shù)據(jù)庫(kù)來(lái)支持多個(gè)微服務(wù)？如果是多個(gè)數(shù)據(jù)庫(kù)，我是否為每一個(gè)微服務(wù)挑選一個(gè)最合適的數(shù)據(jù)庫(kù)，還是選擇同一種類(lèi)型的數(shù)據(jù)庫(kù)？我如何在微服務(wù)架構(gòu)下擴(kuò)展我的數(shù)據(jù)庫(kù)？當(dāng)一個(gè)我依賴(lài)的服務(wù)需要修改數(shù)據(jù)庫(kù) Schem

11、a 的時(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ù)多服 無(wú)論是單體應(yīng)用，還是微服務(wù)應(yīng)用，有一點(diǎn)是肯定的：應(yīng)用的各個(gè)模塊之間都需要進(jìn)行較為頻繁的通信，通過(guò)一起協(xié)同合作，來(lái)實(shí)現(xiàn)應(yīng)用的整體價(jià)值。 在單體應(yīng)用中，這種通信是通過(guò)方法調(diào)用來(lái)完成的。在微服務(wù)中，則通過(guò) API 調(diào)用來(lái)完成。這些模塊或者服務(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ù)模塊，

12、后面共享一個(gè)數(shù)據(jù)庫(kù)，簡(jiǎn)稱(chēng)一庫(kù)多服務(wù)。 這種架構(gòu)模式通常會(huì)被認(rèn)為是微服務(wù)架構(gòu)下的反范式，它的問(wèn)題在于:單點(diǎn)故障：一個(gè)數(shù)據(jù)庫(kù)倒下，整批服務(wù)全部停止。何來(lái)的服務(wù)獨(dú)立性？數(shù)據(jù)在同一個(gè)地方，會(huì)給貪圖方便的開(kāi)發(fā)或者 DBA 工程師編寫(xiě)很多數(shù)據(jù)間高度依賴(lài)的程序或者工具。無(wú)法針對(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)，它滿(mǎn)足每一個(gè)服務(wù)是獨(dú)立開(kāi)發(fā)、獨(dú)立部署、獨(dú)立擴(kuò)展的特性。 當(dāng)需要對(duì)一個(gè)服務(wù)進(jìn)行升級(jí)或者數(shù)據(jù)架構(gòu)改動(dòng)的時(shí)

13、候，不會(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ù)提供最好的工具。比如說(shuō)，如果我希望提供一個(gè)高并發(fā)低延遲的共享用戶(hù)會(huì)話(huà)方案(Shared Session Storage)， Redis 可能是一個(gè)非常理想的選擇。 如果我是在實(shí)現(xiàn)一個(gè)產(chǎn)品目錄，涉及到大量不定結(jié)構(gòu)的商品數(shù)據(jù)及屬性的建模管理，我可能會(huì)采用模式靈活，動(dòng)態(tài) S

14、chema 的 MongoDB 來(lái)作為我的數(shù)據(jù)庫(kù)解決方案。如果我希望支持非常強(qiáng)大的全文搜索，ElasticSearch 則是行業(yè)中的佼佼者。 微服務(wù)的功能分塊獨(dú)立部署為這種架構(gòu)模式提供了非常好的基礎(chǔ)，如上圖左側(cè)所示就是個(gè)典型的混合持久化的案例:混合持久化：Polyglot Persistence多模數(shù)據(jù)庫(kù)：Multi- model Database 當(dāng)然，有句話(huà)說(shuō)的是架構(gòu)師的工作就是每天做不斷的取舍(Trade Off)，因?yàn)檫x擇往往是讓人很糾結(jié)?；旌铣志没膬?yōu)勢(shì)很明顯，可以讓每個(gè)單獨(dú)的服務(wù)使用到最佳的工具和技術(shù)。 但是它的弊端也是不容忽視：部署、監(jiān)控、備份、升級(jí)等數(shù)據(jù)庫(kù)管理工作從來(lái)都是一件困

15、難但是重要的任務(wù)。引入多個(gè)不同的數(shù)據(jù)庫(kù)，也意味著對(duì)系統(tǒng)管理維護(hù)的復(fù)雜度和成本提高了很多。 這種情況下可能需要比較有資源的公司或者團(tuán)隊(duì)才可以使用。這也解釋了這個(gè)模式為何在大型互聯(lián)網(wǎng)公司得到較多的采用與推廣。 針對(duì)于其他小型規(guī)模的用戶(hù)，或者是缺乏足夠掌握各種新型技術(shù)人才的公司來(lái)說(shuō)，另一種更為可行的模式可能是多模數(shù)據(jù)庫(kù)(Multi-model)。如上圖右側(cè)所示，多模數(shù)據(jù)庫(kù)的特征是:依然是一庫(kù)一服務(wù)(為一個(gè)服務(wù)部署一個(gè)單獨(dú)的數(shù)據(jù)庫(kù))。但是使用的是同一種類(lèi)型，支持多種場(chǎng)景的數(shù)據(jù)庫(kù)，如 NoSQL 中間為功能最全面的 MongoDB。雖然是多實(shí)例，但是只需維護(hù)一種類(lèi)型的數(shù)據(jù)庫(kù)，管理上和人員配備上都較為簡(jiǎn)單

16、。 如果你在開(kāi)發(fā)的應(yīng)用是一款企業(yè)級(jí)產(chǎn)品，會(huì)交付到客戶(hù)環(huán)境部署安裝，則運(yùn)維管理的簡(jiǎn)單性將在技術(shù)選型中占據(jù)非常重要的一個(gè)比重，無(wú)疑這種情況下多模數(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ò)展提出了這樣的觀(guān)點(diǎn)，要設(shè)計(jì)一個(gè)真正意義上的可擴(kuò)展系統(tǒng)，我們必須考慮3個(gè)維度，如上圖所示:X 軸，系統(tǒng)復(fù)制(橫向擴(kuò)展)Y 軸，非重疊功能的拆分(微服務(wù))Z 軸，數(shù)據(jù)的分區(qū)(Shard

17、ing) 一個(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ū)管理。比如說(shuō)，一個(gè)社交應(yīng)用可以按國(guó)家或地區(qū)為界把用戶(hù)的數(shù)據(jù)分發(fā)到不同數(shù)據(jù)庫(kù)實(shí)例里面。這樣的話(huà)每個(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)來(lái)完成數(shù)據(jù)分區(qū)的任務(wù)。數(shù)據(jù)庫(kù)分區(qū)的優(yōu)勢(shì)是顯然的，它對(duì)應(yīng)用透明、擴(kuò)展快速、無(wú)須下線(xiàn)等。如果你的應(yīng)用有潛在擴(kuò)充的需求，選擇一個(gè)能夠自動(dòng)擴(kuò)展的分布式數(shù)據(jù)庫(kù)是一個(gè)比較明智的選擇。動(dòng)態(tài)模式支持及快速開(kāi)發(fā)能力

18、 這是一個(gè)很多架構(gòu)師可能會(huì)忽略，但是非常重要的關(guān)注點(diǎn)。我們?cè)诘介_(kāi)發(fā) DevOps 微服務(wù)上的很多努力，都是為了快速開(kāi)發(fā)，快速上線(xiàn)，以及快速響應(yīng)變化的需求。 從數(shù)據(jù)架構(gòu)師的角度來(lái)看，如何不成為在這個(gè)快速開(kāi)發(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è)需要下線(xiàn)、耗時(shí)并且是高成本的運(yùn)維操作。 在新一代的 NoSQL 數(shù)據(jù)庫(kù)產(chǎn)生之前，我們并不需要考慮這個(gè)問(wèn)題，但是以 MongoDB、Cassandra 等為代表的 NoSQL 代表的是靈活

19、建模。 動(dòng)態(tài)支持模式變化的特征使得它們成為敏捷開(kāi)發(fā)和微服務(wù)體系內(nèi)一個(gè)有力的競(jìng)爭(zhēng)者，在選型的時(shí)候也是一個(gè)重要的考量因素之一。我們說(shuō)一庫(kù)一服的架構(gòu)使得對(duì)一個(gè)服務(wù)的數(shù)據(jù)庫(kù)模式修改不會(huì)影響到其他服務(wù)。 但是如果使用一個(gè)動(dòng)態(tài)模式(有時(shí)候有人會(huì)說(shuō)無(wú)模式)的數(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)模式、無(wú)模式(Dynamic schema)、數(shù)據(jù)變化流(Change Stream)、橫向擴(kuò)展能力(Sharding)。多模數(shù)據(jù)庫(kù) MongoDB 從 3.4 版本起在多模數(shù)據(jù)庫(kù)場(chǎng)景上提供了不少功能模塊，比如說(shuō)，使用聚合框架?，F(xiàn)在開(kāi)發(fā)者可以使用:$graphLookup 來(lái)實(shí)現(xiàn)