业务背景
小电作为国内共享充电宝服务平台，目前还处于初创阶段。从运维体系、测试环境等方面来讲，当下产品的业务主要面临了以下几个问题：
- VM 传统模式部署，利用率低且不易扩展
- 开发测试资源抢占
- 多套独立的测试环境（K8s），每次部署维护步骤重复效率低
- 使用 Nginx 配置管理，运维成本极高
在 2020 年初，我们决定启动容器化项目，打算寻找一个现有方案来进行上述问题的解决。
目前公司是以「拥抱云原生」的态度来进行后续业务的方案选择，主要看重云原生模式下的微服务改造、DevOps、持续交付以及最重要的容器化特性。
为什么需要 Apache APISIX
基于上述云原生模式的选择，我们开启了容器化方案搭建。方案主要有三部分组成：
- 自研 Devops 平台 - DNA：这个平台主要是用于项目管理、变更管理（预发、生产环境）、应用生命周期管理（DNA Operator）和 CI/CD 相关功能的嵌入。
- 基于 K8s Namespace 的隔离：之前我们所有的开发项目环境，包括变更环境等都全部注册在一起，所以环境与环境之间的相互隔离成为我们必要的处理过程。
- 动态管理路由的网关接入层：考虑到内部的多应用和多环境，这时就需要有一个动态管理的网关接入层来进行相关的操作处理。
网关选择
在网关选择上，我们对比了以下几个产品：OpenShift Route、Nginx Ingress 和 Apache APISIX。
OpenShift 3.0 开始引入 OpenShift Route ，作用是通过 Ingress Operator 为 Kubernetes 提供 Ingress Controller，以此来实现外部入栈请求的流量路由。但是在后续测试中，功能支持方面不完善且维护成本很高。同时 Nginx Ingres 也存在类似的问题，使用成本和运维成本偏高。
在参与 Apache APISIX 的调研过程中我们发现，Apache APISIX 的核心就是提供路由和负载均衡相关功能，同时还支持：
- 动态路由加载、实时更新
- etcd 存储下的无状态高可用模式
- 横向扩展
- 跨源资源共享（CORS）、Proxy Rewrite 插件
- API 调用和自动化设置
- Dashboard 清晰易用
当然，作为一个开源项目，Apache APISIX 有着非常高的社区活跃度，也符合我们追求云原生的趋势，综合考虑我们的应用场景和 Apache APISIX 的产品优势，最终将项目环境中所有路由都替换为 Apache APISIX。
应用 Apache APISIX 后的变化
整体架构
我们目前的产品架构与在 K8s 中使用 Apache APISIX 大体类似。主要是将 Apache APISIX 的 Service 以 LoadBalancer 类型暴露到外部。然后用户通过请求访问传输到 Apache APISIX，再将路由转发到上游的相关服务中。
额外要提的一点是，为什么我们把 etcd 放在了技术栈外。一是因为早些版本解析域名时会出现偏差，二是因为在内部我们进行维护和备份的过程比较繁琐，所以就把 etcd 单独拿了出来。
业务模型
上图是接入 Apache APISIX 后的业务环境改造模型。每个开发或项目进行变更时，DNA 都会创建一个变更，同时转化为 K8s Namespace 资源。
因为 K8s Namespace 本身就具备资源隔离的功能，所以在部署时我们基于 Namespace 提供了多套项目变更环境，同时包含所有应用副本并注册到同一个 Eureka。我们改造了 Eureka 使得它可以支持不同 Namespace 的应用副本隔离，保证互相不被调用。
功能加持
将上述架构和业务模型实践起来后，每个项目变更都会产生对应的 Namespace 资源，同时 DNA Operator 就会去创建对应的 APP 资源，最后去生成相应的 Apache APISIX 路由规则。
