微服務(wù)架構(gòu)下規(guī)則平臺(tái)方案與規(guī)則遷移方法

池?zé)槼?，史立學(xué)，劉智瓊，朱明英

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

0 引言

為實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型，企業(yè)正大規(guī)模實(shí)踐應(yīng)用系統(tǒng)上云工程，同時(shí)將應(yīng)用系統(tǒng)由原有的MA架構(gòu)（Mono?lithic Architecture，單體架構(gòu)）轉(zhuǎn)變?yōu)镸SA架構(gòu)（Mi?croservice Architecture，微服務(wù)架構(gòu)），升級(jí)為基于云平臺(tái)的微服務(wù)化系統(tǒng)。微服務(wù)架構(gòu)遵循職責(zé)單一、數(shù)據(jù)自治、獨(dú)立部署與運(yùn)維等理念，通常按業(yè)務(wù)領(lǐng)域?qū)误w系統(tǒng)拆分成多個(gè)微服務(wù)，不同業(yè)務(wù)子域的業(yè)務(wù)邏輯歸入到不同微服務(wù)中。業(yè)務(wù)規(guī)則處理是業(yè)務(wù)邏輯的重要組成部分，所以不同子域的業(yè)務(wù)規(guī)則相應(yīng)被劃分到不同的微服務(wù)中處理。然而，在微服務(wù)架構(gòu)下，由于各個(gè)微服務(wù)可以根據(jù)自身的功能、性能、可靠性等不同要求確定自身的實(shí)現(xiàn)方式，所以不同的微服務(wù)可能采取了不同的業(yè)務(wù)規(guī)則實(shí)現(xiàn)方式，如硬編碼方式、文件配置方式、數(shù)據(jù)庫(kù)配置方式、內(nèi)嵌規(guī)則引擎方式等，而這些差異很容易導(dǎo)致微服務(wù)化系統(tǒng)的業(yè)務(wù)規(guī)則管理出現(xiàn)問題，包括業(yè)務(wù)規(guī)則管理分散、無(wú)法看到整體的規(guī)則視圖和定義、無(wú)法統(tǒng)一監(jiān)控業(yè)務(wù)規(guī)則執(zhí)行情況等等，在微服務(wù)架構(gòu)中引入業(yè)務(wù)規(guī)則平臺(tái)是解決這些問題的有效辦法。

1 微服務(wù)架構(gòu)與業(yè)務(wù)規(guī)則

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

微服務(wù)架構(gòu)一般包含五層：基礎(chǔ)設(shè)施層、服務(wù)支撐層、業(yè)務(wù)邏輯層、訪問層和門戶層，其中服務(wù)支撐層為微服務(wù)提供服務(wù)管理等公共服務(wù)，業(yè)務(wù)邏輯層包含多個(gè)微服務(wù)。服務(wù)支撐層包含各種支撐微服務(wù)體系運(yùn)行的公共能力，包括服務(wù)注冊(cè)、服務(wù)監(jiān)控、服務(wù)日志、服務(wù)調(diào)用鏈等等。在業(yè)務(wù)邏輯層，微服務(wù)通常根據(jù)業(yè)務(wù)領(lǐng)域功能劃分，遵循“單一職責(zé)原則”，每個(gè)微服務(wù)專注完成一個(gè)業(yè)務(wù)子領(lǐng)域的功能，專門處理一個(gè)業(yè)務(wù)子域的業(yè)務(wù)邏輯。業(yè)務(wù)規(guī)則是對(duì)業(yè)務(wù)策略的定義和約束，是微服務(wù)業(yè)務(wù)邏輯的重要組成部分，例如，客戶中心微服務(wù)負(fù)責(zé)客戶實(shí)名認(rèn)證規(guī)則的處理、訂單中心微服務(wù)負(fù)責(zé)訂單檢驗(yàn)規(guī)則的處理、促銷中心微服務(wù)負(fù)責(zé)積分贈(zèng)送規(guī)則的處理，等等。業(yè)務(wù)規(guī)則處理在微服務(wù)架構(gòu)中的位置如圖1所示。

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

2 業(yè)務(wù)規(guī)則實(shí)現(xiàn)方式與存在問題

由于每個(gè)微服務(wù)相對(duì)獨(dú)立，不同微服務(wù)可以采用不同的技術(shù)實(shí)現(xiàn)，所以在微服務(wù)架構(gòu)下，各個(gè)微服務(wù)對(duì)業(yè)務(wù)規(guī)則實(shí)現(xiàn)可能存在多種方式，甚至同一微服務(wù)中的不同業(yè)務(wù)規(guī)則也可能使用了不同方式，這些方式包括硬編碼方式、文件配置方式、數(shù)據(jù)庫(kù)配置方式、內(nèi)嵌規(guī)則引擎方式等。

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

文件配置方式是在后臺(tái)的配置文件中配置業(yè)務(wù)規(guī)則的條件和動(dòng)作，包括涉及的屬性及閾值，微服務(wù)程序代碼先從文件中讀取規(guī)則配置信息，然后解釋執(zhí)行規(guī)則，如上述積分贈(zèng)送規(guī)則，屬性的閾值“7”、“100”、“1000”等在文件中設(shè)置，在此種方式下，閾值變化只需要修改配置文件，不需要修改程序，但當(dāng)條件或動(dòng)作的結(jié)構(gòu)超出配置范圍時(shí)仍需修改程序代碼。數(shù)據(jù)庫(kù)配置方式，與文件配置方式相似，不同在于規(guī)則信息保存在數(shù)據(jù)庫(kù)中。

內(nèi)嵌規(guī)則引擎方式是將規(guī)則引擎組件嵌入在微服務(wù)程序中，微服務(wù)程序用相對(duì)固定的模式通過調(diào)用規(guī)則引擎組件的能力執(zhí)行預(yù)先定義的業(yè)務(wù)規(guī)則，例如在規(guī)則引擎drools中，積分贈(zèng)送規(guī)則的條件和動(dòng)作定義：when $point:Point（customerClass==7&& billLimit>=100）then$point.setPoint（1000）。在此種方式下，規(guī)則的條件和動(dòng)作結(jié)構(gòu)以及閾值發(fā)生變化，只需修改業(yè)務(wù)規(guī)則定義，不需要修改微服務(wù)程序代碼，例如積分贈(zèng)送規(guī)則中又增加了一個(gè)條件：客戶在網(wǎng)時(shí)長(zhǎng)超過5年，那么只需將積分贈(zèng)送規(guī)則定義改為：when$point:Point（customerClass==7&&billLimit>=100&&entryYears>=5）then$point.setPoint（1000）即可。在微服務(wù)應(yīng)用程序中實(shí)現(xiàn)業(yè)務(wù)規(guī)則的多種方式如圖2所示。

圖2 業(yè)務(wù)規(guī)則實(shí)現(xiàn)方式

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

3 業(yè)務(wù)規(guī)則平臺(tái)方案

在微服務(wù)架構(gòu)中引入統(tǒng)一的業(yè)務(wù)規(guī)則平臺(tái)是解決上述問題的一個(gè)有效辦法。從微服務(wù)架構(gòu)看，在服務(wù)支撐層新設(shè)業(yè)務(wù)規(guī)則平臺(tái)。與服務(wù)注冊(cè)、服務(wù)監(jiān)控等一樣，業(yè)務(wù)規(guī)則平臺(tái)為微服務(wù)提供公共的平臺(tái)級(jí)服務(wù)，負(fù)責(zé)統(tǒng)一配置和執(zhí)行所有微服務(wù)的業(yè)務(wù)規(guī)則。各個(gè)微服務(wù)可通過輕量級(jí)服務(wù)調(diào)用方式調(diào)用業(yè)務(wù)規(guī)則平臺(tái)的規(guī)則執(zhí)行服務(wù)，并獲取規(guī)則執(zhí)行的結(jié)果。業(yè)務(wù)規(guī)則平臺(tái)在微服務(wù)架構(gòu)中的定位如圖3所示。

圖3 業(yè)務(wù)規(guī)則平臺(tái)在微服務(wù)架構(gòu)中的定位

業(yè)務(wù)規(guī)則平臺(tái)將原來分散在各微服務(wù)中的業(yè)務(wù)規(guī)則配置和執(zhí)行工作抽取出來統(tǒng)一處理，主要功能是規(guī)則配置和規(guī)則執(zhí)行。

在規(guī)則配置方面，功能包括對(duì)象配置、規(guī)則配置、規(guī)則轉(zhuǎn)換等，其中對(duì)象配置業(yè)務(wù)規(guī)則中引用的數(shù)據(jù)對(duì)象定義，包括數(shù)據(jù)對(duì)象的屬性及獲取相應(yīng)屬性值的服務(wù)編排，如客戶等級(jí)從客戶中心微服務(wù)提供的客戶信息查詢服務(wù)中獲取；規(guī)則配置是業(yè)務(wù)規(guī)則的定義，支持令業(yè)務(wù)人員容易理解的類自然語(yǔ)言形式表達(dá)；數(shù)據(jù)對(duì)象和規(guī)則配置的數(shù)據(jù)以結(jié)構(gòu)化數(shù)據(jù)的形式保存在數(shù)據(jù)庫(kù)（如MySQL）中，同時(shí)將結(jié)構(gòu)化的業(yè)務(wù)規(guī)則自動(dòng)轉(zhuǎn)化為規(guī)則引擎可解析的規(guī)則文件，如規(guī)則引擎Drools的DRL（Drools Rule Language，Drools規(guī)則語(yǔ)言）文件，形成規(guī)則文件庫(kù)。

在規(guī)則執(zhí)行方面，功能包括規(guī)則執(zhí)行服務(wù)、對(duì)象取數(shù)、對(duì)象構(gòu)造、規(guī)則觸發(fā)、規(guī)則執(zhí)行、日志生成、日志入庫(kù)等，其中規(guī)則執(zhí)行服務(wù)以輕量級(jí)服務(wù)接口的方式（如Restful API，REST風(fēng)格的應(yīng)用程序接口）對(duì)所有微服務(wù)提供統(tǒng)一的規(guī)則執(zhí)行服務(wù)，只需要微服務(wù)傳入規(guī)則名稱和少量的規(guī)則處理對(duì)象數(shù)據(jù)（如客戶標(biāo)識(shí)）；對(duì)象取數(shù)是根據(jù)規(guī)則中引用的數(shù)據(jù)對(duì)象定義，通過調(diào)用相應(yīng)的微服務(wù)獲取數(shù)據(jù)值；對(duì)象構(gòu)造是創(chuàng)建數(shù)據(jù)對(duì)象并對(duì)象插入規(guī)則引擎中；規(guī)則觸發(fā)是激活規(guī)則引擎，使其對(duì)插入的數(shù)據(jù)對(duì)象執(zhí)行相應(yīng)的規(guī)則；規(guī)則引擎組件主要功能是規(guī)則匹配、規(guī)則執(zhí)行，它根據(jù)規(guī)則定義與數(shù)據(jù)對(duì)象進(jìn)行規(guī)則推理和執(zhí)行；規(guī)則日志生成與入庫(kù)是記錄和保存規(guī)則執(zhí)行服務(wù)的調(diào)用和處理過程，日志記錄通過消息隊(duì)列（如Kafka）最終存儲(chǔ)到分布式列數(shù)據(jù)庫(kù)（如HBase）中。業(yè)務(wù)規(guī)則平臺(tái)技術(shù)方案如圖4所示。

圖4 業(yè)務(wù)規(guī)則平臺(tái)技術(shù)方案

4 業(yè)務(wù)規(guī)則遷移方法

面對(duì)已實(shí)施微服務(wù)架構(gòu)但各微服務(wù)業(yè)務(wù)規(guī)則實(shí)現(xiàn)方式不統(tǒng)一的情形，除了在服務(wù)支撐層部署業(yè)務(wù)規(guī)則平臺(tái)，還需要有一套統(tǒng)一的業(yè)務(wù)規(guī)則遷移方法，以有序地將原來的分散在各微服務(wù)中的業(yè)務(wù)規(guī)則遷移到業(yè)務(wù)規(guī)則平臺(tái)，從而統(tǒng)一業(yè)務(wù)規(guī)則的方式實(shí)現(xiàn)。

微服務(wù)的業(yè)務(wù)規(guī)則遷移到業(yè)務(wù)規(guī)則平臺(tái)，總體上可分為四個(gè)階段，包括規(guī)則設(shè)計(jì)、規(guī)則配置、微服務(wù)適配、規(guī)則發(fā)布。在規(guī)則設(shè)計(jì)階段，主要完成規(guī)則梳理和規(guī)則整合。規(guī)則梳理是各微服務(wù)根據(jù)自己原來的業(yè)務(wù)規(guī)則實(shí)現(xiàn)方式梳理出業(yè)務(wù)規(guī)則的詳細(xì)描述；規(guī)則整合是分析所有微服務(wù)已梳理出來的業(yè)務(wù)規(guī)則，然后整合相似規(guī)則，去除原來不一致的地方，重新設(shè)計(jì)業(yè)務(wù)規(guī)則。在規(guī)則配置階段，主要完成規(guī)則基本信息配置、數(shù)據(jù)對(duì)象配置、對(duì)象服務(wù)映射配置、條件配置和動(dòng)作配置。在微服務(wù)適配階段，各微服務(wù)將原來的業(yè)務(wù)規(guī)則剝離出來，改造成調(diào)用平臺(tái)服務(wù)的方式實(shí)現(xiàn)業(yè)務(wù)規(guī)則。其中，數(shù)據(jù)服務(wù)是微服務(wù)根據(jù)業(yè)務(wù)規(guī)則的數(shù)據(jù)對(duì)象需要，提供相應(yīng)的服務(wù)API給業(yè)務(wù)規(guī)則平臺(tái)使用；規(guī)則服務(wù)調(diào)用是調(diào)用業(yè)務(wù)規(guī)則平臺(tái)提供的統(tǒng)一規(guī)則執(zhí)行服務(wù)完成業(yè)務(wù)規(guī)則的執(zhí)行，并獲取規(guī)則執(zhí)行的結(jié)果。在規(guī)則發(fā)布階段，主要完成規(guī)則測(cè)試、規(guī)則核準(zhǔn)和規(guī)則啟用，其中規(guī)則測(cè)試是對(duì)規(guī)則的配置和執(zhí)行進(jìn)行自動(dòng)化的測(cè)試和驗(yàn)證；規(guī)則核準(zhǔn)是對(duì)測(cè)試結(jié)果進(jìn)行審核和確認(rèn)，確保規(guī)則的定義和執(zhí)行與預(yù)期一致；規(guī)則啟用是規(guī)則正式上線使用，投入生產(chǎn)。業(yè)務(wù)規(guī)則遷移方法如圖5所示。

圖5 業(yè)務(wù)規(guī)則遷移方法

5 結(jié)語(yǔ)

本文研究了微服務(wù)架構(gòu)的特點(diǎn)，分析了微服務(wù)中業(yè)務(wù)規(guī)則的實(shí)現(xiàn)方式及存在問題，并提出微服務(wù)架構(gòu)下業(yè)務(wù)規(guī)則平臺(tái)技術(shù)方案及業(yè)務(wù)規(guī)則遷移方法。在微服務(wù)架構(gòu)中的服務(wù)支撐層引入業(yè)務(wù)規(guī)則平臺(tái)，是解決微服務(wù)分散處理業(yè)務(wù)規(guī)則帶來的各種問題的有效措施，一方面能夠減少眾多微服務(wù)各自重復(fù)開發(fā)業(yè)務(wù)規(guī)則功能帶來的成本，另一方面能夠保證業(yè)務(wù)規(guī)則的配置和執(zhí)行一致性，從而提高微服務(wù)化系統(tǒng)的靈活性和可維護(hù)性，更快地響應(yīng)各種業(yè)務(wù)需求的變化。