加入收藏 | 设为首页 | 会员中心 | 我要投稿 温州站长网 (https://www.0577zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 服务器 > 搭建环境 > Unix > 正文

偷偷告诉你,互联网公司理想的技术架构!

发布时间:2020-02-14 17:11:00 所属栏目:Unix 来源:站长网
导读:副标题#e# 图片来自 Pexels 整体架构 App、PC 以及第三方等调用方通过传统的域名解析服务 LocalDNS 获取负载均衡器的 IP,App 可以通过 HttpDNS 的方式来实现更实时和灵活精准的域名解析服务。 通过负载均衡器到达统一接入层,统一接入层维护长连接 。 API

偷偷告诉你,互联网公司理想的技术架构!

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

③TUNNEL 模式

偷偷告诉你,互联网公司理想的技术架构!

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

④FULL NAT 模式

偷偷告诉你,互联网公司理想的技术架构!

在 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 链的方式提供了网关基本的功能,例如:路由、协议转换、缓存、限流、监控、日志。也可以根据实际的业务需要进行扩展,但注意不要做耗时操作。

偷偷告诉你,互联网公司理想的技术架构!

Spring Cloud Gateway (基于 Spring WebFlux)的工作机制大体如下:

Gateway 接收客户端请求。

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

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

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

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

向客户端响应应答。

请求限流

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

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

常用的限流算法:

计数器

漏桶

令牌桶(推荐)

熔断降级

①服务熔断

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

熔断是为了解决服务雪崩,特别是在微服务体系下,通常在框架层面进行处理。

内部机制采用的是断路器模式,其内部状态转换图如下: 

偷偷告诉你,互联网公司理想的技术架构!

②服务降级

当负荷超出系统整体负载承受能力时,为了保证核心服务的可用,通常可以对非核心服务进行降级。

如果返回缓存内容或者直接返回,服务降级的粒度可以是 API 维度、功能维度、甚至是系统维度,但是都需要事前进行服务级别的梳理和定义。

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

业务隔离

API 网关统一了非业务层面的处理,但如果有业务处理的逻辑,不同业务之间就可能会相互影响。

要进行业务系统的隔离,通常可以采用线程池隔离和集群隔离,但对于 Java 而言,线程是比较重的资源,推荐使用集群隔离。

PUSH 推送

(编辑:温州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读