<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          業(yè)務(wù)中臺設(shè)計八大原則與分布式運行機制

          共 5588字,需瀏覽 12分鐘

           ·

          2022-01-17 01:41

          從業(yè)務(wù)到中臺,必須經(jīng)歷抽象建模的過程。這個過程分為兩個階段,分別是 0 級抽象中心建模的階段和 1 級抽象組件建模的階段。每個階段采用的建模抽象機制都是實體抽象法。下面以 0 級階段建模抽象為例進行說明。

          首先,我們梳理出企業(yè)功能需求,如某飲料企業(yè)的功能需求匯總表如下圖所示。


          其次,找出每一個功能需求所對應(yīng)的業(yè)務(wù)對象或?qū)嶓w。這一步需要剝離功能的差異性,抽象功能的共同點,才能保證定義合理。實體分為兩類:業(yè)務(wù)實體(叫“靜態(tài)實體”更容易理解)和過程實體。

          實體性質(zhì)相同或者實體結(jié)構(gòu)相似度較高,都可歸納為同一實體。在實體基礎(chǔ)上,為了滿足當前功能需求,我們需要定義出系統(tǒng)需要提供的能力。能力就是對實體施加的操作或發(fā)出的命令,這里的能力我們稱為領(lǐng)域能力。最后,根據(jù)能力的主題、實體的密切關(guān)系,定義出主題域(也可以稱為“業(yè)務(wù)域”)。

          業(yè)務(wù)域的命名一般由資深業(yè)務(wù)架構(gòu)師來定義,以避免出現(xiàn)二義性。基于功能需求的抽象,輸出的產(chǎn)物見下表。


          劃分出多個主題域后,技術(shù)架構(gòu)師需要結(jié)合技術(shù)的實現(xiàn),將領(lǐng)域進行組合規(guī)劃出中心。中心的劃分標準主要從實體的聚合度、中心的職責(zé)、中心顆粒度、能否獨立運營等方面來權(quán)衡。確定中心的過程也就是劃定功能邊界的過程。下圖是某企業(yè)的中心劃分結(jié)果。


          業(yè)務(wù)中臺是一個充滿生命力的個體,它承載業(yè)務(wù)邏輯、沉淀業(yè)務(wù)數(shù)據(jù)、產(chǎn)生業(yè)務(wù)價值,并隨著業(yè)務(wù)不斷發(fā)展進化。它的設(shè)計遵循如下圖所示的 8 個原則。

          一、分布式運行機制

          1.服務(wù)松耦合原則

          (1)面向接口實現(xiàn)

          這是服務(wù)松耦合的基本要求,即每一個服務(wù)都按接口的定義進行實現(xiàn)。服務(wù)的消費方不需要依賴某個特定的服務(wù)實現(xiàn),避免服務(wù)提供方的內(nèi)部變更影響到消費方。另外,在服務(wù)提供方切換到其他系統(tǒng)時,不影響服務(wù)消費方的正常運行。

          (2)異步事件解耦

          服務(wù)間的事件通信采用異步消息隊列來實現(xiàn)。由于有消息隊列這個中介,因此生產(chǎn)者和消費者不必在同一時間都保持實時處理能力,而且消費生產(chǎn)者也不需要馬上等到回復(fù)。

          (3)服務(wù)提供者位置解耦

          服務(wù)消費者不需要直接了解服務(wù)提供者的具體位置信息,例如 IP 地址、端口。典型解決方法是服務(wù)注冊中心,服務(wù)提供者啟動時將自己注冊到服務(wù)注冊中心,服務(wù)消費者通過服務(wù)注冊中心查找具體服務(wù)提供者來訪問。同時,服務(wù)注冊中心可以提供負載均衡及 fail-over 的能力。

          (4)版本松耦合

          消費端不需要依賴服務(wù)契約的某個特定版本來工作,這就要求服務(wù)契約在升級時盡可能提供向下兼容性。

          2.服務(wù)依賴原則

          (1)有價值的領(lǐng)域模型

          • 價值導(dǎo)向:確保業(yè)務(wù)中心的服務(wù)都與企業(yè)的商業(yè)理想保持一致,相關(guān)聯(lián)。
          • 簡捷為美:業(yè)務(wù)邏輯和流程避免復(fù)雜化。
          • 領(lǐng)域洞察:緊貼業(yè)務(wù)的核心目的,從業(yè)務(wù)原則指導(dǎo)業(yè)務(wù)邏輯的設(shè)計。

          (2)服務(wù)間最小依賴

          • 高內(nèi)聚:同一類服務(wù)應(yīng)歸在一起。
          • 低耦合:服務(wù)間保持最小聯(lián)系。
          • 能力與接口:業(yè)務(wù)流程和業(yè)務(wù)邏輯的操作都作為中心服務(wù)實現(xiàn),而提供給外部調(diào)用的接口數(shù)據(jù)模型都會轉(zhuǎn)化為服務(wù)。
          • 識別通用性:識別出每個通用能力的可擴展的類型,從設(shè)計上支持它不斷擴展,并在接口定義上滿足其不斷升級的需求。

          (3)能力實體具有層次性

          • 能力與接口:分離接口實體與能力實體。
          • 接口實體與限定元素:將接口實體核心元素與接口操作的限定元素分離。
          • 接口實體的層次結(jié)構(gòu):建設(shè)接口實體和上下文限定元素的層次結(jié)構(gòu)。

          (4)延遲對技術(shù)組件的依賴

          • 捆綁依賴:避免在無關(guān)的技術(shù)組件之間引入新的依賴。

          • 延遲綁定:在使用點才捆綁依賴關(guān)系。

          3.服務(wù)設(shè)計原則

          (1)優(yōu)化遠程調(diào)用

          服務(wù)間的遠程調(diào)用分為同步調(diào)用和異步調(diào)用兩種模式。應(yīng)當分析服務(wù)調(diào)用場景,選擇較優(yōu)的調(diào)用模式。

          (2)去掉冗余數(shù)據(jù)

          盡量去掉接口實體中客戶端不需要的冗余字段,既能減少網(wǎng)絡(luò)開銷,又能避免給前端解析帶去復(fù)雜性。

          (3)設(shè)計粗粒度的服務(wù)接口

          服務(wù)接口若能與前端一個用例或一個業(yè)務(wù)場景相對應(yīng)(粒度較粗),則既能減少遠程調(diào)用次數(shù),又能降低學(xué)習(xí)成本。

          (4)識別并設(shè)計通用的服務(wù)接口

          由于中心服務(wù)不限定應(yīng)用范圍,因此一般要支持不同的應(yīng)用。但不同應(yīng)用在功能豐富性上有很大差異,這就決定了服務(wù)接口需要盡可能保證廣泛兼容性。譬如,服務(wù)接口的參數(shù)和返回值必須是被廣泛支持的較簡單的數(shù)據(jù)類型。

          (5)隔離服務(wù)內(nèi)部的變化

          避免服務(wù)內(nèi)部的領(lǐng)域模型直接傳導(dǎo)給客戶端。如未能提供合理的隔離措施,則當服務(wù)進行內(nèi)部重構(gòu)時,勢必導(dǎo)致客戶端頻繁變化。

          (6)服務(wù)接口先行

          詳細規(guī)定服務(wù)與客戶端雙方對接的內(nèi)容與形式等,對雙方形成強有力的約束和保障。

          (7)服務(wù)接口向下兼容

          由于應(yīng)用的廣泛性,在服務(wù)公開發(fā)布之后就要保證相當?shù)姆€(wěn)定性,不能隨便重構(gòu),即使升級也要盡可能考慮向下兼容性。

          4.服務(wù)命名原則

          強烈建議使用服務(wù)使用者專業(yè)領(lǐng)域內(nèi)有意義的名稱,優(yōu)先選用業(yè)務(wù)概念而不是技術(shù)概念。

          使用名詞命名服務(wù),使用動詞命名操作。

          5.服務(wù)顆粒度原則

          服務(wù)應(yīng)是內(nèi)聚而完整的,能夠獨立完成一個職責(zé)。在服務(wù)內(nèi)部可以是由多個邏輯上密切相關(guān)的代碼塊共同組成。

          6.服務(wù)的無狀態(tài)性原則

          微服務(wù)體系的基本要求是服務(wù)無狀態(tài)。無狀態(tài)的服務(wù)是可伸縮、高可用性的基礎(chǔ)。

          7.服務(wù)操作設(shè)計原則

          操作表示業(yè)務(wù)動作,應(yīng)當使用具體的業(yè)務(wù)含義而不是泛型操作來定義操作。相關(guān)的最佳實踐如下:
          • 重要的服務(wù)不能依賴非重要服務(wù)。

          • 任何服務(wù)調(diào)用都要設(shè)定超時時間。

          • 任何服務(wù)的調(diào)用結(jié)果只有三種可能:成功、失敗或未知。

          • 能異步調(diào)用的服務(wù)盡量使用異步調(diào)用,從而提高系統(tǒng)響應(yīng)速度,降低系統(tǒng)之間的耦合性。

          • 系統(tǒng)拆分時,粒度大小以一個系統(tǒng) 3~8 個開發(fā)人員維護為宜。

          • 系統(tǒng)拆分時,往往先拆分數(shù)據(jù)服務(wù)層,因為數(shù)據(jù)服務(wù)層通常是復(fù)用性高的一層。

          • 服務(wù)的實現(xiàn)不能有單點。

          • 線上遵循 fast-fail 原則,避免服務(wù)調(diào)用時間過長,導(dǎo)致性能下降。fast-fail 原則是只要發(fā)生錯誤,則調(diào)用立即返回。

          • 需要對高壓場景下的服務(wù)調(diào)用鏈路進行特殊處理,可采用將鏈路縮短、預(yù)熱等方式。

          • 服務(wù)設(shè)計過程中,要避免同類服務(wù)由不同服務(wù)單元提供。

          • 服務(wù)要做到向后兼容,如果無法做到,則需要采取管控機制確保服務(wù)消費者升級服務(wù)。

          • 服務(wù)化架構(gòu)的變化要使組織的架構(gòu)能適應(yīng)這種變化。

          • 在部署服務(wù)單元時,要將讀服務(wù)和寫服務(wù)分離,將核心服務(wù)和非核心服務(wù)分離,以保證整個服務(wù)單元的穩(wěn)定性和可靠性。

          • 服務(wù)化時,要同時考慮安全。

          • 靜態(tài)資源也可以實現(xiàn)服務(wù)化,實現(xiàn)靜態(tài)資源與動態(tài)資源分離,從而提高性能。

          • 通過在外層系統(tǒng)埋點,可以實現(xiàn)面向終端用戶服務(wù)的精細管理,比如服務(wù)的容量、服務(wù)的性能等。

          • 需要將每個業(yè)務(wù)領(lǐng)域的通用規(guī)則沉淀成服務(wù)。

          8.服務(wù)約束原則

          • 上可依賴下。
          • 下不可依賴上。
          • 上可跨級依賴下。
          • 平級可允許單向調(diào)用,堅決禁止循環(huán)依賴。
          • 高級別不可依賴低級別。
          • 簡單就是美。
          • 重要的服務(wù)不能依賴非重要服務(wù)。

          二、分布式運行機制

          中臺采用微服務(wù)風(fēng)格進行建設(shè),每一個業(yè)務(wù)中心都是獨立部署的,因此分布式運行機制是保障業(yè)務(wù)中臺正常運行的基礎(chǔ)。無狀態(tài)的微服務(wù)易于擴展和部署,對彈性伸縮、灰度發(fā)布等互聯(lián)網(wǎng)場景有良好的支持。

          同時微服務(wù)架構(gòu)也帶來了復(fù)雜性,一個微服務(wù)應(yīng)用一般由多個服務(wù)組成,每個服務(wù)又有多個實例,因此一套中臺系統(tǒng)部署上線后,至少有幾十個節(jié)點提供服務(wù)。為了管理眾多的微服務(wù),我們需要解決諸如如何使配置一致、如何實時監(jiān)控、如何發(fā)現(xiàn)新服務(wù)、錯誤如何定位等問題。

          1.服務(wù)注冊與發(fā)現(xiàn)

          服務(wù)注冊是服務(wù)發(fā)現(xiàn)機制的核心,服務(wù)實例將自己的服務(wù)信息(包括網(wǎng)絡(luò) IP、端口、服務(wù)名)注冊到服務(wù)注冊中心,服務(wù)注冊中心將服務(wù)信息以及服務(wù)健康狀態(tài)通過 API 暴露出來。服務(wù)消費方通過注冊中心獲取到服務(wù)實例信息,并通過 IP、端口、服務(wù)名的組合去請求服務(wù)提供方提供的服務(wù)。

          除了完成以上核心功能外,服務(wù)注冊與發(fā)現(xiàn)還需要實時監(jiān)控服務(wù)實例的健康狀態(tài),一旦服務(wù)實例不可用,將通知各服務(wù)消費方移除無效服務(wù)實例。另外,一個服務(wù)可能存在多個服務(wù)實例,需要根據(jù)不同的負載均衡算法來保持服務(wù)調(diào)用的均衡。

          2.彈性伸縮

          在分布式集群里通過服務(wù)探針,可以監(jiān)控應(yīng)用和服務(wù)容器的狀態(tài),自動調(diào)整服務(wù)實例的數(shù)量。擴容,在監(jiān)控到服務(wù)容器出現(xiàn)瓶頸,包括負載、CPU、RT 指標都出現(xiàn)緊張時,能夠自動增加應(yīng)用實例到集群中??s容,在監(jiān)控到服務(wù)容器負載減少出現(xiàn)資源浪費時,自動釋放服務(wù)實例減少成本。調(diào)整彈性伸縮的規(guī)則支持用戶靈活配置。

          3.限流降級

          在互聯(lián)網(wǎng)應(yīng)用場景下,用戶的訪問并不總是均勻平穩(wěn)的,時常會出現(xiàn)瞬時的高峰,比如活動期間。分布式應(yīng)用服務(wù)需要提供限流功能,時刻感知流量的變化,并做出相應(yīng)調(diào)整。限流的策略可分為限制訪問的絕對數(shù)量和控制流速(整流)。整流的算法有令牌桶算法,限制總數(shù)可通過設(shè)置規(guī)則來實現(xiàn)。

          降級是指某個服務(wù)被調(diào)低級別后,本服務(wù)的消費者在調(diào)用時即刻返回失敗,這樣服務(wù)實例將不會被調(diào)用。當然,也可以設(shè)置一個默認返回值。降級的規(guī)則支持用戶靈活配置。

          4.灰度發(fā)布

          灰度發(fā)布的技術(shù)用于兩個不同版本同時在線上并行的情形,既可用于業(yè)務(wù)試錯,也可用于版本發(fā)布。一旦確認新版本達到目的,就可以平滑地從舊版本切換到新版本上?;叶劝l(fā)布需要解決兩個方面的問題,才能順利達成目的。

          (1)多版本部署

          多版本部署分為客戶端部署和服務(wù)端部署兩個方面??蛻舳巳绻窃到y(tǒng),可以用熱更新技術(shù)實現(xiàn),比如 Android 的 CodePush。客戶端如果是 H5,則需要在服務(wù)器端部署一套 CSS 和頁面。服務(wù)端部署要求應(yīng)用服務(wù)、中臺服務(wù)都要單獨部署一套,通過版本來區(qū)分。如果需要對 MQ 的數(shù)據(jù)消費進行隔離,則需要重新定義 Topic 或 Tag。

          (2)流量切分

          流量切分包括入口流量切分和中臺服務(wù)流量切分。入口流量的切分策略通常包括按服務(wù)器權(quán)重、IP 地址段或用戶標簽等來切分流量。中臺服務(wù)流量切分通過分布式服務(wù)發(fā)現(xiàn)機制,植入流量切分規(guī)則,控制流量的方向。

          5. 消息隊列服務(wù)

          消息隊列服務(wù)是互聯(lián)網(wǎng)應(yīng)用場景下非常重要的一個技術(shù)中間件。在業(yè)務(wù)上,通過消息隊列既可以提高用戶體驗,又可以支撐 IM 業(yè)務(wù)等;在技術(shù)上既可以解耦系統(tǒng),又可以削峰填谷等。消息隊列具有高性能、高可用、最終一致性等技術(shù)特點,是技術(shù)架構(gòu)的重要組成部分。

          (1)異步通信

          消息發(fā)送方將耗時較長且無須實時處理的操作封裝為消息,發(fā)送給消息隊列服務(wù)。發(fā)送方無須等待消息被消費方處理完成,可以繼續(xù)做其他事情。消費方則可以按自己的節(jié)奏完成消息的消費。異步通信可用于系統(tǒng)間的解耦,各系統(tǒng)獨立自主,互不影響;也可用于減少請求響應(yīng)時間,提升用戶體驗。

          (2)高可用

          消息隊列服務(wù)以集群的方式部署,常見的有 1 主多備或 2 主 2 備等。消息服務(wù)接收到消息后,會同時分發(fā)給多個備份服務(wù)各自創(chuàng)建一個備份。當一臺消息隊列服務(wù)掛掉后,另一臺消息備份服務(wù)可以無縫對接,及時提供服務(wù)。在 RPC 調(diào)用方面,提供了負載均衡、服務(wù)注冊與發(fā)現(xiàn)功能,保證了消息隊列服務(wù)在高并發(fā)場景下的高可用。

          (3)高可靠

          消息隊列服務(wù)提供了極高的可靠性,不過應(yīng)用開發(fā)時還需要統(tǒng)一提供 retry 機制,進一步提高可靠性,降低應(yīng)用開發(fā)的復(fù)雜性。消息隊列服務(wù)在收到消息后,會立即執(zhí)行消息的持久化處理。比較常見的持久化方式包括存儲到文件和存儲到數(shù)據(jù)庫兩種。持久化機制包括同步雙寫和異步復(fù)制,保證了數(shù)據(jù)的高可靠性。

          (4)基于消息的最終一致性

          使用半消息技術(shù),保證只要一個事件發(fā)生后,關(guān)聯(lián)的結(jié)果事件一定會發(fā)生。半消息解決了如下問題:
          • 事件發(fā)生后,事件消息發(fā)送卻失??;

          • 事件消息發(fā)送成功后,消息代理推送給消息消費方卻失??;

          • 消費方重復(fù)消費此消息。


          使用半消息技術(shù),在事件發(fā)生前,先成功發(fā)送一個半消息,這樣就保證了事件發(fā)生的消息一定能夠發(fā)送成功。消息代理增加了事件結(jié)果查詢功能,保證了事件觸發(fā)成功后一定將消息推送給消費方。

          消息代理保證消息推送至少 1 次,但要求消費方自己實現(xiàn)冪等性,避免出現(xiàn)異常。冪等性的保證,可以通過為每一個事件創(chuàng)建唯一 ID,消費方增加一個過濾服務(wù),每處理一個事件都會通過存儲這個事件 ID 來實現(xiàn)。當消費方收到事件消息后,過濾服務(wù)會查詢本事件 ID 是否已經(jīng)消費過。

          6.分布式事務(wù)

          分布式事務(wù)技術(shù)(DTP)用于保證跨多個資源事務(wù)的一致性,目前 X/Open XA 標準已由眾多廠家實現(xiàn)來支持分布式事務(wù)。DTP 模型的典型應(yīng)用場景是兩階段提交協(xié)議,多個資源管理器(RM)由一個事務(wù)管理器(TM)進行管理,事務(wù)管理器控制著全局事務(wù)和分支事務(wù)。

          DTP 模型分別通過準備階段和提交階段來協(xié)作完成全局事務(wù):準備階段,由 TM 通知各 RM 準備事務(wù),并接收 RM 的準備結(jié)果;提交階段,由 TM 通知各 RM 提交分支事務(wù),并接收 RM 的執(zhí)行結(jié)果。RM 執(zhí)行結(jié)果都成功,那么 TM 返回成功,如果任意一個 RM 執(zhí)行失敗,原則上 TM 都會執(zhí)行回滾。但在實踐過程中,RM 失敗的情況也有不同,TM 可按照客戶的需要判定是否回滾所有事務(wù)。

          目前,各大云廠商都提供了分布式全局事務(wù),其中阿里云的 GTS 已經(jīng)實現(xiàn)了分布式全局事務(wù)。在應(yīng)用場景涉及的系統(tǒng)和步驟不是特別多的情況下,GTS 可以方便快速地實現(xiàn)分布式事務(wù)。

          (本文摘錄自《中臺戰(zhàn)略:中臺建設(shè)與數(shù)字商業(yè)》)



          推薦閱讀:

          世界的真實格局分析,地球人類社會底層運行原理

          不是你需要中臺,而是一名合格的架構(gòu)師(附各大廠中臺建設(shè)PPT)

          企業(yè)IT技術(shù)架構(gòu)規(guī)劃方案

          論數(shù)字化轉(zhuǎn)型——轉(zhuǎn)什么,如何轉(zhuǎn)?

          華為干部與人才發(fā)展手冊(附PPT)

          企業(yè)10大管理流程圖,數(shù)字化轉(zhuǎn)型從業(yè)者必備!

          【中臺實踐】華為大數(shù)據(jù)中臺架構(gòu)分享.pdf

          華為的數(shù)字化轉(zhuǎn)型方法論

          華為如何實施數(shù)字化轉(zhuǎn)型(附PPT)

          超詳細280頁Docker實戰(zhàn)文檔!開放下載

          華為大數(shù)據(jù)解決方案(PPT)





          瀏覽 43
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  成人网站观看免费 | 天堂网中文字幕在线观看 | 手机观看AV | 国产夫妻精品自拍 | 69成人网 |