Linkis1.0 与 Linkis0.X 的区别简述

简化用户实现新引擎，EnginePlugin用于将原本实现一个新引擎，需要实现的相关接口和类，以及需要拆分的Entrance-EngineManager-Engine三层模块体系，融合到了一个接口之中，简化用户实现新引擎的流程和代码，真正做到只要实现一个类，就能接入一个新引擎。
全栈计算存储引擎支持，实现对计算请求场景（如Spark）、存储请求场景（如HBase）和常驻集群型服务（如SparkStreaming）的全面覆盖支持。
高级计算策略能力改进，新增Orchestrator实现丰富计算任务管理策略，且支持基于标签的解析和编排。

计算治理的另一大变化是，LinkisManager作为 Linkis 的管理大脑，抽象和定义了 AppManager（应用管理）、ResourceManager（资源管理）和LabelManager（标签管理）；
微服务治理服务，将0.X部分的Eureka和Gateway服务进行了归并统一，并对Gateway服务进行了功能增强，支持按照Label进行路由转发；

a) EngineConn 为连接器，包含引擎与具体集群的会话信息。它只是起到一个连接，一个客户端的作用，并不真正的去执行计算。

b) Executor 为执行器，作为真正的计算场景执行器，是实际的计算逻辑执行单元，也对引擎各种具体能力的抽象，例如提供加锁、访问状态、获取日志等多种不同的服务。

c) Executor 通过 EngineConn 中的会话信息进行创建，一个引擎类型可以支持多种不同种类的计算任务，每种对应一个 Executor 的实现，计算任务将被提交到对应的 Executor 进行执行。这样，同一个引擎能够根据不同的计算场景提供不同的服务。比如常驻式引擎启动后不需要加锁，一次性引擎启动后不需要支持 Receiver 和访问状态等。

d) 采用 Executor 和 EngineConn 分离的方式的好处是，可以避免 Receiver 耦合业务逻辑，本身只保留 RPC 通信功能。将服务分散在多个 Executor 模块中，并且抽象成几大类引擎：交互式计算引擎、流式引擎、一次性引擎等等可能用到的，构建成统一的引擎框架，便于后期的扩充。这样不同类型引擎可以根据需要分别加载其中需要的能力，大大减少引擎实现的冗余。