生产最佳实践：性能和可靠性

¥Production best practices: performance and reliability

本文讨论部署到生产中的 Express 应用的性能和可靠性最佳实践。

¥This article discusses performance and reliability best practices for Express applications deployed to production.

这个主题显然属于 “devops” 世界，跨越传统的开发和运营。因此，信息分为两部分：

¥This topic clearly falls into the “devops” world, spanning both traditional development and operations. Accordingly, the information is divided into two parts:

• 在你的代码中要做的事情（开发部分）：

  ¥Things to do in your code (the dev part):

  • 使用 gzip 压缩

    ¥Use gzip compression

  • 不要使用同步函数

    ¥Don’t use synchronous functions

  • 正确记录日志

    ¥Do logging correctly

  • 妥善处理异常

    ¥Handle exceptions properly

• 在你的环境/设置中要做的事情（运维部分）：

  ¥Things to do in your environment / setup (the ops part):

  • 将 NODE_ENV 设置为 “production”

    ¥Set NODE_ENV to “production”

  • 确保你的应用自动重启

    ¥Ensure your app automatically restarts

  • 在集群中运行你的应用

    ¥Run your app in a cluster

  • 缓存请求结果

    ¥Cache request results

  • 使用负载均衡器

    ¥Use a load balancer

  • 使用反向代理

    ¥Use a reverse proxy

在代码中要做的事情

¥Things to do in your code

以下是你可以在代码中执行的一些操作以提高应用的性能：

¥Here are some things you can do in your code to improve your application’s performance:

• 使用 gzip 压缩

  ¥Use gzip compression

• 不要使用同步函数

  ¥Don’t use synchronous functions

• 正确记录日志

  ¥Do logging correctly

• 妥善处理异常

  ¥Handle exceptions properly

使用 gzip 压缩

¥Use gzip compression

Gzip 压缩可以大大减小响应主体的大小，从而提高 Web 应用的速度。在你的 Express 应用中使用 compression 中间件进行 gzip 压缩。例如：

¥Gzip compressing can greatly decrease the size of the response body and hence increase the speed of a web app. Use the compression middleware for gzip compression in your Express app. For example:

const compression = require('compression')
const express = require('express')
const app = express()

app.use(compression())

对于生产中的高流量网站，实现压缩的最佳方法是在反向代理级别实现压缩（参见 使用反向代理）。在那种情况下，你不需要使用压缩中间件。有关在 Nginx 中启用 gzip 压缩的详细信息，请参阅 Nginx 文档中的 模块 ngx_http_gzip_module。

¥For a high-traffic website in production, the best way to put compression in place is to implement it at a reverse proxy level (see Use a reverse proxy). In that case, you do not need to use compression middleware. For details on enabling gzip compression in Nginx, see Module ngx_http_gzip_module in the Nginx documentation.

不要使用同步函数

¥Don’t use synchronous functions

同步函数和方法会占用正在执行的进程，直到它们返回。对同步函数的单个调用可能会在几微秒或几毫秒内返回，但在高流量网站中，这些调用加起来会降低应用的性能。避免在生产中使用它们。

¥Synchronous functions and methods tie up the executing process until they return. A single call to a synchronous function might return in a few microseconds or milliseconds, however in high-traffic websites, these calls add up and reduce the performance of the app. Avoid their use in production.

尽管 Node 和许多模块提供了它们功能的同步和异步版本，但在生产中始终使用异步版本。唯一可以证明同步功能合理的时间是在初始启动时。

¥Although Node and many modules provide synchronous and asynchronous versions of their functions, always use the asynchronous version in production. The only time when a synchronous function can be justified is upon initial startup.

每当你的应用使用同步 API 时，你都可以使用 --trace-sync-io 命令行标志来打印警告和堆栈跟踪。当然，你不想在生产中使用它，而是为了确保你的代码已准备好投入生产。有关详细信息，请参阅 node 命令行选项文档。

¥You can use the --trace-sync-io command-line flag to print a warning and a stack trace whenever your application uses a synchronous API. Of course, you wouldn’t want to use this in production, but rather to ensure that your code is ready for production. See the node command-line options documentation for more information.

正确记录日志

¥Do logging correctly

一般来说，从你的应用登录有两个原因：用于调试和记录应用活动（基本上，其他一切）。使用 console.log() 或 console.error() 将日志消息打印到终端是开发中的常见做法。但是当目标是终端或文件时 这些函数是同步的，所以它们不适合生产，除非你将输出通过管道传递给另一个程序。

¥In general, there are two reasons for logging from your app: For debugging and for logging app activity (essentially, everything else). Using console.log() or console.error() to print log messages to the terminal is common practice in development. But these functions are synchronous when the destination is a terminal or a file, so they are not suitable for production, unless you pipe the output to another program.

用于调试

¥For debugging

如果你出于调试目的进行日志记录，那么不要使用 console.log()，而是使用像 debug 这样的特殊调试模块。此模块使你能够使用 DEBUG 环境变量来控制将哪些调试消息发送到 console.error()（如果有）。为了让你的应用完全异步，你仍然希望将 console.error() 通过管道传递给另一个程序。但是，你真的不会在生产中调试，是吗？

¥If you’re logging for purposes of debugging, then instead of using console.log(), use a special debugging module like debug. This module enables you to use the DEBUG environment variable to control what debug messages are sent to console.error(), if any. To keep your app purely asynchronous, you’d still want to pipe console.error() to another program. But then, you’re not really going to debug in production, are you?

对于应用活动

¥For app activity

如果你正在记录应用活动（例如，跟踪流量或 API 调用），请使用日志库（如 Pino）而不是 console.log()，这是最快、最有效的选项。

¥If you’re logging app activity (for example, tracking traffic or API calls), instead of using console.log(), use a logging library like Pino, which is the fastest and most efficient option available.

妥善处理异常

¥Handle exceptions properly

Node 应用在遇到未捕获的异常时崩溃。不处理异常并采取适当的措施将使你的 Express 应用崩溃并离线。如果你遵循下面 确保你的应用自动重启 中的建议，那么你的应用将从崩溃中恢复。幸运的是，Express 应用的启动时间通常很短。然而，你首先要避免崩溃，为此，你需要正确处理异常。

¥Node apps crash when they encounter an uncaught exception. Not handling exceptions and taking appropriate actions will make your Express app crash and go offline. If you follow the advice in Ensure your app automatically restarts below, then your app will recover from a crash. Fortunately, Express apps typically have a short startup time. Nevertheless, you want to avoid crashing in the first place, and to do that, you need to handle exceptions properly.

为确保处理所有异常，请使用以下技术：

¥To ensure you handle all exceptions, use the following techniques:

• 使用 try-catch

  ¥Use try-catch

• 使用 promise

  ¥Use promises

在深入这些主题之前，你应该对 Node/Express 错误处理有一个基本的了解：使用错误优先回调，并在中间件中传播错误。Node 使用 “错误优先回调” 约定从异步函数返回错误，其中回调函数的第一个参数是错误对象，后面是后续参数中的结果数据。要指示没有错误，请将 null 作为第一个参数传递。回调函数必须相应地遵循错误优先回调约定才能有意义地处理错误。在 Express 中，最佳实践是使用 next() 函数通过中间件链传播错误。

¥Before diving into these topics, you should have a basic understanding of Node/Express error handling: using error-first callbacks, and propagating errors in middleware. Node uses an “error-first callback” convention for returning errors from asynchronous functions, where the first parameter to the callback function is the error object, followed by result data in succeeding parameters. To indicate no error, pass null as the first parameter. The callback function must correspondingly follow the error-first callback convention to meaningfully handle the error. And in Express, the best practice is to use the next() function to propagate errors through the middleware chain.

有关错误处理基础知识的更多信息，请参阅：

¥For more on the fundamentals of error handling, see:

• Node.js 中的错误处理

  ¥Error Handling in Node.js

使用 try-catch

¥Use try-catch

Try-catch 是一种 JavaScript 语言构造，可用于捕获同步代码中的异常。例如，使用 try-catch 来处理 JSON 解析错误，如下所示。

¥Try-catch is a JavaScript language construct that you can use to catch exceptions in synchronous code. Use try-catch, for example, to handle JSON parsing errors as shown below.

下面是使用 try-catch 处理潜在进程崩溃异常的示例。这个中间件函数接受一个名为 “params” 的查询字段参数，它是一个 JSON 对象。

¥Here is an example of using try-catch to handle a potential process-crashing exception. This middleware function accepts a query field parameter named “params” that is a JSON object.

app.get('/search', (req, res) => {
  // Simulating async operation
  setImmediate(() => {
    const jsonStr = req.query.params
    try {
      const jsonObj = JSON.parse(jsonStr)
      res.send('Success')
    } catch (e) {
      res.status(400).send('Invalid JSON string')
    }
  })
})

但是，try-catch 仅适用于同步代码。因为 Node 平台主要是异步的（特别是在生产环境中），try-catch 不会捕获很多异常。

¥However, try-catch works only for synchronous code. Because the Node platform is primarily asynchronous (particularly in a production environment), try-catch won’t catch a lot of exceptions.

使用 promise

¥Use promises

当 async 函数中抛出错误或在 async 函数中等待被拒绝的 promise 时，这些错误将传递给错误处理程序，就像调用 next(err) 一样

¥When an error is thrown in an async function or a rejected promise is awaited inside an async function, those errors will be passed to the error handler as if calling next(err)

app.get('/', async (req, res, next) => {
  const data = await userData() // If this promise fails, it will automatically call `next(err)` to handle the error.

  res.send(data)
})

app.use((err, req, res, next) => {
  res.status(err.status ?? 500).send({ error: err.message })
})

此外，你还可以为中间件使用异步函数，如果 promise 失败，路由将处理错误，例如：

¥Also, you can use asynchronous functions for your middleware, and the router will handle errors if the promise fails, for example:

app.use(async (req, res, next) => {
  req.locals.user = await getUser(req)

  next() // This will be called if the promise does not throw an error.
})

最佳做法是尽可能靠近站点处理错误。因此，虽然现在在路由中处理此问题，但最好在中间件中捕获错误并处理它，而不依赖单独的错误处理中间件。

¥Best practice is to handle errors as close to the site as possible. So while this is now handled in the router, it’s best to catch the error in the middleware and handle it without relying on separate error-handling middleware.

不该做什么

¥What not to do

你不应该做的一件事是监听 uncaughtException 事件，当异常冒泡回到事件循环时发出。为 uncaughtException 添加事件监听器将更改遇到异常的进程的默认行为；尽管出现异常，该过程仍将继续运行。这听起来像是防止应用崩溃的好方法，但在未捕获的异常后继续运行应用是一种危险的做法，不推荐这样做，因为进程的状态变得不可靠且不可预测。

¥One thing you should not do is to listen for the uncaughtException event, emitted when an exception bubbles all the way back to the event loop. Adding an event listener for uncaughtException will change the default behavior of the process that is encountering an exception; the process will continue to run despite the exception. This might sound like a good way of preventing your app from crashing, but continuing to run the app after an uncaught exception is a dangerous practice and is not recommended, because the state of the process becomes unreliable and unpredictable.

此外，使用 uncaughtException 被官方认可为 crude。所以听 uncaughtException 只是个坏主意。这就是为什么我们推荐诸如多个进程和主管之类的东西：崩溃并重新启动通常是从错误中恢复的最可靠方法。

¥Additionally, using uncaughtException is officially recognized as crude. So listening for uncaughtException is just a bad idea. This is why we recommend things like multiple processes and supervisors: crashing and restarting is often the most reliable way to recover from an error.

我们也不建议使用 domains。它通常不能解决问题，是一个已弃用的模块。

¥We also don’t recommend using domains. It generally doesn’t solve the problem and is a deprecated module.

在你的环境/设置中要做的事情

¥Things to do in your environment / setup

{#in-environment}

以下是你可以在系统环境中执行的一些操作，以提高应用的性能：

¥Here are some things you can do in your system environment to improve your app’s performance:

• 将 NODE_ENV 设置为 “production”

  ¥Set NODE_ENV to “production”

• 确保你的应用自动重启

  ¥Ensure your app automatically restarts

• 在集群中运行你的应用

  ¥Run your app in a cluster

• 缓存请求结果

  ¥Cache request results

• 使用负载均衡器

  ¥Use a load balancer

• 使用反向代理

  ¥Use a reverse proxy

将 NODE_ENV 设置为 “production”

¥Set NODE_ENV to “production”

NODE_ENV 环境变量指定应用运行的环境（通常是开发或生产）。提高性能最简单的方法之一是将 NODE_ENV 设置为 production。

¥The NODE_ENV environment variable specifies the environment in which an application is running (usually, development or production). One of the simplest things you can do to improve performance is to set NODE_ENV to production.

将 NODE_ENV 设置为 “production” 使得 Express：

¥Setting NODE_ENV to “production” makes Express:

• 缓存视图模板。

  ¥Cache view templates.

• 缓存从 CSS 扩展生成的 CSS 文件。

  ¥Cache CSS files generated from CSS extensions.

• 生成不太详细的错误消息。

  ¥Generate less verbose error messages.

测试表明 只要这样做就可以将应用性能提高三倍！

¥Tests indicate that just doing this can improve app performance by a factor of three!

如果需要编写特定于环境的代码，可以使用 process.env.NODE_ENV 检查 NODE_ENV 的值。请注意，检查任何环境变量的值都会导致性能下降，因此应谨慎进行。

¥If you need to write environment-specific code, you can check the value of NODE_ENV with process.env.NODE_ENV. Be aware that checking the value of any environment variable incurs a performance penalty, and so should be done sparingly.

在开发中，你通常在交互式 shell 中设置环境变量，例如使用 export 或 .bash_profile 文件。但一般来说，你不应该在生产服务器上这样做；相反，请使用操作系统的初始化系统 (systemd)。下一节将提供有关使用 init 系统的更多详细信息，但设置 NODE_ENV 对性能非常重要（并且易于操作），因此在此高亮。

¥In development, you typically set environment variables in your interactive shell, for example by using export or your .bash_profile file. But in general, you shouldn’t do that on a production server; instead, use your OS’s init system (systemd). The next section provides more details about using your init system in general, but setting NODE_ENV is so important for performance (and easy to do), that it’s highlighted here.

对于 systemd，请在单元文件中使用 Environment 指令。例如：

¥With systemd, use the Environment directive in your unit file. For example:

# /etc/systemd/system/myservice.service
Environment=NODE_ENV=production

有关详细信息，请参阅 在 systemd 单元中使用环境变量。

¥For more information, see Using Environment Variables In systemd Units.

确保你的应用自动重启

¥Ensure your app automatically restarts

在生产环境中，你永远不希望你的应用处于离线状态。这意味着你需要确保它在应用崩溃和服务器本身崩溃时都重新启动。尽管你希望这两种情况都不会发生，但实际上你必须通过以下方式考虑这两种可能性：

¥In production, you don’t want your application to be offline, ever. This means you need to make sure it restarts both if the app crashes and if the server itself crashes. Although you hope that neither of those events occurs, realistically you must account for both eventualities by:

• 在崩溃时使用进程管理器重新启动应用（和 Node）。

  ¥Using a process manager to restart the app (and Node) when it crashes.

• 使用操作系统提供的初始化系统在操作系统崩溃时重新启动进程管理器。也可以在没有进程管理器的情况下使用 init 系统。

  ¥Using the init system provided by your OS to restart the process manager when the OS crashes. It’s also possible to use the init system without a process manager.

如果遇到未捕获的异常，Node 应用会崩溃。你需要做的最重要的事情是确保你的应用经过良好测试并处理所有异常（有关详细信息，请参阅 正确处理异常）。但作为故障保险，建立一个机制来确保当你的应用崩溃时，它会自动重启。

¥Node applications crash if they encounter an uncaught exception. The foremost thing you need to do is to ensure your app is well-tested and handles all exceptions (see handle exceptions properly for details). But as a fail-safe, put a mechanism in place to ensure that if and when your app crashes, it will automatically restart.

使用进程管理器

¥Use a process manager

在开发中，你只需从命令行使用 node server.js 或类似的东西启动你的应用。但是在生产中这样做是灾难的根源。如果应用崩溃，它将处于离线状态，直到你重新启动它。为确保你的应用在崩溃时重新启动，请使用进程管理器。进程管理器是应用的 “container”，可促进部署、提供高可用性并使你能够在运行时管理应用。

¥In development, you started your app simply from the command line with node server.js or something similar. But doing this in production is a recipe for disaster. If the app crashes, it will be offline until you restart it. To ensure your app restarts if it crashes, use a process manager. A process manager is a “container” for applications that facilitates deployment, provides high availability, and enables you to manage the application at runtime.

除了在应用崩溃时重新启动应用之外，进程管理器还可以让你：

¥In addition to restarting your app when it crashes, a process manager can enable you to:

• 深入了解运行时性能和资源消耗。

  ¥Gain insights into runtime performance and resource consumption.

• 动态修改设置以提高性能。

  ¥Modify settings dynamically to improve performance.

• 控制集群 (pm2)。

  ¥Control clustering (pm2).

从历史上看，使用像 PM2 这样的 Node.js 进程管理器很流行。如果你希望这样做，请参阅其文档。但是，我们建议使用你的 init 系统进行进程管理。

¥Historically, it was popular to use a Node.js process manager like PM2. See their documentation if you wish to do this. However, we recommend using your init system for process management.

使用初始化系统

¥Use an init system

下一层可靠性是确保你的应用在服务器重新启动时重新启动。由于各种原因，系统仍可能出现故障。为确保你的应用在服务器崩溃时重新启动，请使用操作系统内置的初始化系统。目前使用的主要初始化系统是 systemd。

¥The next layer of reliability is to ensure that your app restarts when the server restarts. Systems can still go down for a variety of reasons. To ensure that your app restarts if the server crashes, use the init system built into your OS. The main init system in use today is systemd.

有两种方法可以通过 Express 应用使用初始化系统：

¥There are two ways to use init systems with your Express app:

• 在进程管理器中运行你的应用，并将进程管理器安装为带有 init 系统的服务。进程管理器将在应用崩溃时重新启动你的应用，而初始化系统将在操作系统重新启动时重新启动进程管理器。这是推荐的方法。

  ¥Run your app in a process manager, and install the process manager as a service with the init system. The process manager will restart your app when the app crashes, and the init system will restart the process manager when the OS restarts. This is the recommended approach.

• 直接使用 init 系统运行你的应用（和 Node）。这稍微简单一些，但是你没有获得使用进程管理器的额外优势。

  ¥Run your app (and Node) directly with the init system. This is somewhat simpler, but you don’t get the additional advantages of using a process manager.

Systemd

Systemd 是一个 Linux 系统和服务管理器。大多数主要的 Linux 发行版都采用 systemd 作为它们的默认初始化系统。

¥Systemd is a Linux system and service manager. Most major Linux distributions have adopted systemd as their default init system.

systemd 服务配置文件称为单元文件，文件名以 .service 结尾。这是一个示例单元文件，用于直接管理 Node 应用。为你的系统和应用替换 <angle brackets> 中包含的值：

¥A systemd service configuration file is called a unit file, with a filename ending in .service. Here’s an example unit file to manage a Node app directly. Replace the values enclosed in <angle brackets> for your system and app:

[Unit]
Description=<Awesome Express App>

[Service]
Type=simple
ExecStart=/usr/local/bin/node </projects/myapp/index.js>
WorkingDirectory=</projects/myapp>

User=nobody
Group=nogroup

# Environment variables:
Environment=NODE_ENV=production

# Allow many incoming connections
LimitNOFILE=infinity

# Allow core dumps for debugging
LimitCORE=infinity

StandardInput=null
StandardOutput=syslog
StandardError=syslog
Restart=always

[Install]
WantedBy=multi-user.target

有关 systemd 的更多信息，请参阅 systemd 参考手册。

¥For more information on systemd, see the systemd reference (man page).

在集群中运行你的应用

¥Run your app in a cluster

在多核系统中，你可以通过启动进程集群将 Node 应用的性能提高很多倍。集群运行应用的多个实例，理想情况下每个 CPU 内核一个实例，从而在实例之间分配负载和任务。

¥In a multi-core system, you can increase the performance of a Node app by many times by launching a cluster of processes. A cluster runs multiple instances of the app, ideally one instance on each CPU core, thereby distributing the load and tasks among the instances.

重要：由于应用实例作为单独的进程运行，因此它们不共享相同的内存空间。也就是说，对象对于应用的每个实例都是本地的。因此，你无法在应用代码中维护状态。但是，你可以使用像 Redis 这样的内存数据存储来存储与会话相关的数据和状态。这个警告基本上适用于所有形式的水平扩展，无论是多进程集群还是多物理服务器。

¥IMPORTANT: Since the app instances run as separate processes, they do not share the same memory space. That is, objects are local to each instance of the app. Therefore, you cannot maintain state in the application code. However, you can use an in-memory datastore like Redis to store session-related data and state. This caveat applies to essentially all forms of horizontal scaling, whether clustering with multiple processes or multiple physical servers.

在集群应用中，工作进程可以单独崩溃而不影响其余进程。除了性能优势之外，故障隔离是运行应用进程集群的另一个原因。每当工作进程崩溃时，始终确保记录事件并使用 cluster.fork() 生成新进程。

¥In clustered apps, worker processes can crash individually without affecting the rest of the processes. Apart from performance advantages, failure isolation is another reason to run a cluster of app processes. Whenever a worker process crashes, always make sure to log the event and spawn a new process using cluster.fork().

使用 Node 的集群模块

¥Using Node’s cluster module

Node 的 集群模块 使集群成为可能。这使主进程能够生成工作进程并在工作进程之间分配传入连接。

¥Clustering is made possible with Node’s cluster module. This enables a master process to spawn worker processes and distribute incoming connections among the workers.

使用 PM2

¥Using PM2

如果你使用 PM2 部署你的应用，那么你可以在不修改你的应用代码的情况下利用集群。你应该首先确保你的 应用是无状态的，这意味着没有本地数据存储在进程中（例如会话、websocket 连接等）。

¥If you deploy your application with PM2, then you can take advantage of clustering without modifying your application code. You should ensure your application is stateless first, meaning no local data is stored in the process (such as sessions, websocket connections and the like).

使用 PM2 运行应用时，你可以启用集群模式，以便在具有你选择的多个实例的集群中运行该应用，例如匹配计算机上可用 CPU 的数量。你可以使用 pm2 命令行工具手动更改集群中的进程数，而无需停止应用。

¥When running an application with PM2, you can enable cluster mode to run it in a cluster with a number of instances of your choosing, such as the matching the number of available CPUs on the machine. You can manually change the number of processes in the cluster using the pm2 command line tool without stopping the app.

要启用集群模式，请像这样启动你的应用：

¥To enable cluster mode, start your application like so:

# Start 4 worker processes
$ pm2 start npm --name my-app -i 4 -- start
# Auto-detect number of available CPUs and start that many worker processes
$ pm2 start npm --name my-app -i max -- start

这也可以在 PM2 进程文件（ecosystem.config.js 或类似文件）中配置，方法是将 exec_mode 设置为 cluster，将 instances 设置为要启动的工作进程数。

¥This can also be configured within a PM2 process file (ecosystem.config.js or similar) by setting exec_mode to cluster and instances to the number of workers to start.

运行后，应用可以像这样缩放：

¥Once running, the application can be scaled like so:

# Add 3 more workers
$ pm2 scale my-app +3
# Scale to a specific number of workers
$ pm2 scale my-app 2

有关使用 PM2 进行集群的更多信息，请参阅 PM2 文档中的 集群模式。

¥For more information on clustering with PM2, see Cluster Mode in the PM2 documentation.

缓存请求结果

¥Cache request results

另一个提高生产性能的策略是缓存请求的结果，这样你的应用就不会重复操作来重复服务同一个请求。

¥Another strategy to improve the performance in production is to cache the result of requests, so that your app does not repeat the operation to serve the same request repeatedly.

使用像 Varnish 或 Nginx（另请参阅 Nginx 缓存）这样的缓存服务器可以大大提高应用的速度和性能。

¥Use a caching server like Varnish or Nginx (see also Nginx Caching) to greatly improve the speed and performance of your app.

使用负载均衡器

¥Use a load balancer

无论应用如何优化，单个实例只能处理有限的负载和流量。扩展应用的一种方法是运行它的多个实例并通过负载均衡器分配流量。设置负载均衡器可以提高应用的性能和速度，并使其能够比单个实例扩展更多。

¥No matter how optimized an app is, a single instance can handle only a limited amount of load and traffic. One way to scale an app is to run multiple instances of it and distribute the traffic via a load balancer. Setting up a load balancer can improve your app’s performance and speed, and enable it to scale more than is possible with a single instance.

负载均衡器通常是一个反向代理，用于协调进出多个应用实例和服务器的流量。你可以使用 Nginx 或 HAProxy 轻松地为你的应用设置负载均衡器。

¥A load balancer is usually a reverse proxy that orchestrates traffic to and from multiple application instances and servers. You can easily set up a load balancer for your app by using Nginx or HAProxy.

使用负载平衡，你可能必须确保与特定会话 ID 关联的请求连接到发起它们的进程。这被称为会话亲和性或粘性会话，并且可以通过上面的建议解决，即使用 Redis 等数据存储来存储会话数据（取决于你的应用）。有关讨论，请参阅 使用多个 node。

¥With load balancing, you might have to ensure that requests that are associated with a particular session ID connect to the process that originated them. This is known as session affinity, or sticky sessions, and may be addressed by the suggestion above to use a data store such as Redis for session data (depending on your application). For a discussion, see Using multiple nodes.

使用反向代理

¥Use a reverse proxy

反向代理位于 Web 应用前面，除了将请求定向到应用之外，还对请求执行支持操作。它可以处理错误页面、压缩、缓存、服务文件和负载平衡等。

¥A reverse proxy sits in front of a web app and performs supporting operations on the requests, apart from directing requests to the app. It can handle error pages, compression, caching, serving files, and load balancing among other things.

将不需要了解应用状态的任务移交给反向代理可以释放 Express 来执行专门的应用任务。出于这个原因，建议在生产环境中像 Nginx 或 HAProxy 这样的反向代理后面运行 Express。

¥Handing over tasks that do not require knowledge of application state to a reverse proxy frees up Express to perform specialized application tasks. For this reason, it is recommended to run Express behind a reverse proxy like Nginx or HAProxy in production.