remove server-info plugin

[LiteSun]

Why to remove server-info plugin

When APISIX is deployed in traditional mode, restarting APISIX triggers the server-info plugin to write data to etcd. If too many APISIX instances write to etcd at the same time, it may cause etcd to become unavailable. This can prevent APISIX from starting properly, which in turn affects the data plane (DP) and its ability to handle traffic.

If you need to continue using the server-info plugin, before APISIX begins handling production traffic, refer to the etcd example hardware configurations to test and determine how much etcd hardware resources are required for the number of APISIX instances you’re running. This ensures APISIX can start up reliably.

What are the alternatives?

There is currently no perfect alternative. If you still need the information provided by the server-info plugin, you might consider developing a new plugin to store this data in a different backend such as Redis or MySQL. Alternatively, you can continue using the server-info plugin with caution, making sure that sufficient etcd hardware resources are provisioned

Deprecation schedule

• 3.13.0 – Deprecation begins:

  • Marked as deprecated
  • Documentation updated
  • Warning logs emitted

• 3.14.0 – Grace period:

  • No functional changes
  • Gives developers time to adapt

• 3.15.0 – Extended grace period:

  • Continued support
  • More time for migration and community feedback

• 3.16.0 – Final removal:

  • The feature will be completely removed from this version onward

Considering the uncertainty in APISIX's release cycle, this functionality will be officially deprecated no later than 6 months after the release of version 3.13.0.

[jizhuozhi]

Current limit-req and other rate-limiting plugins offer both local and Redis modes. However, using local mode fails to accurately limit rates (req * N) when using a highly available, multi-replica API Six, while using Redis introduces unnecessary latency (for hot keys, it can only be executed on a single shard, even in a Redis cluster). A natural alternative is to use a divergent convergence approach for decentralized rate limiting, preserving the speed of local mode while maintaining the relatively accurate cluster-based req of Redis mode.

However, to implement the divergence-convergence method, I need a place to store the list of all instances. My current idea is to use etcd as the registry center to register all instances, and use changes to this instance list to update the allocation of local rate limiting values. Therefore, I hope to retain this plugin and provide an API to query the entire registered list.