共计 3510 个字符，预计需要花费 9 分钟才能阅读完成。
VSCO：移动应用如何通过云原生节省 70%的 EC2 账单
公司：VSCO 地点：加州奥克兰行业：照片移动应用程序
挑战
在 2015 年从 Rackspace 迁移到 AWS 之后，除了运行 PHP 单体应用外，VSCO 开始构建 Node.js 和 Go 微服务。该团队使用 Docker 将微服务容器化，但“它们都是在每个服务专用的 EC2 实例的独立组中。”机器学习团队工程经理 Melinda Lu 说。社区团队高级软件工程师 Naveen Gattu 补充：“这产生了大量浪费的资源。我们开始寻找一种在 AWS EC2 实例中整合，并提高效率的方法。”
解决方法
团队开始探索编排系统，并在决定采用 Kubernetes 之前查看了包括 Mesos 和 Swarm 在内的几种解决方案。VSCO 也在他们的云原生堆栈中使用 gRPC 和 Envoy。
影响
在之前，部署需要“大量的手动调整，我们编写的内部脚本，以及由于我们不同的 EC2 实例，操作必须从始至终照顾整个事情。”高级软件工程师 Brendan Ryan 说。“我们并没有真正有条理进行测试的故事，可重复使用的容器或以标准化的方式构建。”现在有更快的上线流程。之前，首次部署的时间是两天的动手设置，现在是两个小时。通过持续集成、容器化和 Kubernetes，速度显着提高。典型服务从代码完成到生产部署到基础设施的时间从一到两周减少到两到四个小时。Gattu 补充：“在工时来说，这是一个人比较起在同时需要开发者和 DevOps。”在生产中单个部署的时间减少了 80%，部署的数量也增加了，从每年 1200 到每年 3200。实际上也节省了成本：凭借 Kubernetes，VSCO 的 EC2 效率提高了 2 倍至 20 倍，具体取决于服务，使公司的 EC2 账单总体节省约 70%。Ryan 指出，该公司能够从管理一个大型单体应用程序到 50 多个微服务，使用“或多或少同等规模的开发团队。我们之所以能够做到这一点，是因为我们对工具的信任度更高和灵活性更高，因此我们不需要聘请 DevOps 工程师来调整每项服务。”随着 Kubernetes、gRPC 和 Envoy 到位，VSCO 的中断时间减少了 88%，这主要是由于消除了 JSON 模式错误和特定于服务的基础设施配置错误，以及加快修复停机的速度。
“看到我们的工程师通过结合大量的 Kubernetes 基元来提出创造性的解决方案，让我一直留下了非常深刻的印象。将 Kubernetes 构造作为服务暴露给我们的工程师，而不是暴露高阶构造对我们来说效果很好。它可以让你熟悉这项技术，并用它做更多有趣的事情。”– Melinda Lu，VSCO 机器学习团队工程经理
作为移动摄影应用程序，VSCO 于 2011 年诞生于云端。最初，“我们使用 Rackspace 并使用 PHP 单体应用程序与 MySQL 数据库通信，使用 FTP 部署，没有容器化，没有编排。”软件工程师 Brendan Ryan 说，“当时足够了。”
在 VSCO 于 2015 年迁至 AWS 并且其用户群超过 3000 万大关之后，该团队很快意识到现有设置将不够用。开发者开始构建一些 Node 和 Go 微服务，团队尝试用 Docker 进行容器化。但是“它们都是在每个服务专用的 EC2 实例的不同组中。”机器学习团队工程经理 Melinda Lu 说。社区团队高级软件工程师 Naveen Gattu 补充说：“这产生了大量浪费的资源。我们开始寻找一种在 EC2 实例中整合并提高效率的方法。”
通过一个包括易用性和实现、支持级别以及是否是开源的清单，团队在决定使用 Kubernetes 之前评估了一些调度解决方案，包括 Mesos 和 Swarm。“Kubernetes 似乎拥有最强大的开源社区。”Lu 说。此外，“我们已经开始标准化大量的 Google 堆栈，Go 作为编写语言，gRPC 用于我们在数据中心内部服务之间的几乎所有通信。所以我们似乎很自然地选择了 Kubernetes。”
“Kubernetes 似乎拥有最强大的开源社区，而且，我们已经开始标准化很多 Google 堆栈，Go 作为编写语言，gRPC 用于我们在数据中心内部服务之间的几乎所有通信。所以我们似乎很自然地选择了 Kubernetes。”– Melinda Lu，VSCO 机器学习团队工程经理
当时，生态系统中很少有托管的 Kubernetes 产品和较少的工具，因此团队建立了自己的集群，并为其特定的部署需求构建了一些自定义组件，例如自动入口控制器和灰度部署的政策构造。“我们已经开始拆除单体了，所以我们一个接一个地搬东西，从相当小的低风险服务开始。”Lu 说。“每一项新服务都部署在那里。”第一项服务于 2016 年底迁移，一年后，整个堆栈的 80%在 Kubernetes 上跑，包括其余的单体。
带来的影响很大。在过去，部署需要“大量的手动调整，我们编写的内部脚本，以及由于我们不同的 EC2 实例，操作必须从始至终照顾整个事情。”Ryan 说。“我们并没有真正有条理进行测试的故事，可重复使用的容器或以标准化的方式构建。”现在有更快的上线流程。之前，首次部署的时间是两天的动手设置时间，现在是两个小时。
通过持续集成、容器化和 Kubernetes，速度显着提高。典型服务从代码完成到生产部署到基础设施的时间从一到两周减少到两到四个小时。另外，Gattu 说，“在工时来说，这是一个人比较起在同时需要开发者和 DevOps。”在生产中单个部署的时间减少了 80%，部署的数量也增加了，从每年 1200 到每年 3200。
“看到我们的工程师通过结合大量的 Kubernetes 基元来提出创造性的解决方案，让我一直留下了非常深刻的印象。将 Kubernetes 构造作为服务暴露给我们的工程师，而不是暴露高阶构造对我们来说效果很好。它可以让你熟悉这项技术，并用它做更多有趣的事情。”– Melinda Lu，VSCO 机器学习团队工程经理
实际上也节省了成本：凭借 Kubernetes，VSCO 的 EC2 效率提高了 2 倍至 20 倍，具体取决于服务，使公司的 EC2 账单总体节省约 70%。
Ryan 指出，该公司能够从管理一个大型单体应用程序到 50 多个微服务，使用“或多或少同等规模的开发团队。我们之所以能够做到这一点，是因为我们能够增加对工具的信任，并且当系统存在压力点时更加灵活。你可以增加服务的 CPU 内存需求，而无需启动和拆除实例，阅读 AWS 页面只是为了熟悉许多行话，这对于我们规模的公司而言并不适合。”
Envoy 和 gRPC 也对 VSCO 产生了积极影响。“我们从开箱即用的 gRPC 中获得了许多好处：跨多种语言输入安全性、使用 gRPC IDL 轻松定义服务、内置架构如拦截器，以及通过 HTTP/1.1 和 JSON 的性能改进。”Lu 说。
VSCO 是 Envoy 的首批用户之一，在它开源五天后将其投入生产。“我们希望通过我们的边缘负载平衡器直接向移动客户端提供 gRPC 和 HTTP/2，而 Envoy 是我们唯一合理的解决方案。”Lu 说。“在所有服务中默认发送一致且详细的统计数据的能力，使得仪表板的可观察性和标准化变得更加容易。”Envoy 内置的指标也“极大地帮助了调试”，DevOps 工程师 Ryan Nguyen 说。
“因为现在有一个支持 Kubernetes 的组织，这会增强信心吗？答案是响亮的。”– Naveen Gattu，VSCO 社区团队高级软件工程师
随着 Kubernetes、gRPC 和 Envoy 的到位，VSCO 的中断时间减少了 88%，这主要是由于消除了 JSON 模式错误和特定于服务的基础架构配置错误，以及加快修复停机的速度。
鉴于其使用 CNCF 项目的成功，VSCO 开始尝试其，包括 CNI 和 Prometheus。“拥有一个大型组织支持这些技术，我们更有信心尝试这个软件并部署到生产中。”Nguyen 说。
该团队为 gRPC 和 Envoy 做出了贡献，并希望在 CNCF 社区中更加活跃。“看到我们的工程师通过结合大量的 Kubernetes 基元来提出创造性的解决方案，让我一直留下了非常深刻的印象。”Lu 说。“将 Kubernetes 构造作为服务暴露给我们的工程师，而不是暴露高阶构造对我们来说效果很好。它可以让你熟悉这项技术，并用它做更多有趣的事情。”
KubeCon + CloudNativeCon 和 Open Source Summit 大会日期：
会议日程通告日期：2019 年 4 月 10 日
会议活动举办日期：2019 年 6 月 24 至 26 日
KubeCon + CloudNativeCon 和 Open Source Summit 赞助方案 KubeCon + CloudNativeCon 和 Open Source Summit 多元化奖学金现正接受申请 KubeCon + CloudNativeCon 和 Open Source Summit 即将首次合体落地中国
