漫谈社区PHP 业务开发

在当前这个互联网业务飞速发展时期，新的产品如雨后春笋般涌出，老产品线新业务也在不断突破和尝试。这就对快速开发迭代提出了更高的要求。

1、基础运行环境

针对新产品的开发，必须可以快速搭建一套LAMP架构。那么无外乎选择一个webserver，选择一个php版本，选择一个mysql版本，再选择一个PHP开发框架和选择一些php通用扩展和基础库等。这个过程读者可能以为已经很快了，能不能更快？

选择的过程要求研发同窗对相关技术方向有必定的积累，权衡利弊和优先点，又是一番调研和学习。若是有一键安装程序，提供自动化安装webserver，php，mysql，以及携带高性能灵活的php开发框架，并提供标准化、安全、经常使用的配置文件，能够大大缩短产品线LAMP系统调研的成本，缩短工做周期。

 

一键安装四步骤：（1）下载；（2）少许配置；（3）make install；（4）start；（固然有end啦，简单的运维工具），运行环境OK。

2、业务开发框架

社区产品线各自为政，封闭得开发各自的业务逻辑。而事实上，各个产品线之间存在不少通用业务逻辑处理，如session验证、权限判断、参数验证、日志打印等。不一样产品线，全部请求都须要作这些处理，能不能不重复开发？无线业务开发和PC上的业务逻辑有不少的不一样，但不一样产品线之间也有不少通用性。能不能不重复开发？

产品线在内部一般对这些通用逻辑的处理作了必定的抽象，设计为ActionChain的形式或者经过基类的方案。框架将更完全：将这些全部请求都要处理的通用逻辑以业务逻辑框架的形式提供，研发同窗只须要关注用户请求专有的逻辑处理。

一个用户请求的处理逻辑以下图：蓝色部分是控制器框架处理流程，绿色部分和控制器框架相结合，处理全部请求通用的业务逻辑。而真正须要研发同窗关注和开发的该用户请求专有的业务处理，即×××部分（固然一个不只仅是一个Action脚本，一个请求的处理会横向作mvc分层，这块后续会有涉及。）

业务逻辑框架继承在一键安装程序中提供，简简单单就能够得到。

原生的PHP业务和模板耦合很深，没有作任何的分层设计，其结果是代码的复用性差。这样的原始的PHP系统如今已几乎消亡。PHP开发框架统一处理路由、渲染、AutoLoad，通用业务逻辑的抽象和基础库的抽象，专有业务MVC分层，已大大加快了产品线业务逻辑的开发。以下图所示：

从上而下，分别是接入层（高性能webserver），PHP开发框架（路由、自动加载、视图引擎等），应用和基础库，存储引擎。

3、通用服务

社区产品线存在不少共同的需求，如日志处理、配置文件的处理、字符串处理、数据库交互、网络交互等。这些算法和工具封装成phplib给产品线使用已比较成熟。

社区类产品线的业务功能存在不少的通用性，诸如评论功能、Tag功能、好友功能、图册、任务系统等，在众多社区产品线都有相似的新功能新需求，各自设计开发？

这些需求在各产品线的UI上有个性化需求，可是后端实现方案大同小异，具备必定的通用性。功能服务化，提供API接口给不一样产品线使用，产品线只须要关注展示逻辑和私有数据的处理逻辑便可，且服务统一运维，下降产品下的系统复杂度。

4、垂直拆分子系统

那么随着咱们业务的拓展，单个应用内部的ui和module的数量愈来愈多，Action和Logic（对应MVC中的M层，内部能够再进一步作分层处理，这次不详述）的交互，logic和logic之间的交互变得愈来愈复杂。开发同窗须要了解整个应用的逻辑，某个logic的升级，须要排查整个应用下是否存在其余ui或logic的反向依赖。在快速开发的要求下，开发同窗对logic之间的相互耦合关系的梳理不清楚，势必引起愈来愈多的问题，影响项目质量，难以开始开发。

单一系统的问题暴露愈来愈多，就到了系统拆分的时候了。如何拆？按业务逻辑垂直拆分。将功能独立的业务逻辑剥离出来，作成独立的子系统。这个时候还须要考虑业务的通用性，是否能够服务化？应用已有相同需求的通用服务？此时通用业务逻辑封装成通用服务或使用了通用服务，旁路的业务逻辑独立成子系统，如此一来就将原先单一庞大的系统作了大量减负。完成此阶段的重构后，系统加入变成以下：

单一系统被拆分红多个APP(APP内部仍然有横向的MVC分层)，并复用大量的通用服务。如此一来研发团队在人员分工并行开发上都获得了极大提升。

5、跨系统调用框架

然而真实的现状，在拆分后的子系统之间并不能彻底消除依赖。为了解决多个子系统之间数据依赖的关系，须要一套统一的解决方案：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）性能提高，易用性高，扩展性高；

6、UI拆分模型

此时独立出来的子系统能够专一作其业务逻辑了，核心的系统也获得减负。可是核心系统的升级更新频率是最高的，业务逻辑也最复杂。到了必定时期，核心系统又变得臃肿，难以维护。此时能够经过一些设计模式来下降程序的可扩展性和可维护性。但即使是如此，仍是有必定的学习成本，在一个App内部，开发同窗或多或少须要关注其余模块的代码，逐渐发展为升级一点就须要排查不少点。这时候又到了进一步减负的时候。若是减负？分为两部：

第一步：异步模型

页面渲染分为两个阶段：主题页面数据和其余非主题页面数据。根据页面的不一样部分由不一样的数据源提供数据。按此逻辑将app进一步作垂直拆分。

PHPService是由PHPmodule+一层很薄的UI，返回格式化数据。

第二步：同步模型

Module作拆分，不一样业务逻辑拆分为不一样的Module，区分为多个数据源，分别提供不一样数据内容，由统一的UI调度不一样的数据源后，统一进行渲染页面返回响应。

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

7、 小结

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

by luhaixia