反编译工作区
16 KiB
电梯生产证据包差异分析（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 时间线（同一日志内存在两次启动）
-
第一次启动窗口（11:16）
11:16:24Tomcat 启动、Consul 注册；11:16:24ConfigSourceProbeRunner 打印：ninca-crk-std.ribbon.listOfServers value=null，ninca-crk-std.ip=10.0.22.102:16106；11:16:34ninca-crk-std初始化为ConfigurationBasedServerList，但current list of Servers=[]；- 随后大量出现
Load balancer does not have available server for client: ninca-crk-std。
-
第二次启动窗口（11:43）
11:43:24再次出现 Tomcat 启动与 Consul 注册（说明同一日志内发生过重启）；11:43:35ninca-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-stdpassing=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. 建议的后续动作
- 命名归档：在证据目录或工单中显式标注 JAR sha256 与
jar tf中cw-elevator-application-*版本，避免「V1 目录名」误导。 - 修复 jcmd 采集：解决 attach 权限 / JVM 参数后重采，补齐 进程内
ribbon.*/feign.*。 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=...
建议下一步（配置侧，变更须评审与灰度）：
- 在现场与 v2 部署模板中显式增加与现场一致的
ninca-crk-std.ribbon.listOfServers（可填与日志中负载均衡最终一致的 三台主机:16106，或与 Consul 解析一致的主机名列表），使 首次启动即不为空；并与ninca-crk-std.ip的业务语义对齐（同一可达入口集合）。 - 重启后对照日志：首次出现
DynamicServerListLoadBalancer for client ninca-crk-std initialized时current list of Servers是否直接非空。
9.3 观测与采集强化（不改业务契约前提下）
- 对照 Ribbon / Consul 探针（当前代码库默认始终运行；延迟见
ElevatorProbeConstants）：在*-probe.log中查 ribbonProbe instance、consulProbe instance 行，与 JVM 及 Consul API 对照（见scripts/collect_elevator_runtime_evidence.sh）。 - 修复 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 快照文件；若现场重新采集，请更新本文件名中的日期或新增一篇并列保留历史结论。