xfyuan
xfyuan A Chinese software engineer living and working in Chengdu. I love creating the future in digital worlds, big and small.

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

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

本文首发于 RubyChina 社区】DHH 在 2020.04.08 发表了一篇最新博客 “The Majestic Monolith can become The Citadel”,继续讨论对微服务的一点看法,提出了一种与微服务相对的“城堡”模式。在 Twitter 上也引发了不少关注,搜关键字“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,每个以不同语言来编写。不,我们只是分离出一个单独的“基地”。这是一个“城堡”的建设。

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

comments powered by Disqus