"三个火枪手"原则：微服务粒度应按团队规模而非业务边界确定

针对[[微服务陷阱三：调用链变长带来的性能损耗与故障定位困难]]和[[微服务陷阱二：”微”字迷思导致团队规模与服务数量不匹配]]反映出的”过分强调small”问题，解法是按团队规模来定微服务拆分粒度，类似贝索斯”两个披萨”团队规模理论，作者提出”三个火枪手”原则：一个微服务由3个人负责开发。团队规模变化时，微服务数量应随之调整——比如团队最初6人，划2个微服务；业务发展、团队扩到12人后，再把已有2个微服务各自拆开，变成4个微服务。为什么恰好是3人而不是2人或4人？从系统复杂度匹配角度看，3人负责一个系统，复杂度刚好落在”每个人都能全面理解整个系统、又能有效分工”这个区间：2人开发的系统复杂度可能不够，开发者会觉得体现不出技术含量；4人及以上开发的系统复杂度又会超出每个人能深入掌握全部细节的范围。从团队管理角度看，3人能形成稳定的备份结构——1人休假或被抽调，剩下2人依然能支撑；如果是2人，抽走1个剩下1个压力就很大；如果只有1人，就是彻头彻尾的单点风险，这个人一旦休假、系统又出问题，团队将完全无从应对。从技术讨论质量角度看，3人小组既能形成有效讨论、又能较快达成一致：2人容易陷入各执己见的僵局，或者两人经验都不足直接导致设计缺陷；1人没有讨论对象，容易陷入思维盲区酿成重大问题；4人及以上，参与讨论的人里往往会有人只是应付了事、并没有真正投入。需要注意的是，”三个火枪手”原则主要用于微服务的设计和开发阶段；一旦某个微服务经过一段时间发展已经进入稳定的维护期、不再需要大量开发投入，就可以放宽到平均1人维护1个甚至多个微服务，只是出于人员备份考虑，最好给每个微服务安排至少2个人共同维护，每个人也可以同时维护多个微服务。