国产一区二区在线视频_国产免费人成在线视频视频_国摸私拍2017无水印套_日韩视频在线观看中字_国产精品日韩一区二区三区_色综合久久综合网欧美综合网_国产午夜免费一区二区三区_最近中文字幕mv手机免费高清_亚洲午夜久久久久国产


在大數(shù)據(jù)時(shí)代,數(shù)據(jù)已經(jīng)成為公司的核心競(jìng)爭(zhēng)力。主要是通過(guò)各種數(shù)據(jù)分析挖掘手段,為公司發(fā)展決策和業(yè)務(wù)開展提供數(shù)據(jù)支持。業(yè)內(nèi)數(shù)據(jù)安全事件頻發(fā),給相關(guān)企業(yè)造成了無(wú)可挽回的損失,更為數(shù)據(jù)安全防護(hù)意識(shí)薄弱的企業(yè)敲響了警鐘。如何對(duì)公司內(nèi)部數(shù)據(jù)最為集中的數(shù)據(jù)分析、數(shù)據(jù)服務(wù)、數(shù)據(jù)治理等各種數(shù)據(jù)類產(chǎn)品進(jìn)行權(quán)限管控,已經(jīng)成為數(shù)據(jù)安全建設(shè)中最為重要的任務(wù)。如果從控制力的角度來(lái)進(jìn)行劃分的話,權(quán)限管控可以分為功能級(jí)權(quán)限管控和數(shù)據(jù)級(jí)權(quán)限管控。早期的數(shù)據(jù)安全產(chǎn)品大多使用傳統(tǒng)的權(quán)限模型,只能實(shí)現(xiàn)功能級(jí)權(quán)限管控,無(wú)法進(jìn)行數(shù)據(jù)級(jí)權(quán)限管控。基于數(shù)據(jù)類產(chǎn)品更高的安全要求,我們需要構(gòu)建一個(gè)同時(shí)滿足各類產(chǎn)品數(shù)據(jù)安全的我們需要構(gòu)建一個(gè)同時(shí)滿足各類產(chǎn)品數(shù)據(jù)安全的平臺(tái)。為此,騰軟技術(shù)不僅設(shè)計(jì)了能表達(dá)和管控各種復(fù)雜關(guān)系的權(quán)限模型,還針對(duì)事前、事中、事后等三個(gè)場(chǎng)景,分別設(shè)計(jì)了審批、權(quán)限、審計(jì)三個(gè)子系統(tǒng)以保障數(shù)據(jù)安全的完整閉環(huán),進(jìn)而滿足數(shù)據(jù)安全的各種要求。

image.png

圖1 權(quán)限背景


功能應(yīng)用類產(chǎn)品的權(quán)限表達(dá),一般為“是否有權(quán)限”,而數(shù)據(jù)類產(chǎn)品權(quán)限表達(dá)的關(guān)系更加復(fù)雜。例如數(shù)據(jù)類產(chǎn)品的報(bào)表,不僅需要表達(dá)出用戶能否訪問(wèn)這個(gè)報(bào)表,而且需要表達(dá)出用戶能訪問(wèn)報(bào)表中的哪些維度、指標(biāo)以及維值的范圍。還需要告知這些維度指標(biāo)來(lái)自于哪些庫(kù)表模型,是否有權(quán)限訪問(wèn)以及創(chuàng)建報(bào)表。


權(quán)限模型

傳統(tǒng)的權(quán)限模型有ACL(Access Control List)訪問(wèn)控制列表,RBAC(Role-Based Access Control)基于角色的訪問(wèn)控制等。以上模型比較適用于應(yīng)用類型產(chǎn)品的權(quán)限管控,而數(shù)據(jù)類型的產(chǎn)品對(duì)信息安全的要求更高,而且各類資源間的關(guān)系也更復(fù)雜,使用傳統(tǒng)的模型難以將內(nèi)部關(guān)系進(jìn)行清晰的表達(dá),所以我們?cè)赗BAC權(quán)限模型的基礎(chǔ)上,擴(kuò)展設(shè)計(jì)了新的權(quán)限模型。

image.png

圖2 傳統(tǒng)權(quán)限模型


如圖2所示,傳統(tǒng)的權(quán)限模型:

?ACL訪問(wèn)控制列表,用戶與權(quán)限直接關(guān)聯(lián),直接維護(hù)用戶與列表中資源的關(guān)系從而達(dá)到權(quán)限管控的目的。

?RBAC模型則是角色與權(quán)限進(jìn)行關(guān)聯(lián),用戶成為相應(yīng)的角色而獲得對(duì)應(yīng)的權(quán)限。


為什么要設(shè)計(jì)新的權(quán)限模型?

1ACL模型是用戶與資源直接建立關(guān)系,沒(méi)有角色的概念。當(dāng)某些用戶需要一批同樣資源的權(quán)限時(shí),賦權(quán)操作就變得很復(fù)雜,此時(shí)這種模型就不太適應(yīng)了。

2RBAC模型引入了角色的概念,角色與資源建立關(guān)系。當(dāng)某些用戶需要一批同樣資源的權(quán)限時(shí),只需要構(gòu)建一個(gè)角色并賦予使用這批資源的權(quán)限。當(dāng)用戶加入這個(gè)角色時(shí),則擁有該角色的所有權(quán)限。解決了賦權(quán)操作復(fù)雜的問(wèn)題。

不過(guò)ACL模型和RBAC模型,都存在以下幾個(gè)問(wèn)題:

1數(shù)據(jù)類產(chǎn)品資源之間關(guān)系復(fù)雜,不能很好地表達(dá)這種復(fù)雜的關(guān)系。例如:一個(gè)報(bào)表下有多個(gè)標(biāo)簽頁(yè),一個(gè)標(biāo)簽頁(yè)下有多個(gè)組件,一個(gè)組件下有多個(gè)維度、指標(biāo)等。同時(shí)維度、指標(biāo)又來(lái)自不同的數(shù)據(jù)模型、庫(kù)表等。資源與資源之間存在關(guān)系,當(dāng)管理員給一個(gè)用戶賦予報(bào)表的全部或部分權(quán)限時(shí),報(bào)表下的子資源需要同時(shí)獲得對(duì)應(yīng)的權(quán)限。

2RBAC模型中角色與角色之間沒(méi)有對(duì)應(yīng)的關(guān)系。例如:組織架構(gòu)中,員工所在的組織架構(gòu)如下:華東區(qū)/銷售一區(qū)/銷售一組,員工擁有的角色是銷售一組的角色。當(dāng)角色之間沒(méi)有關(guān)系時(shí),員工如果需要華東區(qū)角色的權(quán)限時(shí),需要添加到華東區(qū)的角色中。而如果角色與角色之間具有從屬關(guān)系時(shí),則能很好地解決這個(gè)問(wèn)題。

新的權(quán)限模型是如何解決上面這些問(wèn)題的:

1設(shè)計(jì)資源模型時(shí),資源與資源之間具有從屬關(guān)系,并且資源允許多層級(jí),以樹形結(jié)構(gòu)展示。例如報(bào)表是一個(gè)父資源,標(biāo)簽、組件、維度指標(biāo)都是報(bào)表下的子資源,這樣賦權(quán)時(shí)能清晰地展示出報(bào)表資源與下面的子資源的關(guān)系,賦權(quán)和鑒權(quán)時(shí)才能滿足各種權(quán)限控制的要求。

2角色與角色之間具有從屬關(guān)系,例如員工在華東區(qū)/銷售一區(qū)/銷售一組的組織架構(gòu)中,華東區(qū)/銷售一區(qū)/銷售一組這3個(gè)角色之間分別具有父子級(jí)的從屬關(guān)系,當(dāng)員工在銷售一組部門下,則擁有華東區(qū)、銷售一區(qū)、銷售一組的所有權(quán)限。當(dāng)權(quán)限不沖突時(shí)則直接合并所有權(quán)限,沖突時(shí)則以“就近原則”進(jìn)行覆蓋。

image.png

圖3權(quán)限模型


如圖3所示,新的權(quán)限模型包含3個(gè)部分,用戶中心、資源中心、權(quán)限中心。


用戶中心:用戶管理、角色管理

?角色分為個(gè)人、組織、自定義3種,一個(gè)用戶可以同時(shí)擁有多個(gè)角色,比如用戶默認(rèn)對(duì)應(yīng)一個(gè)個(gè)人角色,又可同時(shí)擁有在公司組織架構(gòu)中組織角色、在自定義組織的自定義角色。

?角色支持多層級(jí),滿足角色間權(quán)限繼承的表達(dá)方式。

?用戶、部門信息實(shí)時(shí)更新,每天ETL定時(shí)同步,保證人員入職、轉(zhuǎn)崗、調(diào)離權(quán)限實(shí)時(shí)同步。

image.png

圖4 用戶中心

資源中心:資源管理

?資源類型支持自定義,在通用資源類型的基礎(chǔ)上支持自定義的資源接入,滿足各個(gè)系統(tǒng)不同資源的統(tǒng)一管控。

?資源支持多層級(jí),樹形結(jié)構(gòu)的資源展示方式便于資源的統(tǒng)一賦權(quán)鑒權(quán);給一個(gè)報(bào)表資源賦權(quán)時(shí),掛在報(bào)表下的維度、指標(biāo)等資源能統(tǒng)一獲得權(quán)限。

?支持資源打包簡(jiǎn)化賦權(quán)流程。

?資源安全密級(jí)、資源負(fù)責(zé)人,支持按照資源配置不同的審批模板進(jìn)行權(quán)限自助申請(qǐng)。

image.png

圖5 資源中心


權(quán)限中心:角色與資源的關(guān)系的多種策略表達(dá)

?范圍策略:例如報(bào)表中的平臺(tái)維度的維值包括和,賦權(quán)時(shí),支持按要求給用戶賦予部分或全部權(quán)限;鑒權(quán)時(shí),按照規(guī)則解析為某人擁有某維度的部分或全部權(quán)限。

?表達(dá)式策略:當(dāng)把報(bào)表給用戶賦權(quán)時(shí),設(shè)置表達(dá)式為limit 10,表示當(dāng)前用戶在該報(bào)表其他權(quán)限的基礎(chǔ)上再進(jìn)行限制,只能返回前10條記錄。

?權(quán)限自動(dòng)合并:一個(gè)用戶擁有多個(gè)角色,多角色的同一資源的權(quán)限鑒權(quán)時(shí)按照規(guī)則自動(dòng)合并;規(guī)則解析時(shí),權(quán)限數(shù)據(jù)不沖突時(shí)取合集,沖突時(shí)按照優(yōu)先級(jí)取對(duì)應(yīng)的值。

?黑白名單:支持按照特定的規(guī)則,對(duì)某人針對(duì)某資源全面開發(fā)和封禁,黑白名單策略的優(yōu)先級(jí)最高,其中黑名單高于白名單。

image.png

圖6 權(quán)限中心


挑戰(zhàn)

在建設(shè)數(shù)據(jù)安全平臺(tái)的過(guò)程中,主要面臨以下幾點(diǎn)挑戰(zhàn):

?隨著支持的業(yè)務(wù)線增加,通用平臺(tái)的不能滿足各個(gè)業(yè)務(wù)線的定制需求時(shí),需要保證系統(tǒng)的靈活可擴(kuò)展。

?提供一個(gè)通用的數(shù)據(jù)安全平臺(tái),滿足大部分的數(shù)據(jù)安全的要求,保證系統(tǒng)的通用性。

?權(quán)限系統(tǒng)作為一個(gè)高QPS訪問(wèn)的系統(tǒng),如何保證系統(tǒng)的高可用。


解決思路

1提供靈活可插拔的Plugin服務(wù),在通用權(quán)限基礎(chǔ)上,滿足各個(gè)業(yè)務(wù)線靈活的權(quán)限管控要求。

2提供一個(gè)通用的數(shù)據(jù)安全平臺(tái),滿足基本的權(quán)限、審批、審計(jì)的基礎(chǔ)功能。

3微服務(wù)架構(gòu)、核心與非核心服務(wù)分離、數(shù)據(jù)緩存降級(jí)滿足系統(tǒng)高可用。



解決方案

image.png

圖7 整體架構(gòu)


如圖7所示,分3塊,數(shù)據(jù)內(nèi)容權(quán)限平臺(tái)、審批流平臺(tái)、審計(jì)日志平臺(tái):

?提供各種靈活可插拔的Plugin服務(wù),支持在通用服務(wù)的基礎(chǔ)基礎(chǔ)上進(jìn)行定制開發(fā)。

?提供基礎(chǔ)服務(wù),滿足各種通用的數(shù)據(jù)安全要求。

?提供管理工作臺(tái),支持管理員對(duì)各種數(shù)據(jù)和規(guī)則進(jìn)行頁(yè)面管理和配置。


具體方案

Plugin服務(wù)層,保證系統(tǒng)靈活可擴(kuò)展

在滿足通用權(quán)限的基礎(chǔ)上,各個(gè)業(yè)務(wù)線難免會(huì)有定制的權(quán)限管控需求,于是設(shè)計(jì)了權(quán)限Plugin模塊。通用服務(wù)提供用戶管理、資源管理、鑒權(quán)授權(quán)的服務(wù),Plugin調(diào)用基礎(chǔ)服務(wù)實(shí)現(xiàn)特殊的權(quán)限管控。Plugin模塊的應(yīng)用和數(shù)據(jù)各自單獨(dú)管理,通過(guò)RPC方式調(diào)用通用服務(wù)實(shí)現(xiàn)靈活可插拔。后續(xù)Plugin模塊的服務(wù)支持各個(gè)接入的應(yīng)用單獨(dú)定制開發(fā)。

image.png

圖8 Plugin服務(wù)

如圖8所示,通用權(quán)限的服務(wù)與Plugin的服務(wù)是分離的,支持多個(gè)Plugin服務(wù)靈活可插拔:

?通用服務(wù)提供用戶、資源、鑒權(quán)授權(quán)等通用服務(wù),大部分的系統(tǒng)基于通用服務(wù)即可實(shí)現(xiàn)權(quán)限管控要求。

?Plugin服務(wù)基于通用服務(wù)對(duì)外提供的SDK進(jìn)行拓展,各個(gè)Plugin服務(wù)單獨(dú)部署,保證系統(tǒng)之間互相獨(dú)立。

最終的權(quán)限實(shí)現(xiàn)分層管控,分為核心數(shù)據(jù)層(用戶、資源、權(quán)限數(shù)據(jù))和應(yīng)用層。核心數(shù)據(jù)層的數(shù)據(jù)由通用服務(wù)進(jìn)行管理,達(dá)到權(quán)限數(shù)據(jù)統(tǒng)一管控的要求。應(yīng)用層以Plugin服務(wù)方式接入,Plugin通過(guò)通用服務(wù)層對(duì)外的SDK進(jìn)行權(quán)限數(shù)據(jù)讀寫,達(dá)到定制的管控要求。應(yīng)用層的數(shù)據(jù)各自存儲(chǔ),可以自定義管控規(guī)則。接口之間的調(diào)用通過(guò)BA認(rèn)證鑒權(quán),保證服務(wù)之間調(diào)用的安全性。


基礎(chǔ)服務(wù)層,保證系統(tǒng)通用性

通用權(quán)限系統(tǒng)架構(gòu)

使用微服務(wù)架構(gòu)設(shè)計(jì),系統(tǒng)分為接入層、服務(wù)層、數(shù)據(jù)庫(kù)層、以及外部服務(wù)層。主要包含以下幾個(gè)核心服務(wù):

?用戶服務(wù):主要包含用戶和部門信息同步、角色管理。

?資源服務(wù):包含資源注冊(cè)、資源定時(shí)同步、資源密級(jí)及管理員管理、資源包管理。

?賦權(quán)服務(wù):權(quán)限自助申請(qǐng)、管理員賦權(quán)。

?鑒權(quán)服務(wù):提供各種鑒權(quán)的SDK供使用方調(diào)用。

image.png

圖9 權(quán)限系統(tǒng)架構(gòu)

如圖9所示:

?接入層:對(duì)外所有系統(tǒng)通過(guò)統(tǒng)一的SDK調(diào)用服務(wù)。

?服務(wù)層:微服務(wù)架構(gòu),各個(gè)服務(wù)之間互相之間提供服務(wù)。

?數(shù)據(jù)庫(kù)層:合理利用緩存、數(shù)據(jù)降級(jí),保證服務(wù)高可用。

?集成公司公共服務(wù),保證系統(tǒng)穩(wěn)健運(yùn)行。


審批系統(tǒng)架構(gòu)

提供通用的審批服務(wù),提供多級(jí)審批模板,使用時(shí)選擇模板啟動(dòng)審批流,審批系統(tǒng)按照啟動(dòng)的參數(shù)進(jìn)行規(guī)則解析,自動(dòng)適配對(duì)應(yīng)的審批流程??s減接入流程支持一鍵接入。

image.png

圖10 審批系統(tǒng)架構(gòu)


如圖10所示:優(yōu)化審批接入流程,提供通用的審批服務(wù),減少系統(tǒng)接入開發(fā)成本:

?前期開發(fā)一個(gè)審批功能需要6個(gè)步驟,繪制流程圖,配置審批的組和成員,配置通知的消息,配置事件映射,啟動(dòng)審批流,開發(fā)回調(diào)接口改狀態(tài)。

?而我們?cè)谄脚_(tái)的審批服務(wù)基礎(chǔ)上進(jìn)行封裝,提供通用的審批模板,接入審批系統(tǒng)只需要選擇模板啟動(dòng)審批流,并提供回調(diào)接口即可。能滿足大部分的審批功能。

提供通用的規(guī)則解析引擎,支持審批人、審批條件、審批通知按照規(guī)則動(dòng)態(tài)解析匹配。靈活實(shí)現(xiàn)自動(dòng)審批、多人多級(jí)審批、定時(shí)催辦等多種通用功能。對(duì)接權(quán)限和審計(jì)系統(tǒng),保證審批系統(tǒng)數(shù)據(jù)安全:

?對(duì)接權(quán)限系統(tǒng),提供管理員權(quán)限管控。

?對(duì)接審計(jì)系統(tǒng),操作數(shù)據(jù)落到審計(jì)系統(tǒng)便于后續(xù)的數(shù)據(jù)審計(jì)。


審計(jì)系統(tǒng)架構(gòu)

提供通用的數(shù)據(jù)審計(jì)服務(wù),客戶端日志埋點(diǎn)上報(bào),審計(jì)日志按類型落到Elasticsearch中存儲(chǔ)。對(duì)接如意可視化報(bào)表出審計(jì)報(bào)告,對(duì)接權(quán)限系統(tǒng)管控?cái)?shù)據(jù)權(quán)限。

image.png

圖11 審計(jì)系統(tǒng)架構(gòu)

如圖11所示:審計(jì)數(shù)據(jù)模型層支持自動(dòng)擴(kuò)展:

?每個(gè)應(yīng)用對(duì)應(yīng)一個(gè)appkey,每個(gè)appkey按照模板分日期自動(dòng)創(chuàng)建一個(gè)索引,支持自動(dòng)擴(kuò)展。

?每種類型的審計(jì)日志對(duì)應(yīng)Elasticsearch索引中的一個(gè)type,新增一種操作日志時(shí),type自動(dòng)創(chuàng)建。

?審計(jì)日志中的字段對(duì)應(yīng)type中的字段,新增字段時(shí)自動(dòng)擴(kuò)展。


保證系統(tǒng)高可用微服務(wù)架構(gòu)服務(wù)分離

隨著系統(tǒng)的模塊功能越來(lái)越多,單一架構(gòu)模式已不再適合敏捷開發(fā),模塊越來(lái)越大系統(tǒng)啟動(dòng)則越慢,任一模塊出錯(cuò)則整個(gè)系統(tǒng)的服務(wù)都不可用。為了保證服務(wù)的高可用和擴(kuò)展性,于是以微服務(wù)架構(gòu)把模塊進(jìn)行拆分,并把核心與非核心服務(wù)進(jìn)行分離。

image.png

圖12 微服務(wù)架構(gòu)

如圖12所示:

?前端接入層通過(guò)HTTP接入,BA認(rèn)證校驗(yàn)請(qǐng)求合法性,通過(guò)Nginx負(fù)載均衡。

?管理控制臺(tái),通過(guò)調(diào)用服務(wù)層的各個(gè)服務(wù)實(shí)現(xiàn)統(tǒng)一管理。

?服務(wù)層,抽象系統(tǒng)各個(gè)模塊,每個(gè)模塊都是一個(gè)微服務(wù),每一個(gè)微服務(wù)都獨(dú)立部署,可以根據(jù)每個(gè)服務(wù)的規(guī)模按需部署。

?Client層,對(duì)外提供統(tǒng)一的Pigeon(內(nèi)部分布式服務(wù)RPC通信框架)接口,通過(guò)POM引入調(diào)用服務(wù)層各個(gè)服務(wù)。


權(quán)限繼承

由于資源支持多層級(jí),設(shè)計(jì)權(quán)限模型時(shí)支持權(quán)限繼承,當(dāng)賦權(quán)時(shí)開啟繼承,則用戶默認(rèn)擁有該資源以及下面所有資源的全部權(quán)限,數(shù)據(jù)存儲(chǔ)時(shí)只需要存儲(chǔ)祖先資源與用戶之間的關(guān)系。大大減少了權(quán)限矩陣大小。

image.png

圖13 權(quán)限繼承


權(quán)限數(shù)據(jù)存儲(chǔ)

接入的系統(tǒng)越多,則資源和用戶就越多。隨著系統(tǒng)運(yùn)行越久,對(duì)應(yīng)的權(quán)限數(shù)據(jù)也會(huì)隨之快速增長(zhǎng)。如何在數(shù)據(jù)增長(zhǎng)的同時(shí)保證接口的性能和高可用。


權(quán)限備份與恢復(fù)

參照HBase的版本號(hào)和MySQL的Binlog的設(shè)計(jì)思路,賦權(quán)時(shí)權(quán)限只存儲(chǔ)當(dāng)前用戶最新權(quán)限數(shù)據(jù),歷史權(quán)限數(shù)據(jù)和操作記錄用版本號(hào)的方式存儲(chǔ)到Elasticsearch中。用戶鑒權(quán)時(shí)只需要查詢MySQL的權(quán)限數(shù)據(jù)即可,保證鑒權(quán)接口的高效性。

image.png

圖14 權(quán)限備份與恢復(fù)

如圖14所示:

?賦權(quán)操作時(shí),通過(guò)版本號(hào)管理權(quán)限數(shù)據(jù),每次操作后版本號(hào)加1,MySQL和Redis中只存儲(chǔ)最新的權(quán)限數(shù)據(jù)。

?歷史權(quán)限數(shù)據(jù)通過(guò)版本號(hào)的方式存儲(chǔ)到Elasticsearch中,每次查看歷史操作記錄或恢復(fù)權(quán)限數(shù)據(jù)時(shí),根據(jù)版本號(hào)回溯即可。


權(quán)限過(guò)期清理

?通過(guò)Crane定時(shí)調(diào)度,根據(jù)配置的通知規(guī)則,掃描即將過(guò)期的權(quán)限數(shù)據(jù),發(fā)送消息通知用戶進(jìn)行權(quán)限續(xù)期。

?掃描已過(guò)期的權(quán)限數(shù)據(jù),清理MySQL和Redis中的過(guò)期權(quán)限數(shù)據(jù),并轉(zhuǎn)儲(chǔ)到Elasticsearch中保存,已備后續(xù)的權(quán)限審計(jì)。


數(shù)據(jù)讀寫分離、緩存、備份以及服務(wù)熔斷降級(jí)

各個(gè)服務(wù)使用MySQL分庫(kù)存儲(chǔ),使用Zebra(數(shù)據(jù)庫(kù)訪問(wèn)層中間件)進(jìn)行讀寫分離;合理使用數(shù)據(jù)緩存與備份,并支持服務(wù)的熔斷降級(jí),以保證服務(wù)的高可用。

image.png

圖15 數(shù)據(jù)讀寫分離、緩存、備份以及服務(wù)熔斷降級(jí)

如圖15所示:

?各個(gè)服務(wù)使用MySQL分庫(kù)存儲(chǔ);核心服務(wù)與非核心服務(wù)分離,服務(wù)和數(shù)據(jù)庫(kù)支持按需彈性拓展。

?角色、資源等熱點(diǎn)數(shù)據(jù)使用Redis做緩存,并在Redis緩存不可用時(shí)自動(dòng)下沉到MySQL進(jìn)行查詢。

?操作記錄和歷史數(shù)據(jù)等不活躍數(shù)據(jù)落地到Elasticsearch,以便審計(jì)和數(shù)據(jù)恢復(fù)。

?服務(wù)不可用時(shí)支持熔斷降級(jí),以保證核心服務(wù)的可用性。


合理使用消息隊(duì)列、任務(wù)調(diào)度、線程池、分布式鎖

使用消息隊(duì)列、任務(wù)調(diào)度、線程池進(jìn)行異步、削峰、解耦合,減少服務(wù)響應(yīng)時(shí)間,提升用戶體驗(yàn)。并使用分布式鎖保證數(shù)據(jù)一致性。

image.png

圖16 提高服務(wù)響應(yīng)速度

如圖16所示:

?使用消息隊(duì)列處理用戶請(qǐng)求,實(shí)時(shí)返回操作成功,后臺(tái)根據(jù)接受到的MQ消息異步進(jìn)行處理并修改狀態(tài),頁(yè)面輪詢狀態(tài)展示最終結(jié)果或發(fā)送大象(內(nèi)部通訊工具)消息進(jìn)行最終結(jié)果推送。

?需要定時(shí)同步的任務(wù)通過(guò)Crane分布式任務(wù)調(diào)度平臺(tái)進(jìn)行定時(shí)調(diào)度執(zhí)行。

?審批回調(diào)時(shí)使用線程池處理審批結(jié)果回調(diào)與失敗重試,較少創(chuàng)建銷毀線程的開銷。

?分布式鎖,保證同一個(gè)方法在同一操作上只能被一臺(tái)機(jī)器上的一個(gè)線程執(zhí)行,避免用戶重復(fù)提交或者多機(jī)器重復(fù)處理導(dǎo)致的數(shù)據(jù)不一致。