FTGO 单体应用
├── 用户管理模块（UserModule）
├── 餐厅管理模块（RestaurantModule）
├── 订单管理模块（OrderModule）
├── 支付处理模块（PaymentModule）
├── 库存管理模块（InventoryModule）
├── 配送调度模块（DeliveryModule）
└── 共享数据库（ftgo_db）

// 单体应用的典型困境：
// 订单团队想修改 OrderService 的数据模型
// 但支付团队正在使用同一个 Order 实体
// 库存团队也依赖 Order 中的商品列表字段
// 任何修改都需要跨团队协调 → 开发效率急剧下降

class Order {
    Long id;
    String customerId;          // 用户团队管理
    List<OrderItem> items;      // 库存团队管理
    BigDecimal totalAmount;     // 支付团队管理
    OrderStatus status;         // 订单团队管理
    DeliveryInfo delivery;      // 配送团队管理
    // 所有团队修改同一个类 → 合并冲突不断
}

// 部署频率的退化过程：
// 第1年：每天部署多次（功能少，风险低）
// 第2年：每周部署一次（功能增多，需要协调）
// 第3年：每月部署一次（风险太高，需要长测试周期）
// 第4年：每季度部署一次（已经没有人敢频繁部署了）

// 更糟糕的是：一旦部署失败，回滚也意味着回滚所有功能
// "我只是改了一个按钮颜色，却要回滚整个订单模块的改动"

// 技术锁定的典型场景：
// FTGO 使用 Java 8 + Spring MVC + Oracle
// 团队想尝试：
// - 用 Go 重写配送调度模块（性能更好）→ 不可能，单体只能用一个语言
// - 用 MongoDB 存储餐厅信息（文档模型更合适）→ 困难，共享数据库
// - 用 Elasticsearch 做搜索 → 需要额外的集成层
// 最终：技术栈被锁定，无法渐进式升级

// 微服务架构下的部署：
// order-service v2.1.0 → 独立部署，不影响其他服务
// payment-service v1.5.3 → 独立部署
// inventory-service v3.0.0 → 独立部署
// 每个服务有自己的 CI/CD 流水线
// 部署失败只影响单个服务，回滚也是单服务操作

// FTGO 微服务架构的技术选型：
// order-service     → Java 17 + Spring Boot（复杂业务逻辑）
// payment-service   → Go（高并发、低延迟）
// notification-service → Node.js（I/O 密集）
// recommendation-service → Python（机器学习生态）
// search-service    → Elasticsearch（全文搜索）
// 每个服务选择最适合的数据库：
// order-service     → PostgreSQL（事务性强）
// inventory-service → MongoDB（灵活的文档模型）
// search-service    → Elasticsearch（全文搜索）
// notification-service → Redis（消息缓存）

// 康威定律的体现：
// 团队A（3-5人）→ 负责 order-service
//   - 自主决定技术栈、开发节奏、部署策略
//   - 通过 API 契约与其他团队协作
//   - 对自己的服务全权负责（You build it, you run it）
//
// 团队B（3-5人）→ 负责 payment-service
//   - 独立的技术选型和部署流程
//   - 与团队A通过 REST API 或事件协作
//   - 不需要与团队A协调部署时间

// FTGO 的流量特征：
// order-service：午餐/晚餐高峰期流量是平时的 10 倍
// search-service：全天高负载
// notification-service：低负载但偶尔突发
//
// 微服务架构下的弹性伸缩：
// order-service：高峰期从 3 个实例扩到 20 个实例
// search-service：始终保持 10 个实例
// notification-service：保持 2 个实例
// 相比单体整体扩容，资源利用率大幅提升

// 单体中的调用（确定性）：
Order order = orderService.createOrder(request);
Payment payment = paymentService.process(order);
// 如果 process() 抛异常，事务自动回滚

// 微服务中的调用（不确定性）：
Order order = orderClient.createOrder(request);
// 如果 orderClient 调用超时，订单是否创建成功？
// 如果订单创建成功但支付调用失败，如何回滚订单？
// 如果支付处理到一半网络断开，如何保证一致性？

单体应用 → 模块化单体 → 微服务架构

// 模块化单体的代码组织：
// ftgo-application/
// ├── ftgo-user-module/          // 用户模块
// │   ├── api/                    // 对外接口（接口定义）
// │   ├── impl/                   // 实现
// │   └── spi/                    // 对其他模块的依赖接口
// ├── ftgo-order-module/          // 订单模块
// │   ├── api/
// │   ├── impl/
// │   └── spi/
// ├── ftgo-payment-module/        // 支付模块
// └── ftgo-kitchen-module/        // 厨房模块
//
// 模块间通过接口（api/spi）通信
// 禁止直接访问其他模块的内部类
// 使用模块化框架（如 Spring Modulith）强制执行边界

// Strangler Fig 模式的 Nginx 配置：
// 阶段1：所有流量到单体
location / {
    proxy_pass http://monolith:8080;
}

// 阶段2：订单相关流量路由到新服务
location /api/orders {
    proxy_pass http://order-service:8080;
}
location / {
    proxy_pass http://monolith:8080;
}

// 阶段3：更多功能迁移到微服务
location /api/orders { proxy_pass http://order-service:8080; }
location /api/payments { proxy_pass http://payment-service:8080; }
location /api/restaurants { proxy_pass http://restaurant-service:8080; }
location / { proxy_pass http://monolith:8080; }

// 阶段4：单体完全下线
location /api/orders { proxy_pass http://order-service:8080; }
location /api/payments { proxy_pass http://payment-service:8080; }
location /api/restaurants { proxy_pass http://restaurant-service:8080; }
location /api/users { proxy_pass http://user-service:8080; }

// 典型的一周：
// 周一：订单团队提交代码，等待集成测试
// 周二：支付团队提交代码，与订单团队代码冲突
// 周三：解决冲突，重新测试
// 周四：部署到预发布环境，发现配送模块的 bug
// 周五：修复 bug，重新测试 → 部署推迟到下周
// 
// 结果：每周只能部署一次，每次部署都是一场"战争"

// 所有服务共享同一个 Oracle 数据库
// 订单表的 schema 变更需要 DBA 审批 → 等待 3 天
// 支付团队添加索引导致订单查询变慢 → 互相影响
// 数据库连接池成为性能瓶颈 → 所有服务争抢连接

// 团队想用 Elasticsearch 提升搜索体验
// 但单体应用只能使用 Oracle 数据库
// 想尝试 Go 语言重写性能瓶颈模块
// 但单体应用只能使用 Java
// 结果：技术债务不断累积，团队士气下降

FTGO 微服务架构：

[API Gateway]
    ├── order-service (Java/Spring Boot, PostgreSQL)
    │   └── 负责：订单创建、状态管理、订单查询
    ├── payment-service (Go, PostgreSQL)
    │   └── 负责：支付处理、退款、对账
    ├── restaurant-service (Java/Spring Boot, MongoDB)
    │   └── 负责：餐厅信息管理、菜单管理
    ├── kitchen-service (Node.js, Redis)
    │   └── 负责：厨房订单管理、出餐状态
    ├── delivery-service (Go, Redis)
    │   └── 负责：配送调度、骑手管理
    ├── notification-service (Node.js, Redis)
    │   └── 负责：推送通知、短信、邮件
    └── search-service (Elasticsearch)
        └── 负责：餐厅搜索、菜品搜索

基础设施：
    ├── Consul（服务注册与发现）
    ├── Kafka（异步消息传递）
    ├── Prometheus + Grafana（监控）
    ├── Jaeger（分布式链路追踪）
    └── Kubernetes（容器编排）

迁移计划（6个月）：

第1个月：模块化单体
- 将代码重组为清晰的模块
- 建立模块间的接口契约
- 引入模块化框架强制执行边界

第2个月：提取 order-service
- 创建独立的 order-service
- 通过 API Gateway 路由订单请求到新服务
- 数据迁移：从共享数据库迁移到独立数据库
- 双写验证：同时写入新旧数据库，对比结果

第3个月：提取 payment-service
- 类似流程
- 与 order-service 通过 REST API 通信

第4个月：提取 restaurant-service + search-service
- 引入 Elasticsearch
- 搜索功能独立

第5个月：提取 delivery-service + kitchen-service
- 引入 Kafka 进行异步事件通信

第6个月：下线单体
- 所有功能迁移到微服务
- 关闭单体应用
- 建立完整的微服务运维体系