微服务架构

微服务架构下，Saga与TCC是解决分布式事务一致性的核心方案。Saga通过本地事务序列及逆序补偿实现最终一致性，吞吐量高且侵入性小，适用于长链路、容忍中间状态的场景。TCC通过Try-Confirm-Cancel三阶段预留资源，一致性更强，适用于资金转账等高价值短流程，但开发复杂度高。选型应基于业务容忍度、流程长度及团队能力，在落地时需重点处理幂等、空回滚与防悬挂问题。

从单体架构迁移至微服务时，配置管理常因散乱而成为风险点。平稳迁移需经过五个关键步骤：首先全面盘点配置项并分类清理；其次根据动态推送、治理能力及生态匹配度选型配置中心；第三设计合理的命名空间与权限模型以实现环境隔离；第四通过引入访问抽象，按服务逐个灰度切换并支持双读回退；最后建立覆盖可用性与审计的监控体系及多层级回滚预案。

gRPC与RESTful API在微服务通信中各有侧重。gRPC基于HTTP/2和protobuf二进制序列化，数据体积比JSON小30%~70%，在内部高频调用、低延迟及流式传输场景中性能占优。RESTful API则凭借HTTP/JSON的通用性，在对外公开接口、前端调用及调试便捷性方面具有显著优势。建议内部核心服务采用gRPC，外部入口层使用RESTful，以兼顾性能与兼容性。

服务拆分的关键不在服务数量，而在边界划在哪里：拆分的本质是隔离变化、隔离数据、隔离故障。判断边界是否成立的三个维度是变更频率、数据归属和故障隔离，需依次盘点模块痛点、绘制变更图和表级读写图、列故障场景，三者都支持才值得拆。过早拆分和高成本的组织硬切都是常见误判，应增量试点，先验证团队能力再决定是否继续。

微服务下CI/CD关键在依赖与版本管理。每服务独立流水线，可重复构建，分层测试并强化契约测试。依赖用语义化版本，接口只增不减，数据库先扩后收。按风险选滚动、金丝雀或蓝绿部署。特性开关分离部署与发布，自动回滚须演练且向后兼容。落地先标准化流水线与版本，再补契约测试和依赖图，最后上金丝雀与自动回滚。