CN116820806A - 微服务请求的处理方法、装置、电子设备及可读存储介质 - Google Patents

微服务请求的处理方法、装置、电子设备及可读存储介质 Download PDF

Info

Publication number
CN116820806A
CN116820806A CN202310813942.0A CN202310813942A CN116820806A CN 116820806 A CN116820806 A CN 116820806A CN 202310813942 A CN202310813942 A CN 202310813942A CN 116820806 A CN116820806 A CN 116820806A
Authority
CN
China
Prior art keywords
micro
middleware
service request
sdk
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310813942.0A
Other languages
English (en)
Inventor
李斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kangjian Information Technology Shenzhen Co Ltd
Original Assignee
Kangjian Information Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kangjian Information Technology Shenzhen Co Ltd filed Critical Kangjian Information Technology Shenzhen Co Ltd
Priority to CN202310813942.0A priority Critical patent/CN116820806A/zh
Publication of CN116820806A publication Critical patent/CN116820806A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Physics & Mathematics (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Pathology (AREA)
  • Stored Programmes (AREA)

Abstract

本申请涉及计算机技术领域以及数字医疗领域，具体涉及一种微服务请求的处理方法、装置、电子设备及可读存储介质，其方法包括：在微服务应用启动时，采用Java instrumentation，建立agent插件与中间件API的映射关系以加载所述agent插件，构建微服务应用的多运行时态架构；执行业务逻辑组件，通过中间件API调用agent插件中的中间件SDK，对微服务请求进行处理。本申请实现了将业务逻辑和依赖技术解耦合、将技术API以及技术具体实现解耦合；极大地降低了多运行时态架构微服务应用的部署难度，为医院的线上问诊系统提供强有力的技术支持，满足线上医疗问诊系统数据多、功能多的分布式部署需求。

Description

微服务请求的处理方法、装置、电子设备及可读存储介质
技术领域
本申请涉及计算机技术领域以及数字医疗领域，具体涉及一种微服务请求的处理方法、装置、电子设备及可读存储介质。
背景技术
最近几年，多运行时态微服务架构(Multi-Runtime MicroserviceArchitecture)得到广泛研究，多运行时态微服务架构是为了解决业务逻辑和分布式系统问题之间的松耦合，软件系统的这两部分具有完全不同的动态特征，可以分别演进。
随着线上医疗的的发展以及患者需求的多样化，很多医院都开展了线上问诊业务，且业务系统涉及的功能越来越广泛。线上问诊系统集成了线上诊疗、数据查询、患者数据管理、医疗器械数据管理、药品数据管理等多种功能，为了实现业务逻辑和分布式系统问题之间的松耦合，很多医院的引入了多运行时态微服务架构的服务架构。
虽然多运行时态微服务架构优点很多，但目前业界提出的MicroService Multi-Runtime方案都是基于service mesh之上，例如istio、linkerd2等，这类service mesh方案又依赖kubernetes，且需要运行在较高版本的kubernetes上，对于一个非service mesh架构的系统而言，实施的成本和带来的影响及风险都极高，这给医院的线上诊疗服务系统造成了成本高、风险大的问题。
发明内容
本申请实施例针对上述情况，提出了一种微服务请求的处理方法、装置、电子设备及可读存储介质，以克服或者至少部分克服现有技术的不足之处。
第一方面，本申请实施例提供了一种微服务请求的处理方法，所述方法通过微服务应用实现，所述微服务应用包括：业务逻辑组件、至少一个中间件API、至少一个agent插件，其中所述agent插件中集成有中间件SDK；
所述方法包括：
在所述微服务应用启动时，采用Java instrumentation，建立所述agent插件与所述中间件API的映射关系以加载所述agent插件，构建所述微服务应用的多运行时态架构；
执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理。
第二方面，本申请实施例还提供了一种微服务请求的处理装置，所述装置包括：
部署单元，用于在所述微服务应用启动时，采用Java instrumentation，建立所述agent插件与所述中间件API的映射关系以加载所述agent插件，构建所述微服务应用的多运行时态架构；
执行单元，用于执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理。
第三方面，本申请实施例还提供了一种电子设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行上述的微服务请求的处理方法。
第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行上述的微服务请求的处理方法。
本申请实施例采用的方法至少能够达到以下有益效果：
本申请将可以业务逻辑需要的各种功能以中间件SDK的集成于agent插件中，在微服务应用启动时，采用Java instrumentation，通过建立agent插件与中间件API的映射关系的方式，将agent插件挂载在微服务应用上；当一个请求到达微服务应用后，当业务逻辑在被执行时，可以通过中间件API调用与其具有映射关系的agent插件中的中间件SDK，来对微服务请求进行处理。在业务研发工程中，除了包含业务逻辑的业务代码就是所依赖的技术的API，本申请中将技术的具体实现在业务应用程序启动时，通过java instrumentation以agent方式挂载在业务应用程序中。本申请实现了将业务逻辑和依赖技术解耦合、将技术API以及技术具体实现解耦合；极大地降低了多运行时态架构微服务应用的部署难度、降低了应用实施难度、实用性强、且使用范围广泛，可为医院的线上问诊系统提供强有力的技术支持，将各种功能下沉到中间件SDK中，实现业务逻辑和功能具体实现的解耦合，满足线上医疗问诊系统数据多、功能多的分布式部署问题。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1示出了根据本申请的一个实施例的微服务请求的处理方法的流程示意图；
图2示出了根据本申请的一个实施例的微服务应用的逻辑结构示意图；
图3示出了根据本申请的另一个实施例的微服务应用的逻辑结构示意图；
图4示出了根据本申请的另一个实施例的微服务请求的流程示意图；
图5示出了根据本申请的一个实施例的微服务请求的处理装置的结构示意图；
图6为本申请实施例中一种电子设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
以下结合附图，详细说明本申请各实施例提供的技术方案。
业界在2020年有提出过Multi-Runtime Microservice Architecture，即多运行时态微服务架构，将当今分布式应程序的需求分为4个类别，并进行了抽象定义：生命周期、网络、状态、绑定。其核心概念是每个微服务都有一个以上的运行时组件：Micrologic和Mecha。其中Micrologic表示业务运行时上下文，代表微服务中的业务逻辑；Mecha表示技术运行时上下文，包含依赖的各种中间件和底层技术能力，例如MQ、RPC、限流等。多运行时态微服务架构的目的是为了解决业务逻辑和分布式系统问题之间的松耦合，软件系统的这两部分具有完全不同的动态特征，可以分别演进。
随着线上医疗的的发展以及患者需求的多样化，很多医院都开展了线上问诊业务，且业务系统涉及的功能越来越广泛。线上问诊系统集成了线上诊疗、数据查询、患者数据管理、医疗器械数据管理、药品数据管理等多种功能，为了实现业务逻辑和分布式系统问题之间的松耦合，很多医院的服务引入了多运行时态微服务架构的服务架构。
虽然Mutlti-Runtime Microservice Architecture优点很多，但目前业界提出的MicroService Multi-Runtime方案都是基于service mesh之上，例如istio,linkerd2等，这类service mesh方案又依赖kubernetes，且需要运行在较高版本的kubernetes上；而对于一个非service mesh架构的系统而言，实施的成本和带来的影响及风险都极高，这对于使用Mutlti-Runtime Microservice Architecture的微服务系统造成了成本高、风险大的问题，限制了基于微服务架构的线上医疗系统的迭代和推广。
对此本申请提出了一种微服务请求的处理方法，图1示出了根据本申请的一个实施例的微服务请求的处理方法的流程示意图，从图1可以看出，本申请至少步骤S110～步骤是120：
步骤S110：在所述微服务应用启动时，采用Java instrumentation，建立所述agent插件与所述中间件API的映射关系以加载所述agent插件，构建所述微服务应用的多运行时态架构。
本申请的微服务请求的处理方法可适用于各种基于微服务架构构建的业务系统，如网上商城、保险系统等，尤其适用于数据多、功能需求多的线上医疗系统。
在本申请中，微服务请求是通过微服务应用进行处理的，本申请提供的微服务应用包括：业务逻辑组件、至少一个中间件API、至少一个agent插件，其中所述agent插件中集成有中间件SDK。
其中，中间件ADK可以理解为可实现各种功能的工具包，如在本申请的一些实施例中，所述中间件SDK可以数据库功能SDK、RPC功能SDK、以及限流功能SDK中的至少一项，一一对应的可实现数据库功能、RPC功能、以及限流功能。
本申请的主要构思在于：将业务逻辑和依赖技术解耦合，将技术的API或技术的具体实现解耦合，为了达到这样的目的，本申请通过java instrumentation以agent方式嵌入业务应用程序中。
现有技术中，整个微服务应用从运行时上下文维度，分为Micorlogic和Mecha，Mecha根据所依赖的技术，可以有多个Mecha运行时上下文。在本申请中，从另一维度将微服务应用分为应用态和部署态，请参考图2，图2示出了根据本申请的一个实施例的微服务应用的逻辑结构示意图，从图2可以看出，微服务应用的应用态包含业务逻辑、所依赖的技术实现，技术实现包括中间件API和中间件SDK，其中，中间件SDK被集成于agent插件中；而部署态主要是指技术的实现(包含中间件SDK的agent插件)通过instrumentation技术嵌入业务应用程序这一过程。
Java Instrumentation是Java语言中的一种高级特性，它允许开发人员在程序运行时动态地修改、监控和控制Java应用程序的行为。
Java Instrumentation通过在JVM启动时提供一个代理程序(Agent)，来实现对Java应用程序的监控和修改。这个代理程序可以通过Java的Instrumentation API来访问和操作Java应用程序的字节码，从而实现对应用程序的动态修改。
使用Java Instrumentation，开发人员可以在程序运行时通过修改字节码来实现一些高级功能，例如代码注入、性能监控和分析、代码覆盖率测试等。通过在程序的关键位置插入自定义的代码，开发人员可以实现对程序的行为进行监控和控制，从而更好地理解和优化程序的性能和行为。
Java Instrumentation是一种强大而灵活的特性，它允许开发人员在程序运行时对Java应用程序进行动态修改和监控，从而实现一些高级功能和优化。
在本申请中，通过Java Instrumentation可以建立agent插件与中间件API之间的映射关系，这样在微服务应用启动完毕后，agent插件就挂载或者嵌入了微服务应用程序中了，由于本申请形成的微服务应用中业务逻辑和技术具体实现可分别演进，因此此时形成的微服务应用的架构属于一种多运行时态架构。
对于微服务应用需要加载哪些agent插件，是可以进行管理和控制的，通常通过虚拟机JVM的参数进行控制即可。
步骤是120：执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理。
当微服务应用接收到微服务请求后，则执行业务逻辑组件，通过中间件API调用agent插件中的中间件SDK，对微服务请求进行处理。
具体的，根据所述微服务请求的任一节点，确定对应的目标中间件API；；读取与所述目标中间件API具有映射关系的目标agent插件；解析所述目标agent插件，调用其中的中间件SDK，对所述微服务请求进行处理。
中间件API通常有多个，以对微服务请求中的一个节点进行处理为例，根据微服务请求中该节点的请求内容确定对应的目标中间件API，然后根据agent插件与中间件API的映射关系，确定目标中间件API对应的agent插件作为目标agent插件，然后通过目标中间件API调用该目标agent插件，使用其中中间件SDK的功能对微服务请求的该节点进行处理。
由图1所示的方法可以看出，本申请将可以业务逻辑需要的各种功能以中间件SDK的集成于agent插件中，在微服务应用启动时，采用Java instrumentation，通过建立agent插件与中间件API的映射关系的方式，将agent插件挂载在微服务应用上；当一个请求到达微服务应用后，当业务逻辑在被执行时，可以通过中间件API调用与其具有映射关系的agent插件中的中间件SDK，来对微服务请求进行处理。在业务研发工程中，除了包含业务逻辑的业务代码就是所依赖的技术的API，本申请中将技术的具体实现在业务应用程序启动时，通过java instrumentation以agent方式挂载在业务应用程序中。本申请实现了将业务逻辑和依赖技术解耦合、将技术API以及技术具体实现解耦合；极大地降低了多运行时态架构微服务应用的部署难度、降低了应用实施难度、实用性强、且使用范围广泛，可为医院的线上问诊系统提供强有力的技术支持，将各种功能下沉到中间件SDK中，实现业务逻辑和功能具体实现的解耦合，满足线上医疗问诊系统数据多、功能多的分布式部署问题。
在本申请的一些实施例中，考虑到依赖的一些技术可能是非必须的，且时候可能因为通信等原因，一些agent插件没有被加载成功，对此本申请基于Java SPI技术提供了一种兜底方案，即使在应用启动或运行时，没有加载或者嵌入相关的实现SDK也可实现，具体的，在在所述执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理的步骤之前，所述方法还包括：确定处理所述微服务请求所需的agent插件是否被加载成功，若加载成功，则进入所述执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理的步骤。
也就是说，在前述的步骤S120执行之前，前置“确定处理所述微服务请求所需的agent插件进是否被加载成功”这一步骤，若加载成功，至正常进入所述执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理的步骤。
若确定处理所述微服务请求所需的agent插件没有被加载成功，本申请还提供了Factory SPI这一通道实现相关具体实现的调用，以进行兜底。
具体的，在本申请的一些实施例中，所述微服务应用还包括：Factory SPI；若所述agent插件没有被加载或者加载失败，所述方法还包括：在执行所述业务逻辑组件的过程中，确定所述微服务应用中是否已经加载处理所述微服务请求所需的Mecha组件；若所述微服务应用中已经加载处理所述微服务请求所需的Mecha组件，则通过SDK Factory SPI调用所述Mecha组件中的功能SDK，并返回所述功能SDK的API实现；若所述微服务应用中未加载处理所述微服务请求所需的Mecha组件，则调用空SPI Factory，生产并返回空实现。
需要说明的是，虽然本申请的整体构思是将Mecha组件中的功能SDK作为中间件SDK通过agent插件嵌入应用程序中，但是对于一些原始就被嵌套入业务逻辑中的底层功能Mecha组件，尤其是二次开发的情况，对于一些没有挂载的中间件SDK提供的功能，可以采用本申请提供Factory SPI的方式布局兜底。
图3示出了根据本申请的一个实施例的基于微服务应用的线上问诊系统的逻辑结构示意图，线上问诊系统中是基于微服务应用形成的，从图3可以看出，在处理微服务请求所需的agent插件没有被加载成功的情况下，在执行业务逻辑(Bizcode)过程中，可以调用Factory SPI，首先确定微服务应用中是否已经加载处理微服务请求所需的Mecha组件，若已经加载，则执行嵌入的Mecha的SDK的具体实现，具体的，通过SDK Factory SPI调用所述Mecha组件中的功能SDK，并返回所述功能SDK的API实现；若微服务应用中没有加载处理微服务请求所需的Mecha组件，则执行提前设置的默认的空实现，具体的，调用空SPIFactory，生产并返回空实现。空实现并不耽误微服务请求的正常处理，可直接跳过该处理节点，继续处理，直到整个微服务请求被处理完毕，并返回结果。可以看出，采用本申请的Factory SPI的方式，如此不管是否有嵌入对应的技术具体实现SDK或者Mecha，对应用运行都没有影响。
图4示出了根据本申请的另一个实施例的微服务请求的流程示意图，从图4可以看出本实施例包括：
在微服务应用启动时，采用Java instrumentation，建立agent插件与中间件API的映射关系以加载agent插件，构建微服务应用的多运行时态架构。
接收微服务请求。
确定处理微服务请求所需的agent插件是否被加载成功，若是，则执行业务逻辑组件，通过中间件API调用agent插件中的中间件SDK，对微服务请求进行处理。
若处理微服务请求所需的agent插件没有被加载成功，则确定微服务应用中是否已经嵌入处理微服务请求所需的Mecha组件，若是，则通过SDK Factory SPI调用所述Mecha组件中的功能SDK，并返回所述功能SDK的API实现。
若微服务应用中未嵌入处理微服务请求所需的Mecha组件，则调用空SPIFactory，生产并返回空实现。
图5示出了根据本申请的一个实施例的微服务请求的处理装置的结构示意图，从图5可以看出，微服务请求的处理装置500包括：
部署单元510，用于在所述微服务应用启动时，采用Java instrumentation，建立所述agent插件与所述中间件API的映射关系以加载所述agent插件，构建所述微服务应用的多运行时态架构；
执行单元520，用于执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理。
在本申请的一些实施例中，在上述装置中，所述中间件SDK包括：数据库功能SDK、RPC功能SDK、以及限流功能SDK中的至少一项。
在本申请的一些实施例中，在上述装置中，执行单元520，用于根据所述微服务请求的任一节点，确定对应的目标中间件API；读取与所述目标中间件API具有映射关系的目标agent插件；解析所述目标agent插件，调用其中的中间件SDK，对所述微服务请求进行处理。
在本申请的一些实施例中，在上述装置中，执行单元520，还用于在所述执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理的步骤之前，确定处理所述微服务请求所需的agent插件是否被加载成功，若加载成功，则进入所述执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理的步骤。
在本申请的一些实施例中，在上述装置中，所述微服务应用还包括：Factory SPI；执行单元520，还用于若所述agent插件没有被加载或者加载失败，在执行所述业务逻辑组件的过程中，确定所述微服务应用中是否已经嵌入处理所述微服务请求所需的Mecha组件；若所述微服务应用中已经嵌入处理所述微服务请求所需的Mecha组件，则通过SDK FactorySPI调用所述Mecha组件中的功能SDK，并返回所述功能SDK的API实现。
在本申请的一些实施例中，在上述装置中，执行单元520，还用于若所述微服务应用中未嵌入处理所述微服务请求所需的Mecha组件，则调用空SPI Factory，生产并返回空实现。
在本申请的一些实施例中，在上述装置中，所述微服务应用是基于Spring架构或者Dubbo架构。
需要说明的是，上述的微服务请求的处理装置可一一实现前述的微服务请求的处理方法，这里不再一一赘述。
图6是本申请的一个实施例电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成微服务请求的处理装置500。处理器，执行存储器所存放的程序，并具体用于执行前述方法。
上述如本申请图5所示实施例揭示的微服务请求的处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件格式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central ProcessingUnit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的配置信息，结合其硬件完成上述方法的步骤。
该电子设备还可执行图5中微服务请求的处理装置执行的方法，并实现微服务请求的处理装置在图5所示实施例的功能，本申请实施例在此不再赘述。
本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图5所示实施例中微服务请求的处理装置执行的方法，并具体用于执行前述方法。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的格式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的格式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等格式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现配置信息存储。配置信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的配置信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的同一要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的格式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的格式。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种微服务请求的处理方法，其特征在于，所述方法通过微服务应用实现，所述微服务应用包括：业务逻辑组件、至少一个中间件API、至少一个agent插件，其中所述agent插件中集成有中间件SDK；
所述方法包括：
在所述微服务应用启动时，采用Java instrumentation，建立所述agent插件与所述中间件API的映射关系以加载所述agent插件，构建所述微服务应用的多运行时态架构；
执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理。
2.根据权利要求1所述的方法，其特征在于，所述中间件SDK包括：数据库功能SDK、RPC功能SDK、以及限流功能SDK中的至少一项。
3.根据权利要求1所述的方法，其特征在于，所述执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理，包括：
根据所述微服务请求的任一节点，确定对应的目标中间件API；
读取与所述目标中间件API具有映射关系的目标agent插件；
解析所述目标agent插件，调用其中的中间件SDK，对所述微服务请求进行处理。
4.根据权利要求1所述的方法，其特征在于，在所述执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理的步骤之前，所述方法还包括：
确定处理所述微服务请求所需的agent插件是否被加载成功，若加载成功，则进入所述执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理的步骤。
5.根据权利要求4所述的方法，其特征在于，所述微服务应用还包括：Factory SPI；若所述agent插件没有被加载或者加载失败，所述方法还包括：
在执行所述业务逻辑组件的过程中，确定所述微服务应用中是否已经嵌入处理所述微服务请求所需的Mecha组件；
若所述微服务应用中已经嵌入处理所述微服务请求所需的Mecha组件，则通过SDKFactory SPI调用所述Mecha组件中的功能SDK，并返回所述功能SDK的API实现。
6.根据权利要求5所述的方法，其特征在于，所述方法还包括：
若所述微服务应用中未嵌入处理所述微服务请求所需的Mecha组件，则调用空SPIFactory，生产并返回空实现。
7.根据权利要求1～6任一项所述的方法，其特征在于，所述微服务应用是基于Spring架构或者Dubbo架构。
8.一种微服务请求的处理装置，其特征在于，所述装置包括：
部署单元，用于在所述微服务应用启动时，采用Java instrumentation，建立所述agent插件与所述中间件API的映射关系以加载所述agent插件，构建所述微服务应用的多运行时态架构；
执行单元，用于执行所述业务逻辑组件，通过所述中间件API调用所述agent插件中的中间件SDK，对所述微服务请求进行处理。
9.一种电子设备，包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行所述权利要求1～7中任一项所述的微服务请求的处理方法。
10.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行所述权利要求1～7中任一项所述的微服务请求的处理方法。
CN202310813942.0A 2023-07-04 2023-07-04 微服务请求的处理方法、装置、电子设备及可读存储介质 Pending CN116820806A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310813942.0A CN116820806A (zh) 2023-07-04 2023-07-04 微服务请求的处理方法、装置、电子设备及可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310813942.0A CN116820806A (zh) 2023-07-04 2023-07-04 微服务请求的处理方法、装置、电子设备及可读存储介质

Publications (1)

Publication Number Publication Date
CN116820806A true CN116820806A (zh) 2023-09-29

Family

ID=88116478

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310813942.0A Pending CN116820806A (zh) 2023-07-04 2023-07-04 微服务请求的处理方法、装置、电子设备及可读存储介质

Country Status (1)

Country Link
CN (1) CN116820806A (zh)

Similar Documents

Publication Publication Date Title
US20190324772A1 (en) Method and device for processing smart contracts
US8954929B2 (en) Automatically redirecting method calls for unit testing
US8141070B2 (en) Bridging class loader name spaces
US20140282452A1 (en) System and method for reducing the static footprint of mixed-language java™ classes
CN112698888B (zh) 应用程序的组件化、组件调用和组件初始化方法及其装置
CN110908738A (zh) 用于运行小程序的方法和装置
EP1739550A2 (en) Method and apparatus for allowing non-generified methods to override generified methods
US7900213B2 (en) Generic markup specified object descriptor for a modularized computing application
CN111198677B (zh) 一种设备对象生成方法、装置及设备
CN111045746A (zh) 代码扩展方法和框架
CN116820806A (zh) 微服务请求的处理方法、装置、电子设备及可读存储介质
CN113342660B (zh) 文件测试方法、装置、系统、电子设备及可读存储介质
CN110275710B (zh) 一种Java本地接口一致性检查方法及系统、存储介质及终端
CN113434213B (zh) 一种终端的程序运行方法以及装置
CN113986744A (zh) 一种分库分表组件的测试方法、装置及存储介质
CN113448588B (zh) 数据安全处理方法、装置、电子设备和存储介质
CN114443316B (zh) 一种对象访问方法、装置及电子设备
CN114638004B (zh) 一种数据保护方法、装置及存储介质
CN114237614B (zh) 应用程序的处理方法、装置、电子设备和存储介质
CN111736841B (zh) 一种基于移动互联网的应用集成开发方法及系统
CN116841890A (zh) 一种用于前端项目调试的方法及系统
CN116204223A (zh) 一种用于应用请求接口的字段校验框架和接口校验方法
CN114237770A (zh) 一种微服务链路调用方法、系统、设备及介质
CN116795677A (zh) 一种测试方法、终端设备及存储介质
CN115712504A (zh) 一种数据获取方法、装置、电子设备及可读存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination