API gateway/proxy pattern for microservices deployed using Azure Service Fabric

Question

After watching the BUILD conference videos for Azure Service Fabric, I\'m left imagining how this might be a good fit for our current microservice-based architecture. There is o

Answer 1

We have used an open source project called Traefik with amazing success. There is an Azure Service Fabric wrapper around it - it's essentially a GoLang exe that is deployed onto the cluster as Managed Executable.

It supports circuit breakers, weighted round robin LB, path & header version routing (this is awesome for hosting multiple API versions), the list goes on. And its got a handy portal to view the config and health stats.

The real power in it lies in how you configure it. It's done via the service itself in the ServiceManifest.xml. This allows you to deploy new services and have them immediately able to be routed to - no need to update a routing table etc.

Example

<StatelessServiceType ServiceTypeName="WebServiceType">
  <Extensions>
      <Extension Name="Traefik">
        <Labels xmlns="http://schemas.microsoft.com/2015/03/fabact-no-schema">
          <Label Key="traefik.frontend.rule.example">PathPrefixStrip: /a/path/to/service</Label>
          <Label Key="traefik.enable">true</Label>
          <Label Key="traefik.frontend.passHostHeader">true</Label>
        </Labels>
      </Extension>
  </Extensions>
</StatelessServiceType>

Highly recommended!

Answer 2

The service registration/discoverability you need to do this is actually already there. There's a stateful system service called the Naming Service, which is basically a registrar of service instances and the endpoints they're listening on. So when you start up a service - either stateless or stateful - and open some listener on it, the address gets registered with the Naming Service.

Now the part you'd need to fill in is the "gateway" that users interact with. This doesn't have to be stateful because the Naming Service manages the stateful part. But you'd have to come up with an addressing scheme that works for you, and then it would just forward requests along to the right place. Basically something like this:

1. Receive request.
2. Use NS to find the service that can take the request.
3. Forward the request to it and the response back to the user.
4. If the service doesn't exist anymore, 404.

In general we don't like to dictate anything about how your services talk to each other, but we are thinking of ways to solve this problem for HTTP as a complete built-in solution.

Answer 3

When a service is started, it registers it's endpoint with the fabric naming service. Using the Fabric client APIs you can then ask fabric for the registered endpoints, associated with the registered service name.

So yes, just as you described your case, you would have a gateway that would accept an incoming URI for connection, and then use that path information as the service name lookup, to then create a proxy connection between the incoming request and the actual internal endpoint location.

Looks like the team as posted one the samples that shows how to do this: https://github.com/Azure/servicefabric-samples/tree/master/samples/Services/VS2015/WordCount

Answer 4

We implemented a HTTP gateway service for this purpose as well. To make sure we can have one HTTP gateway for any internal protocol, we implemented the gateway for HTTP based internal services (like ASP.NET WebAPIs) using an ASP.NET 5 middleware. It routes requests from e.g /service to an internal Service Fabric address like fabric:/myapp/myservice by using the ServicePartitionClient and some retry logic from CommunicationClientFactoryBase.

We open-sourced this middleware and you can find it here: https://github.com/c3-ls/ServiceFabric-HttpServiceGateway

There's also some more documentation in the wiki of the project.

Answer 5

This feature is build in for http endpoints, starting with release 5.0 of service fabric. The documentation is available at https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reverseproxy/

Answer 6

I am wondering instead of exposing Rest at N+ services, use the default comm stack everywhere inside service fabric (or as much as possible to keep thing simple internally). Expose REST only at the edge entry point(s) into the fabric. Use a std stateless web 2.x api which wraps the fabric proxies of your services and actors, and/or use a fabric service exposing rest in the same way. Aggregate your apis as needed in the forward facing Rest service(s). Not sure I seen the need yet for additional overhead of an aggregator for naming redirection (maybe I am missing the thought). Then it would seem just an exercise in organizing (and securing) rest endpoint(s) with a desired namespace (i.e. façade pattern).