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