結(jié)合DDD與服務(wù)網(wǎng)格的網(wǎng)絡(luò)輿情分析系統(tǒng)設(shè)計與實現(xiàn)

韓 鈺，丁 悅，石明翔，郭昕銳，郭子巖

（北京城市學(xué)院信息學(xué)部，北京 100080）

0 引言

當前，微服務(wù)架構(gòu)［1］已成為軟件開發(fā)領(lǐng)域的熱點之一，特別是在分布式環(huán)境下，微服務(wù)已經(jīng)成為首選架構(gòu)。許多互聯(lián)網(wǎng)公司都在廣泛地應(yīng)用微服務(wù)架構(gòu)，同時許多傳統(tǒng)企業(yè)也在利用微服務(wù)和容器進行互聯(lián)網(wǎng)技術(shù)轉(zhuǎn)型。在這個過程中，Dubbo 和Spring Cloud 等傳統(tǒng)微服務(wù)框架成為國內(nèi)最受歡迎的開發(fā)框架之一。然而，軟件開發(fā)沒有單一的解決方案，基于這些傳統(tǒng)框架構(gòu)建的應(yīng)用系統(tǒng)在享受開發(fā)的同時也面臨一些痛點，因此需要進一步研究和探索新的方案來解決這些問題。

針對上述問題，國內(nèi)做了很多的研究，廖艷艷［2］、彭永勇等［3］研究分析了Istio 在企業(yè)級微服務(wù)管理方面的相關(guān)問題。論述中提到，采用Istio 服務(wù)網(wǎng)格之后企業(yè)級微服務(wù)系統(tǒng)可以實現(xiàn)獨立運行、動態(tài)擴容、鏈路追蹤等功能，相較于面向服務(wù)的架構(gòu)和SpringCloud 等框架，Istio能夠幫助企業(yè)有效降低開發(fā)和運維成本，提高企業(yè)的效率。因此，本文以網(wǎng)絡(luò)輿情分析系統(tǒng)為例，嘗 試 使用DDD 和ServiceMesh［4］等 技術(shù)，實現(xiàn)基于領(lǐng)域驅(qū)動與服務(wù)網(wǎng)格的網(wǎng)絡(luò)輿情分析系統(tǒng)，使用領(lǐng)域驅(qū)動設(shè)計對網(wǎng)絡(luò)輿情分析系統(tǒng)進行拆分，使其更加易于迭代和擴展，滿足開閉原則。在此基礎(chǔ)上使用Kuberbetes和Istio等技術(shù)把系統(tǒng)整合進服務(wù)網(wǎng)格（Service Mesh）中并進行服務(wù)治理，對系統(tǒng)實現(xiàn)負載均衡、熔斷、限流、可插拔的服務(wù)安全、服務(wù)運行可觀察性等治理能力。

本文所治理和監(jiān)控的網(wǎng)絡(luò)輿情分析系統(tǒng)的主要功能是為相關(guān)部門提供智能化決策支持，提升應(yīng)對處理輿情的速度，以此來引導(dǎo)輿論方向，快速化解危機輿論。此項目是在原單體架構(gòu)的基礎(chǔ)上，設(shè)計出態(tài)勢感知、輿情分析、智能決策和輿情預(yù)警等功能。主要用于多源網(wǎng)絡(luò)內(nèi)容的篩選與檢測、影響力評價模型的建立與分析、系統(tǒng)核心業(yè)務(wù)的實現(xiàn)。系統(tǒng)功能主要包括：自然語言處理、多維度查詢、智能分析及決策支持、系統(tǒng)管理等模塊。

1 基于領(lǐng)域驅(qū)動設(shè)計的服務(wù)子集劃分

領(lǐng)域驅(qū)動設(shè)計（domain driven design，DDD）的概念誕生于2003 年，由Evans［5］提出。它是一種設(shè)計思想方法論，用來指導(dǎo)將復(fù)雜問題進行拆分、找出各子系統(tǒng)間的關(guān)聯(lián)，來解決復(fù)雜系統(tǒng)開發(fā)中遇到的問題。在領(lǐng)域模型創(chuàng)建后，DDD 得到需求的第一步是通過領(lǐng)域模型的變化來指導(dǎo)數(shù)據(jù)和業(yè)務(wù)的變化，而不是將其分割，對數(shù)據(jù)和業(yè)務(wù)的變化分別考量，這樣會造成需求的前后分離。DDD 首先考慮的是業(yè)務(wù)模型，而不是數(shù)據(jù)。

整體服務(wù)拆分共分為三步，首先是梳理需求劃分子域；其次是創(chuàng)建領(lǐng)域模型；最后是對限界上下文中的實體、值對象、聚合根等信息進行挖掘。

1.1 劃分子域

對領(lǐng)域驅(qū)動設(shè)計而言，在分析較為復(fù)雜的問題域時，可以采用“分而治之”的思想［6］，將復(fù)雜的功能需求拆分成子域。根據(jù)賈子甲［7］在先啟階段對微服務(wù)系統(tǒng)拆分方法的研究對本系統(tǒng)進行拆分得到的限界上下文［8］（本系統(tǒng)中子域約等于限界上下文）為：數(shù)據(jù)中心模塊、管理中心模塊、消息中心模塊、智庫中心模塊，輿情中心模塊，如圖1所示。

圖1 基于DDD劃分的子域

1.2 建立領(lǐng)域模型

通過領(lǐng)域驅(qū)動設(shè)計方法繪制領(lǐng)域模型，從而確定業(yè)務(wù)和應(yīng)用邊界，保證業(yè)務(wù)模型與代碼模型的一致性。如果存在一個類被多個程序包所依賴，甚至成為“上帝類”時，開發(fā)工作就必須協(xié)調(diào)開發(fā)的工序，而這一協(xié)調(diào)過程也將是反復(fù)和低效的。理想情況下，我們希望一個變更只影響一個敏捷團隊或者一個服務(wù)［9］。通過DDD 的方法對網(wǎng)絡(luò)輿情分析系統(tǒng)進行設(shè)計和構(gòu)建，發(fā)掘重要的業(yè)務(wù)領(lǐng)域概念，建立業(yè)務(wù)領(lǐng)域概念之間的關(guān)系。

本系統(tǒng)的領(lǐng)域模型劃分如圖2所示。表示層負責(zé)與用戶交互，向用戶呈現(xiàn)數(shù)據(jù)，并處理用戶輸入的請求；應(yīng)用層負責(zé)協(xié)調(diào)領(lǐng)域?qū)拥母鱾€對象來完成用戶請求，同時處理來自表示層的請求和領(lǐng)域?qū)拥捻憫?yīng)；領(lǐng)域?qū)迂撠?zé)存放業(yè)務(wù)中總結(jié)的聚合根、實體、對象和業(yè)務(wù)的處理邏輯，同時對業(yè)務(wù)規(guī)則進行驗證和實施；對限界上下文中相關(guān)的詳細信息會在后文分開說明；基礎(chǔ)設(shè)施層負責(zé)提供基礎(chǔ)設(shè)施支持，通過防腐層進行數(shù)據(jù)庫訪問、網(wǎng)絡(luò)連接等，以便達到保護領(lǐng)域?qū)又袠I(yè)務(wù)的目的。

圖2 網(wǎng)絡(luò)輿情分析系統(tǒng)的領(lǐng)域模型

1.3 限界上下文元素分析

以數(shù)據(jù)中心為例進行主要元素分析，其限界上下文的分析結(jié)果見表1。

表1 數(shù)據(jù)中心關(guān)鍵元素分析表

輿情是一個重要的實體，包含了輿情標簽、話題關(guān)注度、輿情所屬平臺和輿情來源的網(wǎng)民等值對象。時間段是一個實體，用于表示輿情數(shù)量趨勢變化和近三年追蹤輿情數(shù)量趨勢變化等趨勢分析的相關(guān)信息。用戶操作是一個實體，用于記錄用戶對輿情系統(tǒng)的使用情況，例如添加、修改、刪除等操作。

輿情狀態(tài)分析功能中，聚合根是“輿情狀態(tài)分析”，它由輿情實體和狀態(tài)值對象組成。輿情實體代表一條具體的輿情信息，狀態(tài)值對象代表輿情的狀態(tài)，其中的狀態(tài)有：已處理、已解決、已退回、未處理、線上回應(yīng)等。每條輿情信息都對應(yīng)著一個狀態(tài)，輿情實體的生命周期由聚合根控制。

2 基于服務(wù)網(wǎng)格的系統(tǒng)架構(gòu)

通過領(lǐng)域驅(qū)動設(shè)計拆分的系統(tǒng)中存在多個服務(wù)，如果單獨進行部署就會存在配置管理困難、版本迭代時操作復(fù)雜、服務(wù)間調(diào)用情況無法監(jiān)控等問題，因此要進行服務(wù)網(wǎng)格［10］治理。

服務(wù)網(wǎng)格是一種用于管理和控制分布式系統(tǒng)中的服務(wù)間通信的基礎(chǔ)設(shè)施。它通過將網(wǎng)絡(luò)基礎(chǔ)設(shè)施從應(yīng)用程序中分離出來，為應(yīng)用程序提供透明的服務(wù)間通信，并提供諸如路由、負載均衡、故障恢復(fù)、監(jiān)視等功能。服務(wù)網(wǎng)格通常由一組網(wǎng)絡(luò)代理組成，這組代理通常是以Sidecar 形式實現(xiàn)，它與應(yīng)用程序運行在同一容器內(nèi)，通過共享網(wǎng)絡(luò)命名空間和卷等方式與服務(wù)集成在一起攔截服務(wù)請求和響應(yīng)。通過這種方式，可以在不修改應(yīng)用程序代碼的情況下提供額外的功能和可靠性保障。

本系統(tǒng)架構(gòu)采用分布式服務(wù)網(wǎng)格高可用的架構(gòu)方式，使用DDD 的方法論進行拆分，被拆分成如圖2所示的智庫中心、管理中心、消息中心等五個服務(wù)子集。每個服務(wù)子集通過docker進行容器化后以pod 形式運行并管理，使用Kubernetes 實現(xiàn)容器編排、動態(tài)擴展等功能，使用Istio 管理流量規(guī)則和策略來控制服務(wù)間通信，進而實現(xiàn)服務(wù)治理。

服務(wù)中每一個pod 中都會有一個以Sidecar模式存在的Envoy，Envoy 從Istio 中心獲取各服務(wù)的地址并把請求轉(zhuǎn)發(fā)到對應(yīng)服務(wù)的Envoy 中，再由其轉(zhuǎn)到服務(wù)中，通過Envoy來進行各服務(wù)注冊和發(fā)現(xiàn)服務(wù)之間的網(wǎng)絡(luò)代理。如圖3所示。

圖3 服務(wù)網(wǎng)格架構(gòu)圖

各責(zé)任單位發(fā)出消息請求到Ingress 進行統(tǒng)一接入和負載均衡，之后轉(zhuǎn)發(fā)到擁有Nginx 的pod 中進行靜態(tài)資源的請求。用ActiveMQ 進行異步通信實現(xiàn)削峰處理，讓通信具有良好的峰值處理能力和送達保障，其中用戶管理服務(wù)、輿情信息管理服務(wù)、輿情監(jiān)控服務(wù)、輿情反饋管理服務(wù)采用邊車代理進行通信，通過Envoy進網(wǎng)絡(luò)代理；服務(wù)網(wǎng)格控制中心實現(xiàn)服務(wù)編排、流量控制規(guī)則管理、服務(wù)發(fā)現(xiàn)、負載均衡規(guī)則管理等機制，實現(xiàn)系統(tǒng)的動態(tài)擴容和高可用。

3 實驗與分析

為了驗證系統(tǒng)的執(zhí)行效率，本文環(huán)境采用三臺阿里云服務(wù)器，一個為主節(jié)點Master，兩個子節(jié)點node1、node2，云服務(wù)器硬件配置為一臺4核和8 GB內(nèi)存的云服務(wù)器、兩臺2核和2 GB內(nèi)存的云服務(wù)器，使用的操作系統(tǒng)為Centos8.2 64 位。在實驗中，被網(wǎng)格化和未被網(wǎng)格化的網(wǎng)絡(luò)輿情系統(tǒng)依次做了兩組實驗，其中吞吐量的差異如圖4所示。

圖4 不同架構(gòu)下執(zhí)行效率對比圖

并發(fā)數(shù)大于200時，未經(jīng)過領(lǐng)域驅(qū)動拆分和經(jīng)過領(lǐng)域驅(qū)動拆分的吞吐量仍相對同步遞增，但未經(jīng)過領(lǐng)域驅(qū)動拆分的程序，吞吐量在達到一定并發(fā)量后便停止上升，反而有下降的趨勢，其原因判斷為未經(jīng)過服務(wù)治理的程序達到了硬件性能的上限，其緩存和負載均衡也不能進一步提升程序的性能。領(lǐng)域驅(qū)動拆分后，因為有動態(tài)擴容負載均衡和降級熔斷方法的影響，使得吞吐量相對于未經(jīng)領(lǐng)域驅(qū)動拆分的可以進一步增長。

并發(fā)數(shù)達到本次最大時，很明顯可以看到，未經(jīng)領(lǐng)域驅(qū)動拆分和經(jīng)過領(lǐng)域驅(qū)動拆分的吞吐量差距顯著，此時可以證明，本系統(tǒng)中使用的領(lǐng)域驅(qū)動拆分有著明顯的成效。

4 結(jié)語

本文通過領(lǐng)域驅(qū)動設(shè)計從子域劃分到主要元素分析，對網(wǎng)絡(luò)輿情系統(tǒng)進行服務(wù)子集劃分，從而更好地應(yīng)對復(fù)雜業(yè)務(wù)，使技術(shù)實現(xiàn)與業(yè)務(wù)更好地分離，使外部調(diào)用與內(nèi)部系統(tǒng)相互隔離。本文研究了有關(guān)服務(wù)網(wǎng)格的理論與Istio 的應(yīng)用，并使用kuberbetes 與Istio 對經(jīng)過DDD 拆分后的系統(tǒng)進行網(wǎng)格化，降低了運營維護成本，提高了微服務(wù)的可擴展性和可用性。通過實驗結(jié)果的對比分析證明，在經(jīng)過領(lǐng)域驅(qū)動拆分和服務(wù)網(wǎng)格治理后系統(tǒng)有著良好的性能。