引子

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

[[311888]]

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

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

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

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

 

 

2. 什么是計算治理?

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

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

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

 

 

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

 

 

3. 計算治理問題描述

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

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

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

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

 

 

這種狀態(tài)會帶來如下問題：

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

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

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

 

 

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

擴展難問題，上層應(yīng)用新增對接底層計算引擎，維護成本高，改動大。

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

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

 

 

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

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

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

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

 

 

(2)計算治理之理(insight)- 細化特性問題：

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

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

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

核心功能模塊與流程

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

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

 

 

 

 

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

 

 

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

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

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

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

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

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

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

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

4. 申請到資源，要求 EngineConnManager 依照資源啟動新 EngineConn

5.EngineConnManager 啟動新 EngineConn，并主動回推新 EngineConn 信息。

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

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

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

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

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

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

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

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

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

 

 

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

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

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

 

 

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

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

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

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

 

 

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

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

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

 

 

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

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

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

 

 

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

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

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

 

 

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

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

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

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

好處：

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

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

 

 

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

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

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

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

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

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

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

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

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

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

 

 

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

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

 

 

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

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

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

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

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

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

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

 

 

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

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

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

 

 

2. 其他細化特性

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