~~~~~故事开始~~~~~~
功能：有一个交易系统，请实现一个功能：计算15分钟内的交易笔数；
实现：简单，select一把搞定，这个需求，半天总能上线了吧？
~~~~~情节1~~~~~~
附加1：非功能性需求1：性能的要求：要在1000TPS的情况，要求统计功能在5ms返回；
问题：那上面的程序一跑，完蛋了，只能压到5000tps，统计时长最少也得要12ms，怎么办？
实现：放弃DB方案，用内存方案吧；于是需要开发一个交易接收模块，一个交易缓存模块，一个交易统计模块。熬了一周，搞定，程序一跑，达到了1000TPS，统计时长也达到了5ms；
~~~~~情节2~~~~~~
附加2：非功能性需求2：数据量要求：交易量越来越大，统计时长也从15分钟增加到12小时，
问题：完蛋了，那台服务器上的内存使用率超过99%，报警了，怎么办？
实现：把缓存模块剥离出来吧，考虑到交易量的不断扩展，所以需要一个分布式的缓存来适应后续内存使用的持续扩展；缓存的存储引擎，缓存的内存管理，缓存的客户端访问等等，还得考虑交易的发送时序等问题，熬了两周，搞定，程序一跑，杠杠的，性能指标满足要求，内存使用降到了50%，只是又要问运维要两台机器，泪！
~~~~~情节3~~~~~~
附加3：非功能性需求3：可用性要求：这个统计功能太重要了，可用性要达到9999，异常情况下不影响业务；
问题：完蛋了，现在的这个架构，只要一台机器宕机，统计业务就要停，就得写报告啊，怎么办？
实现：实现高可用方案吧，高可用方案之前，先把应用分层吧，通讯层，计算层，缓存层，基于层次来设计load balance和failover吧，熬了四周，搞定，程序一跑，杠杠的，性能指标满足要求，内存使用保持在50%以下，服务器实现热备，异常自动接管，妥妥的。只是又要问运维要四台机器，痛！
~~~~~情节4~~~~~~
附加4：非功能性需要4：伸缩性要求：营销活动了，营销活动了，我们的TPS将会达到*******TPS，你这个统计应用能伸缩吗？言下之意就是能长能短，可粗可细吗？
问题：完蛋了，伸缩不了啊，面对来势汹汹的交易量，怎么办？
实现：实现应用可伸缩方案吧，赶紧实现应用各层的无状态，实现应用间请求的分派策略，实现应用间的状体数据同步等工作，赶紧实现应用的自动化安装，自动化配置，自动化启动，自动加入计算集群，熬了六周，搞定，程序一跑，杠杠的，性能指标满足要求，内存使用保持在50%以下，异常自动接管，吞吐量上来，给两台机器丢到集群，就开始麻利儿干活，赞！哎，那啥，这玩意儿能用云吗？
~~~~~情节5~~~~~~
附加5：非功能性需求5：扩展性要求：这个统计功能挺牛逼，再实现几个功能呗：统计6小时卡片的交易金额，统计6小时商户的最大交易金额，统计6小时卡片的交易地区；
问题：完蛋了，扩展不聊啊，面对来势汹汹的新需求，怎么办？
实现：实现应用的扩展方案吧，赶紧抽象一下统计的模型，实现一个业务关系的统计模型，实现相应的count、sum、distinct等统计算法，赶紧实现配置页面呗，对哦，还得配置实时生效，哎呀，好像统计引擎的管理接口还要调整。。。熬了八周，搞定，参数一配，程序一跑，杠杠的！
~~~~~情节N~~~~~~
还会有其它情节吗？屌丝程序猿们揉了揉眼睛，喝下那晚方便面的汤.，抹了抹嘴巴，不禁陷入了沉思。。。。。。
思考1、其实技术的实现真的不像需求的描述看上去那么简单！
思考2、其实很多隐藏的需求{非功能性需求}影响真的很大，需要及早提出！
思考3、其实，其实，其实，这个统计功能需要做成那么的规模吗？这个变化的过程，我们是在解决一些怎么样的问题？这些问题真实存在吗？要解决这些问题还有其它解决方案吗？全局来看，用应用来解决问题是性价比最高的方式吗？
up方方土，一个混在金融行业的屌丝程序员，喜欢代码，喜欢咖啡，喜欢旅行