本文探讨了互联网公司的技术架构，涉及 DNS、负载均衡、长连接、API 网关、PUSH 推送、微服务、分布式事务以及相关支撑的基础服务。主要是为了学习，希望可以给大家一个参考。
整体架构
App、PC 以及第三方等调用方通过传统的域名解析服务 LocalDNS 获取负载均衡器的 IP，App 可以通过 HttpDNS 的方式来实现更实时和灵活精准的域名解析服务。
通过负载均衡器到达统一接入层，统一接入层维护长连接 。
API 网关作为微服务的入口，负责协议转换、请求路由、认证鉴权、流量控制、数据缓存等。
业务 Server 通过 PUSH 推送系统来实现对端的实时推送，如 IM、通知等功能。
业务 Server 之间通过专有的 RPC 协议实现相互调用，并通过 NAT 网关调用外部第三方服务。DNS（Domain Name System）域名系统，一种分布式网络目录服务，用于域名与 IP 地址的相互转换，能够使人更方便的访问互联网，而不用去记住机器的 IP 地址。
移动解析（HttpDNS）基于 Http 协议向 DNS 服务器发送域名解析请求，替代了基于 DNS 协议向运营商 LocalDNS 发起解析请求的传统方式。
它可以避免 LocalDNS 造成的域名劫持和跨网访问问题，解决移动互联网服务中域名解析异常带来的困扰。
以腾讯云 HttpDNS 为参考，相较于传统 LocalDNS 的优势对比：
为了解决单台机器的性能问题以及单点问题，需要通过负载均衡将多台机器进行水平扩展，将请求流量分发到不同的服务器上面。
客户端的流量首先会到达负载均衡服务器，由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面。
同时负载均衡服务器也会对应用服务器做周期性的健康检查，当发现故障节点时便动态的将节点从应用服务器集群中剔除，以此来保证应用的高可用。
网络负载均衡主要有硬件与软件两种实现方式，主流负载均衡解决方案中，硬件厂商以 F5 为代表，软件主要为 LVS、NGINX、HAProxy。
技术原理上分为 L4 四层负载均衡和 L7 七层负载均衡。
L4 四层负载均衡工作于处于 OSI 模型的传输层，主要工作是转发。它在接收到客户端报文后，需要了解传输层的协议内容，根据预设的转发模式和调度算法将报文转发到应用服务器。
以 TCP 为例，当一个 TCP 连接的初始 SYN 报文到达时，调度器就选择一台服务器，将报文转发给它。
此后通过查发报文的 IP 和 TCP 报文头地址，保证此连接的后继报文被转发到该服务器。
L7 七层负载均衡工作在 OSI 模型的应用层，主要工作就是代理。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求解析出来，再按照调度算法选择一个应用服务器，并与应用服务器建立另外一条连接将请求发送过去。
LVS（IP 负载均衡技术）工作在 L4 四层以下，转发模式有：
改写请求报文的 MAC 地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。
要求调度器与真实服务器都有一块网卡连在同一物理网段上，并且真实服务器需要配置 VIP。
调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。要求负载均衡需要以网关的形式存在于网络中。
调度器把请求报文通过 IP 隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。要求真实服务器支持隧道协议和配置 VIP。
在 NAT 模式的基础上做一次源地址转换（即 SNAT），做 SNAT 的好处是可以让应答流量经过正常的三层路由回到负载均衡上，这样负载均衡就不需要以网关的形式存在于网络中了。
性能要逊色于 NAT 模式，真实服务器会丢失客户端的真实 IP 地址。
将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
权值越大分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下，达到合理有效的地利用主机资源。
将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
将指定的 Key 的哈希值与服务器数目进行取模运算，获取要求的服务器的序号
考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来，一致性哈希可以保证当系统的节点数目发生变化时尽可能减少访问节点的移动。API 网关（API Gateway）是一个服务器集群，对外的唯一入口。从面向对象设计的角度看，它与外观模式类似。
API 网关封装了系统内部架构，对外提供 REST/HTTP 的访问 API。同时还具有其他非业务相关的职责，如身份验证、监控、负载均衡、缓存、流量控制等。
API 网关核心功能是 API 管理。提供 API 的完整生命周期管理，包括创建、维护、发布、运行、下线等基础功能；提供测试，预发布，发布等多种环境；提供版本管理，版本回滚。
API 配置包括前端配置和后端配置：
由于 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.im/post/5e353a14e51d453cf422c6cb