也谈系统设计的一些原则

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

大道至简，合适最好

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

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

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

技 术人员常常犯的错误是技术至上，技术第一，不计成本的去设计和开发无比先进和灵活的系统，不计风险的去采用最新的没经过实用的新技术。所以作为架构师，不仅仅需要精通技术，

更需要良好的沟通协调，去了解业务和客户真正的需求，真正站在客户利益角度和最终用户利益角度思考问题和设计系统，在各种选择中做出权 衡。

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

稳定压倒一切

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

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

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

系统稳定性如果获得？除了大量充分的测试以外，在设计上必须有针对可靠性的设计，基本原则是在尽量保证各服务可靠的基础之上，通过一个健壮的体系结构来确保系统能够在硬件和

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

可扩展性，灵活性

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

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

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

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

这方面的讨论很多，个人认为可扩展性和灵活性设计是架构设计中非常重要的方面，但不能过度。稳定性第一，接下来是灵活性第二，还是性能第二灵活性第三的问题，要具体看需求的

情况了。如果是一个实时大数据量大用户在线服务系统，应该在性能的前提下实现灵活；如果是一个其他的业务系统，灵活性优先于性能。具体情况要具体权衡利弊。

高性能

在进行性能设计时，首先要与客户充分地沟通，了解客户的性能需求，不管它是清晰的还是暗含的。不要等到项目后期才发现其实数据量是60万而不是10万。所以预先了解项目的性能指标，获取与性能相关的数据，从而预先评估架构的性能指标非常重要。

其他具体的性能设计方法可以参考我另外一篇文章：《架构设计之性能设计经验》

可用性，用户友好性

设计以人为本，到头来还是给人用的。产品经理、客户和最终用户很注重界面，他们不知道你的系统有多么先进，只看界面是不是美观，界面友好，标准，操作流畅，有良好的用户体验(User experience)。界面做好了，客户满意，你就成功了一半；否则内部系统再先进，客户都会认为这个系统非常糟糕，用户体验非常不好。因此，可用性设计在这个Web2.0的时代尤其重要。

针对可用性的设计应该由架构师、用户体验设计师共同完成。可用性设计不等于界面设计。界面设计是静态的，而可用性设计是以用户为中心的交互设计(Interaction Design)，更关注用户的行为和体验。交互设计需要研究角色模型，用户行为和上下文，数据整合和呈现方式等(Persona，goal，scenario)。一个成功的可用性设计/用户体验设计需要一个或多个跨学科的设计师，倾听和收集用户对系统使用的需求、体验或不满，并进行艺术化的设计。

例如一个失败的网站，内容繁杂，让客户无所适从；搜索了一个内容，出来一堆东西，用户想在这里面进一步搜索，却找不到这个功能。而良好的网站设计，用户操作非常流畅，流程很容易让用户理解。简洁明了，没有乱七八糟的东西干扰用户。因为后者仔细研究过用户交互模型，

知道大多数用户的操作习惯和困难，而网站内容是根据清晰的流程设计的。数据的呈现方式也是经过整合的，不是所有数据都呈现给用户，而是呈现对用户有用的数据。

可维护性，可管理性

可维护性包括代码的可理解性，可测试性，可修改性和系统的可移植性。如果一个系统的可维护性从最初没有得到很好的重视，当系统面临重大的设计改动时，会发现几乎无法入手，最简单的方法是彻底推翻重写，于是造成大量的资源浪费。

具体来说，软件系统可维护性差的原因有：

1. 过于僵硬: 加入一个新性能，不仅仅意味着建造一个独立的模块，而且因为这个新性

能会波及很多其他的模块，最好变成跨越几个模块的改动。

2. 过于脆弱: 对一个地方的修改，往往会导致看上去没什么关系的另外一个地方发生故

障。尽管在修改之前，设计师会尽力预测可能的故障点，当是修改完成之前，系统的原始设计师们甚至都无法预测到可能会波及的地方。

3. 复用率低: 每当程序员发现一段代码、函数、模块所做的事情是可以在新的模块、或

者新系统中使用的是，他们总是发现，这些已有的代码依赖于一堆其他的东西，以至于很难将它们分开。最好他们发现最好的办法就是不去“碰”这些已有的东西，而是重新写自己的代码。他们可能会使用源代码拷贝的办法，以最原始的复用方式，节省一些时间。

4. 黏度过高: 有的时候，一个改动可以以保存原始设计意图和原始设计框架的方式进行，

也可以以破坏原始意图和框架的方式进行。一个系统设计，如果总是使得第二种办法比第一种办法容易，就叫黏度过高。

5. 系统过于复杂：系统过于复杂和庞大，结构不尽合理，设计文档缺乏或没有更新，系

统年龄大时间久远。

可维护性设计应该采用灵活架构，采用复用的设计方法，尽量减少相互之间的依赖项，尽量采用成熟的工业应用级的产品和框架，采用代码审查机制等。传统软件工程用可理解性、可测试性和可修改性来衡量软件的可维护性,CASE软件工程则以考察可重用性来衡量可维护性。可维护性最直接的体现是良好的软件结构和完整正确的文档体系。维护应在文档级以上展开,应从软件结构出发,即以重构为核心。可重用性是可维护性的基本属性，最大限度地重用现存软件是软件维护方法学的重要思想原则。

运行可管理性，包括运维对系统软硬件各个部分的监控，以便于控制系统运行、监视系统状态、错误处理。为了实现上述目标，系统应该尽量采用参数化的可配置的设计，模块间通信应当尽可能简单，同时建立合理详尽的系统运行日志，系统通过自动审计运行日志和动态跟踪（dynamic tracing facility），了解系统运行状态、监控资源的使用和配置、进行有效的错误处理。

 

第二篇：系统设计七原则

系统设计的七条原则1988 年 X 系统被设计之时, 有 7 条原则,我觉得非常好, 供给写系统的人作为参考:1 Do not add new functionality unless an implementation cannot completea real application without it.除非一件真正的应用程式非用某种功能否则无法完成, 不然就不要添加新的功能.按: 太多功能却处处相似劣於将他们整合为一个功能, 太多相似的功能往往造成程式设计的选择困扰, 也就是去芜存菁, 方能显现功能的真正实用价值.2 It is as important to decide what a system is not as to decide what itis. Do not serve all the world's needs, but make the system extensibleso that additional needs can be met in an upwardly compatible fashion.要决定一个系统是什麽跟决定一个系统不是什麽是同等重要的. 不须满足全世界的需求, 而应让系统能够延伸扩张, 以便额外的需求能以往上相容的方式被满足.按: 往上相容的意思是, 系统只须再做微小修改便可以将功能更新或扩充.3 The only thing worse than generalizing from one example is generalizingfrom no example at all.唯一比从一个例子中归纳做出结论更糟只有从完全无例子中归纳做出结论.按: 也就是说, 从许多例子中归纳做出结论是好的, 优於自己凭空造想.4 If a problem is not completely understood, it is probably best toprovide no solution at all.如果不能完全了解一个问题, 大概最好别提供任何解决之道.按: 可能解决之道不符合问题本意, 误入歧途, 浪费精力.5 If you get 90 percent of the desired effect for 10 percent of the workrequired to get 100 percent, use the simpler solution.如果因为一件工作的百分之十(该工作要求做到 100%), 你得到想要的效果之 90%,则使用比较简单的解决之道.按: 10% work -> 90% effect (easy) ; 剩馀 90% work 才 10% more effect (hard) ;10% work 是比较好的解决之道, 简单, 有效率, 纵使不能尽善尽美.6 Isolate complexity as much as possible.尽可能把复杂性独立出来.7 Provide mechanism rather than policy. In particular, place user interfacepolicy in the client's hands.与其提供施行方针不如提供处理机制. 特别将使用者介面的施行方针交由客户处理.按: policy => 大纲, 处理规定.mechanism => 细则, 处理流程.-------------------------------------------------------------------------这是发表于某个BBS上的文章，源自何方已无从考证。我觉得这些原则对于应用系统的设计，同样有指导意义。故而摘录于此。（HXX注）