上一篇我們分別對“批量規劃”和“實時規劃”作了詳細介紹；OptaPlanner的這兩種開箱即用的特性在具體的工程實踐中極爲實用。
批量規劃可方便巧妙地解決多數據集同時規劃，可有效提高算力資源應用效率。此外，在規劃服務設計方面，基於批量規劃功能，可設計更爲簡潔可靠且高效的的異步服務方案。引擎在執行多個數據集並行運算時，可根據引擎配置來安排有多少個CPU核心參與規劃運算過程，也可使用引擎默認的CPU調度方案，實現服務程序的穩定性與性能的最佳平穩。
實時求解則是OptaPlanner特有功能，暫時未在其求解器中發現相關功能，若引擎本身不支持規劃運算啓動手，對數據集變更的響應能力，我們自己基於一個求解器來設計一套即時響應機制，還是有一定難度的。特別是規劃運算進行過程中，若求解器不提供相關接口，目前還是沒有可用的辦法實現功能的，該功能的工作過程爲：攔截運算過程 -> 更新數據集 -> 基於攔截前最佳方案繼續規劃。這3個步驟中的第1步與第3步，必須由引擎提供相關的API纔有可能實現。因此，OptaPlanner提供的實時規劃功能，在面對實時調度場景(例如：呼叫中心座席調度、AGV設備調度，基於VRP的實時車輛指揮等)時，可以提供官方正式的API來實現。且8.X之後對這些API作了進一步的簡化，只需一個接口的實現，即可實現對規劃過程中的數據集進行更新。因爲OptaPlanner對在規劃的方案實行的是Delta優化(即規劃過程中，實現的是增量、差異優化)，因此，在接收到變更請求後，會以極高的速度計劃出一個變更後的解並實時輸出，這種特性在實時性要求高的場景尤爲重要。
既然這兩種功能都相當實用，那麼有沒有辦法在一個系統中同時實現這兩個功能呢？也就是，我們能否將一批數據集同時提交給規劃服務進行規劃，在規劃過程中，若有些數據集產生變更，我們只需將變更提供到引擎中，引擎可以對變更的數據集產生即時響應，即時輸出該變更後的新解呢？
在8.17.0.Final版本之前，這個要求還沒有辦法實現的。因爲本人在自己經歷的項目開發工作及諮詢服務過程中經常會遇到需要實時規劃的過程；而通過SolverManager實現批量規劃在該功能推出後，也成爲求解數據集的常用方法(現在功能上較少用到簡單Solver進行求解)。但如果將上述兩種特性結合在一起使用呢?爲此，我還碰過一次壁。當我將原來的單次規劃代碼修改成批量規劃後，發現SolverManager並沒有提供實時規劃相關的API。OptaPlanner團隊的Goeffery給了我一個明確的答覆，這確實是SolverManager一個接口斷層(an API gap on SolverManager, 見以下郵件回覆). 也就是說，可實現批量規劃的SolverManager接口，在未支持實時規劃就發佈出來了。因此，但由於實時規劃在業務場景中是必要需求，因此，我只能重新將SolverManager改爲普通的Solver。
不久，在8.17.0.Final版本，SolverManager終於實現了批量+實時規劃了。
與此同時，OptaPlanner還對實時規劃的接口進行了簡化，在以往的版本中，需要分別實現Problem Fact Add/Delete(將Problem Fact, Planning Entity的添加、移除變更分別實現)。而新的實時規劃接口中，會把這些變化統一爲數據集(Problem)的變更，因此只需使用一個接口，在這個接口中針對不同場景編寫一個Problem中的各個實體變更邏輯即可。從而大大地簡化了實時規劃接口。
可參考以下示例代碼，調用接口，編寫實時規劃邏輯。
public class SolvingService { @Inject SolverManager<CloudBalance, Long> solverManager; // (1) public void startSolving(Long problemId) { solverManager.solveAndListen(problemId, this::loadProblem, bestSolution -> saveSolution(problemId, bestSolution)); // (2) } public void addComputer(Long problemId, CloudComputer computer) { solverManager.addProblemChange(problemId, (workingSolution, problemChangeDirector) -> { // (3) List<CloudComputer> computerList = new ArrayList<>(workingSolution.getComputerList()); workingSolution.setComputerList(computerList); problemChangeDirector.addProblemFact(computer, computerList::add); }); } private CloudBalance loadProblem(Long problemId) { // Load the input problem identified by the problemId. } private void saveSolution(Long problemId, CloudBalance cloudBalance) { // Save the best solution, or send it to UI, etc. } }
更詳細的API使用，大家可以參考OptaPlanner的用戶手冊或其JavaDoc。當然大家需要根據自己的規劃服務架構，對實時規劃功能進行合理設計。
上述是當前OptaPlanner在批量、實時規劃的一些實用技巧，供大家參考學習。
>>>>>>>> 彩蛋環節 <<<<<<<<<
OptaPlanner及APS、VRP等場景的應用相關的分享, 本人已斷斷續續寫了超過30篇文章(在知呼、博客園、csdn、[讓APS成爲可能]公衆號等平臺均有發佈)。本人也將開始職業的下半場 -將基於OptaPlanner開發一套適用於國內製造、物流、交通等領域的規劃平臺。此平臺將作爲本人接下來開展新一輪事業的基礎，預計將在6月初發佈一個雲端試用版，供有需要的客戶、網友和各位老師研究。若有合作機會及適當的應用場景，可基於該平臺根據具體業務場景開展一步定製。從而定製開發一套靈活實用的APS、VRP及其衍生系統。
關於該平臺，本文先以Q&A方式作簡要介紹，接下來會推出一系列相關文章、視頻，以模塊、業務場景爲單位，按章節進行有系統地說明。
Q: 能簡單能介紹一下該平臺嗎？
A：該平臺我暫時將其稱爲易規劃平臺(Easy Plan Platform), 它由多個模塊構成，各個模塊針對一個典型的規劃場景，當前的主要目標是實現PJS模塊和VRP模塊：
PJS模塊：即基於Project Job Scheduling模型，模塊適用於APS(生產計劃排程)和項目計劃排程。該模塊在常用的PJS模型的基礎上，實現了資源在空間與時間上的細分，從而解決了“多工序多資源”規劃場景下的難題，並自行開發了各個約束與優化目標的評分邏輯，從而極大地提高了規劃運算效率。該項目改善設計將會成爲本平臺首個專利設計提交申請。同時，該模塊提供項目計劃(大型裝備、船舶製造及建築施工等項目)優化接口，用於接收項目計劃規劃的元素(例如:項目，任務，資源等),可實現大模塊項目計劃排程優化。
VRP模塊：目前主要可應於經典的CVRPTW(Capacitated Vehicle Routing Problem with Time Windows)場景，具體的業務需求，可在此基礎上進一步擴展。此外，基於VRP的模塊擴展“AGV調度”和“固定節點運輸任務調度”場景。
Q：該平臺適用於哪些場景？
A：如前面對該平臺的介紹，目前平臺主要針對APS、VRP兩個場景。後續將根據市場反應與實際需求，陸續推出Call Center Scheuling(呼叫中心、預約控制調度)，Conference Scheduling(會議、講座日程規劃)，Facility Location(設施選址規劃), Maintenance Scheduling(日常維護工作調度)，Rostering(人員排班)和Inventory Scheduling(庫存優化)等模塊。
Q：該平臺是一套系統，它有何用，可直接部署給終端用戶使用嗎？
A: 該平臺目前的定位爲針對以下兩種場景：
- 市場現成運籌規劃產品(如APS, VRP類的產品)靈活性差，無法徹底滿足企業個性化業務需求。可基於我們的平臺，在成熟通用的規劃模型基礎上，靈活實現個性化定製要求。
- 對系統有靈活性、甚至原創性要求，但缺少從頭自研的運籌優化、應用數學人才資源的團隊；可在我們平臺的基礎上進行系統研發。
Q：若有意應用該平臺，如何合作？
A：如上述關於該平臺的作用說明。針對不同的場景可提供相應的合作方式。對於有自研需求的終端用戶，可提供基於企業業務場景的定製化擴展。對於有產品需求，可考慮基於本平臺的一些模型實現，進行產品自研，但平臺的設計技術、代碼版權歸屬，需要進一步商討。
關於該平臺的更多信息，會接下來的各篇文章中介紹，並在6月初平臺發佈時統一發布。敬請期待!
Q: 該平臺與市場上現有規劃類產品，及各位專家的方案有何區別？
A：與現成產品區別 - 平臺更低成本、靈活、可控，因爲平臺底層每一行代碼都由本人編寫，有任何不合理、不科學的地方均可修改。
與目前網絡上各位APS、VRP、規劃調度理論專家的方案區別 - 該平臺是一個具體的軟件系統，是基於OptaPlanner這個接地氣的求解器的一個具體工程化實現。各位專家、老師提出的很多理論、算法和方案，都用具體的設計、結構邏輯加以實現。而不是空有理論、方案，難以落地實踐的空中樓閣。更不是僅使用分配或排序邏輯簡單堆砌的僞運籌規劃系統。如：OptaPlanner實現了各種啓發式尋優算法，PJS模塊實現了 工藝+訂單=任務排程過程的業務實現，並使用成熟的PSJ模型實現了多工序關聯、多資源制約的排程；通過Springboot+引擎的批量、實時規劃功能，實現了基於Web服務的規劃運算節點，並實現完整的內存運算功能。
對着這些代碼2個多月了，平臺將作爲我家的3胎
另外，本人目前大部分工作時間已投身該平臺開發，經歷2個多月的研發，平臺已初步成形(規劃核心已完成，演示系統及文檔正在準備中)，接下需要進行不斷改進、重構和推廣合作。日後OptaPlanner相關的文章預計將會逐步減少，望諸位見諒，但並不代表從此不再出OptaPlanner應用相關的文章，對於該軟件的一些里程碑式的更新和功能，我還是會盡可能推出文章分享給大家。對於OptaPlanner的學習交流，之前有些網友不理解，對於簡單的技術問題，在我時間允許的情況下，留言給我，我會盡可能回覆，但因爲我不瞭解各位的業務場景，不可能太具有針對性。同時，有網友埋怨本人分享知識太少，本人實屬無法認同。畢竟本人也是以OptaPlanner規劃技術謀生的職場或商場普通技術人員，OptaPlanner本身是開源，但不代表我的知識也是開源的，分享相關入門知識和技術，只是希望中國的OptaPlanner應用生態圈慢慢成熟。但這並不是我的責任，我只是憑興趣爲之的義務工作。望各位海涵！
詳細的合作方式，可以與本人聯繫 13631823503 (微信同步)