阿里内部都用什么技术？HSF、MetaQ 与 EagleEye

《核心观点》

1. 简历写「熟悉微服务、熟悉消息队列」的人很多，但一问到实际公司内部在用什么、这些组件的设计初衷是什么，就答不上来。
2. HSF：阿里的分布式服务框架，负责服务的注册、发现、负载均衡与熔断降级。
3. Dubbo 与 HSF 的思路一脉相承，理解了 HSF 解决的问题，再看 Dubbo 就是同一套模型的另一种实现。
4. MetaQ：阿里的消息中间件，也是 RocketMQ 的前身，订单消息、库存扣减、异步解耦这类场景都由它承载。
5. 消息队列这一层，能讲清顺序消息、事务消息、幂等、不丢不重，才算真的做过。
6. EagleEye：阿里的全链路监控系统，线上出问题一屏就能看清整条调用链。
7. 这类内部组件外面看不到、文档也不公开，只有真正在内部待过、或者认真研究过其开源对应物的人才讲得出来。
8. 为什么是加分项：面试官听到 HSF、MetaQ，会默认你有大厂视野，而不只是会背八股；Dubbo、RocketMQ、Sentinel 都源于阿里内部，理解内部版本等于理解开源版的设计初衷。
9. 真正的差异点在于，能不能讲清一个组件「从哪来、解决什么问题、踩过哪些坑」，而不是背了多少题。
10. 区分高下的从来不是题量，而是有没有真实的工程判断。

《参考解析》

HSF 讲什么才算讲到位。RPC 框架的名字不重要，重要的是它替你解决了哪些分布式系统里的具体麻烦：服务提供方启动后把地址注册到中心，消费方订阅并拿到一份本地地址列表，调用时按负载均衡策略选一台、序列化请求、超时与重试，失败率超阈值时熔断、把流量摘到其他节点。可以延展的追问点有四个：注册中心挂了还能不能调用（本地缓存的服务列表 + 推空保护），超时时间该设多少（按下游 P99 加余量，不能层层累加），重试怎么保证不重复扣款（只对幂等接口重试、配合业务幂等键），以及优雅上下线怎么让流量无损切走。把这几问答出来，比背「HSF 是阿里自研的 RPC 框架」有价值得多。

MetaQ 与 RocketMQ：顺序、事务、幂等、不丢不重。消息中间件的四道必答题基本固定。顺序消息：要保证同一业务键的消息落进同一个队列，靠队列内的先进先出实现局部有序——全局有序的代价是吞吐，所以正确说法是「按业务键保序」。事务消息：核心是两阶段加一次回查，先发半消息、本地事务执行完再提交或回滚，如果提交确认丢了就由 Broker 反查本地事务状态；它解决的是「本地事务与发消息不同步」，而不是分布式事务的银弹，消费端仍要幂等。不丢消息要分三段讲：生产端等待确认并在失败时重试，Broker 端刷盘策略与多副本同步复制，消费端处理完业务逻辑再提交位点（先提交后处理会丢、先处理不提交会重复）。不重就要靠幂等：业务唯一键去重表、状态机只允许单向流转、或者用消息自带的业务流水号做去重。

EagleEye 这类全链路追踪为什么重要。一次用户请求在微服务里会横向跨十几个服务、纵向穿过缓存、数据库、消息队列，出了问题靠逐个服务翻日志基本不可能定位。全链路追踪的做法是给每个请求分配一个全局 traceId，跨进程调用时透传，每个环节记录 span（开始时间、耗时、状态、上下游），最后按 traceId 把整棵树拼回去。它的价值有三层：故障时快速定位是哪个环节变慢或报错、容量治理时看链路各段的耗时占比、以及从调用拓扑发现不合理的依赖（比如一个基础服务被上百个上游同步调用）。和监控指标、日志并称可观测性的三支柱——指标告诉你「出问题了」，链路告诉你「问题在哪一段」，日志告诉你「具体为什么」。

怎么把这类知识用进面试。稳妥的讲法不是「我在阿里待过」，而是从开源对应物切入：讲 Dubbo 的服务治理与泛化调用、讲 RocketMQ 的事务消息实现与主从同步、讲 SkyWalking 或 OpenTelemetry 的 trace 模型，再点出它们的内部渊源和设计动机。更占优势的是带一个自己踩过的坑——比如一次重试导致的重复扣款怎么定位、一次位点提交顺序错误导致的消息丢失怎么复盘。面试官区分候选人的依据，是「你有没有在真实系统里为这些机制付过代价」，这一点任何背诵都替代不了。反过来也要注意边界：讲不熟的组件宁可说不知道，硬编一个概念被追问两层就会崩，代价远大于坦白。