江苏龙网

  1. 主页 > 生活百科 > >

微服务是个坏主意吗？

微服务

作者丨Aphinya Dechalert
编译丨千山
曾几何时，我记得我的手指疯狂地敲打键盘，与庞大而杂乱的代码库搏斗 。那是巨石的时代，代码就像古老的城堡一样，由一块块石头砌成一个令人印象深刻的庞然大物 。
几年过去了 ， 时代变了 。开发人员口中的流行语变成了“微服务” 。微服务革命——承诺成为我们的救世主 。
我们被告知，通过将庞然大物分割成更小、自包含的独立服务 ， 我们将获得无与伦比的可扩展性、敏捷性和可维护性 。这听起来是如此完美 。
更快的部署？√
单独扩展？√
独立团队开发？√
但是，当我把单体架构切换成微服务时，我不禁想知道：微服务的魅力真的像它所描述的那样吗?还是只存在于远景的海市蜃楼 ， 只有当我们走近时才显露出它的挑战?
1、微服务的诱人承诺还记得我们不得不与多个团队协调只是为了进行微小的调整吗？传统的单体架构是后勤方面的噩梦 。
每次更改都需要理解代码库的大部分区域，与其他团队同步，并希望一个小的调整不会引发多米诺骨牌效应 。
但微服务打开了新大门：突然之间，团队可以独立开发他们的服务了 。
例如，用户管理团队可以实施新的身份验证策略 ， 而无需等待库存管理团队更新其产品列表方法 。这种解耦不仅仅是在代码层面，它还延伸到了团队动态 。
O'Reilly 的一项调查发现，采用微服务的组织在团队协作方面提高了63% 。每个开发人员都成为其领域的大师（从字面上看，考虑到领域驱动设计实践） 。
在我们之前的一个项目中，我记得“黑色星期五”大促销活动时引发的混乱 。我们的单体应用难以应对大量涌入的用户，导致所有功能的性能下降，而不仅仅是结帐流程 。
微服务很好地解决了这种不平衡的需求 。你只需简单地在负载下扩展服务 ， 而无需为整个应用程序过度配置资源 。
想结账的用户激增？没问题，扩大结帐服务规模 。
宣传视频病毒式传播？没问题 ， 提升媒体服务，不影响触及其他服务 。
思科的一项案例研究显示，使用相同数量的资源的情况下 ， 使用微服务架构设计的应用程序可以处理多达 20%的负载 。
2、不那么迷人的现实虽然许多人认为微服务是解决软件开发问题的灵丹妙药，但作为一名远程开发人员，我对这种架构风格的尝试经常感觉像打开了潘多拉的盒子 。
在虚拟茶水间的闲聊和一行行代码之外，这个故事总是充斥着无数希望、频繁的正面交锋以及相当多的启示 。
当我将我的第一个项目过渡到微服务时，我突然意识到，将一个应用程序拆分为多个服务并不是简单的“分而治之” 。
随着拆分而来的是管理这些离散服务的责任 。有一次，我部署了一个新的微服务，突然间 ， 系统的其他部分失去了对它的跟踪——这是分布式系统中服务发现（Service Discovery）的臭名昭著的挑战 。
此外，数据一致性也成为一场艰苦的战斗 。
我再也不能依靠单个数据库事务来确保一切正常 。因为每个服务都在管理自己的数据，我发现自己陷入了分布式事务的泥潭之中 。
然后是失败 。当一项服务失败时，连锁反应通常会导致其他服务发生级联故障 。
理论上让服务进行通信 ， 听起来很简单 。
但问题是：分布式系统引入了延迟 。
一天晚上，我正在调试一个异常缓慢的操作，却意识到罪魁祸首是服务之间的大量同步调用 。等待下一个请求的次数增加了 。
这需要改变战略 。
【微服务是个坏主意吗？】虽然通过事件进行异步通信减轻了一些痛苦 ， 但它也带来了挑战，例如确保事件的顺序 。
被吹捧的模块化承诺往往与性能相悖 。虽然微服务可以简化流程，但与传统的单体应用相比 ， 它们也可能导致通信延迟 。
3、噩梦循环：部署混乱作为 CI/CD 的坚定倡导者，部署单个服务的承诺感觉就像一个梦 。
但现实很不一样 。最初的几天尤其混乱 。
使用多个管道时，一个服务中的更改有时需要与其他服务进行协调 。还记得你每天都为之头疼的版本兼容性问题吗?有了微服务 ， 跟踪哪个版本的服务A与服务B兼容成为了一种日常仪式 。
4、我开始怀念单体架构了带有一系列服务和数据库阵列的微服务，常常感觉就像一块不断移动的拼图 。有很多个晚上，我发现自己由于无法预见的集成问题而恢复代码 ， 或者梳理日志试图找到哪个服务是薄弱环节 。


推荐阅读


上一篇：如何使用Python构建OTP验证系统？

下一篇：LangChain实战：大语言模型理解代码库