首先，做业务拆分的时候，可以按照基础服务和业务服务先做一个大的服务的拆分，然后基础服务又包括无业务型的基础服务和有业务型的基础服务，这些系统非常明显的跟其他的系统没有太大的关系。业务型基础服务的特点就是跟业务之间的关系很小，就是这些系统跟业务系统之间的关联关系只是主键和外键的关联关系。
宜人贷可以天然地拆卸分成两大系统，一个是贷款业务，一个是理财业务，贷款业务可以拆卸成后台、Web、合作渠道，这个系统之下会有一个基础服务，就是提供一些基础服务和接口的一个系统。
基础服务拆成了两部分，一个是基础服务的进件，一个是服务售后。然后拆分过程中他们又发现一个问题，理财和贷款有两个业务怎么拆都拆不开，就是撮合业务和债券关系，这种拆不开的可以单独再提升一个功能服务来提供服务就可以了。
拆分的系统看起来好像很容易，拆分的办法孙军总结了如下几个：
第一，适当冗余，冗余确保数据库依然可以关联查询；大部分时间并不是做一个全新的系统，而是在原来系统之上做修改，这个时候可以做一些冗余，保证他们可以不修改。
第二，数据复制，但必须保证数据归属系统有修改和发起复制的权限；这个比较适合于刚才说的全局配置，比如说宜人贷的所有公司都会有这么一个集成表，记录了全国的区线，这些在每个系统中都会用，不一定每个系统都以接口的形式调用他。可以在每个系统里面都冗余。
第三，就是如何验证数据库——并不一定非把它拆分成两个验证它，可以一个数据库上建两个帐号，这两个帐号分别的权限指向拆分之后的表，可以通过帐号直接验证拆分效果。
第四，提前规划服务，拆卸之前确定一下区分读多、写多服务，区分快请求、慢请求服务，不同服务需要分开部署。
最后，同一数据不能由超过一个以上的系统控制，同一系统不能由超过一个以上的负责人负责。
4.0版本——云的展望
做到以上几点， 3.0版本已经做的差不多了，但是后面宜人贷依然还有很多要做的，4.0版本是不是要做云平台，异地部署的方案，表很大的时候是不是要做垂直拆分，去IOE或者使用Docker快速部署等等这些，这些其实都是我们做4.0或者5.0将来要考虑的事情。
三、宜人贷理财系统的优化
合理预估流量——强一致与最终一致
图中这三个界面分别为首页、列页，详情页。
首先要合理预估流量，区分出什么是强一致性的流量，什么是非强制性的引流。
评估方法一：平日PV*(24/热度时间)；
评估方法二：热度时间内在线用户数*平均每人操作次数/热度时间。以宜人贷理财端为例，他们在高时期有2万人，然后平均做20次操作，在2分钟左右基本上就把所有的债券抢光了，翻番出来大概是3000多次每秒。
然后要区分什么是强一致，什么是最终一致，这两个流量分别是多少。强一致这个数据必须是最准确的数据，这个数字不能用读写分流的形式保留，必须是正确的数据。最终的数据就是时效性没有那么高，只要最后的结果是一致的就可以。
20次操作包含：注册、注册验证码、登陆、解锁手势密码、首页、浏览产品列表等等这些操作，这里面其中有一些比如说产品余额、生成订单、支付短信、付款，这些都是非常强一致的要求，这个大概占每个操作数的占1/7左右，翻算出来是约500次/S。