11、云服务间延迟、本地运行及部署实践

云服务间延迟、本地运行及部署实践

在云服务的使用中，服务间延迟是一个需要关注的重要问题。当同一项目中的一个服务向另一个服务发出请求时，请求总是会经过 GFE 服务器，这就会带来一定的延迟。经过测试发现，最小延迟惩罚在 7 到 9 毫秒之间，在进行服务设计时需要考虑这一限制。

服务间延迟的教训案例

曾经在开发一个电商产品列表页面时，需要调用两个远程服务，一个返回产品数据，另一个返回价格。但价格服务不支持批量调用，于是只能逐个为每个产品添加价格并将页面推向生产环境。起初一切正常，但后来收到了页面偶尔加载缓慢的投诉。原因在于所有调用是顺序进行的，忽略了每次调用给页面加载增加的延迟。之后天真地将代码更新为并行向价格服务发出所有请求，虽然短期内解决了页面加载缓慢的问题，但每次页面加载都会给价格服务带来流量突发，价格服务难以承受。这个案例告诉我们，不要假设延迟为零，并且尽量在服务之间进行粗粒度的集成，而非细粒度的集成。

演示应用介绍

接下来通过一个包含两个服务的集成示例，展示如何在本地使用 Docker Compose 运行示例，以及如何使用单独的服务账户将两个服务部署到 Cloud Run。

嵌入式只读 SQL 数据库

此演示展示了一种适用于能在 Cloud Run 实例内存中容纳的数据集的模式。产品 API 使用嵌入式 SQLite 数据库，SQLite 是一种基于文件的关系型数据库，适合不经常更改的数据集，因为更改需要将新的容器镜像推送到 Cloud Run。它实现了大部分 SQL 标准，若未来想迁移到外部数据库，它是 Cloud SQL 上 PostgreSQL 的理想前身。

本地运行步骤 </