微服务拆分的三个火枪手原则 _微服务

服务粒度——“三个火枪手”原则三个火枪手原则就是一个微服务由三个人负责开发。一般来说，在进行微服务架构时，根据团队规模来划分微服务数量是合理的。
而为什么是3个人？？？？

从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；如果2个人开发一个系统，系统复杂度不够；如果4个人甚至更多人开发一个系统，系统复杂度又会无法让开发人员对系统的细节都了解很深。
从团队管理来说，3个人可以形成一个稳定的备份，即使1个人有事不在，2个人也可以支撑；如果2个人的话，少了一个人剩余的1个人压力就很大；如果是1个人就更惨了
从技术角度，3个人的技术小组能够形成有效的讨论，能快速达成一致意见；如果是2个人，可能会有意见无法统一问题；如果4个人或更多，就会出现有的成员不认真讨论，开会划水。

拆分方法

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

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

4. 基于性能拆分：将性能要求高或性能压力大的模块拆分出来，避免改模块的性能压力问题而影响其他服务。常见的拆分方式和具体的性能瓶颈有关，可以拆分web服务、数据库、缓存等。例如电商的抢购，性能压力大的是入口排队，可以将排队功能独立成一个服务
以上拆分方式可以根据实际情况自由组合，例如可以基于可靠性拆分出服务A，基于性能拆分出服务B，基于可扩展拆分出C/D/F服务等。
基础设施