关于头条项目经验的总结

前言

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

一、论坛项目经典话术

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

• 你介绍一下你最近/最熟悉的一个项目经验吧
• 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，返回给前端。

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

总结