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

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

微服务架构设计实践
 


目    次
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. 第五步,根据数据架构、应用架构和技术架构,来设计开发架构。

  微信扫一扫,关注该公众号

  该系列文章已经在微信公众号发布,如果感兴趣,请关注。

   以后更多知识通过该微信公众号分享。



posted on 2019-05-10 01:05 NET未来之路 阅读( ...) 评论( ...) 编辑 收藏

转载于:https://www.cnblogs.com/lonelyxmas/p/10842095.html

你可能感兴趣的:(微服务架构设计实践系列之三:软件架构设计思想)