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

文章图片
图1：一个API产品解耦为五个独立的微服务
微服务的好处
在微服务架构中运行产品提供了一系列好处。总体而言，因为产品所有者可以在不同位置部署松散耦合的二进制文件，所以他们能够在具有成本效益和高可用性的部署方案中做出选择，在云中或在他们自己的机器中托管每项服务。它还允许独立的垂直或水平扩展：增加每个组件的硬件资源，或复制允许使用不同独立区域的组件。
另一个好处与开发生命周期有关。由于每个服务在逻辑上都与其他服务分离，并且内部复杂性较低，因此开发人员更容易推理其实现中的更改，并保证新功能具有可预测的结果。这也意味着每个组件都能做到独立开发，允许开发人员在不干扰其他服务的情况下对一个或多个服务进行本地更改。发布可以独立推进或回滚，从而带来对中断的更快反应速度和更专注于核心的生产更改。
微服务面临的挑战
尽管有那么多优点，但基于微服务的架构也可能会让某些流程处理起来更加困难。在接下来的部分中，我将展示我之前提到的一些场景（虽然我改动了一些其中涉及的真实姓名）。我将详细介绍每个场景，包括一些与管理微服务相关的令人难忘的痛点，例如调整前端和后端之间的流量和资源增长需求。我还将讨论如何设计故障域，以及如何基于所有微服务的组合SLO计算产品SLO 。最后，我将分享一些有用的技巧，希望这些技巧可以帮助节省你的时间并预防最终的客户中断。
场景一：PetPic
我们的第一个场景围绕一个名为PetPic的虚构产品展开。如图2所示， PetPic是一项全局服务，可为两处地理区域（Happytails和Furland）的狗狗爱好者提供狗的照片。该服务目前在每个地区都有100个客户，总共有200个客户。前端API运行在独立的机器上，每台机器都位于其中一个区域。作为一个复杂的服务， PetPic有多个组件，但在第一次研究中我们将只考虑其中一个组件：数据库后端。该数据库运行在云端的一个全局区域中，并为Happytails和Furland两个区域提供服务。

文章图片
图2：全局PetPic服务
问题：调整流量增长
目前该数据库在高峰时使用了其所有资源的50% 。考虑到这一点，产品负责人决定在PetPic中实现一项新特性，让它也可以向客户提供猫的照片。新特性实现后，工程师决定首先在Happytails区域推出这项特性。这样，他们可以在向所有人提供新特性之前找出意外的热情用户流量或资源使用变化。考虑到两个地区的用户基数相同，这在当时似乎是一个非常合理的策略。
为准备上线，工程师将Happytails中API服务的处理资源增加了一倍，数据库资源增加了10% 。上线很成功。客户增长了10% ，这可能表明一些爱猫人士加入了PetPic 。数据库资源利用率在峰值时为50% ，再次表明额外资源确实是必要的。
所有信号都表明用户增长10%需要数据库资源也增长10% 。为了准备在Furland区域推出新特性， PetPic工程师向数据库中添加了10%的额外资源。他们还将Furland的API资源增加了一倍，以应对新客户的需求。这些更改与在Happytails推出新功特性时所做的完全相同。
他们在周三为Furland用户推出了这项新特性。然后，在午餐时间，工程师开始收到大量警报，报告用户了服务返回HTTP500错误代码——这意味着用户无法使用该服务了。这与Happytails的上线经历完全两回事。此时，数据库团队联系到工程部，提到数据库资源利用率在两小时前（上线后不久）就达到了80% 。他们试图分配更多的CPU来处理额外的流量，但这一更改在今天之内不太可能实现。同时， API团队检查了用户增长图，并报告没有出现与预期不同的变化：该服务现在共有220个客户。由于工程团队中没有人能找出任何明显的中断原因，他们决定中止发布并在Furland中回滚该特性。