在互联网的早期，如果您想启动一个应用程序，您必须购买或租用硬件。这是一个物理服务器或一组服务器，每个应用程序都需要一个服务器，因此成本很高。2001 年，VMware 推出了虚拟化技术——允许用户在同一硬件上运行多个应用程序的软件。这意味着您可以将一台机器分成多个虚拟机，每个虚拟机运行自己的环境和应用程序。这为企业节省了巨大的成本。
快进到 2006 年。亚马逊通过 Amazon Web Services 及其弹性计算云 (EC2) 普及了基础设施即服务 (IaaS) 的概念。您不再需要购买自己的硬件。您甚至不必担心运行和管理运行应用程序的虚拟机。您实际上是在租用运行服务所需的计算环境和底层基础设施。您按小时付费，就像租用会议室一样。这使得公司能够优化资源以降低成本，并只购买他们需要的计算能力。这是一项革命性的变革，导致计算成本大幅下降。
三年后，Heroku 提出了平台即服务 (PaaS) 的想法。PaaS 在 EC2 之上运行，消除了虚拟操作系统的管理。Heroku 神奇地简化了部署新版本的应用程序；现在您只需要输入 git push heroku。一些最知名的网络公司起源于 Heroku。
这些进步使得以任何规模（无论大小）部署应用程序都变得更加容易和经济实惠。它们催生了许多新业务，并推动了公司对待基础设施方式的根本转变，将其从资本支出转变为可变运营支出。
尽管这一切听起来都不错，但还是有一个大问题。所有这些提供商都是专有公司。这是供应商锁定。在各种环境之间移动应用程序非常困难。而且，混合和匹配本地和基于云的应用程序几乎是不可能的。
那时开源介入了。这就像 Linux 再次出现，只不过软件是 Docker 和 Kubernetes，云端的 Linux。
开源来救援
Docker 于 2013 年兴起，普及了容器的概念。“容器”这个名称呼应了全球革命，当时航运公司用适合船舶、卡车和火车的金属大箱子取代了临时的货物装载方式。有效载荷无关紧要。箱子是标准。
与海运集装箱类似，Docker 容器创建了一个基本的计算包装器，可以在任何基础设施上运行。容器席卷全球。如今，几乎所有企业都在计划在容器基础设施之上构建未来的应用程序——即使他们是在自己的私有硬件上运行这些应用程序。这只是管理现代应用程序的一种更好的方式，这些应用程序通常被切分成无数组件（微服务），需要易于移动和连接。
这导致了另一个问题。管理容器给 DevOps 团队带来了前所未有的压力。它在移动部件的数量和围绕应用程序部署的动态活动方面造成了阶跃变化。输入 Kubernetes。
2015 年，Google 发布了 Kubernetes 作为开源项目。它是 Google 内部系统 Borg 的一个实现。Google 和 Linux 基金会创建了 云原生计算基金会 (CNCF)，以托管 Kubernetes（和其他云原生项目）作为一个独立的项目，由围绕它的社区管理。Kubernetes 迅速成为历史上增长最快的开源项目之一，贡献者遍布数十家公司和组织，达到数千人。
Kubernetes 如此令人难以置信的原因在于它实现了 Google 自己使用 Borg 的经验。没有什么能比得上 Google 的规模。Borg 每周启动超过 20 亿个容器，平均每秒 3,300 个。在高峰期，数量还要多得多。Kubernetes 诞生于烈火中，经过实战检验，可以应对大规模工作负载。
opensource.com
CNCF 在 Dockers 和 Kubernetes 的核心思想基础上，成为了许多其他云原生项目的家园。今天，云原生领域有超过 369 个大大小小的项目。CNCF 托管的关键云原生项目包括 Kubernetes、Prometheus、OpenTracing、Fluentd、Linkerd、gRPC、CoreDNS、rkt、containerd、容器网络接口、CoreDNS、Envoy、Jaeger、Notary、The Update Framework、Rook 和 Vitess。
opensource.com
然而，从其他开源项目的错误中吸取教训，CNCF 一直格外小心，以确保它只选择那些协同工作良好并且可以满足企业和初创公司需求的技术。这些技术正在被大规模采用。
公司蜂拥而至开源技术的最大原因之一是为了避免供应商锁定，并能够在云和私有基础设施之间移动其容器。借助开源，您可以轻松切换供应商，或者可以使用多家供应商的组合。如果您具备技能，您可以自己管理您的堆栈。
切分单体应用
Kubernetes 和容器不仅改变了大规模管理的能力，还改变了更轻松地将大型单体应用程序切分成更易于管理的微服务的能力。每个服务都可以根据需要进行扩展和缩减。微服务还允许更快的部署和更快的迭代，以符合现代持续集成实践。基于 Kubernetes 的编排允许您通过动态管理和调度这些微服务来提高效率和资源利用率。它还增加了一个非凡的弹性水平。您不必担心容器故障，并且可以在需求上升和下降时继续运行。
Kubernetes 已成为云原生编排的首选。它也是开源历史上开发速度最高的项目之一，并得到了包括 AWS、Microsoft、Red Hat、SUSE 和更多主要参与者的支持。
所有这些都对企业产生了直接影响。根据 Puppet 的 2016 年 DevOps 状态 报告，高性能云原生架构可以实现更频繁的开发、更短的交付周期、更低的故障率以及更快的故障恢复。这意味着功能可以更快地推向市场，项目可以更快地调整方向，并且工程和开发团队的等待时间大大减少。今天，如果您要从头开始构建一个新的应用程序，云原生应用程序架构是正确的方法。同样重要的是，云原生思维为如何获取现有（棕地）应用程序并将其缓慢转换为在容器和 Kubernetes 上运行的更高效和弹性的基于微服务的架构提供了路线图。棕地单体应用程序构成了当今大多数软件产品。
单体应用是云原生的对立面。它们昂贵、不灵活、紧密耦合且脆弱。问题是：如何将这些单体应用分解为微服务？您可能想要重写所有大型遗留应用程序。事实是，大多数重写都以失败告终。您尝试重写的第一个系统，在您尝试替换它的同时，仍然在运行和演变。有时，第一个系统演变得太快，您永远无法赶上。
您可以用更有效的方式解决这个问题。首先，停止向您现有的单体应用程序添加重要的新功能。有一个“提升和转移”的概念。这意味着您可以将一个需要千兆字节 RAM 的大型应用程序包装在一个容器中。就这么简单。
从单体应用过渡到容器的示例
Ticketmaster 是一个很好的例子，说明了这种方法。它有代码运行在 PDP-11 上。它创建了一个在 Docker 容器内运行的 PDP-11 模拟器，以便能够容器化该遗留应用程序。Kubernetes 有一项专门的技术，称为 Stateful Sets（以前称为 PetSets），它允许您将容器锁定到一台硬件上，以确保它具有活跃的性能。
Ticketmaster 有一个独特的问题：每当它出售门票时，由于涌入的人太多，它实际上是在对自己发起分布式拒绝服务 (DDoS) 攻击。该公司需要一组可以扩展的前端服务器来处理这种需求，而不是尝试在其遗留应用程序中编写它。相反，它在其遗留应用程序的前面部署了一组新的微服务容器，以实现此目的，从而最大限度地减少了其遗留架构中的持续蔓延。
当您尝试将工作负载从遗留应用程序迁移到容器时，您可能还希望将某些功能从应用程序移动到微服务，或者使用微服务来添加新功能，而不是添加到旧代码库中。例如，如果您想添加 OAuth 功能，您可以使用一个简单的 Node.js 应用程序放在您的遗留应用程序前面。如果您有对性能高度敏感的任务，您可以用 Golang 编写它，并将其设置为驻留在您的遗留单体应用前面的 API 驱动服务。您仍然会收到返回到您现有遗留单体应用的 API 调用。
这些新功能可以使用更现代的语言由不同的团队编写，这些团队可以使用他们自己的库和依赖项集，并开始拆分该单体应用。
北卡罗来纳州的 KeyBanc 是这种方法的一个很好的例子。它在其遗留 Java 应用程序的前面部署了 Node.js 应用程序服务器，以处理移动客户端。这比添加到遗留代码更简单、更高效，并有助于使其基础设施面向未来。
真正的云原生是互补项目的集合
如果您要转向云原生技术，您应该考虑一组互补的项目来交付核心功能。例如，在云原生环境中，最重要的优先事项是监控、跟踪和日志记录。您可以使用 Prometheus、OpenTracing 和 Fluentd。Linkerd 是一个服务网格，支持更复杂的路由版本。gRPC 是一个性能极高的 API 系统，可以替换需要更高吞吐量的应用程序的 JSON 响应。CoreDNS 是一个服务发现平台。这些都是今天 CNCF 的一部分，我们希望在我们的互补解决方案集中添加更多项目。
绿地、棕地，任何领域都可以是云原生的
当您将遗留单体应用迁移到云原生微服务时，您不需要进行绿地开发并重写所有内容。像 Kubernetes 这样的 CNCF 技术非常适合棕地应用程序。几乎每个企业和公司都应该走上一条演进之路。您可以在 Kubernetes 中启动一个全新的应用程序，或者稳步将您的单体应用演变为一个优美的云原生微服务网格，这将为您服务多年。
从云原生社区成员在 KubeCon + CloudNativeCon EU，2018 年 5 月 2-4 日，哥本哈根的演讲中了解更多信息。请查看 会议日程 了解详细信息。
想要掌握 Kubernetes 微服务吗？了解如何在自定进度的动手实验室环境中运行 OpenShift 容器平台。
评论已关闭。