智能扩展：成功使用云原生技术扩展基础架构的4个关键技巧

做者：Reda Benzair

今天的帖子来自CNCF大使兼Streamroot工程副总裁Reda Benzair。文章最初在Streamroot技术开发者的博客上发布。

在这篇文章中，我想与工程经理和后端团队分享一些高级别的要点，以帮助他们成功扩展业务，同时避免一些最多见的陷阱和短视决策。

本文伴随Streamroot首席后端工程师Jordan Pittier发布的第一篇文章，以及咱们去年11月在HighLoad Moscow的历程演讲。这些分享了咱们在从基于VM的架构迁移到基于容器的架构，以及将咱们的基础架构迁移到运行在Google Cloud上的Kubernetes的整个过程当中所面临的经验和挑战。

介绍和背景

首先，我将向你介绍Streamroot的一些背景知识，以及为何咱们花时间调整咱们的Kubernetes Engine架构，不只要扩展规模，还要使咱们的架构更具容错性。

Streamroot是一家为主要内容全部者提供服务的技术供应商 - 媒体集团、电视网络和视频平台。咱们的点对点视频传输解决方案为广播者提供了更高的质量和更低的成本，并与现有的CDN基础设施协同工做。

去年咱们（以及咱们客户）面临的最大挑战之一是扩大到FIFA世界杯的破纪录的观众。事实证实，2018年世界杯是有史以来规模最大的直播赛事，Akamai在峰值时的记录的速度为22 Tbps，超过了以前超级碗记录的两倍。Akamai测量的峰值量超过22 Tbps。这是他们在2014年看到的峰值的3倍。

Streamroot为法国最大的私人广播公司TF1，以及南美洲的国家电视网络提供了世界杯。为了可以以这种规模为咱们的客户服务，咱们须要扩展咱们本身的Kubernetes引擎并可以更快地扩展。咱们须要：

• 处理大量流量，每分钟有数十万个请求到咱们的后端
• 在每届世界杯比赛开始时，在几分钟内达到巨大的峰值
• 确保100％防故障、彻底容错、坚固的后端可以承受任何故障。做为一名体育爱好者，我知道在现场直播期间甚至有两分钟的停机时间是彻底不可接受的...

最后但并不是最不重要的是，咱们必须经过只有少数后端工程师的创业规模团队完成全部这些工做...

若是你对咱们过去几个月的扩展历程感兴趣，并但愿深刻了解技术细节，你能够在Jordan Pittier和Nikolay Rodionov在莫斯科举行的HighLoad++会议演讲，以及咱们的幻灯片中查看。

技巧＃1：新事物并不老是好事：使用云原生技术轻装上阵。

自加入云原生计算基金会（CNCF）以来，Kubernetes已呈指数级增加，对这一复杂解决方案的兴趣日益浓厚，这是一种开源云原生技术的组合。去年12月，CNCF的KubeCon + CloudNativeCon在西雅图集合了来自世界各地的8000多名与会者。

Kubernetes是云原生技术组件之一。还存在许多其余组件，有一些在CNCF托管（https://landscape.cncf.io/），有一些在CNCF以外，如Istio。

云原生技术还很年轻，每个月在不一样领域涌现出各类新组件：存储、安全性、服务发现、软件包管理等。

咱们的建议：谨慎使用这些新组件，并保持简单（、傻瓜）。这些技术是新的，有时仍然比较粗糙，并以使人难以置信的速度发展。尝试使用全部最新的闪亮技术是没有意义的，特别是在生产中，除非这些技术是出于真正的须要。即便你拥有庞大的优秀工程师团队，你也须要考虑维护、运营和调试这些有时缺少稳定性的新技术的成本（资源和时间）。

做为经理和CNCF大使，我建议遵循CNCF分类（https://www.cncf.io/projects/）来选择具备足够成熟度级别的原生组件。CNCF定义的标准包括采用率、寿命以及是否能够依赖开源项目来构建生产工具。今天，Streamroot只利用了3个项目（Kubernetes、Prometheus和Envoy），这些项目处于成熟水平，并根据CNCF基金会已经“毕业”。那里的大量组件仍处于孵化阶段或沙箱阶段。你仍然可使用这些，但请记住，你将面临一些风险：稳定性、错误、有限的社区、学习曲线等。

最重要的是，要明白，即便可能广泛相信孵化或沙箱阶段的全部原生项目均可以填补空白并成熟生产，但这也须要考虑不会增长架构复杂性的问题。在从CNCF或CNCF外部添加任何新组件以前，请务必先问本身如下事项：

• 我真的须要这个组件吗？
• 我在解决一个真正的基础设施问题吗？
• 个人工程师如今和从长远来看可以应付它吗？

图：CNCF分类

技巧＃2：控制你的成本

当启动一个重要的项目，好比将服务从基于VM的服务，转移到Kubernetes支持的基于容器的体系结构时，你的主要关注点可能不是成本，而是成功迁移。虽然你的后端成本可能不是一个即时或中期的问题，但从第一天开始就要考虑到这一点。我强烈建议你尽早跟踪Kubernetes Engine扩展成本，缘由以下：

• 清楚地了解你的资源使用状况和软件效率。后端团队的主要关注点是交付，从管理角度来看，一般很难传达高效软件和资源使用的重要性。
• 在你的架构中发现改进的空间。对来自监控和成本进展的信息进行三角测量，有助于咱们肯定架构的改进。经过简单地使咱们的实例适应咱们的使用，并更好地了解资源的使用和消耗方式，咱们可以将成本下降22％。
• 利用基于数量的成本节约。大多数云供应商（包括Google Cloud和Amazon AWS）都会为提交的实例提供有趣的折扣。不要犹豫，为你的利益使用基础设施成本核算（和减小）。一旦达到必定的支出，即便下降10％的成本，也能够在预算中增长几千甚至几十万美圆，这能够用来派遣你的团队参加会议，甚至能够雇用一个新资源来构建你的产品更快！

为了说明个人第三点，GCP提供持续使用折扣选项，为长期承诺的实例提供显着折扣。例如，若是你承诺一全年的资源，你能够得到30％的折扣（就只一次，实际上很高兴在月底看到帐单！）。这些折扣最高可达57％（！），为期3年。固然，我建议在承诺任何内容以前至少等待6个月，以便肯定你最少使用的平均CPU和RAM资源。

别怕！你无需成为公司财务或计费方面的专家便可有效跟踪你的成本。例如，若是你但愿跟踪每个月使用状况，则能够默认为每一个项目启用费用提醒，而后使用CSV导出功能输入你喜欢的电子表格工具。或者，在GCP上，你能够启用Bigquery Billing Export选项，以便每日导出资源消耗的全部详细信息。而后，花几分钟时间构建一个带有SQL导出或Excel的简单仪表板（不要忘记让工程师正确设置资源标签以识别不一样的行）。

技巧＃3：隔离并保持你的生产安全

许多博客和文章建议你仅使用一个K8群集，但为不一样的环境使用不一样的命名空间（例如，Dev、Staging和Production）。命名空间是一个很是强大的功能，能够帮助你组织Kubernetes资源并提升团队的速度。可是这种设置并不容易：你须要确保有一个完善的CI/CD环境，以免你的staging和prod环境之间的任何干扰，以及像部署错误组件在错误的命名空间中的“愚蠢”错误。读到这篇文章时，你可能会想：“固然，但咱们有一个超级聪明的团队，因此咱们可以处理它。”在那里停一停：每一个人都犯愚蠢的错误，错误越愚蠢，它会发生的机会越多...因此，除非你想要在生产中救火过最紧张的日子，只由于你在那里推进了一个Staging版本，若是使用命名空间的选项，你必须花几周的时间创建一个顶级的CI/CD工做流程。

在咱们这边，咱们选择了另外一个选项来保持咱们的环境分离：咱们决定为咱们的登台（Staging）和生产环境建立彻底自治的集群。这消除了人为错误和安全性故障传播的全部风险，由于两个集群都是彻底隔离的。这种方法的缺点是它会增长你的固定成本：你须要更多的计算机来保持两个集群的正常运行。但它带来的安全和安心对咱们来讲是很是值得的。

此外，你能够经过使用GCP的短暂实例来下降成本开销，这比普通实例便宜80％。固然，这有一个问题：若是Google Cloud须要其余客户，那么这些实例可能会随时关闭。可是当咱们仅将它们用于咱们的临时环境时，丢失一台机器并不会真正影响咱们，咱们甚至学会了利用它来发挥咱们的优点。对咱们来讲，完美的测试是看看咱们的架构如何对咱们的一个组件的随机故障做出反应：一种彻底不可预测的红队试图摧毁系统，由Google Cloud免费提供给你

技巧＃4：从一开始就统一并自动化你的工做流程

当你开始一个新项目时，你考虑的最后一件事是如何与其余开发者共享代码，或者在须要执行紧急回滚时如何在生产和Staging之间推送构建。这是正常并且很是明智：在你真正构建了能够向世界展现的任何东西以前，没有必要进行过分优化。但另外一方面，让这些问题潜伏在永恒中是一个常见的错误。由于你没有时间，须要发布下一个功能，使你的产品最终跨越鸿沟并神奇地带来数百万用户。我对此的建议是花时间尽早建立一个简单有效的工做流程。

首先，一旦你开始与其余人合做，你应该退后一步，建立一个统一且易于转移的开发环境。10年前，这不是一件容易的事：你须要在每一个人的计算机上配置特殊虚拟机，或者在Mac和Windows用户之间进行修改。这是一场真正的噩梦，并引起了许多没必要要的和调试不了的问题。今天，多得了像Docker这样的容器化工具，它能够在不到几天的时间内完成，那么为何不从一开始就实现呢？这将大大简化全部开发者的生活，并使新员工的入职变得简单直接。对于你将节省的全部调试和设置周数来讲，这是一笔很是小的投资。

其次，一旦你有生产流量，就应该考虑建立一个简单但有效的QA/CI/CD工做流程。不须要过早设计过分，但咱们很是幸运地生活在自动化和CI工具的黄金时代，这使你能够毫无困难地实现自动化的一流CI和CD。符合kubernetes API的CI工具列表很长，例如10.1版GitLab引入了与Kubernetes或Jenkins X的集成。大多数公司为小规模项目提供低成本计划，并为开源项目提供免费计划，因此你真的没有任何借口不使用它们！这不是火箭科学，它将为你节省时间、精力和无数头痛，让你的开发者的生活更轻松！

总结一下

Kubernetes和云原生提供了出色的技术，能够简化和支持在云上构建可扩展且灵活的解决方案。不久以后，咱们将Kubernetes视为云技术中无处不在的一部分，就像咱们如今使用Linux和TCP/IP等技术。

因为咱们成功地迁移到这些服务，咱们可以将咱们的基础设施持续扩展到世界杯观众及其余人。在历史上规模最大的体育赛事中，咱们提供超过1.2 Tbps的流量，零停机时间 - 全部这一切都只有两名后端工程师。咱们如今可以处理数百万观众的视频流，峰值每秒有数万个新请求到达。

归功我在本文中讨论过的最佳实践，咱们不只可以从架构、成本和资源角度实现咱们的短时间交付目标，还能实现基础架构的长期可扩展性。总结咱们的主要内容：

• 当工具符合实际须要时，请当心谨慎地使用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即将首次合体落地中国
KubeCon + CloudNativeCon + Open Source Summit购票窗口，当即购票！
CNCF邀请你加入最终用户社区