SAAS应用程序架构微服务与整体式

Question

我们正在为电子商务卖家构建一个应用程序，以图形化方式显示来自销售，广告活动和其他指标的数据。我可以将应用程序组件分为三个不同的部分：

1. 一个用户创建具有不同个性化仪表板的应用程序 指标的图表。用户可以对数据应用高级过滤器， 可视化图形上的数据过滤数据。

2. 一组后台作业，将从第三项获取数据 不同平台的第三方API。工作必须安排在 每周，每天，每小时取决于作业类型。的 当我们将其构建为SAAS平台时，数据量将会很高。

3. 某些数据无法通过API获得，因此我们必须运行 一些自动化任务（抓取工具）以手动下载它， 用户（可能正在使用硒）。

我们已经在 Ruby on Rails 中部分构建了第一部分。

我们需要一些建议来制定架构决策以开始开发，并提出以下问题：

• 微服务架构还是整体式？

• 我们是否应该使用ActiveJob和一些队列库或一些第三方后台作业处理程序在Rails中构建后台作业系统？后台作业将包括大量的API调用。该架构是多租户的，并且将被多个卖家使用。

• 如果我们选择使用微服务架构，那么微应用之间的通信媒介应该是什么？：

• 跨微应用程序共享数据库？
• 无论何时我们需要处理一项操作（即开始一项工作），我们都应该通过对该服务的http调用来完成它，还是有更好的沟通媒介？

非常感谢您的宝贵时间。

Answer 1

整体与微服务：

更好的选择是绝对微服务。使用微服务，您至少可以获得以下好处：

• 可独立部署的服务
• 为每种服务使用不同的技术
• 使用不同的配置部署每个零件
• 在单独的服务器中托管您的重负载工作器服务
• 快速恢复故障而不会影响其他部分
• 进行云友好的设计
• 快速扩展且价格合理

设计需要洞察力和团队合作精神。作为原始解决方案，我建议：

• 使用将外部请求路由到您的系统并充当API网关的单个服务。 Nginx是一个不错的选择。
• 所有其他服务只能在内部访问。
• 对于服务之间的通信，您可以为每个服务公开REST API或
• 雇用一个消息代理。

我建议使用RabbitMQ（在某些情况下更适合使用Kafka）。每个服务都订阅消息代理中的几个频道。当收到诸如“插入URL”之类的相关事件时，它会为其自身定义一个新任务并开始处理作业（例如，以该URL爬行网站）。之后，它可以向经纪人发送一个新事件，例如“网站已处理”，这样，其他服务将被告知，而每个人都知道以后该怎么做。

• 负责响应用户的服务，当接收到需要做长时间工作的请求时，通过其API通知其他服务或将新事件和相关数据发送给代理，然后响应成功给用户的消息。
• 服务可以在新事件发生后或根据计划启动新任务。

一些提示：

• 使用类似Docker的容器化。这样做时，您可以使用docker swarm或Kubernetes之类的工具。它们给您带来无价的好处：

  • 维护简单
  • 高可用性
  • 快速缩放
  • 按需自动缩放
  • 独立扩展每个微服务
  • 服务发现。无需对服务的位置进行硬编码
  • 断路器，以防止重复请求停止服务并减少等待时间。

• 使用微服务，您可以在编排和编排模式之间进行选择。使用编舞。

• 使用CQRS（命令查询职责隔离）模式为CRUD操作和报告使用不同的数据库

要回答您的问题：

• 微服务架构还是整体式？
  • answer：微服务
• 我们应该在Rails中使用...构建后台作业系统吗？
  • answer：您可以为每种服务使用不同的技术和设计
• 后台作业将包括大量的API调用...？
  • answer：您可以根据需要甚至动态地扩展每个微服务。
• 微型应用程序之间的通信媒介应该是什么？
  • answer：其余API，消息代理或混合
• 跨微应用程序共享数据库？
  • 答案：每个域最好都有自己的数据库。但这是每个域的费用，而不是每个工人的费用。您可以拥有一个由相关工作人员共享的主数据库。但是对于其他域（例如用户），您最好拥有不同的数据库。
• 何时需要处理操作... ？？
  • answer：可以安排某些服务像Cron作业那样工作。流程中可能还有其他作业将由用户请求异步触发。