Google cloud platform 用于从SFTP服务器无服务器日志摄取（文件下载）的Google云平台解决方案

今天有一个问题，在我键入答案时被删除了（不知道为什么）。由于答案很长，我决定复制/重新创建它并提供我的答案。也许它会对某些人有用

---

原来的问题是：

我们有一个SFTP服务器，Apache、Nginx和Wordpress日志都被转储在这个服务器上。我们希望将这些日志备份到云存储中，同时解析这些日志的内容并插入到BigQuery表中。我通常使用云函数（NodeJS或Python），这是我首先想到的解决方案

但是，云功能有一个触发器，如果我的目标是让程序持续监视/观察/侦听SFTP文件夹中的新文件，那么这个触发器就没有意义。如果我的要求不那么严格，我可以按计划触发它，比如每小时读取SFTP文件夹中的新文件。当新文件转储到云存储中时，云函数也可以在该部分工作，触发该函数对日志文件进行解析并插入到BigQuery

如果我坚持不断收听SFTP文件夹的要求，您能否建议一个更好的设计解决方案，以及为了实现这一点，我需要将GCP服务（除了云存储和BigQuery）组合在一起

如果要求不那么严格，我的解决方案是否足够好？ 另外，我刚刚发现SFTP凭据具有只读权限。因此，通过添加后缀来重命名文件是毫无疑问的。我是否应该使用类似MemoryStore的缓存来记住哪些文件已完成？

Longread

在我看来，这是一个很大的问题。解决方案不仅需要代码开发，还需要大量的设计思维和决策（包括一些折衷）

根据我的个人经验（我开发了两次这样的解决方案，并在生产中维护了它，等等），可以将云功能与一组GCP资源一起使用—secret manager、pubsub主题、firestore集合、服务帐户和它们的IAM等等。。。根据您的需求（我不知道细节）和上下文，您可能需要创建一个功能组件，该组件由几个不同的云功能组成（比如说两个到五个）。第二，如果您的文件很小（每个文件最多100万个），则每天的文件数量不大（几千或上万个文件），并且您有权在下载时从SFTP服务器删除原始文件

如果您没有这样的权限，那么应该有其他的流程来清理“旧”或“已下载”的文件。否则，最终解决方案将无法工作（当下载一个文件列表，而不是文件，而是一个文件列表需要540秒以上）

SFTP是一个“被动”组件-如果新文件到达，它不会通知我们，因此我们这边应该有一些“主动”组件来发起到SFTP服务器的连接。这是一种“拉动式”交互，并且有规律性——即每10、15或20分钟——连接到SFTP服务器并检查是否有新的内容可下载

下一个。云函数是幂等函数，不可能仅在云函数中存储/保持文件下载的状态。应该有一些外部（相对于云功能）服务来维护每个文件下载过程的状态机。我用过消防车。它非常方便，并且具有非常小的延迟。firestore集合中的每个文档都反映了“文件下载过程”——一个状态机以及大量元数据、状态转换历史等等

云功能有两个重要限制：

540秒超时

2Gb内存

这意味着下载过程（以及任何其他活动）不应超过540秒。如果要在内存（云函数）中存储任何数据，该数据块应小于2Gb

超时限制会影响进程吗？-是的，它可以。整个过程的瓶颈是SFTP服务器和GCP存在点之间的“带宽”。文件越大-下载它所需的时间越长，尤其是在并行下载许多文件时

因此，很快，算法的工作方式如下：

1/第一个云函数每15分钟触发一次（云调度程序=>PubSub主题=>cloud函数）。云函数读取所有SFTP连接和所有数据管道的配置（即GCS bucket中的json文件）（因为此组件可能与许多SFTP服务器一起工作，并且每个SFTP服务器可能有许多数据管道），然后从Secret Manager（每个SFTP服务器）获取凭据，然后连接到SFTP服务器，并下载每个连接/管道的可用文件列表。因此，对于我们知道的每个文件—连接（SFTP服务器）、管道（即源目录）、文件名、文件大小、文件修改时间戳。我不希望从SFTP服务器得到更多的东西。对于每个连接和数据管道，我们都会组成一个文件列表（取决于配置，而且应该是灵活的），最多有5个、8个或10000个文件。该列表作为json结构作为消息推送到PubSub主题中（如果需要，还包含一些额外的元数据）。因此，如果我们有2个SFTP服务器，每个服务器中有3个管道，那么至少会有6条消息。如果SFTP服务器中的目录包含的文件超过5K、8K或10K，则可能会更多。此时，我们不知道这些文件是否已下载，或者下载过程正在进行，或者下载失败，或者这是一个新文件。 部署此函数时，“max instances”参数的值为1

2/第二个云函数是trigg