首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

Restful API 监控实践(1)

Restful API 监控实践(1)

概述随着 docker 等技术的兴起,“微服务”的概念也越来越受青睐,日益增多的 Web Service 逐渐统一于 RESTful                架构风格,使得增量开发的代价越来越小。对于众多同时运行在 RESTful 架构下的服务而言,各种状态的管理及监控成为必然。与 SOAP                服务的复杂协议架构相比,RESTful 的风格是轻量级的 Web Service 架构,其实现和操作比 SOAP 和 XML-RPC                更为简洁,可以完全通过 HTTP 协议实现,并利用缓存 Cache 来提高响应速度,在性能、效率和易用性上都优于 SOAP 协议。
RESTful                协议架构和特点REST 即 Representational State Transfer 的缩写,可译为“表现层状态转化”。REST                最大的几个特点为:资源、统一接口、URI 和无状态。
所谓“资源”,就是网络上的一个实体,或者说是网络上的一个具体信息。在实际开发中,资源多数是以 JSON(或其他                Representation)为载体的、面向用户的一组数据集,资源对信息的表达倾向于概念模型中的数据。
“统一接口”是指 RESTful 架构中定义了的与 HTTP 方法相对应的数据元操作,也就是 CRUD(create、read、update 和                delete,即数据的增删查改)操作,这样就统一了数据操作的接口,使得开发者仅通过 HTTP 方法,就可以完成对数据的所有工作,如下:
  • GET(SELECT):从服务器取出资源(一项或多项)。
  • POST(CREATE):在服务器新建一个资源。
  • PUT(UPDATE):在服务器更新资源(客户端提供完整资源数据)。
  • PATCH(UPDATE):在服务器更新资源(客户端提供需要修改的资源数据)。
  • DELETE(DELETE):从服务器删除资源。
“URI” 标示每一个资源的地址或识别符。每个资源至少有一个 URI 与之对应,最典型的 URI 即 URL。
“无状态”是指所有的资源通过 URI 定位,且这个定位与其他资源无关,也不会因为其他资源的变化而改变。
一个典型的 RESTful 请求通常为以下格式:
$ curl -i -H "Content-Type: application/json" -X POST -d                "{"""key""":"""value"""}" yourApi
而返回值通常为如下的 JSON格式:
监控框架基本功能初模型一个 RESTful 架构下实现的应用程序必然具有天然的 RESTful 架构的特点,那么能不能通过解析获取每个 Job 资源的返回值,达到监控管理                Job 资源的目的呢?为此,我们建立了如图 1 所示的初模型:
图 1             . 监控框架初模型Job 是由一个或多个步骤组成,每个步骤都是运行一个特定程序的请求。 例如,图中提交的 Job 包括了以下几个步骤:上传 Data、build                model、scoring nugget 等一系列请求。
在此框架下,只需要模拟客户端发出 post 命令,同时将返回的 JSON 文件重定向到本地进行解析,获取 Job 状态即可。相关的 shell                代码如下:
清单 1. 获取 Job                状态
1
2
3
4
5
6
evokeJob(){
curl -k -X POST -H "$session" -H 'Cache-Control: no-cache' -H
    'Content-Type: application/json' $RequestURL/trigger -d "{\"env\":
    [\"SPARK_VERSION=2.1\"], \"args\": []}"| python -m json.tool
    >$outputPath/tempJobID.txt
}




其中,需要在网页浏览器中的开发者模式下获得相应的"session"和"RequestURL"参数,如图 2 所示:
图 2               . 网页中获取参数信息
实例: 通过调用此方法,会将如下的 JSON 文件导出:
一般而言,服务器端的 Job 有如下几种状态:
  • Pending
  • Waiting
  • Running
  • Succeeded
  • Failed
只有最后两种是 Job 的最终状态,因此,监控过程期间返回值为中间状态下的 Job 仍需继续运行,监控过程也需持续。提取 Job 状态可以简单的用                shell 脚本中的 sed 方法结合 cut 方法,执行命令脚本如下:
清单 2. 提取 Job                状态
1
2
sub2=`cat $outputPath/tempJobstatus.txt |sed 's/\"//g' | grep result`
            JobStatus=$(echo $sub2| cut -f 4 -d :| cut -f 1 -d ,)




实例:对前文中的 JSON 文件进行解析,可以得到"Waiting"这样一个 job 状态。
通常一个 Job                会在经历了几个中间状态后才会返回最终状态,因此需要通过选取适当时间间隔来监控模型,并不断解析获取到的状态,直到得到最终的那两种状态。最后的结果可以写入                report 文件中进行后续的统计整理。要实现多次重复获取解析可以使用如下的方式:
清单 3.                多次重复解析
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CheckStatus(){
            JobStatus="JobStarting..."
             until [ $JobStatus = "Succeeded" ] || [ $JobStatus = "Failed" ]
            do
             echo "Job Current Status is $JobStatus"
             sleep 5
             curl -k -X POST -H "$session" -H 'Cache-Control: no-cache' -H
                'Content-Type: application/json' $RequestURL/trigger -d "{\"args\": []}"|
                python -m json.tool >$outputPath/tempJobstatus.txt
             sub2=`cat $outputPath/tempJobstatus.txt |sed 's/\"//g' | grep result`
            JobStatus=$(echo $sub2| cut -f 4 -d :| cut -f 1 -d ,)
            done
             report="Job Final Status is $JobStatus"
             echo $report
             echo $report >> $outputPath/Report.txt
            }




实例:通过调用以上的方法 report 中最终只会出现如下两种结果:
Job Final Status is Succeeded
或者
Job Final Status is Failed
返回列表