图片来自 Pexels
App、PC 以及第三方等调用方通过传统的域名解析服务 LocalDNS 获取负载均衡器的 IP，App 可以通过 HttpDNS 的方式来实现更实时和灵活精准的域名解析服务。通过负载均衡器到达统一接入层，统一接入层维护长连接 。
API 网关作为微服务的入口，负责协议转换、请求路由、认证鉴权、流量控制、数据缓存等。
业务 Server 通过 PUSH 推送系统来实现对端的实时推送，如 IM、通知等功能。
业务 Server 之间通过专有的 RPC 协议实现相互调用，并通过 NAT 网关调用外部第三方服务。
DNS（Domain Name System）域名系统，一种分布式网络目录服务，用于域名与 IP 地址的相互转换，能够使人更方便的访问互联网，而不用去记住机器的 IP 地址。DNS 的解析过程如下：
移动解析（HttpDNS）基于 Http 协议向 DNS 服务器发送域名解析请求，替代了基于 DNS 协议向运营商 LocalDNS 发起解析请求的传统方式。
它可以避免 LocalDNS 造成的域名劫持和跨网访问问题，解决移动互联网服务中域名解析异常带来的困扰。
以腾讯云 HttpDNS 为参考，相较于传统 LocalDNS 的优势对比：
L4 四层负载均衡工作于处于 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 而言，线程是比较重的资源，推荐使用集群隔离。
消息推送系统针对不同的场景推出多种推送类型，满足用户的个性化推送需求，并集成了苹果、华为、小米、FCM
等厂商渠道的推送功能，在提供控制台快速推送能力的同时，也提供了服务端接入方案，方便用户快速集成移动终端推送功能，与用户保持互动，从而有效地提高用户留存率，提升用户体验。
在非常多的业务场景中，当业务发生时用户未必在线，也未必有网络。因此，在 MPS 中所有消息均会被持久化。业务发生时，MPS 会尝试做一次推送（第三方渠道推送或自建的 TCP 连接推送）。
来源：https://juejin.im/post/5e353a14e51d453cf422c6cb
END