流服務(wù)是什么

當(dāng)一個(gè)服務(wù)模塊的輸入和輸出都是流的時(shí)候，我們稱其為流服務(wù)。流服務(wù)的好處在于其可以直觀地描述業(yè)務(wù)執(zhí)行流程。

流服務(wù)使用 DAG 來描述執(zhí)行流程，DAG 的每個(gè)節(jié)點(diǎn)代表一個(gè)業(yè)務(wù)單元，每個(gè)業(yè)務(wù)單元負(fù)責(zé)一定的業(yè)務(wù)邏輯。

在業(yè)務(wù)單元中，經(jīng)常會(huì)用到一些具有特定功能的輔助性服務(wù)，如 IP 分析、GPS 解析、第三方征信服務(wù)等。將實(shí)現(xiàn)這些輔助性功能的代碼直接放入流計(jì)算應(yīng)用的業(yè)務(wù)代碼里，或許是一個(gè)好方法，特別是在我們非常在乎性能的時(shí)候。

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

考慮下，如果流計(jì)算任務(wù)需要用到很多輔助性功能（這種情況其實(shí)相當(dāng)常見），而且這些輔助性功能中的某些內(nèi)部邏輯甚至相當(dāng)復(fù)雜，那么將這些功能的實(shí)現(xiàn)代碼全都放到業(yè)務(wù)流程的實(shí)現(xiàn)中，勢必會(huì)造成業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)縱橫交錯(cuò)、程序執(zhí)行流程雜亂無章。

一種折中的方案是將輔助性功能抽取為獨(dú)立的源碼項(xiàng)目，將它們編譯為庫后再鏈接進(jìn)流計(jì)算應(yīng)用。

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

但這樣做也存在問題，即每次對輔助性功能服務(wù)做更改或升級時(shí)，流計(jì)算應(yīng)用必須重新構(gòu)建、測試和發(fā)布。

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

下圖描述了這種將輔助性功能剝離為單獨(dú)微服務(wù)，由流服務(wù)調(diào)用接口訪問的架構(gòu)。

這樣，流計(jì)算應(yīng)用負(fù)責(zé)整體的業(yè)務(wù)邏輯，而輔助性功能被封裝在一個(gè)個(gè)獨(dú)立的微服務(wù)內(nèi)并對外提供友好的使用界面，整個(gè)流計(jì)算系統(tǒng)架構(gòu)清晰，在將來需要調(diào)整時(shí)也更加靈活。

在流服務(wù)中調(diào)用外部的微服務(wù)也存在一個(gè)問題，即性能問題。

在狀態(tài)存儲(chǔ)時(shí)，我們建議使用本地?cái)?shù)據(jù)存儲(chǔ)方案替代遠(yuǎn)程數(shù)據(jù)存儲(chǔ)方案，原因在于遠(yuǎn)程數(shù)據(jù)存儲(chǔ)方案可能會(huì)極大地降低流服務(wù)的性能。與此類似，在流服務(wù)中調(diào)用外部微服務(wù)時(shí)也涉及網(wǎng)絡(luò) I/O，這同樣會(huì)比較顯著地降低流服務(wù)的性能。所以，我們要針對微服務(wù)的調(diào)用過程做優(yōu)化。

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

另外，必須強(qiáng)調(diào)的是，在流計(jì)算中使用微服務(wù)最好采用只讀方式，或者至少應(yīng)該是冪等的。因?yàn)?，如果流服?wù)訪問微服務(wù)時(shí)造成了外部狀態(tài)的改變，就有可能破壞流計(jì)算應(yīng)用整體的可靠性保證機(jī)制。

關(guān)于出現(xiàn)這個(gè)問題的原因，我們在前文討論各種開源流計(jì)算框架的消息傳達(dá)可靠性保證機(jī)制時(shí)已有所分析，這里不再贅述。

相比流服務(wù)，微服務(wù)是一種更加為大眾所知的服務(wù)組織架構(gòu)。

從形式上，微服務(wù)和流服務(wù)最大的區(qū)別在于，微服務(wù)是請求并響應(yīng)的模式，而流服務(wù)則是事件驅(qū)動(dòng)的模式。微服務(wù)系統(tǒng)架構(gòu)將復(fù)雜軟件系統(tǒng)按業(yè)務(wù)功能劃分為一個(gè)個(gè)獨(dú)立的服務(wù)模塊，每個(gè)服務(wù)模塊獨(dú)立開發(fā)、獨(dú)立部署、獨(dú)立提供服務(wù)，各獨(dú)立服務(wù)模塊之間天然是一種松耦合的狀態(tài)。

微服務(wù)確實(shí)有助于我們分解復(fù)雜的系統(tǒng)，但與之而來的問題是，它會(huì)讓業(yè)務(wù)系統(tǒng)變得復(fù)雜。

相比流服務(wù)有一個(gè)提綱挈領(lǐng)的 DAG 代表了完整的業(yè)務(wù)流程，微服務(wù)系統(tǒng)如果沒有額外的設(shè)計(jì)文檔進(jìn)行解釋，那么我們是很難一下就弄清楚業(yè)務(wù)系統(tǒng)的完整執(zhí)行流程的。

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

第一，大部分流計(jì)算框架是構(gòu)建在諸如YARN這樣的分布式操作系統(tǒng)上的，所以它們所運(yùn)行的環(huán)境已經(jīng)云化。這意味著基于這些流計(jì)算框架構(gòu)建的應(yīng)用是可以自由橫向伸縮的。

第二，大部分流計(jì)算框架或多或少地提供了管理界面，這讓我們能夠非常方便地監(jiān)測和追蹤運(yùn)行在系統(tǒng)中的應(yīng)用的狀況。

第三，大部分流計(jì)算框架具備一定的容錯(cuò)機(jī)制，并且可在服務(wù)失敗時(shí)自動(dòng)完成服務(wù)恢復(fù)，不需要我們外部干預(yù)。但是微服務(wù)就不一樣了。

微服務(wù)系統(tǒng)架構(gòu)和服務(wù)治理還是有較大距離的，甚至可以說，服務(wù)治理的概念最初正是為了更好地管理微服務(wù)系統(tǒng)而提出的。

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