概要从URL到页面渲染当在浏览器中输入www.csdn.net 到看到csdn后台管理页面中间经过了哪些步骤或者说用户请求是如何流转的整体架构流程餐厅点餐类比——理解Web各组件用户在浏览器输入网址后请求经过的每一个环节。这是运维排查问题的 “全局地图”。浏览器输入用户在地址栏输入 www.csdn.netDNS解析域名 → IP地址找到服务器在哪TCP三次握手浏览器和服务器打招呼建立连接发送HTTP请求浏览器发送 GET /我要访问网站主页Nginx反向代理请求到达服务器Nginx把请求转发给Spring BootSpring Boot处理若依后端执行业务逻辑查用户列表查询Redis先查缓存看用户数据在不在查询MySQL缓存没有就去数据库查返回JSON后端把用户数据组装成JSON返回给浏览器浏览器渲染Vue前端解析数据展示用户列表分步解析第一步输入网址用户在浏览器里输入www.csdn.net浏览器做的第一件事把https://blog.csdn.net/ 这个URL拆成三部分协议 https:// —— 告诉浏览器 我要用HTTP协议和服务器说话域名 blog.csdn.net—— 告诉浏览器 我要找这台服务器路径 / —— 告诉浏览器 我要访问这个具体的页面端口是协议的 “门牌号”——HTTP默认走80HTTPS默认走443。用户通常不需要手动输入端口浏览器会根据协议自动补全。第二步DNS解析DNS就像电话本把域名翻译成IP地址。计算机通信用的是IP地址而不是域名。第三步TCP三次握手知道了服务器的IP地址后浏览器需要和服务器 打个招呼建立联系。这个建立联系的过程叫 TCP三次握手。第四步发送HTTP请求TCP连接建立后浏览器开始发送HTTP请求。这个请求报文由四部分组成① 请求行GET / HTTP/1.1 —— 我要用GET方法请求 / 这个路径用HTTP/1.1协议② 请求头Host: blog.csdn.net 告诉服务器我访问的是哪个域名③ 空行请求头和请求体之间的分隔符Cookie: 登录Token携带登录凭④ 请求体GET请求没有请求体。如果是POST请求这里会放JSON数据第五步Nginx反向代理请求到达Nginx后Nginx会判断请求的类型1.如果是静态资源请求.html 、.css 、.jsNginx直接返回文件不经过后端——速度极快。2.如果是/system/* 或 /api/* Nginx转发给Spring Boot由csdn后端处理业务逻辑。3.如果请求路径是 /system/user 则属于API请求会被Nginx转发给Spring Boot。生活类比你走进一家餐厅服务员问你 吃什么如果你说 我要一份 成品凉菜服务员直接从柜台拿给你Nginx直接返回静态资源如果你说我要一份 现炒热菜服务员把你的需求转给后厨去做Nginx把请求转发给Spring Boot。第六步Spring Boot处理Nginx把API请求转给Spring Bootcsdn开始处理业务逻辑。第七八步MySQL和RedisMySQL仓库 所有数据存在硬盘上速度慢但容量大。Redis缓存柜 热数据存在内存中速度极快。生活类比MySQL是整个餐厅的大仓库所有食材都放在里面。但去仓库取一趟要5分钟。Redis是灶台边的小柜子常用的油盐酱醋放在里面1秒钟就拿到了。策略常用数据先看柜子里有没有缓存命中没有再去仓库拿缓存未命中拿回来后顺手放一份在柜子里写入缓存。第九十步返回HTTP响应Spring Boot处理完业务逻辑后返回HTTP响应给浏览器。这个响应由三部分组成① 状态行200 OK —— 表示请求成功② 响应头Content-Type: application/json —— 告诉浏览器返回的是JSON数据③ 响应体用户列表JSON数据 —— 实际的数据内容浏览器收到JSON数据后Vue前端框架进行解析和渲染最终在页面上展示出用户列表表格。这就是从请求到响应的完整闭环。整个过程中状态码200表示一切正常。如果看到500、502、404等状态码说明链路中某个环节出了问题就是需要排查的地方。小结从用户在浏览器输入网址敲下回车的那一刻起一条贯穿前后端的请求链路就被触发了。这条链路大致经过十个核心环节浏览器先对URL进行解析识别出协议、域名和路径接着通过DNS服务器把域名翻译成服务器的IP地址然后经过TCP三次握手建立起浏览器与服务器之间的可靠连接连接建立后浏览器发送HTTP请求请求到达服务器端首先由Nginx反向代理接手静态资源直接由Nginx返回API动态请求则被转发给后端的Spring Boot应用Spring Boot接收到请求后执行业务逻辑先查询Redis缓存获取热数据如果缓存未命中再回源到MySQL数据库数据查询完成后后端将结果封装成JSON格式返回给浏览器浏览器拿到JSON数据后由Vue前端框架进行解析和渲染最终在页面上呈现出完整的用户列表。这条链路可以说是运维排查问题的全局地图。当用户反馈页面打不开或接口报错时我们可以根据现象倒推沿着这条链路逐个节点排查——DNS解析有问题就用 nslookup 验证Nginx转发异常就看 access.log 和 error.log后端业务报错就查Spring Boot应用日志响应慢就检查Redis缓存命中率和MySQL慢查询日志。再配合 tail、grep、cat 等命令的组合使用就能从海量日志中快速筛选出异常信息。这张地图掌握得越熟练排查问题时就越能做到精准定位、手到擒来。