Vesoft 7-9月日常实习小结

前言

2025年6月底，伴随着期末考试和得知四月的华为排序挂，正式决定开始找27日常实习。伴随期末考试以及同伴的压力，同时还在准备申请OSPP，长时间的处于焦虑的状态。八股八股没怎么背，算法算法也没怎么刷，匆匆忙忙开始投递面试。

由于准备很不充分，在先后小红书二面挂、字节一面挂、Minimax一面挂后，幸运的通过了 Vesoft 杭州悦数科技 Cloud 团队 Golang开发实习生的三轮面试（两轮技术面 + 一轮交叉面）

7月中正式开始了我的第一段实习，实习时长两个月左右

工作

工作强度其实并不大，挺 wlb，实习生一般975，平时要做什么一般是 mentor 安排的或者跟进需求，也有一些是组内的群里面收到 bug 反馈，自己主动处理的。每周会有周会，且通过个人周报来同步大家的进度。

生产工具

• Macbook Air 13’ M3 8G + 16G
• 27’ 4K 显示器
• Ubuntu 虚拟机 16G + 256G

技术栈

• Go 1.23 & 1.24
• go-zero
• KubeBuilder
• MySQL
• Docker
• K8s（AWS、Azure）

工作内容

公司的主要产品基于自研的开源图数据库 NebulaGraph 做商业版本的悦数图数据库，Cloud 团队这边的主要工作是应对各种云上的需求，主要包括 Cloud 平台 后端开发，以及控制面、数据面的 K8s 集群的维护、还有一些图计算的需求。

实习期间我主要负责 Cloud平台后端和数据面 K8s 集群开发会多一些

Cloud 后端组织权限管理

需求 & 背景

• 平台需要支持多个**组织（Organization）、项目（Project）**维度划分，用户在云端使用时要隔离租户资源
• 平台角色（如：Admin、SchemaDesigner 等）要能够映射到底层 NebulaGraph 内核的角色（如 db_root / db_reader / db_writer）
• 在控制面与数据面之间，要实现权限的端到端传递和校验（即：某操作被允许的前提是租户 / 平台权限同时满足）

技术方案与实现

• 所有资源都实现统一的 (org_id, project_id, resource_type, resource_id) 四元组模型；并用“路径式”匹配策略（类似 org//project//instance/*）让权限策略可级联匹配。
• 原 Casbin 是三元模型 (sub, obj, act)，我扩展成 (sub, obj, act, domain)，通过 domain 区分不同组织 / 项目域，使权限隔离逻辑更清晰；

• 平台角色需要同步到底层数据库角色，但权限同步不是一次性的，通过事件驱动同步机制
  • 平台权限变更会发送事件（PermissionChangedEvent），由异步 Worker 消费，事件 ID 保证幂等；
  • Worker 调用数据库内核 API（或 CLI）执行对应授权操作；
  • 执行结果写入审计日志与任务状态表；
• 在新实例或租户创建时，支持平台初始化脚本能力：创建默认的角色、账号、权限模板，并自动完成权限分配
• 通过结构化装饰器中间件包装表达权限要求，权限声明和业务逻辑分离，提高可扩展性

RegisterHandler(DeleteInstanceHandler,
    WithPermission("instance", "delete"),
    WithMethod("DELETE"),
    WithPath("/api/instance/delete"),
)

产出成果

• 目前平台支持灵活的租户 / 项目划分与权限控制
• 权限同步机制覆盖了大多数常用操作（如访问数据库、DDL／DML 操作、图计算、导入导出接口等）
• 在接口性能上，由于权限中间件较轻（仅索引 + Casbin lookup），整体系统开销可控
• 已为后续扩展（如配额控制、多租户网络隔离、资源超额保护）预留了角色 / 注解扩展点

Cloud 数据面备份恢复

需求 & 背景

• 在裸机或虚拟机环境中，NebulaGraph 已具备通过 nebula-br 工具完成备份与恢复的能力（支持全量与增量备份），但云原生环境下（Kubernetes 场景）存在若干适配问题。
• nebula-br 工具由 br（控制端）、agent（执行端）、nebula（数据库服务端） 组成，其中 agent 负责与 nebula 实例交互、执行数据上传下载与服务管理操作。
• 然而，在 K8s 环境下：
  • 容器为单进程模型，直接通过脚本或 SIGTERM 控制 Nebula 服务会导致 Pod 异常退出；
  • 云厂商的块存储（EBS / 云盘）普遍仅支持 ReadWriteOnce (RWO) 模式，不支持多 Pod 共享写；
  • 缺少统一的控制器来自动化协调 备份 / 恢复流程；
  • sidecar（agent 容器）升级往往会导致整个 Pod 重建，无法满足数据库对高可用性的要求。

因此，需要在 K8s 平台上重构 nebula-br 的架构设计，将其与 nebula-operator 深度集成，实现云原生下的备份与恢复能力。

总体设计

核心目标是：

在 Kubernetes 环境中，通过 CRD（自定义资源）与控制器自动协调备份与恢复流程，使用户能够以声明式的方式完成集群级别的备份与恢复。

主要设计包括：

1. 控制器层（Controller）
   • 将 br 的参数抽象为 Kubernetes CRD 资源，分别定义 Backup 与 Restore 两类对象；
   • Operator 监听 CR 事件，按状态机方式调度备份或恢复子流程；
   • 通过更新 CR 的 .status 字段反映各阶段执行状态，支持重试与回滚机制。
2. Agent 容器化
   • agent 以 sidecar 形式运行在每个 Nebula Pod 中，负责具体的数据上传、下载与服务状态检查；
3. 存储共享机制
   • 在 Pod 内部通过共享 PVC 卷（/data、/logs 等目录）实现 agent 与 nebula 数据目录互通；
   • 不同实例通过独立 PVC 实现数据隔离；
   • 避免 DaemonSet 方式因 RWX 限制导致的卷冲突。

流程设计

• 备份

• 恢复

产出成果

• 成功完成 nebula-br 在 K8s 下的云原生化设计 PoC
• 支持声明式的备份与恢复操作，自动协调多节点并行执行
• 为未来在多云（AWS / Azure）环境上部署的 Nebula Cloud 平台备份恢复功能奠定了架构基础

针对 sidecar agent 后期可以考虑做独立注入和升级，有了解到 openkruise 有在解决这个问题，但没有来得及仔细研究

其他

还有一些平台的小修小补，处理各种前端反馈的 Bug

由于基建还不是特别完善，测试环境还是需要手动部署测试并自己做隔离

新版发布前编写 NebulaGraph 升级脚本 Job，协助按时发版上线等

比较值得提的是 Landing 的大部分时间在学习 K8s二次开发的知识同时深入了解** DBaas 等服务架构设计，包括但不限于多云系统、多租户隔离、资源调度、成本控制、平台服务等，后面也会整理一篇博文，**在知识体系上有很大的帮助。

工作总结

这段时间的工作虽然并没有做很多的需求，但还算充实的，也学到了不少东西；工作之余也在持续的学习，总体上成长了不少。

生活

虽然还是很规律，但总体上还是处于一个焦虑的心情，有时候会暴饮暴食来缓解，所有 tmd 长更胖了

住房

公司在余杭 EFC 这边的 AUX 大厦，这边的租房并不算贵（相比于北上广），在里公司一公里内租了一个单间（隔断房），环境还是非常干净，一级能耗空调，房租是 1750 元/月，商用水电（每天晚上开一夜空调，一个月总共 150 左右）

饮食

由于公司不提供食堂，早上九点左右会提供早餐，午晚餐则一般点外卖或者在 EFC 周边吃，平均一天吃饭会花费五十左右

通勤

由于住的比较近，每天骑共享单车上下班，从出租屋出发到工位 15 分钟左右吧

娱乐

平时娱乐倒不是很多，和 HR 姐姐还有公司部分人有时候工作日晚会去公司万达对面打羽毛球，周末会和 mt 去杭师大打篮球，总的来说还是很快乐的

在杭州待了两个月也没去什么地方，地铁都没做过几次，就去过一次西湖，这是太多人了

人际

在公司大家都比较友好，平时大家的比较忙，自己忙自己的事情会比较多，吃饭时间会热闹些。和 mt 的沟通相处时间会更多一些

收获与展望

技术层面：

• 深入实践 Golang 工程化开发，掌握了以 go-zero 为核心的服务开发流程，对服务治理、模块拆分、依赖注入等工程化实践有了更深入的理解
• 进一步提升了 K8s 的使用与理解，不仅熟悉了容器化部署流程，也对其 开源生态体系 有了系统性的认识，如 Operator 开发、Scheduler 扩展机制等。这些学习过程促使我不断夯实底层计算机基础，包括存储、网络和系统调度等核心知识

工作认知：

• 深刻体会到 互联网企业敏捷开发的节奏与价值导向，学会在有限时间内快速理解业务需求、拆解任务并高效交付
• 在 AI 时代资源上云的趋势 下，意识到云基础设施的重要性，开始关注资源调度、动态扩缩容、自动化运维等底层机制
• 在跨团队协作中，体会到 清晰、结构化的技术方案文档 对沟通效率与项目推进的重要作用

个人思考：

• 对 Bug 的排查思路：注重问题复现和分层定位（二分思想），借助日志、指标、链路追踪快速确定问题根因
• 对开发的理解：技术方案阶段应尽可能深度调研，尽量暴露潜在问题，避免把风险留到编码阶段
• 对学习新技术栈：以官方文档为核心，结合示例与 AI 辅助快速构建数据与逻辑链路，再通过小规模实践验证

未来规划：

• 继续深入学习 云原生领域 的关键技术，包括 Kubernetes 调度策略、资源配额管理、网络配置与控制器设计等，并尝试积极参与相关开源社区的贡献。
• 系统学习 分布式系统设计，提升在高并发、高可用系统架构方面的能力。
• 关注 AI 与云计算的结合方向，持续学习 AI 相关的开发框架与服务化部署技术。
• 不断提升 技术文档与方案设计能力，让自己的思考与实践更具结构化与可复用价值。

同时在这两个月实习过程中，也充斥着对未来的焦虑，也让我更加意识到急于求成往往会适得其反，知道自己想要什么，要学什么，实习的目的更多在于沉淀出一套自己可复用的方法论，在未来遇到相似的场景是否能快速给出比较正确的方向或者能快速在新的场景中从过去的实践中获取不一样的灵感，而不是仅仅按照需求走一步算一步。定期复盘与深度思考是我接下来要坚持的习惯。

最后也很感激我 mt 鼓励我的一句话，在这里送给屏幕前的你：

太专注于未来，却没有意识到，今天正是多年前祈求的模样

感谢这里作为我梦开始的地方，加油吧！