非法请求检验

项目中遇到一个不算大但也不小的问题，非法请求。而且我惊奇地发现一个开发维护两年左右的项目居然没有一丝请求校验（这里指接收层没有校验，请求校验全部下放到了事务逻辑层）的痕迹，让我感到无比震惊。前人的坑后人的锅，一直以来的代码逻辑思路里都没有在事务层处理非法请求的想法，故而一个特定的需求让我遇到了一个特定的工具方法类（remove方法传递负值参数在底层逻辑里变成了add，我想问问这个设计如此精妙的话，那为什么你还要再单独写一个add方法），进而发生了一次非法请求的漏洞修复（熬到凌晨三点四十六分，拉日志只为回滚数据）！故此有感而发了这篇言论！例如：游戏中不通过客户端发送带有规则的参数的协议而直接发送自定义参数进而试图通过程序漏洞来获利的行为司空见惯了！当然不仅仅是游戏，例如：黄牛通过脚本模拟玩家请求，进而刷票。这种情况是不可控制的，而且这种逻辑应该从接受层面进行拦截而不是将这种逻辑下放到每一个功能事务层。如果将这种逻辑下放，那么将造成一些极大的影响。第一：代码维护性极差，底层逻辑可以由架构师统一部署实施，但事务逻辑层的话，那就是一千个人就有一千种想法，每个人都有自己独特的代码风格无论好坏，那么每个人针对不同的需求生成代码的同时还要针对非法请求做逻辑上的处理，使其既要满足需求又要逻辑正常。但人无完人，是人就会犯错，你既不能要求程序完美无缺，也不存在这样的代码，不然测试这个行业的存在意义在哪里呢？商业代码更是如此，一代程序一代代码，前人种树后人乘凉，前人挖坑后人背锅！这种情况在it行业也是比比皆是！所以你不能要求每个程序都要对非法行为做逻辑处理，不易处理也不易维护。而是应该从源头入手，直接针对接受点进行拦截，而不是在事物代码里做逻辑处理，这样做的话代码耦合度极高不说还效果极差。第二：非法请求阻塞队列，试想一下如果将每一个非法逻辑判定都嵌入事务中，那每一次非法请求都将生成一个任务并放入等待队列，而内存是有限的，如果是恶意攻击的话这必然会造成内存溢出，服务器瘫痪！这种情况在许多公司的项目都有，无论大小，上市或创业。至于原因不得而知！我只是简单的举了两个例子，还有许多可遇而不可知的问题存在的！非法请求的逻辑拦截嵌入事务层不可取也不可为！在这方面阿里就做的相当出色！12306，可能每个人都有使用，曾今的12306（阿里未接入前）一度让人绝望，刷票，服务器崩坏。作为一个亿级项目，关系民生出行问题，这种情况是极度严峻的。后面阿里接手后，可以说有了质的飞跃（不是阿里吹，而是承认自己的不足，别人的强大）！为了防止刷票等非法求情或密集请求，阿里采用了一种十分恶心的方式，人眼识别图片（注意：不是校验码，而是图片）相信这个设计一度让你怀疑过人生，这里就不详述了。还有就是针对多点密集请求，监控拦截等一系列逻辑处理。他不会把原本就应该在接收层面解决的问题下放到事务层。这样无论换了谁，都只需要维护一份逻辑代码而不是针对每个功能单点维护，效率极差。当然不是每个项目都需要这样复杂的逻辑，有时一个简单的校验码都能为程序解决无数的问题（可能很多程序猿觉得这样的处理过于平铺直叙，都没有通过高深的算法流弊的数据结构进行封装不能体现自己的价值和能力）但我想说的是，不管花猫白猫，能抓耗子的才是好猫！而且越是简单的方法越是易于维护，而且运算量极低！这里提供一些自己的看法：1:请求校验必须有且必须在接收层进行处理，2:校验码，图片识别或者其他的请求校验应针对不同项目的应用场景单独设计，确保能使得效率最大化。