A：共性实际上在官网及别的回复中有过描述，因为 NJet 最初的代码树来源于 NGINX ，可以使用相同的配置模式进行维护。区别在于 NJet 实现了 CoPilots ，动态配置框架，并对模块做了动态化改造，这种改造是扩展、新增，而不会变更原有实现的逻辑及含义。所以 NGINX 是可以自然，无需改造迁移到 NJet 上的。选择 NJet ，最关键的点是在某些特殊的客户场景下，是需要 7×24 业务无间断。
虽然 NJet 把 7*24 作为切入点。但我们在选择引擎，或其他基础设施时，需要的更多是业务分析。比如我们的业务，可以容忍临时的中断，在线率只需 99%或 99.9%.那就可以不为性能作为切入点，而是重点考虑运维的友好度、扩展性等等。泛泛而谈，我认为有三点是需要考虑的：
首先是避免成为单点，至少需要支持主备的架构，能够尽量快的实现故障的 failover;额外的，则需要实现水平扩展能力，因为一个节点的硬件资源总是有限的。
另外，则是尽量内聚，对于较基础的组件，如果依赖太多的外部组件实现特定功能，一是不利于运维，需要这些额外组件的知识体系的学习;在云环境中，还有可能导致特定基础设施的绑定。比如我们也看到，很多的有效的业务组件，离开了 amazon s3/google bigtable 就无法运行，实际限制了在目前越来越流行的私有云中的应用。
最后一点，则是扩展性。尤其在私有云环境中，我们面临的协议千差万别，甚至还有些古老的协议要支持，像 tuxedo 等。那么实际我们需要大量的实施、交付人员，在现场针对这些特定的协议或需求进行开发。这块业界基本上也有成型的做法，采用嵌入式语言来做。从最早的 TCL ，到 LUA/JS/python ，支持哪种语言，还是要看面临的常见，所以游戏类 LUA 比较频繁，而进行算法处理的，python 比较多。
最近搞了个问答栏目，陆续放点我们的 Q&A 出来，欢迎使用了解 OpenNJet ～
官网： https://njet.org.cn/
主仓： https://gitee.com/njet-rd/njet?_from=gitee_search
