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

1、 詳解微服務(wù)架構(gòu)的數(shù)據(jù)設(shè)計(jì) 微服務(wù)是一個軟件架構(gòu)模式，對微服務(wù)的討論大多集中在容器或其他技術(shù)是否能很好的實(shí)施微服務(wù)這些方面。 本文將從以下幾個角度來和大家分享在微服務(wù)架構(gòu)下進(jìn)行數(shù)據(jù)設(shè)計(jì)需要關(guān)注的地方，旨在幫助大家在構(gòu)建微服務(wù)架構(gòu)時，提供一個數(shù)據(jù)方面的視角:什么是微服務(wù)微服務(wù)的優(yōu)勢及架構(gòu)特點(diǎn)微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計(jì)一個適合微服務(wù)架構(gòu)的數(shù)據(jù)庫什么是微服務(wù) 按照 Martin Fowler 的定義，微服務(wù)是一個軟件架構(gòu)模式，通過開發(fā)一系列的小型服務(wù)的方式來實(shí)現(xiàn)一個應(yīng)用。每一個這樣的小服務(wù)通常都是運(yùn)行在自己的進(jìn)程里面，并且通過輕量級的HTTP API 方式進(jìn)行通訊。 這些服務(wù)通常會以業(yè)務(wù)模塊為界限，能夠

2、被單獨(dú)開發(fā)部署，往往都會用自動化的部署工具來進(jìn)行產(chǎn)品的發(fā)布。通過使用微服務(wù)方法，大公司可以更快推出新產(chǎn)品和服務(wù)，使得開發(fā)團(tuán)隊(duì)與業(yè)務(wù)目標(biāo)保持一致。微服務(wù)的優(yōu)勢 微服務(wù)方法體現(xiàn)出許多優(yōu)勢，包括更快的上線時間、靈活性、彈性、一致性以及相對更低的成本。更快的上線時間 實(shí)施微服務(wù)架構(gòu)可以使組織更快地將應(yīng)用程序推向市場。對整體應(yīng)用程序的更改(即使很小)需要重新部署整個應(yīng)用程序堆棧，從而引入風(fēng)險和復(fù)雜性。 相反，服務(wù)的更新可以立即提交、測試和部署，對個別服務(wù)的更改不會影響系統(tǒng)的其他部分。更好的靈活性和可擴(kuò)展性 微服務(wù)方法在擴(kuò)展應(yīng)用程序時也提供了靈活性。單片應(yīng)用程序要求整個系統(tǒng)(及其所有功能)同時擴(kuò)展。 使用

3、微服務(wù)，只需要縮放需要額外性能的組件或功能。可以通過部署更多微服務(wù)實(shí)例來擴(kuò)展服務(wù)范圍，從而實(shí)現(xiàn)更有效的容量規(guī)劃并降低軟件許可成本，從而降低總體擁有成本。彈性 使用單體應(yīng)用程序時，組件的故障可能會危及整個應(yīng)用程序。在微服務(wù)中，每項(xiàng)服務(wù)都是隔離的，以防止級聯(lián)失敗導(dǎo)致整個系統(tǒng)崩潰。如果單個微服務(wù)的所有實(shí)例均失敗，則整體服務(wù)可能會降級，但其他組件仍可提供有價值的服務(wù)。更容易的規(guī)模化 微服務(wù)使技術(shù)團(tuán)隊(duì)能夠與組織需求保持一致，并且可以調(diào)整團(tuán)隊(duì)的大小以匹配所需的任務(wù)。通常，微服務(wù)團(tuán)隊(duì)規(guī)模較小，但是跨部門(如一般涵蓋Ops、Dev、QA)，并專注于整個應(yīng)用程序的單個組件。 通過提供對個人服務(wù)的所有權(quán)，而不是功

4、能區(qū)域，微服務(wù)還可以打破團(tuán)隊(duì)之間的孤島，并改善協(xié)作。這種方法對于分布式和遠(yuǎn)程團(tuán)隊(duì)尤其強(qiáng)大。 例如，不同地點(diǎn)的團(tuán)隊(duì)可以獨(dú)立發(fā)布和部署功能。微服務(wù)的技術(shù)特點(diǎn) 讓我們通過一個例子來了解微服務(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 是老板的紅人，而且用戶對產(chǎn)品的反響也不錯，所以很多時候他只能默默的服從。這一天 Mandy 又成功的說服了老板要在他們的客戶體驗(yàn)提升項(xiàng)目中增加輿情分析和 AI 客戶服務(wù)模塊，希望通過對社交媒體上有關(guān)聯(lián)邦銀行的所有評論進(jìn)行實(shí)時

5、的監(jiān)控和分析來及時發(fā)現(xiàn)聯(lián)邦銀行的產(chǎn)品反饋或者用戶體驗(yàn)問題。 Jonnathan已經(jīng)預(yù)感到了這樣前所未有的應(yīng)用場景，會有太多的未知和太多的改變，于是這次決定嘗試使用 Microservices 來構(gòu)建這個應(yīng)用。這個是 Jonnathan 設(shè)計(jì)的架構(gòu)，系統(tǒng)要求對客戶的社交賬號，如 Facebook、Twitter、Google+ 及 Snapchat 公開的信息及評論進(jìn)行收集，并在某些合適的時候使用 AI 技術(shù)直接和用戶通過社交工具進(jìn)行互動。 在上圖這個架構(gòu)里面，Jonnathan 把4個不同社交媒體的數(shù)據(jù)采集和交互用 4 個獨(dú)立的模塊進(jìn)行實(shí)現(xiàn)。并用一個 Feed Merge 服務(wù)，一個 Aggr

6、egate Service 把 4 個類似功能的微服務(wù)模塊的數(shù)據(jù)和功能進(jìn)行整合，提供給分析平臺使用。 這里面每一個服務(wù)按照微服務(wù)的架構(gòu)，每一個都是單獨(dú)部署，在一個獨(dú)立的容器內(nèi)執(zhí)行，并使用自己的一個數(shù)據(jù)庫。 果不其然，系統(tǒng)上線一段時間后，Mandy 說 Google+ 上面幾乎沒有什么活動，不值得繼續(xù)維護(hù)這樣的一套系統(tǒng)。Jonnathan 這次毫無抱怨，直接把負(fù)責(zé) Google+ 的容器停了，沒有需要任何代碼改動，甚至完全沒有需要對整個系統(tǒng)進(jìn)行停機(jī)。 剛下線 Google+，Mandy 又來提需求說最近合并了另一家銀行，客戶很多使用 Whatsapp。二話不說，Jonnathan 直接上了一個新

7、的模塊來處理 Whatsapp ，如下圖。 又過了一段時間，這一次是他自己要對系統(tǒng)做調(diào)整了，原來 Snapchat 最近大火，他部署的系統(tǒng)頻受壓力，性能下降。為了解決這個問題，Jonnathan 果斷增加了額外 2 臺容器來同時支撐 Snapchat 信息的采集和處理。 感謝微服務(wù)架構(gòu)，Jonnathan 在一系列的產(chǎn)品需求變化以及系統(tǒng)擴(kuò)容需求下，可以從容應(yīng)付。要實(shí)現(xiàn)微服務(wù)架構(gòu)，需要你銘記以下幾個微服務(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ù)之間的自主

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

9、傳統(tǒng)應(yīng)用雖然開發(fā)復(fù)雜，但是部署和運(yùn)維相對比較集中，一臺數(shù)據(jù)庫，2-4 個應(yīng)用服務(wù)器就差不多了。但是微服務(wù)架構(gòu)下單獨(dú)服務(wù)的數(shù)量輕則 10-20，多則上百個，所以微服務(wù)架構(gòu)一般需要配套的 CI/CD 方法來支撐。數(shù)據(jù)與治理 數(shù)據(jù)的管理在微服務(wù)架構(gòu)下也是和傳統(tǒng)單體有很大的不同考量。大部分時候我們希望數(shù)據(jù)就和服務(wù)一樣，要有充分的獨(dú)立性，可以和某個服務(wù)一起部署，一起擴(kuò)展，或者一起重構(gòu)。 這通常意味著我們可能要在一個微服務(wù)架構(gòu)應(yīng)用內(nèi)使用多個數(shù)據(jù)庫實(shí)例。但是同樣需要考慮到數(shù)據(jù)分布在多實(shí)例之間以后，往往還需要一些冗余，以及如何保持這些數(shù)據(jù)在這些系統(tǒng)中的一致性等問題。下面我們就著重來討論微服務(wù)架構(gòu)下的數(shù)據(jù)設(shè)計(jì)的

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

11、a 的時候，是否會影響到我？當(dāng)微服務(wù)應(yīng)用不斷衍變的時候，我的數(shù)據(jù)庫是否可以快速的響應(yīng)應(yīng)用需求變化？以上這些就是我們在微服務(wù)數(shù)據(jù)架構(gòu)時候要關(guān)注的地方。一庫一服還是一庫多服 無論是單體應(yīng)用，還是微服務(wù)應(yīng)用，有一點(diǎn)是肯定的：應(yīng)用的各個模塊之間都需要進(jìn)行較為頻繁的通信，通過一起協(xié)同合作，來實(shí)現(xiàn)應(yīng)用的整體價值。 在單體應(yīng)用中，這種通信是通過方法調(diào)用來完成的。在微服務(wù)中，則通過 API 調(diào)用來完成。這些模塊或者服務(wù)間調(diào)用，大部分時候是為了共享數(shù)據(jù)。 共享數(shù)據(jù)最賤的方式當(dāng)然就是采用一種共享數(shù)據(jù)庫的模式，也就是單體應(yīng)用常用的方式。應(yīng)用可以有多個系統(tǒng)模塊，但一般都是只有一個數(shù)據(jù)庫。如下圖左邊，3 個微服務(wù)模塊，

12、后面共享一個數(shù)據(jù)庫，簡稱一庫多服務(wù)。 這種架構(gòu)模式通常會被認(rèn)為是微服務(wù)架構(gòu)下的反范式，它的問題在于:單點(diǎn)故障：一個數(shù)據(jù)庫倒下，整批服務(wù)全部停止。何來的服務(wù)獨(dú)立性？數(shù)據(jù)在同一個地方，會給貪圖方便的開發(fā)或者 DBA 工程師編寫很多數(shù)據(jù)間高度依賴的程序或者工具。無法針對某一個服務(wù)進(jìn)行精準(zhǔn)優(yōu)化或擴(kuò)展，如上文所講的 Snapchat 的例子。 所以一般推薦的做法，是為每一個微服務(wù)準(zhǔn)備一個單獨(dú)的數(shù)據(jù)庫，也即一庫一服(Database per Service)模式。如上圖右側(cè)所示。這種模式更加適合微服務(wù)架構(gòu)，它滿足每一個服務(wù)是獨(dú)立開發(fā)、獨(dú)立部署、獨(dú)立擴(kuò)展的特性。 當(dāng)需要對一個服務(wù)進(jìn)行升級或者數(shù)據(jù)架構(gòu)改動的時

13、候，不會影響到其他的服務(wù)。需要對某個服務(wù)進(jìn)行擴(kuò)展的時候，也可以手術(shù)式的對某一個服務(wù)進(jìn)行局部擴(kuò)容。另外，如果某些服務(wù)對數(shù)據(jù)庫有特殊的需求，這種模式也為下文所講的混合持久化(Polyglot Persistence)提供了可能性?；旌铣志没?vs 多模數(shù)據(jù)庫 混合持久化在大型互聯(lián)網(wǎng)公司是一個比較風(fēng)行的模式。它秉承的原則就是為特別的任務(wù)提供最好的工具。比如說，如果我希望提供一個高并發(fā)低延遲的共享用戶會話方案(Shared Session Storage)， Redis 可能是一個非常理想的選擇。 如果我是在實(shí)現(xiàn)一個產(chǎn)品目錄，涉及到大量不定結(jié)構(gòu)的商品數(shù)據(jù)及屬性的建模管理，我可能會采用模式靈活，動態(tài) S

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

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

16、。 如果你在開發(fā)的應(yīng)用是一款企業(yè)級產(chǎn)品，會交付到客戶環(huán)境部署安裝，則運(yùn)維管理的簡單性將在技術(shù)選型中占據(jù)非常重要的一個比重，無疑這種情況下多模數(shù)據(jù)庫更加適用。微服務(wù)擴(kuò)展你的數(shù)據(jù) 微服務(wù)架構(gòu)的一大裨益是其靈活的擴(kuò)展性。以上面的 Snapchat 為例，如果需要采集或處理的數(shù)據(jù)量快速增長，在我們增加應(yīng)用服務(wù)實(shí)例的同時，支撐數(shù)據(jù)存儲的模塊也要相應(yīng)擴(kuò)充。 AFK Partners 在他們的 Scale Cube 一文里對性能擴(kuò)展提出了這樣的觀點(diǎn)，要設(shè)計(jì)一個真正意義上的可擴(kuò)展系統(tǒng)，我們必須考慮3個維度，如上圖所示:X 軸，系統(tǒng)復(fù)制(橫向擴(kuò)展)Y 軸，非重疊功能的拆分(微服務(wù))Z 軸，數(shù)據(jù)的分區(qū)(Shard

17、ing) 一個好的數(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ù)庫分區(qū) 應(yīng)用數(shù)據(jù)分區(qū)，顧名思義，就是在應(yīng)用端對數(shù)據(jù)的存儲進(jìn)行分區(qū)管理。比如說，一個社交應(yīng)用可以按國家或地區(qū)為界把用戶的數(shù)據(jù)分發(fā)到不同數(shù)據(jù)庫實(shí)例里面。這樣的話每個數(shù)據(jù)庫實(shí)例只需要存儲一部分?jǐn)?shù)據(jù)，從而實(shí)現(xiàn)海量的數(shù)據(jù)管理能力。 數(shù)據(jù)庫分區(qū)，就是由數(shù)據(jù)庫的路由節(jié)點(diǎn)來完成數(shù)據(jù)分區(qū)的任務(wù)。數(shù)據(jù)庫分區(qū)的優(yōu)勢是顯然的，它對應(yīng)用透明、擴(kuò)展快速、無須下線等。如果你的應(yīng)用有潛在擴(kuò)充的需求，選擇一個能夠自動擴(kuò)展的分布式數(shù)據(jù)庫是一個比較明智的選擇。動態(tài)模式支持及快速開發(fā)能力

18、 這是一個很多架構(gòu)師可能會忽略，但是非常重要的關(guān)注點(diǎn)。我們在迭代式開發(fā) DevOps 微服務(wù)上的很多努力，都是為了快速開發(fā)，快速上線，以及快速響應(yīng)變化的需求。 從數(shù)據(jù)架構(gòu)師的角度來看，如何不成為在這個快速開發(fā)方法模式中的一個瓶頸，有一個很重要的環(huán)節(jié)就是是否有一個能夠及時響應(yīng)變化的數(shù)據(jù)模型。 傳統(tǒng)的數(shù)據(jù)庫都是強(qiáng)模式，需要對 Schema 進(jìn)行清晰定義, 在需求修改導(dǎo)致模型修改的時候需要對數(shù)據(jù)庫進(jìn)行模式升級，是一個需要下線、耗時并且是高成本的運(yùn)維操作。 在新一代的 NoSQL 數(shù)據(jù)庫產(chǎn)生之前，我們并不需要考慮這個問題，但是以 MongoDB、Cassandra 等為代表的 NoSQL 代表的是靈活

19、建模。 動態(tài)支持模式變化的特征使得它們成為敏捷開發(fā)和微服務(wù)體系內(nèi)一個有力的競爭者，在選型的時候也是一個重要的考量因素之一。我們說一庫一服的架構(gòu)使得對一個服務(wù)的數(shù)據(jù)庫模式修改不會影響到其他服務(wù)。 但是如果使用一個動態(tài)模式(有時候有人會說無模式)的數(shù)據(jù)庫，則在該服務(wù)本身模式修改的時候也可以最小化運(yùn)維成本。一個適合微服務(wù)架構(gòu)的數(shù)據(jù)庫 紅杉資本的合伙人 Matt Miller 是公認(rèn)的微服務(wù)技術(shù)領(lǐng)域?qū)＜?。他廣被傳播的“微服務(wù)生態(tài)圖”詳盡的列出了微服務(wù)架構(gòu)的相關(guān)技術(shù)棧。在這里他推薦了 MongoDB 作為主要的數(shù)據(jù)管理方案。 MongoDB 是一個分布式文檔型數(shù)據(jù)庫，它有以下特性使它非常適合于微服務(wù)架構(gòu)，其主要特點(diǎn)包括:多模數(shù)據(jù)庫(Multi-model)、原生 JSON 數(shù)據(jù)結(jié)構(gòu)API、動態(tài)模式、無模式(Dynamic schema)、數(shù)據(jù)變化流(Change Stream)、橫向擴(kuò)展能力(Sharding)。多模數(shù)據(jù)庫 MongoDB 從 3.4 版本起在多模數(shù)據(jù)庫場景上提供了不少功能模塊，比如說，使用聚合框架?，F(xiàn)在開發(fā)者可以使用:$graphLookup 來實(shí)現(xiàn)