关于apisix:Apache-APISIX-310-版本正式发布

时隔一个月，新版本又来了。这次的 APISIX 3.1.0 是 3.0 大版本以来的第一个新版本，在 3.x 的新时代里，咱们判若两人地在每个版本中给大家奉上更多的新性能。

此次公布的 3.1.0 版本，增加了对插件配置的加密存储和存储在内部平安服务的反对，着重于让用户可能更平安、更释怀地应用他们的配置。在这之外，咱们还引入了许多新的个性，旨在优化对 APISIX 的应用体验。

新个性：插件配置的加密存储

新版本反对将插件的特定字段加密保留到 etcd 中。

在之前的版本中，APISIX 提供了一个 key_encrypt_salt 的配置项，反对对 etcd 外面存储的 SSL key 进行加密，防止明文存储私钥数据。毕竟像私钥这样的敏感数据，少一个中央存储明文，就能多一份安心。那么对于其余同样敏感的配置，比方 jwt-auth 插件中的 secret，咱们能不能也加密起来，防止在 etcd 外面存储明文呢？

3.1 版本中就把加密存储的性能拓展到其余字段上。有了这个性能，咱们能够在某个特定的插件上指定须要加密的字段，而后在 config.yaml 文件中开启加密，即可防止明文存储。

举个例子，咱们给 jwt-auth 插件新增了如下的标记：

     encrypt_fields = {"secret", "private_key"},

当咱们在 config.yaml 里开启了字段的加密性能：

apisix:
    data_encryption:
        enable: true
        keyring:
            - edd1c9f0985e76a2

那么写入到 etcd 的 jwt-auth 插件的配置中的 secret 和 private_key，就会被加密存储。通过 etcdctl get --prefix / 看到的配置，会是诸如“”secret”:”77+NmbYqNfN+oL…””这样的数据，而不是原始的配置信息。

新个性：将敏感信息存储在内部平安服务

除了能够将敏感信息加密存储在 etcd 之外，还能够抉择从别的零碎中动静获取敏感信息，而不再要求敏感信息必须存储在 APISIX 的配置存储（如 etcd）中。

在 3.1 版本中，咱们上线了名为 APISIX Secret 的性能。APISIX Secret 容许用户在 APISIX 中通过一些密钥治理服务（Vault 等）来存储 secret，在应用的时候依据 key 进行读取，确保 secret 在整个平台中不以明文的模式存在。

APISIX 目前反对通过以下形式存储 secret：

• 环境变量
• HashiCorp Vault

相干示例

以 key-auth 插件为例，咱们来简略示范下如何应用该个性。

基于环境变量的敏感信息存储

第一步：APISIX 实例启动前创立环境变量

export JACK_AUTH_KEY=abc

第二步：在 key-auth 插件中援用环境变量

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"username":"jack","plugins": {"key-auth": {"key":"$ENV://JACK_AUTH_KEY"}
    }
}'

通过以上步骤，能够将 key-auth 插件中的 key 配置保留在环境变量中，而不是在配置插件时明文显示。

基于 Vault 的敏感信息存储

第一步：在 Vault 中创立对应的配置，能够应用如下命令：

vault kv put apisix/jack auth-key=value

第二步：通过 Admin API 增加 Secret 资源，配置 Vault 的地址等连贯信息：

curl http://127.0.0.1:9180/apisix/admin/secrets/vault/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri":"https://127.0.0.1:8200"，"prefix":"apisix","token":"root"}'

第三步：在 key-auth 插件中援用 APISIX Secret 资源，填充配置在 Vault 中的地位：

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"username":"jack","plugins": {"key-auth": {"key":"$secret://vault/1/jack/auth-key"}
    }
}'

通过以上步骤，能够将 key-auth 插件中的 key 配置保留在 Vault 中，而不是在配置插件时明文显示。

新个性：实验性基于 gRPC 的 etcd 配置同步

在本次新版本中，咱们还引入了实验性的基于 gRPC 的 etcd 配置同步。以后 APISIX 同步 etcd 的配置，是基于 HTTP long pulling，这就要求 etcd 开启 gRPC-gateway（所幸的是默认就是开启的）。

在实际过程中，咱们遇到了 etcd 的 HTTP API 呈现问题，兴许是因为通过 HTTP 同步配置并非 etcd 的支流应用形式，所以会更容易遇到 bug。通过把 etcd 配置同步由 HTTP long pulling 切换到 gRPC 下面来，APISIX 实现了同步形式与支流接轨。

另外因为 gRPC 自身提供了多路复用的反对，改用 gRPC 同步配置能大幅升高 APISIX 到 etcd 的连接数。以后 APISIX 同步每一类配置都要有独立的 HTTP 连贯，切换到 gRPC 后每个过程只有一条用于配置同步的连贯（如果开启了 L4 代理，那么是两条）。

启用实验性的基于 gRPC 的配置同步，须要在配置文件 config.yaml 中设置 use_grpc: true，如下所示：

  etcd:
    use_grpc: true
    timeout: 3600
    host:
      - "http://127.0.0.1:2379"
    prefix: "/apisix"

新个性：基于 Consul 的服务发现

在 APISIX 之前的版本里，有热心的贡献者提供了基于 Consul KV 的服务发现实现。不过 Consul KV 跟 Consul 本身的服务发现性能有些不同，Consul 本身的服务发现反对额定的一些性能，比方对注册服务的健康检查，所以在应用上会更为宽泛些。本次 3.1 版本中，另一位热心贡献者提供了基于 Consul 的服务发现，填补了这一空缺。

基于 Consul 的服务发现和之前版本里基于 Consul KV 的服务发现有着类似的配置。首先，须要在 config.yaml 文件中启用该服务发现：

discovery:
  consul:
    servers:
      - "http://127.0.0.1:8500"

而后在具体的 upstream 中配置对应的 service_name 和 discovery_type：

curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '{"service_name":"service_a","discovery_type":"consul"}'

对应的 upstream 在应用过程中，就会依据 Consul 外面配置的值去失去真正的上游节点。

新个性：内置的调试插件

工欲善其事，必先利其器，调试是程序员日常工作的一部分。作为重视调试体验的网关，APISIX 在 3.1 版本中以插件的模式内置了一个 Lua 调试器插件，反对动静设置断点、增加回调等等。

默认的配置如下：

plugins:
    ...
    - inspect
    ...

plugin_attr:
  inspect:
    delay: 3
    hooks_file: "/usr/local/apisix/plugin_inspect_hooks.lua"

APISIX 在启动后，会定期查看配置的 hooks_file（这里是 “/usr/local/apisix/plugin_inspect_hooks.lua”），如果文件中有内容，就会依据外面的内容设置断点和回调。比方下方内容会给 limit-req.lua 的 88 行上设置一个断点，并在该断点上注册了回调函数 function(info) ... end。

local dbg = require "apisix.inspect.dbg"

dbg.set_hook("limit-req.lua", 88, require("apisix.plugins.limit-req").access, function(info)
    ngx.log(ngx.INFO, debug.traceback("foo traceback", 3))
    return true
end)

新性能：优化以及更多小性能

除了下面提到的几个大的性能外，此次公布也蕴含许多值得述说的改变，比方：

• 优化 Prometheus 指标采集的资源占用
• 反对在 L4 的代理中，配置域名作为上游
  如果你对新版本的残缺更新细节感兴趣，请参考 3.1.0 公布的 changelog：https://github.com/apache/apisix/blob/release/3.1/docs/zh/latest/CHANGELOG.md#310