.NET 6+Docker Compose微服务架构设计与实现技术咨询

DevOps 小满

2026-8-20

微服务架构落地咨询与解答

架构背景说明

Dematerialized UI 对应 dematerialized API；dematerialized API 通过 SSO Library 验证用户并生成令牌
Flight API 负责I/O校验，并通过 Validate Request 微服务验证请求
Flight API 调用 Booking API 获取基于UserId的预订信息
Flight API 调用 Print Booking API，后者通过 Generate Message Microservice 生成消息
Print Booking API 需调用 Data Access API 获取数据后，再调用 Generate PDF Microservices
Data Access API 负责数据库交互

FlightBookingsMicroserice.V1（解决方案）

ApiGatways 文件夹：包含 DMZ.API/DMZ.API.csproj
BuildingBlocks 文件夹：包含 EventBus/EventBus.csproj、EventBus/EventBusRabbitMQ
Services 文件夹：包含 SSO、Flight、ValidationRequest、Booking、PrintBooking、DataAccess、GeneratePDF、GenerateMessage 等服务，每个服务含API项目及单元测试（部分已实现）
UI 文件夹：包含UI项目
Docker-compose 配置文件

Ocelot是API网关工具，核心作用是统一入口、路由转发、流量管控等。建议只在DMZ.API（作为API网关）中使用Ocelot，Flight API和Print Booking API作为业务微服务，不需要集成Ocelot：

整体结构符合微服务模式，同时可以做一些优化：

优点：
- 拆分独立的BuildingBlocks（事件总线等基础组件），实现复用，避免重复造轮子
- Services文件夹下每个服务独立拆分，符合微服务"单一职责"的核心原则，便于独立部署、维护和扩容
- 包含Docker-compose配置，支持容器化部署，契合微服务的运维需求
优化建议：
- 每个服务建议单独创建子目录，包含其API、域模型、数据访问等模块，进一步强化服务的独立性
- 可增加Infrastructure目录，存放数据库脚本、配置中心等公共运维资源

建议继续使用ASP.NET Core Web API（.NET 6）：

技术栈统一，团队可共享知识、工具和经验，降低学习成本和维护难度，避免多技术栈带来的复杂度
.NET 6轻量、高性能，原生支持容器化，拥有完善的微服务生态（如Polly做熔断降级、IdentityServer做认证授权等），非常适合微服务开发
如果Function API指Serverless函数，可选用.NET 6兼容的Azure Functions或AWS Lambda，和Web API共享技术栈，减少切换成本

推荐采用令牌刷新+服务间令牌交换的方案：

前端在令牌过期前主动调用刷新接口获取新令牌，从源头避免请求时令牌已过期
服务间调用层面：
- 不建议每个API都独立访问身份服务器生成专属令牌，会增加身份服务器压力，且重复实现认证逻辑
- 可采用令牌交换模式：前端传入的SSO令牌在网关（DMZ.API）验证通过后，网关向身份服务器请求服务间专用令牌，后续服务间调用均使用该令牌，可将其有效期设置得比前端令牌更长，覆盖CRUD操作周期
- 若必须在业务服务中验证令牌，建议使用统一的认证中间件复用逻辑，同时开启令牌自动刷新（如中间件检测令牌即将过期时，自动刷新并替换）
另外，关键CRUD操作要实现分布式事务（如基于EventBus的最终一致性），即使令牌过期，也能通过事件回溯修正数据，降低回滚成本

内容的提问来源于stack exchange，提问作者Peter