关于头条项目经验面试题的总结

---

前言

自己学过的项目如何梳理、将每一个项目的核心业务梳理出来，整理成话术。以及发现项目汇总的技术亮点，详细讲解技术亮点的实现思路。

---

一、论坛项目经典话术

话术：将整个项目的各种业务、技术亮点，进行抽取，编成大白话，覆盖所有的核心业务、各种技术解决方案。真正做到，就算照着念，都可以给面试官讲明白。
解决面试问题：

• 你介绍一下你最近/最熟悉的一个项目经验吧
• XXX技术在这个项目中用到过是吧？
• XX业务遇到XX问题，你们是怎么解决的？
  针对自己的项目经验

---

二、请你介绍一下你最近的项目吧

注意：一定要追求真实，一定要给一个真实背景。
项目三要素：项目介绍、岗位职责、业绩、技术亮点

2.1 话术1

我最近做的这个项目是融媒体项目，准确来讲是一个融媒体平台，项目是我们公司自研的，核心业务就是基于我们公司自好的面试官，有的媒体资源、社群、自媒体资源进行整合。基于我们研发的融媒体平台，构建了多款APP，分别针对不同的客户群体。公司业务规划走的就是融媒体矩阵，每个App项目分别针对不同的类目进行打造，各自做专业垂直类目的AP。说白了就是前端换了个皮肤，垂直类目有母婴、健康、旅游、以及各省市区域进行打造，只要运营需要，随时可以生产出很多APP。

项目的核心就是通过矩阵玩法，聚集不同类目下的用户，每一个项目都是一个垂直类目，吸引不同兴趣爱好的用户，说白了就是养一波铁粉，然后为后期打造私域营销、垂直类目精准客群推荐打好基础，后期公司计划就是走这个广告和垂直类目电商进行营利。

还有就是项目架构，我们首先是将整体系统拆分成多个分布式子系统，比如大数据计算和推荐、平台运营管理系统、还有就是我参与的这个融媒体平台项目。

我主要是负责融媒体平台端的一些功能开发，后台架构是用的微服务，便于业务的扩展和将来部署时动态的管理服务资源。

主要服务的话就是个人中心、文章服务、行为数据服务、任务调度微服务、评论服务、检索服务、自媒体管理服务、平台管理服务、图片管理服务、统一认证服务这些基本业务服务，大概有十几个，大部分服务模块相关的核心业务开发我都参与过，我们公司开发模式的话没有严格的划分具体负责哪些模块，都是根据月度下发的任务进行分配的。

然后业务层，就是每一个微服务的话，我们是用的SpringBoot、RabbitMQ、Elasticsearch这些技术MybatisPlus、Redis、MySOL、还是比较主流的;

我在项目中的话，主要是负责iava后端开发，算是我们小组的主力吧，项目也是做了有一年了，目前已经上线几个APR了主要独立负责的一些核心业务的话就是有用户推荐服务|ava端、个人中心、文章服务、任务调度微服务、评论服务、检索服务、统一认证服务这几个核心模块业务的设计与编码

这个项目我从项目立项那会就参与了，我刚进公司的时候这个项目刚开始做，所以这类型业务也是非常熟悉，当然我主要是做后端开发。

大概就是这个情况，面试官。

---

三、你的公司的开发环境是怎么搭建的？

我们公司的项目环境有开发环境、测试环境和线上生产环境，测试环境和生产环境是运维搭建的。

然后开发环境是我(如果你包装3年以下就说你组长搭建)搭建的，我们公司内部有专门的开发机，就是一台高性能的服务器，然后我在上面使用 Docker 部署了一些项目开发环境用的东西，比如:Redis、MySQL、Nacos Server端、Sentinel Server端、SkyWalking Server端，还包括一些其他中间件，Elasticsearch、RabbitMQ、XXL-JOB 这些中间件，还有ELK日志平台，这些都是我部署的。

因为开发环境的这个服务器性能足够满足我们日常开发使用，所以就部署在一台服务器上。主要是能够快速的重置、重启就可以了。

至于公司内部项目管理工具、GitLab、公司内部知识库这些不是我搭建的，因为这些都是公司平台自有的。

开发的时候，我们就是连接公司内网的开发机，所有的连接方式、账号信息，我都是写好文档，在公司内部的 wiki 平台上发布了，用的时候，其他同事去参考就行了。如果回家后需要加班的话，我们就配上 VPN 连接公司内部服务器就行了。

---

四、登录你们是怎么做的？

平台方、媒体端、用户端登录方式是不一样的，平台端和媒体端是支持账号密码、手机验证码登录。
用户端是支持账号密码、手机验证码、微信登录、微博登录多种登录方式。
平台端和媒体端是必须登录后才能使用。
用户端的话，可以匿名访问，但如果要点赞、评论、收藏或者查看个人中心等行为的话，还是需要登录的，App 页面会自动跳出来登录界面。关于登录这块都是我做的，我给您挨个说一下吧

4.1 账号密码登录

我们首先设计了用户表，用户表中包含了用户的账号、密码、手机号、头像、注册时间、是否身份认证这些字段。

当前端提交请求时，请求体中以 JSON 形式提交账号、密码、验证码这几个参数。请求先到后端 gateway 网关，网关处判断登录请求时不需要校验 Token 的，所以直接放行请求被转发到 user 用户服务这里，流程也很简单，先针对参数进行校验，非空、是否合法如果参数有问题，则直接返回登录失败信息。如果参数没问题，就判断一下账号密码是否频繁登录，这里我是借助redis 的 zset数据结构设计了一个时间窗口限流算法实现的。

如果没有限流，就查询用户数据，用户是否存在，如果不存在就返回登录失败。如果存在，就校验密码，我们是使用加随机盐的一个工具类 BCrypt 实现的，它的安全度更高。如果密码校验通过，就封装用户数据，比如用户名、用户头像，封装到JWT Token 的载荷中，返回给前端就可以了。
以后前端就带着这个 Token 访问其他资源。当然了，我在网关处，针对 Token 进行校验，比如访问受限资源，需要判断是否有 Token，判断 Token 是否有效，如果 Token 没问题，就将请求放给后面的微服务。

4.2 手机验证码发送

这个流程主要涉及的到3个接口，分别是：

• 手机验证码发送接口，在common通用服务中
• 滑块验证码接口，在common通用服务中
• 手机验证码登录流程，在user通用服务中

4.2.1 手机验证码发送

首先用户在页面填写手机号码，前端校验手机号没有问题，就会自动向后端【发送登录短信)接口发起请求。

我们是设计了一个 common 服务，就是封装了一些通用功能的服务，将发短信、OSS 对象存储这些通用功能都放到这个通用服务中实现。

限流的条件是满足 5 分钟内发生3次发短信行为，就判定进行限流。如果没有达到限流阈值，我们直接调用三方的短信服务，发送短信。短信发送成功后，我就把短信验证码，缓存到 Redis 中，过期时间 TTL 设置为默认 5 分钟当然这些时间配置什么的，我们都使用统一的配置文件管理了，可以动态修改的。缓存在 Redis 中的 key 的格式为:USER:LOGIN:手机号值就是验证码的随机值。最后响应前端短信发送成功。

另外还有一个点就是限流的细节，我给您讲一下，我们分两级验证码限流的:第一级:用户5分钟内连续发3次短信，达到值后，使用滑块验证码限流，查询请求参数中是否携带滑块验证码参数，如果有，就查询redis 中的验证码，比对前端提交的这个参数是否正确，如果正确，就直接放过去。

第二级:用户 10 分钟内，连续发8次短信，达到值后，直接限流用户 10分钟后重试实现方式就是将用户拉黑，把用户的手机号设计为 key，比如:BLACK:LOGIN:手机号TTL 过期时间设置为 10 分钟，这样用户下次请求时，直接判断这个手机号是否在黑名单如果在的话直接就拒绝了。10 分钟后自然会过期，就又恢复正常发送短信了

4.2.2 手机验证码登录

首先是前端提交登录登录表单，包含手机号、验证码。

后端接收到请求后，先校验一下手机号是否合法。

然后根据手机号，查询 Redis 中缓存的真实验证码，查询完毕后销毁掉 redis 中的验证码.比对验证码是否正确，如果验证码不存在，或者验证码错误，那就直接返回前端失败信息。如果验证码正确，就根据手机号查询用户表中用户数据，如果用户存在，就以JWT格式封装用户 Token，返回给前端。

如果用户不存在，也没关系，直接默认自动注册，写入用户的手机号，关于用户名和头像用默认值代替。
用户自己可以在个人中心中，修改用户名、头像、密码等数据。

---

五、用户行为限流是怎么做的？

有的，这个必须做限流，我是利用redis 的 zset 结合时间窗口限流算法进行实现的。我们是这样考虑的，用户可能有很多行为，是无意义，或者非法的，比如:频繁发送短信、频繁修改个人信息、频繁的点赞、评论等等行为，都应该进行限流。所以我就针对这些频繁的行为进行限流，设计了一个通用的限流接口。思路上是使用时间窗口限流算法，具体实现我利用 redis 的 zset 进行实现。比如说，用户5分钟内只能发送3个验证码，或者 10分钟内只能发送8个验证码，于是我就将用户发短信的行为设计为 key，格式为【场景:行为:用户唯一标识(可以是手机号、用户名)】，score 分数值是时间戳，value值也是时间戳。

限流算法思路：

具体流程:

• 当用户每次发生限流行为，都会记录这个行为，以Redis zset的方式进行记录。
• 在业务处理流程中，使用java api进行查询判断，其实本质就是调用redis 的zcount命令，这个命令可以传入起始分值和结束分值。我就把当前时间戳作为结束分值，然后当前时间戳减去限流时间，比如说5分钟的毫秒值，求出来5分钟前的时间戳。于是根据这两个时间戳作为分值，范围查询 zset中出现的次数，就得到用户在5分钟内，这个行为一共触发了几次。
• 后续的业务，就是不同场景中，根据不同的需求，进行校验就行了，比如说5分钟限流3次，10 分钟限流8次，这就是后面的业务代码考虑的事情了。

---

六、续约Token怎么设计的？

这个续约 token 在我们的项目中有设计过，恰好也是我做的。当时产品经理给到的需求是，要求用户可以保持一个长期登录或者自动登录的效果。避免用户状态频繁过期，频繁登录给用户带来不便我当时就使用双 Token 的方式进行设计的，这种方案提出来后是经过组长评估的，他也认为没问题，于是我就这么做了。

我给您说下我的大概实现思路吧。

首先是登录，在登录的时候，无论何种方式认证，最后都是返回Token 给到前端。在返回 Token 的时候，是生成两个 Token:

• 一个是 AccessToken，我管他叫访问令牌，我处于安全考虑，比如防止令牌被恶意使用设置他的有效期为 3个小时，每次请求资源时携带这个令牌;
• 另一个是 RefreshToken，我管他叫刷新令牌，这个令牌不能用来访问资源，只能用来刷新访问令牌，就是每当访问令牌过期，前端携带这个RefreshToken 获取新的 AccessToken这个刷新 Token 的有效期我设置为7天，当然这个可以改，这是写在配置文件中的;

当 Token 返回给前端后，浏览器端用的是localStorage 保存的，App 端的话有他们自己的地保存方式，将这两个 Token 保存下来。

然后就是访问资源的时候，我们在网关处会进行校验，如果访问的是受限资源，那么网关写了一个全局过滤器，校验是否携带 AccessToken，以及这个 Token 是否过期如果正常，则直接放行。

如果校验异常，可能是 Token 过期，也可能是 Token 数据被篡改或损坏，于是返回拒绝。前端判断拒绝的状态码为 AccessToken 无效后，会重新发起一次请求，携带 RefreshToken 重新请求续约接口，这个续约接口是不需要网关拦截的，然后续约接口针对 RefreshToken 进行解密后，校验签名没有问题，没有被篡改，于是重新颁发新的AccessToken，返回给前端。前端重新携带 AccessToken 发起请求就行了这里面有个重要的地方就是，我针对令牌使用 RSA非对称加密进行加密，目的就是防止被篡改数据。

这就是我设计的实现方案。