您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

放弃微服务,构建单体应用

时间:2021-11-26 09:56:11  来源:CSDN  作者:GreekDataGuy

作者 | GreekDataGuy

译者 | 弯月

出品 | CSDN(ID:CSDNnews)

微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。

本文是我根据构建微服务的经历,总结出的经验教训。

放弃微服务,构建单体应用放弃微服务,构建单体应用

 

噩梦般的数据管理

跨多个微服务保持数据同步是一个很大的难题。

通常人们推荐的方式是每个微服务一个数据库。这样不仅可以实现松散耦合,而且还可以让各个服务的团队独立运作,同时不会影响共享代码的协作速度。

然而,如果两个微服务应该互相同步,但其中一个发生故障,后果会怎样?例如,其中一个微服务更新了数据库,而另一个没有。这样的状况会导致数据的不一致。

根据我的个人经验,跨服务调查数据的不一致会非常痛苦。由于错误跨多个服务,因此需要某个人跨多个服务修正错误。不幸的是,这导致微服务丧失了其优势之一:每项服务由一个开发团队负责。

而单体应用则可以通过一个原子事务打包两个数据库调用,保证两个插入操作都成功或都失败,从而轻松防止出现相同的情况。十分简单。

但是对于微服务,松散耦合导致这些操作变得更加困难。

放弃微服务,构建单体应用

 

设置时间更长

构建微服务架构所需的时间比将相同的功能整合到单体应用更长。虽然微服务的一个服务很简单,但交互的服务集合比类似的单体应用要复杂得多。

单体应用中的函数可以调用任何其他公共函数。但是微服务中的函数仅限于调用同一个微服务中的函数。这就导致服务之间需要通信。而构建通信所需的API或消息系统并非易事。

此外,微服务之间的代码重复无法避免。单体应用则可以定义一个模块,并多次导入,而微服务本身就是应用,所有的模块和库定义都在内部。

放弃微服务,构建单体应用

 

微服务更适合大型团队

将微服务分配给每个团队的做法更适合大型工程团队。

尽管这是该架构的优势之一,但只有当工程团队有足够的人手,可以为每个服务分配多名工程时,这种优势才能发挥出来。缩小代码的范围,可以让开发人员更好地理解代码,并提高开发速度。

然而,大多数创业公司并没有这样奢侈的资源。创业早期,公司的资源往往不足,有些工程师需要负责所有的服务。不幸的是,开发人员的思维需要在多个应用之间来回跳跃,因此会导致生产力低下。

此外,跨多个陌生的微服务调查 bug 真心累。

放弃微服务,构建单体应用

 

开发运维更加复杂

绝大多数人选择微服务的主要原因之一就在于,能够在多个不同类型的服务器上运行不同的服务。

为什么?React 前端的需求完全不同于训练机器学习模型的服务,比如内存、CPU 和正常运行的时间等。针对每个服务选择正确的基础设施可以大大降低成本。但同时也会带来挑战。举个例子,在职业生涯的早期,我曾经造成了大量生产数据丢失,因为在更新完某个服务的代码后,我忘了重启服务,旧代码通过API请求接收数据,然后出错了,未能成功地将这些数据保存到数据库,也没有报错。所以,数据永久地丢失了。

我举这个例子是为了说明与单体应用相比,配置、维护和监控多个微服务需要付出更多的努力。此外,拥有多个应用也会导致黑客攻击的途径增加。

理论上,“松散耦合”可以保证某个服务发生故障时,其他服务继续运行。但这只是痴人说梦,对于业务非常复杂的客户来说,真正实现松散耦合几乎是不可能的。

最后,架构的可靠程度取决于最薄弱的环节。活动的部分越多,出错的概率就越大。

放弃微服务,构建单体应用

 

总结

虽然许多公司都采用了微服务,但实际上并没有必要。尽管如今微服务的人气很高,但并不适合初创公司。

对于大多数公司来说,单体应用才是更好的选择。等到有必要时,再将单体应用的各个部分拆分为微服务。

当然,资金雄厚的大型科技公司完全可以从零开始构建微服务架构。

对于刚起步的创业公司来说,微服务并不适合,而且还会浪费大量的时间和精力。

参考链接:

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



Tags:单体应用   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  Tags: 单体应用  点击:(35)  评论:(0)  加入收藏
它在线上每天服务几十万的用户,并且流水过亿。没有所谓的微服务、分布式,就是一个war包,然后扔到tomcat里面去。里面的代码很多,目前我看到的最大的一个类是28000多行代码。是的...【详细内容】
2020-08-17  Tags: 单体应用  点击:(109)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(3)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(8)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(20)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(16)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(16)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条