多大的服务

“宜小不宜微”，不宜过大的单体，也不宜滥用微服务，应保持在合适的大小。
（ps. 这里只讨论服务的大小。不讨论服务的手段，拆分解耦、服务发现、mesh、告警、限流、全链路建设，都是好的实践，任何服务都可以做的同样好）
什么样的服务大小属于合理的服务？核心有两点，合理划分服务边界，匹配组织结构。

• 团队视角：服务的规模应该尽量限制在最小团队，约3人左右的团队为宜
  • ❎ 过大！跨团队修改同一服务，风险大且不利于基础建设。没有人对整体的架构和质量负责。没有人有全局视角，写代码因为不了解改动范围容易出故障。
  • ❎ 过大！10人以上的团队不宜修改同一服务。很可能服务定位不清晰，10个人的信息交流会有很多gap，效率会大大降低
  • ❎ 过小！团队每个人管三四个服务，说明服务数量过多，无用工作会增加，效率也会降低
• 业务视角：保证产品需求变更如果只在本团队内，修改的服务1-2个即可
  • ❎ 过小！改一个小小的功能，牵扯4-5个服务。服务太小了，效率降低
  • ❎ 过大！同时有四五个业务需求，对应数十个研发同时修改一个服务，而这些功能看起来并不密切。这说明服务包揽的功能太多了，已经膨胀的太大了

更微=更好?

我们以一个模块划分合理、大小合适的单体服务为例，看看如果拆分的更微小，对比起来会有哪些点值得关注：

微服务教

我们看下某网站对单体的批评，一一回应下：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
  • 确实，代码冲突会变多。但在单体内部模块划分合理的情况下，冲突的只会是公共模块；如果这些代码冲突了，使用微服务也会冲突。
• 代码维护难：代码功能耦合在一起，新人不知道何从下手
  • 耦合是模块设计的问题，不是单体的问题。而且单体断层更少，更容易阅读
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
  • 没发现编译时间有显著区别。部分单体仓库会编译多个产物，建议针对性编译，效果更好。
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
  • 绝对意义上，微服务存在同样的问题，而且更难定位。相对意义上，如果说单体的复用代码带来了问题风险的扩大，这属于因噎废食，不可取。
    微服务给我们带来了什么样的反思？拒绝盲目创新，提防吹牛皮但不切实际，小心滥用导致过犹不及。

再次回到起点：monorepo

有趣的是，越来越多人意识到了微服务的问题，最终又回归了单一的仓库，并发明了一新的词：monorepo。

Segment.com 提供活动收集和转发服务，每个客户都需要使用一种特殊格式的数据。因此，工程团队最初决定混合使用微服务和多代码库。这一策略效果很好——随着客户基数的增长，他们扩大了规模，没有出现问题。但是，当转发目的地的数量超过 100 个时，事情开始变得糟糕起来。维护、测试和部署超过 140 个代码库（每个代码库都有数百个日益分化的依赖关系）的管理负担太高了。最终，团队发现他们无法取得进展，三个全职工程师花费了大部分时间来维持系统的运行。
对于 Segment 来说，补救办法就是合并，将所有的服务和依赖迁移到一个单一代码库中。他们必须协调共享库并且测试所有内容，虽然花了很大的代价，但迁移非常成功，最终的结果是降低了复杂性，增加了可维护性。

每个团队的精力是有限的，当每个人管理的仓库>10个，团队管理的仓库>100个，会出现非常多的问题：

• 团队无法集中注意力管理。有很多的仓库大部分人并不知晓。这部分代码不再能被复用，也不再被了解
• 开发要打开很多IDE并发进行，容易出错。测试需要部署非常多的服务，也不能跨服务debug。发布时需要发布过多的仓库，发布容易遗漏；发布有很复杂的依赖，发布也会花费更久的时间。
• 无法发起整体性重构。重构一个服务和同时重构10个服务的难度不是一个级别。