目录
网关分类
开放Api
开放api(openApi) 企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。
微服务网关
微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。 在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。
API服务管理平台
上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。 API网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的API服务管理平台。
网关设计
开放API接口
1、对于OpenAPI使用的API网关来说，一般合作伙伴要以应用的形式接入到OpenAPI平台，合作伙伴需要到 OpenAPI平台申请应用。 因此在OpenAPI网关之外，需要有一个面向合作伙伴的使用的平台用于合作伙伴，这就要求OpenAPI网关需要提供API给这个用户平台进行访问。 如下架构:
当然如果是在简单的场景下，可能并不需要提供一个面向合作伙伴的门户，只需要由公司的运营人员直接添加合作伙伴应用id/密钥等，这种情况下也就不需要合作伙伴门户子系统。
内网API接口
2.对于内网的API网关，在起到的作用上来说可以认为是微服务网关，也可以认为是内网的API服务治理平台。 当企业将所有的应用使用微服务的架构管理起来，那么API网关就起到了微服务网关的作用。 而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理，那么API网关起到的就是API服务治理的作用。 架构参考如下：
3、对于公司内部公网应用（如APP、公司的网站），如果管理上比较细致，在架构上是可能由独立的API网关来处理这部分内部公网应用，如果想比较简单的处理，也可以是使用面向合作伙伴的API网关。 如果使用独立的API网关，有以下的好处：
面向合作伙伴和面向公司主体业务的优先级不一样，不同的API网关可以做到业务影响的隔离。
内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。
内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。
基于以上的分析，如果公司有能力，那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关。
网关框架
目前，比较流行的网关有：Nginx 、 Kong 、Orange等等，还有微服务网关Zuul 、Spring Cloud Gateway等等
对于 API Gateway，常见的选型有基于 Openresty 的 Kong 、基于 Go 的 Tyk 和基于 Java 的 Zuul。这三个选型本身没有什么明显的区别，主要还是看技术栈是否能满足快速应用和二次开发。
网关作用
- 性能：API高可用，负载均衡，容错机制。
- 安全：权限身份认证、脱敏，流量清洗，后端签名（保证全链路可信调用）,黑名单（非法调用的限制）。
- 日志：日志记录（spainid,traceid）一旦涉及分布式，全链路跟踪必不可少。
- 缓存：数据缓存。
- 监控：记录请求响应数据，api耗时分析，性能监控。
- 限流：流量控制，错峰流控，可以定义多种限流规则。
- 灰度：线上灰度部署，可以减小风险。
- 路由：动态路由规则。
Nginx与Zuul的区别
相同点：都可以实现负载均衡、反向代理、过滤请求、实现网关效果
不同点：
Nginx是采用服务器负载均衡进行转发 nginx采用c语言
相对来说Nginx功能比Zuul功能更加强大，能够整合其他语言比如lua脚本实现强大的功能，同时Nginx可以更好的抗高并发。它适合做那种门户网关，是作为整个全局的网关，是对外的，处于最外层的。
Zuul网关更像是业务网关，主要用来对应不同的客户端提供服务的，用于聚合业务的。适合微服务中实现网关。
最好建议nginx+zuul实现网关
Zuul网关
https://github.com/Netflix/zuul
使用Zuul实现反向代理
环境搭建
springcloud-2.0-zuul
Maven依赖信息
| <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.1.RELEASE</version> </parent> <!-- 管理依赖 --> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Finchley.M7</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <!-- SpringBoot整合eureka客户端 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> </dependencies> <!-- 注意： 这里必须要添加， 否者各种依赖有问题 --> <repositories> <repository> <id>spring-milestones</id> <name>Spring Milestones</name> <url>https://repo.spring.io/libs-milestone</url> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories> |
application.properties
###服务启动端口号
server.port= 80
###服务名称(服务注册到eureka名称)
spring.application.name= eureka-client-zuul
###服务注册到eureka地址
eureka.client.service-url.defaultZone= http://localhost:8000/eureka,http://localhost:8001/eureka
eureka.client.register-with-eureka= true
eureka.client.fetch-registry= true
### 配置网关反向代理
### 以 /api-member/访问转发到会员服务
zuul.routes.api-a.path= /api-member/**
zuul.routes.api-a.serviceId= eureka-client-member
### 以 /api-order/访问转发到订单服务
zuul.routes.api-b.path= /api-order/**
zuul.routes.api-b.serviceId= eureka-client-order 启动类
@SpringBootApplication
@EnableEurekaClient
@EnableZuulProxy
public class ZuulApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulApplication.class, args);
}
}
使用Zuul整合Ribbon
Zuul 默认开启了 Ribbon本地负载均衡功能。
Zuul网关负载均衡效果演示
开两个member服务，端口号分别为：9001,9004 通过网关调用两次接口 会出现轮询效果
效果
浏览器直接访问订单项目
通过网关转发请求访问订单项目
网关使用案例
使用zuul过滤器验证客户端是否有登陆
TokenFilter
package com.example.zuul;
import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import org.springframework.stereotype.Component;
import org.springframework.util.StringUtils;
import javax.servlet.http.HttpServletRequest;
@Component
public class TokenFilter extends ZuulFilter {
//过滤类型 pre表示请求之前进行执行 post表示请求之后
@Override
public String filterType() {
return "pre";
}
//过滤器执行顺序
@Override
public int filterOrder() {
return 0;
}
//判断过滤器是否生效
@Override
public boolean shouldFilter() {
return true;
}
//编写过滤器业务逻辑代码
@Override
public Object run() throws ZuulException {
//案例：拦截所有接口，判断接口是否携带usertoken参数
//1.获取上下文
RequestContext requestContent=RequestContext.getCurrentContext();
//2.获取Request
HttpServletRequest request=requestContent.getRequest();
//3.获取token的时候 从请求头获取参数
String userToken=request.getParameter("userToken");
if (StringUtils.isEmpty(userToken)){
// 不会继续执行... 不会去调用服务接口，网关服务直接响应给客户端
requestContent.setResponseStatusCode(401);
requestContent.setSendZuulResponse(false);
requestContent.setResponseBody("userToken is null");
return null;
}
//正常秩序业务逻辑
return null;
}
}
效果：
当请求没有携带token参数时，会返回 userToken is Null的提示。
动态网关
传统方式将路由规则配置在配置文件中，如果路由规则发生了改变，需要重启服务器。这时候我们结合之前整合的SpringCloud Config分布式配置中心，实现动态路由规则。
springCloud Config教程见上一节https://blog.csdn.net/wota5037/article/details/114383940
在之前配置的git仓库上创建一个文件，把配置信息放在里面
Maven依赖信息
新增依赖信息
| <!-- actuator监控中心 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <!-- springcloud config 2.0 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-client</artifactId> </dependency> |
启动类
// zuul配置能够使用config实现实时更新
|
效果
把之前写死的配置注释掉，并启动网关项目，通过网关调用order接口
手动刷新接口
http://127.0.0.1/actuator/refresh
网关集群
Zuul网关集群使用Nginx反向代理即可，保证每台网关配置数据相同。