设计云应用程序时应当注意的4个事项

在为云设计应用程序时，无论选择何种平台，我经常发现在最初的讨论中考虑四个特定主题很有用；可扩展性、可用性、可管理性和可行性。

重要的是要记住，本文中每个主题下的项目并不是一个详尽的列表，其目的只是为与项目利益相关者进行一系列长期而详细的对话提供一个起点，这是对任何应用程序的设计最重要的部分。这些对话的目的应该是产生一个初步到高级的设计和架构。这是通过在客户项目要求的范围内全面考虑这四个关键要素来实现的，始终记住考虑任何设计决策的副作用和权衡（即我们得到了什么，我们失去了什么，或者我们做了什么）。

1可扩展性

关于可扩展性的讨论应该集中在向应用程序和相关服务添加额外容量以处理负载和需求增加的任何需求上。在设计可扩展性时，考虑每个应用程序层、它们应该如何单独扩展以及我们如何避免争用问题和瓶颈尤为重要。需要考虑的关键领域包括：

容量

• 我们是否需要扩展单个应用程序层，如果需要，我们如何在不影响可用性的情况下实现这一目标？

• 我们需要多快完成扩展单个服务？

• 我们如何为应用程序或其任何部分添加额外的容量？

• 应用程序是否需要以 24x7 的规模运行，或者我们可以在工作时间以外或周末进行缩减吗？

平台/数据

• 在大规模工作（数据库大小、事务吞吐量等）的同时，我们能否在所选持久性服务的约束范围内工作？

• 我们如何划分数据以在持久性平台约束（例如最大数据库大小、并发请求限制等）内帮助可伸缩性？

• 我们如何确保有效地利用平台资源？根据经验，我通常倾向于基于许多小实例的设计，而不是较少的大实例。

• 我们能否以最大限度地减少内部网络流量和资源使用，同时保持高效的可扩展性和未来的代码可维护性？

负载

• 我们如何改进设计以避免争用问题和瓶颈？例如，我们可以在合作生产者、竞争消费者模式中的服务之间使用队列或服务总线吗？

• 哪些操作可以异步处理以帮助平衡高峰时段的负载？

• 我们如何使用平台功能进行速率调整（例如 Azure 队列、服务总线等）？

• 我们如何使用平台功能进行负载平衡（例如 Azure 流量管理器、负载平衡器等）？

2可用性

可用性描述了解决方案以对消费者有用的方式运行的能力，尽管应用程序和底层操作系统、网络和硬件依赖项中存在暂时或持久的故障。实际上，对于可用性和可伸缩性的项目之间通常存在一些交叉。应至少涵盖以下项目：

正常运行时间保证

• 产品需要满足哪些服务水平协议 (SLA)？

• 可以满足这些 SLA 吗？我们计划使用的不同云服务是否都符合所需的级别？请记住，SLA 是复合的。

复制和故障转移

• 应用程序的哪些部分最容易出现故障？

• 故障对系统的哪些部分影响最大？

• 应用程序的哪些部分可以从冗余和故障转移选项中受益？

• 是否需要数据复制服务？

• 我们是否仅限于特定的地域可用区域？如果是，我们计划使用的所有服务是否都可用于这些地域？

• 我们如何防止损坏的数据被复制？

• 从故障中恢复是否会给系统带来过大的压力？我们是否需要实施重试策略和或断路器？

灾难恢复

• 如果发生灾难性故障，我们如何重建系统？

• 在灾难恢复场景中丢失多少数据（如果有）是可以接受的？

• 我们如何处理备份？除了数据复制，我们还需要备份吗？

• 如果发生故障，我们如何处理“进行中”的消息和队列？

• 我们是幂等的吗？我们可以重播消息吗？

• 我们在哪里存储我们的虚拟机镜像？我们有备份吗？

性能

• 可接受的性能水平是多少？我们如何衡量？如果我们低于这个水平会发生什么？

• 我们可以使系统的任何部分异步以提高性能吗？

• 系统的哪些部分竞争最激烈，因此更有可能导致性能问题？

• 我们是否可能会遇到可能导致性能问题的流量高峰？我们可以自动扩展或使用以队列为中心的设计来解决这个问题吗？

安全

这本身显然是一个巨大的话题，但可以探索一些与云计算直接相关的有趣项目，包括：

• 保存数据的当地法律和司法管辖区是什么？请记住也包括保存故障转移和指标数据的国家/地区。

• 是否需要联合安全（例如 ADFS 与 Azure Active Directory）？

• 这是一个混合云应用程序吗？我们如何保护公司和云网络之间的链接？

• 我们如何控制对云提供商管理门户的访问？

• 我们如何限制其他服务（例如 IP 地址白名单等）对数据库等的访问？

• 我们如何处理定期更改密码？

• 服务解耦和多租户如何影响安全？

• 我们将如何处理操作系统和供应商安全补丁和更新？

3可管理性

这个话题涵盖了我们了解实时系统的运行状况和性能以及管理站点操作的能力。一些有用的特定于云的注意事项包括：

监控

• 我们打算如何监控应用程序？

• 我们是要使用现成的监控服务还是自己编写？

• 监控/指标数据将物理存储在哪里？这是否符合数据保护政策？

• 我们的监控计划将产生多少数据？

• 我们将如何访问指标数据和日志？随着数据量的增加，我们是否有计划使这些数据可用？

• 是否需要审计和日志记录？

• 我们能否承受丢失一些指标/日志/审计数据（即我们是否可以使用异步设计“即发即忘”来帮助提高性能）？

• 我们是否需要在运行时更改监控级别？

• 我们需要自动异常报告吗？

部署

• 我们如何自动化部署？

• 我们如何在不中断实时系统的情况下修补和/或重新部署？我们还能满足 SLA 吗？

• 我们如何检查部署是否成功？

• 我们如何回滚不成功的部署？

• 我们需要多少环境（例如开发、测试、登台、生产）以及如何部署到每个环境？

• 每个环境都需要单独的数据存储吗？

• 每个环境都需要 24x7 可用吗？

4可行性

在讨论可行性时，我们会考虑在预算和时间限制内交付和维护系统的能力。值得研究的项目包括：

• 能否满足 SLA（即是否有云服务提供商可以提供我们需要向客户提供的正常运行时间保证）？

• 我们是否拥有设计和构建云应用程序所需的内部技能和经验？

• 我们能否在预算限制和对业务有意义的时间范围内根据我们的设计构建应用程序？

• 我们需要在运营成本上花费多少（云提供商通常具有非常复杂的定价结构）？

• 我们可以明智地减少什么（范围、SLA、弹性）？

• 我们愿意接受哪些权衡？

5结论

考虑这四个主题（可用性、可扩展性、可管理性和可行性）将帮助您发现应用程序中需要一些特定于云的思考的领域，特别是在项目的早期阶段。每项下列出的项目绝对不是详尽无遗的，但应该为您提供一个很好的讨论起点。

本文翻译学习，原文链接：https://www.codur.com/publications/cloud-application-design-considerations >>> 欢迎投稿，微信：devopsvip。

关于我们

DevOps云学堂，专注于企业级DevOps运维开发技术实践分享，主要以新Linux运维技术、DevOps技术课程为主。丰富的一线实战经验，课程追求实用性获得多数学员认可。课程内容均来源于企业应用，在这里既学习技术又能获取热门技能，欢迎您的到来！

更多DevOps实践，请关注「DevOps云学堂」

 点击阅读原文，进入企业DevOps学堂