阅读 81

SpringCloud微服务实战(4)-微服务中的服务拆分

1 微服务拆分的起点

1.1 如何拆分?

先明白起点和终点

  • 起点

既有架构的形态

  • 终点

好的架构不是设计出来的,而是进化而来的,一直在演进ing

单一应用架构=》垂直应用架构=》分布式服务架构=》流动计算架构

需要考虑的因素与坚持的原则

什么适合微服务

以下业务形态不适合:

  • 系统中包含很多很多强事务场景
  • 业务相对稳定,迭代周期长
  • 访问压力不大,可用性要求不高

康威定律

  • 沟通的问题会影响系统设计

Organizations which design systems are constrained toproduce designs which are copies of the communication structures of these organizations. 任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。

微服务的团队结构

  • 传统 V.S 微服务

2 服务拆分方法论

扩展立方模型( Scale Cube )

  • X轴水平复制、Z轴数据分区、Y轴功能解耦

如何拆“功能”

  • 单一职责、松耦合、高内聚
  • 关注点分离
    • 按职责
    • 按通用性
    • 按粒度级别

服务和数据的关系

  • 先考虑业务功能,再考虑数据
  • 无状态服务

  • 点餐业务服务拆分分析

3 商品服务编码实战

  • SQL

  • 项目初始化 pom 文件

web 和 webflux

旧版只有web一种模式,默认使用web。新版需指定,新增依赖 org.springframework.boot.spring-boot-starter-web

  • 为启动类添加该注解

开始单元测试

  • 编写测试类

  • 必须要有此二注解,否则NPE

开始实现第二个功能

  • 编码技巧,测试类可直接继承启动类的测试类,减少注解个数,做到最大可能的解耦

4 订单服务

  • SQL

  • sb 引用了 gson, 所以不需要指定版本

5 拆数据

如何拆“数据”?

  • 每个微服务都有单独的数据存储
  • 依据服务特点选择不同结构的数据库类型
  • 难点在确定边界
  • 针对边界设计API
  • 依据边界权衡数据冗余

相关源码

参考

文章分类
阅读
文章标签