记录下2026年5月23日软考论文，前3题分别是关于移动端AI测试、六边形架构、向量数据库，多少有点盲区。而第4题是高并发的性能优化，有点为论文题目兜底的意思，感觉除非前3题里有特别熟悉的，否则大部分人应该是选这题。因为从云化、质量属性等方面切入，多少都能够写写。以下是本人考试论文内容，2个小时时长看着挺长，其实现场码字还是有点紧张。特别是正文部分2500字完全不能超，最后还得删删改改，又要保持逻辑通顺，改完最后只剩下2分多钟。临场发挥算过得去，如果时间更充裕，可以和主题结合得更紧密一些，不过能写完已经不错了，毕竟是高考后第一次写完整的长文了。
题目
在高并发场景下，系统需要在短时间内处理大量用户请求，因此很容易出现响应时间变长，吞吐量下降，请求超时，数据序连接耗尽，cpu和内存占用辛过高等性能问题。
严重时甚至会导致服务阻塞和系统启机，面对高并发场量，单一优化方式往往难以从根本上解决问题，须从缓存设计，异步处理，限流降级，数据库优化，服务拆分以及水平扩容等多个方面进行协同改进
请围绕“高并发系统性能优化方案设计与实践”为论题，依次从以下三仿面边行论述.
1、概要叙达你参与管理和开发的软件项目以及你在基中所承提的主要工作.
2、请你从缓存设计、异步处理，限流降级数据库优化，服务拆分、水平扩容分别说明如何解决高并发系统的性能问题
3、具体阐达你参与管理和开发项目遇到了哪些性能问题，是如何综合采用上述方式进行高并发系统设计与实施的
摘要
2024年3月，我作为架构师参与了某省级运营商“5G无线智能运维工作台”项目的研发与落地。该项目投资约450万元，旨在全面支撑无线网络规、建、维、优全生命周期的智能化管理，主要包含智能化客户优化工单中心、参数集中管控、网外协同总线、极简改造引擎、AI容量中台、网络实时预警等模块。本项目中，我全面负责了系统架构设计与技术选型。本文以该项目为例，重点论述了基于领域驱动设计的微服务拆分和容器化部署、基于事件驱动和柔性事务的最终一致性架构、基于Redis和Clickhouse的数据库缓存设计以及基于APISIX路由和熔断降级。最终，该项目于2024年11月顺利上线，系统运行顺畅，大幅提高了系统性能，获得了省公司与业务部门的一致好评。
正文
某省通信运营商负责全省千万级用户的移动网络规划、建设、维护与优化工作。近年来，为积极响应集团公司关于“自智网络”向L4级别高级自智演进的战略目标，该省运营商拟牵头构建一个海量数据驱动、AI智能决策的全能型业务支撑平台。我公司在通信行业IT与数据中台支撑领域深耕十余年，具备丰富的省级大型系统研发经验，因此于2024年2月成功中标该项目。其建设内容主要包括：智能化客户优化工单中心、百万级参数集中管控中台、网外遗留系统协同总线、极简基站改造决策引擎、容量与AIOPS智能分析中台等核心模块。我在该项目中担任系统架构设计师，全面负责整体架构演进、核心业务模块的技术选型及难点攻关等工作。该项目总投资约450万元，研发团队规模18人。项目自2024年3月启动，历时9个月，于同年11月成功上线验收。上线后大幅改善了原遗留系统的性能，有效提升了无线网络运维效率，获得了省公司及各级分公司的高度评价。
省内原遗留系统是一个单体架构的庞大系统，虽然进行了业务分层，但存在明显的性能瓶颈。如热点保障场景瞬时高并发查询容易造成后台关系型数据库的连接池被耗尽；夜间集中动网操作时，全省数百名网优工程师通过无线工作台集中下发批量脚本，参数管控中台极易发生线程拥塞；一线代维外场上传验收图片时，后台GPU资源不足会导致长时间的等待，用户体验不佳等。
面对以上多种性能问题，我们可以采用异步处理缓解请求的拥塞；通过数据库缓存设计，降低后台数据库压力；通过服务拆分和云化部署，优化硬件利用率，提升系统可用性；通过网关路由和熔断降级提供业务兜底。下面就我在本项目中，采用的一些性能优化设计进行论述。
基于领域驱动设计的微服务拆分和容器化部署
省内原遗留系统采用了单体架构，分为表现层、业务逻辑层和数据层。虽然做了分层设计，但所有模块共享了大部分硬件资源，下一层的失败将导致整个系统失效。为了尽可能降低对运营商用户的影响，无线网络动网操作集中在夜间实施。当全省数百名工程师集中通过无线工作台进行批量参数查询和修改时，系统在短时间内收到大量并发请求，经常出现假死等待的情况。
为了彻底解决遗留系统中因硬件资源短板造成的整个系统失效，我引入了领域驱动设计（DDD）理念，通过事件风暴识别了优化工单协同、参数集中管控、智能验收等独立微服务。同时，我们沿用Java结合Spring Boot构建严谨的业务流转；而对于AI算法等模块，则采用与机器学习更契合的Python开发，充分提升了硬件效率。各微服务通过Docker进行容器化封装并独立部署在各Linux服务器集群上，隔离了硬件资源，通过12台国产算力集群部署到K8s集群，实现业务高峰期的自动横向扩容，而在白天业务低谷时自动回收资源，做到硬件资源的削峰填谷。
基于事件驱动和柔性事务的最终一致性架构
无线工作台经过微服务的拆分后，随着服务数量的激增，服务间形成了蛛网式的复杂调用关系，增加了运维的复杂度。像自动开站这种超长的事务，需要经过综合资源管理查询、工参查询、网管参数查询、指令生成、指令执行和执行结果查询等诸多流程，一旦其中一个环节失败，将导致整个长事务失败，且前台用户在长时间等待后，需要重新发起业务，体验很差。
为此，我采用基于RocketMQ的事件驱动最终一致性架构。当自动开站业务发起后，系统将“开站”这一事件作为半消息发送至RocketMQ，随后提交本地事务并确认消息发布。对于超长事务，我采用Saga柔性事务机制，将整个超长事务拆分步骤，对每一个步骤生成逆向回滚操作，一旦事务失败，已操作的步骤自动回滚，保证了最终数一致性。而在整个事务处理过程中，由于不再需要同步等待，用户可以继续其他操作，极大提高了用户体验。
基于Redis和Clickhouse的数据库缓存设计
遗留系统主要采用了关系型数据库PostgreSQL作为后台数据库，在演唱会和展会等用户高聚集、高并发场景中，时常遭遇连接数被打满的情况，进而导致前台无法刷新数据。
为解决这一性能瓶颈，我主导设计并实施了多级缓存结合列式存储的架构。首先，我们引入了Redis集群作为缓存层，将网元工参数等相对静态的数据“热数据”驻留在内存中。其次，针对优化工单需要用到的海量离线性能数据等，我们利用ClickHouse列式数据库卓越的向量化执行引擎和极高的数据压缩比，将原本在传统数据库中需要数分钟的聚合查询缩短至亚秒级。通过这种多样的数据库缓存模式，使热点场景下对后台数据库的访问负荷下降了80%。
基于APISIX路由网关和熔断降级
系统性能的优化没有银弹，尽管做出了多方面的努力，我们仍然需要为潜在的系统故障和过载做出兜底。我选用了云原生高性能网关Apache APISIX作为全系统的唯一南北向流量入口。它全面接管了外部请求，执行动态路由分发，针对不同业务场景，我们配置了limit-req与limit-count插件进行精细化限流；例如在智能验收业务线中，当后端的AI推理服务因GPU资源短缺导致计算延迟飙升时，APISIX的api-breaker（熔断器）插件会在探测到慢调用比例达到预设阈值后迅速触发熔断机制。此时，网关不再将验收图片上传请求向后透传，而是直接拦截并执行降级逻辑，向工单系统快速返回“系统繁忙，请转人工审核”的状态消息。这一机制成功将故障控制在局部边界内，有效保护了核心业务链路免受下游算法节点性能瓶颈的拖累。
综上所述，在本项目中，我们采用基于领域驱动设计的微服务拆分和容器化部署，解决了主要的硬件性能瓶颈；通过基于事件驱动和柔性事务的最终一致性架构，提升了用户体验；通过基于Redis和Clickhouse的数据库缓存设计，大幅缓解了后台数据库压力；以及通过基于APISIX路由网关和熔断降级，保障了系统在故障和过载情况下的兜底行为。在项目实施过程中，也并非一帆风顺。例如在领域驱动设计过程中，由于无线专家的专业术语和开发人员习惯的CRUD术语无法拉通，导致了一定的沟通障碍。我们通过长期共享工作室和白板便签方法，最终拉通了通用语言。后续我希望继续探索serverless架构，实现更灵活的资源分配，进一步提高硬件效率，缓解性能瓶颈。
