[架构]单体和微服务

合理的服务大小应保持在合适的范围内，不宜过大也不宜过小。团队视角下，服务规模应限制在最小团队，避免跨团队修改同一服务。业务视角下，保证产品需求变更只在本团队内修改的服务数量应为1-2个。拆分微服务会带来性能、复用性、可读性等方面的影响。微服务的盲目创新和滥用应引起警惕。Segment.com的案例表明，当微服务和多代码库的管理负担过大时，合并到单一代码库可以降低复杂性，增加可维护性。团队管理过多的仓库会导致问题增多。