谷歌云部署服务的几个常见问题

前阵子帮一个刚做海外业务的开发者排查问题，他把创业项目的核心服务迁到了谷歌云，本地测试一切正常，上线后时不时会出现请求延迟波动，一开始他觉得是代码写得有问题，查了快一周没找到原因。很多普通开发者接触谷歌云的机会不多，大多是做面向海外用户的项目时才会用到，对它的产品逻辑和使用习惯不熟悉，很容易踩一些提前规划就能避开的坑。我自己前几年帮不同项目做过几次谷歌云的部署和排查，积累了一些实际的经验，整理出来供参考。

资源位置选择很容易被忽略

谷歌云的资源划分逻辑是地域和可用区，地域指一个大的地理区域，可用区是同一个地域下多个互相独立的物理机房，彼此之间用低延迟网络连接，做容灾的时候可以跨可用区部署。很多第一次用谷歌云的人，创建资源的时候直接点默认选项，默认选的地域不一定符合你的用户分布，我见过好几个案例，用户群体在东亚，默认选了远隔万里的其他区域，结果就是所有请求都要跨长距离传输，延迟比就近部署高三到五倍，还容易出现链路波动。

这个问题排查的时候很容易被忽略，因为大家出问题都会先查代码、查配置，不会想到最基础的资源位置选择出了错。刚才提到的那个开发者朋友，后来把服务迁到离用户近的地域之后，延迟直接降了七成多，波动也基本消失了，整个过程没改一行代码，只是调整了资源的物理位置。

选位置的时候还要考虑另一个因素，就是开发团队的位置，如果团队都在同一个区域，把开发环境放在远的地域，开发调试的延迟也会很高，直接影响开发效率。如果终端用户和开发团队距离比较远，可以分开配置，开发环境放在离团队近的地域，生产环境放在离用户近的地域，两边都能兼顾。这一点看起来简单，但很多新手第一次接触的时候真的会忽略，最后花很多时间排查才找到问题根源。

对象存储的权限坑

很多开发者用谷歌云的对象存储服务放静态资源，比如网页的静态文件、用户上传的头像之类的，权限配置这里很容易出错。我之前遇到过一个开发者，他把整个前端项目都托管在对象存储上，配置完之后本地测试没问题，上线之后所有用户都打不开资源，浏览器一直报权限错误。他查了域名解析，查了HTTPS配置，折腾了两天都没找到问题，后来才发现，他创建存储桶的时候，默认权限是只有项目所有者能读，他忘了给公开访问加对应的读取权限。

反过来，也有另一种常见的坑，就是为了排查问题方便，直接把存储桶的所有权限都开放给所有人，哪怕里面存了一些不应该公开的配置文件或者非公开的用户数据，这就会带来明显的安全风险。谷歌云的权限模型是分层的，从项目到存储桶再到单个对象，都可以单独配置权限，新用户很容易搞混不同层级的权限规则，要么给多了要么给少了。

还有一个容易忽略的点，谷歌云的身份访问管理功能，默认会给新项目创建默认的服务账号，很多新手不会去调整服务账号的权限，默认的权限有时候会比服务实际需要的大，这也会留下不必要的安全隐患。实际操作里，最好遵循最小权限原则，给每个服务账号只开它完成工作必须的权限，不要直接用大权限的默认账号跑线上服务。如果是放公开静态资源，只给匿名用户读取存储桶中对应路径的权限就够，不要开放写入或者删除权限；如果是放私有数据，一定要完全关掉公共访问，不要图方便留缺口。

监控告警不要过度也不要不开

很多开发者把服务部署上线之后，就很少再去看后台的资源状态，特别是中小项目，平时流量不大，觉得不会出问题，结果就是有时候资源耗尽或者链路出问题，过了很久才发现，对用户使用造成不小的影响。其实谷歌云自带了完整的基础监控功能，不需要额外搭建第三方监控系统，默认就可以采集所有计算资源、存储资源、网络资源的核心指标，比如CPU使用率、内存占用、磁盘IO、网络出入流量这些，还可以对服务做定期健康检查。弹性伸缩的规则也可以和监控告警结合，设置好触发阈值，自动增减计算资源的数量，不用人工手动操作，应对突发流量的时候更稳定。

你只要提前设置好告警规则，比如CPU连续五分钟超过百分之八十，或者服务健康检查连续失败三次，就可以发通知到你指定的接收渠道，就能第一时间知道出问题，不会等用户反馈才发现。我之前接触过一个项目，就是因为没开告警，凌晨的时候流量突增把资源占满了，服务挂了六个小时才被发现，对业务造成了不小的损失，后来开了自动告警加弹性伸缩，就再也没出过类似的问题。

这里也要提一个常见的误区，很多人开了监控之后，觉得越多越安全，设置了一大堆告警规则，一点小波动就发告警，结果就是团队成员慢慢都把告警静音了，真的出问题的时候反而看不到，这种情况就是所谓的告警疲劳。所以告警规则不是越多越好，要只针对真正会影响服务可用性的核心指标设置，无关的次要指标不要加告警，保证告警的有效性，这一点是比较关键的。

容灾规划的小细节

很多中小项目用谷歌云，一开始图省事，只开一个可用区的资源，这个本身对于低要求的项目来说没问题，但是如果你的服务对可用性要求比较高，最好还是跨同一个地域下的两个可用区部署。同一个地域下的不同可用区，物理距离不远，网络延迟很低，额外增加的成本不多，但是如果某一个可用区出了电力或者网络故障，另一个可用区的资源可以顶上来，不会整个服务都中断。

这里有一个容易错的地方，很多人做跨可用区部署的时候，只把计算资源分布在不同可用区，却把所有数据都只存在一个可用区的本地磁盘里，这样就算计算资源在另一个可用区，数据出问题还是会导致整个服务中断。所以数据层面也要做跨可用区的备份或者同步，谷歌云的大部分托管存储服务本身就默认做了多可用区的冗余，用官方的托管服务比自己把数据存在计算实例的本地磁盘里要省心很多，可靠性也更高。

还有一个容易被忽略的点，就是不用的闲置资源要及时清理，很多人测试的时候开了不少资源，包括计算实例、静态IP、存储桶这些，测试完之后就忘了关，闲置的资源没人维护，很容易出现配置漏洞没被发现，带来不必要的安全风险，及时清理也能让整个项目的资源架构更清晰，后续排查问题也更方便。

总的来说，谷歌云的产品设计整体比较清晰，大部分功能的参考文档也比较完整，对普通开发者来说，只要提前做好基础规划，大部分坑都是可以避开的。最需要注意的就是不要不管配置直接用默认选项，很多默认设置是为了新手创建方便，不一定符合你实际的业务需求，多花十分钟核对基础配置，能省下后面好几天的排查时间。