查看原文
其他

支持 10 亿日流量的基础设施:当 Apahce APISIX 遇上腾讯

腾小源 腾源会 2022-04-23

本文整理自腾讯游戏负责内部容器平台的工程师徐鑫在 Apache APISIX Meetup - 深圳站上的演讲,通过阅读本文,您不仅可以了解网关是什么、网关模式对传统服务架构的改进,还可以了解腾讯 OTeam 诞生的原因,以及 Apache APISIX 是如何在腾讯内部落地的。欢迎感兴趣的同学访问 bilibili 观看视频。

我们有必要先了解一下 网关 (Gateway) 的作用和价值。


PART ONE

网关是什么


传统架构的通用功能

在传统的架构中,没有网关,那么通用功能该怎么复用起来呢?这里的通用功能指业务无关的一些特性,比如:

  • 安全性:身份验证、授权、防重放、防篡改、对抗 DDoS 等

  • 可靠性:服务降级、熔断、限流等

这些功能在传统架构下,最常见的处理方法就是将其放入服务框架当中,通过 AOP 的方式去实现,类似下图:

模块:

  • Backend: 后端服务

  • AOP: 框架携带的 AOP 分层

  • SD: 服务中心,用于服务间发现,此组件在云原生环境下经常用 Service 替代

  • LB: 负载均衡器,放置于网络边界上,作为外部流量的入口

这种架构在早些年的设计中非常常见,由此诞生了很多大而全的服务框架,比如 Dubbo, SpringCloud 等。如果我们去认真去研究它们的功能介绍,我们会发现这些功能点它们大多都有。

这种架构的优点在于上下游关系简单,网络传输中也少了一次转发。但是她们的缺点也很明显:

  • 通用功能的迭代会迫使业务服务更新:由于采用的是代码引用,因此需要业务服务重新编译才能使功能生效。对一些没有实现平滑发布的团队,由于服务会中断,因此还得挑业务的空闲期发布。

  • 版本难以管理:由于我们不可能每次发布都让所有业务服务升级最新版,长此以往,各个服务的版本将会不一致。

那么我们是否可以将这些通用功能下沉到一个独立的服务,它可以单独迭代且业务无关?


网关模式的出现


从上图中,我们可以看到传统架构的大部分内容都没有变化,只是在后端服务与 LB(负载均衡器) 之间多出了一个角色:网关。

(这里需要澄清的是,本文讨论的网关特指 ApiGateway ,即针对后台服务以 API 提供服务的场景。)

在上面的这个图中,有时 LB 同时也起到网关的作用,比如 k8s 的 Ingress 组件。

有了网关这个组件后,我们就可以将传统架构的通用功能下沉到网关,这样一来我们获得了很多的好处:

  • 网关可以独立迭代,不再需要业务服务配合

  • 与语言无关,可以配置专门的团队维护

但是网关模式也有自己的缺点:

  • 多了一次转发,延迟变高,排查问题复杂度变高

  • 网关如果不能正常工作,可能会成为整个平台的瓶颈

如何平衡好网关模式的好处和缺点,不仅十分考验业务团队的实力,更是与网关的选型息息相关。接下来,我们要请出本文要介绍的两个重点对象:腾讯 OTeam 和 Apache APISIX。


PART TWO

概念介绍


OTeam


很多人对腾讯内部的赛马文化恐怕早有耳闻。在腾讯内部,老板们为了创造更有竞争力的产品,通常会让不同的队伍去同一个赛道竞争。

在其他几家互联网大厂都相继在中台发力时,腾讯也开始整合公司内的重复轮子,沉淀技术中台。腾讯将相同性质的几个技术产品都放入同一个 Oteam,将维护人员都整合起来,一起发力,让这些产品逐渐合并成一个大而全的产品,这就是 Oteam。

有的 Oteam 下面有多达十数种产品,而有的只有一种。比如 Apache APISIX 所在的 Oteam 就单单只有 Apache APISIX 这一个产品,这个 Oteam 成立的初衷是:维护腾讯内部的 Apache APISIX 定制化特性。


Apache APISIX

感兴趣的同学可以前往 Apache APISIX 的 Github。我们在这里只简单介绍几个点:

  • Apache APISIX 是基于 OpenResty 的高性能网关,比起竞品 Kong,它的路由性能高了一个数量级

  • Apache APISIX 使用 ETCD 作为配置存储,可以实现配置秒更新

  • Apache APISIX 是 Apache 基金会毕业最快、最让导师省心的项目之一


PART THREE

OTeam 的运营策略

大家是不是很好奇腾讯的 OTeam 是怎么运作,又如何和 Github 的社区形成双赢的关系的?

OTeam 的运作参考下图:

上图可以看到 OTeam 的特性迭代是一个完整的闭环:

  • 用户通过 Issue 反馈问题和需求

  • OTeam 的成员 在 周会 上讨论解决方案,或者直接在 Issue 中跟进

  • 按照解决方案实现特性 or 修复 Bug

  • 代码 Review 后,经历 CI 合入到主干中,再视情况需不需要打包镜像发版

这个流程其实和 Github 多数开源项目的贡献过程是没区别的,关键点在于:

  • 解决了 Issue 后,腾讯工程师会判断这个问题对于社区来说,是否也是一个共性问题。如果是,则会发 PR 到社区的仓库去。
  • 腾讯 OTeam 会定期 Review Apache APISIX 的新特性,判断其是否稳定、是否对腾讯内部也是一个痛点。如果答案是肯定的,合入相关代码。

最早期的时候,OTeam 会每 12 小时,自动合入社区代码到内部仓库中,以保证我们与社区能够共同前进,但这种做法带来了几个问题:

  • 合入的代码通过目前的集成测试只能保证功能 正确性 却没法保证 稳定性,很多偶现的问题都是在并发中发生的。

  • 合入的代码,有时会产生上游的多个 PR 在逻辑上出现冲突的问题,但是各自的 CI 无法检测出来,只有当合入主干后,才会发现主干的代码产生了问题。

出于以上原因,现在 OTeam 转为定期 Review 后合入所需特性的代码的策略。


PART FOUR

OTeam 发展情况

截止 2021 年 5 月,Apache APISIX 所在的 OTeam 在腾讯内部已为超过十个团队落地了 Apache APISIX,其中最大的业务日请求量已超过十亿,同时 OTeam 也为 Apache APISIX 开发了超过十个内部特性,其中包括内部的服务发现、RPC 协议转换、打通监控平台等。

与此同时,OTeam 也将开发的一些通用的特性贡献到了社区,为社区带来了不少 Contributor。目前 OTeam 团队中,有两位成员同时也是 ApacheAPISIX 社区的 PMC,OTeam 为社区贡献了超过 50 个 PR。同时,我们相信 OTeam 今后还会与 Apache APISIX 社区开展更多的合作。


PART FIVE

内部特性介绍

OTeam 的主要职责是维护 Apache APISIX 的一些针对腾讯内部的特性,那么这些特性都是哪些,又解决了什么样的痛点呢?


内部的痛点

先来看看,有哪些痛点是腾讯内部独有的:

  • RPC 框架对前端不友好:腾讯内部有很多遗留项目使用了 TARS 框架,它不像 TRPC 一样可以直接支持 http 协议,它只支持 RPC 框架最传统的 tcp 协议,传输内容都使用特定的二进制协议。这带来的一个问题是,我们需要维护一个中间服务来将这些接口转换为前端友好的 http + json 形式。

  • 服务中心多样化:腾讯内部服务发现的组件众多,比如 CL5、L5、北极星……虽然在未来,服务组件会逐渐统一,但在过渡期间,会存在多个服务中心同时使用的情况,最开始的 Apache APISIX 不支持这一点。

  • 告警:作为一个网关解决方案,告警不是一个它应该关注的方向,但是作为网关这个基础组件,告警一定是团队所关心的事项,要怎么解决告警问题,也是一个痛点。

  • 安全性:腾讯这种体量的公司,除了产品本身会面对大量流量之外,产品还有安全性的要求。不乏 ToC 的产品使用了 OTeam ,它们要面对的不止海量用户的误操作,还要面对来自网络的攻击,无论是善意还是恶意的,最典型的有 DDoS、 重放、篡改请求等。这些流量我们是否可以在网关层解决?

问题的解决

带着这些问题,让我们来看一个架构拓扑图,它来自一个腾讯内部某个落地 case 的简化:
从上图可以看出,刚才提出的几个问题都在 OTeam 都得到了解决:
  • 网关实现协议转换:OTeam 基于 Apache APISIX 实现了 TRPC 与 TARS 的协议转换,这样一来那些没有实现 http 的遗留服务,可以在网关直接使用封装好的协议转换插件来实现 http 和 rpc 互转的需求而不再需要编写中间服务。

  • 支持多服务中心:这一点其实应该不止腾讯内部需要,相信外面也有很多同学在新老架构的过渡期需要,该特性我们已经反馈给了社区。

  • 指标上报自研监控平台:OTeam 利用插件打通了腾讯内部的几个主要的监控平台,让用户可以简单配置后自动上报接口可观测性的相关信息(链路调用、日志、统计),上报后用户可自行在监控平台配置告警。

  • 防重放与防篡改:OTeam 实现了防重放和防篡改插件,让需要这些能力的对外的业务可以直接开箱即用,保护自己的接口安全。

我们希望这些例子能起到抛砖引玉的作用,鼓励大家去发掘更多 Apache APISIX 的使用场景,更好的把 Apache APISIX 这个好用的工具用起来。比如在腾讯云团队,就有同学利用网关实现了一些腾讯云平台强制要求的 API 规范,将这逻辑下沉到了网关。


PART SIX

最后的话

转眼在腾讯内帮助各个团队维护 Apache APISIX 也一年多了,在这个过程中,OTeam 既帮助业务团队解决了他们的痛点,也不断完善了 Apache APISIX 在腾讯内部的特性,同时也间接推动了社区的发展,真的是一个双赢的事情。

如果读者所在公司如果还没有落地网关的话,可以了解下 Apahce APISIX。已经落地了网关的读者,也希望本文能够给你们带来一点在网关落地上的灵感和帮助。

Apache APISIX GitHub:https://github.com/apache/apisix
Apache APISIX 官网:https://apisix.apache.org/
Apache APISIX 文档:https://apisix.apache.org/zh/docs/apisix/getting-started
文章转载自:InfoQ

欢迎关注「腾源会」公众号,期待你的「在看」哦~👇

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存