php网站iis设置,美食网站开发目的与意义,网站收录很高,泰安微信网站建设一、API 网关基础 系统拆分为微服务后#xff0c;内部的微服务之间是互联互通的#xff0c;相互之间的访问都是点对点的。如果外部系统想调用系统的某个功能#xff0c;也采取点对点的方式#xff0c;则外部系统会非常“头大”。因为在外部系统看来#xff0c;它不需要也没…一、API 网关基础 系统拆分为微服务后内部的微服务之间是互联互通的相互之间的访问都是点对点的。如果外部系统想调用系统的某个功能也采取点对点的方式则外部系统会非常“头大”。因为在外部系统看来它不需要也没办法理解这么多微服务的职责分工和边界它只会关注它需要的能力而不会关注这个能力应该由哪个微服务提供。 存在跨域请求在一定场景下处理相对复杂 认证复杂每个服务都需要独立认证 难以重构随着项目的迭代可能需要重新划分微服务。例如可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信那么重构将会很难实施 某些微服务可能使用了防火墙 / 浏览器不友好的协议直接访问会有一定的困难 1.网关功能 通过责任链模式基于 Filter 链的方式提供了网关基本的功能例如统一入口 、鉴权、路由、协议转换、缓存、限流、监控、日志。也可以根据实际的业务需要进行扩展但注意不要做耗时操作。
(1)入口网关包括内容 综合上面的分析微服务需要一个统一的 API 网关负责外部系统的访问操作。API 网关是外部系统访问的接口所有的外部系统接⼊系统都需要通过 API 网关主要包括
①路由转发 「API网关」是内部微服务的对外唯一入口所以外面全部的请求都会先发到这个「API网关」上然后由「API网关」来根据不同的请求去路由到不同的微服务节点上。例如可以 根据路径 来转发、也可以 根据参数 来转发。 并且由于内部微服务实例也会随着业务调整不停的变更增加或者删除节点「API网关」可以与「服务注册」模块进行协同工作保证将外部请求转发到最合适的微服务实例上面去。 服务路由和服务发现紧密相关服务路由一般不会设计成一个独立运行的系统通常情况下是和服务发现放在一起实现的。对于自理式服务发现服务路由是微服务内部实现的对于代理式服务发现服务路由是由 LOAD BALANCER 系统实现的。无论放在哪里实现服务路由核心的功能就是路由算法。常见的路由算法有随机路由、轮询路由、最小压力路由、最小连接数路由等。 负载均衡、本地路由优先等路由策略可以满足大部分场景但是一些场景需要对路由策略设置一些过滤条件。比较常用的是 条件路由规则 黑白名单 流量引导只暴漏部分服务提供者将异常峰值流量导流到几台服务器上防止生产系统雪崩 读写分离 前后台分离 灰度升级将应用路由到新的服务版本按照手机号设备ip等规则路由到不同的集群环境 脚本路由规则。 ②负载均衡/限流 既然「API网关」是内部微服务的单一入口所以「API网关」在收到外部请求之后还可以根据内部微服务每个实例的负荷情况进行动态的负载均衡调节。一旦内部的某个微服务实例负载很高甚至是不能及时响应则「API网关」就通过负载均衡策略减少或停止向这个实例转发请求。当所有的内部微服务实例都处理不过来的时候「API网关」还可以采用限流或熔断的形式阻止外部请求以保障整个系统的可用性。 ③安全认证
「API网关」就像是微服务的大门守卫每一个请求进来之后都必须先在「API网关」上进行身份验证身份验证通过后才转发给后面的服务转发的时候一般也会带上身份信息。同时「API网关」也需要对每一个请求进行安全性检查例如参数的安全性、传输的安全性等等。 ④日志记录 既然所有的请求都需要走「API网关」那么我们就可以在「API网关」上统一集中的记录下这些行为日志。这些日志既可以作为我们后续事件查询使用也可以作为系统的性能监控使用。 ⑤数据转换 因为「API网关」对外是面向多种不同的客户端不同的客户端所传输的数据类型可能是不一样的。因此「API网关」还需要具备数据转换的功能将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上这样兼容了这些请求的多样性保证了微服务的灵活性。
⑥黑白名单相关
比如针对设备 ID、用户 IP、用户 ID 等维度的黑白名单 ⑦服务注册 为了能够代理后面的服务并把请求路由到正确的位置上网关应该有服务注册功能也就是后端的服务实例可以把其提供服务的地址注册、取消注册。一般来说注册也就是注册一些 API 接口。比如HTTP 的 Restful 请求可以注册相应 API 的 URI、方法、HTTP 头。这样Gateway 就可以根据接收到的请求中的信息来决定路由到哪一个后端的服务上。 ⑧弹力设计 网关还可以把弹力设计中的那些异步、重试、幂等、流控、熔断、监视等都可以实现进去。这样同样可以像 Service Mesh 那样让应用服务只关心自己的业务逻辑或是说数据面上的事而不是控制逻辑控制面。 (2)出口网关 在系统开发中会依赖很多外部的第三方系 统比如典型的例子第三方账户登录、使用第三方工具支付等等。可以在应用服务器 和第三方系统之间部署出口网关在出口网关中对调用外部的 API 做统一的认证、授 权审计以及访问控制。 2.网关优点 安全 只有网关系统对外进行暴露微服务可以隐藏在内网通过防火墙保护。 易于监控。可以在网关收集监控数据并将其推送到外部系统进行分析。 易于认证。可以在网关上进行认证然后再将请求转发到后端的微服务而无须在每个微服务中进行认证。 减少了客户端与各个微服务之间的交互次数 易于统一授权。 3.网关关注点
(1)设计重点 性能API 入口网关承担从 客户端的所有流量。假如业务服务处理时间是 10ms而 API 网关的耗时在 1ms那么相当于每个接口的响应时间都要增加 10%这对于性能的影响无疑是巨大的。而提升 API 网 关性能的关键还是在 I/O 模型上。 扩展性也就是可以随时在网关的执行链路上增加一些逻辑也可以随时下掉一些逻辑也就是所谓的热插拔。所以一般来说可以把每一个操作定义为一个 filter过滤器然后使用“责任链模 式”将这些 filter 串起来。责任链可以动态地组织这些 filter解耦 filter 之间的关系无论是增加还是减少 filter都不会对其他的 filter 有任何的影响。Zuul 就是采用责任链模式Zuul1 中将 filter 定义为三类pre routing filter路由前过 滤器、routing filter路由过滤器和 after routing filter路由后过滤器。每一个 filter 定义了执行的顺序在 filter 注册时会按照顺序插入到 filter chain过滤器链 中。这样 Zuul 在接收到请求时就会按照顺序依次执行插入到 filter chain 中的 filter 了。 业务松耦合协议紧耦合 。在业务设计上网关不应与后面的服务之间形成服务耦合也不应该有业务逻辑。网关应该是在网络应用层上的组件不应该处理通讯协议体只应该解析和处理通讯协议头。另外除了服务发现外网关不应该有第三方服务的依赖。 应用监视提供分析数据 。网关上需要考虑应用性能的监控除了有相应后端服务的高可用的统计之外还需要使用 Tracing ID 实施分布式链路跟踪并统计好一定时间内每个 API 的吞吐量、响应时间和返回码以便启动弹力设计中的相应策略。 用弹力设计保护后端服务 。网关上一定要实现熔断、限流、重试和超时等弹力设计。如果一个或多个服务调用花费的时间过长那么可接受超时并返回一部分数据或是返回一个网关里的缓存的上一次成功请求的数据。你可以考虑一下这样的设计。 DevOps 。因为网关这个组件太关键了所以需要 DevOps 这样的东西将其发生故障的概率降到最低。这个软件需要经过精良的测试包括功能和性能的测试还有浸泡测试。还需要有一系列自动化运维的管控工具。 可用性因为所有的流量或调用经过网关所以网关必须成为一个高可用的技术组件它的稳定直接关系到了所有服务的稳定。网关如果没有设计就会成变一个单点故障。因此一个好的网关至少要做到以下几点。 集群化 。网关要成为一个集群其最好可以自己组成一个集群并可以自己同步集群数据而不需要依赖于一个第三方系统来同步数据 服务化 。网关还需要做到在不间断的情况下修改配置一种是像 Nginx reload 配置那样可以做到不停服务另一种是最好做到服务化。也就是说得要有自己的 Admin API 来在运行时修改自己的配置。 持续化 。比如重启就是像 Nginx 那样优雅地重启。有一个主管请求分发的主进程。当我们需要重启时新的请求被分配到新的进程中而老的进程处理完正在处理的请求后就退出。 (2)注意事项 不要在网关中的代码里内置聚合后端服务的功能而应考虑将聚合服务放在网关核心代码之外。可以使用 Plugin 的方式也可以放在网关后面形成一个 Serverless 服务。 网关应该靠近后端服务并和后端服务使用同一个内网这样可以保证网关和后端服务调用的低延迟并可以减少很多网络上的问题。这里多说一句网关处理的静态内容应该靠近用户应该放到 CDN 上而网关和此时的动态服务应该靠近后端服务。 网关也需要做容量扩展所以需要成为一个集群来分担前端带来的流量。这一点要么通过 DNS 轮询的方式实现要么通过 CDN 来做流量调度或者通过更为底层的性能更高的负载均衡设备。 对于服务发现可以做一个时间不长的缓存这样不需要每次请求都去查一下相关的服务所在的地方。当然如果你的系统不复杂可以考虑把服务发现的功能直接集成进网关中。 为网关考虑 bulkhead 设计方式。用不同的网关服务不同的后端服务或是用不同的网关服务前端不同的客户。
另外因为网关是为用户请求和后端服务的桥接装置所以需要考虑一些安全方面的事宜。具体如下 加密数据 。可以把 SSL 相关的证书放到网关上由网关做统一的 SSL 传输管理。 校验用户的请求 。一些基本的用户验证可以放在网关上来做比如用户是否已登录用户请求中的 token 是否合法等。但是我们需要权衡一下网关是否需要校验用户的输入。因为这样一来网关就需要从只关心协议头到需要关心协议体。而协议体中的东西一方面不像协议头是标准的另一方面解析协议体还要耗费大量的运行时间从而降低网关的性能。对此我想说的是看具体需求一方面如果协议体是标准的那么可以干另一方面对于解析协议所带来的性能问题需要做相应的隔离。 检测异常访问 。网关需要检测一些异常访问比如在一段比较短的时间内请求次数超过一定数值还比如同一客户端的 4xx 请求出错率太高……对于这样的一些请求访问网关一方面要把这样的请求屏蔽掉另一方面需要发出警告有可能会是一些比较重大的安全问题如被黑客攻击。 二、网关选型
1.网关分类
(1)流量网关 对于一个服务集群势必有很多非法的请求或者无效的请求这时候要将请求拒之门外降低集群的流量压力。 定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是上图所示的架构模型——流量网关。流量网关通常只专注于全局的Api管理策略比如全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等有点类似防火墙。Kong 就是典型的流量网关。业务网关一般部署在流量网关之后、业务系统之前比流量网关更靠近业务系统。通常API网指的是业务网关。有时候我们也会模糊流量网关和业务网关让一个网关承担所有的工作所以这两者之间并没有严格的界线。
(2)业务网关 当一个单体应用被拆分成许许多多的微服务应用后也带来了一些问题。一些与业务非强相关的功能比如权限控制、日志输出、数据加密、熔断限流等每个微服务应用都需要因此存在着大量重复的代码实现。而且由于系统的迭代、人员的更替各个微服务中这些功能的实现细节出现了较大的差异导致维护成本变高。另一方面原先单体应用下非常容易做的接口管理在服务拆分后没有了一个集中管理的地方无法统计已存在哪些接口、接口定义是什么、运行状态如何。 网关就是为了解决上述问题。作为微服务体系中的核心基础设施一般需要具备接口管理、协议适配、熔断限流、安全防护等功能各种开源的网关产品比如 zuul都提供了优秀高可扩展性的架构、可以很方便的实现我们需要的一些功能、比如鉴权、日志监控、熔断限流等。与流量网关相对应的就是业务网关业务网关更靠近我们的业务也就是与服务器应用层打交道那么有很多应用层需要考虑的事情就可以依托业务网关例如在线程模型、协议适配、熔断限流服务编排等。下面看看业务网关体系结构: 目前业务网关比较成熟的 API 网关框架产品有三个 分别是:Zuul1、Zuul2 和 SpringCloud Gateway 后面再进行对比。 2.常见网关对比 目前常见的开源网关大致上按照语言分类有如下几类 Nginxlua OpenResty、Kong、Orange、Abtesting gateway 等 Java Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等 Go Janus、fagongzi、Grpc-gateway Dotnet Ocelot NodeJS Express Gateway、Micro Gateway
按照使用数量、成熟度等来划分主流的有 5个 OpenResty Kong Zuul、Zuul2 Spring Cloud Gateway
(1)OpenResty OpenResty是一个流量网关OpenResty基于 Nginx与 Lua 的高性能 Web 平台其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。 通过揉和众多设计良好的 Nginx 模块OpenResty 有效地把 Nginx 服务器转变为一个强大的 Web 应用服务器基于它开发人员可以使用 Lua 编程语言对 Nginx 核心以及现有的各种 Nginx C 模块进行脚本编程构建出可以处理一万以上并发请求的极端高性能的 Web 应用 OpenResty 最早是顺应 OpenAPI 的潮流做的所以 Open 取自“开放”之意而Resty便是 REST 风格的意思。虽然后来也可以基于 ngx_openresty 实现任何形式的 web service 或者传统的 web 应用。
也就是说 Nginx 不再是一个简单的静态网页服务器也不再是一个简单的反向代理了。第二代的 openresty 致力于通过一系列 nginx 模块把nginx扩展为全功能的 web 应用服务器。
ngx_openresty 是用户驱动的项目后来也有不少国内用户的参与从 openresty.org 的点击量分布上看国内和国外的点击量基本持平。
ngx_openresty 目前有两大应用目标 通用目的的 web 应用服务器。在这个目标下现有的 web 应用技术都可以算是和 OpenResty 或多或少有些类似比如 Nodejs PHP 等等。ngx_openresty 的性能包括内存使用和 CPU 效率算是最大的卖点之一。 Nginx 的脚本扩展编程用于构建灵活的 Web 应用网关和 Web 应用防火墙。有些类似的是 NetScaler。其优势在于 Lua 编程带来的巨大灵活性。 (2)Kong_性能最高 Kong基于OpenResty开发也是流量层网关 是一个云原生、快速、可扩展、分布式的Api 网关。继承了OpenResty的高性能、易扩展性等特点。Kong通过简单的增加机器节点可以很容易的水平扩展。同时功能插件化可通过插件来扩展其能力。而且在任何基础架构上都可以运行。具有以下特性 提供了多样化的认证层来保护Api。 可对出入流量进行管制。 提供了可视化的流量检查、监视分析Api。 能够及时的转换请求和相应。 提供log解决方案 可通过api调用Serverless 函数。
Kong解决了什么问题
当我们决定对应用进行微服务改造时应用客户端如何与微服务交互的问题也随之而来毕竟服务数量的增加会直接导致部署授权、负载均衡、通信管理、分析和改变的难度增加。
面对以上问题API GATEWAY是一个不错的解决方案其所提供的访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能可以解放开发者去把精力集中在具体逻辑的代码而不是把时间花费在考虑如何解决应用和其他微服务链接的问题上。 (3)Zuul1.0 Zuul是所有从设备和web站点到Netflix流媒体应用程序后端请求的前门。作为一个边缘服务应用程序Zuul被构建来支持动态路由、监视、弹性和安全性。它还可以根据需要将请求路由到多个Amazon自动伸缩组。Zuul使用了一系列不同类型的过滤器使我们能够快速灵活地将功能应用到服务中。
过滤器
过滤器是Zuul的核心功能。它们负责应用程序的业务逻辑可以执行各种任务。 Type 通常定义过滤器应用在哪个阶段 Async 定义过滤器是同步还是异步 Execution Order 执行顺序 Criteria 过滤器执行的条件 Action 如果条件满足过滤器执行的动作
Zuul提供了一个动态读取、编译和运行这些过滤器的框架。过滤器之间不直接通信而是通过每个请求特有的RequestContext共享状态。
下面是Zuul的一些过滤器: Incoming.Incoming过滤器在请求被代理到Origin之前执行。这通常是执行大部分业务逻辑的地方。例如:认证、动态路由、速率限制、DDoS保护、指标。 Endpoint.Endpoint过滤器负责基于incoming过滤器的执行来处理请求。Zuul有一个内置的过滤器ProxyEndpoint用于将请求代理到后端服务器因此这些过滤器的典型用途是用于静态端点。例如:健康检查响应静态错误响应404响应。 Outgoing.Outgoing过滤器在从后端接收到响应以后执行处理操作。通常情况下它们更多地用于形成响应和添加指标而不是用于任何繁重的工作。例如:存储统计信息、添加/剥离标准标题、向实时流发送事件、gziping响应。
过滤器类型
下面是与一个请求典型的生命周期对应的标准的过滤器类型 PRE 路由到Origin之前执行 ROUTING 路由到Origin期间执行 POST 请求被路由到Origin之后执行 ERROR 发生错误的时候执行
这些过滤器帮助我们执行以下功能 身份验证和安全性 识别每个资源的身份验证需求并拒绝不满足它们的请求 监控 在边缘跟踪有意义的数据和统计数据以便给我们一个准确的生产视图 动态路由 动态路由请求到不同的后端集群 压力测试 逐渐增加集群的流量以评估性能 限流 为每种请求类型分配容量并丢弃超过限制的请求 静态响应处理 直接在边缘构建一些响应而不是将它们转发到内部集群
Zuul 1.0 请求生命周期 Netflix宣布了通用API网关Zuul的架构转型。Zuul原本采用同步阻塞架构转型后叫作Zuul2采用异步非阻塞架构。Zuul2和Zuul1在架构方面的主要区别在于Zuul2运行在异步非阻塞的框架上比如Netty。Zuul1依赖多线程来支持吞吐量的增长而Zuul 2使用的Netty框架依赖事件循环和回调函数。 (4)Zuul2.0 上图是Zuul2的架构和Zuul1没有本质区别两点变化 前端用Netty Server代替Servlet目的是支持前端异步。后端用Netty Client代替Http Client目的是支持后端异步。 过滤器换了一下名字用Inbound Filters代替Pre-routing Filters用Endpoint Filter代替Routing Filter用Outbound Filters代替Post-routing Filters。
Inbound Filters 路由到 Origin 之前执行可以用于身份验证、路由和装饰请求
Endpoint Filters 可用于返回静态响应否则内置的ProxyEndpoint过滤器将请求路由到Origin
Outbound Filters 从Origin那里获取响应后执行可以用于度量、装饰用户的响应或添加自定义header
有两种类型的过滤器sync 和 async。因为Zuul是运行在一个事件循环之上的因此从来不要在过滤中阻塞。如果你非要阻塞可以在一个异步过滤器中这样做并且在一个单独的线程池上运行否则可以使用同步过滤器。
上文提到过Zuul2开始采用了异步模型
优势 是异步非阻塞模式启动的线程很少基本上一个CPU core上只需启一个事件环处理线程它使用的线程资源就很少上下文切换(Context Switch)开销也少。非阻塞模式可以接受的连接数大大增加可以简单理解为请求来了只需要进队列这个队列的容量可以设得很大只要不超时队列中的请求都会被依次处理。
不足 异步模式让编程模型变得复杂。一方面Zuul2本身的代码要比Zuul1复杂很多Zuul1的代码比较容易看懂Zuul2的代码看起来就比较费劲。另一方面异步模型没有一个明确清晰的请求-处理-响应执行流程(call flow)它的流程是通过事件触发的请求处理的流程随时可能被切换断开内部实现要通过一些关联id机制才能把整个执行流再串联起来这就给开发调试运维引入了很多复杂性比如你在IDE里头调试异步请求流就非常困难。另外ThreadLocal机制在这种异步模式下就不能简单工作因为只有一个事件环线程不是每个请求一个线程也就没有线程局部的概念所以对于CAT这种依赖于ThreadLocal才能工作的监控工具调用链埋点就不好搞(实际可以工作但需要进行特殊处理)。
总体上异步非阻塞模式比较适用于IO密集型(IO bound)场景这种场景下系统大部分时间在处理IOCPU计算比较轻少量事件环线程就能处理。
Netflix给出了一个比较模糊的数据大致Zuul2的性能比Zuul1好20%左右 这里的性能主要指每节点每秒处理的请求数。为什么说模糊呢因为这个数据受实际测试环境流量场景模式等众多因素影响你很难复现这个测试数据。即便这个20%的性能提升是确实的其实这个性能提升也并不大和异步引入的复杂性相比这20%的提升是否值得是个问题。Netflix本身在其博文22和ppt11中也是有点含糊其词甚至自身都有一些疑问的。 (5)Spring Cloud Gateway
SpringCloud Gateway 是 Spring Cloud 的一个全新项目该项目是基于 Spring 5.0Spring Boot 2.0 和 Project Reactor 等技术开发的网关它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
SpringCloud Gateway 作为 Spring Cloud 生态系统中的网关目标是替代 Zuul在Spring Cloud 2.0以上版本中没有对新版本的Zuul 2.0以上最新高性能版本进行集成仍然还是使用的Zuul 2.0之前的非Reactor模式的老版本。而为了提升网关的性能SpringCloud Gateway是基于WebFlux框架实现的而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway 的目标不仅提供统一的路由方式并且基于 Filter 链的方式提供了网关基本的功能例如安全监控/指标和限流。
Spring Cloud Gateway 底层使用了高性能的通信框架Netty 。
SpringCloud Gateway 特征
SpringCloud官方对SpringCloud Gateway 特征介绍如下 基于 Spring Framework 5Project Reactor 和 Spring Boot 2.0 集成 Hystrix 断路器 集成 Spring Cloud DiscoveryClient Predicates 和 Filters 作用于特定路由易于编写的 Predicates 和 Filters 具备一些网关的高级功能动态路由、限流、路径重写
从以上的特征来说和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别还是在底层的通信框架上。
简单说明一下上文中的三个术语
Filter 过滤器
和Zuul的过滤器在概念上类似可以使用它拦截和修改请求并且对上游的响应进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
Route 路由
网关配置的基本组成模块和Zuul的路由配置模块类似。一个Route模块 由一个 ID一个目标 URI一组断言和一组过滤器定义。如果断言为真则路由匹配目标URI会被访问。
Predicate 断言
这是一个 Java 8 的 Predicate可以使用它来匹配来自 HTTP 请求的任何内容例如 headers 或参数。断言的 输入类型是一个 ServerWebExchange。
