前后端 + Nginx + Gateway + K8s 全链路架构图解

一、先看全景架构图先上图你先有整体感。1用户访问系统的全链路图┌──────────────────────────────┐ │ 用户浏览器 │ │ 访问: https://portal.xxx.com │ └──────────────┬───────────────┘ │ │ 1. 通过域名访问 ▼ ┌──────────────────────────────┐ │ DNS / 本地 hosts │ │ portal.xxx.com - 入口IP │ └──────────────┬───────────────┘ │ │ 2. 解析到入口IP ▼ ┌──────────────────────────────┐ │ Nginx / Ingress入口层 │ │ 根据域名/路径决定转给谁 │ └───────┬────────────────┬─────┘ │ │ 3a. / 页面资源 │ 3b. /api 接口请求 │ │ ▼ ▼ ┌──────────────────┐ ┌────────────────────┐ │ Front 服务 │ │ Gateway 服务 │ │ (静态文件服务) │ │ (API统一入口) │ └────────┬─────────┘ └─────────┬──────────┘ │ │ │ 返回 index.html/js │ 4. 按接口路由转发 ▼ ▼ ┌──────────────────┐ ┌────────────────────┐ │ 浏览器渲染页面 │ │ Backend 服务群 │ │ 执行前端JS代码 │ │ user/order/auth... │ └────────┬─────────┘ └─────────┬──────────┘ │ │ │ 5. 前端继续调接口 │ 6. 查库/执行业务 │ ▼ │ ┌────────────────────┐ │ │ 数据库/缓存 │ │ │ MySQL/Redis/ES等 │ │ └────────────────────┘ │ ▼ ┌──────────────────┐ │ 页面显示真实数据 │ └──────────────────┘2如果放到 Kubernetes 里关系图是这样的集群外部 ──────────────────────────────────────────────────────── 浏览器 | | https://portal.xxx.com v [外部LB / 公网IP / 内网IP] | v [Ingress Controller(Nginx)] ──────────────────────────────────────────────────────── Kubernetes 集群内部 ──────────────────────────────────────────────────────── ┌─────────────────────────────┐ │ Ingress规则 │ │ host: portal.xxx.com │ │ / - front-service │ │ /api/* - gateway-service │ └────────────┬────────────────┘ │ ┌──────────────┴──────────────┐ │ │ v v ┌──────────────────┐ ┌──────────────────┐ │ front-service │ │ gateway-service │ │ ClusterIP服务 │ │ ClusterIP服务 │ └─────────┬────────┘ └─────────┬────────┘ │ │ v v ┌──────────────────┐ ┌──────────────────┐ │ front Pod 1 │ │ gateway Pod 1 │ │ nginx静态文件 │ └──────────────────┘ ├──────────────────┤ ┌──────────────────┐ │ front Pod 2 │ │ gateway Pod 2 │ │ nginx静态文件 │ └─────────┬────────┘ └──────────────────┘ │ │ 路由到内部服务 v ┌─────────────────────────────┐ │ backend service群 │ ├─────────────────────────────┤ │ user-service - user Pod │ │ order-service - order Pod │ │ auth-service - auth Pod │ └─────────────────────────────┘二、先把每个角色讲明白1. 前端 Front 是什么前端是你用户能看到和点击的页面例如登录页首页菜单栏表格按钮图表你开发时可能写的是VueReactHTML/CSS/JS但部署后一般会被打包成index.htmlmain.jsapp.css图片资源所以你可以先记住一句大多数前端项目部署后本质上就是静态文件。2. 后端 Backend 是什么后端负责真正的业务逻辑用户登录查询订单保存表单权限校验访问数据库比如你在页面点“查询用户”前端不是自己知道用户数据而是调用后端接口GET /api/user/list后端返回 JSON 数据前端再渲染出来。3. Gateway 是什么Gateway 是“后端统一入口”。它的作用就像一个总服务台前端所有接口都先打到这里它再决定转给哪个后端服务还可以统一做 token 校验、限流、日志、灰度等比如它会判断/api/user/**- user-service/api/order/**- order-service/api/auth/**- auth-service所以前端一般不直接调user-service、order-service而是统一调gateway。4. Nginx 是什么Nginx 非常常见它通常扮演以下几个角色角色 A静态文件服务器把前端打包好的 HTML/JS/CSS 返回给浏览器。角色 B反向代理把请求转发给后端。角色 C负载均衡后面有多个实例时Nginx 可以轮流转发。角色 DK8s 的入口控制器在 K8s 里常常由 Nginx Ingress Controller 负责把外部请求引入集群内部。5. KubernetesK8s是什么K8s 不是业务代码它是“容器编排平台”。它帮你管理这些服务怎么运行front 怎么部署gateway 怎么部署backend 怎么部署挂了怎么自动重启流量怎么负载均衡怎么滚动发布怎么扩容可以理解为K8s 是整个系统的“基础设施管理者”。三、一个请求是怎么一步一步走通的这个最关键我给你拆成两个阶段阶段 A先把页面打开用户在浏览器输入https://portal.xxx.com第 1 步浏览器先解析域名浏览器并不认识portal.xxx.com它只认识 IP。所以要先查portal.xxx.com对应哪个 IP这个过程可能来自公司 DNS公网 DNS你本机的 hosts 文件比如解析结果portal.xxx.com - 10.10.10.20第 2 步请求打到入口层浏览器向10.10.10.20发请求。这个 IP 通常不是某个具体业务 Pod 的 IP而是负载均衡器 IPIngress 暴露的 IPNginx 所在机器 IP请求先到Nginx / Ingress它是系统的统一入口。第 3 步Ingress/Nginx 根据规则分流比如它有这样的规则portal.xxx.com的/路径 -front-serviceportal.xxx.com的/api/路径 -gateway-service此时你访问的是/所以被转给 front。第 4 步Front 返回前端静态资源front 服务里通常放着index.htmlapp.jsstyle.cssNginx 把这些文件返回给浏览器。浏览器下载这些资源后就把页面渲染出来了。这时候你看到的页面其实只是“页面壳子”很多真实数据还没加载。阶段 B页面加载后再去请求数据比如你打开用户管理页面前端 JS 代码会继续发请求GET /api/user/list第 5 步接口请求再次来到 Ingress/Nginx请求路径现在是/api/user/listIngress/Nginx 一看是/api/开头就知道这是接口请求不是静态页面请求。于是把它转给gateway-service第 6 步Gateway 判断该转给哪个后端Gateway 根据路由规则判断/api/user/** - user-service所以这个请求会被转发给user-service第 7 步Backend 处理业务user-service收到请求后验证参数查数据库组装返回结果比如查 MySQL 后返回[ {id:1,name:张三}, {id:2,name:李四} ]第 8 步数据沿路返回到浏览器返回链路是user-service - gateway - ingress/nginx - 浏览器浏览器拿到 JSON 后前端 JS 把它渲染成表格。于是你就看到页面上出现了真实的数据。四、完整请求链路图我给你画一个更完整的图。【用户访问页面】 浏览器 | | 1. 输入 https://portal.xxx.com v DNS / hosts | | 2. portal.xxx.com - 10.10.10.20 v Ingress / Nginx | | 3. 判断 path / v front-service | | 4. 转发到某个 front Pod v front Pod (nginx index.html/js/css) | | 5. 返回静态资源 v 浏览器 | | 6. 浏览器执行前端JS | 7. 请求 /api/user/list v Ingress / Nginx | | 8. 判断 path /api/* v gateway-service | | 9. 转发到某个 gateway Pod v gateway Pod | | 10. 路由 /api/user/* - user-service v user-service | | 11. 转发到某个 user Pod v user Pod | | 12. 查询 MySQL / Redis v 数据库 | | 13. 返回结果 v user Pod - gateway Pod - Ingress/Nginx - 浏览器 | | 14. 前端渲染数据 v 页面展示最终内容五、为什么前端看上去“能调接口”本质上是因为前端 JS 代码里写了接口地址。例如axios.get(/api/user/list)这里的/api/user/list表示还是请求当前域名但路径走/api如果当前页面是https://portal.xxx.com那么浏览器最终发出去的其实是https://portal.xxx.com/api/user/list这样做的好处是跟页面同域名不容易跨域由 Nginx/Ingress 统一分流这就是很多项目喜欢这样配的原因/走 front/api走 gateway六、为什么本地开发经常要配 hosts这个点特别重要。1hosts 是什么你电脑上的一个文件用来“手工指定域名 - IP 的映射关系”。比如你写10.10.10.20 portal.xxx.com意思是以后你电脑访问portal.xxx.com时不要去问 DNS 了直接认为它就是10.10.10.202为什么要配通常有几个原因原因 1测试域名没有正式 DNS很多测试环境并没有在公司 DNS 或公网 DNS 中配置好。所以你只能自己本地写。原因 2需要访问指定环境比如开发环境入口 IP10.10.10.20测试环境入口 IP10.10.10.30你可以通过改 hosts让同一个域名指向不同环境。原因 3很多功能必须依赖域名例如Cookie 是按域名生效的HTTPS 证书绑定域名登录回调地址需要固定域名Nginx / Ingress 会根据 Host 做路由如果你直接访问 IPhttp://10.10.10.20很多时候会有问题因为系统不是按 IP 配的而是按域名配的。3为什么不能随便用 IP比如 Ingress 规则可能是host: portal.xxx.com只有你请求头里的 Host 是portal.xxx.com它才知道该把请求转给 front-service。如果你直接访问 IPhttp://10.10.10.20Host 就不是portal.xxx.comIngress 很可能匹配不到规则。所以hosts 的作用是让你本地电脑“假装认识这个域名”并把它指向指定 IP。七、K8s 里面这些对象到底是什么这是你以后看部署配置一定会遇到的。1Pod真正跑容器的地方Pod 是 K8s 里最小的运行单元。比如front Podgateway Poduser Pod你可以把 Pod 理解成一个“小运行实例”。但 Pod 的 IP 不稳定重建后可能变所以一般不会直接让别人访问 Pod IP。2Deployment管理一组 PodDeployment 用来管理 Pod 的数量和升级。例如front 部署 2 个副本gateway 部署 2 个副本user-service 部署 3 个副本好处某个 Pod 挂了自动补发版时可以滚动更新可以随时扩容缩容例如front Deployment ├─ front Pod 1 └─ front Pod 2 gateway Deployment ├─ gateway Pod 1 └─ gateway Pod 23Service给 Pod 提供一个稳定访问入口因为 Pod IP 会变所以 K8s 提供 Service。Service 像一个稳定的门牌号front-servicegateway-serviceuser-service别人不需要关心 Pod 有几个也不需要记 Pod IP只要访问 Service 名字即可。例如在集群内部http://gateway-service http://user-serviceK8s 会自动帮你把流量转发到后面的 Pod。4Ingress把外部流量引进来Ingress 负责定义哪个域名哪个路径转发到哪个 Servicehost: portal.xxx.com paths: / - front-service:80 /api - gateway-service:8080它是 K8s 的“外部入口路由规则”。八、用 yaml 思维理解部署关系我不写太复杂只写小白能看懂的版本。1front Deployment意思是部署前端服务的 Pod。apiVersion: apps/v1 kind: Deployment metadata: name: front spec: replicas: 2 template: spec: containers: - name: front image: nginx-front:1.0你可以这样理解创建一个叫front的部署跑 2 个实例容器镜像是nginx-front:1.0里面放的是前端静态文件2front ServiceapiVersion: v1 kind: Service metadata: name: front-service spec: selector: app: front ports: - port: 80 targetPort: 80意思是创建一个服务名叫front-service它后面关联的是 front Pod别人访问front-service:80就能访问 front Pod3gateway ServiceapiVersion: v1 kind: Service metadata: name: gateway-service spec: selector: app: gateway ports: - port: 8080 targetPort: 8080意思是创建一个gateway-service它指向 gateway Pod集群内部访问它就能访问网关4Ingress 路由规则apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: portal-ingress spec: rules: - host: portal.xxx.com http: paths: - path: / pathType: Prefix backend: service: name: front-service port: number: 80 - path: /api pathType: Prefix backend: service: name: gateway-service port: number: 8080你把它翻译成人话就是如果访问域名portal.xxx.com路径是/去 front-service路径是/api去 gateway-service这就是前后端走通的关键连接点。九、Gateway 怎么找到具体 backend在 gateway 里也会有自己的路由配置。比如routes: - id: user uri: http://user-service:8080 predicates: - Path/api/user/** - id: order uri: http://order-service:8080 predicates: - Path/api/order/**翻译成人话/api/user/**的请求转发到user-service/api/order/**的请求转发到order-service所以 gateway 访问 backend 时不是靠公网域名而是靠K8s Service 名称。十、为什么说 K8s 内部靠 Service 互相调用因为 Pod 不稳定而 Service 稳定。例子假设 user-service 后面有 3 个 Poduser Pod Auser Pod Buser Pod CGateway 只需要访问http://user-service:8080K8s 会自动选择某一个 Pod 来处理gateway - user-service - user Pod A gateway - user-service - user Pod B gateway - user-service - user Pod C这就是服务发现和负载均衡。十一、Nginx、Ingress、Gateway 容易混怎么区分这个你一定要记住。1Ingress这是 K8s 的“资源对象”用来写路由规则。你可以理解成“规则配置”。比如什么域名进来什么路径转哪个 service2Ingress Controller常见是 Nginx这是“真正执行 Ingress 规则的程序”。你可以理解成Ingress 是配置文件Nginx Ingress Controller 是执行这些配置的代理程序3业务 Nginx有时 front 本身也会是一个 Nginx 容器用来托管前端静态文件。所以你在项目里经常会看到两个“nginx”的感觉一个是入口 Nginx负责接收外部请求按域名/路径分发。一个是 front 容器里的 Nginx负责返回前端静态资源。这两个角色可能是同一种软件但职责不同。4Gateway这是业务 API 层面的总入口不只是做简单转发还会做token 鉴权统一异常灰度限流监控埋点所以它比普通 Nginx 更“懂业务接口”。十二、你可以这样理解整套系统分层第1层用户访问层 浏览器 / App 第2层域名解析层 DNS / hosts 第3层集群入口层 LB / Ingress / Nginx 第4层页面和API入口层 Front / Gateway 第5层业务服务层 User Service / Order Service / Auth Service 第6层数据层 MySQL / Redis / MQ / ES十三、最常见的两种部署方式方式 A同域名按路径转发https://portal.xxx.com - 前端页面 https://portal.xxx.com/api/* - 后端接口优点不容易跨域配置简单用户只感知一个域名路由方式/- front/api/- gateway这是很多后台管理系统最喜欢的方式。方式 B前后端不同域名https://portal.xxx.com https://api.xxx.com优点接口边界更清晰前后端彻底分离更适合大系统缺点可能有跨域问题需要配置 CORS十四、为什么前端访问后端有时会报跨域浏览器有“同源策略”。同源要求这三项都相同协议相同域名相同端口相同比如页面来自https://portal.xxx.com它去请求https://api.xxx.com域名不同所以跨域。这时后端要正确配置跨域响应头否则浏览器会拦截。所以很多项目喜欢用https://portal.xxx.com/api/*这样前端和接口同源不容易出跨域问题。十五、给你一个“最真实的项目视角”假设你们项目中有这些组件frontgatewayuser-backendorder-backendnginx ingressmysqlredis那你可以这样理解用户访问首页时浏览器 - 域名 - Ingress/Nginx - front - 返回静态页面页面查用户信息时浏览器 - /api/user/info - Ingress/Nginx - gateway - user-backend - mysql页面查订单列表时浏览器 - /api/order/list - Ingress/Nginx - gateway - order-backend - mysql登录校验时浏览器 - /api/auth/login - Ingress/Nginx - gateway - auth-backendgateway 和 backend 的通信方式gateway - user-service gateway - order-service gateway - auth-service都是通过K8s Service 名称。十六、你以后怎么排查“访问不通”这个特别实用我给你一个排查顺序。如果页面打不开按这条链路查1. 域名能不能解析ping portal.xxx.com nslookup portal.xxx.com2. 本地 hosts 有没有配错检查域名写对没IP 对不对3. Ingress / Nginx 是否正常入口 IP 是否正确Ingress 是否有规则Nginx 是否启动正常4. front-service 是否存在kubectl get svc5. front Pod 是否正常kubectl get pods kubectl logs xxx6. 前端静态文件是否真的打进镜像了有时 Nginx 正常但index.html不存在也会 404。如果页面打开了但接口报错按这条链路查1. 浏览器请求的接口地址对不对打开 F12 - Network看实际请求的是哪个 URL。2./api有没有被转发到 gateway看 Ingress 规则。3. gateway 是否正常Pod 是否 Running日志里有没有报错4. gateway 路由是否正确例如/api/user/**是否配到了user-service5. backend service 是否存在kubectl get svc6. backend pod 是否正常kubectl get pods kubectl logs7. 数据库是否可连接很多接口报 500本质是数据库连接失败。十七、最适合小白记住的一张脑图你把下面这段记住很多问题就能自己想通1. 浏览器访问的是“域名”不是 Pod 2. 域名要先解析成 IPDNS 或 hosts 3. 请求先到 Ingress/Nginx 入口 4. 入口按路径把 / 给 front把 /api 给 gateway 5. front 返回静态页面 6. 页面里的 JS 再去调用接口 7. gateway 再把接口转给各个 backend 8. backend 查库后返回数据 9. K8s 用 Deployment 管理 Pod用 Service 提供稳定访问用 Ingress 接外部流量十八、最后给你一个“人话版总结”你可以把整套系统想成一个商场域名商场名字DNS/hosts导航地图告诉你商场在哪Ingress/Nginx商场大门和导购台Front展示大厅给你看页面Gateway总服务台专门接收办事请求Backend后面的各业务办公室MySQL/Redis档案室和缓存柜K8s整个商场运营管理系统流程就是你先找到商场地址域名解析进商场大门Ingress/Nginx先看到展示大厅Front真要办业务时去总服务台Gateway总服务台带你去不同办公室Backend办公室查档案室数据库办完再把结果告诉你