微服务(四)Mapstruct_jwt_spi_API网关

Mapstruct

1.

 2.

 3.注入对象

4. 包扫描

 ====

与DO与DTO之间的属性映射

@Mappings({

@Mapping

})

 list对象转换

把方法改成传入list和返回list<dto>的方法

(因为调用的是上面那个方法,所以不需要映射)

总结:1导入依赖2.转换接口,Mapper注解

@Mapper(componentModel = "spring")

@Mappings({
        @Mapping(source ="userAAId" ,target = "userId"),
        @Mapping(source = "orderSn",target = "orderSSSn")
})

抽象方法返回值为DTO

3.调用方法

 ================        ====

 1.接口

有不同的实现方式

2.动态替换与发现

 ​​​​​

 

 

感觉没啥用; 

===

API网关

 可以用controller实现网关

 希望实现:在相互信任的子系统中验证只需要实现一次

1.Nginx的ip_hash==>一个ip发送的请求总是在一个tomcat中

        弊端:a.如果使用ip_hash策略,负载可能不均衡

                b.失去了集群健壮性

2.Session的冗余存储,一旦用户在某个Tomcat服务器上登录成功,并且创建了Session对象,那么该Tomcat服务器会自动通过广播的方式将session对象复制给其他的tomcat服务器

        弊端:a.从内存的角度来说,因为用户的每个session对象都要各自存储一次,浪费内存

                b.广播风暴占用带宽

3.session的共享存储

 将每个Tomcat服务器中的session对象统一存储在一个共享的地方(Mysql或者Redis)这样所有Tomcat服务器都可以访问到所有用户登录之后对应的Session对象

        弊端:a.必须访问相应数据库(mysql或者redis)才能进行判断用户身份

=====>JWT 单点身份认证解决方案

 数字签名:

 一旦数据被篡改,那么得到的数字签名就不等,可以发现数据被篡改

总结:因为存在着集群下跨域的一个问题,为了让每一个tomcat都能共享到session信息

1.负载均衡一致性hash

2.广播风暴

3.第三方共享

4.jwt解决方案(都会携带cookie就可以了,加密的token,很安全)

2.使用场景

 生成了一个满足安全协议的json字符串-->Token(令牌中包含用户相关的数据),JWT的Token放在cookie中,返回给浏览器

当再次登录的时候会先验证Token的有效性:解密,并验证数字签名,如果验证通过说明数据没有被篡改,用户已经登录

基于session的被称为服务器端的解决方案

基于JWT的解决方案被称为客户端的解决方案

2.4Token VS Session

 JWT的其他验证方式:比如存储Token到请求头,从请求头中取得Token(只有对应的前端才能拥有合法的请求头),因此使用Token可以灵活应用;使用cookie只是一个存储机制,而不是验证机制

 格式

 

 

 @Builder注解 可以将类变成构造者模式