kaiyun官方注册
您所在的位置: 首页> 人工智能> 业界动态> 放弃微服务,构建单体应用

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

2021-10-29
来源:CSDN
关键词: 微服务 单体应用

  噩梦般的数据管理

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

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

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

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

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

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

  设置时间更长

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

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

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

  微服务更适合大型团队

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

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

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

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

  开发运维更加复杂

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

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

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

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

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

  总结

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

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

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

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




1.png

本站内容除特别声明的原创文章之外,转载内容只为传递更多信息,并不代表本网站赞同其观点。转载的所有的文章、图片、音/视频文件等资料的版权归版权所有权人所有。本站采用的非本站原创文章及图片等内容无法一一联系确认版权者。如涉及作品内容、版权和其它问题,请及时通过电子邮件或电话通知我们,以便迅速采取适当措施,避免给双方造成不必要的经济损失。联系电话:010-82306116;邮箱:aet@chinaaet.com。
Baidu
map