復(fù)雜分布式架構(gòu)下的計(jì)算治理之路

作者：JAVA油膩男 關(guān)注 2020-01-06 10:41:52

開(kāi)發(fā)

架構(gòu)

分布式 在當(dāng)前的復(fù)雜分布式架構(gòu)環(huán)境下，服務(wù)治理已經(jīng)大行其道。但目光往下一層，從上層 APP、Service，到底層計(jì)算引擎這一層面，卻還是各個(gè)引擎各自為政，Client-Server模式緊耦合滿天飛的情況。

創(chuàng)新互聯(lián)是一家業(yè)務(wù)范圍包括IDC托管業(yè)務(wù),雅安服務(wù)器托管、主機(jī)租用、主機(jī)托管，四川、重慶、廣東電信服務(wù)器租用,雅安移動(dòng)機(jī)房，成都網(wǎng)通服務(wù)器托管,成都服務(wù)器租用,業(yè)務(wù)范圍遍及中國(guó)大陸、港澳臺(tái)以及歐美等多個(gè)國(guó)家及地區(qū)的互聯(lián)網(wǎng)數(shù)據(jù)服務(wù)公司。

 引子

在當(dāng)前的復(fù)雜分布式架構(gòu)環(huán)境下，服務(wù)治理已經(jīng)大行其道。但目光往下一層，從上層 APP、Service，到底層計(jì)算引擎這一層面，卻還是各個(gè)引擎各自為政，Client-Server模式緊耦合滿天飛的情況。如何做好“計(jì)算治理”，讓復(fù)雜環(huán)境下各種類(lèi)型的大量計(jì)算任務(wù)，都能更簡(jiǎn)潔、靈活、有序、可控的提交執(zhí)行，和保障成功返回結(jié)果?計(jì)算中間件 Linkis 就是上述問(wèn)題的實(shí)踐。

一、復(fù)雜分布式架構(gòu)環(huán)境下的計(jì)算治理有什么問(wèn)題?

1. 什么是復(fù)雜分布式架構(gòu)環(huán)境?

分布式架構(gòu)，指的是系統(tǒng)的組件分布在通過(guò)網(wǎng)絡(luò)相連的不同計(jì)算機(jī)上，組件之間通過(guò)網(wǎng)絡(luò)傳遞消息進(jìn)行通信和協(xié)調(diào)，協(xié)同完成某一目標(biāo)。一般來(lái)說(shuō)有水平(集群化)和垂直(功能模塊切分)兩個(gè)拆分方向，以解決高內(nèi)聚低耦合、高并發(fā)、高可用等方面問(wèn)題。

多個(gè)分布式架構(gòu)的系統(tǒng)，組成分布式系統(tǒng)群，就形成了一個(gè)相對(duì)復(fù)雜的分布式架構(gòu)環(huán)境。通常包含多種上層應(yīng)用服務(wù)，多種底層基礎(chǔ)計(jì)算存儲(chǔ)引擎。如下圖所示：

2. 什么是計(jì)算治理?

就像《微服務(wù)設(shè)計(jì)》一書(shū)中提到的，如同城市規(guī)劃師在面對(duì)一座龐大、復(fù)雜且不斷變化的城市時(shí)，所需要做的規(guī)劃、設(shè)計(jì)和治理一樣，龐大復(fù)雜的軟件系統(tǒng)環(huán)境中的各種區(qū)域、元素、角色和關(guān)系，也需要整治和管理，以使其以一種更簡(jiǎn)潔、優(yōu)雅、有序、可控的方式協(xié)同運(yùn)作，而不是變成一團(tuán)亂麻。

在當(dāng)前的復(fù)雜分布式架構(gòu)環(huán)境下，大量 APP、Service 間的通信、協(xié)調(diào)和管理，已經(jīng)有了從 SOA(Service-Oriented Architecture)到微服務(wù)的成熟理念，及從 ESB 到 Service Mesh 的眾多實(shí)踐，來(lái)實(shí)現(xiàn)其從服務(wù)注冊(cè)發(fā)現(xiàn)、配置管理、網(wǎng)關(guān)路由，到流控熔斷、日志監(jiān)控等一系列完整的服務(wù)治理功能。服務(wù)治理框架的“中間件”層設(shè)計(jì)，可以很好的實(shí)現(xiàn)服務(wù)間的解耦、異構(gòu)屏蔽和互操作，并提供路由、流控、狀態(tài)管理、監(jiān)控等治理特性的共性提煉和復(fù)用，增強(qiáng)整個(gè)架構(gòu)的靈活性、管控能力、可擴(kuò)展性和可維護(hù)性。

但目光往下一層，你會(huì)發(fā)現(xiàn)在從 APP、Service，到后臺(tái)引擎這一層面，卻還是各個(gè)引擎各自為政，Client-Server 模式緊耦合滿天飛的情況。在大量的上層應(yīng)用，和大量的底層引擎之間，缺乏一層通用的“中間件”框架設(shè)計(jì)。類(lèi)似下圖的網(wǎng)狀。

計(jì)算治理，關(guān)注的正是上層應(yīng)用和底層計(jì)算(存儲(chǔ))引擎之間，從 Client 到 Server 的連接層范圍，所存在的緊耦合、靈活性和管控能力欠缺、缺乏復(fù)用能力、可擴(kuò)展性、可維護(hù)性差等問(wèn)題。要讓復(fù)雜分布式架構(gòu)環(huán)境下各種類(lèi)型的計(jì)算任務(wù)，都能更簡(jiǎn)潔、靈活、有序、可控的提交執(zhí)行，和成功返回結(jié)果。如下圖所示：

3. 計(jì)算治理問(wèn)題描述

更詳細(xì)的來(lái)看計(jì)算治理的問(wèn)題，可以分為如下治(architecture，架構(gòu)層面)和理(insight，細(xì)化特性)兩個(gè)層面。

(1)計(jì)算治理之治(architecture)- 架構(gòu)層面問(wèn)題。

緊耦合問(wèn)題，上層應(yīng)用和底層計(jì)算存儲(chǔ)引擎間的 CS 連接模式。

所有 APP& Service 和底層計(jì)算存儲(chǔ)引擎，都是通過(guò) Client-Server 模式相連，處于緊耦合狀態(tài)。以 Analytics Engine 的 Spark 為例，如下圖：

這種狀態(tài)會(huì)帶來(lái)如下問(wèn)題：

• 引擎 client 的任何改動(dòng)(如版本升級(jí))，將直接影響每一個(gè)嵌入了該 client 的上層應(yīng)用;當(dāng)應(yīng)用系統(tǒng)數(shù)量眾多、規(guī)模龐大時(shí)，一次改動(dòng)的成本會(huì)很高;
• 直連模式，導(dǎo)致上層應(yīng)用缺乏，對(duì)跨底層計(jì)算存儲(chǔ)引擎實(shí)例級(jí)別的，路由選擇、負(fù)載均衡等能力;或者說(shuō)依賴(lài)于特定底層引擎提供的特定連接方式實(shí)現(xiàn)，有的引擎有一些，有的沒(méi)有;
• 隨著時(shí)間推移，不斷有新的上層應(yīng)用和新的底層引擎加入進(jìn)來(lái)，整體架構(gòu)和調(diào)用關(guān)系將愈發(fā)復(fù)雜，可擴(kuò)展性、可靠性和可維護(hù)性降低。

重復(fù)造輪子問(wèn)題，每個(gè)上層應(yīng)用工具系統(tǒng)都要重復(fù)解決計(jì)算治理問(wèn)題。

每個(gè)上層應(yīng)用都要重復(fù)的去集成各種 client，創(chuàng)建和管理 client 到引擎的連接及其狀態(tài)，包括底層引擎元數(shù)據(jù)的獲取與管理。在并發(fā)使用的用戶逐漸變多、并發(fā)計(jì)算任務(wù)量逐漸變大時(shí)，每個(gè)上層應(yīng)用還要重復(fù)的去解決多個(gè)用戶間在 client 端的資源爭(zhēng)用、權(quán)限隔離，計(jì)算任務(wù)的超時(shí)管理、失敗重試等等計(jì)算治理問(wèn)題。

想象你有 10 個(gè)并發(fā)任務(wù)數(shù)過(guò)百的上層應(yīng)用，不管是基于 Web 的 IDE 開(kāi)發(fā)環(huán)境、可視化 BI 系統(tǒng)，還是報(bào)表系統(tǒng)、工作流調(diào)度系統(tǒng)等，每個(gè)接入 3 個(gè)底層計(jì)算引擎。上述的計(jì)算治理問(wèn)題，你可能得逐一重復(fù)的去解決 10*3=30 遍，而這正是當(dāng)前在各個(gè)公司不斷發(fā)生的現(xiàn)實(shí)情況，其造成的人力浪費(fèi)不可小覷。

擴(kuò)展難問(wèn)題，上層應(yīng)用新增對(duì)接底層計(jì)算引擎，維護(hù)成本高，改動(dòng)大。

在 CS 的緊耦合模式下，上層應(yīng)用每新增對(duì)接一個(gè)底層計(jì)算引擎，都需要有較大改動(dòng)。

以對(duì)接 Spark 為例，在上層應(yīng)用系統(tǒng)中的每一臺(tái)需要提交 Spark 作業(yè)的機(jī)器，都需要部署和維護(hù)好 Java 和 Scala 運(yùn)行時(shí)環(huán)境和變量，下載和部署 Spark Client 包，且配置并維護(hù) Spark 相關(guān)的環(huán)境變量。如果要使用 Spark on YARN 模式，那么你還需要在每一臺(tái)需要提交 Spark 作業(yè)的機(jī)器上，去部署和維護(hù) Hadoop 相關(guān)的 jar 包和環(huán)境變量。再如果你的 Hadoop 集群需要啟用 Kerberos 的，那么很不幸，你還需要在上述的每臺(tái)機(jī)器去維護(hù)和調(diào)試 keytab、principal 等一堆 Kerberos 相關(guān)配置。

這還僅僅是對(duì)接 Spark 一個(gè)底層引擎。隨著上層應(yīng)用系統(tǒng)和底層引擎的數(shù)量增多，需要維護(hù)的關(guān)系會(huì)是個(gè)笛卡爾積式的增長(zhǎng)，光 Client 和配置的部署維護(hù)，就會(huì)成為一件很令人頭疼的事情。

應(yīng)用孤島問(wèn)題，跨不同應(yīng)用工具、不同計(jì)算任務(wù)間的互通問(wèn)題。

多個(gè)相互有關(guān)聯(lián)的上層應(yīng)用，向后臺(tái)引擎提交執(zhí)行的不同計(jì)算任務(wù)之間，往往是有所關(guān)聯(lián)和共性的，比如需要共享一些用戶定義的運(yùn)行時(shí)環(huán)境變量、函數(shù)、程序包、數(shù)據(jù)文件等。當(dāng)前情況往往是一個(gè)個(gè)應(yīng)用系統(tǒng)就像一座座孤島，相關(guān)信息和資源無(wú)法直接共享，需要手動(dòng)在不同應(yīng)用系統(tǒng)里重復(fù)定義和維護(hù)。

典型例子是在數(shù)據(jù)批處理程序開(kāi)發(fā)過(guò)程中，用戶在數(shù)據(jù)探索開(kāi)發(fā) IDE 系統(tǒng)中定義的一系列變量、函數(shù)，到了數(shù)據(jù)可視化系統(tǒng)里往往又要重新定義一遍;IDE 系統(tǒng)運(yùn)行生成的數(shù)據(jù)文件位置和名稱(chēng)，不能直接方便的傳遞給可視化系統(tǒng);依賴(lài)的程序包也需要從 IDE 系統(tǒng)下載、重新上傳到可視化系統(tǒng);到了工作流調(diào)度系統(tǒng)，這個(gè)過(guò)程還要再重復(fù)一遍。不同上層應(yīng)用間，計(jì)算任務(wù)的運(yùn)行依賴(lài)缺乏互通、復(fù)用能力。

(2)計(jì)算治理之理(insight)- 細(xì)化特性問(wèn)題：

除了上述的架構(gòu)層面問(wèn)題，要想讓復(fù)雜分布式架構(gòu)環(huán)境下，各種類(lèi)型的計(jì)算任務(wù)，都能更簡(jiǎn)潔、靈活、有序、可控的提交執(zhí)行，和成功返回結(jié)果，計(jì)算治理還需關(guān)注高并發(fā)，高可用，多租戶隔離，資源管控，安全增強(qiáng)，計(jì)算策略等等細(xì)化特性問(wèn)題。這些問(wèn)題都比較直白易懂，這里就不一一展開(kāi)論述了。

二、基于計(jì)算中間件 Linkis 的計(jì)算治理 - 治之路(Architecture)

1. Linkis 架構(gòu)設(shè)計(jì)介紹

核心功能模塊與流程

計(jì)算中間件 Linkis，是微眾銀行專(zhuān)門(mén)設(shè)計(jì)用來(lái)解決上述緊耦合、重復(fù)造輪子、擴(kuò)展難、應(yīng)用孤島等計(jì)算治理問(wèn)題的。當(dāng)前主要解決的是復(fù)雜分布式架構(gòu)的典型場(chǎng)景 - 數(shù)據(jù)平臺(tái)環(huán)境下的計(jì)算治理問(wèn)題。

Linkis 作為計(jì)算中間件，在上層應(yīng)用和底層引擎之間，構(gòu)建了一層中間層。能夠幫助上層應(yīng)用，通過(guò)其對(duì)外提供的標(biāo)準(zhǔn)化接口(如 HTTP, JDBC, Java …)，快速的連接到多種底層計(jì)算存儲(chǔ)引擎(如 Spark、Hive、TiSpark、MySQL、Python 等)，提交執(zhí)行各種類(lèi)型的計(jì)算任務(wù)，并實(shí)現(xiàn)跨上層應(yīng)用間的計(jì)算任務(wù)運(yùn)行時(shí)上下文和依賴(lài)的互通和共享。且通過(guò)提供多租戶、高并發(fā)、任務(wù)分發(fā)和管理策略、資源管控等特性支持，使得各種計(jì)算任務(wù)更靈活、可靠、可控的提交執(zhí)行，成功返回結(jié)果，大大降低了上層應(yīng)用在計(jì)算治理層的開(kāi)發(fā)和運(yùn)維成本、與整個(gè)環(huán)境的架構(gòu)復(fù)雜度，填補(bǔ)了通用計(jì)算治理軟件的空白。

要更詳細(xì)的了解計(jì)算任務(wù)通過(guò) Linkis 的提交執(zhí)行過(guò)程，我們先來(lái)看看 Linkis 核心的“計(jì)算治理服務(wù)”部分的內(nèi)部架構(gòu)和流程。如下圖：

計(jì)算治理服務(wù)：計(jì)算中間件的核心計(jì)算框架，主要負(fù)責(zé)作業(yè)調(diào)度和生命周期管理、計(jì)算資源管理，以及引擎連接器的生命周期管理。

公共增強(qiáng)服務(wù)：通用公共服務(wù)，提供基礎(chǔ)公共功能，可服務(wù)于 Linkis 各種服務(wù)及上層應(yīng)用系統(tǒng)。

其中計(jì)算治理服務(wù)的主要模塊如下：

• 入口服務(wù) Entrance，負(fù)責(zé)接收作業(yè)請(qǐng)求，轉(zhuǎn)發(fā)作業(yè)請(qǐng)求給對(duì)應(yīng)的 Engine，并實(shí)現(xiàn)異步隊(duì)列、高并發(fā)、高可用、多租戶隔離
• 應(yīng)用管理服務(wù) AppManager，負(fù)責(zé)管理所有的 EngineConnManager 和 EngineConn，并提供 EngineConnManager 級(jí)和 EngineConn 級(jí)標(biāo)簽?zāi)芰?加載新引擎插件，向 RM 申請(qǐng)資源， 要求 EM 根據(jù)資源創(chuàng)建 EngineConn;基于標(biāo)簽功能，為作業(yè)分配可用 EngineConn。
• 資源管理服務(wù) ResourceManager，接收資源申請(qǐng)，分配資源，提供系統(tǒng)級(jí)、用戶級(jí)資源管控能力，并為 EngineConnManager 級(jí)和 EngineConn 提供負(fù)載管控。
• 引擎連接器管理服務(wù) EngineConn Manager，負(fù)責(zé)啟動(dòng) EngineConn，管理 EngineConn 的生命周期，并定時(shí)向 RM 上報(bào)資源和負(fù)載情況。
• 引擎連接器 EngineConn，負(fù)責(zé)與底層引擎交互，解析和轉(zhuǎn)換用戶作業(yè)，提交計(jì)算任務(wù)給底層引擎，并實(shí)時(shí)監(jiān)聽(tīng)底層引擎執(zhí)行情況，回推相關(guān)日志、進(jìn)度和狀態(tài)給 Entrance。

如上圖所示，一個(gè)作業(yè)的提交執(zhí)行主要分為以下 11 步：

1. 上層應(yīng)用向計(jì)算中間件提交作業(yè)，微服務(wù)網(wǎng)關(guān) SpringCloud Gateway 接收作業(yè)并轉(zhuǎn)發(fā)給 Entrance。

2. Entrance 消費(fèi)作業(yè)，為作業(yè)向 AppManager 申請(qǐng)可用 EngineConn。

3. 如果不存在可復(fù)用的 Engine，AppManager 嘗試向 ResourceManager 申請(qǐng)資源，為作業(yè)啟動(dòng)一個(gè)新 EngineConn。

4. 申請(qǐng)到資源，要求 EngineConnManager 依照資源啟動(dòng)新 EngineConn

5.EngineConnManager 啟動(dòng)新 EngineConn，并主動(dòng)回推新 EngineConn 信息。

6. AppManager 將新 EngineConn 分配給 Entrance，Entrance 將 EngineConn 分配給用戶作業(yè)，作業(yè)開(kāi)始執(zhí)行，將計(jì)算任務(wù)提交給 EngineConn。

7.EngineConn 將計(jì)算任務(wù)提交給底層計(jì)算引擎。

8.EngineConn 實(shí)時(shí)監(jiān)聽(tīng)底層引擎執(zhí)行情況，回推相關(guān)日志、進(jìn)度和狀態(tài)給 Entrance，Entrance 通過(guò) WebSocket，主動(dòng)回推 EngineConn 傳過(guò)來(lái)的日志、進(jìn)度和狀態(tài)給上層應(yīng)用系統(tǒng)。

9.EngineConn 執(zhí)行完成后，回推計(jì)算任務(wù)的狀態(tài)和結(jié)果集信息，Entrance 將作業(yè)和結(jié)果集信息更新到 JobHistory，并通知上層應(yīng)用系統(tǒng)。

10. 上層應(yīng)用系統(tǒng)訪問(wèn) JobHistory，拿到作業(yè)和結(jié)果集信息。

11. 上層應(yīng)用系統(tǒng)訪問(wèn) Storage，請(qǐng)求作業(yè)結(jié)果集。

計(jì)算任務(wù)管理策略支持

在復(fù)雜分布式環(huán)境下，一個(gè)計(jì)算任務(wù)往往不單會(huì)是簡(jiǎn)單的提交執(zhí)行和返回結(jié)果，還可能需要面對(duì)提交失敗、執(zhí)行失敗、hang 住等問(wèn)題，且在大量并發(fā)場(chǎng)景下還需通過(guò)計(jì)算任務(wù)的調(diào)度分發(fā)，解決租戶間互相影響、負(fù)載均衡等問(wèn)題。

Linkis 通過(guò)對(duì)計(jì)算任務(wù)的標(biāo)簽化，實(shí)現(xiàn)了在任務(wù)調(diào)度、分發(fā)、路由等方面計(jì)算任務(wù)管理策略的支持，并可按需配置超時(shí)、自動(dòng)重試，及灰度、多活等策略支持。

基于 Spring Cloud 微服務(wù)框架

說(shuō)完了業(yè)務(wù)架構(gòu)，我們現(xiàn)在來(lái)聊聊技術(shù)架構(gòu)。在計(jì)算治理層環(huán)境下，很多類(lèi)型的計(jì)算任務(wù)具有生命周期較短的特征，如一個(gè) Spark job 可能幾十秒到幾分鐘就執(zhí)行完，EngineConn(EnginConnector)會(huì)是大量動(dòng)態(tài)啟停的狀態(tài)。前端用戶和 Linkis 中其他管理角色的服務(wù)，需要能夠及時(shí)動(dòng)態(tài)發(fā)現(xiàn)相關(guān)服務(wù)實(shí)例的狀態(tài)變化，并獲取最新的服務(wù)實(shí)例訪問(wèn)地址信息。同時(shí)需要考慮，各模塊間的通信、路由、協(xié)調(diào)，及各模塊的橫向擴(kuò)展、負(fù)載均衡、高可用等能力。

基于以上需求，Linkis 實(shí)際是基于 Spring Cloud 微服務(wù)框架技術(shù)，將上述的每一個(gè)模塊 / 角色，都封裝成了一個(gè)微服務(wù)，構(gòu)建了多個(gè)微服務(wù)組，整合形成了 Linkis 的完整計(jì)算中間件能力。

從多租戶管理角度，上述服務(wù)可區(qū)分為租戶相關(guān)服務(wù)，和租戶無(wú)關(guān)服務(wù)兩種類(lèi)型。租戶相關(guān)服務(wù)，是指一些任務(wù)邏輯處理負(fù)荷重、資源消耗高，或需要根據(jù)具體租戶、用戶、物理機(jī)器等，做隔離劃分、避免相互影響的服務(wù)，如 Entrance, EnginConn(EnginConnector) Manager, EnginConn;其他如 App Manger, Resource Manager、Context Service 等服務(wù)，都是租戶無(wú)關(guān)的。

Eureka 承擔(dān)了微服務(wù)動(dòng)態(tài)注冊(cè)與發(fā)現(xiàn)中心，及所有租戶無(wú)關(guān)服務(wù)的負(fù)載均衡、故障轉(zhuǎn)移功能。

Eureka 有個(gè)局限，就是在其客戶端，對(duì)后端微服務(wù)實(shí)例的發(fā)現(xiàn)與狀態(tài)刷新機(jī)制，是客戶端主動(dòng)輪詢刷新，最快可設(shè) 1 秒 1 次(實(shí)際要幾秒才能完成刷新)。這樣在 Linkis 這種需要快速刷新大量后端 EnginConn 等服務(wù)的狀態(tài)的場(chǎng)景下，時(shí)效得不到滿足，且定時(shí)輪詢刷新對(duì) Eureka server、對(duì)后端微服務(wù)實(shí)例的成本都很高。

為此我們對(duì) Spring Cloud Ribbon 做了改造，在其中封裝了 Eureka client 的微服務(wù)實(shí)例狀態(tài)刷新方法，并把它做成滿足條件主動(dòng)請(qǐng)求刷新，而不會(huì)再頻繁的定期輪詢。從而在滿足時(shí)效的同時(shí)，大大降低了狀態(tài)獲取的成本。

Spring Cloud Gateway 承擔(dān)了外部請(qǐng)求 Linkis 的入口網(wǎng)關(guān)的角色，幫助在服務(wù)實(shí)例不斷發(fā)生變化的情況下，簡(jiǎn)化前端用戶的調(diào)用邏輯，快速方便的獲取最新的服務(wù)實(shí)例訪問(wèn)地址信息。

Spring Cloud Gateway 有個(gè)局限，就是一個(gè) WebSocket 客戶端只能將請(qǐng)求轉(zhuǎn)發(fā)給一個(gè)特定的后臺(tái)服務(wù)，無(wú)法完成一個(gè) WebSocket 客戶端通過(guò)網(wǎng)關(guān) API 對(duì)接后臺(tái)多個(gè) WebSocket 微服務(wù)，而這在我們的 Entrance HA 等場(chǎng)景需要用到。

為此 Linkis 對(duì) Spring Cloud Gateway 做了相應(yīng)改造，在 Gateway 中實(shí)現(xiàn)了 WebSocket 路由轉(zhuǎn)發(fā)器，用于與客戶端建立 WebSocket 連接。建立連接成功后，會(huì)自動(dòng)分析客戶端的 WebSocket 請(qǐng)求，通過(guò)規(guī)則判斷出請(qǐng)求該轉(zhuǎn)發(fā)給哪個(gè)后端微服務(wù)，然后將 WebSocket 請(qǐng)求轉(zhuǎn)發(fā)給對(duì)應(yīng)的后端微服務(wù)實(shí)例。詳見(jiàn) Github 上 Linkis 的 Wiki 中，“Gateway 的多 WebSocket 請(qǐng)求轉(zhuǎn)發(fā)實(shí)現(xiàn)”一文。

Spring Cloud OpenFeign提供的 HTTP 請(qǐng)求調(diào)用接口化、解析模板化能力，幫助 Linkis 構(gòu)建了底層 RPC 通信框架。

但基于 Feign 的微服務(wù)之間 HTTP 接口的調(diào)用，只能滿足簡(jiǎn)單的 A 微服務(wù)實(shí)例根據(jù)簡(jiǎn)單的規(guī)則隨機(jī)選擇 B 微服務(wù)之中的某個(gè)服務(wù)實(shí)例，而這個(gè) B 微服務(wù)實(shí)例如果想異步回傳信息給調(diào)用方，是無(wú)法實(shí)現(xiàn)的。同時(shí)，由于 Feign 只支持簡(jiǎn)單的服務(wù)選取規(guī)則，無(wú)法做到將請(qǐng)求轉(zhuǎn)發(fā)給指定的微服務(wù)實(shí)例，無(wú)法做到將一個(gè)請(qǐng)求廣播給接收方微服務(wù)的所有實(shí)例。

Linkis 基于 Feign 實(shí)現(xiàn)了一套自己的底層 RPC 通信方案，集成到了所有 Linkis 的微服務(wù)之中。一個(gè)微服務(wù)既可以作為請(qǐng)求調(diào)用方，也可以作為請(qǐng)求接收方。作為請(qǐng)求調(diào)用方時(shí)，將通過(guò) Sender 請(qǐng)求目標(biāo)接收方微服務(wù)的 Receiver;作為請(qǐng)求接收方時(shí)，將提供 Receiver 用來(lái)處理請(qǐng)求接收方 Sender 發(fā)送過(guò)來(lái)的請(qǐng)求，以便完成同步響應(yīng)或異步響應(yīng)。如下圖示意。詳見(jiàn) Github 上 Linkis 的 Wiki 中，“Linkis RPC 架構(gòu)介紹”一文。

至此，Linkis 對(duì)上層應(yīng)用和底層引擎的解耦原理，其核心架構(gòu)與流程設(shè)計(jì)，及基于 Spring Cloud 微服務(wù)框架實(shí)現(xiàn)的，各模塊微服務(wù)化動(dòng)態(tài)管理、通信路由、橫向擴(kuò)展能力介紹完畢。

2. 解耦：Linkis 如何解耦上層應(yīng)用和底層引擎

Linkis 作為計(jì)算中間件，在上層應(yīng)用和底層引擎之間，構(gòu)建了一層中間層。上層應(yīng)用所有計(jì)算任務(wù)，先通過(guò) HTTP、WebSocket、Java 等接口方式提交給 Linkis，再由 Linkis 轉(zhuǎn)交給底層引擎。原有的上層應(yīng)用以 CS 模式直連底層引擎的緊耦合得以解除，因此實(shí)現(xiàn)了解耦。如下圖所示：

通過(guò)解耦，底層引擎的變動(dòng)有了 Linkis 這層中間件緩沖，如引擎 client 的版本升級(jí)，無(wú)需再對(duì)每一個(gè)對(duì)接的上層應(yīng)用做逐個(gè)改動(dòng)，可在 Linkis 層統(tǒng)一完成。并能在 Linkis 層，實(shí)現(xiàn)對(duì)上層應(yīng)用更加透明和友好的升級(jí)策略，如灰度切換、多活等策略支持。且即使后繼接入更多上層應(yīng)用和底層引擎，整個(gè)環(huán)境復(fù)雜度也不會(huì)有大的變化，大大降低了開(kāi)發(fā)運(yùn)維工作負(fù)擔(dān)。

3. 復(fù)用：對(duì)于上層應(yīng)用，Linkis 如何凝練計(jì)算治理模塊供復(fù)用，避免重復(fù)開(kāi)發(fā)

上層應(yīng)用復(fù)用 Linkis 示例(Scriptis)

有了 Linkis，上層應(yīng)用可以基于 Linkis，快速實(shí)現(xiàn)對(duì)多種后臺(tái)計(jì)算存儲(chǔ)引擎的對(duì)接支持，及變量、函數(shù)等自定義與管理、資源管控、多租戶、智能診斷等計(jì)算治理特性。

好處：

以微眾銀行與 Linkis 同時(shí)開(kāi)源的，交互式數(shù)據(jù)開(kāi)發(fā)探索工具 Scriptis 為例，Scriptis 的開(kāi)發(fā)人員只需關(guān)注 Web UI、多種數(shù)據(jù)開(kāi)發(fā)語(yǔ)言支持、腳本編輯功能等純前端功能實(shí)現(xiàn)，Linkis 包辦了其從存儲(chǔ)讀寫(xiě)、計(jì)算任務(wù)提交執(zhí)行、作業(yè)狀態(tài)日志更新、資源管控等等幾乎所有后臺(tái)功能?；?Linkis 的大量計(jì)算治理層能力的復(fù)用，大大降低了 Scriptis 項(xiàng)目的開(kāi)發(fā)成本，使得 Scritpis 目前只需要有限的前端人員，即可完成維護(hù)和版本迭代工作。

如下圖，Scriptis 項(xiàng)目 99.5% 的代碼，都是前端的 JS、CSS 代碼。后臺(tái)基本完全復(fù)用 Linkis。

4. 快速擴(kuò)展：對(duì)于底層引擎，Linkis 如何以很小的開(kāi)發(fā)量，實(shí)現(xiàn)新底層引擎快速對(duì)接

模塊化可插拔的計(jì)算引擎接入設(shè)計(jì)，新引擎接入簡(jiǎn)單快速

對(duì)于典型交互式模式計(jì)算引擎(提交任務(wù)，執(zhí)行，返回結(jié)果)，用戶只需要 buildApplication 和 executeLine 這 2 個(gè)方法，沒(méi)錯(cuò)，2 個(gè)方法，2 個(gè)方法，就可以完成一個(gè)新的計(jì)算引擎接入 Linkis，代碼量極少。示例如下。

(1). AppManager 部分：用戶必須實(shí)現(xiàn)的接口是 ApplicationBuilder，用來(lái)封裝新引擎連接器實(shí)例啟動(dòng)命令。

  
 
 
 

   
  
  
  
// 用戶必須實(shí)現(xiàn)的方法: 用于封裝新引擎連接器實(shí)例啟動(dòng)命令defbuildApplication(protocol:Protocol):ApplicationRequest 
  
 
 
 

(2). EngineConn 部分：用戶只需實(shí)現(xiàn) executeLine 方法，向新引擎提交執(zhí)行計(jì)算任務(wù)：

  
 
 
 

   
  
  
  
// 用戶必須實(shí)現(xiàn)的方法：用于調(diào)用底層引擎提交執(zhí)行計(jì)算任務(wù)defexecuteLine(context:EngineConnContext,code:String):ExecuteResponse
  
 
 
 

引擎相關(guān)其他功能 / 方法都已有默認(rèn)實(shí)現(xiàn)，無(wú)定制化需求可直接復(fù)用。

5. 連通，Linkis 如何打通應(yīng)用孤島

通過(guò) Linkis 提供的上下文服務(wù)，和存儲(chǔ)、物料庫(kù)服務(wù)，接入的多個(gè)上層應(yīng)用之間，可輕松實(shí)現(xiàn)環(huán)境變量、函數(shù)、程序包、數(shù)據(jù)文件等，相關(guān)信息和資源的共享和復(fù)用，打通應(yīng)用孤島。

Context Service 上下文服務(wù)介紹

Context Service(CS)為不同上層應(yīng)用系統(tǒng)，不同計(jì)算任務(wù)，提供了統(tǒng)一的上下文管理服務(wù)，可實(shí)現(xiàn)上下文的自定義和共享。在 Linkis 中，CS 需要管理的上下文內(nèi)容，可分為元數(shù)據(jù)上下文、數(shù)據(jù)上下文和資源上下文 3 部分。

元數(shù)據(jù)上下文，定義了計(jì)算任務(wù)中底層引擎元數(shù)據(jù)的訪問(wèn)和使用規(guī)范，主要功能如下：

• 提供用戶的所有元數(shù)據(jù)信息讀寫(xiě)接口(包括 Hive 表元數(shù)據(jù)、線上庫(kù)表元數(shù)據(jù)、其他 NOSQL 如 HBase、Kafka 等元數(shù)據(jù));
• 計(jì)算任務(wù)內(nèi)所需元數(shù)據(jù)的注冊(cè)、緩存和管理。
• 數(shù)據(jù)上下文，定義了計(jì)算任務(wù)中數(shù)據(jù)文件的訪問(wèn)和使用規(guī)范。管理數(shù)據(jù)文件的元數(shù)據(jù)。
• 運(yùn)行時(shí)上下文，管理各種用戶自定義的變量、函數(shù)、代碼段、程序包等。
• 同時(shí) Linkis 也提供了統(tǒng)一的物料管理和存儲(chǔ)服務(wù)，上層應(yīng)用可根據(jù)需要對(duì)接，從而可實(shí)現(xiàn)腳本文件、程序包、數(shù)據(jù)文件等存儲(chǔ)層的打通。

三、基于計(jì)算中間件 Linkis 的計(jì)算治理 - 理之路(Insight)

Linkis 計(jì)算治理細(xì)化特性設(shè)計(jì)與實(shí)現(xiàn)介紹，在高并發(fā)、高可用、多租戶隔離、資源管控、計(jì)算任務(wù)管理策略等方面，做了大量細(xì)化考量和實(shí)現(xiàn)，保障計(jì)算任務(wù)在復(fù)雜條件下成功執(zhí)行。

1. 計(jì)算任務(wù)的高并發(fā)支持

Linkis 的 Job 基于多級(jí)異步設(shè)計(jì)模式，服務(wù)間通過(guò)高效的 RPC 和消息隊(duì)列模式進(jìn)行快速通信，并可以通過(guò)給 Job 打上創(chuàng)建者、用戶等多種類(lèi)型的標(biāo)簽進(jìn)行任務(wù)的轉(zhuǎn)發(fā)和隔離來(lái)提高 Job 的并發(fā)能力。通過(guò) Linkis 可以做到 1 個(gè)入口服務(wù)(Entrance)同時(shí)承接超 1 萬(wàn) + 在線的 Job 請(qǐng)求。

多級(jí)異步的設(shè)計(jì)架構(gòu)圖如下：

如上圖所示 Job 從 GateWay 到 Entrance 后，Job 從生成到執(zhí)行，到信息推送經(jīng)歷了多個(gè)線程池，每個(gè)環(huán)節(jié)都通過(guò)異步的設(shè)計(jì)模式，每一個(gè)線程池中的線程都采用運(yùn)行一次即結(jié)束的方式，降低線程開(kāi)銷(xiāo)。整個(gè) Job 從請(qǐng)求—執(zhí)行—到信息推送全都異步完成，顯著的提高了 Job 的并發(fā)能力。

這里針對(duì)計(jì)算任務(wù)最關(guān)鍵的一環(huán) Job 調(diào)度層進(jìn)行說(shuō)明，海量用戶成千上萬(wàn)的并發(fā)任務(wù)的壓力，在 Job 調(diào)度層中是如何進(jìn)行實(shí)現(xiàn)的呢?

在請(qǐng)求接收層，請(qǐng)求接收隊(duì)列中，會(huì)緩存前端用戶提交過(guò)來(lái)的成千上萬(wàn)計(jì)算任務(wù)，并按系統(tǒng) / 用戶層級(jí)劃分的調(diào)度組，分發(fā)到下游 Job 調(diào)度池中的各個(gè)調(diào)度隊(duì)列;到 Job 調(diào)度層，多個(gè)調(diào)度組對(duì)應(yīng)的調(diào)度器，會(huì)同時(shí)消費(fèi)對(duì)應(yīng)的調(diào)度隊(duì)列，獲取 Job 并提交給 Job 執(zhí)行池進(jìn)行執(zhí)行。過(guò)程中大量使用了多線程、多級(jí)異步調(diào)度執(zhí)行等技術(shù)。示意如下圖：

2. 其他細(xì)化特性

Linkis 還在高可用、多租戶隔離、資源管控、計(jì)算任務(wù)管理策略等方面，做了很多細(xì)化考量和實(shí)現(xiàn)。篇幅有限，在這里不再詳述每個(gè)細(xì)化特性的實(shí)現(xiàn)，可參見(jiàn) Github 上 Linkis 的 Wiki。后繼我們會(huì)針對(duì) Linkis 的計(jì)算治理 - 理之路(Insight)的細(xì)化特性相關(guān)內(nèi)容，再做專(zhuān)題介紹。

文章名稱(chēng)：復(fù)雜分布式架構(gòu)下的計(jì)算治理之路
網(wǎng)頁(yè)URL：http://m.fisionsoft.com.cn/article/cojdodj.html