Demystifying Microservices With Spring Cloud
Demystifying Microservices With Spring Cloud
Take a look of how a typical distributed system of Spring Cloud microservices works and communicates, including health checks.
Join the DZone community and get the full member experience.Join For Free
Microservices architecture has been the hot topic for a couple of years. However, the proper implementation of this architecture has been always obfuscating to newbies like me. After working on a couple of projects with this architecture and contribution to open source project Abixen Platform, I thought why not to create a simpler version of an application that helps others to hack out the mystery of current enterprise buzzword micro-services with less effort. This post is about the practical implementation of microservice architecture with Spring Cloud Technologies.
Microservices: An Architectural Style
I am a big fan of concise, but very informative, Microsoft's documentation about architectural styles which says, "A microservices architecture consists of a collection of small, autonomous services. Each service is self-contained and should implement a single business capability." The following diagram explains more than thousands of words.
Source: Microsoft Docs.
- Services can be deployed independently. A team can update an existing service without rebuilding and re-deploying the entire application.
- Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence.
- Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services.
- Services don't need to share the same technology stack, libraries, or frameworks.
Besides for the services themselves, following are some other components that appear in a typical microservices architecture:
Management: The management component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth.
Service Discovery: Maintains a list of services and which nodes they are located on. Enables service lookup to find the endpoint for a service.
API Gateway: The API gateway is the entry point for clients. Clients don't call services directly. Instead, they call the API gateway, which forwards the call to the appropriate services on the back end.
Developing microservices architecture is all about developing loosely coupled modules so that a change to one service should not require a change to another. The sample project I have developed, I'm using Spring Cloud, which has provided production grade libraries for creating microservices like child play. Below is the architectural diagram for an application which provides user-info integrated with bookmarks made by that user:
Here, UserService and BookmarkService typical microservices.
- Zuul routes the requests across services acting as a Gateway. Swagger UI is used to provide UI for API clients. You can select the specific service whose endpoint info you want to extract or try out as below:
- Eureka Registry provides the functionality of service discovery. All the services registered to this service sends continuous health pulse so that gateway can determine if the incoming requests should be forwarded to that corresponding service or not. Eureka dashboard for this application is: The dashboard has other more information including the number of CPUs, memory usage and more, which you can look into running the project.
- Hystrix Dashboard displays the health of each circuit breaker in an efficient manner. Each of Hystrix-enabled services' dashboard can be combined with Turbine.
- Configuration Server allows updates to the configuration by either polling a source for changes or for a source to push changes to the client. This is one the nicest features I'm a big fan of in Spring Cloud, which enables us to externalize the configuration and loads them to the applications when the values changes.
- Feign is a declarative web service client.
- Zipkin server provides Distributed Tracing. By default, storage for tracing is in-memory, which can be easily configured with any of storages like Cassandra or streaming processors like Kafka. The particular tracing would look like this: You can see how easily service calls can be traced to just letting it know about services to be monitored. Obviously, more information is available on this dashboard.
- Auth Server uses Spring Cloud Security which offers a set of primitives for building secure applications and services with minimum fuss. Each request gets intercepted before it gets to the service behind the gateway.
- Hystrix helps to handle failure gracefully in service interaction providing fallback method to default behavior or failure handling method. I am using Redis as a cache server to cache the requests to bookmark service to increase the performance as well as to handle the bookmark service down situation.
What We Achieved
Though it looks complex in the beginning, this architecture provides a lot of advantages over having all services in a single module. If you compare this example with the architecture specification, then you can easily see
bookmarkSvccan be easily built, deploy, redeploy and scaled independently.
- Each of the services has independent persistent modules.
- Services talk to each other via API without knowing internal details providing flexibility to developers for choosing the technology stack.
- Services have been registered to eureka registry service so that they don't need to know the physical address for communication making scaling easy.
- Services live behind the gateway which takes care forwarding request to the corresponding service.
Aren't these features exciting? Check out all the coding in GitHub repository.
In coming posts, I'll be explaining how did I configure the components to create this application. Cheers to microservices!
Published at DZone with permission of Yogen Rai , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.