直销银行系统接口设计（直销银行系统接口设计方案）

本篇文章给大家谈谈直销银行系统接口设计，以及直销银行系统接口设计方案对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享直销银行系统接口设计的知识，其中也会对直销银行系统接口设计方案进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、理财项目资产管理模块怎么测试
• 2、传统银行架构变迁
• 3、银行理财测试点怎么写

理财项目资产管理模块怎么测试

对金融理财产品的功能进行验证。
对于中小银行理财APP来说，需要掌握以下方面的测试：
1、理财产品业务流程测试。
2、账务处理。
3、资金清算。
银行系统，通常行内系统与银行外对接的系统是独立开发的。
对于中小银行APP，一般存在多个系统。
如：
银行核心系统，直销银行系统，资产方（TA）等，多个系统之间通过接口、通讯协议进行资金清算、数据交互等。
在测试系统对账时，必须对账务处理流程有清晰的认识，对于账务处理过程中账务是否处理正确、是否出现错账、是否需要进行调账等案例都要重点覆盖。

传统银行架构变迁

银行属于传统的金融行业，银行业随着科技的不断进步和客户需求的不断提升，对银行科技系统的要求也是逐渐提高，而且随着近几年互联网金融的快速发展，传统银行业系统的发展也是非常迅速，本人08、09年最早在外企从事北美银行网银和手机银行的产品开发工作，后来从10年一直到16年一直在大型国有银行从事软件开发和架构设计的工作，16年中从国有银行离开加入互联网电商，做了不到一年因为种种非技术问题离开又回归了银行系统，目前在一家微型民营银行从事产品设计、架构设计的工作。总的来说还是经历了这几年银行系统快速发展的时期，也涉及了大型架构的变迁，今天就给大家介绍下银行的架构变迁，如有不对的地方还请专家指正。

90年代初期国内银行业蓬勃发展，早期各个分行都是人工记账，定期由省分行统一报送总行系统，随着国内经济的快速发展，银行的业务量也随之暴涨这样的工作模式已经无法满足需求了，所以90年代初4大国有银行都纷纷加强科技部的研发投入，参考美国、英国银行系统建设经验开始建设现代化银行系统，其实在那个年代大家对计算机的印象还非常陌生，在每个柜面都架设计算机，当时的柜面系统都是统一的命令行模式，没有可视化界面，后台系统采用的是集中式的架构，如下图所示：

当时的银行系统基本都是这样的集中式架构，大型国有银行一般也都是这种简单架构，当时大部分行业的系统也都是这样的架构。在这样的架构下柜面前端和后端系统采用的是CS架构，胖客户端的模式，每次客户端升级都需要将安装包提前一天下发给各个网点，现在看起来还是比较low的。银行后端是大核心的模式，即核心系统承担了主要的功能，账户、存贷款、总账、对账、支付、来账等功能都在集中式的大核心系统中，只有很少的一部分功能被剥离出核心系统，归属于外围系统。这些外围系统一般都是市面上有一些软件公司提供了现成的产品，只需要简单的二次开发就可以满足需求，这样一方面降低了开发成本，另一方面也加快的系统实施的进度。但是这种架构的系统承载能力还是比较有限的，随着交易量的快速上升很快就满足不了需求了，听行里的前辈介绍当年的场景，就是他们科技部每天都很忙，交易量每个月都会有大幅增长，每个季度的计息日批量和年底的年终决算都会让所有人忙通宵，这些记忆也成为了所有那个年代银行人痛苦的回忆。

集中式的系统已经逐渐满足不了高速增长的业务需求了，所以规模比较大的国有银行就开始考虑将现有的总行集中式系统分别在各个省分行分别都部署一套，每天晚上再通过批量的方式将各省数据进行集中，这种架构的方式能够最快的解决联机性能问题，但是又会引发新的问题，那就是跨省转账交易无法实时到账，就算是同一家银行的跨省转账一般也无法做到。所以90年代中后期的系统架构图如下图所示：

看图就可以发现，和之前的架构区别主要就是将总行集中式的部署架构调整为了各省分布式的架构，但是这种分布式架构并不是我们现在讨论的互联网分布式架构，当年还没有比较成熟的分布式架构方案，所以当时的分布式其实只是简单的将原先总行部署的一套核心系统和配套的外围系统分别在各省科技部分别部署，分别独立运维，就好像机构在整体行政关系上是一体的，但是实际科技系统是分开的，没有必然的联系，只是每天会进行数据交换来实现跨省转账、票据承兑等业务，所以很多银行业务的效率比较低，很难满足一些比较急迫的客户需求，最后出现了一些现象就是一个客户为了给一个跨省的客户汇款，最快的手段是先用自己本地的卡取现金，再人肉带到异地，有朋友要问了为什么不到当地再取，因为那个年代跨省取现不但取现时间、金额受限制还有高额的手续费。

2000年互联网高速发展，银行的科技水平也在这几年中高速发展，各家行的水平也逐渐拉开了差距，之前老的各省分布式部署的业务问题也渐渐凸显，由工行率先将之前分布式部署的省行系统进行总行上收，系统上收可不是那么简单，当年为什么要各省分别部署？就是因为集中式系统架构已经无法承载每天高速发展的业务量，如果再将各省的数据上收，那就意味着可能每天核心批量还没跑完还没来得及分发给外围系统就已经到第二天开门营业时间了。这么做科技部门需要承担的压力还是非常大的，需要解决很多问题，主要有以下问题：1）数据结构统一，数据映射，各省数据上收，数据迁移；2）新系统开发工作；3）系统上收对上收省份日常业务的影响；4）分行员工新系统的培训工作；5）新旧系统的平滑迁移，新旧系统的日常兼容性交互；6）整体的投产迁移方案、回退方案。我当时在中国银行也有幸经历了这一过程，整个过程持续了快4年，从整体的方案设计到系统的实施再到后面的系统迁移上线等等一系列工作，这个过程是艰难的，基本上加班成为常态，但是在这个过程中也学到了很多东西，也是成长比较快的一个时期。整个改造的一个核心架构思路就是对核心系统进行瘦身，将核心系统精简化，以此来提高核心系统的业务处理吞吐量，并采购最新的大型机来保证处理性能和IO性能，将大部分的业务都单建系统拆离出核心系统，基本上这样的整体架构在当时评估的时候能保证未来10－20年的业务发展量。下图为当时的整体架构图，但是从这个架构图中可以发现，整体架构核心系统和外围系统，再和渠道系统之间都是非常混乱的，系统间是完全的网状结构，图里还没有完全画完，因为画完以后基本是没办法看的，非常复杂的蜘蛛网。有个别系统因为是外包采购的系统的报文结构和其他系统都是不一样的，这样一旦某个系统要和这些奇葩系统进行对接就会遇到这样的问题，需要把这些奇葩接口的报文全部处理一遍，这就导致了很多重复的工作。

大部分银行很快就意识到这种集中式网状架构的缺陷，当时也正好流行ESB总线架构，所以银行系统也不免俗的纷纷去实现ESB总线。总线架构就是在渠道系统和核心、外围系统之间建立了一个ESB总线桥梁，所有的外围和核心系统的接口都注册发布到ESB总线上，由总线对外提供完全统一的接口标准协议，这样就避免了每个系统接入都是同一套标准接口，不用重复去实现不同的报文协议。这样的架构看起来就非常清爽了，不管是渠道系统还是外围系统调用各个系统的接口的时候都比较方便。这样的架构在银行系统中实施了很长时间，包括目前大部分的银行还都是采用这种架构模式，虽然现在看起来非常普通，但是当时看起来此种架构还是非常完美的。而且这种架构对于中小银行就算现在使用起来也是非常合适的。

随着互联网的发展网上银行、手机银行、直销银行纷纷成为新的渠道，人们也开始快速接受这种新兴的互联网渠道，互联网总线架构和之前架构的最大差别在于安全架构，后面会再单独写两篇关于安全的文章。其他方面的架构基本没什么变化，但是会发现一种现象就是，因为核心系统不新增大功能的情况下，不断新增外围新产品，当时中国银行一共有一百多个外围系统，还没算一些快下线的系统。随着业务量的不断上升，核心系统的业务量不断上升，总线的压力也逐渐上升，总线机器不断的横向水平扩展，在走之前总线的集群就扩展到了100个节点。

到了2012年以后随着facebook、amazon开放平台获得的巨大成功，BAT都逐步将自己的接口开放出来，都实施了开放平台生态圈战略，从而推动了SOA服务化的更快速发展。银行之前也一直在研究服务化的实施方案，但是由于ESB总线架构运转的非常稳定，也没出什么问题，所以导致各个行进行服务化改造的动力不是很强，而且这种整体架构的调整涉及到的部门和业务影响都是非常大的，一般银行这样比较稳妥的公司也都不敢有大的动作。我也是有幸在银行赶上了中国银行试点互联网金融，对新建的互联网金融系统实施服务化架构，下面就是当时中国银行的互联网金融服务架构，这个架构其实是一个传统银行互联网金融的一个妥协架构。

从架构图中可以看到，左边是之前的传统银行集中式总线架构，右边是互联网服务化架构，包含了开放平台、服务注册和发现、服务化产品系统。为什么这样设计，这是因为传统银行的各个产品系统是比较稳定的，而且在银行系统待过的同学都知道传统银行要新建一个系统或者新实施一个需求都是要经过很长的周期，传统银行都是瀑布式开发方式，各种评审、审批流程，导致从需求提出到功能上线基本上3个月过去了，效率还是挺低下的。根本满足不了互联网金融快速迭代的需求，因为当时我们不但试点新的soa架构，同时也在试点迭代开发，所以将互联网金融产品单独排期实施，单独部署，产品系统如果涉及到调用传统银行产品接口的地方全部通过ESB总线来调用传统银行产品系统接口。所有的互联网金融产品系统全部将接口服务化注册到服务注册中心，当时我们所有的互联网金融产品系统全部基于阿里的dubbo开发，系统将接口都注册到zookeeper上，两个系统直接的服务交互采用RPC模式；通过开放平台对外提供接口暴露，可以发现这种架构在保障传统银行系统稳定性的同时也可以满足互金需求的快速迭代实施，并且也使用了新兴的互联网分布式技术，来降低开发和运维的成本，目前我了解到的很多银行都在采用这种架构在实施互联网金融业务。

最近两年随着容器技术的不断发展，私有云平台、devops也逐渐在银行系统中进行试点，目前我所在的一家小型民营银行正在进行这方面的技术试点，底层采用docker进行镜像管理、构建、发布，在系统层面全部采用服务化架构，目前我们使用的是springcloud整体的解决方案。这样的架构看起来也是比较清晰，而且扩展性也很强，能够很好的满足未来业务发展的需求，随着docker技术的不断成熟，后续的devops也是逐渐会替代大部分的人工运维，之前我待过的一家互联网电商，80多个产品系统只有3个运维人员，所有的日常监控、版本部署都是自动化的，基本不需要人工干预，这种模式也是后续银行需要的一种开发和运维的方式。

今天只是大概介绍了下银行系统的历史变迁，真的只是非常简单的介绍，其实每个架构都有很多故事，都可以写很多，等到后续有时间会再把其中发生的很多细节写给大家看：）

银行理财测试点怎么写

1、理财产品业务流程测试金融行业软件业务测试需要关注的点如下：a、  金融理财产品业务是否正确；b、 业务流程是否合理；c、  业务流程设计是否满足客户实际需求；d、 能设计正常案例和异常案例来验证业务流程的完整性和正确性；e、  能校验业务流程中资金、库存等数据流的正确性；f、   后台业务处理逻辑测试2、账务处理对于银行APP来说，账务处理为核心系统功能，也是这类软件测试的重点，账务处理不仅涉及到资金，还与交易过程相关，测试过程中需要覆盖的点如下：a、  交易过程中账务处理是否正确；b、 差错账处理流程是否合理；c、  调账流程是否正确；d、 调账数据处理机制是否正确；在测试系统对账时，必须对账务处理流程有清晰的认识，对于账务处理过程中账务是否处理正确、是否出现错账、是否需要进行调账等案例都要重点覆盖。3、资金清算银行系统，通常行内系统与银行外对接的系统是独立开发的。对于中小银行APP，一般存在多个系统，如：银行核心系统，直销银行系统，资产方（TA）等，多个系统之间通过接口、通讯协议进行资金清算、数据交互等，因此测试过程中需重点关注：a、  构造或模拟金融产品交易流程中各关联系统的测试环境，验证交易过程中，报文转换是否正确，数据库中数据落地是否正确；b、 各关联系统功能如库存清算、报表生成、对账是否正确；c、  各关联系统之间资金清算流程是否正确；d、 大数据量场景下数据的处理是否正确。 关于直销银行系统接口设计和直销银行系统接口设计方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 直销银行系统接口设计的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于直销银行系统接口设计方案、直销银行系统接口设计的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。