支持HTTP与Socket服务

时间:2022-01-13 06:02:41

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": ":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插件仅仅包孕了一个返回路由措置惩罚惩罚器的工厂函数。