近一两年来我在博客少有提及公司项目的事情，除了一些技术bug引起我对问题的思考。这样一是为了“避嫌”，公司年初发生了多次因员工在个人博客泄露源代码或者客户资料的事件，公司管理层也加强了对公司“信息安全”的管理，无非是学习华为那一套-“封锁”：使用websense限制员工上外网，使用桌面监控系统监控员工电脑系统，封掉一切可能泄露机密信息的接口。还特地发挥了一下“数字课件”部门兄弟们的聪明才智，搞了一个在线信息安全课件，规定员工都要完成课件学习，并在学习完进行在线测试。说实话，这个课件做的真的不错，只是大家对这种学习丝毫不感兴趣，一切为了应付。二呢还是为了“避嫌”，记得去年年末的一篇文章就引起了一个小风波，结果换来了与“顶头上司”的一次“对话”。作为老员工你的所说说写，直接影响了周围的人，虽然我的博客访问量不大^_^。

而今天我要说说身边的事，说说项目上的事。

在一个项目(或者叫产品也不为过)上持续做了整整三年，说长不长，说短也真的不短了。三年间见证了系统从杂乱变为有序和规范的历程，也见证了自己逐渐成长和成熟的过程。而整个系统的架构也在经历着不断的演进。去年年末我们策划并对系统进行了有史(历史<=3年)以来最大的一次架构调整，今年下旬实现了部分调增的新架构系统上线。但我们心里知道架构演进还远没有达到我们期望的结果，演进还没有接近终点。对于一个中等规模的后台服务系统而言，高性能、大容量以及良好的稳定性和良扩展性一直是终极目标，达到这个目标谈何容易。

记得04年入司时，部门的一个核心产品A正在做革新性的架构调整，听更资历老一些的同事说：A产品在2000年诞生后在线运行了4年，问题也伴随了四年，随着客户业务量的增长，亟需对A的架构进行调整，部门也决定投入大量人力在这个拳头产品上。就这样新架构迭代式的做了近三年，人也换了一批又一批，终于在07年A产品上线了。A产品的架构演进走的是从无到有的革新路线，即整个产品基本都是重写的。这样的路线风险较大，新代码较多，测试过程中发现的缺陷势必也较多，为了保证产品研发人员能专心于研发，且保证现有产品维护能及时，部门还另分出一组人单独做既有产品维护。A的新架构上线后，也出了较多问题，但是架构本身经受住了考验，但是随着系统的运行，也发现了架构的一些弊端。

我所从事开发的产品B应该与A算是姊妹产品，第一版的B产品的一个子系统B-1就是从A未进行架构调整之前的系统修改过来的,也就是说B-1等价于A产品前身。与A产品不同的是，B产品增加了另一个核心系统B-2。这里用图示更直观。

A产品    A前身      — 演化 —> 新架构A
B产品:   B-1        — 演化 —> 新架构B1
            B-2        — 演化 —> ?

B产品初期，我一直投入在B-2上，完成了B-2初始版本的开发以及后期一年半的演化。在将B-2当前架构演化到一个高度后，我退了出来，开始负责B-1的研发。现在回头看来B-2最大的架构有点就是简单清晰，但是由于前期的经验不足，在内部代码结构上留下了比较恶劣的smell，后来人也“效仿”了我的风格，以致现在我再看B-2代码，只能用“惨不忍睹”来形容了，Dreamhead的fanfou中曾经提到过“给予程序员最佳的惩罚便是让他维护自己一年前编写的代码”。当然这都是我的错误，与后人无干。可惜的是我现在没有精力再去精化B-2的结构了。

前面说到B-1就是A产品前身，同样与A前身遭遇问题相同，B-1在处理能力上遇到了瓶颈。B-1的架构进化也就从此开始了。由于有了A产品架构演化的经验与教训，B-1采用了与A不同的架构路线，这期间A产品开发负责人给了我们莫大的帮助，提供了我们所缺少的经验和教训，可以说我们的架构演化是站在“前人的肩膀上的”。而且与A架构调整的轰轰烈烈不同的是，我们B-1后台的核心开发人员一直就保持在三人左右，再带着两三个新员工。人力虽少，但是效率却不差，小步快跑，达到相同目的。我们在去年年末架构演化方案确定后，制定了阶段发布计划，架构调整分阶段进行。一个阶段release后，deliver给客户，上线运行调整，虽说每个版本都不完美，有缺憾，有局限，但是风险也降到了最低，这种平滑过度对客户体验的影响也最小。更重要的是阶段性的deliver，加快了反馈的频率，使我们开始对前期架构演化的优缺点的了解也更多了。架构演化计划也随之调整。但随着对架构理解的深入，我们遭遇到了处理能力和扩展性上遇到了“天花板”，不得不暂停下来反思和讨论。

曙光就在昨天的那次反思和讨论中得以重现，在这之前我们的眼光一直停留在B-1架构蓝图的内部，无论我们如何调整都无法让大家满意，始终觉得“别扭”。这时A产品负责人的一个观点，让我们茅舍顿开。一个虚拟域或组的概念将蓝图组合、叠加和交叉，一副更大的图景展现在我们面前，而这幅图似乎让我们看到了架构演化的终极目标，以至于我昨晚连夜画出了一副架构草图。

这篇文章用“曙光”作为题目也许只有我自己才能体会到其深意吧。

今天是冬至，也是入冬以来感觉最冷的一天，毫不夸张的说：你一张嘴，牙就冻上了。上午LP在家收拾卫生，我继续用Scons改造现有的项目。下午出去理发，头发长长了后，似乎会造成思维迟钝^_^。

试验性的用Scons改造现有的project，过程中对Scons了解又多了一些。上篇文章对Scons的性能没有给出定论，经过对Scons的深入后，发现Scons在执行初始时的性能的确不够快，这是因为Scons启动后，会对全部SConstruct以及下面子目录中的SConscript进行分析，子目录越多Sconscript文件个数越多，性能也就越差。但是这种分析也有一个优点，就是能帮你提前发现你SConscript中的一些“语义”错误，比如如果你在编译两个基础库，一个叫add，一个叫sub，这个基础库源码分别分布在两个目录add和sub中，编译后将分别生成libadd.a和libsub.a的库文件，但是如果你马虎了，在编写SConscript时将target都写成了'add'或都写成了'sub'，则Scons会在执行gcc之前就帮你找出这个"语义"错误，提示如下：
/export/home1/tony_bai/xxlib>scons -f SC*t
scons: Reading SConscript files …
scons: *** Multiple ways to build the same target were specified for: /export/home1/tony_bai/xxlib/lib/libsub.a  (from ['/export/home1/tony_bai/xxlib/add/libsub.a'] and from ['libsub.a'])
File "/export/home1/tony_bai/xxlib/sub/SConscript", line 3, in

Scons脚本基本写的差不多了，编译也ok了，但是编译出来的可执行程序在执行时却出现了问题：提示找不到某.so文件。而用项目"原配"的Makefile编译出来的可执行程序却执行的很好，没有类似问题，百思不得其解。将.so文件所在目录放到"LD_LIBRARY_PATH"中，问题得以解决，但这更加深了对这一现象的质疑。起初我一直以为是Scons在编译选项上不规范造成的，而Scons使用gcc -G -o xx.so xx.o来编译也的确有值得的怀疑点，-G选项是我从未见过的gcc编译选项，查了半天手册也没有对该参数的说明，遂放弃。上工具吧！先用ldd对编译出来的可执行文件进行分析，我们先来假设用Scons编译出来的可执行程序名字为Bin-scons，用"原配"Make编译出来的可执行程序名字为Bin-make。ldd将列出可执行文件中动态依赖的库的名字，并在本机定位出各个动态库的位置。对Bin-scons和Bin-make分别ldd的结果却让我大吃一惊，Bin-scons的ldd结果很正常，xx.so出现在list中，并且其位置为我刚刚加入到LD_LIBRARY_PATH中的那个目录；但是Bin-make的ldd结果中却不见了xx.so的踪影，这是怎么回事呢？回头翻看Makefile，并且又执行了多遍Make，项目的Makefile明明是构造了xx.so，在生成Bin-make时链接了xx.so，并且Bin-make中使用了xx.so中提供的接口。再次仔细对比Make和Scons编译.so时的差别，这回发现了些许不同的地方，"原配"的make在编译.so时，除了用了-shared -fPIC之外，还用了"-c"选项，而从Scons日志中只能看到gcc -G -o libxx.so xx.pic.o，显然Scons先控制gcc将xx.c编译为xx.pic.o，再由xx.pic.o构成libxx.so，而且我发现用Scons和Make编译出的.so文件大小居然不同。显然"-c"对两个编译过程带来了影响。一般来说，我们在编译一个动态库时是不会使用"-c"的，这里先不论项目Makefile写的是否ok，单说"-c"会给编译过程带来什么吧。打开gcc的"–verbose"开关，我们来试试使用和不使用"-c"gcc都做了些什么。还是以add.c为例，将add.c编译为libadd.so。

gcc -o libadd.so -shared -fPIC -c add.c –verbose
执行结果：
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: ../configure –with-as=/usr/ccs/bin/as –with-ld=/usr/ccs/bin/ld –disable-nls
Thread model: posix
gcc version 3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc add.c -quiet -dumpbase add.c -version -fPIC -o /var/tmp//cca0mHxn.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
        compiled by GNU C version 3.2.
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
#include "…" search starts here:
#include search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include
End of search list.
 /usr/ccs/bin/as -V -Qy -s -K PIC -o libadd.so /var/tmp//cca0mHxn.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 Solaris_9_CBE 2001/04/02

gcc -o libadd.so -shared -fPIC add.c –verbose
执行结果：
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: ../configure –with-as=/usr/ccs/bin/as –with-ld=/usr/ccs/bin/ld –disable-nls
Thread model: posix
gcc version 3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc add.c -quiet -dumpbase add.c -version -fPIC -o /var/tmp//ccz128Nl.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
        compiled by GNU C version 3.2.
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
#include "…" search starts here:
#include search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include
End of search list.

 /usr/ccs/bin/as -V -Qy -s -K PIC -o /var/tmp//ccoU5RTD.o /var/tmp//ccz128Nl.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 Solaris_9_CBE 2001/04/02
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o libadd.so /usr/local/lib/gcc-lib/sparc-sun-
solaris2.9/3.2/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtbegin.o -L/usr/local/lib/gcc-lib/sparc-sun-
solaris2.9/3.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/../../.. /var/tmp//ccoU5RTD.o -lgcc_s -lgcc_s
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtend.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtn.o
ld: Software Generation Utilities – Solaris Link Editors: 5.9-1.276

对比这两次的执行结果，我们可以发现，使用了-c的编译过程实际上不是一个完整的共享库(动态库.so)的构建过程，而只是一个带有"-shared, -fPIC"的目标文件(.o)的编译过程，缺少gcc crt目标文件的链接过程，只是目标文件被命名为libadd.so了。这恰恰能解释我们前面提到了两点疑问了。为什么ldd Bin-make时没有发现其依赖xx.so以及Bin-make执行时一切ok，没有报“找不到xx.so”，这一切都是因为xx.so实际上是以.o形式存在的一个文件，在构建Bin-make链接xx.so时，实际上做到是静态链接而不是动态链接，xx.so中的接口代码都已经存在于Bin-make中了，所以ldd无法找到对xx.so的依赖，Bin-make执行时也无需找到xx.so了。看来这是项目Makefile中的一个问题了，只是这个"问题"隐藏太久而未能被发现罢了。

从收音机中得知"冬至"这天应该吃饺子，晚上和LP煮了两包水饺，热腾腾的，吃得直打饱嗝^_^。