2017年3月18日上午，由CIO时代学院与《金融电子化》杂志联合主办的“第七期金融CIO论坛”在广州顺利举行，本次活动的主题为“基于开源技术的金融软件开发”，吸引了近20位来自人民银行、中国工商银行、招商银行、及广州银行、东莞银行等城市商业银行的专家与CIO聚集于此，共同参与本次活动的探讨与研究。腾讯科技（深圳）有限公司架构师、第二届北大互联网CIO-CTO班学员熊普江在活动上带来了题为《浅析互联网金融技术架构设计》的主题分享。以下为演讲实录：


　　各位金融行业的领导还有CIO的同学们，大家上午好！很高兴今天有这个机会，与大家一起进行互联网金融技术架构设计的探讨。

　　现在我们生活中的使用的微信红包、微粒贷，都是互联网与金融的一个创新产品。就互联网的而言，具有我们起源于开放、平等、分享，这是其传统的特点。随着智能手机的使用，我们进入了移动互联网时代，它开始呈现一些新的特点。第一个新特点是移动化：举个移动手机的例子：大家是否尝试过有一天或两天不带手机，与外界沟通、购买支付、查询信息等等都做不了，肯定浑身不自在。实际上智能手机已成为我们的一个器官一样，对方面方面都产生非常重要的影响。移动化还带来更多的个性化的需求，很多交互随时可进行；同时移动化与个性化又使得我们的时间越来越碎片化。比如我们在工作时，可能隔几分钟就要看一下手机。移动互联网的应用又使得我们的碎片化越来越严重。同时由于我们使用的非常频繁，产生的数据就非常多。数据的充分使用方面对我们的各种业务都有帮助，这就是大数据。大数据更进一步，就是现在非常热的人工智能。有了数据后，我们很多的业务应用场景会创新出来，这就是移动互联网的新特点与影响。

　　移动互联网正对各行业的深度融合与影响，同样它对我们金融行业也产生非常重要的重构影响，包括在产品的结构、产品的供给、竞争以及盈利模式、场景上都会产生一些变化。例如，金融最关键的是要解决资金时空分配的错位，这本身就是互联网的一个特点，即解决信息的不对称。又比如另外一个重构影响：网络外部性，它指的是网络的价值在于其用户数量。当用户数量到达一定程度时，网络的价值会越来越高。网络外部性对金融的重构也产生巨大影响。

　　接下来我们就来看看，互联网金融的业务体系。

　　一、互联网金融业务体系



　　目前我们知道互联网已渗透到很多金融场景，包括在股权、借贷、保险方面都有一些创新和场景。以前也有网络银行，但那是在互联网刚出来时一个较初级的应用，实质是将线下的一些东西在网络上做交易。但如今不同了，目前基本上我们每个人随时随刻都可以使用金融的网络服务。所有的这些场景，包括我们讲的微粒贷、红包等，都是金融业务场景中的一些创新业务。

　　在这些业务之下，需要基础设施来支撑的。包括三部分，其中的技术支持是传统的IT，包括原先没有互联网时的一些IT设备。更能体现网络价值的部分是网络支付和网络征信。网络支付，特别是通过移动的支付手段，如支付宝、微信支付，它形成了一个非常好的闭环，使得我们各种交易都可以实现。还有一个网络价值是以往基于纸面的征信，每家银行都是独立的，比如你在某个银行中存了多少钱，做过多少次交易都是可知的。当然目前的央行会有一些数据对接，但这些远远不够。互联网的使用征信的维度与价值大大提升，如阿里巴巴，它有很多商品交易的数据能判断交易行为。腾讯有很多社交数据，不仅能判断具体某人的信用问题，还能够根据其结交的朋友、关系链也能判断这个人信用状况。如果他周围的人都讲信用的，那么这个人的信用会相对比较高一些。因此，基础设施的支撑在互联网金融这块体现出另外两个价值，即支付的便利性与征信的价值。

　　二、金融业务技术架构需求

　　互联网金融也是金融的一方面，属于金融的一个创新或一个融合。第一需求是金融业监管的需求，那是必须要符合的，因为它本身便是金融的一块。第二需求是数据绝对不能丢失或错乱，由于我们无法得知丢失的这笔交易是一分钱还是一个亿。所以对基础架构提出的要求就是数据绝对不能丢。金融是社会经济运转的血液，非常重要，如果你要从事金融行业，上述两个要求是必须的。之后便是互联网所带来的需求。原先我们的银行可能不会7×24小时一直提供服务，互联网要求金融业务每时每刻都可以服务。

　　互联网用户与变化都是海量的，随时有可能造成突发。如事件、秒杀类的活动会瞬时间带来非常大的用户量。这要求我们的架构能否支撑一个十倍以上或百倍突发以及伸缩支撑能力。当然还有一些其他方面，是否能够快速的响应服务。以前有个例子，如吞卡了要找银行处理可能要隔好几天，而在今天的互联网时代可能就不太合适了，很多服务都需要及时响应。还有如何使用开源，如何使得运营成本更低廉。互联网本身就是诞生开放、开源技术的支撑，这也要求我们将低成本的需求融合到互联网金融的架构设计中。

　　1.符合监管要求



　　这里列出的是台湾互联网金融行业的要求。这些监管要求明确了防火墙的策略，网络设备的安全性等技术标准等，这些是必须遵循的。假定我们要去到台湾开设互联网金融业务，合乎这个监管的要求。我们设计互联网金融业务架构，首先要看这个行业的监管要求，并分析如何设计达到这些要求。

　　2.数据不能丢

　　这是非常关键的。其中涉及到技术架构设计时一定要考虑容灾和可靠性。一般的设计我们都做两地三中心。例如台湾规定，即使是在一个城市，两个数据中心要相距30公里以上。当然像腾讯的一些金融业务，如财富通或微粒贷等业务，都是至少放在两个城市。在每一个地方会再设三个中心，一个是在线服务的，一个是备用服务的，一个是发生灾难时恢复的。基本是这三个中心的设计。

　　3.多副本设计

　　在考虑可靠性时候一般要进行多副本的设计。多副本的概念包括多套设备，解决单点。如果有多个副本的话，基本上同时发生故障的概率是微乎其微的，这就是多副本的冗余。有多副本便会涉及到某个副本间发生问题时如何切换，这些都是我们在做容灾设计时需要考虑的，不仅是中心之间的切换，也包括两个城市之间的切换。

　　4.高一致性设计

　　多副本同时带来另外一个麻烦，即多副本间的数据如何一致性。这个挑战是非常大的，特别是有几个地方有多个副本。在金融领域我们需要遵守一个原则是即使不服务也不能错账。即这个服务哪怕不提供，数据不能丢，或者不会产生错误的交易，这是一个原则。在这个原则下再考虑如何将多副本做到强一致性，其中有很多技术手段的优化。

　　除了即使不服务也不能错账这个首要原则外，也要设计尽量缩短不服务的时间。当有故障时我们能在很短的时间内能切换过来，这也是提高服务水平的设计，是高一致性设计时要考虑的地方。

　　5.高扩展性设计

　　除了强一致性设计外，我们还要考虑高扩展性。因为互联网有一个特性是并发和大量的用户会瞬间涌进来。如红包业务，在节日期间是非常明显的。春节期间基本是平时发红包数十倍的量，也可能就在那几秒钟，因此在这种情况下如何样快速支撑下来，扩展性就很重要。架构上考虑做一些集群，甚至想办法做自动扩容，而在业务量下来时还可以自动缩容。

　　高扩展性与符合监管要求等架构设计往往是矛盾的：如提供多个符合监近要求的数据中心，这个机房必须要独立，而且要隔断，要有门禁系统，要有防火墙，还都要用笼子围起来。这些都限制扩展性。这时，金融行业考虑扩展性时要预留一些空间。一般在设计时会考虑未来三年的增长，将这个空间划出来，这也是高扩展的一个考虑。

　　6.高性能设计

　　就互联网应用而言，好在大多都是基于开源的技术，这里会看到有MySQL等，但性能不一定符合我们的要求，我们要做的便是深度的优化。如我们使用考虑将数据放在内存中，其性能可能会提升。同时，我们尽量使用一些高性能硬件，如SSD存储盘，这也能提高读写性能。在软件方面，将每一个模块解耦，尽可能做成无状态，即一个微模块、微服务，这样它们之间相互的关联比较小，每一块可以做到最大的性能。做一些函数及深度的优化，即将一些函数根据自己的业务特点进行优化。例如，腾讯的一个TDSQL数据库，成功应用于微粒贷，做了优化后其性能比其他同类的产品高了很多。

　　目前这个数据库已可处理超过100亿以上的账户，每天请求超过10亿次，零错误。这是在高性能方面，我们要做的一些高性能考虑。

　　7.无安全不金融

　　当然，金融方面还有一个方面便是安全性。这个安全性要无时无刻记在脑海。主要从以下四个方面考虑：

　　物理安全，进到这个区域都是专用的，如专区的隔离。

　　互联安全，所有与金融数据打交道的地方基本都要设置一个防火墙。

　　数据安全，所有保存在我们介质上的数据都是加密的。

　　业务安全，我们要看在事前如何判断这个人的信用和行为。他在操作过程中是否有恶意操作或不正常的操作。事后要对账，是否莫名其妙出现一条数据，这些都是有问题的，这些都是业务的安全。



　　在具体划分时会根据业务会放一些，如核心专区是所有的数据库、中间件都会放入，核心专区是有两层防火墙的，前面的业务也是有防火墙的，后端与其他银行及其他非核心专区打交道也是有防火墙的。非核心专区有一些只读的业务，这个区域主要考虑其性能提升，由于涉及到只读操作，前端加一个防火墙，性能可以做到非常快。当然与外面的一些对接应用都是普通区，可以做一些云化。在数据、业务等方面做一些风控便是无安全不金融，即安全非常重要。

　　8.适当的成本

　　做架构设计时还需考虑适当的成本。在传统金融行业，原先都是用一些大型机、专有的设备或IOE架构，互联网本身，从其一开始便考虑低成本，包括分布式的用PC机来做，用开源软件，Linux或数据库、webServer等等，都是使用一些开源软件做一些分布式的架构。因此在这个架构中，互联网的架构会考虑使用一些开源的软件来实现金融等级的服务。

　　三、实际案例

　　微粒贷是一个非常好的产品，在QQ钱包和微信钱包里面都有这个服务。微粒贷的好处在于操作非常简便，不需要填很多表格及很多操作，它为用户带来的体验和实际需要是非常多的。在金融意识逐渐苏醒后，大家对借贷对这个需求也越来越强烈。微粒贷到目前为止其风险都控制的很好，我们使用了大数据分析，邀请用户使用这个服务。

　　同样的道理，在设计之首先要先了解这个业务的需求和特性。微粒贷的业务即主打个人的小额周转。可能用户临时需要500元、5000与元或10万元的需求，但不需要固定的借款时间。如果我们在银行借钱，需要借至少半年或一年。而微粒贷做到了按天算。今天借明天还只收一天的利息。这是根据互联网的特性，可以设计很短的时间的借贷场景。无需填很多的表，因为绑定银行卡便能够识别用户的身份，不需要超长的审批，只要是受邀的客户，便可以借钱的，它已经做好了风控。当然这还是受银监会监管的一个产品。同时我们要考虑到互联网的特性，要如何保证其实时可用，保证其连续性。

　　基于这些业务特性，架构上有三个阶段的演进。最早是我们使用现成的组件进行服务搭建，之后是提高业务的连续性和可用性，再后是智能化的运营。即未来的自动化、智能运营的方向是一致的。



　　了解业务的需求和特点后，我们架构设计上会考虑涉及的主要模块：第一是要考虑用户的体验，体验接入要非常快，因此有一个统一的接入网关，可以放在各个地方，将各种运营商的链路连接起来。多地部署、就近访问。第二是业务接入的逻辑，当遇到一些不需要、不敏感、非关键的查询业务时，可以直接在业务接入逻辑中将其去掉。将一些只读的数据放在缓存中便可以操作。再往下一层是核心业务，核心业务有比较严密的逻辑和安全的操作考虑。这些核心业务包括借款、还款及各种操作。这个核心的业务逻辑中会用到一些公共的服务，如风控，风控可以是平台级的服务，所有的业务都可以对接这个风控，包括反欺诈。那么财付通的基础服务包括一些对账、清算等，所有的日志流水不仅在其业务中有，在财付通也有。由于微粒贷借贷要从银行中取钱，还要将钱划到银行卡中才能提现，必须要通过传统的银行卡才可以取钱，因此这里还有一个银行划拨回款的通道，还款时也是通过这个卡。最底层是核心DB的存储，存储用户的资料及用户的交易流水、交易数据。



　　结合业务主要模块，我们设计出第一代的业务架构图。TGW统一接入网关就直接拿来用了，CKV是一些缓存的服务，只读的这块也可以直接拿来用。后面的路由，因为我们讲过有两地三中心这样的一个设计，也是直接拿来用的。后面是核心的业务逻辑，如借款、还款、查询等，这些业务都要接风控、财付通还有银行的地方。这个设计能很快的实现业务上线，但这个业务架构的高可用性方面和业务连续性方面是有一些问题的，包括性能方面也有一些问题。比如用户请求到IDC1可能穿透到另外一个IDC2进行这个操作，因为整个是一套系统。而且这些业务有可能是不是独立的，可能是混在一起的，这也是一个问题。包括数据库也是一个单点，都使用了只有一个核心的数据库，这是初期上线时的一个架构。这个架构会有一些穿透和性能，稳定性和可靠性就不能满足要求，等级比较低。



　　第二个版本的架构做了两个重大的改进，一是将其独立，将很多业务的模块解耦，不要与其他业务在一起，都是独立的一个部署。第二个改进便是SET化。一个IDC中有一个完整的服务，另一个IDC是另外一个完整的服务，这些公共的服务做成一些接口和模块。这样每一个交易进来都很快地在本地便可以完成服务，且本地都是有数据和处理的。下面的数据库也是高可用的设计。很多时候在本地便可以完成，当数据不一致时，它会降级到这里来查询服务。第二个架构相对比较完美。多副本、高可用、安全各方面均可达到相对较好的等级。

　　最底层的数据库对业务是最关键的，即数据如何保证其一致性和架构的容灾。既要做多副本，确保高可用性，但又要设法保证数据的一致性。这里头使用了一些自研的性能优化，使两个数据库之间能够很快速同步。还有一些业务甚至可以跑在备机上，如说查询业务，这里有一些性能优化与同步优化。

　　四、总结

　　做互联网金融技术架构的设计主要考虑以下七点：一是合规。二是高一致性，数据不能丢失不能错。三是高可用，大部分情况下都是可用的，即7×24小时都是可用的。四是高扩展，能支撑海量的并发、触发。五是尽可能的解耦，提高性能。能够快速的响应用户的操作。因为在移动互联网时代，人其实是越来越没有耐心的，因此一定要很快地响应用户的请求。六是安全性，确保每一笔都是安全的。七是尽可能使用一些开源的架构、开源的软件，以实现功能和应用。

　　今天的分享就到这里，谢谢大家！
第三十五届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。