新堆栈 @Scale 播客:微服务和复杂性

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

The New Stack @Scale 播客 的第二集中,TNS 创始人兼总编辑 Alex Williams 和我一起加入了大数据公司 Basho Technologies 的 CTO Dave McCrory 和专注于开发人员的 RedMonk 的联合创始人 James Governor 行业分析公司。我们还听取了 Runscope 首席执行官 John Sheehan 和 sysdig 创始人 Loris Degioanni 的讲话。该播客是上周在拉斯维加斯举行的 AWS re:Invent 大会现场录制的。

话题?复杂。我们谈到了高度可扩展系统中复杂性增加的影响,并重点关注了集成大量可能以意想不到的方式相互依赖的微服务所涉及的隐藏复杂性。

正如戴夫解释的那样:

“微服务背后的想法是让每项服务都非常离散且具体地说明它的作用,而不是将许多不同的功能混合或聚合到一个服务中——因此,这是一个非常有目的的服务。这样做的问题是,您没有能够轻松地处理事物的集成,而是松散地耦合了所有内容,而松散地耦合了所有内容会导致复杂性。

“这不仅会导致复杂性——你现在必须管理这个相互依赖的事物网络——你可以有循环依赖,你可以有单向依赖——但除此之外,每一个这些离散服务是版本化的。如果你改变它,它可能会影响下游的其他五件事。因此,您现在必须管理这个巨大的依赖关系图。管理微服务代码真的很容易,因为它只做了一件小事,这很棒。但是现在,您如何处理所有行为的后果以及所有这些行为的依赖性?一旦你真正开始实施微服务,这就是真正的挑战之一。”

讨论中还有更多内容,您可以在 Alex 关于 The New Stack 的博客文章( The New Stack @Scale,展示 2:Managing Complexity 和 Battlestar Galactica )中阅读主题的详细概述。这是一次严肃、深思熟虑的对话,但我最喜欢的部分出现在剧集的 27 分 41 秒,我们四个人决定我们需要更有趣一点,并就哪部科幻小说系列提供了最好的比喻来展开激烈的辩论微服务的本质。 (我的观点在播客播放器下方。)

New Relic 是 New Stack @Scale 播客的赞助商。但是,所表达的内容和观点是 New Stack @Scale Podcast 参与者的观点,这是 The New Stack 的财产。在 New Stack @Scale 播客上表达的任何观点不一定反映 New Relic 的观点。通过嵌入 New Stack @ Scale 播客的音频或链接到 The New Stack,New Relic 不采用、保证、批准或认可 The New Stack 网站上提供的信息、观点或产品。

好的,这是科幻小说的设置。詹姆斯最近似乎开始观看最受欢迎的科幻节目《太空堡垒卡拉狄加》,并很快确定“赛昂人是关于微服务的寓言”。他说,该剧中的赛昂人形机器人完全是一次性的和不可变的……当一个人被杀死时,一个新的人形机器人会完全一样地弹出……“有一个持久的存储层。”就像微服务一样!

但戴夫反驳说,星球大战的冲锋队实际上是更好的比喻。他指出,它们有点自主,如果需要,你可以克隆数十万个。 (又是规模问题。)

争论似乎只是愚蠢的乐趣,但我认为不仅如此。弄清楚如何使用容器和微服务可能很困难,并且拥有一个易于理解的隐喻(或多个隐喻)可以大大有助于让技术水平较低的人更容易理解这些概念。

我,我认为容器和微服务更像是 Minion;可爱、有趣的小家伙们蜂拥而至,试图提供帮助,但有时会妨碍他们。但坦率地说,我真的不在乎人们使用什么隐喻……只要我们除了最近无处不在的集装箱之外还有另一个视觉隐喻。