在C#技术栈下开发社交媒体平台，核心挑战并不是某个具体功能如何实现，而是如何在业务快速变化的同时，保持后端架构的清晰与可扩展。很多团队初期为了赶进度，把所有逻辑写在同一个ASP.NET Core项目里，随着动态feed、好友关系、私信、通知等模块膨胀，代码变成难以维护的巨石应用。本文基于一个真实项目的演进路径，分享如何用C#构建分层、可插拔的社交平台后端。
一、整体分层与职责划分
项目起步时我们确定了四个核心层次：网关层、业务服务层、数据访问层以及基础设施层。网关层只负责路由、鉴权和限流，不写任何业务代码；业务服务层按域拆分，例如用户服务、动态服务、消息服务各自独立；数据访问层统一使用Entity Framework Core，并针对读多写少的场景配置读写分离；基础设施层封装了Redis、RabbitMQ、日志等通用能力。
这种划分带来的直接好处是，当动态服务的流量增长明显快于其他模块时，我们可以单独对它做水平扩容，而不必复制整个系统。同时，各服务之间通过明确的接口契约通信，避免了隐式依赖。下面是一个简化的服务注册示例，展示如何在Program.cs中组织不同层次：
// 在ASP.NET Core中注册分层服务
var builder = WebApplication.CreateBuilder(args);
// 基础设施层
builder.Services.AddStackExchangeRedisCache(options =>
{
options.Configuration = builder.Configuration["Redis:Connection"];
});
// 数据访问层
builder.Services.AddDbContext<AppDbContext>(options =>
options.UseSqlServer(builder.Configuration.GetConnectionString("WriteDb")));
// 业务服务层
builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddScoped<IFeedService, FeedService>();
builder.Services.AddScoped<IMessageService, MessageService>();
// 网关层相关中间件在后续配置
var app = builder.Build();
二、动态Feed的生成与缓存策略
社交媒体平台最典型的读场景是信息流。如果每次打开App都去数据库联表查询关注人的最新动态，系统在万级并发下会迅速崩溃。我们采用推拉结合的模式：活跃用户发动态时，同步将动态ID写入其粉丝的Redis有序集合（推模式）；长尾用户则在其打开feed时临时拉取。这样既控制了写扩散规模，也保证了体验。
具体实现中，FeedService依赖IDatabaseAsync操作Redis，并用EF Core补充动态正文。以下代码展示了写入粉丝feed的核心逻辑，注意其中对批量写入做了管道优化，以降低网络往返：
public class FeedService : IFeedService
{
private readonly IDatabaseAsync _redis;
private readonly AppDbContext _db;
public FeedService(IDatabaseAsync redis, AppDbContext db)
{
_redis = redis;
_db = db;
}
public async Task PushToFansAsync(long authorId, long postId, List<long> fanIds)
{
// 使用Redis批量管道提升写入性能
var batch = _redis.CreateBatch();
foreach (var fanId in fanIds)
{
var key = $"feed:{fanId}";
batch.SortedSetAddAsync(key, postId, DateTimeOffset.UtcNow.ToUnixTimeSeconds());
}
await batch.ExecuteAsync();
// 动态元数据落库
_db.Posts.Add(new Post { Id = postId, AuthorId = authorId });
await _db.SaveChangesAsync();
}
}
缓存层面，我们给热门用户的feed设置了五分钟本地内存缓存，配合Redis形成多级缓存。当某明星用户发博导致瞬时流量尖峰时，网关层限流结合缓存命中，使数据库压力维持在平稳区间。这种策略的缺点是缓存失效瞬间可能有少量请求穿透，因此我们引入了单飞机制，保证同一key只回源一次。
三、实时私信与SignalR集成
私信是社交平台的强实时需求。如果采用轮询，既浪费带宽也增加延迟。我们利用ASP.NET Core SignalR建立长连接，将连接ID与用户ID映射存入Redis，这样在分布式部署下也能准确投递。消息服务在收到发送请求后，除了落库，还通过SignalR的Hub向外推送。
下面是Hub的简化定义，以及如何在MessageService中调用。需要特别注意的是，SignalR的Context.Clients访问应做空值保护，避免用户离线时抛出异常：
public class ChatHub : Hub
{
// 客户端调用此方法发送私信
public async Task SendPrivateMessage(long toUserId, string content)
{
var fromUserId = long.Parse(Context.UserIdentifier);
// 实际项目中此处调用IMessageService持久化并转发
await Clients.User(toUserId.ToString()).SendAsync("ReceiveMessage", fromUserId, content);
}
}
// MessageService中的投递片段
public async Task SendAsync(long from, long to, string text)
{
var msg = new Message { FromId = from, ToId = to, Text = text, SentAt = DateTime.UtcNow };
_db.Messages.Add(msg);
await _db.SaveChangesAsync();
// 通过SignalR backplane推送到指定用户
await _hubContext.Clients.User(to.ToString()).SendAsync("ReceiveMessage", from, text);
}
SignalR自带Scale-out支持，借助Redis backplane，多台网关服务器之间可以互相转发消息。我们在压测中发现，单节点可稳定维持约两万并发连接，通过增加节点线性扩展即可支撑更高规模。缺点是长连接对内存有一定占用，需要合理设置空闲超时。
四、异步任务与后台处理
社交平台有大量非实时任务，例如粉丝数统计、违规内容扫描、每日推送。我们统一用BackgroundService承载，避免阻塞Web请求线程。以通知服务为例，新动态产生后，只向消息队列发一条事件，由独立消费者批量读取并调用手机推送网关。
下面代码演示了一个最小化的后台服务骨架，它通过Channel接收事件，在ExecuteAsync中持续处理：
public class NotificationWorker : BackgroundService
{
private readonly Channel<long> _channel;
private readonly INotificationSender _sender;
public NotificationWorker(Channel<long> channel, INotificationSender sender)
{
_channel = channel;
_sender = sender;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
await foreach (var postId in _channel.Reader.ReadAllAsync(stoppingToken))
{
// 拉取关注者并发送推送，此处省略细节
await _sender.NotifyForPostAsync(postId);
}
}
}
将耗时操作移出请求链路后，API的P99延迟从八百毫秒降到一百二十毫秒以内。同时后台任务可独立重启，不影响线上接口。我们建议所有超过两百毫秒的非交互逻辑都走这条路径。
五、经验总结与避坑建议
回顾整个项目，最大的收益来自早期对边界的苛求：每个服务只解决一个问题，跨服务调用显式化。另一个易踩的坑是过度依赖EF Core的自动迁移，我们在生产环境改为使用独立迁移工具，并冻结运行时自动建表，防止意外结构变更。
如果重来一次，我们会更早引入OpenTelemetry做链路追踪，因为当用户投诉动态看不到时，能快速定位是推模式失败还是缓存未命中。C#在类型安全和异步模型上的优势，让这些排查变得相对可控。对于打算用C#做社交后端的团队，先画好层次图，再写第一行代码，会省下大量返工成本。