问针对双界面在线/移动市场的系统架构建议

EN

如果您将系统分解为更小、更简单和独立的组件，Amazon Web Services将为您提供一些工具，使您的体系结构更简单、更健壮和可伸缩。

因为你有一组不同的sizes of instances，从微型到超大型(以及一些大小的超大型)，你可以灵活地混合每种服务类型到适当的大小，配置，软件依赖，更新周期等。这将使开发人员，测试人员和管理员的生活变得更容易。

您还可以独立地扩展甚至auto-scale每一层和服务。如果您有更多的用户使用其中一个接口，或者增加了通过其中一个接口提供的数据大小，则只能扩展相关的服务。它将为您节省整体扩展整个系统的复杂性和成本。

AWS的另一个特征是能够根据您的需求进行扩展、缩小、扩展和扩展。例如，如果某个接口工作日的用户较多，周末的用户较少，则可以将该接口缩减为周末或晚上，从而节省50%的计算成本。在这方面，您可以从更静态的接口的按需模型切换到reserved instances，再次节省50%的成本。

为了允许不同接口之间的通信，您可以使用DB，但您也可以根据您的用例选择更多的选项。一种选择是使用排队系统作为SQS。队列用作接口之间的缓冲区，降低了一个组件失败的风险(软件错误、硬件故障……)，影响整个系统。接口间通信的另一种选择是使用内存中缓存，这对性能进行了更多的调整。亚马逊网络服务公司正在提供ElasticCache作为这样的服务。它可以比在短时间内和高负载下更新这样的瞬态数据更有效。

除了在一台机器上快速(和肮脏)实现单个服务之外，我看不到任何长期的缺点。

总体目标应该是在移动应用程序和web应用程序之间拥有最多的公共代码。否则，您将面临维护难题，例如修复bug，或者至少在两个地方添加功能。

理想情况下，前端以下的所有内容都应该是通用的。web UI本身应该调用移动应用程序所需的服务器端API。并且大多数逻辑应该放入这些API中，只将表示细节留给UI。这是许多模式(如MVC )所规定的。

我有一个自己运行的移动站点和桌面站点。PHP级别的代码库是完全相同的。只有聪明的模板在两者之间是不同的。尽管移动应用程序不同于移动网站，但基本原则仍然适用。