Concern public number: Java Architect Association, the first article, thank you for your support
A major component of the Spring Cloud+Nginx architecture
Take crazy-Spring Cloud development scaffolding as an example, the architecture of a Spring Cloud+Nginx application is shown in Figure 1-1.
Figure 1-1 Application architecture based on Spring Cloud+Nginx
Nginx as a reverse proxy server, internal proxy Zuul gateway service, through Nginx own load balancing algorithm to achieve client requests proxy forwarding, load balancing and other functions.
Zuul gateway mainly realizes the functions of request routing, load balancing and unified verification within the micro-service cluster. Although Zuul and Nginx have similar functions in terms of routing services and load balancing, Zuul itself registers with Eureka/Nacos to implement routing and forwarding between microservice providers through the serviceID of microservices.
Eureka and Nacos are middleware that provide service registration and discovery in Spring Cloud technology system. Eureka is an open source product from Netflix that provides complete service registration and discovery, and is one of the core components of Spring Cloud’s “Whole Family bucket.”
Nacos is an open source project launched by Alibaba. It is also a service registration and discovery middleware, which is used to complete dynamic registration, dynamic discovery and service management of services, as well as the function of configuration management. Nacos provides an easy-to-use feature set for dynamic service discovery, service configuration, service metadata, and traffic management.
Since the new version of Eureka has closed source, Alibaba’s Nacos has the function of Spring Cloud Config configuration center in addition to Eureka registry, thus greatly reducing the cost of use and maintenance. In addition, Nacos also has the grouping isolation function, a set of Nacos cluster can support multiple projects, multiple environments. For these reasons, Nacos is recommended for real-world development scenarios. However, for learning purposes, this article will cover the Eureka+Config combination in the registry and configuration center. In fact, Nacos and Eureka+Config are similar in principle.
In addition to a set of infrastructure middleware technology components, most of the independent business models in the microservices architecture appear in the role of service providers. Generally speaking, the system can split fine-grained microservices according to various service modules, such as users and products in the system. Each service module is divided into a microservice Provider component, which is started and executed as an independent application program.
In the Spring Cloud ecosystem, remote invocation between microservice Provider providers is accomplished through Feign+Ribbon+Hystrix combination: Feign is used to complete proxy encapsulation of RPC remote invocation; The Ribbon is used to load balance remote target service instances on the client side. Hystrix is used to achieve multiple dimensions of RPC protection, such as automatic fuse downgrading. There are also a number of secondary middleware components in the Nginx+Spring Cloud architecture, including logging, link tracing, application monitoring, JVM performance metrics, physical resource monitoring, and more. This article does not specifically cover the above auxiliary middleware.
Spring Cloud and Spring Boot version selection
Spring Cloud is built on Spring Boot, and there is a corresponding version between them. When building a project, pay attention to this correspondence between versions. If the versions do not match, problems will occur.
Table 1-1 lists the version mapping between Spring Cloud and Spring Boot.
Table 1-1 Version mapping between Spring Cloud and Spring Boot
Table 1-1 Version mapping between Spring Cloud and Spring Boot
Spring Cloud contains a series of sub-components, such as Spring Cloud Config, Spring Cloud Netflix, Spring Cloud Openfeign, etc. To avoid confusion with the version numbers of these sub-components, The version numbers of Spring Cloud are all named in English word form. Specifically, the release number of Spring Cloud is named after the London Underground station in the UK and released in alphabetical order from A to Z. The first version is called Angel, the second version is called Brixton, and so on. In addition, after each major Release resolves a serious Bug, Spring Cloud releases a Service Release (minor Release), or SRX Release, where X is the sequential number. For example, Finchley.SR4 is the fourth minor Release of Finchley.
Most people prefer to use the highest version when choosing a technology, but the highest version is not necessarily the best choice for Spring buckets. For example, the highest current release of Spring CloudHoxton is built on Spring Boot 2.2, which in turn is built on The Spring Framework 5.2, meaning that this is a comprehensive, all-encompassing upgrade to a major release. We will use a lot of third-party components in the project. There will always be some components that are not compatible with Spring Boot 2.2 or SpringFramework 5.2 without sufficient time for matching upgrades. If the overall upgrade of the basic framework is carried out hastily, it will bring a variety of difficulties to the project development. Even potential online bugs.
In addition, the high release of Spring Cloud has recommended many new components of our own, but these new components have not been tested by large-scale practical application, and their functionality is still to be enriched and improved. Take load balancing components as an example. The Spring Cloud-Load Balancer component recommended by Spring Cloud Hoxton is much weaker than the load balancing function of the Ribbon.
The upgrade to the Greenwich version of Spring Cloud Finchley is small, if minimal, and mainly improves Java 11 compatibility. However, Java 8 is the major project of choice in the current production scenario, and Java 11 (a post-April 2019 update) is no longer entirely free. Of course, like Java 11, Java 8 will also face charges for patches after April 2019. The reason for using Java 8 is that Java 8 has been widely used and maintained over the years since its release on March 18, 2014, and is now very mature and stable.
To sum up, Spring Cloud Finchley is selected as the version for study, research and use in this paper, and the recommended sub-version is Finchley.sr4. Maven dependency coordinates are as follows:
<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Finchley.SR4</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> The < artifactId > spring - the boot - dependencies < / artifactId > < version > mid-atlantic moved. RELEASE < / version > < scope > import < / scope > <type>pom</type> </dependency> </dependencies> </dependencyManagement>Copy the codeMiddleware for Spring Cloud microservices development
The basic middleware involved in microservice development and self-validation based on the Crazy-SpringCloud scaffolding (other scaffolds are similar) is roughly as follows:
1.ZooKeeper
ZooKeeper is an open source distributed coordination application and an important component of Big data frameworks Hadoop and HBase. In distributed applications, it can provide protection with high availability
Many basic functions of data consistency barrier: distributed lock, master selection, distributed naming service and so on.
ZooKeeper is used in the high performance distributed ID generator in crazy-Spring Cloud scaffolding.
2.Redis
Redis is a high-performance cached database. In high concurrency scenarios, Redis provides a good buffer for relational databases. Redis is critical in improving the concurrency and response speed of your system. The crazy- SpringCloud scaffolding uses Redis for distributed sessions.
3.Eureka
Eureka is a service registration and discovery framework developed by Netflix. As a REST service provider, Eureka is mainly used to locate middle-tier services running on AWS (Amazon Cloud) for load balancing and middle-tier service failover. Spring Cloud integrates Eureka into the sub-project Spring-Cloud-Netflix to realize the service registration and discovery functions of Spring Cloud.
4.Spring Cloud Config
Spring Cloud Config is the earliest configuration center in the Spring Cloud family bucket. Although many enterprises have replaced the independent configuration center with Nacos or Consul integrated configuration center in production scenarios, Config is still suitable for Spring Cloud projects. It can be used by simple configuration.
5.Zuul
Zuul is an open source gateway for Netflix, which can be used with Eureka, Ribbon, Hystrix and other components. Spring Cloud integrates and enhances Zuul, using it as an internal gateway for microservice clusters. Provides RPC routing and filters requests to providers (service providers) within the cluster.
6.Nginx/OpenResty
Nginx is a high-performance HTTP and reverse proxy server, a Web server developed by Igor Sessoyev for Russia’s second most-visited rambler.ru site. The Nginx source code was released as a BSD-like license, with the first public release of 0.1.0 on October 4, 2004 and 1.0.4 on June 1, 2011. Nginx is well known around the world for its high stability, rich feature set, low memory consumption, and strong concurrency. It is widely used by Baidu, JINGdong, Sina, netease, Tencent, Taobao and so on. OpenResty is a high-performance Web platform based on Nginx and Lua. It integrates a large number of sophisticated Lua libraries, third-party modules and most of the dependencies to quickly build highly scalable dynamic Web applications, Web services and dynamic gateways that can handle extremely high concurrency.
Table 1-2 shows the port configuration and some installation and use videos of the above middleware.
Table 1-2 Port configuration of the main middleware involved in this case and some installation and use demonstration videos
Spring Cloud microservices development and self-validation environment
Before we start learning the core programming of Spring Cloud, we will introduce the preparation of the development and self-validation environment, the installation of middleware, and the preparation of the package capture tool.
Develop and self-validate system options and environment variable configurations for the environment
Firstly, the development and selection of self-validation system are introduced. Most developers have learned to develop in a Windows environment. In this case, it is highly recommended to use CentOS on a VIRTUAL machine as a self-verification environment. Why CentOS?
1. Expose problems in the production environment in advance
In production environments, more than 90% of Java applications are deployed using a Linux environment (such as CentOS). Therefore, using CentOS as a self-verification environment can expose potential problems in the production environment in advance, so as to avoid problems that may not be found during development and may occur once the application is deployed in the production environment (I have experienced this myself).
2. Learn Shell commands and scripts
Basic Shell commands and scripts are required to locate, analyze, and solve online bugs in the production environment. Therefore, use and practice them frequently. In addition, Shell commands and scripts are must-know interview questions for Java programmers. CentOS can be used as a self-verification environment for learning Shell commands and scripts.
Of course, there are some file synchronization or sharing tools you can use to make your development more efficient. For example, VMware Tools can be used to share folders between Windows and CentOS to avoid copying files back and forth during Lua script development and debugging.
Here is a brief introduction to the crazy-SpringCloud scaffolding development and self-validation environment preparation, mainly involving two aspects:
(1) Configuration of environment variables related to middleware (including Eureka, Redis, MySQL, etc.).
(2) Configure the host name.
Many middleware related information (such as IP addresses, ports, user accounts, etc.) are directly stored in plain-text encoded configuration files, which may cause security risks and even leak risks. For this information, it is recommended to configure it through operating system environment variables, and then use environment variables in the configuration file instead of plaintext encoding.
For example, you can configure the environment variable EUREKA_ZONE_HOST for the IP address of Eureka in advance and use it in the application configuration file bootstrap.yml as follows:
eureka:
client:
serviceUrl:
defaultZone: ${SCAFFOLD_EUREKA_ZONE_HOSTS:http://localhost:7777/eureka/}
Copy the codeIn the above configuration, the service-URL address of Eureka is obtained from the environment variable using the ${SCAFFOLD_EUREKA_ZONE_HOSTS} expression. Environment variable SCAFFOLD_EUREKA_ZONE_HOSTS followed by a colon and a default value, said if the environment variable value is empty, http://localhost:7777/eureka/ will use the default value as the value of the configuration items.
What are the benefits of configuring middleware information through environment variables?
First, it provides a layer of flexibility for switching configuration information. If you switch IP, you only need to modify environment variables. Second, it is not necessary to store sensitive information such as passwords in plain-text encoding in configuration files, which provides a layer of security.
Crazy-springcloud microservice development scaffolding uses many environment variables. Taking /etc/profile configuration file in CentOS for self-verification environment as an example, part of the content is roughly as follows:
Export SCAFFOLD_DB_HOST=192.168.233.128 export SCAFFOLD_DB_USER=root export SCAFFOLD_DB_PSW=root export SCAFFOLD_REDIS_HOST = 192.168.233.128 export SCAFFOLD_REDIS_PSW = 123456 export SCAFFOLD_EUREKA_ZONE_HOSTS = http://192.168.233.128:7777/eureka/ export RABBITMQ_HOST = 192.168.233.128 export SCAFFOLD_ZOOKEEPER_HOSTS = 192.168.233.128:2181Copy the code192.168.233.128 in the above environment variables is the IP address of CentOS VIRTUAL machine in the author’s self-verification environment. Redis, ZooKeeper, Eureka, MySQL, Nginx and other middleware run on this VIRTUAL machine. You need to make these changes before running the Crazy-SpringCloud microservices development scaffolding.
Finally, the configuration of the host name is described. If you access the REST interface through IP during debugging, it is not convenient to view packets captured by the Fiddler tool. IP addresses are mapped to host names to facilitate packet capture. In the Windows development environment used by the author, the host name configured in the hosts file is as follows:
127.0.0.1 crazydemo.com 127.0.0.1 file.crazydemo.com 127.0.0.1 admin.crazydemo.com 127.0.0.1 xxx.crazydemo.com Eureka. Server 192.168.233.128 Zuul. server 192.168.233.128 nginx.server 192.168.233.128 admin.nginx.serverCopy the codeNote that the urls used in the demonstration use cases later in this book will use the above host names instead of IP addresses.
Use Fiddler to capture and view packets
During microservice development and validation, there are generally several ways to make a request to an HTTP interface:
(1) Initiate a request directly.
(2) Initiate a request through the internal gateway agent (such as Zuul).
(3) Initiate a request through an external gateway reverse proxy, such as Nginx.
Using the HTTP interface/API /user/detail/v1 of the UAA-Provider service in the crazy-SpringCloud scaffolding as an example, Figure 1-2 shows the HTTP link that initiates requests through the preceding three methods.
Figure 1-2 HTTP links of uAA-Provider requests in three modes
In the production environment, external reverse proxy (Nginx) usually has more than one layer to meet the requirements of forwarding between Intranet and extranet and load balancing between multiple servers. As a result, HTTP links for requests tend to be more complex.
Whether in the development environment, self-verification environment, test environment, or production environment, viewing HTTP interface access links and packet content is very important for locating, analyzing, and solving problems. Therefore, you need to use packet capture tools. There are many types of packet capture tools, and Fiddler is the most popular tool used by the author.
For example, when debugging the UAA-Provider function in the crazy-SpringCloud scaffolding, Fiddler can be used to comprehensively view the request headers and response headers of HTTP packets sent to the server, as shown in Figure 1-3.
Figure 1-3 Viewing the request and response headers using Fiddler
During development, the use of a packet capture tool like Fiddler is useful for analyzing and locating problems. I often use Fiddler to:
(1) View the processing time of the REST interface to help you view the overall time of the interface when solving performance problems.
(2) view the REST interface request header, response header, response content, mainly used to view the request URL, request header, response header is correct, and when necessary, all the request header can be copied to Postman and other request initiating tools, help the new request to quickly construct the same HTTP header.
(3) Request retransmission, in addition to the use of independent request tools (such as SwaggerUI/Postman, etc.) request retransmission can also be directly in Fiddler, the request retransmission has the same header and parameters, very convenient debugging.
Crazy – SpringCloud Microservices development scaffolding
Whether a single application or a distributed application is developed from scratch, it involves a lot of basic and repetitive work, such as user authentication and Session management.
With development scaffolding, this groundwork can be eliminated, and the basic modules provided by the scaffolding can be used directly, and then the business modules can be developed according to the specifications of the scaffolding.
The author has seen a lot of open source scaffolding on the open source platform, but found that these scaffolding can rarely be directly used for the development of business modules. Either the packaging is too heavy and difficult to decouble, or the business module subcontracting is not clear and convenient for development. Therefore, based on the principle of simplicity and clarity, The crazy Maker community initiated by the author launched its own micro-service development scaffold crazy-SpringCloud, whose modules and functions are as follows:
Crazymaker-server - Root project │ ├─ Cloud-Center - Infrastructure Center │ │ ├─ Cloud-Eureka - Registration Center │ │ ├─ Cloud-Config - Configuration Center │ │ ├─ Cloud-Eureka - Registration Center │ │ ├─ Cloud-Config - Configuration Center │ │ ├─ Cloud-Center │ ├─ Cloud-Zuul - Service │ │ ├─ Cloud-Zipkin - Monitoring Center │ ├─ CrazyMaker-Base - Public Base │ │ ├─ Base-Common - Public Base Public methods, such as utils │ │ ├ ─ base - redis - public redis module operation │ │ ├ ─ base - zookeeper - public zookeeper operation module │ │ ├ ─ base - the session - │ │ ├─ Base-Auth - Distributed Session module │ │ ├─ Base-Runtime - All the providers in the system │ ├─ CrazyMaker-UAA - General Spring IOC Bean │ │ ├─ Anti-Flag - UAA-API - DTO, Constants, etc. │ │ ├─ Anti-Flag - UAA-Provider - User Authentication and Authority │ ├─ Crazymaker-Seckill -- -- -- -- -- -- Seconds kill practice │ │ ├ ─ seckill - API, seconds kill DTO, Constants, etc. │ │ ├ ─ seckill - the client - kill service Feign remote call module │ │ ├ ─ seckill - service provider - kill the core implementation, │ ├─ Crazymaker-Demo - Controller layer, Service layer, DAO layer │ │ ├─ ├─ Demo - API - DTO, Constants, etc. │ │ ├─ Demo - Provider - Core implementation Contains the controller layer, service layer, DAO layer code implementationCopy the codeOn the question of how to subcontract business modules, most enterprises have their own unified norms. Crazy-springcloud scaffolding divides each business module into the following three sub-modules from the perspective of clear responsibility, easy maintenance, and quick code navigation.
(1) {module} -API: This submodule defines some common Constants business Constants and DTO transport objects that are dependent both internally and possibly externally on the business module.
(2) {module}-client: this submodule defines some Feign remote call client classes that are dependent on external modules. It is a dependency for external modules and cannot be relied on by other internal submodules.
(3) {module}-provider: this sub-module is the core of the whole service module and an Application that can be started and run independently. This module contains complete code implementation of controller layer, Service layer and DAO layer involving business logic.
Crazy-springcloud microservices development scaffolding has been weakened in the following two aspects:
(1) The introduction of containers is weakened in terms of deployment. Shell scripts are used instead of Docker containers. There are many reasons for this: First, the purpose of this scaffold is to learn, using Shell scripts instead of Docker to deploy, so that everyone can learn Shell commands and scripts; Second, Java and Docker are actually well integrated, it is very easy to learn, a little configuration can do one-click release, find some information to learn can easily master; Three is to deploy and ops is a specialized work, the deployment of the production environment, and even the entire automated build and deployment of the work is, in fact, belong to the operations of the project work, by a special operations staff to complete, and the core of the deployment is still a Shell script, so master Shell script is the top priority for developers.
(2) The introduction of monitoring software is weakened. This book does not specifically introduce the use of link monitoring, JVM performance indicators, and fuses monitoring software. There are several reasons for this. First, there are too many monitoring software. Second, the use of monitoring software is mostly the operation steps and instructions of some software, and the original content is relatively small. The spread of such knowledge in the form of video is better than the form of text. Crazy Maker circle may launch some teaching videos on micro-service monitoring for your reference, please pay attention to the community blog. However, once you understand the core principles of Spring Cloud, mastering the use of monitoring components is basically a piece of cake.
Take seckill as a practical case of Spring Cloud+Nginx
The comprehensive practical case of this paper is to achieve a high-performance second kill system. Why to second kill as a comprehensive practical case of this book? Let’s review a comprehensive case study of J2EE technology in the days when single architecture was still the mainstream. In general, you write a shopping cart application line by line, starting at zero. Through writing shopping cart application can have a full range of J2EE practice, including front-end HTML web pages, JavaScript scripts, back-end MVC framework, database, transaction, multithreading and other technologies.
Times change, technology complexity changes, and so does the division of labor between front and back ends. At present, J2EE development has entered the era of distributed microservices architecture, front-end and back-end frameworks have become very complex, front-end and back-end engineers have a relatively clear division of labor. Back-end programmers specialize in Java development, and front-end programmers specialize in front-end development. Back-end programmers don’t need to know front-end technology (Vue, TypeScript, etc.), but many front-end programmers don’t need to know backend technology either.
Learning Java backend technology is much harder in today’s distributed development era than it was in the monolithic services era. The first step is to learn a lot of distributed, high-performance middleware, such as Netty, ZooKeeper, RabbitMQ, Spring Cloud, Redis, etc., which is a must for today’s back-end programmers. And stress testing tools like JMeter and packet capture tools like Fiddler have become mandatory knowledge for every back-end programmer. Because of the need to locate, discover, and resolve data consistency, high reliability, and other issues in a distributed environment, stress testing can cause a lot of performance-related problems in otherwise normal code at runtime.
In addition, with the development of mobile Internet and Internet of Things, the current high concurrency scenarios are not limited to e-commerce, but also more and more other applications. As a result, highly concurrent development technology is now a basic skill that most people need to master instead of a sophisticated skill that a few engineers need to master. In general, the three most powerful tools for high-concurrency development are caching, degradation, and limiting traffic. The purpose of caching is to improve system access speed, it is the silver bullet against high concurrency; Degradation means that when the service has a problem or the service affects the core process, the service can be temporarily shielded and opened after the peak or the problem is solved. Traffic limiting measures can be used to protect interfaces in situations where caching and downgrade are not possible, such as scarce resources (snap, snap), and write data (comment, order).
With cache, downgrade, and stream limiting, when faced with high concurrent application scenarios like JINGdong 618 and Ali Double 11, there is no need to worry about the system avalanche caused by instantaneous traffic. Even if the service can only be damaged in the end, some small e-commerce platforms will not have the accident of server downtime for several hours during the event.
The business of seckill program is simple enough, and the technology involved is comprehensive enough, which can be said to be a very good practical case of distributed application scenario. In addition, there is a lot of talent mobility in the IT industry now, and everyone will prepare for the interview. In the interview, the cache, degrade, high concurrency limiting, distributed lock, distributed ID, data consistency and other issues covered by the seckill service are generally the key and hot questions.
This article covers the main components of the Spring Cloud+Nginx architecture
- In the next article, we will introduce the introduction of Spring Cloud.
- Feel good friends can forward this article to pay attention to small;