机器人弹性伸缩算法-专利技术交底书

机器人弹性伸缩算法-专利技术交底书

缩略语和关键术语定义
1、 SaaS平台是运营saas软件的平台。SaaS提供商为企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台，并负责所有前期的实施、后期的维护等一系列服务，企业无需购买软硬件、建设机房、招聘IT人员，即可通过互联网使用信息系统。
2、 PAAS平台即(Platform-as-a-Service：平台即服务)，把应用服务的运行和开发环境作为一种服务提供的商业模式。
3、 RPA （Robotic Process Automation） ：机器人流程自动化，又可以称为数字化劳动力（Digital Labor），是一种智能化软件，通过模拟并增强人类与计算机的交互过程，实现工作流程中的自动化。
4、 网络爬虫（又被称为网页蜘蛛，网络机器人，在FOAF社区中间，更经常的称为网页追逐者），是一种按照一定的规则，自动地抓取万维网信息的程序或者脚本。

1、与本发明最相近似的现有技术方案
1.1现有技术的技术方案
现有的云服务应用提供商（Saas）往往采用租赁方式购买云服务平台提供商（Paas）的云服务资源,如：云端的虚拟机等为自己的客户提供云服务。Paas提供商中例如：金山云，阿里云，腾讯云等。Paas供应商往往提供了一套管理工具给用户，也会提供API接口来动态申请开通或申请销毁虚拟机，让他们方便地管理自己租用的云服务器。
在实际的业务中，SaaS企业部署的云服务可能会随着业务的增长而出现资源瓶颈，往往的表现是，服务无法响应，客户的请求反应缓慢等症状，这时，往往需要SaaS企业安排技术人员去申请新的资源，以适应新的需求。但是业务往往是带有周期性质的，往往在经过一段高峰时期的使用后，会出现业务的低潮期，这时候，先前申请的系统资源会大面积的出现闲置，这显然是一种资源浪费，于是技术人员又会申请取消多余的资源。如果这种周期性很频繁，往往会使得SaaS企业的技术人员任务浪费大量的去处理这类事务，而且往往是在事后（已经出现资源瓶颈或长时间大量闲置）才处理，导致客户满意度下降或公司资源浪费。

1.2现有技术的缺点、本发明会解决的问题及达到的效果
采用人为方式去控制Paas平台的资源数量，往往是在事后（已经出现资源瓶颈或长时间大量闲置）处理，导致客户满意度下降或公司资源浪费。
本发明采用特定算法，实现了Paas平台资源的自动伸缩；
2、本发明技术方案的详细阐述（应结合流程图、时序图、原理图等附图进行说明）
本发明以一个自动报税系统为实例，展示具体的虚拟机自动伸缩算法。

上图展示了本发明的一个实例的场景（自动报税系统）的整体架构和主要流程：
构成该报税系统的主要部件：
上图展示了本发明的整体架构和主要流程：
构成该报税系统的主要部件：
1.报税客户端：安装在用户PC上的一个客户端程序。（这部分也可以使用BS架构的WEB应用程序代替）主要的功能是提供给用户一个操作交互的界面，用于用户填写报税客户的资料，发起报税任务和展示报税任务执行结果等功能。
2.任务队列：部署在云端的服务程序。当客户端提交报税任务后，任务队列保存/缓存报税任务的相关信息，并在调度中心请求可执行任务时，返回可执行的任务信息。
3.调度中心：部署在云端的服务程序。主要功能是按照系统既定规则分配报税任务，或是跟进当前任务数与报税机器人的数量判断是否发起增加或减少报税机器人的请求；
4.报税机器人池：由多台虚拟机构成的集群。主要功能是在对应的虚机上运行RPA脚本或是爬虫服务程序，完成具体报税相关任务，并将执行的结果回写任务队列，更新对应任务的状态；

本发明的详细技术方案要点：
1.用户使用客户端发起申报、更正申报、作废申报、缴款等请求；
2.服务端接收客户请求并加入任务队列；任务队列的存储介质为数据库(如：MYSQL,MS SQL Server,Oracle, redis等)；
3.报税机器人池是由多台独立的云端虚拟机组成；报税机器人分为2类：RPA报税机器人和爬虫服务机器人。RPA报税机器人主要用于执行需要特定客户端的任务，例如:自然人税收管理系统扣缴客户端(个税申报客户端)；爬虫报税机器人主要用于基于浏览器访问的服务，例如：企业所得税申报；
4.报税机器人轮询调度中心去获取待执行的任务；
5.调度中心接收报税机器人的请求后查询任务队列是否有待执行的任务，如有，则返回任务给报税机器人执行，报税机器人执行任务，并将结果反馈保存在任务队列对应的数据库中，下一次客户端查询任务执行状态将得到任务执行结果的反馈；否则，返回空，报税机器人进入下一个轮询周期；
6.调度中心会根据提交任务的对应公司，提交的任务数，根据特定算法（餐厅上菜算法）分配报税机器人执行特定地任务；
餐厅上菜算法具体算法逻辑如下：
先用一个形象的场景说明一下这个算法的思想。假设有一家生意很火爆的餐厅，每到饭点就餐的人都很多，就餐的顾客往往都需要排队等候一段时间才能入座就餐，为了让每位顾客都有较好的就餐体验，餐厅老板对厨师和服务员做了如下约定：当有新的顾客入座时，除了厨师们正在炒的菜以外，应优先安排为新入座的顾客上第一份菜，后续根据每位尚未上完菜的顾客上一次上菜的时间排序，等候时间最长的顾客的菜优先做。
上述例子中，已经就坐等候的就餐的顾客可以看做是提交了一批申报任务的用户，提交的任务就是顾客确定的菜单，报税机器人就是炒菜的厨师，任务执行的结果就是炒好的菜送到了顾客的餐桌上，而整个炒菜的调度算法就是餐厅老板定下的炒菜规则，这些规则统一由老板娘（调度中心）来负责监督执行。餐厅的每一位厨师都是在上班时间永不知道疲倦的劳模，每当他们抄完一个菜，就会立即通知服务员（数据反馈接口）给顾客上菜，然后让另一个服务员马上去问老板娘，下一个菜炒什么？由于服务员给客户上菜后，都会顺便给老板娘汇报一下对应顾客已经上过的菜以及上菜的时间。老板娘是餐厅规则的坚定践行者，也是个特别会统筹的人。她将每位就坐后顾客提交上来的菜单分为了三摞：A.“新就坐还未上菜的顾客”,B.“有厨师正在炒”，C.“菜已上完”
每当有一桌新的顾客就坐并点菜后，服务员会把顾客的菜单交给老板娘，老板娘会把交来的菜单放在A摞的最上面。
当服务员每次汇报上菜的结果时，老板娘会从B摞菜单中找到对应的客户菜单（由于做每个菜需要时间可能不同，所以先做的菜不一定先做好），把最近上的一个菜做一个标记，并把这张菜单放在B那一摞菜单的最上面。但是如果这位顾客的菜已经上完，老板娘便会把这张菜单放到C摞上面。
因此当带着厨师询问的服务员问老板娘下一个菜炒什么的时候，老板娘会瞄一下手头上菜单的情况，如果A摞菜单有，老板娘会抽出A摞菜单最下面的一张，选一个菜（随机查找）告诉服务员，然后把这个菜单放到B摞最上面。如果A摞菜单没有了，就从B摞菜单中，抽出最下面的一张，选一个菜告诉服务员，然后把这张菜单放到B摞的最上面。
经过一段时间运营餐厅上菜规则在实践中遇到了一些现实的问题。来就餐的客户常常会出现公司聚餐的情况，这时候一个单位顾客往往会点很多菜，如果让这些客户依然跟其它个人客户一样一个菜一个菜的上，那显然也不合适了，因此，老板娘想了个办法，
她把B摞客户剩余未炒的菜全部写成小纸条：X顾客的Y菜品，然后把它们放到一个黑箱子中。每次服务员来问下一个菜炒什么的时候，就从黑箱子中随机抽一个纸条出来，递给服务员。这样那些点菜多的顾客，每次有厨师空闲时，被选中的概率就会大一些，这样也尽可能的保证了这些客户上菜的频率。

任务重试机制：餐厅虽然口碑很好，但是偶尔也会遇到一些很挑剔的顾客，他们会抱怨炒出菜不符合他们的口味（任务执行失败），餐厅的老板为了提升客户的体验，规定只要顾客认为菜不合胃口，每个菜可以重新帮客户做，但考虑到成本，每个菜最多重做三次。但是对于那种无理取闹的顾客，比如明明点了一个黄焖鸡，上完菜后顾客却说他点的是红烧狗肉。（数据错误导致的失败）餐厅由于有菜单作为证据，因此这类客户要求重做的要求坚决不予理会。
任务超时处理机制：由于管理机制，餐厅为每一个厨师配备了独立的厨房，每个厨房相互独立，厨师平时都只靠服务员传话，厨师之间在工作时间不能互相交流。由于餐厅的厨师们都太过敬业，可能导致积劳成疾，偶尔也会有厨师在炒菜的过程中突然抽风，然后默默地晕倒在了厨房。餐厅的老板注意到了这个问题，于是在每个厨师的门口安装了一个闹钟计时器，规定厨师每开始做一个菜就将闹钟计时器重置一下。如果厨师在炒菜过程中超过了规定的最大时长还未通知服务员来领取炒好的菜，那么闹钟就会响起。这时，老板娘就知道厨师出状况了，她会立即派服务员反馈给对应顾客，说为了做出的饭菜更美味，需要客户再稍等片刻，同时，安排另外一个厨师为客户接着做这道菜。当然，如果做的这道菜，连续让三个厨师出现抽风，那很有可能是这道菜的材料有缺陷，餐厅会告知顾客，今天这道菜由于XX原因无法做出，请客户体谅。

7.报税机器人池弹性伸缩：报税机器人池会根据资源的负荷确定是否动态的增加或减少机器人数量；
继续使用上面的场景来解释这个问题：
经过一段时间的经营，餐厅的口碑已经爆棚，来就餐的人越来越多，排的队也越来越长，顾客要吃到一餐饭平均的等待时间也越来越长，与之形成鲜明对比的是，方圆2公里内的其它餐厅却门可罗雀，餐厅老板为了更好地拓展业务，于是与周围的餐馆达成了一项协议，在用餐高峰期，周围的其它餐馆采用租赁模式将自己的厨师租用给老板（按租时计费），老板则将厨师炒菜的流程进行了全面标准化（虚拟机镜像）。
老板在餐厅门口修了一个大大的侯餐等候区，每位来吃饭的顾客可以先到前台排队机那里拿一个号，并让顾客预先点好菜，这样，老板娘就可以随时知道目前的等候的顾客数量和预期预炒的菜的数量。
老板娘设置了一套租用其它餐厅厨师的规则：
设目前已雇用所有厨师数量为X；
设总店等待中没有活干的厨师数量为Z（已开启且空闲的机器人数量）；
设所有顾客尚未做的菜的数量为D；
老板娘专门安排一些服务员每过一个周期汇报一次空闲厨师数量和剩余菜数量（定时轮询）；
当服务员连续两个周期汇报，Z=0且D>X时,说明厨师不够用了，则向其它店申请租用厨师;
由于租用厨师是短时间租用，单位成本比总店高，因此希望每个厨师被租用后至少能炒R个菜；
那么为了能够尽量少的让客户等待，在每次申请租用厨师时，应该满足如下条件：已雇用厨师X+待租用厨师Z=（D-X）/R,即当雇用完一批新的厨师后，所有厨师每个大概再炒R个菜，就能将现在所有顾客剩余的菜炒完。
即Z=（D-X）/R –X ,但是厨师是有人数上限的，假设这个上限设为Max，那么上述公司的得到的结果Z应<=Max,否则，Z=Max。
当租用了一批新的厨师上岗后，在接下来的R个周期内，服务员不再向老板娘汇报空闲的厨师数量和剩余未做菜数量；
当服务员开始恢复定期汇报空闲厨师数X和剩余菜数量D时，（这个过程有可能不断有新的顾客光临），有可能就会发现有部分厨师已经没有活干了，即D<X,这时，老板娘会宣布与部分租用厨师解除租用关系。
总店的厨师不能随便解除雇佣，（即有一个最低机器人数量，用于应付可能突然到来的任务），他们会继续敬业地为老板服务。设总店的厨师数为Min。
那么解除租用的算法为：
当D<X超过两个汇报周期时，计划解除雇佣的厨师数S=X-D，且应满足X-S>= Min,则即S<=X –Min.

3、 本发明技术方案中的必要技术点及辅助技术点（关键点、创新点、需要保护的点）
3.1必要技术点

1. 本发明所提及的机器人弹性伸缩算法；
   3.2辅助技术点
   无
   4、 针对本发明的技术方案，是否还有其他别的替代方案
   无
   5、本发明的优点
2. 本发明在待执行的任务大于报税机器人数量一定时间后，会动态的增加报税机器人的数量，从而在高峰时期提高申报的并行效率；
3. 本发明在待执行任务很少，有大量报税机器人空闲时，会动态销毁报税机器人对应的虚机数量，从而达到节约系统资源的目的；