How and why I built A springboot/netflix microservices architecture
Spring Cloud Netflix provides Netflix OSS integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with battle-tested Netflix components. The patterns provided include Service Discovery (Eureka), Circuit Breaker (Hystrix), Intelligent Routing (Zuul) and Client Side Load Balancing (Ribbon).
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
Spring Cloud focuses on providing good out of box experience for typical use cases and extensibility mechanism to cover others.
- Distributed/versioned configuration
- Service registration and discovery
- Service-to-service calls
- Load balancing
- Circuit Breakers
- Global locks
- Leadership election and cluster state
- Distributed messaging
High Level Architecture****
The proposing architecture uses AWS (amazon web services), with the following components:
- ELB: An Elastic Load balancer, to balance all the request to the microservices. The user, do a request to a single point (ELB).
- A set of EC2 instances that will have the spring Cloud Gateway service: The gateway pattern service is used to retrieve data from multiple services with a single request, this means the load balancer will only know and make calls to the gateway, in this way we can isolate the important services and protected them inside the AWS cloud. When a user makes a request, the load balancer will call the gateway and then the gateway will call the proper microservice.
- A set of EC2 instances to serve all the microservices available in the cloud. This EC2 instances are only accessed by the gatway.
- A S3 service: We will use this service to store the shared files used by all microservices on the cloud (images, texts, media, etc). For more info see Amazon S3 (Simple Storage Service).
The proposed architecture is formed by 5 diferent kinds of microservices (service patterns): Gateway, Discovery, Authentication, Configuration, Clients.
Gateway (Routing and Filtering)****
Routing in an integral part of a microservice architecture. For example, / may be mapped to your web application, /api/users is mapped to the user service and /api/shop is mapped to the shop service. Zuul is a JVM based router and server side load balancer by Netflix.
Spring Cloud has created an embedded Zuul proxy to ease the development of a very common use case where a UI application wants to proxy calls to one or more back end services. This feature is useful for a user interface to proxy to the backend services it requires, avoiding the need to manage CORS and authentication concerns independently for all the backends.
In the architecture that we are proposing, there will be a microservice acting as the Gateway to the external world. It´s the only one that will be exposed to the final users, protecting the internal microservices to be accesed from outside. The gateway will be called by the front end (throught the AWS Elastic Load Balancer), and it will route the call to the proper service depending of what is requested.
Service Discovery is one of the key tenets of a microservice based architecture. Eureka is the Netflix Service Discovery Server and Client. The server can be configured and deployed to be highly available, with each server replicating state about the registered services to the others. When a client registers with Eureka, it provides meta-data about itself such as host and port, health indicator URL, home page etc. Eureka receives heartbeat messages from each instance belonging to a service. If the heartbeat fails over a configurable timetable, the instance is normally removed from the registry.
In this architecure there will be one aureka server per EC2 instance. As you can see in the diagram 1, there is an "EC2-Spring cloud services" that will contains all the servicews (excpet the gateway), including the discovery one.
So the discovery service can be seen as a phone book in which each service registers itself with the service registry and tells the registry where it lives (host, port, node name) and perhaps other service-specific metadata (things that other services can use to make informed decisions about it), so if another microservice (inluding the gateway) wants to use it/call it, just need to ask its ifnromation to the discovery service.
Configuration Service (Optional)****
Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate.
The authenticarion service is a microservice that is in charge to authenticate, generate JWT tokens and provides an enpoint to validate tokens (JWK). It has its own database with the users, scopes and keys.
A microservice that is ready to work so it registers itself to the Eureka server e.g. an API for some app, or some application that goes to the server and asks for directions to a specific microservice.