【本文首发于 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，每个以不同语言来编写。不，我们只是分离出一个单独的“基地”。这是一个“城堡”的建设。
随着越来越多的人们意识到对于微服务的追逐会走上一条死胡同，“钟摆将会再摆动回来“。“雄伟巨石”在这儿等待着微服务的“难民”。如果他们确实做到了大型应用程序的规模，那么“城堡”这种可以扩展的模式足以让你安心。