HDFS(Hadoop Distributed File System)作为Hadoop下的一个子项目，是目前使用极为广泛的分布式文件系统。它的设计目的是提供一个高容错，且能部署在廉价硬件的分布式系统；同时，它能支持高吞吐量，适合大规模数据集应用。这一目标可以看做是HDFS的架构目标。显然，这样的架构设计主要还是满足系统的质量属性，包括如何保证分布式存储的可靠性，如何很好地支持硬件的水平扩展，如何支持对大数据处理的高性能以及客户端请求的高吞吐量。所以，HDFS的架构设计颇有参考价值，在Hadoop的Apache官方网站上也给出了HDFS的架构指南。在The Architecture of Open Source Applications卷I的第8章也详细介绍了HDFS的架构。

HDFS的高层设计看起来很简单，主要包含NameNode与DataNode，它们之间的通信，包括客户端与HDFS NameNode服务器的通信则基于TCP/IP。客户端通过一个可配置的TCP端口连接到NameNode，通过ClientProtocol协议与NameNode交互。而DataNode使用DatanodeProtocol协议与NameNode交互。一个远程过程调用(RPC)模型被抽象出来封装ClientProtocol和Datanodeprotocol协议。

一 偶然的时间图形

时间是一幅充满神秘暗含玄奥的几何图形。点与线的纷繁组合，凸显宇宙的奥秘，然而，无知的我们却无法将其解密。时间无意作弄我们，我们却自主地愿意接受时间对我们的安排，心甘情愿沦为奴隶。时间冷冰冰地俯瞰这个世界，看到蚁群在他的几何世界中，因为某种偶然发生碰撞，上演的那些喜怒哀乐的话剧，颇为有趣，他却始终不曾流露一丝笑容。冷酷是他成为神诋的唯一标志。

就是在错综复杂的几何图形中的某一点，我阅读博尔赫斯《叛徒和英雄的主题》。不错，我阅读到这一句：“……认为有一种隐秘的时间形式，有一种重复出现的线条图形。”这启发我对时间的遐想。此时，窗外正有一片秋叶缓缓落下，或许具有离去的悲哀，或许充满皈依大地的喜悦，而作为人，其实并不知晓落叶的心情，正如我们不知道时间的规则。就在这一点，我的爱人是否正轻轻发出细微如雨点滴入大海一般的叹息呢？她在想些什么？如果我们心有灵犀，在我的心弦被时间的神秘所触动的时候，她敏感的心弦是否发生共鸣？我和她在空间上分处两个不同的点，就像在一张白纸上描绘的分处两端的点，对折起来，两点产生了奇妙的重叠。时间的魔力可以让空间的不同点产生交汇。也许在下一刻，我们的心绪产生了不可避免的分岔，然而在时间的几何图形中，我们是重叠的。即使面对整个苍穹，虽然时间描绘出不同的景色，例如黄昏的惨白与朝晨的绚烂，在不同的空间之上，每个人物的姿态万千各异，却在时间的几何图形上交汇为同一个点。每一个点都想要挤占这无限小的空间，一个不可计算面积的点的空间，于是，我们的行为产生了碰撞，于是，产生了偶然。

微软研究院首席研究员Leslie Lamport发表了文章Why We Should Build Software Like We Build Houses，吐槽了对如今程序员不愿意做分析，画草图，而是直接开始编码的现状。看了这篇文章后，我对Lamport的观点有一些想法，觉得不吐不快。

其实从文章标题以及作者开篇名义提出的问题来看，显然基于一个假设，或者说事先设定的隐喻，那就是用建筑业来形容软件开发。作者认为建筑设计师在修建房屋之前都会绘制一幅详尽的计划（或蓝图），而软件开发人员却并不这样。以两个不同的行业做对比，认为一个行业这么做了，另一个行业不这样做就有问题，这个假设合理吗？虽然，软件行业中所谓Architecture以及Build的概念确乎来自于建筑行业，甚至这种隐喻在许多年前为诸多大师认可，因而提出诸如软件工程等思想；虽然，它山之石可以攻玉，借鉴别的领域的最佳实践，确乎可以帮助软件开发收获灵感，避免去走太多弯路；然而，毕竟二者之间并不能完全划等号。

若要获得良好的对象设计，就必须对职责进行合理的分配。每个对象承担的职责不能太多，也不能太少，恰如其分即可。职责分配如乐谱中对音符的组织，高明的音乐家总是能让不同的音符放在合理的位置，奏成悦耳的心曲，表达音乐家的内心感情。然而，即使设计师明确职责分配的重要性，在面临纷乱复杂的需求时，常常被乱花迷了眼，或者无法识别正确的职责，又或者顾此失彼，将职责放错了位置，变成了对职责混乱的涂鸦。

要识别职责，进而合理分配职责，有许多秘诀，或云“技巧”。不过，将对象的角色作为职责分配的开始，不失为一个好的起点。角色是对象的身份，若以拟人化的方式思考对象世界，就可以设想：究竟是怎样的身份，需得承担怎样的职责，才会与其身份相当，不至于乱了规矩。红楼梦中，刘姥姥进了大观园，出尽了洋相，就是因为身份失当；又可以想想倘若林黛玉像尤三姐那般爱恨分明，也不至于见花落泪，惹人爱怜了。故而在分配职责时，我们能首先明确对象的角色，即可将思想带入到这一角色中，设身处地，推断这一角色可以或者必须承担哪些职责。

在Object Design:Roles, Responsibility, and Collaborations一书中，将对象的角色分为了五种，分别为信息持有者、构造者、服务提供者、协调者和控制者。这种分类差不多涵盖了对象在软件系统中扮演的角色。以此为基础，在进行软件设计时，可以思考你要设计的对象，究竟属于哪一种角色。

书的内容其实没有书名那么富有诗意，整本书中，汉嘉都在废纸堆中与老鼠、苍蝇为伍，这种如下水道般的卑微存在，在现实生活中，定然是遭到嘲笑、冷落甚至摒弃的下等人。我在书的一开始，完全欣赏不到那种诗意的美。设身处地，我会选择逃离，即使有黑格尔、康德、加缪与梵高。归根结底，我们大多数人无法做到无视周遭环境的龌龊，优游于精神高尚的深邃星空。从这一点来讲，汉嘉无疑是孤独的。

最可悲的是，这种孤独还在于他像一个送灵人，日复一日地挥别逝去的亲人，让这种忧伤啃啮孤独的灵魂，这就好像普罗米修斯在高加索山脉日复一日被恶鹰雕琢肝脏一般的痛苦。

与书为友，却又在随时埋葬他的精神安慰；这似乎是一种悖论。于是，阅读的体验就在这种悲伤中蔓延！？“子非鱼，焉知鱼之乐？”其实，我们这种忧伤不过是庸人自扰。读书读到灵魂中的人，会无视这些悲哀，因为汉嘉用自己的心灵构筑了一个属于自己的独立王国——书的王国。书的开篇就展现了这种欢乐，将肮脏的废纸堆当做自己的love story，作者写道：“三十五年来我同自己、同周围的世界相处和谐，因为我读书的时候，实际上不是读，而是把美丽的词句含在嘴里，嘬糖果似的嘬着，品烈酒似的一小口一小口呷着，直到那词句像酒精一样溶解在我的身体里，不仅渗透到我的大脑和心灵，而且在我的血管中奔腾，冲击到我每根血管的末梢。”

经历了几次过度设计，我对一些设计模式开始抱有谨慎的戒惧。我希望能够合理地运用设计模式，而非为模式而模式。事实上，现在的我较少会有意识地运用设计模式；更多地是通过职责来驱动，以期获得合理的职责分配。之后，再通过辨别代码的坏味道，运用重构来改善设计。大多数情况下，这种方式对于设计而言，已经足够。不过，有时我们仍有必要根据具体场景，做出合理判断和决策。

我曾经遭遇的一个Story，是要实现一个Web Service，提供update的服务接口。需求要求对服务的Request进行验证。这一验证功能并非Story的核心功能，但其逻辑却比核心逻辑复杂数倍。它需要针对不同情况，遵循多个规则验证Request。这些验证逻辑如此的复杂，以至于我们可以在第一时间做出判断，它必须是单独的职责，绝对不适合放到Service对象中。

这种职责分离还不够。因为每一条验证规则，都可以视为一个单独的验证职责。若将每种验证规则封装为一个验证对象，就能很好地满足SRP。每个验证对象只需要做好自己的事情即可，结果只有两个，要么错误，要么通过。若当验证逻辑为一个整体，则可以理解为：只要违背了一条验证规则，出现错误，则可以视为验证不通过；否则将继续验证下一条规则。

今天的心情难以用言语表达。打开公司邮件，看到邮件“ThoughtWorks Declares Tuesday January 15, 2013 as Day of Remembrance for Aaron Swartz”，有一种被震惊的感觉。虽然我与Aaron素昧平生，但只要了解他的生平，就不由不对他产生敬意。这是一位天才，可是如今却像流星一般陨落了。让我感叹生命如此无常的，还在于我恰恰在大约1个月前的公司视频会议上看到过Aaron，当时Aaron身陷美国联邦检查官的起诉中。Roy为此表示愤慨，并组织召开了此次视频会议，Aaron也有出席。在视频中，Aaron瘦削的面庞，蓬松的头发，以及略带忧郁的眼神，确乎很有极客的风范。然而，怎么也想不到，这最初的一面，就成为了最后一面。生命真是残酷。

正是这唯一的一面，让我产生的生死相隔之感，如此的强烈。Aaron的自杀看似是因为自己的抑郁症而起，但我更认为，他的自杀是殉道，是怒其社会对自由的钳制发起的呐喊，他在用生命维护自己的自由。然而，面对国家机器，他的反抗未免脆弱了点儿，他的愤怒未免不值一提。积蓄在他内心的悲愤是如此的不可宣泄，他就像是燃烧中的布鲁诺，殉道以明志！

Octopress本身并不支持生成Tag，而仅仅支持Category。许多为Octopress提供的Tag Cloud，事实上一种假象，乃Category Cloud。对于博客分类而言，Tag与Category完全是不同的维度。Octopress的Category原理，事实上就是在博客目录下建立对应的Category目录，我们完全可以照搬此做法，简单改造，就可以支持Tag了。当然，为了在博客上生成Tag Cloud，自然还需要使用一些现有的插件。

准备

Octopress有一个第三方插件octopress-cumulus，可以生成酷酷的3D Tag Cloud。当然，本质上，这还是Category Cloud。但它的效果可以为我使用。因此，先按照该插件的要求，下载对应的文件。最重要的两个文件是source/javascripts目录下的tagcloud.swf与plugin目录下的category_cloud.rb。前者是生成3D效果的Flash；后者则是读取Category信息到swf中的插件。至于source/_includes/custom/asides/目录下的category_cloud.html文件，则是用于显示边栏的Tag Cloud效果。

使用Homebrew在Max OS下安装，一切都变得容易了许多。你只需要知道你要安装的软件或工具的名称，然后输入一条命令行即可。不过安装MySQL就有点不一样，在输入命令行安装了MySQL之后，还需要做一些配置。

首先运行命令：

$ brew install mysql

Homebrew确实安装了MySQL，但是运行mysql命令，却并不能进入MySQL。通过在Google上查询解决方案，找到博客Install MySQL on Mountain Lion with Homebrew，给出了如下的步骤：

$ mkdir -p ~/Library/LaunchAgents
$ cp /usr/local/Cellar/mysql/5.5.25a/homebrew.mxcl.mysql.plist ~/Library/LaunchAgents/
$ launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist

$ unset TMPDIR
$ mysql_install_db --verbose --user=`YOUR_USER_NAME` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

$ /usr/local/Cellar/mysql/5.5.25a/bin/mysqladmin -u root password 'YOUR_NEW_PASSWORD'

$ mysql.server start

现在，你就可以运行mysql命令使用MySQL了。

CQRS由Greg Young提出，目前在DDD领域中被广泛使用。在我看来，它甚至可以被称为是一种架构风格，可以取得与MapReduce，REST同等的地位，对软件系统的整体架构产生重要影响。

CQRS即Command Query Responsibility Seperation（命令查询职责分离），其设计思想来源于Mayer提出的CQS（Command Query Seperation）。这种命令与查询的分离方式，可以更好地控制请求者的操作。查询操作不会造成数据的修改，因而它属于一种幂等操作，可以反复地发起，而不用担心会对系统造成影响。基于这种特性，我们还可以为其提供缓存，从而改进查询的性能。命令操作则与之相反，它会直接影响系统信息的改变。查询操作与命令操作对事务的要求也不一样。由于查询操作不会改变系统状态，因而，不会产生最终的数据不一致。从请求响应的角度来看，查询操作常常需要同步请求，实时返回结果；命令操作则不然，因为我们并不期待命令操作必须返回结果，这就可以采用fire-and-forget方式，而这种方式正是运用异步操作的前提。此外，对于大多数软件系统而言，查询操作发起的频率通常要远远高于命令操作。如上种种，都是将命令与查询进行分离的根本原因。

这就很好地阐释了我们为何需要运用CQRS模式，同时也说明了CQRS的适用场景。