微服务架构下的问题：
- 安全处理和业务逻辑耦合，增加了复杂性和变更成本
- 随着业务节点增加，认证服务器压力增大
- 多个微服务同时暴露，增加了外部访问的复杂性
1. 微服务环境
实际场景下，类似订单服务的服务，可能有几十个，每个服务是一个集群，有几十个节点，如下图，
1.1 当前微服务架构下的问题
问题1：安全处理和业务逻辑耦合，增加了复杂性和变更成本
在之前的架构中，订单服务 ，同时又是 资源服务器（如下图），订单服务需要知道认证服务器的地址，去校验令牌，通过token转换为用户信息。也就是安全相关的代码，和业务的代码耦合在了一块。虽然可以把这些资源服务器相关代码提成一个jar包，把跟认证相关的代码做成配置，然后每个服务依赖这个jar包，但本质上是没变的，安全相关的代码还是和业务代码在一块。在微服务环境下，解耦是价值最大的，其他的都要为解耦让路。这样耦合在一块，如果你修改了安全相关的代码，那么依赖这个安全的jar包的服务，都要升级这个jar包，在业务代码没变的情况下，因为安全而要修改配置、重新部署，这如果是在一线互联网企业，有几百、上千、上万的微服务环境下，影响面非常大，这样是不能接受的。
问题2：随着业务节点增加，认证服务器压力增大
随着业务场景的变化，之前的10个微服务，可能拆分成20个服务、50个微服务，某些场景下，比如商城有大促，某些服务要做扩缩容，关键的业务节点要部署加倍，这些个微服务都要到认证服务器验token，可能之前认证服务器能撑住原来那么多服务，但是随着服务节点的增多，超过了认证服务器的最大连接数，把认证服务器的连接都占满了，导致认证服务器不可用，所有依赖认证服务器的服务都不可用，导致这些服务都崩掉了，这也是很大的风险。
问题3：多个微服务同时暴露，增加了外部访问的复杂性
客户端直接和各个服务打交道，增加了客户端访问的复杂性
2. 解决方案 —— 网关
上边说的三个问题，都可以在添加网关后解决：
1. 解决安全处理和业务逻辑耦合：获取令牌、校验令牌等，所有跟安全相关的逻辑，都放在了网关上处理，一旦请求过了，订单服务里只有订单相关的业务逻辑。
2. 解决随着业务节点增加，认证服务器压力增大：订单等服务，跟认证服务器没有任何交互，不管各个微服务怎么扩，认证服务器是不受影响的。虽然网关也会扩，但是网关扩缩容的频率和幅度，都远不及各个服务。微服务可能是10到20，20到40的扩容，但是网关可能是2个变4个，4个变8个。网关的扩容幅度和频率，远远小于微服务，再怎么扩，网关的数量是远远小于微服务的。
3. 解决外部访问的复杂性：所有的请求都只和网关打交道，客户端应用只知道一个网关的地址，由网关转发到各个微服务。
2.1 搭建网关
2.2 加入pom.xml依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
<version>2.2.7.RELEASE</version>
</dependency>2.3 yml网关配置
zuul:
routes:
token:
url: http://localhost:9090
order:
url: http://localhost:9080
sensitive-headers:
server:
port: 9070
[点击并拖拽以移动]
这样配置了之后，访问 http://localhost:9070/token/aaa/bbb ，会被转发到 http://localhost:9090/aaa/bbb
访问 http://localhost:9070/token/ccc/ddd ，会被转发到 http://localhost:9060/ccc/ddd
2.4 启动并访问网关
启动类加上 @EnableZuulProxy 注解
分别启动三个服务： this-order-api 、this-security-gateway、is-server-auth（1）现在，客户端访问网关， http://localhost:9070/token/oauth/token ,会被转发到认证服务器（端口9090）的 http://localhost:9090/oauth/token ,来获取令牌，postman实验：
可以成功获取token，说明zuul网关已经帮你把请求转发到了认证服务器9090 。
拿token 访问网关 创建顶单：http://localhost:9070/order/orders
创建成功，说明网关已经将请求转发到了顶单服务。
网关已经初步搭建好了，但是只解决了问题3，客户端访问的复杂性，下面解决两外两个问题。