一、背景：当传统单体架构成为业务发展的枷锁

三年前，我所在的电商团队面临一个艰难抉择：

• 订单系统与库存系统耦合严重，一个接口超时导致全站不可用
• 迭代周期从2周延长至1个月，测试环境冲突频发
• 运维同学每天需要手动重启3-5次服务

作为核心开发，我主动请缨带领3人小组启动微服务改造。这个决定让我经历了从CRUD工程师到架构师的蜕变，也踩过了无数技术深坑。

二、技术选型：在"潮流"与"实用"间寻找平衡

1. 服务拆分策略

• 初期错误：按业务部门垂直拆分（用户服务、订单服务...），导致跨服务调用复杂度激增
• 正确实践：采用DDD领域驱动设计，识别出12个核心聚合根
• 关键工具：使用PlantUML绘制领域模型图，通过事件风暴会议统一认知

2. 技术栈选择

维度	初期方案	踩坑后方案	收获
RPC框架	Dubbo 2.7.x	gRPC+自研注册中心	掌握服务发现核心原理
配置中心	Apollo	Nacos	理解CAP理论实际应用
网关	Spring Cloud Gateway	自研动态路由网关	深入Netty源码级优化

3. 基础设施演进

• 第1阶段：Jenkins+Shell脚本（日均构建失败15次）
• 第2阶段：GitLab CI+ArgoCD（实现金丝雀发布）
• 第3阶段：KubeVela+OAM规范（云原生标准化）

三、关键挑战与解决方案

1. 分布式事务噩梦

• 场景：订单创建需同时扣减库存和积分
• 错误尝试：
  • ❌ Seata AT模式（阻塞数据库连接池）
  • ❌ TCC模式（补偿逻辑复杂度指数级增长）
• 最终方案：

  java

  // 本地消息表+MQ最终一致性实现
  @Transactional
  public void createOrder(OrderDTO order) {
      // 1. 插入订单记录（状态=待确认）
      orderDao.insert(order);
      
      // 2. 插入消息记录到本地表
      messageDao.insert(new Message(
          "inventory.deduct", 
          JSON.toJSONString(order),
          MessageStatus.PENDING
      ));
      
      // 3. 发送确认事件到MQ
      eventPublisher.publish(new OrderCreatedEvent(order));
  }

2. 全链路监控体系搭建

• 踩坑记录：
  • 初期仅用Spring Boot Actuator（无法追踪跨服务调用）
  • 集成SkyWalking后发现OAP服务器内存溢出
• 优化方案：
  • 采样率动态调整：trace.sampling.rate=${env:SAMPLING_RATE:0.1}
  • 存储分离：Elasticsearch+MySQL冷热数据分离
  • 告警规则：P99 > 800ms OR error_rate > 1%

四、成长启示录

1. 技术决策的"3C原则"

• Context：明确当前业务阶段（我们初期拒绝K8s因运维成本过高）
• Cost：计算TCO（自研网关比商业版节省47万/年）
• Community：优先选择有活跃中文社区的技术（如Nacos而非Consul）

2. 架构师的三大能力模型

• 技术纵深：能手写Netty核心代码
• 业务理解：通过用户行为日志反推服务边界
• 沟通艺术：用"电梯演讲"向非技术人员解释CAP理论

3. 持续学习路径

• 书籍：《架构整洁之道》→《微服务设计》→《Kubernetes权威指南》
• 实践：从本地Docker Compose到混合云部署
• 认证：CKA（Kubernetes管理员认证）带来的系统级思维提升

五、未来展望

当前架构已支撑日均千万级订单，但新挑战接踵而至：

• 服务网格（Istio）的运维复杂度
• Serverless与微服务的融合实践
• 基于eBPF的可观测性增强