當一個服務模塊的輸入和輸出都是流的時候，我們稱其為流服務。流服務的好處在于其可以直觀地描述業務執行流程。

流服務使用 DAG 來描述執行流程，DAG 的每個節點代表一個業務單元，每個業務單元負責一定的業務邏輯。

在業務單元中，經常會用到一些具有特定功能的輔助性服務，如 IP 分析、GPS 解析、第三方征信服務等。將實現這些輔助性功能的代碼直接放入流計算應用的業務代碼里，或許是一個好方法，特別是在我們非常在乎性能的時候。

畢竟將這些輔助性功能的邏輯集成到流應用里，會減少相當多的 I/O 操作，確保了流應用的性能。但是這樣做并不優雅。

考慮下，如果流計算任務需要用到很多輔助性功能（這種情況其實相當常見），而且這些輔助性功能中的某些內部邏輯甚至相當復雜，那么將這些功能的實現代碼全都放到業務流程的實現中，勢必會造成業務邏輯和技術細節縱橫交錯、程序執行流程雜亂無章。

一種折中的方案是將輔助性功能抽取為獨立的源碼項目，將它們編譯為庫后再鏈接進流計算應用。

這樣一方面能夠保證流計算應用的性能，另一方面避免了流計算應用的代碼過于雜亂。這樣做不失為一個比較好的辦法，并且在性能優先的情況下可能是最優選擇。

但這樣做也存在問題，即每次對輔助性功能服務做更改或升級時，流計算應用必須重新構建、測試和發布。

從服務治理的角度而言，我們還是應該將輔助性功能剝離出去，讓它們成為單獨的服務，對外提供 REST 或 RPC 的訪問接口。

下圖描述了這種將輔助性功能剝離為單獨微服務，由流服務調用接口訪問的架構。

這樣，流計算應用負責整體的業務邏輯，而輔助性功能被封裝在一個個獨立的微服務內并對外提供友好的使用界面，整個流計算系統架構清晰，在將來需要調整時也更加靈活。

在流服務中調用外部的微服務也存在一個問題，即性能問題。

在狀態存儲時，我們建議使用本地數據存儲方案替代遠程數據存儲方案，原因在于遠程數據存儲方案可能會極大地降低流服務的性能。與此類似，在流服務中調用外部微服務時也涉及網絡 I/O，這同樣會比較顯著地降低流服務的性能。所以，我們要針對微服務的調用過程做優化。

一方面，要小心謹慎地設計微服務，確保微服務能夠快速地返回，不管是成功還是失敗，都必須在給定的時間內快速返回。另一方面，流服務在調用微服務時，可以采取異步 I/O 的方式，這樣能夠保證流服務在處理事件時不會讓 CPU 阻塞在等待微服務請求返回，從而提升流服務的吞吐能力。

另外，必須強調的是，在流計算中使用微服務最好采用只讀方式，或者至少應該是冪等的。因為，如果流服務訪問微服務時造成了外部狀態的改變，就有可能破壞流計算應用整體的可靠性保證機制。

關于出現這個問題的原因，我們在前文討論各種開源流計算框架的消息傳達可靠性保證機制時已有所分析，這里不再贅述。

相比流服務，微服務是一種更加為大眾所知的服務組織架構。

從形式上，微服務和流服務最大的區別在于，微服務是請求并響應的模式，而流服務則是事件驅動的模式。微服務系統架構將復雜軟件系統按業務功能劃分為一個個獨立的服務模塊，每個服務模塊獨立開發、獨立部署、獨立提供服務，各獨立服務模塊之間天然是一種松耦合的狀態。

微服務確實有助于我們分解復雜的系統，但與之而來的問題是，它會讓業務系統變得復雜。

相比流服務有一個提綱挈領的 DAG 代表了完整的業務流程，微服務系統如果沒有額外的設計文檔進行解釋，那么我們是很難一下就弄清楚業務系統的完整執行流程的。

相比微服務而言，流服務的服務治理方案是“與生俱來”的，原因有以下幾點。

第一，大部分流計算框架是構建在諸如YARN這樣的分布式操作系統上的，所以它們所運行的環境已經云化。這意味著基于這些流計算框架構建的應用是可以自由橫向伸縮的。

第二，大部分流計算框架或多或少地提供了管理界面，這讓我們能夠非常方便地監測和追蹤運行在系統中的應用的狀況。

第三，大部分流計算框架具備一定的容錯機制，并且可在服務失敗時自動完成服務恢復，不需要我們外部干預。但是微服務就不一樣了。

微服務系統架構和服務治理還是有較大距離的，甚至可以說，服務治理的概念最初正是為了更好地管理微服務系統而提出的。

針對微服務系統的服務治理方案多種多樣，從 Apache Dubbo 和 Spring Cloud，到 Docker Swarm 和Kubernetes，再到如今的 Service Mesh 等，各種微服務治理方案可謂方興未艾，它們正在快速地發展和演進過程中。