技术领域
[0001] 本
发明涉及
服务器端的
软件开发和运维系统领域，特别是涉及一种新旧代码共同运行的kbroker分布式操作系统。
背景技术
[0002] 鉴于kbroker分布式操作系统的开发方法虽然是最
基础最传统的开发方法，但和现有服务端的开发方法并不相同，这就导致了现有大量已经开发的业务逻辑代码无法在kbroker分布式操作系统上运行，如果要将现有的业务迁移到kbroker分布式系统上运行就需要重写代码，这个迁移成本无疑是难以接受的；同时大家也一定程度上习惯了现有的开发方法，虽然改变并不是很难，但提供一种兼容现有开发方法的解决方案也是很有价值的；最后原有的开发方法下需要用到很多缓存和
数据库之类的辅助组件，在运行时需要运维人员考虑这些辅助组件的灾备和监控等工作，而在kbroker分布式系统上这些工作都是由系统本身来提供的，如何在支持现有代码运行的同时对其使用到的辅助组件进行灾备支持也是需要考虑的。
发明内容
[0003] 鉴于以上所述
现有技术的缺点，本发明的目的在于提供一种新旧代码共同运行的kbroker分布式操作系统，用于解决现有技术中的问题：
[0004] 第一，现有代码无法简单的迁移到kbroker分布式系统上运行。
[0005] 第二，开发者无法按照原来开发方法开发kbroker分布式系统上的应用程序。
[0006] 为解决上述技术问题，本发明是按如下方式实现的：一种新旧代码共同运行的kbroker分布式操作系统，其特征在于，包括：
[0007] 业务层模
块，用于实现整个系统的业务逻辑；所述业务逻辑被拆分成若干个应用程序，每个应用程序包括与之对应的一组app_allocator模块和至少一组app_service模块；
[0008] app_service模块，用于运行应用程序的app_object对象，对kbroker分布式操作系统内提供统一的
接口访问在其上运行的app_object对象，并且对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口；业务逻辑由运行在app_service模块上的业务层app_object对象的逻辑处理以及app_object对象之间的相互调用实现；
[0009] app_allocator模块，用于管理应用程序逻辑运行所需的app_service模块的启动和关闭、app_object对象的创建和删除，并且管理和分配app_object对象在app_service模块运行；app_allocator模块将app_service模块进行分组，为每个分组设置分组编号，该分组编号为virtual_id编号，负责分组内app_service模块的主从灾备；
[0010] kbroker_server模块，用于管理kbroker分布式操作系统中其所在的服务器，kbroker_server模块管理其所在服务器上的app_service模块、app_allocator模块和存储型资源；多个kbroker_server模块之间数据通信连接；
[0011] kbroker_super模块，用于通过kbroker_server模块管理kbroker_server模块所在的服务器；通过kbroker_server模块管理kbroker分布式操作系统中的所有程序
进程，并为每个程序进程设置进程编号program_id；管理业务层应用程序，并为每个业务层应用程序设置应用程序编号app_id；
[0012] app_object对象由应用程序的app_id编号和应用程序上的对象object_id编号来标识；app_object对象的运行模式包括标准模式和扩展模式；标准模式用于新代码的编写和运行；在标准模式下，app_object对象运行在app_service模块的程序内部，通过app_service模块提供的
内部接口与kbroker分布式操作系统进行数据交互；扩展模式用于老代码的运行；在扩展模式下，app_object对象的逻辑处理作为业务层独立执行程序运行在app_service模块外部，通过外部接口与app_service模块连接以实现相同kbroker分布式操作系统的数据交互。
[0013] 进一步地，存储型资源为用于保存数据防止kbroker分布式操作系统重启后丢失数据或临时保存数据的存储介质，
[0014] 存储型资源的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署；当存储型资源的部署方式为在kbroker分布式系统内部署时，由kbroker_server模块负责创建在其所在的服务器上，由kbroker_super模块负责管理；当存储型资源部署方式为在kbroker分布式操作系统外部署时，提供访问接口给kbroker分布式系统内的应用程序进行调用。
[0015] 进一步地，app_allocator模块用于管理app_service模块的主从灾备，[0016] 所有应用程序的app_service模块都支持主从灾备，将app_service模块不需要主从灾备的应用程序作为只有主没有从的特例处理；
[0017] app_allocator模块将app_service模块进行分组，每个分组至少有一个app_service模块作为该分组的主app_service模块；每个分组还包括存在从app_service模块模式和不存在从app_service模块模式，所述存在从app_service模块模式为app_service模块需要主从灾备，所述不存在从app_service模块模式为app_service模块不需要主从灾备，并且app_allocator模块用于管理维护该分组内app_service模块的主从灾备；
[0018] app_allocator模块分配app_object对象到具体分组的主app_service模块上运行，所有
请求访问发送到该对应的主app_service模块上进行响应处理，需要主从灾备的从app_service模块由该分组的主app_service模块同步数据；
[0019] 当现有分组无法满足该应用程序的app_object对象的运行需要时，app_allocator模块用于创建新的分组和启动新分组内新的app_service模块。
[0020] 进一步地，app_allocator模块管理和分配app_object对象，
[0021] app_allocator模块分配一个app_object对象在一个分组的主app_service模块上运行，并对系统内提供请求该app_object对象的路由信息接口；
[0022] 应用程序的app_object对象与app_service模块分组的关系包括关联关系和非关联关系；
[0023] 当应用程序的app_object对象与app_service模块分组的关系为关联关系时，应用程序的app_allocator模块保存object_id编号和virtual_id编号的关联关系、app_service模块分组与其分组内app_service模块的关联关系；启动该app_object对象时找到其关联virtual_id编号对应分组的主app_service模块进行启动和运行；创建app_object对象时先选择一个分组，然后保存object_id编号和virtual_id编号的关联关系；
[0024] 当应用程序的app_object对象与app_service模块分组的关系为非关联关系时，app_allocator模块启动该app_object对象时从所有正在运行的分组中选择一个分组，然后在被选择分组的主app_service模块上启动和运行该app_object对象。
[0025] 进一步地，app_service模块运行该应用程序app_object对象的业务逻辑，[0026] 一个app_object对象在同一个时间段运行在唯一一个该应用程序的app_service模块上，一个app_service模块同时运行多个该应用程序的app_object对象；
[0027] app_service模块根据app_allocator模块的命令创建并记录在其上运行的app_object对象，app_object对象的逻辑由业务层实现，启动和关闭app_object对象的运行由app_service模块负责；
[0028] app_service模块提供主从灾备
框架，在app_object对象需要主从灾备的情况下配合业务层实现主从灾备。
[0029] 进一步地，app_service模块提供统一的接口访问在其上运行的app_object对象，[0030] 当app_object对象运行在标准模式下，利用协程解决逻辑运行中的阻塞问题，其业务逻辑在app_service模块上的一个单线程上运行，所有请求封装成协程排队依次执行；通过重写app_object对象的虚基类app_object_i实现业务逻辑和响应外部请求；
[0031] 当app_object对象运行在扩展模式下，其业务逻辑运行在独立于app_service模块的业务层独立执行程序上，app_service模块将系统内对其上运行app_object对象的函数型请求访问和通知型请求访问转换成该业务层独立执行程序支持的接口进行调用处理。
[0032] 进一步地，当app_object对象运行在扩展模式下，业务逻辑运行在独立于app_service模块的业务层独立执行程序上，
[0033] 当app_object对象运行在扩展模式下，其业务逻辑运行在业务层独立执行程序上，由一个或者多个业务层独立执行程序及其附属组件共同完成了app_object对象的业务逻辑运行，并与其对应的app_service模块一起组成一组app_object对象的运行集合，响应处理kbroker分布式操作系统内对其上运行app_object对象的请求访问；
[0034] app_service模块用于接收kbroker分布式操作系统内对其上运行的app_object对象的请求访问，并将请求访问转发给app_object对象所在业务层执行程序以完成响应处理；业务层执行程序为app_service模块提供访问其上运行的app_object对象的访问接口。
[0035] 进一步地，kbroker分布式操作系统对app_object对象的请求访问包括需要返回值的函数型请求访问和不需要返回值的通知型请求访问。
[0036] 进一步地，app_object对象的业务层独立执行程序用于app_object对象的逻辑运算，附属组件为扩展模式下app_object对象对应的存储型资源；附属组件的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署。当附属组件部署方式为在kbroker分布式系统外部署时，和传统部署方式一致；当附属组件部署方式为在kbroker分布式系统内部署时，其部署方式包括独立部署和应用程序部署；
[0037] 当附属组件的部署方式为独立部署时，附属组件为每组业务层独立执行程序独享的存储型资源，与业务层执行程序部署在一起，app_service模块提供对附属组件的主从灾备，每组业务层独立执行程序对应的所有附属组件作为kbroker分布式操作系统内的一个存储型资源，并且由kbroker_super模块选择kbroker_server模块进行创建和管理；
[0038] 当附属组件的部署方式为应用程序部署时，为附属组件单独创建一个应用程序，该应用程序为存储型应用程序，用于管理辅助组件对应的存储型资源，业务层通过访问该应用程序的app_object对象来访问附属组件。
[0039] 进一步地，app_service模块对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口，
[0040] 当app_object对象运行在标准模式下，业务层直接调用app_service提供的内部函数调用接口，访问其他app_object对象函数型调用的接口通过协程化处理来避免阻塞，同时提供添加异步事件、延时事件、协程化的
锁和
信号的接口；
[0041] 当app_object对象运行在扩展模式下，app_service模块提供接口扩展给业务层使用；app_service模块访问其他app_object对象函数型调用的接口为一个阻塞型的远程调用，由业务层处理阻塞事件对app_object对象逻辑运行的影响，同时提供添加异步事件、延时事件和锁操作的接口，添加的异步和延时事件由app_service模块进行保存，然后再回调业务层执行程序进行执行处理。
[0042] 如上所述，本发明的一种应用于多台服务器的分布式操作系统，具有以下有益效果：
[0043] 第一，现有代码可以经过简单的接口
修改就可以迁移到kbroker分布式操作系统上运行；
[0044] 第二，对现有代码用到的附属组件做灾备支持，降低现有代码迁移后在kbroker分布式系统上运行的运维难度和增加运行的安全性；
[0045] 第三，提供开放者基于现有开发方法开发kbroker分布式操作系统上应用程序的能
力。
附图说明
[0046] 图1显示为本发明
实施例中一种应用于多台服务器的分布式操作系统的模块结构示意图。
具体实施方式
[0047] 以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本
说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
[0048] 需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。
[0049] 本发明提供一种新旧代码共同运行的kbroker分布式操作系统，业务层模块用于实现整个系统的业务逻辑，业务逻辑被拆分成若干个应用程序，每个应用程序包括与之对应的一组app_allocator模块、至少一组app_service模块。app_service模块，用于运行应用程序的app_object对象，对kbroker分布式操作系统内提供统一的接口访问在其上运行的app_object对象，并且对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口；业务逻辑由运行在app_service模块上的业务层app_object对象的逻辑处理以及app_object对象之间的相互调用实现。app_allocator模块，用于管理应用程序逻辑运行所需的app_service模块的启动和关闭、app_object对象的创建和删除，并且管理和分配app_object对象在app_service模块运行；app_allocator模块将app_service模块进行分组，为每个分组设置virtual_id编号，负责分组内app_service模块的主从灾备。kbroker_server模块，用于管理kbroker分布式操作系统中其所在的服务器，kbroker_server模块管理其所在服务器上的app_service模块、app_allocator模块和存储型资源；多个kbroker_server模块之间数据通信连接。kbroker_super模块，用于通过kbroker_server模块管理kbroker_server模块所在的服务器；通过kbroker_server模块管理kbroker分布式操作系统中的所有程序进程，并为每个程序进程设置进程编号program_id；管理业务层应用程序，并为每个业务层应用程序设置应用程序编号app_id。app_object对象由应用程序的app_id编号和应用程序上的对象object_id编号来标识；app_object对象的运行模式包括标准模式和扩展模式；标准模式用于新代码的编写和运行；在标准模式下，app_object对象运行在app_service模块的程序内部，通过app_service模块提供的内部接口与kbroker分布式操作系统进行数据交互；扩展模式用于老代码的运行；在扩展模式下，app_object对象的逻辑处理作为业务层独立执行程序运行在app_service模块外部，通过外部接口与app_service模块连接以实现相同kbroker分布式操作系统的数据交互。
[0050] 存储型资源为用于保存数据防止kbroker分布式操作系统重启后丢失数据或临时保存数据的存储介质，可以为磁盘等计算机的存储介质，也可以为独立的第三方执行程序。
[0051] 存储型资源的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署；当存储型资源的部署方式为在kbroker分布式系统内部署时，由kbroker_server模块负责创建在其所在的服务器上，由kbroker_super模块负责管理；当存储型资源部署方式为在kbroker分布式操作系统外部署时，提供访问接口给kbroker分布式系统内的应用程序进行调用。
[0052] 整个系统都是为了达成业务逻辑由app_object对象的逻辑处理和app_object对象之间的相互调用实现这一目标而进行的，通过app_allocator模块来实现对app_object对象的管理和分配，通过app_service模块封装app_object对象的逻辑处理以及对外部请求的响应处理。在系统的层面实现每个app_object对象一个时间只运行在一个app_service模块上，该app_service模块负责接收所有对该app_object对象的访问请求，并将这些请求交给该app_object对象进行处理。app_service模块就是为了实现对app_object对象的封装而存在的，由其屏蔽了app_object对象实现上的差异。实现对app_object对象封装到app_service模块运行本质上是解决阻塞型调用对app_object对象业务逻辑处理的影响，解决途径上主要有三种：一是用多进程解决阻塞问题、二是用多线程解决阻塞问题、三是用协程解决阻塞问题。其中原kbroker分布式操作系统中使用的就是用协程方式来解决阻塞问题，对应于本
专利中的标准模式；现有常见的服务端程序一般通过多进程或多线程的方式来解决阻塞问题，也有用异步调用方式来解决阻塞问题的，但异步调用的解决方案会导致代码逻辑分散而增加编写的复杂度，对于现有程序的封装对应于本专利的扩展模式。
[0053] app_allocator模块用于管理app_service模块的主从灾备，所有应用程序的app_service模块都支持主从灾备，将app_service模块不需要主从灾备的应用程序作为只有主没有从的特例处理。app_allocator模块将app_service模块进行分组，每个分组至少有一个app_service模块作为该分组的主app_service模块；每个分组还包括存在从app_service模块模式和不存在从app_service模块模式，所述存在从app_service模块模式为app_service模块需要主从灾备，所述不存在从app_service模块模式为app_service模块不需要主从灾备，并且app_allocator模块用于管理维护该分组内app_service模块的主从灾备。app_allocator模块分配app_object对象到具体分组的主app_service模块上运行，所有请求访问发送到该对应的主app_service模块上进行响应处理，需要主从灾备的从app_service模块由该分组的主app_service模块同步数据。当现有分组无法满足该应用程序的app_object对象的运行需要时，app_allocator模块创建新的分组和启动新分组内新的app_service模块。
[0054] app_service模块默认支持主从灾备使得系统的健壮性和可靠性得到增强，降低了运行时的维护工作。将支持主从灾备作为常态，不支持主从灾备作为只有主没有从的特例来处理，一方面支持各种情况下对主从灾备的需求而不仅仅只是在有存储型资源时才支持主从灾备可以更好的增强系统的
稳定性，另外还可以用统一一套逻辑系统同时处理支持和不支持主从灾备两种情况，从而大大减少了代码维护的复杂度。上述app_allocator模块实现的是主从灾备的管理模块，其将与app_service模块实现的主从灾备的处理模块配合起来实现对app_service模块的主从灾备。
[0055] app_allocator模块管理和分配app_object对象，app_allocator模块分配一个app_object对象在一个分组的主app_service模块上运行，并对系统内提供请求该app_object对象的路由信息接口，路由信息为该app_object对象具体运行在哪个主app_service模块。应用程序的app_object对象与app_service模块分组的关系包括关联关系和非关联关系。当应用程序的app_object对象与app_service模块分组的关系为关联关系时，应用程序的app_allocator模块保存object_id编号和virtual_id编号的关联关系、app_service模块分组与其分组内app_service模块的关联关系；启动该app_object对象时找到其关联virtual_id编号对应分组的主app_service模块进行启动和运行；创建app_object对象时先选择一个分组，然后保存object_id编号和virtual_id编号的关联关系。当应用程序的app_object对象与app_service模块分组的关系为非关联关系时，app_allocator模块启动该app_object对象时从所有正在运行的分组中选择一个分组，然后在被选择分组的主app_service模块上启动和运行该app_object对象。
[0056] 上述操作是基于app_service模块都以支持主从灾备的情况下处理的，因为都支持主从灾备，区别只是有没有从app_service模块而已，这就决定了app_object对象的分配是基于app_service模块的主从灾备分组的，app_object对象是运行在其对应主从灾备分组的主app_service模块上的。app_object对象是否和app_service模块分组关联绑定解决的是每次启动后app_object对象是否还需要分配到上次分配的app_service模块分组的问题，原始kbroker分布式操作系统上的存储型应用程序对应的就是app_object对象和app_service模块绑定的情况，本专利中用关联绑定关系标识启动后app_object对象是否还需要分配到原来的app_service模块分组，在处理原本存储型应用程序的基础上为处理更多可能类似的情况留出空间。
[0057] 关联情况下，app_allocator模块保存app_object对象的object_id编号和app_service模块分组的virtual_id编号的关联关系是保存到非易失性存储介质上；保存app_service模块分组与其分组内app_service模块的关联关系也是保存到非易失性存储介质上，由于app_service模块的program_id编号在重新启动后是会变化的，关联关系主要是保存那些可以标记app_service模块具体在哪个kbroker_server模块上的相关信息而非app_service模块的program_id编号，比如存储型应用程序app_service模块用到的存储型资源。
[0058] app_service模块运行该应用程序app_object对象的业务逻辑，一个app_object对象在同一个时间段运行在唯一一个该应用程序的app_service模块上，一个app_service模块同时运行多个该应用程序的app_object对象。app_service模块根据app_allocator模块的命令创建并记录在其上运行的app_object对象，app_object对象的逻辑由业务层实现，启动和关闭app_object对象的运行由app_service模块负责。app_service模块提供主从灾备框架，在app_object对象需要主从灾备的情况下配合业务层实现主从灾备。
[0059] app_service模块负责封装app_object对象，使得在系统中调用时屏蔽掉app_object对象实现的差异。这里提供的标准模式对应于原本kbroker分布式操作系统中的app_object对象的逻辑处理方案，扩展模式用于兼容运行现有代码或者以现有大家熟悉的开发方式进行开发，核心差别就是标准模式中业务逻辑和app_service模块是合二为一的，扩展模式下业务逻辑和app_service模块运行在彼此独立的执行程序，通过相互之间的接口访问来彼此之间的消息交互，这样就可以实现现有的代码以其正常运行的模式进行运行，从而尽可能少的代码改动就可以将原有代码迁移到kbroker分布式系统上运行，同时也使得开发者可以按照原来开发方式在kbroker分布式系统上进行应用程序的开发。
[0060] app_service模块提供主从灾备框架，主从灾备框架由每一个app_service模块内独立的主从灾备模块，配合app_allocator模块对应的主从灾备管理模块实现。主app_service模块通过主从灾备模块来对从app_service模块发送同步信息，从app_service模块通过主从灾备模块接收同步信息并执行。app_service模块中每项需要主从同步的逻辑模块都注册到其主从灾备模块中，每项逻辑模块发送的同步信息和同步信息的执行逻辑都由该项逻辑模块自己定义，主app_service模块上每一项逻辑模块发送的同步信息通过主从灾备模块传递到从app_service模块的主从灾备模块，再由从app_service模块的主从灾备模块传递给对应的逻辑模块来处理同步信息。app_service模块的主从灾备模块为实现主从灾备过程中的主从切换、从app_service模块到主app_service模块的注册、数据导出导入等功能提供框架支持，其中数据导出和导入、同步信息的发送和执行、从切换到主之后的处理工作由每个需要同步的逻辑模块自己实现，其他的统一逻辑都由主从灾备框架实现。
[0061] app_service模块提供统一的接口访问在其上运行的app_object对象，当app_object对象运行在标准模式下，利用协程解决逻辑运行中的阻塞问题，其业务逻辑在app_service模块上的一个单线程上运行，所有请求封装成协程排队依次执行；通过重写app_object对象的虚基类app_object_i实现业务逻辑和响应外部请求。当app_object对象运行在扩展模式下，其业务逻辑运行在独立于app_service模块的业务层独立执行程序上，app_service模块将系统内对其上运行app_object对象的函数型请求访问和通知型请求访问转换成该业务层独立执行程序支持的接口进行调用处理。
[0062] 标准模式就是原本kbroker分布式操作系统提供的解决方案，主要是通过协程来解决阻塞问题，进而将app_object对象运行在同一个线程上支持app_service模块对其接口进行直接调用。
[0063] 当app_object对象运行在扩展模式下，业务逻辑运行在独立于app_service模块的业务层独立执行程序上。当app_object对象运行在扩展模式下，其业务逻辑运行在业务层独立执行程序上，由一个或者多个业务层独立执行程序及其附属组件共同完成了app_object对象的业务逻辑运行，并与其对应的app_service模块一起组成一组app_object对象的运行集合，响应处理kbroker分布式操作系统内对其上运行app_object对象的请求访问。app_service模块用于接收kbroker分布式操作系统内对其上运行的app_object对象的请求访问，并将请求访问转发给app_object对象所在业务层执行程序以完成响应处理；业务层执行程序为app_service模块提供访问其上运行的app_object对象的访问接口。kbroker分布式操作系统对app_object对象的请求访问包括需要返回值的函数型请求访问和不需要返回值的通知型请求访问。
[0064] 扩展模式是将原来的代码部署成多个小的执行分组，每个分组都由运行原来代码的原业务层执行程序支持原来所有的功能但支持的负载范围(app_object对象数量)比较小，将每个分组和app_service模块组合封装在一起，然后通过系统同时运行多个app_service模块与其原业务层执行程序分组的方式支持所有的负载范围。系统负责将app_object对象的访问分配到对应的app_service模块上运行，app_service模块将访问转换成运行原业务层执行程序可以支持的接口以处理访问。为了实现app_service模块和原业务层执行程序的组合封装，需要用容器将原业务层执行程序进行封装，app_service模块负责实现容器功能以及实现与容器内外的通信连接，原业务层执行程序及其附属组件运行在容器内提供接口支持app_service模块的调用，app_service模块将系统发送的访问请求转换后交给容器内业务层执行程序进行处理。原业务层执行程序利用这样的封装就对外展现为运行一定数量app_object对象的运行集合，实现了迁移运行原代码到kbroker分布式操作系统。
[0065] 扩展模式的app_object对象由一个或者多个业务层独立执行程序及其附属组件共同完成了app_object对象的业务逻辑运行，app_object对象的业务层独立执行程序用于app_object对象的逻辑运算，附属组件在通常情况下是用于扩展模式下的app_object对象的数据存储；附属组件为扩展模式下app_object对象对应的存储型资源，附属组件的部署方式包括在kbroker分布式系统内部署和在kbroker分布式系统外部署。当附属组件部署方式为在kbroker分布式系统外部署时，和传统部署方式一致；当附属组件部署方式为在kbroker分布式系统内部署时，其部署方式包括独立部署和应用程序部署。当附属组件的部署方式为独立部署时，附属组件为每组业务层独立执行程序独享的存储型资源，与业务层执行程序部署在一起，app_service模块提供对附属组件的主从灾备，每组业务层独立执行程序对应的所有附属组件作为kbroker分布式操作系统内的一个存储型资源，并且由kbroker_super模块选择kbroker_server模块进行创建和管理。当附属组件的部署方式为应用程序部署时，为附属组件单独创建一个应用程序，该应用程序为存储型应用程序，用于管理辅助组件对应的存储型资源，业务层通过访问该应用程序的app_object对象来访问附属组件。
[0066] 对于原有代码的迁移，最需要修改的就是针对保存数据的附加组件的连接操作部分，这些附加组件主要是缓存和数据库，其他例如消息队列、延时程序之类的都由系统提供的接口来处理。附属组件原有的传统部署方式是将其单独部署，然后提供访问接口给执行程序调用，当附属组件在kbroker分布式系统外部署时可以像之前传统的部署方式一样进行部署。当附属组件在kbroker分布式系统内部署时，缓存和数据库最简单的部署方式就是和原有业务层执行程序一起部署在同一个容器里，然后通过系统提供的访问类库进行访问，使用系统提供的访问类库是为了可以在进行访问操作的同时对对应的从附加组件进行消息同步从而实现主从灾备；另外一种改进形式的部署方式就是将其实现成对应的存储型应用程序，这样很方便的就实现了对附加组件的管理和灾备，原有直接访问附加组件的方式通过替换成对新的存储型应用程序的对象访问就可以了。
[0067] app_service模块对业务层提供访问kbroker分布式操作系统内其他app_object对象的接口，当app_object对象运行在标准模式下，业务层直接调用app_service提供的内部函数调用接口，访问其他app_object对象函数型调用的接口通过协程化处理来避免阻塞，同时提供添加异步事件、延时事件、协程化的锁和信号的接口。当app_object对象运行在扩展模式下，app_service模块提供接口扩展给业务层使用；app_service模块访问其他app_object对象函数型调用的接口为一个阻塞型的远程调用，由业务层处理阻塞事件对app_object对象逻辑运行的影响，同时提供添加异步事件、延时事件和锁操作的接口，添加的异步和延时事件由app_service模块进行保存，然后再回调业务层执行程序进行执行处理。
[0068] 整个系统的核心关键就是处理远程调用引起的阻塞问题，从而使得一个app_object对象的业务逻辑可以在一个app_service模块上运行，kbroker分布式操作系统原本提供的解决方案是通过协程的模式处理调用引起的阻塞问题，传统的服务端开发是通过多进程的方式来处理远程调用引起的阻塞问题，从技术的实现能力上来看无论是进程、线程、协程都可以处理调用引起的阻塞问题。标准模式下由系统直接提供基于协程的远程或者本地调用，业务层就不需要关心阻塞问题了，在扩展模式下，系统提供的是阻塞型的调用接口，利用原本代码中采用的多进程或者多线程的方式来处理阻塞问题，从而在两种模式下都能实现将一个app_object对象的全部业务逻辑放在一个app_service模块上运行的目标。扩展模式下提供的延时和异步接口是为了替换掉传统服务端开发中用到的消息队列和定时回调，从而更方便进行部署和维护。
[0069] 原始kbroker分布式操作系统中kbroker_super模块和kbroker_server模块改动不大，主要是在app_allocator模块和app_service模块上的改动。
[0070] app_allocator模块功能改动主要集中于将所有的app_service模块作为支持主从灾备来处理，将支持主从灾备的app_service模块作为常态，而将不支持主从灾备的app_service模块作为特例，从而在支持业务层各种主从灾备需求的情况下实现统一处理和增强系统的可用性。
[0071] 标准模式下的app_service模块也是提供一个类库给业务层使用，其和原始kbroker分布式操作系统提供的app_service类库的核心功能一致，主要改动是增加主从灾备的管理模块，使得可以各种类型的app_service模块都可以很方便的在app_allocator模块的配合下实现对其自身各个逻辑模块和附加组件的主从灾备。
[0072] 扩展模式下的app_service模块也是提供一个类库给业务层使用，原始kbroker分布式操作系统app_service类库提供的路由缓存和当前运行的app_object对象等功能也之前的一致，创建、启动和关闭app_object对象的接口由业务层调用业务层独立执行程序提供的接口实现；另外业务层主要编写将系统内对其app_object对象的访问请求转换成业务层独立执行程序访问接口的策略。扩展模式下的app_service模块提供一个给业务层使用的扩展库文件用于业务层访问app_service模块，该扩展文件通过
进程间通信方式连接到app_service模块上进行数据交互。
[0073] 现有开发模式下开发的代码，一般会有缓存和数据库等负责保存数据的组件，业务代码负责逻辑处理且与具体的app_object对象无关，业务代码运行时根据参数从缓存或者数据库中获取对应app_object对象的数据重建app_object对象，然后再执行对应的逻辑处理。迁移现有代码时，将缓存和数据库等保存数据的组件归为app_service模块管理和实现主从灾备并提供访问接口给业务层代码调用，现有代码在替换了数据访问接口后按照原有的运行方式进行部署和运行。总体上来看，就是kbroker分布式操作系统通过app_object对象的模式将访问拆分到多个app_service模块上进行处理，每个app_service模块使用原有代码部署运行一个小规模的原有服务来支持访问，再加上系统对数据保存组件提供主从灾备，这就实现了现有代码迁移到kbroker分布式系统上运行。
