UPYUNOpenTalk第二期：挖财架构设计的6大要点《挖财的互联网金融技术探索》，王富强重点分享了目前外财架构设计的6大要点：1.系统层次分离从大数据的角度出发体系上，外财主要做四个纬度的事情，第一个是会员中心，挖财有自己的会员体系，第二个是现金流，第三个是风控中心，第四个是产品中心，最后一个是一些清算和结算。挖财在所有系统上做了一些适度的关键点分离。在这个层面上，SOA（一种构建分布式计算的方法）是必不可少的，当系统达到一定的规模时，就会迫使我们往这个方向走。在现金流系统中，由于现金流数据的特性不同于一般数据，会随着时间的纬度不断上升，不能简单的以用户来划分，所以从用户和用户两个维度来挖钱时间表独立的现金流。为了保持数据的一致性，挖财在选型时采用了Scala语言。在系统体系中，随着数据量的增加，中间件会遇到瓶颈，所以挖财在后面的服务方向是专门针对服务进行优化的，在应用层对数据层做了一些屏蔽工作，将它们分开。除了在技术上划分边界，我们还会划分责任，发挥各自的优势。挖财在这一点上强调前后端分离。最早技术上挖财只做异步调用生成，有一些保护级别的规范，但最终前端的事务必须完全由前端来完成，这样会提高前端的工作效率和后端作为一个整体。2、消息传递的分离主要是在系统层面的隔离和定义。隔离之后，需要系统层面之间的通信和互通。只有在系统形成之后，才能产生更大价值的服务。挖财采用消息传递机制来解决系统互通问题。Remoting（分布式处理方法）用于消息传输的方式。说到remoting，更多的是和RPC相关。互联网的大部分技术系统都是同时用多种语言开发的。RPC是一种跨语言通信标准。基于服务的工作基本上会参考BUBBO服务框架。鉴于金融系统对高并发没有特别高的要求，所以采用HTTP协议实现挖矿。3、异步处理在通过消息传递解决了系统互通的问题后，为了尽量减少事件对系统的影响，所有地方都尽可能实现异步化。挖钱，Async的一个典型应用场景当移动端向服务端发起的请求直接达到最大时，通过异步处理形成一个完整的异步闭环。数据处理完成后，将数据推送到移动端。在这个过程中，可以在服务端进行一些交互，也可以在本地做一些事情。在这个环节中，Kafka和Akka技术在挖矿方面应用最为广泛。Akka是Actor模型在JAVA/Scala平台上比较成熟的实现。Akka本质上是没有限速的，所有的消息都可以实时发送，一不留神就会导致处理节点的数据崩溃，所以我们在使用Akka的时候首先要处理的问题是当前限制。比如ACK机制，用来缓解后端处理的压力。4、信息存储，与其挖钱不如不做空。对于信息，现在采用“不多不短”的原则，保留每一个改动，而不是原来的直接覆盖，做到有问题，有迹可循，不至于迷茫，因为你找不到一些信息。在消息链路中使用Kafka也考虑到了这一点。我们最看重的是Kafka的多副本数据存储能力。除了Kafka，我们也进行了一些小实践。在维护方面，如果核心数据发生变化，以前是直接覆盖，现在核心字段都分配了版本号。后面有什么问题，可以根据时间找出来。比如一个actor崩溃了，我们可以通过Akka的创建函数随时返回，这样就不会有消息丢失，数据丢失的问题。总之，挖钱技术希望有自己的时光机，出了问题可以回滚。5.系统安全对于金融系统来说，安全是一个比较重要的问题。在金融系统中，ATBS已经是标准。为了抵御外部危害，首先尽可能设置门槛，这样可以降低技术成本。在技??术层面，将构建基础防御层，如网络防火墙和应用防火墙。在业务层面，借助第三方的帮助，在反欺诈层面利用同盾科技的技术进行挖矿，同时配备风控团队进行人工干预。在拦截层面，为了保证隔离，不希望Kafka接管一切，如果集群出现故障，集体会受到整体的影响。所以希望将应用的隔离部署在物理上，由相应的集群负责相应的业务处理。6、存储冗余从分布式存储的角度来看，传统互联网更多的是从CP的角度考虑问题，往往弱化存储，但是对于互联网金融企业来说，需要将存储数据的一致性提升到**位。对于核心交易系统，为了避免MessageQueue的弱点，采用简单灵活的Multi-write来解决数据一致性问题。从技术架构上看，挖财希望最终形成这样一个完全由事件触发、以时间和数据为流向、充满弹性机制的Reactive（响应）系统。
