写点什么

停止盲目使用微服务

  • 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:175442

评论 3 条评论

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

阿里大牛肝出的443页TCP/IP协议趣谈笔记,竟然在GitHub标星27k+

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

KubeVirt with YRCloudFile 擦出创新的火花

焱融科技

云原生 文件存储 虚拟化 高性能, 分布式存储,

华为大神用前半生经验所写的SpringBoot全优笔记,现无偿与大家分享!

Java 华为 程序员 面试 计算机

面试讲不清MySQL索引底层,Java面试

Java 程序员 后端

Python基础综合练习1

在即

9月日更

小白都能看懂的JVM知识,一文带你学会JVM内存模型!

华为云开发者联盟

Java JVM 内存管理 Java虚拟机 JVM内存模型

用遗传算法进行智能排课,相信老师会很喜欢

华为云开发者联盟

AI 编码 遗传算法 算子 课程编排

webrtc simulcast 开启

webrtc developer

webrtc、 simulcast,

小红书严惩刷量行为:如何才能优雅的种草

石头IT视角

发布半小时登上GitHub首页的Spring Boot实战笔记,竟是京东T8编写

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

金九银十涨薪50%,从默默无闻,到坐上美团L8技术专家(面经+心得)

Java 编程 程序员 架构 面试

牛皮了!阿里大佬总结的图解Java手册在GitHub火了,完整版开源中

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

Alibaba内部最新Java架构核心宝典 (全彩版小册开源)

Java 程序员 架构 面试 计算机

SQL注入详解

行者AI

测试

恒源云(GpuShare)_GPU租用保姆级教程,助力深度学习训练!

恒源云

Serverless 工程实践 | Serverless 应用开发观念的转变

阿里巴巴云原生

Serverless Serverless架构

程序员35岁后的发展,欢迎一起来讨论

hanaper

阿里内部进阶资料:24w字的Java面试宝典,竟然在GitHub霸榜月余

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

一萌妹子的面试经历,美团四面三小时,成功拿到Java岗offer

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

面试官问的那些Java原理你都懂吗,Java面试手写代码题目

Java 程序员 后端

面试被问Tomcat整体架构设计,深入浅出Java开发

Java 程序员 后端

Python中使用定时调度任务(Schedule Jobs)的5种方式

Regan Yue

Python 调度 9月日更

面试官手里那些秀你一脸的求质数大法,疯狂复习半个月

Java 程序员 后端

面试竟然被这31道Java基础题难倒了,被阿里面试官征服了

Java 程序员 后端

面试官都被搞懵了,阿里P7亲自讲解

Java 程序员 后端

模块3作业

Ping

意外发现GitHub 星标35k+ 435页网络协议深度笔记,出自华为架构师

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

你的工作谁做主?

产品运营心经

工作效率 职场成长

ResNet-50 在 ImageNet-1k 上的实验笔记

毛显新

人工智能 神经网络 深度学习 卷积神经网络 PyTorch

vue3,对比 vue2 有什么优点?

华为云开发者联盟

Vue Vue3 vue2 diff算法 渲染API

浅谈百度阅读/文库NA端排版技术

百度Geek说

大前端 百度文库

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