微服務API模擬框架frock介紹

Urban Airship 是一家幫助領導品牌吸引其移動用戶的公司，他們可以幫助這些公司在客戶下載完應用后就與公司建立起高價值的關系。目前，Urban Airship已經有了數量龐大的客戶群，涵蓋的領域有零售業、媒體與娛樂、運動與旅游、醫療等。這些公司都通過Urban Airship來增強其與客戶的連結性。近日，來自于Urban Airship的開發者開源了他們所使用的一款開發工具： frock ，該框架用于簡化模擬服務套件的管理。如果你在工作中使用了面向服務的架構，那么frock是很值得你去嘗試的一個工具。

解決開發環境的復雜性

Urban Airship使用了 微服務 ，這對于一家SaaS公司來說是非常常見的模式：我們有很多服務，每個服務都包裝了少量的功能，并且每個服務都能通過定義良好的協議為其他服務所請求。這對于可伸縮性與穩定性來說是非常棒的，不過對于開發者與其環境來說卻產生了問題。我們的團隊從事Go的開發工作（Go是Urban Airship Engagement儀表盤產品），它是最早期的Urban Airship代碼基之一，包含了大量的功能：消息生成與報告、賬單與使用報告，以及服務管理（比如說前不久發布的 Urban Airship Connect ）。Go會調用大量的服務，這導致團隊的開發環境產生了很多問題。之前，我們的環境包含了一個單體的、運行于Vagrant之上的虛擬機，它依賴于儀表盤的所有服務，這么做有很多問題：

• 速度非常慢。服務與依賴的數量非常多，包括幾種不同的數據庫都需要保持在運行狀態才行。
• 非常脆弱。我們的團隊缺少JVM專家。上游對服務的修改會破壞我們的開發環境，導致我們很多人都不敢更新。
• 導致開發者無法繼續工作。當開發者的環境被破壞后，他們常常無法繼續工作。環境的復雜性意味著這種破壞是會常常發生的。這會浪費大量的時間，并導致開發者非常沮喪。
• 難以將數據導入到環境中。在開發階段，你需要多種多樣的數據來測試代碼。之前的環境通常要求你手工運行測試數據，這是通過與持有數據的服務進行直接的通信來做到的。

frock就是用來幫助我們解決上述所有難題的優秀工具。

何為frock？

我們可以通過frock使用自己定義的數據來模擬服務，使用團隊習慣的語言與運行時來編寫模擬服務：JavaScript與Node.js。frock的核心只提供了如下一些功能：

• 高度可配置的路由，這使得我們可以輕松攔截對服務的調用。
• 基于插件的架構，它并未對如何編寫模擬服務進行強制性約束。
• 針對常見任務的開箱即用的通用插件，即一個靜態文件服務器與一個代理服務器。
• 支持HTTP與Socket服務。
• HTTP中間件支持，可以自定義服務或路由的行為；比如說，它提供了一個延遲中間件，可以延遲請求的時間。

所有這一切都是通過一個JSON配置文件（根據約定，該文件名為frockfile.json）來配置的，并且通過包含了所有自定義模擬服務的倉庫進行共享。frock從grunt與gulp獲得了靈感，其配置就位于你的項目當中。對于HTTP模擬來說，一個frockfile會包含一個簡單的服務與路由定義，比如說：

{
  "servers": [
    {
      "port": 8080,
      "routes": [
        {
          "path": "/api/devices",
          "methods": ["GET"],
          "handler": "frock-static",
          "options": {
            "file": "./fixtures/devices.json",
            "contentType": "application/json"
          }
        },
        {
          "path": "*",
          "methods": "any",
          "handler": "frock-proxy",
          "options": {
            "url": "http://localhost:8052"
          }
        }
      ]
    }
  ]
}

這是我們frockfile中服務定義的一個高度簡化的版本。在訪問Go儀表盤時，你實際上會命中一個高可用的代理：該代理會在內部將流量導向不同的服務，其中的主服務是Go，不過一些API路由則是由二級服務所處理的。相比于在本地運行這個二級服務，我們可以通過frock選擇這個路由，并使用模擬的版本將其替換掉。在上述代碼示例中，模擬的僅僅是個靜態文件，它由frock-static通用靜態服務器插件所處理。所有其他的請求則會直接轉向本地運行的Go開發服務器，服務器的端口是8052。

編寫frock插件

實際上，frock是我們解決這一問題的第2個平臺，第1個平臺是個名為“multimock”的工具，它是個單體Python應用，能夠創建出多個服務線程，并在到達自定義處理器之前將其傳遞給一些通用的轉換函數。它能夠解決不少問題，不過我們還是重寫了它，最后才有了frock。為什么要這么做呢？這是因為在multimock中編寫插件是非常困難的事情。在編寫frock時，我們的核心原則是“插件的編寫應該保持簡單，內建的假設越少越好”。frock通過對插件施加極少的限制來實現這個目標，并且將Node.js HTTP模塊的簡單性直接應用到了實現中。如下代碼展示了最簡單的一個frock HTTP插件，它只是向命中路由的任何請求響應了“hello world!”而已：

// file ./hello-world.js
module.exports = createPlugin

function createPlugin (frock, logger, options) {
  return handler
function handler (req, res) {
    res.end('hello world!')
  }
}</pre> 
 
如果之前編寫過Node.js的請求處理器，那么上述代碼就很容易理解了；該frock插件只包含了一個返回路由處理器的工廠函數。在上述frockfile示例中，我們將這個插件替換為靜態文件服務器：

{
  "servers": [
    {
      "port": 8080,
      "routes": [
        {
          "path": "/api/devices",
          "methods": ["GET"],
          "handler": "./hello-world"
        },
        {
          "path": "*",
          "methods": "any",
          "handler": "frock-proxy",
          "options": {
            "url": "http://localhost:8052"
          }
        }
      ]
    }
  ]
}
 
 
現在，對http://localhost:8080/api/devices的任何請求都會返回“hello world!”。

 frock對我們的幫助作用 
大的特性發布常常都是非常復雜的：你經常要等待依賴的服務就緒，還要閱讀如何使用這些服務的規范。在快節奏的項目中，這意味著你要不斷追趕集成的日期；當最終所有組件都就位后，你希望他們能夠彼此調用成功。Connect就是這樣一個項目，frock可以幫助Web團隊構建出令我們充滿自信的項目，并且能夠很好地實現集成。
 其實，上面所介紹的關于frock的一切都不是什么革命性的功能，不過frock卻能夠幫助我們以一種更簡單的方式做到這些。建議各位讀者嘗試一下，你會發現它在你的開發環境中是非常有用的。frock README 包含了一個快速起步指南，還有一個內容豐富的文檔與示例代碼，可以幫助你快速起步，在項目中 使用frock 并 實現自己的插件 。