Apache APISIX’s technology selection, testing and continuous integration

Author:Ming Wen Apache APISIX is a cloud-native microservices API gateway, delivering the ultimate performance, security, open source and scalable platform for all your APIs and microservices. Apache APISIX is based on Nginx and etcd. Compared with traditional API gateways, Apache APISIX has dynamic routing and plug-in hot loading, which is especially suitable for API management under micro-service system. This article mainly mainly includes three aspects: First, what is API gateway and what does it do? Second, 阅读更多…

Analysis of Excellent Performance of Apache APISIX Microservices Gateway

Author: Ming Wen Apache APISIX is a high-performance and scalable microservices API gateway. Its implement is based on Nginx and etcd. Compared with traditional API gateways, APISIX has functions such as dynamic routing, plugins hot-reloading , and gRPC protocol transcoding, which is especially suitable for API management under the microservices system. Apache APISIX is a booming open source project. After being open sourced on June 6th,2019, it has quickly gained attention and interests from developers, and 阅读更多…

思必驰:为什么我们重新写了一个 k8s ingress controller?

作者:金卫 前言 大家好,我是来自苏州思必驰的金卫,今天和大家聊聊 Apache APISIX 与 k8s 集成代替原生 ingress 的话题。 写这篇文章时,我们已经在生产环境上应用了 Apache APISIX,接管了部分业务的入口流量,同时正逐步把原生 ingress 中流量迁移过来,如下图所示: 借助 Apache APISIX 动态路由能力做流量分发,同时自定义一些插件,满足业务需求。 APISIX-ingress-controller 将 pod ip 注册到 upstream 的, node 中,业务流量可以绕过 kube DNS 直接访问到 pod。也正是在此基础上,可以通过插件实现一些特殊负载均衡策略。 从图上看,好像做了一件与原生 ingress 重复的事情。那这篇文章我们就简单介绍一下为什么舍弃原生 ingress,用 Apache APISIX 自建一套 ingress controller。 ingress 是什么简单讲,Ingress是 Kubernetes 处理边缘入口流量的一种方式。 ingress 解决什么问题由于 Kubernetes 集群内的服务都是虚拟网络,外部流量访问集群内部,至少需要一个公网ip和端口映射。 Kubernetes 有多种暴露边缘接口的方式,比如,nodeport、loadBalancer、ingress 等方式,相比而言,ingress 通过暴露有限的公网 ip,使用反向代理的方式,无疑是一种更加经济的方式。 说到反向代理,我们也可以直接搭建一个 Nginx 来做反向代理,但是要在 Nginx 里同步 Kubernetes 中随时可变的服务状态,明显增加了维护难度。 好在 Kubernetes 官方提供并维护了一个 nginx ingress controller,帮助我们解决了反向代理的事情,有了这个 nginx ingress controller,可以帮助我们代理所有想要访问 Kubernetes 的边缘流量,并且将流量正确的指向后端服务。 Kubernetes 原生 ingress 阅读更多…

HelloTalk:基于 OpenResty 和 Apache APISIX 的全球化探索之路

作者:李凌 2019 年 12 月 14 日,又拍云联合 Apache APISIX 社区举办 API 网关与高性能服务最佳实践丨Open Talk 广州站活动,HelloTalk, Inc. 后台技术负责人李凌做了题为《HelloTalk 基于 OpenResty 的全球化探索之路》的分享。 李凌,HelloTalk,Inc. 后端技术负责人,专注在服务出海和基于 Golang/CPP 的 IM 服务及相关技术平台的架构,5 年基于 OpenResty 服务治理和使用经验,Apache APISIX Committer。 以下是分享全文: 大家好,我是来自 HelloTalk 的李凌,本次主要介绍 HelloTalk 做什么业务以及基于怎样的场景使用 OpenResty 和 Apache APISIX。 HelloTalk:技术上看是基于全球的 Tiny 版微信 HelloTalk 是全球最大的外语学习社交社区,全球 1600 万用户通过 HelloTalk 和全球语伴学习 150 门外语、进行跨文化交流及交友。用户广泛分布中国、日本、韩国、美、欧、巴西等国家,其中海外用户占 80%,从技术角度来看 HelloTalk 是一个基于全球的 Tiny 版微信。 HelloTalk 海外有很多 KOL 用户在 YouTube、Instagram、Twitter 等平台协助做推广,知名度较高,产品兼顾聊天、改错、翻译等功能,用户可以边聊边语音改文字。其中语音改文字和翻译支持 100 多种语言。 从运营层面看,很多企业出海时不知道怎样去做第一步,技术上也同样面临这个问题——如何做到出海,并且为全球用户提供优质的服务。为了让每个国家的用户都能拥有更好的使用体验,这里就要不得不提到 OpenResty 给我们带来的帮助了。 如上图所示,HelloTalk 的用户分布很散,我们需要找到最佳的平衡点,以性价比最优的方式部署连接节点。亚太区域如韩国、日本,中国长三角和珠三角等地用户分布比较集中,比较好处理,但是在用户高度分散的其他地区(如上图的欧洲、非洲、中东),对提供稳定可靠的服务提出了较高的挑战。 为什么使用 OpenResty 早期 HelloTalk 使用 C++ 阅读更多…

Apache APISIX 技术选型、测试和持续集成

作者:温铭 OpenResty 社区联合又拍云,举办 OpenResty × Open Talk 全国巡回沙龙·成都站,Apache APISIX PPMC 温铭在活动上做了《 API 网关的选型和持续集成 》的分享。 OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 中国社区、又拍云发起,邀请业内资深的 OpenResty 技术专家,分享 OpenResty 实战经验,增进 OpenResty 使用者的交流与学习,推动 OpenResty 开源项目的发展。 温铭,深圳支流科技联合创始人,开源微服务 API 网关 Apache  APISIX PPMC,OpenResty软件基金会发起人,《OpenResty 从入门到实战》专栏作者,创业之前在互联网安全公司工作了 10 年,主要从事服务端的开发和架构,负责开发过木马云查杀、反钓鱼系统和企业安全产品。曾在奇虎 360 担任架构师,开源委员会发起人、委员。 以下是分享全文: 我和院生在做的一个开源的 API 网关项目叫 Apache APISIX,今天介绍这个项目涉及到 OpenResty 的技术和选型,主要包括三个方面: 第一, API 网关是什么,它有什么作用; 第二,如何去做 API 网关,如何做选型; 第三,Apache APISIX 是一个开源项目,介绍我们在只有两个人的情况下是怎么去做测试和持续集成,里面会涉及 OpenResty 的一些通用的东西,值得大家借鉴。 API 网关的作用 什么是 API 网关 以 Kong 为例,左图没有 API 网关,但是后面挂了很多服务,如果每个服务都要实现包括认证、统计、安全校验等功能,会有很多重复的工作。API 网关的作用就是把这些公共的东西抽取出来,如右图,下面的这几个服务,每个服务都只关心自身业务相关的东西,和业务无关的东西全部都丢到API 网关上,即 API 网关就是把公共的东西如统计、安全、限流、限速、缓存等提取出来做了一个中间层。 API 网关的传统功能 让 API 请求更安全、更高效的得到处理。传统的 API 网关有一些基本的功能直到现在都适用的,管理不管南北向的还是东西向的 阅读更多…

Apache APISIX 高性能实战2

作者:王院生 2019 年 8 月 31 日,OpenResty 社区联合又拍云,举办 OpenResty × Open Talk 全国巡回沙龙·成都站,Apache APISIX PPMC 王院生在活动上做了《Apache APISIX 高性能实践》的分享。 OpenResty × Open Talk 全国巡回沙龙是由 OpenResty 社区、又拍云发起,邀请业内资深的 OpenResty 技术专家,分享 OpenResty 实战经验,增进 OpenResty 使用者的交流与学习,推动 OpenResty 开源项目的发展。 王院生,Apache APISIX PPMC,支流科技创始人。 以下是分享全文: 首先做下自我介绍,我大学毕业后在传统金融行业工作九年,2014 年加入奇虎 360,期间撰写了《OpenResty 最佳实践》。我个人比较喜欢研究技术和开源,可能是受老罗影响,喜欢尝试理想化的事情。今年 3 月份与志同道合的伙伴一起创办了深圳支流科技公司,这是一家以开源方式创业的科技公司,在国内屈指可数,APISIX 是我们目前的主要项目。 Apache APISIX 是微服务 API 网关产品,今年 7 月份我在上海做过一次关于“ Apache  APISIX 高性能实践”的分享,这次的内容是在上次分享的基础上,并会将最近的新积累分享给大家。 什么是 API 网关 API 网关的地位越来越重要,它是所有流量的出入口,从图中可以看到请求方可能来自于浏览器、loT 设备以及移动设备等,API 网关作为中间管控层需要做安全控制、流量以及日志记录等。越来越多的企业采用了微服务的方式,以此完成内部解耦、灵活部署、弹性伸缩等技术特性从而满足业务需求。微服务的数量和复杂度也都随之水涨船高,通过 API 网关来完成统一的流量管理调度就非常必要,并对 API 网关提出了更高要求。 Apache APISIX 概述 上图是 Apache APISIX 的基本构架,由于要支持集群和高可用,所以在任何一个节点都需要包含 adminAPI 或 Apache APISIX 内核,使用时可以只启用其中一部分或都启用。admin API 主要用于接收管理员的提交信息,通过 json schema 完成参数的校验,防止非法参数落到存储的配置中心。Apache APISIX 内部部分处理外部请求,根据请求特征,匹配到具体路由规则,执行插件,然后把流量转发到指定上游服务。 Apache APISIX 阅读更多…

Apache APISIX 高性能实战

作者:王院生 2019 年 7 月 6 日,OpenResty 社区联合又拍云,举办 OpenResty × Open Talk 全国巡回沙龙·上海站,OpenResty 软件基金会联合创始人王院生在活动上做了《Apache APISIX 的高性能实践》的分享。 OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 社区、又拍云发起,邀请业内资深的 OpenResty 技术专家,分享 OpenResty 实战经验,增进 OpenResty 使用者的交流与学习,推动 OpenResty 开源项目的发展。活动将陆续在深圳、北京、武汉、上海、成都、广州、杭州等城市巡回举办。 王院生,支流科技创始人,Apache APISIX PPMC。 以下是分享全文: 大家好,我是王院生,很高兴来到上海。首先做下自我介绍,我于 2014 年加入奇虎 360,在那时认识了 OpenResty,此前我是一个纯粹的 C/C++ 语言开发者。在 360 工作期间,利用工作闲暇时间写了《OpenResty 最佳实践》,希望能影响更多的人正确掌握 OpenResty 入门。 什么是 API 网关 API 网关的地位越来越重要,它几乎劫持了所有流量,内外之间完成了用户的安全控制、审计,通过自定义插件的方式满足企业自身特定需求,最常见的自由身份认证等。随着服务在数量和复杂度上的不断增长,更多的企业采用了微服务的方式,这时通过 API 网关来完成统一的流量管理和调度就非常有必要。 微服务网关和传统意义上的 API 网关有一些不同,主要包括下面几点: 动态更新:在微服务之前,服务不像现在这样经常来回地变化。比如微服务需要做横向扩充,或者故障恢复、热备、切换等,IP 、节点等变动更加频繁。举例如微博上一旦出现了爆点事件,就急速扩充计算点,必须要非常快地扩充新机器来扛压。波峰波谷变化明显,分钟级别的机器动态管理,已经越发是常态。 更低延迟:通常动态就意味着可能会做一些延迟(复杂度增加),在微服务里面,对于延迟要求比较高,尤其对于现在的用户体验,超过 1 秒以上的延迟是完全不可接受的。 用户自定义插件:API 网关是给企业用户使用的,它一定存在私有逻辑(比如特殊的认证授权等),所以微服务网关必须能够支持企业用户自定义插件。 更集中的管理 API:如前面所说 API 网关劫持了用户的所有流量,所以用网关来做统一的 API 管理是非常必要的。在网关角度可以看到 API 是如何设计,是否存在延迟、安全问题,以及响应速度和健康信息等。 我们要做的微服务 API 网关产品,除了上面的基本要求,还有一些是我们区别于其他人的: 通过社区聚焦:通过开源方式聚焦有共同需求的人群,让更多不同公司的人可以一起协作,共同打磨更好的产品,减少冗余开发。 简洁的 core:产品的内核必须是非常简洁的,如果内核复杂,会使得大家的上手成本高很多,望而却步肯定不是我们期望的。 可扩展性、顶级性能、低延迟:这几项都是要同时严格保障的,也是我们会花主要精力保证的。目前 APISIX 阅读更多…

360:Apache APISIX 在基础运维平台项目中的实践

作者:久 女主宣言 今天小编为大家分享一篇关于Apache APISIX的文章,文章从开发者的角度讲述了 Apache APISIX 网关在 360 基础运维平台的落地实践,希望能对大家有所帮助。 PS:丰富的一线技术、多元化的表现形式,尽在“360云计算”,点关注哦! Api 网关选型 2019 年 10月,我们团队计划改造 360 基础运维平台的网关层,当时我们主要调研了社区几个比较活跃的网关,如 Kong,Orange,Apache APISIX,最终选择了 Apache APISIX 当时主要是考虑到 Apache APISIX 的存储选型 etcd 比较符合我们的使用场景。 线上运行情况 目前我们添加到网关的 API 数量接近 900 个,日均 PV 1000 万左右,从监控系统来看,网关以及我们各个微服务均运行良好。 •日均 PV •网关 POD 监控 •微服务负载监控图 基础运维平台架构图 下图是我们运维平台项目最终的架构图,网关服务我们部署在公司的容器云上,etcd 服务我们是在 3 台虚机上部署了一套集群。 容器化开发和部署 接下来我具体介绍一下我们是如何使用 Apache APISIX 搭建网关服务的,首先先给大家看下我们网关项目的代码结构 之前我给王院生(Apache APISIX PPMC 之一 )看我们的项目代码结构时,他惊讶的问我,说怎么没有看到 Apache APISIX 的 core 代码。 实际上这是我们在使用容器安装 Apache APISIX 时探索出来的一条道路。它给我们带来最大的好处是,我们业务的代码和 Apache APISIX 的核心代码完全分开,方便 Apache APISIX 升级,也方便我们的业务代码迭代。 下面我给大家分步演示一下,我们是怎么搭建一个这样的环境的。(此处假设大家都了解 docker 容器技术) •启动 openresty 容器 我们团队基于官方的 阅读更多…

贝壳找房:如何基于 Apache APISIX 搭建网关

作者:王辉 我是王辉,在贝壳找房负责 API 网关系统的开发,我们使用 Apache APISIX 作为生产系统的 API 网关,每天处理过亿的生产流量,性能优异,而且很稳定。正好 APISIX 刚刚加入 Apache 孵化器,除了恭喜之外,我想来分享下贝壳找房当初为什么选择 Apache APISIX,以及使用过程中的一些心得。 选择 Kong 还是 APISIX? 对于网关的技术要求,一是要性能好,能够支撑大流量的接入,二是要稳定,不能出问题。 选型的原则就是基于或者借鉴开源项目重构一个更加稳健的版本,能够保证接入更大的流量,刚开始的流量还少,做这样的大动作是完全可以接受的。评估完利弊后和领导表沟通了一下想法,得到领导的肯定后就决定搞起,这时脑海想的第一个就是 Kong 了,大名鼎鼎的开源网关。于是就去官网浏览了一番,周边文章也看了些,第一印象就是这个这个项目很不错,这个功能支持那个功能也支持,能够满足用户想到的没想到的大多数需求,性能还稳定,就是它了。兴高采烈的 clone 了代码开始阅读起来,一天两天若干天过去了,还是一头雾水的样子,想想也是,Kong 能提供这么多的功能,其代码的复杂度可想而知。 这时几个问题出现在我的脑海里,我一个人多久能啃下来 Kong 呢?然后还要构建一个适合自己的项目,又需要多久呢?还有就是这么多的功能我都需要么? 在一个月黑风高的夜晚,QQ群里响了一下声,是温铭发的一条消息还@了全体,API 网关 APISIX 0.5 版本发布了,这是啥?第二天上班就赶紧联系了温铭,才了解到这是他和院生一起搞的开源项目。这节骨眼APISIX 的出现让我看见了一个新的选择,最主要俩位都是业界的大佬,代码质量应该没问题,就是开源时间太短。 抱着试一试的态度开始走近APISIX,先是简单的看看了文档,由于开源时间较短支持的功能有限,但也不少了,动态负载均衡、熔断、身份认证、限速等等,代码量也不是很大降低了学习成本,在这一点上 PK 掉了 Kong,APISIX 更适合我当前的状况,满足我初期的功能规划,也不用考虑不需要的功能怎么处理问题了。 接下来看的就是重点了,开源时间这么短,性能怎么样?看了相同环境的压测数据对比,APISIX完爆 Kong,虽然这样不太公平,毕竟 Kong 是个庞然大物,但对于我的生产环境来说,他俩是一样的。根据 APISIX 的性能测试报告,单核 CPU 可以达到 24k QPS,同时延时只有 0.7 毫秒。 最终选择了 APISIX,我的理由如下: 在都能满足项目需求的前提下,APISIX 学习成本低 Kong 的代码量庞大,后期维护也会带来难度 APISIX 作者经常活跃于 OpenResty 社区,代码质量有保证 最重要的一点就是接触过作者,有什么问题都可以快速的沟通 官网的理由如下图所示: APISIX能提供哪些能力? 热更新和热插件 动态负载均衡 主动和被动健康检测 熔断器 身份认证 限流限速 gRPC 协议转换 动态 TCP/UDP、gRPC、websocket、MQTT 代理 控制台 阅读更多…