现代云原生架构：关于微服务、容器和无服务器你需要了解的

作者：开源云中文社区 2018-10-19 10:49:53

服务器

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

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

微服务

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

[[246733]]

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

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

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

现在，如果业务呈指数级增长，需要处理数十万或数百万用户，会发生什么?最初，短期解决方案是确保运行应用程序的服务器具有强大的硬件规格以承受更高的负载，如果没有，则向服务器添加更多内存、存储和处理能力。这称为垂直缩放，是增加硬件功能的行为(如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中用。

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