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 就得等待。