多用户计算和IO密集型SaaS系统及应用方法与流程

本发明涉及io密集型saas云服务领域，尤其涉及一种多用户计算和io密集型saas系统及应用方法。

背景技术：

软件即服务(software-as-a-service，saas)云服务，是用于使得能够对软件功能和数据做隔离以及服务器存储共享部署，为用户提供普遍、方便、按需的软件访问的模型。

在数据存储和计算量比较大的人工智能计算和数据检索处理服务领域，当用户规模较大、存在无规律密集访问、单个用户数据容量不确定的应用场景中，一般需要集中在单个大计算量的服务器内完成计算，作为一个项目实施的成本较高。然而为多用户提供云服务的本质是需要弹性的计算降低成本、支持在线伸缩、规避不确定性大的服务请求、规避高可靠故障等需求。而采用传统方法改造应用为saas，例如通过统一共享式逻辑处理，数据库分区难以解决计算和io密集型应用。

例如，在目前已经改造的saas多用户图像检索业务中，通过在业务逻辑中区分不同用户u1和u2的域名(domain)，服务请求依据u1和u2数据特征到数据(data)对应的图像特征索引中查找给出结果。在这种架构模式下，逻辑能得到极大的计算，共享做到弹性，数据和逻辑分离，逻辑解耦和比较容易。但该种模式存在的问题是如果面向增强现实技术(augmentedreality,ar)应用的云识别服务，每个用户数据的被检索目标数据都是百万级别，逻辑计算所需加载到内存的数据特征索引数据从数据到逻辑(logic)读取会到达200mb/s，因此数据和逻辑通过网络传输的模式下无法支持大规模的用户访问。

鉴于此，现有技术中对多用户大计算量的数据服务领域，无法有效的解决多用户计算和io密集型服务。

技术实现要素：

本发明实施例提供了一种多用户计算和io密集型saas系统及应用方法，解决了在多用户计算和io密集型应用场景下，多用户的saas应用问题。

本发明实施例提供了一种多用户计算和io密集型saas系统，所述saas系统包括第一逻辑单元、控制器和第二逻辑单元，所述第二逻辑单元包括第一计算池单元，所述第一计算池单元上设置第一服务器和第一用户数据存储单元，所述第一服务器上设置第一容器计算单元，其中：

所述第一逻辑单元，用于接收第一用户的请求消息，根据所述请求消息获取所述第一用户的uuid以及所述第一用户请求的数据标识，并将所述第一用户的uuid发送给所述控制器；

所述控制器，用于根据所述第一用户的uuid确定所述第一用户的第一容器计算单元，并将所述第一逻辑单元接收到的所述第一用户的请求消息路由给所述确定的第一容器计算单元；

所述第一容器计算单元，用于接收所述第一逻辑单元发送的请求消息，根据所述请求消息中包含的所述第一用户的uuid和数据标识向所述第一用户数据存储单元获取所述第一用户的用户数据，并将所述第一用户的用户数据返回给所述第一逻辑单元；

所述用户数据存储单元，用于存储所述第一用户的用户数据，根据所述第一用户的uuid以及数据标识确定所请求的用户数据，并将所述确定的用户数据发送给所述第一容器计算单元。

本发明实施例还提供了一种多用户saas应用方法，使用前述任一所述的多用户计算和io密集型saas系统，所述saas系统包括第一逻辑单元、控制器和第二逻辑单元，所述第二逻辑单元包括第一计算池单元，所述第一计算池单元上设置第一服务器和第一用户数据存储单元，所述第一服务器上设置第一容器计算单元，其中：

所述第一逻辑单元接收第一用户的请求消息，根据所述请求消息获取所述第一用户的uuid以及所述第一用户请求的数据标识，并将所述第一用户的uuid发送给所述控制器；

所述控制器根据所述第一用户的uuid确定与所述第一用户的第一容器计算单元，并将所述第一逻辑单元接收到的所述第一用户的请求消息路由给所述确定的第一容器计算单元；

所述第一容器计算单元接收所述第一逻辑单元发送的请求消息，根据所述请求消息中包含的所述第一用户的uuid和数据标识向所述第一用户数据存储单元获取所述第一用户的用户数据，并将所述第一用户的用户数据返回给所述第一逻辑单元；

所述第一用户数据存储单元根据所述第一用户的uuid以及数据标识确定所请求的用户数据，并将所述确定的用户数据发送给所述第一容器计算单元。

本发明实施例还提供了一种多用户计算和io密集型saas系统，所述saas系统包括存储器和处理器，其中：

所述存储器，用于存储代码和相关数据；

所述处理器，用于执行所述存储器中的代码用以实现前述任一所述的方法步骤

本发明实所提供的多用户计算和io密集型saas系统及应用方法，所能实现的有益效果如下：

本发明所提供的saas应用系统，能够实现计算及io密集型应用的saas服务。本发明所提供的saas系统，(1)引入数据分区思想，将不同用户分到不同计算资源池，一个计算池内拥有共享一套存储区域；(2)将用户进行业务服务中所涉及到的共性服务如授权认证、数据预处理、例如图像搜索业务中特征抽取等服务做成小的服务第一逻辑单元；(3)将saas服务改造成按需加载内存计算，不用的时候释放资源，计算资源与计算负载正比动态调整，存储与计算分离，更大程度的资源共享和为容器集群；(4)引入开源的kubernetes帮助调度docker，帮助实现一个稳定调度器以及路由模块的开发。

附图说明

图1为本发明实施例所提供saas系统的第一结构示意图；

图2为本发明实施例所提供的saas应用方法流程示意图；

图3为本发明实施例所提供saas系统的第二结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。另外，本文中术语“系统”和“网络”在本文中常被可互换使用。

本文中，第一计算池单元、第二计算池单元、……、第n计算池单元，单独或合称“计算池单元”或者“计算池”；第一服务器、第二服务器、第三服务器、……、第n服务器，单独或合称“服务器”；第一容器计算单元、第二容器计算单元、第三容器计算单元、……、第n容器计算单元，单独或合称“容器计算单元”；第一用户数据存储单元、第二用户数据存储单元、第三用户数据存储单元、……、第n用户数据存储单元，单独或合称“用户数据存储单元”；第一用户、第二用户、……、第n用户，单独或合称“用户”。

实施例一：

本发明实施例提供了一种多用户计算和io密集型saas系统，如图1所示，包括第一逻辑单元1、第二逻辑单元2和控制器3，其中第二逻辑单元包括第一计算池单元21。在一个优选的方案中，第一计算池单元21还包括第一服务器211和第一用户数据存储单元212，第一服务器211上还设置第一容器计算单元2111。

在本发明实施例中，第一逻辑单元1集成了逻辑(logic)数据特征的提取和排序等算法功能，该第一逻辑单元1可以是集中共享服务器。第一逻辑单元1能将第一用户的请求消息，例如应用程序编程接口(applicationprogramminginterface,api)请求进行解析，输出所述用户的数据标识以及用户的通用唯一识别码(universallyuniqueidentifier,uuid)，所述第一用户的数据标识可以是表示第一用户待检索数据的数据特征，例如数据的类别、索引、id等。第二逻辑单元2用来对用户的请求及数据进行检索及处理。

在本发明实施例中，第一逻辑单元1包括请求预处理，认证等应用相关公共性逻辑，是无状态的，不涉及密集计算和存储的逻辑部分。第二逻辑单元定义为用户独享计算服务，需要获取用户数据，并将该用户数据加载至内存，配合大量的运算过程得出计算结果的。

在本发明实施例中，在saas系统中引入计算池(pool)的概念，可以将不同用户的数据存储分配到不同的计算池(pool)中，例如可以根据用户数据量的大小，为每个计算池分配一个或者多个用户的存储空间，用来存放用户的数据(data)。在本发明实施例一个优选的方案中，在第一计算池单元(pool1)21中为第一用户分配数据存储空间，用来存储第一用户的数据，该分配的存储空间为第一用户数据存储单元212，设置在第一计算池单元21上。在一个优选的方案中，用户数据存储单元可以是应用所需持久化到磁盘数据的集合，存储在文件系统里，应用运算的时候往往需要批量加载进内存加以密集计算。

在本发明实施例中，可以在每个计算池内设置一个或者多个服务器，每个服务器上集成一个或者多个容器计算单元，该容器计算单元具备容器(docker)和逻辑单元功能。其中容器(docker)可以看作是一个开源的应用容器引擎，让saas系统可以将开发完成的应用程序打包到一个可移植的容器中，然后发布到任何的网络系统中或者服务器上，可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。

在本发明实施例中，所述第一容器计算单元包含为第一用户提供数据检索和计算的服务，并且具有一定的伸缩性。第一容器计算单元与第一用户数据存储单元存在映射关系，第一容器计算单元能直接寻址对应的第一用户数据存储单元。在一个优选的方案中，为第一用户提供计算服务的容器计算单元可以设置在相同或者不同的服务器上，但必须设置在同一计算池单元内，例如第一计算池单元内。

在本发明实施例中，为确保saas系统的顺利运行，还需要在saas系统内设置控制器，该控制器可以通过第一逻辑单元寻址并路由到相应的容器计算单元。具体的，可以控制容器资源动态伸缩释放，并寻址并路由第一逻辑单元到对应的容器计算单元的处理请求。在本发明一个实施例中，该控制器可以包括调度器以及寻址路由器两个组件。

在本发明实施例中，预先在saas系统中进行设置如下：

新用户在saas系统中进行注册时，saas系统为每个新注册的用户分配唯一的uuid，以第一用户进行注册为例进行说明，例如为第一用户分配的uuid为：00000000-0000-0000-c000-000000000046。进一步的，控制器预先根据所述第一用户的uuid定位所述第一用户所在的所述第一计算池，在所述第一计算池里面查找有剩余计算资源的服务器，例如第一服务器上有剩余计算资源，则会选择所述第一服务器为第一用户提供服务，否则会选择第一计算池上的其他服务器为第一用户提供服务，例如第二服务器等；控制器选择第一服务器为第一用户提供服务时，会在第一服务器中查找有剩余计算资源的容器计算单元，例如第一容器计算单元有剩余计算资源时，就选择第一容器计算单元为第一用户提供服务，否则会选择第一服务器上的其他容器计算单元为第一用户提供服务，例如第二容器计算单元等。控制器在所述第一计算池单元内为所述第一用户分配第一数据存储单元，将所述第一数据存储单元加载至所述确定的容器计算单元，例如第一容器计算单元等。

在本发明实施例中，控制器在saas系统中保存为第一用户分配设置的第一计算池单元、第一服务器、第一容器计算单元以及第一用户数据存储单元，例如在系统内设置第一用户的uuid、第一计算池单元名称(pool)、为第一用户提供服务的第一服务器(domain)以及为第一用户提供计算服务的第一容器计算单元的对应关系，并将为第一用户分配的第一用户数据存储单元加载到第一容器计算单元上。控制器根据第一用户的uuid即可查找到对应的与该第一用户对应的第一计算池单元、第一服务器、第一服务器上的第一容器计算单元以及对应的第一用户数据存储单元。在一个优选的实施例中，可以在saas系统内部配置第一用户的映射列表，用来存储第一用户的uuid、第一计算池单元名称、第一服务器域名、第一容器计算单元域名的映射关系，其中第一服务器和第一容器计算单元可以是一个或者多个。在一个优选的方案中，saas系统为每个用户分配uuid、计算池、服务器、容器计算单元以及用户数据存储单元可以由saas系统中的控制器来完成。

在本发明实施例中，当控制器删除为第一用户提供服务的服务器或者容器计算单元时，则控制器将第一用户的映射列表中对应的服务器域名或者容器计算单元域名删除即可。

在本发明实施例中，当控制器为第一用户选择新的服务器或者容器计算单元时，则控制器在第一用户的映射列表增加对应的服务器域名或者容器计算单元域名即可。

在本发明实施例中，控制器根据用户的uuid使用dht一致性哈希算法将用户分配到不同的计算池单元里进行计算。

在本发明实施例中，每个计算池单元中的数据(data)存储io带宽都是有限的，saas系统为每个计算池单元、每个服务器以及每个容器计算单元都设置一个阈值，当目前的访问超过该阈值时，就会路由至其他空闲的单元上，如空闲的计算池、空闲的服务器或者空闲的容器计算单元。例如：可以将部分用户的数据存储区域搬迁至空闲态的计算池内，在saas系统内修改用户的uuid-计算池名称-服务器名称的映射关系即可。在一个优选的方案中，该阈值可以有系统根据计算的需要预先设置。

如图1所示，在本发明实施例中，第一逻辑单元1可以用来接收第一用户的请求消息，根据所述请求消息获取所述第一用户的uuid以及所述第一用户请求的数据标识，并将所述第一用户的uuid发送给所述控制器3；

所述控制器3可以根据所述第一用户的uuid确定为所述第一用户提供计算服务的第一容器计算单元2111，并将所述第一逻辑单元1接收到的所述第一用户的请求消息路由给所述确定的第一容器计算单元2111；

所述第一容器计算单元2111可以接收所述第一逻辑单元1发送的请求消息，根据所述请求消息中包含的所述第一用户的uuid和数据标识向所述第一用户数据存储单元212获取所述第一用户的用户数据，并将获取到的第一用户的用户数据发送给所述第一逻辑单元1；

所述第一用户数据存储单元212可以存储所述第一用户的用户数据，根据所述用户的uuid以及数据标识确定所请求的用户数据，并将所述确定的用户数据发送给所述第一容器计算单元2111。

在本发明实施例一个优选的方案中，预先在所述saas系统中为所述第一用户分配uuid，并为所述第一用户配置第一计算池单元21、第一服务器2111及第一容器计算单元2111，设置所述第一用户的uuid、第一计算池单元21、第一服务器211以及第一容器计算单元2111之间的映射关系；所述系统为所述用户分配对应的第一用户数据存储单元212，并将所述第一用户数据存储单元212加载至所述第一容器计算单元2111。在一个优选的方案中，saas系统的前述设置可以通过控制器来完成。在设置完成后，可以在saas系统中设置并存储第一用户的映射列表，该映射列表中可以保存为第一用户提供服务的第一计算池单元名称、第一服务器域名，以及第一容器计算单元域等信息。其中控制器可以删除该第一用户的映射列表中的第一服务器域名和/或第一容器计算单元域名。映射列表中的第一服务器的域名和/或第一容器计算单元的域名被删除后，该第一服务器和/或第一容器计算单元就不能继续为第一用户提供服务，相反，映射列表中新增第一服务器的域名和/或第一容器计算单元的域名后，该第一服务器和/或第一容器计算单元就可以为第一用户提供服务。

在本发明实施例一个优选的方案中，所述控制器3根据所述第一用户的uuid，以及预先设置的第一用户的uuid、第一计算池单元21、第一服务器211以及第一容器计算单元2111的映射关系，确定与所述第一用户的uuid相对应的第一计算池单元21、第一服务器211和第一容器计算单元2111。

在本发明实施例一个优选的方案中，为第一用户提供服务的全部容器计算单元均设置在第一计算池单元21内，但是可以分布在相同或者不同的服务器上。

在本发明实施例一个优选的方案中，当控制器3检测到为所述第一用户提供服务的第一容器计算单元2111在策略时间内超过阈值时，所述控制器3在所述第一服务器211上为所述用户分配第二容器计算单元2112，将第二容器计算单元2112的域名添加至第一用户的映射列表中，并将所述第一用户数据存储单元212加载到所述第二容器计算单元2112上。所述策略时间可以是在预设的时间段内第一容器计算单元为第一用户提供计算的次数或者频率，例如阈值可以设置为在24小时内计算的次数为10000次。

在本发明实施例一个优选的方案中，当控制器3检测到为所述第一用户提供服务的第一服务器211在策略时间内超过阈值时，所述控制器3为所述用户在计算池单元21内选择有剩余计算资源的第二服务器212，并在所述第二服务器212上为所述用户分配第三容器计算单元2121，将第二服务器212的域名和第三容器计算单元2121的域名添加至第一用户的映射列表中，并将所述第一用户数据存储单元212加载到所述第三容器计算单元2121上。所述策略时间可以是在预设的时间段内第一服务器上为第一用户提供服务的次数或者频率，例如阈值可以设置为在24小时内计算的次数为100000次。

在本发明实施例一个优选的方案中，当所述控制器检测到为所述第一用户提供服务的第一容器计算单元2111在策略时间内低于阈值时，所述控制器3删除所述用户映射列表中的第一容器计算单元2111的域名。所述策略时间可以是在预设的时间段内，第一容器计算单元为第一用户提供计算的次数或者频率，例如阈值可以设置为在24小时内计算的次数为10000次。

在本发明实施例一个优选的方案中，当所述控制器检测到为所述第一用户提供服务的第一服务器211在策略时间内低于阈值时，所述控制器3删除所述用户映射列表中的第一服务器211的域名。所述策略时间可以是在预设的时间段内，第一服务器为第一用户提供计算的次数或者频率，例如阈值可以设置为在24小时内计算的次数为50000次。

在本发明实施例一个优选的方案中，通过所述第一用户的uuid无法为所述第一用户选择第一容器计算单元2111时，则控制器3根据所述第一用户的uuid定位所述第一用户的第一计算池单元21，在所述第一计算池单元21内查找有剩余计算资源的第三服务器213，并在所述第三服务器213上创建为所述第一用户提供计算服务的第四容器计算单元2131，将第三服务器213的域名和第四容器计算单元2131的域名添加至第一用户的映射列表中，并将所述第一用户数据存储单元212加载到所述第四容器计算单元2131。

在本发明实施例中，控制器能获取到第二逻辑中的全部服务器、容器计算单元的负载及计算情况，判断该服务器或者容器计算单元是否有剩余的计算资源。在一个方案中，控制器还能检测到服务器或者容器计算单元在策略时间内高于或者低于设定的阈值。

在本发明实施例中，第一用户的映射列表中存储为第一用户提供计算服务的第一容器计算单元域名时，可以构建第一用户uuid、计算池单元名称(poolname)、服务器域名(servicedomain)和第一容器计算单元(dockerdomain)的对应关系。在一个优选的方案中，在为第一用户重新选择容器计算单元提供计算服务时，例如第一计算池上的第二服务器的第三容器计算单元，则会在映射列表中增加第一用户的uuid、第一计算池单元名称(poolname)、第二服务器域名(servicedomain)和第三容器计算单元(dockerdomain)的对应关系表。在一个优选的方案中，如果需要删除为第一用户提供计算服务时的第一容器计算单元时(该第一容器计算单元设置在第一计算池单元的第一服务器上)，则会在第一用户的映射列表中删除第一用户的uuid、第一计算池单元名称(poolname)、第一服务器域名(servicedomain)和第一容器计算单元(dockerdomain)的对应关系表。

在本发明实施例中，将第一用户数据存储单元加载至第一容器计算单元，也即建立第一容器计算单元和第一用户数据存储单元的关联或者映射关系，第一容器计算单元可以根据用户的请求消息直接到对应的第一用户数据存储单元查找相应的用户数据。

在本发明实施例一个优选的方案中，所述控制器3在检测到第一逻辑单元1在策略时间内低于阈值时，控制器会选择减少所述第一逻辑使用的计算容器单元数量，但是在该种情形下，计算容器单元的数量不能为0；或者所述控制器3在检测到第一逻辑单元1策略时间内高于阈值时，增加所述第一逻辑单元1使用的计算容器单元的数量。

进一步的，在本发明实施例所提供的saas系统中，第二逻辑单元2还可以包括第二计算池单元、第三逻辑单元……和/或第n逻辑单元等，其中n为自然数。在一个优选的方案中，第二计算池单元上还包括一个或者多个服务器，该服务器上还可以包含一个或者多个容器计算单元，用来为向用户提供数据检索及计算服务。该一个或者多个服务器可以为一个或者多个用户提供计算或者检索服务。

在本发明实施例中，每个计算池单元可以包括共享式分布式的文件系统、kubenetes的管理节点、被管理的若干台服务器节点，以及容器域名服务列表等。

如图2所示，在本发明实施例所提供的多用户计算和io密集型saas系统中，第一用户u1进行saas应用的方法步骤如下：

s1、u1的服务请求api请求消息会首先统一发送至第一逻辑单元，由第一逻辑单元解析并处理后，输出u1的uuid和u1请求的数据标识；

具体的，u1的api中包含u1的通用唯一识别码(universallyuniqueidentifier,uuid)，以及所述u1所请求数据的数据标识，所述第一逻辑单元从所述u1的api请求信息中解析出对应的uuid以及所请求的数据标识；u1所请求的数据标识可以是待请求数据的索引、分类、或者其他标识信息。

s2、根据所述u1的uuid在所述saas系统中查找与u1对应的第一计算池单元、第一服务器以及第一容器计算单元；

具体的：第一逻辑单元解析到所述u1的uuid后，通过所述控制器获取在saas系统预先设置的uuid、第一计算池单元、第一服务器以及第一容器计算单元的对应关系表，根据所述u1的uud查找并计算与所述u1对应的第一计算池单元名称、第一服务器的域名以及第一容器计算单元的域名；

s3、第一逻辑单元将u1的api请求路由至第一容器计算单元；

具体的：控制器根据获取到的与u1的uuid相对应的第一计算池单元名称，第一服务器域名以及第一容器计算单元的域名，辅助第一逻辑单元将接收到的api请求逐级路由至对应的第一容器计算单元中，其中该第一容器计算单元设置在所述第一服务器上，而所述第一服务器设置在所述第一计算池单元上；

s4、第一容器计算单元接收到所述u1的api请求后，触发第一容器计算单元的计算和伸缩功能，以向第一用户数据存储单元获取所述u1所请求的用户数据；

s5、第一容器计算单元将获取到的用户数据通过第一逻辑单元返回给u1；

s6、可选地，如果第一容器计算单元在策略时间内超过阈值时，在第一服务器上分配第二容器计算单元为u1提供服务；或者在第二服务器上分配第三容器计算单元为u1提供服务；

例如，控制器检测在24小时内，第一容器计算单元的计算或者访问次数超过10000次的，则认为第一计算单元在策略时间内超过阈值，同时判断该第一服务器上还有处于空闲态的容器计算单元时，则为第一用户在第一服务器上选择第二容器计算单元进行计算服务；如果该第一服务器上没有处于空闲态的容器计算单元时，则为第一用户在第二服务器上选择第三容器计算单元进行计算服务。控制器还将为第一用户重新分配的第二容器计算单元、第三容器计算单元或第二服务器的域名更新至第一用户的映射列表中。

s7、可选地，如果第一容器计算单元或者第一服务器在策略时间内低于阈值时，则所述控制器删除第一用户映射列表中的第一容器计算单元或者第一服务器的域名；

例如，控制器检测在24小时内，第一容器计算单元或者第一服务器的计算或者访问次数超过100次的，则认为第一计算单元或者第一服务器在策略时间内低于阈值，控制器在第一用户的映射列表中删除第一服务器的域名或者第一计算单元的域名。删除完成后，控制器无法再为第一用户定位到该第一容器计算单元或者第一服务器。

s8、可选地，控制通过所述第一用户的uuid无法为所述第一用户选择第一容器计算单元时，则可以为第一用户重新分配容器计算单元。

具体的，控制器根据所述第一用户的定位所述第一用户的第一计算池单元，在所述第一计算池单元内查找有剩余计算资源的第三服务器，并在所述第三服务器上创建为所述第一用户提供计算服务的第四容器计算单元，将第三服务器的域名和第四容器计算单元的域名更新至第一用户的映射列表中，并将所述第一用户数据存储单元加载到所述第四容器计算单元。

实施例二：

本发明实施例提供了一种多用户saas应用的构建方法，应用如实施例一所提供的一种多用户计算和io密集型saas系统，所述方法包括：

2.1在saas系统中构建第一逻辑单元和第二逻辑单元，并建立第一逻辑单元与第二逻辑单元的镜像关系，具体的：

在saas系统中部署kubernetes的基础框架，搭建容器(docker)镜像库为用户的第一逻辑单元(logic1)和第二逻辑单元(logic2)提供镜像，在部署了kubernetes的基础框架的saas系统中，能将用户的api请求从第一逻辑单元镜像到第二逻辑单元进行处理。第一逻辑单元包括请求预处理，认证等应用相关公共性逻辑，是无状态的，是不涉及密集计算和存储的逻辑部分。第二逻辑单元需要用户数据并加载至内存，配合大量计算得出结果。

2.2初始化saas系统中的nfs网络文件系统，用于使得第一用户(u1)和第二用户(u2)进行注册，并返回nfs网络文件系统的两个接入点。

其中：用户在saas系统中进行注册，可以采用多种注册方式，本发明实施例中是以nfs网络文件系统的方式进行注册为例进行说明。

2.3为了实现saas系统中将用户的api请求从第一逻辑单元路由至第一容器计算单元，需要在所述saas系统中部署控制器，该控制器能将所述用户的api请求从第一逻辑单元路由至第一容器计算单元。

为实现该控制器的调度功能，需要为该控制器设定的调度程序的逻辑如下：

2.3.1设定每个计算池(pool)中包含n个服务器，n个服务器在同一个网络内，其中n是自然数，该n个服务器中均设置一个或者多个容器计算单元，例如第一容器计算单元、第二容器计算单元，……，第n容器计算单元，每个容器计算单元均包含逻辑计算功能和容器(docker)伸缩功能；

2.3.2每一个新用户向saas系统进行注册时，该saas系统就会为该新用户分配一个32位uuid，作为唯一的识别码，例如：例如为第一用户分配的uuid为：00000000-1111-0000-c000-000000000048。

2.3.3通过一致性哈希算法将新用户uuid映射到现有的计算池单元内，例如江第一用户映射到第一计算池单元内。

2.3.4控制器为新用户开通容器计算单元，具体的：控制器预先根据所述第一用户的uuid定位所述第一用户所在的所述第一计算池，在所述第一计算池里面查找有剩余计算资源，例如第一服务器上有剩余计算资源时，控制器在第一服务器上为第一用户开通容器计算单元来提供计算服务，例如开通第一容器计算单元来为第一用户提供计算服务等。采用同样的方法可以为第二用户、第n用户选择服务器和容器计算单元。

2.3.5控制器在计算池单元内为每个用户分配用户存储单元，例如在第一计算池单元中为第一用户分配第一用户数据存储单元，并将所述第一用户数据存储单元加载至第一容器计算单元上。第一容器计算单元可以实现在所述第一用户数据存储单元上进行数据的写入和读取。采用同样的方法可以为第二用户、第n用户分配用户数据存储单元，并将分配的用户数据存储单元加载至对应的容器计算单元上。用户存储单元上构建uuid与用户数据的独立目录data-uuid，用来根据uuid对用户数据进行索引，该独立目录的权限赋值给用户的uuid。

2.3.6开通新用户的用户数据存储单元后，还要为该用户开通kubernetesmaster容器，每个用户的服务器注册在kubernetesmaster容器中。

2.3.7控制器还可以收集和监控每个计算池下所有服务器以及容器计算单元的cpu和内存使用量。

2.3.8每个服务器可以设定默认分配给容器计算单元可用的cpu，内存以及网络带宽上限等资源；单个服务器内多个容器计算单元可以共享cpu，内存和网络带宽资源。

2.3.9预设每个容器计算单元cpu和内存的扩容触发边界值。

2.3.10如果一个用户应用需要更多容器计算单元，当容器计算单元的cpu或内存任意达到边界值触发扩容，控制器用kubenetesmaster调度一个容器计算单元在这个计算池下。

2.3.11检测计算池中每个服务器cpu和内存，确保一个计算池内预留足够的服务器，能够开通未来突发情况下开通容器计算单元。

2.4在该saas系统中，可以通过dns系统来寻址帮助第一逻辑单元到第二逻辑单元间的路由，可以使用kube-dns程序实施。第二逻辑单元中的每个容器计算单元的路由信息由控制器统一管理，第一逻辑单元通过控制器定位用户所在的容器计算单元。

2.5在saas系统中，控制器进行路由和寻址的程序，其定义逻辑如下：

2.5.1初始化saas系统中的计算池单元列表。开通计算池单元逻辑实际就是初始化域名(domain)，计算池单元名称(poolname)就是domainname，可以先初始化2个计算池，第一计算池单元(pool1)和第二计算池单元(pool2)。

2.5.2每个用户可以分配一个服务器域名(servicedomain)，也即计算池单元内服务器的域名，为该用户提供寻址路由服务。计算池中容器计算单元(docker)功能开通后，用户的servicedomain需要在dns系统上注册容器计算单元(dockerip)与服务器(servicedomain)关联的记录a，该关联的记录a可以使用uuid-svc.pool-name表示，该关联记录包括用户、计算池单元、计算池单元内的服务器以及服务器上的容器计算单元之间的映射关系；

2.5.3第一逻辑单元(logic1)将接收到的用户的服务请求处理完毕，解析出用户的uuid后，触发控制器启动寻址路由程序；

2.5.4控制器启动寻址路由程序时，可以依据用户的uuid，到dns服务器查找对应的计算池、服务器以及对应的容器计算单元，并寻址调用第容器计算单元的逻辑功能。

2.5.5如果容器计算单元的接口无法访问，可以调用调度程序开通一个新的容器计算单元。

2.5.6当控制器为用户扩容多个容器计算单元后，每个容器计算单元的ip都绑定到一个服务域名里。

2.5.7如果一个用户对应的服务器中有多个容器计算单元，则在第一逻辑单元与第一容器计算单元镜像及计算时，kubernetesservice会依次调用多个容器计算单元，尽量做到负载均衡。

2.6服务器上所设置的第一容器计算单元内部的算法程序逻辑包括：

2.6.1第一容器计算单元挂载共享存储data，程序逻辑读取data-uuid目录里的数据加载至内存。

2.6.2预设定请求最小间隔时间触发容器单元回收，例如该最小时间间隔为1小时。

2.6.3控制器为容器计算单元维护一个lastrequesttimestamp记录并更新每一次接收检索请求的时间戳。

2.6.4如果当前时间减lastrequesttimestamp间隔大于最小间隔时间，触发关闭该容器单元。

2.7容器计算单元在没有计算处理时间内，其他容器计算单元可以占用服务器资源做到资源共享。

2.8当服务器节点宕机后，不必采取措施重新调度。当用户发送api请求给第一逻辑单元时，直接执行步骤2.5.5，为用户重新开通新的容器计算单元，来实现新的寻址路由调度。

实施例三

如图3所示，本发明实施所提供的一种用户计算和io密集型saas系统，所述saas系统包括存储器301和处理器302，其中：

所述存储器301，用于存储代码和相关数据；

所述处理器302，用于执行所述存储器301中的代码和相关数据用以实现前述实施例一和实施例二中的方法步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所属技术领域的技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，并被通讯设备内部的处理器执行，前述的程序在被执行时处理器可以执行包括上述方法实施例的全部或者部分步骤。其中，所述处理器可以作为一个或多个处理器芯片实施，或者可以为一个或多个专用集成电路(applicationspecificintegratedcircuit，asic)的一部分；而前述的存储介质可以包括但不限于以下类型的存储介质：闪存(flashmemory)、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。