泉州seo网站管理,网站的作用和意义,网站制作一薇,网页界面制作步骤API网关是微服务项目的重要组成部分#xff0c;今天来聊聊API网关的技术选型#xff0c;有理论#xff0c;有实战。
不 BB#xff0c;上文章目录#xff1a; 1 API网关基础
1.1 什么是API网关
API网关是一个服务器#xff0c;是系统的唯一入口。 从面向对象设计的角度…API网关是微服务项目的重要组成部分今天来聊聊API网关的技术选型有理论有实战。
不 BB上文章目录 1 API网关基础
1.1 什么是API网关
API网关是一个服务器是系统的唯一入口。 从面向对象设计的角度看它与外观模式类似。
API网关封装了系统内部架构为每个客户端提供一个定制的API。它可能还具有其它职责如身份验证、监控、负载均衡、缓存、协议转换、限流熔断、静态响应处理。
API网关方式的核心要点是所有的客户端和消费端都通过统一的网关接入微服务在网关层处理所有的非业务功能。通常网关也是提供REST/HTTP的访问API。 这或许是一个对你有用的开源项目mall项目是一套基于 SpringBoot Vue uni-app 实现的电商系统Github标星60K采用Docker容器化部署后端支持多模块和微服务架构。包括前台商城项目和后台管理系统能支持完整的订单流程涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能 Boot项目https://github.com/macrozheng/mall Cloud项目https://github.com/macrozheng/mall-swarm 视频教程https://www.macrozheng.com/video/ 后台管理系统演示 前台商城项目演示 1.2 网关的主要功能
微服务网关作为微服务后端服务的统一入口它可以统筹管理后端服务主要分为数据平面和控制平面 数据平面主要功能是接入用户的HTTP请求和微服务被拆分后的聚合。使用微服务网关统一对外暴露后端服务的API和契约路由和过滤功能正是网关的核心能力模块。另外微服务网关可以实现拦截机制和专注跨横切面的功能包括协议转换、安全认证、熔断限流、灰度发布、日志管理、流量监控等。 控制平面主要功能是对后端服务做统一的管控和配置管理。例如可以控制网关的弹性伸缩可以统一下发配置可以对网关服务添加标签可以在微服务网关上通过配置Swagger功能统一将后端服务的API契约暴露给使用方完成文档服务提高工作效率和降低沟通成本。 路由功能路由是微服务网关的核心能力。通过路由功能微服务网关可以将请求转发到目标微服务。在微服务架构中网关可以结合注册中心的动态服务发现实现对后端服务的发现调用方只需要知道网关对外暴露的服务API就可以透明地访问后端微服务。 负载均衡API网关结合负载均衡技术利用Eureka或者Consul等服务发现工具通过轮询、指定权重、IP地址哈希等机制实现下游服务的负载均衡。 统一鉴权一般而言无论对内网还是外网的接口都需要做用户身份认证而用户认证在一些规模较大的系统中都会采用统一的单点登录Single Sign On系统如果每个微服务都要对接单点登录系统那么显然比较浪费资源且开发效率低。API网关是统一管理安全性的绝佳场所可以将认证的部分抽取到网关层微服务系统无须关注认证的逻辑只关注自身业务即可。 协议转换API网关的一大作用在于构建异构系统API网关作为单一入口通过协议转换整合后台基于REST、AMQP、Dubbo等不同风格和实现技术的微服务面向Web Mobile、开放平台等特定客户端提供统一服务。 指标监控网关可以统计后端服务的请求次数并且可以实时地更新当前的流量健康状态可以对URL粒度的服务进行延迟统计也可以使用Hystrix Dashboard查看后端服务的流量状态及是否有熔断发生。 限流熔断在某些场景下需要控制客户端的访问次数和访问频率一些高并发系统有时还会有限流的需求。在网关上可以配置一个阈值当请求数超过阈值时就直接返回错误而不继续访问后台服务。当出现流量洪峰或者后端服务出现延迟或故障时网关能够主动进行熔断保护后端服务并保持前端用户体验良好。 黑白名单微服务网关可以使用系统黑名单过滤HTTP请求特征拦截异常客户端的请求例如DDoS攻击等侵蚀带宽或资源迫使服务中断等行为可以在网关层面进行拦截过滤。比较常见的拦截策略是根据IP地址增加黑名单。在存在鉴权管理的路由服务中可以通过设置白名单跳过鉴权管理而直接访问后端服务资源。 灰度发布微服务网关可以根据HTTP请求中的特殊标记和后端服务列表元数据标识进行流量控制实现在用户无感知的情况下完成灰度发布。 流量染色和灰度发布的原理相似网关可以根据HTTP请求的Host、Head、Agent等标识对请求进行染色有了网关的流量染色功能我们可以对服务后续的调用链路进行跟踪对服务延迟及服务运行状况进行进一步的链路分析。 文档中心网关结合Swagger可以将后端的微服务暴露给网关网关作为统一的入口给接口的使用方提供查看后端服务的API规范不需要知道每一个后端微服务的Swagger地址这样网关起到了对后端API聚合的效果。 日志审计微服务网关可以作为统一的日志记录和收集器对服务URL粒度的日志请求信息和响应信息进行拦截。
2 API网关选型
2.1 常用API网关
先简单看一下市面上常用的API网关 Nginx
Nginx是一个高性能的HTTP和反向代理服务器。Nginx一方面可以做反向代理另外一方面可以做静态资源服务器接口使用Lua动态语言可以完成灵活的定制功能。
Nginx 在启动后会有一个 Master 进程和多个 Worker 进程Master 进程和 Worker 进程之间是通过进程间通信进行交互的如图所示。Worker 工作进程的阻塞点是在像 select()、epoll_wait() 等这样的 I/O 多路复用函数调用处以等待发生数据可读 / 写事件。Nginx 采用了异步非阻塞的方式来处理请求也就是说Nginx 是可以同时处理成千上万个请求的。
Zuul
Zuul 是 Netflix 开源的一个API网关组件它可以和 Eureka、Ribbon、Hystrix 等组件配合使用。社区活跃融合于 SpringCloud 完整生态是构建微服务体系前置网关服务的最佳选型之一。
Zuul 的核心是一系列的过滤器这些过滤器可以完成以下功能 统一鉴权 动态路由 负载均衡 压力测试 审查与监控与边缘位置追踪有意义的数据和统计结果从而带来精确的生产视图。 多区域弹性跨越 AWS Region 进行请求路由旨在实现 ELBElastic Load Balancing弹性负载均衡使用的多样化以及让系统的边缘更贴近系统的使用者。
Zuul 目前有两个大的版本Zuul1 和 Zuul2
Zuul1 是基于 Servlet 框架构建如图所示采用的是阻塞和多线程方式即一个线程处理一次连接请求这种方式在内部延迟严重、设备故障较多情况下会引起存活的连接增多和线程增加的情况发生。 Netflix 发布的 Zuul2 有重大的更新它运行在异步和无阻塞框架上每个 CPU 核一个线程处理所有的请求和响应请求和响应的生命周期是通过事件和回调来处理的这种方式减少了线程数量因此开销较小。 Spring Cloud GateWay
Spring Cloud Gateway 是Spring Cloud的一个全新的API网关项目目的是为了替换掉Zuul1它基于Spring5.0 SpringBoot2.0 WebFlux基于⾼性能的Reactor模式响应式通信框架Netty异步⾮阻塞模型等技术开发性能⾼于Zuul官⽅测试Spring Cloud GateWay是Zuul的1.6倍旨在为微服务架构提供⼀种简单有效的统⼀的API路由管理⽅式。
Spring Cloud Gateway可以与Spring Cloud Discovery Client如Eureka、Ribbon、Hystrix等组件配合使用实现路由转发、负载均衡、熔断、鉴权、路径重写、⽇志监控等并且Gateway还内置了限流过滤器实现了限流的功能。 Kong
Kong是一款基于OpenRestyNginx Lua模块编写的高可用、易扩展的由Mashape公司开源的API Gateway项目。Kong是基于NGINX和Apache Cassandra或PostgreSQL构建的能提供易于使用的RESTful API来操作和配置API管理系统所以它可以水平扩展多个Kong服务器通过前置的负载均衡配置把请求均匀地分发到各个Server来应对大批量的网络请求。 Kong主要有三个组件 Kong Server 基于Nginx的服务器用来接收API请求。 Apache Cassandra/PostgreSQL 用来存储操作数据。 Kong dashboard官方推荐UI管理工具也可以使用 restfull 方式管理admin api。
Kong采用插件机制进行功能定制插件集可以是0或N个在API请求响应循环的生命周期中被执行。插件使用Lua编写目前已有几个基础功能HTTP基本认证、密钥认证、CORSCross-Origin Resource Sharing跨域资源共享、TCP、UDP、文件日志、API请求限流、请求转发以及Nginx监控。 Kong网关具有以下的特性 可扩展性: 通过简单地添加更多的服务器可以轻松地进行横向扩展这意味着您的平台可以在一个较低负载的情况下处理任何请求 模块化: 可以通过添加新的插件进行扩展这些插件可以通过RESTful Admin API轻松配置 在任何基础架构上运行: Kong网关可以在任何地方都能运行。您可以在云或内部网络环境中部署Kong包括单个或多个数据中心设置以及publicprivate 或invite-only APIs。
Traefik
Træfɪk 是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。 重要特性 它非常快无需安装其他依赖通过Go语言编写的单一可执行文件 多种后台支持Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd 支持支持Rest API、Websocket、HTTP/2、Docker镜像 监听后台变化进而自动化应用新的配置文件设置 配置文件热更新无需重启进程 后端断路器、负载均衡、容错机制 清爽的前端页面可监控服务指标。 关于Traefik的更多内容可以查看官网https://traefik.cn/ 2.2 API网关对比 上面是网关对比截图偷个懒大家主要关注Kong、Traefik和Zuul即可 从开源社区活跃度来看无疑是Kong和Traefik较好 从成熟度来看较好的是Kong、Tyk、Traefik 从性能来看Kong要比其他几个领先一些 从架构优势的扩展性来看Kong、Tyk有丰富的插件Ambassador也有插件但不多而Zuul是完全需要自研但Zuul由于与Spring Cloud深度集成使用度也很高近年来Istio服务网格的流行Ambassador因为能够和Istio无缝集成也是相当大的优势。
下面是其它网友的思考结论可供参考 性能NginxLua形式必然是高于Java语言实现的网关的Java技术栈里面Zuul1.0是基于Servlet实现的剩下都是基于webflux实现性能是高于基于Servlet实现的。在性能方面我觉得选择网关可能不算那么重要多加几台机器就可以搞定。 可维护性和扩展性NginxLua这个组合掌握的人不算多如果团队有大神大佬们就随意了当没看到这段话对于一般团队来说的话选择自己团队擅长的语言更重要。Java技术栈下的3种网关对于Zuul和Spring Cloud Getway需要或多或少要搞一些集成和配置页面来维护但是对于Soul我就无脑看看文章需要哪个搬哪个好了尤其是可以无脑对接Dubbo美滋滋此外Soul2.0以后版本可以摆脱ZK在我心里再无诟病我就喜欢无脑操作。 高可用对于网关高可用基本都是统一的策略都是采用多机器部署的方式前面挂一个负载对于而外需要用的一些组件大家注意一下。
3 基于Traefik自研的微服务网关
这个是我司自研的微服务网关基于Traefik进行开发下面从技术选型、网关框架、网关后台、协议转换进行讲解绝对干货
3.1 技术栈选型 Traefik一款开源的反向代理与负载均衡工具它最大的优点是能够与常见的微服务系统直接整合可以实现自动化动态配置。traefik较为轻量非常易于使用和设置性能比较好已在全球范围内用于生产环境。 Etcd一个Go言编写的分布式、高可用的一致性键值存储系统用于提供可靠的分布式键值存储、配置共享和服务发现等功能。更多内容可以查看文章 肝了一个月的ETCD从Raft原理到实践 Go并发能力强性能媲美C处理能力是PHP的4倍效率高语法简单易上手开发效率接近PHP。 3.3 网关框架
整个网关框架分为3块 网关后台hal-fe和hal-admin用于应用、服务和插件的配置然后将配置信息发布到ETCD Traefik读取ETCD配置根据配置信息对请求进行路由分发如果需要鉴权会直接通过hal-agent模块进行统一鉴权。鉴权完毕后如果是Http请求直接打到下游服务如果是Grpc和Thrift协议会通过hal-proxy模块进行协议转换。 协议转换模块读取ETCD配置对Traefik分发过来的请求进行Grpc和Thrift协议转换更多内容可以查看文章 RPC框架从原理到选型一文带你搞懂RPC并通过服务发现机制获取服务下游机器并通过负载均衡将转换后的数据打到下游服务机器。 3.4 网关后台
主要由3大模块组成 应用主要包括应用名、域名、路径前缀、所属组、状态等比如印度海外商城、印度社区 服务主要包括服务名、注册方式、协议类型、所属组、状态等比如评论服务、地址服务、搜索服务。 插件主要包括插件名称、插件类型、插件属性配置等比如路径前缀替换插件、鉴权插件。 一个应用只能绑定一个服务但是可以绑定多个插件。 通过后台完成网关配置后将这些配置信息生成Config文件发布到ETCD中Config文件需要遵循严格的数据格式比如Traefix配置需要遵循官方的文件配置格式才能被Traefik识别。 3.5 协议转换模块
hal-proxy模块是整个微服务网关最复杂也是技术含量最高的模块所以给大家详细讲解一下。
问题引入
在讲这个模块前我们先看下面几个问题 当请求从上游的trafik过来时需要知道访问下游的机器IP和端口才能将请求发送给下游这些机器如何获取呢 有了机器后我们需要和下游机器建立连接如果连接用一次就直接释放肯定对服务会造成很大的压力这就需要引入Client缓存池那这个Client缓存池我们又该如何实现呢 最后就是需要对协议进行转换因为不同的下游服务支持的协议类型是不一样的这个网关又是如何动态支持的呢 实现原理 我们还是先看一下hal-proxy内部有哪些模块首先是Resolver模块这个模块的是什么作用呢这里我简单介绍一下目前公司内部通过服务获取到机器列表的方式有多种比如MIS平台、服务树等也就是有的是通过平台配置的有的是直接挂在服务树下无论哪种方式我们都通过服务名通过一定的方式找到该服务下面所有的主机。
所以Resolver模块的作用其实就是通过服务名找到该服务下的所有机器的IP和服务端口然后持久化到内存中并定时更新。
协议模块就是支持不同的协议转换每个协议类型的转换都需要单独实现这些协议转换无非就是先通过机器IP和端口初始化Client然后再将数据进行转换后直接发送到下游的机器。
最后就是连接池之前我们其实也用到go自带的pool来做但是当对pool数据进行更新时需要加锁所以性能一直起不来后来改成了环形队列然后对数据的操作全部通过原子操作方式就实现了无锁操作大大提高的并发性能。
实现逻辑
这个是hal-proxy的逻辑实现图画了2天包含所有核心对象的交互方式这里就不去细讲能掌握多少靠大家自己领悟。
