大家好,我是煎鱼。

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

过去的巨石应用

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

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

  • 难以部署和维护。
  • 频繁部署的障碍。
  • 不相关的功能之间的依赖性。
  • 难以尝试新的技术/框架。

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

现代的微服务架构

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

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

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

  • UI、静态内容组件化,解耦出来成为可独立部署的客户端应用。
  • 定义边界,服务要有较为明确清洗的边界。
  • 单一职责,服务的能力要单一,数据库等第三方依赖存储要独立。

绞杀者模式

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

如下图:

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

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

服务太小

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

N 人维护数倍服务

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

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

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

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

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

新功能归属谁

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

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

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

  • 这个新功能是什么,具体的业务领域划分?
  • 为什么这两个服务会存储共享这一个新功能的可能?
  • 这两个服务,是否应该继续拆开,要不要合并?
  • 由于新功能的出现,是不是应该拆出第三个服务?

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

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

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

总结

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

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

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

  • 起步上来就一顿拆,应用还没上线就拆出来 60,70 个服务,拆的很开心。
  • 发展时发现有新业务领域,又或是用的时候不对劲。频繁一块功能,好几个服务左右反复横跳,感觉应该在一块。

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

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