对于一个运行稳定且用户量大的老系统而言，频繁的发版，是一件让人头疼的事情。每次新功能的迭代都怕影响了老功能，毕竟这些老功能是项目的根基，服务着大量的用户。时间长了，就造成了一种怪相，宁愿不上新功能，也不能影响了老功能。说到底，是项目组负责人怕了，怕出问题影响自己的绩效。
但是怕，也没用啊，还是要定期发版。
如何解决频繁发版的问题呢？
目前java项目常用的解决方案有三种：
第一种：数据库配置。把可能频繁修改的参数配置到数据库，然后通过修改数据库的方式来变更。
第二种：使用规则引擎。目前常用的规则引擎是Drools，就是Jboss rules。
第三种：使用Groovy。
这三种解决方案有什么优缺点呢？我们来对比一下。
从功能上来说，第一种方式最弱，只能实现一些简单的参数配置。而另外2种方式可以包含复杂的逻辑。
从执行方式上来说，第一种方式是查询数据库，然后赋值给代码运行。第二种方式目前还不清楚。第三种方式是把java代码以字符串的方式配置在数据库中，然后翻译成字节码，jvm通过反射调用执行。
从学习成本来说，第一种方式对于java开发者零成本，第二种方式对于java开发者学习成本最高，第三种方式对于java开发者学习成本次之。
从调试难易程度来说，第一种方式没有代码不需要调试，第二种方式对java支持不友好，无法调试，第三种方式对java支持很好，方便调试。
有的兄弟说了，这几种方式还是要走版本变更啊。我不能去偷偷修改数据库啊。
是的，大兄弟，但是我这种不用重启服务器啊。
最后，给大家介绍一个Groovy的应用场景：Zuul过滤器的动态加载使用到了Groovy，感兴趣的兄弟可以研究一下。
