AWS 上的节点 API 架构答案

【问题标题】：Node API Architecture on AWSAWS 上的节点 API 架构
【发布时间】：2014-03-24 15:56:20
【问题描述】：

我正在制作一个应用程序，它将具有：

iOS 和 Android 应用程序
基于网络的“仪表板”，用于显示从移动应用收集的数据

该应用要求最终用户在我们这里创建一个帐户（我们很可能不会使用 Facebook/Twitter 登录）。

一切都将使用 EC2/RDS/S3 托管在 AWS 上（全部封装在 Elastic Beanstalk 中）

| Web Browser |  <----> | sails.js app | <-------> |actionhero.js API|

                                                        ⬆︎  
                                                        ⬆︎
| Mobile app(s) | <-------------------------------------/

到目前为止，我已经在 actionhero.js 中构建了大部分支持 API，托管在 AWS 上。

对我来说，将 API 和网络应用分开是有意义的，因为网络应用仅适用于一小部分用户——我希望我们的移动应用的流量是网络应用的 50 倍。我们可以扩展 API 以服务于移动用户，而无需扩展sails.js 应用程序。

我的问题是：

(biuggest unknown) 我应该如何处理身份验证？sails.js 应用程序需要能够向 API 发出请求，移动应用程序也是如此。

我正在查看 oauth2orize 节点模块来创建我们自己的身份验证服务器，但它是为 Connect/Express 设计的，所以我认为我不能在基于 actionhero.js 的 API 中利用它。

如果解决方案是创建一个 OAuth 服务器，我应该将它托管在它自己的 EC2 实例上吗？
（AWS 特定问题）我不完全理解创建 AWS 所描述的“工作层”环境的用例。 API 是否属于该类别？
如果我想运行数据查询和聚合任务，我会为此创建一个单独的节点进程，对吗？如果是这样，该后台工作人员是否必须存在于其自己的 EC2 实例上？
Sails.js 和 Actionhero.js 都为 socket.io 提供了强大的支持。 Sails 应用程序和我的 API 之间的通信是否应该通过持久的 WebSocket 连接进行？如果我将来需要创建新实例，这种规模会扩大吗？

这似乎是一个相当典型的模式；我想知道这个设计中是否有任何大的危险信号，在我把自己画到一个角落里。 :-) 谢谢！

额外问题（特定于 AWS Elastic Beanstalk）

我会为sails.js 服务器和API 服务器创建单独的“应用程序”吗？无论如何，这似乎是设置它的唯一方法，但我想确定一下。

【问题讨论】：

标签： node.js amazon-ec2 oauth-2.0 sails.js amazon-elastic-beanstalk

【解决方案1】：

我们现在已经在几个应用程序中使用了 node 和 beanstalk。对于身份验证，您可以在用户首次访问应用程序时为其创建一个帐户，并将该帐户 ID 存储在设备上。如果您希望他们能够从多个设备登录，您需要提供某种方式让他们识别自己，这可以是 id/密码，或者使用 Facebook。设置它并不难。使用 session 让他们登录并保持登录状态。我们一般只是将用户 ID 存储在 session 中。

工作层适用于您想要与您的应用分离的事情，您想要做的事情您不需要知道它是否成功/失败。通知服务器就是一个很好的例子。您将通知的信息发送到 SQS 队列，然后将其发送到工作层，该层完成工作。我们现在只是想弄清楚这一点。

一个大的聚合过程，是的，我会把它带到其他地方，所以它不会占用你的生产服务器。您可能希望创建一些正在进行的数据聚合，因为事务被保存，所以它会累积。事后大汇总可能既耗时又脆弱。

听起来是的，它们将是单独的应用程序。

一个很好的提示。我们使用 grunt 为应用程序创建 zip 文件。它是一个节点批处理工具。我们从 SVN 中检查最新信息，通过删除 .svn 目录之类的操作来清理它，通过简单的字符串替换将我们的配置应用到配置文件中，然后压缩生成的输出。然后将其加载到beantalk中。这消除了实际进行新部署的所有猜测工作和时间。这样，我们可以在几分钟内完成新的构建。

Beanstalk 可能非常令人沮丧。当它失败时，它不太善于告诉你原因。

【讨论】：