基础设施架构
**本文引用的文件** - [[bi-infra 说明文档]](../file/bi-intra/readme.md) - [[APISIX 服务配置]](../file/bi-intra/apisix/services.yaml) - [[APISIX Prometheus 全局规则]](../file/bi-intra/apisix/apisix-prometheus-global-rule.json) - [[Nacos Helm values]](../file/bi-intra/charts/nacos/values.yaml) - [[Grafana Helm values]](../file/bi-intra/charts/grafana/values.yaml) - [[APISIX Dashboard Helm values]](../file/bi-intra/charts/apisix-dashboard/values.yaml) - [[Kafka Helm values]](../file/bi-intra/charts/kafka/values.yaml) - [[Nacos 客户端实现]](../file/bi-common/registry/nacos/client.go) - [[Nacos 服务发现实现]](../file/bi-common/registry/nacos/discovery.go) - [[Nacos 配置结构]](../file/bi-common/registry/nacos/config.go) - [[部署脚本]](../file/scripts/deploy.sh)
目录
引言
本文件面向 BI 分析平台的基础设施架构，系统性阐述容器化部署、Kubernetes 集群配置、APISIX API 网关路由策略、Nacos 配置中心与注册发现、监控与日志体系、CI/CD 自动化部署流程，并提供高可用与容灾设计建议及资源管理与扩缩容策略。
项目结构
基础设施相关配置集中在 bi-infra 子模块，包含：
- APISIX 路由与安全策略配置
- Helm Charts：Nacos、APISIX Dashboard、Kafka、Grafana
- 监控与日志相关配置
- 通用组件：Nacos 客户端 SDK（Go）
图表来源
章节来源
核心组件
- APISIX API 网关：统一入口、路由转发、鉴权与安全防护
- Nacos：服务注册与配置中心
- Kafka：消息队列（KRaft 模式）
- Grafana：可视化与告警
- Helm Charts：标准化部署与运维
- Nacos 客户端 SDK：服务发现与配置获取
章节来源
- [APISIX 服务配置]
- [Nacos Helm values]
- [Kafka Helm values]
- [Grafana Helm values]
- [APISIX Dashboard Helm values]
- [Nacos 客户端实现]
- [Nacos 服务发现实现]
- [Nacos 配置结构]
架构总览
整体采用“网关 + 服务网格 + 中间件 + 监控”的分层架构。前端通过 APISIX 访问后端微服务；服务间通过 Nacos 注册发现；消息通过 Kafka 流转；监控通过 Prometheus 收集指标，Grafana 展示。
图表来源
详细组件分析
APISIX API 网关
- 统一入口与路由：通过 services.yaml 定义各服务的路由前缀、主机名、上游地址等
- 安全与防护：内置 IP 白名单、API Key、限流、WAF 规则
- JWT 认证：支持网关层 JWT 校验
- Prometheus 指标：全局启用 Prometheus 插件采集指标
- 外部代理：支持对特定外部服务进行反向代理
图表来源
章节来源
Nacos 配置中心与注册发现
- Helm 部署：集群模式，3 副本，MySQL(PolarDB-X) 存储
- 客户端 SDK：提供配置中心与服务发现能力，支持注册/注销、订阅、查询
- 默认配置：包含服务端、客户端、鉴权、高级参数等结构化配置
图表来源
章节来源
Kafka 消息队列（KRaft 模式）
- 版本与模式：Kafka 3.9.1，KRaft Combined（Broker + Controller）
- 副本与存储：3 副本，20Gi，阿里云磁盘
- 连接地址：集群内服务地址
章节来源
监控与日志体系
- Prometheus：采集各组件指标
- Grafana：仪表盘与告警
- Helm 配置：可启用 ServiceMonitor、HPA、持久化等
图表来源
章节来源
CI/CD 与自动化部署
- 脚本职责：拉取代码、构建前端/后端、打包 Docker 镜像、使用 docker-compose 启动
- 建议演进：将 docker-compose 迁移为 Helm/Kustomize + ArgoCD/Flux，实现声明式与 GitOps
图表来源
章节来源
依赖关系分析
- 服务依赖：各业务服务通过 Nacos 进行注册与发现
- 网关依赖：APISIX 作为统一入口，依赖 Nacos 获取服务实例
- 监控依赖：各组件暴露指标，Prometheus 抓取，Grafana 展示
图表来源
章节来源
性能考虑
- APISIX：合理设置连接/发送/读取超时与重试次数，避免上游抖动放大
- Nacos：集群模式与 MySQL 存储需评估 QPS 与延迟；开启鉴权与压缩提升安全性与吞吐
- Kafka：副本数与分区数平衡吞吐与恢复时间；磁盘 IOPS 与网络带宽满足峰值
- Grafana：启用 ServiceMonitor 与 HPA，限制资源请求与限制，避免资源争抢
[本节为通用指导，无需列出具体文件来源]
故障排查指南
- APISIX
- 检查路由前缀与 Host 是否匹配
- 核对 JWT 密钥与算法配置
- 查看限流与 WAF 拦截日志
- Nacos
- 确认服务实例健康状态与权重
- 检查订阅回调是否正常触发
- 验证配置中心 DataId/Group 一致性
- Kafka
- 关注分区 leader/follower 状态
- 检查磁盘容量与网络 I/O
- Grafana/Prometheus
- 确认 ServiceMonitor 与抓取间隔
- 校验数据源连通性与权限
章节来源
结论
该基础设施以 APISIX 为核心入口，结合 Nacos 实现服务治理，Kafka 提供异步解耦，Grafana/Prometheus 完成可观测性闭环。通过 Helm Charts 标准化部署，具备良好的可维护性与扩展性。建议进一步推进 GitOps 化与多集群高可用策略，强化容灾与弹性伸缩能力。
[本节为总结性内容，无需列出具体文件来源]
附录
高可用与容灾设计
- APISIX：多副本部署，结合 Ingress/SLB 提供外网入口
- Nacos：集群模式 + 外部 MySQL 存储，跨可用区部署
- Kafka：多副本与分区，跨 AZ 部署，开启 ISR 保障
- Grafana：启用持久化与备份，HPA 动态扩缩
章节来源
资源管理与扩缩容策略
- HPA：根据 CPU/内存或自定义指标自动扩缩
- 资源配额：为命名空间设置 Requests/Limits
- PodDisruptionBudget：保证关键服务的可用性
- Topology Spread：跨节点/AZ 均匀分布
章节来源