Linkis的入门-----很仔细的介绍给各位入门的小伙伴

本文链接：https://blog.youkuaiyun.com/zwhj12345/article/details/121796711

Linkis1.0的详解

第一章：Linkis介绍
一、Linkis简介：
Linkis是微众银行开源的一款数据中间件，用于解决前台各种工具，应用，和后台各种计算存储引擎的连接，访问和复用问题。
Linkis，一个打通了多个计算存储引擎如Spark、TiSpark、Hive、Python和HBase等，对外提供统一REST/WebSocket/JDBC接口，提交执行SQL、Pyspark、HiveQL、Scala等脚本的数据中间件。
Linkis基于微服务架构，提供了金融级多租户隔离、资源管控、权限隔离等企业级特性，支持统一变量、UDF、函数、用户资源文件管理，具备高并发、高性能、高可用的大数据作业/请求全生命周期管理能力。（Linkis介绍文档 - Wiki - Gitee.com）

二、Linkis设计目标：
如何提供统一的数据中间件，对接上层应用工具，屏蔽掉底层的各种调用和使用细节，真正做到让业务用户只需关注业务实现，就算底层平台机房扩建、整体搬迁都不受影响，是Linkis的设计初衷！

三、Linkis技术架构：
Linkis基于SpringCloud微服务技术，新建了多个微服务集群，来打造Linkis的中间件能力。
每个微服务集群都承担系统的一部分功能职责，我们对其进行了如下明确的划分。如：

统一作业执行服务：
一个分布式的REST/WebSocket服务，用于接收上层系统提交的各种访问请求。
目前支持的计算引擎有：
Spark、Python、TiSpark、Hive和Shell等。
支持的脚本语言有：
SparkSQL、Spark Scala、Pyspark、R、Python、HQL和Shell等；
资源管理服务：
支持实时管控每个系统和用户的资源使用情况，限制系统和用户的资源使用量和并发数，并提供实时的资源动态图表，方便查看和管理系统和用户的资源；
目前已支持的资源类型：
Yarn队列资源、服务器（CPU和内存）、用户并发个数等。
统一存储服务：
通用的IO架构，能快速对接各种存储系统，提供统一调用入口，支持所有常用格式数据，集成度高，简单易用；
统一上下文服务：
统一用户和系统的资源文件（用户脚本、JAR、ZIP、Properties等），用户、系统、计算引擎的参数和变量统一管理，一处设置，处处自动引用；
物料库服务：
系统和用户级物料管理，可分享和流转，支持全生命周期自动管理；
元数据服务：
实时的Hive库表结构和分区情况展示。

依赖这些微服务集群的相互协作，我们改善了整个大数据平台对外服务的方式和流程。
Linkis介绍文档 - Wiki - Gitee.com

四、Linkis业务架构：

Gateway网关:
基于Spring Cloud Gateway进行了插件化功能增强，新增了前端Client与后台多WebSocket微服务1多N支持(详细架构实现，主要用于解析和路由转发用户的请求到指定微服务。
统一入口:
统一入口是用户某一类引擎作业的Job生命周期管理者。
从接收作业、作业提交给执行引擎、到作业执行信息反馈给用户，再到作业完成，Entrance管理了一个作业的全生命周期。
引擎管理器:
引擎管理器负责管理引擎的全生命周期。
负责向资源管理服务申请和锁定资源，并实例化新的引擎，也负责监控引擎的生命状态。
执行引擎:
执行引擎是真正执行用户作业的微服务，它由引擎管理器启动。
为了提升交互性能，执行引擎直接跟统一入口进行交互，实时推送执行的日志、进度、状态和结果集给统一入口。
资源管理服务
实时管控每个系统和每个用户的资源使用情况，管理引擎管理器的资源使用和实际负载，限制系统和用户的资源使用量和并发数。
Eureka
Eureka是Netflix开发的服务发现框架，SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。
每个微服务都内置了Eureka Client，可以访问Eureka Server，实时获得服务发现的能力。

五、Linkis流程处理：
1，上层系统提交一个SQl，先经过Gateway，Gateway负责解析用户请求，并路由转发给合适的统一入口Entrance。
2，Entrance会先寻找该系统的该用户是否存在可用的Spark引擎服务，如果存在，则直接将请求提交给Spark引擎服务。
3，不存在可用Spark引擎服务，开始通过Eureka的服务注册发现功能，拿到所有的引擎管理器列表，通过请求RM实时获取引擎管理器的实际负载。
4，Entrance拿到负载最低的引擎管理器，开始要求引擎管理器启动一个Spark引擎服务。
5，引擎管理器接收到请求，开始询问RM该系统下的该用户，是否可以启动新引擎。
6，如果可以启动，则开始请求资源并锁定；否则返回启动失败的异常给到Entrance。
7，锁定资源成功，开始启动新的spark引擎服务；启动成功后，将新Spark新引擎返回给Entrance。
8，Entrance拿到新引擎后，开始向新引擎请求执行SQL。
9，Spark新引擎接收SQL请求，开始向Yarn提交执行SQL，并实时推送日志、进度和状态给Entrance。
10，Entrance将获取的日志、进度和状态实时推送给Gateway。
11，Gateway回推日志、进度和状态给前端。
12，一旦SQL执行成功，Engine主动将结果集推给Entrance，Entrance通知前端拿取结果。
高实时性，高并发，用户隔离度，调度时效性，参考文档：Linkis介绍文档 - Wiki - Gitee.com

第二章，Linkis0.x版本和Linkis1.0版本

一、Linkis0.x和Linkis1.0版本：
Linkis1.0版本和Linkis0.x版本相差巨大，0.x的每个微服务都是独立存在的一个根目录，这种目录结构带来的好处就是易于区分微服务，便于单个微服务进行管理，但也存在一些明显的问题：
1，微服务目录过于复杂，切换目录管理不够方便。
2，没有统一的启动脚本，导致微服务启停比较麻烦。
3，存在大量重复的服务配置，同一配置经常需要修改多处。
4，存在大量重复的Lib依赖，增大了安装包的体积和依赖冲突的风险
因此Linkis1.0中，我们对安装目录结构做了极大程度的优化和调整，减少微服务目录的数量，降低了重复依赖的jar包，尽可能复用了配置文件和微服务管理脚本，主要体现以下几个方面：
1，不再为每个微服务提个bin文件夹，修改为所有服务共用
Bin文件夹修改为安装目录，主要用于安装Linkis1.0和检查环境状态，新增的sbin目录为Linkis提供意见启停，依靠变革参数的方式为所有的微服务提供单独的启停。
2，不再为每个微服务提供单独的conf目录，修改为所有微服务共用，conf文件夹中包括两方面的内容：一方面是所有微服务共用的配置信息，这类配置信息里面包含了用户根据自身环境自定义的信息，另一方面是各个微服务的各自的特殊配置，一般情况下用户不需要自行修改。
3，不再为每个微服务提供lib文件夹，修改为所有微服务共用
Lib文件夹中同样包含两方面内容，一方面是所有微服务都需要的公共依赖，另一方面是各自微服务都各系需要的特殊依赖
4，不再为每个微服务提供log目录，修改为所有微服务共用
Log目录中包含了所有微服务的日志文件。

二，Linkis1.0安装目录结构：
Linkis1.0简化后的目录结构如下，其中淡蓝色标注的为用户使用是必定会使用的目录项和其他目录项初次使用无特殊情况无需关心：