小团队中微服务的可怕之处

2021年6月11日 283点热度 0人点赞 0条评论
图片
作者 | Manuel Reinfurt
译者 | Sambodhi
策划 | Tina

本文最初发表于 Medium 博客,经原作者 Manuel Reinfurt 授权,InfoQ 中文站翻译并分享。

微服务听起来很棒,每一个团队可以彼此独立工作而不影响其他团队。你可以轻松地维护和扩展微服务。你也可以在同一项目中使用不同的技术。它们如此稳定,所以,你的产品会有极好的扩展。在 2021 年,不应该把任何应用作为单体来构建,对吧?

很遗憾,微服务并非在每一种环境下都可以发挥作用,在盲目使用之前,你必须确定它们提供了你所需要的价值。我见过几个典型的项目,有 4~6 名开发者,基本上是一个团队。客户想要构建微服务的应用程序,因为它们非常棒。IT 经理同意了,于是团队开始设计应用程序。

用户管理?是的,这是一个微服务。访问权限管理?也是微服务。管理和预约?同样是微服务!通过连接到几个第三方 API 来管理和发送订单?这绝对是一个微服务。不错,现在每个人都可以得到一个微服务了!有时候你可能会违反物理学法则,每个人都有多个微服务。

恐怖开始

当你开始这个伟大的旅程时,你的团队需要确保每一个微服务都可以独立开发。每一个微服务都有它自己的 CI/CD 管道,自己的数据库和自己的版本化 API。

现在,在启动一个新项目时,你可能只有一个团队。将在同一个团队中构建所有这些微服务。这种情况经常发生:一个人为了实现一个新功能而承担多个微服务。让我们就叫她 Ellie 吧。Ellie 需要在任何地方进行一些调整,同时进行测试。当她遇到问题时,她可以开始对两个微服务进行并行调试,以尝试了解它们之间的通信。如果它实际上是应用程序的一部分,那么 Ellie 就拥有一个更简单的工作环境,并且可以直接在应用程序中进行调试。此外,她还不需要为这些微服务之间的分布式、可能是异步通信编写大量定义和代码。

之后,你的应用程序的第一个版本将提供给你的客户。当你更新应用程序并尝试开始滚动更新时,你将面临在某一时间内运行微服务的多个版本。要么它们都与其他版本兼容(这也需要在开发过程中进行一些工作),要么你需要以某种方式优雅地更新它们。

在最坏的情况下,你正在构建一个分布式的单体应用。而且,在你的小团队里,你会发现微服务的所有缺点,但是很可能并没有从这些中获益。

微服务的亮点在哪里?

亚马逊和 Netflix 是最早提到他们使用微服务的大公司之一,他们解释了微服务为何如此有用。亚马逊提出了两个披萨原则,并表示:“如果两个披萨不足以喂饱一个项目团队,那么这个团队可能就显得太大了”。每个团队都应该有自己的微服务,它绝不应该在两个团队之间分割。要获得完全的所有权,团队必须对其组件及其相关的所有东西拥有完全的控制权。

在单体应用中管理代码和依赖项,面对庞大的软件和数百人的工作,是相当麻烦的。因为微服务与其他所有东西解耦,这是一个完美的方法,可以扩展开发团队的数量。他们可以在自己的微服务上工作,使用已经构建的 API,并扩展现有产品。他们无须与其他 80 个团队中的每个决策保持一致,而且他们可能不必选择相同的技术或保持版本一致。

微服务对于管理大型软件来说并不是必需的,而是管理大量使用这些软件的人。
我现在该怎么办?

但这并不意味着微服务就会陷入混乱。但是,我要你真正思考微服务对你的意义,以及你是否能从中获益。当然,它们可以为你提供许多好处,但同时也增加了许多复杂性。假如这些好处对你无关紧要,你就可以跳过它们。

一个很好的软件开发范式是保持简单。既然可以简单地实现相同的结果,为什么还要选择更复杂的方式呢?你只会让它变得更难理解,以后也更难改变。

微服务同样如此。既然你的团队必须处理所有微服务,并完全控制应用程序,为何还要增加微服务的复杂性?你的产品可能会增长,但是两周内它并不会成为下一个 Netflix。就像俗话所说的:“过早的优化是万恶之源”,所以不要急着优化!

相反,享受一个相当单一的应用程序的好处。尽情享用更快的开发速度,因为你不需要担心改进微服务间的通信,不需要花费更多时间调试和测试微服务间共享通用代码的意义,不需要尝试协调复杂的分阶段微服务发布,甚至不需要在每个微服务上处理巨大的 docker 映像大小和内存需求,因为你正在使用 Spring Boot。

图片

你也不需要全心致力于单体或微服务。你仍可以将应用程序划分为有意义的部分 —— 甚至遵循领域驱动设计的指导原则。有了合适的架构,你的代码和模块仍然可以被恰当地解耦,并且你的应用程序符合 12 要素原则。可以在相同的应用程序中运行这些模块,可以共享相同的构建管道,只需部署一个版本即可进行部署。

但我如何扩大规模呢?

你发布了你的产品,而且非常成功。你希望构建更多功能并适当地扩展。你雇佣并组建了多个开发团队,你是否真的从微服务中获益?现在正是将你的应用拆分到微服务的绝佳时机。

若你的应用程序构建正确,且不同模块已经解耦并易于理解,则拆分它们应该不会太困难。是啊,得费点功工夫。当然,你可以从一开始就直接使用微服务来避免这个问题。但是在这种情况下,你也必须从一开始就直接处理复杂的事情,并且拖拖拉拉。

保证在适当的时候选择合适的架构并且保持简单。关注代码架构和质量。

作者介绍:
Manuel Reinfurt,InCloud 首席技术官。负责技术领导与新工作。精通 Azure、.NET/C#、云计算开发。
原文链接:
https://medium.com/incloud-hq/the-horror-of-microservices-in-small-teams-208f6660dd5
本周好文推荐

维护开源项目太难了,Redis之父:只做自己想做的

误泄露公司代码、疫情期间被裁,一个“菜鸟”程序员的生存日记

小小技术“障眼法”,思科、微软和联想被骗超350万美元

我们4个人做了一款年入百万美元的邮件客户端


InfoQ 读者交流群上线啦!各位小伙伴可以扫描下方二维码,添加 InfoQ 小助手,回复关键字“进群”申请入群。回复“资料”,获取资料包传送门,注册 InfoQ 网站后,可以任意领取一门极客时间课程,免费滴!大家可以和 InfoQ 读者一起畅所欲言,和编辑们零距离接触,超值的技术礼包等你领取,还有超值活动等你参加,快来加入我们吧!

图片

图片

点个在看少个 bug ?

17810小团队中微服务的可怕之处

root

这个人很懒,什么都没留下

文章评论