撰寫部門：Y-供應鏈研發部-履約研發部
1、導讀
業界，規則引擎是一個非常普遍的技術類工具，也有很多非常優秀的開源工具，例如Drools等，它是一種嵌入在應用程式中的元件，主要解決易變邏輯和業務耦合的問題，把易變的規則從應用程式程式碼中分離出來，進而提升交付效率，降低應用程式維護和可擴充套件性成本。
然而，行業上開源的規則引擎，在網際網路場景使用卻存在諸多障礙。從技術上來看，面對特大流量的高併發略顯不足；從交付上看，操作語言是以研發視角，無法讓更多的非技術人員參與來實現交付鏈條的最大化降低；從實施上，也沒有配套的標準化架構開放規範，無法規模化的讓規則從應用程式程式碼中實現分離。
基於此，京東供應鏈研發部自研了一套，面向業務角色的海納低程式碼規則引擎平臺，產品定位是面向業務、研發多角色一體化的零低程式碼開發平臺，這其中規則引擎是其最核心的部分之一。
這個平臺，不僅可以高效的支援網際網路高併發業務，它還具有一套標準化擴充套件開放的能力。基於此業務系統可以快速實現業務規則的規模化開放，短短4個月內，低成本開放了近100+個擴充套件點，抽取沉澱了近400+個業務規則，支援了14+個京東核心鏈路重大專案，產品經理/ISV也首次以無程式碼的方式，在安全清晰的工作邊界內，自助式的完成京東核心鏈路的業務需求，平均的交付週期0.5天內。
另外，從長遠來看，它把研發職能進行轉移及拓寬，以安全的模式讓更多的角色參與研發，進而最佳化了需求的交付模式，為後續生態規模化的交付奠定了基礎。
2、JD履約的應用
現狀
海納低程式碼規則引擎平臺在履約已大規模運用，初步達成了約20%的需求可由業務角色來直接交付，預估後續此比例可提升至40%。和其他平臺的發展情況一樣，海納的發展過程也相當驚心動魄。下面就以一個獨特的視角、簡短的語言為大家展開。
一個陽光明媚的早上，初級工程師小徐揹著軍綠色的雙肩包，前腳剛從滿滿當當的電梯裡面出來，還沒來得及走到工位邊脫下厚重的羽絨服。“鈴鈴鈴”的電話聲音就響起了，是對應業務條線的產品小李打過來的。該死，不會昨天晚上上線有什麼問題吧。小徐揉了下微微發脹的太陽穴，不安的接起電話。很快就放下心來，昨天上線的業務已驗收沒問題了。是一個新的業務訴求要去滿足。
快速溝通了下，小徐就搞明白了大致想要做的事情了。商城上新引入了一批高階的時尚化妝品品牌，業務側將貨物入倉並在APP上開始售賣後，在客戶同時或者分開購買這批化妝品後，在這些貨物在出庫履約生產的時候，物流會建立單獨的生產業務線，為不同品牌的化妝品單獨包裝，並放置到品牌獨立的包裝禮盒中。期望在配送給客戶的時候，使用精美的禮盒也可以加強客戶的感知，提升使用者體驗。
小徐工作已三年了，聽完這個需求後，大腦中已構思出了大致的實現方案了。這個需求簡單，不就是配置一批特殊的品牌增加特殊的業務處理規則麼，幾行if程式碼就可以搞定了，前2天剛實現了個類似的需求。剛想完，小徐就開啟程式碼編輯器，眼睛盯著那幾百行多個if else分支的程式碼，想著加到哪個地方最合適。
想著正有點出神，電話再次響起，還是產品小李，這個需求的優先順序提高了，業務那邊希望今天就可以給出一個排期計劃，小徐預估了大致的工作，覺得應該可以滿足預期。和小李確定了下午的需求評審會時間，並順手將這個任務加到了待辦列表中了，不經意的掃了下工作安排，這週上線的需求就有4個了，突破了以前每週處理2個的平均值了。看來今天晚上要加加班了，不然幹不完了。小徐戴上帽子，遮住了有點稀疏的腦門，抿了一口黑咖啡，全心開始工作了。
幾天後，另外一個角落裡，核心架構師小彭和其他幾個產品、業務聚在一起，對最近排期不滿足的情況進行溝通。大家一番討論後，總算共識了一起評估是否有合適的方式可以提升交付的速度，降低排期不滿足的機率。甚至個別業務還提出來，有沒有什麼工作是可以分出來交給他們來做的。嗯，這是一個有意思的方向。小彭記下了這個關鍵的內容，開始認真琢磨有無好的辦法。小彭從來就不是一個空想派，說幹就幹。從專案文件中拿出了近3年的專案及需求列表，從頭梳理其實現方式，評估需求的共性及特點。
挑戰
小彭帶領團隊，重新審視了最近收到的專案及需求，發現約有40%的需求相似性比較高，需求抽象後基本可以描述為“基於一定組合的業務條件下”，“執行特定領域的業務動作”。看起來和規則引擎的匹配度相當高。但是綜合分析後，發現實施難度存在2類挑戰，均需要有對應的解決方案。
效能挑戰：小彭負責的業務領域有點特殊，所有商城的每一個訂單都會流向他負責的系統，峰值時一天處理超億級訂單。傳統意義上的規則引擎，應用的都是低流量的業務場景。在這種大資料量，高併發的場景下，怎麼保障效能是個問題，需要有對應的解決方案。
價值挑戰：引入成熟的規則引擎，假定可以解決目前的應用場景。但是一般規則引擎都會有其獨立的領域描述語言（DSL Domain Specific Language），這類語言的使用門檻一般都比較高，交給研發人員維護還處於勉強可以接收的程度，交給產品或者業務人員去維護，初步看可能性較低。那麼引入規則引擎後，如何實現一種方案，可以讓產品、業務、研發均可以快速參與進來，均可以使用此產品功能進行快速交付，就是此產品要解決的核心問題了。
方案
經過幾天連夜的奮戰，小彭總算把相關的解決方案敲定了具體的可行性方向，與上級主管沛公約好了彙報討論的時間。與前幾天心驚肉跳的討論不同，在大的討論開始之前，小彭的心反而沒有那麼緊張了。小彭就是這樣，越是難的事情，越覺得有挑戰。即使再難的事情，在心裡過一過，總可以想得明白。他是使萬物迴歸其本源，而種子總能突破土地的束縛，慢慢長成誰也無法阻擋的參天大樹。
落地層面，小彭從來不擔心。雖然可以預判到實施的過程中會有這樣或者那樣的難題。但是小彭和其合作的團隊的戰鬥力，是小彭信心高昂的一切來源。這是一支不同的尋常的團隊，支撐的也是不同尋常的業務。業務上，小彭負責了商城所有訂單的履約生產過程，為每一個訂單實時高效的制定好最優的生產計劃，在過程中發出多個如拆單、轉倉、補貨等多個快速指令，為在商城中消費的每一個客戶提供最優服務，並最大可能性的降低履約生產過程中的生產成本。過去幾年多次一起並肩作戰的戰鬥與衝鋒，早就鍛造了這隻團隊獨特的戰鬥力。
和沛公的交談如預期中順利，但是沛公說他還是要再認真考慮一下。是的，是要認真考慮一下，成熟的人總是要三思而後行，而一但確定好後就毫不猶豫的堅決執行。這個事情，風險和收益同樣巨大。幹好了後面研發交付的工作可以發生變革式的變化，產品、業務來完成需求交付不再是個可望不可即的事情了；但是如果幹不好，比如過程中遇到了無法突破的難題，或者交付後出現業務使用不佳的情況，辛辛苦苦投入的精力可能就會存在白費的情況，特別是面對如此高的交付壓力，一旦失敗，對上對下，都不好交代。
變革的過程總是很痛苦，而有先見之明的人在經歷痛苦後才能有機會涅槃重生。做，還是不做，這是一個擺在沛公面前的難題。在經過一個晚上的深思熟慮後，沛公心中就有了預判和決斷。這個事情是一個長期的事、有價值的事情，現在不做，將來我們也會要做。等將來專案及需求的壓力變得不可阻擋，不得不做的時候，重重壓力下執行的動作反而會變形。最好的時機就是當下，沛公已暗暗下定了決心。至於困難，總會有的，但是隻要信心在，辦法總比困難多。敢於衝鋒，直面失敗，這也是這個團隊難以磨滅的特質。
沛公找到了供應鏈負責整體效能同時身為首架的林老師溝通。林老師最近也一直在思考，如何將供應鏈高頻共性的研發動作進一步抽象、打造出合適的Y工具產品，並將工具提供開放給業務角色，來降低研發的需求數，提升交付效率，部門也一直在做這樣的探索，正好最近零（低）程式碼解決方案也初步有了成果，與沛公提到的想法不謀而合。兩個部門立刻決定，共同推進落地。
一個小的分隊很快就成立了，兩個團隊都挑選了一些精兵強將，共同負責功能的設計、開發及運維，具體帶隊的分別是小麗，小徐，小彭，總體架構師是林老師，部門中一些架構師和研發也自願的踴躍參加，例如 小孫，小馬，小丁，小夢，小張，小喜等等。大家除了日常需要支援的本質工作外，其餘的時間都一頭撲在了這個新產品能力的打造上了。和一般偉大的事業開啟必然附加有華美的篇章不同，研發的工作總是這樣，樸實而無華。沒有激情澎湃的讚歌，也沒有千里不留行的豪邁，只是一個接一個的不眠之夜。看似枯燥的工作，和冷冰冰的程式碼，但總難澆滅大家心中火熱的激情。每每深夜裡有一些靈光乍現的新思路，每個人總會趕緊拿手機記下來，再倒頭躺下。想到新的一天可以和團隊一起，討論新的思路和落地方式，大家按捺不住激動的內心，久久不能入睡。
一個月後，產品雛形已初步完成，小彭拉上業務線對口的產品和業務來試用，算是譭譽參半，小彭沒有洩氣，收集了大家的問題和反饋，並開始快速迭代。又半個月過去，產品總算達到了可用、可交付的狀態。經過一段時間的試點使用後，一些業務、產品開始主動來尋求合作和反饋。總算形成了正向反饋。
3、核心原理介紹
看了這麼多，那這個產品到底是如何完成的呢，其中的原理和亮點分別是什麼，讓小分隊的成員帶領我們來一窺究竟。
提高交付效率、保證交付質量，擴大交付角色，是業界追求的最高目標，也是是小彭及其小分隊追求的最終目標。為保障產品功能可安全、可靠的交付給業務角色，小分隊探索出了一個帶視覺化介面、研發和產品可共同參與開發的通用性規則平臺，並在平臺內設定了一系列的規範化約定，計劃提供沙箱模式、錄製與回放驗證等機制來保證交付的質量，並提升聯調與驗證的效率。
而其核心原理，簡而言之可以表述為：平臺提供視覺化設計器，業務角色在視覺化介面沉浸式式編排業務規則，即可完成所有業務功能的新增、變更、修改與釋出。與之相對應的，平臺在功能後臺自動生成規則引擎描述檔案，待業務角色稽核完成後自動化的同步給應用系統。應用系統透過SDK對擴充套件點進行攔截，並在擴充套件點執行生效的規則編排。
海納低程式碼規則引擎工作示意圖如下所示：
對於適用於業務規則類的業務場景，小分隊的成員很快就發現存在共性特點：“當滿足部分特定業務條件時，執行特定業務動作的一組規則集合”。
小分隊成員對此特點深入研究，發現市面上常見的規則引擎提供的技術規則內容太深奧、太專業，對於普通的業務人員理解難度太高，導致市面的規則引擎產品主要在研發內部使用。為解決這一難題，小分隊在平臺中除了提供純技術規則註冊外，還提供了業務規則註冊與組合編排。使得平臺的使用者不光可以覆蓋至研發角色，還可以覆蓋至業務角色。業務交付需求時，只需關注其業務規則與業務編排，而其背後支撐的複雜技術規則則可完全對業務角色透明。最終業務像畫流程圖一樣在平臺進行操作即可自助式完成需求交付。
伴隨著需求的交付個數的增長，系統中的業務規則和業務行為不斷地擴充，後續的需求交付可複用之前沉澱確定的業務規則，包括如“自營”、“廠直”、“醫藥”等統一的業務含義，均可統一在後續需求進行復用。可進一步提升交付速度。
下邊我們以一個實際的例子展示下海納規則引擎的主要特色功能。為了讓大家有直觀的感受視覺化規則編排和執行過程，先展示下規則編排結果：
從規則流程圖可以看到主要的元素就是菱形和矩形。菱形表示條件，類似於我們程式碼中的if；而矩形則是動作，就是我們具體做的一個動作，比如更新資料庫、遠端介面呼叫等任何想做的事。
那麼規則流程是如何被編排出來，編排出來後又是如何執行的呢？下圖描述了主要過程。
註冊擴充套件點：
擴充套件點是規則要執行的切入點，在平臺註冊擴充套件點後，可圍繞該擴充套件點進行業務規則流程編排。
業務模型註冊：
業務模型是業務資料的載體，確保引擎正確識別並訪問模型以進行邏輯運算；
技術規則註冊：
主要面向研發人員，主要包括方法的簽名資訊，和系統中的程式碼方法對應，提供最基礎的規則。
平臺還內建了豐富的技術規則，如下圖所示，對於一般業務而言，預製的規則可以滿足80%及以上的場景。對於其餘個性化場景，平臺也提供了可擴充套件的能力。
業務規則註冊：
業務規則是對技術規則或業務規則的組合，形成具有業務語義的規則，最終用於業務規則流程編排。為了實現複雜業務條件，我們提供and/or/not/group等多種組合形式，方便業務靈活配置。
業務規則編排：
對業務規則進行組合，以流程圖的方式展現業務流程，最終形成規則流程描述檔案。
規則引擎執行：
SDK將規則流程描述檔案解析成規則引擎能執行的指令碼，規則引擎透過執行指令碼完成業務規則的執行。
小結：
對業務角色而言，海納平臺提供視覺化規則編排能力，業務規則主要是由具有業務語義化的條件規則和動作規則組成，因此產品業務人員可以輕鬆地自助完成業務規則編排。隨著規則豐富度持續提升，業務人員也可以對已有規則進行組合或透過自定義規則方式實現新業務規則建立，實現全面自助。
對於研發角色而言，應用系統只需引入SDK並定義要執行規則擴充套件點即可完成整合工作。後續需求業務實現自助化交付後，整個交付的過程從原來的10天，可縮短至最快0.5天，達成了提效的目的。
亮點
1、輕量化
海納規則引擎以對業務系統無侵入，只需引入規則引擎SDK，新增註解即可完成接入，對於存量系統具有友好的支援。一般而言，1天即可快速完成整合工作。
2、高效能
海納平臺是去中心化的設計，平臺只負責流程編排，編排後的結果以流程描述檔案的方式同步給業務系統，應用系統透過SDK解析並執行，採取本地化執行方式，沒有效能瓶頸，並透過了京東訂單履約核心繫統11.11大促驗證。平臺提供的能力支援峰值一天處理超億級訂單平穩執行，單個規則執行的耗時在納秒級別內完成。
3、研發和業務實現分離
海納規則引擎將研發角色和業務角色分離，在技術領域和業務領域間建立規則適配，遮蔽技術細節，讓業務角色更關注業務規則，提高業務角色的使用體驗。
4、視覺化
面向業務語義的流程編排，流程的編排可以向畫流程圖一樣方便，實現所見即所得的業務體驗。
5、技術資產沉澱
透過在平臺上註冊業務規則和業務行為，可實現技術資產沉澱，隨著業務規則的擴充，可支援更為豐富的業務流程。
4、總結
時間又回到了當下，產品小李找到了小彭，同步了近期業務提過來的幾個需求，均已經在海納規則引擎低程式碼平臺自助化實現了，單個需求差不多5到10分鐘即可完成配置，全程在平臺上沉浸式操作即可。但最終上線需要小彭幫忙審批一下。仔細檢查了業務規則條件，確認業務邏輯符合預期後，小彭快速移動滑鼠，輕輕點選了“釋出生效”，新配置的規則就如同打一個響指一樣，秒級的速度就更新至線上生產環境，並全面執行了。送走小李後，小彭看著線上平穩的監控曲線出神，這個手段確實挺有效，省去了需求評審、業務功能開發、業務功能內部測試的時間，業務角色可以快速自助化交付。那麼其餘60%的需求如何提效呢？是否有其他的解決方案呢？小彭又陷入了沉思。
看到了這裡，您是不是對海納規則引擎低程式碼平臺有了更多的瞭解了呢？您在日常的工作中，是否遇到了類似的場景，可以複用此解決的方案麼？如果有，歡迎多多交流。
在專案需求日趨增加，而人力資源逐步成為瓶頸的時候，採用多種方式來達成提效的效果，是擺在所有人面前的一個難題。希望本文章可以以一個視角和解決方案，以拋磚引玉的方式，引起大家更多的共鳴和思考。