简介本资源是阿里云专有云企业版V3.7.1中云服务总线CSB的官方运维指南PDF文档面向专有云环境下的系统运维工程师、中间件管理员及企业级云平台维护人员聚焦CSB服务的部署、配置、监控与故障排查等核心运维场景。文档内容体系完整涵盖法律声明与通用约定、系统与组件架构解析、安装部署全流程、配置管理规范、多维度监控指标说明以及典型问题的troubleshooting排错步骤具备强实操指导性。资源为单文件PDF格式共1个文件大小986KB轻量易获取便于随查随用。目前已有281人学习下载适合需快速掌握CSB运维要点、构建标准化运维流程或应对生产环境问题的技术人员。1. 这不是一份普通PDF专有云CSB V3.7.1运维指南的实战价值与适用边界你手头这份《阿里云专有云企业版 V3.7.1 云服务总线 CSB 运维指南 20190124.pdf》表面看是份过期文档——版本号V3.7.1、日期2019年连K8s都还没在生产环境大规模铺开。但如果你正维护一套已上线3年以上的专有云企业版尤其是基于“方舟”或早期DTCenter架构部署的系统它就是你排查CSB服务中断、控制台打不开、HSF调用超时等问题时唯一能直接对应到真实组件进程、端口、日志路径和Butler巡检规则的权威依据。它不讲云原生抽象概念只写ps -ef | grep cloud-gateway、netstat -ano | grep 8086、/home/admin/cloud-gateway/log/aosp.log这些命令和路径它把CSB Broker、Console、Admin、Cache、Store拆成可登录、可查进程、可验端口的独立节点它甚至明确告诉你哪些操作属于G3级高危比如改DAuth密码后不重启CSB Admin会导致控制台登录失败。这不是给新手扫盲的入门手册而是给驻场工程师、交付运维、二线支持人员准备的“黑匣子解码器”——当你面对一个运行在物理机虚拟化层自研中间件栈上的CSB集群所有监控告警都指向“服务不可用”而云平台控制台又只显示“组件健康”时这份指南里第4.1.3.1节的进程检查步骤、第5.4.2.4节的服务调用超时根因分析、第7章的csb-broker线程池配置参数就是你定位问题的唯一坐标系。它适用于三类人正在接手老旧专有云项目的运维同学、需要复现历史故障做压测验证的测试工程师、以及为国产化替代方案做兼容性评估的技术架构师——因为V3.7.1是很多政企客户从混合云向全栈信创迁移前的最后一个稳定基线版本。2. 拆解CSB V3.7.1真实部署结构从Butler巡检规则反推组件拓扑CSB V3.7.1不是跑在K8s Pod里的微服务而是一套严格遵循“物理机→虚拟机→应用进程”三层部署模型的专有云组件集合。它的运维逻辑完全绑定在Butler监控体系和手动SSH登录能力上。要真正用好这份指南必须先把它画成一张可落地的拓扑图而不是照搬文档里的抽象架构图。我们从Butler巡检规则反向还原——因为所有巡检项都是真实存在的、可执行的、有明确IP和端口的实体。2.1 Butler巡检规则即CSB组件存活清单文档第4.1.1节列出的Butler巡检规则名称本质就是CSB各组件在生产环境中的“身份证”。每一条规则都对应一个具体进程、一个监听端口、一个部署位置。例如csb-broker-restful-port-8086指向CSB Broker进程的RESTful API入口新版默认端口监听在Broker所在机器的8086端口csb-console-port-8080指向CSB Console控制台的Tomcat服务双节点部署每台机器独立监听8080csb-broker-hsf-port-12205指向Broker的HSF协议端口用于内部服务间调用老版本用12206新旧并存是V3.7.1的典型特征。这些规则不是凭空配置的它们由CSB产品安装包在部署阶段自动注入Butler系统。这意味着只要Butler里存在csb-broker-*规则就证明该集群中至少有一个Broker实例已成功注册反之若规则缺失大概率是部署未完成或Broker进程根本未启动。我曾在一个客户现场遇到控制台能登录但无法发布服务的问题第一反应不是查数据库而是登录Butler控制台——发现csb-broker-restful-port-8086规则状态为“未注册”立刻SSH到Broker节点执行ps -ef | grep cloud-gateway结果返回空证实Broker进程崩溃而非配置错误。2.2 组件部署映射表从文档描述到真实机器角色将文档第1.3节“部署架构”与第4.1.3节“命令巡检”交叉比对可生成一份运维人员必须烂熟于心的部署映射表。这张表决定了你SSH该连哪台机器、查哪个日志、改哪个配置组件分组组件名称部署形态关键进程名 / 启动脚本路径默认监听端口日志主路径依赖关系说明CSB服务总线CSB Broker双节点集群java -jar cloud-gateway.jar/home/admin/cloud-gateway/bin/appctl.sh8086, 12205, 9081/home/admin/cloud-gateway/log/aosp.log依赖Address Server、DAuth、HBaseCSB管控中心CSB Console双节点集群tomcat进程/home/admin/console/tomcat/bin/startup.sh8080/home/admin/console/tomcat/logs/catalina.out依赖CSB StoreMySQL、CSB AdminCSB管控中心CSB Admin双节点集群java -jar csb-admin.jar/home/admin/admin/bin/appctl.sh8083/home/admin/admin/log/admin.log依赖CSB Store、DAuth、TLog公共基础组件Address Server独立集群java -jar address-server.jar8080/home/admin/address-server/logs/server.logCSB Broker启动时通过jmenv.tbsite.net解析其地址公共基础组件DAuth独立集群java -jar dauth.jar8080/home/admin/dauth/logs/auth.log所有CSB组件登录鉴权的统一入口提示表中“默认监听端口”需结合文档第4.1.1节和第4.1.3.1节交叉验证。例如Broker的8086端口在Butler规则中明确为csb-broker-restful-port-8086而在命令巡检章节又要求netstat –ano |grep 8086二者指向同一事实。这种一致性是V3.7.1文档的可靠之处——它不玩概念只写可验证的操作。2.3 为什么必须用Butler而非Zabbix/Prometheus这个问题常被新接手的工程师问起。答案很直白V3.7.1时代的专有云企业版根本没有标准Exporter或Metrics接口暴露给第三方监控系统。Butler是阿里云为专有云深度定制的监控底座它通过Agent直连宿主机能获取到/proc下的进程信息、/sys下的硬件指标、以及组件自定义的HTTP健康检查端点如/health。而Zabbix这类通用监控只能做到“机器存活”无法判断csb-broker进程是否真正在处理请求——因为Broker可能Java进程在但线程池已满、GC频繁、或与DAuth连接中断。文档第4.2.3节“监控指标”明确列出Butler采集的CSB专属指标broker_active_thread_count活跃线程数、broker_request_qpsQPS、console_login_success_rate登录成功率。这些指标在Butler的OpenAPI里有对应字段但在Prometheus里你需要自己写Exporter去抓取而V3.7.1的Broker压根没提供/actuator/prometheus端点。所以当客户问“能不能把CSB监控接入我们现有的Zabbix大屏”我的血泪经验是先确保Butler巡检全部绿灯再考虑用Butler的API把关键指标同步过去——别试图绕过Butler。3. 命令巡检用5条Linux命令覆盖80%的CSB日常故障文档第4.1.3节“命令巡检”是整份指南里最硬核、最值得逐字背诵的部分。它不讲原理只列命令不谈优化只保存活。在专有云现场网络策略常限制外部访问你往往只有SSH权限而ps、netstat、df、ping、tail这五个命令就是你的听诊器、血压计和X光机。下面我把这些命令拆解成可直接粘贴执行的检查流并说明每一步背后的诊断逻辑。3.1 进程存活检查psgrep定位核心组件CSB所有组件均为Java进程但进程名不统一。不能只搜java必须用组件标识符精准定位# 检查CSB Broker进程新版 ps -ef | grep cloud-gateway | grep -v grep # 检查CSB Console进程Tomcat ps -ef | grep catalina | grep -v grep # 检查CSB Admin进程 ps -ef | grep csb-admin | grep -v grep # 检查DAuth进程认证中心 ps -ef | grep dauth | grep -v grep逻辑说明与参数说明ps -ef列出所有进程的完整信息用户、PID、PPID、启动时间、命令行grep 关键词筛选含特定字符串的进程行grep -v grep排除grep自身进程避免误判关键词选择依据文档第4.1.3.1节“CSB Broker运行时是一个Java进程”其JAR包名为cloud-gateway.jar故用cloud-gatewayConsole基于Tomcat故搜catalinaAdmin独立JAR包名为csb-admin.jar。现象判断若任一命令无输出说明该组件进程未启动。此时不要急着重启先看日志见3.4节因为进程退出常伴随OOM或配置错误。3.2 端口监听检查netstat验证服务网络可达性进程在不代表服务可用。必须确认其监听端口真实打开且未被占用# 检查Broker RESTful端口新版 netstat -tuln | grep :8086 # 检查Broker HSF端口新版 netstat -tuln | grep :12205 # 检查Console Tomcat端口 netstat -tuln | grep :8080 # 检查Address Server端口关键依赖 netstat -tuln | grep :8080 | grep address-server逻辑说明与参数说明netstat -tuln中-tTCP、-uUDP、-l仅监听端口、-n数字格式不解析域名grep :端口号精准匹配端口列冒号开头确保是端口而非PID文档第4.1.3.1节表格明确列出各端口用途8086是Broker对外提供REST API的端口若此处无监听外部调用必然失败12205是HSF内部调用端口若缺失服务间级联会中断address-server的8080端口若未监听Broker启动时会因无法解析jmenv.tbsite.net而卡死。关键技巧netstat -tuln | grep LISTEN可一次性查看所有监听端口再人工比对文档表4-1比逐条执行更高效。3.3 磁盘空间检查df防止日志写满导致服务假死CSB组件日志采用滚动策略但若磁盘长期满载滚动机制会失效最终导致Broker拒绝写入新日志而阻塞请求# 检查根分区使用率影响所有组件 df -h / # 检查Broker日志目录所在分区通常/home在独立分区 df -h /home # 检查Broker日志目录实际占用精确到目录 du -sh /home/admin/cloud-gateway/log/ # 检查Console日志目录 du -sh /home/admin/console/tomcat/logs/逻辑说明与参数说明df -h以人类可读格式GB/MB显示磁盘使用率du -sh 目录计算指定目录总大小-s汇总-h可读文档第4.1.3.1节强调“CSB已启动滚动日志机制请保持该巡检以备万一”说明日志管理是V3.7.1的薄弱环节血泪经验某客户Broker频繁超时ps和netstat均正常最后发现/home分区98%满du显示/home/admin/cloud-gateway/log/下堆积了2年未清理的aosp.log.2019-xx-xx文件。清理后服务立即恢复——日志写满是V3.7.1最隐蔽也最高频的“玄学”故障。3.4 日志实时追踪tail -f捕捉启动失败与运行时异常进程和端口都正常但服务仍不可用日志是唯一真相来源。V3.7.1的日志路径在文档中白纸黑字写明无需猜测# 实时跟踪Broker主日志关键 tail -f /home/admin/cloud-gateway/log/aosp.log # 实时跟踪Console启动日志 tail -f /home/admin/console/tomcat/logs/catalina.out # 实时跟踪Admin日志 tail -f /home/admin/admin/log/admin.log # 实时跟踪DAuth日志鉴权失败必查 tail -f /home/admin/dauth/logs/auth.log逻辑说明与参数说明tail -f实时追加显示日志新增内容-ffollow是核心路径全部来自文档第4.1.3.1节“默认路径为/home/admin/cloud-gateway/log/aosp.log”及第5章故障处理示例Broker的aosp.log是服务调用链路日志包含认证、路由、超时等全量信息catalina.out是Console启动过程日志若出现Caused by: java.lang.OutOfMemoryError说明JVM内存不足auth.log中若高频出现Invalid token则DAuth密钥可能已变更。避坑提示不要用cat aosp.log | grep ERROR因为ERROR可能是历史遗留tail -f才能看到当前正在发生的异常。3.5 依赖服务连通性ping和curl验证组件间通信CSB是组件协作系统单点正常不等于整体可用。必须验证关键依赖是否可达# 测试Address Server域名解析Broker启动前提 ping jmenv.tbsite.net # 若ping不通尝试直接curl其健康检查端点更准确 curl -I http://jmenv.tbsite.net:8080/health # 测试DAuth服务连通性所有组件鉴权依赖 curl -I http://dauth-host:8080/auth/check # 测试CSB StoreMySQL连通性Console和Admin依赖 mysql -h store-host -P 3306 -u csb_user -ppassword -e SELECT 1;逻辑说明与参数说明ping jmenv.tbsite.net是文档第4.1.3.1节明确要求的检查项jmenv.tbsite.net是Address Server的固定域名Broker通过它获取服务列表curl -I只获取HTTP响应头不下载内容速度快适合健康检查mysql -h直连Store数据库验证管控数据层是否就绪关键认知V3.7.1的组件间通信高度依赖内网DNS和固定端口ping通只是第一步curl返回HTTP/1.1 200 OK才代表服务真正就绪。曾有客户因DNS缓存未刷新ping通但curl超时折腾半天才发现是/etc/resolv.conf里nameserver配置错误。4. 高危操作避坑G3级变更的5个血泪现场记录文档第2章将运维操作分为G1/G2/G3三级其中G3级操作“有可能对业务产生影响”需客户侧双重确认。但现实中很多故障恰恰源于对G3操作边界的误判——以为只是改个配置实则触发了全局级联故障。以下是我在多个专有云项目中踩过的5个真实G3级坑按“现象→原因→解决”结构整理每一条都对应文档中的具体条款。4.1 现象CSB控制台登录后反复跳转至登录页F5刷新无效原因违反文档第5.4.1.3节“控制台登录后出现安全提示”的隐含前提——在未通知客户的情况下修改了DAuth的cookie.domain配置。V3.7.1的Console与DAuth共享同一域名下的Cookie若DAuth配置的domain为.company.com而Console部署在csb-console.company.com修改DAuth domain为.new-company.com后Console生成的登录Cookie无法被DAuth识别导致鉴权失败循环重定向。解决立即回滚DAuth的cookie.domain配置并重启DAuth服务同时清除浏览器所有company.com域下的Cookie后续操作任何DAuth配置变更前必须同步检查Console的web.xml中session-config的cookie-domain设置确保二者一致。4.2 现象服务发布成功但消费方调用返回404 Not Found原因误操作文档第5.4.2.1节“服务找不到”的G3场景——在Butler中删除了csb-broker-restful-port-8086巡检规则后未意识到该规则关联着Broker的HTTP服务注册。V3.7.1的Broker启动时会向Butler注册自身健康状态Butler再将此状态同步给负载均衡如F5。删除规则导致Broker虽在运行但负载均衡认为其“不健康”流量被切断。解决在Butler控制台重新创建csb-broker-restful-port-8086规则并等待3分钟让状态同步验证方法curl http://broker-ip:8086/health返回{status:UP}且负载均衡池中该节点状态变为绿色。4.3 现象CSB Broker CPU持续100%top显示java进程占满但aosp.log无明显错误原因触犯文档第5.4.2.6节“CPU占用率高”的禁忌——在未评估线程池压力的情况下将csb-broker的maxThreads参数从默认200调至1000。V3.7.1的Broker线程模型为传统BIO线程数暴增导致上下文切换开销剧增CPU空转。解决立即编辑/home/admin/cloud-gateway/conf/broker.properties将maxThreads1000改回maxThreads200执行appctl.sh restartLocal教训V3.7.1的线程池扩容必须配合acceptCount和connectionTimeout参数协同调整单独调大maxThreads是典型翻车操作。4.4 现象级联服务调用失败错误日志显示HSF service not found on address server原因忽略文档第4.1.3.1节“检查地址服务器”的强制要求——在升级Address Server后未同步更新所有Broker节点的/home/admin/cloud-gateway/conf/jmenv.properties文件中的address.server.url。V3.7.1的Broker启动时读取此文件获取Address Server地址旧地址失效导致服务列表拉取失败。解决在所有Broker节点执行sed -i s/old-url/new-url/g /home/admin/cloud-gateway/conf/jmenv.properties然后重启Broker注意此操作必须在所有Broker节点上同时完成否则出现服务列表不一致。4.5 现象修改CSB StoreMySQL的root密码后Console和Admin全部报500错误原因违反文档第5.4.1.5节“CSB控制数据库用户名密码变更”的G3流程——仅修改了MySQL密码但未更新/home/admin/console/conf/jdbc.properties和/home/admin/admin/conf/jdbc.properties中的password字段。V3.7.1的Console和Admin在启动时读取各自配置文件连接Store密码不匹配导致连接池初始化失败。解决编辑两个配置文件更新password后的值分别重启Console和Admin关键步骤重启前必须先ps -ef | grep console确认旧进程已退出避免端口冲突重启后检查catalina.out末尾是否有Connected to database字样。5. 故障根因定位从告警到日志的四层穿透法当Butler告警亮红灯或客户反馈“服务调用超时”你不能停留在“重启试试”。V3.7.1的复杂性在于组件多、依赖深、日志分散。我总结了一套四层穿透法从宏观告警层层下钻到微观代码行确保每次故障都能定位到确切原因。这套方法已在多个跨部门协同故障中验证有效。5.1 第一层Butler告警分类——锁定故障域Butler告警是第一道过滤器。V3.7.1的告警类型在文档第5.2节明确定义必须严格按此分类告警类型对应Butler巡检规则示例故障域判断逻辑容器异常告警csb-broker-restful-port-8086Broker进程或端口异常问题在Broker本体或其直接依赖Address Server、DAuth巡检异常告警csb-console-port-8080Console服务不可达问题在Console进程、Tomcat配置、或其依赖Store、Admin组件可用性故障Butler中csb-broker组件状态为DOWNBroker节点级故障需登录该节点查ps、netstat、aosp.log服务连续性故障Butler无告警但业务调用失败问题在服务链路内部如HSF路由、DAuth鉴权、HBase存储需查aosp.log中的traceId操作要点登录Butler控制台后先看告警时间戳是否集中。若多个csb-broker-*规则在同一分钟内告警大概率是网络分区或宿主机故障若仅单个规则告警则聚焦该节点。切忌一看到告警就全局重启——V3.7.1的组件重启有顺序依赖如必须先启DAuth再启Broker。5.2 第二层组件进程与端口——验证基础存活告警定位到具体组件后SSH登录对应机器执行第3章的命令巡检流。但此时要增加一个关键动作对比告警时间与进程启动时间。# 查看Broker进程启动时间精确到秒 ps -eo pid,lstart,cmd | grep cloud-gateway | grep -v grep # 查看Console Tomcat启动时间 ps -eo pid,lstart,cmd | grep catalina | grep -v grep判断逻辑若进程启动时间晚于Butler告警时间说明进程刚被重启过告警是重启前的状态若启动时间远早于告警时间如进程已运行3天则问题在运行时如内存泄漏、线程阻塞。曾有一个案例aosp.log显示大量OutOfMemoryError但ps显示Broker已运行72小时证实是缓慢内存泄漏非启动失败。5.3 第三层日志关键词扫描——聚焦高频错误模式V3.7.1的日志格式统一aosp.log中每行以[时间] [级别] [类名] -开头。针对不同故障扫描特定关键词效率极高故障现象必查日志关键词grep命令关键词含义与根因指向服务调用超时grep timeout /home/admin/cloud-gateway/log/aosp.log若匹配行含HSF invoke timeout检查csb-broker的hsf.timeout配置及下游服务响应若含http read timeout检查网络或目标服务。认证失败grep 401 /home/admin/cloud-gateway/log/aosp.log401 Unauthorized表明DAuth鉴权失败需查auth.log中对应token的校验日志。服务找不到grep not found /home/admin/cloud-gateway/log/aosp.logservice not found in registry指向Address Server服务列表未同步no provider for service指向服务未正确发布。数据库连接失败grep SQLException /home/admin/console/tomcat/logs/catalina.outCommunications link failure表明Console与Store网络不通Access denied表明密码错误。技巧用grep -A 5 -B 5 关键词-A后5行-B前5行查看上下文常能发现隐藏线索。例如timeout前一行可能是Sending request to http://downstream-service:8080/api这就锁定了问题服务。5.4 第四层配置参数溯源——对照文档验证生效值日志和进程都正常但行为异常一定是某个配置参数未生效或被覆盖。V3.7.1的配置分散在多处必须按优先级逐层检查JVM启动参数最高优先级ps -ef | grep cloud-gateway查看-D参数如-Dcsb.broker.maxThreads500会覆盖配置文件组件主配置文件/home/admin/cloud-gateway/conf/broker.properties对应文档第7章环境变量cat /home/admin/cloud-gateway/bin/setenv.shV3.7.1常用JAVA_OPTS传递参数Butler动态配置若有部分参数可通过Butler API动态下发需查Butler配置中心。血泪经验某次HSF调用不稳定查broker.properties中hsf.timeout3000正常但ps发现启动参数中有-Dhsf.timeout500根源是运维脚本里硬编码了错误值。永远相信ps输出的启动命令而不是配置文件——因为V3.7.1的启动脚本appctl.sh会拼接多层参数。6. 进阶技巧用Butler OpenAPI自动化巡检与告警收敛手工执行ps、netstat、tail在单集群尚可但当你负责10套V3.7.1专有云时必须自动化。Butler提供了稳定的OpenAPI文档虽未公开但SDK和内部接口稳定我用Python封装了一个轻量巡检工具每天凌晨自动执行并邮件告警。核心逻辑不是替代人工而是把重复劳动标准化把“经验”变成“代码”。6.1 Butler OpenAPI调用基础获取CSB组件健康状态Butler的/api/v1/health接口可批量获取组件状态。以下Python脚本演示如何调用需提前在Butler控制台申请AccessKeyimport requests import json # Butler API配置需替换为实际值 BUTLER_URL https://butler-api.internal:8443 ACCESS_KEY your_access_key SECRET_KEY your_secret_key def get_csb_health(): 获取所有CSB相关组件的健康状态 # 构造签名简化版实际需按Butler签名规范 headers { Content-Type: application/json, x-acs-accesskeyid: ACCESS_KEY, x-acs-signaturemethod: HMAC-SHA1 } # 查询CSB Broker、Console、Admin的健康状态 params { product: CSB, component: [csb-broker, csb-console, csb-admin] } try: response requests.get( f{BUTLER_URL}/api/v1/health, paramsparams, headersheaders, timeout10, verifyFalse # 内网证书常为自签 ) if response.status_code 200: data response.json() # 解析返回的健康状态 for item in data.get(result, []): component item.get(component) status item.get(status) # UP or DOWN last_check item.get(lastCheckTime) print(f[{component}] Status: {status}, Last Check: {last_check}) else: print(fButler API error: {response.status_code}) except Exception as e: print(fRequest failed: {e}) if __name__ __main__: get_csb_health()参数说明与逻辑BUTLER_URL是Butler API网关地址通常为https://butler-api.internal:8443内网域名ACCESS_KEY/SECRET_KEY在Butler控制台“API密钥管理”中创建权限需包含health:readparams[component]指定查询的CSB组件与Butler中注册的组件名严格一致返回的status字段直接对应Butler UI中的“健康/不健康”状态比SSH登录查ps更权威——因为它包含了端口探测、HTTP拨测等综合判断。6.2 告警收敛合并同类告警避免短信轰炸Butler默认对每个巡检规则单独告警一个Broker节点的3个端口告警会发3条短信。我们用API聚合只在“Broker整体不可用”时告警def check_broker_overall_health(): 判断CSB Broker整体健康状态3个关键端口任一失败即视为DOWN broker_ports [csb-broker-restful-port-8086, csb-broker-hsf-port-12205, csb-broker-ws-port-9081] all_up True down_reasons [] for rule_name in broker_ports: # 调用Butler API查询单个规则状态 status query_butler_rule_status(rule_name) # 此函数需自行实现 if status ! UP: all_up False down_reasons.append(f{rule_name} is {status}) if not all_up: # 发送聚合告警 send_alert(fCSB Broker DOWN! Reasons: {, .join(down_reasons)}) return all_up def send_alert(message): 发送企业微信/邮件告警示例 import smtplib from email.mime.text import MIMEText msg MIMEText(message) msg[Subject] 【紧急】CSB Broker 故障告警 msg[From] monitorcompany.com msg[To] ops-teamcompany.com s smtplib.SMTP(smtp.internal) s.send_message(msg) s.quit()设计思想V3.7.1的Broker是高可用集群单节点端口异常不等于服务不可用但若restful、hsf、ws三个核心端口同时异常则基本可判定该节点彻底失效。此逻辑将3条告警收敛为1条大幅提升告警有效性。6.3 配置备份自动化防止人为误操作的后悔药V3.7.1的所有配置文件都在/home/admin/下但手工备份易遗漏。我写了一个定时脚本每天凌晨压缩备份关键配置#!/bin/bash # backup_csb_config.sh DATE$(date %Y%m%d) BACKUP_DIR/backup/csb-config/$DATE mkdir -p $BACKUP_DIR # 备份所有CSB组件配置 cp -r /home/admin/cloud-gateway/conf $BACKUP_DIR/broker-conf cp -r /home/admin/console/conf $BACKUP_DIR/console-conf cp -r /home/admin/admin/conf $BACKUP_DIR/admin-conf cp -r /home/admin/dauth/conf $BACKUP_DIR/dauth-conf # 备 p a hrefhttps://download.csdn.net/download/qq_19067309/87833158 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p