入司后连续做过几个项目。最近在做一个新的项目的设计的时候，突然想到是不是该把以前项目中一些好的设计想法应用到新的项目中，并且尽量减少在新的项目中遗留以前的不好的设计呢？那么以前的项目中哪些是值得我去借鉴，哪些又是应该去避免的呢？真的很遗憾，自己并没有系统的反思和总结过，这就是我写下这篇Blog的直接起因。

一直在Unix平台下做设计和开发，所以下面谈的内容可能都有些局限性。作为设计原则本身，某些可能具有很强的通用性，而还有一些可能局限于某个平台、某个领域。这里我想到了以下几个方面(仅仅提出一些观点，而没有太关注具体的解决方法，给大家一个想象的空间^_^)：

1、扩展
扩展性在这里被我分为“性能扩展”和“功能扩展”两类。
1) 性能扩展
作为电信级系统，对其的性能要求肯定不会低。那么如何做性能扩展呢？有两种方法：提高单点处理能力（垂直扩展）和平行扩展。
垂直扩展 – 简单说就是一个进程不够，我再加一个进程做同样的处理。问题出现了：如何做进程间的通讯？使用共享内存（最快的IPC）还是其他IPC方式呢？还是一个权衡的过程。
水平扩展 – 简单说就是一台机器不够，我再加一台机器。咱们也时髦一把，弄个分布式。问题出现了：如何做分布式节点之间的通讯？目前流行soap，而且又有开源包，如gsoap，其唯一缺点也是致命缺点就是慢。所以我想大部分开发商还是使用自己的内部协议。另外分布式与钱还是挂钩的。分布式意味着需要更多的机器平台来承载我们的系统，机器是钱，对机器的服务也是钱。看来这也是大家都喜欢分布式的原因。

2) 功能扩展：
做电信软件，其面对的最大的问题可能就是“用户需求变化多端”这个问题，更有甚者就是“用户并不知道需求，需要你去引导用户”，这样就会给项目带来较大的风险。如何能在设计这一层来规避风险或者减小风险带来的损失呢？尽量划分清易变化的需求和较稳定的需求，采用面向接口编程的形式（记住面向接口并不是Java等语言的专利）。比如以动态链接的方式（有点plugin的意思）实现系统中那些易变化的功能模块。一旦用户需求改变，我们需要修改的只是一个动态链接库（即替换一个plugin）。

2、隔离
隔离是为了可测试和好维护。其缺点是可能带来性能上的缺失。
1) 可测试性
可测试性在当前可是衡量一个软件设计好坏的重要标准。大型程序，模块众多。首先应该想到的就是怎么做集成测试？集成测试可能需要把一个模块单独拿出来运行。这就需要我们在设计的时候使模块间的耦合性尽量小，比如我们可以采用文件或者MQ的方式来解除模块间的耦合。这样一旦模块A开发完毕，产生其输入数据的模块B还未完成，我们就可以使用模拟器来产生输入数据即可(生成文件或者手工写数据到MQ中)。

2) 维护性
软件脱离不了服务，服务也是钱，也算在软件的成本中。如果一个软件的维护成本过高，完全可能会使该项目赔本。可维护性高的一个很重要的指标就是能快速定位问题所在。隔离模块可以提高定位错误的效率。因为我们可以将某一模块从系统中拿出来，单独测试定位问题，一个一个的排查，而不是大海捞针般的在系统中胡乱撞。

隔离还有一点很重要，就是尽可能的让每个模块能单独可运行（并不一定是独立程序），而无须依赖其他模块。

3、灵活
在我看来体现一个系统是否灵活，最重要的一点就是其配置文件设计的灵活性和合理性。

1) 配置文件格式
现在Java世界的配置文件基本已经被xml格式所垄断，而在C这边仍旧使用着传统的“key – value”格式。xml的多级配置是传统“key – value”不能比拟的。
例如：

# in "key – value" format
[mqlist]
name = testmq1;testmq2

在传统配置文件中我们需要对name字串进行解析才能得到各个mq的名字。而且大多数读"key – value"的程序可能都有对value值长度的限制，也就是说我们不能无限制的增加mq的个数。在xml中不存在这样的问题。况且现在像expat这样的开源包对xml的支持也很好。建议在以后设计时向xml格式配置文件转移。

2) 配置方式
一个灵活的配置，会给系统维护和变更带来极大的方便。甚至可以通过修改配置来满足用户新的需求。另外集中配置和分散配置也是需要设计者考虑的问题。比如将整个系统做成一个大程序，并做集中配置，那么除非有动态配置更新程序，否则一旦配置更改，就需要重启整个系统。相反如果系统是一个小程序的集合，采取分散配置，这样针对每个小程序的配置修改只会影响到其自己，只需重启相应的程序即可。

3) 配置粒度
很难用定义解释这个问题，举个例子可能会有更好理解。比如按照一定的配置格式写一个文件(由若干行记录组成)。对文件格式的配置可能如下：
粒度粗的配置

粒度细的配置

可以看出“粒度粗的配置”只支持到区分记录间的对齐方式和填充字节的差异性；而“粒度细的配置”则支持到区分字段间的对齐方式和填充字节的差异性。一旦需求发生变化，要求每条记录的字段间的alignment和padding可以不同的话，那么“粒度粗的配置”则不能满足需求，而“粒度细的配置”仅仅通过改变配置即可满足这个需求。从这个例子可以看出配置粒度粗细选择某种程度上可能会影响程序的扩展性，一般来说配置粒度细的程序扩展性要更好些。

4、层次
做设计一定要考虑层次，这里体会不多也就不多说了，总之有一点就是“在做设计的时候心中一定要有层次的概念”。

5、小结
给我的感觉：设计是一门权衡的艺术，相信通过上面的一些文字也可以不充分的论证这一点。本文仅仅是我在做过一些项目后的一些体会，并没有很牢固的理论基础。自己也正在计划着读一些关于架构设计方面的书，来提高一下自己的理论水平^_^。

APR中少见对数据结构的封装，好像唯一例外的就是其对循环链表，即环(RING)的封装。

在大学的时候学的不是计算机专业，但大三的时候我所学的专业曾开过一门好像叫“计算机软件开发基础”的课，使用的是清华的一本教材，课程的内容包括数据结构。说实话听过几节课，那个老师讲的还不错，只是由于课程目标所限，没讲那么深罢了。当然我接触数据结构要早于这门课的开课时间。早在大一下学期就开始到计算机专业旁听“数据结构”，再说一次实话，虽号称名校名专业，但是那个老师的讲课水平却不敢恭维。

言归正传! 简单说说环(RING)：环是一个首尾相连的双向链表，也就是我们所说的循环链表。对应清华的那本经典的《数据结构》一书中线性表一章的内容，按照书中分类其属于线性表中的链式存储的一种。环是很常见也很实用的数据结构，相信在这个世界上环的实现不止成千上万，但是APR RING(按照APR RING源代码中的注释所说，APR RING的实现源自4.4BSD)却是其中较独特的一个，其最大的特点是其所有对RING的操作都由一组宏(大约30个左右)来实现。在这里不能逐个分析，仅说说一些让人印象深刻的方面吧。

1、如何使用APR RING？
我们先来点感性认识! 下面是一个典型的使用APR RING的样例：
假设环节点的结构如下：
struct  elem_t {    /* APR RING链接的元素类型定义 */
    APR_RING_ENTRY(elem_t)  link; /* 链接域 */
    int                                     foo; /* 数据域 */
};

APR_RING_HEAD(elem_head_t, elem_t);

int main() {
    struct elem_head_t  head;
    struct elem_t       *el;

    APR_RING_INIT(&head, elem_t, link);

    /* 使用其他操作宏插入、删除等操作，例如 */
    el = malloc(sizeof(elem_t);
    el->foo = 20051103;
    APR_RING_ELEM_INIT(el, link);
    APR_RING_INSERT_TAIL(&h, el, elem_t, link);
}

2、APR RING的难点–“哨兵”
环是通过头节点来管理的，头节点是这样一种节点，其next指针指向RING的第一个节点，其prev指针指向RING的最后一个节点，即尾节点。但是通过察看源码发现APR RING通过APR_RING_HEAD宏定义的头节点形式如下：
#define APR_RING_HEAD(head, elem)     \
    struct head {       \
             struct elem *next;      \
             struct elem *prev;      \
    }
如果按照上面的例子进行宏展开，其形式如下：
struct elem_head_t {
     struct elem_t *next;
     struct elem_t *prev;
};

而一个普通的元素elem_t展开形式如下：
struct elem_t {
     struct {       \
        struct elem_t *next;     \
        struct elem_t *prev;     \
     } link;

     int foo;
};
通过对比可以看得出头节点仅仅相当于一个elem_t的link域。这样做的话必然带来对普通节点和头节点在处理上的不一致，为了避免这种情况的发生，APR RING引入了“哨兵(sentinel)”节点的概念。我们先看看哨兵节点在整个链表中的位置。

sentinel->next = 链表的第一个节点；
sentinel->prev = 链表的最后一个节点；

但是察看APR RING的源码你会发现sentinel节点只是个虚拟存在的节点，这个虚拟节点既有数据域(虚拟出来的，不能引用)又有链接域，好似与普通节点并无差别。在APR RING的源文件中使用了下面这幅图来说明sentinel的位置，同时也指出了sentinel和head的关系 — head即为sentinel虚拟节点的link域。

 普通节点
+->+——-+<–
   |struct |
   |elem   |
   +——-+
   |prev   |
   |   next|
   +——-+
   | etc.  |
   .       .
   .       .

sentinel节点
+->+——–+<–
   |sentinel|
   |elem    |
   +——–+
   |ring    |
   |   head |
   +——–+

再看看下面APR_RING_INIT的源代码：
#define APR_RING_INIT(hp, elem, link) do {    \
            APR_RING_FIRST((hp)) = APR_RING_SENTINEL((hp), elem, link); \
           APR_RING_LAST((hp))  = APR_RING_SENTINEL((hp), elem, link); \
    } while (0)
你会发现：初始化RING实际上是将head的next和prev指针都指向了sentinel虚拟节点了。从sentinel的角度来说相当于其自己的link域的next和prev都指向了自己。所以判断APR RING是否为空只需要判断RING的首个节点是否为sentinel虚拟节点即可。APR_RING_EMPTY宏就是这么做的：
#define APR_RING_EMPTY(hp, elem, link)     \
    (APR_RING_FIRST((hp)) == APR_RING_SENTINEL((hp), elem, link))

那么如何计算sentinel虚拟节点的地址呢？
我们这样思考：从普通节点说起，如果我们知道一个普通节点的首地址(elem_addr)，那么我们计算其link域的地址(link_addr)的公式就应该为link_addr = elem_addr + offsetof(elem_t, link)；前面我们一直在说sentinel虚拟节点看起来和普通节点没什么区别，所以它仍然符合该计算公式。前面我们又说过head_addr是sentinel节点的link域，这样的话我们将head_addr输入到公式中得到head_addr = sentinel_addr + offsetof(elem_t, link)，做一下变换即可得到sentinel_addr = head_addr – offsetof(elem_t, link)。看看APR RING源代码就是这样实现的：
#define APR_RING_SENTINEL(hp, elem, link)    \
    (struct elem *)((char *)(hp) – APR_OFFSETOF(struct elem, link))

至此APR RING使用一个虚拟sentinel节点分隔RING的首尾节点，已达到对节点操作一致的目的。

3、使用时注意事项
这里在使用APR RING时有几点限制：
a) 在定义RING的元素结构时，需要把APR_RING_ENTRY放在结构的第一个字段的位置。
b) 链接一种类型的元素就要使用APR_RING_HEAD宏定义该种类型RING的头节点类型。学过C++或者了解泛型的人可能都会体味到这里的设计有那么一点范型的味道。比如：
模板：APR_RING_HEAD(T_HEAD, T) —- 链接—-> T类型元素
实例化：APR_RING_HEAD(elem_head_t, elem_t) — 链接—->elem_t类型元素
 
4、APR RING不足之处
1) 缺少遍历接口
浏览APR RING源码后发现缺少一个遍历宏接口，这里提供一种正向遍历实现：

#define APR_RING_TRAVERSE(ep, hp, elem, link)    \
            for ((ep)  = APR_RING_FIRST((hp));     \
            (ep) != APR_RING_SENTINEL((hp), elem, link);   \
           (ep)  = APR_RING_NEXT((ep), link))
大家还可以模仿写出反向遍历的接口APR_RING_REVERSE_TRAVERSE。