日常运维工作中有许多的任务要执行，例如项目发布/数据备份/定时巡检/证书更新/漏洞修复等等，大部分的任务都会有多个步骤共同完成，例如一个发布任务会有拉代码、编译、分发、通知等等步骤，而不同的任务可能还包含相同或相似的步骤，例如对于相同语言相同架构的不同项目来说，他们的发布任务步骤可能是相同的，仅仅是几个参数不同而已，为此我们上线了任务系统，任务系统可以像乐高搭积木一样组合不同的步骤（也就是子任务）为一个模板，然后基于模板配合参数来创建任务并执行，灵活且高效
其中子任务的类型越丰富则上层模板的组合方式就会越多样，从而最终的任务覆盖场景就能越全面，目前任务系统子任务的类型已经支持了命令、脚本、作业、Jenkins、审批、通知、API、告警策略和事件规则，之前有篇文章任务系统之Jenkins子任务介绍过Jenkins类型子任务的实现，那这篇文章来介绍下另一个很重要的子任务类型：API
API的使用场景非常之广，在现代的Web系统中绝大部分的操作都可以由API来完成，任务系统对API类型子任务的支持不仅使得任务系统的覆盖场景更加的全面，同时也使得API的调用更加的方便和安全。在未支持API类型子任务之前，任务系统都是通过脚本类型子任务由用户自己编写脚本来实现API调用的，这种方式虽然可用但存在问题，其一是因为写脚本对用户有一定的能力要求，同时增加了复杂度，其二也更为关键的是不安全，API往往需要验证，验证内容写在脚本中，脚本明文存储在数据库中，增加了安全风险，集成API类型子任务可以完美解决这两个问题
API类型子任务的使用方式很简单，只需要三步，第一步新建API，第二步新建API类型的子任务，这里选择第一步创建的API，第三步在任务模板中添加第二步创建的子任务，然后就可以新建任务执行了。其中第二第三步是任务系统的通用流程，这里重点说下第一步关于API的创建，API与Jenkins一样是作为一个插件存在于系统中的，由独立的API管理页面
点击右上角添加按钮之后就可以添加新的API了，创建表单主要包含名称、请求、参数和成功条件四块内容
名称就是个输入框，标识这个API的名称，清晰易理解就好
请求和参数用来配置这个API的主要属性，包含了Method、URL、Parameters、Body、Headers、Cookies和Authentication认证方式配置，页面参考了Postman的设计。其中认证方式的话支持Basic、BearerToken和APIKey，后续也可以根据需要新增更多的认证方式，甚至直接接入多云的认证，实现云上API的便捷使用，以弥补多云系统的不足
前后端通过JSON格式实现数据交互，前端根据输入的请求和参数组装成JSON格式提交给后端，后端则根据认证方式加密对应的密码或Token字段并保存到数据库，当任务请求发起时从数据库获取JSON数据并解密，解析解密后的JSON数据调用Requests模块请求并获取结果
最后一块是判断API是否请求成功的规则集，默认情况下会判断API的返回状态码，如果状态码为2xx或者3xx都认为是成功的，当然用户也可以根据状态码或是响应体自定义成功的规则，例如某些情况下你可能仅需要API返回200表示成功，或者是响应体里的state字段为1算成功，都可以通过自定义灵活的配置。判断API是否请求成功很重要，在一个任务流中，某个步骤的成功与失败直接影响后续步骤的执行，API也不例外，当API任务执行失败时则终止任务流程的执行
前端组装好的JSON格式参考如下服务器托管网
{
"name": "获取Github仓库blog的branches",
"api": {
"method": "GET",
"url": "https://api.github.com/repos/ops-coffee/blog/branches",
"parameters": [],
"body": "",
"headers": [{"name": "Content-Type", "note": "", "type": "string", "value": "application/json"}],
"cookies": [],
"authorization": {
"type": "Bearer",
"bearer_to服务器托管网ken": "ghp_3dtK****************IIcN",
}
},
"success": [
{"key": "status_code", "type": "状态码", "value": ["200"], "operator": "匹配"},
{"key": "name", "type": "响应体", "value": "main", "operator": "等于"}
]
}
后端加解密的方法可以参考文章Model字段加密的优雅实现，Request请求则比较简单
# 不同的认证类型使用不同的请求方式
if authorization.get("type", "").lower() == "basic":
auth = (authorization.get("basic_username", ""), authorization.get("basic_password", ""))
response = requests.request(method, url, params=parameters, headers=headers, cookies=cookies, auth=auth,
data=body)
else:
if authorization.get("type", "").lower() == "bearer":
headers["Authorization"] = "Bearer " + authorization.get("bearer_token", "")
elif authorization.get("type", "").lower() == "apikey":
headers[authorization.get("api_key_key")] = authorization.get("api_key_value", "")
response = requests.request(method, url, params=parameters, headers=headers, cookies=cookies, data=body)
# 解析Response结果判断是否成功
......
API创建完成后就可以添加子任务，添加了子任务就可以将子任务添加到模板，最后创建任务并执行了，执行结果实时输出
至此API类型子任务介绍完成，API类型子任务快速打通了任务系统与三方的链接，为任务系统增加了无限可能，期待它在业务中的表现
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
问题描述 PCF8591在循环读取两个通道时，两个通道数据出现交错问题。 例如我们想实现：第一次读取通道一、第二次读取通道二、第三次读取通道一、第四次读取通道二……依次循环 但实际数据：第一次读取的值为0x80服务器托管网、第二次读取的值为通道一的值、第三次读…
