這篇文章主要介紹“數(shù)據(jù)作為微服務(wù)的實(shí)現(xiàn)方法是什么”，在日常操作中，相信很多人在數(shù)據(jù)作為微服務(wù)的實(shí)現(xiàn)方法是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數(shù)據(jù)作為微服務(wù)的實(shí)現(xiàn)方法是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

創(chuàng)新互聯(lián)公司公司2013年成立，先為滄縣等服務(wù)建站，滄縣等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為滄縣企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

1.引言

Microservices(微服務(wù))是新軟件項(xiàng)目中所青睞的架構(gòu)設(shè)計(jì)。隨著從單一系統(tǒng)到分布式系統(tǒng)的演化不僅發(fā)生在應(yīng)用程序空間中，而且發(fā)生在數(shù)據(jù)存儲(chǔ)中，管理數(shù)據(jù)成為最困難的挑戰(zhàn)之一，然而，要從這種類型的方法中獲得最大的收益，需要克服前面的幾個(gè)需求。

在遵循微服務(wù)設(shè)計(jì)指南時(shí)，我們找到一些對數(shù)據(jù)處理的參考。其中一些常見的方向包括:

• 每個(gè)服務(wù)的使用各自的私有數(shù)據(jù)庫實(shí)現(xiàn)松散耦合。

• 擁抱最終一致性。

• 為最終一致性事務(wù)實(shí)現(xiàn)saga pattern。

• 使用Command Query Responsibility Segregation(CQRS)和API組合。

考慮到這一點(diǎn)，當(dāng)將松耦合作為體系架構(gòu)中的一個(gè)基本部分時(shí)，共享數(shù)據(jù)庫現(xiàn)在就變成了一個(gè)反模式，使得事務(wù)和查詢變得更加困難。每個(gè)服務(wù)使用數(shù)據(jù)存儲(chǔ)都需要封裝數(shù)據(jù)，而與體系架構(gòu)的其他域的交互應(yīng)該只發(fā)生在API級(jí)別，這鼓勵(lì)我們隱藏?cái)?shù)據(jù)實(shí)現(xiàn)細(xì)節(jié)。因此，使用諸如Spring Boot這樣的輕量級(jí)框架只是微服務(wù)之旅的第一步。

2.查詢的挑戰(zhàn)

因?yàn)槊總€(gè)服務(wù)都有數(shù)據(jù)存儲(chǔ)，所以我們需要使其可供其他服務(wù)使用，從而成為該域的入口點(diǎn)。由于所有數(shù)據(jù)調(diào)用都發(fā)生在服務(wù)級(jí)別，并且根據(jù)它們的域，當(dāng)需要組合數(shù)據(jù)視圖時(shí)，傳統(tǒng)的table join（表連接）不再是我們在共享數(shù)據(jù)庫實(shí)現(xiàn)中使用的方案。此外，我們無法編寫查詢私有數(shù)據(jù)存儲(chǔ)并聚合數(shù)據(jù)的服務(wù)，因?yàn)樗`反了封裝設(shè)計(jì)。

為了解決前面的挑戰(zhàn)，我們需要回到微服務(wù)體系架構(gòu)中，使用成熟的企業(yè)集成模式(Enterprise Integration Patterns, EIP)，比如 content enrichment(內(nèi)容濃縮)和aggregator( 聚合器)。大多數(shù)時(shí)候，這些模式被重新命名為API組合模式，通常在API網(wǎng)關(guān)之類的組件中實(shí)現(xiàn)。

通常，API組合模式涉及到添加另一個(gè)服務(wù)，該服務(wù)使用所需的信息調(diào)用底層數(shù)據(jù)服務(wù)來組合所需的數(shù)據(jù)視圖。如下圖所示，它將首先查詢客戶服務(wù)的基本信息，然后使用該信息從支付服務(wù)檢索該客戶的歷史記錄。

乍一看，這看起來像是一個(gè)簡單的組合任務(wù)，然而，業(yè)務(wù)通常需要對數(shù)據(jù)的使用方式進(jìn)行越來越多的控制，并向此類服務(wù)添加更多的邏輯。對要檢索的數(shù)據(jù)量、消費(fèi)終端用戶的權(quán)限等的限制是常見的業(yè)務(wù)需求，這使得實(shí)現(xiàn)這類服務(wù)成為一項(xiàng)全職維護(hù)任務(wù)。

另一方面，Command Query Responsibility Segregation(CQRS)試圖解決查詢挑戰(zhàn)，側(cè)重于維護(hù)從多個(gè)源事件聚合的一個(gè)或多個(gè)物化的數(shù)據(jù)集。 結(jié)果，系統(tǒng)的復(fù)雜性隨著事件總線現(xiàn)在的要求而增加。我們將在以后的文章中討論這種模式。

3.分布式數(shù)據(jù)集成

正如前面所討論的，微服務(wù)的分布式特性使得服務(wù)與服務(wù)的通信和服務(wù)組合對于成功實(shí)現(xiàn)至關(guān)重要。嘗試以一種主流的方式從頭開始實(shí)現(xiàn)所有的服務(wù)，盡管這是可能的，但并不總是建議這樣做，特別是在已存在專門的工具并幫助我們簡化工作的情況下。

實(shí)際上，從頭開始編碼所有內(nèi)容，通過服務(wù)使數(shù)據(jù)可用于外部消費(fèi)的例子是可以避免的。 我們可以公開不同商店中的數(shù)據(jù)，不僅是使用現(xiàn)有框架的關(guān)系數(shù)據(jù)庫，這些框架可以幫助我們實(shí)現(xiàn)API組合模式，還可以使用簡單的數(shù)據(jù)即微服務(wù)服務(wù)。

分布式數(shù)據(jù)集中集成通過一個(gè)統(tǒng)一的API提供對任何存儲(chǔ)實(shí)現(xiàn)中的數(shù)據(jù)的集成訪問。數(shù)據(jù)集成允許連接和統(tǒng)一數(shù)據(jù)，即使數(shù)據(jù)存儲(chǔ)在SQL或JDBC之外的不止一種數(shù)據(jù)源中。與數(shù)據(jù)庫管理系統(tǒng)相反，它不應(yīng)該存儲(chǔ)任何數(shù)據(jù)，而應(yīng)該作為一個(gè)single point(單點(diǎn))接口來優(yōu)化訪問數(shù)據(jù)源。

顯然，這種框架應(yīng)該與微服務(wù)的分布式特性相兼容。因此，引擎和實(shí)現(xiàn)應(yīng)該是輕量級(jí)的，并且能夠作為容器部署在云環(huán)境中。它應(yīng)該具有在運(yùn)行時(shí)獨(dú)立執(zhí)行組件的靈活性，比如Spring Boot或?qū)⑵淝度氲綉?yīng)用程序中。

到此，關(guān)于“數(shù)據(jù)作為微服務(wù)的實(shí)現(xiàn)方法是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！

網(wǎng)頁名稱：數(shù)據(jù)作為微服務(wù)的實(shí)現(xiàn)方法是什么
文章源于：http://jinyejixie.com/article36/pspspg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、ChatGPT、Google、企業(yè)網(wǎng)站制作、品牌網(wǎng)站建設(shè)、

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)