# Instagram 提高了其应用程序的性能。 这是如何做。
> 原文: [http://highscalability.com/blog/2014/9/29/instagram-improved-their-apps-performance-heres-how.html](http://highscalability.com/blog/2014/9/29/instagram-improved-their-apps-performance-heres-how.html)
![](https://img.kancloud.cn/d8/c5/d8c54b434528a1efcfacb4dc79703933_200x204.png)
[平面设计](http://en.wikipedia.org/wiki/Flat_UI_Design)只是另一张漂亮的面孔,还是作为 UI 革命掩盖的巨大性能突破? 事实证明,扁平化设计是赢得冷战的坚石。
Instagram 工程师 [Tyler Kieft](http://tylerkieft.com/) 在他在 [@scale 会议](http://atscaleconference.com/)上发表的简短且内容丰富的演讲中,对上述内容进行了详尽的解释:[在典型 Android](https://www.youtube.com/watch?v=GHTO2WKDO6I#t=8927) 上的 Instagram ]。 该演讲是[系列演讲](/blog/2014/9/22/how-facebook-makes-mobile-work-at-scale-for-all-phones-on-al.html)的一部分,该演讲由 Facebook 进行,主题是如何为全球范围内的移动应用程序设计现实,与美国相比,这种手机的速度较慢,屏幕较小,网络速度较慢。 。
为典型的手机而不是高端手机进行设计需要 Instagram 团队深入思考其设计。 泰勒(Tyler)演讲的启示之一是**向平面设计**的转移极大地提高了应用程序的美观性,可用性和实用性,并且极大地提高了性能。
这真是一个惊喜。 我只是将平面设计视为思考如何构建漂亮的 UI 的一种方式。 傻我 感谢泰勒(Tyler)如此清晰,有力地解释了平面设计的好处,并使用 Instagram 作为可能的典范。
平面设计是反拟态的,它是数字化本地人,避免了对现实外观的痴迷,采用简单的元素,简单的版式,平面颜色和简单的设计。
使用平面设计,Instagram 可以从冷启动时间缩短 120 毫秒。 它还能够将显示提要屏幕所需的资产数量从 29 个减少到 8 个。 同时,使应用程序更美观,更易用,并更加关注不同手机尺寸的内容。
平面设计如何使这一切成为可能?
## 转向平面设计
* Instagram 改写了他们的 UI,以专注于 Android 上提供的各种 UI 的更好性能。
* Instagram 于 2012 年在 Android 上发布时,它是由 3 个人在大约 4 个月内建成的。 两名工程师和一名设计师。 Android 版本使用与 iOS 版本相同的设计。
* 该设计使用了甜美的渐变色和许多 UI 元素。
* 向 iOS7 过渡到平面设计,使产品变得更加简单和美观。 没有更多的渐变。 拿出箱子。 没有更多的阴影。
* 他们从适应平面设计**的经验中学到了**:
* **平面设计是减少**,更快开发代码和更快交付产品的机会。 这对开发人员来说很棒。
* **平面设计的性能更高**。 开发人员不仅做得更少,而且手机在显示 UI 方面也做得更少。
* 使用从 iOS7 平面设计重新设计中学到的新 Android 版本的目标:
* **使其平坦,使其更快**。 这不是重写。 导航模式没有改变。
* **注意屏幕空间**。 重新浏览每个屏幕,并弄清楚如何更好地适应所有屏幕尺寸。
* **变得漂亮**。 这是他们在 Instagram 上所做的一切的基础。
* 总体效果是极大的简化。 进行了哪些更改?
* **将所有内容从 Chrome** 中删除。 拿出所有渐变和光泽按钮。 去勾勒形状而不是图标的渐变按钮。 剩下的是纯色和扁平形状。 希望用户界面淡入背景。
* **拿出注释图标**,使注释全屏显示,为注释文本留出更多空间。 使内容在屏幕上脱颖而出。 用户界面越少,使用小屏幕的人就有更多的空间阅读文本。
* **分叉了用于拍照的手机布局**。 在小型电话上,他们使用在屏幕顶部带有动作按钮的设计。 对于较大的屏幕,所有命令都在底部。
* **删除了整个应用程序不必要的 UI,以使内容更加集中**。 搜索屏幕上的三层铬减少到两层。 这在小型电话上腾出了很多空间。 由于三星 Galaxy 的按钮纤薄,采用扁平化设计很容易以编程方式进行操作,从而为内容腾出了很多空间。
* 请注意,演讲中有很多关于不同设计的精美图片,因此非常值得观看之前和之后的图片。
## 为什么要进行平面设计?
* **使用资产着色**运送更少的资产。 这意味着 APK 的大小较小,这在小型网络上非常有用。 魔术是**资产着色** **(**我以前从未听说过)。 [资产着色](http://blog.danlew.net/2014/08/18/fast-android-asset-theming-with-colorfilter/)表示资产(在这种情况下为图像)可以通过程序进行着色。 例如,可以通过编程方式将灰色的心脏染成红色。 资产着色意味着需要运输的资产更少。 传统上,每种按钮状态(按下,未按下,选择等)都需要单独的图像。通过着色,可以将不同状态的所有图像都不再需要运送了。 仅需要图像,并且可以设置不同的状态。
* **加载更少的资产**。 这意味着 UI 显示速度更快,并且用于存储位图的内存更少。 必须从闪存中读取每个需要显示的资产,并将其解码为位图。 完成的次数越少,应用程序变得越快。
* **更快的迭代时间**。 如果您要更改颜色或进行新开发,则不再需要设计师。 只需更改代码并重新编译即可。
* 结果:
* **在进行平面设计之前,需要 29 种不同的资源来显示供稿屏幕**。 平面设计后, **8 个资产**显示同一页面。 仅需要形状即可显示图标和徽标。 其他所有内容均以代码形式绘制为纯色和矩形。 仅仅是从所有设备的冷启动时间起将**缩短了 120ms** 。
* **采用扁平化设计,整个应用变得更快**。 每个屏幕的工作量都减少了。 更少的资产被加载,整个应用变得更加生气。 评论中的用户评论了应用程序在重新设计后的感觉。 人们真的很喜欢它。 人们赞赏与平台匹配的设计所带来的速度提升。
## 缩短冷启动时间
* 冷启动时间是应用程序启动并变得响应所需的时间。 从点击图标到在应用程序周围单击,它均有效。 我们的目标是让**应用能够超快速地启动**,以便使用低端手机的用户拥有丰富的体验。
* 几年前,在低端 Galaxy Y 上,Instagram 的启动时间为 3 秒。 在高端 Galaxy S5 上,启动时间为 750 毫秒。
* 现在,在 Galaxy Y 上,Instagram 需要 1.5 秒才能启动。 在 Galaxy S5 上,需要花费 **400 毫秒**。
* 怎么样? (除去资产)
* **对应用程序**进行配置。
* 找出导致应用速度下降的原因。
* 在 Android 上,您可以使用**方法跟踪**,并且可以在代码中放置计时语句。 方法跟踪数较小的方法。 **时序声明**是墙上时钟时间,而不是机器时间。 同时使用这两种功能可以让您对缓慢的情况有良好的感觉。
* **解决最慢的问题**。
* **延迟加载**。 从冷启动路径中删除项目。
* **重写慢速代码**。 例如,慢速 JSON 解析代码被重写为更快。
* **延迟到后台线程**。 不要在 UI 线程中执行操作,而可以在后台执行。
* **迭代**。 再次开始配置文件步骤。
* **应用范围内的单身人士发现速度很慢**。 通过计时发现。
* 在应用启动之前,已经启动了许多**重单例**:HTTP 客户端,Cookie 存储,图像缓存,视频缓存。 确实不需要这些东西即可向用户显示用户界面。 它们可以并行加载到后台。
* **两部分延迟加载**
* 想要**在后台**中初始化单例,但程序员仍将其视为始终可用于该应用的单例。 不想让程序员必须检查单例是否可用,因为那不是单例。
* **在 UI 线程**上创建足够的对象,以便公共 API 完全起作用,并且可供程序员使用。 将艰苦的工作推迟到后台线程。 对于高速缓存,这意味着打开和读取磁盘存储。 对于客户端,证书将在后台加载。 Cookies 在后台反序列化和解码。 通过这些更改,UI 可以更快地出现在屏幕上。
* **Newsview 运行缓慢**。 通过方法跟踪找到。
* 新闻视图最初显示为网络视图,其中显示了您的所有喜欢和评论。 需要在启动时加载它以尽快向用户显示其数据。
* 问题是无法控制 Webview。 它具有自己的堆栈和缓存系统。 **将其转换为本地**。 花了 2-4 周的时间。 原始转换后,冷启动时间将**降低了 30%**。
## 得到教训
* **可以实现快速的冷启动时间**。 如果他们很快,他们甚至会变得更快。 剖析,修复,迭代。
* **谨慎使用像素**。 查看每个屏幕,查看不需要的内容。 与美国相比,其他国家/地区的用户使用的手机要小得多。
* 移动电话喜欢简单的设计,移动开发人员也喜欢。 这要容易得多,也要快得多。
## 相关文章
* [在 Reddit 上](http://www.reddit.com/r/programming/comments/2iqfr7/how_instagram_improves_their_apps_performance/)
* [Facebook 斥资 10 亿美元收购 Instagram 架构](http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html)
* [Instagram 体系结构更新:Instagram 有何新功能?](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html)
* [有人可以表达 Google 的材料设计与苹果公司的平面设计吗?](http://www.quora.com/Can-someone-articulate-Googles-material-design-vs-Apples-flat-design)
我发现有趣的是,这种平面设计运动是由 Microsoft 与 Windows Phone 一起发起的。
总是会有更多的高档用户界面(如游戏中),但从总体上看,功能正在取代形式。 我喜欢那个。
它以功能为基础,对我有很多帮助。 直到观看了这个出色的演示,我才知道平面设计是什么。 现在,在许多不同的层次上它变得更加有意义。
正如文章所提出的那样,功能必须战胜视觉障碍。 但是作为仍然使用 iOS6.1.3 的匕首,我必须要求您承认,自 iOS7 以来,奇怪而与众不同的选择令人困惑:白色文本的鲜绿色背景,窄字体,细腻的灰色阴影以及总体而言太多了 屏幕上呈鲜亮的白色,而对于发现此效果实际上令人痛苦的用户则无能为力。 而且,即使使用 iOS8.0.2,提供的修改也是如此之小,以至于令人怀疑。
好吧,渐变对处理程序征税-如果处理器不能比程序员领先一步,就消除渐变。 但是至少要为用户提供背景颜色选项。 给一些真实的对比度控制。 为需要的人提供一些粗细的字体。
我们生活在一个这样的世界中,所有用户都将以正确的视线来到餐桌上,这一假设和期望越来越普遍。 但这是一个精英主义的假设。 使它精简,使其快速,但不要把我们中的很多人甩在后面。
- LiveJournal 体系结构
- mixi.jp 体系结构
- 友谊建筑
- FeedBurner 体系结构
- GoogleTalk 架构
- ThemBid 架构
- 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构
- TypePad 建筑
- 维基媒体架构
- Joost 网络架构
- 亚马逊建筑
- Fotolog 扩展成功的秘诀
- 普恩斯的教训-早期
- 论文:Wikipedia 的站点内部,配置,代码示例和管理问题
- 扩大早期创业规模
- Feedblendr 架构-使用 EC2 进行扩展
- Slashdot Architecture-互联网的老人如何学会扩展
- Flickr 架构
- Tailrank 架构-了解如何在整个徽标范围内跟踪模因
- Ruby on Rails 如何在 550k 网页浏览中幸存
- Mailinator 架构
- Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据
- Yandex 架构
- YouTube 架构
- Skype 计划 PostgreSQL 扩展到 10 亿用户
- 易趣建筑
- FaceStat 的祸根与智慧赢得了胜利
- Flickr 的联合会:每天进行数十亿次查询
- EVE 在线架构
- Notify.me 体系结构-同步性
- Google 架构
- 第二人生架构-网格
- MySpace 体系结构
- 扩展 Digg 和其他 Web 应用程序
- Digg 建筑
- 在 Amazon EC2 中部署大规模基础架构的六个经验教训
- Wolfram | Alpha 建筑
- 为什么 Facebook,Digg 和 Twitter 很难扩展?
- 全球范围扩展的 10 个 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展
- 《 FarmVille》如何扩展以每月收获 7500 万玩家
- Twitter 计划分析 1000 亿条推文
- MySpace 如何与 100 万个并发用户一起测试其实时站点
- FarmVille 如何扩展-后续
- Justin.tv 的实时视频广播架构
- 策略:缓存 404 在服务器时间上节省了洋葱 66%
- Poppen.de 建筑
- MocoSpace Architecture-一个月有 30 亿个移动页面浏览量
- Sify.com 体系结构-每秒 3900 个请求的门户
- 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训
- Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长
- 扩展 BBC iPlayer 的 6 种策略
- Facebook 的新实时消息系统:HBase 每月可存储 135 亿条消息
- Pinboard.in Architecture-付费玩以保持系统小巧
- BankSimple 迷你架构-使用下一代工具链
- Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表
- Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件
- Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求
- Node.js 成为堆栈的一部分了吗? SimpleGeo 说是的。
- 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量
- Medialets 体系结构-击败艰巨的移动设备数据
- Facebook 的新实时分析系统:HBase 每天处理 200 亿个事件
- Microsoft Stack 是否杀死了 MySpace?
- Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰
- Facebook:用于扩展数十亿条消息的示例规范架构
- Evernote Architecture-每天有 900 万用户和 1.5 亿个请求
- TripAdvisor 的短
- TripAdvisor 架构-4,000 万访客,200M 动态页面浏览,30TB 数据
- ATMCash 利用虚拟化实现安全性-不变性和还原
- Google+是使用您也可以使用的工具构建的:闭包,Java Servlet,JavaScript,BigTable,Colossus,快速周转
- 新的文物建筑-每天收集 20 亿多个指标
- Peecho Architecture-鞋带上的可扩展性
- 标记式架构-扩展到 1 亿用户,1000 台服务器和 50 亿个页面视图
- 论文:Akamai 网络-70 个国家/地区的 61,000 台服务器,1,000 个网络
- 策略:在 S3 或 GitHub 上运行可扩展,可用且廉价的静态站点
- Pud 是反堆栈-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术
- StackExchange 体系结构更新-平稳运行,Amazon 4x 更昂贵
- DataSift 体系结构:每秒进行 120,000 条推文的实时数据挖掘
- Instagram 架构:1400 万用户,1 TB 的照片,数百个实例,数十种技术
- PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片
- Etsy Saga:从筒仓到开心到一个月的浏览量达到数十亿
- 数据范围项目-6PB 存储,500GBytes / sec 顺序 IO,20M IOPS,130TFlops
- 99designs 的设计-数以千万计的综合浏览量
- Tumblr Architecture-150 亿页面浏览量一个月,比 Twitter 更难扩展
- Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天对 2000 万张照片进行爬网,分析和排名
- LinkedIn:使用 Databus 创建低延迟更改数据捕获系统
- 在 30 分钟内进行 7 年的 YouTube 可扩展性课程
- YouPorn-每天定位 2 亿次观看
- Instagram 架构更新:Instagram 有何新功能?
- 搜索技术剖析:blekko 的 NoSQL 数据库
- Pinterest 体系结构更新-1800 万访问者,增长 10 倍,拥有 12 名员工,410 TB 数据
- 搜索技术剖析:使用组合器爬行
- iDoneThis-从头开始扩展基于电子邮件的应用程序
- StubHub 体系结构:全球最大的票务市场背后的惊人复杂性
- FictionPress:在网络上发布 600 万本小说
- Cinchcast 体系结构-每天产生 1,500 小时的音频
- 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容
- 棱镜更新:基于文档和用户的机器学习
- Zoosk-实时通信背后的工程
- WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量
- 史诗般的 TripAdvisor 更新:为什么不在云上运行? 盛大的实验
- UltraDNS 如何处理数十万个区域和数千万条记录
- 更简单,更便宜,更快:Playtomic 从.NET 迁移到 Node 和 Heroku
- Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序
- BigData 使用 Erlang,C 和 Lisp 对抗移动数据海啸
- 分析数十亿笔信用卡交易并在云中提供低延迟的见解
- MongoDB 和 GridFS 用于内部和内部数据中心数据复制
- 每天处理 1 亿个像素-少量竞争会导致大规模问题
- DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长
- SongPop 在 GAE 上可扩展至 100 万活跃用户,表明 PaaS 未通过
- Iron.io 从 Ruby 迁移到 Go:减少了 28 台服务器并避免了巨大的 Clusterf ** ks
- 可汗学院支票簿每月在 GAE 上扩展至 600 万用户
- 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段
- 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量
- Facebook 的网络秘密
- 神话:埃里克·布鲁尔(Eric Brewer)谈银行为什么不是碱-可用性就是收入
- 一千万个并发连接的秘密-内核是问题,而不是解决方案
- GOV.UK-不是你父亲的书库
- 缩放邮箱-在 6 周内从 0 到 100 万用户,每天 1 亿条消息
- 在 Yelp 上利用云计算-每月访问量为 1.02 亿,评论量为 3900 万
- 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips
- Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户,300K QPS,22 MB / S Firehose 以及发送推文
- Salesforce Architecture-他们每天如何处理 13 亿笔交易
- 扩大流量的设计决策
- ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行
- 如何制作无限可扩展的关系数据库管理系统(RDBMS)
- Bazaarvoice 的架构每月发展到 500M 唯一用户
- HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息
- NYTimes 架构:无头,无主控,无单点故障
- 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放,喜欢和更多内容
- Google 如何备份 Internet 和数十亿字节的其他数据
- 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧
- AOL.com 体系结构如何发展到 99.999%的可用性,每天 800 万的访问者和每秒 200,000 个请求
- Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 构建社交音乐服务
- 大,小,热还是冷-条带,Tapad,Etsy 和 Square 的健壮数据管道示例
- WhatsApp 如何每秒吸引近 5 亿用户,11,000 内核和 7,000 万条消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理
- 关于 Disqus 的更新:它仍然是实时的,但是 Go 摧毁了 Python
- 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明
- 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集
- 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序
- 一点点:建立一个可处理每月 60 亿次点击的分布式系统的经验教训
- StackOverflow 更新:一个月有 5.6 亿次网页浏览,25 台服务器,而这一切都与性能有关
- Tumblr:哈希处理每秒 23,000 个博客请求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构
- MixRadio 体系结构-兼顾各种服务
- Twitter 如何使用 Redis 进行扩展-105TB RAM,39MM QPS,10,000 多个实例
- 正确处理事情:通过即时重放查看集中式系统与分散式系统
- Instagram 提高了其应用程序的性能。 这是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架构
- 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大规模构建发布平台
- Aeron:我们真的需要另一个消息传递系统吗?
- 机器:惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化
- AWS 的惊人规模及其对云的未来意味着什么
- Vinted 体系结构:每天部署数百次,以保持繁忙的门户稳定
- 将 Kim Kardashian 扩展到 1 亿个页面
- HappyPancake:建立简单可扩展基金会的回顾
- 阿尔及利亚分布式搜索网络的体系结构
- AppLovin:通过每天处理 300 亿个请求向全球移动消费者进行营销
- Swiftype 如何以及为何从 EC2 迁移到真实硬件
- 我们如何扩展 VividCortex 的后端系统
- Appknox 架构-从 AWS 切换到 Google Cloud
- 阿尔及利亚通往全球 API 的愤怒之路
- 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分
- 为社交产品设计后端
- 阿尔及利亚通往全球 API 第 3 部分的愤怒之路
- Google 如何创造只有他们才能创造的惊人的数据中心网络
- Autodesk 如何在 Mesos 上实施可扩展事件
- 构建全球分布式,关键任务应用程序:Trenches 部分的经验教训 1
- 构建全球分布式,关键任务应用程序:Trenches 第 2 部分的经验教训
- 需要物联网吗? 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式
- Uber 如何扩展其实时市场平台
- 优步变得非常规:使用司机电话作为备份数据中心
- 在不到五分钟的时间里,Facebook 如何告诉您的朋友您在灾难中很安全
- Zappos 的网站与 Amazon 集成后冻结了两年
- 为在现代时代构建可扩展的有状态服务提供依据
- 细分:使用 Docker,ECS 和 Terraform 重建基础架构
- 十年 IT 失败的五个教训
- Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售
- 整个 Netflix 堆栈的 360 度视图
- Wistia 如何每小时处理数百万个请求并处理丰富的视频分析
- Google 和 eBay 关于构建微服务生态系统的深刻教训
- 无服务器启动-服务器崩溃!
- 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南
- 为 David Guetta 建立无限可扩展的在线录制活动
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿个通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训
- 缩放原理
- TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿条通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训