翻译 DHH 最新博客——“雄伟巨石” 可以成为 “城堡”

apexy · 2020年04月13日 · 最后由 Qwaz1314 回复于 2020年11月07日 · 13603 次阅读
本帖已被管理员设置为精华贴

DHH 在 2020.04.08 发表了一篇最新博客“The Majestic Monolith can become The Citadel”,继续讨论对微服务的一点看法,提出了一种与微服务相对的“城堡”模式。在推上也引发了不少关注,搜关键字“The Majestic Monolith”就能看到很多。这是原文链接:https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/

我按照个人理解,粗略翻译了一下。大家可以对照原文来看,如有翻译不准确的地方,请在回复中提出来。

[翻译]

“雄伟巨石”可以成为“城堡”

大多数的 Web 应用应该都是从一块“雄伟巨石”开始其生涯的:一个单一代码库做其所需的所有事儿。与之相对的是一群 Service,不管这些 Service 是“微”还是“大一点”的,都试图把应用切成孤岛,每个仅做整体工作的一小片而已。

大多数的 Web 应用都将以“雄伟巨石”形态在其一生中都能持续提供很好的服务。这种模式的上限很高,比大部分人幻想成为架构师时所能想象的要高得多。

但是,尽管如此,“雄伟巨石”仍然会有需要一些帮助的那一天。也许你正在与庞大的团队打交道,其中的人们相互磕磕绊绊(即使这样,别忘了有很多非常大的组织依然在使用 monorepo 模式!)。或者你终究会遇到极端负载下的性能或可用性问题,这在“雄伟巨石”的技术选择范围内无法轻松解决。你的第一直觉将是改进“雄伟巨石”直到其能够应对问题,做了这一切而没成功时,你才会考虑下一步。

下一步就是“城堡”,保持“雄伟巨石”在中心位置,但用一系列的“基地”对其支援,每个分离出应用程序职能一个小的子集。“基地”使得“雄伟巨石”得以卸下其不同行为的一个切片,(这些不同行为)要么是出于组织原因,要么是出于性能或实现的原因。

一个在 Basecamp 的这种例子是我们的旧 chat 应用 Campfire。它是在 2005 年构建的,那时 Ajax 和其他 JavaScript 技术都还很新颖,所以它基于 polling 而不是现代 chat app 目前使用的长连接。这意味着每个客户端连接到系统都会每三秒触发一个请求来询问“是否有我的新消息?”。大多数这些请求都会回答“不,没有”,但为了获取这个答案,你仍然不得不对请求进行身份验证,查询数据库,等等。

与应用程序的其他相比,这个服务的性能特征大不相同。在任何给定时间,它都将占所有请求的 99%。它也是一个确实很简单的系统。在 Ruby 中,它仅仅 20 行代码长度而已,如果我没记错的话。换句话说,这是一个极好的“基地”候选人!

所以我们就(为它)构筑了一个“基地”。这么些年来,在日光下使用每种高性能编程语言来重写这种“基地”成为了我们的乐趣,因为通常只用短短几百行代码就能搞定,不管什么语言。所以我们使用了 C,C++,Go,Erlang,还有些我都忘记了。

但这显然是一种“基地”!应用程序的其他部分继续作为 Ruby on Rails 构建的“雄伟巨石”。我们没有试图把整个 app 切成小的 Service,每个以不同语言来编写。不,我们只是分离出一个单独的“基地”。这是一个“城堡”的建设。

随着越来越多的人们意识到对于微服务的追逐会走上一条死胡同,“钟摆将会再摆动回来“。“雄伟巨石”在这儿等待着微服务的“难民”。如果他们确实做到了大型应用程序的规模,那么“城堡”这种可以扩展的模式足以让你安心。

hooopo 回复

来源?

文章里“微服务难民”链接里的沙雕视频挺搞笑的 😂

文章感觉很有帮助,我们公司目前采用的就是城堡模式。虽然一直在这么做,但是之前不知道叫什么模式。😀 以后有了,城堡,巨石,基地😋 😋

jasl 将本帖设为了精华贴。 04月14日 05:41

微服务管理者能分山头,技术人员能折腾着玩,除了对产品不一定好,其他都照顾到了。

DHH 在推上对“城堡”模式给出了一个定义:”A single Majestic Monolith captures the majority mass of the app, with a few auxiliary outpost apps for highly specialized and divergent needs.“

AppSignal 也专门发了一篇文章来详细描述他们自己采用的“城堡”模式架构,跟 #5 楼的同学一样,AppSignal 一直这么做,而现在 DHH 给出了一个专门的命名。

AppSignal 文章在此:https://blog.appsignal.com/2020/04/08/the-citadel-architecture-at-appsignal.html

把 outpost 翻译成“前哨”、“堡垒”,比“基地”好些。

基地给人的感觉像是整个应用的基础

hjiangwen 回复

多谢。我个人是觉得“基地”比较合适,跟“城堡”、“巨石”比,感觉上概念没那么大。这个词跟“基石”、“基础”还是不同的,不至于混淆吧。

再加上红警……😀

软件工程上的 R&D,水平不够就招人来凑。就 AppSignal 的例子,他们为了用 Kafka 写了 Kafka gem 这是勤快又高水平,若是别的公司直接转 Java 了

Rei 回复

我不由自主的笑了😆

apexy 回复

堡垒

hooopo 回复

太真实了,😈

调用链跟踪系统

太真实了,😈

dhh 月经?

lanzhiheng 回复

分工只是结果而已。大公司的老板不是 sb,不会招一大堆人来,然后为了分工再搞一套体系。

招更多的人、用复杂的架构,都是为了解决实际的问题。

任何工具,都需要思考对应的场景、需求、成本,然后才做出考量和选择。

用一句话总结:小公司用微服务的是 sb,大公司不用微服务是找死。

为了微服务而微服务,大有人在

https://martinfowler.com/bliki/MonolithFirst.html https://cbra.info/book/index.html

采用单体应用优先策略,基于组件的 Rails 应用程序有利于实施绞杀者策略,从单体架构演进到微服务架构。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号