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