关于过气网红编程语言 Ruby，我们此前曾发过一篇文章去回顾其大受追捧的过往，并讨论了它每况愈下的生存状态。不过人气并不能直接说明语言质量差，一方面 Ruby on Rails（用 Ruby 写的开源 Web 应用程序框架）仍是实现原型设计演示的好方法，能帮助开发者在几天之内更稳妥地构建起最小可行性产品，另一方面，市场对于 Rails 和 Ruby 开发者还是存在刚性需求。

近期，GitLab 就发布了一篇文章阐述它们坚持使用 Ruby on Rails 的原因。全球有许多流行网站都是基于 Rails 构建的，尽管今天 Rails 有日落西山之势，但技术选型还得图个“合适”。从 GitLab 的角度看，他们本身没有复杂的运行体系，也不需要用微服务，在这样的情况下，Ruby on Rails 对他们而言反而是最佳选择。

Ruby on Rails 胜在哪

2004 年 7 月，Rails 的创始人 David Heinemeier Hansson 从 37signals 公司的项目管理工具 Basecamp 分离出 Ruby on Rails，并且以开源方式发布。

David 曾在一个采访中回顾他创造 Ruby on Rails 的心路历程，其中最大的影响来自他使用 PHP 与 Java 的深度经验。一方面，他不喜欢 Java 那种冗长、僵化、导致 Java Web 框架既复杂又难以使用的设计方式，但他赞赏 Java 良好的结构完整性。另一方面，他喜欢 PHP 易于上手的友好特性，但也发现 PHP 过于混乱，难以提供顺畅的项目开发轨道。

当时的情况就是，必须在两种都不够好的方案中做选择：要么是易于上手却混乱不堪，要么是结构良好却难以使用。这种困境不禁让人联想起服务器级操作系统（例如稳定却难以使用的 Unix）和客户端操作系统（例如简便易懂却经常崩溃的 Windows 和 MacOS）间的经典难题。

当初人人都觉得现实就是这样残酷，只能陷入二选一的艰难抉择。但后来 NeXT 在 Unix 的坚实基础之上却开发出一套漂亮、易用且流畅的 GUI。如今，“服务器级”Unix 不仅能够运行起漂亮的 GUI 桌面，甚至还能搭载在大部分手机、智能手表当中。

所以事实证明，易用性和稳定性之间并不是非此即彼的关系。Web 框架中的易用性和混乱性也是如此——明明是两条并行的车道，为啥非得纠缠在一起？

所以，David 看到的一个理想的平衡点是：既平易近人、又结构良好的 Web 框架。凭借其扎实、支持元编程的 Samlltalk 特性，再加上良好的 Unix 集成效果，Ruby 证明了自己完全可以在配合 Rails 之后成为那个正确答案。

回到 GitLab 本身，当联合创始人 Dmitriy Zaporozhets 在决定开发自己的版本控制服务器软件的时候，他其实也是 PHP 开发背景，但他没有坚持自己熟悉的方法，而是选择了 Rails。

对此，Sid Sijbrandij（GitLab 联合创始人 &现任 CEO）表示了肯定：Dmitry 的判断是有先见之明（或许也有偶然性），但不管怎么说，GitLab 也因此发展得不错。这里的部分原因可归功于 Rails 在良好架构与平易近人之间找到了平衡。

“我们不需要微服务”

在 1971 年发表的文章《关于将系统分解为模块时，所应遵循的标准》中，David L. Parnas 将模块化系统的优势总结如下：

• 有望“缩短开发时间，因为各独立小组可以在每个模块上工作，彼此之间几乎不需要沟通。”
• 有望“对单一模块做出重大变更或改进，且不影响其他模块。”
• 有望每次只学习系统中的一个模块。

Fred Brooks 在后来的《人月神话》中也强调了减少沟通需求的重要意义，认为额外的沟通开销正是“在项目后期再增加人手，反而会进一步拖慢项目进度”的主要原因之一。

Sid Sijbrandij 认为，模块化虽然受到高度追捧，但也往往神秘莫测。因此，设计师们只能从当今世界上规模最大的软件系统中汲取灵感——万维网。考虑到万维网的基本特性，它只能选择模块化构建方式。

使用独立的进程组织本地软件系统，再使用 REST 架构风格将各微服务组合起来，这样确实有助于通过操作系统强制划定模块边界。虽然这是种行之有效的严格模块化实现方式，但对应的成本也相当沉重。

Sid Sijbrandij 进一步说道，目前分布式系统也面临着类似的实现挑战与高昂成本，人们迟迟找不到在分布式计算中保障性能与可靠性的有效方法。

“简而言之，为了保证性能与可靠性，我们只能把原本以纳秒为衡量单位、且永不失败的函数调用，替换成以毫秒甚至秒为衡量单位、而且随时可能失败的网络调用。而且我们经常需要在几乎没有工具支持的情况下，跨多项服务开展跟踪，于是故障诊断变得更加困难。只有相当成熟的 DevOps 组织才能成功运行起微服务架构。总之，请大家明确一点——我们不是谷歌，我们可能搞不定那么复杂的大规模运行体系。”

而且即使是真能管理起来，还有另一个问题要注意：**架构本身的复杂度，是不是已经超出了问题本身的原始复杂度。**微服务并不能降低复杂性，所以想象中的模块化改进最终带来的很可能只是一团永远理不清头绪的乱麻。

模块化单体架构

凭借着良好架构加平易近人、再加高效操作，Rails 帮助 GitLab 开发出了模块化单体架构。模块化单体与分布式架构完全相反：它强调程序应该具有良好的结构、架构以及更高的模块化水平，其中每个进程都能稳定运行且尽可能保持简单。

Sid Sijbrandij 表示，虽然将 GitLab 构建成单体最符合项目预期，但对于具体结构取舍也绝不能太过教条。总之，架构要为需求服务，而非需求为架构服务。

虽然 Rails 确实能帮助 GitLab 有效达成目标，但它也有一些缺点，特别是在性能方面。所幸的是，GitLab 大多数代码库中只有极小一部分需要重视性能。“所以我们用 Go 自己编写了 gitaly 守护进程以处理实际 git 操作，并使用 PostgreSQL 处理非 repo 持久性数据。”Sid Sijbrandij 坦言道。

Sid Sijbrandij 表示，模块化单体架构把 GitLab 的“核心开放”（Open Core）商业模式从理论真正转化为现实。尽管 Rails 本身并不能实现这一点，这是那些出色的贡献者和工程师们完成的，但 Rails 还是为这些成功奠定了基础。

开源运动的“圣经”《大教堂与集市》里提到，为了发挥开源的真正优势，贡献者必须能够随时访问源代码。另一方面，为了在接收各种贡献的同时保持架构完整性，就需要在开放组件和封闭组件之间划开定清晰的分界线、保证代码结构良好。

如此一来，有些人可能会想问，GitLab 为什么不开发一套合适的插件接口呢？或者干脆建立基于微服务的服务接口？对于这类问题，Sid Sijbrandij 的回答是坚决的：没必要。因为这些方法不仅会在部署和集成层面，显著提升源代码轻微改动的实现难度，同时也会带来过于严格的架构实施约束。“谁能预测出未来一切可能的扩展点？根本不可能，我们也压根不打算给自己找这个麻烦。”

“凭借着这些无聊的模块化单体，用户及其他第三方开发商一样能为核心产品做出贡献、并帮助社区积累起巨大的影响力，同时保持着无与伦比的创新速度与可扩展性。”或许在 GitLab 看来，有时候，平平淡淡才是真。

参考链接：

https://about.gitlab.com/blog/2022/07/06/why-were-sticking-with-ruby-on-rails/

https://corecursive.com/045-david-heinemeier-hansson-software-contrarian/