本文源码：GitHub·点这里 || GitEE·点这里

一、服务网关简介

1、外观模式

客户端与各个业务子系统的通信必须通过一个对立的外观对象进行，外观模式提供一个高层次的接口，使得子系统更易于应用：

简略说一下外观模式，网关和这个模式很像，然而比外观模式简单，模式，构造，准则这些都是通用的，在各种架构或组件中应用。

2、网关简介

微服务网关从感觉上，很像是：拦截器 + 路由 + 过滤器，拦挡申请，系列根底解决，路由转发到指定服务。

服务网关在整个架构体系上也是一个服务器，作为申请的惟一入口，与外观模式非常相似，在网关层解决所有的非业务性能，为客户端提供定制的 API，在网关层通常会执行如下操作：如权限校验、监控、负载平衡、缓存、日志、限流、等等。

二、网关模式

1、模式比照

这里比照罕用的申请服务管理模式，和网关模式，如图：

惯例模式

在没有网关的状况下，微服务架构会在业务层服务上提供一个 API 服务，用来接管参数，例如 Client-API，通常会依据零碎模块划分多个 API，例如，经营零碎，用户零碎等。

• 申请对立进入 Client-API 服务；
• Client-API 通过鉴权，限流，路由等操作；
• 如果申请通过，会转发到相应业务服务上；
• 如果申请被拦挡，会间接返回给客户端；
• Client-API 集成所有业务服务的凋谢接口；

该模式下的毛病非常明显，每个 Client-API 都须要实现一套非业务服务，代码冗余，当零碎收缩之后，保护老本极高，实用于轻量级零碎架构。

网关模式

在业务服务层上，增加一层网关管制，在服务网关中能够实现一系列的横切非业务性能：

• 客户端申请在网关层做对立拦挡；
• 网关上执行：路由 / 鉴权 / 限流 / 降级等操作；
• 网关判断是转发申请还是间接响应客户端；

网关服务层要执行很多非业务流程，作为零碎的服务端惟一入口，接受所有服务的路由转发，平安，限流，缓存，日志，监控，熔断降级等性能，网关服务不仅要做到高可用，还要避免出现性能瓶颈。

2、多重网关

在大型简单的零碎中，通常会对网关做分层治理，把一类业务布局到一个网关下，防止网关过于臃肿，不便保护和治理：

总网关：通用罕用来做路由转发性能；

模块网关 ：分类的业务服务聚合网关，对这类服务的做非业务性操作，最初申请转发到具体服务上，在数据类平台上，通常对数据通道(流入流出) 做一层独立的服务网关；对数据分析类服务做一层独立网关；根本是依据服务的应用状况来划分，这样防止单层服务网关过于简单的状况。

三、外围性能

1、配置层面

服务发现

网关应该有服务发现性能，通过对立注册核心，获取服务列表，这样能力执行对立代理服务和路由转发性能。

路由申请

植入网关层服务之后，客户端不晓得本人申请的是哪个具体的服务，只须要把申请转发给网关，网关放行之后会把申请路由到指定业务服务上。

负载平衡

网关连贯的服务实例可能是集群模式存在，所以网关还能够对各个服务实例上执行负载平衡策略，常见的策略就是服务轮询或者按权重路由。

2、定制开发

定制开发例如：权限校验，日志集成，接口限流，等相干性能，须要和数据库交互，能够做成独立服务，在服务中实现具体的解决逻辑，网关层间接调用即可。

四、网关组件

1、Netflix-Zuul

Zuul 网关次要提供动静路由，监控，弹性，平安管控等性能。在分布式的微服务零碎中，零碎被拆为了多个微服务模块，通过 zuul 网关对用户的申请进行路由，转发到具体的后微服务模块中，Netflix 开源的一个基于 JVM 路由和服务端的负载均衡器。

2、Tyk 组件

Tyk 是一个开源的、轻量级的、疾速可伸缩的 API 网关，反对配额和速度限制，反对认证和数据分析，反对多用户多组织。基于 go 语言编写，在 Java 架构零碎中应用很少。

3、Kong 组件

Kong 是一款基于 Nginx+Lua 编写的高可用，可扩大的开源网关我的项目，由 Mashape 公司凋谢。外围是实现数据库形象，路由和插件治理，插件能够存在于独自的代码库中，并且能够在几行代码中注入到申请生命周期的任何地位。提供易于应用的 RESTfulAPI 来操作和配置 API 治理，并且能够程度扩大多个 Kong 服务器，通过前置的负载平衡配置把申请平均地散发到各个 Server，来应答高并发的网络申请。

五、源代码地址

GitHub·地址
https://github.com/cicadasmile/husky-spring-cloud
GitEE·地址
https://gitee.com/cicadasmile/husky-spring-cloud

举荐浏览：微服务架构