一种运行在App和服务器软件之间的中间代理程序的制作方法

本发明涉及一种中间代理程序，具体是一种运行在App和服务器软件之间的中间代理程序。

背景技术：

目前互联网App几乎都需要与服务器软件进行实时信息交互，如果服务器软件发生故障App也会面临无法运行的窘境；另外，服务器软件升级时，由于上线前无法做大量公测，很可能造成使用体验变差从而丢失用户，一些游戏商会做限号公测，但如果公测期间体验不好或体验周期过长其口碑依然会受到负面影响。因此我们需要各种方案来一方面保障在线业务的稳定持续运行，另一方面要最大减少因程序更新带来不稳定性风险。

现有技术中通过软件狗进行系统监控，该方案主要通过监控的系统资源使用情况、以及发送健康探测包判断受监控的服务软件是否处于异常状态，如果发现异常，则自动重新启动该服务，使其能够正常运行，并将服务器软件发生问题的时间写入日志文件，以供运维人员进行分析；软件狗的缺点是：检测手段过于简陋：目前方案的监控只能监控服务软件的工作端口，例如新浪服务器的端口是80，而不能对业务内容实时监控；处理结果过于简单：监控程序发现服务软件异常时，会强制重启服务，而实际运行环境下有时候业务压力大可能会导致工作端口繁忙而没有响应监控程序的检测包，这样会导致服务软件反复重启；监控日志缺少实质内容：监控产生的日志仅仅能记录服务软件的系统资源使用、重启情况，而不能提供服务软件业务相关的监控信息；运维成本高：监控程序需要在每台物理机或虚拟机上单独配置，如果主机数量过多无法远程统一管理。

现有技术中采用负载均衡分流设备进行业务分流，该方案目前采用专用的7层负载均衡产品，主要通过对Cookie、URL等信息组合对业务均衡；负载均衡分流设备的缺点是：产品软件固化不能满足不同的业务模型：负载均衡产品设计过于封闭，业务使用者只能根据均衡产品已有的方式来控制业务流而不能根据使用者的需求来定义业务流逻辑；均衡局限性：目前该类产品均通过策略规则下发实现负载或均衡控制，而实际中越来越多的业务的URL和Cookie信息都采取了加密处理，这些固定的规则无法处理加密的信息，也无法满足均衡的业务要求； 缺少对业务流量的实时回放：不能对指定业务流做实时的回放，例如使用者希望业务A能够复制一份到一台测试机器上，同时测试机器返回的请求均衡设备能够丢弃或触发指定事件。

技术实现要素：

本发明的目的在于提供一种监控粒度精准，运维成本低的运行在App和服务器软件之间的中间代理程序，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：

一种运行在App和服务器软件之间的中间代理程序，包括控制中心和可编程的工作节点，工作节点作为软件与业务系统同时运行在一台机器上且对业务系统透明，工作节点从控制中心接收规则并根据规则将业务数据分流到多个业务系统上或回放业务流到测试或模拟业务系统中，控制中心负责集中管控所有工作节点，并采用ESTFUL-API协议与工作节点通信。

作为本发明进一步的方案：所述节点由控制层、数据层、转发层和网络IO层四部分组成，其中控制层用于与中心端通信，负责接收业务逻辑并注册到数据层中；数据层处理经过的数据流，如果有业务逻辑，所有的数据流会经过数据层处理；转发层用来维护一张转发表，将业务流发送到指定的主机；网络IO层用于数据的实际发送，同时对标记的业务流进行流控。

作为本发明再进一步的方案：所述中心端由WEB管理、编译引擎、节点通信组件组成，其中通过编译引擎将使用者编写的业务逻辑编译成节点支持的库文件。

与现有技术相比，本发明的有益效果是：

本发明可以注入使用者自定义的业务处理逻辑，并加载到HTTP-hooker中，进而做到更精准的监控粒度，例如统计业务类型的每秒处理业务数TPS，并根据设置的阀值触发不同的业务事件，比如：分流、告警等；能够回放App访问服务器的真实流量到测试环境中，让新业务上线前能够在真实网络环境中得到检验；提供开放的编程接口，让使用者自定义业务模型用于测试或优化，较传统的规定策略方式更加灵活机动，对于业务流加密的信息也可以通过编程实时解密分析；集中方式的管理减少了运维成本。

附图说明

图1为本发明中的软件部署示意图。

图2为本发明中的软件系统结构示意图。

图3为本发明中节点收到请求数据时的处理流程示意图。

图4为本发明中节点收到应答数据时的处理流程示意图。

图5为本发明通过真实环境业务流模拟的示意图。

具体实施方式

下面结合具体实施方式对本专利的技术方案作进一步详细地说明。

请参阅图1-2，一种运行在App和服务器软件之间的中间代理程序，包括控制中心和可编程的工作节点，工作节点作为软件与业务系统同时运行在一台机器上且对业务系统透明，工作节点从控制中心接收规则并根据规则将业务数据分流到多个业务系统上或回放业务流到测试或模拟业务系统中，控制中心负责集中管控所有工作节点，并采用ESTFUL-API协议与工作节点通信。

所述节点由控制层、数据层、转发层和网络IO层四部分组成，其中控制层用于与中心端通信，负责接收业务逻辑并注册到数据层中；数据层处理经过的数据流，如果有业务逻辑，所有的数据流会经过数据层处理；转发层用来维护一张转发表，将业务流发送到指定的主机；网络IO层用于数据的实际发送，同时对标记的业务流进行流控，所述中心端由WEB管理、编译引擎、节点通信组件组成，其中通过编译引擎将使用者编写的业务逻辑编译成节点支持的库文件。

请参阅图3，当节点收到请求数据时，http_xxx_hooker是可注入的hook点，业务逻辑以链表形式可动态加载在这两个点顺序执行，Hook点的处理过程是通过控制层以注册方式增加或更新的，例如：控制层通过调用：Register_httpHook(HOOK_POINT，http_process)可增加http_process处理过程，HTTP共享缓存描述了一条HTTP流的信息，通过它可关联、保存业务的私有数据。

请参阅图4，当Hooker节点收到HTTP应答数据时，与处理HTTP请求过程相同，如果是应答请求当通过转发处理后发现是镜像服务器返回的数据，默认丢弃该应答，可通过在forward_hooker位置重新定义处理过程。

请参阅图5，图5描述了本发明在正式上线前通过真实环境业务流模拟的情况，本发明需要在cookie中增加该用户的个历史手机号信息。

首先在控制中心定义三个业务逻辑为：

(1)对原有A业务的cookie解密并提取出用户身份信息，根据用户ID查询业务数据库A，将查询的注册手机号(新业务需要cookie携带手机号)的附加到Cookie信息中并加密，最后将修改后的HTTP请求回放到新业务A服务器上；

(2)对用户X的业务请求标记做HTTP回放。

(3)对用户Y的业务请求标记做业务分流

定义的业务逻辑通过RESTFUL通信接口下发到节点上，节点的控制层将下发的so文件动态加载，并将其中的函数(业务逻辑)动态注册到http_request_hooker和http_forward_hooker中。当有真实的用户X请求来时，在request_request_hooker中解密判断X用户身份，并会对请求加标记表明需要回放转发；在request_forward_hooker会对回放的业务流根据新定义的业务逻辑查询数据库增加手机号信息最后加密转发到新业务A上(测试环境)；当有真实的用户Y请求来时，在request_request_hooker中解密判断Y身份，并取得会对请求加标记表明需要分流转发；在request_forward_hooker会对分流标记的业务流转发到另一台业务A服务器上。

本发明可以注入使用者自定义的业务处理逻辑，并加载到HTTP-hooker中，进而做到更精准的监控粒度，例如统计业务类型的每秒处理业务数TPS，并根据设置的阀值触发不同的业务事件，比如：分流、告警等；能够回放App访问服务器的真实流量到测试环境中，让新业务上线前能够在真实网络环境中得到检验；提供开放的编程接口，让使用者自定义业务模型用于测试或优化，较传统的规定策略方式更加灵活机动，对于业务流加密的信息也可以通过编程实时解密分析；集中方式的管理减少了运维成本。

上面对本专利的较佳实施方式作了详细说明，但是本专利并不限于上述实施方式，在本领域的普通技术人员所具备的知识范围内，还可以在不脱离本专利宗旨的前提下作出各种变化。