2009年的第一个工作日，一切尽在平淡中度过。

往往大家都有这样的体会，那就是"长假“过后的第一个工作日身体多不在状态，假期中身体的懒散的惯性还没有彻底消除掉，也许脑子里还在回忆着与亲人朋友聚会时的那抹快意。但元旦后上班的第一天或许有些不同，毕竟这是新年后在同事面前的第一次亮相，要有蓬勃向上的气质和神态^_^。

晨会上，组内同事围在椭圆会议桌，大家似乎都较为沉默，要不是我打开话题，各位似乎还停留在"假期"状态。大家轮流说完后，我提醒大家新年里大家要为自己确定好目标，制定好远期和近期的计划。其实如果你在2008年最后一天总结和回顾的话，那么2009年的第一个工作日其实你应该抽出些许时间在白纸上或者Excel上或者是电子日记本上或者是MindManager上记录下你今年的目标和计划，包括工作上的和私人的，花这个时间是很值得的。

会后回到座位上，发现网络居然不好用，mail服务器也罢工了。唉，偌大一个公司，网络却常常"瘫痪"，真是让人觉得很不爽。不好用就不好用吧，正好用这段时间为项目组做一个上半年的工作计划，列出一些目标。中午网络恢复，各省陆续有一些问题汇集到我这，处理问题花了我一些时间，还好今天问题处理的都很高效，手到擒来。

晚上有饭局，主要是宴请售后工程师们，感谢他们去年一年来对我们开发出来的产品的大力支持。大家把酒言欢，好不热闹，但我还不是很习惯这样的场合，闷头吃。

近一两年来我在博客少有提及公司项目的事情，除了一些技术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产品负责人的一个观点，让我们茅舍顿开。一个虚拟域或组的概念将蓝图组合、叠加和交叉，一副更大的图景展现在我们面前，而这幅图似乎让我们看到了架构演化的终极目标，以至于我昨晚连夜画出了一副架构草图。

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