转载

基于yaf的模块化开发方案

随着我们网站流量越来越大，用户越来越多，需求也越来越复杂，一站式开发已经远远不能支撑我们的业务发展需要，在产品发展期内碰到的问题越来越多，技术架构限制了业务的发展，这对于研发人员来讲是不能忍的，业务制约技术发展可以接受，但技术制约了业务的发展就是问题了。

我先来总结下一站式开发将面临的问题：

1、代码量大，开发、部署、测试都将是问题

这个很容易理解，我们的业务需求全部在一个系统中的时候，开发、部署、测试必然都会存在很大的风险，比如开发，即使从一开始就参与项目的成员，在业务规模庞大的时候，也很难做把控控制风险；比如部署，因为量大，导致代码发布会非常慢，大部分发布平台会先打包，到线上服务器解压，这个过程当在紧急上线发布的时候会急死人的，一旦上线出现问题，回滚成本将会更高，影响的不单单是发布系统，严重的将导致服务不可用的状态。

2、严重制约业务发展

有一个好的习惯，开发人员会在开发过程中习惯性的将公用的功能封装成类或方法，如果这是核心功能，那它可能出现在整个系统的任何地方，当核心功能需要开发的时候，则会牵一发动全身，很可能面临的将是系统重构。

举个很简单的例子。

如我们有一个函数（或者一个类）

function custom_function($a,$b) { //TODO }

实现了最基础的业务功能，一开始它满足了当前的业务，实现了基本功能，但随着业务发展，这个基础功能变得更强大，支持的特性更多了，为了支持业务，我们把函数扩展根据参数做兼容，如：

function custom_function($a,$b,$c){ if(empty($c)){ //兼容老业务 }else if($c== "XXX"){ //支持新业务 }else if($c == "ccc"){ //新业务 } }

虽然能满足需求，但可以想像维护这样一段代码会让后来人骂娘多少次？当然，虽然我们听不见，但毕竟让后人非常不爽。

3、不得已的推倒重构

基于各种压力，更多的是基于业务发展的压力，我们不得已痛苦的对整个系统进行重构，这个过程漫长而痛苦，一方面要支持现有系统的业务，另一方面还要对整个系统进行技术重构，让他们之间的耦合更少，这个成本和风险将会让我们痛不欲生。

那我们在项目最初是不是就该考虑从业务上拆分成多个模块？答案是肯定的。但是也将带来一些问题：

1、PM不懂技术，不清楚怎么拆分

这个问题还好解决，在规划和项目评审的时候，跟技术一起讨论，侧重于在业务功能上进行拆分，比如用户相关操作全部归为用户模块，后台相关归为后台模块，浏览的归为view模块

2、怎么控制粒度，控制不好反而会增加更多的成本

这个要在技术内部好好的做沟通和规划，控制好边界

3、数据共享？

虽然拆成了多个模块，但是对于数据俩讲，它遍布整个系统，模块与模块之间的数据如何共享？

在项目初期的解决方案是，

－将最基础的数据独立成library模块，它提供最细单元的数据共享，这些可以在整个模块中调用；

－提供跨模块调用的业务接口，比如在模块A下，让框架支持调用B模块下的接口；

－提供http服务化接口，这个大多数是在项目成熟阶段的时候才会做的事情；

解决困难问题的方向就在框架身上了，它将具备以下特性：

1、代码量少、精简

2、可跨模块调用，模块中几乎不用包含任何框架的实现

3、可调用最基础的library模块

4、管理配置化

在目前所有php框架中，要想实现模块化编程还是比较困难的，大部分的框架实现都是在框架内部有自己的application或module，这里面是具体的模块化的业务代码。

基于yaf的模块化开发方案

还有一种完全的模块化，每一个模块业务都有这样一套框架实现：

基于yaf的模块化开发方案

但是这样的缺点显而易见，一方面很难做到跨模块调用，需要在外层在包一层逻辑实现，另一方面框架维护和代码量让模块显得更重。

所以更多的是采用第一种方式，今天的主题yaf，其实也是这样一种架构，只是框架逻辑实现在so扩展中了，

但今天所要谈的是基于这两种方案之中的办法，既能让模块之间完全独立，又能让它跨模块调用接口，而且模块中基本不用维护任何框架代码，只需要按照框架的规范写代码就可以了。

基于yaf的模块化开发方案

每个模块之间提供interface，供其他模块直接调用，每个模块只处理自己的业务，当有业务需要共享时直接按照规范写interface就可以了。

项目目录如下：

基于yaf的模块化开发方案

但是yaf不支持跨模块的调用，模块与模块之间是不能通过interface来通信的，为了解决这个问题，我增加了两个类Yaf_Init和Yaf_Caller

Yaf_Init

$app = Yaf_Init::init(); $app->Bootstrap()->run();

这个只是一层封装，根据目录解析出当前模块名，省去配置config.ini的烦恼，为了灵活性，Yaf_init::init()后面将增加参数可以灵活自定义配置，每一个webroot/module/index.php中都是上面的代码。

等同于下面

$config = array( 'application'=> array( 'directory' => app目录 ) ) $application = new Yaf_Application($config); $application->Bootstrap()->run();

为了能够找到app的目录，还需要在php.ini中增加一个配置，

yaf.app_path = /home/admin/web/htdocs/app/

如果访问/home/admin/web/webserver/webroot/module/index.php时，

会解析出module拼成app目录：

/home/admin/web/htdocs/app/module/传给$config.application.directory，

将$config 配置传递给yaf_application的构造函数进行初始化

Yaf_Caller

$Object = new Yaf_Caller('moduleName','className'); $Object->test();

这个类用来实例化其他模块中interface的类库,其实它也是一层简单的包装，保存环境变量，切换到某模块，然后调用Yaf_loader::autoload(),该构造函数接收两个参数，第一个是模块名，第二个是interface的类名，

interface的命名规范：

/app/htdocs/moduleA/Interface/Admin.php

比如模块A提供了一个interface，类名是admin

则Admin.php的类写法

class Interface_Admin{    function test(){         //TODO    } }

其他模块调用时

//object返回的是Interface_Admin类 $object = new Yaf_Caller('moduleA','Admin'); 它直接可以调用Interface_Admin下的public方法。 $object->test();

这套方案有以下优点：

－模块代码量小，只需要实现业务代码就可以

－模块之间可以无缝调用inteface接口

未完待续……

原文出处:

原文 http://www.imsiren.com/archives/1236

正文到此结束

所属分类：编程技术

本文标签： 测试数据实例 ACE 服务器 UI 解析网站流量 root 配置 App http PHP 网站 CTO src web cat 需求 lib 目录产品代码总结压力管理开发 Bootstrap 参数
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二

其他链接

关于本站

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。

问题交流

基于yaf的模块化开发方案

Yaf_Caller

热门推荐

相关文章

说给你听

本文目录

随机标签

书籍教程

近期评论

网站信息

其他链接

关于本站

问题交流