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

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

最近在思考改进项目中一模块的实现，该模块维护起来让我很是头疼，所有才有了整体换掉它的想法。设计和实现中利用了内存对齐的技术。关于内存对齐，我曾经写过三篇文章，第一篇介绍了计算内存对齐的方法和例子，第二篇说了一个内存对齐的应用；三谈内存对齐时，则从其本质上做了阐述，而这次实际上是继续在其本质上的做文章，结合本质谈谈为什么内存对齐的计算方法就应该是第一篇中所讲的那两条。

如果对内存对齐本质还不清楚的话，就看看我的内存对齐系列的第三篇吧。如果你清楚了本质，那么我们结合第一篇中交待的内存对齐计算方法来进一步探究，为什么计算的方法就是这个样子的。

再理解一下对齐系数/模数，众所周知Alignment module反映了CPU 取数据时对数据起始地址的限制-这个地址值必须能被Alignment module所整除，但继续仔细考虑下去，你会想到CPU在下一次取数据依然要从下一个能被Alignment module所整除的地址的地方去取，这显而易见，又能说明什么呢？如果说CPU第一次取数据的地址是first_read_address，那么连续下一次的地址就应该是first_read_address + Alignment module了，也就是说每次取数据的量就是Alignment module这么多，这样通过Alignment module我们又可以知道一个量，那就是：在Alignement module限制下，CPU一次能取Alignment module个字节；在“Data alignment: Straighten up and fly right”一文中作者也称之为"memory access granularity"。从应用层开发人员的角度理解：被访问变量的长度，就是CPU要去读取的字节数；而对齐系数又是限制CPU读取字节数的一个指标，有了这两个理解，解决下面的疑问就有了基础了。

在'也谈内存对齐'一篇中介绍了内存对齐的计算方法，这里不妨再引用一下：
1、数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员自身长度中，比较小的那个进行。
2、结构(或联合)的整体对齐规则：在数据成员完成各自对齐之后，结构(或联合)本身也要进行对齐，对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中，比较小的那个进行。

疑问：对于数据成员对齐规则：为什么每个成员的对齐都要按照Min(指定对齐模数，数据成员自身长度)来确定呢？为了不用Max(指定对齐模数，数据成员自身长度)呢，用Max值对齐的不更加完美么？同样对于结构的整体对齐规则也一样有此疑问。这里我们还是举个例子更加直观：
#pragma pack(8)
struct Foo {
    char    a;
    int    b;
    short    c;
};
#pragma pack()
我们先来看数据成员对齐，以b为例子，按照规则的说法，sizeof(b) = 4 < 8，那么Address_of_b = Start_Address_of_Foo + 4; 我们来看看当应用的代码里访问b的时候，CPU做了些什么？Address_of_b一半情况下是不能被8整除的，在不能被8整除的情况下，我们去访问b，这里我要提两个问题：
1) 访问b的时候是否会因内存没有对齐到8上而触发core呢？(在Sun SPARC上因访问未对齐地址上的变量时会出core)
2) 为什么不将b放到Start_Address_of_Foo + 8这个地址上呢？

下面一一说说我的理解：
根据前面所说，程序在访问b的时候，CPU实际不一定是从Address_of_b这个地址上开始读取的。如果b这个地址恰巧既能被4整除，也能被8整除(如地址24)，那就无可厚非了。但是如果这个地址只能被4整除，而不能被8整除(如地址12)，那么此时CPU读取的地址肯定是从Address_of_b – 4开始读取8个字节的，也就是说实际上CPU都是从能被8整除的地址上读取的，而且一次读了8个字节，b所在的位置恰是这个8个字节中的后4个字节，所以不存在触发core的可能。

第二个问题，sizeof(b) = 4 < 8，为什么就要按照4而不是按照8去安排b的地址呢？我们不妨按照8去给b分配地址，Address_of_b' = Start_Address_of_Foo + 8，这样的话CPU也能一次将b读取，而且是从b的起始地址开始读，似乎更完美。但你看出问题了么？这么做浪费的空间显然大了很多。将b安排在Address_of_b'比安排在Address_of_b多浪费了一半空间。

同样整体对齐原则也是同样的道理。内存对齐计算显然有两个目标：一是减少CPU的访存次数；第二个就是还要保持存储空间的效率足够高。