互联网公司理想的技术架构！看完我收藏了

本文探讨了互联网公司的技术架构，涉及 DNS、负载均衡、长链接、API 网关、PUSH 推送、微服务、分布式事务以及相关支撑的基础服务。主要是为了学习，但愿能够给你们一个参考。

总体架构

APP、PC以及第三方等调用方经过传统的域名解析服务LocalDNS获取负载均衡器的IP，APP能够经过HttpDNS的方式来实现更实时和灵活精准的域名解析服务。

经过负载均衡器到达统一接入层，统一接入层维护长链接 。

API网关做为微服务的入口，负责协议转换、请求路由、认证鉴权、流量控制、数据缓存等。业务Server经过PUSH推送系统来实现对端的实时推送，如IM、通知等功能。

业务Server之间经过专有的RPC协议实现相互调用，并经过NAT网关调用外部第三方服务。

域名解析

传统 DNS

DNS（Domain Name System）域名系统，一种分布式网络目录服务，用于域名与 IP 地址的相互转换，可以令人更方便的访问互联网，而不用去记住机器的 IP 地址。

DNS 的解析过程以下：

• 客户端递归查询 LocalDNS（通常是 ISP 互联网服务提供商提供的边缘 DNS 服务器）获取 IP。
• LocalDNS 迭代查询获取 IP，即不断的获取域名服务器的地址进行查询。

HttpDNS

移动解析（HttpDNS）基于 Http 协议向 DNS 服务器发送域名解析请求，替代了基于 DNS 协议向运营商 LocalDNS 发起解析请求的传统方式。

它能够避免 LocalDNS 形成的域名劫持和跨网访问问题，解决移动互联网服务中域名解析异常带来的困扰。

以腾讯云 HttpDNS 为参考，相较于传统 LocalDNS 的优点对比：

负载均衡

为了解决单台机器的性能问题以及单点问题，须要经过负载均衡将多台机器进行水平扩展，将请求流量分发到不一样的服务器上面。

客户端的流量首先会到达负载均衡服务器，由负载均衡服务器经过必定的调度算法将流量分发到不一样的应用服务器上面。

同时负载均衡服务器也会对应用服务器作周期性的健康检查，当发现故障节点时便动态的将节点从应用服务器集群中剔除，以此来保证应用的高可用。

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

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

L4 vs L7

L4 四层负载均衡工做于处于 OSI 模型的传输层，主要工做是转发。它在接收到客户端报文后，须要了解传输层的协议内容，根据预设的转发模式和调度算法将报文转发到应用服务器。

以 TCP 为例，当一个 TCP 链接的初始 SYN 报文到达时，调度器就选择一台服务器，将报文转发给它。

此后经过查发报文的 IP 和 TCP 报文头地址，保证此链接的后继报文被转发到该服务器。

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

LVS 转发模式

LVS（IP 负载均衡技术）工做在 L4 四层如下，转发模式有：

• DR 模式
• NAT 模式
• TUNNEL 模式
• FULL NAT 模式

①DR 模式（直接路由）

改写请求报文的 MAC 地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。

要求调度器与真实服务器都有一块网卡连在同一物理网段上，而且真实服务器须要配置 VIP。

②NAT 模式 （网络地址转换）

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

③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 推送

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

①设备建连、注册、绑定用户流程

②消息推送过程

在很是多的业务场景中，当业务发生时用户未必在线，也未必有网络。所以，在 MPS 中全部消息均会被持久化。业务发生时，MPS 会尝试作一次推送（第三方渠道推送或自建的 TCP 链接推送）。

自建渠道中，会经过查询缓存来判断用户的终端是否有 TCP 链接，若是存在则推送，客户端收到推送消息后，会给服务端回执，服务端便可更新消息状态。

若是推送失败，或者回执丢失，用户在下一次创建链接时，会从新接受消息通知，同时客户端会进行逻辑去重。

微服务体系

做者：VectorJin
连接：https://juejin.cn/post/684490...