腾讯 IEG 后台开发实习一面：项目、算法与微服务八股

《面试题目》

1. HTTP 的长连接和短连接有什么区别？长连接的目的是什么？
2. 你知道哪些 Java 开发的框架？
3. 你知道有哪些保障负载均衡的方法吗？
4. 微服务框架有哪些？如果让你设计微服务的服务发现你会怎么做？
5. 你怎么做注册中心集群的高可用性保障？
6. 如果让你做一个 RPC 框架，你会从哪些方面入手？
7. 平时都用哪些语言开发？你觉得 C++ 有什么有趣的特点吗？
8. 平时在学校的爱好是什么，会怎么去学习？
9. 聊一下目前自学遇到的瓶颈和困难。
10. 算法题：二叉树的最大路径和（DFS 做法）。

《参考解析》

HTTP 长短连接：短连接是「一次请求一次 TCP 握手、响应完就关」，每个请求都要付三次握手和慢启动的成本。长连接复用同一条 TCP，用 Connection: keep-alive 保持，省掉重复握手、也避免每次都从拥塞窗口最小值重新爬，同时天然支持服务端推送。目的是降低延迟、减少 TIME_WAIT 和端口耗尽，代价是要处理空闲连接的保活与超时回收。

负载均衡：分四层和七层。四层（LVS、DPDK）按 IP/端口转发，性能高；七层（Nginx、Envoy、Spring Cloud Gateway）能按路径、Header、灰度标签路由。调度算法有轮询、加权轮询、最少连接、一致性哈希。要配健康检查摘除故障节点，并防止健康检查本身把刚重启、还在预热（JIT 未编译、连接池为空）的实例打成「健康」而被流量打死，常见做法是加慢启动权重。

服务发现：核心是注册、心跳、发现三件事。服务启动后把 ip:port + 元数据（版本、机房、权重） 写到注册中心并定期续约，消费方订阅变更并缓存到本地；调用时客户端侧或网关侧做负载均衡。关键设计点是变更如何推送到调用方（长连接推送 + 本地缓存兜底），以及注册中心挂了能不能靠已有缓存继续工作。

注册中心高可用：集群多副本 + 一致性协议（etcd/ZooKeeper 用 Raft/ZAB，Nacos 有 CP/AP 两种模式）。客户端本地缓存是最后一道防线，注册中心整体不可用时仍能按上次的服务列表调用。另外要做多机房部署、脑裂时的取舍（宁可短时间看到过期列表，也别整体不可用）、以及实例摘除的延迟与抖动控制。

RPC 框架设计：从协议、序列化、通信、代理、治理五块切入。协议要有魔数、版本、序列化方式、请求 ID、超时；序列化在性能和体积上权衡（Protobuf/Thrift 优于 JSON）；通信层用 Netty 做连接复用和异步回调，用一个 Map 把请求 ID 映射到未完成的 Future；客户端用动态代理屏蔽调用细节；治理层包括服务发现、负载均衡、超时重试、熔断限流、优雅上下线和链路追踪。难点是「超时了到底成没成功」——重试要配幂等键，否则会重复下单。

二叉树最大路径和：任意路径不要求经过根，因此递归返回的值只能是「以当前节点为端点、向下走一侧」的最大贡献，而全局答案在每一层用 左贡献 + 右贡献 + 当前值 更新。贡献为负的子树直接舍弃（取 max(0, ...)），时间复杂度 O(n)，空间是递归栈 O(h)。