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

apexy · 2020年04月13日 · 最后由 opo 回复于 2020年09月03日 · 10932 次阅读
本帖已被设为精华帖!

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 回复

来源?

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

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

hooopo 回复

zhh 和 dhh

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 应用程序有利于实施绞杀者策略,从单体架构演进到微服务架构。

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