1.安全认证
●Session
认证中最常用的一种方式,也是最简单的。存在多节点session丢失的情况,可通过nginx粘性Cookie和Redis集中式Session存储解决
●HTTP Basic Authentication
服务端针对请求头中base64加密的Authorization 和用户名和密码进行校验。
●Token
Session 只是一个 key,会话信息存储在后端。而 Token 中会存储用户的信息,然后通过加密算法进行加密,只有服务端才能解密,服务端拿到 Token 后进行解密获取用户信息。
●JWT认证
JWT(JSON Web Token)用户提供用户名和密码给认证服务器,服务器验证用户提交信息的合法性;如果验证成功,会产生并返回一个 Token,用户可以使用这个 Token 访问服务器上受保护的资源。
①认证服务提供认证的 API,校验用户信息,返回认证结果
②通过JWTUtils中的RSA算法,生成JWT token,token里封装用户id和有效期
③服务间参数通过请求头进行传递,服务内部通过 ThreadLocal 进行上下文传递。
④Hystrix导致ThreadLocal失效的问题可以通过,重写 Hystrix 的 Callable 方法,传递需要的数据。
★Token最佳实践
●设置较短(合理)的过期时间。
●注销的 Token 及时清除(放入 Redis 中做一层过滤)。
虽然不能修改 Token 的信息,但是能在验证层面做一层过滤来进行处理。
●监控 Token 的使用频率。
为了防止数据被别人爬取,最常见的就是监控使用频率,程序写出来的爬虫程序访问频率是有迹可循的
●核心功能敏感操作可以使用动态验证(验证码)。
比如提现的功能,要求在提现时再次进行验证码的验证,防止不是本人操作。
●网络环境、浏览器信息等识别。
银行 APP 对环境有很高的要求,使用时如果断网,APP 会自动退出,重新登录,因为网络环境跟之前使用的不一样了,还有一些浏览器的信息之类的判断,这些都是可以用来保证后端 API 的安全。
●加密密钥支持动态修改。
如果 Token 的加密密钥泄露了,也就意味着别人可以伪造你的 Token,可以将密钥存储在配置中心,以支持动态修改刷新,需要注意的是建议在流量低峰的时候去做更换的操作,否则 Token 全部失效,所有在线的请求都会重新申请 Token,并发量会比较大。
2.灰度发布
★痛点:
●服务数量多,业务变动频繁,一周一发布
●灰度发布能降低发布失败风险,减少影响范围
通过灰度发布,先让一部分用户体验新的服务,或者只让测试人员进行测试,等功能正常后再全部发布,这样能降低发布失败带来的影响范围。
●当发布出现故障时,可以快速回滚,不影响用户
灰度后如果发现这个节点有问题,那么只需回滚这个节点即可,当然不回滚也没关系,通过灰度策略隔离,也不会影响正常用户
可以通过Ribbon的负载均衡策略进行灰度发布,可以使用更可靠的Discovery
★Discovery
基于Discovery 服务注册发现、Ribbon 负载均衡、Feign 和 RestTemplate 调用等组件的企业级微服务开源解决方案,包括灰度发布、灰度路由、服务隔离等功能
①首先将需要发布的服务从转发过程中移除,等流量剔除之后再发布。
②部分机器中的版本进行升级,用户默认还是请求老的服务,通过版本来支持测试请求。
③测试完成之后,让新的版本接收正常流量,然后部署下一个节点,以此类推。
3.多版本隔离
本地复用测试服务-Eureka Zone亮点
region 地理上的分区,比如北京、上海等
zone 可以简单理解为 region 内的具体机房
在调用的过程中会优先选择相同的 zone 发起调用,当找不到相同名称的 zone 时会选择其他的 zone 进行调用,我们可以利用这个特性来解决本地需要启动多个服务的问题。
[^]: 当你访问修改的服务 A 时,这个服务依赖了 B、C 两个服务,B 和 C 本地没有启动,B 和 C 找不到相同的 zone 就会选择其他的 zone 进行调用,也就是会调用到测试环境部署的 B 和 C 服务,这样一来就解决了本地部署多个服务的问题。
4.各组件调优
当你对网关进行压测时,会发现并发量一直上不去,错误率也很高。因为你用的是默认配置,这个时候我们就需要去调整配置以达到最优的效果。
首先我们可以对容器进行调优,最常见的就是内置的 Tomcat 容器了,
Hystrix 的信号量(semaphore)隔离模式,并发量上不去很大的原因都在这里,信号量默认值是 100,也就是最大并发只有 100,超过 100 就得等待。