本发明涉及计算机技术领域，特别是一种微服务架构下将无状态服务接收到的消息通过长连接透传的方法和装置。
背景技术：
微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。微服务应用的一个最大的优点是，它们往往比传统的应用程序更有效地利用计算资源。这是因为它们通过扩展组件来处理功能瓶颈问题。这样一来，开发人员只需要为额外的组件部署计算资源，而不需要部署一个完整的应用程序的全新迭代。最终的结果是有更多的资源可以提供给其它任务。
作为IOT平台，大多数客户都希望通过平台能实现终端发送的数据能透传到自有的业务系统中进行数据处理，来实现业务系统与终端进行通信的需求。而IOT平台由于数据量大，对平台的性能和稳定性又有较高要求，当前主流的微服务架构可以很好的实现系统对这方面的要求。
微服务架构下，存在多个无状态服务用于接收终端发来的消息，这些消息需要通过同一个长连接发送到目标服务器，那么当一个消息在A服务上接收并与目标服务器建立长连接C进行数据透传后，当B服务再次接收到消息并希望通过使用长连接C进行透传，则无法在B服务中获取长连接C的句柄，无法实现数据透传。
技术实现要素：
本发明的目的是提供一种微服务架构下将无状态服务接收到的消息通过长连接透传的方法和装置，解决多个无状态服务消息无法通过同一个长连接实现透传到目标服务器的问题。
为了实现上述目的，第一方面，本发明提供的一种微服务架构下将无状态服务接收到的消息通过长连接透传的方法，包括：
透传服务器收到消息后根据协议内容判断本条消息是否是本次通信的第一条消息；
如果是第一条消息，透传服务器与目标服务器建立长连接并将连接句柄缓存至当前透传服务器内存中；将当前透传服务器的地址信息缓存至缓存服务器；
透传服务器通过长连接向目标服务器发送消息数据，以便目标服务器向终端回复消息。
可选地，在透传服务器收到消息后根据协议内容判断本条消息是否是本次通信的第一条消息之前，所述方法还包括：
终端向应用服务器发送消息；
应用服务器解析消息并根据协议内容判断本条消息是否是本次通信的第一条消息；
如果是第一条消息，先清理缓存服务器中当前终端对应的历史缓存，再选择一台透传服务器进行消息发送；
如果不是第一条消息，先从缓存服务器获取本次通信过程中缓存的透传服务器地址信息，再向该地址信息对应的透传服务器地址发送消息进行通信。
可选地，所述选择一台透传服务器为通过负载均衡进行选择。
可选地，所述地址信息包括透传服务器的IP和端口信息。
第二方面，本发明实施例提供了一种用于实现第一方面中方法的微服务架构下将无状态服务接收到的消息通过长连接透传装置，包括：
第一判断单元，用于透传服务器收到消息后根据协议内容判断本条消息是否是本次通信的第一条消息；
缓存单元，用于如果是第一条消息，透传服务器与目标服务器建立长连接并将连接句柄缓存至当前透传服务器内存中；将当前透传服务器的地址信息缓存至缓存服务器；
长连接发送单元，用于透传服务器通过长连接向目标服务器发送消息数据，以便目标服务器向终端回复消息。
可选地，在透传服务器收到消息后根据协议内容判断本条消息是否是本次通信的第一条消息之前，所述装置还包括：
终端发送单元，用于终端向应用服务器发送消息；
第二判断单元，用于应用服务器解析消息并根据协议内容判断本条消息是否是本次通信的第一条消息；
选择单元，用于如果是第一条消息，先清理缓存服务器中当前终端对应的历史缓存，再选择一台透传服务器进行消息发送；
应用服务器发送单元，用于如果不是第一条消息，先从缓存服务器获取本次通信过程中缓存的透传服务器地址信息，再向该地址信息对应的透传服务器地址发送消息进行通信。
可选地，所述选择一台透传服务器为通过负载均衡进行选择。
可选地，所述地址信息包括透传服务器的IP和端口信息。
本发明提供的微服务架构下将无状态服务接收到的消息通过长连接透传方法和装置，将透传服务独立出来，在首次建立长连接时将当前透传服务地址信息缓存至外部服务器，当应用服务器准备透传时，可以根据缓存服务器找到对应的透传服务器地址，并在该透传服务器内找到句柄，从而实现消息的透传。
附图说明
图1为本发明实施例提供的微服务架构下将无状态服务接收到的消息通过长连接透传方法的交互流程图；
图2为本发明实施例提供的微服务架构下将无状态服务接收到的消息通过长连接透传装置的结构图。
具体实施方式
下面将参考附图中示出的若干示例性实施方式来描述本发明的原理和精神。应当理解，描述这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。
虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者部分合并后更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置、服务器或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境、甚至包括分布式处理、服务器集群的实施环境)。
术语解释：
微服务：一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。微服务应用的一个最大的优点是，它们往往比传统的应用程序更有效地利用计算资源。这是因为它们通过扩展组件来处理功能瓶颈问题。这样一来，开发人员只需要为额外的组件部署计算资源，而不需要部署一个完整的应用程序的全新迭代。最终的结果是有更多的资源可以提供给其它任务。因此，本发明实施例中所述的服务对应的应用程序指的是微服务应用。
无状态服务：对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到(比如说数据库)，服务器本身不存储任何信息。在本实施例下文的叙述中，应用服务器接收到的消息(请求)即为无状态服务下请求消息。
长连接：指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。
如图1所示，本发明实施例提供的一种微服务架构下将无状态服务接收到的消息通过长连接透传方法，包括如下步骤：
S1：终端向应用服务器发送消息。
其中，终端可以是任意一种用户终端，包括但不限于手机、平板电脑、个人电脑、可穿戴设备等。
S2：应用服务器解析消息并根据协议内容判断本条消息是否是本次通信的第一条消息。
S3：如果是第一条消息，先清理缓存服务器中当前终端对应的历史缓存，再选择一台透传服务器进行消息发送。
清楚历史缓存一方面为该透传服务器接下来存储的地址信息(见下文步骤S6)留出存储空间，还可以避免再次发送消息(如步骤S4)时，应用服务器受到缓存信息的干扰，导致透传服务器地址查找错误或查找效率降低。
在步骤S3中，可以采用负载均衡规则选择透传服务器，具体可以选择计算资源剩余较多，即负载压力较小的透传服务器，以到达平衡消息传递计算资源的作用。
S4：如果不是第一条消息，先从缓存服务器获取本次通信过程中缓存的透传服务器IP和端口信息，再向该IP和端口对应的透传服务器地址发送消息进行通信。需要说明的是，步骤S4是在步骤S6中，在透传服务器已经将地址信息保存到缓存服务器时执行的。即下文叙述的步骤S6，承接步骤S3，在存在第一条消息的情况下，将地址信息保存到缓存服务器中，以便再次发送消息时，执行步骤S4。
S5：透传服务器收到消息后根据协议内容判断本条消息是否是本次通信的第一条消息。在本实施例中，如果步骤S3中判断为本次通信的第一条消息，则在步骤S5中，判断结果对应的也为本次通信的第一条消息。
S6：如果是第一条消息：透传服务器与目标服务器建立长连接并将连接句柄缓存至当前透传服务器内存中；将当前透传服务器的IP及端口缓存至缓存服务器。
步骤S6中，将建立长连接的句柄缓存到当前的透传服务器中，当该透传服务器再次接收到需要透传的消息时，就可以从本地直接获取到句柄，解决了再次透传时无法找到句柄的问题。将当前透传服务器的IP及端口缓存至缓存服务器，以便下次透传时应用服务器可以从外部的缓存服务器快速找到透传服务器的地址。
S7：透传服务器通过长连接向目标服务器发送消息数据。
获得了句柄后，透传服务器将接收到的消息直接发送给目标服务器，有目标服务器做出响应。
S8：目标服务器向终端回复消息。
目标服务器做出响应后，将回复消息依次通过透传服务器、应用服务器最终返回给终端。
本发明实施例还提供了实现上述方法的微服务架构下将无状态服务接收到的消息通过长连接透传装置，如图2所示，该装置包括：
第一判断单元，用于透传服务器收到消息后根据协议内容判断本条消息是否是本次通信的第一条消息；
缓存单元，用于如果是第一条消息，透传服务器与目标服务器建立长连接并将连接句柄缓存至当前透传服务器内存中；将当前透传服务器的地址信息缓存至缓存服务器；
长连接发送单元，用于透传服务器通过长连接向目标服务器发送消息数据，以便目标服务器向终端回复消息。
可选地，在透传服务器收到消息后根据协议内容判断本条消息是否是本次通信的第一条消息之前，所述装置还包括：
终端发送单元，用于终端向应用服务器发送消息；
第二判断单元，用于应用服务器解析消息并根据协议内容判断本条消息是否是本次通信的第一条消息；
选择单元，用于如果是第一条消息，先清理缓存服务器中当前终端对应的历史缓存，再选择一台透传服务器进行消息发送；
应用服务器发送单元，用于如果不是第一条消息，先从缓存服务器获取本次通信过程中缓存的透传服务器地址信息，再向该地址信息对应的透传服务器地址发送消息进行通信。
可选地，所述选择一台透传服务器为通过负载均衡进行选择。
可选地，所述地址信息包括透传服务器的IP和端口信息。
上述各单元所执行的流程与方法实施例中的步骤S1-S8相对应，更为具体的实施方式可参考方法中各步骤相应的描述，在此不再赘述。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。