在 360基础运维平台项目中的实践
API 网关选型
2019 年 10 月，我们团队计划改造 360 基础运维平台的网关层，当时我们主要调研了社区几个比较活跃的网关，如 Kong，Orange，Apache APISIX，最终选择了 Apache APISIX 当时主要是考虑到 Apache APISIX 的存储选型 etcd 比较符合我们的使用场景。
线上运行情况
目前我们添加到网关的 API 数量接近 900 个，日均 PV 1000 万左右，从监控系统来看，网关以及我们各个微服务均运行良好。
- 日均 PV
- 网关 POD 监控
- 微服务负载监控图
基础运维平台架构图
下图是我们运维平台项目最终的架构图，网关服务我们部署在公司的容器云上，etcd 服务我们是在 3 台虚机上部署了一套集群。
容器化开发和部署
接下来我具体介绍一下我们是如何使用 Apache APISIX 搭建网关服务的，首先先给大家看下我们网关项目的代码结构
之前我给王院生(Apache APISIX PMC 之一 )看我们的项目代码结构时，他惊讶的问我，说怎么没有看到 Apache APISIX 的 core 代码。
实际上这是我们在使用容器安装 Apache APISIX 时探索出来的一条道路。它给我们带来最大的好处是，我们业务的代码和 Apache APISIX 的核心代码完全分开，方便 Apache APISIX 升级，也方便我们的业务代码迭代。
插件化开发
1、项目插件介绍
正如在上面代码结构图中所看到的，我们项目的 apisix 目录里面有两个目录，libs 和 plugins，libs 里面我们放一些常用的类库，plugins 里面存放我们自定义的业务插件，我们所有的业务都采用插件机制来开发。 下图是我们项目中目前使用到的插件。
稍微解释一下，我们项目的入口域名有两个，一个是提供给 openApi 访问的，认证插件使用的是 Basic Auth，一个是提供给 web 浏览器访问的，认证插件使用的是 web auth(cookie 认证)。
对应 OpenResty 的请求处理流程，我们的插件主要集中在 access 和 log 阶段
| 插件 | 阶段 | 描述 |
|---|---|---|
| ip-restriction | access_by_lua | ip 限流，使用 apisix 原生插件 |
| basic-auth | access_by_lua | 对 openApi 请求用户鉴权，自研插件 |
| web-auth | access_by_lua | 对 webApi 请求用户鉴权，自研插件 |
| limit-rate | access_by_lua | 对请求实现用户级别和用户+请求参数级别的限流，自研插件 |
| proxy-rewrite | access_by_lua,balancer_by_lua | 对请求进行转发，设置接口级别的超时时间，自研插件 |
| log | log_by_lua | 将请求日志记录到 kafka，再通过 logstash 读到 es 中，自研插件 |
| alarm | log_by_lua | 根据响应的 statusCode 来报警，自研插件 |
2、Etcd 缓存对象
etcd 缓存对象的原理是利用 etcd 的 watch 功能，将数据从 etcd 缓存到内存对象中，业务使用的时候直接从内存中读取，避免网络 io 消耗，etcd 的 watch 功能又保障了数据的实时性，Apache APISIX 的这一特性，简直是让人拍案叫绝。
上线后遇到的问题
crontab 清理日结
由于我们网关部署在容器，运行一段时间之后，日志文件超过了默认的配额 50G，后来我们在镜像里面默认安装了 cron 和 logrotate，然后在容器 entrypoint 里面开启了 cron 用来解决这个问题。
感谢
最后特别感谢一下 Apache APISIX 的贡献者们，贴出 Apache APISIX 官网[2] 和 Apache APISIX Github 地址[3]
References
[1] etcd 官方文档: https://doczhcn.gitbook.io/etcd/index
[2] Apache APISIX 官网: https://apisix.apache.org/
[3] Apache APISIX Github 地址: https://github.com/apache/apisix
以上就是本次分享的内容~
如果有什么建议，也可以在我们评论区留言，供大家参考学习。
