一线架构师实践指南（一）

绪论

       从本质上，架构设计是需求驱动的，而不是模型驱动的。但当很清楚需求却依然设计不出架构时，就说明“需求驱动的架构设计”的总结还“缺点什么”。架构设计是一门艺术，不可能把“一桶需求”倒进某台神奇的机器，然后等着架构设计自己被“加工生成”完毕，因此“需求驱动的架构设计”的总结给架构师的启发不够。那缺点儿什么呢？答案是“人的因素”、“架构师的因素”。

       质疑意识，是架构师最宝贵的意识之一。通过“质疑”引入更多的“质量属性”，以及“特殊功能场景”来驱动后续架构设计工作的开展。

       架构设计方法的阶段：

       阶段1：把握需求特点，确定架构确定力

       阶段2：根据重大需求，确定概念架构

       阶段3：细化架构设计，关注不同视图

       先做后做——叫做阶段，齐头并进——叫做视图。任何好的方法（不限于软件领域），都必须以时间轴来组织，因为这样才最利于指导实践。

       3个阶段，1个贯穿

       Pre-architecture阶段（PA阶段）：最大误区：架构师是技术人员不必懂需求。

       Conceptual Architecture 阶段（CA阶段）：最大误区：概念架构=理想设计。

       Refined Architecture 阶段（RA阶段）：最大误区：架构=模块+接口

       对非功能目标的考虑贯穿整个架构设计阶段。

子系统划分的4大原则：

l   职责分离原则

l   通用专用分离原则

l   技能分离原则

l   工作量均衡原则

Pre-architecture阶段

       作为架构师，首先要面对的风险就是需求。既要关注功能需求，又要平衡相互矛盾的质量属性需求，还不能遗漏各方的约束性需求。架构师不仅要考虑支持功能、满足质量要求，还要重视各种约束性需求。

        相互矛盾的质量属性：高性能和灵活扩展这两个质量属性之间存在矛盾关系，性能和安全性，与其他许多质量属性都是矛盾的。

在架构设计之初，就全盘考虑架构设计要重点支持的关键质量目标。在第一时间就判断这些“关键质量”之间有没有冲突关系，并制定权衡取舍策略。

架构师不必是需求捕获专家，也不必是编写《软件需求规格说明书》的专家；但他一定应在需求分类、需求折中和需求变更的研究方面是专家。

架构设计对系统成败非常关键。功能需求、质量属性及约束共同决定了架构，对这3类需求的把握是否到位、设计决策是否对路，是架构设计成败的关键所在。

四步法：

1、          需求结构化

2、          分析约束影响

3、          确定关键质量

4、          确定关键功能

Pre-architecture就是架构设计的最前期阶段，其工作目标包括：理解需求、建立需求大局观、确定架构设计方向等。该阶段虽然是铺垫性质的阶段，但对架构实际而言意义重大。

       重大需求塑造概念架构。如果对需求的理解缺乏大局观，那将如何识别重大需求、特色需求、高风险需求？Pre-architecture阶段能够帮助架构师建立理解需求的大局观。任何需求都可定位于业务级需求、用户级需求、开发级需求这3个需求层次的某一层，同时也必属于功能、质量、约束这3类需求的某一类。

       对需求理解不透、遗漏需求往往是架构设计失败的重要原因。

尽早开始架构设计

l   让架构师参与需求分析工作，让架构师相对自由地“全程”参与需求分析工作。

l   不能被动地等待完善的《软件需求规格说明书》出现的那一刻才开始架构设计。满足下列3个条件就可以尽早开始架构设计工作：

1、          有了明确的业务需求

2、          了解全面的用户需求

3、          有了典型的行为需求

明确架构设计的“驱动力”

l   分析业务需求和约束背后的衍生需求

l   发现遗漏需求

l   确定关键功能

l   确定关键质量

l   权衡质量属性之间的矛盾关系

架构设计的目标必然随领域不同、规模不同、条件不同而变化。为重用、简单、可扩展都加了“最”（而不是权衡折中），不符合架构设计的实现、更何况“灵活”和“简单”之间常常存在矛盾。

任何一项功能都是由一条特定的“职责协作链”完成的。作为完整的软件系统，它在支持每一个具体功能时，都必然涉及软件不同“部分”之间的相互配合。质量是完善架构设计的驱动力，不考虑质量的系统是无法走出实验室的。至于约束，则有不同的具体方式影响着架构设计。把多而杂的架构影响因素梳理清楚、建立全面有序的理解。分别针对约束、质量、功能这3类需求开展相应工作。分析约束影响，识别隐含需求；确定关键质量，明确关键质量之间的优先级；确定关键功能，便于更有针对性地分配有限的架构设计时间。

需求结构化

       有经验的架构师懂得运用需求的结构。他们能够将复杂的需求集合梳理得井井有条，为进一步分析不同需求之间的联系（作为权衡折中的依据）、识别遗漏的重要需求打下坚实基础。Pre-architecture 阶段要求进行需求结构化。全面理解需求的各个层次、各个方面，更为分析需求之间关系、识别遗漏需求、发现延伸需求奠定基础。绝不能认为《软件需求规格说明书》就是需求的全部。首先，需求文档常常不够全面，所有有经验的架构师都重视需求文档，但不应该“唯需求文档是瞻”。其次，需求变更经常发生，“依赖且仅依赖需求文档”不够聪明，使架构设计工作非常被动。所以，架构师要通过需求结构化真正全面地“鸟瞰”需求大局，就必须超越《软件需求规格说明书》。还有一个重大的意义在于，只有摆脱对《软件需求规格说明书》提交时间、文档质量、内容变更的“呆板依赖”，才有可能尽早开始架构设计。

       需求是分层次的。业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？需求的三个层次，是站在“不同层次的涉众提出需求所站的立场不同”的角度，将需求划分为三种类型。其次，需求还必须从不同方面进行考虑。实践一再表明，忽视质量属性和约束性需求，常常导致架构设计最终失败。于是，从“需求定义了直接目标还是间接限制”的角度，把需求划分为3种类型，这就是需求的3个方面：

       功能需求：更多体现各级直接目标要求。

       质量属性：运行期质量+开发期质量。

       约束需求：业务环境因素+使用环境因素+构建环境因素+技术环境因素。

       一句话，需求是有结构的。而且，需求的结构绝对不是“List”，而应该是“二维数组”。结构化是控制复杂性的好办法。进行需求结构化之后，复杂性得到了控制。

为什么必须分析约束影响

       风险有一个恼人的特点：一旦你忘记了它，它就会找上门来制造麻烦。对于架构设计而言，来自方方面面的约束性需求中潜藏了大量风险因素。Pre-architecture阶段明确要求必须分析约束影响。分析约束影响的要义：尽早识别风险。业务环境、使用环境、构建环境应分别考虑客户、用户、开发方这3类涉众，而技术环境则和3类涉众都有关。

第一，来自客户或出资方的约束性需求。架构师必须充分考虑客户对上线时间的要求、预算限制，以及集成需要等非功能需求。

第二，来自用户的约束性需求。软件提供给何阶层用户？用户的年龄段？使用偏好？用户是否遍及多个国家？使用期间的环境有电磁干扰、车船移动等因素吗？

第三，来自开发人员和升级维护人员的约束性需求。如果开发团队的技术水平有限、磨合程度不高、分布在不同城市，会有何影响？开发管理方面、源代码保密方面，是否须要顾及？

第四，也不能遗忘，业界当前技术环境本身也是约束性需求。技术平台、中间件、编程语言等的流行度、认同度、有缺点等。技术发展的趋势如何？

架构是应当直接或间接地了解和掌握上述需求和约束，并深刻理解它们对架构的影响，只有这样才能设计出合适的软件架构。

       约束是架构设计的上下文。没有全局观念就不可能成为架构师，“约束是架构设计要解决的问题的上下文”是一个犀利的理解，揭示了“软件需求=功能需求+质量属性+约束”背后更深层次的规律。从本质上讲，分析约束影响就是分析各个需求项之间的关系，并发现被遗漏的需求。

确定关键质量

       如何确定关键质量呢？遵守和运用5 大原则：

n   分类合适+必要扩充。

n   考虑多方涉众。

n   检查性思维。

n   识别矛盾+划定优先级。

n   严格程度符合领域与规模特点。

质量的分类方式是基础，架构师对质量毫无研究绝对不行。任何时候，只要关键属性多于一个，都要考虑它们之间是否有矛盾关系，在第一时间做出权衡取舍，确定不同的优先级。

       持续可用性包括了可靠性。若是分布式系统，安全性差会随时造成系统瘫痪，持续可用性将大受影响，所以持续可用性也包括安全性高的隐含要求。可维护性和可管理性也深刻影响着持续可用性。性能=速度+吞吐量+持续高速性。效率=CPU、内存、硬盘和网络的利用率。

       为什么会遗漏重要的质量属性呢？因为架构师没有全面考虑多方涉众的利益。用户在使用软件系统的过程中，其关心的质量属性可能包括易用性、性能、可伸缩性、持续可用性、鲁棒性等。架构师也应为开发人员而设计。软件的可扩展性、可重用性、可移植性、易理解性、易测试性等也类似，它们都深刻影响着开发人员的工作，使开发更顺畅，抑或更艰难。

       检查性思维这条原则颇为简单。这是一种意识，意识到“在架构设计之初”像“过一遍Checklist”一样，看看每一项质量属性是否确实算不上“关键质量”，从而防止遗漏关键需求。

       架构师应确定关键质量的优先级，并在《架构文档》中明确记录此要求。

       质量严格程度受到系统所处领域及系统规模的影响。首先，不同领域对软件系统的质量要求不同。其次，规模不同，对同一领域的软件而言，产品的要求常常也比项目高，平台的要求常常比产品高。

确定关键功能的4条规则

1.       核心功能

2.       必做功能

3.       高风险功能

4.       独特功能

识别“核心功能”的标志是业务层的接口要放映这些功能。

关键功能子集”的确定并不存在“标准答案”。只要较好地覆盖组成架构的不同职责模块，并体现职责模块之间协作关系的特点，那么“关键功能子集”的价值也就体现了。