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的應用，請發電郵致：kentbill@gmail.com
或到討論組發表你的意見：https://groups.google.com/forum/#!forum/optaplanner-cn
如有須要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人平常工做繁忙，經過微信,QQ等工具可能沒法深刻溝通，較複雜的問題，建議以郵件或討論組方式提出。(討論組屬於google郵件列表，國內網絡可能較難訪問，需自行解決)