我的创业公司正在构建一个在线/移动劳动力市场，其中将有一个业务界面供企业发布工作，我们通过移动界面为用户分发这些工作。我们使用Rails，REST，Amazon RDS＆amp; EC2和mysql。
我的问题是：从服务器端的架构角度来看，它是否有意义？：
a）有2个应用程序用于Web界面，1个用作移动界面的服务器端（API），并通过DB和2个不同的EC2实例进行通信
b）尝试构建一个为两个接口提供服务的综合应用程序
非常感谢任何关于利弊的观点和观点
由于
答案 0 :(得分：0)
如果您将系统分解为更小，更简单和独立的组件，Amazon Web Services将为您提供一些工具，使您的架构更简单，更强大和可扩展。
由于您设置了从微型到超大型（以及一些超大型）的sizes of instances，您可以灵活地将每种服务类型混合到适当的大小，配置，软件依赖性，更新周期它将使开发人员，测试人员和管理员的生活更加轻松。
您还可以独立扩展甚至auto-scale每个图层和服务。如果您拥有其中一个接口或另一个接口的更多用户，或者通过其中一个接口提供的数据大小增加，则只能扩展相关服务。它将为您节省整个系统扩展的复杂性和成本。
AWS的另一个特点是能够根据您的需要进行扩展，缩小，缩小和扩展。例如，如果其中一个界面在工作日有更多用户而周末更少，则可以在周末或晚上缩小此界面，为此实例节省50％的计算成本。在这方面，您可以从更静态的接口的按需模型切换到reserved instances，再次节省50％的成本。
要允许不同接口之间的通信，您可以使用数据库，但根据您的使用情况，您还可以选择更多选项。一种选择是将队列系统用作SQS。队列用作接口之间的缓冲区，降低了一个组件故障的风险（软件错误，硬件故障......），影响整个系统。接口通信的另一个选择是调整性能，即使用内存缓存。 AWS正在提供ElasticCache作为此类服务。它可以比在短时间内和高负载下更新此类瞬态数据更有效。
除了在一台机器上快速（和肮脏）实施单一服务外，我认为没有长期利弊。
答案 1 :(得分：0)
总体目标应该是在移动和Web应用程序之间使用大量代码。否则，您正在考虑最终会遇到的维护问题，例如：修复错误，或至少在两个地方添加功能。
理想情况下，前端下方的所有内容都应该是常见的。 Web UI本身应该调用移动应用程序所需的服务器端API。大多数逻辑应该放在这些API中，只留下UI的演示细节。这是由许多模式如MVC规定的。
我有一个自己运行的移动网站和桌面网站。代码库在PHP级别上完全相同。只有两者之间的智能模板不同。虽然移动应用程序与移动网站不同，但基本原则仍然适用。