zeppelin源码分析(3)——主要的class分析(上)

zeppelin的module、package、class众多，如何快速地理清头绪，抓住重点？本文分析zeppelin主要module中重点的类以及它们之间的关系，理清这些类的职责，对于理解zeppelin的运行过程至关重要。
经过之前文章的分析，我们已经了解了zeppelin涉及到框架层面的几个module为：zeppelin-server、zeppelin-zengine、zeppelin-interpreter，并且三者之间有如下的依赖关系：

本文要分析的主要的class，也都来自于这三个module。

以上类图中省略了字段和方法，以避免过早引入太多细节，重点关注类与类之间的关系组成。由于篇幅的限制，再加上zeppelin提供的核心价值是与Interpreter相关的多语言repl解释器，笔者就选择从右上角黄色的区域开始，分多篇分析。

Interpreter

Interpreter是一个抽象类，该类是zeppelin核心类，Zeppelin提供的核心价值：解释执行各种语言的代码，都是通过该抽象类的每个具体的实现类完成的。Interpreter主要规定了各语言repl解释器需要遵循的“规范(contract)”，包括：
1. repl解释器的生命周期管理。如open(), close(), destroy(）,规定了产生和销毁repl解释器。
2. 解释执行代码的接口——interpreter()，这些真正产生价值的地方。
3. 执行代码过程中交互控制和易用性增强，如cancel(), getProgress(), completion()，分别是终止代码的执行、获取执行进度以及代码自动完成。
4. 解释器的配置接口，如setProperty()、setClassLoaderURL(URL[])等。
5. 性能优化接口，如getScheduler(),getIntepreterGroup()等。
6. 解释器注册接口（已经deprecated了），如一系列重载的register接口。
以上体现了zeppelin的repl解释器进程需要受其主进程ZeppelinServer的控制，也是zeppelin设计决策在代码中的体现。
注：现在的解释器注册通过如下2种方式进行:

1. 将interpreter-setting.json打包到解释器的jar文件中
2. 放置到如下位置：interpreter/{interpreter}/interpreter-setting.json

RemoteInterpreterService Thrift协议分析

Apache Thrift是跨语言RPC通信框架，提供了相应的DSL(Domain Specific Language)和支持多种语言的代码生成工具，使得代码开发人员可以只关注具体的业务，而不用关注底层的通信细节。zeppelin使用Thrift定义了其主进程ZeppelinServer与需要采用独立JVM进程运行的各repl解释器之间的通信协议。
关于为什么要采用单独的JVM进程来启动repl解释器进程，本系列的第3篇也有提及，这里再赘述一下：
1. zeppelin旨在提供一个开放的框架，支持多种语言和产品，由于每种语言和产品都是各自独立演进的，各自的运行时依赖也各不相同，甚至是相互冲突的，如果放在同一JVM中，仅解决冲突，维护各个产品之间的兼容性都是一项艰巨的任务，某些产品版本甚至是完全不能兼容的。
2. 大数