新手上路
3小时前
主楼
原理
- 大型服务经验教训 - Eric Brewer, 加州大学伯克利分校 & Google
- 构建大型分布式系统的设计、经验教训和建议 - Jeff Dean, Google
- 如何设计良好的 API 及其重要性 - Joshua Bloch, 卡内基梅隆大学 & Google
- 关于效率、可靠性和扩展性 - AWS 资深副总裁 James Hamilton
- 混沌工程原理
- 在混沌中寻找秩序
- 十二要素应用
- Clean Architecture
- High Cohesion and Low Coupling
- Monoliths and Microservices
- CAP Theorem and Trade-offs
- CP 数据库和 AP 数据库
- 无状态与有状态的可扩展性
- 纵向扩展与横向扩展:隐藏成本
- ACID 与 BASE
- 阻塞/非阻塞与同步/异步
- 数据库的性能和可扩展性
- 数据库隔离级别及其对性能和可扩展性的影响
- 大型集群中数据丢失的概率
- 适用于高度可扩展解决方案的数据访问:使用 SQL、NoSQL 和多语言持久化)
- SQL 与 NoSQL
- SQL 与 NoSQL - Salesforce 的经验教训
- NoSQL 数据库:调查与决策指导
- 分片如何工作
- 一致性哈希
- 一致性哈希:算法权衡
- 不要被哈希技巧欺骗
- Netflix 的统一一致性哈希
- 最终一致性 - 亚马逊 CTO 韦纳·沃格尔斯
- 缓存是王道
- 反缓存
- 理解延迟
- 每个程序员都应该知道的延迟数字
- 服务可用性的微积分
- 扩展 Web 应用程序时的架构问题:瓶颈、数据库、CPU、IO
- 常见瓶颈
- 分布式事务之外的生存之道
- 在各种层级上依赖软件可靠地重定向流量
- 故意破坏事物
- 避免过度设计
- 可扩展性最差实践
- 使用 Solid 技术 - 不要重新发明轮子 - 保持简单!
- 通过分布式复杂性实现简单性
- 为什么过度复用是有害的
- 性能是一项特性
- 将性能纳入你的工作流程
- 服务器端渲染相较于客户端渲染的优势
- 自动化与抽象:来自 Facebook 的教训
- AWS 的做与不做
- (UI)设计无法扩展 - Spotify 设计总监 Stanley Wood
- Linux 性能
- 构建快速且弹性的 Web 应用程序 - Ilya Grigorik
- 接受部分失败,最小化服务损失
- 弹性设计
- 自我修复设计
- 面向扩展设计
- 面向演进设计
- 从错误中学习
可扩展性
- 微服务与编排
- Uber 的领域导向微服务架构
- SoundCloud 的服务架构(分为三部分:领域网关、增值服务、BFF)
- Riot Games 的容器(分为八部分)
- Pinterest 的容器化
- Netflix 容器使用的演进
- Uber 的 MySQL 容器化
- Spotify 的微服务测试
- 在 Treehouse 中在生产环境中使用 Docker
- SoundCloud 中的微服务
- 在 Stripe 上可靠地操作 Kubernetes
- Trivago 使用 Istio 进行跨集群流量镜像
- 纽约时报的农业规模 Kubernetes(3 部分)
- BBC 的纳米服务
- 彭博的 PowerfulSeal:Kubernetes 集群的测试工具
- Netflix 的 Conductor:微服务编排器
- Shopify 上驱动超过 10 万家在线商店的 Docker 容器
- Medium 的微服务架构
- Betabrand 从裸金属到 Kubernetes 的转型
- Tinder 的 Kubernetes 实践
- 在 Quora 采用 Kubernetes
- 在 Pinterest 构建 Kubernetes 平台
- Nubank 的微服务
- Mercari 的微服务中的支付交易管理
- Snap 的 Service Mesh
- eBay 的 GRIT:微服务间分布式事务协议
- Palantir 的 Rubix:Kubernetes
- Uber 的 CRISP:微服务架构关键路径分析
- 分布式缓存
- EVCache:Netflix 的分布式内存缓存
- Netflix 的 EVCache 缓存预热基础设施
- Box 的 Memsniff:强大的 Memcache 流量分析器
- Etsy 使用一致性哈希和缓存涂抹的缓存机制
- Facebook 照片缓存的性能分析
- Facebook 缓存效率练习
- Trivago 的 tCache:可扩展的数据感知 Java 缓存
- Pycache:Quora 的进程内缓存
- Trivago 将 Memcached 内存使用减少 50%
- Yelp 的内部服务调用缓存
- Allegro 使用大数据估算缓存效率
- Zalando 的分布式缓存
- ClickHouse 的 S3 分布式缓存
- Netflix 的应用数据缓存从 RAM 到 SSD
- Skyscanner 的复制缓存权衡
- Yext 中的四叉树位置缓存
- Vimeo 中的视频元数据缓存
- Twitter 中的 Redis 扩展
- Slack 中的 Redis 工作队列扩展
- 将持久数据从 Redis 中迁移出 Github
- 在 Instagram 中使用 Redis 存储数十亿个简单键值对
- Trivago 中的 Redis
- Deliveroo 中的 Redis 存储优化
- Wattpad 的 Redis 内存优化
- Heroku 的 Redis 集群
- SoundCloud 解决远程构建缓存未命中(两部分)
- Flipkart 的评分与评论(两部分)
- eBay 的项预取缓存
- Wix 的跨区域缓存库
- Pinterest 提升分布式缓存性能和效率
- DoorDash 标准化和提升微服务缓存
- HTTP 缓存和 CDN
- Zynga Geo Proxy: 在 Zynga 减少移动游戏延迟
- Conde Nast 上的 Google AMP
- Deliveroo 在托管基础设施(CDN)上的 A/B 测试
- HAProxy 与 Kubernetes 用于 SoundCloud 面向用户的流量
- Bandaid:Dropbox 的服务代理
- Slack 中的服务工作者
- Spotify 的 CDN 服务
- 分布式锁
- Chubby:Google 松散耦合分布式系统中的锁服务
- Uber 的分布式锁
- GoSquared 使用 Redis 实现分布式锁
- Twitter 的 ZooKeeper
- Chartio 使用分布式锁消除重复查询
- 分布式跟踪、追踪和测量
- Twitter 的 Zipkin:分布式系统追踪
- 使用 Kubernetes Pod 元数据改进 SoundCloud 中的 Zipkin 跟踪
- Canopy:Facebook 的可扩展分布式跟踪与分析
- Pintrace:Pinterest 的分布式跟踪
- XCMetrics:Spotify 的 Xcode 构建指标一站式工具
- LinkedIn 的实时分布式追踪
- Shopify 的大规模服务基础设施追踪
- HelloFresh 的分布式追踪
- Pinterest 的分布式追踪数据分析
- Uber 的分布式追踪
- JVM Profiler:在 Uber 上追踪分布式 JVM 应用程序
- Dropbox 的数据检查
- Showmax 的分布式系统追踪
- osquery 在 Palantir 的企业应用
- Etsy 的 StatsD
- 分布式调度
- PagerDuty 的分布式任务调度(3 部分)
- 谷歌的 Cron 构建
- Quora 的分布式 Cron 架构
- Airbnb 的 Chronos:Cron 的替代品
- Nextdoor 的调度器
- Peloton:Uber 的统一资源调度器,用于多样化的集群工作负载
- Fenzo:Netflix 的 Apache Mesos 框架的开源调度器
- Airflow - 工作流编排
- Airflow at Airbnb
- Adyen 中的 Airflow
- Pandora 中的 Airflow
- Robinhood 中的 Airflow
- Lyft 中的 Airflow
- Drivy 中的 Airflow
- Grab 中的 Airflow
- Adobe 中的 Airflow
- Walmart 中审计 Airflow 作业运行
- MaaT:阿里巴巴基于 DAG 的分布式任务调度器
- boundary-layer:Etsy 的声明式 Airflow 工作流
- 分布式监控和告警
- Unicorn:eBay 的修复系统
- M3:优步的指标和监控平台
- Athena:Dropbox 的自动化构建健康管理系统
- Vortex:Dropbox 的监控服务器应用程序
- Nuage:领英的云管理服务
- Telltale: Netflix 应用监控
- ThirdEye: LinkedIn 监控平台
- Periskop: SoundCloud 异常监控服务
- Securitybot: Dropbox 分布式告警机器人
- 阿里巴巴监控系统
- Dailymotion 真实用户监控
- Uber 告警生态系统
- Airbnb 告警框架
- 在 SoundCloud 上基于服务级别目标(SLOs)进行警报
- Uber 的基于工作的预测工作流用于可观察性异常检测
- 在 HackerEarth 上使用 Graphite 和 Cabot 的监控和警报系统
- Twitter 的可观察性(2 部分)
- Slack 的分布式安全警报
- Bloomberg 的实时新闻警报
- LinkedIn 的数据管道监控系统
- Picnic 的监控和可观察性
- 分布式安全
- Aardvark and Repokid: AWS 最小权限分布式高速开发在 Netflix
- LISA:领英分布式防火墙
- Coinbase 在云端安全存储比特币的基础设施
- BinaryAlert:在 Airbnb 实现实时无服务器恶意软件检测
- 为 Segment 实现可扩展的 IAM 架构以安全访问 100 个 AWS 账户
- Indeed 的 OAuth 审计工具箱
- Yelp 的 Active Directory 密码黑名单
- Slack 中的大规模系统调用审计
- Yahoo 的 Athenz:基于角色的细粒度访问控制
- Slack 中的安全开发生命周期
- Kinvolk 的无特权容器构建
- Diffy:Netflix 云端数字取证差异引擎
- Netflix 在 AWS 中检测凭证泄露
- Spotify 可扩展的用户隐私
- Indeed 的 AVA:审计 Web 应用程序
- TTL as a Service:Yelp 中自动撤销过时权限
- Slack 的企业密钥管理
- Twitch 的可扩展性和认证
- Netflix 的边缘认证和令牌无关的身份传播
- 使用 Cilium 加强 Palantir 的 Kubernetes 基础设施
- 通过自动化改进 Lyft 的 Web 漏洞管理
- Drobbox 同步密码有效载荷时的时钟偏差
- 分布式消息、队列和事件流
- Cape:Dropbox 的流式事件处理框架
- Brooklin:LinkedIn 的近实时数据流分布式服务
- Samza:LinkedIn 的流处理系统,用于延迟洞察
- Bullet:Yahoo 用于流式数据的向前查询引擎
- EventHorizon: 用于在 Etsy 上观看事件流量的工具
- Qmessage: Quora 上的分布式异步任务队列
- Cherami: Uber 用于传输异步任务的消息队列系统
- Dynein: Airbnb 的分布式延迟任务队列系统
- Timestone:Netflix 用于非并行化工作负载的排队系统
- Riot Games 的消息服务
- Dropbox 的消息系统模型
- Zillow 通过事件日志进行生产环境调试
- Netflix 的跨平台应用内消息编排服务
- Netflix 的视频网关重构
- Netflix 为百万设备扩展推送消息
- Indeed 使用 RabbitMQ 延迟异步消息处理
- 在雅虎基准测试流计算引擎
- 通过 Protobuf 模式验证在 Deliveroo 提高流数据质量
- 在 Medium 扩展电子邮件基础设施
- Slack 的实时消息
- Nike 的流式事件数据库
- Udemy 的事件跟踪系统
- 事件驱动消息
- 阿里巴巴的领域驱动设计
- Weebly 的领域驱动设计
- Moonpig 的领域驱动设计
- 为 Netflix 下载扩展事件溯源
- Jet.com 的事件溯源扩展
- eBay 上的事件溯源(2 部分)
- FREE NOW 的事件溯源:进化视角
- Brainly 使用事件溯源和 CQRS 模式构建可扩展的内容流
- 发布-订阅消息
- Pulsar:Yahoo 上的大规模发布-订阅消息
- Wormhole:Facebook 上的发布-订阅系统
- MemQ:Pinterest 上的云原生发布-订阅系统
- Netflix 上的微服务中的发布-订阅
- Kafka - 消息代理
- LinkedIn 上的 Kafka
- Pinterest 上的 Kafka
- Trello 上的 Kafka
- Salesforce 中的 Kafka
- 纽约时报中的 Kafka
- Yelp 中的 Kafka
- Criteo 中的 Kafka
- Shopify 在 Kubernetes 上运行 Kafka
- Kafka on PaaSTA:在 Yelp 上运行 Kafka on Kubernetes(两篇)
- Yelp 在无停机时间的情况下迁移 Kafka 的 Zookeeper
- Uber 使用 Kafka 进行重新处理和死信队列
- Chaperone:在 Uber 端到端审计 Kafka
- 在 Dropbox 基础设施中查找 Kafka 吞吐量限制
- 沃尔玛的成本编排
- InfluxDB 和 Kafka 助力 Hulu 每秒扩展超过 100 万指标
- 在 PayPal 中扩展 Kafka 以支持数据增长
- 流数据去重
- Kafka 的精确一次语义
- Tapjoy 的实时去重
- 段落的去重
- Mail.Ru 的去重
- Mixpanel 的 Petabyte 级数据去重
- 分布式日志记录
- LinkedIn 上的日志记录
- Pinterest 的可扩展和可靠日志摄入
- Twitter 的高性能复制日志服务
- CERN 加速器上的 Spark 日志服务
- Quora 的日志记录和聚合
- Badoo 的守护进程日志收集与分析
- Palantir 的静态代码分析日志解析
- eBay 的集中式应用日志记录
- 在 Netflix 上以超大规模丰富 VPC 流量日志,提供网络洞察
- Yahoo 的分布式日志存储 BookKeeper
- Facebook 的日志分布式数据存储 LogDevice
- Yelp 的日志收集系统 LogFeeder
- DBLog:Netflix 中的通用变更数据捕获框架
- 分布式搜索
- Instagram 的搜索架构
- eBay 的搜索架构
- 在 Box 搜索架构
- 在 Coupang 搜索发现索引平台
- 在 Pinterest 通用搜索系统
- 在 eBay 通过提升 25% 改善搜索引擎效率
- 使用 Lucene 在 Palantir 索引和查询遥测日志
- TripAdvisor 的查询理解
- LinkedIn 的搜索联合架构(2018)
- Slack 的搜索
- DoorDash 内部的搜索引擎
- Twitter 搜索的稳定性和可扩展性
- Twitter 搜索服务(2014 年)
- Traveloka 的自动补全搜索(两部分)
- Canva 中的数据驱动自动更正系统
- Flipkart 中适应印度语音的搜索
- Dropbox 中的 Nautilus 搜索引擎
- LinkedIn 中的 Galene 搜索架构
- Manas:Pinterest 上的高性能定制化搜索系统
- Sherlock:Flipkart 的近实时搜索索引
- Nebula:Airbnb 用于构建搜索后端的存储平台
- ELK(Elasticsearch、Logstash、Kibana)堆栈
- 使用 ELK 在 Uber 实现实时预测
- 在 Envato 上构建可扩展的 ELK 堆栈
- Robinhood 上的 ELK
- 在 Uber 上扩展 Elasticsearch 集群
- eBay 的 Elasticsearch 性能调优实践
- 使用 Elasticsearch 插件提升性能(两部分)at Tinder
- Kickstarter 的 Elasticsearch
- Trivago 使用 Logstash 和 Google Protocol Buffers 进行日志解析
- 使用数据管道和 Elasticsearch 在 Yelp 进行快速订单搜索
- 将核心业务搜索迁移到 Elasticsearch 在 Yelp
- 在 Vinted 中拆分 Elasticsearch
- 在 Wattpad 中使用 Elasticsearch 进行自排名搜索
- Vulcanizer:一个在 Github 上操作的 Elasticsearch 的库
- 分布式存储
- 内存存储
- MemSQL 架构 - 快速(MVCC,InMem,LockFree,CodeGen)且熟悉(SQL)
- 在 Quora 优化 Memcached 效率
- 使用 MemSQL 在 Cisco UCS 上构建实时数据仓库
- Tapjoy 迁移到 MemSQL
- 迪士尼使用 MemSQL 和 Kinesis 实现实时洞察
- MemSQL 在 Pandora 上使用仪表板查询数百亿行数据
- 对象存储
- Uber 上的 HDFS 扩展
- Databricks 选择 S3 而非 HDFS 的原因
- Quantcast 上的 Amazon S3 文件系统
- Trivago 使用 Amazon S3 版本控制进行大规模图像恢复
- Yahoo 的云对象存储
- LinkedIn 的 Ambry:分布式不可变对象存储
- Dynamometer:在 LinkedIn 上使用最小硬件以最大保真度进行 HDFS 扩展测试
- Hammerspace:Airbnb 的持久、并发、堆外存储
- MezzFS:在 Netflix 媒体处理平台挂载对象存储
- Magic Pocket:Dropbox 的内部百亿级存储系统
- 关系型数据库
- Uber 上的 MySQL
- Pinterest 上的 MySQL
- Twitch 上的 PostgreSQL
- 在 Airbnb 中扩展基于 MySQL 的财务报告系统
- 在 Wix 中扩展 MySQL
- 在 Meta 中构建和部署 MySQL Raft
- Airbnb 的 MaxScale (MySQL) 数据库代理
- 从 Postgres 切换到 MySQL 在 Uber
- 在 Instagram 上使用 Postgres 处理增长
- 在 TransferWise 上扩展分析数据库(Postgres)
- 在 Adyen 上更新 50TB 的 PostgreSQL 数据库
- PayPal 在每日处理数百亿查询时扩展数据库访问
- Yelp 最小化 MySQL 读写停机时间
- Facebook 将 MySQL 从 5.6 迁移到 8.0
- Quora 从 HBase 迁移到 MyRocks
- 复制
- Booking.com 中的 MySQL 并行复制(4 部分)
- Github 中的 MySQL 复制延迟缓解和读取负载减少
- Shopify 中的数据库副本读取一致性
- 黑盒审计:验证 MySQL 和 Redshift 之间的端到端复制完整性(Yelp)
- Airbnb 主 MySQL 数据库分区
- Herb:无模式数据存储的多数据中心复制引擎(Uber)
- 分片)
- 在 Pinterest 分片 MySQL
- 在 Twilio 分片 MySQL
- 在 Square 分片 MySQL
- 在 Quora 分片 MySQL
- Uber 的无模式数据存储的分片层
- Instagram 的分片与 ID
- Notion 的分片 Postgres
- Figma 的分片 Postgres
- Solr:提升批量索引性能的 Box 实践
- Tinder 的地理分片推荐(三部分)
- Facebook 的 Shard Manager 服务扩展实践
- Presto 分布式 SQL 查询引擎
- Presto at Pinterest
- Presto Infrastructure at Lyft
- Presto at Grab
- Engineering Data Analytics with Presto and Apache Parquet at Uber
- Slack 中的数据整理
- Netflix 在 AWS 上的大数据平台中的 Presto
- Eventbrite 中的 Presto 自动扩展
- Uber 使用 Alluxio 本地缓存加速 Presto
- NoSQL 数据库
- 键值数据库
- Nike 中的 DynamoDB
- Segment 中的 DynamoDB
- DynamoDB at Mapbox
- Manhattan: Distributed Key-Value Database at Twitter
- Sherpa: Distributed NoSQL Key-Value Store at Yahoo
- HaloDB: Embedded Key-Value Storage Engine at Yahoo
- Indeed 的 MPH:快速且紧凑的不可变键值存储
- LinkedIn 的 Venice:分布式键值数据库
- 列式数据库
- Cassandra
- Cassandra at Instagram
- Storing Images in Cassandra at Walmart
- Storing Messages with Cassandra at Discord
- Scaling Cassandra Cluster at Walmart
- 使用 Cassandra 在 Yelp 上扩展广告分析
- 使用 Spark 和 Cassandra 在 Dream11 上扩展到 1 亿+读写
- 将 Food Feed 从 Redis 迁移到 Cassandra 在 Zomato
- 在 Netflix 上对 AWS 上的 Cassandra 可扩展性进行基准测试
- 使用 Cassandra 在 Intuit QuickBooks 中实现大规模服务解耦
- 使用 Cassandra 在 SoundCloud 中保持计数同步
- 在 Glassdoor 中通过 Cassandra 驱动配置提高性能和负载均衡
- Spotify 中的 cstar:Cassandra 协调工具
- HBase
- HBase at Salesforce
- HBase in Facebook Messages
- HBase in Imgur Notification
- 在 Pinterest 上提高 HBase 备份效率
- 小米的 HBase
- Redshift
- GIPHY 上的 Redshift
- Redshift at Hudl
- Redshift at Drivy
- Document Databases
- eBay: Building Mission-Critical Multi-Data Center Applications with MongoDB
- MongoDB 在百度:跨 160 个分片存储 2000 多亿文档的多租户集群
- Addepar 中的 MongoDB 数据迁移
- Parse(已被 Facebook 收购)的 AWS 和 MongoDB 基础设施
- Addepar 中的 MongoDB 数据迁移
- LinkedIn 上的 Couchbase 生态系统
- Zendesk 上的 SimpleDB
- Espresso:LinkedIn 的分布式文档存储
- 图数据库
- FlockDB:Twitter 的分布式图数据库
- TAO:Facebook 社交图谱的分布式数据存储
- Akutan:eBay 的分布式知识图谱存储
- 时间序列数据库
- Beringei:Facebook 的高性能时间序列存储引擎
- MetricsDB:Twitter 的时间序列数据库,用于存储指标
- Atlas:Netflix 的内存维度时间序列数据库
- Heroic:Spotify 的时间序列数据库
- Roshi:SoundCloud 的时间序列事件分布式存储系统
- Goku:Pinterest 的时间序列数据库
- Netflix 的时序数据存储扩展(2 部分)
- Netflix 的时序数据抽象层
- Druid - 实时分析数据库
- Druid at Airbnb
- Druid at Walmart
- Druid at eBay
- Netflix 上的 Druid
- 分布式存储库、依赖关系和配置管理
- DGit:Github 上的分布式 Git
- Stemma:Palantir 上的分布式 Git 服务器
- Flickr 分布式系统配置管理
- Microsoft 的 Git 仓库
- Microsoft 使用大型仓库解决 Git 问题
- Google 的单个仓库
- 在 Adyen 扩展基础设施和(Git)工作流
- 在 Booking.com 分发 dotfiles
- 秘密探测器:在 Yelp 的源代码中防止秘密
- 在 LinkedIn 大规模管理软件依赖
- LinkedIn 在高速版本库中合并代码
- Twitter 的动态配置
- Mixpanel 的动态配置
- GoDaddy 的动态配置
- Spotify 的舰队管理(3 部分)
- 扩展持续集成和持续交付
- Facebook 的持续集成栈
- Netflix 的分布式仓库和依赖关系的持续集成
- Dropbox 使用 Bazel 进行持续集成和部署
- Airbnb 大规模采用 Bazel 进行 Web 开发
- BuzzFeed 的持续部署
- Screwdriver:Yahoo 为动态基础设施开发的持续交付构建系统
- CI/CD at Betterment
- CI/CD at Brainly
- Scaling iOS CI with Anka at Shopify
- Scaling Jira Server at Yelp
- Flexport 通过自动扩展 CI/CD 集群降低测试成本
可用性
- 韧性工程:学会拥抱失败
- LinkedIn 的 Project Waterbear 韧性工程
- iHeartRadio 中应对流量过载的弹性
- GO-JEK 中分布式系统的弹性
- eBay 为企业提供的实用 NoSQL 弹性设计模式
- Quora 确保灾难弹性的措施
- Expedia 的站点弹性
- eBay 使用 Kafka 的弹性和灾难恢复
- Uber 多区域 Kafka 的灾难恢复
- 故障转移
- 全球流量路由和故障转移的演进
- 灾难恢复故障转移测试
- 为故障设计微服务架构
- GoSquared 使用 ELB 实现自动故障转移
- 美国运通消除数据库以提高可用性
- Vinted 使用 Redis Sentinel 实现故障转移
- FreeAgent 的高可用性 SaaS 基础设施
- GitHub 的 MySQL 高可用性
- Eventbrite 的 MySQL 高可用性
- 沃尔玛的业务连续性与灾难恢复
- 负载均衡
- 现代网络负载均衡和代理的介绍
- 前五名(负载均衡)可扩展性模式
- Facebook 的负载均衡基础设施支持超过 13 亿用户
- DHCPLB:Facebook 的 DHCP 负载均衡器
- Katran:Facebook 的可扩展网络负载均衡器
- 确定性光圈:Twitter 的分布式负载均衡算法
- Netflix 使用 Eureka 进行负载均衡
- Netflix 边缘负载均衡
- Zuul 2:Netflix 的云网关
- Yelp 的负载均衡
- Github 的负载均衡
- Vimeo 使用一致性哈希改进负载均衡
- 500 pixel 的 UDP 负载均衡
- QALM: Uber 的 QoS 负载管理框架
- 使用 Rum DNS 进行流量引导 LinkedIn
- Dropbox 的流量基础设施(边缘网络)
- Dropbox 基于智能 DNS 的负载均衡
- 在 Stripe 监控 DNS 系统
- 在 Monday 的多 DNS 架构(3 部分)
- Hulu 的动态任意播 DNS 基础设施
- 速率限制
- 在 Cloudflare 中扩展到数百万个域的速率限制
- Cloud Bouncer:Yahoo 的分布式速率限制
- 在 Stripe 中使用速率限制器扩展 API
- Allegro 的分布式速率限制
- Ratequeue:Twilio 的核心队列和速率限制系统
- Grab 的配额服务
- Figma 的速率限制
- 自动扩展
- Pinterest 自动扩展
- 基于请求队列的 Square 自动扩展
- Trivago 的 Jenkins 自动扩展
- Spotify 的 Pub-Sub 消费者自动扩展
- 基于 CPU 负载的 Spotify Autoscaling Bigtable 集群
- Yelp Autoscaling AWS Step Functions Activities
- Scryer:Netflix 的预测性自动扩展引擎
- Bouncer:Palantir 的简单 AWS 自动扩展回滚
- Clusterman:Yelp 的 Mesos 集群自动扩展
- 谷歌全球分布式存储系统中的可用性
- 雅虎的 NodeJS 高可用性
- 领英的运维(11 部分)
- 监控 LinkedIn 动态的高可用性
- 支持 Facebook 全球活动
- BlaBlaCar 的高可用性
- Netflix 的高可用性
- Twilio 的高可用云基础设施
- Airbnb 在 Kubernetes 上实现分布式数据库的高可用性
- Dropbox 自动化数据中心操作
- Riot Games 全球化玩家账号
稳定性
- 断路器
- 分布式系统中的断路器
- 用于容器扩展的断路器
- SoundCloud 上的韧性课程
- Trivago 上的时间序列数据库保护器:Protector
- Heroku 通过断路器提高生产稳定性
- Zendesk 上的断路器
- Traveloka 中的断路器
- Shopify 中的断路器
- 超时
- Netflix 中的容错(超时和重试、线程分离、信号量、断路器)
- 强制超时:DoorDash 的可靠性方法论
- 解决 eBay 中 tcp_tw_recycle 启用时的连接超时问题
- Booking.com 的 MySQL 容错复制
- 舱壁:在一个部分中划分和容忍故障
- 稳态:始终将日志放在单独的磁盘上
- 限流:保持稳定节奏
- 多集群:提升领英大规模单体 API 服务的弹性和稳定性
- 英雄联盟服务器的确定性(四部分)
性能
- 操作系统、存储、数据库、网络上的性能优化
- 通过背景数据预取提升 Instagram 性能
- 解决领英 Linux 文件系统性能回归问题
- eBay 如何使用压缩技术解决网络 I/O 瓶颈
- Dropbox 如何优化 Web 服务器以实现高吞吐量和低延迟
- Netflix 在 60,000 毫秒内进行 Linux 性能分析
- Mixpanel 如何实时缩减 Google Cloud 持久磁盘(PD-SSD)
- 使用 Python & Celery 在 Zapier 中通过 jemalloc 减少 40% 的 RAM 使用
- 在 Slack 中减少内存占用
- Slack 的持续负载测试
- Pinterest 的性能改进
- Wix 服务器端渲染
- Yelp MySQLStreamer 性能提升 30 倍
- Netflix API 优化
- Walmart 使用 Riemann 和 Clojure 进行性能监控
- Zynga 的实时游戏性能追踪仪表盘
- eBay 优化 CAL 报告 Hadoop MapReduce 作业
- eBay Quartz 调度器性能调优
- Riot Games 的 C++分析(第一部分:优化,第二部分:测量与分析)
- 在家搭建 HomeAway 的 React 服务器端渲染分析
- Dailymotion 的硬件辅助视频转码
- Dropbox 在每秒 1000 万次请求下的跨分片事务
- Pinterest 的 API 分析
- Yelp 的 Pagelets 并行化服务器端处理
- Twitter 在 Redis 中改进键过期
- MindGeek 使用火焰图优化广告投放网络性能
- Netflix 的容器预测 CPU 隔离
- 提升 Uber 中 HDFS I/O 利用率以提高效率
- 云宝石:Etsy 云端 kWh 估算
- 无限制:修复云端 CPU 限制(两部分)在 Indeed
- 通过调整垃圾回收进行性能优化
- LinkedIn 上的 Java 应用程序中的垃圾回收
- Adobe 在高通量、低延迟机器学习服务中的垃圾回收
- SoundCloud 上 Redux 应用程序中的垃圾回收
- Twitch 上 Go 应用程序中的垃圾回收
- 分析阿里巴巴的 V8 垃圾回收日志
- Instagram 通过 Python 垃圾回收减少每请求 50%内存增长
- 移除 Github 的带外垃圾回收器(OOBGC)的性能影响
- 在 Allegro 调试 Java 内存泄漏
- 阿里 JVM 优化
- 优步大规模服务 JVM 内存调优
- 沃尔玛 Solr 性能调优
- Flipkart 高吞吐量微服务内存调优
- 图像、视频、页面加载性能优化
- Facebook 大规模优化 360 度照片
- Etsy 在照片基础设施中减少图像文件大小
- Pinterest 提升 GIF 性能
- 在 Pinterest 优化视频播放性能
- 使用 Netflix 动态优化器优化低带宽视频流
- YouTube 自适应视频流
- 在 Dailymotion 减少视频加载时间
- 提升 Zillow 主页性能
- Expedia 客户端性能优化过程
- BBC 的 Web 性能
- 通过 Brotli 压缩进行性能优化
- 使用 Brotli 压缩提升 LinkedIn 网站 Speed
- Booking.com 中的 Brotli
- Treebo 中的 Brotli
- Dropbox 静态内容中使用 Brotli 部署
- Yelp 使用 Brotli 进行渐进增强
- DoorDash 通过压缩加速 Redis
- 语言和框架的性能优化
- Netflix 的 Python 使用
- Python 大规模应用(3 部分)在 Instagram
- OCaml 最佳实践(2 部分)在 Issuu
- PHP 在 Slack
- Go 在 Trivago
- Etsy 中的 TypeScript
- Etsy 中使用 Kotlin 管理状态
- DoorDash 中的 Kotlin
- Bumble 中的 BPF 和 Go
- GitLab 中的 Ruby on Rails
- Figma 中的 Rust 生产应用
- WeWork 的语言栈选择
- Discord 从 Go 切换到 Rust
- Agoda 的 ASP.NET Core 性能优化
- Uber 的 Go 数据竞争模式
- Netflix 的 Java 21 虚拟线程
智能化
- 大数据
- Uber 的数据平台
- 宝马的数据平台
- Netflix 的数据平台
- Flipkart 数据平台
- Coupang 数据平台
- DoorDash 数据平台
- Khan Academy 数据平台
- Airbnb 的数据基础设施
- LinkedIn 的数据基础设施
- GO-JEK 的数据基础设施
- Pinterest 的数据摄取基础设施
- Pinterest 的数仓架构
- Spotify 的数仓编排服务
- Spotify 的大数据处理(两篇)
- Uber 的大数据处理
- Lyft 的 Analytics Pipeline
- Grammarly 的 Analytics Pipeline
- Teads 的 Analytics Pipeline
- PayPal 的实时欺诈预防 ML 数据管道
- LinkedIn 上的大数据分析和机器学习技术
- LinkedIn 上的 Hadoop 自助服务报告平台
- LinkedIn 上的隐私保护分析和报告
- 沃尔玛用于跟踪商品可用性的分析平台
- 使用 Apache Pinot 在 Uber 上进行移动应用崩溃的实时分析
- HALO:Facebook 上的硬件分析和生命周期优化
- RBEA:King 上的实时分析平台
- AresDB:Uber 的 GPU 加速实时分析引擎
- AthenaX:Uber 的流式分析平台
- Jupiter:Uber 的配置驱动广告技术批量摄取平台
- Delta:Netflix 的数据同步和丰富平台
- Keystone:Netflix 的实时流处理平台
- Databook:利用元数据将大数据转化为知识(Uber)
- Amundsen:Lyft 的数据发现与元数据引擎
- Maze:Uber 的漏斗可视化平台
- Metacat:让 Netflix 的大数据可发现且有意义
- SpinalTap:Airbnb 的变更数据捕获系统
- Accelerator:eBay 的快速数据处理框架
- Omid:Yahoo 的交易处理平台
- TensorFlowOnSpark:Yahoo 在大数据集群上的分布式深度学习
- CaffeOnSpark:Yahoo 上的大数据集群分布式深度学习
- Spark on Scala:Adobe 的 Analytics 参考架构
- Spotify 的实验平台(2 部分)
- Airbnb 的实验平台
- Zalando 的智能产品平台
- LINE 的日志分析平台
- Myntra 的数据可视化平台
- Netflix 的构建和扩展数据血缘关系
- 为 Pinterest 的计算机视觉任务构建可扩展的数据管理系统
- Etsy 的结构化数据
- 扩展成熟的数據管道 - Airbnb 的管理开销
- Airbnb 的 Spark 分区策略
- LinkedIn 在领英上扩展 Hadoop 分布式文件系统
- LinkedIn 在领英上扩展 Hadoop YARN 集群超过 10,000 个节点
- 在 Pinterest 上扩展大数据访问控制
- 分布式机器学习
- Yelp 的机器学习平台
- Etsy 的机器学习平台
- Zalando 的机器学习平台
- Uber 的 AI/ML 基础设施扩展
- Lyft 的推荐系统
- Lyft 的强化学习平台
- Etsy 的推荐服务平台
- Spotify 的用户预测基础设施
- Aroma:在 Facebook 使用机器学习进行代码推荐
- Flyte:Lyft 的云原生机器学习和数据处理平台
- LyftLearn:基于 Kubernetes 构建的 Lyft 机器学习模型训练基础设施
- Horovod:Uber 的开源分布式深度学习框架(适用于 TensorFlow)
- Genie:优步的 Gen AI 应召助手
- COTA:利用 NLP 和机器学习提升优步客户服务
- Manifold:优步的模型无关可视化调试工具
- Repo-Topix:Github 上的主题提取框架
- Concourse:在领英以近乎实时的方式生成个性化内容通知
- Altus Care:将聊天机器人应用于 eBay 平台工程
- PyKrylov:加速 eBay 机器学习研究
- Box Graph:Box 的即时社交网络
- PricingNet:Skyscanner 使用神经网络进行定价建模
- PinText:Pinterest 的 Multitask Text Embedding System
- SearchSage:Pinterest 的 Search Query Representations 学习
- Cannes:ML 为 Dropbox 每年节省 170 万美元的文档预览
- 为 Yelp 的点击率预测扩展 Gradient Boosted Trees
- 在苹果公司实现规模化隐私学习
- Mercari 的图像分类深度学习实验
- Allegro 产品图像中的框架检测深度学习
- Hulu 基于内容的视频相关性预测
- 在 Yelp 上管理不当视频内容
- 在 TripAdvisor 上使用深度学习改进照片选择
- 在 TripAdvisor 上使用深度学习为体验提供个性化推荐
- BBC 的个性化推荐系统
- 康泰纳什的机器学习(2 部分)
- 康泰纳什的自然语言处理和内容分析(2 部分)
- iHeartRadio 使用机器学习描绘音乐世界(2 部分)
- Netflix 使用机器学习提升流媒体质量
- 利用机器学习匹配 GO-JEK 的司机与乘客
- 利用深度神经网络改进 YouTube 视频缩略图
- 利用分位数回归实现 Instacart 准时送达
- Zalando 利用深度学习实现跨语言端到端产品搜索
- Jane Street 机器学习
- Quora 端到端答案排序机器学习
- Booking.com 排序平台
- Flipboard 使用 LDA 聚类相似故事
- Flickr 中的相似性搜索
- Indeed 的求职推荐大规模机器学习管道
- Taboola 从原型到生产的深度学习
- CERN 使用机器学习粉碎原子
- 在 Medium 上映射标签
- 在 Monsanto 使用狄利克雷过程混合模型在 Scala 中进行聚类
- 在 Foursquare 使用 DBSCAN 和随机森林映射标记
- 在 Uber 进行预测
- 优步的财务预测
- Twitter 通过工作流实现机器学习生产化
- eBay 基于深度学习的 GUI 测试
- Pivotal 通过机器学习扩展推荐驾驶路线
- DoorDash 实时预测
- Dropbox 使用机器学习索引数十亿图像中的文本
- Etsy 通过语义嵌入建模用户旅程
- LinkedIn 自动化虚假账户检测
- 在 Airbnb 构建知识图谱
- 在 Instagram 的核心建模
- 在 Mercari 的禁止物品检测中的神经架构搜索 (NAS)
- 在 Airbnb 的计算机视觉
- Zillow 的 3D Home Backend Algorithms
- Lyft 的长期预测
- Yelp 使用深度学习发现热门菜肴
- Twitter 用于广告候选排名的 SplitNet 架构
- Indeed 上的工作筛选
- Yelp 上的餐厅等待时间预测架构
- Spotify 上的音乐个性化
- GoDaddy 上的域名估值深度学习
- Stripe 上的相似性聚类以捕获欺诈团伙
- Etsy 上的个性化搜索
- Lyft 上的机器学习特征服务基础设施
- Etsy 上的上下文特定竞价系统
- 在 Yelp 上大规模审核照片中的推广垃圾邮件和不适当内容
- 在 Dropbox 上使用机器学习优化支付
- 在 Netflix 上大规模扩展媒体机器学习
- eBay 的相似度引擎
- Etsy 在内容审核中的机器学习
架构
- Medium 的技术栈
- Shopify 的技术栈
- Airbnb 的构建服务(4 部分)
- Evernote 的架构
- Riot Games 聊天服务的架构(3 部分)
- 英雄联盟客户端更新的架构
- Twitter 广告平台的架构
- Uber API 网关的架构
- Tinder API 网关的架构
- Slack 的基本架构
- eBay 采用轻量级分布式架构处理数千个库发布
- LinkedIn 后端架构
- Flickr 后端架构
- Zendesk 基础设施(三部分)
- Grubhub 的云基础设施
- LinkedIn 的实时存在平台
- LinkedIn 的设置平台
- Glassdoor 的近线系统以实现规模和性能(2 部分)
- Pinterest 广告实时用户行为计数系统
- Riot Games API 平台
- 纽约时报游戏平台
- Kabootar:Swiggy 通信平台
- Simone:Netflix 的分布式模拟服务
- Seagull:帮助 Yelp 每天运行超过 2000 万次测试的分布式系统
- PriceAggregator:Agoda 的智能酒店价格获取系统(3 部分)
- Phoenix:Tinder 的测试平台(3 部分)
- Netflix 的六边形架构
- LINE 贴纸服务的架构
- Palantir 的 Stack Overflow Enterprise 架构
- Pinterest 关注动态、兴趣动态和为你精选的架构
- WeWork 的 API 规范工作流
- Netflix 的媒体数据库
- 沃尔玛的会员交易历史架构
- Dropbox 的同步引擎(两部分)
- Twitter 的广告节奏服务
- Netflix 的快速事件通知系统
- 金融、银行和支付系统架构
- Monzo 的银行后端
- Wealthsimple 的规模化交易平台
- Margo Bank 的核心银行系统
- Nubank 的架构
- TransferWise 的技术栈
- Addepar 技术栈
- Airbnb 分布式支付系统中的双重支付避免
- Etsy 支付扩展(3 部分)
- Paytm 每日安全处理数百万数字交易
- Grammarly 的计费和支付平台
面试
- 设计大规模系统
- 我的扩展英雄 - Jeff Atwood(面试前的 endorphins,开个玩笑)
- 从构建大规模分布式系统到软件工程建议 - Jeff Dean
- 面向规模的系统架构入门
- 系统设计面试解析
- 系统设计面试前需要了解的 8 件事
- 系统设计面试前 10 个常见问题
- 简明版前 10 个常见大规模软件架构模式
- 云大数据设计模式 - Lynn Langit
- 如何在 45 分钟的系统设计面试中设计出错误的 Netflix?
- API 最佳实践:Webhooks、弃用和设计
- 解释低级系统(操作系统、网络/协议、数据库、存储)
- Linux 中 I/O 等待时间的精确含义
- Paxos 实践——工程视角
- 如何实现分布式锁
- SQL 事务隔离级别详解
- “当...会发生什么?以及如何”问题
- Netflix:当你按下播放键时会发生什么?
- Monzo:点对点支付如何运作
- 传输与对等连接:您的请求如何到达 GitHub
- Spotify 如何流式传输音乐
组织
- SoundCloud 的工程级别
- Palantir 的工程角色
- Dropbox 的工程职业框架
- Twitter 的工程团队扩展
- LinkedIn 工程团队如何跨团队扩展决策制定
- GOJEK 如何扩展数据科学团队
- Zalando 如何扩展敏捷开发
- bol.com 如何以 60 个自主团队运行
- 从 Intercom 扩展产品团队的经验教训
- 在 Typeform 招聘、管理和扩展工程团队
- 在 Instagram 扩展 Datagram 团队
- 在 Flexport 扩展设计团队
- Salesforce 的团队模型用于扩展设计系统
- Wish 的构建分析团队(4 部分)
- Transferwise 从 2 位创始人到 1000 名员工
- Adobe 从 10 人增长到 170 人的 UX 团队经验教训
- Pinterest 扩展的五条经验教训
- Vinted 的工程方法
- Indeed 使用指标改进开发流程(和指导人员)
- Skyscanner 创建内部产品时需要避免的错误
- Etsy 的 RACI (Responsible, Accountable, Consulted, Informed)
- Zalando 的领导力四大支柱 (Empathy, Inspiration, Trust, Honesty)
- Shopify 的结对编程
- Asana 的分布式责任
- Zalando 的轮岗工程师
- Pinterest 的实验想法评审
- Spotify 的技术迁移
- Yelp 的代码所有权改进
- eBay 的敏捷代码库
- Miro 的敏捷数据工程
- Airbnb 通过 Slack 实现自动化事件管理
- BBC 的代码重构组织
- 代码审查
- Palantir 的代码审查
- LINE 的代码审查
- Medium 的代码审查
- LinkedIn 代码审查
- 迪士尼代码审查
- Netlify 代码审查
Talk
- [《分布式系统一分钟入门 - Confluent 开发者体验高级总监 Tim Berglund》(视频链接:https://www.youtube.com/watch?v=Y6Ev8GIlbxc)]
- [《在 Facebook 构建实时基础设施 - Facebook 软件工程师 Jeff Barber 和 Shie Erlich》(会议演讲链接:https://www.usenix.org/conference/srecon17americas/program/presentation/erlich)]
- [《为 Google 构建可靠的社交基础设施 - Google 高级经理 Marc Alvidrez》(会议演讲链接:https://www.usenix.org/conference/srecon16/program/presentation/alvidrez)]
- [《在 Google 规模下构建分布式构建系统 - Google 软件工程师 Aysylu Greenberg》(视频链接:https://www.youtube.com/watch?v=K8YuavUy6Qc)]
- Dropbox 的站点可靠性工程 - Tammy Butow, Dropbox 的站点可靠性工程经理
- 谷歌如何实现行星级规模 - Melissa Binde, 谷歌云平台 SRE 总监
- Netflix 的微服务指南 - Josh Evans, Netflix 运营工程总监
- 大型在线服务实现快速响应时间 - Jeff Dean, 谷歌高级研究员
- Shopify 处理 80K RPS 名人销售架构 - Shopify 工程负责人 Simon Eskildsen
- Facebook 规模化经验 - Facebook 工程总监 Bobby Johnson
- Salesforce 大中华区性能优化 - Salesforce 企业架构师 Jeff Cheng
- GIPHY 如何向 3 亿用户交付 GIF - GIPHY 服务工程师 Alex Hoang 和 Nima Khoshini
- 阿里巴巴的高性能数据包处理平台 - 阿里巴巴高级总监王海勇
- 解决大规模数据中心和云互联问题 - Equinix 首席技术官 Ihab Tarazi
- 扩展 Dropbox - Dropbox 后端工程师 Kevin Modzelewski
- 在 Facebook 上以性能进行扩展 - Facebook 基础设施副总裁 Jia Bill
- 在 Facebook 上为十亿用户扩展实时视频 - Sachin Kulkarni,Facebook 工程总监
- 在 Instagram 上扩展基础设施 - Lisa Guo,Instagram 工程
- 在 Twitter 上扩展基础设施 - Yao Yue,Twitter 高级软件工程师
- 在 Etsy 上扩展基础设施 - Bethany Macri,Etsy 工程经理
- 阿里为全球购物节实时基础设施的扩展 - 蒋晓伟,阿里高级总监
- Spotify 数据基础设施的扩展 - Matti (Lepistö) Pehrs,Spotify
- Pinterest 的扩展 - Marty Weiner,Pinterest 的创始工程师
- Slack 的扩展 - 魏冰,Slack 基础设施软件工程师
- Youtube 后端扩展 - Sugu Sougoumarane, Youtube 软件工程师
- Uber 后端扩展 - Matt Ranney, Uber 首席系统架构师
- Netflix 全球 CDN 扩展 - Dave Temkin, Netflix 全球网络总监
- Facebook 负载均衡基础设施扩展以支持 13 亿用户 - Patrick Shuff, Facebook 生产工程师
- 将 NSFW 网站(不适宜在工作场合观看的网站)扩展至每日 2 亿观看量及更高 - MindGeek 的首席平台开发者 Eric Pickup
- 在 Quora 上扩展计数基础设施 - Quora 的软件工程师 Chun-Ho Hung 和 Nikhil Gar
- 在微软上扩展 Git - 微软的首席程序经理 Saeed Noursalehi
- 在 Shopify 上跨多个数据中心扩展多租户架构 - Shopify 的工程负责人 Weingarten