系统架构设计师【论文-2016年 试题4】: 论微服务架构及其应用(包括写作要点和经典范文)

论微服务架构及其应用(2016年 试题4)

近年来,随着互联网行业的迅猛发展,公司或组织业务的不断扩张,需求的快速变化以及用户量的不断增加,传统的单块(Monolithic)软件架构面临着越来越多的挑战,已逐渐无法适应互联网时代对软件的要求。在这一背景下,微服务架构模式(Microservice Architecture Pattern)逐渐流行,它强调将单一业务功能开发成微服务的形式,每个微服 务运行在一个进程中;采用 HTTP 等通用协议和轻量级 API 实现微服务之间的协作与通信。 这些微服务可以使用不同的开发语言以及不同数据存储技术,能够通过自动化部署工具独立 发布,并保持最低限制的集中式管理。

【问题 1】

请围绕"论微服务架构及其应用"论题,依次从以下三个方面进行论述。

  • 1.概要叙述你参与管理和开发的、采用微服务架构的软件开发项目及在其中所担任的主要工作。
  • 2.与单块架构相比较,微服务架构有哪些特点?请列举至少 4 个特点并进行说明。
  • 3.结合你参与管理和开发的软件开发项目,描述该软件的架构,说明该架构是如何采用微服务架构模式的,并说明在采用微服务架构后,在软件开发过程中遇到的实际问题和解决方案。

写作要点

一、叙述你参与管理和开发的、釆用微服务架构的软件开发项目,并明确指出在其中承担的主要任务和开展的主要工作。

二、与单块架构相比,微服务架构具有如下特点:

(1)通过服务实现组件化。单个微服务实现简单,能够聚焦一个指定的业务功能或业务需求。

(2)功能明确,易于理解。微服务能够被一个开发人员理解、修改和维护,这样小团队能够更关注自己的工作成果,并降低沟通成本。

(3)围绕业务功能构建开发团队。采用微服务架构,可以围绕业务功能构建开发团队,这样更符合企业的分工与组织结构,便于管理。

(4)支持多种开发语言与多种平台。不同的微服务能使用不同的语言开发,运行在不同的操作系统平台上,通过标准的协议和数据格式进行交互与协作。

(5)离散化数据管理。在微服务架构中,无法创建或维护统一的数据模型或结构,全局数据模型将在不同的系统之间有所区别,需要进行数据模型的离散化管理。

(6)基础设施自动化。微服务强调以灵活的方式集成自动部署,通过持续身集成工具实现基础设施自动化。

三、考生需结合自身参与软件开发项目的实际状况,描述该软件的架构,并明确说明软件架构为什么属于微服务架构,具有微服务架构的哪些特征。并结合项目开发实际,说明采用微服务架构模式后对软件开发过程的影响以及遇到的问题,包括服务的定义与划分、服务之间的协作关系、服务部署、服务管理等。

经典范文

摘要

2020年6月,我单位联合xxx、xxx有限公司开发了省xxx综合应用管理平台,作为公司核心技术骨干,我担任了系统架构师的职务,主要负责xxx应用系统架构体系设计及核心组件的开发工作。该系统按照省机关业务类型划分,依次包含基础功能支撑板块、平台资源管理板块、煤炭能源板块、油气板块、新能源能源板块、电力板块、安全监管板块、经济运行板块、智能数据分析业务以及数据可视化板块,业务范围依次涵盖省煤炭、电力、油气、新能源等能源领域。

本文首先介绍构建xxxx应用系统的项目背景,然后分析了微服务技术架构对于该项目的必要性,并以能源云应用系统作为例,结合微服务架构的特性与实际情况,分别讨论了微服务技术架构的应用情况。实践证明,在大型的应用系统构建过程中,使用微服务技术架构,能够实现各应用分区自治、庞大业务的有效管理及业务功能灵活拓展的优势。

正文

xxx综合应用管理平台,是机关响应国家"十四五"规划所采取的数字信息化措施的开创性项目,旨在深化运用国家以及省市政务信息资源,加强政务信息共享,实现数据编目、数据整合、能源应用服务,规范政务信息资源社会化增值开发利用工作,合理规划政务信息的采集(煤炭、油气、新能源、电力等领域),加强政务信息资源管理。项目的总体目标为:理清能源数据家底,形成能源数据资源目录;实现省能源数据的统一综合管控;基于能源大数据,支撑能源全产业的决策与分析;通过省级数据共享与开放平台向兄弟单位共享能源数据、向社会企业与公众开放脱敏数据。

在项目早期,我们组织了相关承建企业及核心用户,一起进行了项目需求的评审,拟在确定项目的研发计划、细化项目需求,从而进一步确定采取的系统软件架构。项目整体涉及了能源领域的众多业务,体系繁杂且比较庞大,部分业务有着相似的数据支撑组件而部分业务之间又不存在过多的信息交互,基于此,我提出了项目整体采取微服务架构体系构建的方案,并陈述了按照业务板块划分、基础业务拆分方式规划微服务的必要性。在专家评审过程中,通过以往采用微服务架构体系规划项目的经验,最终确定了该系统架构设计方案。

微服务架构体系作为目前IT领域主流的技术,有服务化、强韧性、可观测性和自动化四类设计原则。通过服务化的设计原则,应用被分解为多个服务,可分别选择不同的技术,单个服务模块很容易开发、理解和维护,无需协调其他服务对本服务的影响;通过强韧性的设计原则,微服务可以分布式云化部署,负载均衡管理请求的分发,避免单机失败对整体服务的影响,以及弹性调整资源容量;通过可观测性的设计原则,能够对系统进行健康检查、指标监控、日志管理和链路追踪,提高系统运维、管理和排错能力;通过自动化的设计原则,可实现系统的自动化部署、自动化扩展伸缩、自动化运维、持续交付和集成,有效减少人工操作的工作量。

系统开发过程中,主要采取SpringCloud Alibaba技术架构作为微服务架构的实现方案,系统采取jenkins+docker一体化部署方式实现微服务的部署,前端采用Vue 3.0开发架构,通过nginx实现HTTP请求的动态负载及业务服务的调用层次抽象管理。采用该体系具备众多优势,下面就其特点、开发过程及系统上线后的实际情况进行结合,从而说明本项目采取此方案的好处、遇到的问题及其解决方案。

一、以微服务独立部署,实现各应用的独自管理,却又可以简便的进行交互。

每个服务都是一个独立的项目,可以独立部署,不依赖于其他服务,耦合性低。在系统构建过程中,我结合项目整体需求将应用系统拆分为了众多微服务,按照业务领域、使用用户类型对象进行划分,包含以提供基础数据支撑的平台服务,主要提供用户管理、能源企业管理、企业部门管理及业务数据字典管理等服务;以提供能源领域服务的四大板块服务,包括煤炭、油气、新能源、电力;以提供综合数据应用管理的上层众多汇总型服务。按照这种方式划分,由三个承建企业依次划分职责,同步开发,大大的提高了项目整体完成的效率。若服务之间需要进行通信,只需基于微服务体系的消息交互标准,以Rest标准化接口通过FeignAPI组件实现远程服务调用,通过nacos构建的统一网关,实现方便快捷的交互。

二、服务的快速启动

合理拆分之后服务由于依赖的库及代码量的减少,能够极大的提高服务的启动速度。虽然合理拆分能够提高系统启动速度,但也增加了系统服务的数量。基于此,我通过采取构建统一的打包平台方案,选取了jenkins+docker镜像结合的解决方案,通过docker将每一个微服务打包为至少一个能独立运行的容器,并通过docker-compose描述这些镜像服务的关系,使用jenkins进行脚本的统一集成,所有服务均以可视化方式展现在jenkins平台,很好的解决了服务数量增多之后的管理问题。

三、职责专一,由专门的承建企业负责专门的工作职能

本项目涉及领域众多、周期长,服务的拆分有利于团队之间的分工。在项目开发计划中,我们将服务划分过后,由不同的企业负责不同的服务,例如我司承建四大能源领域板块的构建等, 在项目开发过程中,除了特殊的业务流程需要服务之间进行信息交互外,大部分情况下均无需在意其他团队的开发进度。

四、服务可以动态按需扩容

当某个服务的访问量较大时,我们只需要简单的增加服务的申请资源或者增加服务实例数量,即可0成本的实现服务扩容。在应用部署的早期,我们将所有的服务实例均部署为3个,通过nginx实现一级均衡的同时,也采取了微服务的Ribbon负载体系。例如对于煤炭服务的访问,可动态负载到该3个不同的煤炭服务实例,该3个部署实例位于不同的服务器上,动态负载的同时也保障了服务不会出现单点故障问题。但随着系统用户(各省市机关、各企业用户)的加入及业务数据日益累计,整个系统出现了一定的性能问题。经过排查分析,发现煤炭企业用户会在每天下午2点左右集中上报生产数据,导致同一时刻大量的报表填报请求,导致出现了性能瓶颈,需要进行扩容,通过修改jenkins配置文件,增加打包镜像数量将原有的3个报表服务实例扩容一倍解决了问题。

五、服务的复用

每个服务都提供 REST API,所有的基础服务都按照尽可能高的内聚度进行抽取。类似于组件开发方法,可将一些底层的服务进行归纳总结,方便应用到以后的项目中,提高企业的生产效率。在本项目中,众多基础服务大部分均复用可以往团队开发的组件。譬如报表动态生成服务,该服务是以往能源产业几乎一致的需求服务,可通过该服务动态配置填报报表对象、填报周期、时间截止等。

经过我和团队的不懈努力,历时一年,项目终于于 XXX X年 XX 月通过顺利通过了验收,并得到了一致好评,运行至今,用户反馈良好,通过此类较大应用的开发使得公司的应用规划能力得以提升。但是,在实施过程中,也暴露了一些具体问题,例如微服务之间接口交互时,由于业务复杂,简单的消息调用无法满足繁忙场景,当交互频率增大到一个数量级时需要建立具有动态优先级调整机制的处理队列等等,这些问题通过引入消息队列组件Kafka得以妥善解决,没有影响到项目的运行情况。也在项目的实施过程中,发现了自己的一些短板,例如在安全性处理方面,还需要从服务部署层面、三方安全软件集成方面提升,由于自己从事的几乎都是政府职能项目,安全性是尤为需要考虑的质量属性,今后也会在这方面深入研究,力求使自己的架构实施能力更加全面、稳固,为国家政府信息化建设规划贡献自己的一份力。

相关推荐
想进大厂的小王2 小时前
项目架构介绍以及Spring cloud、redis、mq 等组件的基本认识
redis·分布式·后端·spring cloud·微服务·架构
九卷技术录2 小时前
(微服务)服务治理:几种开源限流算法库/应用软件介绍和使用
微服务·服务治理·限流算法
阿伟*rui3 小时前
认识微服务,微服务的拆分,服务治理(nacos注册中心,远程调用)
微服务·架构·firefox
ZHOU西口4 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
deephub6 小时前
Tokenformer:基于参数标记化的高效可扩展Transformer架构
人工智能·python·深度学习·架构·transformer
想进大厂的小王6 小时前
Spring-cloud 微服务 服务注册_服务发现-Eureka
微服务·eureka·服务发现
架构师那点事儿7 小时前
golang 用unsafe 无所畏惧,但使用不得到会panic
架构·go·掘金技术征文
W Y9 小时前
【架构-37】Spark和Flink
架构·flink·spark
Gemini199510 小时前
分布式和微服务的区别
分布式·微服务·架构
ftswsfb16 小时前
【系统架构设计师(第2版)】七、系统架构设计基础知识
系统架构