网页前端技术,深圳营销型网站建设优化,物流网站建设方案范文,设计排版优秀网站目前随着云原生ServiceMesh和微服务架构的不断演进#xff0c;网关领域新产品不断出现#xff0c;各种网关使用的技术#xff0c;功能和应用领域也不断扩展#xff0c;在各有所长的前提下也有很多功能重合#xff0c;网上各种技术PR文章#xff0c;评测资料和网关落地实践…目前随着云原生ServiceMesh和微服务架构的不断演进网关领域新产品不断出现各种网关使用的技术功能和应用领域也不断扩展在各有所长的前提下也有很多功能重合网上各种技术PR文章评测资料和网关落地实践很多都有自己的立场和业务场景很难客观判断各种网关技术的优缺点和适合场景。 本文从技术实现角度对各种网关分分类同时尽量理清各种网关的概念和适用场景其实很难分清楚方便大家进行讨论和决策 网关技术的演进 https://higress.io/zh-cn/docs/overview/what-is-higress 各网关github贡献者情况的变化目前云原生网关是大趋势 https://git-contributor.com/?chartcontributorOverTimerepoapache/apisix,solo-io/gloo,kong/kong,tyktechnologies/tyk,openresty/openresty,envoyproxy/envoy,istio/istio,apache/shenyu,spring-cloud/spring-cloud-gateway 网关按照技术实现分类
基于Nginx Lua的网关 网关githubGithub starsIssue closed项目开始时间贡献者数量社区活跃度OpenRestyhttps://github.com/openresty/openresty11.5k447201229一般KONGhttps://github.com/Kong/kong35.7k39552015322高APISIXhttps://api7.ai/12.4k39702019386高 Nginx 是一个高性能的 HTTP 和反向代理 web 服务器同时也提供了 IMAP/POP3/SMTP 服务。Nginx 是由伊戈尔·赛索耶夫为俄罗斯访问量第二的 http://Rambler.ru 站点俄文Рамблер开发的第一个公开版本0.1.0发布于2004年10月4日。 作为 Web 服务器相比 ApacheNginx 使用更少的资源支持更多的并发连接体现更高的效率这点使 Nginx 尤其受到虚拟主机提供商的欢迎。能够支持高达 50,000 个并发连接数的响应Nginx 选择了 epoll and kqueue 作为开发模型. OpenResty(®) 是一个基于 Nginx 与 Lua 的高性能 Web 平台其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。 OpenResty(®) 通过汇聚各种设计精良的 Nginx 模块主要由 OpenResty 团队自主开发从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。这样Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块快速构造出足以胜任 10K 乃至 1000K 以上单机并发连接的高性能 Web 应用系统。 OpenResty® 的目标是让你的Web服务直接跑在 Nginx 服务内部充分利用 Nginx 的非阻塞 I/O 模型不仅仅对 HTTP 客户端请求,甚至于对远程后端诸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都进行一致的高性能响应。 Kong 是 API 管理的强大效率工具。对需要从事 API 管理的广大开发员来说它是最出色的工具之一。Kong 是开源工具具有可扩展性和模块性可以在任何一种基础设施上运行。多年来Kong 一直在支持优秀的开发项目比如 Mashape世界上规模最大的API市场。最棒的是Kong得到了强大的 Nginx 的支持。Kong or Kong API Gateway is a cloud-native, platform-agnostic, scalable API Gateway distinguished for its high performance and extensibility via plugins. By providing functionality for proxying, routing, load balancing, health checking, authentication (and more), Kong serves as the central layer for orchestrating microservices or conventional API traffic with ease. Apache APISIX 是一个动态、实时、高性能的云原生 API 网关。它构建于 NGINX ngx_lua 的技术基础之上充分利用了 LuaJIT 所提供的强大性能。 为什么 Apache APISIX 选择 NGINXLua 技术栈。 国产开源的API网关 2019 年左右开始研发的 APISIX 核心包括 Lua 插件、多语言插件运行时Plugin Runner、Wasm 插件运行时等 功能丰富的各种内置插件包括可观测性、安全、流量控制等。 APISIX 在其核心中提供了路由匹配、负载均衡、服务发现、API 管理等重要功能以及配置管理等基础性模块。除此之外APISIX 插件运行时也包含其中提供原生 Lua 插件的运行框架和多语言插件的运行框架以及实验性的 Wasm 插件运行时等。APISIX 多语言插件运行时提供多种开发语言的支持比如 Golang、Java、Python、JS 等。 APISIX 目前也内置了各类插件覆盖了 API 网关的各种领域如认证鉴权、安全、可观测性、流量管理、多协议接入等。当前 APISIX 内置的插件使用原生 Lua 实现关于各个插件的介绍与使用方式可以查看相关插件文档。 为什么 Apache APISIX 是最好的 API 网关 以 Nginx 为内核的网关比较成熟的选择是 Kong 运行相对稳定性能也比 Java 异步化网关好不少。Kong 作为相对传统的 API 网关直接作为容器化环境中的网关需要不少额外工作包括对 Kubernetes 基于 ETCD 注册中心的纳管和稳定运行为生产业务的架构升级带来不少额外的开发、维护负担。 APISIX性能比KONG好支持的插件和功能更多对云原生支持更好国产开源本地化适配比较好但没有KONG稳定。 API7企业版在APISIX基础上增加了RBAC审计日志流量标签SOAP协议支持等企业级特性通过了 GDPR, FIPS等合规审计支持全生命周期管理集成了API设计工具和API门户。
基于Java Netty的异步化网关
Spring Cloud Gateway Apache Shenyu Netflix Zuul1、Zuul2
网关githubstarsClosed issues开始时间Spring Cloud Gatewayhttps://github.com/spring-cloud/spring-cloud-gateway4.1k19242017Apache Shenyuhttps://github.com/apache/shenyu/issues8k19012019Netflix Zuulhttps://github.com/Netflix/zuul12.8k10382013 Java 异步化网关的典型代表是 Spring Cloud 系列的 Zuul 2.x 和 Spring Cloud Gateway 好处是基于 Java 语言开发有 Spring Cloud 项目作为参考自研实现、扩展、维护容易适合以 Java 为核心语言栈的团队“折腾”缺点是 Java 语言本身在异步效率、内存回收等性能方面难以与传统代理软件匹敌在大规模流量场景下有明显的性能瓶颈。 基于云原生技术的网关 Service Mesh 架构包括东西向使用 Sidecar 做服务治理同时还有一个基于 IstioEnvoy 的 Gateway 负责做跨集群之间的流量互通。如果选择 Envoy 作为网关后续就有可能跟 Service Mesh 整合成一个大的流量调度方案从长远来看这是更有利于未来向统一应用架构技术栈演进的选择。开源 Istio Envoy目前业界比较流行的方案 Istio 服务网格从逻辑上分为数据平面和控制平面。
数据平面 由一组智能代理Envoy组成 被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。 它们还收集和报告所有网格流量的遥测数据。控制平面 管理并配置代理来进行流量路由。
Istio 的流量管理模型源于和服务一起部署的 Envoy 代理。 网格内服务发送和接收的所有 data plane 流量都经由 Envoy 代理 这让控制网格内的流量变得异常简单而且不需要对服务做任何的更改 虽然国内目前使用 Envoy 作为网关的开源项目或商业化产品不多但是国外使用 Envoy 作为网关的产品或案例并不少比如Tetrate、Gloo Edge、Ambassador网关改名为 Emissary-ingress等虽然有的使用 Istio 作为控制面有的选择自建控制面板但大家都不约而同地把 Envoy 作为未来演进路线的一种选择。下一代云原生网关这个方向目前还没有形成一个事实上的标准除了 Envoy业内还有很多企业在探索这个方向。 Service Mesh 架构提供了一个新的可能可以把中间件所有的通用能力下沉到 Sidecar更方便地为业务提供增量特性缩短新业务上线的时间。 https://istio.io/latest/zh/docs/ops/deployment/architecture/ 阿里巴巴开源下一代云原生网关 Higress基于 Envoy支持 Nginx Ingress 零成本快速迁移 Higress是基于阿里内部的Envoy Gateway实践沉淀、以开源Istio Envoy为核心构建的下一代云原生网关实现了流量网关 微服务网关 安全网关三合一的高集成能力深度集成Dubbo、Nacos、Sentinel等微服务技术栈能够帮助用户极大的降低网关的部署及运维成本且能力不打折在标准上全面支持Ingress与Gateway API积极拥抱云原生下的标准API规范同时Higress Controller也支持Nginx Ingress平滑迁移帮助用户零成本快速迁移到Higress。 云原生API网关选型对比
产品KongAPISIXTraefikAmbassadorGlooIstio Gateway语言LuaLuaGolangPythonGolangGolang部署复杂度中等中等简单简单简单简单依赖Cassandra或Postgres可DBlessETCDV2版本K8SK8SK8SK8S开源Apache2.0开源Apache2.0开源MIT协议开源Apache2.0开源Apache2.0开源Apache2.0开源核心技术Nginx/LuaNginx/LuaGolangEnvoyEnvoyEnvoy社区情况大大 国内大中中大API认证授权支持支持支持支持支持支持流控支持支持高性能支持支持商业版支持基于Envoy全局限流数据转换基于HTTP基于HTTP不支持基于HTTP基于HTTP不支持路由策略host, path, methodhost, path, methodHost, pathhost, head, pathheader, queryparam, method, path, functionHost, head, path容器集成自带数据面、控制面自带数据面、控制面仅作为网关作为控制面适配Envoy作为控制面适配Envoy作为控制面适配Envoy 基于Java Agent技术的Sermant网关
https://github.com/huaweicloud/SermantSermant(也称之为Java-mesh)是基于JavaAgent无代理的服务网格技术。其利用JavaAgent为宿主应用程序提供增强的服务治理功能以解决大规模微服务体系结构中的服务治理问题。 Sermant的愿景还包括构建插件开发生态系统以帮助开发人员更容易地开发服务治理功能同时不干扰业务代码。Sermant架构描述如下。 Sermant中的JavaAgent广泛采用类隔离技术以消除框架代码、插件代码和宿主应用程序代码之间的类加载冲突。 基于JavaAgent技术通过ByteBuddy字节码增强技术修改Java服务的字节码只支持Java微服务。
Dubbo Proxyless Mesh
Dubbo Proxyless 模式是指 Dubbo3 直接与 Istiod 通信通过 xDS 协议实现服务发现和服务治理等能力。 Dubbo3 依旧保持了 2.x 的经典架构以解决微服务进程间通信为主要职责通过丰富的服务治理如地址发现、流量管理等能力来更好的管控微服务集群Dubbo3 对原有框架的升级是全面的体现在核心 Dubbo 特性的几乎每个环节通过升级实现了稳定性、性能、伸缩性、易用性的全面提升。 Dubbo 3已经实现了对 Istio 体系的全面接入可以用 Istio 控制面治理 Dubbo 服务而在数据面部署架构上针对 Sidecar 引入的复杂性与性能问题Dubbo 还支持无代理的 Proxyless 模式。 除此之外Dubbo Mesh 体系还解决了 Istio 架构落地过程中的很多问题包括提供更灵活的数据面部署架构、更低的迁移成本等。 Proxyless 模式使得微服务又回到了 2.x 时代的部署架构同 Dubbo 经典服务治理模式非常相似所以说这个模式并不新鲜 Dubbo 从最开始就是这样的设计模式。这样做可以极大的提升应用性能降低网络延迟。有人说这种做法又回答了原始的基于 SDK 的微服务模式其实非也它依然使用了 Envoy 的 xDS API但是因为不再需要向应用程序中注入 Sidecar 代理因此可以减少应用程序性能的损耗。 但相比于 Mesh 架构Dubbo 经典服务治理模式并没有强调控制面的统一管控而这点恰好是 Service Mesh 所强调的强调对流量、可观测性、证书等的标准化管控与治理也是 Mesh 理念先进的地方。 在 Dubbo Proxyless 架构模式下Dubbo 进程将直接与控制面通信Dubbo 进程之间也继续保持直连通信模式我们可以看出 Proxyless 架构的优势
没有额外的 Proxy 中转损耗因此更适用于性能敏感应用更有利于遗留系统的平滑迁移架构简单容易运维部署适用于几乎所有的部署环境 初步结论 目前APISIX相比KONG由于后发优势在性能和功能方面有优势开源社区比较活跃国产开源针对云原生做了很多改造本土化适配和支持比较好但稳定性不如KONG可以先进行小规模研究和使用逐步作为东西向网关使用解决协议转换限流等需求。 Apache ShenyuSpring Cloud GatewayZuul阿里CSB2.0都是基于Java异步化的网关适合业务团队作为业务网关使用Shenyu功能最多目前Bug比较多稳定性一般有业务网关需求的团队可以内部使用。 在云原生的大背景下Service Mesh是目前的技术趋势开源 Istio Envoy目前社区非常活跃。很多大厂已经完成规模化落地云原生网关但是下一代云原生网关这个方向目前还没有形成一个事实上的标准GateWay API标准刚出来没用多久。但是如果公司缺乏相关的技术储备和人才短期落地会比较困难。 目前国内很多公司阿里系公司已经从Dubbo2升级到Dubbo3升级的好处包括结合Service Mesh框架实现统一的云原生服务治理下一代通信协议 Triple实现Stream、跨网关调用应用级服务发现模型降低单机及注册中心资源消耗。升级Dubbo3可以解决目前Dubbo2框架不再维护微服务架构逐渐落后的问题还可以同时把JDK8升级到JDK17在性能和微服务治理方面都有收益长期看是应该升级的。 建议先从新项目或相对独立的业务开始升级验证。 参考资料亲历者复盘网易的 Envoy 网关选型、开发与改造_语言 开发_蔡芳芳_InfoQ精选文章SpringCloud Gateway 在微服务架构下的最佳实践_阿里云_阿里巴巴云原生_InfoQ写作社区阿里巴巴开源下一代云原生网关Higress基于Envoy支持Nginx Ingress零成本快速迁移_语言 开发_蔡芳芳_InfoQ精选文章云原生时代18岁的NGINX过时了吗_语言 开发_Tina_InfoQ精选文章业务网关的落地实践_文化 方法_Qunar技术沙龙_InfoQ精选文章从Kong到Envoy网易严选网关架构演进之路Apache ShenYu 介绍 | Apache ShenYu雪球基于Apache APISIX的双活架构演进_架构_雪球基础组件团队_InfoQ精选文章Proxyless Mesh 在 Dubbo 中的实践https://github.com/apache/dubbo/issues/9436https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/upgrades-and-compatibility/2.x-to-3.x-compatibility-guide/是时候考虑升级 JDK 17 了 - 知乎【推荐】ShenYu网关快速接入 (多端注册)ingress控制器那么多到底该选哪一个累觉不爱。
