Support API Gateway for microservices about fabio HOT 6 CLOSED

Can you give some examples for cases 2 and 4?

For the circuit breaker one could argue that if the service is throwing lots of errors it isn't healthy anymore and should indicate that via the health check to consul which would then automatically remove it from fabios' routing table. Then the health check would actually say "service healthy" instead of just "service up".

from fabio.

For feature 2, there's an explanation on Netflix Hystrix:
http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html
As to feature 4, it's still a pattern for API gateway:
http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html

If FabIO could support them all, it'll be very awesome!

from fabio.

Could you please explain briefly in your own words what behavior you think fabio should have and which problems this would solve instead of sending me links and make me figure it out? I took a glance a the articles and I am not sure they apply to fabio at all but I may be missing something here.

from fabio.

The claimed design aim of fabio is to serve microservices' deployment. Routing is an important feature but not all, because microservices does not automatically mean better availability unless you have a fault tolerant architecture, these feature are fundamental requirements for the socalled "resiliency": circuit breaker, retries, bulk heading and fallbacks.
Circuit breaker is not just a healthy check and then remove it from consul, because the backend services could be still healthy through the http api exposed to consul, however, it might be overloaded, or the connection between proxy and services have met some errors. The proxy should be able to protect the services from those situations. Retries and fallbacks are the by-products for circuit breaker. As to the bulk heading, it has the close relationship with "isolation", when a backend service is overloaded, it should not affect other requests sent to proxy.
As to the feature of multiple service calling in a single client request, it's very common in microservices: say a request would assemble and render the results for a shopping cat, while it has the dependent services including order management, user management, recommender engine,...,etc, if each request can only send a single service call, there would be lots of redundant network traffic which is unfriendly for mobile apps.
These are all required features for a microservice api gateway and not the definition coming from me. If fabio could not be an API gateway for microservices architecture, then an extra layer would be required for such purpose which would cause a traffic redundancy.

from fabio.

OK, I get the circuit breaker argument in that fabio can actively drop connections to reduce the load on the backend servers. The question is how fabio determines that a service has an error. 400, 503, 1s timeout, 5s timeout, all of the above? So you would have to configure that for every route since fabio itself isn't configured.

Fallback would be a pretty service unavailable page instead of a dropped connection, correct? (for example)

Retries are dangerous since fabio cannot know which calls are idempotent and hence safe to retry. You can make the assumption that GET requests are OK to retry but that may not necessarily true for all of your routes. So this would also be something to either be disabled by default or to be enabled on a per-rotue basis.

The isolation that you are referring to and the link you've sent stems partly from the fact that Netflix is using java and tomcat as their underlying services. Fabio is written in Go and does not suffer from the thread-per-request model. It can handle a lot more concurrent requests if the underlying operating system can. In our setup the backend services will bail way before fabio does. Also, you don't run just a single fabio server if only for the sake of high-availability. The way our teams run fabio is to deploy it to each of their servers which handle incoming http requests which scales the number of concurrent requests you can handle horizontally.

As for the "bulk call" feature I'm assuming that you want fabio to trigger multiple service calls from a single inbound request. This is a matter of API design and should not be put into the API gateway IMO. If I understand the linked Netflix article correctly then that is exactly what they are doing.

However, most of these issues are only really relevant if you are starting to run services at scale. May I ask what the scale of the services (in req/sec) is you want to use fabio for?

from fabio.

OK, I'm going to close this issue since it is about whether fabio could support certain features and I think we've explored this sufficiently. If not then feel free to re-open.

Otherwise, please create specific tickets for features (one per feature) that you want/need to support a concrete use case.

from fabio.