具体实施方式

下面将参考若干示例性实施方式来描述本说明书实施例的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本说明书实施例，而并非以任何方式限制本说明书实施例的范围。相反，提供这些实施方式是为了使本说明书实施例公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域的技术人员知道，本说明书实施例的实施方式可以实现为一种系统、装置设备、方法或计算机程序产品。因此，本说明书实施例公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

虽然下文描述流程包括以特定顺序出现的多个操作，但是应该清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

请参阅图1，本实施方式可以提供一种系统部署方法，可以应用于分布式系统。该系统部署方法可以用于将不同的子系统的前端页面分开部署至不同的服务节点，隔离各个子系统的代码，降低了子系统之间的耦合度。上述系统部署方法可以包括以下步骤。

S101：获取目标部署信息集；其中，目标部署信息集中包含目标子系统的程序包和特征参数。

在本实施方式中，可以获取目标部署信息集。其中，上述目标部署信息集可以为待进行部署的子系统的相关信息集，目标部署信息集中可以包含目标子系统的程序包和目标子系统的特征参数。上述目标子系统的程序包可以为压缩包，也可以为文件，具体的可以根据实际情况确定，本说明书实施例对此不作限定。

在本实施方式中，开发人员在完成子系统的项目代码开发后，可以将代码进行编译，并打包成zIP(压缩包)。开发人员可以进入服务管控中心页面，将子系统的程序zIP包进行上传，并在服务管控中心页面填写子系统的特征参数。开发人员通过点击提交按钮，可以将子系统的程序zIP包和子系统的特征参数进行提交，并同时生成部署请求。

在本实施方式中，部署请求中可以包含子系统的程序zIP包和子系统的特征参数，部署请求可以放入线程中等待处理。对应的，服务器在接收到部署请求时，在确定当前可以处理的情况下，可以解析获取到目标部署请求中的目标部署信息集。

在本实施方式中，上述目标子系统的特征参数可以用于表征目标子系统的属性信息。在一些实施例中，上述特征参数可以包括：子系统名、所需节点个数、灰度策略、子系统描述、版本号等，当然可以理解的是，上述特征参数还可以包含其它信息，例如：所述项目名称等，具体的可以根据实际情况确定，本说明书实施例对此不作限定。

S102：在根据目标子系统的特征参数确定目标子系统为新增子系统的情况下，确定部署目标子系统的至少一个目标服务节点；其中，目标服务节点为未部署过子系统的服务节点。

在本实施方式中，由于前端采用单页面(single-page-application)架构，当部署多个子系统时，子系统间互相联动复杂，需要嵌套各种页面，开发和部署成本高昂，其中许多代码重复度高，互相耦合，可维护性差。因此，可以将各个子系统的前端页面分开部署至各个服务器，一个服务器对应一个服务节点。

在本实施方式中，可以预先根据目标子系统的特征参数确定目标子系统是否为新增子系统，如果目标子系统和当前正在运行的子系统重名，则说明目标子系统不是新增子系统，反之则是。

在本实施方式中，在确定目标子系统为新增子系统的情况下，可以确定部署所述目标子系统的至少一个目标服务节点。其中，由于需要将不同的子系统部署至不同的服务节点，因此，上述目标服务节点可以为未部署过子系统的服务节点，上述目标服务节点可以为新增的服务节点。

在本实施方式中，可以是根据目标子系统所需的服务节点数量确定目标服务节点的数量，从而新增对应数量的服务节点，得到目标服务节点。在一些实施例中，也可以根据当前系统中可用的服务节点数量，确定目标服务节点的数量，从而得到目标服务节点。当然，目标服务节点确定的方式不限于上述举例，所属领域技术人员在本说明书实施例技术精髓的启示下，还可能做出其它变更，但只要其实现的功能和效果与本说明书实施例相同或相似，均应涵盖于本说明书实施例保护范围内。

S103：根据目标子系统的程序包，将目标子系统部署至至少一个目标服务节点中。

在本实施方式中，可以根据目标子系统的程序包，将目标子系统部署至上述至少一个目标服务节点中，以使上述至少一个服务节点均可以执行目标子系统的功能。

S104：将至少一个目标服务节点注册到总路由节点。

在本实施方式中，可以将至少一个目标服务节点注册到总路由节点，以使在用户访问系统时，统一通过访问总路由节点来获取前端页面资源来展示首屏(首屏指用户访问的第一个页面)，并通过总路由节点统一调度用户提交的请求，以转发到对应的服务节点进行处理。从而可以将系统部署简化统一，开发人员只需考虑新增子系统内部的代码，通过提交程序包即可一键部署完成。使得网页前端的治理简化，逻辑清晰，可维护性高，解决了子系统开发部署成本高的问题。

在本实施方式中，各个子系统之间可以使用不同的前端框架，例如：子系统A使用React框架，子系统B使用Vue框架。从而可以按照需求使用不同的框架以获得不同框架的优点，历史项目集成的话也不需要改框架代码，修改下即可集成。不同框架之间可以通过JS(JavaScript)、CSS(Cascading Style Sheets，层叠样式表)资源隔离来防止代码互相污染。可以通过监听URL(Uniform Resource Locator，统一资源定位符)的变化来控制展示对应的子系统，例如：http://a.com/systemA将展示子系统A，http://a.com/systemB将展示子系统B。

在本实施方式中，React是一个用于构建用户界面的JavaScript库，Vue框架是一套用于构建用户界面的渐进式框架。JavaScript是一种高级的、多范式、解释型的编程语言，是一门基于原型、函数先行的语言，它支持面向对象编程、命令式编程以及函数式编程。

从以上的描述中，可以看出，本说明书实施例实现了如下技术效果：可以获取目标部署信息集，其中，目标部署信息集中可以包含目标子系统的程序包和特征参数。在根据所述目标子系统的特征参数确定所述目标子系统为新增子系统的情况下，可以确定部署所述目标子系统的至少一个目标服务节点，上述目标服务节点可以为未部署过子系统的服务节点。可以根据所述目标子系统的程序包，将所述目标子系统部署至所述至少一个目标服务节点中，从而可以将不同的子系统的前端页面分开部署至不同的服务节点，隔离各个子系统的代码，降低了子系统之间的耦合度，使得开发人员只需考虑新增子系统内部的代码，有效简化了开发人员的工作量。进一步的，将所述至少一个目标服务节点注册到总路由节点，从而可以通过总路由节点进行统一管理，进而可以将系统放入部署简化统一，可以高效地实现网页前端子系统的开发部署。

在一个实施方式中，在获取目标部署信息集之后，还可以包括：在根据所述目标子系统的特征参数确定所述目标子系统不是新增子系统的情况下，将正在运行的子系统对应的各个服务节点停机。可以确定部署所述目标子系统的至少一个目标服务节点；其中，所述目标服务节点为历史部署过目标子系统的服务节点。进一步的，可以根据所述目标子系统的程序包，将所述目标子系统部署至所述至少一个目标服务节点中。将所述至少一个目标服务节点注册到总路由节点，并启动所述至少一个目标服务节点和所述正在运行的子系统对应的各个服务节点。

在本实施方式中，如果不是新增子系统，则可以对当前正在运行的子系统对应的各个服务节点进行停机。并判断需要停机的子系统对应的各个服务节点是否停机完成，在确定全部停机完成的情况下，可以将目标子系统的程序包进行解压，并部署至所述至少一个目标服务节点中。

在本实施方式中，在确定成功将至少一个目标服务节点注册到总路由节点之后，可以，启动所述至少一个目标服务节点和所述正在运行的子系统对应的各个服务节点，从而完成对目标子系统的部署。

在本实施方式中，由于目标子系统不是新增子系统，因此，为了确保服务的完整提供，可以直接部署至历史部署过目标子系统的服务节点中。当然可以理解的是，在历史部署过目标子系统的服务节点的数量不够时也可以新增服务节点，以用于部署目标子系统。具体的可以根据实际情况确定，本说明书实施例对此不作限定。

在一个实施方式中，目标子系统的特征参数可以包括：目标子系统名、所需服务节点个数，在获取目标部署信息集之后，还可以包括：获取所述总路由节点上正在运行的子系统信息，并根据所述目标子系统名和所述正在运行的子系统信息，确定所述目标子系统是否为新增子系统。

在本实施方式中，由于部署子系统的服务节点均需注册到总路由节点，因此，可以获取所述总路由节点上正在运行的子系统信息。上述子系统信息中可以包含子系统名。当然可以理解的是，上述子系统信息中还可以包含其它信息，例如：对应的服务节点、版本号等。具体的可以根据实际情况确定，本说明书实施例对此不作限定。

在本实施方式中，如果正在运行的子系统信息存在与目标子系统名相同的子系统，则说明目标子系统不是新增子系统，历史已经部署过。反之，则说明目标子系统为新增子系统。

在一个实施方式中，所述目标子系统的特征参数还可以包括：目标灰度策略，在获取目标部署信息集之后，还可以包括：将所述目标子系统名和所述目标灰度策略写入目标数据库的灰度策略表中；其中，所述灰度策略表中可以包含：策略ID、子系统名、灰度控制字段、控制字典值、用户灰度关联表、服务节点灰度关联表，用户灰度关联表中包含用户ID和策略ID，服务节点灰度关联表中包含服务节点IP地址和策略ID。

在本实施方式中，目标子系统的特征参数还可以包括：目标灰度策略，灰度策略可以用于描述什么请求应该路由到灰度版本(灰度服务器)中，灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式，例如：让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

在本实施方式中，每个灰度策略可以对应一个策略ID(身份标识)，一个策略ID可以唯一确定一个灰度策略。IP地址全称为网际协议地址，是一种在因特网上的给主机编址的方式。上述用户ID可以为用户的唯一标识，例如：用户名称、身份证号等。具体的可以根据实际情况确定，本说明书实施例对此不作限定。

在本实施方式中，目标数据库可以为总路由节点用于存储数据的数据库，也可以为分布式系统中用于存储数据的数据库，具体的可以根据实际情况确定，本说明书实施例对此不作限定。

在一个实施方式中，在将所述至少一个目标服务节点注册到总路由节点之后，还可以包括：在所述总路由节点接收到目标用户发出网页请求的情况下，根据所述网页请求确定目标用户ID、子系统名。获取所述灰度策略表，并利用所述目标用户ID、子系统名和所述灰度策略表，确定需要采用的灰度策略的目标策略ID。进一步的，可以根据所述目标策略ID和所述灰度策略表，确定所述目标策略ID对应的服务节点，并将所述网页请求转发至所述目标策略ID对应的服务节点。

在本实施方式中，由于目前涉及灰度用户访问灰度功能时，需要多次访问多个后端服务器获取灰度标签，管理复杂，且灰度标志来源前端使得灰度策略不完全可信，可被用户自行破解。具体的，用户在进入页面后，第一次请求会获取对应后端服务器的属于该用户的灰度标签，可以将返回的灰度标签放入客户端浏览器的缓存中，后续请求根据该浏览器缓存的灰度标签，将请求转发到对应的灰度后端服务器。在该场景下，用户可以通过手动更改浏览器缓存来切换灰度状态，使得系统存在灰度管理的风险。因此，为了解决该问题，可以由总路由节点统一处理用户提交的网页请求，可以获取网页请求中登录用户的会话ID来获取该用户所对应的灰度策略，最终将请求转发到对应的灰度服务器。该方法避免了用户修改灰度标签的可能，用户将无法控制自身的灰度状态，解决了灰度方案安全性低的问题。

在本实施方式中，总路由节点在接收到网页请求的情况下，可以解析网页请求的HTTP报文，从而得到用户会话ID(用户会话ID通常为session ID)、子系统名、URL。可以根据用户会话ID从后端服务器中获取到目标用户ID。其中，HTTP(超文本传输协议)是用于从万维网服务器传输超文本到本地浏览器的传送协议。

在本实施方式中，可以通过查询目标数据库获取灰度策略表，从而可以利用目标用户ID、子系统名、URL和所述灰度策略表，确定出需要采用的灰度策略的目标策略ID。进一步的，可以根据服务节点灰度关联表，根据目标策略ID，确定所述目标策略ID对应的服务节点。其中，目标策略ID对应的服务节点可以为灰度服务器。

在本实施方式中，可以将网页请求转发到目标策略ID对应的服务节点，例如：根据用户所属地区做灰度，只有地区A的用户可以访问功能A，通过上述实施例可以根据地区灰度策略，将地区A的用户请求转发至带有功能A的服务节点。

在一个实施方式中，在将所述至少一个目标服务节点注册到总路由节点之后，还可以包括：在所述总路由节点接收到目标用户发出网页请求的情况下，根据所述网页请求确定子系统名。可以通过所述总路由节点获取当前注册的服务节点集合，遍历所述当前注册的服务节点集合，确定所述子系统名对应的服务节点。进一步的，可以将所述网页请求转发至所述子系统名对应的服务节点。

在本实施方式中，总路由节点在接收到外部的网页请求的情况下，可以从网页请求中解析出网页请求的请求URL，得到子系统名。进一步的，可以通过所述总路由节点获取当前注册的服务节点集合，并遍历当前注册的服务节点集合。如果当前注册的服务节点集合中存在与子系统名相同的服务节点，则说明该服务节点为子系统对应的服务节点，可以将所述网页请求转发至所述子系统名对应的服务节点。

在本实施方式中，可以实时确定当前注册的服务节点集合是否遍历完成，如果在确定遍历完成的情况下仍没有确定出子系统名对应的服务节点，则可以返回网页请求404报文。其中，404报文可以用于表示访问的指定资源不存在，以进行错误提示。

在一个实施方式中，在将所述至少一个目标服务节点注册到总路由节点之后，还可以包括：在所述总路由节点接收到目标用户发出网页请求的情况下，将所述网页请求转发至渲染服务节点。所述渲染服务节点可以根据所述网页请求的报文获取初始html文件和JS代码文件；其中，所述初始html文件为未渲染界面的html文件。进一步的，所述渲染服务节点通过解析所述JS代码文件渲染所述初始html文件，得到渲染完成的html页面，并将所述渲染完成的html页面反馈给所述目标用户。

通常页面将JS代码渲染成html页面需要依赖客户端浏览器，由于首屏需要大量计算机算力来进行渲染，故浏览器会较长时间白屏，甚至卡顿，降低了用户体验。在本实施方式中，可以将客户端浏览器渲染计算迁移至计算力强大的渲染服务节点中，以减轻用户计算机硬件使用压力，并且可以将渲染服务节点纳入集群治理，防止流量高峰时由于渲染服务器的卡顿导致系统崩溃，解决了首屏加载速度慢的问题。

在本实施方式中，渲染服务节点可以解析网页请求的报文，网页请求的报文中可以包含目标URL和业务参数报文。可以根据目标URL获取到服务节点的初始html文件和JS代码文件，其中，初始html文件为未渲染界面的html文件。渲染服务节点可以将JS代码进行解析并渲染html文件，从而可以高效地返回渲染完成的html页面给目标用户。其中，html(Hyper Text Markup Language，超文本标记语言)是标准通用标记语言下的一个应用。

在一个实施方式中，在将所述至少一个目标服务节点注册到总路由节点之后，还可以包括：所述总路由节点按照预设时间间隔请求已注册的各个服务节点的检查接口，将不能与所述总路由节点建立连接的服务节点作为异常服务节点，得到异常服务节点集合，并断开所述总路由节点与所述异常服务节点集合中各个异常服务节点的连接。

在本实施方式中，可以通过总路由节点按照预设时间间隔对各个服务界定啊进行健康检查，具体的，总路由节点可以按照预设时间间隔请求已注册的各个服务节点的检查接口。其中，上述预设时间间隔可以为大于0的数值，例如：30秒、10分钟、1小时等，具体的可以根据实际情况确定，本说明书实施例对此不作限定。

在本实施方式中，每次健康检查可以均生成一个正常服务节点集合和异常服务节点集合，在初始第一次进行健康检查时得到的正常服务节点集合和异常服务节点集合可以存入缓存中。后续在每次进行健康检查时，可以先获取缓存中的正常服务节点集合和异常服务节点集合，并遍历正常服务节点集合，判断正常服务节点集合中的当前服务节点是否能和总路由节点建立连接，如果不能则将该服务节点从正常服务节点集合中移除，并将该服务节点加入异常服务节点集合中。

在本实施方式中，可以断开总路由节点与异常服务节点集合中各个异常服务节点的连接，使得总路由节点后续不会再将用户请求转发至异常服务节点集合中的服务节点。

在本实施方式中，还可以遍历从缓存中获取的异常服务节点集合，判断异常服务节点集合中当前遍历的服务节点是否能和总路由节点建立连接，如果可以则将该服务节点从异常服务节点集合中移除，并将该服务节点加入正常服务节点集合中；如果不可以则将该服务节点继续保留在异常服务节点集合中，从而可以得到本次健康检查的正常服务节点集合和异常服务节点集合。进一步的，可以更新缓存中的正常服务节点集合和异常服务节点集合，以存储最新的正常服务节点集合和异常服务节点集合。

在一个实施方式中，在将所述至少一个目标服务节点注册到总路由节点之后，还可以包括：获取所述总路由节点的流量负载信息，在根据所述流量负载信息确定所述总路由节点的流量负载达到预设阈值的情况下，横向增加总路由节点的数量。

在本实施方式中，由于部署子系统的服务节点较多，每次部署更新程序，需要一台台服务器去上传程序并输入启动命令，使得部署程序运维工作量大。因此，需要通过总路由节点进行服务节点健康检查及灰度总控，及时检测异常服务节点并根据实时流量负载信息对服务器节点进行动态扩容或者缩容。从而可以通过集群治理将所有节点纳入管控，可以一键部署系统程序，解决了部署程序运维工作量大的问题，实现了针对网页前端分布式治理。

在本实施方式中，可以获取当前总路由节点的流量负载信息，其中，流量负载信息可以包含每秒并发访问数量、CPU(中央处理器)频率、内存占用量等。进一步的，可以确定总路由节点的流量负载是否达到预设阈值，例如：并发访问数量是否达到预设阈值10000。可以为不同的流量负载参数分别设置预设阈值，预设阈值的具体数值可以根据实际情况确定，本说明书实施例对此不作限定。

在本实施方式中，流量负载信息中任何一个流量负载参数达到预设阈值则说明总路由节点处于过负载的状态，可以横向增加总路由节点数量，减小总路由节点的流量负载压力。

在一个场景示例中，集群治理系统可以如图2中所示，可以包括：服务管控中心201、总路由节点202、渲染服务节点203、服务节点204、健康检查205、灰度总控206。

在本场景示例中，服务管控中心201的部署流程可以包括：

步骤201：服务管控中心获取到上传的程序包、子系统参数(子系统名、所需节点个数、灰度策略)。

步骤202：将子系统名和灰度策略插入到目标数据库中的灰度策略表中。

步骤203：判断该上传的子系统是否为新增子系统(该上传的子系统是否和当前正在运行的子系统重名)。

步骤204：如果不是新增子系统，则对目前正在运行的子系统对应的服务节点进行停机。

步骤205：判断需要停机的子系统的全部服务节点是否停机完成。

步骤206：在确定全部停机完成的情况下，按所需节点个数将程序包解压并部署到各个服务节点。

步骤207：将部署了程序的服务节点注册到总路由节点。

步骤208：启动上述各个停机了的服务节点。

在本场景示例中，灰度总控206的流程可以包括：

步骤301：总路由节点接收到网页请求。

步骤302：解析网页请求的HTTP报文，并从中获取到用户会话ID(用户会话ID通常为session ID)、子系统名和URL。

步骤303：根据用户会话ID从后端服务器中获取到用户ID。

步骤304：查询数据库，根据用户ID，子系统名，URL，查询数据库中的灰度策略表。

步骤305：根据对应的灰度策略，将网页请求转发到对应的服务节点。具体的，可以先根据URL获得到使用的子系统名(例如，system_a)，再根据用户ID去查找用户灰度关联表和灰度策略表，查询到该用户ID对应的灰度控制字段(例如，area)，该用户的地区字典值如果为01，则按照灰度策略表中系统名为system_a、控制字段为area、控制字典值为01的策略去查询服务节点灰度关联表，获取服务节点的IP，并根据该IP进行转发。如根据用户所属地区做灰度，只有地区A的用户可以访问功能A，则根据地区灰度策略，将地区A的用户请求转发至带有功能A的服务节点。

在本场景示例中，渲染服务节点203的处理流程可以包括：

步骤401：总路由节点接收到网页请求。

步骤402：总路由节点将该网页请求转发到渲染服务节点。

步骤403：渲染服务节点解析网页请求的报文，根据网页请求的报文中的URL获取到服务节点的空的html文件(未渲染界面的html文件)和JS代码文件。

步骤404：渲染服务节点将JS代码进行解析并渲染html文件。

步骤405：返回渲染完成的html页面给用户。

在本场景示例中，健康检查节点205的健康检查流程可以包括：

步骤501：总路由节点定时请求各服务节点的健康检查接口，该定时时间可以自定义，如10分钟一次。

步骤502：遍历正常服务节点集合。

步骤503：判断当前遍历的服务节点是否能和总路由节点建立连接。

步骤504：如不能建立连接，则将该服务节点从正常服务节点集合中移除。

步骤505：如能建立连接，则将该服务节点加入异常服务节点集合中。

步骤506：断开总路由节点与异常服务节点的连接，总路由节点后续不会将用户请求转发至异常服务节点集合中的服务节点。

步骤507：遍历异常服务节点集合。

步骤508：判断当前遍历的服务节点是否能和总路由节点建立连接。

步骤509：如不能建立连接，则将该服务节点从异常服务节点集合中移除。

步骤510：将该服务节点加入正常服务节点集合中。

步骤511：获取当前总路由节点的流量负载信息，包含每秒并发访问数量、CPU频率、内存占用量。

步骤512：判断流量负载是否达到预设阈值，例如：并发访问数量是否达到预设值10000。

步骤513：横向增加总路由节点数量，减小总路由节点的流量负载压力。

基于同一发明构思，本说明书实施例中还提供了一种系统部署装置，如下面的实施例所述。由于系统部署装置解决问题的原理与系统部署方法相似，因此系统部署装置的实施可以参见系统部署方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图3是本说明书实施例的系统部署装置的一种结构框图，如图3所示，可以包括：获取模块301、确定模块302、部署模块303、注册模块304，下面对该结构进行说明。

获取模块301，可以用于获取目标部署信息集；其中，所述目标部署信息集中包含目标子系统的程序包和特征参数；

确定模块302，可以用于在根据所述目标子系统的特征参数确定所述目标子系统为新增子系统的情况下，确定部署所述目标子系统的至少一个目标服务节点；其中，所述目标服务节点为未部署过子系统的服务节点；

部署模块303，可以用于根据所述目标子系统的程序包，将所述目标子系统部署至所述至少一个目标服务节点中；

注册模块304，可以用于将所述至少一个目标服务节点注册到总路由节点。

本说明书实施例实施方式还提供了一种电子设备，具体可以参阅图4所示的基于本说明书实施例提供的系统部署方法的电子设备组成结构示意图，所述电子设备具体可以包括输入设备41、处理器42、存储器43。其中，所述输入设备41具体可以用于输入目标部署信息集。所述处理器42具体可以用于获取目标部署信息集；其中，所述目标部署信息集中包含目标子系统的程序包和特征参数；在根据所述目标子系统的特征参数确定所述目标子系统为新增子系统的情况下，确定部署所述目标子系统的至少一个目标服务节点；其中，所述目标服务节点为未部署过子系统的服务节点；根据所述目标子系统的程序包，将所述目标子系统部署至所述至少一个目标服务节点中；将所述至少一个目标服务节点注册到总路由节点。所述存储器43具体可以用于存储目标子系统的程序包和特征参数等数据。

在本实施方式中，所述输入设备具体可以是用户和计算机系统之间进行信息交换的主要装置之一。所述输入设备可以包括键盘、鼠标、摄像头、扫描仪、光笔、手写输入板、语音输入装置等；输入设备用于把原始数据和处理这些数的程序输入到计算机中。所述输入设备还可以获取接收其他模块、单元、设备传输过来的数据。所述处理器可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式等等。所述存储器具体可以是现代信息技术中用于保存信息的记忆设备。所述存储器可以包括多个层次，在数字系统中，只要能保存二进制数据的都可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也叫存储器，如RAM、FIFO等；在系统中，具有实物形式的存储设备也叫存储器，如内存条、TF卡等。

在本实施方式中，该电子设备具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

本说明书实施例实施方式中还提供了一种基于系统部署方法的计算机存储介质，所述计算机存储介质存储有计算机程序指令，在所述计算机程序指令被执行时可以实现：获取目标部署信息集；其中，所述目标部署信息集中包含目标子系统的程序包和特征参数；在根据所述目标子系统的特征参数确定所述目标子系统为新增子系统的情况下，确定部署所述目标子系统的至少一个目标服务节点；其中，所述目标服务节点为未部署过子系统的服务节点；根据所述目标子系统的程序包，将所述目标子系统部署至所述至少一个目标服务节点中；将所述至少一个目标服务节点注册到总路由节点。

在本实施方式中，上述存储介质包括但不限于随机存取存储器(Random AccessMemory，RAM)、只读存储器(Read-Only Memory，ROM)、缓存(Cache)、硬盘(Hard DiskDrive，HDD)或者存储卡(Memory Card)。所述存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的，用于进行网络连接通信的接口。

在本实施方式中，该计算机存储介质存储的程序指令具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

显然，本领域的技术人员应该明白，上述的本说明书实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本说明书实施例不限制于任何特定的硬件和软件结合。

虽然本说明书实施例提供了如上述实施例或流程图所述的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑性上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本说明书实施例提供的执行顺序。所述的方法的在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

应该理解，以上描述是为了进行图示说明而不是为了进行限制。通过阅读上述描述，在所提供的示例之外的许多实施方式和许多应用对本领域技术人员来说都将是显而易见的。因此，本说明书实施例的范围不应该参照上述描述来确定，而是应该参照前述权利要求以及这些权利要求所拥有的等价物的全部范围来确定。

以上所述仅为本说明书实施例的优选实施例而已，并不用于限制本说明书实施例，对于本领域的技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的保护范围之内。