尚硅谷springcloud2020day4(p31-39)

今天是2020-12-6
一。服务注册进consul
学完三个注册中心，大概的流程也知道了，如果想更换注册中心且正常调用服务，你需要：
1.pom文件更换注册中心的依赖
2.application.yml更改注册中心的url，比如把cloud.zookeeper.connectstring换成cloud.consul.host，不过consul的ip地址和端口号是分开赋值的
3.服务消费者目前还是照旧注入resttemplate并启动loadbalanced负载均衡，然后控制器的方法返回resttemplate.getforObject(http://服务名/服务提供者提供的rest接口路径,返回值类型),就可以成功调用服务了
二。知识补充
这里也发现了一个以前没有注意到的知识点：为什么在调用集群服务时，加@loadbalanced就能写服务名而不是具体的服务地址呢，其实：
1.@LoadBalanced是一个注解，用于标记要配置为使用LoadBalancerClient的RestTemplate bean的。
2.在LoadBalancerClient接口中,URI reconstructURI(ServiceInstance instance, URI original)方法表示为系统构建一个合适的URI，我们在Spring Cloud中服务的发现与消费一文中发送请求时使用了服务的逻辑名称(http://HELLO-SERVICE/hello)而不是具体的服务地址，在reconstructURI方法中，第一个参数ServiceInstance实例是一个带有host和port的具体服务实例，第二个参数URI则是使用逻辑服务名定义为host和port的URI，而返回的URI则是通过ServiceInstance的服务实例详情拼接出的具体的host:port形式的请求地址。一言以蔽之，就是把类似于http://HELLO-SERVICE/hello这种地址转为类似于http://195.124.207.128/hello地址（IP地址也可能是域名）。
负载均衡根据服务名称帮我们动态选择其中的一个服务实例，然后用这个方法将服务名转换为具体的实例的地址，执行请求。我们的服务在向注册中心注册服务的时候，可以说就是以服务名-实例地址的kv形式注册的，一个服务名可以对应的多个实例地址，所以需要负载均衡动态选择其中一个来执行。
三。三种注册中心的重点概念
1.cap,eureka是ap保证高可用，zookeeper和consul是cp保证强一致
2.三种注册中心springcloud都集成了
3.健康检查,zookeeper和consul默认都有，eureka要自己配置
4.eureka和consul有可视化界面，zookeeper没有
AP：保证高可用与分区容错，牺牲了一定的一致性，比如说A节点更新了数据c的值，B节点可能因为网络故障没有同步更新c，但是为了保证高可用，此时用户来请求B上的服务，也要返回未更新的C，等网络恢复，最终c还是会更新，这就是ap的，高可用以及最终一致性。
CP：保证强一致与分区容错，牺牲了可用性，如果A节点更新了数据C,B节点因为网络故障还没有同步更新c，此时用户来请求B上的服务，为了保证强一致性，会拒绝用户的请求，等网络恢复，同步更新了C再开始接受请求。redis、mongodb就是cp原则
CA：至于CA还是顺便说一下，保证了强一致与高可用，没有保证分区容错，可以说就是单服务器，没有涉及到分布式，那么就要保证数据及时更新并及时响应用户，传统的mysql、oracle就是ca原则
四。负载均衡
负载均衡就是将请求分摊到多台服务器上，从而达到高可用。
就目前来说，需要掌握的负载均衡有两类：
1.服务端负载均衡，目前了解nginx。nginx属于服务器负载均衡，客户端所有的请求都会经过nginx，nginx启用负载均衡以及反向代理，将请求转发到网关集群中的某个网关上，然后由具体的应用层网关做日志记录，鉴权等详细功能以及将请求路由到具体的服务集群。nginx本身功能较少，一般就是做负载均衡与反向代理，可以开发lua脚本添加功能。
2.客户端负载均衡，目前了解zuul以及feign，都属于本地负载均衡，基于ribbon实现，nginx转发的请求到达zuul后，zuul就对请求做鉴权，日志记录等工作，同时过滤不合法的请求，将合法的请求路由到指定的后端集群，注意：zuul结合ribbon实现了负载均衡，所以会默认轮询将请求路由到集群中的某台服务器上。这个时候就有疑问了，feign与zuul同属本地负载均衡，那还要feign做什么？其实可以说zuul做了最外层微服务的负载均衡，如果接下来还有内部的服务间相互调用涉及到服务集群，那么就需要feign来实现负载均衡。
3.总结起来，现在能掌握的就是请求统一发送到一级网关nginx，由nginx做负载均衡，将请求分摊到二级网关zuul集群中的某一个zuul，zuul针对请求做鉴权、日志记录等处理，将过滤后合法的请求动态路由到后端集群中，这个时候实现了负载均衡，默认轮询调用集群中的某台服务器，这次服务调用后，由feign负责接下来内部的服务调用时涉及到集群的负载均衡。
五。ribbkexon
ribbon工作时会分两步：
(1)先选择注册中心，优先选择同一区域内负载较少的注册中心
(2)根据用户指定的策略，比如随机、轮询等，从去注册中心取得的服务列表中选择一个实例地址。
六。RestTemplate
常用方法:
1.getForObject,发送一个HTTP GET请求，返回的请求体将映射为一个对象。
(1)getForObject(url,reponsebleType)，不带参数模式
(2)getForObject(url,reponsebleType，object xx…/Map<String,?> map),带参模式，可以携带一或多个对象，或者直接携带一个map集合，url的写法：“http://localhost/get/{id}”，即以占位符携带，请求的方法就以@PathVariable取出占位符中的数据
2.getForEntity()，发送一个HTTP GET请求，返回的ResponseEntity包含了响应体所映射成的对象，和上一个方法的区别就是，getForObject只返回响应体，而该方法返回响应的全部信息：响应状态,响应头 和 响应体。
至于方法的各种重载形式与getForObject一致。
3.postForObject(),POST 数据到一个URL，返回根据响应体匹配形成的对象
(1)postForObject(url,request,reponsebleType),非restful风格,request是MultiValueMap<String, Object>类型，可以携带参数–这种方式是表单传递，hashmap是请求传递
(2)postForObject(url,null,reponsebleType,object xx…/Map<String,?> map),
restful风格，url还是写成占位符形式
4.postForEntity()POST 数据到一个URL，返回包含一个对象的ResponseEntity，这个对象是从响应体中映射得
到的。
该方法与postForObject的重载形式基本一样，唯一区别就是,postForObject的request只能携带请求体，而该方法的request是HttpEntity<MultiValueMap<String, Object>>类型，可以设置请求头的参数，即需要设置请求头就使用该方法
七。ribbon常用算法
1.RoundRobinRule，ribbon的默认算法,轮询算法，轮流访问实例列表中的实例
2.RandomRule，随机算法，随机访问实例列表中的某个实例
3. RetryRule，重试算法，如果轮询算法选择的实例为null或者已经失效，那么就重新轮询选择一个，直到实例有效就返回。重新选择时，每次轮询选择一个后，判断这个实例是否有效或者当前花费的时间已经大于等于最大重试时间，满足一个就放弃重新选择，并返回选择的实例。这里就可以联想起：熔断器的超时时间一定要大于ribbon配置的单次超时时间*重试次数，如果ribbon还在重试，但是此时已经超过了熔断器的超时时间，那么就不会再继续请求调用后端服务，直接调用降级方法，所以要注意。
4.WeightedResponseTimeRule，根据响应时间加权。每隔30秒统计一次每个实例的权重，30秒后根据统计结果来分配权重，并根据权重分配调用数据
5.BestAvailableRule ，最低并发策略。该算法会遍历实例列表中每个实例并过滤标记为circuit tripped的实例，让每个实例的并发数与当前最小并发数比较来找出最小并发数的实例。
6.AvailabilityFilteringRule ，可用过滤策略。通过predicate来过滤掉一直失败且被标记为circuit tripped的实例，也会过滤掉并发数较高的实例，对于剩下的实例以轮询算法调用。
7.ClientConfigEnabledRoundRobinRule，该策略较为特殊，我们一般不直接使用它。因为它本身并没有实现什么特殊的处理逻辑。通过继承该策略，默认的choose就实现了线性轮询机制，在子类中做一些高级策略时通常可能存在一些无法实施的情况，就可以用父类的实现作为备选。
继续加油！