大家好，我是煎鱼。

我有一个好朋友小咸鱼，他们组织早期是业务萌芽的初期，在快速发展阶段，面临着软件开发周期的挑战。

过去的巨石应用

这 “强大又厚实” 的巨石应用是他们应用架构上的一个早期策略：

但随着业务的持续发展，巨石应用的痛点也非常明确。像是：

• 难以部署和维护。

• 频繁部署的障碍。

• 不相关的功能之间的依赖性。

• 难以尝试新的技术/框架。

这些痛点也正给他们公司带来各种各样的组织问题，而当代微服务的横空出世，对软件工程师很有吸引力，他们也就转型了。

现代的微服务架构

正式迈向了微服务转型之路，一切先从拆分开始：

在以往的大单体中，我们会将其 Cache、DB 等混合在遗爱。但在做微服务后，我们会选用拆成多个服务的方式，最终演变成：

微服务拆分有以下几种粗的基准：

• UI、静态内容组件化，解耦出来成为可独立部署的客户端应用。

• 定义边界，服务要有较为明确清洗的边界。

• 单一职责，服务的能力要单一，数据库等第三方依赖存储要独立。

绞杀者模式

在完成微服务改造的基准的定义后，绝大部分公司都是采取业界中比较著名的 “绞杀者” 模式。

如下图：

由于会考虑微服务的组织，大多都是有成熟业务的盈利组织了，业务发展太迅猛，才发现技术架构跟不上业务要求的迭代速度和周期，不大可能停下业务硬重构。

因此业内基本采取边迁移，边改造为微服务的渐进式重构的方式，实现 “绞杀者”，把技术债务给偿还了。

服务太小

在微服务逐步的演进过程中，我们就会发现一个新的问题。虽然在微服务做规划时，都会很认真的对服务的拆分进行深入研讨，但还是出现了服务拆的很爽，但后面实战的时候发现服务太小了。

N 人维护数倍服务

出现了 “10 名工程师组成了维护 60 项服务的小组。一人负责一个服务还不够用” 的情况。

正当以为这不是常见问题时，最近看到我的好朋友 HHF(@HHFCodeRv)提到有人向他咨询架构相关的问题。

下面是咨询他的公司的 Java 架构师落地的方案。如下图：

亮点是这 2 个后端开发，其中一个还是架构师。结合实际情况，可能只有 1 个后端在干活。这堪称 1:17 的人和服务的配比量，每天光切 IDE 找服务可能就得好几东...

当然，应用还没上线，就拆成数倍的服务。形成 N 个人维护其自身数量的数倍服务，不大合理。这也是业内很多互联网公司需要思考和解决的问题。

新功能归属谁

在实际的业务场景中，出现了 “有人要求我把一个新功能同时部署到两个不同服务之中” 的诉求。

因为这个新功能同时是 ServiceA 和 ServiceB 这两个服务的职责划分的所有者或者部分所有者，所以新功能理应同时在这两个服务都要有所提供。

这时候需要考虑以下问题：

• 这个新功能是什么，具体的业务领域划分?

• 为什么这两个服务会存储共享这一个新功能的可能?

• 这两个服务，是否应该继续拆开，要不要合并?

• 由于新功能的出现，是不是应该拆出第三个服务?

在真实的项目场景中，我们会按照事前定的 “契约” 进行设计和开发。也就是在设计时，就要针对服务的上下文边界确立好，做好约束和规范。

出现上面这些问题，我们要想想：是不是服务的职责不清晰还是拆分有偏差，又或是业务领域改变了?。

我们要尽快对整体的服务做一个再规划，界定新的上下文。否则，以后会越来越乱，有好受的。

总结

在今天的文章中，我们介绍了巨石应用和微服务架构的一些基本特性。同时也给大家展示了，最常见的切换方式：绞杀者模式。

随后和大家探讨了所有微服务演讲中，都必然会碰到的一个大问题：服务太小。

服务太小又分为两种情况：

• 起步上来就一顿拆，应用还没上线就拆出来 60，70 个服务，拆的很开心。

• 发展时发现有新业务领域，又或是用的时候不对劲。频繁一块功能，好几个服务左右反复横跳，感觉应该在一块。

这种情况下，我们需要分清楚，这是人，还是设计上的问题(这很重要)。及时重新界定新的领域，面向服务做好新的上下文界定，能够适当的解决部分问题。

业务是在持续发展的，若要做好，要长期的阶段性复盘。但若是人的问题，那就需要好好思考了，毕竟康威定律。