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

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

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

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

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

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

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

如下图：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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