上线时间：20151214
就在2015年12月14日，我们财务研发部的财务独立系统（简称财务系统）上线了，总的来说是很成功的，但是里面有一些细节，还是值得总结的，有出现的问题，也有一些实施的方案，下面我说来总结几点。
一、出现的问题，也就是最大的失误，就是线上环境数据库和本地环境数据库不同，当时本地测试使用的是订单主数据库，而线上考虑到不能影响订单数据库性能，只能让我们使用从库，我画个丑点的图表示一下。
正常的操作流程图：
出问题的情况图：
这种情况，造成的问题是什么？本地测试时，没有问题，线上运行时，有问题，而且，如果不仔细想，想破脑袋也想不出问题出在哪，这种问题也是最难找的。
我要表达的意思就是，很多情况测试没问题，程序没问题，运行时有BUG，找问题侧重于思考运行环境等方面的问题，是环境不一样，或者是系统压力不一样等等引发的问题。
二、系统拆分方案，也是当初着手做这项工作时，非常棘手的一个问题。能不能拆出来，用什么方案，像数据同步方案，订单系统和财务系统之间之前的很密切的互相调用等等，是用同步还是异步。开始考虑了消息队列，后面发现实施起来很麻烦，订单系统各个点要发半空消息，财务系统这边也要获取消息队列，数据庞大的情况下，能不能及时处理也是个问题，后来最终使用的是财务数据库使用SQL语句链接订单数据库服务器进行数据同步，这种相对来说比较轻量级，也不需要对程序进行改动，相对来说减少了很大一部分工作量。在程序是，我们对重要的一起系统间的调用，使用了事务补偿的方案，比如：系统A调用系统B，在系统B产生了一条数据，如果系统A在那个事务里失败了，但又不能操作系统B的数据库，那么，系统B的自动作业中，会检测系统A事务处理的状态为失败，就把对应系统B中产生的数据删除或做其他处理，这就是事务补偿。
三、程序上加一个开关，来快速处理回滚的问题。就是如果上线后，发现拆分出来的财务系统有问题，不能用，那么，通过一个配置开关，就能直接用回原来的未拆分时的系统。意思就是做系统拆分，不能只考虑一刀切（最理想的状况），还要考虑到如果有问题，如何快速还原到之前正确的状态，通俗点就是留条后路。
四、时刻记住自己的目标，不能乱做。比如我们拆分初期，原来的模块就不是很完善，需要还想着在拆分时完善一下系统，人力不够，时间不够，那时候真的是有点做不下去，后面，我们也确定了拆分的目的，就是把原来的功能拆下来，哪怕原来的有些部分功能是错的，也不要花太多时间去改，记录下来哪些有问题，拆出来了再去完善，不然拆分基本的任务都完不成，怎么去完善。
五、关于程序优化方面，主要是数据库保存数据比较耗时，比如要保存100条数据到数据库，那能想到的策略就是先放在内存，在最后时刻才将数据一次性保存到数据库，这样能减少与数据的连接次数，从而减少浪费时间提高程序性能。就像现在的迅雷下载、旋风下载等等都有缓存，可以设置（假设使用旋风下载：缓存设置成256M，每秒下载1M，都是保存到内存，满256M时，才一次性地保存到硬盘上，可以在任务管理器中直观地看到QQDownload.exe进程，从几十M慢慢变到2~300M,然后又变成几十M，一直循环）。
评论列表: