软考高级“系统架构设计师”论文——论微服务架构及其应用

本文更新于2025-09-06。
原文致谢：https://www.zifangsky.cn/1499.html

©版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。
转载请注明来源：最新“系统架构设计师”论文范文——论微服务架构及其应用 - zifangsky的个人博客

我报考的是2021年下半年软考高级“系统架构设计师”，一次性低分飘过（上午成绩48，下午成绩57，论文成绩47）。没报班没买课，花了4个月时间备考，买了两本考试指定用书：《系统架构设计师教程》和《系统架构设计师2013至2018年试题分析与解答》。
一定要做题。上午的考试“综合知识”（选择题）和下午的第一门考试“案例分析”（简答题），在《系统架构设计师2013至2018年试题分析与解答》中都有试题和分析解答。但下午的第二门考试“论文”在《系统架构设计师2013至2018年试题分析与解答》中只有试题和写作要点，范文只能从网上找。当时，我找了几篇“信息系统项目管理师”的范文，“系统架构设计师”的范文反而不太好找，只找到这一篇。考试前一周，用纸笔把全文抄写一遍。第一，加深印象，主要是熟悉行文结构；第二，计时，看看两个小时写3000字需要什么速度，毕竟好多年没写过字。抄完之后，手都软了。
碰巧，考试时，论文4选1就有一题是：论微服务架构及其应用。真是天时地利人和（我本身也是服务端开发）！
最后，再次感谢原博主分享的范文！
《最新“系统架构设计师”论文范文——论微服务架构及其应用》
摘要

我所在的公司是国内主要的几家征信公司之一，作为一个征信公司应当在当前这种时代背景下承担起防范化解重大风险、促进金融服务实体经济、进一步扩大对外开放、深化金融供给侧结构性改革和推动经济高质量发展等重大战略部署过程中的新任务、新挑战。因此，2018年5月，公司决定在我们目前已有系统构件的基础上建设一站式互联网大数据征信平台，提供实时在线的大数据征信产品服务，重点服务于银行、保险、互联网金融、供应链金融、消费金融等多种商业场景。在该项目中，公司任命我为系统架构师兼研发负责人，负责项目的架构评审、改造设计及实现。最后，在我们公司多个部门同事的良好配合下，该项目已经在2019年4月底完成系统上线，到目前为止已经经过多次小版本迭代更新，得到了公司领导、各部门同事以及客户的一致认可。本文作者结合实际经验，以该项目为例，讨论微服务架构及其应用，包括微服务的基本概念及特点，如何从单体架构迁移到微服务架构，以及在实现微服务架构的过程中遇到的问题及其解决方案等等。
正文

近年来，互联网行业发展迅速，同时伴随着公司组织、业务的不断扩张，需求的快速变化以及用户量的不断增加，公司目前已有的几个采用了单体架构的信用和风控方面的项目已经无法适应业务的高速迭代，各个项目中都存在模块间耦合严重，新需求变更困难等问题。因此，在这种背景下，公司决定在目前内部已有系统构件的基础上建设全新的互联网大数据征信平台，在整合原有业务系统的基础上开发满足用户新需求的一站式解决方案。
我带领研发部门的同事经过一段时间的架构考察和评估，最终决定采用微服务架构建设新系统。2018年5月，该系统正式开工研发，我被任命为系统架构师兼研发负责人，主要负责系统架构设计实现以及把控项目进度、技术难点攻关等方面的工作。在这个项目中，系统主要提供信用报告、信用评分、用户画像、信用风险监控、智能建模分析、社会信用体系建设等主要业务模块，在实际使用时，用户可根据实际情况的需要将上述模块自由组合，限于篇幅，在此我们不再详细介绍各个模块的具体功能。
微服务的目的是充分拆分庞大臃肿的系统，以促进敏捷开发和部署。在这个一站式互联网大数据征信平台项目的管理和开发中，我们按照功能需求将系统划分为用户中心、信用评分报告、信用风险监控、机器学习建模分析、社会信用体系建设5个微服务，同时将项目研发人员划分为5个小组。在项目开发过程中，首先我负责收集来至客户和公司各部门的所有需求，然后召开需求评审会议，跟项目组同事一起评审需求的优先级和工作量，在需求评审结束后将之安排给各个小组研发，各小组组长向我汇报工作同时全权负责他所在小组的研发进度、代码质量等方面的工作。在这个项目中，原则上每个小组负责一个组件的完整生命周期，从开发，到测试，再到运维以及后续迭代升级。最后，各个服务组件通过RESTful HTTP协议和消息路由功能进行服务组装。
传统的单体软件架构在构建部署和扩展伸缩方面有很大的局限性，传统的单体架构一般分为客户端界面、数据库、服务端应用三个部分。系统中任何程序的变更都需要整个应用重新构建和部署新版本。另外传统的单体软件架构在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。而微服务架构恰好可以完美地解决传统单体架构所遇到的种种问题。微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立，单个服务功能的改变只需要重新构建部署相应的服务即可。与单体架构相比，微服务架构有如下的特点：
一，通过服务实现组件化。由于单个微服务实现简单，能够聚焦于一个指定的业务功能或业务需求，每个服务对外提供统一的轻量级REST接口，实现组件化。
二，功能明确，易于理解。微服务能够更好被一个开发人员理解、修改和维护，这样小团队可以更关注自己的工作成果，便于管理。
三，围绕业务功能构件开发团队。如果采用微服务架构，需要围绕业务功能来构件开发团队，这样更符合企业的分工与组织结构，避免出现一个开发团队负责维护多个系统服务的情况。
四，支持多种开发语言与多种平台。不同的微服务能使用不同的语言进行开发，运行在不同的操作系统平台上，服务之间通过标准的REST接口和统一的轻量级JSON数据格式进行交互与协作。
五，基础设施自动化。微服务强调以灵活的方式集成自动部署，通过CI持续集成工具实现基础设施自动化，所以一般微服务都离不开DevOps。
六，故障处理设计。微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
七，演进式迭代。微服务应用更注重快速更新，因此系统的功能会随着时间不断变化和演进。
在微服务架构下，我们选择RESTful HTTP协议进行通讯。每个微服务都统一对外提供REST服务。无论前端调用后端服务还是后端之间的服务调用都统一走REST接口，同时使用JSON数据格式进行交互与协作，这样微服务架构就可以支持各种异构系统服务间的交互。
在技术选型上，由于我们原有构件大多采用SpringMVC架构开发，因此我最终选择基于Spring Cloud服务框架做微服务架构，服务框架的选择也决定了后续的服务注册与发现选型、服务负载均衡选型、以及服务容错选型等等。
服务的注册与发现，服务之间需要创建一种服务发现机制，用于帮助服务之间互相感知彼此的存在。服务启动时会将自身的服务信息注册到注册中心，并订阅自己需要消费的服务。
负载均衡是服务高可用的保证手段，为了保证高可用，每一个微服务都需要部署多个服务实例来提供服务。我们主要支持随机、轮询、最少链接数的策略将来自网络的请求分配给内部中的多个服务器。
服务容错采用快速失败，失效切换的策略。如果连续失败多次则直接熔断，不再发起调用。这样可以避免一个服务异常拖垮所有依赖于他的服务。
在微服务实践中，我们主要遇到三个问题，一运维开销及成本增加，因为每个微服务需独立运行，还可能采用多种语言环境，这将导致资源开销大；二代部分码重复，某些底层功能需要被多个服务所用；第三个问题是难以可视化及全面测试，在动态环境下服务间的交互可能会产生一些无法预料的异常。因此，首先服务划分应尽量合理，不要划分太细太多，其次采用公共模块的方式提供底层服务，再次微服务可通过监控发现生产环境的异常，进而快速回滚，弥补可测性不足的问题。
通过项目实践证明，实施微服务架构收益会大于成本。在拥抱微服务之前，也需要认清它所带来的挑战。需要避免为了“微服务”而“微服务”。对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则，对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。
最后，虽然项目在开发过程遇到了很多问题，但是在我们整个团队的齐心协力之下，问题都得到很好的解决，达到了项目的预期目标，得到了公司领导、各部门同事以及客户的一致好评。我也将在后续的工作实践中不断地学习，提高自身素质和能力，带领技术团队为公司提供更高质量的技术服务，为业务保驾护航。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！