首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >老人新坑:新项目别一上来就用微服务!!

老人新坑:新项目别一上来就用微服务!!

作者头像
架构师修行之路
发布于 2021-12-28 09:39:40
发布于 2021-12-28 09:39:40
3110
举报
文章被收录于专栏:架构师架构师

作者|Arnold Galovics

翻译|张健欣

编辑|燕珊

微服务变得越来越理所当然,似乎我们一直生活在微服务的世界中。很多时候,我们常常讨论微服务采用与否、如何选型等问题。但本文作者 Arnold Galovics 想讨论的是,为什么一个全新的项目从开始就使用微服务通常是个坏主意。很长一段时间以来,他都在思考这个问题。

最近,当他与其他开发人员交谈并询问他们如何启动一个全新项目时,答案几乎都是:这儿用一个微服务,那儿用一个微服务,用户管理用一个微服务,身份验证用一个微服务,鉴权用一个微服务,session 管理用一个微服务等等。因此,关于微服务,Arnold Galovics 想基于他过去工作项目的一手经验,讲讲别人没有讲过的一些东西,他撰写了一篇题为《不要从微服务开始,单体架构才是你的朋友》(Don’t Start With Microservices – Monoliths Are Your Friend)的文章。

Arnold 的文章很快在技术社区引发热议。有持赞同意见的人直言,微服务对于大多数普通需求来说是一种“矫枉过正”,还有人提出微服务有个 Arnold 没提到的更严重的缺点——将事情分成模块需要时间,并且涉及做出我们可能不知道答案的决定。“启动新产品时,最重要的是尽快启动并运行产品,以便人们可以试用并提供反馈。而根据收到的反馈,我们往往可能会意识到需要构建与现有的完全不同的东西。我见过很多工程劣质的成功产品,也见过很多设计精良的产品失败。产品的成功与其设计的好坏无关。速度往往是最重要的因素。”

另外,有条热门评论提出了个有意思的问题:为什么没有人谈论介于这两者之间的架构——模块化单体?

对此,有回复说道“因为没有新发明的架构称为‘模块化单体’——单体从一开始就应该是模块化的。”该回复进一步指出,微服务不是单体应用不好而诞生的答案,人们的理解在某些地方出现了问题,这也可能是因为很多人不知道应该在代码中构建模块,然后大量的单体最终成为“意大利面条式”代码,就像现在许多微服务架构那样。

有人对此表示赞同并表示,“模块化单体”只是“代码中关注点的适当分离”,其实从一开始就存在。但也有人提出反对意见,认为“模块化单体”要比“分离关注点”更复杂,并不完全是一回事。

一千个人眼中有一千个哈姆雷特,我们将 Arnold Galovic 的这篇文章翻译出来,希望能为读者带来一些参考价值。以下是他的分享内容:

理想中的微服务

我们先来看看,多数文章提到的一些微服务的主要优势有哪些:

  • 故障隔离
  • 消除技术锁定
  • 更容易理解
  • 更快的部署
  • 可伸缩性

是的,这些都不是书中的虚假承诺,但我也必须对你说实话,使用微服务的话,你的系统很难实现这些承诺。下面让我一一列举这些优势。

故障隔离。由于应用程序由多个服务组成,因此如果其中一个服务宕机或出现问题,则只会影响系统的那个部分。以 Netflix 为例,当你观看节目时,你并不关心推荐。因此,如果它们有一个服务来处理当前观众,为他们提供视频流;它们有另一个服务来处理个人用户推荐。如果推荐服务宕机,系统中最重要的功能(例如观看节目)不会受到影响。故障被隔离了。

消除技术锁定。想想单体应用。它是一个巨大的应用程序,有成百上千个 API,管理数百个数据库表。这个应用程序是用 Java 写的,团队花了 5 年时间开发它。一种奇特的新语言出现了,纸面上带来更好的性能、提供更好的安全性等等。这可能是 Go 或 Rust,团队想试验下该语言及其技术栈。他们如何在一个单体应用中做到这一点呢?他们做不到,因为这是一个单独的部署包。你可以将应用程序的一部分切换到不同的语言,但这并不容易做到。

使用微服务时,不同的服务可以使用不同的技术栈。服务 A 可以用 Java 写,服务 B 可以用 Go 写,服务 C 可以用 Whitespace 写,如果你有勇气这么做的话。

更容易理解。当你有多个服务负责整个功能的一小部分时,这个服务本质上会更小,因此更容易理解。

更快的部署。在常规的单体应用系统中,要么完全部署,要么根本不部署。你需要部署一个包,这是一个要么全有要么全无的场景。使用微服务,你有机会独立部署,这意味着,如果你想要部署推荐服务的一次升级(回到 Netflix 的例子),你可以部署单个服务并节省大量时间。

可伸缩性。我的最爱。你可以通过启动多个实例来增加特定功能的容量,从而扩展服务。像前面举的例子,如果人们在 Netflix 上查看大量推荐,它们可以很容易地启动多个推荐服务的实例来应对负载。在单体应用环境中,你要么扩展应用程序的每一个部分,要么什么都不扩展。

现实生活中的微服务

我要用残酷的事实打击你,我的朋友。我并不是说这些优势无法实现,但是你、你的项目、你的组织必须非常努力才有可能实现这些优势。

基础设施要求

下面让我从微服务的一个最大困难——基础设施开始讲起。

绝对是 10 r6g 的真实照片。在 K8S 上运行的单个登录应用程序的 16x 大型(64vCPU、512GB RAM)服务器

你曾经部署过单体应用吗?当然,我们可以将其复杂化,但在常规情况下,如果将应用程序部署到云上,单体应用就是你所需要的形式。让我们以一个简单的在线商店应用程序为例:

  • 应用程序的一个负载均衡器
  • 运行应用程序的一个计算实例
  • 应用程序的一个(关系型)数据库
  • 用于日志聚合的 Kibana

如果你用的是微服务:

  • 一个 Kubernetes 集群
  • 一个负载均衡
  • 运行应用程序和托管 K8S 集群的多个计算实例
  • 一个或多个(关系型)数据库,取决于你是否每个服务用一个数据库
  • 一个用于服务间通信的消息系统,例如 Kafka
  • 用于持续集成(持续部署)的 Jenkins
  • 用于日志聚合的 Kibana
  • 用于监控的 Prometheus
  • 用于分布式跟踪的 Jaeger/Zipkin

而且这只是一个高层级的概览。微服务确实可以产生价值,但问题是:代价是什么?

尽管这些承诺听起来很好,但你的架构中有更多活动的部件,这自然会导致更多的失败。如果你的消息系统挂了怎么办?如果你的 K8S 集群出现问题怎么办?如果 Jaeger 宕机,而你无法跟踪错误怎么办?如果指标没有进入 Prometheus 怎么办?

显然,你将花费更多时间(和金钱)来构建和运转这个复杂的系统。

更快的部署?

我将讲讲优势列表中的第一点:更快的部署。当你想到 Netflix、Facebook、Twitter,并且观看他们的会议演讲,他们描述他们正在运行的微服务数量,以及他们如何向 Git 提交内容,并在数小时内将其投入生产。这是不是好得难以置信?

在我看来,这绝对是可以实现的,但我承认我从未参与过这样的微服务项目。我并不是说这是不可能的,只是从稳定性、基础设施和团队文化角度来看,这真的很难实现。

让我分享一下我是如何从我的经历中得出这个结论的。在对一个全新的项目进行编码之前,你通常会先研究如何将产品转变成技术方案。你会设计系统,设计微服务,会有多少个微服务,每个微服务的职责等等。

有一个真正的教学项目,我们在这个项目中练手,我们最终做了 80+ 微服务,用了多长时间呢,4 个月?

这 80+ 微服务的现实意义是,与其将这 80+ 微服务一起组合成一个单体应用并部署这个单体应用,部署单个微服务绝对会更快,但是....... 这 80+ 微服务太小了,以至于一个开发单元——敏捷领域的叙事——永远不可能只涉及一个服务。系统从根本上被破坏了,更快的部署的承诺立即消失了。我们不再拥有更快的部署,而是相反,更慢的部署。而且慢得多。

另外,我会反复思考这个问题。部署过程中活动的部件越多,意味着潜在故障越多。很多时候,基础实施不够稳定,部署会随机失败,因为:

  • 在下载 / 上传软件包时,Artifactory/Nexus/Docker 仓库短时间内不可用;
  • Jenkins 构建器随机卡住。

这只是其中的一部分。产品必须分解为微服务。每个服务都必须对其自己的事情负责。例如,Netflix 中的一个推荐服务应该负责向用户提供推荐。

不是谁都是 Netflix,也不是所有东西都容易分解成合适的大小和职责。这是领域驱动设计(Domain Driven Design,DDD)和有界上下文可以提供帮助的地方,但这实践起来并不容易,有时甚至没有足够的时间 / 开发性来试验这些方法。

配套文化

无论如何,在我看来,微服务的第二个困难是组织 / 项目文化。如果产品(部门)根本不关心底层系统架构会怎么样?我是说,他们会关心吗?

举个例子:如果你有一个拥有大量微服务的复杂架构会怎么样。产品负责人进来对团队说,让我们开发整个功能。在团队分析完功能请求后,发现它涉及 10-15 个微服务,因为它与许多其它的已有功能有关联。那你会怎么办?

你试图将它分解成更小的部分,但是这么做到底对不对,这里存在着疑问,因为每个小部分的功能没有意义,而且逐个服务发布它会增加大量开销。你当然不能对产品负责人说,仅仅因为我们用的是微服务,所以我们需要 3-4 倍时间,对吧?

这个对话会是什么样子?

  • 产品经理:嗨,伙计们,我想到了一个非常棒的功能。我们的竞争对手也准备做这个功能,所以我们要快点实现它。2 周做完,可以吗?
  • 团队:好吧,初步看来,我们可以实现这个功能。而且这个功能看起来也是一个好主意,可以带来更多的客户。我们会重新组织,好好谈谈。
  • 团队:好吧,2 周有一点儿问题。因为我们用微服务是为了更快,我们需要更多时间来实现这个功能,由于我们需要涉及 15 个服务,因此我们需要 6 周的时间来完成初步实现。
  • 产品经理:初步实现?
  • 团队:是的。这 15 个服务之间的通信非常重要,因此初步实现不会包括异常处理、弹性通信模式、调试跟踪等其它东西。如果做这些的话,我们还额外需要 4 周时间。
  • 产品经理跳窗了

更好的故障隔离

这一点自然是正确的。如果一个服务挂了,只有那个服务会受影响,对吧?虽然确实如此,但这并不是绝对的。让我给你展示 Netflix 的一个虚拟架构图——我对其进行了简化:

假设用户想要看推荐。请求转到推荐服务,它查询用户数据来了解用户详情,并将推荐存储在其数据库中(不在图片上),而且由于这是用户相关的数据,所以它们可能需要将其加密。

现在,如果数据加密服务挂了会发生什么?我们还能做推荐吗?肯定不能,因为我们不能加密用户数据,所以我们自然会说,嘿,伙计,我们现在不能给你推荐,请 5 分钟后再试。这个故障影响到系统中的推荐服务,系统会以无法立即提供推荐的事实来优雅地做出回应。

但是你知道要优雅地处理这类情况需要做多少工作吗?非常多。

让我们再举一个例子。用户尝试使用登录服务来登入系统。数据加密服务仍在故障,登录服务调用分析服务来获取在一个时间区间内有多少用户正在尝试登入的指标,以及其它一些虚构的指标。不过,分析服务也在与数据加密服务通信,因为这些数据也需要加密。

现在,编写分析服务的团队正忙着,没有时间来实现适当的异常处理,因此数据加密服务的问题会转而影响到登录服务。显然,登录服务是在几个月前完成的,这个服务没有准备好处理来自分析服务的底层错误,因此即使不关键的分析服务失败也会导致用户登录被拒绝。

而且我知道你是怎么想的。是的,实现登录服务的团队不负责为处理这种情况做准备,但是如果他们认为分析服务会优雅地处理这个异常呢?这已经写在分析服务的 API 合约中,但它没有那样生效。

那么,当你在一个单体应用程序中,会发生什么呢?一个服务崩溃在这个上下文中并没有真正的意义,但假定由于某种原因,连接到数据加密的数据库表不可访问了。

在这种情况下,异常处理非常简单,因为你只需要准备一个 exception 就可以了。但是在过分赞扬单体应用前,需要说的是,单体应用也有缺点,如果单体应用挂了,什么东西都不可用了。因此,这是一个平衡问题,需要问问你自己。是实现一个 try-catch 代码块更容易,还是处理一个同步 HTTP 调用异常或异步消息异常更容易?

我记得,对于 80+ 微服务,标准化异常处理是非常了不起的事情,它需要一个团队花费数月来完成。这甚至不意味着在每个地方都引入异常处理,而只是将现有的异常用我们使用的一个自定义库重写,这样我们就可以减少未来异常处理场景所需的繁琐工作。

关于作者

Arnold Galovics 六年级开始学习 Flash 编程,之后开始接触 HTML、CSS、JavaScript,在高中时期学了几年 Pascal,然后在大学开始学习 C、C++ 和 Java。Java 是其职业垫脚石,他为 Java 投入了大量时间。2012 年开始作为全职软件开发者,参与金融行业、OAuth2、与 OpenID 兼容的身份验证平台、物联网等应用程序的开发,主要专长是 Java 及相关框架,熟悉 Spring、JUnit、TestNG、Mockito、JPA、Hibernate,以及 Kubernetes、Kibana、Ansible、Jaeger、Zipkin、Kafka、MQTT 等。只要是跟 Java 相关的开发技术、基础设施、云、架构都比较熟悉。在过去几年中,他过渡到了团队管理的位置,团队规模从 5 人增长到 35 人,试图使用 ScrumKanban 来实践敏捷方法,希望在团队成员个人创造力与公司目标之间取得平衡。

原文链接:

https://arnoldgalovics.com/microservices-in-production/

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-12-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 架构师修行之路 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
75%新项目都可以“无脑”选择单体架构
以微服务的方式构建新项目并不困难,新架构带来的新承诺也着实令人充满期待。然而,现实与想象往往相去甚远。本文是该作者 Arnold Galovics 关于微服务系列文章中的第二篇。感兴趣的朋友可以点击此处阅读第一篇《新项目别一上来就用微服务》,在第一篇文章中,Arnold 介绍了微服务架构对于基础设施的要求、更快的部署特性、给组织文化提出的挑战以及天然的故障隔离优势。
深度学习与Python
2022/03/23
2990
75%新项目都可以“无脑”选择单体架构
从单体架构迁移到微服务,8个关键的思考、实践和经验
随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多。去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上。毋庸置疑,微服务的理念正在席卷整个开发者社区,像Netflix、Uber这样的公司都是非常成功的应用案例。 但需要注意的是,实施微服务,也需要付出额外的代价,Martin曾经就说过,除非面对的是一个过于复杂以至于难于管理的单体应用,否则绝对不要考虑使用微服务。大多数的软件系统应该构建为独立的单块程序。确保注重单体应用
yuanyi928
2018/04/02
2K0
从单体架构迁移到微服务,8个关键的思考、实践和经验
(译)Medium 的微服务架构
微服务架构的目标是帮助工程团队安全快速地完成高质量的产品交付。良好解耦的服务能够在最小化对其它系统的影响的条件下进行快速迭代。
崔秀龙
2019/07/23
4960
(译)Medium 的微服务架构
有效的微服务:10 个最佳实践
如果没有正确的拆分,那么结果就是一堆浆糊,有着单体结构的缺点,和微服务结构的复杂度,可以称之为分布式单体。
dys
2020/02/12
5650
有效的微服务:10 个最佳实践
探讨微服务架构如何降低系统复杂度
在数字化转型的浪潮下,企业面临着前所未有的挑战,其中之一就是如何构建和维护日益复杂的IT系统。传统的单体应用虽然在初期能够满足需求,但随着业务的扩张和技术的迭代,其弊端逐渐显现,包括但不限于:
终有链响
2024/07/29
1910
一文带你了解微服务架构和设计(多图)
最近几年微服务很火,大家都在建设微服务,如果不懂点微服务相关的技术,都不好意思跟同行打招呼了,也见过身边很多人在微服务踩过很多坑,我从 16 年开始接触微服务,有多家大型企业的微服务分布式系统的架构经验,所以就打算跟大家做一期关于微服务的分享,不过微服务和涉及的分布式计算非常的复杂,绝非是一篇文章就可以讲清楚的,本文只是从最简单的概念的基本使用带你入门,如果后续还有兴趣的话,可以查阅相关的文献和技术书籍去深入学习
phoenix.xiao
2020/09/17
1.3K0
微服务架构设计总结实践篇,10 步搭建微服务
微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
架构之家
2022/07/12
9370
微服务架构设计总结实践篇,10 步搭建微服务
微服务模式系列之二:微服务架构
译者评论: 微服务架构大家已经耳熟能详,但是我认为这篇文章最有价值的是这段: 但这类解决方案中也存在着以下弊端: 开发者必须应对创建分布式系统所产生的额外的复杂因素。 现有开发者工具/IDE主要面向单体应用程序,因此无法显式支持分布式应用的开发。 测试工作更加困难。 开发者必须采取服务间通信机制。 很难在不使用分布式事务机制的情况下跨服务实现功能。 跨服务实现功能要求各团队进行密切协作。 部署复杂。在生产环境下,对这类多种服务类型构建而成的系统进行部署与管理十分困难。 内存占用量更高。微
yuanyi928
2018/04/02
8970
微服务模式系列之二:微服务架构
微服务架构: 什么是微服务, 是什么时候和怎么使用微服务
微服务架构现在已经广泛使用,看看什么是微服务,简要概述一下什么时候和怎么样使用它们,以及相对于单体架构的优势。 介绍 现在,微服务架构模式得到了广泛关注,并且已经成为趋势。如果不清楚可以来看看谷歌搜索趋势。 可以看到从2014年开始,人们对这个词的兴趣大增,随着时间的推移,这种趋势还在不断增加。 这种对微服务炒作正处于顶峰。即使是在当前炒作的高峰期,也值得研究微服务架构风格。我相信这肯定有一定的风险,花时间去理解它是很好的。 有一些微服务架构优越性支撑起这种炒作。像Netflix、亚马逊(Amazon)和
程序你好
2018/07/20
1.5K0
你适合微服务么:实施微服务的4个先决条件和重点工作
“Mesh App and Service Architecture”作为Gartner2016 十大战略技术趋势中之一,里面大量提到微服务的概念。微服务(Microservices)这个概念不是新概念,很多公司已经在实践了,例如Google、Netflix、Facebook、Twiter、Alibaba。微服务架构模式(Microservices Architecture Pattern)的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务,每个服务都可以很容易得局部改良。 微服务从去年以
yuanyi928
2018/04/02
1.4K0
你适合微服务么:实施微服务的4个先决条件和重点工作
微服务架构的7大好处
对于刚开始考虑使用微服务来开发自己业务或者想学习微服务架构的微服务领域的新手程序猿来说,首先,我们要快速了解微服务如何在日后的工作中为您的开发工作带来的好处。
用户8554325
2023/03/10
1.8K0
微服务架构的7大好处
微服务开发的 10 个最佳实践
随着软件系统越来越复杂,大型的软件系统变得难于开发、增强、维护、现代化和规模化。为解决这一问题,人们尝试过模块化软件开发、分层软件架构、SOA。现在,微服务架构成为解决现代软件应用复杂性的新“利刃”。但正确设计微服务架构非常具有挑战性和困难,因此本文作者提出一些最佳实践,这些实践有助于开发有效的微服务应用程序。
lyb-geek
2022/11/18
6190
微服务开发的 10 个最佳实践
【微服务架构】什么是微服务? — 全面了解微服务架构
What is Microservices — Edureka 您有没有想过,什么是微服务以及扩展行业如何与它们集成,同时构建应用程序以满足客户的期望? 要了解什么是微服务,您必须了解如何将单体应用程序分解为独立打包和部署的小型微型应用程序。本文将让您清楚了解开发人员如何使用微服务根据需要扩展其应用程序。 在本文中,您将了解以下内容: 为什么是微服务? 什么是微服务? 微服务架构的特点 微服务架构的优势 设计微服务的最佳实践 使用微服务的公司 为什么是微服务? 现在,在我告诉你微服务之前,让我们看看在
架构师研究会
2022/04/24
2.6K0
【微服务架构】什么是微服务? — 全面了解微服务架构
面向项目经理的Java微服务
微服务是一种用于设计复杂软件的架构解决方案,将其分解为可独立部署的小型模块化服务。它通常与传统的单一体系结构形成对比,在这种体系结构中,软件是作为一个单元构建的。通常,微服务通过REST进行通信。
Java架构师历程
2018/09/26
1.2K0
面向项目经理的Java微服务
测试微服务的4个最佳实践
随着微服务架构的出现,应用程序堆栈发生了根本性的变化,这对软件测试产生了连锁反应。每天多次发布微型版本,软件测试更加精细,它与开发同时发生,并且与测试单体应用程序有根本的不同。
lyb-geek
2018/12/28
7390
为什么应该使用微服务(Microservices) ?
如今,微服务非常流行。几乎每个人都喜欢。不仅仅是Netflix、亚马逊或谷歌,似乎几乎每个人都采用了这种架构风格。虽然微服务已经存在了很长一段时间,也有很多关于它的文章,但我今天想再写一篇,所以请耐心听我说。
程序你好
2018/09/29
1.2K0
为什么应该使用微服务(Microservices) ?
[译]微服务-Martin Fowler
作者:YYGCui 出处:http://blog.cuicc.com/blog/2015/07/22/microservices/ 在过去几年中,“微服务架构”这一术语如雨后春笋般涌现出来,它描述了一种将软件应用程序设计为一组可独立部署的服务的特定方式。虽然这种架构风格没有明确的定义,但在组织、业务能力上有一些共同的特征:自动化部署,端点智能化,语言和数据的去中心化控制。 “微服务” - 软件架构拥挤大街上的有一个新术语。虽然我们自然的倾向是轻蔑的一瞥将它一带而过,然而我们发现这一术语描述了一种越来越吸引人
纯洁的微笑
2018/04/18
1.4K0
[译]微服务-Martin Fowler
SpringCloud简介与微服务架构
微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
BUG弄潮儿
2021/02/03
6660
SpringCloud简介与微服务架构
可组合架构与微服务:哪个更优?
两种软件开发架构都有各自的优缺点。下面是如何决定可组合架构还是微服务架构哪种更适合你的方法。
云云众生s
2024/03/28
1840
什么是微服务
在介绍微服务时,首先得先理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是"微"、什么是"服务", 微 狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释(2 pizza 团队最早是亚马逊 CEO Bezos提出来的,意思是说单个服务的设计,所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 )。 而所谓服务,一定要区别于系统,服务一个或者一组相对较小且独立的功能单元,是用户可以感知最小功能集。
前朝楚水
2018/07/26
1K0
相关推荐
75%新项目都可以“无脑”选择单体架构
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档