So far the process has been achieved (as shown below) OAuth2-based authentication and authorization, order, or a single node, it has not yet entered into the micro-environment services.
Under the actual scenario, similar to the service order service, there may be dozens, each service is a cluster, there are dozens of nodes, as shown below,
In this scenario, the current problem of micro-services architecture:
Question 1: Security processing and business logic coupling, adds to the complexity and cost of change
In the previous architecture, service orders, but it is also a resource server (as shown below), service orders need to know the address of the authentication server to verify the token, the user information is converted into token. That is code for safety-related codes, and coupling in a piece of business. Although these server resources relevant code commission a jar package, the code associated with the authentication configuration is made, then each service depends on the jar package, but the essence is not changed, and security-related code or a business code . In the micro-service environment, the value of decoupling is the largest, the other must make way for the decoupling. Such a coupling, if you modify the security-related code, then the dependent services that secure the jar package, should upgrade the jar package, in the case of business code has not changed because of safety and to modify the configuration, redeploy, If this is the first-line Internet companies, there are hundreds, thousands, tens of thousands of micro-under service environment, the impact is very large, this is unacceptable.
Question 2: With the increase of service node, the authentication server pressure increases
As business scene 10 before the micro service, the service may be split into 20 and 50 micro-services, in some scenarios, such as a large store promotion, some services do scalable capacity, critical business to deploy a node doubles these micro services to the authentication server must experience token, before the authentication server may be able to shore up the original so much service, but with the increase in service node, exceeding the maximum number of connections authentication server, the authentication server connections are filled, leading to the authentication server is unavailable, the authentication server all dependent services are not available, these services are leading to collapse out, and this is a big risk.
Question 3: Multiple simultaneous exposure to micro-services, increasing the complexity of external access
Clients directly and deal with the various services, increases the complexity of client access
Add the Gateway:
He said the top three issues can be resolved after the addition of the gateway:
1，解决安全处理和业务逻辑耦合：获取令牌、校验令牌等，所有跟安全相关的逻辑，都放在了网关上处理，一旦请求过了，订单服务里只有顶单相关的业务逻辑。
2，解决随着业务节点增加，认证服务器压力增大：顶单等服务，跟认证服务器没有任何交互，不管各个微服务怎么扩，认证服务器是不受影响的。虽然网管也会扩，但是网关扩缩容的频率和幅度，都远不及各个服务。微服务可能是10到20，20到40的扩容，但是网关可能是2个变4个，4个变8个。网关的扩容幅度和频率，远远小于微服务，再怎么扩，网关的数量是远远小于微服务的。
3，解决外部访问的复杂性：所有的请求都只和网关打交道，客户端应用只知道一个网关的地址，由网关转发到各个微服务。
搭建Zuul网关
新建项目：nb-server-gateway
pom加入zuul依赖:
<!-- 网飞的zuul网关 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>
网关端口：9070
yml网关配置
这样配置了之后，访问 http://localhost:9070/token/aaa/bbb ，会被转发到 http://localhost:9090/aaa/bbb
访问 http://localhost:9070/token/ccc/ddd ，会被转发到 http://localhost:9060/ccc/ddd
启动类加上 @EnableZuulProxy 注解
分别启动三个服务：
现在，客户端访问网关， http://localhost:9070/token/oauth/token ,会被转发到认证服务器（端口9090）的 http://localhost:9090/oauth/token ,来获取令牌，postman实验：
可以成功获取token，说明zuul网关已经帮你把请求转发到了认证服务器9090 。
拿token 访问网关 创建顶单：http://localhost:9070/order/orders
创建成功，说明网关已经将请求转发到了顶单服务。
网关已经初步搭建好了，但是只解决了问题3，客户端访问的复杂性，下面解决两外两个问题。
代码github:https://github.com/lhy1234/springcloud-security/tree/chapt-4-8-gateway01