This paper discusses the technical architecture of Internet companies, including DNS, load balancing, long connection, API gateway, PUSH PUSH, micro service, distributed transaction and related supporting basic services. Mainly for learning, I hope I can give you a reference.

The overall architecture

Callers such as apps, PCS, and third parties obtain the IP address of the load balancer using LocalDNS, the traditional domain name resolution service. The APP uses HttpDNS to implement real-time, flexible, and accurate domain name resolution services.

Access the unified access layer through load balancers, and the unified access layer maintains long connections.

As the entrance of microservices, API gateway is responsible for protocol transformation, request routing, authentication, traffic control, data caching, etc.

The service Server uses the PUSH system to implement real-time PUSH on the peer end, such as IM and notification.

Service servers invoke each other through the proprietary RPC protocol and invoke external third-party services through the NAT gateway.

Domain name resolution

Traditional DNS

The Domain Name System (DNS) is a distributed network directory service that translates Domain names into IP addresses. It enables users to access the Internet more conveniently without remembering the IP address of the host.

The DNS resolution process is as follows:

  • The client recursively queries LocalDNS (usually an edge DNS server provided by an ISP) to obtain an IP address
  • LocalDNS Iteratively obtains IP addresses, that is, continuously obtains DNS server addresses for query

HttpDNS

Mobile DNS (HttpDNS) sends domain name resolution requests to the DNS server based on THE Http protocol. It replaces the traditional method of initiating DNS resolution requests to the Local DNS of carriers based on the DNS protocol, avoiding domain name hijacking and cross-network access problems caused by Local DNS. Resolve the problems caused by abnormal domain name resolution in mobile Internet services.

Tencent Cloud HttpDNS as a reference, compared with the advantages of traditional LocalDNS:

advantage Tencent cloud HttpDNS Operators LocalDNS
High speed Access nodes cover Top17 operators in China, southeast Asia and North America, providing accurate analysis and fast access Users access and resolve exceptions across the network
security Bypass carrier Local DNS, no hijacking, prevent DNS contamination interception Domain name resolution results are directed to AD pages and third-party ads are inserted
smart Accurately identify source requests and access to the most accurate nodes Requests are forwarded to other carriers instead of recursive domain name resolution
reliable The DISASTER recovery (Dr) of a three-place IP cluster provides automatic second-level failover and services with more than 99% SLA The operation and maintenance environment of the cache server is uneven and sometimes fails

Load balancing

To solve the performance problems of a single machine and a single point of view, multiple machines need to be horizontally scaled through load balancing to distribute the request traffic to different servers.

Client traffic will first reach the load balancing server, through certain by the load balancing server scheduling algorithm will flow distributed to different application servers, and load balancing server can do periodic health examination on the application server, when found fault nodes and the dynamic of the nodes from the application server in the cluster, to ensure that the application of high availability.

Network load balancing is mainly implemented by hardware and software. In mainstream load balancing solutions, HARDWARE manufacturers are represented by F5, and software is mainly LVS, NGINX, and HAProxy.

Technically, it is divided into L4 and L7 load balancing.

L4 vs L7

L4 layer 4 load balancing works in the transport layer of OSI model, and its main work is forwarding. After receiving the packet from the client, it needs to know the protocol content at the transport layer and forward the packet to the application server according to the preset forwarding mode and scheduling algorithm. In the case of TCP, when an initial SYN packet arrives for a TCP connection, the scheduler selects a server and forwards the packet to it. After that, you can check the IP address and TCP header address of the sent packets to ensure that the subsequent packets of the connection are forwarded to the server.

L7 seven-layer load balancer works in the application layer of OSI model, and its main work is proxy. The layer-7 load balancer will establish a complete connection with the client and resolve the request of the application layer, then select an application server according to the scheduling algorithm, and establish another connection with the application server to send the request.

LVS forwarding mode

LVS (IP load balancing technology) works at layer 4 below L4, and the forwarding modes include DR mode, NAT mode, TUNNEL mode, and FULL NAT mode.

DR mode (Direct Routing)

Rewrites the MAC address of the request packet and sends the request to the real server. The real server directly returns the response to the customer. The scheduler and real server must have one NIC connected to the same physical network segment, and the real server must be configured with VIP.

NAT mode (Network Address Translation)

The dispatcher rewrites the destination address of the request message and dispatches the request to the real server at the back end according to the preset scheduling algorithm. When the response packet from the real server passes the scheduler, the source IP address of the packet is rewritten and returned to the customer to complete the load scheduling process. Load balancing must exist on the network in the form of a gateway.

TUNNEL model

The scheduler forwards the request packets to the real server through the IP tunnel, and the real server returns the response directly to the client. Therefore, the scheduler only processes the request packets. The real server must support the tunnel protocol and VIP configuration.

FULL NAT mode

Perform source ADDRESS translation (SNAT) based on the NAT mode. SNAT enables the response traffic to be routed back to the load balancer through normal Layer-3 routes. In this way, the load balancer does not need to exist on the network in the form of a gateway. In NAT mode, the real server loses the real IP address of the client.

Scheduling algorithm

polling

External requests are distributed sequentially to real servers in the cluster, and it treats each server equally regardless of the actual number of connections and system load on the server.

Weighted polling

The larger the weight is, the higher the access probability is. It is mainly used to make reasonable and effective use of host resources when the performance of each back-end server is unbalanced.

The minimum connection

Schedule network requests to the server with the fewest established links. If the real servers of the cluster system have similar system performance, the “minimum connection” scheduling algorithm can balance the load better

The hash

The hash value of the specified Key is modulo calculated with the number of servers to obtain the serial number of the required server

Consistency hashing

Considering that every node in a distributed system may fail and new nodes are likely to be added dynamically, consistent hashing ensures that the movement of access nodes is minimized when the number of nodes in the system changes.

API gateway

API Gateway is a server cluster, the only access to the external. From an object-oriented design perspective, it is similar to the appearance pattern. The API gateway encapsulates the internal architecture of the system and provides REST/HTTP apis externally. It also has other non-business related responsibilities such as authentication, monitoring, load balancing, caching, flow control, etc.

API management

The core function of the API gateway is API management. Complete API lifecycle management, including creation, maintenance, publishing, running, offline and other basic functions; Provide testing, pre-release, release and other environments; Provides version management and version rollback.

API configuration includes front-end configuration and back-end configuration. Front-end configuration refers to HTTP-related configuration, such as Http methods, URL paths, request parameters, and so on. Back-end configuration refers to the configuration of microservices, such as service name, service parameters, and so on. This completes the front-end Http to back-end microservice transformation through API configuration.

The asynchronous

Because THE API gateway mainly deals with network I/O, through non-blocking I/O and I/O multiplexing, it can achieve the use of a small number of threads to carry a large number of concurrent processing, avoiding thread context switching, greatly increasing system throughput and reducing machine costs.

Common solutions include Tomcat/Jetty+NIO+ Servlet3.1 and Netty+NIO. Netty+NIO is recommended to achieve higher throughput. Spring 5.0’s WebFlux reactive programming model is asynchronous, event-driven, and non-blocking. It is internally implemented based on Netty+NIO or Servlet 3.1 non-blocking containers.

Chain processing

The chain processing provides basic gateway functions, such as routing, protocol conversion, caching, traffic limiting, monitoring, and logging, in the Filter chain mode. You can also perform the expansion based on actual service requirements, but do not perform time-consuming operations.

The working mechanism of Spring Cloud Gateway (based on Spring WebFlux) is as follows:

  1. Gateway receives client requests.
  2. The client requests are matched with the routing information. Only the matched information can be sent to the downstream service.
  3. The request passes through the Filter chain and performs pre processing logic, such as modifying the request header information.
  4. The request is forwarded to the downstream service and a response is returned.
  5. The response passes through the Filter chain, performing the POST processing logic.
  6. Reply to the client.

Request the current limit

Request limiting is the last effective line of defense against system flushing in the face of unknown traffic. You can limit traffic for clusters, business systems, and specific API dimensions.

The specific implementation can be divided into cluster edition and standalone edition, the difference is that the cluster edition uses the backend unified cache such as Redis to store data, but there is a certain performance loss; The standalone version is stored in native memory (recommended).

Common traffic limiting algorithms: counters, leaky buckets, token buckets (recommended)

Fusing the drop

Service fusing

When the downstream service becomes unavailable or responds slowly for some reason, the upstream service directly returns to the target service to release resources quickly to ensure the overall service availability. Resume the call if the target service improves.

Circuit breakers are designed to address service avalanches, especially in microservices, and are usually handled at the framework level. The internal mechanism adopts circuit breaker mode, and its internal state transition diagram is as follows:

Service degradation

When the load exceeds the overall load capacity of the system, in order to ensure the availability of core services, non-core services can usually be degraded to return cache content or directly return.

The granularity of service degradation can be API dimension, functional dimension, or even system dimension, but the service level needs to be sorted out and defined in advance.

In real scenarios, the administrator decides whether to expand or degrade the server after the server load exceeds the threshold.

Business isolation

API gateways unify non-business level processing, but if there is logic for business processing, different businesses may interact with each other. Thread pool isolation and cluster isolation are commonly used to isolate business systems, but threads are a heavy resource for Java and cluster isolation is recommended.

PUSH PUSH

Information push system Launched a variety of push type for different scene, meet the demand of the user’s personalized push, and integrate the apple, huawei, millet, channels to the push function of FCM and other manufacturers, in providing the console rapidly push ability at the same time, also provides a server access, convenient user fast integration of mobile terminal push function, keep the user interaction, This improves user retention and improves user experience.

Process for connecting devices, registering users, and binding users

Message push process

In many business scenarios, the user may not be online or on the network when the service occurs. Therefore, all messages are persisted in MPS. When a service occurs, MPS attempts to push it (through a third-party channel or a self-built TCP connection). In the self-built channel, the user terminal checks whether there is a TCP connection by querying the cache. If there is a TCP connection, the user pushes the message. After receiving the push message, the client sends an acknowledgement to the server, and the server updates the status of the message. If the push fails or the receipt is lost, the user will receive the notification again when establishing a connection next time, and the client will perform logical deduplication.

Microservice system

TODO writes another article about it. Look forward to it!

The resources

www.linuxvirtualserver.org/zh/lvs1.htm…

www.infoq.cn/article/Mag…

www.cnblogs.com/mindwind/p/…

Blog.csdn.net/gaopeiliang…

www.jianshu.com/p/76cc8ba5c…

www.jianshu.com/p/cda7c0366…

Juejin. Cn/post / 684490…