我正在使用一个桌面应用程序，该应用程序可以上传到云存储。存储提供商提供了一种上传文件的简便方法。您将获得accessKeyId和secretAccessKey并准备上载。我正在尝试提出用于上传文件的最佳方法。
选项1。将每个应用程序实例打包为访问密钥。这样，无需中间人就可以将文件直接上传到云。不幸的是，在上传到云之前，我无法执行任何逻辑。例如..如果每个用户都有5GB的可用存储空间，我将无法在存储提供者处验证此约束。我还没有找到执行此操作的任何提供程序。在上载之前，我可能会向自己的服务器发送请求以进行验证，但是由于密钥在应用程序中进行了硬编码，因此我确信这是一个简单的利用方法。
选项2。将每个上载的文件发送到可以执行约束逻辑的服务器，并将文件转发到最终的云存储。这种方法遭受服务器瓶颈的困扰。例如，如果100个用户开始上传（或下载）1 GB文件，并且服务器的带宽速度为1000Mb / s，则每个用户仅以10Mb / s的速度上传1.25MB / s。
方法2似乎是可行的方法，因为我可以控制谁可以上传并且密钥不会公开共享。我正在寻找使带宽瓶颈最小化的技巧。建议使用哪种方法来将大文件同时上传到云存储？我正在考虑部署许多低CPU和低内存实例，并使用流传输，而不是先缓冲整个文件然后再发送。
答案 0 :(得分：1)
我认为要求架构验证和改进不在本论坛的讨论范围之内，但我会咬一口。另外，某些方面还不清楚。我假设您的意思是您将文件上传到S3之类的文件，但是您将根据他们支付的费用来限制用户可以上传的数量。
您可以使用选项1。直接上载到存储提供程序，但首先使用服务器进行验证。您需要能够：
这些会增加您的费用。虽然不如选项2那样多。
您的应用将在上传之前对您的服务器进行API调用，以确定上传是否有效。任何不是好答案的答案（或缺少答案）都意味着上传失败。这也意味着您要在体系结构中引入单点故障，并且最好确保只要您仍然有用户，服务器就始终可以正常运行并且可用，否则将违反惠顿定律。我的建议是，在这里无服务器。
您将使用临时的access_key / secret_key对来上传文件。桌面应用程序会将文件直接上传到您要与之打交道的任何提供商，但是它将使用密钥/秘密对，该密钥对/密钥对每12小时更改一次。每个用户都有自己的对，您需要确保一个用户只能访问自己的文件。否则，他们将可以访问每个人的文件，并且您将违反惠顿定律。这样，即使他们以某种方式弄清楚秘密是什么，他们最多也只能访问12个小时，之后您将更改密钥并将其切断。
应用程序与服务器之间的所有通信均使用公钥加密技术进行加密。私钥存储在您的服务器上，用户获得公钥。这样，您可以轻松地根据需要更新加密密钥，因为公共密钥是公共的。请记住，这提供了加密，而不是身份验证。
通过更改用于直接与服务器提供者通信的access_key / secret_key对和用于与服务器通信的私钥，可以轻松使用户的访问无效。
您的服务器应跟踪每个用户的文件，并验证服务器端数据库中的内容与存储中的内容相同。定期做。每天，每周，每2个小时，无论您适合什么。如果发现不一致之处，请进行调查。也许他们正试图作弊。也许您的应用存在错误。这意味着您必须能够在存储级别识别哪个文件属于哪个用户。这就像将用户的所有文件及其UUID存储在目录中一样容易。请勿在此处使用名称或电子邮件。除数据库外，任何个人身份数据都不应存储在其他任何地方。即使在那儿，也只有在需要时才应对其进行加密。
所以，它是这样的：
下载和其他操作应以类似方式进行。
无服务器（AWS上的Lambda，Google功能等）的绝佳用例，应降低成本并提供更多的冗余和“正常运行时间”。
可以改进，有缺陷。例如，在上传之前在客户端对文件进行加密会增加一层安全性。但是这篇文章已经太久了。
你去了。那将是3000美元：）。