PHP前端、Java后端

2013-12-17

  PHP用于WEB项目时,没有办法像Java 的Tomcat 容器一样提供常驻内存的机制,所以,PHP被认为无法适用于大型项目。但是,WEB应用基本上属于标准的MVC模式,View的修改是最多的,controller的改动量偏大,Model基础数据的修改是最少的,servcie层改动量比较少。由于无需因为一点点view更改就重启web container,且PHP表述灵活强大,在前端表示上的绝对优势,我们也不希望完全放弃PHP。所以,就有了PHP前端、Java后端这样的架构方式的需求。 这里所谓前端,是指view + controller。
  但是,一个问题是项目到什么规模才需要从PHP转变到此种模式。我认为这里有一个很好的参考。HDF是国内在互联网医疗的龙头企业,基本上占据了大部分市场。用户量有上千万,访问量也非常大。这段时间CTO老大就在考虑重写后端的可行性了。我们的业务类型偏重浏览,查询与交互较轻,不像淘宝或者12306。公司经过七年的发展,开发与测试团队就有50人了。 我想,这也许是一个很好的参考标准。PHP也没有想象的那么弱。在合适的时间,以合适的成本,采用合理的方案,这才是真正的难点。
  因为我们的 front 与 service 可以看做是两个PHP 服务,之间通过自定义的XML协议来通信。所以,即使决定了要改写service,用Java实现,前端部分使用PHP保持不变,压力还是比较小的。前段时间技术组讨论了前端PHP与后端PHP的通信协议,目标就是即使后端用Java写,协议也能照常使用的问题。之前使用的XML还是重量级了,两端都是PHP,序列化与反序列化都非常简单,采用同一套标准即可。但是,后端换成Java,这个序列化就是一个大问题。我们讨论的结果是先尝试使用JSON协议,手动的把各种对象转换成数据Bean。前端PHP丧失了对于后端各种数据类型的感知,前端开发者完全后service开发者隔离,前端开发者只需要关注数据Bean即可。故,数据Bean可能经常需要被更改。这就带来了两个问题:service端的修改;已有的view上的修改。要想减少service改动,那么数据Bean就需要尽可能的”重型“;要想减少更改已有的view对bean的使用,那么Bean的结构更改就要尽量的少。可以想象,将来,这些Bean可能会比较杂乱。我们打算以一个内部模块作为试点,让两个毕业生花费一个月来做,看看反馈如何。经试验,发现JSON的方案不怎么好,问题还是在于Bean的封装和解析。做两次独立的工作,浪费,真的浪费,这两位同学最后都烦了。而且,Bean的结构需要专门的文档来管理,不像PHP 的class那样可直接参考代码文件。程序员不是喜欢所有的代码都有文档,这是肯定的,因为这相当于给系统增加了一个必须依赖的组件,且这个组件的维护不是那么简单的事情。
  JSON格式本身时没有问题的,我们只是不希望太多额外的JSON包装及解析。另外的一种方式就是在Java中直接把Model序列化成JSON,或者PHP service中直接把Model 转换为JSON,辅以部分Bean的构造,这样子基本上满足了简单性、高效性的需求。另外,如果service出现了异常,还需要报backtrace 信息放入JSON中。

老笔记整理

 

 

如果有任何意见,欢迎留言讨论。


[ 主页 ]
COMMENTS
POST A COMMENT

(optional)



(optional)