企业架构实践（五）：从基础设施到技术架构——构建企业 IT 运行环境

一、系统能够运行，背后需要什么？

在前面的文章中，我们分别讨论了企业 IT 系统、应用集成和数据架构。

这些内容主要关注企业有哪些业务系统、系统之间如何协作，以及数据如何产生和流转。

但还有一个问题需要回答：

这些应用系统究竟运行在哪里？它们依赖哪些基础技术？

例如，一个 MES 系统从开发到正式上线，除了业务功能本身，还需要考虑：

• 应用运行在哪种操作系统上？
• 使用物理服务器还是虚拟机？
• 是否使用容器化部署？
• 数据库部署在哪里？
• 文件存储如何提供？
• 应用之间如何通信？
• 如何监控系统运行状态？
• 出现故障后如何排查和恢复？

这些问题涉及企业 IT 的基础运行环境，也是技术架构（Technology Architecture）需要关注的内容。

学习 TOGAF Standard 10 时，我逐渐意识到，技术架构并不只是服务器、网络设备和操作系统的清单。

它更重要的价值，是把支撑企业应用运行的技术平台、基础设施和相互依赖关系梳理清楚。

二、什么是技术架构？

在 TOGAF 的架构内容中，技术架构属于信息系统架构之后的重要组成部分。

如果说应用架构关注的是：

• 企业有哪些应用系统？
• 各个系统承担什么职责？
• 系统之间如何交互？

那么技术架构关注的就是：

• 这些应用运行在哪些技术平台上？
• 使用什么操作系统和运行环境？
• 依赖哪些数据库、中间件和存储服务？
• 不同技术组件之间如何连接？
• 如何保障系统的性能、可用性和可维护性？

可以用一个简单的例子理解。

假设企业有一个 MES 系统：

这些架构视角描述的是同一个企业 IT 环境，只是关注的角度不同。

技术架构并不是孤立存在的，它需要支撑上层应用和业务运行。

三、从基础设施开始理解技术架构

对于制造企业而言，技术架构通常可以从基础设施开始梳理。

我所在企业目前的技术环境，主要包括服务器、虚拟化平台、操作系统、容器平台、网络、存储以及各类基础软件。

如果按照层次进行整理，可以形成下面的结构：

这只是一个便于理解的分层方式。

实际环境中，各层之间并不一定是严格的一对一关系。例如，数据库可以直接运行在虚拟机上，也可以运行在容器中；容器平台本身也依赖底层计算、网络和存储资源。

技术架构需要把这些关系表达出来，而不仅仅是按照产品名称分类。

四、虚拟化平台：基础计算资源的管理

4.1 为什么需要虚拟化？

在早期的 IT 环境中，一个应用可能直接部署在一台物理服务器上。

随着业务系统不断增加，如果每个系统都使用独立的物理服务器，就容易出现资源利用率低、服务器数量多、维护复杂等问题。

虚拟化技术（Virtualization）可以将物理服务器的计算、内存和存储资源进行抽象，再划分为多个虚拟机。

每台虚拟机可以运行独立的操作系统和应用。

目前企业使用 VMware vSphere 作为虚拟化平台，主要用于管理虚拟机资源，并为上层应用提供计算环境。

4.2 虚拟化平台在整体架构中的位置

可以将其理解为：

物理服务器提供 CPU、内存和硬件资源，vSphere 在这些资源之上创建和管理虚拟机，虚拟机再运行 Linux 或 Windows 操作系统，最终承载各类应用。

例如：

Physical Server
       |
       v
VMware vSphere
       |
       +------------------+
       |                  |
       v                  v
    Linux VM           Windows VM
       |                  |
       v                  v
  Business Apps       Other Services

这种方式让基础资源管理更加灵活。

例如，可以根据应用需求调整虚拟机的 CPU 和内存配置，也可以通过虚拟机管理平台完成日常运维工作。

4.3 虚拟化并不等于高可用

这里有一个需要特别注意的地方。

使用虚拟化平台，并不代表应用就自动具备高可用能力。

虚拟机可以运行在虚拟化平台上，但如果底层资源、网络、存储或者应用本身存在单点故障，仍然可能影响业务。

因此，在技术架构中，需要进一步区分：

• 虚拟化能力。
• 计算资源冗余。
• 存储冗余。
• 网络冗余。
• 应用层高可用。
• 数据备份与恢复。

这些能力解决的问题并不相同。

例如，虚拟机备份可以帮助恢复虚拟机，但不能直接代替数据库备份；数据库备份也不能代替应用配置和文件数据的备份。

架构设计需要根据业务重要程度确定相应的保护措施。

五、Kubernetes：从虚拟机到容器化应用

随着企业自研系统和基础服务逐渐增加，单纯依靠虚拟机部署应用，在部署、升级和资源管理方面会遇到一些限制。

容器技术提供了另一种应用运行方式。

5.1 什么是容器化？

容器化（Containerization）是将应用程序及其运行依赖封装在容器中，使应用能够在相对一致的环境中运行。

与传统部署方式相比，容器化有几个比较明显的特点：

• 应用及其运行依赖可以一起打包。
• 部署环境相对统一。
• 应用可以通过镜像进行版本管理。
• 更方便地进行自动化部署。
• 可以与持续集成和持续交付流程结合。

例如，一个基于 .NET Core 的 Web API，可以构建成 Docker 镜像，然后部署到 Kubernetes 中运行。

5.2 Kubernetes 在企业技术架构中的作用

Kubernetes 是容器编排平台，主要负责容器化应用的部署、调度和运行管理。

目前企业已经使用 Kubernetes 承载多个业务应用和基础服务。

例如：

• ERP Sync Service。
• MES 相关服务。
• Document Generator。
• Message Service。
• MinIO。
• RabbitMQ。
• 其他内部应用和服务。

从技术架构角度来看，Kubernetes 不只是一个部署工具，它已经成为企业应用运行环境的重要组成部分。

可以将整体关系简化为：

Physical Infrastructure
          |
          v
    VMware vSphere
          |
          v
      Linux VMs
          |
          v
     Kubernetes
          |
          +----------------------+
          |          |           |
          v          v           v
         MES     ERP Sync     Document
                 Service      Generator
          |
          v
      Application
       Services

这里需要说明，以上是逻辑关系示意，并不代表所有应用都部署在同一台虚拟机或同一个 Kubernetes 节点上。

5.3 容器平台也有自己的技术依赖

Kubernetes 本身并不能独立运行。

它需要底层计算资源、网络和存储支持。

例如：

• 计算资源来自虚拟机或物理服务器。
• 网络负责 Pod、Service 和外部系统之间的通信。
• 持久化存储用于保存需要长期保留的数据。
• 镜像仓库用于管理容器镜像。
• 监控和日志平台用于观察集群及应用状态。

因此，在技术架构图中，不能只画一个 Kubernetes 方框，然后把所有应用放进去。

还需要逐步梳理 Kubernetes 与底层资源之间的关系。

5.4 容器化不代表所有问题都得到解决

容器化能够改善应用部署和管理方式，但也会带来新的运维要求。

例如：

• 如何管理镜像版本？
• 如何处理配置和密钥？
• 如何管理持久化存储？
• 如何进行资源限制？
• 如何监控 Pod 和节点状态？
• 如何处理应用升级失败？
• 如何备份和恢复有状态服务？

特别是数据库、消息队列和对象存储等有状态服务，不能仅仅关注容器是否正常运行，还需要考虑数据持久化和恢复能力。

六、数据库与中间件：应用运行的重要基础

企业应用通常不会只依赖操作系统和容器平台。

数据库、中间件以及各种基础服务，同样是技术架构的重要组成部分。

结合目前的技术环境，可以从以下几个方面理解。

6.1 关系型数据库

目前企业使用 PostgreSQL 和 MySQL 作为主要的关系型数据库。

它们为不同业务应用提供数据存储能力。

同时，也使用了一些数据库连接和代理组件：

需要注意，数据库代理和数据库本身是不同的技术组件。

例如，ProxySQL 可以帮助管理应用与 MySQL 之间的连接和请求，但它并不能代替数据库自身的备份、复制和高可用设计。

同样，使用 pgpool 也不意味着 PostgreSQL 已经具备完整的高可用能力。

具体能力还需要结合实际部署模式和配置来判断。

6.2 Redis

Redis 是一种常用的内存数据存储系统。

在企业应用中，可以用于：

• 缓存。
• 临时数据存储。
• 会话数据。
• 计数和状态管理。
• 部分需要快速访问的数据。

使用 Redis 可以减少部分应用对关系型数据库的直接访问压力。

不过，缓存并不等于数据的权威存储。

在设计时，需要明确哪些数据可以丢失后重新生成，哪些数据必须持久保存，以及缓存失效后应用如何处理。

6.3 RabbitMQ

RabbitMQ 是消息中间件，主要用于不同应用之间的异步消息传递。

在目前的 ERP 与 MES 集成架构中，RabbitMQ 承担消息传递的角色。

实际链路是：

D365 F&O ↔ ERP Sync Service ↔ RabbitMQ ↔ MES

其中：

• ERP Sync Service 负责与 D365 F&O 进行业务数据同步。
• ERP Sync Service 和 MES 都连接 RabbitMQ。
• RabbitMQ 为双方之间的消息交互提供支持。
• D365 F&O 并不直接连接 RabbitMQ。

从技术架构角度来看，RabbitMQ 是独立的中间件组件，而不是 ERP 或 MES 的内部功能。

它的运行状态会影响相关集成业务，因此需要关注消息积压、消息处理失败、服务可用性和异常恢复等问题。

目前 RabbitMQ 在 Kubernetes 中采用单实例部署。

这意味着，在评估相关业务的可用性时，需要把 RabbitMQ 的单实例运行方式纳入考虑，而不能仅仅因为它运行在 Kubernetes 中，就认为它已经具备高可用能力。

七、存储架构：数据最终保存在哪里？

存储是技术架构中非常重要的一部分。

应用可以运行在容器中，数据库可以运行在虚拟机或容器中，但数据最终仍然需要保存到某种存储介质。

如果没有明确存储架构，应用部署方式和数据保护策略就很难形成完整的设计。

7.1 NFS：为 Kubernetes 提供持久化存储

目前 Kubernetes 后端使用 NFS 作为网络文件存储。

从架构关系来看，Kubernetes 中需要持久化存储的应用，可以通过相应的存储配置使用 NFS 提供的空间。

简化关系如下：

        Kubernetes
             |
             v
    Persistent Volumes
             |
             v
            NFS
             |
             v
      Storage Platform

这种方式可以让容器化应用使用持久化存储，而不必将重要数据只保存在容器自身的临时文件系统中。

不过，NFS 只是提供文件访问能力。

其自身的可用性、容量、性能和备份策略，仍然需要单独规划。

7.2 MinIO：统一对象存储能力

企业目前使用 MinIO 保存 MES 等业务系统产生的文件、图片和附件。

MinIO 采用多节点部署，通过 Bitnami Helm Chart 在 Kubernetes 中进行部署和管理。

与传统文件系统相比，对象存储更适合通过 API 访问和管理大量业务文件。

例如：

• MES 生产过程中的图片。
• 业务附件。
• 系统生成的文件。
• 其他需要由业务系统保存和访问的对象。

从应用架构角度看，业务系统通过 MinIO 提供的接口保存和读取文件，而不需要每个业务系统都独立建设一套文件存储服务。

不过，MinIO 多节点部署并不意味着备份工作已经完成。

存储服务的可用性和数据备份是两个不同的问题。

当前 MinIO 还没有独立的备份机制，因此需要将其作为后续技术架构优化的重要事项。

尤其是业务文件和附件，一旦发生误删除、数据损坏或者存储故障，可能直接影响业务数据的完整性。

后续需要结合数据规模、每日新增量、恢复时间要求和现有备份资源，规划独立的数据保护方案。

八、监控与日志：让技术架构具备可观测性

技术架构不仅要考虑系统如何部署，还需要考虑系统运行过程中如何被观察和管理。

如果应用已经上线，但无法及时发现异常，那么架构仍然存在明显的运维短板。

目前企业使用 Prometheus、Grafana 和 ELK 等工具支持系统监控和日志分析。

8.1 Prometheus

Prometheus 主要用于采集和存储监控指标。

例如：

• CPU 使用率。
• 内存使用情况。
• 磁盘空间。
• 网络流量。
• Kubernetes 节点状态。
• Pod 运行状态。
• 应用暴露的业务或技术指标。

通过这些指标，可以了解基础设施和应用的运行情况。

8.2 Grafana

Grafana 主要用于监控数据的可视化展示。

通过 Dashboard，可以将不同来源的指标集中展示。

例如，可以建立：

• 服务器监控面板。
• Kubernetes 集群监控面板。
• 数据库监控面板。
• 应用服务监控面板。

这样，运维人员可以从不同层次观察系统运行状态。

8.3 ELK

ELK 主要用于业务系统日志的集中采集、存储和查询分析。

在多个业务系统运行的环境中，如果每次排查问题都需要登录不同服务器查看日志，效率会比较低。

集中日志平台可以帮助我们：

• 按时间查询日志。
• 根据关键字检索异常。
• 关联不同应用的日志。
• 分析接口调用和业务处理过程。
• 辅助定位系统故障。

监控指标和日志分析解决的问题并不完全相同。

Prometheus 更关注系统运行状态和指标变化，ELK 更关注具体事件和日志内容。

两者结合，可以为日常运维和故障排查提供更完整的信息。

九、从技术清单到技术架构视图

前面介绍了虚拟化、容器平台、数据库、中间件、存储和监控等技术组件。

但如果只是整理出一份软件和硬件清单，还不能算是完整的技术架构。

技术架构更需要关注这些组件之间的关系。

例如，一个 MES 系统的技术依赖可以从以下几个方面梳理：

这张表可以帮助我们初步了解 MES 依赖哪些技术组件。

但如果要形成更完整的架构视图，还需要继续回答：

1. 这些组件分别部署在哪里？
2. 哪些组件是多个业务系统共同使用的？
3. 哪些组件存在单点风险？
4. 哪些组件之间存在版本或兼容性依赖？
5. 哪些组件需要重点监控？
6. 哪些数据需要独立备份？
7. 某个基础组件发生故障，会影响哪些业务系统？

这些问题能够帮助我们从单纯的技术盘点，逐步走向技术架构管理。

十、技术架构还需要关注什么？

除了技术组件本身，我认为还有几个方面值得在架构梳理过程中持续关注。

10.1 标准化

企业系统越来越多，如果不同项目完全按照自己的方式选择技术，长期下来就容易形成复杂的技术环境。

例如：

• 不同项目使用不同的开发框架。
• 数据库版本不统一。
• 容器镜像缺少统一管理。
• 日志格式各不相同。
• 部署方式缺少规范。
• 监控方式不一致。

这些问题短期内可能不会明显影响业务，但会增加后续维护成本。

因此，可以逐步建立技术标准和技术选型规范。

例如，明确主要开发框架、数据库类型、容器部署规范、日志规范和监控要求。

标准化并不是要求所有系统都使用同一种技术，而是尽量减少没有必要的技术差异。

10.2 安全性

技术架构还需要考虑安全问题。

例如：

• 操作系统安全更新。
• 服务器访问权限。
• 网络区域划分。
• 数据库访问控制。
• 容器镜像安全。
• 密钥和证书管理。
• 日志审计。
• 数据备份保护。

安全不应该只在应用上线之后再考虑，而应该成为技术架构设计的一部分。

10.3 可用性与灾难恢复

对于制造企业而言，部分 IT 系统中断可能直接影响生产和仓储业务。

因此，需要根据系统的重要程度确定可用性目标。

例如：

• 哪些系统允许短时间中断？
• 哪些系统需要优先恢复？
• 数据最多允许丢失多少？
• 系统发生故障后，需要多长时间恢复？
• 是否需要异地备份？
• 是否需要定期进行恢复演练？

这里可以引入两个常见概念：

RPO（Recovery Point Objective，恢复点目标）：发生故障后，业务能够接受的数据丢失时间范围。

RTO（Recovery Time Objective，恢复时间目标）：发生故障后，业务能够接受的最长恢复时间。

这两个指标需要结合业务部门的实际要求确定，而不是简单由 IT 部门自行设定。

10.4 生命周期管理

技术组件也有生命周期。

例如，操作系统、数据库、中间件和开发框架都会经历版本升级、停止维护等阶段。

如果企业长期不关注这些变化，就可能面临：

• 安全补丁无法获得。
• 版本兼容性问题。
• 厂商停止支持。
• 技术人员难以维护。
• 升级成本越来越高。

因此，技术架构还需要关注技术组件的版本、维护状态和升级计划。

十一、从技术架构回到 TOGAF

通过这一篇的梳理，可以看到技术架构并不是单纯的基础设施管理。

它与前面讨论的几个架构领域存在直接联系。

如果只关注业务系统，就可能忽略系统运行所依赖的基础设施。

如果只关注服务器和网络，也可能无法理解这些资源最终支撑了哪些业务。

TOGAF 提供的价值之一，就是帮助我们从不同架构领域观察企业，并把这些视角联系起来。

十二、这一阶段的实践总结

回顾企业现有的 IT 环境，从最初的服务器和基础网络，到虚拟化平台、Linux、Kubernetes，再到数据库、中间件、对象存储、监控和日志平台，技术环境已经逐步形成了多个层次。

这些技术组件并不是独立存在的。

例如：

• vSphere 为虚拟机提供运行环境。
• Linux 为应用和平台提供操作系统环境。
• Kubernetes 管理容器化应用。
• PostgreSQL 和 MySQL 提供数据存储。
• RabbitMQ 支持系统间消息交互。
• NFS 和 MinIO 提供不同类型的存储能力。
• Prometheus、Grafana 和 ELK 支持监控和日志分析。

从日常 IT 管理的角度看，我们可能更关注某个系统是否正常运行、某个服务是否出现故障。

但从企业架构的角度来看，还需要进一步理解这些技术组件之间的依赖关系，以及它们对业务连续性的影响。

我目前的理解是，技术架构建设不一定要从复杂的架构图开始。

可以先把现有技术环境梳理清楚，明确每个组件的用途、部署位置、依赖关系和运维责任，再逐步识别其中的风险和改进空间。

这样形成的技术架构，才更接近企业真实的运行环境，也更容易用于后续的规划和管理。

下一篇，我准备结合 TOGAF ADM 的后续阶段，讨论如何把前面梳理的业务、应用、数据和技术架构联系起来，进一步识别现状与目标之间的差距，并形成可执行的改进路线。