系统分析过程—确定关键技术方案的可行性

    系统分析过程到底该做什么，仅仅是产出一份系统分析文档吗？个人认为，系统分析的最重要的产出之一就是确定关键技术方案的可行性。
    对于一些关键技术的选择，首先肯定是先选择已成熟的方案，避免重复发明轮子，但要注意的是，没有一种技术是适合 所有场景的，成熟的方案不一定适合解决当前的需求。如果在系统分析阶段不把这个问题确定，到编码阶段突然发现之前分析设计的方案不可行，那么就会造成设计变更，增大开发和测试的工作量，给项目会带来巨大的风险。
    下面以最近做的一个需求为例来阐述：
    现有有一个短信网关系统，该系统是CP与各运营商交互的中介，所有的下行和上行短信都必须经过该系统。 由于该系统产生的短信流水的量很大，亿级别，所以之前已经对DB进行了分库，分为三个库，每个库一张流水表，采用随机入库的算法。即使进行了分库，现在每张表的数据量仍然达到了亿级，而且还只保留最近三个月的数据，三个月前的数据由DBA的定时脚本进行清理。在后台专门有一个查询页面，供客服小二根据手机号和时间来查询短信流水。
由于业务的需要，客服小二提了一个查询需求，需要查询6个月内的短信流水。有人可能会问，这种查询需求为什么不交给数据仓库去做？原因是依赖数据仓库查询的过程太慢了，想一下这个场景：当一个客户打电话 给小二，咨询是否给他发过短信，但小二无法自己去查数据仓库，所以他需要走流程，提需求给数据仓库的人，运气好，数据仓库的技术人员会马上帮你查，运气不好，可能要搁很长时间，此时客户不骂你才怪呢。所以，数据仓库查询是不适合这种马上需要知道结果的查询场景，它一般适合用来做离线的批量统计对账。
    所以，现在DB就需要保存6个月的数据（原来只保留3个月），意味着每张表的数据量会翻一倍，那么这个查询肯定会非常慢，有必要进行分表了。目前公司已经有了一个成熟的分库分表框架，只要配置分库分表的规则就可以直接采用，好像这就是最佳解决方案，当时需求到我这边的时候，定的方案确实就是采用这个。但大家没有弄清该系统存在这么一个现状，该短信流水已经采用了随机分库的规则，而且流水的生成是放在一个事务中的，该事务已经关联一个datasource，而如果采用该分库分表的框架，则需要将该流水对应的DAO关联到另一个datasource上，现在矛盾就出现了：两个不同的datasource是无法放在同一个事务里的（不考虑分布式事务，因为仅仅为了一个后台查询而采用这种方案，会大大增加系统复杂度），而且原来随机分库的规则是不可能更改的（因为随机分库可以提高可用性，譬如一个手机号对应流水如果插入某个库失败，则可以随机选择另外一个库插入。而如果采用某种规则进行分库（譬如根据手机号分库），那么该手机号对应的流水就永远插入不成功，影响可用性）。所以这个方案是不可行的，需要寻找新的解决方案。
    新的方案就是仍采用原来的随机分库规则，只进行分表，所以datasource保持不变，不影响原来的事务逻辑。原来是每个库里一张表，现在按月份分成12张表，那么每张表的数据量相比于之前就会缩小3倍（原来是3个月的数据存储在一张表里，现在是3个月的数据存储在3张表中），而且即使将来有需求要保留12个月的数据，每张表的数据量仍然不会增加。 所以是满足查询需求的，当然该方案的分表规则就需要应用系统自己实现了，其实是很简单的，采用ibatis的动态表名技术就可以了。
    还有一点需要提的是，原来的查询是直接从主库查询的，这样导致的后果是如果查询使得DB抖动，则会影响其他的主业务流程，因此本次决定改造为从备库中查询。
    记流水帐似的写了这么多，其实就想说明一点：系统分析过程中最重要的产出就是确定关键技术的可行性，切勿把这种不确定性留到编码阶段。