云原生技术：详尽的知识解析

戳蓝字“CSDN云计算”关注我们哦！

本文旨在揭示现代软件行业的关键主题——云原生应用程序。这篇文章涉及微服务、容器和无服务器应用程序。在这里，我们将讨论这些技术的实际优点和缺点。

微服务是什么

微服务架构作为构建现代软件应用程序的强大方法而享有盛誉。那么什么是微服务？微服务可以简单地描述为，将软件应用程序所需的功能分离为多个独立的小型软件服务或“微服务”。每个微服务负责自己专注的任务。为了使微服务协同工作以形成大型可伸缩应用程序，它们之间进行通信和交换数据。

微服务的诞生是因为需要克服单体应用程序的复杂性和不灵活性。单体应用程序是一种应用程序，其中所有必需的功能一起编码到同一服务中。例如，这是一个表示单体活动（如音乐会、演出等）预订应用程序的图表，负责预订支付处理和活动预订：

用户可以使用该应用程序预订音乐会或演出。需要一个用户界面。此外，我们还需要一个搜索功能来查找活动、一个预订处理程序来处理用户预订然后保存该预订、一个活动处理程序来帮助查找活动（确保有可用的座位，然后将其链接到预订）。在生产级应用程序中，需要更多的任务，例如支付处理，但是现在我们主要关注上图中概述的四个任务。

这种单体应用程序适用于中小负载。它在单个服务器上运行，连接到单个数据库，并且可能使用相同的编程语言编写。

现在，如果业务呈指数级增长，需要处理数十万或数百万用户，会发生什么？最初，短期解决方案是确保运行应用程序的服务器具有强大的硬件规格以承受更高的负载，如果没有，则向服务器添加更多内存、存储和处理能力。这称为垂直缩放，是增加硬件功能的行为（如RAM和硬盘驱动器容量），以运行繁重的应用程序。但是，从长远来看，这通常是不可持续的，因为应用程序上的负载持续增加。

单体应用程序的另一个挑战是仅限于一种或两种编程语言所导致的不灵活性。这种不灵活性会影响整体质量和应用效率。例如，node.js是用于构建Web应用程序的流行JavaScript框架，而R在数据科学应用程序中很流行。单体应用程序很难同时使用这两种技术，而在微服务应用程序中，我们可以简单地构建用R编写的数据科学服务和用Node.js编写的Web服务。

活动应用程序的微服务版本将采用以下形式：

此应用程序将能够在多个服务器之间进行扩展，这种做法称为水平扩展。每个服务都可以使用专用资源部署在不同的服务器上，也可以部署在不同的容器中（稍后会详细介绍）。不同的服务可以用不同的编程语言编写，从而实现更大的灵活性，不同的专业团队可以专注于不同的服务，从而实现应用程序的更高整体质量。

使用微服务的另一个显著优势是易于持续交付，这是经常、在任何时间部署软件的能力。微服务使持续交付更容易的原因是，与单体应用程序相比，部署到一个微服务的新功能不太可能影响其他微服务。

微服务的问题

严重依赖微服务的一个显著缺点是，随着数量和范围的扩大，它们可能变得太复杂而无法长期管理。有一些方法可以通过利用Prometheus等监控工具来检测问题，像Docker这样的容器技术来避免污染主机环境并避免过度设计服务。但是，这些方法需要付出努力和时间。

云原生应用程序

微服务架构非常适合云原生应用程序。云原生应用程序简单地定义为从头开始为云计算架构而构建应用程序。这意味着，如果我们将应用程序设计为预期将部署在分布式、可扩展的基础架构上，我们的应用程序就是云原生的。

例如，构建具有冗余微服务架构的应用程序使得应用程序云原生化，因为这种架构允许我们的应用程序以分布式方式部署，从而使其可扩展且几乎总是可用。云原生应用程序不需要始终部署到AWS等公有云，我们可以将其部署到自己的分布式云基础设施中（如果有的话）。

实际上，使应用程序完全云原生的原因不仅仅是使用微服务。你的应用程序应采用持续交付，这样你能够不间断地为生产应用程序提供更新。你的应用程序还应该使用消息队列和容器、无服务器等技术（容器和无服务器是现代软件架构的重要主题）。

云原生应用程序假定可以访问众多服务器节点，可以访问预先部署的软件服务（如消息队列或负载均衡器），易于与持续交付服务集成等。

如果将云原生应用程序部署到AWS或Azure等商业云，则应用程序可以选择使用只能在云上用的软件服务。例如，DynamoDB是一个功能强大的数据库引擎，只能在AWS上用于生产应用程序。另一个例子是Azure中的DocumentDB数据库。还有仅云的消息队列，例如Amazon Simple Queue Service（SQS），可用于允许AWS云中的微服务之间的通信。

如前所述，云原生微服务应设计为允许服务之间的冗余。如果我们以活动预订应用程序为例，应用程序将如下所示：

每个微服务将分配多个服务器节点，允许部署冗余微服务架构。如果主节点或服务因任何原因而失败，则辅助节点可以接管以确保云原生应用程序的持久可靠性和可用性。这种可用性对于电子商务平台等不容错的应用程序至关重要，因为停机时间会导致大量的收入损失。

云原生应用程序为开发人员、企业和初创公司提供了巨大价值。

Prometheus是一个值得一提的微服务和云计算领域的工具。Prometheus是一个开源系统监控和警报工具，可用于监控复杂的微服务架构，并在需要采取措施时发出警报。Prometheus最初是由SoundCloud创建的，用于监控他们的系统，后来逐渐发展成为一个独立的项目。该项目现在是云原生计算基础的一部分，该基础是为云原生应用程序构建可持续生态系统的基础。

云原生的限制

对于云原生应用程序，如果需要迁移部分或全部应用程序，你将面临一些挑战。这是由多种原因造成的，具体取决于部署应用程序的位置。

例如，如果你的云原生应用程序部署在AWS等公有云上，则云原生API不是跨云平台的。因此，应用程序中使用的DynamoDB数据库API仅适用于AWS，但不适用于Azure，因为DynamoDB仅属于AWS。API也永远不会在本地环境中工作，因为DynamoDB在生产中只能在AWS中用。

另一个原因是因为在构建一些云原生应用程序时会做出一些假设，例如在需要时可以使用几乎无限数量的服务器节点，并且可以非常快速地使用新的服务器节点。在需要购买真正的服务器、网络硬件和布线的本地数据中心环境中，有时难以保证这些假设。

容器

软件容器技术是下一个需要讨论以解释云原生应用程序的关键技术。容器只是将一些软件封装在隔离的用户空间或“容器”中的想法。

例如，MySQL数据库可以在容器内部隔离，其中存在环境变量和它所需的配置。容器外部的软件默认情况下不会看到容器内包含的环境变量或配置。多个容器可以存在于同一本地虚拟机、云虚拟机或硬件服务器上。

容器提供了在同一台机器上运行众多隔离了的软件服务的能力，包括所有配置、软件依赖关系、运行时、工具和附带文件。在云环境中，这种能力转化为节省的成本和工作量，因为为每个微服务配置和购买服务器节点的需求将减少，不同的微服务可以部署在同一主机上而不会相互干扰。容器与微服务架构相结合，是构建现代、便携、可扩展且经济高效的软件的强大工具。在生产环境中，需要多个服务器节点与众多容器相结合才能实现可扩展性和冗余。

除了微服务隔离之外，容器还为云原生应用程序增加了更多好处。使用容器，你可以将具有所需的所有配置、依赖关系和环境变量的微服务移动到新的服务器节点，而无需重新配置环境，实现强大的可移植性。

由于软件容器技术的强大和普及，一些新的操作系统，如CoreOS或Photon OS，是为用作容器的主机而从头开始构建的。

软件行业最受欢迎的软件容器项目之一是Docker。思科、谷歌和IBM等大公司在其基础设施及产品中使用Docker容器。

软件容器世界中另一个值得注意的项目是Kubernetes。Kubernetes是一个允许自动化容器部署、管理和扩展的工具。它是由谷歌建立的，以便管理容器（每周数十亿个）。Kubernetes提供了一些强大的功能，例如容器之间的负载均衡、故障容器的重新启动以及容器使用的存储编排。该项目和Prometheus都是云原生基础的一部分。

容器的复杂性

在容器的情况下，有时管理它们的任务可能变得相当复杂，原因与管理不断增加的微服务数量相同。随着容器或微服务的规模不断扩大，需要有一种机制来识别每个容器或微服务的部署位置、目的是什么以及它们需要什么资源保持运行。

无服务器应用程序

无服务器架构是一种新的软件架构范式，它因为AWS Lambda服务而推广。为了完全理解无服务器应用程序，有助于了解一个称为功能即服务或简称FaaS的重要概念。

FaaS的理念是，诸如亚马逊之类的云提供商甚至是诸如Fission.io或funktion之类的本地软件都可以提供服务，其中用户可以请求远程运行的功能以执行非常特定的任务。功能结束后，这些结果将返回给用户。不维护任何服务或有状态数据，并且用户将功能代码提供给运行该功能的服务。

使用恰当无服务器架构设计的云原生生产应用程序背后的想法是，不构建预期持续运行的多个微服务以执行单个任务，而是构建一个与FaaS结合的微服务较少的应用程序，其中FaaS涵盖不需要持续运行服务的任务。

FaaS是一种比微服务更小的结构。例如，在我们之前介绍的活动预订应用程序的情况下，有多个微服务涵盖不同的任务。如果我们使用无服务器应用程序模型，一些微服务会被替换为用于相同目的的许多功能。

这是一个使用无服务器架构展示应用程序的图：

在此图中，事件处理程序微服务以及预订处理程序微服务被许多产生相同功能的功能所取代。这消除了运行和维护两个现有微服务的需要。

无服务器架构的优势在于，不需要配置虚拟机和/或容器来构建利用FaaS的应用程序部分。一旦它们的功能结束，运行这些功能的计算实例从用户的角度来看就不再存在。此外，需要由用户监控和维护的微服务和/或容器的数量减少，节省了成本、时间和精力。

无服务器架构为软件工程师和架构师提供了另一种功能强大的软件构建工具，可用于设计灵活且可扩展的软件。已知的FaaS有Amazon的AWS Lambda、Microsoft的Azure Functions、Google的Cloud Functions等。

无服务器应用程序的另一个定义是使用BaaS或后端作为服务范式的应用程序。 BaaS的想法是，开发人员只编写其应用程序的客户端代码，然后依赖于托管在云中的多个软件预构建服务（可通过API访问）。BaaS在移动应用程序编程中很受欢迎，开发人员可以依赖大量的后端服务来驱动应用程序的大部分功能。 BaaS服务的例子有：Firebase和Parse。

无服务器应用程序的缺点

与微服务和云原生应用程序类似，无服务器架构并不适用于所有场景。

FaaS提供的功能本身并不保持状态，这意味着在编写功能代码时需要特别注意。这与全微服务不同——开发人员可以完全控制状态。尽管有这种限制，但在FaaS的情况下保持状态的一种方法是将状态传播到数据库或像Redis这样的内存缓存。

这些功能的启动时间并不总是很快，因为要有时间分配给FaaS服务提供商发送请求，然后在某些情况下启动运行该功能的计算实例也需要时间。在设计无服务器应用程序时必须考虑这些延迟。

FaaS不像微服务那样持续运行，这使得它们不适合任何需要持续运行软件的任务。

无服务器应用程序具有与其他云原生应用程序相同的限制，其中应用程序从一个云提供商到另一个云提供商，或从云到本地环境的可移植性因供应商锁定而变得具有挑战性。

结论

云计算架构为开发高效、可扩展且可靠的软件开辟了道路。本文介绍了云计算领域的一些重要概念，如微服务、云原生应用程序、容器和无服务器应用程序。

微服务是大多数可扩展的云原生应用程序的构建块，它们将应用程序任务分解为各种有效的服务。容器是如何将微服务隔离并安全地部署到生产环境而不污染它们的方式。无服务器应用程序将应用程序任务分离为更小的构造，这些构造通常称为可通过API使用的功能。云原生应用程序利用所有这些架构模式来构建可扩展、可靠且始终可用的软件。

原文链接：

1. http://superuser.openstack.org/articles/modern-cloud-native-architecture-what-you-need-to-know-about-micro-services-containers-and-serverless/

2. http://superuser.openstack.org/articles/modern-cloud-native-architectures-microservices-containers-and-serverless-part-2/