[架构之路-117]-《软考-系统架构设计师》-软架构设计-10-应用程序架构与基于Web的架构设计负载均衡技术

Posted 2023-03-04 文火冰糖的硅基工坊

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了[架构之路-117]-《软考-系统架构设计师》-软架构设计-10-应用程序架构与基于Web的架构设计负载均衡技术相关的知识，希望对你有一定的参考价值。

前言：

第10节应用程序架构与Web架构设计

10.1 应用架构

应用架构（Application Architecture）是描述了IT系统功能和技术实现的内容。

应用架构分为以下两个不同的层次：

企业级的应用程序架构：企业层面的应用架构起到了统一规划、承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。在企业架构中，应用架构是最重要和工作量最大的部分，他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。

单个系统的应用程序架构：在开发或设计单一IT系统时，设计系统的主要模块和功能点，系统技术实现是从前端展示到业务处理逻辑，到后台数据是如何架构的。这方面的工作一般属于项目组，而不是企业架构的范畴，不过各个系统的架构设计需要遵循企业总体应用架构原则。

应用架构主要以架构图的方式描述系统的组成和框架，一般从系统功能和系统技术层次两个架构视角进行设计：

备注：

基站软件：L1/L2/L3/OAM模块，本质上是应用程序！！！它们的架构，归属于应用程序架构！！！，应用程序解决的业务。

基站软件：硬件抽象层和操作系统抽象层，本质上是中间件程序，他们的架构，归属于中间件架构！！！，中间件解决的服务。

基站软件：Linxu OS和TCP/IP协议栈，本质上是系统软件，它们的架构，归属于系统软件架构！！！，系统软件解决的资源（CPU/内存）

基站硬件：SOC, DSP, FPGA, Switch等，本质上是硬件，他们的架构，归属于硬件架构！！！

硬件、Linux OS、TCP/IP、中间件、应用程序共同组成了一个系统，它们的架构，归属于基站系统架构。

基站、RRH、核心网、internet网，组成了一个更大的系统, 5G系统，它们的架构，归属于5G系统架构！！！

10.2 J2EE:企业分布式多层应用程序架构

10.2.1 概述

J2EE的全称是Java 2 Platform Enterprise Edition，它是由SUN公司领导、各厂家共同制定的工业标准，或者说，它是在SUN公司领导下，多家公司参与共同制定的企业级分布式应用程序开发规范。J2EE是市场上主流的企业级分布式应用平台的解决方案 [1] 。

J2EE本身是一个标准，而不是一个现成的产品（虽然现在有很多符合J2EE标准的产品），它由以下几个部分组成：

（1）J2EE规范。该规范定义了J2EE平台的体系结构、平台角色及J2EE中每种服务和核心API的实现要求。它是J2EE应用服务器开发商的大纲。

（2）J2EE兼容性测试站点。Sun公司提供的一个测试J2EE应用服务器是否符合J2EE规范的站点，对通过该站点测试的产品，Sun公司将发放兼容性证书。

（3）J2EE参考实现。即J2EESDK，它既是Sun公司自己对J2EE规范的一个非商业性实现，又是为开发基于J2EE企业级应用系统原型提供的一个免费的底层开发环境。

（4）J2EE实施指南。即BluePrints文档，该文档通过实例来指导开发人员如何去开发一个基于J2EE的多层企业应用系统 [2] 。

10.2.2 四层体系架构

J2EE的体系结构可以分为四层，如图1：J2EE体系结构图所示。

·客户端层：负责与用户直接交互，J2EE支持多种客户端，所以客户端既可以是WEB浏览器，也可以是专用的Java客户端。

·服务器端组件层（前端）：本层是为了基于WEB的应用服务的，利用J2EE中的JSP与Java Servlet技术，可以响应客户端的请求，并向后访问封装有商业逻辑的组件。

·EJB层（后端）：本层主要封装了商务或业务逻辑，完全企业计算机，提供了事务处理，负载均衡、安全、资源连接等各种基本服务，程序在编写EJB时可以不关心这些基本的服务，集中注意力于商务逻辑的实现。

·企业信息系统层（数据层）：企业信息系统层包括了企业的现有系统（包括数据库系统、文件系统），J2EE提供了多种技术以访问这些系统，如JDBC访问DBMS。

在J2EE规范中，J2EE平台包括有一整套的服务、应用编程接口和协议，可用于开发一般的多层应用和基于WEB的多层应用，是J2EE的核心和基础。它还提供了EJB、Java Servlets API、JSP和XML技术的全面支持等。

10.2.3 组成组件

J2EE应用程序是由组件构成的。J2EE组件是具有独立功能的软件单元，它们通过相关的类和文件组装成J2EE应用程序，并与其他组件交互。J2EE规范中定义了下列J2EE组件：

（1）客户层组件，包括客户端应用程序和Applets；

（2）Web层组件，包括Java Servlet和Java Server Pages（JSP）；

（3）业务层组件，即Enterprise JavaBeans（EJB）。

1.客户层组件

J2EE应用程序可以是基于Web方式的，也可以是基于传统方式的。

Web层组件：J2EE Web层组件可以是JSP页面或Servlets。根据J2EE规范，静态的 html页面和Applets都不是Web层组件。Web层可能包含某些JavaBean对象来处理用户输入，并把输入发送给运行在业务层上的enterprise bean来进行处理。

2.业务层组件

业务层的代码逻辑用来满足银行、零售、金融等特殊商务领域的需要，由运行在业务层上的enterprise bean进行处理。

有三种企业级的bean：会话（session）beans、实体（entity）beans和消息驱动（message-driven）beans。会话bean表示与客户端程序的临时交互，当客户端程序执行完毕，会话bean和相关数据就会消失。相反，实体bean表示数据库表中一行永久的记录，当客户端程序中止或服务器关闭时，就会有潜在的系统服务保证实体bean的数据得以保存。消息驱动bean结合了会话bean和JMS的消息监听器的特性，允许一个业务层组件异步接收JMS消息。

3.企业信息系统层

企业信息系统层处理企业信息系统软件，包括企业基础建设系统，如企业资源计划（ERP）、大型机事务处理、数据库系统和其他的遗留信息系统等。例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统 [4] 。

10.3 Web架构设计

10.3.1 Web架构设计的知识体系

Web架构设计，是当前互联网的主要架构之一，它涉及到面非常广：

10.3.2 数据库与Web业务处理的分离：数据库集群

数据库与Web服务器业务处理分离的原因如下：

（1）随着业务量和用户数量的增加，单台机器的处理能力（CPU）成为了瓶颈。

（2）随着业务量和用户数量的增加，数据库访问（并发）成为了瓶颈。

（3）随着业务量和用户数量的增加，数据库的容量（内存）成为了瓶颈。

10.3.3 Web业务处理与数据库的分离：应用集群

应用集群的基本思想：

三个臭皮匠，顶一个诸葛亮（N个二流的开发人员 > 一个超牛人员）

考团队的力量，而不是靠个人英雄主义

分布式替代集中式

量变引起质变

Web服务器业务处理与数据库分离的原因如下：

（1）随着业务量和用户数量的增加，单台机器的处理能力（CPU）成为了瓶颈。

（2）随着业务量和用户数量的增加，业务处理能力（并发）成为了瓶颈。

10.3.4 负载均衡技术

由于目前现有网络的各个核心部分随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性的技术就是负载均衡（Load Balance）。

一个能够提供高并发访问，快速响应的服务器集群不是一开始就能设计出来的，但对于软件架构师而言，在架构设计之初就要有应付这种高并发，为集群提供水平扩展的计划，具体何时进行扩展，就需要在后续处理业务的过程中慢慢演化了。同时，在设计之初，为了能快速扩展而不影响集群的正常使用，建议把服务器设计成无状态的，也就是集群服务器不存储请求上下文信息，这样用户的请求被发往集群中的任何一个节点所处理的返回结果都将是一样的。因此在集群中就可以使用负载均衡技术将不同的请求发往不同的节点上进行处理。如下图：

负载均衡服务器需要能够感知或者可以配置集群中的服务器数量，可以及时发现集群中新上线或者下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，这样就实现了服务器集群的伸缩性。负载均衡的实现技术有多种多样，从硬件实现到软件实现，从商业产品到开源产品，应有尽有。

（1）HTTP重定向（服务器在公网中）

本文主要介绍Web服务器中HTTP反向代理机制，以此来达到服务器之间的负载均衡。

利用HTTP重定向协议实现负载均衡大概工作原理如下图：

HTTP重定向服务器是一台普通的应用服务器，其唯一个功能就是根据用户的HTTP请求计算出一台真实的服务器地址，并将该服务器地址写入HTTP重定向响应中（重定向响应状态码为302）返回给用户浏览器。

用户浏览器在获取到响应之后，根据返回的信息，重新发送一个请求到真实的服务器上。如上图所示，浏览器访问www.apusapp.com，DNS服务器解析到IP地址为114.100.20.200，即HTTP重定向服务器的IP地址。重定向服务器计根据某种负载均衡算法算出真实的服务器地址为114.100.20.203并返回给用户浏览器，用户浏览器得到返回后重新对114.100.20.203发起了请求，最后完成访问。

这种负载均衡方案的有点是比较简单，缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差；同时，重定向服务器本身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP返回码302重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。因此实践中很少使用这种负载均衡方案来部署。

HTTP是应用层的负载均衡，也就是说，即在七层协议的应用层才会收到负载均衡重定向地址的信息。

（2）反向代理（服务器在局部私有网络中，后台服务器对外不可见）

反向代理服务器位于用户与目标服务器之间，但是对于用户而言，反向代理服务器就相当于目标服务器，即用户直接访问反向代理服务器就可以获得目标服务器的资源。同时，用户不需要知道目标服务器的地址，也无须在用户端作任何设定。

反向代理服务器通常可用来作为Web加速，即使用反向代理作为Web服务器的前置机来降低网络和服务器的负载，提高访问效率。

反向代理的工作原理是，代理服务器来接受客户端的网络访问连接请求，然后服务器将请求有策略的转发给网络中实际工作的业务服务器，并将从业务服务器处理的结果，返回给网络上发起连接请求的客户端。

通常的代理服务器，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。由于外部网络上的主机并不会配置并使用这个代理服务器，普通代理服务器也被设计为在Internet上搜寻多个不确定的服务器,而不是针对Internet上多个客户机的请求访问某一个固定的服务器，因此普通的Web代理服务器不支持外部对内部网络的访问请求。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。此时代理服务器对外就表现为一个Web服务器，外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于，这个服务器没有保存任何网页的真实数据，所有的静态网页或者CGI程序，都保存在内部的Web服务器上。因此对反向代理服务器的攻击并不会使得网页信息遭到破坏，这样就增强了Web服务器的安全性。 [3]

反向代理方式与包过滤方式或普通代理方式并无冲突，因此可以在防火墙设备中同时使用这两种方式，其中反向代理用于外部网络访问内部网络时使用，正向代理或包过滤方式用于拒绝其他外部访问方式并提供内部网络对外部网络的访问能力。因此可以结合这些方式提供最佳的安全访问方式。

优点：

1)提高了内部服务器的安全

外部网络用户通过反向代理访向内部服务器，只能看到反向代理服务器的IP地址和端口号，内部服务器对于外部网络来说是完全不可见。而且反向代理服务器上没有保存任何的信息资源，所有的网页程序都保存在内部服务器上，对反向代理服务器的攻击并不能使真的网页信息系统受到破坏，这样就提高了内部服务器的安全性。

2)加快了对内部服务器的访问速度

在内部服务器前放置两台反向代理服务器，分别连接到教育网和公网，这样公网用户就可以直接通过公网线路访问学校服务器，从而避开了公网和教育网之间拥挤的链路。同时反向代理服务器的缓存功能也加快了用户的访问速度。 [4]

3)节约了有限的IP资源

校园网内部服务器除使用教育网地址外，也会采用公网的IP地址对外提供服务，公网分配的IP地址数目是有限的，如果每个服务器有分配-个公网地址，那是不可能的，通过反向代理技术很好的解决了IP地址不足的问题。

（3）DNS域名解析负载均衡

DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。

最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。

DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。

（4）NAT负载均衡

随着访问量的上升，当一台服务器难以胜任时，就必须采用负载均衡技术，将大量的访问合理地分配至多台服务器上。实现负载均衡的手段有许多种，比如可以采用服务器群集负载均衡、交换机负载均衡、DNS解析负载均衡等等。除此以外，也可以通过地址转换方式实现服务器的负载均衡。事实上，这些负载均衡的实现大多是采用轮询方式实现的，使每台服务器都拥有平等的被访问机会。

NAT（Network Address Translation 网络地址转换）简单地说就是将一个IP地址转换为另一个IP地址，一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。

当外网主机访问服务器的内部全局地址202.68.10.10时，路由器会采用轮询（Round Robin）方式在4台服务器之间分发会话，即1-4个报文的目的地址会被替换为服务器1-4的内网地址。地址替换对于外网主机是透明，外网主机只知道与202.68.10.10在通信，无法知道内网的网络拓扑结构。基于NAT的负载均衡可以减轻单台服务器提供服务器的压力，但是由于NAT路由器无法感知服务器的故障，如果其中某一台服务器出现故障，路由器仍然会将数据转发到该服务器，会造成去往服务器集群的流量出现路由黑洞。

（5）F5负载均衡

F5 lnc(纳斯达克：FFIV) ，全球领先的应用交付网络（Application Delivery Networking，ADN）领域的厂商，创建于1996年，总部位于美国西雅图市，F5为全球大型企业、运营商、政府与消费品牌提供更加快速、安全以及智能的应用，通过交付云与安全解决方案，F5帮助企业在不损失速度与管理性的同时享有它们所需的应用架构。

F5提供业界领先的成套集成产品和服务。F5的产品能够消除带宽拥塞，并提高关键任务互联网服务器和应用系统的可用性和速度，其中包括Web发布、内容提供、电子商务、高速缓存、防火墙等。F5的解决方案能够为服务提供商、企业和电子商务公司智能化地自动提供最佳的互联网性能、可用性和内容发布。F5的解决方案广泛部署于全球范围的大型企业、领先的服务供应商、金融机构、政府机构、卫生保健领域和门户网站中。

解决方案

F5解决方案关键词

应用交付网络（ADN）、服务器负载均衡、链路负载均衡、多站点负载均衡、WEB加速及应用安全、本地流量管理、灾难备份、广域网传输优化、SSL VPN、ISP互访互通、远程安全接入/访问、文件存储虚拟化、多链路接入、远程安全访问。

（6）nginx

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器 [13] ，同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：Рамблер）开发的，公开版本1.19.6发布于2020年12月15日。 [11]

其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、简单的配置文件和低系统资源的消耗而闻名。2022年01月25日，nginx 1.21.6发布。 [12]

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好。

在连接高并发的情况下，Nginx是Apache服务不错的替代品：Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一。能够支持高达 50,000 个并发连接数的响应，感谢Nginx为我们选择了 epoll and kqueue作为开发模型。

10.3.5 负载均衡算法

目前负载均衡算法主要分为两类：

静态负载均衡算法：以固定的概率分配任务，不考虑服务器的状态信息，如：轮询法、加权轮询法、随机法、加权随机法等。

静态算法的策略和规则是完全确定，不管目标服务器的实际状态。

动态负载均衡算法：以服务器的实时负载状态信息来决定任务的分配，如：最小连接法、加权最小连接数法等。

动态算法的策略和规则是需要根据目标服务器的实际状态进行修正，不会死板，一刀切。是一种实事求是的哲学思想。

（1）轮询（Round Robin）法

轮询法，就是将用户的请求轮流分配给服务器，比如有10台服务器，从第1台开始分配，每次有请求进来，就分配到下一台服务器。这种算法比较简单，具有绝对均衡的优点，但是也正是因为绝对均衡，因此它无法保证分配任务的合理性，无法根据服务器承受能力来分配任务。

结论：轮询法适用于机器性能都在同一水平的服务，一旦某台机器性能不好，极有可能产生木桶效应，性能差的机器扛不住更多的流量。

（2）随机（Random）法

随机法，是随机选择一台服务器来分配任务。它保证了请求的分散性达到了均衡的目的。同时它是没有状态的不需要维持上次的选择状态和均衡因子。但是随着任务量的增大，它的效果趋向轮询后也会具有轮询算法的部分缺点。

结论：同样地，它也不适用于机器性能有差异的分布式系统。

（3）加权轮询（Weight Round Robin）法

实际上，不同的服务器存在着配置和当前系统的负载不相同，因此它们的处理能力也不一样。所以对配置高、负载低的机器分配更高的权重，使其能够处理更多的请求，而配置低、负载高的机器，则给其分配较低的权重，降低其系统负载，加权轮询很好的处理了这一问题，并将请求按照顺序且根据权重分配给服务器。

说明：Nginx默认的负载均衡使用的就是加权轮询法。

例如：集群中共有3台服务器A、B、C，其中A的硬件水平是B的2倍，B的硬件水平是C的3倍，则权重值可以如下划分

（4）加权随机（Weight Random）法

与加权轮询法类似，加权随机法也是根据服务器不同的配置和负载情况来配置不同的权重。不同的是，它是按照权重来随机选择服务器的，而不是顺序。

（5）最小连接数（Least Connections）法

最小连接法，将任务分配给此时具有最小连接数的服务器。

当一台服务器收到一个请求后，它的连接数间1。但是根据连接数并不能真实的反应服务器的负载能力，当服务器不处于同一水平时，有可能连接数少的服务器处理能力差，而连接数多的服务器处理能力强。

结论：最小连接法适用于机器性能都在同一水平的服务。确保某一个时刻，所有的服务器均衡的分摊任务。

（6）源地址哈希法

源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

10.3.6 不同session之间状态上下文的保存与同步

（1）有无状态的分离

（2）通过cookie在不同session之间传递信息

（3）通过redis数据库存放session的上下文状态

（4）数据库读写的分离

为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改业务的生产服务器；第二台数据库服务器，主要进行读的操作。·

在一些大型网站业务场景中，单台数据库服务器所能提供的并发量已经无法满足业务需求，为了满足这种情况，一般而言是通过主从同步的方式来同步数据，在此基础上，通过读写分离来提升数据库的并发和负载能力。

一般而言，业务场景下对数据库的查询操作要远远高于增、删和改，并且读操作对数据库的影响要更小。因此，我们一般会设置一台数据库服务器作为主服务器，主要承担数据的增、删和改的任务，配置3-4台数据库服务器为从服务器，主要承担数据的查询任务。数据库从服务器从数据库主服务器中同步数据，以此实现数据的一致性。

读写分离带来的好处时：大部分的读操作流量可以被分流到不同的读服务器上来支持用户流量的变化。缺点是：需要写服务与所有的读服务器进行数据同步。

读写分离实现方式

根据读写分离实现的层级，读写分离一般有两种方式实现，通过应用程序层实现和通过中间件层实现。

通过应用程序层实现是指在网页内部实现数据查询语言和数据操作语言分别指向不同的mysql主库和从库。通过应用程序层实现的MySQL读写分离图解如下：

这样做的优点是减少了部署的难度，部署安装即用，且性能较好，缺点是当架构拓展时也要修改代码，难以实现自动分库、分表等高级操作，在一些大型应用场景中不是很适用。

通过中间件层实现是指在应用程序层统一将所有的SQL语句指向一个中间件设备，由该中间件设备将不同的SQL语句指向不同的数据库服务器进行操作。通过中间件层实现读写分离图解如下：

支持读写分离常用中间件：常用的读写分离中间件程序有以下种：

1、cobar

阿里B2B开发的关系型分布式系统，是一款早期的中间件，后来因开发者离职而无人维护。

2、MyCAT

技术爱好者在cobar的基础上进行了二次开发，解决了cobar的一些问题，并加入了一些新功能，目前MyCAT社区活跃度较高，也有很多公司在使用MyCAT。

3、OneProxy

Oneproxy是一款商业收费的中间件，由支付宝团队开发，在高并发场景下十分稳定。

4、Vitess

该中间件架构复杂，且使用Vitess需要使用其所提供的API接口。

5、Kingshard

由360团队开发，支持分库分表，但是在高并发情况下稳定性一般。

6、MaxScale和MySQL Route

这两者均为MySQL官方中间件。

Maxscale是Mariadb研发的，MySQL Route是现在Oracle公司为MySQL数据库发布的中间件。

（5）用IO高速缓Cache进一步提升数据库读的时间效率（用内存读替代磁盘读）

（6）内容分发网络

备注：

CDN类似边缘服务器，内容下沉到边缘服务器CDN

10.3.7 网络通信数据传输的数据编码机制

（1）HTTP

超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而 [9] 消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣，因为它使开发和部署非常地直截了当。

（2）XML VS JSON

[架构之路-116]-《软考-系统架构设计师》-软架构设计-9-构件与中间件技术

[架构之路-110]-《软考-系统架构设计师》-软件架构设计-3-架构描述语言ADL与UML

[架构之路-107]-《软考-系统架构设计师》-0-系统分析师与系统架构设计师简介与官网介绍

软考高级系统架构设计师系列论文之：软考高级架构设计师百篇范文