0602-Zuul构建API Gateway-Zuul Http Client、cookie、header

1、Zuul Http Client

　　zuul使用的默认HTTP客户端如今由Apache HTTP Client支持，而不是已弃用的Ribbon RestClient。要使用RestClient或使用okhttp3.OkHttpClient，请分别设置ribbon.restclient.enabled = true或ribbon.okhttp.enabled = true。若是您想定制Apache HTTP客户端或OK HTTP客户端提供ClosableHttpClient或OkHttpClient类型的Bean。

2、Cookies和敏感header头

2.一、基础使用

　　在同一个系统中的服务之间共享header是能够的，但你可能不但愿敏感的header向下游泄漏到外部服务器中。您能够指定一个忽略的header列表做为路由配置的一部分。Cookie扮演着特殊的角色，由于他们在浏览器中具备明肯定义的语义，而且始终将其视为敏感。若是代理的用户是浏览器，那么下游服务的cookie也会给用户带来问题，由于它们都混乱了（全部下游服务看起来都是来自同一个地方）。

　　若是您对服务的设计很是当心，例如，若是只有一个下游服务设置了cookie，那么您可能会让它们从后端一路流向调用者。另外，若是您的代理设置了Cookie而且全部后端服务都属于同一个系统，那么简单地共享它们（例如使用Spring Session将它们连接到某个共享状态）多是很天然的。除此以外，任何由下游服务设置的cookie均可能对调用者不是颇有用，所以建议您将（至少）“Set-Cookie”和“Cookie”制做为不属于您的域的路由的敏感header。即便对于属于您的域名的路由，也要尽可能仔细考虑它们在容许Cookie与代理之间流动以前的含义。

　　敏感header能够配置为每一个路由以逗号分隔的列表，例如，

 zuul:
  routes:
    users:
      path: /myusers/**
      sensitiveHeaders: Cookie,Set-Cookie,Authorization
      url: https://downstream

其中sensitiveHeaders：未传递到下游请求的敏感header列表。默认为一般包含用户凭据的一组“安全”的报头。若是下游服务是与代理相同的系统的一部分，那么它们就能够从列表中删除这些文件，所以它们正在共享认证数据。若是在本身的域以外使用物理URL，那么一般泄漏用户凭据将是一个坏主意。

注意：这是sensitiveHeaders的默认值，因此你不须要设置它，除非你想让它不一样。注：这是Spring Cloud Netflix 1.1中的新功能（在1.0中，用户没法控制header和全部cookie在两个方向上流动）。

2.二、空header

sensitiveHeaders是一个黑名单，默认不是空的，因此为了让Zuul发送全部的头文件（除了“被忽略”的头文件），你必须明确地将它设置为空列表。

 zuul:
  routes:
    users:
      path: /myusers/**
      sensitiveHeaders:
      url: https://downstream

敏感header也能够经过设置zuul.sensitiveHeaders进行全局设置。若是sensitiveHeaders在路由上设置，这将覆盖全局sensitiveHeaders设置。

2.三、忽略header

　　除了每一个路由敏感报头以外，您还能够为zuul.ignoredHeaders设置一个全局值，以便在与下游服务交互期间应丢弃的值（包括请求和响应）。默认状况下，若是Spring Security不在类路径中，它们是空的，不然它们被初始化为Spring Security指定的一组众所周知的“安全”头文件（例如涉及缓存）。在这种状况下，假设下游服务可能也会添加这些header，而且咱们须要来自代理的值。为了避免丢弃这些众所周知的安全性头文件，以防Spring Security在类路径中，您能够将zuul.ignoreSecurityHeaders设置为false。若是您在Spring Security中禁用了HTTP安全响应头而且须要下游服务提供的值，这会颇有用

3、Manager Endpoint

若是您在Spring Boot Actuator中使用@EnableZuulProxy，您将启用（默认状况下）两个附加端点：

• Routes
• Filters

注意：关闭验证或者开启：management.security.enabled=false

3.一、Routes Endpoint

　　GET / routes路由端点将返回映射路由列表：

{
  /stores/**: "http://localhost:8081"
}

能够经过将？format = details查询字符串添加到/ routes来请求其余路由详细信息。这将产生如下输出：GET /routes?format=details. 

{
  "/stores/**": {
    "id": "stores",
    "fullPath": "/stores/**",
    "location": "http://localhost:8081",
    "path": "/**",
    "prefix": "/stores",
    "retryable": false,
    "customSensitiveHeaders": false,
    "prefixStripped": true
  }
}

POST将强制刷新现有routes（例如，若是服务目录中有更改）。您能够经过将endpoints.routes.enabled设置为false来禁用此端点。

注意：路由应该自动响应服务目录中的更改，但POST /路由是强制更改当即发生的一种方式。

3.二、Filters Endpoint

GET / filters中的过滤器端点将按类型返回Zuul过滤器的映射。对于地图中的每种过滤器类型，您能够找到该类型的全部过滤器的列表及其详细信息。

4、绞杀者模式和本地转发

绞杀者模式：参看博客https://martinfowler.com/bliki/StranglerApplication.html

　　迁移现有应用程序或API时常见的模式是“扼杀”旧的端点，并慢慢地用不一样的实现替换它们。Zuul代理是一个有用的工具，由于您可使用它来处理来自旧端点客户端的全部流量，但会将某些请求重定向到新端点。

application.yml. 

zuul:
  routes:
    first:
      path: /first/**
      url: http://first.example.com
    second:
      path: /second/**
      url: forward:/second
    third:
      path: /third/**
      url: forward:/3rd
    legacy:
      path: /**
      url: http://legacy.example.com

　　在这个例子中，咱们扼杀了映射到与其余模式不匹配的全部请求的“遗留”应用程序。/ first / **中的路径已被提取到具备外部URL的新服务中。而且/ second / **路径被转发，以便它们能够在本地处理，例如，与一个正常的Spring @RequestMapping。/ third / **中的路径也被转发，但具备不一样的前缀（即/ third / foo被转发到/ 3rd / foo）。

　　被忽略的模式不会被彻底忽略，它们只是不被代理处理（因此它们也被有效地本地转发）。