如何选择合适的后端框架（多年经验总结）

近年来，后端框架的选择一直是争论不休的话题。其实这个问题并没有标准答案，没有哪个框架是绝对完美的，它们各有优缺点。最终的选择很大程度上取决于具体需求、问题领域以及待开发的平台。

我们常遇到的另一个错误前提是，我们倾向于选择某个框架，仅仅因为它流行。然而，流行并不一定意味着更好，一切都取决于实际需求。我们必须摒弃这种观念：无论问题是什么，我们总是想推荐自己偏爱的框架。我们常常建议所有人使用我们当下最流行的技术，将其视为开发任何应用程序的万能灵药，却从未真正了解过实际需求。这种做法我们必须摒弃，彻底清除。

每个框架都有其优缺点，绝对没有例外。如果有人否认这一点，那是因为他们从未遇到过问题，但这并不意味着问题不存在。那么，我们在选择后端框架时应该遵循哪些参数呢？

我们可以说，存在以下几个参数：

• 约定与配置
• 性能/速度
• 社区
• 编程语言

约定与配置

为了在做出选择时考虑到这一点，我们必须了解这个特定术语指的是什么。

顾名思义，约定是一种标准化的、通用的实践，通常被某个社群所采纳。当我们把这个概念应用到后端框架领域时，它指的是那些拥有标准且预定义功能的框架，开发者无需自行实现这些功能。例如，那些自带会话管理、预定义中间件、身份验证服务、路由、模型-视图-控制器（MVC）架构等功能的框架。这些通常是最流行的框架，例如 Django、Rails 和 Lavarel。

现在，与框架的传统做法相反，配置型框架通常将大部分配置工作交给开发者。它们通常没有太多预先定义的“约定”，而是将这些实现留给开发者自行决定。例如，它们可能没有身份验证模块、预定义的数据库管理接口等等。控制权完全掌握在用户手中。例如，Python 的 Tornado、Go 的 Fasthttp 或 NodeJS 的 Express 就是如此。

通常，这种区别也可以在其他一些社区中找到，例如全栈框架与REST框架。

现在，要做出决定，正如我们之前提到的，我们必须了解每个选项的利弊，以及它的优点和缺点。

习俗

• 优点：
  • 这些框架非常高效，因为它们引入了许多已经预定义或实现的功能，开发团队无需浪费时间进行开发。
  • 如果一个框架被广泛使用，它通常会得到一个庞大而活跃的社区的支持，这个社区会指导或推动框架的发展，使其遵循行业最佳实践。这对于那些对该框架了解不多的团队来说尤其有利。
• 缺点：
  • 现在，这些预定义的功能通常以黑盒的形式打包。这意味着部分代码或功能对开发者来说是被混淆或隐藏的。正如那句名言所说，它就像魔法一样运作。但这为什么会产生负面影响呢？很简单，如果我们想要改变这些标准模块的工作方式，就会面临挑战，因为这意味着要修改框架的默认行为，而这绝非易事。
  • 调试起来要困难得多，因为任何发现的错误都可能隐藏在那些黑盒子里。
  • 由于这类框架因其优点和缺点而广为人知，攻击手段可能非常多，因此可能需要额外的安全措施。但好的安全策略可以解决所有问题，对吧？

配置

• 优点：
  • 由于其特性，它们可以适应许多问题或需求，因为配置留给了用户，开发人员可以实现更多自定义流程，而使用典型的约定框架则很难做到这一点。
  • 与框架相比，它们的黑盒更少，因此更容易调试。
  • 总的来说，它们效率更高，因为它们只需使用最少的资源即可，避免过载。通常，我们常常试图用枪打死一只苍蝇，我们想用一个框架来解决一个小问题，而我们甚至不会使用其 50% 的预定义功能。
• 缺点：
  • 显然，根据所需功能的不同，这类框架可能会导致标准化功能的开发时间稍长一些，这可能会影响团队的生产力。
  • 对于新手程序员来说，根据所开发平台的类型，这可能会带来一些复杂性问题，因为他们没有框架通常提供的规范指导。因此，开发人员可能会遇到一些系统设计方面的挑战。例如，如果框架没有定义文件结构，最终，如果设计决策不当，项目可能会变得一团糟。

因此，我们可以得出结论：如果您想要实现标准功能，例如数据库连接、身份验证、CRUD 管理等服务，那么约定式框架通常是更好的选择。相反，如果我们需要为业务实现具有非常特定功能的 API，并且需要快速扩展，那么使用配置式框架可能更合适。正如我们将在下一节中看到的，这些框架通常更注重性能。举例来说，如果我们尝试用 C 语言实现 WebSocket，那么改用 NodeJS 将会困难得多。

如果生产力是您当前工作环境中的关键指标（例如在初创公司中），那么最佳选择是采用约定俗成的框架，同时考虑到开发时间会更短。此外，使用最流行的框架可以确保您不会遇到开发人员短缺的问题。有时，这会影响开发时间和相关成本。

框架约定

• Django（Python）
• Ruby on Rails（Ruby）
• ASP.NET
• Spring（Java）
• Lavarel（PHP）
• CakePHP

框架配置

• Tornado（Python）
• FastHttp(Go)
• FastAPI（Python）
• 凤凰（灵药）
• Express（NodeJS）
• NextJS（NodeJS）是配置和约定相结合的产物。
• 金（Go）

性能/速度

这些指标虽然至关重要，但也最难衡量，因为性能/速度的概念涵盖多个方面。为了便于理解，我们可以将其定义为请求对系统资源（例如内存、CPU、磁盘等）的影响。

另一个重点是能够在一定时间内处理并发请求的能力。

最后，虽然并非每个应用程序都需要数据库，但了解我们的框架与数据库之间的关系有多重要也至关重要。因为这会根据我们的需求极大地影响性能。

那么，如何根据性能或速度来选择框架呢？为此，了解框架将要面对的请求数量至关重要。每秒、每分钟或每小时处理数千个请求的情况并不相同。因此，在选择框架之前，最好查看一些基准测试（我建议这样做），了解它在我们需要处理的请求数量下的表现。例如，如果我们需要构建一个 API，每秒从多个传感器接收数千个数据，那么像 Django 或 Rails 这样的框架可能并非最佳选择，选择像 Go 的 fasthttp 这样并发处理能力更强的框架可能更好。如果我们需要创建一个酒店预订系统，那么像 Lavarel、Rails 或 Django 这样的框架可能更合适，因为它们具有很强的健壮性，而且我们的主要目标并非追求极致的性能。

您可以在这里查看一个知名的框架基准测试。

正如你所见，如果需要处理大量的每秒请求，传统框架的性能并不理想。当然，我们必须考虑问题的具体情况，因为绝大多数开发者可能并不需要处理如此高的并发量。如果你需要更多关于后端框架基准测试的信息，可以点击这里查看。

数据库连接以及框架如何与它们交互至关重要。目前，许多框架都内置了 ORM（对象关系映射），它提供了一个允许对关系数据库进行查询的接口，但代价是增加了额外的层级，从而影响连接和查询的性能。因此，如果我们的应用程序需要执行非常复杂的查询或同时维护多个连接，最好使用一个能够提供更大自由度且层级较少的框架。

在这里我们可以看到一个基准测试，它发出 REST API 调用，而每个调用又会向 AWS 中的 c3.large (R10) / m1.large (R1 至 R9) EC2 实例的数据库发出 20 个查询。

正如你所看到的，情况与之前的图表类似，我们可以看到传统框架和大多数特定框架之间存在显著差异，但这种差异未必能转化为优势，因为寻找一位 Rust 开发人员可能比寻找一位 Spring 或 Rails 开发人员要困难得多。例如，如果我们想实现一个预订系统，使用 Rust 将会变得极其复杂，因为我们需要重新发明轮子。因此，我们可以看到其中的权衡：生产力与性能。

社区

在选择框架时，这一点至关重要，因为拥有更庞大的社区意味着它能提供更好的支持或文档。此外，程序员可能遇到的错误也可能已被其他人记录/解决。

编程语言

Web 开发已经是一个被广泛研究的课题，因此，我们看到许多框架都遵循某种约定、全球标准，它们的结构或工作方式非常相似。因此，在选择框架时，我们可以将其简化为选择我们想要使用的编程语言。而要做出这个决定，需要考虑几个变量，例如复杂性或学习曲线、社区、流行度、性能、领域或用途。

举个例子，如果我们需要开发一个硬件控制器，就应该使用像 C 语言这样接近机器语言的语言，而不是 Python 这种脚本语言。但如果我们要实现高级功能，高级语言则更合适。例如，如果需要处理并发，Perl 或 Earlang 就是不错的选择。

结论

我认为有两个关键点可以帮助我们做出决定：绩效与效率。一般来说，如果你在一家初创公司，正在开发最小可行产品（MVP）或标准产品，最好根据效率、预定义功能和标准来选择框架。这将对资金和人力资源都产生影响。在这种情况下，我会倾向于采用约定式框架。

一般来说，像 Facebook、Google、Twitter 等公司，生产力不成问题。它们拥有大量资源和数百名软件工程师，甚至有能力构建自己的框架。React 就是一个完美的例子，它最初是 Facebook 内部的一个工具，如今已成为全球标准。因此，如果你拥有一个庞大的团队、充足的时间，并且所处领域对性能要求极高，我会倾向于选择一个能够提供最大灵活性的框架，而这种灵活性正是由配置类型决定的。

我想先提一点建议：永远不要说一定要用我偏爱的框架或编程语言。编程中不存在完美，也永远不会存在。如果你问软件工程师“最好的编程语言是什么？”，他回答的第一个词是“视情况而定”，那么这位工程师的资历就可能很高。

如果你喜欢我的内容或者觉得它对你有帮助，可以请我喝杯咖啡来鼓励我创作更多内容。

欢迎在评论区向我提问，或者如果您对如何选择框架有任何建议，也请告诉我。

我把这篇文章做成了一个YouTube视频。欢迎订阅，我会制作关于全栈技术的视频内容。

另外，欢迎在 dev. 上关注我，以便在新帖子发布时立即收到通知。