A WASM-based gateway plugin system

Abstract

This invention relates to the field of digital information transmission technology and discloses a gateway plugin system based on WASM. The system includes: a plugin management module, which creates an independent WASM gateway plugin instance for each WASM gateway plugin in a pre-loaded plugin list obtained according to routing configuration within a sandbox execution environment; a host proxy module, used to establish a controlled communication channel between the sandbox execution environment and the gateway host environment; a route matching module, used to match the target WASM gateway plugin from the routing configuration based on received client requests and a preset hierarchical priority matching algorithm; and an extensible request module, used to dynamically load and execute the target WASM gateway plugin using the WASM gateway plugin instance in a plugin execution pipeline, obtaining the plugin processing result. The system provided in this application improves the security of gateway business logic extension, as well as fine-grained resource management, host capability exposure control, and multi-plugin collaborative processing capabilities.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, and in particular to a gateway plug-in system based on WASM. Background Technology

[0002] In modern microservice architectures, API gateways serve as a unified entry point, undertaking core functions such as routing, authentication, traffic control, and protocol conversion. As business scenarios diversify, gateways need to support flexible business logic expansion capabilities.

[0003] Traditional gateways typically extend their functionality through built-in modules or by loading native shared libraries, but this approach suffers from several drawbacks: Poor security isolation: Traditional plugins share memory with the main process, making them vulnerable to malicious or defective plugins that can cause gateway crashes, memory leaks, unauthorized access to system resources, and prevent the secure execution of third-party code. Inefficient resource management: Plugins are often statically loaded at startup or dynamically initialized upon request, leading to high memory usage or significant performance overhead from repeated initialization. The lack of concurrent instance control can easily result in resource exhaustion. Inadequate host capability control: Plugins need to interact with the host, and existing solutions often expose system calls in an all-or-nothing manner, lacking fine-grained access control and operation auditing, posing risks of data leakage and resource abuse. Rigid orchestration and scheduling: When multiple plugins collaborate, statically configured plugin chains are often used, making it difficult to dynamically orchestrate the execution pipeline based on request content and routing strategies, resulting in inflexible changes.

[0004] Therefore, improving the security of gateway business logic extension, as well as the fine-grained management of resources, host capability exposure control, and multi-plugin collaborative processing capabilities have become technical problems that urgently need to be solved by those skilled in the art. Summary of the Invention

[0005] This invention provides a gateway plugin system based on WASM to address the technical issues of improving the security of gateway business logic extension, as well as fine-grained resource management, host capability exposure control, and multi-plugin collaborative processing capabilities.

[0006] In a first aspect, the present invention provides a gateway plugin system based on WASM, the system comprising: a plugin management module, configured to obtain routing configuration from a service registry manager, and create a preloaded plugin list according to the WASM gateway plugin corresponding to the routing configuration, create an independent WASM gateway plugin instance for each WASM gateway plugin in the preloaded plugin list in a sandbox execution environment, and manage the WASM gateway plugin instance using an object pool mode;

[0007] The host proxy module is used to define a set of host capability interfaces related to the gateway service, so as to establish a controlled communication channel between the sandbox execution environment and the gateway host environment. Each host capability interface in the set of host capability interfaces has a built-in static declaration layer, dynamic policy layer and audit tracing layer to implement mandatory access control and full-link audit for each call to the host capability interface.

[0008] The route matching module is used to receive client requests and, based on the client requests and a preset hierarchical priority matching algorithm, match the target route and one or more associated target WASM gateway plugins from the route configuration.

[0009] An extensible request module is used to dynamically load and execute the target WASM gateway plugin using the WASM gateway plugin instance through the controlled communication channel, according to a predefined plugin execution pipeline, to obtain the plugin processing result of the client request.

[0010] Preferably, the host capability interface set includes the following core domains: HTTP traffic manipulation interface domain, gateway runtime context interface domain, external service communication interface domain, authentication, authorization and security interface domain, state management and data access interface domain, observability and operation and maintenance interface domain, traffic governance and control interface domain, and tool and helper function interface domain.

[0011] Preferably, the hierarchical priority matching algorithm includes: tenant isolation matching with first priority, request path accuracy matching with second priority, host header condition matching with third priority, and HTTP method whitelist matching with fourth priority.

[0012] Preferably, the plug-in management module is configured as follows:

[0013] Create a plugin configuration list for each of the WASM gateway plugins in the preloaded plugin list. The plugin configuration list is used to set the resource limits of the WASM gateway plugin in the sandbox execution environment. The resource limits include: memory safety boundary, computing resource limit, capability access control and network access policy.

[0014] Based on the plugin configuration list, an independent WASM gateway plugin instance is created for each of the WASM gateway plugins in the sandbox execution environment;

[0015] Based on the WASM gateway plugin instance, a reusable plugin instance pool is constructed, and the initial pool size is set. Based on the initial pool size, the plugin instance pool is managed using an object pool pattern.

[0016] Preferably, the extensible request module is configured as follows:

[0017] Based on the configured number of concurrent execution licenses for plugins, obtain a target WASM gateway plugin instance from the plugin instance pool for the target WASM gateway plugin;

[0018] The plugin execution context parameters are serialized into input data with a size limit, and the input data is passed into the sandbox execution environment through the host capability interface set;

[0019] Within the sandbox execution environment, the phase support query function corresponding to the target WASM gateway plugin instance is called. If the output result of the phase support query function is "supported", the target WASM gateway plugin instance is used to dynamically load and execute the target WASM gateway plugin. The phase support query function is used to determine the request processing phase supported by the target WASM gateway plugin instance.

[0020] Through the host capability interface set, the output data generated by the target WASM gateway plugin instance in the sandbox execution environment is transmitted back to the gateway side, and the core processor on the gateway side parses and executes the plugin processing result carried by the output data.

[0021] Preferably, the system further includes:

[0022] The isolation control module is used to hard limit the number of concurrent execution licenses of the plugin through a global semaphore mechanism, and to monitor the resource consumption of each WASM gateway plugin instance, so that the failure of a single WASM gateway plugin instance does not affect the execution of other WASM gateway plugin instances.

[0023] Preferably, the isolation control module includes:

[0024] A global concurrency controller is used to construct a global hierarchical semaphore system. Based on the global hierarchical semaphore system, a semaphore permission request is made before each target WASM gateway plugin is executed. If the request is successful, the target WASM gateway plugin continues to be executed. If the request fails, it enters a waiting queue. The global hierarchical semaphore system includes a global total permission semaphore, a plugin-level concurrent semaphore, and a tenant-level quota semaphore.

[0025] The sandbox resource monitor is used to perform memory resource monitoring, CPU resource monitoring, and network resource monitoring on each of the WASM gateway plugin instances, and to handle the detected faults according to the preset fault isolation and self-healing mechanism.

[0026] Preferably, the system also includes:

[0027] The error handling module is triggered at any stage of the execution of the target WASM gateway plugin by the extensible request module. It is used to call the error handling interface of the currently associated plugin through the controlled communication channel to process the error information in the sandbox execution environment and generate a standardized error response.

[0028] Preferably, the system further includes:

[0029] A blockchain network is used to store and maintain a trusted metadata record for the WASM gateway plugin, the trusted metadata record containing the WASM gateway plugin's unique content identifier, developer digital signature, version number, and security audit status hash value.

[0030] Preferably, the blockchain network is deployed with smart contracts, which include:

[0031] The plugin registration contract receives registration requests from developers for WASM gateway plugins to be registered, and performs permission and version verification on the WASM gateway plugins to be registered according to the registration requests, and registers basic information for the WASM gateway plugins to be registered that pass the verification.

[0032] The reputation evaluation contract, in response to the runtime status data of the WASM gateway plugins, performs a reputation score on each of the WASM gateway plugins and generates a plugin reputation score;

[0033] The access control contract receives the plugin usage license request initiated by the plugin management module, and verifies the WASM gateway plugin to be verified according to the plugin usage license request, and generates the plugin verification result.

[0034] This invention provides a WASM-based gateway plug-in system. Compared with existing technologies, the embodiments of this invention have the following advantages:

[0035] The WASM-based gateway plugin system provided in this application reduces the processing time for each request from creation and execution time to almost only execution time by reusing pre-initialized WASM gateway plugin instances. It adopts a three-pronged design philosophy of preloading, pooling, and isolation, completely changing the inefficient "on-demand loading, use-and-discard" model of traditional plugin systems. By setting a set of business-level host capability interfaces, the plugin capability boundary is narrowed from the operating system to the gateway's business semantics, achieving a fundamental improvement in security performance compared to the traditional approach of granting system-level security to extension modules. Through a pre-defined hierarchical priority matching algorithm, sub-millisecond-level efficient route matching is achieved, significantly improving route matching performance and effectively solving the routing performance bottleneck problem of gateway systems in high-concurrency scenarios. The isolation control module fundamentally solves the systemic risk problem caused by the failure of a single plugin in traditional gateway plugin systems, ensuring that the gateway maintains stability and reliability while providing high scalability. A decentralized, automated, and verifiable WASM gateway plugin management system is constructed, permanently anchoring the unique content identifier and developer digital signature of the WASM gateway plugin to the blockchain, preventing supply chain attacks and promoting transparency in security practices. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the structure of a WASM-based gateway plug-in system provided in a preferred embodiment of the present invention;

[0037] Figure Labels

[0038] 1- Plugin Management Module, 2- Host Proxy Module, 3- Route Matching Module, 4- Extensible Request Module. Detailed Implementation

[0039] The embodiments of the present invention are described in detail below with reference to the accompanying drawings. The embodiments are provided for illustrative purposes only and should not be construed as limiting the scope of the invention. The accompanying drawings are for reference and illustration only and do not constitute a limitation on the scope of protection of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of this invention.

[0040] In the description of this invention, it should be noted that, unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this specification is for the purpose of describing specific embodiments only and is not intended to limit the invention. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0041] Please see Figure 1The diagram shown illustrates a WASM-based gateway plugin system. In an embodiment of the present invention, a WASM-based gateway plugin system is provided, the system comprising:

[0042] The plugin management module retrieves route configurations from the service registry manager and creates a preloaded plugin list based on the corresponding WASM gateway plugins. In the sandbox execution environment, it creates an independent WASM gateway plugin instance for each WASM gateway plugin in the preloaded plugin list and manages these instances using an object pool model. In existing technologies, gateway plugin systems typically use an on-demand loading model, loading the corresponding WASM gateway plugin only when a client request matches a specific route. While this model saves initial memory usage, it leads to significant initial request latency and, in high-concurrency scenarios, may cause resource contention and performance fluctuations due to the simultaneous initialization of multiple WASM gateway plugins. In a preferred embodiment of this application, the WASM-based gateway plugin system uses the plugin management module to call the service registry manager to obtain route configurations. The plugin management module transforms the WASM gateway plugins from static bytecode into efficient, reusable runtime execution units. The plugin management module establishes a bidirectional communication connection with the service registry manager. The service registry manager can be a centralized configuration center, such as Consul (a service mesh solution), Etcd (a distributed key-value store), or Nacos (a dynamic service discovery and configuration management platform), or it can be a distributed configuration service. The connection between the plugin management module and the service registry manager supports automatic retries, failover, and configuration version subscription mechanisms, ensuring that the plugin management module can detect changes in route configurations in real time. The plugin management module retrieves complete route configuration documents from the service registry manager. These documents use a declarative configuration language and include: all registered route rules and matching conditions; the WASM gateway plugins associated with each route configuration; and metadata for each WASM gateway plugin, such as the plugin's name and version storage location.

[0043] Furthermore, all unique plugin identifiers are extracted from the routing configuration document to form a preloaded plugin list, which includes all WASM gateway plugins associated with the routing configuration. Based on the preloaded plugin list, an independent WASM gateway plugin instance is created for each WASM gateway plugin in the sandbox execution environment. The following operations are performed in the sandbox execution environment: the bytecode of the WASM gateway plugins in the preloaded plugin list is loaded from a local file or a remote URL (Uniform Resource Locator, i.e., a web address); and an Extism plugin configuration manifest (a configuration file defining plugin behavior, dependencies, and resources in the Extism framework) is created for each WASM gateway plugin. The Extism plugin configuration manifest is a JSON-formatted configuration file used to define the resource limitations of the WASM gateway plugin during Extism runtime, such as memory safety boundaries, computational resource limits, capability access control, and network access policies. The Extism plugin configuration manifest is a deployment description of the WASM plugin that conforms to runtime security policies; it defines both the plugin's initialization parameters and enforces its runtime resource and permission boundaries. The Extism plugin configuration manifest is defined using a declarative configuration language. This includes: memory safety boundaries (maximum linear memory, maximum function table size, and global variable limits); computational resource limits (maximum execution time, maximum instruction count, and enabling fuel-based billing); capability access control (a list of allowed host functions and explicitly prohibited functions, as host functions are the plugin's sole communication channel with the outside world, such as Redis access functions); and network access policies (allowed external hosts and maximum concurrent connections).

[0044] Furthermore, an object pool pattern is adopted to manage the lifecycle of created WASM gateway plugin instances. WASM gateway plugin instances are characterized by high creation costs and large memory consumption. Creating a WASM plugin instance is not a simple memory allocation but a complex process. It requires loading the WASM gateway plugin's binary file from the storage system, verifying the integrity and security of the binary file, allocating independent linear memory space, configuring a secure sandbox environment, and initializing the plugin's running state. This entire process takes 100-500 milliseconds, which is unacceptable for gateway systems requiring fast response times. Additionally, each WASM gateway plugin instance requires independent memory space to ensure security isolation, typically consuming 10-100MB of memory per instance. Uncontrolled, arbitrary creation would quickly exhaust server memory. Therefore, this application employs an object pool pattern to manage the entire lifecycle of WASM gateway plugin instances. The WASM gateway plugin instance lifecycle includes the plugin instance creation phase, plugin instance configuration phase, plugin instance invocation phase, plugin instance recycling phase, and plugin instance destruction phase. In a preferred embodiment of this application, a reusable plugin instance pool is constructed based on the WASM gateway plugin instances. The initial pool size is 8. A plugin instance pool with too small an initial size can easily lead to request queuing and waiting, affecting throughput. A plugin instance pool with too large an initial size will cause memory waste and excessive warm-up time. 8 is a balanced value that has been tested in practice and can meet the concurrency requirements of most application scenarios. The warm-up time for creating 8 WASM gateway plugin instances is between 1 and 3 seconds, which is acceptable during system startup. If the initial pool is set too large, such as 50 WASM gateway plugin instances, the warm-up time may reach 10-15 seconds, affecting the system startup speed. When the gateway system starts, 8 WASM gateway plugin instances are immediately created according to the object pool mode. These WASM gateway plugin instances have already completed time-consuming initialization work such as WASM gateway plugin loading, memory allocation, and sandbox configuration, and are in a "standby" state. Upon receiving a client request, the system checks if there are any idle WASM gateway plugin instances in the plugin instance pool. If so, the instance is invoked immediately. Otherwise, it checks if the plugin instance pool has reached its maximum instance limit. If not, a new WASM gateway plugin instance is dynamically created. If the limit has been reached, the client request must wait for other WASM gateway plugin instances to be released. During the WASM gateway plugin instance recycling phase, the internal state of the WASM gateway plugin instance is cleaned up, and then the system checks if the plugin instance pool has reached its limit. If not, the WASM gateway plugin instance is returned to the pool for later use. If the limit has been reached, the WASM gateway plugin instance is destroyed to release memory.

[0045] In the preferred embodiment of this application, by reusing already initialized WASM gateway plugin instances, the processing time for each request is reduced from creation and execution time to almost only execution time. For high-concurrency scenarios, the performance improvement can reach 5-10 times. The design concept of preloading, pooling, and isolation completely changes the inefficient "on-demand loading, discard after use" model of traditional plugin systems. The plugin instance pool ensures that the gateway plugin system does not create plugin instances indefinitely. By setting a maximum instance limit, memory leaks and resource exhaustion attacks are prevented. Simultaneously, the timeout cleanup mechanism for idle instances avoids long-term memory occupation. If a WASM gateway plugin instance crashes, it will only affect the current client request and will not affect other WASM gateway plugin instances, achieving fault isolation.

[0046] The WASM-based gateway plugin system of this application also includes:

[0047] A host proxy module is used to define a set of host capability interfaces related to gateway services, in order to establish a controlled communication channel between the sandbox execution environment and the gateway host environment. Each host capability interface in the set has a built-in static declaration layer, dynamic policy layer, and audit tracing layer to enforce access control and full-link auditing for each host capability interface call. In the prior art, WASM gateway plugins run in an isolated sandbox execution environment and cannot directly access the system resources of the gateway host environment. Traditional solutions allow WASM gateway plugins to access host resources in non-standard ways, which poses security risks. To solve the above technical problems, in a preferred embodiment of this application, a host proxy module is set up to establish a secure, efficient, and scalable controlled communication channel between the sandbox execution environment and the gateway host environment by defining a standardized set of host capability interfaces, thereby enabling plugins to have restricted access to gateway service capabilities. The set of host capability interfaces is the secure communication bridge of this application. The host capability interfaces of this application are not simply exposed traditional operating system calls or library functions, but a domain-specific language designed based on gateway service semantics, secure sandbox isolation, and the principle of least privilege. All host capability interfaces are proxied and securely encapsulated through the host proxy module, forming a unique, controlled, and auditable communication boundary between the WASM gateway plugin and the gateway host. All host capability interface calls are made through a controlled communication channel, ensuring that the WASM gateway plugin cannot directly access the host memory or execute system calls. In a preferred embodiment of this application, the host capability interface set includes the following core domains: HTTP traffic manipulation interface domain, gateway runtime context interface domain, external service communication interface domain, authentication, authorization, and security interface domain, state management and data access interface domain, observability and operation and maintenance interface domain, traffic governance and control interface domain, and tool and helper function interface domain. Among them, the HTTP traffic manipulation interface domain is the most core interface domain, used to directly handle requests and responses. For example, the request parsing interface obtains the HTTP method, URI, protocol version, and client IP / TLS information; the header and parameter manipulation interface reads request and response headers, queries parameters, and cookies; the request body streaming access interface supports chunked reading and writing, efficiently processing large volumes of data; and the response generation interface sets status codes, generates redirects, and directly writes to the response body.The Gateway Runtime Context interface field provides WASM gateway plugins with information about the processing status and environment of client requests within the gateway. For example, the routing decision information interface retrieves the matching routing rule ID, upstream service target, and plugin chain configuration; the tenant and identity context interface retrieves the tenant ID to which the request belongs, and the user identity and permission claims injected by the pre-authentication plugin; and the request processing stage interface retrieves the current processing stage of the client request, the global request ID, and the tracking context. The request processing stage includes: request reception stage, route matching stage, request verification stage, plugin loading stage, permission acquisition stage, plugin execution stage, upstream request stage, and response processing stage. The External Service Communication interface field allows plugins to interact with services outside the gateway under strict control. For example, the upstream service proxy interface supports initiating proxy calls to predefined upstream services based on the current request context; the general HTTP client interface supports initiating HTTP requests to external domains permitted by network security policies; and the service discovery interface supports querying the service registry manager and resolving the list of instances corresponding to service names. The Authentication, Authorization, and Security interface domain provides standardized security capabilities. For example, the token parsing and verification interface supports standardized parsing of tokens such as JWT (JSON Web Token) and verification of their validity; the permission check interface supports querying whether specific resources or operations are permitted based on the injected identity context; and the sensitive operation interface supports calling the gateway-integrated key management service for data encryption / decryption and signature verification. The State Management and Data Access interface domain provides secure, isolated, and persistent data storage and sharing capabilities. For example, the namespaced key-value store interface supports basic get / set / delete operations, with storage spaces automatically isolated by tenant ID and plugin ID; the cache access interface supports reading and writing to the gateway-integrated distributed cache; and the sandbox shared memory interface supports plugins in the same request pipeline to efficiently exchange data through pre-allocated memory areas. The Observability and Operations Interface domain enables WASM gateway plugins to be deeply integrated into the gateway's observability system. For example, the structured logging interface supports recording logs with rich context and supports hierarchical and audit logs; the metric reporting interface supports reporting metrics such as counters and histograms, automatically aggregating them to the gateway monitoring system; and the diagnostics and debugging interface supports performance profiling injection and slow query reporting capabilities in debug mode. The Traffic Governance and Control Interface domain encapsulates the gateway's core traffic governance capabilities for declarative use by plugins. For example, the rate limiter interface supports requesting or checking traffic quotas based on algorithms such as token bucket and leaky bucket; the circuit breaker status interface supports querying the circuit breaker status of specific upstream services; and the dynamic configuration interface supports securely reading or subscribing to specific gateway configuration fragments at runtime.The Tools and Helper Functions interface field provides general utility functions to ensure logical consistency. For example, the encoding / decoding and hashing interface supports Base64 encoding / decoding, URL encoding / decoding, SHA256 hash calculation, etc.; the time and random number interface supports obtaining secure random numbers and the current timestamp; and the string and JSON processing interface supports providing secure string operations, JSON parsing, and serialization functions.

[0048] In a preferred embodiment of this application, each host capability interface domain incorporates three layers of security control: a static declaration layer, a dynamic policy layer, and an audit and tracing layer. The static declaration layer requires that the list of required interfaces be explicitly declared in the Extism plugin configuration manifest of each WASM gateway plugin; undeclared interfaces cannot be called. The dynamic policy layer performs real-time checks on each call, such as verifying the timing of the call is compliant; verifying resource quotas to ensure that a single request does not exceed N calls; and verifying content policies to prohibit the setting of certain sensitive response headers. The audit and tracing layer generates non-repudiable audit logs for all calls, recording which WASM gateway plugin, when, which interface was called, the parameters, and a result summary for security tracing. During each call to a host capability interface domain, mandatory access control and end-to-end auditing are implemented based on the static declaration layer, dynamic policy layer, and audit and tracing layer.

[0049] In a preferred embodiment of this application, by setting a business-level host capability interface set, the plugin capability boundary is narrowed from the operating system to the gateway business semantics. Compared with the traditional approach of granting system-level security to extension modules, this achieves a fundamental improvement in security performance. Existing technologies use a generic WASI interface in general WASM host environments, which is abstracted towards the operating system. The host capability interface domain of this application is a vertical abstraction oriented towards the API gateway domain, better meeting business needs, and eliminating the need for developers to assemble from underlying primitives. The host capability interface set of this application combines functionality and security, balancing the conflicting requirements of "powerful plugin functionality" and "system security isolation."

[0050] In the preferred embodiment of this application, although there are many host capability interface domains, most of them are standardized exposures of the gateway's existing core functions. For example, the "HTTP traffic control interface" corresponds to the gateway's existing HTTP protocol stack, the "upstream service proxy interface" corresponds to the gateway's existing reverse proxy engine, and the "rate limiter interface" corresponds to the gateway's existing rate limiting module. Therefore, this application only needs to design a secure, plugin-oriented API facade for the existing functions to adapt it to the requirements of this application.

[0051] In a preferred embodiment of this application, the WASM-based gateway plug-in system further includes:

[0052] The route matching module receives client requests and, based on the client requests and a preset hierarchical priority matching algorithm, matches the target route and one or more associated target WASM gateway plugin instances from the route configuration. In a preferred embodiment of this application, after receiving the client request, deep parsing is initiated to extract key feature vectors for route matching. These key feature vectors mainly include: tenant identity features, request path features, network host features, and HTTP method features. Specifically, the tenant identity feature is extracted from the predefined x-tenant-id request header to extract the tenant's unique identifier. The request path feature is extracted using standardized extraction of the complete URI path and path segmentation analysis to identify the location and pattern of variables in the path. The network host feature is extracted using precise extraction of the HTTP Host request header, supporting standard formats including port numbers, and the resolution and mapping of virtual host aliases, as well as SNI-based TLS hostname matching. The HTTP method feature is extracted using standardized extraction of the request method, supporting standard HTTP methods and extended methods, as well as semantic classification of method types, such as secure methods and insecure methods. Auxiliary matching features can also be set, including request header features, client network features, and timing and context features. Request header feature extraction uses standard HTTP header field parsing and the identification and extraction of custom business header fields, supporting pattern matching header filtering. Client network feature extraction uses source IP address geolocation parsing, supporting country, region, and city-level granularity, as well as network operator identification and network type classification. Timing and context feature extraction uses request arrival timestamps and time zone standardization, as well as request sequence numbers and associated session identifiers.

[0053] In a preferred embodiment of this application, the preset hierarchical priority matching algorithm is configured to include: first-priority tenant isolation matching, second-priority request path accuracy matching, third-priority host header condition matching, and fourth-priority HTTP method whitelist matching. Specifically, the first-priority tenant isolation matching, based on tenant identification characteristics, limits the search scope to a subset of routing rules belonging to that tenant. If no tenant identification characteristics are provided, a default tenant space is used. The validity of the tenant identification characteristics and access permissions are verified. Tenant isolation matching enables complete configuration isolation in a multi-tenant environment, avoiding rule interference and unauthorized access between tenants. The second priority is request path precision matching, which performs multi-mode matching on request paths within the tenant space, including: exact path matching, prefix path matching, and wildcard pattern matching. In exact path matching, the highest matching score is obtained when the request path exactly matches the rule path, supporting both case-sensitive and case-insensitive matching modes. In prefix path matching, the second highest matching score is obtained when the request path uses the rule path as a prefix; the longer the matching length, the higher the score, implementing the longest prefix matching principle. In wildcard pattern matching, single-level and multi-level wildcard modes are supported. Wildcard matching serves as a fallback solution with the lowest priority; its semantics are clear, avoiding fuzzy matching. The third priority is host header condition matching. After path matching, optional host header constraint checks are performed. Host header condition matching modes include: exact host matching, wildcard host matching, multi-host list matching, and port ignore mode. Exact host matching means the Host header exactly matches the rule host. Wildcard host matching supports… The ".example.com" format allows for subdomain wildcard matching. Multiple host list matching means the rule defines multiple allowed hostnames; any match is acceptable. Port ignore mode allows ignoring the port number portion of the Host header. Host header condition matching strategies include: skipping this priority check if the rule doesn't define a host condition; excluding the rule if a host condition is defined but the request doesn't meet it; and using a Boolean filter instead of scoring. The fourth priority is HTTP method whitelist matching, which sets whitelist and blacklist modes. Whitelist mode defines a list of allowed HTTP methods, and blacklist mode defines a list of disallowed HTTP methods. If no method condition is defined, all methods are allowed.

[0054] Based on the aforementioned hierarchical priority matching algorithm, the target route and its associated one or more target WASM gateway plugins are matched from the routing configuration. This application achieves sub-millisecond-level efficient route matching through a pre-defined hierarchical priority matching algorithm. Compared to the complexity of traditional linear traversal matching algorithms, this application significantly reduces matching complexity. Even in scenarios with massive routing rules, it maintains a stable microsecond-level response time, greatly improving route matching performance and effectively solving the routing performance bottleneck problem of gateway systems in high-concurrency scenarios. The hierarchical priority matching strategy of this application establishes a four-level precise matching priority system, fundamentally eliminating routing ambiguity and ensuring that each client request can be accurately routed to the expected target WASM gateway plugin instance, achieving a routing accuracy rate of over 99.99%, significantly reducing business anomalies caused by incorrect routing.

[0055] In a preferred embodiment of this application, during the request filtering phase, an internal management endpoint check is performed. This check employs a three-layer interception architecture to ensure that client requests are identified and processed at the highest level. After a client request enters the gateway, it is determined whether it is an internal endpoint. If so, the internal endpoint is processed directly, and a response is returned. Internal endpoints include three categories: the first is "version" (gateway version information query interface), which returns gateway version information in structured JSON format; the second is "metrics" (Prometheus format monitoring metric exposure interface), which returns metrics conforming to the Prometheus text format specification. Metric categories include: system metrics, business metrics, plugin metrics, and network metrics; the third is "config" (dynamic configuration query and update interface), which returns or updates all or part of the currently effective gateway configuration. If it is not an internal endpoint, the aforementioned route matching is performed. If route matching fails, a 404 error is returned; if route matching succeeds, load balancing is performed to select the backend and request body filtering is applied. During the request body filtering phase, the system stores the received client request body fragments in the context. When the end flag is received, all request body fragments are aggregated, and the request body size is checked to see if it exceeds the maximum limit configured in the route. The default value for this application is 10MB. If it exceeds the limit, a 413 error is returned. If it does not exceed the limit, the request body is converted into a string format for subsequent plugin execution and concurrency control.

[0056] In the preferred embodiment of this application, unlike the traditional gateway design that mixes management endpoints in service routing, the present invention adopts an architecture of front-end interception, independent processing, and security isolation to ensure that management operations do not affect the processing performance of service traffic, while preventing the management interface from being maliciously exploited.

[0057] In a preferred embodiment of this application, the WASM-based gateway plug-in system further includes:

[0058] An extensible request module is used to dynamically load and sequentially execute the target WASM gateway plugin instance according to a predefined plugin execution pipeline through the controlled communication channel, thereby completing the lifecycle transformation of the client request. In a preferred embodiment of this application, the target WASM gateway plugin instance is executed sequentially according to the plugin list configured in the routing configuration, under the security protection of the controlled communication channel. The plugin execution includes the following steps:

[0059] S01. Based on the configured number of concurrent execution licenses for the plugin, obtain or create a WASM gateway plugin instance for the target WASM gateway plugin from the plugin instance pool. The number of concurrent execution licenses controls the system's concurrent execution level. In this application, the number of concurrent execution licenses is 64, the timeout is 5 seconds, and a fair first-in-first-out queue is used. In specific execution, the request thread attempts to acquire a semaphore license. If the current number of concurrent execution licenses is less than 64, the license is granted immediately. If the limit has been reached, the request thread enters a waiting queue. If the license is not acquired after the timeout, a "Time out Error" is generated. Obtain an available WASM gateway plugin instance from the plugin instance pool. Specifically, check if there are any idle plugin instances in the instance pool. If so, acquire an idle plugin instance and mark it as active. If not, and the number of instances in the current plugin instance pool is less than the maximum instance limit, dynamically create a new plugin instance. If the maximum instance limit has been reached and there are no idle instances, wait for other instances to be released. After acquisition, immediately mark the plugin instance as "in use" and record the acquisition thread and request ID for tracking purposes.

[0060] S02. Serialize the plugin execution context parameters into input data with a size limit and pass it to the sandbox execution environment through the host capability interface set. Before execution begins, the execution context parameters are serialized. The execution context parameters refer to the collection of all environment, input, and state information required for plugin execution. The serialization format is JSON, and the serialization size is limited to 10MB. The serialized content includes request metadata, client information, environment variables, and context data. Security controls are implemented during serialization. Data exceeding 10MB triggers a serialization failure exception. Sensitive information is anonymized before serialization, and the format correctness of the serialization result is verified using JSON Schema.

[0061] S03. Within the sandbox execution environment, the phase support query function corresponding to the target WASM gateway plugin instance is called. If the phase support query function outputs "supported," the target WASM gateway plugin instance is dynamically loaded and executed. The phase support query function is used to determine the request processing phases supported by the target WASM gateway plugin instance. The plugin's phase support query function is called, passing in the current phase identifier, and the output of the phase support query function is obtained. The output includes "supports the current phase," "does not support the current phase," and "verification failed." This application's phase compatibility verification avoids undefined behavior caused by executing the WASM gateway plugin in an unsupported phase, allows the WASM gateway plugin to finely control functional availability at each phase, and supports the WASM gateway plugin to implement different processing logic at different phases.

[0062] S04. Through the host capability interface set, the output data generated by the target WASM gateway plugin instance in the sandbox execution environment is transmitted back to the gateway side. The core processor on the gateway side parses and executes the plugin processing result carried by the output data. The actual execution of the plugin is placed in an isolated sandbox execution environment to avoid blocking the main asynchronous runtime. In a preferred embodiment of this application, the sandbox execution environment is a "blocking task thread pool", specifically configured as follows: the thread pool size is 2 CPU cores, the thread stack size is 2MB, and the task queue length is 1000. The specific execution process is as follows: the plugin execution task is submitted to the blocking task thread pool; the main asynchronous thread returns immediately to continue processing other requests; the thread pool allocates a dedicated thread to execute the plugin WASM code; after execution, the main thread is notified through the Future / Promise mechanism. Safe isolation is implemented during plugin execution. The requirements for safe isolation include: each plugin executes in an independent thread; memory isolation between threads to avoid data competition; and thread crashes do not affect the stability of the main runtime. Through the host capability interface set, the output data generated by the target WASM gateway plugin instance in the sandbox execution environment is transmitted back to the gateway side. The core processor on the gateway side parses and executes the plugin processing results carried by the output data. The parsing process includes: verifying the correctness and integrity of the JSON format; extracting HTTP response header information; parsing the response body content; verifying the consistency between the status code and the business status; and determining the subsequent process based on the next_action (next operation). For example, if JSON parsing fails, an error is logged and a 500 Internal Server Error status code is returned; if a required field is missing, default values ​​are added or a 400 Bad Request is returned; if the data format is abnormal, a warning is logged and an attempt is made to repair it or use the default value.

[0063] After execution, execution metrics are collected. These metrics include performance metrics, business metrics, and resource metrics. Performance metrics include execution time, peak CPU utilization, peak memory allocation, and I / O wait time. Business metrics include the number of successful executions, the number of failed executions categorized by error type, the number of timeouts, and peak concurrent execution. Resource metrics include plugin instance pool utilization, semaphore wait time statistics, thread pool queue length, and memory fragmentation rate. For metric storage, real-time metrics are stored in a memory circular buffer, retaining data from the most recent 5 minutes. Historical metrics are persisted to a time-series database, retaining detailed data for 30 days. Aggregated metrics are aggregated by minute, hour, and day and retained long-term.

[0064] In a preferred embodiment of this application, the WASM-based gateway plug-in system further includes:

[0065] An isolation control module is used to hard limit the number of concurrent execution licenses for the plugins through a global semaphore mechanism and monitor the resource consumption of each WASM gateway plugin instance, so that an anomaly of a single WASM gateway plugin instance does not affect the execution of other WASM gateway plugin instances. In a preferred embodiment of this application, a dual isolation protection system is constructed, including hardware isolation for concurrent execution implemented through a global semaphore mechanism and soft isolation for resource consumption implemented through sandbox resource monitoring. Therefore, the isolation control module includes:

[0066] A global concurrency controller maintains a global hierarchical semaphore system. Based on this system, each target WASM gateway plugin must successfully obtain permission before execution, achieving system-level total concurrency control. In a preferred embodiment of this application, a global hierarchical semaphore system is used to achieve fine-grained concurrency control. Specifically, the global hierarchical semaphore system includes a global total permission semaphore, plugin-level concurrency semaphores, and tenant-level quota semaphores. The global total permission semaphore controls the total number of WASM plugin instances allowed to execute simultaneously across the entire gateway system, preventing system-level resource exhaustion and ensuring that core gateway functions are not affected. The plugin-level concurrency semaphore controls the maximum number of concurrent executions of the same type of plugin, configured based on plugin ID or functional category. For example, an authentication plugin can execute a maximum of 5 instances simultaneously to prevent excessive resource consumption by a specific plugin type. The tenant-level quota semaphore controls the maximum number of concurrent executions per tenant, configured based on tenant ID, achieving fair resource allocation among multiple tenants. Before any plugin is executed, calculate the required license type and quantity, acquire semaphore licenses at all levels, and continue execution if successful; otherwise, enter the waiting queue, set the acquisition timeout, and return an error if the timeout occurs. After execution is complete, release semaphore licenses in reverse order.

[0067] The isolation control module also includes:

[0068] The sandbox resource monitor performs memory resource monitoring, CPU resource monitoring, and network resource monitoring on each WASM gateway plugin instance, and handles detected faults according to a preset fault isolation and self-healing mechanism. In a preferred embodiment of this application, the sandbox resource monitor performs memory resource monitoring, CPU resource monitoring, and network resource monitoring. Memory resource monitoring includes: linear memory usage, host memory usage, memory allocation patterns, and memory leak detection; CPU resource monitoring includes: CPU time consumption, CPU utilization, instruction execution count, and hotspot function identification; network resource monitoring includes: number of network connections, network bandwidth usage, connection duration, and external call frequency. To implement sandbox resource monitoring, in this preferred embodiment of this application, different non-intrusive monitoring technologies are used for different objects. For example, for WASM runtime extensions, monitoring points are injected at the WASM runtime level; for host function wrappers, resource metering is performed before all host function calls; for memory access interception, the allocation and access patterns of linear memory are monitored; and for system call hooks, system-level resource access is intercepted and metered.

[0069] In a preferred embodiment of this application, a fault isolation and self-healing mechanism is set up, employing a tiered fault handling strategy. Specifically, Level 1 is for handling minor anomalies, addressing situations where resource usage is close to but not exceeded. The handling strategy involves sending an early warning, restricting the allocation of new requests, and observing subsequent behavior. The recovery mechanism is that the restriction is automatically lifted after resource usage decreases. Level 2 is for handling moderate anomalies, addressing situations where resource usage exceeds the quota but does not affect system stability. The handling strategy involves pausing the acceptance of new requests, allowing currently executing requests to complete, initiating detailed diagnostic data collection, and notifying the operation and maintenance system to record the event. The recovery mechanism is that the system automatically restarts after resource release. Level 3... Level 1 is for severe anomaly handling, addressing situations where resources are exhausted or abnormal behavior threatens system stability. The handling strategy is to immediately terminate the abnormal plugin instance, isolate related resources, initiate emergency resource reclamation, trigger system-level alarms, and record abnormal data for analysis. The recovery mechanism requires manual intervention to analyze and determine the recovery strategy. Level 4 is for catastrophic failure handling, addressing situations where plugin failures may extend to affect the gateway core. The handling strategy is to immediately terminate all similar plugin instances, initiate system-level protection mode, isolate the scope of the failure, switch to degraded service mode, and notify upstream services to switch traffic. The recovery mechanism is manual recovery after systemic analysis.

[0070] In the preferred embodiment of this application, the isolation control module fundamentally solves the problem of systemic risk caused by the failure of a single plug-in in traditional gateway plug-in systems, ensuring that the gateway maintains stability and reliability while providing high scalability.

[0071] In a preferred embodiment of this application, after the plugin is executed, the plugin processing result is intelligently converted and accurately forwarded to the upstream target service. Unlike the traditional simple path mapping of gateways, this application ensures that the upstream service can receive standardized, compliant, and business-oriented requests through deep semantic understanding and dynamic reconstruction of the original request during the upstream request filtering stage. The execution of the upstream request filtering stage follows strict triggering logic, which is as follows: successful route matching (the target upstream service must have been determined); plugin chain execution completed (all registered request processing plugins have been executed); upstream service available (the target service has passed the health check and the circuit breaker is not activated); and valid request status (the request has not been prematurely terminated due to an error). After satisfying the above upstream request filtering stage execution triggering logic, the upstream request filtering stage is executed. During the upstream request filtering stage, URI rewriting is performed according to the routing configuration. URI rewriting supports three rewriting modes, each corresponding to different business scenarios. Specifically:

[0072] The first mode, service path wildcard concatenation, aims to preserve the original semantics of the request by only adding a service namespace. The rewriting algorithm directly concatenates the service prefix with the original request path. The service prefix is ​​a fixed path prefix defined in the routing configuration. Specifically, the concatenation rules are: if the service prefix ends with " / " and the original request path begins with " / ", deduplication is performed, and multi-level prefix nesting is supported, for example, / api / v1 / + / users / profile → / api / v1 / users / profile. Finally, URL encoding consistency is automatically handled to ensure correct transmission of encoded characters. This first mode is suitable for scenarios such as RESTful API gateways (API gateways conforming to REST specifications) and microservice API routing.

[0073] The second mode, static service path replacement mode, aims to completely rewrite the request path, achieving request semantic transformation. The rewriting algorithm directly replaces the original request path with a static service path, which is the complete target path defined in the routing configuration. The specific replacement rule completely ignores the client's original request path, supports dynamic parameter templates in the path, and finally extracts parameter values ​​from the original request to populate the dynamic parameter templates. This second mode is suitable for scenarios such as protocol conversion, API version migration, and backend service reconstruction.

[0074] The third mode, route prefix pruning, aims to remove the public prefix exposed by the gateway, revealing the true service path. The trigger condition is the presence of "trim_prefix = true" in the route configuration. The pruning algorithm directly removes the matching route prefix from the original request path. Specifically, the pruning principle accurately identifies the path prefix used for matching in the route configuration and supports multi-segment prefix pruning. For example, for a route ` / api / v1 / `, a request ` / api / v1 / users` → ` / users` is executed. Finally, intelligent boundary processing ensures that the pruned path begins with " / ", avoiding the generation of invalid paths. This third mode is suitable for scenarios such as multi-layer gateway proxies, path flattening, and migration compatibility.

[0075] In a preferred embodiment of this application, after URI rewriting, the header injected by the plugin is added to the upstream request. If the plugin returns a new request body, the "content-length" mode is switched to the "transfer-encoding: chunked" mode.

[0076] In the preferred embodiment of this application, a three-mode URI rewriting architecture is used to achieve accurate conversion of request semantics, significant improvement in transmission efficiency, and comprehensive enhancement of system reliability in the gateway system, achieving breakthrough improvements in four dimensions: functionality, performance, reliability, and security.

[0077] In a preferred embodiment of this application, the WASM-based gateway plug-in system further includes:

[0078] An error handling module is triggered when an error occurs at any stage of the execution of the target WASM gateway plugin by the scalable request module. It is used to call the error handling interface of the currently associated plugin through the controlled communication channel to process the error information in the sandbox execution environment and generate a standardized error response. In the prior art, error handling in traditional gateways is scattered, the response format is not uniform, and plugins cannot participate in error handling. To address the above defects, in the preferred embodiment of this application, a three-in-one error management system consisting of an error handling pipeline, plugin-customizable error handling, and standardized error response generation is constructed, realizing full-link standardization and scalability from error detection, processing to response. The error handling module is designed as a unified infrastructure throughout the entire request processing phase. Specifically, during the request reception phase, it triggers network connection errors and protocol parsing errors; during the route matching phase, it triggers route matching failures; during the request verification phase, it triggers request format errors and excessively large request parameters; during the plugin loading phase, it triggers plugin loading failures and version incompatibility; during the license acquisition phase, it triggers semaphore closure and insufficient resources; during the plugin execution phase, it triggers plugin execution errors; during the upstream request phase, it triggers connection timeouts, service unavailability, and protocol errors; and during the response processing phase, it triggers response format errors and size exceeding limits. In this application, regardless of the phase in which an error occurs, it uniformly enters the "fail_to_proxy" generation cycle function for error handling, and finally returns a standardized error response.

[0079] The error handling pipeline of this application consists of three stages. In the first stage, error detection points are set at the critical boundaries of each processing stage of the request. When an error occurs, the complete processing context is captured immediately, and preliminary classification and priority assessment are performed based on the error characteristics. The further propagation of the error in the system is immediately blocked. In the second stage, an appropriate processor is selected based on the error type and severity. The error handling interface of the associated plugin is called through a controlled communication channel. When the plugin fails to process the error, it automatically degrades to the system default processing and sets strict timeout limits for the plugin error handling. In the third stage, a standardized HTTP response is built based on the processing result to ensure the consistency of the error response format, encoding, and structure. The complete error handling process is recorded for later analysis and optimization. Finally, the resources occupied during the error handling process are released.

[0080] In a preferred embodiment of this application, the WASM-based gateway plug-in system further includes:

[0081] A blockchain network is used to store and maintain trusted metadata records for the WASM gateway plugin. These trusted metadata records include the WASM gateway plugin's unique content identifier, developer digital signature, version number, and security audit status hash. Traditional centralized plugin distribution models suffer from core problems such as single points of failure, trust dependency, and auditing difficulties. To address these shortcomings, in this preferred embodiment, blockchain technology is deeply integrated with the WASM gateway plugin to construct a decentralized, immutable, and publicly verifiable plugin trusted verification system. The blockchain network adopts a main-chain-side-chain hybrid architecture. The plugin's main chain is a public blockchain, such as Ethereum or Polkadot, primarily used for global consensus guarantees, maximum security assurance, and final arbitration. The plugin's side chain is a consortium blockchain or a dedicated blockchain, primarily used for high-performance transaction processing, enterprise-level privacy protection, and low-latency verification. The validator nodes of the blockchain network are consortium nodes composed of gateway manufacturers, security audit institutions, and trusted developers. They are responsible for verifying and packaging plugin metadata transactions. The observer nodes are gateway running nodes that only synchronize and verify data and do not participate in consensus. The archive nodes are dedicated nodes that store complete historical data and provide long-term audit support. The light nodes are resource-constrained edge gateway nodes that perform efficient verification through Merkle proofs.

[0082] A plugin registration contract is deployed on the blockchain network, responsible for registering basic plugin information. Developers call the contract's `registerPlugin` function (the plugin registration function) and attach the plugin's basic information, including: core identifier information, such as the plugin content hash, developer wallet address, and registration timestamp; version information, such as semantic version number and previous version hash; trusted proof, such as developer digital signature, audit institution signature, and audit timestamp; state information, such as plugin state, state changer, and state change time; and storage reference information, such as the IPFS CID of detailed metadata and the IPFS CID of the source code. The contract logic is as follows: verify the developer's signature to ensure the request comes from the private key holder; check if the core identifier of the WASM gateway plugin to be registered already exists to prevent duplicate registration; generate a unique plugin ID, which can be an auto-incrementing ID or an address derived from the developer's address and content hash; store the plugin's basic information in the contract's mapping, initializing the state to pending review or registered; and emit a `PluginRegistered` event (the plugin registration event) for the frontend to listen for. The status of a pending WASM gateway plugin is typically an enumeration type, such as registered, under review, approved, rejected, deprecated, malicious, etc. The plugin information structure contains a version linked list. When a developer releases a new version, they call the `updateVersion` function (update version), providing the new semantic version number, the new content hash, and the previous version hash. The contract logic for version updates is as follows: verify whether the previous version hash matches the current latest version to ensure version continuity, and then use the new version as the new head node of the linked list, updating the stored reference information.

[0083] A reputation evaluation contract is also deployed on the blockchain network. The goal of this contract is to transform the runtime performance of a plugin into an objective, quantifiable, and tamper-proof plugin reputation score. Responding to the plugin's runtime status data, a reputation score is assigned to each WASM gateway plugin. Runtime status data includes: uptime, number of crashes, number of security incidents, user ratings, and the number of ratings. The contract internally maintains a plugin reputation score, for example, an integer from 0 to 100, and updates the plugin reputation score using a multi-dimensional weighted algorithm. Specifically, the runtime status data is normalized to obtain uptime score, stability score, security score, and user satisfaction score. The normalization process is represented as follows:

[0084]

[0085]

[0086]

[0087]

[0088] in, Indicates normal operating time in minutes. Indicates uptime. Indicates the normal operating reference time. Indicates stability score, Indicates the number of crashes. This represents the crash penalty coefficient. Indicates the number of operating cycles. Indicates safety score. This represents the safety time penalty coefficient. Indicates the number of security incidents; Indicates user satisfaction score. This represents the sum of user ratings. Indicates the number of times a user has rated a product. This represents the user rating benchmark.

[0089] In the preferred embodiment of this application, dynamic weight allocation is adopted. When a new WASM gateway plugin is launched, user rating and runtime have higher weights to encourage early adoption and accumulation. When the WASM gateway plugin is widely used, the weights of stability score and security score are significantly increased because their impact is wider. Once a security incident occurs, the weight of security score will be temporarily and significantly increased in several subsequent update cycles to reflect the lasting impact of its serious consequences.

[0090] Finally, the plugin reputation score is calculated using the following formula:

[0091]

[0092] in, This represents the plugin's reputation score. Indicates the first Dimensional rating, Indicates the first The weights of the dimensional scores are dynamically allocated based on the running status of the WASM gateway plugin.

[0093] Once the reputation evaluation is complete, the last update timestamp is recorded. Any user or other contract can call the `getReputationScore` view function free of charge to obtain the latest plugin reputation score and key metrics for the WASM gateway plugin. The user interface can sort and tag plugins based on their reputation scores.

[0094] Access control contracts are also deployed on the blockchain network to implement policy-based access control. The plugin management module (as the requester) initiates a structured plugin usage license request to the access control contract. This request includes at least the following metadata fields: target plugin identifier, a unique identifier for the WASM gateway plugin to be verified, such as plugin ID or content hash; requester identity, the blockchain address of the tenant or service initiating the request; and request context information, including a request timestamp, resource requirement description, or session ID, used to enhance auditing and correlation. In response to the received plugin usage license request, the access control contract calls its internally integrated license verification function to perform chained conditional verification on the request, including: identity and permission verification, checking whether the requester's identity exists in the list of allowed tenants; and timeliness verification, obtaining the current block timestamp of the blockchain and comparing it with the expiration time defined in the policy to verify whether the current time is earlier than the expiration time, ensuring that the request occurs within the license's validity period.

[0095] Upon successful verification, an access permission credential is generated. This credential contains: authorization ID, plugin ID, tenant address, expiration time of this authorization, and a random number to prevent replay attacks. The request result containing this permission credential is returned to the plugin management module, triggering an on-chain event to record the authorization details for external monitoring and auditing.

[0096] In a preferred embodiment of this application, a decentralized, automated, and verifiable WASM gateway plugin management system is constructed. The unique content identifier and developer digital signature of the WASM gateway plugin are permanently anchored to the blockchain, ensuring that the plugin bytecode cannot be maliciously tampered with from the moment of release. Before use, users verify the plugin upon download by calculating a local hash and comparing it with the on-chain record, preventing supply chain attacks. The developer's digital signature strongly binds the plugin to a specific blockchain identity; any malicious behavior will be permanently traced back to that identity, causing irreversible damage to its reputation. This establishes a strong deterrent against malicious activity, offering higher credibility than anonymous or easily forged centralized account systems. Linking the storage of third-party security audit reports with the plugin version allows users and automated systems to transparently verify whether a version has been audited by a specific authoritative institution and whether the audit report itself is complete and unmodified, promoting transparency in security practices.

[0097] This embodiment provides a WASM-based gateway plugin system to address the technical issues of improving the security of gateway business logic extension, as well as achieving fine-grained resource management, host capability exposure control, and multi-plugin collaborative processing. The system includes: a plugin management module, used to obtain routing configurations from the service registry manager, create a preloaded plugin list based on the corresponding WASM gateway plugins according to the routing configurations, create an independent WASM gateway plugin instance for each WASM gateway plugin in the preloaded plugin list in the sandbox execution environment, and manage the WASM gateway plugin instances using an object pool model; a host proxy module, which defines a set of host capability interfaces related to gateway services, used to establish a controlled communication channel between the sandbox execution environment and the gateway host environment, each host capability interface in the set has a built-in static declaration layer, dynamic policy layer, and audit tracing layer to implement mandatory access control and full-link auditing for each host capability interface call; a route matching module, used to receive client requests, and match the target route and one or more associated target WASM gateway plugins from the routing configuration according to the client request and a preset hierarchical priority matching algorithm; and an extensible request module, used to dynamically load and execute the target WASM gateway plugins using WASM gateway plugin instances through the controlled communication channel and according to a predefined plugin execution pipeline, to obtain the plugin processing result of the client request. The WASM-based gateway plugin system provided in this application reduces the processing time for each request from creation and execution time to almost only execution time by reusing pre-initialized WASM gateway plugin instances. It adopts a three-pronged design philosophy of preloading, pooling, and isolation, completely changing the inefficient "on-demand loading, use-and-discard" model of traditional plugin systems. By setting a set of business-level host capability interfaces, the plugin capability boundary is narrowed from the operating system to the gateway's business semantics, achieving a fundamental improvement in security performance compared to the traditional approach of granting system-level security to extension modules. Through a pre-defined hierarchical priority matching algorithm, sub-millisecond-level efficient route matching is achieved, significantly improving route matching performance and effectively solving the routing performance bottleneck problem of gateway systems in high-concurrency scenarios. The isolation control module fundamentally solves the systemic risk problem caused by the failure of a single plugin in traditional gateway plugin systems, ensuring that the gateway maintains stability and reliability while providing high scalability. A decentralized, automated, and verifiable WASM gateway plugin management system is constructed, permanently anchoring the unique content identifier and developer digital signature of the WASM gateway plugin to the blockchain, preventing supply chain attacks and promoting transparency in security practices.

[0098] The various embodiments in this specification are described in a progressive manner. For directly identical or similar parts of the various embodiments, refer to each other. Each embodiment focuses on its differences from other embodiments. It should be noted that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as these combinations of technical features do not contradict each other, they should be considered within the scope of this specification.

[0099] The above-described embodiments are merely preferred embodiments of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various improvements and substitutions without departing from the principles of the present invention, and these improvements and substitutions should also be considered within the scope of protection of the present invention. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A gateway plug-in system based on WASM, characterized in that, The system includes: The plugin management module is used to obtain route configuration from the service registration manager, create a preloaded plugin list according to the WASM gateway plugin corresponding to the route configuration, create an independent WASM gateway plugin instance for each WASM gateway plugin in the preloaded plugin list in the sandbox execution environment, and manage the WASM gateway plugin instance using the object pool mode. The host proxy module is used to define a set of host capability interfaces related to the gateway service, so as to establish a controlled communication channel between the sandbox execution environment and the gateway host environment. Each host capability interface in the set of host capability interfaces has a built-in static declaration layer, dynamic policy layer and audit tracing layer to implement mandatory access control and full-link audit for each call to the host capability interface. The route matching module is used to receive client requests and, based on the client requests and a preset hierarchical priority matching algorithm, match the target route and one or more associated target WASM gateway plugins from the route configuration. An extensible request module is used to dynamically load and execute the target WASM gateway plugin using the WASM gateway plugin instance through the controlled communication channel, according to a predefined plugin execution pipeline, to obtain the plugin processing result of the client request.

2. The WASM-based gateway plug-in system as described in claim 1, characterized in that, The host capability interface set includes the following core domains: HTTP traffic manipulation interface domain, gateway runtime context interface domain, external service communication interface domain, authentication, authorization and security interface domain, state management and data access interface domain, observability and operation and maintenance interface domain, traffic governance and control interface domain, and tools and helper function interface domain.

3. The WASM-based gateway plug-in system as described in claim 1, characterized in that, The hierarchical priority matching algorithm includes: tenant isolation matching (first priority), request path accuracy matching (second priority), host header condition matching (third priority), and HTTP method whitelist matching (fourth priority).

4. The WASM-based gateway plug-in system as described in claim 1, characterized in that, The plugin management module is configured as follows: Create a plugin configuration list for each of the WASM gateway plugins in the preloaded plugin list. The plugin configuration list is used to set the resource limits of the WASM gateway plugin in the sandbox execution environment. The resource limits include: memory safety boundary, computing resource limit, capability access control and network access policy. Based on the plugin configuration list, an independent WASM gateway plugin instance is created for each of the WASM gateway plugins in the sandbox execution environment; Based on the WASM gateway plugin instance, a reusable plugin instance pool is constructed, and the initial pool size is set. Based on the initial pool size, the plugin instance pool is managed using an object pool pattern.

5. The WASM-based gateway plug-in system as described in claim 4, characterized in that, The extensible request module is configured as follows: Based on the configured number of concurrent execution licenses for plugins, obtain a target WASM gateway plugin instance from the plugin instance pool for the target WASM gateway plugin; The plugin execution context parameters are serialized into input data with a size limit, and the input data is passed to the sandbox execution environment through the host proxy module; Within the sandbox execution environment, the phase support query function corresponding to the target WASM gateway plugin instance is called. If the output result of the phase support query function is "supported", the target WASM gateway plugin instance is used to dynamically load and execute the target WASM gateway plugin. The phase support query function is used to determine the request processing phase supported by the target WASM gateway plugin instance. Through the host capability interface set, the output data generated by the target WASM gateway plugin instance in the sandbox execution environment is transmitted back to the gateway side, and the core processor on the gateway side parses and executes the plugin processing result carried by the output data.

6. The WASM-based gateway plug-in system as described in claim 5, characterized in that, The system also includes: The isolation control module is used to hard limit the number of concurrent execution licenses of the plugin through a global semaphore mechanism, and to monitor the resource consumption of each WASM gateway plugin instance, so that the failure of a single WASM gateway plugin instance does not affect the execution of other WASM gateway plugin instances.

7. The WASM-based gateway plug-in system as described in claim 6, characterized in that, The isolation control module includes: A global concurrency controller is used to construct a global hierarchical semaphore system. Based on the global hierarchical semaphore system, a semaphore permission request is made before each target WASM gateway plugin is executed. If the request is successful, the target WASM gateway plugin continues to be executed. If the request fails, it enters a waiting queue. The global hierarchical semaphore system includes a global total permission semaphore, a plugin-level concurrent semaphore, and a tenant-level quota semaphore. The sandbox resource monitor is used to perform memory resource monitoring, CPU resource monitoring, and network resource monitoring on each of the WASM gateway plugin instances, and to handle the detected faults according to the preset fault isolation and self-healing mechanism.

8. The WASM-based gateway plug-in system as described in claim 1, characterized in that, The system also includes: The error handling module is triggered at any stage of the execution of the target WASM gateway plugin by the extensible request module. It is used to call the error handling interface of the currently associated plugin through the controlled communication channel to process the error information in the sandbox execution environment and generate a standardized error response.

9. The WASM-based gateway plug-in system as described in claim 1, characterized in that, The system also includes: A blockchain network is used to store and maintain a trusted metadata record for the WASM gateway plugin, the trusted metadata record containing the WASM gateway plugin's unique content identifier, developer digital signature, version number, and security audit status hash value.

10. The WASM-based gateway plug-in system as described in claim 9, characterized in that, The blockchain network is deployed with smart contracts, which include: The plugin registration contract receives registration requests from developers for WASM gateway plugins to be registered, and performs permission and version verification on the WASM gateway plugins to be registered according to the registration requests, and registers basic information for the WASM gateway plugins to be registered that pass the verification. The reputation evaluation contract, in response to the runtime status data of the WASM gateway plugins, performs a reputation score on each of the WASM gateway plugins and generates a plugin reputation score; The access control contract receives the plugin usage license request initiated by the plugin management module, and verifies the WASM gateway plugin to be verified according to the plugin usage license request, and generates the plugin verification result.

Images