一个团队多少个微服务合适?

文章《少个分号》由公众号DDD和微服务发布，讨论了当前软件开发中微服务架构的挑战与维护问题。作者通过个人经历和行业观察指出，随着微服务的普及，一个开发者可能需要管理多个代码仓库，而这对于团队规模较小的项目尤其成为一个问题。

作者提到，过去常见的是多人协作在一个大型代码库上工作，但现在趋势已经转变为一个人需要处理多个微服务的代码库。这种转变对硬件配置和开发者的认知能力都提出了更高的要求。作者认为，虽然微服务在处理复杂系统和大团队时是合理的，但许多项目在微服务的边界和职责划分上并不明确，导致开发者在本地开发时不得不启动和修改多个服务，增加了认知负担。

针对微服务架构带来的认知负担问题，作者提出了一个衡量认知负担的公式。公式考虑了团队人数、人均服务维护量以及服务数量，通过对数运算得到一个“认知商”，以此衡量团队的压力。当认知商接近零时，表明没有认知负担；认知商为正表示过多人员维护一个服务，为负则表示服务过多。作者建议，认知商绝对值在0-1之间为安全，超过1则需要警惕。

最后，作者总结了“六个一原则”，来指导微服务的合理划分：每个服务由一个小团队维护、有明确职责、对应一个代码仓库、有对应的部署单元和配置、拥有一个数据库（如有必要）、以及对应一条流水线。这些原则旨在明确服务的责任、权限和职责边界，确保微服务的合理性。