大型電網企業應用系統服務化改造方法研究

蒙亮 胡俊楊

[摘? ? 要] 十三五期間，隨著電網信息化支撐業務領域的廣度和深度不斷增強，傳統IT架構如何適應“互聯網+電網”形勢下的戰略轉型，成為電網信息化管理過程中的迫切需求和需要思考的問題。本文基于許多大型電網企業多年來的架構應用實踐，詳細闡述了如何以領域驅動設計（簡稱：DDD）為指導思想，對復雜的應用系統進行服務拆分。

[關鍵詞] IT架構;領域驅動;服務拆分

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2018. 21. 033

[中圖分類號] F270.7;TP393.09? ? [文獻標識碼]? A? ? ? [文章編號]? 1673 - 0194（2018）21- 0085- 03

1? ? ? 前? ? 言

1.1? ?背景與意義

隨著網絡安全法的發布實施、大數據、云計算、移動互聯網、物聯網、人工智能等新技術發展日新月異，供給側結構性改革、電力體制改革、國資國企改革、“一帶一路”、“互聯網+”等新政策的不斷推進，許多電網企業的發展處于重要戰略機遇期、轉型升級期、改革深化期。內外部環境的深刻變化，直接對電網企業信息化建設提出了新要求。大多數電網企業需要信息化手段來支撐主營業務的深化改革及競爭型業務的創新發展。

IT架構升級是大型電網企業推進信息化建設過程中必不可少的環節之一，它除了需要充分考慮業務轉型與新技術應用的發展外，還涉及基礎設施、運行時環境、服務框架、數據訪問框架、工作流程、工作臺和云管理等基礎性軟硬件平臺和關鍵技術的整合應用。關于服務如何抽象，應用系統架構如何進行應用化改造，是IT架構升級過程中的關鍵問題。

1.2? ?主要工作

本文針對IT服務架構中最為關鍵的服務抽象設計，引入領域驅動設計技術，實現服務和組件的拆分。主要的研究內容包含以下幾個方面。

（1）戰略設計模式理論包括：識別領域、劃分子域、尋找核心域、支撐域和通用域、劃定限界上下文和建立上下文映射圖。戰略設計模式是系統的業務框架設計，保證了領域模型的完整性。

（2）戰術設計模式理論主要包括：實體、值對象、聚合、識別領域事件等。戰術模式解決了領域的最小業務單元高內聚[1]。

2? ? ? 技術發展分析

自Eric Evans提出新的軟件開發方法DDD后，在國內外出現許多DDD理論的研究者和實踐者。

國外有許多專家對DDD的發展做出了卓越貢獻，例如Greg Young對Betrand Meyer的CQS模式進行改造，提出CQRS模式，Vaughn Verno完善了DDD思想，正式提出了領域事件模式以及六邊形架構風格實現DDD。

隨著國內的互聯網公司逐漸深入實體經濟，業務日益復雜，領域模型在一個復雜的體系里變得尤為重要。國內的盒馬鮮生已經成功將DDD運用到實際的開發中，在互聯網架構下完整實施具有阿里特點的領域驅動設計模式。目前已經有許多開發人員嘗試著將DDD應用到銀行、航空、物流及信息系統等項目中，隨著云計算、微服務框架等新技術發展完善，DDD將有更多的應用場景。

3? ? ? 必要性分析

“十二五”期間，許多電網企業信息化處于大建設期，與應用系統的大規模建設的現實相適應，電網企業選擇成熟穩定、為人熟知、IDE友好、便于共享、易于開發、部署和測試的單塊架構，采用傳統軟件開發方法開展企業級應用建設;上述模式在大建設期充分發揮了其自身特點，促進了電網企業應用建設的迅速開展。

隨著業務的不斷擴大，需求功能的持續增加，單塊架構已經很難滿足業務快速變化的需要。一方面，代碼的可維護性、擴展性、靈活性在降低;而另一方面，系統的測試成本、構建成本以及維護成本卻在顯著增加。因此，隨著項目或者產品規模的不斷擴大，單塊架構應用的改造與重構勢在必行。

4? ? ? 規劃方案

垂直拆分：依據領域驅動理念，收集資料，了解系統背景，識別領域通用語言。識別領域，劃分子域，尋找核心域、支撐域和通用域，圍繞這些子域劃定限界上下文，建立上下文映射圖。以戰略模型為基石，進行戰術建模：識別實體、值對象，劃分聚合，識別領域事件。戰術的成果幫助概念分離，分析設計原因和領域特征，厘清模型內對象的關系、各種業務規則、數據一致性的設計以及測試用例的設計。

領域服務、倉儲和工廠的設計，幫助分離服務。以“低內聚，高耦合”為原則，建立服務與服務之間的關系，實現事務的一致性。聚合內的服務要求事務高度一致，關鍵聚合根的扭轉實現了動態模型的設計。設計是否符合需求的場景要求，通過場景走查檢驗一切的設計符合度和用戶體驗度。

其總體設計如下圖所示：

4.1? ?資料收集

明確背景和定位，收集業務需求描述，繪制用例及核心業務流程圖。

4.2? ?識別通用語言

領域驅動設計的一個核心的原則是使用一種基于模型的語言。使用模型作為語言的核心骨架，要求團隊在進行所有的交流中都使用一致的語言，在代碼中也是這樣。在共享知識和推敲模型時，團隊會使用演講、文字和圖形。這兒需要確保團隊使用的語言在所有的交流形式中看上去都是一致的，這種語言被稱為“通用語言”。

4.3? ?戰略建模

戰略建模是從宏觀的角度來劃分和集成限界上下文，它包括領域識別，子域及限界上下文劃分（分析出子域、核心域、支撐域）、上下文映射圖。

4.3.1? ?識別領域

一個領域本質上就是一個問題域，只要是同一個領域，那問題域就相同。只有確定系統所屬的領域，才能進而了解系統的核心業務，即要解決的關鍵問題、問題的范圍邊界。

一個領域內可以包含1個或者多個子域。子域又分核心域、支撐子域、通用子域。按照實際功能將這些交織的模型劃分成邏輯上相互分離的子域，從而在一定程度上減少系統的復雜性。

4.3.2? ?劃分子域

一個領域內可以包含1個或者多個子域。理論上一個子域對應一個限界上下文是最優也是最理想的情況，但是有時又要考慮到業務關聯度需要做出權衡。子域又分核心域、支撐子域、通用子域。

4.3.3? ?尋找核心域、支撐域和通用域

所有子域按照子域類型的定義劃分成核心域、支撐域和通用域，具體的內容如下：

核心域：它是整個業務領域的一部分，也是業務成果的主要促成因素。在實施DDD時，主要關注的核心。

支撐域：對應著業務的某些重要方面，但卻不是核心，那么他便是一個支撐子域。

通用域：如果一個子域被用于整個業務系統，那么這個子域便是通用子域。

4.3.4? ?劃定限界上下文

限界上下文是一個由顯式邊界限定的特定職責。領域模型存在于邊界之內。在邊界內，每一個模型概念，包括屬性和操作，都具有特殊的含義。

一個業務領域包含多個限界上下文，與一個限界上下文溝通，需要通過顯式邊界進行通信。系統通過確定的限界上下文解耦，每一個上下文內部緊密組織，職責明確，具有較高的內聚性。

4.3.5? ?劃分聚合

與值對象相反，聚合是實體的合并。聚合是一組相關對象的集合，我們把它作為數據修改的單元。一個聚合包括至少兩個實體與一個根， 根包含了聚合內所有實體的引用，并作為聚合的代表供外界訪問，外界只能通過根來訪問聚合內的實體，而聚合內的實體之間可以隨意互相訪問。包含在聚合內的實體構成了一個整體，當聚合消亡時，它們也將隨之消亡。聚合使得實體間的關系網大大簡化了，聯系緊密的實體可以被放入聚合內部封裝起來，聚合之間的聯系則通過根變得清晰而有條理[2]。

4.3.6? ?識別領域事件

領域事件定義領域專家所關心的事件的對象。當關心的狀態由于模型行為而發生改變時，系統將發布領域事件。

4.3.7? ?模型詳細說明

模型詳細說明主要描述了設計的原因、模型內對象的關系、各種業務規則、數據一致性規則、測試用例等。

（1）緩存存儲。緩存是領域對象在內存中的生存場所，是一種面向業務的存儲方式，而同時我們的領域模型也是一種面向業務的模型，有了面向業務的存儲以后，我們就可以進行面向業務的運算，而正是這種面向業務的運算使得我們的系統具有更好的伸縮性和擴展性。因為此時的領域對象通過緩存都是跑在中間件中，而在負載增多的時候，通過水平的增加中間件服務器來進行水平伸縮。

（2）數據庫設計：①打破外鍵關系。讓一個服務的代碼通過另一個服務暴露的API來訪問數據，而不是直接訪問數據庫。這個API調用會成為微服務化的第一步。這時候可能會有性能擔憂，可以做一個性能測試，如果這個“慢”在可接受的范圍內，就沒有問題。②共享靜態數據。把一些些共享的靜態數據放入代碼，比如放在屬性文件中，或者簡單地放在一個枚舉中。③共享數據。共享的可變數據對于分離系統來說通常是一個麻煩。領域概念不是在代碼中進行建模，相反是在數據庫中隱式地進行建模，這里缺失的領域概念是中間服務。④共享表。兩個業務共用一個表，但是每個業務的關注點不同，我們可以采取行動把它們存儲在不同的上下文中，從而分離出兩張表，分別在對應的兩個服務中。各自依據各自的關注點來建表結構，進行表建模。

（3）事務邊界的處理。事務控制需要注意的事項：①在事務中，不要運行昂貴而不必要的、與事務無關的操作指令，如日志記錄，其磁盤讀寫代價高，非常消耗資源。②不要在瀏覽數據的時候打開事務（設置值@TransactionAttribute（NOT_SUPPORTED））。

事務控制的邊界位于服務層。事務邊界的處理主要有以下幾種方式：

①再試一次。可以對某一個業務先做一次操作，操作終止后，再對另一個業務做另一次操作，這時可以把這部分操作放在一個隊列或者日志文件中，之后再嘗試對其進行觸發。對于某些操作來說這是合理的，但要保證重試能夠修復這個問題。②終止整個操作。另一個選擇是拒絕整個操作。在這種情況下，需要把系統重置到某種一致的狀態，要么重試補償事務，要么使用一些后臺任務來清除這些不一致的狀態。可以給后臺的維護人員提供一個界面來進行該操作，或者將其自動化。③使用分布式事務。手動編配補償事務非常難以操作，一種替代方案是使用分布式事務。分布式事務會橫跨多個事務，然后使用事務管理器的工具來統一編配其他底層系統中運行的事務。就像普通的事務一樣，一個分布式的事務會保證整個系統處于一致的狀態。唯一不同的是，這里的事務會運行在不同系統的不同進程中，通常它們之間使用網絡進行通信。

（4）測試用例。微服務架構中的測試類型主要包括：單元測試、接口測試、集成測試、組件測試和端到端測試。

（5）模塊、倉儲、工廠、領域服務。①模塊：模塊為人們提供了兩種觀察模型的方式，一是可以在模塊中查看細節，而不會被整個模型淹沒，二是觀察模塊之間的關系，而不考慮其內部細節。模塊之間應該是低耦合的，而在模塊內部則是高內聚的。模塊并不僅僅是代碼的劃分，而且也是概念的劃分。②倉儲：倉儲是一組負責領域對象的持久化的服務。從架構角度來看，倉儲用于連接領域層和基礎結構層，領域層通過倉儲訪問存儲機制，而不用過于關心存儲機制的具體細節。按照DDD設計原則，倉儲的作用對象的領域模型的聚合根，也就是說每一個聚合都有一個單獨的倉儲[3]。③工廠：工廠模式（Factory Pattern）是Java中最常用的設計模式之一，在DDD中也被廣泛使用，它是一種體現封裝思想的設計模式。工廠的作用是將創建對象的細節隱藏起來，當創建一個對象時，如果創建工作很復雜，或者暴露了過多的內部結構，則可以使用工廠進行封裝。事實上除了通過工廠來創建對象，大部分情況下領域對象的創建都不會太復雜，所以我們只需要簡單地使用構造函數創建對象就可以了。④領域服務：當領域中的某個操作過程或轉換過程不是實體或值對象的職責時，便應該將該操作放在一個單獨的接口中，即領域服務。如果勉強地把這些重要的領域功能歸為實體或值對象的職責，那么不是歪曲了基于模型的對象的定義，就是人為地增加了一些無意義的對象。應確保領域服務和通用語言是一致的，并且保證它是無狀態的[4]。

（6）動態模型設計。動態模型設計包括業務流程設計、設計關鍵聚合根的狀態流轉圖。

（7）場景走查。確定領域模型、領域服務、倉儲等完成系統用例以及關鍵業務流程，確認領域模型是否能滿足領域中的業務場景和業務流程。

最常用的就是通過序列圖來走查場景，對創建的領域模型進行逐步驗證。

（8）實現架構設計。依據前面的所有分析和設計，最終實現架構設計。部署打包方式為：Jenkins自動化打包，實現持續集成與發布。

5? ? ? 結? ? 語

電網企業業務復雜，應用系統較多，本文提出的應用系統服務化改造方法作為一種指導思想，可以有序推動大型電網企業的IT架構升級，確保IT建設資產與實際業務的符合，有效支撐企業業務運轉，完成從企業信息化到信息化企業的跨越，最終打造安全、可靠、綠色、高效的智能電網。

主要參考文獻

[1][美]Eric Evans.領域驅動設計： 軟件核心復雜性應對之道[M].修訂版.趙俐，譯. 北京：人民郵電出版社，2016.

[2][美]Vaughn Vernon.實現領域驅動設計[M]. 滕云，譯. 北京： 電子工業出版社，2014.

[3]黃文光，金義富. 基于領域驅動設計構建企業級Web平臺的應用[J]. 實驗室研究與探索，2013，32（8）：72-75.

[4]王忠，程磊. 基于領域驅動設計的軟件開發[J]. 軟件導刊，2008， 7（2）：37-39.