系统架构设计师论文分享-论微服务架构

我的软考历程

摘要

2023年2月，我所在的公司通过了研发纱线MES系统的立项，该系统为国内纱线工厂提供SAAS服务，旨在提高纱线工厂的数字化和智能化水平。我在该项目中担任系统架构设计师一职，负责该项目的架构设计工作。本文结合我在该项目中的实践，详细论述了微服务架构及其应用。微服务架构把系统分为一个个独立的模块，每个模块单独管理、开发、部署和运行，所以它具有技术异构型、容错性、高可用性、模块独立性等特点。本项目采用微服务架构开发，提高了项目的开发和迭代速度，让项目的性能、可用性、可修改性、安全性、可维护性得到了保障。最终在2023年12月，该项目正式上线并对外提供服务，目前已经有563家工厂接入了该系统，系统运行良好，得到了客户的一致赞扬。

项目背景

随着我国从制造业大国向制造业强国的转换以及工厂数字化和智能化的持续推进，我所在的某地某科技公司基于自研的物联网平台相继开发了染整一体化和织布一体化平台，这些平台上线后，得到了工厂的追捧，也为公司带来了丰厚的经济回报。基于此，我司于2023年2月开始研发纱线MES系统，该系统预算730万，建设工期10个月，涵盖纱线工厂从清花、梳棉、并条、精梳、粗纱、细纱到络筒的全流程工序，将为纱线工厂提供全面的生产管理解决方案以及基于数据的智能决策分析能力。该项目为物联网层次架构，整体分为感知层、网络层和应用层。其中网络层为公司已有的物联网平台，这次重点建设内容为感知层和应用层，感知层使用Golang语言开发，作为联网网关部署在工厂侧，负责工厂数据的采集和云端指令的下发。应用层为纱线MES系统主体，采用Java语言开发，使用Spring Cloud微服务架构，数据库使用Mysql，缓存使用Redis，前端框架使用vue.js，日志、监控和链路追踪采用skywalking、prometheus、grafana和ELK，最终通过devops的方式部署在kubernetes集群中。系统上线后，将提供以下：基础管理、数据接入、工单排产、数字孪生、工资计算、智控中心和数据分析等等功能，通过以上功能，可以全面提升纱线工厂的数字化和智能化水平，使其运营水平和生产效率得到质的飞跃。

论述内容

该系统涉及模块众多，如果采用单体架构，在开发效率和部署上会面临问题，单体架构中每一个模块进行改动都要进行整体的测试和部署，这很影响开发和部署的效率，造成服务的不稳定性。而微服务架构相对于单体架构具有以下特点：1、模块独立性，可以独立管理、开发、测试和部署并独立运行。2、技术异构性，由于每个微服务互相不影响，所以每个微服务都可以采用不同的技术实现。3、容错性、可用性，微服务之间不存在紧密耦合，一个微服务出现问题，不影响其他微服务。4、可扩展性，微服务之间是独立的，所以可以独立的扩展，不影响其他微服务，具有良好的扩展性。不过微服务也存在如下问题：1、分布式下的复杂性，由于微服务采用分布式的模式，就存在服务管理，注册，发现、服务依赖等问题。2、微服务的数据一致性，由于每个微服务采用独立的数据库，当有依赖事务时，就需要保证数据的一致性，这在分布式下是比较困难的。3、运维的复杂性，传统的手工部署在微服务模式下难以实施。本文结合我在该项目中的实践，详细论述微服务架构的实施以及相应问题的解决方案。

1、分布式下的复杂性。

为了解决微服务在分布式下的复杂性，我们采用Spring Cloud架构，使用nacos作为服务的配置和注册中心，每一个服务启动时都会把自己的ip和端口相关信息推送到nacos中，这样nacos就维护了全部的微服务实例信息。当一个微服务有请求时，就会通过nacos获取对应的ip和端口信息，然后通过ribbon实现负载均衡，通过open-feign进行远程调用。同时，微服务还面临分布式配置的问题，如果没有全局的配置中心，在发布服务时会因为配置的不一致或者手工的错误而导致失败，有了nacos作为分布式配置中心，免去了手工维护配置的不稳定性，让系统不会因为配置而产生错误，同时nacos可以按环境保存配置，在不同的环境之间做了隔离，避免了因为环境而导致的问题。

2、数据的一致性问题。

微服务采用多实例部署，当一个请求的业务涉及多个微服务时，就会存在不同微服务修改数据的可能，在单体情况下，可以采用一个事务进行处理，但是在微服务下就没法这样做了。为了解决这个问题，我们采用了多种方式：1、批处理。2、seata。3、基于消息队列。第一种方式比较简单，比如纱线的前纺数据，这一部分数据对于业务不那么重要，所以我们每日都会通过批量处理的方式进行校验，如果数据不对再触发边端的重复上报。第二种方式是通过阿里开源的seata，它是一个开源的分布式事务解决方案，通过它，我们使用AT模式可以做到对业务没有侵入而实现分布式事务。当然这种方式对性能有很大影响，在使用时要对重要的事务进行处理，比如在纱线业务中，工单排产是一个复杂过程，这个过程会涉及到不同微服务的数据调整，一旦出现错误，会造成严重的后果，那这种就需要用seata来保证处理过程的分布式事务性。第三种是采用消息队列，比如我们采用RocketMQ消息队列，它提供了一种特性的消息：事务消息，通过它可以实现分布式下的数据一致性。比如在纱线业务中，我们对工资做计算时，就是通过生产的数据进行触发消息执行的。

3、运维的复杂性。

在微服务架构情况下，如果采用手工部署，基本时不可能完成，也会对项目的进度造成重大影响。基于此，我们采用了docker和kubernetes以及cicd技术，当我们的代码在提交后，就会触发cicd的自动编译，自动代码扫码和执行单元测试，当这一步骤完成后，就会进行docker镜像的制作，并把生成的镜像提交到镜像仓库中。最后，我们就可以一键进行镜像的部署，把微服务部署到kubernetes集群中。通过这种方式，我们有效地保障了项目的进度，同时减少了人工导致的错误，保障了项目的质量。

总结

通过采用微服务架构模型，我们提升了开发和迭代速度，保障了项目的性能、可用性、安全性、可修改性等质量指标，确保了项目的按时上线。最终在2023年12月，该项目正式上线并对外提供服务，目前已经有563家工厂接入了我们的系统，系统运行良好，表现优异，得到了客户工厂和公司领导的一致好评。项目虽然获得了成功，但是也遇到过一些问题，在项目初期，由于产品对纱线业务的不熟悉，导致了多次功能的调整和返工，这让开发人员产生了抵触情绪。为了解决这个问题，我提出两个解决方案：1、派产品去工厂一线，熟悉纱线工厂操作流程，与工人交流，掌握纱线业务的难点和痛点，保障需求质量。2、开发人员也要参与需求的整理过程，有问题反馈给产品，同时在做设计时，采用灵活的设计模式，为需求的变更留下可操作的空间。通过这两个方法，最终解决了这个问题。得益于本次项目的实践，我不仅学到了微服务相关的知识，也锻炼了自己的架构和管理能力，我意识到只有不断地学习和实践才能让知识融汇于自己的技术体系之中，才能在未来的工作中游刃有余、勇担大任，为祖国的信息化建设贡献自己的力量。