ryan4yin opened a new issue, #9703: URL: https://github.com/apache/apisix/issues/9703
### Current State Our usage scenario is that we want to use APISIX to handle iterations between the new system and the old one. Because the new system may have potential performance or stability problems running for a long time, to ensure the availability of the whole system, we implemented a deployment method to make APISIX passing requests to the new system by default, and use the old system as a **fallback server**. Considering that others might have the same need, I created this issue to record it and wanted to discuss the possibility to add it to APISIX's FAQ. related to: - https://github.com/apache/apisix/discussions/7773 - http://nginx.org/en/docs/http/ngx_http_upstream_module.html @tzssangglass has helped me to implement this feature, thanks again! ### Desired State The whole workaround describes below. First, create an upstream, and set the old system's `priority` to `-1`, thus the old system wil be marked as a backup server. It will be passed requests only when the primary servers(the new system) are unavailable. ```curl curl -i -X PUT http://127.0.0.1:9180/apisix/admin/upstreams -H "X-API-KEY: ${API_KEY}" -d ' { "id": "xxx-with-fallback", "desc": "xxx's upstream with the old system as backup nodes", "scheme": "http", "type": "roundrobin", "keepalive_pool": { "size": 200, "idle_timeout": 75, "requests": 1000 }, "nodes": [ { "host": "<the-domain-of-new-system-1>", "port": 8080, "weight": 0 }, { "host": "<the-domain-of-new-system-2>", "port": 8080, "weight": 0 }, { "host": "<the-domain-of-the-old-system-1>", "port": 8080, "weight": 0, "priority": -1 }, { "host": "<the-domain-of-the-old-system-2>", "port": 8080, "weight": 0, "priority": -1 } ], "retries": 1, "retry_timeout": 3, "timeout": { "connect": 1, "send": 1, "read": 1 }, # ... other configs ... }' ``` and then we need to define in what scenario we think the new system is unavailable, so the request will be passed to the old system. so archive this goal, we should add configuration into APISIX's `config.yaml`： ```yaml apisix: node_listen: 8080 # APISIX listening port enable_heartbeat: true enable_admin: true enable_admin_cors: true enable_debug: false # ... other configurations http_server_configuration_snippet: | # Add custom Nginx http server configuration to nginx.conf. # The configuration should be well indented! # Specifies in which cases a request should be passed to the next server(the fallback server with priority=-1): proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 non_idempotent; # in case you want to limits the number of possible tries for passing a request to the fallback server(the new system), enable this line: # proxy_next_upstream_tries 1; # ... other configurations ``` With those two configurations, through these configurations, we can implement the fallback feature mentioned above using APISIX. Generally, if there is a problem with the new system, the retry mechanism of APISIX we configured here will always be triggered, so the requests can always be processed properly, and no users are affected. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
