![[架构]单体和微服务](http://chestnutheng.github.io/logo.png){kind=logo}
[架构]单体和微服务
内容提要
合理的服务大小应保持在合适的范围内，不宜过大也不宜过小。团队视角下，服务规模应限制在最小团队，避免跨团队修改同一服务。业务视角下，保证产品需求变更只在本团队内修改的服务数量应为1-2个。拆分微服务会带来性能、复用性、可读性等方面的影响。微服务的盲目创新和滥用应引起警惕。Segment.com的案例表明，当微服务和多代码库的管理负担过大时，合并到单一代码库可以降低复杂性，增加可维护性。团队管理过多的仓库会导致问题增多。
延伸解读
服务大小的双重判断标准
文章从团队和业务两个视角给出了服务大小的具体判断标准。团队视角下，服务规模应限制在最小团队（约3人），避免跨团队修改同一服务，10人以上团队不宜修改同一服务，而每人管三四个服务则说明服务过小。业务视角下，产品需求变更只在本团队内修改的服务数量应为1-2个，若一个小功能牵扯4-5个服务则服务过小，若数十人同时修改一个服务则服务过大。这些标准为评估服务划分是否合理提供了可操作的参考。
拆分微服务的隐性成本
文章通过对比合理单体与更微服务，揭示了拆分带来的隐性成本。性能上，微服务可能带来数毫秒的劣化；复用性上，无法直接引用其他仓库代码，但也避免了复用bug；可读性上，需要跨多个仓库，层次深，理解困难；研发和部署成本也显著增加，需要多仓库并行操作和多台机器。这些成本在拆分前往往被低估，需要谨慎权衡。
对常见微服务批评的再思考
文章回应了某网站对单体的批评，指出许多问题并非单体独有。例如，代码冲突在单体中可通过合理模块划分限制在公共模块，微服务同样会冲突；代码维护难是模块设计问题，单体断层更少更易阅读；部署不灵活可通过针对性编译缓解；稳定性问题微服务同样存在且更难定位。这些回应提醒读者，微服务并非解决所有问题的银弹，盲目创新可能适得其反。
从微服务回归monorepo的启示
Segment.com的案例表明，当微服务和多代码库的管理负担过大时，合并到单一代码库可以降低复杂性、增加可维护性。他们维护超过140个代码库，三个全职工程师大部分时间用于维持系统运行，最终通过迁移到单一代码库成功解决问题。文章还指出，当每人管理仓库>10个、团队管理仓库>100个时，会出现非常多的问题。这提示团队需警惕微服务滥用带来的管理负担，适时回归monorepo。
Q&A
什么是合理的服务大小？
合理的服务大小应保持在合适的范围内，不宜过大也不宜过小，团队规模应限制在最小团队，避免跨团队修改同一服务。
微服务的盲目创新可能带来什么风险？
微服务的盲目创新和滥用可能导致管理复杂性增加，降低可维护性，甚至影响系统的稳定性。
Segment.com是如何解决微服务管理问题的？
Segment.com通过将所有服务和依赖合并到一个单一代码库中，成功降低了复杂性并增加了可维护性。
拆分微服务对性能和可读性有什么影响？
拆分微服务可能导致性能劣化和可读性降低，因为需要跨多个仓库查找代码，增加了理解的难度。
团队管理过多仓库会导致什么问题？
团队管理过多的仓库会导致问题增多，降低效率，增加沟通成本和管理负担。
如何确保服务的规模适合团队结构？
服务的规模应与团队结构匹配，确保每个团队负责1-2个服务，避免过多的跨团队修改。
