共计 3562 个字符，预计需要花费 9 分钟才能阅读完成。
业务背景
小电作为国内共享充电宝服务平台，目前还处于初创阶段。从运维体系、测试环境等方面来讲，当下产品的业务次要面临了以下几个问题：
- 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 路由规定。
性能一：我的项目变更多环境
在变更环境中咱们有两种场景，一个是点对点模式，即一个域名对应一个利用。开发只须要启用域名，DNA 里就会利用 Apache APISIX 去生成对应路由，这种就是繁多门路的路由规定。
另一种场景就是多级门路路由。在这种场景下咱们基于 Apache APISIX 将我的项目变更中须要的多个 APP 路由指向到以后 Namespace 环境，其关联 APP 路由则指向到一套稳固的 Namespace 环境中（通常为 Stable 环境）。
性能二：自动化流程
基于上述我的项目环境的一些路由规定，搭配 Apache APISIX 的 API 调用性能做了一个控制中心，汇合了一些包含域名前缀和对应的利用实例等性能。
比方某个新利用上线时，能够申请一条相应的路由规定，而后把规定加到控制中心中。须要申请路由时，就能够一键启用这条路由规定并主动同步到 Apache APISIX。
另外咱们也提供了繁多一般路由申请，包含线上环境和测试环境，或者一些对外公网的裸露与测试需要等，也能够调用 Apache APISIX 接口。
基于 Apache APISIX 的具体实际
基于 OpenShift 部署
OpenShift 具备十分严格的 SCC 机制，在利用 OpenShift 去部署 Apache APISIX 时遇到了很多问题，所以每次发版都要从新去做编译。
另外基于 Apache APISIX 提供的 Docker 镜像性能，咱们将日常的一些根底软件进行了更新，比方调优和问题查看，通过 Image Rebuild 性能上传到外部镜像仓库。
跨版本平滑解决
咱们一开始应用的 Apache APISIX 为 1.5 版本，在更新到最新版本的过程中，咱们经验了相似 etcd v2 版本性能降落、减少了 CORS 插件强校验等状况。
基于此，咱们采取了版本切流的计划，新版本启用并创立新的 Service 以及裸露相干 SLB 信息。通过 Service 的 Selector 属性，将 Gateway 切换到新版本的 Apache APISIX 中。另一方面咱们也会将流量进行切分解决，将局部流量通过 DNS 解析到新版本 Apache APISIX SLB 地址，来实现版本更迭的平滑解决。
解决 etcd 压缩问题
在应用期间咱们也察看到 Load 始终突高不下的状况，经查看发现 etcd 内的数据量已达到 600 多兆，所以咱们采取了定期压缩 etcd 的措施，将历史事物数据全副革除。具体代码可参考：
ETCDCTL_API=3 etcdctl --endpoints=http://etcd-1:2379 compact 1693729
ETCDCTL_API=3 etcdctl --endpoints=http://etcd-1:2379 defrag获取 Client-IP
在线上业务场景中，咱们须要获取到源 IP 去做相干的业务解决。刚好 Apache APISIX 提供了「X-Real-IP」的性能，通过配置 real\_ip\_header 和开启 externalTrafficPolicy 的 Local 模式进行相干获取操作。
将来冀望
家喻户晓，小电当初是主做共享充电宝业务场景，所以在属性上也是偏物联网方向。
从业务层面登程，咱们也还有一些重要业务比方 MQTT 类型的利用。目前它们在容器内还是以 SLB 模式去裸露的，心愿后续也能够接入到整个 Apache APISIX 集群里。
从前端层面来讲，目前的前端利用还是部署在容器里，后续咱们也打算将前端利用间接接入 Apache APISIX，通过 Proxy Rewrite 插件性能间接指向咱们的阿里云 OSS 域名。这样能够节俭容器部署的资源，进行更不便地治理。
在对 Apache APISIX 我的项目上，咱们通过实际部署也产生了一些改良需要，心愿后续 Apache APISIX 的版本更迭中能够进行相干性能的反对或欠缺。比方：
- 技术治理层面进行多集群性能的增加
- 开发层面进行更细粒度的用户权限治理
- 性能层面反对 SSL 证书滚动更新
- Apache APISIX-Ingress-Controller 相干业务接入
对于作者
作者孙冉，运维专家。目前就任于小电平台架构部，次要负责 K8s 集群和 API 网关的相干部署。
对于 Apache APISIX
Apache APISIX 是一个动静、实时、高性能的开源 API 网关，提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。
Apache APISIX 能够帮忙企业疾速、平安地解决 API 和微服务流量，包含网关、Kubernetes Ingress 和服务网格等。目前已被普华永道数据安全团队、腾讯蓝军、安全河汉实验室和爱奇艺 SRC 等业余网络安全机构测试，并给予了高度认可。
Apache APISIX 落地用户（仅局部）
- Apache APISIX GitHub：https://github.com/apache/apisix
- Apache APISIX 官网：https://apisix.apache.org/
- Apache APISIX 文档：https://apisix.apache.org/zh/…
