写点什么

停止盲目使用微服务

  • 2022-02-17
  • 本文字数:1634 字

    阅读完需:约 5 分钟

停止盲目使用微服务

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


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

管理数据是一场噩梦


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


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


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


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

设置时间更长


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

微服务最适合大型团队


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

DevOps 更复杂


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


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


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


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


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

总结


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


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


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


作者介绍:


GreekDataGuy,开发者。


原文链接:


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

2022-02-17 17:175407

评论 3 条评论

发布
用户头像
不敢苟同,事实上是,单体一旦形成很难转型到微服,微服也不会像作者说的很难配置和监控,举个我自己的例子,微服部署在Azure AKS,所有的微服通过Gateway以Client的形式进行交流, 至于监控有太多的实时监控软件比如我用的是kubernetic
2022-03-19 14:26
回复
用户头像
笔者应该是传统架构往微服务架构转型的践行者,很大可能性是刚刚开始尝试使用微服务。微服务架构很多时候和云平台配合可能更容易成功一些。微服务架构已经屏蔽了底层的数据操作,用微服务架构再考虑数据的同步,应该是建设思路和微服务架构理念不适配。
2022-02-22 18:13
回复
用户头像
我们是需要提供很多各种各样的API接口,因此按照业务分类、性能要求拆分了10+个小的微服务,可以提高接口性能和服务稳定性
2022-02-20 18:49
回复
没有更多了
发现更多内容

Python——字符串转换与处理

在即

6月日更

递归全排列问题(两种方法 Java实现)

若尘

数据结构 递归 6月日更

当人工智能遇上视频直播——基于Agora Web SDK实现目标识别

dajyaretakuya

深度学习 音视频 WebRTC 声网 TensorFlow.js

你愿意被管理么?

escray

学习 极客时间 朱赟的技术管理课 6月日更

【Vue2.x 源码学习】第八篇 - 数组的深层劫持

Brave

源码 vue2 6月日更

Webpack 系列:如何编写loader

范文杰

webpack 6月日更

高性能 JavaScriptの七 -- 编程实践小技巧

空城机

JavaScript 大前端 6月日更

【Flutter 专题】109 图解自定义 ACERadio 单选框

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 6月日更

证券互动问答平台关键词监控提醒

木头

互动平台 证券监控 股市消息 监控提醒

那个陪我打王者的兄弟进了阿里

艾小仙

【LeetCode】从上到下打印二叉树 Java题解

Albert

算法 LeetCode 6月日更

待办事项列表,敏捷项目管理的核心工件

万事ONES

Scrum 敏捷 研发管理 ONES

Packer 自动化镜像 Windows 安装过程

HoneyMoose

【21-1】21 连更第一篇

耳东@Erdong

6月日更

缓存穿透、缓存雪崩、缓存击穿问题与优化方案

Skysper

模块六作业

c

架构实战营

☕️【Java技术之旅】站在Linux操作系统角度去看Thread(线程)

洛神灬殇

线程 Thread 6月日更 内核线程

春色满园关不住,带你体验阿里云 Knative

阿里巴巴云原生

云原生

【布道API】浅谈API设计风格

devpoint

Rest API 6月日更

密码学系列之:生日攻击

程序那些事

加密解密 密码学 程序那些事

Kubernetes 的自动伸缩你用对了吗?

张晓辉

Kubernetes k8s最佳实践

聊聊追求测试技术导致过度测试

陈磊@Criss

这些书都学完,绝对是编程界的大佬

看山

Java 程序员 6月日更

Locust完成gRPC协议的性能测试

陈磊@Criss

内嵌双向链表的设计与实现

实力程序员

一文教会你认识Vuex状态机

华为云开发者联盟

Vue 应用 vuex 事件 父子组件

Mybatis 二级缓存简单示例

Java mybatis

读深入ES6记[二]

蛋先生DX

ES6 6月日更

如何进行可视化大屏视觉设计?

博文视点Broadview

Java 并发编程——线程池开篇

Antway

6月日更

SpringBootApplication注解

梦倚栏杆

停止盲目使用微服务_架构_GreekDataGuy_InfoQ精选文章