第九篇Java技术分享-网关调研

前文：
redis高可用集群于上周已经用两种方式搭建并测试成功，奈何最近工作强度太大，只能这周末尽量放出了～
正文：
这篇是邀我师傅的稿子，属于网关调研类文档(原创)～，大家有不错的文章后台可以署名发给我哦～

网关调研
API Gateway/Backend for Front-End作为一种目前非常流行并且经过验证的Pattern，不论是在 Netflix/Amazon还是BAT都得到了广泛的应用。在Microservice architecture pattern大行其道的 当下，API Gateway的建设显得尤为重要。

Gateway的核心功能如下:
强悍的负载均衡能力; 支持动态服务管理服务，最好能跟服务发现结合在一起; 持故障控制:健康检查、限流、熔断、重试; 详细的监控指标(比如支持 Prometheus); 日志聚合(其实这个应该说是基本功能);
附加功能:
支持分布式追踪，支持 Opentracing; 金丝雀发布，灰度发布，A/B 测试; 统一认证:JWT，OAuth，Basic auth 等; HTTP 缓存; 请求、返回内容的显示以及修改; 请求限制:机器人检测、黑白 IP 名单;
业界开源的方案有:
Kong/kong:基于 OpenResty 那一套做的，依赖于 Nginx 强悍的性能，添加了动态服务管理功 能，以及插件机制，语言是 lua ，假如自己拓展需要学习新语言
TykTechnologies/tyk:用 Golang 实现的网关，如果团队使用 Golang 技术栈，可以考虑下; Netflix/zuul:用 Java 实现的网关，目前看来只适合 Java 技术栈
其中前两个是目前用得比较广泛的，这两者几乎就是市场的老大与老二了

Kong
版本:2.0.4
kong是Mashape 在openresty基础上进行的开发，而openresty基于nginx，所以kong的很多概念和用法都有nginx特色，包括对功能进行描述的词汇，比如upstream services就是nginx设定的upstream。 Kong 主要有三个组件:
Kong Server :基于nginx的服务器，用来接收 API 请求。
Apache Cassandra/PostgreSQL:用来存储操作数据。
Kong dashboard:官方推荐 UI 管理工具，当然，也可以使用 restfull 方式管理 admin api。

核心概念理解
Routes:请求的转发规则，按照 Hostname 和PATH，将请求转发给 Service;(相当于nginx 配 置中的location)
Services:多个 Upstream 的集合，是 Route 的转发目标;(eg: 理解nginx 配置文件中server) Upstream:上游对象用来表示虚拟主机名，拥有多个服务(目标)时，会对请求进行负载均衡 Target:最终处理请求的 Backend 服务。
Consumers:API 的用户，记录用户信息; Plugin:插件，可以是全局的，也可以绑定到 Service、Router 或者 Consumer; Certificate:https 配置的证书;

install in docker
以下命令kong数据、配置文件、插件并未挂载到本地，仅限测试使用

konga kong-dashboard
这里以konga为例介绍一下安装使用
docker network create kong-net
#创建数据库容器
docker run -d --name kong-database \
--network=kong-net \
-p 5432:5432 \
-e "POSTGRES_USER=kong" \
-e "POSTGRES_DB=kong" \
-e "POSTGRES_PASSWORD=kong" \ postgres:9.6
#初始化数据库，注意替换内网IP docker run --rm \
--network=kong-net \
-e "KONG_DATABASE=postgres" \
-e "KONG_PG_HOST=192.168.0.3" \
-e "KONG_PG_PASSWORD=kong" \ kong:latest kong migrations bootstrap
#启动kong容器，注意替换内网IP docker run -d --name kong \
--network=kong-net \
-e "KONG_DATABASE=postgres" \
-e "KONG_PG_HOST=192.168.0.3" \
-e "KONG_PG_PASSWORD=kong" \
-e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
-e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
-e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
-e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
-e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \ -p 8000:8000 \
-p 8443:8443 \
-p 8001:8001 \
-p 8444:8444 \
kong:latest

install in k8s
待补充

管理Kong
Kong分为开源和商业两个版本，开源版本并没有提供UI管理系统，但是提供了丰富且强大的API，开发 人员可以通过API管理我们的网关。但是大多数情况下，通过UI操作还是更为便捷，这里有几个常用管 理系统:

1.konga
2.kong-dashboard

这里以konga为例介绍一下安装使用

#初始化konga数据库，注意替换内网IP

docker run --rm pantsel/konga:latest -c prepare -a postgres -u postgresql://kong:kong@192.168.0.3:5432/konga
#启动konga容器注意替换内网IP
docker run -d
-p 1337:1337 \
--network kong-net \
-e "DB_ADAPTER=postgres" \
-e "DB_URI=postgresql://kong:kong@192.168.0.3:5432/konga" \ -e "NODE_ENV=production" \
--name konga \
pantsel/konga

安装完成之后需要创建账号

然后添加kong的地址信息

然后可以看到首页的数据图

接下来可以新建一个服务让我们访问kong的根目录可以路由到kong-admin-api


接下来点击列表中的kong-admin-api，切换到Routes标签页创建映射路径，这里有一点需要注意:在 设置Hosts、Paths、Methods、Protocols字段后需要回车才可以应用设置的内容


整合服务发现 DNS轮训发现
指定DNS的Kong只能通过Consul获取服务实例?

准备好consul之后，kong在启动时需要指定consul的dns地址，添加-e "KONG_DNS_RESOLVER=ip:port参数
所有的服务实例注册到consul后，在Kong中创建的Service以服务名.service.consul作为Host，之后 所有转发到此Service的请求都会负载到这个服务的实例上。

从Eurka同步实例 具体参考:048-使用Kong替换Zuul(从Eureka同步列表)
插件
Kong拥有丰富的插件体系，自带的插件就能满足绝大部分常见的需求，支持熔断、限流、日志、指 标、链路追踪、认证等等，并且支持自己开发插件，不过开发语言是Lua，需要一定的学习成本，具体 可以参考Plugin Development - Introduction。

Zuul

Zuul 是 Netflix 开源的微服务网关组件，它可以和 Eureka、Ribbon、Hystrix 等组件配合使用。社区活 跃，融合于 SpringCloud 完整生态。
Zuul使用了一系列不同类型的过滤器，使我们能够快速灵活地将功能应用到服务中。

Zuul 1.0的生命周期

Zuul 2.0的生命周期

Zuul 基于JVM的路由器和服务器端负载均衡器。同时， Zuul 的规则引擎允许规则和过滤器基本上用任 何JVM语言编写，内置支持 Java 和 Groovy 。这个功能，就可以实现动态路由的功能了。当需要添加某 个新的对外服务时，一般上不停机更新是通过数据缓存配置或者使用 Groovy 进行动态路由的添加的。
集成服务发现
对于Zuul来讲，Spring Cloud做了很好的包装，可以说开箱即用。
Zuul可以再没有配置路径映射关系的情况下，会使用被调用服务的Eureka service ID并将其映射 到其中一个目标服务实例
也可以自定义路径-服务关系
我们在配置路径-服务映射关系的时候，只需要指定定义的spring.application.name即可。

手动配置
如果没有集成注册中心的话，也可以在配置文件中指定服务完整路径:
但是，问题又来了，因为这样的配置会绕过eureka，这就导致请求都会指向单个路由，那么当 organization服务有多个怎么办?怎么利用Ribbon来实现服务均衡?有两种做法:

#这种实现方法需要Ribbon禁用eureka。禁用后会有一个问题，就是其他注册到eureka的服务无法通过网关 访问，需要手动自己配置.listOfServers属性。


对于非Java语言开发的服务来讲，想要使用Zuul转发，除了上面两种方式以外，还有两个办法:
使用一个独立的zuul服务专门转发那些其它语言的服务
创建Spring Cloud Sidecar实例(推荐使用这种)，Spring Cloud sidecar允许注册其它语言实现 的服务到eureka，然后就可以通过zuul代理了，可以参考Polyglot support with Sidecar
其他功能
对于网关很需要的限流、日志、指标、认证等其他功能，都需要自己去实现。 从上面也能看出，Zuul的缺点很明显，就是只支持Java体系的服务，而且Spring Cloud官方不会集成Zuul 2.0
对比
对于Kong来讲，很多人不选它的理由只有一个: 不会lua编程，二次开发不方便。实际上，这都不是问 题。一方面，lua语言很简单，花一两天看看cookbook就会了;另一方面kong社区活跃，用户量大，无 论是官方插件，还是第三方插件，都非常丰富，很少直接二次开发，即便有一点特殊需求，也可以找到 类似的插件
如果对网关的稳定性和性能要求不是很高，反而是对扩展性有较高要求，则目前建议临时用zuul，并等 待zuul2.0和spring cloud gateway的成熟。

参考文章
微服务设计模式之API 网关
使用Kong在生产环境替代Eureka+Zuul+Hystrix 服务网关——Spring Cloud Zuul