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

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

网关是什么传统架构的通用功能

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

安全性：身份验证、授权、防重放、防篡改、对抗DDos等

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

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

模块：

Backend:后端服务

AOP:框架携带的AOP分层

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

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

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

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

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

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

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

网关模式的出现

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

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

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

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

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

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

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

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

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

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

概念介绍OTeam

很多人对腾讯内部的赛马文化恐怕早有耳闻。在腾讯内部，老板们为了创造更有竞争力的产品，通常会让不同的队伍去同一个赛道竞争。由于产品的竞争关系，下面的技术当然也不会共享，因此导致早期的腾讯在技术沉淀方面是互联网大厂中垫底的那个。

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

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

ApacheAPISIX

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

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

ApacheAPISIX使用ETCD作为配置存储，可以实现配置秒更新

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

OTeam的运营策略

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

OTeam的运作参考下图：

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

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

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

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

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

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

解决了Issue后，腾讯工程师会判断这个问题对于社区来说，是否也是一个共性问题。如果是，则会发PR到社区的仓库去。

腾讯OTeam会定期ReviewApacheAPISIX的新特性，判断其是否稳定、是否对腾讯内部也是一个痛点。如果答案是肯定的，合入相关代码。

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

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

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

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

OTeam发展情况

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

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

内部特性介绍

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

内部的痛点

先来看看，有哪些痛点是腾讯内部独有的：

RPC框架对前端不友好：腾讯内部有很多遗留项目使用了TARS框架，它不像TRPC一样可以直接支持

转载请注明:http://www.aideyishus.com/lkzp/659.html