云计算应用程序_云应用程序设计注意事项

云计算应用程序

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

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

可扩展性

有关可伸缩性的讨论应集中在为应用程序和相关服务增加额外容量以应对负载和需求增加的任何要求上。 在设计可伸缩性时，考虑每个应用程序层，如何分别扩展以及如何避免争用问题和瓶颈尤为重要。 要考虑的关键领域包括：

容量

• 我们是否需要扩展各个应用程序层，如果需要，如何在不影响可用性的情况下实现这一目标？
• 我们需要多长时间扩展单个服务？
• 我们如何为应用程序或应用程序的任何部分增加额外的容量？
• 应用程序是否需要以24×7的比例运行，还是可以例如在工作时间以外或周末缩小比例？

平台/数据

• 在大规模（数据库大小，事务吞吐量等）工作时，我们能否在所选持久性服务的约束下工作？
• 我们如何在持久性平台约束（例如最大数据库大小，并发请求限制等）内对数据进行分区以帮助扩展性？
• 我们如何确保我们有效地利用平台资源？ 根据经验，我通常倾向于基于许多小实例而不是更少的大实例进行设计。
• 我们可以折叠层以最小化内部网络流量和资源使用，同时保持有效的可伸缩性和将来的代码可维护性吗？

加载

• 我们如何改进设计以避免争用问题和瓶颈？ 例如，我们可以在协作生产者，竞争性消费者模式下的服务之间使用队列或服务总线吗？
• 哪些操作可以异步处理以帮助平衡高峰时段的负载？
• 我们如何使用平台功能进行费率平均（例如，Azure队列，服务总线等）？
• 我们如何使用平台功能进行负载平衡（例如，Azure Traffic Manager，负载平衡器等）？

可用性

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

正常运行时间保证

• 产品需要满足哪些服务水平协议（SLA）？
• 可以满足这些SLA吗？ 我们计划使用的不同云服务是否都符合要求的级别？ 请记住， SLA是复合的 。

复制和故障转移

• 应用程序的哪些部分最容易遭受故障的威胁？
• 故障对系统的哪些部分影响最大？
• 应用程序的哪些部分可以从冗余和故障转移选项中受益？
• 是否需要数据复制服务？
• 我们是否局限于特定的地缘政治地区？ 如果是这样，我们计划在这些区域使用所有服务吗？
• 我们如何防止损坏的数据被复制？
• 从故障中恢复是否会对系统造成过大压力？ 我们是否需要实施重试策略和/或断路器？

灾难恢复

• 如果发生灾难性故障，我们如何重建系统？
• 在灾难恢复方案中丢失多少数据（如果有）是可以接受的？
• 我们如何处理备份？ 除了数据复制外，我们是否还需要备份？
• 发生故障时，我们如何处理“运行中”的消息和队列？
• 我们是幂等的吗？ 我们可以重播消息吗？
• 我们将VM映像存储在哪里？ 我们有备份吗？

性能

• 可接受的性能水平是多少？ 我们如何衡量呢？ 如果跌破这个水平会怎样？
• 我们可以使系统的任何部分异步以提高性能吗？
• 系统的哪些部分最受竞争激烈，因此更有可能引起性能问题？
• 我们是否可能遇到流量高峰，这可能会导致性能问题？ 我们可以自动缩放还是使用以队列为中心的设计来覆盖这一点？

安全

这本身显然是一个巨大的话题，但是一些与云计算直接相关的有趣话题值得探讨：

• 保存数据的地方法律和管辖范围是什么？ 请记住，也要包括保存故障转移和指标数据的国家/地区。
• 是否有对联合安全性的要求（例如，带有Azure Active Directory的ADFS）？
• 这是一个混合云应用程序吗？ 我们如何确保公司网络与云网络之间的链接？
• 我们如何控制对云提供商的管理门户的访问？
• 我们如何限制其他服务（例如IP地址白名单等）对数据库等的访问？
• 我们如何处理常规的密码更改？
• 服务解耦和多租户如何影响安全性？
• 我们将如何处理操作系统和供应商的安全补丁和更新？

可管理性

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

监控方式

• 我们打算如何监视应用程序？
• 我们将使用现成的监视服务还是编写自己的服务？
• 监视/度量数据将物理存储在哪里？ 这是否符合数据保护政策？
• 我们的监控计划将产生多少数据？
• 我们将如何访问指标数据和日志？ 我们是否有计划使这些数据随着数量的增加而可用？
• 是否有审核和记录的要求？
• 我们是否可以承受丢失一些指标/记录/审核数据的问题（例如，我们可以使用异步设计来“解雇”以帮助提高性能）吗？
• 我们是否需要在运行时更改监视级别？
• 我们需要自动异常报告吗？

部署方式

• 我们如何自动化部署？
• 在不中断实时系统的情况下，我们如何打补丁和/或重新部署？ 我们还能满足SLA的要求吗？
• 我们如何检查部署是否成功？
• 我们如何回滚失败的部署？
• 我们需要多少个环境（例如，开发，测试，过渡，生产），以及如何将其部署到每个环境？
• 每个环境都需要单独的数据存储吗？
• 每个环境都需要24×7可用吗？

可行性

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

• 是否可以满足SLA（即是否有云服务提供商可以提供我们需要向客户提供的正常运行时间保证）？
• 我们内部是否具有设计和构建云应用程序所需的技能和经验？
• 我们是否可以在预算限制和对业务有意义的时间表范围内为我们的设计构建应用程序？
• 我们需要在运营成本上花费多少（云提供商通常具有非常复杂的定价结构）？
• 我们可以明智地减少什么（范围，SLA，弹性）？
• 我们愿意接受哪些权衡？

结论

考虑这四个主题（可用性，可伸缩性，可管理性和可行性）将帮助您发现应用程序中需要一些特定于云的思想的区域，特别是在项目的早期阶段。 每个项目下列出的项目绝对不是穷举性的，但应为您提供一个良好的讨论起点。

翻译自: https://www.javacodegeeks.com/2015/06/cloud-application-design-considerations.html

云计算应用程序