【发布时间】：2011-03-26 06:11:12
【问题描述】：
当您决定部署云设置时，您遇到了哪些架构/实施问题以及您是如何解决这些问题的？
一些例子包括：
- （架构）设计模式，当您计划将现有应用程序迁移到云端时
- 应该优先考虑哪些非功能性需求？
- 如何克服云开销？ （因为虚拟化 - 例如资源计量等）
【问题讨论】：
标签： design-patterns architecture cloud implementation
【发布时间】：2011-03-26 06:11:12
【问题描述】：
我面临的最大问题是本地后备。在典型的云场景中，您正在将曾经存在于传统数据存储（数据库、文件系统等）中的资源移动到 API 背后的某个地方，您无法轻松地在本地复制这些资源。对于我们的应用程序，我们将一些典型的队列从 MySQL 移至 Amazon's SQS。问题：
目前亚马逊对每 10,000 个 SQS 请求收取 0.01 美元的费用，这个成本可能看起来非常小，但在本地开发（或者为您的测试服务器，假设您有一个单独的服务器）时，绝对没有理由付费。
如果您没有本地队列回退，则每个开发/测试环境都需要一个单独的队列。您真的不希望来自不同队列的消息混淆。
对于我们的环境（据我所知），没有一种简单的方法可以在本地模拟 SQS。
在架构上，我用简单的adapters 处理了向 SQS 的过渡：
- 完成大部分工作的抽象适配器，具有用于存储特定内容的抽象函数，
- 继承抽象适配器并利用 SQS SDK 的 SQS 适配器，
- 一个 MySQL 适配器，或多或少与我们之前的完全一样，
- factory method 创建了队列模型，决定使用什么适配器，并将其提供给模型。
当我们将图像移动到S3 时，相同的架构（或多或少）运行良好，并带有文件系统本地回退。简单、小巧且易于解释，更重要的是，它有效。如果您正在将应用程序迁移到云中，您可能会为您的后端服务编写相当多的适配器，除了具有简单的回退机制之外，您不希望供应商锁定到特定服务。
显然，如果您正在构建一个考虑到云的应用程序，则可能不一定需要本地回退，尤其是如果您的平台具有模拟云环境的简单方法。类似Stratosphere，如果您在.Net / Mono 上进行开发，或者您的目标是亚马逊的服务。但是如果你有一个成熟的应用程序，你已经在本地建立了一个基础设施，继续使用它更有意义。
如果您将云用作精美的数据存储，则无需担心云“开销”。但是，如果您正在寻找云计算，那么就没有答案，它总是取决于您到底在做什么。
几个相关问题：
【讨论】：