本公开涉及通信
技术领域：
：，具体而言，涉及一种应用间的通信方法、应用间的通信装置、电子设备及计算机可读介质。
背景技术：
：微服务架构是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。目前，微服务架构已经成为业界的主流架构模式。但是，微服务的盛行也带来了不少的挑战，比如应用的拓扑结构更复杂、服务之间的交互稳定性降低、一个业务逻辑需要一条调用链上的多个微服务统一协调等等。鉴于此，本领域亟需一种应用间的通信方法，能够提升通信的效率和稳定性。需要说明的是，在上述
背景技术：
：部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。技术实现要素：本公开的目的在于提供一种应用间的通信方法、应用间的通信装置、电子设备及计算机可读介质，进而至少在一定程度上能够提升通信的效率和稳定性。根据本公开的第一个方面，提供一种应用间的通信方法，包括：响应于第一应用向第二应用发起的连接请求，通过所述第一应用对应的第一边车组件获取所述第一应用发送的第一流量数据；通过所述第一边车组件将所述第一流量数据转发至与所述第一边车组件相关联的桥接组件上；通过所述桥接组件对所述第一流量数据进行处理，并将所述第一流量数据转换为与所述第二应用相匹配的第二流量数据；将所述第二流量数据发送至所述第二应用对应的第二边车组件上，并通过所述第二边车组件转发至所述第二应用。在本公开的一种示例性实施例中，所述第一边车组件与所述第一应用部署在同一宿主机上，所述第二边车组件与所述第二应用部署在同一宿主机上。在本公开的一种示例性实施例中，所述桥接组件在容器平台或者虚拟主机上部署运行。在本公开的一种示例性实施例中，所述通过所述桥接组件对所述第一流量数据进行处理，包括：从控制面板获取所述桥接组件的服务治理规则，并根据所述服务治理规则对所述第一流量数据进行处理。在本公开的一种示例性实施例中，所述将所述第一流量数据转换为与所述第二应用相匹配的第二流量数据，包括：通过所述桥接组件将所述第一流量数据中的通信协议转换为与所述第二应用相匹配的通信协议；通过所述桥接组件将所述第一流量数据中的通信报文转换为与所述第二应用相匹配的通信报文；根据转换后的所述通信协议和所述通信报文得到所述第二流量数据。在本公开的一种示例性实施例中，所述通过所述桥接组件将所述第一流量数据中的通信协议转换为与所述第二应用相匹配的通信协议，包括：获取所述第一应用所使用的通信协议类型，以及所述第二应用所使用的通信协议类型；若所述第一应用所使用的通信协议类型与所述第二应用所使用的通信协议类型不同，则通过所述桥接组件将所述第一流量数据中的通信协议转换为所述第二应用所使用的通信协议类型。在本公开的一种示例性实施例中，所述通过所述桥接组件将所述第一流量数据中的通信报文转换为与所述第二应用相匹配的通信报文，包括：获取所述第一应用中的通信报文格式，以及所述第二应用中的通信报文格式；若所述第一应用中的通信报文格式与所述第二应用中的通信报文格式不同，则通过所述桥接组件将所述第一流量数据中的通信报文转换为所述第二应用中的通信报文格式。根据本公开的第二方面，提供一种应用间的通信装置，包括：流量数据获取模块，用于响应于第一应用向第二应用发起的连接请求，通过所述第一应用对应的第一边车组件获取所述第一应用发送的第一流量数据；边车组件转发模块，用于通过所述第一边车组件将所述第一流量数据转发至与所述第一边车组件相关联的桥接组件上；流量数据处理模块，用于通过所述桥接组件对所述第一流量数据进行处理，并将所述第一流量数据转换为与所述第二应用相匹配的第二流量数据；桥接组件转发模块，用于将所述第二流量数据发送至所述第二应用对应的第二边车组件上，并通过所述第二边车组件转发至所述第二应用。根据本公开的第三方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的应用间的通信方法。根据本公开的第四方面，提供一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的应用间的通信方法。本公开示例性实施例可以具有以下有益效果：本公开示例实施方式的应用间的通信方法中，通过在两个应用之间增加一个桥接组件，在实现应用间的通信时，仅通过边车组件完成流量的拦截和转发，对于通信时的复杂规则控制则通过桥接组件来完成。本公开示例实施方式中的应用间的通信方法，通过增加桥接组件，一方面，能够降低边车组件对宿主机资源的依赖和占用，减少边车组件对应用进程的影响，提高通信过程的稳定性；另一方面，通过减少通信过程中的链路长度，减少应用间流量通信的跳转次数，从而提升通信的效率；再一方面，由于桥接组件具有自动化调度、自动扩缩容以及高可扩展性的特点，并且在桥接组件上可以快速进行定制化需求开发，因此能够在降低二次开发成本的同时，提升服务网格数据面的可扩展性以及整个服务治理的效率，并进一步提升通信的效率。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。附图说明此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1示意性示出了基于远程过程调用框架的微服务实现的流程框图；图2示意性示出了根据本公开的一个相关实施例中的基于服务网格的微服务实现的流程框图；图3示意性示出了根据本公开的一个相关实施例中的通过企业服务总线进行通信的流程框图；图4示出了本公开示例实施方式的应用间的通信方法的流程示意图；图5示出了本公开示例实施方式的将第一流量数据转换为第二流量数据的流程示意图；图6示意性示出了根据本公开的一个具体实施方式中的基于服务网格的微服务实现的流程框图；图7示意性示出了根据本公开的一个具体实施方式中的边车组件与桥接组件集群管理的示意图；图8示出了本公开示例实施方式的应用间的通信装置的框图；图9示出了适于用来实现本公开实施方式的电子设备的计算机系统的结构示意图。具体实施方式现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。微服务架构已经成为目前业界的主流架构模式，它使得企业服务中的各个组件可以独立地开发、测试、部署、升级以及扩缩容，使应用的迭代升级更敏捷。但是微服务的盛行也带来了不少的挑战，比如应用的拓扑结构更复杂、服务之间的交互稳定性降低、一个业务逻辑需要一条调用链上的多个微服务统一协调，更容易引起雪崩问题等等；另外，微服务之间的安全问题也暴露了出来，比如权限控制、通信安全等。图1示意性示出了基于远程过程调用框架的微服务实现的流程框图，上述如图1所示的基于RPC(RemoteProcedureCall，远程过程调用)框架的微服务实现，存在代码侵入、SDK(SoftwareDevelopmentKit，软件开发工具包)升级困难等问题。在此基础上，一些相关实施例中，可以将服务网格ServiceMesh应用在微服务中以解决上述问题。例如，Istio是一个开源的服务网格产品，以透明层的方式构建在现有分布式应用中，可以以统一的方式去检测和管理微服务。目前Istio默认的数据面实现是Envoy，Envoy是专为大型现代SOA(Service-OrientedArchitecture，面向服务架构)设计的L7代理和通信总线。该项目源于以下理念：网络对应用程序来说应该是透明的。当网络和应用程序出现问题时，应该很容易确定问题的根源。图2示意性示出了根据本公开的一个相关实施例中的基于服务网格的微服务实现的流程框图，通过管控面API(ApplicationProgrammingInterface，应用程序接口)201可以控制应用APP之间的通信，其中，Pilot是Istio流量管理的核心组件，用户通过Pilot的API管理网络相关的资源对象，Pilot会根据用户的配置和服务的信息把网络流量管理变成Envoy能识别的格式并分发至各个Sidecar(边车)代理中。在Istio架构中，Mixer充当应用代码和后端基础设施的中间层，为整个集群执行访问控制和管理，并且收集代理观察到的服务之间的流量统计数据。Istio-Auth(Authentication)为身份认证组件。应用1与应用2之间进行通信时，如果两个应用所使用的协议不同或者报文不同，可以分别通过两个应用对应的边车组件进行转换使两边适配。然而，目前的服务网格数据面产品，如Envoy等，在实际应用中仍然存在以下几点问题：1、对应用进程的影响。在服务网格落地时，避免不了需要面对企业现有的部署环境、服务开发框架和通信协议，并且有一部分的企业服务(特别是金融行业的部分老旧系统)会使用如图3所示的方法，通过企业服务总线的方式进行应用间的通信。这些系统无法进行系统改造，甚至是重新编译部署，但是，这些系统往往承担了比较重要的职责(如银行核心系统)。在这个背景下对服务网格的数据面产品就有了非常高的要求，即适配各种部署环境(虚机、物理机、容器、私有云、公有云；服务开发框架：多版本并行的dubbo(开源分布式服务框架)、springcloud(一种云应用开发工具)、自研框架)以及各种通信协议和报文规范(tcp、http、dubbo、webservice、8583、定长等)，当边车组件Sidecar在执行复杂处理逻辑时，对宿主机的cpu(centralprocessingunit，中央处理器)、内存、网络、io(Input/Output，输入/输出)等资源会有一定要求，进而对应用服务有一定的影响。2、对请求时长的影响。当需要进行协议转换时，现有服务网格数据面的产品(如Envoy)需要进行多次协议转换。如图2所示，假设应用1使用的是tcp协议，应用2使用的是webservice协议，当应用1访问应用2时，应用1发出的socket(tcp)请求被边车组件1拦截，边车组件1读取报文后，将应用1所发出的tcp请求转换成grpc(RPC框架)协议并转发至边车组件2，边车组件2进而将请求转换为webservice协议，最终转发给应用2。通过上述过程可以看出，整个流程进行了两次协议转换，应用1->边车组件1->边车组件2->应用2，且两个边车组件均进行了报文解析和协议转换，并且增加了调用链路，对总请求时长有一定的影响。3、服务网格还需要有服务治理的能力，应用1访问应用2时，当需要进行权限、安全、限流、熔断等服务治理时，需要同时将响应的规则通过某种协议，比如xDS(Envoy获取配置信息的传输协议)发给边车组件1和边车组件2，当集群中应用服务非常多的时候，边车组件的数量也非常多，这种规则下发会占用大量网络资源。基于上述问题，本示例实施方式首先提供了一种应用间的通信方法。参考图4所示，上述应用间的通信方法可以包括以下步骤：步骤S410.响应于第一应用向第二应用发起的连接请求，通过第一应用对应的第一边车组件获取第一应用发送的第一流量数据。步骤S420.通过第一边车组件将第一流量数据转发至与第一边车组件相关联的桥接组件上。步骤S430.通过桥接组件对第一流量数据进行处理，并将第一流量数据转换为与第二应用相匹配的第二流量数据。步骤S440.将第二流量数据发送至第二应用对应的第二边车组件上，并通过第二边车组件转发至第二应用。本公开示例实施方式的应用间的通信方法中，通过在两个应用之间增加一个桥接组件，在实现应用间的通信时，仅通过边车组件完成流量的拦截和转发，对于通信时的复杂规则控制则通过桥接组件来完成。本公开示例实施方式中的应用间的通信方法，通过增加桥接组件，一方面，能够降低边车组件对宿主机资源的依赖和占用，减少边车组件对应用进程的影响，提高通信过程的稳定性；另一方面，通过减少通信过程中的链路长度，减少应用间流量通信的跳转次数，从而提升通信的效率；再一方面，由于桥接组件具有自动化调度、自动扩缩容以及高可扩展性的特点，并且在桥接组件上可以快速进行定制化需求开发，因此能够在降低二次开发成本的同时，提升服务网格数据面的可扩展性以及整个服务治理的效率，并进一步提升通信的效率。下面，结合图5至图7对本示例实施方式的上述步骤进行更加详细的说明。在步骤S410中，响应于第一应用向第二应用发起的连接请求，通过第一应用对应的第一边车组件获取第一应用发送的第一流量数据。在基于服务网格的微服务实现中，边车模式是通过给应用服务加装一个边车组件，来达到控制和逻辑的分离的目的。比如日志记录、监控、流量控制、服务注册、服务发现、服务限流、服务熔断等在应用服务中不需要实现的控制面功能，可以交给边车组件进行处理，应用服务只需要专注实现业务逻辑即可。本示例实施方式中，当第一应用需要与第二应用进行通信时，由第一应用向第二应用发起连接请求。响应于第一应用向第二应用发起的连接请求，与第一应用部署在同一宿主机上的第一边车组件仅做流量劫持处理，即获取第一应用发送的第一流量数据，而不进行其他操作。由于边车组件未做复杂逻辑处理，仅做流量劫持与转发，所以对宿主机占用的cpu、io、网络、内存等资源极少，基本对业务应用无影响。由于处理逻辑简单也降低了升级的频次。边车组件的具体技术方案可以通过iptables、ipvs、cilium、ebpf等技术实现，其中，iptables是Linux防火墙工作在用户空间的管理工具，其主要功能是实现对网络数据包进出设备及转发的控制；ipvs(IPVirtualServer，IP虚拟服务器)是一种负载均衡器，能够实现传输层负载平衡；cilium是一个用于透明保护部署在Linux容器管理平台(比如Docker和Kubernetes)上的应用服务之间网络连接的开源软件；ebpf(extendedBerkeleyPacketFilter，扩展伯克利包过滤器)是一个通用执行引擎，可基于此开发性能分析工具、软件定义网络等诸多场景。在步骤S420中，通过第一边车组件将第一流量数据转发至与第一边车组件相关联的桥接组件上。本示例实施方式中，在整个数据面方案中增加了桥接组件(Bridge)。第一边车组件获取到第一应用发送的第一流量数据之后，将其转发至与第一边车组件相关联的桥接组件上，并通过桥接组件来进行通信过程中的复杂规则控制。桥接组件为轻量级高性能高可扩展性网络代理产品，可实现服务治理、限流、权限、路由、转发、熔断、多协议适配等功能，可以由Nginx、Openresty、Netty、Go等技术实现，其中，Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件代理服务器；Openresty是一个全功能的Web应用服务器；Netty是一个利用Java的高级网络的能力，隐藏其背后的复杂性而提供一个易于使用的API的客户端/服务器框架；Go提供了一系列用于创建Web服务器的标准库，可以用于创建Web服务器。桥接组件可以在容器平台(比如Kubernetes)上部署运行，也可以在虚拟主机(物理机)上部署运行。本示例实施方式中，将桥接组件在Kubernetes容器平台进行使用，依靠Kubernetes的资源调度，可以方便地快速拉起Bridge组件，并且根据流量情况，自动进行扩缩容。本示例实施方式中，依靠桥接组件的自动化调度、自动扩缩容、以及高可扩展性，能够实现强大灵活的服务治理功能。并且桥接组件可以基于开源产品进行二次开发，可选技术框架非常多，降低了二次开发成本。在桥接组件上可快速地进行定制化需求开发，比如服务治理、流量控制、权限控制、路由规则、灰度发布、流量转发、多协议支持、协议转换、报文适配等。另外，通过增加桥接组件，能够提升服务网格数据面的高可扩展性，以及整个服务治理的效率。通过底层平台(如Kubernetes)可以快速的对Bridge进行扩缩容，为企业降本增效。在步骤S430中，通过桥接组件对第一流量数据进行处理，并将第一流量数据转换为与第二应用相匹配的第二流量数据。第一边车组件将拦截到的第一流量数据转发至与其相关联的桥接组件上之后，通过桥接组件对第一流量数据进行处理，根据第二应用的实际情况将第一流量数据转换为第二流量数据之后再进行转发。本示例实施方式中，通过从控制面板获取桥接组件的服务治理规则，并根据服务治理规则对第一流量数据进行处理。其中，服务治理规则可例如权限控制、限流、路由、转发、熔断等服务治理功能对应的处理规则。在管控指令下发方面，通过增加桥接组件，能够提升服务网格产品的控制效率。除此之外，还需要对流量数据中的通信协议和报文规范进行匹配。本示例实施方式中，如图5所示，将第一流量数据转换为与第二应用相匹配的第二流量数据，具体可以包括以下几个步骤：步骤S510.通过桥接组件将第一流量数据中的通信协议转换为与第二应用相匹配的通信协议。通过获取第一应用所使用的通信协议类型，以及第二应用所使用的通信协议类型，若第一应用所使用的通信协议类型与第二应用所使用的通信协议类型不同，则通过桥接组件将第一流量数据中的通信协议转换为第二应用所使用的通信协议类型。步骤S520.通过桥接组件将第一流量数据中的通信报文转换为与第二应用相匹配的通信报文。通过获取第一应用中的通信报文格式，以及第二应用中的通信报文格式，若第一应用中的通信报文格式与第二应用中的通信报文格式不同，则通过桥接组件将第一流量数据中的通信报文转换为第二应用中的通信报文格式。步骤S530.根据转换后的通信协议和通信报文得到第二流量数据。对第一流量数据中的通信协议和报文规范进行转换之后，得到与第二应用相匹配的第二流量数据。本示例实施方式中，由于桥接组件单独部署在其他容器平台上，与业务应用不在同一台宿主机上，因此在进行复杂规则处理时(如限流、路由、权限、转发、熔断降级等)，对业务应用所在的宿主机的cpu、内存、io、网络等资源毫无影响。另外，由于数据处理操作仅在桥接组件进行，边车组件只负责流量的拦截和转发，因此，相比于其他基于数据网格的实现方案来说，降低了边车组件对宿主机资源(cpu、内存、io、网络等)的依赖，减少了边车组件对应用进程的影响。同时，由于边车组件不需要进行报文解析和协议转换，因此也减少了链路长度和应用间流量通信的跳转次数，进而减少总请求时长，提升了通信效率。在步骤S440中，将第二流量数据发送至第二应用对应的第二边车组件上，并通过第二边车组件转发至第二应用。通过桥接组件处理得到第二流量数据之后，将第二流量数据转发到第二应用对应的第二边车组件上，再通过第二边车组件转发至第二应用，以完成第一应用与第二应用之间的通信过程。其中，第二边车组件与第二应用部署在同一宿主机上，第二边车组件也只负责流量的拦截和转发，不进行其他处理。图6示意性示出了根据本公开的一个具体实施方式中的基于服务网格的微服务实现的流程框图。管控面601可以控制应用之间的通信，可以使用现有的Istio等产品的能力，遵循xDS协议即可，也可以适配其他协议。在数据面602中，应用1与应用2之间通过增加一个桥接组件，相当于搭了一座虚拟的桥，在桥上加了一些控制流量的虚拟关卡，进行控制与拦截，以及复杂规则的流量处理。边车组件1和2仅执行流量的劫持和转发，具体流量劫持与转发的规则，可以通过xDS从管控面601获取相关配置。图7示意性示出了根据本公开的一个具体实施方式中的边车组件与桥接组件集群管理的示意图。在各个应用间进行通信时，边车组件701、702、703、704将流量劫持后，转发到指定的桥接组件上，由桥接组件完成权限控制、限流、路由、转发、熔断等服务治理功能，桥接组件的具体规则主要包括3部分，通信协议、报文规范和服务治理，具体规则可以通过xDS从管控面获取。其中，一个边车组件对应一个桥接组件，但是一个桥接组件可以进行多个应用之间的管理。应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。进一步的，本公开还提供了一种应用间的通信装置。参考图8所示，该应用间的通信装置可以包括流量数据获取模块810、边车组件转发模块820、流量数据处理模块830以及桥接组件转发模块840。其中：流量数据获取模块810可以用于响应于第一应用向第二应用发起的连接请求，通过第一应用对应的第一边车组件获取第一应用发送的第一流量数据；边车组件转发模块820可以用于通过第一边车组件将第一流量数据转发至与第一边车组件相关联的桥接组件上；流量数据处理模块830可以用于通过桥接组件对第一流量数据进行处理，并将第一流量数据转换为与第二应用相匹配的第二流量数据；桥接组件转发模块840可以用于将第二流量数据发送至第二应用对应的第二边车组件上，并通过第二边车组件转发至第二应用。在本公开的一些示例性实施例中，流量数据处理模块830可以包括服务治理规则获取单元，可以用于从控制面板获取桥接组件的服务治理规则，并根据服务治理规则对第一流量数据进行处理。在本公开的一些示例性实施例中，流量数据处理模块830还可以包括通信协议转换单元、通信报文转换单元以及第二流量数据生成单元。其中：通信协议转换单元可以用于通过桥接组件将第一流量数据中的通信协议转换为与第二应用相匹配的通信协议；通信报文转换单元可以用于通过桥接组件将第一流量数据中的通信报文转换为与第二应用相匹配的通信报文；第二流量数据确定单元可以用于根据转换后的通信协议和通信报文得到第二流量数据。在本公开的一些示例性实施例中，通信协议转换单元可以包括通信协议类型获取单元以及通信协议类型转换单元。其中：通信协议类型获取单元可以用于获取第一应用所使用的通信协议类型，以及第二应用所使用的通信协议类型；通信协议类型转换单元可以用于若第一应用所使用的通信协议类型与第二应用所使用的通信协议类型不同，则通过桥接组件将第一流量数据中的通信协议转换为第二应用所使用的通信协议类型。在本公开的一些示例性实施例中，通信报文转换单元可以包括通信报文格式获取单元以及通信报文格式转换单元。其中：通信报文格式获取单元可以用于获取第一应用中的通信报文格式，以及第二应用中的通信报文格式；通信报文格式转换单元可以用于若第一应用中的通信报文格式与第二应用中的通信报文格式不同，则通过桥接组件将第一流量数据中的通信报文转换为第二应用中的通信报文格式。上述应用间的通信装置中各模块/单元的具体细节在相应的方法实施例部分已有详细的说明，此处不再赘述。图9示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。需要说明的是，图9示出的电子设备的计算机系统900仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM903中，还存储有系统操作所需的各种程序和数据。CPU901、ROM902以及RAM903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。特别地，根据本发明的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本申请的系统中限定的各种功能。需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本
技术领域：
：中的公知常识或惯用技术手段。应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。当前第1页12当前第1页12
技术领域：
：，具体而言，涉及一种应用间的通信方法、应用间的通信装置、电子设备及计算机可读介质。
背景技术：
：微服务架构是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。目前，微服务架构已经成为业界的主流架构模式。但是，微服务的盛行也带来了不少的挑战，比如应用的拓扑结构更复杂、服务之间的交互稳定性降低、一个业务逻辑需要一条调用链上的多个微服务统一协调等等。鉴于此，本领域亟需一种应用间的通信方法，能够提升通信的效率和稳定性。需要说明的是，在上述
背景技术：
：部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。技术实现要素：本公开的目的在于提供一种应用间的通信方法、应用间的通信装置、电子设备及计算机可读介质，进而至少在一定程度上能够提升通信的效率和稳定性。根据本公开的第一个方面，提供一种应用间的通信方法，包括：响应于第一应用向第二应用发起的连接请求，通过所述第一应用对应的第一边车组件获取所述第一应用发送的第一流量数据；通过所述第一边车组件将所述第一流量数据转发至与所述第一边车组件相关联的桥接组件上；通过所述桥接组件对所述第一流量数据进行处理，并将所述第一流量数据转换为与所述第二应用相匹配的第二流量数据；将所述第二流量数据发送至所述第二应用对应的第二边车组件上，并通过所述第二边车组件转发至所述第二应用。在本公开的一种示例性实施例中，所述第一边车组件与所述第一应用部署在同一宿主机上，所述第二边车组件与所述第二应用部署在同一宿主机上。在本公开的一种示例性实施例中，所述桥接组件在容器平台或者虚拟主机上部署运行。在本公开的一种示例性实施例中，所述通过所述桥接组件对所述第一流量数据进行处理，包括：从控制面板获取所述桥接组件的服务治理规则，并根据所述服务治理规则对所述第一流量数据进行处理。在本公开的一种示例性实施例中，所述将所述第一流量数据转换为与所述第二应用相匹配的第二流量数据，包括：通过所述桥接组件将所述第一流量数据中的通信协议转换为与所述第二应用相匹配的通信协议；通过所述桥接组件将所述第一流量数据中的通信报文转换为与所述第二应用相匹配的通信报文；根据转换后的所述通信协议和所述通信报文得到所述第二流量数据。在本公开的一种示例性实施例中，所述通过所述桥接组件将所述第一流量数据中的通信协议转换为与所述第二应用相匹配的通信协议，包括：获取所述第一应用所使用的通信协议类型，以及所述第二应用所使用的通信协议类型；若所述第一应用所使用的通信协议类型与所述第二应用所使用的通信协议类型不同，则通过所述桥接组件将所述第一流量数据中的通信协议转换为所述第二应用所使用的通信协议类型。在本公开的一种示例性实施例中，所述通过所述桥接组件将所述第一流量数据中的通信报文转换为与所述第二应用相匹配的通信报文，包括：获取所述第一应用中的通信报文格式，以及所述第二应用中的通信报文格式；若所述第一应用中的通信报文格式与所述第二应用中的通信报文格式不同，则通过所述桥接组件将所述第一流量数据中的通信报文转换为所述第二应用中的通信报文格式。根据本公开的第二方面，提供一种应用间的通信装置，包括：流量数据获取模块，用于响应于第一应用向第二应用发起的连接请求，通过所述第一应用对应的第一边车组件获取所述第一应用发送的第一流量数据；边车组件转发模块，用于通过所述第一边车组件将所述第一流量数据转发至与所述第一边车组件相关联的桥接组件上；流量数据处理模块，用于通过所述桥接组件对所述第一流量数据进行处理，并将所述第一流量数据转换为与所述第二应用相匹配的第二流量数据；桥接组件转发模块，用于将所述第二流量数据发送至所述第二应用对应的第二边车组件上，并通过所述第二边车组件转发至所述第二应用。根据本公开的第三方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的应用间的通信方法。根据本公开的第四方面，提供一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的应用间的通信方法。本公开示例性实施例可以具有以下有益效果：本公开示例实施方式的应用间的通信方法中，通过在两个应用之间增加一个桥接组件，在实现应用间的通信时，仅通过边车组件完成流量的拦截和转发，对于通信时的复杂规则控制则通过桥接组件来完成。本公开示例实施方式中的应用间的通信方法，通过增加桥接组件，一方面，能够降低边车组件对宿主机资源的依赖和占用，减少边车组件对应用进程的影响，提高通信过程的稳定性；另一方面，通过减少通信过程中的链路长度，减少应用间流量通信的跳转次数，从而提升通信的效率；再一方面，由于桥接组件具有自动化调度、自动扩缩容以及高可扩展性的特点，并且在桥接组件上可以快速进行定制化需求开发，因此能够在降低二次开发成本的同时，提升服务网格数据面的可扩展性以及整个服务治理的效率，并进一步提升通信的效率。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。附图说明此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1示意性示出了基于远程过程调用框架的微服务实现的流程框图；图2示意性示出了根据本公开的一个相关实施例中的基于服务网格的微服务实现的流程框图；图3示意性示出了根据本公开的一个相关实施例中的通过企业服务总线进行通信的流程框图；图4示出了本公开示例实施方式的应用间的通信方法的流程示意图；图5示出了本公开示例实施方式的将第一流量数据转换为第二流量数据的流程示意图；图6示意性示出了根据本公开的一个具体实施方式中的基于服务网格的微服务实现的流程框图；图7示意性示出了根据本公开的一个具体实施方式中的边车组件与桥接组件集群管理的示意图；图8示出了本公开示例实施方式的应用间的通信装置的框图；图9示出了适于用来实现本公开实施方式的电子设备的计算机系统的结构示意图。具体实施方式现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。微服务架构已经成为目前业界的主流架构模式，它使得企业服务中的各个组件可以独立地开发、测试、部署、升级以及扩缩容，使应用的迭代升级更敏捷。但是微服务的盛行也带来了不少的挑战，比如应用的拓扑结构更复杂、服务之间的交互稳定性降低、一个业务逻辑需要一条调用链上的多个微服务统一协调，更容易引起雪崩问题等等；另外，微服务之间的安全问题也暴露了出来，比如权限控制、通信安全等。图1示意性示出了基于远程过程调用框架的微服务实现的流程框图，上述如图1所示的基于RPC(RemoteProcedureCall，远程过程调用)框架的微服务实现，存在代码侵入、SDK(SoftwareDevelopmentKit，软件开发工具包)升级困难等问题。在此基础上，一些相关实施例中，可以将服务网格ServiceMesh应用在微服务中以解决上述问题。例如，Istio是一个开源的服务网格产品，以透明层的方式构建在现有分布式应用中，可以以统一的方式去检测和管理微服务。目前Istio默认的数据面实现是Envoy，Envoy是专为大型现代SOA(Service-OrientedArchitecture，面向服务架构)设计的L7代理和通信总线。该项目源于以下理念：网络对应用程序来说应该是透明的。当网络和应用程序出现问题时，应该很容易确定问题的根源。图2示意性示出了根据本公开的一个相关实施例中的基于服务网格的微服务实现的流程框图，通过管控面API(ApplicationProgrammingInterface，应用程序接口)201可以控制应用APP之间的通信，其中，Pilot是Istio流量管理的核心组件，用户通过Pilot的API管理网络相关的资源对象，Pilot会根据用户的配置和服务的信息把网络流量管理变成Envoy能识别的格式并分发至各个Sidecar(边车)代理中。在Istio架构中，Mixer充当应用代码和后端基础设施的中间层，为整个集群执行访问控制和管理，并且收集代理观察到的服务之间的流量统计数据。Istio-Auth(Authentication)为身份认证组件。应用1与应用2之间进行通信时，如果两个应用所使用的协议不同或者报文不同，可以分别通过两个应用对应的边车组件进行转换使两边适配。然而，目前的服务网格数据面产品，如Envoy等，在实际应用中仍然存在以下几点问题：1、对应用进程的影响。在服务网格落地时，避免不了需要面对企业现有的部署环境、服务开发框架和通信协议，并且有一部分的企业服务(特别是金融行业的部分老旧系统)会使用如图3所示的方法，通过企业服务总线的方式进行应用间的通信。这些系统无法进行系统改造，甚至是重新编译部署，但是，这些系统往往承担了比较重要的职责(如银行核心系统)。在这个背景下对服务网格的数据面产品就有了非常高的要求，即适配各种部署环境(虚机、物理机、容器、私有云、公有云；服务开发框架：多版本并行的dubbo(开源分布式服务框架)、springcloud(一种云应用开发工具)、自研框架)以及各种通信协议和报文规范(tcp、http、dubbo、webservice、8583、定长等)，当边车组件Sidecar在执行复杂处理逻辑时，对宿主机的cpu(centralprocessingunit，中央处理器)、内存、网络、io(Input/Output，输入/输出)等资源会有一定要求，进而对应用服务有一定的影响。2、对请求时长的影响。当需要进行协议转换时，现有服务网格数据面的产品(如Envoy)需要进行多次协议转换。如图2所示，假设应用1使用的是tcp协议，应用2使用的是webservice协议，当应用1访问应用2时，应用1发出的socket(tcp)请求被边车组件1拦截，边车组件1读取报文后，将应用1所发出的tcp请求转换成grpc(RPC框架)协议并转发至边车组件2，边车组件2进而将请求转换为webservice协议，最终转发给应用2。通过上述过程可以看出，整个流程进行了两次协议转换，应用1->边车组件1->边车组件2->应用2，且两个边车组件均进行了报文解析和协议转换，并且增加了调用链路，对总请求时长有一定的影响。3、服务网格还需要有服务治理的能力，应用1访问应用2时，当需要进行权限、安全、限流、熔断等服务治理时，需要同时将响应的规则通过某种协议，比如xDS(Envoy获取配置信息的传输协议)发给边车组件1和边车组件2，当集群中应用服务非常多的时候，边车组件的数量也非常多，这种规则下发会占用大量网络资源。基于上述问题，本示例实施方式首先提供了一种应用间的通信方法。参考图4所示，上述应用间的通信方法可以包括以下步骤：步骤S410.响应于第一应用向第二应用发起的连接请求，通过第一应用对应的第一边车组件获取第一应用发送的第一流量数据。步骤S420.通过第一边车组件将第一流量数据转发至与第一边车组件相关联的桥接组件上。步骤S430.通过桥接组件对第一流量数据进行处理，并将第一流量数据转换为与第二应用相匹配的第二流量数据。步骤S440.将第二流量数据发送至第二应用对应的第二边车组件上，并通过第二边车组件转发至第二应用。本公开示例实施方式的应用间的通信方法中，通过在两个应用之间增加一个桥接组件，在实现应用间的通信时，仅通过边车组件完成流量的拦截和转发，对于通信时的复杂规则控制则通过桥接组件来完成。本公开示例实施方式中的应用间的通信方法，通过增加桥接组件，一方面，能够降低边车组件对宿主机资源的依赖和占用，减少边车组件对应用进程的影响，提高通信过程的稳定性；另一方面，通过减少通信过程中的链路长度，减少应用间流量通信的跳转次数，从而提升通信的效率；再一方面，由于桥接组件具有自动化调度、自动扩缩容以及高可扩展性的特点，并且在桥接组件上可以快速进行定制化需求开发，因此能够在降低二次开发成本的同时，提升服务网格数据面的可扩展性以及整个服务治理的效率，并进一步提升通信的效率。下面，结合图5至图7对本示例实施方式的上述步骤进行更加详细的说明。在步骤S410中，响应于第一应用向第二应用发起的连接请求，通过第一应用对应的第一边车组件获取第一应用发送的第一流量数据。在基于服务网格的微服务实现中，边车模式是通过给应用服务加装一个边车组件，来达到控制和逻辑的分离的目的。比如日志记录、监控、流量控制、服务注册、服务发现、服务限流、服务熔断等在应用服务中不需要实现的控制面功能，可以交给边车组件进行处理，应用服务只需要专注实现业务逻辑即可。本示例实施方式中，当第一应用需要与第二应用进行通信时，由第一应用向第二应用发起连接请求。响应于第一应用向第二应用发起的连接请求，与第一应用部署在同一宿主机上的第一边车组件仅做流量劫持处理，即获取第一应用发送的第一流量数据，而不进行其他操作。由于边车组件未做复杂逻辑处理，仅做流量劫持与转发，所以对宿主机占用的cpu、io、网络、内存等资源极少，基本对业务应用无影响。由于处理逻辑简单也降低了升级的频次。边车组件的具体技术方案可以通过iptables、ipvs、cilium、ebpf等技术实现，其中，iptables是Linux防火墙工作在用户空间的管理工具，其主要功能是实现对网络数据包进出设备及转发的控制；ipvs(IPVirtualServer，IP虚拟服务器)是一种负载均衡器，能够实现传输层负载平衡；cilium是一个用于透明保护部署在Linux容器管理平台(比如Docker和Kubernetes)上的应用服务之间网络连接的开源软件；ebpf(extendedBerkeleyPacketFilter，扩展伯克利包过滤器)是一个通用执行引擎，可基于此开发性能分析工具、软件定义网络等诸多场景。在步骤S420中，通过第一边车组件将第一流量数据转发至与第一边车组件相关联的桥接组件上。本示例实施方式中，在整个数据面方案中增加了桥接组件(Bridge)。第一边车组件获取到第一应用发送的第一流量数据之后，将其转发至与第一边车组件相关联的桥接组件上，并通过桥接组件来进行通信过程中的复杂规则控制。桥接组件为轻量级高性能高可扩展性网络代理产品，可实现服务治理、限流、权限、路由、转发、熔断、多协议适配等功能，可以由Nginx、Openresty、Netty、Go等技术实现，其中，Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件代理服务器；Openresty是一个全功能的Web应用服务器；Netty是一个利用Java的高级网络的能力，隐藏其背后的复杂性而提供一个易于使用的API的客户端/服务器框架；Go提供了一系列用于创建Web服务器的标准库，可以用于创建Web服务器。桥接组件可以在容器平台(比如Kubernetes)上部署运行，也可以在虚拟主机(物理机)上部署运行。本示例实施方式中，将桥接组件在Kubernetes容器平台进行使用，依靠Kubernetes的资源调度，可以方便地快速拉起Bridge组件，并且根据流量情况，自动进行扩缩容。本示例实施方式中，依靠桥接组件的自动化调度、自动扩缩容、以及高可扩展性，能够实现强大灵活的服务治理功能。并且桥接组件可以基于开源产品进行二次开发，可选技术框架非常多，降低了二次开发成本。在桥接组件上可快速地进行定制化需求开发，比如服务治理、流量控制、权限控制、路由规则、灰度发布、流量转发、多协议支持、协议转换、报文适配等。另外，通过增加桥接组件，能够提升服务网格数据面的高可扩展性，以及整个服务治理的效率。通过底层平台(如Kubernetes)可以快速的对Bridge进行扩缩容，为企业降本增效。在步骤S430中，通过桥接组件对第一流量数据进行处理，并将第一流量数据转换为与第二应用相匹配的第二流量数据。第一边车组件将拦截到的第一流量数据转发至与其相关联的桥接组件上之后，通过桥接组件对第一流量数据进行处理，根据第二应用的实际情况将第一流量数据转换为第二流量数据之后再进行转发。本示例实施方式中，通过从控制面板获取桥接组件的服务治理规则，并根据服务治理规则对第一流量数据进行处理。其中，服务治理规则可例如权限控制、限流、路由、转发、熔断等服务治理功能对应的处理规则。在管控指令下发方面，通过增加桥接组件，能够提升服务网格产品的控制效率。除此之外，还需要对流量数据中的通信协议和报文规范进行匹配。本示例实施方式中，如图5所示，将第一流量数据转换为与第二应用相匹配的第二流量数据，具体可以包括以下几个步骤：步骤S510.通过桥接组件将第一流量数据中的通信协议转换为与第二应用相匹配的通信协议。通过获取第一应用所使用的通信协议类型，以及第二应用所使用的通信协议类型，若第一应用所使用的通信协议类型与第二应用所使用的通信协议类型不同，则通过桥接组件将第一流量数据中的通信协议转换为第二应用所使用的通信协议类型。步骤S520.通过桥接组件将第一流量数据中的通信报文转换为与第二应用相匹配的通信报文。通过获取第一应用中的通信报文格式，以及第二应用中的通信报文格式，若第一应用中的通信报文格式与第二应用中的通信报文格式不同，则通过桥接组件将第一流量数据中的通信报文转换为第二应用中的通信报文格式。步骤S530.根据转换后的通信协议和通信报文得到第二流量数据。对第一流量数据中的通信协议和报文规范进行转换之后，得到与第二应用相匹配的第二流量数据。本示例实施方式中，由于桥接组件单独部署在其他容器平台上，与业务应用不在同一台宿主机上，因此在进行复杂规则处理时(如限流、路由、权限、转发、熔断降级等)，对业务应用所在的宿主机的cpu、内存、io、网络等资源毫无影响。另外，由于数据处理操作仅在桥接组件进行，边车组件只负责流量的拦截和转发，因此，相比于其他基于数据网格的实现方案来说，降低了边车组件对宿主机资源(cpu、内存、io、网络等)的依赖，减少了边车组件对应用进程的影响。同时，由于边车组件不需要进行报文解析和协议转换，因此也减少了链路长度和应用间流量通信的跳转次数，进而减少总请求时长，提升了通信效率。在步骤S440中，将第二流量数据发送至第二应用对应的第二边车组件上，并通过第二边车组件转发至第二应用。通过桥接组件处理得到第二流量数据之后，将第二流量数据转发到第二应用对应的第二边车组件上，再通过第二边车组件转发至第二应用，以完成第一应用与第二应用之间的通信过程。其中，第二边车组件与第二应用部署在同一宿主机上，第二边车组件也只负责流量的拦截和转发，不进行其他处理。图6示意性示出了根据本公开的一个具体实施方式中的基于服务网格的微服务实现的流程框图。管控面601可以控制应用之间的通信，可以使用现有的Istio等产品的能力，遵循xDS协议即可，也可以适配其他协议。在数据面602中，应用1与应用2之间通过增加一个桥接组件，相当于搭了一座虚拟的桥，在桥上加了一些控制流量的虚拟关卡，进行控制与拦截，以及复杂规则的流量处理。边车组件1和2仅执行流量的劫持和转发，具体流量劫持与转发的规则，可以通过xDS从管控面601获取相关配置。图7示意性示出了根据本公开的一个具体实施方式中的边车组件与桥接组件集群管理的示意图。在各个应用间进行通信时，边车组件701、702、703、704将流量劫持后，转发到指定的桥接组件上，由桥接组件完成权限控制、限流、路由、转发、熔断等服务治理功能，桥接组件的具体规则主要包括3部分，通信协议、报文规范和服务治理，具体规则可以通过xDS从管控面获取。其中，一个边车组件对应一个桥接组件，但是一个桥接组件可以进行多个应用之间的管理。应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。进一步的，本公开还提供了一种应用间的通信装置。参考图8所示，该应用间的通信装置可以包括流量数据获取模块810、边车组件转发模块820、流量数据处理模块830以及桥接组件转发模块840。其中：流量数据获取模块810可以用于响应于第一应用向第二应用发起的连接请求，通过第一应用对应的第一边车组件获取第一应用发送的第一流量数据；边车组件转发模块820可以用于通过第一边车组件将第一流量数据转发至与第一边车组件相关联的桥接组件上；流量数据处理模块830可以用于通过桥接组件对第一流量数据进行处理，并将第一流量数据转换为与第二应用相匹配的第二流量数据；桥接组件转发模块840可以用于将第二流量数据发送至第二应用对应的第二边车组件上，并通过第二边车组件转发至第二应用。在本公开的一些示例性实施例中，流量数据处理模块830可以包括服务治理规则获取单元，可以用于从控制面板获取桥接组件的服务治理规则，并根据服务治理规则对第一流量数据进行处理。在本公开的一些示例性实施例中，流量数据处理模块830还可以包括通信协议转换单元、通信报文转换单元以及第二流量数据生成单元。其中：通信协议转换单元可以用于通过桥接组件将第一流量数据中的通信协议转换为与第二应用相匹配的通信协议；通信报文转换单元可以用于通过桥接组件将第一流量数据中的通信报文转换为与第二应用相匹配的通信报文；第二流量数据确定单元可以用于根据转换后的通信协议和通信报文得到第二流量数据。在本公开的一些示例性实施例中，通信协议转换单元可以包括通信协议类型获取单元以及通信协议类型转换单元。其中：通信协议类型获取单元可以用于获取第一应用所使用的通信协议类型，以及第二应用所使用的通信协议类型；通信协议类型转换单元可以用于若第一应用所使用的通信协议类型与第二应用所使用的通信协议类型不同，则通过桥接组件将第一流量数据中的通信协议转换为第二应用所使用的通信协议类型。在本公开的一些示例性实施例中，通信报文转换单元可以包括通信报文格式获取单元以及通信报文格式转换单元。其中：通信报文格式获取单元可以用于获取第一应用中的通信报文格式，以及第二应用中的通信报文格式；通信报文格式转换单元可以用于若第一应用中的通信报文格式与第二应用中的通信报文格式不同，则通过桥接组件将第一流量数据中的通信报文转换为第二应用中的通信报文格式。上述应用间的通信装置中各模块/单元的具体细节在相应的方法实施例部分已有详细的说明，此处不再赘述。图9示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。需要说明的是，图9示出的电子设备的计算机系统900仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM903中，还存储有系统操作所需的各种程序和数据。CPU901、ROM902以及RAM903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。特别地，根据本发明的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本申请的系统中限定的各种功能。需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本
技术领域：
：中的公知常识或惯用技术手段。应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
