【系统架构师合格论文】论微服务架构及其应用

摘要

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

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

正文

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

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

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

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

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

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

2、服务的快速启动

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

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

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

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

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

5、服务的复用

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

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