论微服务架构及应用

 2021年初,我所在的公司承担了某能源集团化工产业部的化工生产运营综合管控系统,简称运营管控系统。我有幸担任了该项目的系统架构师,主要负责系统的体系架构、架构评估和研发管理工作。
    随着国内外化工行业日新月异的繁荣与发展,化工产业部在数字化、网络化、信息化方面要求不提提高。传统管理方式和技术手段也越来越难以适用瞬息万变的市场情况了。加上原来化工产业部原来建设的信息系统大多部署困难,升级麻烦,扩展性差等原因。从2018年开始,化工产业部陆续投资建设了MES(生产制造管理系统)、设备信息管理系统、MES、能源管理系统、安全运营管控系统。这些系统在无论是业务得切合度,还是系统本身的运行情况都非常良好。但是这些系统是各自运行,相互独立,是一个个所谓的信息孤岛。正是因为这些信息孤岛,使得运营管控系统就应运而生了。
   针对化工业务当前的特点以及集团化工产业部的具体业务情况,经过项目组讨论,大家一致决定采用微服务架构来设计和实现运营管控系统。数据库采用PostgreSQL数据库,操作系统采用华为欧拉系统。大家都知道,微服务是一种架构风格,它的主要特点有服务组件化、独立部署、耦合程度低、高度自治、故障隔离等。所谓的微服务组件化是将复杂的单体应用程序拆分成更小的服务,每个服务都围绕具体的业务功能或者流程来构建从而实现服务组件化。独立部署是每个微服务都可以独立开发、测试、部署。不需要依赖其他服务。这样团队可以并行工作,从而提高开发效率;耦合程度低是服务之间通过轻量级通信机制进行交互,达到降低服务之间的耦合程度,使得系统更容易维护和扩展,从而提高系统的灵活性和可定制性。其中轻量级通信机制有REST api,事件流,消息代理等。高度自治是每个服务可以选择独立的技术栈,包括数据库和部署方式从而提高系统的灵活性和可定制性。故障隔离是每个微服务都是独立的,一个服务发生故障不影响其他服务正常运行,从而实现故障隔离,提高系统可用性。
   在决定采用微服务架构后,第一要务就是按业务需求拆分服务。根据运营管控具体业务需求,系统一共分5大模块,工厂模型、智慧工作台、通用服务、业务活动监测、运营管控。我们把这5个大模块分别部署成了5个独立的服务。但是,通用服务模块实现的功能主要是通过ETL方式在数据库之间抽取、推送数据。可以说不属于微服务。其余的四个服务都是采用通用的前后分离模式,前端vue页面或者报表+后端Springboot服务,底层实现原理其实都是ajax+json方式。这其实就是典型微服务。工厂模型、智慧工作台、业务活动监测、运营管控,为了完全达到独立部署,互不影响,四个模块不仅用四台服务器部署成四个独立的服务,同时也配置了四个独立数据库。但是,为了方便服务之间相互调用,又单独配置一个Nginx代理服务器,统一代理上述四个服务,这样所有的服务就有一个统一的访问入口。另外说明一点,所有服务器都部署在集团机房,相关的安全措施以及服务器监控软件、日志软件都是集团运维团队统一实施部署。
   数据推送模块的功能不仅在各个模块之间的推送数据,也在各个系统之间的推送数据。正因为有了数据推搡功能,各个系统、各个模块,可以说都能拥有整个化工板块的数据,从而使得各个系统融为了一个有机整体。系统之间也真正实现无缝衔接。而业务活动监测主要通过一些关键业务指标的定义,同时收集部分相关数据然后进行分析、展示,另外加上一些特殊算法。化工业务人员不仅能从业务活动监测页面看到相关设备和装置的实时数据,还能通过图标或者其他方式做一定的分析和预测。这个功能模块看简单,做起来还是比较复杂的,我们的团队在这个过程有过许多的反反复复,也有过一定经验教训。不仅学到很多化工方面的专业知识,在软件开发方面也积累些许宝贵经验。还有,工厂模型是管理整个化工板块的基础数据,包括物料、物料分类、装置、组织机构等数据,这些数据如果有变化,通过MQ以消息形式推送到其他各个系统。智慧工作台主要实现了两个功能模块,一个功能是当前用户处理自己所需要处理的待办业务,还有一个功能模块就是当前登录用户查看自己所关注的业务数据变化情况。这两个模块相对都比较简单。
   最后说一下,运营管控是整个系统中最大的功能模块,也是最复杂的一个模块。该模块主要是两大功能,一个功能是各个化工厂通过报表的形式给化工产业部报送数据。另一个功能是数据展示功能,各级领导通过页面的形式查看各类生产、销售、采购、物质等数据图表。报送数据功能来自两个方面,一部分数据是各个化工厂业务人员通过报表手工录入,报表开发用的是FR报表工具。另外一部分数据是通过DCS和PLC等自动化系统采集过来,因为数据上传必须通过广域网,很难做到秒级传输,所以数据采集周期为1分钟。数据展示功能重点在各个化工厂以及化工产业部大屏上,不仅需要数据实时、准确,而且得有各种展现效果。这个模块的开发过程看似复杂,其实过程反而似乎没有曲折,因为我们有了前面经验,遇到问题好像没那么多,而且解决问题速度也相对比较快了。最关键的还是用微服务架构的过程中,我们前面做的功能模块形成组件,在开发后面模块过程中用起来了。
    从整个项目开发历程来看,虽然在业务监测活动模块中,有一些反复,也遇到了需求把握不准确的场景,但是微服务架构的使用弥补了短板,对我们确实有所帮助。在以后开发活动中,微服务架构应该是首选架构,尤其是遇到这种时间紧,任务重的项目。采用微服务架构可以说事半功倍,整个项目开发历时一年又3个月,在2022年3月成功上线,系统运行至今非常稳定,同时赢得了同事、领导、客户的一致好评。该项目在2022还被公司评为优秀项目。作为该项目的架构师、设计师。不仅学到了很多的知识,同时又一次积累到宝贵的经验。

你可能感兴趣的:(架构,微服务,云原生)