PCon全球产品创新大会最新日程上线,这里直达 了解详情
写点什么

企业级开发,PHP 准备好了吗?

  • 2009 年 10 月 20 日
  • 本文字数:3784 字

    阅读完需:约 12 分钟

虽然 PHP 是 Web 应用开发中最广泛使用的环境,但它还是一度被认为无缘企业级开发。InfoQ 组织了一个虚拟座谈小组来讨论语言 / 平台的演变及 PHP 在企业环境下的适用性。

参加此次虚拟座谈小组的人有:

  • Zeev Suraski,Zend Technologies 公司创始人,该公司主要关注 PHP 的进展,
  • Rob Nicholson,高级技术研员, 曾为 IBM 编写过程序设计语言运行时,
  • Derick Rethans,PHP 开发小组成员,eZ 组件的项目负责人

InfoQ**:企业软件的一个关键元素就是互操作性,它可以让软件与其他平台交换信息。大家都认为 PHP 在这方面表现欠佳,因为它的 WS-* 支持相对来说比较新且功能较少,成熟度不高。关于这点你们是怎么考虑的?它会不会有所改变?**

Zeev:我觉得相比 WS-* 而言,互操作性涉及的要更加多些。事实上,我们只看到了很少的基于 SOAP 的 Web 服务请求,而更多的则来自于其他标准,这主要是因为部署 SOAP 的过程较为复杂。PHP 极好地支持了互操作,并且为此提供了很多不同的接口(REST,优秀的 XML 支持,SOAP,以及为 web 服务提供的 ZF 组件等等)。据说 PHP 从 2004 年开始就为 SOAP 提供了非常好的基础支持,从 2006 年开始就通过 Axis2 扩展为 WS-* 提供了广泛的支持。我只能说我还从没有碰到过用户抱怨缺乏互操作性的情况,如果真的有,那也一定是赞美吧。

Rob:我觉得这只是部分人的观点。PHP 源于其简单性。它是一门只需必要的复杂度,就能“解决 web 问题”的语言。因此 PHP 程序员会更多的选择 REST 而不是 SOAP。传统的企业软件正逐步向位于中间的 PHP 靠拢。比方说,IBM 的许多企业级软件产品在去年都提供了 RESTful 交互支持,包括 Atom 发布协议,这样的话就多了一个选择。在该用 WS-* 的地方使用它,而在开发的简单性和速度至关重要时,应使用 REST。我们也饶有兴趣的看到了 PHP 被用来直接加强企业连通性。IBM 的 Message Broker 可以当作一个“万能转换器”,它能够将一个东西连接到另外一个东西,而现在它的消息转化流中也提供了对 PHP 计算节点的支持。所以现在是可以在企业软件内部中使用 PHP 语言简单而又强大的语法和语句的。我们最近为 IBM 的 CISC 事务处理器发布了一个 SupportPac,用以支持 PHP 语言。CISC 正如软件一样,具有“企业级“的性质。它运行于主机上,可以由一些像银行,政府和医疗保健部门的组织来使用,用以处理一些最重要的可能影响到日常生活的事务。

Derick:我觉得这里没什么太大问题。PHP 已经为所有的 WS 技术如 SOAP,XML-RPC 和 JSON 提供了支持。

InfoQ:过去的几年里,将脚本语言移植到 JVM 中并以利用它丰富的监控,安全等功能已经成为了一种趋势。这对于 PHP 开发而言并不陌生,因为现实世界中存在好些个运行在 JVM 中的 PHP 应用。制造商们对于提升性能的话题各抒己见。你们是怎么看待这种趋势的?

Zeev:我们在.Net 中也看到了类似的趋势,但是这些脚本语言并没有很远地脱离原始的实现。我想对于 JVM 上的 PHP 也是同样的道理。事实上我们可以看到原生实现的 PHP 相比综合改造后的 PHP 所拥有的性能优势——尤其是对内存的需要以及在现实世界中长期运行的表现。尽管如此,标准实现最大的优势是在于它所拥有的强大社区支持(包括在代码贡献和使用上),这是其他实现所缺少的一个东西。

Rob:它的一切都令人如此兴奋,我相信它会有很好的未来。在数以千计的已经被实现的语言中,只有少量语言在自然选择过程中幸存下来,原因是它们特别适合于某个用途。因此开发者改进创新某种语言的实现是一个很自然的事情。如果我们看看 Ruby 社区就会发现,这门语言的成功归因于至少半打以上的实现,还有这些实现中的共享测试和性能调整,它们帮助明确了语言的规范,而相互间”最快 Ruby“头衔的竞争也功不可没。我想我们正在 PHP 上见证同样的事情发生。我们已经看到了 PHP 实现间协作所带来的巨大好处,例如在过去两年里由社区产生了大量的全新测试用例以及为改善某些 API 而作的努力,我相信这种现象在未来会持续下去。我现在正工作于 PHP 在 JVM 上的一个实现,它已经用在了 IBM 的 ProjectZero 孵化器(incubator )中,WebSphere sMush 产品,以及我前面提到的 CISC PHP SupportPac 和 MessageBroker 计算节点中。我认为对于某些类型的问题,在 JVM 上运行 PHP 会非常有意义。我们看到我们的合作伙伴和客户正在使用它来耦合现有的基于 Java 的系统,这样做他们可以在轻松重用 Java 库和 API 的同时,享受 PHP 所带来的便捷。

Derick:尽管性能方面“可能”会有所提高,但是可扩展性却始终是个问题。PHP 的整体思想是在无共享架构的情况下轻松实现可扩展性。在 JVM 上跑 PHP 会移除掉它的无共享架构。不幸的是 PHP 社区中只有一个叫做 PHP-on-JVM 的项目在尽可能的贡献着测试用例。

InfoQ:从 PHP 4 到 PHP 5 的升级不是一个简单的迁移过程。关于那些犹豫是否对即将发布的 PHP 6 进行投资的公司,你们想说些什么?

Zeev: 实际上我并不同意关于 4->5 迁移是个非常困难过程的说法。整个过程并没有太多的兼容性破坏问题,而只是相对简单地修补应用程序。事实上想要利用新的功能,多花一点工作是在所难免的,也是意料之中的。在 6 的版本中我们实际上更多的考虑了兼容性破坏问题——目前这个问题在 6 中要比在 5 中更具实质性。这就是我们需要花时间去做的事情。

Rob:我认为 PHP5 在今后很长一段时间都会存在。即将发布的 5.3 版本已经尽可能的设计为无痛升级,且增加了原本定在 PHP6.0 中的几乎全部的功能,只差移除掉一些不用的功能和增加 PHP 6.0 中的 unicode 了。我非常渴望看到 unicode 版本的的 PHP,因为它可以让基于 PHP 的 JVM 具有更加直接的兼容性,之所以更加直接是因为 JVM 原生地采用了 unicode 来表示字符串,但是我怀疑采纳过程在 PHP 5 和 PHP 6 中都将会非常缓慢且持续许多年。

Derick:虽然大家对此总是怀疑,但是我们会努力减少这些问题,通过引入向前兼容的功能来转移到 PHP 6。如果大家能够向我们反馈一下自己在当前开发版本中碰到的问题的话,那么可以帮助我们将迁移过程变得更加简单。

InfoQ:在所有的建立的语言中,社区中的人们都推动增加了许多高级的功能。而另一方面 PHP 一直被认为易学的功能较少。你们认为这种情况需要改变吗?

Zeevv:我绝对不认为它应该改变,因为它是 PHP 成功的一个关键因素。希伯来语中有句谚语大致这么说“给的越多,拿的越多”,我坚信这句话对于 PHP 是适用的,至少在语言结构与语法上如此。通过使用扩展和框架,PHP 可以无止境的扩展,在我来看,这些扩展和框架正是 PHP 最佳和最有趣的“最后前沿”。我觉得完全使用 PHP 的大型复杂网站(Facebook,Yahoo,Flickr),完全基于 PHP 的复杂现有应用(SugarCRM,OpenPro,CMS’s),以及公司网站或内部系统依赖于 PHP 的企业证明了这样一个事实:PHP 的功能集已经成熟,并且我们应该朝着这个方向走下去。

Rob:在我们着手为 IBM 的脚本产品 WebSphere sSmash 选择脚本语言时,就因为 PHP 如此广泛的使用面而特别选择了它。我们希望能够让数以百万的 PHP 程序员们能与企业或者企业软件紧密联系在一起,并且我们希望支持一种能够让新人程序员快速上手的语言。PHP 的强大在于它的简单性。一门语言如果不想灭亡的话就一定需要不断的演变。如果 PHP 5 没有支持面向对象编程的话,肯定会丧失很多吸引力。伴随着 PHP 5.3 的发布,PHP 肯定可以在这些新的特性上潜在的增加其复杂性。我想未来更多的工作是去了解怎样使用它们和在此之上形成的语句。鉴于新版本被采纳的滞后性,因此在大部分主流应用程序转移到使用 5.3 功能之前,还需要等上若干年,我想在这段时间里 PHP 程序员将会用大量实例来掌握这些新功能,并将它们用在简化常见的编程任务上。

Derick:不,它不需要改变,这两类开发人员都存在。增加新功能并不一定需要提高入门的门槛。

InfoQ:PHP 作为一门语言,在这些年里一直追随优秀的范型而演变,并从一个简单的预处理器演变成了一个强大的 OO 语言。随着函数式编程风格崭露头角,你们觉得这种这种范式是否会走进未来 PHP 的世界?

Zeev:不会。PHP 仍然支持过程式开发,并且不太可能会消失;我们早在启动 PHP(PHP 3)中就增加了 OO 的支持,虽然它现在跨越到了 PHP 5 中。lambda 大概是最接近函数式范式的东西了,而这正是我们需要完成的。这也映衬了我前面回答的一个问题——我们不想要一个一劳永逸的语言,只是想要一个能够完成工作的简单语言。

Rob:这在一定程度上已经发生了。PHP 5.3 中闭包的概念就是来源于函数式编程的世界里。PHP 社区混杂了大量经过“经典训练”的计算机科学专业人员以及一些业余自我训练的程序员。看到这个多样的社区中闭包的诞生和常用语句的演化其实是一件很有趣的事。我相信我们最终会完成一套被广泛接受的模式和语句,它可以很优雅的解决 web 开发中的常见问题,而程序员在使用时都不会想到其实这一切都源于函数式编程。

Derick:我不确定,我认为它不会特别合适。但是如果它对 PHP 应用程序有意义的话,也许可以找到进入 PHP 的出路。PHP 在集成其他语言中有趣和有用的理念方面一直做得很优秀。

你是怎么认为的呢,选择 ** PHP ** 是企业的明智之举吗?

查看英文原文: Is PHP Ready for the Enterprise?


感谢霍太稳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2009 年 10 月 20 日 02:348008
用户头像

发布了 125 篇内容, 共 30.6 次阅读, 收获喜欢 2 次。

关注

评论

发布
暂无评论
发现更多内容

【架构师训练营】第2周总结

花生无翼

极客大学架构师训练营

程序员开发色情游戏,赴日寻找AV女优真人拍摄,结果...

程序员生活志

程序员 游戏开发

2020年6月17日 MySQL基准测试

瑞克与莫迪

架构师训练营第二周总结:软件开发简史和框架设计的方法

hifly

设计模式 极客大学架构师训练营

架构师训练营第二周作业

路人

「架构师训练营」第 2 周学习总结

guoguo 👻

极客大学架构师训练营

第二章总结

大雄

【架构师第二周】总结

浪浪

「架构师训练营」第2周作业 - 设计原则

guoguo 👻

极客大学架构师训练营

架构师训练营第二周总结

极客大学架构师训练营

Netty4.x的Channel相关类图及分析

娄江国

【week02】作业

chengjing

一款开源的Diffy自动化对比测试框架:超详细实战讲解

狂师

开源 测试 测试驱动开发实战营 自动化测试

原创 | TDD工具集:JUnit、AssertJ和Mockito (二十二)编写测试-超时

编程道与术

Java 编程 TDD 单元测试 JUnit

Spring BeanPostProcessor 你不能不知道的事

CoderLi

Java spring 程序员 源码分析 后端

架构师训练营 No.2 周作业

连增申

基于 Docker 实现 MySQL 主从复制

ytao

MySQL Dockerfile

第二周总结

changtai

架构师第二周课后作业

傻傻的帅

极客大学架构师训练营

无抽象不架构

菜根老谭

架构 抽象 架构思维 抽象思维

【week02】总结

chengjing

架构师训练营-第二周-作业1

狂奔嘀兔纸

极客大学架构师训练营

架构师训练营作业 --Week2

吴炳华

极客大学架构师训练营

依赖倒置原则理解

Thrine

面向对象设计原则

陈皮

架构师训练营-week2命题作业

J.Smile

极客大学架构师训练营

架构第二周-学习总结

J.Smile

极客大学架构师训练营

0616作业2

Geek_10

BAT面试题汇总:分布式+Dubbo +JVM+微服务+多线程+Spring附答案(建议收藏)

程序员生活志

Java spring 面试 分布式 mybatis

如何高效开会?

石云升

高效工作 时间管理 高效 开会

[Redis源码阅读]redis持久化

老胡爱分享

数据库 redis 缓存 持久化

企业级开发,PHP准备好了吗?-InfoQ