当前位置: 首页 > article >正文

【后端开发】系统设计101——Devops,Git与CICD,云服务与云原生,Linux,安全性,案例研究(30张图详解)

【后端开发】系统设计101——Devops,Git与CICD,云服务与云原生,Linux,安全性,案例研究(30张图详解)

文章目录

    • 1、Devops
      • DevOps与SRE与平台工程的区别是什么?
      • 什么是k8s(Kubernetes)?
      • Docker与Kubernetes。我们应该使用哪个?
      • Docker是如何工作的?
      • 开发者生产力工具
    • 2、Git与CICD
      • Git命令的工作原理
      • Git是如何工作的?
      • Git合并与Git变基
      • 简单介绍CI/CD流程
      • Netflix技术栈(CI/CD流程)
    • 3、云服务与云原生
      • 各种云服务的好用备忘单(2023版)
      • 什么是云原生?
    • 4、Linux
      • 解释Linux文件系统
      • 你应该知道的18个最常用的Linux命令
    • 5、安全性
      • HTTPS是如何工作的?(非对称传秘钥,对称传数据)
      • 用简单的术语解释 Oauth2.0(第三方wx/qq登录)
      • 认证机制的四种主要形式(SSH,Oauth,SSL,Cert)
      • Session、cookie、JWT、token、SSO和OAuth 2.0 - 它们是什么?
      • 如何安全地在数据库中存储密码以及如何验证密码?
      • 用通俗易懂的语言解释JSON Web Token(JWT)
      • Google Authenticator(或其他类型的两步验证器)是如何工作的?
    • 6、常见架构(9张)
      • Netflix的技术栈
      • Twitter 2022年的架构
      • Airbnb过去15年中微服务架构的演变
      • Monorepo vs. Microrepo
      • 你会如何设计Stack Overflow网站?
      • 为什么Amazon Prime Video的监控从无服务器转向单体应用?如何节省90%的成本?
      • Disney Hotstar如何在锦标赛期间捕捉50亿个表情符号?
      • Discord如何存储数万亿条消息
      • YouTube、TikTok Live或Twitch上的视频直播是如何工作的?

用图像和简单语言解释复杂系统。
参考资料: 1, 2, 3

文章目录
1、Devops
DevOps与SRE与平台工程的区别是什么?
什么是k8s(Kubernetes)?
Docker与Kubernetes。我们应该使用哪个?
Docker是如何工作的?
开发者生产力工具
2、Git与CICD
Git命令的工作原理
Git是如何工作的?
Git合并与Git变基
简单介绍CI/CD流程
Netflix技术栈(CI/CD流程)
3、云服务与云原生
各种云服务的好用备忘单(2023版)
什么是云原生?
4、Linux
解释Linux文件系统
你应该知道的18个最常用的Linux命令
5、安全性
HTTPS是如何工作的?(非对称传秘钥,对称传数据)
用简单的术语解释 Oauth2.0(第三方wx/qq登录)
认证机制的四种主要形式(SSH,Oauth,SSL,Cert)
Session、cookie、JWT、token、SSO和OAuth 2.0 - 它们是什么?
如何安全地在数据库中存储密码以及如何验证密码?
用通俗易懂的语言解释JSON Web Token(JWT)
Google Authenticator(或其他类型的两步验证器)是如何工作的?
6、常见架构(9张)
Netflix的技术栈
Twitter 2022年的架构
Airbnb过去15年中微服务架构的演变
Monorepo vs. Microrepo
你会如何设计Stack Overflow网站?
为什么Amazon Prime Video的监控从无服务器转向单体应用?如何节省90%的成本?
Disney Hotstar如何在锦标赛期间捕捉50亿个表情符号?
Discord如何存储数万亿条消息
YouTube、TikTok Live或Twitch上的视频直播是如何工作的?

1、Devops

DevOps与SRE与平台工程的区别是什么?

DevOps、SRE和平台工程的概念是在不同的时间出现的,并由各个个人和组织进行了发展。

  • DevOps作为一个概念于2009年由Patrick Debois和Andrew Shafer在敏捷大会上提出。他们试图通过促进协作文化和共同负责整个软件开发生命周期来弥合软件开发和运营之间的差距。
  • SRE或站点可靠性工程是由Google在2000年代初引入的,旨在解决管理大规模复杂系统的运营挑战。Google开发了SRE实践和工具,例如Borg集群管理系统和Monarch监控系统,以提高其服务的可靠性和效率。
  • 平台工程是一个更为新近的概念,建立在SRE工程的基础之上。平台工程的确切起源不太清楚,但它通常被理解为DevOps和SRE实践的扩展,重点是提供一个全面支持整个业务视角的产品开发平台。

值得注意的是,尽管这些概念在不同的时间出现,但它们都与改进软件开发和运营中的协作、自动化和效率的广泛趋势相关。

在这里插入图片描述

什么是k8s(Kubernetes)?

K8s是一个容器编排系统,用于容器的部署和管理。它的设计受到了Google内部系统Borg的影响。

  • 一个k8s集群
    由一组运行容器化应用程序的工作节点(称为节点)组成。每个集群至少有一个工作节点。

  • 工作节点托管Pod
    这些Pod是应用程序工作负载的组成部分。
    控制平面管理集群中的工作节点和Pod。
    在生产环境中,控制平面通常跨多台计算机运行,集群通常运行多个节点,提供容错和高可用性。

  • 控制平面组件

  • API服务器:
    API服务器与k8s集群中的所有组件进行通信。所有pod的操作都通过与API服务器通信执行。

  • 调度器:
    调度器观察Pod的工作负载,并将负载分配给新创建的Pod。

  • 控制器管理器
    控制器管理器运行控制器,包括Node Controller,Job Controller,EndpointSlice Controller和ServiceAccount Controller等。

  • Etcd
    etcd是一个键值存储,用作Kubernetes的后备存储器,用于存储所有集群数据。

  • 节点 Pod
    Pod是一组容器,是k8s管理的最小单位。Pod具有应用于Pod中每个容器的单个IP地址。

  • Kubelet
    在集群中的每个节点上运行的代理。它确保容器在Pod中运行。

  • Kube Proxy
    Kube-proxy是一个网络代理,运行在集群中的每个节点上。它将从服务进入节点的流量路由到正确的容器。它将请求转发到正确的容器,以便执行工作。

在这里插入图片描述

Docker与Kubernetes。我们应该使用哪个?

什么是Docker?

  • Docker是一个开源平台,允许您在隔离的容器中打包、分发和运行应用程序。
  • 它专注于容器化,提供轻量级环境,封装应用程序及其依赖项。

什么是Kubernetes?

  • Kubernetes,通常称为K8s,是一个开源容器编排平台。
  • 它提供了一个框架,用于自动化部署、扩展和管理容器化应用程序跨节点的集群。

它们之间有什么不同?

  • Docker:Docker在单个操作系统主机上的单个容器级别操作。
    您必须手动管理每个主机,为多个相关容器设置网络、安全策略和存储可能会很复杂。
  • Kubernetes:Kubernetes在集群级别上运行。它管理多个容器化应用程序跨多个主机,提供自动化的任务,如负载平衡、扩展和确保应用程序的期望状态。
    简而言之,Docker专注于容器化和在单个主机上运行容器,而Kubernetes专门管理和编排容器在跨多个主机的集群中运行

在这里插入图片描述

Docker是如何工作的?

Docker的架构以及当我们运行 “docker build”、“docker pull” 和 “docker run” 时它是如何工作的。

Docker架构有三个组件:

  • Docker客户端
    Docker客户端与Docker守护进程通信。
  • Docker宿主机
    Docker守护进程监听Docker API请求,并管理Docker对象,如镜像、容器、网络和卷。
  • Docker注册表
    Docker注册表存储Docker镜像。Docker Hub是一个公共注册表,任何人都可以使用。

让我们以“docker run”命令为例。

  • Docker从注册表中拉取镜像。
  • Docker创建一个新的容器。
  • Docker为容器分配一个读写文件系统。
  • Docker创建一个网络接口,将容器连接到默认网络。
  • Docker启动容器。

在这里插入图片描述

开发者生产力工具

自动将代码转换为架构图?

  • 用Python代码绘制云系统架构。
  • 图表也可以在Jupyter笔记本中直接呈现。
  • 不需要设计工具。
  • 支持以下提供商:AWS、Azure、GCP、Kubernetes、阿里云、Oracle Cloud等。

可视化JSON文件

  • 嵌套的JSON文件很难阅读。
  • JsonCrack从JSON文件生成图形图表,使其易于阅读。
  • 此外,生成的图表可以下载为图像。

在这里插入图片描述

2、Git与CICD

Git命令的工作原理

首先,必须确定我们的代码存储在哪里。

  • 通常认为只有两个位置 - 一个是在像Github这样的远程服务器上,另一个是在我们的本地计算机上。然而,这并不完全准确。

Git在我们的计算机上维护了三个本地存储。这意味着我们的代码可以在四个位置找到:

  • 工作目录:我们编辑文件的地方,此时会跟暂存区的文件做diff,git add以后丢到暂存区。
  • 暂存区:一个临时位置,文件被保存在这里以供下一次提交使用。commit以后丢到本地仓库。
  • 本地仓库:包含已提交的代码。
  • 远程仓库:存储代码的远程服务器。

大多数Git命令主要在这四个位置之间移动文件

在这里插入图片描述

Git是如何工作的?

Git是一种分布式版本控制系统。

每个开发者都维护着主仓库的本地副本,并对其进行编辑和提交。

由于操作不涉及远程仓库,因此提交非常快速。

如果远程仓库崩溃,可以从本地仓库恢复文件。

在这里插入图片描述

Git合并与Git变基

当我们将一个Git分支的更改合并到另一个分支时,可以使用“git merge”或“git rebase”。
下面的图表展示了这两个命令的工作方式。

Git合并

  • 这将在主分支中创建一个新的提交G’。G’将主分支和功能分支的历史记录联系起来
  • Git合并是非破坏性的。主分支和功能分支都不会被更改。

Git变基

  • Git变基将功能分支的历史记录移动到主分支的头部。它为功能分支中的每个提交创建新的提交E’、F’和G’。
  • 使用变基的好处是它具有线性的提交历史记录。
  • 如果不遵循“Git变基的黄金法则”,它可能会带来风险。

Git变基的黄金法则

  • 永远不要在公共分支上使用它!

在这里插入图片描述

简单介绍CI/CD流程

第一部分 - 带有 CI/CD 的 SDLC

  • 软件开发生命周期(SDLC)包括几个关键阶段:开发,测试,部署和维护。 CI / CD自动化并集成了这些阶段,以实现更快速和可靠的发布。
  • 当代码被推送到git存储库时,它会触发自动构建和测试过程。运行端到端(e2e)测试用例以验证代码。如果测试通过,则代码可以自动部署到staging / production。如果发现问题,则将代码发送回开发以修复错误。此自动化为开发人员提供了快速反馈,并减少了生产中错误的风险

第二部分 - CI和CD之间的区别

  • 持续集成(CI - Continuous Integration)自动化构建,测试和合并过程。每当提交代码以尽早检测集成问题时,它都会运行测试。这鼓励频繁的代码提交和快速反馈。
  • 持续交付(CD- Continuous Delivery)自动化发布流程,如基础架构更改和部署。它确保软件可以通过自动化工作流程可靠地随时发布。 CD还可以自动化生产部署之前需要的手动测试和批准步骤。

第三部分 - CI/CD 管道
典型的 CI/CD 管道具有几个连接的阶段:

  • 开发人员提交代码更改以进行源控制
  • CI服务器检测更改并触发构建
  • 编译代码并进行测试(单元测试,集成测试)
  • 测试结果报告给开发人员
  • 成功后,工件将部署到staging环境
  • 在发布之前可能会在staging上进行进一步测试
  • CD系统将批准的更改部署到生产中

在这里插入图片描述

Netflix技术栈(CI/CD流程)

计划:Netflix工程团队使用JIRA进行计划,使用Confluence进行文档编写。

编码:Java是后端服务的主要编程语言,而其他语言则用于不同的用例。

构建:Gradle主要用于构建,而Gradle插件则用于支持各种用例。

打包:将包和依赖项打包成Amazon Machine Image(AMI)进行发布。

测试:测试强调生产文化对构建混沌工具的关注。

部署:Netflix使用其自行构建的Spinnaker进行金丝雀发布部署。

监控:监控指标集中在Atlas中,使用Kayenta检测异常。

事件报告:事件按优先级分派,使用PagerDuty进行事件处理。

在这里插入图片描述

3、云服务与云原生

各种云服务的好用备忘单(2023版)

在这里插入图片描述

什么是云原生?

下面是一张图表,展示了自1980年代以来体系结构和流程的演变
组织可以使用云原生技术在公共、私有和混合云上构建和运行可扩展的应用程序
这意味着应用程序被设计为利用云特性,因此它们对负载具有弹性并且易于扩展。

云原生包括四个方面

  • 开发流程:这已经从瀑布流发展到敏捷开发到DevOps
  • 应用程序架构:架构已经从单片式发展到微服务。每个服务都被设计为小巧,适应云容器中有限的资源。
  • 部署和打包:应用程序曾经部署在物理服务器上。然后在2000年左右,那些不敏感于延迟的应用程序通常部署在虚拟服务器上。使用云原生应用程序,它们被打包成Docker镜像并部署在容器中
  • 应用程序基础设施:应用程序大规模部署在云基础设施上,而不是自托管服务器上。

在这里插入图片描述

4、Linux

解释Linux文件系统

Linux文件系统曾经类似于一个无组织的城镇,个人可以在任何地方建造自己的房屋。然而,1994年引入了文件系统层次结构标准(FHS),以规范Linux文件系统。

通过实施像FHS这样的标准,软件可以确保在各种Linux发行版中具有一致的布局。然而,并不是所有的Linux发行版都严格遵循这个标准。它们经常包含自己独特的元素或迎合特定的需求。

要熟练掌握这个标准,你可以从探索开始。利用“cd”命令进行导航和“ls”命令列出目录内容。想象文件系统就像一棵树,从根目录(/)开始。随着时间的推移,它将变得自然而然,使你成为一名熟练的Linux管理员。

在这里插入图片描述

你应该知道的18个最常用的Linux命令

Linux命令是与操作系统交互的指令。它们有助于管理文件、目录、系统进程和系统的许多其他方面。为了有效地导航和维护基于Linux的系统,你需要熟悉这些命令。

以下图表显示了常用的Linux命令:

  • ls - 列出文件和目录
  • cd - 更改当前目录
  • mkdir - 创建新目录
  • rm - 删除文件或目录
  • cp - 复制文件或目录
  • mv - 移动或重命名文件或目录
  • chmod - 更改文件或目录权限
  • grep - 在文件中搜索模式
  • find - 搜索文件和目录
  • tar - 操作tarball归档文件
  • vi - 使用文本编辑器编辑文件
  • cat - 显示文件内容
  • top - 显示进程和资源使用情况
  • ps - 显示进程信息
  • kill - 通过发送信号终止进程
  • du - 估算文件空间使用量
  • ifconfig - 配置网络接口
  • ping - 在主机之间测试网络连接

在这里插入图片描述

5、安全性

HTTPS是如何工作的?(非对称传秘钥,对称传数据)

超文本传输安全协议(HTTPS)是超文本传输协议(HTTP)的扩展。HTTPS使用传输层安全协议(TLS)传输加密数据。如果数据在在线上被劫持,劫持者只能获得二进制代码。

数据是如何加密和解密的

  • 步骤1 - 客户端(浏览器)和服务器建立TCP连接。
  • 步骤2 - 客户端向服务器发送“客户端hello”消息。该消息包含一组必要的加密算法(密码套件)和它支持的最新TLS版本。
    服务器响应一个“服务器hello”,以使浏览器知道它是否支持这些算法和TLS版本。
    然后,服务器向客户端发送SSL证书。该证书包含公钥、主机名、过期日期等。客户端验证证书。
  • 步骤3 - 在验证SSL证书后,客户端生成一个会话密钥,并使用公钥对其进行加密。服务器接收加密的会话密钥,并使用私钥对其进行解密。
  • 步骤4 - 现在,客户端和服务器都持有相同的会话密钥(对称加密),加密数据在一个安全的双向通道中传输

为什么HTTPS在数据传输期间要切换到对称加密? 有两个主要原因:

  • 安全性:非对称加密只能单向进行。这意味着如果服务器试图将加密数据发送回客户端,任何人都可以使用公钥解密数据。(同时任何人都可以用服务器的公钥伪造返回数据)
  • 服务器资源:非对称加密增加了相当多的数学开销。它不适用于长时间会话中的数据传输。

在这里插入图片描述

用简单的术语解释 Oauth2.0(第三方wx/qq登录)

OAuth 2.0 是一个强大且安全的框架,可以让不同的应用程序代表用户在不共享敏感凭证的情况下安全地互相交互

OAuth 涉及的实体有用户、服务器和身份提供者(IDP)。

OAuth Token 可以做什么?

  • 当您使用 OAuth 时,您会获得一个代表您身份和权限的 OAuth Token。该 Token 可以做一些重要的事情:
  • 单点登录(SSO):使用 OAuth Token,您可以只使用一个登录即可登录多个服务或应用程序,让您的生活更加轻松和安全。
  • 系统间授权:OAuth Token 允许您在各个系统之间共享您的授权或访问权限,因此您不必在各处单独登录。
  • 访问用户资料:具有 OAuth Token 的应用程序可以访问您允许的某些用户资料的部分内容,但不会查看全部。
  • 请记住,OAuth 2.0 的目的是在不同的应用程序和服务之间使您的在线体验无缝、无忧,并保护您和您的数据的安全。

1

在这里插入图片描述

认证机制的四种主要形式(SSH,Oauth,SSL,Cert)

  • SSH 密钥: 用于安全地访问远程系统和服务器的加密密钥
  • OAuth Tokens : 提供对第三方应用程序上用户数据的有限访问权限的令牌
  • SSL 证书: 数字证书确保服务器和客户端之间的通信安全和加密
  • Credentials凭证: 用户身份验证信息用于验证并授予对各种系统和服务的访问权限

在这里插入图片描述

Session、cookie、JWT、token、SSO和OAuth 2.0 - 它们是什么?

这些术语都与用户身份管理相关。
当您登录网站时,您声明了自己的身份(识别)。您的身份将得到验证(认证),并被授予必要的权限(授权)。
过去提出了许多解决方案,这个列表还在不断增长。

从简单到复杂,这是我对用户身份管理的理解:

  • WWW-Authenticate是最基本的方法。浏览器会要求您输入用户名和密码。由于无法控制登录生命周期,它现在很少使用。
  • Session-Cookie可以更细致地控制登录生命周期。服务器维护会话存储,浏览器保留会话ID。Cookie通常只适用于浏览器,不适用于移动应用程序
  • 为了解决兼容性问题,可以使用Token。客户端将Token发送到服务器,服务器验证Token。缺点是Token需要加密和解密,可能会耗费时间。
  • JWT是表示Token的标准方式。这些信息可以得到验证和信任,因为它们是数字签名的。由于JWT包含签名,因此不需要在服务器端保存会话信息。
  • 通过使用SSO(单点登录),您只需登录一次即可登录多个网站。它使用CAS(中央认证服务)来维护跨站点信息
  • 通过使用OAuth 2.0,您可以授权一个网站访问另一个网站上的您的信息

在这里插入图片描述

如何安全地在数据库中存储密码以及如何验证密码?

不应该做的事情

  • 存储明文密码不是一个好主意,因为任何有内部访问权限的人都可以看到它们。
  • 直接存储密码哈希不足够安全,因为它容易受到预计算攻击,如彩虹表攻击
  • 为了减轻预计算攻击,我们对密码进行加盐处理。

什么是盐?

  • 根据OWASP指南,“盐是在哈希过程中作为唯一随机生成的字符串添加到每个密码中的一部分”

如何存储密码和盐?

  • 哈希结果对于每个密码都是唯一的。
  • 可以使用以下格式将密码存储在数据库中:hash(password + salt)。

如何验证密码?

  • 要验证密码,可以进行以下过程:
  • 客户端输入密码。
  • 系统从数据库中获取相应的盐。
  • 系统将盐附加到密码上并进行哈希处理。我们称哈希值为H1。
  • 系统比较H1和H2,其中H2是存储在数据库中的哈希值。如果它们相同,则密码有效。

在这里插入图片描述

用通俗易懂的语言解释JSON Web Token(JWT)

想象一下,你有一个特殊的盒子,叫做JWT。在这个盒子里,有三个部分:头部、载荷和签名。

  • 头部就像盒子外面的标签。
    它告诉我们盒子的类型和如何保证安全。
    它通常采用JSON格式编写,JSON是一种使用花括号{ }和冒号:来组织信息的方式。

  • 载荷就像你想要发送的实际信息或数据。
    它可以是你的姓名、年龄或任何你想要分享的数据。
    它也以JSON格式编写,因此易于理解和处理。

  • 现在,签名是使JWT安全的关键。
    它就像一个特殊的印章,只有发送者知道如何创建。
    签名是使用秘密代码创建的,有点像密码。
    这个签名确保没有人可以在发送者不知道的情况下篡改JWT的内容。

当你想要将JWT发送到服务器时,你将头部、载荷和签名放在盒子里。
然后你将它发送到服务器。
服务器可以轻松地读取头部和载荷,以了解你是谁以及你想要做什么。

在这里插入图片描述

Google Authenticator(或其他类型的两步验证器)是如何工作的?

Google Authenticator通常用于启用2因素身份验证时登录我们的帐户。它如何保证安全?
Google Authenticator是一种基于软件的验证器,实现了2FA两步验证服务。以下图表提供了详细信息。

这里涉及到两个阶段:

  • 阶段1 - 用户启用谷歌两步验证。
  • 阶段2 - 用户使用验证器进行登录等操作。

阶段1

  • 步骤1和2:Bob打开网页启用两步验证。前端请求一个秘密密钥。认证服务为Bob生成秘密密钥并将其存储在数据库中。
  • 步骤3:认证服务向前端返回一个URI。URI由密钥发行者、用户名和秘密密钥组成。URI以QR码的形式显示在网页上。
  • 步骤4:然后Bob使用Google Authenticator扫描生成的QR码。秘密密钥存储在验证器中。

阶段2

  • 步骤1和2:Bob想要使用谷歌两步验证登录网站。为此,他需要密码。每30秒,Google Authenticator使用TOTP(基于时间的一次性密码)算法生成一个6位数字密码
    Bob使用密码进入网站。
  • 步骤3和4:前端将Bob输入的密码发送到后端进行身份验证。认证服务从数据库中读取秘密密钥,并使用与客户端相同的TOTP算法生成一个6位数字密码
  • 步骤5:认证服务比较客户端和服务器生成的两个密码,并将比较结果返回给前端。只有两个密码匹配时,Bob才能继续登录过程

这种身份验证机制安全吗?其他人能否获取秘密密钥?

  • 我们需要确保使用HTTPS传输秘密密钥。
  • 验证器客户端和数据库存储秘密密钥,我们需要确保秘密密钥已加密。

黑客能否猜测6位数字密码?

  • 不行。密码有6位数字,因此生成的密码有100万个潜在组合。
  • 此外,密码每30秒变一次。如果黑客想在30秒内猜测密码,他们需要每秒输入30,000个组合

在这里插入图片描述

6、常见架构(9张)

Netflix的技术栈

移动端和Web端:Netflix采用Swift和Kotlin构建本地移动应用程序。对于Web应用程序,它使用React。

前端/服务器通信:Netflix使用GraphQL。

后端服务:Netflix依赖于ZUUL、Eureka、Spring Boot框架和其他技术。

数据库:Netflix利用EV Cache、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 2022年的架构

是的,这是真正的 Twitter 架构。它由 Elon Musk 发布,我们重新绘制以提高可读性。

在这里插入图片描述

Airbnb过去15年中微服务架构的演变

Airbnb的微服务架构经历了三个主要阶段。

单体架构(2008-2017)

  • Airbnb最初只是一个简单的房东和客人市场。这是在Ruby on Rails应用程序中构建的 - 单体架构。
  • 面临的挑战是什么?
    团队所有权混淆+未拥有的代码
    部署缓慢

微服务(2017-2020)

  • 微服务旨在解决这些挑战。
  • 在微服务架构中,关键服务包括:
    数据获取服务
    业务逻辑数据服务
    写工作流服务
    UI聚合服务
    每个服务都有一个拥有团队
  • 面临的挑战是什么?
    数百个服务和依赖项对人类来说很难管理。

微服务+宏服务(2020-现在)

  • 这是Airbnb目前正在研究的。微服务和宏服务混合模型的重点是API的统一。

在这里插入图片描述

Monorepo vs. Microrepo

微服务仓库Microrepo 和 宏服务仓库Monorepo

Monorepo 和 Microrepo 是两种不同的代码库管理方法。
哪个是最好的?为什么不同的公司选择不同的选项?

对比

  • Monorepo并不是新的概念,Linux和Windows都是使用Monorepo创建的
    为了提高可扩展性和构建速度,谷歌开发了内部专用工具链以更快地扩展,同时采用了严格的编码质量标准来保持一致性。
    亚马逊和Netflix是微服务哲学的主要代表。这种方法自然地将服务代码分成不同的存储库。它可以更快地扩展,但后期可能会出现治理痛点。

  • 在Monorepo中,每个服务都是一个文件夹,每个文件夹都有BUILD配置和OWNERS权限控制。每个服务成员都负责自己的文件夹。
    另一方面,在Microrepo中,每个服务都负责自己的存储库,构建配置和权限通常设置为整个存储库。

  • 在Monorepo中,无论您的业务如何,依赖关系都是在整个代码库中共享的,因此,当有版本升级时,每个代码库都会升级其版本。
    在Microrepo中,依赖关系是在每个存储库中控制的。业务可以根据自己的时间表选择何时升级版本。

  • Monorepo有一个标准的签入流程。谷歌的代码审查流程因设定了高标准而闻名,确保了Monorepo的一致质量标准,无论业务如何。
    Microrepo可以自己设置标准,也可以采用最佳实践并采用共享标准。它可以更快地为业务扩展,但代码质量可能会有所不同。

  • 谷歌工程师构建了Bazel,Meta构建了Buck。还有其他开源工具可用,包括Nix、Lerna和其他工具。
    多年来,Microrepo支持的工具越来越多,包括Java的Maven和Gradle、NodeJS的NPM以及C/C++的CMake等。

在这里插入图片描述

你会如何设计Stack Overflow网站?

基于现场服务器和单体架构(在下面的图像中),这就是实际构建的方式!

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

  • 上图的顶部部分。
  • 微服务用于将系统分解为小组件。
  • 每个服务都有自己的数据库。大量使用缓存。
  • 服务被分片。
  • 服务通过消息队列异步交互。
  • 服务使用事件溯源和CQRS实现。
  • 展示分布式系统方面的知识,例如最终一致性、CAP定理等。

实际情况

  • Stack Overflow仅使用9个现场Web服务器处理所有流量,而且它是一个单体架构!它有自己的服务器,不运行在云上
  • 这与我们当今的所有流行信仰相反。

在这里插入图片描述

为什么Amazon Prime Video的监控从无服务器转向单体应用?如何节省90%的成本?

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

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

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

旧架构存在什么问题?

  • 旧架构基于Amazon Lambda构建,用于快速构建服务。
  • 然而,在高规模运行架构时,它并不具备成本效益。
  • 最昂贵的两个操作是:
    1、编排工作流程 - AWS步骤函数按状态转换收费,编排每秒执行多个状态转换。
    2、分布式组件之间的数据传递 - 中间数据存储在Amazon S3中,以便下一个阶段可以下载。当数据量很大时,下载可能很昂贵。

单体架构节省90%的成本

  • 单体架构旨在解决成本问题。
    仍然有三个组件,但媒体转换器和缺陷检测器部署在同一进程中,节省了通过网络传递数据的成本。
    令人惊讶的是,这种部署架构变更方法导致了90%的成本节约!
  • 这是一个有趣且独特的案例研究,因为微服务已成为技术行业的首选和时尚选择。
    很高兴看到我们正在更多地讨论如何发展架构,并更加诚实地讨论其优缺点。将组件分解为分布式微服务会带来成本。

亚马逊领袖对此有何看法?

  • 亚马逊首席技术官Werner Vogels: “构建可发展的软件系统是一种策略,而不是一种宗教。以开放的心态重新审视您的架构是必须的。”
  • 前亚马逊可持续性副总裁Adrian Cockcroft: “Prime Video团队已经遵循了我称之为Serverless First的路径…我不赞成Serverless Only。”

迁移前后的架构比较:

在这里插入图片描述

Disney Hotstar如何在锦标赛期间捕捉50亿个表情符号?

  • 1、客户端通过标准HTTP请求发送表情符号。您可以将Golang服务视为典型的Web服务器。选择Golang是因为它很好地支持并发。Golang中的线程是轻量级的。

  • 2、由于写入量非常高,使用Kafka(消息队列)作为缓冲区。

  • 3、表情符号数据由名为Spark的流处理服务聚合。它每2秒聚合一次数据,这是可配置的。根据间隔需要进行权衡。较短的间隔意味着表情符号将更快地传递给其他客户端,但这也意味着需要更多的计算资源。

  • 4、聚合数据被写入另一个Kafka。

  • 5、PubSub消费者从Kafka中拉取聚合的表情符号数据。

  • 6、表情符号通过PubSub基础架构实时传递给其他客户端。PubSub基础架构很有趣。Hotstar考虑了以下协议:Socketio、NATS、MQTT和gRPC,并选择了MQTT。

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

在这里插入图片描述

Discord如何存储数万亿条消息

下面的图表显示了Discord消息存储的演变过程:

MongoDB => Cassandra => ScyllaDB

  • 2015年,Discord的第一个版本建立在单个MongoDB副本之上。
    到了2015年11月,MongoDB存储了1亿条消息,内存无法再容纳数据和索引。延迟变得不可预测,消息存储需要迁移到另一个数据库。他们选择了Cassandra。
  • 到了2017年,Discord有12个Cassandra节点,存储着数十亿条消息
  • 在2022年初,它拥有了177个节点,存储着数万亿条消息。此时,延迟变得不可预测,维护操作的成本也变得太高。

Cassandra对比ScyllaDB(替换的原因):

  • Cassandra使用LSM树作为内部数据结构。读取比写入更昂贵。在有数百个用户的服务器上可能会有许多并发读取,导致热点问题
    维护群集,如压缩SSTables,会影响性能。 垃圾回收暂停会导致显著的延迟峰值。
  • ScyllaDB是一个用C++编写的与Cassandra兼容的数据库。
    Discord重新设计了其架构,拥有一个单体式API,一个用Rust编写的数据服务和基于ScyllaDB的存储
    在ScyllaDB中,p99读取延迟为15毫秒,而在Cassandra中为40-125毫秒。p99写入延迟为5毫秒,而在Cassandra中为5-70毫秒。.

在这里插入图片描述

YouTube、TikTok Live或Twitch上的视频直播是如何工作的?

直播流与常规流媒体不同,因为视频内容是通过互联网实时发送的,通常延迟只有几秒钟。

下面的图示解释了实现这一点的背后发生的事情。

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

直播流的标准协议包括:

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

在这里插入图片描述


http://www.kler.cn/a/535237.html

相关文章:

  • 02vue3实战-----项目目录详解
  • Postgresql的三种备份方式_postgresql备份
  • GitHub 使用教程:从入门到进阶
  • 本地化部署 AI 的第一步,认识和使用 ollama
  • 逻辑回归原理
  • Ollama教程:轻松上手本地大语言模型部署
  • 下标为3的倍数
  • 解锁C#数据校验:从基础到实战的进阶之路
  • 日志模块自定义@SkipLogAspect注解跳过切面
  • 三格电子-单串口服务器说明
  • [paddle] 矩阵乘法
  • 高性能音频分析仪,音频分析器、国产音频分析仪
  • QUIC协议详解
  • ES6- 代码编程风格(let、字符串、解构赋值)
  • 所遇皆温柔,佛系过生活
  • pycharm集成通义灵码应用
  • 【PyTorch】解决Boolean value of Tensor with more than one value is ambiguous报错
  • leetcode——组合总和(回溯算法详细讲解)
  • DNN(深度神经网络)近似 Lyapunov 函数
  • 解锁反序列化漏洞:从原理到防护的安全指南
  • 【OpenCV插值算法比较】
  • 给排水 笔记
  • MapReduce是什么?
  • Swan 表达式 - 数组相关操作
  • 【Prometheus】如何通过golang生成prometheus格式数据
  • 使用 MMCM 的 I/O 时序 ZHOLD/BUF_IN 补偿