企业官网建设流程全解析

简介：这份文档面向Teamcenter实施与运维人员，聚焦使用Deployment Center部署AWC2406的完整流程，适合正在搭建测试环境、核对安装配置或排查部署问题的中级读者参考。压缩包内为1个docx文件，约4.67MB，以图文笔记形式组织安装准备、环境配置与组件部署等章节，便于按目录快速查阅。已有312人学习下载，在同类部署资料中具有一定参考价值。内容涵盖安装前的主机名调整、防火墙关闭与IPv6禁用，JDK17.0.3、Siemens License Server和SQL Server2019的安装要点，以及将AWC2406介质加入Deployment Center存储库时的路径与日志排错提示。环境与组件部分涉及环境创建、可用软件更新、应用程序选择，以及Active Workspace Client、Gateway、Corporate Server、Database Server等组件的顺序配置，并提示Database Server与TC密码的特殊字符限制。文末还说明生成安装脚本、定位deploy_XXX.zip并运行deploy.bat的部署方式，可帮助读者对照检查配置、减少重复试错，适合作为官方文档之外的实操型补充材料。

1. 从一台干净的 Linux 说起：AWC2406 部署到底难在哪

手上拿到一台刚装好的 Linux、一份 AWC2406 介质、一个 Deployment Center 压缩包，任务是把这套 Web 客户端跑起来。第一次接触的人，多半会卡在 Deployment Center 的表单页：选项太多，看起来每项都能填，填错一项后面全盘报错。AWC2406 是这套 PLM 平台的 Web 客户端，Deployment Center 是配套的图形化部署工具，它把“装哪些组件、装在哪个目录、连哪个库、开哪些端口”收敛成一套模板变量。适合照着做的是实施和运维工程师，不用先啃完手册，但得知道自己在填什么。反直觉的是，真正让人翻车的不是点按钮，而是点按钮之前那几项环境基线，包括主机名、Java 版本、库连通性、卷权限；任何一项没对齐，最后都会收到一句语焉不详的失败提示。

2. Deployment Center 的模板机制：为什么它决定了后面所有的坑

装过两三次之后会发现，Deployment Center 界面上点的每一步，落到磁盘上就是同一份部署包。理解这一层，排查效率会差出一个数量级：界面报错只是表象，真正的线索在模板变量和渲染出来的配置文件里。这一章先把机制讲透，后面配置参数和排查故障才有判断依据。

2.1 Deployment Center 的真实产物是一份 TEM 部署包

Deployment Center 本身不装任何东西，它是模板的渲染器。模板里包含四类内容：组件定义，说明这套部署有几个组件、每个组件对应哪个安装包；变量定义，包括主机名、端口、数据库连接这类的占位符；依赖顺序，规定谁先启动、谁依赖谁；执行脚本，包括解压、配置替换、服务注册这一串动作。你在界面上填的每一个值，最后都被替换进模板的占位符，生成一份可执行的部署包。

这个理解带来的第一个判断是：部署失败先查变量渲染，再查环境。界面上的红色提示往往只是“某个步骤退出码非零”，真正的原因藏在部署包目录的配置文件和日志里。我一般会先执行一遍占位符检查，看有没有${这种没被替换掉的东西残留。

# 进入 Deployment Center 生成的部署包目录 cd /opt/awc2406/tem/awc2406-deploy # 检查配置文件里是否还有没被替换的占位符 grep -rn '\${' ./config/ ./scripts/ || echo "占位符已全部替换"

逻辑很直接：模板变量只要有一个没赋值，渲染结果里就会留下${xxx}原样。这种配置在启动阶段通常不会立刻报错，等到服务去连数据库或者注册到网关时才炸，报错信息还跟根因隔了好几层。grep的退出码非零就代表没找到，||后面那行是给正常情况一个明确回显，免得你盯着空输出怀疑命令没跑。

第二个判断是：不要在原始模板上直接改。介质自带的模板是只读的一部分，升级或者重新解压介质时会被覆盖，你之前调过的参数全丢。常见做法是导入模板后立刻克隆一份，命名带上环境和日期，后续所有修改都在克隆体上做。多人共用一个模板更麻烦，A 改了端口，B 重新渲染一次就把 A 的改动冲掉，排查时互相怀疑，这种血泪经验在实施现场一点都不少见。

第三个判断是版本匹配。模板版本必须和 AWC2406 介质版本对应，错配的典型表现是变量名对不上：你在界面里填的“网关端口”，渲染出来根本没落到配置文件里，因为新模板里这个变量已经改名了。Deployment Center 的界面不会拦这种错，它只认变量名，不认你的意图。拿到介质先确认模板来源，别从别的项目目录随手拷一份过来用。

2.2 AWC2406 的三层拓扑：Web 接入、微服务与数据层

AWC2406 不是一个单体应用，它至少分三层。分清这三层，端口规划、日志定位、启动顺序才有依据。

部署顺序上，数据层必须先就绪。数据库能连、FSC 端口通、卷目录可写，这三件事没做完就往下走，微服务启动时会一直重试连接，日志刷得飞快但看不出重点。微服务层起来之后才是 Web 接入层，因为 Web 层启动时要向注册中心报到，注册中心没人，容器起得来但页面打不开。

端口规划要按层来做。网关独占一个对外的端口，微服务实例从一个连续端口段里分配，Servlet 容器自己再占一个。规划时把这几个区间一次划好，别和机器上已有的服务打架。我一般会在环境检查阶段就把整个端口段扫一遍，而不是等部署到一半报 bind 异常再回头改。

日志也是分层的。每层日志目录不同，排查时先定位是哪一层的问题，再进对应目录，比在一个大日志文件里翻要快得多。这一条听起来废话，但在现场，把 Web 层日志当成全部日志看，是最常见的误判来源。

2.3 部署前先过一遍这张环境基线表

Deployment Center 的表单再长，也覆盖不了环境本身的问题。下面这几项必须在打开浏览器之前确认完，否则后面每一步都在赌。

这张表里最容易被跳过的是主机名解析和时钟。主机名只在部署后改一次，服务注册信息、证书里的名称全对不上，恢复起来比重装还费劲。时钟偏差不用太大，微服务之间校验令牌就会失败，表现出来的现象是“登录成功但立刻被踢回登录页”，很容易被当成账号问题去查。

3. 部署前的四道环境检查：主机、Java、数据库与共享卷

环境检查这一步没有 Deployment Center 界面那么有存在感，但它决定了后面所有步骤是顺水推舟还是反复返工。这一章按四道检查展开，每道给可直接执行的命令，跑完再开部署。

3.1 主机名、专用账号与目录规划

主机名要一次定死。服务注册、证书、配置文件里都可能引用它，部署完再改，等于把一堆注册信息变成脏数据。同时要保证本机能用这个主机名解析到自己，很多启动脚本第一步就是拿主机名做自检。

# 固定主机名，并确保本机能用主机名解析到自己 hostnamectl set-hostname awc2406-node01 grep -q "awc2406-node01" /etc/hosts || echo "10.20.30.41 awc2406-node01" >> /etc/hosts getent hosts awc2406-node01 # 建专用账号，应用不要用 root 跑 useradd -m -s /bin/bash awcdeploy mkdir -p /opt/awc2406/{app,logs,temp,data} chown -R awcdeploy:awcdeploy /opt/awc2406 chmod 750 /opt/awc2406 # 安装目录和日志目录的磁盘余量要分开看 df -h /opt /var /tmp

getent hosts是验证解析最直接的方式，它走的是系统解析链路，和启动脚本看到的结果一致。专用账号的意义不只是安全，文件属主错了，服务写日志会失败，而这类失败经常被包装成“日志组件初始化异常”，让人往错误方向查。目录分成 app、logs、temp、data 四个，是为了后面排查时能按类型定位：临时文件被系统清理导致启动失败，这种坑把 temp 放到/tmp下就会遇到。chmod 750是防止同机其他账号误读配置里的口令。

3.2 Java 与系统参数的检查命令

Java 版本不对，Deployment Center 有可能照样把包生成出来，直到服务启动才报UnsupportedClassVersionError。所以版本检查要放在最前面，而且要检查运行部署的那个账号下的 Java，不是 root 下的。

# 用应用账号检查 Java，别用 root 的 su - awcdeploy -c "java -version" su - awcdeploy -c 'echo $JAVA_HOME' # 文件句柄与进程数上限，微服务数量多时默认值不够 ulimit -n ulimit -u # 端口占用预检，把模板里打算用的端口先排一遍 for p in 8080 8443 9001 9010; do if ss -lnt | awk '{print $4}' | grep -q ":$p$"; then echo "端口 $p 已被占用" else echo "端口 $p 空闲" fi done # 时钟同步状态 timedatectl | grep -E "System clock|synchronized"

ulimit -n默认值常见是 1024，AWC2406 这一套微服务加上连接池，很容易顶到这个上限，表现是运行一段时间后开始报“too many open files”，重启就好、过一阵又犯，特别像玄学。修的时候别只改当前会话，写进/etc/security/limits.conf，并且确认服务是通过登录会话启动的，否则不生效。

端口预检的脚本里，ss -lnt输出第四列是本地地址加端口，用awk取出来再匹配，比grep ":$p"精确，避免 8080 匹配到 18080 这种误判。时钟那一行看的是System clock synchronized是否为 yes，不是看时区对不对，这两件事经常被混为一谈。

3.3 数据库连通性与文件卷权限预检

数据库这块，端口通只是第一层。防火墙放行、账号没锁、库字符集支持中文，这三件事任何一件不满足，都会在登录或者建表阶段炸出来。

# 第一层：端口连通性 nc -zv db-host 1521 # 第二层：用真实账号实际登录一次，别只看端口 # 以下为通用客户端示意，换成你们环境里的客户端 dbclient -h db-host -p 1521 -U awc_user -d awcdb -c "select 1" # FSC 端口连通性 nc -zv fsc-host 9000 # 卷目录权限，用应用账号测，不是 root ls -ld /data/volume01 su - awcdeploy -c "touch /data/volume01/.wtest && rm -f /data/volume01/.wtest && echo OK"

nc -zv只证明网络层通，证明不了账号可用。实际登录一次的意义在于把口令错误、账号锁定、库不存在这几种情况提前暴露，而不是等部署到一半连接池初始化失败。卷权限用应用账号测是关键，root 能写不代表应用能写，而附件上传失败的现象往往是“上传进度卡在 99%”，日志里只有一句权限异常，不点进去看不出是哪个目录。

文件卷还有一项容易漏：共享卷如果是网络挂载，要确认挂载参数里没有限制文件大小或者禁止某些操作，否则大附件写一半失败，重试也一样失败。

4. 用 Deployment Center 生成 AWC2406 部署包：六组参数怎么填

环境过了，才轮到 Deployment Center 出场。这一章按实际操作顺序走：导入模板、克隆、填参数、生成、试运行。参数部分按六组归类，每组说清楚填错的典型症状。

4.1 导入模板并克隆一份自己的

打开 Deployment Center 之后第一件事不是新建，是导入介质里自带的模板。导入完先别动，直接克隆一份，命名规则建议带上环境和日期，比如awc2406-prod-202406。克隆的好处是原始模板保持干净，升级或者重新导入时不会把历史修改带进来。

克隆之后先看模板的组件树，确认里面包含的组件和你要装的层次一致。如果数据服务端已经就绪，模板里应该只有 Web 层和微服务层；如果是从零开始，模板会把数据层也带上，这时候参数会多出一大截，别漏填。组件树里每个节点都能展开看变量列表，填之前先扫一眼有没有明显标红的必填项，比填到一半被打断要好。

还有一点：模板里的默认值不要照单全收。默认端口、默认路径在演示环境能用，在生产环境十有八九冲突。我的习惯是把所有默认值过一遍，凡是涉及端口和路径的，全部改成规划好的值，改完再统一检查一遍。

4.2 六组参数逐项填：主机、端口、数据库、管理员、FSC、证书

参数表按组看，比在界面上一个个找要清楚。下面这张表里的“填错的表现”是实际排查时最省时间的线索。

主机与路径这一组，重点在“应用账号要有写权限”。Deployment Center 生成部署包的时候用的是当前登录账号，执行部署的可能是应用账号，两者不一致时，最常见的现象是部署进行到一半报“无法写入”，但目录ls出来权限看着是对的。临时目录单独规划，别用系统默认的/tmp，那个目录有清理策略，服务跑一段时间后临时文件被清掉，报错信息通常和真实原因无关。

端口这一组，微服务端口段要连续。不连续也能配，但后面扩节点、加实例的时候会很难受。端口填完回看一眼有没有和 3.2 里扫出来的占用冲突，这个顺序别反。

数据库这一组，连接池上限不要照抄模板默认值。并发量小的环境默认值够用，并发一上来连接不够，表现是间歇性超时，很难复现。库名和账号要区分大小写，某些库在特定配置下大小写不敏感，换一台机器就敏感了，这种问题在迁移时特别常见。

管理员这一组，初始口令要符合口令策略，否则部署脚本创建账号那一步静默失败，后面登录一直报认证错误，你以为是服务没起来，其实服务好好的。

FSC 与卷这一组，卷名和路径必须和实际挂载的一致。卷名对不上，服务启动不报错，上传附件时才失败。

证书与 SSO 这一组，如果暂时不上 SSO，开关一定要显式关掉，别留空。留空的行为在不同版本里不一致，有的当成关闭，有的当成开启然后去连一个不存在的地址，表现就是登录页一直转圈。

4.3 生成部署包、试运行、正式执行

参数填完，点生成。生成之后先别急着执行，做两件事：占位符自检和试运行。这两步加起来不到五分钟，能省掉一次失败重来。

cd /opt/awc2406/tem/awc2406-deploy # 自检：确认没有未替换的占位符 grep -rn '\${' ./config/ || echo "没有未替换的占位符" # 试运行：只打印将要执行的动作，不落盘 ./tem.sh -t deploy --dry-run # 正式执行，输出留档 ./tem.sh -t deploy 2>&1 | tee /opt/awc2406/logs/deploy-$(date +%Y%m%d%H%M).log

第一行grep的退出码非零表示没有匹配，也就是干净。如果匹配到了，输出里会带文件名和行号，直接定位到是哪个变量没赋值。

--dry-run这个参数在不同版本的部署脚本里名字可能不同，有的叫-n，有的叫preview，以你拿到的部署包里tem.sh --help的输出为准。试运行的价值在于看执行顺序：数据层是不是排在微服务层前面，Web 层是不是最后，顺序错了说明模板选错了，这时候改还来得及。

正式执行用tee留一份带时间戳的日志，这个习惯在出问题的时候价值极高。部署失败的现场往往会被下一次重试覆盖，有日志就能回看第一步到底报了什么。日志文件名带时间戳，多次重试不会互相覆盖。

执行完之后不要只看最后一行是不是成功。逐段翻一下输出，特别是中间那些被标成 warning 的行，很多问题在部署阶段只是 warning，运行一段时间才变成故障。

5. 部署失败排查：AWC2406 安装的 5 个高频翻车点

部署失败的表现千奇百怪，但根因收敛下来就那么几类。这一章按“现象、原因、解决”的方式列五条，每条都是我在现场真实遇到过不止一次的。

5.1 服务进程起来了但页面打不开

现象：ps -ef能看到进程，端口也在监听，浏览器访问一直转圈或者直接连接被拒。

原因通常有三种。第一种是 Web 接入层起来了但微服务层没起来，Web 层只是个转发壳子，后端没有注册中心可用，请求发出去没人接。第二种是防火墙只放行了本机，外部访问被挡，本机curl能通，换台机器就不行。第三种是证书问题，浏览器对自签证书的处理策略不同，有的直接拒绝，页面看起来就是打不开。

解决顺序是先用本机curl打网关的健康检查地址，返回码正常说明服务本身没问题，问题在网络或证书；返回码异常就进网关日志看注册情况。注册中心里如果只有网关没有业务微服务，回到微服务日志找启动失败的原因，通常是数据库连接或者端口冲突。

5.2 登录报错先分清是认证还是授权

现象：页面能打开，输入账号口令之后报错，有的提示认证失败，有的提示无权限，还有的登录成功但立刻跳回登录页。

原因分三类。认证失败多半是初始管理员没创建成功，或者口令不符合策略被脚本跳过了。无权限是账号建了但没分配组织或者角色，属于配置遗漏。登录成功立刻跳回，八成是时钟偏差导致令牌校验失败，或者 SSO 开关状态和实际配置不一致。

解决时先看认证服务的日志，别在 Web 层日志里找。认证日志里会明确写是“用户不存在”“口令错误”还是“令牌过期”。令牌过期这一类，先去核对 3.2 里的时钟同步，再回头看 SSO 配置。这个顺序能省掉大量无效排查。

5.3 附件上传卡住多半在 FSC 和卷权限

现象：上传小文件正常，大文件卡在某个百分比不动，或者上传成功但下载报 404。

原因：FSC 服务没起来，或者卷路径配置和实际挂载不一致。还有一种情况是共享卷的挂载参数限制了单文件大小，超过阈值的写入直接失败。

解决：先确认 FSC 端口通、进程在，再看应用账号对卷目录有没有写权限。这两步在 3.3 已经做过一遍，但部署之后目录属主可能被部署脚本改掉，需要复查。大文件失败的话，看挂载参数里有没有文件大小限制，有就调整或者换存储路径。

5.4 端口冲突与重复部署的清理

现象：第二次部署时报端口被占用，或者服务起两个实例互相抢注册。

原因：上一次部署失败之后没清理干净，进程还在，端口还占着。或者部署脚本把服务注册成了系统服务，重装时旧服务没卸载。

解决：部署前先ss -lnt扫一遍，发现有残留进程就按端口找到 PID 再处理。系统服务用对应的管理命令确认状态，别直接删文件，删了注册信息还在，下次启动照样拉起一个残缺实例。重装之前养成习惯：停服务、确认端口释放、再执行部署。

5.5 时间不同步引发的令牌失效

现象：登录成功，点任何一个菜单都提示会话失效，反复登录反复失效。

原因：微服务之间校验令牌时会比对签发时间和当前时间，偏差超过阈值就判定失效。容器化部署时宿主机时间正常但容器内时间漂移，也会出现同样的现象。

解决：先看宿主机timedatectl的同步状态，再看容器内时间和宿主机是否一致。同步服务配置好之后，重启相关微服务让它们重新取时间。这一条特别隐蔽，因为所有日志看起来都正常，只有令牌校验那一行是 warning。

6. 部署后的验证与增量重部署：三条命令和一次最小化重跑

部署脚本返回成功不等于系统可用，这一步要自己验证。验证分两层：服务活着，和业务能走通。

6.1 三条命令确认服务真的活着

# 1. 进程在不在 ps -ef | grep -i awc | grep -v grep | wc -l # 2. 端口在不在监听 ss -lnt | grep -E ":(8080|8443)\b" # 3. 网关健康检查，看返回码 curl -k -s -o /dev/null -w "%{http_code}\n" https://awc2406-node01:8443/ # 4. 日志里最近的错误 tail -n 300 /opt/awc2406/logs/gateway.log | grep -iE "error|exception" | tail -n 20

第一条数进程数量，和预期组件数对不上就说明有服务没起来。第二条看端口，\b是为了避免 8080 匹配到 18080。第三条只看返回码，200 或者 302 都算正常，5xx 就要进日志。第四条是补充，日志尾部有 ERROR 不一定代表当前有问题，但连续出现同一条就值得看。

这四条跑完只能说明服务层活着。业务层还要走一遍：登录、打开一个模块、上传一个附件、下载回来。这四步覆盖了认证、微服务路由、FSC 和卷，基本能暴露大部分配置问题。

6.2 改一个参数后的最小化重部署

部署完发现某个参数填错了，最忌讳的是全量重装。全量重装耗时不说，还会把已经配好的数据覆盖掉。判断标准很简单：改的东西影响不影响已经写入的数据。

判断完之后，非全量的改动走“改配置、重启、验证”三步，别碰部署包。全量的改动才回到 Deployment Center 重新渲染。我一般会在改之前把原始配置文件备份一份，改完对比一下，确认只动了预期的那几行。

最后说个自己的习惯。每次部署完成，我会把这次用的模板名、关键参数、部署日志、验证结果记在一个文本文件里，放在部署目录旁边。下一次遇到同样的问题，翻这个文件比翻聊天记录快得多。这套东西的很多坑不是技术难题，是信息丢失，谁在什么时候改了什么，过两周就没人记得。把它记下来，比任何排查技巧都管用。希望帮到你。

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