假设我们在Google Firebase Hosting上有一个网站，将一些请求路由到Google Cloud Run服务。该服务完全被认为是一个实施细节，其唯一的客户端是单个网站。使用Cloud Run服务的唯一原因是，它是Firebase平台内唯一合适的技术方案。
现在，假设服务的API每次更新都可能会有突破性的变化，那么Firebase Hosting的内容也必须改变。如何将两部分一起更新或回滚，以避免不兼容的情况发生？
直截了当的说，我们可以分步骤更新服务和网站内容，但这意味着网站旧版本的一些请求可能会到达新版本的服务，或者反过来，导致API不匹配而出现错误。当同时回滚网站内容和服务时，也会出现同样的问题。
一种理论上的解决方案是根据修订标签将请求确定地路由到不同的服务修订版，但 Cloud Run 不支持这种方法。
一个现实的解决方案是为网站内容的每次更新创建一个新服务。然而，这将导致服务的无限制积累，而这些服务不会像服务修订版那样自动删除。
另一种解决方案（下面提出）是在服务中保持向后兼容性--它将同时支持最新和以前的API版本。然而，这可以被认为是一个不必要的开销。由于这两个部分（静态内容和服务）并没有真正需要独立更新，因此避免在服务中保持向后兼容的开销将是非常方便的。
据我所知，由于Firebase和Cloud Run是不同的产品，所以没有办法在一个事务中进行更新来避免你提到的这种行为。
另外，在API设计中，一个好的做法是允许 服务进化 这意味着更新API不会破坏消耗它的应用程序，并且新版本的应用程序应能够以一种他们可以使用当前API的方式发展。
当一个新的API不允许追溯兼容时，会有不同的端点，这就是为什么有些API是 apiName/V1/method 和 apiName/v2/method 但在这种情况下，两个版本的API都被部署。