Snapchat 在青少年中广为人知。 如果你不知道它是如何工作的,你可能已经超过 25 岁了。 Snapchat 是最受欢迎的社交媒体应用程序之一,它为儿童和青少年提供了他们想要的东西:一种分享普通事件的简单方法,同时也让它们看起来很酷。
与记录和发布您所做的一切的 Facebook 和 Twitter 不同,Snapchat 使用的消息应该会消失(看看它们是如何消失的)。
有很多关于 Snapchat 的内容,如果您是开发人员,它甚至更多。 因此,这篇文章将为您提供 Snapchat 的高级视图 系统设计 以及更多的见解。
介绍
Snapchat 是一家总部位于美国的 社交网络 让用户立即连接、共享图像等的应用程序。
- 消息和图像(或快照)有 24 小时的时间限制。 鼓励人们分组分享他们的故事。
- Snap Map 允许用户在地图上查看他们的朋友所在的位置。
- 回忆会提醒用户一年后他们保存或分享的照片。
- Snapchat 非常受年轻一代,尤其是青少年的欢迎。 该应用有 319 亿活跃用户,每天发送 5.4 亿张快照。
重要的设计术语
单体架构 – 独立于其他应用程序运行的单层应用程序称为单体(monolithic architecture)。 单体架构旨在执行和处理完成任务所需的所有活动。 该应用程序从头到尾执行所有功能。
微服务 – 它与巨石截然相反。 微服务 是一种将应用程序组织为服务集合的架构方法。 这些服务用于控制应用程序的许多方面。 顾客下单,服务员拿走并交付,厨师准备。 在此示例中,每个组件的功能独立且独立于其他组件; 没有人确切知道其他人在做什么,也没有人可以访问相同的信息。
JSON:它是一种基于文本的格式,可用于显示 JavaScript 对象、文字、数组和数据。 这种基于文本的格式旨在易于读写,并且易于软件消化。 JSON 通常用于在服务器和在线应用程序之间传输数据和信息。
编曲配置:自动化许多操作的技术称为编排。 这些工作包括计算机系统和软件配置、协调和管理。
代理:代理充当寻找资源的客户端和提供资源的服务器之间的中间人。
网孔:服务网格是一种软件架构模式,它在基础设施层中增加了一层,以允许通过代理在服务之间进行受监管的、可观察的和安全的通信。
高级设计
单体问题
Snapchat 起源于基于 Google App Engine 的基于云的单体应用。 然而,随着该程序越来越受欢迎并获得更多用户和数据,可扩展性成为一个问题。
此外,由于巨石内部有巨大的爆炸半径,系统范围内的干扰更有可能发生。 Snapchat 的问题之一被定义为“公地悲剧”,其中功能竞争资源访问权; 功能在应用程序启动时加载,允许某些功能加载更快,但其他功能加载速度较慢。
工程师还从开发的角度寻求其组件的清晰可见性、分离和所有权,以便服务可以灵活高效。
转型
随着 Snapchat 的扩张,该公司意识到它需要将其单一的基础设施分解成更小、更高效的部分。 为了减少延迟,该组织决定开发基于微服务的设计。
为了实现这些目标,Snapchat 选择使用可扩展的 NoSQL 数据库服务 Amazon DynamoDB 更新其软件。 由于其努力,该公司能够将延迟中值减少 20%。
该应用程序被该公司重写为许多较小的应用程序。 Snapchat 始于众多应用程序,包括相机、聊天、记忆、图片编辑、内容消费和地图。 尽管将这些程序集成到一个单一的单体中对消费者来说很方便,但它在保持良好性能方面提出了一个严重的技术问题。
为了重写,公司制定了许多基本规则。 不要预加载; 每个功能都应该是自己的应用程序,并且应该很快。 Snapchat 在几个地方停止了修改以启用重写,这使其成为一项严格的技术任务。
附加功能集成
Snapchat 的相机应用程序具有镜头、滤镜、bitmoji 以及添加增强现实动画等功能。 Snapchat 的聊天应用程序还允许用户存储照片、保存谈话、添加表情符号等等。
除其他外,Snapchat 的地图允许您监控好友,如果他们愿意的话。 记忆、照片编辑和内容消费都是具有独特功能的独立 Snapchat 应用程序。
记忆允许您存储或修改照片或视频以供以后使用,以及上传或发送它们。 用户还可以利用图片编辑来剪切电影、添加文本、添加贴纸等。
Snapchat 的外部内容消费是指它根据一系列参数向用户展示的内容。
微服务
该程序当时广泛依赖 JSON 来执行网络查询。 然而,解析 JSON 既耗时又低效。 Snapchat 使用集中式网络管理 API 来掩盖 JSON 的使用作为解决此问题的实现细节。
微服务引入了应用程序状态管理、服务通信和故障管理的挑战。 Snapchat 使用 Temporal 等开源技术来克服编排困难,以构建强大且可靠的系统。
因此,该组织决定使用服务网格设计模式。 Snapchat 使用 Envoy(另一个充当代理的开源工具)来实现这种模式。 Envoy 通过基础设施管理服务流量,让开发人员能够了解潜在的困难。
Snapchat 在服务网格中创建了一个名为 Switchboard 的内部应用程序。 Switchboard 用作 Snap 服务的控制面板,允许用户转移流量、管理服务依赖项(一种允许根据其他服务的条件管理一个服务的功能)和排空区域。
为了简化服务中潜在配置的复杂性,使用了 Switchboard,而不是暴露整个 Envoy API。 得益于服务网格,Snap 为其微服务提供了一个通用的内部和区域网络。
同一区域内的服务可以在不使用公共互联网的情况下相互连接,并且没有外部网络流量可以与内部网络部分通信。
出于安全原因,只有网关被授权将自己暴露在互联网上。 例如,API 网关可能很容易充当前门,处理来自客户端/用户的请求并将它们与网络一起路由。
网络和 API 网关
来自 Snapchat 客户端的所有查询都来自 API Gateway。 它使用相同的 Envoy 映像并连接到与我们的内部微服务相同的控制平面。 我们的控制平面允许我们启用自定义 Envoy 过滤器。
Snapchat 的身份验证系统以及我们的速率限制和减载技术均由这些过滤器处理。 Envoy 在过滤链完成后使用 Service Mesh 将请求路由到相关的微服务。
结论
Snapchat 的 API 网关将外部流量路由到应用程序的许多功能。 用户修改配置状态的请求由服务器管理,然后 提供数据 并将信息返回给应用程序的众多服务。
总体而言,Snapchat 目前的设计可以与在单个操作系统上运行的多个程序进行比较,在这种情况下是 Snapchat 应用程序。 我非常努力地为您提供 Snapchat 系统设计的高级概述。 希望你觉得它有用。
发表评论