微服務數(shù)據(jù)管理(譯):每個服務一個數(shù)據(jù)庫模式

場景

假設我們正在使用微服務架構(gòu)模式開發(fā)一個在線商店應用漠趁。大多數(shù)的服務都需要持久化數(shù)據(jù)到某些數(shù)據(jù)庫中扁凛。例如,訂單服務存儲訂單信息闯传,用戶服務存儲用戶信息令漂。

問題

微服務應用中的數(shù)據(jù)庫架構(gòu)是什么樣的?

約束條件

服務必須是松耦合的,這樣才能夠獨立地開發(fā)叠必、部署和擴展這些微服務荚孵。

必須保持某些跨多個服務的業(yè)務事務的不變性。例如纬朝,下訂單用例必須驗證新訂單不會超出用戶信用額度限制收叶。某些業(yè)務事務必須更新由多個服務擁有的數(shù)據(jù)。

某些業(yè)務事務需要查詢由不同服務擁有的數(shù)據(jù)共苛。例如判没,查看可用信用額度用例必須查詢用戶服務來查找信用額度限制以及訂單服務來計算未完成訂單總數(shù)量。

某些查詢必須關聯(lián)由多個服務擁有的數(shù)據(jù)隅茎。例如澄峰,查找屬于特定區(qū)域的用戶以及他們最近一段時間的訂單,需要關聯(lián)用戶和訂單辟犀。

有時候為了擴展俏竞,數(shù)據(jù)庫必須可以被復制和共享。

不同服務有不同的數(shù)據(jù)存儲要求堂竟。對于某些服務魂毁,關系型數(shù)據(jù)庫是最好的選擇。其它服務可能需要NoSQL數(shù)據(jù)庫比如MongoDB(擅長存儲復雜出嘹、非結(jié)構(gòu)化數(shù)據(jù))或Neo4J(能高效地存儲以及查詢圖形數(shù)據(jù))席楚。

解決方案

保持每個微服務的持久化數(shù)據(jù)是私有的并且只能通過該服務的API訪問。下圖展示了該模式的結(jié)構(gòu):

服務的數(shù)據(jù)庫實際上作為該服務實現(xiàn)的一部分税稼。它不能直接地被其它服務訪問烦秩。

保持服務持久化數(shù)據(jù)的私有有一些不同的方式。為每個服務提供一個數(shù)據(jù)庫服務器不是必要郎仆。例如闻镶,如果使用關系型數(shù)據(jù)庫,可以使用下面的三種方式:

Private-tables-per-service —— 每個服務擁有一個必須只能被該服務訪問的表集

Schema-per-service —— 每個服務都有一個私有的數(shù)據(jù)庫schema

Database-server-per-service —— 每個服務都有自己的數(shù)據(jù)庫服務器

Private-tables-per-service和schema-per-service的開銷是最低的丸升。使用schema-per-service比較有吸引力铆农,因為該方式讓所有權比較清楚。某些高吞吐量服務可能需要它們自己的數(shù)據(jù)庫服務器狡耻。

創(chuàng)建一些邊界壁壘來加強模塊化是個好主意墩剖。例如,可以給每個服務分配不同的數(shù)據(jù)庫用戶ID夷狰,并且使用數(shù)據(jù)庫訪問控制機制比如授權岭皂。沒有某種邊界壁壘來實施封裝,開發(fā)人員總會被誘惑去繞過某個服務的API而去直接訪問它的數(shù)據(jù)沼头。

影響

每個服務一個數(shù)據(jù)庫的好處:

有利于確保服務是松耦合的爷绘。某個服務的數(shù)據(jù)庫發(fā)生改變不影響其它服務书劝。

每個服務能夠使用最合適它們需求的數(shù)據(jù)庫類型。例如土至,某個服務處理文本搜索购对,可以使用ElasticSearch。處理社交圖數(shù)據(jù)的服務可以使用Neo4j陶因。

弊端:

實現(xiàn)跨不同服務的事務很復雜骡苞。由于CAP理論,最好避免分布式事務楷扬。此外解幽,很多現(xiàn)代(NoSQL)數(shù)據(jù)庫不支持分布式事務。最好的解決方案是使用Saga模式(事件履歷模式)烘苹。當服務更新數(shù)據(jù)時躲株,服務發(fā)布事件。其它的服務訂閱這些事件并且更新它們的數(shù)據(jù)作為回應镣衡。

目前在多個數(shù)據(jù)庫中實現(xiàn)關聯(lián)查詢是很有挑戰(zhàn)的霜定。

一些解決方案:

API組合 —— 應用處理關聯(lián)而不是數(shù)據(jù)庫捆探。例如站粟,每個服務(或者API網(wǎng)關)可以檢索某個用戶和他的訂單,首先從用戶服務檢索用戶助被,然后查詢訂單服務切诀,返回用戶最近一段時間的訂單。

命令與查詢職責分離(CQRS)—— 維護一個或多個包含不同服務的數(shù)據(jù)的物化視圖(materialized view)丰滑。這些視圖由訂閱事件的服務保有倒庵。例如,通過維護一個關聯(lián)用戶和訂單的視圖擎宝,在線商店能夠執(zhí)行某個查詢?nèi)フ页瞿硞€特定區(qū)域的用戶和他們最近一段時間的訂單绍申。該視圖由訂閱用戶和訂單事件的服務更新顾彰。

管理不同SQL和NoSQL數(shù)據(jù)庫的復雜性

文章來源:Pattern: Database per service

最后編輯于
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末涨享,一起剝皮案震驚了整個濱河市灰伟,隨后出現(xiàn)的幾起案子儒旬,更是在濱河造成了極大的恐慌,老刑警劉巖挡爵,帶你破解...
    沈念sama閱讀 223,126評論 6 520
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件茶鹃,死亡現(xiàn)場離奇詭異涩惑,居然都是意外死亡获雕,警方通過查閱死者的電腦和手機宴偿,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,421評論 3 400
  • 文/潘曉璐 我一進店門李命,熙熙樓的掌柜王于貴愁眉苦臉地迎上來蕉汪,“玉大人,你說我怎么就攤上這事者疤【月恚” “怎么了除秀?”我有些...
    開封第一講書人閱讀 169,941評論 0 366
  • 文/不壞的土叔 我叫張陵,是天一觀的道長寇蚊。 經(jīng)常有香客問我仗岸,道長,這世上最難降的妖魔是什么扒怖? 我笑而不...
    開封第一講書人閱讀 60,294評論 1 300
  • 正文 為了忘掉前任蚂蕴,我火速辦了婚禮,結(jié)果婚禮上骡楼,老公的妹妹穿的比我還像新娘稽鞭。我一直安慰自己,他們只是感情好篮条,可當我...
    茶點故事閱讀 69,295評論 6 398
  • 文/花漫 我一把揭開白布涉茧。 她就那樣靜靜地躺著疹娶,像睡著了一般。 火紅的嫁衣襯著肌膚如雪蚓胸。 梳的紋絲不亂的頭發(fā)上除师,一...
    開封第一講書人閱讀 52,874評論 1 314
  • 那天汛聚,我揣著相機與錄音,去河邊找鬼倚舀。 笑死痕貌,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的超升。 我是一名探鬼主播,決...
    沈念sama閱讀 41,285評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼乾闰,長吁一口氣:“原來是場噩夢啊……” “哼涯肩!你這毒婦竟也來了巢钓?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 40,249評論 0 277
  • 序言:老撾萬榮一對情侶失蹤铅乡,失蹤者是張志新(化名)和其女友劉穎阵幸,沒想到半個月后芽世,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,760評論 1 321
  • 正文 獨居荒郊野嶺守林人離奇死亡荠割,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,840評論 3 343
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了箕宙。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,973評論 1 354
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖陷寝,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情凤跑,我是刑警寧澤仔引,帶...
    沈念sama閱讀 36,631評論 5 351
  • 正文 年R本政府宣布致扯,位于F島的核電站抖僵,受9級特大地震影響缘揪,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜蹈垢,卻給世界環(huán)境...
    茶點故事閱讀 42,315評論 3 336
  • 文/蒙蒙 一曹抬、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧谤民,春花似錦张足、人聲如沸坎藐。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,797評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽疫铜。三九已至块攒,卻和暖如春佃乘,著一層夾襖步出監(jiān)牢的瞬間趣避,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,926評論 1 275
  • 我被黑心中介騙來泰國打工程帕, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留愁拭,地道東北人。 一個月前我還...
    沈念sama閱讀 49,431評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像惜论,于是被迫代替她去往敵國和親馆类。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,982評論 2 361

推薦閱讀更多精彩內(nèi)容