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
- 依据边界权衡数据冗余
相关源码
参考
