不管是做一个新的系统，还是重构优化老的系统，需求整理是第一位的。 我们可以通过一系列的问题来厘清需求，分清主次，比如：

– 这个需求一定要做么？不做会怎么样？

– 这个需求带来的系统代价有多大，是否值得，能否有变通的方法

– 这个需求可以下次做么？

特别要提到，如果是重构系统，很多以前的需求可能都不存在了，这样可以减少很多设计的时候的限制，甩掉这些负担，新设计能够轻装上阵

放眼外部架构

基于一个原则：世界上大部分的问题，别人已经遇到过，并且已经有了方案，虽然可能不是最优的，但也是可以学习的。学习的来源，主要有以下几个：

– 公开的论文、文章，特别是一些著名公司的系统设计论文，很有参考价值。

– 对类似系统熟悉的同事朋友

– 经典的书籍

平时对外部架构的学习积累是很重要的，这样在你需要设计一个新系统的时候，就会源源不断的有灵感，遇到类似的问题，想想别人是怎么抉择的，从而得出比较好的设计。

架构设计的原则

系统越简单越好

简单不是简陋，是通过对需求的深刻理解，精心设计，从而保持系统的简单。简单，能带来很多好处：

– 实现起来不容易出错，是一个可控的系统

– 可理解程度更高，维护简单

– 容易扩展

这个原则被很多架构设计者熟知，但要做到并不容易，很多系统设计之初是一个简单优雅的系统，到后来越来越臃肿。主要的原因，在我看来，有可能一开始对需求没有深入理解，漏掉了一些需求，或者是对系统的考虑不全面，导致有重大缺陷，后来为了补坑，让系统越来越复杂。

复杂的系统拆分成简洁的子系统，并保持子系统间交互越清晰越好

复杂的系统总是容易出错、脆弱的，如果能够拆分就尽量拆分，并保持系统间的交互越清晰越好。模块之间常见的一种接口是数据，在我看来这是很强壮的。Unix系统一个突出的优点：工具之间输入输出的就是通过管道来进行，用多个小的工具就拼成灵活而强大的系统：

svn status|egrep ".cc|.h" |egrep "A|M" | awk '{print $2}' |xargs python cpplint.py

利用所有可利用的成熟系统

一个新系统设计的时候的周边生态系统和老系统设计的时候，一般都有较大的不同。业界有很多非常成熟的开源框架系统，把设计建立在这些成熟系统上，是站在巨人肩膀上，可以站的更高，做出更先进稳定的系统。

利用这些系统，新架构会更简单，可靠，强大。

架构中要留下扩展演进的能力

系统架构所满足的需求有可能经常变动，所用的资源也是如此。因此在系统设计的时候，需要考虑架构扩展演进的能力，留下满足未来空间的可能，但也是要平衡好，不要太多地增加现有系统的复杂性。

架构要有监控运营

当你实现的系统最终跑起来的时候，你需要了解他的运行情况是否符合你的预期，是否存在缺陷，哪里可以优化，内置的监控运行模块会帮你的大忙。而且在设计之初就需要考虑这一点，如果后来系统已经实现好了，再回头来加，难度要大很多，而且可能让系统比较丑陋。

《UNIX编程艺术》这本书里一些重要的原则非常值得借鉴：

– 使用简洁的接口拼合简单的部件

– 清晰胜于机巧

– 设计时考虑拼接组合

– 设计要简洁，复杂度能低则低

– 除非确无它法，不要编写庞大的程序