與Henrik Feldt談論Suave 1.0

HF：Suave的第一次代碼提交是大約6年前由Ademar Gonzales開始的。我大約在2年前加入了這一項目，當時我正在尋找一個合適的web服務器，它應當符合我的用例的需求，能夠在Windows及Linux上通過puppet部署由F#編寫的微服務。當時，Suave的開發已經停滯了幾年的時間，但我喜歡它的代碼庫，因為它非常容易理解。

當時的Suave有一些穩定性方面的問題，但Ademar給予了我非常積極的響應，每次我編寫了一個單元測試或是repository的時候，他都能快速地修復其中的問題，而且經常是連夜回復。

因此，我們之間的合作具有很高的生產力。從我的角度來看，初次的互動是非常積極的。大約兩個月之后，在經過了大量的測試之后，我們將其發布到生產環境中。隨后我們克服了一些小小的障礙，在一周之后部署了修正代碼。Suave的表現正如它的名字一樣：非常平滑（smooth）

HF：我常用的做法是讓每個路由的前綴對應著一個不同的F#模塊，記錄在Filters.pathStars中。如此一來，在開發過程中，我就能夠輕易地對App.fs文件進行掃描，以找到我想要改動的前綴。App.api是一個龐大的“選擇”列表，任何互不相關的關注點，例如登錄功能都可以通過“context”功能以加入這個路由列表中。

對于每個模塊，例如帳號（Accounts）模塊來說，會通過Accounts.api列出所有謂詞+路徑的組織（以及其他過濾器）。在這個“選擇”列表中的每一行將負責為調用者生成一個響應，哪怕發生了校驗失敗的情況（通過“bindReq”實現）。

在App.api中的前綴/位置列表中的最下方部分是文件模塊的使用，因此如果某個API的路由找不到匹配，至少該請求可能會對應一個靜態文件。對于qvitoo來說，如果該文件也找不到，那么請求也將始終能夠匹配并返回index.html。因為我們使用了React.JS以及react-router，因此react-router需要負責應用的深度鏈接與導航，并找到正確的頁面。

這種結構能夠讓我們以一種非常靈活的方式添加更多的路由。在Suave中不需要擔心可維護性的問題，因為這個庫不會干擾你的行為，讓你能夠自由地加以選擇。

另外一種方式是通過類似于generator://github.com/rayokota/generator-angular-suave這樣的工具自動生成路由。此外，我認為將來在這方面可能會用到一些元編程技術（例如camlp4）。

當然是構建web應用了！你可以構建各種應用，包括API、微服務以及一個大型的web網站。你也可以把它當作一個服務端類型的F#或C#的CLR應用，作為訪問你的CLR客戶端的入口。你也可以在TopShelf Windows服務中通過它暴露/health功能，并結合使用Logary，它能夠讓運維工作顯得更簡單。

HF：你需要安裝Mono或者.NET，然后運行fsx文件或是exe文件，僅此而已！

主要的麻煩在于，如何在沒有登錄的情況下，保證你的服務器始終在運行這個可執行文件。

如果你的服務器是Windows環境，那么可以選擇TopShelf（我們在GitHub上的庫中有一個示例），或者運行winsw并直接指向你的控制臺應用。Suave本身是非常穩定的，因此你可以在很長的時間內運行這些微服務，并且無需任何人工的介入。

在qvitoo中，我們的開發工作都在OS X上完成，并且在CentOS、Ubuntu以及CoreOS的某些擴展等操作系統中進行預發布和實際部署。當我們運行Linux系統時，所要做的就是在你所選擇的進程管理器中保持一個入口。我們所選擇的是systemd，因此對于qvitoo.com，我們編寫了一個qvitoo.service文件，如下所示：

[Unit] 
Description=Logibit Qvitoo
Wants=bus-org.freedesktop.NetworkManager.target
After=bus-org.freedesktop.NetworkManager.target

[Service]
EnvironmentFile=/etc/sysconfig/qvitoo
User=qvitoo
ExecStart=/opt/qvitoo/start
Restart=always
RestartSec=5

在我看來，Suave如今所受到的關注是因為Suave非常容易上手。

當然，你也可以 部署至Heroku中 ，這是一種十分簡便的方法，因此你完全無需管理服務器的問題。如果樂意的話，你也可以選擇使用Azure。

這個項目有以下幾個里程碑：

• 將首個版本0.0.2發布為NuGet包。
• 設計了產品的文檔以及suave.io網站，這起到了非常大的作用，人們開始對這一項目感興趣。
• 對于公共API實現了完全的文檔化，各種HTTP的組合完全按照HTTP RFC實現了文檔化。
• 通過Ademar設計的monadic socket builder，讓產品的穩定性得到了很大的改進。
• 0.10版本開始支持服務端事件發送（Server Sent Events）。
• 大約在0.16版本開始，人們對此項目的興趣逐漸上升，人們開始在推文中提到Suave。
• 從0.19版本開始支持加密的強會話狀態，并支持在cookie中保存狀態。
• 0.20版本對API進行了大量的重新組織，讓這些API更受歡迎，并且易于理解。
• 0.21修復了在過載的情況下出現末端緩沖區溢出的狀況。
• 從0.25版本開始，這一項目得到了Don Syme的關注，他為我們免費提供了一次API的審查，并且通過一個內容豐富的pull request改進了許多小地方。
• 0.26版本開始支持Razor。
• 0.27版本開始支持WebSocket！
• 0.32版本開始支持OWIN，從此能夠支持來自于社區的大量用例。
• 0.33版本創建了LibUV這個tcp factory。
• 1.0版本使API穩定了下來，并且通過托管代碼實現了TLS（來自于框架）。

HF：qvitoo采取了事件溯源的領域驅動設計（DDD）及命令查詢職責分離（CQRS）系統，運行在先進的硬件上，寫操作的延遲通常在毫秒級以下，而讀操作也差不多同樣快，性能上的延遲主要取決于對于其他子系統的IO操作。

我們還沒有對Suave進行過基準測試，在第1個版本發布之前，我們的主要目標是發布一個優秀的功能性API，它需要做到易用與易于上手。我們希望Suave能夠在高吞吐量的網站與服務中得到更廣泛的應用，我們將看到更多對于性能方面的貢獻。

我在運行OS X的筆記本上進行過一些測試，它每秒種能夠運行5600次HelloWorld。按照我們的假設，如果我們能夠轉換到其他異步框架，例如Hopac上，那么將能夠獲得指數級的吞吐量性能提升，因為它的內存分配比起F#中的async實現要少。而如果在對關鍵路徑中進行的對象分配能夠做得更好，那么還有可能獲得指數級的提高。

如果某位讀者覺得這是一個有趣的挑戰，那不妨來嘗試一下貢獻代碼。我們會頻繁并快速的合并各種pullrequest，并對合并的要求提供大量的反饋，這會使得貢獻代碼的過程更有趣，而且新人也能夠很容易上手。

HF：我們準備支持HTTP2。另外，我們也在討論如何通過更少的內存分配實現1至2個數量級的性能提高。我們或許會轉為使用Hopac，它在異步性能上的表現比起F#中內置的異步功能更出色。

F#團隊提供了一個支持CoreCLR的pull request，等到CoreCLR for F#方面的工具比較穩定之后，我們就打算合并這個pull request。

另外，如果所有的F# HTTP客戶端都能夠使用相同的SocketOp編程模型，也將有一定的實用性，它非常適合于對由Suave開發的網站與API進行單元測試與集成測試時。

作為一門編程語言，F#正在逐漸成熟的過程中。如果Suave能夠通過F#進行編譯，那么或許由Suave開發的網站或許能夠在編譯后運行在Mirage這種exo kernel（也叫做云操作系統）中？甚至也許能夠將Suave網站編譯為原生代碼，在不依賴于類庫的情況下運行。

我們樂意為在Alpine Linux上通過Mono或CoreCLR進行部署提供一個良好的用例。經過幾個月之前開始的工作，Mono已經開始了測試repo。一個Suave服務的部署包大約有5MiB（約等于5MB）用于操作系統，30MiB用于CoreCLR，還有5MiB用于服務本身。

HF：如果你是一位熟練的開發者，并且有興趣在工作中使用一些令人振奮的技術，例如F#、Suave、AI以及web，那么你或許很適合在qvitoo工作。請發送郵件至hi@qvitoo.com。

如果你想要更多地了解如何編寫Suave代碼，以及通用的F#代碼，你可以訂閱 F# TV ，這也是對Suave的開發與維護的一種幫助。