互联网公司理想架构的探讨

　　本文探讨了互联网公司的技术架构，涉及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协议向运营商Local DNS发起解析请求的传统方式，可以避免Local DNS造成的域名劫持和跨网访问问题，解决移动互联网服务中域名解析异常带来的困扰。
　　以腾讯云HttpDNS为参考，相较于传统LocalDNS的优势对比：
　　优势
　　腾讯云HttpDNS
　　运营商LocalDNS
　　高速
　　接入节点覆盖国内Top17运营商、东南亚及北美，解析精准，访问迅速
　　用户跨网访问、解析异常问题
　　安全
　　绕开运营商Local DNS，无劫持，防止DNS被污染拦截
　　域名解析结果被指向广告页面、插入第三方广告
　　智能
　　精确识别来源请求，访问导向最准确节点
　　自身不进行域名递归解析，而把请求转发给其他运营商
　　可靠
　　一个IP三地集群容灾，秒级自动故障切换，服务提供99%以上的SLA
　　缓存服务器运维环境参差不齐，时有故障 负载均衡
　　为了解决单台机器的性能问题以及单点问题，需要通过负载均衡将多台机器进行水平扩展，将请求流量分发到不同的服务器上面。
　　客户端的流量首先会到达负载均衡服务器，由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面，同时负载均衡服务器也会对应用服务器做周期性的健康检查，当发现故障节点时便动态的将节点从应用服务器集群中剔除，以此来保证应用的高可用。
　　网络负载均衡主要有硬件与软件两种实现方式，主流负载均衡解决方案中，硬件厂商以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 连接，如果存在则推送，客户端收到推送消息后，会给服务端回执，服务端即可更新消息状态。如果推送失败，或者回执丢失，用户在下一次建立连接时，会重新接受消息通知，同时客户端会进行逻辑去重。 微服务体系
　　转载地址：https://mp.weixin.qq.com/s/fqPLVZkAhyjAlXqLeXh7Ow
　　转载公众号：架构文摘