Request Replication for Microservice Fault Isolation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In microservice architectures, it is challenging to isolate and identify faults when upgrading container images, as the continuous integration environment with changing container images makes it difficult to ensure compatibility and stability, leading to performance degradation and errors, such as seen in the online shopping website Web-Mart after upgrading features.

Innovation Solution

The system replicates user requests to both a stable production system with validated container images and modified production systems with unvalidated images, comparing their responses to identify faults and determine the best combination of container images for optimal performance without disrupting the original production system.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If container images are continuously updated in a microservice architecture, then system functionality and features are improved, but system stability and reliability deteriorate due to compatibility issues and faults

Engineering Contradiction:
Improvesystem functionalityVSAvoidsystem stability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system segments the production environment into multiple isolated containers, each running a different version of container images. This allows simultaneous operation of stable and updated versions, enabling functionality improvement while maintaining stability through version isolation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary validation by dispatching replicated requests to containers with updated container images before full deployment. The fault detector compares responses from updated and stable versions in advance, identifying potential issues before they affect the entire system.

Inventive Principle:
Principle #10Preliminary action

2Difficulty of detecting and measuring

If multiple versions of container images are tested simultaneously, then fault identification capability is improved, but system complexity increases due to multiple production systems

Engineering Contradiction:
Improvefault identification capabilityVSAvoidsystem complexity
Core Design Contradiction:
Difficulty of detecting and measuringVSDevice complexity

Solution Approach 1:

The system creates copies of the production system architecture, with each copy running a specific version of container images. These replicated systems allow parallel testing of multiple versions while maintaining a standardized structure, making fault detection easier without proportionally increasing overall system complexity.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The fault detector acts as an intermediary component that receives and compares responses from multiple production systems. This centralized mediation simplifies the complexity by providing a single point of comparison and fault identification, rather than requiring complex distributed monitoring across all systems.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Measurement precision

If replicated requests are dispatched to multiple production systems, then validation accuracy is improved, but processing time increases due to parallel request handling

Engineering Contradiction:
Improvevalidation accuracyVSAvoidprocessing time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The system maintains continuous operation by having the stable production system continue serving requests while updated versions are validated in parallel. The fault detection process occurs continuously in the background, ensuring validation accuracy without causing service interruptions or significant delays.

Inventive Principle:
Principle #20Continuity of useful action

Solution Approach 2:

The system applies partial validation by selectively dispatching replicated requests to updated production systems based on risk assessment and confidence levels. Not all requests are routed for validation, allowing the system to maintain high validation accuracy for critical operations while reducing processing overhead for routine operations.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS10275329B2Fault isolation and identification in versioned microservices
Publication Date: 2019.04.30 RED HAT INC
  • US10275329B2 patent drawing
  • US10275329B2 patent drawing
  • US10275329B2 patent drawing

AI summary

A method for identifying and isolating faults in versioned microservices includes a request replicator receiving an original request, and determining whether to replicate the original request. The request replicator replicates the original request creating one or more replicated requests, including a first replicated request. In an example, the request replicator dispatches the original request to a stable production system, and dispatches the first replicated request to a first modified production system. The stable production system produces a first reply to the original request. The first modified production system produces a second reply to the first replicated request. A fault detector performs a comparison of the second reply and the first reply and determines, based on the comparison, that the first modified production system has a verification status. Then, the stable production system is replaced with first modified production system.