关于软件设计的抽象思想
曾经被阿里的某CTO问过一个问题：什么是好的架构？
听到这种最著名的开放式问题，我心里“咯噔”一下，心想：“又来了”。
一个老生常谈，莫衷一是的话题，得与失只在一念之间。
贤哲们的思想，犹如星辰遗落的闪光碎片，美丽零散；正如人生哲理，再著名的编程思想也是一样的细碎不成体系，在现实的复杂性面前会被毫不留情的击得粉碎。但是他山之石可以攻玉，如果不了解那些名词，想必设计思维还会有所欠缺。
下面尝试整理一下我所思考过的那些问题。
架构的原罪：变与不变
软件之所以称为“software”,根本性的原因就在于它是可变的。要修改一个硬件，必须用物理化学手段如高温、高压、强酸、化合等等原子分子级别的操作，而且往往是不可逆的。在计算机发明以前，人类文明几万年的历史，主要是硬件史。更快更简单的造出或掠夺更好的硬件，就是生产力。计算机发明以后，另一个位面：虚拟世界诞生了。在这个位面里，改变衣服的颜色不是先漂白再用着色剂染色，而是修改一个RGB数字；发射子弹不是通过机簧的张力而是一个函数调用；核爆炸试验不需要原子反应而是CPU计算。通过二进制将模拟世界转变换成数字世界，世界的一小部分能通过电磁现象得以模拟，最直接的也是最大的红利就是：相比物质时代，改变的代价变得前所未有的小，促使生产力的爆发性增长。
软件变动的代价再怎么小，我们也仍然觉得麻烦。市场经济下，人类对生产力的追求是无止境的。所以，软件设计的核心追求是：尽可能不变！由于这个潜在的原动力，虚拟位面的造物主开始借鉴现实世界的一切智慧结晶。西方建筑学的计模式（或者我国宋代逆天的《营造法式》？），机械制造的标准件，音乐的结构、曲式、旋律等乐理，社会组织制度，生物，化学，工艺流程，甚至简单到积木和钩子，无一不是造物主们灵感的源泉。（题外话：好程序员应该是博学的，只有精通现实世界才能更好的构造虚拟世界嘛）
为了救赎“变”这个原罪，造物主有个很直觉的思路：
“将变与不变相隔离！”
这句话在软件设计史上的地位相当于原始海洋中细胞膜的诞生，毫不起眼，但是意义无远弗届。统治当代编程思想的面向对象由此发轫。数据和方法一朝碰头，有趣的概念就自然而然的诞生了：类，对象，消息，接口，抽象，继承，多态，封装，复用，多么像一群单细胞生物啊！
造物主当然不会止步于此。类和类可以通过各种设计模式（factory、abstract factory、builder、bridge，command,decorator,flyweight,iterator,mediator,observer,proxy,facade,singleton,chain of responsibility,vistor,state,strategy,template）组成类库或模块，他们遵循的原则包括：“单一职责”，“开闭”，“liskov替换”，“依赖倒置”，“接口隔离”，“重用发布等价”，“共同封闭重用”，“无环稳定依赖”，“稳定抽象”等，到此为止，多细胞生物诞生了！模块一般表现为一个包，为了解决依赖性封装为OSGI、maven、jigsaw或者js的AMD，nodejs的npm，ruby的gem，debian的apt等。
“将变与不变相隔离”，说得fashion一点就是“解耦”，通俗一点就是“把会变的逻辑用设计技巧从稳定的逻辑中抽取出来，使软件设计不用修改就能适应需求的变化”。一个合格的架构师要具备厘清问题领域中哪些是变，哪些是不变，哪些是可能变的洞察力，需要对各种设计技巧和优劣心知肚明，然后才能开始着手设计。这种洞察力在基础软件领域有一些成熟的经验，譬如管道、请求响应、MVC、IOC、代理等等，由于基础应用的需求稳定，所以这种架构的着眼点更关注灵活性、扩展性、性能等方面，学习参考Spring、Jetty、Netty、Nginx。在应用软件领域，这个洞察力就不太靠谱了，因为软件的用户变成了人，逻辑像野草一样不可控起来。费尽心力设计一个优雅的系统，客户的一句话就得改头换面。架构师很痛苦，尤其在web方面，很少见到在逻辑层用上什么设计模式，如果用上了，基本也是吃力不讨好的后果。“变”与“不变”，是架构师需要学习的第一堂课，是指导我们行动的准则。一个逻辑，如果无法判断其稳定性，就不要花费精力设计，否则迟早掉入“过度设计”的坑里。
架构的抉择：选择合适的技术而不是最好的技术
多细胞生物怎么协作呢？模块通过各种纤尘、线程或进程运行，与进程内或进程外甚至远程的其他模块以各种稀奇古怪的方式通信，包括函数调用、共享内存、文件、管道、消息、信号量、socket，这些通信方式有的还涉及到序列化和反序列化，譬如RMI、hessian、xml、json、thrift、protobuf、phprpc、amf、avro等。模块接着整合为应用，在OS或虚拟机上运行，抢夺CPU指令流水，占领内存，处理IO的IN/OUT，把虚拟世界运转起来。应用可以扩张成集群，不管是水平扩展还是垂直扩展，通过代理服务器、负载均衡路由、LVS等方式，IO、Memory和CPU的负载可以得到分流，从而架构出大规模计算集群；反之汇总集群计算结果的方式有map/reduce、集中式存储等。基本从家庭发展到了部落。已经有了生物聚集性，离蚁群的群体智慧还有一步之遥。现在方兴未艾的云平台和开放平台浪潮，则进一步将各个部落开放出来，各个平台通过互联网也具备了整体协作的简单能力。
我们处在这样一个空前复杂的虚拟生态系统之中，能选择的实在太多了。作为架构师，这是一个整合的时代！
选择合适的机房，合适的硬件，合适的平台，合适的语言，合适的框架，合适的数据存储，合适的分布式，合适的协议，
到处都是选择题。怎么选？
如果你头脑惯于发热，或者极度追求高端技术，甚至是为了技术而技术却忘了产品的成功才是你应该追求的目标，你往往会做出一些漂亮的架构，能为简历增光添彩，但却对团队伤害至深。要选择最合适的技术，而不是最好的技术。就像算法的本质是空间与时间的博弈，架构的本质是开发效率和产品目标的平衡。开发快，运行快，可扩展，能重用，好测试，容易部署，便于运维，学习成本低，好招人，甚至公司的中远期规划，这些责任是架构师必须铭记在心。架构师要慎重抉择每一项技术，有针对性的做性能测试，压力测试，代码实现，周边工具调查等实际的劳务。你应该对各种性能参数了如指掌。JVM一次普通方法调用，一次反射方法调用，一个事务插入，索引查询，一次http通讯，一个memcache set操作的耗时这些细枝末节往往是决定架构成败的关键。
在我决定离职的那段时间里，我一直在反思两年中公司所犯下的错误。除了产品的问题，技术架构也是一个决定性的败因。由于未知的历史原因，公司形成了C++,Flash,Java三个技术团队，互不统属，用网络游戏的架构加上千万PV的web架构开发两套互联的产品，技术很复杂，迭代很迟钝。作为java架构师，我也是很缓慢的才觉察到大局的失误。大错已成！到我管理整个技术部时有心杀贼无力回天。这段创业失败的经历教会我很多，其中之一就是：合适的目标加上合适的技术才是王道，不要好高骛远，不要追高求新，在创业初始阶段开发效率和用户体验是第一位的。
相关架构参考：
一个架构已经存在并良好运作了，还有什么要做的？要防止它腐化！与时俱进。这又是个大课题，幸亏有人写得比我好多了：http://www.infoq.com/cn/articles/cjz-architecture-corruption 作者是前yahoo工程师陈金洲，应该还有人记得他写的buffalo框架吧，我很喜欢用。
携程网的架构演化：http://www.infoq.com/cn/presentations/ly-ctrip-on-soa
讲的比较实在和翔实，现实的世界里不只是漂亮的图表，而是要把繁杂的遗留系统优化成井井有条的理想世界。SOA架构，简单的分布式事务，ESB服务，服务治理，携程基本上是一个处于初级阶段的大型系统。