漫谈社区PHP业务开发.doc

?漫谈社区PHP 业务开发 2012-10-22 15:10:25 - 百度技术 的BLOG 原始出处：/4114344/1033716  在当前这个互联网业务飞速发展时期，新的产品如雨后春笋般涌出，老产品线新业务也在不断突破和尝试。这就对快速开发迭代提出了更高的要求。 一、基础运行环境 针对新产品的开发，必须能够快速搭建一套LAMP架构。那么无外乎选择一个webserver，选择一个php版本，选择一个mysql版本，再选择一个PHP开发框架和选择一些php通用扩展和基础库等。这个过程读者可能觉得已经很快了，能不能更快？ 选择的过程要求研发同学对相关技术方向有一定的积累，权衡利弊和优先点，又是一番调研和学习。如果有一键安装程序，提供自动化安装webserver，php，mysql，以及携带高性能灵活的php开发框架，并提供标准化、安全、常用的配置文件，可以大大缩短产品线LAMP系统调研的成本，缩短工作周期。 ? 一键安装四步骤：（1）下载；（2）少量配置；（3）make install；（4）start；（当然有end啦，简单的运维工具），运行环境OK。 二、业务开发框架 社区产品线各自为政，封闭得开发各自的业务逻辑。而事实上，各个产品线之间存在很多通用业务逻辑处理，如session验证、权限判断、参数验证、日志打印等。不同产品线，所有请求都需要做这些处理，能不能不重复开发？无线业务开发和PC上的业务逻辑有很多的不同，但不同产品线之间也有很多通用性。能不能不重复开发？ 产品线在内部通常对这些通用逻辑的处理做了一定的抽象，设计为ActionChain的形式或者通过基类的方案。框架将更彻底：将这些所有请求都要处理的通用逻辑以业务逻辑框架的形式提供，研发同学只需要关注用户请求专有的逻辑处理。 一个用户请求的处理逻辑如下图：蓝色部分是控制器框架处理流程，绿色部分和控制器框架相结合，处理所有请求通用的业务逻辑。而真正需要研发同学关注和开发的该用户请求专有的业务处理，即黄色部分（当然一个不仅仅是一个Action脚本，一个请求的处理会横向做mvc分层，这块后续会有涉及。） 业务逻辑框架继承在一键安装程序中提供，简简单单就可以获得。 原生的PHP业务和模板耦合很深，没有做任何的分层设计，其结果是代码的复用性差。这样的原始的PHP系统现在已几乎消亡。PHP开发框架统一处理路由、渲染、AutoLoad，通用业务逻辑的抽象和基础库的抽象，专有业务MVC分层，已大大加快了产品线业务逻辑的开发。如下图所示： 从上而下，分别是接入层（高性能webserver），PHP开发框架（路由、自动加载、视图引擎等），应用和基础库，存储引擎。 三、通用服务 社区产品线存在很多共同的需求，如日志处理、配置文件的处理、字符串处理、数据库交互、网络交互等。这些算法和工具封装成phplib给产品线使用已比较成熟。 社区类产品线的业务功能存在很多的通用性，诸如评论功能、Tag功能、好友功能、图册、任务系统等，在众多社区产品线都有类似的新功能新需求，各自设计开发？ 这些需求在各产品线的UI上有个性化需求，但是后端实现方案大同小异，具有一定的通用性。功能服务化，提供API接口给不同产品线使用，产品线只需要关注展现逻辑和私有数据的处理逻辑即可，且服务统一运维，降低产品下的系统复杂度。 四、垂直拆分子系统 那么随着我们业务的拓展，单个应用内部的ui和module的数量越来越多，Action和Logic（对应MVC中的M层，内部可以再进一步做分层处理，此次不详述）的交互，logic和logic之间的交互变得越来越复杂。开发同学需要了解整个应用的逻辑，某个logic的升级，需要排查整个应用下是否存在其他ui或logic的反向依赖。在快速开发的要求下，开发同学对logic之间的相互耦合关系的梳理不清楚，势必引发越来越多的问题，影响项目质量，难以开始开发。 单一系统的问题暴露越来越多，就到了系统拆分的时候了。如何拆？按业务逻辑垂直拆分。将功能独立的业务逻辑剥离出来，做成独立的子系统。这个时候还需要考虑业务的通用性，是否可以服务化？应用已有相同需求的通用服务？此时通用业务逻辑封装成通用服务或使用了通用服务，旁路的业务逻辑独立成子系统，如此一来就将原先单一庞大的系统做了大量减负。完成此阶段的重构后，系统加入变成如下： 单一系统被拆分成多个APP(APP内部仍然有横向的MVC分层)，并复用大量的通用服务。如此一来研发团队在人员分工并行开发上都得到了极大提高。 五、跨系统调用框架 然而真实的现状，在拆分后的子系统之间并不能完全消除依赖。为了解决多个子系统之间数据依赖的关系，需要一套统一的解决方案：API框架。子系统成为独立的应用（APP），APP之间存在相互的数据依赖，这些依