内容

面试官： 你提到主导了直播与互动教室核心服务的架构演进，引入了 DDD 和基于 Docker 的水平伸缩。

DDD 实践与限界上下文划分依据

你提到用 DDD 解耦了信令、媒体流、状态同步服务。假设在“举手提问”场景中:

Q1. 信令服务（处理举手请求）、媒体流服务（调整视频流焦点）、状态同步服务（广播举手状态）之间的数据流如何设计？

Q2. 这三个服务的领域模型（实体/值对象）具体包含哪些属性？它们之间的上下文映射（如防腐层）如何实现？

微服务拆分权衡

Q1. 媒体流服务若进一步拆分为“视频编解码”和“传输控制”两个微服务，你认为是否合理？请从 CAP 理论（一致性 vs 可用性）和部署成本（资源占用、运维复杂度）角度分析利弊。

水平伸缩与状态管理

Q1. 媒体流服务单节点承载用户量提升 5-40 倍，这个提升是如何实现的？主要是 Docker/K8s 带来的，还是架构优化（比如连接复用、协议优化）带来的，或者是两者结合？

Q2. 进行水平伸缩时，如何解决有状态服务（比如 WebSocket 连接、媒体会话状态）的问题？用了什么方案？（如将状态外置到 Redis/数据库？使用 Sticky Session？还是服务本身设计成无状态的？）

Q3. 服务发现(Nacos)在伸缩过程中扮演什么关键角色？负载均衡策略选的是什么？为什么？（如 Round Robin, Least Connections, Consistent Hash）

Q4. 为什么选择一致性哈希（Consistent Hash）而非最小连接数（Least Connections）？请结合“用户突然重连可能命中不同节点”的场景解释。