使用.NET Core搭建分布式音频效果处理服务（一）需求、问题和解决方案的几个坑
最近公司需要在服务器上实现两个音频的合成及效果处理。
哇，乍一听功能很简单吧，就是将两个音频叠加，随便一个媒体处理软件几秒钟即可完成，但这仅仅只是针对单用户而言而已。其次，本来这种服务原本就不应该在服务器上面实现，为何？
- 流媒体处理是相当耗费服务器资源的，包括IO，CPU，bandwidth等等。
- 服务器资源并不是毫无限制的，比如物理数量就会涉及到整体成本。
- 如果是一台机器维护到也简单，但实际运行场景远不止这么简单。
- 处理这类流媒体，时间上绝不是用毫秒级的方式来响应，这样就会衍生出更多的问题，比如一些莫名其妙的运行时错误。
如果在C/S模式下，完全可以采用client原生的在客户机上面进行流数据媒体处理，再将处理后的文件上传到指定的云存储位置（比如阿里云的OSS），这样对于服务器来说0压力，只是做个中间数据传递即可。一切就那么简单，不存在大并发问题，不存在扩展性问题，可两个关键问题又来了：
- 如果所有交互设备都使用统一的流媒体处理库进行处理（比如ffmpeg），那么，最终得到的效果文件将必定是一样的，可目前关键是目前IOS小组和ANDROID小组参数一样，得到的效果却完全不一样，IOS上有很明显的电流声和杂音（如果有高手指点一下，鄙人非常感谢，嘿嘿）。
- 在原生的软件（APP）上调用ffmpeg是可行的，在网页上怎么办？毕竟目前网页也可以实现录音的功能，比如微信API、Recorder.js，用户需要将自己的录制的声音进行一些效果处理的时候，那么网页将是无能为力的。
如上的最终效果不一致、平台功能没有100%覆盖问题，将又是这个产品实际的最大隐患，一致性和通用性并不只是针对技术要求，用户在产品的反馈上同样也需要一致性和通用性。因此，这样就需要服务器来统一处理这类功能需求和问题，如下几点优势（仅针对这个项目而言）：
- 一致性。不论在哪种设备和操作系统（现在谁没有几台的智能设备啊），通过服务器统一反馈回来的音频文件试听效果均是一样的。
- 通用性。只需要统一的一个接口调用，不论PC，APP，H5网页，甚至包括嵌入式设备，只要能通信，那用户就能实现自己想要的音频合成效果。
- 不发烧。还有一个就是用户的可移动设备不用在因为处理某个音频而发烧烫手了，喝喝（对于部分低配的ANDROID手机）。
纯粹的点对点C/S模式，这里就不画图了，下一节我们开始慢慢的画饼o(∩_∩)o 哈哈。
感谢阅读
