因爲工作和其它原因，很長一段時間沒有出新的、關於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#solverManager
原創不易，如果覺得文章對你有幫助，歡迎點贊、評論。文章有疏漏之處，歡迎批評指正。
本系列文章在公衆號不定時連載，請關注公衆號（讓APS成爲可能）及時接收,二維碼：
http://weixin.qq.com/r/WjtFXSvE2HanrW8_925I (二維碼自動識別)
如需瞭解更多關於OptaPlanner的應用，請發電郵致：[email protected]
或到討論組發表你的意見：https://groups.google.com/forum/#!forum/optaplanner-cn
若有需要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人日常工作繁忙，通過微信,QQ等工具可能無法深入溝通，較複雜的問題，建議以郵件或討論組方式提出。(討論組屬於google郵件列表，國內網絡可能較難訪問，需自行解決)