每日面试题
面向服务的路由
在刚才的路由规则中，我们把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然就不合理了。
我们应该根据服务的名称，去Eureka注册中心查找 服务对应的所有实例列表，然后进行动态路由才对！
过滤器的使用场景
场景非常多：
•请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
•异常处理：一般会在error类型和post类型过滤器中结合来处理。
•服务调用时长统计：pre和post结合使用。
过滤器
Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的
默认的路由规则
•认情况下，一切服务的映射路径就是服务名本身。
–例如服务名为：user-service，则默认的映射路径就是：/user-service/**
也就是说，刚才的映射规则我们完全不配置也是OK的
负载均衡和熔断
Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只
有1S，很容易就触发了。因此建议我们手动进行配置
#网关配置
zuul:
retryable: true #开启重试（注意：检查之前是否配置zuul，如果配置需要合并配置项）
#全局负载均衡配置
ribbon:
ConnectTimeout: 250 # 连接超时时间(ms)
ReadTimeout: 2000 # 通信超时时间(ms)
OkToRetryOnAllOperations: true # 是否对所有操作重试
MaxAutoRetriesNextServer: 2 # 同一服务不同实例的重试次数
MaxAutoRetries: 1 # 同一实例的重试次数
#熔断
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMillisecond: 6000 # 熔断超时时长：6000ms
什么是CAP理论？
C(consistency):数据一致性：所有节点拥有数据的最新版本
A(availability):可用性:数据具备高可用性
P（partition‐tolerance）:分区容错性:容忍网络出现分区，分区之间网络不可达
CAP是无法完全兼顾的，可以选择AP,也可以选择CP,要注意的是：不是选择了AP,C就完全抛弃了。不是说选了CP,A就完
全抛弃了！
在CAP理论中，C所表示的一致性是强一致性（每个节点的数据都是最新版本）
1.网关流程.png
2.maven坐标--spring boot 坐标要求.png
3.maven坐标--spring cloud 坐标要求.png
4.路由默认情况.png
5.网关--分析.png
6.今日流程图.png
