Compilify——让你在浏览器中编译.NET代码

Compilify是一款以服务形式出现的在线编译器，其创始人是Justin Rusbatch，它运行在Roslyn CTP^[1]之上。从最近开始，它已得到来自.NET社区的大量关注。我们与Justin取得了联系，并向他请教了几个问题。

InfoQ：请向我们的读者做下自我介绍吧？

Justin： 我叫Justin，是名自学开发者，现在就职于一家基于.NET进行网络开发的小型公司，公司位于宾夕法尼亚州的中部。当我还是计算机操作员时，我利用值 夜班时为大型机安装磁带的间隙自学了C#。我使用ASP.NET工作了一年，不过MVC框架一经问世我就转移到了它上面，而且从那时起我已用MVC框架开 发了好几个网站。我也喜欢学习其他语言，对Ruby on Rails、node.js、以及F#都略懂一二。

InfoQ：你最近启动了Compilify项目——请解释一下其用途何在？

Justin： Compilify（读作“compile-ify”）的灵感源于好几件事儿。灵感的主要来源之一就是Roslyn CTP给Visual Studio带来的C#交互窗口（C# Interactive window）。此窗口提供了一种替代环境，以便在开发中的项目上来执行个别语句，并直接得到结果。

Compilify使.NET编译器成为完全便携式的，而且可通过快捷的接口访问，从而促进共享和协作。它不是位于浏览器中的集成开发环境 （IDE），而且永远也不会那样。其实它比那简单得多。为了试验只需几行代码的新点子，你无需启动集成开发环境（IDE）或新建控制台项目。开发者的时间 非常宝贵。正如子曰“思而不学则殆”，花太多时间思考问题却未曾实际尝试过任何解决方案，这样只会导致设计过度的解决方案、并扼杀生产力。

Compilify作为帮助新手学习C#的教学工具同样具有很大潜力。下载、安装、启动Visual Studio可能令新手望而却步。实际上，某些开发者无法安装Visual Studio可能是由于安装了其他不能与之并行的应用程序——从而导致了更加不堪回首的经历。Compilify使得在无需安装任何程序、甚至连浏览器插 件都不需要的情况下，用户即可上手学习C#。

InfoQ：请解释一下Compilify的幕后运行原理？

Justin： 其结构非常巧妙！

一旦用户向服务器提交代码执行，就会用SignalR来建立持久连接。Web服务器使用SignalR连接ID将接收到的代码打包成对象，然后将其添加到位于我的Redis服务器上的处理队列中。从而释放Web服务器，以便继续处理来自其他用户的请求。

尽管处理过程说起来很简单，但是后台工作服务器的处理任务却十分繁重。为了防止运行任何恶意代码，每次执行代码时都会新建充当安全沙箱角色的、低信 任级别的应用程序域（AppDomain）。虽然我没有花时间分析过性能，不过到目前为止，在该应用程序的现阶段下我还无需担心性能问题。因为在应用程序 域（AppDomain）中，除了用户代码之外，只加载了一些必要的程序集。
用户代码先被包装成方法、然后解析成编译单元、进而释放到程序集中。在沙箱内部会加载该程序集，并调用用户代码所包装成的方法。执行结果被序列化，并返回给工作服务器。我在单独的线程中执行这些工作，以便万一耗时太久（目前设置的时间限制是5秒）我可以取消处理。

一旦执行结果返回给了工作服务器，工作服务器就会使用相应的SignalR连接ID（此ID是为了执行此代码，在最初创建请求时得到的）、通过 pub/sub（即publish/subscribe，发布/订阅）通道将执行结果发布回Redis服务器。Web服务器会在App_Start上订阅 此通道。然后以便SignalR通过此通道将任何消息转发给相应的客户端。
为了便于安全执行用户代码，并确保Web服务器的稳定性，因此这种复杂架构是有必要的。

InfoQ：当键入代码时，编辑器几乎会在瞬间做出响应，尽管如此，这仍需一次到服务器的往返行程，你是如何做到的呢？

Justin： 验证用户代码的过程会在输入完成后0.5秒开始。编辑器里的内容会使用标准的AJAX请求以POST方式发送至服务器。在服务器上，会使用Roslyn对 代码进行解析、并检查各种语法或引用错误。然而一旦出现错误，实际上就会终止将编译单元释放到程序集的处理。任何错误都会返回给客户端，并显示给用户。

InfoQ：粗算一下，你花了多少时间或精力来构建此项目？

Justin： 在推出Compilify之前，我在此项目上工作了一周半的时间。当然离完成还差得很远。实际上，我在04月11日发布的版本确实只是个概念验证。我希望 通过发布此版本可以收到一些反馈，而且最好能引起大家的一些兴趣——不过让我始料未及的是，收到的反馈几乎和流量一样多。

 InfoQ：一般来说，你收到的流量是何种状况，而且你为了满足流量要求，平均需要多少台前端Web服务器及后台工作服务器？

Justin： 自从04月11日推出以来的一周时间里，网站点击量已接近20,000。用户已保存、验证或执行代码超过70,000次。大多数流量发生在上周 Twitter发现此站点之后。在John Galloway发微博评论此站点以后产生了不错的负载量——并发会话数保持在50至60之间。随即Scott Hanselman也对此发微博评论，在之后不到五分钟的时间里，该值就增加了两倍，并发会话数的峰值接近170。因此我必须赶紧调整至3台Web服务器 和2台后台工作服务器，以便跟上负载的增长。

如前所述，我确实对这种流量始料未及，而且要是没有来自AppHarbor那帮哥们的帮助，我可能无法解决这种状况。和他们联系很容易，而且他们给我的信息有助于识别那些我能做的改变，以便降低负载。

通过在Web应用程序（负责处理代码验证）与后台工作服务器（负责编译并执行代码）之间保持Redis队列，我能够很容易地扩展该应用。要是队列开始变长，我就增加更多的后台工作服务器，要是前端开始变得不堪重负，我就增加更多的Web服务器。用于AppHarbor的附加组件New Relic确实可以让我轻松监视Web服务器和后台工作服务器的负载。

InfoQ：对于Rosyln、SignalR、Redis、或是在该项目中用到的其他组件，你有哪些特别的学习经验可以分享？

Justin： 尽管SignalR是一款功能强大的工具，并且极其容易建立，但是需要注意你的使用方式。由于它也很快，因此让人感觉有些轻量级。我就曾犯过在页面加载时打开连接却永远不关闭的错误。而对于像http://jabbr.net（由David Fowler创建的聊天应用）等应用，这种行为却是必要的。

不过在我的情况下，就不必那样做。直到用户为了运行代码点击链接以前，我都无需推送消息到客户端。而且一旦执行结果被推送到客户端，也就无需保持连 接的开启状态。自从我按需开启连接之后，服务的负载便随之急剧下降。尽管已有许多关于SignalR的示例，但它们大多是在展示某种用法，例如 Jabbr，因此它们并不会教你如何关闭连接。

Compilify是位于github上的开源项目。该服务位于AppHarbor云平台之上，AppHarbor公司最近资助了该项目。他们在其博客上也推出了一篇对Justin的采访，其中包含更多细节。

译注

[1] Roslyn CTP，传统上，编译器都是黑盒——源代码从一端进入，然后对象文件或程序集从另一端出来。Roslyn项目 通过开放VB和C#编译器改变了这种模型。编译器提供了各种API（应用程序编程接口），从而使得工具和最终用户可以共享编译器所拥有的与代码有关的丰富 信息。通过微软的“Roslyn”CTP（即Community Technology Preview，社区技术预览版）版可预览新的语言对象模型，该模型用于代码生成、分析和重构，还有即将到来的脚本支持、及C#与VB的交互使用。更多内 容请参阅Microsoft “Roslyn” CTP下载页面。