2. 环境规划与部署架构
Active Workspace（以下简称 AWC）的环境规划不是“先装起来再说”的工作，它决定了后续三年内系统的性能上限、扩容成本和故障恢复能力。AWC 本身是一个典型的 Java 微服务 + 前端静态资源 + 搜索索引 + 数据库访问的复合体，它并不孤立运行，而是与 Teamcenter 企业服务器（TC Server）、FSC（File Server Cache）、数据库、Solr 索引服务、Web 层（通常为 WebLogic 或 Tomcat）共同构成一条完整的请求链路。因此，部署模式的选择必须从“整条链路”出发，而不是只看 AWC 这一个进程。
一、三种部署模式的适用边界
单机模式把 TC Server、数据库、Web 层、AWC 和 Solr 全部放在一台物理机或虚拟机上。它的优点是部署快、网络延迟几乎为零、排障简单，适合 POC 验证、开发环境、培训环境以及并发用户少于 30 人的小型部门。它的致命弱点是单点故障：一旦这台机器宕机，整条链路全部中断，且 CPU、内存、磁盘 IO 相互争抢，AWC 的 JVM 与数据库的缓冲池会互相挤压。
集群模式把 Web/AWC 层横向扩展为多个节点，前置负载均衡器，TC Server 与数据库独立部署，Solr 可独立成集群。它解决的是并发能力和可用性问题：单个 AWC 节点故障时，负载均衡器把流量切到存活节点，用户几乎无感知。集群模式适合 100 人以上、有明确 SLA 要求的生产环境。
云部署模式本质上是集群模式在 IaaS/PaaS 上的实现，但引入了弹性伸缩、托管数据库、对象存储和跨可用区（AZ）容灾。它的关键差异在于：网络延迟从“局域网微秒级”变成“可用区内毫秒级”，因此数据库与 TC Server 必须同可用区部署，跨可用区只用于容灾副本，不能用于日常读写。
二、硬件 Sizing 的估算方法
Sizing 的核心输入是三个量：并发在线用户数、峰值请求速率、数据体量（尤其是文件卷和索引量）。一个可用的经验起点是：每 100 个在线用户配置 1 个 AWC 节点（4 vCPU / 16 GB 内存），JVM 堆建议设置为物理内存的 50%~60%，即 8~10 GB，剩余内存留给操作系统页缓存和 JVM 堆外内存。
数据库侧，Teamcenter 的 Oracle 或 SQL Server 实例建议独立部署，内存不低于 32 GB，且必须使用 SSD 或企业级 NVMe。Solr 索引节点的内存与索引量强相关，经验值为每 100 万文档约需 2~4 GB 堆内存，同时磁盘预留索引体积 2 倍以上的空间用于合并操作。
下面这张图给出了一条典型的 AWC 生产请求链路与各层的高可用设计要点，可作为规划时的对照参考：
三、网络拓扑的关键约束
AWC 对网络延迟非常敏感，因为一次页面加载可能触发数十次 TC Server 调用和 Solr 查询。规划时应遵守三条硬约束：
- AWC 节点与 TC Server 必须处于同一低延迟网段，建议 RTT 小于 1 ms，跨机房部署会显著拖慢页面响应。
- TC Server 与数据库之间建议万兆互联，因为元数据查询和签入签出会产生大量小包往返。
- FSC 与 TC Server 必须共享同一存储卷或高速 NAS，文件缓存命中率直接决定大装配体的打开速度。
对外暴露的只有负载均衡器的 443 端口，AWC 节点、TC Server、数据库、Solr 均不应直接暴露到用户网段。如果使用云部署，安全组应只允许负载均衡器网段访问 AWC 节点端口（默认 8080 或 8443）。
四、高可用设计的落地检查
高可用不是“多买一台机器”，而是要让每一层都能在单点故障时继续提供服务。规划阶段可以用下面这份检查表逐项确认：
| 层级 | 单点风险 | 推荐做法 | 验证方式 |
|---|---|---|---|
| 接入层 | 单台负载均衡器宕机 | 双机 Keepalived + VIP 漂移 | 手动关闭主节点，观察 VIP 是否在 3 秒内漂移 |
| AWC 层 | 单节点 JVM 崩溃 | 至少 2 节点，健康检查间隔 5 秒 | kill 一个节点进程，确认请求自动切换 |
| TC Server | 进程池耗尽或节点宕机 | 双节点 + 共享池配置 | 模拟高并发，观察池占用与排队情况 |
| 数据库 | 实例故障 | 主备 + 自动切换（Data Guard / AlwaysOn） | 执行一次计划内切换演练，记录 RTO |
| Solr | 索引分片不可用 | 副本数 ≥ 2，分片均匀分布 | 停掉一个 Solr 节点，确认检索仍返回结果 |
五、一个可参考的 sizing 示例
假设某制造企业有 300 名工程师需要日常使用 AWC，峰值并发约 120 人，文件卷总量 2 TB，Solr 索引约 800 万文档。按前面的经验值可以推算出：
AWC 节点数 = ceil(120 / 100) = 2 个节点（建议 3 个，留冗余）
单节点配置：4 vCPU / 16 GB，JVM 堆 -Xmx10g
TC Server：2 节点，每节点 8 vCPU / 32 GB
数据库：1 主 1 备，每节点 16 vCPU / 64 GB / NVMe SSD
Solr：3 节点，每节点 8 vCPU / 32 GB，堆 16 GB，副本数 2
FSC：与 TC Server 同网段，共享 10 GbE 存储，缓存盘 ≥ 1 TB
负载均衡：2 台，Keepalived + VIP，健康检查 /awc/health 每 5 秒
需要强调的是，以上数字是基于经验公式的示例估算，不是实测结果。真实项目必须在 POC 阶段用接近生产的数据量和并发模型压测，观察 AWC 节点 CPU 使用率、JVM GC 频率、TC Server 池占用、数据库等待事件和 Solr 查询延迟，再据此调整节点数量和单节点规格。压测时建议至少覆盖“登录 + 打开大装配体 + 全文检索 + 签入签出”四条典型路径，因为它们的资源消耗模式差异很大。
环境规划的最终产出应该是一份可执行的部署清单：每台机器的角色、CPU/内存/磁盘规格、IP 与网段、端口开放关系、高可用切换方式、以及压测验收指标。这份清单越具体，后续安装和排障的成本就越低。