企业级应用架构设计探索

来源:用户上传      作者:刘鑫璐

　　摘要：随着大型金融企业信息化建设的不断推广，信息化水平不断提升，客户及内部各部门对lT的需求也持续增加，核心应用系统承载的访问量及交易量日益增加，合理、高效的应用系统架构显得尤为重要。采用分层设计理念，将四个逻辑层分别架构和选型设计并给出实际部署方案，形成了企业级高可用应用系统架构解决方案，从而达到加强系统的健壮性，减少重复性的错误的效果，为应用研发设计、测试管理、运维管理等提供参考。
　　关键词：应用;架构设计;高可用性;运维;IT选型
　　中图分类号：TP311 文献标识码：A
　　文章编号：1009-3044（2020）05-0074-04
　　开放科学（资源服务）标识码（OSID）：
　　1 背景
　　应用系统构架是对已确定的需求的技术实现构架、做好规划，运用成套、完整的工具，在规划的步骤下去完成任务。应用系统架构是应用系统设计的核心，也是应用系统的“灵魂”。应用系统上线后运行稳定安全与否，取决于构建之初的架构选型和设计，常常有“一年之计在于春，系统之初在于架构”的说法。
　　当今技术的发展日新月异，大型金融企业中的应用系统设计逐渐更新优化，逐渐演变为集群化、模板化的标准架构。大型金融企业盈利能力依靠的是优秀的产品和服务、及时准确的信息，而科技是提供创造、获取、分析、管理信息的手段，因此必须保证信息的安全性、可靠性、准确性、及时性。为应对挑战，科技部门应相互合作、同心协力，不断提升信息服务水平，着重从基础架构和系统运维两个维度对开放平台基础架构、产品和服务进行深入分析，并总结了多年来的经验，形成了现有大型金融企业的企业级高可用应用系统架构解决方案。
　　2 典型架构
　　结合大型金融企业信息系统的技术特点和业务需求，推荐典型的高可用基础架构模式如下。
　　2.1 总体架构
　　大型金融企业应用系统架构包含接入层、应用层、数据库层及存储层四个逻辑次，如图1所示。
　　接入层接收前端访问请求，并分发至应用层进行处理。对于日均联机交易量百万级以上的系统，建议采用硬件负载均衡设备实现用户访问接入，软件负载均衡产品通常用于并发数低于200的业务场景，硬件负载均衡设备则能够承担更大并发数及负载压力的业务场景，并且可根据需求进行横向扩展。
　　应用层负责应用程序的部署和运行，实现业务处理逻辑。应用层通常集群化部署，每台应用服务器“镜像”化自己，于是一组系统配置相同、应用部署相同的服务器构成应用处理组合，实现业务逻辑，并根据需求进行横向和纵向扩充。
　　数据库层负责提供数据管理服务，数据管理一般采用成熟的厂商产品，处理联机事务和联机分析事务，对于数据量、业务量较大的系统，采用具有一定容错能力的数据库集群，各个节点相互协同，同时对外提供服务，大幅提高了数据库的可用性;对于数据量、业务量不大的系统，无须使用Multiplex集群，采用传统的HA技术构建一个Active-Standby模式的集群就能满足需求。对于同时具有联机事务处理和联机分析处理需求的应用，可结合实际情况采用混合架构模式，对于混合架构而言，需要应用具有相应时间窗口进行数据库之间的数据同步。
　　存储层的高可用模式分为三个层面，一是利用存储设备自身提供的磁盘冗余机制保障存储设备的高可用性，二是利用操作系统逻辑卷管理（LVM，Logical Volume Manager）工具实现对两台存储设备的同步读写，三是利用系统关联机时间对上述两台存储设备分别进行存储级镜像，将数据备份到第三台甚至第四台存储设备上，以此保障存储层面的高可用及数据安全。
　　2.2 接入层
　　系统接人层作为业务系统的直接访问入口，一般采用负载均衡技术，分为软件负载均衡和硬件负载均衡两种方式。
　　通常，软件负载均衡方式适用于并发访问数较低、负载压力较小且高可用性要求相对较低的应用场景（日均业务量百万以内），优势是部署方便、成本较低，缺点是架构难以扩展、可靠性较低。硬件负载均衡方式具有承担更高负载和更多并发访问的能力，同时架构灵活，具有很强的伸缩性[1]。
　　硬件负载均衡方式已成为系统接入层的首要选择。下面重点介绍由硬件负载均衡构成的三类集群。
　　2.2.1 高可用集群架构
　　当应用的并发访问压力在一台负载均衡设备的承载能力以内时，对于系统接入层，我们可采用高可用集群架构，即利用双机容错技术将两台负载均衡设备组成“一主一备”的集群以保障系统接入层的高可用性，单台设备发生故障，可以实现毫秒级的主备切换，对用户体验几乎透明。目前大型金融企业多数开放式系统的接入层均采用这种架构，如图2所示。
　　2.2.2 多级负载均衡集群架構
　　当应用的并发访问压力超过一台负载均衡设备的承载能力时，就需要进行横向扩展，比如网上银行系统，利用多台设备搭建一个多级负载均衡集群，如图3所示，第一级由处于主备模式的两台链路负载均衡设备（简称LC）构成，实现对下一级应用负载均衡集群进行链路层的负载、分发;第二级根据业务压力选用多台应用负载均衡（简称LTM）对后端的应用服务器集群进行负载、分发，集群中每个节点的地位相同，共同承担用户访问请求，当一个或多个节点失效时不会影响系统接人层的可用性。
　　2.2.3 基于客户端的高可用应用系统架构
　　对于客户端/服务器（c/s）架构的应用系统，可通过客户端的可用性设计提高系统的整体可用性，而不需采用统一接入的集群式架构，由客户端来选择连接的应用服务器，当其中一套不可用时，客户端主动地选择其他正常工作的应用系统，依次保证系统的高可用，其中对于数据更新不敏感或者数据实时同步要求不高的系统，后端数据库也可部署多套，数据采取定期同步方式，如Notes邮件系统、QQ等均采用了该模式。由于各应用系统完全对等，且对数据更新不敏感，因此可根据访问量需求进行动态弹性扩展，此类架构具有一定的约束条件，但具有很好的可用性和可扩展能力，对基础架构和资源投入相对也要求较低。 　　2.3 应用层
　　从大型金融企业开放平台技术使用现状及未来发展规划来看，J2EE是使用最广泛、最主要的应用开发技术架构，是企业级应用开放的首选技术方案，未来仍将保持这一势头;它广泛应用于B/S架构领域，具有较好的可用性、安全性、可靠性和可伸缩性[2]。
　　对于大型金融企业用户来讲，更看重系统运行的稳定和产品可维护性，商业化中间件产品是设计稳定系统的必备条件。在成熟产品中，IBM Websphere提供了优秀的处理性能和实践经验，在各大银行核心系统中使用普遍。
　　Websphere应用服务器集群（简称WAS集群）由一组应用服务器组成，每个服务器上部署了同样的应用程序。通过集群可以实现可扩展性（服务更多客户，提高吞吐量），负载均衡（平衡负载资源，使资源得以有效利用），高可用性（提供故障恢复和补偿机制，在关键性业务中提供容错功能）。WAS集群可横向和纵向扩展，横向扩展通过增加相同配置的服务器实现，纵向扩展通过调整单台服务器上的CPU、内存和磁盘空间实现，从而可以根据不同需求实现业务性能补给。
　　图4是Websphere集群体系结构，包括DM（DeploymentManager）节点、Node节点、App Server节点以及负载均衡节点。DM是协调节点，负责配置分发和节点信息同步管理;Node接收DM同步的信息，为APP Server提供管理容器;App Server是实现业务逻辑的应用组件，是J2EE程序运行的载体;负载均衡节点是前端接入的统一调度，负责分发请求到App Server，在维护App Server时可以按照需求渐入渐出，为维护App Server提供便利。
　　2.4 数据库层
　　数据库服务器层是应用系统最为核心的部分，也是应用设计需要重点关注的环节。本节将从业务类型和数据部署等维度描述数据库服务器层的典型架构。
　　数据处理大致主要分为联机事务处理（OLTP）和联机分析处理（OIAP），大型金融企业中两种处理类型并存且各自支撑相应业务场景。
　　2.4.1 联机事务处理（OLTP）
　　联机事务处理是传统关系数据库的主要应用，主要是基本的、日常的事务处理，其主要特征包括：1）并发用户数量大;2）用户要求响应时间短;3）事务操作的数据量小，增删改频繁等。OLTP系统通常要求数据的强一致性。
　　当业务场景以联机事务处理为主时，Oracle RAC已成为成熟的解决方案[3]，部署架构详见图5。
　　2.4.2 联机分析处理（OLAP）
　　联机分析处理是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持。其主要特点包括：1）并发用户数较低;2）单次操作的数据量较大;3）复杂查询操作较多，修改、删除等操作通常采用批量的方式等。OLAP系统不要求数据的强一致性，最终一致性即可。
　　当业务场景以联机分析处理为主时，若业务量和数据量不大的系统，建议采用HA或者冷备架构即可，如数据分析型系统;若业务量和数据量较大，建议采用HBASE作为解决方案。HBASE是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBASE技术可在廉价PC Server上搭建起大规模结构化存储集群[4]。HBASE可以实现海量数据分析处理和存储，通常与Hadoop结合一起使用，在非实时交易处理场景中应用广泛，部署架构详见图6。
　　2.5 存储层
　　开放平台目前主要使用的存储分为SAN和NAS两类，其用途简要介绍如下：
　　SAN存储由于其在读写速度、冗余性、安全性等方面的优势，一般用于各类数据库的数据设备或者对实时响应要求非常高、稳定性要求高的文件系统。SAN存储的数据复制技术包括快照、存储内镜像、存储间镜像、异地灾备等，根据系统的实际需要，采取不同的数据复制技术进行备份[5]。
　　NAS存储由于其能提供独立的文件系统服务，一般用于共享环境下、数据量较大但对实时响应要求不高的环境。
　　兩者区别如下：
　　1）扩展性：NAS和SAN都具有良好的扩展性，便于扩展。
　　2）服务方式：NAS提供文件级的数据访问、存储服务;而SAN提供块级数据访问、存储服务。
　　3）文件系统所在位置：NAS的文件系统集成在NAS设备上;而SAN的文件系统集成在主机侧。
　　4）性能：NAS与业务应用共享网络，占用LAN网络带宽资源，即影响业务，NAS自身的传输能力也受到限制;而SAN采用专用的存储网络，不占用LAN的带宽资源，提供传输性能，但是成本相对来高。
　　3 结束语
　　本文结合大型金融企业应用系统设计实践和经验，从系统接入层、应用服务器层、数据库服务器层和存储层四个逻辑层论述了企业级应用架构设计标准和选型，并给出相应的设计模式和部署方案，为应用研发设计、测试管理、运维管理等提供参考和依据。
　　业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。本文提到的应用架构设计主要针对大型金融行业企业制定，考虑到业务交易成熟度、交易量和故障容忍程度，选型过程中均采用较为成熟的商业级产品作为模板，如Oracle、Websphere，其他类型企业也可考虑使用部分开源软件和低成本产品代替，但需结合本文架构设计中要求做好调研评估和统筹规划。
　　随着科技不断发展，系统架构与设计也跟随技术的发展不断升级和改进，只有牢牢抓住基本设计原则和设计规范，才能顺应科技时代的要求，设计出安全、稳定、健壮的应用系统，提高生产运维工作效率。
　　参考文献：
　　[1]龙佳琴.负载均衡技术在企业中的应用研究[J].计算机光盘软件与应用，2014（6）：97-100.
　　[2]朱彬.企业级应用软件架构模式的研究和应用[D].沈阳：沈阳工业大学，2004.
　　[3]左奇.银行核心系统分布式数据库技术架构探讨[J].中国金融电脑，2019，358（5）：81-82.
　　[4]唐长城，杨峰，代栋，等.一种基于HBase的数据持久性和可用性研究[Jl.计算机系统应用，2013，22（10）：175-180.
　　[5]李斯伟.基于IP的SAN存储技术研究[J].电讯技术，2004，44（3）：132-135.
　　【通联编辑：谢媛媛】
转载注明来源:https://www.xzbu.com/8/view-15180453.htm