背景
在日常巡检时发现，MIK-SSR-WEB 的 Grafana 监控中出现 500 的异常响应。
原因分析
1. Grafana监控
在监控面板中发现，503 响应不为 0
2. Skywalking l链路
在 Skywalking 中过滤错误响应，发现所以异常的 URL 均为 /mik-web-static/map/2c-prd/released-menu/michaels_menu_tree.json
在扩大查询范围时发现，此错误持续出现，在业务高峰期时存在响应时间过长的问题。偶发性出现 Socket 超时的问题。
3. ELK 日志
在 ELK 日志中发现，异常请求的日志为errorUrl https://storage.googleapis.com/mik-web-static/map/2c-prd/released-menu/michaels_menu_tree.json, status: 500; statusText: Internal Server Error;
4. GCP Logging
查询 MIK-WEB-STATIC 中的日志，确实存在 GCP Storage 返回 500 异常响应的日志，但是在日志中未发现具体错误原因。
5. GCP Logging 官方文档
由于为查询到具体错误原因，随去查询 GCP 的官方文档，排查错误原因。截取部分信息如下：
Cloud Storage 是一项可扩缩性极强的服务，利用自动扩缩技术来实现极高的请求速率。
负载重新分配时间
当存储桶的 IO 容量即将达到其上限时，Cloud Storage 通常会数分钟检测一次负载，并根据情况将负载重新分配到更多服务器上。因此，如果您存储桶的请求率增长过快，使 Cloud Storage 来不及执行这种重新分配，那么您可能会遇到临时性限制，具体而言，可能出现较长的延迟时间和较高的错误率。 如要避免出现此类延时和错误，请按照下文所述逐渐提高您存储桶的请求率。
如果您遇到任何问题（例如，延迟时间延长或错误率增加），请暂停提升操作或暂时降低请求率，以便为 Cloud Storage 提供更多时间来扩缩您的存储桶。在以下情况下，您应该使用指数退避算法重试您的请求：
收到响应代码为
408和429的错误。收到响应代码为
5xx的错误。
至此，已经确认由于 GCP Logging 限流/限速导致 500 的异常响应。根据官方文档描述，由于 GCP Storage 为一个扩缩容极强的服务，故在扩容阶段未能响应超过限制的请求时将出现 408、429、5XX 的异常响应。
结合 GCP Logging 的时间和 ELK、Skywalking 的的时间线，确认此问题的根本原因是 GCP Storage 存在限流/限速 在扩容阶段响应异常。
改进方案
GCP Storage 文档提示：
通过提升请求速率、选择对象键和分配请求来避免存储桶出现临时性限制的最佳做法。
由于系统面临的突发流量较大，系统无法控制用户行为，所以无法通过逐步提升请求速率的方式进行优化。
为了保持较高的请求速率，请避免使用顺序名称。使用完全随机的对象名称可让您实现负载的最佳分配。如果您想要将序列号或时间戳用作对象名称的一部分，请通过在序列号或时间戳之前添加哈希值来为对象名称引入随机性。
官方建议通过随机名称的方式来实现负载均衡，在后续的优化时可以考虑添加随机前缀的方式来优化性能。
优化建议
-
MIK-SSR-WEB 主动监听 JSON 文件变化，当文件内容发生变化时再重新请求。
-
将 JSON 文件、JS 文件、图片按功能分配到不同的 Bucket 中来避免限流/限速，同时再同一个 Bucket 中的文件名添加随机前缀实现负载均衡。
参考文档
