云原生简介(一)

最新推荐文章于 2024-09-18 07:45:46 发布

寒冰屋

最新推荐文章于 2024-09-18 07:45:46 发布

阅读量212

点赞数

分类专栏：微服务文章标签：云原生容器 cloud native

原文链接：https://www.codeproject.com/Articles/5298223/Introduction-to-Cloud-Native

版权

微服务专栏收录该内容

68 篇文章 5 订阅

订阅专栏

使用Docker和Kubernetes进行容器化

Serverless

下一步

在这里，我们将提供基础知识，了解支持云原生开发的概念（DevOps、微服务无服务器、容器化、Kubernetes、CosmosDB等可扩展云数据库等概念），解释这些概念如何影响云的设计和架构——本机应用程序，并强调它们与狂野西部方法的Node应用程序在临时基础上部署到VM的区别。

Node.js的一大优势是其入门门槛相对较低。初学者和经验丰富的程序员都可以使用Node.js快速编写小型Web服务。

初创公司特别迅速地注意到Node.js的吸引力，并迅速将其用于日常任务。然而，它也很早就在银行等大型企业中流行起来，通常是在负责使公司软件方法现代化的数字创新团队中。

Node.js现在是一股不可忽视的力量，它的许多项目的规模和范围都在扩大。曾经流行的狂野西部、编写服务并将其部署到虚拟机(VM)的临时方法已经落后于我们。随着公司寻求更成熟的部署模型，云原生方法很可能就是他们正在寻找的——与Node.js一开始变得如此流行的许多相同的原因。

云与云原生

并非在云中运行的所有内容都是云原生的。在较高的层面上，云原生意味着您的云提供商负责所有硬件和机器维护，因此您不必这样做。实际上，这意味着您的应用程序具有高度的可扩展性和动态性。

云方法

您在云中运行软件，但您不是云原生的。在云中租用服务器与拥有自己的服务器没有太大区别。

例如，在启动VM并部署应用程序时，您仍然必须选择具有足够磁盘空间、内存和处理器速度的VM来支持您的工作负载。此外，您有责任使您的操作系统(OS)和您安装的任何其他软件保持最新状态。

安装您的应用程序可能需要您安装和配置Web服务。扩展具有挑战性，因为它迫使您准备好第二个VM来承担一些工作负载，需要路由平衡器和其他工具。这主要是专门的系统管理员通常执行的手工工作。

云原生方法

现在考虑云原生。你选择你的云服务，启动它，它就在那里。Web应用程序（例如Node.js）可以是Azure上的应用服务。您只需选择您的计划，这与选择您的VM的硬件相当，但稍微容易一些，并且您可以在以后进行更改。然后，您部署您的应用程序，这就像上传一个包一样简单。之后，它只是运行。当您的应用程序繁忙时，您可以直接按一个按钮来扩展。更好的是，您可以设置阈值，以便Azure自动上下扩展您的应用程序。

您可能也需要一个数据库。有几个云原生数据库选项，例如Azure SQL和Cosmos DB。Cosmos DB很有趣，因为它完全拥抱云并且具有高度的可扩展性。最好的部分：它有一个MongoDB接口，因此它可能已经与您的MEAN堆栈应用程序一起使用。您只需单击几下即可启动并运行MongoDB实例。

使用云原生，设置一些基础设施和托管您的应用程序就像在Node.js中构建服务一样容易。两者相辅相成，Node.js运行在许多Azure服务上。

自动化的力量

云原生的一个很酷的特性是它很容易完全自动化。可以通过Azure资源管理模板（或ARM模板）创建和配置云资源，该模板是一个JSON文件，用于描述所需的一个或多个服务。另一种选择是PowerShell或批处理脚本，或者，当您在Linux上运行时，使用PowerShell Core或shell脚本。

通过自动化您的基础架构发布，您可以轻松启动新环境并将发布带回软件团队。这减少了部署错误的可能性，同时加快了部署速度。自动化允许采用DevOps团队：开发和运营结合在一起，以实现发布稳定软件的共同目标。

进入DevOps

DevOps和云原生相得益彰。DevOps团队努力缩短开发周期并实践持续发布和部署。也就是说，一旦您将代码提交到代码存储库（通常是Git），它就会自动构建和测试（也称为持续集成或CI），然后部署到各种环境（持续部署或CD）。这种自动化的构建、测试和部署就是CI/CD。

在过去，运维需要一个软件包并将其安装在服务器上，通常甚至不需要与开发人员会面。在DevOps团队中，运维与开发人员一起工作，以确保环境检查软件运行所需的所有框。

Azure DevOps 服务可帮助DevOps团队实施敏捷或Scrum方法和CI/CD。

微服务的模块化和可扩展性

许多应用程序，尤其是较旧的应用程序，曾经被编写为一个巨大的包，也称为单体应用程序。如果该程序包中出现某些问题，则一切都会中断并且整个应用程序都不可用。

这并不总是有意义的。例如，如果销售模块出现故障，帮助台员工就没有理由不能查阅客户信息。在单体应用中，扩展是一个挑战，因为你必须扩展一切，或者什么都不扩展。

随着云原生和DevOps的兴起，部署应用程序变得更加容易，以至于一切都完全自动运行。这提供了像微服务这样的新可能性。使用微服务，您无需编写和部署一个庞大的应用程序，而是编写和部署几个一起工作的较小的、松散耦合的应用程序。然后，如果其中一个出现故障，系统的其他部分仍能正常运行。

微服务支持扩展，因为扩展系统的各个部分更容易。作为额外的好处，维护几个较小的应用程序通常也比维护一个巨大的应用程序更容易，因为后者可能要复杂得多。另外，如果您需要，您可以用不同的语言编写程序的不同部分。

Azure的各种服务运行微服务，并且都完全支持Node.js。

使用Docker和Kubernetes进行容器化

虽然微服务确实解决了传统软件开发的一些挑战，但它们也带来了一些新的挑战。运行和部署数十甚至数百个服务并不容易，尤其是当这些服务具有各种依赖项或使用不同语言编写时。容器化旨在解决这个问题，目前最流行的容器解决方案是Docker。

容器最好被描述为轻量级虚拟机，尽管它在技术上不是虚拟机。容器在主机上运行，并且与VM不同，它使用主机的操作系统。然而，容器的行为有点像沙箱，因为它几乎完全与系统的其余部分隔绝。容器可以包含运行应用程序所需的特定语言的特定运行时的特定版本。在同一主机上运行的另一个容器可能具有相同的语言，但具有不同的版本。容器可以将运行应用程序所需的所有依赖项打包在一起。这使您能够在完全自定义的容器中运行您的软件，并且只需将容器发送给任何人即可运行。

下一个挑战是微服务之间的依赖关系并确保它们保持正常运行。这就是我们拥有容器编排器的原因。迄今为止最受欢迎的是Kubernetes，它与Docker完美配合。使用协调器，您可以描述哪些服务应该在何处运行、需要多少实例、何时需要扩展等等——基本上，您的环境应该如何表现。

Azure为Docker和Kubernetes提供了云原生解决方案。