如何自动更新和回滚Firebase托管站点+ Cloud Run服务? [英] How to atomically update and roll back a Firebase Hosting site + Cloud Run service?
问题描述
假设我们在Google Firebase Hosting上有一个站点，该站点将一些请求路由到Google Cloud Run服务.该服务完全被视为实现细节，并且它的唯一客户端是单个网站.使用Cloud Run服务的唯一原因是，它是Firebase平台内唯一合适的技术选项.
现在，假设该服务的API在每次更新时都可能会有重大更改，因此Firebase托管内容也必须更改.如何将两个部分一起更新或回滚以避免不兼容?
直接，我们可以在单独的步骤中更新服务和网站内容，但这意味着来自网站旧版本的某些请求可能会到达服务的新版本或相反，从而由于API不匹配而导致错误.同时回滚站点内容和服务时会出现相同的问题.
一种理论上的解决方案是基于修订标签确定地将请求路由到不同的服务修订，但这在Cloud Run中不受支持.
一个可行的解决方案是为网站内容的每次更新创建一个新服务.但是，这将导致服务的无限制累积，而这些服务不会像服务修订版那样被自动删除.
另一个解决方案(在下面提出)将保持服务的向后兼容性-它将支持最新的API版本和以前的API版本.但是，这可以被认为是不必要的开销.由于这两个部分(静态内容和服务)实际上并不需要独立更新，因此避免维护服务中向后兼容性的开销将非常方便.
对于我所知，无法在单个事务中进行此更新来避免这种行为，因为您提到的Firebase和Cloud Run是不同的产品.
API设计中的一个好的做法是允许 服务演进 ，这意味着更新API不会破坏使用该API的应用程序，并且该应用程序的新版本应能够以使用当前API的方式进行发展.
当新API不允许追溯兼容时，要做的事情就是拥有不同的端点，这就是为什么某些API是 apiName/V1/method 和 apiName/v2/method ，但在这种情况下，两个版本的API均已部署.
Suppose we have a site on Google Firebase Hosting that routes some requests to a Google Cloud Run service. The service is considered entirely an implementation detail and its only client is the single website. The only reason for using a Cloud Run service is that it is the only suitable technical option within the Firebase platform.
Now, suppose that the API of the service may have a breaking change with every update, so the Firebase Hosting content must change too. How do you update or roll back both parts together so as to avoid incompatibilities?
Straightforwardly, we can update the service and the site content in separate steps, but that means some requests from the old revision of the site may reach the new revision of the service or the other way around, causing errors due to API mismatch. The same issues are present when rolling back the site content and the service at the same time.
One theoretical solution would be to deterministically route requests to different service revisions based on revision labels, but that is not supported on Cloud Run.
One realistic solution would be to create a new service for every update of the site content. However, that would result in unbounded accumulation of services which are not automatically deleted like service revisions are.
Another solution (proposed below) would be to maintain backwards compatibility in the service - it would support both the latest and the previous API version. However, this can be considered an unnecessary overhead. Since the two parts (static content and the service) have no real need to ever be updated independently, it would be very convenient to avoid the overhead of maintaining backwards compatibility in the service.
For what I know there is no way to make this update in a single transaction to avoid this behavior you mentioned as Firebase and Cloud Run are different products.
Also a good Practice in API design is to allow Service Evolution this means that updating the API shall not break the apps consuming it and new versions of the app shall be able to evolve in a way that they can consume the current API.
Something that is done when a new API will not allow retrocompatibility is to have different endpoints this is why some APIs are apiName/V1/method and apiName/v2/method but in this case both versions of the API are deployed.
这篇关于如何自动更新和回滚Firebase托管站点+ Cloud Run服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
