跳到主要内容

技术场景

一、黑马​

1. 单点登录是怎么实现的？​

单点登录（SSO） 是一种认证机制，指的是用户只需要登录一次，就可以访问多个相互关联但独立的系统或应用，而不需要每次访问新系统时都重新登录。

通俗讲：登录一次，处处通行。

应用场景例子：

  • 登录一次企业官网后台系统，就可以无感跳转到CRM、OA、财务系统等。

JWT实现：

  1. 用户访问其他系统，会在网关判断token是否有效
  2. 如果token无效会返回401，前端跳转到登录页面
  3. 用户发送登录请求，返回浏览器一个token，浏览器把token保存到cookie
  4. 再去访问其他服务的时候，都需要携带token，由网关统一验证后路由到目标服务

2. 权限认证是如何实现的？​

  • 后端管理系统的开发经验
  • 介绍RBAC权限模型5张表的关系：基于角色的访问控制
    • 3个基础部分组成：用户、角色、权限
    • 5张表：用户表、角色表、权限表、用户角色中间表、角色权限中间表
  • 权限框架：SpringSecurity

3. 上传数据的安全性如何控制？​

使用非对称加密，给前端一个公钥让他把数据加密后传到后台，后台负责解密后处理数据。

  • 文件很大建议使用对称加密，不过不能保存敏感信息
  • 文件较小，要求安全性高，建议采用非对称加密

4. 你负责项目的时候遇到了哪些比较棘手的问题，如何解决的？​

  • 设计模式
  • 线上BUG
  • 调优
  • 组件封装：AOP日志

5. 你们项目中日志是怎么采集的？​

我们搭建了ELK日志采集系统。

  • ElasticSearch是全文搜索分析引擎，可以对数据存储、搜索、分析
  • Logstash是一个数据收集引擎，可以动态收集数据，可以对数据进行过滤、分析，将数据存储到指定的位置
  • Kibana是一个数据分析和可视化平台，配合ElasticSearch对数据进行搜索，分析，图表化展示

6. 查看日志的命令​

目前采集日志的方式：按天保存到一个日志文件

Linux中查看日志：

  • 实时监控日志的变化
    • tail -f xx.log
  • 按照行号查询
    • 尾部：tail -n 100 xx.log
    • 头部：head -n 100 xx.log
  • 按照关键字找日志的信息
    • 查询日志文件中包含debug标志的行号：cat -n xx.log | grep “debug”
  • 按照日期查询
    • sed -n ‘/2023-01-01 12:12:12.090/，/2023-01-01 12:12:12.091/p’ xx.log
  • 日志太多的处理方式
    • 分页
    • 过滤

7. 生产问题怎么排查​

  • 分析日志
  • 远程DEBUG

8. 怎么快速定位系统瓶颈​

  • 压测（性能测试），项目上线之前测评系统的压力
  • 监控工具、链路追踪工具，项目上线之后监控
  • 线上诊断工具，项目上线之后监控、排查

二、登录​

1. 认证 (Authentication) 和授权 (Authorization)的区别是什么？​

说简单点就是：

  • 认证 (Authentication)： 你是谁。
  • 授权 (Authorization)： 你有权限干什么。

稍微正式点的说法就是：

  • Authentication（认证） 是验证您的身份的凭据（例如用户名/用户 ID 和密码），通过这个凭据，系统得以知道你就是你，也就是说系统存在你这个用户。所以，Authentication 被称为身份/用户验证。
  • Authorization（授权） 发生在 Authentication（认证） 之后。授权嘛，光看意思大家应该就明白，它主要掌管我们访问系统的权限。比如有些特定资源只能具有特定权限的人才能访问比如 admin，有些对系统资源操作比如删除、添加、更新只能特定人才具有。

2. RBAC模型了解吗？​

RBAC 即基于角色的权限访问控制（Role-Based Access Control）。这是一种通过角色关联权限，角色同时又关联用户的授权的方式。简单地说：一个用户可以拥有若干角色，每一个角色又可以被分配若干权限，这样就构造成“用户-角色-权限” 的授权模型。

在这种模型中，用户与角色、角色与权限之间构成了多对多的关系。

在 RBAC 权限模型中，权限与角色相关联，用户通过成为包含特定角色的成员而得到这些角色的权限，这就极大地简化了权限的管理。为了实现 RBAC 权限模型，数据库表的常见设计如下（一共 5 张表，2 张用户建立表之间的联系）：、

image-20250430142210232

通过这个权限模型，我们可以创建不同的角色并为不同的角色分配不同的权限范围。

  • 由服务器生成并发送给浏览器。
  • 浏览器在每次请求中自动携带 Cookie。
  • 可用于存储用户登录状态、追踪行为等。

优点：

  • 自动随请求携带。
  • 支持持久化。

缺点：

  • 容易被劫持（如XSS）。
  • 体积小（一般4KB限制）。
  • 不安全的数据最好不要直接存 Cookie。

Session​

  • 用户首次访问时，服务端创建 Session，生成 Session ID。
  • 服务端将 Session ID 写入 Cookie 发送给客户端。
  • 后续请求中客户端携带 Session ID，服务端找到对应会话信息。

优点：

  • 安全性高（数据存在服务器）。
  • 便于管理用户状态。

缺点：

  • 占用服务器资源（大规模用户时需优化，如 Redis 存储）。
  • 不能跨域使用。

JWT​

  • 登录成功后，服务器生成一段字符串（Token）返回给客户端。
  • 客户端每次请求时在请求头中携带该 Token（如 Authorization: Bearer xxxxx）。
  • 服务端校验 Token 是否有效。

结构为：header.payload.signature

  • Header：说明签名算法等。
  • Payload：存储用户信息（如 userId、role 等）。
  • Signature：由前两部分加密签名而成，用于校验内容是否被篡改。

优点：

  • 数据结构标准化，携带信息丰富。
  • 服务器可通过签名快速校验合法性，无需存储状态。
  • 跨域支持，适合分布式系统。

缺点：

  • Payload 内容是明文（可被解析），敏感信息不能放其中。
  • 一旦签发，无法主动失效（需要加入黑名单机制）。
  • 体积大，不适合频繁请求。

4. 如何使用JWT进行身份认证？​

在基于 JWT 进行身份验证的的应用程序中，服务器通过 Payload、Header 和 Secret(密钥)创建 JWT 并将 JWT 发送给客户端。客户端接收到 JWT 之后，会将其保存在 Cookie 或者 localStorage 里面，以后客户端发出的所有请求都会携带这个令牌。

image-20250430144613474

简化后的步骤如下：

  1. 用户向服务器发送用户名、密码以及验证码用于登陆系统。
  2. 如果用户用户名、密码以及验证码校验正确的话，服务端会返回已经签名的 Token，也就是 JWT。
  3. 用户以后每次向后端发请求都在 Header 中带上这个 JWT 。
  4. 服务端检查 JWT 并从中获取用户相关信息。

两点建议：

  1. 建议将 JWT 存放在 localStorage 中，放在 Cookie 中会有 CSRF 风险。
  2. 请求服务端并携带 JWT 的常见做法是将其放在 HTTP Header 的 Authorization 字段中（Authorization: Bearer Token）。

5. OAuth2​

OAuth2 是一个授权协议，允许第三方应用在不暴露用户密码的前提下访问受保护资源，授权码模式是最安全的流程，适合服务器端登录集成，如 GitHub 登录你项目的实现方式。

名称说明
Resource Owner（资源拥有者）通常是用户，拥有资源的权限
Client（客户端）想要访问资源的第三方应用（如你的网站、App）
Authorization Server（授权服务器）提供令牌和身份验证的服务器（如 GitHub 的授权服务）
Resource Server（资源服务器）存储资源的服务器，验证令牌并提供数据（如 GitHub API）
Access Token（访问令牌）客户端访问资源的“通行证”，有有效期
+--------+                                +-------------------+
|        |--(1) 跳转授权页面 ------------>|                   |
|        |                                |  授权服务器         |
|  客户端  |<-----------(2) 返回code -------|（Authorization Server）|
|        |                                +-------------------+
|        |
|        |                                +-------------------+
|        |--(3) 用code换取access_token -->|                   |
|        |                                |  授权服务器         |
|        |<----------(4) 返回token --------|（Authorization Server）|
|        |                                +-------------------+
|        |
|        |                                +-------------------+
|        |--(5) 携带token请求资源 -------->|                   |
|        |                                |  资源服务器         |
|        |<----------(6) 返回用户信息 ------|（Resource Server）    |
+--------+                                +-------------------+

说明：
(1) 客户端引导用户跳转至授权服务器授权页面；
(2) 用户登录并授权后，授权服务器重定向回客户端并携带授权码（code）；
(3) 客户端使用授权码向授权服务器请求令牌；
(4) 授权服务器返回 access_token（可选：refresh_token）；
(5) 客户端携带 access_token 向资源服务器请求用户信息；
(6) 资源服务器验证 token 后返回用户信息。

三、AI调用​

1. 参数​

身份认证参数

参数名说明
access_token 或 Authorization接口访问令牌，通常需要通过 API Key 或 client_id/client_secret 申请获得。
API-Key（部分平台如 OpenAI）一种简洁的身份验证方式，直接在请求头中添加。

请求头参数

参数名示例值说明
Content-Typeapplication/json请求体格式
AuthorizationBearer your_token_here使用 Bearer token 验证（如 OpenAI）
X-API-KEYyour_api_key有些平台使用自定义头验证

请求体参数

参数名类型说明
modelstring使用的模型名称，如 gpt-3.5-turbo、ernie-bot 等
messagesarray聊天上下文数组，每项包含 role（如 user/assistant） 和 content
promptstring输入提示词（适用于图像生成、文字生成等）
temperaturefloat控制输出的随机性，范围一般是 0~1，越高越随机
top_pfloat采样范围控制，一般与 temperature 配合使用
max_tokensint控制生成结果最大 token 数
streamboolean是否启用流式输出（如 WebSocket 场景）
userstring（可选）用户标识，有助于追踪和控制滥用