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 下载页面。
评论