早前公司支持在内部开始小范围孵化 .NET Core 技术相关的产品，借以取代由 Java 重型开发的一系列产品。推动结果是相对成功的，公司自有产品继续基于 .NET Framework 继续开发，对于业务模块要求全部要在 .NET Standard 下编译通过，并且UT测试也在该环境下进行。
其中有一个比较小的模块比较特殊，它承担了数据解析，分析，并将分析结果存入 SQLServer 中，以及处理与数据服务相关 HTTP 相应。但由于历史原因，它依赖了 BCL 之外的库，但仍然想让它跨平台，至少能在 Windows Server 、Ubuntu Server 和 CentOS 上运行 。
悲催的是这个模块还引用了静态资源，Javascript 和 CSS，以及一些图片资源等。幸运的是这个模块除了 HTTP 请求处理，其它依赖项都可以将源码直接编译进来，所以我们打算将 HTTP 请求处理的框架换掉，使其不再依赖 ASP.NET MVC，并将资源使用嵌入的资源方式直接编译到程序集，再使用一个控制器处理资源请求，不过既然 ASP.NET MVC 都不依赖了，也没有控制器一说了。
调用这个模块的是一个 SelfHost 程序，侦听一个固定端口，通过 Nginx 作为反向代理服务器，供其他Web服务调用，技术实现细节也就是 HttpListener 了，并且有一大堆的 Response 的包装类，实现上不是很优雅，所以连服务器程序也打算一起换掉。
然后就是选型，替代 ASP.NET MVC 的最好框架无疑是 Nancy 了，有关 Nancy 的技术细节可以参考官网和Github。
Nancy On Github : https://github.com/NancyFx
我于 2014 年开始接触这个框架，在那时尝试过将自己个人 Blog 使用 Nancy 重写，并在树莓派上的 Raspbian Debian 上运行起来了，不过那时候没有 .NET Core，有的是一堆 Bug 的 Mono Runtime，如今 Nancy 有超过 271 个 Contributors 和 6K 的 Stars 了，超过 1400 的基佬 Fork 了这个项目，并且解决 Issues 的速度奇快，版本发布也尽然有序，这一切都是在 .NET Core 开源之后，所以我怀疑 Nancy 说不定是有巨硬爸爸在背后撑腰。
接下来需要选择 HTTP 应用服务器，也没有太多疑问，连 ASP.NET Core 已经使用 KestrelServer 了。关于 KestrelServer 我是看博客园上张善友大佬的文章入门的，KestrelServer 实现了 HTTP 的监听，请求和相应，其底层使用了 Libuv 这个库，Libuv 可以说是这几年在 Asynchronous I/O 领域的明星项目了，也大概是因为 Nodejs 的流行。
至此，依据原有的项目特性，我们做好了跨平台的技术替代方案，下篇文章将会继续描述在迁移过程中遇到的难题。
