前面一篇主要说了金融系统建设的必要性，这一篇我们主说金融系统的整体平台架构。
金融系统从业务来讲，主要分为三个部分：贷前、贷中和贷后。
贷前主要指：客户的获客、客户的额度审批、合同签订。
贷中主要指：客户的融资申请、财务放款。
贷后主要指：贷后客户监测、回款催收、资产管理等。
但是如果系统足够大，涉及到平台的概念，它又会拆分为各个子系统。每个功能模块就能够形成单个独立小系统，再加上底层平台架构，再增加了很多的子类系统。
从业务考虑
CRM：营销获客，意向客户的信息收集，其中包含了各个渠道和来源（微信端、APP端、代理商、自我开发等）。
审批系统：结合流程引擎进行客户风险和其他维度的审批（风险审批、放款审批、资料更新审即各类办公化审批）。
各业务系统：包含各个业务场景（小贷业务、企业贷款、保理、融资租赁、保险分期等各类金融场景）。
资产管理：涉及客户的催收，委外管理等。
财务系统：财务收款管理、账单管理、银企直联等等。
报表系统：数据集中化，统一报表。
下图为我们目前的业务模型的系统架构：
今天我们不讲小型的系统，我们讲金融平台的设计和架构。
从平台系统本身架构而言，不可缺少的包含：
系统管理：主要包括系统的角色管理、权限管理、菜单管理、站点（子系统）管理、表单管理、定时任务管理、日历管理、数据字典等等。主要是平台底层工作。
UCenter（用户中心）：从平台而言，或包括多个站点，例如：代理商站点、普通客户站点、核心客户站点、后台站点、微信端、APP端等等、API接口端；按照业务也会分为多个站点，例如电商会有团购站点、秒杀站点、活动站点等等；所以考虑系统的通用性，将用户中心进行的抽离，形成单独的用户中心。其主要作用是集中化对用户进行管理，目前我们的权限还建立在系统管理中，在逐步的升级过程中，会将权限控制下放至用户中心。
文件中心：跟上面是同理的，文件会涉及多个系统进行访问，如果文件处理的场景更加复杂化，访问更加频繁。就需要考虑将文件系统切换到OSS（七牛云、阿里oss系统等），就是如果我们在这里进行了抽离，对于后期的升级会更加方便。金融平台中，因为风险控制的问题，会要求很多的附件信息，在我们平台中单个客户的附件可能都会超过1G的资料，所以单独的抽离是非常又必要的。
消息中心：消息中心主要用于，系统之间的通信、站内通信、邮件通信、短信通知、微信通知、钉钉通知等。
综合而言，我们对系统分块使用了两个维度：业务型系统分类和技术型系统分类。
下图为总体的技术选型
