mirror of
https://github.com/hpd840321/starRiverProperty.git
synced 2026-06-09 08:20:31 +08:00
hpd840321
7b2bd307f1
- backend/: 13 Maven modules (cw-elevator-application, cloudwalk-cloud, intelligent-cwoscomponent, ninca-crk, etc.) - frontend/: 4 Vue projects (elevator-front, cwos-portal, alarm-front, front_acs) + decompiled + scripts - scripts/: build, test-env, tools (Docker Compose, service templates, API parity) - docs/: AGENTS.md, superpowers specs, architecture docs - .gitignore: standard Java/Maven exclusions Moved from legacy maven-*/ root layout to backend/ organized structure.
43 lines
3.0 KiB
Markdown
43 lines
3.0 KiB
Markdown
# 生产滚动升级：ninca-common-component-organization（三实例）
|
||
|
||
**现场根目录（部署包）：**
|
||
`/media/zebra/9e8fa357-7db6-4d70-88ed-d5de5a059a663/星河湾星中星/部署包/ninca_common_component_organization_01-ninca_common_component_organization`
|
||
|
||
根下含 `bootstrap.properties`、`application-node.properties` 示例、`sql/`；三台各用子目录（本仓样例为 `…207` / `…208` / `…209`，与 `application-node.properties` 里 `component-organization-01`～`03` 对应）。
|
||
|
||
---
|
||
|
||
## 1. 为什么这样升级对终端用户额外风险小
|
||
|
||
三台是**滚动替换**：任意时刻总有两台在跑，上游 Consul/Ribbon 或负载均衡会把流量导向健康实例，不会像整机停机那样突然断服务。
|
||
数据库脚本在 `**component-organization`** 库里**只执行一次**（维护窗口、由 DBA 或授权人在单点执行），避免三台各跑一遍弄乱数据。
|
||
若新版本在某台不满意，可**换回停机前备份的旧 JAR**；涉及访客楼层等策略时，也可在库或配置侧**关闭/禁用策略**降低影响（与研发确认具体字段）。运行与构建均为 **JDK 8**。
|
||
|
||
---
|
||
|
||
## 2. 升级顺序（先库后应用）
|
||
|
||
1. **数据库（一次）**
|
||
在 `**component-organization`** 上按变更单执行对应 DDL/DML（脚本与部署包 `sql/`、`docs/sql/` 同源说明一致）。**同一迁移禁止在三台应用机上重复执行。** 慎用含 `DROP TABLE` 的「全量安装」类脚本；生产优先增量脚本。迁移验证落库后再动应用。
|
||
2. **应用（逐台）**
|
||
建议顺序如 **207 → 208 → 209**（或按现网约定）。**每台流程：** 若现场有 LB/摘流习惯可先摘该实例 → `stop.sh` 停进程 → **备份当前 Fat JAR**（如加 `.bak.日期`）→ 上传新 JAR（与发布说明 **SHA-256** 一致；三台用同一制品）→ **JDK 8** 下 `start.sh` 启动 → 本节第 3 步检查通过后再处理下一台。
|
||
保留各节点 `application-node.properties` 中的节点差异（Consul、instance-id、IP 等）；合并新版本键值时勿把数据源/Redis/注册中心改成测试环境。
|
||
|
||
---
|
||
|
||
## 3. 每台做完看什么（最多三条）
|
||
|
||
- **健康：** `http://<节点IP>:<management.port>/actuator/health`（路径以现场为准）应为 **UP**。
|
||
- **日志：** `logs/` 下 info/error，无持续报错、无连库/注册中心失败风暴。
|
||
- **冒烟：** 按变更单做只读或低风险接口抽查；若本次含访客楼层策略，用只读方式确认读取符合预期。
|
||
|
||
---
|
||
|
||
## 4. 不满意怎么撤回
|
||
|
||
**应用：** 停进程 → 把备份的 JAR 换回运行文件名 → 再起动并按上节三项看一眼。可只回滚有问题的那台。
|
||
**库：** 优先与研发确认是否可通过关策略、改配置规避；若必须还原库，由 DBA 在评估窗口内操作，必要时先停写或停齐三台应用，避免双写分叉。
|
||
|
||
---
|
||
|
||
**备忘：** 三台最终应用包 **SHA-256 一致**；`sql/README.txt` 中对含 `DROP` 的脚本风险有说明，执行前核对变更单。 |