服务粒度
当团队实施微服务架构时，可以根据团队规模来划分微服务数量。一个团队约有 6 个人时，可以划分为 2 个微服务。随着业务的扩展和团队规模的增加（例如，扩展到 12 个人），可以将已有的 2 个微服务进一步细分为 4 个微服务。这种基于团队规模的微服务拆分方法，有助于管理复杂度，保持开发效率。
为什么是 3 个人，不是 4 个或者其他数量呢？
首先，3 个人负责一个系统，每个人都能够全面理解整个系统，同时又能够进行分工。如果是 2 个人，系统的复杂度不够，开发人员可能会感到技术上的挑战不够；如果是 4 个人或者更多，系统复杂度可能会导致开发人员无法全面了解系统的细节。
其次，3 个人形成一个稳定的备份，即使其中一个人休假或者调动到其他系统，剩余的 2 个人也可以支撑工作。如果是 2 个人，剩余的 1 个人可能承担过大压力；如果是 1 个人，团队就存在单点故障。
最后，3 个人的技术小组可以形成有效的讨论，快速达成一致意见。如果是 2 个人，可能会出现意见不一致的情况；如果是 1 个人，可能会陷入思维盲区；如果是 4 个人或者更多，可能会出现参与度不足的情况。
“三个火枪手”的原则主要适用于微服务设计和开发阶段。当微服务经过一段时间发展后，进入维护期，无需太多开发工作时，平均每个微服务维护 1 个人或者几个微服务都是可以接受的。然而，为了确保人员备份，最好安排每个微服务由 2 个人维护，每个人可以维护多个微服务。
拆分方法
基于业务逻辑拆分：这种方式是将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。但在实践过程中最常见的一个问题就是团队成员对于“职责范围”的理解差异很大，经常会出现争论，难以达成一致意见。
基于可扩展拆分：将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中。
基于可靠性拆分：将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。具体拆分的时候，核心服务可以是一个也可以是多个，只要最终的服务数量满足“三个火枪手”的原则就可以。
基于性能拆分：基于性能瓶颈将系统中的业务模块进行拆分，将性能要求高或者性能压力大的模块拆分为独立的服务。例如，电商系统中，抢购功能可能会导致性能瓶颈，可以将该功能独立为一个服务。
基础设施
大多数人关注微服务的“small”和“lightweight”特性，但实际上微服务的成败更多取决于被忽视的“automated”（自动化）方面。为什么这样说呢？因为即使服务粒度划分不合理，当团队遇到问题时，很自然地会考虑重新拆分或合并服务；但如果与“automated”相关的基础设施不健全，微服务就会成为一个坑，使得研发、测试和运维陷入各种微服务陷阱中。
微服务基础设施如下图所示：
图片
看到上面这张图，相信很多人都会倒吸一口凉气，说好的微服务的“轻量级”呢？都这么多基础设施还好意思说自己是“轻量级”，感觉比 ESB 还要复杂啊？
确实如此，微服务并不是很多人认为的那样简单和轻量级。要成功实施微服务，这些基础设施是必不可少的，否则微服务可能会成为一个难以摆脱的泥潭，使业务和团队陷入困境。因此，可以说微服务并没有减少复杂性，而是将复杂性从ESB（企业服务总线）转移到了基础设施上。你可以看到，“服务发现”、“服务路由”等实际上都是ESB的功能，只是在微服务中被剥离出来，成为了独立的基础系统。
虽然建设完善的微服务基础设施是一项庞大的工程，但不必因为团队规模较小或公司规模不大而放弃微服务的实施。首先，开源社区已经提供了一些成熟的微服务基础设施解决方案，比如知名的 Spring Cloud 项目，包含了服务发现、服务路由、网关、配置中心等功能。其次，如果微服务的数量不是很多，也并非每个基础设施都是必需的。因此，我建议按照以下优先级来搭建基础设施：
1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2. 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。
以上 3 和 4 两类基础设施，其重要性会随着微服务节点数量增加而越来越重要，但在微服务节点数量较少的时候，可以通过人工的方式支撑，虽然效率不高，但也基本能够顶住。
