<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>BeeFog – 参与开源项目开发</title><link>https://queenbee.netlify.app/zh/docs/6-contribute/</link><description>Recent content in 参与开源项目开发 on BeeFog</description><generator>Hugo -- gohugo.io</generator><atom:link href="https://queenbee.netlify.app/zh/docs/6-contribute/index.xml" rel="self" type="application/rss+xml"/><item><title>Docs: 开发计划</title><link>https://queenbee.netlify.app/zh/docs/6-contribute/roadmap/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://queenbee.netlify.app/zh/docs/6-contribute/roadmap/</guid><description>
&lt;h3 id="v10">v1.0&lt;/h3>
&lt;h3 id="v11-next-release">v1.1 Next Release&lt;/h3>
&lt;h2 id="history">History&lt;/h2></description></item><item><title>Docs: 技术架构</title><link>https://queenbee.netlify.app/zh/docs/6-contribute/arch/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://queenbee.netlify.app/zh/docs/6-contribute/arch/</guid><description>
&lt;p>在贡献代码前，您可能需要了解 BeeFog 的架构。总体架构在第一章简介中有介绍，
这里会详述控制中心 QueenBee 的系统架构。&lt;/p>
&lt;h2 id="queenbee-技术架构">QueenBee 技术架构&lt;/h2>
&lt;p>BeeFog 的系统模块架构如下图所示，其中方块为模块，连线为模块间调用关系。&lt;/p>
&lt;p>&lt;img src="https://queenbee.netlify.app/images/arch-zh.png" alt="架构图">&lt;/p>
&lt;h3 id="工作节点--worker-bees-">工作节点 [ Worker Bees ]&lt;/h3>
&lt;ul>
&lt;li>BeeFog 的工作节点可以部署在服务器，PC或手机等各种设备之上。&lt;/li>
&lt;li>有的独立 Worker 单纯的只完成 BeeFog 的工作。在 PC 和移动设备上，大多是集成 Worker SDK 的 APP，在用户使用时就可以进行工作。&lt;/li>
&lt;li>工作节点的行为是完全主动的，在自己有空闲时，会向控制中心请求任务。&lt;/li>
&lt;li>在完成任务后，会将结果状态报告给控制中心。报告时也可能根据任务配置携带结果数据。&lt;/li>
&lt;li>任务执行会有时间限制，在超时后，控制器会将任务分给别的节点执行，不再接收此次任务的结果报告。&lt;/li>
&lt;/ul>
&lt;h3 id="控制中心--queen-bee-">控制中心 [ Queen Bee ]&lt;/h3>
&lt;p>控制中心被分为多个模块。模块之间通过接口暴露的函数调用。有几个模块会开放 REST API 供用户使用。&lt;/p>
&lt;h4 id="工作设备管理器--worker-manager-">工作设备管理器 ( Worker Manager )&lt;/h4>
&lt;ol>
&lt;li>提供工作设备注册接口。工作设备每次上线通过提供 &lt;code>节点组 Code&lt;/code> 在管理器注册，换取 &lt;code>Token&lt;/code> 用以后续其他请求的认证。&lt;/li>
&lt;li>管理器可以通过 &lt;code>Token&lt;/code> 辨识来源设备并记录所有设备的状态。&lt;/li>
&lt;li>提供查看工作设备汇总状况的 REST API 供用户使用。&lt;/li>
&lt;/ol>
&lt;h4 id="任务定义管理器--job-manager-">任务定义管理器 ( Job Manager )&lt;/h4>
&lt;ol>
&lt;li>存储和管理任务定义&lt;/li>
&lt;li>提供查询、新增、修改和删除任务定义的 REST API 供用户使用。&lt;/li>
&lt;/ol>
&lt;h4 id="任务调度中心--job-dispatcher-">任务调度中心 ( Job Dispatcher )&lt;/h4>
&lt;ol>
&lt;li>提供调用任务和查看实例状态的 REST API 供用户使用。&lt;/li>
&lt;li>提供调用任务的接口供系统内部使用。&lt;/li>
&lt;li>工作设备请求任务和汇报任务结果的接口。&lt;/li>
&lt;li>任务每次被调用，都会产生一个运行实例(Run)。调度中心负责维护并保存实例整个生命周期的状态。&lt;/li>
&lt;li>任务在被调用后，未被分配给工作设备前，存储在一个任务池中。调度中心还要负责任务分配的匹配检验与优先逻辑。&lt;/li>
&lt;li>任务在工作设备完成并报告后，可能还有需要在调度中心执行的步骤，比如发送通知等。&lt;/li>
&lt;/ol>
&lt;h4 id="自动任务触发器--automation-trigger-">自动任务触发器 ( Automation Trigger )&lt;/h4>
&lt;p>任务除了使用接口直接调用，还可以预设一定的规则去触发，比如定时触发或根据云端的一个文件状态去触发等等。本模块管理触发规则并实施触发。&lt;/p>
&lt;ol>
&lt;li>监听任务定义中新增或修改了触发器的事件，在服务中维护触发器。&lt;/li>
&lt;li>实施自动触发任务。&lt;/li>
&lt;li>任务触发器如果想要支持分布式部署，开发难度极高，所以本模块为独立部署的一个单例服务。&lt;/li>
&lt;/ol>
&lt;h2 id="基础设施">基础设施&lt;/h2>
&lt;p>我们使用了以下基础设施：&lt;/p>
&lt;ul>
&lt;li>Mysql 用以数据存储&lt;/li>
&lt;li>Redis 用以缓存&lt;/li>
&lt;li>NSQ 用以事件发布和监听&lt;/li>
&lt;/ul></description></item><item><title>Docs: Worker Manager</title><link>https://queenbee.netlify.app/zh/docs/6-contribute/worker-manager/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://queenbee.netlify.app/zh/docs/6-contribute/worker-manager/</guid><description>
&lt;h2 id="主要工作">主要工作&lt;/h2>
&lt;ul>
&lt;li>一个测速接口让节点可以测速决定连接哪个区域的 Queen&lt;/li>
&lt;li>一个注册接口让节点可以在启动是简单上报自己的情况&lt;/li>
&lt;/ul></description></item><item><title>Docs: 数据模型</title><link>https://queenbee.netlify.app/zh/docs/6-contribute/data-model/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://queenbee.netlify.app/zh/docs/6-contribute/data-model/</guid><description>
&lt;h2 id="任务定义--task-">任务定义 [ Task ]&lt;/h2>
&lt;p>任务是本系统中最重要的概念，它描述了一个任务的整个生命周期的配置。&lt;/p>
&lt;h4 id="元数据--meta-">元数据 ( Meta )&lt;/h4>
&lt;p>任务 ID，名称，创建时间等等各种管理信息。&lt;/p>
&lt;h4 id="节点要求--scope-">节点要求 ( Scope )&lt;/h4>
&lt;p>用一个字符串列表表示对于节点的能力要求。&lt;/p>
&lt;h4 id="输入--inputs-">输入 ( Inputs )&lt;/h4>
&lt;p>调用一个任务时的输入描述，分为必须提供的和可选提供的。&lt;/p>
&lt;h4 id="工作节点步骤--worker-steps-">工作节点步骤 ( Worker Steps )&lt;/h4>
&lt;p>工作节点将顺次执行每个步骤。&lt;/p>
&lt;p>所有支持的步骤详见步骤类型章节。&lt;/p>
&lt;h4 id="服务端步骤--queen-steps-">服务端步骤 ( Queen Steps )&lt;/h4>
&lt;p>在任务结果返回云端后，云端也可以选择执行一些步骤。&lt;/p>
&lt;h2 id="任务实例--instance-">任务实例 [ Instance ]&lt;/h2>
&lt;p>每当调用一个任务，就会生成一个任务实例。任务实例除了携带任务定义外，还会有以下内容。&lt;/p>
&lt;h4 id="输入--inputs--1">输入 ( Inputs )&lt;/h4>
&lt;p>任务所需的输入。&lt;/p>
&lt;h4 id="额外节点要求--extrascope-">额外节点要求 ( ExtraScope )&lt;/h4>
&lt;p>调用任务时可以提出对工作节点的额外要求，用以提供对任务进行编排的可能。&lt;/p>
&lt;p>额外要求会与任务定义内的要求取并集，当是节点 Scope 子集的时候才能成功匹配。
比如可以要求匹配一个地理位置必须在四川，要有执行浏览器任务的能力，今天还没有执行过这个任务的节点。&lt;/p>
&lt;h4 id="上下文--context-">上下文 ( Context )&lt;/h4>
&lt;p>上下文会携带任务发起方的一些信息。后面我们会知道，任务执行时也可以触发新的任务实例，所以 Context 有可能在任务中链式传递。&lt;/p>
&lt;h2 id="任务结果--result-">任务结果 [ Result ]&lt;/h2>
&lt;p>任务结果是任务在工作节点执行后生成的一个结果对象，它会被返回云端等待后续处理。&lt;/p>
&lt;p>结果默认状态下只有成功或失败的状态，若失败时可能携带错误信息。若任务定义中要求返回一些结果数据，也会返回。&lt;/p>
&lt;h2 id="任务触发器--trigger-">任务触发器 [ Trigger ]&lt;/h2>
&lt;p>除了利用接口调用任务，还可以配置多种自动触发并调用任务的触发器。
一个任务可以被配置多个触发器。&lt;/p>
&lt;p>目前支持如下类型的触发器：&lt;/p>
&lt;h4 id="计划任务--cron-">计划任务 ( Cron )&lt;/h4>
&lt;p>通过配置一个 Cron，并指定输入，可以配置一个定时执行的计划任务。&lt;/p></description></item></channel></rss>