13 Real World Case Studies

Netflix's Tech Stack

这篇文章是基于许多Netflix工程博客和开源项目的研究。如果你发现任何不准确的地方，请随时告诉我们。

移动和网页：Netflix采用Swift和Kotlin构建原生移动应用。对于其网页应用，它使用React。
前端/服务器通信：Netflix使用GraphQL。
后端服务：Netflix依赖ZUUL、Eureka、Spring Boot框架等技术。
数据库：Netflix使用EV缓存、Cassandra、CockroachDB等数据库。
消息/流媒体：Netflix使用Apache Kafka和Fink进行消息传递和流媒体传输。
视频存储：Netflix使用S3和Open Connect进行视频存储。
数据处理：Netflix使用Flink和Spark进行数据处理，然后使用Tableau进行可视化。Redshift用于处理结构化数据仓库信息。
CI/CD：Netflix使用JIRA、Confluence、PagerDuty、Jenkins、Gradle、Chaos Monkey、Spinnaker、Atlas等多种工具进行CI/CD流程。

Twitter Architecture 2022

Yes, this is the real Twitter architecture. It is posted by Elon Musk and redrawn by us for better readability.

Evolution of Airbnb’s microservice architecture over the past 15 years

Airbnb’s microservice architecture went through 3 main stages.

单体（2008 - 2017）

Airbnb最初是一个简单的房东和客人市场。这是在一个Ruby on Rails应用程序中构建的 - 单体。

挑战是什么？

混乱的团队所有权 + 无主代码
部署缓慢

微服务（2017 - 2020）

微服务旨在解决这些挑战。在微服务架构中，关键服务包括：

数据获取服务
业务逻辑数据服务
写入工作流服务
UI聚合服务
每个服务都有一个拥有团队

挑战是什么？

数百个服务和依赖关系对人类来说难以管理。

微 + 宏服务（2020 - 现在）

这就是Airbnb现在正在做的。微服务和宏服务的混合模型专注于API的统一。

Monorepo vs. Microrepo.

Monorepo并不是新概念；Linux和Windows都是使用Monorepo创建的。为了提高可扩展性和构建速度，Google开发了其内部的专用工具链，以更快地扩展它，并制定了严格的编码质量标准以保持一致性。

亚马逊和Netflix是微服务理念的主要倡导者。这种方法自然地将服务代码分离到单独的仓库中。它扩展得更快，但可能会导致后期的治理痛点。

在Monorepo中，每个服务都是一个文件夹，每个文件夹都有一个BUILD配置和OWNERS权限控制。每个服务成员负责自己的文件夹。

另一方面，在Microrepo中，每个服务负责自己的仓库，构建配置和权限通常为整个仓库设置。

在Monorepo中，无论你的业务如何，依赖关系在整个代码库中共享，所以当有版本升级时，每个代码库都会升级他们的版本。

在Microrepo中，依赖关系在每个仓库内控制。企业根据自己的时间表选择何时升级版本。

Monorepo有标准的签入流程。Google的代码审查过程以设定高标准而闻名，确保Monorepo的一致质量标准，无论业务如何。

Microrepo可以设定自己的标准，也可以通过整合最佳实践采用共享标准。它可以更快地为业务扩展，但代码质量可能会有所不同。Google工程师构建了Bazel，Meta构建了Buck。还有其他开源工具可用，包括Nx、Lerna等。

多年来，Microrepo有了更多的支持工具，包括Java的Maven和Gradle，NodeJS的NPM，C/C++的CMake等。

How will you design the Stack Overflow website?

如果你的答案是本地服务器和单体（在下图底部），你可能会在面试中失败，但这实际上就是它的构建方式！

人们认为它应该是什么样子

面试官可能期望的是图片顶部的样子。

微服务用于将系统分解为小的组件。
每个服务都有自己的数据库。大量使用缓存。
服务是分片的。
服务通过消息队列异步地相互通信。
服务使用带有CQRS的事件源实现。
展示对分布式系统的知识，如最终一致性、CAP定理等。

它实际上是什么

Stack Overflow仅用9台本地Web服务器就服务于所有流量，而且它是单体的！它有自己的服务器，不在云上运行。

这与我们当今的所有流行观念相反。

Why did Amazon Prime Video monitoring move from serverless to monolithic? How can it save 90% cost?

The diagram below shows the architecture comparison before and after the migration.

什么是亚马逊Prime Video监控服务？

Prime Video服务需要监控数千个实时流的质量。监控工具会自动实时分析流，并识别质量问题，如块损坏、视频冻结和同步问题。这对客户满意度来说是一个重要的过程。

有三个步骤：媒体转换器、缺陷检测器和实时通知。

旧架构有什么问题？

旧架构基于Amazon Lambda，这对于快速构建服务是有好处的。然而，在大规模运行架构时，它并不具有成本效益。两个最昂贵的操作是：

编排工作流 - AWS步骤函数按状态转换向用户收费，而编排每秒执行多次状态转换。
分布式组件之间的数据传递 - 中间数据存储在Amazon S3中，以便下一阶段可以下载。当数据量很大时，下载可能会很昂贵。

单体架构节省了90%的成本

单体架构旨在解决成本问题。仍然有3个组件，但媒体转换器和缺陷检测器部署在同一个进程中，节省了通过网络传递数据的成本。令人惊讶的是，这种部署架构变更的方法导致了90%的成本节省！

这是一个有趣且独特的案例研究，因为微服务已经成为科技行业的一种首选和时尚选择。很高兴看到我们正在进行更多关于架构演进的讨论，并进行更多关于其优缺点的诚实讨论。将组件分解为分布式微服务是有成本的。

亚马逊领导层对此有何评论？

亚马逊首席技术官Werner Vogels：“构建可演进的软件系统是一种策略，而不是一种宗教。带着开放的心态重新审视你的架构是必须的。”

前亚马逊可持续发展副总裁Adrian Cockcroft：“Prime Video团队遵循了我称之为无服务器优先的路径……我不提倡仅使用无服务器。”

How does Disney Hotstar capture 5 Billion Emojis during a tournament?

客户端通过标准HTTP请求发送表情符号。你可以把Golang服务看作是一个典型的Web服务器。选择Golang是因为它很好地支持并发。Golang中的线程很轻量级。
由于写入量非常大，所以使用Kafka（消息队列）作为缓冲区。
表情符号数据由一个名为Spark的流处理服务进行聚合。它每2秒聚合一次数据，这是可配置的。根据间隔需要进行权衡。较短的间隔意味着表情符号更快地传递给其他客户端，但这也意味着需要更多的计算资源。
聚合后的数据被写入另一个Kafka。
PubSub消费者从Kafka拉取聚合后的表情符号数据。
表情符号通过PubSub基础设施实时传递给其他客户端。PubSub基础设施很有趣。Hotstar考虑了以下协议：Socketio、NATS、MQTT和gRPC，并最终选择了MQTT。

LinkedIn采用了类似的设计，每秒流式传输一百万个赞。

How Discord Stores Trillions Of Messages

The diagram below shows the evolution of message storage at Discord:

MongoDB ➡️ Cassandra ➡️ ScyllaDB

2015年，Discord的第一个版本是在单个MongoDB副本之上构建的。大约在2015年11月，MongoDB存储了1亿条消息，RAM无法再容纳数据和索引。延迟变得不可预测。消息存储需要迁移到另一个数据库。选择了Cassandra。

2017年，Discord有12个Cassandra节点，存储了数十亿条消息。

在2022年初，它有177个节点，存储了数万亿条消息。此时，延迟变得不可预测，维护操作变得过于昂贵而无法运行。

问题的原因有几个：

Cassandra使用LSM树作为内部数据结构。读取比写入更昂贵。在有成百上千用户的服务器上，可能会有许多并发读取，导致热点。
维护集群，如压缩SSTables，会影响性能。
垃圾收集暂停会导致显著的延迟峰值 ScyllaDB是一个用C++编写的与Cassandra兼容的数据库。Discord重新设计了其架构，拥有一个整体式API，一个用Rust编写的数据服务，以及基于ScyllaDB的存储。

ScyllaDB的p99读取延迟为15ms，而Cassandra为40-125ms。p99写入延迟为5ms，而Cassandra为5-70ms。

How do video live streamings work on YouTube, TikTok live, or Twitch?

直播与普通流媒体的不同之处在于，视频内容是通过互联网实时发送的，通常只有几秒钟的延迟。

下面的图表解释了幕后发生了什么，使这成为可能。

第一步：原始视频数据由麦克风和摄像头捕获。数据被发送到服务器端。
第二步：视频数据被压缩和编码。例如，压缩算法将背景和其他视频元素分开。压缩后，视频被编码为H.264等标准。经过这一步骤后，视频数据的大小要小得多。
第三步：编码后的数据被分割成较小的片段，通常长度为几秒钟，因此下载或流式传输所需的时间要少得多。
第四步：分段数据被发送到流媒体服务器。流媒体服务器需要支持不同的设备和网络条件。这被称为“自适应比特率流媒体”。这意味着我们需要在第二步和第三步中生成不同比特率的多个文件。
第五步：实时流媒体数据被推送到CDN（内容分发网络）支持的边缘服务器。数百万观众可以从附近的边缘服务器观看视频。CDN显著降低了数据传输延迟。
第六步：观众的设备解码和解压缩视频数据，并在视频播放器中播放视频。
第七步和第八步：如果需要存储视频以供回放，编码后的数据将被发送到存储服务器，观众稍后可以从中请求回放。

实时流媒体的标准协议包括：

RTMP（实时消息传输协议）：最初由Macromedia开发，用于在Flash播放器和服务器之间传输数据。现在它被用于通过互联网传输视频数据。请注意，像Skype这样的视频会议应用程序使用RTC（实时通信）协议以降低延迟。
HLS（HTTP实时流媒体）：它需要H.264或H.265编码。苹果设备只接受HLS格式。
DASH（动态自适应流媒体）：DASH不支持苹果设备。
HLS和DASH都支持自适应比特率流媒体。

目录