12 Api 2026

面试问题

整体问题偏向项目追问，主要围绕实际使用场景展开。

1. 你这个做了什么

主要是项目经历追问。

更关注：

  • 实际负责内容
  • 是否真正参与核心实现
  • 在项目中的角色

注释

这类问题通常需要提前整理：

  • 项目背景
  • 自己负责的模块
  • 技术选型原因
  • 遇到的问题
  • 如何解决
  • 最终效果

避免只描述：

text
1

用了什么技术

而需要强调：

text
1
2

为什么这么做
解决了什么问题

2. Elasticsearch 丢日志怎么处理

知识点补充

日志丢失通常需要从几个方向排查：

数据写入链路

例如：

text
1

应用 -> Filebeat/FluentBit -> Kafka -> Logstash -> Elasticsearch

需要确认：

  • 哪一层出现丢失
  • 是否存在 buffer 满
  • 是否出现 backpressure
Elasticsearch 本身

重点包括：

  • 磁盘是否写满
  • JVM Heap 是否不足
  • 是否触发 GC
  • refresh / flush 压力
  • shard 是否过多
  • replica 是否异常
常见排查命令
bash
1
2
3

GET _cluster/health
GET _cat/nodes?v
GET _cat/shards?v
常见优化方向
  • 增加 buffer
  • Kafka 做削峰
  • 减少 shard 数量
  • 调整 bulk 大小
  • 调整 refresh_interval
  • 增加 data node

3. HAProxy 替代是怎么替代 kube-proxy的

问题主要在于：

  • 为什么替换
  • 如何迁移
  • 替换后架构变化

注释

常见替代方向：

原组件替代方案
HAProxyEnvoy
HAProxyNginx
HAProxy云厂商 LB
HAProxyKubernetes Ingress

一般迁移需要考虑

  • 四层还是七层
  • 会话保持
  • 健康检查
  • TLS
  • 配置兼容
  • 性能影响
  • 灰度切换

4. LB 是怎么实现

注释

LB（LoadBalancer）实现通常分几个方向：

四层 LB

基于：

  • IP
  • TCP/UDP

常见：

  • LVS
  • HAProxy
  • 云厂商 NLB
七层 LB

基于：

  • HTTP
  • Host
  • Path

常见：

  • Nginx
  • Envoy
  • Ingress Controller
Kubernetes 场景

通常链路：

text
1

Service -> kube-proxy -> iptables/ipvs

云环境：

text
1
2
3
4

Service(type=LoadBalancer)
  -> cloud-controller-manager
  -> Cloud API
  -> 云厂商 LB

裸金属环境：

  • MetalLB
  • BGP
  • ARP

结果总结

  • 自我介绍相比之前有优化，但对面试方向的引导仍然不够
  • 面试问题更多偏向接手后的实际问题，而不是基础原理
  • 面试官更关注“是否能处理现有问题”，而不是知识体系本身
  • 整体交流过程中，对方更偏向结果导向

30 Api 2026

面试问题

遇到的都是纯流水线问题：

  • Java 项目和其他项目有什么区别
  • 如果遇到了 P0 级别故障你怎么处理
  • 日志你们更倾向于用什么样的
  • 新入职遇到问题更倾向于 AI 查资料还是问同事
  • 阿里云的 Terway 和 Flannel 区别

我的薄弱点

  • ELK

ELK 需要重点补的是完整日志链路，而不是只知道 Elasticsearch。 面试中可以按 采集层 -> 缓冲层 -> 处理层 -> 存储层 -> 查询展示层 来回答，例如： Filebeat / FluentBit -> Kafka -> Logstash / Vector -> Elasticsearch -> Kibana / Grafana。 排查日志丢失时，要先确认是采集端丢、队列丢、消费端丢，还是 Elasticsearch 写入失败。

  • OpenTracing

OpenTracing 主要用于分布式链路追踪，核心概念包括 Trace、Span、Context、Propagation。 面试中可以说明：一个请求经过多个服务时，每个服务内部的操作可以形成 Span，多个 Span 组成一个 Trace。 现在 OpenTracing 已经逐渐被 OpenTelemetry 统一，回答时可以顺带提到 OpenTelemetry 是当前更主流的标准。

  • 解决问题回答

解决问题类问题不要直接给结论，要按故障处理流程回答。 推荐结构： 现象确认 -> 影响范围 -> 止血恢复 -> 定位根因 -> 修复验证 -> 复盘改进。 P0 故障重点不是展示自己多懂技术，而是展示优先级意识：先恢复业务，再分析根因，最后做长期治理。

  • 平时专注的都是调度框架原理，根本没看基础信息，用到的也少，没回答好亲和性、反亲和性

Kubernetes 亲和性主要分为 Node Affinity 和 Pod Affinity。 Node Affinity 用来控制 Pod 调度到哪些节点上，例如按照节点标签选择机器。 Pod Affinity 用来让 Pod 尽量和某些 Pod 调度在一起。 Pod Anti-Affinity 用来让 Pod 尽量分散，常用于高可用场景，避免多个副本落在同一个节点或同一个可用区。 面试中可以结合 Deployment 多副本高可用来说：反亲和性可以减少单节点故障导致多个副本同时不可用的问题。

结果总结

  • 面试都是模棱两可问题，没有具体的技术方向
  • 自己的项目完全没有被问到
  • 个人感觉这样的公司不要去，他们是要干活的，不是解决问题的人，没有发展
  • 还有一种可能是面试官的技术水平也是合约
  • 第二次面试网络不好直接终止