Since retrying the requests to the system
service still does not succeed, you need a "fall back" plan.
You will create a fallback method as an alternative solution for when retry requests to the system
service have failed.
Although you disabled MicroProfile @Retry
and other MicroProfile Fault Tolerance policies using the
MP_Fault_Tolerance_NonFallback_Enabled
config property, the fallback policy is still available.
As mentioned before, Istio does not offer any fallback capabilities, so the MicroProfile Fallback capability can be used to complement it.
The @Fallback
annotation dictates a method to call when the original method encounters a failed execution.
If your microservices have a Retry policy specified, then the fallback occurs after all of the retries have failed.
Update the InventoryResource.java file.
Create the getPropertiesFallback()
method.
Add the @Fallback
annotation before the getPropertiesForHost()
method,
to call the getPropertiesFallback()
method when a failure occurs.
The getPropertiesFallback()
method, which is the designated fallback method for the original
getPropertiesForHost()
method, prints out a warning message in the browser that says
the system
service may not be running.
Rebuild your application to add fallback behaviour to your microservices:
Next, run the docker build
commands to rebuild the container images for your application:
Deploy your microservices again to turn off all MicroProfile Fault Tolerance capabilities, except fallback:
Wait until all of your deployments are ready and available.
Run the kubectl get pods
command to get the new [system-pod-name]
.
Pause the system
service pod to simulate that the service is unavailable:
Make a request to the service by using curl
:
If the curl
command is unavailable, then use Postman.
You will see the following output:
HTTP/1.1 200 OK
x-powered-by: Servlet/4.0
x-from-fallback: yes
content-type: application/json
date: Mon, 19 Aug 2019 19:49:47 GMT
content-language: en-US
x-envoy-upstream-service-time: 4242
server: istio-envoy
transfer-encoding: chunked
You can see that the request is now successful and returns a 200
response code, with a header called
x-from-fallback
, indicating that the fallback method is called when the system
service is not available.
See the number of times that the service is retried before the fallback method is called:
You will see the following output:
The above command returns 3, indicating that a total of 3 requests are made to the system
service.
The Istio retries that you enabled on the inventory
service are not performed, because the Fallback policy is enabled.
However, the 3 default requests by Istio on the server end are still performed.
Because all of these requests failed, the getPropertiesFallback()
fallback method is called.