分布式架构在农业银行的应用实践与展望
一般可以将架构分为两类，一类是以垂直扩展（Scale up）为主的架构，如通过增加单机配置，或者将中低端设备升级成为高端设备，用以提升系统的处理能力，称之为集中式架构，早期的哑终端主机架构是典型代表。
（一）分布式架构简介
一般可以将架构分为两类，一类是以垂直扩展（Scale up）为主的架构，如通过增加单机配置，或者将中低端设备升级成为高端设备，用以提升系统的处理能力，称之为集中式架构，早期的哑终端主机架构是典型代表； 一类是以水平扩展（Scale out）为主的架构，通过横向扩充节点，如一个节点扩充到多个节点，每个节点运行独立实例，节点与节点之间通过网络互连，随着节点扩充系统处理能力能够随之提升，单节点失效时，整个集群仍然可以对外提供服务，称之为分布式架构[2]。
2、分布式架构的优缺点 分布式架构按照一定的维度将系统进行拆分，通过一定的负载均衡机制，将业务分摊到多个节点上处理。 这种架构的优点是可以采用更开放的架构，各节点松耦合，对底层产品的可靠性、可用性依赖降低，可以基于廉价的硬件和开源软件构建，受单一厂商的制约较少，可以引入多家厂商竞争，成本更为低廉，可用性、可扩展性更好。 尤其是随着应用规模的扩大，边际成本将更低。 这种架构的难点是要做好各节点的协同工作，尤其是要处理好数据的一致性、完整性问题。 根据CAP理论[3]，在可用性、分区性与一致性三者之间，同时只能满足两个，如果要满足可用性（A）、分区性（P），就需要牺牲一致性（C），业界的一般做法主要是根据业务特点，通过较为复杂的应用设计，放弃实时一致性、保障最终一致性来解决该问题，分布式架构增加了应用设计和研发的复杂度。 此外，随着节点数的增加和分布部署，对运维管理、异常处置也提出了更高的要求。 农业银行在分布式架构上的实践
随着Linux等开源软件日益成熟，X86服务器的可靠性、处理性能快速提升，虚拟化、集群、大数据、高速网络技术得到广泛应用，为构建分布式架构提供了有利条件。 近年来，农业银行在主机和开放领域对分布式架构进行了研究和实践。
（一）主机领域 以新一代核心银行系统建设为契机，农业银行对主机的架构进行了优化。 一是将交易路由层分离出来，实现交易的统一接入和负载均衡调度，减少了对主机的依赖，降低了资源消耗。 二是采用读写分离设计，构建主机开放融合架构，将查询类交易的应用逻辑处理下移到国产X86服务器上，通过DRDA方式访问主机数据库，从试点情况来看，交易下移后可比下移前可节省60%左右的主机计算资源消耗，效果明显。 三是将明细数据下移到开放平台上，基于Hadoop架构实现明细业务查询。 四是将可以下移的业务系统整体下移到开放平台，减少主机资源使用。 （二）开放领域 全国数据大集中之后，农业银行大力推进集群架构、虚拟化技术的应用，采用Linux替代UNIX，用X86服务器替代小型机，引入集群数据库和MPP数据库，探索存储虚拟化应用，构建更加开放的分布式架构，同时加强监管控等运维平台研发，降低分布式架构所带来的运维压力，提升系统运维标准化、自动化水平。 1、农业银行开放平台分布式架构 下图列出了农业银行目前开放平台的典型架构，从应用接入层、应用服务层到数据服务层和存储服务层，均实现了分布式部署。
图1：
农业银行开放平台分布式架构
（1）应用接入层负责前端访问需求的统一接入，以及对后端应用服务器的交易分发和负载均衡。
通过应用接入层实现了前端对后端的透明访问，后端系统可以根据业务量和系统性能按需扩展，弹性部署。
（2）应用服务层负责应用逻辑的处理，以Java和.net平台为主，集群中各节点基于对等结构，运行状态独立，任何一个节点出现问题，能够通过前端负载均衡集群及时判断和隔离，硬件层面全部采用X86服务器，基于计算虚拟化实现资源使用的弹性伸缩。
（
3）数据服务层负责数据的存取服务，按类型总体分为联机事务处理（OLTP）和联机分析处理（OLAP）两个领域。
OLTP领域一般采用成熟的厂商产品，保持2-3家形成一定竞争，降低集中度风险。
对于大业务量的OLTP场景，采用读写分离、联机与批量分离设计，或者按照一定的维度对数据库进行拆分，如网银系统，日均交易量已经达到上亿笔，单数据库处理起来压力非常大，按照客户等维度拆分成多个数据库，实现了数据库的堆叠和横向扩展，单个数据库异常对全局无影响或者影响极为有限。
图2：
分布式数据库架构
随着X86服务器可靠性和处理能力提升，以及集群数据库技术的成熟，农业银行加大了X86服务器在数据库领域的使用力度，2014年，全国集中的信贷系统数据库从高端小型机迁移到国产X86服务器，日均交易量达3000万笔。
在新一代银行卡受理环境系统建设中，全面采用X86服务器构建集群数据库计算环境，根据业务特点，进行针对性的设计，保障了数据库单点失效后的业务连续性。
对于业务量不是特别大的场景，利用虚拟化技术，构建集中部署、有效隔离、弹性伸缩的数据库资源池，为系统整合提供了支撑。
OLAP领域，农业银行较早地实现了分布式数据库集群架构，2011年，以审计三期系统建设为契机，基于分布式数据库集群，采用4台X86服务器，实现了全行审计数据的大集中，管理数据达30TB以上，满足了上千审计人员的使用。
基于此，将分析型系统的数据库部署架构全部统一到X86集群上。
2013年开始，农业银行积极与国内主流厂商开展合作，攻克多个技术难点，构建了分布式的MPP集群数据库，目前最大的集群达到56节点，所管理的数据达2PB，日作业量达40000以上。
在业务逻辑相对简单或者非结构化领域，采用Hadoop架构满足数据分析需求，2013年底，核心系统明细查询业务迁移到Hadoop平台，满足了广大客户明细查询需求。
（
4）存储服务层
存储层主要是完成数据的存储、备份，农业银行主要使用的存储分为SAN和NAS两类，通过LVM镜像、存储复制、虚拟化等技术实现存储的高可用。
在品牌方面保持3家左右的竞争，近年来随着国产自主可控产品的日益成熟，农业银行在国产SAN、NAS存储方面应用日益广泛。
此外，基于服务器、万兆网络、固态盘和软件定义的分布式存储技术逐步成熟，农业银行也对其进行了研究和试点。
分布式架构与运维管理
分布式架构降低了单个节点对基础软硬件的可靠性、可用性依赖，通过架构来保障系统的整体可用性。
但随着分布式架构、虚拟化等技术的实施，设备与系统数量快速增长，一个系统涉及的节点众多，为运维管理带来了较大的挑战。
为此，农业银行在监管控系统建设方面做了大量工作，以提升运维管理的标准化、自动化水平。
一是在监控管理方面，大力推进基础架构与应用产品的集中监控管理，经过多年的建设，基本实现了计算、存储、网络等基础架构的7*24小时监控，对关键应用系统建立了端到端的实时监控，出现异常后，能够实现快速发现、快速定位、快速处置。
二是研发推广了自动化运维管理平台，实现了系统的批量部署、合规检查等功能。
三是研发推广了用户统一管理、行为审计等系统，实现了密码集中管理、单点登录、行为审计。
四是基于ITIL流程平台，推广ISO20000等规范，统一了变更、事件、问题等管理流程。
未来展望
虽然农业银行近年来在分布式架构上做了一些研究和实践，但仍有许多提升空间。 特别是农业银行正在建立两地三中心多活架构，以此为契机，将进一步提升分布式架构在多中心的应用。
一是主机平台上 ，深入研究业务特点和应用架构，将可以下移的应用和数据迁移到开放平台。 进一步推广主机开放融合架构，扩大查询交易迁移范围，从核心系统业务类型来看，查询类交易占比达70%左右，如果能将大部分查询类交易移植到融合架构上，效果将更为显著。 另外，以两地三中心建设为契机，实现核心系统的异地双活部署，提升系统处理能力、灾备系统的可靠性，确保极端情况下的业务连续运行。 二是开放平台上 ，通过对集群技术、分布式数据库、分布式存储等技术的深入应用，结合业务特点对应用进行精心设计，以两地三中心为契机，将业务合理分布到多个中心，构建多活架构，进一步提升系统的健壮性和应急处置能力。 三是运维管理上 ，加强开发与运维的融合，持续优化完善现有的监管控平台，加强流程平台与自动化平台的融合，加强实时流数据的应用，进一步提升端到端的运维管理标准化、自动化水平，提升问题发现、定位、处置能力。 总结
综上所述，分布式架构具有更好的可扩展性，对基础软硬件的可靠性、可用性依赖度更低，可以采用更加开放、廉价的产品构建。 但我们也要看到其给应用设计、研发、运维管理所带来的挑战。 总之，技术是为业务服务的，无论是集中式架构还是分布式架构，各有优缺点，我们需要根据不同的应用场景，选择合适的技术架构。 此外，银行与互联网企业在信息系统建设上，无论是业务类型、风险容忍度、监管要求上，还是技术架构和文化机制上，有着较大的差异。 确保客户资金安全和生产运行稳定，是银行信息化建设的首要原则，在分布式架构应用当中，要结合技术可控、风险可控、成本可控综合考量，要本着实事求是、稳妥前行的原则逐步推进。 （来自： e-works）
在线问答
即时回复
（一）分布式架构简介
一般可以将架构分为两类，一类是以垂直扩展（Scale up）为主的架构，如通过增加单机配置，或者将中低端设备升级成为高端设备，用以提升系统的处理能力，称之为集中式架构，早期的哑终端主机架构是典型代表； 一类是以水平扩展（Scale out）为主的架构，通过横向扩充节点，如一个节点扩充到多个节点，每个节点运行独立实例，节点与节点之间通过网络互连，随着节点扩充系统处理能力能够随之提升，单节点失效时，整个集群仍然可以对外提供服务，称之为分布式架构[2]。
信息系统发展到今天，单一的架构难以满足业务量、数据量不断增长和业务需求灵活多变的要求，集中式架构与分布式架构不再是泾渭分明，往往处于融合状态，如农业银行全国数据大集中工程实施以前，核心系统部署在各省域中心，通过交换系统实现全行的业务联网，从全行来看，核心系统是一个分布式的架构，但从某个省中心来看，又是一个集中式的架构。 全国集中以后，核心系统基于主机的并行耦合架构，将核心业务全部集中到一个数据库当中，通过耦合器实现内存共享，一般将其理解为集中式架构，但该架构本身也采用了许多分布式技术，如应用服务层、数据服务层、存储服务层均实现了多节点部署，单机故障不会影响到业务的连续运行，系统处理能力可以通过垂直扩展或者水平扩展提升。
（二）优缺点分析 1、集中式架构的优缺点 集中式架构系统底层一般采用成熟的商业基础软件构建，这种架构的优点是成熟稳定，可用性、可靠性好，银行的技术人员可专注于业务功能开发，无需过多关注底层技术的实现。 全国数据大集中后，农业银行核心业务系统交易成功率和业务连续性得到了进一步提升，产品创新与推广更为高效，业务量年均增长率近30%，至2016年底，日均交易量在3.2亿笔左右，峰值交易量突破4.5亿笔/日，业务级交易峰值突破13000tps。 自集中以来，虽然业务产品和业务量均大幅增长，但底层技术架构基本保持不变，运维更为集中统一，有力地保障了业务快速发展和生产的平稳运行。 缺点方面，一是风险度集中，虽然产品比较成熟稳定，但一旦出现软件或者逻辑上的极端异常，也有可能导致整个集群不可用，从而引发全局性停业。 二是我国人口基数大，随着经济的快速发展，业务量在全球处于领先，许多新的问题、产品缺陷将有可能首先在我国触发。 三是成本高昂，集中式架构对基础软硬件产品的可靠性、可用性依赖度高，这些技术产品基本被极少数公司所垄断，缺乏有力的竞争者，IT成本居高不下。 四是核心技术受制于人，供应链风险较大。
2、分布式架构的优缺点 分布式架构按照一定的维度将系统进行拆分，通过一定的负载均衡机制，将业务分摊到多个节点上处理。 这种架构的优点是可以采用更开放的架构，各节点松耦合，对底层产品的可靠性、可用性依赖降低，可以基于廉价的硬件和开源软件构建，受单一厂商的制约较少，可以引入多家厂商竞争，成本更为低廉，可用性、可扩展性更好。 尤其是随着应用规模的扩大，边际成本将更低。 这种架构的难点是要做好各节点的协同工作，尤其是要处理好数据的一致性、完整性问题。 根据CAP理论[3]，在可用性、分区性与一致性三者之间，同时只能满足两个，如果要满足可用性（A）、分区性（P），就需要牺牲一致性（C），业界的一般做法主要是根据业务特点，通过较为复杂的应用设计，放弃实时一致性、保障最终一致性来解决该问题，分布式架构增加了应用设计和研发的复杂度。 此外，随着节点数的增加和分布部署，对运维管理、异常处置也提出了更高的要求。 农业银行在分布式架构上的实践
随着Linux等开源软件日益成熟，X86服务器的可靠性、处理性能快速提升，虚拟化、集群、大数据、高速网络技术得到广泛应用，为构建分布式架构提供了有利条件。 近年来，农业银行在主机和开放领域对分布式架构进行了研究和实践。
（一）主机领域 以新一代核心银行系统建设为契机，农业银行对主机的架构进行了优化。 一是将交易路由层分离出来，实现交易的统一接入和负载均衡调度，减少了对主机的依赖，降低了资源消耗。 二是采用读写分离设计，构建主机开放融合架构，将查询类交易的应用逻辑处理下移到国产X86服务器上，通过DRDA方式访问主机数据库，从试点情况来看，交易下移后可比下移前可节省60%左右的主机计算资源消耗，效果明显。 三是将明细数据下移到开放平台上，基于Hadoop架构实现明细业务查询。 四是将可以下移的业务系统整体下移到开放平台，减少主机资源使用。 （二）开放领域 全国数据大集中之后，农业银行大力推进集群架构、虚拟化技术的应用，采用Linux替代UNIX，用X86服务器替代小型机，引入集群数据库和MPP数据库，探索存储虚拟化应用，构建更加开放的分布式架构，同时加强监管控等运维平台研发，降低分布式架构所带来的运维压力，提升系统运维标准化、自动化水平。 1、农业银行开放平台分布式架构 下图列出了农业银行目前开放平台的典型架构，从应用接入层、应用服务层到数据服务层和存储服务层，均实现了分布式部署。
图1：
农业银行开放平台分布式架构
（1）应用接入层负责前端访问需求的统一接入，以及对后端应用服务器的交易分发和负载均衡。
通过应用接入层实现了前端对后端的透明访问，后端系统可以根据业务量和系统性能按需扩展，弹性部署。
（2）应用服务层负责应用逻辑的处理，以Java和.net平台为主，集群中各节点基于对等结构，运行状态独立，任何一个节点出现问题，能够通过前端负载均衡集群及时判断和隔离，硬件层面全部采用X86服务器，基于计算虚拟化实现资源使用的弹性伸缩。
（
3）数据服务层负责数据的存取服务，按类型总体分为联机事务处理（OLTP）和联机分析处理（OLAP）两个领域。
OLTP领域一般采用成熟的厂商产品，保持2-3家形成一定竞争，降低集中度风险。
对于大业务量的OLTP场景，采用读写分离、联机与批量分离设计，或者按照一定的维度对数据库进行拆分，如网银系统，日均交易量已经达到上亿笔，单数据库处理起来压力非常大，按照客户等维度拆分成多个数据库，实现了数据库的堆叠和横向扩展，单个数据库异常对全局无影响或者影响极为有限。
图2：
分布式数据库架构
随着X86服务器可靠性和处理能力提升，以及集群数据库技术的成熟，农业银行加大了X86服务器在数据库领域的使用力度，2014年，全国集中的信贷系统数据库从高端小型机迁移到国产X86服务器，日均交易量达3000万笔。
在新一代银行卡受理环境系统建设中，全面采用X86服务器构建集群数据库计算环境，根据业务特点，进行针对性的设计，保障了数据库单点失效后的业务连续性。
对于业务量不是特别大的场景，利用虚拟化技术，构建集中部署、有效隔离、弹性伸缩的数据库资源池，为系统整合提供了支撑。
OLAP领域，农业银行较早地实现了分布式数据库集群架构，2011年，以审计三期系统建设为契机，基于分布式数据库集群，采用4台X86服务器，实现了全行审计数据的大集中，管理数据达30TB以上，满足了上千审计人员的使用。
基于此，将分析型系统的数据库部署架构全部统一到X86集群上。
2013年开始，农业银行积极与国内主流厂商开展合作，攻克多个技术难点，构建了分布式的MPP集群数据库，目前最大的集群达到56节点，所管理的数据达2PB，日作业量达40000以上。
在业务逻辑相对简单或者非结构化领域，采用Hadoop架构满足数据分析需求，2013年底，核心系统明细查询业务迁移到Hadoop平台，满足了广大客户明细查询需求。
（
4）存储服务层
存储层主要是完成数据的存储、备份，农业银行主要使用的存储分为SAN和NAS两类，通过LVM镜像、存储复制、虚拟化等技术实现存储的高可用。
在品牌方面保持3家左右的竞争，近年来随着国产自主可控产品的日益成熟，农业银行在国产SAN、NAS存储方面应用日益广泛。
此外，基于服务器、万兆网络、固态盘和软件定义的分布式存储技术逐步成熟，农业银行也对其进行了研究和试点。
分布式架构与运维管理
分布式架构降低了单个节点对基础软硬件的可靠性、可用性依赖，通过架构来保障系统的整体可用性。
但随着分布式架构、虚拟化等技术的实施，设备与系统数量快速增长，一个系统涉及的节点众多，为运维管理带来了较大的挑战。
为此，农业银行在监管控系统建设方面做了大量工作，以提升运维管理的标准化、自动化水平。
一是在监控管理方面，大力推进基础架构与应用产品的集中监控管理，经过多年的建设，基本实现了计算、存储、网络等基础架构的7*24小时监控，对关键应用系统建立了端到端的实时监控，出现异常后，能够实现快速发现、快速定位、快速处置。
二是研发推广了自动化运维管理平台，实现了系统的批量部署、合规检查等功能。
三是研发推广了用户统一管理、行为审计等系统，实现了密码集中管理、单点登录、行为审计。
四是基于ITIL流程平台，推广ISO20000等规范，统一了变更、事件、问题等管理流程。
未来展望
虽然农业银行近年来在分布式架构上做了一些研究和实践，但仍有许多提升空间。 特别是农业银行正在建立两地三中心多活架构，以此为契机，将进一步提升分布式架构在多中心的应用。
一是主机平台上 ，深入研究业务特点和应用架构，将可以下移的应用和数据迁移到开放平台。 进一步推广主机开放融合架构，扩大查询交易迁移范围，从核心系统业务类型来看，查询类交易占比达70%左右，如果能将大部分查询类交易移植到融合架构上，效果将更为显著。 另外，以两地三中心建设为契机，实现核心系统的异地双活部署，提升系统处理能力、灾备系统的可靠性，确保极端情况下的业务连续运行。 二是开放平台上 ，通过对集群技术、分布式数据库、分布式存储等技术的深入应用，结合业务特点对应用进行精心设计，以两地三中心为契机，将业务合理分布到多个中心，构建多活架构，进一步提升系统的健壮性和应急处置能力。 三是运维管理上 ，加强开发与运维的融合，持续优化完善现有的监管控平台，加强流程平台与自动化平台的融合，加强实时流数据的应用，进一步提升端到端的运维管理标准化、自动化水平，提升问题发现、定位、处置能力。 总结
综上所述，分布式架构具有更好的可扩展性，对基础软硬件的可靠性、可用性依赖度更低，可以采用更加开放、廉价的产品构建。 但我们也要看到其给应用设计、研发、运维管理所带来的挑战。 总之，技术是为业务服务的，无论是集中式架构还是分布式架构，各有优缺点，我们需要根据不同的应用场景，选择合适的技术架构。 此外，银行与互联网企业在信息系统建设上，无论是业务类型、风险容忍度、监管要求上，还是技术架构和文化机制上，有着较大的差异。 确保客户资金安全和生产运行稳定，是银行信息化建设的首要原则，在分布式架构应用当中，要结合技术可控、风险可控、成本可控综合考量，要本着实事求是、稳妥前行的原则逐步推进。 （来自： e-works）
扩展阅读
MySQL亿级数据数据库优化方案测试-银行交易流水记录的查询
原来银行都在用这些数据库
恒丰银行 I MySQL MGR与Galera性能测试买家秀
揭秘：贵州交警“六合一”系统，零故障运行500天的背后
警告：ORA-00600 2252 错误正在SCN问题下不断爆发
解读年度数据库性能：PostgreSQL的日志文件和数据加载
给数据库减负的八个思路，盘它！
开源正在吞噬软件业？看开源的7大理念
数据和云小程序『DBASK』在线问答，随时解惑 欢迎了解和关注。
在线问答
即时回复
数据和云
ID：OraNews
如有收获，请划至底部，点击“在看”，谢谢！
资源下载
关注公众号：数据和云（OraNews）回复关键字获取
help，30万+下载的完整菜单栏
2019DTCC，数据库大会PPT
2018DTCC , 数据库大会PPT
2018DTC，2018 DTC 大会 PPT
ENMOBK，《Oracle性能优化与诊断案例》
DBALIFE，“DBA 的一天”海报
DBA04，DBA 手记4 电子书
122ARCH，Oracle 12.2体系结构图
2018OOW，Oracle OpenWorld 资料
产品推荐云和恩墨Bethune Pro2 企业版，集监控、巡检、安全于一身，你的专属数据库实时监控和智能巡检平台，漂亮的不像实力派，你值得拥有！
云和恩墨zData一体机现已发布超融合版本和精简版，支持各种简化场景部署，零数据丢失备份一体机ZDBM也已发布，欢迎关注。
云和恩墨大讲堂 | 一个分享交流的地方
长按，识别二维码，加入万人交流社群
请备注：云和恩墨大讲堂