后端系统概览

当用户与应用交互时，他们通常是在与一个客户端界面通信，例如网页浏览器或移动应用。该客户端通常不包含系统的核心逻辑。相反，它会向后端系统发送请求，由后端系统负责完成繁重的工作。

后端系统位于客户端和数据层之间。它的职责是接收请求，按照应用的规则进行处理，并返回结果。这个过程通常包括验证输入、执行业务逻辑，以及检索或修改存储在数据库或其他存储系统中的数据。

例如，当用户登录网站时，客户端会将登录凭据发送到后端。后端验证这些凭据，查询数据库中的用户记录，并返回一个响应，说明身份验证是否成功。

从本质上讲，后端充当应用的决策引擎。它通过应用逻辑并协调数据库、缓存或外部服务等底层系统，将传入请求转换为有意义的响应。

大多数后端系统都遵循分层结构，将职责分散到系统的不同部分。不是把所有功能都放在一个庞大的代码库中，而是让每一层专注于解决特定问题。

API 层 作为后端的入口点。它接收来自浏览器或移动应用等客户端的请求，验证输入，并格式化返回给客户端的响应。

应用层 包含系统的业务逻辑。这里实现规则、工作流和决策过程。例如，应用层可能决定订单如何处理，或者用户是否有权限执行某个操作。

数据层 负责持久化存储。它与数据库或存储系统通信，读取和写入应用运行所需的信息。

在这些组件之下的是 基础设施层，它为系统提供运行环境。这包括托管后端的服务器、容器、操作系统和云服务。

这种分层结构有助于工程师保持系统的模块化，使其在应用增长时更容易维护、扩展和横向扩展。

当客户端向后端系统发送请求时，它会经过多个处理步骤，而不是直接跳到数据库或应用逻辑。

请求首先以 HTTP request 的形式到达服务器，此时 router 会决定应用的哪一部分应该处理它。在到达主逻辑之前，请求可能会经过 middleware，执行身份验证检查、日志记录或验证等任务。

一旦到达 handler，后端就会执行 business logic，通常会组织在 controllers 和 services 中。这些组件会处理请求，并可能执行 database queries 来读取或更新存储的数据。

处理完成后，后端会构造一个 response 并将其发送回客户端。

后端工程师负责让应用正常运行的内部系统。他们的工作包括构建 API、实现业务逻辑、管理数据存储，以及维护后端服务。

同时，工程师必须在现实世界的约束下设计系统。应用必须快速响应（performance）、能够处理不断增长的需求（scalability），并且在组件发生故障时仍保持可用（reliability）。

系统还必须保护敏感信息（security），同时保持易于理解，并能适应未来开发（maintainability）。

由于这些目标往往彼此冲突，后端工程需要在保持系统稳定和高效的同时，权衡各种取舍。

单体架构将所有应用组件放在一个单一的可部署系统中。API 层、应用逻辑和数据库交互通常都存在于同一个代码库中，并作为一个服务运行。许多早期阶段的应用都会从这种方式开始，因为开发和部署更简单。

在单体架构中，组件通常共享同一个数据库，并作为一个整体一起部署。虽然这种方式在初期可能更容易构建和维护，但随着系统变大，它会变得更难扩展或修改。

微服务架构采用了不同的方法。应用不再是一个大型系统，而是被拆分为多个更小的服务。每个服务专注于特定职责，并且可以独立开发、部署和扩展。

这些服务通过服务间通信相互交流，通常使用 API 或消息传递系统。这使大型系统能够更灵活地扩展和演进，但也会在网络、部署和系统协调方面引入额外的复杂性。

在真实应用中，后端系统很少独立运行。相反，它们会协调多个底层系统协同工作，以提供服务。

一个典型的后端可能会与用于持久化存储的数据库、用于更快读取的缓存、用于后台处理的消息队列以及用于第三方集成的外部 API进行通信。后端决定何时以及如何使用这些组件。

这个协调层还会执行重要规则。它会验证传入请求，确保用户有权限执行操作，并在系统中的数据发生变化时保持一致性。

从系统设计的角度来看，后端是应用的控制中心。它管理信息在各个基础设施组件之间的流动，同时提供一个干净的接口，供客户端安全地交互。