1、微服务拆分的起点和终点
- 起点:既有架构的形态(将一个已有的架构转化为微服务架构)
- 终点:好的架构不是设计出来的,而是进化来的(一直在演进ing)
2、业务形态不适合微服务的
- 系统中包含很多强事务场景
- 业务相对稳定,迭代周期长
- 访问压力不大,可用性要求不高
3、康威定律
- 任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。(沟通的问题会影响系统的设计)
4、扩展立方模型
- X轴的伸缩:由负载均衡器后运行的多个拷贝构成。如果有N份拷贝,每份拷贝处理1/N的负载。
- Y轴的伸缩:Y轴伸缩将应用分成多份不同的服务,每份服务负责一个或多个紧密相关的功能。
- Z轴的伸缩:使用Z轴伸缩的话,每个服务器运行一份完全相同的代码,每个服务器只负责数据的一个子集。
5、服务拆分方法
服务拆分关键地方:功能和数据
1.拆功能
- 单一职责(每个服务只负责业务功能的一个单独的部分),松耦合(服务之间耦合度低,修改一个服务不用导致另一个服务跟着修改),高内聚(服务内部相关的行为都聚集在一个服务内,而不是分散在不同的服务中)
- 关注点分离:按职责(给服务进行分类,比如订单、商品等)、按通用性(一些基础组件,与具体的业务无关的也可划分成单独的服务,比如消息服务,用户服务)、按粒度级别(微服务并不是越小越好,这个比较难把握)
2.服务和数据的关系
- 先考虑拆分业务功能,再考虑拆分业务功能对应的数据。
- 无状态服务(一个数据需要被多个服务共享,才能完成一个请求,这个数据就可以称为状态。依赖这个状态数据的服务称为有状态服务,反之无状态服务):
3.如何拆数据
- 每个微服务都有单独的数据存储(一个服务的数据智能通过API来访问,服务之间数据是有隔离的)
- 依据服务特点,选择不同结构的数据库类型(依据服务的功能特点,选择合适的数据库)
- 难点在确定边界
- 针对边界设计API
- 依据边界权衡数据冗余