[toc]

系统分析师笔记16_Web应用系统分析与设计

该笔记内容来自《系统分析师教程》第2版。

Web应用系统简介

Web应用程序

Web应用程序是在Web浏览器中运行的软件。Web应用程序拥有多个优势，几乎所有大企业都将其作为向用户提供的产品和服务的一部 分。

以下是Web应用程序的一些最常见的优势。

• (1)易于访问。可以从所有Web浏览器及各种个人和企业设备访问Web应用程序。位于不同地点的团队可以通过基于订阅的Web应用程序访问共享文档、内容管理系统和其他业务服务。
• (2)开发高效。具体而言，Web应用程序的开发过程相对简单，且对企业而言具有成本效益。小型团队可以实现较短的开发周期，使Web应用程序成为一种构建计算机程序的高效且经济的方法。此外，由于同一版本适用于所有现代浏览器和设备，因此开发人员无须为多个平台创建多个不同的迭代。
• (3)使用简单。Web应用程序无须用户下载，易于访问，同时使得最终用户无须进行维护和担心硬盘驱动器的容量问题。Web应用程序可自动进行软件和安全更新，这意味着它们始终是最新版本，并且面临的安全漏洞风险更低。
• (4)扩展性强。使用Web应用程序的企业可以在需要时添加用户，而无须配备额外的基础设施或昂贵的硬件。此外，绝大多数Web应用程序数据都存储在云中，这意味着企业无须投资于本地服务器或数据库。

Web应用特征

Web应用程序具有以下特征。

• 1.云托管和可扩展性： 由于低内存、高吞吐量的特点，Web应用程序占用空间更小，因此在相同硬件上可托管更多此类应用。更高的高吞吐量意味着，通过相同硬件上的一个应用，Web应用系统可服务更多客户，进而降低服务器和托管基础设施所需的投入。
• 2.跨平台： 大部分新式Web应用具有跨平台性，可在Linux、macOS以及Windows系统上运行。
• 3.自动化测试： Web应用自动化测试是一种高效、准确、可重复的测试方法，可以帮助开发人员和测试人员快速发现和解决Web应用程序中的缺陷和问题，同时也可以提高测试效率、降低测试成本、缩短测试周期。
• 4.支持传统应用和SPA 传统Web应用程序涉及极少的客户端行为，而是依赖服务器执行该应用可能需要执行的所有导航、查询和更新。用户执行的每个新操作会被转换为新的Web请求，其结果是最终用户浏览器中的完整页面重载。与之相反，单页应用程序(SPA)涉及极少动态生成的服务器端页面负载。许多SPA在一个静态HTML文件中进行初始化，此文件加载该应用启动和运行所需的JavaScript库。这些应用大量使用Web API处理数据需求，并提供更为丰富的用户体验。
• 5.简单的开发和部署： 整体应用程序通常部署到单个终结点。可轻松将部署自动化，作为持续集成(CI)和持续交付(CD)管道的一部分。

Web应用架构设计

Web应用架构设计原则

以下为Web应用架构的通用设计原则。

• 分离关注点。
• 封装
• 依赖关系反转
• 显示依赖关系
• 单一责任
• 避免自我重复
• 持久性无知
• 有界上下文

Web应用架构分类

Web应用程序的体系结构可以根据软件开发和部署模式分为不同的类别。

整体式架构

整体式架构是一种传统的软件开发模型(也称为Web开发架构)，其中整个软件作为一段代码开发，运用传统的瀑布模型。

这意味着所有组件都是相互依赖和互连的，并且每个组件都需要运行应用程序。若要更改或更新特定功能，需要重写并编译整个代码。

微服务架构

在微服务架构中，代码被开发为松散耦合的独立服务，通过 RESTfulAPI 进行通信。每个微服务都包含自己的数据库并运行特定的业务逻辑，这意味着您可以轻松开发和部署独立的服务。

无服务器架构

无服务器架构是开发软件应用程序的模型。在此结构中，底层基础结构的预配由基础结构服务提供商管理。

这意味着用户只需为正在使用的基础架构付费，而无须为空闲CPU时间或未使用的空间付费。无服务器计算降低了成本，因为资源仅在应用程序执行时被使用。

扩展任务由云提供商处理。此外，后端代码得到简化。它减少了开发工作和成本，并加快了上市时间。

Web应用架构模式

B/S架构

B/S架构的全称为Browser/Server，即浏览器/服务器结构。

Browser指的是Web浏览器，极少数事务逻辑在前端实现，主要事务逻辑在服务器端实现。B/S架构的系统无须特别安装，只需要有Web浏览器即可。

该体系结构基于请求-响应模型。客户端将请求发送到服务器以获取信息，服务器对此进行响应。

P2P架构

P2P架构是一种网络，是两个或多个客户端不经过服务器而直接通信的架构。可能首先会使用服务器，以让客户端间査找到对方，但在此之后就不再需要服务器了。

具体分两种不同的形式：一种是完整连接拓扑架构，指的是每个客户端与其他客户端之间都必须有连接，信息可以直接在用户间交换；另一种是环形拓扑架构，指的是信息只有通过一个或多个客户端才能传递的架构。

P2P 架构中的所有计算机都具有相同的权限。因此，即使某些计算机/节点出现故障，网络和通信仍然处于正常运 行状态。

P2P 的基本架构如图所示

MVC/MVP 架构

MVC(Model-View-Controller)体系结构是一种软件体系结构模式，其中应用程序逻辑根据功能分为三个组件。这些组件称为:模型(model)，表示数据在数据库中的存储方式;视图(view)，用户可见的组件，例如输出或GUI;控制器(controller)，充当模型和视图之间接口的组件。

MVC体系结构不仅用于桌面应用程序，还用于移动和Web应用程序。

微服务架构

微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务依据业务功能设计，以全自动的方式部署，与其他服务使用HTTPAPI通信。同时服务会使用最小规模的集中管理(如Docker)能力，服务可以用不同的编程语言与数据库等组件实现。

微服务架构区别于传统的单体软件架构，是一种为了适应当前互联网后台服务的三高需求:高并发、高性能、高可用而产生的软件架构。

与微服务相对的另一个概念是传统的单体式应用程序，其内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性，彼此相互依赖，很难拆分和扩容。

在微服务架构中，不同的功能/任务被拆分为单独的模块/代码库，这些模块/代码库相互协同工作，形成一个整体的大型服务。

微服务的架构如图16-6所示。

微服务架构的缺点及其解决方案

微服务把单体应用拆分成很多小的分布式服务，不可避免地会存在服务管理问题。为了克服微服务架构存在的缺点，一些技术概念相继被提出。

1. 服务发现和注册 微服务之间相互调用完成整体业务功能，如何在众多微服务中找到正确的目标服务地址，这就是所谓服务发现功能。常用的做法是服务提供方启动时把本服务的地址上报给服务注册中心， 这就是服务注册。服务调用方订阅服务变更通知，动态接收服务注册中心推送的服务地址列表。
2. 服务监控 大型微服务架构的服务运维是一大挑战。服务运维人员需要实时掌握服务运行中的各种状态，一般需要控制面板监测服务的内存使用率、调用次数、健康状况等信息。这就需要系统有一套完备的服务监控体系等。
3. 服务容错 任何服务都不能保证100%不出问题，生产环境复杂多变，服务运行过程中不可避免地会发生各种故障(宕机、过载等)，工程师能够做的是在故障发生时尽可能降低影响范围、尽快恢复正常服务，因此需要引入熔断、隔离、限流和降级、超时机制等服务容错机制来保证服务持续可用性。

Web应用开发框架

开发框架简介

Java EE开发框架

.NET开发框架

Web层开发框架

Web 应用系统开发

Web应用系统通信协议

Web上计算机之间通过特定的通信协议完成通信。通信协议是网络上所有设备(如Web服务器、计算机及交换机、路由器、防火墙等)之间通信规则的集合，规定了通信时信息必须采用的格式及其含义。

Web应用通信协议是Web应用开发的基础，常用的Web应用通信协议有HTTP、MIME、RTP/RSTP 和 MMS 等.

Web应用系统数据存储

缓存系统

缓存系统是一种本地数据存储，有助于快速访问应用程序服务器的数据，而不是每次都联系数据库。

在传统设置中，数据存储在数据库中。当用户发出请求时，应用服务器会从数据库中请求该数据并将其呈现给用户。当再次请求相同的数据时，服务器应再次执行重复且耗时的相同过程。通过将此信息存储在临时缓存中，应用可以快速向用户呈现数据。

云存储

简单来说，云存储就是将存储资源放到云上供使用者存取的一种新兴方案。使用者可以在任何时间、任何地方，通过任何可连网的装置连接到云上方便地存取数据。

CDN

内容交付网络(CDN)是安装在各个地理位置的服务器网络，用于更快、更好地向用户交付内容。用户的请求不是联系中央服务器，而是路由到存储内容的缓存版本的CDN服务器。

因此，站点速度和性能得到提高，数据包丢失减少，服务器负载减少。它还支持受众细分和高级Web安全性。

负载均衡器

负载均衡器是一种服务，它根据可用性或预定义策略将流量负载分布在不同的服务器之间来平衡流量负载。

当负载均衡器中收到用户请求时，它会根据可用性和可伸缩性检索服务器的运行状况，并将请求路由到最佳服务器。

负载均衡器可以是硬件组件，也可以是软件程序。负载均衡可以通过如下两种方式完成:

• TCP/IP级别负载均衡，基于DNS的负载均衡。
• 应用级负载均衡，基于应用负载的负载均衡。

消息队列

消息队列是一个缓冲区，它异步存储消息，并促进Web应用程序中不同服务之间的通信。

在当今的微服务环境中，软件是在更小、模块化和独立的构建块中开发的，这些构建块使用RESTful API相互通信。这些块之间的通信是使用消息队列协调的。

软件组件连接到这些消息队列的末端，以发送和接收消息并处理它们。消息队列提供精细的可伸缩性，简化解耦过程并提高可靠性和性能。

Web应用系统客户端技术

Web客户端的主要任务是通过浏览器来展现页面内容并实现与用户的交互，HTML是信息展现的有效载体。

为了提高客户端的功能性，出现了脚本、DOM等概念;为了提高开发人员对信息展现格式的控制能力，出现了CSS等技术。

常用的客户端开发技术主要有HTML、CSS等基本开发技术，客户端脚本、DHTML、DOM等主要开发技术和ActiveX、Applet等扩充开发技术，其开发的代码在客户端(主要是浏览器)中执行。

Web客户端开发的主要任务是设计与开发Web应用的Web页面，通过设计格式、布局以实现数据的展现和用户交互。

Web应用系统服务端技术

Web服务器端的开发技术也是由静态向动态逐步发展完善起来的。

Web服务器端开发的代码在服务器(Web服务器及扩展环境)端执行，主要有CGI、ISAPINSAPI等基本开发技术，PHP、ASP、ASP.NET、JSP 等高级开发技术和基于后台数据库的 ODBC、ADO、JDBC等数据库连接技术。

每种技术都有其特点，开发人员要根据需求和具体情况来决定使用哪种系统环境和开发技术。这些技术的主要任务是设计与开发应用程序，在处理用户交互的基础上实现既定的需求，为客户端提供动态生成的数据，实现数据源之间的交互与管理。

Web应用系统部署

Web应用的部署是把已经构建完成的Web应用发布到服务器上，通过对Web应用的运行环境进行配置，使得用户可以通过Internet访问该Web应用。

Web应用的部署一般包括打包、发布和评估。

Web应用系统测试

Web应用测试概述

Web应用测试是保障Web应用高可靠性和高可用性的必要手段，随着需求量与应用领域的不断扩大，对Web应用的正确性、有效性、可用性和对Web服务器等方面都提出了越来越高的要求，因此如何对Web应用进行有效的、系统的测试已经成为了Web应用开发的重要工作之一。

Web应用测试不但需要检查和验证Web应用是否按照设计的要求运行，而且还要测试Web应用在不同客户端的浏览器上运行是否正确、显示是否合适、Web应用是否符合用户的使用习惯、Web应用是否能够满足并发量的要求等内容。更重要的是，还要从最终用户的角度进行安全性和可用性等方面的测试。

Web应用测试过程

Web应用测试更多采用敏捷开发方法。敏捷方法中单元测试用例由开发人员完成，其他测试工作由非开发人员完成。这就要求开发人员和测试人员之间需要有效的沟通和协调、相互理解，一旦有功能出现变化，这种变化可以立即被发现。

Web应用功能测试

功能测试在整个测试过程中起着至关重要的作用，它结合Web应用规格说明的要求，保证Web应用在功能上能够达到预期的目标。只有满足功能需求的Web应用才可能是客户需要的，一个不满足功能要求的Web应用可以说是无用的Web应用。

根据测试内容的不同，功能测试主要可以分为链接测试、表单测试、数据校验、Cookie测试和数据库测试。

Web应用性能测试

Web应用性能测试主要可以划分为速度测试、负载测试、压力测试、强度测试、并发测试、大数据量测试、配置测试和可靠性测试等。

Web应用安全性测试

Web应用安全性测试是对整个Web应用的安全防卫措施的有效性进行测试，以揭露安全机制中的漏洞。通常的安全机制包括信息访问控制、用户身份校验以及对机密信息进行加密等，同时要能根据用户的访问情况判断出该用户是正常的用户还是蓄意的破坏者。

Web应用的安全性测试主要包括数据加密测试、用户身份验证测试、日志文件测试、脚本测试、Session测试、备份与恢复测试等。

Web服务测试

Web服务测试特性

与传统软件测试相比，由于Web服务自身的特性，使其测试也具有不同特性。如图所示。

Web服务测试内容

Web服务测试可分为三个层次:

• Web服务基础设施的验证与确认
• Web服务独立测试
• Web服务集成测试。