具体要求

设计高可用电商系统：

环境介绍

本地虚拟机VM : Ubuntu22.04
内存：8 GB
CPU：4核
网络环境：使用美国代理

框架搭建思路

一、 宏观架构设计

将这台虚拟机视为一个“微型数据中心”。系统将分为三层：
基础设施层 (Infra)：模拟底层的网络和存储能力。
业务应用层 (App)：电商微服务，重点在于服务间的解耦。
治理与运维层 (Ops)：监控、日志与自动化发布。

二、 核心实施路径

整个项目拆解为 5 个里程碑，每个里程碑解决一个核心问题。

1. 基础设施基石 (解决“跑起来”的问题)

在业务上线前，必须先解决单机 K8s 的两大痛点：进不来（网络）和 存不住（存储）。
流量入口 (Ingress)：
使用 Ingress-Nginx。
思路：在本地 hosts 文件做域名欺骗（如 192.168.x.x order.shop.local），模拟公网域名访问。
持久化存储 (Storage)：
使用 Rancher Local Path Provisioner。
思路：虽然只有一块硬盘，但通过 StorageClass 动态创建 PV/PVC，让数据库认为自己挂载了独立的云盘。

2. 数据与中间件层 (解决“依赖”问题)

微服务是无状态的，但数据是有状态的。
数据库部署：
MySQL：用于存储订单、商品数据。必须挂载 PVC。
Redis：用于支付服务的缓存和防重。
配置管理 (ConfigMap/Secret)：
核心思想：配置与代码分离。不要把数据库密码写在代码里，而是通过 K8s 环境变量注入。

3. 微服务开发与高可用编排 (解决“稳不稳定”的问题)

这是项目的核心。需要开发三个简单的 Spring Boot 或 Go 应用，重点在于 K8s 的 YAML 编写。

服务定义：
Product-Service (商品)：提供查询接口。
Order-Service (订单)：调用商品服务扣库存，写入数据库。
Pay-Service (支付)：模拟支付延时和成功/失败。
伪高可用 (Pseudo-HA)：
由于是单机，真正的物理高可用做不到。
思路：设置 replicas: 3。配置 podAntiAffinity（反亲和性）。
健康检查：配置 livenessProbe（存活探针）和 readinessProbe（就绪探针），模拟服务“假死”后 K8s 自动重启它。

4. 可观测性体系 (解决“看不看得见”的问题)

这一步要让系统透明。
监控 (Prometheus)：
使用 Prometheus Operator。
思路：自动发现 Service，抓取 /metrics 接口数据。
展示 (Grafana)：
导入 K8s 集群监控大屏（看 Node 负载）。
关键点：自定义一个业务大屏，展示“每秒下单数”和“支付失败率”。

5. CI/CD 自动化闭环 (解决“快不快”的问题)

最后，把手动 kubectl apply 变成流水线。
工具选型：在 K8s 内部署轻量级 Jenkins 或使用 GitLab CI（如果资源允许）。
流水线逻辑：
Git Push -> Jenkins Webhook -> Build Docker Image -> Push to Local Registry -> Helm Upgrade / Kubectl Apply。
版本控制：使用 Git Commit ID 作为镜像 Tag，实现版本可追溯。

三、 流量流向全景图

用户 (浏览器) 请求 http://order.shop.local
DNS (本地 hosts) 解析到虚拟机 IP
K8s NodePort -> Ingress Controller
Ingress 规则 路由到 -> Order Service (ClusterIP)
Order Service 内部 DNS 调用 -> Product Service (查询库存)
Order Service 写入 -> MySQL (持久化存储)
Prometheus 定时拉取所有服务的指标 -> Grafana 展示