应用迁移方案_Kubernetes如何成为迁移旧版应用程序的解决方案

应用迁移方案

在互联网的早期，如果要启动应用程序，则必须购买或租用硬件。 这是一台物理服务器或服务器机架，并且每个应用程序需要一台服务器，因此非常昂贵。 在2001年，VMware推出了虚拟化软件，该软件允许用户在同一硬件上运行多个应用程序。 这意味着您可以将一个盒子拆分为多个虚拟盒子，每个虚拟盒子都运行自己的环境和应用程序。 为企业节省的成本是巨大的。

快进到2006年。Amazon通过Amazon Web Services及其弹性计算云（EC2）推广了基础架构即服务（IaaS）的概念。 您不再需要购买自己的硬件。 您甚至不必担心运行和管理运行您的应用程序的虚拟机。 您实际上是在租用运行服务所需的计算环境和基础架构。 您按小时付费，就像租用会议室一样。 这使公司可以优化资源以降低成本，并仅购买所需数量的计算能力。 它具有革命性，并导致计算成本的惊人下降。

此后三年，Heroku提出了平台即服务（PaaS）的想法。 PaaS通过取消对虚拟操作系统的管理来操作EC2之上的一层。 Heroku极大地简化了应用程序新版本的部署； 现在您只需要输入git push heroku 。 一些最著名的网络公司起源于Heroku。

这些进步使部署各种规模的应用程序（无论大小）变得更加容易且更加经济实惠。 他们促成了许多新业务的创建，并推动了公司如何对待基础架构的根本性转变，将基础架构从资本支出转变为可变运营支出。

尽管听起来不错，但是有一个大问题。 所有这些提供商都是专有公司。 这是供应商锁定。 在各种环境之间移动应用程序很困难。 混合和匹配本地和基于云的应用程序几乎是不可能的。

那时就是开放源代码的介入。它再次是Linux，除了软件是Docker和Kubernetes （云的Linux）。

开源救援

Docker诞生于2013年，普及了容器的概念。 当运输公司用可装在船，卡车和有轨电车上的大型金属盒代替临时货运时，“容器”这个名称呼应了全球革命。 有效载荷无关紧要。 盒子是标准的。

这导致了另一个问题。 管理容器给DevOps团队带来了沉重的负担 。 它使活动部件的数量和围绕应用程序部署的动态活动发生了逐步变化。 输入Kubernetes 。

2015年，Google发布了Kubernetes作为开源项目。 它是Google内部系统Borg的实现。 Google和Linux基金会创建了Cloud-Native Computing Foundation（ CNCF ），将Kubernetes（和其他云原生项目）托管为一个独立项目，由其周围的社区管理。 KubernetesSwift成为历史上增长最快的开源项目之一，在数十家公司和组织中成长为成千上万的贡献者。

使Kubernetes如此令人难以置信的是它对Google自己在Borg中的体验的实施。 没有什么比Google的规模强大。 博格每周发射超过20亿个容器，平均每秒发射3,300个容器。 在鼎盛时期，还有很多很多。 Kubernetes诞生于大火中，经过了战斗测试，可以应付大量工作。

1_cncf-history.png

^{Linux Foundation， CC BY 3.0}

基于Docker和Kubernetes的核心思想，CNCF成为了许多其他云原生项目的所在地。 如今，在云原生空间中有369多个大型和小型项目。 由CNCF托管的关键云计算的本地项目包括Kubernetes ， 普罗米修斯 ， OpenTracing ， Fluentd ， Linkerd ， GRPC ， CoreDNS ， RKT ， containerd ， 集装箱网络接口 ， CoreDNS ， 特使 ， 积家 ， 公证 ， 更新框架 ， 鲁克和Vitess 。

2_cncf-landscape.jpg

^{Linux Foundation， CC BY 3.0}

但是，从其他开放源代码项目的错误中吸取教训后，CNCF格外谨慎，以确保仅选择能够协同工作并能够满足企业和初创企业需求的技术。 这些技术正在被广泛采用。

公司涌向开源技术的最大原因之一是避免供应商锁定，并能够跨云和私有基础架构移动其容器。 使用开源，您可以轻松切换供应商，也可以混合使用多个供应商。 如果您有技能，则可以自己管理堆栈。

切下整体块

Kubernetes和容器不仅改变了大规模管理的能力，而且改变了大规模，整体的应用程序，并更容易地将它们分割为更易于管理的微服务。 可以管理每个服务以根据需要扩展和缩小。 微服务还允许更快的部署和更快的迭代，与现代持续集成实践保持一致。 基于Kubernetes的编排允许您通过动态管理和调度这些微服务来提高效率和资源利用率。 它还增加了非凡的弹性。 您不必担心容器发生故障，并且可以随着需求的上升和下降而继续操作。

Kubernetes已成为原生云编排的首选。 它也是开源历史上速度最快的开发项目之一，并得到了AWS，Microsoft，Red Hat，SUSE等主要参与者的支持。

所有这些都会对企业产生直接影响。 根据Puppet的2016年DevOps状态报告，高性能的云原生架构可以更频繁地开发，缩短交货时间，降低故障率并从故障中恢复更快。 这意味着功能可以更快地推向市场，项目可以更快地展开，工程和开发团队的等待时间要少得多。 如今，如果您要从头开始构建新应用程序，那么原生云应用程序架构就是正确的方法。 同样重要的是，云计算本机思维为如何利用现有（棕地）应用程序并将它们缓慢地转换为运行在容器和Kubernetes上的基于微服务的更有效，更具弹性的架构提供了路线图。 布朗菲尔德的整体应用程序构成了当今所有软件产品的绝大部分。

整体是云原生的对立面。 它们昂贵，不灵活，紧密耦合且易碎。 问题是：如何将这些整体细分为微服务？ 您可能需要重写所有大型旧应用程序。 事实是，大多数重写都以失败告终。 您试图重写的第一个系统仍在运行并且不断发展，即使您尝试替换它。 有时，第一个系统的发展太快，您永远无法追上。

您可以更有效地解决此问题。 首先，停止向现有的整体应用程序添加重要的新功能。 有一个“提拉和转移”的概念。 这意味着您可以处理一个需要千兆字节RAM的大型应用程序，并在其周围包装一个容器。 简单。

从整体式过渡到容器的示例

票务大师就是这种方法的一个很好的例子 。 它具有在PDP-11上运行的代码。 它创建了一个在Docker容器中运行的PDP-11仿真器，以便能够将该旧应用程序进行容器化。 Kubernetes有一项特定的技术，称为状态集 （以前称为PetSet），它允许您将容器锁定到一个硬件上，以确保其具有活动的性能。

Ticketmaster有一个独特的问题：每当售票时，由于所有人进入，它实际上是在对自身发起分布式拒绝服务（DDoS）攻击。该公司需要一套可以扩展和扩展的前端服务器。处理该需求，而不是尝试在其旧版应用程序中编写它。 取而代之的是，它为此目的在旧版应用程序之前部署了一组新的微服务容器，从而最大程度地减少了旧版架构中的持续扩展。

在尝试将工作负载从旧版应用程序转移到容器时，您可能还希望将某些功能从应用程序转移到微服务中，或使用微服务添加新功能，而不是添加到旧代码库中。 例如，如果要添加OAuth功能，则可以在旧版应用程序前面放置一个简单的Node.js应用程序。 如果您具有对性能高度敏感的任务，则可以用Golang编写它，并将其设置为驻留在旧式整体前面的API驱动的服务。 您仍然可以将API调用返回到您现有的旧版独石。

这些新功能可以由不同的团队用更现代的语言编写，这些团队可以使用自己的一组库和依赖项，并开始拆分整体。

北卡罗来纳州的KeyBanc是这种方法的一个很好的例子。 它在其旧版Java应用程序之前部署了Node.js应用程序服务器，以处理移动客户端。 这比添加遗留代码更简单，更有效，并且有助于其基础架构过时。

真正的云原生是互补项目的集合

如果您正在使用云原生技术，则应考虑一系列补充项目以提供核心功能。 例如，在云原生环境中，最大的优先事项是监视，跟踪和日志记录。 您可以使用Prometheus，OpenTracing和Fluentd。 Linkerd是一个服务网格，支持更复杂的路由版本。 gRPC是一个非常高性能的API系统，可以替换需要更高吞吐量的应用程序的JSON响应。 CoreDNS是一个服务发现平台。 这些都是当今CNCF的一部分，我们希望将更多项目添加到我们的补充解决方案中。

绿地，棕地，任何领域都可以是云原生的

当您将遗留的整体迁移到云原生的微服务时，您无需走绿路并重写所有内容。 Kubernetes等CNCF技术喜欢棕地应用。 几乎所有的企业和公司都应该有一条发展的道路。 您可以在Kubernetes中建立一个全新的应用程序，也可以将您的整体稳定地发展成一个漂亮的云原生微服务网格，将为您服务多年。

向云原生社区成员了解更多信息，他们将在 2018年5月2日至4日在哥本哈根 举行的 KubeCon + CloudNativeCon EU 上进行 演讲 。 有关详细信息，请参见会议时间表 。

想通过Kubernetes掌握微服务吗？ 了解如何在自定进度的动手实验室环境中运行OpenShift容器平台。

翻译自: https://opensource.com/article/18/2/how-kubernetes-became-solution-migrating-legacy-applications

应用迁移方案