软考系统架构设计师范文2：论面向服务的架构及其应用

论面向服务的架构(设计)及其应用

摘要：

 

2017年5月，我参加了公司“数据中心管理系统”项目的开发，并担任系统架构师职务，负责系统的架构设计。该系统旨在将公司分散在全国各地的数据中心内的设备状态与信息通过一系列传输协议发送到服务端，服务端进行分析和处理后反馈给设备操作指令或给管理人员发送通知信息，最终实现终端监控并管理所有设备。本文以数据中心管理系统为例，论述了软件架构风格在项目中的选择与应用。整个系统选择数据抽象和面向对象、管道/过滤器、基于规则的系统和进程通信四种架构风格组合应用完成项目，有效的实现了终端统一管理所有数据中心，同时证明了良好的架构风格选择和应用使系统的性能、可用性等指标都达到了预期目标。该项目于2018年11月完成验收后正式上线，交付至今运行稳定，得到了公司的嘉奖和用户的一致好评。
   (欢迎交流备考345092496)                                                                                                                                                         

正文：

背景和项目概述：

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

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

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

 

过渡段：

在架构设计之初我分析了将要开发的所有模块的特点。由于系统的组成模块较多，各个模块的开发语言、架构风格、执行标准等都可能有所不同，为保证各个模块之间以统一通用的方式进行交互，满足系统整体标准化、松耦合、粗粒度服务和可移植性等多方面因素后，我决定采用面向服务的架构设计来开发该系统。本文首先阐述SOA主要的技术和标准及每种技术和标准的具体内容，并论述如何使用面向服务架构开发系统，最后描述本次项目开发过程中构件面向服务架构时遇到了哪些问和解决方案以及个人感悟。

 

论点：

技术介绍：

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。与 SOA 紧密相关的技术主要有 UDDI、WSDL和SOAP。其中UDDI（统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的注册规范，主要包含数据模型、API和注册服务三项内容；WSDL（服务描述语言）是对服务进行描述的语言，它有一套基于 XML 的语法定义，包含服务实现定义和服务接口定义；SOAP（简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP 用 XML 来格式化消息，用HTTP来承载消息。通过SOAP应用程序可以在网络中进行数据交换和远程过程调用。SOAP主要包括封装、编码规则、RPC和绑定四个部分。

SOA主要的实现方式有WebService、ESB和服务注册表，本次在项目中使用的是WebService方式实现SOA。在该方式中包含三个重要角色，分别是服务提供者、服务请求者和服务注册中心，下面说明具体的构建过程及遇到的问题和实施效果。

结合项目：

服务提供者，主要完成服务的设计、描述、定义和发布工作。通过对业务的分析梳理，并综合考虑粗粒度、松耦合、自包含等特点对服务进行了设计。同时为了避免服务间通信量过大、交互频繁，尽量减少了服务的数量。经设计初步提炼出设备接入、消息处理、规则反馈和业务分析四个主要服务。其中设备接入服务与网关设备相接的服务，负责与网关设备进行消息交互；消息处理服务在网关设备接入服务和业务分析服务之间将输入的消息经过顺序处理和转换后产生输出流；规则反馈服务为使用频率较高的消息自动执行反馈及相应操作；业务分析服务负责系统管理、设备管理、网络组件管理、通知管理、规则管理、日志管理等。

服务注册中心，服务注册中心是连接服务提供者和服务请求者的纽带，服务提供者在此发布服务描述，服务请求者在此查找需要的服务。虽然在某些情况下服务注册中心是可选角色，但注册中心的存在可使服务提供者和服务消费者进一步解耦。本项目为了保证系统中各服务间松耦合和相互独立性，在架构设计中使用了该技术，注册中心内包含已发布的设备接入、消息处理、规则反馈和业务分析四项服务，其描述信息主要包括服务功能描述、参数描述、接口定义等相关内容。

服务请求者，服务的请求者即是服务的消费者，通过服务注册中心可查找、绑定和调用服务。系统中主要的流程是设备信息收集和业务结果反馈。数据中心管理系统利用服务注册中心获取对应的服务接口、参数和返回值实现动态绑定。在设备信息收集阶段，设备通过设备接入服务将消息发送到消息处理服务，消息经过格式转换后发送到规则反馈或业务分析。在业务结果反馈阶段，业务分析或规则反馈服务将处理结果通过消息处理后发送到设备。在服务调用期间请求者不需要关心服务提供者的业务处理和技术实现，只需关注自身业务，简化了开发流程提升了工作效率。

结语：

从本次项目开发整体来看，SOA架构的使用使模块间耦合度降低，提高了系统的性能，可用性和可修改性等多项指标，满足公司的预期要求，保证系统后期的快速二次开发和数据接入。但在系统开发过程中也遇到一些问题，由于SOAP是基于XML方式通信效率较低，当消息爆发式增长时，会造成大量的消息积压，无法得到及时解决，因为消息的反馈并没有严格的顺序要求，所以我选择增加路由灵活、容错能力好的消息中间件RabbitMQ和升级硬件组合方案来解决该问题。

此次项目的顺利开发让我更进一步了解到系统架构设计的重要性，同时积累了更多的经验，同时也暴露出自身在架构设计方面的还存在一些不足，我应当总结本次项目经验，争取在下个项目中做的更好。