Foreword
Modern computers are based on computing, storage, and scheduling systems, so modern architectures are constantly evolving around these three topics.
In the infrastructure department, it is also mainly to solve these three problems and provide the three major capabilities of transparency, high availability, and rapid scalability for the business department. Our group is mainly responsible for the topic of [traffic scheduling]. The following are some macro technologies notes.
In the monolithic structure, traffic scheduling is intuitive and non-intuitive (DNS + Nginx can complete one traffic scheduling). Evolving to the microservice structure (service granularity becomes finer, service scaling is more flexible (more frequent offline and offline), and teams are loosely coupled), traffic scheduling has not disappeared, but has become more complex.
Explanation of key terms
-
1. Control Plane/Data Plane [1]
-
Control plane: contains routing tables, is responsible for routing control, guides the direction of traffic, pays attention to “guidance”, and belongs to the bypass service (core).
-
Data plane: According to the routing logic of the control plane, the actual calling link of business traffic.
Many of the control planes belong to the [core] bypass business: require consistency => raft protocol.
-
2. East-West/North-South traffic [2]
-
North-South traffic: business client —> server;
East-west traffic: inter-service calls within a data center or between data centers; east-west/north-south traffic belongs to data plane traffic.
Evolution of Service Governance
The cornerstone of service governance is dynamic service discovery. The evolution of Alibaba Cloud service governance [3] is large and comprehensive. Here I only record my understanding.
| stage | goal | means |
| Incubation period | Dynamic service discovery | Client/server service discovery, load balancing |
| Growth period | Improve development and iteration efficiency | Standard API, unified configuration, version management |
| Mature stage | Deployment boundaries, links Tracking, elastic scaling | Service preheating, graceful offline, monitoring and tracking, current limiting, circuit breaker, rollback |
Core skill points
-
1. Why do you need a registration center?
It is not microservices that give birth to the registration center, but microservices strengthen the registration center. -
In the early days, DNS + nginx could complete the traffic scheduling of a single unit, but no matter whether DNS resolves the ip or nginx forwards it to the upstream instance, the bottom layer has the shadow of the registration center.
-
There is a concept of addressability, service addressability[4], each microservice must have a unique addressable name, which dynamically represents a group of services that can handle traffic Instance resource.
-
For resources, there must be CRUD interaction, which is the deployment platform and service discovery. At the same time, when an instance fails, the registry must be able to instruct the service to switch to a suitable instance to run.
There must be health detection at the deployment level to inform the business side of the readiness of the instance; when actually receiving traffic, the load layer will also have its own active health check detection.
-
2. Standardized API interface, unified configuration
Improve the efficiency of development iterations, uniformly use an API interface in the form of method and body payload (to avoid tearing caused by passing parameters in the wrong format), and do not need to modify the configuration on n instances. -
Each team is in a loosely coupled relationship, and upstream and downstream changes will not be actively notified, so version management is required (lower versions cannot be directly offline), and a version debugging interface provided to the development team.
-
3. Service Discovery
Service discovery is the cornerstone of service governance, with three tricks: registration, heartbeat, and addressing. -
There are two modes: client service discovery, server service discovery,
-
The core difference is: whether the client saves the service list information.
-
? The deployment system does the [register] action.
-
? Microservice caller addressing
-
? Proactively report heartbeat/proactive detection of registration center: maintain instance resource status.
-
4. Load balancing
-
? random
-
? Polling
-
? Polling with authority
-
? Dynamic scheduling based on the service quality of the backend instance
Recently, I thought about a problem. Load balancing is not only about obtaining the list of available instances of the service, and then doing traffic sharing; in fact, the existence of load balancing also provides us with an opportunity for lossless flow switching.
-
5. Aircraft takeoff and landing are the most prone to accidents
-
? Service preheating: The service process starts, waits for the service configuration/cache to be ready, and then notifies the registration center that the instance resources are ready and can receive streams.
-
? Graceful offline: Set the service termination time (30s) when offline, process the traffic in transit, and no longer receive new request traffic.
-
6. Current limiting fuse
The status of some services on the link will affect the entire link (avalanche), so it is necessary to ensure the high availability of the microservice link => service fusing and current limiting. -
Fuse: Fuse down the downstream calls; flow limit: limit the traffic entering this application.
-
Whether it is client service discovery or server service discovery, there is a registration center, which can also be called name service, which is the cornerstone of traffic scheduling and unifies the entrance of traffic scheduling.
In the modern Internet structure, before the traffic hits the application, it will be connected to a certain load layer in a corresponding posture.
Most of the time, the traffic does not care about a specific application instance, but the availability of the service; the load layer needs to achieve lossless expansion and contraction, and lossless flow switching, all of which involve dynamic online and offline instances.
Dynamic service discovery based on nginx7 layer load
Server-side service discovery adds a new load layer between the client and the streaming application. In addition to load balancing, it also provides an opportunity for failover and lossless switching. Different load layers have different connection postures.
Let’s focus on dynamic service discovery based on nginx host name (server-side service discovery).
When nginx is a reverse proxy and load balancing, we pay attention to the context [server configuration section] [upstream configuration section] of nginx [http configuration section].
In the above configuration, nginx will match the requested Host header and the server_name directive to determine which upstream virtual host the request is forwarded to.
For relevant knowledge, please pay attention to the key role of the Host request header in the virtual host service multi-domain service [5]
Using nginx’s third-party component nginx_http_dyups_module[6], you can dynamically modify the upstream configuration.
This module can be used to update your upstream-list without reloading Nginx.
daemon off;
error_log logs/error.log debug;
events {
}
http {
upstream test_upstream {
server 127.0.0.1:8088;
server 127.0.0.1:8089;
}
server {
listen 80;
location / {
# The upstream here must be a nginx variable
set $up test_upstream;
proxy_pass http://$up;
}
}
server {
listen 8088;
location / {
return 200 "8088";
}
}
server {
listen 8089;
location / {
return 200 "8089";
}
}
server {
listen 8090;
location / {
return 200 "8090" ;
}
}
server {
listen 8081;
location / {
dyups_interface;
}
}
}
-
1. This component is not compiled into tengine by default (Taobao’s open source nginx distribution with strong features), please use the
--with-http_dyups_moduleconfiguration parameter to enable it.
./configure --add-module=./modules/ngx_http_upstream_dyups_module // configured as a static component make // compile make install // install
-
2. It is necessary to add the
dyups_interfacecommand to activate the [dynamically modify upstream configuration] capability. -
3. Demonstrate using the dyups api to modify the upstream configuration without restarting nginx.
Query upstream: localhost:8081/detail
test_upstream server 127.0.0.1:8088 weight=1 max_conns=0 max_fails=1 fail_timeout=10 backup=0 down=0 server 127.0.0.1:8089 weight=1 max_conns=0 max_fails=1 fail_timeout=10 backup=0 down=0 // Actual request `curl 127.0.0.1`, polling returns 8088 or 8089
Update upstream configuration: curl -d "server 127.0.0.1:8090;" 127.0.0.1:8081/upstream/test_upstream
// call `localhost:8081/detail` again test_upstream server 127.0.0.1:8090 weight=1 max_conns=0 max_fails=1 fail_timeout=10 backup=0 down=0 // Actual request `curl 127.0.0.1`, polling returns 8090
The above is the understanding of the large topic of traffic scheduling. Due to space limitations, tactical actions have not been launched. The road is long and the road is long, and the words are poor. If there are mistakes or different opinions, please leave a message to discuss.
Reference link
[1] Control Plane/Data Plane: https://geek-docs.com/network/network-ask-answer/difference-between-control-plane-and-data-plane .html[2] east-west/north-south traffic: https://zhuanlan.zhihu.com/p/40677776[3] Evolution of Alibaba Cloud Service Governance:  [4] Service Addressability: https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservices-addressability -service-registry[5] The key role of the Host request header in the virtual host service multi-domain service: https://www.cnblogs.com/JulianHuang/p/16639016.html[6] nginx_http_dyups_module: http://tengine.taobao.org/document_cn/http_dyups_cn.html
Click “Like“
Looking“
It is necessary to show attitude!
The knowledge points of the article match the official knowledge files, and you can further learn relevant knowledge. Java skill treeHomepageOverview 108680 people are learning systematically