重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
本篇内容介绍了“如何选择适合自己的微服务API网关”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
在涞水等地区,都构建了全面的区域性战略布局,加强发展的系统性、市场前瞻性、产品创新能力,以专注、极致的服务理念,为客户提供做网站、网站建设 网站设计制作按需定制,公司网站建设,企业网站建设,成都品牌网站建设,营销型网站建设,成都外贸网站建设,涞水网站建设费用合理。
让我们先来看下微服务 API 网关的作用,下图是一个简要的说明:
API 网关并非一个新兴的概念,在十几年前就已经存在了,它的作用主要是作为流量的入口,统一的处理和业务相关的请求,让请求更加安全、快速和准确的得到处理。它有以下传统的功能:
反向代理和负载均衡,这和 Nginx 的定位和功能是一致的;
动态上游、动态 SSL 证书和动态限流限速等运行时的动态功能,这是开源版本 Nginx 并不具备的功能;
上游的主动和被动健康检查,以及服务熔断;
在 API 网关的基础之上进行扩展,成为全生命周期的 API 管理平台。
在最近几年,业务相关的流量,不再仅仅是由 PC 客户端和浏览器发起,更多的来自手机、IoT 设备等,未来随着 5G 的普及,这些流量会越来越多,同时,随着微服务架构的结构变迁,服务之间的流量也开始爆发性的增长。在这种新的业务场景下,催生了API 网关更多、更高级的功能:
云原生友好,架构要变得轻巧,便于容器化;
对接 Prometheus、Zipkin、Skywalking 等统计、监控组件;
支持 gRPC 代理,以及 http 到 gRPC 之间的协议转换,把用户的 http 请求转为内部服务的 gPRC 请求;
承担 OpenID Relying Party 的角色,对接 Auth0、okta 等身份认证提供商的服务,把流量的安全作为头等大事来对待;
通过运行时动态执行用户函数的方式来实现 serverless,让网关的边缘节点更加灵活;
不锁定用户,支持混合云的部署架构;
最后就是网关节点要状态无关,可以随意的扩容和缩容。
一个微服务 API 网关具备了上述十几项功能,就可以让用户的服务只关心业务本身,而和业务实现无关的功能,比如服务发现、服务熔断、身份认证、限流限速、统计、性能分析等,就可以在独立的网关层面来解决。从这个角度来看,API 网关既可以替代 Nginx 的所有功能,来处理南北向的流量,也可以完成 Istio 控制面和 Envoy 数据面的角色,来处理东西向的流量。
正因为微服务 API 网关的地位如此重要,所以它一直处于兵家必争之地,传统的 IT 巨头在这个领域很早就都有布局,比如谷歌、CA、IBM、红帽、salesforce、以及 AWS、阿里云等公有云厂商。
这些闭源的商业产品,它们的功能都很完善,覆盖了 API 的设计、多语言 SDK、文档、测试和发布等全生命周期管理,并且提供 SaaS 服务,有些还与公有云做了集成,使用起来非常方便,但同时也带来两个痛点:
平台锁定。API 网关是业务流量的入口,它不像图片、视频等 cdn 加速的这种非业务流量可以随意迁移,API 网关上会绑定不少业务相关的逻辑,一旦使用了闭源的方案,就很难平滑和低成本的迁移到其他平台。
无法二次开发。一般的大中型企业都会有自己独特的需求,需要定制开发,这时候你就只能依靠厂商,而不能自己动手去做二次开发。
所以我们更偏重于开源的 API 网关方案,比如 Kong、APISIX 和 Trk 等。这些 API 网关是从云原生软件基金会(CNCF)的全景图中摘选的:
是可以在单机就能完整部署,还是需要多个节点配合才能使用?
是否有外部的数据库依赖?比如 MySQL、Postgres?
是否有 web 控制台可以操作整个集群?
你是否可以编写自己的插件来扩展 API 网关的功能?
当你使用了某个 API 网关后,是否可以平滑而且低成本的迁移到其他 API 网关?
是否会被锁定在特定的平台上?
是否支持部署在用户自己的内部服务器中?
是否支持多云、混合云的部署模式?
是否支持动态上游、动态 SSL 证书、主动/被动健康检查这些基本的功能
能否对接 Prometheus、Zipkin、Skywalking 等统计、监控组件
是否可以通过 HTTP REST API 和 yaml 配置文件这两种方式,来控制网关配置
使用者能否通过 Github、QQ 群、Stack Overflow 等方式联系到社区的开发者?
开源许可证是否友好?
是否可以方便的提交自己的修改到主线版本?
背后是否有商业公司支持?
开源版本和商业版本差异是否很大?
商业版本是按照 API 调用次数还是订阅方式收费?
下面是各个 API 网关多个角度的对比结果:
API 网关 | Kong | APISIX | Trk | Apigee | AWS
| Aliyun |
部署模式 | 单机和集群 | 单机和集群 | 单机和集群 | 不支持单机 | PaaS | PaaS |
数据存储 | Postgres 或者 Cassandra | etcd | redis | Postgres,Cassandra和Zookeeper | PaaS | PaaS |
是否开源 | Apache 2.0 协议 | Apache 2.0 协议 | MPL 协议 | 否 | 否 | 否 |
核心技术 | Nginx+Lua | Nginx+Lua | Golang | 未知 | 未知 | 未知 |
私有部署 | 是 | 是 | 是 | 否 | 否 | 否 |
自定义插件 | 是 | 是 | 是 | 否 | 否 | 否 |
社区活跃度 | 高 | 高 | 高 | 中 | 低 | 低 |
对接外部 IdP | 否 | 是 | 否 | 是 | 是 | 否 |
支持yaml | 是 | 是 | 否 | 否 | 否 | 否 |
从中我们可以看出,Kong 和 APISIX 都是非常好的选择。
“如何选择适合自己的微服务API网关”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!