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