starRiverProperty/docs/testing/elevator-evidence-v1-v2-diff-20260430.md

电梯生产证据包差异分析（2026-04-30）

证据根目录（仓库内）：maven-cw-elevator-application/logs/evidence/

本文基于 collect_elevator_runtime_evidence.sh 现场采集产出的三份时间戳目录，对制品真实版本、本地配置、Consul 健康实例、日志关键行与 jcmd 作对比。与历史排查主线的关系见 elevator-service-instance-missing-investigation.md。

---

1. 三份目录与「版本指纹」

目录	采集时间（collected-at.txt）	jar-path.txt 展示名	jar.sha256.txt	jar-tf.txt 内模块版本（lib）	说明
elevator-evidence-20260430-112820	2026-04-30T11:28:20+0800	.../cw-elevator-application-V1.0.0.20211103.jar	8da5978a7b34...90544908	无（当次未成功生成 jar-tf）	与 113912 同一 JAR 字节（见 sha256）
elevator-evidence-20260430-113912	2026-04-30T11:39:12+0800	同上	同上	含 cw-elevator-application-*-**2.0.7**.jar	可确认 fat-jar 内为 Maven 2.0.7 发布结构
elevator-evidence-20260430-114350	2026-04-30T11:43:50+0800	同上	c087067de3f6...8942054（不同）	含 cw-elevator-application-*-**1.0-SNAPSHOT**.jar	第三套制品：与 113912 非同一文件；内嵌为 SNAPSHOT 构件

核心结论（勿仅看文件路径名）：

• 三份 jar-path.txt 的文件名均为历史目录 cw-elevator-application-V1.0.0.20211103.jar，但 112820/113912 与 114350 的 sha256 不同，说明现场曾替换过该路径上的 JAR 或 114350 采自另一时刻/已换包。
• 112820 与 113912 的 sha256 一致，不是「V1 代码 vs V2 代码」的两套包，而是同一物理 JAR 的两次采集；区别仅在于 113912 多出了 jar-tf.txt / java-version.txt 等，用于认定模块版本为 2.0.7。
• 114350 代表另一制品：内嵌 1.0-SNAPSHOT，不得与「正式发布 2.0.7」混为一谈。

JDK：113912、114350 的 java-version.txt 均为 OpenJDK 1.8.0_41（路径脚本写死 /data/cwos/java）。

---

2. 主轴对比：112820 ↔ 113912（同一 JAR、两轮采集）

维度	112820	113912	结论
磁盘 application.properties	内容一致	一致	diff 无差异
磁盘 bootstrap.properties	一致	一致	无差异
proc-cmdline.txt	java -jar ... cw-elevator-application-V1.0.0.20211103.jar（含 JDWP）	相同	无差异
Consul /v1/health/service/...?passing=true	各服务 passing 数组长度均为 3	相同	无差异
elevator-app.log.keylines.txt	与 113912 同一时期的日志摘录	内容一致（同一日志切片）	无实质环境差异

小结：此轴不宜表述为「V1 与 V2 运行态对比」，应表述为 同一 2.0.7 制品（sha256 一致）在短时间内的两次证据归档，第二次补充了 jar tf 与 JDK 版本文件。

---

3. 主轴对比：113912 ↔ 114350（两套不同 JAR）

维度	113912	114350	结论
jar.sha256.txt	8da5978a...	c087067d...	不同文件
fat-jar 内 lib/cw-elevator-application-*.jar	*-2.0.7.jar	*-1.0-SNAPSHOT.jar	版本线不同
解压 jar-application.properties.txt（BOOT-INF 内嵌默认）	logging.level.*=debug，logging.path=/data/cwos/cw-elevator-application-V1.0.0.20211103/logs	logging.level.*=info，logging.path=logs	打包内嵌默认配置不同（与磁盘目录 application.properties 可能再叠加覆盖）
磁盘 application.properties（采集快照）	需与 114350 目录单独比对		以各目录下同名文件为准

部署含义：

• 114350 更符合「本地 Maven reactor SNAPSHOT 打出 fat-jar」的内嵌特征（1.0-SNAPSHOT + 内嵌 properties 为相对 logs）。
• 113912 更符合「发布流程 2.0.7」打入的内嵌与 lib 版本。

若现场长期沿用目录名 cw-elevator-application-V1.0.0.20211103 仅替换 JAR，会出现「路径像 V1、内容实为 2.0.7 或 SNAPSHOT」——必须以 sha256 + jar tf 为准。

---

4. jcmd

三份目录的 jcmd-system-properties.txt 均为 Attach 失败（AttachNotSupportedException: Unable to open socket file），无法对比进程内最终 system properties。后续现场需满足 JVM attach 条件后再采一次（或使用启动参数导出），否则 Ribbon/Feign 运行态只能依赖日志与磁盘配置。

---

5. 日志与 Ribbon 行为（三份 keylines 共性）

在 112820 / 113912 的 elevator-app.log.keylines.txt 中可见一致现象（与 elevator-service-instance-missing-investigation.md 一致）：

• Consul 注册：elevator-app 成功注册（带 HTTP health）。
• 配置探针：磁盘 ./bootstrap.properties 中 spring.cloud.consul.discovery.enabled=true，classpath 内嵌为 false（多源并存）。
• ninca-crk-std：DynamicServerListLoadBalancer 使用 ConfigurationBasedServerList，但 current list of Servers=[]，随后出现 Load balancer does not have available server for client: ninca-crk-std。
• 其他客户端（如 cwos-portal、ninca-common）日志中可见 Consul 解析出的 3 台实例。

差异排查方向（非本次证据目录两两 diff，而是现象归因）：重点核对 ninca-crk-std 的 Ribbon 静态列表 / NincaCrkStdRibbonConfiguration 生效路径与 Consul 列表是否交替覆盖，详见上述 investigation 文档。

114350 的 elevator-app.log.keylines.txt 与 113912 文件不完全相同（diff 有差异），如需逐行对比可在本地对两份 keylines 执行 diff -u。

---

6. logs/evidence/elevator-app.log 全量日志专项排查

逐项走查（客户端名 / 时序 / Consul vs ConfigurationBased / bootstrap）：见 consul-ribbon-no-server-walkthrough.md。

针对 maven-cw-elevator-application/logs/evidence/elevator-app.log 进行额外统计与时间线复盘：

6.1 关键信号统计

• Load balancer does not have available server for client: ninca-crk-std：290 次
• ConfigurationBasedServerList：1 次
• ConsulServerList：7 次
• 探针启动信号（CONFIG SOURCE PROBE START / RIBBON...PROBE / CONSUL...PROBE / ELEVATOR DIAGNOSTIC PROBES）：仅 2 条（其中可见的为 CONFIG SOURCE PROBE START）

6.2 时间线（同一日志内存在两次启动）

1. 第一次启动窗口（11:16）

   • 11:16:24 Tomcat 启动、Consul 注册；
   • 11:16:24 ConfigSourceProbeRunner 打印：ninca-crk-std.ribbon.listOfServers value=null，ninca-crk-std.ip=10.0.22.102:16106；
   • 11:16:34 ninca-crk-std 初始化为 ConfigurationBasedServerList，但 current list of Servers=[]；
   • 随后大量出现 Load balancer does not have available server for client: ninca-crk-std。

2. 第二次启动窗口（11:43）

   • 11:43:24 再次出现 Tomcat 启动与 Consul 注册（说明同一日志内发生过重启）；
   • 11:43:35 ninca-crk-std 初始化时已是 current list of Servers=[...:16106 x3]；
   • 第二次窗口未见与第一次同规模的“空列表 + 连续 no available server”模式。

6.3 结合证据包的解释

• 112820 / 113912 与第一次窗口行为一致，暴露出 ninca-crk-std 在该时段未拿到可用服务列表；
• 114350 对应另一制品（1.0-SNAPSHOT）后，日志中出现 ninca-crk-std 能初始化出 3 台服务的信号；
• 因三份 Consul 健康快照均显示 ninca-crk-std passing=3，可初步排除「Consul 没有实例」这一外因，更可能是客户端侧配置/初始化时序/构件差异导致。

---

7. Consul 健康快照

三份目录中下列服务的 passing 实例数（JSON 数组长度）一致：均为 3（elevator-app、cwos-portal、ninca-common、ninca-common-component-organization、ninca-crk-std、cloudwalk-device-thirdparty）。
说明：本次采集窗口内 Consul 侧上游实例数量未成为三份包之间的差异变量；与 JVM 内 Ribbon 列表为空等问题需从 客户端配置与负载均衡初始化顺序 侧继续查。

---

8. 建议的后续动作

1. 命名归档：在证据目录或工单中显式标注 JAR sha256 与 jar tf 中 cw-elevator-application-* 版本，避免「V1 目录名」误导。
2. 修复 jcmd 采集：解决 attach 权限 / JVM 参数后重采，补齐 进程内 ribbon.* / feign.*。
3. ninca-crk-std：按 investigation 文档与 下节第 1 条 优先验证 ribbon.listOfServers 与 ninca-crk-std.ip 的关系。

---

9. 综合证据 + 日志 + 多进程后的「下一步方向」

9.1 已对齐的事实（减少走弯路）

来源	结论
三份 consul-health-*.json	各上游（含 ninca-crk-std）passing 均为 3
ps-ef.txt（随证据采集）	各业务为独立 Java 进程；ninca-crk-std 在目标环境以单独进程形式存在（与电梯进程不同）
proc-cmdline.txt	电梯进程为 java -jar，工作目录下 cw-elevator-application-V1.0.0.20211103.jar（文件名可与真实字节不一致，须看 sha256）
elevator-app.log	同一日志两次启动：首次 11:16 ninca-crk-std 负载均衡 Servers=[]；重启后 11:43 同客户端出现 3 台 :16106，说明问题偏 客户端 Ribbon 配置/初始化时序，而非「现场没有 ninca-crk-std 进程」

9.2 优先验证：Ribbon 静态列表键 ≠ 业务 ninca-crk-std.ip

证据包内 application.properties（及仓库 deploy/v2-maven/application.properties）仅有：

• ninca-crk-std.ip=10.0.22.102:16106（供业务代码等使用）

而探针行显示：

• ninca-crk-std.ribbon.listOfServers value=null

电梯侧对 ninca-crk-std 使用 NincaCrkStdRibbonConfiguration，其 ConfigurationBasedServerList 从 Ribbon 标准配置（如 ninca-crk-std.ribbon.listOfServers）取服务器列表；与 ninca-crk-std.ip 无自动绑定（ninca-crk-std.ip 在业务类中如 AcsElevatorRecordServiceImpl 以 @Value 使用）。

对照 deploy/v1-legacy/application.properties 中显式：

• ninca-crk-std.ribbon.NIWSServerListClassName=...
• ninca-crk-std.ribbon.listOfServers=...

建议下一步（配置侧，变更须评审与灰度）：

1. 在现场与 v2 部署模板中显式增加与现场一致的 ninca-crk-std.ribbon.listOfServers（可填与日志中负载均衡最终一致的 三台主机:16106，或与 Consul 解析一致的主机名列表），使 首次启动即不为空；并与 ninca-crk-std.ip 的业务语义对齐（同一可达入口集合）。
2. 重启后对照日志：首次出现 DynamicServerListLoadBalancer for client ninca-crk-std initialized 时 current list of Servers 是否直接非空。

9.3 观测与采集强化（不改业务契约前提下）

1. 对照 Ribbon / Consul 探针（当前代码库默认始终运行；延迟见 ElevatorProbeConstants）：在 *-probe.log 中查 ribbonProbe instance、consulProbe instance 行，与 JVM 及 Consul API 对照（见 scripts/collect_elevator_runtime_evidence.sh）。
2. 修复 jcmd Attach：解决 jcmd-system-properties.txt 中的 AttachNotSupportedException 后重采，便于核对 进程内最终 ribbon.* / feign.*（与磁盘 properties 是否一致）。

9.4 仍建议对照的仓库文档

• elevator-service-instance-missing-investigation.md：Ribbon 双路径（Consul vs ConfigurationBased）与现象描述。
• 若调整 listOfServers，需在变更说明中记录 与对外 HTTP/Feign 契约不变（仅内部路由与配置）。

---

10. elevator-app-probe.log 同步分析（仓库内样本）

文件：maven-cw-elevator-application/logs/evidence/elevator-app-probe.log（与主日志同一次启动窗口 2026-04-30 11:16:24，仅含 cn.cloudwalk.elevator.debug 包输出。）

10.1 探针开关（首行汇总）

本证据文件采自 2026-04-30 进程；当时摘要行仍描述 config / ribbon / consul 三开关。当前仓库实现为：三类探针默认全开，调度仅改源码 ElevatorProbeConstants，不再使用 elevator.*.probe.enabled。

• configProbe=true：ConfigSourceProbeRunner 已执行（本文件主体）。
• ribbonProbe=false：当时未启用 Ribbon 探针属性，故本文件中无 ribbonProbe instance 等行（非当前代码行为）。
• consulProbe=false：当时未启用 Consul HTTP 探针，故本文件中无 consulProbe instance 等行（非当前代码行为）。

新版进程应在延迟（Consul 约 20s、Ribbon 约 22s）后于 *-probe.log 中出现 consulProbe / ribbonProbe 明细；与 elevator-app.log 中 Netflix Ribbon 行交叉验证时无需再开属性开关。

10.2 配置源冲突（与主日志 / keylines 一致）

键	合并后 getProperty	并存来源
spring.cloud.consul.host	10.0.22.102	磁盘 file:./bootstrap 为 IP；classpath:/bootstrap 为 主机名
spring.cloud.consul.discovery.enabled	true	磁盘为 true；classpath 为 false（最终以 Environment 合并结果为准，探针 value= 为 true）

10.3 Ribbon 相关键在 Environment 中的显式值

• *.ribbon.NIWSServerListClassName：均为 null（探针未解析到属性文件中的覆盖字符串）。
• *.ribbon.listOfServers：均为 null。
• ninca-crk-std.ip：10.0.22.102:16106（file: 与 classpath: 一致）。

与 NincaCrkStdRibbonConfiguration + 主日志中 ConfigurationBasedServerList 且 Servers=[] 的现象一并阅读：Environment 层未出现 ninca-crk-std.ribbon.listOfServers，与「仅靠业务键 ninca-crk-std.ip」并存。

10.4 小结

项目	结论
本文件作用	专用 elevator-app-probe.log，避免在主日志中筛选探针类
本次样本覆盖范围	仅 ConfigSource（当时未开 Ribbon/Consul 探针）；新版本默认可见全量探针
与排查关系	历史样本解释「旧证据缺 Ribbon/Consul 行」；现行构建以 ElevatorProbeConstants 为准，深层 Ribbon 行为仍可对照 elevator-app.log 中 DynamicServerListLoadBalancer

---

延伸（不改现场属性文件的审核备忘）：elevator-v1-v2-init-timing-config-audit.md（初始化时序、探针顺序、jcmd attach、V1/V2 模板对照）。

---

文档生成说明：基于仓库内已检入的 logs/evidence 快照文件；若现场重新采集，请更新本文件名中的日期或新增一篇并列保留历史结论。