Internet ideal architecture

This paper discusses the Internet's technical infrastructure, involving DNS, load balancing, long connection, API Gateway, PUSH Push, micro-services, distributed transactions and related support basic services. Mainly to study, hoping to give you a reference.

Overall structure

Here Insert Picture Description
APP, PC as well as third parties such as the caller through the traditional DNS service LocalDNS get a load balancer IP, APP can be implemented more flexible and accurate real-time domain name resolution services through HttpDNS way.

Unified access layer reaching through a load balancer, unified access layer maintains long connections.

Gateway API and services as an inlet micro responsible protocol conversion, request routing, authentication authorization, flow control, data caching.

Business Server to achieve real-time push to end by pushing PUSH system, such as IM, notification functions.

Business Server implements calls between each other via a proprietary RPC protocol, and calls to external third-party services through the NAT gateway.

DNS

Traditional DNS

DNS (Domain Name System) domain name system, a distributed network directory service, used to convert domain names and IP addresses, can make people more convenient access to the Internet, without having to remember the IP address of the machine.

DNS resolution process is as follows:
Here Insert Picture Description
Client recursive queries LocalDNS (typically ISP Internet service provider edge DNS server) to obtain IP

LocalDNS iterative queries to obtain IP, ie constantly obtain the domain name server address queries

HttpDNS

Mobile parse (HttpDNS) Http-based protocol to send DNS server domain name resolution request to replace the traditional way of initiating resolution request to the DNS protocol-based operators Local DNS, domain name can be avoided due to Local DNS hijacking and cross-network access problems to solve mobile Internet services DNS problems caused by abnormal.

Tencent cloud HttpDNS as a reference, the advantages compared to traditional LocalDNS comparison:
Here Insert Picture Description

Load Balancing

In order to address performance issues as well as of a single point on a single machine, multiple machines need to scale horizontally through load balancing, traffic requests are distributed to different servers above.

客户端的流量首先会到达负载均衡服务器,由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面,同时负载均衡服务器也会对应用服务器做周期性的健康检查,当发现故障节点时便动态的将节点从应用服务器集群中剔除,以此来保证应用的高可用。

网络负载均衡主要有硬件与软件两种实现方式,主流负载均衡解决方案中,硬件厂商以F5为代表,软件主要为LVS、NGINX、HAProxy。

技术原理上分为L4四层负载均衡和L7七层负载均衡。

L4 vs L7
Here Insert Picture Description
L4四层负载均衡工作于处于OSI模型的传输层,主要工作是转发。它在接收到客户端报文后,需要了解传输层的协议内容,根据预设的转发模式和调度算法将报文转发到应用服务器。以TCP为例,当一个TCP连接的初始SYN报文到达时,调度器就选择一台服务器,将报文转发给它。此后通过查发报文的IP和TCP报文头地址,保证此连接的后继报文被转发到该服务器。

L7七层负载均衡工作在OSI模型的应用层,主要工作就是代理。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求解析出来,再按照调度算法选择一个应用服务器,并与应用服务器建立另外一条连接将请求发送过去。

LVS转发模式

LVS(IP负载均衡技术)工作在L4四层以下,转发模式有:DR模式、NAT模式、TUNNEL模式、FULL NAT模式。
Here Insert Picture Description
DR模式(直接路由)
Here Insert Picture Description
改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。要求调度器与真实服务器都有一块网卡连在同一物理网段上,并且真实服务器需要配置VIP。

NAT模式 (网络地址转换)
Here Insert Picture Description
调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文通过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。要求负载均衡需要以网关的形式存在于网络中。

TUNNEL模式
Here Insert Picture Description
调度器把请求报文通过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,所以调度器只处理请求报文。要求真实服务器支持隧道协议和配置VIP。

FULL NAT模式
Here Insert Picture Description
在NAT模式的基础上做一次源地址转换(即SNAT),做SNAT的好处是可以让应答流量经过正常的三层路由回到负载均衡上,这样负载均衡就不需要以网关的形式存在于网络中了。性能要逊色于NAT模式,真实服务器会丢失客户端的真实IP地址。

调度算法

轮询

将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。

加权轮询

权值越大分配到的访问概率越高,主要用于后端每台服务器性能不均衡的情况下,达到合理有效的地利用主机资源。

最少连接

将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用"最小连接"调度算法可以较好地均衡负载

哈希

将指定的Key的哈希值与服务器数目进行取模运算,获取要求的服务器的序号

一致性哈希

考虑到分布式系统每个节点都有可能失效,并且新的节点很可能动态的增加进来,一致性哈希可以保证当系统的节点数目发生变化时尽可能减少访问节点的移动。

API网关

API网关(API Gateway)是一个服务器集群,对外的唯一入口。从面向对象设计的角度看,它与外观模式类似。API网关封装了系统内部架构,对外提供REST/HTTP的访问API。同时还具有其它非业务相关的职责,如身份验证、监控、负载均衡、缓存、流量控制等。

API管理

API网关核心功能是 API 管理。提供 API
的完整生命周期管理,包括创建、维护、发布、运行、下线等基础功能;提供测试,预发布,发布等多种环境;提供版本管理,版本回滚。

API配置包括前端配置和后端配置。前端配置指的是Http相关的配置,如HTTP 方法、URL路径,请求参数等。后端配置指的是微服务的相关配置,如服务名称、服务参数等。这样通过API配置,就完成了前端Http到后端微服务的转换。

全异步

由于API网关主要处理的是网络I/O,那么通过非阻塞I/O以及I/O多路复用,就可以达到使用少量线程承载海量并发处理,避免线程上下文切换,大大增加系统吞吐量,减少机器成本。

常用解决方案有 Tomcat/Jetty+NIO+servlet3.1 和Netty+NIO,这里推荐Netty+NIO,能实现更高的吞吐量。Spring 5.0 推出的WebFlux反应式编程模型,特点是异步的、事件驱动的、非阻塞,内部就是基于Netty+NIO 或者Servlet 3.1 Non-Blocking IO容器 实现的。

链式处理

链式处理即通过责任链模式,基于 Filter 链的方式提供了网关基本的功能,例如:路由、协议转换、缓存、限流、监控、日志。也可以根据实际的业务需要进行扩展,但注意不要做耗时操作。
Here Insert Picture Description
Spring cloud gateway (基于 Spring WebFlux)的工作机制大体如下:

Gateway 接收客户端请求。

客户端请求与路由信息进行匹配,匹配成功的才能够被发往相应的下游服务。

请求经过 Filter 过滤器链,执行 pre 处理逻辑,如修改请求头信息等。

请求被转发至下游服务并返回响应。

响应经过 Filter 过滤器链,执行 post 处理逻辑。

向客户端响应应答。

请求限流
请求限流是在面对未知流量的情况下,防止系统被冲垮的最后一道有效的防线。可以针对集群、业务系统和具体API维度进行限流。

具体实现可以分为集群版和单机版,区别就是集群版是使用后端统一缓存如Redis存储数据,但有一定的性能损耗;单机版则在本机内存中进行存储(推荐)。

常用的限流算法:计数器、漏桶、令牌桶(推荐)

熔断降级

服务熔断

当下游的服务因为某种原因突然变得不可用或响应过慢,上游服务为了保证自己整体服务的可用性,不再继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。

熔断是为了解决服务雪崩,特别是在微服务体系下,通常在框架层面进行处理。内部机制采用的是断路器模式,其内部状态转换图如下:
Here Insert Picture Description
服务降级

当负荷超出系统整体负载承受能力时,为了保证核心服务的可用,通常可以对非核心服务进行降级,如果返回缓存内容或者直接返回。

服务降级的粒度可以是API维度、功能维度、甚至是系统维度,但是都需要事前进行服务级别的梳理和定义。

真实场景下,通常是在服务器负载超出阈值报警之后,管理员决定是扩容还是降级。

业务隔离

API网关统一了非业务层面的处理,但如果有业务处理的逻辑,不同业务之间就可能会相互影响。要进行业务系统的隔离,通常可以采用线程池隔离和集群隔离,但对于Java而言,线程是比较重的资源,推荐使用集群隔离。

PUSH推送

消息推送系统 针对不同的场景推出多种推送类型,满足用户的个性化推送需求,并集成了苹果、华为、小米、FCM
等厂商渠道的推送功能,在提供控制台快速推送能力的同时,也提供了服务端接入方案,方便用户快速集成移动终端推送功能,与用户保持互动,从而有效地提高用户留存率,提升用户体验。

Here Insert Picture Description
Construction equipment company, registered, bind the user process
Here Insert Picture Description
push messaging process
Here Insert Picture Description
in a lot of business scenarios, users may not occur when a business online, you may not have a network. Therefore, all the messages in the MPS will be persistent. When business occurs, MPS will try to do a push (push or self-built third-party channels to push TCP connections). Self-built channels, will pass the query cache to determine whether the user's terminal has TCP connection, if there is a push, after the client receives the push message, the server will return receipt, the server can update the status of the message. If the push fails, or receipt is lost, the next time the user when the connection is established, it will re-accept message notification, and the client would logically go heavy.

Micro service system

Here Insert Picture Description

Author: VectorJin

Source: https: //juejin.im/post/5e353a14e51d453cf422c6cb#heading-8
above are some of my own thoughts, to share out the welcome to correct me, the way to find a wave of concern inside information you little concerned about my partner after private letter [ Java ] you can receive free ~

Published 19 original articles · won praise 7 · views 6460

Guess you like

Origin blog.csdn.net/ZYQZXF/article/details/104399438