微服务拆分过细，过分强调"small"
微服务基础设施不健全，忽略了"automated"
微服务并不轻量级，规模大了后，"lightweight"不再适应
那么微服务最佳实践怎么去做呢？
服务粒度
微服务拆分粒度的“三个火枪手”原则，即一个微服务三个人负责开发。当我们在实施微服务架构时，根据团队规模来划分微服务数量，如果业务规继续发展，团队规模扩大，我们再将已有的微服务进行拆分。例如，团队最初有 6 个人，那么可以划分为 2 个微服务，随着业务的发展，业务功能越来越多，逻辑越来越复杂，团队扩展到 12 个人，那么我们可以将已有的 2 个微服务进行拆分，变成 4 个微服务。
整理如下：
【定义】
平均3个开发人员负责一个微服务。
【剖析】
1. 为什么不是1个？
因为没有备份，且一个人思维有局限。
2. 为什么不是2个？
• 因为异常情况下剩余1个，压力会很大；
• 2个人负责维护一个微服务，微服务复杂度偏低。
3. 为什么不是4个或者5个？
如果4个或4个以上，每个人不一定能掌握单个服务所有细节。
【技巧】
1. 微服务数量 = 服务端开发人数 /3 ；
2. 3 = 1 +2，1个有经验的(P7/P6+)，2个普通的(P5/P6)；
3. 处于维护期的服务，维护人员为2人
"三个火枪手"的原则主要应用于微服务设计和开发阶段，如果微服务经过一段时间发展后已经比较稳定，处于维护期了，无须太多的开发，那么平均 1 个人维护 1 个微服务甚至几个微服务都可以。当然考虑到人员备份问题，每个微服务最好都安排 2 个人维护，每个人都可以维护多个微服务。
拆分方法
1. 基于业务逻辑拆分
这是最常见的一种拆分方式，每个单独的业务模块拆分为一个独立的服务。
例如：假设我们做一个电商系统，第一种方式是将服务划分为“商品”“交易”“用户”3 个服务，第二种方式是划分为“商品”“订单”“支付”“发货”“买家”“卖家”6 个服务，哪种方式更合理，是不是划分越细越正确？
导致这种困惑的主要根因在于从业务的角度来拆分的话，规模粗和规模细都没有问题，因为拆分基础都是业务逻辑，要判断拆分粒度，不能从业务逻辑角度，而要根据前面介绍的“三个火枪手”的原则，计算一下大概的服务数量范围，然后再确定合适的“职责范围”，否则就可能出现划分过粗或者过细的情况，而且大部分情况下会出现过细的情况。
2. 基于可扩展拆分
将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中，例如将“日志服务”和“升级服务”放在同一个子系统中；不稳定的服务粒度可以细一些，但也不要太细，始终记住要控制服务的总数量。
这样拆分主要是为了提升项目快速迭代的效率，避免在开发的时候，不小心影响了已有的成熟功能导致线上问题。
3. 基于可靠性拆分
业务模块中将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。具体拆分的时候，核心服务可以是一个也可以是多个，只要最终的服务数量满足“三个火枪手”的原则就可以。
这样做的好处是：
避免非核心服务故障影响核心服务
核心服务高可用方案可以更简单
能够降低高可用成本
4. 基于性能拆分
基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。
常见的拆分方式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等。例如电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务。以上几种拆分方式不是多选一，而是可以根据实际情况自由排列组合，例如可以基于可靠性拆分出服务 A，基于性能拆分出服务 B，基于可扩展拆分出 C/D/F 三个服务，加上原有的服务 X，最后总共拆分出 6 个服务（A/B/C/D/F/X）。
总结：
基础设施
大部分人主要关注的是微服务的“small”和“lightweight”特性，但实际上真正决定微服务成败的，恰恰是那个被大部分人都忽略的“automated”。为何这样说呢？因为服务粒度即使划分不合理，实际落地后如果团队遇到麻烦，自然会想到拆服务或者合服务；如果“automated”相关的基础设施不健全，那微服务就是焦油坑，让研发、测试、运维陷入我上一期讲的各种微服务陷阱中。
微服务并不是很多人认为的那样又简单又轻量级。要做好微服务，这些基础设施都是必不可少的，否则微服务就会变成一个焦油坑，让业务和团队在里面不断挣扎且无法自拔。因此也可以说，微服务并没有减少复杂度，而只是将复杂度从 ESB 转移到了基础设施。
通常情况下，我建议按照下面优先级来搭建基础设施：
1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2. 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。
一般微服务基础设施优先级
【总结】
服务粒度
三个火枪手，一个服务三个人。好处包括：1）全面了解系统，2）相互形成备份，3）相互讨论。
拆分原则
1）基于业务逻辑 结合三个火枪手选择，计算服务数量，由此决定服务的职责范围。2）基于可扩展性 将成熟的和不变化的服务分为稳定服务，而将不成熟和变化的服务称为变化服。
3）基于可靠性 将业务模块按照优先级排序，将高可用的核心模块和不高可用的非核心模块分开，重点保证核心模块的高可用性。好处有a）让非核心业务不再影响核心业务，b）让核心业务变得更加简单，c）降低高可用成本
4）基于性能 类似于基于可靠性分析，将对性能要求高的和负载大的模块拆分出来，避免受其它业务影响。基础设施 包括四大块：
1）服务发现，服务路由，服务容错
2）接口框架，api网关
3）自动化部署，自动化测试，配置中心
4）服务监控，服务跟踪，服务安全。
在现有微服务上拆分上，之前并没有将研发人数跟服务数量很好地结合起来。三个火枪手的原则很实用。不用特别高大上，异常接地气。