开发高质量的软件是一件极具挑战的工作。其中一个重要的原因就是对于“质量”的定义各不相同，变化莫测。而软件架构的设计主要就是围绕满足功能要求和非功能要求，其中的非功能要求就是软件的各种质量属性。
杰拉尔德温伯格在他的四部曲巨作《质量软件管理》的第一卷第一章中就谈到了什么是质量以及质量的重要性。温伯格在书中讲了一个很有趣的故事。某软件企业每年都会根据所开发软件的质量对开发团队进行奖励，质量好的团队将会获得相应的嘉奖。可是如何评价软件的质量是一个令人头疼问题，于是他们采用了量化指标，根据用户反馈的defect的数量来定。某款软件质量超群，自推出至市场以来，只收到了一个defect。于是开发相应软件的团队获得了年度质量大奖！可是这款软件真的是一款高质量的软件么？看看这个defect的内容吧：“该软件无法安装！”
为了了解软件的质量是否满足要求，我们必须定义软件的质量属性（Quality Attributes）。同时质量属性也是影响软件架构的重要因素。软件架构主要由需求决定，需求有功能性的和非功能性的，其中非功能性的需求主要就是指质量属性，即各种“性”（“-ilities“）。wikipedia上列出了大概80种不同的质量属性，下面我们讨论一下其中最常见的属性。
可用性（Availability）
可用性是指系统正常工作的时间所占的比例。可用性会遇到系统错误，恶意攻击，高负载等问题的影响。
当年在一家存储公司开发管理软件，"HA"（High Availability）是一个经常被提及的性能属性。"DU"(Data Unavailable)和"DL"(Data Lost)都是非常严重的可用性问题。
可用性面临的主要问题有：
- 物理层失效：比如数据库服务器宕机，停电， 网络欠费被中国电信断网
- 恶意攻击：例如DOS（Deny of Service）攻击
- 软件的设计问题或BUG：比如错误的资源控制锁导致某个资源长期被占用，各种core dump， out of memery, out of stack。
- 升级或日常维护
针对这些问题，为了增加可用性，需要考虑
- 如何设计故障转移（failover），一般可以使用冗余来消除系统中的单点故障。可以是各种冷热备份，分布式系统。
- 如何设计在线升级。我当年在那家存储公司的一个主要责任就是做在线升级，因为存储设备有两个同时工作的单元构成，所以升级的过程简单说就是先升级第一个单元，然后再升级第二个单元。听上去非常简单，然而实际的升级过程非常复杂，在升级之前，会做非常多的健康检查，比如检查两个单元是不是都在正常工作，有没有坏的磁盘，存储设备的版本是不是满足要求，等等等等。特别是由于存储设备的软硬件型号复杂，还要考虑各种不同的运行环境，各种软件BUG，健康检查非常非常的复杂。当然大多数情况下，用户可以跳过健康检查，然而由此引发的升级失败，后果自负！
- 如何设计异常处理。异常处理是一个很大的话题，为了支持高可用性，我们应该如何处理异常呢？举个例子，一个网站要处理用户的订单，然而由于数据库服务器的故障，虽然前端的服务一切正常，可是订单无法处理。你会怎么处理这个数据库服务器异常的情况呢？大多数的程序员会在捕获异常的时候写日志，把异常状记录下来，然后在客户端的UI上显示一段谁也看不懂的异常代码。这样的异常处理其实跟没做差不多，甚至更糟。那么把异常代码翻译成用户可以看懂的语言是不是会好一点呢？也许会，如果你告诉用户因为你的数据库故障，请明天再来，可想而知用户会多么失望！好的异常处理是把用户的订单请求记录下来，发给人工处理，或者等待数据库恢复后自动处理，并告诉用户订单已经处理，并有可能迟延，请求得到用户的谅解。
- 如何应对不稳定的网络连接。
灵活性 （Flexibility）
灵活性是指系统是否能够很容易的适应环境和需求的变化。
例如现在需求是返回10以内的所有质数。我们可以使用以下程序：
function prime(){
var result = [2,3,5,7];
return result;
}
这段程序非常好，性能也非常高。然而非常的不具备灵活性，通过对需求的分析我们似乎可以大胆的预见10是一个非常有可能会改变的需求，于是提高灵活性的方式就是把10变成可变参数：
function prime(range){
var result = [];
var i,k;
for(i=2; i<=range; i++){
result.push(i);
}
for(i=0; i<result.length; i++){
for(k=i+1; k<result.length; k++){
if(result[k]%result[i]==0){
result.splice(k,1);
}
}
}
return result;
}
我们看到第二段代码为了增加灵活性，代码变的更复杂，运行时间变长。当然第一段代码中的质数根本就没有经过计算验证，完全是我自己计算出来的，因为10以内的质数这样简单的运算根本不需要计算机。
在软件开发中有哪些问题会引起灵活性下降呢？
- 由于各种原因而造成的数量惊人的代码
- 过于复杂的代码
- 不断重复的代码
糟糕的软件中这三点往往是一起出现的。
软件系统通常可以通过以分层，组件化等方式来提高灵活性。我在实践中的原则是”用简单构造复杂“。软件系统本身是非常复杂的，然而构建软件系统的基本单元却应该是非常简单的。例如计算机的基本组成单元是门电路，每一个门电路都非常简单，然而计算机系统却是如此的复杂和灵活。凯文凯利在他的《失控》一书中，也有同样的观点。
构建灵活软件系统的关键在于找到那个简单单元的边界，每一个单元应该足够的简单，但是不能够过于简单，“Simple，but not Simpler！”
概念一致性 （Conceptual Integrity）
我们很少在软件设计的时候谈论概念一致性，也许我们认为概念一致是一个共同的假定，然而实际上，在软件开发的过程中，往往会出现很多概念不一致的情况。
概念一致性的问题主要表现在以下的方面：
- 在一个模块的设计中混杂不同的问题域
- 不同的组织或者团队负责系统中的同一个功能
- 没有统一的代码规范
- 为了满足后向兼容，系统中存在新旧两套不同的代码栈
我们可以看出，这些问题大多是管理的问题。我个人认为，为了实现概念一致性，在软件的设计过程中应该尽可能少的引入新的概念。软件设计的过程是一个抽象的过程，我们把复杂的软件系统抽象为一个个的层，问题域，过程，模块，服务，接口，这些都是非常必要的。但是这些东西都应该是越少越好，能在一两层解决的问题，绝不要划分成四五层，能提供一个API接口，绝不要给三个。人类能够同时掌握的概念是有限的，大部分人可能也就三四个把，当你设计的系统中有五六个或者七八个陌生的概念需要同时掌握的时候，对你的团队中其它需要使用你的设计的开发人员来说绝对是一个巨大的挑战。大部分人不会费力气去搞懂你设计的高大上的新概念。他们很有可能会设计出一套对他们自己更容易理解的并行的方案来解决同样的问题。
互操作性 （Interoperability）
互操作性指的是系统内或者系统之间不同的组件可以有效地进行信息交换，通常是以服务（Service）的形式来进行的。互操作性的关键因素包括通信协议，接口定义，数据格式的定义等等，而标准化是实现互操作性的重要手段。
实现互操作性的主要挑战有以下这些方面：
- 系统内部或者和已有的旧系统（legacy system）之间的数据定义不一致
- 系统的边界模糊，模块之间耦合严重，导致数据冗余
- 缺乏标准，或者各方对标准的实现和认识不一致
我现在所在的商务智能团队的总架构师（Chief Architect）就一直在部门间推动对数据文档统一格式标准的定义和实现。这本身对于我们产品内部的互操作性是非常有必要的，然而BI的团队分布在各个大洲（主要是德国，法国，加拿大，中国和印度），每个部门对各自产品优先级的认识不一致，在加上对旧系统兼容性的要求，这项工作的进展非常非常的缓慢。BI的各个产品仍然很难互操作。
我之前开发过通信网管，当时做的产品是统一网管平台，就是把各个厂商（华为，中兴，朗讯等等）的电信设备统一的管理起来。当时已经有了相当成熟的电信网管理标准（TMF，ISO等标准）和技术标准（Q3,Corba）。然而理解的不同，厂商对标准的实现千奇百怪，所以实际上需要给每一个厂商定制不同的接口适配器。我当时就在负责一些这样的接口开发。
面向服务的架构（SOA）曾经是一个非常热门的词汇，现在似乎不怎么提起了。我司当年曾经大张旗鼓的宣传SOA。其实这样的架构能够解决的一个主要的问题就在能够把企业内部各种已有系统通过暴露标准服务接口的方式有效的协调起来。
为了实现互操作性，我们一般需要
- 定义标准的数据格式和语义
- 定义标准的服务接口，并使用基于服务的架构
- 设计高内聚，低耦合的模块以获得最大的灵活性和可重用性