从微服务开始掌控全局_直播从l2层级节点回源-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_22421145/article/details/135439666

在这里插入图片描述

一、架构发展历程

软件架构发展过程大致分为：单体、烟囱/洋葱/插件…架构、重量级企业架构、微服务、Serverless（详细见我写的另一篇文章进化中的架构）。它们的发展过程代表了技术从简单到复杂，吞吐量/容量从小到大，组织架构也随之不断变更，个人在其中的作用也被无限缩小。微服务作为当下主流架构，从它入手学习系统的全貌，了解自身在软件开发过程中所处的位置，无疑是非常具有趣味性的事情。

1.1、微服务

如果面试官要你介绍一下微服务，你会如何说呢？
（大背景）在当下移动互联网时代，用户众多，这带来了qps高、需求变化频繁、竞争压力大、迭代速度快等问题，传统架构难以很好地解决，微服务应运而生。
（优点）一般利用DDD原则划分出多个领域，由不同团队独自维护开发，不仅做到了代码物理隔离，提高稳定性，代码维护方便，也由于领域相对独立，组织架构随之改变，解决了沟通协作成本高的问题，再配合各种需求管理方法论和CIDI流水线，支持了需求快速迭代。同时因为单个服务较轻量级，配合k8s如扩缩容、mq等，无疑带来了很大的灵活性和横向扩展性，轻松应对系统容量调整。
（缺点）但微服务的缺点同样不可忽视，它带来了非同寻常的复杂度。如微服务间通信相较于本地方法调用，需要额外考虑协议选择、降级容错、限流、下游容量、以及各种参数配置。再比如一致性，需要额外考虑分布式事务、CAP原则…如果忽视这些东西，即使系统一时没有出问题，崩溃也是迟早的事情。
（构成）现在一个微服务系统，一般包含以下几种角色，或者说是能力：
1、网关，主要起到流量入口的作用，根据url的path将流量转发到不同服务上。除此以外，网关还可以做一些偏业务的事情，比如失败重试、风控、限流、流量灰度等。
2、注册中心，服务的每台实例启动时，会把自身ip、服务唯一标识等信息注册到注册中心，用于服务发现。调用者请求时可以根据服务唯一标识从注册中心拿到若干实例。
3、配置中心，是统一保存配置的地方。它一般有以下能力，当修改配置时，能够主动推送到所有实例；保留每次修改的记录，知道是谁几点修改了什么内容，并能够回滚；区分不同的机房/集群，能够分别配置。
4、业务服务，指的是我们自己编写的服务。按照角色可以区分为：

BFF，业务网关，一般对应于一个产品。编排Server提供的接口，形成最终的逻辑，将数据吐给客户端。也会做一些业务强相关的事情，如鉴权。较大较复杂的业务会采用这种形式，结构上更加清晰，功能复用度更高
Server，主要的业务逻辑，并提供rpc给其它服务调用
Job，各类任务，包括定时任务、mq等
Manager，管理后台

5、sidecar，有必要在这里把它从服务网格中单独拿出来说，因为作为控制面板，会劫持应用流量做一些控制，可能会造成与预期不符的情况，比如db-sidecar配置连接池固定为1000个，任你应用配置怎么改也没用。我们服务启动时，k8s会自动帮我们在同一个pod上启动一个或多个sidecar服务，用于管理/监控我们服务的数据库连接、rpc请求等。这其实是网格服务思想，在无侵入的前提下管理和监控整个微服务。但sidecar从来没有真正地流行起来，它带来很多的额外资源消耗，尤其在现在降本增效的大前提下，sidecar已经变成proxyless模式，既使用sdk来代替。但这样老问题又回来了，要为不同语言维护不同的sdk、如何让数量众多的应用及时升级sdk版本…
6、可观测性，把可观测性换成透明度可能没有这么绕口，意思就是微服务如此复杂，我们必须有能力知道当前系统的运行状态，一个请求经过了哪些服务、时间消耗在了哪里、有问题及时报警、出问题时快速定位…总而言之，可观测性包含三个方面，分别是日志、链路追踪、监控。
（展望）微服务的缺点十分明显，系统过于复杂，开发投入了过多精力在系统维护上，不能100%投入到业务开发。下一代架构Serverless就解决了这个问题，目前Serverless的一种实现方案FAAS已经在腾讯云、阿里云等对外公开使用，使用者无需关注cpu、内存、扩缩容等等，只需编写方法上传到FAAS中即可运行，其他一切交给云。

下面，将进入微服务内部，看一看每个关键技术的底层原理
在这里插入图片描述

二、RPC

2.1、rpc是什么

如果面试官问你，restful与rpc的区别是什么，你会怎么回答？
（背景）rpc起始于对本地方法的对标，希望以调用本地方法的形式来调用远程方法，所以它们有一些共性，比如要性能好、是面向方法的。而resuful是一种理念，指导我们如何设计出优雅的面向资源的接口，而且其作者主导了http1.1设计，restful身上的http味道是很浓厚的。从这里不难看出，restful和rpc的根本出发点就不一样。
而且从现在的实践上来看，人们都是以http来承载restful，而rpc用在需要高性能交互的微服务之间。然而事无绝对，比如spring feign就使用http来作为微服务之间交互的协议。再比如为了带宽成本和性能，一些app客户端与服务器的交互也采用了grpc，主要还是看具体的场景。综上所述，resuful与rpc是两个独立的东西，但是又有一些交叉在里面。
在这里插入图片描述

（详细讲解rpc）尽管rpc与本地方法看起来有些共同点，但两者本质上却是毫无关联。很久以前，有大能已经列举了rpc的‘种种原罪’：

网络是可靠的
延迟是不存在的
带宽是无限的
网络是安全的
拓扑结构是一成不变的
总会有一个管理员
不必考虑传输成本
网络是同质化的

如果忽视这些问题，你的程序将崩溃。而且从中也不难看出，为什么远程调用要配置超时、要做降级、要熔断、要限流，很大程度就是为这些问题买单！
目前rpc框架最基本的功能无外乎都是为了解决以下三个问题：

如何表示数据：如何表示方法签名，参数和返回。比如grpc的protobuf
如何传输数据：用什么协议传输数据。比如grpc基于h2构建的协议，协议本身就叫做grpc
如何确定方法：一个远程请求来了，如何确定调用哪个本地方法。比如grpc的protobuf

除了解决以上问题，rpc框架还会支持一些高级功能，比如基于服务注册发现的调用、流式传输、自定义序列化协议、透明度等等，基本上就是这样。

2.2、详细拆解grpc

看我以前写的grpc实现原理

三、事务

在这里插入图片描述

面试官可能不会问你什么是事务，但你不能不知道它的来龙去脉。否则僵硬地回答ACID、隔离级别这些概念又与死记硬背有啥区别呢？
首先，事务这个概念是关系型数据库为了解决数据一致性问题而提出的概念。保证数据一致性的场景很多，比如语言层面的锁、java中保证可见性的volitate、硬件层面的总线锁…等等，事务只是其中之一。
事务似乎随着服务架构的发展而不断进化，单体架构使用本地事务即可，再往后提出XA全局事务用于支持多个数据库参与的事务，到了微服务时代，基于CAP原理，传统意义上的事务实现成本过于巨大，所以又提出了分布式事务。

3.1、本地事务

说起本地事务，都会提起它的四大特性，分别是A原子性、C一致性、I隔离性、D持久性。按照因果关系来说，因为有了A、I、D，所以达成了C。下面我们看看A、I、D是如何实现的。

3.1.1、实现原子性和持久性

待完善

3.1.2、实现隔离性

待完善

四、网络链路

如果面试官问你，浏览器输入一个url后会发生什么，你会怎么回答呢？
（由大到小、由粗到细）大致分为以下几个步骤：

DNS域名解析
流量经过CDN到达服务端
服务端响应

4.1、DNS域名解析

在这里插入图片描述
相关文章太多了，我再写一遍无异于画蛇添足，可以看这篇文章来了解基本原理

4.2、CDN

4.2.1、用户的请求如何进入CDN

这里再描述一遍请求流量是如何从DNS走到CDN的
在这里插入图片描述
上图是一次普通的DNS解析域名过程，本地DNS经过递归查询获取到icyfenix.cn的ip地址，如果返回的不是ip地址而是CNAME，那么本地DNS又会经历一遍递归查询，最终从CDN服务商架设的DNS权威服务器中，得到一个具体的CDN地址并返回给客户端，如下图所示：
在这里插入图片描述
上面描述的流程，客户端对cdn是无感知的，它更像是在浏览器输入一个网址，获取网页资源的过程。但实际上音视频app中并不是这样工作的，其中涉及到各类复杂情况，这点会在cdn一节最后描述。（你需要先阅读以下内容作为铺垫）

4.2.2、CDN是什么

如果你去百度cdn是什么，只会得到它是内容分发网络，有什么什么作用，因为这是从外部视角来看待/使用它。从内部视角来看，就会发现它的另一面。
cdn系统一般有多级缓存，最底层是边缘CND节点（边缘一词并不代表不重要，而是借用了公网的概念，边缘网络-骨干网），边缘节点数量最多，距离用户最近，可以说是一级缓存。
L2 cdn节点一般部署在骨干网上，可以看做是二级缓存。当用户的资源请求穿透边缘节点时，一般会查询l2节点（不绝对，与回源策略有关）。
源站保存了所有原始数据，一般技术方案是hdfs。它的特点是数据存储量大、流量较小、功能齐全（包含了视频转码、切片、同步媒资到cdn系统…）
cdn

那么用户请求一份数据，是如何回源的呢？
首先数据分发方式分为主动推送和被动回源。我们可以调用cdn系统提供的api接口同步媒资，由cdn系统去推送到各个节点。而被动回源方式见下图
在这里插入图片描述
主播分大小、数据分冷热。对于大主播、热数据，用户直接访问边缘cdn，再回源l2，最后回源源站，如图路径2；对于冷数据，直接回源l2，如图路径3；对于极冷数据，直接回源源站，如图路径1；

cdn缓存策略
待补充

这些cdn节点的部署结构是怎么样的呢？
在上面的回源路径中，各级回源是通过公网进行的。公网环境不受控制，耗时慢、收费较贵。现在将各个cdn节点使用专线打通，并与源站打通，那么回源就可以走专线。
在这里插入图片描述

4.2.3、CDN有啥用

总结一下，cdn作为分布式的多级缓存系统，缓存有的作用它也有，再结合它具有网络的属性，特点如下：

缓存数据，避免源站压力过大
多个cdn节点提供巨大流量支持，预防DDoS攻击
距离用户近，提供更快的响应
节点间使用专线，网络性能好，如果是公司自建cdn，自己的app可以走cdn网络，质量好
作为透明代理（当你了解了cdn的原理后，它就不透明了 O(∩_∩)O ），可以对资源修改、鉴权等等

4.2.4、其它CDN

上面说的cdn是我们认为的通常意义上的cdn，其实cdn还有多种类型

pcdn
pcdn全程叫做p2p cdn，大白话解释原理就是，把你家的电视机、电视盒子、智能音箱、路由器、自建边缘节点、淘汰服务器…当做cdn节点，用来提供内容分发服务。（当然也不要着急关闭相关功能，这就像献血一样，互利互惠）
为啥要这样做呢？这些设备走的是家庭宽带，价格便宜（企业宽带贵），利用起来不仅能够满足业务，还可以达到降本的目的。
大致流程如下图所示：
在这里插入图片描述

mcdn
全称叫做microCDN，原理是宽带用户在接入网络之前，需要进行拨号，从运营商那边获得授权的能够上网的入口，这个宽带拨号过程一般和运营商的区域拨号服务器进行交互完成。现在有这样一部分资源，可以认为是在运营商的拨号服务器上直接进行拨号，然后会得到公网IP地址，这样这些IP地址就有可能被用来提供给网络服务，特别是视频CDN服务。由于拨号宽带的特征，一个拨号只有固定的网络带宽，一般是50/100Mbps上下行的带宽，所以运营商拨号服务器一般可以同时拨号100路以上，能够汇聚5-10Gbps的互联网带宽。
mCDN系统就是利用这些网络资源搭建的CDN系统，这些分散在全国各地各运营商更加琐碎的服务资源有如下一些特征：更加廉价的带宽流量成本；不是常规大型机房，网络环境复杂、质量和稳定性存在不确定因素。

商业cdn
专业的cdn厂商

自建cdn
自建cdn的目的往往是为了降低成本、与商业cdn议价时有底气、有更多的业务灵活度…
在架构上，自建与商业基本都是一样

廉价cdn

4.2.5 视频app如何使用CDN

公司为了保证观看视频质量、降低成本、拥有自主cdn产权等等目的，会混合使用多种cdn。这时客户端会请求一个调度接口，由后端根据用户ip、视频清晰度、热度、cdn优先级等等信息，返回一个最合理的cdn地址。

4.3、服务端

请添加图片描述
一个请求到达机房后，还要经过若干步骤才能够到达服务端：

硬件slb：例如NetScaler、F5等。性能非常好，一般只需少量物理机组成高可用，即可支撑起所有流量
软件slb：硬件slb高性能带来的缺点是灵活性不足，几乎不能根据业务扩展，所以硬件slb下面会挂载着多台软件slb。大公司一般会基于开源技术开发自己的软件slb，例如nginx、Appactive等。它的作用除了最基本的流量转发，还有多机房切流、WAF、全局限流、服务发现等等
API网关：软件slb的灵活性体现在全公司层面，对于每个单独的业务线缺少更加灵活的支持，API网关就填补了这个空白。API网关一般支持协议转换、降级、熔断、重试、限流、mock、流量重放、更加丰富的流量转发策略…这里有一些详细的介绍Shepherd、alibaba
BFF网关：一般一个业务线对应一个BFF网关，主要作用是编排下游服务、收敛流量入口，统一管理、统一鉴权/转换、代码功能复用
后端服务：-