微服务—网关

简介：除了服务内部直接互相调用通讯之外，还需要让外界访问的到，比如手机，客户端之类，那就需要某种机制将后退服务暴露出去。所有的外部请求都会先经过API网关这一层。服务网关是连接内（服务内部）外（客户端）的大门。常用的网关有Zuul，Gateway（性能更佳），Nginx。 情景：为什么随着微服务的出现API网关也出现了，原因是不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的API才能完成一个业务需求。一个微服务写的好与不好，不需要其他内容，只需要看服务网关构建的怎么样就知道了。如果让客户端直接与各个微服务通信，会有以下的问题：

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

二.存在跨域请求，每个服务都需要独立认证（跨域处理）。 这里提一嘴：URI是统一资源定位符，用来定义网络信息资源的。URI分为URL和URN URL相比于URN做到了不仅仅是标识资源，还做到了告知访问资源的方式，例如http协议，而URN则没有。

三.认证(登陆权限校验等）复杂，每个服务都需要独立认证。（http是无状态的，没有记录用户信息理想状态下session和cookie标识了用户，登陆成功后返回1个session存入内存，下次登陆会从内存中把这个session以cookie的形式发到服务器端验证，但在分布式情况下不共享主内存，所以session无法做到同步，在这样的场景下，网关就出现了，我们可以把每个服务的认证都到网关里去做认证，认证完成后网关把请求发送给相应的服务。总而言之就是认证不仅仅是你登陆账号，而是你在登陆账号后它会记录你的信息。 认证的方式有很多种，安全认证与鉴权在伦敦的微服务大会上提出了四种方案如下：

单点登录（SSO） 这种方案意味着每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，当动辄数十个微应用时，这种方案的弊端会更加明显。分布式 Session 方案 分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。在某些场景下，这种方案很不错，用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性了。客户端 Token 方案 令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等客户端 Token 与 API 网关结合 这个方案意味着所有请求都通过网关，从而有效地隐藏了微服务。 在请求时，网关将原始用户令牌转换为内部会话 ID 令牌。在这种情况下，注销就不是问题，因为网关可以在注销时撤销用户的令牌 ）

四.难以重构，随着项目的迭代，可能需要（例如优化项目）重新划分微服务。例如可能将多个微服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。

五.某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问困难。

所以综上所述，服务网关对于微服务而已是必不可少的！！！

说了这么多，网关到底能做到什么，我分为以下几点：

1.可以屏蔽掉后台服务的细节，后台服务需要升级或修改，对外让用户无感知

2.路由（接受请求并转发就是路由）功能，可以将外部的请求反向路由（代理是相对的，客户端代理服务器端就是反向）到具体的某个微服务

3限流和容错，意思是所有的请求都会经过网关，在网关内部进行处理限流和容错

4监控和日志

5安全 用户认证，授权，反爬虫等 可以看到网关层是最外层，是客户端与服务器交互式经过的第一个服务节点，它主要用来屏蔽下游业务服务，对于客户端而言，只需要跟网关交互就相当于在于下游多个业务服务节点交互。从而让客户端有一种只在和一台服务器交互的感觉。 这样的好处显而易见，不管是下游业务服务、支持服务 、基础服务，客户端只与网关交互，从而使客户端与服务端交互变的非常简单。客户端无需关心各个节点间的依赖关系、如何协同工作。客户端只会了解到本次请求是否成功。开发者可以灵活的添加业务服务模块，可以在网关层做一些最上层的公共的操作，如过滤恶意请求、设置IP黑名单、做身份认证、限流、负载均衡等。API的实现方面更多的考虑业务逻辑，而安全、性能、监控可以交由API网关来做，这样既提高业务灵活性又不缺少安全性。各司其职，事半功倍。

使用API网关的优点如下：

1易于监控：可以在网关收集监控数据并将其推送到外部系统进行分析。 2易于认证：可以在网关上进行认证，然后再将其转发到后端的微服务，而无需在每个微服务中进行认证。 3减少了客户端与各个微服务之间的交互次数。

说了这么多 我们来初步认识其中两种比较典型的网关Zuul和Gateway

Zuul基于java和groovy，一共有两代分别是Zuul 1.x 和 Zuul 2.x 源码: 官方链接. 核心： ZuulFilter（过滤器）调用链 Zuul用户（开发者）只需要关系如何定义ZuulFilter以及它们之间的顺序，最后解决问题 底层：打开源码，可以看到Servlet，Zuul处理的是Http请求。 注意点：Zuul可以扩展至其他微服务框架中，其内部没有实现限流，负载均衡，Zuul二代支持异步 适用场景：小型微服务架构或复杂架构（非springCloud体系dubbo等），Zuul是一个不错的选择

Zuul实现高可用（集群）：

Gateway对比Zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、复杂均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件 优点： 1.Gateway很好的支持异步 2.Gateway具有更好的扩展性、稳定性。

总结：

在微服务架构中网关上的选择，最好的方式是使用现在比较成熟的Spring Cloud套件，其提供了Spring Cloud Gateway网关，或是结合公司情况来自主研发一套适合自己的微服务套件，至少从网关上可以看到其内部实现并不难。Zuul相对于Gateway它的兼容性更高，可以使用非Spring Cloud体系，而Gateway仅支持Spring Cloud套件