微服务,服务粒度多少合适
项目服务化好处
- 复用性,消除代码拷贝
- 专注性,防止复杂性扩散
- 解耦合,消除公共库耦合
- 高质量,SQL稳定性有保障
- 易扩展,消除数据库解耦合
- 高效率,调用方研发效率提升
微服务拆分实现策略
- 统一服务层
- 一个子业务一个服务(最佳实践)
- 一个库一个服务
- 一个接口一个服务
微服务拆分以业务拆分优先:采用领域驱动设计(DDD)的限界上下文划分服务边界
实践场景类问题
-
问题:如何拆分单体系统?
- 识别核心业务链路(如电商的购物流程) 。
- 优先拆分高频变更模块(如促销服务)。
- 逐步演进,避免一次性过度拆分 。
-
问题:服务粒度如何权衡?
- 性能需求:RPC调用链控制在5ms内。
- 业务复杂度:避免跨服务事务。
技术实现类问题
-
问题:如何保证拆分后的数据一致性?
- Saga模式:拆分长事务为本地事务链。
- 最终一致性:通过消息队列(如RabbitMQ)异步同步。
-
问题:服务通信如何设计?
- 外部标准化:RESTful API
- 内部高性能通信:gRPC/Dubbo(二进制协议)。