开发者学堂课程【5天突破 Spring Cloud：微服务调用 Feign 与负载均衡】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/781/detail/13702
微服务调用 Feign 与负载均衡
在客户端代理注意一个问题，接口声明的时候，搜索订单服务等真正调后台的方法靠@RequestMapping 来进行匹配。后台 hi 通过真正的地址偏移和服务名，转给真正的后台订单服务的 hello 方法，这是真正的过程。
测试为了代理，功能正不正常，能不能和后台服务进行交互，定义了客户端代理变量，该变量没有真正的对象，因为这是 Spring 帮助创建对象，这里使用了动量代理机制，底层动态创建对象然后注入，然后通过这个调用。
声明对象没有变量，直接调用方法会出现空值异常，Spring 从诞生之初就在帮助大家解决繁琐的工作，到 Spring Boot 阶段更有代表性了，变得更傻瓜式了。
接下来先启动注册中心再启动微服务，再启动测试客户端 Feign 这个程序。注册中心背后做繁杂的工作，表面上看只有一个注解，但是通过源码可知背后调用 Tomcat,在8761端口上暴露地址，背后有缓存和维护等，维护所有向它注册的服务列表，再启用多线程定时，一般是30秒，将注册到注册中心的服务通信一遍，发送消息，查看是否正常。注册中心可以主动更新信息。
运行 run 注册中心，刷新一下注册中心界面，一个服务都没有，先刷新一个服务，先订单一，run 运行。然后启动项目程序，9001端口是调用方，注册中心是8001，可以打开浏览器测试，搜索localhost:8001/hello，看后端服务是对的。同理测试9001，通过 hi 调，hi 会通过客户端代理通过网络请求发给后端微服务，微服务本身架构更复杂，数据链路多了一层，后期还经过代理，反映一个问题并不是集群架构是最优的。
启动出错，查看错误信息：
创建的时候依赖项有问题，程序没启用EurekaClient,与注册中心连不上，作为调用端，添加一个注解@EnableEurekaClient，帮助完成与注册中心打交道。再次启动出错找不到 ClientProxy,检查复制单词是否拼写错误。
再次启动仍出错，再添加注解@EnableFeignClients,启动成功
。Feign 底层实际也依赖 EurekaClient,也需要和注册中心打交道，也涉及服务的过滤，包括后期状态缓存列表的更新问题。再集群架构模式下尤其是微服务这种更复杂的体系下会变得更复杂，这里在同一目录下是为了简单，后面可以拆到不同的包中，为了测试简单。再次浏览器测试调用 hi，测试成功返回了服务器端的字符串。
这体现了复杂的调用链，通过代理通过网络请求去找服务端的注册中心的微服务真实例子的某一台。体现多台可以把第二台服务上线，注册中心有服务一2021，第二台服务与第一台是一模一样的，只是端口是9002，返回2022，区分返回字符串，区分是哪台服务器来的。注意添加@EnableEurekaClient,默认添加了，自动和注册中心叫交互，然后启动。如果出现包级别，在 Order 订单微服务中没有加入包扫描的路径，因为这里包的级别更低层次，除了根目录的包其他都低一级。
另外，如果 com.alibaba 与目录级别相同的话，需要加扫描，显示指定扫描哪个包，放在不同目录级别下需要添加包扫描的路径。
再看注册中心，调用端程序也注册了，但其实是没必要的，订单服务已注册两台，8002和8001返回的字符串不一样，调8002返回2002，再通过9001 Feign 来调，
返回字符串2001和2002会发生变化，因为从注册中心实际 Feign 服务列表有两台注册中心服务，再执行一个策略：挨个轮询，体现一个最公平的策略挨个轮询，随机就是不确定，抽到谁就是谁。
真正微服务调用优化策略挨个轮询与随机并不是最好的，因为微服务程序后台压力不确定服务配置也有差距，理论配置更好或者资源空闲更多的可以多调用几次，有些服务器处理比较强目前还没有压力，实际服务器公平但不一定合理，要合理的话算法会加上服务端当前处理的请求处理的监控、服务器的当前可用资源消耗的监控。
还有一个策略在某些情况下有些客户端请求连续在同一台机器上处理会比较合理，保证数据尽可能在同一台机器处理，相对比较连贯。算法没有绝对好绝对坏，可根据后续定制优化。
再调用端还可以做额外限流，一台订单服务处理一千个请求，或者假设来了一百万但只有十台服务器，会链崩溃，现在就需要限制一下，这就涉及限流问题。
三．负载均衡
(一）Spring Cloud 负载均衡器 Ribbon
1.Spring Cloud 客户端负载均衡器 Ribbon
2.Ribbon 是 Netflix 发布的开源项目
3.Ribbon 主要功能是提供客户端的软件负载均衡算法
4.Ribbon 将 Netflix 的中间层服务连接在一起
5.Ribbon 客户端组件提供许多配置如连接超时，重试等
6.配置文件中列出后台所有机器
7.Ribbon 会自动（如简单轮询，随机连接等）去连接这些机器
8.Spring Cloud 使用 Ribbon 实现自定义的负载均衡算法
（二）Ribbon 负载均衡算法
1. 默认规则：轮询 RoundRobin
2. 简单轮询负载均衡（RoundRobin)
3. 随机负载均衡（Random)随机选择 UP 的Server
4. 加权响应时间负载均衡 WeightedResponseTime
5. 区域感知轮询负载均衡（ZoneAware)
早期公司提供了 Ribbon 组件，主要解决负载均衡算法，负载均衡算法注意默认就是轮询，随机就是保证不了每一台都能调用，在随机次数足够多的情况下出现相对公平，轮询是挨个排，某些外在因素会导致算法不够。Ribbon 常见的算法第一个是 RoundRobin,比较好一点的是加权的。
