技术栈：SpringBoot + SpringCloud + MybatisPlus + Swagger + knif4j + Redis + MongoDB + ElaticSearch + JWT + Kafka/Kafka Stream + Jenkins + Dockerfile + nginx + git + SkyWalking(链路追踪) + 云服务(阿里云服务内容安全)
1. 管理员后台系统(平台管理员)
频道接口开发—-ad_channel 频道信息表
- 分页条件查询
- 新增频道
- 修改频道
- 删除频道：需要判断改频道是否有效，无效方可进行删除操作
- 查询频道
配置全局异常处理器—-无论正常执行还是出现异常，都返回统一的响应结果
- 如果异常不进行处理，最终异常就会抛给框架，框架会对异常进行默认的处理，相应的结果就为默认的json字符串，这是不满足开发规范中的统一响应结果的
- 在抛出异常后，将异常信息发送到MQ中，然后被告警平台消费，定位了指定详细的异常位置，通过发邮件或者发短信通知相关人员进行处理即可。
敏感词的管理—-定义文章中的敏感词汇，后续可进行审核文章内容
- 增加敏感词
- 删除敏感词
- 修改敏感词
- 查询敏感词
管理员后台登录
- 管理员后台登录进行校验 账号密码，密码在数据库中的表现形式为加密之后的，用户前端传入的账号密码，通过账号查询有无此人，没有查询结果直接返回；若有此账号信息，对传入的密码进行相同的加密操作(密码+此用户的盐值)与数据库中存放的加密之后的密码串进行比对，相同则通过验证，生成对应id的token，同时为了数据安全，将用户的账号密码置空进行返回
网关定义全局过滤器，实现jwt校验
- 判定当前请求是否是登录操作，如果是登录操作的话，直接放行
- 从请求头中获取token的值jwt令牌，判定jwt令牌是否存在，如果令牌不存在的话，直接返回相应错误信息，结束。
- 如果jwt令牌存在，检验令牌的有效期，令牌过期，直接响应错误信息，结束
- 如果jwt令牌存在，并且令牌有效，需要从jwt令牌中获取id
- 然后将现有的request对象进行增强(增强header信息–>userId)
- 放行
密码加密方式
可逆加密 ：加密后，密文可以反向解密得到密码原文
- 对称加密：加密的密钥和解密的密钥是一样的：AES、DES、3DES、Blowfish、IDEA、RC4、RC5、RC6、HS256…
- 非对称加密：加密的密钥和解密的密钥是不一样的（密钥对=私钥（解密）+公钥（加密））
不可加密算法：一旦加密就不能反向解密得到密码原文：MD5、SHA、HMAC
Base64编码：Base64只是一种编码方式，不能算是加密方法。
手动加密：MD5+随机字符串：这样子的密码，加密多次值是不相同的，因为加入了随机字符串，也就是在MD5的基础上手动加盐（salt）处理
分布式事务
CAP定理
- 一致性 C：写操作之后的读操作，必须返回改制
- 强一致性：要求更新过的数据都被后续的访问都看看到
- 弱一致性：可以容忍后续的部分或者全部访问不到
- 最终一致性：经过一段时间后要求可以访问到更新后的数据
- 可用性 A：只要用户收到请求，服务器就必须要给出回应
- 分区容错性 P：区间通信失败，服务器之间无法正常进行通信
为什么说一致性和可用性冲突？
- 分区容错性是一定需要保证的，一致性和可用性会产生冲突，一致性高的话，那么它的可用性势必就会降低，相反，可用性高的话，一致性就会降低，比如一台服务器只负责一台服务器的数据一致的话，那么它的一直性就会高，如果一台服务器给十台服务器同步数据的话，那么它的可用性很高，但是数据的一致性就会变的很低。所以一致性和可用性是冲突的。
- 一致性 C：写操作之后的读操作，必须返回改制
BASE理论
- BASE理论是基于CAP理论的，核心思想为：既然我们没有办法做到强一致性，那么我们就需要根据每个业务的特点，采用适当的方式使得系统达到最终一致性
- 基本可用：假设系统出现了不可预知的故障，但是还是可以使用的，就是相比较正常的系统而言，响应时间可能会变久一些，比如服务的降级
- 软状态：允许系统的数据存在中间状态，认为这种状态是不影响系统的整体可用性的。即 允许系统在多个不同节点的数据副本存在数据延时
- 最终一致性：系统可以保证在没有其他更新操作情况下，数据最终一定是可以达到一致的状态，因此最终所有的客户端都是可以获取到最新的值
分布式事务的解决方案
- Seata事务模式AT
- TC 事务协调器：主要负责事务的提交或者回滚
- TM 控制全局事务的边界。负责开始全局事务，最终发起全局提交或者全局回滚的决议
- RM 控制分支事务，负责分支注册，状态汇报，接受事务协调器的指令，驱动分支事务的提交和回滚
- AT模式是基于两阶段提交协议的演变
- 一阶段：业务数据和回滚日志在同一个本地事务进行提交
- 二阶段：提交异步化，十分快速就完成了。回滚是通过一阶段的回滚日志进行反向补偿
分布式文件系统-FastDFS
FastDFS包括Tracker server 和 Storage server
Tracker server 负责负载均衡和调度， Storage server 主要负责文件存储， Storage server 是没有自己的文件系统，它是利用操作系统的文件系统来管理文件的。
用户认证为自媒体人
- 跨域：cors–>是一个为w3c标准，“跨域资源共享”，发送xmlHttpRequest请求
- 用户通过了实名认证，就可以成为发布者，需要用户在App端进行实名认证提交，然后在平台运营端就可以进行人工审核
- 审核成功后就需要开通发布者账号，发布者账号和app端账号密码一致，然后就可以通过发布者平台正常的进行文章的发布
- 用户在App端进行实名认证信息的提交，保存到实名认证信息表中，系统运营端对实名信息表进行查询，
2. 自媒体人后台系统(自媒体人)
上传素材图片
- 通用模块继承fastdfs，方便后期各个模块引用
- 自媒体微服务
- 上传素材图片到fastdfs中，同时要保存一份数据到素材表中，方便后期的管理
- 然后进行路径的拼接，素材表中保存的url没有fastdfs所在虚拟机的地址和端口号，需要进行路径的拼接，在上传后进行页面的回显操作
自媒体登录
- 从前端获取到自媒体人输入的账号和密码，去数据库中进行查找
- 数据库中的密码是通过md5+盐值 加密后进行存储 ，数据库中同时也会进行保存加密后的盐值
- 验证密码：使用用户输入的密码 + 数据库存储的盐值 拼接 进行md5加密与数据库中存储的密码进行对比。一致通过验证。
自媒体网关
- 上传素材的时候，是需要知道是哪一位自媒体人登录了当前系统
- 上传图片需要携带token,首先请求带网关服务，解析token是否有效，如果有效的话，解析后将用户的数据设置到header中
- 在自媒体微服务中使用过滤器解析header中的数据，就可以获取到用户数据，然后将用户信息设置到当前线程中，ThreadLoad
- 在后续的操作中就可以从此线程中获取到当前登录的用户信息
素材列表 全部/收藏 0 不收藏 1收藏
- 正常查询就好
- 分页查询–从threadload中获取登录用户