分布式架构在金融行业的应用分析

转载原文http://www.zte.com.cn/cndata/magazine/zte_technologies/2016/2016_6/magazine/201606/t20160620_458638.html

　　近年来，“去IOE”成为一个热门话题。这一方面是技术考量，IOE代表这一代成功的技术架构，但互联网时代下海量高并发使得传统IOE架构不能适应业务发展。另一方面IOE代表海外巨头产品，他们处于垄断地位使得用户缺乏议价能力，成本高昂，技术上受制于人，安全风险较高。
　　随着国家安全可控政策的实施，移动互联网金融业务的兴起，普惠金融业务量的迅速提升，以及利率市场化导致收入受限，金融信息系统采用分布式架构是大势所趋。通过实施分布式架构改造，我们可以构建起高可用、易扩展、低成本的现代金融信息体系。
　　维基百科对于分布式系统的定义为：“分布式系统是由若干个相互独立的组件构成，但从外部用户来说，就像一个单一系统。”这个定义包含两个核心内容：从硬件角度，各组件都是自治的、独立的；从软件角度，用户感受是整体的、一致的。
　　分布式架构的核心理念是按照一定维度将系统进行拆分，通过开放的结构，实现各业务模块松耦合，降低对底层硬件的依赖程度。同时通过系统级容错设计，在廉价硬件基础设施上构建起高可靠、高可用、可扩展的开放技术体系。
　　金融行业与互联网行业的最大区别在于金融行业对于数据的可靠性和一致性要求极高，而互联网行业则容许有少量的错误或不一致。这也导致互联网行业在分布式架构的一些实践经验没有办法直接应用于金融行业。本文将重点讨论在金融行业中如何进行分布式架构改造。

金融信息系统的现状及问题
　　这些年随着互联网金融的发展，以及我国金融制度的不断完善，金融信息系统面临如下挑战：
　　● 运行要求严格
　　银监会监管规定，涉及客户服务的业务停机超过30分钟要上报银监会，超过2小时要上报国务院。
　　● 利率市场化，同业竞争加剧
　　银行要尽快引入新技术，完善移动渠道的访问能力，增加服务渗透力，新业务能够快速部署上线。
　　● 利润空间下降，IT成本压缩
　　传统银行IT架构采购和维护成本过高，谁拥有更低成本的IT技术谁就更有竞争力。
　　● 普惠金融服务系统波动大，压力大
　　要求系统可灵活弹性扩展，“秒杀”、“双十一”等活动将常态化；24小时银行服务，要求缩短系统变更、维护的计划停机时间。
　　● 跨界融合，金融能力开放
　　银行服务由传统金融服务转变成场景化、社区化的综合性服务（泛金融服务），需要通过能力开放实现与其他行业服务的融合。
　　● 信息安全、自主可控的监管要求
　　“IOE”对金融业形成事实垄断，产品闭源不可控，IT系统依赖性过大，失去议价能力，供应链单一，在紧急情况下国外厂商技术封锁可能造成国家金融安全风险。要满足信息安全、自主可控的监管要求，必须“去IOE”。
　　图1是目前我国大部分商业银行的典型技术架构。

　　在这个架构中，通过业务分层分为4个主要业务模块，渠道模块主要负责用户服务及业务接入，产品模块负责提供各种产品服务，而所有的交易最终都会落在核心服务层执行，各种数据汇总到分析服务产生各种报表供业务人员或领导进行决策。
　　每个业务模块都由很多子模块构成，在传统商业银行架构内每个子模块都是独立的完整竖井式IT系统，从业务服务到数据库一应俱全，每新上一个业务都要重新配置一批服务器和数据库。所有业务压力最终都会落到核心服务上，这就需要核心服务配置一个超强的服务器和数据库，能够应对所有业务请求，压力巨大。因此我们必须重塑金融IT架构，以加速面向互联网时代业务转型，包括重塑平台、重塑数据和重塑服务，从而实现开放高效的IT基础设施、智慧的服务平台和泛在便捷的服务渠道。

金融行业分布式架构改造要点
吞吐量与性能需求
　　2015年双11支付宝全天支付7.1亿笔，交易峰值每秒达14万笔，每笔支付耗时0.035秒，微信红包业务猴年春节每分钟达8.1亿笔，而现有商业银行最高并发峰值处理能力仅为1.5万笔/秒，远远无法应对互联网金融的冲击。从架构角度一方面我们需要扩展核心业务系统数据库处理能力，因为这里是全系统的瓶颈，另一方面需要对各业务进行分布式架构改造，让容量性能能够通过简单增加节点进行线性扩展。
系统可用性需求
　　传统架构中的高可用性是通过高可靠硬件设备来实现的，相当于把所有鸡蛋放进一个篮子里，然后用各种手段保护好这个篮子。而分布式架构的理念则是把鸡蛋分散到多个篮子，任何一个篮子坏掉不影响吃鸡蛋。对于金融系统，我们实施分布式架构必须满足以下可用性需求：
　　● 单节点故障是常态，有自愈能力；
　　● 出现问题后局部故障不扩大，系统能够带故障工作；
　　● 具备故障自动发现、恢复与隔离的能力；
　　● 能够支持多版本灰度发布，通过先小范围试用，降低软件故障影响范围，提高业务上线速度；
　　● 减少计划停机，支持业务无中断升级。
系统安全性需求
　　传统封闭系统的安全性主要由系统生产厂商保证，就像一个黑箱一样，不是没有安全漏洞而是我们不知道他们有没有漏洞。而开放系统则通过整个过程的开放性，保证了所有漏洞都能够在第一时间发现并修复。
　　采用分布式架构的核心业务系统应该从网络、操作系统、数据库系统和应用多层面采取安全加固措施，包括链路和数据加密、身份识别、访问控制、数字签名、入侵检测、系统加固、审计跟踪等，提高系统安全性。
容灾与备份需求
　　由于金融业在整个社会生产过程中的核心地位，金融数字资产的安全性和可服务性要求是永远摆在第一位的。我们不仅仅要部署多个数据中心，而且要求能够在多个中心之间可以智能地调度金融交易，当任何一个站点的系统停止运行时，其金融交易均可在分钟级内全部切换至另外一个中心对外提供服务。分布式架构下多活是一个技术挑战，在这方面蚂蚁金服已有成功尝试，实现支付宝同城及异地双活部署。系统需要在分布式处理架构下对业务迁移，数据复制、同步、拆分、负载全局路由等技术进行创新，实现分布式架构下多活业务实践。
数据一致性需求
　　银行核心业务系统要求保证事务的强一致性，不同于社交信息处理、互联网信息处理、电商交易处理等可以容忍最终的事务完整性而不追求实时的事务完整性。将分布式中间件、分布式数据库和补偿交易、延时控制等应用优化相结合，可以满足银行核心交易一致性要求。但由于金融系统非常复杂，模块组件众多，历史包袱沉重，分布式架构需要渐进演进，对现有业务及服务尽量兼容升级。
运维自动化需求
　　分布式架构增加了系统的复杂性，设备和系统的数量也大大增加，无疑增加了运维工作的复杂性和工作量，因此应采用云管理平台等工具实现软硬件一体化统一运维管理，常用运维操作自动执行，降低管理风险，系统提高运维管理自动化水平。系统需要整合各类自动化工具，对常用日常操作如配置管理、变更操作、清理维护等做到全面自动化。自动化的前提是数据，因此还需要建立运维数据平台，搜集各类运行数据和信息，进行性能分析和故障预警、业务影响与风险分析、故障根因分析，实现自动化故障处置。

金融行业分布式架构改造步骤
　　金融行业进行分布式架构改造，我们认为应该分三阶段实施（见图2）。

第一阶段：应用架构的X86化改造
　　将主要应用从小机下移，降低主机系统压力。这一阶段希望能够达到的目标是应用无状态，数据集中，统一管控。整体系统架构有可能仍然是集中式架构，但部分应用进行分布式改造，与集中式架构整合，统一管理。
　　主要难点在于部分主机应用有可能需要重写代码，开发和验证有一定工作量。数据库部分则可以用基于X86环境的高性能分布式数据库替代小机环境下数据库。
第二阶段：云化基础设施改造
　　建立云平台，存储计算虚拟化，数据库分布式部署，逐步迁移各类应用到云平台之上。在这一阶段需要实现数据与业务分离，实施业务去状态化改造，并将数据层迁移到云化基础设施。
　　数据层分布式改造，在保持接口兼容性和数据一致性前提下提供分布式存储与服务能力。由于云化环境下系统拓扑由静态拓扑结构变成动态拓扑结构，因此我们还需要构建服务化交易路由层，将业务拓扑由静态路由改造为动态路由。对于暂时不便改造的业务，通过负载均衡服务实现动态路由。可下移的业务改造后统一下移到云化环境。
第三阶段：云化服务
　　这一阶段的重点是打造开放的服务能力平台，按需提供云化业务服务。需要建立微服务治理框架，抽取公共服务能力，统一数据处理，实现业务逻辑下移，由应用服务层完成核心业务逻辑。全面部署X86集群，减少对数据层逻辑依赖。本阶段还需要统一数据抽取与分析，构建公共数据处理，将可下移的业务改造后统一下移到云化环境，构建统一开放平台，保持对外接口的一致性。

分布式金融架构愿景
　　经过以上一系列架构改造，我们可以初步描绘出未来分布式金融架构的一个愿景（见图3）。

　　整体架构分四层，包括云化资源层、微服务平台层、开放业务能力层以及渠道接入层。另外还有安全管理、业务管理、应用开发环境等外围必备服务。
　　云化资源平台主要提供异构物理IT设备资源的虚拟化，形成资源池，对上层提供资源的管理、使用、计费等。云化资源平台包括计算资源池、存储资源池、网络资源池等，对于数据能力需要提供分布式数据库和分布式NOSQL存储以及大数据平台。云化资源平台还需要提供统一的基础运维，实现智能运维，提供应用的图形化编排、自动化部署、运行监控，以及弹性伸缩、容灾等高可用性服务。
　　微服务平台是本解决方案的核心，主要提供丰富的服务能力，包括数据服务、安全服务、中间件服务，以及从业务中抽取的核心公共业务服务，如交易服务、信贷服务、客户服务、支付服务、账户服务、积分服务等。通过统一的微服务平台我们可以实现基础金融业务能力的服务化。
　　仅仅有各种微服务是不够的，我们还需要对各种服务进行统一的治理管控，因此需要建立服务治理中心，主要包括服务的注册、发现、健康管理、部署管理、服务授权、服务调度以及动态服务路由等。我们还需要构建服务能力商店，让业务开发者能够自选服务完成业务的访问控制管理，并通过OPENAPI将服务能力对外部应用开放。
　　各业务除了共享的公共服务能力外，还包含各业务特有的一些能力服务，这部分需要进行业务服务能力化封装，也统一部署到服务平台供各种前端渠道统一调用。
　　应用层是银行提供各类金融类的业务，包括面向客户的业务、面向员工的业务。
　　金融机构对外接口主要分为两类，面向客户的接口以及面向监管机构及同业机构的接口。客户接口按照客户类型的不同，通过开放能力OPENAPI实现内部服务能力的统一开放，让用户终端设备或企业应用能够安全地访问银行业务。同业及监管则主要是通过数据交换方式完成信息共享及上报，同样我们通过抽取必要信息，并通过数据开放服务完成信息交换。
　　为实现整个金融业务的分布式架构改造，不仅仅是线上生产系统需要改造，我们还必须构建一体化的应用服务能力开放基础设施，支撑应用从开发、测试、部署到线上运维管理的一整套体系才能够实现一体化的自动化发布与运维。整个DevOps需要平台支持虚机、容器、物理裸机混合编排、部署、管理，提供业务图形化编排，应用一键自动化部署和智能监控、弹性伸缩、容灾双活等资源调度服务，从而实现云应用的全生命周期管理。
　　在分布式架构的实施过程中，我们需要遵循以下设计原则：
　　● 可扩展设计
　　通过功能内聚，对外松耦合，让业务能够不断适应用户增长的数量和服务请求。功能可扩展，通过一系列可独立部署的服务组件，经过业务编排，构成灵活的可复用业务模块，为多种业务提供服务，实现业务快速发布；性能可扩展，所有组件能力都能简单扩展，无共享架构保证不出现业务单点瓶颈。
　　● 高可用设计
　　我们要相信一个宇宙真理：硬件迟早会坏！软件永远有Bug！只要是人就一定会犯错！高可用架构的设计目标是：在恶劣的环境下系统能活下来，维持主要功能正常。主要手段包括集群容灾、数据复制、故障隔离，以及事先做好容量规划和限额管理，让系统入口流量不会超过系统瓶颈的处理能力。同时做好运行管理，在异常场景下可以做依赖降级，不要让被依赖的异常服务影响关键业务处理。

中兴通讯分布式架构产品支撑
　　中兴通讯云计算产品针对金融行业需求，全面规划了分布式架构解决方案，能够从硬件设备、资源池、资源管理、分布式服务，以及服务管理等全方位服务金融业务（见图4）。

　　中兴通讯分布式资源层提供分布式存储、分布式文件系统、SDN等组件。在资源管理层中兴通讯的特色是全面支持异构系统，不仅能够管理自家产品，更能够兼容管理VMWARE、小型机集群以及物理机集群。在服务层中兴通讯提供中间件服务、数据服务以及对应的服务治理中心，中间件服务包括WAS、ESB、负载均衡、锁服务、BPS、网络代理等。数据服务包括分布式消息队列、分布式大数据平台、分布式数据库等。值得一提的是分布式数据库，针对金融行业高可用、高一致性需求，中兴通讯发布了面向事务操作的GoldenDB分布式数据库，不仅做到了线性可扩展，而且在分布式事务处理方面通过运用专利技术，能够在各种异常场景下保证数据和事务一致性，同等条件下性能超过国际同行。中兴iSware分布式服务治理平台支持基于虚拟机以及容器的统一服务开发、编排、部署、测试、发布、管理、调度等全生命周期服务治理。上层应用使用服务能力时仅需要简单服务调用即可。系统可根据服务请求、流量等按需提供服务并保证服务质量。在异常情况下则可以按照预定策略进行服务调度及限流控制等。
　　中兴通讯在金融分布式架构领域积极推进开放平台生态圈建设。目前中兴通讯已经与多家银行进行了分布式架构改进的实践，实践成果获得了银监会一等奖。同时中兴通讯联合全球领先的银行IT解决方案合作伙伴在核心业务云化、分布式数据服务、开放平台整合等领域开展合作，共同帮助金融客户应对新时代的挑战。

转载于:https://my.oschina.net/u/3248336/blog/1574723