微服务依赖管理的陷阱与模式( 五 )

文章图片
图7：将写入SLO与控制和数据库组件对齐
按照相同的逻辑，我们来检查上传新图像的SLO 。当客户请求向PetPic加载新图像时， API必须请求控制组件以验证内容，这需要150毫秒到800毫秒。除了检查滥用内容之外，控制组件还会验证图像??是否已存在于数据库中。现有图像被视为已验证（并且不需要重新验证）。历史数据显示， Furland和Happytails的客户倾向于在两个地区上传相同的图像集。当数据库中已经存在图像时， Control组件可以为其创建一个新ID ，而无需复制数据，这需要大约50毫秒。这段旅程适合大约一半的写入请求， 50%的延迟情况总计为250毫秒。
包含滥用内容的图像通常需要更长的时间来处理。控制组件返回响应的时间限制为800毫秒。此外，如果图像是狗或猫的有效图片，并且假设它不在数据库中，则数据组件可能需要长达1000毫秒来保存它。考虑到所有数字，在最坏的情况下，返回响应可能需要近2000毫秒。正如你在图7的左列中所见， 2000毫秒远远高于当前SLO工程师为写入而预测的时间，这表明他们在提出SLO时可能忘了包括不良场景。为了缓解这种不匹配现象，你可以考虑将第99个百分位的SLO与请求截止时间绑定。这种情况也可能导致服务性能不佳或错误。例如，数据库可能会在API向客户端报告超过操作期限后才完成图像写入过程，从而导致客户端混乱。在这种情况下，最好的策略是与数据库团队合作提高数据库性能或调整PetPic的写入SLO 。
要点
确保你的分布式产品为客户提供正确的SLO是非常重要的。在构建外部SLO时，你必须考虑所有后端的当前SLO 。你应该考虑所有不同的用户旅程以及请求生成响应可能采取的不同路径。如果需要更好的SLO ，请考虑更改服务架构或与后端所有者合作以改进服务。将服务和后端保持在同一位置，可以更轻松地确保SLO对齐。
作者介绍
SilviaEsparrachiari已在谷歌担任软件工程师11年了，她曾在用户数据隐私、垃圾邮件和滥用预防领域任职，最近在谷歌CloudSRE工作。她拥有分子科学学士学位和计算机视觉和人机交互硕士学位。她目前在谷歌的工作重点是促进一个相互尊重和多元化的环境，让人们可以更好地提高他们的技术技能。
【微服务依赖管理的陷阱与模式】BetsyBeyer是谷歌纽约分部的技术作家，专门研究站点可靠性工程（SRE）。她与他人合著了《站点可靠性工程：谷歌如何运行生产系统》（2016年）、《站点可靠性工作簿：实施SRE的实用方法》（2018年）和《构建安全可靠的系统》（2020年）。在她迄今为止的职业生涯中， Betsy还学习了国际关系和英国文学，她拥有斯坦福大学和杜兰大学的学位。