Microservice Orchestration Through Process-Based Service Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The high communication overhead in microservice architectures due to frequent interactions between independently deployed microservices is a significant challenge.
Innovation Solution
The creation of service isolation groups, where microservices within the same group are deployed in the same process and different groups are deployed in different processes, with a service runtime module managing intra-process and inter-process communication based on belonging relationships.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If microservices are deployed independently on a network, then service independence and deployment flexibility are improved, but communication overhead increases significantly
Solution Approach 1:
The patent merges multiple microservices into the same process by creating service isolation groups. Microservices within the same group share a common process space, enabling direct memory access and eliminating network communication overhead while maintaining service independence through process isolation mechanisms.
Solution Approach 2:
The patent segments microservices into different service isolation groups based on their communication patterns. Services with frequent interactions are grouped together to share process space, while services with infrequent interactions remain in separate groups, optimizing the balance between communication efficiency and service independence.
2Loss of energy
If microservices are grouped in the same process, then communication cost is reduced, but fault isolation capability may be compromised
Solution Approach 1:
The patent segments microservices into isolated groups where each group has its own process space. This segmentation enables fault containment within groups while maintaining efficient communication within-group, resolving the contradiction between communication efficiency and fault isolation.
Solution Approach 2:
The patent introduces service isolation groups as intermediary layers between individual microservices. These groups act as containment boundaries that prevent fault propagation while enabling optimized communication patterns within the group through shared process space.
3Adaptability or versatility
If service isolation groups are created with different runtime types, then service compatibility is improved, but system complexity increases
Solution Approach 1:
The patent creates service runtime modules with multi-functionality that can support multiple programming languages and runtime environments. This universal runtime capability allows diverse microservices to be grouped together without increasing overall system complexity, as the runtime module adapts to different service types.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The present disclosure provides a microservice orchestration and calling method and apparatus, a device, a microservice system and a medium. The microservice orchestration method implements microservice orchestration by creating (S102) a plurality of service isolation groups and establishing (S103) a belonging relationship between each microservice to be orchestrated and the service isolation groups. In addition, the belonging relationship indicates that microservices in the same service isolation group are deployed in a same process when being deployed on a physical machine cluster, and microservices belonging to different service isolation groups are deployed in different processes when being deployed on the physical machine cluster, so that during the running process of the microservice system obtained based on the microservice orchestration method, faults can be isolated between the microservices in the different service isolation groups, and the communication cost of microservice calling can be reduced.