一、概述
很多企業在選低代碼平臺的時候，第一個問題就是"能不能私有化部署"。這不難理解——核心業務資料放在別人伺服器上，總覺得心裡不踏實。算數低代碼平臺支援完全私有化部署，所有資料都在企業自己的伺服器上執行，我們只提供軟體和運維支援。
這份文件面向的是企業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整合開發指南瞭解介面規範。