使用Thrift的网络框架搭建一般性网络应用

Idea的提出

Thrift 存在的一些问题:

  • 相比于protobuf,Thrift的序列化和反序列化性能表现欠佳,大概比protobuf慢10倍。
  • 相比于其他RPC框架,Thrift拥有优秀的底层通信框架。(作者简单比较过thrift和grpc1.0的通信框架,grpc的设计实在太过简单。)

由此提出猜想和假设:

  • 将 Thrift 的底层通信框架抛离出Thrift框架,利用其来构建一般性的网络应用。
  • 组合 Thrift 的底层通信框架 和 protobuf序列化协议,使之成为一个新的RPC框架。

从实现难度和工作量上的考虑,本文尝试实现第一个假设,“将 Thrift 的底层通信框架抛离出Thrift框架,利用其来构建一般性的网络应用”。第二个假设希望日后,作者在时间和精力富余的时候再进行试验。

使用Thrift的网络框架搭建一般性网络应用的优点

  • 快速搭建网络应用,节省时间成本
  • 当Thrift协议序列化和反序列化成为系统性能瓶颈时,可对其进行替换,同时又能保留Thrift的网络框架,减少对上下游系统的影响

如何操作

有两种方法:

  • 在IDL文本中,将自定义协议的结构体存为一个thrift的string变量。
  • 构建自定义的Processor类

下面对这两种方法做详细介绍:

在IDL文本中,将自定义协议的结构体存为一个thrift的string变量

举例:

namespace cpp com.thrift.test

struct Parameter{
    1: required string bin_data;
}

service DemoService{
    i32 demoMethod(1:string param1, 2:Parameter param2);
}

将新的协议序列化后的数据放入bin_data中,这种方法缺点是,自己定义的协议,还要被thrift的序列化反序列协议包裹,不能完全消除thrift序列化和反序列化的代价。

第一种方法太过简单和粗糙,因此经过挖掘thrift代码后,探索出了更精细的方法。

构建自定义的Processor类

Thrift 底层通信模块的四大基类,TServer、TProcotol、TProcessor、TTransport,其中TProcessor::process是负责处理具体业务逻辑入口。

class TProcessor {
 public:
  virtual ~TProcessor() {}

  virtual bool process(boost::shared_ptr<protocol::TProtocol> in, 
                       boost::shared_ptr<protocol::TProtocol> out) = 0;

  bool process(boost::shared_ptr<apache::thrift::protocol::TProtocol> io) {
    return process(io, io);
  }

 protected:
  TProcessor() {}
};

因此,只要自定义实现TProcessor的基类,重写process方法,就能自定义自己的网络应用。

下面是一个Hello world应用的简单实现:

首先实现一个HelloWorldProcessor 类。’

class HelloWordProcessor : public apache::thrift::TProcessor {
public:
  virtual bool process(boost::shared_ptr<apache::thrift::protocol::tprotocol> in, boost::shared_ptr</apache::thrift::protocol::tprotocol><apache::thrift::protocol::tprotocol> out) {
    out->writeBinary("Hello world!");
    out->getTransport()->flush();
    out->getTransport()->close();
    GlobalOutput.printf("send bytes %s", "Hello world!");
    return true;
  }
};

然后构建main函数,本实例使用TSimpleServer模型

using namespace std;
using namespace apache::thrift;
using namespace apache::thrift::processor;
using namespace apache::thrift::protocol;
using namespace apache::thrift::transport;
using namespace apache::thrift::server;
int main(int argc, char **argv) {
boost::shared_ptr<tprotocolfactory> protocolFactory(new TBinaryProtocolFactory());
boost::shared_ptr<tprocessor> processor(new UwsgiProcessor());
boost::shared_ptr<tservertransport> serverTransport(new TServerSocket(9090));
boost::shared_ptr<ttransportfactory> transportFactory(new TBufferedTransportFactory());
TSimpleServer server(processor,
  serverTransport,
  transportFactory,
  protocolFactory);
printf("Starting the server...\n");
server.serve();
printf("done.\n");
return 0;
}

最后编译、链接和运行。

简单实现一个socket客户端,发送请求,就能得到HelloWord。

性能测试

待完善

Thrift 底层通信框架的优化和调优

待完善

本文小结

作者写本文,正是在工作中遇到了一些真实的问题,比如thrift序列化反序列化慢,thrift底层那么优秀的通信框架如何更高的加以利用呢?因此带着工作中的一些问题,开始阅读thrift的源代码。

除了本文中的一些实例,作者还做了一个小的代码库,里面就用到了本文中的方法,单独使用了thrift了网络框架,Github地址如下:https://github.com/zuocheng-liu/GI

AE-Memcached 优化记录

优化背景和目的

  • 学习Memcached 代码
  • 将 Memcached 的代码成为自己的技术积累
  • 优化Memcache 代码,提高自己系统分析能力

源代码托管于Github上:

https://github.com/zuocheng-liu/ae-memcached

性能优化

网络模型的优化

  • 网络IO多路复用 + 单线程

  • 将 Redis 异步库 移植至 Memcached

优化动态申请内存机制

  • 使用预分配,减小系统调用 malloc、realloc、free的次数,主要出现在新建/关闭链接时,会有较多的系统调用

部分小的函数使用宏代替

优化Memcache协议命令的解析

  • 调整各个命令的解析顺序,把get 和 set 命令放到最前面

软件架构优化

软件架构优化,保证关键代码性能不变

使用宏加强代码复用

  • 重构verbose日志
  • 重构网络库
  • 重构slab

命令模式重构 Memcache 协议

  • 创建command_service类,统一管理命令的解析、处理

更深层次的抽象

将 stats 、 settings 、 logger 和全局资源进行抽象

解耦

  • 将各个模块接口化,减少模块间耦合,尤其是 slab item memcached之间的耦合
  • 依赖注入原则,增强各个模块的复用,其中mem_cache模块 settings等可以形成框架。
  • logger
  • command service

Rest – 架构风格与基于网络的软件架构设计 – 总结

简介

本文内容是博主的一篇读书笔记。读的书是Roy Thomas Fielding的博士论文 Architectrual Styles and the Design of Network-based Software Architectures (《架构风格与基于网络的软件架构设计》)。

为什么想读这篇论文?主要因为REST架构风格和Restful的框架,在Web系统设计中越来越流行。 Rest这个词,在软件研发人员之间,尤其是博主周围同事、同学之间,不断被提起,可见其影响之大。学习追踪了一下Rest,知道Rest架构风格最早由Fielding在他的博士论文中提出,于是就开始读这篇论文。

本博客可以成为一篇论文的导读,想阅读但未读 Fielding博士这篇论文的读者,希望本博客能给您帮助。

阅读此论文前的一点准备和对论文的一点小总结

Fielding博士的论文写成的时间在2000年,猜测Rest的概念形成时间比2000年还早。

而本博客写于2015年末,与论文写成已有十几年间隔,互联网领域里,无论是行业还是技术,发展太快,好多东西估计也让Fielding难以预料。2000年时,有很多概念并不明朗,好多软件还没有出现,因此论文中有一些东西,让现代的人看很具体,但论文中却写的并不清楚。

读Fielding博士的论文最好立足于2000年的环境下,从现在(2015年)的角度看论文里的内容,论文里有超前也有滞后的内容,有技术领域里早已被人熟知的概念,也有经典不变的原理和原则。

所以,最好用选择性的并略带批判的观点去看这篇论文,从中找寻具有价值的内容,并鉴别已经过时的内容。

论文目录及各章内容简单总结

第一章 软件架构

软件架构中,被用到的一些概念、术语。

第二章 基于网络应用的架构

话题范围缩小,关注基于网络应用的架构。谈及7个方面的架构属性,可作为评估一种架构优劣的7个维度。

第三章 基于网络的架构风格

话题范围进一步缩小,聚焦基于网络的架构风格。列举了很多种架构风格,并用上一章的提到的7个维度,对它们进行简单评估。

第四章 设计Web架构:问题与洞察力

提出Web系统的架构风格需求,比如需要满足容量大、可伸缩性强。(后面提出Rest风格正是满足了这些需求。)

第五章 表述性状态转移

博主认为,这是这篇论文的核心内容。

主要讲了Rest风格的具体内容,从5个方面约束和规范Web架构。

在描述Rest风格的时候,论文用了一个很特别的例子,这个例子是讲述了一个架构,从无到有,再从简单到复杂演化的过程。过程中,这个架构每一步变化都使用Rest风格来约束它,让架构表现出了很好的可伸缩性。论文中称这是Rest风格的推导过程。

Rest 风格的约束

  • 无状态, 请求的上下文无关
  • 缓存约束,缓存约束于客户端
  • 统一接口,Rest 风格核心特征
  • 分层系统,添加中间层和中间层约束。(类似于现在的Proxy 和 Proxy+缓存,比如nginx、nginx+cache、 msyql proxy、file proxy)
  • 按需代码。按照现在的理解则是,让B/S架构,替换掉以前的C/S架构。

第六章 经验与评估

这一章内容有些杂乱。

论文具有局限性的内容

  • Cookie 违反了Rest (6.3.4.2)
  • 会话状态全部保存在客户端
  • 缓存约束于客户端, 可靠性降低
  • 特别适合分布式超媒体系统

问题总结

  • Web应用程序的无状态性

    http协议作为技术背景的web应用程序请求——应答模式是无状态的

    web应用是有状态的,session、cookies等状态机制+其他辅助的机制(违反Rest)

  • 经常被谈及的Rest风格的URL是Rest定义的吗?

Rest风格是抽象的,而经常被谈及Rest风格的URL,只是遵从Rest风格的一种具体实现,Feilding博士的这篇论文里并没有具体去谈。

  • Rest 风格推荐HTTP中的GET,POST,PUT,DELETE对资源进行访问和控制是吗

此篇论文里并没有具体去写这个问题

后记

博主第一次听人提起 Rest 是 2012年时,当时博主刚大学毕业参加工作,在公司里听前辈工程师们谈起Rest。可惜博主3年后才开始主动去学习有关Rest的内容。

虽然读完了Feilding博士的论文,但是感觉Rest的内容好像不仅有这些,可能是其他人的补充,再去学习下。

2015年12月14日

线程安全的单例模式-以C++代码为例

本文描述3种场景下的单例模式:

  • 进程体内无线程的单例模式
  • 进程体内多线程单例模式
  • 在单个线程体中的单例模式

本文所写单例模式代码都使用懒汉模式。

进程体内单例

注意问题:

  • 如果进程体中运行多个线程,则需要考虑多线程同步访问的问题。
  • 如果进程体重没有运行多个线程,则不需要考虑多线程同步访问。
  • 使用线程同步锁保证多进程同步

使用场景举例 :

  • 日志类、文件读写类
  • 资源管理类

代码示例:

进程体内没有运行多线程的单例模式,无需考虑线程同步与互斥

class Singleton {
  public:
    static Singleton* getInstance() {
        if (NULL == instance) {
          instance = new SingletonInside();
        }
        return instance;
    }
  private:
    SingletonInside(){}
    ~SingletonInside() {}
    static Singleton* instance;
};

Singleton::instance = NULL;    

进程体内运行多线程单例模式,使用系统mutex保证线程安全

class Singleton {
  public:
    static Singleton* getInstance() {
        pthread_once(&g_once_control, InitOnce);
        pthread_mutex_lock(&mutex);  // lock
        if (NULL == instance) {
          instance = new SingletonInside();
        }
        pthread_mutex_unlock(&mutex); // unlock
        return instance;
    }
  private:
    SingletonInside() {

    }
    ~SingletonInside() {
       pthread_mutex_destroy(&mutex);   // destroy lock
    }
    static void InitOnce(void) {
      pthread_mutex_init(&mutex,NULL);  // init lock
    }
    Singleton* instance;
    static pthread_once_t g_once_control;
    static pthread_mutex_t mutex;
};
Singleton::instance = NULL;
pthread_once_t Singleton::g_once_control = PTHREAD_ONCE_INIT;

单个线程体中的单例

某些资源在单个线程体内需要保持单例,即每个线程体内都保持唯一。每个线程体内,对象相互隔离,则无需考虑线程安全问题。

此种单例模式的实例需要调用系统提供的 TLS 接口,放于线程局部存储中。

使用场景举例:

  • 多路复用Socket封装类
  • 网络上下文环境类
  • 线程安全的资源

代码示例

class Singleton {
  public:
    static Singleton* getInstance() {
       pthread_once(&g_once_control, InitOnce);
       Singleton* instance = (Singleton*)pthread_getspecific(g_thread_data_key);

        if (NULL == instance) {
          instance = new SingletonInside();
          pthread_setspecific(g_thread_data_key, (void*)Singleton)
        }
        return instance;
    }
  private:
    SingletonInside() {}
    ~SingletonInside() {
       pthread_key_delete(g_thread_data_key);
    }
    static void InitOnce(void) {
      pthread_key_create(&g_thread_data_key, NULL);
    }

    static pthread_once_t g_once_control;
    static pthread_key_t g_thread_data_key;
};

pthread_once_t Singleton::g_once_control = PTHREAD_ONCE_INIT;
pthread_key_t Singleton::g_thread_data_key;

如果使用 Poco库 TreadLocal ,代码还会简洁很多,性能上也会好很多

    class Singleton {
      public:
        static Singleton* getInstance() {
            if (NULL == instance) {
              instance = new SingletonInside();
            }
            return instance;
        }
      private:
        SingletonInside() {}
        ~SingletonInside() {
           delete instance;
        }
        static Poco::ThreadLocal<Singleton> instance;
    };
Poco::ThreadLocal<singleton> Singleton::instance = NULL;

总结

  • 无论程序是多进程运行还是多线程运行,代码都要尽量兼容线程安全

不同设计模式的适用场景总结

软件设计过程中,该选择那种设计模式,除了借鉴直接的经验,还可以从以下方面考虑:

  • 领域对象模型中,类之间的关系是什么(继承、实现、关联、依赖、组合、聚合)
  • 容易变化的部分是什么,即易于扩展的部分
  • 不容易变化的部分是什么,即需要复用的部分

按照我们的思路,设计模式之所以多种多样,就是对应的领域模型中上面三个方面有很大不同。把握住以上几点,就能正确地选用设计模式

门面模式,Facade Pattern

  • 门面类和被门面类封装的类之间是继承或者依赖关系
  • 类的内部接口、内部逻辑经常变化;不被需要的对外接口容易变化;
  • 类的对外部接口不容易变

适配器模式, Adapter Pattern

  • 适配器类和被适配的类之间是继承或者依赖关系
  • 需要适配的类,或者其接口容易变化
  • 适配的类的接口不容易变化

原型模式, Adapter Pattern

  • 不同类之间有共同的父类
  • 类的部分属性、方法容易变化
  • 类的另外一部分属性、方法不容易变化,且构建复杂,成本很高

单例模式,Singleton Pattern

  • 类在全局唯一存在,其他类与单例类是
  • 类的唯一性不会变化

多例模式,Multition Pattern

  • 多例类的对象之间是聚合关系
  • 多例类的对象的数量容易变化

策略模式,Strategy Pattern

  • 对象和算法,是依赖关系
  • 逻辑框架不容易变化
  • 策略算法容易变化

代理模式,Proxy Pattern

  • 代理和被代理的类之间是依赖关系
  • 代理者的接口不容易变化
  • 被代理者的接口具体实现容易变化

工厂模式,Factory Methond Pattern

  • 工厂模式产生的对象一般有相同的父类(继承关系)
  • 由工厂产生对象不会变
  • 工厂产生对象所属的类的种类是不断变化(增多或减少)

抽象工厂模式,Abstract Factory Pattern

  • 同工厂模式
  • 变化的是,工厂创建对象所属的类的接口会不断变化

门面模式,Facade Pattern

  • 封装类和被封装的类之间是依赖关系
  • 接口类(封装类)的接口不容易变化
  • 实现类(被封装的类)的接口容易变化

Adapter Pattern

  • 同门面模式
  • 适配器类更倾向于兼容现有系统的接口需求

模版模式,Template Method Pattern

建造者模式,Builder Pattern

  • 构建、配置、注入依赖容易变化,且较复杂

桥梁模式,Bridge Pattern

命令模式,Command Pattern

装饰模式,Decorator Pattern

迭代器模式,Iterator Pattern

组合模式,Composite Pattern

观察者模式,Observer Pattern

  • 观察者和被观察者是关联关系
  • 被观察者的数量或种类容易变化

责任链模式,Chain of Responsibility Pattern

访问者模式,Visitor Pattern

状态模式,State Patter

原型模式,Prototype Pattern

中介者模式,Mediator Pattern

解释器模式,Interpreter Pattern

亨元模式,Flyweight Pattern

备忘录模式,Memento Pattern

MVC框架-路由分发总结

路由的类型 Route Type

无路由 No Route

HTTP请求直接定位到特定的脚本文件执行。比如http://domain/news/latest.php

动态路由

依据某种动态规则进行路由和分发,一般有如下形式:

强约束URL

将Class,function 等信息隐藏在url中,请求来时,依据规则解析URL就可以定位Action函数,比如http://domain/modelName/className/functionName

优点是简单,缺点是灵活性差,路由信息包含的少,比如拦截器、模版只能在action中写代码调用,不能集中配置。

依据注释信息自动路由

将路由信息,写到执行函数的注释里,请求来时,解析所有action函数的注释,找到合适的,再执行action函数。 Java Spring 和 PHP Symonfy 支持这种路由方式

注释的关键字有(举例)

  • @url
  • @template
  • @filter
  • @trigger

优点是维护起来比路由表简单,缺点是性能较低。

静态路由

路由配置写在配置文件中,依据配置文件,确定如何分发。

路由信息配置在配置文件中,文件或数据格式如下:

  • PHP
  • Yaml
  • Xml
  • Json

笔者最推荐的是 Yaml,因为Yaml 格式的可读性最高,最易于维护。

半静态半动态路由

动态和静态相结合的路由.

尤其是在URL解析中,使用正则匹配的路由方式。

路由的组成 Route Components

路由分发的元素

  • URL , URL特征决定分发到特定Action函数
  • Action 函数,函数所在的class、Namespace
  • 模版 template ,页面渲染的模版
  • 拦截过滤器,Filters , 比如权限检查、地区检查、无效请求检查等各类filter
  • 触发器,triggers , 页面调用后触发的操作

URL 的组成

URL 包含着路由的关键信息,决定请求分发到具体的Action函数

MVC 框架的 URL 一般由下列部分组成

  • 域名 domain name
  • 模块/目录 model/directory name
  • 功能 function name
  • 参数 parameter

参数有两种形式存于http请求中,一种是作为POST和GET方法的参数,一种是直接在URL中。

Route Style

Restfull 的路由分发

遵循Rest 风格、规范的URl

普通的路由分发

企业应用架构之分层 – 总结

常见分层架构模式

三层架构 3-tier architecture

微软.net 体系推荐的分层结构,因此早期在C/S架构和ASP编码的系统中被广泛应用,同时也被其他语言广泛借鉴。

表现层, Presentation Layer(PL)

主要负责数据的输入接口和输出。输入指在WEB、客户端或为外界提供的API的数据请求接口;输出则是Web界面、客户端输出、API的数据输出。

页面模版、 对外API数据格式化、Request接受 、Output推送、 Commander操作都在这一层。

业务逻辑层, Bisiness Logic Layer(BLL)

主要负责从原始数据到结果数据的中间过程。系统中最关键、中重要的一层。也被称作领域层(Domain Layer),领域中所有对象的逻辑关系和功能实现算法都在这一层中。

业务逻辑、服务等处于这一层。

数据访问层, Data Access Layer(DAL)

主要是对原始数据的操作层(CRUD操作),为业务逻辑层或表示层提供数据服务。数据源包括,数据库、文件、网络存储系统、其他系统开放的API、程序运行上下文环境等等。

许多框架中的ORM 、 Active Record 、 Dao 类或库都处于这一层。

三层架构总结

三层架构能较好的满足大部分的业务场景,实现高内聚、低耦合。不同层次之间逻辑解耦或者隔离,变为弱依赖,每层的逻辑内聚。从层次角度看,使系统有了较好的可扩展性。

三层架构的不足有:

  • 业务逻辑复杂度高的系统,业务逻辑层将变得庞大臃肿,为了解决这个问题,四层架构/多层架构被人提出。
  • 不关注表现层的实现。

四层架构 4-tier architecture

四层架构和三层架构极为类似,分为表示层、服务层、业务逻辑层、数据访问层。除了服务层,其他三层和三层架构的三层几乎一致,而服务层,是对三层架构中业务逻辑层的再细分,以解决业务逻辑层经常出现的臃肿的问题。

四层架构是Java EE(J2ee) 推荐的分层架构,尤其是Java Spring+Struct+Hibernate(SSH)组合的框架 将Dao层、 Service层,做了明确的定义和规范。由于SSH框架被广泛使用,其他框架,包括其他语言的框架(比如PHP)也都借鉴SSH,因此在这些框架里能看到Dao类、Service类的抽象定义。

服务层, Service Layer

在三层架构中,把业务逻辑层的上层逻辑分离出来,组成服务层。服务层往往是逻辑的表示层,即向上层(表示层)提供逻辑的外观。事务控制、安全检查、事务脚本等可以置入业务层(参考Martin fowler 的《企业应用的架构模式》)

四层架构总结

四层架构是三层架构的发展或进化。服务层的出现让三层架构的业务逻辑层不再变得臃肿。

四层架构和三层架构都存在一个不足,就是不强调前端的实现。当面对需要个性化定制界面、复杂用户交互、页面之间有依赖关系时,需要更好的解决方案。

MVC 模式

MVC 模式最主要包括三部分,Model View Controller(模型-视图-控制器)。

相比于三层架构或者四层架构,MVC最突出的优点是前端控制的灵活性。如果把MVC的View和Controller剥离出来,实际上是一种叫前端控制器模式的设计模式。

MVC 的缺点很明显,将前端以外逻辑都放到 Model里,随着业务增多,Model将越来越难以维护。

MVC 并不适合称作一种分层架构,更适合称为一种复合的设计模式。有人还将MVC模式归类为前端架构。

为什么MVC模式被广泛的采用? 笔者是这样认为的:

  • MVC模式最适合新闻门户网站、展示类网站,此类网站业务逻辑往往较为简单。
  • MVC模式最适合产品初创时被使用,因为项目初期逻辑简单, 使用MVC模式产品能快速成型,可以尽早投放市场进行试验(多数可能会被淘汰),这样就降低了试验成本。(如果产品有潜力,中后期随着业务增多和变得复杂,系统必然面临重构压力。)
  • MVC模式最适合产品原型的实现(注重前端)。

其他分层架构

除了三/四层架构,MVC模式,还有很多架构模式,但这些多是与三/四层架构、MVC模式类似,或是在他们之上进行扩展和改造。比如 MVVM (Model-View-ViewModel)、MVP、DDD架构模式等。

关于分层的总结

分层的思想或目的

  • 高内聚
  • 低耦合
  • 增强系统的可扩展性
  • 增强系统的可维护性

分层的优点

  • 开发人员可以只关注整个结构中的其中某一层;
  • 可以很容易的用新的实现来替换原有层次的实现;
  • 可以降低层与层之间的依赖;
  • 有利于标准化;
  • 利于各层逻辑的复用;
  • 结构更加的明确;
  • 在后期维护的时候,极大地降低了维护成本和维护时间

分层的缺点

相比于分层的优点,分层的缺点显得微不足道。

  • 使用分层虽然增多了代码量,但清晰的架构和代码复用却降低了开发成本、维护成本。
  • 分层虽然在逻辑上增多了代码的调用、增多了逻辑分支,降低了性能,但是这部分降低的性能与系统中真正的性能瓶颈(存储IO、网络IO、高层次的语言)相比,显得实在渺小。
  • 分层有时会导致级联的修改,但这种情况是可以通过面向接口的设计或者使用中介者模式、门面模式、适配器模式等设计模式解决。

如何设计分层架构

  • 软件的发展都是遵循着从简单到复杂的过程,软件架构也是一个迭代的过程,是一个循序渐进,不断完善的过程。简而言之,不断地重构。
  • 借鉴或者直接使用Java EE(j2me)的分层规范,并使用dao、service等类的命名。
  • 层与层之间交互部分,要遵循面向接口设计的原则,不吝舍使用设计模式。
  • 分层的选择要平衡成本和风险,使收益最大化。
  • 业务逻辑不要局限于四层架构或三层架构,依据领域业务特点可更细地划分层次。

什么是设计模式 – 总结

设计模式是如何诞生的?

  • 领域中有些东西是不变的,有些是不停变化的
  • 不变的东西和变化的东西之间,总存在着某些特定的关系,符合某种特定的规则和规律
  • 因为这些特定关系,经验丰富的设计者总在做重复的设计,也不断地复用自己的设计。他们为了设计的通用,也提出了非常好设计
  • 没有经验的设计者,却察觉不到这些关系,做不出好的设计
  • 经验丰富的设计者向没有经验的设计者传授好的、被重复使用的设计和经验,并讲述那些事物之间某些亘古不变的关系,这些就是设计模式的雏形
  • 将这些关系和设计进行整理和总结之后,设计模式诞生了。

设计模式是什么?

  • 是对程序设计人员经常遇到的设计问题的可再现的解决方案(The Smalltalk Companion)
  • 建立了一系列描述如何完成软件开发领域中特定任务的规则
  • 关注与复用可重复出现的结构设计方案
  • 提出了一个发生在特定设计环境中的可重复出现的设计问题,并提供解决方案
  • 识别并确定类和实例层次上或组件层次上的抽象关系

设计模式的作用?

  • 让开发人员能够控制系统的复杂度,不至于失控
  • 增强设计的可伸缩性/可扩展性(Scalable/scalability)
  • 增强设计的复用
  • 设计领域的通用语言(传递、沟通),设计模式具有很强的业务表述力

初学者掌握设计模式的方法

  • 模仿 – 最快的方法,学习和内化都比较迅速
  • 学习书本 – 比较而言学习较快,内化很慢
  • 不断重构自己的代码,自己去领悟设计模式 – 学习效率最慢,但是理解最透彻,内化效果最好的方法
  • 团队讨论、交流共享 – 学习较快、内化较快,但是时间成本很高,而且团队讨论往往不是高频率的活动

如何提升自己使用设计模式的能力

  • 学习设计模式的使用场景,简单地使用常用的设计模式
  • 改造设计模式,使之更好地满足业务场景
  • 总结业务场景,创建和组合新的设计模式
  • 将重复使用的设计模式及设计模式组合,创建框架。框架形成后,完善和丰富它。
  • 总之,把设计模式使用好,离不开经验,离不开积累
  • 在经验和积累之上,再创新。发现和创造新的模式、新的思想,并将这些新东西注入框架。

主流MVC框架的设计模式及遵守的软件设计原则

摘要

本文以主流的MVC框架为例,比如Java 的SSH、PHP的Symfony和Zend Framework ,在简单地剖析他们的设计原理之后,找到其中使用的设计模式;鉴赏他们的代码实现,查看设计者们都遵守了哪些软件设计原则。作此文,一为学习,二为总结。其中下面所写内容可能并不全面,也可能不准确,但会不断修改完善。

框架模式


MVC 模式

  • y = f (x)
  • View/Response = Controller (Model, Request)

Active Record 模式

  • Yii Active Record
  • Ruby on Rails Active Record

ORM 模式

  • PHP 的 Doctorine
  • Java 的 Hibernate

三/四层架构,3/4-tier Architecture

  • MVC 框架会借鉴三/四层架构的分层思想,对整个系统进行分层,最常见的是在 Model 层中再细分层次。
  • SSH 的 DAO/JavaBean、Service、Response 等
  • Symfony 2 的 Doctrine、Service、view 等

设计模式的使用


前端控制器,Frontend Controller Pattern

拦截过滤器模式,Intercepting Filter Pattern

复合模式,Compound Pattern

  • MVC框架如果不使用复合模式,本文也没有任何意义了

单例模式,Singleton Pattern

  • Controller 、 Context、 View 等框架核心类使用了单例模式

多例模式,Multition Pattern

  • 各类资源池、进程池、线程池(PHP 的后面两个用不上)

策略模式,Strategy Pattern

代理模式,Proxy Pattern

  • 抽象类的使用

工厂模式,Factory Methond Pattern

Action 对象的创建

抽象工厂模式,Abstract Factory Pattern

  • ajxaAction 、 WebAction 、 APIAction 以及 ajax和web组合的Action 或者 ajax和API组合的Action,复杂的框架会使用抽象工厂模式

门面模式,Facade Pattern

Logger 类,将第三方开源Logger类封装统一接口,将第三方 Logger 繁冗接口屏蔽

适配器模式,Adapter Pattern

  • Zend Framework 的 Zend_Db_Adapter 类,将具体不同的数据库(Mysql、Oracle、SQLite)类接口通过Driver类封装,为上层提供统一接口
  • Zend_Cache 对不同cache的接口的再次封装

模版模式,Template Method Pattern

  • 各种复杂逻辑的抽象类
  • 框架的扩展类

建造者模式,Builder Pattern

  • 依赖注入原则的遵守和实践,将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
  • Content 对象的创建者是 Controller
  • Config 对象的创建
  • ORM 的 Object 对象创建

桥梁模式,Bridge Pattern

命令模式,Command Pattern

  • Http 请求的解析就是命令模式
  • Symfony 2 的 Console
  • Symfony 2 的 Command 类

装饰模式,Decorator Pattern

  • ajxaAction 、 WebAction 、 APIAction 以及 ajax和web组合的Action 或者 ajax和API组合的Action

迭代器模式,Iterator Pattern

  • 路由设置的遍历

组合模式,Composite Pattern

观察者模式,Observer Pattern

  • 各种 Trigger 类
  • 各类自定义的扩展

责任链模式,Chain of Responsibility Pattern

  • 路由的解析,尤其是Restful风格的URL,依据路由表(责任链),定位Action 类和方法

访问者模式,Visitor Pattern

状态模式,State Patter

原型模式,Prototype Pattern

  • Action 中,讲执行权移交给另外一个 Action ,比如redirect 或者 forward,获得执行的Action还要和原有Action的属性、状态、上下文一致。原型模式是比较好的选择。

中介者模式,Mediator Pattern

  • 充当中介者的类是 Context,某些框架Context类,为Request、Respose、GlobalConfig 等等单例类进行抽象,为业务代码提供唯一的调用方式,即Context的类提供的接口

解释器模式,Interpreter Pattern

亨元模式,Flyweight Pattern

  • 通用状态类
  • 各种 Util 类
  • HTTP meta 类、特殊字符享元归类

备忘录模式,Memento Pattern

  • 系统日志、状态,以支持回滚
  • 数据库事务

软件设计原则 SOLID


单一职责原则(Simple responsibility pinciple SRP)

开-闭原则(Open-Closed Principle, OCP)

里氏代换原则(Liskov Substitution Principle,LSP)

迪米特法则(Law of Demeter LoD),最少知识原则(Least Knowledge Principle,LKP)

接口隔离原则(Interface Segregation Principle, ISP)

依赖倒置原则(Dependence Inversion Principle)

  • 建造者模式的使用
  • 路由表的使用,或其他各种配置都收集到配置文件中,使用依赖注入容器,实现代码和实现的解耦

Service Locator Patten 总结

核心思想

将构建依赖的接口彻底与依赖者分离,并将此依赖作为“服务”绑定到一个标识符,而后依赖者则可通过这个标识符获取被绑定的依赖。

优点

  • 上层逻辑不依赖于服务接口的具体实现,实现解耦
  • 提高系统的可扩展性
  • 逻辑分层更加简洁清晰,使不同层次的开发人员各司其职,提高团队开发效率

适用场景

与 (Abstract) Factory Patten 比较

  • Factory Patten 创建的所有结果对象多有统一的抽象接口的(更具一般性的)对象
  • Service Locator Patten 创建的服务,异构性程度比较大,接口缺少一般性
  • Factory Patten 单纯为创建对象
  • Service Locator Patten 职能更多些,包括创建服务、配置服务、注入服务的依赖等等

与 Dependence Injection Container 配合

  • Service Locator Patten 和 Dependence Injection并不互斥
  • Service Locator Patten 在定位服务时,创建服务、配置服务、注入服务的依赖通过Dependence Injection Container实现,可以进一步解耦

与 Proxy Patten 配合

  • 对创建的服务进行抽象,增强服务的一般性(即抽象出统一接口)

与 Singleton Patten 配合

  • 承担特定职责的Service Locator的对象无需多次实例化,节省开销
  • 对Service Locator定位的服务缓存做集中存储,存储数据结构存于Service Locator的单例对象即可

优化和扩展

  • 与多种设计模式配合使用
  • 在Service Locator类里定义服务实例化对象的缓冲池,使服务只实例化1次,节省开销

代码示例

symfony2 framework 使用总结

安装

The following exception is caused by a lack of memory and not having swap configured

  • 内存不足
  • 将PHP环境变量memory_limit调大,增大swap 交换内存

Compile Error: Cannot redeclare class Symfony\Component\Debug\Exception\FlattenException

  • 重复定义类名
  • ./vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Exception/FlattenException.php
  • ./vendor/symfony/symfony/src/Symfony/Component/Debug/Exception/FlattenException.php
  • 暂时不要使用Dubug功能了吧

php app/console doctrine:schema:update –force

配置symfony2\app\config\config.yml

mapping_types:
enum: string
set: string
varbinary: string
tinyblob: text

后台自动任务设计和编码总结

资源预估

  • 预估数据量、算法的时间、空间复杂度
  • 依据预估的结果分配合理的资源(内存,CPU),避免资源不够用。

避免数据脏读

自动脚本处理大量数据速度快,尤其有写操作的任务,数据一致性在分布式环境下往往难以保证。这种情况下应该避免数据脏读,比如数据库会有主从复制同步延迟的现象,这时应该强制连接数据库主库。

幂等性

有写操作的脚本,需要考虑脚本执行的幂等性,即在输入相同参数多次运行与运行一次的结果相同。 保证幂等性具体应该考虑一下几点:

  • 逻辑上,检查待处理数据的状态,已经处理过的数据不再处理。
  • 禁止并发运行,不允许运行多个进程同步运行同一任务。如何保证?信号量、Memcache加锁。

参数控制

  • 在设计阶段,应该通过参数控制,限制脚本的操作范围。参数可以是时间,自动脚本周期运行,每次运行,只处理相应周期范围内的数据。
  • 注意默认参数的参数值。

读并发

自动脚本处理速度快,在和其他系统进行交互时,会对其他系统产生大量而密集的请求。

  • 要考虑其他系统的抗并发能力
  • 合理限制单位时间对其他系统的访问次数
  • 尽量将数据集中做批量请求,减少请求次数
  • 在本地做缓存,消除重复的请求。

容错 和 错误处理

  • 容错 自动脚本往往批量处理大量数据,循环处理每条数据。在单次循环中的错误或异常,应该全部捕获,并记下日志,让脚本继续运行。
  • 日志 记录重要操作,包括info、warning、error等级所有日志,形式可以是文本记录或数据库,便于追查和报警。

备灾和数据修复

  • 在不可抗拒因素(断电,其他原因宕机)等引起任务中途突然停止,应该依据日志定位、和追查处理到哪一阶段。修复错误数据。
  • 在保证脚本幂等性的前提下,重复执行脚本可自动处理未完成的工作。

优化

随着业务增长,任务处理数据量越来越大,可能会出现,任务超时,内存不够用的情况,应该及时对自动任务进行优化,优化的方案可以从算法、业务架构上考虑。