共计 3237 个字符，预计需要花费 9 分钟才能阅读完成。
有赞是一家次要从事批发科技 SaaS 服务的企业，帮忙商家进行网上开店、社交营销、进步留存复购，拓展全渠道新批发业务。在往年，有赞技术中台开始设计实现新的云原生 PaaS 平台，心愿通过一套通用模型来进行各种利用的公布治理和微服务相干治理。而 Apache APISIX 在其中起到了十分要害的作用。
为什么须要流量网关
有赞 OPS 平台
有赞 OPS 平台是后期基于 FLASK 的单体利用，次要以反对业务为主。起初逐步上线了很多业务，部署了很多业务端代码，进入容器化阶段。网关在过后只是外部 FLASK 利用的一部分性能，且没有一个明确的网关概念，仅作为业务利用的流量转发性能应用。下图展现的就是过后的网关 1.0 业务构造。
因为后期整个体系次要着重于业务方向，所以没有产生太多的能源去进行革新。从 2018 年开始，通过外部交换咱们发现，如果没有一个很好的网关层治理，对后续产品性能的实现和业务接入度上会带来越来越显著的瓶颈。
没有网关层治理呈现的问题
问题一：性能方面
- 每次新增后端服务，都须要进行编码变更
- 流量转发的代码用 Python 简略实现，未按“网关”要求进行设计
- Flask 框架的性能限度，单机 QPS 范畴局限在 120-150
- 反复造轮子：不同的业务需要都生产一套对应入口
- 治理麻烦，运维简单
基于这个问题，咱们的口头方向是：业余的工作交给业余的零碎去做。
问题二：外部业务方面
- 须要治理的外部服务数量十分多（上百）
- 局部服务未对接 CAS 实现鉴权
- 新的服务对接 CAS 存在对接老本，反复开发耗时耗力
- 所有服务间接配置在接入层，没有外部服务的标准及最佳实际
带着以上这两方面问题，咱们就开始对网关类产品进行了相干的调研。
为什么抉择了 Apache APISIX
思考到产品成熟度和可拓展性，最终咱们在 Kong 和 Apache APISIX 中进行比照抉择。
Apache APISIX Ingress Controller 已更新到 v1.3 版本
具体详情可查看：https://github.com/apache/api…
从上图比照中能够发现，两者在很多方面根本并驾齐驱，所以存储端成为咱们重点思考的一点。因为 etcd 在咱们公司外部的运维体系上曾经比拟成熟，所以 Apache APISIX 相较 Kong 则稍逊一筹。
同时思考到在开源我的项目层面，Apache APISIX 的国内交换与跟进处理速度上都十分优良，我的项目的插件体系比拟丰盛全面，对各个阶段的应用类型都比拟符合。
所以在 2020 年调研之后，最终抉择了 Apache APISIX 作为有赞行将推出云原生 PaaS 平台的流量网关。
应用 Apache APISIX 后的产品新貌
当咱们开始接入 Apache APISIX 后，前文提到的两方面问题逐个失去了解决。
成果一：优化了架构性能
Apache APISIX 作为入口网关部署在外部服务区域边缘，前端的所有申请都会通过它。同时咱们通过 Apache APISIX 的插件性能实现了与公司外部 CAS 单点登录零碎的对接，之前负责流量转发的账号变为纯业务零碎。同时在前端咱们提供了一个负责鉴权的 SDK 与 Apache APISIX 鉴权接口进行对接，达成一套残缺又自动化的流程体系。
于是问题失去了解决：
- 每次减少新的后端服务，只需调用 Apache APISIX 接口，将新的服务配置写入
- 流量转发通过 Apache APISIX 实现，在网关该做的事件上，它实现得非常优良
- 网关不再是架构中的性能瓶颈
- 对不同的业务需要，能够对立应用同一个网关来实现；业务细节有差别，能够通过插件实现
成果二：外部服务接入标准化
接入 Apache APISIX 后，公司新的外部服务接入时将自带鉴权性能，接入老本极低，业务方能够间接开始开发业务代码。同时在新服务接入时，按外部服务的标准进行相干路由配置，后端服务能够对立拿到鉴权后的用户身份，省时省力。
具体对于外部服务的一些调整细节这里简略介绍一下。
鉴权插件 OPS-JWT-Auth
鉴权插件是基于 JWT-Auth 协定去开发的，用户拜访前端时，前端会先去调用 SDK，去前端本地获取可用的 JWT-Token。而后通过下图的门路取得用户无效信息，放在前端的某个存储里，实现登录鉴权。
部署配置降级
在部署层面，咱们从简略版本经验三次迭代后实现了目前的多集群配置部署。
- 版本一 ：双机房 4 个独立节点，管理程序别离写入每个节点的 etcd
- 版本二 : 双机房 4 个独立节点，主机房三节点 etcd 集群
- 版本三 : 三机房 6 个独立节点，三机房 etcd 集群
目前咱们还是计算与存储混合部署在一起，后续咱们会去部署一个真正高可用的 etcd 集群，这样在管控立体 Apache APISIX 运行时就能够分离出来，以无状态模式部署。
### 新增鉴权插件 PAT-Auth
在往年咱们又新增了 Person Access Token（PAT）的鉴权插件，这个性能相似于在 GitHub 下来调用 Open API 一样，会生成一个集体 Token，能够以个人身份去调用 Open API。
因为咱们本人的运维平台也有一些这样的需要，比方本地的一些开发插件须要以个人身份去拜访云平台上的接口时，这种状况下集体 Token 形式就比拟不便，容许开发本人给本人受权。
目前 Apache APISIX 2.2 版本后已反对多个 Auth 插件应用，当初能够反对一个 Consumer 运行多个 Auth 插件的场景实现。
更多玩法待开发
降级运维自动化
在应用 Apache APISIX 的过程中，咱们也经验了几次版本变动。但每次降级，都或多或少呈现因为兼容性而导致革新开发，实现后进行线上变更，运维效率效率较低。所以后续咱们会尝试在存储面部署三机房 etcd 集群的同时，将 Apache APISIX 运行面容器化实现主动公布。
traffic split 插件应用
traffic split 是 Apache APISIX 在最近几个版本中引入的插件，次要性能是进行流量拆散。有了这个插件后，咱们能够依据一些流量头上的特色，利用它去主动实现相干操作。
如上图在路由配置上引入 traffic split 插件，如果当有 Region=Region1 的状况，便将其路由到 Upstream1。通过这样的规定配置，实现流量管控的操作。
东西向流量治理
咱们的应用场景中更多是波及到在内网多个服务之间去做服务，调用鉴权时能够依附 Apache APISIX 做流量治理。服务 A、服务 B 都能够通过它去调用服务 C，两头还能够退出鉴权的插件，设定其调用对象范畴、环境范畴或者速率和熔断限流等，做出相似这样的流量管控。
外部权限零碎对接
之后咱们也打算将公司的权限零碎与 Apache APISIX 进行对接，鉴权通过后，断定用户是否有权限去拜访后端的某个资源，权限的管理员只需在管控立体上做对立配置即可。
这样带来的一个益处就是后端的所有服务不须要各自去实现权限管控，因为当下所有流量都是通过网关层解决。
Go Plugin 开发
目前 Apache APISIX 在计算语言层面已反对多计算语言，比方 Java、Go 以及 Python。刚好咱们最近实现的云原生 PaaS 平台，也开始把技术栈从 Python 往 Go 上转移。
心愿后续在应用 Apache APISIX 的过程中，能够用 Go 去更新一些咱们曾经实现了的插件，期待在后续的迭代中给有赞产品带来更多的益处。
对于作者
作者戴诺璟，来自有赞技术中台，运维平台开发工程师。
对于 Apache APISIX
Apache APISIX 是一个动静、实时、高性能的开源 API 网关，提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。Apache APISIX 能够帮忙企业疾速、平安的解决 API 和微服务流量，包含网关、Kubernetes Ingress 和服务网格等。
- Apache APISIX GitHub：https://github.com/apache/apisix
- Apache APISIX 官网：https://apisix.apache.org/
- Apache APISIX 文档：https://apisix.apache.org/zh/…
