2015年11月28-29日，备受关注的“北大CIO班十周年年会暨首届中国行业互联网大会”在北京大学与宽沟会议中心隆重举行。29日，互联网+金融分论坛在宽沟会议中心也如期召开，来自金融行业的资深专家、企业代表和CIO优秀学员们出席了此次论坛，人才济济，共聚一堂。就金融行业在互联网大背景和新时代信息技术的影响下，进行了最新的技术交锋和很有价值的业内经验交流。腾讯公司架构师、第二届北大互联网CIO-CTO班学员熊普江，就主题“浅析互联网金融技术架构设计”发表演讲，以下为演讲实录：
各位金融的大拿，大家上午好。我跟大家分享一下关于互联网金融技术架构方面的一些设计考虑。在讲之前，我想先发一个微信红包。刚才的这个抢红包应用实际上就是互联网+金融的案例，即个人小额转帐的变种。它跟将个人小额转帐与我们传统发红包结合起来了，是一个非常好的创新的应用。
互联网实际上正在重构整个金融行业。我们知道传统互联网有这样几个特点：开放、平等、高效、共享。但是互联网到发展到今天，特别是智能手机的普及，它具备了一些新特点：首先是移动化，随时随地可用，很方便。刚才百度的朱同学也分享这个大数据，产生了非常多的应用场景；由此更可以针对个性化来进行一些创新；还有一个是智能手机这个移动终端，也使得我们时间与事务处理都碎片化了，而且这个碎片化还将越来越严重。
金融的目标是资金时空分配效率的提高，需要解决信息不对称问题。而这恰恰是互联网所具备的特点与优势。
所以我们可以看到，互联网可以帮助我们的金融产品在结构方面，在供给方面，在竞争方面及盈利模式方面都会产生重构。
那我们来看到一下，当今主流的互联网金融业务体系是怎样的：
大家可以看到图上所列金融业务，有些是很早之前就有的，比如网络银行，最早只是借助网络完成传统线下的一些交易，但是那个都是粗浅。到今天，我们有P2P，有众筹，有各种各样的小额贷款，有2014年出来的微信红包，微信/支付宝转帐这些。还有很多，包括阿里也有花呗，京东的白条等等，这些都是相比较而言，都是原有金融业务在互联网下的创新。
支撑这些金融业务或者讲金融创新业务的，是下面这层基础设施。基础设施最下面一块“技术支持”在互联网里面不是新东西，这一块我们其他互联网业务都要用到，都有现成的建设。但是在这之上有比较关键的东西造就我们今天互联网上的金融变化、金融创新：一个是网络支付技术，它非常方便，使得整个金融交易的闭环形成。还有一个就是征信技术。金融行业征信风控是必不可少的，但以前在金融行业征信往往手段非常有限，只能根据片面场景的交易场景报告，而且数据缺少共享。但是今天就不一样，有非常多的数据，根据你各种上网行为，关系链等分析来做风控，而且非常实时；还可以做个性化定价。
所以，从金融业务体系上可以看到，技术方面的需求我们主要关注基础设施这一块，包括基础支撑技术、征信技术、支付技术方面。
这样，我们就可以提出金融业务的技术架构需求了。对互联网场景下的金融技术架构需求，我觉得有这几点：要符合监管的要求；数据不能丢失；这两个需要主要是跟金融有关，因为金融是国家经济发展的血液，它非常重要，涉及社会与经济的稳定，所以前面两个都是非常重要的前置需求。然后是跟互联网结合产生的需求，它需要：快速的响应，还有7×24小时的服务，还有10倍以上的扩展性。
先来看符合监管要求，指是我们架构设计的时候，要考虑到就是一些合规。这里边我列的一个例子，是台湾金融监管的一些技术条款。即在台湾，要从事互联网金融，就必须满足这些标准，包括服务器、防火墙要符合一些标准，包括防护策略与方案都有一些标准。所以我们在做架构设计之前，首先考虑这个行业有哪些合规的要求要满足。
刚才讲过，金融非常重要，涉及到社会与经济的稳定。所以在做架构设计的时候，在合规之外首要考虑的是数据是不能丢掉，也就是这里说的容灾设计。最常见设计要求是“两地三中心”，即要两个地方（城市），每个地三个中心（一主两从），也就是要多个副本。为什么要多个副本呢，这是涉及到互联网分布式容灾体系的一个理论：即多个独立的小概率事件同时发生的几率极低。有多个副本是独立的，本身副本故障率也比较低。有了多副本，还需要考虑的是故障的时候怎么切换，做架构设计时也要考虑。
然后架构设计上要看就是准确一致性。金融首先需要准确性，因为首先金融这个东西代表的是真金白银；而在互联网的交易里面，你不知道这一笔交易，是一分钱还是十个亿。所以必须保证不能错。这里也涉及到一个主要的架构设计原则，即：最多不交易，也不能错，这是一个要点。第二要点是说要强一致性，因为有多个副本。强一致性与多个副本是矛盾，这就需要考虑多个副本如何做到一致性，有必要单独针对这一点做优化。同样，特别要考虑当主点发生问题的时候，切换时一致性如何做。
刚才讲了互联网金融架构的一处重要原则是不服务也不能错帐，再有一个就是扩展性。刚才提到过，互联网业务有一个特点：传播快、海量、突发性。因此互联网金融业务同样有可能有十倍百倍的爆发。像腾讯的红包业务，节日的时候就是成倍的增长，如春节瞬间发红包的峰值就是平时的百倍以上。
如何做到这个高扩展性？首先在前端的网关接入也是分多个地方就近接入；在网关后面，采用集群机制，有需要就可以随时的横向扩展；有条件的话，还可以自动容量伸缩。这样架构可以保障业务不间断提供服务。除了这些考虑点，有一个重要的点，需要强调一下，就是适当地预留一个空间。为什么，因为金融的合规要求会导致一些限制，比如要单独物理上隔笼子。隔笼子就不那么简单了，所以在设计上还要考虑物理上一些未来可拓展。
接下来看性能方面的设计。互联网业务往往是海量的、还有突发性，这就是说设计要考虑怎么样达到优秀的读写性能。这里很多时候考虑使用缓存（KV/cache），使用高性能的硬件，比如说常用的SSD磁盘（我们有好几位同学在做这个东西）。再就是要尽量的解耦，各个功能与应用的关联性不要那么强，尽量独立，多分几个模块。单个独立的模块在解耦的情况下，会大大减少锁竞争，可以异步并行，不仅在性能也可以做到极致，而且关联性小的话，后面能够很快速的对这些独立的单个模块做调整，做升级。
还有一些耗时处理的解决，就可能要做一些函数级的优化，单独有针对性的对一些关键函数去改写它，提高性能。
这里我们看一个例子,是腾讯的TDSQL数据库高性能优化后的对比。我们有针对性的做了优化之后（包括函数重写），强同步的TPS可以做到9500。实际上，这个TDSQL数据库，现在支撑过日请求超过十亿次的业务。
针对金融业务的技术架构，安全的考虑必不可少。”无安全不金融“，就是要将安全贯穿在整个架构设计里面。架构设计的安全表现在几个方面：物理的安全，互连的安全，数据的安全和业务的安全。这里列了两个图，我们来看安全的着眼点：1、区域划分。有核心专区与非核心专区。应当将涉及交易写入的、以及涉及监管的设备与服务放入核改专区，这个专区是非常严格的管理，包括物理的隔离。
由于我们要兼顾架构的性能，有一些查询服务就不一定放到专区里，就是将非核心的业务抽取出来可以放到专区外面（非核心专区）。这样区分后，可以看到，与核心专区打交道的地方都要设定防火墙，非核心专区则只有一道防火墙。非核心专区的数据是实时同步的，但是它是只读，这样兼顾到了性能。在数据的保存上，我们要考虑加密及备份。而在业务安全层面，则在交易前，交易时，交易后，要做多维度的风控管理。
最后讲一点，互联网比较注重成本。所以互联网金融架构的设计也要考虑做到适当的成本。互联网兴起的特点之一是分享免费，或者说是屌丝经济也好，非常注重考虑成本，使用PC服务器、基于开源软件、采用分布式架构等等，同样互联网应用于金融也是这样。这个成本就是跟传统金融不一样，传统金融的IT架构都是一些大型机，当然现在可能有一些转变。但是目前来说我们国家也要求自主可控的底层架构，因此去IOE是互联网金融的显着趋势。
下面我就以微信红包的案例来谈谈互联网金融架构的设计。微信红包这个应用大家都很熟了，刚才也实际抢了一次，它的设计实际上包含我前面讲的几个方面。
别看发红包貌似一个非常简单的操作，实际上是技术层面涉及了很多很复杂的处理。我们拆细来看它有几个操作过程：发的过程是从银行拿钱出来，或者从你的零钱包拿钱出来，这个就是“支付“。支付完了之后发出来给单个人或多个人抢，抢的时候有很多逻辑：比如说是不是群里,有没有抢的资格，红包是不是已经抢完了等等。还有就是说，有没有外挂与作弊，是不是在赌博，这里就涉及风控在里面。然后是”拆”,就是将你抢到的红包进行入帐处理。最后还有一个消息通知,系统要告诉发红包的人，哪些人抢到了红包；系统要告诉抢到的人，抢到了某人的红包。
可以很明白地看到，红包会有非常高的并发。因为它的一个业务特点就是抢，会人为造成突发的峰值就非常高。这些业务需求与业务特性，架构设计需要满足。
我们来看看红包的每个步骤中，是如何考虑架构设计要点的。一是发的时候，即在支付的时候，很关键的一点，钱不能出错。但是这里也可能会有网络异常的情况，这个时候要有一些机制来保证，即使现在网络不通，在后面也一定可以是一样的。所以这个地方有做红包的状态检查，以便后续对帐与修复。
在抢的时候就是说你看有没有资格，这个就不需要精准一致。更关键的是可以抢，所以这个时候可用性、性能都要求高。
到拆的时候，这个数据又要求精准，要一定不能错的。刚才讲过这里，因为拆完之后是要放入钱到零钱包中去的。同样有可能网络失败，也要有机制保证数据最终一致。
最后是查红包的记录，这里也可以不完全一致。我们可以做异步来保证可用性与性能，就是你抢中红包了，但可以先不放在你钱包里。所以当你查零钱总额的时候，红包的钱不一定加上去了。但是当去查的一刻，可以触发同步更新数据，稍微延后了一点，但保证最后是一致的。而查的时候，数据必须展现，所以这个时候对可用性要求就很高。
大家可以思考一下，春节的时候那么大的突发量怎么办？基本上是平时的百倍。这里实际上我们就要考虑做一些柔性的处理。柔性处理包括说在这个时候进行限流，或者有一些非关键的操作就跳过去，或者说是异步化。举例而言，像现在平常发红包每一步都要做风控检查，在春节的时候这个操作就不一定那么敏感，可以适当的放过或抽样，这样可以使得系统有更大的支撑能力。
我们来看一下微信红包业务的主要模块。类似地，红包业务尽可能解耦，拆分多个模块。统一接入网关这一块是就近部署，确保能够多个地方接入，冗余且高性能。红包业务集群是指红包逻辑这块，主要负责拆，抢等操作处理。由于红包也是一个消息，以及抢红包的提示等等这些，也就是有消息总线与微信收发消息基础模块进行接口。接着关联接口是风控，比如判断是不是在赌博。到最后跟银行打交道的这个地方，支付核心事务处理集群，实际上就是支付。刚才讲过，交易数据与系统放在核心专区里面的，有一些查询的地方就放在一些非核心里面，大概是这样的。
我们大概过一下微信红包业务的架构。我们要发红包，实际有两个界面入口进来，一个是+号，一个是从你钱包进来。进入发红包界面，实际是发一个预订单。做过电商的都知道，有订单系统就可以实现业务逻辑了，因为按道理就是拿出这个钱来发就好了，但大家看到微信红包架构里设计了一个列表系统。为什么设计这个列表系统呢？这个其实很关键，设计主要基于2点：一是提高性能，减缓后端系统的压力。增加列表系统分开来，可以增加这层缓存，提高性能。由于发红包会有读写的扩散，列表系统也可以有效减缓后端DB的压力；要知道红包春晚峰值达到每秒高达10多万笔的交易。第二是确保数据一致性。我们有多个副本以确保可靠，这个列表系统可以有效增强多副本的一致性，必要时修复一致性。这个重点讲一下。
我们再来看一下多份列表系统的工作与切换架构。我们要查看有哪些人收到红包，就需要用到列表服务。通过列表服务可以查到我发什么红包，红包详情是怎么样。那么这里就要考虑红包数据不一致怎么办？刚才讲过是有修复工具的，在你下订单的时候，系统已经记录了修复所需要的信息。还有最关键列表系统查询失败怎么办？列表系统是冗余的，请求失败的时候它会做一些切换。这里就用到了我刚才讲过有“两地三中心“，其中的一个中心会先停掉架构图中的这个复制，同时联动地修改入口，用户基本上无感知。如果做的比较好的话，可以智能、自动的切过来、恢复过去。
最后稍微总结一下，互联网金融技术架构的设计，要考虑这几点，首先要合规，要准确要一致，再次是高扩展性、高性能与高安全，最后是成本方面。好，我的分享就到这里，谢谢大家。
抢沙发
