游网偶见一文写的是某传统业务的大哥投互联网的简历，被分布式的一些细节问题问的有些蒙。面试官最后说除你们除了CRUD什么也不会，还好意思说干了几年开发。
技术这块我也不熟，分布式微服务也能用，究根问底的细节功力估计也达不到面试官问题的程度，但我想说的是传统业务里不只是有CRUD，还有人对业务的思考这种水面之下的东西。大可不必依某些流行技术的通晓来揶揄别人。
比如12306，当年一开张就闹了大花脸被暴烈的春运订票风暴直接刮倒。现在也出来了几个问题，一个是抢票工具，一个是黄牛通过占票退票达到倒手的目的，而订票本身也不是很容易，偶尔还是有卡的情况。
这些我不知道现在有没有技术上的处理手段，如果有想必十分高深。但我想说如果从做业务的角度来说并非没有破解的办法。如果采用投票池的办法来解，不但能解决这三个问题，还可以增加更多的服务。
比如开始订票后每二分钟或者五分钟的订票做为一波订票一起去从票池里摇号取票。采用这个办法可以轻易解决抢票工具的问题，抢票工具再高级也无非就是比别人快那几秒抢到下单线程里去，占一个时间先机，那把这个先入的线程淹没到票池里使其没有发挥的机会就可以了。
当本轮投票结束后就开始进行摇票的工作，这个时候对使用抢票工具的人来说我们已经抹掉了其先发的优势，大家都是平等的。摇票的结果可能对某些人来说是我的确是比别人早订了一分钟，但我就是没摇上。那北京车牌摇号还有人摇了8年没摇上呢，这个是相对的公平，至少抹掉了大家在网络，设备，工具上的不公平，也给了大年龄操作人员一个公平。同时也可以对已经摇过票但没有的中同学下次进行一下概率倾斜，让大家都尽早拿到自己的票。
因为摇号是一个封闭的内部操作，其不会受天量并发的限制那么我可以从容地进行少量线程的批量数据处理，这个就把瞬时压力降低了很多。而且还可以从容地对每个下单(可能订一张票也可能订几张票，因为五分钟的话大家可以慢慢提交，一下提交多张订票)进行分析处理。
比如一张单订有几张票的座位就排在一起，老年人排到靠过道的位置(方便老年人频繁如厕，同时位置比较开阔也利于休息或者抢救)，一排中的异性可以排到过道或者靠窗（这个坐在两个男的或者两个女的中间的异性往往也比较尴尬）。如果勾选了服从调剂，那么可以让老年人订到下铺，年轻人换到上铺。
同时如果实在没有摇到号的，还可以给出其他可以换乘的车次列表，供乘客下次摇票的时候选择。
这样在5到10分钟后返回订票结果的时候我们就不仅仅是只完成一个订票的工作，还提供了一些服务。
同时对退票的处理也一样，黄牛的退票无非是即退即买。那通过票池的方式来解决，无论什么时间退票，每二十分钟或十分钟通知允许大家观察一下有没有退票。比如十点二十，十点四十，十一点这样每二十分钟统一开一次退票观察窗口。既避免了黄牛倒退票，同时也避免乘客反复刷退票，消耗系统资源。
现在系统仅仅是把原先的订票电子化了，引用了一些微服务分布式的实现。但其本质就像是把算盘改成了计算器，没有任何业务上的提升。该抢票一样抢票，该倒票一样倒票。
而把分布式服务的技术加上分步式业务的思路，这个问题就可以有所解决。原先下单到订票的一个长业务流程被分割成下单和摇票两部分。下单部分只是单纯的插入，大大减少系统并发对锁的压力。插进去就完了，出票有后边的摇票进程统一控制。
在摇票部分我们可以实实在在地引入服务，就像财务系统中填录凭证，我们可以默认类型为收付转的一种，需要改变也只是需要再选一下，这才是真正地引入了服务。而不是仅仅用最新的架构与技术手段把老业务流程翻拍复制一遍。
最近也有出去过几次面试，面试官最后问我你觉得你在团队的作用是什么（不是指写代码或者管理哈^_^。
我想了想说,大概是是让大家写更少的代码吧。他不置可否。
另外我想说即便是技术，在某些技术上的层次来说传统的还是要比互联网的强一些。比如数据库，某些面试官纠结在怎么使用索引，什么是B+树。那么对于比如系统参数的调优，比如hint，比如shrink，比如高水线，比如真正地看懂一个执行计划，并针对性地进行调整，完全都没听说过。那么有什么必要去揶揄别人呢