探讨互联网理想架构

标签: 探讨 互联网 理想 | 发表时间:2020-03-05 03:55 | 作者:翔宇
出处:http://weekly.dockone.io

【编者的话】本文探讨了互联网公司的技术架构,涉及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的优势对比:

负载均衡

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

客户端的流量首先会到达负载均衡服务器,由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面,同时负载均衡服务器也会对应用服务器做周期性的健康检查,当发现故障节点时便动态的将节点从应用服务器集群中剔除,以此来保证应用的高可用。

网络负载均衡主要有硬件与软件两种实现方式,主流负载均衡解决方案中,硬件厂商以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+servlet 3.1和Netty+NIO,这里推荐Netty+NIO,能实现更高的吞吐量。Spring 5.0推出的WebFlux反应式编程模型,特点是异步的、事件驱动的、非阻塞,内部就是基于Netty+NIO或者Servlet 3.1 Non-Blocking IO容器实现的。

链式处理

链式处理即通过责任链模式,基于Filter链的方式提供了网关基本的功能,例如:路由、协议转换、缓存、限流、监控、日志。也可以根据实际的业务需要进行扩展,但注意不要做耗时操作。

Spring Cloud Gateway(基于Spring WebFlux)的工作机制大体如下:
  1. Gateway接收客户端请求。
  2. 客户端请求与路由信息进行匹配,匹配成功的才能够被发往相应的下游服务。
  3. 请求经过Filter过滤器链,执行pre处理逻辑,如修改请求头信息等。
  4. 请求被转发至下游服务并返回响应。
  5. 响应经过Filter过滤器链,执行post处理逻辑。
  6. 向客户端响应应答。


请求限流

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

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

常用的限流算法:计数器、漏桶、令牌桶(推荐)

熔断降级

服务熔断

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

熔断是为了解决服务雪崩,特别是在微服务体系下,通常在框架层面进行处理。内部机制采用的是断路器模式,其内部状态转换图如下:

服务降级

当负荷超出系统整体负载承受能力时,为了保证核心服务的可用,通常可以对非核心服务进行降级,如果返回缓存内容或者直接返回。

服务降级的粒度可以是API维度、功能维度、甚至是系统维度,但是都需要事前进行服务级别的梳理和定义。

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

业务隔离

API网关统一了非业务层面的处理,但如果有业务处理的逻辑,不同业务之间就可能会相互影响。要进行业务系统的隔离,通常可以采用线程池隔离和集群隔离,但对于Java而言,线程是比较重的资源,推荐使用集群隔离。

PUSH推送

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

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

消息推送过程:

在非常多的业务场景中,当业务发生时用户未必在线,也未必有网络。因此,在MPS中所有消息均会被持久化。业务发生时,MPS会尝试做一次推送(第三方渠道推送或自建的TCP连接推送)。自建渠道中,会通过查询缓存来判断用户的终端是否有TCP连接,如果存在则推送,客户端收到推送消息后,会给服务端回执,服务端即可更新消息状态。如果推送失败,或者回执丢失,用户在下一次建立连接时,会重新接受消息通知,同时客户端会进行逻辑去重。

微服务体系



原文链接: https://juejin.im/post/5e353a14e51d453cf422c6cb

相关 [探讨 互联网 理想] 推荐:

探讨互联网理想架构

- - DockOne.io
【编者的话】本文探讨了互联网公司的技术架构,涉及DNS、负载均衡、长连接、API网关、PUSH推送、微服务、分布式事务以及相关支撑的基础服务. 主要是为了学习,希望可以给大家一个参考. APP、PC以及第三方等调用方通过传统的域名解析服务LocalDNS获取负载均衡器的IP,APP可以通过HttpDNS的方式来实现更实时和灵活精准的域名解析服务.

小米是互联网公司吗?雷军的理想与小米的现实

- - 博客园_新闻
尽管早在创业之初雷军就宣讲过自己的答案,但此后 8 年,小米这家公司却从未逃离由上述论题所引发的自我折磨. “小米是一定以手机、智能硬件和 IoT 平台为核心的互联网公司. ” 小米的 IPO 招股书中,“互联网公司”的身份界定之前被附加了多达 3 个定语. 其中后两个,正是在经历了 2015 年“U型”低谷后,小米为自己拓展出的新商业机会.

移动互联网=移动+互联网?

- 可可 - It Talks-魏武挥的blog
从名词上看,移动互联网似乎就是互联网加上一个移动. 但移动互联网远不是“移动的互联网”那么简单. 它的本质——网络部分,就和互联网大不相同;而它的表现——移动部分,也正因为移动,造就了很多和互联网相当不一样的商业机会. 而更重要也是很多人并没有注意到的是,它可能会改变整整一代人的信息处理习惯. 从网络部分而言,我们都知道,理论上互联网是没有拥有者的.

重新索引互联网

- keso - 爱范儿 · Beats of Bits
重新索引互联网 Facebook 雇佣公关抹黑 Google 的过程已经水落石出. 问题是: Google 那么多产品, Facebook 为何对 Social Circle 这么敏感. Google 号称自己的使命是“索引互联网”. 这件事的难点并非派出多少爬虫,而是对收集来的海量内容做排序:怎样让真正重要的网页,的排到 Google 搜索结果的前面来.

中美互联网差异

- leeking001 - 互联网的那点事
在互联网以指数的速度发展的今天,人们的生活已经离不开网络,那么,这两个打过在互联网方面有什 么差异呢. 我们从下面一系列与互联网相关的参数来比较两个国家,比如:互联网用户数量,互联网普及率,互联网连接的速度,域名数量,受欢迎的网站,网页浏 览器,操作系统等等. 十年前,美国是世界上的互联网头号大国,而现在很明显已经不是,取而代之的是中国.

重新索引互联网

- Ray - 最新文章 - UCD大社区
重新索引互联网 Facebook 雇佣公关抹黑 Google 的过程已经水落石出. 问题是: Google 那么多产品, Facebook 为何对 Social Circle 这么敏感. Google 号称自己的使命是“索引互联网”. 这件事的难点并非派出多少爬虫,而是对收集来的海量内容做排序:怎样让真正重要的网页,的排到 Google 搜索结果的前面来.

互联网七巧板

- Ray ma - 云科技
话说天下事势,合久必分分久必合. 大半年前在一辆宝马车里,一互联网大佬爆料说“百度可能收购新浪,肯定在谈”. 半个月前又开始传,百度高管去硅谷跟Facebook谈合资了. 前天又听到,搜狐可能和另一家互联网巨头合资做微博. 互联网的谣言和互联网的股价一样,起起伏伏. 不过,本文主题不是关于百度或者搜狐或者新浪,而是关于合资.

被选择的互联网

- Jacqueline - 月光博客
  连线杂志的那篇《互联网死了》确实震动业界,而现在,百度的框计算似乎正在验证他的话. 无论是高兴也好,无论是哀嚎也罢,百度的框计算终究给最终用户带来了一些实际的东西. 他改变了人们对于传统搜索的认知. 而百度这类似的行为,正成为互联网的一种趋势. 可以说,商业化的大潮,正在人为的割裂互联网,让他的边界越来越明显.

互联网的锤子(三)

- 盛开 - 月光博客
  对微博的讨论思路仍将从信息的获取和发布两个方面结合微博的特征来讨论,这将是我们的思维定势.   2006年twitter诞生,在blog之后,在rss,digg,youtube之后. 在这些应用出现之后,网民创造的信息内容与日俱增,对新闻资讯,博文的评论散落在网络的各个角落. Twitter生逢其时,将网民集合在一个平台上,最初将这一优势显现出来的是对突发新闻的报道,在现场的网民发布现场图片信息,通过twitter直接将图片传送给其他网民,经过转发评论,现场的新闻图片传播到整个twitter平台上,实现即时广泛的传播.

Facebook = 未来的互联网?

- iamsure - 爱范儿 · Beats of Bits
或许现在许多人看到这个标题的时候还会认为是危言耸听,可这一天似乎已经离我们越来越近. 社交网络可能就是未来互联网的代名词. 毋庸置疑的是,互联网依然增长迅猛,但从以下三组数据我们发现,互联网的增长重心在向特定方向聚集. 线上视频保持着爆炸性增长,每年用户使用增长率 45%. 移动设备用户上网使用时间较去年增长了28%,其中智能手机用户上网使用时间翻倍.