GitLab 技术选型为何不同：坚持用 Web 框架十多年、坚决不用微服务 _小知识

文章插图

关于过气网红编程语言 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 桌面，甚至还能搭载在大部分手机、智能手表当中。

【GitLab 技术选型为何不同：坚持用 Web 框架十多年、坚决不用微服务】所以事实证明，易用性和稳定性之间并不是非此即彼的关系。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 架构风格将各微服务组合起来，这样确实有助于通过操作系统强制划定模块边界。虽然这是种行之有效的严格模块化实现方式，但对应的成本也相当沉重。