⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://mubu.com/doc/7CxiBTch0G 「hoxis」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

什么时候进行服务化拆分?

  • 项目第一阶段的主要目标是快速开发和验证想法,证明产品思路是否可行。
  • 这个阶段功能设计一般不会太复杂,开发采取快速迭代的方式,架构也不适合过度设计。
  • 接着,大规模地扩张开发人员,以支撑多个功能的开发;
  • 一旦单体应用同时进行开发的人员超过 10 人这个时候就该考虑进行服务化拆分了。

服务化拆分的两种姿势

  • 纵向拆分,是从业务维度进行拆分。按照业务的关联程度来决定。
  • 横向拆分,是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立不与其他业务耦合。

服务化拆分的前置条件

  • 服务如何定义。服务之间的调用都通过接口描述来约定,约定内容包括接口名、接口参数以及接口返回值。
  • 服务如何发布和订阅。注册中心,记录每个服务提供者的地址以供服务调用者查询
  • 服务如何监控。需要通用的监控方案,能够覆盖业务埋点、数据收集、数据处理,最后到数据展示的全链路功能。
  • 服务如何治理。熔断
  • 故障如何定位。将一次请求进行标记,并在多个依赖的服务系统中继续传递,以便串联所有路径,从而进行故障定位。

总结

  • 过度的拆分反而会让服务数量膨胀变得难以管理
  • 找到符合自己业务现状和团队人员技术水平的拆分粒度才是可取的。
  • 我建议的标准是按照每个开发人员负责不超过 3 个大的服务为标准
文章目录
  1. 1. 什么时候进行服务化拆分?
  2. 2. 服务化拆分的两种姿势
  3. 3. 服务化拆分的前置条件
  4. 4. 总结