微服务架构设计实践系列之三：软件架构设计思想

微服务架构设计实践 

目    次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 物理架构4.4.6 开发架构
3  软件架构设计思想

3.1  软件架构定义
        对于软件架构的定义，仁者见仁，智者见智。目前，业界比较流行的两大流派是组成派和决策派，这两派的概念相辅相成，具体如下：
        组成派：软件架构 = 组件 + 交互。
        决策派：软件架构 = 重要决策集。
        上述两大流派的描述过于抽象，不利于理解，本人更喜欢下述关于软件架构的描述，通俗易懂，即：
        软件架构是软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构描述的对象是直接构成系统的抽象组件，各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。
        软件架构是一个用于指导系统实现的草图，这个草图越详细对于系统实现的指导意义越重大，贯穿于软件的整个生命周期。
3.2  软件架构本质
        架构的本质就是对系统进行有序化重构，不断减少系统无序的程度，使系统不断进化。
        架构从无序到有序的基本实现手段是分和合，即先把系统打散，然后重新组合。
        分的过程是把系统拆分为各个子系统、模块、组件。拆分的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。合的过程就是根据最终要求，把各个分离的组件有机整合在一起。
        分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷；
        合的结果使系统变得柔性，可以因需而变，实现业务敏捷。
        相对来说，第一步的拆分更难。
3.3  软件架构过程
        在此次软件架构设计过程中，采用了温昱老师在《软件架构设计》一书中提及的ADMEMS方法体系。
        ADMEMS方法通过3个阶段和一个贯穿环节，来覆盖“需求进，架构出”的完整架构设计过程。
         


3.3.1  PA阶段
        架构准备阶段是架构设计的第一个阶段，此阶段的工作目标是：理解需求，建立需求大局观，确定架构设计方向等。
        功能需求、质量属性和约束共同决定了架构，对这3类需求的把握是否到位、设计决策是否对路，是软件架构设计的关键所在。
        如果可能的话，架构师应该尽早的参与需求分析工作，对需求进行大局的梳理，而不能被动地等待《软件需求规格说明书》的完成。
        只要满足以下3个条件，架构师就可以开始架构设计工作：
        1.明确的业务需求：甲、乙双方对系统的目标达成共识，《愿景文档》通过了正式评审，并且明确了投资、工期标准、整合等约束条件。
        2.全面的用户需求：系统范围明确，即系统能帮用户干什么，不能干什么。
        3.典型的行为需求：核心功能的《用例规约》已定义。
        在架构准备阶段，通过对软件需求的详细分析，抽取出确定概念性架构所需要的关键需求。
        此阶段的输入是软件需求（即上述的三部分：明确的业务需求、全面的用户需求、典型的行为需求），成果物是确定的关键需求，包括关键功能、关键质量属性和关键约束影响，作为下一个阶段的输入。
3.3.2  CA阶段
        概念架构是对系统设计的最初构想，对大型系统的成功非常关键。
        概念性架构定义了系统的高层组件，笼统地界定了高层组件的职责，以及它们之间的关系。
        概念性架构主要是对系统进行适当的分解，而不陷入细节。
        概念性架构规定了每个组件的非正式规约及架构图，但不涉及接口细节。
        在进行概念架构设计时，必须牢牢抓住重大需求、特色需求、高风险需求，有针对性地确定解决方案。
        关键需求塑造概念架构。反过来，概念架构体现关键需求。
        此阶段的输入是关键需求，包括关键功能、关键质量属性和关键约束影响，成果物是针对关键问题的解决策略，和以高层抽象组件方式描述的整个系统的组成草图，可以用在《软件方案建议书》。此成果物作为下一个阶段的输入。
3.3.3  RA阶段
        从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略；再进行细化架构的设计，以保证为开发提供足够的指导和限制。
        在细化架构阶段，整体设计思路为以分而治之为核心思想的多视图方法。
        此阶段的输入是关键问题的解决策略，和以高层抽象组件方式描述的整个系统的组成草图，成果物是描述系统的各种视图，这些视图从不同的角度，不同的关注点，描述了抽象的、完整的系统解决方案。
3.4  软件架构视图
        多视图方法是业界广泛认可的一种架构设计思路。
        一种优秀的多视图方法，应该能够比较完善地覆盖架构设计的各项工作内容，并且将每项工作内容明确地、有理有据地、一目了然地划归到不同的架构视图中去。
        在多视图方法中，每个视图都从一个思维角度聚焦一组技术关注点，都从特定角度规划系统的拆分和组合，都是架构的一种体现。
        多视图方法种类繁多，其中影响最大的当属由Philippe Kruchten于1995年首次提出的RUP的4+1视图方法，涉及视图分别为逻辑架构视图、运行架构视图、开发架构视图、数据架构视图、物理架构视图。
        另一种在架构设计中经常使用的多视图方法是联邦企业架构框架（Federal Enterprise Architecture Framework），涉及视图分别为：业务架构视图、数据架构视图、应用架构视图、技术架构视图。
        本人所使用的视图方法是以RUP的4+1视图方法和联邦企业架构框架为基础，基于本人在架构设计方面的实践经验，总结出常用的6中架构视图，涉及视图为：业务架构视图、数据架构视图、应用架构视图、技术架构视图、物理架构视图、开发架构视图。
        为了理论与实践相结合，对于每种视图的介绍放到架构设计实践的细化架构阶段，结合实际的项目，详细描述每种视图。
3.5  架构之间的关系
        从根本上讲，架构设计毫无疑问是需求驱动的。所以，软件需求是整个软件架构设计过程的前提条件。
        在架构设计过程中，不同的架构视图之间并不是孤立存在的，它们之间存在着依赖关系，并且这些依赖关系也决定了这些架构视图的设计顺序，具体如下：
        1. 第一步，根据用户需求确定业务架构。
        2. 第二步，根据业务架构，分析、定义数据架构。
        3. 第三步，根据数据架构，并结合功能需求定义应用架构。
        4. 第四步，根据数据架构与应用架构来设计技术架构。
        5. 第五步，根据数据架构、应用架构和技术架构，来设计开发架构。
  微信扫一扫，关注该公众号
  该系列文章已经在微信公众号发布，如果感兴趣，请关注。   以后更多知识通过该微信公众号分享。