一：技术选型之路

Posted 2023-04-18 字节跳动数据平台

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

Notebook 是一种支持 REPL 模式的开发环境。所谓「REPL」，即「读取-求值-输出」循环：输入一段代码，立刻得到相应的结果，并继续等待下一次输入。Notebook 通常使得探索性的开发和调试更加便捷，在 Notebook 环境，用户可以交互式地在其中编写代码、运行代码、查看输出、可视化数据并查看结果，使用起来非常灵活。

在数据开发领域，Notebook 广泛应用于数据清理和转换、数值模拟、统计建模、数据可视化、构建和训练机器学习模型等方面。

但是显然，做数据开发，只有 Notebook 是不够的。目前火山引擎 DataLeap 数据研发平台提供了任务开发、发布调度、监控运维等一系列能力。研发团队将 Notebook 作为一种任务类型，加入了火山引擎 DataLeap 数据研发平台，使用户既能拥有 Notebook 交互式的开发体验，又能享受一站式大数据研发治理套件提供的便利。

 

如果还不够直观的话，试想以下场景：

 

在交互式运行和可视化图表的加持下，用户很快就调试完成了一份 Notebook。简单整理了下代码，根据使用到的数据配置了上游任务依赖，上线了周期调度，并顺手挂了报警。之后，基本上就不用管这个任务了：不需要每天手动检查上游数据是否就绪；不需要每天来点击运行，因为调度系统会自动帮用户执行这个 Notebook；执行失败了有报警，可以直接上平台来处理；上游数据出错了，可以请系统发起深度回溯，统一修数。

 

2019 年末，基于业务需求决定支持 Notebook 任务的时候，火山引擎 DataLeap 研发团队调研了许多 Notebook 的实现，包括 Jupyter、Polynote、Zeppelin、Deepnote 等。Jupyter Notebook 是 Notebook 的传统实现，它有着极其丰富的生态以及庞大的用户群体，相信许多人都用过这个软件。

 

事实上，在字节跳动数据平台发展早期，就有了在物理机集群上统一部署的 Jupyter（基于多用户方案 JupyterHub），供内部的用户使用。考虑到用户习惯和其强大的生态，Jupyter 最终成为了火山引擎 DataLeap 研发团队的选择。

 

（图：Jupyter Notebook 界面）

 

Jupyter Notebook 是一个 Web 应用。通常认为其有两个核心的概念：Notebook 和 Kernel。

• Notebook 指的是代码文件，一般在文件系统中存储，后缀名为ipynb。Jupyter Notebook 后端提供了管理这些文件的能力，用户可以通过 Jupyter Notebook 的页面创建、打开、编辑、保存 Notebook。在 Notebook 中，用户以一个一个 Cell 的形式编写代码，并按 Cell 运行代码。Notebook 文件的具体内容格式，可参考 The Notebook file format（https://nbformat.readthedocs.io/en/latest/format_description.html）。

• Kernel 是 Notebook 中的代码实际的运行环境，它是一个独立的进程。每一次「运行」动作，产生的效果是单个 Cell 的代码被运行。具体来讲，「运行」就是把 Cell 内的代码片段，通过 Jupyter Notebook 后端以特定格式发送给 Kernel 进程，再从 Kernel 接受特定格式的返回，并反馈到页面上。这里所说的「特定格式」，可参考 Messaging in Jupyter（https://jupyter-client.readthedocs.io/en/stable/messaging.html）。

 

在火山引擎 DataLeap 数据研发平台，开发过程围绕的核心是任务。用户可以在项目下的任务开发目录创建子目录和任务，像 IDE 一样通过目录树管理其任务。Notebook 也是一种任务类型，用户可以启动一个独立的任务 Kernel 环境，像开发其他普通任务一样使用 Notebook。

 

（图：火山引擎 DataLeap 数据开发 Notebook 任务界面）

 

目前 Notebook 任务已成为字节跳动内部使用较为高频的任务类型，用户可以在火山引擎 DataLeap 官网开通交互式分析的版本，使用到 DataLeap 的 Notebook 任务。

 

点击跳转 火山引擎大数据研发治理DataLeap 了解更多

微服务技术选型之路

本文以笔者个人经历讲述关于微服务方面的技术选型和相关知识点。微服务模式的项目从初建到上线部署应用，每一个环节都会涉及到相当多的技术细节（上线后的性能调优更需要）。本文着重介绍一套微服务搭建流程中面临的一些技术选型，战略性的技术方案及相关技术的简要介绍，不做每一项技术的深入说明。

?微服务简介

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。

微服务是系统架构上的一种设计风格，主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP/HTTPS协议的RESTful API进行通信协作，也可以通过RPC协议进行通信协作。被拆分成的每一个小型服务都围绕着系统中一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储，业务开发，自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。

微服务的优点

• 每个微服务都很小，这样能够聚焦一个指定的业务功能或业务需求。
• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发，如Java、Python、PHP、C#等。
• 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Travis CI等工具。
• 一个团队的新成员能够更快投入生产。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务方便融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
• 微服务能够即时被要求扩展。
• 微服务能部署中低端配置的服务器上。
• 易于和第三方应用系统集成。
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。

?微服务技术选型

前几年较为火的微服务技术有阿里的Dubbo方案。后面又出现了Spring体系下的微服务方案。本文主要介绍Spring体系下的微服务技术选型方案。

构建一套微服务最基本的是需要搭建网关，注册中心，开发具体实现业务功能的服务。对于各个微服务之间的通信，可通过Feign方案处理。具体搭建一套微服务技术选型可参考如下方案：

不同的技术选择应用的场景不同：

• 网关：若整个公司业务都基于java开发，可以直接使用Spring Gateway做网关。若还存在其他的开发语言，也可选择kong网关模式。
• 注册中心：基于java开发，Spring体系下可直接用 Spring Eureka。若还存在其他语言编写的服务，可使用Consul。
• 微服务搭建：各自语言都可以搭建。若采用java开发，可参考Spring boot方案搭建微服务。
• 持续集成的方案，三种都可以。若基于java开发，第一种最为传统，运维人员或开发人员工作更多，需编写启动脚本，使用jdk命令启动java程序。建议使用第二种方案。第三种方案操作更为简便，但需用阿里云的产品。
• Spring Boot 项目构建：采用Spring Boot模式搭建微服务项目时，对于Maven项目pom.xml配置文件的使用需注意pom文件配置单项目模式和项目聚合模式的区别。对于网关，注册中心可采用单项目模式。但在搭建真正业务的服务时，建议采用父子级项目聚合的方式。笔者最初做微服务开发时，采用了单项目的模式，当开发了多个业务的微服务后，单项目模式在引用依赖项目版本，管理项目时极为不便。

微服务相关知识点

本文针对Spring体系下微服务常用的几个知识点做简要说明，具体细节，原理，如何应用可通过关键词搜索详细了解。

Spring Boot

Spring Boot是由 Pivotal团队提供的全新框架,其设计目的是用来简化新 Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的配置。

Spring Boot的核心思想就是约定大于配置,一切自动完成。采用 Spring Boot可以大大的简化开发模式,通过组件的模式集成常用的框架。

Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用 Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线线、负载均衠、断路器、数据监控等,都可以用 Spring Boot的开发风格做到一键启动和部署。 Spring并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组台起来,通过 Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系統开发工具包。

微服务是可以独立部署、水平扩展、独立访问(或者有独立的数据库)的服务单元, Spring Cloud就是这些微服务的大管家,采用了微服务这种架构之后,项目的数量会非常多, Spring Cloud做为大管家就需要提供各种方案来维护整个生态。

Spring Cloud就是一套分布式服务治理的框架,既然它是一套服务治理的框架,那么它本身不会提供具体功能性的操作,更专注于服务之间的通讯、熔断、监控等。因此就需要很多的组件来支持一套功能。

Spring Cloud的子项目，大致可分成两类，一类是对现有成熟框架”Spring Boot化”的封装和抽象，也是数量最多的项目；第二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。

?Spring Cloud Eureka

Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。而Spring Cloud Netflix项目是Spring Cloud的子项目之一，主要内容是对Netflix公司一系列开源产品的包装，它为Spring Boot应用提供了自配置的Netflix OSS整合。通过一些简单的注解，开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路由（Zuul），客户端负载均衡（Ribbon）等。

Spring Cloud Gateway

Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代Netflix ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

Spring Cloud Feign

Feign是一个伪客户端，即它不做任何的请求处理。Feign通过处理注解生成request，从而实现简化HTTP API开发的目的，即开发人员可以使用注解的方式定制request api模板，在发送http request请求之前，feign通过处理注解的方式替换掉request模板中的参数，这种实现方式显得更为直接、可理解。

Feign封装了Http调用流程，更适合面向接口化的编程习惯。在服务调用的场景中，我们经常调用基于Http协议的服务，而我们经常使用到的框架可能有HttpURLConnection、Apache HttpComponnets、OkHttp3 、Netty等等，这些框架在基于自身的专注点提供了自身特性。而从角色划分上来看，他们的职能是一致的提供Http调用服务。