云服务总线CSB运维指南解读：巡检、故障处理与配置调优实战

简介：阿里云专有云企业版V3.7.1云服务总线CSB运维指南（20190124版）是一份面向企业IT运维与架构人员的官方技术文档，系统讲解CSB的完整运维体系。文档从法律声明与通用约定讲起，明确保密义务、知识产权及格式说明，随后给出运维概述、系统架构、安装部署、配置管理、监控管理和故障排查（troubleshooting）等核心模块，并细化到组件架构、部署架构、安装前准备、配置步骤、监控项及常见问题解决步骤，可帮助读者掌握CSB的安装配置、日常巡检、状态监控和排错方法，同时重视高危操作的规范执行。资源为单个PDF文件，共1份，大小约986KB，内容结构清晰、目录完整，可作为企业内部培训或日常查阅的离线手册。目前已有281人学习下载，适合正在使用或计划引入阿里云专有云CSB的运维团队和技术支持人员参考。

1. 云服务总线 CSB 运维指南 V3.7.1 怎么读：最值钱的不是开头的法律声明

拿到专有云企业版云服务总线 CSB（Cloud Service Bus）运维指南 V3.7.1 这份 PDF 时，我先把目录从头翻了一遍，发现真正决定你半夜能不能睡踏实的内容集中在中间四章：系统架构与组件职责、例行巡检、高危操作分级、故障处理。这份文档不是写给第一次接触 CSB 的人看的概念手册，而是给已经在专有云环境里接了 CSB、需要扛住日常巡检和故障应急的驻场运维、中间件团队以及服务接入开发者的操作基准。你要是带着“服务发不出去、调用超时、控制台打不开”这类具体问题来翻，会比我当初从头通读高效得多。

2. 系统架构与部署形态：运维前先分清十类组件和它们的依赖关系

2.1 三个子系统：服务总线、管控系统、运维监控系统

CSB 逻辑上由三块组成：服务总线系统、服务管控系统、运维监控系统。服务总线系统是数据面，CSB Broker 在这里处理 API 消费方的服务调用请求，完成认证鉴权、协议转换、流量控制，并且要和其他服务总线实例协调跨实例的级联式服务调用。服务管控系统是控制面，用户用控制台来做服务发布、订阅和组织管理，背后支撑它的是 CSB Admin、CSB Cache 和 CSB Store。运维监控系统则是 Butler 那一套，Broker 把系统状况和服务调用日志实时推送过去，用于监控报警和分析。

运维上最容易犯的错是把数据面和控制面的职责混在一起。Broker 手里的服务定义、授权信息、系统配置全都来自管控侧下发的缓存，你不要试图在一台 Broker 上手工改服务定义或者直接改库里数据来“救急”。某次我接手一个环境，同事为了快速让一个服务生效，直接在 Store 的 MySQL 里 insert 了一条记录，结果 Broker 的 Cache 没有刷新，服务照样找不到，反而把两边数据搞得不一致。正确做法是从控制台走发布流程，让管控侧统一把数据推下去。

2.2 组件清单与部署形态：双节点和公共组件的边界

整份文档里列出的组件不算少，我建议按“哪些是 CSB 自有的、哪些是公共组件”来分组记忆，这样出问题时能快速定位责任边界。

这表里有几个值得注意的点。第一，CSB Broker 是双节点部署，巡检时至少要确认两个节点都在正常工作，不能只看一台。第二，Cache 和 Store 的关系是一快一慢，线上服务定义读取走 Cache，只有未命中才回源 Store，所以排查服务定义不一致时要先查 Cache 是否刷新。第三，TLog、DAuth、Butler 这些公共组件不只服务 CSB 一个产品，它们的变更窗口、版本升级会影响所有使用方，操作前要去和公共组件负责人确认，别单方面动。

2.3 数据流与依赖关系：排查时沿着这条链路走

CSB 的一次服务调用，数据大致这样流转：API 消费方的请求先到客户提供的负载均衡设备，转发到 CSB Broker；Broker 向 DAuth 发起认证鉴权校验，同时从 CSB Cache 获取服务定义和服务控制信息，Cache 里没有则回源到 CSB Store；授权通过后 Broker 完成协议转换并把请求转发给后端服务提供方；处理结束，调用日志推送到 TLog，实时计算交给 JStorm，海量数据落入 HBase；集群里每个节点的健康状况实时上报给 Butler。

这条链路的最大价值在于：故障表现往往是同一个“调用失败”或“超时”，但日志落点完全不同。我排查时先区分是 Broker 拒绝（鉴权失败、限流）还是后端连接超时（提供方无响应），再看是 Cache/Store 拿不到定义还是 DAuth 鉴权抖动。文档里也单独给公共基础组件列了巡检章节，Address Server、Diamond Server、DAuth、TLog、JStorm、HBase 都有对应的检查点，这说明 CSB 的高可用高度依赖这些公共组件，平时巡检时不要只盯着 Broker 和 Console。

2.4 端口清单：先记住这些数，巡检才不会抓瞎

CSB 的端口分服务总线和管控中心两组，Broker 服务发布的时候会自动生成对应的巡检规则，规则名称里就直接带端口号。我把文档里的端口表整理了一份：

版本兼容端口最容易引起疑惑，老版节点上会同时存在 8082 走 HSF 级联、8087 走 HTTP、12206 走 HSF 开放端口这一类配置排查时要先确认节点上的具体版本，别拿新版的端口清单去套老版机器，否则会误判“端口没监听”。

3. 例行巡检：Butler 巡检规则配置与命令巡检清单

3.1 Butler 巡检：四种类型与参数解析

CSB 的巡检分成两条路径：一条是 Butler 平台上的自动巡检，适合持续监控，异常时直接告警到值班群；另一条是命令行手工巡检，适合每日例行检查和故障应急时快速确认现状。先说 Butler 这条路。

Butler 提供 HTTP、TCP、PING、DB 四种巡检类型。HTTP 用得最多，因为它能直接拨测服务接口的状态码和响应时间；TCP 适合确认端口是否在监听；PING 适合确认机器和容器网络是否可达；DB 适合巡检数据库连接和关键表状态。创建巡检规则的操作路径是：登录 Butler 控制台，左侧导航进入“系统管理 > 巡检管理”，单击“创建巡检配置”，先选模板和巡检类型，再配置巡检对象——这里要选租户、产品、服务、组件和容器 IP，支持全部机器和部分机器两种范围，最后配置巡检方案并保存。

HTTP 巡检的核心参数我整理了一份，照着填不容易漏：

填这套参数最容易翻车的两个地方。一个是状态码检测的顺序匹配规则：如果配置了多条匹配规则，告警触发按从上到下的顺序执行，只要第一条命中就告警，后面的规则不再判断，规则顺序摆错会出现服务明明正常却持续告警的情况。另一个是多节点拨测的比对逻辑：两个 Broker 节点的响应内容如果有 IP 或时间戳之类的差异，也会被判定为异常，这类误报在双节点部署里尤其常见，所以建议先用单节点拨测验证单点健康，再决定是否要做多节点比对。

控制台之外，文档还提到可以通过 OpenAPI 或 SDK 做响应内容检测和响应时间检测，适合把巡检规则纳入自动化发布流程的场景。我用 curl 创建一个 HTTP 巡检规则时一般这么写：

# 创建一次 HTTP 巡检规则（示意，参数名以你环境里的 OpenAPI 版本为准） curl -X POST 'http://butler-console-host:port/butler/openapi/check/rule' \ -H 'Content-Type: application/json' \ -d '{ "ruleName": "csb-broker-restful-port-8086", "checkType": "HTTP", "targetIp": "10.0.0.11", "checkPort": 8086, "checkUri": "/health", "cycleMinutes": 5, "expectStatus": 200, "timeoutMs": 3000 }'

ruleName 尽量和 Broker 服务发布时自动生成的规则名对齐，方便日后维护时一眼看出规则对应的端口和服务。checkType 对应 HTTP/TCP/PING/DB 四种类型之一，HTTP 巡检由端口加 URI 完成拨测，URI 路径要填实际可访问的健康检查接口。cycleMinutes 对应检测周期，按文档可选 5/10/15/30/60 分钟。expectStatus 填你接口真实的返回码，如果服务用 302 做跳转就填 302，别想当然写 200。timeoutMs 设成你服务接口耗时分布的 p95 再加一点余量，设太短会把慢接口误报成故障。AccessKey 和 SecretKey 用于发起带签名的拨测请求，巡检对象不需要签名的环境可以不传这对参数，但如果你创建的是带鉴权的拨测，少了它请求会直接被拒。

规则创建成功后，操作列里有“立即拨测”按钮，刚建完规则时一定要点一次。我见过有人在巡检平台配了几十条规则，但从来没拨测过，直到线上出故障才发现规则参数填错、从一开始就没生效过——这种巡检等于没有。

3.2 命令巡检：服务总线、管控中心与公共基础组件

命令巡检是 Butler 之外的兜底手段，适合应急时快速确认状态，也适合在没有巡检平台权限的环境里做手工检查。服务总线（CSB Broker）的检查分四步：进程、端口、磁盘、地址服务器。

# 1. 查看 CSB Broker 进程是否存活 ps -ef | grep cloud-gateway # 2. 检查核心服务端口监听状态 netstat -ano | grep -E '8081|8086|9081|8082|8087|12205|12206' # 3. 检查日志目录是否写满磁盘 df -lh /home/admin/cloud-gateway/log # 4. 检查地址服务器连通性（域名按专有云部署参数获取） ping address-server-internal

第一条命令确认 cloud-gateway 这个 Java 进程还活着，进程掉了其他检查都没意义。第二条把 Broker 的核心端口一次性列出来，8086 是 HTTP 开放端口，9081 是 WebService 端口，12205/12206 是 HSF 开放端口，8081/8082 分别对应新旧版的级联端口；如果 netstat 里少了某个端口，先看日志再决定要不要重启，别上来就动进程。第三条针对日志写满磁盘的场景，CSB 已启动滚动日志机制，但滚动不代表自动清理，大量调用日志堆积仍然可能把磁盘写满，导致 Broker 无法响应服务接入请求，这条巡检必须在清单里保留。第四条确认 Broker 能正常连接地址服务器，Broker 要靠它拿软负载地址，地址服务器不通，服务发现和级联都会出问题。

进程如果确认异常需要重启，按文档路径以 admin 用户进入 /home/admin/cloud-gateway/bin 目录，执行 appctl.sh startLocal。重启前先 ps 看旧进程是否退干净，重启后立刻 netstat 验证端口，日志默认路径是 /home/admin/cloud-gateway/log/aosp.log，启动报错会写在这里。

管控中心巡检看两块：CSB Console 的 8080 端口要能访问，控制台页面要能正常打开登录；CSB Admin 进程和 CSB Cache（Redis 集群）的运行状态要正常，Cache 里的服务定义缓存要和服务实际发布状态一致，不一致时多半是缓存未刷新，等刷新或按流程处理。公共基础组件巡检按文档列的顺序走：Address Server 用 ping 确认连通；Diamond Server 看静态配置是否一致，配置漂移会导致不同节点的服务行为不一致；DAuth 是鉴权中心，确认服务进程和鉴权接口响应正常；TLog 看日志采集是否断流，断了排查日志推送链路；JStorm 看实时计算任务是否在跑，任务卡死会影响监控数据；HBase 看容量是否告警，容量打满会拖累日志落库。

3.3 巡检之后：验证规则有效性、维护规则与调度

创建巡检规则之后有三个后续动作值得养成习惯。第一，立即拨测验证规则有效性，刚建好规则时点一次，确认能正确返回预期结果再让它按周期跑。第二，编辑规则时要复测，改了 URI 或状态码预期后至少手动拨测一次，避免改坏了自己不知道。第三，删除规则要慎重，文档明确写了删除巡检规则会同时把调度管理里对应的调度规则删掉，想恢复得重新建一遍，所以我一般会在删之前把规则参数截图留档，防止误删后连原来的配置都记不清。

4. 故障处理与常见问题避坑：G1/G2/G3 分级与五条踩坑记录

4.1 高危操作分级：动手前先给自己定个级

CSB 文档把运维操作分成 G1、G2、G3 三个级别，这个分级不是摆设，我建议每个进来值班的人都先背下来。

文档里有一条总原则：涉及服务连续性故障的操作均属于高危操作，按 G3 处理。换句话说，凡是可能让线上调用中断的操作，哪怕你觉得“就重启一下的事”，都要走变更申请。重启进程在文档里写得很明白：将导致业务中断，恢复业务所需时间约 10 分钟。这就是 G3 级别的代价。

4.2 告警处理：容器异常与巡检异常

容器异常告警是最常见的值班告警类型。收到告警先看容器状态是 Pending、CrashLoopBackOff 还是 Running 但健康检查失败，这三种的处理路径完全不同。再看宿主机资源——CPU、内存、磁盘——是不是被其他应用挤占，公共组件和 CSB 混部的情况下资源争抢最容易引发这类问题。最后看 Broker 日志里有没有 OOM 或线程池拒绝的报错，这两个是导致容器被反复杀掉的元凶。

巡检异常告警要分两类处理。一类是真实故障：所有节点同时告警，说明服务整体不可用，直接走故障响应机制。另一类是单节点闪断：先看网络和负载均衡，确认是不是负载均衡健康检查把节点摘了；再判断是配置差异还是真异常，最直接的办法是登录节点用 curl 手动拨测一次目标接口，拿真实返回和告警内容做比对。很多巡检告警是误报，但不能因为见过几次误报就默认所有告警都是误报，每次都要验证过才能消警。

4.3 服务连续性故障排查路径

服务连续性故障的排查，我按文档里的小节顺序整理成了一套路径，每类问题先看什么、再看什么，照着走比现场瞎试快得多。

服务发布失败：先确认 CSB Console 能不能连接 CSB Store，连接不上查网络和 Store 状态；再查服务定义有没有真正写入成功；最后看 Broker 有没有拿到最新定义，这里最容易卡在 CSB Cache 的旧缓存上，缓存不刷新，定义就一直是旧的。常见做法是等待缓存过期或按流程手动刷新，不要去数据库硬改。

服务找不到：先确认服务发布在哪个服务域、消费方的订阅是否生效；然后沿 Broker → Cache → Store 的链路逐层查。另外要留意 HSF 版本兼容问题，文档里老版级联端口 8082 和 HSF 开放端口 12206 就是为版本兼容保留的，跨版本级联调用时经常是端口对不上导致找不到服务。

HSF 服务调用失败或不稳定：先从服务提供方开始查，确认提供方服务是否正常注册到了地址服务器；再查 Broker 到提供方的网络连通性；最后看鉴权链路是否通过，DAuth 鉴权失败和网络不通表现很像，但日志里的错误码完全不同。不稳定的情况通常和连接池、线程池、网络抖动有关，查的时候把提供方接口的耗时分布拉出来看看。

服务调用超时：拆成连接超时和读超时两类。连接超时看网络链路和负载均衡，读超时看服务提供方的响应能力和 Broker 的线程池。常见误区是把两个超时混在一起调，调大连接超时对响应慢没有帮助，调大读超时又会让调用方等更久。

控制台相关故障：控制台报告内存溢出时，先看 Tomcat 日志和 JVM 参数，调堆内存属于变更动作，按 G2 流程申请；控制台正常启动但无法访问，检查 8080 端口监听、浏览器代理配置和网络策略，文档的运维准备里明确写了需要用配置代理的浏览器登录控制台，专有云环境里控制台通常不直接暴露，访问不了先怀疑代理而不是怀疑服务；控制台登录后出现安全提示，多半是证书或浏览器安全策略问题，按文档核对证书配置。

CPU 占用率高：优先看两件事——日志量和 GC 情况。日志量过大先看是不是 TLog 采集链路卡住导致 Broker 侧堆积，GC 频繁则看 JVM 参数和堆内存设定是否合理。CPU 高不一定是线程池不够，很多时候是日志打太多或 GC 抖动，别一上来就加线程。

4.4 常见问题避坑记录：五条容易翻车的操作细节

按“现象 → 原因 → 解决”的格式，把我在 CSB 环境里踩过的坑和同事踩过的坑整理五条：

避坑一：Butler 巡检状态码规则顺序导致持续误报。现象：服务访问正常，但巡检告警不断。原因：状态码检测配置了多条规则，规则按从上到下顺序匹配，第一条规则提前命中，后面的规则不再判断。解决：只保留一条精确的状态码规则，多条规则时必须按优先级从上到下排列，高优先级放最前。

避坑二：重启 Broker 后端口没起来。现象：执行 appctl.sh startLocal 显示成功，但 netstat 查不到端口。原因：旧进程没退干净，端口被占用，或者启动时连接地址服务器失败。解决：重启前先 ps -ef | grep cloud-gateway 确认旧进程状态，必要时先停干净；启动后立刻用 netstat 验证端口，失败则看 aosp.log 的启动报错，按报错逐条排查。

避坑三：日志写满磁盘导致 Broker 无响应。现象：调用大面积超时，登录机器发现 /home/admin/cloud-gateway/log 使用率 100%。原因：滚动日志机制只做轮转，不会自动清理历史文件，长时间运行后日志堆积。解决：把 df -lh 巡检固化到每日清单里，定期归档并删除过期日志，我一般保留 7 天以内的日志，太旧的直接清理。

避坑四：多节点拨测误报。现象：双节点 Broker 都正常，但多节点拨测结果不一致触发告警。原因：两个节点响应内容存在 IP、时间戳等正常差异，被比对逻辑判定为异常。解决：先做单节点拨测确认单点健康，确认是配置差异导致的响应差异后，再决定是否改用单节点拨测，或对多节点比对规则加白名单字段。

避坑五：直接用 root 或 admin 账号操作。现象：变更记录混乱，误操作后无法追踪责任人。原因：文档运维准备章节明确写了“不建议直接使用 root 或 admin 账号”，但实际操作时图省事很容易直接登。解决：用最小授权账号操作，变更申请里写清楚要执行的命令和影响面，误操作时才能追溯和回滚。

5. csb-broker 配置参考：线程池、连接、网络与 CORS 的调整边界

5.1 线程池配置：先看现象再动参数，别一上来就翻倍

csb-broker 的线程池配置直接决定 Broker 能扛住多少并发调用。文档里有“csb-broker 线程池相关的配置”这一节，但没有把全部参数值列出来，这意味着不同专有云版本之间参数名可能有差异，调整前要先确认你手里的版本实际支持的参数名。

调整的原则是现象驱动。如果大量调用超时且日志里出现线程池拒绝的报错，看最大线程数和队列容量；如果 CPU 没打满但响应变慢，看核心线程数和队列策略。我一般会先把最大线程数在当前基础值上调 20% 到 30%，观察一到两天，确认 CPU 和响应时间的变化趋势后再决定下一步，不会一次性翻倍。线程池调大意味着更多线程竞争 CPU 和内存，收益不一定线性。

# csb-broker 线程池与连接配置（示例，参数名以你的版本实际为准） server.tomcat.max-threads=200 server.tomcat.min-spare-threads=20 server.tomcat.max-connections=1024 server.tomcat.accept-count=100

max-threads 是最大工作线程数，调大能提升并发吞吐，但会加大内存压力和 GC 负担，需要配合堆内存一起评估。min-spare-threads 是常驻线程数，调大能降低冷启动时的线程创建开销，但也会抬高基础资源占用。max-connections 是最大连接数，超过这个数的连接会进入等待队列。accept-count 是等待队列长度，队列满了新请求才会被拒绝。这四个值是一套组合，只调其中一个往往会把瓶颈挤到另一个参数上。

5.2 连接配置：三个超时要分开理解

连接配置里最容易混淆的是三组超时：建立连接超时、读取响应超时、从连接池获取连接的超时。它们对应的故障现象完全不同。建立连接超时说明网络链路、负载均衡或目标端口有问题，排查方向是网络层；读取响应超时说明服务提供方处理太慢或 Broker 线程池不够，排查方向是后端的处理能力和队列状态；连接池获取连接超时说明请求量超过了连接池容量，排查方向是池大小和请求峰值。

配置时最常见的错误是把读超时压得过低。有人为了让故障发现得更快，把读超时设成 1 秒，结果正常的慢接口全部被误杀，值班群一晚上全是告警。我一般的做法是先用日志统计接口耗时分布，看 p95 和 p99 是多少，读超时设在 p95 的 1.5 到 2 倍左右，既留出余量，又不会让真正卡死的请求拖太久。连接池大小也不是越大越好，连接多了后端提供方的压力会成倍增加，配合压测数据来定更靠谱。

5.3 网络配置：监听地址、端口冲突与负载均衡健康检查

Broker 在多网卡环境下要特别注意监听地址是否绑在了正确的网卡上。专有云环境里的机器通常有管理网、业务网、存储网等多张网卡，Broker 的监听地址绑错网卡，负载均衡转发过来的请求会直接连接超时。

端口冲突的排查路径：先用 netstat 看端口监听情况，再用 ss 或 lsof 确认占用进程，最后看防火墙策略是否放行了对应端口。排查的时候要按文档端口清单逐项对，特别是版本兼容端口，新旧版并存的环境里很容易出现一个端口被两个进程抢占的情况。

还有一类问题容易被忽略：负载均衡的健康检查路径和巡检 URI 不一致。CSB 服务总线的负载均衡由客户提供，文档里提到常见选择有 F5 或 SLB 这类设备，如果负载均衡的健康检查配的是根路径，而服务实际健康检查接口是别的路径，就会出现“负载均衡认为节点正常、但真实接口已经不可用”的状态，流量继续往故障节点打，调用失败率直线上升。我一般在巡检时会把负载均衡的健康检查配置纳入检查范围，确保它的探测路径和实际服务健康状态一致。

5.4 http-cors 支持配置：跨域问题别误判成服务故障

http-cors 配置影响的是控制台或门户侧发起的跨域调用，不影响 Broker 之间的内部调用。CORS 配置错的时候，表现是浏览器控制台报跨域错误，但后端日志里没有任何异常，这时候特别容易把问题误判成服务故障，白查半天。

配置时把 allowed-origins 按实际门户域名收敛，不要放开成 *。专有云环境里控制台访问通常要走代理和域名跳转，CORS 的 Origin 头跟浏览器地址栏的域名强相关，配置时要把实际使用的域名都覆盖到。调完 CORS 后用浏览器实测一次跨域调用，确认响应头里带了正确的 Access-Control-Allow-Origin 再结束变更。有些场景改 CORS 配置不用重启 Broker，但保守起见，我把这类改动也按变更流程走一遍，改完立即验证，不留下没验证的配置变更。

6. 日志排查与 DAuth 接入：运维文档最后两章的正确用法

6.1 用日志分类先圈定故障范围

CSB 的服务总线日志默认在 /home/admin/cloud-gateway/log/aosp.log，排查时我先按关键字把日志切成几段：鉴权问题查 AUTH、TOKEN、DAuth 相关行；超时问题查 TIMEOUT、threadpool、reject 相关行；协议转换报错查 protocol 相关行。这样切完，故障范围基本能缩到一两层组件。

# 从 Broker 日志中快速定位鉴权链路和线程池超时记录 grep -E "AUTH|TOKEN|DAuth" /home/admin/cloud-gateway/log/aosp.log | tail -50 grep -E "TIMEOUT|threadpool|reject" /home/admin/cloud-gateway/log/aosp.log | tail -50

第一条看鉴权链路，DAuth 返回的异常码会体现在这几类关键字附近；第二条看线程池和超时记录，能直观看到是连接池耗尽还是单次调用超时。tail -50 控制输出量，日志量大时先取尾部再看上下文。如果某类日志量突然暴增，基本能锁定是哪个环节在抖动。日志关键字的具体格式会随版本有差异，但先按功能分类再查细节的思路不会变。

6.2 DAuth 企业账号接入：三个接口完成认证闭环

DAuth 负责 CSB 的认证、授权、鉴权。企业自有账号系统接入 DAuth 标准时，文档给了三个实现点：登录页面、获取用户接口、查询用户接口（可选）。核心是走通“页面登录 → 换取凭证 → 获取用户信息”的闭环。

接入时最容易忽略的是错误码处理。凭证失效、用户不存在、权限不足要返回不同的错误码，DAuth 侧才能精确判断是账号问题还是接口问题。如果所有异常都返回同一个错误码，排障时只能靠猜，线上对接会非常痛苦。

6.3 我的运维文档阅读顺序

拿到这类运维指南 PDF，我一般先从目录里挑出“高危操作”和“故障处理”两章读透，把 G3 级操作抄成一张值班清单贴在最显眼的地方。这份 V3.7.1 文档里，重启 Broker、CSB 控制数据库用户名密码变更、优雅停止都属于这类操作，动手前一定先想清楚影响面再走变更流程——这是我踩过几次坑之后形成的习惯。从那以后，我每次接手新的中间件运维文档都强制走一遍这个流程：先看高危操作和故障处理，再梳理组件边界和巡检清单，最后才是配置调优。文档版本是 20190124，如果你手里的环境版本更新，配置参数名和端口清单可能会有变化，以你环境实际部署参数为准。希望这份拆解思路帮到你。

本文还有配套的精品资源，点击获取