微服務架構下規則平臺方案與規則遷移方法

池煒成，史立學，劉智瓊，朱明英

（1.中國電信股份有限公司研究院，廣州510630；2.中國電信集團公司，北京100033）

0 引言

為實現數字化轉型，企業正大規模實踐應用系統上云工程，同時將應用系統由原有的MA架構（Mono?lithic Architecture，單體架構）轉變為MSA架構（Mi?croservice Architecture，微服務架構），升級為基于云平臺的微服務化系統。微服務架構遵循職責單一、數據自治、獨立部署與運維等理念，通常按業務領域將單體系統拆分成多個微服務，不同業務子域的業務邏輯歸入到不同微服務中。業務規則處理是業務邏輯的重要組成部分，所以不同子域的業務規則相應被劃分到不同的微服務中處理。然而，在微服務架構下，由于各個微服務可以根據自身的功能、性能、可靠性等不同要求確定自身的實現方式，所以不同的微服務可能采取了不同的業務規則實現方式，如硬編碼方式、文件配置方式、數據庫配置方式、內嵌規則引擎方式等，而這些差異很容易導致微服務化系統的業務規則管理出現問題，包括業務規則管理分散、無法看到整體的規則視圖和定義、無法統一監控業務規則執行情況等等，在微服務架構中引入業務規則平臺是解決這些問題的有效辦法。

1 微服務架構與業務規則

單體架構系統的代碼耦合性強，程序統一開發、打包和部署，而隨著應用系統越來越復雜，單體系統業務擴展能力差、難以升級維護等問題越來越明顯。為了解決問題，業界提出了微服務架構，它按照分而治之、關注分離的思想將單體系統分解為多個小而自治的微服務，例如BSS（Business Supporting System，業務支撐系統）微服化后，系統拆分為客戶中心、訂單中心、促銷中心、商品中心、批價中心、帳務中心等多個微服務，每個微服務相對獨立，可以獨立開發、打包和部署，有獨立的數據庫，令每個微服務可以專注完成某個業務子域的功能，微服務間通過調用輕量級服務的方式獲得對方的數據或服務。微服務的高內聚性、高擴展性和高自治性等能夠較好地解決單體架構的問題。

微服務架構一般包含五層：基礎設施層、服務支撐層、業務邏輯層、訪問層和門戶層，其中服務支撐層為微服務提供服務管理等公共服務，業務邏輯層包含多個微服務。服務支撐層包含各種支撐微服務體系運行的公共能力，包括服務注冊、服務監控、服務日志、服務調用鏈等等。在業務邏輯層，微服務通常根據業務領域功能劃分，遵循“單一職責原則”，每個微服務專注完成一個業務子領域的功能，專門處理一個業務子域的業務邏輯。業務規則是對業務策略的定義和約束，是微服務業務邏輯的重要組成部分，例如，客戶中心微服務負責客戶實名認證規則的處理、訂單中心微服務負責訂單檢驗規則的處理、促銷中心微服務負責積分贈送規則的處理，等等。業務規則處理在微服務架構中的位置如圖1所示。

圖1 微服務架構

2 業務規則實現方式與存在問題

由于每個微服務相對獨立，不同微服務可以采用不同的技術實現，所以在微服務架構下，各個微服務對業務規則實現可能存在多種方式，甚至同一微服務中的不同業務規則也可能使用了不同方式，這些方式包括硬編碼方式、文件配置方式、數據庫配置方式、內嵌規則引擎方式等。

在硬編碼方式中，在微服務程序中直接編寫業務規則處理的邏輯代碼，包括規則的條件和動作語句，而且規則中使用的數值是在程序中固化的，以為積分贈送規則為例，業務規則的邏輯表達如下：如果客戶是七星客戶且當月帳單額不少于100元，那么當月贈送1000電信積分，“如果”部分表達了規則條件，“那么”部分表達了規則動作。在硬編碼方式中，規則的條件和動作以及閾值“7”、“100”、“1000”都寫在代碼中，在此種方式下，當條件或動作的結構發生變化（如：增加一個判斷條件）或者任一閾值發生變化時都要修改程序代碼。

文件配置方式是在后臺的配置文件中配置業務規則的條件和動作，包括涉及的屬性及閾值，微服務程序代碼先從文件中讀取規則配置信息，然后解釋執行規則，如上述積分贈送規則，屬性的閾值“7”、“100”、“1000”等在文件中設置，在此種方式下，閾值變化只需要修改配置文件，不需要修改程序，但當條件或動作的結構超出配置范圍時仍需修改程序代碼。數據庫配置方式，與文件配置方式相似，不同在于規則信息保存在數據庫中。

內嵌規則引擎方式是將規則引擎組件嵌入在微服務程序中，微服務程序用相對固定的模式通過調用規則引擎組件的能力執行預先定義的業務規則，例如在規則引擎drools中，積分贈送規則的條件和動作定義：when $point:Point（customerClass==7&& billLimit>=100）then$point.setPoint（1000）。在此種方式下，規則的條件和動作結構以及閾值發生變化，只需修改業務規則定義，不需要修改微服務程序代碼，例如積分贈送規則中又增加了一個條件：客戶在網時長超過5年，那么只需將積分贈送規則定義改為：when$point:Point（customerClass==7&&billLimit>=100&&entryYears>=5）then$point.setPoint（1000）即可。在微服務應用程序中實現業務規則的多種方式如圖2所示。

圖2 業務規則實現方式

從微服務化系統的整體來看，不同微服務采用不同業務規則實現方式會產生多種問題，主要包括：第一，不同微服務的靈活性參差不齊，方式一最差，其次是方式二或方式三，最好的是方式四，但對整個微服務化系統而言，靈活性較差的微服務會直接拉低了系統整體的靈活性，導致業務需求響應緩慢，并影響系統整體的穩定性，難以適應業務規則繁多易變的市場環境；第二，由于業務規則的管理和實現分散在各個微服務中，缺乏整體的業務規則目錄和視圖，業務規則的實現缺乏透明度，無法統一獲取各類業務規則的配置和執行情況，給業務運營和規則解釋造成較大障礙；第三，業務規則實現的重用性低，同一業務規則可能在不同微服務中被重復開發甚至執行不一致，從而不但增加了業務規則實現的開發成本，還導致整體的業務策略難以落實。

3 業務規則平臺方案

在微服務架構中引入統一的業務規則平臺是解決上述問題的一個有效辦法。從微服務架構看，在服務支撐層新設業務規則平臺。與服務注冊、服務監控等一樣，業務規則平臺為微服務提供公共的平臺級服務，負責統一配置和執行所有微服務的業務規則。各個微服務可通過輕量級服務調用方式調用業務規則平臺的規則執行服務，并獲取規則執行的結果。業務規則平臺在微服務架構中的定位如圖3所示。

圖3 業務規則平臺在微服務架構中的定位

業務規則平臺將原來分散在各微服務中的業務規則配置和執行工作抽取出來統一處理，主要功能是規則配置和規則執行。

在規則配置方面，功能包括對象配置、規則配置、規則轉換等，其中對象配置業務規則中引用的數據對象定義，包括數據對象的屬性及獲取相應屬性值的服務編排，如客戶等級從客戶中心微服務提供的客戶信息查詢服務中獲取；規則配置是業務規則的定義，支持令業務人員容易理解的類自然語言形式表達；數據對象和規則配置的數據以結構化數據的形式保存在數據庫（如MySQL）中，同時將結構化的業務規則自動轉化為規則引擎可解析的規則文件，如規則引擎Drools的DRL（Drools Rule Language，Drools規則語言）文件，形成規則文件庫。

在規則執行方面，功能包括規則執行服務、對象取數、對象構造、規則觸發、規則執行、日志生成、日志入庫等，其中規則執行服務以輕量級服務接口的方式（如Restful API，REST風格的應用程序接口）對所有微服務提供統一的規則執行服務，只需要微服務傳入規則名稱和少量的規則處理對象數據（如客戶標識）；對象取數是根據規則中引用的數據對象定義，通過調用相應的微服務獲取數據值；對象構造是創建數據對象并對象插入規則引擎中；規則觸發是激活規則引擎，使其對插入的數據對象執行相應的規則；規則引擎組件主要功能是規則匹配、規則執行，它根據規則定義與數據對象進行規則推理和執行；規則日志生成與入庫是記錄和保存規則執行服務的調用和處理過程，日志記錄通過消息隊列（如Kafka）最終存儲到分布式列數據庫（如HBase）中。業務規則平臺技術方案如圖4所示。

圖4 業務規則平臺技術方案

4 業務規則遷移方法

面對已實施微服務架構但各微服務業務規則實現方式不統一的情形，除了在服務支撐層部署業務規則平臺，還需要有一套統一的業務規則遷移方法，以有序地將原來的分散在各微服務中的業務規則遷移到業務規則平臺，從而統一業務規則的方式實現。

微服務的業務規則遷移到業務規則平臺，總體上可分為四個階段，包括規則設計、規則配置、微服務適配、規則發布。在規則設計階段，主要完成規則梳理和規則整合。規則梳理是各微服務根據自己原來的業務規則實現方式梳理出業務規則的詳細描述；規則整合是分析所有微服務已梳理出來的業務規則，然后整合相似規則，去除原來不一致的地方，重新設計業務規則。在規則配置階段，主要完成規則基本信息配置、數據對象配置、對象服務映射配置、條件配置和動作配置。在微服務適配階段，各微服務將原來的業務規則剝離出來，改造成調用平臺服務的方式實現業務規則。其中，數據服務是微服務根據業務規則的數據對象需要，提供相應的服務API給業務規則平臺使用；規則服務調用是調用業務規則平臺提供的統一規則執行服務完成業務規則的執行，并獲取規則執行的結果。在規則發布階段，主要完成規則測試、規則核準和規則啟用，其中規則測試是對規則的配置和執行進行自動化的測試和驗證；規則核準是對測試結果進行審核和確認，確保規則的定義和執行與預期一致；規則啟用是規則正式上線使用，投入生產。業務規則遷移方法如圖5所示。

圖5 業務規則遷移方法

5 結語

本文研究了微服務架構的特點，分析了微服務中業務規則的實現方式及存在問題，并提出微服務架構下業務規則平臺技術方案及業務規則遷移方法。在微服務架構中的服務支撐層引入業務規則平臺，是解決微服務分散處理業務規則帶來的各種問題的有效措施，一方面能夠減少眾多微服務各自重復開發業務規則功能帶來的成本，另一方面能夠保證業務規則的配置和執行一致性，從而提高微服務化系統的靈活性和可維護性，更快地響應各種業務需求的變化。