如何利用 Apache APISX 晋升 Nginx 的可观测性

​
“ 可观测性 ” 是一种度量伎俩，不便把握基础设施、零碎平台或者应用程序的运行状况。常见的伎俩是收集 metrics、logging 和 tracing 及 events 数据，能够帮忙开发 / 运维人员检测、考察、预警和纠正零碎问题。
​
本文将从 Nginx 可观测性、Apache APISIX 与 Nginx 的关系、Apache APISIX 可观测性，以及联合 Apache SkyWalking 进一步晋升可观测性这些方面分享对于可观测性的计划与实际。
​

Nginx 的可观测性

​

1、Nginx 常见监控形式

​
Nginx 在肯定水平上可能做到可观测，以下列举出 Nginx 的常见监控形式：
​

• ngx_http_stub_status_module。
• VTS module + [exporter] + prometheus + grafana。（如果 Nginx 版本比拟低，须要引入 exporter）

• Nginx Amplify SaaS。
  ​

  ngx_http_stub_status_module

  ngx_http_stub_status_module 次要收集实例级别的统计信息。
  ​

  VTS module

  VTS module 有三个比拟显著的毛病。
  ​

• 装置简单
  尽管 VTS module 可能采集指标，采集的指标类型也比拟多，然而它的装置比较复杂。如果想要采纳 VTS module，须要从新编译 Nginx，在编译 Nginx 之前退出 VTS moudle，实现编译后重新安装 Nginx 才能够失常应用 VTS。
  ​
• 扩大能力弱
  VTS 扩大能力分为两局部，一是在编译之前给 VTS 减少扩大；二是在编译之后减少扩大 —— 批改 nginx.conf 配置文件。通过批改 nginx.conf 文件来减少扩大会使 Nginx reload，生产环境间接 reload 或多或少会对业务产生一些影响。
  ​

• 社区更新迟缓
  VTS module 最新的一次更新是在 2018 年，曾经停摆 3 年了。
  ​

  Nginx Amplify SaaS

  ​
  Nginx Amplify 是一个 SaaS 服务，Nginx Amplify 在远端提供服务，在 Nginx 服务之外装置 Agent。
  ​
  在 Nginx 之外装置采集模块，那么在采集指标上就会有限度，只能拿到 Nginx 裸露进去的信息，没有裸露的外部信息是拿不到的。
  ​
  另外，这是一个 SaaS 服务，须要通过公网将采集到的数据传到服务端，这会带来一些安全隐患，同时把一些企业用户阻挡在里面。或者 Nginx Amplify 的目标群体是 Nginx plus 这样的企业用户，不是开源用户。
  ​
  Nginx Amplify SaaS 社区也不沉闷，曾经停摆 2 年。
  ​

  2、Nginx 本身 Events 缺点

  ​
  Nginx 在 Events 收集上本身有缺点，这里列举出两个问题：
  ​
  一、Nginx 基于 nginx.conf 进行配置，批改后通过 reload nginx.conf 文件使配置失效。除 reload 事件外，没有其余 Events 可用，咱们无奈得悉每次批改文件的变动，如：起初只配置一个路由，批改文件减少十个路由，只有 reload 事件无奈得悉减少的十个路由是哪十个路由。
  ​
  二、Nginx 开源产品短少被动健康检查。Nginx 是一个反向代理，真正的后端服务可能会呈现重启、降级或者异样的状况，如果没有被动的健康检查，依附被动查看，只能在流量出现异常的时候，才晓得服务出了问题，这会丢掉很多 Events，导致上游 Events 事件信息不残缺。
  ​

  3、Nginx 可观测性总结

  ​
  Nginx 的开源版本没有提供十分好用的监控。尽管 Nginx 提供了一些监控工具，但这些工具的装置和配置非常复杂，简直没有扩展性。可能这些工具的设计并不是为了可观测性，只是为了能看到指标或统计数据，不便定位问题。当初有各种可观测性设置类的产品，然而很难集成到 Nginx 上。
  ​
  另外，Nginx 社区停滞不前，导致 Nginx 迭代速度慢。
  ​

  Apache APISIX 概述

  ​

  1. Apache APISIX 与 Nginx 的关系

  ​
  
  Apache APISIX 基于 Nginx 实现，但只依赖 Nginx 的网络库，在 Nginx 根底上，Apache APISIX 实现了本人的外围的代码，并预留了扩大机制。
  ​
  在表格中列出了 Apache APISIX 和 Nginx 的性能比照，Apache APISIX 既能够做反向代理，又能够做 Nginx 不反对的性能，如：被动健康检查、流量治理、横向扩缩容等，而且这些性能都是开源的。
  ​

• API 设计：在 API 设计方面应用 Apache APISIX 更加简略。
• 开源 Dashboard：在界面上就能把反向代理全副配置完。
• 被动健康检查：Apache APISIX 反对被动健康检查，能够联合 Events 欠缺可观测性。
• 流量治理：适宜监测数据，或者在业务公布上线时应用。
• 横向扩缩容：Apache APISIX 反对横向扩缩容，这个个性得益于 Apache APISIX 的架构（见下图）。
• 插件扩大机制
• 插件编排：依照业务需要，将多个插件依照逻辑编排，组合起来应用
• 动静的证书治理
  ​

2、Apache APISIX 简介

​
Apache APISIX 是一个动静、实时、高性能的 API 网关，提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。Apache APISIX 也是全世界最沉闷的开源 API 网关我的项目，是生产可用的高性能网关。寰球已有数百家企业应用 Apache APISIX 解决要害业务流量，涵盖金融、互联网、制作、批发、运营商等等，比方美国航空航天局（NASA）、欧盟的数字工厂、中国航信、中国移动、腾讯、华为、微博、网易、贝壳找房、360、泰康等。
​

3、Apache APISIX 解决方案

​

​
上图右边，从上往下的是从单体服务到 SOA（面向服务的架构）到微服务的演进过程。
​
在 SOA 下，网关个别采纳 Nginx 或者 HAProxy；在微服务架构下，网关应用 Nginx 做负载平衡。微服务架构有两个比拟常见的解决方案：一个是基于 Java 技术栈实现，如 Spring Cloud 系列；另一个是 Service Mesh。在这个演进过程中，Apache APISIX 处于什么地位，能做什么呢? 简略的说，左图中红色的局部（Nginx / HAProxy / Kong / Spring Cloud Zuul / Spring Cloud Gateway / Traefik / Envoy / Ingress Nginx）都能够替换为 Apache APISIX 的解决方案。
​
在 SOA 下有 Apache APISIX SLB 解决方案，在微服务架构下有 Apache APISIX Gateway，在 Kubernetes 部署有 Apache APISIX Ingress，在 Service Mesh 里部署有 Apache APISIX mesh。
​

​
从业务申请的流量方面看，当客户端发动申请时会通过 LB，通过 Gateway，申请被散发到后端业务服务。红色的局部（LB / Gateway / Spring Cloud Gateway / K8s Ingress / Sidecar）都能够抉择 Apache APISIX 作为解决方案。Apache APISIX 反对多语言开发插件，能够在 Java 体系下应用 Java 编写插件。
​
Apache APISIX 是全流量的数据面，在 LB、Gateway、Ingress 和 sidecar 方面 Apache APISIX 都有相应的解决方案，他们是对立的解决方案，在可观测性方面也是对立的计划。当解决方案对立时，管理控制链也是很容易实现进去的。
​

Apache APISIX 的可观测性

​
Apache APISIX 在可观测性上能够做哪些事件？Apache APISIX 可观测性上的劣势在哪里？
​

1、Apache APISIX 反对采集的数据类型

​
Apache APISIX 反对采集的数据类型：
​

• Tracing – 集成 SkyWalking
• Metrics – 集成 SkyWalking / Prometheus

• Logging – 集成 SkyWalking / other Logging Platforms
  ​
  Apache APISIX 是一个网关类的产品，能够代替 Nginx 或者其余的网关；在可观测性上 Apache APISIX 能够集成多个 APM 或可观测性零碎，如：Tracing 局部能够集成 SkyWalking，Metrics 指标上能够集成 SkyWalking 或 Prometheus，Logging 能够集成 SkyWalking 以及其余一些日志零碎。
  ​

  2、Apache APISIX 在可观测性上的劣势

  ​

  2.1、高度扩大能力

  ​
  Apache APISIX 能够通过插件扩大本身的能力，下面提到的三种数据类型，都是通过插件机制来实现的。
  ​
  为什么 Apache APISIX 扩大能力强？因为 Apache APISIX 反对自定义插件。Apache APISIX 反对多语言编写插件，默认采纳 Lua 语言，也能够应用 Java、Golang 等编程语言编写插件。
  ​

  2.2、灵便的配置能力

  ​
  举三个例子来介绍下 Apache APISIX 灵便的配置能力。第一个例子是 Apache APISIX 能够在运行时批改 logging 的配置，如：减少 / 批改日志字段。批改日志字段是一个比拟常见的需要，比方：业务刚开始上线时，配置好了日志字段，零碎运行一段时间后，须要批改或者减少几个日志字段。如果应用 Nginx，通过批改 nginx.conf 文件实现需求，reload 使配置失效。Apache APISIX 只须要通过脚本把字段配置好，就会动静失效。
  ​
  第二个灵便配置能力的例子是 Prometheus 的应用。在 Apache APISIX 里，想要创立 / 删除某一个 metric 或者扩大 metrics labels，只须要在 Prometheus 插件里新增一个 metircs 或者填写相干信息，Apache APISIX 有 hot reload 机制能够间接失效，不须要重启。
  ​
  第三个灵便的配置能力体现在 Apache APISIX 的实现。Apache APISIX 把路由对象全副治理起来，在内存里有一套对象管理机制。在 Apache APISIX 里给某个 API 加插件，失效的级别能够细化到 API，每一个 API 都能够绑定插件，也能够从 API 上把插件去掉。Apache APISIX 能够精细化管制到每一个服务外面每一个 API 的可观测性数据采集。换句话说，你能够只采集最关怀的数据，而且这些配置都是动静失效的，能够随时调整。
  ​

  2.3、沉闷的社区

  ​
  Apache APISIX 最重要的一个劣势是有一个沉闷的社区，一个沉闷的社区能够让产品疾速迭代、变得越来越欠缺，让大家的需要失去满足。
  ​
  
  上图展现的是 Apache APISIX（绿色）、Kong（浅蓝）、mosn（黄色）、bfe（深蓝）贡献者增长曲线，Apache APISX 增长趋势最快，曲线最为平缓。Apache APISIX 社区活跃度在同类型我的项目外面是最沉闷的。
  ​

  联合 Apache SkyWalking，在可观测性上做进一步晋升

  ​
  Apache APISIX 与 Apache SkyWalking 联合能够做哪些晋升？除了 SkyWalking tracing 插件，还能够将 tracing、metrics、logging 和 events 汇聚到 SkyWalking，借助 SkyWalking 的聚合能力让数据实现联动。
  ​

  1、SkyWalking Satellite

  ​
  SkyWalking Satellite 由 Apache APISIX 社区、Apache SkyWalking 社区、百度深度合作开发。
  ​
  
  SkyWalking Satellite 依照上图步骤采集数据，SkyWalking Satellite 能够部署到更凑近产生数据的前端，以 sidecar 的模式存在。图中从上往下业务申请通过 Apache APISIX 代理到 Upsteam，Satellite 在 Apache APISIX 的旁边，以 sidecar 的模式部署，收集 Apache APISIX 的 tracing、metrics、logging 这三种数据类型的数据，通过 GRPC 协定发送给 SkyWalking。最重要的一点是：在这种部署形式下，Apache APISIX 不须要做任何改变就能够间接将三种数据类型集成到 SkyWalking。
  ​

  2、ALS 计划

  ​
  ALS（Access Log Service）将通过 Apache APISIX 的拜访日志发送进去，在一般的 access log 上减少非凡的字段，如：减少关键字段便于生成拓扑图，同时聚合出 metrics。
  ​
  ALS 计划最大的益处是能够间接通过 access log 形式剖析和聚合出拓扑图、metrics 和 logging 这三种类型的数据。
  ​
  在应用 Prometheus 时，如果配置了 URI 级别的 metrics 指标的统计，会导致整个 metrics 急剧收缩。因为 URI 级别的服务可能有几十个，每个 metrics 前面可能有许多 labels，这会升高网关性能，减少 metrics 获取难度。应用 ALS 计划，通过流的形式将数据发送给 SkyWalking，把计算的事件交给 SkyWalking，后续也不便查问，不会呈现每隔几秒钟拉取一次十分宏大的数据的状况。
  ​

  3、将 Events 整合到 SkyWalking

  ​
  罕用的 Events 包含：配置散发、集群变动和健康检查。
  ​

• 配置散发：在配置 API 散发时，可能会新增 / 批改 / 删除路由、减少插件。
  ​
• 集群变动：集群发生变化时，须要晓得集群里的服务数。如：扩容时 IP 会发生变化，变动体现在网关收到音讯的时候。每个过程都是一个事件，这些事件都须要被裸露进去。
  ​

• 健康检查：被动探测是否衰弱。如：业务申请失败率忽然变高，事件探测到业务服务不衰弱，此时能够疾速定位到问题。
  ​

  延长浏览

  ​
  问：Apache APISIX 的扩大机制是怎么实现的，扩大这个性能是否对 Apache APISIX 自身稳定性有影响？。
  ​
  答：Apache APISIX 扩大机制得益于它的架构，能够在各个 phases（rewrite / access / header_filter / body_filter / preread_filter / log）减少业务逻辑。稳定性方面，Apahce APISIX 曾经开源了近 50 个插件，每一个插件都会有端到端的测试，这些插件都是通过验证的、是稳固可用的。然而自定义插件要遵循肯定的标准，尽管很简略，然而大家也不能太随便。自定义插件的稳定性保障，须要由业务方本人来保障。
  ​
  问：Nginx 的 nginx.conf 文件外面可能配置了很多规定，前面的规定可能被后面的规定拦挡，不分明前面的规定是否失效，Apache APISIX 是否有什么办法晓得哪些规定已失效？
  ​
  答：Nginx 的 nginx.conf 文件配置越多，配置服务越简单，这个文件越难以保护。
  ​
  然而在 Apache APISIX 里配置文件是固定的，Apache APISIX 官网提供的配置就是在大多数场景下的最优配置，其余路由的配置是通过 API 的形式配置进去的，路由配置都是在内存外面的。在治理形式上，能够通过多种组织形式治理你的路由，如：能够通过 Dashboard 来治理。
  ​
  举例说明，比方有一个服务叫 ABC，在这个服务上面可会有各种路由定义，路由定义通过列表的形式进行查看，路由里有一个字段叫优先级，能够通过配置路由的优先级字段，让类似的路由规定依照优先级顺次匹配。另外一种路由查看形式是在 dashboard 中给 API 打上标签，能够让路由的治理变得更加人性化，便于依照标签过滤查问路由列表。
  ​

  对于作者

  ​
  金卫，Apache APISIX PMC 和 Apache SkyWalking committer
  ​
  

  对于 Apache APISIX

  ​
  Apache APISIX 是一个动静、实时、高性能的开源 API 网关，提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。Apache APISIX 能够帮忙企业疾速、平安的解决 API 和微服务流量，包含网关、Kubernetes Ingress 和服务网格等。
  ​
  寰球已有数百家企业应用 Apache APISIX 解决要害业务流量，涵盖金融、互联网、制作、批发、运营商等等，比方美国航空航天局（NASA）、欧盟的数字工厂、中国航信、中国移动、腾讯、华为、微博、网易、贝壳找房、360、泰康、奈雪的茶等。
  ​

• 余位贡献者，一起缔造了 Apache APISIX 这个世界上最沉闷的开源网关我的项目。聪慧的开发者们！快来退出这个沉闷而多样化的社区，一起来给这个世界带来更多美妙的货色吧！
  ​
• Apache APISIX GitHub：https://github.com/apache/apisix
• Apache APISIX 官网：https://apisix.apache.org/
• Apache APISIX 文档：https://apisix.apache.org/zh/…