gateway

网络拓扑图： SPINE1配置 ====================================================== hostname SPINE-1 nv overlay evpn feature ospf feature bgp feature pim feature nv overlay ip pim rp-address 192.168.1.8 group-list 239.0.0.0/24 ip pim log-neighbor-changes ip pim ssm range 232.0.0.0/8 ip pim anycast-rp 192.168.1.8 192.168.1.1 ip pim anycast-rp 192.168.1.8 192.168.1.2 vrf context management interface Ethernet1/1 no switchport ip address 10.10.1.1/30 ip ospf network point-to-point ip router ospf 100 area 0.0.0.0 ip pim sparse-mode no shutdown interface Ethernet1/2 no switchport ip address 10.10.3.1/30 ip ospf

先来看看Nginx 的虚拟机配置 upstream test_app { server 127.0.0.1:5000; } server { listen 127.0.0.1:80; location / { proxy_pass http://test_app; } } 对于nginx的虚拟机配置，正常应该有下面三个东西 upstream ： 指定代理后端应用服务地址 server ： 配置指定主机，端口 location ： 路由指定允许访问的url地址 Istio v1aplha3 路由 API 中的配置资源 v1alpha3引入了以下这些新的配置资源来控制进入网格，网格内部和离开网格的流量路由。 Gateway VirtualService DestinationRule ServiceEntry 跨多个配置资源的控制流程。 Gateway Gateway 用于为 HTTP / TCP 流量配置负载均衡器， Gateway 只用于配置L4-L6功能（例如，对外公开的端口，TLS 配置） Gateway 类似Nginx中的server 配置 类似实例如下： apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway spec: servers: - port:

一 概述 Kong是一个clould-native、快速的、可扩展的、分布式的微服务抽象层（也称为API网关、API中间件或在某些情况下称为服务网格）框架。更确切地说，Kong是一个在Nginx中运行的Lua应用程序，并且可以通过 lua-nginx模块实现 。Kong不是用这个模块编译Nginx，而是与 OpenResty 一起发布， OpenResty 已经包含了lua-nginx-module。OpenResty 不是 Nginx的分支，而是一组扩展其功能的模块。 这为可插拔架构奠定了基础，可以在运行时启用和执行Lua脚本（称为 “插件” ）。因此，我们认为Kong是 微服务架构的典范 ：它的核心是实现数据库抽象，路由和插件管理。插件可以存在于单独的代码库中，并且可以在几行代码中注入到请求生命周期的任何位置。Kong作为开源项目在2015年推出，它的核心价值是高性能和可扩展性。 Kong被广泛用于从初创企业到全球5000家公司以及政府组织的生产环境中。 如果构建Web、移动或IoT（物联网）应用，可能最终需要使用通用的功能来实现这些应用。Kong充当微服务请求的网关（或侧车），通过插件能够提供 负载平衡 、 日志记录、身份验证、速率限制、转换 等能力。 一个service可以创建多个routes，routes就相当于前端配置，可以隐藏业务真正的接口地址

上篇文章 《Eureka 缓存机制》 介绍了Eureka的缓存机制，相信大家对Eureka 有了进一步的了解，本文将详细介绍API网关如何实现服务下线的实时感知。 一、前言 在基于云的微服务应用中，服务实例的网络位置都是动态分配的。而且由于自动伸缩、故障和升级，服务实例会经常动态改变。因此，客户端代码需要使用更加复杂的服务发现机制。 目前服务发现主要有两种模式：客户端发现和服务端发现。 服务端发现：客户端通过负载均衡器向服务注册中心发起请求，负载均衡器查询服务注册中心，将每个请求路由到可用的服务实例上。 客户端发现：客户端负责决定可用服务实例的网络地址，并且在集群中对请求负载均衡, 客户端访问服务登记表，也就是一个可用服务的数据库，然后客户端使用一种负载均衡算法选择一个可用的服务实例然后发起请求。 客户端发现相对于服务端发现最大的区别是：客户端知道（缓存）可用服务注册表信息。如果Client端缓存没能从服务端及时更新的话，可能出现Client 与 服务端缓存数据不一致的情况。 二、网关与Eureka结合使用 Netflix OSS 提供了一个客户端服务发现的好例子。Eureka Server 为注册中心，Zuul 相对于Eureka Server来说是Eureka Client,Zuul 会把 Eureka Server 端服务列表缓存到本地，并以定时任务的形式更新服务列表

https://gitee.com/owenwangwen/open-capacity-platform/tree/master/new-api-gateway package com.open.capacity.client.filter; import java.nio.charset.StandardCharsets; import java.util.List; import java.util.Map; import javax.annotation.Resource; import org.apache.commons.lang3.StringUtils; import org.springframework.cloud.gateway.filter.GatewayFilterChain; import org.springframework.cloud.gateway.filter.GlobalFilter; import org.springframework.core.Ordered; import org.springframework.core.io.buffer.DataBuffer; import org.springframework.data.redis.core.RedisTemplate; import org.springframework