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类别最低要求机器一台专用机器或 VM也可以是官方 Docker 镜像操作系统Ubuntu 22.04 / 24.04 / 26.04或 Debian 12 / 13CPU 架构x86-64 或 aarch64内存至少 2 GB RAM若内存不足 5 GB官方要求配置交换空间Swap建议 2 GB内存100 用户4 GB RAM并配备 2 个 CPU磁盘10 GB 可用空间考虑到操作系统本身占用总计约需 25 GB 磁盘网络DNS 中有可用的主机名hostname凭据用于发送邮件的 SMTP 凭据其中各项细节将在下文逐一展开。上述要求满足后即可按 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.04Ubuntu 24.04Ubuntu 26.04Debian 12Debian 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 直接决定数据库响应质量。更大组织的硬件建议见下文可扩展性规划一节。网络与安全规格入站访问需求汇总如下端口用途说明443HTTPS用户访问 Zulip 主服务端口可在 deployment.md 中配置为其他值80HTTP可选Zulip 只通过 HTTPS 提供服务收到 HTTP 请求会自动 301 重定向到 HTTPS25SMTP可选仅在启用邮件网关incoming email integration时需要4369应被防火墙保护epmdErlang 服务不支持仅绑定 localhost暴露它会让远程用户探测到服务器正在运行 RabbitMQ 及其端口不会泄露更多信息22SSH远程管理Zulip 自身不要求 SSH但绝大多数安装都会需要它出站访问需求出站 HTTP(S)80/443用于图片与网页预览、移动端推送通知。若禁用这些功能则无需出站 Internet 访问出站 SMTP通常 587连接到你的 SMTP 服务器用于发送各类邮件。域名需要一个用户访问服务器的域名如zulip.example.com。为了用 Certbot 签发有效 SSL 证书以及启用 Google 认证等服务公共 DNS 名称更简单Zulip 也可配置使用非公共域名甚至 IP 地址作为外部主机名但不推荐。反向代理Zulip 支持部署在反向代理之后。SSRF 防护SmokescreenZulip 默认配置了 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 证书文档。出站邮件SMTPZulip 需要可用于发送出站邮件的 SMTP 凭据典型用途包括注册流程中的邮箱确认邮件、消息通知邮件、密码重置等。如果没有现成的出站 SMTP 方案可参考 email.md 中关于免费出站 SMTP 选项与原型验证方案的介绍。安装器用法衔接从要求到安装满足上述要求后即可执行安装。核心安装命令如下完整过程见 install.mdcd $(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 \ --emailYOUR_EMAIL --hostnameYOUR_HOSTNAME安装器常用选项选项作用--emailit-teamexample.com维护者的真实邮箱会显示在自动邮件、帮助页与错误页上--hostnamezulip.example.com用户可访问的域名会成为设置中的EXTERNAL_HOST非 ASCII 域名需使用 Punycode--certbot自动获取 SSL 证书并配置自动续期--push-notifications/--no-push-notifications注册移动推送通知服务需同意服务条款--no-submit-usage-statistics关闭启用推送通知时默认提交的汇总使用统计--agree-to-terms-of-service配合--push-notifications在脚本化安装中跳过服务条款交互--self-signed-cert生成自签名证书适合测试环境高级安装器选项详见 deployment.md--postgresql-version指定要安装的 PostgreSQL 版本当前支持 14、15、16、17、18默认 18--postgresql-database-nameexampledbname自定义数据库名默认zulip仅首次安装可设置--postgresql-database-userexampledbuser自定义数据库用户默认zulip仅首次安装可设置--no-init-db跳过数据库初始化已有 Zulip 数据库时使用--no-overwrite-settings保留已有的/etc/zulip配置文件。安装器会创建zulip用户、建立/home/zulip/deployments/目录current符号链接指向当前部署代码树、安装依赖、配置 PostgreSQL/RabbitMQ/Memcached/Redis 等第三方服务并初始化数据库。可扩展性规划本节面向更大的组织尤其是1000 用户或 500 日活用户给出容量规划指引。这些建议偏保守旨在覆盖各种可能不适配你具体场景的使用模式。资源需求的三个决定参数Zulip 的资源需求主要取决于三个参数日活用户数例如全员都是员工时即为员工数总用户账户数可以远大于日活数消息量message volume。服务器角色划分应用服务器与数据库服务器在下面的讨论中配置最多涉及两类服务器应用服务器运行 Django、Tornado、RabbitMQ、Redis、Memcached 等数据库服务器运行 PostgreSQL。其中 Django 主导应用服务器的资源需求。你可以把每个服务都放到独立系统上Docker 部署就是这样做的但对大多数场景而言这么做几乎没有可扩展性收益。拆分部署的细节见 deployment.mdZulip 完整支持每个顶层服务独立成机/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 规模推荐日活用户规模RAM 推荐25 日活用户4 GB100 日活用户8 GB400 日活用户应用服务器 16 GB 数据库 16 GB2000 日活用户应用服务器 32 GB 数据库 32 GB更大规模大致呈线性扩展专用数据库对于数百日活用户的安装官方推荐使用远程 PostgreSQL 数据库但并非强制。CPU由于 Zulip 在请求延迟优化上做了大量工作应用服务器的 CPU 占用被重度优化大多数内存充足的服务器 CPU 也足够因此 CPU 很少成为瓶颈。对于带独立数据库的大型安装推荐应用服务器选用高 CPU 实例数据库选用数据库优化型通常是低 CPU、高内存实例。应用服务器磁盘优先 S3 后端规模扩大后官方推荐使用 S3 文件上传后端存储上传文件。启用 S3 后端时建议为操作系统、Zulip 软件、日志和临时/空闲空间准备50 GB 磁盘由于上传文件会在本地缓存如果大量使用上传文件可能需要更多磁盘。S3 后端的本地缓存由 nginx 维护有三个可调参数upload-backends.mds3_memory_cache_size缓存索引的内存大小默认 1 MB约可容纳 8 千个条目s3_disk_cache_size缓存内容的磁盘大小默认 200 MBs3_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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类别最低要求机器一台专用机器或 VM也可以是官方 Docker 镜像操作系统Ubuntu 22.04 / 24.04 / 26.04或 Debian 12 / 13CPU 架构x86-64 或 aarch64内存至少 2 GB RAM若内存不足 5 GB官方要求配置交换空间Swap建议 2 GB内存100 用户4 GB RAM并配备 2 个 CPU磁盘10 GB 可用空间考虑到操作系统本身占用总计约需 25 GB 磁盘网络DNS 中有可用的主机名hostname凭据用于发送邮件的 SMTP 凭据其中各项细节将在下文逐一展开。上述要求满足后即可按 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.04Ubuntu 24.04Ubuntu 26.04Debian 12Debian 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 直接决定数据库响应质量。更大组织的硬件建议见下文可扩展性规划一节。网络与安全规格入站访问需求汇总如下端口用途说明443HTTPS用户访问 Zulip 主服务端口可在 deployment.md 中配置为其他值80HTTP可选Zulip 只通过 HTTPS 提供服务收到 HTTP 请求会自动 301 重定向到 HTTPS25SMTP可选仅在启用邮件网关incoming email integration时需要4369应被防火墙保护epmdErlang 服务不支持仅绑定 localhost暴露它会让远程用户探测到服务器正在运行 RabbitMQ 及其端口不会泄露更多信息22SSH远程管理Zulip 自身不要求 SSH但绝大多数安装都会需要它出站访问需求出站 HTTP(S)80/443用于图片与网页预览、移动端推送通知。若禁用这些功能则无需出站 Internet 访问出站 SMTP通常 587连接到你的 SMTP 服务器用于发送各类邮件。域名需要一个用户访问服务器的域名如zulip.example.com。为了用 Certbot 签发有效 SSL 证书以及启用 Google 认证等服务公共 DNS 名称更简单Zulip 也可配置使用非公共域名甚至 IP 地址作为外部主机名但不推荐。反向代理Zulip 支持部署在反向代理之后。SSRF 防护SmokescreenZulip 默认配置了 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 证书文档。出站邮件SMTPZulip 需要可用于发送出站邮件的 SMTP 凭据典型用途包括注册流程中的邮箱确认邮件、消息通知邮件、密码重置等。如果没有现成的出站 SMTP 方案可参考 email.md 中关于免费出站 SMTP 选项与原型验证方案的介绍。安装器用法衔接从要求到安装满足上述要求后即可执行安装。核心安装命令如下完整过程见 install.mdcd $(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 \ --emailYOUR_EMAIL --hostnameYOUR_HOSTNAME安装器常用选项选项作用--emailit-teamexample.com维护者的真实邮箱会显示在自动邮件、帮助页与错误页上--hostnamezulip.example.com用户可访问的域名会成为设置中的EXTERNAL_HOST非 ASCII 域名需使用 Punycode--certbot自动获取 SSL 证书并配置自动续期--push-notifications/--no-push-notifications注册移动推送通知服务需同意服务条款--no-submit-usage-statistics关闭启用推送通知时默认提交的汇总使用统计--agree-to-terms-of-service配合--push-notifications在脚本化安装中跳过服务条款交互--self-signed-cert生成自签名证书适合测试环境高级安装器选项详见 deployment.md--postgresql-version指定要安装的 PostgreSQL 版本当前支持 14、15、16、17、18默认 18--postgresql-database-nameexampledbname自定义数据库名默认zulip仅首次安装可设置--postgresql-database-userexampledbuser自定义数据库用户默认zulip仅首次安装可设置--no-init-db跳过数据库初始化已有 Zulip 数据库时使用--no-overwrite-settings保留已有的/etc/zulip配置文件。安装器会创建zulip用户、建立/home/zulip/deployments/目录current符号链接指向当前部署代码树、安装依赖、配置 PostgreSQL/RabbitMQ/Memcached/Redis 等第三方服务并初始化数据库。可扩展性规划本节面向更大的组织尤其是1000 用户或 500 日活用户给出容量规划指引。这些建议偏保守旨在覆盖各种可能不适配你具体场景的使用模式。资源需求的三个决定参数Zulip 的资源需求主要取决于三个参数日活用户数例如全员都是员工时即为员工数总用户账户数可以远大于日活数消息量message volume。服务器角色划分应用服务器与数据库服务器在下面的讨论中配置最多涉及两类服务器应用服务器运行 Django、Tornado、RabbitMQ、Redis、Memcached 等数据库服务器运行 PostgreSQL。其中 Django 主导应用服务器的资源需求。你可以把每个服务都放到独立系统上Docker 部署就是这样做的但对大多数场景而言这么做几乎没有可扩展性收益。拆分部署的细节见 deployment.mdZulip 完整支持每个顶层服务独立成机/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 规模推荐日活用户规模RAM 推荐25 日活用户4 GB100 日活用户8 GB400 日活用户应用服务器 16 GB 数据库 16 GB2000 日活用户应用服务器 32 GB 数据库 32 GB更大规模大致呈线性扩展专用数据库对于数百日活用户的安装官方推荐使用远程 PostgreSQL 数据库但并非强制。CPU由于 Zulip 在请求延迟优化上做了大量工作应用服务器的 CPU 占用被重度优化大多数内存充足的服务器 CPU 也足够因此 CPU 很少成为瓶颈。对于带独立数据库的大型安装推荐应用服务器选用高 CPU 实例数据库选用数据库优化型通常是低 CPU、高内存实例。应用服务器磁盘优先 S3 后端规模扩大后官方推荐使用 S3 文件上传后端存储上传文件。启用 S3 后端时建议为操作系统、Zulip 软件、日志和临时/空闲空间准备50 GB 磁盘由于上传文件会在本地缓存如果大量使用上传文件可能需要更多磁盘。S3 后端的本地缓存由 nginx 维护有三个可调参数upload-backends.mds3_memory_cache_size缓存索引的内存大小默认 1 MB约可容纳 8 千个条目s3_disk_cache_size缓存内容的磁盘大小默认 200 MBs3_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
