总结
Contoso Shoes 是一家在线鞋店，希望在即将推出期间高度可用。 两年前，他们将其本地部署迁移到云，并通过采用 OpEx 模型受益。 在过去六个月里，他们遇到了可用性问题，并且操作员无法快速解决问题。 组织现在希望投资于使工作负载成为关键任务，并专注于提高系统的整体可靠性和可观测性。
在以前的体系结构中，应用程序部署在单个区域中，无法承受区域中断。 Azure 应用服务和外部监视工具没有办法检查应用程序本身的运行状况。 这种差距导致流量路由到运行不正常的应用服务实例，从而导致请求失败。 团队看不到 API 组件影响其平台依赖项所导致问题的级联影响。
通过完成这一挑战，你已大致了解了任务关键型设计。 你通过练习应用了学习内容，以满足 Contoso 的需求。
改进的设计使用运行状况模型检测到一个或多个组件的性能下降。 SRE 团队现在可以在问题导致全面中断之前快速识别和解决问题。 解决方案以主动-主动模式部署在多个区域之后，它可以承受完整的区域故障，同时为其操作者提供更多系统运行状况见解。 Contoso 还通过在地理位置更靠近客户的区域中更快地为客户提供服务，改善了他们的客户体验。
祝贺你完成此挑战项目。 你已验证了分析现有示例解决方案和设计改进的体系结构方面的技能。
建议执行的后续步骤
已完成的练习是一个良好的开端，但它们并未涵盖任务关键型工作负载的所有方面。 继续探索“架构良好的任务关键型工作负载”中给出的设计原则和领域。 建议学习以下重要价值领域：
持续验证和测试
必须完全验证应用程序代码和基础结构的运行状况。 范围必须涵盖可靠性、性能、可用性、安全性、质量和规模的要求集。
详细了解：持续验证和测试
使用多个应用程序环境
强烈建议开发/测试环境不应与生产环境共享资源。 每个环境都有自己的可靠性、容量和安全性要求。 是否可以识别跨环境共享的此体系结构中的服务？ 如何更改设计以与此建议保持一致？
详细了解：应用程序环境
展开的部署环境
任务关键型系统需要严格的预发布测试和可靠的软件开发生命周期 (SDLC) 做法。 不使用单个共享开发环境，而是使用与过渡和生产更紧密一致的多个临时环境。 你应该使用专用的过渡环境进行负载和性能测试、混沌测试、用户验收测试 (UAT) 以及安全测试。
详细了解：临时蓝/绿部署
通过消息代理提高复原能力
引入消息代理以帮助处理需要与多个终结点协调的复杂事务。 可将请求加入队列以等待处理，避免冒着因单个组件故障而造成销售损失的风险。
详细了解：松散耦合事件驱动的体系结构
了解更多
有关在 Azure 上设计解决方案的详细信息，请参阅 Azure 架构良好的框架指南。
在 Azure 体系结构中心中探索这些参考体系结构，作为扩展设计的一种方式：