一种业务请求处理系统及超融合一体机
技术领域
本发明涉及云计算技术领域，尤其涉及一种业务请求处理系统及超融合一体机。
背景技术
超融合一体机基于超融合架构(Hyper Converged Infrastructure，HCI)，是指在同一套单元设备中不仅仅具备计算、网络、存储和服务器虚拟化等资源和技术，而且还包括备份软件、快照技术、重复数据删除、在线数据压缩等元素，而多套单元设备可以通过网络聚合起来，实现模块化的无缝横向扩展(scale-out)，形成统一的资源池。超融合一体机中通常设置至少三个物理机，并需要定义出控制节点、存储节点、网络节点及计算节点。
为保证超融合一体机的高可用，通常在两台或者三台物理机上部署控制节点，并将其中一台物理机上的控制节点定义为主节点，将另一台或者另两台物理机上的控制节点作为备用节点。
然而，控制节点的资源消耗巨大，如果在两个或者两个以上的物理机中均部署控制节点，则会导致物理机无法有效地对外提供计算服务、存储服务或者网络通信服务，由此导致用户体验的下降；但如果仅在一台物理机上部署一个控制节点，则又会导致因为仅存在一个控制节点所导致的因为物理机断电、宕机或者离线所导致的控制节点不可用，并进一步导致整个超融合一体机无法对外响应的问题。因此，有必要对现有技术中的超融合一体机予以改进。
发明内容
本发明的目的在于揭示一种业务请求处理系统及超融合一体机，用以克服现有的超融合一体机所存在的上述缺陷，尤其是为了降低超融合一体机中控制节点对超融合一体机物理资源的占用与开销，并实现快速的故障切换及数据的强一致性。
为实现上述第一个发明目的，本发明提供了一种业务请求处理系统，包括：
至少两个物理节点，在至少两个物理节点中分别部署CVM，并仅将其中一个CVM所属的物理节点定义为主节点，将其他物理节点定义为从节点，每个物理节点所配置的物理磁盘被划分为用于安装操作系统的操作系统盘，以及形成分布式存储架构的若干服务数据盘，并将至少一个服务数据盘挂载至CVM；
所述主节点中所部署的CVM纳管主节点及所有从节点，所述主节点所部署的CVM响应外部请求所生成的有状态服务数据保存于服务数据盘中，并在主节点中止服务时由高可用组件选举出的新的主节点自服务数据盘中调用并加载所述有状态服务数据。
作为本发明的进一步改进，其特征在于，所述CVM被封装并运行于配置于物理节点的容器或者虚拟机中。
作为本发明的进一步改进，每个物理节点均配置计算服务、存储服务、网络服务及高可用组件。
作为本发明的进一步改进，仅为主节点中的CVM赋予控制节点权限，当所述主节点发生中止服务时由高可用组件选举出新的主节点后将所述控制节点权限迁移至新的主节点中的CVM。
作为本发明的进一步改进，所述高可用组件选自corosync组件、pacemaker组件或者heatbeat组件中的一种或者几种的组合。
作为本发明的进一步改进，所述主节点所部署的CVM响应外部请求所生成的有状态服务数据和无状态服务数据，并将所述有状态服务数据保存于服务数据盘，而将无状态服务数据保存于操作系统盘。
作为本发明的进一步改进，所述主节点所部署的CVM响应外部请求所生成的有状态服务数据和无状态服务数据，并将所述有状态服务数据与无状态服务数据同时保存于服务数据盘。
作为本发明的进一步改进，所述物理节点配置第一物理网卡、第二物理网卡、第三物理网卡、第一虚拟网桥、第二虚拟网桥、至少一个业务虚拟机以及形成分布式存储架构的若干服务数据盘所组成的分布式存储装置；
任意两个物理节点之间所配置的第一物理网卡、第二物理网卡及第三物理网卡均独立连接至三层交换机或者路由器，并发生对端会话；
所述CVM通过第一虚拟网桥连接至第一物理网卡，所述业务虚拟机通过第二虚拟网桥连接至第二物理网卡，所述分布式存储装置连接至第三物理网卡。
作为本发明的进一步改进，所述第一虚拟网桥配置第一虚拟网卡与第二虚拟网卡，所述CVM配置第三虚拟网卡；所述第一虚拟网卡与第二虚拟网卡相通讯，以在CVM与第一虚拟网桥之建立通讯连接；所述第二虚拟网卡与部署CVM的物理节点建立通讯连接。
作为本发明的进一步改进，所述物理节点中的CVM纳管所属物理节点中逻辑上相互独立的操作系统盘与服务数据盘，所述操作系统盘保存于形成该操作系统盘的物理节点中，所有物理节点的服务数据盘共同组成基于分布式存储架构的分布式存储装置。
基于相同发明思想，本申请还揭示了一种超融合一体机，包括：
至少一个如上述任一项发明创造所述的业务请求处理系统。
与现有技术相比，本发明的有益效果是：
首先，在多个物理节点中的至少两个物理节点中分别部署CVM，并仅将主节点中的CVM赋予控制节点权限，同时将CVM封装并运行于容器或者虚拟机中，从而显著地降低了主节点对整个业务请求处理系统的资源的占用与开销；
其次，由于多个物理节点的物理磁盘所形成的具有分布式存储架构的若干服务数据盘记录有状态服务数据，使得在主节点发生中止服务(例如宕机、断电、系统崩溃、磁道损坏等情形时)时，能够通过内部数据网络从分布式存储装置中调用保存有上述有状态服务数据的一个或者多个服务数据盘，并直接将一个或者服务数据盘挂载至新的主节点中所配置的CVM中，从而使得该业务请求处理系统在主节点由于宕机、系统崩溃等异常情况导致其中止服务时能够快速恢复对外响应能力，提高了整个业务请求处理系统的可靠性与稳定性，并能够数据的强一致性，并实现了故障的快速切换；
同时，由于各个物理节点中的配置相同，使得增加或者减少物理节点的操作更为简便，并且确保了在增加或者减少物理节点的过程中不停止对外服务；
最后，基于高可用组件，确保了该业务请求处理系统中主节点与从节点之间的角色切换的简便性，实现了业务请求处理系统的高可用性。
附图说明
图1为业务请求处理系统中的两个物理节点中分别部署CVM，并将其中一个物理节点定义为主节点同时将另一个物理节点定义为从节点后，有状态服务数据保存至分布式存储装置的示意图；
图2为业务请求处理系统的高可用组件在两个物理节点之间执行主节点与从节点切换的示意图；
图3为业务请求处理系统的网络拓扑图；
图4为有状态服务数据与无状态服务数据分别保存至服务数据盘与操作系统盘的示意图；
图5为一种超融合一体机的架构示意图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。
在详细阐述本申请各个实施例之前，对涉及的主要技术术语的含义予以定义。
术语“无状态服务数据(StatelessServiceData)”是指：该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的。
术语“有状态服务数据(StatefulServiceData)”是指：该服务的实例可以将一部分数据随时进行备份，并且在创建一个新的有状态服务时，可以通过备份恢复这些数据，以达到数据持久化的目的。
术语“HA组件”与术语“高可用组件”具等同技术含义。
术语“CVM”：控制虚拟管理器(Controller Virtual Manager)。
实施例一：
参图1至图4所示，本实施例揭示了一种业务请求处理系统的一种具体实施方式。
本实施例所揭示的业务请求处理系统及基于该业务请求处理系统的一种超融合一体机中的“业务请求”泛指一切基于逻辑上独立于该业务请求处理系统的主体(例如用户、管理员、机器人程序、自动运行的脚本等)向该业务请求处理系统发起的会话请求、存储、修改、读取等事件。
“业务请求”在实际场景中可被理解为直接或者间接生成有状态服务数据，例如：在购物网站上进行购物的事件、创建镜像文件的事件，或者无状态服务数据，例如：轮询事件、删除数据事件等。
有状态服务数据基于有状态服务的发生而产生，无状态服务数据基于无状态服务的发生而产生。同时，有状态服务和无状态服务是两种不同的服务架构，两者的不同之处在于对于服务状态的处理。服务状态是服务请求所需的数据，它可以是一个变量或者一个数据结构。无状态服务不会记录服务状态，不同业务请求之间也是没有任何关系；而有状态服务的不同业务请求之间是存在关系的。
本实施例所揭示的该业务请求处理系统可应用于超融合架构，并运用于基于超融架构的超融合一体机中，或者应用于云平台、集群服务器或者数据中心或者其他场景中。
结合图5所示，需要说明的是，在本实施例中，该业务请求处理系统中包含两个或者两个以上的物理节点，例如，物理节点41、物理节点42至物理节点4i(参数i取大于或者等于2的正整数)。在所有物理节点中，仅将其中一个物理节点定义为主节点，而将其他物理节点定义为从节点，每个物理节点的配置相同，即每个物理节点均配置CVM、计算服务(逻辑上形成“计算节点”)、存储服务(逻辑上形成“存储节点”)、网络服务(逻辑上形成“存储节点”)以及HA组件。
尤其需要说明的是，在申请各个实施例中，主节点与一个或者多个从节点均是物理节点，只是由于在某个时刻由于一个物理节点中的CVM被赋予控制节点权限，才使得该物理节点被认定为主节点，而将其他物理节点认定为从节点，且主、从节点之间的角色可以发生变化，当前状态下主节点发生宕机、系统崩溃等异常时，被赋予控制节点权限的CVM会被关闭，而由HA组件在一个或者多个从节点的物理节点中选举出唯一一个物理节点，并启动该物理节点上的CVM，并重新为选举出的物理节点中所部属的CVM赋予控制节点权限，从而将该从节点转换为主节点，并由具有控制节点权限的角色转换后的主节点中CVM纳管所属物理节点及其他作为从节点的物理节点。
所有的物理节点基于x86架构的物理计算机或者物理服务器。在该业务请求处理系统的整个生命周期所形成的时间轴上的任意一个时间点上，只有一个物理节点中所部署的CVM被赋予控制节点权限，并将其他物理节点的CVM不赋予控制节点权限，并且在当前的主节点正常响应外部发起的访问请求时，其他物理节点中所部署的CVM并不启动，而由当前状态中作为主节点的物理节点所部署的CVM纳管所有的物理节点，以执行超融合一体机或者云平台中的控制节点(Control Node)所需要执行的网络控制、调度管理、API服务、存储卷管理、数据库管理、身份管理和镜像管理等。
具体的，在本实施例中，一种业务请求处理系统，包括：
至少两个物理节点，在至少两个物理节点中分别部署CVM，并仅将其中一个CVM所属的物理节点定义为主节点10，将其他物理节点定义为从节点20，每个物理节点所配置的物理磁盘被划分为用于安装操作系统的操作系统盘48，以及形成分布式存储架构的若干服务数据盘49，并将至少一个服务数据盘49挂载至CVM422。每个物理节点的物理磁盘可通过分区工具或者后台管理员将一块物理磁盘划分为多个磁盘分区，或者将同一个物理节点中的多个物理磁盘所组成的磁盘阵列(RAID)划分为磁盘分区，并将一个或者多个磁盘分区作为安装操作系统的操作系统盘48及若干服务数据盘49。
主节点10中所部署的CVM422纳管主节点10及所有从节点20，主节点10所部署的CVM422响应外部请求(例如图1中由用户发起的访问请求)所生成的有状态服务数据12,22保存于服务数据盘49中，并在主节点10中止服务时由高可用组件50选举出的新的主节点(即图3中的物理节点4j，参数j小于或者等于参数i)自服务数据盘49中调用并加载所述有状态服务数据12,22。有状态服务数据12,22被保存至分布式存储装置47中，并能够被所有的物理节点进行访问，并在当前状态的主节点10发生宕机等异常情况时，由角色切换后的主节点直接纳管全部剩余并呈健康状态的物理节点。此时，分布式存储装置47中的有状态服务数据12,22能够直接被挂载至作为新的主节点中的CVM，例如物理节点4j中的CVM442中。同时，原来的主节点10中的CVM422产生并保存至物理节点42的操作系统盘48中的无状态服务数据11，通过第一物理网卡461发送至由HA组件50所选定的新的主节点所配置的第一物理网卡461中，并最终落盘至物理节点4j的操作系统盘48中。尤其需要说明的是，无状态服务数据11,21也可以在物理节点42与物理节点4j的主从节点切换过程中不发生迁移。
结合图1与图3所示，图1中的主节点10可被理解为图3中的物理节点42，图1中的从节点20可被理解为图3中的物理节点4j。基于用户发起的访问请求是不确定的，既可以产生有状态服务数据12,22，也可以产生无状态数据11,21，或者同时产生有状态服务数据12,22与无状态服务数据11,21。物理节点42与物理节点4j均可为计算机集群(服务器)或者超融合一体机中的一个逻辑上彼此独立且基于x86架构的计算机装置。物理节点42中部署CVM422，物理节点4j中部署CVM442。当物理节点42的角色为主节点时，CVM422启动但此时的CVM442并不启动，只有CVM422所属的物理节点42发生宕机、系统崩溃等异常时才启动重新选定的另一个物理节点4j中的CVM442，并触发启动该CVM442的事件，同时为该CVM442赋予控制节点角色，从而最终将物理节点4j定义为主节点。
在本实施例中，所有物理节点41～物理节点4i中均部署CVM(即CVM421、CVM422～CVM42i)，且CVM被封装并运行于配置于物理节点的容器(Container)或者虚拟机(VM)中，并最优选为容器。同时，配置并运行CVM的物理节点基于软件定义方式规划底层硬件并虚拟化出的多个业务虚拟机45与供CVM配置并运行的虚拟机在所属物理节点中相互独立。所有物理节点中均可创建并部署业务虚拟机，各个物理节点中的物理磁盘形成的一个或者多个虚拟数据盘基于第三物理网卡463及三层交换机/路由器共同接入并组成图5中的分布式存储装置47，且各个物理节点中的业务虚拟机45通过第二物理网卡462及三层交换机/路由器接入内部数据网络60。
首先，在本实施例中，由于将CVM被封装并运行于配置于物理节点的容器(Container)或者虚拟机(VM)中，物理节点组成的业务请求处理系统后，任意时间点只启动一个CVM，使得所有的物理节点在业务请求处理系统中运行的服务都是一样的，业务请求处理系统中的各物理节点不分控制节点，计算节点等，任意物理节点宕机也能确保整个业务请求处理系统能够正常工作。
同时，由于传统的高可用方案中需要两台或两台以上的物理节点组成集群来运行控制服务，而在本实施例中CVM被赋予控制节点权限的物理节点42都是单机的，执行传统控制节点的控制服务直接无需考虑各个物理节点之间的数据同步，从而极大地降低了整个业务请求处理系统技术复杂度和资源消耗。
其次，受限于数据库、消息队列等中间件的限制，采用传统的三个物理节点(一个主节点、两个从节点)情况下，采用现有的高可用架构的业务请求处理系统中最大宕机数量不能超过一台。然而，在本实施例中，只要业务请求处理系统中还有两台健康的物理节点，就可从这两台健康的物理节点中基于HA组件50重新选举出一个主节点，并形成一个主节点和一个从节点的业务请求处理系统，并继续对外提供服务。
最后，采用容器或者虚拟机封装并运行CVM422或者其他物理节点中未未启动的CVM，会使得物理节点的部署和扩容操作更为容易。相对于传统技术中需要在安装部署时需要预先在安装控制节点，控制节点安装完成后再安装其他节点的技术方案，本实施例所揭示的技术方案中，所有的物理节点的部署及配置都一样，无需区别对待，更有利于物理节点的扩容与缩容。
在本实施例中，仅为主节点10(即图3中的物理节点42)中的CVM422赋予控制节点权限，当所述主节点10发生中止服务时由高可用组件(即HA组件50)选举出新的主节点(即图3中的物理节点4j)后将CVM422的控制节点权限迁移至新的主节点中的CVM442。高可用组件50选自corosync组件、pacemaker组件或者heatbeat组件中的一种或者几种的组合，以通过高可用组件对各个物理节点41～4i之间建立同步连接，防止各个物理节点41～4i之间发生脑裂；同时，通过HA组件50为整个业务请求处理系统执行选举新的主节点的操作。鉴于上述HA组件50均为现有成熟的技术，在此不再予以详述。在本实施例中，无论存在多少个物理节点，作为主节点10的物理节点仅为一个，且启动该物理节点中的CVM。
结合图1、图3及图4所示，主节点10所部署的CVM422响应外部请求所生成的有状态服务数据12和无状态服务数据11，并将所述有状态服务数据12保存于服务数据盘49，而将无状态服务数据11保存于操作系统盘48。物理节点42配置第一物理网卡461、第二物理网卡462、第三物理网卡463、第一虚拟网桥43、第二虚拟网桥44、至少一个业务虚拟机45以及形成分布式存储架构的若干服务数据盘49所组成的分布式存储装置47。同样的，物理节点4j配置第一物理网卡461、第二物理网卡462、第三物理网卡463、第一虚拟网桥43、第二虚拟网桥44、至少一个业务虚拟机45以及形成分布式存储架构的若干服务数据盘49所组成的分布式存储装置47。操作系统盘48使用dock镜像，服务数据盘49将分布式存储装置47中所创建的云硬盘挂载至指定的物理节点后，将dock镜像挂载至CVM422。图1中实线方框示出的主节点10表示在当前状态下启动CVM的物理节点，虚线方框示出的从节点20(数量至少一个)表示在当前状态下未启动CVM的物理节点。
物理节点42与物理节点4j之间所配置的第一物理网卡461、第二物理网卡462及第三物理网卡462均独立连接至三层交换机或者路由器，并发生对端会话。
第一虚拟网桥43配置第一虚拟网卡431与第二虚拟网卡432，所述CVM422配置第三虚拟网卡433。第一虚拟网卡431与第二虚拟网卡432相通讯，以在CVM422与第一虚拟网桥43之建立通讯连接。第二虚拟网卡432与部署CVM422的物理节点42建立通讯连接。CVM422通过第一虚拟网桥43连接至第一物理网卡461，所述业务虚拟机45通过第二虚拟网44桥连接至第二物理网卡462，所述分布式存储装置47连接至第三物理网卡463。第二虚拟网桥44还配置第四虚拟网卡441，并通过第四虚拟网卡441与业务虚拟机45相通讯。物理节点42中的业务虚拟机45与任意一个位于对端的物理节点4j中所配置的业务虚拟机通过该物理节点4j中的第二物理网卡462、第二虚拟网桥44与该物理节点4j中的业务虚拟机45发生会话。发生会话在本实施例中可被理解为数据迁移、数据复制、数据删除、数据备份、创建镜像文件等计算机事件。
物理节点42中的CVM422纳管所属物理节点42中逻辑上相互独立的操作系统盘48与服务数据盘49，所述操作系统盘48保存于形成该操作系统盘的物理节点42中，所有物理节点42的服务数据盘49共同组成基于分布式存储架构的分布式存储装置47，以将该分布式存储装置47作为所有物理节点的共享存储池，参图1所示。
参图3所示，尤其需要说明的是，在本实施例中，根据网络流量类型定义了三个网络，分别是管理网络，业务网络，存储网络。每个物理节点分别用三个物理网卡来承载对应的网络，即承载管理流量的物理网卡461、承载业务流量的物理网卡462及承载存储流量的第三物理网卡463。管理网络主要用于各个物理节点之间控制命令下发和心跳检查等；业务网络主要用于响应用户发起的访问请求的业务虚拟机，承载业务虚拟机内部的业务流量；存储网络用于分布式存储装置47的管理、存储吞吐等，分布式存储装置47所形成的共享资源池上的服务数据盘49对外给CVM提供服务走存储网络。
第一虚拟网桥43配置有第一虚拟网卡431与第二虚拟网卡432，第一虚拟网卡431与CVM422相互通讯，第二虚拟网卡432连接该物理节点42并记录该物理节点的IP地址，所有物理节点的IP地址均不相同，例如，物理节点42中的IP地址为192.168.8.11/24，物理节点4i中的IP地址为192.168.8.12/24。所有的CVM都使用相同的IP地址(192.168.8.10/24)。第二虚拟网桥44配置出多个虚拟网卡441，分别给不同的业务虚拟机45使用。这样不同物理节点之间的虚拟机网络可以互通并可位于10.0.0.0/24网段。每个物理节点的物理磁盘被划分形成的服务数据盘49不需要执行底层虚拟化，可直接使用第三物理网卡463与对端的物理节点所同样配置的第三物理网卡463相通讯，并共同形成具有共享存储池功能的分布式存储装置47。不同物理节点中启动的业务虚拟机的IP地址是不同的。
结合图5所示，每个物理节点均配置计算服务、存储服务、网络服务及高可用组件(即HA组件50)。参图2所示，物理节点42中部署HA-start服务423、HA-stop服务424，物理节点4j中部署HA-start服务443、HA-stop服务444。HA-start服务423对CVM422是否启动以及第一虚拟网卡431与第三虚拟网卡433是否建立通讯连接进行检测，并使用NMAP扫描CVM422的IP地址，以确定当前的主节点10中的CVM422是否正常。
物理节点42和物理节点4j组成集群，集群启动之后由高可用组件50选举出一个主节点，主节点选举出来之后，高可用组件50将该节点的HA-start服务443启动起来。物理节点42和物理节点4j上HA-stop服务424、444都开机默认自启动的。两个节点HA-stop服务424、444判断当前节点是否是主节点做不同的动作，如果当前节点是主节点HA-stop服务444不做任何操作。如果当前节点不是主节点，则实时检测物理节点42中所部署的CVM422是否被关闭，若CVM422已经被启动，则强制关闭CVM422。如果集群中由于脑裂导致无法选举出主节点，HA-stop服务424、444负责保证各自物理节点上的CVM都是关闭的。
为了避免集群脑裂，必须保证物理节点42和物理节点4j每个节点启动CVM时HA-stop服务424、444启动。若CVM422及CVM442被封装并运行于虚拟机时，Libvirt服务启动必须依赖HA-stop服务424，防止HA-stop服务424故障了，CVM被某些程序拉起。若CVM封装并运行于容器时，容器进程服务启动必须依赖HA-stop服务424，防止HA-stop服务424故障了，CVM某些程序拉起。同时，如果该业务请求处理系统无法选举出一个新的主节点(例如图2中的物理节点4j)以运行HA-start服务443，HA-stop服务424负责将自身节点的CVM422执行关闭，以防止重复启动两个CVM，从而防止两个物理节点之间发生主节点角色的争夺，并由此导致整个业务处理系统发生脑裂。
通常情况下该业务请求处理系统中的物理节点采用奇数个物理节点以组成集群，在物理节点数量是偶数的情况下，高可用组件50由于投票原理无法选举出主节点，高可用架构可以采用第三方仲裁节点或者仲裁设备实现。
参图3与图4所示，在本实施例中，物理节点42中的业务虚拟机的IP地址段为10.0.0.11-13/24，物理节点4j中的业务虚拟机的IP地址段为10.0.0.14-16/24。物理节点42中分布式存储装置47的IP地址为192.168.9.11/24，物理节点4j中分布式存储装置47的IP地址为192.168.9.12/24，且物理节点42中分布式存储装置47(由所属物理节点的物理磁盘形成的一个或者多个虚拟数据盘)与物理节点4j(由所属物理节点的物理磁盘形成的一个或者多个虚拟数据盘)中分布式存储装置47共同组成共享存储池。因此，在本实施例中，分别落入操作系统盘48的无状态数据与落入服务数据盘49的有状态数据，确保了用户发起的访问请求后对用户响应的稳定性，确保了用户的良好用户体验，能保证主节点物理节点宕机之后，新选举出来的主节点启动CVM442立即接管服务数据盘49，CVM中的有状态的服务继续读写磁盘上的数据，从而确保了该业务请求处理系统能以“无缝衔接式”继续正常为用户提供服务。
需要说明的是，图3中每个物理节点中的分布式存储装置47均可被视为图5中分布式存储装置47的组成部分之一。
实施例二：
结合图1所示，本实施例所揭示的一种业务请求处理系统与实施例一相比，其主要区别在于，在本实施例中，主节点10所部署的CVM422响应外部请求所生成的有状态服务数据12和无状态服务数据11，并将所述有状态服务数据12与无状态服务数据11同时保存于服务数据盘49。
在本实施例中，因业务请求处理系统在重启时会丢失无状态服务数据11，因此，可将所述有状态服务数据12与无状态服务数据11同时保存于服务数据盘49。保留无状态服务数据11，可通过对无状态服务数据11的历史记录进行分析，预测该业务请求处理系统中所配置的各种服务和硬件寿命的趋势，从而为更换某个或者某些个物理节点提供准确的参考依据。
本实施例与实施例一中相同部分的技术方案，请参实施例一所示，在此不再赘述。
实施例三：
结合图5所示，本实施例还揭示了一种超融合一体机。
在本实施例中，一种超融合一体机，包括：至少一个如实施例一和/或实施例二所揭示的一种业务请求处理系统。
本实施例与实施例一和/或实施例二中相同部分的技术方案，请参实施例一和/或实施例二所示，在此不再赘述。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。
