Zulip 生产环境部署要求与可扩展性规划：硬件、网络、凭据与大规模集群配置指南

Zulip 生产环境部署要求与可扩展性规划：硬件、网络、凭据与大规模集群配置指南

【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip

本篇技术指南以 Zulip 官方生产文档《Requirements and scalability》为核心，系统梳理在自建 Zulip 服务器前必须满足的服务器、操作系统、硬件、网络与凭据要求，并深入展开面向大规模组织（数百到数千日活用户）的容量规划、磁盘估算、灾备与 Tornado 实时推送服务分片方案。读完本文，你将能够依据预期用户规模与消息量，准确评估一台服务器是否够用、需要多大的内存与磁盘，以及何时应当拆分为应用服务器 + 独立数据库的架构。

部署前的整体要求清单

要运行一台 Zulip 生产服务器，官方要求具备以下基础条件（详见 requirements.md）：

其中各项细节将在下文逐一展开。上述要求满足后，即可按 install.md 中的完整安装流程进行生产部署。

服务器要求详解

通用要求：Zulip 应当是系统上的唯一应用

Zulip 的安装器假定系统上只运行 Zulip 这一件事：它会用apt安装系统软件包（如 nginx、PostgreSQL、Redis），并把这些服务配置为 Zulip 专用。因此官方强烈建议使用云厂商的全新实例、全新 VM、官方 Docker 镜像或专用物理机。

如果执意在托管其他服务的服务器上安装，官方明确表示无法提供支持，但留下了一些应对建议，见 install-existing-server.md。该文档提醒：Zulip 安装脚本假定它可以全权改写/etc下的配置文件，因此绝不建议安装在运行着其他 nginx 或 Django 应用的服务器上；如果确实要这样做，需要手动备份并合并 nginx 配置、处理 Puppet 冲突，属于"仅供专家操作"的高风险路径。

操作系统支持矩阵与 Ubuntu universe 仓库

Zulip 生产环境支持的操作系统为：

• Ubuntu 22.04
• Ubuntu 24.04
• Ubuntu 26.04
• Debian 12
• Debian 13

同时，任何支持 Docker 的平台都可以通过官方 Docker 镜像运行 Zulip。官方建议直接选用你熟悉的最新支持版本，可以省去日后升级操作系统的额外工作。

如果使用 Ubuntu，必须启用Ubuntu universe 软件仓库，通常执行：

sudo add-apt-repository universe sudo apt update

硬件规格：CPU、内存与磁盘

CPU 与内存：面向 100+ 用户的安装，最低需要2 个 CPU 和 4 GB RAM；用户较少的场景下，1 个 CPU、2 GB RAM 加 2 GB Swap 即可。官方明确不建议为数百用户（无论是否活跃）的团队使用 AWSt2这类 CPU 严重受限的实例。

磁盘空间：面向几十个用户的服务器至少需要 10 GB 专用空闲磁盘。官方推荐使用SSD，并避免使用限制每秒 IOPS 的云存储后端——因为该磁盘主要用于 Zulip 数据库，IOPS 直接决定数据库响应质量。更大组织的硬件建议见下文"可扩展性规划"一节。

网络与安全规格

入站访问需求汇总如下：

出站访问需求：

• 出站 HTTP(S)（80/443）：用于图片与网页预览、移动端推送通知。若禁用这些功能则无需出站 Internet 访问；
• 出站 SMTP（通常 587）：连接到你的 SMTP 服务器，用于发送各类邮件。

域名：需要一个用户访问服务器的域名（如zulip.example.com）。为了用 Certbot 签发有效 SSL 证书，以及启用 Google 认证等服务，公共 DNS 名称更简单；Zulip 也可配置使用非公共域名甚至 IP 地址作为外部主机名（但不推荐）。

反向代理：Zulip 支持部署在反向代理之后。

SSRF 防护（Smokescreen）：Zulip 默认配置了 Smokescreen 出站 HTTP 代理，用于防御 SSRF（服务端请求伪造）攻击——防止用户诱导 Zulip 服务器向内网私有资源发起请求。如果你的网络已有自己的出站 HTTP 代理，Zulip 也支持改用该代理。相关配置项位于/etc/zulip/zulip.conf的[http_proxy]段：

[http_proxy] host = 127.0.0.1 # 出站 CONNECT 代理主机，默认 localhost port = 4750 # 出站 CONNECT 代理端口，默认 4750 allow_addresses = 10.17.17.17 # 允许访问的私网地址（默认拒绝全部私网地址）

按 system-configuration.md 的说明，allow_addresses、allow_ranges、deny_addresses、deny_ranges均为逗号分隔的 IP 或 CIDR 列表；默认拒绝所有私网地址（如 127.0.0.0/8、192.168.0.0/16），允许规则优先于拒绝规则。修改zulip.conf后需以 root 运行zulip-puppet-apply才能生效。Smokescreen 也可作为独立 Puppet 类zulip::profile::smokescreen部署到独立主机，供多前端服务器部署共用。

部署前需要准备的凭据

SSL 证书

Zulip 服务器需要为其域名准备一张 SSL 证书。最推荐、最简单的做法是使用安装器的--certbot选项（详见 ssl-certificates.md）：它会自动获取证书并配置 cron 任务持续自动续期。

对于测试环境，安装器还提供更省事的--self-signed-cert选项（ssl-certificates.md）自动生成自签名证书——它不适合生产使用（除非服务器位于反向代理之后），但非常适合测试。如果希望以其他方式获取证书，可参考完整的 SSL 证书文档。

出站邮件（SMTP）

Zulip 需要可用于发送出站邮件的 SMTP 凭据，典型用途包括：注册流程中的邮箱确认邮件、消息通知邮件、密码重置等。如果没有现成的出站 SMTP 方案，可参考 email.md 中关于免费出站 SMTP 选项与原型验证方案的介绍。

安装器用法衔接：从要求到安装

满足上述要求后即可执行安装。核心安装命令如下（完整过程见 install.md）：

cd $(mktemp -d) curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz tar -xf zulip-server-latest.tar.gz

随后以 root 运行安装器：

[ "$(whoami)" != "root" ] && sudo -s ./zulip-server-*/scripts/setup/install --push-notifications --certbot \ --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

安装器常用选项：

高级安装器选项（详见 deployment.md）：

• --postgresql-version：指定要安装的 PostgreSQL 版本，当前支持 14、15、16、17、18，默认 18；
• --postgresql-database-name=exampledbname：自定义数据库名，默认zulip，仅首次安装可设置；
• --postgresql-database-user=exampledbuser：自定义数据库用户，默认zulip，仅首次安装可设置；
• --no-init-db：跳过数据库初始化（已有 Zulip 数据库时使用）；
• --no-overwrite-settings：保留已有的/etc/zulip配置文件。

安装器会创建zulip用户、建立/home/zulip/deployments/目录（current符号链接指向当前部署代码树）、安装依赖、配置 PostgreSQL/RabbitMQ/Memcached/Redis 等第三方服务并初始化数据库。

可扩展性规划

本节面向更大的组织（尤其是>1000 用户或 500+ 日活用户）给出容量规划指引。这些建议偏保守，旨在覆盖各种可能不适配你具体场景的使用模式。

资源需求的三个决定参数

Zulip 的资源需求主要取决于三个参数：

1. 日活用户数（例如全员都是员工时即为员工数）；
2. 总用户账户数（可以远大于日活数）；
3. 消息量（message volume）。

服务器角色划分：应用服务器与数据库服务器

在下面的讨论中，配置最多涉及两类服务器：

• 应用服务器：运行 Django、Tornado、RabbitMQ、Redis、Memcached 等；
• 数据库服务器：运行 PostgreSQL。

其中 Django 主导应用服务器的资源需求。你可以把每个服务都放到独立系统上（Docker 部署就是这样做的），但对大多数场景而言这么做几乎没有可扩展性收益。拆分部署的细节见 deployment.md：Zulip 完整支持每个顶层服务独立成机，/etc/zulip/settings.py中有各服务的远程配置内联说明。

这一设计在源码层面有直接印证：默认单机部署对应 Puppet 类zulip::profile::standalone（见 standalone.pp），它只是将"除数据库外的一切"（standalone_nodb）与 PostgreSQL 合并在同一台机器上：

zulip::profile::standalone ├── zulip::profile::standalone_nodb │ ├── zulip::profile::app_frontend │ ├── zulip::profile::memcached │ ├── zulip::profile::rabbitmq │ ├── zulip::profile::redis │ └── zulip::localhost_camo └── zulip::profile::postgresql

拆分部署时，只需在目标机器上分别应用zulip::profile::postgresql（数据库机）、zulip::profile::standalone_nodb（应用机）等类——puppet/zulip/manifests/profile/ 目录下的每个 profile 类都允许独立配置到一台主机上。

面向日活用户的 RAM 规模推荐

专用数据库：对于数百日活用户的安装，官方推荐使用远程 PostgreSQL 数据库，但并非强制。

CPU：由于 Zulip 在请求延迟优化上做了大量工作，应用服务器的 CPU 占用被重度优化；大多数内存充足的服务器 CPU 也足够，因此 CPU 很少成为瓶颈。对于带独立数据库的大型安装，推荐应用服务器选用高 CPU 实例，数据库选用数据库优化型（通常是低 CPU、高内存）实例。

应用服务器磁盘：优先 S3 后端

规模扩大后，官方推荐使用 S3 文件上传后端存储上传文件。启用 S3 后端时，建议为操作系统、Zulip 软件、日志和临时/空闲空间准备50 GB 磁盘；由于上传文件会在本地缓存，如果大量使用上传文件，可能需要更多磁盘。

S3 后端的本地缓存由 nginx 维护，有三个可调参数（upload-backends.md）：

• s3_memory_cache_size：缓存索引的内存大小，默认 1 MB（约可容纳 8 千个条目）；
• s3_disk_cache_size：缓存内容的磁盘大小，默认 200 MB；
• s3_cache_inactive_time：条目自上次使用后的最长缓存时间，默认 30 天。

这些默认值对中小规模部署通常足够；大型部署或图片密集型场景应提高s3_disk_cache_size（可能达到数 GB），并按磁盘缓存可容纳的文件数估算是否要提高s3_memory_cache_size。S3 存储与 Zulip 服务器距离较远时也应增大缓存，因为缓存未命中代价更高。此外可通过S3_UPLOADS_STORAGE_CLASS使用 S3 Intelligent-Tiering 等存储类降低成本。

数据库磁盘规划

数据库强烈推荐使用SSD。磁盘容量估算：

• 大多数消息接收者 <100 人的场景：每100 万条历史消息约需 10 GB，另加每 1000 用户 1 GB；
• 若大部分消息发送给订阅人数达 1 万+ 的公共频道（如 chat.zulip.org 的场景）：在按上面计算的基础上，再按每 1000 用户账户 × 每 100 万条公共频道消息约增加 20 GB估算。

真实规模参考案例

文档给出了一组真实数据作为参照：Zulip 开发社区服务器拥有12K 用户账户（约 300 日活）和80 万条历史消息（其中 40 万条发往公共频道）时，采用默认配置的单机部署：16 GB RAM、4 核（几乎始终空闲），数据库占用磁盘约100 GB。

灾难恢复：warm spare 与 PostgreSQL 温备

可以方便地运行一台温备（warm spare）应用服务器与一台温备数据库（利用 PostgreSQL 流复制温备）。温备应用服务器需要满足：

• 持有/etc/zulip配置的副本；
• 同步LOCAL_UPLOADS_DIR，或改用 S3 上传后端。

温备数据库在/etc/zulip/zulip.conf中配置主库与复制用户：

[postgresql] replication_user = replicator replication_primary = hostname-of-primary.example.com

若使用密码认证，可在/etc/zulip/zulip-secrets.conf设置postgresql_replication_password。配置后运行zulip-puppet-apply重建 PostgreSQL 配置，用 wal-g 的env-wal-g backup-fetch或pg_basebackup拉取基准备份，备库即开始实时复制。主库故障时用pg_ctl promote提升温备为新主库，并确保旧主库不会重新上线造成双主分歧。

如需更快故障切换（无需重启 Zulip 服务），可在/etc/zulip/settings.py配置逗号分隔的远程 PostgreSQL 服务器列表，Zulip 会依次选择第一个可写入（即非只读副本）的服务器：

REMOTE_POSTGRES_HOST = 'primary-database-host,warm-standby-host'

远程数据库的常规配置项还包括REMOTE_POSTGRES_PORT（通常 5432）与REMOTE_POSTGRES_SSLMODE；使用密码认证时在/etc/zulip/zulip-secrets.conf中设置postgres_password。完整流程见 postgresql.md。

大规模组织的 Tornado 分片

对于数千日活用户的服务器，Zulip 支持对其实时推送服务 Tornado 进行分片（sharding），既可按组织（realm）分片（适合托管多个组织），也可按用户 ID 分片（适合单个超大型组织）。配置位于/etc/zulip/zulip.conf的[tornado_sharding]段（system-configuration.md）：

• 每个 Tornado 实例监听独立端口，从 9800 起依次递增；
• 单个 Tornado 实例通常可承载1000–1500 并发活跃用户（取决于消息发送量）；
• 组织可按键名（子域名或完全限定主机名）分配端口：

[tornado_sharding] 9800 = realm-a realm-b 9801 = realm-c 9802 = realm-host.example.net

• 也可通过正则表达式按完全限定主机名分配：

[tornado_sharding] 9800_regex = ^realm-(a|b)\.example\.com$ 9801_regex = ^other(-option)?\.example.com$

• 超大型组织可用_连接多个端口，横跨多个 Tornado 分片：

[tornado_sharding] 9800 = small-realm 9801_9802 = very-large-realm

注意：运行scripts/zulip-puppet-apply之后，任何分片变更还需额外运行scripts/refresh-sharding-and-restart才能生效。

需要特别强调的是：将单个 Zulip 组织（realm）的流量分散到多台应用服务器时需要非常谨慎，这正是官方在大多数需要冗余的场景下推荐"热备（hot spare）而非负载均衡"的原因。

更多可扩展性参考

对影响 Zulip 可扩展性的技术细节感兴趣的读者，可以进一步阅读性能与可扩展性设计文档。若仍有可扩展性疑问或不确定 Zulip 是否适合你的场景，建议直接联系 Zulip 的销售或支持团队获取协助；日常运维也可参考部署选项总览、系统配置参考与生产设置指南。

小结

Zulip 的生产部署要求可以归纳为一条清晰的主线：先用"日活用户数、总账户数、消息量"三个参数估算规模，再对照内存/磁盘/CPU 推荐表选择单机或双机（应用 + 数据库）架构，最后补齐网络端口、SSL 证书与 SMTP 三项前置条件。对于数千日活用户级别的组织，Zulip 还提供了 Tornado 分片、warm standby 温备与独立服务拆分等成熟的横向扩展手段，使得从几十人的团队协作到大型开源社区的高负载场景都能找到对应的部署方案。

【免费下载链接】zulipZulip server and web application. Open-source team chat that helps teams stay productive and focused.项目地址: https://gitcode.com/GitHub_Trending/zu/zulip