joeldepuri/jimmy-ai-backend-platform

# Jimmy — 具备自主事件响应功能的 AI 驱动微服务后端平台       ## 🧠 技术栈亮点 | 层级 | 技术 | |---|---| | **后端与 API** | Python, Node.js, REST APIs, OpenAPI 3.0, Streamlit | | **AI Agent** | AWS Bedrock (Claude Haiku 4.5), boto3, LangChain, Agentic AI Workflows | | **数据库** | PostgreSQL (13 个表), SQL, 内存缓存 | | **微服务** | 6 个独立服务 (auth, gateway, orders, product, user, frontend) | | **云服务 (AWS)** | EKS, Lambda, EventBridge, SNS, S3, CloudWatch, ECR, Bedrock | | **CI/CD 与部署** | GitHub Actions (matrix CI), Docker, ArgoCD, Terraform, Helm, GitOps | | **可观测性** | Prometheus (15秒抓取), Grafana, Fluent Bit, CloudWatch | ## 📌 项目简介 Jimmy 是一个全栈后端平台，结合了： - 一个**精品电商微服务应用**，包含 6 个后端服务和 18 个 REST API 端点 - 一个由 AWS Bedrock 驱动的**自主 AI agent** (Jimmy)，负责监控基础设施并自动响应事件 - 一个基于 Python 并使用 Streamlit 构建的**运维仪表盘**，用于实现实时的系统可观测性 - 旨在将手动日志分析时间从大约 **20 分钟缩短至 1 分钟以内** ## 💡 为什么开发这个项目 大多数 DevOps 工具和 AI agent 演示都是孤立存在的——要么是缺乏运维智能的微服务应用，要么是没有真实操作对象的 AI agent。我想构建一个将两端连接起来的系统：一个能产生真实运维信号的后端应用，以及一个能对这些信号进行推理并采取自主行动的 AI agent。 最让我感兴趣的工程挑战是 **agentic loop（代理循环）** —— 设计这样一个系统：Jimmy 能够获取日志、查询指标、识别根本原因、从 S3 中提取正确的 runbook、执行修复（重启 pod、扩展 deployment）并报告结果，所有这些都无需人工干预。使用 OpenAPI 3.0 schema 构建 8 个 Lambda action group，将它们连接到 Bedrock 的 agent runtime，并通过 EventBridge 可靠地触发整个流程，这是一项真正的系统设计实践——而不是一个教程项目。 次要目标是证明我能够从零开始构建和部署一个生产级的微服务后端：auth、gateway、订单管理、产品目录、用户资料和前端——所有这些都独立容器化，部署到 EKS，并通过 GitOps 进行管理。 ## 🏗️ 架构 ### 后端应用层 ``` graph TD Client["Client / Browser"] GW["API Gateway Service\n(Node.js)"] Auth["Auth Service\nJWT / OAuth2"] Orders["Orders Service"] Products["Product Service"] Users["User Service"] DB["PostgreSQL\n13 tables"] FE["Frontend\n(React)"] Client --> FE Client --> GW GW --> Auth GW --> Orders GW --> Products GW --> Users Auth --> DB Orders --> DB Products --> DB Users --> DB ``` ### Jimmy AI Agent 层 ``` graph LR EB["EventBridge\nevery 5 min"] ID["incident_detector\nLambda"] BA["AWS Bedrock Agent\nJimmy - Claude Haiku 4.5"] AG["7 Action Groups\nvia OpenAPI 3.0"] S3["S3 Runbooks"] SNS["SNS Report"] EB --> ID ID --> BA BA --> AG AG -->|"fetch_logs\nfetch_metrics\nfetch_health"| BA BA --> S3 S3 -->|runbook fetched| BA AG -->|"restart_pod\nscale_deployment"| BA BA --> SNS ``` ## 🗂️ 仓库结构 ``` jimmy-ai-backend-platform/ ├── projects/ │ ├── boutique-microservices/ # Core backend application │ │ ├── backend/ │ │ │ └── services/ # 6 microservices (Node.js/TypeScript) │ │ │ ├── auth/ # JWT auth, register, login, logout │ │ │ ├── gateway/ # API routing │ │ │ ├── orders/ # Order processing │ │ │ ├── order-service/ # Order status management │ │ │ ├── product-service/ # Product catalog + categories │ │ │ └── user-service/ # Profile + addresses │ │ ├── frontend/ # React frontend │ │ ├── database/ # PostgreSQL schema (13 tables) │ │ ├── prometheus/ # Metrics scrape config (15s interval) │ │ └── grafana/ # Dashboard ConfigMaps │ ├── aiops-assistant/ # Jimmy AI agent │ │ ├── app.py # Streamlit operations dashboard │ │ ├── lambda/ # 8 Lambda implementations (Python 3.12) │ │ │ ├── fetch_logs/ │ │ │ ├── fetch_metrics/ │ │ │ ├── fetch_health/ │ │ │ ├── fetch_runbook/ │ │ │ ├── restart_pod/ │ │ │ ├── scale_deployment/ │ │ │ ├── send_incident_report/ │ │ │ └── incident_detector/ │ │ ├── schemas/ # OpenAPI 3.0 action group schemas │ │ ├── runbooks/ # S3 runbook templates │ │ ├── setup-iam.sh # IAM roles setup (run first) │ │ └── deploy.sh # Full agent deployment script │ └── Infrastructure/ # Terraform IaC │ └── modules/ │ ├── eks/ # EKS cluster (1-2 nodes, m7i-flex.large) │ ├── ecr/ # 7 ECR repositories │ ├── vpc/ # VPC, 3 subnets across AZs │ └── argocd/ # GitOps setup ├── gitops/ │ └── k8s/ # Kubernetes manifests (ArgoCD managed) │ ├── backend/ # Deployment YAMLs for all services │ ├── database/ # PostgreSQL StatefulSet │ └── frontend/ # Frontend deployment └── .github/ └── workflows/ └── ci.yml # Matrix CI (7 images parallel) ``` ## 🚀 快速开始 ### 前置条件 ``` # 所需工具 aws --version # AWS CLI (credentials configured) kubectl version # Kubernetes CLI terraform --version # >= 1.0 helm version # Kubernetes package manager argocd version # GitOps CLI gh --version # GitHub CLI docker --version # Container builds python3 --version # >= 3.12 (for Jimmy agent) ``` ### 1. 克隆仓库 ``` git clone https://github.com/joeldepuri/jimmy-ai-backend-platform.git cd jimmy-ai-backend-platform ``` ### 2. 配置 AWS 基础设施 ``` cd projects/Infrastructure # 初始化并应用 Terraform # 这将创建：VPC (10.1.0.0/16, 3 subnets), EKS cluster, # 7 ECR repositories, node group (m7i-flex.large, 1-2 nodes) terraform init terraform plan terraform apply ``` ### 3. 为 EKS 配置 kubectl ``` aws eks update-kubeconfig \ --region us-east-1 \ --name eks-cluster kubectl get nodes # should show 1-2 ready nodes ``` ### 4. 为 Jimmy 设置 IAM ``` cd projects/aiops-assistant # 创建：aiops-lambda-role, aiops-bedrock-agent-role chmod +x setup-iam.sh ./setup-iam.sh ``` ### 5. 部署 Jimmy (AI Agent + 全部 8 个 Lambda) ``` # 部署全部 8 个 Lambda functions，创建 Bedrock Agent， # 设置 7 个 action groups，配置 EventBridge (每 5 分钟)， # 将 runbooks 上传至 S3，配置 SNS chmod +x deploy.sh ./deploy.sh ``` ### 6. 安装 ArgoCD 并部署应用 ``` # 安装 ArgoCD kubectl create namespace argocd kubectl apply -n argocd \ -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml # 应用 GitOps manifests — ArgoCD 从这里接管 kubectl apply -f gitops/argo-cd.yml kubectl apply -f gitops/kustomization.yml ``` ### 7. 运行 Streamlit 仪表盘 ``` cd projects/aiops-assistant pip install -r requirements.txt # streamlit, boto3, python-dotenv streamlit run app.py # 访问 http://localhost:8501 ``` ## ⚙️ CI/CD 流水线 **GitHub Actions Matrix CI** (`.github/workflows/ci.yml`)： - 并行构建 **7 个 Docker 镜像** —— auth, gateway, orders, order-service, product-service, user-service, frontend - 为每个镜像标记 commit SHA，以实现完整的部署可追溯性 - 推送至 **AWS ECR**（7 个存储库） - 通过 matrix 策略比顺序构建**快 66%** **通过 ArgoCD 进行 GitOps 部署：** - 监控 `gitops/k8s/` 目录 - 任何推送到 main 分支的操作都会触发与 EKS 集群的自动同步 - 闭环管理 —— 集群状态始终与 Git 状态保持一致 ## 🔍 可观测性技术栈 | 工具 | 用途 | 配置 | |---|---|---| | Prometheus | 指标收集 | 15 秒抓取间隔 | | Grafana | 仪表盘 | 通过 ConfigMap 部署 | | Fluent Bit | 日志聚合 | DaemonSet → CloudWatch | | CloudWatch | 日志存储 + 告警 | AWS 原生 | ## 🧠 经验总结 **Agentic AI 系统设计比看起来要难。** 通过 OpenAPI 3.0 schema 将 AWS Bedrock 的 agent runtime 连接到真实的 Lambda action group 需要非常精确的 schema 定义——Bedrock 期望的内容与 Lambda 返回的内容之间的任何不匹配都会导致静默失败。调试这个过程让我懂得了必须慎重对待 API 契约，将其视为首要关注点，而不是事后补充。 **GitOps 是一种真正不同的心智模型。** 我一开始以为 ArgoCD “只是另一种部署工具”。当我意识到 Git 仓库才是事实的来源——而不是集群——并且集群是向 Git 靠拢而不是相反时，这改变了我对分布式系统中状态管理的看法。 **可观测性必须是设计出来的，而不是后期硬加上去的。** 我在初始部署之后才添加了 Prometheus 和 Grafana，因此不得不重构服务暴露指标的方式。如果从一开始就这样做，事情会容易得多。这现在成了我在构建每个新的后端服务时都会应用的一条经验。 **Terraform 模块设计在规模化时至关重要。** 将基础设施拆分为多个模块（eks、ecr、vpc、argocd）使代码库变得易于维护。如果使用扁平的 Terraform 文件，要在跨越 3 个可用区和 7 个 ECR 存储库的情况下进行管理将是无法承受的。 ## 🔗 相关链接 - **YOLOv5 ML Project**: [github.com/joeldepuri/yolov5-ml-web-platform](https://github.com/joeldepuri/yolov5-ml-web-platform) - **作者**: Jedeediah Joel Depuri - **LinkedIn**: [linkedin.com/in/joeldepuri](https://linkedin.com/in/joeldepuri) - **GitHub**: [github.com/joeldepuri](https://github.com/joeldepuri)

标签：API集成, Kubernetes, MITM代理, 人工智能运维, 可观测性, 大语言模型代理, 子域名突变, 微服务架构, 测试用例, 漏洞探索, 电商系统, 自动化攻击, 自定义请求头, 请求拦截, 逆向工具