设为首页 收藏本站
查看: 681|回复: 0

[经验分享] ErLang / Python Web 的类似CGI/FastCGI模式

[复制链接]

尚未签到

发表于 2017-5-4 09:31:33 | 显示全部楼层 |阅读模式
ErLang Web

ErLang语言从一开始,就是针对并发设计的。ErLang作为一个平台,在稳定性和实时性方面也有不俗的表现。不少人希望把ErLang应用在Web领域。
ErLang Inets里面包括HTTP Server、FTP Server等。ErLang的Web开发框架叫做YAWS(Yet Another Web Server)。如果说Inets相当于Apache HTTP Server的地位,那么YAWS就相当于Servlet Server的地位。
一些优秀的程序员为ErLang开发了ORM持久层、Template层等。但是,由于ErLang的几项缺点,使得ErLang在Web开发领域举步维艰。这些缺点包括:
(1)字符串处理能力弱。I/O(输入输出)能力也不强。
对于大量处理HTML的Web应用程序来说,这是一个致命缺陷。
(2)变量值只能赋值一次。不能修改。
这意味着,除了I/O(输入输出)之外,ErLang应用程序是无状态的,无副作用的。也意味着,我们难以在ErLang程序中用基本数据结构存放可以改变的状态。对于普通程序员来说,这种限制会带来编程的难度。这并不是不可逾越的障碍,只是需要思路上的转换。
(3)ErLang不支持循环,只能用递归表示循环。
对于普通程序员来说,这也是一个不小的挑战。程序员需要习惯Map、Reduce等函数,简化需要循环的编程。程序员还需要习惯于把大量的数据作为参数在各个层次之间函数调用传来传去,因为ErLang不支持成员变量。这一点有点类似于浏览器和服务器之间把状态信息传来传去,以保证服务器的无状态性(Stateless)。

(2)(3)两个问题并不是不可逾越的鸿沟,只是一种编程模型上的转换。但是第一个问题是无法回避的问题。
人们想到了一种方法,把字符串处理工作交给其他语言(比如Python、Ruby、Perl等)来做。这种思路需要考虑的问题是,ErLang如何同其他语言进行交互通信?

如果ErLang中存在Python、Ruby等语言的解释器,那就好了。这个思路有些强人所难了。ErLang最不擅长的就是处理字符串,更别说解释一门语言了。
如果Python、Ruby等语言可以直接编译为ErLang虚拟机指令,那也是个不错的选择。目前还没有这方面的项目出现。从实现难度上考虑,Python、Ruby里面的语法元素映射不容易为ErLang虚拟机指令,比如,类、对象、循环、变量多次赋值、环状数据结构等。
ErLang本身提供了Jinterface和erl_interface两种语言接口。Jinterface用来和Java程序通信,erl_interface用来和C语言程序通信。
Java可以通过JNI(Java Native Interface)调用C语言程序。C语言程序和Java程序运行在同一个进程中。
Jinterface和erl_interface的例子表明,ErLang和其他语言的交互模式和JNI不同。ErLang和其他语言程序各自运行在不同的ErLang Node当中。两个Node只能进行通信,而不能进行函数调用,顶多只能通过通信渠道进行远程函数调用(RPC)。
既然都是远程通信,Jinterface和erl_interface也没有什么特殊的。Python、Ruby等语言一样可以和ErLang进行通信。常见的通信手段比如Socket。
在一个ErLang Web应用程序中,ErLang和Python之间的通信过程可能如下:
ErLang Web应用程序收到HTTP Request,根据URL把处理过程转到一个handle函数中。
handle(Request … ) ->
Model = getModel(…), %% 根据参数获取数据

View = getView(… ), %%这里的View通常是一个Template文件名

HTML = send( [Context, View] ) %% 经过通信渠道,发到Python语言程序中
%% HTML是一个Binary。ErLang输出HTML到浏览器
.

Python语言从通信渠道收到数据流,解析出来Context和View,然后根据View读取一个Template文件,并且把Context和Template结合起来,产生HTML,发还给ErLang程序。
我们看到,这里面涉及到一次大数据量通信——Python把HTML发送到ErLang。这种时间空间效率是否能够忍受呢?我们能否做出改进呢?
ErLang和Python之间的这种通信过程,和CGI/FastCGI的工作方式很类似。都是跨进程传输HTML。我们来看CGI/FastCGI的模型。

CGI输出重定向

CGI的全称是Common Gateway Interface。CGI程序一般安装在一个支持CGI的HTTP Server中,比如Apache HTTP Server。
CGI程序和HTTP Server之间的流程和上述的ErLang/Python通信过程类似:
HTTP Server收到HTTP Request之后,根据URL把处理转到对应的CGI程序中。
CGI程序通过环境变量或者参数等渠道,获取HTTP Request等信息,查询数据库获取数据,然后产生HTML,输出到标准输出(STDOUT)。实际上是利用输入输出重定向(I/O Redirect)把HTML传回给HTTP Server。
如果操作系统不支持输入输出重定向,那么HTTP Server自己就需要分配一个缓冲区,存放CGI程序输出的HTML,然后,HTTP Server把缓冲区里面的HTML输出到浏览器。这个过程和上述的ErLang/Python通信情况差不多。
如果操作系统支持标准输入输出重定向,而且可以重新定向到Socket,那么CGI程序也许可以把HTML直接通过Socket写入浏览器端,而不需要把HTML发回到HTTP。不过,CGI程序一般都是把HTML重定向输出回服务器。

字符串处理进程直接把结果写入浏览器Socket

ErLang/Python通信和CGI/FastCGI模式的输出模式比较相似。
浏览器和Web Server建立Socket连接,Web Server把字符串处理工作交给另外一个进程的字符串处理程序,字符串处理程序把字符串处理结果传回到Web Server,最后由Web Server把HTML通过Socket传回给浏览器。
那么,字符串处理程序能否直接把HTML通过Socket发到浏览器呢?
这好像很难。虽然Socket句柄只是一个整数,但是进程间似乎不能共享Socket(和文件句柄)同级别的资源。

我们知道,ErLang程序最终是通过Socket把HTML传给浏览器的。Sokect句柄是一个整数,我们能否把Socket句柄直接传给Python程序,然后让Python程序直接把HTML写到Socket里面,就相当于直接传输到浏览器里面。
在同一个进程中,多个线程可以共享进程的资源,包括Socket句柄,文件句柄等等。两个进程之间,就不能共享Socket句柄了。

上述是我的思考。涉及到很多我不了解的领域。请大家指正。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-372798-1-1.html 上篇帖子: Python常用函数大总结(转)— —想学习Python的兄弟可以收藏了 下篇帖子: (好文)[Python] 第 2 部分: 探索 Python 类型的层次结构 —— 了解对象和容器
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表