Bluecore 利用 Istio 迁移到 Kubernetes

Bluecore 是一款多渠道个性化平台，专门提供大规模高度个性化的电子邮件、网站消息和付费媒体广告。由于 Bluecore 的独特功能需要处理客户推荐数据以及发送大量个性化数字通信，因此他们需要处理大量数据的摄取、处理和发送。这是一个巨大的工作量；在最近的黑色星期五，他们发送了超过 20 亿封电子邮件。

除了容量之外，Bluecore 还需要速度。他们与大多数合作伙伴签署了服务协议，保证任何客户都会在提交作业后的几小时内收到电子邮件、网站消息或广告，这意味着处理速度至关重要。他们通过在 Google App Engine 上运行的单体应用程序和运行大约 12,000 个 Pod 的 Google Kubernetes Engine (GKE) 集群来实现这一壮举。

挑战：单体架构和不断增长的数据流量

Bluecore 是一家大型运营商，对数据传输和处理有严格的要求。他们面临着艰巨的挑战；他们需要处理的数据量不断增加。他们知道，如果他们的架构无法更新以处理不断增长的需求，他们的管道将会过载。

对他们架构的检查表明，单体应用程序将是最大的挑战。Bluecore 开发团队意识到，为了实现未来的增长，是时候开始迁移到更灵活、更可扩展的基础设施了。

Kubernetes 提供了一条扩展路径，而且由于 Bluecore 已经在 App Engine 上运行，因此将部分工作流迁移到 GKE 看起来是轻而易举的事。然而，Bluecore 的大多数工程师都没有足够的容器化应用程序经验。这可能会使迁移到 GKE 变得痛苦。

幸运的是，他们找到了解决方案。

解决方案：使用 Istio 服务网格赋能开发人员

“Istio 使得您能够开箱即用地开始构建，”Bluecore 基础设施团队的软件工程师 Shray Kumar 解释道。“并且您可以确保以正确的方式构建事物。”

如果没有服务网格，将单体应用程序分解为容器化服务会带来一些没有明显解决方案的挑战。例如，其中之一是实现身份验证和授权。如果每个容器化服务都需要自己的解决方案，那么各个开发人员想出自己的方法的可能性太大。这会导致代码碎片化，并带来许多未来的头痛问题。

值得庆幸的是，Kumar 和基础设施团队熟悉 Istio。他们与 Bluecore 数据平台团队的首席工程师 Al Delucca 密切合作，制定了一个开始实施 Istio 的计划。

“我们遇到了问题，”Delucca 解释道。“但是 Istio 是否是解决它的工具，这是我们必须弄清楚的。”

他们发现，Istio 的功能集为现有的挑战提供了许多解决方案。授权是一个大问题。来自合作伙伴应用程序的传入消息需要进行身份验证。Istio 可以在边缘执行该身份验证，这意味着每个单独的服务都不需要实现自己的方法。

“我们能够将身份验证和授权推送到边缘，这减轻了我们工程师理解这些系统的负担，”Delucca 说。“与其说他们直接使用 Istio，不如说是 Istio 在他们不知情的情况下为他们做了什么。这就是关键 - 对我们来说是巨大的胜利。”

当他们的工程师开始将单体应用程序分解为服务时，他们遇到了另一个 Istio 可以解决的挑战。跟踪对服务的调用似乎会很麻烦。许多旧版功能没有关于其依赖项和要求的清晰文档。这意味着性能问题和远程服务调用可能会让开发人员不知所措。幸运的是，Istio 的分布式跟踪 出现了。借助它，开发人员能够查明瓶颈和需要修复错误和额外工作的服务。

Istio 的服务网格使开发人员能够专注于将单体应用程序分解为单独的服务，而无需深入了解整个基础设施。这使 Bluecore 的工程师能够更快地提高生产力。

结论：未来

虽然 Bluecore 团队已经在他们使用的 Istio 功能中找到了难以置信的价值，但他们仍在寻求利用更多功能。这些功能包括管理自动扩展的 金丝雀部署 的能力。金丝雀部署允许团队通过仅使用应用程序流量的一小部分来测试新版本的服务来引入该服务。如果测试顺利，则可以在逐步淘汰旧版本的同时自动部署升级。另一方面，如果在新版本中检测到问题，则可以快速回滚到旧版本。

Bluecore 团队将继续将他们的单体应用程序分解为容器化服务，使用 Istio 将越来越多的服务推送到边缘，让他们的开发人员有更多时间做他们最擅长的事情。他们相信，他们已经准备好迎接下一阶段的增长，因为他们需要摄取和处理越来越多的数据。