不同规模公司的技术栈差异

┌─────────────────────────────────────────────────────────────────────┐
│                        阿里云/腾讯云                                   │
│                                                                      │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │                       ECS 云服务器                            │   │
│  │                                                               │   │
│  │  Docker Compose                                               │   │
│  │  ┌────────────────────────────────────────────────────────┐   │   │
│  │  │  nginx:latest         (反向代理 + SSL证书 + 静态资源)    │   │   │
│  │  │                                                        │   │   │
│  │  │  app:latest            (Spring Boot FAT JAR)           │   │   │
│  │  │                        (内嵌Tomcat, 一键java -jar)      │   │   │
│  │  │                                                        │   │   │
│  │  │  redis:7-alpine        (缓存 + Session共享 + 分布式锁)   │   │   │
│  │  │                                                        │   │   │
│  │  │  mysql:8.0             (业务数据库, 或直接用RDS)         │   │   │
│  │  │                                                        │   │   │
│  │  │  rabbitmq:3-alpine     (消息队列, 流量小可省略)          │   │   │
│  │  └────────────────────────────────────────────────────────┘   │   │
│  └──────────────────────────────────────────────────────────────┘   │
│                                                                      │
│  其他云服务：                                                          │
│  ├─ OSS (对象存储：图片/文件/静态资源)                                │
│  ├─ CDN (加速OSS静态资源)                                            │
│  ├─ CloudMonitor (基础监控：CPU/内存/磁盘/网络)                       │
│  ├─ SLS (日志服务，替代ELK，按量付费)                                 │
│  └─ DNS + 域名备案                                                    │
└─────────────────────────────────────────────────────────────────────┘

✗ 错误回答：
"我在小公司，技术栈比较浅，用的就是Spring Boot + MySQL，没什么可说的。"
(贬低自己的经历，面试官会觉得你没有总结能力)

✓ 优秀回答框架：

"我在创业公司虽然技术栈以Spring Boot单体为主，
但正因为团队小，我从需求分析到上线部署全流程都做过。
具体来说：

1 从零搭建项目：我负责了整个后端的架构选型和初始化，
   选择了Spring Boot + MyBatis-Plus + MySQL + Redis这套方案。
   选型考虑是：团队成员都熟悉Java、业务场景以CRUD为主、
   短期没有微服务化的必要。

2 经历过完整链路：对接过支付宝和微信支付、做过数据库设计
   和SQL优化、配置过Nginx和HTTPS证书、搭过Jenkins自动部署。

3 有技术判断力：我知道单体架构在业务增长后需要拆成微服务，
   也规划好了分表方案（预留了分布式ID和分表键），
   不是只会CRUD不考虑未来。

4 踩过坑才有深度：有一次线上OOM，我从堆转储分析到线程Dump，
   最终定位到是ThreadLocal没有清理导致的内存泄漏。
   这种实战排查经验，是大厂里分工细化的环境下不容易获得的。"

核心亮点：
1. 强调"全流程经验"——广度是你的核心优势
2. 承认"简单够用"的合理性——展示技术选型的判断力
3. 展示"知道怎么进化"——体现架构思维，不是只会CRUD
4. 穿插具体踩坑案例——证明你不仅有广度，也有深度思考

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│    C端应用    │     │  Admin管理端  │    │  第三方开放平台│
│   (H5/App)   │     │  (PC/Mobile) │     │  (API对接)    │
└──────┬───────┘     └──────┬───────┘     └──────┬───────┘
       │                    │                    │
       ▼                    ▼                    ▼
┌──────────────────────────────────────────────────────────────┐
│                   接入层 (Ingress)                            │
│    Nginx + SLB (负载均衡) + CDN + WAF (Web防火墙)             │
└──────────────────────────┬───────────────────────────────────┘
                           │
┌──────────────────────────▼───────────────────────────────────┐
│              Spring Cloud Gateway (网关集群 × 2节点)            │
│  路由转发 | JWT/OAuth2鉴权 | Sentinel限流 | 灰度发布 | 请求日志 │
│  路由规则 + 限流规则 → 持久化到Nacos，动态刷新无需重启            │
└────┬──────────┬──────────┬──────────┬──────────┬──────────────┘
     │          │          │          │          │
     ▼          ▼          ▼          ▼          ▼
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ 用户服务│ │ 订单服务│ │ 商品服务│ │ 支付服务│ │ 通知服务│
│ (User) │ │(Order) │ │(Product)│ │ (Pay)  │ │(Notify)│
└───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘
    │          │          │          │          │
    ├────OpenFeign 同步调用────────────┤          │
    └───────────RocketMQ 异步解耦──────┴──────────┘
                         │
                         ▼
┌──────────────────────────────────────────────────────────────┐
│                    中间件层 (Middleware)                     │
│                                                             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│  │MySQL主从  │ │Redis     │ │RocketMQ │ │Elastic-  │        │
│  │+分库分表  │ │Cluster   │ │集群      │ │search    │        │
│  │Sharding- │ │3主3从    │ │4主4从    │ │集群      │        │
│  │Sphere    │ │          │ │          │ │          │        │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘        │
│  ┌──────────┐ ┌──────────┐                                   │
│  │MinIO/OSS │ │Nacos     │                                   │
│  │(对象存储) │ │(注册+配置)│                                  │
│  └──────────┘ └──────────┘                                    │
└──────────────────────────────────────────────────────────────┘
                         │
                         ▼
┌──────────────────────────────────────────────────────────────┐
│                   可观测性 (Observability)                    │
│                                                              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│  │Prometheus│ │ Grafana  │ │   ELK    │ │SkyWalking│        │
│  │(指标)    │ │(看板)    │ │ (日志)   │ │(链路)    │         │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘        │
│  ┌──────────┐                                                │
│  │Alert-    │ → 钉钉/企微通知                                 │
│  │manager   │                                                │
│  └──────────┘                                                │
└──────────────────────────────────────────────────────────────┘
                         │
                         ▼
┌──────────────────────────────────────────────────────────────┐
│                   DevOps部署层                                │
│                                                               │
│  K8s集群 (3 Master + 3 Worker)                                │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│  │ Jenkins  │ │ Harbor   │ │ Helm     │ │ GitLab   │        │
│  │ (Pipeline)│ │(镜像仓库)│ │(Chart)   │ │ (代码仓)  │        │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘        │
└──────────────────────────────────────────────────────────────┘

告警分级示例：

P0 (致命): 核心接口不可用 → 立即电话 + 钉钉@所有人
  例：登录/支付/下单接口500错误率>5%

P1 (严重): 功能受损 → 钉钉@值班人 + 企微通知
  例：P99延迟 > 5s、数据库连接池耗尽

P2 (一般): 需要关注 → 钉钉群通知
  例：磁盘使用率 > 80%、JVM FullGC频率升高

P3 (提示): 日常观察 → 日报/周报汇总
  例：慢SQL数量增加、缓存命中率下降

✓ 优秀回答框架：

"我在上一家中型互联网公司（200人左右）担任后端开发，负责订单域。
技术栈是Spring Cloud Alibaba全套，服务数大概15个左右。

我最大的收获有三个方面：

第一是微服务治理的实战经验。
比如服务多了以后，Nacos频繁推送导致服务间调用超时，
后来排查发现是Nacos AP模式下健康检查过于敏感，
调整了心跳间隔（从5s调整为15s）解决了。
再比如Sentinel限流规则的动态配置，我们通过Nacos持久化实现，
避免了每次重启规则丢失的问题。

第二是稳定性建设。
我是我们组On-Call值班的负责人，经历过几次线上事故后，
搭建了完善的告警体系。核心接口P99 > 3s钉钉告警，
错误率 > 1%电话告警，每天自动出稳定性日报。

第三是性能优化的实践经验。
以MySQL为例，我们有一个慢查询导致接口超时的问题，
通过EXPLAIN分析发现是索引失效（隐式类型转换），
修复后查询时间从2.3s降到15ms。

当然现在回头看也有不足：
- 微服务拆得比较随意，没有严格按DDD划分边界
- 配置管理没有统一规范，各服务有自己的配置文件
- 发布流程太慢，从开发到上线要一周

如果让我重新规划，会更早引入配置规范，用统一的配置中心做配置管理。"

核心亮点：
1. 具体技术场景 + 解决方案（证明实战经验）
2. 稳定性建设和值班制度（证明运维意识）
3. MySQL索引优化的量化数据（证明深度）
4. 反思不足 + 改进方案（证明架构思维）

┌─────────────────────────────────────────────────────────────────────┐
│                       大厂自研深度分级                                │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Level 1: 直接用开源（极少）                                          │
│  → 只有周边工具才用纯开源方案                                          │
│  → 例：日志采集、监控面板等非核心链路                                  │
│                                                                      │
│  Level 2: 开源 + 配置调优 + Bug修复                                   │
│  → 不改核心逻辑，但加监控埋点、调整默认参数                             │
│  → 例：对MySQL内核参数优化、JVM统一调优                               │
│                                                                      │
│  Level 3: Fork + 深度定制                                            │
│  → Fork开源项目，核心组件按需重写，保持API兼容                          │
│  → 例：美团对Kafka的深度改造、字节对Redis的定制化                       │
│                                                                      │
│  Level 4: 完全自研 (API不兼容)                                        │
│  → 核心中间件从零自研，解决开源方案的架构瓶颈                            │
│  → 例：OceanBase (完全自研的分布式数据库)、Kitex (自研RPC框架)         │
│                                                                      │
│  Level 5: 云化输出 / 商业化                                          │
│  → 自研项目商业化，对外提供服务或开源                                  │
│  → 例：阿里云全线产品、字节火山引擎、京东云                             │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

                              ┌──────────────────────────────────────────┐
                              │         全局负载均衡 (GSLB)               │
                              │         按userId哈希 → 路由到单元          │
                              │         每个单元处理1/N的用户               │
                              └──────────────────┬───────────────────────┘
                                                 │
         ┌───────────────────────────────────────┼───────────────────────────────┐
         │                                       │                               │
         ▼                                       ▼                               ▼
┌─────────────────────────┐     ┌─────────────────────────┐     ┌─────────────────────────┐
│     单元 A (北京机房)     │     │     单元 B (上海机房)     │     │     单元 C (广州机房)     │
│                         │     │                         │     │                         │
│  ┌───────────────────┐  │     │  ┌───────────────────┐  │     │  ┌───────────────────┐  │
│  │ 接入网关            │  │     │  │ 接入网关            │  │     │  │ 接入网关            │  │
│  └────────┬──────────┘  │     │  └────────┬──────────┘  │     │  └────────┬──────────┘  │
│           │             │     │           │             │     │           │             │
│  ┌────────▼──────────┐  │     │  ┌────────▼──────────┐  │     │  ┌────────▼──────────┐  │
│  │ 业务服务集群         │  │     │  │ 业务服务集群         │  │     │  │ 业务服务集群         │  │
│  │ 用户/订单/商品/支付  │  │     │  │ 用户/订单/商品/支付  │  │     │  │ 用户/订单/商品/支付  │  │
│  └────────┬──────────┘  │     │  └────────┬──────────┘  │     │  └────────┬──────────┘  │
│           │             │     │           │             │     │           │             │
│  ┌────────▼──────────┐  │     │  ┌────────▼──────────┐  │     │  ┌────────▼──────────┐  │
│  │ 单元数据库           │  │     │  │ 单元数据库           │  │     │  │ 单元数据库           │  │
│  │ (只存本单元用户数据)  │  │     │  │ (只存本单元用户数据)  │  │     │  │ (只存本单元用户数据)  │  │
│  └───────────────────┘  │     │  └───────────────────┘  │     │  └───────────────────┘  │
│                         │     │                         │     │                         │
│  用户范围: ID 1-3kw      │     │  用户范围: ID 3-6kw      │     │  用户范围: ID 6-9kw      │
└─────────────────────────┘     └─────────────────────────┘     └─────────────────────────┘
                                                                          │
         ┌────────────────────────────────────────────────────────────────┘
         ▼
┌────────────────────────────────────────────────────────────────────────┐
│                       全局服务 (Global Service)                         │
│                                                                         │
│  存放全局数据：配置信息、公告、元数据、全局字典                           │
│  跨单元查询：全站搜索、全局报表、跨单元的用户关联查询                     │
│                                                                         │
│  全局服务本身也要多活部署，不能成为单点                                   │
└────────────────────────────────────────────────────────────────────────┘

大厂面试官的核心关注点（按权重排序）：

1 原理理解 (40%) —— 不只是API，是"为什么这么设计"
   例：为什么Redis用单线程？为什么Kafka吞吐高？
   为什么Sentinel用滑动窗口做统计？

2 场景判断 (30%) —— 知道在什么场景下用什么技术
   例：什么时候用MQ解耦？什么时候用分布式锁？
   分库分表的策略怎么选？

3 踩坑经验 (20%) —— 曾经踩过什么坑，怎么解决的
   例：缓存一致性怎么保证？分布式事务失败怎么处理？
   OOM怎么排查？

4 原理广度 (10%) —— 有没有横向对比不同方案的差异
   例：RocketMQ vs Kafka vs RabbitMQ 的选型对比
   Seata AT vs TCC vs Saga 的选择

✗ 错误回答：
"大厂用的都是自研中间件，我没用过，不太了解。"

✓ 优秀回答思路：

"虽然我之前在中小公司用的是开源方案，但我在原理层面有深入研究。
比如Redis，我不光会用，还读过：
- dict的渐进式rehash过程
- ziplist和quicklist的转换条件
- 主从复制的完整流程（包括psync2优化）

我认为开源方案和自研方案在核心原理上是相通的，
大厂只是在极致性能和稳定性上做了更多工程优化。
如果有机会学习贵司的自研中间件，我相信能很快上手。
事实上，我最近已经在看Kitex（字节）/Dubbo（阿里）
的源码，对SPI扩展机制和自定义协议有了初步理解。"

核心思路：承认没经验 + 展示原理深度 + 表达学习意愿 + 展示主动研究

✓ 优秀回答思路：

"我在上一家公司用的是自研RPC框架（如JSF/Kitex），
对比开源Dubbo，核心差异在三点：

1 协议层：自研基于Netty+自定义二进制协议，
   减少了序列化开销，比Dubbo的Hessian2提升了约30%吞吐

2 服务发现：自研注册中心支持秒级推送，
   基于长连接+版本号对比，比Nacos的15s+长轮询快得多

3 治理能力：支持基于方法级别的权限控制和熔断策略，
   以及更细粒度的流量调度

当然自研也有代价——社区维护成本高，新员工学习曲线陡。
我看到贵司也在做类似的自研中间件，
想了解下相比开源方案的主要设计思路是什么？"

核心思路：具体对比 + 承认代价 + 反问体现思考深度

┌──────────────────────────────────────────────────────────────┐
│                        渠道层 (Channel)                        │
│                                                               │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ 手机银行  │  │ 网上银行  │  │ 柜面系统  │  │ 开放平台  │     │
│  │   APP    │  │  Web端   │  │ 柜台终端  │  │ API接入   │     │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘     │
└──────────────────────┬───────────────────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────────────────┐
│                      网关层 (Enterprise Service Bus)           │
│                                                               │
│  企业服务总线 (ESB) / 前置系统 / 接入网关                       │
│  安全认证 + 报文转换 (XML/ISO8583) + 流量控制 + 签名验签        │
│  协议转换：HTTP ↔ TCP/XML ↔ JSON 等                             │
└──────────────────────┬───────────────────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────────────────┐
│                      应用层 (Application)                      │
│                                                               │
│  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐ │
│  │ 核心银行 │  │ 信贷系统 │  │ 理财系统 │  │ 风控系统 │  │ 核算系统 │ │
│  │ (Core)  │  │ (Loan)  │  │ (Asset) │  │ (Risk)  │  │(Settle)│ │
│  └────────┘  └────────┘  └────────┘  └────────┘  └────────┘ │
└──────────────────────┬───────────────────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────────────────┐
│                      数据层 (Data)                             │
│                                                               │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │  Oracle  │  │   DB2    │  │ 达梦DM8   │  │  IBM MQ  │     │
│  │  (主库)   │  │  (备库)   │  │ (国产化)   │  │  (消息)   │     │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘     │
│  ┌──────────┐  ┌──────────┐                                    │
│  │   Redis  │  │ WebLogic │                                    │
│  │  (少数场景)│  │ (应用服务器)│                                    │
│  └──────────┘  └──────────┘                                    │
└──────────────────────────────────────────────────────────────┘

✓ 优秀回答框架：

"我之前在互联网公司做后端开发3年，技术功底还是比较扎实的。
为什么选择银行系统？主要考虑两点：

1 长期发展：我希望在一个领域深耕，银行系统虽然技术栈相对传统，
   但业务复杂度极高（日切对账、总分核对、利率计算、合规风控），
   技术要求并不比互联网简单。

2 稳定性建设：我理解银行的核心诉求是稳定和安全。
   用成熟技术而不是最新技术，恰恰是对用户负责。
   而且现在的银行都在做数字化转型和信创改造，
   Oracle迁移到达梦、ESB逐步演进为微服务架构，
   这里面有大量技术挑战，我希望能参与这个过程。

我的互联网经验可以为银行带来：
- 微服务拆分的实践经验
- 自动化测试和CI/CD的工程理念
- 高并发场景下的性能优化思路
但这些经验我会结合银行的合规要求做适配，不会盲目套用。"

核心策略：强调互联网的技术功底 + 对银行稳定文化的充分理解 + 数字化转型的参与意愿

✓ 优秀回答框架：

"我在银行核心系统有4年经验，最大的优势是**对高可用和数据一致性
有深刻理解**。银行系统对数据准确性的要求甚至高于互联网：
- 日切对账：每日零点前后必须保证账务绝对平衡
- 幂等控制：一笔交易重试100次结果必须一致
- 补偿机制：跨系统调用失败时必须有完善的冲正/补偿流程
- 对账体系：内部账与外部渠道按日/按周/按月核对

虽然技术上用的中间件比较传统（Oracle/WebLogic/IBM MQ），
但我理解背后的**设计理念**——事务ACID、幂等设计、补偿机制、对账体系。
这些设计理念在任何架构下都是通用的。

我也在持续学习互联网技术栈，自己搭了Spring Cloud Alibaba的
Demo项目，已经熟悉了Nacos/Sentinel/Gateway/Seata这些组件。
如果需要，我可以现场展示这个项目。"

核心策略：转换劣势为优势——银行经验 = 严谨 + 高可用 + 数据一致性强认知

外企技术栈 = 云原生 + 深度绑定自家云厂商

示例：AWS生态下的技术栈全景

┌─────────────────────────────────────────────────────────────────────┐
│                           AWS 生态系统                                │
│                                                                      │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │                    计算 (Compute)                            │    │
│  │  EC2 (虚拟机) → ECS/EKS (容器) → Lambda (Serverless)        │    │
│  │  Fargate (无服务器容器) → Step Functions (工作流编排)        │    │
│  └─────────────────────────────────────────────────────────────┘    │
│                                                                      │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │                  API与集成 (API & Integration)               │    │
│  │  API Gateway (API管理) + ALB/NLB (负载均衡)                 │    │
│  │  SQS (消息队列) + SNS (通知) + EventBridge (事件总线)        │    │
│  └─────────────────────────────────────────────────────────────┘    │
│                                                                      │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │                   数据 (Data)                                │    │
│  │  RDS/Aurora (关系型) + DynamoDB (NoSQL) + ElastiCache (缓存)│    │
│  │  S3 (对象存储) + Redshift (数仓) + EMR (大数据)             │    │
│  └─────────────────────────────────────────────────────────────┘    │
│                                                                      │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │             可观测性与DevOps (Observability & DevOps)        │    │
│  │  CloudWatch (监控日志) + X-Ray (链路追踪)                    │    │
│  │  CodePipeline/CodeBuild (CI/CD) + CloudFormation (IaC)      │    │
│  └─────────────────────────────────────────────────────────────┘    │
│                                                                      │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │             基础设施即代码 (Infrastructure as Code)          │    │
│  │  Terraform (跨云) + AWS CDK / CloudFormation (AWS原生)      │    │
│  │  Packer (镜像构建) + Ansible (配置管理)                     │    │
│  └─────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────┘

✓ 优秀回答框架（外企面经）：

"在外企工作最大的收获是**工程文化和代码质量意识**。
我们每个功能上线前都要写Design Doc，团队Review通过后才能开始开发。
CI流水线会自动跑Lint、单元测试（要求>85%覆盖率）、安全扫描，
通过后才能合并到主分支。虽然初期觉得流程慢，
但回头看这种规范性确实减少了线上问题。

技术方面，我深入使用了AWS生态，对云原生架构有实战经验：
- 用EKS做容器编排，结合Helm管理微服务部署
- 用Lambda + API Gateway做无服务器架构
- 用DynamoDB做高并发场景下的NoSQL方案
- 用Terraform管理基础设施，基础设施即代码

英语方面，我日常工作需要和国外同事协作，
每周都有全英文的Design Review和Sprint Planning，
可以无障碍用英文沟通技术方案。

如果面试国内互联网公司，我需要补充一些自研中间件的知识，
但我认为云原生的设计理念和微服务治理的核心是相通的。"

核心亮点：工程规范性 + 云原生深度 + 英语能力 + 对新环境的适应意愿

┌─────────────────────────────────────────────────────────────────────┐
│                     技术栈选型决策树                                 │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Q1: 团队规模多大？                                                  │
│  ├─ <10人 → 选最简单的方案：Spring Boot + MySQL + Redis + Nginx     │
│  │          一人能搞定所有，不需要微服务                              │
│  └─ ≥10人 → 进入 Q2                                                 │
│                                                                      │
│  Q2: 业务量级？                                                     │
│  ├─ DAU < 10万 → 单体 + 少量微服务即可                              │
│  │                最多拆3-5个服务，分库分表不需要                     │
│  ├─ DAU 10-100万 → 需要微服务 + 分库分表 + 消息队列                  │
│  │                  Spring Cloud Alibaba 全家桶上场                  │
│  └─ DAU > 100万 → 全链路优化 + 多活架构 + 自研/深度定制中间件        │
│                     大厂级别，需要专门的中间件团队                     │
│                                                                      │
│  Q3: 团队技术能力？                                                │
│  ├─ 全员熟练K8s → 上K8s，收益 > 成本                                 │
│  └─ 没人懂K8s → Docker Compose或K3s，降维起步                        │
│                 或直接上云服务（阿里云ACK托管集群）                   │
│                                                                      │
│  Q4: 合规要求？                                                    │
│  ├─ 金融/政务/国央企 → Oracle/达梦 + 等保三级 + 商用中间件           │
│  │                     绝对不能碰社区版的开源组件                     │
│  └─ 一般互联网公司 → MySQL + 开源方案，合规要求低                    │
│                                                                      │
│  Q5: 云还是自建？                                                  │
│  ├─ 云厂商 → 直接用云服务 (RDS/Redis/MQ)                             │
│  │          省钱省力，按量付费，要啥有啥                              │
│  └─ IDC自建 → 自己运维中间件集群                                     │
│               成本高但可控，适合大厂和有特殊合规要求的公司             │
│                                                                      │
│  Q6: 未来3年业务预期？                                              │
│  ├─ 预计10倍增长 → 预留扩展能力 (分库分表/缓存/异步化)               │
│  │                从一开始就要考虑可扩展性设计                        │
│  └─ 稳定业务 → 够用就好，不要过度设计                                │
│                今天的优化可能就是明天的技术债                         │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

四步回答法：

Step 1: 场景 (Context) —— 讲清楚背景
"当时的情况是：团队5个人、创业初期、DAU 1万左右、
业务逻辑复杂度中等、要求在3个月内上线MVP。
我们面临的核心约束是：人少、时间紧、预算有限。"

Step 2: 对比 (Comparison) —— 展示你有做调查研究
"我们在以下几个方案中做了权衡：
- 单体 vs 微服务：选单体。DAU才1万，微服务的治理成本远大于收益。
  引入Nacos/Sentinel/Gateway/Seata这套，5个人光运维就忙不过来。
- MySQL还是MongoDB：选MySQL。业务关系复杂（订单/用户/商品/支付关联），
  MongoDB的多文档事务不如MySQL的ACID成熟。
- Docker Compose vs K8s：选Docker Compose。没人懂K8s，
  学了再上线黄花菜都凉了。直接ECS + Docker Compose先跑起来。"

Step 3: 决策 (Decision) —— 讲清楚最终选择和核心理由
"最终的选型是：Spring Boot 3 + MySQL 8 + Redis 7 + Docker Compose。
核心原则是：**用最成熟的技术解决当前问题，不为未来的不确定性买单**。
在满足需求的前提下，选团队最熟悉、社区最活跃、资料最丰富的方案。"

Step 4: 反思 (Retrospective) —— 展示成长性思维
"现在回头看，这个决策基本正确。但有一点遗憾：
当时MySQL没有预留分表的字段（用了自增主键，没用分布式ID），
导致后来数据量大时做分表比较痛苦。
如果能重来，我会一开始就设计好分表方案：
用雪花算法ID + 按时间分区，即使当时不需要分区，
但预留了扩展性，后续迁移成本会低很多。"

这套回答展示了什么？
- 你能基于实际场景做技术判断 (场景驱动的选型思维)
- 你考虑过多个方案并且能说清楚优劣 (权衡能力)
- 你能复盘并承认不足 (成长性思维)
- 你有架构前瞻性 (不是只解决眼前问题)

场景：3个后端，6个月上线，DAU目标5万
选型：
├─ Spring Boot + MyBatis-Plus（快，熟，够用）
├─ MySQL (RDS) + Redis (云托管)
├─ Docker Compose (单机部署)
├─ 阿里云OSS + CDN (图片/静态资源)
├─ 无需MQ（业务简单，@Async够用）
└─ 无需分库分表（预估数据量可控）

总成本：~500元/月 (云服务器 + RDS)

场景：20个后端，已获A轮融资，DAU 50万
选型：
├─ Spring Cloud Alibaba (Nacos + Sentinel + Gateway + Seata + Feign)
├─ MySQL主从 + ShardingSphere (用户/订单表分库)
├─ Redis Cluster (缓存 + 分布式锁 + Session共享)
├─ RocketMQ (交易消息 + 异步通知 + 死信重试)
├─ Elasticsearch (商品搜索 + 订单搜索)
├─ K8s (15个微服务容器化)
├─ Prometheus + Grafana + SkyWalking (可观测性)
└─ Jenkins + GitLab CI (CI/CD)

总成本：~3-5万/月 (云服务 + 自建K8s节点)

场景：100+后端，上市/Pre-IPO，DAU 5000万+
选型：
├─ 自研RPC框架 (Kitex/HSF/JSF)
├─ 自研微服务治理体系 (Service Mesh + Sidecar)
├─ 自研分布式数据库 (OceanBase/PolarDB/veDB)
├─ 自研消息队列 (RocketMQ深度定制/BMQ/JMQ)
├─ 自研缓存系统 (Tair/Squirrel)
├─ 自研配置中心 (Lion/自研)
├─ 多活架构 + 单元化 (2-3个机房同时服务)
├─ 全链路压测 + 混沌工程
├─ 全链路可观测性 (自建APM + OpenTelemetry)
└─ AI for Ops (智能告警/根因定位/容量预测)

总成本：千万级/月 (基础设施 + 中间件团队)

✓ 标准回答模板（根据情况选择）：

版本A：强调成长与挑战（适合面互联网公司）

"我期望的技术栈有以下几个特点：

第一，**有挑战的技术问题**。我希望工作中能接触到高并发、
分布式、数据一致性这类场景。比如用Redis解决缓存问题、
用MQ做异步解耦、用分布式事务保证一致性——
这些场景能让我持续成长，而不是天天写CRUD。

第二，**有规范的工程实践**。我希望团队有完善的Code Review、
CI/CD和自动化测试流程。代码质量上的追求，
最终会反映在系统的稳定性和自己的成长速度上。

第三，**不排斥但也不盲从新技术**。我不会因为一个技术"火"
就去追，而是会基于实际场景判断是否合适。
但同时我也保持学习和研究——比如最近我在学习
Virtual Threads和LangChain4j，虽然当前项目不一定用得上，
但保持对新技术的敏锐度是必要的。

对于贵司的技术栈，我了解主要是XX和XX（提前做了功课），
我认为与我的技术方向和成长预期是匹配的。"

版本B：强调务实与价值（适合面传统企业/国企）

"比起具体用什么技术栈，我更关注**解决的问题是否有价值**。
我认为技术是为业务服务的，先进的技术如果不能解决实际问题
就没有意义。在上一家公司，我用Spring Boot搭建了一套
完整的订单系统，虽然没有微服务化，但很好地支撑了业务增长。

当然我也在不断学习新技术，保持自己的竞争力。
我理解贵司的技术栈以XX为主，虽然是成熟技术，
但稳定性和可靠性经过了长时间验证，这是对用户负责的表现。
我相信我的技术基础能快速适应贵司的环境。"

版本C：强调能力可迁移（适合跨行业跳槽）

"我不会把技术栈当成选择公司的首要标准。
我的经验告诉我，**核心的工程能力是可迁移的**——
不管是Spring Boot还是ASP.NET Core，不管是MySQL还是Oracle，
背后的设计理念（事务、索引、缓存、异步）是相通的。

我更看重的是：团队的技术氛围、代码质量要求、和技术Leader的视野。
具体用什么框架和语言，给我2-4周时间我就能上手。"

不管哪个版本，一定要加上最后一句，展示你做了功课：
"我在来面试前已经了解过贵司的技术栈，主要是XX和XX，
和我的技术方向是匹配的/是我想要学习的方向。"

✓ 回答框架：

一个好的技术栈应该具备五个特征：

1 社区活跃：有足够多的用户和贡献者，
   遇到问题能搜到答案，不担心项目突然消亡。
   （不看star数的绝对值，看增长趋势和Issue响应速度）

2 团队匹配：团队里有人懂，或者学习成本可控。
   引入一个没人会的技术栈，风险远大于收益。

3 场景适配：技术的设计哲学和业务场景匹配。
   就像你不会用Kafka处理延迟消息，不会用RabbitMQ做日志收集。

4 生态兼容：能和现有技术栈良好集成。
   Spring Cloud Alibaba的好处就是和Spring Boot无缝衔接。

5 可演进：技术本身有持续发展的动力，
   不会短时间内被替代。也要考虑升级路径是否平滑。

✓ 回答框架（按领域组织，不要散装罗列）：

"按领域来说，我最深入的是三个方向：

1 Java生态：Spring Boot的自动配置原理、@Conditional机制、
   自定义Starter开发都理解得很清楚。
   Spring Cloud Alibaba的Nacos（AP/CP模式切换、健康检查机制）
   和Sentinel（滑动窗口限流、规则持久化）读过部分核心源码。

2 数据存储：MySQL的索引优化、事务隔离级别和MVCC有实战经验。
   Redis的5种数据结构底层实现、持久化和主从复制原理理解较深。

3 中间件：RocketMQ的事务消息和顺序消息在生产环境用过，
   了解其存储机制和刷盘策略。ES的倒排索引和DSL查询有一定实践。

其他技术像K8s、Docker、Prometheus能达到独立使用的水平，
但还在持续深入学习中。"

✓ 回答框架：

"选择Java主要是三个原因：

1 生态成熟：Java在企业级应用中的生态是最完善的。
   Spring全家桶让复杂的微服务开发变得标准化，
   中间件（MQ/ES/Redis/NoSQL）对Java的集成支持最好。

2 大厂背书：国内头部互联网公司（阿里/美团/京东）的核心系统
   仍然以Java为主，这意味着Java开发者的职业天花板很高。

3 性能+规范性平衡：Java比Python/Ruby性能好，
   比Go的工具链成熟、框架统一。Virtual Threads出来后，
   并发编程的复杂度也大大降低了。

当然我也在学习Go——主要看中它在云原生和中间件开发领域的优势。
但我认为Java在未来5-10年依然是企业级后端的第一选择。"

✗ "我什么都会" —— 面试官会找你最弱的方向深挖，露馅扣分
✗ "这些技术都差不多" —— 说明你没有深入了解过差异
✗ "我只做业务，不管用啥" —— 说明你没有技术热情
✗ "大厂用的都是自研，我没用过所以不了解" —— 避重就轻，显得没有学习主动性
✗ "Spring Boot就是自动配置，具体原理我没看过" —— 面试官一秒判断水平