面向对象，服务器架构，设计模式探讨
转载自：http://hi.baidu.com/wind_stay/blog/item/fe9db22c5b44b03e359bf75b.html
面向对象，服务器架构，设计模式探讨
鹦其鸣声，求其友矣
原著：吕跃强 版权申明：完全属于吕跃强，任何转摘和引用必须指明出处
主 要 内 容
n 1 服务器本身的架构
n 2 设计模式，面向对象在服务器开发中的应用
参考：
网络的基础架构: ACE
高效的并发服务器结构： apache（session独立性较高）
特殊应用服务器 : darwin 流媒体服务器，
1 服务器架构的探讨
1.1迭代vs并发vs混合
迭代：那些对每个事件的处理时间短暂、简单。Session处理不复杂，并且可以分解为多个短暂步骤 ，并且分开处理
并发：session复杂。Session中的阻塞不确定，session上下文复杂。如：对某个中转的session处理，收到read请求，然后与数据库交互，然后与加密机交互，然后向服务器提交请求，读取服务器应答，再加密机交互，数据库，然后向客户端回应。像这种建议用多线程。
混合：平时迭代处理，对消耗大的请求并发处理
1.2 多线程VS多进程
n 多线程：效率高，占用资源小。共享地址空间，线程间影响大
n 多进程：效率低，占用资源大。但是安全，稳定性高。
n Apache 是多进程下面的多线程，整合了效率和安全。
1.3 并发分类
n 1.3.1 每个连接pthread_create一次
就是针对每个事件发生时开一个线程处理,处理完了线程退出。这种模式其实效率在有的系统中还是相当可观的，也就是采用原生线程的平台中。
这种模式在一些压力不大的系统中应用还是挺广泛的。而且编成简单。
1.3.2 预创建线程池模式
n 1.3.2.1预创建半同步/半异步（生产者/消费者）模式
由主线程（生产者线程）倾听事件，然后把事件和参数完一个队列里丢。消费者线程读出队列数据进行处理
一般说来主线程处理i/o事件并解析然后再往队列丢数据，然后消费者读出数据进行应用逻辑处理。当然，主线程也可以不处理i/o事件，而把句柄等直接往队列里丢，让消费者来处理i/o和应用逻辑。
优点：简化编程将低层的异步I/O和高层同步应用服务分离，且没有降低低层服务性能。集中层间通信。另外，适合相互交互的session
缺点 ：需要线程间传输数据，因此而带来的动态内存分配，数据拷贝，语境切换带来开销。高层服务不可能从底层异步服务效率中 获益。
n 线程池的调度：可以用操作系统信号量或者条件变量的来，也可以自己管理线程对象，然后由程序具体激活某个线程。
这种模式在很多系统中应用非常广泛
半同步半异步框图
1.3.2.2 预创建领跑者/跟随者模式
n 每次允许一个线程leader等待在事件源集合上。同时其他线程follower 排队等候成为领导者的机会。Leader检测到事件后，马上转入follower并提升一个follower为leader，然后直接处理事件这时处于processer角色，处理完成后成为follower
缺点: 实现复杂性和缺乏灵活性
优点：增强了CPU高速缓存相似性，消除了动态内存分配和线程间的数据交换
需要注意的问题
n 确定句柄类型。UDP并发句柄，TCP socket 为迭代句柄。
n 确定句柄集类型。WaitForMultipleObjects() 是并发的，而select是迭代的
n 事件分离和处理，角色转换。底层操作系统可以将事件在内部排队，直到有leader
n 在OLAP系统中应用非常广。
1.4 内存池的管理
n 重载new/delete
譬如在我的CTcpWrRdSocket中，重载了new实现静态内存池
n 参考STL 配置器allocator 建立动态CMemory类。这个工作还没有做
1.5 服务器几个部分
n 配置文件处理
Apache的配置文件处理系统非常值得深究。 在我的框架中就一个简单类。建议自己继承一个以支持XML格式的配置
n 日志处理
（目前我的日志系统是由C库函数实现的。如果你习惯用<<的话也可以重载<<操作符。需要注意的是endl, hex, showbase等流操作子其实函数。没试过带参数的操作子）
n 边界处理socket （类图在包装器模式一节）
n 事件分离 select epoll_wait （类图在包装器模式一节）
n 线程池 （类图在最后）
n 应用逻辑处理
n 另外服务器的某些子系统可进行动态加载 （ace 和apache）
2 面向对象
2.1 设计方法：面向对象 vs 面向过程
一个程序最重要的要求就是能满足需求并且健壮的跑。对于此无论是面向对象和过程都能很好的满足。
误区：面向对象方法设计出来的软件一定比面向过程的具有更高质量。
误区： 只要学好vc++ 就能精通面向对象的设计方法
当然以后面对类似的需求，我们希望快速的高质量的搭建新系统。这样对软件的扩张性和维护性就提出了相当的要求，这时面向对象的设计方法就大行其道了。而面向过程就显得吃力。
误区：只要用了类（有的仅仅是类，就连继承都没有，更不用说多态了），就是面向对象了。
其实用了类只是基于对象编程
n 面向过程一般按照功能进行分解，最后分解成函数。这样在非常大的软件系统中存在极大的耦合（外部变量，函数耦合），并且难于管理，且扩张性和维护性不高。就是变量名和函数名管理就很头痛。而现实世界中的物体往往是属性和行为的复合体。所以面向过程适合那些以功能操作为主，对扩张性要求不高的系统。
n Rational统一过程（RUP）：起始，细化，构建，移交的不断重复过程。敏捷开发（XP）：其实也就是跌代。这里对象技术至关重要，否则原来的代码无法跌代，得打掉重写。上一个周期的跌代仅是验证了可行性。
n Rup和XP不是培训几周就可以实现的。
2.2 面向对象的原则
n 开闭原则：一个模块对扩张开放，对修改关闭
n 完全替换原则：派生类可完全替换基类
n 非循环依赖原则：包与包直接切忌循环依赖
n 依赖倒置原则：依赖抽象，而不要依赖与具象
n 优先使用聚合，而不是继承
n 为人写代码：代码风格要统一，简洁
开闭原则和依赖倒置原则解释
2.3 面向对象设计
2.3.1 类的粒度：共性 VS 个性
n 日志：日志类的分类根据使用的要求，日志可以远程本地， 滚动 按条，有前缀 无前缀分。远程的还可以TCP UDP分。然后除UDP外所有的类都可以再继承实现一个线程安全的。其实还可以再分。就是这样从类图看就已经非常累赘了。
n 继承的粒度和减少使用者的分枝代码矛盾把握
n 使用聚合减少类的种类（较大不同时）
n 就使用（属性）开关量减少
共性 VS 个性 类粒度的把握
2.3.2 类职责分配
n 通用职责分配软件模式（GRASP）：设计原则的总结和概括。
n 9种职责分配模式：专家 创建者 低耦合 高内聚 控制者 多态 纯虚构 中介者 不要和陌生人讲话
2.3.2.1 不要和陌生人讲话
Class CInerDataWkThread
{
private:
Creator * m_ptReactor;
public:
ThreadFunc(void)
{
if( false==m_bIsStatic )
n {
n if( !SetAynCancel() )
n { return -1; }
n }
n while(1)
n {
n Wait();
n //和陌生人CObserver说话了，错误
n m_ptReactor->GetObserver()->EventProcess(&m_tEventPara);
n // 只和m_ptReactor说话，由m_ptReactor负责和CObserver说话，正确
n m_ptReactor->EventNotify();
n }
n return 0;
n }
n }
2.3.2.2 专家：与封装特性一致
这里m_tQueueTData 暴露在两个类中，导致到处是 Lock UnLock代码
根据专家原则，应该对此单独做一个类使其专门完成此职责
2.4 设计模式：变化之道 vs 永恒之美
n 模式：每个模式描述了一个在我们的环境中不断发生的问题，并且描述了解决该问题的核心方案，这样你就可以多次使用这一解决方案，不必重新劳动。
n 模式的组成：包括名称，解决的问题，方案和使用模式的结果。
n 模式的精髓：1 适应变化 2 针对接口编程，而不是实现编程（其实就是virtual + 继承）3 优先使用聚合而不是继承
2.4.1 模式的分类
n 架构模式：1.1 分层模式 1.2 管道和过滤器 1.3 黑板 2.1 C/S p2p B/S 3. MVC
n 设计模式：
n 类模式：工厂方法，适配器，模版方法，解释器
n 对象模式： 抽象工厂，原型模式，单件，桥接 复合 装饰 外观 享元 代理 命令 跌代器 中介者 观察者 职责链 策略
2.4.2 包装器模式: 通一接口VS暴露细节
n 也叫适配器（adapter）
n 定义: 将一个类的接口或一组API转换成用户希望的另外一个接口。
n 标准的可以以继承或聚合的方式实现，推荐聚合
2.4.3 桥接模式
n 一个抽象有多个实现时，通常用继承协调。抽象类定义接口，具体子类则用不同的方式实现，此方法有时不够灵活。继承机制将抽象和实现部分固定在一起。
n 感觉把一一列举变成排列组合，一次一点修改相关全改（举个例子：9个十位数和10个个位数组成90个两位数，不用烈举90个了。我用了10 个数，原来是10-19，现在变为20-29 ，只需1变为2 就可以了）
n 意图：把抽象部分和实现部分分离，使他们可以独立的变化
2.5 观察者模式：间接依赖VS直接依赖
n 谁或何时触发更新，目标的删除，观察多个目标，参数推拉模型
n 观察者在服务器中的变体：显示的指定感兴趣的改变 反应器模式
直接依赖变成间接依赖
2.6单件模式：隐式全局VS显式全局
n 不用释放内存
n 模式介绍：
n 全局变量的头痛
n 自创的多件模式
Class A
{
Public:
Static A *Instance();
~A();
Protected:
A();
Private:
Static A* m_pThis;
}
A *A::m_pThis=NULL;
A *A::Instance()
{
If( NULL==m_pThis)
{ m_pThis = new A(); return m_pThis; }
Else { return m_pThis; }
}
自创的多件模式
class CAnonymSem
{
public:
CAnonymSem();
~CAnonymSem();
static CAnonymSem *GetFirstSingleton(void);
protected:
static CAnonymSem *m_pFirst;
sem_t m_tSem;
};
CAnonymSem *CAnonymSem::m_pFirst=NULL;
CAnonymSem *CAnonymSem::GetFirstSingleton(void)
{
if( NULL==m_pFirst )
{
m_pFirst=new CAnonymSem();
return m_pFirst;
}
else {return m_pFirst; }
}
2.7 模版方法：依赖倒置vs正向依赖
好莱坞原则
class CAppServer
{
public:
void Run(void)
{
Daemon();
SignalInit();
RealRun();
}
protected:
int Daemon();
int SignalInit();
virtual int RealRun()
{ cout<<"hello, in CAppServer::RealRun()"<<endl; }
}
class CMyServer:public CAppServer
{
protected:
int RealRun()
{ cout<<"hello, in CMyServer::RealRun()"<<endl; }
}
main()
{
CAppServer *pMyApp = new CMyServer;
pMyApp->Run();
}
3 我的服务器框架类图
谢 谢 大 家，如有建议请发email到以下信箱：
