一、概述
很多企业在选低代码平台的时候，第一个问题就是"能不能私有化部署"。这不难理解——核心业务数据放在别人服务器上，总觉得心里不踏实。算数低代码平台支持完全私有化部署，所有数据都在企业自己的服务器上运行，我们只提供软件和运维支持。
这份文档面向的是企业IT团队和运维工程师，把私有化部署从头到尾的方案讲清楚：从架构规划到容器化部署，从数据库选型到高可用配置，从监控告警到数据备份恢复。按着这份文档走，一个有经验的运维团队大概2-3天就能把平台跑起来。
根据IDC的调研，2024年有超过70%的中大型企业在采购企业级软件时要求支持私有化部署（数据来源：IDC《中国企业数字化转型支出指南, 2024》）。信通院的数据也显示，金融、政务、制造业这三个行业对私有化部署的需求最为强烈（数据来源：中国信通院《云计算白皮书（2024）》）。
二、私有化部署架构
私有化部署的整体架构分三层：接入层、应用层、数据层。这种分层设计的好处是每一层可以独立扩展，哪层压力大就加哪层的资源，不用整个集群一起扩。
2.1 部署架构总览
| 层级 | 组件 | 数量（最小集群） | 数量（推荐集群） | CPU/内存（单节点） | 职责 |
|---|---|---|---|---|---|
| 接入层 | Nginx负载均衡 | 2 | 2 | 4C/8G | SSL终结、请求分发、静态资源 |
| Keepalived VIP | 2 | 2 | 1C/1G | 浮动IP、Nginx高可用 | |
| 应用层 | API网关服务 | 2 | 4 | 4C/8G | 路由、认证、限流 |
| 应用管理服务 | 2 | 2 | 4C/8G | 应用CRUD、发布 | |
| 表单引擎服务 | 2 | 4 | 4C/8G | 表单渲染、数据CRUD | |
| 工作流服务 | 2 | 2 | 4C/8G | 流程引擎、审批流转 | |
| AI能力服务 | 2 | 4 | 8C/16G | 大模型对接、NL2SQL | |
| 文件服务 | 2 | 2 | 4C/8G | 文件上传下载、MinIO | |
| 数据层 | MySQL主从 | 2（1主1从） | 3（1主2从） | 8C/32G | 业务数据存储 |
| Redis集群 | 3 | 6（3主3从） | 4C/16G | 缓存、会话、限流 | |
| RabbitMQ | 2 | 3 | 4C/8G | 异步消息队列 | |
| MinIO | 1 | 4（分布式） | 4C/8G+2TB | 对象存储 | |
| 运维层 | Prometheus+Grafana | 1 | 1 | 4C/8G | 监控、告警 |
| ELK日志栈 | 1 | 3 | 8C/16G | 日志收集、检索 |
最小集群需要约15台服务器（虚拟机即可），推荐集群约25台。如果用户量不大（500人以下），最小集群完全够用。日活用户超过2000的话，建议直接上推荐集群配置。
2.2 网络规划
私有化部署的网络建议分三个VLAN：
- 外网VLAN：只有Nginx节点暴露外网IP，其他所有服务节点都不对外。Nginx负责SSL终结和反向代理。
- 内网VLAN：应用服务和数据服务之间的通信走内网，带宽充足、延迟低。数据库不对外，只能被应用层访问。
- 管理VLAN：运维访问专用通道，通过堡垒机+VPN接入，所有管理操作都有审计记录。
三、容器化部署方案
所有服务都容器化了，用Docker打包、用Kubernetes编排。这样做的好处太多了——环境一致性、快速扩缩容、滚动更新、故障自愈，都是容器化带来的好处。Gartner的报告显示，到2025年超过85%的企业将在生产环境运行容器化应用（数据来源：Gartner《容器管理市场指南, 2024》）。
3.1 Docker镜像规范
每个微服务打包成一个独立的Docker镜像，基于Alpine Linux基础镜像构建，镜像大小控制在200MB以内。多阶段构建——编译阶段用JDK 17，运行阶段用JRE 17，把镜像体积压到最小。
# Dockerfile示例（应用管理服务）
FROM eclipse-temurin:17-jdk-alpine AS builder
WORKDIR /build
COPY . .
RUN ./gradlew :app-service:bootJar --no-daemon
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /build/app-service/build/libs/*.jar app.jar
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
CMD wget -qO- http://localhost:8080/actuator/health || exit 1
ENTRYPOINT ["java", "-XX:+UseG1GC", "-XX:MaxRAMPercentage=75", "-jar", "app.jar"]
3.2 Kubernetes部署配置
在K8s中，每个微服务部署为一个Deployment，前面挂一个ClusterIP Service。关键配置参数：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| replicas | 2（最小）/ 4（推荐） | 每个服务至少2个副本保证高可用 |
| requests.cpu | 1000m | 保证分配1核CPU |
| requests.memory | 2Gi | 保证分配2G内存 |
| limits.cpu | 4000m | 最大可用4核CPU |
| limits.memory | 6Gi | 最大可用6G内存 |
| maxSurge | 1 | 滚动更新时最多多出1个Pod |
| maxUnavailable | 0 | 滚动更新时不允许减少Pod |
| readinessProbe | /actuator/health/readiness | 就绪检查端点 |
| livenessProbe | /actuator/health/liveness | 存活检查端点 |
| startupProbe | /actuator/health | 启动检查（给足启动时间） |
| HPA targetCPU | 70% | CPU使用率超70%自动扩容 |
3.3 配置管理
配置用K8s ConfigMap和Secret管理。非敏感配置（如数据库连接池大小、线程池配置）放ConfigMap，敏感信息（如数据库密码、API密钥）放Secret。ConfigMap和Secret通过环境变量或Volume挂载到容器中，改配置不需要重新打包镜像。
四、数据库选型
数据库是整个平台的核心，选型必须慎重。我们支持MySQL和PostgreSQL两种数据库，各有优劣，选哪个取决于你的具体场景。
4.1 MySQL vs PostgreSQL对比
| 对比维度 | MySQL 8.0 | PostgreSQL 16 | 推荐场景 |
|---|---|---|---|
| 读写性能 | OLTP场景优秀 | 复杂查询更优 | 高并发简单查询→MySQL |
| JSON支持 | JSON类型（基本） | JSONB（强类型+索引） | 大量JSON数据→PG |
| 全文检索 | 基本支持 | 内置强大全文检索 | 需全文检索→PG |
| 扩展性 | 插件生态中等 | 插件生态丰富（PostGIS等） | 需GIS/向量检索→PG |
| 运维难度 | 低（成熟度高） | 中等（需更多调优） | 运维能力有限→MySQL |
| 社区支持 | 非常活跃 | 活跃 | 都OK |
| 高可用方案 | MHA/Orchestrator | Patroni/Repmgr | MySQL方案更成熟 |
| 授权协议 | GPL（免费） | PostgreSQL License（免费） | 都OK |
我们的建议是：90%的企业选MySQL就够了，运维简单、生态成熟、文档丰富。如果你的业务有大量复杂SQL查询、JSON数据处理或全文检索需求，再考虑PostgreSQL。不确定的话，先上MySQL，后续可以平滑迁移。
4.2 数据库配置参数
以下是MySQL 8.0在32G内存服务器上的关键配置参数：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| innodb_buffer_pool_size | 16G（内存的50%） | InnoDB缓冲池，最关键参数 |
| innodb_log_file_size | 2G | redo log文件大小 |
| innodb_flush_log_at_trx_commit | 1 | 每次事务提交都刷盘（最安全） |
| sync_binlog | 1 | 每次事务都同步binlog（最安全） |
| max_connections | 500 | 最大连接数 |
| innodb_read_io_threads | 8 | 读IO线程数 |
| innodb_write_io_threads | 8 | 写IO线程数 |
| slow_query_log | ON | 开启慢查询日志 |
| long_query_time | 1 | 超过1秒记录为慢查询 |
| binlog_format | ROW | 行级binlog（用于主从复制） |
五、高可用配置
高可用是企业级部署的硬要求。我们的高可用方案从接入层到数据层全覆盖，任何单点故障都不会导致服务中断。
5.1 接入层高可用
两台Nginx通过Keepalived实现主备高可用。Keepalived用VRRP协议维护一个虚拟IP（VIP），正常情况下VIP在主Nginx上。主Nginx挂了，备Nginx在3秒内接管VIP，用户几乎无感知。Nginx配置了健康检查，后端服务不可用时自动从负载均衡池中摘除。
5.2 应用层高可用
每个微服务至少2个副本，通过K8s的Service实现负载均衡。K8s会自动检测Pod健康状态，不健康的Pod会被重启（livenessProbe）或从负载均衡中摘除（readinessProbe）。配合HPA（水平Pod自动扩缩容），CPU使用率超过70%自动增加Pod数量，流量降下来后自动缩容。
5.3 数据层高可用
MySQL采用一主多从架构，主库负责写操作，从库负责读操作。主库故障时通过MHA（MySQL Master High Availability）自动选举新主库，切换时间控制在30秒以内。Redis采用哨兵（Sentinel）模式或集群模式，自动故障转移。RabbitMQ采用镜像队列模式，消息在多个节点间同步复制。
| 组件 | 高可用方案 | 故障切换时间 | 数据一致性 |
|---|---|---|---|
| Nginx | Keepalived主备 | < 3秒 | - |
| MySQL | MHA一主多从 | < 30秒 | 强一致（半同步复制） |
| Redis | Sentinel/Cluster | < 10秒 | 最终一致 |
| RabbitMQ | 镜像队列 | < 5秒 | 强一致 |
| MinIO | 分布式纠删码 | 自动 | 强一致 |
六、监控告警体系
部署完不等于完事，你得能看到系统在跑什么状态。我们的监控方案是Prometheus + Grafana + AlertManager三件套，在众多企业级监控方案中算是比较成熟的选择。
6.1 监控维度
| 监控层级 | 监控指标 | 采集方式 | 告警阈值 |
|---|---|---|---|
| 主机层 | CPU使用率、内存使用率、磁盘使用率、网络IO | node_exporter | CPU>80%、磁盘>85%、内存>90% |
| 容器层 | Pod状态、容器CPU/内存、重启次数 | cAdvisor + kube-state-metrics | Pod重启>3次/5分钟、Pending>5分钟 |
| 应用层 | QPS、响应时间、错误率、JVM GC | Micrometer + Prometheus | P99>2秒、错误率>1%、GC暂停>500ms |
| 数据库层 | 连接数、慢查询、主从延迟、表锁 | mysqld_exporter | 连接数>80%、从库延迟>10秒 |
| 中间件层 | Redis命中率、MQ堆积、连接数 | redis_exporter + rabbitmq_exporter | MQ堆积>1000条、Redis内存>80% |
| 业务层 | 表单提交成功率、流程审批耗时 | 自定义业务指标 | 提交失败率>0.5% |
6.2 告警渠道
告警通过AlertManager分发到不同渠道：
- P0级告警（系统不可用）：电话+短信+钉钉/飞书群机器人，7×24小时
- P1级告警（功能异常）：钉钉/飞书群机器人+邮件，工作时间
- P2级告警（预警）：邮件，工作时间
- P3级告警（信息）：Grafana面板展示，不单独通知
告警做了防抖处理——同一个指标在5分钟内只告警一次，避免告警风暴。同时配置了告警收敛规则，关联告警合并通知，比如"数据库连接异常"和"应用服务数据库连接超时"会合并成一条通知。
七、数据备份与恢复
数据是企业的命根子，备份策略必须做到位。我们的备份方案是"3-2-1原则"——3份数据副本、2种存储介质、1份异地存储。
7.1 备份策略
| 备份类型 | 频率 | 保留时长 | 备份方式 | 存储位置 | 预估大小 |
|---|---|---|---|---|---|
| 全量备份 | 每日（凌晨2:00） | 30天 | mysqldump --single-transaction | 本地NAS + 异地对象存储 | DB大小的1-1.5倍 |
| 增量备份 | 每小时 | 7天 | binlog实时同步 | 本地NAS | 约全量的5-10% |
| Redis快照 | 每6小时 | 7天 | RDB + AOF | 本地磁盘 | 约内存大小的1-2倍 |
| MinIO数据 | 实时 | - | 分布式纠删码（自动冗余） | 多节点分布存储 | - |
| 配置文件 | 变更即备份 | 90天 | Git版本管理 | Git仓库 + 异地 | 极小 |
7.2 恢复流程
数据恢复分两种场景：
场景一：整个数据库恢复（比如误删库、服务器故障）
- 从最近的全量备份恢复基础数据
- 重放全量备份后的binlog，恢复到故障前的时间点
- 验证数据完整性（行数校验、关键字段抽样）
- 切换应用连接到恢复后的数据库
- 预期RTO（恢复时间目标）：2-4小时，取决于数据量
场景二：单表/单条数据恢复（比如误删某条记录）
- 在临时实例上恢复全量备份
- 重放binlog到误操作前的时间点
- 从临时实例中导出需要恢复的数据
- 在主库上执行数据恢复SQL
- 预期RTO：30-60分钟
7.3 恢复演练
备份不演练等于没备份。我们要求客户每季度执行一次恢复演练——在隔离环境中模拟从备份恢复完整系统，验证备份数据的可用性和恢复流程的可操作性。演练结果记录在案，包括恢复时间、数据完整性校验结果、发现的问题和改进措施。
八、安全加固
私有化部署的安全加固也不能放松。以下是关键安全措施清单：
- 操作系统加固：关闭不必要的端口和服务，定期安全补丁更新，配置fail2ban防暴力破解
- 网络隔离：数据库和中间件不对外暴露端口，只允许应用层内网访问
- 访问控制：堡垒机+SSH密钥登录，禁用密码登录，所有操作录屏审计
- 数据加密：传输层全链路TLS，存储层敏感字段AES-256加密
- 漏洞扫描：每月用Trivy扫描容器镜像漏洞，高风险漏洞48小时内修复
- 安全审计：所有API调用、数据操作、配置变更记录审计日志，保留180天
九、性能调优建议
部署完成后，根据实际使用情况做性能调优是持续的工作。几个关键调优方向：
- JVM调优：用G1GC替代CMS，设置
-XX:MaxGCPauseMillis=200控制GC停顿时间。堆内存建议设为容器内存限制的75%。 - 连接池调优：HikariCP的
maximumPoolSize建议设为CPU核心数×2+有效IO数。不是越大越好，连接太多反而会拖慢数据库。 - 缓存策略：热点数据放Redis，设置合理的TTL。注意缓存穿透和雪崩问题——空值缓存+随机过期时间。
- SQL优化：定期分析慢查询日志，用EXPLAIN检查执行计划。大表查询该加索引加索引，该分页分页。
- 前端优化：静态资源CDN加速，首屏按需加载，大表单分步渲染。
数据来源说明：本方案引用的行业数据来自 Gartner《容器管理市场指南, 2024》、IDC《中国企业数字化转型支出指南, 2024》以及中国信通院《云计算白皮书（2024）》。技术方案部分基于算数科技在多个企业级客户生产环境的实际部署经验总结。
十、部署检查清单
最后附上一份部署检查清单，上线前逐项确认：
| 检查项 | 检查内容 | 通过标准 |
|---|---|---|
| 网络连通性 | 各节点间网络互通 | ping延迟<1ms，无丢包 |
| SSL证书 | 域名证书已配置 | HTTPS访问正常 |
| 数据库主从 | 主从复制状态 | 从库延迟<1秒 |
| Redis集群 | 集群状态正常 | 所有节点online |
| 服务健康 | 所有微服务启动正常 | health检查全部UP |
| 监控告警 | Prometheus采集正常 | 所有target up |
| 日志收集 | ELK日志正常入库 | 可检索到最新日志 |
| 备份策略 | 备份任务已配置 | 手动触发备份成功 |
| 安全加固 | 防火墙规则已配置 | 端口扫描仅开放必要端口 |
| 压测验证 | 并发压测通过 | P99<2秒，错误率<0.1% |
部署过程中遇到任何问题，随时联系我们的技术支持团队：邮箱 cooper@micount.cn，电话 18016313342。我们也提供驻场部署服务，由经验丰富的工程师到现场协助完成部署和调优。
更多技术细节可以参考低代码平台技术架构白皮书了解平台架构，或者看API集成开发指南了解接口规范。