Download the PHP package bugloos/fault-tolerance-bundle without Composer
On this page you can find all versions of the php package bugloos/fault-tolerance-bundle. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download bugloos/fault-tolerance-bundle
More information about bugloos/fault-tolerance-bundle
Files in bugloos/fault-tolerance-bundle
Package fault-tolerance-bundle
Short Description Fault Tolerance Bundle
License proprietary
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package fault-tolerance-bundle
Fault Tolerance Bundle
What does it do? :)
- Circuit Breaker Pattern
- Cache each request that you want and saves in Redis for a specified time
- Determine static fallback data for while that circuit breaker doesn't allow request to be executed and cache data doesn't exist for the request
Installation
Compatibility
- PHP v7.4 or above
- Symfony v4.4 or above
What is circuit breaker pattern
In microservice architecture, a service usually calls other services to retrieve data, and there is the chance that the downstream service may be down. It may be cause by slow network connection, timeouts, or temporal unavailability. Therefore, retrying calls can solve the issue. However, if there is a severe issue on a particular microservice, then it will be unavailable for a longer time. In such case, the request will be continuously sent to that service, since the client doesn’t have any knowledge about a particular service being down. As a result, the network resources will be exhausted with low performance and bad user experience. Also, the failure of one service might lead to cascading failures throughout the application.
Therefore, you can use the Circuit Breaker Design Pattern to overcome this problem. With the help of this pattern, the client will invoke a remote service through a proxy. This proxy will basically behave as an electrical circuit breaker. So, when the number of failures crosses the threshold number, the circuit breaker trips for a particular time period. Then, all the attempts to invoke the remote service will fail within this timeout period. After the timeout expires, the circuit breaker allows a limited number of test requests to pass through it. If those requests succeed, the circuit breaker resumes back to the normal operation. Otherwise, if there is a failure, the timeout period begins again.
Usage
To protect a point of access to remote service, we use the command pattern. Here is how a minimal implementation could look like:
This command could be used like this:
Note: the extra parameters you pass to the factory’s getCommand method are forwarded to the command’s constructor.
Command-specific configurations are merged with the default one on instantiation. “GetOrderProxyCommand” in this case is the command key. By default, it is the same as command’s class, but you can set it yourself by overriding the getCommandKey protected method:
Fault tolerant bundle only works with the command keys. If you have two different commands with the same command key - Fault tolerant will disable and enable requests, as for a single entity. This may be used for grouping commands.
To manage configuration for each command you can use Config object in config protected method in command class:
Note: the config you set is merged with the default configs.
Request Cache
Request cache, when enabled, caches command execution result within a single HTTP request, so you don’t have to worry about loading data over network more than needed.
Results are cached per command key per cache key. To define cache key generation logic, implement getCacheKey protected method:
Fallback
For a command, you can specify fallback logic, that will be executed in case of a failure, or when the remote service is blocked:
Note: If you want to use logic requiring networking for your fallback, make sure to “wrap” it into a Fault tolerant command of its own
