共计 2346 个字符，预计需要花费 6 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
当应用 Notebook 的我的项目日渐减少时，火山引擎 DataLeap 研发团队发现运行中的 PaaS 服务切实太多了，之前的架构有如下毛病：
1. 部署麻烦。全量降级 JupyterLab 较为苦楚。只管有降级脚本，然而通过 API 操作降级服务，可能因为镜像构建失败等起因，会造成卡单景象。
2.JupyterLab 须要一直的依据用户增长（我的项目增长）进行扩容，一旦事后启动好的资源池不够，就会存在新我的项目里有用户关上 Notebook，须要经验整个 JupyterLab 服务创立、环境拉起的流程，速度较慢，影响体验。
3. 运维艰难。当用户 JupyterLab 可能呈现问题，为了找到对应的 JupyterLab，咱们须要先依据我的项目对应到 JupyterHub user，而后依据 user 找到 JupyterHub 记录的服务 id，再去 PaaS 平台找服务，进 webshell。
4. 当然，还有资源的节约。尽管每个实例很小(1c1g)，然而数量很多；有些我的项目并不总是在应用 Notebook，但 JupyterLab 仍然运行。
5. 稳定性存在问题。一方面，JupyterHub 是一个单点，降级须要先起后停，挂了有危险。另一方面，EG 入流量通过特定负载平衡策略，自身是为了使 JupyterLab 固定往一个 EG 申请。在 EG 降级时，JupyterLab 申请的终端会随之扭转，极其状况下有可能造成 Kernel 启动屡次的状况。
基于简化运维老本、升高架构复杂性，以及进步用户体验的思考，2021 上半年，火山引擎 DataLeap 研发团队对整体架构进行了一次改进。在新的架构中，火山引擎 DataLeap 研发团队次要做了以下改良，大抵简化为下图：
1. 移除 JupyterHub，将 JupyterLab 改为多实例无状态常驻服务，并实现对接火山引擎 DataLeap 的多用户鉴权。
2. 革新本来落在 JupyterLab 本地的数据存储，包含用户自定义配置、Session 保护和代码文件读写。
3.EG 反对长久化 Kernel，将 Kernel 近程环境元信息长久化在远端存储 (MySQL) 上，使其重启时能够重连，且 JupyterLab 能够晓得某个 Kernel 须要通过哪个 EG 连贯。
（图：火山引擎 DataLeap 下改进版 Notebook 整体架构）
单用户的 Jupyter Notebook / JupyterLab 的鉴权绝对简略（实际上 JupyterLab 间接复用了 Jupyter Notebook 的这套代码）。例如，应用默认命令启动时，会主动生成一个 token，同时主动拉起浏览器。有了 token，就能够任意地拜访这个 Notebook。
事实上，JupyterHub 也是起到了保护 Token 的作用。前端会发动一个获取 Token 的 API 申请，再拿着获取的 Token 申请通过 JupyterHub proxy 到实在的 Notebook 实例。
（图：前: JupyterHub 提供的 auth 能力；后：实现了 auth 性能的 JupyterLab）
最初，因为所有用户会共享同一组 JupyterLab，火山引擎 DataLeap 研发团队还须要禁止一些接口的调用，以保证系统的平安。最典型的接口包含敞开服务(Shutdown)，以及批改配置等。后续 Notebook 所需的配置，转由前端保留在浏览器内。
Jupyter Notebook 应用 File Manager（https://github.com/jupyter-server/jupyter_server/blob/main/jupyter_server/services/contents/filemanager.py）治理 Contents 相干读写，原生行为是将代码存储在本地，多个服务实例之间无奈共享同一份代码，而且迁徙时可能造成代码失落。
为了防止代码失落，火山引擎 DataLeap 研发团队的做法是，把代码按我的项目别离存储在 OSS 上并间接读写，同时解决了一些因为代码文件元信息失落，并发编辑导致的其余问题。
（图：按我的项目别离长久化代码到 OSS）
Notebook 应用 Session 治理用户到 Kernel 的连贯，例如前端通过 POST /session 接口启动 Kernel，GET /session 查看以后运行中的 Kernel。在 Session 解决方面，原生的 Notebook 应用了原生的 sqlite(in memory)，见代码（https://github.com/jupyter-server/jupyter_server/blob/main/jupyter_server/services/sessions/sessionmanager.py）。
（图：Session 表）
Kernel Gateway 在启动 Kernel 时，记录了对于 Kernel 的一些元信息，包含启动参数、连贯 Kernel 应用的 IP/Port 等。有了这些信息，当一个 Kernel Gateway 重启且 Remote Kernel 不敞开，就有方法从新连贯上。本来这些信息默认在内存 dict 中保护，开源仓库中有一套存储在本地文件的计划；基于这套计划，火山引擎 DataLeap 研发团队扩大了自研的存储到 MySQL 的计划。
（图：EG 拜访流程示意图）
当 EG 服务自身重启或者降级时，会在过程退出之前去革除接管信息。当页面持续拜访时，JupyterLab 服务将会随机散发相应申请，由其它的 EG 服务持续接管。
架构降级简化后，整套火山引擎 DataLeap 下的 Notebook 服务的稳定性取得了极大的晋升。因为实现了用户无感知的降级，不仅晋升了用户的应用体验，运维的老本也同时升高了。
点击跳转 大数据研发治理 DataLeap 理解更多