UPYUN Open Talk 第二期：挖财架构设计中的6大关键点

在UPYUN Open Talk 第二期“移动时代互联网金融架构趋势”的技术分享中，挖财首席架构师王福强带来了《挖财的互联网金融技术探索》，王福强重点分享了当前挖财架构设计中的6大关键点：

00#系统层级分离

从大的体系来讲，挖财主要在做四个纬度的事情，第一个是会员中心，挖财有一套自己的会员体系，第二个是现金流，第三个是风控中心，第四个是产品中心，最后是一些清算和结算的东西。
挖财在所有的系统上都会做一些适度的关键点分离。在这个层面上SOA（构造分布式计算的方法）必不可少，当系统形成一定规模后也会逼着我们往这个方向走。

在现金流体系中，因为现金流数据的特性和一般数据特性不一样，它会随着时间的纬度不停往上涨，不能单纯按照用户来划分，所以挖财从用户和时间线两个维度的区分现金流。为了保持数据的一致性，挖财在选型的时候采用了Scala语言。在系统体系里，中间件会随着数据量的增长而遭遇瓶颈，所以挖财在后面的服务化方向就专门针对服务做优化，在应用层针对数据层做一些屏蔽工作，将其分离开来。
除了在技术上做边界分离，我们还会对职责进行一些划分，让个人优势得以充分发挥，挖财在这一点上强调的是前后端分离，最早挖财在技术上只是做异步的调用，生成一些protect层面的规范，但最终前端的事情还是要完全由前端来做，这会使得前后端的工作效率得到整体提升。

01#消息传递
上面的分离，主要是在系统层级的隔离和界定上，隔离后还需要进行系统层级间的交流互通，形成体系后才可以产生更大价值的服务。挖财采用了消息传递机制来解决系统互通的问题。
在消息传送的方式上采用remoting(分布式处理方式)，提到remoting更多的还是和RPC相关的概念，互联网大部分技术体系都是同时采用多语言开发的，RPC是跨语言的通信标准。基于服务做的工作，基本都会参考使用BUBBO服务框架。鉴于金融系统对高并发的要求没有特别高，挖财采用了HTTP协议来实现。

02#异步化处理
通过消息传递解决了系统互通的问题后，为了尽量减少事件给系统带来的影响，在尽可能所有的地方都走异步化。

当移动端对服务器端发起的请求直接达到百万级别以后，通过异步处理的方式形成一个完整的异步闭环，等数据处理完后，将数据Push给移动端。在这个过程中，服务器端可以进行某些交互，也可在本地做一些事情。在这个环节挖财使用得最多的是Kafka和Akka技术。Akka是Actor模型在JAVA/Scala平台上的一个比较成熟的实现。
Akka本质上没有限速，所有的消息都可以实时发送，这就会导致稍不注意就会导致处理节点的数据崩盘，所以我们在使用Akka过程中第一个要处理的问题就是限流。比如通过ACK机制缓解后端处理压力。

03 #信息存储，宁多勿缺
挖财对信息这一块现在采用宁多勿缺的原则，保留每一次的更改，代替原有的直接覆盖，这样使得出现问题的时候能有迹可循，不会因为查询不到一些信息而一头雾水。
在消息传递环节采用Kafka也是考虑到了这方面的原因，我们最看重的就是Kafka的多副本数据保存能力。
除了Kafka,我们还进行了一些小实践，在维护方面，如果核心资料变更，以前是直接覆盖，现在是核心字段配一个版本号，后期出现任何问题都可以根据时间将操作找出来。比如说Actor崩溃的话，我们通过Akka的创建功能可以随时回去，不至于出现消息丢失、数据丢失的问题。总之挖财的技术希望能有自己的时光机，出了问题可以回退。

04 #系统安全
对金融系统来讲，安全是一个比较重要的问题。在金融系统来说，ATBS已经是最低标准。为了抵制外来危害，首先尽可能的设置门槛，这样可以减低技术成本。
在技术层面，会构建基本防御层，比如网络防火墙，应用防火墙。
在业务层面，借力第三方，在反欺诈层面挖财使用了同盾科技的技术，同时配以风控团队进行人工干预。
在拦截层面，为了保证隔离性，且不希望Kafka在接管所有东西后，这个集群出现问题，这个集体整体会受到影响，因此希望从物理上部署应用的隔离性，相应集群负责相应的业务处理。

05#存储冗余
从分布式存储的角度来讲，传统互联网更多在CP的角度考虑问题，往往是将存储弱化掉，但对互联网金融企业来讲，需要将存储数据的一致性提高到第一位。对于核心交易系统，为了避免Message Queue的弱势，采用了简单、灵活的Multi-write来解决数据一致性的问题。

挖财从技术架构上来说，希望最终形成这样一套完全靠事件来触发的，以时间和数据为流向,充满弹性机制的Reactive(响应)系统。