软考系统架构设计师范文3:论基于架构的软件设计方法及应用

论基于架构的软件设计方法及应用

 

 

摘要：

 

2017年5月，我参加了公司“数据中心管理系统”项目的开发，并担任系统架构师职务，负责系统的架构设计。该系统旨在将公司分散在全国各地的数据中心内的设备实现终端统一监控并管理。本文以数据中心管理系统为例，论述了基于架构的软件设计方法在项目中的具体应用。着重从架构需求、架构设计、架构实现三个阶段展开介绍。在架构需求阶段，通过用户访谈、问卷调查、现场观摩、构造原型的方式全面获取了需求；在架构设计阶段通过UML模型中的4+1视图来对系统的架构进行建模；在架构实现阶段，对系统构件进行了获取、开发和组装。该项目于2018年11月完成验收后正式上线，交付至今运行稳定，得到了公司的嘉奖和用户的一致好评。

(欢迎交流备考345092496)

正文：

背景和项目概述：

 

2016年7月中国电信提出了适应智能化时代、通过智能牵引转型升级的3.0战略，着重推进网络智能化、业务生态化、运营智慧化，构建行业领先的物联网开放平台，为客户提供强大的物联网能力应用服务，重塑客户业务流程，挖掘业务价值，降低运营成本。公司一方面落实集团战略，一方面也因为公司业务多年来的不断扩展，在全国各地逐渐建设了多个数据中心，传统的数据中心管理模式是单机的，即为每一个数据中心设计一套管理系统，安排管理人员负责状态监控，事件处理和数据上报等工作。随着数据中心的不断增多，地域分布广泛，继续使用传统的单机模式必将增加大量的人力物力开支。

如何统一管理所有数据中心的所有设备，降低管理成本，减少人力物力开支，成了公司亟待解决的问题。我公司多年从事数据中心的设备生产、模块设计、设备管理以及相关软件开发，有着丰富的相关经验，经公司所有部门领导商讨后决定由开发部门负责开发一套数据中心管理系统。公司组建了12人的开发团队和3名系统实施人员，并任命我为该项目的系统架构师，负责软件架构设计和开发工作。

系统经过仔细梳理之后，拆分为四个主要模块。设备接入模块是与网关设备相接的模块，负责与网关设备进行消息交互；消息处理模块将设备传入消息和业务层处理结果转换为各自所能识别和处理的格式；规则模块根据自定义规则对相应消息反馈处理结果并进行消息持久化；业务模块包括系统管理、设备管理、网络组件管理、通知管理、规则管理、日志管理等功能。

 

过渡段：

ABSD是架构驱动的，强调由商业，质量和功能需求的组合驱动软件架构设计。强调用视角与视图描述软件架构，用用例与质量场景描述需求。ABSD有三个基础，即功能分解，架构风格的选择，以及软件模板的使用。本文首先介绍ABSD开发阶段以及每个阶段包括哪些活动，并结合项目论述ABSD的具体应用，最后讨论一下我在本次项目开发过程中遇到的问题和解决方案以及个人感悟。

 

论点：

技术介绍：

 

基于架构的软件设计方法（ABSD）包括架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化六个阶段。架构需求阶段明确用户对系统在功能、行为、性能、设计约束等方面的期望，包括需求获取、标识构件和架构评审；架构设计阶段根据需求生成并调整架构决策，包括提出架构模型、映射构件、分析构件相互作用、产生架构和评审；架构文档化阶段对架构设计分析与整理，产生架构规格说明书和架构质量说明书；架构复审阶段评价架构能否满足需求与实现质量属性、层次构件划分是否合理，标识潜在的风险，及早发现设计中的缺陷错误；架构实现阶段对架构进行实现，包括架构分析与设计、构件实现、组装和系统测试；架构演化阶段主要解决开发中用户需求变更问题，包括架构演化计划、构件变动、更新构件相互作用、构件组装测试与技术评审。

 

结合项目：

架构需求阶段，在此阶段遇到的主要问题是OJ平台需要支撑全校编程课程的教学活动，这就需要有效、快速地全面获取需求。在需求的前期阶段，我们采用了用户访谈和调查问卷结合的方式，把需求调研团队分成了几组，分别进行需求收集。通过与课程教学组长的详细沟通，我们对OJ系统的主要业务功能、用户角色等有了整体、全面的了解。之后又制作了调查问卷表格，下发给各位任课教师，经过统计整理后，我们获悉了编程课程的教学活动、过程细节。在需求的中期阶段，我们在课程教学组长的协助和安排下，跟随任课教师，前往学校的计算机实验室，对目前编程课程的实验教学现场进行了观摩，了解了在传统实验教学方式中，学生和教师们的具体操作流程。在需求的后期阶段，我们基本上已经完成了大部分业务需求的收集，通过快速原型法构造出了一个仿真的OJ系统，供用户试用与反馈，让用户也参与到设计中，提供了工作流程方面、业务领域方面不可或缺的经验，也为以后项目通过验收提供了有力支持。

  架构设计阶段，在此阶段遇到的主要问题是如何合理设计与描述软件架构。我们以UML模型中的4+1视图来对架构建模。场景视图使用UML模型中的用例图来进行建模，结合用户需求，在系统中划定了在校学生、任课教师、系统管理员、校外人员四类用户角色，并分别为这些角色标识了相应用例。逻辑视图使用UML模型中的包图来进行建模，我们经过分析，决定采用微服务架构风格开发，将系统分为前端Web服务、平台保障服务、业务服务三部分。前端Web服务由负载均衡与服务器集群结合；平台保障服务分为API网关、服务注册中心、监控平台，用以实现基础服务框架；业务服务分为多个微服务，实现具体业务功能。物理视图使用UML模型中的部署图来进行建模，系统微服务采用分布式的部署方法，每个微服务根据实际情况可在同一台物理机器或多台物理机器上同时部署多个实例。集群通过负载均衡做统一访问，部署为路由模式，系统内部网络与外部网络分属于不同的逻辑网络。在负载均衡算法的选择上，使用了最小连接法。

   架构实现阶段，在此阶段遇到的主要问题是系统构件如何实现和组装。构件实现分为两种方式：获取现有构件、开发新构件。OJ系统需要与教务管理和OA系统对接，我们使用开发商提供的SDK实现；微服务架构的基础框架，如Spring Cloud、Eureka，以及评测机调用的编译器等，直接集成第三方软件实现。对于常见信息系统共同具备的用户管理、角色权限管理、日志记录、内容维护、消息中心等基本功能，通过取用单位过往项目开发中所积累的相应构件来实现。对于OJ系统专属功能构件，需要专门开发，我们使用了多种设计模式，例如通过装饰器模式来实现同一试题在实验作业、比赛、考试等多种使用场景下的扩展功能，通过策略模式来实现评测机对C语言、Java、Python等多种编程语言的不同编译方法。构件实现完成后，我们根据不同业务类型，采用了不同的构件组装方式。例如考试服务从题库获取试题信息，采用同步消息方式；程序评测服务属于耗时操作，采用异步消息方式；涉及审批流程的业务，采用基于工作流的组装方式。

 

结语：

 

从本次项目开发整体来看，良好的架构风格选择使模块间耦合度降低，提高了系统的性能，可用性和可修改性等多项指标，满足公司的预期要求，保证系统后期的快速二次开发和数据接入。但在系统开发过程中也遇到一些问题，第一，由于设备数量较多，使用ID标识设备会导致数据可视化效果较差，难以定位设备。为此我采用经纬度定位和设备ID标识相结合两种方法结合，使用Echarts+VUE获取数据，以百度地图为基底直观展示所有设备，方便快速定位。第二，大量的控制层代码与关系数据库持久层的交互使运行速率较低，为提高效率，我增加Redis作为缓存和Elasticsearch搜索引擎，虽然增加了系统的复杂性，但数据访问速率得到了极大的提高。

此次项目的顺利完成为我在项目的架构风格选择等方面积累了更多的经验，同时也暴露出自身在架构风格选择方面的还存在一些不足，我应当总结本次项目经验，力争在下个项目中做到更好。