「第二部:容器和微服务架构」(2) 容器化单体应用

简介: 「第二部:容器和微服务架构」(2) 容器化单体应用

您可能需要构建一个单独的、整体部署的web应用程序或服务,并将其部署为一个容器。应用程序本身可能不是内部单一的,而是由几个库、组件甚至层(应用程序层、域层、数据访问层等)构成。但是,在外部,它是一个容器—单个进程、单个web应用程序或单个服务。

要管理此模型,可以部署一个容器来表示应用程序。为了增加容量,您可以向外扩展,也就是说,只需在前面添加更多带有负载平衡器的副本。简单性来自于在单个容器或VM中管理单个部署。


图1 容器化单体应用程序的体系结构示例


可以在每个容器中包含多个组件、库或内部层,如图1所示。单体容器化应用程序的大部分功能都在一个容器中,带有内部层或库,并通过在多个服务器/vm上克隆容器来扩展。然而,这种整体模式可能与容器原则“容器做一件事,在一个过程中做”相冲突,但在某些情况下可能是可以的。

如果应用程序不断增长,需要对其进行扩展,那么这种方法的缺点就显而易见了。如果整个应用程序都可以扩展,这其实不是问题。然而,在大多数情况下,应用程序中只有少数部分是需要扩展的瓶颈,而其他组件使用较少。

例如,在典型的电子商务应用程序中,您可能需要扩展产品信息子系统,因为浏览产品的客户比购买产品的客户多。更多的客户使用他们的购物篮,而不是使用支付管道。添加评论或查看购买历史记录的客户较少。你可能只有少数员工需要管理内容和营销活动。如果缩放整体设计,则这些不同任务的所有代码都会多次部署并在同一级别缩放。

有多种方法可以扩展应用程序的水平复制,分割应用程序的不同区域,并对类似的业务概念或数据进行分区。但是,除了扩展所有组件的问题之外,对单个组件的更改还需要对整个应用程序进行完全的重新测试,并完全重新部署所有实例。

但是,单块方法很常见,因为应用程序的开发最初比微服务方法容易。因此,许多组织使用这种体系结构方法进行开发。虽然一些组织已经取得了足够好的结果,但其他组织正在达到极限。许多组织使用这个模型设计他们的应用程序,因为多年前工具和基础设施使得构建面向服务的体系结构(service-oriented architectures,SOA)变得太困难,直到应用程序增长,他们才看到这一需要。

从基础设施的角度来看,每台服务器可以在同一台主机上运行多个应用程序,并且在资源使用效率方面具有可接受的比率,如图2所示。


图2 整体方法:主机运行多个应用程序,每个应用程序作为容器运行


Microsoft Azure中的单体应用程序可以使用每个实例的专用vm进行部署。此外,使用Azure虚拟机缩放集,您可以轻松缩放vm。Azure应用服务还可以运行单体应用程序并轻松扩展实例,而无需管理VM。自2016年以来,Azure应用服务还可以运行Docker容器的单个实例,从而简化部署。

作为QA环境或有限的生产环境,您可以部署多个Docker主机VM,并使用Azure平衡器平衡它们,如图3所示。这使您可以使用粗粒度方法管理缩放,因为整个应用程序都位于单个容器中。


图3多个主机扩展单个容器应用程序的示例


可以使用传统的部署技术管理到不同主机的部署。Docker主机可以通过Docker run或Docker compose等命令进行管理,这些命令可以手动执行,也可以通过诸如continuous delivery(CD)pipelines之类的自动化进行管理。

将单体应用程序部署为容器

使用容器管理单体应用程序部署有很多好处。扩展容器实

例比部署其他vm快得多,也容易得多。即使使用虚拟机规模集,VM也需要时间来启动。当部署为传统的应用程序实例而不是容器时,应用程序的配置作为VM的一部分进行管理,这并不理想。

将更新部署为Docker映像要快得多,网络效率也高得多。Docker镜像通常在几秒钟内启动,这加快了卷展栏的速度。拆卸Docker映像实例和发出Docker stop命令一样简单,通常不到一秒钟就完成。

因为容器在设计上是不可变的,所以您不必担心损坏的vm。相反,VM的更新脚本可能会忘记解释磁盘上的某些特定配置或文件。

虽然单块应用程序可以从Docker中受益,但我们只谈到了好处。管理容器的其他好处来自与容器编排器一起部署,后者管理每个容器实例的各种实例和生命周期。将单体应用程序分解成可以单独扩展、开发和部署的子系统是您进入微服务领域的切入点。

将单个基于容器的应用程序发布到Azure应用程序服务

无论您想要获得部署到Azure的容器的验证,还是当应用程序只是单个容器应用程序时,Azure应用程序服务都提供了一种提供可伸缩的基于单个容器的服务的好方法。使用Azure应用服务很简单。它提供了与Git的强大集成,使您可以轻松地获取代码、在Visual Studio中构建代码并将其直接部署到Azure。


图4 从Visual Studio 2019将单个容器应用程序发布到Azure应用程序服务


如果没有Docker,如果你需要Azure应用服务中不支持的其他功能、框架或依赖项,你必须等到Azure团队更新了应用服务中的这些依赖项。或者你必须切换到其他服务,比如Azure云服务或VMs,在那里你有进一步的控制权,你可以为你的应用程序安装所需的组件或框架。

Visual Studio 2017及更高版本中的容器支持使您能够在应用程序环境中包含您想要的任何内容,如图4-4所示。由于是在容器中运行,因此如果向应用程序添加依赖项,则可以在Dockerfile或Docker映像中包含依赖项。

如图4所示,发布流通过容器注册表推送镜像。这可以是Azure容器注册表(一个靠近你在Azure中的部署并受Azure活动目录组和帐户保护的注册表),也可以是任何其他Docker注册表,如Docker Hub或本地注册表。

相关文章
|
8天前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
6天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
2天前
|
关系型数据库 MySQL Docker
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
51 5
|
7天前
|
Kubernetes Cloud Native Docker
云原生之旅:从容器化到微服务
本文将带领读者踏上云原生的旅程,深入探讨容器化和微服务架构的概念、优势以及它们如何共同推动现代软件的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务应用,并解释相关的配置和操作。无论你是云原生新手还是希望深化理解,这篇文章都将为你提供有价值的见解和实操指南。
|
13天前
|
Kubernetes Cloud Native 开发者
云原生入门:从容器到微服务
本文将带你走进云原生的世界,从容器技术开始,逐步深入到微服务架构。我们将通过实际代码示例,展示如何利用云原生技术构建和部署应用。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的信息和启示。
|
13天前
|
Kubernetes Cloud Native 持续交付
容器化、Kubernetes与微服务架构的融合
容器化、Kubernetes与微服务架构的融合
29 1
|
13天前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
29 1
|
13天前
|
Cloud Native 安全 持续交付
深入理解微服务架构及其在现代软件开发中的应用
深入理解微服务架构及其在现代软件开发中的应用
29 1
|
26天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
7天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。