CN116260820A - Application method of cloud native network function - Google Patents
Application method of cloud native network function Download PDFInfo
- Publication number
- CN116260820A CN116260820A CN202310143804.6A CN202310143804A CN116260820A CN 116260820 A CN116260820 A CN 116260820A CN 202310143804 A CN202310143804 A CN 202310143804A CN 116260820 A CN116260820 A CN 116260820A
- Authority
- CN
- China
- Prior art keywords
- application
- service
- decoupling
- network function
- cloud native
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 59
- 238000004891 communication Methods 0.000 claims abstract description 39
- 230000008569 process Effects 0.000 claims description 31
- 230000002085 persistent effect Effects 0.000 claims description 30
- 238000011161 development Methods 0.000 claims description 20
- 239000003795 chemical substances by application Substances 0.000 claims description 13
- 238000012545 processing Methods 0.000 claims description 5
- 239000003999 initiator Substances 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 8
- 238000013500 data storage Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 4
- 238000007726 management method Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000013508 migration Methods 0.000 description 2
- 230000005012 migration Effects 0.000 description 2
- 239000000178 monomer Substances 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 238000007670 refining Methods 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention provides an application method of a cloud native network function, and belongs to the technical field of communication network function virtualization. The application method provided by the invention carries out application statement from different layers, carries out decoupling application on the cloud native network based on network function decoupling, service logic and storage decoupling and application program and network decoupling, and better realizes resource sharing and elastic deployment in the whole network range based on a unified control and arrangement telecommunication clouding environment and a cloud native network function CNF. Meanwhile, the application of the power-assisted cloud primary network function in the communication technical field further enables the telecommunication network to be developed to the cloud stage.
Description
Technical Field
The invention belongs to the technical field of communication network function virtualization, and particularly relates to an application method of a cloud native network function.
Background
Network function virtualization (Network Function Virtualization, NFV) reduces the expensive equipment cost of the network by using general-purpose hardware such as x86 and virtualization technology to carry the software processing of many functions. The network equipment functions can be independent of special hardware through software and hardware decoupling and function abstraction, resources can be fully and flexibly shared, rapid development and deployment of new services are realized, and automatic deployment, elastic expansion, fault isolation, self-healing and the like are performed based on actual service requirements. NFV replaces hardware-based or device-based network services by a method of creating virtual network functions (Virtualized Network Function, VNF) to implement an open architecture of unified generic hardware platform + business logic software.
In the prior art, the transformation of Network Functions (NF) is a key to implementing NFV, and NF has undergone an evolution process from Physical Network Functions (PNF), virtual Network Functions (VNF) to Cloud Native Network functions (CNF). Among them, the physical network function has many drawbacks, and thus cannot meet the network demands of the day-to-day and month-to-day, for example, the server cannot be sliced/partitioned to run more applications/VNFs; the operation systems of the general servers are not uniform, so that the configuration modes are not uniform and difficult to maintain; the processing capacity of the network function cannot be increased elastically along with the increase of the network load, and the expansion is difficult; the cloud scene needs to feed back equipment manufacturers for development and has long development period for new business support. Disadvantages of virtual network functions include: the starting time is long, and the starting time is in the order of minutes. Although much better than physical machines; overhead by virtual machine manager (Hypervisor) and Guest OS; implemented as a code monomer. All development, testing, maintenance, deployment and troubleshooting must treat the VNF as a single atomic unit. The cloud native network function is still in the exploration stage, and resource sharing and elastic deployment in the whole network range are not realized.
Disclosure of Invention
The invention aims to: an application method of a cloud native network function is provided to solve the above problems existing in the prior art. Aiming at the technical field of communication, the application of the cloud native network function is realized from different layers, and the application of the power-assisted cloud native network function in the technical field of communication further develops the telecommunication network to the clouding stage.
The technical scheme is as follows: according to the method, aiming at a micro-service and stateless development mode, service logic and storage decoupling are decoupled from the network function, and application decoupling is performed on three layers of application program and network decoupling. When a single-instance expansion resource encounters a bottleneck, the elastic expansion of the container instance can be realized by matching with a load balancing mechanism; meanwhile, when the rapid development and automatic deployment of the products of the network operators are realized, the products can be continuously updated.
The network function is decoupled at the code implementation level, and a micro service module is designed according to the service function and the module division, so that a single micro service is responsible for independent task processing.
Decoupling business logic from storage further decouples micro-service application execution, persists, caches, configures, communicates, and is independently a third-party distributed component while retaining business logic as an application. The process of performing service logic and storage decoupling comprises the following steps: the application is decoupled from the outside, the persistent storage is decoupled from the business logic, the cache is decoupled from the business logic, the application configuration is decoupled from the business logic, and the inter-application communication is decoupled.
In the process of executing the application with respect to external decoupling, load balancing is set for the application program between the application and the outside, and communication is performed with the application program through a reverse proxy of the load balancing.
In the process of decoupling the persistent storage and the business logic, the persistent storage in the application is pumped away and is independently stored in the distributed persistent storage; distributed persistent storage is still used for application copy, post-restart applications, and upgrade applications.
In the process of decoupling the execution cache and the business logic, the business variable is separated from the program and stored in an independent cache system, and the business logic directly reads and writes data from the distributed cache system.
And in the process of decoupling the application configuration and the business logic, different configurations are independently stored in the distributed configuration system, and the configuration is read from the distributed configuration system after the program is started.
In the process of performing communication decoupling between applications, third party message middleware is constructed as a communication bridge, and messages are sent and received through a producer consumer mode.
In performing application-to-network decoupling, micro-service inter-application communication uses a service grid as an infrastructure layer for inter-service communication. In the actual operation process, the application is used as a service initiator, a request is sent to a local service grid agent in an existing mode, then the grid agent performs subsequent operation, and finally the request is forwarded to a target service.
Based on the application decoupling application method, a container and a container arranging tool are adopted to deploy the cloud native network function application.
The beneficial effects are that: the invention provides an application method of a cloud native network function, which is characterized in that network function NF decoupling, service logic decoupling and storage decoupling are carried out, application program and network decoupling are carried out on three layers of application statement of the cloud native network function, a telecommunication clouding environment based on unified control and arrangement and a cloud native network function CNF target are realized, and resource sharing and elastic deployment in the whole network range are further better realized. Meanwhile, aiming at the development mode of micro-servitization and stateless CNF, the application decoupling method can guide the development of new NF and can also reform old NF, so that CNF meets the requirements of cloud primary operation.
Drawings
Fig. 1 is a diagram of the evolution of the functionality of a prior art telecommunications network.
Fig. 2 is an evolution diagram of a conventional network function.
Fig. 3 is a schematic diagram of a decoupling application according to an embodiment of the present invention.
Fig. 4 is a schematic diagram illustrating the network function NF decoupling according to an embodiment of the present invention.
FIG. 5 is a schematic diagram of service logic and data storage decoupling according to an embodiment of the present invention.
Fig. 6 is a schematic diagram of decoupling an application program from a network according to an embodiment of the present invention.
Fig. 7 is a schematic operation diagram of an embodiment of the present invention applied to an external decoupling embodiment.
FIG. 8 is a diagram illustrating the storage between a micro-service and a data cache according to an embodiment of the present invention.
Detailed Description
In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without one or more of these details. In other instances, well-known features have not been described in detail in order to avoid obscuring the invention.
The applicant believes that in the process of the evolution of network functions, as shown in fig. 1, the network functions undergo an evolution process from Physical Network Functions (PNFs), virtual Network Functions (VNFs) to Cloud Native network functions (CNFs).
Among them, as shown in fig. 2, a Physical Network Function (PNF) is a physical device supporting a network function. PNFs typically provide software functionality by a generic server instead of a dedicated hardware entity of the network device vendor. PNFs deployed in a network may include routers, gateways, and firewall devices. The Physical Network Function (PNF) runs applications directly on the physical server, the most traditional way to run applications. PNF suffers from the following drawbacks, failing to meet the changing network requirements:
(1) The server cannot be sliced/partitioned to run more applications/VNFs.
(2) The operation systems of the general servers are not uniform, so that the configuration modes are not uniform and difficult to maintain.
(3) The processing capacity of the network function cannot be increased flexibly with the increase of the network load, and the expansion is difficult.
(4) The cloud scene needs to feed back equipment manufacturers for development and has long development period for new business support.
A Virtual Network Function (VNF) is a network function that operates in a virtual environment. The VNF needs to run this VNF using virtual machines. In addition, the virtual machine requires one Hypervisor (Hypervisor) to partition the physical servers into multiple logical Servers (VMs). VNFs also suffer from the following non-negligible drawbacks:
(1) Although much better than physical machines, the start-up time is long, on the order of minutes.
(2) Overhead caused by virtual machine Hypervisor (Hypervisor) and Guest OS.
(3) Implemented as a code monomer. All development, testing, maintenance, deployment and troubleshooting must treat the VNF as a single atomic unit.
Example 1
In one embodiment, aiming at the problems existing in the prior art, the embodiment provides an application method of a cloud native network function, and based on an architecture for realizing running the network function in a container, a telecommunication clouding environment and a cloud native network function CNF are uniformly controlled and arranged so as to better realize resource sharing and elastic deployment in a whole network range.
Specifically, as shown in fig. 3, in the process of executing an application, cut-in analysis is performed from three layers of network function NF decoupling, service logic and storage decoupling and application program and network decoupling, wherein the network function NF decoupling is currently applied to a 5G core network, and is not applied to other communication fields. The service logic is decoupled from the storage, the application program is decoupled from the network, and the 2 decoupling ideas and methods are not applied in the communication field at present.
Cloud native network functions (CNFs) are an architecture implemented to run network functions within a container. CNF inherits the operational principles of all cloud native architectures, including K8s lifecycle management, agility, resilience, and observability. CNFs place Physical (PNF) and Virtual Network Functions (VNF) in containers. Apart from the advantages that many VNFs will be obtained, no VM software overhead is necessary.
In a further embodiment, to meet the flexibility, the network function NF development does not employ traditional monolithic applications, but employs a micro-serviceless, stateless development mode. As shown in fig. 4, the micro-servization decomposes the network function NF into a plurality of micro-services with independent functions, which greatly shortens the version development period, improves the NF fault tolerance, is easy to maintain, and can well satisfy agility. Stateless, meaning that NF processes a single request, independent of other requests, so that the elasticity characteristics can be satisfied, and the NF service is not affected.
Aiming at the mentioned micro-servitization and stateless development modes, the application method mentioned in the embodiment decouples network function NF, service logic and storage, and the application program and network decoupling execute the instruction of developing new NF and reform old NF, so that CNF meets the requirements of cloud native operation.
The multiple micro-services form a complete network function NF, so that the network function NF is decoupled to split the NF into multiple micro-services with relatively independent functions. Microservice has many advantages, such as facilitating containerized deployment of each microservice; the service can be independently expanded and upgraded, so that the project release period is greatly shortened; because the micro-service logic is simpler and easier to maintain than the single-body application; each micro service can flexibly adopt a proper technical stack, and is not limited to a fixed technical stack, such as C/C++, so that development efficiency is improved; because each micro-service is independently operated, better fault isolation can be realized in the micro-service architecture, and the fault tolerance of the whole network function NF is improved.
Any application is made up of business logic representing a regular mapping of real business implemented in code and stateful data stores, where the states are stored in a database, cache, file, communication data stream, or other form of storage. In the traditional program development and deployment modes, the application program is stateful, so that state inconsistency among cross-border points easily occurs. Therefore, in order to achieve application stateless, the business logic of the program needs to be separated from the data storage. Based on the result of the network function NF decoupling, the service logic and the data storage decoupling are continuously adopted, so that the micro-service application of the CNF is further decoupled.
In a further embodiment, the micro-service inter-application communication does not use its own protocol stack to communicate during execution of the application decoupling from the network, using the service grid as an infrastructure layer for inter-service communication.
Compared with the virtual network function in the prior art, the cloud native network function in the embodiment is not just a containerized network virtual machine, but introduces the cloud native concept at the same time, and has elasticity and agility. When a single-instance expansion resource encounters a bottleneck, the elastic expansion of the container instance can be realized by matching with a load balancing mechanism; meanwhile, when the rapid development and automatic deployment of the products of the network operators are realized, the products can be continuously updated.
Example two
In a further embodiment based on the first embodiment, the network function NF is decoupled at the code implementation level, and the micro service module is designed according to the service function and the module division, so that a single micro service is responsible for independent task processing. The whole software platform service is subjected to grain refining and splitting, so that split micro services can be independently operated without interference.
In the process of executing service division, based on an AKF splitting principle, stateless service splitting is executed, an application service interface design conforming to a Restful mode is used, and a unified interface is shared at the same time, so that the requirement of transmission state between a client and a server is met.
The AKF splitting principle is to divide mutually isolated and complete subsystems according to the user demands, and three coordinate axes of the AKF expansion cube model are respectively as follows: x, Y, Z, wherein the X-axis represents horizontal replication services and data, solving the problems of application service throughput and availability; the Y-axis longitudinal expansion splits the complex application into a plurality of services, each service corresponding to a group of associated functions; the Z-axis expansion divides the system by the angle of the user to obtain a subsystem meeting the user requirement.
The stateless service splitting is to extract stateless services in the application platform for micro-service, wherein the stateless services are that no persistent data is generated in the operation process, no other service interfaces are relied on in the single request process, and all required data information can be obtained from external storage such as a database and the services per se.
In the process of interface design, restful is an object of a representable flow unit or resource, each request object in the service is represented by a URL, and all resources such as an application program, a database, an algorithm and the like share a unified interface so as to transmit a state object between a client and a server.
Example III
In a further embodiment based on the first embodiment, as shown in fig. 5, the conventional application uses business logic, persistent storage, buffering, configuration and communication as an integral application, so in the process of performing decoupling of business logic and storage, in order to achieve stateless application, the embodiment separates the business logic of the program from data storage, and reserves the business logic as the application by means of independently using the persistent storage, buffering, configuration and communication as a third-party distributed component.
The process of decoupling the business logic and the data storage of the program comprises the following steps: the application is decoupled from the outside, the persistent storage is decoupled from the business logic, the cache is decoupled from the business logic, the application configuration is decoupled from the business logic, and the inter-application communication is decoupled.
Conventional network communication, such as HTTP communication, requires specifying the IP address and port of the destination to communicate. In the process of executing the application to external decoupling, load balancing is set for the application program, and then the application program is communicated with the reverse proxy of the load balancing, so that network interruption caused by application program variation is prevented. Specifically, the application is decoupled from the outside, the application is not directly exposed to provide services to the outside, load balancing is newly added between the application and the outside, the outside reversely agents the traffic to the application through the load balancing, and meanwhile, the traffic is loaded to all copies of the application through the load balancing. The external user and the external application are connected with the application through load balancing, and the independent distributed storage, the distributed cache and the distributed configuration which are decoupled in the subsequent steps are connected with the application through load balancing. Because load balancing can lead traffic into normal application copies until abnormal application copies recover to be normal, by decoupling, restarting of the application is prevented, upgrading is prevented, and the suspension causes abnormal CNF service, so that normal operation of the CNF is ensured.
In the process of decoupling the persistent storage from the business logic, the persistent storage in the application is separated and stored in the distributed persistent storage. The persistent storage mentioned therein may be a database, an object store, a text file of XML, txt, etc. In the actual operation process, the application copy is still used by the application or the upgrading application after restarting, so that the application persistent data is not lost. The persistent storage is used for storing persistent data in the application, and the persistent storage used by different applications is different, for example, a persistent storage database comprises a structured database such as MySQL, DB2 and the like, and a non-relational database such as MongoDB, HBase and the like; object store OSS, text store including XML, YAML, TXT etc. formats of stored text.
And in the process of decoupling the execution cache and the service logic, the cache of the global variable of the application and the like is stripped from the service logic in the application and is stored in the distributed cache, and the service logic directly reads and writes cache data from the distributed cache. By the method, cache loss of global variables and the like of the application caused by application migration and upgrading and CNF abnormality caused by restarting can be avoided. For example, after the service logic is initialized, the initialization mark is written into the cache, and when the service logic executes the service, the initialization mark is read from the cache, and the initialization operation is not repeatedly executed. The operation aims at that a plurality of operation examples exist in service logic, and the data among the examples are kept synchronous by storing the data shared among the examples in a cache, so that the data loss in the cache caused by stopping or restarting a certain example is prevented, and the whole service is influenced.
In conventional application development, application configuration is independent from an application program, and certain attributes of the application program can be updated without recompiling the application program. While the application configuration has been decoupled from the traffic, in CNF applications are deployed in distributed clusters, applications are not fixed on fixed hosts, thus resulting in application migration that may lose the application configuration. In the process of executing decoupling of application configuration and business logic, the embodiment independently stores different configurations into a distributed configuration system, and reads the configurations from the distributed configuration system after a program is started.
Traditional application development, applications directly connect communication to interact data, and once the service is suspended, the data received and to be sent are lost, so that the normal work of the CNF is affected. In the process of executing communication decoupling between applications, the communication between applications is decoupled, message middleware is added between applications, the application sends and receives messages through the message middleware, a destination application is added when the application sends the messages, and the message middleware eliminates the messages after the application receives the messages, so that message loss is avoided.
Example IV
In a further embodiment based on the embodiment, although decoupling of communication between applications is mentioned in decoupling business logic and storage, the micro-services are coupled with message middleware, and direct communication is still needed between some micro-services, so the present implementation proposes decoupling of application programs from networks, and further decoupling of programs from networks using service grids. The application is used as a service initiator, and only needs to send the request to a local service grid agent in the simplest mode, then the grid agent can perform subsequent operations, and finally the request is forwarded to the target service.
As shown in fig. 6, the overall architecture of the service grid applies a Sidecar (Sidecar) mode to the micro-service architecture system of the CNF, a Sidecar agent is deployed for each application service in a matched manner, the application service does not directly participate in communication, but completes complex communication among services through the Sidecar agent, and finally a network topology structure is obtained. The application acts as the initiator of the service and only needs to send the request to the local side car agent in the simplest way, and then the side car agent can perform subsequent operations to forward the request to the target service.
The present embodiment masks the complexity of micro services to handle various communication problems by sinking the communication of the micro services to the infrastructure layer.
Example five
Taking a fifth generation mobile communication technology (5G) core network (5 GC) as an example, a cloud native network function implementation method in a 5GC scene is described.
The network function NF is decoupled, splitting the 5GC into multiple, functionally independent microservices. According to the service characteristics of 5GC, the method can be split into: AMF, responsible for access and mobility management functions; AUSF, responsible for authentication service function; NEF, responsible for network opening function; NRF, responsible for network repository function; NSSF, responsible for network slice selection function; PCF, responsible for controlling policy function; SMF, responsible for session management function; UDM, responsible for unified data management functions; UPF, responsible for user plane functions. The micro-service splitting can facilitate containerization deployment, expansion and upgrading, and improves the fault tolerance of the whole 5GC.
The 5GC business logic is decoupled from storage, embodied from the following 5 aspects:
first, the application is decoupled from the outside, setting up a load balancing LB for an instance of a 5GC micro-service, communicating with other services through the LB. In the cloud native scenario, for OSI network model 4 layer (transport layer, L4), mechanisms such as kubernetes Service are used to provide 4 layer load balancing (L4 LB) capability; for layer 7 (application layer, L7), a mechanism such as kubernetes Ingress is used to provide layer 7 routing load (L7 LB) capability. As shown in FIG. 7, each micro-service has multiple running instances, and the services do not communicate directly through instances, but through L4 LB, L7 LB. This avoids failure of one instance (e.g., NRF instance 1), the LB may load traffic to the other instance (e.g., NRF instance 2), avoiding the spread of the failure throughout the 5GC.
Second, the persistent storage is decoupled from the service logic, the persistent storage is stripped from the 5GC service logic and is uniformly stored in the distributed persistent storage (such as MySQL database and OSS object storage), and a plurality of instances of the micro-service share the persistent data, so that the synchronization of the persistent data among the plurality of instances can be ensured. As shown in FIG. 8, the micro service instance stores the persisted data in distributed persistent storage.
Thirdly, the cache is decoupled from the service logic, the cache data is stripped from the 5GC service and is uniformly stored in a distributed cache (such as Redis, memcache), and a plurality of instances of the micro service can share the cache data, so that the cache data synchronization among the plurality of instances is ensured. As shown in FIG. 8, the micro-service maintains cached data in a distributed cache.
Fourth, the application configuration is decoupled from the service logic, the application configuration is stripped from the 5GC service and is uniformly stored in a distributed configuration system (such as kubernetes ConfigMap, springCloud Config), and such a set of configuration can be applied to multiple instances. As shown in FIG. 8, the micro service instance stores persistence data into the distributed configuration system.
Fifth, inter-application communication is decoupled, and certain information interaction between 5GC micro services is avoided, wherein information is exchanged through third party middleware (such as Kafka, activeMQ) instead of direct communication, so that information loss caused by service restart is avoided.
Application program and network decoupling, 5GC micro-service communication can be further decoupled, and a service grid agent (such as ISTIO) is added on the LB, and the micro-service traffic is forwarded through the agent.
As described above, although the present invention has been shown and described with reference to certain preferred embodiments, it is not to be construed as limiting the invention itself. Various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (10)
1. The application method of the cloud native network function is characterized by comprising the following steps:
for the development mode of micro-service and stateless, the application decoupling is executed from three layers of network function decoupling, service logic decoupling and storage decoupling and application program decoupling.
2. The method for applying cloud native network functions according to claim 1, wherein the network functions are decoupled at a code implementation level, and micro service modules are designed according to service functions and module division, so that a single micro service is responsible for independent task processing.
3. The method for applying cloud native network functions according to claim 1, wherein the decoupling of the business logic from the storage further decouples the execution of the micro-service application, and the persistent storage, caching, configuration, communication are independently third-party distributed components while retaining the business logic as an application;
the process of performing service logic and storage decoupling comprises the following steps: the application is decoupled from the outside, the persistent storage is decoupled from the business logic, the cache is decoupled from the business logic, the application configuration is decoupled from the business logic, and the inter-application communication is decoupled.
4. A method for applying a cloud native network function according to claim 3, wherein load balancing is set for the application program between the application and the outside in the process of executing the application with respect to external decoupling, and the application program is communicated through a reverse proxy of the load balancing.
5. The method for applying cloud native network functions according to claim 3, wherein in the process of performing decoupling of persistent storage and service logic, the persistent storage in the application is pulled away and is separately stored in the distributed persistent storage; distributed persistent storage is still used for application copy, post-restart applications, and upgrade applications.
6. The method for applying the cloud native network function according to claim 3, wherein in the process of performing the decoupling of the cache and the service logic, the service variable is separated from the program and stored in an independent cache system, and cache data is directly read from and written to the distributed cache system when the service logic is performed according to service requirements;
after the service logic is initialized, the initialization mark is written into the cache, and when the service logic executes the service, the initialization mark is read from the cache and the initialization operation is not repeatedly executed.
7. The method for cloud native network function according to claim 3, wherein different configurations are independently stored in the distributed configuration system during the process of decoupling the application configuration from the service logic, and the configuration is read from the distributed configuration system after the program is started.
8. A method for applying a cloud native network function according to claim 3, wherein in the process of performing communication decoupling between applications, a third party message middleware is constructed as a communication bridge, and the message is transmitted and received through a producer consumer mode.
9. The method of claim 1, wherein the micro-service inter-application communication uses a service grid as an infrastructure layer for inter-service communication in performing the decoupling of the application from the network;
in the actual operation process, the application is used as a service initiator, a request is sent to a local service grid agent in an existing mode, then the grid agent performs subsequent operation, and finally the request is forwarded to a target service.
10. The application method of the cloud native network function according to claim 1, wherein the cloud native network function application is deployed using a container and a container orchestration tool based on the application decoupled application method.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310143804.6A CN116260820A (en) | 2023-02-21 | 2023-02-21 | Application method of cloud native network function |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310143804.6A CN116260820A (en) | 2023-02-21 | 2023-02-21 | Application method of cloud native network function |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116260820A true CN116260820A (en) | 2023-06-13 |
Family
ID=86685878
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310143804.6A Pending CN116260820A (en) | 2023-02-21 | 2023-02-21 | Application method of cloud native network function |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116260820A (en) |
-
2023
- 2023-02-21 CN CN202310143804.6A patent/CN116260820A/en active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11429369B2 (en) | Distributed upgrade in virtualized computing environments | |
US20230123775A1 (en) | Cloud native software-defined network architecture | |
US9201704B2 (en) | System and method for migrating application virtual machines in a network environment | |
US9529582B2 (en) | Modular architecture for distributed system management | |
US20200167185A1 (en) | Node regeneration in distributed storage systems | |
US10979248B1 (en) | Onboarding a VNF which includes a VNFC composed of manageable software elements | |
KR20110000752A (en) | Distributed virtual switch for virtualized computer systems | |
US10218605B2 (en) | On-demand control plane redundancy | |
US11539553B1 (en) | Onboarding a VNF which includes a VDU with multiple VNFCs | |
US20230336414A1 (en) | Network policy generation for continuous deployment | |
EP4160409A1 (en) | Cloud native software-defined network architecture for multiple clusters | |
CN114615268B (en) | Service network, monitoring node, container node and equipment based on Kubernetes cluster | |
US11513830B2 (en) | Introspection into workloads running within virtual machines | |
Escaleira et al. | Multi-access edge computing as a service | |
US20210240511A1 (en) | Computer-implemented method for reducing service disruption times for a universal customer premise equipment, ucpe, device with resource constraint in a network functions virtualization, nfv, network infrastucture | |
US20240095158A1 (en) | Deployment checks for a containerized sdn architecture system | |
US20230138867A1 (en) | Methods for application deployment across multiple computing domains and devices thereof | |
CN110795209B (en) | Control method and device | |
EP4160411A1 (en) | Virtual network routers for cloud native software-defined network architectures | |
CN116260820A (en) | Application method of cloud native network function | |
John et al. | Making cloud easy: design considerations and first components of a distributed operating system for cloud | |
EP3340048A1 (en) | System and method for content - application split | |
US10469374B2 (en) | Multiple provider framework for virtual switch data planes and data plane migration | |
Sehgal | Introduction to OpenStack | |
CN114157569A (en) | Cluster system and construction method and construction device thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |