概述

微服務架構作爲當前最流行的架構體系，它所集成的服務大都是輕量級的(這也是爲什麼叫微服務)。單個微服務內部實現邏輯簡單，處理客戶請求時間短，經常做一些數據的增刪改查操作。一般來說2到3千行代碼就可以實現一個微服務。

與輕量級的微服務對應的是重量級的算法服務。如何定義重量級服務呢？首先服務請求處理時間很長，一般在幾分鐘到幾個小時都有可能，視處理的數據量大小而定；其次，算法的輸入參數和輸出結果的數據量都很大。由於以上兩個原因，一般算法服務的併發能力都很弱(很多時候只允許同時處理一個請求，或者認爲它併發量就是1).

在微服務框架中如何集成這類算法服務呢？我認爲需要考慮三個方面：
1. 算法服務自動發現和任務調度。
2 .算法服務的輸入參數和計算結果數據傳遞。
3. 算法服務和任務狀態監控。

整體架構圖

由於算法服務資源是有限的，算法服務的併發能力也很差或者說沒有併發能力。我們需要一個算法調度服務來分配資源。算法服務部署後通過心跳註冊(IP地址、服務狀態等信息)，算法調度服務就拿到了所有算法服務的狀態和數量。

Client應用從算法調度服務申請計算任務，新任務添加到任務隊列裏面(可以放到內存也可以放到數據庫，推薦放到數據庫，重啓服務數據不丟失)。

算法調度服務檢測從算法服務上報的心跳，發現有算法服務空閒了，就從任務隊列中取出一個任務交給它去執行。

由於算法服務是重型化的，它需要的輸入參數和計算後的結果數據量都很大，直接通過restful接口傳遞不是特別合適。這裏提供一種思路：採用文件的方式傳遞。輸入參數和計算結果都通過JSON串的形式保存到文件，通過FTP上傳和下載。

監控進程實際上是算法服務的守護進程，和算法服務部署到同一個虛擬機或者docker容器裏面。監控服務啓動後就開始週期性的向調度服務發送心跳。

這個監控進程不是必須的，如果算法服務本身實現了心跳上報的功能，就不需要了。但是如果要實現對算法服務的啓停功能(kill進程，啓動進程)，那還是需要的。

上報心跳單獨拿出來說，上報心跳實現了很多功能：算法服務註冊，申請新任務，上報任務執行進度等。如果調度服務長時間收不到某個算法服務的心跳，會認爲它已經掉線了，會通知運維人員定位問題。