I am looking for an open source API Gateway that can do protocol transformations (Spring Cloud offers Zuul but it accepts only REST connections and does not do protocol transformations). Any idea (or clever solution) given that most of the following protocols must be supported?
CoAP
AMQP
MQTT (must be supported)
STOMP
REST (must be supported)
Sine the next hop after the API Gateway, I was thinking Spring Cloud Stream with custom inbound/outbound adapters. There is also the Spring Cloud Data Flow but I think that is it a different beast.
PS: Oracle API Gateway seems to support multiple protocols but I am looking for an open source solution.
Related
Is it possible to setup federation using pure AMQP protocol/headers? Right now I'm using REST API to setup federation and un-federate an autogenerated queue which is a bit cumbersome.
Update:
I'm using RabbitMQ 3.7.8 which is AMQP version 0.9 of the protocol
At present we have a lot of ASP.net WebAPI service applications hosted on premises. We are planning to move these to Azure AKS. We've identified a lot of common code across these applications which is mostly implemented as ASP.Net reusable middleware components so that the logic is not duplicated in code.
In a K8s environment it makes sense to offload this common functionality to one or more proxy applications which intercepts the requests being forwarded from the ingress to the services (assuming this is the correct approach). Some of the request inspection / manipulation logic is based on the service host and path to be defined in the ingress and even on the headers in the incoming requests.
For e.g. I considered using OAuth2_proxy but found that even though authentication is quite easy to implement, Azure AD group based authorization is impossible to do out of the box with that. So what's the idiomatic way one goes about setting up such a custom proxy application? (I'm familiar with using libraries such as ProxyKit middleware in ASP.Net to develop http proxies.)
One approach that comes to mind is to deploy such proxies as sidecar containers in each service application pod but that would mean there'd be unnecessary resource usage by all such duplicate container instances in each pod. I don't see the benefit over the use of middleware components as mentioned previously. :(
The ideal setup would be ingress --> custom proxy 1 --> custom proxy 2 --> custom proxy n --> service where custom proxies would be separately deployable and scalable.
So after a lot of reading and googling I found that the solution was to use API Gateways that are available as libraries (preferrably based on .Net):
Ocelot placed behind the nginx ingress fits the bill perfectly
Ocelot is a .NET API Gateway. This project is aimed at people using .NET running a micro services / service oriented architecture that need a unified point of entry into their system. However it will work with anything that speaks HTTP and run on any platform that ASP.NET Core supports.
Ocelot is currently used by Microsoft and Tencent.
The custom middleware and header/query/claims transformation solves my problem. Here are some worthy links
Microsoft Docs: Implement API Gateways with Ocelot
Ocelot on Github
Ocelot Documentation
Features
A quick list of Ocelot's capabilities for more information see the documentation.
Routing
Request Aggregation
Service Discovery with Consul & Eureka
Service Fabric
Kubernetes
WebSockets
Authentication
Authorisation
Rate Limiting
Caching
Retry policies / QoS
Load Balancing
Logging / Tracing / Correlation
Headers / Query String / Claims Transformation
Custom Middleware / Delegating Handlers
Configuration / Administration REST API
Platform / Cloud Agnostic
I am developing a website using which is based on a microservices architecture which is containerized with docker. Now I want to communicate with microservices using rest API. I read some articles which show some diagrams that API gateway make some connections to microservices. I am confused about the main purpose of the API gateway.
Gateways are used for cross cutting concerns like authentication, logging and redirect to respective backend services. They are usual the single point of entry for applications and are exposed publicly. the rest of the services can sit behind the firewall that your gateway has access to making backend services secure. you also write your resiliency logic in the gateway by implementing retry or circuit breaker patterns etc.
Since gateway has advantages but it can be single point of failure. so make sure it's highly available by deploying redundant copies
is there any way to implement the Smart Proxy Pattern under Spring Cloud Streams? Having a HTTP Source that get a request connected to other micro services (or processors) and finally return the response through the same connection that was made in the request?
Using Spring Cloud Data Flow maybe it is difficult but by using the Spring Cloud Stream should be possible isn't it?
Thanks.
Almost every spring-cloud guide suggests Ribbon with Feign for RPC.
I wonder why Http Rest takes precedence over binary transport protocol for inner micro-services communication behind the API gateway?
What are the binary alternatives to http that support async invocation and all great features that Netflix OSS provides ? (auto-discovery, load-balancing, circuit breaker, retry policy etc.)
Thanks
There is nothing preventing you from using binary RPC like thrift or protobuffs or msgpack with spring cloud. You can use LoadBalancerClient.choose(<serviceId>) to get a host and port you could supply to any network client. Our integrations were the simple rest clients.
Here is a guide that integrates Spring MVC with google protocol buffers.