公共-八股文

1. 项目怎么保证敏捷开发

1.会议
2.文档
3.持续构建
4.持续集成

2. TCP三次握手和四次挥手

A请求连接B
B发送ACK给A
A发送ACK给B

A请求断开连接B
B发送ACK给A[已确认收到请求，但是还需要等待B空闲]
B发送断连请求给A[B空闲才发断连请求]
A发送ACK给B

3. 跨域请求是什么，有什么问题，怎么解决

客户端发起请求时，会检查请求的协议、域名、端口是否与当前一致，如果不一致就会出现跨域问题
要处理该问题:
1.请求:请求通过后台转发至真正的接口[夹一层转发层,利用后台转发，类似网关]
2.响应:响应上面加上“access-control-allow-origin”

4. 浏览器一个请求到一个响应，经历的步骤

1.请求URL，通过DNS解析找到对应IP以及端口
2.NGINX之类反向代理到对应的服务上
3.后台服务依据URL，将请求转发至对应的类，对应的接口上
4.接口走完所有逻辑以后，返回响应
5.客户端收到响应后渲染

5. 敏感数据怎么加解密，怎么传输

加解密:算法分对称与非对称，直接rsa加密，公钥加密，私钥解密
传输:可直接用最常见的https协议传输

6. 什么是拆包、粘包

两个都是网络传输中的概念
拆包:由于单个数据包过大，导致无法一次性传输，从而将其拆分成若干数据包再进行传输
粘包:由于数据包较小，因此发送方将若干数据包拼接成一个数据包进行传输

问题:
拆包:接收方收到若干数据包，无法正确还原大的数据包，或者无法知道是否收到所有分割包
粘包:接收方收到大的数据包，无法正确分割出若干原始数据包

解决办法:
其实两种问题都是无法正确识别包引发的
1.定长
2.特殊字符分割
3.包头添加长度、顺序等信息

7. 扫码登录如何实现?
graph TD 客户端申请生成二维码 --> 服务端生成二维码ID --> 客户端依据ID生成二维码 --> 手机APP扫描二维码,携带身份信息发送服务端 --> 服务端更新客户端信息,已扫描待确认,生成临时token发送至手机 --> 手机确认,并将临时token发送服务端 --> 服务端更新客户端信息,将token发至客户端 --> 客户端依据token访问服务端
8. 对接第三方接口需要注意什么?

1.安全性:接口加密解密(hutool-crypto)，传输采用加密HTTP协议等等
2.稳定性与可靠性:直接影响业务的实际体验与流程，需要充分的评估与测试
3.访问限制与费用:是否有服务限流之类的限制，或者接口使用是否有费用，需要充分评估

9. 失血、贫血、充血、胀血

名称	特点	优点	缺点
失血模式	Domain Object（领域对象）模型仅仅包含对象属性的定义和操作对象属性的getter/setter方法，所有的业务逻辑完全由Business Logic层(业务逻辑层)中的服务类来完成。这种类在java中叫POJO，在.NET中叫POCO。	领域对象结构简单	1.肿胀的业务代码逻辑，难以维护 2.无法应对频繁更改的需求
贫血模式	Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter方法并包含了对象的行为（例如：就像一个完整的人，具有一些属性如姓名、性别、年龄等，还具有一些能力，如走路、吃饭、恋爱等，这样才是一个完整的对象）， 但不包含依赖Dao层(持久层)的业务逻辑。这部分依赖于Dao层的业务逻辑将会放到Business Logic层（业务逻辑层）中的服务类来实现，组合逻辑也由服务类负责。可以看出，贫血模型中的领域对象是不依赖于持久层的。代码架构层次结构是： Client-> Business Facade Service -> Business Logic Service(Business Logic Service是依赖Domain Object的行为) -> Data Access Service	1.层次结构清楚，各层级单向依赖 2.对于只有少量业务逻辑的应用来说，使用起来非常自然 3.开发迅速，易于理解	无法良好的应对复杂逻辑与场景
充血模式	Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter方法并包含了大多数相关的业务逻辑，也包含了依赖于持久层的业务逻辑， Business Logic层是很薄的一层，仅仅简单封装少量业务逻辑以及控制事务、权限逻辑等，不和DAO层打交道。所以，使用充血模型的领域对象是依赖于持久层的。代码架构层次结构是： Client-> Business Facade Service -> Business Logic Service -> Domain Object -> Data Access Service	1.更加符合面向对象原则 2.业务逻辑层很薄，符合单一职责原则 3.不和dao层打交道	1.职责不好划分，对开发要求高 2.业务层可能需要针对模型中已有行为还要进行封装，从而导致重复劳动
胀血模式	Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter方法并包含了所有相关的的业务逻辑，也包含了不想关的其它应用逻辑（如授权、事务等）。胀血模型取消了Business Logic层(业务逻辑层)，只剩下Domain Object和DAO两层，在Domain Object的Domain Logic上面封装事务，授权逻辑等。	简化了分层架构，符合面向对象原则	1.取消了业务逻辑层,直接在领域对象上封装事务以及授权，业务逻辑进一步混乱了 2.代码可理解性与可维护性更差了

参考:
https://blog.csdn.net/u011537073/article/details/114267739