为何大型网站前端使用PHP后台逻辑用Java

 

　　前两周参加完 ThinkInLamp 的 PHP 架构师大会，听鸟哥一上午的分享，感慨不少，PHP 业界虽然方向不明荒废了两三年的时间，终究仍是又从新崛起了。

　　其实包括 Java 的重启问题，如今也已经不少解决方案了，再不济，双进程 Load Balance 切换也很容易作（但可能引起冷启动问题）。

　　而 PHP 的性能问题随着 @Laruence 在 PHPNG 上的努力，眼看着 JIT 快来了，ZVAL 也优化了，尤为是作数据分析最坑的 Array 常量引用和 Array 结构大小等问题都获得了解决，必然在将来有着更广阔的空间。 如今也有了相似 @韩天峰 的 Swoole 这样的解决方案，真正作到了 fastcgi.com 所提出的那套标准 FastCGI 方案，消除了每次启动重建上下文、初始化数据的成本，而且还能以 Backend / Web Server / TCP or UDP Server 等多种方式工做。

　　但这些，并无让异构语言环境消亡，反而在业界愈来愈多见了。 核心关键点仍是在于开源业界的兴起使得咱们有更多更好的选择，并且架构的发展也愈来愈容易、愈来愈有必要以异步交互等方式解耦。 非核心模块或中间件选用异构语言的开源项目，用到超出其性能上限或有特殊业务诉求涉入开发提高也是挺常见的事情。

　　而分层分模块以后，不一样模块根据本身的业务场景、需求用不一样语言实现已经愈来愈常见，固然也有一部分缘由是公司技术团队的成分。 而 PHP 和 Java 做为 Web 开发当中市占率最高的两项，在组合里经常一块儿出现也就不足为奇了。 今天 Python / NodeJS / Go 等也已经有不少开源项目加入到异构系统的大军里来了。

 

// 原答案，大概是2012年左右写的吧。

　　首先，为何是PHP和Java，不是其余。这和二者的开源社区都很活跃，而且都很适合进行Web开发有很大的关系，并且都很适合Linux环境下运行，能够在运维上统一管理。

　　尽管.Net市场占有率也不低，但因为Windows和SQL Server的License费用、开源社区不活跃等多种问题相对而言考虑得少一些。TIOBE TOP 10中适合Web开发的语种还包括了Python Perl Ruby，其中Perl已是昨日黄花，主要在服务器脚本领域还有较多应用，Web上已经不太可能Yesterday oncemore了。Python最近上升势头挺猛，但仅须要考虑文档较少、招聘相对困难基本就注定了暂时不会是大网站的主流选择。Ruby就不更不用提了。

　　再看一下两个语言之间的差别。 PHP灵活，上手快，易修改，发布快捷，缺点是容易犯错（常见如拼写错误、SQL注入、上传执行等）、执行效率不高、缺少全局缓存。Java的优势则是稳定可靠、运行效率高（尤为是JIT的出现以后差距更大了）、不容易犯错（强类型、预编译、必须拦截异常等等），缺点是开发和发布的效率相对较低。尽管优秀的工程师能在必定程度上改变以上的问题，但一般而言，哪能处处都是高手多如狗的梦之队？

　　而后从MVC的层次结构上说，在通常网站项目的开发周期中，需求变动最频繁、调整最多的是View，其次是Controller，最后是Model。这很是好理解，没事干谁每天改数据结构？每次版本升级控制结构都要改的啦，或多或少而已。而View，啥时候两天不改BU啊PM啊UED啊大概是集体休年假了吧？

　　再次是二者之间的通讯，目前RPC技术已经足够成熟，不管是Web Service/Hessian/RESTful API都可以让开发人员专一在功能开发上，而不须要过多的考虑异构平台的差别和通信的细节。这也就意味着在大公司里同时应用两种语言的方案并不会引入过多的复杂度和工做量。固然，文档量的下限却是所以被拔高了很多，但事实上大部分团队对此其实都是喜闻乐见的：别天天说文档重要但没空了，你不写其余同事怎么配合？

　　总的来讲，靠近用户的前端，使用PHP可以更快的完成前端频繁而琐碎的更新，自如的应对各类需求的变化。页面的结构调整、用户输入内容的基本验证、仅只和用户交互有关的简单逻辑等都很适合使用PHP来开发，甚至能够经过相似Smarty等模板技术将其页面的变更迁移到前端团队。而基本的业务逻辑和数据的更新采用Java开发，能够有效的提升复用度、提高性能和吞吐能力、规避安全问题等。而开发效率稍有下降换来的是可维护性的提高，发布速度慢就更不是问题了，由于一般对于基础业务逻辑的调整每每都是总体修改，并层层测试确认才能发布的。

　　因此，大型网站前端采用PHP后端采用Java，既好招人又好维护、系统稳定还性能高、连安全性都大大增长。代码复用、文档完备度竟然也都改善了。让你在以上这些好处触手可及时，对架构师知识谱系在广度上要求更高一些这事根本就不是个问题。

　　好吧，后面的同窗补充了一个很好的问题，为何不是仅用PHP或是仅用Java？这个我本来稍微提了，不过以前发布前删掉了的，由于问题是为何PHP+Java。其实也有不少公司为了保证团队组织不至于过分复杂，会更倾向于采用单一语言，尤为是中小公司。

　　单一方案其实同样能够作良好的隔离，PHP一样能够提供Service，而性能问题其实不少时候是算法和架构的问题而不是语言差别的问题。如Velocity或JSTL等也是很优秀的隔离方案。

　　

但咱们都知道，现实每每比理想骨感不少，这些方案在高压力下会暴露出不少问题而体现双语言的优点，这些在上面其实都提到，详细说明一些很可贵到改变的点： 

　　一、PHP因为其动态脚本语言的特性，包括类、函数、常量在内都须要在每次请求周期中重复执行后才能创建运行环境；为了保证解析速度而牺牲编译质量；应用了FastCGI但仅仅只是复用进程处理请求减小fork成本而不是像其余语言，初始化完毕后经过FastCGI的接口得到数据并以对应接口返回数据等几个缘由，基本上已经不可能在性能上追回当初更烂如今开着JIT牌跑车的Java了。 更况且，还缺乏了系统级共享数据的支持，使得核心数据一次性初始化后重复使用必须借助扩展或中间件。

　　二、在PHP里是如此的容易犯错而难以发现，即便你用实质上出自官方的Zend Studio，也没法改变一个事实：要保证你的程序高质量无大错，得要有充足的经验、足够的严谨、以及——负责任的QA。淘宝的黄裳就曾经拿IDE这事开过玩笑。而玩笑背后的那个缘由“缺少中间件”最近几年有很多的改善，主要是很多中间件的支持变得更普遍了从而让PHP得益，但发展的根源其实仍是在C和Java社区。性能和易犯错则是语言特性形成的技术难点，也是用来换取灵活、快捷的必要代价，很难去期望有根本的改善。

　　三、Java的世界里也有JSTL、Velocity和Freemaker等，但和PHP灵活而强大的动态能力、丰富的函数和类库、轻松的学习成本、多到使人发指的文档相比，简直就是渣，就是渣啊！JSTL改完了要重启Context啊有木有？Velocity不关缓存也要重启啊有木有？Velocity开缓存性能低下啊有木有？即便这些都无论，调整下某个数据校验规则要改Action也要重启有木有？

　　好吧，吐槽结束。

 

　　实际工做中性能问题能够经过良好的架构解决，容易犯错的问题能够经过框架和规范以及全面的测试来解决，中间件选择少些但其实该有的都有了，Java的灵活性同样有很多可供考虑的解决方案，不说 OSGi 之类，就算是挫得要死的摘掉节点重启，完成后从新上节点的策略也都能凑效。

　　因此，你们会看到单一语言的技术团队也不少，这个问题的真正考虑仍是更多在团队自身的特色、积累等等。用了双语言的，也知道本身为何要用这些，不用的也清楚本身的路该怎么走。最后的最后说一句：若是你不知道本身为何要用双语言方案的话，基本上你也就不须要考虑它了。

　　后端java最大的优点在于庞大的生态环境，你想解决的任何问题，java都有现成的方案，并且，相对其余语言来讲，基于jvm的方案在运行效率和运维成本上平均来讲是最佳的（这里不讨论说什么运维人员的能力之类的，只假设咱们的运维都只具备通常的平均水平），因此，后端自然是倾向java的，不管前端用什么。

　　至于前端，最大的问题在于，一个网站的UI，变更至关频繁，传统的基于java的开发方案，jsp tag lib，freemaker， velocity。。。。你让前端怎么改，怎么调试？不通过专门学习他们怎么看得懂？并且，java的开发模式，动不动上来就是MVC，后端跟前端结合太紧密了，基本上前端很难自由的在ui层工做。反过来，基于PHP的前端方案，至少作前端的都能看得懂，都能调试得了，这就是巨大的生产力的解放了，讲后端java作成rest服务，前端全部的动态代码均可以交给前端工程师，对他们来说，最舒服的动态网页方案，天然就是PHP，这个是历史沉淀决定了，谁也无法改变，不管你多么看不起PHP，包括我本身也是并不喜欢PHP，可是仍然要再强调一次，对前端工程师来讲，最舒服最自在的动态网页方案，仍然是PHP！就如同上面不少人回答的，PHP就是快，快在哪儿？PM说要改什么，前端上手10分改好，30分钟后已经release了。把任务发给后端工程师？那慢慢等吧。

　　上面说过，传统的java的前端方案，上来就是MVC，模板引擎，一堆东西，这些玩意儿，作企业应用是很好的，作网站？的确好像不多据说哈。为何？我抄一段别处的文字（不用考虑版权，这就是我本身写的）

　　在过去十年，基于Java的MVC框架如同雨后春笋通常层出不穷，但都不肯意面对或者解决的问题是，它对前端设计师极不友好，并且，开发效率及其低下，互联网企业鲜有基于Java，尤为是基于MVC来构建本身的网站，是有深入的缘由的： 

 　　一、对前端设计师极不友好。MVC模式下，可编程的模板语言成为很是重要的角色，而以视觉创造为主要工做的前端设计师，他们熟悉的是HTML和CSS，而嵌入模板文件的各种动态代码，对他们来讲即便不是如同天书，也是及其让人及其困惑的，固然，他们必然要面对这些内容，所以，传统的PHP必然成为他们的最佳，由于，这个至少是比较容易让人理解的。 

　　二、开发效率低下。互联网企业的开发一般是快速迭代的，并无明确的需求一说，传统的PHP开发模式之因此受到青睐，就在于它易于变动，开发速度快，MVC模式的开发在这一点基本完败，所以，不多有互联网企业会基于Java来构建本身的前端页面，即便有，也一般是基于JSP的自有框架。 

 

更进一步的，在过去将近10年的MVC历史中，咱们其实一直都被下面的问题困扰着： 

一、前端设计师和工程师一直在抱怨嵌入到页面的动态代码让他们很难对页面进行大规模的重构，而另外一方面，后端开发人员也常常抱怨他们要花很大的精力才能修复前端对页面的重构带来的问题。 

二、开发人员常常还会由于模板语言贫乏的功能而饱受折磨。一些特殊的复杂渲染逻辑常常须要富有经验的开发人员才能写出极具技巧性的代码来实现。而这样的代码，一般会成为谁也没法理解的魔术代码。 

三、开发人员对MVC低下的开发效率极度不满，咱们一直在渴望能够有一个更加高效的开发模式。

好了，题归正传，若是咱们必定要用java来作前端，究竟有没有比上面列举的这些MVC，模板之类的更好的办法？答案是有的，那就是view first。由Lift(不知道的lift的请参看：Lift (web framework))最早提出并倡导的view first的理念，应该算是对网站开发模式的一个漂亮的总结，实际上，PHP的前端方案，自己就是暗合view first的理念的。经过view first的理念，避开了繁琐的MVC架构，同时，lift提供了一个纯html的模板引擎，使得前端工程师能够在彻底不考虑后端实现的状况下独立工做，对先后端的协同工做效率，能够说是有着划时代的意义的。

asta4自己最初的目的就是提供一个lift的java移植版，固然，在后期开发中，逐渐仍是有了一些不一样的东西，但从总体上说，lift对前端最重要的两个特性，在asta4d是几乎原样移植过来的：

 

一、view first

二、css selector driving template engine

 

前端的纯html模板中不会嵌入任何后端的动态代码，前端工程师只须要跟html打交道，咱们的前端和后端是分开两个部门的，常规的工做流程是：

一、任务书或者bug ticket下来，前端开branch，开始作或者改页面

二、若是是页面的bug对应，一般到这一步就已经结束了，若是是新功能，或者bug须要后端协做，那么ticket转给后端

三、后端拿到ticket，开工干活，完事，push。

四、release

　　注意，这个过程当中，前端和后端几乎不会交流，由于他们不须要交流！前端经过html和css，以及js表达本身的想法，后端只负责一件事情，把前端须要的数据填上去，是的，就是填数据而已，因此只有后端看不懂前端的数据应该填在哪儿，或者应该填什么数据的时候，才会须要有限的交流。

　　咱们的一个实际经验是，一次耗费了前端部门2我的月的UI彻底重构工做，当前端工做完成后，后端部门只花了30分钟，就完成了全部须要修改的地方，是的，30分钟，在前端完成工做后30分钟，咱们的重构分支就合并到主干准备release了。

 

 

 

来自：知乎

连接：https://www.zhihu.com/question/20314377