如何做好系统设计

在进行系统设计时，不仅要考虑软件的功能性需求，还要考虑非功能性需求，比如软件的性能(Performance)、可扩展性(Scalability)，系统的稳定性(Reliability)、部署(Deployment)和更新(Uprade)，可维护性(Maintainability)，版本的管理，系统的安全(Security)，界面的友好程度可用性(Usability, User experience)等。要想覆盖所有需求，实现一个简单而优秀的系统，可谓艰难。

大道至简，合适最好

什么是优秀的系统设计？ 这个问题颇有争议，但几乎每个软件工程师和架构师都追求优秀的系统设计。当然，系统设计并不代表结果，系统设计只是架构师或者带头程序员的工作，优秀的系统设计必须经由良好的项目管理和团队努力，经过分析需求、设计、开发、测试、分发、维护，以及迭代或重构的过程。中间哪个环节出了问题，再好的设计都将功亏一篑。

可能每个人都对自己设计的系统很自信很满意，但“实践是检验真理的唯一标准”。如果一个系统设计经过实践证明，大家(指客户或用户)公认为优秀的系统，那就是一个优秀的系统设计。

大道至简，适合的就是最好的。其实设计并没有那么严重，适合的就是最好的，简单最好。软件也是一种服务，这个系统设计出来就是为了服务一些用户还没有被满足的需求，如果你能够恰好满足了这些没有被满足的需求，而且能以比较低的代价提供这种服务，那这就是最好的系统。因为系统设计的来源是商业需求，而商业追求利益最大化。你的软件和服务必须比别人功能更加先进，更加好用，对变化的商业 需求反应更加灵活，推出或者升级的速度更快，开发和维护成本更低，才能证明这个系统设计的优秀性。所以系统简单，不能说明你的系统不优秀，说不定设计者有化繁为简的过人能力；系统复杂，功能繁多，也不能说明系统优秀。

技 术人员常常犯的错误是技术至上，技术第一，不计成本的去设计和开发无比先进和灵活的系统，不计风险的去采用最新的没经过实用的新技术。所以作为架构师，不仅仅需要精通技术，更需要良好的沟通协调，去了解业务和客户真正的需求，真正站在客户利益角度和最终用户利益角度思考问题和设计系统，在各种选择中做出权 衡。

极限编程人士的一个响亮的口号是“You aren’t oin to need it”。这其中包含的核心意义就是不要为了考虑程序的可扩展性，把目前不需要的功能加入到软件中来。不要过度设计。抓住重点，合适就好。比如根据二八原则，80%的用户只会使用20%的功能，而这20%的功能就是客户最关注的最需要的功能，也就是软件或服务的“卖点“，系统设计时必须集中精力和充分考虑到这部分需求。如果把精力放在某些花哨的功能上，既不 重要，也没必要，那就是过度设计。要想避免过度设计，我觉得可以遵循敏捷开发方式来做。尽可能的简单设计，当满足不了时，重构；保证产品是可运行的，不断的加入新的特征；产品经常性的提交给客户使用。

稳定压倒一切

标题党的风格，但这个口号在社会上如此，系统设计上也是如此。系统的稳定性压倒一切，即使牺牲性能，也要确保系统的稳定。即使扩展性不强，也要保持系统稳定。即使用户界面不友好，也不要系统不稳定。

为什么用户这么关注稳定性？由于人们日常的工作对系统依赖程度越来越多，因此系统必须可靠。举个例子，我想我们都玩过CPU超频吧，频率高了确实挺爽，但如果一天死机几次，正在干的活全部丢失，你心里还会放心踏实的工作吗？同样的道理，一个网站如果不稳定，经常宕掉，用户的信息和辛辛苦苦写的文章搞丢失，还会有人上这个网站吗？所以稳定性是系统设计最重要的方面。

但实施起来比说起来困难，有时候为了实现系统灵活的扩展性，导致系统架构不稳定；也有时候为了实现高性能，导致系统不稳定。如何取舍和平衡，不同的需求，不 同的架构师会做出不同的抉择。但个人认为稳定性放第一位，再先进灵活的框架，再牛的功能，如果不够稳定，坚决不要没有充分测试匆忙上线。

系统稳定性如果获得？除了大量充分的测试以外，在设计上必须有针对可靠性的设计，基本原则是在尽量保证各服务可靠的基础之上，通过一个健壮的体系结构来确保系统能够在硬件和软件出错的情况下依然平稳的运行。比如采用统一面向方面的框架，统一的异常处理、错误隔离、报警、容错和恢复机制，考虑系统的冗余度，尽可能地避免单点故障，尽可能地保证一个进程故障都不会引起系统的瘫痪，同时也允许系统对部分服务做升级和维护而不影响系统继续提供核心的服务等等。总之，系统可靠性是系统在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程序的概率。成功地运行不仅要保证系统能正确地运行，满足功能需求，还要求当系统出现意外故障时能够尽快恢复正常运行，数据不受破坏。

可扩展性，灵活性

毋庸置疑，一个先进的系统设计具有很强的可扩展性和灵活性，因为现在的商业需求变化迅速，如果每次小小变化都导致大量系统改动的话，这样的体系结构无疑是失败的。所以架构师必须去主动迎接未来可能的变化，设计灵活的可扩展的架构。但具体系统的可扩展性做到哪个程度，以及和其他设计指标的权衡利弊如何取舍是个问题。

比如具体灵活到哪个程度的问题，是要实现对各个组件的无依赖性，是要实现对具体数据库(File/XML/SQL Server/Oracle/DB2)的无依赖性，还是要实现对具体操作系统(Windows, Linux, OS2, AIX)的无依赖性？灵活程度不一样，设计要求和设计方法不一样。

架构设计必须尽量封装可能的变化，例如在业务流程发生有限的变化时（比如每个业务模块本身的业务逻辑没有变的情况下），能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求；如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块或组件调用规则即可。这就是按需设计，不是过度设计。

设计指标的权衡利弊如何取舍的问题也很明显，比如降低依赖性常用的方法是封装变化(Wrapper)，分层设计，但会带来系统的性能下降，尤其是大数据量的情况下；引入缓存机制吧又会增加系统复杂性，降低系统稳定性等。