互金总结系列（1）-- 开篇

一、开篇

笔者从16年开始进入互金行业工作，算是经历了互金的开始(不算最开始)到结束。职位从高级开发工程师到后面的技术总监、技术负责人，负责了前后端分离、服务化、平台化等一系列项目。现在就来好好回顾总结下整个的技术演变过程。



二、LV0的系统图





上图主要目的在表述已有的系统和一些主要依赖的外部系统之间的关系，除了我们自己的系统外，我们还依赖了一些三方数据方来查询数据判断用户的信用和欺诈情况，登陆注册以及用于运营依赖的外部短信服务商和推送服务商，放款和还款依赖的三方支付公司。我们没有自建文件系统，直接使用阿里云的oss即可满足我们对证件、照片等的存储需求。oss文件为私有权限，仅供内部系统使用，数据安全是非常重要的。



三、系统部署图





这个是我见到的系统最开始的样子。一台jenkins用于发布系统，两台nginx高可用，配置中心选择了大家常用disconfig,RPC组件选择了微博的motan(那个时候的dubbo已经不再维护了，微博又在推这个框架，轻量、高效)，数据库选择了阿里云的单实例的mysql，缓存选了mem，主要服务于注册登陆、三方系统交互及热点数据，如果只是一些基础的KV使用，mem有更高性能（其实主要是选型的那位前辈程序员只会M没接触过R）。部署的业务系统有3个，服务管理后台的admin、服务app的api、以及当时只能充当一个支付网关的支付系统。



四、项目结构



这个大概就是那个时候的项目结构，一个项目，admin和api两个系统依赖相同的services，只要是业务逻辑都在这一层。现在看来这种结构问题多多，但当时就是这个结构。产生的原因很多，总的来说就是业务起步阶段，缺人、缺钱、缺时间。



五、后台系统的核心模块





admin主要包含下面几块：

1. review用于确认用户的信用等级和欺诈的可能性，即是否放款给用户。和三方数据服务商做交互。

2. review过了的用户会通过finance触发放款（手动、任务）。

3. 接下来就是借款到期之后如果用户没有通过客户端结清那么就进入到collection过程，这个过程会伴随比较多的短信和推送，和三方的短信系统做交互较多。



六、活动图



活动图会描述主要的一个流程，以及推出的节点。信审拒绝、放款多次尝试失败都会关闭订单，用户还款完成之后也会关闭订单。用户超过90天未还，就直接计入坏账，这部分会标记出来并做特殊处理，就订单的生命周期来说也是处于一种结束的状态。



七、状态图





状态有主次之分，主状态是核心状态。上图是当前订单的主要状态，每种主要状态都对应了多种子状态，比如等待还款的状态下包含了：未到期未还、逾期未还，等待信审状态的子状态下有等待第一轮审核、等待第二轮审核等。现在的很多业务都是状态迁转很清晰的业务，抓住了清晰的状态迁转路径不经对理解业务有很大的帮助，也在系统设计的时候帮我们更好的划分边界。其实这个是后来的主状态示意图，LV0的状态是什么已经找不到了。状态的设计的时候一定不能偷懒，用多个状态表示混合状态是千万要杜绝的，因为这种设计不可维护，后期业务上升架构升级的时候数据的迁移会变得非常痛苦。