.NET 手写微服务全框架，从零实现注册中心 / 网关 / 分布式事务，带你自研企业微服务平台

来源： .NET 手写微服务全框架，从零实现注册中心 / 网关 / 分布式事务，带你自研企业微服务平台

最近后台很多朋友留言：面试总被问微服务底层原理，只会用 Consul、Ocelot、CAP，说不出实现细节；项目里套了一堆第三方组件，出了问题根本无从下手；想往架构师方向走，却始终停留在 "调用方" 层面。

今天这篇文章，我带你纯手写一套 .NET 微服务核心框架，不依赖任何第三方微服务组件，从零实现服务注册与发现、API 网关、分布式事务三大核心模块。全程源码级拆解，看完你不仅能看懂主流框架的设计思想，还能亲手搭出一套可落地的企业级微服务底座。

---

一、为什么要手写微服务框架？

很多人觉得 "有现成的为什么要自己写"，这是典型的开发者思维误区。

• 面试层面
  
  ：大厂面试问的永远是 "原理" 和 "设计"，不是 "怎么用"。你说你会用 Consul，面试官问你服务心跳失效机制怎么实现、服务列表怎么推拉同步，答不上来直接 pass。
• 排障层面
  
  ：生产环境网关超时、服务注册不上、事务消息丢失，不懂底层只能瞎猜参数，定位问题效率差十倍。
• 架构层面
  
  ：真正的架构师不是组件搬运工，而是能根据业务特性裁剪、定制、自研基础设施的人。

今天我们实现的这套框架，对标主流微服务架构的核心能力：

核心模块	业界主流方案	我们自研实现
服务注册中心	Consul / Nacos	基于 ASP.NET Core + 内存缓存 + 心跳机制
API 网关	Ocelot / YARP	基于中间件的路由转发 + 负载均衡
分布式事务	CAP / MassTransit	基于本地消息表 + 补偿机制的 TCC 简化版

所有代码基于 .NET 8 编写，无任何第三方微服务 NuGet 依赖，复制粘贴就能跑。

---

二、整体架构设计

先看全景架构图，心里有个整体认知：

核心设计原则：

1. 注册中心中心化
   
   ：所有服务启动时注册，定时发心跳，下线自动摘除
2. 网关无状态化
   
   ：网关从注册中心拉取服务列表，本地做负载均衡
3. 事务最终一致性
   
   ：采用异步确保型方案，牺牲强一致换取高可用

---

三、模块一：从零实现服务注册中心

3.1 核心原理

服务注册中心本质就是一个 "服务地址字典" + "心跳保活机制"：

• 服务启动时，把自己的服务名、IP、端口上报给注册中心
• 每隔 N 秒发一次心跳，证明自己还活着
• 注册中心超过 M 秒没收到心跳，就把该实例从服务列表里移除
• 消费方从注册中心拉取可用服务列表，本地缓存

3.2 服务注册中心核心代码

新建一个 Web API 项目 MicroService.Registry，定义服务实例模型：

注册中心核心存储，用 ConcurrentDictionary 保证线程安全：

然后暴露三个 HTTP 接口：注册、心跳、发现，注册为单例服务即可。一个最简化的注册中心就完成了。

3.3 客户端 SDK 封装

给业务服务封装一个客户端，让接入方一行代码就能完成注册：

后台服务启动时自动注册 + 定时心跳：

---

四、模块二：手写 API 网关

4.1 网关核心职责

我们的网关实现三大核心能力：

1. 路由转发
   
   ：根据请求路径匹配对应服务
2. 服务发现
   
   ：从注册中心拉取服务实例列表
3. 负载均衡
   
   ：轮询算法分发请求

4.2 网关中间件实现

基于 ASP.NET Core 中间件管道实现，这是网关最核心的转发逻辑：

4.3 负载均衡策略

抽象出负载均衡接口，支持轮询、随机两种策略，后续可扩展权重、一致性哈希：

最后在 Program.cs 里一行启用网关：

一个具备服务发现、负载均衡、路由转发能力的 API 网关就写完了，总代码不到 300 行。

---

五、模块三：手写分布式事务框架

5.1 方案选型

分布式事务有 TCC、Saga、本地消息表等多种方案。我们实现最通用、落地性最强的本地消息表方案，保证最终一致性。

核心思路：

1. 业务操作和消息写入放在同一个本地事务里
2. 后台任务定时扫描待发送消息，投递到消息队列
3. 消费方幂等处理，失败自动重试
4. 超过最大重试次数进入死信人工干预

5.2 本地消息表设计

5.3 事务消息发布端

核心是 TransactionMessagePublisher，在业务事务里同步写入消息：

业务使用示例（订单创建 + 扣库存消息在一个事务里）：

5.4 后台消息投递器

后台任务定时扫描待发送消息，异步投递：

配合消费端的幂等校验（按 MessageId 去重），一套完整的最终一致性分布式事务方案就落地了。

---

六、整体联调与运行效果

1. 启动注册中心（端口 8000）
2. 启动订单服务、库存服务，自动注册到注册中心
3. 启动网关（端口 9000）
4. 客户端调用 http://localhost:9000/order/api/order/create
5. 网关转发到订单服务，订单服务写入本地消息
6. 后台投递器自动调用库存服务扣减库存

整个链路没有引入 Consul、Ocelot、CAP 等任何第三方微服务组件，全部自研实现。

---

源码

为了帮助大家快速上手，本文配套完整可运行源码包已整理好。

关注公众号【WPF开发上位机专家】，评论区留言或者后台回复【自研微服务】即可直接获取全部源码。

如果这篇文章对你有帮助，欢迎点赞、在看、转发给身边的 .NET 开发者。

今天我们实现的是微服务框架的 "最小可行版本"，但核心思想和主流框架完全一致。真实企业级框架还会扩展：

• 注册中心持久化 + 集群部署
• 网关限流、熔断、降级
• 分布式链路追踪
• 配置中心
• 容器化部署

掌握了底层原理，再去看任何微服务框架都是降维打击。架构能力的提升，从来不是靠堆组件，而是靠拆解和实现的过程。