关于apisix:支持-10-亿日流量的基础设施当-Apache-APISIX-遇上腾讯

55次阅读

共计 4129 个字符,预计需要花费 11 分钟才能阅读完成。

本文整顿自腾讯游戏负责外部容器平台的工程师徐鑫在 Apache APISIX Meetup – 深圳站上的演讲,通过浏览本文,您不仅能够理解网关是什么、网关模式对传统服务架构的改良,还能够理解腾讯 OTeam 诞生的起因,以及 Apache APISIX 是如何在腾讯外部落地的。

在正式进入分享之前,先给大家介绍一下网关 (Gateway) 的作用和价值。

网关是什么

传统架构的通用性能

在传统架构中是没有网关的,那么通用性能该如何复用?这里的通用性能指业务无关的一些个性,比方:

  • 安全性:身份验证、受权、防重放、防篡改、反抗 DDos 等
  • 可靠性:服务降级、熔断、限流等

这些性能在传统架构下,最常见的解决办法就是将其放入服务框架当中,通过 AOP 的形式去实现,相似下图:

图中模块释义:

  • Backend: 后端服务
  • AOP: 框架携带的 AOP 分层
  • SD: 服务中心,用于服务间发现,此组件在云原生环境下常常用 Service 代替
  • LB: 负载均衡器,搁置于网络边界上,作为内部流量的入口

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

这种架构的长处在于上下游关系简略,网络传输中也少了一次转发。但它们的毛病也很显著:

  • 通用性能的迭代迫使业务服务更新: 因为采纳的是代码援用,须要业务服务从新编译能力使性能失效。对一些没有实现平滑公布的团队,因为服务会中断,因而还得挑业务的闲暇期公布。
  • 版本难以治理: 因为咱们不可能每次公布都让所有业务服务降级最新版,长此以往,各个服务的版本将会不统一。

那么是否能够将这些通用性能下沉到一个独立的服务,它能够独自迭代且业务无关?

网关模式的呈现

从上图咱们能够看到传统架构的大部分内容都没有变动,只是在后端服务与 LB(负载均衡器)之间多出了一个角色:网关(本文探讨的网关特指 ApiGateway,即针对后盾服务以 API 提供服务的场景)。

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

有了网关这个组件后,咱们就能够将传统架构的通用性能下沉到网关,劣势立即就能展示进去:

  • 网关能够独立迭代,不再须要业务服务配合
  • 与语言无关,能够配置专门的团队保护

然而网关模式也有本人的毛病:

  • 多了一次转发,提早变高,排查问题复杂度变高
  • 网关如果不能失常工作,可能会成为整个平台的瓶颈

如何均衡好网关模式的劣势和毛病,不仅非常考验业务团队的实力,更是与网关的选型非亲非故。接下来,咱们要请出本文要介绍的两个重点对象: 腾讯 OTeamApache APISIX

我的项目介绍

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 基金会毕业最快、最让导师省心的我的项目之一

Apache APISIX in OTeam 的经营策略

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

OTeam 的运作参考下图:

能够看到 OTeam 的个性迭代是一个残缺的闭环:

  • 用户通过 issue 反馈问题和需要
  • OTeam 的成员在周会上探讨解决方案,或间接在 issue 中跟进
  • 依照解决方案实现个性或修复 Bug
  • 代码 review 后,经验 CI 合入到骨干中,再视状况需不需要打包镜像发版

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

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

最晚期的时候,OTeam 会每 12 小时主动合入社区代码到外部仓库中,以保障咱们与社区可能共同前进,但这种做法带来了几个问题:

  • 合入的代码通过目前的集成测试只能保障性能正确性却没法保障稳定性,很多偶现的问题都是在并发中产生的。
  • 合入的代码有时会产生上游的多个 PR 在逻辑上呈现抵触的问题,然而各自的 CI 无奈检测进去,只有当合入主干后,才会发现骨干的代码产生了问题。

出于以上起因,当初 OTeam 转为定期 Review 后合入所需个性代码的策略。

Apache APISIX in OTeam 倒退状况

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

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

外部个性介绍

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

外部痛点

先来看看,有哪些痛点是腾讯外部独有的。

  • RPC 框架对前端不敌对: 腾讯外部有很多遗留我的项目应用了 TARS 框架,它不像 TRPC 一样能够间接反对 HTTP 协定,它只反对 RPC 框架最传统的 TCP 协定,传输内容都应用特定的二进制协定。这带来的一个问题是,咱们须要保护一个两头服务来将这些接口转换为前端敌对的 http + json 模式。
  • 服务中心多样化: 腾讯外部服务发现的组件泛滥,比方 CL5、L5、北极星等。尽管在将来,服务组件会逐步对立,但在过渡期间,会存在多个服务中心同时应用的状况,最开始的 Apache APISIX 不反对这一点。
  • 告警性能缺失: 作为一个网关解决方案,告警不是一个它应该关注的方向,然而作为网关这个根底组件,告警肯定是团队所关怀的事项,要怎么解决告警问题,也是一个痛点。
  • 安全性: 腾讯这种体量的公司,除了产品自身会面对大量流量之外,产品还有安全性的要求。不乏 ToC 的产品应用了 OTeam,它们要面对的不止海量用户的误操作,还要面对来自网络的攻打,无论是善意还是歹意的,最典型的有 DDos、重放、篡改申请等。这些流量咱们是否能够在网关层解决?

问题的解决

带着这些问题,让咱们来看一个架构拓扑图,它来自一个腾讯外部某个落地案例的简化:

从上图能够看出,方才提出的几个问题都在 OTeam 都失去了解决。

  • 网关实现协定转换:OTeam 基于 Apache APISIX 实现了 TRPC 与 TARS 的协定转换,这样一来那些没有实现 HTTP 的遗留服务,能够在网关间接应用封装好的协定转换插件来实现 HTTP 和 RPC 互转的需要而不再须要编写两头服务。
  • 反对多服务中心: 这一点其实应该不止腾讯外部须要,置信里面也有很多同学在新老架构的过渡期须要,该个性咱们曾经反馈给了社区。
  • 指标上报自研监控平台:OTeam 利用插件买通了腾讯外部的几个次要的监控平台,让用户能够简略配置后主动上报接口可观测性的相干信息(链路调用、日志、统计),上报后用户可自行在监控平台配置告警。
  • 防重放与防篡改:OTeam 实现了防重放和防篡改插件,让须要这些能力的对外的业务能够间接开箱即用,爱护本人的接口平安。

咱们心愿这些例子能起到抛砖引玉的作用,激励大家去挖掘更多 Apache APISIX 的应用场景,更好地把 Apache APISIX 这个好用的工具用起来。比方在腾讯云团队,曾经有同学利用网关实现了一些腾讯云平台强制要求的 API 标准,并将此逻辑下沉到了网关。

最初的话

转瞬在腾讯内帮忙各个团队保护 Apache APISIX 也一年多了,在这个过程中,OTeam 既帮忙业务团队解决了他们的痛点,也不断完善了 Apache APISIX 在腾讯外部的个性,同时也间接推动了社区的倒退,实现了共赢。

如果各位读者所在的公司还没有落地网关的话,能够理解下 Apache APISIX。曾经落地了网关的读者,也心愿本文可能给你们带来一点在网关落地上的灵感和帮忙。

对于 Apache APISIX

Apache APISIX 是一个动静、实时、高性能的开源 API 网关,提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。Apache APISIX 能够帮忙企业疾速、平安的解决 API 和微服务流量,包含网关、Kubernetes Ingress 和服务网格等。

200 余位贡献者,一起缔造了 Apache APISIX 这个世界上最沉闷的开源网关我的项目。聪慧的开发者们!快来退出这个沉闷而多样化的社区,一起来给这个世界带来更多美妙的货色吧!

  • Apache APISIX GitHub:https://github.com/apache/apisix
  • Apache APISIX 官网:https://apisix.apache.org/
  • Apache APISIX 文档:https://apisix.apache.org/zh/…
正文完
 0