【系统架构设计师】论文：论面向服务的架构设计及其应用

论文：论面向服务的架构设计及其应用

论文一

摘要

2021年1月，我所在的公司承担了某地市交通局的交通信息服务平台的建设工作。该平台的建设目标是汇聚多种交通信息系统的数据，既要满足公众出行者对交通信息多样化、个性化的需求，又要满足交通管理部门对交通运行状况掌控和管理的需求。

我在该项目中承担系统架构师的职务，主要负责设计平台系统架构。本文以交通信息服务平台的设计为例，首先简要说明了SOA技术框架的概念、包含的服务类型、主要技术和实现方式，然后详细阐述了如何基于SOA理念设计分层的交通信息服务平台架构，最后解释了如何用XML技术解决异源交通数据格式的问题。目前，平台已经稳定运行一年多，实践证明，这种架构设计提高了系统的共享性，达到服务重用、服务共享的目标，使不同厂商、不同平台和不同数据接口的交通信息能够有机灵活整合，实现信息的共享和交互。

正文

随着社会经济的迅猛发展，城市化水平的不断提高，行车难问题变得日趋严重。公众对交通信息的需求日益趋于多样化和个性化，不同的公众因为时间、所在位置、应用交通方式和心理习惯等不同，所需的服务内容和方式也有所不同；交通管理部门掌握的交通数据越来越多，如何有效利用这些数据为交通决策提供指导，提高交通运行的效率与安全也越来越受到重视。在这样的背景下，各种各样的交通信息平台如雨后春笋般兴起，建设成果颇为丰富，涵盖交通数据采集、传输、处理和展示的各个环节，涉及的交通数据包括道路监控视频、交通控制信号、车流传感器、车辆GPS数据、公交地铁运营数据、道路技术设施数据等，这些交通信息平台为公众出行服务以及交通精细化管理提供了数据基础。然而，目前已有的系统相互独立，形成一座座“信息孤岛”，不但无法实现数据的共享和业务整合，还造成了重复建设、资金浪费的问题。SOA架构凭借其高解耦性、粗粒度、位置和传输协议透明等优点，有助于不同系统间数据和业务松耦合集成，为实现交通信息共享提供准确、及时、全面的技术支持。

本文结合实际项目经历，首先简要说明了SOA技术框架的概念、包含的服务类型、主要技术和实现方式，然后详细阐述了如何基于SOA理念设计分层的交通信息服务平台架构，最后解释了如何用XML技术解决异源交通数据格式的问题。SOA架构是一种组件模型，SOA的服务类型分为6类，分别为：连接服务、业务服务、交互服务、流程服务、信息服务和协作服务。其中，连接服务实现服务的接入，服务间的通信和交互，还提供安全性、可靠性、高性能的服务能力保障；业务服务为新建服务提供特定运行支持环境；交互服务实现人与服务之间的交互功能；流程服务是业务流程的运行环境，提供流程驱动、服务调用、事务管理等功能，支持按特定的顺序和特定的规则调用一组服务；信息服务指为其它服务提供数据访问及资源访问；协作服务包括通信代理和web服务代理，既可以实现组织之间的交互通信，也能实现组织内部的交互通信。

SOA的主要技术包括web service和ESB。Web Service由服务提供者、服务请求者、服务注册中心构成，支持服务发布、查找和绑定，基于XML标准，由web服务描述语言WSDL（用于描述web服务的接口和操作功能）、简单对象访问协议SOAP（为建立web服务和服务请求之间的通信提供支持）、通用描述发现和集成UDDI（用于web服务注册和服务查找）组成；企业服务总线ESB是传统中间件技术与XML、web服务等技术结合的产物, 主要支持异构系统集成；ESB基于内容的路由和过滤，具备复杂数据的传输能力，并可以提供一系列标准接口。通过对遗留子系统的调研,以及对用户需求的准确把握,我遵循SOA架构思想设计了交通信息服务平台总体架构。架构分为7个层次, 分别为系统层、组件层、服务层、表示层、服务总线层和辅助管理层。

一、系统层
系统层包含系统中已经存在的各种遗留系统及数据库, 包括各交通信息采集系统、交通信息处理系统、交通信息发布系统、交通数据库管理系统等. 由于这些系统使用不同的技术实现, 包含不同的接口和定义, 因此我使用JDBC和web service对这些应用系统进行包装, 使他们具有统一的接口, 便于其它服务调用。包含各种遗留系统和原始数据, 包括交警数据、交通数据和泛交通数据。

二、组件层
组件层主要把底层现有交通系统的功能封装成组件, 可采用不同的技术, 发布成web service供服务层调用, 并通过WSDL描述这些Web Service的位置以及其提供的操作. 包括各交通信息采集系统组件、处理系统组件、发布系统组件、数据库管理系统组件。在这一层可采用J2EE或者COM框架, 使用hibernate透明支持系统层的多种数据库. 最后统一包装成Web Service, 用WSDL对外描述.

三、服务层
、服务层是设计中最关键的一层. 在服务层中, 通过具体系统分析, 发现与具体交通业务对齐的服务, 定义交通业务对象、输入、输出、约束条件等, 把交通组件包装成我们所需要的不同的功能服务, 包括数据采集服务、数据发布服务、数据获取服务、数据存储服务、数据权限验证服务、消息服务、监控服务。如车辆GPS处理服务, 包括删除研究区域外数据、变换数据时间和经纬度格式、删除重复和异常数据、对数据按车辆进行分组排序、生成标准线矢量数据等一系列的处理。

四、流程层
流程层的任务是合成和编排服务层中公开的交通服务, 将它们绑定成一个流程, 使之可以作为单独的应用程序而共同作用.这些应用程序支持特殊的用例和业务过程.包括路况信息融合流程/ 车辆位置处理流程/ 出行时间预测流程/ 事故预测查询流程。如路况信息融合需要用到交警视频监控、雷达、车辆GPS等多源数据, 通过合成和编排服务层中相应的服务, 绑定成流程, 通过流程的调用可生成路况信息。

五、表示层
表示层提供了从交通服务消费者到提供者的端到端的解决方案, 在服务接口设计上我采用了基于MVC的SpringMVC框架. MVC各模块可简单介绍…还采用了thymeleaf模板引擎、Canvas等前端技术. 表示层对外发布交通信息的方式主要有交通信息网站、移动终端app、路侧情报板等。

六、服务总线层
在基于 SOA 的集成服务平台架构设计中，采用了企业服务总线作为各应用系统间的信息交换工具，将过去点对点的接口关系变成点对总线的关系，使企业各个系统松耦合。ESB通过基于内容的路由和过滤, 支持复杂数据的处理, 提供了一系列标准的接口, 使得交通遗留系统、交通数据库应用、J2EE和 .NET、交通web service都能够与ESB进行交互操作, 无缝地集成多种交通IT资产, 连接系统提供的各种服务, 使得交通信息服务平台内部可以容易地进行异步或者同步数据交换; 另外, 企业总线层对外提供了交通服务注册管理和服务查询的功能务. 接口服务的提供者将接口信息和服进行注册和发布；接口服务的使用者查询到自身需使用的服务后，提交使用申请，在得到授权后，可以绑定服务接口并进行调用。

通过制定企业服务总线的集成标准，统一了服务的开发规范、使用规范和运维规范，可以有效降低信息系统间的集成改造难度，提升服务接口的可重用性，增强跨系统信息交互的监测管理能力，便于信息系统灵活重构以适应业务的不断变化发展。

七、辅助管理层
这一层为平台提供了监视、管理和维持诸如安全、性能、可用性等QoS功能. 其中, 安全模块采用身份认证、权限控制、SSL传输、消息加密等手段。如身份认证, 为访问应用系统提供统一的单点登录功能，只需登录 1 次，即通过 1 个系统的安全验证后，再访问其他系统时，不需要重新登录验证。

总结

在架构设计过程中, 遇到的主要问题是异构交通数据库之间的信息交换问题. 目前交通信息存在于异构的系统当中，不同的数据库技术和网络通讯技术、硬件环境等都是阻碍交通信息融合的因素。而 SOA 中的 XML 技术是良好的实现数据拓展与跨平台技术工具，因此我利用这项技术为交通信息提供统一的文档及数据格式, 通过XML与数据库之间的映射, 使每个交通子系统都将其内部的数据格式转换成行业标准的基于XML的数据格式, 实现交通子系统间的信息交换。

在架构决策阶段, 我所设计的架构得到了各部门的认可和采纳, 平台上线后, 持续稳定运行, 尽管经历了交通业务逻辑变更、新增业务系统、新增数据库、新增用户视图等复杂运维状况, 但由于设计之初就采用了基于SOA架构的思想, 因此能够较轻松应对, 在降低维护难度和成本、方便扩展业务功能、提供系统安全性、稳定性等方面均表现出色。

论文二

摘要

2017年5月，我参加了公司“数据中心管理系统”项目的开发，并担任系统架构师职务，负责系统的架构设计。该系统旨在将公司分散在全国各地的数据中心内的设备状态与信息通过一系列传输协议发送到服务端，服务端进行分析和处理后反馈给设备操作指令或给管理人员发送通知信息，最终实现终端监控并管理所有设备。

本文以数据中心管理系统为例，论述了软件架构风格在项目中的选择与应用。整个系统选择数据抽象和面向对象、管道/过滤器、基于规则的系统和进程通信四种架构风格组合应用完成项目，有效的实现了终端统一管理所有数据中心，同时证明了良好的架构风格选择和应用使系统的性能、可用性等指标都达到了预期目标。该项目于2018年11月完成验收后正式上线，交付至今运行稳定，得到了公司的嘉奖和用户的一致好评。

正文

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和升级硬件组合方案来解决该问题。

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