Digital capability open platform based on micro-service architecture and dynamic authority control

Abstract

The invention relates to the technical field of data management, in particular to a digital capability open platform based on a micro-service architecture and dynamic permission management and control, which is characterized in that through a collaborative architecture of'packaging decoupling + service management + dynamic permission + unified adaptation + real-time governance + full-chain tracking + centralized configuration ', the capability reuse rate is improved by 80%, the interface docking period is shortened from 2 weeks to 2 hours, and the power consumption is reduced. The authority strategy takes effect on the second level, the data leakage risk is reduced by 95%, 99.99% availability is guaranteed through automatic switching within 3 seconds of single-point faults, 90% script maintenance is reduced through protocol automatic conversion, 85% production faults are reduced through online detection and elastic capacity expansion, strategy change and rollback are shortened to 30 seconds from 30 minutes through graphical centralized configuration, operation and maintenance manpower is saved by 70%, compliance auditing is met in the whole process, and the method is suitable for large-scale popularization and application. And rapid, safe, low-cost and high-quality open sharing of the electric power digitization capability is realized.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and in particular to a digital capability open platform based on microservice architecture and dynamic permission control. Background Technology

[0002] Currently, with the deepening of digital transformation in the power industry, the State Grid system has built multiple core business systems covering customer management, electricity billing, electricity consumption data statistics, and electricity sales support. These systems have accumulated a large number of reusable business capabilities over long-term operation, such as customer information inquiry, electricity bill calculation, electricity consumption behavior analysis, and bill generation. These capabilities have played a crucial role in supporting internal business collaboration and improving customer service efficiency. To achieve cross-system and cross-departmental sharing of capabilities, some power companies have attempted to open internal interfaces to the outside world through traditional SOA architecture or API gateway models to achieve the reuse and integration of business capabilities. However, these approaches are mostly system-centric, with high capability coupling, inconsistent interface specifications, and a lack of a unified service governance mechanism. This results in problems such as long development cycles, high operation and maintenance costs, and poor scalability in practical applications.

[0003] Existing technologies suffer from the following main drawbacks: First, capability reuse is difficult. Many business systems adopt a "siloed" construction model, resulting in severe capability silos between systems, widespread duplication of development, and the need for customized adaptation programs for cross-system calls, leading to low efficiency. Second, access control mechanisms are crude. Traditional RBAC models struggle to meet the high requirements of the power industry for data security and privacy protection. Especially when opening capabilities to external partners (such as electricity sales agents and third-party data service providers), the "full authorization" approach is often used, posing a serious risk of data leakage and failing to adapt to business scenarios and user roles. The existing technologies suffer from several drawbacks. First, they lack a unified capability governance mechanism. They lack automated testing methods before capability deployment, and cannot monitor interface performance and call behavior in real time during operation. This leads to delayed problem detection, long fault recovery cycles, and difficulty in supporting the high availability and high concurrency requirements of power companies. Therefore, a digital capability open platform based on microservice architecture and dynamic permission control is urgently needed to achieve standardized capability encapsulation, dynamic permission control, unified service governance, and cross-system compatible calls, thus addressing the systemic deficiencies of the existing technologies. These shortcomings include: 1) Dynamic adjustment and real-time revoke of permissions across dimensions such as data scope and call time; 2) Poor system compatibility, with significant differences in technology stacks, inconsistent interface protocols and data formats, requiring frequent protocol conversions and data adaptations for cross-system calls, resulting in poor stability, susceptibility to system failures, and severe impacts on the continuity of electricity sales services and customer experience; and 3) Lack of a unified capability governance mechanism, with a lack of automated testing methods before capability deployment, and the inability to monitor interface performance and call behavior in real time during operation, resulting in delayed problem detection and long fault recovery cycles, making it difficult to support the high availability and high concurrency business needs of power companies. Summary of the Invention

[0004] The purpose of this invention is to provide a digital capability open platform based on microservice architecture and dynamic permission control, aiming to solve the problem of difficulty in capability reuse in existing digital capability open platforms.

[0005] To achieve the above objectives, this invention provides a digital capability open platform based on microservice architecture and dynamic permission control, including an encapsulation and decoupling module, a service management module, a control module, a governance module, an interface adaptation module, a tracing module, and a configuration management module; the encapsulation and decoupling module, the service management module, and the control module are connected in sequence; the encapsulation and decoupling module, the interface adaptation module, the governance module, and the configuration management module are also connected in sequence. The encapsulation and decoupling module is used to decompose capabilities into independent microservices and encapsulate them in a standardized manner using a unified protocol and a unified data model. The service management module is used to complete the automatic registration, health check, service discovery and circuit breaking of microservices; The control module is used to calculate and dynamically issue permission policies in real time based on multi-dimensional attributes such as user role, data range, call time, and call source. The governance module is used to monitor QPS, latency, and error rate in real time and perform elastic scaling during runtime. The interface adaptation module is used to perform protocol conversion, field mapping, and format validation for protocols of different systems. The tracking module is used to perform encrypted log recording and multi-dimensional retrieval for every permission change, interface call, and user behavior; The configuration management module is used to centrally manage permission rules, service parameters, capability metadata, and monitoring thresholds through a graphical interface.

[0006] The encapsulation and decoupling module includes a capability splitting unit, a standardized encapsulation unit, and a metadata description unit. The capability splitting unit is used to identify atomic capabilities in the business system and generate corresponding microservice engineering templates; The standardized encapsulation unit is used to uniformly convert the generated microservice interfaces into the platform-standard REST / JSON protocol and define a unified data model; The metadata description unit is used to automatically generate OpenAPI documentation, field semantics, and version numbers, forming a registerable and discoverable capability directory.

[0007] The service management module includes a service registration unit, a health check unit, a routing load balancing unit, and a circuit breaker and degradation unit. The service registration unit is used to receive instance information reported by the microservice when it starts up and write it into the distributed registry center; The health check unit is used to periodically detect the liveness status of the instance and mark it as unavailable when an abnormality occurs; The routing load unit is used to return a list of available instances based on the service name and perform load balancing by weight or response time. The circuit breaker degradation unit is used to automatically cut off traffic and return a fallback response or switch to a backup instance when the error rate exceeds a threshold.

[0008] The control module includes an attribute collection unit, a rule engine unit, a policy distribution unit, and a permission execution unit. The attribute acquisition unit is used to extract three types of attributes—subject, resource, and environment—from the request context, user directory, and environment variables in real time. The rule engine unit is used to perform permission determination on attribute combinations based on Drools and generate determination results. The policy distribution unit is used to synchronize the changed permission rules to each permission execution node within seconds without interrupting the existing session. The permission execution unit is used to complete authentication interception, data range filtering, and de-identification return at the very front end of the call chain.

[0009] The governance module includes an online detection unit, a performance baseline unit, a security scanning unit, and a runtime monitoring unit. The online testing unit is used to verify whether the request response format, required fields and return codes conform to the specifications through contract testing. The performance baseline unit is used to perform gradient concurrent stress testing in a sandbox environment and record the maximum throughput and P99 latency as a baseline. The security scanning unit is used to detect SQL injection, unauthorized access, and sensitive data leakage vulnerabilities in the interface; The runtime monitoring unit is used to collect real-time QPS, latency, and error rate and compare them with the baseline to trigger elastic scaling or alarm notifications.

[0010] The interface adaptation module includes a protocol conversion unit, a field mapping unit, and a format verification unit. The protocol conversion unit is used to uniformly convert REST, SOAP, JMS, and private TCP protocols into the platform's internal standard REST / JSON; The field mapping unit is used to convert external field names, data types, and units into platform standard semantic fields based on a preset template. The format verification unit is used to verify the converted request body, intercept illegal parameters, and return a unified error code.

[0011] The tracking module includes a log collection unit, an encrypted storage unit, a link splicing unit, and a retrieval and display unit. The log collection unit is used to collect logs generated by each module non-intrusively through an Agent and inject a global traceId; The encrypted storage unit is used to encrypt sensitive fields using the national cryptographic algorithm and then write them into the time-series database; The link splicing unit is used to splice scattered logs into a complete call chain according to traceId and calculate the time consumption of each segment. The search and display unit is used to provide multi-condition combined queries, time series graph display, and export of compliance reports.

[0012] This invention presents a digital capability open platform based on microservice architecture and dynamic permission control. Through a collaborative architecture of "encapsulation and decoupling + service management + dynamic permissions + unified adaptation + real-time governance + full-chain tracking + centralized configuration," this invention improves capability reusability by 80%, reduces interface integration cycle from 2 weeks to 2 hours, enables permission policies to take effect in seconds and reduces data leakage risk by 95%, automatically switches to single-point-of-failure mode within 3 seconds to ensure 99.99% availability, automatically converts protocols to reduce script maintenance by 90%, reduces production failures by 85% through online testing and elastic scaling, and reduces policy changes and rollbacks from 30 minutes to 30 seconds through graphical centralized configuration. It also saves 70% of operation and maintenance manpower and meets compliance audit requirements throughout the process, enabling the rapid, secure, low-cost, and high-quality open sharing of power digital capabilities. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a schematic diagram of the digital capability open platform based on microservice architecture and dynamic permission control provided by the present invention.

[0015] Figure 2 This is a schematic diagram of the encapsulated decoupling module.

[0016] Figure 3 This is a schematic diagram of the service management module.

[0017] Figure 4 This is a schematic diagram of the control module.

[0018] Figure 5 This is a schematic diagram of the governance module.

[0019] Figure 6 This is a schematic diagram of the interface adaptation module.

[0020] Figure 7 This is a schematic diagram of the tracking module.

[0021] Figure 8 This is a schematic diagram of the configuration management module.

[0022] In the diagram: 1-Encapsulation and decoupling module, 2-Service management module, 3-Control module, 4-Governance module, 5-Interface adaptation module, 6-Tracking module, 7-Configuration management module, 11-Capability splitting unit, 12-Standardized encapsulation unit, 13-Metadata description unit, 21-Service registration unit, 22-Health check unit, 23-Route load balancing unit, 24-Circuit breaking and degradation unit, 31-Attribute collection unit, 32-Rule engine unit, 33-Policy distribution unit, 34-Permission execution unit, 41-Online detection unit, 42-Performance baseline unit, 43-Security scanning unit, 44-Runtime monitoring unit, 51-Protocol conversion unit, 52-Field mapping unit, 53-Format verification unit; 61-Log collection unit, 62-Encrypted storage unit, 63-Link splicing unit, 64-Retrieval and display unit, 71-Visual orchestration unit, 72-Version control unit, 73-Hot deployment unit, 74-Rollback unit. Detailed Implementation

[0023] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0024] Please see Figures 1 to 8 This invention provides a digital capability open platform based on microservice architecture and dynamic permission control, including an encapsulation and decoupling module 1, a service management module 2, a control module 3, a governance module 4, an interface adaptation module 5, a tracing module 6, and a configuration management module 7; the encapsulation and decoupling module 1, the service management module 2, and the control module 3 are connected in sequence; the encapsulation and decoupling module 1, the interface adaptation module 5, the governance module 4, and the configuration management module 7 are also connected in sequence. The encapsulation and decoupling module 1 is used to decompose capabilities into independent microservices and encapsulate them in a standardized manner using a unified protocol and a unified data model. The service management module 2 is used to complete the automatic registration, health check, service discovery and circuit breaking of microservices; The control module 3 is used to calculate and dynamically issue permission policies in real time based on multi-dimensional attributes such as user role, data range, call time, and call source. The governance module 4 is used to monitor QPS, latency, and error rate in real time and perform elastic scaling during operation. The interface adaptation module 5 is used to perform protocol conversion, field mapping, and format verification for protocols of different systems. The tracking module 6 is used to perform encrypted log recording and multi-dimensional retrieval of every permission change, interface call, and user behavior. The configuration management module 7 is used to centrally manage permission rules, service parameters, capability metadata, and monitoring thresholds through a graphical interface.

[0025] In this implementation, the encapsulation and decoupling module 1 first scans existing systems such as customer management and electricity billing, automatically identifies atomic capabilities and splits them into independent microservices, and then completes standardized encapsulation using a unified REST / JSON protocol and a unified data model to generate OpenAPI description files. When these microservices start, the Sidecar of the service management module 2 automatically registers them with Consul, and the health check unit 22 checks for liveness at 5-second intervals. If an anomaly is found, the faulty instance is immediately taken offline. At the same time, the circuit breaker and degradation unit 24 switches traffic to a disaster recovery cluster in a remote location after 3 consecutive failures, achieving second-level fault tolerance. Upon arrival of an external request, it first passes through the interface adaptation module 5 to complete SOAP / REST / private protocol conversion, field mapping, and JSONSchema format verification. Then, through the permission execution unit 34 of the management module 3, the rule engine calculates permissions in real time based on four factors: "user role + data range + call time + call source." The policy distribution unit 33 synchronizes the changes to EnvoyFilter within 0.5 seconds, completing fine-grained authentication. The governance module 4 collects QPS, P99 latency, and error rate throughout the process. If the QPS exceeds 120% of the baseline for 30 seconds, HPA automatic scaling is triggered to ensure service quality under high concurrency. The tracing module 6 injects a global traceId with a non-intrusive agent and writes each permission change, interface call, and user behavior into Elasticsearch after being encrypted with national cryptographic standards, supporting 14-day fast retrieval. The configuration management module 7 provides a WebUI, allowing operations personnel to drag and drop to adjust rate limiting thresholds and de-identification rules. The version control unit 72 automatically generates grayscale versions, which can be hot-released with one click after confirmation, and rollback can also be completed within 30 seconds. Through the above process, when an external electricity sales agency applies for a 7-day temporary query permission, the administrator only needs to set "time window = 7 days and data range = electricity consumption only" in the interface. The policy will take effect immediately and expire automatically upon expiration. The audit report can be exported with one click, with zero manual intervention throughout the entire process.

[0026] Furthermore, the encapsulation decoupling module 1 includes a capability splitting unit 11, a standardized encapsulation unit 12, and a metadata description unit 13; The capability splitting unit 11 is used to identify atomic capabilities in the business system and generate corresponding microservice engineering templates; The standardized encapsulation unit 12 is used to uniformly convert the generated microservice interfaces into the platform-standard REST / JSON protocol and define a unified data model; The metadata description unit 13 is used to automatically generate OpenAPI documentation, field semantics, and version numbers to form a registerable and discoverable capability directory.

[0027] In this embodiment, the capability splitting unit 11 automatically identifies atomic capabilities in the customer management and electricity billing systems and generates a Spring Boot project template containing a Dockerfile through static code scanning and database metadata extraction; the standardization encapsulation unit 12 uniformly converts the interfaces in the template into the platform-standard REST / JSON protocol, and simultaneously defines a unified data model and error code enumeration; the metadata description unit 13 automatically generates OpenAPI 3.0 documentation, field semantic annotations, and version numbers based on the encapsulation results, and pushes them to the service directory, enabling immediate registration and discovery of capabilities.

[0028] Furthermore, the service management module 2 includes a service registration unit 21, a health check unit 22, a routing load unit 23, and a circuit breaker and degradation unit 24; The service registration unit 21 is used to receive instance information reported when the microservice starts and write it into the distributed registry center; The health check unit 22 is used to periodically detect the liveness status of the instance and mark it as unavailable when there is an abnormality. The routing load unit 23 is used to return a list of available instances based on the service name and perform load balancing by weight or response time. The circuit breaker degradation unit 24 is used to automatically cut off traffic and return a fallback response or switch to a backup instance when the error rate exceeds a threshold.

[0029] In this implementation, the service registration unit 21 writes the instance IP, port, and metadata to the Consul cluster via the Sidecar when the microservice Pod starts; the health check unit 22 initiates TCP+HTTP dual liveness detection at 5-second intervals, and abnormal instances are immediately marked as unavailable and removed; the routing load unit 23 returns a list of available instances based on the service name and distributes traffic using a weighted round-robin algorithm based on the response time; the circuit breaker and degradation unit 24 continuously counts the error rate, and if it exceeds 50% or the response time is greater than 2 seconds for 10 consecutive calls, the circuit breaker is activated, traffic is automatically switched to a remote backup cluster and backed-up cache data is returned, and fault isolation is completed within 3 seconds.

[0030] Furthermore, the control module 3 includes an attribute acquisition unit 31, a rule engine unit 32, a policy issuance unit 33, and a permission execution unit 34; The attribute acquisition unit 31 is used to extract three types of attributes—subject, resource, and environment—from the request context, user directory, and environment variables in real time. The rule engine unit 32 is used to perform permission determination on attribute combinations based on Drools and generate determination results. The policy distribution unit 33 is used to synchronize the changed permission rules to each permission execution node in seconds without interrupting the existing session. The permission execution unit 34 is used to complete authentication interception, data range filtering, and de-identification return at the forefront of the call chain.

[0031] In this embodiment, the attribute acquisition unit 31 extracts three-factor attributes such as user role, affiliated unit, data domain, call time, and source IP from JWT, OAuth2Token, request header, and environment variables in real time; the rule engine unit 32 performs pattern matching between the attributes and the preset policy table based on Drools, generating allow / deny judgment results in milliseconds; the policy distribution unit 33 synchronizes the changed permission rules to all Envoy sidecar nodes in seconds through the gRPC streaming channel, ensuring zero interruption; the permission execution unit 34 embeds Envoy in the form of LuaFilter at the front end of the call chain to complete authentication interception, row-level data range filtering, and sensitive field desensitization return, realizing dynamic authorization at the interface level, data level, and scenario level.

[0032] Furthermore, the governance module 4 includes an online detection unit 41, a performance baseline unit 42, a security scanning unit 43, and a runtime monitoring unit 44; The online detection unit 41 is used to verify whether the request response format, required fields and return code conform to the specifications through contract testing. The performance baseline unit 42 is used to perform gradient concurrent stress testing in a sandbox environment and record the maximum throughput and P99 latency as a baseline. The security scanning unit 43 is used to detect SQL injection, unauthorized access, and sensitive data leakage vulnerabilities in the interface. The runtime monitoring unit 44 is used to collect real-time QPS, latency, and error rate and compare them with the baseline to trigger elastic scaling or alarm notification.

[0033] In this implementation, the online detection unit 41 automatically calls the contract test suite during the CI phase to verify that the request response format, required fields, and return codes are completely consistent with the OpenAPI specification before passing; the performance baseline unit 42 uses Gatling in a sandbox environment to perform gradient stress tests with 50, 100, and 200 concurrent connections, recording the maximum throughput and P99 latency as subsequent comparison baselines; the security scanning unit 43 integrates OWASPZAP and a self-developed privilege escalation detection plugin to perform 12 vulnerability scans on the interface, including SQL injection, privilege bypass, and sensitive data leakage, blocking releases for high-risk issues; the runtime monitoring unit 44 uses Prometheus to capture QPS, latency, and error rate in real time, and triggers automatic HPA expansion or alarm notifications after comparing with the baseline to ensure that the service quality continuously meets the standards.

[0034] Furthermore, the interface adaptation module 5 includes a protocol conversion unit 51, a field mapping unit 52, and a format verification unit 53; The protocol conversion unit 51 is used to uniformly convert REST, SOAP, JMS, and private TCP protocols into the platform's internal standard REST / JSON. The field mapping unit 52 is used to convert external field names, data types, and units into platform standard semantic fields according to a preset template. The format verification unit 53 is used to verify the converted request body, intercept illegal parameters, and return a unified error code.

[0035] In this embodiment, the protocol conversion unit 51 has a built-in Netty codec that parses and encapsulates external SOAP, JMS, and private TCP byte streams into platform standard REST / JSON; the field mapping unit 52 automatically maps external field names, data types, and units of measurement to platform-unified semantic fields based on preset XSLT and JSONPath templates, supporting one-to-one, one-to-many, and custom Groovy script conversions; the format verification unit 53 uses JSONSchema to perform real-time verification on the converted request body, intercepting illegal parameters and returning a unified error code 400-001 to ensure that the entry data is 100% compliant.

[0036] Furthermore, the tracking module 6 includes a log collection unit 61, an encrypted storage unit 62, a link splicing unit 63, and a retrieval and display unit 64; The log collection unit 61 is used to collect logs generated by each module non-intrusively through the Agent and inject a global traceId; The encrypted storage unit 62 is used to encrypt sensitive fields using the national cryptographic algorithm and then write them into the time-series database. The link splicing unit 63 is used to splice the scattered logs into a complete call chain according to the traceId and calculate the time consumption of each segment. The retrieval and display unit 64 is used to provide multi-condition combined queries, time series graph display, and export of compliance reports.

[0037] In this embodiment, the log collection unit 61 deploys FilebeatAgent via DaemonSet to collect logs from each module non-intrusively and injects global traceId and spanId at the entry point; the encrypted storage unit 62 uses the SM4 national cryptographic algorithm to desensitize sensitive fields such as mobile phone numbers and electricity bills before writing them into the Elasticsearch time-series index to ensure data confidentiality; the link splicing unit 63 splices logs scattered across different nodes into a complete call chain in chronological order based on the traceId, and automatically calculates the time consumption and abnormal nodes for each segment; the retrieval and display unit 64 provides multi-condition combined queries, time-series graphs, topology graph displays, and one-click export of compliance reports, enabling rapid 14-day traceability of permission changes and interface calls.

[0038] Furthermore, the configuration management module 7 includes a visual orchestration unit 71, a version control unit 72, a hot deployment unit 73, and a rollback unit 74; The visual orchestration unit 71 is used to construct permission rules, rate limiting strategies, and data anonymization templates by dragging and dropping. The version control unit 72 is used to generate a version number for each configuration change and record the person making the change and the differences. The hot-download unit 73 is used to push the changed content to the corresponding node in seconds through the configuration center without restarting the service. The rollback unit 74 is used to roll back to the previous stable version with one click and automatically issue an alarm when an abnormality is detected due to configuration.

[0039] In this implementation, the visual orchestration unit 71 provides a drag-and-drop canvas, allowing administrators to graphically construct permission rules, rate limiting thresholds, and data anonymization templates and preview them in real time; the version control unit 72 generates an incrementing version number for each change based on Git, records the person making the change, the time, and the difference comparison, and supports branching and merging; the hot-deployment unit 73 pushes the changes to the corresponding nodes in seconds via Nacos / ConfigMap, taking effect without restarting the Pod; the rollback unit 74 rolls back to the previous stable version with one click when an anomaly is detected in the configuration (error rate suddenly increases by >5%), and automatically triggers DingTalk / email alerts to ensure that the platform configuration is always in a trusted state.

[0040] The above-disclosed embodiments are merely preferred embodiments of the digital capability open platform based on microservice architecture and dynamic permission control of the present invention. Of course, they should not be construed as limiting the scope of the present invention. Those skilled in the art can understand that implementing all or part of the above embodiments and making equivalent changes in accordance with the claims of the present invention are still within the scope of the invention.

Claims

1. A digital capability open platform based on microservice architecture and dynamic permission control, characterized in that: It includes an encapsulation and decoupling module, a service management module, a control module, a governance module, an interface adaptation module, a tracing module, and a configuration management module; the encapsulation and decoupling module, the service management module, and the control module are connected in sequence; the encapsulation and decoupling module, the interface adaptation module, the governance module, and the configuration management module are connected in sequence. The encapsulation and decoupling module is used to decompose capabilities into independent microservices and encapsulate them in a standardized manner using a unified protocol and a unified data model. The service management module is used to complete the automatic registration, health check, service discovery and circuit breaking of microservices; The control module is used to calculate and dynamically issue permission policies in real time based on multi-dimensional attributes such as user role, data range, call time, and call source. The governance module is used to monitor QPS, latency, and error rate in real time and perform elastic scaling during runtime. The interface adaptation module is used to perform protocol conversion, field mapping, and format validation for protocols of different systems. The tracking module is used to perform encrypted log recording and multi-dimensional retrieval for every permission change, interface call, and user behavior; The configuration management module is used to centrally manage permission rules, service parameters, capability metadata, and monitoring thresholds through a graphical interface.

2. The digital capability open platform based on microservice architecture and dynamic permission control as described in claim 1, characterized in that, The encapsulation and decoupling module includes a capability splitting unit, a standardized encapsulation unit, and a metadata description unit; The capability splitting unit is used to identify atomic capabilities in the business system and generate corresponding microservice engineering templates; The standardized encapsulation unit is used to uniformly convert the generated microservice interfaces into the platform-standard REST / JSON protocol and define a unified data model; The metadata description unit is used to automatically generate OpenAPI documentation, field semantics, and version numbers, forming a registerable and discoverable capability directory.

3. The digital capability open platform based on microservice architecture and dynamic permission control as described in claim 1, characterized in that, The service management module includes a service registration unit, a health check unit, a routing load balancing unit, and a circuit breaker and degradation unit. The service registration unit is used to receive instance information reported by the microservice when it starts up and write it into the distributed registry center; The health check unit is used to periodically detect the liveness status of the instance and mark it as unavailable when an abnormality occurs; The routing load unit is used to return a list of available instances based on the service name and perform load balancing by weight or response time. The circuit breaker degradation unit is used to automatically cut off traffic and return a fallback response or switch to a backup instance when the error rate exceeds a threshold.

4. The digital capability open platform based on microservice architecture and dynamic permission control as described in claim 1, characterized in that, The control module includes an attribute collection unit, a rule engine unit, a policy distribution unit, and a permission execution unit; The attribute acquisition unit is used to extract three types of attributes—subject, resource, and environment—from the request context, user directory, and environment variables in real time. The rule engine unit is used to perform permission determination on attribute combinations based on Drools and generate determination results. The policy distribution unit is used to synchronize the changed permission rules to each permission execution node within seconds without interrupting the existing session. The permission execution unit is used to complete authentication interception, data range filtering, and de-identification return at the very front end of the call chain.

5. The digital capability open platform based on microservice architecture and dynamic permission control as described in claim 1, characterized in that, The governance module includes an online detection unit, a performance baseline unit, a security scanning unit, and a runtime monitoring unit; The online testing unit is used to verify whether the request response format, required fields and return codes conform to the specifications through contract testing. The performance baseline unit is used to perform gradient concurrent stress testing in a sandbox environment and record the maximum throughput and P99 latency as a baseline. The security scanning unit is used to detect SQL injection, unauthorized access, and sensitive data leakage vulnerabilities in the interface; The runtime monitoring unit is used to collect real-time QPS, latency, and error rate and compare them with the baseline to trigger elastic scaling or alarm notifications.

6. The digital capability open platform based on microservice architecture and dynamic permission control as described in claim 1, characterized in that, The interface adaptation module includes a protocol conversion unit, a field mapping unit, and a format verification unit; The protocol conversion unit is used to uniformly convert REST, SOAP, JMS, and private TCP protocols into the platform's internal standard REST / JSON; The field mapping unit is used to convert external field names, data types, and units into platform standard semantic fields based on a preset template. The format verification unit is used to verify the converted request body, intercept illegal parameters, and return a unified error code.

7. The digital capability open platform based on microservice architecture and dynamic permission control as described in claim 1, characterized in that, The tracking module includes a log collection unit, an encrypted storage unit, a link splicing unit, and a retrieval and display unit; The log collection unit is used to collect logs generated by each module non-intrusively through an Agent and inject a global traceId; The encrypted storage unit is used to encrypt sensitive fields using the national cryptographic algorithm and then write them into the time-series database; The link splicing unit is used to splice scattered logs into a complete call chain according to traceId and calculate the time consumption of each segment. The search and display unit is used to provide multi-condition combined queries, time series graph display, and export of compliance reports.

Images