使用外部API和智能内容建议设置移动应用程序的体系结构

Gre*_*gra 5 architecture rdbms amazon-web-services nosql

我和我的一些同事已经开始研究为用户提供社交购买体验的iPhone应用程序.目标是为数以百万计的产品提供扩展的搜索功能(全文,模糊搜索,基于过滤器等),这些产品不断从几个产品列表API(如eBay和亚马逊)获取,然后进行标准化(即转换为字段,类别和关系),应用了一些业务逻辑,以便用户能够根据几个标准获得自定义内容(独特的配置文件,即年龄/性别,搜索历史记录,我的朋友购买的内容等).该应用程序还具有社交功能,如关于产品的帖子,喜欢和评论,跟随其他用户等.

所以现在我们正在尝试设计支持这些需求的服务器架构,其中包括性能考虑因素("给我所有与我的搜索词匹配的产品,并通过相关性对它们进行排序"应该运行得非常快~1到10秒)和可扩展性考虑(10个结果用户将获得与100,000个用户相同的时间结果,假设我可以投入更多的机器来解决这个问题).

我们假设我们将拥有数以万计的产品

我们想到的是(基于AWS):

  1. 设置Elastic Beanstalk以支持可伸缩性,方法是在流量增加时抛出更多EC2实例,并在流量减少时将其删除
  2. 使用MySQL设置RDS作为应用程序的RDBMS(管理用户,配置文件,规范化产品等)以及多个可用区域
  3. 在不同的服务器上设置后台"代理"进程,以便不断从API获取产品数据(具有可自定义的提取Que)
  4. 将上述"原始数据"存储在某些NoSQL中作为临时数据
  5. 设置另一个"代理"以规范数据,对其进行分析并将其插入RDBMS中,以便能够快速搜索已经基于用户不同的配置文件
  6. 设置缓存机制以减少RDBMS上的负载
  7. 建立一个好的全文搜索引擎(即Lucene)

我们主要考虑的是:

  1. Linux环境
  2. 主要是PHP和MySQL
  3. 性能是一个问题
  4. 可扩展性将在不久的将来(6-12个月)成为一个问题(希望:)

现在有几个问题:

  1. 架构是否有意义?
  2. 关于数据存储 - RDBMS是正确的选择还是我们应该考虑使用NoSQL引擎(即MongoDB)?
  3. 在解决这个问题时,我们应该考虑哪些技巧/方法?

顺便说一句,战争故事将非常感激:)

chr*_*ris 1

我认为根据您的描述,您可能希望避免 Elastic Bean Stalk,并直接部署到您控制的 EC2 实例上。

前端将运行网络加载,并且主要从缓存中查询。这可以位于弹性负载均衡器后面,您可以使用自动缩放规则来确保您始终有足够的资源来处理负载。

我可能会使用 solr 进行全文搜索,但我不是这方面的专家 - 我认为 solr 将具有一些可扩展性、复制性等,以使管理您的搜索基础设施更容易管理。有一些很好的 AWS Solr 参考架构旨在扩展。

听起来您将需要几个后端服务层 - 一个用于提取数据,另一个用于规范化数据。如果您打算使用 AWS,您可能可以构建这些,以便中央控制流程将工作分配给您通过现货市场获得的实例 - 这有助于降低总体成本。如果现货市场飙升,您可以选择放慢导入/处理速度,或使用按需实例并稍微增加成本。

我可能会将其设计为使用 mysql 和 no-sql 存储的组合。Mysql 用于核心功能 - 帐户、用户首选项等,而 NoSQL 用于产品信息。您可能希望将其存储为 UI 可以直接使用且只需最少处理的格式。如果设计得当,这应该允许对 NoSQL 存储进行分片,这将有助于可扩展性,尽管您需要一种在节点出现故障时重现数据的方法。

要处理产品和相关数据(评论、帖子等)之间的关系,您需要将它们与用于从 NoSQL 存储中检索它们的任何密钥相关联。如果您要处理数以百万计的产品记录,您可能需要确定您的数据保留要求 - 您是否真的需要保留已过时和/或多年不可用的产品的详细信息?

然而,如果搜索将成为数据的主要接口,您可能不需要 NoSQL 解决方案 - 只需从 solr 中提取您需要的内容即可。

您可以将缓存放在大多数这些层的前面。