ModelContextProtocol项目中的客户端与服务端API分离设计思考

背景与问题起源

在ModelContextProtocol项目的C# SDK开发过程中，开发团队遇到了一个关于NuGet包设计的架构问题。当前的项目结构将客户端和服务端API都打包在同一个ModelContextProtocol包中，这导致了一些实际应用场景中的不便。

现状分析

当前ModelContextProtocol NuGet包包含了完整的客户端和服务端功能实现。这种设计虽然简化了包的维护，但也带来了一些问题：

1. 不必要的依赖传递：当开发者只需要使用客户端功能时，仍然会被强制引入服务端相关的依赖项，如ASP.NET Core的DI容器抽象等
2. 包体积膨胀：服务端特有的功能代码增加了整体包的大小
3. 未来扩展限制：如果未来服务端需要增加对ASP.NET Core的依赖，将会影响所有客户端用户

技术讨论与方案探索

开发团队对这个问题进行了深入的技术讨论，尝试了多种解决方案：

方案一：客户端/服务端分离

最初提出的方案是将现有包拆分为：

• ModelContextProtocol.Client
• ModelContextProtocol.Server

经过实际验证，这种拆分会导致：

• 总包体积增大（约增加125KB）
• 需要创建第三个共享核心包
• 部分内部实现需要在多个包中重复编译

方案二：协议层与辅助层分离

另一种方案是将基础协议实现与高级功能分离：

• ModelContextProtocol.Protocol（基础协议实现）
• ModelContextProtocol（高级功能）

这种方案虽然减少了约90KB的体积，但改善效果有限。

性能考量

微软Visual Studio团队特别关注程序集加载数量对启动性能的影响。任何增加程序集加载数量的方案都可能影响IDE的启动性能。

最终解决方案

经过多次讨论和验证，团队决定采用折中方案：

1. 从主包中移除对Microsoft.Extensions.Options和Microsoft.Extensions.Hosting的依赖
2. 将这些功能移至AspNetCore专用包中
3. 创建ModelContextProtocol.Core精简包

调整后的依赖关系简化为：

• Microsoft.Extensions.Logging.Abstractions
• Microsoft.Extensions.AI.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• System.Net.ServerSentEvents（在net10中属于netcoreapp）

技术实现细节

在实现过程中，团队特别关注了以下技术点：

1. JSON序列化优化：协议中的约80个DTO类使用了JSON源生成器，这占据了包体积的很大部分
2. 修剪(trimming)支持：在简单控制台应用场景下，大部分依赖项可以被完全修剪掉
3. ASP.NET Core集成：将ASP.NET特有的功能完全隔离在单独的包中

架构设计启示

这个案例为我们提供了几个重要的架构设计经验：

1. 依赖最小化原则：核心库应尽可能减少外部依赖
2. 关注实际应用场景：需要考虑不同使用场景下的具体需求
3. 性能权衡：在功能拆分和性能影响之间需要找到平衡点
4. 未来扩展性：设计时要考虑未来可能的功能演进路径

结论

ModelContextProtocol项目通过这次架构调整，实现了更清晰的模块划分和更合理的依赖管理。这种演进过程展示了在实际项目中如何平衡功能完整性、性能要求和未来可扩展性等重要因素。最终的解决方案既满足了客户端应用的轻量级需求，又保留了服务端功能的完整性，为项目未来的发展奠定了良好的基础。