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

因為工作和其它原因，很長一段時間沒有出新的、關於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方法有以下區別：

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

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

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

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

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

本系列文章在公眾號不定時連載，請關註公眾號（讓APS成為可能）及時接收,二維碼：

 http://weixin.qq.com/r/WjtFXSvE2HanrW8_925I (二維碼自動識別)

如需瞭解更多關於OptaPlanner的應用，請發電郵致：[email protected]
或到討論組發表你的意見：https://groups.google.com/forum/#!forum/optaplanner-cn
若有需要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人日常工作繁忙，通過微信,QQ等工具可能無法深入溝通，較複雜的問題，建議以郵件或討論組方式提出。(討論組屬於google郵件列表，國內網路可能較難訪問，需自行解決)