2. 环境总览
智能寻源算法并非运行在单机孤岛，而是嵌入在采购供应链中台的一个微服务集群内。本章从全局视角拆解运行环境的三层结构：基础设施层、算法引擎层与业务接入层，并给出完整的硬件/软件依赖清单及标准化配置流程。
2.1 运行环境三层架构
下图展示了智能寻源算法从数据输入到策略输出的完整链路。架构采用“数据-计算-服务”分离设计，确保品类策略的迭代不影响线上寻源业务。
架构要点：品类策略配置通过业务接入层下发，算法引擎层实时加载策略并执行寻源匹配，基础设施层提供弹性计算与持久化存储。三层之间通过 gRPC 或异步消息解耦，单层故障不影响其他层核心功能。
2.2 硬件与软件依赖清单
以下清单基于生产环境 5000+ SKU、日均 10 万次寻源请求的规模制定。测试环境可按比例缩减 CPU/内存，但数据库与缓存规格建议不低于生产环境的 1/4。
2.2.1 硬件依赖
| 组件 | 推荐配置 | 最低配置 | 说明 |
|---|---|---|---|
| 算法计算节点 | 8 vCPU / 32 GB RAM | 4 vCPU / 16 GB RAM | 运行 Java/Python 微服务，需支持 AVX2 指令集 |
| 数据库节点 | 16 vCPU / 64 GB RAM / SSD | 8 vCPU / 32 GB RAM / SSD | MySQL 8.0 + Elasticsearch 8.x 混合部署 |
| 缓存节点 | 4 vCPU / 16 GB RAM | 2 vCPU / 8 GB RAM | Redis 6.x 集群模式，至少 3 主 3 从 |
| 对象存储 | 4 vCPU / 8 GB RAM / 2 TB HDD | 2 vCPU / 4 GB RAM / 500 GB HDD | MinIO 或 AWS S3 兼容存储，存放品类策略文件与模型 |
| K8s 管理节点 | 4 vCPU / 8 GB RAM | 2 vCPU / 4 GB RAM | 3 节点高可用，etcd 单独挂载 SSD |
2.2.2 软件依赖
| 软件/组件 | 版本要求 | 用途 |
|---|---|---|
| 操作系统 | Ubuntu 22.04 LTS / CentOS 7.9+ | 容器宿主机与开发环境 |
| Docker + containerd | Docker 24+ / containerd 1.7+ | 容器运行时 |
| Kubernetes | v1.28+ | 微服务编排与弹性伸缩 |
| Java | JDK 17 (LTS) | 寻源算法主服务 (Spring Boot 3.x) |
| Python | 3.10+ | 品类策略解析与评分模型推理 |
| MySQL | 8.0.30+ | 品类策略元数据、寻源结果持久化 |
| Elasticsearch | 8.10+ | 供应商与物料全文检索 |
| Redis | 6.2+ | 策略缓存、分布式锁、热数据加速 |
| MinIO | RELEASE.2024-01+ | 品类策略文件与算法模型存储 |
| Prometheus + Grafana | Prometheus 2.50+ / Grafana 10+ | 指标采集与监控看板 |
版本兼容性注意：JDK 17 与 Spring Boot 3.x 搭配时，请确认所有第三方依赖（如 Elasticsearch Client、Redis Client）已升级到 Jakarta EE 9+ 版本。Python 3.10 以下版本不支持类型注解的某些高级特性，可能导致品类策略解析器报错。
2.3 环境配置流程概览
配置流程分为 6 个标准步骤，从基础设施初始化到算法服务验证。建议使用自动化工具（Ansible/Terraform）执行前 4 步，减少人工操作误差。
2.3.1 各步骤关键操作
- 基础设施：使用 Kubespray 或 Rancher 部署 K8s 集群，配置至少 3 个 worker 节点，开启 HPA 与 Cluster Autoscaler。
- 中间件部署：通过 Helm Chart 安装 MySQL 8.0（主从）、Redis 6.x 集群、Elasticsearch 8.x 三节点集群。注意设置资源配额与持久卷声明。
- 存储初始化：在 MinIO 中创建
source-policy和algorithm-model两个桶，设置访问密钥与生命周期策略。 - 镜像构建：执行
mvn clean package -DskipTests打包 Java 服务，docker build -t source-algo:<tag> .构建镜像并推送至 Harbor 仓库。 - 服务部署：使用 Helm 部署算法微服务，配置 ConfigMap 挂载品类策略文件，通过 Service 暴露 gRPC 端口。
- 集成验证：运行预置的寻源测试用例，检查策略加载、匹配结果、评分排序是否与预期一致。
自动化配置建议：将步骤 1-4 编写为 Ansible Playbook，步骤 5 使用 Helmfile 管理多环境 values 文件。每次环境重建时，只需执行
ansible-playbook setup-env.yml 即可完成全流程配置，耗时约 15-20 分钟。
2.4 环境配置检查清单
配置完成后，逐项核对以下清单，确保环境就绪：
| 检查项 | 验证方法 | 预期结果 |
|---|---|---|
| K8s 节点状态 | kubectl get nodes |
所有节点 Ready |
| MySQL 连接 | mysql -h <host> -u root -p -e "SELECT 1;" |
返回 1 |
| Redis 集群 | redis-cli -c cluster info |
cluster_state:ok |
| ES 健康状态 | curl -X GET "localhost:9200/_cluster/health" |
status: green |
| MinIO 桶可读写 | mc ls source-policy/ |
列出策略文件 |
| 算法服务 Pod | kubectl get pods -n source-algo |
所有 Pod Running |
| 寻源链路测试 | 调用寻源 API 并检查日志 | 返回 Top-5 供应商列表 |