作为一款运行于Linux/FreeBSD平台上以支持ASP.NET著称的高性能HTTP服务器和反向代理服务器，继5.6版完成对OWIN标准应用的支持后，就把着力点放到了对ASP.NET5的支持。
但是，由于ASP.NET5与之前的ASP.NET相比，不管是从运行环境还是部署方式都发生了革命性的变化，Jexus很难像“前ASP.NET时代”那样，把ASP.NET5轻易地纳入其工作进程内直接运行。
支持ASP.NET5，摆在Jexus面前有多种待选方案，比如利用OWIN协议针对ASP.NET5开发专用的适配器，或者利用Jexus的反向代理功能，等等等等，但反复权衡之后，Jexus 5.8.1版选择了一条更加直捷且现实可行的方案：通过“端口转发”功能，把网站端口与应用程序宿主端口“桥接”起来。
之所以选择“端口转发”这个方案，是因为：
1，OWIN方案。由于mono与.NET Core是完全不同的两个运行平台，本质上有很大的不同，为在Jexus进程内运行的OWIN适配器的开发工作造成了极大的困难，而且ASP.NET5还在发展中，架构方面、API方面都有相当的不确定性；
2，反向代理方案。Jexus支持反向代理并且可以利用它做负载均衡，但是，反向代理由于需要对外部用户发过来的请求包和工作服务器发回来的响应包进行不同程度的解析和重组，必然会消耗一定的计算资源。而且，反向代理对于WebSocket等技术的支持也有很大的难度和更大的性能消耗；
3，基于.NET Core重新改写Jexus。这个方案明显不现实：原因之一，Jexus必须继续支持已经在生产环境中被广泛使用的“前ASP.NET”，如果基于core改写，就会出现与“前ASP.NET”兼容性问题甚至出现“断代”风险，这绝不是Jexus用户愿意看到的事；原因之二，Jexus已经是一个开发了多年的成熟的WEB服务器，重写Jexus绝不是一个简单的事情，需要花费相当长的时间和非常大的精力。
“端口转发”有着类式端口“桥接”的直接效果，它既避免OWIN方案的开发难度，也避免了反向代理方案在性能方面的耗损和应用层交互协议的局限性。而且更重要的是，这个方案在支持微软为ASP.NET5量身打造的Kestrel这个宿主服务器的同时，也支持其它的花样繁多的自宿主应用，把Tomcat、node.js的服务让Jeuxs整合起来对外统一用80端口提供服务，也完全是可行的。
Jexus 5.8.1 BETA1已经发布
====================================分割线================================
文章转载自 开源中国社区[http://www.oschina.net]
时间： 2024-03-20 08:48:54