向大佬们学习的第二天 2020.4.16-4.17

微服务（二）

Feign 声明式客户端

Feign是NetFlix开发的声明式、模板化的HTTP客户端，用于更便捷、优雅地调用HTTP API。
SpringCould对Feign进行了增强，使Feign支持Spring MVC注解、整合了Ribbon和Eureka，让Feign使用更方便
可能是刚开始接触微服务的关系、我对用Rest Template 或 Feign框架 的感触不深，只是说Rest Template相对比较单一和基础、Feign在Http请求的基础上新增了很多功能，包括Ribbon负载均衡、Eureka注册中心

zuul 服务网关

首先我们来看一下在没有Zuul 服务网关之前的微服务架构

使用Eureka作为服务注册中心、来进行服务端和客户端服务注册与发现，而服务之间通过Ribbon和Fegin实现负载均衡和服务消费，通过spring could config进行外部化配置中心，用Hystrix熔断机制避免微服务架构中部分服务故障导致的蔓延。
这样架构存在的不足：
破坏了服务的无状态特点，如果我们要实现对服务的访问权限控制、而开放服务的权限控制机制将贯穿并污染整个开放服务的业务逻辑，破坏服务集群的RESTAPI无状态特点
无法直接复用既有的Client接口，实现外部访问时，不能不在原有接口的基础上，添加校验逻辑。
因此、这里引入 服务网关 Zuul
可以通过服务网关，将业务组件中的权限控制、日志打印等通用东西从我们的业务组件中抽出去，放到访问请求的最前端
Zuul是Netflix开源发微服务网关，核心是一系列的过滤器
特征：
身份认证与安全：识别每个资源的验证，拒绝不符合的要求
审查与监控
动态路由：动态地将请求路由到不同的后端路由
压力测试；
负载分配：可以和Nginx配合使用
静态响应处理：在边缘位置直接建立部分响应，避免其转发到内部集群

在用户请求服务之前，会先通过Zuul服务网关，通过Zuul进行一系列认证校验或者逻辑校验、通过后转发到后端服务，所以后端微服务只需要关注业务逻辑即可，当然也就可以直接复用。
用Nginx进行转发的话：

Zuul中最重要的就是过滤器：ZuulFliter
ZuulFilter是一个抽象类，其实现类需要实现4个方法：

shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
run：过滤器的具体业务逻辑。
filterType：返回字符串代表过滤器的类型
a)pre：请求在被路由之前执行
b)routing：在路由请求时调用
c)post：在routing和errror过滤器之后调用
d)error：处理请求时发生错误调用
filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

Config 分布式配置中心

为什么不把各自的配置文件放到各自的项目中，而要把他们抽出来进行分布式配置，统一进行管理？
假如说：项目已经启动，而数据库服务器的IP地址突然变了，这个时候是不是只能重启服务器了？
假如说：我有多个项目的配置文件都要变了，是不是每个项目都需要重启然后才能搞定？
Spring Could Config 为分布式系统外部化配置提供了服务端和客户端的支持，包括Config Server 和 Config Client。
Config Server 是一个可横向扩展、集中式的配置服务器，它用于集中管理应用程序各个环境下的配置，默认使用Git存储配置文件内容，也可以用SVN、本地存储、GitHub等
Config Client 是 客户端，用于操作存储在Config Server中的配置内容，微服务在启动的时候会去请求Config Server获取到配置文件，然后把它们注入到容器中，启动容器。

虽然使用了分布式的配置，每个Config Client 业务服务在启动的时候都去调用你的Config Server获取配置信息，但是当你改变Server中配置信息的时候，Client是不会自动更新的，所以在需要用到actuator，调用actuator的refresh请求，可以刷新Client中的配置信息。这里又可以通过git中的钩子（Web Hook），在每次更新Server配置的时候动态去调用actuator中的refresh请求。
但问题又来了，如果Client非常多，一个一个请求的去刷新好像也不是个事，所有这里可用通过消息总线（Spring could Bus）消息队列的方法去实现。
具体RabbitMQ的内容在下一章节展开