专栏
案例
活动
科技资讯
跨界金融
证券
保险
银行
首页
搜索
经典案例
  • 黑龙江农村信用社——增值税管理系统
  • 黑龙江省农村信用社联合社于2005年8月2日成立,由省内13家市地联社、办事处和81家县级联社自愿出资入股设立,具有独立法人资格的地方性金融机构。经省政府授权,黑龙江省农村信用社联合社在省政府的领导下,负责行使对辖内市、县(市、区)农村信用合作联社、农村信用合作社联合社、农村合作银行、农村商业银行等农村合作金融机构的行业管理、业务指导、协调服务职能。

  • 鑫元基金——新一代互联网金融产品-鑫钱宝
  • 经中国证监会批准,鑫元基金管理有限公司于2013年9月12日在上海正式成立。公司由南京银行股份有限公司发起,与南京高科股份有限公司联合组建,注册资本金2亿元人民币,总部设在上海。公司经营范围包括基金募集、基金销售、特定客户资产管理、资产管理和中国证监会许可的其他业务。截止2016年12月31日,公司管理的总资产规模近4000亿,母公司固定收益业务特色突出,货币、固收基金行业排名靠前,子公司规模排名行业前十。

    视频
    更多
    北京农商行李秀生谈IT技术对银行的风险管
    • 北京银行:新平台应对新挑战,NewSQL开源数据库的转型实战
    • BY:王柏寒
      2018-10-12

    这是最好的时代,也是最坏的时代。在这个时代,我们有各种技术可以选择;而同时,在这个时代,我们有各种技术要选择。

    近年来,国家不断提高对信息技术安全、自主可控的战略要求,银行业希望在快速发展业务的同时不断降低经营成本。这不仅促使商业银行积极提升自主掌控能力,同时,对基础软件的服务能力、软硬件升级成本控制也提出了新的要求。面对互联网金融新业务带来的交易复杂度及交易频次的大幅提升,商业银行信息系统原来采用的传统数据库一体化解决方案,在应对此类场景时遇到了明显的性能瓶颈,而提升系统性能只靠替换式的硬件升级,成本昂贵。在这种背景下,引入一种高性能、可弹性扩展、能够支持互联网OLTP场景的数据库成为北京银行系统建设的优先选择方案。

    新挑战,新平台

    传统的数据库系统在面临互联网应用时,有一些不能回避的痛点。2008年以前,数据库基本上是以单机型为主,比如广为人知的Oracle、MySQL、PostgreSQL等单机数据库支撑的数据存储业务,但是随着互联网的蓬勃发展,接入到互联网的设备越来越多,数据量越来越大,并发处理需求越来越急迫,各界业者们渐渐发现这种单机关系型数据库已经无法满足在互联网中遇到的诸如大数据存储、高并发等问题。于是,以Google为代表的一些互联网公司开始转向NoSQL这种分布式的数据库,这是一个牺牲掉部分关系转向追求可扩展性的模型。但是近几年来,很多业务不能直接以NoSQL的模型来生搬硬套,很多已有业务,特别是对传统行业,比如银行业来说,历史遗留下来的程序都是以关系型数据库为基础的,所以很难把这些Old-SQL的资源放在一个分布式的场景来使用。难道就没有办法将单机型SQL关系模型与NoSQL的分布式能力结合在一起吗?之后不久,NewSQL型数据库应用而生。

    今年3月,北京银行分布式核心交易系统完成投产,成为国内首家采用NewSQL数据库方案应用于核心交易场景的银行。此系统的投产使北京银行信息系统可以从容面对“双十一”等高并发、大交易量的业务场景,提供更强的服务能力,并且改变以往只能通过硬件替换式升级的局面,可以快速、持续、低成本地支撑业务量增长。北京银行实现了两地三中心五副本的部署模式,具备服务器级、机房级的容灾能力,大大提升了信息系统可靠性。

    分布式架构实践过程

    虽然分布式事务数据库在互联网应用场景下的探索取得了良好的成效和大量的实战经验,积累了很多成熟的技术,但相比互联网企业,金融行业对风险控制的要求更高,所以在面对高复杂度交易场景、业务实时高一致性等方面的需求时,需要更为完善的技术方案支持。所以,北京银行对于分布式数据库的选择也比较谨慎,利用两轮专项POC评测来探索分布式数据库的适用场景及性能指标,并且为了为避免测试场景的单一化、模式化、常规化,北京银行提出“标准化交易组”的概念,尽可能模拟银行真实使用场景,使测试结果更加真实准确。

    目前绝大部分分布式数据库解决方案都是基于MySQL主从复制结合分库分表中间件方式进行改造和集成。此类架构离银行业务场景中的高可用和多中心容灾及多活的高级别安全要求有一定距离。北京银行率先采用了两地三中心五副本的高可用部署架构方案,支持同城两中心多活,并具备服务器级、机柜级、数据中心级容灾能力。满足金融行业对风险控制的严格要求的同时,提高北京银行信息系统对业务支撑的持续性。

    相比于传统数据库架构,分布式事务数据库架构更加复杂,组成部件更多。并且,面对OLTP的场景,分布式事务数据库进行一次事务操作比传统数据库要复杂的多,需要面临更多挑战。北京银行认为建设一套完备、针对性强的评测体系,用以检验迁移分布式事务数据库的可行性十分有必要。北京银行建立评测体系有两个目标:

    一是实现对分布式事务数据库的全面评测,北京银行自主提出了一套“分布式事务数据库评测指标”(如图),包含六大项,二十一项细分功能指标。六大项包括算法指标、可靠性指标、安全备份能力、个性化能力、数据库支持能力和兼容性指标,再逐一对指标项进行验证,得到评测结果;二是验证数据库迁移本地化可行性,提出“标准化交易组”概念,将生产实际运行的典型交易迁移到开放式平台,用典型交易对分布式事务数据库进行测试,测试指标包括TPS、QPS和响应时间等性能指标。同时,利用“标准化交易组”进行多场景组合,再对第一步提出的评测指标进行回测验证。

    结合两轮POC结果,入选产品表现出了架构的先进性和高效的性能,水平扩展能力、交易处理能力和功能指标均符合北京银行对分布式数据库产品的要求。其采用的Raft算法保证了数据的强一致性,同时可以实现两地三中心多活的部署方式,以上特性在应用中具备较大优势。除了优秀的开源社区环境,其背后的团队在开发支持、技术培训、运维服务、成本控制等方面也表现出了优秀的素质。

    微服务+NewSQL

    除了分布式NewSQL数据库之外,针对服务领域应用,北京银行在微服务上进行了相应的探索,用到了两个重要的系统——网联支付清算平台和银联无卡支付系统,收益效果显著。

    首先,对比之前的传统系统架构,其通过服务划分,践行了软件设计思想中的“单一功能原则”,将复杂的问题简单化,更有利于设计、开发、维护,同时简单化的功能使得人员学习、掌握成本更低,以往需要整个开发团队共同协作研发的软件功能,现在只需要2~3人便可以完成;其次,横向扩展能力较之前传统应用架构有了长足进步。不用修改任何代码,通过配置文件即可动态完成集群扩、缩容;最后,CI/CD效率显著提升。每个微服务都具备“单一功能原则”,其将运行所需资源包装为容器形式发布,其不依赖于其它微服务或其它例如数据库、内存缓存等资源,因此其升级过程更为独立,开发人员可以快速完成服务升级发布。北京银行应用“微服务+NewSQL”后的主要评测数据包括:

    1.单节点测试、双节点测试、多节点测试,用以测试横向线性扩展能力。

    2.观测多个服务节点CPU、内存使用率,确认其具备流量限制和负载均衡能力。

    3.进行系统滚动升级测试,观测请求响应情况,确认其可以支持不间断服务的系统升级。

    对于金融类信息系统而言,数据库扮演着不可替换的基石作用,它的支撑能力至关重要,因此,北京银行把分布式NewSQL数据库的建设放在首要位置。

    微服务与其它技术作为NewSQL数据库的消费者,同时也是NewSQL数据库的价值输出渠道,除了要满足业务需求外,还应更加紧密适配NewSQL数据库,将业务价值最大化。在实际应用过程中,两个方面的问题显得尤为重要:一是将分布式应用架构与分布式NewSQL数据库作为一个整体进行设计,高度匹配二者能力矩阵,让其共同发力,例如两地三中心多活、灰度发布、流量负载、一致性保障等特性,只有二者都具备同等的能力才能最终释放价值;二是分布式NewSQL数据库兼容MySQL的SQL语法、驱动标准、数据库命令等技术标准,但其基于分布式理论搭建,在事务模型、隔离级别、锁实现机制等特性上均带有分布式色彩,应用系统在与其对接时应充分考虑这些内容,充分展现出分布式NewSQL数据库的特色。

    面对架构改造升级变化巨大,在硬件选择上,有两点明显变化。第一,由数据库对硬件IO能力有所要求,采用了SSD磁盘替换SAS磁盘;第二,分布式系统架构对网络依赖较大,因此需保证较小的网络延时和较大的传输带宽。除此之外,并没有特殊要求,采用的均为普通的X86服务器。

    另外,由传统数据库过渡到分布式NewSQL数据库,由单体应用到微服务应用架构模式,在人员需求方面也产生了一些变化:

    1.成立专项创新小组,对开源软件进行应用探索,可以较为敏捷地使用开源软件释放业务价值,同时甄别开源软件是否可以满足金融级应用需求的能力,确保应用安全

    2.北京银行希望从“竖井式架构”和“SOA架构”转型到微服务架构,其成败关键在于人员的工作思路的变化以及技术的转型。在进行系统架构升级之前,一定会投放相应的资源进行调研、评测、原型设计等相应的工作,确保新架构的可行性,人员能力在这个过程也顺其自然得到了提升。同时,银行也积极推动员工融入开源社区、积极拥抱新技术,结合着实际工作,快速实现人员的技术转型。

    3.现今,FinTech高速发展,技术更新换代速度快,这对技术人员提出了更高的要求。在银行这种信息系统历史资产庞大的企业,科技人员一边要在旧的系统上进行研发、维护,另一边还要进行新系统的开拓,的确会造成人员成本的升高。为此,行内确定了两条策略加以应对:一个是从基础性软件入手,着重信息系统能力建设,范围不求全,但一定是关键核心部件,释放最大的业务价值;另一个是采用渐进式方式,进行新旧系统换代,给技术人员能够提供一个相对充裕的缓冲期,保障升级稳定及成本可控。

    后期为确保稳定安全,在网联支付清算平台和银联无卡支付平台接入以后,北京银行持续对数据库性能进行监控,不断对应用提出修改意见;将NewSQL数据库监控接入总行统一监控告警平台,加强运维监控力度;进行不间断服务滚动升级改造,在数据库部件进行版本升级时依旧可以保证业务连续性。实践一段时间后,北京银行交易型数据库NewSQL的转型从以下三方面提升金融服务能力:

    1.性能提升:保障海量、高并发业务对接,交易处理效率大幅提升。

    2.成本降低:由X86服务器构成分布式数据库平台,大幅降低金融IT成本。

    3.安全备份:有效实现数据可追溯,满足监管要求;提高运维自动化。

    释放价值,展望未来

    目前国内越来越多的金融机构将开源技术作为主流应用的技术,而银行在开展技术能力转型建设的过程中,也必然会应用越来越多的开源技术。开源软件是当前软件发展的趋势,互联网企业的大规模应用和快速迭代使开源软件成为先进技术事实上的代表。传统银行业使用开源软件的初衷是希望快速获得互联网企业同样的能力,但是需要跨越多个技术挑战。

    未来在金融科技应用创新领域上,北京银行计划从几个方面,进一步升级金融互联网和大数据的应用创新能力:一是继续发展云计算技术,利用云计算灵活的开发、集成、部署能力,缩短产品发布周期,快速响应业务需求;二是依托大数据技术,通过对客户交易、行为、应用等大容量、多样性的数据进行有效分析,精准提升整体服务质量、落实金融风险防控;三是将热门感官技术引入到渠道服务中,与人工智能相结合,全力打造“全能智慧银行”,实现用户体验的持续创新。

    不同于部分银行在新兴业务上采用互联网公司提供的整体外包解决方案,北京银行寻求自主可控能力,主动在模式和管理上创新,与互联网思维和技术不断切磋、碰撞、融合。通过研究、评测、应用、部署等工作,在实践中做到了自主掌控。双方在合作中互惠互利,利用双方优势,实现了信息系统服务能力的快速提升,打造出具有北京银行特色的创新驱动力。

    分享
    0人觉得很赞
    发布
    游客宝贝2018-10-12
    11