Home > php教程 > php手册 > 【转】漫谈社区PHP 业务开发

【转】漫谈社区PHP 业务开发

WBOY
Release: 2016-06-06 20:07:50
Original
859 people have browsed it

在当前这个互联网业务飞速发展时期,新的产品如雨后春笋般涌出,老产品线新业务也在不断突破和尝试。这就对快速开发迭代提出了更高的要求。 一、基础运行环境 针对新产品的开发,必须能够快速搭建一套LAMP架构。那么无外乎选择一个webserver,选择一个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调度不同的数据源后,统一进行渲染页面返回响应。

如此持续减负后,产品线内部的子系统和模块将越来越多,需要维持部署和运维的统一。对团队成员的分工很细,业务理解很专注和深入,合作、并行的效率也会更高,从而使整个开发周期缩短。
七、 小结

随着业务逻辑的不端壮大,每个子系统或模块的业务功能如果过于臃肿就需要不断做减分,以保持在可控的规模内。如此随着产品的发展,产品线内部的子系统和模块将越来越多,需要维持部署和运维的统一,保持简单。对团队成员的分工更细,业务理解保持专注和深入,合作、并行的效率也会更高,从而使整个开发周期缩短。

from:http://stblog.baidu-tech.com/?p=1954

source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Recommendations
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template