英文:
How to temporarily fail/disable REST APIs at runtime?
问题
我正在开发一个REST服务，主要提供两个API：PUT请求和GET请求。
在灾难恢复期间，该服务将处于一种状态，无法接受新的PUT请求，但仍然能够响应GET请求。我正在寻找如何在运行时临时禁用/拒绝传入的PUT API调用（通过返回500或其他非200的状态码），同时服务正在进行灾难恢复。该服务在负载均衡器后面的一组主机上运行，启用了自动扩展。需要临时在运行服务的所有主机上禁用PUT API请求。
我看到了这篇关于在运行时更新配置的帖子：https://stackoverflow.com/questions/1659642/java-update-properties-file-run-time，但看起来这需要在每台主机上手动更新属性文件，如果运行服务的主机数量较多，这可能不是最优解。
想知道是否有其他方法来实现这一目标。提前致谢！
英文:
I am working on an REST service which primarily provides 2 APIs: PUT request and GET request.
During a disaster recovery, the service will be in a state where it cannot accept new PUT requests, but can still be able to provide response for GET requests. I am looking to see how I can temporarily disable/fail incoming PUT API calls (by returning 500s or anything other than 200) at runtime, while the service is actively undergoing a disaster recovery. The service runs on a set of hosts behind a load-balancer, with auto-scaling enabled. The PUT API requests need to be disabled temporarily on all the hosts running the service.
I have com across this post on updating configurations at runtime: https://stackoverflow.com/questions/1659642/java-update-properties-file-run-time, but it looked like this requires manually updating the properties file on each of the hosts, which might not be optimal if we have a large number of hosts running the service.
Wondering if there are other approaches to achieve this. Thanks in advance!
答案1
得分: 1
大多数情况下，负载均衡器位于防火墙后面。如果您可以访问防火墙，您可以在启动灾难恢复之前设置一个任务，以在防火墙中设置规则，并阻止任何连接到目标服务或方法。灾难恢复完成后，设置一个任务来删除该规则并允许连接。
英文:
Mostly, Load-Balancer placed behind firewall. If you have access to your firewall, you can set a task before starting disaster recovery for set a rule in your firewall and blocking any connection to your target service or method using firewall. After DR completed, set a task for drop the rule and allow connections.
答案2
得分: 1
这是Redis或任何其他消息代理的经典用例。
因此，您可以在Redis服务中创建一个通道。如果您的API进入灾难恢复状态，某个东西会发布一条消息。API的所有实例都订阅该通道并接收该消息，并将其缓存在某个地方。在您的路由中添加一个中间件，该中间件在每个请求上检查缓存的值，并在应用程序处于灾难恢复状态时返回错误。然后，当您的应用程序不再处于灾难恢复状态时，向Redis通道发送一条消息，导致所有服务器从缓存中清除该值。
这种解决方案快速、干净、简单且可靠。在运行时更改应用程序配置并不是您想尝试做的事情。配置旨在保持稳定。它不是状态。
英文:
This is a classic use case for Redis or any other message broker.
So, you could create a channel in a Redis service. If your API enters disaster recovery, something publishes a message. All instances of the API are subscribed to that channel and receive the message, and cache it somewhere. Add a middleware to your routes that checks that cached value on every request, and returns an error if the application is in disaster recovery. Then, when your application is no longer in disaster recovery, send a message to the Redis channel causing all the servers to clear the value from cache.
This kind of solution is fast, clean, easy, and reliable. Changing application configuration just isn't something you want to try to do at runtime. Configuration is meant to be stable. It isn't state.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论