转载

『互联网架构』软件架构-zuul微服务网关（上）（100）

不知不觉，文章都写100篇了，从0到1，从1到100，感谢老铁们的支持，不同的微服务一般有不同的网络地址，而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。比如一个电影购票的收集APP,可能回调用电影分类微服务，用户微服务，支付微服务等。

源码：https://github.com/limingios/netFuture/tree/master/源码/『互联网架构』软件架构-zuul微服务网关（上）（100）/

zuul微服务网关

微服务网关产生原因

> 公司内部一致都使用微服务，微服务都是通过doubo这种互相调用了，现在新起来一个项目需要调用电影分类微服务，用户微服务，支付微服务等。

『互联网架构』软件架构-zuul微服务网关（上）（100）

1. 客户端会多次请求不同微服务，增加客户端的复杂性。

2. 存在跨域请求，在一定场景下处理相对复杂。（有的公司服务比较微服务都是通过内部的域名的方式，分类的微服务域名www.idig8.com/type，用户微服务www.idig8.com/user，用户微服务www.idig8.com/pay，这样就不存在跨域的问题。但是大多数公司都是分类的微服务域名type.idig8.com，用户微服务user.idig8.com，用户微服务pay.idig8.com，主流的公司都是通过二级域名来的区分微服务的东西，如果通过ajax进行调用的话，这就涉及到跨域的问题）

3. 认证复杂，每一个服务都需要独立认证。

4. 难以重构，随着项目的迭代，可能需要重新划分微服务，如果客户端直接和微服务通信，那么重构会难以实施。（本身微服务都是拆分的细，拆分的越细越方便重构，对于整体来说是复杂了，但是对于小模块来说业务逻辑少了细了方便重构了。BAT这种大型互联网公司最大的特点就是快，三天两头需求跟这边，一天可能变几次需求，一周可能发布5,6个版本，一个是需求快，快速响应需求，在做新需求的时候需要重构以前写的不好的地方，第一开始设计的系统都是不完美的，真正完美的系统都是通过重构出来的，可能重构很多次，例如上边的图例如果把商品分类微服务拆分了，拆分成商品价格服务，商品基础资料服务，商品分类服务，这样拆分后完蛋了，原来客户端调用一个服务现在调用3,4个服务，它也需要改。）

5. 某些微服务可能使用了其他协议，直接访问有一定困难。（有的服务是http的，有的服务RPC的，也就是需要支持多种协议，也特别麻烦）

都可以借助微服务网管解决。微服务网管是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过微服务网关，架构演变成（其实就是门面的设计模式，统一服务，到达隔离）。

『互联网架构』软件架构-zuul微服务网关（上）（100）

zuul微服务网关

> Zuul是Netflix开源的微服务网关，他可以和Eureka,Ribbon,Hystrix等组件配合使用。Zuul

组件的核心是一系列的过滤器。

官网 https://github.com/Netflix/zuul

『互联网架构』软件架构-zuul微服务网关（上）（100）

1. 动态路由：动态将请求路由到不同后端集群。

2. 压力测试：逐渐增加指向集群的流量，以了解性能。

3. 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。

4. 静态响应处理：边缘位置进行响应，避免转发到内部集群。

5. 身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求。

Spring Cloud对Zuul进行了整合和增强。目前，Zuul使用的默认是Apache的HTTP

Client，也可以使用Rest Client，可以设置ribbon.restclient.enabled=true。

源码：08-ms-gateway-zuul

添加依赖

<dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>

『互联网架构』软件架构-zuul微服务网关（上）（100）

 application.yml

server:
  port: 8040
spring:
  application:
    name: microservice-gateway-zuul
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/
  instance:
    prefer-ip-address: true
management:
  security:
    enabled: false

『互联网架构』软件架构-zuul微服务网关（上）（100）

运行项目(需启动两个用户微服务和一个订单微服务，eureka-server，zuul的项目

1.08-ms-consumer-order-ribbon

2.08-ms-eureka-server

3.08-ms-gateway-zuul

4.08-ms-provider-user

『互联网架构』软件架构-zuul微服务网关（上）（100）

访问尝试： http://127.0.0.1:8040/microservice-consumer-order/user/1

发现zuul会代理所有注册到eureka server的微服务，并使用ribbon做负载均衡，zuul的路由规则如下，可以访问地址：http://localhost:8040/routes

『互联网架构』软件架构-zuul微服务网关（上）（100）

http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**会被转发到serviceId对应的微服务：http://127.0.0.1:8040/microservice-consumer-order/user/1

『互联网架构』软件架构-zuul微服务网关（上）（100）

zuul还自动整合了hystrix。http://localhost:8040/hystrix.stream

『互联网架构』软件架构-zuul微服务网关（上）（100）

PS：目前通过一个zuul的一个api地址只能访问一个服务，但是在实际的生产中，通过访问一个网关需要调用后端的多个微服务，也就是客户端想访问商品的详情的页面，如果是接口的话，我需要访问后端的3个接口，现在使用了zuul我需要的客户端只请求1个api接口，却可以调用后端的3-4个接口，而不是一个一个请求调用。下次咱们一起说说聚合微服务网关。

『互联网架构』软件架构-zuul微服务网关（上）（100）