來源：京東技術

導讀
規則引擎是一種嵌入在應用程式中的元件，主要解決易變邏輯和業務耦合的問題，行業上開源的規則引擎，在網際網路場景使用存在諸多障礙，如高併發略顯不足、更多面向技術人員、無法規模化的讓規則從應用程式程式碼中實現分離。
基於此，京東供應鏈研發部自研了一套，面向業務角色的海納低程式碼規則引擎平臺，產品定位是面向業務、研發多角色一體化的零低程式碼開發平臺，其中規則引擎是其最核心的部分之一，本文以此為核心展開說明。

01

前言

業界，規則引擎是一個非常普遍的技術類工具，也有很多非常優秀的開源工具，例如Drools等，它是一種嵌入在應用程式中的元件，主要解決易變邏輯和業務耦合的問題，把易變的規則從應用程式程式碼中分離出來，進而提升交付效率，降低應用程式維護和可擴充套件性成本。

然而，行業上開源的規則引擎，在網際網路場景使用卻存在諸多障礙。從技術上來看，面對特大流量的高併發略顯不足；從交付上看，操作語言是以研發視角，無法讓更多的非技術人員參與來實現交付鏈條的最大化降低；從實施上，也沒有配套的標準化架構開放規範，無法規模化的讓規則從應用程式程式碼中實現分離。

基於此，京東供應鏈研發部自研了一套，面向業務角色的海納低程式碼規則引擎平臺，產品定位是面向業務、研發多角色一體化的零低程式碼開發平臺，這其中規則引擎是其最核心的部分之一。

這個平臺，不僅可以高效的支援網際網路高併發業務，它還具有一套標準化擴充套件開放的能力。基於此業務系統可以快速實現業務規則的規模化開放，短短4個月內，低成本開放了近100+個擴充套件點，抽取沉澱了近400+個業務規則，支援了14+個京東核心鏈路重大專案，產品經理/ISV也首次以無程式碼的方式，在安全清晰的工作邊界內，自助式的完成京東核心鏈路的業務需求，平均交付週期0.5天內。

另外，從長遠來看，它把研發職能進行轉移及拓寬，以安全的模式讓更多的角色參與研發，進而最佳化了需求的交付模式，為後續生態規模化的交付奠定了基礎。

02

JD履約的應用

2.1 現狀

海納低程式碼規則引擎平臺在履約已大規模運用，初步達成了約20%的需求可由業務角色來直接交付，預估後續此比例可提升至40%。和其他平臺的發展情況一樣，海納的發展過程也相當驚心動魄。下面就以一個獨特的視角、簡短的語言展開說明。

一個陽光明媚的早上，初級工程師小徐揹著軍綠色的雙肩包，前腳剛從滿滿當當的電梯裡面出來，還沒來得及走到工位邊脫下厚重的羽絨服。“鈴鈴鈴”的電話聲音就響起了，是對應業務條線的產品小李打過來的。“不會昨天晚上上線有什麼問題吧”，小徐揉了下微微發脹的太陽穴，不安的接起電話，很快就放下心來，昨天上線的業務已驗收沒問題了，是一個新的業務訴求要去滿足。

快速溝通後，小徐明白了大致想要做的事情。商城上新引入了一批高階的時尚化妝品品牌，業務側將貨物入倉並在APP上開始售賣後，客戶同時或者分開購買這批化妝品後，這些貨物在出庫履約生產的時候，物流會建立單獨的生產業務線，為不同品牌的化妝品單獨包裝，並放置到品牌獨立的包裝禮盒中。期望在配送給客戶的時候，使用精美的禮盒也可以加強客戶的感知，提升使用者體驗。

小徐工作已三年，聽完這個需求後，大腦中已構思出了大致的實現方案了。這個需求簡單，不就是配置一批特殊的品牌增加特殊的業務處理規則麼，幾行if程式碼就可以搞定了，前兩天剛實現了個類似的需求。剛想完，小徐就開啟程式碼編輯器，眼睛盯著那幾百行多個if else分支的程式碼，想著加到哪個地方最合適。

想著正出神，電話再次響起，還是產品小李，這個需求的優先順序提高了，業務希望今天就可以給出排期計劃，小徐預估了大致的工作，認為應該可以滿足預期。和小李確定了下午需求評審會時間，並順手將該任務加到了待辦列表中，看到這周工作安排：上線的需求就有4個，突破了以前每週處理2個的平均值了。看來今天晚上要加加班了，不然幹不完。小徐戴上帽子，遮住了有點稀疏的腦門，抿了一口黑咖啡，全心開始工作了。

幾天後，另外一個角落裡，核心架構師小彭和其他幾個產品、業務聚在一起，對最近排期不滿足的情況進行溝通。討論是否有合適的方式可以提升交付的速度，降低排期不滿足的機率。甚至個別業務還提出來，有沒有什麼工作是可以分出來交給他們來做的。嗯，這是一個有意思的方向。小彭記下了這個關鍵的內容，開始認真琢磨有無好的辦法。小彭從來就不是一個空想派，說幹就幹。從專案文件中拿出了近3年的專案及需求列表，從頭梳理其實現方式，評估需求的共性及特點。

2.2 挑戰

小彭帶領團隊，重新審視了最近收到的專案及需求，發現約有40%的需求相似性比較高，需求抽象後基本可以描述為“基於一定組合的業務條件下”、“執行特定領域的業務動作”。看起來和規則引擎的匹配度相當高。但是綜合分析後，發現實施難度存在2類挑戰，均需要有對應的解決方案。

效能挑戰：小彭負責的業務領域有點特殊，所有商城的每一個訂單都會流向他負責的系統，峰值時一天處理超億級訂單。傳統意義上的規則引擎，應用的都是低流量的業務場景。在這種大資料量，高併發的場景下，怎麼保障效能是個問題，需要有對應的解決方案。

價值挑戰：引入成熟的規則引擎，假定可以解決目前的應用場景。但是一般規則引擎都會有其獨立的領域描述語言（DSL Domain Specific Language），這類語言的使用門檻一般都比較高，交給研發人員維護還處於勉強可以接收的程度，交給產品或者業務人員去維護，初步看可能性較低。那麼引入規則引擎後，如何實現一種方案，可以讓產品、業務、研發均可以快速參與進來，均可以使用此產品功能進行快速交付，就是此產品要解決的核心問題了。

2.3 方案

經過幾天連夜的奮戰，小彭總算敲定了具體的可行性方向，與上級主管沛公約好了彙報討論的時間。與前幾天心驚肉跳的討論不同，在大的討論開始之前，小彭的心反而沒有那麼緊張了。小彭就是這樣，越是難的事情，越覺得有挑戰。即使再難的事情，在心裡過一過，總可以想得明白。他是使萬物迴歸其本源，而種子總能突破土地的束縛，慢慢長成誰也無法阻擋的參天大樹。

落地層面，小彭從來不擔心。雖然可以預判到實施的過程中會有這樣或那樣的難題。但小彭和其合作團隊的戰鬥力，是小彭信心高昂的一切來源。這是一支不同尋常的團隊，支撐的也是不同尋常的業務。業務上，小彭負責了商城所有訂單的履約生產過程，為每一個訂單實時高效的制定好最優的生產計劃，在過程中發出多個如拆單、轉倉、補貨等多個快速指令，為在商城中消費的每一個客戶提供最優服務，並最大可能性的降低履約生產過程中的生產成本。過去多次並肩作戰與衝鋒，早就鍛造了這支團隊獨特的戰鬥力。

和沛公的交談如預期中順利，但沛公說他還是要再認真考慮一下。是的，是要認真考慮一下，成熟的人總是要三思而後行，而一但確定好後就毫不猶豫的堅決執行。這個事情，風險和收益同樣巨大。幹得好則後面研發交付的工作可以發生變革式的變化，產品、業務來完成需求交付不再是個可望而不可及的事情；幹得不好，比如過程中遇到了無法突破的難題，或者交付後出現業務使用不佳的情況，辛辛苦苦投入的精力可能就會存在白費的情況，特別是面對如此高的交付壓力，一旦失敗，對上對下，都不好交代。

變革的過程總是很痛苦，而有先見之明的人在經歷痛苦後才能有機會涅槃重生。做，還是不做，這是一個擺在沛公面前的難題。在經過一個晚上的深思熟慮後，沛公心中就有了預判和決斷。這個事情是一個長期的事、有價值的事、正確的事，現在不做，將來也會要做。等將來專案及需求的壓力變得不可阻擋，不得不做的時候，重重壓力下執行的動作反而會變形。最好的時機就是當下，沛公已暗暗下定了決心。至於困難，總會有的，但是隻要信心在，辦法總比困難多。敢於衝鋒，直面失敗，這也是這個團隊難以磨滅的特質。

沛公找到了供應鏈負責整體效能同時身為首架的林老師溝通。林老師最近也一直在思考，如何將供應鏈高頻共性的研發動作進一步抽象、打造出合適的Y工具產品，並將工具提供開放給業務角色，來降低研發的需求數，提升交付效率，部門也一直在做這樣的探索，正好最近零（低）程式碼解決方案也初步有了成果，與沛公提到的想法不謀而合。兩個部門立刻決定，共同推進落地。

一個小的分隊很快就成立了，兩個團隊都挑選了一些精兵強將，共同負責功能的設計、開發及運維，具體帶隊的分別是小麗、小徐、小彭，總體架構師是林老師，部門中一些架構師和研發也自願踴躍參加，例如小孫、小馬、小丁、小夢、小張、小喜等。大家除了日常需要支援的本職工作外，其餘的時間都撲在了這個新產品能力的打造上了。和一般偉大的事業開啟必然附加有華美的篇章不同，研發的工作總是這樣，樸實而無華。沒有激情澎湃的讚歌，也沒有千里不留行的豪邁，只是一個接一個的不眠之夜。看似枯燥的工作，和冷冰冰的程式碼，但總難澆滅大家心中火熱的激情。每每深夜裡有一些靈光乍現的新思路，每個人總會趕緊拿手機記下來，再倒頭躺下。想到新的一天可以和團隊一起，討論新的思路和落地方式，大家按捺不住激動的內心，久久不能入睡。

一個月後，產品雛形已初步完成，小彭拉上業務線對口的產品和業務來試用，算是譭譽參半，小彭沒有洩氣，收集了大家的問題和反饋，並開始快速迭代。又半個月過去，產品總算達到了可用、可交付的狀態。經過一段時間的試點使用後，一些業務、產品開始主動來尋求合作和反饋。總算形成了正向反饋。