微服务的灾难：拆的很爽，就是服务太小了……转载本文请联系脑筋急转弯公众号。大家好，我是炸鱼。我有一个好朋友小闲鱼。他们的组织初期是企业萌芽的初级阶段。在快速发展阶段，他们面临着软件开发周期的挑战。过去“强厚”的打石应用是他们应用架构的早期策略：但随着业务的不断发展，打石应用的痛点也非常明显。喜欢：难以部署和维护。频繁部署的障碍。不相关函数之间的依赖关系。难以尝试新技术/框架。这些痛点也在给他们的公司带来各种组织问题，而当代微服务的出现对软件工程师非常有吸引力，他们也随之转型。现代微服务架构正式走上微服务转型之路，一切从拆分开始：以往我们会将其Cache、DB等混合在legacy中。但是做微服务之后，我们会选择拆分成多个服务的方式，最终演化为：微服务拆分有以下几个粗略的基准：UI，静态内容组件化，解耦成为可独立部署的客户终端应用。定义好边界，服务要有更清晰、更明确的边界。职责单一，服务能力单一，数据库等独立的第三方依赖存储。Strangler模式在完成微服务改造的标杆定义后，大部分公司采用的是业界著名的“Strangler”模式。如下图所示：大多数考虑微服务的组织都是业务成熟的盈利组织。业务发展太快，才发现技术架构跟不上业务所需的迭代速度和周期，也不可能阻止业务的辛勤工作。结构。因此，业界基本采用向微服务迁移转型的渐进重构方式来实现“扼杀者”，偿还技术债。服务太少了。在微服务逐渐演进的过程中，我们会发现一个新的问题。虽然在微服务的规划中，会仔细深入地讨论服务的拆分，但是看起来还是觉得服务的拆分很酷，但是在后面的实战中，发现服务太少了。当N个人维护多个服务时，会出现“10个工程师组队维护60个服务，一个人负责一个服务不够”的情况。正当我以为这不是一个普遍的问题时，最近看到我的好朋友HHF（@HHFCodeRv）提到有人问他架构相关的问题。以下是咨询他的公司的Java架构师的结论。如下图所示：亮点是这两个后端的开发，其中一个还是架构师。结合实际情况，可能只有一个后端在工作。这可以称为1:17的人与服务的比例。每天轻砍IDE找服务可能要花好几倍……当然，应用上线前，会被拆分成多个服务。组成N个人维护自己数倍的服务数量是不合理的。这也是业内众多互联网公司需要思考和解决的问题。新功能属于谁？在实际业务场景中，有一个需求是“有人让我同时部署一个新功能到两个不同的服务”。因为这个新功能是ServiceA和ServiceB职责分工的所有者或部分所有者，所以新功能应该同时在两个服务中提供。这时候需要考虑以下几个问题：这个新功能是什么，具体的业务领域划分？为什么这两个服务存储共享这个新功能的可能性？这两项服务应该继续分离还是合并？随着新功能的出现，是否要拆解第三方服务？在真实的项目场景中，我们会按照预先确定的“契约”进行设计和开发。也就是说，在设计的时候，需要建立服务的上下文边界，进行约束和规范。当出现上述问题时，我们不得不思考：是服务职责不明确，还是拆分有偏差，还是业务领域发生了变化？我们需要尽快重新规划整体服务，定义新的上下文。不然以后越乱越乱，心里不舒服。总结在今天的文章中，我们介绍了单体应用和微服务架构的一些基本特性。同时也为大家展示了最常见的切换方式：绞杀模式。然后跟大家讨论了一个所有微服务演讲都不可避免会遇到的大问题：服务太小。服务太少，分两种情况：一开始就拆了，应用上线前就拆了60、70个服务，很痛快。开发的时候发现有新的业务领域，或者使用的时候有问题。经常一个功能，几个服务反复左右跳转，感觉应该放在一起。在这种情况下，我们需要区分这是人为问题还是设计问题（这一点很重要）。及时重新定义新的领域，为服务定义新的上下文，可以很好地解决一些问题。业务不断发展。要想做好，需要一个长期的阶段性回顾。但如果是人的问题，那就需要仔细想想了，毕竟康威定律。
