Design patterns 在以云为中心的设计中，您遇到了哪些架构问题？

当您决定部署云设置时，您面临哪些体系结构/实现问题，以及如何解决这些问题

一些例子包括：

• （架构）当您计划将现有应用程序移入云中时的设计模式
• 应优先考虑哪些非功能性需求
• 如何克服头顶上的云层？（由于虚拟化，如资源计量等）

---

我面临的最大问题是当地的退路。在一个典型的云场景中，您正在将曾经存在于传统数据存储（数据库、文件系统等）中的资源移动到API后面的某个地方，您无法在本地轻松复制这些资源。对于我们的应用程序，我们将几个典型的队列从MySQL移动到了。问题：

目前，Amazon每10000 SQS请求收费0.01美元，这一成本似乎非常小，但在本地开发时（或者为您的测试服务器，假设您有一个单独的测试服务器），绝对没有理由付费

如果您没有本地队列回退，那么每个开发/测试环境都需要一个单独的队列。您真的不希望来自不同队列的消息被混淆

没有一种简单的方法可以在本地为我们的环境模拟SQS（据我所知）

在架构上，我用简单的方法处理了向SQS的过渡：

• 一个完成大部分工作的抽象适配器，具有用于存储特定内容的抽象函数
• 继承抽象适配器并使用SQS SDK的SQS适配器
• 一个MySQL适配器，或多或少和我们以前的一样
• 创建队列模型、决定使用哪种适配器并将其提供给模型的

当我们将映像移动到时，相同的体系结构（或多或少）工作得非常好，并且有一个文件系统本地回退。简单、小巧、易于解释，更重要的是，它可以工作。如果您要将应用程序迁移到云端，那么很可能您要为后端服务编写很多适配器，除了使用简单的回退机制之外，您不希望被供应商锁定到特定的服务

显然，如果您在构建应用程序时考虑到了云，那么您可能不一定需要本地回退，特别是如果您的平台具有模拟云环境的简单方法。比如，如果您是在.Net/Mono上开发的，或者您的目标是亚马逊的服务。但是如果你有一个成熟的应用程序，你已经在本地建立了一个基础设施，继续使用它会更有意义

如果您将云用作一个奇特的数据存储，那么云“开销”并不是您真正需要担心的事情。但是，如果你正在寻找云计算，那么就没有答案了，它总是取决于你到底在做什么

一些相关问题：