系统架构详解：四层部署模式与关键目录

Fri, 05 Jun 2026 10:00:00 +0800

Teamcenter 采用多层架构，Client 端基于 Java，Server 端基于 C（ITK）。理解其架构是运维和二次开发的前提。

Teamcenter 四层架构

层级	技术栈	核心组件	职责
客户端层（Client Tier）	Java	Rich Client (RAC), Active Workspace, Mobility 移动端, NX 集成客户端	用户交互界面
应用层（Application Tier）	J2EE	TC Server, FMS/FSC 文件服务, Pool 连接池, Web Services	业务逻辑处理、会话管理
服务层（Server Tier）	C++ ITK	TC Server 核心服务, ITK Handler, Workflow Engine, SOA Services	核心数据处理、工作流引擎
数据层（Data Tier）	DB + File	Oracle/SQL Server/PostgreSQL, Volume（文件卷）	持久化存储

部署模式对比

模式	架构	说明	适用场景
二层部署（2-Tier）	Client → DB	客户端直接连接数据库，无中间层	小规模测试、个人学习
三层部署（3-Tier）	Client → J2EE → DB	客户端通过 J2EE 应用服务器连接数据库	中小型团队、Web 访问
四层部署（4-Tier）	Client → J2EE → C++ Server → DB	完整 C/S 架构，TCFS 文件系统服务管理文件卷	企业级生产环境

关键目录与文件服务

%TC_ROOT% — Teamcenter 安装目录，包含 bin（可执行文件）、include（ITK 头文件）、lib（库文件）、sample（示例代码）
%TC_DATA% — Teamcenter 数据目录，包含站点配置、日志、本地库等
Volume（文件卷） — 存储实际文件数据（3D 模型、2D 图纸等），通过 FSC（File Server Component）/ FCC（File Client Component）管理

⚠️ 企业生产环境强烈推荐使用 4-Tier 部署，保证系统的安全性和可扩展性。

K8s 云原生架构实战：从单体到微服务的演进

Thu, 04 Jun 2026 20:00:00 +0800

为什么迁移到云原生？

弹性伸缩：流量高峰自动扩容，闲时缩容省钱
故障隔离：单个服务崩溃不影响全局
发布效率：从手动部署到 GitOps，发布从小时级降到分钟级

架构全景

┌─────────────────────────────────────────┐
│              Ingress (Nginx)            │
├─────────────────────────────────────────┤
│  API Gateway → 服务网格 (Istio)         │
├────────┬────────┬────────┬──────────────┤
│ 用户服务 │ 订单服务 │ 支付服务 │ 消息服务      │
├────────┴────────┴────────┴──────────────┤
│           持久层 (PostgreSQL + Redis)    │
└─────────────────────────────────────────┘

关键决策

1. Helm vs Kustomize

最终选了 Kustomize —— 轻量、无需额外学习 Helm 模板语法，K8s 1.14+ 原生支持。

2. 服务网格要不要上？

初期没上 Istio，用 K8s Service + Ingress 足够。服务网格在微服务数量超过 20 个时才体现价值。

3. 可观测性三板斧

日志：Loki + Promtail（比 ELK 轻量 10 倍）
指标：Prometheus + Grafana
追踪：Jaeger（分布式链路追踪）

踩坑

imagePullPolicy: IfNotPresent 没设，每次都拉镜像，慢得离谱
资源限制没设，一个服务吃光节点内存
Health Check 没配，滚动更新直接断流

📝 完整 YAML 配置清单和部署脚本已整理，后续开源。

架构设计 on 文艺技术笔记