Information service publishing and distributing method and system

Abstract

The invention discloses a method and a system for publishing and distributing information service, which realize full-process automatic management of application from developer submission and auditing to access party online through unified application uploading, mirror image construction, isolation environment auditing and multi-dimensional automatic verification. The system supports multi-tenant isolated deployment, and a built-in review rule engine completes compatibility, safety and functional verification; realizing cross-environment adaptation based on the standardized container mirror image and the reusable application assets; and dynamic resource scheduling and alarm rollback are supported through a multi-level elastic capacity expansion and contraction and abnormal instance processing mechanism. According to the method and the system, application version multiplexing and operation state visual monitoring can be realized, the delivery efficiency is improved, the operation and maintenance cost is reduced, and the cluster resource utilization rate and the system stability are improved.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and PaaS (Platform-as-a-Service) technology, and in particular to an information service publishing and distribution method and system, which is suitable for building an automated application platform that supports application review and listing, on-demand isolated deployment, and intelligent operation and maintenance during runtime. Background Technology

[0002] With the development of containerization and PaaS technologies, the building, deployment, and operation of applications on platforms are gradually becoming automated. However, in the existing technology system, the process from application submission by developers to the final provision of services to different business parties still has many shortcomings.

[0003] First, existing platforms typically revolve around image building and continuous delivery processes, but lack a unified access review mechanism before applications go live. This makes it impossible to systematically verify the application's compatibility, security risks, resource quota compliance, and operational behavior, which can easily lead to situations such as environmental incompatibility, security vulnerability exposure, or abnormal resource consumption in the production environment.

[0004] Secondly, in existing technologies, the application delivery process is mainly based on single-tenant deployment. After the application passes verification, it is difficult to reuse it in the form of "standardized application assets". Different business parties need to repeatedly build, test and configure, which increases the deployment cost.

[0005] Furthermore, in scenarios where multiple business parties use the same application in parallel, the existing platform's isolation and distribution capabilities are insufficient. It is difficult to achieve logical isolation deployment based on the business parameters or operating environment of different access parties, which may lead to problems such as mutual configuration interference and unclear data access boundaries.

[0006] Furthermore, application deployment processes and runtime operation and maintenance mechanisms are often disconnected in existing platforms. Resource scheduling typically relies on manual operation or fixed rules, and cannot automatically make scaling up / down or alarm decisions based on real-time traffic, performance indicators, or anomalies, resulting in insufficient resource utilization or decreased service reliability.

[0007] Although some existing technologies have introduced monitoring systems and elastic scaling mechanisms, these capabilities and the application review, release and distribution processes have not formed a unified closed loop, making it difficult to support the needs of automated application management in multi-role and multi-tenant scenarios.

[0008] Therefore, there is still a need for an application release and distribution method and system that can achieve unified application review, reusable management, on-demand isolated distribution, and intelligent operation and maintenance during runtime, in order to solve the above-mentioned technical problems. Summary of the Invention

[0009] This invention provides a method and system for publishing and distributing information services, which is used to automate the process of application from uploading, review, and listing to on-demand deployment and runtime operation and maintenance, so as to support unified management of applications in multi-role and multi-tenant scenarios.

[0010] This invention provides a method for publishing and distributing information services, comprising three stages: trusted application deployment, on-demand distribution and deployment, and intelligent operation and maintenance during runtime. Each stage includes the following steps: The trusted application deployment stage involves receiving application code, application packages, or configuration files submitted by developers and parsing them to obtain application metadata. Based on the submitted content, a standardized container image is generated through the build engine, and the build artifacts are output. In an isolated audit environment, the build artifacts undergo multi-dimensional audits, and the audit results are recorded. Approved application versions are registered in the application asset repository and marked as distributable. These multi-dimensional audits include: compatibility audits (forward and backward compatibility of service interfaces and communication protocols, verification of runtime dependency versions, container base images, and system configurations), security audits (performing image vulnerability scans, sensitive permission checks, and security baseline verification), resource configuration audits (checking runtime parameters such as resource requests, restrictions, probes, and port exposures), behavioral audits (verifying the application startup process, system calls, and network behavior), and application functionality audits (verifying the application's front-end page adaptability and interaction flow). Further audits may include static code defect detection, open-source component license compliance verification, and data privacy compliance checks. On-demand distribution and deployment phase: The access party browses the application asset library and selects the target application through the access party portal, and submits deployment parameters, including the operating environment, business configuration and expansion requirements, etc.; According to the deployment request, a logically isolated deployment unit is created for the access party. The deployment unit includes an independent namespace, configuration object and network access policy, and the deployment parameters are injected into the deployment unit. The approved image is pulled in the deployment unit and the service orchestration is completed. An independent access entry is generated for the deployment unit, and the target application is instantiated. The running status and metadata of the application instance are recorded. In the runtime intelligent operation and maintenance phase: continuously collect application-level, workload-level, and node-level runtime metrics, and execute automated scaling operations according to preset strategies, including application replica (Pod) scaling and node-level scaling based on cluster resource levels; detect runtime anomalies, including high latency, increased error rate, and resource anomalies, and perform alarm push, abnormal instance isolation or recovery, and other processing; synchronize the running status, scaling events, and anomaly records to the visualization monitoring module for viewing by different roles.

[0011] The present invention also provides an information service publishing and distribution system for performing the above-described methods, the system comprising: The developer portal module is used to receive application submission requests and collect application metadata; The image building module is used to execute the build process based on the submitted content and generate standardized container images. The application auditing module is used to perform compatibility, security, resource configuration, and behavior audits in an isolated environment and generate audit reports. The application asset repository module is used to store approved application versions and their metadata, and provides application query and version management capabilities; The access portal module is used by access parties to select applications, submit deployment parameters, and initiate deployment requests. The multi-tenant distribution and scheduling module is used to create deployment units, inject deployment parameters, allocate access points, and complete application instantiation. The intelligent operation and maintenance module is used to collect runtime metrics and perform scaling up and down, anomaly detection, and alarm handling. The visualization monitoring module is used to display the running status and event information in terms of application, access party, or resource dimensions.

[0012] The above modules can work together through event bus or interface calls to achieve closed-loop management of application review, listing, distribution and operation and maintenance.

[0013] The present invention also provides a computer-readable storage medium having stored thereon computer program instructions, which, when executed by a processor, cause the processor to perform the steps of the information service publishing and distribution method described above. Figure 1 System overall architecture diagram Figure 2 Application Trusted Listing Method Flowchart Figure 3 Flowchart of On-Demand Distribution and Deployment Method Detailed Implementation

[0014] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the specific embodiments of this invention will be further described below with reference to the accompanying drawings. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of this invention.

[0015] To clearly illustrate the technical solution of this invention and avoid ambiguity in terminology, the definitions of the core terms involved in this invention are explained below: Platform: refers to the information service publishing and distribution system described in this invention, which includes a developer portal module, an image building module, an application review module, an application asset library module, an access party portal module, a multi-tenant distribution and scheduling module, an intelligent operation and maintenance module, and a visual monitoring module, used to realize the automated review, isolated deployment, and operation management of applications; Access party: refers to the entity that requests to deploy and run an application instance, which selects an approved application version for deployment through the platform; Developers: refers to the entities that submit application code, application packages, or metadata and participate in the application review process; they are the developers and providers of the application. Multi-tenancy refers to the independent deployment of applications by multiple access parties on the same platform. Through logical isolation mechanisms, resources (computing, storage, network) and data are kept separate, ensuring the independence and security of each tenant's application operation. Deployment unit: refers to a logically isolated runtime environment created for a single access party, which includes at least the namespace, independent configuration object and network access policy in the container orchestration platform; Application assets: refer to application versions and their associated metadata that have passed multi-dimensional automated review and are stored in the application asset library for access parties to select and deploy; Runtime metrics: These refer to application-level, workload-level, and node-level performance and status data collected during the operation of application instances, which are used to trigger elastic scaling or alarms.

[0016] like Figure 1 As shown in the diagram, this invention represents the overall system structure and inter-module dependencies in a three-layer architecture diagram: "Instrumentation Layer → Core Module Layer → Interaction Role Layer," clearly illustrating the complete chain from "underlying support—core functionality—user interaction." To avoid cluttering the accompanying drawings, only the key components of the container orchestration platform directly related to this invention are shown.

[0017] In this embodiment, the relationships and main interactions between the three layers are as follows: The infrastructure layer provides runtime, orchestration, and storage capabilities. This layer typically includes container orchestration platforms (e.g., Kubernetes clusters), image repositories, load balancers / Ingress, metrics / monitoring endpoints, and message brokers. This infrastructure exposes its capabilities to the outside world through standardized interfaces. For example, it provides resource creation, query, and scheduling interfaces through the Kubernetes API Server; image pull interfaces through the Registry; runtime data exposure through metric endpoints (Prometheus or equivalent implementations); and external access points through Ingress / LoadBalancer. The core module layer implements the functional logic of this invention. This layer consists of eight modules as shown in the diagram (Developer Portal Module 101, Image Building Module 102, Application Review Module 103, Application Asset Library Module 104, Access Portal Module 105, Multi-tenant Distribution and Scheduling Module 106, Intelligent Operation and Maintenance Module 107, and Visual Monitoring Module 108). Each module is deployed on top of the infrastructure layer as a microservice or service component. Modules communicate asynchronously through message queues, and interaction between modules and the infrastructure layer is completed through standardized API interfaces. For example: the multi-tenant distribution and scheduling module 106 creates resources such as Namespace, Deployment, StatefulSet, Service, and Ingress by calling the Kubernetes API Server to achieve isolated deployment and access entry allocation; this module also initiates image pull requests to the image repository to complete the instantiation process; the image building module 102 pushes the build artifacts to the image repository and notifies the application audit module 103 of the build completion event through a standardized API interface; the application audit module 103 performs compatibility and behavior detection on the image in the isolated SandboxNamespace using the container runtime of the infrastructure, and writes the audit results back to the application asset repository module 104; the intelligent operation and maintenance module 107 pulls runtime data from the infrastructure's metric collection endpoints and triggers Pod-level or node-level scaling actions by calling the cluster's elastic scaling interface (such as the HPA interface or the cluster auto-scaling API) and coordinating with the multi-tenant distribution and scheduling module 106; The interaction role layer presents different user perspectives and operation entry points. This layer includes core business roles such as developers and access parties, who initiate upload, deployment, review, and operation and maintenance related operations through the developer portal module 101 and the access party portal module 105, respectively. The portal modules interact with the core module layer via REST / API and receive status feedback and alarm information from the visual monitoring module 108 and the intelligent operation and maintenance module 107, thereby completing the closed-loop interaction between roles and the system.

[0018] like Figure 2 The flowchart shown is a process for the trusted application upload method of the present invention. The method is based on the system architecture shown in Figure 1 and completes the trusted upload of the application through the automated collaboration of four core modules.

[0019] In step S11, the developer submits application data through the developer portal module 101. The developer portal module 101 performs format verification on the received upload request (verifying the integrity of the uploaded file and the compliance of the configuration file format). After the verification is successful, the key information contained in the upload request is parsed, specifically including: application basic information (application name, version number, icon), development language type (mainstream development languages ​​such as Golang, Python, Java, .Net, etc.), application related files (source code package, compiled binary package, image description file), dependency configuration files (pom.xml file for Java applications, requirements.txt file for Python applications, init.sql file for database initialization), service function type (front-end display service, back-end management service, business logic service), runtime environment dependency parameters (JDK version, database type and version, middleware type and version), and preset resource thresholds (CPU requirement value, memory requirement value, storage requirement value).

[0020] In step S12, the developer portal module 101 synchronizes the parsed key information to the image building module 102. The image building module 102 matches the standardized Dockerfile template corresponding to the development language type, installs the application's required dependent components according to the dependency configuration file, performs code compilation (in the case of source code upload), and image packaging operations to generate an application container image that conforms to the OCI standard. The image tag is named by the version number. The image building module 102 pushes the generated application container image to a private image repository (such as Harbor) for versioned storage through HTTPS protocol + OAuth2.0 authentication. After the push is completed, it returns the image storage address and push success status to the developer portal module, and at the same time synchronizes the image ready event to the application review module 103 through a message queue.

[0021] Step S13: After receiving the image ready event pushed by the message queue (including application ID, image storage address, and parsed key information), the application audit module 103 starts a multi-dimensional automated audit process in an independent container sandbox environment, which specifically includes the following steps: 1) Audit Environment Initialization: Application audit module 103 calls the K8s API to create a temporary isolated environment within the dedicated audit namespace. This environment features include: an independent runtime container, an independent database / cache instance (such as using an on-demand MySQL / Redis debugging environment), an independent log collection channel, and a mounted temporary storage volume; at the same time, it simulates the actual runtime environment of the application to deploy the application. 2) Multi-dimensional audit execution: Security scanning: Dependency vulnerability scanning and sensitive interface scanning are performed using automated tools: Dependency vulnerability scanning uses Snyk or Dependency-Check tools to detect high-risk CVE vulnerabilities in application dependency components; Sensitive interface scanning uses Swagger API Security Tester or Swagger API Exploit tools to traverse application interfaces and simulate access scenarios to identify interface risks such as unauthorized access and leakage of sensitive parameters. API Availability Check: Automatically construct API test cases, simulate normal access scenarios to execute API calls, and verify the API response status (such as HTTP 200 status code), return format (such as JSON field integrity), and core functionality availability; Resource usage detection: In simulated operation scenarios, real-time monitoring of application CPU usage, memory usage, and resource level changes ensures that resource consumption is within the platform's preset range; Application Functionality Validation: The application is automatically loaded in a simulated terminal environment (including different resolutions and operating systems), and predefined user interaction scripts are executed through a mobile automation framework to verify whether key functional processes (such as login, form submission, and button clicks) respond normally and whether interface elements are rendered correctly, ensuring the functionality and interaction consistency of the application on the target terminal. Version compliance check: Verify that the application dependency versions, compilation parameters, and configuration file formats conform to the platform's unified specifications to avoid distribution and deployment failures due to inconsistencies in specifications; 3) Review result processing: If there are no high-risk issues, the application is marked as "distributable" and synchronized to the application asset library module 104 to complete the entry into the library; if the review fails, feedback on rectification suggestions is provided to support the developer to optimize and resubmit.

[0022] In step S14, after receiving the inbound request, the application asset library module 104 classifies and stores information such as application metadata, image address, and audit report (structured data is stored in the database, and unstructured data is stored in object storage), completing the application trusted listing closed loop and providing a trusted asset foundation for subsequent on-demand distribution and deployment.

[0023] like Figure 3 The diagram shown is a flowchart of the on-demand distribution and deployment method of the present invention. The method is based on the system architecture shown in Figure 1. The core of the method is to achieve a closed-loop process of tenant self-configuration, isolated deployment, and independent access through the collaboration of the access portal module, the multi-tenant distribution and scheduling module and the K8s infrastructure.

[0024] Step S21: Application selection and deployment parameter submission. The access party accesses the list of distributable applications provided by the application asset library module 104 through the access party portal module 105, filters and selects the target application and its corresponding version based on business requirements; after selection, the access party fills in the custom deployment parameters, including: deployment environment selection (test environment / production environment), resource quota configuration (required values ​​for CPU, memory, and storage, not exceeding the platform's preset upper limit), and business configuration parameters (custom domain name, callback address); after the parameters are filled in, the access party submits the deployment request, and the access party portal module 105 receives the request.

[0025] Step S22, Deployment Request Verification and Forwarding: After receiving the deployment request, the access portal module 105 performs dual verification: 1) Compliance verification: Verify whether resource quotas and parameter formats are compliant, and whether the target application is in a "distributable state"; 2) Permission verification: Based on the RBAC permission model, verify whether the access party has the deployment permission for the target application; If the verification fails, an error message is returned and resubmission is supported after parameter modification; if the verification passes, the deployment request is encapsulated into a standardized instruction (including access party ID, application ID, version number, image address, and custom parameters) and forwarded to the multi-tenant distribution and scheduling module 106 through a message queue.

[0026] Step S23: Multi-tenant isolation deployment unit creation. After receiving the deployment instruction, the multi-tenant distribution and scheduling module 106 calls the K8s API Server to create the multi-tenant isolation deployment unit. 1) Dedicated namespace creation: Generate a namespace according to unique rules and configure resource quota limits that match the access party's request; 2) Configuration object creation: Non-sensitive business configurations are stored using ConfigMap, and sensitive configurations are stored using encrypted Secrets; 3) Network isolation policy configuration: Create isolation rules through network plugins to prohibit the access party's namespace from communicating with other access parties, and only open necessary intra-cluster service access permissions, while configuring rate limiting policies.

[0027] Step S24, Application Image Pulling and Instantiation: After the isolated deployment unit is created, the multi-tenant distribution and scheduling module 106 performs application instantiation. 1) Image Pull: Based on the application image address, pull the target version image from the private image repository through authentication configuration; 2) Application Orchestration: Generate K8s Deployment / StatefulSet configurations, inject environment variables, configuration parameters and health probe configurations, and start Pod instances; 3) Configuration adaptation: The configuration parameters are automatically loaded during Pod startup to adapt the application to business requirements.

[0028] Step S25: Independent access entry configuration and result feedback. After the application Pod instance is started and ready, the multi-tenant distribution and scheduling module 106 configures the independent access entry: creates Ingress rules, assigns a dedicated access domain name and binds an SSL certificate to ensure encrypted access; summarizes the deployment results (access address, running status, etc.) and synchronizes them to the access portal module 105 through a message queue; the portal module visualizes the results for the tenants and supports the access party to perform subsequent operations such as restart, stop, and destroy, completing the on-demand distribution and deployment closed loop.

[0029] In a preferred embodiment, the information service publishing and distribution system of the present invention is used to realize the complete process of a game application from submission, review, and listing, to deployment initiated by the access party and final intelligent operation and maintenance. This embodiment aims to illustrate the typical working mode of the method of the present invention, so as to further demonstrate the actual technical effect produced by the collaboration of various modules. Its process is based on the overall system architecture diagram shown in Figure 1.

[0030] In this embodiment, the developer uploads the game application code package and application metadata (including runtime environment requirements, resource quota suggestions, health check methods, etc.) through the developer portal module 101. After the developer portal module 101 completes the metadata format verification (verifying field integrity and parameter format compliance), it directly sends a submission instruction (including developer ID, code storage path, service type, and metadata information) to the image building module 102.

[0031] After receiving the submission command, the image building module 102 pulls the corresponding source code from the code repository and builds a standardized container image according to the platform's pre-built game application building template (adapted to the compilation environment of game engines such as Unity and Unreal). After the image is built, it is named according to the rule of "Developer ID - Service Role Name - Version Number", pushed to the private image repository, and directly sends an image ready command (Developer ID, image storage address) to the application review module 103.

[0032] Upon receiving the image ready instruction, application audit module 103 calls the Kubernetes API to create a temporary isolated Pod in the platform-specific audit namespace, starts an instance of the image, and the required middleware instances. The audit module then uses built-in detection plugins to perform multi-dimensional automated audits sequentially: 1) Security vulnerability scanning: Scan for high-risk CVE vulnerabilities in dependent components using the Dependency-Check tool, and detect unauthorized access risks to game interfaces using the Swagger API Security Tester; 2) Interface availability check: Automatically construct dedicated API test case Pods to simulate normal access scenarios and execute standardized interface calls required by the platform to verify their response status, return format, and functional availability; 3) Resource Limit Verification: Verify whether the preset thresholds for CPU and memory are within the platform's allowable range to ensure that the game's resource requirements are reasonable; 4) Application Function Review: For applications containing web front-end or H5 game interfaces, load game login verification and automatically execute predefined user interaction scripts. Capture page rendering status, JavaScript exception logs and network request responses in real time to verify whether interface elements are clickable, whether business processes are complete, and whether there are any front-end function anomalies such as white screen or script blocking. 5) Runtime Behavior Detection: Simulate game startup and concurrent access scenarios to monitor for violations such as sensitive information leakage and unauthorized external connections; If all the above multi-dimensional reviews are passed, the application review module 103 will synchronize the review results, application metadata, and image address to the application asset library module 104, and mark the application version as "distributable"; otherwise, the review module will return the specific reason for failure (such as the absence of a standardized interface, status code 404) to the developer portal module 101 so that the developer can fix it and resubmit.

[0033] Once an application is listed as "distributable," the access party (such as a game operation platform) can browse the list of game applications in the application asset library module 104 through the access party portal module 105, and filter and select the target application version. In this embodiment, the access party fills in deployment parameters such as business name, access method (HTTP / HTTPS), custom domain name, and SSL certificate, and submits a distribution deployment request.

[0034] After receiving the deployment request, the access portal module 105 performs compliance and permission checks. Once the checks are passed, the deployment request is forwarded to the multi-tenant distribution and scheduling module 106.

[0035] The multi-tenant distribution and scheduling module 106 creates an independent logically isolated deployment unit (i.e., a dedicated namespace) for the access party based on its identity information. Combined with the configuration submitted by the access party, it generates corresponding Kubernetes native resources (Deployment, StatefulSet, Service, ConfigMap, Secret, and Ingress). Subsequently, the resource creation is completed through the Kubernetes API Server. Among them, ConfigMap stores non-sensitive environment variable configurations, Secret stores sensitive information such as encrypted database connection strings, and Ingress configures the independent access domain name for the game application and binds an SSL certificate to ensure secure transmission.

[0036] After the Kubernetes resources are created, the platform automatically pulls the approved game application image from the private image repository, starts the application Pod according to the Deployment or StatefulSet description, and generates an independent access entry (such as "game.example.com / v1.0.0 / ") based on the Ingress or load balancer configuration for end users to access.

[0037] After the game application is successfully deployed, the intelligent operation and maintenance module 107 continuously acquires multi-dimensional operation metrics through metric collection endpoints (including application tracking points, K8sMetrics Server, and Prometheus): 1) Application-level metrics: QPS (Queries Per Second), error rate (error rate of game login / recharge interface); 2) Container-level metrics: Pod's CPU / memory utilization and disk I / O rate; 3) Node-level metrics: Cluster node resource level, network bandwidth utilization; The intelligent operation and maintenance module 107 uses the built-in policy engine to evaluate indicator data and determine whether elastic scaling operations need to be performed.

[0038] For example, in this embodiment, when the system detects that the average CPU utilization of the game application continues to exceed 75% and the request latency (P95) rises to more than 500ms, the intelligent operation and maintenance module 107 automatically calls the K8s HPA interface to trigger horizontal scaling of the Pod (the number of replicas increases from 2 to 4); when the load decreases (CPU utilization is stable below 30%) and continues for 30 minutes, the system automatically reclaims the excess Pod replicas (reducing them from 4 to 2), realizing on-demand resource allocation and cost optimization.

[0039] In one alternative implementation, the operation and maintenance steps further include an automatic handling mechanism for abnormal instances.

[0040] Specifically, when the system detects that a newly deployed application instance continues to operate abnormally within a preset time window, it can identify the abnormal operating state as a predefined abnormal pattern and automatically trigger the abnormal handling process, including: logically isolating the abnormal instance, rolling back to the previous stable version, and triggering an alarm and automatically creating a problem ticket for operation and maintenance personnel to follow up.

[0041] Furthermore, during the distribution and deployment phase, an application version update trigger mechanism can be provided: when an access party selects a new version of an already deployed application through the access party portal, the system automatically generates an update request, which is then executed by the multi-tenant distribution and scheduling module. Update methods may include rolling updates, blue-green / canary releases, and an automatic rollback mechanism in case of anomalies in the new version, ensuring continuous service availability and secure and reliable version upgrades.

[0042] The visualization monitoring module 108 displays operational metrics, elastic scaling events, anomaly handling information, and deployment status to the access party in real time through a graphical interface, enabling transparent management of the game application's operational status. It also supports the access party in manually triggering operations such as restarting and uninstalling.

[0043] The above description is merely a specific embodiment of the present invention, intended to illustrate the technical solution of the present invention, and not to limit the scope of protection of the present invention. Those skilled in the art can easily conceive of various equivalent modifications, substitutions, or combinations within the technical scope disclosed in the present invention, and these modifications, substitutions, and combinations should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the appended claims.

Claims

1. An information service publishing and distributing method, characterized by, The method comprises the following steps: S1, a release preparation step: receiving application-related files and application metadata submitted by developers and performing format and integrity checking; S2, an image building step: generating a standardized container image based on a pre-set building template or building pipeline and generating identifiable metadata for the image, and then pushing the image to an image repository; S3, an audit and listing step: performing multi-dimensional automated auditing on the image or application in a temporarily isolated audit environment, and registering the application and its version information as distributable application assets when the auditing is qualified; S4, a distribution request step: receiving a deployment request initiated by an access party, the request including an application identifier to be deployed, a target version, and deployment parameters, and performing permission and compliance checking on the request; S5, an isolated deployment step: creating a logically isolated deployment unit for the access party and generating native resources of a container orchestration platform inside the unit to complete application instantiation and configure an independent access portal for the deployment unit; S6, a running and maintenance step: continuously collecting application-level, workload-level, and cluster-level running indicators, and performing multi-level elastic scaling and abnormal handling based on pre-set strategies, while recording and displaying running status and alarm information.

2. The method of claim 1, wherein, The container image generated in step S2 is associated with metadata for identification, which includes but is not limited to application identifier, version number, build timestamp, signature, or tamper-proof digest; the metadata is used for version verification and integrity checking in steps S3 and S5.

3. The method of claim 1, wherein, The multi-dimensional automated auditing in step S3 includes at least two or more of the following: (a) compatibility check, for checking the adaptability of runtime dependencies, base images, and target platforms; (b) static security analysis and third-party dependent component vulnerability detection, for identifying security defects or known vulnerabilities in source code and dependent components; (c) dynamic security scanning or penetration testing, for simulating potential unauthorized access, unauthorized operation, or sensitive information leakage behavior; (d) resource configuration and performance evaluation, including but not limited to startup time, memory and CPU usage, and resource change trend; (e) behavior and network boundary detection, including monitoring of external communication behavior, sensitive resource access, and running behavior characteristics; (f) privacy and compliance check, for checking whether the data access logic and user authorization mechanism comply with the pre-set privacy protection or compliance strategy; (g) interface contract and API compatibility check, for verifying whether the interface behavior is compatible with the existing interface baseline; (h) license and third-party component compliance check, for checking whether the use of third-party components complies with the pre-set license policy; (i) application function auditing, for checking the interface display effect and pre-set interaction operation execution result of the application in the automated running environment 4. The method of claim 1, wherein, The logically isolated deployment unit created in step S5 is a namespace, virtual cluster, or other equivalent logically isolated domain; the independent access portal is a dedicated domain name, independent routing, or independent load balancing address, and supports encrypted transmission.

5. The method of claim 1, wherein, When the step S3 fails, the system will feedback the audit failure reason and the recommended repair items to the developer portal, supporting the developer to modify and re-submit, and re-trigger the processing flow of steps S2 to S3.

6. The method of claim 1, wherein, The elastic scaling of step S6 includes at least one or more of the following levels: (a) instance (Pod) horizontal scaling based on application level indicators; (b) vertical scaling or Pod resource adjustment based on workload level or single node resource pressure; (c) node level scaling or recycling (including starting or releasing computing nodes or requesting elastic instances of cloud services) based on cluster resource water level and scheduling strategy; (d) event-driven elastic scaling triggered by external event sources (such as message queue backlog, database change stream or custom indicators), which realizes the on-demand start and stop of workloads through event-driven scaling controller 7. The method of claim 1, wherein, In step S6, when it is detected that the new deployment instance appears a pre-defined abnormal pattern within a pre-set time window, the system automatically triggers any one or combination of the following operations: isolating the abnormal instance, rolling back to the last stable version, triggering an alarm and creating a problem ticket.

8. An information service publishing, distributing system, characterized by comprising: Comprise: a developer portal module, an image building module, an application audit module, an application asset library module, an access party portal module, a multi-tenant distribution scheduling module, an intelligent operation and maintenance module, and a visual monitoring module; the modules work together to realize the method steps of claim 1.

9. The system of claim 8, wherein, The multi-tenant distribution scheduling module also generates a configuration storage component (for storing non-sensitive environment variables) and a sensitive information storage component (for storing sensitive configurations in ciphertext) when generating container orchestration platform native resources, and injects sensitive information into the target deployment unit in a restricted manner during deployment.

10. The system of claim 8, wherein, The audit logic of the application audit module and the elastic scaling strategy of the intelligent operation and maintenance module correspond to the method steps of claims 2 and 6.

11. The system of claim 8, wherein, The modules interact asynchronously / synchronously through an event bus or standardized REST / GRPC interface, and the event bus is used to carry build task events, audit events, deployment events, and alarm events to ensure high cohesion and low coupling between modules.

12. The system of claim 8, wherein, The image building module supports pluggable builders based on build templates, and generates an unalterable build product digest during the build process for step S3 to verify that the image has not been tampered with during the audit.

13. The system of claim 8, wherein, The multi-tenant distribution scheduling module supports Canary / Blue-Green release according to access party policies, and can automatically roll back to the last stable version when the release fails.

14. A computer-readable storage medium having stored thereon instructions executable by a processor, the instructions, when executed, causing the processor to perform the steps of the information service publishing and distribution method of any one of claims 1 to 7.

Images