Based on the. net core microservice framework and the. netcore framework
I. Preface
The open-source surging has suffered a lot. net is also favored.. net core Learning Group. NET China Foundation for convenience in China. net core open-source project promotion, I accept the invitation to join the team for mutual exchange and learning, and recently updated the new surging version
Update content:
1. Castle. Core compatibility issues will be removed in the next version to solve the first time some users compile VS program.
2. Increased fault tolerance and downgrade
3. Route Fault Tolerance reconstruction, for failure retry and Failure no retry, failure callback,
4. Added some functional unit tests.
5. Upgrade supports. net core 2.0
Latest: https://github.com/dotnetcore/surging
II. Introduction and example of Service Fault Tolerance and downgrade 1. Introduction to service fault tolerance and downgrade
The reliability of microservices mentioned in the previous article is omitted for fault tolerance and degradation. This article introduces fault tolerance and degradation.
When microservices are unavailable, fault tolerance must be performed based on preset policies. Most of the Fault Tolerance capabilities and policies are public, so they can be implemented in the framework.
Service Fault Tolerance
When a microservice fails to be called, the fault tolerance mechanism can be used to implement automatic fault tolerance for the microservice at the underlying level, improving the system reliability.
Surging fault tolerance policies include:
Failover: the automatic Failover policy for failed microservice calls refers to re-selecting the next available microservice provider when a service call exception occurs. When a microservice is released, you can specify a fault tolerance policy for the service cluster. Consumers can overwrite common configurations of service providers to implement personalized error tolerance policies.
Injection: After a microservice fails to be called, an exception callback interface or Injection script is provided to execute the failure processing logic customized by the microservice consumer.
Service downgrade
The service is unavailable for some reason, but the process cannot directly fail. It must be implemented on the local Injection server. For example, if the ticket is purchased for 12306 million yuan at the end of the year, the ticket query service cannot work normally, at this time, the service should be enabled, and the previous cache record or NULL should be returned, instead of the failure.
Common downgrade policies:
1. The service route is short-circuited and null is directly returned. For example, Injection = "return null ;".
3. short-circuited service routing. The local simulated interface implementation class is directly executed. Injection = "true ;".
Fault Tolerance and downgrade
When a service is unavailable, the service logic can be opened for normal operation of the service.
Automatic Fault Tolerance downgrade: this function is triggered automatically based on the defined threshold value, and relevant policies are called to downgrade.
Forced downgrade: triggered by manual operations based on system running conditions.
2. Service Fault Tolerance and downgrade example
Create a service fault tolerance and downgrade, select Injection policy script Injection, and return null directly.
[Command(Strategy= StrategyType.Injection ,Injection = @"return null;")]
Create a service fault tolerance and downgrade, select Injection policy script Injection, and directly Return Task <UserModel>
[Command(Strategy= StrategyType.Injection ,Injection = @"return Task.FromResult(new Surging.IModuleServices.Common.Models.UserModel { Name=""fanly"", Age=18 });",InjectionNamespaces =new string[] { "Surging.IModuleServices.Common"})]
Create a service fault tolerance and downgrade, and select Injection policy to directly call the local module.
[Command(Strategy= StrategyType.Injection ,Injection = @"return true;")]
Create a service fault tolerance and downgrade, select the Failover policy, and automatically switch to retry remote calls.
[Command(Strategy= StrategyType.Failover )]
Configuration parameters
Parameters |
Function |
Remarks |
Strategy |
Fault Tolerance Policy |
Including Failover and Injection |
FailoverCluster |
Number of failovers |
Default Value: 3 |
ExecutionTimeoutInMilliseconds |
Execution timeout |
Default Value: 1000 |
RequestCacheEnabled |
Enable cache? |
Disabled by default |
Injection |
Script Injection |
|
InjectionNamespaces |
Inject namespace |
The Assembly name is more appropriate |
BreakeErrorThresholdPercentage |
How much fuse protection is enabled when the error rate reaches? |
Default Value: 50 |
Breakesleepw.winmilliseconds |
How many seconds will the circuit breaker attempt? |
Default Value: 60000 |
BreakerForceClosed |
Disable the circuit breaking forcibly |
|
BreakerRequestVolumeThreshold |
At least how many requests fail in 10 seconds before the fuse works |
Default Value: 20 |
MaxConcurrentRequests |
Maximum concurrency |
10 |
Iii. Test
Test Environment
CPU: Intel Core i7-4710MQ
Memory: 16 GB
Hard Disk: 1 tb ssd + 512 GB HDD
Network: Lan
The test results are as follows:
Iii. Summary
In the next version of surging, content such as cache degradation, file configuration service fault tolerance, and degradation will be added, and unit tests will be added. For API gateway, we are starting to research and integrate ocelot in the next month, if you are interested, please pay more attention or join the QQ group: 615562965