外卖项目总结（1）

外卖项目总结

技术点

• Nginx
  1.1 Http服务器，部署静态资源，访问性能高。
  1.2 负载均衡：通过调理算法将客户端的访问流量分发到差别的应用服务器上面，避免单点故障。
  
  
  
  1.3 反向代理与正向代理
  相同点：都位于客户端与服务器之间
  差别点：
  正向代理反向代理为客户端服务为服务器端服务应用在FQ、内网访问应用在负载均衡、隐藏真实服务器IP客户端设置代理服务器端设置代理客户端直到目标服务器客户端只知道代理服务器
  
• Swagger——框架
  接口文档的在线天生，让API结构主动化地以可视化的形式展现出来。提供了接口文档的主动天生、交互式测试、接口定义规范
  SpringBoot中的使用：
  2.1 引入依赖
  2.2 添加设置类
  2.3 在对应位置使用注解
  常用注解：
  1. @Api(tags = "")//用在类上
  2. @ApiModel//用在类上
  3. @ApiModelProperty//用在属性上
  4. @ApiOperation//方法上

  复制代码
  面试一问：
  
  
  
  • Swagger文档对生产环境是否安全？
    不建议在生产环境袒露Swagger，可能导致接口被恶意测试或攻击。通常设置为仅在开辟或测试环境启用
    
  • 使用过程中碰到过什么问题
    我在使用 Swagger 时碰到过接口过多导致加载速度变慢的问题，后来通过分组（groupName）、限定扫描包路径、升级 Springdoc 版本解决。此外，对于须要登录态的接口，设置了全局参数添加 Token 以便测试。
    
  • Swagger有哪些代替方案
    Apifox: 国内常用，集接口文档、调试、Mock、测试于一体
    Knife4J：Swagger的增强UI，中文社区常用
    
  
  
• JWT
  将原始的JSON数据进行安全封装，右Header（令牌类型、署名算法等）、载荷（携带信息）、署名（防伪）组成
  应用场景：身份验证、授权、信息交换
  使用流程：
  
  
  
  • 导入依赖
    
  • 编写工具类
    
  • 利用工具类下发/解析JWT实现功能
    认证流程：
    用户登录，服务端验证用户名密码正确后，天生 JWT（包含用户信息）并返回给客户端。
    客户端将 JWT 存储（通常在 localStorage 或 sessionStorage）。
    客户端每次请求 API 时，将 JWT 放在 HTTP Header（Authorization: Bearer ）。
    服务端通过验证 JWT 的署名，确定用户身份，无需再查询数据库。
    优点：
    
  • 无状态：服务器端不须要存储Session信息，减少了服务器压力，适合分布式架构
    
  • 跨语言支持：基于JSON，各语言均有库支持
    
  • 安全性：通过署名可以防止篡改
    面试一问：
    
  • JWT与Session区别
    |Session|JWT|
    |----|----|
    |服务器端生存Session|服务端无状态，不生存token|
    |扩展到多服务器须要共享Session|JWT自包含，适合分布式架构|
    |相对安全，不易被盗取|易被盗取，需共同https|
    
  • JWT怎样防止被篡改
    通过署名算法，验证载荷是否被修改
    
  • JWT可以存储敏感信息吗
    不建议。虽然署名能防篡改，但 Payload 是明文可解码（Base64Url 编码），除非对内容进行额外加密。
    
  • JWT怎样实现过期
    使用 Payload 中的 exp 字段，服务端验证 Token 是否过期。
    
  • JWT怎样实现登出
    由于 JWT 无状态，登出比力麻烦：可以维护黑名单（存储已登出 Token 的标识）；减短 Token 有用期 + 使用 Refresh Token 机制。
    
  • JWT有Refresh Token吗？
    通常联合使用：Access Token：短有用期（如 15min），用于访问资源；Refresh Token：长有用期，用于获取新的 Access Token
    
  
  
• Refresh Token
  背景：Access Token 一样平常设置较短的过期时间（如15min）以提升安全性。但如果Access Token过期，用户须要重新登录会导致体验很差。由此引入了Refresh Token（刷新令牌），用于在Access Token过期后，无需重新登录即可调换新的Access Token
  工作原理：
  
  
  
  • 用户登录成功
    服务端天生Access Token（短期有用），同时天生Refresh Token（长期有用）。将两者返回给客户端
    
  • 客户端请求接口时
    使用 Access Token进行认证
    
  • 当 Access Token过期
    客户端使用Refresh Token 请求服务端刷新获取新的Access Token
    
  • 如果Refresh Token 也过期
    用户须要重新登录
    存储位置
    Access Token： LocalStorage / SessionStorage / Cookie
    Refresh Token： 通常存放在HttpOnly Cookie，避免被js读取，进步安全性
    面试一问：
    
  • 为什么Access Token不设置长一点的有用期？
    安全性考虑：Token有用期越短，即使被盗取，也能尽快失效
    
  • Refresh Token可以打消吗？
    可以，通常在服务端维护：Refresh Token列表或黑名单；用户登出时，立即将Refresh Token失效。
    
  ​