本文來源于我在InfoQ中文站翻譯的文章，原文地址是：http://www.infoq.com/cn/news/2016/02/introducing-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的核心僅僅提供了例如以下一些功能：

• 高度可配置的路由，這使得我們能夠輕松攔截對服務的調用。
• 基于插件的架構，它并未對怎樣編寫模擬服務進行強制性約束。

• 針對常見任務的開箱即用的通用插件。即一個靜態文件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 = createPluginfunction createPlugin (frock, logger, options) {return handlerfunction 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并實現自己的插件。

總結

以上是生活随笔為你收集整理的微服务API模拟框架frock介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。