微服務下的統(tǒng)一數(shù)據(jù)查詢

時間：2022-08-11 15:48:01 | 來源：網(wǎng)站運營

時間：2022-08-11 15:48:01 來源：網(wǎng)站運營

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，微服務作為一種云服務的架構(gòu)方式被越來越多的企業(yè)采用，使用微服務的架構(gòu)進行開發(fā)，提供了產(chǎn)品的可靠性，可擴展性，降低維護成本，同時也可以支持按需伸縮服務。對于開發(fā)人員，微服務的代碼量明顯減少，遇到問題也更容易解決。但同時微服務也帶來了許多問題，例如：分布式部署的復雜度明顯提升、接口調(diào)整的成本升高、對運維的需求也更高了。其中一個主要的問題是不同的服務使用獨立的數(shù)據(jù)庫，提高了數(shù)據(jù)使用的效率，但對于復雜的業(yè)務場景也帶來了查詢其他服務的數(shù)據(jù)的復雜度。

1.常見問題

　　以單據(jù)業(yè)務為例，下面將介紹幾個典型的問題場景。

　　目前的企業(yè)服務開發(fā)中，單據(jù)開發(fā)是比較常見的開發(fā)任務，一個業(yè)務單據(jù)上一般會引用很多的基礎數(shù)據(jù)對象，少的有幾個，多的可能有十幾個。

　　界面顯示數(shù)據(jù)翻譯問題：在界面顯示上，單據(jù)引用的數(shù)據(jù)一般顯示為名稱或編碼，但數(shù)據(jù)庫中存儲為對象的ID.因此，后臺服務在查詢到單據(jù)數(shù)據(jù)后需要轉(zhuǎn)換為編碼或名稱返回界面顯示，如下圖所示：







　　多個服務關聯(lián)查詢問題：在單據(jù)業(yè)務實現(xiàn)時，經(jīng)常會出現(xiàn)關聯(lián)多個服務查詢的場景，例如在報銷單審批時，查詢報銷單的費用承擔部門的上級部門負責人對應的用戶進行審批。需要追溯多個對象進行查詢。如下圖所示：







　　數(shù)據(jù)導入問題：單據(jù)業(yè)務中，存在很多數(shù)據(jù)導入的場景，而通過excel導入數(shù)據(jù)時，需要根據(jù)名稱或編碼翻譯為ID然后插入數(shù)據(jù)庫中。

2.常見解決方案探討

　　對于界面顯示數(shù)據(jù)翻譯問題，按微服務的開發(fā)方式，最簡單的方案是，同步調(diào)用相關的服務進行數(shù)據(jù)翻譯。例如，報銷單界面顯示數(shù)據(jù)時需要經(jīng)過如下步驟：

　　1．查詢報銷單數(shù)據(jù)

　　2．根據(jù)報銷單的承擔部門調(diào)用部門接口翻譯數(shù)據(jù)

　　3．根據(jù)報銷單的報銷人賬戶調(diào)用員工賬戶服務翻譯數(shù)據(jù)

　　4．根據(jù)報銷單的工程項目調(diào)用項目服務翻譯數(shù)據(jù)

　　5．報銷單的行政區(qū)劃調(diào)用社會級基礎數(shù)據(jù)服務翻譯數(shù)據(jù)

　　6．返回界面顯示。

　　可以看出中間有幾個引用的數(shù)據(jù)，就需要調(diào)用幾次遠程服務接口。一方面，開發(fā)復雜，每個單據(jù)都需要編寫相關的翻譯代碼，另一方面，調(diào)用次數(shù)過多，導致時間消耗過長。

　　因此，實際業(yè)務中常見的解決方案有幾種：

　?。?）數(shù)據(jù)庫中冗余字段方式。

　　例如上述報銷單界面顯示時，需要翻譯部門、員工、項目等基礎數(shù)據(jù)屬性時，可以在部門中直接冗余相關的名稱字段。在保存數(shù)據(jù)中直接保存到數(shù)據(jù)庫中。如下圖所示：







　　此方案的問題是，如果對應的基礎數(shù)據(jù)對象修改了名稱時，需要同步修改的數(shù)據(jù)，從業(yè)務方案上，可以通過事件通知的方式，在相關的對象發(fā)生變動時，同步修改冗余字段的內(nèi)容?；蛘叨〞r同步冗余字段內(nèi)容。但當單據(jù)不斷增加的情況下，一個部門的變動，可能引發(fā)十幾個或更多的單據(jù)或其他基礎數(shù)據(jù)的同步行為，計算過程復雜，對數(shù)據(jù)的更新操作壓力會比較大。同時通過事件的方式進行同步，對開發(fā)要求較高，配置錯誤時，會導致數(shù)據(jù)沒有被更新，顯示錯誤。

　?。?）直接備份數(shù)據(jù)表的方式

　　可以通過定時拉取的或推送的方式從指定的數(shù)據(jù)中，同步表數(shù)據(jù)，在同步時可以通過指定字段或建立視圖等方式，僅同步指定字段內(nèi)容，減少同步數(shù)據(jù)和避開敏感數(shù)據(jù)。







　　此方案的問題與第一個方案類似，但微服務不斷增多的情況下，每個微服務都要同步其他微服務的數(shù)據(jù)庫表，需要同步的數(shù)據(jù)庫表會越來越多，帶來的消耗也會越來越大。數(shù)據(jù)庫之間的同步關系復雜度上升對運維的復雜度也會升高。而且同步出現(xiàn)問題時，也會導致界面顯示數(shù)據(jù)的不一致性。

　?。?）統(tǒng)一數(shù)據(jù)中心查詢方式。

　　通過統(tǒng)一的數(shù)據(jù)采集服務，將數(shù)據(jù)收歸到統(tǒng)一的數(shù)據(jù)中心，其他業(yè)務服務需要查詢數(shù)據(jù)時，調(diào)用統(tǒng)一的數(shù)據(jù)服務中心進行查詢，可以在最大程度上降低要同步數(shù)據(jù)的復雜度，通過合并多個對象查詢的方式提高訪問速度。




3.統(tǒng)一查詢方案說明

　　方案的實現(xiàn)主要是組合了gPaaS以下幾個能力形成的：存儲模型管理，元數(shù)據(jù)模型管理，統(tǒng)一的數(shù)據(jù)倉庫，數(shù)據(jù)同步服務，數(shù)據(jù)查詢服務。








　　存儲模型管理：負責提供數(shù)據(jù)存儲模型的建立，由數(shù)據(jù)提供方建立對外的數(shù)據(jù)模型視圖?？芍С謹?shù)據(jù)提供方根據(jù)數(shù)據(jù)的敏感性或是否僅內(nèi)部使用屬性等對提供的數(shù)據(jù)模型進行選擇，僅提供可對外提供的必要數(shù)據(jù)屬性。

　　1．支持查詢數(shù)據(jù)視圖的模型的管理，支持單表模型描述，也支持多表關聯(lián)的復雜結(jié)構(gòu)數(shù)據(jù)模型描述。







　　在進行查詢視圖定義時，支持對數(shù)據(jù)進行篩選，數(shù)據(jù)提供方指定提供數(shù)據(jù)屬性范圍。其次，有可能的情況下需要數(shù)據(jù)來源方提供ID、時間戳、刪除標記等屬性。用于后續(xù)數(shù)據(jù)抽取服務時的增量抽取能力。

　　2．支持對來源數(shù)據(jù)庫的連接管理，可由業(yè)務方提供只讀的數(shù)據(jù)庫賬號，用于同步服務同步數(shù)據(jù)使用。支持模型與數(shù)據(jù)庫的關系管理，支持單一數(shù)據(jù)庫部署，和多租戶多數(shù)據(jù)庫的部署模式。







　　為支持多租戶的部署模型，部分微服務會連接存在相同的表結(jié)構(gòu)多個數(shù)據(jù)庫，通過租戶或其他參數(shù)進行數(shù)據(jù)的分庫存儲。因此，在數(shù)據(jù)源模型描述支持多個數(shù)據(jù)庫的描述方式。模型視圖上僅與數(shù)據(jù)源保持關系，在來源業(yè)務系統(tǒng)更換數(shù)據(jù)庫或進行數(shù)據(jù)庫隔離的情況下，不需要重新修改視圖模型。

　　元數(shù)據(jù)模型管理：元數(shù)據(jù)一般指用于描述數(shù)據(jù)的數(shù)據(jù)，包含對象模型，對象的屬性模型（包括屬性的數(shù)據(jù)類型，與其他對象的引用關系），以及對象的存儲模型。來源業(yè)務系統(tǒng)通過存儲模型管理中描述的數(shù)據(jù)倉庫的模型，與元數(shù)據(jù)的存儲模型對應，建立完整的業(yè)務系統(tǒng)的對象關系模型。







　　元數(shù)據(jù)模型支持屬性標簽描述，用于后續(xù)查詢服務可根據(jù)統(tǒng)一的標簽進行查詢，例如根據(jù)ID返回名稱時，只需要個業(yè)務提供方在模型中的名稱屬性設置標簽為（name）即可通過統(tǒng)一的語句進行查詢。

　　統(tǒng)一數(shù)據(jù)倉庫：使用支持高并發(fā)的分布式NoSQL數(shù)據(jù)庫實現(xiàn)。支持按字段條件查詢的方式獲取數(shù)據(jù)。

　　數(shù)據(jù)同步服務：通過多種方式從業(yè)務系統(tǒng)的數(shù)據(jù)庫中拉取對應的數(shù)據(jù)同步到統(tǒng)一數(shù)據(jù)倉庫中。

　　1．支持通過定時任務拉取數(shù)據(jù)方式。

　　2．通過binlog同步方式。

　　一般通過兩種方式結(jié)合，binlog可以保障數(shù)據(jù)以最短時間同步到統(tǒng)一數(shù)據(jù)倉庫中。當啊同步服務出現(xiàn)問題時，可以通過定時任務進行補償。

　　數(shù)據(jù)查詢服務：通過元數(shù)據(jù)模型，提供基于元數(shù)據(jù)模型的查詢服務。根據(jù)元數(shù)據(jù)模型描述，形成對應的數(shù)據(jù)模型查詢語句，調(diào)用數(shù)據(jù)倉庫的接口進行查詢。

　　可根據(jù)標簽，進行語句的擴展，例如查詢名稱為“張三”的用戶，可以使用name = “張三”，或者 <lable：name> = “張三”的方式描述查詢條件參數(shù)。查詢服務接收到參數(shù)后，根據(jù)元數(shù)據(jù)模型，轉(zhuǎn)換為存儲模型的結(jié)構(gòu)，調(diào)用數(shù)據(jù)倉庫的服務接口進行查詢。

4.目前方案的優(yōu)勢及使用場景

　　統(tǒng)一查詢方案的優(yōu)勢如下：

　　1.對原有業(yè)務系統(tǒng)無侵入，不需要修改業(yè)務服務的代碼。

　　2.在定義查詢視圖時，可通過限制查詢字段及增加查詢條件的方式，對敏感數(shù)據(jù)進行過濾，避免出現(xiàn)數(shù)據(jù)問題。

　　3.查詢視圖與實際業(yè)務視圖分離，業(yè)務系統(tǒng)可在修改自己的數(shù)據(jù)庫同時，通過修改查詢視圖，保障對原有的查詢視圖屬性不發(fā)生變化，避免影響其他服務的使用。

　　4.使用獨立的數(shù)據(jù)倉庫進行查詢操作，避免影響原有業(yè)務數(shù)據(jù)庫的性能。

　　5.通過使用NoSql數(shù)據(jù)庫構(gòu)建數(shù)據(jù)倉庫，在例如界面主鍵翻譯這種高并發(fā)操作的提高執(zhí)行效率。當數(shù)據(jù)倉庫性能下降時，比較傳統(tǒng)的關系型數(shù)據(jù)庫更容易動態(tài)增容擴展。

　　業(yè)務上推薦使用的場景有：

　　1.界面顯示數(shù)據(jù)時的主鍵翻譯為名稱、編碼。

　　2.支持公式或報表等需要同步模型配置查詢數(shù)據(jù)的場景。

　　3.可以用于參照服務，參照服務的數(shù)據(jù)實效性要求不高，使用統(tǒng)一數(shù)據(jù)倉庫有利于降低主數(shù)據(jù)庫的業(yè)務壓力。