0

我的创业公司正在建立一个在线/移动劳动力市场，其中将有一个业务界面供企业发布工作，我们通过移动界面为用户分配这些工作。我们使用 Rails、REST、Amazon RDS & EC2 和 mysql。

我的问题是：从服务器端架构的角度来看，这样做有意义吗？：

a) 有 2 个应用程序，一个服务于 Web 界面，一个充当移动界面的服务器端 (API)，并且都通过数据库和 2 个不同的 EC2 实例进行通信

b) 尝试构建一个服务于两个接口的综合应用程序

任何关于利弊的意见和观点将不胜感激

谢谢

4

2 回答 2

0

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

理想情况下，前端以下的所有内容都应该是通用的。Web UI 本身应该调用移动应用程序所需的服务器端 API。大部分逻辑都应该放在这些 API 中，只将呈现细节留给 UI。这是 MVC 等许多模式所规定的。

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

于 2013-01-14T04:02:29.980 回答
0

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

由于您有一组不同大小的实例，从微型到特大（以及一些特大），您可以灵活地将每种服务类型混合到适当的大小、配置、软件依赖关系、更新周期等。这将使开发人员、测试人员和管理员的生活更加轻松。

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

AWS 的另一个特点是能够根据您的需要向上、向下、向外和向内扩展。例如，如果其中一个接口在工作日的用户较多，而在周末的用户较少，则可以在周末或晚上缩小该接口，从而为该实例节省 50% 的计算成本。在这方面，您可以从更多静态接口的按需模型切换到保留实例，再次节省 50% 的成本。

为了允许不同接口之间的通信，您可以使用您的数据库，但您还可以根据您的用例提供更多选项。一种选择是将排队系统用作SQS。队列用作接口之间的缓冲区，降低了某个组件发生故障（软件错误、硬件故障...）的风险，从而影响整个系统。接口间通信的另一个选项，更注重性能的是使用内存缓存。AWS 正在提供ElasticCache作为此类服务。它可以比在短时间内和高负载下更新此类瞬态数据更有效。

除了在单台机器上快速（和肮脏）实施单一服务之外，我没有看到任何长期的缺点。

于 2013-01-12T10:22:18.657 回答