What is Spring Cloud?
Spring Cloud is a toolset provided by Pivotal to simplify building distributed systems. Spring Cloud introduces the concepts of Cloud Connector and Service Connector. A cloud platform connector is an interface that needs to be implemented by a cloud platform provider so that other modules in the library can work with that cloud platform.
Spring Boot
The most important thing about Spring Cloud is that it works with Spring Boot, which can help developers create Spring-based applications and services more easily.
As can be seen from the Boot in the name of the Spring Boot project, the role of Spring Boot is to create and start a new project based on the Spring framework. Spring Boot will select the most suitable Spring sub-projects and third-party open source libraries for integration. Most Spring Boot applications need very little configuration to get up and running quickly. Spring Boot includes the following features:
Create stand-alone Spring applications.
Embeds directly into a Tomcat or Jetty server, no need to deploy a WAR file.
Provides a recommended base POM file to simplify Apache Maven configuration.
Automatically configure the Spring framework based on project dependencies as much as possible.
Provides features that can be used directly in production, such as performance metrics, application information, and application health checks.
No code generation and no XML configuration files.
Service Discovery and Smart Routing
Each service contains a specific microservice architecture. When you are building a microservices architecture on Spring Cloud, here are a few basic concepts that need to be clarified first. First, you need to create two basic services, Configuration Service and Discovery Service. As shown below:
The image above illustrates four microservices and the dependencies between each service.
The Configuration service is at the top, marked in yellow, and is depended on by other microservices.
The Discovery service is at the lowest end, marked in blue, and is also depended on by other services.
The two microservices marked in green are the two use cases we use in this series of blog posts: Movies and Movie Viewing Suggestions.
Configuration Service
Configuration Service is a very important component in microservice architecture. As the 12-factor application theory says, the configuration of a microservice application should be stored in the environment, not in the local project.
The reason the Configuration service is an essential base component is because it provides service management for all base services that are peer-to-peer and retrieved.
Suppose we have multiple deployment environments. For example we have a staging environment and a production environment, the configuration for each environment will be different. Each configuration service will have a separate Git repository to store the environment configuration. No other environment can access this configuration repository, it just provides configuration services running in that environment.
When the Configuration service starts, it will point to the path configured according to the configuration file and start the corresponding service. Each microservice runs by reading the specific environment in its own configuration file. In this process, the configuration is managed internally and centrally through version management, and changing the configuration does not require restarting the service.
Through the service terminal provided by Spring Cloud, you can change the environment configuration and send a refresh signal to the Discovery service (discovery service), and all users will be notified of the new configuration.
Discovery Service
Discovery Service is another important component of microservice architecture. Discovery Service manages numerous service instances running in containers, and these instances work in a clustered environment. In these applications, we use the client-side approach called service-to-service. As an example, I use Spring Cloud Feign, a client-side open source project based on Restful-style microservices, derived from the Netflix OSS project.
@FeignClient("movie") public interface MovieClient { @RequestMapping(method = RequestMethod.GET, value = "/movies") PagedResources findAll(); @RequestMapping(method = RequestMethod.GET, value = "/movies/{id}") Movie findById(@RequestParam("id") String id); @RequestMapping(method = RequestMethod.POST, value = "/movies", produces = MediaType.APPLICATION_JSON_VALUE) void createMovie(@RequestBody Movie movie); }
In the above example, I created a Feign client and mapped a REST API method to expose the movie service. Using the @FeignClient annotation, I can declare the client API I want to create for the movie microservice. [email protected] �Declare a URL rule on the method to describe the routing rules of a REST API.
What's even more exciting is that this is all easy in Spring Cloud, all I have to do is know the service ID to create my Feign client. The URL address of the service is automatically configured in the runtime environment, because each microservice in the cluster will be registered by binding the serviceid at startup.
Other services in the microservice architecture also run in the way mentioned above. I only need to know the serviceid of the communication service, all operations are automatically bound by Spring.
API Gateway
API Gateway service is another important component of Spring Cloud (for its introduction, you can read this article). It can be used to manage domain entities in cluster services. The green hexagons in the figure below are the data-driven services we provide, which are mainly used to manage our own entity classes and databases. By adding the API Gateway service, we can create a proxy-exposed interface for each API route through the green-colored service below.
Suppose both the recommendation service and the movie service expose their own REST APIs on their own managed domain entities. API gataway routes through the discovery service and proxy-based API methods injected from other services. In this way, including the recommendation service and the movie service will have a fully defined route to the local microservice through the exposed REST API. API Gateway will redefine routing requests to service instances, all of which are HTTP-based.
example project
I have created an example project on GitHub: https://github.com/kbastani/spring-cloud-microservice-example, this project is an end-to-end cloud-native platform that uses Spring Cloud to build the actual microservice architecture.
basic concept:
Integration testing with Docker
Hybrid persistence
Microservice Architecture
service discovery
API Gateway
Docker
Each service is built and deployed using Docker. End-to-end integration testing on a development machine using Docker Compose.
Hybrid persistence
Hybrid persistence actually means using multiple databases for storage. Different microservice instances use their own database and communicate via REST service or message bus. For example, you can build microservices based on the following databases:
Neo4j (graphical)
MongoDB (documented)
MySQL (association)
Microservice Architecture
This example demonstrates how to create a new application using microservices. Since each microservice in the project has only a single parent project. What developers get for this is that each microservice can be run and developed locally. Adding a new microservice is very simple, when the microservice is discovered it will automatically discover the runtime cluster environment.
Service Discovery
The project contains two discovery services, one in Netflix Eureka and the other using
Consul from Hashicorp. A variety of discovery services provide a variety of options, one is to use (Consul) to do DNS service clustering, and the other is (Consul) proxy-based API gateway.
API Gateway
Each microservice is associated with Eureka to retrieve API routes across the cluster. Using this strategy, each microservice running on the cluster only needs to load balance and expose interfaces through a common API gateway, and each service will automatically discover and forward routing requests to its own routing service. This proxy technology facilitates the development of the user interface, as the platform's complete API is mapped to the proxy service through its own host.
Docker instance
The example below will be built with Maven, using Docker to build container images for each microservice. We can elegantly use Docker Compose to build a full microservice cluster on our own host.
start building
Before doing so, please move to the project's GitHub repository.
https://github.com/kbastani/spring-cloud-microservice-example
Clone or fork the project and download the source code to your computer. After downloading, you need to use Maven and Docker to compile and build the local container image.
Download Docker
First, download Docker if you don't already have it. You can follow this guide to get Docker: https://docs.docker.com/installation/, then install and run it on your development machine.
Of course you also need to install Docker Compose (https://docs.docker.com/compose/), this guide will help you: https://docs.docker.com/compose/install/.
Environmental requirements
To be able to run the example program, you need to install the following software on your development machine:
Maven 3
Java 8
Docker
Docker Compose
Build the project
To build the current project through the command line, run the following command in the root directory of the project:
$ mvn clean install
The project will download the corresponding dependency jar package according to each project declaration in pom.xml. Each service will be built, and the Maven Docker plugin will automatically build each container image from the local Docker Registry. Docker will clean up the corresponding resources by running mvn clean install according to the command line after the build is successful.
After the project builds successfully, you will see the following output:
Start the cluster with Docker compose
Now that each image is successfully built, we use Docker Compose to speed up launching our cluster. I have included the yaml file for Docker Compose into the project, you can get it from GitHub.
Now we start the microservice cluster with the following command line:
$ docker-compose up
If everything is configured correctly, each container image will run as a virtual container on Docker and an auto-discovered network service. You will see a series of log output as they start sequentially. This may take a while to complete, depending on the capabilities of the machine running your instance program.
Once the container starts successfully, you will see the application service registered through the Discovery service through the Eureka host.
Copy and paste the following command from the command line terminal into the $DOCKER_HOST environment variable defined in Docker.
$ open $(echo \"$(echo $DOCKER_HOST)\"| \sed 's/tcp:\/\//http:\/\//g'| \sed 's/[0-9]\{4,\}/8761/g'| \sed 's/\"//g')
If Eureka starts correctly, the browser will start and open the Eureka service dashboard, as shown in the following figure:
We will see each running service instance and status. Use the following commands to get data-driven services, such as movie services.
$ open $(echo \"$(echo $DOCKER_HOST)/movie\"| \sed 's/tcp:\/\//http:\/\//g'| \sed 's/[0-9]\{4,\}/10000/g'| \sed 's/\"//g')
This command will access the REST API terminal that accesses the movie service according to the proxy method provided by the navigation gateway terminal. These REST APIs are configured using HATEOAS, an interface that supports automatic discovery of services through inline links.
{ "_links" : { "self" : { "href" : "http://192.168.59.103:10000/movie" }, "resume" : { "href" : "http://192.168.59.103:10000/movie/resume" }, "pause" : { "href" : "http://192.168.59.103:10000/movie/pause" }, "restart" : { "href" : "http://192.168.59.103:10000/movie/restart" }, "metrics" : { "href" : "http://192.168.59.103:10000/movie/metrics" }, "env" : [ { "href" : "http://192.168.59.103:10000/movie/env" }, { "href" : "http://192.168.59.103:10000/movie/env" } ], "archaius" : { "href" : "http://192.168.59.103:10000/movie/archaius" }, "beans" : { "href" : "http://192.168.59.103:10000/movie/beans" }, "configprops" : { "href" : "http://192.168.59.103:10000/movie/configprops" }, "trace" : { "href" : "http://192.168.59.103:10000/movie/trace" }, "info" : { "href" : "http://192.168.59.103:10000/movie/info" }, "health" : { "href" : "http://192.168.59.103:10000/movie/health" }, "hystrix.stream" : { "href" : "http://192.168.59.103:10000/movie/hystrix.stream" }, "routes" : { "href" : "http://192.168.59.103:10000/movie/routes" }, "dump" : { "href" : "http://192.168.59.103:10000/movie/dump" }, "refresh" : { "href" : "http://192.168.59.103:10000/movie/refresh" }, "mappings" : { "href" : "http://192.168.59.103:10000/movie/mappings" }, "autoconfig" : { "href" : "http://192.168.59.103:10000/movie/autoconfig" } } }
Summarize
This is the first part of a series of blog posts on building microservices architectures with Spring Cloud and Docker. In this article, we came across the following concepts:
Service Discovery
Externalized Configuration
API Gateway
Service Orchestration with Docker Compose
In the next blog post, we'll demonstrate how to use the backend service to build a front-end application, and we'll also introduce an example of hybrid persistence, using MySQL and Neo4j.
http://www.chinacloud.cn/show.aspx?id=20968&cid=12