《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》

摘要: 原创出处 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. 总结