软件架构概念

 

前几天，有几个以前的同事到我家来玩，席间大家讨论到目前流行的软件架构。这些同事大部分目前转向从事软件架构工程师工作，有的想成长为软件架构工程师。大家共同的感受是抛开具体项目谈论软件架构都觉得很简单，不就是RUP的4+1视图与软件架构文档么？但针对具体的项目，总感到力不从心、无从下手，设计的软件架构工作产品总得不到领导与同事的认可，不是有些问题领导与同事觉得没有说清楚，就是有些东西领导与同事觉得过于罗索或繁锁。大家请我根据多年从事软件架构的经验讲讲软件架构究竟应该包含哪些内容、做到什么程度。

而我本人向来注重学习某一理论知识的精神与指导思想并结合具体工作如何应用，不太注重太多的概念与理论，所以大家问到这个问题，我虽然知识大家对软件架构的概念与思想认识存在一定的模糊，但我也一时无法向大家讲解明白。而是我使用大家提到的一个项目为例，从多个方面指出大家的认识不足与正确做法，讲了许多，最后看大家有点仿然大悟的表情下又隐约有许多满腹疑惑，我只好说，我回头好好整理一下思路，过几天再与大家讨论。

刚好这阵了有次我去中兴网信面试，与一位资深的领导再次有幸谈到软件架构的话题。这位资深的领导出了一道面试题，要我根据自己的经验给软件架构作个定义。我从记忆深处进行了深度搜索，一来我向来注重学习某一理论知识的精神与指导思想并结合具体工作如何应用而不太注重太多的概念与理论，二来我记忆中所有的软件架构学习书籍与资料中都回避给软件架构作一个统一的定义，大家都是从各自讲解与重点关注的角度进行了阐述。于是我也从工作经验将软件架构从多个不同角度进行了我力能所及的说明与解释，讲了许多。最后这位资深的领导说我从思维发散的角度多视角的对软件架构进行了较详尽的阐述，但能不能从思维收敛的角度对软件架构作一个精简的定义？我摇摇头，实在很难用精简的语句说明的。而是这位资深的领导用一句话概括：软件架构就是软件系统的主要包括的元素及这些元素间的关系。

虽然我没有接到中兴网信的回复，可是，当我听到这位领导的概括后，我当时真的想拍案叫绝——虽然我心里还是隐隐觉得该定义还是遗漏了点什么重要的东西。

而是我把所有学习软件架构的书籍与资料重新学习了一遍，并上网搜索相关知识。还是延用这位资深领导的定义并结合工作经验与再次学习体会，我这样定义软件架构：软件系统包含的主要元素、重要约束与关键决策，以及它们之间的关系并如何进行协作交互，以满足软件系统的不同涉众需求。

首先说说主要元素。这里说的元素不但包括接口、类、组件，还应有框架、子系统、独立程序（如数据库服务器）、管道、消息等。为什么是主要元素而不是所有元素？一、从需求的角度用户首先并主要关注核心业务需求的满足，如果核心业务需求不能满足，其它的一切都不必讲。这就好比去买手机，如果这部手机不能正常通话，就是再美观、有再多的辅助功能，也不能成其为手机，也就不会有人购买。软件架构作为与客户等涉众人员沟通的工具，不能重点关注如何满足这些核心业务需求的要求，也就失去它存在的意义。如果能够有效的把握这些主要的核心业务需求，也就离软件项目的成功不远了。二、从软件项目开发的现实来看，大多数软件项目都面临项目工期的压力，软件架构工程师必须在一定的时间内决定架构设计方案，否则没有软件架构所提供的对技术的足够指导以及对分工协作的足够限制，开发设计编码团队将面临项目失败的风险。所以软件架构工程师没有时间对所有元素进行深入分析。三、人的精力、能力是有限的，如果不能把主要精力和时间花在决定软件项目成功的核心业务需求上，而是所有软件需求与元素上，最终导致所有需求与元素都分析了又都不够深入，这样的软件架构只能是流于形式的软件架构，对提高软件的质量不但没有帮助反而会害软件项目失败。

最容易被忽略的可能是重要约束。在说明重要约束的重要性前看看这样一个例子：C/S软件系统需要实现信息量不大的高并发实时网络通讯，对于大多数有经验的软件架构工程师都会摒弃SELECT方式的无论是同步还是异步、阻塞还是非阻塞SOCKET通讯模式，而会选择IOCP。但如果软件系统有一条运行约束：系统必须运行在LINUX下，整个软件系统的架构都面临巨大冲击：LINUX下根本不支持IOCP！必须使用EPOLL。所以，许多约束之中其实隐藏着一些隐含的需求，它通过以下三种路径影响软件系统：一、直接制约设计决策。如上面的例子，架构工程师必须直接遵循，并影响关键决策。二、引申并转化为功能需求。这种情况下可能会增加软件系统的元素，如果在软件架构中不进行必要的说明，软件项目的涉众人员可能会对这些"无缘无故突然冒出来的"元素表示疑惑。三、引申并转化为非功能需求。这种情况下也可能会影响关键决策。

可以这样讲：软件架构的每一个过程中的每一步工作都是一系列的重要设计决策。可是最难让人理解是软件架构如何包含决策？这里有两个误解：一是认为软件架构就是RUP的4+1视图与软件架构文档，所以无法说明这些决策。二是在软件架构中引入的每一个设计模式、框架，其实就表现了一系列决策。所以虽然人们不理解软件架构如何包含决策，但其实每一位架构工程师都在不自觉的包含决策。我之所以提出是希望在架构过程中应主动有意识的包含这些关键决策。

主要元素、重要约束与关键决策从局部静态孤立的说明了软件系统的组成成份，而它们之间的关系则是说明它们是如何静态组成一个有机的软件系统整体的；如何进行协作交互则是从动态的角度说明软件系统是能进行怎样的行为、怎样满足软件系统的不同涉众需求。

我之所以决定采用博客的方式来进行软件架构的学习，就是知识自己的认识还是有片面性的一面，希望将自己的学习体会写出来，一来可以交流、共享、保存；二来希望有不吝赐教的同会能有建设性的拍砖，帮助我提高。