zeppelin源码分析(4)——主要的class分析(下)

本文主要分析类图中右下角的部分，如果说类图中右上角部分决定了zeppelin运行时对解释器进程的处理，那么右下角这部分类是决定了Note运行方式。

Note

Note是单个’记事本’的内存对象，是zeppelin管理的最小单位，无论是做权限控制、共享、还是持久化，都是以Note为粒度的。从类关系上看，Note是由一些列的有序Paragraph组成，因此其绝大部分职责都是与管理Paragraph有关：
1. Paragraph的CRUD、相对顺序控制
2. 与处理前后端数据双向推送的AngularObject的管理
3. 整体和单个Paragraph 执行，以及执行过程的基于Observer模式的执行过程Hook
4. Note基本的样式外观控制
为了“分离关注点”，其他的功能，如：
1. Note相关的Interpreter加载和初始化
2. 持久化与反持久化，包括延迟持久化
3. 权限控制
都交给Note“依赖的服务”来解决，这些服务在运行时，会由“组合”Note的Notebook类来负责注入。这些依赖的注入顺序为：

Paragraph

Paragraph代表着一段代码以及支撑其执行所需要的“环境信息”，是代码执行的最小单位。Paragraph的职责如下：
1. 获取代码文本，并解析分离类似%spark的interpreter声明段和可执行代码段。
2. 代码执行，以及执行过程控制（进度和终止）
3. 代码执行结果获取
4. 代码中变量查找以及替换

Notebook

Notebook实际上是Note的Manager，职责如下：

1. Note的CRUD，克隆、导入/导出
2. Note和相关Interpreter配置时和运行时映射关系维护
3. Note cron式调度执行控制
   其他所有Note公共的服务，都交给ZeppelinServer类来注入，具体的有：

服务	说明
NotebookRepo	Note的持久化服务
SearchService	Note的全文检索服务
NotebookAuthorization	Note的Authorization服务
Credentials	数据源相关的“用户/密码”服务

NotebookServer

NotebookServer的主要功能是将Notebook、Note、Paragraph、Interpreter等类封装的能力，通过WebSocket的形式对web 客户端提供出去，所以其具体的职责包括：
1. 维护WebSocket连接与Note之间映射关系
2. 处理客户端和服务器之间的双向通信（通过WebSocket，具体的通信协议见：Message类），包括消息的序列化/反序列化，消息解析和服务端处理、处理结果的向客户端广播/单播发送等。
3. Note的CRUD操作以及Paragraph的CRUD操作、执行、导入、导出时的权限控制
4. 前后端AngularObject的双向bind处理
5. WebSocket客户端合法性校验(checkOrigin)

关于zeppelin采用WebSocket技术的必要性问题，这里也做一下简单分析。zeppelin是共享式、Notebook式的大数据分析环境，以repl的方式执行以Paragraph为最小粒度的代码段。
1. 首先repl的方式强调实时反馈执行结果，特别是在大数据环境下，一段代码可能需要执行很长时间，在执行的过程中，zeppelin的用户期望看到执行进度和中间结果，需要在前后端之间建立一个长连接，便于实时传递数据。
2. 另外zeppelin的另一个亮点是其结果可视化能力，需要在前后台传递图片，并且支持较大数据量的传输的能力（相对传统http技术）。
3. 再者，由于是共享式环境，一个Note可能被多个用户同时看到、甚至编辑，需要在各个已经打开了同一个Note的web客户端之间同步Note的代码、执行结果和进度信息。
基于以上3点，zeppelin采用WebSocket技术是水到渠成的事情。

ZeppelinServer

ZeppelinServer是各个组件的”组装者”，它是系统的主入口，职责如下：
1. 内嵌jetty服务器，支持以WebSocket和REST两种方式对外暴露系统功能
2. 创建NotebookServer实例，建立起处理WebSocket Connection和消息处理的服务端
3. 创建Notebook需要的相关依赖，如Note持久化服务(NotebookRepo)、Note的全文索引服务（SearchService），并完成向Note、Paragraph的注入。
4. Note权限配置文件的加载以及初始化
5. InterpreterFactory的初始化
6. 初始化动态依赖加载器(DependencyResolver)

NotebookRepo以及Note持久化子系统

Notebook的持久化子系统主要由NotebookRepo以及其子类组成。各类主要的职责如下：
1. NotebookRepo是顶层接口，规定了持久化层基本的CRUD接口。
2. NotebookVersioned定义了Note的版本管理接口，目前其实现类只有 GitNotebookRepo。GitNotebookRepo是以JGit库实现的基于本地文件系统的、支持以Note为粒度进行checkin和show log的Note仓库。
3. VFSNotebookRepo是zeppelin的默认实现类（配置参数zeppelin.notebook.storage控制，参见：ZeppelinConfiguration。

ZEPPELIN_NOTEBOOK_STORAGE("zeppelin.notebook.storage", VFSNotebookRepo.class.getName()),

使用apache common-vfs来实现多文件系统支持。
4. NotebookRepoSync的初衷是为了让2个NotebookRepo之间进行自动同步修改，实现：在本地repo保存修改的同时，让zeppelin自动将修改同步到远程的repo上。
要启用2个repo之间的同步，做如下修改：

1. 在zeppelin-site.xml中修改配置参数zeppelin.notebook.storage，以逗号分隔2个实现类的完整类名
2. 注意顺序，一般是将VFSNotebookRepo作为一个，而S3NotebookRepo或者是AzureNotebookRepo等作为第二个。zeppelin目前只支持最大2个Repo（maxRepoNum=2作为编译时常量），不能通过配置修改。

1. S3NotebookRepo和AzureNotebookRepo，实现向2大云存储系统的持久化Notebook。
2. ZeppelinHubRepo是为了向zeppelinhub持久化Notebook而设计的，zeppelinhub是一个类似于Github的分享网站，区别在于Github是分享git仓库的，zeppelinhub是分享note的。

SearchService以及Note的全文检索子系统

Note的全文检索子系统由SearchService接口和其子类组成，目前只有一个实现类LuceneSearch，采用基于内存的索引，在Notebook每次重新加载所有的Note、或者Note有更新、删除的时候会重新索引该Note，保证全文索引与持久化的Note文件一致性。

截止目前为止，zeppelin的所有重点的类我们就分析完了。通过分析单个类的职责和类之间的关系，我们清楚的了解了zeppelin如何将自己要解决的主要问题——支持多个语言repl的解释器——这个庞大的目标，一步步进行关注点拆分，并且合理的组合到各个类，乃至各个模块中，形成一个可实现的设计方案。