理财平台架构分析

　　一个理财平台可以从不同的维度来看。对于一个消费者来说，最宏观的看法，P2P公司的理财平台相当于一个中介，一边用于对接用户，一边用于对接产品提供商。这个中介系统负责用户和产品提供者之间的交互。对于一个P2P理财公司来说，最核心的两个模块是财务账目模块和运行模块。其他的模块都是基于这两个核心来扩展的。

把登陆模块单独拎出来，是为了日后进行登陆安全控制；追踪客户记录进行大数据分析；
概念：结算和清算，清算是两个系统之间，如P2P公司和银行之间，是发生在两个独立系统结算之外的。结算则是本系统内的一种账务计算，它只限于本系统。

什么是好的架构系统？看上面的业务架构图，它严格的定义了各个模块的边界。对于一个需求，我们写在哪个系统的哪个部分，都唯一确定，而不会产生模棱两可的状况。码农所做的工作就是在相应的格子中填充代码，完成相应的单元测试。架构的设计要解耦，比如一个客户购买P2P公司的一款理财产品，他在H5端下单付钱，P2P公司的理财平台要对接到银行，从客户的银行卡扣钱，银行扣钱成功要通知P2P平台，这个通知很大概率是收不到的。这就涉及到了消息传递的同步和异步。我们先举个例子，A在微信上向B发了一条微信消息，A立即接受到了发送成功，但是此时消息只是到达了A服务器，(假如A服务器有足够策略保证把接受到的消息发送到B服务器，再递推到B客户)。这就是简单的同步和异步问题。如果你问我同步好？还是异步好，一般公司的是先采用同步方式，后采用异步方式，因为异步方式需要单独的开发消息传送机制。而且是当数据体量特别大的时候，才去采用异步方式来提高效率。

OP平台的全称是Operation Platform，看上面的图：

图的最左侧，运营平台面向的对象是：产品人员(录标)、结算人员、客服人员和管理人员(测试人员，开发人员等)。
运营平台依赖于财务系统、会员系统、交易系统、合同系统。客户和平台之间的每次交易都一份合同，当然是电子合同。
OP系统要做的工作是途中所标注的那些模块，这是技术研发人员向管理者和运营人员、市场人员、测试人员开放的接口。

如上图所示，是P2P理财平台的表结构的设计：

大致分为七大类，当然随着项目的运维后续还会陆续的有扩表(尤其适合后台管理部分的表结构)，粗看表结构的命名规则包括有：T_、P_、OP_、相应的分别表示Trade(交易平台)、Produce(产品平台)、Operation Platform(运营平台)。
在变量的字段定义中，主要使用的类型只有：varchar(128)、char(1)、date、number(15)这四种，稍微提及一下，char的长度是固定的、varchar的长度是可变化的；char的效率比varchar效率高<这也是标记状态的字段一般均使用char(1)来定义数据类型>，因为char初始化时已经在硬盘上申请好了空间，而varchar在使用时才分配空间，所以使用时要先分配空间，故而效率低;date是日期类型，具体显示成什么样子那是显示问题，它的本质上还是一个日期类型。number类型是存数字的，varchar和char毕竟存的是字符串；当然了number(5)表示存5位整数，number(5,2)表示存5位数，其中2位小数。<如果表的主键用NUMBER类型，在用“SELECT * FROM TEST WHERE ID = xxx”这种类型的SQL语句时比之VARCHAR类型的要快？因为VARCHAR类型如果较长的话，数据库将会逐个逐个字符比较，这样，它找出该条记录的速度比较慢。>
重点看一下会员表，因为任何一个系统：电商平台、互联网金融、在线教育、O2O都需要保存用户的登陆记录。T_Login_Token表，token的原则是注册或首次登陆成功后下发，每次登陆成功后修改，同时这个表中还记录了登陆的设别手机型号，序列号等详细设备信息。T_Login_History对登陆历史做了记录，以后可以用于用户行为监控，以及万一出现金融事故之后，可以查找线索。另外还有对接第三方的短信验证表、银行卡表、身份证验证表。

上图的表示详细的表结构，应该蛮详细的，尤其是对设备号的跟踪，登陆token的记录等。

接下来，再来回顾一下系统依赖图，对于用户来说，他们的视角是ios、android、pc、h5四个入口，这四个入口用于对外展现公司的产品目录，大部分情况下他们的交互是与后台通过接口来交互，也有少部分情况需要不同的设备之间进行交互。对于后台的交互，Controller对于相应的请求request，做出相应的业务逻辑处理后，封装到response返回给四个终端。

上图所示，定义的接口规范是用于终端和后台进行的数据交互，最常用的可以使用jQuery封装好的ajax来获取请求。下面是一个Android客户端需要调用H5的时候定义的一些公共接口文档。