我想设计具有客户端（可能是 C# gui）和服务器组件（Java、C++、Perl）的非常高可用性（永远不要关闭服务器、推出功能而不重启等）应用程序。
我从（minimize-code-maximize-data.html和Yegge）那里得到了一些建议，我想让大多数逻辑从数据库中动态读取，以便所有配置（包括所有 GUI 配置、文本翻译等、业务规则以及data) 将驻留在服务器上的数据库中，而不是驻留在需要重新启动才能读入可执行内存的代码中。
我希望能够在不重新启动客户端或服务器的情况下自定义应用程序的任何方面，并让应用程序以尽可能短的延迟反映更改（动态类加载等）。
设计这样一个“永不杀死”系统的性能和其他限制是什么？有没有人设法创建这样的应用程序？主要的教训是什么？什么时候这不符合成本效益并且需要更传统的构建、发布、质量保证、几个小时的停机时间方法？
我在一个 MUD 游戏服务器上工作，它对脚本进行动态编译，这样游戏中的几乎所有东西都可以在运行时更改和重新编译，而无需断开任何用户的连接。
也许我从那个项目中学到的最大的教训是，当你编写的代码如此灵活以至于它可以做任何事情时，它实际上什么都不做。
最终，系统的用户不再输入数据——他们正在编写一种神秘的代码语言，这是我的系统所独有的。
警惕灵活性——为代码增加灵活性就像在手臂上增加肘部。有几个关节可以到达你想去的地方很好，但如果你的肘部太多，它就会变得虚弱且难以指挥。
在脚本解释器（如 Rhino）周围使用高度静态且小型的代码库，这与考虑并没有太大的不同：
http://www.mozilla.org/rhino/ScriptingJava.html
这样，所有逻辑和数据都可以放入可重新加载的脚本中，程序的唯一核心部分是脚本运行器和类似 shell 的部分。
这绝对不利于性能，我认为这是理所当然的。
如果我没记错的话，耶格曾经在他的博客上发布过类似的东西，所以如果你再次和他交谈，可能会问他这个问题。