OptaPlanner 7.32.0.Final版本彩蛋 - SolverManager之異步求解

OptaPlanner 7.32.0.Final版本彩蛋 – SolverManager之異步求解

2020 年 2 月 26 日
筆記

因為工作和其它原因，很長一段時間沒有出新的、關於OptaPlanner的文章了，但工余時間並沒有停止對該引擎的學習。與此同時Geoffrey大神帶領的KIE項目團隊並沒有閑下來，儘管在工業可用性、易用性和使用門檻方面，OptaPlanner相對傳統的求解器已經做得相當出色；特別是在規划過程交互、和各種操作接口方面，更是目前最為容易使用的規劃求解器。

以第7版一系列子版本中，OptaPlanner很多子版只作了細微的更新，如優化規劃性能，改善Business Center集成水平等。而在作為OptaPlanner直接使用者的我們而言，第7版的所有子版本中，目前本人認為最大最有意義的更新有2個。一個是7.9.0版本提供內了置的多線程規劃，從而實現了規划過程中的多CPU同時對同一問題進行運算，大大地發揮了多CPU（核）服務器的並行運算能力。而今天本文需要詳解的新增接口SolverManager則是在系統集成方面的另一次重大創新。SolverManager接口在7.32.0版本中發佈。

規劃服務的常見場景與異步服務

OptaPlanner的核心是一個運籌優化求解器，可以對各領域的規劃問題（NPC, NP-Hard問題）進行規劃求解，尋找出問題的近似最優解。OptaPlanner規劃組件提供了相當完善的求解運算功能。但在實際的規劃系統設計中，除了設計相應的規劃模型，還需要考慮規劃程序部署問題，便於與現有系統集成。這類部署問題並非OptaPlanner求解器自身的功能焦點。因此，對於我們軟件開發、工程人員而言，還需要設計好相應的架構系統，才能實現規劃程序與現有信息系統之間良好數據交互。

通常情況下規劃運算需要使用大量的運算資源，也即CPU運算能力。我們會把基於OptaPlanner的規劃程序部署成獨立的規劃服務，以接口方式與外界系統進行數據通訊。部署成獨立的服務除了有利於降低系統模塊間低耦合外，另一個重要原因是有利於運算資源的擴展。當問題規劃增大時，程序所需的CPU運算能力也會大副提升；獨立存在的規劃服務更有利於硬件資源的更新。當然，需要在Client端進行即時規劃的場景（例如手機導航軟件）除外。

因為規劃服務大多數情況下，需要一定的運算周期才能得到可行、且相對最優方案。若根據上述的場景需求，在常見的項目中，可以把規劃程序做成一個輕量級的Jar包，再過Web和應用服務器，以Web服務的方式對外提供服務。例如使用Spring Boot進行封裝，對外提供Web API服務。通過使Spring Boot的Controller與規劃程序包在進程上相互獨立，從而實現規劃服務的異步性。當然也可以通過在Spring Boot程序中通過多線程方式實現異常調用的特性。不同的實現方法視實際需要而定。

SolverManager特性解決異步問題

對於上述場景，OptaPlanner是否可提供Out-Of-The-Box的解決方案呢？在7.32.0.Final版本之前，求解器規劃問題時的接口方法是Solver.solve(),這個方法是同步的，需要規劃完成後才能返回。若需要實現異步功能，就需要自己想辦法實現了，例如上面提到的將服務進程與規划進程相互獨立，或使用不同的線程來響應服務和啟動規劃，實現起來對軟件架構設計需要有一定的經驗才能做得相對完善。很幸運，在7.32.0.Final版本中，終於從OptaPlanner內置功能上實現了此特性，這個就是SolverManager。SolverManager是7.32.0.Final版本提供的新接口，通過此接口我們可以在調用規劃核心程序進行問題求解時，調用線程即時返回，從而實現調用線程與規劃線程異步執行。具體訪求是：通過SolverManager.solve()方法可以啟動一個異步規劃方法，調用方可以即時返回，通過輪詢的方式調用SolverManager的其它方法來查詢規劃狀態（SolverManger.getSolverStatus）並獲取結果（SoverJob.getFinalBestSolution）。SolverManager的基本用法如下：

CloudBalance problem1 = ...;  UUID problemId = UUID.randomUUID();  // Returns immediately  SolverJob<CloudBalance, UUID> solverJob = solverManager.solve(problemId, problem1);  ...  CloudBalance solution1;  try {      // Returns only after solving terminates      solution1 = solverJob.getFinalBestSolution();  } catch (InterruptedException | ExecutionException e) {      throw ...;  }

可以看出，使用SolverManager 對一個問題進行求解時，與Solver對象的solve方法有以下區別：

異步執行，當solve方法被調用後，方法會馬上返回，而不待引擎運行結果。調用者需要通過輪詢或回調方法(bestSolutionChanged事件)獲取運行結果。
每個問題對應一個ID，因為SolverManager會啟動線程池同一時間對多個問題進行求解，因此每個問題需要有一個唯一的標識做識別，在下一篇文章中的SolverManger批量求解中將會詳解。

因此，在7.32.0.Final版本中，SolverManager的出現，將會在進行求解服務的設計過程中，大大簡化引擎與服務的設計複雜度。希望在未來的應用過讓OptaPlanner在工業場景的可能性上更勝一籌。

關於SolverManager接口的詳細介紹見以下使用說明：

https://docs.optaplanner.org/7.33.0.Final/optaplanner-docs/html_single/index.html#solverManagerdocs.optaplanner.org

原創不易，如果覺得文章對你有幫助，歡迎點贊、評論。文章有疏漏之處，歡迎批評指正。