# 概述

高级软件体系结构课程作业是找一个现成的软件来分析架构，需要：

1. 制作相应 PPT 并且演讲

2. 写 6000-8000 字小论文来描述该软件架构

本着面向搜索引擎 的分析方法，成功找到如下案例：

分析一个大型软件体系结构 —— 爱奇艺

link:https://blog.csdn.net/Wsk1234567/article/details/102697419

开始针对相应内容进行资料收集和整理，并恶补相关知识和内容。

其他相关资料

爱奇艺微服务标准技术架构实践 https://cloud.tencent.com/developer/article/1796751?from=article.detail.1896541

爱奇艺的架构到底有多牛逼？https://zhuanlan.zhihu.com/p/146119034

爱奇艺移动业务后台系统架构设计 https://wenku.baidu.com/view/7e25fc4fb42acfc789eb172ded630b1c58ee9b63.html

爱奇艺推荐系统架构与实践 https://blog.csdn.net/zhlei12345/article/details/78795946

AI 时代的生产资料从何而来？—— 打造千万级 QPS 规模的实时大数据收集体系 https://www.iqiyi.com/common/20190125/bcea429424475c33.html

干货 | 爱奇艺 PC Web 新框架实践 https://www.iqiyi.com/common/20190306/961ac0e7fa538fa0.html

爱奇艺的工作流调度系统 ——Gear https://www.iqiyi.com/common/20190125/10a243e8905694cc.html

爱奇艺 RND 框架技术探索 —— 架构与实现 https://blog.51cto.com/u_15282126/2948577

# 爱奇艺架构分析

# 简介

爱奇艺是一款集视频、直播、社区等多种服务于一体的软件产品，其为用户提供电影、电视剧、综艺、动漫、娱乐热点资讯等内容，视频播放清晰流畅，操作界面简单友好。

本文着重对爱奇艺在不同层级的框架进行分析和阐述，总体大概分为三部分：

  1. 总体架构概览

  2. 客户端应用架构分析

  3. 服务架构分析

# 架构概述

# 主要的软件结构风格：

  1. 具有很明显的 C/S 风格，以及三层 C/S 风格：

    c/s

    爱奇艺将系统客户端和服务端，同时分为三个主要层级：表示层、功能层和数据层。其中表示层负责用户接口（User Interface）部分，用于检查用户的输入和操作，并显示应用的输出数据；功能层是整个系统实现的本体，它具体的业务逻辑实现，如用户检索数据的处理，视频流的编码和发送等；数据层是负责数据库和媒体数据存储部分，该层作为系统的持久层，负责对数据库的读写及管理。

    ​ C／S 结构作为目前比较成熟的技术，虽然有着能处理大量数据、响应速度快和交互性强等优点，但其在很多方面依然有所局限性。比如，每台客户端都需要安装相应的客户端程序，无法实现快速部署的安装和配置，缺乏通用性。此外，其结构的方案需要有针对性的开发，且变更不够灵活，难以维护和管理。

  2. B/S 浏览器 / 服务器体系结构风格

    层次模型

    在 Web UI 以及移动 App 中具有 B/S 的风格，相比 C/S 架构， B/S 架构是有更广的应用范围，在处理模式上大大简化了客户端，用户只需安装浏览器即可，而将应用逻辑集中在服务器和中间件上，可以提高数据处理性能。在软件的通用性上，B/S 架构的客户端具有更好的通用性，对应用环境的依赖性较小，同时因为客户端使用浏览器，在开发维护上更加便利，可以减少系统开发和维护的成本。

  3. 基于层次消息总线的体系结构风格

    ​ image-20221014091808066

    消息总线（Message Queue，MQ），是一种跨进程的通信机制，用于在上下游之间传递消息。MQ 是一种常见的上下游 “逻辑解耦 + 物理解耦” 的消息通信服务，消息发送上游只需要依赖 MQ，逻辑上和物理上都不用依赖其他服务。

    ​ …

  4. …

  5. …

# 应用架构

简要介绍几种爱奇艺用到的技术架构和框架

# PC 端

RND框架相关…

参考 https://blog.51cto.com/u_15282126/2948577

# 概述

RND，全称 React Node Desktop，起源于 RN 在爱奇艺 PC 端的实现，采用 React JS framework +Node.js runtime + native UI engine 架构，目前 RND 已经在爱奇艺 PC 客户端大量应用。RND 无缝地将 Native 部分与 Java Script 开发的 UI 模块融合到一起，用户从体验上无法感知哪部分是 C++ 开发，哪部分是 Java Script 开发的。RND 的应用有效降低了开发难度和成本，提高了开发效率，同时也为产品迭代提供了更加多样化的解决方案。

基于 RND 的频道页：

爱奇艺RND框架技术探索——架构与实现_软件研发

融合 Native 播放器的 RND 页面：

爱奇艺RND框架技术探索——架构与实现_软件研发_02

# 技术选型与架构设计

整体应用的分层结构如图。RN 最核心的部件是 JavaScript 引擎。对于 UI 部分的实现，在移动端，RN 对接的都是原生的 UI 组件，桌面平台，爱奇艺也有自己的 UI 渲染引擎 ——Lyra,Lyra 是一套十分优秀的异步渲染引擎，目前支持 Windows 和 MAC OS 两个平台，RND 所有的 UI 渲染都是以 Lyra 作为基础，并且 RND 还整合了 Yoga 布局系统来实现 UI 组件的 flex 布局计算。

在 Native 能力方面，因 RND 集成了 Node 运行时，这得基于 RND 的 JS 开发者拥有了 Node 强大的 Native 基础能力，开发者可以按需引入 Node 模块来扩展应用的 Native 能力；本地缓存方面，RND 采用了高性能的本地存储系统 LevelDB，LevelDB 是一款性能十分优秀的 Nosql 数据库，支持 key/value 形式的数据存储；在调试方面，RND 除了支持 Chrome 外，还支持 VSCode、Electron 调试，方便开发者按自己的需求进行调试。

爱奇艺RND框架技术探索——架构与实现_软件研发_04

# 相关分析 (以下为分层风格的优缺点，需要针对当前项目修改)

在分层风格中，系统将划分为一个层次结构。

每一层都具有高度的内聚性，包含抽象程度一致的各种构件，支持信息隐藏。

分层有助于将复杂系统划分为独立的模块，从而简化程序的设计和实现。

通过分解，可以将系统功能划分为一些具有明确定义的层，较高层是面对特定问题，较低层具有一般性。

每层都为上层提供服务，同时又利用了下层的逻辑功能。在分层体系结构中，每一层只对相邻层可见。层次之间的连接件是协议和过程调用。用以实现各层之间的交互。

优点：

  1. 设计者可以将系统分解为一个增量的步骤序列从而完成复杂的业务逻辑。
  2. 每一层之多和相邻的上下两层进行交互。
  3. 只要给相邻层提供相同的接口。

缺点：

  1. 并非所有系统都能够按照层次来进行划分。
  2. 很难找到一种合适和正确的层次划分方法。
  3. 在传输数据是，需要经过多个层次。
  4. 多层结构难以调试。

# Web 端

PC Web框架…

参考 https://www.iqiyi.com/common/20190306/961ac0e7fa538fa0.html

# 概述

爱奇艺主站 PC Web 前端框架 Uniqy 是一款十分轻量面向用户站点的前端框架，其实现页面渲染的架构图如下：

img

具有明显的管道过滤器风格。

优点：

  1. 简单性。
  2. 支持复用。
  3. 系统具有可扩展性和可进化型。
  4. 系统并发性（每个过滤器可以独立运行，不同子任务可以并行执行，提高效率）。
  5. 便于系统分析。

缺点 (此部分内容可删除)：

  1. 系统处理工程是批处理方式。
  2. 设计交互式应用系统时，具有较长的响应时间。
  3. 由于没有通用的数据传输标准，因此每个过滤器都需要解析输入数据和合成数据。
  4. 难以进行错误处理。

这种风格存在明显的问题，就是从启动到最终相应需要的时间较长，反应到用户体验上，就是启动白屏，页面迟迟不能加载完全。

因此，爱奇艺的解决方案是：使用同步与异步二次渲染相结合的方式。也就是说在服务端按需直出页面，而在客户端浏览器上使用框架进行二次的组件渲染，完成最终的视图构建。这里有一张图可以描述主站 PC Web 页面渲染的基本模式：

img

​ 一些比较重要的组件，优先在服务端渲染好，而一些搜索权重并不是很高的组件，使用异步渲染的方式。所以，当用户使用高版本浏览器访问爱奇首页、播放页等页面时，看到的第一屏内容是由服务端渲染出的，而等页面 js 完全下载好开始执行时，包括第一屏的组件会被二次编译，绑定 js 中定义好的方法、指令或过滤器等，与异步组件一并渲染。

img

img

​ 可以明显看到第一屏下半部分是空白的，因为非首屏部分采用的是异步渲染，这些组件只有在到达可视区域时才会被编译，然后被插回页面，完成视图更新。

最终，页面的初始加载时间大大降低。

# 服务架构

大数据收集体系 …

参考 https://www.iqiyi.com/common/20190125/bcea429424475c33.html

内容跟预期不符，不写了，开摆

服务标准技术架构…

参考 https://cloud.tencent.com/developer/article/1796751?from=article.detail.1896541

https://zhuanlan.zhihu.com/p/345552079

https://www.cnblogs.com/kenshinobiy/p/11113124.html

为数以亿计的用户提供服务的爱奇艺技术产品团队，为了适应业务的快速迭代和创新，并支撑海量的用户请求，进行了微服务架构的改造。

# 微服务架构简介

微服务架构区别于传统的单体软件架构，是一种为了适应当前互联网后台服务的「三高需求：高并发、高性能、高可用」而产生的的软件架构。

# 单体式应用程序

与微服务相对的另一个概念是传统的单体式应用程序 (Monolithic application)，单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性，也就是相互依赖彼此，很难拆分和扩容。

单体应用程序的优点

  • 开发简洁，功能都在单个程序内部，便于软件设计和开发规划。
  • 容易部署，程序单一不存在分布式集群的复杂部署环境，降低了部署难度。
  • 容易测试，没有各种复杂的服务调用关系，都是内部调用方便测试。

单体应用程序的缺点

  • 业务逻辑简单。
  • 软件维护和系统迭代困难。
  • 不易扩展，扩展整个应用程序可能导致额外的资源浪费

img

由于单体式应用程序就像一个大型容器一样，里面放置了许多服务，且他们都是密不可分的，这导致应用程序在扩展时必须以「应用程序」为单位。

当里面有个业务模块负载过高时，并不能够单独扩展该服务，必须扩展整个应用程序，这可能导致额外的资源浪费。

此外，单体式应用程序由于服务之间的紧密度、相依性过高，这将导致测试、升级有所困难，且开发曲线有可能会在后期大幅度地上升，令开发不易。相较之下「微服务架构」能够解决这个问题。

# 微服务

微服务 (Microservices) 就是一些协同工作小而自治的服务。

2014 年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等组件实现 。

# 微服务架构

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的

微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

** 概念：** 把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

微服务优点

  • 隔离性，一个服务不可用不会导致另一个服务也瘫痪，因为各个服务是相互独立和自治的系统。
  • 可扩展性，可以只对那些影响性能的服务做扩展升级
  • 简化部署，各个服务的部署是独立的
  • 易优化，单个服务的代码量不会很大

爱奇艺团队在微服务化的过程中存在：

·部分基础设施存在重复建设，在资源浪费的同时稳定性也不易保证；

·由于使用的技术架构和 SDK 不统一，最佳实践难以快速推广；

·技术架构不统一导致在东西向流量中大量引入了业务自行维护的网关，使得链路加长，影响排障效率和响应延时。

为解决上述问题，爱奇艺中间件团队推出了爱奇艺的微服务标准架构：

img

写不动了

。。。。。。

推荐系统架构 …
工作流调度系统…

# 提问与回答

Q1: 在大量用户用户使用C/S架构对服务器进行访问的时候，要如何保证能为庞大数量的用户提供流媒体服务而不会因为服务器载荷量过大而宕机呢？

A1：首先，在用户和服务器进行通信的过程中，因为服务端架构是分布式的微服务，所以计算资源池可以实现容器化和弹性扩容，以保证峰值请求能被满足。其次，用户的一个服务请求可以被分解为多个子请求，分别提交给不同的服务器进行处理，使得用户能够快速得到服务器的最终响应。但是即便如此，服务器也无法承担成千上万的流媒体带宽，因此，会使用 p2p 和 cdn 加速方案，利用用户的闲置带宽和中转服务器加速，来实现大量的流媒体传输服务。

Q2：爱奇艺的web端、PC端、移动端有哪些区别？

A2：从系统架构上看，web 端是基于 B/S 架构，PC 端、移动端是基于 C/S 架构。B/S 架构是浏览器与服务器间的通信，传输协议为 http/https，因此 web 端的安全性比较低；而 C/S 架构通常采用公司内部协议，因此 PC 端、移动端安全性高于 web 端。web 端从浏览器登录就是最新版本，而 PC 端和移动端会收到更新提示或需授权自动更新权限。web 端需兼容各种版本浏览器，PC 端需兼容各种操作系统，移动端需兼容各种操作系统、手机型号及版本。

Q3：爱奇艺业务如此庞杂，是如何应对由于业务快速迭代和创新而带来的应用重构和修改的呢？

A3：爱奇艺使用了微服务的架构，将不同的业务功能写成一个个子系统，每个子系统就是一个微服务，每个子系统遵从 “高内聚，低耦合” 的原则，每个子系统独立运行，这样每个子系统可以专注于自己的业务逻辑的编写，不用管整个系统的其他部分，只要规范好接口，微服务之间可以通过 http 协议进行通信，这样就方便了整个应用的扩展和修改，当有业务需求需要变动时，只要修改涉及到的微服务或者增加新的微服务即可。

Q4：爱奇艺的三层C/S 结构有什么优点？

三层架构是⼀种严格分层⽅法，即数据访问层只能被业务逻辑层访问，业务逻辑层只能被页⾯显⽰层访问，⽤户通过表⽰层将请求传送给业务逻辑层，业务逻辑层完成相关业务规则和逻辑，并通过数据访问层访问数据库获得数据，然后按照相反的顺序依次返回将数据显⽰在页⾯显⽰层。在三层架构之间，通过派⽣类去实现接⼝；通过调⽤派⽣类的⽅法和属性，三层之间实现相互调⽤。三层设计的优势为：⾼内聚低耦合、标准定义、逻辑复⽤、分散关注。⾼内聚低耦合降低了层与层之间的依耐性，提⾼了复⽤性。同时，明确了开发⼈员的分⼯，提⾼了软件项⽬的开发速度。

问题补充

在爱奇艺部署 服务器集群时面临的问题？
在部署 Nacos 服务时，爱奇艺考虑了服务部署架构方面的高可用性。目前爱奇艺的 Nacos 服务是一个大集群，实例分布在多个不同的可用区中，在每个可用区内部，用户会申请不同的 VIP，最终的内网域名是绑定在这些 VIP 上。另外其底层所使用的 MySQL 也采用了多机房部署。这样的架构可以避免单个 Nacos 实例或者单机房故障造成整个 Nacos 服务的不可用。以下是一些可能的故障场景的模拟：
1. 单个 Nacos 实例故障：利用 Load Balancer 集群提供的健康检查能力自动从 VIP 中摘除；
2. 某个 VIP 集群故障：利用客户端重试机制解决；
3. 单个 AZ 故障：利用客户端重试机制解决；
4.MySQL 集群故障：MySQL 与注册发现过程无关，不受影响；
5. 整个 Nacos 服务故障：客户端兜底机制，如服务实例缓存等。

爱奇艺有如此庞杂的业务，是如何对复杂的工作流进行管理的？

爱奇艺团队提出了名为 Gear 的工作流调度系统，Gear 系统通过作业管理、依赖管理、重试机制对工作流完成了高效率、高可靠性的管理。通过 Gear，爱奇艺实现了复杂工作流的高效率调度。作业管理：Gear 提供了 Web 界面和 Java SDK 来管理用户的作业，包括启动、暂停、恢复、停止、重跑、补跑等，也支持查看（或获取）运行状态、进度和日志等。
定时启动：与 Linux 的 crontab 类似，用户通过定义 cron 表达式来描述定时启动的逻辑。
依赖管理：包含两方面含义，一是定时任务启动前的依赖检测（如 HDFS 文件或目录、HTTP URI 等），二是任务之间的依赖关系管理，以 DAG（Directed Acyclic Graph，有向无环图）的形式展现。
报警机制：包括工作流的失败报警，以及 SLA 报警（规定时间内未启动、规定时间内未结束、运行时间过长）。
重试机制：包括单个任务失败后的自动重试，可配置最大重试次数和重试间隔。
高可用性：Gear 的每一个环节，包括工作流引擎、后台服务、任务执行机，都提供了高可用方案，确保用户的任务执行不受单点故障影响。

爱奇艺实时大数据体系未来有几个发展方向
1 在存储和计算两个方向上探索流批一体的应用场景，围绕 Flink 引擎 2 构建流批一体的数仓体系，打通实时流灌入数据湖（Iceberg）的数据通路，依托实时更新的数据湖体系，支持更多更丰富的 OLAP 业务场景

3ETL->ELT：引导实时数仓的架构变迁，将实时数据构建环节中的部分计算转移到实时数仓下游的 OLAP 体系和数据湖中，依托 OLAP 引擎的强大性能来满足用户的过滤 / 聚合等需求，将实时数仓的链路做短，提升实时数据的质量和稳定性、降低延迟。

4、BI+AI：打通实时数据生产 -> 实时特征生产 -> 在线模型训练 -> 线上推理的链路，方便用户一站式的实现从数据准备到 AI 算法模型训练的相关工作。