面试项目 - eas

重点面试准备

  1. 这个项目的整体架构是什么？核心价值是什么？
  2. 项目中怎么用 K8s Informer 机制实现事件驱动？
  3. 各个控制器（Service/Vipserver/Cloud）之间怎么协同工作？
  4. Storage Cache 的高并发优化怎么做的？效果如何？
  5. LLM Gateway 支持哪几种调度模式？适用场景是什么？
  6. 集成阿里云资源（如 NLB/Nacos）时，遇到什么难点？怎么解决？
  7. 项目怎么保障高并发、高可用场景下的服务稳定性？
  8. 你在项目中独立负责的核心功能是什么？有什么贡献？
  9. 项目目前有什么不足？如果让你改进，怎么改？
  10. 如果要接入 GPT-4 这类新 AI 模型，需要做哪些适配工作？

项目模块功能整理

一、核心模块功能（基于代码仓库分析）

1. 核心控制器模块

  • Service Controller：管理 EAS 服务生命周期的 K8s 控制器
  • Vipserver Controller：管理注册在每个 EAS 服务中的 vipserver 端点的 K8s 控制器
  • 使用 Kubernetes Informer 机制实现事件驱动的控制器模式
  • 支持多种服务类型：传统服务、外部服务、无服务器服务等

2. 云服务相关模块

  • Cloud Controller：管理云资源的控制器，包含以下能力：
    • 私有链接资源管理
    • 服务域 DNS 记录管理
    • DNS 敲门服务管理
    • 负载均衡网关 Pod 管理
    • Redis 云资源管理
    • 网络负载均衡器集成
    • Nacos 服务发现集成
  • 支持阿里云服务集成（私有链接、DNS、NLB、Redis、Nacos 等）

3. AI / 机器学习相关模块

（1）LLM Gateway：大型语言模型网关服务

  • 支持多种调度模式（调度器模式、重调度模式、网关模式）
  • 实现负载均衡和请求处理
  • 支持多种调度策略（基于指标、前缀缓存、最少请求等）

（2）AIGC Gateway：AI 生成内容网关

  • 支持 SD API 和 ComfyUI API
  • 提供 AI 服务的统一入口

4. 网络和网关模块

（1）Gateway Controller：网关控制器

  • 基于 controller-runtime 框架实现
  • 集成多种云服务提供商（MSE、NLB、DNS 等）
  • 支持 Contour 网关供应器

（2）Proxy Server：代理服务器

  • 实现 TCP 连接代理
  • 支持 WebSocket 升级
  • 提供连接复用和监控功能

5. 存储和数据相关模块

（1）Storage Cache：存储缓存系统

  • 实现基于 LRU 的并发缓存机制
  • 支持分片机制减少锁竞争
  • 提供对象版本比较功能

（2）StateDB：状态数据库

  • 管理服务状态（OK、PREPARE、FAIL、EXIT）
  • 支持状态变更事件监听
  • 提供状态持久化功能

（3）Cache Server：缓存服务器

  • 实现 K8s 资源的缓存服务
  • 支持 REST API 接口
  • 提供认证和访问控制

（4）Database Integration：数据库集成

  • 支持 MySQL、SQLite 等关系型数据库
  • 集成 InfluxDB 时序数据库
  • 提供 ORM 封装和连接管理

（5）Storage Volumes：存储卷管理

  • 支持多种存储类型（OSS、NFS、云盘、Git 等）
  • 实现存储卷的挂载和配置管理
  • 支持加密和只读等存储选项

6. 监控和运维模块

  • Persist Controller：持久化控制器
    • 管理各种资源的缓存
    • 实现资源变更检测
    • 提供缓存管理功能
  • Supervisor：服务监控
    • 管理服务状态和生命周期
    • 提供状态报告和健康检查

7. 工具和辅助模块

  • EAS Init：系统初始化工具
    • 数据库初始化
    • 配置加载和执行
  • Command Line Tools：命令行工具
    • 提供各种组件的命令行接口
    • 支持 cobra 命令行框架

二、如何阅读这个代码仓库

  1. 从 README 开始：了解项目基本结构和编译方法
  2. 理解核心概念：熟悉 K8s 控制器模式和 EAS 服务架构
  3. 按模块分析：按照上述模块分类逐一分析相关文件
  4. 关注 cmd 目录：每个可执行程序的入口点
  5. 理解 pkg 结构：按功能划分的包结构
  6. 查看配置文件：了解系统的配置方式和参数

项目架构总结

该项目采用微服务架构，各个控制器组件职责分离，可独立部署。大量使用 Kubernetes 的 Informer 机制实现事件驱动的反应器模式，同时集成了多种云服务（如阿里云）和数据库技术。

豆包面试题准备

一、简历上的项目介绍（3 个版本，适配不同岗位）

简历介绍核心：突出技术栈、核心职责、量化成果，避免堆砌模块，聚焦与目标岗位匹配的亮点（如云原生岗侧重 K8s / 云资源，AI 岗侧重网关 / 调度）。

版本 1：通用云原生方向（适配后端 / 云原生工程师）

plaintext

1
2
3
4
5
6
7
8
9
项目名称：EAS云原生服务治理平台
项目周期：202X.XX-202X.XX
角色：核心开发工程师
核心职责：
1. 设计并实现基于K8s Informer机制的事件驱动控制器（Service/Vipserver），支撑传统服务、无服务器等多类型服务生命周期管理，服务部署成功率提升至99.9%；
2. 参与Cloud Controller开发，集成阿里云私有链接、NLB、Nacos等云资源，实现云资源与K8s服务的联动管理，降低运维成本40%；
3. 开发Gateway Controller与Contour网关供应器集成，实现TCP代理、WebSocket升级及连接复用，支撑日均100万+请求的稳定转发；
4. 设计基于LRU的分片并发缓存系统，解决高并发下锁竞争问题，缓存命中率提升至92%。
技术栈：Kubernetes、Golang、controller-runtime、Informer、阿里云SDK、Contour、Redis、MySQL

版本 2：AI 方向（适配 AI 工程化 / LLM 网关开发岗）

plaintext

1
2
3
4
5
6
7
8
9
项目名称：EAS云原生AI服务网关平台
项目周期：202X.XX-202X.XX
角色：AI网关模块负责人
核心职责：
1. 主导LLM Gateway设计与开发，支持调度器/重调度/网关3种模式，实现基于指标、前缀缓存、最少请求的负载均衡策略，LLM服务响应延迟降低25%；
2. 开发AIGC Gateway，集成SD API与ComfyUI API，提供AI生成内容服务统一入口，支撑10+AI团队的快速接入；
3. 对接Nacos服务发现与云资源（NLB/Redis），保障AI服务的高可用与弹性伸缩，服务可用性达99.95%；
4. 设计AI请求缓存机制与流量控制策略，解决突发流量下的服务过载问题，峰值QPS提升至5万+。
技术栈：Golang、Kubernetes、LLM调度、AIGC API、Nacos、负载均衡、缓存架构

版本 3：精简版（适配简历空间有限场景）

plaintext

1
2
3
4
5
项目名称：EAS云原生服务治理平台
项目周期：202X.XX-202X.XX
角色：后端开发工程师
核心职责：基于K8s构建多模块服务治理平台，负责控制器、云资源集成、AI网关等核心模块开发；实现事件驱动的服务生命周期管理，集成阿里云/AI服务/缓存系统，支撑高并发、高可用的企业级服务运行。
技术栈：Golang、Kubernetes、Informer、controller-runtime、阿里云（NLB/Nacos）、LLM Gateway、LRU缓存

二、面试重点准备（分模块 + 高频问题）

面试核心：不仅懂 “做了什么”，更懂 “为什么这么做”“怎么解决问题”“有什么优化空间”，结合项目细节拆解。

1. 项目整体架构理解（必问基础）

核心问题

  • 项目的整体架构是什么？为什么采用微服务 + K8s 控制器模式？
  • 各个控制器（Service/Vipserver/Cloud/Gateway）之间如何协同工作？
  • 项目的核心价值是什么？解决了业务中的什么痛点？

准备方向

  • 用 “组件 + 通信” 逻辑总结：K8s集群作为底座 → 各类控制器监听资源事件 → 云资源/AI网关/缓存等模块提供能力 → 统一服务入口对外提供服务；
  • 痛点对应：传统服务部署复杂→用控制器自动化管理；多类型服务（传统 / 云 / AI）接入混乱→用网关统一入口；云资源运维成本高→控制器联动管理。

2. 核心技术细节（技术深度考察）

（1）K8s 控制器相关（高频）

问题

  • 什么是 K8s Informer 机制？项目中如何使用 Informer 实现事件驱动？
  • Informer 的 Indexer、Reflector、Workqueue 分别起什么作用？如何避免重复事件处理？
  • controller-runtime 框架的核心组件有哪些？项目中是如何基于它开发控制器的？

准备方向

  • 原理简化说：Informer 是 “客户端缓存 + 事件通知” 工具，避免频繁调用 K8s API；项目中通过For(&corev1.Service{})监听资源，Reconcile方法处理事件；
  • 踩坑点补充（加分）：比如 Workqueue 设置延迟重试，解决资源未就绪时的处理失败问题；用 Indexer 建立资源索引，提升查询效率。

（2）缓存与存储模块

问题

  • 项目中的 Storage Cache 是如何实现 LRU 并发缓存的？分片机制怎么减少锁竞争？
  • StateDB 的状态设计（OK/PREPARE/FAIL/EXIT）是基于什么业务场景？如何实现状态持久化和事件监听？
  • Cache Server 的认证和访问控制是怎么实现的？支持哪些 REST API？

准备方向

  • LRU 实现：用 “双向链表 + 哈希表”，并发安全用sync.RWMutex；分片按 key 哈希分桶，每个桶独立锁，减少竞争；
  • 状态设计逻辑：PREPARE（初始化中）→OK（运行中）→FAIL（异常）→EXIT（销毁），对应服务生命周期；持久化用 MySQL/Redis，事件监听用观察者模式。

（3）网关与网络模块

问题

  • Proxy Server 如何实现 TCP 代理和 WebSocket 升级？连接复用是怎么做到的？
  • Gateway Controller 集成 Contour 网关的原理是什么？如何实现多云服务（MSE/NLB/DNS）集成？
  • 项目中的负载均衡策略（基于指标 / 最少请求 / 前缀缓存）是如何实现的？适用场景是什么？

准备方向

  • TCP 代理：用net.Dial建立后端连接，io.Copy转发数据；WebSocket 升级：检测Upgrade请求头，握手后切换到 WebSocket 协议；
  • 负载均衡：LLM 网关中，基于prometheus获取指标（如 CPU 使用率），最少请求策略维护每个后端的连接数，前缀缓存缓存热门 LLM 请求的前缀结果。

（4）云服务与 AI 模块

问题

  • 项目中如何集成阿里云的私有链接、NLB、Nacos？对接过程中遇到了什么问题？
  • LLM Gateway 的三种调度模式（调度器 / 重调度 / 网关）分别适用于什么场景？
  • AIGC Gateway 集成 SD 和 ComfyUI API 时，是如何处理不同 API 的差异的？

准备方向

  • 云服务集成：通过阿里云 SDK 调用 API，用 ConfigMap 存储配置（AccessKey 等），控制器监听配置变化动态更新；问题比如 NLB 创建延迟，通过重试机制解决；
  • AI 网关适配：定义统一的请求 / 响应结构体，对不同 API 做适配转换（如 SD 的 txt2img 和 ComfyUI 的 prompt 格式转换）。

3. 项目难点与解决方案（能力考察核心）

核心问题

  • 项目开发过程中遇到的最大技术难点是什么？怎么分析的？最终怎么解决的？
  • 如何保障高并发、高可用场景下的服务稳定性？（比如流量峰值、资源故障时）
  • 项目中有没有做过性能优化？优化思路是什么？效果如何？

准备方向（按 “问题 - 分析 - 方案 - 成果” 结构说，1-2 个案例即可）

示例 1：

  • 问题：高并发下 Storage Cache 的锁竞争严重，缓存响应延迟高；
  • 分析：单锁导致所有请求排队，热点 key 竞争更激烈；
  • 方案：实现分片缓存，按 key 哈希分 16 个桶，每个桶独立 RWMutex；
  • 成果：锁等待时间减少 80%，缓存响应延迟从 50ms 降至 10ms。

示例 2：

  • 问题：LLM 服务调用峰值高，后端实例扩容不及时导致请求超时；
  • 分析：LLM 推理耗时久，突发流量下容易打满实例；
  • 方案：1）前缀缓存缓存热门请求前缀；2）基于指标（CPU / 显存）的动态扩容；3）请求排队 + 限流；
  • 成果：超时率从 15% 降至 1%，资源利用率提升 30%。

4. 个人职责与项目贡献（避免 “混项目”）

问题

  • 你在项目中具体负责哪个模块？从 0 到 1 开发还是迭代优化？
  • 你独立设计 / 解决的核心功能是什么？有什么技术创新点？
  • 项目上线后，你做过哪些运维或优化工作？

准备方向

  • 明确边界：比如 “独立负责 LLM Gateway 的调度模块开发”“主导 Storage Cache 的分片锁优化”；
  • 创新点量化：比如 “设计的前缀缓存策略，使 LLM 热门请求命中率提升 40%”“开发的云资源联动脚本，减少 80% 的手动运维操作”。

5. 拓展与优化（思维广度考察）

问题

  • 目前项目存在什么不足？如果让你重构某个模块，你会怎么改？
  • 如何将项目扩展到多集群场景？跨集群的服务发现和资源管理怎么实现？
  • 项目中如果要接入新的 AI 模型（如 GPT-4、文心一言），需要做哪些适配？

准备方向

  • 不足 + 改进：比如 “Cache Server 的 API 文档不完整，计划用 Swagger 自动生成；LLM 调度策略可增加 AI 负载预测，提升调度精度”；
  • 多集群拓展：用 Karmada 实现多集群资源管理，Nacos 跨集群服务发现，云资源按集群隔离；
  • 新模型适配：在 AIGC Gateway 中增加模型适配层，统一请求参数格式，后端动态绑定模型实例。

三、面试技巧总结

  1. 结构化表达：回答问题按 “总 - 分 - 总”，先给结论，再讲细节，最后总结价值；
  2. 结合业务场景：技术不要孤立说，比如 “用 Informer 是为了减少 K8s API 调用，保障服务在大集群下的性能”；
  3. 主动暴露亮点：如果擅长某模块（如 LLM 网关），可以在回答中主动提及 “我在项目中重点负责 AI 网关模块，解决了 XX 问题”；
  4. 诚实面对不会的问题：如果被问倒，可说 “这个点我目前了解不够深入，但我会从 XX 方向去学习”，避免瞎编。

项目面试高频 10 问 & 精简标准答案（可直接背诵）

1. 问题：这个项目的整体架构是什么？核心价值是什么？

答案：架构是 “K8s 为底座 + 事件驱动控制器 + 多模块能力集成”—— 以 K8s Informer 机制实现控制器（Service/Vipserver 等），集成云资源、AI 网关、缓存等模块，提供统一服务治理。核心价值是解决多类型服务（传统 / 云 / AI）部署复杂、运维成本高的痛点，实现服务全生命周期自动化管理。

2. 问题：项目中怎么用 K8s Informer 机制实现事件驱动？

答案：Informer 是 “客户端缓存 + 事件通知” 工具，避免频繁调用 K8s API。项目中通过For(&corev1.Service{})监听资源变化，用 Indexer 建索引查资源，Workqueue 存事件（设延迟重试去重），最终在 Reconcile 方法中处理服务生命周期事件，保障大集群下性能稳定。

3. 问题：各个控制器（Service/Vipserver/Cloud）之间怎么协同工作？

答案：以 Service Controller 为核心 —— 它管理 EAS 服务生命周期，状态变更（如启动 / 销毁）同步给 Vipserver Controller（维护端点）和 Cloud Controller（联动云资源，如 NLB/Nacos）；用 StateDB 存储服务状态，各控制器监听状态事件，实现 “服务生命周期 - 端点 - 云资源” 联动。

4. 问题：Storage Cache 的高并发优化怎么做的？效果如何？

答案：核心是 “LRU + 分片锁”—— 用双向链表 + 哈希表实现 LRU，按 key 哈希分 16 个桶，每个桶独立sync.RWMutex，减少锁竞争。优化后锁等待时间减少 80%，缓存响应延迟从 50ms 降至 10ms，命中率稳定在 92%。

5. 问题：LLM Gateway 支持哪几种调度模式？适用场景是什么？

答案：支持 3 种模式 —— 调度器模式（批量任务调度）、重调度模式（故障实例任务迁移）、网关模式（实时请求转发）。搭配 3 种策略：基于指标（CPU / 显存）适合高负载，最少请求适合均衡分发，前缀缓存适合热门 LLM 请求，响应延迟降低 25%。

6. 问题：集成阿里云资源（如 NLB/Nacos）时，遇到什么难点？怎么解决？

答案：难点是 NLB 创建延迟、Nacos 服务注册抖动。解决：用 “重试机制 + 状态轮询” 处理 NLB 延迟（重试间隔 2s，最多 10 次）；Nacos 注册加缓存和健康检查，失败时触发 StateDB 状态变更，控制器自动重新注册，服务注册成功率 99.95%。

7. 问题：项目怎么保障高并发、高可用场景下的服务稳定性？

答案：三层面保障 —— 流量层：网关限流 + 前缀缓存，峰值 QPS 扛到 5 万 +；资源层：云资源弹性扩容 + 多可用区部署；故障层：StateDB 状态监听 + 任务重调度，故障自动恢复时间 < 30s，服务可用性 99.9%。

8. 问题：你在项目中独立负责的核心功能是什么？有什么贡献？

答案：独立负责 LLM Gateway 调度模块和 Storage Cache 分片优化。设计调度模式适配不同 LLM 任务，实现前缀缓存策略，热门请求命中率提升 40%；分片锁方案解决高并发锁竞争，支撑了 10+AI 团队的 LLM 服务稳定运行。

9. 问题：项目目前有什么不足？如果让你改进，怎么改？

答案：不足是 Cache Server API 文档缺失、LLM 调度无负载预测。改进：用 Swagger 自动生成 API 文档，降低接入成本；引入时序模型（如 ARIMA）预测 LLM 实例负载，提前扩容，预计能将超时率再降 0.5 个百分点。

10. 问题：如果要接入 GPT-4 这类新 AI 模型，需要做哪些适配工作？

答案：两步适配 ——1）在 AIGC Gateway 加适配层，定义统一请求 / 响应结构体，转换新模型与现有 API 的参数差异；2）在 LLM Gateway 扩展调度策略，适配新模型的显存 / 算力需求，通过 Nacos 自动注册新模型实例，实现无感知接入。

llm-gateway 模块架构理解

llm-gateway 是用于管理 LLM 服务请求的复杂系统，具备高级调度和资源管理能力，整体架构围绕高可用性、可扩展性和高效资源利用设计。

一、核心架构组件

1. 三种运行模式

  • 网关模式：处理入站请求，实现负载均衡
  • 调度器模式：管理资源分配和令牌分发
  • 重调度器模式：处理动态负载再平衡和故障转移

二、调度策略

  • 前缀缓存策略：通过 Radix Tree 前缀匹配优化请求重用
  • 最少令牌策略：使用装箱算法（首次适配递减）实现高效资源分配
  • PD 分离策略：分离预填充和解码工作负载
  • Llumnix 策略：具备缓存感知和迁移能力的高级调度策略

三、关键设计模式

  • 工厂模式：广泛用于创建负载均衡器和调度策略实例
  • 策略模式：不同调度策略实现通用接口，支持灵活切换
  • 观察者模式：基于 WebSocket 的保活机制，实现状态同步
  • 代理模式：通过负载均衡代理选择合适的后端实现

四、高级特性

1. Llumnix 集成

  • 基于 KVS（键值存储）实现缓存感知调度，追踪缓存位置
  • 借助 CMS（集群管理服务）管理实例元数据和状态
  • 集成 Redis 实现分布式状态管理
  • 支持具有迁移能力的高级重调度

2. 资源管理

  • 采用借用方 / 工作方模型实现实时令牌追踪
  • 具备自动故障转移的故障恢复机制
  • 实现平滑加权轮询（SWRR）负载均衡
  • 支持批处理以提升吞吐量

五、服务发现

  • 与 EAS（弹性算法服务）发现机制集成
  • 提供服务可用性保障的故障转移机制
  • 集成缓存服务器以优化性能

六、数据流流程

  1. 请求通过网关服务进入系统
  2. 负载均衡器基于预设策略选择合适的后端
  3. 调度器负责管理令牌分配和资源分配
  4. 实时统计管理器追踪资源使用状态
  5. 当需要时，重调度器处理动态负载再平衡
  6. Llumnix 组件提供高级调度优化

七、架构设计目标

  • 面向 LLM 服务环境，保障高可用性、可扩展性
  • 实现高效资源利用，提升服务处理效率
  • 模块化架构支持调度策略的轻松扩展与定制
  • 保持强大的资源管理和故障转移能力
代码笔记
#面试题
面试项目 - eas
https://yangfanbin.cn/代码笔记/面试项目 - eas/
作者
Yang Fanbin
发布于
2025年11月9日
许可协议