Web 应用中的架构转变

每天?分享?最新?软件?开发?，Devops，敏捷?，测试?以及?项目?管理?最新?，最热门?的?文章?，每天?花?3分钟?学习?何乐而不为?，希望?大家?点赞?，评论?，加?关注?，你的?支持?是我?最大?的?动力?。

在过去的几年中，应用程序开发的前景一直在不断变化，无论是在客户端(前端)还是在服务器端(后端)。在客户端，我们有大量令人敬畏的新的和更新的 JavaScript [和其他脚本]框架; 在服务器端，我们有新的架构方法，如单页应用程序、微服务和无服务器架构。

这将是一系列面向整个堆栈开发人员的文章，特别是那些来自服务器端背景的文章，介绍 Web 应用程序设计和开发中的趋势和最佳实践。为了开始这个系列，让我们从研究已经发生的服务器端架构转变开始。

最近的过去: 传统的 N 层架构

在过去的十年里，互联 已经成为提供内容和服务的首选平台。因此，每个企业都希望在线，为了满足这种爆炸式增长的需求，开发人员采用了 N 层架构方法来快速构建和部署可靠的应用程序。

N 层架构由多个独立的层组成; 每个层代表系统的不同关注点。从高层来看，大多数系统通常分为三个主要层: 客户机、服务器和存储。

客户端层是终端用户看到和交互的，通常指的是瘦客户端(比如 Web 浏览器)或者粗客户端(比如完全成熟的 Java Swing/)。 上申请)。

随着时间的推移，存储层保留着重要的数据，即使在断电的情况下也是如此，它通常是一个基本的关系数据库系统(如 MySQL、 Oracle 或 SQLServer)。

服务器层位于客户端和存储层之间，是应用程序所有实际操作发生的地方。由于在这个层中发生了这么多事情，服务器层通常被进一步划分为多个子层: web、 ubbusiness 和持久性。

服务器 Web 层是应用程序在服务器端的入口点，负责处理用户交互、将请求转换为模型、生成和交付动态用户界面、会话管理和其他任务。许多 Java 开发人员依赖 SpringMVC 或 Struts 等框架来实现这一层。

服务器业务层是将业务逻辑实现为一个精心组合和定义良好的 API (应用程序编程接口——函数调用的集合)的地方。像 EJB 这样的技术。NET 和 Spring 通常被用来实现这个层。

服务器持久层负责通过对象关系映射(ORM)工具(如 Hibernate、 EclipseLink、 Spring JDBC Template 或其他 ORM 工具)抽象出应用程序与存储层特定关系数据库的交互。

下图(1)描述了传统的 N 层架构。

架构转变 # 1: 单页应用程序(SPA)的兴起

我们从 AJAX 的新时代中醒来，Gmail 和 Google Maps 等应用一夜成名，刷新整个页面已成为过去。应用程序现在被设计成只请求内容和信息的必要部分(部分响应) ，以便使用瘦客户机创建高度交互的用户体验，而到目前为止，只有使用厚客户机才能做到这一点。在客户端执行此操作所需的额外逻辑并不是什么新鲜事物ーー它几乎与以前在服务器 Web 层中使用的逻辑相同。我们实际上将 Web 层从服务器移动到了客户端(Web 浏览器)。

然而，客户端的这种附加逻辑带来了新的挑战和复杂性，比如必须处理大量的 XMLHttpRequest，并且比以往任何时候都更深入地理解 Web 浏览器的 DOM (文档对象模型)。为了处理这种增加的复杂性，出现了许多新的基于 JavaScript 的框架来处理底层细节和例程操作。有些框架固执己见，有些则不然; 有些是基本框架，有些是端到端解决方案。虽然看起来每隔一天就会出现一个新的框架，但好的框架都采用了之前在服务器 络层成功使用过的最佳实践和模式，包括组件、模型、视图和控制器、注释、依赖注入、服务和接口契约等。

由于 Web 层被从服务器层移除并移动到客户端层，因此为服务器层引入了一个新的薄层，以便将现有的服务器业务层直接暴露给新的客户端 Web 层。这通常是使用自定义 SOAP 或 REST API 完成的。这些 API 的创建和 Web 层布局的架构转变为支持离线支持等功能铺平了道路，但更重要的是，支持多种客户端类型的能力，即使是那些具有不同本地实现的客户端类型，使用相同的后端(想想一个支持 iOS 和 Android 应用程序以及桌面和移动 Web 界面的单一后端)。

下图(2)描述了架构迁移1: Web 层从服务器移动到客户端。

建筑转变 # 2: Microservices 的崛起

将应用程序构建和部署为单个 tarball 的传统方法是如何创建单个应用程序。微服务是一个很小的应用程序，它只实现完整应用程序功能的一小部分。微服务的目标是完成一件事情，并且把这件事情做好，并且可以使用几乎任何技术堆栈来实现，而不一定与其他服务使用相同的堆栈。微服务数量众多，增加了分布式管理、微服务间通信、认证与授权、分布式日志与跟踪、服务注册与发现、反向代理与 关等领域的复杂性。像 Spring 和 Lagom 这样的框架可以通过抽象出许多分布式特性来简化实现。

尽管微服务是当前构建现代应用程序的新趋势，但是选择设计和构建单一应用程序本身并没有什么错。只要您的软件可伸缩性需求和需求变化率是恒定的，那么单一代码库就可以很容易地部署、管理和开发单一的应用程序。

但是，当应用程序的特性增长和/或正常运行时间需求和可伸缩性需求非常高时，考虑将应用程序重构或设计为一组微服务是明智的。微服务允许应用程序水平扩展和独立更改，但是这些好处并不是免费的。众所周知，分布式应用程序很难监视、管理和测试。

下图(3)描述了架构迁移2: 微服务的兴起。

架构转变 # 3: 无服务器架构

无服务器架构是您今天经常在标题中看到的一个流行词。我有意不想把它称为 Web 应用程序架构的下一个迭代。现在这个主意还挺有意思的。

这个概念非常简单——我们已经有一个客户端 Web 层，所以为什么不重构(或设计)后端，以利用第三方托管服务的横切关注点; 通过使用 Lambda (或纯函数) ，您的应用程序可以在第三方的云基础设施上执行任何所需的自定义逻辑。这是一个与微服务非常相似的概念，但是，主要的区别是你不拥有后端服务，因此你不需要开发，管理，或支持这些服务和硬件运行，从而使你的生活更简单。

将所有横切关注点(包括持久性)放入基础设施的想法有很多优点。它可能会大大简化分布式应用程序体系结构，但是在所有问题得到解决并且无服务器体系结构成为主流之前还需要一些时间。目前，无服务器架构处于几年前云托管的同样地位; 企业和客户更关注云托管对数据隐私的威胁，而不是看到其在基础设施简化方面的全部潜力。

下图(4)描述了架构转换(?) : 无服务器架构。