停止盲目使用微服务

2022 年 2 月 27 日 InfoQ

作者 | GreekDataGuy
译者 | Sambodhi
策划 | 辛晓亮

为什么大多数公司最好要避免使用微服务呢?微服务看起来是一种很好的解决方案。从理论上讲,微服务可以加快开发速度,同时允许你独立扩展应用程序的不同部分。但在现实中,微服务是有隐藏成本的。也就是说,我认为,在没有亲自构建微服务之前,你不可能理解它们有多复杂。

下面是我在构建微服务(有时是失败的)时所学到的经验心得。

管理数据是一场噩梦

保持微服务间的数据同步可能是一项挑战。

每个微服务都有一个数据库,这是推荐的模式。它允许松散的耦合,并且可以让特定服务团队在无需放慢速度协作共享代码的情况下,独立地工作。但如果本应同步启动的微服务中的一个出现故障时,会发生什么呢?比如,其中一个微服务更新了其数据库,而另外一个却没有。这种情形会导致数据不一致。

根据个人的经验,调查跨服务的数据不一致会非常痛苦。错误的跨服务性质需要一个人在不同的服务中工作来修正错误。遗憾的是,这就导致了微服务的优势,即专门针对团队的服务,无法发挥作用。

在一个单体应用中,只要把两个数据库调用合并到一个原子事务中,就能很容易地避免这种情况,因此,所有的插入都会成功,或者都不会成功。非常的简单。但是,松散的藕合会使微服务变得更为难以实现。

设置时间更长

构建一个微服务架构所花费的时间要比将相同的特性整合到一个单体应用中要多得多。尽管单个服务是非常简单的,但是交互的服务集合要远比单一的单体更加复杂。在一个单体中,一个函数可以调用任何其他公共函数。但是,微服务中的函数仅限于调用同一个微服务中的函数。这就需要服务之间的通信。构建 API 或者消息传递来促进这一点并不容易。而且,跨微服务的代码重复也是不可避免的。当一个单体应用可以一次定义一个模块并多次导入,而微服务是它自己的应用:在每一个模块都必须定义模块和库。

微服务最适合大型团队

将微服务分派到各个团队的奢侈做法是留给大型工程部门。尽管这对这个架构来说是一个很大的优势,但是如果你拥有足够的工程师来为每一项服务指定一些工程师,那么这才是可行的。减少代码范围,可以让开发人员对代码有更好的理解,加快开发的速度。但是,大部分的初创公司都没有这样的奢侈。在一个创业早期的公司,由于缺乏足够的资源,有些工程师必须在所有的服务之间工作。遗憾的是,这样做会降低工作效率,因为在不同的应用中跳跃,可能会导致环境的变化。我发现,在我已经很久没有关注的微服务中调查 Bug,是一件非常令人筋疲力尽的事情。

DevOps 更复杂

选择微服务最有说服力的一个原因就是可以在不同类型的服务器上运行不同的服务。这是为什么呢?React 前端的内存、CPU 和启动时间的需求与训练机器学习模型的服务大相径庭。为每一项服务选择适当的基础架构类型,可以极大地减少费用。但是,这也给自己带来了一个挑战。

举个例子,在我的职业生涯初期,由于忘记重启一个更新过代码的服务,导致我丢失了大量的生产数据。过期的代码会通过 API 来接收数据,却没有把数据存入数据库,反而消无声息地失败。这样的数据就会永远丢失了。

我之所以提出这一点,是想要表明,配置、维护和监控多个微服务,要比单一的单体应用要复杂得多。拥有多个应用程序,还为骇客增加了多个攻击面。

从理论上讲,“松散耦合”的服务允许每个服务在其他服务失败时继续工作。但这只是一厢情愿的想法:对于有客户的复杂业务来说,很难实现真正的松散耦合。

最终,你的应用程序架构的可靠程度取决于最薄弱的部分。移动的碎片越多,出错的可能性就越大。

总    结

许多公司使用微服务并不是真正需要它们,而且尽管微服务现在很流行,但它们并不适合初学者。大多数公司最好的做法是构建一个单体,然后在绝对必要的时候将单体的部分拆分到微服务中。

把从头开始的微服务架构的机会留给那些财力雄厚的大型科技公司。

你的早期阶段的创业公司也许还没有准备好。我的公司就没有准备好,结果,让我们付出了大量的时间和精力。

作者介绍:

GreekDataGuy,开发者。

原文链接

https://betterprogramming.pub/stop-using-microservices-build-monoliths-instead-9eac180ac908

点击底部阅读原文访问 InfoQ 官网,获取更多精彩内容!

今日好文推荐

让员工加班?去哪儿网被处罚!“东数西算”全面实施;俄乌冲突导致网络安全股价大涨 | Q资讯

修完1300万行代码,我帮苹果省下2亿美元,但没拿到承诺的千万股票

被侮辱、被无视,Swift 之父离开核心团队:纯属浪费时间

无法忍受不做单元测试和内卷,我离开了这家在美中国企业

点个在看少个 bug 👇

登录查看更多
0

相关内容

【吴恩达报告】以数据为中心的人工智能技巧
专知会员服务
51+阅读 · 2022年3月21日
【AI+医疗健康】美国数字健康战略(附44页最新报告)
专知会员服务
91+阅读 · 2022年3月15日
专知会员服务
30+阅读 · 2020年12月21日
【2020新书】使用Kubernetes开发高级平台,519页pdf
专知会员服务
66+阅读 · 2020年9月19日
【2020新书】软件和人工智能项目中的设计思维,157页pdf
专知会员服务
118+阅读 · 2020年8月30日
【2020新书】如何认真写好的代码和软件,318页pdf
专知会员服务
63+阅读 · 2020年3月26日
【新书】Java企业微服务,Enterprise Java Microservices,272页pdf
详解微服务中的三种授权模式
InfoQ
0+阅读 · 2022年1月12日
新项目别一上来就用微服务
InfoQ
0+阅读 · 2021年12月24日
微服务下分布式事务模式的详细对比
InfoQ
0+阅读 · 2021年12月12日
微服务依赖管理的陷阱与模式
InfoQ
0+阅读 · 2021年12月2日
如何在微服务中设计用户权限策略?
InfoQ
0+阅读 · 2021年11月19日
容器并不能解决一切问题
InfoQ
0+阅读 · 2021年11月18日
如何借助 Tekton 实现微服务的 Pipeline
InfoQ
0+阅读 · 2021年11月11日
使用 Kotlin 重写 AOSP 日历应用
谷歌开发者
0+阅读 · 2021年9月15日
国家自然科学基金
3+阅读 · 2015年12月31日
国家自然科学基金
1+阅读 · 2014年12月31日
国家自然科学基金
2+阅读 · 2014年12月31日
国家自然科学基金
0+阅读 · 2013年12月31日
国家自然科学基金
0+阅读 · 2013年12月31日
国家自然科学基金
2+阅读 · 2013年12月31日
国家自然科学基金
1+阅读 · 2012年12月31日
国家自然科学基金
1+阅读 · 2012年12月31日
国家自然科学基金
1+阅读 · 2011年12月31日
国家自然科学基金
0+阅读 · 2009年12月31日
Arxiv
0+阅读 · 2022年4月20日
RIS-Assisted Cooperative NOMA with SWIPT
Arxiv
0+阅读 · 2022年4月18日
VIP会员
相关资讯
详解微服务中的三种授权模式
InfoQ
0+阅读 · 2022年1月12日
新项目别一上来就用微服务
InfoQ
0+阅读 · 2021年12月24日
微服务下分布式事务模式的详细对比
InfoQ
0+阅读 · 2021年12月12日
微服务依赖管理的陷阱与模式
InfoQ
0+阅读 · 2021年12月2日
如何在微服务中设计用户权限策略?
InfoQ
0+阅读 · 2021年11月19日
容器并不能解决一切问题
InfoQ
0+阅读 · 2021年11月18日
如何借助 Tekton 实现微服务的 Pipeline
InfoQ
0+阅读 · 2021年11月11日
使用 Kotlin 重写 AOSP 日历应用
谷歌开发者
0+阅读 · 2021年9月15日
相关基金
国家自然科学基金
3+阅读 · 2015年12月31日
国家自然科学基金
1+阅读 · 2014年12月31日
国家自然科学基金
2+阅读 · 2014年12月31日
国家自然科学基金
0+阅读 · 2013年12月31日
国家自然科学基金
0+阅读 · 2013年12月31日
国家自然科学基金
2+阅读 · 2013年12月31日
国家自然科学基金
1+阅读 · 2012年12月31日
国家自然科学基金
1+阅读 · 2012年12月31日
国家自然科学基金
1+阅读 · 2011年12月31日
国家自然科学基金
0+阅读 · 2009年12月31日
Top
微信扫码咨询专知VIP会员