1. 微服务架构与ASP.NET Core
微服务架构不是“把项目拆成多个小项目”这么简单。它本质上是一种围绕业务能力组织系统的架构风格：每个服务独立部署、独立运行、独立演进，服务之间通过网络通信协作，共同完成整体业务。理解这一点，是后续所有工程实践的前提。
1.1 微服务的定义与核心特征
微服务（Microservices）是一种将单一应用程序划分为一组小型服务的架构方式，每个服务运行在独立进程中，围绕业务能力构建，通过轻量级通信机制（如 HTTP/REST、gRPC、消息队列）交互。它强调以下几个关键特征：
- 单一职责与业务边界清晰：一个服务只负责一个明确的业务领域，例如“订单服务”只处理订单生命周期，不掺杂库存或支付逻辑。
- 独立部署与独立数据：每个服务可单独发布，拥有自己的数据库或数据存储，避免共享数据库带来的耦合。
- 去中心化治理：不同服务可选择最适合自身的技术栈，而不必全系统统一。
- 面向失败设计：承认网络不可靠、服务会故障，通过超时、重试、熔断、降级等手段保证整体可用性。
- 可观测性：日志、指标、链路追踪是标配，否则分布式问题几乎无法定位。
1.2 与单体架构的对比
单体架构把所有功能打包成一个进程、一个部署单元。它的优势是开发简单、调试方便、事务一致性强，适合早期快速验证。但随着业务增长，单体容易出现代码膨胀、构建变慢、发布风险高、局部扩容困难等问题。微服务则通过拆分换取独立性与弹性，但代价是分布式复杂度上升。
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署单元 | 一个整体 | 多个独立服务 |
| 数据存储 | 通常共享一个库 | 每服务独立数据 |
| 技术栈 | 统一 | 可异构 |
| 扩容粒度 | 整体扩容 | 按服务扩容 |
| 故障影响 | 易全局崩溃 | 可隔离降级 |
| 复杂度 | 集中在代码 | 分散在分布式系统 |
选择哪种架构，取决于团队规模、业务复杂度和交付节奏。微服务不是目标，而是应对复杂系统的一种手段。
1.3 ASP.NET Core 在微服务中的优势
ASP.NET Core 是构建微服务的理想平台之一，原因包括：
- 跨平台与轻量：可在 Linux、Windows、macOS 运行，容器镜像小，启动快。
- 内置依赖注入与配置系统：天然适合按服务组织代码与配置。
- 高性能：Kestrel 服务器与异步编程模型适合高并发 API 网关和服务间调用。
- 丰富的生态：gRPC、SignalR、HealthChecks、Polly、OpenTelemetry 等可直接集成。
- 与容器和编排友好：官方提供 Docker 支持，便于部署到 Kubernetes。
1.4 典型技术选型与工程全景
一个典型的 ASP.NET Core 微服务工程通常包含以下层次与组件：
- API 网关：如 YARP 或 Ocelot，负责路由、认证、限流。
- 服务注册与发现：Consul、Eureka 或 Kubernetes Service。
- 服务间通信：REST/HTTP、gRPC、RabbitMQ/Kafka 消息。
- 数据存储：每个服务独立使用 SQL Server、PostgreSQL、MongoDB 或 Redis。
- 可观测性：Serilog 日志、Prometheus 指标、Jaeger 链路追踪。
- 容错与弹性：Polly 实现重试、熔断、超时、舱壁隔离。
- CI/CD：GitHub Actions、Azure DevOps 或 Jenkins 构建镜像并部署。
下图展示了本节核心内容的结构关系：从单体到微服务的拆分逻辑，以及 ASP.NET Core 在其中的技术定位。
1.5 工程落地时的关键判断
在实际项目中，是否采用微服务、拆到什么粒度，需要结合团队规模、业务边界和运维能力综合判断。一个常见的误区是“为了微服务而微服务”，结果把一个简单系统拆成十几个服务，反而增加了部署、调试和一致性成本。合理的做法是：先识别业务边界（如订单、库存、支付），再评估每个边界的独立变更频率和扩容需求，最后决定是否拆分。