微服務API模擬框架frock介紹

時間 2020-08-10

標籤微服 api 模擬框架 frock 介紹简体版

原文原文鏈接

本文來源於我在InfoQ中文站翻譯的文章，原文地址是：http://www.infoq.com/cn/news/2016/02/introducing-frockgit

Urban Airship是一家幫助領導品牌吸引其移動用戶的公司，他們可以幫助這些公司在客戶下載完應用後就與公司創建起高價值的關係。github

眼下，Urban Airship已經有了數量龐大的客戶羣，涵蓋的領域有零售業、媒體與娛樂、運動與旅遊、醫療等。這些公司都經過Urban Airship來加強其與客戶的連結性。近日。來自於Urban Airship的開發人員開源了他們所使用的一款開發工具：frock。該框架用於簡化模擬服務套件的管理。數據庫

假設你在工做中使用了面向服務的架構，那麼frock是很值得你去嘗試的一個工具。json

解決開發環境的複雜性gulp

Urban Airship使用了微服務，這對於一家SaaS公司來講是很常見的模式：咱們有許多服務，每個服務都包裝了少許的功能，並且每個服務都能經過定義良好的協議爲其它服務所請求。這對於可伸縮性與穩定性來講是很棒的，只是對於開發人員與其環境來講卻產生了問題。咱們的團隊從事Go的開發工做（Go是Urban Airship Engagement儀表盤產品），它是最先期的Urban Airship代碼基之中的一個，包括了大量的功能：消息生成與報告、帳單與使用報告。以及服務管理（比方說前不久公佈的Urban Airship Connect）。api

Go會調用大量的服務。這致使團隊的開發環境產生了許多問題。以前，咱們的環境包括了一個單體的、執行於Vagrant之上的虛擬機。它依賴於儀表盤的所有服務。這麼作有許多問題：架構

速度很慢。
服務與依賴的數量許多，包括幾種不一樣的數據庫都需要保持在執行狀態才行。app
很脆弱。咱們的團隊缺乏JVM專家。
上游對服務的改動會破壞咱們的開發環境，致使咱們許多人都不敢更新。框架
致使開發人員沒法繼續工做。當開發人員的環境被破壞後，他們常常沒法繼續工做。
環境的複雜性意味着這樣的破壞是會常常發生的。這會浪費大量的時間。並致使開發人員很沮喪。函數
難以將數據導入到環境中。
在開發階段。你需要多種多樣的數據來測試代碼。
以前的環境一般要求你手工執行測試數據。這是經過與持有數據的服務進行直接的通訊來作到的。

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

何爲frock？

咱們可以經過frock使用本身定義的數據來模擬服務，使用團隊習慣的語言與執行時來編寫模擬服務：JavaScript與Node.js。

frock的核心僅僅提供了例如如下一些功能：

高度可配置的路由，這使得咱們可以輕鬆攔截對服務的調用。
基於插件的架構，它並未對怎樣編寫模擬服務進行強制性約束。
針對常見任務的開箱即用的通用插件。即一個靜態文件server與一個代理server。
支持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通用靜態server插件所處理。所有其它的請求則會直接轉向本地執行的Go開發server，server的端口是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!')
  }
}

假設以前編寫過Node.js的請求處理器。那麼上述代碼就很easy理解了；該frock插件僅僅包括了一個返回路由處理器的工廠函數。

在上述frockfile演示樣例中。咱們將這個插件替換爲靜態文件server：

{
  "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並實現本身的插件。