我计划将API作为web服务提供。然而，当我更新API的（解释的）代码库时，我预计可能需要重新启动API服务，甚至只有一段时间代码被覆盖。这引入了传入API请求可能被丢弃的可能性，或者更糟糕的是，由API触发的进程可能被中断。
python的烧瓶库似乎提供了某种解决方案；通过启用调试模式，它将检查所有python文件上的已修改标志，并且对于每个请求，它将重新加载任何已更改的模块。让我放弃这种方法的并不是表现上的惩罚，而是它看起来有点被抛弃了。
对于一个常见的问题，肯定有一种优雅、高可用性的方法吗？
编辑：正如@piotrek在下面回答的那样，"没有银弹"。一条简短可见的评论建议在更新后使用DNS切换到新的API服务器。
实际上没有银弹。你提到了两件不同的事情。一个是可用性。这取决于你想在9999…可用性中有多少个9。第二件事是api的更改。所以：
-
可用性：
有些技术允许您进行热更改/取消支付。这意味着挂起的请求进入旧路径，新请求进入新路径。如果你的技术不支持它，由于其他原因你就不能使用它，还有其他选择
-
在小型intranet应用程序中，您根本不在乎。你停止了这个世界：停止应用程序，上传新版本，然后开始。在应用程序停止时，许多web框架停止接受新连接，并等待所有挂起的请求完成。如果你的不支持它，你有两个选择：
- 忽略它（数据库将回滚当前事务，用户将得到错误）
- 自己实施（可能很有挑战性）
你尽最大努力缩短不活动的时间。
- 如果你不能停止一切，那么你可以做：
- 聚类。逐个重新启动服务。一直有服务器可用。这并不总是可能的，因为有时你必须更改你的数据库，而不是总是你可以在工作系统上这样做，或者你不能在更新失败的情况下丢失任何数据
- 微服务。如果您将应用程序拆分为许多独立的组件，这些组件与持久队列相连，那么您只会切换系统的某些部分（优雅的降级）。例如，您可以禁用将更改写入数据库但仍允许读取的组件。如果你有快速完成更新的基础设施，那么更新可能会被忽视——请求会被放入队列，并被新版本接收
-
-
api更改：
你的api版本。每个请求都说明它需要哪个版本。
- 如果你控制了所有的客户/小规模/决定不支持旧版本：你不在乎。每个人都必须更新其客户端
- 如果没有，那么微服务可能会有所帮助。您将公共api与内部api分离。如果您保持所有的公共api服务都在运行，并宣布其中一些服务已弃用。您可以监控它们的使用情况。当您决定某个版本的使用率足够低时，您会宣布终止使用，然后关闭特定版本
这是我目前最好的