从一开始，Bluecore就运行在Google Cloud Platform(GCP)上。到了构建高性能服务的时候，我们自然而然地希望利用GCP基础设施，而不是自己构建它。通过使用Kubernetes(GKE)、Redis(MemoryStore)、BigTable和其他GCP技术，我们能够构建具有足够带宽和延迟的服务，每秒发送10000个个性化推荐。
你很可能收到了一封电子邮件，引诱你购买你放在网上购物车里的一种产品，而且它可能还附带了一些其他推荐的产品。我们是怎么想出这些产品来推荐消费者的呢？在Bluecore，我们通过两种方式创建产品推荐：通过产品推荐或通过消费者行为推荐。例如，可以根据最近查看或以前购买的产品来推荐产品。Bluecore已经开发出强大的数据模型来计算.。
将产品映射到用户并不是一个看起来那么简单的过程。我们评估有关可以在运行时将哪些产品插入电子邮件的规则。例如，不包括缺货或打折的产品。因为我们只展示有效的产品是很重要的，我们必须有一个最新的产品目录。对于任何一家给定的零售店，产品都是不断变化的。因此，使我们的产品保持最新需要其自身的服务。
虽然电子邮件是我们的主要产品，但Bluecore也在零售商的网站上提供实时产品推荐，这带来了比电子邮件更严格的延迟限制。现场推荐迫使我们重新考虑我们的推荐基础设施。推荐服务的构建考虑到了Bluecore的工程价值之一，即构建“尽可能简单，尽可能强大”的东西。在推荐服务的整个发展过程中，我们已经……。
制作一封电子邮件有三个组成部分：模板(电子邮件的设计大纲)、受众(将接收电子邮件的电子邮件地址列表)和推荐(我们掌握的每个收件人的数据科学模型派生的值)。模板在云数据存储中，我们的受众在BigQuery中生成，我们的推荐在数据存储中。电子邮件是在Google App Engine Standard(GAE)中生成的，我们按每封电子邮件查询云数据存储(有时.。
好吧，不。正如我们之前提到的，我们现在支持当消费者在网站上时显示的推荐。这意味着延迟现在确实很重要。从仅限电子邮件到同时提供现场和电子邮件服务的转变迫使我们重新评估我们的架构。现场建议要求我们有更严格的SLO(300-400毫秒)。在网站开始感觉缓慢之前，这就是你得到的全部信息。在考虑到其他服务、网络和传输到.的情况下，建议获取只是加载时间的一部分。
受众(电子邮件地址列表)生成和个性化(将地址与他们的推荐进行映射)是分开的，这意味着模板仅限于附加到受众查询行的数据。如果推荐类型在单个模板内进行个性化，则受众查询将无法管理。
在新版本的推荐服务中，我们想要做五件基本的事情：
考虑到我们的新目标，本着“尽可能简单，尽可能强大”的精神，让我们构建一个天真的服务实现。我们知道我们需要GRPC服务，我们的推荐数据来自BigQuery/Datastore，而我们的产品数据驻留在Datastore中。我们的推荐服务(用GO编写)支持运行时个性化，因为现在我们将产品和推荐数据提供给服务，并将推荐的产品提供给个性化……。
数据存储非常昂贵，而且BigQuery无法满足我们的延迟要求。所以再说一次，不是。即使我们将所有建议导出到数据存储区，我们仍然无法达到延迟目标。不过没关系，我们不能责怪锤子是个坏螺丝刀，我们只是需要合适的工具！
让我们把重点放在如何改进图表的“RECS”部分。建议被写入BigQuery或Google Cloud Storage(GCS)，然后一些被加载到数据存储中。相反，我们可以将来自BigQuery和GCS的所有推荐加载到BigTable中。BigQuery Storage API的发布使得从BigQuery中提取海量数据变得更快。我们固定的推荐模式使范围保持在可管理的范围内。
在考虑提高性能时，很多时候答案是实现缓存。在我们的情况下，这不是一个好的解决方案，因为接收者的推荐数据在其无效之前很可能只被读取一次。缓存未命中意味着我们将从源读取，从而导致延迟、金钱或两者都要付出代价，就像我们在前面的系统图中所说的那样。然而，Bigtable在受到重创时表现良好。E