一种算法集成服务框架系统的制作方法

本发明涉及计算机软件后端服务开发领域，特别是一种算法集成服务框架系统。

背景技术：

当前计算机软件后端服务开发领域，后台进程之间的数据交互是非常普遍的需求。对于“智能安防+ai”领域下的后端服务开发需求中，相比传统领域的后端服务数据交互，又有其独有的业务复杂性与更高的性能要求，具体表现在：

1、业务场景灵活多变，功能需求多变，重构需求大

面对不同需求方，时长有不同的定制化需求，需要针对性的进行新的开发、修改、重构等工作。

2、功能模块多，接入需求更强

针对新增需求的算法/业务处理功能模块接入，以及旧的功能模块升级等。新接入的算法模块在业务流程图上可能不是简单的“线性插入”关系，而是“旁路”或者“交叉依赖”关系。整体业务模型有可能会很复杂。

3、数据处理量大，性能要求高

相比传统场景来讲，智能安防+ai涉及到对视频/图像的算法处理过程，需要接入处理大量视频帧/图像数据。在实际应用中会有“多路并行处理”和“实时响应”等业务需求。一方面，传递和处理图像数据带来极大的内存开销，对性能造成很大考验；另一方面，ai算法一般时间复杂度较高，处理时间较长，再加上“多路”“实时”等用户需求，如何实现高效数据交互凸显为严重问题。

对于“跨进程数据交互”这一简单议题来说，从操作系统到上层应用，从具体到抽象，有诸多手段方法可以选择。一般来说，基础一点的方案是使用操作系统一些底层api/技术实现相关功能封装。典型可以使用的手段有：管道类(包含匿名/命名pipe，socket等)，消息类(如windowsmessage，posixmessagequeue等)，共享内存(mmap)。

1)管道类(pipe，socket等)

几乎在所有的操作系统里，管道类是进程间通信最常用，最典型的方法之一。管道类消息通信组件的特点是：系统一般会以句柄/文件描述符的方式，给用户提供一个可实现一对一的通信id。两端进程可以使用这个唯一id实现一对一的数据发送和接收操作。数据通信采用标准的fifo(先进先出)模式，即先发送的数据会先到达对端，保证有序。

管道类通信的优势在于：

a.方便实用的“发送”“接收”原语

操作系统提供现成的read/write或者send/recv方法，几乎可以用在任何场合

b.灵活的数据交互

发送端可一次发出1个或者n个字节的数据，接收端可一次接收1个或者n个字节数据。用户可以自定义数据交互协议内容。

c.一对一与双工通信模型

pipe/socket在通信过程中提供了一对一的业务模型，不同的交互对之间在数据上是隔离的，这样的设计有助于开发者实现更清晰的数据交互逻辑。另外，一个交互对之间都可以“既发又收”。

2)消息类

消息类也是一种常见的数据交互手段。相比起管道类来说，消息类只能基于“消息”的方式进行数据收发，而且使用的也不全是“一对一”的通信手段(如windows一般需要使用“消息循环”来实现消息的接收)。与管道类似，消息也是使用fifo通信模型，使用场景与管道类各有侧重。

与管道类似，消息通信一般也有“发送”和“接收”原语，不同的是数据交互是以“消息”为基本单位，而不是字节。另外，很多消息组件未支持全双工通信。

3)共享内存类

共享内存是操作系统提供的一种可以在多个进程之间直接映射内存地址的一种技术。通过这种技术，可以将一块物理内存映射到多个进程的地址空间里，实现通过不同虚地址对同一个物理地址的统一访问。一般的，这种方式因为传递消息时不需要进行内存拷贝，是最高效的跨进程数据传递手段。但是内存共享技术并没有配套的消息通知实现机制，因此在业务中一般难以单独使用，需要配合其他逻辑。

对于业务场景下有上下游关系的消息传递，为了实现“逻辑解耦+物理解耦”，目前通用的技术手段是使用“消息总线”(messagequeue)。这里的“消息总线”是一个泛指概念，不是单纯局限于xxmq，其他类似kafka，zmq等在功能上提供总线机制的组件都算。

简单来讲，消息总线提供了以下几点核心功能：

a.消息队列

提供一个可靠/非可靠的进程间消息传递的队列。根据实际设计，可能是一对一，也可能是m：n等等。队列是进程间高效数据通信的保证。

b.消息收发装置

不同组件实现机制不同。一般的，相比传统点对点的数据收发模式，消息总线组件提供了“发布——订阅”模式，支持消息发送者和消息接收者通过“话题”(topic)进行业务关联。发送者向指定“话题”注册，然后接受者‘订阅’“话题”，这样可以很方便的实现m:n的消息传递。

常用的消息总线组件有：

1)mq类(如activemq，rabbitmq等)

提供重量级的消息队列实现，很多历史较为悠久(如activemq)，在很多产品中使用，支持多种协议与数据对接模式(如向数据库的持久化等)，支持事务，系统代码量较大，支持主备安全性。因业务复杂性系统吞吐量相对较低。

2)kafka

相比起传统mq实现有更高的性能，数据存取有o(1)的时间复杂度，消息吞吐量高，支持批量操作，支持消息持久化。

3)zero-mq

严格意义上不是传统mq，而是一个通信协议级的实现，有类似常见mq组件的功能(如一对多通信)。一般场景下通信效率比kafka还高，但是不支持消息持久化。

上面所列举的传统技术方案，在目前“智能安防+ai”场景下均有明显缺点。

“智能安防+ai”场景下的跨进程数据通信，一般而言与业务逻辑紧密相关，其中一个最大的需求是跟随视频图像帧的处理流程，对图像像素数据和业务数据进行流转传递。目前主流的监控视频分辨率为1080p(1920*1080)。以常用的rgb24像素格式为例，单张图像像素数据的字节数为：1920*1080*3≈6mb。一般的，一个摄像头每秒25帧，在一个物理主机上一般需要进行几十路视频的算法处理，按照40路计算，相当于单机每秒需要处理1000帧。帧数乘以单帧字节数，相当于每秒钟需要传递大约6gb的图像数据！而且这还未考虑具体算法的处理对系统资源的消耗。

底层的操作系统数据交互手段，无论是管道(pipe)类还是消息类，跨进程传递的消息在实现层面都是采用了内存拷贝。面对如此大规模的数据量，内存拷贝技术无法实现很好的传输性能。实测仅拷贝内存就会占用大量的cpu资源，造成系统整体可用资源降低，更不用说后续还有对资源需求更重的算法处理过程了。

共享内存技术因为采用直接内存映射，面对大内存块的跨进程传输有天然优势，因为不需要进行实际的内存拷贝。但是共享内存技术本身只提供了进程间访问同一块内存的数据的方法，并不能提供消息通信的相关机制。因此为了真正实现进程间数据“交互通信”的需求，还必须配上相关的数据通信方案。

“消息总线”组件都属于较为重量级的实现。在当前的需求场景里，因数据量太大，不考虑跨主机之间的数据传递。而且数据全部实时处理，如果服务断掉，因为算法处理业务链不完整，中间数据保存的意义有限，所以对相关数据的消息持久化也没有要求。这样的话使用xxmq，kafka的意义就比较弱了，无法发挥其功能优势。zero-mq相比之下，在消息功能设计上是更加适合需求的。但是遇到与底层数据交互手段一样的“内存拷贝”性能瓶颈。

综合来讲，目前常用的方法均有其不足的一面，难以完美解决当前需求。

技术实现要素：

本发明的目的是要解决现有技术中存在的不足，提供一种算法集成服务框架系统。

为达到上述目的，本发明是按照以下技术方案实施的：

一种算法集成服务框架系统，包括算法集成框架底层基础服务rmmt_daemon和上层应用sdk；

所述底层基础服务rmmt_daemon包括命令解析器、内存分配器、全局共享内存块、全局内存分配器，所述命令解析器通过服务端/算法集成服务框架rmmt_sdk接入上位应用程序用于对上位应用程序的请求命令进行解析处理，内存分配器与命令解析器连接，全局内存分配器与内存分配器连接，全局共享内存块与全局内存分配器连接，全局共享内存块用于初始化时指定全局内存池大小，使用过程中给上位应用程序做内存分配/释放/传递共享内存；全局共享内存块连接有上位应用程序的操作系统共享内存资源接口；

所述上层应用sdk包括daemon命令交互模块、共享内存访问模块、网络协议交互模块，daemon命令交互模块、共享内存访问模块、网络协议交互模块通过api接口连接上位应用程序，daemon命令交互模块通过服务端/算法集成服务框架rmmt_sdk连接命令解析器，网络协议交互模块用于与算法集成框架底层基础服务rmmt_daemon通信，共享内存访问模块连接上位应用程序的操作系统共享内存资源接口。

与现有技术相比，本发明基于管道(pipe)技术和共享内存技术相结合的，支持以消息方式实现跨进程消息传递与大内存块高效传输的一整套业务组件，能够实现大块数据在ai后端服务(主要是算法服务)间的高效传输，但是在功能上弱于一般意义上“消息总线”；在形态上，整个组件更像一套框架，基于整个框架来搭建高性能松耦合的算法业务应用。将本发明的算法集成服务框架系统运用于智能安防+ai的图像算法处理时，rmmt框架在单机4核心处理器(主频3.2ghz)上的tps可达到10000左右(一个rmmt_daemon，挂2个上位进程)，在多线程场景下性能没有明显减少；在应用环境下(单机40路视频算法处理)，rmmt产生的额外cpu占用率在单核心的10％左右，大概比使用传统pipe/zmq减少了80％-90％，并且内存占用也少了很多。

附图说明

图1为本发明的底层基础服务rmmt_daemon的内部架构图。

图2为本发明的上层应用sdk的内部架构。

图3为将本发明的算法集成服务框架系统运用于智能安防+ai的图像算法处理的整体架构图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步的详细说明。此处所描述的具体实施例仅用于解释本发明，并不用于限定发明。

本实施例的提供一种算法集成服务框架系统，包括算法集成框架底层基础服务rmmt_daemon和上层应用sdk；

如图1所示，所述底层基础服务rmmt_daemon包括命令解析器、内存分配器、全局共享内存块、全局内存分配器，所述命令解析器通过服务端/算法集成服务框架rmmt_sdk接入上位应用程序用于对上位应用程序的请求命令进行解析处理，内存分配器与命令解析器连接，全局内存分配器与内存分配器连接，全局共享内存块与全局内存分配器连接，全局共享内存块用于初始化时指定全局内存池大小，使用过程中给上位应用程序做内存分配/释放/传递共享内存；全局共享内存块连接有上位应用程序的操作系统共享内存资源接口；

rmmt_daemon(算法集成框架底层基础服务)所提供的功能有：

框架上位进程的接入、退出和状态监控；

框架上位进程的请求命令解析处理(如：请求分配、释放、传递共享内存等)；

全局共享内存分配管理。包括初始化时指定全局内存池大小，使用过程中给上位进程做内存分配/释放等；

此服务程序被上位程序强依赖。因为涉及到跨进程内存管理问题，使用librmmt_sdk2.so的上位程序从启动到关闭的完整生存期内，基础服务程序必须全程在线。如果基础服务程序退出，则依赖它的所有上位程序将无法正常工作。在librmmt_sdk2.so中有默认开关，在运行时检测到与基础服务连接断开之后，将会退出(abort())。

如图2所示，所述上层应用sdk包括daemon命令交互模块、共享内存访问模块、网络协议交互模块，daemon命令交互模块、共享内存访问模块、网络协议交互模块通过api接口连接上位应用程序，daemon命令交互模块通过服务端/算法集成服务框架rmmt_sdk连接命令解析器，网络协议交互模块用于与算法集成框架底层基础服务rmmt_daemon通信，共享内存访问模块连接上位应用程序的操作系统共享内存资源接口；

应用sdk是为上位程序所调用的动态库组件(关系形态可见上方架构图)，它所提供的功能和特性有：

基于server-client模型的message-channel通信。c-s模型类似于tcp-socket(server方监听地址，然后accept等待client接入；client端使用connect连接server)；

通信模型为双端全双工；交互方式是message-oriented；

每个message(消息)支持传递一个<2gb的消息体(可以为文本或者二进制)，以及0～n个共享内存块；

共享内存块的分配采用类似malloc方式(指定分配大小，对齐字节默认16)。c++接口共享内存块采用shared_ptr智能指针管理生存期；

共享内存块能够支持内存数据跨进程的直接内存映射访问(零拷贝)。共享内存节点元数据结构跨进程传输极其高效(message-channel传输十几字节，c端/s端都向基础服务通信一次)；

共享内存块的生存期管理为智能傻瓜式管理。高效、精确、合理的共享内存管理与回收策略。共享内存在其生存期明确的前提下，采用即时回收策略，引用计数为0时立即回收(适用于绝大多数使用场景)。当且仅当因上位程序异常退出时候造成的“野指针”内存块会被超时计时器标记，采用gc策略回收。

在最开始的时候，没有算法集成服务框架，为了保证服务的工作性能，所有图像算法相关组件都只能以sdk的形式集成在一个进程里，导致整个进程臃肿且难于维护和调试，给开发工作带来很大不便。引入了算法集成服务框架以后，就可以将系统中原先的算法模块独立出来，做成一个个可重用的算法服务组件，既解决了重度耦合问题，方便开发和调试，也给业务提供了更高的可重用性，如图3所示，其中，“消息总线/数据交互抽象层”即为本发明的算法集成服务框架系统所实现的功能。上下方的各个服务组件即为基于算法集成框架应用sdk的“上位程序”。这些程序之间的数据交互都依赖于rmmt。上方部分在功能定位上属于业务程序部分，提供具体业务逻辑实现与对外通信。下方部分为底层功能/算法微服务。这些服务都是可重用的，能够很方便的被其他的业务进程模块所调用。

经过实测，rmmt框架在单机4核心处理器(主频3.2ghz)上的tps可达到10000左右(一个rmmt_daemon，挂2个上位进程)。在多线程场景下性能没有明显减少。在应用环境下(单机40路视频算法处理)，rmmt产生的额外cpu占用率在单核心的10％左右，大概比使用传统pipe/zmq减少了80％-90％，并且内存占用也少了很多。

本发明的技术方案不限于上述具体实施例的限制，凡是根据本发明的技术方案做出的技术变形，均落入本发明的保护范围之内。