本來這段時間一直都在加緊我家“三胎”（易排通用智能規劃平臺）建設，畢竟我們的通用規劃平臺原定6月初就能上線，但因爲其中遇到的各種技術問題及其它項目的突發情況，導致也只能跟隨國家的003號航母，只能推遲上線，進度緊迫。經過近兩個星期的奮戰，終於將我們的【易排通用智能規劃平臺】的主要功能上線了，並做了一些基本的使用資料，供各位小夥伴先得試用。
因爲我們的平臺還處在剛上線提供試用階段，後續還有數不清的功能、平臺設計、應用小視頻需要我日以繼夜地奮力補充（這些資料裏不僅僅有平臺的介紹資料喔，也有我們做規劃或供應鏈信息化設計過程中的一些滿滿乾貨，敬請期待），理應是安排不了時間發佈新的文章，但發現OptaPlanner已官宣，將在8.x版開始棄用對Drools評分機制，並在9.x不再支持Drools作爲評分，作爲替換的，將使用Constraint Stream（約束流）方式作爲評分。當然，之前支持的Easy Java score calculation和Incremental Java score calculation這兩種方式必然不會取消的。其中，我們的【易排通用規劃平臺】使用的就是Incremental Java score calculation，這種方式的優點是極度高效，有能力的小夥伴可以通過官言的示例嘗試一下，目前大多數案例都有多種評分方式的，可以通過修改配置來嘗試不同的評分方式，當問題空間足夠大時(相同的問題模型，問題空間基本上取決於數據量大小)，其運算時間差異可以是一個數量級的，甚至當數量大到一定程度時，使用Drools的評分方式會出現崩潰的情況(之前我們做過一個VRP項目遇到到這種情況，節點足夠多時，不是放一兩個小時就能跑出來，而是跑着跑着就出現JVM級別的溢出異常了)。
關於Drools評分方式（下稱DRL評分方式，官方也使用類似的叫法）的優劣，及未來補充的ConstraintStream方式，在本文中作一些概括性介紹，更詳細的資料及從DRL到ConstraintStream的轉換，可以參考OptaPlanner官方發佈的博文：
https://www.optaplanner.org/blog/2022/05/26/optaplanner-deprecates-score-drl.html
使用DRL評分方式的優點
邏輯表達豐富，可用較簡短的腳本表達較複雜的業務邏輯
因爲Drools本身是與OptaPlanner同屬一項目羣(KIE)的開源規劃引擎軟件，它具有一套成熟的規劃描述腳本及規則推理引擎。算是目前世界上最成熟的開源規則引擎了（有沒有之一不清晰，也許是我見識不夠廣）。因此，當我們使用Drools腳本，對OptaPlanner中涉及到的各種各樣業務規則(都會抽象成約束)進行評分描述時，是相當有優勢的。OptaPlanner這個引擎與Drools有相當豐富的接口，可實現兩個引擎之間的高度匹配，從而則讓OptaPlanner具備更豐富的約束表達能力。
自主生成OptaPlanner中規劃實體的約束違反統計信息
我們做OptaPlanner程序的時候，歸根到底是要以高效、合理的方式對讓引擎對各個規劃實體(Planning Entity)中的規劃變量(Planning Variable)進行不同的取值組合，並照我們編寫好的評分約束對各個組合方案進行評分，從中找到評分最高的組合方案。而在此過程中，若我們使用DRL評分方式，哪個規劃實體的哪個取值違反了哪條約束被扣了多少分，通過DRL的評分方式在運算過程，會把上述做詳細的記錄。因此，當我們完成規劃運算，得到一個方案時，通過這個方案和OptaPlanner的評分API，就可以完整、精確地描述出，究竟是哪個規劃實體的哪個變量取了什麼值違反了哪個約束，導致被扣了多少分了。這樣看來這個功能是不是很炫？目前我見到的其它求解器，應該還沒有提供這種功能吧？當然也可能是我孤陋寡聞。而這個功能在業務場景上來說，是相當有用的，就是說，當你的規劃程序跑出一個生產計劃方案，這個計劃方案哪個任務放在哪個機臺上，導致扣了多少分，你直接就可以通過它的約束違反信息，就可以直接找到違反約束的原因和具體數據。而不需要我們人工對整個計劃方案中的各個數據，一個一個尋找。
相同的功能要求，如果我們使用的評分方式是Incremental Java score calculation，是沒有自動的功能來記錄這些約束違反信息的，而是需要我們在實現這個約束邏輯Java代碼裏，編寫相應的評分邏輯，來保存這些信息的。完成了些邏輯後，最終生成的計劃方案，才能統計出各個任務的約束違反情況，否則你只能從方案知道它的分數概況，也就是僅能知道哪個約束扣了多少分，但是哪個任務分配到哪個機臺，因爲與哪個任務衝突引起的扣分，不通過人工去編寫邏輯，你是看不到的。
使用DRL評分方式的優點
老師教導我們，所有事物都要辯證地看，因爲事物必然具有兩面性的。那麼DRL的評分方式的缺點在哪裏呢？
學習成本
這個缺點對於我們沒有涉及到規劃引擎的小夥伴來說，肯定是一個巨大的差評。畢竟我們去掌握一門新的開發語言都需要花費不少精力了，況且還要學習掌握一門專門編寫規則的腳本，雖然它是一種描述性的腳本語言(我們在學校進而學計算課的時候，把這種語言稱爲第四代語言，例如：SQL腳本)，但絲毫不代表它簡單。在面對一些複雜的場景時，要實現一些約束的邏輯，我們寫腳本雖然不長，但其實要實現它，還是要花費不少心思的。總不會有人說，SQL腳本就比C++、Java簡單吧？SQL腳本簡單的僅僅是表達的方法，但處理一大堆複雜關聯查詢時，一條SQL的難點不一定比C++低，畢竟C++還是針對具體的每個對象進行運算的，而SQL則主要設計來針對一個數據集合進行處理的。所以並不能說它就簡單。
要完成對Drools引擎在OptaPlanner上的應用，除了要了解Drools腳本以外，還需要對Drools這個規則引擎的一些基本原理與結構有一定理解，才能更好的理解每個評分約束中，每個變更的含義，例如：哪些變量代表的是一個對象，什麼情況下一個變量代表的是一個對象列表。
當然若完全掌握了Drools的評分方式，並積累了一定用DRL表達OptaPlanner約束的經驗後，面對一些約束，還是很有“拿着錘子你看到的滿眼都是釘子”感覺的。也就是，當你面對一個約束時，會自然而然地很快通過Drools腳本來構思出它的大概邏輯結構。
運算效率
運算效率指的是使用DRL評分時，引擎的計算速度。若你深入瞭解了OptaPlanner引擎的主要工作就知道，它所謂的運算，絕大多數時間都是在進行分數計算，還有小部分是使用各種啓發式算法對搜尋過程的搜尋方向進行控制。因此，在這過程中，若使用DRL評分方式，Drools規則引擎就是擔起了一個非常大運算責任。但Drools其實還是需要把這些約束轉換成Java字節碼進行運算的，而且是大量的集合運算，因此，很多情況下，性能上相對直接用Java編寫的邏輯會更慢的。大家回憶一下各自的系統的性能卡頓點，是不是很多時候都是一些超長超複雜的SQL存儲過程造成的？而其實它卡的原因還不一定是它的邏輯複雜，而是一些邏輯涉到數據集的運算，當我們處理不好這些數據集的關聯查詢時，就會引起很大規模的集合與集合之間的關聯運算(就是各種表、視圖進行的各種Join)，從而成爲絕對的性能瓶。
Drools在進行約束評分運算時，實際上它就是一個規則推導過程，也有可能涉及很多對象集合的操作與判斷。因此，當數據量大，評分約束相當複雜，或關聯到衆多對象列表時，也有可能引起如SQL查詢一樣的效果，從而大大影響了運算性能。
DRL評分的替代 - ConstraintStream.
這種評分方式大概是從7.8x版本開始提出，8.x版本後開始慢慢完善。它充分使用了Java8以後的版本中出現的Stream特性，對大量的場景使用了函數式編程，從而大大地簡化了集合數據處理的難度。也就是說，如果我們在使用Java的Stream功能，能很靈活地編寫其中的Lambda表達式，ConstraintStream應用起來也是得心應手的。只是因爲ConstraintStream是專門針對約束編程的，因此，它提供了一些特定的API供我們使用，我們要理解這引起API的前提，還是要理解評分過程的一些原理與原則。這也是我們學習ConstraintStream最大難點。
我目前主要投入的精力都在我們的“三胎” - 【易排通用規劃平臺】上，這個平臺因爲基於靈活性與運算性能的考慮，我並沒有使用DRL或ConstraintStream方式，而是直接使用Incremental Java score calculation的方式。這種方式與前兩種對比，最貼切就理解就是單反相機與傻瓜相機的差別吧。正是因爲我能在沒有時間壓力的前提下，把我目前掌握到的各種排產約束通過Incremental Java score calculation方式精心實現，從而讓這個平臺在運算大數據量訂單時，性能遠比使用Drools或ConstraintStream高。期待大家可能嘗試該平臺，這個平臺我們將會使用租用方式，以SaaS方式提供一些有規劃要求的場景，例如MES、MOM的計劃模塊。令專門提供這類系統、方案的小夥伴可以開箱即用地擁有一個規劃引擎。當然，當你們遇到一些客戶的個性化需求、約束或優化目標，而在我們平臺上還沒有提供的，也歡大家向我們提出，我們可以通過項目合作的方式定製這些功能。
最後，我做了一個關於這個平臺的操作說明。因爲這個平臺主要是針對我們業內小夥伴，他們都有相應的軟件技術能力，且目前時間與精力都比較緊張；因此暫時未提供操作界面供大家使用，而是使用WebAPI方式供各位小夥伴集成到自己的系統中。當然要調用這些接口，其中一個很重要的步驟是把你們自己的系統中的業務數據，構建成這個接口的數據規範，才能把它傳進來調用這些接口。關於這個接口說明視頻，我已經發布在我的公衆號上，當然知呼視頻我也會上傳。後續我會把構建這些數據的各個要點以短視頻方式給大家提供講解，從這些短視頻中，並僅僅可以掌握這個平臺接口的一些約束，還可以學到一些不錯的乾貨，因爲這兩個月來，爲了構建這個接口數據，裏面表達業務的各種原理、規則、方案，設計一個推翻一個，經過無數次的迭代，最終才形成現在相對科學合理的結構。
接口說明：
https://mp.weixin.qq.com/s/DFLFNgRbJBP-iSONdeTPEQ
https://mp.weixin.qq.com/s/x46p0en7AQVxRIsioSAmhg
本系列文章在公衆號不定時連載，請關注公衆號（搜“讓APS成爲可能”）
如需瞭解更多關於OptaPlanner的應用，請發電郵致：12977379@http://qq.com
若有需要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人日常工作繁忙，通過微信,QQ等工具可能無法深入溝通，較複雜的問題，建議以郵件或討論組方式提出。(討論組屬於google郵件列表，國內網絡可能較難訪問，需自行解決)