微服务拆分

服务粒度——“三个火枪手”原则

三个火枪手原则就是一个微服务由三个人负责开发。一般来说，在进行微服务架构时，根据团队规模来划分微服务数量是合理的。

而为什么是3个人？？？？

1. 从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；如果2个人开发一个系统，系统复杂度不够；如果4个人甚至更多人开发一个系统，系统复杂度又会无法让开发人员对系统的细节都了解很深。

2. 从团队管理来说，3个人可以形成一个稳定的备份，即使1个人有事不在，2个人也可以支撑；如果2个人的话，少了一个人剩余的1个人压力就很大；如果是1个人就更惨了

3. 从技术角度，3个人的技术小组能够形成有效的讨论，能快速达成一致意见；如果是2个人，可能会有意见无法统一问题；如果4个人或更多，就会出现有的成员不认真讨论，开会划水。

拆分方法

1. 基于业务逻辑拆分：最常见的拆分方式，将系统中的业务模块按照职责范围识别出，每个业务模块拆分为一个独立的服务。但是，每个人对职责范围的理解不一样，如：电商系统中，可以分为“商品”“交易”“用户”3个服务，也可以分为“商品”，“订单”，“支付”，“买家”，“卖家”，“发货”6个服务
2. 基于可拓展拆分：将系统中的业务模块按照稳定性排序，将成熟的和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。稳定服务的颗粒度可以粗一些（及时是逻辑上没有强关联的服务，也可以放在同一个子系统中）；不稳定的服务可以划分的细一些（控制数量，参考三个火枪手原则）。这样拆分还有个好处是避免开发时不小心影响了成熟的功能。
3. 基于可靠性拆分：将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。好处

• 避免非核心服务故障影响核心服务。日志功能属于非核心服务，将其拆分出来，及时日志系统出问题，也不影响核心服务
• 核心服务高可用方案可以更简单。核心服务的功能逻辑将变简单，且存储的数据可能更少，用到的组件也会更少明科技高可用方案要简单。
• 降低高可用方案成本。如上一条所讲，将核心服务拆分后，功能逻辑将变简单、存储的数据更少。。。带来的核心服务占用的机器、带宽等资源将减少。

1. 基于性能拆分：将性能要求高或性能压力大的模块拆分出来，避免改模块的性能压力问题而影响其他服务。常见的拆分方式和具体的性能瓶颈有关，可以拆分web服务、数据库、缓存等。例如电商的抢购，性能压力大的是入口排队，可以将排队功能独立成一个服务

以上拆分方式可以根据实际情况自由组合，例如可以基于可靠性拆分出服务A，基于性能拆分出服务B，基于可扩展拆分出C/D/F服务等。

基础设施

如图，为微服务的基础设施

微服务所带来的快速开发，这是建立在有良好的基础设施上，换句话说，没有自动测试、自动化部署等等等等支持，当服务拆分的越来越多的时候，也就是所有开发同学、运维同学、测试同学崩溃的时候

通常情况下，一个公司或团队要实施微服务，可以从如下优先级开始：

1. 服务发现、服务路由、服务容错：这些是最最基本的：）
2. 接口框架、API网关：主要是为了提高开发效率，接口框架是提升内部服务的开发效率、API网关是为了提升与外部服务对接的效率
3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率
4. 服务监控、服务跟踪、服务安全：提升运维效率