Architectures
APIM在DEV/STG/PRD环境中的部署
在此架构中，APIM平台部署在Kubernetes集群上，并通过命名空间和角色进行分段。该系统设计为在多个环境中独立运行，例如开发、暂存和生产。
入口层和外部/内部路由
在最上层，系统利用两个负载均衡器（LB）：
内部LB（管理员访问） - 提供访问：
- APIM控制台 (apim-admin.company.com)
- IAM控制台 (tenant-admin.company.com)
- 管理员开发者门户 (developers-admin.company.com)
- 认证控制台 (auth-admin.company.com)
面向互联网的LB（用户访问） - 提供外部访问：
- 开放API服务 (api.company.com)
- 公共开发者门户 (developers.company.com)
流量通过集中式入口控制器路由，在此进行TLS终止，并根据域路径将流量通过HTTP转发到内部服务。
节点组：管理
该组托管管理租户、项目、网关、API和策略所需的所有核心组件。
关键命名空间：
namespace: apim
核心组件：
| 组件 | 描述 |
|---|---|
| 租户管理器（IAM） | 处理系统用户和租户组织的身份和访问管理 |
| 租户管理控制台 | 租户管理员的UI前端（使用Vue.js构建） |
| API管理控制台BFF | 协调UI和服务交互的前端后端（Vue.js和Node.js） |
| 网关管理器 | 控制网关的配置和与项目的关联 |
| 策略管理器 | 管理入站/出站策略定义，如IP过滤、认证、日志记录 |
| 开发者门户（前端和后端） | API用户浏览和测试已发布API的接口 |
| 分析管理器 | 处理实时API使用分析和报告（与FluentBit连接） |
持久数据库：
- 租户管理数据库（PostgreSQL）
- APIM数据库主/从（MariaDB）
- PVC配置用于数据持久性和冗余。
节点组：用户节点组
该组执行运行时API流量并将用户API调用路由到后端微服务。
命名空间：
namespace: user-namespace
组件：
| 组件 | 描述 |
|---|---|
| API网关 | 基于Kong的网关，处理入站API请求 |
| API网关数据库 | PostgreSQL存储运行时网关配置和状态 |
| 内存数据库（主/从） | 用于令牌/会话存储（可能是Redis或类似） |
| 微服务 | 接收路由API流量的实际后端服务 |
API网关接收来自外部用户的请求并执行：
- 策略执行（认证、IP过滤等）
- 路由到适当的微服务
- 通过入口返回响应
节点组：监控
| 组件 | 描述 |
|---|---|
| 日志系统 | 由Elasticsearch提供支持，用于收集结构化API日志 |
| 监控系统 | 由Prometheus提供支持，收集系统健康和警报的指标 |
日志和监控组件与FluentBit和API网关日志集成，使得：
- 实时API流量洞察
- 自定义指标可视化
- 通过Slack/Email渠道警报
系统通信流程
- 管理员通过入口控制器访问系统的内部域。
- 用户通过外部域调用开放API和开发者门户，这些请求路由到Kong网关。
- Kong强制执行API策略（入站/出站）并路由到相应的微服务。
- 所有组件的日志和指标被流式传输到监控和日志堆栈。
与云和第三方服务的集成APIM部署
该架构展示了APIM系统如何与外部基础设施（如AWS）以及日志/监控服务（如CloudWatch、Datadog或Firehose）集成。
How It Works:- 外部用户通过公共域访问系统，该域通过AWS API网关通过VPC链接路由到内部APIM网关。
- 使用私有域和Route53将请求内部路由到APIM服务所在的Kubernetes集群。
- 一旦请求到达Kong网关，入站策略将被强制执行（认证、头部注入等），然后流量被路由到后端服务。
- 响应通过出站策略（例如，数据掩码、日志记录）传递，并返回给客户端。
- 所有请求/响应日志和指标通过集成的导出器转发到CloudWatch、Datadog或Firehose。
- 使用基于Swagger的规范注册动态暴露或更新API，通过开发者门户。
该架构支持跨组织边界的安全、可扩展和可观察的API管理。它确保API治理，同时允许无缝扩展到云原生服务。
开发环境的内部部署
此版本反映了APIM平台的内部专用设置，用于开发用途。它强调在API测试或服务开发期间的安全性和封闭访问。
How It Works:- 所有流量在内部流动，通过私有DNS和ALB进入集群。
- 内部开发人员通过预定义的内部子域访问APIM控制台、开发者门户和IAM。
- 来自开发前端应用程序的API流量发送到Kong网关，在此应用所有配置的策略。
- 后端微服务（托管在bo命名空间中）响应通过网关路由的请求。
- 整个堆栈按命名空间分隔，以便于维护和角色分离：
- apim包含配置和控制逻辑。
- microservices包含运行时服务和业务逻辑。
该架构允许安全的API开发和测试，而无需暴露于公共网络。它最适合在暂存或生产发布之前验证服务、应用策略和验证访问控制。
仅开发的内部流模型
该架构展示了开发环境中详细的内部流量流动，重点关注网络边界和隔离。
How It Works:- 内部应用程序和开发人员通过私有域和NLB/ALB路由与APIM控制台或开发者门户进行交互。
- 前端的请求被路由到Kong网关，在此强制执行运行时策略，如认证、速率限制和转换。
- 网关将请求路由到同一集群中托管的后端微服务或通过服务网格（如适用）。
- API使用情况、日志和流量统计被发送到内部可观察性工具，如Datadog，确保在开发操作期间的可见性。
- 在此环境中没有面向公众的访问点 - 所有组件，包括API网关，都是严格内部的。
该设置确保了一个安全、隔离的管道，用于开发和测试API，同时保留完整的监控和治理能力。它允许开发团队模拟类似生产的API行为，而无需外部暴露。
组件描述和资源
该表概述了分配给APIM控制平面中每个组件的CPU、内存和存储资源。它帮助基础设施和DevOps团队准确高效地规划和配置Kubernetes集群。
| Instance | Description | kind | Replicas | CPU (m) | CPU Total (m) | Memory (Mi) | Memory Total (Mi) | Storage (GB) | Storage Total (GB) |
|---|---|---|---|---|---|---|---|---|---|
| deploy-apim-analysis-manager | 分析管理器 | 部署 | 1 | 0.5 | 0.5 | 1024 | 1024 | 0 | 0 |
| deploy-apim-bff | APIM 控制台 BFF | 部署 | 1 | 0.5 | 0.5 | 512 | 512 | 0 | 0 |
| deploy-apim-gateway-manager | 网关管理器 | 部署 | 1 | 0.5 | 0.5 | 768 | 768 | 0 | 0 |
| deploy-apim-tenant-manager | 租户管理器 (IAM) | 部署 | 1 | 0.5 | 0.5 | 768 | 768 | 0 | 0 |
| deploy-apim-tenant-manager-console | 租户管理器控制台 | 部署 | 1 | 0.2 | 0.2 | 512 | 512 | 0 | 0 |
| deploy-apim-policy-manager | 策略管理器 | 部署 | 1 | 0.2 | 0.2 | 512 | 512 | 0 | 0 |
| deploy-apim-developer-portal-backend | 开发者门户后端 | 部署 | 1 | 0.2 | 0.2 | 512 | 512 | 20 | 20 |
| deploy-apim-developer-portal-frontend | 开发者门户前端 | 部署 | 1 | 0.2 | 0.2 | 64 | 64 | 0 | 0 |
| deploy-apim-mariadb-master | APIM 数据库 (MariaDB 主) | 有状态集 | 1 | 0.5 | 0.5 | 512 | 512 | 10 | 10 |
| deploy-apim-mariadb-slave | APIM 数据库 (MariaDB 从) | 有状态集 | 1 | 0.2 | 0.2 | 256 | 256 | 0 | 0 |
| statefulset-apim-tenant-manager-postgresql | IAM 数据库 (PostgreSQL) | 有状态集 | 1 | 0.5 | 0.5 | 256 | 256 | 10 | 10 |
| 总计 | 4 | 5760 | 40 |
- CPU: 4 核心
- 内存: 6 GiB
- 存储: 40 GB
Notes:
- CPU/内存根据副本扩展策略增加
- 日志/监控存储随流量规模变化
- 支持一个公共和一个私有的 APIM 部署