当前位置：首页 > news >正文

19.【.NET 8 实战--孢子记账--从单体到微服务--转向微服务】--单体转微服务--当前项目拆分规划

news 来源：原创 2025/6/20 21:56:16

随着业务规模的不断扩大和系统复杂度的提升，孢子记账系统需要进行微服务架构的转型。本文将详细规划从单体应用向微服务架构迁移的具体方案，包括功能模块分析、服务拆分、技术选型以及实施步骤等内容。通过合理的服务拆分和架构设计，未来我们将构建一个更加灵活、可扩展的系统架构。

一、现有功能分析

1.1 分析方法

为了准确识别系统中的功能模块，我们采用了以下三种分析方法：

代码结构分析：通过分析项目代码组织结构和命名空间
数据库表结构分析：通过分析数据库表之间的关联关系
业务功能梳理：通过分析业务流程和功能依赖关系

1.2 分析过程

首先分析系统的基础架构层，识别出系统管理相关的功能模块
然后分析核心业务层，识别出账务相关的功能模块
最后分析支撑功能层，识别出货币汇率和报表相关的功能模块

1.3 分析结果

系统在表现层采用RESTful API设计风格，通过Controllers层处理所有HTTP请求，并实现了统一的响应格式和基于角色的权限控制机制。在业务层，系统通过Server.Interface定义业务接口，并在Server命名空间下实现具体业务逻辑，采用依赖注入模式实现松耦合。数据访问层使用Entity Framework Core作为ORM框架，通过统一的SporeAccountingDBContext管理数据库操作，支持MySQL数据库。

系统的主要业务功能围绕账务管理展开，包括账本管理、收支记录管理、收支分类管理和预算管理。账本管理支持创建、查询、修改和删除账本；收支记录管理支持记录、查询、修改和删除收支；收支分类管理采用树形结构，支持分类的增删改查和层级控制；预算管理支持设置预算、查看预算使用情况和调整预算。此外，系统还提供货币汇率管理功能，包括货币信息维护、汇率记录和汇率转换。报表管理功能支持报表生成、查询和日志记录，系统配置功能支持用户配置和系统参数配置。

在数据库设计方面，系统采用关系型数据库设计，主要包含用户权限、账务核心、货币汇率、系统配置和报表等五大类数据表。用户权限相关表包括SysUser、SysRole、SysUrl和SysRoleUrl，实现了用户-角色-权限的完整权限管理体系。账务核心表包括AccountBook、IncomeExpenditureRecord、IncomeExpenditureClassification和Budget，构成了系统的核心业务数据。货币汇率相关表包括Currency和ExchangeRateRecord，支持多币种记账和汇率转换。系统配置表Config用于存储用户配置信息，报表相关表Report和ReportLog用于记录报表生成历史。

根据上述分析，系统主要包含以下核心功能模块：

模块名称	功能
系统管理模块	用户管理角色管理权限管理系统配置
账务核心模块	账本管理收支记录收支分类预算管理
货币与汇率模块	货币管理汇率记录
报表模块	报表生成报表日志

1.4 模块依赖分析

核心业务模块之间存在明确的依赖关系：用户服务依赖角色服务，收支记录依赖账本和分类，预算依赖收支分类，报表依赖收支记录。外部依赖包括MySQL数据库、RabbitMQ消息队列和JWT认证服务。系统配置包括数据库连接配置、JWT配置和消息队列配置，这些配置通过appsettings.json文件统一管理。

二、微服务拆分

根据前面的分析，我们将服务拆分为五大模块：身份认证服务、账务核心服务、货币汇率服务、报表服务以及配置服务。以下是这五大服务的具体职责、核心实体以及与其他服务的依赖关系，后续我们将按照这五大模块来重构目前的系统。

服务名称	职责	核心实体	依赖关系
身份认证服务 (Identity Service)	• 用户认证与授权 • 用户信息管理 • 角色权限管理	• SysUser • SysRole • SysUrl • SysRoleUrl	• 被其他所有服务依赖 • 独立的用户数据库
账务核心服务 (Accounting Core Service)	• 账本管理 • 收支记录管理 • 收支分类管理 • 预算管理	• AccountBook • IncomeExpenditureRecord • IncomeExpenditureClassification • Budget	• 依赖身份认证服务 • 依赖货币汇率服务
货币汇率服务 (Currency Service)	• 货币信息管理 • 汇率管理 • 汇率转换计算	• Currency • ExchangeRateRecord	• 依赖身份认证服务 • 需要对接外部汇率API
报表服务 (Report Service)	• 报表生成 • 报表存储 • 报表查询	• Report • ReportLog	• 依赖身份认证服务 • 依赖账务核心服务 • 依赖货币汇率服务
配置服务 (Configuration Service)	• 系统配置管理 • 配置项统一维护	• Config • ConfigTypeEnum	• 依赖身份认证服务 • 被其他服务依赖

三、使用技术

在进行微服务拆分时,我们需要选择合适的技术栈来支撑整个系统的运行。以下是针对服务通信、数据存储和部署等方面的技术选型。

3.1 服务间通信

在服务间通信方面，我们将采用RESTful API作为主要的通信方式，通过HTTP/HTTPS协议实现服务之间的数据交换。RESTful API具有良好的可读性和自描述性，能够支持多种数据格式如JSON、XML等，便于不同服务之间的集成。同时，我们将在服务内部实现统一的API版本控制机制，确保API的向后兼容性。

对于需要异步处理的场景，我们将引入RabbitMQ消息队列系统，通过发布-订阅模式处理服务间的异步通信需求。RabbitMQ具有高可靠性和灵活的消息路由能力，可以有效解耦服务间的依赖关系，提高系统的可扩展性。

在整个微服务架构中，我们将实现基于Ocelot的API网关，统一管理所有服务的入口。API网关将负责请求路由、负载均衡、认证授权、限流熔断等功能，同时提供API聚合能力，减少客户端与后端服务的直接通信次数。此外，我们还将在API网关层面实现统一的日志记录、监控指标收集和调用链路追踪，为系统运维和问题排查提供支持。通过这种方式，我们可以构建一个稳定、高效、可扩展的服务间通信体系。

3.2 数据库策略

在数据库策略方面，我们将采用数据库分离的方案，为每个微服务配置独立的数据库实例。这种方式可以确保服务之间的数据隔离，避免数据耦合，同时也能让各个服务根据自身的数据访问特点选择最适合的数据库类型。

对于身份认证服务，由于需要处理用户信息、角色权限等结构化数据，我们选择使用MySQL等关系型数据库，这类数据库在处理事务性操作和复杂查询方面表现出色。

报表服务则考虑使用MongoDB等文档数据库，因为报表数据通常包含大量非结构化或半结构化信息，文档数据库在处理这类数据时具有更好的灵活性和查询性能。

对于配置服务，我们计划使用Redis等键值存储数据库，这类数据库具有极快的读写速度和简单的数据结构，非常适合存储系统配置信息。

账务核心服务和货币汇率服务仍然使用关系型数据库，因为这些服务需要处理大量的事务性操作和复杂的数据关系。

通过选择合适的数据库类型，我们可以充分发挥每个服务的性能优势，同时也为未来的扩展提供更大的灵活性。此外，我们还将实施完善的数据备份和恢复策略，确保数据的安全性和可靠性。

3.3 部署建议

在部署方面，我们将采用基于Docker的容器化部署方案，通过容器技术实现服务的标准化封装和快速部署。每个微服务都会被打包成独立的Docker镜像，包含运行时环境和应用程序代码，确保了环境的一致性和可移植性。我们将使用Docker Compose来编排多个容器的运行，实现服务之间的联动部署。

同时，为了更好地管理服务实例，我们将引入Nacos作为服务注册与发现中心，所有微服务在启动时都会向Nacos注册自己的服务信息，包括服务名称、IP地址、端口等，其他服务可以通过Nacos发现和访问目标服务。

在配置管理方面，我们选择使用Nacos配置中心，实现配置的统一管理和动态更新。Nacos支持配置的版本管理、灰度发布和权限控制，能够有效降低配置管理的复杂度。

为了实现统一的日志管理，我们将部署ELK（Elasticsearch、Logstash、Kibana）日志收集系统。所有微服务的日志都会被收集到Elasticsearch中集中存储，通过Kibana提供的可视化界面，运维人员可以方便地查看和分析系统日志，快速定位问题。

这套完整的部署方案将为整个微服务架构提供稳定可靠的运行环境，同时也为后续的扩展和维护提供了良好的基础支持。

四、拆分步骤建议

在进行微服务拆分时,我们需要遵循一定的顺序和策略,以确保整个拆分过程的平稳进行。首先,我们将从身份认证服务开始拆分,因为这是整个系统的基础设施。身份认证服务负责用户认证、授权以及用户信息管理,其他所有服务都需要依赖它来实现用户身份验证。在这个阶段,我们需要将现有的用户管理相关代码迁移到新的服务中,同时确保JWT token的生成和验证机制能够正常工作。

第二步是拆分配置服务。配置服务作为系统的中枢神经,为其他所有服务提供配置管理支持。我们需要将分散在各个模块中的配置项统一迁移到配置服务中,实现配置的集中管理和动态更新。这包括数据库连接字符串、第三方服务配置、系统参数等各类配置信息。同时,我们还需要实现配置的版本控制和环境隔离,确保不同环境下的配置能够正确加载。

第三步将进行货币汇率服务的拆分。这是一个相对独立的功能模块,主要负责货币信息管理和汇率转换计算。由于该服务的功能相对独立,且与其他业务模块的耦合度较低,因此适合在这个阶段进行拆分。我们需要设计合理的汇率数据更新机制,并确保汇率转换的准确性。同时,还需要考虑如何优化汇率数据的缓存策略,以提高系统性能。

第四步是拆分账务核心服务,这是整个系统最核心的业务模块。该服务包含账本管理、收支记录管理、收支分类管理以及预算管理等核心功能。在拆分过程中,我们需要特别注意数据一致性的问题,确保在服务拆分过程中不会影响用户的正常使用。同时,我们还需要设计合理的数据迁移方案,并进行充分的测试验证。

最后一步是拆分报表服务。报表服务依赖于账务核心服务和货币汇率服务的数据,因此放在最后进行拆分是最合适的。在这个阶段,我们需要重点关注数据聚合的性能优化,因为报表服务需要处理大量的数据统计和分析工作。同时,我们还需要设计合理的报表缓存机制,避免频繁进行大量的数据计算,提高系统的响应速度。在实现过程中,我们可以考虑采用异步处理的方式,将耗时的报表生成任务放到后台进行处理。

五、非业务功能

在微服务架构转型过程中，数据一致性问题是首要需要关注的风险点。由于系统被拆分成多个独立的服务，每个服务都维护着自己的数据库，这就可能导致数据同步不及时或数据不一致的情况。例如，在账务核心服务中进行收支记录的同时，可能需要同步更新报表服务中的统计数据，如果这个过程中出现网络故障或服务宕机，就可能造成数据不一致。为了解决这个问题，我们需要实现可靠的数据同步机制，采用最终一致性策略，并建立完善的数据校验和修复机制。

服务间通信延迟是另一个重要的风险因素。在微服务架构中，原本系统内部的方法调用变成了跨网络的服务调用，这不可避免地会增加系统的响应时间。特别是在某些业务流程需要调用多个服务时，延迟会进一步累积。例如，生成一份完整的财务报表可能需要依次调用账务核心服务、货币汇率服务等多个服务，如果不做优化，可能会导致用户体验下降。我们需要通过合理的服务调用设计、数据缓存策略和异步处理机制来降低通信延迟带来的影响。

分布式事务处理是微服务架构中最具挑战性的问题之一。在单体应用中，我们可以依赖数据库的事务机制来保证数据的一致性，但在微服务架构中，由于涉及多个独立的数据库，传统的ACID事务已经无法满足需求。例如，当用户进行一笔跨币种的收支记录时，需要同时在账务核心服务中记录收支信息，并在货币汇率服务中记录汇率使用记录，这就形成了一个跨服务的事务场景。我们需要采用补偿事务（Saga）模式或最终一致性等分布式事务解决方案来处理这类问题。

随着服务数量的增加，服务之间的依赖关系会变得越来越复杂。每个服务都可能依赖多个其他服务，形成复杂的依赖网络。这种复杂的依赖关系不仅增加了系统的维护难度，还可能导致服务调用链路过长，影响系统性能。例如，报表服务依赖于账务核心服务和货币汇率服务，如果这些被依赖的服务又依赖其他服务，就可能形成较深的调用链。我们需要通过合理的服务设计和依赖管理来控制服务间的依赖复杂度。

运维复杂度的提升是微服务架构转型过程中不可避免的挑战。相比单体应用，微服务架构需要管理更多的服务实例、数据库实例和网络连接。这不仅增加了部署和维护的工作量，还提高了问题排查的难度。例如，当系统出现异常时，需要分析多个服务的日志才能定位问题根源；服务的更新和升级也需要考虑多个服务之间的兼容性。我们需要建立完善的监控告警系统、自动化部署流程和服务治理机制来应对这些挑战。

我们需要实现一个统一的监控系统，用于全面监控微服务架构的运行状态。这个监控系统将集成Prometheus和Grafana，实时收集各个服务的性能指标、资源使用情况和业务指标。通过Prometheus，我们可以收集服务的CPU使用率、内存占用、请求响应时间、错误率等关键指标；而Grafana则提供直观的可视化界面，帮助运维人员快速发现和定位问题。同时，我们还将实现自定义的业务监控指标，如数据提交成功率、用户活跃度等，为业务决策提供数据支持。监控系统还需要配置合理的告警规则，当发现异常情况时能够及时通知相关人员。

为了提高系统的可用性和稳定性，我们将建立完善的服务降级和熔断机制。当检测到某个服务出现故障或响应时间异常时，自动触发服务降级，返回默认值或缓存数据，避免故障扩散。例如，当货币汇率服务无法访问时，系统可以使用缓存的汇率数据继续提供服务。同时，我们还需要实现优雅的服务降级策略，在非核心功能出现问题时，确保核心业务流程不受影响。此外，还要建立完善的熔断恢复机制，当服务恢复正常后能够自动恢复正常调用。

然后，我们将制定详细的API文档和版本控制策略。使用Swagger或OpenAPI规范编写API文档，详细描述每个接口的请求参数、响应格式、错误码等信息。在版本控制方面，我们将采用语义化版本号（Semantic Versioning）规范，明确定义API的主版本、次版本和修订版本。对于不兼容的API变更，必须升级主版本号；对于向后兼容的功能新增，升级次版本号；对于bug修复，升级修订版本号。同时，我们还需要维护API的变更日志，记录每个版本的变更内容，并制定合理的API废弃策略。

同时，建立完整的微服务测试策略至关重要。我们将实施多层次的测试方案，包括单元测试、集成测试、契约测试和端到端测试。单元测试确保各个服务的核心逻辑正确性；集成测试验证服务间的交互是否符合预期；契约测试确保服务间的接口协议一致性；端到端测试验证整个业务流程的正确性。我们将使用xUnit作为单元测试框架，WireMock模拟外部服务依赖，Pact进行契约测试，Selenium执行端到端测试。同时，我们还需要在CI/CD流程中集成自动化测试，确保每次代码变更都经过完整的测试验证。

最后，我们需要规划合理的数据备份和恢复方案，确保系统数据的安全性和可靠性。针对不同类型的数据库，采用不同的备份策略：关系型数据库采用全量备份加增量备份的方式，每天进行一次全量备份，每小时进行增量备份；MongoDB采用副本集机制，确保数据的多副本存储；Redis采用主从复制和AOF持久化机制。所有备份数据都需要进行加密存储，并定期转移到异地备份系统。

六、总结

我们制定了从身份认证服务开始，依次拆分配置服务、货币汇率服务、账务核心服务到报表服务的渐进式迁移策略。同时，我们也充分考虑了数据一致性、服务通信延迟、分布式事务等技术挑战，并通过监控系统、服务降级机制、API版本控制等手段来保障系统的可用性和可维护性。这套完整的规划方案将指导我们有序地完成微服务架构转型，构建一个更具扩展性和弹性的系统。