云时代哪种应用架构模型最适合你？
越来越多的企业正在经历数字化转型之旅，以满足不断变化的消费者需求。客户也越来越可能使用社交网络、移动应用程序和数字技术。由于这一变化，数字战略现在已成为整体业务战略不可或缺的一部分。
许多企业正在通过互联网通过云服务平台获取计算能力，并在大多数应用程序开发中采用云优先策略。这进一步推动了应用程序设计的变化——以前，功能和状态被优先考虑，但现在大多数面向消费者的应用程序正在转向软件即服务 (SaaS)和数字平台。应用程序设计的重点现在更加关注用户体验、无状态和敏捷性。
选择正确的应用程序架构取决于您的业务需求。在这篇文章中，我们将根据一般业务需求研究实现数字化转型的四种架构选择。
传统的三层应用架构
我们都知道三层应用架构——它是一种客户端-服务器架构，典型的结构包括表示层、应用层和数据库层。
它具有用户界面、业务/数据访问逻辑和数据访问。许多企业应用程序都是使用简单的 3 层应用程序架构创建的。
三层应用架构有什么问题？
简单来说，三层应用模型已经过时了。它是为公共云和移动应用程序扩散之前的应用程序开发而设计的，并且难以适应云计算。
随着时间的推移，应用程序可能会变得太大和太复杂而无法进行频繁更改。不仅如此，它还需要维护至少三层硬件和软件，这对于业务来说可能是低效的。
3 层应用程序模型也经常被称为单体架构。这些天来，我们有多种新的架构模型，下面，我们将研究一些现在在云时代可用的架构模型。
1.微服务架构
在云模型中，设计为服务和数据集合的复杂应用程序与应用程序完全分离。微服务是一种将应用程序构建为服务集合的架构风格。每个服务都可以用不同的编程语言编写并单独测试。它们可以独立部署并围绕业务能力进行组织。
以使用微服务架构开发的电子商务应用程序为例。每个微服务都可以专注于单一业务功能（例如，购物车、搜索、客户评论）。其中每一个都可以是用不同编程语言编写的单独服务，部署在不同的基础架构中，并由不同的团队管理。
每个服务都使用轻量级协议与其他服务进行通信。对于 3 层，我们都知道模型视图控制器 (MVC) 框架。Sidecar、Ambassador 和 Adapter 是一些支持微服务架构的框架。
微服务架构与单体架构
在单体架构中，所有这些组件作为一个模块共存（大部分情况下）由一个团队管理——所有东西都捆绑在一起。如果需要更新，则需要部署整个应用程序，这会减慢大型复杂应用程序的更改速度。对于较小的应用程序，单体架构通常是最佳解决方案。
观看视频“什么是微服务？” 详细了解微服务架构和单体架构之间的区别：
微服务、容器和 Kubernetes
创建和运行微服务应用架构的最佳选择之一是使用容器。容器为您的应用程序封装了一个轻量级的虚拟化运行时环境，并允许您将应用程序从开发人员的桌面一直移动到生产部署。您可以在大多数可用操作系统中的虚拟机或物理机上运行容器。容器提供一致的软件环境，您可以将应用程序的所有依赖项封装为可部署单元。容器可以在笔记本电脑、裸机服务器或公共云中运行。
许多组织使用Kubernetes来管理容器并确保没有停机时间。Kubernetes 在多个主机中提供容器编排，用于容器生命周期管理。您可以使用 Kubernetes 自动部署、自动扩展应用程序以及快速构建和交付。
如需更深入地了解 Kubernetes，请观看我们的视频“Kubernetes Explained”：
红帽 OpenShift是最受欢迎的领先混合云企业容器平台之一。许多公共云提供商提供容器即服务 (CaaS)。其他一些可用的 Kubernetes 引擎包括IBM Cloud Kubernetes Service、开源 Kubernetes、AWS（EKS、ECS 和 Fargate）、Google GKS 和 Azure AKS。
通常每个微服务都是由不同的小团队构建的，他们选择自己的编程语言和部署时间表。企业使用像Istio这样的服务网格来管理微服务和管理之间的通信。在服务网格中，请求通过微服务之间的代理（例如 Sidecar）进行路由。
2、云原生架构
云原生架构专为计划部署在云端的应用程序而设计，而微服务是其中的关键部分。
云原生是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。云原生是用于描述基于容器的环境的术语，它是关于如何创建和部署应用程序，而不是在哪里。
云原生技术使我们能够在公共云、私有云和混合云中运行应用程序。云原生开发对于将应用程序快速推向市场至关重要；它可以帮助人员、流程和技术构建、部署和管理为云做好准备的应用程序。
视频“什么是云原生？” 提供了有关云原生方法的更多背景信息：
云原生架构模型使用DevOps、持续集成(CI)、持续交付(CD)、微服务和容器。大多数企业使用十二因素方法来设计可扩展且强大的云原生应用程序。
在云中，应用程序必须能够在多个节点上同时运行，共享配置/会话状态，具有集中的日志记录机制，并且能够使用 DevOps 和 CI/CD 流程进行部署。许多云提供商提供了云原生开发指南——亚马逊网络服务 (AWS) 有其架构完善的框架，谷歌有各种关于如何构建云原生应用程序的指南，微软 Azure 有它的云模式指南。
通常，云原生应用程序本质上是无状态的。这些服务使用基于 REST 的协议或消息传递相互通信。API 网关、容器注册表、面向消息的中间件（MOM：发布/订阅或请求/响应）、服务网格和编排可能是云原生架构的一部分。
3. 事件驱动的无服务器架构
事件驱动架构 (EDA) 基于为响应事件而运行的解耦系统。事件驱动架构使用事件来触发解耦服务之间的通信。EDA 已经存在很长时间了，但现在它在云中具有更多的相关性。
那么，什么是新的？如果使用得当，它可以显着提高敏捷性、成本节约和运营效益。分布式无服务器EDA 可以执行称为函数的代码，这些代码会自动扩展以响应REST API或事件触发器。
对于无服务器模型，不需要服务器管理。无服务器模型也可以快速扩展（因此可以快速更新和部署）并且它是无状态的。
以下是来自不同云提供商的一些当前可用的云无服务器服务：
无服务器的类型
- 功能即服务（FaaS）：将功能片段上传到云端并让这些片段独立执行。
- 后端即服务 (BaaS)：利用第三方的服务，例如应用程序管理、数据库管理和云存储。
- 移动后端即服务 (MBaaS)：移动应用程序的功能。
4. 基于云的架构
我们如何才能使单体应用程序在云环境中运行良好？基于云的架构最适合构建现代 Web 应用程序（静态/动态网站）、部署 Web 应用程序、连接到数据库以及分析用户行为。
传统的基于云的应用程序架构涉及负载均衡器、Web 服务器、应用程序服务器和数据库。它可以从资源弹性、软件定义的网络、自动配置、高可用性和可扩展性等云功能中受益。
这种类型的架构非常适合不必担心维护服务器的组织。无服务器函数支持不同的编程语言，例如 PHP、Java、.NET、Node.js、Python、Ruby、Docker 和 Go。
API Gateway 是一项重要的服务，可让开发人员轻松创建和发布安全 API。API 将充当应用程序访问数据和业务逻辑的前门。它还负责授权和访问控制。开发人员使用 API Gateway 为不同的 API 调用调用不同的无服务器函数。
如何决定哪种架构模型最适合您的应用程序
您在选择架构模型时做出的决定会影响项目的成败。您应该根据您的应用程序和非功能性需求做出选择。例如，当您只想旅行几英里时，您不会选择飞机运输。
在为您的应用项目选择架构之前，请考虑以下事项：
- 是单体优先还是微服务优先？（对于具有简单应用需求的小型项目，单片机可能是正确的选择。）
- 您的团队准备好使用微服务了吗？
- 您的团队是否有现有的基于云的 DevOps 和 CI/CD 流程？
- 您的托管模式是什么？私有的、公共的、混合的？
- 应用程序架构如何影响您的项目？
- 多种架构模型的组合对您有用吗？
- 您的应用程序需要持久性和会话吗？
总结
Web 应用程序架构不断发展，以满足数字业务需求和不断变化的 IT 基础架构环境。人工智能、分析、自动化、高级机器人、边缘计算、区块链、物联网 (IoT)和 API等技术正在重新定义许多行业的可能性。基础架构、应用程序和数据大小的复杂性不断增加，需要新的架构方法。大多数企业通过使用一个或多个云提供商来采用多云方法。企业通过使用私有、公共或混合 SaaS、PaaS或IaaS模型来使用云服务。
在早期，应用程序部署是一个困难的过程，无法在正常工作时间内完成。但是，不同的部署方法（例如蓝绿和金丝雀部署）以及 DevOps 和 CI/CD（持续集成和持续交付）现在允许随时部署而不会出现任何应用程序中断。
单体架构仍然适用于许多应用程序，但必须为您的数字用例使用正确的架构，以实现敏捷性和上市时间。对于简单的应用程序，请考虑选择传统的单片方法。云原生或微服务模式非常适合具有复杂性的不断发展的应用程序。当您有多个使用多种语言和部署计划的经验丰富的团队时，使用微服务架构是有意义的。下面给出了传统 3/N 层应用程序与基于云的架构模型之间的比较，以供参考。
