Spring Cloud contains many things, configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state,just to name a few. Beginners will get puzzled where to start(at least I was). I wrote a “Hello world” demo using Spring Cloud Finchley.M7 which is based on Spring 5 and Spring Boot 2, to give new comers of Spring Cloud a taste of microservice architecture.
The project can be found here in github. It is self-contained, and sub-projects constituting each component can be run as a normal Java application, depending on no other services outside of it.
The demo contains following minimum components that a microserivce architecture should have.
1.A service registry: The server who holds the meta information of all serives instances. A service instance reports its meta information(including service name, host and port, etc) to a service registry on startup and its status is monitored by the service registry. Clients of the service registry will get the information of other service intances.
To keep this demo simple, a single instance of Eureka Server is used.
2.A service gateway: The single entry point for all clients. The API gateway handles requests in one of two ways. Some requests are simply proxied/routed to the appropriate service. It handles other requests by fanning out to multiple services.
In the demo, all requests to the path /s1 are proxied/routed to service1 instances retrieved from the service registry above.
Spring Cloud Gateway is used, which is built on Spring Framework 5, Project Reactor and Spring Boot 2.0,using non-blocking APIs.Websockets are also supported and it’s a much better developer experience since it’s tightly integrated with Spring.
To implement a gateway, another option is Zuul, but Zuul is built on servlet 2.5 (works with 3.x), using blocking APIs. It doesn’t support any long lived connections, like websockets.
3.microservices: There are three microservices in the demo, service1, service2, service3. Service1 calls service2 and service3 in a reactive(non-blocking) way, and aggregate the responses to give the final response of service1.
Some trivial figures to help understanding the demo.
1.The communications of service registry and service registry client
2.the processing flow of a client accessing the path of “/s1/”
