搜索导购项目开源架构（往期）

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/fill8bag/article/details/49469145 文章中涉及的专业术语定义如下：

      风尚项目：风尚项目是XX网的购物分享WEB项目。

      聚优惠项目：就是XX网的聚优惠WEB项目。

      搜索导航：XX网 团购导航、网购导航。

一、总体架构

1、总体的框架的设计

1. 业务层和服务层的分离：这里需要和业务方来配合什么是业务层和服务层，需要完全的解耦。
2. 统一的数据访问操作机制 DAL层和数据库访问DAO层，带给我们的好处就是

• 数据库性能优化的封装，目前数据库成为我们的主要的瓶颈，在这个版本中，我们主要是给程序员一个透明化的DAL，让程序员不用关心具体的垂直和水平的分库。这个功能有DAL层来做。
• Cache的封装：在没有采用Cache的时候，我们发现我们的代码中到处充满着一大堆Cache的代码，把Cache封装在Dao层后，我们不用再插入一条数据库和更新数据数据库后去手工的修改Cache，DAL层会主动的把这个工作给做了的。
• 为兼容Zend_Cache组件：由于项目开发采用了PHP语言，和开源的ZendFramework框架，我们将封装Redis等新产品提供一个缓存任何数据的统一方法。
• 基于Redis、MemcacheDB的缓存框架，由于这个缓存框架是在DAO的前面的一层，对于数据库读的压力是有很大的提高。

1. 服务化机制

       目前依赖服务这一层有2个来源，一个是内部依赖就是各个项目之间的服务调用，还有一个就是外部系统的服务调用，以后这个部分就用开发式API的方式暴露出来。通过服务机制的好处就是和业务的解耦，不用担心业务层的改动需要涉及到服务层的改动。

1. 页面显示层采用PHP ZendFramework，MVC框架带来的好处就是

• 提供了强壮而高效的 MVC 实现，易于使用的数据库摘要和实现 HTML 表单解析、校验和过滤的表单等组件，开发者可以通过这些易用的、面向对象的接口联合所有这些操作。
  
• 可以做到模块化开发的真正的解耦，模块目录结构允许你把不同的MVC应用程序分离成为独立的单元，并和不同的前端控制器配合再使用。
• 模板系统Zend_View提供了两套机制来实现，一种是直接通过通过视图脚本，另一种是实现Zend_View_Interface接口，把第三方的模板系统封装成Zend_View兼容的类。
  
• 页面Widgets可以有效切分页面，方便每个页面按钩子Cache并选择不同模式加载。

2、子模块设计

2.1 开发框架

以上图表描述了工作流

采用Zf原因基于如下考虑

1)    ZF中的组件可以独立使用，是一个强大而可扩展的web开发框架，而且PHP简单。
2)    Zend_Db::factory可自动生成SQL，对于数据库的性能，也能做到SQL的优化。
3)    ZF能够做更灵活的二次开发， DAO和DAL框架暂时都在ZF的基础上进行开发。（DAO层对数据库操作进行封装， DAL操作数据库、文本、Cache的原始数据）
4)    Zend_Service支持任何基于REST的Web服务，支持流行的Web Services。
5)    Zend_Rest自定义服务接口，返回内容可以是Serialize值、SimpleXMLElement、Json等。

        2.2 统一数据访问层DAL模块
          DAL架构图 (可用NoSQL Mongodb替代方案)

1．引入集群（Group）的概念，保证数据的高可用性，高容错性能解决单节点机器宕机的问题。
2．引入读/写分离，提高数据的查询速度，同样也起到了一定的数据备份效果。
3．单个Group组可通过引入负载均衡策略，比如MySql Proxy。
4．引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证负载均衡策略的正确实施，以确保系统的高度稳定性。

DAL达到的目的

• 数据库的垂直和水平的自动的分割，对于程序员来说，不需要在代码中显示的指明是需要访问哪个数据库和哪张表的。
• 做到Service层与DAL层的解耦，DAL有效封装对数据库、文本文件、Cache的操作。
• Cache的操作，Redis、MemcacheDb可通过各种数据类型，做到高速原子的访问、写入。

日志模块

   日志模块的话，主要是为了监控，我们后台PHP执行类的执行效率，有时候一个用户的一个动作，我们不知道是在action 还是在service层 还是在dao层执行慢，加入了日志这个模块后，我们会在每一层都是加入执行的时间戳和必要的参数，这样的话我们对于日志的统计和查看就非常的方便了的。

1．采用AOP的方式来打印日志，这样的话，对于项目中不需要显示的依赖，不会造成代码上的耦合
2．由于日志的数据比较大，我们后台会采用NoSql的产品，Mongdb就是适合存储非可靠性的海量的数据。
3．可以实时的查询，统计后台的执行的情况，可以统计下一个用户的行为我们的主要时间是耗在那个层上，是不是可以有优化的地方。
   
  项目中使用的方式：采用AOP的方式来使用，需要的地方只要配置下就可以了的。

Search服务

      搜索流程图

      目前搜索的需求就是搜索一个站内的数据模型， 这个搜索的模块的架构图是如下所示。

       

      1）为了解决实时的搜索需求，我们会做一个实时的索引模块把需要实时搜索的数据，立即的，单线程做索引的话，我们在时间上、系统资源满足不了需求，这时候需要用分布式搜索的方式的任务的切分和合并的方式来做。

事件列队控制器，比如Gearman

文件服务器模块

       文件服务器的目的

• 图片服务器和主站的分离，分离带宽的压力，分离请求访问的压力
• 所有的上传文件，头像，图片都是统一独立上传，非核心文件一般都是写到文件服务器

       文件服务器的架构图

a.    各系统的上传统一有我们的上传服务器处理上传的图片，相关业务也要写在这里
b.    FastDFS可以很好的解决文件存储的相关问题，FastDFS特性：

      1．对等结构，每个结点都是Master，不存在单点问题（MooseFS、mogileFS需存储文件索引信息）
      2．只能通过专有API对文件进行存取访问，不支持POSIX接口方式，不能mount使用（包括了C客户端API、FastDHT客户端API和PHP extension等）
      3．文件不分块存储，上传的文件和OS文件系统中的文件一一对应
      4．支持相同内容的文件只保存一份，节约磁盘空间  
      5．下载文件支持HTTP协议，可以使用内置Web Server，也可以和其他Web Server配合使用
      6．支持在线扩容
      7．支持主从文件
      8．存储服务器上可以保存文件属性（meta-data）
      9．V2.0网络通信采用libevent，支持大并发访问，整体性能更好

c.    FastDFS架构图：

需要考虑的问题是，容灾问题、性能问题、文件同步延迟问题，以及老的数据迁移问题
1．通过FastDFS的冗余备份机制
2．文件同步延迟，更新和文件下载可优先选择源Storage 服务器
3．运维的定时的数据的备份机制，这里年估计增长率在1T左右，对于存储的要求也是有点大。
4．老的数据迁移应该怎样解决？

业务服务化模块

   这里说的业务服务化的目的就是为了更好能够给第三方系统提供服务支持。这里的服务的暴露的方式主要有下面几种方案，但是对于同一个项目中的调用不需要走下面的协议。
          Zend_Rest方案：跨语言，走http协议，数据交换可以是Serialize值、json格式等。
          WebService方案：跨语言，数据通过XML来交换，性能一般，没有二进制的数据交换来的高。
          Socket协议：性能最高，对于通讯双方都是要求使用Socket，比较底层，开发要求比价高。

开发分支的管理

       Trunk作为发布分支，每次发布前打一个tag，可以作为回滚的分支代码，
开发：从Trunk打最新的分支，在分支Branch上开发，如果发现Trunk上已经有了更多的版本，并且是项目中依赖的话，需要新建一个分支，把老的分支合并过去。
测试(兼配置管理员)：每次测试开发人员的时候，拉一个最新的trunk，把开发的测试合并到trunk的上进行测试，测试好了后，合并到trunk上，如果觉的trunk不合适的话，可以再合并到一个预发布分支上，最后再合并到trunk的正式发布分支上。
运维：运行 测试给的编译部署脚本，再配置参数，再启动服务器.
这样做的好处就是开发不用在主干上开发，不用合并2次代码，测试方便，运维还是只要配置参数运行测试写的部署脚本，再加上自己的脚本做下操作启动服务就可以了的。

问题列表