CN112351114A

CN112351114A - 一种信息处理方法、装置以及存储介质

Info

Publication number: CN112351114A
Application number: CN201910722552.6A
Authority: CN
Inventors: 刘唯一
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Priority date: 2019-08-06
Filing date: 2019-08-06
Publication date: 2021-02-09
Anticipated expiration: 2039-08-06
Also published as: CN112351114B

Abstract

本发明实施例提供一种信息处理方法以及装置，其中所述方法包括：在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包；其中，所述第一文件包为至少一个第一组件中目标第一组件的客户端对应的文件包；将第二文件包添加到至少一个第一组件中，得到更新后的第一组件；所述第一组件包括第一组件的客户端、第一组件的服务器端；基于更新后的第一组件，生成所述至少一个第一组件服务器端对应的地址信息的接口文件；其中，所述接口文件用于表征服务注册与服务契约租赁的接口。应用本发明所述方法，能够实现服务之间直接通过互联网协议(IP)地址进行交互，有效减少对物理机端口的占用。

Description

一种信息处理方法、装置以及存储介质

技术领域

本发明涉及业务支撑领域，尤其涉及一种信息处理方法、装置以及存储介质。

背景技术

在微服务应用中，将微服务集群迁移到Kubernetes平台后，Kubernetes平台中的域名系统(Domain Name System，DNS)解析不能将Spring Cloud微服务框架中的逻辑宿主机(pod)的地址解析成对应的互联网协议(Internet Protocol，IP)地址。因此，pod之间的交互只能通过端口(port)来进行，由于每个应用至少会占用一个宿主机的port，那么当存在很多应用时，通过port的交互会加大宿主机的端口的管理成本。

发明内容

有鉴于此，本发明实施例期望提供一种信息处理方法及装置，能够实现将服务所在的pod的地址解析成对应的IP地址，从而实现服务之间通过IP地址来进行交互，有效减少对端口的占用，减轻宿主机的端口管理成本。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例提供一种信息处理方法，所述方法包括：

在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包；其中，所述第一文件包为至少一个第一组件中目标第一组件的客户端对应的文件包；

将第二文件包添加到至少一个第一组件中，得到更新后的第一组件；所述第一组件包括第一组件的客户端、第一组件的服务器端；

基于更新后的第一组件，生成所述至少一个第一组件服务器端对应的地址信息的接口文件；其中，所述接口文件用于表征服务注册与服务契约租赁的接口。

在上述方案中，所述在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包，包括：

在第一文件包中创建第一配置类；

在第一文件包中的所述第一配置类中加入第一函数，得到第二文件包；

其中，所述第一配置类用于在程序启动后，替换所述至少一个第一组件客户端中原生的配置类；所述第一函数用于获取所述至少一个第一组件服务器端的地址信息。

在上述方案中，所述在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包前，所述方法还包括：

在容器管理平台中创建至少一个第一组件；

基于所述至少一个第一组件，创建第一项目，并在第一项目的布局文件中引入所述第一文件包。

在上述方案中，所述在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包后，所述方法还包括：

将所述第二文件包添加到第二组件中，得到更新后的第二组件；所述更新后的第二组件用于监控服务的调用过程。

在上述方案中，所述方法还包括：

依据更新后的第二组件，记录所述接口文件的调用过程，并对所述调用过程进行分析，得出分析结果，基于分析结果，对调用过程进行监控。

本发明实施例还提供一种信息处理方法，所述方法包括：

调用接口文件；

基于所述接口文件，将服务信息注册到至少一个第一组件的服务器端中，并返回服务信息注册列表；

基于所述服务信息注册列表，访问服务信息。

在上述方案中，所述基于所述服务信息注册列表，访问服务信息，包括：

登陆第一组件的服务器端的站点页面；

在所述站点页面的服务信息注册列表中选择至少一条服务信息；

基于所述服务信息中所述第一组件的服务器端的地址信息访问对应的服务信息。

本发明实施例还提供一种信息处理装置，所述装置包括：扩展模块、更新模块以及接口生成模块；其中，

所述扩展模块，用于在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包；其中，所述第一文件包为至少一个第一组件中目标第一组件的客户端对应的文件包；

所述更新模块，用于将第二文件包添加到至少一个第一组件中，得到更新后的第一组件；所述第一组件包括第一组件的客户端、第一组件的服务器端；

所述接口生成模块，用于基于更新后的第一组件，生成所述至少一个第一组件服务器端对应的地址信息的接口文件；其中，所述接口文件为用于表征服务注册与服务契约租赁的接口。

在上述装置中，所述扩展模块，用于在第一文件包中创建第一配置类；在第一文件包中的所述第一配置类中加入第一函数，得到第二文件包；

在上述装置中，所述装置还包括：第一组件创建模块；

所述第一组件创建模块，用于在容器管理平台中创建至少一个第一组件；基于所述至少一个第一组件，创建第一项目，并在第一项目的布局文件中引入所述第一文件包。

在上述装置中，所述装置还包括：第二组件创建模块；

所述第二组件创建模块，用于将所述第二文件包添加到第二组件中，得到更新后的第二组件；所述更新后的第二组件用于监控服务的调用过程。

在上述装置中，所述第二组件创建模块，用于依据更新后的第二组件，记录所述接口文件的调用过程，并对所述调用过程进行分析，得出分析结果，基于分析结果，对调用过程进行监控。

本发明实施例还提供一种信息处理装置，所述装置包括：调用模块、注册模块以及访问模块；其中，

所述调用模块，用于调用接口文件；

所述注册模块，用于基于所述接口文件，将服务信息注册到所述至少一个第一组件的服务器端中，并返回服务信息注册列表；

所述访问模块，用于基于所述服务信息注册列表，访问服务信息。

在上述装置中，所述访问模块，用于登陆第一组件的服务器端的站点页面；

本发明还提供一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序被处理器执行时实现上述所述方法的任一步骤。

本发明还提供一种信息处理装置，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器用于运行所述计算机程序时，执行上述所述方法的步骤。

本发明实施例提供的信息处理方法以及装置，通过在第一组件的第一文件包中加入第一函数对第一文件包进行扩展，由此可以基于第一函数获取地址信息的功能，使得通过扩展后的第一文件包对第一组件进行部署后，可以基于所述部署直接生成第一组件地址信息对应的接口文件。由此可以实现通过Kubernetes平台中的DNS解析，直接解析出微服务中第一组件所在pod的IP地址，进而可以基于所述IP地址进行服务的注册与发现，从而有效减少对端口的占用。

附图说明

图1为本发明实施例提供的一种信息处理方法的流程图；

图2为本发明实施例提供的一种微服务架构；

图3为在组件中引入扩展包的部署流程；

图4为本发明实施例提供的另一种信息处理方法的流程图；

图5为本发明实施例提供的一种信息处理装置的结构示意图；

图6为本发明实施例提供的另一种信息处理装置的结构示意图；

图7为本发明实施例信息处理装置的一种硬件结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对发明的具体技术方案做进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

需要说明的是，微服务就是将一个原本独立的系统拆分成多个功能模块，拆分后每个功能模块可以作为一个独立的子系统运行，这样的一个子系统就称为一个微服务。

为了实现在服务发现时可以根据Kubernetes平台内的DNS解析直接得到服务发现组件(eureka)所在的pod的IP地址，本发明实施例提供一种信息处理方法，如图1所示，所述方法包括：

S101，在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包；其中，所述第一文件包为至少一个第一组件中目标第一组件的客户端对应的文件包。

这里，所述第一组件为服务发现组件(eureka)；在本发明实施例中，所述eureka组件被集成在Spring Cloud微服务框架的子项目Spring Cloud Netflix中，以实现服务发现的功能。

其中，所述eureka组件既可以提供服务发现功能，也可以提供服务注册功能。

对于服务发现功能，所述服务发现可以让一个应用或者组件，发现所述服务自身的运行环境以及其他服务或者组件的信息。

对于服务注册功能，所述服务注册是指一个服务将自身的位置信息在注册中心进行注册的过程；这里，所述服务一般会将它的主机的IP地址以及port进行注册，有时候也会注册服务访问的认证信息、使用协议、版本号以及关于环境的内容。

需要说明的是，在微服务的框架中，所述eureka组件包含两个组件：服务端组件(eureka server)和客户端组件(eureka client)；其中，所述eureka client分为服务提供者和服务消费者。

这里，所述eureka server通常作为服务注册中心使用，用于提供服务注册功能。具体地，各个微服务启动时，会通过eureka client向eureka server进行注册；对应地，所述eureka server会存储所述注册信息。

所述eureka client是一个Java客户端，用于和所述eureka server进行交互，同时所述eureka client也是一个内置的默认使用轮询负载均衡算法的负载均衡器。

需要说明的是，当eureka client作为服务提供者时，用于提供服务；其中，所提供的服务需要向eureka server进行注册。具体地，在应用启动后，eureka client会向eurekaserver发送心跳(默认周期为30秒)，如果所述eureka server在多个心跳周期内没有接受到某个服务节点的心跳，eureka server将会从服务注册表中将所述服务移出(默认90秒)。当所述eureka client作为服务消费者时，用于调用服务；具体地，在服务信息列表中发现待调用的服务，并消费所述服务。

这里，需要说明的是，所述eureka client可以既是服务提供者，也是服务消费者。

还需要说明的是，所述注册中心可以由单台eureka server实现，也可以由多台eureka server实现。

这里，如果所述服务注册中心由单台eureka server部署，可能会因为服务注册中心的故障导致整个服务瘫痪。因此，可能需要在生产环境中通过多个eureka server节点部署服务注册中心，来保证服务注册中心的整体持续可用。

在本发明实施例中，通过部署多个eureka server节点组成eureka集群来保证服务注册中心的整体持续可用。

为了更好地理解本发明实施例中服务发现组件(eureka)的实现原理，如图2所示为一个微服务架构，具体地：

如图2所示，所述微服务架构由3个角色组成：服务发现组件服务器端(eurekaserver)、服务发现组件客户端(eureka client)的服务提供者、服务发现组件客户端(eureka client)的服务消费者。

其中，所述eureka server为服务注册中心，提供服务注册和发现；所述服务提供方将自身服务注册到eureka server，从而使服务消费方能够找到；所述服务消费方从eureka server获取注册的服务列表，从而能够消费服务。

需要注意的是，图2中的3个角色都是逻辑角色，在实际运行中，这几个角色甚至可以是同一个主体，例如，所述eureka server也可以充当服务提供方。

在图2中，所述服务发现组件集群由3个eureka server组成。在服务启动时，服务提供者会向任意一个eureka server注册信息，所述注册信息包括服务名、IP、port、心跳周期等信息；所述eureka server获取注册请求，将服务信息存入到读写缓存中，并向其他eureka server进行信息的同步。

这里，所述向其他eureka server进行信息的同步，具体是，当eureka client向其中一个eureka server进行服务注册时，它会提供注册信息，收到注册信息的eurekaserver会将所述注册信息向另一个eureka server进行同步。

需要注意的是，当存在3个以上的eureka server时，例如eureka server1、eurekaserver2、eureka server3，当eureka client向eureka server1进行注册后，eurekaserver1会将注册信息同步至eureka server2，但eureka server2不会将从eurekaserver1那里同步到的信息同步给eureka server3，只能由eureka server1向eurekaserver3进行同步。

本发明实施例的服务注册发现的基本过程如下：首先需要一个服务注册中心eureka server，作为服务提供者的eureka client向服务注册中心eureka server注册，将自己的信息通过接口(API)的形式提交给服务注册中心eureka server。作为服务消费者的eureka client向服务注册中心eureka server注册，同时服务消费者获取一份服务信息注册列表，该列表包含了所有向服务注册中心eureka server注册的服务信息。在获取服务信息注册列表之后，作为服务消费者的eureka client就可以知道作为服务提供者的eurekaclient的IP地址，可以通过访问所述IP地址消费服务提供者提供的服务。

需要说明的是，对于服务注册中心来说，所述服务消费者和服务提供者都是客户端；服务提供者和服务消费者可以互为提供与消费的关系。

在本发明实施例中，在应用服务对所述eureka server进行注册之前，需要部署eureka server、eureka client。

这里，为了实现根据Kubernetes平台中的DNS解析可以得到eureka组件所在的pod的IP地址，在部署eureka server、eureka client的过程中，需要对eureka client的jar包进行修改，使用修改后的jar包来部署eureka server、eureka client。

具体地，在步骤S101中，所述第一文件包是指eureka client的jar包，本发明是对eureka client的jar包进行修改。

所述对eureka client的jar包进行修改具体是指在jar包中添加用于获取地址信息的第一函数，由此得到修改后的jar包，即第二文件包。

需要说明的是，由于在eureka集群中存在多个eureka组件。这里，所述第一文件包可以为多个eureka组件中任意一个eureka组件的客户端(eureka client)对应的jar包。

S102，将第二文件包添加到至少一个第一组件中，得到更新后的第一组件；所述第一组件包括第一组件的客户端、第一组件的服务器端；

在本发明实施例中，通过第二文件包来部署eureka组件，具体地，通过第二文件包来部署服务发现组件的服务器端(eureka server)，以及服务发现组件的客户端(eurekaclient)。

这里，所述部署是指将第二文件包添加到对应的组件中。

这里，由于所述第二文件包中包含获取地址信息的第一函数，在微服务启动后，更新后的eureka组件同样包含获取地址信息的第一函数，可以实现对eureka组件所在逻辑宿主机pod的IP地址的获取。

S103，基于更新后的第一组件，生成所述至少一个第一组件服务器端对应的地址信息的接口文件；其中，所述接口文件用于表征服务注册与服务契约租赁的接口。

这里，在进行服务发现时，由于更新后的第一组件eureka中包含获取地址信息的第一函数，可以在服务启动后，通过DNS解析获取每个第一组件所在pod的IP地址。

在本发明实施例中，可以对获取的第一组件的IP地址进行统一的封装，形成IP地址组成的接口文件；所述接口文件提供给其他的服务进行调用，其他服务通过调用这个接口实现服务的注册和服务契约租赁。

下面对Kubernetes平台上搭建Spring Cloud微服务架构的过程进行描述:

具体地，在Kubernetes平台中创建至少一个第一组件；所述Kubernetes平台是一种容器管理平台。

这里，首先需要准备Kubernetes平台环境。

所述Kubernetes平台环境的搭建可以自行搭建，也可以直接采用谷歌、阿里云等提供的Kubernetes平台环境。

在安装了Kubernetes平台后，在Kubernetes平台中新建一个命名空间，例如eureka。

新建一个应用的标签，例如eureka-server；这里，所述标签用于筛选服务，部署的eureka服务都会被标上这个标签。

新建一个headless service，例如eureka-server-service；由此，所述headlessservice对应的域名就是eureka-server-service或者eureka.eureka-server-service。

如此就完成了Kubernetes平台的相关配置工作，然后开始在Kubernetes平台上部署eureka组件。

这里，首先需要部署服务注册中心，所述服务注册中心由eureka server组成；然后部署eureka client的服务提供方和消费方，最后部署网关。

需要说明的是，将所述eureka组件部署的在Kubernetes平台上，可以通过镜像服务的方式。这里，所述镜像服务可以是自行构建，也可以直接采用各个公司的Kubernetes集群服务中提供的镜像选择，具体操作在此不作赘述。

对于注册中心的部署：

新建一个项目，并在项目的布局文件中引入需要的依赖内容；这里，可以将该项目命名为spring-boot，所述布局文件是指pom.xml文件。

为了实现通过修改后的jar包来部署eureka组件，在所述pom.xml文件中引入eureka client的jar包。

需要说明的是，为了防止注册中心崩溃，所述注册中心可以采用集群的方式，即构建高可用eureka集群。如此，上述新建的spring-boot项目就可以作为eureka server集群项目。

这里，还需要准备配置文件。

需要说明的是，所述配置文件可以是所述spring-boot项目资源(resources)目录下的配置文件，具体地，所述配置文件可以是application.yaml文件；在所述application.yaml文件中添加关于服务主机、服务名称等配置。所述配置文件还可以是properties文件。

这里，以配置文件为properties文件进行说明。

应理解，对于eureka server集群的情况，需要部署多个eureka server节点。在同一个项目中部署多个eureka server节点，需要使用不同的配置。例如，可以在本发明实施例的spring-boot一个项目的前提下，通过不同的启动参数来启动占用不同端口的三个服务来模拟eureka集群。

这里，可以创建多个配置文件作为集群不同的节点配置文件；例如，通过application-eureka-server1.properties文件来配置eureka-server1节点；通过application-eureka-server2.properties文件来配置eureka-server2节点，以此类推，配置其他节点。

在创建了多个配置文件后，所述节点的启动可以通过指定的启动参数来实现。例如，可通过配置启动参数：spring.profiles＝eureka-server1，来启动eureka-server1节点，相应地，配置spring.profiles＝eureka-server2，来启动eureka-server2节点，以此类推，启动其他节点。

进一步地，还需要创建启动类：在第一文件包中创建第一配置类；

这里，具体是在spring-boot项目中创建第一配置类；例如，所述第一配置类可以设置为SuyanCustomConfigure类；所述第一配置类为一种启动类。

需要说明的是，对于创建的第一配置类，需要在其中添加注解，如添加@EnableEurekaServer注解，所述注解用于开启对eureka server的支持，即通过所述注解表明当前创建的是eureka server。

在本发明实施例中，为了实现在Kubernetes部署后，可以根据Kubernetes中的DNS解析出eureka所在pod的IP地址，在上述第一配置类中加入第一函数；所述第一函数可以获取所有eureka组件所在pod的IP地址。

这里，所述第一配置类为一个启动类；那么在所述第一配置类中添加了第一函数后，可以在程序启动后，使用更新后的第一配置类替换掉原始的启动类。例如，可以使用添加了第一函数的SuyanCustomConfigure类替换掉eureka client原生的EurekaClientConfigBean类。

至此完成了注册中心的部署。

这里，由于第一函数的作用，可以在程序启动后，返回eureka集群中所有eureka组件所在pod的IP地址。那么，在本发明实施例中，可以对返回的所有eureka组件所在pod的IP地址进行统一的封装，形成接口文件，将所述接口文件返回给eureka client调用。

接着，部署服务发现组件客户端(eureka client)：

先新建一个项目，同样地，可以将所述项目命名为spring-boot，并在项目的布局文件中引入需要的依赖内容；这里，所述布局文件是指pom.xml文件，为了实现通过修改后的jar包来部署eureka组件，在所述pom.xml文件中引入jar包。

同样的，准备配置文件；这里，所述配置文件中可以配置端口号，服务名称和服务注册中心地址。

创建启动类，即创建第一配置类，并在创建的第一配置类中添加注解。

这里，与上述eureka server不同的是，由于所述eureka client可以作为服务提供者，以及服务消费者，那么在配置文件中需要对此进行说明。

这里，可以对上述创建的第一配置类的命名进行区分，例如，在所述eurekaclient的部署中，创建第一配置类可以命名为DiscoverySuyanConfig类，用于配置服务对ConfigServer的支持。那么，在所述命名为DiscoverySuyanConfig类的第一配置类中通过添加@EnableEurekaClient注解，来表明当前创建的是eureka client。

对于当前创建的eureka client具体是何种身份，可以通过编写具体服务提供控制类来表明当前创建的是服务提供者(Provider)，还是服务消费者(Consumer)。

在创建第一配置类后，同样的，在所述第一配置类中加入第一函数；所述第一函数可以获取所有eureka组件所在pod的IP地址。在所述第一配置类中添加了第一函数后，可以在程序启动后，使用更新后的第一配置类替换掉原始的启动类。

需要说明的是，当所述eureka client为服务消费者时，所述部署流程与上述服务提供者不同之处在于增加了RestTemplate类实例，所述RestTemplate实例，主要用于调用远程服务。例如，所述RestTemplate类的配置可通过如下方式：

public RestTemplate restTemplate(){

return new RestTemplate()；

}

在程序启动后，所述服务消费者同样会注册到服务注册中心。

这里，所述eureka client的部署同eureka server的部署相同之处不再赘述。

在部署完eureka server以及eureka client后；在spring-boot项目的META-INF文件下创建spring.factories文件，并在所述spring.factories文件里进行如下配置：

EnableAutoConfiguretion＝SuyanAutoConfigurei；

BootstrapConfigureaion＝DiscoverySuyanConfig。

如此，就完成了对eureka组件的扩展项目。

这里，将扩展后的eureka组件打包成jar文件，发到中心仓库供其它组件使用。

在此，对本发明的部署方式做一个总结，如图3所示为扩展包引入的部署流程，在确定引入了扩展包后，通过所述扩展包部署服务发现组件(eureka)。以此类推，采用同样的方式部署其他组件。对于服务发现框架来讲，实现一个服务的注册与发现需要部署注册中心，部署服务发现组件的客户端的服务消费者、服务提供者等。

这里，所述方法还包括：

将第二文件包添加到第二组件中，得到更新后的第二组件；

所述更新后的第二组件用于监控服务的调用过程。

这里，在将jar扩展包添加到第二组件后，可以得到更新后的第二组件；所述第二组件包括：hystrix-turbine、zipkin以及zuul网关等组件。

依据更新后的第二组件，可以记录所述接口文件的调用过程，并对所述调用过程进行分析，得出分析结果，基于分析结果，对调用过程进行监控。

这里，所述hystrix-turbine用于记录Spring Cloud微服务框架的服务调用过程中的一些信息，比如：调用频率、错误率等；所述zipkin是一套开源的链路监控系统，在加入上述扩展jar之后，可以在Kubernetes平台里的eureka server上进行注册，从而让客户端应用eureka client发现使用。这里，利用所述组件可以对微服务平台的调用做监控，对完整的调用链做跟踪，排查问题更加方便。

本发明实施例提供的信息处理方法，通过在第一组件的第一文件包中加入用于获取地址信息的第一函数实现对第一文件包的扩展，再将扩展后的第一文件包对第一组件进行部署，由此可以实现在程序启动后，可以基于所述部署直接生成第一组件所在pod地址信息的接口文件。能够使得Kubernetes中的DNS直接解析出将微服务中的第一组件所在pod解析成对应的IP，进而可以基于所述IP进行服务的发现与注册，从而有效减少对端口的占用。

在所述eureka client侧，如图4所示，所述信息处理方法包括：

S201，调用接口文件；

S202，基于所述接口文件，将服务信息注册至所述至少一个第一组件的服务器端中，并返回服务信息注册列表；

S203，基于所述服务信息注册列表，访问服务信息。

这里，在程序启动后，部署的eureka client可以调用上述eureka server返回的封装后的接口文件来进行服务的注册。对应地，所述eureka server将所述注册信息进行记载。

这里，所述eureka client将自身的服务信息注册至所述至少一个第一组件的服务器端中的任意一个第一组件中，再返回服务信息注册列表。例如，所述eureka client作为服务提供者，将自身的服务信息注册至上述服务注册中心集群中的任意一个eurekaserver上，在注册之后，也同样可以获得所述注册中心上已经注册的服务信息，以及服务信息对应的地址信息。

需要说明的是，由于在上述第一配置类中加入了第一函数；所述第一函数可以获取所有eureka组件所在pod的IP地址。那么，在程序启动后使用更新后的第一配置类替换掉原始的启动类；由此生成的接口文件可以直接根据Kubernetes平台中的DNS解析出eureka所在pod的IP地址。

如此，所述eureka client调用的就是所述可以直接被Kubernetes的DNS解析出IP地址的接口。

在所述eureka client获取注册服务信息后，可以对所述注册的服务信息进行访问。其中，所述基于所述服务信息注册列表，访问服务信息，包括：

登陆第一组件的服务器端的站点页面；

基于所述服务信息中所述第一组件服务器端的地址信息访问对应的服务信息。

这里，所述第一组件的站点页面为eureka组件作为eureka server时的服务注册中心地址页面，例如，站点页面为http://localhost:6781/，所述6781是指服务器端的端口号。

登陆注册中心的站点页面后，可以在所述站点页面上，看到已经注册的服务信息。

发明实施例提供的信息处理方法，由于所述接口文件为可以直接被Kubernetes中的DNS解析出IP地址的接口，使得在调用所述接口文件后，可以直接获取eureka组件所在pod的IP地址，以此可以方便地基于IP地址进行交互，实现服务的注册与发现，达到减少宿主机的端口管理成本的目的。

基于前述实施例相同的技术构思，本发明实施例提供一种信息处理装置300，如图5所示，所述装置包括：扩展模块301、更新模块302以及接口生成模块303；其中，

所述扩展模块301，用于在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包；其中，所述第一文件包为至少一个第一组件中目标第一组件的客户端对应的文件包；

所述更新模块302，用于将第二文件包添加到至少一个第一组件中，得到更新后的第一组件；所述第一组件包括第一组件的客户端、第一组件的服务器端；

所述接口生成模块303，用于基于更新后的第一组件，生成所述至少一个第一组件服务器端对应的地址信息的接口文件；其中，所述接口文件为用于表征服务注册与服务契约租赁的接口。

这里，所述信息处理装置300中，所述扩展模块301，还用于在第一文件包中创建第一配置类；

所述信息处理装置300还包括：第一组件创建模块；所述第一组件创建模块，用于在容器管理平台中创建至少一个第一组件；基于所述至少一个第一组件，创建第一项目，并在第一项目的布局文件中引入所述第一文件包。

所述信息处理装置300还包括：第二组件创建模块；所述第二组件创建模块，用于将所述第二文件包添加到第二组件中，得到更新后的第二组件；所述更新后的第二组件用于监控服务的调用过程。

所述第二组件创建模块，还用于依据更新后的第二组件，记录所述接口文件的调用过程，并对所述调用过程进行分析，得出分析结果，基于分析结果，对调用过程进行监控。

需要说明的是，由于所述信息处理装置300解决问题的原理与前述应用于eurekaserver端的信息处理方法相似，因此，所述信息处理设备300的具体实施过程及实施原理均可以参见前述方法和实施过程，以及实施原理的描述，重复之处不再赘述。

本发明实施例提供的信息处理装置，通过在第一组件的第一文件包中加入用于获取地址信息的第一函数实现对第一文件包的扩展，再将扩展后的第一文件包对第一组件进行部署，由此可以实现在程序启动后，可以基于所述部署直接生成第一组件所在pod地址信息的接口文件。能够使得Kubernetes中的DNS直接解析出将微服务中的第一组件所在pod解析成对应的IP，进而可以基于所述IP进行服务的发现与注册，从而有效减少对端口的占用。

基于前述实施例相同的技术构思，本发明实施例还提供一种信息处理装置400，如图6所示，所述装置包括：调用模块401、注册模块402以及访问模块403；其中，

所述调用模块401，用于调用接口文件；

所述注册模块402，用于基于所述接口文件，将服务信息注册至所述至少一个第一组件的服务器端中，并返回服务信息注册列表；

所述访问模块403，用于基于所述服务信息注册列表，访问服务信息。

所述访问模块403，还用于登陆第一组件的服务器端的站点页面；在所述站点页面的服务信息注册列表中选择至少一条服务信息；基于所述服务信息中所述第一组件的服务器端的地址信息访问对应的服务信息。

需要说明的是，由于所述信息处理装置400解决问题的原理与前述应用于eurekaclient端的信息处理方法相似，因此，所述信息处理设备400的具体实施过程及实施原理均可以参见前述方法和实施过程，以及实施原理的描述，重复之处不再赘述。

本发明实施例还提供一种计算机存储介质，其上存储有计算机程序，其中，该计算机程序被处理器执行时实现上述实施例中所述方法的步骤。并且该计算机程序被处理器执行时实现执行上述实施例中所提供的方法的各个步骤，这里不再赘述。

本发明实施例还提供一种信息处理装置，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器用于运行所述计算机程序时，执行存储在存储器中的上述方法实施例的步骤。

图7是本发明实施例信息处理装置的一种硬件结构示意图，该信息处理装置500包括：至少一个处理器501、存储器502，信息处理装置500中的各个组件通过总线系统503耦合在一起，可理解，总线系统503用于实现这些组件之间的连接通信。总线系统503除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图7中将各种总线都标为总线系统503，所述存储器502包括操作系统5021以及应用程序5022。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种信息处理方法，其特征在于，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包，包括：

在第一文件包中创建第一配置类；

3.根据权利要求1所述的方法，其特征在于，所述在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包前，所述方法还包括：

在容器管理平台中创建至少一个第一组件；

4.根据权利要求1所述的方法，其特征在于，所述在第一文件包中添加用于获取地址信息的第一函数，得到第二文件包后，所述方法还包括：

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

6.一种信息处理方法，其特征在于，所述方法包括：

调用接口文件；

基于所述服务信息注册列表，访问服务信息。

7.根据权利要求6所述的方法，其特征在于，所述基于所述服务信息注册列表，访问服务信息，包括：

登陆第一组件的服务器端的站点页面；

8.一种信息处理装置，其特征在于，所述装置包括：扩展模块、更新模块以及接口生成模块；其中，

9.根据权利要求8所述的装置，其特征在于，

所述扩展模块，用于在第一文件包中创建第一配置类；在第一文件包中的所述第一配置类中加入第一函数，得到第二文件包；

10.根据权利要求8所述的装置，其特征在于，所述装置还包括：第一组件创建模块；

11.根据权利要求8所述的装置，其特征在于，所述装置还包括：第二组件创建模块；

12.根据权利要求11所述的装置，其特征在于，

所述第二组件创建模块，用于依据更新后的第二组件，记录所述接口文件的调用过程，并对所述调用过程进行分析，得出分析结果，基于分析结果，对调用过程进行监控。

13.一种信息处理装置，其特征在于，所述装置包括：调用模块、注册模块以及访问模块；其中，

所述调用模块，用于调用接口文件；

14.根据权利要求13所述的装置，其特征在于，

所述访问模块，用于登陆第一组件的服务器端的站点页面；在所述站点页面的服务信息注册列表中选择至少一条服务信息；

15.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7任一项所述方法的步骤。

16.一种信息处理装置，其特征在于，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器用于运行所述计算机程序时，执行权利要求1至7任一项所述方法的步骤。