漫谈社区PHP 业务开发
在当前这个互联网业务飞速发展时期,新的产品如雨后春笋般涌出,老产品线新业务也在不断突破和尝试。这就对快速开发迭代提出了更高的要求。
一、基础运行环境
针对新产品的开发,必须能够快速搭建一套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之间存在相互的数据依赖,这些依赖以API的形式对外提供。如下图:
当APP1依赖APP2或APP3的数据后,APP2和APP3会将一部分数据接口以API的形式提供,数据做统一的打包,通过标准规范的URL提供产品线内部其他APP调用。这种形式非常类似于一个产品对外开放API(对第三方开放API,我们称为openAPI,遵守统一的协议,并经过必要的权限验证),而解决内部子系统之间数据依赖的API接口可以进一步简化。
APP提供的API解决提供接口描述(输入、输出),处理API的URL,Logic的转发实现。API_LIB统一来管理所有的API接口,并提供统一的API_Server::call接口供调用。完全对上屏蔽内部的转发和实现细节。通常产品线内部为了达到运维的简化和统一,所有的子系统是同机部署的,API接口的会带来额外的网络消耗,以及增大qps。在此部署前提下,API_Server的实现方式可以通过HTTP调用或优化为直接PHPRequire方式实现。优势:
(1)框架统一,接口收敛,业务解耦;
(2)性能提升,易用性高,扩展性高;
六、UI拆分模型
此时独立出来的子系统可以专注做其业务逻辑了,核心的系统也得到减负。但是核心系统的升级更新频率是最高的,业务逻辑也最复杂。到了一定时期,核心系统又变得臃肿,难以维护。此时可以通过一些设计模式来降低程序的可扩展性和可维护性。但即便是如此,还是有一定的学习成本,在一个App内部,开发同学或多或少需要关注其他模块的代码,逐渐发展为升级一点就需要排查很多点。这时候又到了进一步减负的时候。如果减负?分为两部:
第一步:异步模型
页面渲染分为两个阶段:主题页面数据和其他非主题页面数据。根据页面的不同部分由不同的数据源提供数据。按此逻辑将app进一步做垂直拆分。
PHPService是由PHPmodule+一层很薄的UI,返回格式化数据。
第二步:同步模型
Module做拆分,不同业务逻辑拆分为不同的Module,区分为多个数据源,分别提供不同数据内容,由统一的UI调度不同的数据源后,统一进行渲染页面返回响应。
如此持续减负后,产品线内部的子系统和模块将越来越多,需要维持部署和运维的统一。对团队成员的分工很细,业务理解很专注和深入,合作、并行的效率也会更高,从而使整个开发周期缩短。
七、 小结
随着业务逻辑的不端壮大,每个子系统或模块的业务功能如果过于臃肿就需要不断做减分,以保持在可控的规模内。如此随着产品的发展,产品线内部的子系统和模块将越来越多,需要维持部署和运维的统一,保持简单。对团队成员的分工更细,业务理解保持专注和深入,合作、并行的效率也会更高,从而使整个开发周期缩短。
by luhaixia
建议继续学习:
- 我的PHP,Python和Ruby之路 (阅读:11825)
- PHP程序的执行流程 (阅读:9022)
- Nginx+FastCgi+Php 的工作机制 (阅读:8821)
- PHP业务逻辑层和数据访问层设计 (阅读:6432)
- PHP的优势 (阅读:6076)
- 深入了解php底层机制(-) (阅读:5259)
- PHP最佳实践 (阅读:4920)
- PHP将死,何以为继? (阅读:4800)
- 直到刚才,我才想明白大家对 PHP 的用法是如此迥异 (阅读:4308)
- 总结的一些PHP开发中的tips (阅读:4131)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:editor 来源: 搜索研发部官方博客
- 标签: PHP
- 发布时间:2012-07-27 14:02:13
- [68] 如何拿下简短的域名
- [68] Go Reflect 性能
- [64] Oracle MTS模式下 进程地址与会话信
- [61] 图书馆的世界纪录
- [60] 【社会化设计】自我(self)部分――欢迎区
- [60] IOS安全–浅谈关于IOS加固的几种方法
- [58] android 开发入门
- [53] 视觉调整-设计师 vs. 逻辑
- [48] 读书笔记-壹百度:百度十年千倍的29条法则
- [47] 界面设计速成