使用流来分离组件逻辑
当前，即使是最小的应用程序也可能发现自己必须通过API调用或队列来连接多个组件。 在许多需要控制流或异步通信的情况下，可能需要流或队列，并且在使用GCP（Google Cloud Platform）时，您可以利用托管服务Google Pub / Sub作为事件提取和交付系统。
为了显示一个简单的示例，我们可以想象一下要将日志索引到Elasticsearch中的情况。 我们不想让syslog服务器（它将收集日志）也运行相同的逻辑来对日志进行索引（如果Elasticsearch宕机或它对性能的影响，我们将需要处理Syslog服务器中的本地队列）其他）。 为此，我们将使用一组不同的框，这些框将运行Logstash（将日志写入到Elasticsearch），而Google Pub / Sub将允许我们分离那些框和Syslog服务器之间的逻辑。
在这种情况下，我们将考虑以下负载：
- 每秒发送的日志数量：10000
- 每个日志的大小（压缩后）：5kb
这如何影响您的预算？
与任何云部署一样，基于云供应商提供的信息来计算定价成本变得很简单。 在这种情况下，由于没有与网络流量相关的成本，因此我们只需要计算使用Pub / Sub发送消息的成本。
您可以在 此处 找到发布/订阅价格 。 我们将使用从6月开始的新定价模型来简化您可以在 此处 找到的计算 。
在这种情况下，我们每秒将有大约50MiB的数据发送到Pub / Sub，最终是每天4TiB或每月120TiB。 这意味着我们的发布/订阅费用总计每月大约4800美元或每年57600美元 。 该成本将保持线性增长，因此，如果我们发送的数据量是10倍，我们预计成本将增加10倍。
GCP中的微批处理
虽然前面的示例对于大中型公司可能是可以接受的，但是随着数据量的增长（每秒日志的大小或数量），成本也会随之增加。 现在，如果我们开始每秒发送10万条日志，我们预计成本还将增长到每年50万美元。 一种显着降低成本的方法是，通过利用Google Cloud Storage（GCS）中缺少区域网络传输成本的优势，将架构从通过Pub / Sub直接流式传输日志转换为使用微型批次。
微批处理通过不再处理单个日志而是小批量处理改变了我们的工作方式。 此示例中的Syslog服务器将创建1000个日志的文件并将它们写入GCS（每个文件约5mb），同时将GCS文件名写入Pub / Sub。 Logstash服务器现在将从“发布/订阅”新对象中读取，并从GCS请求对其进行处理。 增加的延迟可能会有所不同，具体取决于其实现方式和基础应用程序（根据我的经验，延迟会增加2到5秒）。
在这里，您可以找到运行python脚本的示例容器的代码，该脚本从Pub / Sub读取新的文件名条目，从GCS请求文件内容，然后通过本地TCP套接字将其发送到Logstash。
通过微批量降低成本
在微批量架构中，我们需要考虑以下成本：
发布/订阅
在这种架构中，Pub / Sub仅用于发送和接收GCS文件名（带有随机前缀以避免热点），因此我们可以估计10个文件名，最高每秒100个字节，这大约为每月2.5GiB， 每月花费10美分 。
谷歌云存储
在这种情况下，我们会将批次存储在GCS区域存储中，并最多保留一天。 为此，我们需要考虑创建文件的写操作，检索文件的读操作以及一天存储文件的成本。
将操作写入GCS
这将是A类操作，每万次操作需要支付0.05美元。
写入操作：每秒10次/每月25920000。
每月写入操作的费用： ±130美元
向GCS读取操作
这将是B类操作，每万次操作费用为0.004美元。
读取操作：每秒10个/每月25920000。
每月读取操作的成本： ±11美元
存储
定价：每月每GB 0.020美元，一天应该为0.0006美分
存储量：120TiB
每月存储成本： ±74美元
在这种情况下，微批量策略的费用约为每月215美元或每年2580美元 。 这意味着通过增加少于5秒的额外延迟，与之前描述的流传输模型相比，每月成本降低了95％以上。 如果使用此模型获得的延迟可以进一步增加，则可以通过增加批处理大小来减少使用Pub / Sub的成本（减少对Google Cloud Storage的读写操作），这也可以改善对日志并降低存储成本）。 如果您愿意随时保留少于一天的可用数据，也可以降低成本（降低GCS存储成本）。
扩展解决方案时，我们只需要考虑到，如果我们每秒处理1000个以上的写请求（大约是本文示例的100倍），则需要研究Google扩展此处的GCS的最佳实践。 同样从Logstash或Syslog的角度来看，将进行一些额外的处理，但不足以使预算有明显的增加。
尽管本文着重介绍Google Cloud的发布/订阅，但可以通过在Kafka群集上减少负载并在HDFS中存储文件（以例如，对延迟的影响要大于其他延迟）。
结论
在设计解决方案时，我们应该始终追求简单性并尽可能获得最佳性能，但是复杂性和性能影响之间的权衡应与其相关的成本影响相平衡。 如果碰巧有一个需要传输大量数据并可以接受几秒钟的延迟的解决方案，那么微批处理可以大大减少您的预算。
让我知道您是否在做类似的事情以及您的经验，或者对此方法有任何评论！
