Shulou(Shulou.com)05/31 Report--

How to understand the micro-service architecture of Spring Cloud and Docker, in order to solve this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a simpler and easier way.

Micro-service architecture of Spring Cloud and Docker

Functional service

The overall application is broken down into three core micro-services. These microservices are applications that are organized around certain business functions and can be deployed independently.

Relationship between services

Account Service (account Service)

Contains user input logic and validation: income / expenditure, savings and account settings.

Statistics Service (Statistical Services)

Perform calculations on the main statistical parameters and get the timeline of each account. The data point contains values normalized to the base currency and time period. These data can be used to track the cash flow dynamics of the account over its lifetime.

Notification Service (Notification Service)

Save user contact information and message settings (such as reminders and backup frequency), and the timer collects the required information from other servers and sends it to subscribers via emial.

Be careful

Each micro-service has its own database, and the persistent data of micro-service can not be accessed directly by bypassing the API provided by micro-service.

In this example, I use mongoDB as the database for each microservice, and the user can choose the appropriate database according to the type of microservice.

Synchronous REST API is used to communicate between micro-services and micro-services, and the usual practice is to communicate in an interactive style, such as retrieving data through synchronous GET requests, creating / updating operations using asynchronous methods through Message Broker, in order to separate service and buffer messages, with the goal of achieving ultimate consistency.

Infrastructure Services (Infrastructure Services)

There are many common patterns in distributed systems that can help us describe core services. Spring cloud provides powerful tools to help spring boot applications implement these patterns, which are briefly described below:

System architecture

Config Service (configuration Service)

Spring cloud config is a centralized configuration service in distributed systems.

In this project, I use native profile to load the configuration file from the local classpath, and you can view the config service resources under the shared directory. For example, when Notification-service requests its configuration information, the configuration service returns the following two files: shared/notification-service.yml and shared/application.yml (this file will be shared by all applications).

Client-side Usage (used by the client)

As long as you build a Spring Boot application with spring-cloud-starter-config dependencies, the rest will be automatically configured

There is no need for any other built-in properties in the application, just a bootstrap.yml file that contains the name of the current application and the url of the Config service

Spring:

Application:

Name: notification-service

Cloud:

Config:

Uri: http://config:8888

Fail-fast: true

Spring cloud config supports dynamic modification of App configuration information, such as adding @ RefreshScope annotations to EmailService bean, which means that you can modify the body and title of email without recompiling or restarting Notification service. The specific operations are as follows:

1. Modify the relevant attributes on the config server

2. Execute a refresh request to the Notification service:

Curl-H "Authorization: Bearer # token#"-XPOST http://127.0.0.1:8000/notifications/refresh

You can also automate this process using webhooks

Be careful

1. Dynamic refresh has the following restrictions: @ RefreshScope annotations cannot take effect on @ Configuration classes and @ Scheduled methods.

2. The fail-fast attribute means that if the service cannot connect to the config service, the service will fail immediately during startup. This is useful when starting all services together.

Auth Service (authentication service)

Authorization responsibilities are fully extracted to a separate server, which grants OAuth3 tokens to the back-end resource service. The authentication server is used for user authorization and secure machine-to-machine communication on the periphery.

In this project, I use password credentials as the authorization type for user authorization (because it is only used by the native application UI), and client credentials as the authorization type for microservice authorization.

Spring Cloud Security provides convenient annotation and automatic configuration, making it easy to implement from both the server and the client. You can learn more in the documentation and view the configuration details in the Auth Server code.

The client is similar to traditional session-based authentication, where you can get Principal object information from request, verify the user's role, and use the @ PreAuthorize annotation for regular-based access control.

Every client (account-service, statistics-service, notification-service and browser) has a scope attribute: server: backend service, ui: browser. Controller can be prevented from being accessed externally through scope:

@ PreAuthorize ("# oauth3.hasScope ('server')")

@ RequestMapping (value = "accounts/ {name}", method = RequestMethod.GET)

Public List getStatisticsByAccountName (@ PathVariable String name) {

Return statisticsService.findByAccountName (name)

}

API Gateway

In this example, there are three core services that expose external API to the client, but in the real world, the number of core services increases dramatically as the system complexity increases. There may be a complex page that requires hundreds of services to be called to render it.

In theory, the client should request each microservice directly, but there are many challenges and limitations in this approach. For example, the client needs to know the addresses of all microservices, execute http calls independently for each message, and then merger the information on the client. Another problem is non-web-friendly protocols, which might be used on the backend.

Usually a better implementation is to use API Gateway, which is a single entry into the system to route requests to the appropriate back-end services or to invoke multiple back-end services and aggregate the results back to the client. API Gateway will also be used for permission verification, monitoring, stress testing, service migration, static response processing and active traffic management.

The Netflix open source project edge service can be used in the Spring cloud project through the @ EnableZuulProxyannotation annotation

In this example, we use Zuul to store static content (UI application) and route requests to the appropriate microservice. Here is the routing configuration of Notification service:

Zuul:

Routes:

Notification-service:

Path: / notifications/**

ServiceId: notification-service

StripPrefix: false

This configuration means that all requests starting with / notifications are routed to the Notification service,Notification service address and are not hard-coded. Zuul uses the service discovery mechanism to locate the Notification service instance and achieve load balancing for access.

Service Discovery (Service Discovery)

The network location of the service instance can be determined automatically through service discovery (due to the expansion of the number of instances and the failure / update of the instance, the network address of the service instance will change)

The key part of service discovery is service registration. In this example, we use Netflix Eureka to implement this function. Eureka is a good example based on the client service discovery pattern, where the client is responsible for determining the location of available service instances (using the registration server) and load balancing requests.

In Spring Boot, you can use spring-cloud-starter-eureka-server dependencies to build Eureka Registry with @ EnableEurekaServer annotations and simple configuration properties.

Client support requires the use of @ EnableDiscoveryClient annotations and the addition of bootstrap.yml files containing application names

Spring:

Application:

Name: notification-service

When the application starts, it registers in Eureka Serve and provides relevant meta-data information (such as host,port, health check page, home page, etc.). Eureka receives heartbeat information from each instance of the microservice, and if the heartbeat information is not received within the agreed time (configurable), the instance will be removed by the registry.

Eureka provides a simple page where you can view the running microservices and the corresponding instances of these services

Eureka

Load Balancer, Circuit Breaker, and Http Client (load balancing, circuit breaker and http Client)

Netflix OSS provides another excellent set of tools.

Ribbon

Ribbon is a client-side load balancer through which you can control HTTP and TCP client requests. Compared with traditional load balancers, each online call does not require additional jumps, and you can directly contact the services you need.

Eureka itself is integrated with Spring Cloud and Service Discovery and is available right out of the box. Eureka Client provides a dynamic list of available services that Ribbon can use to achieve load balancing.

Hystrix

Hystrix is the implementation of fuse mode, which controls latency and failure through network access dependencies. The core idea is to stop the cascade failure in the distributed environment of a large number of micro-services, which helps the system to recover as soon as possible.

In addition to providing fuses, Hystrix can also add a fallback method that returns the default value if the main command fails.

Furthermore, Hystrix generates metrics of execution results and latency for each command, which we can use to monitor system behavior.

Feign

Feign is a declarative HTTP client that integrates seamlessly with Ribbon and Hystrix. In fact, with a Spring-Cloud-Starter-Feign dependency and @ EnableFeignClients annotation, you can have a complete set of load balancers, circuit breakers, and HTTP clients with a reasonable default configuration that is readily available.

Here is a column of Account Service:

@ FeignClient (name = "statistics-service")

Public interface StatisticsServiceClient {

@ RequestMapping (method = RequestMethod.PUT, value = "/ statistics/ {accountName}", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)

Void updateStatistics (@ PathVariable ("accountName") String accountName, Account account)

}

The above example specifies the required service id-statistics-service, relying on the automatic discovery of Eureka

Monitor Dashboard

In this project configuration, each microservice equipped with Hystrix pushes metrics to Turbine through Spring Cloud Bus (using an AMQP proxy). Monitoring project is just a small Spring boot application that includes Turbine and Hystrix dashboards.

Let's look at the system behavior under different loads: Account service calls Statistics service, and the Statistics service response simulates different delays. The response timeout threshold is set to 1 second.

Monitor Dashboard

Log Analysis

Centralized logging is very effective in analyzing problems in distributed systems. The technology stacks of Elasticsearch, Logstash, and Kibana let you easily search and analyze your logs, system utilization, and network activity data. The relevant description can be found in this article.

Security

Advanced security configuration is beyond the scope of this proof-of-concept project. To more realistically simulate a real system, consider using https and JCE keystores to encrypt microservice passwords and configure server property content (see the documentation for more information).

Infrastructure Automation (basic setup Automation)

Deploying interdependent micro-services is much more complex than deploying an overall application. It is important to have a fully automated infrastructure. With continuous delivery, we can get the following benefits:

The ability to release software at any time.

Any build may eventually become a release.

Build artifacts at once and deploy as needed

This is to implement a simple continuous delivery workflow in this project:

Continuous delivery process

In this configuration, Travis CI establishes a tagged image for each successful Git push. As a result, each microservice on Docker Hub always has the latest image, while the old image is marked with Git commit hash. Deploying them is easy and quick to roll back if necessary.

How to Run All the Things?

You will launch 8 Spring Boot applications, 4 MongoDB instances and RabbitMq. Make sure you have 4 Gb RAM on your machine. With Gateway,Registry,Config,Auth Service and Account Service, you can always run important services.

Before we begin

Install Docker and Docker Compose.

Export environment variables: CONFIG_SERVICE_PASSWORD, NOTIFICATION_SERVICE_PASSWORD, STATISTICS_SERVICE_PASSWORD, ACCOUNT_SERVICE_PASSWORD, MONGODB_PASSWORD

Production Mode

In this mode, the latest images will be fetched from the docker hub, simply copy the docker-compose.yml and click docker-compose up-d

Development Mode

If you want to build the image yourself (for example, you have made some changes in the code), you must clone all repository and build using Maven. Then run

Docker-compose-f docker-compose.yml-f docker-compose.dev.yml up-d

Docker-compose.dev.yml inherits docker-compose.yml and can build images locally and expose all container ports to facilitate development.

Important Endpoints

Ilocalhost:80-Gateway

Ilocalhost:8761-Eureka Dashboard

Ilocalhost:9000-Hystrix Dashboard

Ilocalhost:8989-Turbine stream (source for Hystrix Dashboard)

Ilocalhost:15672-RabbitMq management

Be careful

All Spring Boot applications rely on the running Config Server to start. However, we can start all containers at the same time, because the docker-compose option always has the fail-fast and restart properties of Spring Boot. This means that all dependent containers will attempt to restart until the configuration server is up and running.

In addition, after all applications are started, the service discovery mechanism will take some time, and the service will not be discovered by the client immediately until the instance, the Eureka server and the client have the same metadata in their local cache, so three heartbeats may be required. The default heartbeat cycle is 30 seconds.

This is the answer to the question on how to understand the micro-service architecture of Spring Cloud and Docker. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.