外卖项目总结(1)


外卖项目总结

技术点

  1. Nginx
    1.1 Http服务器,部署静态资源,访问性能高。
    1.2 负载均衡:通过调度算法将客户端的访问流量分发到不同的应用服务器上面,避免单点故障。

    1.3 反向代理与正向代理
    相同点:都位于客户端与服务器之间
    不同点:

    正向代理 反向代理
    为客户端服务 为服务器端服务
    应用在FQ、内网访问 应用在负载均衡、隐藏真实服务器IP
    客户端配置代理 服务器端配置代理
    客户端直到目标服务器 客户端只知道代理服务器
  2. Swagger——框架
    接口文档的在线生成,让API结构自动化地以可视化的形式展现出来。提供了接口文档的自动生成、交互式测试、接口定义规范
    SpringBoot中的使用:
    2.1 引入依赖
    2.2 添加配置类
    2.3 在对应位置使用注解
    常用注解:

    @Api(tags = "")//用在类上
    @ApiModel//用在类上
    @ApiModelProperty//用在属性上
    @ApiOperation//方法上
    

    面试一问:

    1. Swagger文档对生产环境是否安全?
      不建议在生产环境暴露Swagger,可能导致接口被恶意测试或攻击。通常配置为仅在开发或测试环境启用
    2. 使用过程中遇到过什么问题
      我在使用 Swagger 时遇到过接口过多导致加载速度变慢的问题,后来通过分组(groupName)、限定扫描包路径、升级 Springdoc 版本解决。此外,对于需要登录态的接口,配置了全局参数添加 Token 以便测试。
    3. Swagger有哪些代替方案
      Apifox: 国内常用,集接口文档、调试、Mock、测试于一体
      Knife4J:Swagger的增强UI,中文社区常用
  3. JWT
    将原始的JSON数据进行安全封装,右Header(令牌类型、签名算法等)、载荷(携带信息)、签名(防伪)组成
    应用场景:身份验证、授权、信息交换
    使用流程:

    1. 导入依赖
    2. 编写工具类
    3. 利用工具类下发/解析JWT实现功能
      认证流程:
      用户登录,服务端验证用户名密码正确后,生成 JWT(包含用户信息)并返回给客户端。
      客户端将 JWT 存储(通常在 localStorage 或 sessionStorage)。
      客户端每次请求 API 时,将 JWT 放在 HTTP Header(Authorization: Bearer )。
      服务端通过验证 JWT 的签名,确定用户身份,无需再查询数据库。
      优点:
    4. 无状态:服务器端不需要存储Session信息,减少了服务器压力,适合分布式架构
    5. 跨语言支持:基于JSON,各语言均有库支持
    6. 安全性:通过签名可以防止篡改
      面试一问:
    7. JWT与Session区别
      |Session|JWT|
      |—-|—-|
      |服务器端保存Session|服务端无状态,不保存token|
      |扩展到多服务器需要共享Session|JWT自包含,适合分布式架构|
      |相对安全,不易被窃取|易被窃取,需配合https|
    8. JWT如何防止被篡改
      通过签名算法,验证载荷是否被修改
    9. JWT可以存储敏感信息吗
      不建议。虽然签名能防篡改,但 Payload 是明文可解码(Base64Url 编码),除非对内容进行额外加密。
    10. JWT如何实现过期
      使用 Payload 中的 exp 字段,服务端验证 Token 是否过期。
    11. JWT如何实现登出
      由于 JWT 无状态,登出比较麻烦:可以维护黑名单(存储已登出 Token 的标识);减短 Token 有效期 + 使用 Refresh Token 机制。
    12. JWT有Refresh Token吗?
      通常结合使用:Access Token:短有效期(如 15min),用于访问资源;Refresh Token:长有效期,用于获取新的 Access Token
  4. Refresh Token
    背景:Access Token 一般设置较短的过期时间(如15min)以提升安全性。但如果Access Token过期,用户需要重新登录会导致体验很差。由此引入了Refresh Token(刷新令牌),用于在Access Token过期后,无需重新登录即可换取新的Access Token
    工作原理:

    1. 用户登录成功
      服务端生成Access Token(短期有效),同时生成Refresh Token(长期有效)。将两者返回给客户端
    2. 客户端请求接口时
      使用 Access Token进行认证
    3. 当 Access Token过期
      客户端使用Refresh Token 请求服务端刷新获取新的Access Token
    4. 如果Refresh Token 也过期
      用户需要重新登录
      存储位置
      Access Token: LocalStorage / SessionStorage / Cookie
      Refresh Token: 通常存放在HttpOnly Cookie,避免被js读取,提高安全性
      面试一问:
    5. 为什么Access Token不设置长一点的有效期?
      安全性考虑:Token有效期越短,即使被窃取,也能尽快失效
    6. Refresh Token可以撤销吗?
      可以,通常在服务端维护:Refresh Token列表或黑名单;用户登出时,立即将Refresh Token失效。