微软

Azure架构良好的框架:性能效率支柱

性能的博客

Azure架构良好的框架于2020年7月推出,以帮助管理日益复杂的云。

该框架由五个卓越的建筑支柱组成:

框架的支柱很少能单独实现。随着工作负载的功能能力不断增长,它对系统的影响可能是深远的。成本优化必须与绩效效率相平衡。相反,卓越运营可以补充和提高绩效效率。

Azure良好架构框架是一组功能强大的工具。一旦工作负载投入生产,Azure提供Azure Advisor来了解添加功能和服务时发生的更改,因此定期检查工作负载并在关键工作负载上使用Azure的监视工具是一个很好的实践。

绩效效率支柱—一个例子

“如果你唯一的工具是锤子,那你就很难吃意大利面。——大卫·艾伦。

下面的场景表示Azure客户端对性能的需求,目标是设计具有吞吐量需求的RESTful API服务。该需求与相对的可靠性和成本需求相平衡。

可靠性模式是提高系统可用性所必需的,但通常包括对用户不可见且在相关数据中不可用的重试机制,因此可感知的性能会下降。重试或其他可靠性模式将记录发生情况和时间长度,以识别性能下降。

成本可能会根据扩展资源实例的需求而受到影响。如果流量增加并且是意外的,那么扩展将增加成本,或者Azure中配置的成本上限将阻止足够的扩展来满足性能要求。

让我们使用一个具有分布式云架构的场景。我还将介绍一些额外的工具,如k6、Postman、WireMock、Faker和Azure Application Insights,这些工具已经成为您工具箱中的新工具。

分布式架构的挑战

“如果我能更快地连接到服务器,我的电脑就不需要硬盘了……相比之下,随身携带这些不联网的电脑就太麻烦了。”~——史蒂夫·乔布斯,苹果公司联合创始人、前首席执行官和董事长

您现在可能已经猜到,我们的重点将是使用全局分布式体系结构、操作数据收集和检测的客户端场景。此场景使用Azure应用程序洞察的一个特征。Azure监控.我们正在创建一个显示查询数据的仪表板,以确定影响相互依赖系统的问题,包括目标解决方案的性能。我们的目标是性能效率,这是通过将应用程序的可用资源与对这些资源的需求相匹配来实现的。

回到我们的项目场景,它使用Azure应用程序服务作为面向客户端的API资源。做出这一决定有几个原因,超出了我们的讨论范围性能的支柱.然而,Azure应用程序服务是一个自然的设计选择为我们的要求。对于大多数其他选项,你将需要仪表你的应用程序Azure应用程序洞察,但App Services默认集成了App Insights Agent。通过选择此选项,应用程序默认具有运行时监控。安装App Insights SDK提供了额外的灵活性,但对于项目场景来说并不是必需的。

如果您还记得的话,我们的场景具有分布式体系结构。我们的仪器具有分布式遥测相关性。可以开始了,对吧?好吧,除非你将“operation_Id”配置为请求id的值。

倾听和适度调整

“在我成长的过程中,我一直想成为某个人。现在我意识到我应该说得更具体些。——莉莉·汤姆林

既然我们已经讨论了性能监视,那么让我们来讨论该场景的功能需求。客户端为团队提供了任意3秒的性能SLA来处理任何请求。幸运的是,我们的解决方案提供了“自动定量”对于我们的应用实例。我们可以使用我们的仪器来确保我们通过设置警报来满足3秒的要求。尽管这个溶液很活泼。从生产的角度来看,我们不知道历史上的吞吐量是多少。

基线——根据事实行动

那么,让我们回到绩效效率支柱。假设有一场意想不到的风暴正向你所在的某个区域移动。销售部门预计API的流量会意外增加。现在企业对3秒服务水平协议的感觉如何?我们可以猜测我们将从该区域获得多少额外流量,并设置自动缩放的上限,以适应推测的缓冲。我们可以让人随叫随到,手动管理潜在的需求。

但是,我们将请求平均流量和峰值流量的历史数据,因为我们使用了性能效率支柱。在收集性能需求时,云工程的一个方面是确保您拥有业务峰值和预期需求增长的历史基线和目标基线。

在这一点上,采访、倾听、理解和记录项目的关键目标和指标是至关重要的。确定它将如何在有边界的上下文和领域内交互,影响内部和外部客户。问一些引导性的问题,以确定可能转变为差距的期望。有时候,这些数据是某人回忆中的隐性知识。然而,大多数公司保留了至少几年前的营销分析。

如果有基于季节性业务线的基于事件的减速,比如滑雪行业或游泳池供应或经济趋势,可能会导致我们应用程序的流量异常,那么这个基线数据还可以提供成本效益。

好了,我们已经尽职调查过了。我们已经作出了推断,我们的结论也得到了接受。然而,我们现在需要在平均负载和峰值负载下测试我们的应用程序,并且我们有一个来自产品负责人的新需求。我们一直在使用“Postman”来执行API的功能测试和自动化集成测试,我们的客户希望从这些测试的工作中得到一些重用。

虽然基于JMeter的广泛使用使用它是理想的,因此可以减少客户端的人员配置问题,但它没有提供与Postman所需的接口。经过一些研究,我们找到了一个产品,(k6, 2021),微软认可它。它是一种现代的云工具,集成了DevOps自动化测试,占用空间很小。然而,它推出还不到一年,但却拥有很高的声誉、越来越多的用户和出色的文档。使用应用程序(带有模拟响应)并执行我们在基线分析期间收集的所有吞吐量模型的概念证明(POC)提供了解决方案是合理的证据。

校长

我们考虑了所有的Azure良好架构框架原则并达成了一个解决方案。我们已经求过了性能模式从设计的角度来权衡。

POC和模型测试

“如果终端用户在你的网站上看到了糟糕的表现,她的下一个点击可能会是your-competition.com。”伊恩Molyneaux

项目示例的设计和实现使用k6分割成URL和Payload, Postman作为数据源,JavaScript模块,并在Payload中包含WireMock和Faker提供模拟测试数据,这些都是性能解决方案的简单方法。在部署RESTful api时,您可以开发在测试迭代阶段重用所必需的模块化。

  • 通过将Postman与“k6”集成来生成url和有效载荷。
  • 使用注入模拟输入数据骗子将业务规则转换为有效负载中的占位符。
  • 我们根据全球位置和要求测试平均和峰值场景的产品定义测试场景。由于我们的测试是隔离的,我们可以确保在引入下一阶段测试之前为位置提供测试数据。
  • 测试返回每个场景的平均、最小、最大、平均、90和95吞吐量结果。

转K6演示

结果比预期的要快得多,即使在触发重试事件时也是如此。随着全局位置的添加,吞吐量趋于正常。尽管上面的结果是在一个演示系统上执行的,但是虚拟用户、迭代和持续时间与客户端基线的性能测试是一致的。

检查表

....连阿憨和楚伊都有清单。~乔恩·斯图尔特

现在我们已经到了Azure良好架构的性能模式针对非功能性和功能性需求的适用性。然后我们从设计的角度权衡并记录了这些权衡。

我们已经完成了具有代表性的性能测试,考虑了预期的延迟问题。我们已经完成了框架检查表包括设计建议。捕捉的性能数据Azure应用程序洞察

结论

Azure良好架构框架的此场景可作为Perficient的微软Azure团队为了我们的客户。这里讨论的一些模式和实践已经使用了几十年,有些则更特定于云设计。它们具有必须根据需求进行评估的设计权衡。

在发布之前的性能测试期间提供隔离将确保仅对应用程序而不是其依赖项验证额外的延迟。Application Insights的使用为您的服务提供了响应时间(吞吐量),并可以在正确配置时提供相关性测试。该框架是一个指导方针,并考虑体系结构权衡基于领域和功能需求。该框架的使用已被证明成功地满足了业务目标,同时提供了灵活性。

参考文献

转k6。(2021年11月)。转k6文档。从k6文档检索:https://k6.io/docs/

微软。(2021年12月)。性能效率检查表。检索自Azure产品文档:https://docs.microsoft.com/en-us/azure/architecture/framework/scalability/performance-efficiency

微软。(2021年12月)。性能效率模式。检索自Azure产品文档:https://docs.microsoft.com/en-us/azure/architecture/framework/scalability/performance-efficiency-patterns

微软。(2021年12月)。绩效效率原则。检索自Azure产品文档:https://docs.microsoft.com/en-us/azure/architecture/framework/scalability/principles

微软。5月(2022)。性能效率的权衡。检索自Azure产品文档:https://docs.microsoft.com/en-us/azure/architecture/framework/scalability/tradeoffs

微软Azure文档。5月(2022)。应用程序洞察中的遥测相关性。检索自Azure Monitor文档:https://docs.microsoft.com/en-us/azure/azure-monitor/app/correlation

在部署RESTful api时,在测试迭代阶段重用所必需的模块化。


为什么Perficient ?

我们帮助各行各业的客户开发战略解决方案,并加速创新云项目雷竞技raybet提现。作为经过认证的Azure直接云解决方案提供商(CSP),我们通过提供支持来保持Microsoft Azure操作的正常运行,从而帮助您推动创新。

无论您的IT团队是否缺乏某些技能,或者只是需要为大型业务提供支持,我们都可以提供帮助。我们的专业知识和全面的全球支持将帮助您充分利用Azure的丰富功能。

联系我们的团队了解更多。

留下回复

你的电邮地址将不会公布。必填字段已标记

这个网站使用Akismet来减少垃圾邮件。了解如何处理您的评论数据

罗伯特·迪安

Rob是微软业务部门Perficient的解决方案架构师,在Azure团队工作,对新兴云架构和框架的工作充满热情。Rob提供企业级软件架构解决方案已经超过20年了。在他的职业生涯中,他为各个垂直市场的许多跨职能团队和客户提供了技术、设计和流程领导,并提供了咨询、指导和教练。Rob已经完成了IDesign架构师的硕士课程,并学习和实现了Zachman、TOGAF和FEA软件架构方法,并于2015年开始了他的云迁移和解决方案之旅。

更多来自作者

关注我们
推特 Linkedin 脸谱网 Youtube Instagram