Spring Boot

What benefits Spring Framework provides:

• Dependency injection: it’s very critical to provide a loosely coupled application
• Duplication/Plumbing Code

o   Spring JDBC
o   Spring MVC
o   Spring AOP
o   Spring ORM
o   Spring JMS
o   Spring Test

Pillars of a spring boot project:

• Auto Configuration: When we use Spring MVC, we need to configure component scan, dispatcher servlet, a view resolver, web jars (for delivering static content) among other things.
Spring Boot looks at

o   Frameworks available on the CLASSPATH
o   Existing configuration for the application. 

Based on these, Spring Boot provides basic configuration needed to configure the application with these frameworks.
All auto configuration logic is implemented in spring-boot-autoconfigure.jar.
As soon as we add Spring Boot Starter Web as a dependency in our project, Spring Boot Autoconfiguration sees that Spring MVC is on the classpath. It autoconfigures dispatcherServlet, a default error page and webjars.
• Spring Boot Starter project
All web application needs Spring MVC, Jackson Databind (for data binding), Hibernate-Validator (for server side validation using Java Validation API) and Log4j (for logging)along with compatible versions of all these frameworks.

o   spring-boot-starter-web-services - SOAP Web Services
o   spring-boot-starter-web - Web & RESTful applications
o   spring-boot-starter-test - Unit testing and Integration Testing
o   spring-boot-starter-jdbc - Traditional JDBC
o   spring-boot-starter-hateoas - Add HATEOAS features to your services
o   spring-boot-starter-security - 
 Authentication and Authorization using Spring Security.
 Basic Authentication is the default.
 Using default security password, Default userid is user. Default password is printed in the server start up log.
o   spring-boot-starter-data-jpa - Spring Data JPA with Hibernate
o   spring-boot-starter-cache - Enabling Spring Framework’s caching support
o   spring-boot-starter-data-rest - Expose Simple REST Services using Spring Data REST
o   spring-boot-starter-actuator - To use advanced features like monitoring & tracing to your application out of the box
o   spring-boot-starter-undertow, spring-boot-starter-jetty, spring-boot-starter-tomcat - To pick your specific choice of Embedded Servlet Container
o   spring-boot-starter-logging - For Logging using logback
o   spring-boot-starter-log4j2 - Logging using Log4j2

• Spring Boot Starter Parent

o   All Spring Boot projects typically use spring-boot-starter-parent as the parent in pom.xml.
o   Spring Boot Starter Parent defines spring-boot-dependencies as the parent pom. It inherits dependency management from spring-boot-dependencies. Details in the next section.
o   Parent Poms allow you to manage the following things for multiple child projects and modules:
 Configuration - Java Version and Other Properties
 Dependency Management - Version of dependencies
 Default Plugin Configuration
o   A few other settings related to encoding and source, target version are also set in the parent pom.
<java.version>1.6</java.version><resource.delimiter>@</resource.delimiter> <!-- delimiter that doesn't clash with Spring ${} placeholders --><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding><maven.compiler.source>${java.version}</maven.compiler.source><maven.compiler.target>${java.version}</maven.compiler.target>
o   Spring Boot Starter Parent inherit from spring-boot-dependencies, it shares all these characteristics as well.
<properties><activemq.version>5.13.4</activemq.version>...<ehcache.version>2.10.2.2.21</ehcache.version><ehcache3.version>3.1.1</ehcache3.version>...<h2.version>1.4.192</h2.version><hamcrest.version>1.3</hamcrest.version><hazelcast.version>3.6.4</hazelcast.version><hibernate.version>5.0.9.Final</hibernate.version><hibernate-validator.version>5.2.4.Final</hibernate-validator.version><hikaricp.version>2.4.7</hikaricp.version><hikaricp-java6.version>2.3.13</hikaricp-java6.version><hornetq.version>2.4.7.Final</hornetq.version><hsqldb.version>2.3.3</hsqldb.version><htmlunit.version>2.21</htmlunit.version><httpasyncclient.version>4.1.2</httpasyncclient.version><httpclient.version>4.5.2</httpclient.version><httpcore.version>4.4.5</httpcore.version><infinispan.version>8.2.2.Final</infinispan.version><jackson.version>2.8.1</jackson.version>....<jersey.version>2.23.1</jersey.version><jest.version>2.0.3</jest.version><jetty.version>9.3.11.v20160721</jetty.version><jetty-jsp.version>2.2.0.v201112011158</jetty-jsp.version><spring-security.version>4.1.1.RELEASE</spring-security.version><tomcat.version>8.5.4</tomcat.version><undertow.version>1.3.23.Final</undertow.version><velocity.version>1.7</velocity.version><velocity-tools.version>2.0</velocity-tools.version><webjars-hal-browser.version>9f96c74</webjars-hal-browser.version><webjars-locator.version>0.32</webjars-locator.version><wsdl4j.version>1.6.3</wsdl4j.version><xml-apis.version>1.4.01</xml-apis.version></properties>

What is REST?

REST stands for REpresentational State Transfer. REST specifies a set of architectural constraints. Any service which satisfies these constraints is called RESTful Service.
The five important constraints for RESTful Web Service are

• Client - Server: There should be a service producer and a service consumer.
• The interface (URL) is uniform and exposing resources.
• The service is stateless.
• The service results should be Cacheable. HTTP cache, for example.
• Service should assume a Layered architecture. Client should not assume direct connection to server - it might be getting info from a middle layer - cache.

Fault Tolerance

When we build a microservices architecture, there are a large number of small microservices, and they all need to communicate with one another.
Let’s say Microservice5 is down at some point of time. The solution to this problem is to have a fallback in case of failure of a microservice. This aspect of a microservice is called fault tolerance.
A popular framework used to implement fault tolerance is Hystrix, a Netflix open source framework. Here is a code example of the same:

@GetMapping("/fault-tolerance-example")
@HystrixCommand(fallbackMethod="fallbackRetrieveConfguration")
public LimitConfiguration retrieveConfiguration() {
        throw new RuntimeException("Not Available");
}
public LimitConfiguration fallbackRetrieveConfiguration() {
        return new LimitConfiguration(999, 9);
}

Here, if retrieveConfiguration() fails, then fallbackRetrieveConfiguration is called, which returns a hardcoded LimitConfiguration instance:
Difference between catching exception and Hystrix
• Metrics and Dashboarding provided Out of the Box which can help you peek into your system and dependent connection
• Implements BulkHead by using different Thread Pools
• Lower maintenance cost
• Health check ability. It provides a health check class which plugins with Health monitoring APIs
• The main difference is that Hystrix opens the circuit (it is an analogy to electrical circuits) when it detects an error and does not invoke downstream services until sometime has elapsed. This behavior prevents an avalanche of errors in cascading. It is similar to a smart traffic light that turns red and doesn't let you pass because it knows that you are going to have an accident a little later. After a configurable time, the circuit is closed again. You can see 'Circuit opened / closed' at Hystrix dashboard:

load balancing algorithms

Ribbon offers wide variety of client side load balancing algorithms to choose from.

naming server

Eureka Naming server offers naming server to register all the microservices, which can be used to fetch the address of the registered microservices.

Auto scaling

You can containerize each microservice using Docker and create an image.
Kubernetes has the capability to manage containers. Kubernetes can be configured to auto scale based on the load. Kubernetes can identify the application instances, monitor their loads, and automatically scale up and down.

Centralized Logging

Using Log Streams is one way to implement centralized logging. The common way to implement it is to stream microservice logs to a common queue. Distributed logging server listens to the queue and acts as log store. It provides search capabilities to search the trace.
Popular Implementations
Some of the popular implementations include
• the ELK stack (Elastic Search, Logstash and Kibana) for Centralized Logging
• Zipkin, Open Tracing API And Zaeger for Distributed Tracing

API Gateway

In microservices, we route all requests - both internal and external - through API Gateways. We can implement all the common features like authentication, logging, auditing, and rate limiting in the API Gateway.
For example, you may not want Microservice3 to be called more than 10 times by a particular client. You could do that as part of rate limiting in the API gateway.
You can implement the common features across microservices in the API gateway. A popular API Gateway implementation is Zuul API Gateway.

Centralized Configuration

Configuration for all microservices (for all environments) is stored at one place - a centralized configuration store.
When a microservice needs its configuration, it provides an id at launch - a combination of microservice name and the environment.
Spring Cloud Config Server is one of the popular implementations of a cloud config server