Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to understand the Spring Cloud micro-service architecture". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to understand the Spring Cloud micro-service architecture".

I. the development of distributed service framework

1.1 first Generation Service Framework

Representatives: Dubbo (Java), Orleans (.net), etc.

Features: closely bound to the language

1.2 second generation service framework

Representatives: Spring Cloud, etc.

Status quo: suitable for hybrid development (for example, ASP.Net Core can be integrated with Spring Cloud with the help of Steeltoe OSS), in the same year

1.3 the third generation service framework

Representative: Service Mesh (Service Grid) = > such as Service Fabric, lstio, Linkerd, Conduit, etc.

Status quo: in the rapid development, the update iteration is relatively fast

1.4 Future (visual) mainstream service architecture and technology stack

The basic cloud platform provides resource capabilities (computing, storage and network, etc.) for micro-services, the container is scheduled and orchestrated by Kubernetes as the minimum work unit, and Service Mesh (Service Grid) manages the service communication of micro-services. Finally, the business interfaces of micro-services are exposed through API Gateway.

At present, my project team is already adopting this technical architecture, the service grid uses Linkerd, and the container choreography uses K8SMagi Spring Cloud is no longer useful. But, does not mean that Spring Cloud does not have the meaning of learning, for small and medium-sized project teams, Spring Cloud is still the first choice.

II. Brief introduction of Spring Cloud

2.1 introduction to Spring Cloud minimalism

First of all, although Spring Cloud has the word "Cloud", it is not a cloud computing solution, but a toolset built on top of Spring Boot for quickly building a common pattern for distributed systems.

Second, applications developed using Spring Cloud are ideal for deployment on Docker and PaaS (such as Pivotal Cloud Foundry), so they are also called cloud native applications (Cloud Native Application). Cloud nativeness can be simply understood as a software architecture for cloud environment.

Summary: Spring Cloud is a cloud native application development tool based on Spring Boot, which provides a simple development method for configuration management, service discovery, fuses, intelligent routing, micro-agent, control bus, distributed session and cluster state management involved in JVM-based cloud native application development.

Spring Cloud has the following characteristics:

Convention is greater than configuration

Suitable for all kinds of environment

Hides the complexity of components and provides a declarative, XML-free configuration

Ready to use out of the box, quick start

Rich components and complete functions

.

As the representative framework of the second generation micro-service, Spring Cloud has been applied in many large, small and medium-sized companies in China. Many companies embrace Spring Cloud in their lines of business, while some choose to embrace Spring Cloud in part. For example, teacher Yang Bo, a senior architect of PPDAI, based on his own practical experience and in-depth investigation of Spring Cloud, and combined with the results of open source projects of domestic first-tier Internet companies, believes that some components in the Spring Cloud technology stack are still far away from production-level development, and finally puts forward a micro-service architecture technology stack for reference by small and medium-sized teams. Also known as "Micro Service Architecture Technology Stack 1.0 with Chinese characteristics":

The components involved in the above figure are not described in detail here.

2.2 Spring Cloud Core Sub-Project

Spring Cloud Netflix: core component, which can integrate multiple Netflix OSS open source suites, including the following components:

Eureka: service governance component, including service registration and discovery

Hystrix: fault-tolerant management component that implements fuses

Ribbon: service invocation component of client load balancer

Feign: a declarative service invocation component based on Ribbon and Hystrix

Zuul: gateway component that provides intelligent routing, access filtering and other functions

Archaius: externalizing configuration components

Spring Cloud Config: configuration management tool to realize externalized storage of application configuration, support client configuration information refresh, encryption / decryption configuration content, etc.

Spring Cloud Bus: events, message buses, used to propagate state changes or events in the cluster, and to trigger subsequent processing

Spring Cloud Security: a spring security-based security toolkit to add security controls to our applications

Spring Cloud Consul: encapsulates Consul operations. Consul is a service discovery and configuration tool (similar to Eureka) that integrates seamlessly with Docker containers.

.

Third, the example structure description

3.1 sample environment version

Java: JDK & JRE 1.8 8u151

Spring Boot: 1.5.15.RELEASE

Spring Cloud: Edgware.SR3 (tip: the version of Spring Cloud is named after the London subway station)

3.2 sample address and structure description

Example

3.2.1 Service Registration and Discovery-based on Eureka

Examples of this section are located at: part1_service-register-discovery

The example in this section mainly demonstrates how to implement service registration and discovery based on Eureka, including two versions:

① single node version (for development environment debugging) = > located in the eureka-service-sn (sn stands for single node) project

It should be noted here that you need to disable the self-protection mechanism of Eureka in the development environment, otherwise you will not be able to easily see the effect of service removal. You need to set it in application.yml as follows:

Eureka: server: enableSelfPreservation: false # turn off self-protection mechanism in local debugging environment

This is because Eureka considers that there may be a network partition failure in the production environment, which can cause the microservice to fail to communicate with the Eureka Server. Its architectural philosophy is that it would rather keep all microservices at the same time (both healthy and unhealthy microservices will be retained) rather than blindly cancel any healthy microservices.

② HA multi-node version (for deployment / production environment) = > located in the two projects eureka-service-ha-1 & eureka-service-ha-2

It should be noted that the application.yml of the two nodes remains the same in this version, but because the hostname of peer1 and peer2 is used, you need to set the hosts file for Windows (I assume you are using a Windows system) in the local development environment as follows:

127.0.0.1 peer1 peer2

Extension: in addition to Eureka, you can also choose a versatile Consul. About the basic concepts of Consul and server installation and configuration, you can take a look at my article ".net Core microservices based on Consul implementation service registration in discovery". Finally, I have to say that the annotations encapsulated by core components in Spring Boot and Spring Cloud are so powerful that many operations can be done directly with one annotation without too much coding.

3.2.2 client load balancing-based on Ribbon

Examples of this section are located at: part2_ client-load-balance

The example in this section mainly demonstrates how to implement client-side load balancing based on Ribbon. It is recommended to start Eureka first, and then start UserService and MovieService. Check the log by accessing the API API / log-instance of MovieService. The test results are shown below:

As can be seen from the above figure, different service nodes are accessed in turn through the client's load balancing algorithm.

3.2.3 declarative REST calls-based on Feign

Examples of this section are located at: part3_feign

The example in this section mainly demonstrates how to implement declarative calls based on Feign, including the following:

(1) basically integrate Feign for single-parameter and multi-parameter requests: located in the project movie-service

The important thing to note is that don't forget to annotate the startup class with @ EnableFeignClients

@ SpringBootApplication @ EnableDiscoveryClient @ EnableFeignClients / / to use Feign, you need to add this note public static void main (String [] args) {SpringApplication.run (MovieServiceApplication.class, args);}}

(2) the use of custom Feign configuration: located in the project movie-service-feign-customizing

The following Feign interface uses the custom configuration class FeignConfiguration.

@ FeignClient (name = "user-service", configuration = FeignConfiguration.class) public interface UserFeignClient {/ * use the annotation @ RequestLine * @ see https://github.com/OpenFeign/feign * @ param id user id * @ return user information * / @ RequestLine ("GET / {id}") User findById (@ Param ("id") Long id);}

(3) the use of Feign logs: located in the project movie-service-feign-logging

It is important to note that although Feign provides logger, its log printing only responds to the DEBUG level. There are four types of log levels, as follows:

Available values for Logger.Level:

* NONE: no logs are recorded (default)

* BASIC: only record the request method, URL, response status code and execution time

* HEADERS: based on recording the BASIC level, record the header of the request and response

* FULL: header,body and metadata for recording requests and responses

To output log printing, set the DEBUG level within application.yml:

Logging: level: # set the log level of the Feign interface to DEBUG, because Feign's Logger.Level only responds to DEBUG. Com.mbps.cd.movieservice .feign.UserFeignClient: DEBUG

Finally, the log printing effect for the FULL level is shown in the following figure:

3.2.4 Fault tolerant processing-based on Hystrix

Examples of this section are located at: part4_hystrix

This part of the example mainly demonstrates how to implement fault-tolerant processing based on Hystrix, including the following:

(1) Universal integration of Hystrix: this example is located in the movie-service project.

For common methods, you only need to add HystrixCommand annotations and define fallback methods, such as:

HystrixCommand (fallbackMethod = "findByIdFallback") @ GetMapping (value = "/ user/ {id}") public User findById (@ PathVariable Long id) {return restTemplate.getForObject ("http://user-service/" + id, User.class); public User findByIdFallback (Long id) {User user = new User (); user.setId (- 1L); user.setUsername (" Default User "); return user;}

(2) Feign uses Hystrix: this example is located in the movie-service-feign-hystrix project

For Feign, it works as an API. Fortunately, Spring Cloud integrates Hystrix with Feign by default, but it is turned off by default and needs to be manually enabled in the configuration file:

Feign: hystrix: enabled: true

In previous versions (previous versions of Dalston), it was enabled by default. As for why it is disabled by default, you can take a look at this:

Then add the fallback attribute directly to the FeignClient annotation, as shown below:

@ FeignClient (name = "user-service", fallback = FeignClientFallback.class) public interface UserFeignClient {@ GetMapping (value = "/ {id}") User findById (@ PathVariable ("id") Long id); @ Component class FeignClientFallback implements UserFeignClient {@ Override public User findById (Long id) {User user = new User (); user.setId (- 1L); user.setUsername ("Default User"); return user;}}

If you want to be able to leave a log to see the cause of a fallback in the event of a Feign fallback, you can use FallbackFactory, sample project: movie-service-feign-fallback-factory.

@ FeignClient (name = "user-service", fallbackFactory = FeignClientFallbackFactory.class) public interface UserFeignClient {@ GetMapping (value = "/ {id}") User findById (@ PathVariable ("id") Long id); @ Component class FeignClientFallbackFactory implements FallbackFactory {private static final Logger LOGGER = LoggerFactory.getLogger (FeignClientFallbackFactory.class) @ Override public UserFeignClient create (Throwable cause) {return new UserFeignClient () {@ Override public User findById (Long id) {/ * * the log is best placed in each fallback, but not directly in the create method * otherwise, when the reference starts, the log will be printed * / FeignClientFallbackFactory.LOGGER.info ("sorry, fallback. Reason was: ", cause); User user = new User (); user.setId (- 1L); user.setUsername (" Default Username "); return user;}};}}

When a fallback occurs, the log output information is as follows:

In addition, with regard to Hystrix, there is also the topic of monitoring. Here, since it is not involved in the technical architecture of my project team, interested children's shoes can pay attention to the monitoring that comes with Hystrix and aggregation monitoring based on Turbine. Reference articles: "Hystrix Monitoring Panel (Dalston version)" and "Hystrix Monitoring data aggregation".

3.2.5 API Gateway-based on Zuul

Examples of this section are located at: part5_zuul

The example in this section mainly shows how to implement an API gateway based on Zuul and mainly includes the following contents:

(1) integrate Zuul to write API gateway: located in zuul-service project

What can be tested and verified:

Routing rules: start eureka,user-service,movie-service,zuul-service in turn, and then access the user-service interface through zuul

Load balancer: start eureka in turn, multiple user-service,zuul-service, then visit user-service several times, and finally check the log information (both user-service will print hibernate log information) to verify whether the load balancing effect is achieved. PS:Zuul has built-in Ribbon to achieve load balancing.

Routing endpoints: start eureka,user-service,movie-service,zuul-service in turn, and then the browser accesses zuul-service (http://localhost:5000/routes) can get routing endpoint information

For routing endpoints, you need to change the following configuration to display the routing endpoint information properly, otherwise an error of 401 will be reported:

Management: security: enabled: false # defaults to true, changed to false so that you can see the routes routing configuration: examples mainly demonstrate routing prefixes, global sensitivity settings, and routing rules settings for large file upload: for very large file uploads (such as 500m), you need to improve the timeout setting in Zuul # the following settings are for very large file uploads (such as 500m) Improved timeout setting hystrix: command: default: execution: isolation: thread: ribbon: ConnectionTimeout: 3000 ReadTimeout: 60000

(2) Zuul filter: mainly located in the project zuul-service-filter.

For the request declaration cycle of Zuul, there are four standard filter types:

PRE: called before the request is routed, you can use this filter to authenticate, record debugging information, etc.

ROUTING: routes requests to micro-services, which can be used to build requests sent to micro-services

POST: executed after routing to the microservice, which can be used to add standard HTTP Header for the response, collect statistics and metrics, send the response from the microservice to the client, etc.

ERROR: executes this filter when an error occurs in other phases

The filter of PRE type is demonstrated in this example. In some scenarios, to disable some filters, you only need to set them in the configuration file. For example, disable the PreRequestLogFilter filter here:

Zuul: # disable specified filter settings PreRequestLogFilter: pre: disable: true # disable the PreRequestLogFilter filter we created

(3) Fault tolerance and fallback of Zuul: mainly located in the project zuul-service-fallback

Zuul itself comes with Hystrix, but the granularity it monitors is micro-service level, not an API. When an API is not available, it will throw an exception page with a 500 error code. We can add a fallback to Zuul for a more friendly return. The implementation is also very simple, only need to implement the FallbackProvider interface. It is important to note that previous versions of Edgware (that is, Dalston and earlier) need to implement the ZuulFallbackProvider interface, while Edgware and later versions need to implement the FallbackProvider interface. Because FallbackProvider is a subinterface of ZuulFallbackProvider, its advantage is that it has one more interface to obtain the possible causes of fallback, which can be found in this article: "Spring Cloud Edgware's new features: improvements to Zuul fallback." The following is the result of accessing the user-service interface in this example (user-service is manually shut down by me):

(4) High availability architecture of Zuul

In a production environment, you generally need to deploy highly available Zuul to avoid a single point of failure. In actual development, there are two situations:

The client of ① Zuul is also registered with Eureka Server (e.g. MVC App, SPA, etc.)

At this time, the high availability of Zuul is no different from other micro-services, with the help of Eureka and Ribbon to achieve load balancing.

The client of ② Zuul is not registered with Eureka Server (such as mobile App, etc.)

In reality, this scenario may be more common, where an additional load balancer is needed to achieve high availability of Zuul, such as Nginx, HAProxy, F5, etc.

(5) use Zuul to aggregate microservices: this example is located in the zuul-service-aggregation project

In many scenarios, an external request may query multiple services at the Zuul backend. In this case, you can use Zuul to aggregate service requests, that is, you only need to request once, and Zuul requests each service, and then organize the data to be sent to the client (such as the App client). In the example, the aggregation of micro-service requests is mainly based on the combination of RxJava and Zuul.

3.2.6 Unified configuration Management-based on Spring Cloud Config

Spring Cloud Config provides server-side and client-side support for distributed system externalization configuration, including Config Server and Config Client. The architecture diagram is shown below:

Among them, each microservice requests Config Server to obtain the required configuration properties when starting, and then caches these attributes to improve performance, as shown in the following figure:

Examples of this section are located at: part6_config

The examples in this section mainly demonstrate how to implement a unified configuration center based on Spring Cloud Config, and mainly include the following:

(1) basic Config Server and Config Client writing: this example is located in config-service and config-client

This example needs to use some configuration files that have been put into git. Here, I have put them on github so that you can directly use them for testing, warehouse address.

The rules for mapping endpoints to configuration files are as follows:

/ {application} / {profile} [/ {label}] / {application}-{profile} .yml / {label} / {application}-{profile} .yml / {application}-{profile} .properties / {label} / {application}-{profile} .properties where application: indicates the virtual host name of the microservice, that is, the configured spring.application.name profile: represents the current environment, dev, test or production? Label: represents git warehouse branch, master or relase or others repository name? By default, in the master project, the configuration file of config-service is as follows: server: spring: application: name: sampleservice-config-server cloud: config: server: git: # configure Git warehouse address uri: https://github.com/EdisonChou/ EDC.SpringCloud.Samples.Config # Git warehouse account (if authentication is required) username: # Git warehouse password (if authentication is required) password:

Startup sequence: start config-server first, and then start config-client, because config-client will go back to config-server to get the configuration when starting, and an error will be reported if config-server is not started at this time.

It is important to note that in config-client, the configuration of spring cloud config should be placed in bootstrap.yml instead of application.yml, otherwise it will not work. A concept of spring cloud's "boot context" is involved here.

(2) manually refresh the configuration using the / refresh endpoint: still in the config-client project

To refresh the configuration during operation, you need two modifications: add the @ RefreshScope annotation

@ RestController @ RefreshScope / / @ RefreshScope annotations are indispensable, otherwise the configuration will not refresh public class ConfigClientController {@ Value ("${profile}") @ GetMapping ("/ profile") public String hello () {return this.profile;}} even if / refresh is called

In addition, for Spring Boot 1.5.x, you also need to turn off security authentication for the config-client side, otherwise you will not be able to properly refresh:

Management: security: enabled: false

After that, you can refresh the configuration by initiating an POST request to config-client:

However, if all microservices need to refresh the configuration manually, it will be a lot of work. Therefore, in the actual environment, the configuration will generally be automatically refreshed.

(3) use Spring Cloud Bus to automatically refresh the configuration: this example is located in the config-server-cloud-bus and config-client-cloud-bus projects

The architecture used in this example is shown below, which adds Config Server to the message bus and uses the / bus/refersh endpoint of Config Server to refresh the configuration. In this way, each micro-service only needs to focus on its own business logic, instead of manually refreshing the configuration.

Tip:Spring Cloud Bus connects nodes of distributed systems based on lightweight message agents (such as RabbitMQ, Kafka, etc.) and can broadcast state changes (such as configuration updates) or other management instructions. We can think of Spring Cloud Bus as a distributed Spring Boot Actuator.

Running order: start config-service-cloud-bus first, then start two config-client-cloud-bus (the first default port is 8081, the second port is changed to 8082), modify the profile value in sampleservice-foo-dev.properties in github, then commit & push, then POST requests the / bus/refersh endpoint of config-service-cloud-bus, and finally visit the / profile endpoint of both client again for verification.

If some scenarios want to know the details of Spring Cloud Bus event propagation, you can trace the event bus with the following settings:

Spring: cloud: bus: trace: enabled: true # enable cloud bus tracking

(4) use in conjunction with Eureka: this example is located in config-service-eureka and config-client-eureka projects.

(5) High availability of Config Server: high availability of Git warehouse, high availability of RabbitMQ and high availability of Config Server itself.

For the high availability of Git repositories, third-party Git repositories, similar to GitHub, have already achieved high availability. For self-built Git repositories, such as GitLab, you can refer to GitLab official documentation to build high availability.

For the high availability of Config Server itself, it can also be divided into two cases: not registered to Eureka and registered to Eureka.

In addition, this example does not cover the encryption of configuration content, which relies on JCE (Java Cryptography Extension)

Extension: with regard to the Unified configuration Center, you can also choose a more useful Apollo (Ctrip's open source project)

3.2.7 Micro Service tracking-based on Spring Cloud Sleuth

First of all, it is worth mentioning that Spring Cloud Sleuth borrows a lot of Google Dapper,Twitter Zipkin and Apache HTrace designs, we need to understand some terms, such as span, trace, annotation and so on.

This example is located at: part7_sleuth

The example in this section mainly demonstrates how to implement distributed link monitoring based on Spring Cloud Sleuth and mainly includes the following:

(1) basic integration Spring Cloud Sleuth: located in user-service-trace and m ovie-service-trace projects, you can mainly view the console output log.

(2) the combination of Spring Cloud Sleuth and Zipkin: located in three projects: zipkin-service-server, user-service-trace-zipkin and movie-service-trace-zipkin

Zipkin is an open source distributed tracking system of Twitter, which is designed based on the Dapper paper. Its main function is to collect the timing data of the system, so as to track the system delay of the micro-service architecture. In addition, it also provides a very friendly interface to help track and analyze data.

The following figure shows a simple flow chart of service invocation after being connected to Zipkin:

Running order: first run zipkin-service-server, then run user-service-zipkin and movie-service-zipkin, then visit http://localhost:8010/user/1 to get data results, and finally visit the home page of zipkin server. After entering the filter conditions such as start time and end time, click the Find a trace button to see the trace list, as shown in the following figure:

Click "dependency Analysis" to get the following figure, which helps us to analyze the dependency relationship:

It is important to note that when developing and debugging, because the default sampling percentage is 10%, span will be ignored by dint Sleuth, so we can set it to 100% in the development environment:

Spring: sleuth: sampler: # specifies the percentage of requests that need to be sampled. The default is 0.1 (i.e. 10%). It is convenient to see if it is set to 100% (not in the actual environment) percentage: 1.0

(3) use RabbitMQ to collect data: this example is located in zipkin-service-server-stream and user-service-trace-zipkin-stream projects

In addition, Spring Cloud Sleuth can be used with ELK, but this example does not cover. Of course, the trace data in the example is stored in memory, but it is recommended that the trace data be stored in ElasticSearch, not only in the production environment.

Thank you for reading, the above is the content of "how to understand the Spring Cloud micro-service architecture". After the study of this article, I believe you have a deeper understanding of how to understand the Spring Cloud micro-service architecture, and the specific usage needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.