PHP和JAVA双语言重构项目

最近公司网站在改版，其他相关的产品也需要升级改版，公司进行的策略是“'客户端用php','服务端用java'”,具体是：“项目的controller里的基本校验数据整理输出等用php(也有少量部分查询类的接口是php开发)”，“java端是各种业务逻辑和操作数据库封装成接口供php端调用”，因为我是php所以主要参数php端的编码；接口封装有接口封装的优势以下是我最近开发对其的感受：

第一：网站升级改版很多业务逻辑无需更改可调取旧的接口无论前端如何变化数据是变动不大的；

第二：接口封装后模块化更强，负责接口层的程序员负责编码测试，php端的负责调取数据，责任明确；

第三：文档性很强，公司的文档和数据字典关于表结构和接口的参数返回值等都在文档中写的很明了，办公流程更标准化了；

第四：方便简单明了。

 

最近发现很多公司都用这种模式开发架构项目，跟之前同学的CTO聊后了解到他架构项目也是如此，这种架构部署的优势还是很大的，下面就转载别人的文章具体讲讲它的优劣势吧

一下内容是转载的来自：

http://www.zhihu.com/question/20314377/answer/14801579

// 技术日新月异，回答放一段时间不更新会变味啊。
前两周参加完 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等也是很优秀的隔离方案。
但我们都知道，现实往往比理想骨感很多，这些方案在高压力下会暴露出很多问题而体现双语言的优势，这些在上面其实都提到，详细说明一些很难得到改变的点：
1. PHP由于其动态脚本语言的特性，包括类、函数、常量在内都需要在每次请求周期中重复执行后才能建立运行环境；为了保证解析速度而牺牲编译质量；应用了FastCGI但仅仅只是复用进程处理请求减少fork成本而不是像其他语言，初始化完毕后通过FastCGI的接口获得数据并以对应接口返回数据等几个原因，基本上已经不可能在性能上追回当初更烂现在开着JIT牌跑车的Java了。 更何况，还缺少了系统级共享数据的支持，使得核心数据一次性初始化后重复使用必须借助扩展或中间件。
2. 在PHP里是如此的容易犯错而难以发现，即使你用实质上出自官方的Zend Studio，也无法改变一个事实：要保证你的程序高质量无大错，得要有充足的经验、足够的严谨、以及——负责任的QA。淘宝的黄裳就曾经拿IDE这事开过玩笑。而玩笑背后的那个原因“缺乏中间件”最近几年有不少的改善，主要是不少中间件的支持变得更广泛了从而让PHP得益，但发展的根源其实还是在C和Java社区。性能和易犯错则是语言特性造成的技术难点，也是用来换取灵活、快捷的必要代价，很难去指望有根本的改善。
3. Java的世界里也有JSTL、Velocity和Freemaker等，但和PHP灵活而强大的动态能力、丰富的函数和类库、轻松的学习成本、多到令人发指的文档相比，简直就是渣，就是渣啊！JSTL改完了要重启Context啊有木有？Velocity不关缓存也要重启啊有木有？Velocity开缓存性能低下啊有木有？即使这些都不管，调整下某个数据校验规则要改Action也要重启有木有？
实际工作中性能问题可以通过良好的架构解决，容易犯错的问题可以通过框架和规范以及全面的测试来解决，中间件选择少些但其实该有的都有了，Java的灵活性一样有不少可供考虑的解决方案，不说 OSGi 之类，就算是挫得要死的摘掉节点重启，完成后重新上节点的策略也都能凑效。
所以，大家会看到单一语言的技术团队也很多，这个问题的真正考虑还是更多在团队自身的特点、积累等等。用了双语言的，也知道自己为什么要用这些，不用的也清楚自己的路该怎么走。最后的最后说一句：如果你不知道自己为什么要用双语言方案的话，基本上你也就不需要考虑它了。