Let’s with some of the very basic components in Spring Cloud and then head our path of re-phrasing the application using Spring Cloud constructs. Netflix¬†the online streaming service has been a premier contributor towards a large number of the Spring Cloud components, no surprise if we see that most of the package imports would be of netflix. I would say Netflix Tech Blogs¬†are a must follow for anyone aspiring to read more on their technology contribution.

Spring Cloud is a comprehensive set of components built specifically to build cloud based applications using the battle tested and proven Spring Framework.

While building microservice format applications its advisable to follow the 12factors defined.

Well, though there are over 40 components/sub-projects; some of the key Spring Cloud components we will discussing and consuming in our eStore application would be –

  • Spring Cloud Config Server – A centralized git-backed configuration management system
  • Spring Cloud Discovery Server – A cloud based service discovery system for quick publish and discovery of services within the system
  • Zuul API Gateway – A cloud API Gateway which can be even used as a reverse-proxy for all the services within the system
  • Spring Cloud Config Client – All the services which need to look and act as a config clients annotate themselves
  • Spring Cloud Discovery Client – All the services within the system which need be registered to the Discovery system and discovered by other services annotate themselves
  • Feign Rest Client – A Rest Client which understand the Spring Cloud eco-system and can call REST services either directly or through service discovery
eStore cloud microservices

eStore cloud microservices

The above image depicts a typical architecture of an application built with Spring Cloud. Lets dig deep into what each component does within the entire system. Each of the services have been built with a client-side load balancer which helps scale the service independently.

The story goes like this,

  • The Config Service is a git-backed centralized configuration service, where configuration of all the services can be maintained and retrieved based on Spring Profiles, like a configuration for each of the deployment environment like Dev, QA, STG, Beta and PROD can be maintained. While the service is spun we can set one of the Spring Profiles active and the respective configuration are then served by the Config Service.
  • The Discovery Service enables services to be published and discovered by other services.
  • The API Gateway acts as a proxy and reverse-proxy for all the API’s exposed by various services within the system like User Service, Catalog Service and Order Service. It would act as a SPOE (Single Point Of Entry), there-by enabling AuthN, AuthZ and fine-grained control of API request coming into the system. Any system failures can also be gracefully handled using Spring Cloud Hystrix, a programmable; configurable circuit breaker system.
  • All the participating services which intend themself to be discovered annotate their Main-Class (aka Class annotated with SprintBootApplication) with¬†EnableDiscoveryClient.
  • The StoreFront UI Service no longer need be an application built on Java, since its only catering the UI of the application. It can now be built on NodeJS and make calls to the API’s on the API Gateway Service.

I hope the code speaks to itself. There are other strategies I haven’t talked on in this article like Virtualization, Containerization, PaaS. Spring Cloud off late even supports polyglot development of microservices using Spring Sidecar, where microservices can be developed using other programming languages & frameworks like NodeJS, RoR (Ruby on Rails) etc. The same is even supported while building microservices on PaaS like Pivotal CloudFoundry, IBM Bluemix etc.

Pages: 1 2 3 4