概述
只有在拆分确实能带来收益时，我们才拆分单体——通常是团队相互阻塞，或组件的扩展需求差异很大。若拆分无益，我们会直说：微服务转移复杂度，并不消除复杂度。
核心优势
按真实边界拆分
服务遵循业务领域，而不是组织架构图。否则得到的是分布式单体，两边的缺点都占齐了。
第一天就具备可观测性
分布式追踪、可关联的日志、按服务划分的指标，在首次上线之前就已就位。
只扩容真正需要的部分
支付与报表各自独立获得资源，而不是一起扩容。
我们的工作方式
- 01
需求梳理
在提出任何方案之前，先厘清现有系统、约束条件和业务目标。
- 02
架构设计
设计系统结构、数据模型与集成点。决策形成文档，而非临场发挥。
- 03
开发实施
以短迭代交付，代码经过评审，预发布环境随时可查看。
- 04
测试与质量
每次发布前完成自动化测试以及性能与安全检查。
- 05
上线与支持
带回滚方案上线，之后持续监控与迭代。
技术栈
DockerKubernetesRabbitMQgRPCKafkaTraefikOpenTelemetry
应用场景
每次发布都互相阻塞的团队
多个团队共用一条部署流水线，只能排队等待。
单一功能上的流量高峰
图像处理或报表生成挤占了应用其余部分的资源。
并购之后的系统整合
两个产品需要表现得像一个，又不必完全合并代码。