外卖项目总结（1）
<h2 id="外卖项目总结">外卖项目总结</h2><h3 id="技术点">技术点</h3>
<p><img src="https://img2024.cnblogs.com/blog/3417030/202507/3417030-20250707223548392-303569240.png"></p>
<ol>
<li>
<p>Nginx<br>
1.1 Http服务器，部署静态资源，访问性能高。<br>
1.2 负载均衡：通过调度算法将客户端的访问流量分发到不同的应用服务器上面，避免单点故障。<br>
<img src="https://img2024.cnblogs.com/blog/3417030/202507/3417030-20250707223558607-179198187.png"><br>
1.3 反向代理与正向代理<br>
相同点：都位于客户端与服务器之间<br>
不同点：</p>
<table>
<thead>
<tr>
<th>正向代理</th>
<th>反向代理</th>
</tr>
</thead>
<tbody>
<tr>
<td>为客户端服务</td>
<td>为服务器端服务</td>
</tr>
<tr>
<td>应用在FQ、内网访问</td>
<td>应用在负载均衡、隐藏真实服务器IP</td>
</tr>
<tr>
<td>客户端配置代理</td>
<td>服务器端配置代理</td>
</tr>
<tr>
<td>客户端直到目标服务器</td>
<td>客户端只知道代理服务器</td>
</tr>
</tbody>
</table>
</li>
<li>
<p>Swagger——框架<br>
接口文档的在线生成，让API结构自动化地以可视化的形式展现出来。提供了接口文档的自动生成、交互式测试、接口定义规范<br>
SpringBoot中的使用：<br>
2.1 引入依赖<br>
2.2 添加配置类<br>
2.3 在对应位置使用注解<br>
常用注解：</p>
<pre><code>@Api(tags = "")//用在类上
@ApiModel//用在类上
@ApiModelProperty//用在属性上
@ApiOperation//方法上
</code></pre>
<p>面试一问：</p>
<ol>
<li>Swagger文档对生产环境是否安全？<br>
不建议在生产环境暴露Swagger，可能导致接口被恶意测试或攻击。通常配置为仅在开发或测试环境启用</li>
<li>使用过程中遇到过什么问题<br>
我在使用 Swagger 时遇到过接口过多导致加载速度变慢的问题，后来通过分组（groupName）、限定扫描包路径、升级 Springdoc 版本解决。此外，对于需要登录态的接口，配置了全局参数添加 Token 以便测试。</li>
<li>Swagger有哪些代替方案<br>
Apifox: 国内常用，集接口文档、调试、Mock、测试于一体<br>
Knife4J：Swagger的增强UI，中文社区常用</li>
</ol>
</li>
<li>
<p>JWT<br>
将原始的JSON数据进行安全封装，右Header（令牌类型、签名算法等）、载荷（携带信息）、签名（防伪）组成<br>
应用场景：身份验证、授权、信息交换<br>
使用流程：</p>
<ol>
<li>导入依赖</li>
<li>编写工具类</li>
<li>利用工具类下发/解析JWT实现功能<br>
认证流程：<br>
用户登录，服务端验证用户名密码正确后，生成 JWT（包含用户信息）并返回给客户端。<br>
客户端将 JWT 存储（通常在 localStorage 或 sessionStorage）。<br>
客户端每次请求 API 时，将 JWT 放在 HTTP Header（Authorization: Bearer <token>）。<br>
服务端通过验证 JWT 的签名，确定用户身份，无需再查询数据库。<br>
优点：</token></li>
<li>无状态：服务器端不需要存储Session信息，减少了服务器压力，适合分布式架构</li>
<li>跨语言支持：基于JSON，各语言均有库支持</li>
<li>安全性：通过签名可以防止篡改<br>
面试一问：</li>
<li>JWT与Session区别<br>
|Session|JWT|<br>
|----|----|<br>
|服务器端保存Session|服务端无状态，不保存token|<br>
|扩展到多服务器需要共享Session|JWT自包含，适合分布式架构|<br>
|相对安全，不易被窃取|易被窃取，需配合https|</li>
<li>JWT如何防止被篡改<br>
通过签名算法，验证载荷是否被修改</li>
<li>JWT可以存储敏感信息吗<br>
不建议。虽然签名能防篡改，但 Payload 是明文可解码（Base64Url 编码），除非对内容进行额外加密。</li>
<li>JWT如何实现过期<br>
使用 Payload 中的 exp 字段，服务端验证 Token 是否过期。</li>
<li>JWT如何实现登出<br>
由于 JWT 无状态，登出比较麻烦：可以维护黑名单（存储已登出 Token 的标识）；减短 Token 有效期 + 使用 Refresh Token 机制。</li>
<li>JWT有Refresh Token吗？<br>
通常结合使用：Access Token：短有效期（如 15min），用于访问资源；Refresh Token：长有效期，用于获取新的 Access Token</li>
</ol>
</li>
<li>
<p>Refresh Token<br>
背景：Access Token 一般设置较短的过期时间（如15min）以提升安全性。但如果Access Token过期，用户需要重新登录会导致体验很差。由此引入了Refresh Token（刷新令牌），用于在Access Token过期后，无需重新登录即可换取新的Access Token<br>
工作原理：</p>
<ol>
<li>用户登录成功<br>
服务端生成Access Token（短期有效），同时生成Refresh Token（长期有效）。将两者返回给客户端</li>
<li>客户端请求接口时<br>
使用 Access Token进行认证</li>
<li>当 Access Token过期<br>
客户端使用Refresh Token 请求服务端刷新获取新的Access Token</li>
<li>如果Refresh Token 也过期<br>
用户需要重新登录<br>
存储位置<br>
Access Token： LocalStorage / SessionStorage / Cookie<br>
Refresh Token： 通常存放在HttpOnly Cookie，避免被js读取，提高安全性<br>
面试一问：</li>
<li>为什么Access Token不设置长一点的有效期？<br>
安全性考虑：Token有效期越短，即使被窃取，也能尽快失效</li>
<li>Refresh Token可以撤销吗？<br>
可以，通常在服务端维护：Refresh Token列表或黑名单；用户登出时，立即将Refresh Token失效。</li>
</ol>
<p></p>
</li>
</ol><br><br>
来源：https://www.cnblogs.com/waterme123/p/18971801
頁:
[1]