From 3312ced263a40095fde1b486f5e068532292a298 Mon Sep 17 00:00:00 2001 From: wizardforcel <562826179@qq.com> Date: Sat, 27 Jun 2020 10:09:07 +0800 Subject: [PATCH] 2020-06-27 10:09:07 --- SUMMARY.md | 245 +++++++++++ docs/{246.md => 1.md} | 0 docs/10.md | 77 +--- docs/100.md | 164 +------- docs/101.md | 472 ++------------------- docs/102.md | 246 +++-------- docs/103.md | 259 +++++++++--- docs/104.md | 188 +++------ docs/105.md | 284 +++++++++++-- docs/106.md | 244 ++++++++--- docs/107.md | 277 ++++--------- docs/108.md | 310 ++++---------- docs/109.md | 115 ++---- docs/11.md | 565 ++++++------------------- docs/110.md | 74 +--- docs/111.md | 722 ++++++++++---------------------- docs/112.md | 158 +------ docs/113.md | 78 ++-- docs/114.md | 314 +++----------- docs/115.md | 150 ++----- docs/116.md | 639 +++++++++++++++++++++++++--- docs/117.md | 284 ++----------- docs/118.md | 138 +++---- docs/119.md | 328 ++++++++++----- docs/12.md | 156 ++++--- docs/120.md | 393 +++--------------- docs/121.md | 135 ++---- docs/122.md | 204 ++------- docs/123.md | 242 ++--------- docs/124.md | 242 +++++++++-- docs/125.md | 204 +++++++-- docs/126.md | 135 ++++-- docs/127.md | 393 +++++++++++++++--- docs/128.md | 328 +++++---------- docs/129.md | 138 ++++--- docs/13.md | 209 +++------- docs/130.md | 284 +++++++++++-- docs/131.md | 639 +++------------------------- docs/132.md | 150 +++++-- docs/133.md | 314 +++++++++++--- docs/134.md | 78 ++-- docs/135.md | 158 ++++++- docs/136.md | 722 ++++++++++++++++++++++---------- docs/137.md | 74 +++- docs/138.md | 115 ++++-- docs/139.md | 310 ++++++++++---- docs/14.md | 378 +---------------- docs/140.md | 277 +++++++++---- docs/141.md | 244 +++-------- docs/142.md | 284 ++----------- docs/143.md | 188 ++++++--- docs/144.md | 259 +++--------- docs/145.md | 246 ++++++++--- docs/146.md | 472 +++++++++++++++++++-- docs/147.md | 164 +++++++- docs/148.md | 456 ++++++++++++-------- docs/149.md | 181 +++++--- docs/15.md | 293 ++----------- docs/150.md | 226 +++++++++- docs/151.md | 327 +++++++-------- docs/152.md | 150 ++++--- docs/153.md | 131 ++++-- docs/154.md | 223 ++++++++-- docs/155.md | 258 ++++++++---- docs/156.md | 372 +++++++++++------ docs/157.md | 184 ++++----- docs/158.md | 290 ++++++++----- docs/159.md | 471 ++++++++++++++------- docs/16.md | 249 ++--------- docs/160.md | 65 ++- docs/161.md | 66 ++- docs/162.md | 495 +++++++++------------- docs/163.md | 462 ++++++++++++++++++--- docs/164.md | 173 +++++--- docs/165.md | 414 ++++++++++++++----- docs/166.md | 155 ++++++- docs/167.md | 176 +++++--- docs/168.md | 342 +++------------ docs/169.md | 288 ++++++++----- docs/17.md | 230 ++++++----- docs/170.md | 111 +++-- docs/171.md | 301 ++++++++++++-- docs/172.md | 132 ++---- docs/173.md | 113 +++-- docs/174.md | 92 ++--- docs/175.md | 117 ++---- docs/176.md | 388 ++++++++++++----- docs/177.md | 196 +++++++-- docs/178.md | 184 +++++++-- docs/179.md | 358 ++-------------- docs/18.md | 402 ++++++------------ docs/180.md | 396 +++++++++++++++++- docs/181.md | 231 +++++++++-- docs/182.md | 50 +-- docs/183.md | 272 +++++------- docs/184.md | 225 +++++----- docs/185.md | 373 ++++++++--------- docs/186.md | 527 +++++++++++++++-------- docs/187.md | 459 +++++++++++--------- docs/188.md | 537 ++++++++++++++++++++++-- docs/189.md | 158 ++++--- docs/19.md | 249 +++++------ docs/190.md | 206 +-------- docs/191.md | 266 +++++++++--- docs/192.md | 634 +++++++++++++++++++++++++++- docs/193.md | 205 +++++---- docs/194.md | 381 ++++++++++++++--- docs/195.md | 104 ++++- docs/196.md | 351 +++++----------- docs/197.md | 202 +++++---- docs/198.md | 291 +++++-------- docs/199.md | 325 ++++++++++----- docs/2.md | 820 +----------------------------------- docs/20.md | 200 +++------ docs/200.md | 382 ++++++++++------- docs/201.md | 116 ++++-- docs/202.md | 442 ++++++++++---------- docs/203.md | 288 +++++++++++-- docs/204.md | 421 +++++++++++++------ docs/205.md | 205 +++++---- docs/206.md | 132 +++--- docs/207.md | 551 +++++++++++++++++++++--- docs/208.md | 96 +++-- docs/209.md | 133 +++--- docs/21.md | 256 +++++------- docs/210.md | 183 +++----- docs/211.md | 700 ++++++++++++++++++++++++++++++- docs/212.md | 230 +++++++---- docs/213.md | 216 ++++++---- docs/214.md | 205 ++++++--- docs/215.md | 296 +++++++++---- docs/216.md | 942 +++++++++++++++++++++++++++++++++++------- docs/217.md | 202 +++------ docs/218.md | 117 +++--- docs/219.md | 30 +- docs/22.md | 204 +++++---- docs/220.md | 247 +++++++++-- docs/221.md | 654 +++++++++++++++++++++++++---- docs/222.md | 183 +++++--- docs/223.md | 494 ++++++++++++++-------- docs/224.md | 104 +++-- docs/225.md | 204 ++++----- docs/226.md | 256 +++++++----- docs/227.md | 200 ++++++--- docs/228.md | 249 ++++++----- docs/229.md | 402 ++++++++++++------ docs/23.md | 104 ++--- docs/230.md | 230 +++++------ docs/231.md | 249 +++++++++-- docs/232.md | 293 +++++++++++-- docs/233.md | 378 ++++++++++++++++- docs/234.md | 209 +++++++--- docs/235.md | 156 +++---- docs/236.md | 565 +++++++++++++++++++------ docs/237.md | 77 +++- docs/238.md | 147 +++---- docs/239.md | 108 +++-- docs/24.md | 494 ++++++++-------------- docs/240.md | 711 ++++++++++++++++++++++++++++--- docs/241.md | 214 ++++++++-- docs/242.md | 229 +++++++--- docs/243.md | 214 +++++++--- docs/244.md | 290 ++++++++++++- docs/245.md | 820 +++++++++++++++++++++++++++++++++++- docs/25.md | 183 +++----- docs/26.md | 654 ++++------------------------- docs/27.md | 247 ++--------- docs/28.md | 30 +- docs/29.md | 117 +++--- docs/3.md | 290 +------------ docs/30.md | 202 ++++++--- docs/31.md | 942 +++++++----------------------------------- docs/32.md | 296 ++++--------- docs/33.md | 205 +++------ docs/34.md | 216 ++++------ docs/35.md | 230 ++++------- docs/36.md | 700 +------------------------------ docs/37.md | 183 +++++--- docs/38.md | 133 +++--- docs/39.md | 96 ++--- docs/4.md | 214 +++------- docs/40.md | 551 +++--------------------- docs/41.md | 132 +++--- docs/42.md | 205 ++++----- docs/43.md | 421 ++++++------------- docs/44.md | 288 ++----------- docs/45.md | 442 ++++++++++---------- docs/46.md | 116 ++---- docs/47.md | 382 +++++++---------- docs/48.md | 325 +++++---------- docs/49.md | 291 ++++++++----- docs/5.md | 229 +++------- docs/50.md | 202 ++++----- docs/51.md | 351 +++++++++++----- docs/52.md | 104 +---- docs/53.md | 381 +++-------------- docs/54.md | 205 ++++----- docs/55.md | 634 +--------------------------- docs/56.md | 266 +++--------- docs/57.md | 206 ++++++++- docs/58.md | 158 +++---- docs/59.md | 537 ++---------------------- docs/6.md | 214 ++-------- docs/60.md | 459 +++++++++----------- docs/61.md | 527 ++++++++--------------- docs/62.md | 373 +++++++++-------- docs/63.md | 225 +++++----- docs/64.md | 272 +++++++----- docs/65.md | 50 ++- docs/66.md | 231 ++--------- docs/67.md | 396 +----------------- docs/68.md | 358 ++++++++++++++-- docs/69.md | 184 ++------- docs/7.md | 711 +++---------------------------- docs/70.md | 196 ++------- docs/71.md | 388 +++++------------ docs/72.md | 117 ++++-- docs/73.md | 92 +++-- docs/74.md | 113 ++--- docs/75.md | 132 ++++-- docs/76.md | 301 ++------------ docs/77.md | 111 ++--- docs/78.md | 288 +++++-------- docs/79.md | 342 ++++++++++++--- docs/8.md | 108 ++--- docs/80.md | 176 +++----- docs/81.md | 155 +------ docs/82.md | 414 +++++-------------- docs/83.md | 173 +++----- docs/84.md | 462 +++------------------ docs/85.md | 495 +++++++++++++--------- docs/86.md | 66 +-- docs/87.md | 65 +-- docs/88.md | 471 +++++++-------------- docs/89.md | 290 +++++-------- docs/9.md | 147 ++++--- docs/90.md | 184 +++++---- docs/91.md | 372 ++++++----------- docs/92.md | 258 ++++-------- docs/93.md | 223 ++-------- docs/94.md | 131 ++---- docs/95.md | 150 +++---- docs/96.md | 327 ++++++++------- docs/97.md | 226 +--------- docs/98.md | 181 +++----- docs/99.md | 456 ++++++++------------ 246 files changed, 34523 insertions(+), 34278 deletions(-) create mode 100644 SUMMARY.md rename docs/{246.md => 1.md} (100%) diff --git a/SUMMARY.md b/SUMMARY.md new file mode 100644 index 0000000..69740b3 --- /dev/null +++ b/SUMMARY.md @@ -0,0 +1,245 @@ ++ [LiveJournal 体系结构](1.md) ++ [mixi.jp 体系结构](2.md) ++ [友谊建筑](3.md) ++ [FeedBurner 体系结构](4.md) ++ [GoogleTalk 架构](5.md) ++ [ThemBid 架构](6.md) ++ [使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构](7.md) ++ [TypePad 建筑](8.md) ++ [维基媒体架构](9.md) ++ [Joost 网络架构](10.md) ++ [亚马逊建筑](11.md) ++ [Fotolog 扩展成功的秘诀](12.md) ++ [普恩斯的教训-早期](13.md) ++ [论文：Wikipedia 的站点内部，配置，代码示例和管理问题](14.md) ++ [扩大早期创业规模](15.md) ++ [Feedblendr 架构-使用 EC2 进行扩展](16.md) ++ [Slashdot Architecture-互联网的老人如何学会扩展](17.md) ++ [Flickr 架构](18.md) ++ [Tailrank 架构-了解如何在整个徽标范围内跟踪模因](19.md) ++ [Ruby on Rails 如何在 550k 网页浏览中幸存](20.md) ++ [Mailinator 架构](21.md) ++ [Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据](22.md) ++ [Yandex 架构](23.md) ++ [YouTube 架构](24.md) ++ [Skype 计划 PostgreSQL 扩展到 10 亿用户](25.md) ++ [易趣建筑](26.md) ++ [FaceStat 的祸根与智慧赢得了胜利](27.md) ++ [Flickr 的联合会：每天进行数十亿次查询](28.md) ++ [EVE 在线架构](29.md) ++ [Notify.me 体系结构-同步性](30.md) ++ [Google 架构](31.md) ++ [第二人生架构-网格](32.md) ++ [MySpace 体系结构](33.md) ++ [扩展 Digg 和其他 Web 应用程序](34.md) ++ [Digg 建筑](35.md) ++ [在 Amazon EC2 中部署大规模基础架构的六个经验教训](36.md) ++ [Wolfram | Alpha 建筑](37.md) ++ [为什么 Facebook，Digg 和 Twitter 很难扩展？](38.md) ++ [全球范围扩展的 10 个 eBay 秘密](39.md) ++ [BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展](40.md) ++ [《 FarmVille》如何扩展以每月收获 7500 万玩家](41.md) ++ [Twitter 计划分析 1000 亿条推文](42.md) ++ [MySpace 如何与 100 万个并发用户一起测试其实时站点](43.md) ++ [FarmVille 如何扩展-后续](44.md) ++ [Justin.tv 的实时视频广播架构](45.md) ++ [策略：缓存 404 在服务器时间上节省了洋葱 66％](46.md) ++ [Poppen.de 建筑](47.md) ++ [MocoSpace Architecture-一个月有 30 亿个移动页面浏览量](48.md) ++ [Sify.com 体系结构-每秒 3900 个请求的门户](49.md) ++ [每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训](50.md) ++ [Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长](51.md) ++ [扩展 BBC iPlayer 的 6 种策略](52.md) ++ [Facebook 的新实时消息系统：HBase 每月可存储 135 亿条消息](53.md) ++ [Pinboard.in Architecture-付费玩以保持系统小巧](54.md) ++ [BankSimple 迷你架构-使用下一代工具链](55.md) ++ [Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表](56.md) ++ [Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件](57.md) ++ [Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求](58.md) ++ [Node.js 成为堆栈的一部分了吗？ SimpleGeo 说是的。](59.md) ++ [堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量](60.md) ++ [Medialets 体系结构-击败艰巨的移动设备数据](61.md) ++ [Facebook 的新实时分析系统：HBase 每天处理 200 亿个事件](62.md) ++ [Microsoft Stack 是否杀死了 MySpace？](63.md) ++ [Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰](64.md) ++ [Facebook：用于扩展数十亿条消息的示例规范架构](65.md) ++ [Evernote Architecture-每天有 900 万用户和 1.5 亿个请求](66.md) ++ [TripAdvisor 的短](67.md) ++ [TripAdvisor 架构-4,000 万访客，200M 动态页面浏览，30TB 数据](68.md) ++ [ATMCash 利用虚拟化实现安全性-不变性和还原](69.md) ++ [Google+是使用您也可以使用的工具构建的：闭包，Java Servlet，JavaScript，BigTable，Colossus，快速周转](70.md) ++ [新的文物建筑-每天收集 20 亿多个指标](71.md) ++ [Peecho Architecture-鞋带上的可扩展性](72.md) ++ [标记式架构-扩展到 1 亿用户，1000 台服务器和 50 亿个页面视图](73.md) ++ [论文：Akamai 网络-70 个国家/地区的 61,000 台服务器，1,000 个网络](74.md) ++ [策略：在 S3 或 GitHub 上运行可扩展，可用且廉价的静态站点](75.md) ++ [Pud 是反堆栈-Windows，CFML，Dropbox，Xeround，JungleDisk，ELB](76.md) ++ [用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术](77.md) ++ [StackExchange 体系结构更新-平稳运行，Amazon 4x 更昂贵](78.md) ++ [DataSift 体系结构：每秒进行 120,000 条推文的实时数据挖掘](79.md) ++ [Instagram 架构：1400 万用户，1 TB 的照片，数百个实例，数十种技术](80.md) ++ [PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片](81.md) ++ [Etsy Saga：从筒仓到开心到一个月的浏览量达到数十亿](82.md) ++ [数据范围项目-6PB 存储，500GBytes / sec 顺序 IO，20M IOPS，130TFlops](83.md) ++ [99designs 的设计-数以千万计的综合浏览量](84.md) ++ [Tumblr Architecture-150 亿页面浏览量一个月，比 Twitter 更难扩展](85.md) ++ [Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL](86.md) ++ [Pixable Architecture-每天对 2000 万张照片进行爬网，分析和排名](87.md) ++ [LinkedIn：使用 Databus 创建低延迟更改数据捕获系统](88.md) ++ [在 30 分钟内进行 7 年的 YouTube 可扩展性课程](89.md) ++ [YouPorn-每天定位 2 亿次观看](90.md) ++ [Instagram 架构更新：Instagram 有何新功能？](91.md) ++ [搜索技术剖析：blekko 的 NoSQL 数据库](92.md) ++ [Pinterest 体系结构更新-1800 万访问者，增长 10 倍，拥有 12 名员工，410 TB 数据](93.md) ++ [搜索技术剖析：使用组合器爬行](94.md) ++ [iDoneThis-从头开始扩展基于电子邮件的应用程序](95.md) ++ [StubHub 体系结构：全球最大的票务市场背后的惊人复杂性](96.md) ++ [FictionPress：在网络上发布 600 万本小说](97.md) ++ [Cinchcast 体系结构-每天产生 1,500 小时的音频](98.md) ++ [棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容](99.md) ++ [棱镜更新：基于文档和用户的机器学习](100.md) ++ [Zoosk-实时通信背后的工程](101.md) ++ [WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量](102.md) ++ [史诗般的 TripAdvisor 更新：为什么不在云上运行？ 盛大的实验](103.md) ++ [UltraDNS 如何处理数十万个区域和数千万条记录](104.md) ++ [更简单，更便宜，更快：Playtomic 从.NET 迁移到 Node 和 Heroku](105.md) ++ [Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序](106.md) ++ [BigData 使用 Erlang，C 和 Lisp 对抗移动数据海啸](107.md) ++ [分析数十亿笔信用卡交易并在云中提供低延迟的见解](108.md) ++ [MongoDB 和 GridFS 用于内部和内部数据中心数据复制](109.md) ++ [每天处理 1 亿个像素-少量竞争会导致大规模问题](110.md) ++ [DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长](111.md) ++ [SongPop 在 GAE 上可扩展至 100 万活跃用户，表明 PaaS 未通过](112.md) ++ [Iron.io 从 Ruby 迁移到 Go：减少了 28 台服务器并避免了巨大的 Clusterf ** ks](113.md) ++ [可汗学院支票簿每月在 GAE 上扩展至 600 万用户](114.md) ++ [在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段](115.md) ++ [缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量](116.md) ++ [Facebook 的网络秘密](117.md) ++ [神话：埃里克·布鲁尔（Eric Brewer）谈银行为什么不是碱-可用性就是收入](118.md) ++ [一千万个并发连接的秘密-内核是问题，而不是解决方案](119.md) ++ [GOV.UK-不是你父亲的书库](120.md) ++ [缩放邮箱-在 6 周内从 0 到 100 万用户，每天 1 亿条消息](121.md) ++ [在 Yelp 上利用云计算-每月访问量为 1.02 亿，评论量为 3900 万](122.md) ++ [每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips](123.md) ++ [Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户，300K QPS，22 MB / S Firehose 以及发送推文](124.md) ++ [Salesforce Architecture-他们每天如何处理 13 亿笔交易](125.md) ++ [扩大流量的设计决策](126.md) ++ [ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行](127.md) ++ [如何制作无限可扩展的关系数据库管理系统（RDBMS）](128.md) ++ [Bazaarvoice 的架构每月发展到 500M 唯一用户](129.md) ++ [HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息](130.md) ++ [NYTimes 架构：无头，无主控，无单点故障](131.md) ++ [接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放，喜欢和更多内容](132.md) ++ [Google 如何备份 Internet 和数十亿字节的其他数据](133.md) ++ [从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧](134.md) ++ [AOL.com 体系结构如何发展到 99.999％的可用性，每天 800 万的访问者和每秒 200,000 个请求](135.md) ++ [Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构](136.md) ++ [使用 AWS，Scala，Akka，Play，MongoDB 和 Elasticsearch 构建社交音乐服务](137.md) ++ [大，小，热还是冷-条带，Tapad，Etsy 和 Square 的健壮数据管道示例](138.md) ++ [WhatsApp 如何每秒吸引近 5 亿用户，11,000 内核和 7,000 万条消息](139.md) ++ [Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理](140.md) ++ [关于 Disqus 的更新：它仍然是实时的，但是 Go 摧毁了 Python](141.md) ++ [关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明](142.md) ++ [在 PagerDuty 迁移到 EC2 中的 XtraDB 群集](143.md) ++ [扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序](144.md) ++ [一点点：建立一个可处理每月 60 亿次点击的分布式系统的经验教训](145.md) ++ [StackOverflow 更新：一个月有 5.6 亿次网页浏览，25 台服务器，而这一切都与性能有关](146.md) ++ [Tumblr：哈希处理每秒 23,000 个博客请求的方式](147.md) ++ [使用 HAProxy，PHP，Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构](148.md) ++ [MixRadio 体系结构-兼顾各种服务](149.md) ++ [Twitter 如何使用 Redis 进行扩展-105TB RAM，39MM QPS，10,000 多个实例](150.md) ++ [正确处理事情：通过即时重放查看集中式系统与分散式系统](151.md) ++ [Instagram 提高了其应用程序的性能。 这是如何做。](152.md) ++ [Clay.io 如何使用 AWS，Docker，HAProxy 和 Lots 建立其 10 倍架构](153.md) ++ [英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。](154.md) ++ [Wix 的 Nifty Architecture 技巧-大规模构建发布平台](155.md) ++ [Aeron：我们真的需要另一个消息传递系统吗？](156.md) ++ [机器：惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化](157.md) ++ [AWS 的惊人规模及其对云的未来意味着什么](158.md) ++ [Vinted 体系结构：每天部署数百次，以保持繁忙的门户稳定](159.md) ++ [将 Kim Kardashian 扩展到 1 亿个页面](160.md) ++ [HappyPancake：建立简单可扩展基金会的回顾](161.md) ++ [阿尔及利亚分布式搜索网络的体系结构](162.md) ++ [AppLovin：通过每天处理 300 亿个请求向全球移动消费者进行营销](163.md) ++ [Swiftype 如何以及为何从 EC2 迁移到真实硬件](164.md) ++ [我们如何扩展 VividCortex 的后端系统](165.md) ++ [Appknox 架构-从 AWS 切换到 Google Cloud](166.md) ++ [阿尔及利亚通往全球 API 的愤怒之路](167.md) ++ [阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分](168.md) ++ [为社交产品设计后端](169.md) ++ [阿尔及利亚通往全球 API 第 3 部分的愤怒之路](170.md) ++ [Google 如何创造只有他们才能创造的惊人的数据中心网络](171.md) ++ [Autodesk 如何在 Mesos 上实施可扩展事件](172.md) ++ [构建全球分布式，关键任务应用程序：Trenches 部分的经验教训 1](173.md) ++ [构建全球分布式，关键任务应用程序：Trenches 第 2 部分的经验教训](174.md) ++ [需要物联网吗？ 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式](175.md) ++ [Uber 如何扩展其实时市场平台](176.md) ++ [优步变得非常规：使用司机电话作为备份数据中心](177.md) ++ [在不到五分钟的时间里，Facebook 如何告诉您的朋友您在灾难中很安全](178.md) ++ [Zappos 的网站与 Amazon 集成后冻结了两年](179.md) ++ [为在现代时代构建可扩展的有状态服务提供依据](180.md) ++ [细分：使用 Docker，ECS 和 Terraform 重建基础架构](181.md) ++ [十年 IT 失败的五个教训](182.md) ++ [Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售](183.md) ++ [整个 Netflix 堆栈的 360 度视图](184.md) ++ [Wistia 如何每小时处理数百万个请求并处理丰富的视频分析](185.md) ++ [Google 和 eBay 关于构建微服务生态系统的深刻教训](186.md) ++ [无服务器启动-服务器崩溃！](187.md) ++ [在 Amazon AWS 上扩展至 1100 万以上用户的入门指南](188.md) ++ [为 David Guetta 建立无限可扩展的在线录制活动](189.md) ++ [Tinder：最大的推荐引擎之一如何决定您接下来会看到谁？](190.md) ++ [如何使用微服务建立财产管理系统集成](191.md) ++ [Egnyte 体系结构：构建和扩展多 PB 分布式系统的经验教训](192.md) ++ [Zapier 如何自动化数十亿个工作流自动化任务的旅程](193.md) ++ [Jeff Dean 在 Google 进行大规模深度学习](194.md) ++ [如今 Etsy 的架构是什么样的？](195.md) ++ [我们如何在 Mail.Ru Cloud 中实现视频播放器](196.md) ++ [Twitter 如何每秒处理 3,000 张图像](197.md) ++ [每天可处理数百万个请求的图像优化技术](198.md) ++ [Facebook 如何向 80 万同时观看者直播](199.md) ++ [Google 如何针对行星级基础设施进行行星级工程设计？](200.md) ++ [为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事，以及 Tarantool 与此相关的内容](201.md) ++ [The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购](202.md) ++ [Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入](203.md) ++ [从将 Uber 扩展到 2000 名工程师，1000 个服务和 8000 个 Git 存储库获得的经验教训](204.md) ++ [QuickBooks 平台](205.md) ++ [美国大选期间城市飞艇如何扩展到 25 亿个通知](206.md) ++ [Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题](207.md) ++ [AdStage 从 Heroku 迁移到 AWS](208.md) ++ [为何将 Morningstar 迁移到云端：降低 97％的成本](209.md) ++ [ButterCMS 体系结构：关键任务 API 每月可处理数百万个请求](210.md) ++ [Netflix：按下 Play 会发生什么？](211.md) ++ [ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务](212.md) ++ [每天为 1000 亿个事件赋予意义-Teads 的 Analytics（分析）管道](213.md) ++ [Auth0 体系结构：在多个云提供商和地区中运行](214.md) ++ [从裸机到 Kubernetes](215.md) ++ [Egnyte Architecture：构建和扩展多 PB 内容平台的经验教训](216.md) ++ [缩放原理](217.md) ++ [TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件](218.md) ++ [Tinder：最大的推荐引擎之一如何决定您接下来会看到谁？](219.md) ++ [如何使用微服务建立财产管理系统集成](220.md) ++ [Egnyte 体系结构：构建和扩展多 PB 分布式系统的经验教训](221.md) ++ [Zapier 如何自动化数十亿个工作流自动化任务的旅程](222.md) ++ [Jeff Dean 在 Google 进行大规模深度学习](223.md) ++ [如今 Etsy 的架构是什么样的？](224.md) ++ [我们如何在 Mail.Ru Cloud 中实现视频播放器](225.md) ++ [Twitter 如何每秒处理 3,000 张图像](226.md) ++ [每天可处理数百万个请求的图像优化技术](227.md) ++ [Facebook 如何向 80 万同时观看者直播](228.md) ++ [Google 如何针对行星级基础设施进行行星级工程设计？](229.md) ++ [为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事，以及 Tarantool 与此相关的内容](230.md) ++ [The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购](231.md) ++ [Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入](232.md) ++ [从将 Uber 扩展到 2000 名工程师，1000 个服务和 8000 个 Git 存储库获得的经验教训](233.md) ++ [QuickBooks 平台](234.md) ++ [美国大选期间城市飞艇如何扩展到 25 亿条通知](235.md) ++ [Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题](236.md) ++ [AdStage 从 Heroku 迁移到 AWS](237.md) ++ [为何将 Morningstar 迁移到云端：降低 97％的成本](238.md) ++ [ButterCMS 体系结构：关键任务 API 每月可处理数百万个请求](239.md) ++ [Netflix：按下 Play 会发生什么？](240.md) ++ [ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务](241.md) ++ [每天为 1000 亿个事件赋予意义-Teads 的 Analytics（分析）管道](242.md) ++ [Auth0 体系结构：在多个云提供商和地区中运行](243.md) ++ [从裸机到 Kubernetes](244.md) ++ [Egnyte Architecture：构建和扩展多 PB 内容平台的经验教训](245.md) diff --git a/docs/246.md b/docs/1.md similarity index 100% rename from docs/246.md rename to docs/1.md diff --git a/docs/10.md b/docs/10.md index b5c4b72..4833a53 100644 --- a/docs/10.md +++ b/docs/10.md @@ -1,75 +1,14 @@ -# AdStage 从 Heroku 迁移到 AWS +# Joost 网络架构 -> 原文： [http://highscalability.com/blog/2017/5/1/the-adstage-migration-from-heroku-to-aws.html](http://highscalability.com/blog/2017/5/1/the-adstage-migration-from-heroku-to-aws.html) +> 原文： [http://highscalability.com/blog/2007/9/7/joost-network-architecture.html](http://highscalability.com/blog/2007/9/7/joost-network-architecture.html) -![](img/222acfea60c08f75dd8f5c824f121167.png) +Joost 的网络架构师 Colm MacCarthaigh 在 2007 年 4 月 3 日于曼彻斯特举行的英国网络运营商论坛会议上向[做了本次演讲](http://www.uknof.org.uk/uknof7/MacCarthaigh-Joost.pdf)。 -*这是 AdStage 网站可靠性工程负责人 [G Gordon Worley III](https://www.linkedin.com/in/gworley3/) 的来宾[重新发布](https://medium.com/adstage-engineering/migrating-from-heroku-to-aws-our-story-80084d31025e)。* +我没有在上面的文章中看到链接。 但是我有 [http://www.royans.net/files/MacCarthaigh-Joost.pdf](这里有一个副本 [http://www.royans.net/files /MacCarthaigh-Joost.pdf](http://www.royans.net/files/MacCarthaigh-Joost.pdf) -我在 2013 年秋季加入 [AdStage](https://medium.com/@adstage) 时，我们已经在 Heroku 上运行了。 这是显而易见的选择：超级容易上手，比全尺寸虚拟服务器便宜，并且足够灵活以随着我们的业务发展。 成长，我们做到了。 Heroku 让我们仅专注于构建引人注目的产品，而不会分散管理基础结构，因此，到 2015 年末，我们已同时运行数千个 dynos（容器）以跟上我们的客户。 +我在 Joost 论坛上链接了 Colm 的演示视频。 -我们需要所有这些测功机，因为在后端，我们看起来很像[细分](https://medium.com/@segment)，并且像它们一样，我们的许多成本[与用户数量](https://segment.com/blog/the-million-dollar-eng-problem/)成线性比例。 以 25 美元/ dyno /月的价格计算，加上其他技术成本，到 2016 年中期，我们的年度基础设施支出将突破 100 万美元，而这占了 COGS 的很大比例，因此要花费数年才能实现盈利。 坦率地说，这种情况是不可持续的。 工程团队开会讨论了我们的选择，一些快速计算表明我们为 Heroku 的便利每月要支付超过 10,000 美元，而类似资源将直接在 AWS 上花费。 如果我们从 Heroku 迁移，那足以证明工程师专职在基础架构上工作，因此我的任务是成为我们的第一位运营负责人，并带头进行向 AWS 的迁移。 +[http://www.scaryideas.com/video/2362/](http://www.scaryideas.com/video/2362/) -这也是一个很好的时机，因为 Heroku 已成为我们最大的限制。 我们的工程团队采用了[看板](https://en.wikipedia.org/wiki/Kanban_%28development%29)方法，因此理想情况下，我们会不断产生从构思到完成的故事。 不过，当时我们正在生成大量正在进行的工作，这些工作通常会阻塞我们的发布渠道。 进行质量检查的工作很慢，并且经常被送回以进行错误修复。 “ [在我的计算机](https://jcooney.net/archive/2007/02/01/42999.aspx)上正常工作”的情况经常出现，但是当暴露在我们的暂存环境中时会失败。 由于 AdStage 是写在不同技术堆栈上的相互依赖的服务的复杂组合，因此每个开发人员都很难使其工作站与生产保持最新状态，这也使得部署到分阶段和生产过程很缓慢，需要大量的人工干预 。 但是，我们在此问题上别无选择，因为我们不得不将每个服务都部署为自己的 Heroku 应用程序，从而限制了自动化的机会。 我们迫切需要找到一种替代方法，使我们能够自动化部署并为开发人员提供更早的访问可靠测试环境的机会。 - -因此，除了通过迁移 Heroku 削减成本外，我们还需要清除质量检查约束。 否则，我可以自由地设计我们的 AWS 部署，只要它以最少的代码更改即可运行我们所有的现有服务，但我添加了一些需求： - -* **简单的系统管理** ：我以前使用过 Chef 等工具，并希望避免从头开始频繁重建系统的容易出错的过程。 我想通过登录机器并运行命令来更新机器。 -* **无聊** ：我想使用已知有效的“无聊”技术，而不是尝试一些新技术来解决其问题。 我想将风险集中在业务逻辑而不是基础架构中。 -* **零停机时间** ：在 Heroku 上进行部署往往会导致我们的用户遇到“漏洞”，原因是某些用户请求花费的运行时间比 Heroku 允许的连接耗用时间更长。 我希望能够消除这些斑点。 -* **回滚** ：如果部署出现问题，我希望能够退出部署并使用最新的已知工作版本恢复服务。 -* **有限的复杂度** ：我将是唯一一个专职构建和维护我们的基础架构的人，因此我需要确定项目的范围以适应需求。 - -知道 [Netflix](https://medium.com/@NetflixTechBlog) [设法通过](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)[在 AWS 上运行](http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html)数十亿美元的业务，没有比亚马逊的机器映像和自动缩放组更完美，我决定遵循他们的可靠方法，但绝对没有 意味着“性感”的方法：构建机器映像，使用它在自动伸缩组中创建实例，将其放在弹性负载均衡器之后，并将负载均衡器连接到 DNS 记录，以使我们的客户以及彼此可以访问它们。 - -因此，我着手构建我们的 AWS 部署策略。 - -### 成为 AWS Sumo - -在对系统进行工程设计时，我喜欢花很多时间在进行设计之前先仔细考虑并测试假设。 Rich Hickey 将此称为[吊床驱动的开发](https://www.youtube.com/watch?v=f84n5oFoZBc)。 - -我们的办公室没有吊床，所以我使用了[相扑躺椅](https://www.sumolounge.com/)。 - -![](img/8e7035455cd1d066981cf95862e69d34.png) - -在 2016 年春季的几个月中，我思考并思考并整理了 AWS 部署系统的基础。 它的架构看起来像这样： - -![](img/0c10e55ee443acef0a7f6bd72b5472bf.png) - -它的核心是我们所谓的 AdStage 统一图片。 此机器映像用于为所有环境（从开发和测试到过渡和生产）中的所有服务创建实例。 它上面是我们所有存储库的副本以及运行它们所需的依赖项。 根据一些实例标签的值，实例可以以不同的方式出现以反映其用法。 - -例如，当一个实例以“审阅”模式出现时，所有服务及其从属数据库在该实例上一起运行并相互通信。 这样，进行开发和质量检查的工程师就可以访问运行任意代码版本的完整堆栈的隔离版本。 他们在这些评论框上所做的任何操作都不会影响登台或制作，也不会与其他评论框进行交互，从而完全消除了我们以前的质量检查/登台限制。 另外，只要审核框通过质量检查，就可以对其进行成像，并将该图像部署到生产中。 - -之所以可行，是因为当实例以“登台”或“生产”模式启动时，它还会告知其应运行的服务。 这是由实例从其自动伸缩组继承的标签确定的，这使我们可以启动运行相同代码的实例队列，以分散客户的负载。 对于服务于 Web 请求的自动扩展组，它们连接到弹性负载均衡器，该负载均衡器在我们的服务器之间平均分配请求。 负载平衡器为我们提供了一个固定点，我们可以在该固定点上平稳地交换实例，从而实现零停机时间部署，并使回滚就像将旧版本的统一映像保留在备用数据库中一样容易交换。 - -但是，我们使用的 AWS 资源无法完全协调自身，因此我们编写了一个使用 AWS API 来实现的 Ruby [Thor](https://github.com/erikhuda/thor) 应用程序。 它负责启动审阅框，构建映像，然后将这些映像部署到暂存和生产环境中。 它会在将负载均衡器切换到新版本之前自动验证部署是否正常运行，如果部署完成后检测到问题，则会建议回滚。 它还使用一些巧妙的技巧来协调多个部署并锁定关键资源，以防止多个工程师破坏彼此的部署，因此任何人都可以启动部署，尽管如果这会引起冲突，他们将被停止。 - -这涵盖了我们的所有需求：成像实例使系统管理变得容易，设置很无聊且被广泛使用，部署过程固有的停机时间为零，支持回滚的部署是自动化的，并且在少于 1500 的情况下并不是很复杂 而且，由于它解决了 QA 约束，并且据我们估计将节省 10,000 美元的运营支出，因此剩下的只是计划从 Heroku 到 AWS 的实时迁移。 - -### 实时迁移 - -2016 年 7 月是旧金山的典型节日。 大部分时间，雾气和寒冷的空气使我一直在里面工作，而在我们办公室对面的街道上，准备不足的游客在[龙门](https://www.lonelyplanet.com/usa/san-francisco/attractions/dragons-gate/a/poi-sig/383985/361858)上自拍时发抖。 同样，因为一切都准备从 Heroku 迁移到 AWS，所以我们要做很多工作。 - -我们的客户依靠我们来管理他们的广告活动，自动化他们的广告支出并报告他们的广告效果。 当我们陷入困境时，它们又陷入了直接通过网络界面手动创建和更新广告的黑暗时代。 当我们切换到 AWS 时，他们负担不起我们离线的费用，因此我们将不得不进行实时迁移。 或至少与合理生活一样。 - -我们实施了 1 周的代码冻结，并在星期六的早晨找到了 1 小时的窗口，那时我切换了数据库和其他在运行时不易移动的服务，而 AdStage 进入维护模式。 在准备过程中，我们已经进行了登台系统的迁移，并编写了一部剧本，可以用来削减生产。 我使用代码冻结功能花了一周时间来调整 AWS 部署以匹配 Heroku 部署。 周六上午一切似乎都很好。 我们失败了，我切断了数据库，然后重新启动了 AdStage。 我花了整整一天的时间看监视器，并靠近键盘，以防万一发生任何问题，但是什么也没做。 那天晚上我睡着了，以为一切都很好。 - -在一个 la 懒的星期天早晨之后，我开始在下午收到一些警报，提示我们的进口商正在备份。 当我们研究该问题时，问题很快就变得显而易见：尽管名义上拥有更多的计算资源，但在某种程度上，我们在 AWS 上的 CPU 数量要少于 Heroku。 结果，我们无法跟上，并且每小时我们都越来越落后。 为了避免队列溢出，我们不得不降低导入的频率，最终我们不得不重新打开 Heroku 应用程序以与 AWS 一起运行以跟上工作量。 这与省钱相反。 - -我们发现，Heroku 一直在告诉我们一个幸福的谎言。 官方每个 dyno 仅获得 2 个 [ECU](https://aws.amazon.com/ec2/faqs/#What_is_an_EC2_Compute_Unit_and_why_did_you_introduce_it) ，但实际情况是，由于我们 Heroku 上的邻居没有充分利用它们的全部份额，我们接近了 6 个。 这意味着我们的 AWS 实例数量太小了 3 倍，尽管 Heroku 实际上便宜得多！ 如果只有一种方法可以为更多实例支付更少的费用…… - -那就是我们开始使用竞价型实例的时候。 我们曾考虑过使用它们，因为它们的价格约为按需价格的 1/10，但是它们存在一定的风险，因为如果您的底价低于拍卖价，它们可以随时终止。 幸运的是，这种情况很少发生，否则自动伸缩组会为您管理点实例的复杂性。 另外，如果备份临时扩展组使用按需部署的按需实例，则很容易，如果我们暂时无法获得足够的竞价型实例来满足需求，则可以通过单个命令进行扩展。 我们最终能够将约 80％的机队转换为现场实例，尽管使用的资源比原始预期多了 3 倍，但我们的成本却降低到了预期目标之内。 - -### 结论 - -除了我们对容量的意外低估外，从 Heroku 切换到 AWS 的过程也很顺利。 不过请不要误会我的意思：这是值得做的，因为我们已经达到了将我们的一些基础设施运营纳入内部的经济规模才有意义。 如果我们不花至少一名工程师的薪水来购买可以通过转用 AWS 节省的运营成本，并且如果基础架构没有成为核心能力，那么我们将坚持使用 Heroku 并让那个人（我！）来工​​作 在对我们的业务更重要的事情上。 只是由于经济和流程的变化，从 Heroku 迁移到 AWS 成为了我们的故事的一部分。 - -Heroku 在 AWS 上运行，因此您不必进行过多的迁移就可以减少中间商。 - -...或者您雇用知道如何正确运行数据中心的人员。 - -感谢您的帖子。 非常有趣，只是有几个问题：图像如何获得其初始配置？ 您提到要避免使用 Chef / Puppet 之类的东西，但是大概您仍然需要一些可重复的过程来使用初始配置来构建 AMI。 那是雷神应用程序的功能吗？ - -您应该尝试进行性能调整，例如 JVM 调整，线程池调整等，以降低基础架构成本。 - -似乎没有这么多麻烦就节省了很多。 您节省了全职人员成本，但是在 AWS 上通常需要 DevOps 成本，在 Heroku 中，Dev 团队可以解决。 放大/缩小测功机与 EC2 相比，哪一个更容易？ \ No newline at end of file +幻灯片是一样的。 \ No newline at end of file diff --git a/docs/100.md b/docs/100.md index a62f6a8..fa00b4d 100644 --- a/docs/100.md +++ b/docs/100.md @@ -1,154 +1,26 @@ -# Tumblr：哈希处理每秒 23,000 个博客请求的方式 +# 棱镜更新：基于文档和用户的机器学习 -> 原文： [http://highscalability.com/blog/2014/8/4/tumblr-hashing-your-way-to-handling-23000-blog-requests-per.html](http://highscalability.com/blog/2014/8/4/tumblr-hashing-your-way-to-handling-23000-blog-requests-per.html) +> 原文： [http://highscalability.com/blog/2012/8/1/prismatic-update-machine-learning-on-documents-and-users.html](http://highscalability.com/blog/2012/8/1/prismatic-update-machine-learning-on-documents-and-users.html) -![](img/b53e7c03eb181dee4f3635b07ef4a84e.png) +![](img/70ac891b8ff6179d45189f15eaa4af67.png) -*这是 Tumblr 的 SRE 工程师 [](http://michael.tumblr.com/) [Michael Schenck](http://michael.tumblr.com/) 的特邀帖子。* +在 [Prismatic Architecture-使用社交网络上的机器学习确定您应该在网络上阅读的内容](http://highscalability.com/blog/2012/7/30/prismatic-architecture-using-machine-learning-on-social-netw.html)的同时，Jason Wolfe 甚至面对漫长的夜晚将 iPhone 应用程序投入使用而感到疲倦的感觉， 英勇地同意谈论 Primatic 的机器学习方法。 -在 Tumblr，博客（或 Tumblelog）是我们互联网上访问量最高的面孔之一。 tumblelogs 最方便的方面之一是其高度可缓存的特性，这是奇妙的，因为 Tumblr 网络为我们的用户提供了很高的视图/发布比率。 就是说，扩展边界代理层（更不用说缓存层）对满足所有这些请求是必需的，这并非完全简单。 +文档和用户是 Prismatic 应用 ML（机器学习）的两个领域： -本文介绍了负责博客服务的外围部分的体系结构，这是我们流量更大的外围端点之一。 +### 文件 ML -这是我们的方法。 +* 给定一个 HTML 文档： + * 了解如何提取页面的主要文本（而不是侧边栏，页脚，注释等），标题，作者，最佳图像等 + * 确定相关功能（例如，文章的主题，主题等） +* 其中大多数任务的设置非常典型。 使用其他机器上的大批作业对模型进行训练，这些机器从 s3 读取数据，将学习到的参数文件保存到 s3，然后在摄取管道中从 s3 读取（并定期刷新）模型。 +* 流出系统的所有数据都可以反馈到该管道中，这有助于了解更多有趣的内容，并随着时间的推移从错误中学习。 +* 从软件工程的角度来看，Prismatic 编写的最有趣的框架之一是“ flop”库，该库实现了最先进的 ML 训练和推理代码，看起来与精美的普通 Clojure 代码非常相似，但是可以编译（使用 宏的魔力）到低级数组操作循环，这些循环与 Java 一样接近金属而无需借助 JNI。 +* 与相应的 Java 相比，该代码可以紧凑和易于阅读，并且执行速度基本相同。 +* 创建[快速运行的故事聚类组件](http://blog.getprismatic.com/blog/2012/4/17/clustering-related-stories.html)付出了很多努力。 -### 统计信息 +### 用户 ML -* 共有 278 名员工，团队中有 6 名员工负责 Tumblr 的所有外围（Perimeter-SRE），包括一名经理。 - -* 超过 2800 台服务器中，不到 20％的服务器用于博客服务功能 - -* 每秒（峰值）超过 23,000 个博客请求 - -* 每秒（峰值）超过 6,500 个博客缓存清除事件 - -* 超过 1.96 亿个博客 - -* 超过 930 亿个帖子 - -### 平台 - -* [HAProxy](http://www.haproxy.org/) - -* [清漆](https://www.varnish-cache.org/) - -* [鸟](http://bird.network.cz/) - -### 我们在哪里-基于地图的分区 - -在早期，我们只需要一台活动和一台备用代理服务器以及清漆节点。 两者都很容易管理，监视和高度可用。 - -但是，由于要满足所有用户请求，因此将达到容量限制，并且由于流行而导致停机前，必须准备好下一步步骤（即使不是理想的部署）。 - -### 超出单个代理节点 - -超出单个 活动 代理服务器的数量非常普遍，并且通常涉及 DNS。 像循环 A 记录这样基本的东西可能会满足您的需求，但通常值得花额外的钱进行健康检查 GSLB 配置（即使您只有一个地理位置）。 - -DNS 的缺点是，尽管名称服务器将以相当均匀的速率对每个 IP 进行响应，但不能保证每个查找都将用于相同数量的请求。 用户 A 可能在一分钟内向解析的 IP 发出 10 个请求，而机器人 B 可能在同一分钟内发出 100 个请求。 如果您有两个 IP，则用户 A 获得一个 IP，而机器人 B 获得另一个 IP，而它们是仅有的两个发出请求的客户端，那么您的一个代理的请求速率是另一个的 10 倍。 - -较低的 TTL 可以减轻此影响，以便 30 秒 TTL 可以平衡两个代理之间的那 110 个请求。 在最初的 30 秒内，用户 A 将转到代理 P1，而机器人 B 将转到代理 P2。 然后，他们的下一个解决方案可能会交换 IP，以便用户 A 将其请求发送到代理 P2，而机器人 B 将其请求发送到代理 P1。 在该分钟窗口结束时，每个代理将处理大约 60 个请求。 TTL 较低的缺点是查找更多，因此 DNS 成本较高（但 DNS 通常是您较便宜的第三方服务之一）。 - -### 超出单个清漆节点 - -虽然 DNS 可以为您增加代理层的时间，但是缩放清漆要复杂一些。 即使您使用单个清漆节点的容量限制围绕请求并发进行，您也不希望简单地在循环中添加两个清漆节点。 这降低了缓存命中率，清除了更多的资源/时间，并且实际上并没有增加缓存的工作量（仅复制它）。 - -超出单个清漆节点的最简单迭代是 静态分区 。 这涉及确定您的唯一标识符，并在两个清漆节点之间划分此空间。 - -对于 Tumblelogs，这是博客的主机名。 由于 DNS 不区分大小写，因此您只需要担心 40 个字符即可。 字母数字（a-z 和 0-9）和四个允许的字符（-_。〜）。 因此，对于两个清漆节点，博客主机名在这两个缓存节点之间被分割（在第一个字符上）。 - -### 均匀分布的分区-通过一致的哈希 - -前面的两个示例（DNS 循环和静态分区）都是朝着正确方向迈出的一步，但是在分区方面却提供了非常粗糙的粒度。 在足够小的规模上，这种粒度不一定是有问题的，但是随着您的流量开始增长，方差变得更加明显。 结果，减少最不热和最热节点处理的流量差异变得越来越重要。 这就是一致性哈希真正可以发挥作用的地方。 - -### 分区代理流量 - -如果您的服务器所处的环境可以影响服务器前面的路由器，用户和代理服务器之间的路由器的路由表，那么您可以利用等价的多 -路径路由（ECMP）。 ECMP 使您能够将代理视为同一哈希环中的多个切片，然后在这些切片之间映射请求者。 - -这是通过通知到特定目标 IP（高可用性 IP）的多个路径（代理服务器）的路由基础结构来实现的。 然后，ECMP 将对请求源进行哈希处理，以确定哪个代理应接收此请求会话的数据包。 典型的 ECMP 实现提供第 3 层（仅 IP）和第 3 + 4 层（IP：端口）哈希选项。 第 3 层意味着来自特定 IP 的所有请求将转到特定的代理，这可能有助于调试，但与使用单个 NAT IP 的大型网络不平衡。 第 3 + 4 层通常提供最佳的分发，但是调试特定的客户端变得更具挑战性。 - -有多种方法可以 通知 路由器多个路径，但是我建议使用 OSPF 或 iBGP 进行动态路由通告。 一个人只需要在环回接口上侦听高度可用的 IP，启用内部路由以及将自己的 IP 作为下一跃点广告到该高度可用的 IP。 我们发现 BIRD 提供了一种轻巧可靠的方式来执行来自代理的路由广告。 - -### 划分清漆流量 - -Tumblelog 通过其完全限定的域名（FQDN）进行标识，因此，博客的所有 URI 路径将始终在该博客 FQDN 下找到。 Tumblelog 的大部分是 tumblr.com 的子域，例如 [engineering.tumblr.com](http://engineering.tumblr.com/) ，但是我们也支持用户携带自己的自定义域名 。 - -考虑各种 FQDN 时，很明显，TLD 的变体数量最少，然后是域名（特别是由于绝大多数是 tumblr.com），然后是子域。 因此，我们最重要的位出现在可变长度字符串的最左侧。 - -### 了解问题域 - -![](img/acbf9820b55f36b5e6df32353fdd183a.png) - -* 完美-演示将散列函数应用于我们的测试数据集时，其散列函数是否为 完美 - -* constant_hdr-主机标头上的一致性哈希（最佳现实结果） - -* constant_hdr_use_domain_only-基本域名（即 tumblr.com 或 foo.net）上的一致性哈希，只有两个阵营 tumblr.com 和所有其他域名 - -* mapbased_firstchar-将主机标头的第一个字符映射到清漆节点（我们的原始静态分区实现） - -* mapbased_hdr-基于主机标头的映射 - -虽然一致的散列显然是 tumblelog FQDN 的最平均分布的领先者，但是我们接着确定散列函数是否合适。 默认情况下，HAProxy 使用 SDBM 哈希函数。 但是，在进一步研究后，通过比较 SDBM，CRC，MD5，DJB2 等，我们确定 DJB2 提供了更好的分布。 这导致我们向 HAProxy 提交了补丁，以使哈希函数可配置（有关更多信息，请参见“感谢”部分）。 - -### 比较静态分区和一致性哈希 - -![](img/92b6bf9ab0a831619ca9f08d88d90435.png) - -这显示了在移至最佳匹配哈希函数之前和之后，每个清漆节点每秒请求之间的方差变化。 - -### 其他注意事项 - -### 节点增长 - -在任一模型中，节点增长将意味着键空间移位，从而导致缓存失效。 在一致的哈希模型中，预测将失效的键的百分比要容易得多。 基本上为 1 / N（N 是添加新节点之前的缓存节点数）。 使用静态分区模型，除非您对要从中获取键空间的节点的请求进行分析，否则最糟糕的情况是小于或等于键上键的总百分比。 您从中获取键空间的节点。 - -### 节点故障 - -使用静态分区时，除非您提供故障转移选项，否则单节点故障将导致无法访问 1 / N 密钥。 HAProxy 确实允许您拥有一个备用节点，但是现在您可以决定了。 每个密钥空间有 2N 个缓存节点（一个活动，一个备用）或共享的备用节点。 一种极端情况是 浪费 占硬件的 50％，其中频谱的另一端（所有活动节点之间共享 1 个备用节点）意味着两个故障节点导致备用 支持其他活动节点的密钥空间的 2 倍。 - -使用一致的哈希，将自动处理节点故障。 删除一个节点后，将移动 1 / N 个键（导致 1 / N 个键无效），并且每个剩余的活动节点的键空间均匀增加。 - -### 正在清除缓存 - -将清除请求发送到单个清漆节点很容易，但是从多个清漆节点清除也应该很容易。 不必使代理服务器和清除服务器保持同步，最简单的方法是通过同一代理服务器发送所有清除请求。 - -拒绝来自非本地 IP 空间的清除尝试非常重要，以防止任何恶意的批量清除。 - -### 获得的经验教训 - -* 您知道尚未回答的问题的答案。 面对扩展挑战时，请不要忽视您已经在其他地方使用的模式。 - -* 通过简单扩展。 在短期内可能会增加复杂性以克服可伸缩性挑战，但最终会赶上您。 - -* 了解您的哈希函数。 您使用的哈希函数与决定如何处理哈希值同样重要。 - -* 降级，不失败。 建议您的代理人监视自己达到后端的能力。 如果不能，则不要停止发布路由，而只是发布非优先级路由（例如，使用 OSPF 会增加路径成本）。 这样，如果所有后端都无法正常运行，您仍然可以提供错误页面，而不是无法访问。 - -### 谢谢 - -## * [Blake Matheny](http://tumblr.mobocracy.net/) 和 [Andrew Terng](http://andrew.tumblr.com/) 进行了散列函数比较并为 HAProxy 创建了补丁。 - -* [Bhaskar Maddala](http://maddalab.tumblr.com/) 与 HAProxy 社区合作，以获取 [此功能已添加到 HAProxy 1.5 版本](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-hash-type) 。 - -* [Arnoud Vermeer](http://blog.arnoudvermeer.nl/) 和 [Aaron Prat](http://aaronprat.tumblr.com/) 与 ECMP / OSPF 流量分配有关。 - -## 相关文章 [ - -* [关于 HackerNews](https://news.ycombinator.com/item?id=8132473) -* [雅虎以 10 亿美元的价格收购了 Tumblr 架构](http://highscalability.com/blog/2013/5/20/the-tumblr-architecture-yahoo-bought-for-a-cool-billion-doll.html) -* [Tumblr Architecture-150 亿页面浏览量一个月，比 Twitter 难扩展](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) - -对于任何混乱，我们深表歉意，共有 278 位 Tumblr 员工。 - -负责 Tumblr 所有外围（Perimeter-SRE）的团队由 6 人组成（包括一名经理）。 - -本文介绍了负责博客服务的外围部分的体系结构，这是我们流量更大的外围端点之一。 - -对于那些不了解哈希的人来说，它会使您变得 O（1）复杂，并且比对普通 b 树数据库的搜索要快。 令人惊讶的结果，我想这就是您扩展 tumblr 之类的方式的原因：） - -非常有趣的文章。 -但是有一个问题：您提到 BIRT 是 IP 平衡器，尽管 Haproxy 也是平衡器，但是对于 TCP / HTTP 级别，不是 IP。 那么负载均衡人员到底是谁呢？ - -感谢您分享这个幕后或“后台”视图。 “ 1.96 亿个博客”数量巨大，接近 1000 亿个帖子表明这些博客已被实际使用，而不是像其他平台那样，通常一旦注册就此后一直处于闲置状态。 - -从网络工程的角度来看，这非常有趣。 我猜想您的 HAProxy 框上正在运行 BIRD，然后将散列的流量平衡到 Varnish？ 是否还可以通过 Varnish 服务器从您的边缘路由器提供网络图？ 谢谢！ \ No newline at end of file +* 猜测用户对社交网络数据感兴趣的内容，并使用应用内的显式信号（+ /删除）完善这些猜测。 +* 使用显式信号的问题很有趣，因为用户输入应该很快反映在其提要中。 如果用户连续从给定的发布者中删除了 5 篇文章，请立即停止向他们展示该发布者的文章，而不是明天。 这意味着没有时间在所有用户上运行另一个批处理作业。解决方案是在线学习：立即根据用户提供给我们的观察结果更新用户模型。 +* 用户交互事件的原始流已保存。 这样可以在以后发生机器故障或类似情况时通过原始数据上的松散写回缓存丢失任何数据，从而在以后的原始事件中重新运行用户感兴趣的 ML。 在线学习中的漂移可以得到纠正，并且可以计算出更准确的模型。 \ No newline at end of file diff --git a/docs/101.md b/docs/101.md index 0871b1a..adafa8a 100644 --- a/docs/101.md +++ b/docs/101.md @@ -1,464 +1,60 @@ -# StackOverflow 更新：一个月有 5.6 亿次网页浏览，25 台服务器，而这一切都与性能有关 +# Zoosk-实时通信背后的工程 -> 原文： [http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html](http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html) +> 原文： [http://highscalability.com/blog/2012/8/27/zoosk-the-engineering-behind-real-time-communications.html](http://highscalability.com/blog/2012/8/27/zoosk-the-engineering-behind-real-time-communications.html) -![](img/85ffbec924f9896a08e0740e47a435dc.png) +![](img/efefbfdcf2cb4bd5b05bf84c461508eb.png) -Stack Overflow 的员工对于他们的工作以及原因仍然保持着开放的态度。 因此，该进行另一个[更新](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html)了。 堆栈溢出到底在做什么？ +*这是 [Peter Offringa 的来宾帖子，](http://www.linkedin.com/in/peteroffringa) [Zoosk](https://www.zoosk.com/) 的工程副总裁。 Zoosk 是一个拥有 5000 万会员的浪漫社交网络。* -构成[，StackExchange](http://stackexchange.com/) 的站点网络（包括 StackOverflow）在全球流量中排名第 54； 它们有 110 个站点，并且以每月 3 或 4 个的速度增长； 400 万用户； 4000 万个答案； 每月有 5.6 亿次网页浏览。 +当我们的会员可以实时互动时，他们会从 Zoosk 中获得最大的收获。 毕竟，用户建立的每个连接的另一端可能是将来的关系。 这种情况的刺激性和丰富性只能实时实现。 实时通信（RTC）的一般说明引用了促进这些交互的 Zoosk 服务套件。 这些通信使用 XMPP 协议进行传递，该协议还为其他流行的即时消息传递产品提供了支持。 Zoosk 成员在三种不同的交互中体验实时通信： -这只有 25 台服务器。 为了一切。 那就是高可用性，负载平衡，缓存，数据库，搜索和实用程序功能。 全部都有相对少数的员工。 现在就是质量工程。 +* **存在**。 当成员主动连接到 Zoosk RTC 基础结构时，其公开身份显示为“可用”。 如果它们闲置了一段时间，它们的状态将转换为“离开”。 当他们关闭或断开客户端应用程序的连接时，其状态会自动变为“离线”。 成员还可以选择对其他用户“不可见”。 此选项允许他们保留在 Zoosk 服务上并查看其他在线成员，但不会在其他用户的花名册中出现。 +* **通知**。 重要的交互在视觉上被打包为“敬酒”，并附带短消息。 敬酒向用户表示事件，例如收到调情，查看其个人资料或与其他用户匹配。 Zoosk 服务利用这些通知包来通知客户端应用程序更新与 UI 相关的徽章的值，例如来自另一个用户的未读消息的数量。 +* **消息传递**。 如果两个用户同时在线，则他们可以以熟悉的“即时消息”聊天格式相互发送消息。 这些消息通过 RTC 基础结构实时传输。 如果用户将来使用其他客户端应用程序重新连接，则消息内容也将保留到数据库中，以供将来检索消息历史记录。 -此更新基于 Marco Cecconi 的 [StackOverflow](http://www.dev-metal.com/architecture-stackoverflow/) 的体系结构（视频）和 Nick Craver 的[进行 Stack Overflow](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/) 的体系结构。 此外，我还合并了来自各种来源的评论。 毫无疑问，某些细节已经过时了，就像我早在写这篇文章时所说的那样，但它仍然具有代表性。 +目前，这些通信已通过网络浏览器，iPhone 应用程序，iPad，Android 和可下载的桌面应用程序传递给 Zoosk 所有主要产品上的用户-Zoosk.com 网站和 Facebook 应用程序。 -堆栈溢出仍使用 Microsoft 产品。 Microsoft 基础架构可以正常运行且价格便宜，因此没有令人信服的理由进行更改。 SO 是务实的。 他们在合理的地方使用 Linux。 没有纯粹的动力来使所有 Linux 或保留所有 Microsoft。 那不会有效。 +### RTC 基础结构 -堆栈溢出仍使用放大策略。 网站上没有云。 由于其 SQL Server 装有 384 GB 的 RAM 和 2TB 的 SSD，AWS 会付出巨大的代价。 云还会降低它们的速度，从而更难优化和解决系统问题。 另外，SO 不需要水平扩展策略。 可以在横向扩展中使用的最大峰值负载没有问题，因为它们在正确调整系统大小方面非常成功。 +这些 RTC 服务是通过高性能和可扩展的基于 XMPP 的基础结构提供的。 由开源 Jabber 服务器 [Tigase](http://www.tigase.org) 支持的聊天服务是此服务的核心。 Tigase 用 Java 编写，我们的平台团队创建了许多自定义扩展来处理 Zoosk 特定的业务逻辑。 -因此，杰夫·阿特伍德（Jeff Atwood）的话似乎很：“硬件便宜，程序员昂贵”，这似乎仍然是该公司的绝大部分。 +Tigase 部署在基于 Linux 的标准 8 CPU 应用服务器类计算机上。 Tigase 服务器配置在成对的群集中，主要和次要节点通过负载平衡器进行管理。 所有连接一次都定向到主节点。 如果对主服务器的服务检查失败，则负载平衡器将立即开始将用户流量重定向到辅助服务器。 -Marco Ceccon 在演讲中说，在谈论体系结构时，您需要首先回答这个问题：正在解决哪种问题？ +这些成对的群集中有 18 个，每个群集可随时处理 4,000 至 8,000 个连接。 除了用于传输 XMPP 流量的套接字连接之外，Tigase 还包括一项用于支持 HTTP 上的 BOSH 连接的服务。 -首先是简单的部分。 StackExchange 做什么？ 它需要主题，在主题周围创建社区，并创建很棒的问答站点。 +BOSH 是我们允许网络浏览器浏览 Zoosk.com 和我们的 Facebook 应用程序以保持与 Tigase 的持久连接的协议。 我们的桌面应用程序和移动应用程序使用标准的 TCP-IP 套接字连接。 -第二部分涉及规模。 就像我们将看到的那样，StackExchange 的增长非常快，可以处理大量流量。 它是如何做到的？ 让我们来看看...。 +[![](img/f5fca2a57132c5608226dc08f283b7b8.png) ](http://farm9.staticflickr.com/8297/7872925374_a93ee99bf9_o.png) 全尺寸 -## 统计资料 +Tigase 服务器通过 Tigase 和客户端应用程序（Web 浏览器，移动设备，桌面应用程序）之间的持久连接实时进行实时传输。 Zoosk 的许多核心产品功能，包括搜索结果，配置文件视图和消息传递，都需要确保在所有客户端应用程序上几乎实时地反映这种状态。 为使此状态在 Zoosk 基础结构的其余部分中保持一致，用户数据库中的用户记录将更新以反映其当前的在线状态，包括其最新在线转换的时间戳。 -* StackExchange 网络有 110 个站点，并且每月以 3 或 4 的速度增长。 +用户的在线状态也存储在我们搜索基础架构的缓存中，以便搜索结果可以考虑在线状态。 Zoosk 搜索功能由一层 SOLR 服务器提供支持。 我们已经扩展了每个 SOLR 服务器，以包括一个 ehcache 实例来存储当前在线的那些用户。 通过称为在线状态管理器（OSM）的专用 Tigase 实例实时更新此在线状态缓存。 -* 400 万用户 +OSM 从主要的 Tigase 聊天服务器接收指示用户在线状态的自定义 XMPP 数据包，然后进行网络调用以更新每个 SOLR 服务器上的 ehcache 实例。 在高峰流量期间，每分钟大约有 8,000 个这些在线状态转换。 通过在 SOLR 索引之外维护此缓存，可以实时更新用户的状态，而与从主节点到从节点的定期索引复制快照分开。 然后，在查询时将用户的状态与搜索结果结合起来，以根据用户当前是否在线对结果进行过滤或排名。 搜索算法更喜欢在线用户，因为这会鼓励实时通信并为其他用户提供更丰富的体验。 +[ -* 800 万个问题 +核心 RTC 功能之外的用户与 Zoosk 服务的交互也可以触发业务逻辑，该逻辑会向连接的用户生成实时通知。 例如，如果另一个用户查看了我们的用户个人资料，或者接受了该用户的好友请求，我们希望立即将该操作通知我们的用户。 基于 PHP 的 Web 应用程序将触发异步作业，该异步作业将打开与 Tigase 服务器的网络连接，并将 XMPP 数据包传递到服务器，而自定义消息有效负载将为通知提供数据。 此数据包由 Tigase 处理，并路由到当前连接用户的客户端应用程序。 -* 4000 万答案 +然后，用户的客户端应用程序将处理此自定义数据包，并向用户显示适当的“祝酒”，或更新“徽章”，以反映特定功能指标的当前值（配置文件视图数，未读消息等）。 如果用户当时处于脱机状态，则 Tigase 将存储数据包，直到用户重新连接为止。 届时，它将自定义数据包传递给用户的客户端应用程序。 -* 作为全球排名第 54 的网络流量站点 +### 监视和测试 -* 同比增长 100％ +Zoosk 技术运营团队已经建立了多种方法来测试和监视 RTC 基础结构的运行状况，以确保响应能力和可用性。 这些测试主要涉及各种机制来从 Tigase 服务器收集性能数据，或模拟实际的用户交互。 如果特定的运行状况检查失败或性能数据超出既定阈值，则我们的 Nagios 安装将生成警报。 -* 每月 5.6 亿次网页浏览 +* **Tigase Monitor** -这是一个每 10 分钟在 cron 上运行的脚本。 它登录到所有主要的聊天服务器，并测试连接和状态传输。 它记录这些测试的结果，并将更新发送给 Nagios，以确定是否生成警报。 +* **Tigase 的性能指标**-这些内容涵盖了各种内部 Tigase 指标，包括执行关键功能的时间，消息计数，队列大小，内存消耗等。这些值每 2 分钟由临时统计收集一次 通过 XMPP 管理界面命令。 然后将这些度量传递到 Ganglia 进行绘图。 +* **商业智能报告**-脚本每小时检查一次与每个主 Tigase 服务器的活动连接数，以及它在前一个小时内传递的消息数。 该数据被加载到数据库中。 定制的 Excel 报告可以连接到该数据源，并提供具有易于比较的历史趋势的数据摘要视图。 +* **Tigase 测试套件**-这是一个无头 XMPP 客户端，它登录到每个 Tigase 服务器并模拟真实的交互。 然后，TTS 将记录其功能测试的结果，以供团队审核。 -* 在大多数工作日，高峰更像是 2600-3000 请求/秒。 编程是一种职业，意味着工作日比周末要忙得多。 +### [![](img/fe4a02128277bf91affecfdf14f5e31e.png) ](http://farm9.staticflickr.com/8296/7872943312_1d3a7026d0_o.png) 全尺寸 +下一步 -* 25 台服务器 +展望未来，我们将继续积极探索为 Zoosk 会员提供实时体验的新方法。 我们将在下个月向我们的移动 Web 应用程序（Touch）推出 RTC 支持。 交付 Zoosk 应用程序的其他设备或介质将类似地进行实时连接。 随着我们的成员增加主动连接到 Zoosk 应用程序的时间，我们计划增强基于 RTC 的功能，以促进成员之间的发现和通信。 -* 2 TB SQL 数据全部存储在 SSD 上 +这里的图形（可能是无意间）泄漏了 Zoosk.com 上的活动用户数。 -* 每个 Web 服务器在 RAID 1 中具有 2 个 320GB SSD。 +实际上，它泄漏的是任何一次活动用户的数量。 马特假设同一个人整天都保持登录状态。 但是当涉及到[扩展其实时平台](http://zooskdev.wordpress.com/2011/09/13/4-tricks-to-going-real-time-for-tech-ops/)时，Zoosk 并不太紧。 -* 每个 ElasticSearch 盒都有 300 GB，也使用 SSD。 +18 个服务器之间仅 150k 并发用户的负载平衡又如何呢？ 仅一个 tigase 实例就够这么低的容量吗？ 也许这只是出于过现实的冗余因素？ -* 堆栈溢出的读写比率为 40:60。 - -* 数据库服务器平均 10％的 CPU 使用率 - -* 11 个 Web 服务器，使用 IIS - -* 2 个负载均衡器，其中 1 个处于活动状态，并使用 HAProxy - -* 4 个活动数据库节点，使用 MS SQL - -* 3 个应用服务器实现标签引擎，任何通过标签命中进行搜索 - -* 3 台机器使用 ElasticSearch 进行搜索 - -* 2 台使用 Redis 进行分布式缓存和消息传递的机器 - -* 2 个网络（每个 Nexus 5596 +光纤扩展器） - -* 2 个 Cisco 5525-X ASA（认为防火墙） - -* 2 个 Cisco 3945 路由器 - -* 2 个只读 SQL Server，主要用于 Stack Exchange API - -* 虚拟机还执行诸如部署，域控制器，监视，用于系统管理员的操作数据库等功能。 - -## 平台 - -* 弹性搜索 - -* 雷迪斯 - -* HAProxy - -* MS SQL - -* [观察者](https://github.com/opserver/Opserver) - -* 团队城市 - -* [Jil](https://github.com/kevin-montrose/Jil) -基于 Sigil 构建的快速.NET JSON 序列化器 - -* [Dapper](https://code.google.com/p/dapper-dot-net/) -微型 ORM。 - -## UI [ - -* UI 具有消息收件箱，当您获得新徽章，收到消息，重大事件等时，将向该消息收件箱发送消息。使用 WebSockets 完成并由 Redis 驱动。 - -* 搜索框由 ElasticSearch 使用 REST 接口提供动力。 - -* 由于有如此多的问题，因此不可能仅显示最新的问题，它们会变化得太快，每秒都会出现一个问题。 开发了一种算法来查看您的行为方式，并向您显示您最感兴趣的问题。它使用了基于标签的复杂查询，这就是开发专门的标签引擎的原因。 - -* 服务器端模板用于生成页面。 - -## 服务器 - -* 这 25 台服务器的工作量不大，即 CPU 负载低。 据估算，SO 只能在 5 台服务器上运行。 - -* 数据库服务器的利用率为 10％，除非在执行备份时服务器突然崩溃。 - -* 有多低 数据库服务器具有 384GB 的 RAM，Web 服务器的 CPU 使用率为 10％-15％。 - -* 放大仍然有效。 其他具有类似浏览量的横向扩展站点通常可以在 100、200，最多 300 台服务器上运行。 - -* 系统简单。 建立在.Net 上。 只有 9 个项目，其他系统有 100 个。 之所以拥有很少的项目，是因为编译如此迅速，这需要在开始时就进行规划。 在一台计算机上，编译需要 10 秒钟。 - -* 110K 行代码。 给出了它的作用的一小部分。 - -* 这种简约的方法存在一些问题。 一个问题是测试不多。 不需要测试，因为那里有一个很棒的社区。 Meta.stackoverflow 是社区的讨论站点，并且报告了错误。 Meta.stackoverflow 还是新软件的测试版站点。 如果用户发现任何问题，他们会报告所发现的错误，有时还会报告解决方案/补丁。 - -* 纽约已使用 Windows 2012，但正在升级到 2012 R2（俄勒冈已经在使用它）。 对于 Linux 系统，它是 Centos 6.4。 - -* 实际上，负载几乎遍布 9 台服务器，因为 10 台和 11 台仅用于 meta.stackexchange.com，meta.stackoverflow.com 和开发层。 这些服务器还运行约 10-20％的 CPU，这意味着我们还有很多可用空间。 - -## 固态硬盘 - -* Intel 330 作为默认设置（网络层等） - -* 英特尔 520 用于中级写入，例如 Elastic Search - -* 用于数据库层的 Intel 710 & S3700。 S3700 只是高耐用性 710 系列的后继产品。 - -* 独家 RAID 1 或 RAID 10（10 是具有 4 个以上驱动器的任何阵列）。 故障已经不是问题，即使有数百个 intel 2.5 英寸固态硬盘投入生产，也没有一个故障。每种型号都保留一个或多个备件，但是多个驱动器故障并不是一个问题。 - -* 鉴于非常频繁的 SO 写/重新索引，ElasticSearch 在 SSD 上的性能要好得多。 - -* SSD [更改搜索](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/#comment-1201059884)的使用。 由于锁定问题，Lucene.net 无法处理 SO 的并发工作负载，因此将其转移到 ElasticSearch。 事实证明，在所有 SSD 环境中，实际上都不需要对二进制读取器进行锁定。 - -* 到目前为止，唯一的纵向扩展问题是 SQL 盒上的 SSD 空间，这是由于可靠性与非消费空间中的空间的增长方式所致，即驱动器具有用于功率损耗等的电容器。 - -## 高可用性 [ - -* 主数据中心在纽约，备用数据中心在俄勒冈。 - -* Redis 具有 2 个从属，SQL 具有 2 个副本，标记引擎具有 3 个节点，elastic 具有 3 个节点-任何其他服务也具有高可用性（并且都存在于两个数据中心中）。 - -* 并非所有数据中心之间都存在从属关系（不需要通过同步来占用带宽的非常临时的高速缓存数据等），而是大数据项，因此在活动数据中心发生故障时，仍然存在共享的高速缓存。 没有缓存就可以开始，但这不是很优雅。 - -* Nginx 用于 SSL，但是已经过渡到使用 HAProxy 终止 SSL。 - -* 发送的 HTTP 总流量仅占发送总流量的 77％。 这是因为正在向俄勒冈州的辅助数据中心以及其他 VPN 通信进行复制。 这些流量的大部分是到俄勒冈州 SQL 复制副本和 Redis 从站的数据复制。 - -## 数据库 - -* MS SQL Server。 - -* Stack Exchange 每个站点有一个数据库，因此 Stack Overflow 获取一个，超级用户获取一个，Server Fault 获取一个，依此类推。 这些的架构是相同的。 具有不同数据库的这种方法实际上是分区和水平缩放的一种形式。 - -* 在主要数据中心（纽约）中，每个集群通常有 1 个主数据库和 1 个只读副本。 在 DR 数据中心（俄勒冈州）中还有 1 个只读副本（异步）。 在俄勒冈州运行时，主要目录在那里，并且两个纽约副本均为只读且异步。 - -* 有一些皱纹。 有一个“网络范围的”数据库，其中包含登录凭据和聚合数据（主要通过 stackexchange.com 用户配置文件或 API 公开）之类的东西。 - -* 职业生涯 Stack Overflow，stackexchange.com 和 Area 51 都有各自独特的数据库架构。 - -* 所有架构更改将同时应用于所有站点数据库。 它们需要向后兼容，因此，例如，如果您需要重命名一列-最坏的情况-这是一个多步骤的过程：添加新列，添加适用于两列的代码，回填新列，更改 代码，使其仅适用于新列，请删除旧列。 - -* 不需要分区。 索引可以处理所有事情，并且数据还不够大。 如果需要过滤索引，为什么不提高效率呢？ 仅在 DeletionDate = Null 上建立索引，这是一个常见的模式，其他则是枚举中特定的 FK 类型。 - -* 每个项目 1 张表中有投票，例如 1 张表用于投票，1 张表用于评论投票。 我们大多数页面都是实时呈现的，仅为匿名用户缓存。 鉴于此，没有要更新的缓存，只需重新查询即可。 - -* 分数是非规范化的，因此经常需要查询。 所有的 ID 和日期，职位投票表目前只有 56,454,478 行。 由于建立索引，大多数查询仅需几毫秒。 - -* 标记引擎完全是独立的，这意味着不必依赖外部服务来获得非常核心的功能。 这是一个巨大的内存结构数组结构，针对 SO 用例和针对重击组合的预计算结果进行了优化。 这是一个简单的 Windows 服务，在冗余团队中的几个盒子上运行。 CPU 几乎总是占 2-5％。 负载不需要三个盒子，只是冗余。 如果所有这些操作一次都失败，则本地 Web 服务器将标记引擎加载到内存中并继续运行。 - -* 与传统的 ORM 相比，Dapper 缺少编译器来检查查询。 编译器正在检查您告诉数据库的内容。 这可以帮助很多事情，但是仍然存在运行时遇到的根本断开问题。 权衡的一个巨大问题是所生成的 SQL 令人讨厌，并且查找其来源的原始代码通常并非易事。 尝试优化查询时，缺乏提示查询，控制参数化等功能的问题也很大。 例如。 文字替换已添加到 Dapper，以帮助进行查询参数化，从而允许使用诸如过滤索引之类的内容。 Dapper 还拦截了对 Dapper 的 SQL 调用，并添加了 add 的确切来源。 它节省了很多时间来追踪事物。 - -## 编码 - -* 过程： - - * 大多数程序员都在远程工作。 程序员在自己的蝙蝠洞中编码。 - - * 编译非常快。 - - * 然后运行他们已经进行的一些测试。 - - * 编译后，代码将移至开发登台服务器。 - - * 新功能通过功能开关隐藏。 - - * 在与其他站点相同的硬件上运行。 - - * 然后将其移至 Meta.stackoverflow 进行测试。 每天有 1000 个用户使用该网站，因此它是一个很好的测试。 - - * 如果通过，它将在网络上发布并由更大的社区进行测试。 - -* 大量使用静态类和方法，以简化操作并提高性能。 - -* 代码很简单，因为复杂的位打包在一个库中，并且是开源和维护的。 .Net 项目的数量保持较低，因为使用了社区共享的代码部分。 - -* 开发人员可以获得两到三个监视器。 屏幕很重要，它们可以帮助您提高工作效率。 - -## 快取 - -* 缓存所有东西。 - -* 5 级缓存。 - -* 第一个：网络级缓存：在浏览器，CDN 和代理中进行缓存。 - -* 第二名：.Net 框架免费提供的，称为 HttpRuntime.Cache。 内存中的每个服务器缓存。 - -* 第三名：Redis。 分布式内存键值存储。 在为同一站点提供服务的不同服务器之间共享缓存元素。 如果 StackOverflow 有 9 台服务器，则所有服务器都将能够找到相同的缓存项。 - -* 第四：SQL Server 缓存。 整个数据库都缓存在内存中。 整个事情。 - -* 第五名：SSD。 通常仅在 SQL Server 缓存预热时命中。 - -* 例如，每个帮助页面都被缓存。 访问页面的代码非常简洁： - - * 重用了静态方法和静态类。 从 OOP 的角度来看，这确实很糟糕，但是对于简洁的代码却非常快速且非常友好。 所有代码都直接寻址。 - - * 缓存由 Redis 的库层和微型 ORM [Dapper](https://code.google.com/p/dapper-dot-net/) 进行处理。 - -* 为了解决垃圾回收问题，仅创建模板中使用的类的一个副本并将其保存在缓存中。 从统计数据中可以测量所有内容，包括 GC 操作，已知间接层会增加 GC 压力到明显的缓慢点。 - -* 由于查询字符串哈希值基于文件内容，因此 CDN 命中数有所不同，因此只能在构建中重新获取它。 300 至 600 GB 的带宽通常每天点击 30-50 百万次。 - -* CDN 不用于 CPU 或 I / O 负载，而是用于帮助用户更快地找到答案。 - -## 部署 [ - -* 想要每天部署 5 次。 不要建立宏伟的宏伟的东西，然后再活下来。 重要原因： - - * 可以直接衡量性能。 - - * 被迫制造可能起作用的最小的东西。 - -* 然后，通过 Powershell 脚本构建 TeamCity，然后将其复制到每个 Web 层。 每个服务器的步骤是： - - * 告诉 HAProxy 通过 POST 使服务器停止旋转 - - * 延迟让 IIS 完成当前请求（约 5 秒） - - * 停止网站（通过以下所有操作使用相同的 PSSession） - - * Robocopy 文件 - - * 启动网站 - - * 通过另一个 POST 在 HAProxy 中重新启用 - -* 几乎所有内容都是通过 puppet 或 DSC 进行部署的，因此升级通常仅包括对 RAID 阵列进行核对并从 PXE 引导进行安装。 它的速度非常快，而且您知道它做得正确/可重复。 - -## 团队合作 - -* 队伍： - - * SRE（系统可靠性工程）：-5 人 - - * 核心开发人员（Q & A 网站）：〜6-7 人 - - * 核心开发人员：6 人 - - * 仅针对 SO Careers 产品进行开发的职业团队：7 人 - -* Devops 和开发人员团队确实紧密相连。 - -* 团队之间有很多变动。 - -* 大多数员工都在远程工作。 - -* 办公室主要是销售部门，丹佛和伦敦则完全是这样。 - -* 在所有其他条件相同的情况下，在纽约市更喜欢有一些人，因为面对面的时间对于“完成任务”之间的偶然互动是加分的。 但是，这种设置可以进行实际工作，并且官方团队合作几乎可以完全在线进行。 - -* 他们了解到，亲自聘用能够在任何地方热爱该产品的最佳人才所带来的收益远远超过其个人收益，而不仅仅是愿意住在您所在城市的人才。 - -* 某人偏远的最常见原因是建立家庭。 纽约很棒，但宽敞却不是。 - -* 办公室在曼哈顿，那里有很多人才。 由于数据中心总是在不断完善，因此它不必离疯狂的距离。 与 NYC 位置的许多骨干网的连接速度也稍快-尽管我们在这里谈论的只是几毫秒（如果有的话）的差异。 - -* 组建一支很棒的团队：爱极客。 例如，早期的 Microsoft 充满了极客，他们征服了整个世界。 - -* 从 Stack Overflow 社区雇用。 他们寻求对编码的热情，对他人的热情以及对沟通的热情。 - -## 预算 - -* 预算几乎是基于项目的。 仅在为新项目添加基础结构时才花钱。 利用率如此低的 Web 服务器与 3 年前建造数据中心时购买的 Web 服务器相同。 - -## 测验 - -* 快速行动并破坏事物。 现场直播。 - -* 重大更改通过推送进行测试。 开发具有功能相同的 SQL Server，并且它在同一 Web 层上运行，因此性能测试也不错。 - -* 很少的测试。 由于 Stack Overflow 的活动社区和大量使用静态代码，因此它们不使用许多单元测试。 - -* 基础架构发生变化。 共有 2 种，因此只要有可能，就可以使用旧配置进行备份，并具有快速故障回复机制。 例如，keepalived 会在负载均衡器之间快速进行故障回复。 - -* 冗余系统通常只是为了进行定期维护而进行故障转移。 通过拥有专用的服务器来不断测试 SQL 备份，该服务器用于不断地还原它们（这是免费许可证，可以执行此操作）。 计划每 2 个月左右启动一次完整的数据中心故障转移-辅助数据中心在所有其他时间都是只读的。 - -* 每次推送都会运行单元测试，集成测试和 UI 测试。 所有测试必须成功，才能进行生产构建。 因此，关于测试的信息有些混杂。 - -* 显然应该进行测试的事物具有测试。 这意味着在 Careers 产品上涉及金钱的大多数事物，以及在 Core 端上易于进行单元测试的功能（具有已知输入的事物，例如标记，我们的新顶部栏等），而对于大多数其他事情，我们只是做一个功能 手动进行测试并将其推送到我们的孵化站点（以前称为 meta.stackoverflow，现在称为 meta.stackexchange）。 - -## 监控/记录 - -* 现在考虑使用 http://logstash.net/进行日志管理。 当前，专用服务将 syslog UDP 通信插入 SQL 数据库。 网页添加了用于出站计时的标头，这些标头由 HAProxy 捕获并包含在 syslog 通信中。 - -* [Opserver](https://github.com/opserver/Opserver) 和 Realog。 有多少度量标准浮出水面。 Realog 是由 Kyle Brandt 和 Matt Jibson 在 Go 中构建的日志显示系统 - -* 通过 syslog 而不是 IIS 从 HAProxy 负载平衡器进行日志记录。 它比 IIS 日志具有更多的通用性。 - -## 阴天 - -* 硬件比开发人员便宜且代码高效。 您的速度只有最慢的瓶颈，而且当前所有的云解决方案都具有基本的性能或容量限制。 [ -* 如果从第一天开始构建云，您能否构建得那么好？ 最有可能。 您能否一致性地渲染所有页面，以执行多个最新查询并跨您无法控制的云网络缓存获取数据，并获得不到 50 毫秒的渲染时间？ 那是另一回事。 除非您谈论的是更高的成本（至少 3-4 倍），否则答案是否定的-SO 托管在自己的服务器中仍然更加经济。 - -## 性能为特征 - -* StackOverflow 非常重视性能。 主页的目标是在 50 毫秒内加载，但可以低至 28 毫秒。 - -* 程序员热衷于减少页面加载时间并改善用户体验。 - -* 记录到网络的每个请求的时间。 借助这些指标，您可以决定改进系统的位置。 - -* 其服务器以如此低的利用率运行的主要原因是高效的代码。 Web 服务器的平均 CPU 率为 5-15％，使用的 RAM 为 15.5 GB，网络流量为 20-40 Mb / s。 SQL 服务器平均约有 5-10％的 CPU，365 GB 的 RAM 和 100-200 Mb / s 的网络流量。 这具有三个主要优点：一般的增长空间和升级的必要性； 当事情发疯时（查询错误，代码错误，攻击等等），可以保持在线的余地； 以及在需要时恢复供电的能力。 - -## 经验教训 [ - -* **如果使用 MS 产品，为什么要使用 Redis？** [gabeech](http://www.reddit.com/r/programming/comments/1r83x7/what_it_takes_to_run_stack_overflow/cdkpv7w) ：这与 OS 宣传无关。 我们在运行效果最佳的平台上运行事物。 期。 C＃在 Windows 计算机上运行最好，我们使用 IIS。 Redis 在我们使用* nix 的* nix 机器上运行得最好。 - -* **作为策略过度杀伤**。 尼克·克雷弗（Nick Craver）解释了为什么他们的网络被过度配置了：20 Gb 大规模杀伤力大吗？ 您敢打赌，在 20 Gb 管道中，活动的 SQL 服务器平均大约 100-200 Mb。 但是，由于存在大量内存和 SSD 存储，因此备份，重建等操作可能会使它完全饱和，因此确实可以达到目的。 - -* **SSD 摇滚**。 数据库节点均使用 SSD，平均写入时间为 0 毫秒。 - -* [了解您的读/写工作量](http://sqlblog.com/blogs/louis_davidson/archive/2009/06/20/read-write-ratio-versus-read-write-ratio.aspx)。 - -* **保持高效运行意味着经常不需要新机器。 只有当由于某种原因需要不同硬件的新项目出现时，才添加新硬件。 通常会添加内存，但是除了该高效代码和低利用率以外，它不需要替换。 因此，通常谈论的是添加 a）SSD 以获得更多空间，或 b）为新项目添加新硬件。** - -* **不要害怕专长**。 SO 使用基于标签的复杂查询，这就是为什么要开发专门的标签引擎的原因。 - -* **仅执行需要做的事情**。 不需要测试，因为活跃的社区已经为它们进行了验收测试。 仅在需要时添加项目。 仅在必要时添加一行代码。 您没有需要它确实有效。 - -* **重新发明可以**。 通常的建议是不要重新发明轮子，例如，将其变成正方形只会使它变得更糟。 在 SO 上，他们不必担心制作“方轮”。 如果开发人员可以编写比已经开发的替代方案更轻巧的东西，那就去做。 - -* **转到裸机**。 进入 IL（.Net 的汇编语言）。 一些编码使用 IL，而不是 C＃。 查看 SQL 查询计划。 进行 Web 服务器的内存转储，以查看实际情况。 例如，发现拆分呼叫会产生 2GB 的垃圾。 - -* **没有官僚机构**。 您的团队总是需要一些工具。 例如，编辑器，Visual Studio 的最新版本等。只需进行很多操作即可。 - -* **垃圾收集驱动的编程**。 SO 竭尽全力减少垃圾收集成本，跳过诸如 TDD 之类的做法，避免抽象层，并使用静态方法。 虽然极端，但结果却是高性能的代码。 当您在短窗口中处理数亿个对象时，实际上可以测量 GC 运行时应用程序域中的暂停时间。 这些对请求性能有相当不错的影响。 - -* **低效代码的成本可能比您认为的**高。 高效的代码进一步扩展了硬件，减少了功耗，并使程序员更易于理解代码。 - -## 相关文章 - -* [关于黑客新闻](https://news.ycombinator.com/item?id=8064534) - -* [运行堆栈溢出所需的时间[Nick Craver]](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/) - - * [在 Reddit 上](http://www.reddit.com/r/programming/comments/1r83x7/what_it_takes_to_run_stack_overflow/) - -* 视频 [StackOverflow](http://www.dev-metal.com/architecture-stackoverflow/) 的体系结构，作者 Marco Cecconi - - * [关于 HackerNews](https://news.ycombinator.com/item?id=7052835) - - * [演示幻灯片](https://speakerdeck.com/sklivvz/the-architecture-of-stackoverflow-developer-conference-2013) - -* [Stackoverflow.com：通往 SSL 的道路](http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/) - -* [哪些工具和技术用于构建 Stack Exchange 网络？](http://meta.stackexchange.com/questions/10369/which-tools-and-technologies-are-used-to-build-the-stack-exchange-network) - -* [被 GC 攻击](http://blog.marcgravell.com/2011/10/assault-by-gc.html) - -* [StackOverflow 上的 Microsoft SQL Server 2012 AlwaysOn AG](http://www.brentozar.com/archive/2012/09/microsoft-sql-server-alwayson-ags-at-stackoverflow/) - -* [为什么我们（仍然）相信远程工作](http://blog.stackoverflow.com/2013/02/why-we-still-believe-in-working-remotely/) - -* [运行堆栈溢出 SQL 2014 CTP 2](http://nickcraver.com/blog/2013/11/18/running-stack-overflow-sql-2014-ctp-2/) - -* 多年来，HighScalability 在 StackOverflow 上有几篇文章：[堆栈溢出体系结构](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html)， [StackOverflow 的扩展野心](http://highscalability.com/blog/2010/2/15/scaling-ambition-at-stackoverflow.html)，[堆栈溢出体系结构更新](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)， [StackExchange 体系结构更新[](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html) 。 - -这里有 Stack 开发人员-还有一个单独的 Careers 团队，专门为 SO Careers 产品进行开发。 也大约有 7 位开发者。 - -有关首次出现在堆栈上的某些情况，请访问： [http://www.jonhmchan.com/blog/2014/1/16/my-first-six-weeks-working-at-stack-overflow](http://www.jonhmchan.com/blog/2014/1/16/my-first-six-weeks-working-at-stack-overflow) - -“快如闪电”？ 真？ 在称自己为作家之前，请先了解“闪电”和“闪电”之间的区别 - -我从来不知道他们在大多数网站上都使用 C＃编写代码，考虑到他们仅使用 25 台服务器，看到这样的项目进行扩展，真是令人震惊！ （哇） -我对数据库的低延迟感到惊讶，即使它全部在内存中，也有一些物理瓶颈无法让您处理超过 20gb / sec 的速度（不确定是什么，取决于内存速度） ）。 - -很棒的帖子，很惊讶地看到它们继续运行。 令我的公司感到羞耻的是，我们的服务器从左到右落在中间，仅运行了一部分 SO 运行！ - -在 MS SQL 停止读取 - -不是.net 人，但是许多项目如何影响编译时间？ - -非常有趣-感谢您的总结！ - -很好的简历，它很棒的 stackoverflow 原理！ 高性能！ - -“下降到裸机。进入 IL”。 IL 中的 I 代表中级。 因此，也许应该将其改写为“更紧密地接近裸机”，但实际上并非如此。 - -“大多数程序员都在远程工作。程序员在自己的蝙蝠洞中编写代码。” - -有点违背 - -“在其他所有条件相同的情况下，在纽约市更倾向于有人陪伴，因为面对面的时间是在“完成工作”之间进行的随意互动的加分。但是，这种设置可以进行真正的工作和 官方团队合作几乎完全在线上进行。” - -“他们已经了解到，亲自聘用能够在任何地方钟情于该产品的最优秀人才而获得的收益远远超过个人受益，而不仅仅是愿意住在您所居住的城市的人才。 ” - -出色而翔实，因此令人大开眼界。 对于那些讨厌微软技术栈的人……包括我在内，这是有教益的。 真的很棒。 - -关于编译速度和项目数量。 如果在 Visual Studio 中“卸载项目”，则可以禁用该项目的编译。 我有一个包含 14 个项目的解决方案，而卸载我不从事的项目可以节省大量时间。 - ->看到这样的项目可以扩展，考虑到他们仅使用 25 台服务器，这真是令人震惊 - ->很棒的帖子，很高兴看到他们的运行量 - -你疯了吗？！ 他们在每个数据库服务器上都有 384GB 的内存。 他们甚至在 Web 服务器上都有 SSD。 他们每个月提供的访问量仅为 5.6 亿，这是整个服务的 560000000 / 30/24/3600 = 216 RPS，如果将其除以 Web 服务器数量，则每个 Web 服务器将为 19 RPS ，而且它不是廉价服务器，甚至在 Raid 1 和 shit 中甚至都有 SSD。 给定像这样的数字，我会很高兴我没有使用 IIS 或任何 Microsoft 软件来提供 Web 应用程序... - -大量使用静态类和方法会产生代码异味 - -我发现 Marco Cecconi 在 SpeakerDeck 上有一些更新的幻灯片：[](https://speakerdeck.com/sklivvz "https://speakerdeck.com/sklivvz") - -@Nikita 哦，拜托，你知道数学很愚蠢。 流量显然遵循模式，几乎可以肯定，他们在峰值负载下的速度明显超过 216 RPS。 对于一个相当复杂，写繁重的网站而言，5.6 亿的页面浏览量是非常可观的。 - ->停止在 MS SQL 中阅读 - -当然可以 - -> 你疯了吗？！ 他们在每个数据库服务器上都有 384GB 的内存。 他们甚至在 Web 服务器上都有 SSD。 他们每个月提供的访问量仅为 5.6 亿，这是整个服务的 560000000 / 30/24/3600 = 216 RPS，如果将其除以 Web 服务器数量，则每个 Web 服务器将为 19 RPS ，而且它不是廉价服务器，甚至在 Raid 1 和 shit 中甚至都有 SSD。 给定像这样的数字，我会很高兴我没有使用 IIS 或任何 Microsoft 软件来提供 Web 应用程序... - -您的计算基于以下假设：这是其硬件堆栈可以管理的最大数量。 它在文章中多次声明，所有内容都超量配置，正常运行负载约为 10％。 -您所做的重大损害会导致类似的结论。 - -如果他们具有关于在最高性能下可以处理多少页面请求的任何统计信息，那将更加有趣。 即使这样，它也说明了他们特定的软件堆栈，将他们认为缺乏 RPS 归因于 IIS 是愚蠢的 - -正如 Nikita 所说，这些数字似乎并不令人印象深刻。 我在 SQL 部分中不知道，但是在 HTTP 部分中，只有一台具有 apache 和 php 的 1GB ram 双核服务器可以完成这项工作。 - -Nick Craver-此处的堆栈溢出系统管理员。 - -我以为我会在这些评论中消除一些混乱和不好的数字。 - -页面浏览量仅占我们负载的一小部分。 我们为许多 AJAX / JSON 路由和 API 请求提供服务，在任何给定的工作日总计超过 1.3 亿个请求。 例如，昨天我们处理了 150,091,472 个请求，平均约为 1730 RPS。 当然，我们有高峰时间与非高峰时间，所以这不是一个很好的指标。 在高峰期，我们通常会在 9 个主要 Web 服务器中的每一个上看到 2600-3000 RPS，负载约为 15％。 供参考：过去 30 天内，我们处理了 3,710,241,322（37 亿）个请求。 - -注意：这些 Web 服务器可能已经使用了 4 年，订购时并没有达到最高级的水平（Intel E5640 处理器）。 而且，这些数字不包括每个页面视图附带的我们的 Websocket 连接，它们将使数字甚至更高，并且它们由相同的 9 台 Web 服务器提供服务。 - -IIS 和 Microsoft 堆栈并不是所有时间都花在哪里（只有一小部分时间花在这里），它存在于我们的代码，API 调用，DB 查询，标签引擎请求等中。 对我们的网络的每个请求的*时序细分。 然后，每隔一段时间我们就会通过调整传递来发疯，并取得巨大的性能胜利……这是我们有一段时间没做过了。 在下一次优化通过之后，我将尝试发布更新的利用率数字。 同样值得注意的是，我们提供的几乎所有内容都不是静态内容，这些请求由我们的 CDN 处理的时间超过 99.97％。* - -@bob-托德是一位优秀作家。 但是他可能会考虑雇用编辑。 看来错别字已得到纠正。 您必须是一个很好的编辑才能赶上这一点。 也许你应该申请这份工作。 - -有人能解释为什么“堆栈溢出的读写比率为 40:60”吗？ 如何测量？ 什么构成读写操作？ 我对该统计数据感到非常惊讶。 我以为它将具有 99：1 的读写比。 与一小部分人发布新问题，答案，投票赞成/反对等等相比，不是大多数人只是查看答案而进行的操作。 - -很棒的帖子。 作为 stackoverflow 的粉丝，我只是喜欢这个极富启发性和内容丰富的博客。 - -很棒的文章，我很奇怪地从工程学的角度看待目前的体系结构。 11 万行和对抽象的厌恶通常不是成功的工程运动的先兆。 至少在一起时 我希望安装一些非常有趣的过程来帮助保持平稳运行。 - -但丁·埃里克（Dante Elrik） - -谢谢。 很高兴看到有人放弃了他们的基础架构和方法论。 对于所有批评家：他们所做的都是有效的。 成功了 很稳定 谁在乎这是怎么做的。 他们就是这样做的，而且显然很成功。 我敢肯定，如果您想像这些人一样详细描述它，那么高可扩展性将发布您的“高级”技术堆栈和公司文化。 就我自己而言，从物理基础结构到开发人员与“站点可靠性工程师”的比例，我发现这是一本有趣的文章。 \ No newline at end of file +我可以为这样的公司工作！ \ No newline at end of file diff --git a/docs/102.md b/docs/102.md index bdf3d1f..56de01b 100644 --- a/docs/102.md +++ b/docs/102.md @@ -1,230 +1,92 @@ -# 一点点：建立一个可处理每月 60 亿次点击的分布式系统的经验教训 +# WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量 -> 原文： [http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html](http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html) +> 原文： [http://highscalability.com/blog/2012/9/26/wordpresscom-serves-70000-reqsec-and-over-15-gbitsec-of-traf.html](http://highscalability.com/blog/2012/9/26/wordpresscom-serves-70000-reqsec-and-over-15-gbitsec-of-traf.html) -![](img/d8f15c5b26ebe6302516a72aa276f0fa.png) +*这是 [Barry Abrahamson](http://barry.wordpress.com/) ，Automattic 的 Chief Systems Wrangler 和 *Nginx 的共同创始人* Andrew Alexeev 的特邀帖子。* -您是否想知道 [有点](http://bitly.is/1g3AhR6) 赚钱吗？ 一个 [URL 缩短器](http://en.wikipedia.org/wiki/URL_shortening) 不会那么难写，对吧？ bitt 的首席应用开发人员 [Sean O'Connor](http://linkd.in/1nt6KTN) 回答了如何立即在 [中产生一点可赚钱的问题 他在](http://bit.ly/1iuEAlb) [培根会议](http://devslovebacon.com/) 上发表的 演讲。 +[WordPress.com](http://wordpress.com/) 每月服务超过 3300 万个网站，吸引了 3.39 亿人和 34 亿页。 自 2008 年 4 月以来，WordPress.com 的页面浏览量增长了约 4.4 倍。 [WordPress.com VIP](http://vip.wordpress.com/) 托管了许多受欢迎的网站，包括 CNN 的政治通讯器，NFL，Time Inc.的 The Page，People Magazine 的 Style Watch，Flickr 和 KROQ 的企业博客，等等。 Automattic 在全球分布的十二个数据中心中运行两千台服务器。 WordPress.com 客户数据可立即在不同位置之间复制，从而为数亿访问者提供极其可靠和快速的 Web 体验。 -肖恩说，写一个可行的 URL 缩写很容易，写一个可缩放且高度可用的 URL 缩写并不容易。 +### 问题 -Bitly 不会通过“缩短服务”服务获利，而是在分析产品上获利，该产品将 URL 点击数据与他们从网络上抓取的数据融合在一起，以帮助客户了解人们在网络上关注的内容 。 ， +WordPress.com 始于 2005 年，始于共享托管，就像所有 [WordPress.org](http://wordpress.org/) 网站一样。 很快将其移至单个专用服务器，然后移至两个服务器。 2005 年底，WordPress.com 向公众开放，到 2006 年初，它已扩展到四个 Web 服务器，并使用循环 DNS 分配了流量。 此后不久，WordPress.com 扩展到第二个数据中心，然后扩展到第三个数据中心。 很快，轮询 DNS 不再是可行的长期解决方案。 -Analytics 产品最初是一种用于爬网 Web 服务器日志的后端服务。 日志包含来自带注释的链接的数据以及 cookie 数据，以指示单击链接的页面，在何处单击，链接的内容等。但是，所有链接都回到了网站的域。 建立链接与您的域到另一个域以使第三者可以进行分析的想法是一个可怕的主张，但这也是一种天才。 +虽然像 F5 BIG-IP 这样的硬件设备提供了 WordPress.com 所需的许多功能，但由 5 名成员组成的自动系统团队决定评估基于现有开源软件构建的不同选项。 在商品硬件上使用开源软件可以提供最高的灵活性，并且还可以节省成本。*“为单个数据中心在故障转移配置中购买一对有能力的硬件设备可能会有点昂贵，但是购买和维修 10 套 10 个数据中心的 10 套很快变得非常昂贵。”* -尽管此话题不是关于尖锐的体系结构的，但它是对分布式系统的性质以及如何解决分布式系统的大难题的有思想的探索。 +最初，WordPress.com 团队选择 Pound 作为软件负载平衡器，因为它易于使用且内置 SSL 支持。 在使用 Pound 大约两年后，WordPress.com 需要其他功能和可伸缩性，即： -也许我从他的演讲中最喜欢的一课是这个（我的光泽）： +* 快速重新配置功能，而不会中断实时流量。 +* 更好的运行状况检查机制，允许从后端故障平稳逐步恢复，而不会因意外负载而使应用程序基础结构过载。 +* 更好的可伸缩性-每秒请求数和并发连接数。 庞德基于线程的模型无法在每个负载均衡实例每秒可靠地处理超过 1000 个请求。 -**SOA +队列+异步消息传递确实很强大** 。 这种方法可以隔离组件，让工作同时进行，让盒子独立发生故障，同时使组件仍然易于推理。 +### 解 -我也非常喜欢他的解释，说明为什么事件样式消息比命令样式消息更好。 我从来没有听过这样的话。 +在 2008 年 4 月，Automattic 将所有 WordPress.com 负载平衡器从 Pound 转换为 [NGINX](http://nginx.com/) 。 在此之前，Automattic 工程师一直在将 NGINX 用于 [Gravatar](http://gravatar.com/) ，并且对其性能和可伸缩性印象深刻，因此自然而然地下一步就是迁移 WordPress.com。 在将 WordPress.com 切换到 NGINX 之前，Automattic 评估了其他几种产品，包括 HAProxy 和 LVS。 选择 NGINX 的原因如下： -肖恩（Sean）从真实的经验谈起。 如果您想从单一思维方式转变为多思维方式，那么此演讲非常值得一看。 ， +* 简单，灵活和合理的配置。 +* 能够即时重新配置和升级 NGINX 实例，而无需删除用户请求。 +* 通过 FastCGI，uwsgi 或 SCGI 协议路由应用程序请求； NGINX 还可以直接从存储中提供静态内容，以实现其他性能优化。 +* 唯一经过测试的软件能够每秒可靠地处理从单个服务器到 WordPress 应用程序的 10,000 个实时流量请求。 +* NGINX 的内存和 CPU 占用空间极小且可预测。 切换到 NGINX 之后，负载平衡服务器上的 CPU 使用率下降了三倍。 -因此，让我们看看 Sean 对分布式系统有何感想…… +总体而言，WordPress.com 的峰值负载来自 NGINX 负载均衡器，服务于大约 70,000 req / sec，超过 15 Gbit / sec 的流量，还有很大的增长空间。 硬件配置是运行 Debian Linux 6.0 的具有超线程功能的 Dual Xeon 5620 4 核 CPU，8-12GB RAM。 作为高可用性设置的一部分，WordPress.com 以前使用 Wackamole / Spread，但最近开始迁移到 Keepalived。 跨入基于 NGINX 的 Web 加速和负载平衡层的入站请求的平均分配基于 DNS 轮询机制。 -## 统计信息 +### 参考资料 -* 每月有 60 亿点击 +* [关于黑客新闻](http://news.ycombinator.com/item?id=4578258) +* [WordPress 上的 Barry。 负载均衡器更新](https://barry.wordpress.com/2008/04/28/load-balancer-update/) +* [WordPress 上的 Barry。 磅](https://barry.wordpress.com/2007/11/01/static-hostname-hashing-in-pound/)中的静态主机名哈希 +* [WordPress 上的 Barry。 WordPress.com 的新服务器](https://barry.wordpress.com/2007/01/31/new-servers-for-wordpresscom/) +* [WordPress 上的 Barry。 负载均衡器测试](https://barry.wordpress.com/2006/08/30/load-balancer-testing/) +* [由 Matt Mullenweg 打开](http://en.blog.wordpress.com/2005/11/23/opening-it-up/) +* [Quantcast 提供的 WordPress.com 流量和人口统计](https://www.quantcast.com/wordpress.com) -* 6 亿个每月缩短 +NGINX 自几年以来进展顺利。 每秒的请求量和最小的硬件使我印象深刻。 -* 公司内 50 名员工和大约 20 名工程师 +我希望有一天能看到某种适用于.Net 的轻型服务器，并具有这种结果。 -* 400 台服务器。 并非所有 400 台服务器都在处理重定向。 约 30 台服务器处理来自外界的所有传入流量，包括缩短，重定向，api 请求，Web ui 等.400 台服务器的其余部分专用于存储和组织用户数据或提供各种形式的处理和分析（数据库）的各种服务 ，指标，网页抓取，文本分析等）。 +他们的数据库系统如何工作？ -* 每月抓取一亿个网页。 +@Seun。 我无法想象平台的大部分将需要提供需要数据库命中的动态数据。 博客文章发布后，它基本上是静态的。 提供静态文件/数据非常容易，而且成本也不高。 这种模式的难点在于增加每台服务器的密度，但这实际上只是为了大规模地降低成本，并且只有当站点达到 wordpress 拥有的规模时才值得付出努力。 总之，如果提供静态数据是他们的问题，那么扩展数据库很容易，不需要任何特殊操作。 主从服务器或将表移动到专用服务器的基本内容。 -## 来源 +应用程序更具动态性，难以扩展数据层。 -* [经验教训，了解建筑物的分布式系统](http://devslovebacon.com/conferences/bacon-2014/talks/lessons-learned-building-distributed-systems-at-bitly) +我会对数据库分片更感兴趣。 -## 平台 [ +您是否真的需要 2000 台服务器来处理这么多的静态流量？ 还是它们还充当自托管 CDN，包括备份和冗余？ -请注意，这些只是谈话中提到的内容，而不是完整的列表。 +看看 Barry 的博客。 他（和其他人）分享了很多有关 WordPress.com 环境的信息。 -* HDFS +WP.com 似乎在 550 台 mySQL 服务器上使用了 HyperDB 复制（截至 2011 年 7 月）-[链接](https://barry.wordpress.com/2011/07/20/hyperdb-lag-detection/) -* S3 +嗨，达里安， -* Nagios +您想特别了解数据库分片什么？ 很乐意对此发表评论。 -* 实时使用的实时分布式消息系统是 [Nsq](https://github.com/bitly/nsq) 。 +是的，我们需要所有服务器。 流量通常不是静态的。 请记住，从 WordPress.com 提供的图像中有 85％是动态转换的-即时进行的。 相信我，如果我们不需要那么多服务器，我会很乐意摆脱它们；） -* 稍微使用 [主机池](https://github.com/bitly/go-hostpool) 来管理主机池。 +哇！ 这非常好。 我认为 Apache 基金会现在需要改进 Apache。 -* 谈话的结尾已结束，但提到使用了很多不同的数据库。 ， +WordPress.com 使用 WordPress-multisite。 +WordPress-multisite 通过 PHP 处理静态文件，可以减少您使用 Nginx 的麻烦。 -## 关于分布式系统的性质 +因此，要获得像 wordpress.com 一样的性能，请在 nginx 的前面放置清漆以缓存静态内容，或者使用 [nginx-maps 指令](http://rtcamp.com/tutorials/nginx-maps-wordpress-multisite-static-files-handling/)。 -* 任何真正高度可用的东西都将被固有地分发。 为了达到一定程度的可用性，您必须具有地域多样性。 根据定义，如果您在不同区域中具有独立的操作系统，则必须将其分发。 +这也是我最喜欢的有关可伸缩性的视频之一-http://2011.sf.wordcamp.org/session/ask-barry/。 +谢谢 Barry！ -* 创建分布式系统的旧方法。 创建抽象，让您假装实际上没有分发。 +他们用什么来运行实际的 WordPress 应用程序？ 我曾经在 nginx 后面尝试过 PHP-FPM，但取得了一些成功，但我想知道他们是否在 nginx 后面有完整的 Apache 堆栈。 - * 例如，NetApp 会产生无限磁盘的错觉。 +我们在 Web /应用程序服务器上使用 Nginx + PHP-FPM。 - * Oracle，是一个高度可用的数据库，可让您假装世界与实际不同。 +您为什么不赞成使用 haproxy，而选择 nginx 代替 LB？ +您对 GSLB 使用什么？ - * 两者都可以解决实际问题，但是两者都很昂贵，因此请另辟 different 径。 +只是一个问题：WordPress 是否使用 nginx 作为负载均衡器，并且背后是 Apache，还是 nginx 是本机？ -* 新方法。 通过接受分布式系统的固有特性来解决问题，并将其内置到它们作为工具提供的抽象中。 +谢谢 - * 您对事物的看法发生了重大变化。 由于您的抽象与所构建内容的实际情况更加紧密一致，因此您可以进行更强大的折衷，从而更高效地完成工作。 +@ Lord2y：请阅读 Barry 的答案，在您的上方仅两篇文章：） -* 带有 1x RAM 的 4 盒总是比带有 4x RAM 的 1 盒便宜。 这意味着分布式系统是扩展和实现高可用性的方法。 +@Rahul Bansal：为什么要在 nginx 前面使用清漆？ 您可以使用 nginx 缓存... -* 分布式系统出现问题，因为您要从一台计算机迁移到 N 台计算机。 - - * **组件的并发** 。 机器 A 与机器 B 同时工作。这就是获得水平缩放的方式。 功能强大，但代价是需要在机器之间进行协调。 例如，在锁定数据时，使框彼此等待，您将不再并发。 - - * **缺少全局时钟** 。 每个盒子的时钟都不完美。 如果有一台以上的机器，那么每台机器都会有自己的时间感。 这意味着无法根据时间对在不同计算机上发生的事件进行排序。 如果事件之间相隔 1 或 2 秒，则他们不知道先发生哪些事件。 - - * **独立故障** 。 如果方框 A 失败，则方框 B 应该继续工作。 - -* 有些问题（例如分析）太大，无法在一台计算机上处​​理。 或至少这样的机器不会在预算内。 - -## 实施分布式系统的策略 - -### 面向服务的体系结构 - -没有一个整体式的应用程序。 网络上有数十种相互通信的小型服务。 - -* 这是一种抽象，非常类似于代码中的功能，但是是系统级的。 - -* 不必将系统的所有细节都保留在脑海中。 可以只注意 API 边界和合同。 - -* 强大的开发和运营能力。 - -* Bitly 是一家拥有 6 年历史的公司，并且具有很多代码。 您无需查看每一行代码。 您只使用该服务。 - -* 设计良好的服务仅几百行代码。 - -* 在操作上，很容易确定哪个系统有问题。 然后，您可以深入研究该系统以查找问题。 - -* 故障现在意味着功能减少而不是停机。 通常，每个服务都旨在回答特定问题。 由于如果其中之一发生故障，它们将完全与自己的持久层隔离，那么唯一丢失的就是回答该问题的能力，但是总体而言，服务仍处于运行状态。 出现故障的度量系统永远不会影响 URL 缩短请求。 ， - -### 异步消息传递 - -* 发送消息而无需等待回复。 - -* 真的很容易在组件之间放置队列。 如果框 A 正在向框 B 发送邮件，并且框 B 出现问题，则框 B 恢复后，这些邮件将排队并且可以进行处理。 - -* 处理错误的更多选项。 如果包装盒出现问题，该消息将稍后处理。 方框 A 不必了解或关心方框 B 的麻烦。 - -* 不利的一面是，将执行的操作更自然地建模为同步请求。 - -* URL 缩短请求是一个完全同步的过程，因为： - - * **速度**。 希望尽快返回答复。 例如，不想处理队列备份。 - - * **一致性**。 不想将相同的缩写网址提供给多个用户。 而是提供一个错误而不是一个无效的链接。 - -* 指标系统完全异步。 单击一个小链接后，它会翻译并通过 HTTP 返回。 有关转换的数据会弹出到分析和其他下游系统的队列中。 如果在处理指标方面有一点延迟，那就不是世界末日了。 - -* 可以将消息视为命令或事件。 - - * 命令说“做 X”。 - - * 一个事件说“ X 发生了”。 - -* 事件比命令更有用。 - - * **可以更好地隔离系统**。 命令意味着知道谁接收命令，否则将毫无意义。 说了些什么意味着您不必在乎谁在使用消息。 只要宣告发生了 X，其他服务就可以增加统计信息或执行任何操作。 - - * **事件自然映射为让多个使用者处理消息**。 将位 URL 解码为 HTTP 重定向后，会将消息发送到多种服务：将其保存到 HDFS 和 S3 的存档服务，实时分析服务，长期历史记录分析，注释服务。 解码服务只需要发布事件，而无需了解下游服务。 下游服务只是收到一个事件，他们不在乎发送方式或发送者。 - - * **添加新消费者很容易**。 可以创建新服务，并且可以注册活动，而制作人不知道或不在乎。 服务处理事件的方式的变化同样也不是生产者所关心的。 生产者和消费者是孤立的，只能通过事件指定的合同进行联系。 - -## 使服务发挥出色 - -* **在服务**之间使用背压。 如果某个服务繁忙，则应告知其他请求服务以限制其请求，从而减少它们在出现问题的服务上的负担。 例如，指数补偿。 帮助防止通过系统的级联错误。 还可以帮助系统更快地恢复。 例如，依赖缓存的服务需要一个预热期，如果请求的服务在预热期间没有回退，则数据库可能会崩溃。 - -* **绕过故障**。 例如，服务之间的负载平衡。 Bitly 使用 [主机池](https://github.com/bitly/go-hostpool) 管理主机池。 客户端向主机请求服务。 然后，客户端会在每个请求上告诉 hostpool 请求是否失败。 基于此反馈，主机池可以管理主机分配以路由到更健康的主机。 - -## 监视 [ - -* 使用一台或两台服务器，不难知道何时发生故障，但是当您拥有数百台服务器时，就需要帮助。 - -* **使用 Nagios 之类的工具检查服务器运行状况**。 检查统计信息，例如“盒子是否在交换？” - -* **运行完整性检查**。 例如，服务正在响应，但是返回的数据已损坏。 - -* **集中记录**。 之所以重要，是因为您可以跨多个主机检测故障。 如果一个用户造成了您所有的错误，那么通过在机器之间跳来跳去将很难检测到。 集中式日志使检测整体问题变得更加容易，例如所有错误都来自一个 ip 地址。 - -* **人机界面**。 您如何在正确的时间向正确的人获取正确的信息。 如何从工具中公开信息？ - - * 例如， Nsq 有一个不错的管理界面，可提供有关队列行为的反馈。 这样您就可以看到队列正在备份，但这是因为一个主机。 - - * 部署系统的 Web UI。 使部署和查看部署历史记录变得容易。 如果 Nagios 快要疯了并且刚刚部署了某人，则可能与他们有关。 - -## 经验教训 [ - -* **知识就是力量** 。 您越了解工作性质，可以做出更好的决策，工作效率就越高。 效率意味着您可以以更低的成本制造更大，更快的系统。 - -* **构建处理泄漏抽象的内容** 。 如果您正在使用抽象层来隐藏系统的基础分布式特性，那么它将最终冒泡。 您的代码必须理解并处理所有泄漏。 - -* **如果可以将** 全部放在一个盒子中。 如果您不需要分布式系统，请不要构建一个。 它们复杂且建造昂贵。 - -* **在面向服务的体系结构中，故障意味着功能减少而不是停机**。 - -* **SOA +队列+异步消息传递确实很强大** 。 这种方法可以隔离组件，让工作同时进行，让盒子独立发生故障，同时使组件仍然易于推理。 - -* **当速度和一致性至关重要时，请使用同步请求。** 。 给用户一个错误，而不是缓慢或错误的答案。 - -* **事件样式消息比命令样式消息** 更好。 它们允许更好地隔离系统之间，并自然支持多个使用者。 帮助保持服务重点，而不用担心服务超出预期范围。 - -* **注释而不是过滤器** 。 生产者级别的筛选器基于对下游服务关心的假设进行烘烤。 例如公共链接与私有链接。 从流中过滤出私人链接意味着对私人链接感兴趣的服务将无法获得所需的链接。 相反，请使用链接是私有链接还是公共链接来注释事件，并让服务仅在他们关心的事件类型上运行。 - -* **服务应该相互配合** 。 使用反压可防止服务过载，并绕过故障服务。 - -* **如果没有 Nagios 检查，则几乎可以确定是** 。 您只是还不知道。 - -* **工具应将信息公开给人类** 。 在正确的时间向正确的人提供正确的信息。 - -## 相关文章 - -* [关于黑客新闻](https://news.ycombinator.com/item?id=8031606) - -假设所有负载平均分布在 8 个高峰时段，即每秒仅 17 个请求（6000000000/400/30/8/3600）。 他们在用 400 台服务器做什么？ 考虑到缩短的请求几乎不会导致负载，因此每秒 17 个请求是什么。 每个 CPU 内核应为> 100，并每秒。 - -这里是原始演讲的作者。 真的很受宠若惊。 - -首先，对文章进行了较小的更正，是〜20 名工程师（50 人公司）而不是 50 名工程师。 - -第二个建议：tobi，并非所有 400 台服务器都在处理重定向。 约 30 台服务器处理来自外界的所有传入流量，包括缩短，重定向，api 请求，Web ui 等。其余 400 台服务器专用于各种服务，包括存储和组织用户数据或提供各种形式的处理和分析（数据库） ，指标，网页抓取，文本分析等）。 - -@tobi 400 可能包括质量保证和生产环境，并且将分布在 HDFS /数据库集群，队列处理器，应用服务器等上。此外，该帖子似乎表明他们正在使用商品硬件，这可能意味着它们的主机不在 不是多租户。 - -tobi，“ 400 台服务器”！= 400 台 Web 服务器。 - -是的，加上单击！=流程，并且在 8 个小时内完全均匀地加载是一个可怕的假设（考虑到即使在 Twitter 高峰期间，他们也希望获得低延迟的同步响应，而互联网上没有“营业时间”之类的东西）。 - -这是一个仍然人为但更现实的示例： - -[6000000000（点击）x 4（每次点击的平均进程数）] -/ [400/3]（每个进程平均 3 个服务器层） -/ 30（每月天数） -/ 24（小时） 每天） -* 10（峰值时间突发） -/ 3600（每小时秒数） - -在突发期间没有故障的情况下，向任何特定服务器提供 700 msgs /秒的速度。 - -6B req / sec == 200M / day 平均值 - -尽管这可以达到〜3000 / sec，但必须意识到平均值和峰值相差很大。 您不能为平均水平设计架构师。 峰值可以提高 10 倍。 - -像这样的分布式系统最大的麻烦就是一致性：确保不会将相同的短 URL 分配给两个不同的 URL。 我想您可以通过规范化和哈希 URL 并在哈希上共享来缓解这种情况... - -适用于所有 API 和 Web 的 30 台服务器非常合理。 用于分析和相关服务的 370 台服务器（占 92.5％）揭示了赚钱的地方。 - -我同意，仅 1 核 CPU 可以很好地满足 17 rps 的要求。 @bitlydevs，您应该阅读 snabswitch 如何仅通过一个节点即可提供 10M rps。 - -http://highscalability.com/blog/2014/2/13/snabb-switch-skip-the-os-and-get-40-million-requests-per-sec.html - -“带有 1x RAM 的 4 盒总是比带有 4x RAM 的 1 盒便宜。” - -怎么/为什么？ - -是的，在这里听 santosh，老兄显然知道更好 \ No newline at end of file +@Barry：“请记住，从 WordPress.com 提供的图像中有 85％是动态转换的-即时进行的。” ：我不明白。 什么是动态转换的？ 无论如何，如果您需要对图像做一些事情（例如缩放，压缩），则可能是在第一次调用图像时完成了，然后将结果缓存了，还是我错过了一些东西？ \ No newline at end of file diff --git a/docs/103.md b/docs/103.md index 400343c..beeb085 100644 --- a/docs/103.md +++ b/docs/103.md @@ -1,116 +1,257 @@ -# 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序 +# 史诗般的 TripAdvisor 更新：为什么不在云上运行？ 盛大的实验 -> 原文： [http://highscalability.com/blog/2014/7/7/scaling-the-world-cup-how-gambify-runs-a-massive-mobile-bett.html](http://highscalability.com/blog/2014/7/7/scaling-the-world-cup-how-gambify-runs-a-massive-mobile-bett.html) +> 原文： [http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html](http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html) -![](img/e4028d1797a9d7ec80e7ae1eee87fd4d.png) +![](img/f5d73e9a698265918ca5768397e905ed.png) -*这是 [cloudControl](https://www.cloudcontrol.com) 的 Elizabeth Osterloh 和 Tobias Wilke 的来宾帖子。* +*这是 [Shawn Hsiao](http://www.linkedin.com/in/phsiao) ， [Luke Massa](http://www.princeton.edu/rocky/people/residential-college-advis/luke-massa/) 和 [Victor Luu](http://www.linkedin.com/pub/victor-luu/57/243/91a) 的来宾帖子。 肖恩负责运行[，TripAdvisor](http://www.tripadvisor.com/) 的技术运营团队，卢克和维克托在去年夏天加入了他的团队。 该帖子由 TripAdvisor 的工程负责人 [Andy Gelfond](http://www.linkedin.com/in/andrewgelfond) 介绍。* -初创企业在构建软件时所面临的问题与大公司完全不同。 较大的公司在更长的时间范围内开发项目，并且通常拥有整个 IT 部门来支持它们创建定制的体系结构。 当初创公司有一个好主意，它广受欢迎并且需要快速扩展时，情况就完全不同了。 +距离我们上一篇关于 [TripAdvisor 建筑](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html)的帖子已经过去了一年多。 这是令人兴奋的一年。 我们的业务和团队不断增长，我们现在是一家独立的上市公司，随着我们的发展，我们继续保持/扩展我们的开发流程和文化-我们仍然经营着数十个独立团队，每个团队继续在整个 整个堆栈。 唯一改变的是数字： -Gambify 就是这种情况，Gambify 是一种组织投注游戏的应用程序，适时发布了世界杯足球赛。 该公司成立于德国，仅由两个人经营。 当他们设法获得一些主要认可（包括阿迪达斯和德国队明星托马斯·穆勒）时，他们不得不为突然涌现的用户以及非常特定的高峰时间做好准备。 +* 每月 5600 万访客 +* 每天有 350M +页的请求 +* 120TB +的仓库数据在大型 Hadoop 集群上运行，并且迅速增长 -## Gambify 应用：基本架构 +我们还有一个非常成功的大学实习计划，该计划于去年夏天招募了 60 多名实习生，所有这些人很快就入职，并且与我们的全职工程师一样从事相同的工作。 -Gambify 的核心是基于 Symfony2 的 PHP 后端，该后端通过 Rest API 将数据提供给前端。 前端是用于桌面浏览器的 Ember.js 应用程序，其中的 PhoneGap 包装用于移动应用程序。 +这里反复出现的一个想法是，为什么不在云上运行？ 我们的两个暑期实习生 Luke Massa 和 Victor Luu 通过在 Amazon Web Services 上部署我们网站的完整版本来认真研究这个问题。 用他们自己的话说，以及很多技术细节，这里是他们去年夏天所做的事情的故事。 -Gambify 代码库分为多个包，可用于不同的场景，例如 随后是世界杯的比赛场景，然后是德国国家联赛或其他欧洲联赛的联赛场景。 为了存储数据，Gambify 除了使用结果表之外，还使用常规的 MySQL 数据库。 在这里，他们将赌注汇总到 Redis 中。 +## 在 AWS 上运行 TripAdvisor -## 主要挑战 +今年夏天，我们在 TripAdvisor 开展了一个实验项目，以评估在亚马逊的弹性云计算（EC2）环境中运行整个生产站点的情况。 当我们第一次尝试在 EC2 环境中托管 www.tripadvisor.com 和所有国际域时，我们工程组织的许多成员的回应非常简单：当我们已经拥有自己的硬件时，真的值得向 Amazon 付钱吗？ 而且效果还可以吗？ -* **在没有专门团队的情况下实现可用于生产的基础架构**。 最初，团队从托管在专用服务器上的较小，较不高级的应用程序版本开始。 他们面临配置和维护它的困难，因此决定专注于开发应用程序本身。 他们需要一个易于维护和扩展的解决方案。 +几个月后，随着我们在云端的伟大实验即将结束，**答案当然是肯定的，**是。 在这段时间内，我们学到了很多东西，不仅是关于 AWS 的惊人好处和严重的陷阱，而且还了解了如何在我们自己的传统托管环境中改进架构。 尽管我们还没有准备好翻转 DNS 并通过 AWS 发送所有流量，但事实证明，它的灵活性是一种非常有用和实用的学习工具！ -* **规划基于需求的资源使用，尤其是在比赛**之后的高峰时段。 用户倾向于在游戏后立即登录以查看比赛结果及其排名-此时，负载可能会增加到每分钟 10.000 个请求。 +## 项目目标 -* **最大化应用速度，** **，尤其是在更新匹配结果和排名**时。 用户期望在使用该应用程序时将延迟降到最低，并在访问当前结果和排名时获得快速响应。 +* 使用 EC2 构建整个站点，并演示我们可以获取生产级流量 +* 为此操作建立成本模型 +* 确定有助于降低成本和提高可伸缩性的体系结构更改 +* 使用此迁移到新平台可以发现我们当前架构的可能改进。 -## 与云基础架构集成 +## 建筑 -Gambify 决定在如此小的团队中配置和维护专用服务器很困难，因此决定搜索平台即服务提供商。 他们决定使用 cloudControl PaaS。 +我们的目标是为现场站点建立一个功能完备的镜像，以实现生产级流量。 我们将其称为“ Project 700k”，因为我们试图每分钟处理 700k HTTP 请求，并且具有与我们的实时站点相同的用户体验。 用户体验将通过请求响应时间统计信息来衡量。 经过大量的摆弄和调整，我们最终提出了以下系统架构： -**Buildpacks** ：Gambify 是用 PHP 编写的，最初在 Apache 服务器上运行以进行测试。 cloudControl 平台使用 Buildpack 系统，这是一种用于准备要部署的映像的开放标准，它已成为事实上的云平台之间互操作性的行业标准。 cloudControl PHP buildpack 提供了与原始设置相同的开源组件，因此 Gambify 能够将其现有应用程序“插入”到 cloudControl 平台，而无需进行任何重大更改。 +**虚拟私有云**-我们所有的服务器都托管在单个 VPC 或虚拟私有云中。 这是亚马逊在单个地理区域内提供虚拟网络的方式（我们碰巧在美国东部弗吉尼亚州，但理论上我们可以在加利福尼亚州，爱尔兰等地启动一个全新的 VPC），所有实例都使用私有 IP 相互寻址 。 -**容器**：cloudControl 平台基于容器。 容器基于 LXC 技术，并且包含堆栈映像，部署映像和配置。 堆栈映像提供了底层操作系统和通用库。 部署映像包含现成的应用程序。 这些配置可以包括数据库和其他第三方服务的访问凭据。 +**子网**-在 VPC 内，我们有两个子网，为简单起见，每个子网当前位于同一可用区域中，但我们计划稍后将它们扩展以实现冗余。 第一个子网具有其安全设置，允许来自 Internet（我们称为公共子网）的传入和传出流量。 第二个私有子网，仅允许来自公共子网的流量。 Public Subnet 包含一个登台服务器，它使我们可以通过 SSH 进入私有子网，以及一组稍后将要介绍的负载均衡器。 我们所有的服务器，内存缓存和数据库都位于专用子网中。 -可以垂直缩放容器（跨多个实例）或水平缩放容器（通过增加内存和处理能力）。 Gambify 能够在单个容器上测试其应用程序，然后使用 cloudControl 的粒度扩展功能根据需要进行扩展。 +**前端和后端服务器**-前端负责接受用户请求，处理请求，然后向用户显示请求的数据，并提供正确的 HTML，CSS 和 javascript 。 前端使用 Java 处理大多数此类处理，并且可以查询内存缓存或后端以获取其他数据。 假设服务器正确地进行了负载平衡，那么所有前端的创建方式都是相同的，并且应该承载相似的流量。 -**路由&请求分发**：cloudControl 路由层使用反向代理负载平衡器集群来管理用户请求的接受和转发到平台上运行的应用程序。 智能 DNS 以循环方式提供快速可靠的域名解析服务。 所有节点均等地分配到三个不同的可用区域，但可以将请求路由到任何其他可用区域中的任何容器。 为了保持较低的延迟，除非没有可用的路由层，否则路由层将尝试将请求路由到相同可用性区域中的容器。 这是自动处理的，因此 Gambify 可以将此方面外包给 cloudControl 作为服务提供商。 +后端实例被配置为托管特定服务，例如媒体或度假租赁。 由于这种分布，一些服务器配置为执行多个较小的作业，而其他服务器配置为执行一个较大的作业。 这些服务器还可以进行内存缓存或数据库调用来执行其工作。 -## 优化基于需求的资源使用 +**负载均衡器**-为了充分利用弹性，我们使用 Amazon 的 ELB（弹性负载均衡器）来管理前端和后端服务器。 前端专门属于一个池，因此仅在一个负载平衡器下列出。 但是，后端可以执行多种服务，因此在多个负载平衡器下列出。 例如，后端可能负责搜索，论坛和社区服务，然后成为这三个负载平衡器的一部分。 之所以可行，是因为每个服务都在唯一的端口上进行通信。 所有前端服务器和后端服务器都配置为发送和接收来自负载平衡器的请求，而不是直接与其他实例进行通信。 -Gambify 使用 New Relic 监视其性能。 这有助于他们确定游戏之前，之中和之后的用户高峰模式。 他们还实时使用 Google Analytics（分析）来查看用户负载何时增加，而请求负载却没有增加。 +**登台服务器**-另一个登台实例，我们称为 stage01x，用于处理进入 VPC 的请求。 它备份代码库，收集时序和错误日志，并允许 ssh 进入实例。 由于 stage01x 必须位于公共子网中，因此它会从 Amazon 那里获得一个弹性 IP，该 IP 还在早期阶段就将面向公众的负载均衡器服务于托管在其背后的 AWS 站点。 stage01x 还会维护一个 Postgresql 数据库，其中包含服务器的主机名和服务。 这在添加新实例并在其整个生命周期内进行管理方面起着至关重要的作用，我们将在后面讨论。 -Gambify 优化的主要部分已预先完成，并通过使用 Loader.io 的负载测试进行了说明。 这样一来，Gambify 就可以在客户群过大而无法处理工作负载之前发现瓶颈。 +### VPC 站点架构图 -**Gambify 应用：原始状态** +![](img/463acdb6deab4bdc0a2f69fb29aa7ffc.png) +（[原尺寸](http://farm9.staticflickr.com/8450/8044909998_04e8375ef7_o.png)） --10 个容器@ 512 mb +**示例 HTTP 请求**-为了更全面地了解该体系结构，让我们逐步浏览一下互联网上的 HTTP 请求（用红线标出）。 它通过弹性 IP 在作为运行 NGinx 的公共子网中的负载平衡器的登台实例处进入 VPC。 然后，负载平衡器将流量路由到前端负载平衡器之一。 然后，ELB 重定向到它们后面的前端服务器，这些前端服务器开始处理请求。 在这里，我们有两个负载均衡级别，可以将请求分为不同的池以进行 AB 测试。 --数据库：MySQLd“微型”附加组件 +然后，前端服务器决定它需要向后端服务发出请求，该服务也由 ELB 后面的许多后端服务器运行。 后端处理该请求（可能向其他后端发出请求）或数据库服务器（其结果存储在内存缓存服务器中），然后将信息发送回前端，该信息通过负载均衡器发回 给用户。 -![](img/c550fd9b9963aa48ed21e58372f081a8.png) +**实例类型**-EC2 具有极好的可扩展性，因此，使用某些脚本，我们能够快速更改网络中后端服务器和前端服务器的数量。 因为所有后端和前端都在负载均衡器后面，所以没有人需要直接解决它们或知道它们是什么。 -（Loader.io：60 秒内有 2000 个客户端） +但是，数据库更难扩展，因为它们不在负载均衡器的后面。 可以预料，memcache 会根据实例数和每个实例上的 RAM 对键值绑定进行哈希处理，并假定两者都是固定的。 内存缓存的版本允许添加/删除成员资格，但是我们目前不在应用程序堆栈中使用它。 因此，memcache 的实时扩展将不是简单或有效的。 -从优化角度来看，Gambify 主要通过使用索引字段查询来优化数据库访问，将对时间不敏感的部分移动到异步处理中，并在某些请求中跳过一些抽象层（ORM）。 这些优化有助于缩短单个请求的加载时间。 +我们为前端，后端和内存缓存实例选择了 m2.xlarge（超大内存）实例，因为它们具有适当的内存量和较高的 CPU。 我们的数据库使用 cc2.8xlarge（群集计算八个额外的大实例）实例，这些实例需要极高的 iops 才能处理整个站点的空缓存而导致的冷启动。 -为了处理高峰时间，他们使用 cloudControl 的粒度扩展功能来进行扩展，尤其是在人们登录游戏后立即查看结果和得分时。 然后，负载可以增加到每分钟 10.000 个请求。 +## 这个怎么运作 -白天，Gambify 只能由一名工人在六个（128mb）容器上运行。 在比赛中，比赛后八名工人将它们最多扩展到 18（1024mb）个容器。 MySQL 数据库在扩展方面面临挑战，因此他们决定使用一种大型 RDS 设置。 对于未来，他们正在考虑迁移到可伸缩数据库。 +**TACL** -我们的前端和后端服务器通过 TACL（TripAdvisor 配置语言）进行配置，TripAdvisor 配置语言描述了如何设置实例。 本质上，我们创建了一个“ aws.ini”文件，该文件定义了在何处发送和接收某些请求。 -**Gambify 应用：当前状态** +例如，论坛数据（DEV_DB_FORUMS_HOST）存储在 dbs001x 上，社区数据（DEV_DB_COMMUNITY_HOST）存储在 dbs003x 上。 Memcache 实例通过其主机名直接引用。 ![](img/02c19b7722d8bb65e9a2c6999a8f7561.png) --18 个容器（512 mb） +如前所述，每个前端池和后端服务组由一个负载均衡器表示，我们分别以 lbf 或 lb 作为前缀。 --MySQLd“中”加载项 +![](img/a953bfc4fa06d8519b780c4bbd83a307.png) -![](img/012c917d86d8faf361b2b698749b65aa.png) +每个需要 aws.ini 中信息的服务器都将其主机名添加到文件头中。 例如，这就是 web110x 的 aws.ini 文件的标题。 设置 -(Loader.io: 2000 clients in 60 seconds) +TACL，以便服务器在配置，启动和提供服务时引用此 aws.ini 文件。 为了进行架构更改（例如添加新数据库），我们将修改并分发此 aws.ini 文件，并启动相关实例。 通过这种负载均衡器抽象，添加新的前端和后端实例非常容易，因为它们将被适当的 ELB 包含。 -## 最大化应用速度 +**Naming_service DB** -我们当前的活动站点使用托管在托管数据中心中的物理服务器。 因此，扩展或升级实例非常昂贵且耗时。 使用 Amazon EC2 的主要优势在于，我们可以廉价，快速地做到这一点，以应对流量的逐分钟变化。 为了对此进行管理，我们在 stage01x 上保留了一个存储命名数据库的数据库。 -Gambify 的许多应用程序速度优化都是通过异步作业处理来完成的，以便保持主要请求的快速。 为此，Gambify 使用了几个与 cloudControl 平台集成的第三方附加服务。 作业队列通过 Redis 处理。 +由于 EC2 实例具有相对短暂的性质，因此该数据库对于我们的运营需求至关重要。 我们偶尔会终止实例，并可能启动替换实例。 开发与此数据库一起使用的 API 可确保正确“重构”系统，例如，将旧实例从负载均衡器中删除。 当然，通过启动新实例进行扩展时，此数据库是必需的。 它为每个给定的前端和后端实例存储主机名，实例 ID 和服务。 stage01x 上的脚本用于为新启动的实例查找和分配主机名。 -**用户搜索**：异步处理的部分之一是外部 Web 服务，例如用户搜索功能。 用户与搜索索引（Searchly）同步，该索引使人们可以找到他们的朋友。 +![](img/bfbd43b49ddb60c727c1f9df2dadacaf.png) +![](img/a0bceec44cd36f7912c47102a3ca2423.png) -**用户内容**：Amazon S3 用于存储用户内容，例如。 个人资料图片。 图片上传被异步处理并调整大小，以防止移动客户端在仅需要显示缩略图时加载更大的原始图片。 +**定制服务器映像**-我们为前端和后端服务器创建了两个定制的 CentOS 5.7 映像。 在他们的/etc/rc.local 中，我们添加了一个脚本，该脚本负责完全配置和启动实例。 启动后，它将在 stage01x 上的命名数据库中查询其主机名和服务，将其添加到适当的负载均衡器中，然后对其进行配置和反弹。 “反弹”是指启动或重新启动需要在服务器上运行的应用程序的过程。 -**下注包装**：Gambify 能够非常快速地处理赌注并发布结果，因为所有赌注都分组为 1000 个赌注的包装。 然后从 Redis 的作业队列中处理这些。 因为他们知道最大的工作量是在每次比赛之后发生的，所以他们启动了多个工作人员来尽快处理结果。 这些作业将加载所有赌注，并为每个单独的赌注计算分数，然后重新计算表格中的相应分数。 +我们对这种模块化的启动感到特别兴奋，因为它使测试后端服务更加容易。 从事度假租赁服务的团队可以在 EC2 上启动一个度假租赁实例，并专门在不影响整个测试环境的情况下工作，而不是在一个开发人员的工作站上启动和启动整个网站。 -## 解决方案摘要 +**时间和错误日志**-我们的前端服务器在接收和处理请求时生成日志。 使用 stage01x 和某些 ssh 隧道传输，我们可以远程压缩这些日志文件，并将它们发送回本地工作站进行分析。 -* **在没有专门团队的情况下实现可用于生产的基础架构**。 Gambify 团队决定专注于开发应用程序本身，并将基础架构外包给 cloudControl。 通过 cloudControl，资源分配，路由和请求分配得以自动化。 +## 一路走来的问题 -* **规划基于需求的资源使用，尤其是在比赛**之后的高峰时段。 通过使用 New Relic 监控性能，Gambify 能够确定比赛之前，之中和之后的高峰时间。 他们使用 cloudControl 的细化缩放功能在比赛后的高峰时段直接放大，然后在一天的其余时间进行缩减。 +**停电**-2012 年 6 月 15 日，EC2 美东地区发生故障，我们失去了生产力。 2012 年 6 月 29 日，EC2 US-East 发生故障，我们丢失了一些实例。 Amazon 确实提供了可用区（相隔 20 或 30 英里）以实现冗余，因此这会稍微减轻影响。 但是，总的来说，亚马逊可能会以其数据一致性而不是数据可用性而闻名。 +[](http://technewspedia.com/wp-content/uploads/2012/06/6522_Chaiten-660x350.jpg) -* **最大化应用速度，** **，尤其是在更新匹配结果和排名**时。 Gambify 使用了几种集成的第三方服务来最大化其应用程序中的响应时间，特别是通过使用 Redis 进行异步作业处理。 +**磁盘空间不足**-如上所述，我们的服务器生成计时，错误和许多其他类型的日志。 在测试的早期阶段，我们的日志（尤其是错误日志）将快速增长，并占用数 GB 的磁盘空间。 我们决定利用 m2.xlarge 的 420GB 临时存储空间。 之前，我们完全避免使用临时存储，因为它是临时存储（重新启动后数据不会持续存在）。 但是，这对于存储日志很好。 Cronjobs 每小时都会将日志发送到本地工作站，因此我们仍然能够收集和备份重要数据。 +[](http://kpao.typepad.com/.a/6a015392891771970b01543663249d970c-pi) -## 在比赛结束时 +**实例不可用**-我们尝试在 us-east-1b 中使用新的 SSD hi1.4xlarge 实例，但这些实例通常在高峰时段不可用。 我们的 Amazon 联系人告诉我们，由于需求旺盛，这些实例确实不可用。 我们在 us-east-1d 中遇到了类似的问题，其中我们未能启动 m1.xlarge 实例。 这提醒我们，EC2 尚不具有无限的服务规模，因此需要在操作模型中建立实例类型及其数量的必需储备。 -这就是在德国比赛之后，对于 Gambify 来说，真正的请求高峰看起来是什么样的-特别是 6 月 30 日对阿尔及利亚的比赛。 有趣的事实：根据 Gambify 的说法，这场比赛的顶峰略低，因为当德国获胜时，人们会庆祝而不是检查结果。 +作为附带说明，每个 Amazon AWS 帐户均以 20 个实例上限开始，随着我们的实验的进行，我们需要与我们的 Amazon 联系人合作以将限制增加到 60 个实例，然后增加到 600 个。 我们的 ELB 遇到了类似的限制。 同样，我们的联系很快就使我们获得了批准，从而使我们可以使用 20-30 个负载均衡器。 +[](http://media.amazonwebservices.com/blog/console_ec2_hello_hi1_mndoci_1.png) -![](img/5577bfeddfb12ef440ac03397f234b5b.png) +**未充分利用的，配置错误的数据库**-简而言之，我们发现我们需要对 postgresql 数据库（位于 cc2.8xlarge 实例中）进行其他修改，以使其在 EC2 环境中正常工作。 下面列出了其中一些。 这些变化帮助我们了解了自己的环境与亚马逊环境相比的工作方式。 -## 目标！ +* enable_hashjoin = off（最初为 on） +* enable_mergejoin =关（开） +* shared_buffers = 4GB（8GB） +* Effective_cache_size = 48GB（16GB） -垂直扩展不是要向同一台机器增加更多功率，水平扩展不是要添加新机器吗？ 您在 cloudControl 容器部分中说了另一种方法。 +**丢失的数据**-EC2 通过 EBS 卷为数据存储提供了很好的抽象级别。 为了扩展数据库实例的存储，我们只需为每个数据库实例创建 1 TB EBS 卷，将其附加到实例上，然后使用``mkfs''和``mount''Unix 命令将其装入。 -非常有趣的文章，因为我目前在相同情况下（仅一名开发人员）开发服务。 +使用 EBS 卷时，我们遇到了一些问题。 当我们将一个 EBS 卷重新装载到另一个实例时，在将一个 EBS 卷转移到另一个实例时，云以某种方式删除了所有还原的成员数据，我们不得不花半天的时间在该实例上还原数据库。 此外，在尝试使用“ tunefs”和“ resize2fs”之类的命令从快照调整 EBS 卷大小时，我们遇到了问题。 使用这些调整大小的卷的实例在一天后遇到实例可达性错误，我们不得不运行“ e2fsck”几个小时来清理它们。 -只是一个错误：“容器可以垂直缩放（跨多个实例）或水平缩放（通过增加内存和处理能力）” +当然，我们在安装和调整大小过程中可能犯了一些严重的错误，因此不必过分担心 EC2 的这种行为。 我们发现，一般来说，AMI 和 EBS 快照的可用性有助于我们快速启动新的数据库实例。 例如，如果我们想将 dbs001x 上的数据分成两台机器，则只需创建 dbs001x 的映像，从中启动一个新实例，然后适当地重定向流量。 显然，此功能仅限于只读数据库，创建 1 TB 设备的映像通常是一夜之间的工作。 我们仍在寻找提高数据库冗余性和可伸缩性的其他方法。 我们当前的实时站点使用心跳和 DRDB 进行恢复，并且希望了解如何将其应用于 EC2。 -垂直扩展：增加内存和 CPU -水平扩展：添加更多服务器实例 +**不相等的实例**-一方面，我们尝试对前端和后端服务器的 CPU 性能进行基准测试，所有这些服务器的大小均为 m2.xlarge。 我们使用命令 bc 设置了一个简单的数学运算 2 ^ 2 ^ 20 的时间，发现该时间分为两组，具有统计意义。 我们在测试的实例上运行 cpuid，更快的组在双 2.40 GHz 处理器上运行，而较慢的组在双 2.66 GHz 处理器上运行。 尽管这不是我们网站功能的主要问题，但它使确定我们可以使用的计算能力变得更加困难。 -我很好奇这种设置的成本，以及它们在高峰时段如何变化？ 与类似的专用服务器解决方案（具有如此规模）的成本有何比较？ +另外，即使我们的前端计算机都具有相同的大小和相同的 AMI，大约 10％的前端计算机也无法正常弹跳。 同样，这可能是我们配置而不是 Amazon 的无法预料的问题。 -实际上，缩放是错误的方法。 非常不幸的混搭...我们将联系 HS 进行修复。 +**负数时间**-通常情况下，低俗的时间值得庆祝。 但是，当我们分析一些最近的计时日志时，我们发现某些最小服务呼叫时间为负数。 这些计时统计信息是通过调用 Java.currentTimeMillis（）来计算的。 我们仍在对此进行调查，并且有兴趣尝试通过一个简单的 Java 应用程序来复制问题。 -通常，云服务提供更大的灵活性，而 PaaS 通常专注于在整个应用程序生命周期中提供自动化和编排，以帮助开发人员提高其日常工作效率。 +**窃取周期**-运行 m2.xlarge 实例时，我们预期窃取周期为 1％或 2％。 但是，当前端处于负载状态时，我们在一两分钟内会遇到高达 7-8％的抖动。 我们的 Amazon 联系人告诉我们，这仅仅是由于每个实例的负载。 -成本收益通常不在于购买的每台原始计算能力的价格比，而在于效率的提高，更多的是效率的提高，即通过使用该服务节省的时间，您可以专注于重要的事情。 +另外，我们在 m1.small 实例上进行了实验，并通过数学计算接管了它的 CPU 使用率。 跑马场表明，其中 98％用于数学计算，另有 2％被盗。 但是，在 Amazon 的监视服务 Cloudwatch 上，该实例似乎以 98％的 CPU 利用率运行，而不是 100％的全部利用率。 这可能会导致较大的窃用周期问题，因为无法确定某个实例是否由于窃用周期而被用完，或者是否“未充分利用”。 通常，我们希望看到更多有关 CPU 性能的保证。 -可以这样想：使用专用服务器，为服务器支付的费用较低，但是会附加大量的运营成本。 对于 PaaS，部分运营成本包含在使用服务的成本中。 但是总体而言，PaaS 的成本应该更便宜，因为运营商由于规模经济而降低了运营成本。 +**组播**-不支持。 我们使用 JGroups，这取决于它的工作。 有人告诉我们使用 vCider 或 vpncubed 来模拟多播。 vCider 要求我们升级到 CentOS 6，并且 vpncubed 的安装时间很长。 在我们的优先级列表中，该级别较低，但是我们将来希望进一步探索这些选项。 -小型项目通常可以很便宜地启动并利用收益。 当您成长时，它通常会保持很长一段时间的经济性。 最终可能会有一点，DIY 再次变得更加高效。 但这是一个问题，一旦您足够大就可以轻松解决。 \ No newline at end of file +**ELB 延迟**-尽管我们将所有后端置于特定负载均衡器之后的体系结构对于 50-60k reqs / min 以下的流量非常有效，但我们发现 ELB 大大降低了我们的后端响应时间，尤其是对于 二手服务。 为了测试这一点，我们让一个前端直接将流量发送到后端，而不是通过 ELB。 我们在下午 4:50 左右更改了此设置，使负载测试流量保持不变，并发现服务时间显着减少。 + +![](img/aeec3c71a61cd03e1cc18f3f990c0e63.png) + +我们的亚马逊联系人告诉我们，ELB 可能需要预热。 我们怀疑负载平衡器也是云平台，默认情况下可能是小型实例。 预热可能只是将这个给定平台升级为可以处理更高流量负载的平台的问题。 + +## 负载测试 + +该网站的原始设置存在一些问题。 我们无法在前端使用 Amazon 的 ELB，因为我们的前端实例隐藏在私有 VPC 中。 我们发现有些公司通过将前端实例保留在公共 EC2 网络中来解决此问题，但是这种架构会使我们的 VPC 设置无效。 + +我们使用了另一位工程师先前开发的负载测试系统，该系统获取了真实现场流量的存档日志，并以一定的请求数/分钟发送。 最初，我们将此流量定向到 stage01x 实例。 但是，到我们达到 20k reqs / min 时，很明显我们需要专用的实例来处理流量。 我们将这些实例命名为 lod01x 至 lod04x ，这些实例负责将 HTTP 通信发送到六个前端 ELB。 + +**VPC 带宽问题**-在测试的早期阶段，我们在 VPC 之外的实例将流量发送到 VPC。 但是，我们发现，无论我们如何扩展站点，负载测试的上限均为每分钟 5 万请求。 平均页面大小为 18KB，看来 VPC 仅接受 100Mbps 的流量。 我们的 Amazon 联系人向我们保证没有此限制，但是为了确保所有负载测试都保留在 VPC 中。 + +**NGinx 问题**-在我们的早期阶段，我们还为每个 lod 实例安装了 NGinx 负载平衡器。 但是，后来发现这成为我们测试的瓶颈，因为小型实例无法处理这么多的“打开文件”。 我们将其抓取，然后将流量直接发送到负载均衡器，而没有初始的 NGinx 负载均衡。 + +这是我们网站的配置，最高可达 70 万请求/分钟。 在提高请求率的过程中，我们无法保持相同的用户体验。 请求响应统计随着请求率的提高而恶化，我们将在后面详细讨论。 + +![](img/85cd8fbdd58983b90edd9cb4077d6ce8.png) + +**现场比较**-我们的现场有 80 个前端和 52 个后端，每个都有 24 个核心。 总共增加了 3168 个内核。 在我们的最高 AWS 配置下，每个 270 个前端和 70 个后端分别具有 2 个核心，我们只有 680 个核心。 这导致了后端垃圾回收的问题，我们将在后面讨论。 + +我们的 Amazon 内存缓存的运行情况相当不错。 我们通过 libmemcached-tools 附带的 memslap 实用程序进行了基准测试，发现使用 12 个中等的物理服务器，我们最初的 12 个 Amazon memcache 实例的性能大约是我们 Memcache 集群容量的 80-90％。 + +![](img/b8089280ce17cabf61bc0bd770793b66.png) +![](img/8cc4733ffe4a0454c7ac45cf2ab4621c.png) + +## 时间和错误编号 + +每个前端服务器都会自动记录发送和接收的每个请求的计时数据。 压缩后每小时发送一次到“伐木工人”服务器，在其中计算基本统计信息，并将请求时间细分为各个部分，例如 google，数据库和 xml 调用。 在评估站点性能时，我们主要关注平均总时间和 cpu 时间。 + +![](img/8afc1f118d7ded8e3815ce1c0ff7d379.png) +（[原尺寸](http://farm9.staticflickr.com/8320/8044985089_c26e7e7a98_o.png)） + +[![](img/27c03f4a1751e7b77eeedf992c25e325.png) +（](http://farm9.staticflickr.com/8320/8044985089_c26e7e7a98_o.png) [全尺寸](http://farm9.staticflickr.com/8310/8044991710_8b0bdfcd23_o.png)） + +这两个图表显示了我们从 20k reqs / min 扩展到 60k reqs / min 时，Hotel Reviews Servlet 的时间统计信息（并非所有请求都与酒店评论有关）。 根据数据，向上扩展发生在星期五的 3-4pm 之间，直到 5pm 才稳定下来。 我们关闭了网站过夜，然后在周六中午左右将其恢复，请求数量大约增加了两倍，请求时间大致保持相同，平均大约 200 毫秒。 + +在较低的负载下，这些延迟数与我们的实时站点相当，因为我们每分钟最多扩展 15 万个请求，因此延迟显着增加。 我们的主要 servlet（例如，Hotel Reviews 或 Typeahead）的时间比我们的实时站点慢了近 10 倍，后者的运行时间是此请求级别的两倍，并且在显示出更高的延迟之前，已经经过了四倍于此请求级别的测试。 + +ELB 是问题的一部分，如前所述。 但是，我们怀疑根本原因是垃圾回收开销超过了后端服务器的 CPU 数量。 仅使用两个内核，我们的 m2.xlarge 实例就没有足够的计算能力来跟上高请求速率的 GC 需求，这不足以实现高应用程序吞吐量和低应用程序延迟。 为了解决这个问题，我们很可能需要将后端数量加倍，或者使用功能更强大的实例以及更多的内核。 在这两种情况下，重点都将放在支持获得更高请求率并执行更多工作的服务上。 + +## 成本 + +### EC2 + +EC2 的付款包括三个主要部分：实例使用情况，EBS 使用情况和网络输出使用情况。 在生产级别上假定网络输出率为 200 GB /小时，每小时的成本约为 14.30 美元。 可以预见，前端服务器和后端服务器的实例使用对总成本的贡献最大。 + +### 现场比较 + +我们每个托管数据中心的初始设置约为 220 万美元，加上每年约 30 万美元的升级和扩展费用。 如果我们假设初始安装成本在三年内摊销，则资本支出每年约为 100 万美元。 运营支出（包括空间，功率和带宽）每年约为 30 万美元。 每个数据中心每年的总成本约为 130 万美元。 每个数据中心有 200 多台机器来支持我们的运营。 每台机器的成本通常为 7,000 美元。 + +如果我们每年在完整的 EC2 站点上花费 130 万美元，那么我们可以负担得起以下架构，前提是我们使用了一年的预留实例。 + +* 550 前端和后端 +* 64 个 Memcache +* 10 个数据库 + +的价格为$ 1,486,756.96 + +这意味着我们可以为当前配置添加更多 60％的容量（340 个前端和后端，32 个内存缓存，5 个数据库）。 + +如果我们使用三年的预留实例合同，那么这种配置每年将花费 88 万美元。 如果我们想在三年内花费 390 万美元，我们可以负担得起这样的架构： + +* 880 前端和后端 +* 64 个 Memcache +* 20 数据库 + +有趣的是，即使有这个数目，我们也只能获得 1760 个服务器核心（每台计算机上有 2 个），而我们的现场站点则可以运行 3500 个核心。 **不过，我们有信心，有了这样的资源，我们将能够正确解决我们目前在生产级流量**上遇到的垃圾收集和延迟问题。 + +### 降低总成本 + +* 预留实例-我们计算出，仅在 1 年的合同上使用预留实例将使我们的年度总费用减少一半。 我们也不需要为高峰流量保留所有实例，而是利用按需或利用率较低的保留实例来降低总成本。 +* 仅将实例调整为必要的容量。 现在，这可以通过启动不同比例的后端来完成。 +* 放置组-在我们知道将永远存在的实例组之间获得更好的性能。 + +## 故障点 + +* 前面有某种“类似于 BigIP”的实例。 当这种情况发生时，我们该怎么办？ +* 我们的负载均衡器由 Amazon 管理，当它们出现故障时会发生什么？ 引用完整的 DNS 名称而不是 IP 地址是有希望的，但这通常是未知的。 +* 自动缩放有助于前端池和后端池，确保它们都保持在一定数量。 但是，将内存缓存恢复到命中率将非常耗时，并且我们需要依靠复制的热备用数据库。 + +## 最佳实践 + +* 可以通过 AWS 管理控制台执行的所有操作都可以通过提供的命令行工具来完成。 准备好**来使**尽可能多的启动过程自动化。 +* 在自动化过程中，请确保**等待足够长的时间，以使实例既运行又可访问：** + * “ ec2-describe-instances”告诉您实例是否正在运行 + * 较新版本的“ ec2-describe-instance-status”会告诉您实例是否已通过实例以及系统可达性状态检查 +* 早期，**开发了一些用于跟踪所有实例**的系统。 这与 GUI 问题有关。 尽管您可以使用标签和名称来跟踪所有内容，但通常需要一种更加自动化的方式将所有内容组合在一起。 例如，我们在登台服务器上有一个 postgresql 数据库来管理它。 +* **停止的实例也可以是终止的实例**。 云计算的优势在于，当某个实例出现问题时，通常更容易在其位置启动新实例，而不是重新启动。 显然，请尝试找出潜在的问题！ + * 在此注意，请注意，``终止的实例''仍会在您的控制台中闲逛，并且如果您运行 ec2-describe-instances 将会显示出来。 如果您使用实例名称来区分实例，这将是一个问题，因为两个实例都会出现。 +* **清理 EBS 卷**，如站点所建议。 存储成本会迅速增加。 另外，请确保您清理快照，因为快照的收费与卷的 GB /月价格相同 +* **不要忘记短暂存储**，但不要忘记它的短暂存储。 对于累积的文件（例如错误日志）很有用。 使用 crontabs 保存重要数据。 +* **利用图像和快照快速放大**。 +* 详细的监视非常酷，但是我们发现 CloudWatch / monitoring 的免费层**足够**。 在 1 分钟和 5 分钟之间查看统计信息对于总体扩展决策而言并不那么重要。 但是，当然可以帮助对实例的代表性子集进行详细监视。 +* **ELB 也是监视实例状态**的好方法，即使它们实际上并没有使用（在更改架构后我们仍在使用它们）。 适当配置健康检查/阈值。 +* 通过**更加关注安全组设置**，可以解决许多令人沮丧的网络问题。 + +时间向后移动是虚拟化的经典问题，特别是如果 VM 从一个物理主机移动到另一物理主机上，或者仅仅是由于 VM 时钟漂移和重置而造成的。 最好也使用 nanotime API 进行时序实验-并尝试查看系统负载是否也很重要-因此生成 IO 和 CPU 负载以查看会发生什么。 如果您可以在测试 VM 的任一端请求其他实例，希望将它们分配在同一物理主机上，则可以查找相关行为 + +“暂时的（重新启动后数据不会持续存在）” + +临时磁盘在重新启动后仍然存在。 当您为实例快照时，它们只是不会被复制。 我在 EC2 上运行 Windows 操作系统，当我重新启动任何安全补丁时，非启动驱动器又回来了。 + +必填： +xkcd on the“ Cloud” +http://xkcd.com/908/ + +很棒的帖子！ 很好地了解了将应用程序完全迁移到云中的成本和收益。 + +迁移到云+自动化部署的每个部分的另一方面是能够迫使开发人员在交付给发布代码流之前，在以 1：1 的生产环境中测试其更改的能力。 自动化整个部署的能力是我对于开发团队的云所看到的最大好处之一。 + +感谢您提供的信息非常丰富。 您能否扩展一下创建 TACL 的原因？ TACL 提供的 AWS 缺少什么，或者 TACL 有什么更好的表现？ + +我觉得这是一个非常有趣的概念。 我认为您提出了一些很棒的观点，即 aws 没有婴儿规模，有些跌倒了。 我想用负数来解决您的问题，我不确定您是否跟踪多个实例的时间，希望您设置 ntp 服务器并定期同步服务器。 + +我工作的一家公司遇到了一个同样的问题，即日志时间到处都是，因为用户将访问一台后端服务器，并且它将一个时间写入 db，然后使用会回来，并再次记录 db，但是因为第一个服务器关闭了时间同步，所以它写的数量比第二个服务器大 + +成本模型中缺少的是建立和管理 DC 基础结构所需的人员。 而且，它只谈论核心，没有网络成本。 + +[摘自 PlanForCloud-RightScale]这篇文章启发我们写博客文章，比较在 AWS On-Demand 实例与预留实例上 TripAdvisor 的部署成本：http://blog.planforcloud.com/2012/10/tripadvisor-and -pinterest-costs-on-aws.html + +非常翔实！ 该实验需要多长时间才能完成？ 两个暑期实习生 8 周？ + +您好 +我们是否可以获取实时 xml tripadvisor 供稿？ + +提前谢谢！ +SJ \ No newline at end of file diff --git a/docs/104.md b/docs/104.md index d8e2c36..ece939d 100644 --- a/docs/104.md +++ b/docs/104.md @@ -1,170 +1,104 @@ -# 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集 +# UltraDNS 如何处理数十万个区域和数千万条记录 -> 原文： [http://highscalability.com/blog/2014/6/16/migrating-to-xtradb-cluster-in-ec2-at-pagerduty.html](http://highscalability.com/blog/2014/6/16/migrating-to-xtradb-cluster-in-ec2-at-pagerduty.html) +> 原文： [http://highscalability.com/blog/2012/10/8/how-ultradns-handles-hundreds-of-thousands-of-zones-and-tens.html](http://highscalability.com/blog/2012/10/8/how-ultradns-handles-hundreds-of-thousands-of-zones-and-tens.html) -![](img/cdb2e4247da951758fbc13791ce84010.png) +![](img/b27dad94d59a8812e517ea44a846a9a9.png) -*这是软件通才 [Doug Barth](https://twitter.com/dougbarth) 的来宾帖子，他目前发现自己在 [PagerDuty](https://www.pagerduty.com/) 从事运营工作。 在加入 PagerDuty 之前，他曾在芝加哥的 Signal 和在线旅游公司 Orbitz 任职。* +*这是 [Neustar](http://twitter.com/jeffreydamick) 的首席软件工程师 [Jeffrey Damick](http://twitter.com/jeffreydamick) 的来宾帖子。 Jeffrey 在过去两年半的时间里，对 [UltraDNS](http://www.ultradns.com) 的软件体系结构进行了全面的复兴。* -大约六个月前，PagerDuty 将其生产 MySQL 数据库切换为在 EC2 内部运行的 [XtraDB 群集](http://www.percona.com/software/percona-xtradb-cluster) 。 这是我们为什么以及如何进行更改的故事。 +UltraDNS 是顶级 DNS 提供商之一，为许多[顶级域（TLD）](http://en.wikipedia.org/wiki/Top-level_domain)以及[二级域（SLD）](http://en.wikipedia.org/wiki/Second-level_domain)提供服务。 这需要处理数十万个区域，每个区域包含数百万个记录。 尽管 UltraDNS 取得了全部成功，但几年前它却陷入了一片混乱，其发布计划充其量只是一个杂乱无章的事情，并且该团队仍在努力以瀑布式开发风格满足功能要求。 -## 在之前的数据库外观 +## 发展历程 -PagerDuty 的 MySQL 数据库是相当典型的部署。 我们有： +意识到必须要做的事情，团队聚在一起，确定了首先要进攻的最重要区域。 我们从代码库入手，稳定了我们的旗舰专有 C ++ DNS 服务器，建立了通用的最佳实践和自动化。 测试是非常手工的，并且不容易重现，因此我们将质量检查工程师和开发人员紧密联系在一起，以创建和审查设计，代码和自动化测试。 他们的目标是消除交付物的可变性。 我们介绍了以下工具： -* 一对 Percona 服务器将数据写入支持 [DRBD](http://www.drbd.org/) 的卷。 +* 单元测试：gtest +* 性能测试：dnsperf（已修改）&定制 pcap 工具 +* 静态分析：cppcheck +* 测试&构建自动化：Jenkins +* 任务跟踪：吉拉 +* 代码评论：鱼眼和坩埚 +* 通用框架：基于 Boost 的选定部分 -* 支持 DRBD 卷的主服务器和辅助服务器的 EBS 磁盘。 +## 环境 -* 生产数据库的两个同步副本。 （如果主服务器发生故障，我们希望能够快速切换到辅助服务器而不丢失任何数据。） +我们的各种部署环境（包括生产环境）是另一个需要立即关注的领域。 这些环境缺乏任何同质性。 数十种口味和版本的 Linux 被积极使用。 由于目标数量众多，没有统一性的开发非常复杂且容易出错，因此我们对 1 个发行版的 1 个版本进行了标准化。 为了获得更好的安装和相关软件包的可复制性，我们选择 puppet 来管理此任务。 我们采用了以下内容： -* 许多异步复制从属服务器，用于灾难恢复，备份和意外修改恢复。 +* 发行：RHEL（移至 Ubuntu） +* 配置管理：人偶 +* 指标制图：石墨 +* 监控：Nagios -## 旧设置出现问题 +## 建筑 -我们的数据库设置已经为我们服务了好几年，但是它提供的故障转移架构没有达到我们的可靠性目标。 另外，更改主机很麻烦：要从一台 DRBD 主机切换到另一台主机，我们必须在主服务器上停止 MySQL，卸载 DRBD 卷，将辅助服务器更改为主服务器状态，在该辅助服务器上安装该卷并启动 MySQL。 该设置需要停机-并且一旦 MySQL 在新服务器上启动并运行，我们就有了一个冷缓冲池，需要在应用程序性能恢复正常之前进行预热。 +为了保持市场竞争力，需要 DNSSEC，增强的定向答案和增强的流量服务等功能。 当前的体系结构很大程度上基于 Oracle，以至于它直接影响了我们 DNS 服务器的每秒查询（QPS）速率。 -我们尝试使用 Percona 的 buffer-pool-restore 功能来缩短停机时间，但是我们的缓冲池太大了。 我们发现，恢复保存的缓冲池页面使用的系统资源要比缓慢处理传入请求的流量要多。 +UltraDNS DNS 服务器需要有效地支持具有独特使用模式的 TLD 和 SLD。 TLD 通常包含数百万条记录，并且不经常（通常每天）更改，但是更改可能占记录的很大一部分。 SLD 是较小的区域，记录在数万至数十万之间，但变化率较高，占记录的百分比较小。 -另一个问题：如果发生计划外的翻转，我们的异步奴隶将无法恢复。 我们将 binlog 存储在单独的，非 DRBD 支持的磁盘上，并禁用了 sync_binlog（由于引入了性能上的损失）。 这种设置意味着我们需要在计划外翻转之后从备份中还原异步从属服务器。 +所有类型都要求尽快在全局范围内传播更改。 DNSSEC 带来了额外的麻烦，因为签名记录集以及对它们进行签名的密钥必须一起在边缘可用。 因此，我们构建了 DNSSEC 区域签名服务来满足我们对速度和扩展功能的要求。 -## 我们喜欢 XtraDB 群集 +但是我们仍然需要确保将区域的正确状态呈现给我们的 DNS 服务器并以有效的方式进行传输，因此我们用 Java 创建了专门的数据馈送服务。 我们利用 Thrift 及其基于 HTTP 的紧凑编码，使我们能够轻松地使用标准 Web 缓存进行扩展。 -关于 XtraDB Cluster 的一些事情很突出。 +### 数据馈送服务： -* 不用拥有主动和被动服务器对，我们可以让 三个 实时服务器在彼此之间同步复制更改。 这将使我们能够更快地移动连接。 +* 数据存储：嵌入式 OrientDB +* 传输：使用码头& apache-cxf 通过类似 HTTP REST 的接口进行节俭 +* 测试：Cucumber-jvm +* 静态分析：pmd，checkstyle +* 代码覆盖率：JaCoCo +* 依赖管理：常春藤 -* 由于 XtraDB 群集是多主服务器，因此它使我们可以将流量发送到多台服务器，从而确保每台服务器始终具有暖缓冲区。 在 XtraDB 群集中，异步从属服务器可以将任何节点用作主服务器，并且可以在节点之间移动而不会破坏复制流。 +结果，我们的 DNS 服务器能够迁移到一个模型，该模型将几乎每个区域都保留在内存中，同时通过无锁管道提供数据。 这带来了显着的性能改进，从而使每个 DNS 服务器的> QPS 处理能力提高了 7 倍。 -* 群集的自动节点配置非常适合我们现有的自动化。 配置新节点后，我们要做的就是提供另一个节点的地址-新节点将自动接收数据集的副本（并在同步后加入集群）。 +现在，我们不再依赖数据库复制，因为我们只将所需的数据传输到边缘，因此我们的数据传播更加可预测和稳定。 -## 我们准备了什么 +这两项增强功能使我们的节点数几乎增加了一倍，并改善了 DDoS 缓解措施，因为我们必须不断处理每秒每秒数十吉比特的攻击流量。 -为 XtraDB Cluster 准备我们的应用程序确实涉及一些新的约束。 其中一些是简单的 MySQL 调整，大部分对应用程序逻辑是隐藏的，而另一些则是更基本的更改。 +## 人 -在 MySQL 方面： +技术只是被攻击的一个方面，我们也转向使用瀑布模型中的 scrum。 这种变化花费了相当长的时间，并且在今天仍在发展，但是它已经带来了可观的收益。 另一个重要的变化是收紧我们的招聘流程，以确保我们雇用的人员符合我们的流程和技术目标。 我们从其他大公司吸取了一些教训，并完善了招聘流程，以解决候选人的技术和非技术方面的问题。 结果，我们建立了一支强大的团队，能够复兴该产品。 -* 我们需要确保仅使用具有主键的 InnoDB 表。 +## 结论 -* 我们必须确保我们的应用程序不依赖于启用的查询缓存（因为集群不支持它）。 +路上遇到了许多坎 bump，但现在我们处于一个更好的地方，可以快速适应和调整。 现在，我们的发布时间表大约是在 sprint 快要结束时每两周发布一次，但是通常会有临时更改始终在所有时间推出。 为了跟踪自己，我们现在旨在收集所有方面的指标，包括我们的软件，硬件，网络，支持问题以及交付情况，以便我们不断改进。 -* 我们必须从基于语句的复制切换到基于行的复制。 +## 服务可用性 -除了这些 MySQL 配置更改（我们能够在 DRBD 服务器端隔离测试）之外，还需要更改应用程序逻辑： +*为说明我们的改进，以下是来自加利福尼亚圣何塞的单个节点内的图表* -* 我们需要使用分布式锁定机制，因为 MySQL 锁定（例如 SELECT FOR UPDATE 语句）对于群集节点而言是本地的。 +### 稳定度： -* 因此，我们用 [Zookeeper](http://zookeeper.apache.org/) 锁替换了我们的 MySQL 锁（Zookeeper 已在该系统的其他部分中用于该目的）。 +![](img/9f72a2ed0087165b5167901234cc30a0.png) -* 考虑到需要将写入集同步发送到所有节点这一事实，我们更改了进行较大更改的作业（通常是存档作业）的逻辑，以使用许多较小的事务而不是一个较大的事务。 +### 最新版本（2012）： -## 我们如何处理架构变更 +![](img/dbede9913e6e3405f8ba3254639474fe.png) -模式更改在 XtraDB 群集中尤其重要。 有两个选项可用于控制如何在集群中应用架构更改：总订单隔离（TOI）和滚动架构升级（RSU）。 +*如果听起来有意思，我们正在[招聘](http://www.neustarlife.biz/job-openings/)！* -RSU 允许您单独升级每个节点，在 DDL 语句运行时从群集中取消该节点的同步，然后重新加入群集。 但是这种方法可能会带来不稳定性-RSU 无法避免大型表上的架构更改带来的操作问题（因为它会在 DDL 语句完成之前将写集缓冲在内存中）。 +嗨，谢谢你的这篇非常有趣的文章！ -相比之下， TOI 在所有 集群节点上同时对 应用模式升级，阻塞集群直到更改完成。 我们决定将 TOI 与 Percona 的在线模式更改工具（pt-online-schema-change）一起使用。 它确保任何阻塞操作都很快，因此不会阻塞群集。 +您能否提供一些详细信息，说明为什么从 RHEL 迁移到 Ubuntu？ -## 迁移过程 +谢谢！！ +卡尔 -建立了 XtraDB Cluster 引入的约束后，我们开始了推广过程。 +我们已经评估了 ubuntu 12.x 和 rhel 上较新的工具，库和内核所带来的任何性能优势，但更重要的是，这对于已经在本地计算机上运行 ubuntu 的开发人员来说更容易了。 -首先，我们在生产中建立了一个集群，作为现有 DRBD 数据库的从属。 通过使该群集在生产环境中运行并接收所有写入流量，我们可以开始了解它在实际生产负载下的行为。 我们还设置了指标收集和仪表板来关注集群。 +啊，好吧，:-) -与此同时，我们花了一些时间对测试集群进行负载测试，以量化其相对于现有 DRBD 设置的性能。 +谢谢！ -运行这些基准测试使我们发现，必须对一些 MySQL 配置进行调整才能获得我们一直喜欢的性能水平： +好的，我花了一秒钟的时间阅读了更改颜色（或颜色）编码的 b / c 图形。 -* 将 innodb_flush_log_at_trx_commit 设置为 0 或 2 可获得最佳写入性能（相反，将其设置为 1，则将测试可扩展性限制为只能在我们的测试 VM 上使用 4 个线程）。 由于所有更改都被复制到 3 个节点，因此即使出现单个节点的磁盘一致性宽松的情况，我们也不会丢失任何数据。 +非常令人印象深刻。 -* 需要一个大的 innodb_log_file_size 值。 我们最终为生产服务器提供了 1GB 的文件。 +-XC -在让我们感到满意的是 XtraDB Cluster 能够处理我们的生产负荷之后，我们开始了将其移入生产用途的过程。 +我想知道您还在使用 orient db 吗？ -首先将所有测试环境切换到群集设置（并针对它们运行负载和故障测试）。 如果集群挂起，我们需要一种方法来快速将我们的系统重新配置为回退到单节点集群。 我们编写了该过程的脚本，并在负载下对其进行了测试。 +你好。 +请您详细说明 OrientDB 的使用方式和性能如何？ +我们目前正在研究 OrientDB。 -实际上，将生产服务器移动到集群是一个多步骤的过程。 我们已经将生产集群设置为现有 DRBD 服务器的从属服务器，因此我们站起来并从属另一对 DRBD。 （这台 DRBD 服务器在那里，以防万一切换出现严重错误，我们需要退回到基于 DRBD 的解决方案，幸好我们最终不必这样做。） - -然后，我们将其余的异步从属设备（灾难恢复，备份等）移到了 XtraDB 集群后面。 那些奴隶坐在 XtraDB 集群后面，我们执行了正常的奴隶升级过程，将生产流量转移到新系统。 - -![](img/08676a1cb3f98f192c2bd2f90463450c.png) - -![](img/7a770bcb799c0ccf8a0b22a6bc4e84a6.png) - -## 实际效果：收益 - -经过六个多月的生产使用，我们发现在 XtraDB 群集上运行有很多好处： - -* 我们已经成功执行了生产集群的滚动重启和升级，而没有停止生产流量。 - -* 我们已经使用 pt-online-schema-change 在生产系统上执行了模式修改。 - -* 我们已经优化了如何处理写冲突。 XtraDB Cluster 在遇到冲突时会返回死锁错误-即使使用 pt-online-schema-change 执行快速 DDL 语句时也是如此。 冲突导致我们的应用服务器返回 503 响应，负载平衡层将捕获该响应。 负载平衡器随后将在另一台服务器上重试该请求。 - -## 现实世界的表现：烦恼 - -在此过程中，我们还发现了一些令人沮丧的问题： - -* 某些集群的关键状态计数器是有状态的，这意味着它们在运行“ SHOW GLOBAL STATUS”后重置为零。 这使得很难监视系统中的关键计数器（例如流量控制），这些计数器很少增加，但对于了解系统的行为至关重要。 （但是，此问题已在 XtraDB Cluster 5.6 使用的 Galera 3.x 中修复。） - -* ActiveRecord 的 MySQL 适配器隐藏了事务语句引发的异常，这些异常在发生写入集冲突时发生。 （此错误已在 Rails 4.1 中修复了 [。）](https://github.com/rails/rails/pull/12779) - -* 我们还有很多工作要做，以解决服务器不正常的问题。 当前，我们的应用程序服务器连接到本地 HAproxy 实例，该实例将其连接转发到单个群集节点。 为了进行计划内的维护，我们在将流量完全分配给另一个群集节点之前，先将其缓慢释放到另一个群集节点以对其缓冲池进行预热。 将来，我们计划切换到完全多主机设置，以确保所有节点都具有热缓冲池。 - -很棒的帖子！ - -出于好奇，您是否发现具有 RBR 的集群提高了总体交易吞吐量？ 您有可衡量的性能提升吗？ - -在查看 pt-online-schema-change 时，看来基于行的复制格式可能存在一些问题，尤其是在涉及触发器时（pt-osc 用于确保将更改写入新的临时表） 。 这是您必须处理的事情吗？ - -http://dev.mysql.com/doc/refman/5.5/en/replication-features-triggers.html - -＃1221372 如果服务器是基于行的复制中的从服务器 -，则 pt-online-schema-change 应该会出错 -https://bugs.launchpad.net/percona-toolkit/+bug/1221372 - -＃1225577 pt-online-schema-change 可以静默删除行 -https://bugs.launchpad.net/percona-toolkit/+bug/1225577 - -对于使用 pxc 的人来说，架构更新过程是什么样的？ - -问候。 - -集群中有多少数据（大致数字）？ 我正在尝试将数据迁移到具有非常大的表的类似设置（大约 60 GB）中，并始终使用临时空间来打不同类型的障碍，并且在使用 mysqldumps 时集群不响应。 旧设置包含一个相当旧的 MySQL 版本。 - -香港专业教育学院 - -在为群集提供生产写入流量之前，我们仅对群集运行人为基准。 这些基准测试表明群集的性能与独立服务器一样，但应注意，sysbench 不会强调 RBR 与 SBR 的局限性。 （在单个事务中修改的行数很大） - -因为我们的表都没有使用触发器，所以我们不需要处理任何触发器问题。 如果您在表上定义了触发器，则 pt-osc 将不起作用。 错误＃1221372 不会影响我们，因为我们总是在主服务器上运行 pt-osc。 - -根据操作类型的不同，我们的架构升级会有所不同。 使用 Rails 迁移运行创建/删除表。 Alter 表是使用 pt-osc 运行的，我们手动插入 Rails 迁移行以将该迁移标记为完成。 - -什么， - -我们的数据库有几百个 GB，表的大小各不相同（几兆最大> 100 GB）。 我还没有遇到任何有关临时空间的问题。 对于 mysqldump，也许您遇到流控制问题？ 如果让 mysqldump 针对群集节点运行并且执行 FTWRL，则由于该节点无法提交挂起的写集，因此将迅速启动流控制。 - -如果要从群集节点提取备份，则需要处理该问题。 您可以在备份期间将节点从群集中取消同步，切换到另一个备份系统（如 xtrabackup），或使用事务进行一致的备份（仅需要 InnoDB 表）。 对于我们来说，我们有一个专用于备份的主机，它是集群的异步从机。 这样，备份过程带来的任何额外负担都不会影响我们的生产集群。 - -希望有帮助！ - -Mika, - -我们正在运行一个非常相似的系统。 从 Doug 的描述中，听起来就像他们遵循了 PXC“参考体系结构”一样。 对我们来说，无论数据集大小如何，它都可以完美地工作。 一些现成的 Web 应用程序不能很好地与 PXC 配合使用，并且其中的大多数约束已在 OP 中列出。 我想在几点上进行扩展： -1-最新版本支持“更多”查询缓存，并且可以在启动配置中对其进行配置。 我们通过在 MySQL 进程启动后让操作员将 QC 大小设置为非零来解决早期的限制。 -2-临时 MyISAM 表不复制。 当 DDL 指向其他表时，这将导致在其他节点上记录错误。 它还可以防止依赖临时表的应用程序扩展到单个节点之外。 -3-编码不正确的应用程序可能会在群集上遇到认证错误（冲突），并且不会重试该语句。 可以将自动提交配置为对依赖它的应用程序自动重试。 -InnoDB 上的 4- FULLTEXT 索引仅在 5.6 上受支持。 但是 5.6 对我来说似乎还不完全成熟-从 PXC 版本中已修复的错误数量来看。 但是至少 Percona 似乎在努力工作。 - -有一个仅在 5.6 中修复的 bug 击中了我们，但它本身表现为在群集的滚动更新期间 mysql 进程崩溃，因此该更新仅在零停机时间内回滚。 Percona 很快就解决了这个问题，即使我们不是付费客户，我也非常满意他们的沟通（可以为从事 PXC 工作的人员找到联系信息）。 - -要回答您的问题（部分是这样）：Percona 创建了一个出色的工具“ XtraBackup”，可以进行在线备份。 在体验了 XtraBackup 之后，真的没有回过 mysqldump 了。 看看，确实没有与该工具进行备份的比较。 - -道格， - -如果使用 PHP，是否尝试在客户端主机上使用 mysqlnd_ms 而不是 HAProxy？ 关于 mysqlnd_ms 的任何评论？ 看起来很有趣，但是我不确定我是否愿意放弃客户端主机上 HAProxy 提供的稳定性，控制性和可见性。 - --V - -我们在一个国家/地区中确实有一个 percona Xtra 数据库集群（Master-Master -Master）设置，而我们希望在其他国家/地区中设置灾难恢复设置。请提出一种最佳的实现方法吗？ 提前致谢！ \ No newline at end of file +感谢您分享。 \ No newline at end of file diff --git a/docs/105.md b/docs/105.md index 1d37111..b361a41 100644 --- a/docs/105.md +++ b/docs/105.md @@ -1,65 +1,265 @@ -# 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明 +# 更简单，更便宜，更快：Playtomic 从.NET 迁移到 Node 和 Heroku -> 原文： [http://highscalability.com/blog/2014/5/19/a-short-on-how-the-wayback-machine-stores-more-pages-than-st.html](http://highscalability.com/blog/2014/5/19/a-short-on-how-the-wayback-machine-stores-more-pages-than-st.html) +> 原文： [http://highscalability.com/blog/2012/10/15/simpler-cheaper-faster-playtomics-move-from-net-to-node-and.html](http://highscalability.com/blog/2012/10/15/simpler-cheaper-faster-playtomics-move-from-net-to-node-and.html) -[![](img/6e2c7ef262b0ce58d944b649ddaa220d.png)](https://farm6.staticflickr.com/5524/14195687156_f1ff1631aa_o.jpg) +![](img/f9ab322d6775cffd84a15e52504cfff4.png) -[Wayback Machine](https://archive.org/web/web.php) 如何工作？ 现在，有超过[个索引](http://blog.archive.org/2014/05/09/wayback-machine-hits-400000000000/)的网页达 4000 亿个，可以一直浏览到 1996 年的互联网，这是一个更加引人注目的问题。 我看了好几次，但是我从来没有找到一个很好的答案。 +*这是 [Playtomic](https://playtomic.com/) 首席执行官 Ben Lowry 的特邀帖子。 Playtomic 是一项游戏分析服务，每天大约有 2 千万人在大约 8000 种移动，网络和可下载游戏中实施。* -这是来自 Hacker News 上一个线程的一些信息。 它以 [mmagin](https://news.ycombinator.com/item?id=7723291) 开头，前存档员工： +*这是 [Ben Lowry 在 Hacker News](http://news.ycombinator.com/item?id=4458124) ：*上的一个很好的摘要语录 -> 我不能说说他们目前的基础架构（尽管现在更多的是开源的-http://archive-access.sourceforge.net/projects/wayback/），但是就回溯机器而言， 任何地方都没有 SQL 数据库。为了使 Wayback 机器运行： -> -> * 存档数据为 ARC 文件格式（http：// en 的前身）。 wikipedia.org/wiki/Web_ARChive），实质上是单独压缩的记录的串联。 也就是说，您可以寻求特定的偏移量并开始对记录进行解压缩。 因此，您可以使用三元组（服务器，文件名，文件偏移量）访问任何已归档的网页，从而将其散布在许多商品级机器上。 -> * 构建了所有内容的排序索引，该索引使您可以查找（url）并提供时间列表或（url，time）到（文件名，文件偏移）。 它是通过构建一个排序的文本文件（首先在 url 上排序，第二次在时间上排序）并通过简单地将其拆分为 N 个大致相等的大小在多台计算机上分片来实现的。 在排序后的文本文件中进行二进制搜索的速度之快令人惊讶，部分原因是您在文件中查看的前几点仍然被缓存在 RAM 中，因为您经常点击它们。 -> * （这是我有点生锈的地方），Web 前端会收到一个请求，查询适当的索引机。 然后，它将使用一种小机制（可能是网络广播？）来查找（唯一）文件名所在的服务器，然后从该服务器请求特定记录。 -> * （编辑：仅供参考，我的知识已有 5 年了。我知道他们做了一些事情，以使该指数比当时更先进。） -> -> 至少，我会考虑将 blob 移出 MySQL 并将其放入文件系统中。 文件系统擅长于此。 您当然可以做一些像文件名一样的内容的 SHA-1 哈希这样简单的事情，然后根据文件系统的性能特征，在存储它们的树中可以有几个级别。 da39a3ee5e6b4b0d3255bfef95601890afd80709 进入目录 da / 39 /，然后将 da39a3ee5e6b4b0d3255bfef95601890afd80709 插入表的“指针”字段中，以替换实际数据。 显然，此设计假定 _that_ 文件的内容不变。 如果要更改表中该行的数据，则必须在文件系统中写入一个新文件并更新“指针”。 +> 昨天有超过 2 千万的人点击了我的 API 700,749,252 次，玩了我的分析平台集成的大约 8,000 款游戏，总播放时间不到 600 年。 就是昨天 有许多不同的瓶颈在等着人们大规模经营。 在我的用例中，Heroku 和 NodeJS 最终以非常便宜的价格缓解了很多。 -互联网档案[的 sam 和 raj 回复了](https://news.ycombinator.com/item?id=7723726)： +Playtomic 始于几乎唯一的 Microsoft.NET 和 Windows 体系结构，该体系结构保持了 3 年，然后被 NodeJS 完全重写所取代。 在整个生命周期中，整个平台从单个服务器上的共享空间发展为完全专用，然后扩展到第二专用，然后将 API 服务器卸载到 VPS 提供程序和 4-6 个相当大的 VPS。 最终，API 服务器安装在 Hivelocity 的 8 台专用服务器上，每个服务器都具有超线程+ 8gb ram +运行 500 或 3 个 API 堆栈实例的双 500gb 磁盘的四核。 -> Thanks! We were writing up a response at the same time:The Wayback Machine data is stored in WARC or ARC files[0] which are written at web crawl time by the Heritrix crawler[1] (or other crawlers) and stored as regular files in the archive.org storage cluster. -> -> 播放是通过对 WARC 数据中的指针的 2 级索引进行二进制搜索来完成的。 该索引的第二层是一个 20TB 压缩的（URL，日期，指针）元组的排序列表，称为 CDX 记录[2]。 第一级适合核心，它是 CDX 索引中每 3000 个条目的 13GB 排序列表，并带有指向较大 CDX 块的指针。 +这些服务器通常为 30,000 至 60,000 个并发游戏玩家提供服务，每秒最多接收 1500 个请求，并通过 DNS 轮询实现负载平衡。 + +7 月，整个服务器群被 Heroku 托管的 NodeJS 重写所取代，以节省大量资金。 + +## 使用 NodeJS 扩展 Playtomic + +迁移包括两个部分： + +1. **专用于 PaaS** ：优势包括价格，便利性，利用其负载平衡和降低总体复杂性。 缺点包括没有用于 NodeJS 的 New Relic，非常小的崩溃以及通常不成熟的平台。 +2. **.NET 到 NodeJS** ：将具有本地 MongoDB 实例和服务预处理事件数据的 ASP.NET/C#体系结构切换到本地，然后将其发送到集中式服务器以完成操作； 到 Heroku + Redis 上的 NodeJS 以及 SoftLayer 上的预处理（请参见 Catalyst 程序）。 + +## 专用于 PaaS + +复杂性的降低是显着的； 我们在托管合作伙伴 Hivelocity 拥有 8 台专用服务器，每台服务器运行 3 或 4 个 API 实例。 每个人都运行一小套软件，其中包括： + +* MongoDB 实例 +* 日志预处理服务 +* 监视服务 +* 带有 api 网站的 IIS + +部署是通过 FTP 脚本完成的，该脚本将新的 api 站点版本上载到所有服务器。 服务更讨厌部署，但很少更改。 + +MongoDB 对于在预处理和发送日志之前临时保存日志数据是一个糟糕的选择。 它提供了最初只写内存的巨大速度优势，这意味着写请求几乎立即就“完成”了，这远远优于 Windows 上的常见消息队列，但是它从未回收已删除数据留下的空间，这意味着 db 大小会膨胀到 如果不定期压缩，则超过 100 GB。 + +PaaS 提供商的优势是众所周知的，尽管它们似乎最成熟并且拥有广泛的技术支持，但对 Heroku 和 Salesforce 的信心最容易，尽管看上去最相似。 + +过渡到 PaaS 的主要挑战是，人们像在专用服务器上那样，可以与网站一起运行辅助软件的想法已经动摇。 大多数平台都提供了一些可以利用的后台工作线程，但这意味着您需要通过 3 rd 第三方服务或服务器来路由 Web 线程中的数据和任务。 + +我们最终选择在 Softlayer 上的大型服务器上运行了十二个特定目的的 Redis 实例和一些中间件，而不是后台工作程序。 Heroku 不对出站带宽收费，而 Softlayer 不对入站带宽收费，这巧妙地避免了所涉及的大量带宽。 + +## 从.NET 切换到 NodeJS + +在服务器端使用 JavaScript 是一种混合体验。 一方面，缺乏形式和样板正在解放。 另一方面，没有 New Relic，也没有编译器错误，这使所有事情都变得比原本困难。 + +有两个主要优点，这使得 NodeJS 对于我们的 API 极为有用。 + +1. **后台工作程序**与 Web 服务器位于相同的线程和内存中 +2. **与 Redis 和 mongodb 的持久共享连接** + +### 后台工作者 + +NodeJS 具有非常有用的功能，可以独立于请求继续工作，允许您预取数据和其他操作，这些操作可以让您非常早地终止请求，然后完成对它的处理。 + +对于我们而言，将整个 MongoDB 集合复制到内存中（定期刷新）是特别有利的，这样，整个工作类都可以访问当前数据，而不必使用外部数据库或本地/共享缓存层 。 + +在以下条件下，我们每秒总共节省 100 至 1000 的数据库查询： + +* 主 api 上的游戏配置数据 +* 数据导出 api 上的 API 凭据 +* GameVars，开发人员用来存储配置或其他数据以将其热加载到他们的游戏中 +* 排行榜得分表（不包括得分） + +基本模型是： + +> var cache = {}; > -> 索引查找的工作方式是二进制搜索存储在核心中的第一级列表，然后 HTTP 范围请求从 CDX 索引加载适当的第二级块。 最后，通过 CDX 记录指向的范围请求 WARC 数据加载网页数据。 在最终输出之前，将应用链接重写和其他转换以使回放在浏览器中正常工作。 +> module.exports = function（request，response）{ +> response.end（cache [“ x”]）; +> } > -> 服务器堆栈： +> 函数 refresh（）{ > -> * 前端：Tengine + HAProxy 到 Wayback Tomcat 应用程序服务器池[3] -> * 后端：Redis 支持的 archive.org 元数据 API [4]用于对象定位，而 nginx 在 linux 上（通过 ext4）用于数据服务 +> //从数据库中获取更新的数据，存储在缓存对象 +> 中。cache [“ x”] =“ foo”; +> setTimeout（refresh，30000）; +> } > -> * [0] http://en.wikipedia.org/wiki/Web_ARChive -> * [1] https://github.com/internetarchive/heritrix3 -> * [2] https://github.com/internetarchive/CDX-Writer -> * [3] https://github.com/internetarchive/wayback -> * [4] http://blog.archive.org/2013/07/04/metadata-api/ +> refresh（）; -sytelus [问](https://news.ycombinator.com/item?id=7724051)：为什么不使用哈希表而不是二进制搜索？ +这样做的优点是，您可以与后端数据库建立单个连接（每个 dyno 或实例），而不是每个用户建立一个连接，并且具有非常快的本地内存缓存，该缓存始终具有新数据。 -gojomo [回复了](https://news.ycombinator.com/item?id=7724347)： +注意事项是您的数据集必须很小，并且此线程与其他所有线程都在同一线程上运行，因此您需要意识到阻塞线程或执行过多的 CPU 工作。 -> 这里是前存档员工（&还是偶尔的合同贡献者）。 这是我在 2003 年加入时的第一个问题！ -> -> 某些 Wayback Machine 查询需要经过排序的键遍历：列出可以捕获 URL 的所有日期，发现 URL 的最近日期，并列出所有以某个 URL 前缀开头的可用 URL。 +### 持久连接 + +NodeJS 通过.NET 为我们的 API 提供的另一个巨大好处是持久性数据库连接。 在.NET（等）中进行连接的传统方法是打开您的连接，进行操作，然后将您的连接返回到池中，以便在短期内不再使用或不再使用时可以重新使用。 + +这是很常见的，除非达到很高的并发性，否则它将正常工作。 并发率很高，因此连接池无法足够快地重用连接，这意味着它会生成新连接，数据库服务器必须扩展这些连接才能处理。 + +在 Playtomic，我们通常有数十万并发游戏玩家正在发送事件数据，这些事件数据需要被推回到不同数据中心中的 Redis 实例，而使用.NET 则需要大量 连接数量–这就是为什么我们在每台旧专用服务器上本地运行 MongoDB 的原因。 + +使用 NodeJS，每个 dyno /实例具有单个连接，该连接负责推送特定 dyno 接收的所有事件数据。 它位于请求模型之外，如下所示： + +> var redisclient  = redis.createClient(….); > -> 维护（URL，日期，指针）的规范排序主索引（20TB 二级索引 rajbot 提到）可以满足两种查询。 一旦有了该工件，就可以相当高效地满足各个捕获查找的需求。 （然后，分布式哈希表将需要额外维护。） +> module.exports = function（request，response）{ > -> 同样，查询也不是随机的：存在热范围，甚至单个用户的会话都从范围查询（URL 的所有日期）开始，然后访问相同范围的一个 URL。 然后，加载页面内联资源的最近日期捕获开始达到相似的范围，后续点击链接或附近日期也是如此。 因此，即使主索引仍在旋转的磁盘上（除非最近发生了一次重大的 SSD 升级，以免引起了我的注意），但浏览范围却经常出现在主内存缓存中。 +> var eventdata =“ etc”; > -> 毫无疑问，有许多地方可以改进，但是这种基本的排序索引模型已经很适合该应用程序很长时间了，避免了过多的特定于领域的复杂性，并且适用于许多代索引/分片/复制/内部- API 调整。 +> redisclient.lpush（“ events”，eventdata）; > -> 顺便说一句，Archive 正在招聘多个技术职位，其中包括负责开发下一代 Wayback Machine 的高级职位：https：//archive.org/about/jobs.php +> } -[Vecrios](https://news.ycombinator.com/item?id=7723794) 中的一个有趣的问题：我仍然无法理解它们如何存储大量数据并且不会用完空间？ +### 最终结果 -dwhly [回答](https://news.ycombinator.com/item?id=7724035)： +**高负载：** -> 几年前与 Brewster 的一次对话中：磁盘驱动器的密度加倍使它们在 Wayback 机器的空间方面保持相对中性。 它仍然占据着与过去 10 年大致相同的尺寸，我认为这实际上是一组大约 15-20 英尺长的机架。 -> -> 但是，新的电视新闻和搜索功能所需的空间甚至远远超过 IIRC 档案库，或者肯定正在朝这个方向发展。 +最后一刻的要求 + +* * * + +_exceptions：75 （0.01％） _ 失败：5 （0.00％） 总计：537,151 （99.99％） data.custommetric.success：1,093 （0.20％） data.levelaveragemetric.success ：2,466 （0.46％） data.views.success：105 （0.02％） events.regular .invalid_or_deleted_game＃2：3,814 （0.71％） events.regular.success：527,837 （98.25％） gamevars.load.success：1,060 （0.20％） geoip.lookup.success：109 （0.02％） Leaderboards.list.success：457 （0.09％） Leaderboards.save.missing_name_or_source＃201：3 （0.00％） 排行榜。保存。成功：30 （0.01％） 。 +排行榜.saveandlist。成功：102 （0.02％） playerlevels.list.success：62 （0.01％） playerlevels.load.success：13 （0.00％） + +* * * + +此数据来自在每个实例的后台运行的一些负载监控，将计数器推送到 Redis，然后将其汇总并存储在 MongoDB 中，您可以在 [上查看它们的运行情况 https://api.playtomic.com/load.html](https://api.playtomic.com/load.html) 。 + +该数据中有几种不同的请求类别： + +* **事件** 从 MongoDB 检查游戏配置，执行 GeoIP 查找（开源的非常快速的实现，网址为 https://github.com/benlowry/node-geoip-native） ，然后推送到 Redis +* **GameVars ， 排行榜，玩家级别** 都从 MongoDB 中检查游戏配置，然后再检查相关的 MongoDB 数据库 +* **数据** 查找被代理到 Windows 服务器，因为 NodeJS 对存储过程的支持不佳 + +The result is 100,000s of concurrent users causing spectactularly light Redis loads fo 500,000 – 700,000 lpush’s per minute (and being pulled out on the other end): + + 1  [||                                                                                      1.3%]     Tasks: 83; 4 running + 2  [|||||||||||||||||||                                                                    19.0%]     Load average: 1.28 1.20 1.19 + 3  [||||||||||                                                                              9.2%]     Uptime: 12 days, 21:48:33 + 4  [||||||||||||                                                                           11.8%] + 5  [||||||||||                                                                              9.9%] + 6  [|||||||||||||||||                                                                      17.7%] + 7  [|||||||||||||||                                                                        14.6%] + 8  [|||||||||||||||||||||                                                                  21.6%] + 9  [||||||||||||||||||                                                                     18.2%] + 10 [|                                                                                       0.6%] + 11 [                                                                                        0.0%] + 12 [||||||||||                                                                              9.8%] + 13 [||||||||||                                                                              9.3%] + 14 [||||||                                                                                  4.6%] + 15 [||||||||||||||||                                                                       16.6%] + 16 [|||||||||                                                                               8.0%] + Mem[|||||||||||||||                                                                 2009/24020MB] + Swp[                                                                                    0/1023MB] + + PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command +12518 redis     20   0 40048  7000   640 S  0.0  0.0  2:21.53  `- /usr/local/bin/redis-server /etc/redis/analytics.conf +12513 redis     20   0 72816 35776   736 S  3.0  0.1  4h06:40  `- /usr/local/bin/redis-server /etc/redis/log7.conf +12508 redis     20   0 72816 35776   736 S  2.0  0.1  4h07:31  `- /usr/local/bin/redis-server /etc/redis/log6.conf +12494 redis     20   0 72816 37824   736 S  1.0  0.2  4h06:08  `- /usr/local/bin/redis-server /etc/redis/log5.conf +12488 redis     20   0 72816 33728   736 S  2.0  0.1  4h09:36  `- /usr/local/bin/redis-server /etc/redis/log4.conf +12481 redis     20   0 72816 35776   736 S  2.0  0.1  4h02:17  `- /usr/local/bin/redis-server /etc/redis/log3.conf +12475 redis     20   0 72816 27588   736 S  2.0  0.1  4h03:07  `- /usr/local/bin/redis-server /etc/redis/log2.conf +12460 redis     20   0 72816 31680   736 S  2.0  0.1  4h10:23  `- /usr/local/bin/redis-server /etc/redis/log1.conf +12440 redis     20   0 72816 33236   736 S  3.0  0.1  4h09:57  `- /usr/local/bin/redis-server /etc/redis/log0.conf +12435 redis     20   0 40048  7044   684 S  0.0  0.0  2:21.71  `- /usr/local/bin/redis-server /etc/redis/redis-servicelog.conf +12429 redis     20   0  395M  115M   736 S 33.0  0.5 60h29:26  `- /usr/local/bin/redis-server /etc/redis/redis-pool.conf +12422 redis     20   0 40048  7096   728 S  0.0  0.0 26:17.38  `- /usr/local/bin/redis-server /etc/redis/redis-load.conf +12409 redis     20   0 40048  6912   560 S  0.0  0.0  2:21.50  `- /usr/local/bin/redis-server /etc/redis/redis-cache.conf + +and very light MongoDB loads for 1800 – 2500 crud operations a minute: + +insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time +    2      9      5      2       0       8       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     7k   116   01:11:12 +    1      1      5      2       0       6       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     2k     3k   116   01:11:13 +    0      3      6      2       0       8       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k     6k   114   01:11:14 +    0      5      5      2       0      12       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     5k   113   01:11:15 +    1      9      7      2       0      12       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     4k     6k   112   01:11:16 +    1     10      6      2       0      15       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     1|0     4k    22k   111   01:11:17 +    1      5      6      2       0      11       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k    19k   111   01:11:18 +    1      5      5      2       0      14       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     3k   111   01:11:19 +    1      2      6      2       0       8       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k     2k   111   01:11:20 +    1      7      5      2       0       9       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     2k   111   01:11:21 +insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time +    2      9      8      2       0       8       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     5k   111   01:11:22 +    3      8      7      2       0       9       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     9k   110   01:11:23 +    2      6      6      2       0      10       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k     4k   110   01:11:24 +    2      8      6      2       0      21       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k    93k   112   01:11:25 +    1     10      7      2       3      16       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     4m   112   01:11:26 +    3     15      7      2       3      24       0  6.67g  14.8g  1.23g      0      0.2          0       0|0     0|0     6k     1m   115   01:11:27 +    1      4      8      2       0      10       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     2m   115   01:11:28 +    1      6      7      2       0      14       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     3k   115   01:11:29 +    1      3      6      2       0      10       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k   103k   115   01:11:30 +    2      3      6      2       0       8       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k    12k   114   01:11:31 +insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time +    0     12      6      2       0       9       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k    31k   113   01:11:32 +    2      4      6      2       0       8       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     9k   111   01:11:33 +    2      9      6      2       0       7       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k    21k   111   01:11:34 +    0      8      7      2       0      14       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     9k   111   01:11:35 +    1      4      7      2       0      11       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k     5k   109   01:11:36 +    1     15      6      2       0      19       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     5k    11k   111   01:11:37 +    2     17      6      2       0      19       1  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     6k   189k   111   01:11:38 +    1     13      7      2       0      15       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     1|0     5k    42k   110   01:11:39 +    2      7      5      2       0      77       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     2|0    10k    14k   111   01:11:40 +    2     10      5      2       0     181       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0    21k    14k   112   01:11:41 +insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time +    1     11      5      2       0      12       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     4k    13k   116   01:11:42 +    1     11      5      2       1      33       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     3|0     6k     2m   119   01:11:43 +    0      9      5      2       0      17       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     1|0     5k    42k   121   01:11:44 +    1      8      7      2       0      25       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     6k    24k   125   01:11:45 + +## 相关文章 + +* [新的 API 服务器：Heroku 和 NodeJS 与专用和.NET](https://playtomic.com/blog/post/86-the-new-api-server-heroku-an) +* [日志处理，从无到有，每天发生十亿个事件](https://playtomic.com/blog/post/68-log-processing-from-nothing) +* [每天在预算范围内实时处理超过 3 亿个事件](https://playtomic.com/blog/post/53-handling-over-300-million-ev) +* [回顾 2010 年-从每月 4000 万事件到每天 3 亿](https://playtomic.com/blog/post/46-looking-back-on-2010) +* [四种让玩家爱上您的游戏的方式](http://www.gamasutra.com/blogs/BenLowry/20111116/8914/Four_ways_to_keep_players_in_love_with_your_game.php) +* [已发布 InkTd Flash 游戏源代码](http://www.emanueleferonato.com/2012/04/19/inktd-flash-game-source-code-released/) +* [黑客新闻主题](http://news.ycombinator.com/item?id=4615799)的相关评论 +* [Heroku 成功案例页面](http://success.heroku.com/playtomic) +* [关于黑客新闻](http://news.ycombinator.com/item?id=4655718) + +Redis 和 MongoDB 嗯...。 好文章 + +这是一篇很棒的文章，感谢您的分享。 + +因此，您切换了三件事：体系结构，部署/操作模型和运行时。 +多汁的标题指的是第三部分，它可能是更改的最不重要的部分，而成本最高的部分（因为它需要完全重写）。 + +不要误会我的意思-我爱我一些 node.js，并且我是 Heroku 的忠实拥护者，但是.NET impl 中指出的所有警告很容易（或不太容易，但比完全重写要容易得多） ）可寻址。 因此，您*可以*通过优化现有代码库（而不是重写）并迁移到具有 AppHarbor，Azure 的易于部署的模型（或在 Heroku 上运行 Mono）来获得类似的结果。 而且您还会有 New Relic :) + +很想听听您对完整重写的成本收益平衡的看法 + +写得好！，我们曾经做过类似的事情。 当我们的集合太大时，Node GC 将暂停很长一段时间，并最终会因 JS 内存不足错误（大约 2 Gig）而崩溃。 我们最终创建了一个 NodeJS C ++插件来存储 V8 堆之外的数据，这实际上使我们可以将驻留在内存中的缓存扩展到超过 10 个 Gig。 + +我对 Node.JS 不太了解，但是 devdazed 的评论提出了我无法解决的问题。 在哪个星球上，NodeJS 内置的 GC 比 JVM（或.NET）更好？ + +我猜不能与成功争辩-这对他们是有用的。 但是很难相信在 JVM 或.NET 环境中无法轻松实现同一目标，在这些环境中，您不会遇到与 GC 相关的陷阱。 或者至少您发现的那些是众所周知的。 + +这是一本不错的书，但是我没有得到一些要点： +1.后台工作者。 通过创建一个新线程，Asp.net 可以轻松地做到这一点。 唯一应注意的事情是不会在该线程中引发未处理的异常。 +2.持久连接。 为什么不仅仅拥有一个静态的 MongoServer 实例（它是线程安全的类）呢？ MongoCollection 类也是线程安全的。 所以我们甚至可以有一个静态的集合实例 + +究竟是什么使您用 Node.js 取代.NET？ ASP.NET 完全支持异步。 通过从.NET 切换到节点，您还可以获得“沉重”（如 3-10 倍）的性能。 如果您的应用切换到 node.js 之后变得更快，那么您首先在.net 方面做错了什么。 + +您也可以随意处理数据库连接。 您可以使用[ThreadStatic]或其他某种机制使每个线程保持一个打开状态。 + +@Dmitry： + +并不是说我是该领域的专家（也不认为 Node 是灵丹妙药），但也许我会说一些话来为您澄清一下： + +1.我不会依赖 ASP.NET 来执行后台任务，因为该实现通常非常脆弱。 ASP.NET 根本不是为此目的而设计的，我想如果您想通过 ASP.NET 应用程序上下文中的线程 API 实现后台工作程序，则需要一个非常非常好的理由。 我宁愿选择 WCF 服务作为 Windows 服务托管，它更可靠。 + +2.的确如此，拥有静态的 MongoServer / MongoDatabase 实例将使您在应用程序域的整个生命周期中都具有持久的连接。 最后一部分很重要，因为 ASP.NET 应用程序可以出于多种原因（计划的应用程序池回收，web.config 或应用程序文件夹更改等）重新启动。 而且我认为 Node 在这方面更可靠。 + +但总的来说，我同意其他人的观点，即完全没有必要完全重写（以及移至 Node）（但我认为他们也知道自己在做什么）。 + +What on earth made you replace .NET with Node.js? ASP.NET supports asynchrony to the fullest. You also take a *heavy* (like 3-10x) perf hit by switching to node from .NET. If your app got faster after switching to node.js you did something wrong on the .net side in the first place. + +You are also free to handle your DB connections however you want. You could have kept one open per thread for example with [ThreadStatic] or some other mechanism. + +最近所有的 node.js 文章都有什么？ + +是的，node.js 速度很快，但是它缺少太多基本功能，因此当您重写所有模块时，“神奇”的速度优势将不复存在，而且整个代码库将成为一堆不断调用自身的回调 ，进行简单的更改需要您分析整个过程，就像穿针一样。 + +Node.js 令人头疼。 -并感谢 [rietta](https://news.ycombinator.com/item?id=7724313) 所说的 Wayback Machine 如何在银河系中存储比星星更多的页面。 神话般的图像。 +我们正在将 StatsD + Graphite 与我们的企业 Node 应用一起使用。 有了它，您可以轻松免费地免费获得 New Relic。 -据我了解，大约在 2000 年开始出现 GMR（巨磁阻比）读取磁头，从而使硬盘容量每年翻一番（甚至更多）。 我记得在 2000 年，典型的硬盘驱动器为 2 到 4 GB。 当然，现在是 5 到 10 TB，而它们增加到约 20 TB。 因此，我完全不难理解 Wayback 机器如何在硬盘大小相同的情况下保存“足够”的数据。 \ No newline at end of file +哇，这家伙真的很喜欢过度设计！ 在 API 客户端中使用 boost（并迫使 android 用户使用自定义 SDK 进行编译，这对于使用 malkade skd 的用户而言更加痛苦）。 \ No newline at end of file diff --git a/docs/106.md b/docs/106.md index 8219637..b4ca57c 100644 --- a/docs/106.md +++ b/docs/106.md @@ -1,63 +1,191 @@ -# 关于 Disqus 的更新：它仍然是实时的，但是 Go 摧毁了 Python - -> 原文： [http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html](http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html) - -[![](img/c586fc50f256a62f6bb89ab1a5abdb14.png)](https://farm3.staticflickr.com/2937/14110625651_4d66420224_o.png) 我们上次在 Disqus 上发表的文章： [Disqus 如何以每秒 165K 消息且小于.2 秒的延迟](http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html)进行实时处理，虽然有些过时了，但是 Disqus 上的人们 一直在忙于实现，而不是在谈论，所以我们对他们现在在做什么并不了解，但是我们确实对 John Watson 的 [C1MM 和 NGINX](https://www.youtube.com/watch?v=yL4Q7D4ynxU) 作了简短的更新，并撰写了一篇文章 [出这个 Go 东西](http://blog.disqus.com/post/51155103801/trying-out-this-go-thing)。 - -因此，Disqus 增长了一些： - -* 13 亿独立访客 -* 100 亿页面浏览量 -* 5 亿用户参与讨论 -* 300 万个社区 -* 2500 万条评论 - -他们仍然都是关于实时的，但是 Go 在其 Realtime 系统中取代了 Python： - -* 原始的实时后端是用非常轻量级的 Python + gevent 编写的。 -* 实时服务是 CPU 密集型任务与大量网络 IO 的混合体。 Gevent 可以毫无问题地处理网络 IO，但是在更高的竞争中，CPU 阻塞了一切。 切换到 Go 消除了该争用，这是所看到的主要问题。 -* 仍可在 5 台 Nginx 机器上运行。 - * 使用 NginxPushStream，它支持 EventSource，WebSocket，Long Polling 和 Forever Iframe。 - * 所有用户都已连接到这些计算机。 - * 在正常的一天中，每台计算机看到 3200 个连接/秒，100 万个连接，150K 包/秒的 TX 和 130K 包/秒的 RX，150 mbit / s 的 TX 和 80 mbit / s 的 RC，从头到尾的< 15ms 延迟 结束（比 Javascript 渲染评论要快） - * 一开始有很多资源枯竭的问题。 给出了 Nginx 和 OS 的配置，可帮助缓解问题，对其进行调整以应对许多连接移动少量数据的情况。 -* 优先使用网络带宽。 - * 使用 10 千兆位网络接口卡很有帮助。 - * 启用 gzip 很有帮助，但是 Nginx 为 gzip 的每个连接预先分配了很多内存，但是由于注释很小，所以这太过分了。 降低 Nginx 缓冲区大小可以减少内存不足的问题。 -* 随着消息速率的提高，在每秒处理 10k +消息的高峰时，计算机达到了极限，在最坏的情况下，端到端延迟达到了数秒和数分钟。 -* 切换到 Go。 - * 节点未选择，因为它不能很好地处理 CPU 密集型任务。 - * Go 不能直接访问数据库。 它消耗 RabbitMQ 的队列并发布到 Nginx 前端。 - * 没有使用 Go 框架。 这是一个很小的组件，Disqus 的其余部分仍然是 Django。 - * 之所以喜欢 Go，是因为它的性能，本机并发性以及对 Python 程序员的熟悉程度。 - * 在短短一周内就建立了替换系统，并取得了令人瞩目的成果： - * 端到端延迟平均不到 10 毫秒。 - * 当前消耗大约 10-20％的可用 CPU。 大幅减少。 -* 他们想更好地利用资源，而不是增加更多机器： - * 对于已经完成的工作量，我们不想横向扩展更多。 向问题扔出越来越多的硬件并不总是最好的解决方案。 最后，拥有更快的产品也会产生自己的利益。 +# Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序 + +> 原文： [http://highscalability.com/blog/2012/10/22/spanner-its-about-programmers-building-apps-using-sql-semant.html](http://highscalability.com/blog/2012/10/22/spanner-its-about-programmers-building-apps-using-sql-semant.html) + +![](img/e618cf11a7e558cbccc35dc3c895b625.png)很多人似乎都非常讨厌 [NewSQL](http://blogs.the451group.com/information_management/2011/04/06/what-we-talk-about-when-we-talk-about-newsql/) 这个词，或者几乎是这个词的任何新造词，但是在看过高级软件工作人员 Alex Lloyd 之后 Google 工程师，就 Building Spanner 进行了精彩的演讲 [ ，这是最适合 Spanner 的术语。](http://vimeo.com/43759726) + +Spanner 将 OldSQL 的 SQL +事务模型包装在全球分布式 NoSQL 系统的重新设计的骨骼上。 在我看来，这是 NewSQL。 + +由于 Spanner 不是 BigTable 的近亲，因此 NoSQL 组件应该不足为奇。 Spanner 负责在任意数量的地理分布数据中心内跨越数百万台计算机。 令人惊讶的是，OldSQL 是如何被接受的。 Alex 在 HotStorage 会议上发表的 [](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf)早期演讲中，采用 OldSQL 的原因是希望使程序员更轻松，更快速地构建应用程序 。 主要思想似乎很熟悉： + +* 小型复杂数据库与庞大，可扩展，简单的数据库之间存在错误的二分法。 我们可以拥有功能并对其进行扩展。 +* 复杂性可以保留，可以放到某个地方，因此，如果不在数据库中，则将其推送给开发人员。 +* 将复杂性降低到堆栈中，以便开发人员可以专注于构建功能而不是数据库而不是基础结构。 +* 创建快速发展的应用团队的关键：ACID 交易； 全局可序列化； 编写第一步交易，而不是十步工作流程； 编写查询而不是代码循环； 加盟 没有用户定义的冲突解决功能； 标准化同步； 即付即用，获得可预期的性能所需的费用。 + +Spanner 并非以成为 NewSQL 明星为目标。 Spanner 最初是 BigTable 克隆，带有分布式文件系统隐喻。 然后，Spanner 演变为全局 ProtocolBuf 容器。 最终，Spanner 受到 Google 内部客户的推动，以变得与关系和应用程序程序员更加友好。 + +显然，在 Google 内部使用 [Dremel](http://highscalability.com/blog/2010/8/4/dremel-interactive-analysis-of-web-scale-datasets-data-as-a.html) 已向开发人员表明，可以大规模使用 OLAP 和 SQL，他们希望 OLTP 应用具有相同的易用性和上市时间。 看来 Google 有很多应用程序可供开发，程序员不喜欢处理在最终一致的系统之上生产可靠产品的现实世界中的复杂性。 + +诀窍是弄清楚如何使 SQL 真正大规模地工作。 为了表明我们仍处于编程经验阶段的深度，该过程甚至花费了 Google 五年的开发时间。 亚历克斯说，真正的工作实际上是建立一个复杂的，可靠的分布式系统。 那是很难正确的部分。 + +在谈论原子钟等所有内容时，您可能会感到系统中存在魔力。 您可以进行巨大的跨表，跨数百万条记录的数据中心事务处理而不会受到任何损失。 那是不对的。 Spanner 是 OLTP 系统。 它使用两阶段提交，因此长时间的大型更新仍将锁定和阻止，程序员仍处于进入和退出的困境。 想法是这些限制值得程序员提高生产力，并且确实出现的任何瓶颈都可以逐案处理。 通过演讲，我逐渐感觉到，Spanner 的域中将包含诸如 pub-sub 之类的专用应用程序域。 尽管事务方面可能是常规事务，但除了所有的全局重新分区魔术在幕后透明进行之外，它们的事务时间戳方法在读取路径上确实具有很多不错的功能。 + +为说明每个 Paxos 组很难扩展到大量副本的困难，Alex 转向了水文隐喻： + +> 您可以将 Spanner 分区用作一种有序的 pub-sub 方案，在该方案中，您在某个分区的所有位置都有只读副本，并且您正试图使用​​它来以有序方式将数据分配给很多 不同的数据中心。 这带来了不同的挑战。 如果您没有足够的带宽访问那些数据中心的某些子集，该怎么办？ 您不希望数据在领导者中缓冲太久。 如果您将其溢出到磁盘上，那么当带宽可用时，您就不会招致搜索损失。 它变得像水文学。 您需要将所有这些数据在不同的时间发送到不同的位置，并且希望在变化的条件下使所有流平稳地移动。 平稳地意味着更少的服务器重启，意味着更好的延迟尾部，意味着更好的编程模型。 + +这也许是我最喜欢的部分。 我只是喜欢数据流过的图像，就像水滴从数百万台机器和网络中滴落，暂时聚集在内存和磁盘的洞穴中，总是分裂，总是重组，总是不断变化，总是不断进步，是巨大的不断流动的一部分 [数据周期](http://en.wikipedia.org/wiki/Water_cycle)永不丢失。 太棒了。 + +如果您有机会观看视频，我强烈建议您这样做，这的确很好，根本没有什么毛病。 关于在分布式事务中使用时钟的部分做得特别好。 但是，如果您时间紧缺，可以参考以下内容： + +* 5 年的努力。 +* NoSQL 规模的 SQL 语义。 +* 试图获得一个看起来像单个巨型 MySQL 的抽象。 +* 关系数据库是一个非常熟悉的生产环境，可以在其中建立应用程序。 +* Spanner 是存在证明，可以将关系数据库扩展到全局分布式存储系统。 +* 编写应用时无需考虑事务语义。 正确无误。 然后，您返回并优化一些高事务写入，这些优化将真正获得回报。 +* 希望向应用程序开发人员提供真正直接的语义。 应用程序开发人员应考虑业务逻辑而不是并发性。 +* 他们这样做的方式是通过构建具有绝对绝对误差的时钟。 然后将它们与时间戳分配集成在并发控制中： + * 时间戳的总顺序遵循事务的部分顺序。 如果交易 A 在交易 B 之前发生，我们知道交易 A 的时间戳小于交易 B 的时间戳。 + * 这意味着对所有内容进行有效的可序列化查询。 您可以将跨越数十个数据中心的 PB 级数据库的总和提高到一分钱。 可能需要一段时间才能获取所有数据。 但是您可以期望答案是正确的。 +* BigTable 早期的 NoSQL 数据库。 论文于 2006 年问世。 +* MegaStore 建立在 BigTable 之上。 它添加了 Paxos 同步层和更丰富的数据模型。 论文在 2011 年问世。 +* 底层架构中的 Spanner 很像 BigTable。 更新会附加到数据中心本地分布式文件系统中的日志中。 定期将它们压缩为不可变的 b 树（SSTables），并定期将这些 SSTable 合并在一起。 Leveldb 是一个开源版本。 +* 开发人员仍必须考虑如何对数据进行分区以提高效率，但开发人员应尽可能地专注于业务逻辑。 +* 目标不是数据重新分区的停机时间。 **Google 所做的一切都与数据移动息息相关，因为在数据中心之间移动用户和重新分片是一项持续的后台活动。** **因为这是一个连续的过程，所以各种并发性错误不断出现**。 事务有助于正确地分配其连续的分区流逻辑。 在进行交易之前，他们有很多错误，这就是为什么花了 5 年的时间的一部分。 +* 希望程序员减少在设计过程中早期做出的分区决策的束缚。 +* 希望获得 Megastore 最成功的部分： + * 处理大规模数据中心中断，而不会给用户带来明显影响。 + * 处理单元内部较小的中断，微中断。 示例：底层平板电脑因过载或损坏而中断，仅一个机架上的电源就中断了，等等。 + * 用户可能会在计时器触发时看到延迟增加，并且他们移至另一个数据中心，但看不到对事务语义的影响。 +* 但是 Megastore 有一些问题： + * 数据库被划分为一堆实体组。 实体组是他们自己的交易域，您不能跨实体组进行交易。 + * 它使用乐观并发。 当副本之间的传播间隔为 50 毫秒，而您正在执行同步复制时，写入将至少花费 50 毫秒，这将为乐观并发故障创建一个很大的漏洞窗口。 + * 将分层系统整合为单个集成系统的好处。 与 Megastore 和 Bigtable 之间的接口相比，Spanner 与物理存储之间的接口要丰富和优化。 +* 向 SQL 的文化转变 + * 基于 SQL 的分析系统 Dremel 在 Google 上进行了许多 SQL 转换，因为它可以将查询的语义向下推送到存储系统中，并让其确定该怎么做。 + * 这种文化根深蒂固，您可以扩展，也可以使用 SQL。 Dremel 表明，对于分析，您可以同时拥有。 Spanner 显示您可以同时使用 OLTP。 +* 由于业务问题，人们要求简化地理分区。 例如，将用户数据从一个区域移动到另一区域。 + * 法律问题 + * 产品增长意味着您想要尽可能高效地将多少人放到 +* 扳手的数据模型 + * 并不总是具有关系模型。 与 Jeff Dean 在 2009 年提出的内容完全不同。 + * 带有单个用户关系表的示例，每个用户都有一个名称和家庭区域。 + * User 数据库可以分为几个分区。 美国的一个只读分区，欧洲的另一个分区。 大型数据库将具有数百万个分区。 分区 1 在美国将具有三个副本。 另一个分区在欧洲具有三个副本。 美国有一个只读副本。 这很有用，因此您可以在欧洲拥有一个书面仲裁，这意味着您永远不会阻塞跨大西洋的 RPC 调用，但是在美国，尽管它可能有些陈旧，但您仍然可以查询所有数据。 + * 主细节层次结构在物理上被聚在一起。 在分布式系统上，更为重要的是记录将存储在其他服务器上。 + * 关系抽象的底层是程序员如何将密钥手动编码到 Bigtable 中。 每个表格单元格都只有一个条目，例如： + + * @ 10 部分是时间戳。 + * 在 Bob 记录开始之前，Alice 的订单将与 Alice 一起存储。 +* 并发 + * 在较高级别，Spanner 使用两阶段锁定和快照隔离的组合。 + * 并未尝试创建疯狂的新模型。 旨在找出如何扩展已验证模型的目标。 + * 此模型最适合读取为主的工作负载。 您将大部分时间花在便宜的快照隔离读取上，而不花大量时间在悲观主义事务写入上。 + * Blogger 示例，它首先担心正确性，然后担心优化。 + * Blogger 有 280 个 Servlet。 低频高复杂度操作，例如用户通过发送文本消息来创建博客，然后他们希望将该博客合并到现有博客中。 + * 花费大量的时间才能将其创建为由精心设计的工作流程精心安排的一系列幂等操作。 + * 使用 ACID 交易，Blogger 会更快。 在没有性能优势的情况下花费在这些复杂的编程任务上的时间本来可以减少某些高频页面的 50 毫秒，从而产生更大的整体影响。 + * 与在单台计算机上编程相同的过程。 您从互斥锁开始，然后才尝试原子操作。 + * 仅执行弱一致性的 NoSQL 数据库正在对整个系统实施广泛应用的过早优化。 应该选择值得的页面。 +* 在 Google 看到的模式中保留提交顺序 + * 他们在设计过程中考虑的经验法则： + * 如果 T1 在 T2 之前完成，那么他们想保留这一事实。 T2 与 T1 之间存在提交顺序相关性。 + * 假设 T3 写了一些 T4 读取的内容，因此存在传统的数据依赖性，因此 T3 必须始终在 T4 之前发生。 + * T1 和 T2 在 T3 和 T4 之间没有关系。 + * **系统性能来自并发运行没有依赖性的事务。** + * **目标是保留与原始历史记录相同的依存顺序。** + * 可序列化是一个带有大量变化的重载术语。 + * 线性化是从并发编程中借鉴的一种思想，并且很好地适用于在分布式数据库之上对分布式系统进行编程。 + * 包含可序列化性，无法上下班提交顺序。 + * 即使没有可检测的依存关系，即使一笔交易发生在另一笔交易之前，也必须保留该订单，即使该交易发生在不同的机器上。 + * 示例架构： + * 一个分区是购买的广告表。 在美国写仲裁，在欧洲写只读副本。 + * 这些广告的展示在美国的一个分区。 例如，在 2:00 和 2:01，有人观看了小狗广告。 + * 欧洲的一个分区，用于展示广告。 + * **在美国有一个只读的欧洲数据副本，反之亦然。 这样可以使双方进行过时的读取和快速的写入，而无需越过池塘。 您仍然可以在任何一侧高效地使用 MapReduce。** + * 交易示例： + * 交易 1：用户购买了广告。 + * 在后台，广告投放系统正在不断扫描分区以显示广告，并发送检索广告查询。 + * 广告投放系统会随着时间累积其要保存在数据库中的一批展示次数。 + * 事务 2：服务器写入印象分区以记录印象。 + * 这是两个不同的分区，不同的副本，不同的数据中心以及潜在的不同大陆。 + * 现在，您想编写一个 SQL 查询来审核小时级别的展示次数。 选择一个时间戳。 + * 根据时间戳记只有三个合法结果： + * 既看不到广告也看不见。 + * 看到广告，但没有展示。 + * 查看添加和所有展示。 + * 在所有系统中，他们都在替换 MapReduce 或查询必须容忍结果的无限变化。 + * 它可能会看到展示，但看不到广告。 + * **针对这种弱语义编写查询意味着很难分辨出腐败，错误或并发异常之间的区别。** + * 解决此问题的方法是通过单个中央服务器序列化每个更新。 如果更新位于一起，则有效，但不适用于分区遍布全球的分散式模型。 +* 在全球分布式数据库中扩展 Spanner 所需语义的选项： + * **一个分区模型** 。 大量的 WAN 通信。 将所有分区都包含在每个事务中。 + * **集中时间戳预言** 。 如果您同时在两个不同的大陆上进行更新，则效果不佳。 + * **Lamport 时钟** 。 通过每个外部系统和协议传播时间戳。 如果您的系统数量和协议数量都不足，则此方法有效，当您拥有大量不受控制的分布式系统或协议（例如与贸易伙伴一起使用）或它们只是协议时，您将无法正常工作 不碰。 在 Google 进行了几次尝试，但是在复杂的系统中始终无法成功完成时间戳。 + * **建立一个分布式时间戳预告片** 。 其中的一个 TrueTime 是 Google 常规时间清理产生的。 时间有一个 epsilon 时间，因此您知道进行现在呼叫的实时时间在该时间间隔内。 源自一堆不同数据中心中的 GPS 接收器，这些数据中心由原子钟备份。 GSP 系统有时确实存在错误。 一次代码推送可以消除大量卫星，因此备份非常有用。 +* TrueTime + * 目标不变式：写 A 和 B，如果 A 发生在 B 之前，则意味着 A 在 B 开始之前完成，那么 A 的时间戳应小于 B。完成意味着任何人都可以看到效果。 不仅是客户，还有 Paxos 奴隶。 + * 使用此不变式，意味着您可以说在特定时间戳记下的快照读取是可序列化的。 + * TrueTime 与天体导航的工作原理类似，只是那是硬错误界限，而不仅仅是猜测。 + * 每台 Google 服务器中都有一个时间守护程序，每台服务器中都有一个水晶，每个数据中心都有一些来自不同制造商的 GPS 的时间主控器，以解决错误的多样性，其中一些具有原子钟来交叉检查 GPS。 + * 守护程序每 30 秒与时间主对话，并获得时间修复。 在两者之间，死者根据自己的晶体进行侦察。 服务器错误容限随着时间的推移而扩大，他们选择了百万分之 200。 + * 现在几点了？ 在本地计算机上读取时间。 将 GetTime 发送到时间主机。 返回时间为 T。再次读取本地服务器时间。 你得到一些增量。 然后，您可以扩展该增量以获得所需的任何误差范围。 回来了一个ε。 现在您可以说时间在[t t + e）]中。 时间不早于 t，因为时间主因您收到 t 的回应而报告了 t 的因果关系。 但是会有很多偏差，因为邮件可能是在 epsilon 之前发送的。 您不知道往返 t 产生的位置。 开始漂移之前的主要错误是与主设备的往返时间。 + * 您可以建立 GPS 以外的其他系统来分配时间。 例如，LED 闪烁并为所有系统提供时钟脉冲。 使用心跳系统，该系统定期与中央服务器对话，并且在这些心跳之间，所有服务器都认为时间是固定的。 GPS 在那并且可以工作。 原子钟是一种方便的交叉检查。 而且所有硬件都不贵。 +* 当 Paxos 领导程序从客户端接收到提交请求时，该分区的 Paxos 领导程序流 + * 接收开始提交。 + * 获取事务锁定。 任何两阶段提交系统中的典型值。 抓住读写锁，以确保冲突的事务不会同时执行。 + * 选择一个时间戳记，以使 true.max 大于当前时间。 + * 并行执行两件事：运行 Paxos 以就写入内容达成共识，等待真正的时间肯定超过该写入时间戳记。 + * 通常，Paxos 将花费比等待更长的时间，因此它不会增加额外的开销。 + * 通知 Paxos 奴隶解锁。 + * 确认返回客户端。 +* 为什么起作用？ 通过等到提交时间戳记过去，我们将所有将来的事务推向更大的时间戳记。 保证下一个事务的时间戳大于前一个事务的时间戳。 **每个事务都同意选择一个比其起始点大的时间戳，并且每个事务都同意将其提交推迟到自己的提交时间戳记过去。** + * 当 Paxos 进行得太快或只有一个副本，而您只是要提交到本地磁盘时，TrueTime epsilon 可能比提交该提交所需要的时间大。 + * 当 TrueTime epsilon 达到峰值时发生，例如 TrueTime 母版下降并且您必须转到更远程的 TrueTime 母版的情况下。 或者当 Paxos 副本异常关闭时。 + * 现实中的 epsilon 在 1 到 7 毫秒之间反弹。 + * 当通过使用具有更高 QoS 的时间数据包来改进网络时，尾部延迟降低了。 < SDN 的一个论点，即通过系统以更高的 QoS 获得诸如时间和 Paxos 之类的控制数据包。 + * 通过更频繁地轮询时间主数据，以高 QoS 轮询，改善内核处理，在 NIC 驱动程序中记录时间戳，购买更好的振荡器，注意内核错误（节能模式（您使用的时钟））来减少 epsilon。 + +## 读取路径 + +* 类型： + * 在读取-修改事务中，看起来与标准的两阶段锁定相同，只是它发生在 Paxos 领导者身上。 获取读锁。 + * 不属于事务的强读取，客户端不会基于该读取进行写入。 Spanner 将选择一个更大的时间戳并在该时间戳上进行读取。 + * 当您只想知道数据已使用 5 或 10 秒时，就会读取陈旧的数据。 Spanner 将选择落入陈旧范围内的最大已提交时间戳。 + * MapReduce /批量读取-不在乎数据是否新鲜。 例如，让客户选择一个时间戳并说我想知道所有事情。 +* 为强读而选择的时间戳记： + * 问 TrueTime，现在的时间比现在大。 您知道这也大于所有先前提交的事务的提交时间戳。 并非总是最好的时间戳，因为您希望最大化能够在该时间戳上进行读取的副本。 + * 查看提交历史记录。 从最近的文章中选择一个时间戳。 + * 强制声明预读的范围。 例如，这 5 个用户和该系列产品。 范围的概念高于分区的概念。 + * 准备的分布式事务。 由于分布式事务必须在每个分区上同时提交时间戳，因此存在一个不确定性窗口，在此窗口中，您不会为某些对象提交什么数据来提交时间戳。 +* 有效使用原则： + * 数据局部性仍然很重要。 从一台机器上读取一堆东西比从一堆机器上读取要好。 将客户和订单放在同一分区中。 + * 大用户将跨越多个分区，但是跨分区在事务级别上不会产生语义影响。 + * 设计应用的正确性。 处理数百个需要处理但不需要那么快的细腻坚硬的角落案件。 例如，您一天更改几次 Gmail 过滤器？ + * 放宽仔细审核的高流量查询的语义。 也许在某些情况下，阅读会过时。 您过去读得越远，越能提供更多副本。 + * Spanner 中的默认语义是它们是可线性化的。 + * 使用闪存备份将允许毫秒写入。 +* 第一个大用户：F1 + * 已将对收入至关重要的共享 MySQL 实例迁移到 Spanner。 对 Spanner 数据模型的影响很大。 F1 需要一个强大的 MySQL。 + * Spanner 最初是 BigTable 之子 + * 包含许多分叉的 BigTable 代码，并带有分布式文件系统隐喻。 您有一棵目录树，每个目录都是地理位置的单位。 这与建立数据库的人无关。 + * 他们添加了结构化密钥，但最终他们只是在构建下一个 Megastore。 + * 他们决定 Spanner 需要更丰富的数据模型，从而确定 Spanner 是协议缓冲区的存储库。 Spanner 将是一个巨大的协议缓冲区。 这似乎是合理的，但同样，它不是用户建模数据的方式。 + * 他们认为 F1 是更好的模型，因此最终他们转向了关系数据模型。 + +## 他们现在在做什么？ + +* **完善 SQL 引擎**。 时间戳加迭代器的位置足以重启跨分区查询。 如果查询需要一分钟，并且负载平衡器在那一刻将您依赖的平板电脑移动到另一台服务器，或者该服务器被抢占，因为您正在共享单元中运行，并且抢占迫使这些平板电脑移动，查询会 不必中止，也不必扔掉工作。 像这样移动服务器很难工作，但对用户而言确实有价值。 +* **对内存使用情况的精细控制**，因此您无需创建分布式死锁，因为当一堆服务器都依赖于它们时，它们都需要内存才能取得进展，而它们都需要取得进展才能释放该内存 。 +* **细粒度的 CPU 调度**。 即使出现大得慢的大查询，也要保持快的查询快。应该对无希望的慢查询进行时间划分，以使快的查询保持快。 保持延迟的尾巴。 +* **基于快照隔离的强读取仍然非常绿色**。 这些正在以越来越多的用例进入生产。 +* **缩放到每个 Paxos 组**的大量副本。 您可以将 Spanner 分区用作严格有序的 pub-sub 方案，在该方案中，您在某个分区的所有位置都有只读副本，并且您正尝试使用它来以有序方式将数据分配到许多不同的数据中心。 这带来了不同的挑战。 如果您没有足够的带宽访问那些数据中心的某些子集，该怎么办？ 您不希望数据在领导者中缓冲太久。 如果您将其溢出到磁盘上，那么当带宽可用时，您就不会招致搜索损失。 它变得像水文学。 您需要将所有这些数据在不同的时间发送到不同的位置，并且希望在变化的条件下使所有流平稳地移动。 平稳地意味着更少的服务器重启，意味着更好的延迟尾部，意味着更好的编程模型。 + +## Q & A + +* 您如何证明交易之间没有依赖关系？ 假设某人通过电子邮件向某人发送了一些数据，然后该人单击了基于该数据的链接，从而导致了另一个数据中心的写入。 很难说两个不同中心之间的交易之间没有因果关系。 他们希望您能够在整个系统之间建立因果关系的前提下关联整个系统中事务的顺序。 +* 最终的一致性和交易模型的空间。 + * 移动是一种情况，用户在更新本地缓存，并且数据将其返回服务器，因此您不必依赖事务，因此必须具有某种最终的一致性机制来合并更改并处理冲突。 + * 允许并发编辑的 Google 文档是另一种情况。 您有五个打开的窗口，它们每个都在进行本地更新。 这些更新异步地冒泡回到服务器。 应用用于合并更新的可操作转换代数，然后才将这些更新应用于数据库的规范副本。 ## 相关文章 -* [在黑客新闻](https://news.ycombinator.com/item?id=7711110)上/ [在 Reddit](http://www.reddit.com/r/Python/comments/2504ni/update_on_disqus_its_still_about_realtime_but_go/) 上 +* [Alex Lloyd-建筑扳手](http://vimeo.com/43759726) 视频（ [幻灯片](http://berlinbuzzwords.de/sites/berlinbuzzwords.de/files/slides/alex_lloyd_keynote_bbuzz_2012.pdf) ） +* [Google Spanner 的最令人惊讶的启示：NoSQL 出现了，NewSQL 出现了](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html) +* [面板：大数据，无需 SQL，大问题，无需担心](http://static.usenix.org/multimedia/hotstorage11seltzer) （ [幻灯片](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf) ）（ [视频](https://www.usenix.org/conference/hotstorage11/panel-big-data-no-sql-big-problems-no-worries) ） +* [互联网规模的企业问题](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf) -对评论感兴趣的是，“ Go 不能直接访问数据库。它会占用 RabbitMQ 的队列并发布到 Nginx 前端”，但是我很难想象那里到底发生了什么。 可以再充实一点吗？ +伟大的帖子托德。 这些方法正在合并！ -理查德：链接的谈话可能是您获得更多细节的最佳选择，但我认为想法是，Disqus 的实时系统通过 RabbitMQ 获得新评论并通过 nginx 发送通知-它不具有长期状态 数据库。 因为我们实质上是在这里讨论通知系统，所以这很有意义。 - -我和理查德在一起。 对发生故障时会发生什么感到好奇。 - -因此，您用流队列替换了 Django（ORM），您的结论是 Go 的性能优于 Python？ 它甚至与编程语言有什么关系？ - -通常，当人们更改语言时，他们也会更改应用程序的架构 - -但是很难看出提速的百分比来自于语言 - -@Velko，不，不是这样。 通过阅读有关其先前设置的文章，了解有关哪些部分发生了变化的更多信息。 - -我想知道他们是否尝试过使用 pypy。 以我的经验，使用 pypy 的 Python 和 Go 一样快。 - -[PyPy](http://pypy.org/) - -PyPy 是 Python 语言（2.7.9 和 3.2.5）的一种快速，兼容的替代实现。 它具有几个优点和独特的功能 - -通过阅读有关其先前设置的文章，了解有关哪些部分发生了变化的更多信息。 \ No newline at end of file +您的文章内容丰富，但有时我会觉得有些困惑。 谢谢托德。 \ No newline at end of file diff --git a/docs/107.md b/docs/107.md index b312f00..4b2cf97 100644 --- a/docs/107.md +++ b/docs/107.md @@ -1,259 +1,140 @@ -# Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理 +# BigData 使用 Erlang，C 和 Lisp 对抗移动数据海啸 -> 原文： [http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html](http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html) +> 原文： [http://highscalability.com/blog/2012/11/26/bigdata-using-erlang-c-and-lisp-to-fight-the-tsunami-of-mobi.html](http://highscalability.com/blog/2012/11/26/bigdata-using-erlang-c-and-lisp-to-fight-the-tsunami-of-mobi.html) -![](img/169da6be29a418ae00a0c92191729dff.png) +![](img/d7393e0f00b2136eb372dc5f189c4a3d.png) -*这是关于[的 Disqus 更新：它仍然是实时的，但是 Go 拆除了 Python](http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html) 。* +*这是 [Jon Vlachogiannis](http://www.linkedin.com/in/johnvlachoyiannis) 的来宾帖子。 Jon 是 [BugSense](http://www.bugsense.com/) 的创始人和首席技术官。* -您如何向 Web 规模应用程序添加实时功能？ 这就是 [Adam Hitchcock](https://www.linkedin.com/in/adamhitchcock) ，在 Disqus 上，Disqus 的一名软件工程师在精彩的演讲中谈到：[使 DISQUS Realtime](https://www.youtube.com/watch?v=5A5Iw9z6z2s) （[幻灯片](https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock)）。 +BugSense，是一个错误报告和质量指标服务，每天跟踪数千个应用程序。 当移动应用崩溃时，BugSense 可帮助开发人员查明并解决问题。 该初创公司向其客户提供一流的服务，其中包括 VMWare，三星，Skype 和数以千计的独立应用程序开发人员。 跟踪超过 200M 的设备需要快速，容错和廉价的基础架构。 -Disqus 必须采用他们的评论系统并为其添加实时功能。 在谈话之时（2013 年），他们每月只有 10 亿的唯一身份访问者，这并非易事。 +最近六个月，我们决定使用我们的 BigData 基础架构，向用户提供有关其应用性能和稳定性的指标，并让他们知道错误如何影响他们的用户群 和收入。 -Disqus 开发的是一种称为“实时”的实时评论系统，该系统经过测试可处理 150 万个并发连接的用户，每秒 45,000 个新连接，每秒 165,000 条消息，并且端到端的延迟少于 0.2 秒。 +我们知道我们的解决方案应该从第一天开始就可以扩展，因为超过 4％的智能手机将开始使用 DDOS 向我们提供数据。 -评论系统的本质是它受 IO 约束并且具有很高的扇出度，这是评论的传入，必须将其发送给许多读者。 这个问题与 Twitter 必须解决的[非常相似。](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) +我们希望能够： -Disqus 的解决方案及其解决之道非常有趣。 他们尝试了不同的体系结构，但选择了基于 Python，Django，Nginx Push Stream Module 和 Thoonk 构建的解决方案，这些解决方案均通过灵活的管道体系结构进行了统一。 在此过程中，我们能够大幅减少其服务器数量并轻松处理高流量负载。 +* 提取应用程序逻辑并使用 JSON 填充浏览器 +* 快速运行复杂算法 +* 无需专用 Hadoop 集群即可进行数据实验 +* 预处理数据，然后将其存储（减少存储） +* 能够在每个节点上处理超过 1000 个并发请求 +* 每个应用程序“加入”超过 1.25 亿行 +* 做到这一点，而无需花费大量的服务器时间 -在演讲的某一时刻，亚当问管道式架构是否是一个好的架构？ 对于 Disqus 消息，通过一系列转换进行过滤是完美的选择。 这是一个非常古老的想法。 Unix 系统 5 长期以来具有 [Streams 功能](http://infohost.nmt.edu/~eweiss/222_book/222_book/0201433079/ch14lev1sec4.html)用于创建灵活的管道体系结构。 这是组织代码的一种非常灵活而强大的方式。 +该解决方案使用： -因此，让我们看看 Disqus 如何发展其实时评论架构并在此过程中创建新旧事物。 +* 在 Azure 上运行的大型实例不到 20 个 +* 内存数据库 +* 一种用 C 语言编写的功能齐全的自定义 LISP 语言，用于实现查询，这比始终使 VM（带有垃圾收集器）联机的速度快很多倍 +* Erlang 用于节点之间的通信 +* 修改后的 TCP_TIMEWAIT_LEN 可以惊人地减少 40K 连接，节省了 CPU，内存和 TCP 缓冲区 -## 统计资料 +## 内存数据库万岁 -* 当前： +我们知道，处理所有这些流量的唯一方法是使用内存数据库。 - * 300 万个网站使用 Disqus 作为其评论系统 +不仅要处理巨大的数据集上的即席问题（例如，“有多少个使用三星设备的唯一用户在一个星期内有此特定错误”）， 内存限制还与数据处理前后的数据序列化和反序列化有关。 因此，我们启动了 LDB 项目。 - * 每月有十亿人参与对话 +## LDB 项目 - * 每月有 2000 万条评论 +您是否相信可以将来自各种来源（成千上万种不同资源，如移动设备）的数据馈送到系统中，在几行代码中描述要提取的信息，然后将所有这些信息掌握在您的指尖中 ？ 实时。 系统持续运行时？ +LDB 不仅是数据库，更是一个应用程序服务器。 即使是内存中数据，实际上也将数据存储在硬盘驱动器中并在其他节点之间复制。 -* 截至 2013 年 3 月： +对于 LDB，我们不会运行查询。 **我们之所以运行算法，是因为我们拥有用 C 语言编写的完整的自定义 LISP 语言，该语言可以访问与数据库**相同的地址空间。 这意味着您可以非常快速地搜索数据，增加计数器，获取/放置等。 - * 每月有十亿独立访客。 +拥有 LISP 的优点是，您可以轻松地像 Hive 这样创建类似于 SQL 的语言并实时查询数据，如下所示： - * 18 位工程师 +![](img/4f86c5099d53bd29080e5c65dc645ef5.png) -## 平台 +LDB 的工作方式如下： -* Python（Disqus 是一项服务，用 Python 和其他语言编写） +每个应用都有自己的 LDB。 这意味着它自己的内存空间。 这样，我们可以轻松地将较大的应用程序（在流量方面）移动到不同的计算机上。 -* Django +［HTG1］ ［HTG2］ ［HTG3］ ［HTG4］ ［HTG5］ ［HTG6］ ［HTG7］ ［HTG8］ ［HTG9］当请求来自移动设备时，主 LDB 节点接受连接（使用 erlang 线程池）并将数据转发到特定的数据库。 此请求处理机制用少于 20 行的 Erlang 代码实现。 我们选择 Erlang 进行节点间通信的另一个原因。 -* [Thoonk Redis 队列](http://blog.thoonk.com/) -Redis 之上的队列库。 +当请求“流式传输”到 LDB 时，名为“ process.lql”的文件负责分析，标记数据并创建任何计数器。 所有这些都是即时完成的，并可满足每个请求。 -* Nginx [推流模块](http://wiki.nginx.org/HttpPushStreamModule) -用于 Nginx 设置的纯流 http 推技术。 Comet 变得简单且真正可扩展。 +![](img/21f3217c4f84d924505193761bfaba1b.png) -* [Gevent](http://www.gevent.org/) -基于协程的 Python 网络库，该库使用 greenlet 在 libev 事件循环的顶部提供高级同步 API。 +我们能够做到这一点，因为启动 LISP-VM 并针对每个请求执行所有这些过程仍然很多次 始终使 VM（带有垃圾回收器）联机的速度更快。 -* 使用 EventSource 的长轮询（在浏览器中） +使用 LDB，我们可以使用不超过 3 行代码来创建时间序列和汇总数据。 +例如。 这样会为唯一用户创建 7 天的时间序列： -* [Sentry](https://github.com/getsentry/sentry) -一个与平台无关的实时错误记录和聚合平台。 +![](img/2e1e91d523a2dd76b05398fc2faee593.png) -* [缩放比例](https://github.com/Cue/scales) -跟踪服务器状态和统计信息，使您可以查看服务器的运行状况。 +## 备择方案 -* 在原始金属（而非 EC2）上运行。 +在我们的测试中，我们发现 SQL 数据库不太适合，因为我们的数据是非结构化的，并且我们需要很多复杂的“联接”（和许多索引）。 另一方面，对于 NoSQL 数据库，我们无法在数据上运行算法（在系统运行时），而使用映射器/约简器会使整个过程变得复杂而缓慢。 我们需要一个没有大锁或 DB 锁的高并发系统，该系统可以在仅几个 KB 的时间内跟踪数百万个唯一事件，并且非常容易扩展。 -## 架构 +一个很好的替代方法是使用 Stream 数据库（例如 [Storm](http://storm-project.net/) ）。 我们的主要问题是有很多活动部件和单个节点的性能。 使用 LDB，我们的优势是能够非常快速地处理数据（它们驻留在相同的内存空间中），将它们存储为聚合计数器或符号（因此，千兆字节的数据以 KB 为单位），然后让 DSL 执行任何关联 我们要在飞行中。 没有序列化/反序列化，没有网络调用，也没有垃圾收集器。 就像将汇编代码映射到您的数据上一样。 -* 实时动机： +在 LDB 之上，我们还有可以缩放和处理传入数据的接收器，一个流组件，其中的所有内容都在几行代码中定义，一个存储引擎和一个复制 发动机。 - * **参与度** 。 评论的实时分发鼓励用户在页面上停留更长的时间。 实时评论后的人比以前多。 +## 优化内核-TCP 的 UDP 行为 - * **买卖数据** 。 从全局评论流中创建消防软管产品。 +与每秒处理大量请求的其他服务相比，进行分析时的独特之处在于，移动设备与服务器之间的对话非常小（3 个 TCP 握手数据包，1 个有效负载数据包和 3 个 TCP 终止数据包 ）。 -* 旧的实时系统： +但是，TCP 在设计时并未考虑到类似问题（即设备之间的小对话框），并实现了称为 TIME_WAIT 的状态（持续时间约为 1） 分钟 （在 2.6 Linux 内核中），在该时间之后，最后一个 FIN 数据包发送之后，该特定连接元组的 TCP 状态保持打开状态一段时间，以便接收可能已延迟的任何杂散数据包（即 连接关闭）。 在我们的例子中，这有点没用（我们想要类似于 UDP 行为但具有 TCP 保证的东西），因为有效负载只有 1 个数据包（对于查看请求，最多 4 或 5 个数据包），因此我们决定修改内核源并减少 常量，此常量降至 20 英寸。结果是惊人地减少了 40K 连接，节省了 CPU，内存和 TCP 缓冲区。 - * 用 Django 编写的 Disqus 应用程序将通过许多键发布到内存缓存：Forum：id，thread：id，user：id，post：id。 也许将来有人会觉得有趣。 由于 pub / sub 的价格便宜，因此可以进行以后的创新。 +我们应用的补丁在文件中： +linux-kernel-source / include / net / tcp.h - * 前端客户端每隔几秒钟会轮询一次内存缓存密钥。 +#define TCP_TIMEWAIT_LEN（[ 60 * HZ ） +至 +#define TCP_TIMEWAIT_LEN（ 20 * HZ ） - * 客户端将显示任何新评论。 - - * 问题：根本没有缩放。 一次只有 10％的网络可以使用该产品。 - -* 第一种解决方法： - - * 新帖-> Disqus-Redis [发布/订阅](http://redis.io/topics/pubsub) -> [烧瓶](http://en.wikipedia.org/wiki/Flask_(web_framework)) （一个 Web 框架）前端集群<-HAProxy <-客户端。 - - * 客户端将连接到 HAProxy。 HAProxy 用于处理数百万个连接。 - - * 问题：由于烧瓶计算机正在执行冗余工作，因此它们很快耗尽了 CPU。 如果两个订户正在侦听同一线程，则该消息将被格式化两次。 - -* 第二种方法： - - * 已创建后端服务器以执行重复数据删除格式化工作。 - - * 新流程：新帖子-> Disqus-> redis 队列->“ python 胶” Gevent 格式服务器（2 个服务器用于冗余）-> redis 发布/订阅（6 个服务器） -> Flask FE（前端）群集（14 个大服务器）<-HA 代理（5 个服务器）<-客户端 - - * 效果很好。 除了扩展外，它使用的服务器越来越多，尤其是 Flask 集群。 Redis 发布/订阅集群也迅速增长。 - -## 第三种制胜法则： - -* 使用 [流水线架构](http://www.cs.sjsu.edu/~pearce/modules/patterns/distArch/pipeline.htm) ，其中消息在过滤器作用下从一个队列传递到另一个队列。 - -* 切换到 Nginx +推送流模块。 这取代了 redis pub / sub，flask 服务器和 HAProxy 集群。 - -* 新流程如下所示：新帖子-> Disqus-> redis 队列->“ python 胶” Gevent 格式服务器（2 个服务器）-> http 帖子-> nginx pub 端点- > nginx +推送流模块（5 个服务器）<-客户端 - -* 仅使用了 redis 的 pub / sub，并且 nginx 推送流模块支持相同的功能。 - -* 由于内核中的网络内存限制，需要 5 个推送流服务器。 这是一个套接字分配问题，即有很多套接字打开。 否则可以在 3 台服务器上运行，包括冗余。 - -* 流程中的 Disqus 部分是 Django Web 应用程序，它使用 post_save 和 post_delete 挂钩将内容放入 thunkk 队列中。 这些挂钩对于生成实时数据通知非常有用。 - -* Thoonk 是 Redis 之上的队列库。 - - * 他们已经有了 thunkk，因此可以使用它来代替分解 RabbitMQ 计算机的 HA 集群。 最终真的很喜欢它。 - - * Thoonk 被实现为状态机，因此很容易查看已声明或未声明哪些作业，等等。使故障后的清除变得容易。 - - * 由于使用 zset 将队列存储在 Redis 中，因此可以在队列上执行范围查询。 例如，您可以询问哪些消息已被处理，并采取适当的措施，因此对实施端到端的确认很有用。 - -* python 胶水程序。 - - * 收听 thoonk 队列。 - - * 为客户端执行所有格式化和计算。 包括清洁和格式化数据。 - - * 最初是在 Flask 群集中进行格式化的，但是这占用了太多 CPU。 - - * 发现用 gzip 压缩单个邮件并不成功，因为邮件中没有足够的冗余来从压缩中节省足够的钱。 - - * 对于这样的 IO 绑定系统，Gevent 的运行速度非常快。 - - * 看门狗确保 [绿色](https://pypi.python.org/pypi/greenlet) 始终在运行，也就是说，始终在执行工作。 Greenlet 是没有隐式调度的微线程： [协程](http://en.wikipedia.org/wiki/Coroutine) 。 - - * 监视器监视许多故障，然后在观察到时发出警报。 - -* 流水线架构。 - - * python 胶水程序的结构是一个数据管道，数据必须经过几个阶段：解析，计算，发布到另一个地方。 这些在 greenlet 中运行。 - - * [Mixins](http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful) 用于实现阶段功能：JSONParserMixin，AnnomizeDataMixin，SuperSecureEncryptDataMixin，HTTPPublisher，FilePublisher。 - - * 这个想法是组成管道。 一条消息将从 thunkk 中传出并通过以下管道运行：JSONAnnonHTTPPipeline，JSONSecureHTTPPipeline，JSONAnnonFilePipeline。 - - * 管道可以共享它们的大多数功能，但是仍然是专门的。 启用新功能时很棒，您可以创建一个新的管线阶段，创建一个新的管线，并使旧管线与新管线并排运行。 新旧功能愉快地共存。 - - * 测试也可以在管道中进行。 要运行测试，只需在管道中插入 filter / module / mixin 即可运行测试。 - - * 容易推断。 每个 mixin 都很容易理解。 它做一件事。 项目中的新工程师使用这种方法设计的系统要容易得多。 - -* Nginx 推送流 - - * 处理系统的发布/订阅方面和 Web 服务方面。 并且都很好。 - - * 最近通过 5 台服务器吸引了 200 万并发用户。 CPU 使用率低于 15％时，每台计算机的用户数量达到约 950K 的峰值，每台计算机达到 40 MB /秒。 - - * 持续将数据写入套接字以测试套接字是否仍然打开。 如果不是，则将其清理以为下一次连接腾出空间。 - - * 配置是发布端点和订阅端点，以及如何在它们之间映射数据。 - - * 内置良好的监视功能，可通过推送流状态端点进行访问。 - - * 模块中的内存泄漏需要全天滚动重启，尤其是当每个进程有数十万个并发连接时。 浏览器将在断开连接时迅速知道，因此它将重新启动并重新连接。 - -* 较长的轮询 - - * 这是在浏览器/ JavaScript 客户端上。 - - * 当前使用 WebSocket 的原因是它们速度很快，但由于它内置在浏览器中并且可以处理所有内容，因此正在迁移到 EventSource。 只需注册消息类型并为其提供回调处理程序即可。 - -## 测试 - -* 黑暗时间测试。 Disqus 已安装在数百万个网站上，因此需要对数百万个并发连接进行测试。 使用现有网络进行负载测试，而不是在 EC2 中创建伪设置。 - -* 例如，有条理的客户说只有 10％的用户或恰好这个网站应该流经新系统。 - -* 最暗时间。 世界上发生了一些重要的事情，而且两个网站的流量也很大。 因此，他们接受了所有流量，并通过系统中的单个 pub / sub 密钥发送了流量。 这有助于识别代码中的许多热点。 - -## 度量 - -* 测量所有东西。 在流水线系统中，您只需测量每个阶段的输入和输出，即可与 HAProxy 等其他系统协调数据。 没有测量数据，就无法向下钻取并找出谁是错的。 - -* 尽可能将指标表示为+1 和-1。 （我不太了解这一点） - -* Sentry 帮助查找代码中的问题。 - -* 通过测量，可以轻松创建漂亮的图形。 - -* 当选择教皇并看到白色烟雾时，流量峰值达到每秒 245 MB，当天传输了 6 TB 数据，峰值 CPU 为 12％。 - -## 获得的经验教训 - -* **一次工作**。 在大型扇出架构中，在一个地方进行工作，然后将其发送给所有消费者。 不要为每个消费者重复工作。 - -* **最有可能失败的代码是您的代码**。 您很聪明，但是很聪明的人写了 redis 和其他产品，所以要比系统的其他部分更关心您的代码。 - -* **端到端的支架不错，但价格昂贵**。 想要 100％交付的客户所必需。 无法为每个前端用户做到这一点。 - -* **Greenlets 是免费的**。 使用它们。 它们使代码更易于阅读。 - -* **发布是免费的**。 发布到所有频道。 由于消息已通过所有渠道发布，因此他们无需事先进行计划就可以制作出实时的流量大图。 - -* **有时候会有个大胜利。** 发现 Nginx 推送流模块简化了其系统的巨大块并减少了服务器数量。 - -* **了解负载测试时的用例，以便您可以真正测试系统**。 - -* **使用实际流量进行测试**。 当您的系统变大并且生成合成负载本身就是一个巨大的项目时，这是一种容易得多的方法。 - -* **使用 Python** 。 他们确实喜欢 Python 和 Django，尽管其中一些后端内容现在是用 Go 编写的。 - -* **响应规模而增加的服务器数量是您的体系结构可能需要进行一些调整的标志。 看一看，您可以更改架构并更有效地使用资源。** - -* **使用现成的技术**。 不必觉得您必须从头开始构建所有内容。 利用代码，使您的团队规模变小。 +使用此架构，我们可以为所有付费客户（运行少于 20 个大型实例）提供有关移动应用程序的实时分析和见解。 在 Azure 上，包括后备和备份服务器。 ## 相关文章 -* [将 DISQUS 扩展到 7500 万评论和 17,000 RPS](http://highscalability.com/blog/2010/10/26/scaling-disqus-to-75-million-comments-and-17000-rps.html) （2010） +* [关于 HackerNews](http://news.ycombinator.com/item?id=4833052) + +既然没有垃圾收集器，如何在 LISP 实现中回收内存？ 谢谢。 -* Disqus [nginx-push-stream-module 配置](https://gist.github.com/dctrwatson/0b3b52050254e273ff11) 适用于> 1MM 并发用户。 +好贴！ 我特别喜欢 TCP 技巧。 您能否分享每天有多少事件和多少数据进入？ 另外，您要从中提供查询的内存数据集大小是多少？ 我对您正在执行的联接大小特别感兴趣。 -* [通过](https://www.youtube.com/watch?v=5A5Iw9z6z2s) [Adam 制作 DISQUS 实时](https://www.linkedin.com/in/adamhitchcock) （ [幻灯片](https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock) ） 希区柯克 ，软件工程师，〜2013 年 3 月 +噢亲爱的。 `tcp_tw_reuse`或`tcp_tw_recycle`有什么问题？ -* [将 Django 扩展到 80 亿页面浏览量](http://blog.disqus.com/post/62187806135/scaling-django-to-8-billion-page-views) [Matt Robenolt](https://www.linkedin.com/in/mattrobenolt) ，运筹领先，2013 年 9 月 +何俊！ -* [HTTP for Great Good](https://www.youtube.com/watch?v=HAjOQ09I1UY) （[幻灯片](https://speakerdeck.com/mattrobenolt/http-for-great-good)），作者：Matt Robenolt，2013 年 10 月 +我非常喜欢阅读！ 我是一位经验丰富的 Erlang 程序员，我很想阅读有关 Lisp 实际使用的更多信息。 如果您有任何有关 List 的良好介绍性文章的链接，那就太好了！ -* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) +非常感谢您的精彩文章！ -* [Twitter 用来处理 1.5 亿活跃用户，300K QPS，22 MB / S Firehose 的架构，并在 5 秒内发送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) +本文充满了不寻常的陈述和设计决策，我怀疑 BugSense 是由外星人控制的：） -* John Watson 的 [C1MM 和 NGINX](https://www.youtube.com/watch?v=yL4Q7D4ynxU) （[[幻灯片](https://speakerdeck.com/dctrwatson/c1m-and-nginx)）-Disqus 结构的更新。 +有什么问题：echo“ 20” > / proc / sys / net / ipv4 / tcp_fin_timeout？ 不工作？ -* [试试这个 Go 事情…](http://blog.disqus.com/post/51155103801/trying-out-this-go-thing) +在每个请求上启动 LISP VM 的速度要比一直保持 VM 联机的速度快？ 好的，我明白了，Lisp VM 不能很好地完成 GC。 但是有一个 JVM 和 Clojure（Lisp 方言顺便说一句） -引用“如果可以的话，将指标表示为+1 和-1。（我不太了解这一点）” +LISP + Erlang 的组合？ 有人非常了解 Lisp 和 Erlang :)。 -这不仅仅是计数指标吗？也就是说，因为您正在使用链接的消息队列，因为消息到达您对计数器+1 的每个点，而消息离开您-1 的另一个计数器。 您可以在每个节点/队列的输入和输出处执行此操作。 -每个点+1 的变化，每个点-1 的变化告诉您每个时间间隔（传入和传出）的消息吞吐量，总+1 和总-1 的差告诉您消息' 在队列中”。 +嗯-而不是在服务器上浪费 TCP 时间，您难道不就让客户端在服务器之前关闭 TCP 连接吗？ 这将给客户端增加“等待时间”的负担。 -好读！ +我猜您的协议目前已经广泛部署，因此更改它为时已晚？ -好东西。 +我愿意在这方面寻找另一面，但是我仍然看不到在提出了如此精美高效的体系结构之后，您选择使用 Windows Azure，这是最糟糕的此类产品（IaaS / PaaS） +。 ..我一直在烦我..这似乎引入了各种性能和财务瓶颈。 除非您对支持 Windows Phone 设备有何需求（极不可能）。 因此，我得出的结论是，您获得了免费优惠或其他优惠。请帮助我理解。 -现在，他们需要解决垃圾邮件问题。 +对于建议使用 tcp_tw_reuse 的人： -这看起来像一团糟。 在这家公司工作会很害怕。 这就是为什么您需要良好的系统架构师的原因。 如果您不能用 c / c ++自己编写（暗示理解）这些工具的一半，则需要重新考虑领导该项目。 现在您有了一个巨大的泥球，上帝知道有多少种不同类型的“粘土”。 -http://en.wikipedia.org/wiki/Big_ball_of_mud +http://serverfault.com/questions/303652/time-wait-connections-not-being-cleaned-up-after-timeout-period-expires -我很好奇他们是否会考虑为此使用 elixir 以及 phoenix 框架。 流水线方法，大规模，并发性和容错性固有地内置于长生不老药中，并且不需要像这样做的一整套分散的组件。 话虽如此。 做到这一点仍然是一个了不起的壮举，我敢肯定，出于很多原因，研究长生不老药可能不是他们追求的解决方案。 +tcp_fin_timeout 设置套接字在 FIN-WAIT-2 状态下花费的时间。 此参数不会影响在 TIME_WAIT 状态下花费的时间。 尝试 netstat -o 并观察处于 TIME_WAIT 状态的套接字的计时器值（选择 tcp_fin_timeout 值）。 -这看起来很混乱。 会害怕在这个组织工作。 这就是为什么您需要好的程序设计师。 如果您不能在 c / c ++中自己创建（暗示理解）这些资源的 50％，则需要重新评估获得的资源。 现在您有了一个伟大的泥泞足球，上帝知道有多少种“粘土”。 +@Sumit R：你的意思是...？ 您是否阅读了整个 serverfault 线程，特别是有关`tcp_tw_reuse`问题的答案？ 您实际上曾经使用过`tcp_tw_reuse=1`吗？ -我很好奇你们在 django 中存储持久连接的位置，这是我们的主要问题，我们的队列（我们使用 Rabbitmq）连接快要死了并且无法恢复。 +Lisp 解释器的内存处理由我们完成。 我们使用世代容器，并在每个“简短”脚本完成时回收分配的内存（对于“年轻”条目。由于系统体系结构/设计，无需收集“顽固”条目。通常，我们分为三代） 有自己的收集策略）。 因此，无需拥有成熟的垃圾收集器。 -现在他们需要解决垃圾邮件问题。这就是为什么您需要优秀的程序设计师。 如果您不能在 c / c ++中自己创建（暗示理解）这些资源的 50％，则需要重新评估获得的资源。 -好东西。 +我们不使用 JVM 或任何其他托管 VM 解决方案（Clojure，F＃等），因为我们只希望每个 VM（以及特定 VM 上的语言）提供的功能的子集，并且有大量空间可以优化 满足我们自己的“特殊”需求。 此外，Scheme（Lisp）还提供了构建具有表达力的程序所需的一切，这些程序通常具有功能范式的抽象和形式/模式。 -从它的声音来看，它听起来像是一个混乱的机构，但是，从它提供的服务的种类来看，我相信他们可能已经将其微调到可以接受的水平。 +你好 -我喜欢这篇文章，但有一个问题。 -Disqus 使用的数据库是什么？ +真的很想知道有关 Lisp（方案）实现以及它们如何与 Erlang 一起工作的更多信息。 您是否有可能开源示例或框架的一部分？ -该帖子解释了如何保存新帖子，但是当我打开网站并打开 Disqus 评论时。 获取所有评论并显示在网站上的过程是什么？ +无论如何，感谢您的文章。 -谢谢这个 \ No newline at end of file +此致 +尼古拉斯 \ No newline at end of file diff --git a/docs/108.md b/docs/108.md index a76d0b5..9ad076b 100644 --- a/docs/108.md +++ b/docs/108.md @@ -1,301 +1,139 @@ -# WhatsApp 如何每秒吸引近 5 亿用户，11,000 内核和 7,000 万条消息 +# 分析数十亿笔信用卡交易并在云中提供低延迟的见解 -> 原文： [http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html](http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html) +> 原文： [http://highscalability.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html](http://highscalability.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html) -![](img/6ed8bd179e354645ecb9c3ffe096b700.png) +![](img/99cc6b2427bd4e7b9d56427444015cb7.png) -上次[访问 WhatsApp](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) 时，他们刚刚被 Facebook 以 190 亿美元的价格收购。 我们了解了他们的早期体系结构，该体系结构主要集中于优化 Erlang，以处理服务器上的 200 万个连接，使用 All The Phones 并通过简单性使用户满意。 +*这是 [Ivan de Prado](http://www.linkedin.com/in/ivanprado) 和 [Pere Ferrera](http://www.linkedin.com/in/pedroferrera) 的来宾帖子， [Datasalt](http://www.datasalt.com) 的创始人， [Pangool](http://pangool.net) 和 [Splout SQL](http://sploutsql.com) 大数据开源项目。* -两年后，流量增长了 10 倍。 WhatsApp 如何使它跃升到新的可扩展性水平？ +使用信用卡支付的金额巨大。 显然，可以通过分析所有交易得出数据中的内在价值。 客户忠诚度，人口统计，活动热点图，商店推荐以及许多其他统计数据对于改善客户与商店之间的关系都非常有用。 在 [Datasalt](http://www.datasalt.com) ，我们与 [BBVA 库](http://www.bbva.com)合作开发了一个系统，该系统能够分析多年的数据并为不同的低延迟 Web 和移动应用程序提供见解和统计信息。 -[Rick Reed](http://www.linkedin.com/pub/rick-reed/2/186/427) 在 Erlang 工厂的一次演讲中告诉我们： [这是“十亿”，带有“ B”： WhatsApp 的下一个级别](https://www.youtube.com/watch?v=c12cYAUTXXs) （ [幻灯片](https://github.com/reedr/reedr/blob/master/slides/efsf2014-whatsapp-scaling.pdf) ），这显示了 WhatsApp 的统计数据： +除了处理大数据输入外，我们面临的主要挑战是**的输出也是大数据，甚至比输入**还大。 并且此输出需要在高负载下快速提供服务。 -> 拥有数百个节点，数千个内核，数百 TB 的 RAM 的东西，并希望为不久将在全球范围内成为现实的数十亿智能手机提供服务？ WhatsApp 上基于 Erlang / FreeBSD 的服务器基础结构。 在满足对消息传递服务不断增长的需求方面，我们面临着许多挑战，但是随着我们不断扩大服务范围（> 8000 核）和速度（>每秒 70M Erlang 消息）， 系统。 +由于使用了[云（AWS）](http://aws.amazon.com)， [Hadoop](http://hadoop.apache.org/) 和 [Voldemort](http://www.project-voldemort.com/voldemort/) ，我们开发的解决方案每月的基础设施成本仅为数千美元。 在下面的几行中，我们将解释所提出的体系结构的主要特征。 -与两年前相比，最显着的变化是什么？ +## 数据，目标和首要决策 -* 显然，除了工程师数量之外，每个维度都更大。 更多的盒子，更多的数据中心，更多的内存，更多的用户以及更多的扩展问题。 Rick 最引以为傲的是，用很少的工程师来处理这种增长水平：每个工程师 4000 万用户。 这是云计算胜利的一部分。 他们的工程师在他们的软件上工作。 网络，硬件和数据中心由其他人处理。 +该系统使用 BBVA 在世界各地的商店中进行的信用卡交易作为分析的输入源。 显然，数据是匿名的，非个人的，并且可以进行隔离以防止任何隐私问题。 信用卡号被散列。 任何产生的见解始终是汇总，因此无法从中获得任何个人信息。 -* 由于需要有足够的头部空间来处理每个盒子上增加的总体负载，因此他们放弃了尝试为每个盒子尽可能多地支持连接。 尽管他们通过增加大型机箱并在 SMP 机器上高效运行来降低管理开销的一般策略仍然保持不变。 +我们为每个商店和不同时间段计算许多统计数据和数据。 这些是其中一些： -* 瞬态很好。 如今，多媒体，图片，文本，语音，视频已成为其体系结构的一部分，而不必长期存储所有这些资产，极大地简化了系统。 该体系结构可以围绕吞吐量，缓存和分区展开。 +* 每个商店的付款金额直方图 +* 客户保真 +* 客户人口统计 +* 店铺推荐（在这里购买的客户也可以在...购买）。 按位置，商店类别等过滤。 -* Erlang 是它自己的世界。 听了这个谈话，很清楚您在 Erlang 的世界观中所做的一切都多少，这可能会令人迷惑。 尽管最终是一个分布式系统，所有问题都与其他任何分布式系统相同。 +该项目的主要目标是通过低延迟的 Web 和移动应用程序向所有代理（商店，客户）提供所有这些信息。 因此，一项苛刻的要求是能够在高负载下以亚秒级的延迟提供结果。 由于这是一个研究项目，因此需要处理代码和要求方面的高度灵活性。 -* Erlang 数据库 Mnesia 似乎是造成大规模问题的重要原因。 这让我想知道是否还有其他一些数据库可能更合适，是否需要留在 Erlang 解决方案系列中是否会有点盲目呢？ +因为一天仅更新数据不是问题，所以我们选择了面向批处理的架构（Hadoop）。 我们选择 Voldemort 作为只读存储来提供 Hadoop 生成的见解，这是一个简单但超快速的键/值存储，可以与 Hadoop 很好地集成。 -* 您可能会想到很多与规模有关的问题。 不稳定的连接问题，队列太长以至于它们会延迟高优先级的操作，定时器的抖动，在一种流量级别上正常工作的代码在较高流量级别上严重中断，高负载下的高优先级消息无法得到服务，阻塞其他操作的问题 意外的方式，导致资源问题的故障等等。 无论您使用什么系统，这些事情都会发生，并且必须通过它们来解决。 +## 该平台 -* 我对 Rick 跟踪并修复问题的能力感到震惊和惊讶。 非常令人印象深刻。 +该系统基于 [Amazon Web Services](http://aws.amazon.com/) 构建。 具体来说，我们使用 S3 存储原始输入数据，使用 Elastic Map Reduce（亚马逊提供的 Hadoop）进行分析，并使用 EC2 提供结果。 使用云技术使我们能够快速迭代并快速交付功能原型，这正是我们这类项目所需的。 -瑞克总是讲好话。 他非常慷慨地提供具体细节，这些细节显然直接来自生产中遇到的问题。 这是我对他的讲话的掩饰… +## 架构 -## 统计信息 +![](img/1e99350f5920f4f713d11ef7c9d510e4.png) -* 每月有 4.65 亿用户。 +该体系结构包含三个主要部分： -* 每天& 40B 中有 19B 条消息 +* **数据存储**：用于维护原始数据（信用卡交易）和生成的 Voldemort 存储。 +* **数据处理**：在 EMR 上运行的 Hadoop 工作流，执行所有计算并创建 Voldemort 所需的数据存储。 +* **数据服务**：Voldemort 群集，用于服务来自数据处理层的预先计算的数据。 -* 600M 图片，2 亿语音，1 亿视频 +银行每天都将当天发生的所有交易上载到 S3 中的文件夹中。 这使我们能够保留所有历史数据-每天执行的所有信用卡交易。 所有这些数据都是处理层的输入，因此我们**每天都重新计算所有内容**。 重新处理所有数据可以使我们变得非常敏捷。 如果需求发生变化或发现一个愚蠢的错误，我们只需更新项目代码，并在下一批之后修复所有数据。 这是一项发展决定，为我们带来了： -* 147M 高峰并发连接-手机已连接到系统 +* 简化的代码库&架构， +* 灵活性&适应变化， +* 轻松处理人为错误（只需修复错误并重新启动过程）。 -* 230K 高峰登录/秒-电话连接和断开连接 +每天一次，控制器在 EMR 上启动新的 Hadoop 集群并启动处理流程。 此流程由大约 16 个[元组 MapReduce 作业](http://www.datasalt.com/2012/02/tuple-mapreduce-beyond-the-classic-mapreduce/)组成，这些作业计算各种洞察力。 流的最后一部分（Voldemort 索引器）负责构建数据存储文件，该文件随后将部署到 Voldemort。 流程完成后，结果数据存储文件将上传到 S3。 控制器关闭 Hadoop 集群，然后将部署请求发送到 Voldemort。 然后，Voldemort 从 S3 下载新的数据存储并执行热交换，完全替换旧的数据。 -* 342K 峰值 msgs in / sec，712K 峰值 +## 技术 -* 大约有 10 位团队成员在 Erlang 上工作，他们既处理开发工作，又处理操作。 +### Hadoop 和 Pangool -* 假期多媒体使用率最高。 +整个分析和处理流程是使用 Hadoop 之上的 [Pangool Jobs](http://pangool.net) 实现的。 这使我们在性能，灵活性和敏捷性之间取得了良好的平衡。 元组的使用使我们能够使用简单的数据类型（int，字符串）在流之间传递信息，同时我们还可以将其他复杂的对象（如直方图）包含在其自己的自定义序列化中。 - * 输出 146Gb / s（圣诞节前夕），电话的带宽相当大 +另外，由于 Pangool 仍然是低级 API，因此我们可以在需要时对每个 Job 进行很多微调。 - * 已下载 360M 视频（圣诞节偶数） +### 伏地魔 - * 已下载 2B 张图片（46k / s）（除夕） +![](img/1ebd61748cea4343d7797358d63067a3.png) [Voldemort](http://www.project-voldemort.com/voldemort/) 是 LinkedIn 基于 [Amazon Dynamo](http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html) 概念开发的键/值 NoSql 数据库。 - * 1 张图片已下载 3200 万次（除夕） +Voldemort 背后的主要思想是将数据分成多个块。 每个块都被复制并在 Voldemort 群集的节点中提供服务。 每个 Voldemort 守护程序都可以将查询路由到保留特定键值的节点。 Voldemort 支持快速读取和随机写入，但是对于此项目，我们将 Voldemort 用作只读数据存储区，在每次批处理之后替换所有数据块。 因为数据存储是由 Hadoop 预先生成的，所以查询服务不受部署过程的影响。 这是使用这种只读批处理方法的优点之一。 我们还具有灵活性，可以在需要时更改集群拓扑并重新平衡数据。 -## 堆栈 +Voldemort 提供了一个 Hadoop MapReduce 作业，该作业在分布式集群中创建数据存储。 每个数据块只是一个 [Berkeley DB](http://www.oracle.com/technetwork/products/berkeleydb/overview/index-093405.html) [B 树](http://en.wikipedia.org/wiki/B-tree)。 -* Erlang R16B01（加上自己的补丁） +Voldemort 的接口是 TCP，但我们想使用 HTTP 服务数据。 VServ 是一个简单的 HTTP 服务器，它将传入的 HTTP 请求转换为 Voldemort TCP 请求。 负载平衡器负责在所有 VServ 之间共享查询。 -* FreeBSD 9.2 +## 计算数据 -* Mnesia（数据库） +### 统计 -* 偏航 +分析的一部分在于计算简单的统计信息：平均值，最大值，最小值，标准偏差，唯一计数等。它们是使用众所周知的 MapReduce 方法实现的。 但是我们也计算一些直方图。 为了在 Hadoop 中有效地实现它们，我们创建了一个自定义直方图，该直方图只能通过一次计算。 而且，我们可以在一个 MapReduce 步骤中，在任意数量的时间段内，为每个商务计算所有简单的统计数据以及相关的直方图。 -* SoftLayer 是他们的云提供商，裸机，网络内相当隔离的双数据中心配置 +为了减少直方图使用的存储量并改善其可视化效果，将由许多分箱组成的原始计算出的直方图转换为可变宽度的分箱直方图。 下图显示了特定直方图的 3 槽最佳直方图： -## 硬件 +![](img/779804f408b769317f66c7adeabf68c9.png) -* 〜550 个服务器+备用设备 +使用[随机重启爬山](http://en.wikipedia.org/wiki/Hill_climbing)近似算法计算出最佳直方图。 下图显示了每次爬山迭代中可能的移动： - * 约 150 个聊天服务器（每个约 100 万个电话，1.5 亿个高峰连接） +![](img/98213b36ae6dffee5c9e390d629df3f5.png) - * 〜250 毫米（多媒体）服务器 +该算法已被证明非常快速和准确：与精确的动态算法（由[本文](http://cosco.hiit.fi/Articles/aistat07.pdf)实现）相比，我们达到了 99％的精度，速度提高了一个因子。 - * 2x2690v2 Ivy Bridge 10 核（超线程总共 40 个线程） +### 商业建议 - * 数据库节点具有 512GB 的 RAM +推荐使用共现进行计算。 也就是说，**如果有人在商店 A 和 B 中都购买了商品，则存在 A 和 B 之间的同现**。 即使购买者在 A 和 B 都购买了几次，也仅考虑一次共现。给定商店的顶级共同商店是该商店的推荐。 - * 标准计算节点具有 64GB RAM +但是需要对共现这一简单概念进行一些改进。 首先，因为几乎每个人都在其中购物，所以通过简单的降频来过滤掉最受欢迎的商店。 因此，推荐它们没有任何价值。 按位置（商店彼此靠近），商店类别或两者过滤推荐也可以改善推荐。 与“总是真实的”建议相比，基于时间的同现产生了更热烈的建议。 限制共现的时间会导致人们建议在第一次购买后立即购买的商店。 - * SSD 主要用于可靠性，但由于需要更多存储空间而存储视频时除外 +Hadoop 和 Pangool 是计算共现并生成建议的理想工具，尽管有些挑战并不容易克服。 特别是，如果一个买家在许多商店付款，则此信用通知的同现次数将显示二次增长，从而使分析不能线性扩展。 因为这种情况很少见，所以我们只考虑每张卡的并发数量，只考虑购买者购买最多的那些卡。 - * 双链路 GigE x2（面向用户的公共&面向后端系统的私有） +## 成本&一些数字 -* > 11,000 个内核运行 Erlang 系统 +BBVA 在西班牙进行的一年信用卡交易在 Voldemort 上提供的信息量为 270 GB。 整个处理流程将在 24 个“ m1.large”实例的群集上运行 11 小时。 整个基础设施，包括为生成的数据提供服务所需的 EC2 实例，每月费用约为 3500 美元。 -## 系统概述 +仍有优化的空间。 但是考虑到该解决方案敏捷，灵活且可在云中运行，价格相当合理。 在内部基础架构中运行的系统的成本将便宜得多。 -* 二郎的爱。 +## 结论&的未来 - * 很棒的语言，只用很少的工程师就能支持这么多的用户。 +由于使用了 Hadoop，Amazon Web Services 和 NoSQL 数据库等技术，因此可以快速开发可扩展，灵活的解决方案，并准备以合理的成本承受人为的失败。 - * 强大的 SMP 可扩展性。 可以运行非常大的盒子并保持较低的节点数。 操作复杂性随节点数（而不是核心数）而定。 +未来的工作将涉及用 [Splout SQL](http://sploutsql.com) 代替 Voldemort，它允许部署 Hadoop 生成的数据集，并将低延迟键/值扩展到低延迟 SQL。 由于可以“即时”执行许多聚合，因此可以减少分析时间并减少数据量。 例如，它将允许在任意时间段内汇总统计信息，而这是无法预先计算的。 - * 可以即时更新代码。 +在“ LinkedIn 开发的键/值 NoSql 数据库”之后，我停止阅读 -* 可扩展性就像清除雷区。 他们通常能够在爆炸之前发现并清除问题。 测试系统的事件是世界性事件，尤其是足球，这会产生较大的垂直负载峰值。 服务器故障，通常是 RAM。 网络故障。 和不良的软件推动。 +对那些什至不知道如何添加用户密码哈希的白痴都不感兴趣。 -* 传统外观架构： +这是一个令人困惑的描述，并且体系结构似乎布局/解释不当。 另外，如何处理节点故障？ - * 电话（客户端）连接到聊天和 MMS（多媒体）。 +回答“ dev”的评论：EMR 下的节点故障由 Amazon 透明处理，而 Voldemort 群集中的节点故障由 Voldemort 的故障转移功能处理。 我们只需要指定所需的复制因子，就可以相应地部署数据块。 - * 聊天连接到瞬时离线存储。 后端系统在用户之间传递消息时会保留它们。 +随意问您可能感兴趣的其他问题，并且您认为这些解释不够充分。 - * 聊天连接到数据库，例如帐户，个人资料，推送，群组等。 +感谢 Ivan 和 Pere，这非常有趣！ 我有一个快速的问题。 270 GB 的数据集并不是很大，并且由于您最终要使用 HTTP，所以我想知道是什么导致您选择 Voldermort 而不是像 Sofadb 这样的东西？ 我也对 Splout（您似乎是内部开发的）感到好奇。 在给定数据量的情况下，这似乎代表了相当大的工程努力-您能解释一下 Splout 在此特定用例与（敢于说）分片 RDBMS 的优势吗？ 非常感谢！ -* 发给手机的消息： +嗨斯蒂芬，谢谢你的评论和问题。 我们选择 Voldemort 的原因有三个：速度，简单性以及与 Hadoop 的良好集成。 我们认为很少有数据库可以有效地从 Hadoop 提取数据。 我们对那些其数据结构可以由 Hadoop 预先生成并且可以以全有或全无的方式部署 Hadoop 文件且不影响查询服务的数据库感兴趣。 这为系统增加了安全层，并使后端与前端完全脱开。 反过来，这使体系结构更简单，从而消除了在处理和服务之间逐渐增加流状态的需要。 - * 实际短信 +ElephantDB 是另一个可以满足这些要求并且可以选择的数据库，但是我们以前在 Voldemort 方面已有过积极的经验。 - * 通知：小组主题，个人资料照片更改等 +我不确定您的问题是否更像我们是否可以使用以 CouchDB 为中心的系统来替代 Hadoop + Voldemort。 如果真是这样，我们目前没有足够的 CouchDB 经验来判断这是否是一个有趣的选择。 - * 存在消息：键入，空闲，已连接/未连接等 +关于 Splout SQL，实际上您实际上可以将其视为分片的 RDBMS，但它是只读的，并且与 Hadoop 紧密集成，这正是我们所需要的。 通过成为只读文件，它实际上比传统的 RDBMS 变得更易于管理，并且通过将其与 Hadoop 集成，我们使应用程序能够轻松，安全地将数据从处理过程转移到服务过程中，而这正是我上面提到的所有好处。 -* 多媒体数据库： +关于数据大小，请考虑到 270 GB 仅是西班牙的一年数据，但是该应用程序可能会服务数年和多个国家/地区的数据。 此外，由于需求变化很快，因此输出幅度仍然未知，因为每次添加新功能时输出幅度可能都会增加。 - * 内存中 [Mnesia 数据库](http://www.erlang.org/doc/man/mnesia.html) 使用大约 2TB 的 RAM 在 16 个分区上分片，以存储约 180 亿条记录。 +希望这能回答您的问题，否则请随时提出。 - * 消息和多媒体仅在传递时存储，而在传递媒体时，有关媒体的信息存储在数据库中。 +谢谢 Pere，这很有道理-我现在意识到 Splout 或 ElephantDB 的优点是不必通过 MR 对初始数据存储进行处理，然后再将 ETL 转换为需要自己维护和明显的性能优势的单独存储 是只读+（我想）要维护的代码库较小（显然 Elephant 是 2k LoC！）。 干杯! -* 每台服务器的连接数为 100 万，而不是两年前的每台服务器 200 万的连接数，通常是因为服务器繁忙得多： +这是一个有趣的问题，但我只是希望对它进行更多的解释。 - * 随着更多的用户，他们希望在每台服务器上以更多的净空运行，以吸收峰值负载。 +使用这种类型的数据时（除规模之外），您遇到的最困难的事情是什么？ - * 用户比两年前更加活跃。 他们正在发送更多消息，因此服务器正在执行更多操作。 +我自己花了 10 多年的时间分析信贷/借记数据，我很好奇:) - * 这些服务器之外的功能已移至它们上运行，因此它们可以做更多的事情。 - -## 去耦 - -* 隔离瓶颈，使它们不会在系统中传播 - - * 紧密耦合会导致级联故障。 - - * 堆栈中较深的后端系统不应冒充前端。 - - * 所有内容均已分区，因此，如果一个分区出现问题，其他分区将不会受到影响。 - - * 解决问题时，请保持尽可能多的吞吐量。 - -* 异步性可最大程度地减少延迟对吞吐量的影响 - - * 即使在系统中的各个点存在等待时间或等待时间无法预测时，也可以保持尽可能高的吞吐量。 - - * 减少耦合，并使系统尽可能快地工作。 - -* 避免 [行头阻塞](http://en.wikipedia.org/wiki/Head-of-line_blocking) - - * 行头块是在队列中对第一个数据包进行处理而使在其后排队的所有那些项目饿死的地方。 - - * 分离的读写队列。 特别是在表上执行事务的地方，因此，如果在写侧存在任何延迟，则不会阻塞读侧。 通常，读取端的运行速度要快得多，因此任何阻塞都会堆积读取器。 - - * 单独的节点间队列。 如果某个节点或连接节点的网络出现故障，则可能会阻止应用程序中的工作。 因此，当将消息发送到不同的节点时，会将消息传递给不同的 [进程](http://www.erlang.org/doc/reference_manual/processes.html) （Erlang 中的轻量级并发），因此仅备份发往问题节点的消息。 这允许发送到健康节点的消息自由流动。 问题被隔离到问题所在。 修补的 mnesia 在 async_dirty 复制时可以很好地做到这一点。 发送消息的应用程序与发送程序是分离的，并且如果节点出现问题，则不会感到任何背压。 - - * 当使用不确定的延迟时，使用“队列” FIFO 工作程序分配模型。 - -* 元集群 - - * 请注意，本节仅在演讲开始约 29 分钟时进行，非常简短，很不幸。 - - * 需要一种方法来包含单个群集的大小，并允许其跨越很长的距离。 - - * 构建了 wandist，这是 gen_tcp 上类似 dist 的传输，它由需要相互通信的节点的网格组成。 - - * pg2 之上的透明路由层创建了一个单跳路由调度系统。 - - * 示例：两个数据中心中的两个主要群集，两个不同数据中心中的两个多媒体群集，以及两个数据中心之间的共享全局群集。 它们之间都有广电连接。 - -* 示例： - - * 通过使用 async_dirty 避免进行 Mnesia 事务耦合。 大多数交易未使用。 - - * 仅在从数据库取回时使用调用，否则将强制转换所有内容以保留异步操作模式。 在 Erlang 中，handle_call 会阻止响应，并且消息已排队，而 handle_cast 不会阻止，因为操作结果无关紧要。 - - * 呼叫使用超时，而不是监控器。 减少远端 proc 上的竞争，并减少分发渠道上的流量。 - - * 当只需要尽力而为时，请在演员表上使用 nosuspend。 如果一个节点有问题或网络有问题，这会将一个节点与下游问题隔离开，在这种情况下，分发缓冲区会在发送节点上备份，并且尝试发送的 proc 会被调度程序挂起，从而导致级联失败，每个人 正在等待，但尚未完成任何工作。 - - * 使用大型分配缓冲区来吸收网络和下游节点中的问题。 - -## 并行化 - -* 工作分配： - - * 需要分配超过 11,000 个核心的工作。 - - * 从单线程 [gen_server](http://www.erlang.org/doc/man/gen_server.html) 开始。 然后创建一个 gen_factory 以将工作分散到多个工作人员。 - - * 在一定的负载下，调度过程本身成为了瓶颈，而不仅仅是执行时间。 繁琐的操作使许多节点进入了盒子的调度过程，过程的锁定成为分配端口和过程本身进入的瓶颈。 - - * 如此创建了 gen_industry，位于 gen_factory 之上的一层，因此有多个调度过程，允许对进入包装盒的所有输入以及对工人本身的调度进行并行化。 - - * 通过一个键选择工作程序进行数据库操作。 对于 IO 等不确定的延迟情况，使用 FIFO 模型分配工作量以防止行首阻塞问题。 - -* 分区服务： - - * 在 2 到 32 种方式之间进行分区。 大多数服务是按 32 种方式分区的。 - - * [pg2 寻址](http://erlang.org/doc/man/pg2.html) ，它们是分布式进程组，用于寻址整个群集中的分区。 - - * 节点成对运行。 一个是小学，另一个是中学。 如果一个或另一个发生故障，它们将处理主要和次要流量。 - - * 通常尝试将访问单个 [集合](http://www.erlang.org/doc/man/ets.html) （内置术语存储）或单个记忆缺失片段的进程数限制为 8。 锁争用在控制之下。 - -* Mnesia： - - * 因为他们不使用事务来获得尽可能高的一致性，所以他们通过哈希将对单个节点上单个进程的记录的访问序列化。 哈希到一个分区，该分区映射到 [记忆缺失片段](http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html) ，最终被分派到一个工厂，一个工人中。 因此，对单个记录的所有访问都将进入单个 erlang 进程。 - - * 每个记忆缺失片段仅在一个节点上的应用程序级别被写入或读取，这使得复制流只能在一个方向上进行。 - - * 当同级之间存在复制流时，片段更新的速度会遇到瓶颈。 他们修补 OTP，以使多个事务管理器仅针对 async_dirty 运行，因此记录更新并行发生，从而提供了更多的复制吞吐量。 - - * 修补程序，用于将 mnesia 库目录拆分为多个库，这意味着可以将其写入多个驱动器，从而增加了磁盘的吞吐量。 真正的问题是何时从对等方加载了失忆症。 将 IO 分散在多个驱动器（甚至是 SSD）上，就数据库加载速度而言，提供了更大的可伸缩性。 - - * 将记忆缺失的岛屿缩小到每个岛屿的两个节点。 岛屿是记忆障碍的群集。 即使有 32 个分区，也将有 16 个支持一个表的岛。 由于只有两个节点需要完成架构操作，因此有更好的机会在负载下支持架构操作。 如果尝试同时启动一个或两个节点，则减少了加载时间协调。 - - * 通过快速警报来处理 Mnesia 中的网络分区。 他们继续运行。 然后进行手动对帐，以将它们合并在一起。 - -## 优化 - -* 离线存储系统曾经是负载高峰期间的一个大瓶颈。 只是无法将内容快速推入文件系统。 - - * 用户可以快速读取大多数邮件，例如 60 秒内可以读取 50％。 - - * 添加了回写缓存​​，因此可以在必须将消息写入文件系统之前将其传递。 98％的缓存命中率。 - - * 如果由于负载而备份了 IO 系统，则在 IO 系统追赶时，缓存会提供额外的缓冲以全速传输消息。 - -* 通过将 BEAM（Erlang VM）打补丁到所有异步工作线程中的循环文件端口请求，从而解决了异步文件 IO 中的行头阻塞问题，该问题在出现大邮箱或慢速磁盘的情况下可简化写操作 。 - -* 将大型邮箱保留在缓存之外。 有些人处于大量群组中，每小时收到数千封邮件。 他们污染了缓存并放慢了速度。 从缓存中逐出它们。 请注意，处理不成比例的大型用户是每个系统（包括 Twitter ）的问题。 - -* 缓慢访问带有很多碎片的失忆表 - - * 帐户表分为 512 个片段，这些片段被划分为多个孤岛，这意味着用户到这 512 个片段的稀疏映射。 大多数片段将是空的和空闲的。 - - * 主机数量加倍导致吞吐量下降。 事实证明，记录访问的速度确实很慢，因为当目标为 7 时，哈希链的大小超过了 2K。 - - * 发生的是散列方案导致创建了大量的空存储桶，而很少的存储桶非常长。 两行更改将性能提高了 4 比 1。 - -## 修补 - -* 争夺计时器轮。 在一台主机中有几百万个连接，并且每当特定电话发生任何事情时，每个连接都在设置和重置计时器，因此，结果是每秒成千上万个计时器设置和重置。 一个计时器轮和一个锁，这是一个重要的竞争来源。 解决方案是创建多个计时器轮以消除竞争。 - -* mnesia_tm 是一个很大的选择循环，在尝试加载表时，由于选择接收，积压可能会导致无法返回的点。 修补程序将物料从传入的事务流中拉出并保存以供以后处理。 - -* 添加多个 mnesia_tm async_dirty 发件人。 - -* 为 prim_file 命令添加标记/设置。 - -* 有些星团横跨整个大陆，因此，健忘症应该从附近的节点而不是整个国家/地区加载。 - -* 为异步文件 IO 添加循环调度。 - -* 种子和哈希散列以破坏与 phash2 的重合。 - -* 优化主要/名称表的比例。 - -* 如果已经遗失，请不要将其遗忘在队列中。 无法完成具有待处理的转储的架构操作，因此如果排队了很多转储，则无法进行架构操作。 - -## 2/22 中断 - -* 即使所有这些工作都发生了。 它发生在最坏的时间，在 Facebook 收购之后，发生了 210 分钟的中断[。](http://techcrunch.com/2014/02/22/whatsapp-is-down-facebooks-new-acquisition-confirms/) - -* 由于负载未发生。 它始于后端路由器问题。 - -* 路由器丢弃了 VLAN，该 VLAN 导致整个集群中大量节点断开/重新连接。 当一切重新连接时，它处于不稳定状态，他们从未见过。 - -* 最终决定，他们必须停止所有操作并将其恢复，这是他们多年来没有做过的事情。 花了一段时间才将所有内容放回原处并重新保存。 - -* 在此过程中，他们发现了一个过度耦合的子系统。 通过断开连接和重新连接，pg2 可以进入 n ^ 3 消息传递状态。 他们看到 pg2 消息队列在几秒钟内从零增加到 400 万。 推出补丁。 - -## 版本 - -* 无法模拟这种规模的流量，尤其是在高峰时段，例如午夜的新闻除夕。 如果他们尝试的是极具破坏性的措施，则推出的速度将非常缓慢。 只需要一小部分流量。 然后快速迭代，直到效果良好为止，然后部署到集群的其余部分。 - -* 推出是滚动升级。 一切都是多余的。 如果他们要进行 BEAM 升级，则会先安装 BEAM，然后逐步在集群中执行重新启动以获取新更改。 有时，它只是一个热补丁，无需全面重启就可以推出。 这是罕见的。 通常升级整个事情。 - -## 尚待解决的挑战 - -* 由于升级，数据库会定期刷新。 数据量太大的问题需要花费很长时间才能加载，并且由于各种原因，加载会在较大规模下失败。 - -* 实时集群状态&大规模控制。 旧的 shell 窗口方法不再起作用。 - -* 2 次幂分割。 现在有 32 个分区。 下一步是 64，这将起作用，但是 128 分区将是不切实际的。 关于这一点没有太多讨论。 - -对 whatapp 与其他聊天应用说微信/行比较的兴趣，是否有关于此的博客/文章/文档？ - -Softlayer 的路由器只是“丢弃” VLAN。 - -他们可以通过廉价找到的 LCD（最低公分母）人员联网的另一朵云。 - -检查我们。 我们可以做的更好：) - -是的，乔，让我们使用您的小公司。 这并不是说 Softlayer 并不是一个存在时间更长的大型企业集团。 他们并不便宜。 他们很容易成为更高端的提供商之一。 他们知道自己在做什么。 一个问题并不大。 AWS 遇到了一些问题。 - -您的帖子只是展示您的天真，给您的公司起了坏名声。 我建议不要发布有关其他提供商的负面评论，以使自己看起来不错。 \ No newline at end of file +谢谢 +Jon Wren \ No newline at end of file diff --git a/docs/109.md b/docs/109.md index bf80bdb..554b224 100644 --- a/docs/109.md +++ b/docs/109.md @@ -1,102 +1,67 @@ -# 大，小，热还是冷-条带，Tapad，Etsy 和 Square 的健壮数据管道示例 +# MongoDB 和 GridFS 用于内部和内部数据中心数据复制 -> 原文： [http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html](http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html) +> 原文： [http://highscalability.com/blog/2013/1/14/mongodb-and-gridfs-for-inter-and-intra-datacenter-data-repli.html](http://highscalability.com/blog/2013/1/14/mongodb-and-gridfs-for-inter-and-intra-datacenter-data-repli.html) -[![](img/d95d6fc5fd7b47e48afbe6d9bd2b671b.png)](http://surf.transworld.net/1000104592/features/the-10-best-surf-photos-in-the-history-of-transworld-surf/) +![](img/8bf2ff01d2394d7e2b94688b0b76f3d8.png) *这是 LogicMonitor 副总裁 [Jeff Behl](jbehl@logicmonitor.com) 的来宾帖子。 [在过去 20 年中，Jeff](@jeffbehl) 有点过时，他为许多基于 SaaS 的公司设计和监督基础架构。* -*这是 [Hakka Labs](https://twitter.com/petesoder) 的创始人 [Pete Soderling](https://twitter.com/petesoder) 的[访客转发](http://www.hakkalabs.co/articles/big-small-hot-cold-data-needs-robust-pipeline)，创建了软件工程师成长的社区。* +## 用于灾难恢复的数据复制 -针对 MongoHQ 最近发表的题为“ [您没有大数据](http://blog.mongohq.com/you-dont-have-big-data/)”的帖子，我通常会同意作者的许多观点。 +灾难恢复计划的必然部分是确保客户数据存在于多个位置。 对于 LogicMonitor，这是一个基于 SaaS 的物理，虚拟和云环境的监视解决方案，我们希望在数据中心内外都可以复制客户数据文件。 前者用于防止设施中的单个服务器丢失，而后者用于在数据中心完全丢失的情况下进行恢复。 -但是，无论您称其为大数据，小数据，热数据还是冷数据-我们都有能力承认*更多*数据将保留下来-这是由于许多不同的因素造成的。 +## 我们在哪里：Rsync -如本文所述，可能主要是由于存储成本随着时间的推移而降低。 其他因素包括对开放 API 的访问，在线上不断增长的消费者活动的数量，以及公司相互“共享”数据时在幕后形成的（主要是）幕后发展的大量其他激励措施。 （您知道[他们这样做](http://www.theguardian.com/business/2013/jun/24/barclays-bank-sell-customer-data)，对吧？） +像大多数在 Linux 环境下工作的人一样，我们使用了可信赖的朋友 rsync 来复制数据。 -但是，过去两年来我学到的最重要的事情之一是，对于具有远见卓识的公司而言，开始设计更强大的数据管道以收集，汇总和处理不断增长的数据量至关重要。 这样做的主要原因是能够以一致的方式准备好看似神奇的类似量子的操作的数据，这些操作可以推断数据之间的关系，否则这些关系肯定不会引起注意-在引用的文章中巧妙地描述为“ 从针头堆中确定针头的性质。” +![](img/5d8418f63b8ea168deb7b0bafc7c4dce.png) -但这提出了一个问题-精心设计的数据管道的特征是什么？ 您难道不可以将所有数据都放入 Hadoop 并称之为一天吗？ +Rsync is tried, true and tested, and works well when the number of servers, the amount of data, and the number of files is not horrendous.  When any of these are no longer the case, situations arise, and when the number of rsync jobs needed increases to more than a handful, one is inevitably faced with a number of issues: -正如许多工程师所发现的那样-答案是巨大的“不！” 我们汇总了 Stripe，Tapad，Etsy & Square 的智能工程师的四个示例，这些示例展示了您实际上可以在野外看到的一些实际数据管道的各个方面。 +* 备份作业重叠 +* 备份作业时间增加 +* 过多的同时作业使服务器或网络超载 +* 完成 rsync 作业后，没有简单的方法来协调所需的其他步骤 +* 没有简便的方法来监视作业计数，作业统计信息并在发生故障时得到警报 -## **Stripe 如何做到？** +Here at LogicMonitor [our philosophy](http://blog.logicmonitor.com/2012/07/17/our-philosophy-of-monitoring/) and reason for being is rooted in the belief that everything in your infrastructure needs to be monitored, so the inability to easily monitor the status of rsync jobs was particularly vexing (and no, we do not believe that emailing job status is monitoring!).  We needed to get better statistics and alerting, both in order to keep track of backup jobs, but also to be able to put some logic into the jobs themselves to prevent issues like too many running simultaneously.The obvious solution was to store this information into a database. A database repository for backup job metadata, where jobs themselves can report their status, and where other backup components can get information in order to coordinate tasks such as removing old jobs, was clearly needed.  It would also enable us to monitor backup job status via simple queries for information such as the number of jobs running (total, and on a per-server basis), the time since the last backup, the size of the backup jobs, etc., etc.    -我们在 [Stripe](http://www.hakkalabs.co/companies/stripe) 上与 Avi Bryant 进行了交谈，后者为我们很好地描述了 Stripe 进行数据管道构建的方式。 +## MongoDB 作为备份作业元数据存储 -> Stripe 从各种来源向 HDFS 馈送数据，其中许多是非结构化或半结构化的 -> -例如服务器日志或 JSON -> 和 BSON 文档。 在每种情况下，第一步都是将 -> 转换为结构化格式。 我们已经标准化了使用 Thrift 来定义 -> 的逻辑结构，并使用 Parquet 作为磁盘上的存储 -> 格式。 -> -> 我们选择 Parquet 是因为它是 Cloudera Impala 查询引擎固有的高效列格式 -> ， -> 使我们可以快速关联数据访问临时报告。 -> Parquet 和 Thrift 的组合也可以有效地使用，并且 -> 可以从 Twitter 的 Scalding 框架中惯用，这是我们为复杂批处理选择的 -> 工具。 -> -> 下一阶段是``非规范化''：为了保持我们的分析工作和 -> 查询快速，我们会在 Scalding 中提前进行最常见的联接， -> 写入新的 Thrift 模式集。 同时，我们进行了大量的 -> 增强和注释数据：例如，对 IP -> 地址进行地理编码，解析用户代理字符串或清除丢失的值。 -> -> 在许多情况下，这会导致结构具有嵌套结构， -> 在 Scalding 中效果很好，并且哪个 Parquet 很高兴存储，但是 -> 目前 Impala 无法查询。 我们开发了一个简单的工具 -> ，该工具可将任意嵌套的 Parquet 数据转换为等效的 -> 扁平化架构，并在必要时使用它来 -> 维护每个数据源的并行副本以供 Impala 使用。 -> 我们期待着 Impala 的未来版本，该版本可能会删除 -> 这个额外的步骤。 +The type of backup job statistics was more than likely going to evolve over time, so MongoDB came to light with its “[schemaless](http://blog.mongodb.org/post/119945109/why-schemaless)” document store design.  It seemed the perfect fit: easy to setup, easy to query, schemaless, and a simple JSON style structure for storing job information.  As an added bonus, MongoDB replication is excellent:  it is robust and extremely easy to  implement and maintain.  Compared to MySQL, adding members to a MongoDB replica set is auto-magic.So the first idea was to keep using rsync, but track the status of jobs in MongoDB. But it was a kludge to have to wrap all sorts of reporting and querying logic in scripts surrounding rsync.  The backup job metainfo and the actual backed up files were still separate and decoupled, with the metadata in MongoDB and the backed up files residing on a disk on some system (not necessarily the same).  How nice it would be if the the data and the database were combined.  If I could query for a specific backup job, then use the same query language again for an actual backed up file and get it.  If restoring data files was just a simple query away...  [Enter GridFS](http://docs.mongodb.org/manual/applications/gridfs/). -## **Tapad 的数据管道** +## 为什么选择 GridFS -[Tapad](http://www.hakkalabs.co/companies/tapad) 是纽约市的一家广告技术公司，在过去几年中，其流量和数据均实现了大幅增长。 因此，我联系了他们的 CTO [Dag Liodden](http://www.hakkalabs.co/engineers/dag-liodden) ，以了解他们如何构建数据管道以及他们使用的一些策略和工具。 用达格的话来说，这是他们的做法： +You can read up on the details GridFS on the MongoDB site, but suffice it to say it is a simple file system overlay on top of MongoDB (files are simply chunked up and stored in the same manner that all documents are).  Instead of having scripts surround rsync, our backup scripts store the data and the metadata at the same time and into the same place, so everything is easily queried. -* 所有摄取的数据都以 pub-sub 方式流过消息队列（我们使用 Kafka 并每小时通过它推送多个 TB 数据） -* 所有数据均使用支持架构演进的一致的非规范化架构进行编码（我们使用 Avro 和 Protocol Buffers） -* 我们的大多数数据存储都从消耗消息队列的流程进行实时更新（将热数据推送到 Aerospike 和 Cassandra，将实时可查询的数据推送到 Vertica，并且原始事件通常存储有来自 Aerospike 集群的数据， 在 HDFS 中） -* 高级分析和数据科学计算通常在 HDFS 中对非规范化数据执行 -* 实时更新始终可以通过脱机批处理作业复制到 HDFS 存储的数据上。 我们努力使我们的计算逻辑，使其可以在流中*和*以批处理 MR 模式运行，而无需进行任何修改 +当然，MongoDB 复制可与 GridFS 一起使用，这意味着备份的文件可立即在数据中心内和异地复制。 通过 Amazon EC2 内部的副本，可以拍摄快照以保留所需的尽可能多的历史备份。 现在，我们的设置如下所示： -他指出，最后一点使他们可以随意更改其流计算，然后用更新的预测回填其他数据存储。 +![](img/3c3ccfd357f047d89266ff1df34f8b30.png) -Dag 还解释了在存储方面使用多种类型的数据技术背后的“原因”，并解释了它们中的每一个都有其自己的特定“最佳位置”，这使其对它们具有吸引力： +优点 -* Kafka：高吞吐量并行发布订阅，但宽松的传递和延迟保证，有限的数据保留和无查询功能。 -* Aerospike：按键（我们拥有 32 亿个键和 4TB 复制数据），跨数据中心复制，高可用性但查询功能非常有限，按键具有极快的随机访问读/写性能 -* Cassandra：中等的随机访问读/写性能，原子计数器和数据模型，非常适合时间序列存储。 灵活的一致性模型和跨数据中心复制。 -* HDFS：高吞吐量和廉价的存储。 -* Vertica：快速和强大的即席查询功能，用于交互式分析，高可用性，但不支持嵌套的数据结构，多值属性。 基于存储的定价使我们限制了我们在此处放置的数据量。” +* 作业状态信息可通过简单查询获得 +* 备份作业本身（包括文件）可以通过查询检索和删除 +* 复制到异地位置实际上是立即的 +* 分片可能 +* 借助 EBS 卷，通过快照进行 MongoDB 备份（元数据和实际备份数据）既简单又无限 +* 自动化状态监控很容易 -## **Etsy 如何处理数据** +## 通过 LogicMonitor 进行监控 -再举一个例子，我们联系了 [Etsy 的](http://www.hakkalabs.co/companies/etsy)数据团队的工程经理 Rafe Colburn，并询问他们如何处理他们的管道。 这是 Rafe 的独家新闻： +LogicMonitor 认为，从物理级别到应用程序级别的基础架构的所有方面都应位于同一监视系统中：UPS，机箱温度，OS 统计信息，数据库统计信息，负载平衡器，缓存层，JMX 统计信息，磁盘 写入延迟等）。所有都应该存在，其中包括备份。 为此，LogicMonitor 不仅可以监视 MongoDB 的常规统计信息和运行状况，还可以对 MongoDB 执行任意查询。 这些查询可以查询任何内容，从登录静态信息到页面视图，再到最后一个小时内完成的（猜测是什么？）备份作业。 -> Etsy 的分析渠道不是特别线性。 它从我们的工具开始，它由一个事件记录器组成，该事件记录器在浏览器中运行，而另一个事件记录器可以从后端调用。 两者都 ping 一些内部“信标”服务器。 -> -> 实际上，我们使用良好的旧 logrotate 程序将生成的 Apache 访问日志在达到一定大小时运送到 HDFS，并使用 Hadoop 处理它们。 我们还将每晚对生产数据（驻留在 MySQL 中）进行快照，并将其复制到 HDFS 中，以便我们可以将点击流数据添加到事务数据中。 -> -> 通常，我们会将 Hadoop 作业的输出发送到 Vertica 数据仓库，在该仓库中我们也复制生产数据，以进行进一步分析。 我们使用这些数据来提供我们自己的报告和分析工具。 -> -> 对于 [etsy.com](http://etsy.com/) 上使用从 Hadoop 作业生成的数据的功能，我们有一个自定义工具，该工具获取作业的输出并将其存储在分片的 MySQL 集群中，可以在该集群上进行大规模访问。 今年，我们正在考虑将 Kafka 集成到管道中，以将数据从我们的工具移至 Hadoop（以及流分析工具），并将数据从我们的分析平台发送回公共站点。 +Now that our backups are all done via MongoDB, I  can keep track of (and more importantly, be alerted on): -## **Square 的方法** +* 每台服务器运行的备份作业数 +* 所有服务器之间同时执行的备份数 +* 任何未备份超过 6 个小时的客户门户 +* MongoDB 复制滞后 -拥有复杂数据管道的公司的另一个示例是 [Square](http://www.hakkalabs.co/companies/square) 。 我们与他们的工程经理之一 [Pascal-Louis Perez](http://www.hakkalabs.co/engineers/pascal-louis-perez) 取得了联系，他们为我们提供了他们的管道架构的战略视图。 +### 复制滞后 -由于支付在整个系统中的重要性，Square 已在整个数据管道中扩展了“对帐”的概念； 每个转换数据必须能够被审核和验证。 据 Pascal 称，这种方法的主要问题在于扩展规模可能具有挑战性。 对于收到的每笔付款，“大约需要 10 到 15 个会计分录，对帐系统的规模因此必须比处理的帐目规模大一个数量级，而处理的帐目已经非常大。” +![](img/5a3a770e6603b39a268e7856bbd86972.png) -Square 解决此问题的方法利用流处理，这使他们可以将相应的数据域映射到不同的流。 用 Pascal 的话来说，“流表示将数据流水线与数据源的多样性区分开的第一层抽象。下一层是将多个流之一组合在一起并产生一个或多个流的运算符。一个示例运算符是” “匹配器”，它接收两个流，从中提取相似种类的密钥，并根据匹配条件产生两个流。 +### 工作完成 -Pascal 指出，流处理和基于流的运算符的系统类似于关系代数及其运算符，但是在这种情况下，它是实时的并且具有无限关系。 +![](img/501c0f8d17f23d06dd79c7855378d1ad.png) -很明显，将数据塞入 Hadoop 并不会为您提供这些功能！ - -有趣的例子特别时髦。 在前端，您会看到艺术家和手工艺人像在线公开市场一样出售其商品。 可以很好地了解后端的工作方式。 - -这是一个非常有用的技术概述，它对我来说是个新名词-数据管道如何工作。 我最近一直在使用 [TitanDB](http://thinkaurelius.github.io/titan/ "TitanDB") 和 hbase 来处理图形方面，您可以在此处阅读[，尽管它不是真实的示例。](http://tjadclark.com/blog/article/11-big-data-putting-it-in-a-graph "Big data in a graph") - -看到在现实世界中有使用 HBase 的用例，这使我对将来使用 HBase 的决策更有信心。 \ No newline at end of file +您是否正在使用保险丝访问 GridFS，或者是否正在根据 API 编写所有代码？ \ No newline at end of file diff --git a/docs/11.md b/docs/11.md index eeb3ce0..3f96c66 100644 --- a/docs/11.md +++ b/docs/11.md @@ -1,530 +1,211 @@ -# Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题 +# 亚马逊建筑 -> 原文： [http://highscalability.com/blog/2017/3/15/architecture-of-probot-my-slack-and-messenger-bot-for-answer.html](http://highscalability.com/blog/2017/3/15/architecture-of-probot-my-slack-and-messenger-bot-for-answer.html) +> 原文： [http://highscalability.com/blog/2007/9/18/amazon-architecture.html](http://highscalability.com/blog/2007/9/18/amazon-architecture.html) -![](img/7217d552460750f7e349311ee16c6eb1.png) +*这是基于乔亚希姆·罗德（Joachim Rohde）对亚马逊 CTO 采访的发现而提供的非常有用的亚马逊更新。 您将了解 Amazon 如何围绕服务组织团队，构建可扩展系统的 CAP 定理，他们如何部署软件等等。 还包括了“ ACM 队列”文章中的许多新功能。* -我编写了一个东西。 称为 [Probot](https://probot.us/) 。 Probot 是一种快速简便的方法，可为您的会计和税务问题提供高质量的答案。 Probot 将找到一位真正的现场专家来回答您的问题并处理所有细节。 您可以通过 Facebook Messenger，Slack 或 Web 回答问题。 答案最低为 10 美元。 那就是球场。 +亚马逊从一个很小的在线书店发展成为地球上最大的商店之一。 他们做到了这一点，同时开创了对产品进行评分，评论和推荐的有趣新方法。 格雷格·林登（Greg Linden）在一系列博客文章中分享的是 Amazon 的出生困境 -在这种新的机器人时代似乎很自然，不是吗？ 我还是这么想。 没有那么多（到目前为止），但是稍后会更多。 +网站：http：//amazon.com -我认为 Probot 足够有趣，因为它是一个程序员（我）如何利用当今的基础架构可以完成很多工作的一个很好的例子。 +## 信息来源 -实际上，所有这些新颖的云/无服务器/服务内容都可以正常工作。 我能够以相对可扩展，可用和负担得起的方式对跨越 Messenger，Slack 和 Web 的系统进行编程，同时只需最少的开发。 +* [早期亚马逊作家，格雷格·林登](http://glinden.blogspot.com/2006/05/early-amazon-end.html)* [Linux 如何为 Amazon 节省了数百万美元](http://news.com.com/2100-1001-275155.html)* [专访 Werner Vogels](http://www.se-radio.net/index.php?post_id=157593) -亚马逊的 CTO* 异步体系结构-Chris Loosley 的 Werner Vogels 演讲的精彩[摘要](http://www.webperformancematters.com/journal/2007/8/21/asynchronous-architectures-4.html)* [向亚马逊技术平台学习](http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388)-与 Werner Vogels 的对话* [Werner Vogels 的 Weblog](http://www.allthingsdistributed.com) -构建可扩展且强大的分布式系统 -过去，担心 VPS 限制，开车前往 Colo 网站检查有问题的服务器，甚至担心容器/虚拟机集群自动扩展的日子已经一去不复返了。 至少对于许多用例而言。 + ## 平台 -多年的编程经验和撰写此博客无法避免犯错误。 在此过程中，我犯了很多愚蠢的愚蠢错误，但我对最终的想法感到满意。 + * 的 Linux* 甲骨文* C ++* 佩尔* 石匠* 爪哇* 博斯* Servlets -这是 Probot 的工作方式。... + ## 统计资料 -## 平台 + * 超过 5500 万活跃客户帐户。* 全球超过 100 万活跃零售合作伙伴。* 访问 100-150 之间的服务以构建页面。 -* 无服务器：AWS Lambda + ## 架构 -* Web 主机：S3 上的静态站点，单页应用程序 + * 我们对可伸缩性的真正含义是什么？ 如果我们在系统中增加资源时以与添加资源成比例的方式提高性能，则该服务被称为可伸缩的。 通常，提高性能意味着要服务更多的工作单元，但是也可以处理更大的工作单元，例如数据集增长时。 -* 语言：Javascript /节点 + * 亚马逊所做的重大体系结构更改是从两层的整体架构转变为可服务于许多不同应用程序的完全分布式，去中心化的服务平台。* 作为一个与后端通信的应用程序启动。 用 C ++编写。* 它成长了。 多年来，亚马逊的扩展工作一直致力于使后端数据库进行扩展，以容纳更多物品，更多客户，更多订单并支持多个国际站点。 在 2001 年，很明显前端应用程序无法再扩展。 数据库被分成几个小部分，并围绕每个部分创建了一个服务接口，这是访问数据的唯一方法。* 数据库成为共享资源，这使得很难扩展整个业务。 前端和后端流程的发展受到限制，因为它们被许多不同的团队和流程共享。* 它们的体系结构是松散耦合的，并围绕服务构建。 面向服务的体系结构为他们提供了隔离，使他们可以快速，独立地构建许多软件组件。* 聚集了数百个服务和大量应用程序服务器，这些服务服务器汇总了来自服务的信息。 呈现 Amazon.com 网页的应用程序就是这样一种应用程序服务器。 服务 Web 服务接口的应用程序，客户服务应用程序和卖方接口也是如此。* 许多第三方技术很难扩展到亚马逊的规模。 特别是通讯基础设施技术。 它们会在一定规模下正常工作，然后失败。 因此，他们被迫建立自己的。* 不拘泥于一种特定的方法。 在某些地方，他们使用 jboss / java，但仅使用 servlet，而不使用 J2EE 堆栈的其余部分。* C ++用于处理请求。 Perl / Mason 用于构建内容。* 亚马逊不喜欢中间件，因为中间件往往是框架而不是工具。 如果您使用中间件软件包，则会锁定他们选择的软件模式。 您将只能使用他们的软件。 因此，如果您想使用其他软件包，则将无法使用。 你被困住了。 一个事件循环，用于消息传递，数据持久性， + AJAX 等。太复杂了。 如果中间件可以在较小的组件中使用，而更多的是作为工具而不是框架使用，那么他们会更感兴趣。* SOAP Web 堆栈似乎想再次解决所有相同的分布式系统问题。* 同时提供 SOAP 和 REST Web 服务。 30％使用 SOAP。 这些通常是 Java 和.NET 用户，并使用 WSDL 文件生成远程对象接口。 70％的人使用 REST。 这些往往是 PHP 或 PERL 用户。* 在 SOAP 或 REST 中，开发人员都可以获取到 Amazon 的对象接口。 开发人员只想完成工作。 他们不在乎导线上的内容。* 亚马逊希望围绕他们的服务建立一个开放的社区。 选择 Web 服务是因为它很简单。 但是帽子只在外围。 在内部，它是一种面向服务的体系结构。 您只能通过界面访问数据。 WSDL 中对此进行了描述，但是它们使用了自己的封装和传输机制。* 团队很小，并且围绕服务 + 进行组织-服务是在 Amazon 内部提供功能的独立单位。 这也是亚马逊在团队内部进行组织的方式。 + -如果您有一个新的业务构想或问题，您想组成一个团队来解决。 由于沟通困难，团队人数不得超过 8-10 人。 他们被称为两个披萨队。 您可以养活两个比萨饼的人数。 + -团队很小。 他们被授予权限并有权以他们认为合适的方式解决问题，即服务。 + -例如，他们创建了一个小组，以在书中查找文本唯一的短语。 该团队为此功能构建了一个单独的服务接口，他们有权执行所需的操作。 + -广泛的 A / B 测试用于集成新服务。 他们看到了影响并进行了广泛的测量。* 部署 + -他们创建用于管理依赖关系和进行部署的特殊基础结构。 + -目标是将所有合适的服务部署在一个盒子上。 所有应用程序代码，监视，许可等都应放在包装盒中。 + -每个人都有一个解决这些问题的本地系统。 + -部署过程的输出是虚拟机。 您可以使用 EC2 来运行它们。* 从客户后方进行工作以验证是否值得进行一项新服务 + -从客户后方进行工作。 专注于您想要为客户交付 + 的价值。 + -迫使开发人员专注于交付给客户的价值，而不是先构建技术然后再去思考如何使用它。 + -从新闻稿开始，介绍用户将看到的功能并向后工作以检查您是否正在构建有价值的东西。 + -最终以尽可能最小的设计完成。 如果您确实要构建大型分布式系统，那么简单是关键。* 状态管理是大规模系统 + 的核心问题-内部，它们可以提供无限的存储空间。 + -并不是所有的操作都是有状态的。 结帐步骤是有状态的。 + -最近点击的网页服务具有基于会话 ID 的建议。 + -无论如何，他们都会跟踪所有事情，因此保持状态无关紧要。 会话几乎不需要保留单独的状态。 服务将已经保留了信息，因此您只需要使用服务即可。* Eric Brewer 的 CAP 定理或系统的三个属性 + -系统的三个属性：一致性，可用性，对网络分区的容忍度。 + -对于任何共享数据系统，这三个属性中最多可以有两个。 + -可分区性：将节点分为几个小组，可以看到其他小组，但看不到所有人。 + -一致性：写入一个值，然后读取该值，您将获得相同的值。 在分区系统中，存在不正确的窗口。 + -可用性：可能并不总是能够写入或读取。 系统会说您不能写，因为它想保持系统的一致性。 + -要扩展，您必须进行分区，因此您只能为特定系统选择高一致性或高可用性。 您必须找到可用性和一致性的正确重叠。 + -根据服务需求选择特定的方法。 + -对于结帐流程，您始终希望兑现将商品添加到购物车的请求，因为它可以产生收益。 在这种情况下，您选择高可用性。 对客户隐藏错误，并在以后进行分类。 + -当客户提交订单时，您希望保持一致性，因为多项服务（信用卡处理，运输和处理，报告）正在同时访问数据。 -* API：API 网关 + ## 得到教训 -* DNS：Route53 + * 您必须改变思路，才能构建真正可扩展的系统。 以概率的方式处理混乱，事情会顺利进行。 在传统系统中，我们提供了一个完美的世界，在这个完美的世界上一切都没有失败，然后我们在这个完美的世界上构建了复杂的算法（协议技术）。 相反，将其视为理所当然的东西会失败，这是 + 现实，请接受它。 例如，使用快速重启和快速恢复方法进行更多操作。 随着数据和服务的良好传播，您可能会接近 100％。 创建自我修复，自我组织的熄灯操作。 -* CDN：CloudFront + * 创建一个没有共享的基础架构。 基础架构可以成为开发和部署的共享资源，其缺点与逻辑层和数据层中的共享资源相同。 它可能导致锁定和阻塞以及死锁。 面向服务的体系结构允许创建并行且隔离的开发流程，以扩展功能开发以适应您的增长。 -* 用户登录名： [Cognito](https://github.com/aws/amazon-cognito-identity-js) + * 使用 API​​打开系统，您将在应用程序周围创建一个生态系统。 -* SSL 证书：让我们加密 + * 管理大型分布式系统的唯一方法是使事情尽可能简单。 通过确保设计中没有隐藏的需求和隐藏的依赖关系，使事情变得简单。 将技术减少到解决您所遇到的问题所需的最低限度。 这无助于公司创建人为的和不必要的复杂性层。 -* 服务器：EC2，t2.small，Ubuntu + * 围绕服务进行组织可提供敏捷性。 您可以并行执行的操作是因为输出是服务。 这样可以加快上市时间。 创建一个基础结构，以允许快速构建服务。 -* 信息库：GitHub + * 在实际实现之前，任何会引起炒作的问题都存在问题 -* 源代码控制：Git + * 在内部使用 SLA 来管理服务。 -* 付款：贝宝 + * 任何人都可以非常快速地将 Web 服务添加到其产品中。 只需将产品的一部分作为服务实施并开始使用即可。 -* Slackbot： [Botkit](https://github.com/howdyai/botkit) + * 出于性能，可靠性和成本控制的原因，构建自己的基础架构。 通过自己构建它，您不必说您倒闭，因为这是 X 公司的错。 您的软件可能不比其他软件更可靠，但是与第三者合作时，您可以更快地进行修复，调试和部署。 -* 队列：SQS + * 用度量和客观辩论将好与坏分开。 我去过前亚马逊的几场演讲，而这正是亚马逊给我的印象，与其他公司截然不同。 他们根深蒂固的道德操守是让真正的客户有选择的余地，看看哪个最有效，并根据这些测试做出决策。 -* 备份：AWS Data Pipeline，每周将生产数据保存到 S3 + [Avinash Kaushik](http://highscalability.com/blog-occam-s-razor-avinash-kaushik) 称这摆脱了 HiPPO（房间中收入最高的人）的影响。 这是通过 A / B 测试和 Web Analytics 等技术完成的。 如果您对应该如何编写代码有疑问，请让人们使用它，然后看看哪种选择可以为您提供所需的结果。 -* 数据库：DynamoDB + * 营造节俭文化。 例如，亚马逊使用书桌门。 -* 节点进程管理器： [PM2](http://pm2.keymetrics.io/) + * 知道你需要什么。 亚马逊在一个早期的推荐系统上经历了糟糕的经历，但并没有奏效：“这不是亚马逊所需要的。在亚马逊上进行书推荐需要使用稀疏数据，只需进行几次评级或购买即可。它必须要快。 该系统需要扩展到大量的客户和庞大的目录，还需要增强发现能力，使目录中深处的书籍无法被读者自己找到。” -* SSL 终止：Nginx + * 人们感兴趣的旁人项目通常是您获得最大价值和创新的项目。 永远不要低估您最感兴趣的地方徘徊的力量。 -* Web 框架：jQuery，Bootstrap + * 让每个人都参与制作狗粮。 在圣诞节高峰期间，请进仓库并整理书籍。 那是团队合作。 -* 开发平台：MacBook Air + * 创建一个登台站点，在发布到野外之前，您可以在其中进行全面的测试。 -* 本地测试 Web 服务器： [http 服务器](https://www.npmjs.com/package/http-server) + * 一个健壮的，集群的，复制的，分布式文件系统非常适合 Web 服务器使用的只读数据。 -* 测试隧道： [Ngrok](https://ngrok.com/) + * 如果更新不起作用，有一种方法可以回滚。 如有必要，编写工具。 -* SQS 轮询： [平方英尺消费者](https://www.npmjs.com/package/sqs-consumer) + * 切换到基于深度服务的体系结构（http://webservices.sys-con.com/read/262024.htm）。 -* 日志记录：CloudWatch + * 在面试中寻找三件事：热情，创造力，能力。 对 Amazon.com 成功的最大预测是热情。 -## 起源故事 + * 雇用鲍勃。 知道他们的东西，拥有令人难以置信的调试技能和系统知识的人，最重要的是，他们拥有一头石头就能解决仅凭跳进就可以想象到的最严重的高压问题。* 创新只能来自底层。 那些最接近问题的人最有可能解决问题。 任何依赖创新的组织都必须拥抱混乱。 忠诚和服从不是您的工具。 -我的妻子 [琳达·科尔曼](http://www.possibility.com/Lgc/AcctRes.html) 是一名注册代理，这意味着她是一位了不起的税务会计师，并且在会计专家中都很有经验。 她有一个网站 [BizTaxTalk](http://biztaxtalk.com/) ，在这里她为人们的税收问题提供了很好的答案：免费。 她有很多问题。 有真正问题的人需要帮助，很难找到可以回答这类问题的人。 + * 创意必须无处不在。 -您可能会想像它变得势不可挡。 她最终不得不放弃 BizTaxTalk，因为它占用了她太多的时间。 + * 每个人都必须能够进行实验，学习和迭代。 职位，服从和传统不应该拥有任何权力。 为了使创新蓬勃发展，必须衡量。 -我想为什么不通过它获利？ 琳达可以回答人们的问题并获得报酬。 双赢。 我知道这种类型的质量检查网站不是新手，但机器人程序是解决该问题的新方式，应该是处理此类信息交换的一种很好的方式。 使用文本可以非常方便地异步处理问答流程。 + * 拥抱创新。 在整个公司的面前，杰夫·贝佐斯（Jeff Bezos）会将一双耐克旧鞋授予“勇于创新”的人，以表彰他们的创新精神。 -因此，Probot 建立了一个双面市场。 有问题的用户（例如约会服务）与能够回答其问题的主题专家（称为 Pro）相匹配。 Probot 处理消息的匹配，计费和协调。 + * 不要为性能付出代价。 给予良好的待遇和高薪，但保持平稳。 以其他方式认可出色的工作。 绩效工资听起来不错，但是在大型组织中几乎不可能做到。 使用非金钱奖励，例如旧鞋子。 这是说谢谢的方式，有人在乎。 -尽管我显然会从税务和会计问题入手，但最终可以吸引更多的主题专家，并且话题数量也有所增加。 这就是我编写代码的方式。 它可以轻松扩展以处理新主题和问题树。 + * 快速变大。 像巴恩斯（Barnes）和诺贝尔（Nobel）这样的大人物在你的尾巴上。 亚马逊甚至不是网络上的第一，第二，甚至第三本书店，但最终他们的愿景和驱动力胜出了。 -这就是我要建立的。 + * 在数据中心，只有 30％的员工时间花费在与价值创造相关的基础架构问题上，其余 70％专门用于应对硬件采购，软件管理，负载平衡，维护，可扩展性挑战以及 以此类推。 -## 架构 + * 禁止客户端直接访问数据库。 这意味着您可以在不涉及客户的情况下扩大服务范围并提高可靠性。 这很像 Google 能够独立地在其堆栈中分发改进以使所有应用程序受益的能力。 -*继续阅读* 。 这是一遍又一遍的 HS 建议。 那就是我所做的。 我有在 Node 上使用最出色的 [Botkit](https://github.com/howdyai/botkit) 制作 Slackbots 的经验，因此我就从这里开始。 + * 创建一个统一的服务访问机制。 这使得服务易于聚合，分散请求路由，分布式请求跟踪以及其他高级基础结构技术。 -我也有使用 AWS Lambda 来开发 Alexa 技能的经验，并且不想管理任何东西-玩系统管理员多年就足够了-所以我选择了 AWS。 如果 Google Cloud Functions 是 GA，那么我可能会选择使用 Google Cloud。 + * 通过 Web 服务接口向世界上任何开发人员免费提供 Amazon.com 也是一项重大成功，因为它推动了许多创新，他们无法想到或自己建立。 -以下是我们将介绍的所有主题： + * 开发人员自己最清楚哪些工具使它们最高效，哪些工具最适合工作。 -* ProbotService Lambda 函数 + * 不要对工程师施加太多限制。 为某些事情提供激励，例如与监视系统和其他基础结构工具集成。 但对于其余部分，允许团队尽可能独立地运作。 -* Slackbot + * 开发人员就像艺术家。 只要有自由，他们就可以发挥出自己最好的作品，但是他们需要好的工具。 有许多具有自助性质的支持工具。 为服务开发周围的环境提供支持，而该环境永远不会妨碍开发本身。 -* Messengerbot + * 您构建它，然后运行它。 这使开发人员可以接触到他们软件的日常操作。 它还使他们与客户进行日常联系。 客户反馈回路对于提高服务质量至关重要。 -* 网站 + * 开发人员应每两年花一些时间在客户服务上。 他们实际上将收听客户服务电话，接听客户服务电子邮件，并真正了解他们作为技术人员所做的各种事情的影响。 -* PayPal 集成 + * 使用“客户的声音”，这是客户关于您网站体验的某些特定部分的真实故事。 这可以帮助经理和工程师了解我们为实际人员构建这些技术的事实。 如果您做错了什么或对客户而言真正的痛点是什么，则客户服务统计数据可以作为早期指示。 -* 测试 + * 像 Google 一样，Amazon 的基础设施具有巨大的竞争优势。 他们可以利用相对简单的原始服务来构建非常复杂的应用程序。 他们可以独立扩展业务规模，保持无与伦比的系统可用性，并快速引入新服务，而无需进行大量重新配置。 -* 采纳 +亚马逊的首席技术官沃纳·沃格斯（Werner Vogels）谈到了 SE-Radio 的技术细节。 您可以在[下找到播客，网址为 http://www.se-radio.net/index.php?post_id=157593](http://www.se-radio.net/index.php?post_id=157593) +有趣的一集。 -* 获得的经验教训 +那是一次很好的采访。 谢谢。 我将尽快添加新信息。 -## ProbotService Lambda 函数 +亚马逊使用 Perl 和 Mason。 +请参阅： [http://www.masonhq.com/?MasonPoweredSites](http://www.masonhq.com/?MasonPoweredSites) -这是实现 Probot Service 后端的 AWS Lambda 函数。 大多。 这也是我许多愚蠢错误的根源。 让我解释。 +如我所见，他们减少了 c ++部分并转移到 j2ee？ -我为 Slack 编写的第一个 Probot 机器人用于 Slack，并且取得了一些进步，但是 Slackbot 在 EC2 实例上的 Ubuntu 进程中运行。 +除非您是经理，否则我不确定您怎么能弄错那个错误，但是即使那样，某些工程师还是会在星期日之前教您。 -我犯的一个大错误是不首先使用 API​​。 我的大部分职业都是建立另一种消息协议。 是我做的吗？ 当然不是。 +感谢您抓住这一点。 我听了几次，有时我只是写我听到的内容，而不是我的意思。 -我对所有机器人逻辑进行了编程，因此可以直接在 Slackbot 流程中执行。 这是可能的，因为 AWS 具有用于访问 DynamoDB，SQS，Lambda 和其他 AWS 服务的漂亮 Node API。 因此，所有 AWS 访问都直接用 javascript 编码。 效果很好。 没问题 +我实际上在以下位置给出了可扩展性的详细定义： [http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html“](有关可扩展性的信息 -当我需要制作 Web 客户端时出现了问题。 嗯，在相同的代码也几乎可以在 Web 客户端中正常工作的意义上，这并不是问题。 真酷。 因此，我浪费了很多时间来建立 Slack 和 Web 客户端可以共享的通用库。 但是我对我的数据库访问代码可以在 Web 上看到的想法感到非常不舒服。 对于 Intranet 服务，我不会担心，但按我的喜好显示数据结构的攻击面太大了。 +我个人喜欢 [http://www.acmqueue.com/modules.php?name=内容& pa =显示页& pid = 388“]( ACM Queue 中的采访最适合 高层视野 -我犯的另一个大错误，也与不首先创建 API 有关，是因为对 DynamoDB 在数据库更改时将新值和旧值传递给 Lambda 函数的能力深感兴趣。 我所做的是像状态机一样触发逻辑。 例如，如果旧记录说状态为 PENDING，而新状态为 ASSIGNED，则触发 PENDING 到 ASSIGNED 的转换。 它有效，我认为它真的很聪明。 问题在于面对许多无法移动状态但仍触发 Lambda 函数的操作，它过于脆弱。 +-维尔纳 -解决这两个问题的方法是构建一个 API，我使用 Lambda 做到了。 我选择不使用 API​​ Gateway，因为直接从 Node 调用 Lambda 函数非常容易。 API 网关增加了延迟，复杂性和成本。 也很难使用。 从 HTTP 请求转换参数并将其映射到 Lambda 调用对于任何复杂的事情来说都是非常接近魔术的过程。 回复相同（反方向）。 如果将来需要使用公共 API，则可以重新考虑此决定，但是直接使用 Lambda 是非常简单的方法。 必须更改所有 Slack 和 Web 代码才能使用新的 API。 真痛苦 +似乎他们使用 Java 来完成通常用 Perl 完成的工作。 -### 如何构建无服务器 API？ +>使用非货币奖励，例如旧鞋。 这是 +>说谢谢的一种方式，有人在乎。 -下一个决定是如何构建 API？ 每个 API 调用都映射到一个单独的函数吗？ 还是将功能归为一个入口？ 还是可能有多个入口点？ +有一次我愚蠢到参加亚马逊全公司会议，而不是将其视为免费的入睡日，我看到贝索斯给了一个男人一双鞋子。 -我选择了一个入口点。 之所以采用这种方法，是因为我不想使用框架来管理 Lambda。 我想知道所有东西如何连接在一起，框架包含很多魔术。 因此，我创建了一个 zip 文件，并使用 AWS 控制台将其上传到 Production 或 Test。 将来，我将使其自动化，但现在可以正常使用。 +我当时想：“这个家伙造了宇宙飞船，他把臭旧的网球鞋给高成就者？他们不喜欢打他吗？自尊心在哪里？” -使用单个入口点时的一个问题是如何复用函数调用？ 我选择模仿 [JSON-RPC](http://www.jsonrpc.org/specification) ，这些在过去我已成功用于服务器应用程序。 +但是我想这就是为什么我是前亚马逊人的原因。 当我放弃他们时，薪水提高了 20％，而且没有传呼机职责。 见，杰夫。 -请求包装在 JSON-RPC 负载中。 使用“ method”属性指定要调用的方法，并使用“ params”属性传递任何参数。 ProbotService index.js 文件解压缩 JSON-RPC 请求并调用正确的方法。 看起来像： +这是我一段时间以来最愚蠢的读物之一。 一家聪明的公司为什么会花钱在员工的“奖励”上，这对除了您从中获得奖励的人以外的任何人都没有帮助？ 当亚马逊表现出色时，他们就会获得真正的高成就，而且股价在 90 美元左右，我知道他们的感觉还不错。 我的猜测是他们想拥抱杰夫。 -> 如果（request.method ===“ giveAnswerToUser”）{ -> -> var op = new QuestionImpl（appcfg）; -> -> op.giveAnswerToUser（request.params，function（error，data）{ -> -> 返回 sendResponse（错误，数据，请求，回调）； -> -> }） -> -> } +成就不佳的人很可能会对此表示不满，然后去其他地方，他们在亚马逊工作的事实很可能有助于这项工作，就像我确定的那样。 而且，看来您离开并没有对亚马逊造成太大的伤害:) -我以标准的 RPC 方式创建了一个名为 ProbotService 的存根对象，该对象使从客户端代码调用 Lambda 函数变得更加容易。 例如： *service.getQuestion（id，callback）*格式化正确的 JSON-RPC 结构，调用正确的 Lambda 函数，并在返回回复时调用回调。 +以前的 Nikies 面向成就卓越的人的事情听起来像是给 IBM 员工的（愚蠢的）文凭。如果您真的想感谢一个成就卓越的人，请给他们加薪或奖金，或者..不愿意参加巡航。 便秘的旧鞋子..多么可爱:)） -### 共享代码 +>而且，看来您离开并未对亚马逊造成太大的伤害:) -我选择不在 Facebook Messenger 机器人代码中调用 ProbotService Lambda。 而是，服务库代码与 Messenger 代码打包在一起并直接调用。 这是一种代码共享方法。 在 ProbotService 和 Facebook Messenger 之间共享相同的基础代码。 +哦，我敢肯定，没有我，amzn 很好。 但是亚马逊员工的半衰期约为 18 个月，所以认为在那工作很糟糕的不只是我。 想一想，如果不必每 18 个月更换一半的员工，amzn 的运营效率就会提高多少。 我确信这将对其股价产生影响。 :) -原因是 Facebook Messenger Webhook 调用通过 API 网关调用，该 API 网关调用 Lambda 函数。 使用 ProbotService 还会调用 Lambda 函数。 因此，将在另一个 Lambda 函数中调用 Lambda 函数。 这可以正常工作，但是最坏的情况下的延迟比我希望用户体验到的要高，因此我选择通过共享代码来删除跃点。 我仍然不确定这是否是最好的决定，但是它确实有效，并且 Messenger 机器人的响应时间让人感觉很快。 +>如果公司 +>表现不错，并且股票价格在 90 美元左右，亚马逊的真正成就就会得到回报，我知道他们对 +>感觉很好。 我的猜测是他们想拥抱杰夫。 -由于 Slackbot 在自己的进程中运行，因此没有多余的跃点，因此使用 ProbotService 是正确的选择。 Web 客户端代码中也使用了 ProbotService，因此不会泄漏任何内部详细信息。 +当然，现在股价飞涨，我为那里的人感到高兴，他们为此赚了很多钱。 但是 amzn 按照市场标准支付工资，并依靠股票来提高工资。 我对你的薪水赌博并不酷。 -### ProbotService API +算上我过去几年的全部收入...如果我的所有 amzn 赠款都以每笔$ 90 支付，如果我呆在那里，我可能会多赚$ 15-25K。 但是，2.5 万美元的保费（或每年 625 万美元，因为需要花费 4 年的归属时间）并不足以让我进入亚马逊，考虑到要换取这笔保费，我需要工作 10- 每周多 30 小时。 我认为基于权益的补偿是针对傻瓜的。 用权益补偿来换取巨大的每周工作量需求是……更大的吸盘。 -以下是 Probot API 中的一些功能。 我不会使用 Swagger 之类的文档。 +我目前的公司为我提供了真正的现金红利和额外的带薪休假，以使他们表现良好。 我要把它接在笨拙的旧鞋子上！ 钱用来说话； 像 bulsh * t 这样的鞋子，是用来走路的。 -* updateFromPaypalWebhook +作为对您的文章的深入研究的副作用，我将其翻译为德语： [http://habacht.blogspot.com/2007/10/amazon-architecture.html](http://habacht.blogspot.com/2007/10/amazon-architecture.html) -* getQuestion +为什么？ perl 是用于文本处理的常用工具：） java 不仅限于 perl -* GiveAnswerToUser +由于谦虚，我倾向于说 Java 并不适合所有传统的业务术语。 效率，投资回报。 我今天经营一家公司，并且相信我，从长远来看，Java 并不是设计大型&关键应用程序的最终选择。 只有伪专家和伪 IT 经理才将 Java 视为明天编程问题的第一个答案。 我建议您检查 J2EE 后面的语言/框架环境。 以 Perl 6 为例。 我在开玩笑 ？ 并不是的。 我们的最后一个 Web 服务完全使用 Perl 和 Ruby 中的接口进行了完全设计。 开明的用户想知道它是否是 struts + hibernate + weblogic + oracle（可能带有 SAP R / 3 连接器）。 现在的现实已经大不相同：我们必须考虑纯粹的业务。 Java 的？ 好的，我今天将检查 Sun 的博客。 我也爱 Java。 -* GiveAnswerToPro +真的很有趣，喜欢阅读。 但是，我觉得如果您真的想感谢一个成就卓越的人，请给他们加薪或奖金！ 那就是我最欣赏的，毕竟我们是为了钱而工作。 -* askQuestionOfUser +大部分内容非常有用（特别是我同意的部分；） -* cancelQuestion +梅森对我来说是新的！ 非常好的帖子。 [http://evandro.net/“]( Evandro [http://www.poker73.com/”](坐下&转到 -* acceptProAnswer +Very informative for the most part (specially the parts I agree with ;) -## Slackbot +您能否解释一下“ DOM”的含义 -![](img/40070da02aed39af548489071241ab44.png) +那是一篇关于亚马逊建筑大师的好书。 在下周对亚马逊的采访中肯定会有所帮助。 -### 机器人样式 +亚马逊是一家伟大的公司。 真的启发了我。 [http://www.csscatwalk.com“]( CSS 画廊 -对机器人进行编程时，您必须做出的决定之一是：您要使用对话式 AI 风格机器人还是结构化命令驱动风格机器人。 +谢谢！ -我采用了结构化的命令驱动方法。 用户选择一个问题主题，然后漫游器会引导他们通过问题树收集 Pro 回答此类问题所需的数据。 例如，对于纳税申报表，您需要知道它是哪一年，是个人还是公司，是否是公司的实体类型（合伙企业，C-Corp 等），等等。 +非常感谢您提供如此详细的信息。 它无疑帮助我了解了有关构建可扩展网站的更多事实。 -AI 风格很性感，但如果那不是您的事，那么做起来真的很难。 因此，我想出了一种与用户进行对话的方式，可以针对每个问题进行自定义。 实际上，我提出了几种不同的对话描述符解决方案，但我对其中任何一个都不满意。 这是 Slack 的样子： +That was a nice read about amazon architecutre. Would definitely help during the interview with amazon next week. -> probot.machine.add（“ ask-return-type”，{ -> -> 操作：probot.machine.askFromOptions， -> -> 选项：[“个人”，“业务”]， -> -> 显示：[“个人”，“业务”]， -> -> 问题：“在回答税收问题时，帮助您的专家了解报税种类会很有帮助。”， -> -> sayOnAccept：“知道了。您选择了 _ {response} _ 选项。”， -> -> 答案：功能（机器，cmd，答案，下一个）{ -> -> console.log（“ ask-return-type：answer：” + answer）; -> -> probot.dto.setReturnType（answer）; -> -> if（answer ===“ individual”） -> -> 的 cmd.next =“询问税年”； -> -> 其他 -> -> cmd.next =“询问实体类型”; -> -> next（null）; -> -> }， -> ->    }) - -我对 Messenger 采取了完全不同的方向。 我也很讨厌这种方式。 - -### 松弛主机 - -使用 Slack 时，webhooks 可用于实现 Slack 命令，但是对话风格要求代码在流程上下文中运行。 因此，我建立了一个没有任何冗余的小型 EC2 实例。 由于我不希望用户在 Slack 上不断与 Probot 互动，因此我认为停工时间不会造成任何伤害。 所有状态都将在 DynamoDB 中，因此不会丢失任何内容。 弹性 IP 用于访问主机。 - -*保持简单，不要使事情复杂化* 。 关于 HS 的另一个很长的课程。 如果有人最终使用您的系统，则可以稍后再做所有花哨的工作。 - -[PM2](http://pm2.keymetrics.io/) 是出色的 Node 进程管理器，用于在 Slack 进程死后重新启动它。 PM2 还管理日志并执行其他一些精美的操作。 Route53 会 ping 通该过程，并在出现任何问题时向我发送电子邮件。 够好了。 - -Botkit 完成了许多繁重的工作。 它处理程序与 Slack 之间的所有协议工作，同时为身份验证，进行对话之类的事情提供了许多方便的抽象方法。 - -### 互动消息 - -在我完全完成 Slackbot 实现之后，Slack 引入了用户使用按钮而不是输入文本来进行选择的功能。 由于我还没有发布任何东西，所以是时候进行更改了。 这些按钮确实使用户更容易。 问题是按钮需要您的进程实现 HTTPS Webhook，以便 Slack 可以通过按下哪个按钮的信息回调到您的进程中。 这是开发流程的重大变化。 松弛的开发是很好的，以前也包含在内。 现在，您的机器人程序必须可以通过 URL 从外部进行访问。 - -在 EC2 中的生产机器上还不错。 我使用 Nginx 终止 SSL，并将请求传递给 Slackbot 进程。 这需要使用我使用“加密”的 SSL 证书。 由于必须定期更新，这是维护上的麻烦，但它们是免费的，因此请选择毒药。 - -让 Slack 通过 Comcast 路由器访问在笔记本电脑上运行的进程并不容易。 我在各种解决方案上浪费了很多时间。 很多时间。 我最终屈服了，并向 Ngrok 支付了他们的隧道服务。 像魅力一样工作。 花钱。 Slack 应该考虑能够完全在无服务器上工作。 那将是一个更清洁的解决方案。 - -### 身份和验证 - -在 Probot 中，没有尝试创建 Slack，Messenger 和网络上常见的用户。 每个都使用其环境固有的身份机制。 对于 Slack，这意味着使用 Slack 分配的团队 ID 和用户 ID。 Probot 询问用户的姓名和电子邮件地址，但不打扰身份和身份验证。 Slack 处理所有这些。 - -### 数据库 - -Slack 提供了自己的数据库抽象，用于存储团队，用户和渠道。 当 Probot 使用 DynamoDB 时，我创建了一个简单的 [适配器](https://github.com/ToddHoff/botkit-storage-dynamodb) ，该适配器允许 Slack 将其数据存储在 DynamoDB 中。 - -通常的做法是在 Slack 的数据结构中插入自己的属性。 因此，用户数据存储在 Slack 的用户对象中。 - -### 从 Pro 向用户发送消息 - -与用户对话时，使用 Botkit 发送消息就像 *bot.say（“某些字符串”）* 一样容易。 在以后的某个时间以异步方式向用户发送消息并非易事。 例如，当专业人士为用户提供答案或想要提出问题时，必须向用户提供消息。 - -我可以弄清楚如何使异步消息传递起作用的唯一方法： - -* 当团队连接到 Probot 时，将 Botkit 机器人 对象存储在内存中。 需要机器人对象才能向用户发送消息。 - -* 每个用户都与一个团队相关联，因此当出现消息时，可以找到适当的机器人对象。 - -* 来自 Pro 的所有消息都排队到 AWS SQS。 - -* Slackbot 进程使用一个名为 sqs-consumer 的漂亮软件包来轮询 SQS 以获取消息。 - -* 使用 bot 对象将消息发送给用户。 - -* 用户调用@probot 进行对话以处理消息。 该消息可能是答案，问题或状态更新。 用户可以对答案进行评分并发表评论。 他们还可以拒绝答案，这意味着用户无需付费。 我不希望别人觉得自己被人扯了。 这是 Pro 承担的风险。 尽管我不这样做，但匹配算法可以在进行匹配时利用评分数据。 - -Sqs 消费者是为什么 Node 对开发人员如此高效的一个示例。 是的，javascript 很烂。 是的，回调编程有点糟。 但是从字面上来看，我需要花五分钟的时间思考*，我需要轮询 SQS* 来找到一个好的 npm 可安装软件包并拥有有效的代码。 Node 一直在发生这种情况。 - -## Messengerbot - -![](img/96ab0db0dea30355d9828a21db9dff88.png) - -Messenger 是与 Slack 完全不同的野兽。 尽管 Botkit 支持 Messenger，但我还是决定直接将代码编码到 [Messenger API](https://developers.facebook.com/docs/messenger-platform/) ，因为它比 Slack 简单得多。 那是因为作为团队协作工具，Slack 具有很多功能。 Slack 具有用于与团队，渠道，用户，组，权限，功能等配合使用的各种 API。 - -使用 Facebook Messenger 时，将通过 Webhook 接收消息，并使用 HTTP 调用发送格式化的消息。 那几乎就是您所能做的。 因此，Messenger 机器人可以完全在 Lambda 函数上运行。 如果您不关心团队的所有方面，那么 Messenger 可能是一个更好的起点。 - -回想一下，这是 和您所知道的 咬住我的地方。 Probot 不是团队工具。 它与用户进行一对一的交互，因此所有开销都没有任何好处，并且需要很长时间才能解决。 另一方面，Slack 的员工非常乐于与他们合作。 如果您有问题，那么有技术印章的真实人将为您提供一个很好的答案。 你可以想象？ - -实际上，我一直在考虑取消对 Slack 的支持，因为没有人在使用它，而且 EC2 实例每月都要花我很多钱。 无服务器可为此类工作量赢得大量时间。 使用 Lambda，我只在人们实际使用 Probot 时付款。 - -### 简化 Messenger - -一件事立即变得很清楚，那就是必须简化 Probot 才能在 Messenger 上正常工作。 使用 Slack 时，复杂的用户交互变得自然。 在 Messenger 上，复杂的问题树根本不起作用。 - -我所做的一个简化是减少用户可以从 Pro 请求的答案类型。 在 Slack 上，用户可以要求以不同的价格快速，完整或深入地回答问题。 添加这一额外的交互层会使整个过程陷入困境，因此，使用 Messenger 时，Pro 可以提供的唯一可能的答案类型是 Quick 类型。 - -无法将简短的文本字符串发送到 Messenger 进一步增强了对简短和简单的需求。 松弛搭配文字很棒。 您可以吐出文本页面没问题。 有了 Messenger，您可以发送的最大尺寸。 长字符串必须分成大块，而不是美观。 - -另一个简化是 Messenger 上，用户一次只能回答一个未解决的问题。 在网络和 Slack 上，用户可以一次打开多个问题。 回想起来，这可能也是我应该构建 Slack 的方式。 通过聊天界面管理多个悬而未决的问题很复杂。 - -这是关于 HS 的又一个很长的课程： 保持简单愚蠢 。 说起来容易做起来难。 - -### Facebook Messenger Webhook - -在 Messenger 机器人配置中，指定了一个 Webhook，Facebook 会使用用户相关事件进行调用。 Webhook 使用绑定到 Lambda 函数的 API 网关实现。 Lambda 函数是使用共享代码方法实现的。 它包含了所需的所有源代码，而不是调用其他服务。 - -Lambda index.js 文件中的启动代码负责解析来自 Facebook 的消息并正确分发。 在处理每个消息之前， startSession 与发送者 ID 一起调用，该 ID 被用作用户 ID。 startSession 获取用户记录（如果存在），如果不存在，则请求该用户的配置文件并创建用户记录。 如果用户记录中已有问题 ID，则会从数据库中检索该问题，并创建该问题的状态机对象。 传入消息是状态机上的一个事件，它驱动消息的处理方式。 - -使用 startSession 来处理用户消息所需的所有数据均已就绪，因此任何较低级别的代码都不必担心。 同样，在处理完一条消息后，将检查脏标志，如果对象已更改，则会在数据库中自动对其进行更新。 我发现这种风格使使用 Lambda 函数更加简洁。 较低级别的代码永远不必担心状态管理。 - -这是 Slack 比 Facebook 更具优势的领域。 Lambda 函数无法存储状态，因此必须激活每个状态并随每个请求将其钝化。 使用 Slack，状态可以存储在 Slackbot 进程中，尽管如果我要再做一次，则可能不会将状态保持在 Slack 中。 转到数据库并编辑记录并在下次请求时提取更改非常方便。 为了使这些更改在 Slackbot 中可见，必须重新启动该过程。 - -Messenger 具有许多不同类型的消息：消息，回发，身份验证，传递确认，消息读取，帐户链接等。 消息类型有几种子类型：快速答复，文本，回声，回执，已读回执，键入，键入，等等。 - -通常，我唯一要注意的消息是与用户的交互。 所有命令源均映射为通用请求格式，并馈入 Question 状态机。 例如，当用户点击“回发”按钮，“开始”按钮，“持久”菜单或“结构化消息”时，发生回发事件。 我认为来自用户的任何纯文本输入都是为了响应我之前提出的问题。 快速回复 只是用户可点击按钮的另一种类型。 - -### Facebook 问题状态机 - -所有问题都存储在 DynamoDB 中。 每个问题都有一个属性，用于指定问题所在的当前状态。将消息标准化为通用请求格式后，将其应用于“问题”状态机，该状态机看起来像： - -> var QuestionDto = require("./QuestionDto");function FacebookQuestionSm(appcfg, startState) {  console.log("FacebookQuestionSm:startState:" + startState);  this.startState = startState;  var self = this;  this.any = {    help: {      action: FacebookQuestionSm.sendHelp,    },    getstarted: {      action: FacebookQuestionSm.sendGetStarted,    },    settings: {      action: FacebookQuestionSm.sendSettings,    },    status: {      action: FacebookQuestionSm.sendStatus,    },  ...  this.states = {    start : {      on : {        accounting: {          forward: "ask_accounting_question"        },        ask_accounting_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_question",          data: { type: "accounting", msg: "Great choice, I see you want to ask an accounting question." }        },        ask_individual_tax_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_tax_year",          data: { type: "tax", returnType: "individual",                   msg: "Great choice, I see you want to ask a tax question for an individual."           }        },        ask_business_tax_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_entity_type",          data: { type: "tax", returnType: "business",             msg: "Great choice, I see you want to ask a business related tax question."           }        }      }    },    ask_tax_year : {      action: FacebookQuestionSm.sendTaxYearQuestion,      on : {        text: {          verify: FacebookQuestionSm.verifyTaxYear,          action: FacebookQuestionSm.saveTaxYear,          next: "ask_question"        }      }    }, -> ->     ... -> -> } -> -> this.on = function（appcfg，userid，request，next）{ -> -> console.log（“ on：userid：” + userid +``request：“ + JSON.stringify（request））; -> -> } - -上的 *方法接受请求并将其应用于状态定义。 这可以正常工作，但是处理用户可以与机器人进行交互的所有方式都会使代码看起来有些骇人。* - -### Identity and Authentication - -与 Slack 一样，Facebook 提供了专门用于 Messenger 的用户 ID，而我只是使用该 ID。 它不是真实的 Facebook 用户 ID，因此您不能使用 graph API 来获取大量用户信息。 该 ID 与问题一起存储，因此可以将答复直接发送给用户。 - -### Database - -Slack 的 Facebook 数据库 API 等效，因此用户数据存储在 DynamoDB 中 Facebook 特定的用户表中。 - -## 网站 - -![](img/f2c70cd017c86d78ddbcadea563ee25a.png) - -[Probot.us](https://probot.us/) 是 S3 上托管的单页应用程序。 作为单页应用程序，所有操作均使用 Slack 使用的相同 ProbotService API 完成。 使用 S3 的优点是我无需管理任何事情。 它是一个与其他网站非常相似的网站，因此我不会在此进行过多介绍，但有一些主题值得注意。 - -### 电子邮件崩溃 - -您是否曾经做过一些您最终不会做的事情，但还是成功了？ 这是另一个浪费时间的大错误。 毫无疑问，我不太擅长制作网站。 我希望这可以解释为什么我真正尝试完全避免制造一个。 - -我所做的是通过电子邮件使所有 Pro 交互工作。 问题将通过电子邮件发送给专业人士。 专业人士会通过电子邮件答复并回答问题。 电子邮件中的关键字使它可以解析和提取数据。 用户没有注意到差异，因为他们仍然会使用 Slack 或 Messenger。 - -这是流程：Probot 向 Pro 发送了电子邮件。 例如，将问题分配给专业人士时，他们将收到一封包含该问题，有关用户的信息以及一些簿记属性的电子邮件，以将电子邮件映射回该问题。 专业人士会回覆他们的回应，并确保将文字插入正确的位置，以便可以正确解析。 AWS 收到了 Pro 的回复并将其保存到 S3 中。 这导致了 Lambda 函数被调用。 该功能将解析电子邮件，提取所有数据，并相应地更新用户。 - -尽管配置很麻烦，但实际上确实有效，并且编写代码很有趣。 只有我的测试专家讨厌它。 只是讨厌它。 当然，他们做到了，这对他们来说很糟糕。 因此，我最终制作了 Pro 仪表板，以管理我一直知道自己必须解决的所有 Pro 问题。 我还添加了一个收件箱，以便用户可以在网络上提问和管理问题。 同一网站还为 Slack 用户充当着陆页，以便他们可以将 bot 安装到他们的团队中。 - -### [HTG0 BC] - -尽管我已经在 Golang 中使用了完整的用户注册系统，但我希望将所有内容保留在 Node 中。 我决定重试一下，而不是重新发明轮子。 我不想对用户密码的安全性负责，Cognito 可以处理所有这些。 使用起来很棘手，这里的有一些奇怪的问题要弄清楚。 示例代码和文档可能会更好。 但是我最终得到了所有典型的流程-注册，忘记密码，更改密码，重新发送验证码，输入验证码等-都可以正常工作。 这并不容易，但是似乎可以可靠地工作。 - -### 节点和浏览器之间共享代码 - -这是我犯的另一个错误：我不打算在 Node 和浏览器之间共享代码。 到我意识到可以共享很多代码的时候，采用另一种模块哲学已经太费力了。 我确实共享代码，但是在包含导致在两种情况下都不起作用的依赖项的代码时，我必须非常小心。 - -## PayPal 集成 - -我选择 PayPal 是因为我发现它们的 API 是可以理解的，其仪表板也可以使用，并且其文档可以使用。 支持速度很慢，但通常会有所帮助。 - -当用户接受专业人士对其问题的回答时，付款状态机将启动。在 ProbotService 中，PayPal API 用于创建发票，该发票由 PayPal 发送到用户的电子邮件地址。 通过 PayPal，您可以配置一个 Webhook 来使用发票相关事件。 Webhook 使用绑定到 Lambda 函数的 API 网关。 - -当 Lambda 函数接收发票事件时，它将在事情发生时通知用户和 Pro。 - -* 松弛：通过前面描述的 SQS 机制通知用户。 会向 Pro 发送电子邮件，告知他们应该访问仪表板以获取详细信息。 绝不会通过电子邮件发送任何敏感信息。 - -* Messenger：发短信给用户。 请注意，要在上次联系后 24 小时向用户发送消息，您必须对机器人具有特殊权限。 这并不总是容易获得的。 因此，如果您的机器人需要提前进行此类功能计划。 - -* Web：向用户发送电子邮件，并要求用户登录 Probot 以获得其仪表板上的更多信息。 - -这花了一些时间才能开始工作。 如果未调用与 Webhook 关联的 Lambda 函数，则很难理解问题所在。 绝对打开 A​​PI 网关日志记录。 您将需要它。 - -PayPal Lambda 函数使用与前面所述相同的代码共享方法。 无需进行远程 ProbotService 调用，而是直接调用代码。 - -## 测试 - -这里没什么好想的。 - -对于 API 网关，Lambda 和 DynamoDB，有所有版本的测试和生产版本。 根据配置在运行时选择使用哪个。 - -该网站有测试和生产版本。 为了测试它们，我只使用所有功能。 使用 *aws s3* 命令行将文件从开发环境复制到 S3。 对于本地开发，将 http-server 用作 Web 服务器，并且可以通过 localhost 测试所有功能。 - -PayPal 具有测试和生产配置选项。 每个都分别指向测试和生产网络挂钩。 PayPal 具有在调用 Webhooks 时记录的日志，这在调试时很有用。 不幸的是，事件不是实时发送的，因此您必须等待事件被发送并显示日志。 - -对于 Slack，有一个单独的机器人，用于测试和生产。 每个都分别指向测试和生产网络挂钩。 Messenger 也是一样。 除了将测试版本和生产版本视为完全不同的漫游器之外，我没有其他更清洁的方法。 - -对于本地开发，Slackbot 在开发计算机上运行。 Ngrok 用作隧道，因此 Slack 可以向该进程发送交互式消息。 使用网站的测试版本将测试机器人安装到团队中。 它具有正确的应用程序令牌，可以识别机器人的测试版本。 安装测试机器人后，您可以通过 Slack 与该机器人对话。 - -对于本地开发测试，通过共享代码使 Lambda 代码变得更加容易。 唯一可以调用的外部服务是其他人的服务，而不是您自己的服务。 因此，要进行测试，根本不需要将代码上传到 Lambda。 Lambda 函数中使用的相同代码可从可从命令行执行的脚本中调用。 为您 API 中的每个函数创建一个相应的脚本，并且可以在本地对其进行完全调试。 - -Messengerbot 的本地开发测试比较棘手，因为将消息发送到 bot 时，消息会显示在 Messenger 中。 当您点击按钮时，回复将返回到您的测试网络挂钩。 据我所知，尚无干净的方法可以以可单元测试的方式进行此操作。 我所做的是将 Bot 的测试版本安装到 Messenger 中并记录了用户 ID。 在为每个方案制作测试脚本时，在运行时选择要使用的用户 ID，测试版本或生产版本。 如果方案涉及要求用户回答问题，则将从脚本中发送问题。 然后，您转到手机上，然后使用测试机器人进行回复。 答复将转到您的测试网络挂钩，以便代码可以正常运行。 我对这种方法不是很满意，但是这种方法确实有效，并且比通过 Messenger 进行的所有测试都更快。 - -总有一天应该从 GitHub 安装所有内容，但今天不是那天。 - -## 采纳 - -吸收不好。 我希望随着税收季节临近活动的到来。 问题的一部分在于，作为一名程序员，我几乎迷上了营销。 我正在尝试 Messenger Bot 广告，但是这些广告无效。 - -使用尝试使漫游器不转化的渠道隐喻用户，他们在实际转化并提出问题之前已经保释。 可能存在信任问题。 他们不知道他们在问谁或将得到什么样的答案。 我尝试在网站和漫游器页面上解决这些问题。 例如，如果您不喜欢答案，则无需付款，因此无风险。 - -一种可能性是人们并没有真正使用 Messenger 机器人，并且对于这种应用程序而言，这是一次失败的实验。 - -另一个可能性是我的机器人不是很好。 完全有可能的事情。 - -如果您有任何想法或疑问，请告诉我。 - -## 获得的经验教训 - -* **不要做您所知道的**。 在盲目做您知道的事情之前，先环顾四周，看看是否有更好的选择。 - -* **API 优先**。 为您的服务提出一个抽象并将其实现在一个地方。 当您必须在不同的平台上实现另一个客户端时，您将感激不尽。 - -* **DTO 首先**。 我犯了通过代码库传播数据库访问代码的错误。 只需创建一个数据传输对象并将代码从一开始就集中在一个地方即可。 然后，可以轻松打包和重用它。 - -* **一次**。 要做的聪明的事情是必须使一个简单的机器人来测试这个概念。 我当时知道这一点，但是我真的很想看看在所有三个平台上开发一个机器人的感觉。 那个决定的人是个白痴。 - -* **吻**。 这么容易说，很难做到。 - -* **提前计划共享节点和浏览器模块**。 一旦已经编写了很多代码，就很难进行改造。 - -* **代码共享**。 在 Lambda 函数之间共享很好的模块化库代码在实践中效果很好。 它使从命令行进行测试变得容易。 - -* **无服务器作品**。 由于种种原因，每个人都在涌动。 它可以让一个人完成很多工作。 您有发展机会，但管理起来却少得多。 对于不可预测的工作负载，它便宜得多且可扩展性更高。 我不能说工具很烂，因为我选择不使用任何工具，但是我们仍然有一种方法可以弄清所有这些在实践中是如何工作的。 - -* **事件> API** 。 使用 webhooks 使用 Serverless 将系统连接在一起非常强大。 相比之下，站起一个盒子并运行一个过程来使用 API​​似乎很原始。 - -像大多数课程一样，回想起来，大多数这些令人沮丧的头脑震撼显而易见，但是我想这就是为什么它们是课程。 - -看起来很酷 - -哇听起来真酷 您是独自建造的吗？ 花了多少时间？ - -是的，只有我。 这花了一个令人尴尬的时间:-) - -@ToddHoff 几乎所有编程都可以，尤其是在您必须学习新知识的情况下，这几乎总是这样，因为有各种各样的工具可以完成工作。 - -您的帖子非常有趣。 我正在尝试从中学习。 但是我不明白一件事。 - -您提到了为 lambda 创建单个入口点，然后将请求路由到单独的函数。 但是，如果没有 API 网关，请求如何首先到达 lambda？ - -嗨，杰克， - -可以通过 API 直接调用 Lambda 函数。 他们不需要通过 HTTP。 我大致是这样做的： - -包括适用于您的环境的 AWS API，对于 Web 或 in 节点而言，有所不同。 - -appcfg.AWS = require（“ aws-sdk”）; -appcfg.DB =新的 appcfg.AWS.DynamoDB（）; -appcfg.DBCLIENT = new appcfg.AWS.DynamoDB.DocumentClient（）; -appcfg.LAMBDA = new appcfg.AWS.Lambda（）; -appcfg.SES =新的 appcfg.AWS.SES（）; -appcfg.SQS = new appcfg.AWS.SQS（）; - -函数 ProbotService（appcfg）{ -this.id = 0; -var self = this; - -this.invokeLambda = function（method，params，next）{ - -var payload = { -method：method， -params：params， -id：self.id ++ -} - -var params = { -FunctionName：appcfg.Amazon.ProbotService， -Payload：JSON.stringify（payload） -} - -appcfg.LAMBDA.invoke（params，function（error，response）{ -if（error）return next（error）; - -var payload = JSON.parse（response.Payload）; -如果（payload.error）返回 next（payload.error）； -如果（payload.errorMessage）返回 next（new Error（payload.errorMessage））; - -返回 next（空，payload.result）； - -}）//调用 - -} // invokeLambda - -嗨，托德， - -感谢您的广泛回应！ - -实际上，我知道如何调用 lambda。 我从您调用它的地方很好奇。 看来您可能是从客户端调用它的？ - -PS。 我刚刚开始学习 nodejs。 因此，无论我说什么，都可能变得毫无意义。 - -是的，无论是网站上的客户端，还是 slack 上的 nodejs 内，还是 lambda 本身的 nodejs 内，都是客户端。 尽管几天前我关闭了 slackbot。 太昂贵了，无法继续运行。 - -只需为环境添加正确的库并正确配置即可。 - -在网上： - -<脚本 src =“ js / aws-cognito-sdk.js” > < / script > -<脚本 src =“ js / amazon-cognito-identity.min.js” > < / script > -<脚本 src =“ https://sdk.amazonaws.com/js/aws-sdk-2.3.5.min.js” > < / script > - -在 slack 和 lambda 上，它们将 sdk 安装到 node_modules 中，并且由于用户看不到环境，因此可以从文件中加载配置。 -var AWS = require（'aws-sdk'）; -AWS.config.loadFromPath（'cfg.json'）; -appcfg.AWS = AWS; - -我保持对 appcfg 中所有服务的访问权并将其传递。 这样，您可以在启动时以特定于环境的方式配置所有内容。 - -现在，您可以在所有环境中使用相同的 lambda 调用代码。 - -this.giveAnswerToPro = function（answer，next）{ -return self.invokeLambda（“ giveAnswerToPro”，答案，下一步）; -} // GiveAnswerToPro - -这是我的模块问题出现的地方。您必须小心在每个环境中包含的内容。 在网络资料中包含一个在 nodejs 中不可用的模块，您已将其破坏。 - -这很酷。 您是否考虑过在营销中使用会计师的图片和/或个人资料？ 甚至有照片。 主页上显示“真实的会计师”，因此看到它可能会让人放心。 - -Hi Todd, - -感谢您的回复！ - -我知道可能要问很多。 但是，如果您不介意，会介意开放源代码并与我们共享吗？ -对像我这样的人进入 nodejs 和 aws 领域确实很有帮助。 - -谢谢。 - -我得考虑杰克。 我不确定如何将我的东西充分分离出来。 - -有趣的文章。 \ No newline at end of file +大多数情况下非常有用 \ No newline at end of file diff --git a/docs/110.md b/docs/110.md index fe7b43c..9dd95ab 100644 --- a/docs/110.md +++ b/docs/110.md @@ -1,73 +1,37 @@ -# 使用 AWS，Scala，Akka，Play，MongoDB 和 Elasticsearch 构建社交音乐服务 +# 每天处理 1 亿个像素-少量竞争会导致大规模问题 -> 原文： [http://highscalability.com/blog/2014/3/11/building-a-social-music-service-using-aws-scala-akka-play-mo.html](http://highscalability.com/blog/2014/3/11/building-a-social-music-service-using-aws-scala-akka-play-mo.html) +> 原文： [http://highscalability.com/blog/2013/1/21/processing-100-million-pixels-a-day-small-amounts-of-content.html](http://highscalability.com/blog/2013/1/21/processing-100-million-pixels-a-day-small-amounts-of-content.html) -![](img/7887820329b58171ca35d8132a92ae4c.png) +![](img/5088f2340fb872cea42ebbdd8c5dbfc1.png) -*这是[前 Roem Hermon](https://twitter.com/margolis20) ， [serendip.me](http://serendip.me) 的首席架构师 [Rotem Hermon](https://twitter.com/margolis20) 的来宾转贴，涉及在进行启动音乐服务后的体系结构和扩展注意事项 。* +*这是 [Gordon Worley](http://www.linkedin.com/pub/gordon-worley/39/977/257) 的来宾帖子， [Korrelate](http://korrelate.com/) 的软件工程师在其中将在线购买与离线购买相关联（查看他们在这里做了什么）。* -[serendip.me](http://serendip.me) 是一项社交音乐服务，可以帮助人们发现朋友分享的美妙音乐，还可以将他们介绍给他们的“音乐灵魂伴侣”，即他们社交圈之外的人，他们在音乐方面有着相似的品味。 +几周前，我们一天早上来到办公室，发现所有服务器警报都响了。 像素日志处理落后了 8 个小时，并且没有取得进展。 查看日志后，我们发现有一个大客户在夜间上线，为我们提供的流量比最初告诉我们的要多 10 倍。 我不会说我们感到惊慌，但办公室肯定比平时更加​​紧张。 但是，在接下来的几个小时中，由于有远见和快速的思考，我们得以扩大规模以处理增加的负载并清除积压的日志，以使日志处理恢复到稳定状态。 -Serendip 在 AWS 上运行，并基于以下堆栈构建： [scala](http://www.scala-lang.org/) （和某些 Java）， [akka](http://akka.io/) （用于处理并发性），[播放框架](http://www.playframework.com/)（用于 Web 和 API 前端）， [MongoDB](http://www.mongodb.org/) 和 [Elasticsearch](http://elasticsearch.org/) 。 +在 Korrelate，我们部署了[跟踪像素](http://en.wikipedia.org/wiki/Web_bug)（也称为信标或网络错误），我们的合作伙伴将其用于向我们发送有关其用户的信息。 这些微小的 Web 对象不包含可见内容，但可以包含透明的 1 乘 1 gif 或 Javascript，并允许我们的合作伙伴在有人看到广告或采取与广告相关的操作时通知我们，而无需向我们发送广告服务器日志。 例如，当我们的一个合作伙伴展示广告时，他们通过将展示跟踪像素作为图像包含在 iframe 中或嵌入以我们的像素为源的脚本标签来触发我们的展示跟踪像素。 他们的广告会动态生成像素的网址，因此可以在查询字符串中向我们传递有关所展示广告的信息。 对于选择接受第三方 cookie 的用户，我们还可以在用户上设置和读取 Korrelate 用户 ID cookie，以便我们可以跟踪他们的活动，并在[聚合和匿名化](http://korrelate.com/privacy/)之后使用它，以提供我们的 分析产品。 -### 选择堆栈 +在早期，甚至在 Korrelate 成为 Korrelate 之前，我们就知道有一天我们需要每天摄取数十亿个跟踪像素。 因此，当我们开始编写像素对数处理器时，我们进行了架构选择，使其可以扩展。 -建立 serendip 的挑战之一是从第一天起就需要处理大量数据，因为 serendip 的主要特征是它收集**并从公共音乐服务在 Twitter** 上共享的每一首音乐。 因此，当我们讨论选择要使用的语言和技术的问题时，一个重要的考虑因素就是扩展能力。 +最初，日志处理器是用 Java servlet 编写的，但是事实证明这很难在服务器上进行管理，而且我们都不满意使用 Java 进行编程。 寻找替代方案，因为当时我们使用 [Pentaho](http://www.pentaho.com/) 分析工具套件来生成有关原始数据的报告，所以我们转向了[水壶](http://kettle.pentaho.com/)（俗称 Pentaho 数据集成） 数据。 -JVM 似乎是我们系统经过验证的性能和工具的正确基础。 它也是许多开源系统（例如 Elasticsearch）的选择语言，这使**使用其本机客户端**-很大的优势。 +Kettle 是在 JVM 上运行的提取转换加载工具，可以充分利用多线程来快速处理大量数据。 它还具有一个称为 Spoon 的易于使用的 GUI 工具，用于设计 Kettle 程序，该程序需要大量的配置，而编程却相对较少。 我们非常享受使用 Kettle 创建和部署日志处理的速度。 随着时间的流逝，我们意识到了水壶的局限性。 -当我们研究 JVM 生态系统时，scala 脱颖而出，成为一种有趣的语言选择，它允许现代方法编写代码，同时保持与 Java 的完全互操作性。 支持 scala 的另一个论点是 **akka actor 框架，它似乎非常适合流处理基础结构**（确实如此！）。 Play 网络框架才刚刚开始被采用，并且看起来很有希望。 早在 2011 年初我们刚开始时，这些仍然是最前沿的技术。 因此，我们当然非常高兴，到 2011 年底，scala 和 akka 合并成为 [Typesafe](http://typesafe.com/) ，随后不久 Play 就加入了。 +通过 Kettle 作业运行大量数据需要大量内存（在我写这篇文章时，日志处理器需要 8 GB 内存来处理 250,000 条记录的文件）。 在开发方面，使用 Spoon 易用性的缺点是源文件仅是人类可编辑的 XML，因此我们无法利用 Git 正常工作流来轻松合并并发开发分支，从而迫使我们 就像有人处理日志处理器时源被锁定一样。 但是尽管有这些限制，我们仍继续使用 Kettle，因为它正在工作，我们还有很多其他工作要做，并且我们知道我们可以在需要时扩大规模，即使它会很昂贵。 -**选择 MongoDB 是因为它结合了开发人员的友好性，易用性**，功能集和可能的可伸缩性（使用自动分片）。 我们很快了解到，要使用和查询数据的方式将需要在 MongoDB 上创建很多大索引，这将使我们很快遇到性能和内存问题。 因此，我们一直主要将 MongoDB 用作键值文档存储，还依赖于其原子增量来获取需要计数器的多个功能。 -通过这种使用，MongoDB 变得非常可靠。 它也很容易操作，但是主要是因为我们设法*避免使用分片*并使用单个副本集（MongoDB 的分片架构非常复杂）。 +几个月前，我们不得不开始同时运行两个日志处理器，以适应我们的负载。 这是一个很好的体验，因为它有助于揭示日志处理中的问题区域。 -为了查询我们的数据，我们需要一个具有完整搜索功能的系统。 在可能的开源搜索解决方案中， **Elasticsearch 成为最具扩展性和面向云的系统**。 它的动态索引架构以及它提供的许多搜索和构面功能使我们可以在其之上构建许多功能，从而使其成为我们体系结构的核心组成部分。 +当只有一个日志处理器运行时，我们遇到的唯一性能问题与过程的各个部分有关，需要很长时间才能完成。 例如，我们发现对数据库中表的更新花费了很长时间，因此我们几乎将所有存储像素数据的表都转换为仅追加，以便快速插入。 某些表不能仅作追加操作，因此要与我们创建的加载表一起使用，日志处理将快速将数据插入到表中，然后稍后再回过头来将加载表与数据库中的主表进行同步 比我们执行 upsert 的速度快。 -我们选择**自己管理 MongoDB 和 Elasticsearch** ，并且出于两个主要原因，不使用托管解决方案。 首先，我们希望完全控制两个系统。 我们不想依靠其他因素进行软件升级/降级。 其次，我们处理的数据量意味着托管解决方案比直接在 EC2 上直接管理它要昂贵。 +调出第二个日志处理器会使我们面临新的问题。 尽管由于对仅追加表的非阻塞写入而使我们能够快速写入数据库，但是需要与加载表同步的少数几个表引起了足够的争用，两个日志处理器在运行一个日志处理器时几乎没有任何收益。 为了解决这个问题，我们将日志处理分为两部分：仅写到仅追加表的部分和需要插入堆表的部分。 这样，我们就可以打开仅追加日志处理器的两个实例（仅是堆表日志处理器之一），并获得良好的吞吐量，因为堆表从每个需要插入或更新的日志文件接收的数据相对较少，而追加- 只有表从每个日志文件接收很多数据。 -### 一些数字 +因此，在像素大量涌入的早晨，我们认为我们已经做好了扩大规模的准备。 我们在几个小时之内启动了运行其他附加仅日志处理器实例的其他服务器，并开始处理日志（堆表日志处理器自行继续足够快地运行以保持运行状态）。 但是，我们很快发现，日志处理器中仍然存在争用。 -Serendip 的“泵”（处理 Twitter 公众流和 Facebook 用户供稿的部分）**每天大约消化 5,000,000 个项目**。 这些项目通过一系列“过滤器”传递，这些过滤器检测并解析受支持服务（YouTube，Soundcloud，Bandcamp 等）的音乐链接，并在它们之上添加元数据。 泵和过滤器作为 akka actor 运行，并且整个过程由单个 **m1.large EC2 实例**管理。 如果需要，可以通过使用 akka 的远程角色将系统分发到处理器集群来轻松扩展。 +为了跟踪日志处理的方式，我们将一些基本统计信息写到了几个审计表中，这些统计信息涉及日志处理需要多长时间以及处理多少像素。 为了收集这些数据，我们使用了 Kettle 的内置日志记录功能将信息写入表格，然后将其合并为对我们有用的摘要形式。 事实证明，Kettle 的编写方式要求在审计表上请求排他表级锁以将其写入。 而且由于在日志处理器实例的每次运行中都会发生数十次，因此对于相同的表，我们有数百个请求彼此等待。 每个请求的清除速度都很快，但是加了一点点延迟，导致日志处理器实例在应在 2 中完成时需要花费 15 分钟的时间来运行。 -在这些项目中，我们每天大约可获得 850,000 个有效项目（即真正包含相关音乐链接的项目）。 这些项目在 Elasticsearch 中（以及在 MongoDB 中用于备份和保持计数器）都已建立索引。 由于每个有效项都意味着更新多个对象，因此在 Elasticsearch 中我们获得的**索引速率为〜40 / sec** 。 -我们**在 Elasticsearch 中保留项目（推文和帖子）的每月索引**。 每个月度索引包含**〜2500 万个项目，并具有 3 个碎片**。 群集以 **4 个节点运行，每个节点在 m2.2xlarge 实例**上。 此设置有足够的内存来运行我们需要的数据搜索。 +我们关闭了 Kettle 的内置日志记录功能，将其替换为我们自己的一些不需要表级锁定的代码，并且日志处理器之间的数据库争用消失了。 我们以艰难的方式学到了我们经常听到的智慧，但显然还没有被内在化：**少量争用可能成为大规模的问题**。 -我们的 MongoDB 集群处理更多数据类型，计数器和统计信息更新时，每秒**为 100 个写入/秒，每秒 300 次为**读取。 副本集具有在 **m2.2xlarge 实例上运行的主节点，在 m1.xlarge 实例**上运行的辅助节点。 +通过从日志处理中完全消除争用，我们能够快速启动十多个日志处理器实例，并使用它们来快速处理积压的事务，然后将其调节回稳定状态。 在短短 24 小时内，一切恢复正常，节省了一些额外的硬件和日志处理器。 -### 建立一个提要 +尽管日志处理器现在可以处理高级别的并发性，但仍需要对其进行重建以处理更多的像素，而无需当前日志处理器的高昂成本。 调出当前日志处理器的新实例意味着添加具有大量 RAM 的服务器（通常大约需要 24 GB，以便我们在每台服务器上运行两个日志处理器，以及用于其他进程的额外 RAM），这是很昂贵的。 而且，当前的日志处理器在与数据库的有限连接上仍然面临潜在的争用。 为了解决这个问题，我们需要寻找减少需要向数据库传递数据的进程数量的方法。 -当我们开始设计 Serendip 的主要音乐供稿的体系结构时，我们知道我们希望供稿是动态的并对用户的动作和输入做出反应。 如果用户给某首歌“加油”或“播放”特定艺术家，我们希望该动作立即反映在提要中。 如果用户“不喜欢”艺术家，则我们不应再次播放该音乐。 - -我们还希望提要是来自多个来源的音乐的组合，例如朋友共享的音乐，喜爱的艺术家的音乐以及具有相同音乐品味的“建议”用户共享的音乐。 -这些要求意味着采用“ [扇出即写](http://www.quora.com/What-is-the-best-storage-solution-for-building-a-news-feed-MongoDB-or-MySQL)”的方法来创建提要是不可行的。 我们需要一个选项，以使用与用户有关的所有信号实时构建提要。 Elasticsearch 提供的功能集使我们能够构建这种实时提要生成。 - -提要算法包含几种“策略”，用于选择要在每次提要中以不同比率动态组合的项目。 每种策略都可以考虑到最新的用户操作和信号。 将策略的组合转换为对实时数据的几次搜索，这些搜索由 Elasticsearch 不断索引。 由于数据是基于时间的，并且索引是每月创建的，因此**我们始终只需要查询完整数据**的一小部分。 - -幸运的是，Elasticsearch 可以很好地处理这些搜索。 它还提供了扩展此体系结构的已知途径-**写入可以通过增加分片**的数量进行缩放。 可以通过添加更多副本和物理节点来扩展搜索范围。 - -查找“音乐灵魂伴侣”（通过音乐品味匹配用户）的过程很好地利用了 Elasticsearch 的**构面（聚合）功能。 作为持续的社交流处理的一部分，该系统通过计算遇到的社交网络用户的顶级共享艺术家（使用对共享音乐的多面搜索）来准备数据。** - -当偶然的用户发出信号（通过播放音乐或与提要互动）时，它可以触发对该用户的音乐灵魂伴侣的重新计算。 该算法会根据喜欢的艺术家列表（不断更新）找到最匹配的其他用户，并权衡受欢迎程度，分享数量等其他参数。然后应用另一组算法来过滤垃圾邮件发送者（是的， 是音乐垃圾邮件发送者……）和离群值。 - -我们发现，此过程可为我们提供足够好的结果，同时又使我们免于需要其他可以运行更复杂的群集或推荐算法的系统。 - -### 监控和部署 - -Serendip 正在使用 [ServerDensity](http://www.serverdensity.com/) 进行监视和警报。 这是一款易于使用的托管解决方案，具有不错的功能集和合理的启动价格。 ServerDensity 本机提供服务器和 MongoDB 监视。 我们还大量使用了向其中报告自定义指标的功能，以报告内部系统统计信息。 - -内部统计信息收集机制为系统中发生的每个操作收集事件，并将其保存在 MongoDB 收集中。 定时作业每分钟一次从 MongoDB 中读取这些统计信息，并将其报告给 ServerDensity。 这使我们可以使用 ServerDensity 监视和警告 Elasticsearch 以及我们的运营数据。 - -使用 Amazon Elastic Beanstalk 完成服务器和部署的管理。 Elastic Beanstalk 是 AWS 的受限 PaaS 解决方案。 它非常容易上手，尽管它并不是真正功能齐全的 PaaS，但其基本功能足以满足大多数常见用例的需要。 它提供了简单的自动缩放配置，还可以通过 EC2 进行完全访问。 - -使用驻留在 EC2 上的 [Jenkins](http://jenkins-ci.org/) 实例完成应用程序的构建。 Play Web 应用程序打包为 WAR。 [构建后脚本](https://github.com/rore/beanstalk-upload)将 WAR 作为新的应用程序版本推送到 Elastic Beanstalk。 新版本不会自动部署到服务器，而是手动完成的。 通常将其首先部署到登台环境中进行测试，然后将其批准部署到生产环境中。 - -### 外卖 - -总结一下，这是从构建 serendip 中学到的一些重要经验教训，而不是通过任何特殊命令得出的。 - -1. **知道如何缩放**。 您可能不需要从第一天开始进行扩展，但是您需要知道系统的每个部分如何扩展以及扩展到什么程度。 如果扩展需要时间，请提前给自己足够的时间。 -2. **准备峰**。 特别是在初创企业的生命中，如果您始终以接近最高的容量运行，那么一个救生员或 reddit 帖子就会使您的系统瘫痪。 保持足够的余量，以便您可以处理突然的负载或准备好快速扩展。 -3. **选择一种不会阻碍您的语言**。 确保要使用的技术使用您的语言的本地客户端，或者至少具有主动维护的客户端。 不要卡在等待库更新。 -4. **相信炒作**。 您需要一种将随您的产品一起增长并且不会过早死亡的技术。 一个充满活力，活跃的社区以及对该技术的一些质疑可以很好地表明其生存。 -5. **不要相信炒作**。 查找有关您正在评估的技术的简报。 他们可以教您有关它的弱点。 但也不要太当真，当事情无法按预期进行时，人们往往会情绪激动。 -6. **玩得开心**。 选择一种使您兴奋的技术。 一个让您认为“哦，太酷了，我该怎么办”。 毕竟，这也是我们的目标。 \ No newline at end of file +我们还希望从 Kettle 转移到一个使代码管理更容易的系统。 为此，我们已开始使用 [Storm](http://storm-project.net/) 构建新的日志处理器，该处理器提供了用于创建自定义实时流处理工作流的灵活框架，类似于 [Hadoop](http://hadoop.apache.org/) 提供了灵活框架的方式 用于批处理。 尽管仅 Storm 本身提供的内置功能要比 Kettle 少得多，但也不必这样做，因为 Storm 工作流可以用任何语言编写，也可以使用我们想要的任何现有库。 由于我们的大多数代码已经在 Ruby 中，因此我们能够利用现有的代码库在 Ruby 中构建 Storm 工作流。 基于其他使用 Storm 的[其他人](https://github.com/nathanmarz/storm/wiki/Powered-By)，我们希望看到我们的 Storm 日志处理器每天可以扩展到数十亿像素。 \ No newline at end of file diff --git a/docs/111.md b/docs/111.md index 1036047..e25206f 100644 --- a/docs/111.md +++ b/docs/111.md @@ -1,532 +1,262 @@ -# Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构 +# DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长 -> 原文： [http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) +> 原文： [http://highscalability.com/blog/2013/1/28/duckduckgo-architecture-1-million-deep-searches-a-day-and-gr.html](http://highscalability.com/blog/2013/1/28/duckduckgo-architecture-1-million-deep-searches-a-day-and-gr.html) -![](img/fb94c22e828546d379d859ae77268cf7.png) +![](img/0fc8c666278eef1071727bcc17340365.png) *这是对 [Gabriel Weinberg](https://twitter.com/yegg) ， [Duck Duck Go](https://duckduckgo.com/) 的创建者和一般[的创始人的访谈，内容涉及创业大师](http://www.gabrielweinberg.com/blog/)，关于 DDG 的架构是什么样的 在 2012 年。* -[Rick Reed](http://www.linkedin.com/pub/rick-reed/2/186/427) 在 3 月即将举行的演讲中，标题为 [，即“十亿”和“ B”：在 WhatsApp 上扩展到新的水平](http://lanyrd.com/2014/erlangfactory/scwqrt/) 令人眼前一亮 [WhatsApp](http://en.wikipedia.org/wiki/WhatsApp) 统计信息： +创新的搜索引擎新贵 DuckDuckGo 在 2012 年 2 月获得了 [3000 万次搜索](https://duckduckgo.com/traffic.html) ，平均每天超过 100 万次搜索。 [超级投资者 Fred Wilson](http://www.avc.com/a_vc/2012/02/duck-duck-go-passed-1mm-searches-per-day.html) 将其定位为干净，私有，公正且快速的搜索引擎。 与加布里埃尔交谈之后，我喜欢弗雷德·威尔逊（Fred Wilson）先前所说的话，这似乎更接近问题的核心： [我们为 Reddit，Hacker News 无政府主义者](http://venturebeat.com/2012/05/21/fred-wilson-duckduckgo-reddit-hacker-news/) 投资了 DuckDuckGo。 -> 拥有数百个节点，数千个内核，数百 TB 的 RAM 的东西，并希望为不久将在全球范围内成为现实的数十亿智能手机提供服务？ WhatsApp 上基于 Erlang / FreeBSD 的服务器基础结构。 在满足对消息传递服务不断增长的需求方面，我们面临着许多挑战，但是随着我们不断扩大服务范围（> 8000 核）和速度（>每秒 70M Erlang 消息）， 系统。 +选择 DuckDuckGo 不仅可以视为一项技术选择，而且可以视为一场革命的投票。 在这个时代，您知道自己的本质不关乎爱情或友谊，而是更有效地将您卖给广告商，因此 DDG 将自己定位为 [不追踪替代方案](http://whatisdnt.com/) ， [隐私标记](https://duckduckgo.com/privacy)。 当然，您仍然可以通过获利来获利，但方式会更加文明和匿名。 -但是由于我们还没有那个话题，让我们来看一下 Rick Reed 两年前在 WhatsApp 上的演讲： [扩展到数百万个同时连接](http://vimeo.com/44312354) 。 +推进隐私权是一种与 Google 等人竞争的利基市场的好方法，因为从定义上讲，他们永远无法在隐私权上竞争。 我明白了。 但是我发现最引人注目的是 DDG 的强大愿景，即将一群垂直数据供应商捆绑到他们的搜索框架中，从而使众包插件网络提供更广泛的搜索范围。 例如，有一个专门的 Lego 插件，可针对完整的 Lego 数据库进行搜索。 例如，在您的搜索查询中使用香料的名称，然后 DDG 会识别出它的名称，并可能触发对高度调整的配方数据库的更深入的搜索。 每次搜索都可以触发许多不同的插件，这些插件都可以实时处理。 -在 Yahoo 期间，Rick Reed 用 C ++构建了高性能的消息总线，对于高可伸缩性体系结构并不是陌生的。 创始人也是前雅虎人，他们在缩放系统方面经验不多。 因此，WhatsApp 凭借其扩展能力诚实地表现出来。 而且由于他们的目标是在世界上每部智能手机上都拥有大毛毛的大胆目标，因此几年之内可能会增加 50 亿部手机，因此他们需要充分利用这种体验。 +无法搜索 Open Web 提供所有这些数据吗？ 不完全是。 这是具有语义的结构化数据。 不是 HTML 页面。 您需要一个能够对更丰富的数据集进行分类，映射，合并，过滤，确定优先级，搜索，格式化和消除歧义的搜索引擎，而关键字搜索无法做到这一点。 您需要 DDG 在其搜索引擎中内置的智能工具。 当然，现在的问题之一是，数据已经变得非常有价值，许多成年人不再愿意共享它们。 -在我们弄清事实之前，让我们先讨论一下这个绝对迷人的难题：WhatsApp 对 Facebook 可能价值 190 亿美元？ +获得广告支持会使 DDG 处于棘手的位置。 定向广告更有利可图，但具有讽刺意味的是，DDG 不跟踪政策意味着它们无法收集定向数据。 对于那些对隐私感兴趣的人来说，这也是一个卖点。 但是，由于搜索是出于意图驱动而著名的，因此 DDG 的对查询进行分类并将其与数据源进行匹配的技术已经成为一种高价值的定位方式。 -作为一名程序员，如果您问我 WhatsApp 是否值那么多，我会回答否定！ 它只是通过网络发送内容。 变得真实。 但是我也是那个认为我们不需要博客平台的人，因为远程登录到您自己的服务器，用 vi 编辑 index.html 文件然后用 HTML 编写帖子有多难？ 我花了相当长的时间才意识到这不是愚蠢的代码，而是让所有这些用户都喜欢并使用您的产品才是最困难的部分。 您无法购买爱情 +看到这些力量如何发挥作用将令人着迷。 现在，让我们看看 DuckDuckGo 如何实现他们的搜索引擎魔力... -是什么让 WhatsApp 如此有价值？ 技术？ 忽略所有说可以使用 PHP 在一周内编写 WhatsApp 的人。 那根本不是真的。 就像我们将看到的很酷的技术一样。 但可以肯定的是，如果他们愿意的话，Facebook 有足够的能力来构建 WhatsApp。 +## 信息源 -让我们看一下功能。 我们知道 WhatsApp 是 [无头](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) （无广告，无头，无游戏）的产品，其忠实的 [用户 世界](http://www.wired.com/wiredenterprise/2014/02/whatsapp-rules-rest-world/) 。 它在残酷的 SMS 收费世界中提供免费短信。 作为一个庇护的美国人，最令我惊讶的是，有多少真实的人使用 WhatsApp 与家人和朋友保持联系。 因此，当您使用 WhatsApp 时，您认识的人很可能已经在使用它，因为每个人都拥有一部电话，从而缓解了空社交网络的问题。 它积极地跨平台运行，因此您认识的每个人都可以使用它，并且它将正常工作。 它“行之有效”是经常使用的短语。 它功能齐全（共享位置，视频，音频，图片，一键通，语音消息和照片，阅读回执，群组聊天，通过 WiFi 发送消息，并且无论收件人是否在线，都可以完成所有操作） 或不）。 它很好地处理了本地语言的显示。 使用您的手机号码作为身份并将您的联系人列表作为社交图表非常简单。 无需电子邮件验证，用户名和密码，也不需要信用卡号。 这样就可以了。 +* 对 Gabriel Weinberg 的个人采访。 +* 在 **相关文章下列出的资源。** -令人印象深刻，但那不值 190 亿美元。 其他产品可以在功能上竞争。 +## 统计资料 -[Google 想要](https://www.theinformation.com/Google-Was-Willing-to-Beat-Facebook-s-19-Billion-Offer-for-WhatsApp) 是可能的原因。 这是 [威胁](http://www.forbes.com/sites/parmyolson/2013/12/19/watch-out-facebook-whatsapp-climbs-past-400-million-active-users/) 的威胁。 费用为每位用户 0.99 美分。 Facebook 是 [绝望的](http://www.foxbusiness.com/technology/2014/02/21/facebook-buying-whatsapp-is-desperate-move/) 。 适用于 [您的电话簿](http://www.theregister.co.uk/2014/02/20/facebook_whatsapp_19bn_buy_also_45_for_your_phonebook/) 。 用于元数据（即使 WhatsApp 不保存任何元数据）。 - -适用于 [4.5 亿活跃用户](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) ，用户基础每天增长一百万，潜在的十亿用户。 Facebook 需要其下一个十亿用户使用 WhatApp。 当然，如果有的话，那一定是一部分。 每位用户约 40 美元的成本似乎并不合理，尤其是在大量库存支付的情况下。 Facebook 以 [每位用户 30 美元的价格收购了 Instagram](http://finance.fortune.cnn.com/2012/04/10/why-instagram-is-worth-1b-to-facebook/) 。 Twitter 用户为 [，价值$ 110](http://www.forbes.com/sites/georgeanders/2013/11/07/a-twitter-user-is-worth-110-facebooks-98-linkedins-93/) 。 - -本尼迪克特·埃文斯 [很好地证明了](https://www.youtube.com/watch?v=VnhbvS0MBXE) 移动业务是一个价值 1 万亿美元的业务，WhatsApp 正在扰乱该行业的 SMS 部分，全球范围内 全球短信系统每天仅发送 200 亿条短信，每天发送 180 亿条短信，从而实现超过 1000 亿美元的收入。 从 PC 到几乎普及的智能手机的过渡发生了根本变化，机遇的规模是一个比 Facebook 正常运营的市场更大的可寻址市场。 - -但是 Facebook 承诺不会投放广告，也不会出现干扰，那么胜利在哪里？ - -[商业使用移动](http://www.happymarketer.com/singapore-is-progressively-doing-business-over-whatsapp-are-you) 的有趣发展。 WhatsApp 用于为项目团队创建小组对话，风险投资家通过 WhatsApp 进行交易流程对话。 - -Instagram 用于科威特 [出售绵羊](http://storify.com/cbccommunity/kuwait-entrepreneurs-use-instagram-to-sell-sheep) 。 - -WhatsApp 的竞争对手微信在 1 月份推出了出租车出租车服务。 在第一个月， [接待了 2100 万辆出租车](http://www.techinasia.com/wechat-21-million-taxi-rides-booked/) 。 - -电子商务的未来似乎将通过移动消息传递应用程序进行传播，它一定是电子商务吗？ - -不仅仅是使用 WhatsApp 的企业曾经在台式机或网络上使用过这些应用程序。 西班牙的警务人员使用 WhatsApp 来抓捕罪犯。 意大利的人们使用它来组织篮球比赛。 - -出于显而易见的原因，商务和其他应用程序正在向移动设备转移。 每个人都拥有移动设备，这些消息传递应用程序功能强大，免费且使用便宜。 您不再需要桌面或 Web 应用程序即可完成工作。 许多功能可以叠加在消息传递应用程序上。 - -因此，消息传递对 Google 和 Facebook 构成了威胁。 桌面已死。 网络快要死了。 消息传递+移动是 [整个生态系统，它们避开了其渠道](https://news.ycombinator.com/item?id=7282876) 。 消息传递已经成为[在移动而不是搜索上的参与中心](http://cubed.fm/2014/02/cubed-episode-18-the-paradigm-shift-of-mobile-engagement-models/)，它改变了事物的发现方式以及改变应用程序将赢得未来的本质。 我们不仅是前网页排名，而且是网络前。 - -Facebook 是否需要进入这个市场或变得无关紧要？ - -随着移动技术的发展，我们看到了 Facebook 的无人化。 Facebook 的桌面 Web 界面是门户样式的界面，可访问后端提供的所有功能。 它很大，很复杂而且吱吱作响。 谁真正喜欢 Facebook UI？ - -当 Facebook 转向移动设备时，他们尝试了门户方法，但这种方法无效。 因此，他们采用的策略是更小，更集中，[专用的应用](http://www.theverge.com/2014/1/16/5269664/facebook-plans-suite-of-standalone-mobile-apps-for-2014)。 移动第一！ 在小屏幕上，您只能做很多事情。 在移动设备上，找到特殊的应用程序要比在复杂的门户风格的应用程序中找到深深的菜单要容易得多。 - -但是 Facebook 向前迈进了一步。 他们不仅在创建专用的应用程序，而且还在提供具有相似功能的多个竞争应用程序，而这些应用程序甚至可能没有共享后端基础架构。 我们通过 Messenger 和 WhatsApp，Instagram 和 Facebook 的照片应用程序看到了这一点。 Paper 是 Facebook 的备用界面，功能非常有限，但它做得很好。 - -康韦定律可能在这里适用。 “设计系统的组织受约束以产生作为这些组织的通信结构副本的设计”的想法。 借助整体后端基础架构，我们获得了类似于 Borg 的门户设计。 向移动的转变使组织摆脱了这种思维方式。 如果可以构建仅提供一部分 Facebook 基础结构视图的应用程序，则可以构建完全不使用 Facebook 基础结构的应用程序。 而且如果他们不需要 Facebook 的基础架构，那么它们完全可以免费完全不由 Facebook 构建。 那么，Facebook 到底是什么？ - -Facebook 首席执行官马克·扎克伯格（Mark Zuckerberg）有他自己的看法，他在移动世界大会 上的 [主旨演讲中说，Facebook 收购 WhatsApp 与该公司密切相关。 Internet.org 愿景：](http://techcrunch.com/2014/02/24/whatsapp-is-actually-worth-more-than-19b-says-facebooks-zuckerberg/) - -> 的想法是开发一组免费使用的基本互联网服务-“互联网 911”。这些服务可能是社交网络服务，例如 Facebook，消息服务，搜索或其他 像天气一样。向用户免费提供这些捆绑服务将像各种网关药物一样工作-那些如今可能能够负担数据服务和电话费用的用户根本看不出为什么要为这些数据付费 这将为他们提供为何重要的一些背景信息，这将使他们为此类更多的服务付费（或者希望如此） - -这是长距离比赛，这是一种游戏，拥有大量有价值的股票，您可以玩。 - -我们得出结论了吗？ 我不这么认为。 如此惊人的美元金额加上如此微弱的明显立即回报，以至于长期游戏的解释实际上确实是有道理的。 我们还处在移动的初期。 没有人知道未来会是什么样，所以不必费力强迫未来看起来像您的过去。 Facebook 似乎就是这样做的。 - -但是足够了。 仅 32 位工程师如何支持 4.5 亿活跃用户？ 让我们找出... - -## 来源 - -这里的警告是，我们对所有架构的 WhatsApp 知之甚少。 只是零零碎碎地从各种来源收集而来。 Rick Reed 的主要演讲是关于使用 Erlang 时使服务器达到 200 万连接的优化过程，这很有趣，但这不是完整的体系结构。 - -* [从 2012 年起缩放至数百万个同时连接](http://vimeo.com/44312354) （ [幻灯片](http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf) ），作者：瑞克·里德 - -* [Erlang Factory 对 Rick Reed 的采访](http://mirkobonadei.com/interview-with-rick-reed/)。 - -* [对来自 Erlang 的 WhatsApp](http://pdincau.wordpress.com/2013/03/27/an-interview-with-eugene-fooksman-erlang/) 的 Eugene Fooksman 的采访。 - -* [DLD14-WhatsApp 怎么了？ （Jan Koum，David Rowan）](http://www.youtube.com/watch?v=WgAtBTpm6Xk&feature=youtu.be) - -* [yowsup](https://github.com/tgalal/yowsup/wiki/Yowsup-Library-Documentation) 是 WhatsApp API 的开源版本。 由于 DMCA 移除，该存储库现在不可用[，但是它们确实记录了 WhatsApp 的一些内部工作原理。 万物的多样性。](http://openwhatsapp.org/blog/2014/02/13/mass-dmca-takedowns-whatsapp/) - -* 在 *相关文章下列出的一些来源。* - -## 统计信息 - -这些统计信息通常适用于当前系统，而不是我们正在讨论的系统。 当前系统的讨论将包括有关数据存储，消息传递，元集群以及更多 BEAM / OTP 补丁的黑客技巧。 - -* 4.5 亿活跃用户，并且达到这个数字的速度超过历史上任何其他公司。 - -* 32 位工程师，一名开发人员支持 1400 万活跃用户 - -* 每天在七个平台上（入站+出站）发送 500 亿条消息 - -* 每天有超过一百万的用户注册 - -* 为广告投入了$ 0 - -* 来自红杉资本的 6000 万美元[投资； 红杉将赚 34 亿美元](http://techcrunch.com/2011/04/08/sequoia-whatsapp-funding/) - -* 35％是 Facebook 现金中的[被用于交易](http://finance.fortune.cnn.com/2014/02/19/facebook-whatsapp-the-other-numbers/) - -* 数百个节点 - -* > 8000 色 - -* 数百兆字节的 RAM - -* >每秒 70M Erlang 消息 - -* 在 2011 年，WhatsApp 在具有内存和 CPU 的单台计算机上实现了 [100 万个已建立的 tcp 会话](http://blog.whatsapp.com/index.php/2011/09/one-million/) 。 在 2012 年，它被推翻了 [200 万 tcp 连接](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/) 。 2013 年，WhatsApp [发了推文](https://twitter.com/WhatsApp/status/286591302185938946) ：12 月 31 日，我们创下了新的记录天：入站 7B 消息，出站 11B 消息=一天处理的总消息量为 180 亿 ！ 2013 年快乐！！！ +* 2012 年 2 月的 3 千万次搜寻 +* 每天平均超过一百万次搜索 +* 每天 12M API 请求 ## 平台 -### 后端 - -* Erlang - -* FreeBSD - -* 偏航，lighttpd - -* PHP - -* 自定义补丁 [BEAM](http://www.erlang-factory.com/upload/presentations/708/HitchhikersTouroftheBEAM.pdf) （BEAM 类似于 Java 的 JVM，但适用于 Erlang） - -* 自定义 XMPP - -* 托管[可能位于软件层](http://www.ip-adress.com/whois/whatsapp.com) 中 - -### 前端 - -* 七个客户端平台：iPhone，Android，Blackberry，诺基亚 Symbian S60，诺基亚 S40，Windows Phone 、？ - -* SQLite - -### 硬件 - -* 面向用户的标准服务器： - - * Dual Westmere Hex-core（24 个逻辑 CPU）； - - * 100GB RAM，SSD； - - * 双网卡（公用面向用户的网络，专用后端/分发）； - -## 产品 - -* **重点是消息传递**。 不管人们身在何处，都可以联系世界各地的人们，而不必花很多钱。 创始人扬·库姆（Jan Koum）记得 1992 年与全世界的家人建立联系有多么困难。 - -* **隐私** 。 由扬·库姆（Jan Koum）在乌克兰度过的成长经历所塑造，那里没有什么私人物品。 消息不存储在服务器上； 聊天记录未存储； 目标是尽可能少地了解用户； 您的姓名和性别未知； 聊天记录仅在您的手机上。 - -## 常规 - -* WhatsApp 服务器几乎完全在 Erlang 中实现。 - - * 执行后端消息路由的服务器系统是在 Erlang 中完成的。 - - * 伟大的成就是，使用很小的服务器空间就可以管理活动用户的数量。 团队的共识是，这很大程度上是因为 Erlang。 - - * 值得一提的是 [Facebook 聊天室](http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)于 2009 年用 Erlang 编写，但由于很难找到合格的程序员，他们放弃了它。 - -* WhatsApp 服务器已从 ejabberd 启动 - - * Ejabberd 是用 Erlang 编写的著名开源 Jabber 服务器。 - - * 最初选择是因为它开放，受到开发人员的好评，易于启动以及 Erlang 对于大型通信系统的长期适用性的保证。 - - * 接下来的几年用于重写和修改 ejabberd 的相当多的部分，包括从 XMPP 切换到内部开发的协议，重组代码库和重新设计一些核心组件，并对 Erlang VM 进行很多重要的修改，以 优化服务器性能。 - -* 为了每天处理 500 亿条消息，重点是建立一个可靠的有效系统。 获利是一个值得关注的问题，它远未实现。 - -* 系统运行状况的主要衡量标准是消息队列长度。 节点上所有进程的消息队列长度将得到持续监控，如果它们积压的积压超过预设阈值，则会发出警报。 如果一个或多个进程落后，则会发出警报，这将提供指向下一个攻击瓶颈的指针。 - -* 通过上载图像，音频或视频以发送到 HTTP 服务器，然后发送指向内容的链接及其 Base64 编码缩略图（如果适用）来发送多媒体消息。 - -* 通常每天都会推送一些代码。 通常，一天要多次，但通常可以避免高峰时段。 Erlang 有助于积极地将修补程序和功能投入生产。 热加载意味着可以推送更新而无需重启或流量转移。 通常，再次通过热加载可以很快消除错误。 系统趋向于松散耦合，这使得很容易以增量方式推出更改。 - -* Whatsapp 应用程序使用什么协议？ WhatsApp 服务器池的 SSL 套接字。 所有消息都会在服务器上排队，直到客户端重新连接以检索消息为止。 消息的成功检索将发送回 whatsapp 服务器，该服务器将该状态转发回原始发件人（它将在消息旁边显示为“复选标记”图标）。 客户端接受消息后，就会从服务器内存中清除消息 - -* 在 Whatsapp 中，注册过程如何在内部进行？ WhatsApp 曾经根据电话 IMEI 号码创建用户名/密码。 最近更改了。 WhatsApp 现在使用应用程序的一般请求发送唯一的 5 位数 PIN 码。 然后，WhatsApp 将 SMS 发送到指定的电话号码（这意味着 WhatsApp 客户端不再需要在同一部电话上运行）。 然后，根据密码，该应用会向 WhatsApp 请求一个唯一的密钥。 该密钥用作将来所有呼叫的“密码”。 （此“永久”密钥存储在设备上）。 这也意味着注册新设备将使旧设备上的密钥无效。 - -* Android 上使用了 Google 的推送服务。 - -* Android 上的更多用户。 Android 更加令人愉快。 开发人员可以对功能进行原型设计，并在一夜之间将其推销给数亿用户，如果有问题可以迅速解决。 iOS，不是很多。 - -## 每服务器 2 百万个以上的连接 - -* 经历了很多用户增长，这是一个好问题，但这也意味着必须花钱购买更多的硬件，并增加管理所有这些计算机的操作复杂性。 - -* 需要针对流量增加进行规划。 例如足球比赛和西班牙或墨西哥的地震。 这些发生在高峰流量负载附近，因此需要有足够的备用容量来处理高峰和颠簸。 最近的一场足球比赛在每日高峰时出站邮件率激增了 35％。 - -* 初始服务器装入是每台服务器 200 个同时连接。 - - * 推断出来将意味着很多服务器都有望实现增长。 - - * 面对突发负载，服务器很脆弱。 网络故障和其他问题将会发生。 需要解耦组件，以免大容量情况下变脆。 - - * 目标是每服务器一百万个连接。 当它们以 200K 连接运行时，给出了一个宏伟的目标。 运行具有裕量的服务器以允许发生世界性事件，硬件故障以及其他类型的故障，将需要足够的弹性来处理高使用率水平和故障。 - -## 用于提高可伸缩性的工具和技术 - -* 编写了系统活动报告程序工具（wsar）： - - * 记录整个系统的系统统计信息，包括 OS 统计信息，硬件统计信息，BEAM 统计信息。 它是经过构建的，因此很容易从其他系统（例如虚拟内存）中插入指标。 跟踪 CPU 利用率，总体利用率，用户时间，系统时间，中断时间，上下文切换，系统调用，陷阱，已发送/已接收的数据包，所有进程中队列中消息的总数，繁忙的端口事件，流量速率，输入/输出字节 ，排程统计资料，垃圾收集统计资料，收集的字词等。 - - * 最初每分钟运行一次。 由于系统的驱动更加困难，因此需要一秒钟的轮询分辨率，因为如果一分钟内看不到该事件，则该事件将在空间中发生。 真正细粒度的统计数据，以查看一切运行情况。 - -* CPU 中的硬件性能计数器（pmcstat）： - - * 以时间百分比查看 CPU 的位置。 可以知道执行仿真器循环花费了多少时间。 在他们的情况下，这是 16％，告诉他们只有 16％的人在执行仿真代码，因此即使您能够删除所有 Erlang 代码的所有执行时间，也只能节省总运行时间的 16％。 这意味着您应该专注于其他领域以提高系统效率。 - -* dtrace，内核锁计数，fprof - - * Dtrace 主要用于调试，而不是性能。 - - * 在 FreeBSD 上修补了 BEAM 以包括 CPU 时间戳。 - - * 编写脚本以创建所有进程的汇总视图，以查看例程在所有时间上所花费的时间。 - - * 最大的获胜是在打开锁定计数的情况下编译模拟器。 - -* 一些问题： - - * 较早的时候，在垃圾回收例程上花费了更多时间，这被减少了。 - - * 看到已调离的网络堆栈有一些问题。 - - * 大多数问题与模拟器中的锁争用有关，这在锁计数的输出中表现出强烈的作用。 - -* 测量： - - * 合成工作负载（意味着从您自己的测试脚本生成流量）对于以极大规模调整面向用户的系统的价值很小。 - - * 非常适合简单的界面（例如用户表），可以尽快生成插入和读取。 - - * 如果要在一台服务器上支持一百万个连接，则将需要 30 台主机打开足够的 IP 端口以生成足够的连接来仅测试一台服务器。 对于 200 万台服务器，它将占用 60 个主机。 只是很难产生这种规模。 - - * 在生产期间看到的流量类型很难生成。 可以猜测正常的工作量，但是实际上可以看到网络事件，世界事件，因为多平台可以看到客户端之间行为的变化以及国家/地区的变化。 - - * Tee 的工作量： - - * 进行正常的生产流量并将其通过管道传输到单独的系统。 - - * 对于可能限制副作用的系统非常有用。 不想散布流量并做会影响用户永久状态或导致向用户发送多条消息的事情。 - - * Erlang 支持热加载，因此可以在完整的生产负载下运行，有一个想法，进行编译，在程序运行时加载更改并立即查看更改的好坏。 - - * 添加了旋钮以动态更改生产负载，并查看其如何影响性能。 将跟踪 sar 输出，以查看诸如 CPU 使用率，VM 使用率，侦听队列溢出以及转动旋钮以查看系统如何做出反应。 - - * 实际生产负荷： - - * 终极测试。 同时进行输入工作和输出工作。 - - * 将服务器放入 DNS 两次，这样它将获得正常流量的两倍或三倍。 由于客户端不遵守 DNS TTL 且存在延迟，因此造成了 TTL 问题，因此无法迅速做出反应以获取更多无法处理的流量。 - - * IPFW。 将流量从一台服务器转发到另一台服务器，这样可以为主机提供所需客户端连接的确切数量。 一个错误导致内核崩溃，因此无法很好地工作。 - -* 结果： - - * 开始于每个服务器 200K 个并发连接。 - - * 第一个瓶颈出现在 425K。 系统出现了很多争论。 工作停止了。 对调度程序进行检测，以衡量正在执行的工作，休眠或旋转的工作量。 在负载下，它开始达到休眠状态，因此整个系统使用了 35-45％的 CPU，但调度程序的利用率为 95％。 - - * 第一轮修复程序已超过一百万个连接。 - - * VM 使用率为 76％。 CPU 占 73％。 BEAM 模拟器以 45％的利用率运行，这与用户百分比非常接近，这很好，因为该模拟器以用户身份运行。 - - * 通常，CPU 利用率不是衡量系统繁忙程度的好方法，因为调度程序使用 CPU。 - - * 一个月后，解决瓶颈问题的原因是每个服务器有 200 万个连接。 - - * BEAM 利用率为 80％，接近 FreeBSD 可能开始分页的位置。 CPU 大致相同，连接增加了一倍。 调度程序遇到了争用，但运行得很好。 - - * 似乎是个停止的好地方，因此开始分析 Erlang 代码。 - - * 最初每个连接有两个 Erlang 进程。 切成一个。 - - * 使用计时器做了一些事情。 - - * 每个服务器的连接数达到 280 万峰值 - - * 571k pkts / sec，> 200k dist msgs / sec - - * 进行了一些内存优化，因此 VM 负载降至 70％。 - - * 尝试了 3 百万个连接，但失败了。 - - * 当系统出现问题时，请查看长消息队列。 单个消息队列或消息队列的总和。 - - * 已添加到 BEAM 工具中有关每个进程的消息队列统计信息。 发送/接收多少消息，速度有多快。 - - * 每 10 秒采样一次，可以看到一个进程在其消息队列中有 600K 条消息，出队列率为 40K，延迟为 15 秒。 预计排水时间为 41 秒。 - -* 调查结果： - - * Erlang + BEAM 及其修复-具有出色的 SMP 可扩展性。 几乎线性的可伸缩性。 卓越。 在 24 路机器上，可以以 85％的 CPU 使用率运行系统，并且可以保持生产负荷。 它可以像这样整天运行。 - - * 证明 Erlang 的程序模型。 - - * 服务器启动的时间越长，它将积累长期处于运行状态的连接（大多数情况下处于空闲状态），因此它可以处理更多的连接，因为这些连接对每个连接而言并不那么忙。 - - * 竞争是最大的问题。 - - * 他们的 Erlang 代码中进行了一些修复，以减少 BEAM 的争用问题。 - - * 一些已修补到 BEAM。 - - * 对工作负载进行分区，因此无需过多地处理处理器。 - - * 时间锁定。 每次从端口传递消息时，它看起来都会更新一天中的时间，这是所有调度程序中的一个锁，这意味着所有 CPU 都在打一个锁。 - - * 优化使用计时器轮。 删除了 bif 计时器 - - * 检查 IO 时间表在算术上增长。 创建的 VM 崩溃将在各个点重新分配哈希表。 改进以使用表格的几何分配。 - - * 添加了写入文件，该文件占用一个您已经打开的端口，以减少端口争用。 - - * Mseg 分配是所有分配器之间的单点争用。 按调度程序进行。 - - * 接受连接时有很多端口事务。 设置选项以减少昂贵的端口交互。 - - * 当消息队列积压很大时，垃圾回收将破坏系统的稳定性。 因此，暂停 GC 直到队列缩小。 - - * 避免付出一些常见的代价。 - - * 将 TSE 时间计数器从 FreeBSD 9 反向移植到了 8。读取计时器更便宜。 快速获取时间，比购买芯片便宜。 - - * 从 FreeBSD 9 向后移植 igp 网络驱动程序，因为在 NIC 锁定时存在多个队列问题。 - - * 增加文件和套接字的数量。 - - * Pmcstat 显示花费了大量时间来查找网络堆栈中的 PCB。 因此，增加哈希表的大小可以使查找更快。 - - * BEAM 补丁 - - * 先前提到的检测补丁。 仪器调度程序可获取利用率信息，消息队列的统计信息，睡眠次数，发送速率，消息计数等。可以使用 procinfo 以 Erlang 代码进行操作，但是连接数百万时非常慢。 - - * 统计信息收集非常有效，因此可以在生产中运行。 - - * 统计信息以 3 个不同的衰减间隔保持：1、10、100 秒间隔。 允许随着时间推移查看问题。 - - * 使锁计数适用于较大的异步线程数。 - - * 为调试锁定计数器添加了调试选项。 - - * 调整 - - * 将调度程序的唤醒阈值设置为低，因为调度程序会进入睡眠状态并且永远不会唤醒。 - - * 优先使用 mseg 分配器，而不是 malloc。 - - * 每个调度程序的每个实例都有一个分配器。 - - * 配置载波大小从大到大。 使 FreeBSD 使用超级页面。 降低了 TLB 跳动率，并提高了同一 CPU 的吞吐量。 - - * 以实时优先级运行 BEAM，以使诸如 cron 作业之类的其他事情不会中断计划。 防止可能导致重要用户流量积压的故障。 - - * 修补程序可记录旋转计数，以便调度程序不会旋转。 - - * 失忆症 - - * 首选 os：timestamp 而不是 erlang：now。 - - * 不使用事务，但是使用远程复制遇到了积压。 每个表的并行复制可提高吞吐量。 - - * 实际上还有很多更改。 - -## 课程 - -* **优化是一项仅适用于巨魔和工程师的深色球衣工作。** 。 当 Rick 进行他为获得 200 万个服务器连接所做的所有更改时，我很麻木。 请注意，编写工具，运行测试，向后移植代码，将测试对象添加到几乎每个堆栈级别，调试系统，查看痕迹，处理非常低级的细节并试图理解所有内容都需要大量工作 。 这就是消除瓶颈，以将性能和可伸缩性提高到极限的方法。 - -* **获取所需的数据**。 **编写工具。 补丁工具。 添加旋钮。** Ken 坚持不懈地扩展系统以获取他们所需的数据，不断为他们管理和优化系统所需的数据编写工具和脚本。 尽一切努力。 - -* **测量。 消除瓶颈。 测试。 重复。** 这就是您的操作方式。 - -* **二郎岩石！** Erlang 继续证明其作为通用，可靠，高性能平台的能力。 尽管就个人而言，所需的所有调优和补丁处理都对该主张造成了怀疑。 - -* **破解病毒代码并获利** **。** 病毒性是一种寓言性的品质，但是正如 WhatsApp 所显示的，如果您确实发现了，伙计，它值得很多钱。 - -* **价值和员工人数现已正式离婚** **。** 当今世界上有很多倍增力。 先进的全球电信基础设施使类似 WhatsApp 的应用成为可能。 如果 WhatsApp 必须建立网络或电话等，那将永远不会发生。 强大的廉价硬件和开放源代码软件的可用性当然是另一个倍数。 就像在正确的时间，正确的位置，正确的产品出现在正确的购买者面前一样。 - -* **这种对用户想法** **的残酷关注。** WhatsApp 专注于成为一个简单的消息传递应用程序，而不是游戏网络，广告网络或消失的照片网络。 那为他们工作。 它指导了他们的无广告立场，在添加功能时保持应用程序简单的能力，以及总体而言，它在任何手机上都可以正常工作。 - -* **简单原因的限制是可以的** **。** 您的身份与电话号码相关，因此，如果更改电话号码，则您的身份将消失。 这非常像计算机。 但这确实使整个系统的设计更加简单。 - -* **年龄不是没有** **。** 如果是年龄歧视导致 WhatsApp 联合创始人布莱恩·阿克顿（Brian Acton）在 2009 年无法在 Twitter 和 Facebook 上找到工作，那真可耻，可耻，可耻。 - -* **简单开始，然后自定义** **。** 最初启动聊天时，服务器端基于 ejabberd。 此后已被完全重写，但这是向 Erlang 方向迈出的第一步。 在最初的用例中，Erlang 的可伸缩性，可靠性和可操作性方面的经验导致了越来越广泛的使用。 - -* **保持服务器计数低** **。** 不断努力将服务器数量保持在尽可能低的水平，同时为产生短期使用高峰的事件留有足够的空间。 分析和优化，直到这些工作受到收益递减的影响，然后再部署更多硬件。 - -* **故意过度配置硬件。** 这可确保用户在庆祝活动期间获得不间断的服务，并且员工能够享受假期，而不必花费所有时间解决过载问题。 - -* **当您收取费用** **时，增长停滞。** 当免费使用 WhatsApp 时，增长非常快，早期每天有 10,000 次下载。 然后，当切换到付费时，每天的费用下降到 1,000。 到了年底，在添加了图片消息后，他们决定收取一次性的下载费用，后来又改为年度付款。 - -* **灵感来自最陌生的地方** **。** 忘记了 Skype 帐户上的用户名和密码的经验驱使人们使应用程序“正常运行”。 +* EC2 +* Ubuntu +* Perl & CPAN +* [服务器密度](http://www.serverdensity.com/) -监控 +* Solr +* PostgreSQL +* Memcached +* [Bucardo](http://bucardo.org/) -异步 PostgreSQL 复制系统 +* [全球流量管理器](http://www.dnsmadeeasy.com/services/global-traffic-director/) -区域之间的负载平衡 +* Nginx +* [getFavicon](http://getfavicon.appspot.com/) -提供收藏夹图标 +* [daemontools](http://en.wikipedia.org/wiki/Daemontools) -用于管理 Unix 服务的免费工具 +* 转到 +* [Asana](http://asana.com/) -项目管理。 +* HipChat-内部通讯 +* Yammer +* JavaScript +* YUI（移至 jQuery） + +## 内部内容 + +* Gabriel 喜欢他们的系统： + * 非常简单，尽管随着时间的推移它们变得越来越复杂。 一切都是模块化的，可以减轻复杂性。 Daemontools 用于保持服务运行，一切都通过 Nginx 运行。 有很多不同的服务，但是架构使它们都保持不变。 + * 主要目标是 100％的正常运行时间和速度。 降低复杂度有助于实现这两个目标。 + +## 走出地下室并进入 AWS（主要是） + +* DuckDuckGo 过去耗尽了加百利的地下室。 现在，大多数组件（包括所有前端组件）都在 AWS 上。 + * 一些“持久性机器”仍然存在于地下室，因为没有令人信服的理由来移动这些组件，例如 Git 存储库，爬网以及更新[零点击连接](http://dhruvbird.com/ddb/zc.html)的实时 Wikipedia 索引。 + * Linode 用于托管一些社区功能，例如翻译。 + * 作为迁移到 AWS 的一部分，从 FreeBSD 迁移到 Ubuntu。 +* 移动到多个区域以获得更好的前端性能。 使 DDG 遍地快速，用户将来。 + * 用户抱怨的一项是速度。 通过在 4 个 AWS 数据中心（加利福尼亚，弗吉尼亚，新加坡，爱尔兰）中运行，DDG 可以更接近其全球用户。 + * 相同的软件在所有数据中心中运行。 + * Global Traffic Director 用于其 DNS，并在区域之间平衡用户负载。 DDG 希望使用更多的区域（南美和另一个亚洲数据中心），但是 Traffic Director 目前仅在四个区域工作。 +* 由于 EBS 参与了大多数大型故障，因此完全退出了 EBS。 EBS 也经历了性能差异。 + * 本来应该可以使用新的 Provisioned IOP，但是在体系结构中具有较少的额外移动部件会更好。 + * 尽管当前的非 EBS 体系结构运行良好，但将来可能会尝试使用 PIOP。 +* 主要在超大型计算机上运行，​​因为它们似乎是网络高 IO 的最佳选择，并且它们具有 4 个临时磁盘。 + * 基准测试表明，超大型机器的性能差异最低。 + * 发现 4 个临时磁盘的性能比条带化 8 个 EBS 磁盘的性能要好。 + * 对高 IO 实例类型不感兴趣，因为目标是在内存中保留尽可能多的数据。 高事务处理率不是问题，并且数据将尽快缓存。 另外，机器的 IO 使用率也不高。 +* 中型实例用于开发人员计算机。 每个人都有自己的中等开发实例。 临时实例用于测试，足以模拟实际环境。 +* 数据中心同步。 + * 主要处理只读数据。 更新会一直发布，但不必立即发布。 意味着数据中心之间的同步不是数据中心问题。 确实没有任何一致性问题。 + * 后端系统（非 AWS）具有主数据库，可将更新推送到区域。 +* 分布式缓存系统使用 memcached。 + * 高内存 m2.xlarge 用于缓存。 + * 大小约为 100GB，在 m2.xlarge 机器上分片。 + * 缓存某些内容时，它将推送到所有其他缓存系统。 没有主人。 + * 自定义 Perl 解决方案。 + * 缓存是通过 Nginx 路由的，因此如果数据在缓存中，请求将完全绕过 Perl 后端。 + * 不受大小限制，它们可以根据需要添加任意数量的缓存计算机，挑战是弄清楚要放入缓存中的内容，这样将很有用，并且不会产生不良结果。 + * 研究更智能的缓存老化算法。 查看返回的有机链接。 您可以从其相关的代码片段和域中找到很多有关链接的信息。 问题在于此信号仅在结果返回后才可用，因此 UI 速度较慢，但​​对缓存非常有用。 + * 优先考虑的是在所有区域中正确同步。 现在，他们将致力于制作更智能的缓存。 +* 使用了许多数据库，包括 PostgreSQL，Solr，Berkeley 和平面文件。 + * Bucardo 用于 PostgreSQL 复制。 + * Solr 同步是通过自己的过程进行的，而不是内置的复制。 + * PostgreSQL 主服务器在地下室，而从服务器在每个区域。 + * PostgreSQL 保存即时答案和实体数据。 例如，如果您输入“ duckduckgo”，那么您会从 Wikipedia 中获得某些东西，而这是来自 PostgreSQL 的。 + * PostgreSQL 数据库有大约 100 个数据源。 这些由后端爬网并存储在数据库中。 + +## 搜寻-非常复杂 + +* 高级别：尝试弄清楚查询的含义，然后将其路由到适合该查询的适当数据存储区和 API。 在某些情况下，请将其带回，并行化并混合在一起。 +* 零点击实例答案框可以由 PostgreSQL，Solr，即时 API，平面文件或组合提供动力。 +* 链接结果是由 API 驱动的，尽管顶部链接可能来自其他来源。 [链接源包括](http://help.duckduckgo.com/customer/portal/articles/216399-sources) ：Bing，Yahoo，Yandex，Blekko，WolframAlpha 等。 +* 所有解析和合并逻辑都在 Perl 中。 +* 合并的两个级别：后端和客户端。 + * 在后端，将来自不同 API 的对链接结果的异步请求合并，然后再将其返回给客户端。 + * 在客户端上，向可能在不同计算机上的模块化组件发出了异步 JavaScript 请求。 包括广告请求，搜索结果，搜索建议。 由于它们具有不同的延迟，因此将它们保持分开。 + * 这些请求均独立缓存。 可以缓存的所有内容都会被缓存。 任何涉及外部请求的操作都可能很慢。 如果来自他们的数据存储区，Instant Answer 将很快返回。 + * 通过流水线化和缓存可以更快地发出请求。 + * 缓存服务器是按区域划分的，它们会尝试尽可能多地填充它们。 大大缩短了响应时间。 + * 目标缓存命中率为 50％。 目前为 30％。 问题是结果被缓存的时间长度。 结果会发生变化，因此，当您遇到突发新闻时，您不希望出现 5 天前的结果。 他们正在尝试提高 差异缓存 的性能，学习何时将某些内容缓存一周而不是更长或更短。 + * 搜索建议的缓存命中率更高，因为并非每次查询都出现，并且可以缓存更长的时间。 + * 广告未缓存。 供应商具有点击欺诈检测功能。 广告会留有空间，因此，当广告可用时，页面显示不会出现毛刺。 缓存有关搜索的内部指标，以便更好地呈现页面。 +* Nginx 仍然可以提供所有服务。 + * 由于出于隐私方面的考虑，他们不想在其域外拨打电话，因此所有路由和代理均通过其 Nginx 服务器进行路由。 最大的示例是 URL 的图标。 getFavicon 服务用于获取网站图标。 它们被缓存了大约一天，因此速度很快，因此搜索结果不会 [泄漏给提供者](http://www.gabrielweinberg.com/blog/2011/01/search-leakage-is-not-fud-google-et-al-please-fix-it.html) 。 + * Nginx 缓存由于错误而受到限制。 大小约为一档。 +* [DuckDuckHack](http://duckduckhack.com/) 是新的即时应答平台。 + * 4 种插件类型。 Fathead 类型（查询空间的胖头）是 PostgreSQL 存储，它实际上是关键字数据库。 + * 比赛不一定要完全击中。 它是定义，链接类别，消歧页面以及它们具有的许多其他功能的大数据存储。 + * 梦想是吸引更多的细分受众，以更好地为关心特定主题的人们提供服务。 例如：乐高零件。 例如，有一个乐高零件数据库。 零件图片和零件编号可以通过搜索自动显示。 + * 很难集成插件，因此尽管有很多需求，但采用速度比他们希望的慢。 仍在学习如何使其最佳发挥作用。 + * 对结果进行两个级别的过滤。 如果使用了严格的触发器，并且插件返回某些内容的可能性很高，那么结果的页面上将留有空间，并在结果返回时进行填充。 如果相关性很低并且结果经常被过滤掉，那么就不会再有空格了，因为页面上似乎有很大的空白。 涉及很多个案逻辑。 +* 引擎的核心正在决定如何将搜索路由到正确的后端组件。 + * 这个主题上有一个知识产权墙，但仍有许多细节。 + * 两种查询：长尾巴和胖尾巴。 粗尾查询针对 PostgreSQL，长尾查询针对 Solr。 对于较短的查询，PostgreSQL 优先。 长尾填补了“实例答案”的所有其他内容。 + * 不像其他搜索引擎那样以机器学习为中心。 启发式用于将查询空间划分为不同的部分，它们专注于那些特定的部分以找出如何最好地对其进行分类。 + * 示例：输入豆腐生姜。 香料插件会根据 DDG 认为这是食谱搜索的事实，即时获取结果。 DDG 与插件提供商合作，从其抓取中提取好成分关键字。 为它们的数据存储区构建了一个非常具体的分类器，它们在每个查询上运行。 + * 有时会触发多个类别，并且它们必须是优先顺序才能对结果进行排序。 会变得很复杂。 + * 一些分类器要简单得多。 插件接口支持关键字触发器，这相对简单。 比赛不一定是准确的。 例如，匹配可以在单词的开头或结尾。 它是哈希系统。 您查看所有单词并根据哈希进行匹配。 真快。 + * 正则表达式插件较慢。 尝试转换为哈希，或在其下使用带有正则表达式的更广泛的哈希。 + * 核心代码在插件执行之前运行，以进行分类。 像“豆腐”这样的单词查询更多地依赖于 the 头。 首先运行，其余所有短路。 + * 有很多情况，您很快就会陷入困境。 + * 诸如“ 60 分钟”之类的查询会产生歧义，这意味着它询问您是指哪个“ 60 分钟”，这是来自 PostgreSQL 的。 还触发了一个插件，可在节目实际播放时为您提供。 + * 存在用于调整插件的元语言。 例如，假设数据是否与此插件匹配，那么即使有另一个即时答案，数据也足以显示。 + * 赞助商链接被联合到 Microsoft Yahoo! 搜索联盟。 + * 在我们的示例查询页面中，“即时答案”框可能转到 PostgreSQL 和 Solr 数据库以及其他存储。 “ 60 分钟”部分，该部分实时进行服务，以使用 JavaScript API 提取数据。 + * Dream 要在 Instant Answers 中获得 80％的覆盖率，每个初创公司都将创建一个插件，以利用其专业的数据来改善搜索结果。收益是流量，因为即时答案甚至显示在广告上方。 并非所有信息都显示在框中。 预计点击率将达到 50％。 +* 搜索建议来自一个完全不同的本地组件。 + * 有些人对事物使用不同的单词。 目标不是重写查询，而是提供有关如何做得更好的建议。 + * 例如，“电话评论”将用电话代替电话。 这是通过 NLP 组件发生的，该组件试图弄清楚您的电话意思以及查询中是否应该使用任何同义词。 + * 希望探索更多此查询构建组件，但尚未找到最佳的 UI。 +* 许多盲人用户写有关可用性问题的文章。 由于信息隐藏在脚本中，因此很容易意外破坏可用性。 屏幕阅读器可能对呈现的内容感到困惑，因为需要适当的标题标签。 例如，很容易忘记放入 ALT 标签。 +* 目标是通过添加 1000 多个来源以提供所有内容的即时解答，以达到 80％的搜索覆盖率。 维基百科使您达到 20％。 添加更多的长尾巴，您最多可以得到 30％。 长长的尾巴表示它与任何内容都不完全匹配，但是 Wikipedia 中有一段与该问题完全匹配。 它不会直接打到 Wikipedia 主题，而是在 Wikipedia 中。 + * Google 收购了 MetaWeb 作为填写其知识图谱的手段。 + * Google 在页面右侧有更多信息，并显示更多信息。 DDG 将信息推到顶部，而信息却更少。 + * 何时显示即时答案的标准是，它们应该比链接要好得多。 在 DDG 右手边扔很多可能对某人感兴趣的东西。 +* 滤泡。 当您单击一个链接时，会显示更多类似该链接的链接。 您的点击和搜索历史记录将您锁定在过滤器气泡中。 您会看到越来越多的内容。 搜索和点击历史记录不用于定位结果。 过滤器气泡破裂。 他们可能会在将来提供此功能，但必须选择加入。 + +## 开发 + +* 团队处于 50％远程状态。 全职 10-15 人。 20 至 25 人是固定供款人。 有些人在兼职做非常具体的功能。 对他们来说很棒。 +* 用于源代码控制的 Git。 使用标签发布。 部署系统可以访问所有计算机并安装软件。 自插件启动以来，情况更加复杂。 +* 每个开发人员都有一个中等云实例。 +* Asana 用于项目管理。 +* HipChat 和 Yammer 用于内部通信 +* 前端开发使用很多底层 JavaScript。 从 YUI 迁移到 jQuery 的思考。 + +## 获利策略- [广告](http://help.duckduckgo.com/customer/portal/articles/216405-advertising) + +* 目标是避免混乱，因此请尽量减少广告。 如果广告有用，那么它们实际上可以改善结果。 +* 在广告定位更精准之前，不会有更多的广告。 这将需要更好的广告网络后端。 +* 搜索广告供稿不多，因此选择不多。 要在搜索空间中实际投放广告，您需要大量的广告客户。 可以将整个查询类别组合在一起，例如财务查询，但随后广告变得不那么相关了。 +* 考虑到与其他搜索引擎相比，广告商在 DDG 上投放广告系列的动机仍然很低。 +* 开放数据比以往任何时候都多，但是仍有一些数据被锁定并且无法通过插件获得：飞行，电影和体育。 有些公司对数据拥有垄断权，这就是他们的业务。 初创企业通常更愿意共享数据。 +* 搜索供应商没有要求使用特定的广告网络。 + +## 观众提问 + +* 延迟管理？ + * 可能时管道请求。 + * 受亚马逊网络的限制，但主要的事情是将事物分成不同的区域。 + * 使用异步。 + * 使用内存缓存。 + * 为 Nginx 评估 SPDY。 +* 最大的扩展挑战？ + * 没什么大不了的，主要是因为他们已经对架构进行了模块化。 拆下组件并放入其自己的堆栈很简单。 前端需求是单独完成的。 只需更改主机名，然后指向其他位置即可。 + * 降低必要的数据集复制的复杂度，并尝试使其尽可能保持只读。 +* 如果 Yahoo 和 Bing 关闭您会怎样？ + * 还有其他提供商，因此没有即时问题。 + * 总体而言，风险随着时间的推移而降低，因为 DDG 是这些公司的资产，因为 DDG 正在从 Google 手中抢占份额。 DDG 正在使用他们的广告网络。 + * 未被视为威胁，因此不太可能出现结果。 +* 您会赚足够的钱生存吗？ + * 不用担心！ + * 搜索广告可赚钱。 他们希望通过减少他们的 cr 脚，使他们更有利可图。 + * 他们的方法并没有那么昂贵。 他们不需要赚大笔的钱就可以继续营业。 +* 从长远来看，您如何计划与 Google 脱颖而出？ + * 专注于 Google 无法轻松复制的功能，并非出于技术原因，而是出于商业和文化原因。 + * 长尾答案功能。 + * 真正的隐私。 + * 缺乏混乱-链接结果不会因其他属性的插入而混乱，因此请保持干净。 + * 更积极地删除垃圾邮件。 Google 做得不好。 + * 即时答案在移动设备上很棒。 构建新的移动应用程序，但是移动设备在发行方面更具挑战性。 所谓分发，是指电话具有内置的搜索提供程序，这是使用阻力最小的途径。 即使使用非常出色的搜索应用，也很难吸引人们使用它们。 Siri 是使搜索难以使用的另一个示例。 + +## 获得的经验教训 + +* **保持简单** 。 他们没有大量的负载均衡器和许多子系统。 模块化组件，使其独立。 +* **用户关心性能** 。 通过复制到多个区域并包括一个缓存层，使其更接近用户，从而大大提高了性能。 +* **缓存只是故事的开始** 。 缓存后，您必须找出如何最好地构造缓存以及何时使数据过期。 保留数据的时间过长，用户将获得不良结果。 因此，必须将数据仔细分类为特定的缓存策略。 +* **只读架构很不错** 。 DDG 方法的强大功能是因为它们具有很大程度上只读的数据集。 +* [**众包插件**](http://idealab.talkingpointsmemo.com/2012/05/duckduckgo-wants-developers-to-hack-its-search-results.php) **获得更大的搜索范围是一个好主意**。 实时集成这么多数据源将是一个很大的挑战，但是拥有一个能够正确处理这么多种不同类型数据的搜索引擎的愿景真是太棒了。 希望世界不会破坏计划。 +* **使用这么多第三方服务是优势和劣势** 。 之所以有实力，是因为这些联盟使 DDG 能够访问比以往更多的数据。 就像一个较弱的国家与其他较弱的国家结盟，共同对抗一个较大的国家。 不利之处在于，由于信息源具有更高的延迟，必须将它们合并在一起以使一切看起来像一个统一的整体，因此使系统的设计更加困难。 +* **启发式工作** 。 您最终会遇到一个复杂的基于规则的体系结构，但是启发式方法可以让您微调所有不同搜索结果源之间的关系。 诀窍是获取查询并将其正确映射到所有插件。 与普通的机器学习方法相比，做得好是一个非常有价值的解决方案，当它碰上时会很棒，但是错过时会卡住。 +* **与巨人** 竞争时，您需要一个角度。 DDG 正在追求他们不希望 Google 复制的功能，并保持较低的成本，以便他们有能力继续获得更合理的收入。 +* **移动是挑战和机遇** 。 移动设备上的搜索引擎锁定使其难以竞争。 具有讽刺意味的是，“即时答案”是一项出色的移动功能，因为您无需分页浏览大量文本即可找到所需内容。 + +非常感谢 Gabriel Weinberg 抽出宝贵的时间进行采访。 他非常有耐心，对答案很开放。 我们花了很长时间，但我认为结果值得。 如果您有兴趣，DuckDuckGo 正在寻找移动开发人员。 ## 相关文章 -* [关于黑客新闻](https://news.ycombinator.com/item?id=7306066) - -* [主题演讲：Benedict Evans-InContext 2014](https://www.youtube.com/watch?v=VnhbvS0MBXE) （相关的 [幻灯片](http://ben-evans.com/presentations/2013/11/5/mobile-is-eating-the-world-autumn-2013-edition) ） - -* [Whatsapp 和 190 亿美元](http://ben-evans.com/benedictevans/2014/2/19/whatsapp-and-19bn) ，作者：Benedict Evans - -* [WhatsApp 的博客：一家市值 160 亿美元的初创企业的精彩日记](http://www.slideshare.net/socialmarketingfella/the-diary-of-a-16-billion-startup-31457350) -Andre Bourque 的精彩活动时间表。 - -* Rick 在 GitHub 上对 [Erlang 的更改](https://github.com/reedr) - -* [WhatsApp 博客](http://blog.whatsapp.com/) ： - - * [一百万！](http://blog.whatsapp.com/index.php/2011/09/one-million/) （ [Hacker News](https://news.ycombinator.com/item?id=3028547) ） - - * [一百万就是 2011 年](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/) - - * [4 亿个故事](http://blog.whatsapp.com/index.php/2013/12/400-million-stories/) - -* [WhatsApp：内幕](http://www.wired.co.uk/news/archive/2014-02/19/whatsapp-exclusive) - -* [WhatsApp](http://www.whatsapp.com/opensource/) 使用的开源项目 - -* [Whatsapp，Facebook，Erlang 和实时消息传递：一切都始于 ejabberd](http://blog.process-one.net/whatsapp-facebook-erlang-and-realtime-messaging-it-all-started-with-ejabberd/) - -* Quora： [WhatsApp 如何工作？](http://www.quora.com/How-does-WhatsApp-work-1) ， [WhatsApp 如何在移动网络中工作？](http://www.quora.com/How-does-WhatsApp-work-out-of-mobile-network) ， [WhatsApp 如何成长得如此之大？](http://www.quora.com/WhatsApp-Messenger/How-did-WhatsApp-grow-so-big) - -* [WhatsApp 已损坏，实际上已损坏](http://fileperms.org/whatsapp-is-broken-really-broken/) -早期的安全问题 - -* [WhatsApp 首席执行官 Jan Koum Hates Advertising 和 Tech Rumor Mill（全潜视频）](http://allthingsd.com/20130510/whatsapp-ceo-jan-koum-hates-advertising-and-the-tech-rumor-mill-full-dive-video/) - -* [新加坡正在逐步通过 WhatsApp 开展业务。 你是？](http://www.happymarketer.com/singapore-is-progressively-doing-business-over-whatsapp-are-you) - -* [四个数字解释了 Facebook 为什么收购 WhatsApp](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) - -* [马克·扎克伯格的公告](https://www.facebook.com/zuck/posts/10101272463589561?stream_ref=10) - -* [带有 Mochiweb 的百万用户彗星应用程序，第 3 部分](http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3) - -* [Erlang 内部，WhatsApp 成功背后的罕见编程语言](http://www.fastcolabs.com/3026758/inside-erlang-the-rare-programming-language-behind-whatsapps-success) - -* [Facebook 的扎克伯格说，WhatsApp 的价值实际上超过 19B 美元，并且是 Internet.org 达成了交易](http://techcrunch.com/2014/02/24/whatsapp-is-actually-worth-more-than-19b-says-facebooks-zuckerberg/) - -* [Facebook 以 190 亿美元收购 Whatsapp：价值与定价观点](http://aswathdamodaran.blogspot.in/2014/02/facebook-buys-whatsapp-for-19-billion.html) - -* [Facebook 的 190 亿美元渴望，马克·扎克伯格（Mark Zuckerberg）解释](http://www.forbes.com/sites/georgeanders/2014/02/19/facebook-justifies-19-billion-by-awe-at-whatsapp-growth/) - -* [恕我直言：从 WhatsApp 汲取的教训](http://blog.mindcrime-ilab.de/2012/12/16/imho-lessons-learned-from-whatsapp/) - -* [您可能不会使用 WhatsApp，但世界其他地区肯定会使用](http://www.wired.com/wiredenterprise/2014/02/whatsapp-rules-rest-world/) - -* [WhatsApp 的故事挑战了山谷的一些传统智慧](http://techcrunch.com/2014/02/23/the-whatsapp-story-challenges-the-valleys-conventional-wisdom/) - -* [根据 Jan Koum（视频）的说法，WhatsApp 做了正确的事](http://recode.net/2014/02/20/what-whatsapp-did-right-according-to-jan-koum-video/) - -* [Facebook 为什么要购买 WhatsApp？](http://kottke.org/14/02/why-did-facebook-buy-whatsapp) - -* [有人可以向我解释 WhatsApp 的估值吗？](http://www.linkedin.com/today/post/article/20140220134541-79695780-can-someone-explain-whatsapp-s-valuation-to-me) - -* [Google 对 WhatsApp 的不寻常出价](https://www.theinformation.com/Google-s-Unusual-Offer-to-WhatsApp) 。 - -我理解正确吗？ WS 正在一台唯一的服务器上运行？ 真？ 那简直是疯了，O_o 正常，它总是掉下来... - -伊凡，你是怎么得出这个结论的？ -是从哪儿说的？ - -> 数百个节点 -> > 8000 个内核 -> 数百兆字节的 RAM - -谢谢！ 这是我今年（2014 年）阅读的最好的，最有趣，最令人鼓舞和最具挑战性的文章之一。 我喜欢看到其他人所做的既平凡（或使复杂的平凡）又令人惊奇。 我的团队将继续使用 Java，但是看到另一个团队不仅在财务上如此成功，而且能够满足数亿用户的需求是令人鼓舞的。 太棒了！ 谢谢！ - -800 万资金是错误的。 他们筹集了大约六千万。 - -yowsup 在这里可用：https：//github.com/nprasan/yowsup - -我赞同 Kevin 的评论-一篇非常出色的文章。 实际上在 1 篇文章中有 3 篇很棒的文章：移动应用程序市场分析，深入的技术探讨，一般课程。 非常感谢！ 会在这里上班... - -您说：“尽管就个人而言，所需的所有调优和修补工作都对该主张造成了一些怀疑。” 这种怀疑似乎基于 Erlang / OTP 静止不动的假设，而事实上一段时间前 WhatsApp 的 Erlang / OTP 补丁已被并入 Erlang / OTP 中。 Erlang / OTP 是开源的，社区补丁很常见，爱立信的 OTP 团队在社区的帮助下继续在功能，性能和可伸缩性方面推动平台向前发展。 我相信 WhatsApp 最初是在 Erlang / OTP 的 R14B 版本上开发补丁的，但是下个月（2014 年 3 月），OTP 团队将发布 17.0 版，再次达到了每年生产 Erlang / OTP 的新主要版本的正常时间表。 - -很棒的帖子！ -时间过长 - -到目前为止，我几个月来读的最好的文章。 -做得好，可扩展性高。 - -首先，很棒的文章。 whatsapp 的工程设计以及他们对细节的关注给我留下了深刻的印象。 拥有内部外观很酷。 - -但是，对于涉及“ 200 万个 TCP 连接”的测试，我感到困惑。 我不清楚这到底是什么意思。 我的理解是，无效的 TCP 连接理论上只需要 R​​AM，而对 CPU 或带宽的影响很小。 - -如果是这样，我很难怀疑该基准所达到的目标。 在大多数情况下，RAM 不是限制因素吗？ 我不清楚 Erlang 在这里有什么特别的帮助，或者说 200 万个连接测试的实际含义是，CPU 和带宽是否应该处于闲置状态。 在演示文稿中，听起来好像 CPU 的使用率为 85％，但我不清楚 CPU 的实际功能。 谁能启发我？ - -优秀的文章。 - -谈到隐私，“邮件未存储在服务器上” +* [关于黑客新闻](http://news.ycombinator.com/item?id=5129530) +* [Duck Duck 在 Twitter 上转到](https://twitter.com/duckduckgo) +* [2009 Duck Duck Go Architecture](http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-architecture.html) （ [Hacker News](http://news.ycombinator.com/item?id=525048) ） +* [2011 架构更新](http://help.duckduckgo.com/customer/portal/articles/216392-architecture) +* [DuckDuckGo 过去用光了我的地下室](http://www.gabrielweinberg.com/blog/2011/12/duckduckgo-used-to-run-out-of-my-basement.html) +* [用 Perl 编写的 Duck Duck Go](http://news.ycombinator.com/item?id=1500487) +* [用 Bucardo 复制 PostgreSQL](http://www.gabrielweinberg.com/blog/2011/05/replicating-postgresql-with-bucardo.html) +* [PostgreSQL 技巧和窍门](http://www.gabrielweinberg.com/blog/2011/05/postgresql.html) +* [nginx JSON 骇客](http://www.gabrielweinberg.com/blog/2011/07/nginx-json-hacks.html) +* [我是我自己经营的搜索引擎（Duck Duck Go）的创始人，AMA](http://www.reddit.com/r/IAmA/comments/bbqw7/i_am_the_founder_of_a_search_engine_duck_duck_go/) +* [DuckDuckGo 爆炸](http://news.ycombinator.com/item?id=3770958) -关于 DDG 流量增加的黑客新闻讨论 +* [Gabriel Weinberg 的博客](http://www.gabrielweinberg.com/blog/) -在创业公司和其他主题上经常要说的有趣的事情 +* Tech Spot [DuckDuckGo 创始人加布里埃尔·温伯格的访谈](http://www.techspot.com/article/559-gabriel-weinberg-interview/) +* [DuckDuckGo 创始人加布里埃尔·温伯格（Gabriel Weinberg）谈论创建更多私有搜索引擎](http://techland.time.com/2012/03/23/duckduckgo-founder-gabriel-weinberg-talks-about-creating-a-more-private-search-engine/) +* [在搜索引擎中隐藏 Google](http://articles.washingtonpost.com/2012-11-09/business/35505935_1_duckduckgo-search-engine-search-results) +* [没有目标广告的 Google 的免费跟踪替代品](http://www.heavychef.com/search-engines-a-track-free-alternative-to-google-with-no-targeted-ads/) +* [Duck Duck Go 开源](https://github.com/duckduckgo/duckduckgo/wiki) -DDG 是封闭源，但具有一些开放源代码组件 +* [DataSift 架构：每秒 120,000 条推特的实时数据挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) +* [Google 和搜索的未来：阿米特·辛格（Amit Singhal）和知识图](http://m.guardiannews.com/technology/2013/jan/19/google-search-knowledge-graph-singhal-interview) +* [DuckDuckGo 可以挑战在位搜索冠军吗？](http://www.business2community.com/seo/can-duckduckgo-challenge-the-reigning-champions-of-search-0382883) -不对 +@Gabriel Weinberg： +好的帖子。 谢谢！ :) +为什么不将 Rout 53 用于全局 DNS？ 我认为它的区域比 Global Traffic Director 多，不是吗？ -至少，视频和 img 消息将发送到服务器，然后进行压缩，然后转发给您的联系人。 -如果 whatsapp 在此之后将其删除，我相信这取决于 NSA。 +这肯定是一篇精彩的文章！ 大量和合成。 深入了解 DDG 使我意识到每个方面都有多么复杂。 -很棒的文章！ 感谢您分享。 +首先，我已经进行了 6 个月的测试，最后才恢复使用 Mountain View 的功能。 用英语使用 DDG 通常是准确的，但是以我的语言（法语）显示的结果不够可靠。 现在，我了解到，映射和合并数十个源以及它们的元数据，实时翻译所有内容都是一项艰巨的任务。 -优秀的文章...！ 感谢分享。 +然后，让我将“一个投诉用户**认为**太快”改成“加布里埃尔，请到欧洲旅行，每次搜索都享受±.5s-±.8s 的时间。我认为亚马逊的网络速度更快（ 好吧，考虑到我当地的 Amazon 商店的性能），但是一天要进行±50 次搜索，有时我不得不重新输入“！g < search >”，以便在非常简单的搜索（例如商店名称， 知名品牌或艺术家）。 -绝对惊人的文章！ 我喜欢它，每一行，每一句话！！！ +最后，几乎没有与法语查询相关的广告。 这非常舒适，但我想还不能使收入最大化。 -伟大的伟大伟大的职位。 我在 2009 年从事类似项目的工作，我知道所有这些技术讲座，并且帖子中的细节非常详尽。 我非常感谢作为技术部分的商业观点和经验教训...很好的结论。 -值得花时间阅读。 谢谢。 +我希望 DDG 能够在所有语言和所有大洲不断进步，并且我会不时检查... -不要相信会告诉您的人会花费 30 台主机打开足够的 IP 端口来生成足够的连接来测试具有一百万个并发连接的服务器。 这是完全错误的，并且仅仅是对知识缺失的证明。 ;） +感谢您的采访！ -已收藏。 这是非常棒的信息，感谢您的分享， +感谢您的文章。 它们用于离线数据处理？ -由于不熟悉此类工程的尖端人员，这是一本有趣的文章。 -谁能回答一个愚蠢的问题？ +很棒的文章！ 对您为什么选择 Ubuntu 而不是 AWS 中提供的其他免费 Linux 操作系统有任何见解？ 例如，Fedora，OpenSUSE，Amazon Linux？ -我很欣赏从单个服务器中获得如此高的效率必然需要大量的工作，这是一项巨大的成就，但是为什么这样的消息传递应用程序原则上会带来巨大的可扩展性挑战？ 为什么最小数量的服务器很重要？ 在我的手机上看到自己的小 WhatsApp 气泡时，我经常只与约 20 个人联系，很少能以每小时 4 个以上的速度进行完整的对话。 -因此，如果我不得不从视觉上代表整个网络，我会猜想有很多自然的分区，而不是像 bittorrent 这样的大规模且不可预测的互连。 并不是说这将是一个小的编程任务，但是原则上，通用框架不能通过遵循然后预测用户的自然分区来将连接分配给服务器。 例如。 我和我的伦敦哥们都乱伦，与圣保罗的交通突然中断为零。 +很生气的 DDG 不支持 IPv6。 bing，yahoo 和 google 支持 IPv6。...DDG 向后。 -因此，一旦最佳地分配了连接，服务器之间的剩余最小流量就不会成为问题-尤其是当您看到我突然尝试与 Sao Paolo 进行实时聊天时，您将我们切换到同一台服务器进行一次 。 +Gabriel-您愿意在 Lucene / Solr Revoltuion 上发表有关 DDG 如何使用 Solr 的论文吗？ 我很肯定社区会很感兴趣。 Lucene / Solr Revolution 将于 4 月底在圣地亚哥举行。 我们已经将您的博客发布到 SearchHub.org 上，这是所有 Lucene / Solr 的地方。 -我不是在问为什么 WhatsApp 没有尝试构建这种复杂的东西，而是我是否对社交网络连接的预测分区的 Hadoop 需求未得到满足是正确的？ （是的，我意识到这比 hadoop 要复杂得多） +theipv6guy： -当客户端收到消息后，消息将被删除，这听起来很完美，但是如果出现群发消息怎么办？ 它会一直持续到小组的所有成员都收到吗？ +就我而言，就 IPv6 而言，这是一些相当有力的评论。 DuckDuckGo 使用 AWS，仅在某些产品上支持 IPv6。 正如我希望 DDG 赶上潮流一样，我不怪他们没有转换托管服务提供商，甚至只是在一切面前 shoe 脚 Akamai 或双栈 ELB。 -不错的文章。 让您欣赏系统的复杂性，并像 Whatsapp 一样被我们视为日常用户。 +您应该将怒火引向亚马逊。 -嘿，这是很酷的文章。 +（不过，是否在其 Linode 上启用了 IPv6？：D） -我有一个问题，我还没有完全明白。 那么，客户端建立的每个套接字连接都将在一个单独的过程中结束吗？ 如果是这样，那么服务器如何创建一百万个：/进程中的消息队列如何一次可能达到 20 万条消息？ +很棒的帖子，谢谢。 有关我所遇到的问题和我没有遇到的问题的许多详细信息。 -谢谢 +优秀的文章。 我不了解所有技术，但细节令人着迷。 -Facebook 没有购买 Whatsapp 的建筑，而是购买了 10 亿以上的昏迷用户 \ No newline at end of file +很难击败 Google。 干净利落。 \ No newline at end of file diff --git a/docs/112.md b/docs/112.md index 7130f03..6bfc17b 100644 --- a/docs/112.md +++ b/docs/112.md @@ -1,149 +1,31 @@ -# AOL.com 体系结构如何发展到 99.999％的可用性，每天 800 万的访问者和每秒 200,000 个请求 +# SongPop 在 GAE 上可扩展至 100 万活跃用户，表明 PaaS 未通过 -> 原文： [http://highscalability.com/blog/2014/2/17/how-the-aolcom-architecture-evolved-to-99999-availability-8.html](http://highscalability.com/blog/2014/2/17/how-the-aolcom-architecture-evolved-to-99999-availability-8.html) +> 原文： [http://highscalability.com/blog/2013/2/25/songpop-scales-to-1-million-active-users-on-gae-showing-paas.html](http://highscalability.com/blog/2013/2/25/songpop-scales-to-1-million-active-users-on-gae-showing-paas.html) -![](img/fcdd630ddc84ef7497d6c5ee8be15365.png) +![](img/4831f5897791fb0ce4c74a47a1d343de.png) -*这是 AOL 的 [Dave Hagler](http://www.linkedin.com/in/hagler) 系统架构师的特邀帖子。* +您应该在下一个项目中使用 PaaS 吗？ 通常，答案是“否”，因为您想要控制，但这是 [SongPop](http://www.songpop.fm/) 中的一个示例，显示了为什么 PaaS 的承诺没有通过。 SongPop 能够自动扩展到 6000 万用户，100 万每日活跃用户，每天在全球范围内提供 17 TB 的歌曲和图像，每秒处理 10k +次查询，所有这些都由 6 人的工程团队组成，并且只有一名工程师全职工作 后端。 -AOL 主页每天收到超过 **800 万名访客**。 与《美国早安》或电视上的《今日秀》相比，每天的观看者更多。 每月提供的网页浏览量超过十亿。 自 1996 年以来，AOL.com 一直是主要的互联网目的地，并且仍然拥有大量忠实用户。 +不幸的是，这里并没有很多细节，但是可以在[通过 App Engine 和 Google Cloud Storage](http://googleappengine.blogspot.com/2013/02/scaling-songpop-to-60-million-users.html) 将 SongPop 扩展到 6000 万用户中找到。 大纲遵循脚本。 你从小开始。 让 PaaS 做繁重的工作。 而当您需要扩展时，您只需购买更多资源并进行一些调整（也许很多）。 收获是，您可以专注于功能开发，并且可以与一个小型团队合作。 -**AOL.com 的架构是第 5 代**。 在过去的 20 年中，它已经从头开始进行了 5 次重建。 当前的体系结构是 6 年前设计的。 零件已升级，并在此过程中添加了新组件，但总体设计仍保持完整。 经过 6 年的持续改进，对代码，工具，开发和部署过程进行了高度调整，使 AOL.com 体系结构经过了测试，并且非常稳定。 +这是他们的体系结构图： -工程团队由开发人员，测试人员和运营人员组成，**总共约有 25 人**。 大多数人在弗吉尼亚州的杜勒斯，在爱尔兰的都柏林有一个较小的团队。 +![](img/1ab5b01808e0961190f9d2178e03350f.png) -通常，使用的技术是 **Java，JavaServer Pages，Tomcat，Apache，CentOS，Git，Jenkins，Selenium 和 jQuery** 。 在该堆栈之外还使用了其他一些技术，但是这些是主要组件。 +一些经验教训： -## 设计原则 +* **首要支持。** 这听起来有点像销售推销，但是一旦他们的每日活跃用户达到 10 万，他们就开设了“高级支持”帐户，从而使他们可以与现实生活中的人交谈并快速解决停机问题。 +* **使**归一化。 为了减少就绪延迟，他们将跨多个模型散布的数据收集到一个实体中。 老歌，但仍然是一个巨大的胜利。 +* **缓存**。 为了减少查询，将用户的反对者列表缓存到 memcache 中，这是 GAE 的功能。 这个和非规范化更改花费了一名工程师 4 天的时间。 +* **截止日期**。 一旦操作的性能超过阈值，就该回落到另一个更可预测的策略了。 +* **综合索引**。 查询速度很慢，其原因可追溯到正在使用的许多索引属性。 解决方案是使用复合索引或将数据合并到单个实体中。 借助 Premier Support 的帮助可以追溯到此问题，Premier Support 也显示了 PaaS 的弱点，程序员不应该找到这些问题吗？ 也许查询日志很慢？ +* **易于与其他服务**集成。 亚马逊和谷歌等公司的一个优势是，他们可以创建功能强大的协作服务套件。 由于 SongPop 需要每天在世界范围内消费和分发 17 TB 的歌曲和图像，因此他们发现 Google Cloud Storage 价格合理，并且可以从 GAE 轻松使用。 而且，当您想做一些 BigData 时，已经内置了 Google BigQuery。 设计要点。 +* **位置标头**。 GAE 请求会自动包含标头，这些标头包含基于客户端请求的 IP 地址的位置信息。 SongPop 使用此信息选择对手并建立个人资料。 +* **同步模拟游戏。** Song Pop 使用的一种有意义的策略是[同步模拟游戏](http://uncrunched.com/2012/06/22/980/)。 可扩展的，一致的，低延迟的游戏很难，那么为什么要那么做呢？ SongPop 所做的是录制游戏，然后在您玩游戏时与您对战。 您似乎是在和一个真实的人比赛，但是没有一个讨厌的工程挑战。 您只需要存储声音片段和游戏结果，将玩家匹配到游戏，然后答复游戏即可。 相当聪明。 -有一些重要的总体原则可以驱动体系结构。 首先，所有都有**冗余。 即使出现故障或需要维修时，仍然存在冗余。 要求有 5 个 9 的可用性，每年大约需要 5 分钟的停机时间。** +显然，这是您的标准 Facebook 风格游戏，因此它不是复杂的应用程序，但将其包含在体系结构决策矩阵中是一个很好的存在证明。 -第二个原则是 AOL.com **不应依赖任何共享基础结构**来传递其页面。 如果其他 AOL 属性或系统出现故障，则 AOL.com 需要保持正常运行。 一段历史：在开发此体系结构时，大多数 AOL Web 属性只有一个共享的基础架构，称为 Big Bowl，这是一个反复出现的问题，其中一个属性会影响其他属性。 结果，当前的 AOL.com 专门设计为通过隔离自身来解决此问题。 对 AOL.com 的任何依赖都以保护服务为前提，该保护服务将对下游系统的调用集中在较小的服务器上。 下游系统没有从数千个服务器接收请求，而是从大约 20 个不同的服务器获得呼叫。 并且响应被缓存以进一步防止不堪重负。 此外，外部数据库被复制以提供给 AOL.com 自己的副本，并由其自己的运营团队进行管理。 关于唯一共享的组件是网络和身份验证服务。 +## 相关架构 -另一个原理是**缓存用于优化性能，但不是系统以**规模运行的要求。 该基础结构的大小可在不进行缓存的情况下承受全部流量，同时仍可确保足够的冗余度以容忍中断。 缓存是一种奖励，但不是必需的。 - -## 物理基础架构 - -在 3 个数据中心中为 AOL.com 服务。 其中两个位于北弗吉尼亚州，一个位于加利福尼亚州，均由 AOL 拥有和运营。 所有 3 个数据中心都在积极地为流量提供服务，但是每个数据中心的大小都使其能够自行处理全部流量。 这样可以使一个数据中心脱机以进行维护，并且在发生故障的情况下仍具有冗余数据中心。 - -收到请求后， **Akamai GSLB 处理整个数据中心**的负载平衡，并将用户定向到最近的一个。 Akamai CDN 用于静态内容。 一旦进入数据中心，对服务或数据库的任何进一步请求将保留在该数据中心内。 用户会话信息保存在 cookie 中，并在请求中传递，因此任何服务器都可以为任何请求提供服务而不会保留任何状态。 - -![](img/405b9912b048be40b59c33cdc6de1e1b.png) - -在每个数据中心内，Netscaler 设备接收**请求并将其负载均衡到许多前端应用程序服务器**之一。 所有数据中心大约有 **700 个前端服务器。 前端是虚拟服务器，操作员可以根据需要通过扩展其他服务器来快速增加容量。 前端的虚拟主机分别配置有 2 个虚拟 CPU，4GB RAM 和 80GB 磁盘空间。 每个前端服务器都运行 Apache 和 Tomcat 的单个实例。 Apache 将请求传递给在本地主机上运行的 Tomcat。 **Tomcat 处理大量请求**，调用数据库和服务，并执行所有应用程序逻辑。** - -## 流量 - -AOL.com 的访问量出人意料地可预测，遵循与互联网使用情况类似的模式。 重大世界事件将导致峰值，但否则模式将非常一致。 - -每天的流量从凌晨 3 点到 6 点是最低的，直到上午 10 点才急剧增加，**大约以 200,000 次点击/秒的速度徘徊 7 小时**，然后在下午 5 点之后开始下降。 每天重复相同的周期。 - -![](img/2d8a3b3966866cfb64f4511c53152938.png) - -在工作日中，到 AOL.com 的流量比周末高。 每周中没有一个特定的工作日始终高于其他工作日。 换句话说，星期一与星期二或星期五没有什么不同。 但是周末总是比工作日低。 - -![](img/8b1027eb76bddcc988a96f30d2290e3c.png) - -流量分布在 3 个数据中心的 2,000 台前端服务器中。 东海岸的两个数据中心分别接收约 40％的流量**，而 20％的流量到达西海岸**。 分布不均是因为 Akamai 将用户路由到最近的数据中心，并且在美国东部地区有更多的最终用户。 此外，流向国际站点 aol.ca，aol.co.uk，aol.fr，aol.de 的流量都流向美国的东海岸数据中心。 - -## 监控 - -AOL 数据中心（包括 AOL.com）中运行的所有应用程序均由自主开发的工具监视**，该工具已开发了多年，其功能类似于 Amazon 的 CloudWatch。 硬件和软件指标可以实时收集和汇总。 客户端应用程序提供报告，图形和仪表板。 提供了主机，CPU，接口，网络设备，文件系统，Web 流量，响应代码，响应时间，应用程序度量标准和其他信息。 每分钟检查一次服务器端点，并在未达到可用性和响应时间的某些阈值时发出警报。** - -![](img/170b823bf1899c1b28782495f8d38030.png) - -## 内容管理系统 - -AOL.com 的大部分内容以及很多业务逻辑都来自**内容管理系统**。 CMS 是基于相同的 **Java / JSP 技术堆栈**构建的本地应用程序。 它具有除典型 CMS 之外的许多功能。 编辑者使用它来创建您在 AOL.com 上看到的内容。 开发人员使用它来配置应用程序。 它还是一个指标仪表板，供编辑人员提供有关页面上每个内容的性能如何的实时数据。 - -AOL 主页不仅仅是一个页面，而且位于单个域 www.aol.com。 它实际上由相同内容的数十个不同版本组成，它们在不同的域上，可能有许多可见或细微的差异。 CMS 允许在一个地方对主页的这些不同版本进行编程，并从层次结构中的多个父级继承特定版本的内容。 版本之间的差异可以很简单，例如页面上的不同品牌徽标，不同的跟踪 ID，或者某些或全部内容可以完全不同。 例如，用作美国主页（www.aol.com）的 AOL.com 版本可能与加拿大版本（aol.ca）不同，而加拿大版本可能与移动版本（m.aol。）不同。 com）。 还有供合作伙伴使用的品牌版本，例如 Verizon 的移动门户。 - -![](img/3b81271e9d2c67779494b4317543f820.png) - -这样，**内容会滴入**，从而消除了对大量手动复制内容的需要。 以仅与美国站点相关的突发新闻事件为例。 编辑人员将在“美国”部分对突发新闻进行编程，并将其编入所有从美国继承的网站。 如果由于某种原因突发新闻仅针对 Verizon 门户，则编辑者可以在该级别进行编程，并将其下放到各个 Verizon 站点。 - -在将 **推广给更广泛的受众**之前，我们**测试每个功能以查看其性能。 为了方便测试，CMS 中内置了一个多变量测试工具，该工具允许任意数量的测试单元并行运行。 我们会不断测试不同的内容和设计元素，以优化体验。 定义为访问量百分比的测试受众将获得该网站的其他版本。 将用户随机放入测试单元中，并使用浏览器 cookie 进行跟踪。 测试可能是按钮颜色的微小外观变化，可能是内容的不同布局，也可能是完全不同的体验。 在应用结果之前，测试通常会运行数周。** - -## 数据库 - -AOL.com 上的内容是高度动态的，并且需要访问数据库并为每个页面视图应用规则。 除了您在页面上看到的标记外，CMS 还包含许多规则和条件内容。 例如，如果您使用的是较旧的浏览器，则可能在页面顶部看到“浏览器升级”标语。 因此，CMS 数据库需要快速，能够处理极端流量突发并且始终可用。 我们正在运行 **MySQL 5** ，并且与虚拟化的前端服务器不同，**数据库服务器更大，具有 16 个 CPU 和额外磁盘空间的物理主机**。 - -CMS 数据库有 **30 个从属副本，每个数据中心**中有 10 个。 单个主服务器位于其中一个数据中心，而备用主服务器位于同一数据中心中，以防发生故障。 除了主服务器和从属服务器之外，每个数据中心中都有一个与主服务器进行复制的中继器，并且该中继器在其数据中心中充当从属服务器的主服务器。 中继器的目的是减少跨数据中心的复制流量。 发生故障时，每个数据中心中都有一个备用转发器。 如果主主机及其备份发生故障，则将其中一个转发器指定为新主机。 - -应用程序**通过 HTTP 接口**访问数据库。 AOL 开发了一个 apache 模块，用作 MySQL 的接口。 每个数据库主机上都有一个安装有模块的 Web 服务器。 管理员管理与其数据库的连接池，将 sql 查询作为 GET 请求，然后以 XML 格式返回结果。 对于 AOL.com 之类的 Java 应用程序，有一个 Java 客户端库可将 HTTP 调用和 XML 解析抽象为类型化的对象。 - -HTTP 数据库接口有多个原因。 首先，它使客户端的数据库访问更加简单。 任何使用任何编程语言的应用程序都可以进行 HTTP 调用，而无需担心 MySQL 客户端驱动程序或连接池。 其次，扩展应用程序也很容易。 应用程序通过单个 URL（指向负载均衡器虚拟 IP 地址的 URL）访问数据库。 添加新的从属服务器后，客户端应用程序无需将其添加到其配置中。 HTTP 接口的另一个好处是用于监视。 标准的 Web 服务器访问日志和监视工具可以提供数据库事务量，查询响应时间和错误。 整个 SQL 查询都作为参数包含在 URL 中，因此可以轻松地在日志中使用。 apache 模块中还内置了一个管理界面，可以从任何 Web 浏览器获取数据库诊断信息。 - -## 缓存 - -在体系结构中，有几个区域使用了缓存。 CMS 中有**个二级缓存。 首先，访问数据的 CMS Java 代码利用内存缓存。 由于**的内容在 CMS 中的每个内容都是**版本，并且从未更新过，而是一个新版本，因此可以轻松地缓存数据以减少对数据库的查找。 这种类型的缓存位于 Tomcat 实例级别，每个 700 个实例均保留其自己的缓存。** - -但是仍然需要为每个页面加载检查数据库，以查看是否有新的内容修订版。 这会转化为许多数据库查询，通常结果相同。 由于我们的数据库查询全部由 HTTP 接口通过前面描述的 apache mod 代理，因此我们可以使用 Varnish Cache 轻松地**缓存请求。 数据库查询是简单的 HTTP GET 请求，URL 中带有完整的 SQL 查询，因此 Varnish 可以很好地工作，从而大大减少了到数据库服务器的流量。** - -**Akamai CDN 用于缓存所有静态资产**。 除了静态资产缓存之外，Akamai 还每隔几分钟就会缓存一个精简的 AOL.com 静态版本。 当所有数据中心均无法访问时，这是灾难情况下很少使用的后备。 用户将直接从 Akamai 获取缓存的页面，直到实际页面重新联机。 - -缓存的最终区域在 AOL.com **前端 JSP 代码**中。 前端的工作是从 CMS 收集大量的小片段内容，并将它们组装成 HTML 页面。 我们开发了一个 JSP 标记库，使开发人员可以在页面上缓存任何组合的 HTML 块。 例如，要指定要缓存的页面部分，请用< cache：cache > < / cache：cache >包围它。 - -![](img/f88580f3eef6b3cc4afdcf5a59615af9.png) - -## 开发流程 - -对于需要更改编码的主要功能，开发团队会松懈地遵循 **Scrum 流程**。 冲刺通常需要 3 到 4 周，具体取决于业务承诺。 有时，可能同时处理多个 Sprint，例如某个功能需要花费 4 个多星期的开发时间。 - -仅通过 CMS 发布即可完成许多**网站更改，而无需构建或代码部署过程。 这些是经常发生的事件，它们作为非周期过程处理，请求通过电子邮件列表发送给团队。 这些更改全天部署，每天变化范围从几到十几个或更多。 这些更改的周转时间为几分钟到几天。** - -开发**小组每周轮换一个 iPhone，以作为应用程序随时待命**。 触发应用程序级别监视时，应用程序呼叫会收到警报。 例如，来自下游系统的数据可能已停止流动。 对于最终用户而言，这不会造成明显的问题，因为在这种情况下会有冗余和适度的后备，但是它会在问题变得严重之前主动发出警告。 除了应用程序待命之外，运营团队还可以待命以解决网络，主机和数据库问题。 有明确定义的上报途径和团队来处理任何情况。 - -开发人员**在其本地环境**中工作。 大多数使用 Macbook Pro 笔记本电脑和 Netbeans 或 Eclipse。 在开发过程中使用了 6 种非生产环境。 所有环境都与生产环境匹配相同的配置，但规模较小。 有 2 个 Dev Integration，4 个 QA 和 1 个 Staging 环境。 多个 QA 环境对于同时支持 2 个 sprint 以及必要时的生产修复都必不可少。 通常，在任何给定时间仅使用 1 或 2 个 QA 环境。 国际版本也有单独的 Dev，QA 和 Staging，它们分别运行同一代码库的单独实例来服务 aol.co.uk，aol.fr 和 aol.de。 - -在安装新代码之前， **QA 流程相当严格**。 这些年来，已经建立了许多回归测试，不仅有大量的自动化测试，而且还有许多手动测试。 硒用于自动化测试。 有一个自定义的屏幕截图工具，可以快速捕获各种浏览器/操作系统组合中的页面外观。 与典型的网站相比，AOL 使用较旧系统的用户更多，而我们的回归测试套件则包括 IE7，AOL 桌面浏览器以及模拟缓慢的 Internet 连接。 我们还测试了浏览器/操作系统/设备组合的广泛矩阵。 在装有 Windows 7 的 IE9 上看起来有些不错，但在装有 Windows XP 的 IE9 上却坏了。 它增加了很多额外的时间来对浏览器和操作系统的所有排列进行站点回归测试，但是事实证明，多年来，它是必要的。 Windows XP 和旧版 IE 构成了最大的问题。 AOL.com 倾向于在这些较旧的系统上吸引更多用户，因此我们会更加注意它。 - -完整的安装过程从开始到结束大约需要 2 个小时，整个开发团队都在听电话会议。 当流量最低时，安装通常在美国东部时间上午 6 点完成。 在安装过程中，站点或 CMS 不会停机。 即使大多数安装步骤都是脚本化的，但每个步骤都由操作员单独运行并在执行过程中进行验证。 在生产安装的前一天，在登台环境中练习了整个安装过程和脚本。 备份数据库后，将部署并验证各种组件。 - -更新网站的一个挑战是 CDN 交付的 CSS，图像和 Javascript 会缓存在浏览器中。 这样，用户可能会遇到糟糕的体验，直到缓存的元素过期为止。 我们遵循消除此问题的过程。 首先，将新的**静态内容推送到新版本路径**下的 CDN，从而使旧资产和新资产均可用。 接下来，将生产环境中运行的旧代码配置为指向新资产。 为了使它起作用，我们确保所有静态内容都向后兼容。 一旦有新资产可用，就将新代码部署到前端 Tomcat 服务器。 对于每台服务器安装，Apache 都会停止运行，这会告诉负载平衡器停止旋转并停止发送流量。 然后停止 Tomcat，安装新代码，重新启动 Tomcat，最后重新启动 Apache，这触发负载均衡器开始发送流量。 **使用 AOL 基于 RPM 软件包**定制开发的部署系统，通常需要 20 到 30 分钟才能在所有数据中心（总共超过 2000 台服务器）中部署新代码。 - -## 来回回顾 - -AOL.com 的技术堆栈已经成熟并且运行良好。 就像任何使用 6 年以上的系统一样，如果我们今天才开始，我们可能不会做出相同的选择。 Java / Tomcat / JSP 已被 Web 应用程序的 Python 和 PHP 取代。 Nginx 的性能可能优于 Apache，并且出现了 NoSQL 数据库。 许多这些技术已在 AOL 的其他领域中使用。 这是成功软件系统的经典难题。 相同的健壮功能使当今的体系结构如此灵活和可靠，这使得利用新技术变得困难。 - -但是我们在此过程中做出了一些有影响力的更改。 仅举几个例子，包括从物理主机到虚拟主机的转换。 添加清漆缓存； 并将 Jenkins 引入构建过程。 我们正在对前端 HTML 和 CSS 进行完全重写，以清理大量旧代码并促进响应性设计，而这几年前还没有考虑过。 我们的道路仍然是发展体系结构，在合理的时候重建零件并适应行业不断变化的需求。 - -感谢您提供非常有趣的信息:-) - -我感觉合理。 简单，无聊且有效。 同样，虽然有人将 Java 称为新的 COBOL，但这并不总是一件坏事-许多语言设计使其能够很好地处理 5 年未修改的代码的维护工作，这对于像这样的大型项目来说是一个重大问题。 - -即使它是免费的，在系统重写后，任何问题所涉及的风险似乎也超过了任何财务收益。 - -像将其作为寻呼机一样旋转物理 iPhone 似乎有些愚蠢。 也许你们可能想研究一下 PagerDuty 这样的更好的解决方案。 - -做得好！ - -确实很有趣，有很多好处。 我真的很喜欢这篇文章。 谢谢戴夫。 - -鉴于该站点全天仅执行 8 毫米操作，因此每秒 200k 次的命中率似乎太高了。 在这段时间内，按照 200k /秒的文章进行 8 个小时的数学运算，将获得 84MM 的点击。 所以有些事了。 - -@EJ-200,000 次命中/秒是对前端服务器的所有请求。 对该页面的访问会产生许多服务器调用，因为在后台还会发生其他 ajax 调用。 另外，其他 AOL 属性正在使用 api，这些 api 会导致访问前端服务器的流量，但不会注册用户访问。 - -@ EJ 每天有 800 万访客，相对于每秒 20 万页面请求。 它没有详细介绍每个用户获得多少页面请求。 - -戴夫，感谢您花费时间和精力来教育我们所有人。 您参与设计的过程令人印象深刻，您的雇主也允许您提高人们的数字敏感性，这也说明了他们的数量。 - -嗨，戴夫， - -我希望您能透露更多有关您如何授权用户的信息。 您正在使用 cookie，并且有一些身份验证服务。 是否在每个请求（如果适用）上调用这些服务？ 解决方案是自家生产的吗？ - -我知道这个主题有点...嗯...很敏感，所以我会尽我所能。 - -谢谢 - -数据库设计更引人入胜。 有人知道我们是否也可以采用类似的设计进行交易处理吗？ - -很棒的文章，非常感谢。 -一件特别的事引起了我的注意，因为我们一直都在努力解决它： -“对于每台服务器安装，Apache 都停止了，这告诉负载均衡器使其停止旋转并停止发送流量。” - -为了将其从负载均衡器池中删除，Apache 实际上是否已停止运行？ 还是为了在停止 Apache 之前将其删除而做些什么？ -显然，仅停止 Apache，将导致所有活动用户断开连接。 -除非使用“平稳停止”？ - -Thanks \ No newline at end of file +* [通过 App Engine 和 Google Cloud Storage 将 SongPop 扩展到 6000 万用户](http://googleappengine.blogspot.com/2013/02/scaling-songpop-to-60-million-users.html) +* [Song Pop 每天吸引 200 万活跃用户，其中许多人可能在调情](http://techcrunch.com/2012/07/03/song-pop/) \ No newline at end of file diff --git a/docs/113.md b/docs/113.md index 383baea..b92edcd 100644 --- a/docs/113.md +++ b/docs/113.md @@ -1,43 +1,65 @@ -# 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧 +# Iron.io 从 Ruby 迁移到 Go：减少了 28 台服务器并避免了巨大的 Clusterf ** ks -> 原文： [http://highscalability.com/blog/2014/2/10/13-simple-tricks-for-scaling-python-and-django-with-apache-f.html](http://highscalability.com/blog/2014/2/10/13-simple-tricks-for-scaling-python-and-django-with-apache-f.html) +> 原文： [http://highscalability.com/blog/2013/3/13/ironio-moved-from-ruby-to-go-28-servers-cut-and-colossal-clu.html](http://highscalability.com/blog/2013/3/13/ironio-moved-from-ruby-to-go-28-servers-cut-and-colossal-clu.html) -![](img/8790837ab14b40922ff5236ee8cf66d7.png) [HackerEarth](http://www.hackerearth.com/) 是一项编码技能实践和测试服务，在一系列写得很好的文章中描述了构建站点的试验和磨难，以及它们如何克服它们：[使用以下方法扩展 Python / Django 应用程序： Apache 和 mod_wsgi](http://engineering.hackerearth.com/2013/11/21/scaling-python-django-application-apache-mod_wsgi/) ，[编程方面的挑战，正常运行时间和错误（2013 年）](http://engineering.hackerearth.com/2014/01/22/programming-challenges-uptime-mistakes/)，P [ ost-mortem：2014 年 1 月 25 日的大故障](http://engineering.hackerearth.com/2014/01/27/big-outage-25-january/)，[强大的实时服务器](http://engineering.hackerearth.com/2013/05/31/the-robust-realtime-server/) ， [100,000 个强大的 CodeFactory 服务器](http://engineering.hackerearth.com/2013/03/12/100000-strong/)，[具有 Django 和 HAProxy 的扩展数据库](http://engineering.hackerearth.com/2013/10/07/scaling-database-with-django-and-haproxy/)，[连续部署系统](http://engineering.hackerearth.com/2013/08/05/continuous-deployment-system/)， [HackerEarth 技术堆栈](http://engineering.hackerearth.com/2013/03/20/hackerearth-technology-stack/)。 +![](img/60fa20df9697ae26cfa43f92f27f70a6.png) -这些文章的特征并使其特别有用，是对改进的驱动力和对报告哪些无效以及如何确定哪些有效的开放态度。 +在过去的几个月中，我一直在使用 Go 编写系统程序，因此我一直在寻找信息以补充我的确认偏见。 当 Iron.io 用 Go 重写他们原来忙于工作的作业执行系统 IronWorker 时，Iron.io 写下了他们的[经验，这时机会突然出现，最初是用 Ruby 编码的。](http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html) -正如他们所说的那样，当您仅由 3-4 名工程师组成的团队来构建复杂的产品时，就会发生错误，但是对基础架构的投资使他们可以进行更多的休息，在班加罗尔的街道上漫游，而他们的服务器每分钟很高兴地为成千上万的请求提供服务 ，同时轻松达到 50,000 个用户群。 +结果： -这是他们做事的方式： +* 从 30 台服务器降至 2 台，第二台服务器仅用于冗余。 +* CPU 利用率降至 5％以下。 +* 内存使用率下降。 只有“几百 KB 的内存（在启动时）与我们的 Rails 应用程序（约 50 MB）（在启动时）”。 +* 级联故障现在已成为过去。 +* 在数百台服务器上运行的新服务全部用 Go 编写。 +* 他们相信使用 Go 可以使他们“制造出色的产品，成长和扩展并吸引 A 级人才。而且我相信它将继续帮助我们在可预见的未来发展。” 通常，建议根据人才库的规模选择一种语言，他们发现选择 Go 语言可以帮助他们吸引顶尖人才。 +* 部署很容易，因为 Go 可以编译为一个静态映像。 +* Go 的次要缺点：学习新语言和有限的库。 +* 对于将获得大量流量的服务器以及要为突然增长做好准备的服务器，Go 是一个不错的选择。 -**HackerEarth 的当前体系结构：**前端服务器； API 服务器； 代码检查器服务器； 搜索服务器-Apache Solr &弹性搜索； 实时服务器-使用 Tornado 编写； 状态服务器； 工具链服务器（主要用于持续部署）； 集成测试服务器； 日志服务器； Memcached 服务器； 很少有服务器可以处理数据分析数据库和后台作业。 RabbitMQ，Celery 等粘合许多服务器； 监控服务器； 数据库经过分片并通过 HAProxy 进行负载平衡。 +当然，不受第二系统效果影响的重写速度可能要快得多，但您可能还记得，LinkedIn 也有类似的经历： [LinkedIn 从 Rails 迁移到节点：27 台服务器被削减，速度提高了 20 倍](http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html) -1. **删除不必要的 Apache 模块**。 节省内存并提高性能。 通过只包含您需要的内容，您可以将加载的模块数量减少一半。 -2. **使用 Apache MPM（多处理模块）工作者**。 通常，对于高流量服务器来说，这是一个更好的选择，因为它比前叉 MPM 占用的内存少。 -3. **保持活动状态**。 CloudFront 提供了静态文件，实验表明，这样做效率更高，进程/线程可以自由地即时处理新请求，而不必等待请求到达较旧的连接。 -4. **mod_wsgi** 的守护程序模式。 线程和进程的数量是恒定的，这可以使资源消耗可预测，并防止流量高峰。 -5. **调整 mpm-worker 配置**。 他们在经过大量试验后显示了他们使用的配置，这有利于他们的应用程序类型，这种类型的应用程序比 CPU 占用更多的内存。 -6. **检查配置**。 启用模块 mod_status.so 和 mod_info.so 以查看 Apache 的运行方式。 这些信息帮助他们大大减少了我们必须运行的服务器数量，并使应用程序更稳定，更能抵抗流量突发。 -7. **不会自动缩放**。 100％的正常运行时间是不断的斗争。 卷起袖子，朝着这个目标努力。 -8. **不要为运行 100 台服务器**而感到自豪。 编写更好的代码并调整系统。 向大量请求抛出服务器并不引以为豪。 例如，这意味着确保请求不会查询数据库 20 次。 -9. **异步代码检查器服务器排队系统**。 重写代码检查器服务器排队系统以使其异步，从而大大减少了其前端服务器上的处理开销。 -10. **使用龙卷风进行认真的平行作业**。 “ socket.io”模块无法扩展到超过 150 个同时连接。 Nowjs 还泄漏了文件描述符。 -11. **分片数据库和数据库路由器**。 对数据库进行分片可减少单个数据库的开销，并进一步减少查询延迟。 -12. **缓存它**。 在内存缓存中有超过一百万个键值对，会话以 redis 维护，其他任何持久性数据都进入 MySQL 或 S3，但是大多数缓存都保留了适当的生命周期。 -13. **持续部署**。 手动更新生产中的代码更改会使他们发疯，这将完全浪费时间。 +这是 Go 问题解决的解释： -我实际上很喜欢这篇文章，但是请不要开始使用链接诱饵标题。 我通常会忽略带有此类标题的内容，直到我意识到它具有高可伸缩性，我几乎跳过了这一标题。 +* 使用 Ruby，持续的服务器 CPU 使用率介于 50％和 60％之间。 添加服务器以将 CPU 使用率保持在 50％，以便可以正常处理流量高峰。 这种方法的缺点是需要水平扩展昂贵的服务器。 +* 他们有一个非常有趣的失败模式。 当流量激增时，Rails 服务器将达到 100％CPU。 这导致服务器出现故障，这导致负载均衡器将流量路由到其余服务器，这导致更多服务器的 CPU 使用率达到 100％。 最终结果是级联失败。 -确实。 这不是一些愚蠢的嗡嗡声。这些文章的内容并不保证会被贬低为“＃X 的简单技巧”标题。 +使用 Ruby 的上市时间论点很有道理。 性能并不是一切，但在这里我们看到了性能的价值，尤其是在 Web 层之外。 优质的服务是鲁棒性和成本上的双赢。 -实际上，我尝试了各种各样的内容。 有些长，有些短。 一些原始的，一些其他的。 如果您感兴趣的话，有些则精心策划了其他细节，有些则是独立的。 有些是针对初学者的，有些是针对专家的。 一些非常具体，一些非常笼统。 +通常，弱点被数量掩盖，数量昂贵且并不总是有效。 -因此，任何一篇帖子都可能不是您的事，但这并不意味着它不会成为某人的事。 +性能起到缓冲的作用，使系统能够吸收流量而不会中断，而在打卡机打孔后又能承受打卡机的冲击。 即时分配，拆分新实例需要花费时间，时间足够长，以至于流量峰值可能会导致级联故障。 通过为性能而不是上市时间进行编码，可以防止这些问题的发生。 -项目符号格式是传达特定想法的最快方法。 这些想法可能对许多人来说都是旧帽子，或者是新的有趣的东西。 如果有兴趣，您可以参阅参考的源材料以获取更多详细信息，这正是这个主意。 否则，您可以继续前进，这确实是个主意。 +## 去并不完美 -我认为前两个评论仅表示他们不喜欢标题，因为它看起来像是个骗人的把戏。 但正如他们也指出的那样，您的文章始终都是出色的，这就是为什么继续阅读它的原因。 +如果您查看 Go 的 Google 小组，Go 并非没有[性能问题](https://groups.google.com/forum/?fromgroups#!searchin/golang-nuts/performance$20problem)。 这些问题通常可以被编码。 例如，使用 bufio.ReadSlice 而不是 bufio.ReadString 可以删除数据副本，神奇的是您的代码快了 X 倍。 -确实，内容没有问题。 只是 linkbait 的头衔（不公正地）。 +学习这些技巧需要时间，尤其是使用这种新语言时。 -jpj，完全是。 :) \ No newline at end of file +Go 绝对处于劣势的地方是 JVM 和 V8 JavaScript Engine 多年来优化垃圾收集和代码生成的地方。 Go 可能需要一段时间才能赶上。 + +表演从来都不是免费的。 您必须编写聪明的代码。 最小化共享状态，不要浪费内存，不要像地狱那样配置文件，了解您的语言并通过它来做正确的事情。 + +## 相关文章 + +* [低级可伸缩性解决方案-条件收集](http://highscalability.com/blog/2013/3/11/low-level-scalability-solutions-the-conditioning-collection.html)-将工作盲目地排入队列并不总是最好的方法。 +* [规模甚大甚至赢不了-Google 和 Facebook 示例](http://highscalability.com/blog/2013/2/11/at-scale-even-little-wins-pay-off-big-google-and-facebook-ex.html) +* [Google：驯服长时延的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) +* [黑客新闻](https://news.ycombinator.com/item?id=5365096)的原始文章 +* [发生了什么](http://jmoiron.net/blog/whats-going-on/)-现代语言中的 Hash 成瘾探索 +* [分析 Go 程序](http://blog.golang.org/2011/06/profiling-go-programs.html) + +为什么去？ 为什么不选择 Erlang？ + +Go 与这个故事无关。 根本原因是 Ruby。 当 Ruby 消失并被任何工业语言（可能是 Java，C＃或任何经过验证的语言）取代时，问题也就消失了。 + +对于那些决定迁移到 Go 的用户，有[高度优化的库用于进程内缓存](https://github.com/valyala/ybc/tree/master/bindings/go/ybc)，[快速 Memcache 客户端库](https://github.com/valyala/ybc/tree/master/libs/go/memcache)和[为 SSD](https://github.com/valyala/ybc/tree/master/apps/go/memcached) 优化的 Memcache 服务器，全部以 走 ：） + +仍然不知道您的问题是来自红宝石还是铁轨 + +为什么不使用 Python？ + +Waaat？ 从解释代码移至编译代码，并且性能得到改善？！ 这些“工程师”一定是天才！！！ + +它们从 30 台服务器减少到 2 台服务器，这一事实证明了 Ruby 最初的选择是多么的糟糕。 但是现在他们正在转向 Go-一种更加晦涩的语言？ 这使我怀疑他们是否考虑了客户的需求，或者他们是否只是想炫耀自己在最新技术方面的优势。 \ No newline at end of file diff --git a/docs/114.md b/docs/114.md index ead81ff..1278e22 100644 --- a/docs/114.md +++ b/docs/114.md @@ -1,304 +1,102 @@ -# Google 如何备份 Internet 和数十亿字节的其他数据 +# 可汗学院支票簿每月在 GAE 上扩展至 600 万用户 -> 原文： [http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html) +> 原文： [http://highscalability.com/blog/2013/4/1/khan-academy-checkbook-scaling-to-6-million-users-a-month-on.html](http://highscalability.com/blog/2013/4/1/khan-academy-checkbook-scaling-to-6-million-users-a-month-on.html) -![](img/e618cf11a7e558cbccc35dc3c895b625.png) + -[Raymond Blum](https://plus.google.com/115038404694487056892/posts?hl=en) 领导了一组站点可靠性工程师，负责对 Google 的数据保密并确保其安全。 当然，Google 永远不会说这实际上有多少数据，但是从评论看来，它还不是 [约字节](http://en.wikipedia.org/wiki/Yottabyte) ，但很多 [艾字节](http://en.wikipedia.org/wiki/Exabyte) 大小。 仅 GMail 就要处理近几十亿字节的数据。 +[可汗学院](https://www.khanacademy.org/) 是由 [Salman Khan](https://www.khanacademy.org/talks-and-interviews/key-media-pieces/v/salman-khan-talk-at-ted-2011--from-ted-com) 创立的一家非营利性公司，其目标是向所有人，任何地方，任何时间提供免费的世界一流的教育。 那是很多知识。 长期以来，我受汗学院的启发和迷住，我真的很想知道他们打算如何去做。 [可汗学院的首席开发人员 Ben Kamens](https://twitter.com/kamens) 在一次采访中给出了令人惊讶的答案：[如何将您的初创企业扩展到数百万的用户](http://www.youtube.com/watch?v=r7hC0oVPTVs)。 -Blum 先生在视频中 [Google 如何备份互联网](http://www.youtube.com/watch?v=eNliOm9NtCM) 解释了常见的备份策略不适用于 Google 原因：通常他们以容量 扩展规模 **。 如果备份两倍的数据需要两倍的工作量（时间，精力，空间等），那么它将无法正常工作，并且无法扩展。 您必须找到效率，以便容量可以比支持该容量所需的努力更快地扩展。 从备份一个 EB 备份到备份两个 EB 时，需要一个不同的计划。 谈论主要是关于 Google 如何做到这一点。** +**简短答案**：组建一支强大的团队，专注于功能，让 [Google App Engine](https://appengine.google.com/) 负责。 -演讲的一些主要主题： +在采访中，有些人似乎被 GAE 的全部爱拒之门外。 部分原因在于，面试官是 Google App Engine 的开发倡导者 Fred Sauer，因此两者之间有一定程度的熟悉度。 但是最大的原因是，由于您应该喜欢 GAE 的所有原因，他们真的很喜欢 GAE。 没关系。 在这个时代，您可以自由选择任何平台。 -* **从来没有数据丢失** 。 即使是臭名昭著的 GMail 中断也没有丢失数据，但是故事远不只是大量的磁带备份而复杂。 从整个堆栈中检索数据，这需要在各个层面（包括人员）进行工程设计。 +**最大的惊喜**： -* **备份无用**。 这是您关心的还原。 这是一个还原系统，而不是备份系统。 备份是您为还原的奢侈而支付的一种税。 将工作转移到备份上，并根据需要使其变得复杂，以使还原如此简单，一只猫就可以做到。 +* “ 60 分钟”上的个人资料所带来的访问量比 TechChrunch，HackerNews 和其他所有内容的总和还多。 旧媒体还没有死。 -* **您无法线性缩放**。 您无法拥有 100 倍的数据或 100 倍的人员或机器资源。 寻找力的乘数。 自动化是提高利用率和效率的主要方法。 +第一部分**最喜欢**： -* **冗余**。 Google 的东西总是失败。 废话 人体细胞死亡的方式相同。 Google 并不梦想事情不会消亡。 它计划。 +* GAE 是所有典型可扩展性问题的抽象，让您专注于业务问题。 所有 [抽象泄漏](http://www.joelonsoftware.com/articles/LeakyAbstractions.html) ，无论您选择什么，都将不得不处理问题，但是您正在选择要处理的问题类型 根据您选择的平台。 这全都在于了解您要进行的权衡。 -* **所有事物的多样性** 。 如果您担心站点的位置，请将数据放在多个站点中。 如果您担心用户错误，请与用户交互隔离。 如果要防止软件错误，请把它放在其他软件上。 将东西存储在不同的供应商设备上，以减少大的供应商错误影响。 +以下是我对访谈的主要要点： -* **将人类带出循环** 。 GMail 保留多少电子邮件副本？ 这不是人类应该关心的事情。 一些参数是由 GMail 配置的，系统会处理。 这是一个不变的主题。 制定了高级策略，系统也这样做了。 如果发生超出规范的事情，只会打扰到人。 +* 汗学院（Khan Academy）每月大约有 600 万用户，也许是 1500 万注册用户。 为了进行比较，Coursera [共有 600 万用户](http://news.illinois.edu/ii/12/1115/coursera_daphne_koller.html) ，但我不确定这些用户的活跃程度。 -* **证明** 。 如果您不尝试，将无法使用。 不断测试备份和还原，以验证它们是否有效。 +* 演变： -对于任何规模的组织，这里都有很多值得学习的地方。 布拉姆先生的 [演讲](http://www.youtube.com/watch?v=eNliOm9NtCM) 具有娱乐性，内容丰富，值得一看。 他似乎确实很喜欢工作中的挑战。 + * 最初，创建了视频以支持学习如何解决数学问题。 这些视频托管在 YouTube 上。 YouTube 没有扩展问题。 -这是我对这个非常有趣的演讲的掩饰，我们从野兽内部学习了许多秘密： + * 但是 YouTube 不是交互式的，他们要做的很大一部分是向用户展示学习树，进行测验，管理结果等。因此，他们首先尝试了一个基于 Java 的自托管网站，但该网站被压碎了。 加载。 -* **数据可用性必须为 100％ 。** **从来没有数据丢失**。 + * 然后切换到 GAE。 可汗学院与许多初创公司不同，因为它已经在 YouTube 上建立了一个现成的受众群体。 数十万用户从 YouTube 切换到 GAE。 他们缓慢地建立了可以处理新用户的非 YouTube 网站的基础。 在 YouTube 上引导客户可能是一个不错的一般策略。 - * 从统计上讲，如果您从 2GB 的文件中丢失了 200K，这听起来不错，但是该文件现在可能已无用，请考虑执行文件或纳税申报单。 + * 有很多新闻报道，整个事情如雪球般滚滚，而且还在不断增长。 - * 数据的可用性对访问的可用性更为重要。 如果系统出现故障，那不是世界末日。 如果数据丢失，那就是。 +* 为什么选择 GAE？ - * Google 保证在所有可能的组合中为您提供以下所有服务： + * 对于任何一家初创公司来说，不要使用 GAE 或 EC2 之类的提供商都是没有道理的。 它们有助于解决许多您不需要解决的可伸缩性问题。 轻而易举。 如果您吸引了很多注意力，则可以立即投入更多资金并扩大规模。 - * 位置隔离 + * Spectrum：您想要开箱即用的控制权与可伸缩性的要求是多少？ 控制得越多，您越有可能朝自己的脚开枪，做错事。 - * 与应用层问题的隔离 + * GAE 为您提供了开箱即用的可扩展性。 只要插入信用卡，就不会有很多可扩展性问题。 这为我提出了一个要点：他们如何负担 GAE？ 有趣的是，非营利性经济学可以使人们摆脱对每个新客户获取成本的关注，而不必担心货币化策略。 - * 与存储层问题的隔离 + * 使用 AWS，您必须更多地玩游戏，知道如何处理实例，这需要花费更多时间。 - * 与媒体故障隔离 + * 他们不携带传呼机，不用担心复制，不需要重启实例，也不需要应用操作系统补丁。 他们与 GAE 并不需要做很多事情。 - * **考虑可以在** 上移动滑块的尺寸。 将软件垂直放置，水平放置。 如果要涵盖所有内容，则需要在不同位置复制该软件层。 您可以在不同位置的 VM 上执行此操作。 + * Khan Academy 的暑期实习生 Dylan Vassallo 参与了多个 App Engine 项目，并在 Hacker News 主题 中发表了出色的评论 [像 GAE：我是可汗学院的暑期实习生，从事各种 App Engine 项目。 我没有根据的猜测是我们是该平台的大客户之一。 GAE 最大的缺点之一就是缺乏控制：与 EC2 不同，在 EC2 中，您需要根据自己的需要来模制原始的 Linux 安装，而您的应用程序必须始终符合 GAE 的服务模型。 但是，通过放弃其中一些自由，您会得到很多很棒的回报。 可汗学院（Khan Academy）已成功利用 App Engine 扩展到数百万用户，而无需雇用一个系统管理员或花费太多时间担心与操作相关的任何事情。 我们能够毫不费力地应对流量高峰，例如 60 分钟的外观和新计算机科学课程的发布（http://khanacademy.org/cs）。 要部署站点，任何开发人员（或我们友好的 CI 机器人）都可以简单地运行我们的“ deploy.py”并等待几分钟，然后回到花时间在产品上。 我们不必再考虑数据库是否可以处理我们向其抛出的写负载。 就此而言，App Engine 数据存储区是独一无二的无后顾之忧。 （嗯，我敢肯定 Google SRE 对此非常担心，但我们不必这样做。）](about:blank) -* **冗余与可恢复性** 不同。 +* 为什么旧媒体仍然有意义。 与 60 分钟驱动的流量相比，来自 TechCrunch，HackerNews 等的所有流量都不算什么。 差远了。 - * 多份复印无助于达到无损保证。 + * 他们知道他们将获得大量流量，因此他们准备好转弯右拨盘，以快速启动新实例。 这就是他们所做的一切。 这是一个错误。 - * 许多副本对某些类型的中断有效。 如果小行星撞击数据中心，并且您的副本很远，您就会被覆盖。 + * 他们最终为这些新用户做了很多不必要的工作。 他们需要简化体验。 例如，他们认为对于所有这些新流量来说，这将是运行该平台的好时机，这是第一次使用其新的测试基础架构来跟踪所有这些美味数据的 A / B 测试。 失败了 - * 如果存储堆栈中有错误，则复制到 N 个位置无济于事，因为该错误会损坏所有副本。 以 GMail 中断为例。 + * 只要确保主要体验干净整洁。 如果您必须跟踪数据，请确保它非常重要，并使用经过良好测试的数据跟踪解决方案。 - * 小行星的数量不及代码错误，用户错误或缓冲区写入错误。 + * 不要一次增加流量运行新代码。 您只会得到一次。 如果有一半的国家因为您试图跟踪太多数据而无法访问该网站，那么这是不值得的。 - * 冗余有利于参考位置。 当您希望所有数据引用都尽可能靠近使用数据的位置时，复制就很好。 + * 他们现在要做的是使主页尽可能静态，简单，快速地加载，如果您分支出主页，则可以获得完整的体验。 简化传入流量。 -* **整个系统非常强大，因为其中有很多**。 +* 没有进行足够的负载测试。 60 分钟带来了很多流量，并且没有经过测试。 但是它们具有一致的高流量负载，当不同时区的用户上线时，流量每天都会激增。 交通也是季节性的。 他们通过自然流量模式获得了很多有用的压力测试。 他们必须处理高峰，低谷，人流量少的月份，然后人流量大的时候。 因此，他们知道必须在 GAE 中配置其代码才能处理该峰值。 - * **Google 内容始终失败**。 废话 人体细胞死亡的方式相同。 我们没有梦想事情不会消亡。 我们为它计划。 机器一直死掉。 +* 将您的工作尽可能多地转移给其他人。 他们适合哪个 GAE。 巨大的胜利。 在有 9 名或 10 名员工的情况下，他们认为不再需要解决性能问题，并希望下一次能够解决问题。 他们将人们奉献给表演。 他们建立仪表板以提前预测问题。 试图更加积极地关注性能和可伸缩性问题。 - * **冗余就是答案** 。 总的来说，结果比一台高质量机器更可靠。 一架机器可以被小行星摧毁。 放置在 50 个不同位置的机器更难销毁。 +* 2 至 5 人的小组不关注可扩展性问题。 专注于功能。 使您的产品很棒。 让人们回到它。 成功开展业务后，您就可以对所有想要的东西进行过度设计。 当您有机会构建成功的产品时，请担心问题。 -* **大规模并行系统有更多的损失机会** 。 +* 绩效是每个人的工作，每个人都被分配给它。 尝试在整个团队中建立对绩效的总体意识。 - * 可以在 30K 台计算机上运行的 MapReduce 非常棒，直到出现错误为止。 您有相同的错误等待立即在任何地方运行，从而扩大了影响。 + * 您将遇到大获胜的性能问题，然后这是一个反复的较小的改进游戏，每次改进.25％，. 5％导致性能提高，因此这必须是每个人的工作。 人们不仅可以投入额外的 JavaScript 或进行新的数据库查询，还只会使您的网站运行缓慢。 -* **本地副本无法防止站点中断** 。 + * 他们有一个或两个人的团队专注于表现的宿舍。 可能是性能改进，也可能是工具，可以使他们更加了解性能。 - * 如果服务器机房中有洪灾，RAID 将无济于事。 +* 收集大量数据。 他们想向老师和其他人报告数据。 他们的旧数据存储系统无法汇总所有数据。 因此，他们致力于： - * 大约一年前，在整个 Google 上使用的 Google 文件系统（GFS）将 RAID 的概念提升了一个档次。 使用 [编码技术](http://en.wikipedia.org/wiki/Erasure_code) 一次写入不同城市中的多个数据中心，因此您只需要 N-1 个片段即可重建数据。 因此，有了三个数据中心，一次就可以消亡，您仍然可以获得可用的数据。 + * 汇总数据 -* **可用性和完整性是组织范围内的特征** 。 + * 在写入上做更多的工作，因此读取速度很快。 重新配置数据。 复制到任何地方。 使其真正快速地进行以后的分析。 - * Google 工程师，BigTable，GFS，Colossus 都知道数据持久性和完整性是第一要务。 有很多系统可以检查和纠正数据可用性和完整性方面的任何失误。 + * 对于分析而言，它们似乎可能不在 GAE 范围内，但这并未具体说明。 -* **您想要所有事物的多样性** 。 +* 在需求旺盛之前，请不要着迷于棘手的问题，例如即时重新配置功能。 - * 如果您担心站点的位置，请将数据放在多个站点中。 +* 它们足够小，每个人都应对 DevOps 负责，以保持系统正常运行。 将来，GAE 之外可能会有足够的系统，他们将拥有独立的团队，但目前还没有。 - * 如果您担心用户错误，请与用户交互隔离。 +* 在技术和产品上都使事情变得简单，直到您完全知道需要构建什么为止。 从长远来看，他们为解决问题和解决问题而构建的许多功能会导致真正的问题。 构建后很难将其关闭。 - * 如果要防止软件错误，请将其放在其他软件上。 将东西存储在不同的供应商设备上，以减少大的供应商错误影响。 - -* **用来备份内容的磁带确实非常好** 。 - - * **磁带很棒，因为它不是磁盘** 。 如果可以的话，他们会使用打孔卡。 - - * 想象一下您是否在 SATA 磁盘的设备驱动程序中存在错误。 磁带可以帮助您避免麻烦。 因为不同的媒体意味着不同的软件，所以它增加了您的多样性。 - - * 磁带容量遵循摩尔定律，因此尽管他们正在研究替代方案，但他们对磁带作为备份介质感到非常满意，但他们不会说它们是什么。 - - * 磁带已加密，这意味着邪恶力量很难从中获得有用的东西。 - -* **备份无用。 这是您关心的** 还原。 - - * 在有人需要数据之前先确定是否存在问题。 当您需要还原时，您确实需要它。 - - * **运行连续还原** 。 不断随机选择 5％的备份并还原它们以进行比较。 为什么？ 在数据丢失之前找出备份是否有效。 抓了很多问题。 - - * **运行自动比较** 。 由于原件已更改，因此无法与原件进行比较。 因此，对所有内容进行校验和并比较校验和。 将其返回到源介质，磁盘或闪存，或它来自何处。 确保数据可以往返。 这一直都在做。 - -* **出现故障率变化的警报** 。 - - * **如果有所不同，您可能想了解一下** 。 如果一切正常，请不要告诉我。 - - * 可能会出现一些故障，但不要针对第一次尝试后无法还原的文件发出警报。 - - * 假设第一次尝试的失败率通常是 N。第二次尝试的失败率是 Y。如果失败率发生变化，则说明出现了问题。 - -* **一切都破裂了** 。 - - * 磁盘一直损坏，但是您知道它发生的时间，因为您正在监视它。 - - * 使用磁带之前，您不知道它已损坏，直到尝试使用它为止。 磁带可以使用很长时间，但是您需要先对其进行测试。 - -* 磁带 上的 **[RAID4](http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_4) 。** - - * 不要只写一盘磁带。 它们是墨盒。 机器人可能会掉落它们，或者可能会产生一些磁通量。 不要碰碰运气 - - * 写入磁带 **时，告诉编写者保留数据** ，直到可以更改为止。 如果这样做，您就违反了合同。 - - * 建立 4 个完整的磁带，然后通过将所有内容异或来生成第 5 个代码带。 您可以丢失 5 盘磁带中的任何一盘并恢复数据。 - - * 现在告诉编写者他们可以更改源数据，因为数据已经将其移到了最终的物理位置，并且现在是冗余的。 - - * Google 备份的每一位数据都经过此过程。 - - * 一个月会丢失数百个磁带，但是由于这个过程，每月不会有数百个数据丢失案例。 - - * 如果丢失了一条磁带，则可以使用连续还原检测到该磁带，并使用同级磁带重建另一条磁带，一切正常。 在极少的情况下，如果两个磁带都损坏，则只有在磁带上的相同两个点都损坏的情况下，数据才会丢失，因此在磁带级进行重建。 - - * 由于这些技术，不会造成数据丢失。 这很昂贵，但这是做生意的成本。 - -* **备份是您为还原**所支付的奢侈税。 - - * **这是一个还原系统，而不是备份系统** 。 恢复是不可屏蔽的中断。 他们胜过一切。 恢复备份。 - - * 使备份变得复杂并且需要的时间很长。 使恢复尽可能快和自动。 - - * 恢复应该是愚蠢的，快速且简单的。 希望一只猫能够触发集中还原。 - - * 当您休息好或狗累了时，恢复可能会发生。 因此，您不希望人为因素决定还原服务数据副本是否成功。 你压力很大。 因此，在进行备份的所有时间中，所有工作和思考都要做。 - - * 大量系统以这种方式工作。 - - * 数据源可能必须能够存储一段时间（也许几天），然后才能保证已备份数据。 但是一旦备份，便可以快速还原和还原。 - - * 不再最有效地利用备份上的介质来加快还原速度。 花两个小时读磁带是不好的。 只写一半的磁带并并行读取它们，这样您就可以在一半的时间内取回数据。 - -* **秤是一个问题** 。 - - * 当您有 EB 级数据时，会有现实世界的限制。 如果您必须复制 10 EB，那么每天备份数据可能需要 10 周的时间。 - - * 在全球的数据中心中，您有几种选择。 您是否给每个站点近乎无限的备份能力？ 您是否按地区对所有备份进行群集？ 运送数据的带宽呢？ 您不需要带宽来赚钱吗？ - - * 查看相关费用。 有妥协。 并非每个站点都具有备份功能。 必须平衡网络上的可用容量。 您从哪里获得最大的收益。 例如，备份必须在站点 X 上进行，因为它具有带宽。 - -* **您无法线性缩放**。 - - * 不能只是说您想要更多的网络带宽和更多的磁带驱动器。 驱动器损坏，因此，如果驱动器数量为 10,000，则需要的操作员数量是驱动器数量的 10,000 倍。 您是否有 10,000 倍的装载台来放置磁带驱动器，直到卡车将其捡起。 这些都不是线性的。 - - * 尽管磁带库的数量增加了一个完整的数量级，但涉及的人数却没有 10 倍。 还有更多的数字，但远非线性增长。 - - * 例子是一个早期的预测，随着电话数量的增长，美国人口的 30％将被用作电话接线员。 他们看不到的是自动切换。 - -* **自动化所有** 。 - - * 调度是自动的。 如果您有一项服务，则说我有一个数据存储，并且每个 N 都需要一个副本，并且还原必须在 M 中进行。在内部，系统会做到这一点。 计划备份，运行还原测试以及运行完整性测试等。当检测到损坏的磁带时，将自动对其进行处理。 - - * 您作为人类没有看到任何这些。 您可能有一天会问平均多少磁带断裂。 否则，如果磁带损坏率从每天 100 条磁带更改为每天 300 条磁带，可能会发出警报。 但是在此之前，请不要告诉我每天是否有 100 盘磁带破损，如果这超出了正常范围。 - -* **人体不应参与稳态操作** 。 - - * 包装和运输驱动器仍然是人类的活动。 自动化的界面可以准备运输标签，获取 RMA 编号，检查包裹是否已外出，获得收据确认，以及是否发生这种情况，必须由人工干预。 - - * **库软件维护同样** 。 如果要进行固件更新，则不会有人在每个系统上运行并执行升级。 下载它。 让它推送到金丝雀图书馆。 让它进行测试。 让结果验证为准确。 然后将其推出。 没有人参与正常操作。 - -* **自动处理机器死亡** 。 - - * 机器每分钟死两次。 如果一台机器在使用 30,000 台机器的 MapReduce 工作中快要死了，请不要告诉我，只需处理并继续前进即可。 查找另一台机器，移动工作，然后重新启动。 - - * **如果存在依赖项，则安排等待时间**。 如果您等待太久，请告诉我。 您可以自己安排时间。 这是算法的工作，而不是人类的工作。 - -* **随着增长不断提高效率** 。 - - * 大大提高了利用率和效率。 不能有 100 倍的数据需要 100 倍的人员或机器资源。 - -* **2011 年的重大 GMail 中断和恢复** 。 关于 Google 如何删除数据并取回数据的故事。 - - * 在星期日的上午 10:31，他得到了一个页面，上面写着“ Holly Crap call xxx-xxxx”。 有关中断的更多信息 [此处](http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html) 。 - - * Gmail 的数据量已接近 EB。 磁带很多。 - - * 100％恢复。 可用性不是 100％。 在第一天或第二天还没有全部。 但是到了一段时期的尽头。 - - * 在复制发生的层中发生了一系列的错误和不幸。 是的，我们有三个相同的文件，但它们都是空的。 即使进行单元测试，系统测试和集成测试，错误也可以解决。 - - * 从磁带恢复。 大量工作。 这是恢复时间与规模有关的地方。 取回千兆字节可以在几毫秒到几秒钟内完成。 取回 200,000 个各个演出的收件箱将需要一段时间。 - - * 在欧洲唤醒了几个同事，因为他们比较新鲜。 分布式劳动力的优势。 - - * 已从许多磁带上还原了数据并进行了验证。 没花几个星期或几个月，只花了几天。 他们对此感到满意。 其他处于类似情况的公司花了一个月的时间才意识到他们无法取回数据。 已采取步骤来确保下一次该过程将更快。 - - * 一个磁带机需要 2 个小时才能读取。 磁带遍布各处。 否则，任何一个位置都将没有足够的能力来读取还原过程中涉及的所有磁带。 - - * 使用压缩和校验和，他们实际上不需要读取 200K 磁带。 - - * 从那时起，恢复流程已得到很大改善。 - -* **优先还原** 。 - - * 可以在保存更重要的数据（例如当前收件箱和发送的电子邮件）之后恢复已存档的数据。 - - * 一个月内没有被触摸过的帐户可以等待，直到更活跃的用户被首先还原。 - -* **备用系统被视为巨大的全球生物** 。 - - * 不想仅在纽约进行 GMail 备份，因为如果该数据中心增长或收缩，则备份需要适当扩展。 - - * 将备份视为一个巨大的全球跨越系统。 进行备份时，它可能完全位于其他位置。 - - * 必须在磁带所在的位置进行磁带还原。 但是在制作磁带之前，数据可能在纽约，而备份在俄勒冈州，因为那里有足够的存储空间。 位置隔离是自动处理的，不会告诉客户端其数据备份的位置。 - - * 容量可以移动。 只要具有全球容量并且网络可以支持它，磁带位于何处都没有关系。 - -* **您拥有的数据越多，保留它就越重要** 。 - - * 通常，越大的东西越重要。 Google 过去只是搜索。 现在是 Gmail，存储在驱动器，文档等中的东西。它既更大，也越来越重要。 - -* **拥有良好的基础架构** 。 - - * 可以使用通用的瑞士军刀真的很不错。 编写 MapReduce 时，他们可能从未想到过将其用于备份。 但是，如果没有 MapReduce，就不可能出现将其用于备份的想法。 - -* **缩放比例确实很重要，您无法拥有任何无法扩展的部分-软件，基础架构，硬件，流程-**。 - - * 您不能说我将在拥有操作人员的情况下部署更多的磁带机。 如果您要雇用两倍的人，您有两倍的停车位吗？ 自助餐厅的房间？ 洗手间？ 一切都必须扩大规模。 您将遇到一个瓶颈，它将阻止您。 - -* **证明** 。 - - * 不要将任何事情视为理所当然。 希望不是战略。 - - * 如果不尝试，将无法使用。 必须进行还原才能验证备份。 直到最后，您还没有证明任何东西。 这种态度发现了很多失败。 - -* **DRT。 灾难恢复测试** 。 - - * 每 N 个月就会发布一次灾难场景。 模拟组织各个级别的响应。 - - * 在灾难不带走任何损失的情况下，公司将如何生存？ 必须学会适应。 - - * 发现基础结构和物理安全方面的巨大漏洞。 - - * 想象一下，一个数据中心有一条通向它的道路，并且有卡车在路上装载着备用发电机的燃料。 路迷路了怎么办？ 最好有一条道路和另一家柴油燃料供应商。 - - * 确实有供应链冗余策略。 - -* **在不同时间点在不同位置的不同软件堆栈中的冗余** 。 - - * **不要只让数据在堆栈中迁移** 。 将数据保留在堆栈的不同层中一段特定的驻留时间。 因此，如果您丢失了该数据，则此数据会重叠。 时间，位置和软件。 - - * 考虑 GMail 中断示例。 如果复制损坏了，怎么也不会丢失数据？ 这是听众提出的问题，他真的不想透露细节。 数据一直在备份。 假设我们有截至 9PM 的数据。 假设损坏发生在晚上 8 点，但尚未录制到磁带上。 腐败被制止了。 软件已回滚到工作版本。 在堆栈中的某个时刻，所有数据仍然存在。 磁带上有东西。 有东西正在复制。 前端有东西。 日志中有东西。 所有这些来源都有重叠之处，有可能重建所有数据。 对于这种情况，政策是直到将数据放入另一个堆栈中 N 个小时后，才从一个卡住的数据中取出数据。 - -* **删除问题** 。 - - * 我要删除它。 不会为了删除数据而重写磁带。 大规模而言太昂贵了。 - - * 一种方法是对加密密钥进行智能处理。 他没有告诉我们 Google 做什么。 也许丢失了有效删除数据的密钥？ - -* **当您信任同事并分担责任时，一个庞大的组织就可以工作。** 。 - - * 相信他们了解自己的部分。 - - * 确保组织和软件接口定义正确。 在各层之间实施验证测试。 - -* **白名单和黑名单**。 - - * 确保数据位于保证的位置，并保证不在某个位置，这与其余的哲学原理（即位置多样性和位置独立性）背道而驰。 - - * 最初不是堆栈的功能。 必须添加以支持政府要求。 - - * 在堆栈中将责任降低得越低越好。 填写正确的个人资料，它就会神奇地发生。 +* 懒惰。 使用其他人的工具。 在您的企业表现出色之前，请不要害怕使用他人的工作。 ## 相关文章 -* [在 Reddit 上](http://www.reddit.com/r/programming/comments/1wzsmk/how_google_backs_up_the_internet_along_with/) - -“如果您想对软件错误进行“保护”，那么？？？ - -嘿托德， - -这是一个令人难以置信的帖子，其中包含许多有用的信息，非常感谢您将其组合在一起！ - -嘿， - -我想知道更多有关 Google 备份的内容。 是完整的档案备份，以便保存在 google 中创建的每个文件，还是更多的滚动备份，其中删除了未使用的数据，仅备份了最近的几周。 - -另外，是 Google 对数据进行重复数据删除，还是每个用户的每个文件等等，都是单独保存的。 - -呵呵，所以安全是一个问题。 -这是我在网上找到的最佳信息之一，谢谢分享 \ No newline at end of file +* [Ben Kamens 博客](http://bjk5.com/) 中，关于可汗学院的话题很多。 非常可爱的狗。 他在 [亚马逊的 Mega Dropdown](http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown) 上写了一篇很棒的文章。 +* [GitHub 上的可汗学院](https://github.com/Khan) -他们的所有代码均为 [开源](https://khanacademy.kilnhg.com/) +* 如果 GAE 对您中的某些人来说太过分了，这是关于 [的好消息，有关 Google App Engine](https://news.ycombinator.com/item?id=4403739) 的隐藏成本 +* [我在可汗学院（Khan Academy）做过的事情](http://jamie-wong.com/2012/08/22/what-i-did-at-khan-academy/) -虽然视频内容很笼统，但这是关于团队所做工作的具体内容 +* Google Group for [Khan Academy Developers](https://groups.google.com/forum/?fromgroups#!forum/khanacademy-developers) +* [可汗学院使用 GAE / Bingo 进行的 A / B 测试课程](http://bjk5.com/post/28269263789/lessons-learned-a-b-testing-with-gae-bingo) +* [Khan Academy Docs](https://sites.google.com/a/khanacademy.org/forge/home) -很多果汁详细信息 +* [可汗学院使用 Google App Engine](https://cloud.google.com/files/KhanAcademy.pdf) 来扩展和简化 +* [有关可汗学院开发工作原理的大图片](http://www.brianbondy.com/blog/id/109/) [图](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions) +* [GAE 调整应用性能](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions) [调节](https://developers.google.com/appengine/docs/adminconsole/performancesettings) -您的旋钮，如果您知道 [如何调整它们](http://bjk5.com/post/40833194761/pending-queues-and-loading-requests-on-app-engine) 。 +* [第 1 部分：可汗学院首席开发人员 Ben Kamens 访谈](http://www.youtube.com/watch?v=BXxYEhwDh28) +* [访谈：可汗学院首席开发人员 Ben Kamens 回答了您的问题](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions) \ No newline at end of file diff --git a/docs/115.md b/docs/115.md index c472f72..ffd18c8 100644 --- a/docs/115.md +++ b/docs/115.md @@ -1,128 +1,62 @@ -# 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放，喜欢和更多内容 +# 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段 -> 原文： [http://highscalability.com/blog/2014/1/28/how-next-big-sound-tracks-over-a-trillion-song-plays-likes-a.html](http://highscalability.com/blog/2014/1/28/how-next-big-sound-tracks-over-a-trillion-song-plays-likes-a.html) +> 原文： [http://highscalability.com/blog/2013/4/10/check-yourself-before-you-wreck-yourself-avocados-5-early-st.html](http://highscalability.com/blog/2013/4/10/check-yourself-before-you-wreck-yourself-avocados-5-early-st.html) -![](img/7983a905c376ef6b7f410040a654d96a.png) +![](img/d02a7ba0dcd059b036ce353085ef0a44.png)在[中不要惊慌！ 这是如何快速扩展您的移动应用](http://venturebeat.com/2013/04/06/dont-panic-heres-how-to-quickly-scale-your-mobile-apps/)的方法。 [Mike Maelzer](http://www.linkedin.com/in/maelzer) 描绘了 [Avocado](https://avocado.io/) （一种用于连接情侣的移动应用程序）是如何发展的，可在几周内处理 30 倍的流量。 如果您只是入门，那么这是一个值得学习的好例子。 -*这是 Next Big Sound 的首席架构师 [Eric Czech](http://www.linkedin.com/profile/view?id=26317730) 的来宾帖子，讨论了解决音乐分析中可伸缩性挑战的一些独特方法。* +我喜欢的东西：写得很好，在一个很小的空间中包装了很多有用的信息； 它是由故障驱动的，显示了有目的的测试和生产经验所驱动的增量变化的过程； 它显示出对于重要的用户（对于他们而言）注册的意识； 使用副本设置进行测试，这是一个不错的云优势。 -跟踪在线活动并不是什么新主意，但是要在整个音乐行业中做到这一点并不容易。 每天有五十亿个音乐视频流，曲目下载和艺术家页面喜欢出现，并且衡量跨 Spotify，iTunes，YouTube，Facebook 等平台的所有活动的可能性带来了一些有趣的可扩展性挑战。 Next Big Sound 从一百多个来源收集此类数据，将所有内容标准化，并通过基于 Web 的分析平台提供该信息以记录唱片公司，乐队经理和艺术家。 +他们从中学到的最大的教训是一个很好的教训： -尽管我们的许多应用程序都使用诸如 Hadoop，HBase，Cassandra，Mongo，RabbitMQ 和 MySQL 之类的开源系统，但是我们的用法是相当标准的，但是我们这样做的一个方面是非常独特的。 我们从 100 多个来源收集或接收信息，我们很早就努力寻找一种方法来处理这些来源的数据随时间变化的方式，最终我们决定需要一个可以代表这些变化的数据存储解决方案。 基本上，我们需要能够以与使用修订控制（通过 Git）控制创建数据的代码几乎相同的方式对这些源中的数据进行“版本化”或“分支化”。 为此，我们在 Cloudera 发行版中添加了一个逻辑层，并将该层集成到 Apache Pig，HBase，Hive 和 HDFS 中之后，我们现在有了一个基本的版本控制框架，可用于 Hadoop 集群中的大量数据。 +> 最好早得多开始扩展过程。 由于时间紧迫，我们不得不做出让步-例如放下四个媒体缩放器盒。 虽然在某些扩展问题上投入更多的硬件确实可以，但是这并不理想。 -作为一种 [Moneyball for Music，](http://www.forbes.com/sites/zackomalleygreenburg/2013/02/13/moneyball-for-music-the-rise-of-next-big-sound/)“ Next Big Sound 已经从 MySpace 上的一台服务器 LAMP 站点跟踪播放（开始之初很酷）发展为少数艺术家，从而发展了整个行业[ 广告牌的流行度图表[以及在 Spotify](http://www.digitaltrends.com/social-media/billboard-social-networking-music-chart-debuts/) 上播放的每首歌曲的[摄取记录。 数据的增长速度已接近指数级，而分布式系统的早期采用对于保持数据的更新至关重要。 跟踪了来自公共和私有提供商的 100 多个来源，处理音乐分析的异质性需要一些新颖的解决方案，这些解决方案超出了现代分布式数据库免费提供的功能。](http://www.spotifyartists.com/spotify-next-big-sound-artist-analytics/) +这是我对这篇文章的介绍： -Next Big Sound 也已经在全云提供商（Slicehost），混合提供商（Rackspace）和托管（ [Zcolo](http://www.zayo.com/services/colocation) ）之间进行了过渡，而这些工作全部由小型工程人员使用，除了开放源码系统外什么也没有。 在这个过程中我们不乏经验教训，我们希望其他人可以从我们的成功和失败中汲取教训。 +## 进化一-使之工作 -## 统计信息 +刚开始时，您只想完成工作，无论完成多少。 您如何确定需要解决的问题？ Avacodo 所做的是有目的地测试他们的软件，寻找弱点，修复它们，然后进行迭代。 一个非常明智的增量过程。 您可能会想，为什么不跳到最终结果，但是那永远不会真正解决。 敏捷/精益思维的所有观点都有很多真理。 每个大型系统都是从较小的系统演变而来的。 -* 40 个节点 Hadoop 集群（150TB 容量），约 60 个 OpenStack 虚拟机 +* 第一个问题：您真的需要扩展吗？ 为什么要经历所有这些努力？ Avocado 正在促销中，他们希望带来更多的流量，而他们负担不起那些潜在的新用户带来的不良体验。 因此，必须应对大量的流量高峰。 +* 他们从典型的拥有每种功能设置的服务器开始：1 前端服务器（存储：API，Web 状态，socket.io，HAProxy，隧道/ SSL 加密）； 1 个 Redis 服务器; 1 个 MySQL 服务器； 1 个批处理服务器（正在运行其他守护程序）。 +* 复制测试设置用于运行常见的方案，例如帐户创建。 +* 在测试环境中使用较小的 EC2 实例可以节省资金，并且可以消除与资源相关的错误。 +* 使用 [jmeter](http://jmeter.apache.org/) 构建的测试脚本每分钟模拟成千上万的用户注册。 +* 测试旨在使用不同的场景来发现薄弱环节，例如添加第二台服务器并使用服务器上的所有 CPU。 +* 通过数千个同时注册来提高性能： + * 由于创建新的 Python 进程来发送电子邮件验证和调整个人资料图片的大小而导致的 CPU 高峰。 + * 所有这些都发生在一个盒子上。 + * 一些 MySQL 查询需要很长时间。 + * SSL 是主要的 CPU 负载 -* 10TB 的未复制压缩指标数据（原始 6TB，已索引 4TB） +## 进化二-测试驱动的变更 -* 10 名工程师，共 22 人 +根据测试结果，他们： -* 5 年的发展 +* 添加了一些数据库索引以加快访问速度。 创建表时，您是否不应该知道要添加哪些索引？ 这不是很明显吗？ 有时是，有时不是。 让您的数据库告诉您哪些缓慢的方法也适用，尤其是在游戏初期。 +* 重新编写电子邮件验证以使用 node.js 的异步功能，而不是每次都派生一个单独的 Python 进程。 吞吐量提高了 3 到 5 倍。 他们为什么首先使用 Python 方法？ 看来显然是浪费。 也许他们已经有了代码？ 也许他们知道如何用 Python 做到这一点？ 在较大的计算机上可能没有关系。 但这是明智的渐进式变化。 采取可行的措施，并在无法解决时进行修复。 尽管他们在这里仍然有巨大的失败漏洞。 如果进程终止，则用户注册状态机将停止。 +* SSL 已移至其自己的服务器。 同样，这很明显是一个问题，而更大的机器可能会成为一个问题，但是从一台机器上启动肯定更容易。 +* 对于促销，分配了四个新实例来调整图像大小。 晋升后将其删除。 处理预期流量高峰的好策略。 -* 每天 30 万次时序查询 +## 进化三-生产驱动型变化 -* 每天有 400G 新数据，处于峰值 +随着我们对生产经验的深入了解，我们可以看到问题的类型正在变为那些很难预测并且似乎只有修复的奇怪问题。 -* 为超过 100 万名艺术家录制了超过 1 万亿个事件，包括 YouTube 音乐视频观看次数（ [Kris Schroder 的 Google I / O 演讲](http://commondatastorage.googleapis.com/io-2013/presentations/1122%20-%20Find%20the%20next%20big%20thing%20with%20the%20YouTube%20Analytics%20API.pdf) [ [GNIP](http://gnip.com/sources/twitter/) ），iTunes 购买和在线广播流（通过[与 Spotify](http://www.spotifyartists.com/spotify-next-big-sound-artist-analytics/) 的合作伙伴关系） +* 在促销监视期间，警报提示响应时间较慢，因此添加了第二台前端服务器。 因此要进行监控。 最终添加了 15 台服务器。 +* 注意到在较大的 EC2 实例上，仅使用一个 CPU，node.js 是单处理器解决方案，并且 HAProxy 每个框仅路由到一个实例。 重新启动 HAProxy 以读取新配置以解决此问题花费了几秒钟，因此他们创建了冗余 HAProxy 服务器以减少停机时间。 +* ELB 用于将流量路由到两个 HAProxy 服务器并处理 SSL，从而减少了代理箱的数量并节省了资金。 +* 这导致 socket.io 出现多服务器问题，因为用户需要与一台服务器维护一个会话。 因此，他们参加了粘性会议，需要做一些棘手的更改。 +* 有趣的发现：Websockets 不能在所有的蜂窝网络上工作。 由于这是至关重要的移动应用程序。 另外，ELB 不支持 websocket。 因此他们使用了 XHR 轮询。 命运的惊人转折。 +* 将 Socket.io 移动到具有 8 个 socket.io 服务器（每个 CPU 一个）的自己的盒子中，总共有 16 个 socket.io 服务器实例。 +* 似乎很多套接字服务器。 为了减少数量，使用了数据库连接池。 最初，每个 socket.io 服务器都有一个数据库连接，该数据库连接将工作排队到数据库中，从而使 socket.io 使用了 8 个 CPU 中的 60％。 每个服务器实例使用 2 至 10 个数据库连接池将 CPU 使用率降至 3％，并显着缩短了响应时间。 +* 为什么不从一开始就使用连接池？ 这是很标准的。 他们没有，我感到很惊讶，但是会出现各种各样的问题，重点不是他们是哪个问题，而是您找到并解决这些问题。 -## 平台 +## 进化四-走向全球 -* **托管**：通过 [ZColo](http://www.zcolo.com/) 托管 +* 移动对夫妇遍布世界各地，因此他们也通过在全球范围内启动服务器进行调整，以指导亚马逊按时进行路由。 注意这有多疯狂。 一次国际发行本来是一笔大买卖。 现在，这只是您要做的另一件事。 +* 他们应该早些时候走向全球吗？ 毕竟，移动性能是应用的关键。 但这太疯狂了，您必须具有系统使用经验，然后才能前往多个位置。 -* **操作系统**：适用于 VM 和物理服务器的 Ubuntu 12.04 LTS +## 进化五-现在使它更好地工作 -* **虚拟化**：OpenStack（2 个 Dell R720 计算节点，96GB RAM，2 个 Intel 8 核 CPU，15K SAS 驱动器） +* 在处理了最初的促销任务，了解了其系统的工作原理并解决了问题之后，现在该考虑自动化和自动部署策略了。 慢慢来，这样您就可以一次担心一种问题。 从一开始就进行自动化将使事情变得非常复杂，因为您甚至在不知道应该如何工作的情况下尝试进行自动化。 更好的渐进式思维。 -* **服务器**：主要是 Dell R420、32GB RAM，4 个 1TB 7.2K SATA 数据驱动器，2 个 Intel 4 核 CPU - -* **部署**：詹金斯 - -* **Hadoop** ： [Cloudera（CDH 4.3.0）](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh.html) - -* **配置**：厨师 - -* **监控**：Nagios，神经节，Statsd +石墨， [Zenoss](http://www.zenoss.com/) ，[立方体](http://square.github.io/cube/)，[口红](http://techblog.netflix.com/2013/06/introducing-lipstick-on-apache-pig.html) - -* **数据库**：HBase，MySQL，MongoDB，Cassandra（最近放弃使用 HBase） - -* **语言**：PigLatin + Java 用于数据收集/集成，Python + R + SQL 用于数据分析，PHP（ [Codeigniter](http://ellislab.com/codeigniter) + [Slim](http://www.slimframework.com/) ），JavaScript（ [AngularJS](http://angularjs.org/) + [Backbone.js](http://backbonejs.org/) + [D3](http://d3js.org/) ） - -* **处理**：黑斑羚，猪，蜂巢， [Oozie](http://oozie.apache.org/) ， [RStudio](http://www.rstudio.com/ide/docs/server/configuration) - -* **联网**：瞻博网络（10Gig，带自动故障转移功能的冗余核心层，机架上有 1 个 Gig 访问交换机） - -## 存储体系结构 - -使用 Cassandra 和 HBase 等分布式系统存储时间序列数据相对简单，但是管理数据随时间变化的方式则要简单得多。 在 Next Big Sound，来自 100 多个源的数据聚合涉及某种传统的 Hadoop [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) 管道，其中原始数据通过 MapReduce 应用程序，Pig 或 Hive 处理，并将结果写入 HBase，以便以后通过[进行检索。 Finagle](http://twitter.github.io/finagle/) / [节俭](http://thrift.apache.org/)服务； 但有一个转折。 Hadoop / HBase 中存储的所有数据均由特殊的版本控制系统维护，该系统支持 ETL 结果随时间的变化，从而允许定义处理管道的代码中的变化与数据本身保持一致。 - -我们在 Hadoop 中管理数据的“版本”方法是对 [Linked.in 数据周期](http://data.linkedin.com/blog/2009/06/building-a-terabyte-scale-data-cycle-at-linkedin-with-hadoop-and-project-voldemort)中所用技术的扩展，其中 Hadoop 的结果将定期重复进行完全重新计算并自动替换 [Voldemort](http://www.project-voldemort.com/voldemort/) 中的旧结果集具有可恢复的版本控制。 我们系统的区别在于版本控制不仅发生在全局级别，还发生在许多可配置的更深层次上。 例如，这意味着，如果我们在 Twitter 上记录艺术家所在国家/地区的转推数，并且发现对推文位置进行地理编码的逻辑在几天内是错误的，那么我们只需创建新的数据版本即可 那些日子，而不是重建整个数据集。 现在，这些新版本中的每一个都将具有不同的值，并且可以将某些版本的访问权限限制为某些用户。 开发人员可能只会看到最新版本，而普通用户将看到旧版本，直到确认新数据正确为止。 像这样的“分支”数据对于跟上数据源和客户请求的变化以及支持有效的增量数据管道至关重要。 - -有关该系统的更多详细信息，此图描绘了上述一些关键差异。 - -[](https://dl.dropboxusercontent.com/u/65158725/hadoop_arch.png) - -有关更多详细信息，请查看 [论文：HBlocks：用于迭代数据工程的 Hadoop 子系统](https://dl.dropboxusercontent.com/u/65158725/hblocks.pdf) 。 - -除了 Hadoop 基础架构，我们还面临许多其他挑战。 跨社交网络和内容分发站点映射音乐行业中实体的关系，构建 Web 应用程序以对数百万个数据集进行排序/搜索，以及通过数百万个 API 调用和 Web 爬网管理信息收集，都需要专门的解决方案。 我们仅使用开源工具来完成所有这些工作，下面简要介绍了这些系统之间的相互关系。 - -[![](img/71a5dfef96b935acef0ce26a6451573f.png)](https://dl.dropboxusercontent.com/u/65158725/nbs_arch.png) - -* **数据表示**：我们的指标仪表板的构建一直是一个正在进行的项目，大部分都是由我们的客户指导的。 要在灵活性和学习曲线之间取得适当的平衡，是一个移动目标，其中有许多不同的数据集，并且维护一致的 JavaScript / PHP 代码库来管理这些代码，这对每个新客户和新功能都将变得更加困难。 以下是到目前为止我们如何处理的一些要点： - - 1. 从简单的 Codeigniter 应用开始，尝试尽可能多地整合 Backbone，现在（积极地）转向 Angular - 2. 大型静态对象的内存缓存（例如国家/地区与州之间的映射） - 3. 用于指标数据缓存和历史记录的本地存储（即，当您重新加载页面时，这就是我们之前所知道的方式） - 4. 用以前使用过的[人力车](http://code.shutterstock.com/rickshaw/)进行的 D3 绘制图形 - - 同样，我们对功能标志不做任何花哨的事情，但是我们不断地使用它们的基本实现。 在一直被重写的代码库中，它们一直是一个至关重要的（尽管有时是混乱的）常量，如果没有它们，我们将无法完成许多工作。 - -* **查找**：我们已投入巨资开发产品，使我们的用户能够根据多种标准在我们的数据中搜索有趣的歌手或歌曲（我们称其为“ “查找”产品）。 与音乐的股票筛选器类似，该产品可让用户按“在以前从未出现在某种流行度图表上的 YouTube 视频观看次数的 30％-40％范围内说唱艺术家”等条件过滤后对结果进行排序。 此基础结构的大部分驻留在 MongoDB 中，该位置由 MapReduce 作业提供索引丰富的集合，并在数百万个实体中提供近乎即时的搜索功能。 - - 在 MongoDB 上构建这种类型的产品效果很好，但是索引限制一直是一个问题。 我们目前正在探索更适合这种用例的系统，特别是 ElasticSearch。 - -* **内部服务**：我们的产品和 API 使用的所有度量标准数据均从内部 Finagle 服务提供，该服务从 HBase 和 MySQL 读取。 这项服务分为多个层（所有层都运行相同的代码），在这些层中，我们的产品直接使用了更关键的低延迟层，而第二层则具有更高的吞吐量，但具有更高的 90％延迟 程序化客户。 两者中的后者往往更加突发和不可预测，因此使用这样的单独层有助于使客户的响应时间尽可能短。 这也是一种方便的拆分方式，因为这意味着我们可以为关键层构建更小的虚拟机，然后将其他 Finagle 服务器阵列并置在我们的 Hadoop / HBase 计算机上。 - -* **下一个 Big Sound API** ：我们已经在对外公开以及在内部为产品提供动力的主要 API 上进行了许多迭代。 以下是一些我们发现最有影响力的最佳做法： - - 1. 不要构建仅公开方法的 API，不要构建对系统中的实体建模的 API，并让 HTTP 动词（例如 GET，PUT，POST，HEAD，PATCH，DELETE）暗示这些实体的行为。 这使得 API 的结构更容易推断和试验。 - 2. 对于需要实体*关系*的方法，请对主要实体使用类似“字段”参数的方法，并让该参数中的字段存在暗示实际上需要查找什么关系。 对我们来说，这意味着我们的 API 公开了带有“ fields”参数的“ artist”方法，该方法仅在将字段设置为“ id，name”时返回艺术家的姓名，但也可能返回有关 YouTube 艺术家的数据 频道及其上的所有视频（如果字段设置为“ id，名称，个人资料，视频”）。 获取实体之间的关系可能很昂贵，因此这是保存数据库查询的好方法，而无需编写一堆丑陋的组合方法，例如“ getArtistProfiles”或“ getArtistVideos”。 - 3. 使用外部公开的 API 来构建自己的产品始终是一个好主意，但是我们看到的另一个微妙的优势是新加入 Web 开发人员。 过去，我们在 JS 代码和 API 调用之间放置了很多 PHP 代码，但现在试图将交互作用严格地限制在 JavaScript 和 API 之间。 这意味着网络开发人员可以将精力集中在他们熟知的浏览器代码上，并且可以与他们喜欢的 Backbone 和 Angular 框架更好地协作。 -* **警报和基准**：音乐世界中总是发生着很多事情，我们尝试在所有噪声中挖掘重大事件的一种方法是通过对整个平台的数据进行基准测试（例如 确定每天发生的 Facebook 喜欢次数的总体趋势），并在客户关心的艺术家看到活跃的活动高峰时提醒我们的客户。 我们在此方面存在一些早期的可伸缩性问题，但我们已经解决了大多数问题，致力于将仅 Pig / Hadoop 用于其结果存储在 MongoDB 或 MySQL 中。 剩下的问题集中在如何为“重要”设置阈值上，到目前为止，我们最大的收获是在线活动趋向于全球趋势和峰值，因此基准必须考虑尽可能多的数据，而不能仅仅关注 在单个实体（或本例中的艺术家）上。 与这些更全面的基线的偏离是*实际*行为变化的良好指示。 - -* **Billboard Charts** ：我们向 Billboard 杂志授予了两张图表，一张用于在线艺术家的整体流行度（[社交 50 图表](http://www.billboard.com/charts/social-50)），而另一张基本上是试图预测哪些艺术家最有可能 以便将来列出该列表（[下一个大声音图表](http://www.billboard.com/charts/next-big-sound-25)）。 计算这些图表不会带来任何重大的缩放挑战，因为它只是对所有艺术家的计算得分进行反向排序，但是生成经过精打细算，具有重复数据删除功能且值得生产的列表是需要考虑的。 我们系统中的重复或几乎重复的艺术家以及这些艺术家与他们的在线个人资料的关联存在很多问题（例如，贾斯汀·比伯的 Twitter 用户名是“ justinbieber”，“ bieber”还是“ bieberofficial”？）。 解决这样的问题通常需要自动化和人机交互的结合，但是当在过滤例程中避免误报非常重要（即，即使删除一个合法的艺术家是一个大问题）时，手动管理也是必要的。 但是，我们发现，通过记住执行的动作然后具有重播这些动作的功能的系统来增加这种管理是非常有效且易于实现的。 - -* **预测性广告牌得分**：我们产生的更有趣的分析结果之一是[专利算法](http://making.nextbigsound.com/post/68287169332/predicting-next-years-breakout-artists)，用于计算艺术家在下一次“突破”时的可能性 年。 此过程涉及[随机梯度增强](http://astro.temple.edu/~msobel/courses_files/StochasticBoosting(gradient).pdf)技术的应用，以基于不同社交媒体号码的“病毒性”来预测这种可能性。 除了数学之外，这很难做到，因为我们使用的许多工具都没有 Hadoop 友好的实现，并且我们发现 [Mahout](http://mahout.apache.org/) 不能在基本应用程序之外运行。 然后，我们针对此类过程的体系结构包括通过 MapReduce 作业构建并写入 MongoDB 或 Impala 的输入数据集，然后通过 [R-Mongo](http://cran.r-project.org/web/packages/RMongo/index.html) 和 [R-Impala](http://cran.r-project.org/web/packages/RImpala/index.html) 引入 R 中，然后进行处理 在单个巨型服务器上使用 R 的一些并行处理库，例如[多核](http://cran.r-project.org/web/packages/multicore/index.html)。 使用 Hadoop 进行大多数繁重的工作，并将其余的工作留给单个服务器存在一些明显的局限性，目前尚不清楚我们最终将如何解决这些问题。 [RHadoop](https://github.com/RevolutionAnalytics/RHadoop/wiki) 可能是我们最大的希望。 - -## 托管 - -* 推出自己的网络解决方案很糟糕。 如果您要组成一个小型团队，请确保您已经有人专心完成以前完成的任务，否则请找人。 这很容易成为我们托管的最大痛苦（也是一些令人恐惧的中断的原因）。 - -* 在托管服务提供商之间移动总是很棘手，但如果您预算要在运行于两种环境中的机器上不可避免地花费的额外资金，则不必冒险，它们或多或少地在做同一件事。 除了一些不可避免的例外，我们总是最终在关闭任何旧资源之前，在新的提供程序中完整地复制体系结构，并且通常会进行一些增强。 供应商之间的共享系统似乎永远无法正常运行，通常节省下来的钱不值得缺少睡眠和正常运行时间。 - -* 由于我们约有 90％的容量专用于 Hadoop / HBase，并且工作负载真正稳定，因此很难超越拥有自己的服务器所带来的价格。 由于用户流量，我们的工作量并不是每天都突发，因为与正在进行的所有内部号码处理相比，该流量很小。 我们确实必须定期增加容量，但是将其作为步进功能很好，因为这些增加通常与大客户或数据合作伙伴的收购相吻合。 这就是为什么我们继续使用自己的硬件每月可节省约 2 万美元的原因。 - -## 获得的经验教训 - -* 如果您要汇总来自许多来源的数据并对其进行适度的转换，那么您将犯错误。 在大多数情况下，这些错误可能很明显，您可以在将它们投入生产之前将其修复，但是在其余时间中，一旦它们出现，您将需要适当的地方来对其进行处理。 这是我们在意识到这一点之前经历了很多次的场景： - - 1. 为 Twitter 艺术家的追随者收集 TB 级的数据集，在一两天内将其加载到数据库中。 - 2. 让客户知道数据已经准备好了，而让我们知道这些数据真是太棒了。 - 3. （一个月后）等等，为什么所有追随者中有 20％生活在堪萨斯州的大黄？ - 4. 哦，将位置名称转换为坐标的代码会将“ US”转换为该国家中部的坐标。 - 5. 好的，既然客户仍在使用数据集的正确部分，我们就不能删除整个内容，而只能对其进行重新处理，将其写入新表中，更新所有代码以读取两个表中的所有代码，仅从中获取记录 如果新表中不存在旧表，则在重新处理完成后删除旧表（容易吗？）。 - 6. 一百行骇人的意大利面条代码（永不消失），几天后，工作完成。 - - 在某些情况下，可能有一种更聪明的处理方式，但是当您遇到足够多的情况时，很显然，您需要一种更新生产数据的好方法，而不仅仅是将其完全删除和重建。 这就是为什么我们要为它构建系统的麻烦。 - -* 我们的大多数数据都是使用 Pig 生成和分析的。 它功能强大，几乎我们所有的工程师都知道如何使用它，并且它作为我们存储系统的中坚力量发挥了很好的作用。 搞清楚它到底在做什么，到底有什么进展，我们发现 Netflix 的 Lipstick 对此很有帮助。 我们还发现，用 Pig 来缩短开发迭代的时间很重要，而不是具有较高的可见性。 必须花时间在运行时间更长的脚本上智能地构建示例输入数据集，这些脚本会生成 20 多个 Hadoop 作业，然后再尝试对其进行测试。 - -* 从 0.4 版本开始，我们就使用了 Cassandra 多年，尽管初期经历过恐怖的经历，但是当我们离开它时，它确实很棒。 这一举动与 Cassandra 并没有多大关系，而实际上只是由于我们在重建存储架构时希望使用 Cloudera 平台的结果。 在广泛使用 HBase 和 HBase 之后，我们吸取的教训是，对于大多数人来说，争论使用哪种可能只是浪费时间。 一旦我们了解如何对其进行调整，它们都可以可靠地工作并表现良好，并且专注于我们的数据模型（例如，键压缩方案，行大小上限，使用可变长度整数，查询访问模式）产生的变化要大得多。 - -[下一个 Big Sound Blog](http://blog.nextbigsound.com/) 也有一些关于音乐行业数据挖掘的有趣帖子，如果您真的喜欢这种事情，我们总是[招聘](https://www.nextbigsound.com/about#join)！ - -因此，这些算法将以博弈数据为基础来制定自我强化的商业决策，而这将花费所有人类的技巧和投入。 知道了，商业音乐变得更加孤立和注重结果，而计算机会告诉我们我们想要什么，然后我们就会喜欢它。 明白了，音乐品味的天网。 \ No newline at end of file +我读了“ CPU”，但我怀疑很多时候它应该是 CPU“线程”。 在体系结构规模上迭代的一个很好的例子，并且不会感到被堆栈的任何特定部分所束缚。 \ No newline at end of file diff --git a/docs/116.md b/docs/116.md index e18df66..08cfe35 100644 --- a/docs/116.md +++ b/docs/116.md @@ -1,61 +1,596 @@ -# NYTimes 架构：无头，无主控，无单点故障 - -> 原文： [http://highscalability.com/blog/2014/1/13/nytimes-architecture-no-head-no-master-no-single-point-of-fa.html](http://highscalability.com/blog/2014/1/13/nytimes-architecture-no-head-no-master-no-single-point-of-fa.html) - -![](img/e344a023a89234e354fd84f1c9ab2deb.png) - -纽约时报（NYTimes）的系统架构师 Michael Laing 向[表示了极大的敬意](http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2014-January/032920.html)，使他们了解 [RabbitMQ](http://www.rabbitmq.com/) 的使用以及 RabbitMQ 邮件列表中的整体体系结构。 结束语表明这绝对是一个可以学习的架构： - -> 尽管 Fabrik 看起来很复杂，但它具有简单的组件，并且主要是原理和管道。 掌握的关键点是没有头脑，没有主人，没有单点故障。 在撰写本文时，我可以看到组件发生故障（不是 RabbitMQ），并且我们正在对其进行修复，以使它们更加可靠。 但是系统不会失败，用户可以连接，并且消息可以传递，无论如何-所有这些都在设计参数之内。 - -由于很短，因此，我不能说得更好，这里我只复制几个原始资源： - -> 简短说明一下，感谢 RabbitMQ 团队的出色产品。 -> -> 我们一流的在线产品 www.nytimes.com 具有新外观和新基础，现在包括使用 RabbitMQ 实现的消息传递体系结构。 -> -> 这种架构- Fabrik -在俄勒冈州和都柏林的 6 个 AWS 区域中分布了数十个 RabbitMQ 实例。 实例分为“批发”和“零售”两层。 通过 websockets / sockjs 连接到客户端。 -> -> 该系统自今天启动以来，已自动扩展到约 500,000 个用户。 连接时间保持在 200ms 左右。 -> -> Fabrik 提供突发新闻，视频提要等订阅服务，并将添加更多基于事件的服务。 它还支持与注册用户的订阅状态有关的个人消息传递。 -> -> 没有 RabbitMQ，该系统将无法实现。 这是一个无处不在的组件，从未动摇或失败过。 -> -> We are using: a single Amazon Linux AMI, RabbitMQ, Cassandra 2, python 2 -> -> 我们将皮卡搭配龙卷风和 libev 用于 nytuseaбrik 批发和零售产品； 我们的内部客户使用 Java 和 PHP。 -> -> 我们使用 Rabbit MQ 作为消息传递系统。 目前，我们处理的消息包括突发新闻警报和实时视频警报。 我们的内部客户通过 AMQP 向 fabrik 发送这些消息。 然后，我们将它们发送到堆栈中，以确保它们已交付。 -> -> 我们在堆栈的所有层都有 Rabbit，并用铁锹将它们连接起来。 我们自己的内部代码有助于根据那里的服务级别路由消息。 某些消息（例如突发新闻）必须尽快发出。 因此，我们将它们散布到整个群集中，然后将它们铲到其他区域的群集中进行处理。 消息从那里发送到前端进行传递。 -> -> 我们还将 Rabbit 用于个别邮件。 如果您是 NYTimes 的注册用户，我们可以亲自向您发送消息。 信用卡到期之类的事情。 -> -> 在生产中，我们在 c1-xlarges 的每个区域都有一个 RabbitMQ 客户端 3 集群和一个核心 3 集群。 弗吉尼亚州 c1 介质的代理群集将客户端连接到客户端群集。 所有服务都是并行的，因此我们可以添加更多的核心和客户端。 -> -> 零售层会自动缩放并使用 c1-medium，并且将单个兔子铲子连接到其中一只核心兔子。 每个 python websocket / sockjs 网关最多支持 10 万个客户端。 -> -> 我们将自动部署到 AWS 虚拟私有云中的子网中。 客户端通过最小的延迟被路由到最快的健康区域。 -> -> 在技​​术组件中，网关是最复杂的。 我们将逐步将其转移到开源中，并且第一部分可能是 python websocket / sockjs 库，坦率地说，它击败了大多数其他内容，并完全符合相关标准。 可以粗略地认为它是由 python 管理的 C 协同进程，因此，可以在其他语言/环境中重用。 -> -> 我们在 2 个区域/ 6 个区域中有一个 12 节点的 Cassandra 集群。 它用于消息的持久性和缓存。 我们不在 RabbitMQ 中使用持久性。 我们的服务是幂等的，重要的消息可能会被多次复制，从而创造有意竞速的条件，从而以最快的速度获胜。 -> -> Although it may seem complex, Fabrik has simple components and is mostly principles and plumbing. The key point to grasp is that there is no head, no master, no single point of failure. As I write this I can see components failing (not RabbitMQ), and we are fixing them so they are more reliable. But the system doesn't fail, users can connect, and messages are delivered, regardless - all within design parameters. +# 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量 + +> 原文： [http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html) + +![](img/824ae269f3bd907a2a05b2053f990ad9.png) + +Pinterest 一直处于指数增长曲线，每个月半翻倍。 两年来，他们的浏览量已经从每月 0 增至 100 亿，从 2 位创始人和一位工程师到 40 多位工程师，从一台小型 MySQL 服务器到 180 个 Web 引擎，240 个 API 引擎，88 个 MySQL DB（cc2。 8xlarge），每个+ 1 个从属，110 个 Redis 实例和 200 个 Memcache 实例。 + +惊人的增长。 那么 Pinterest 的故事是什么？ 告诉他们的故事，我们有我们的吟游诗人，Pinterest 的 [Yashwanth Nelapati](http://www.linkedin.com/in/yashh) 和 [Marty Weiner](http://pinterest.com/martaaay/) ，他在 [Scaling Pinterest](http://www.infoq.com/presentations/Pinterest) 演讲中讲述了 Pinterest 架构演变的戏剧性故事。 这是一年半前他们想要快速扩展并且有很多选择的时候他们希望听到的演讲。 他们做出了许多错误的选择。 + +这是一个很棒的话题。 它充满了惊人的细节。 它也是非常实用，扎根的，并且包含几乎任何人都可以采用的策略。 强烈推荐。 + +我在演讲中最喜欢的两个课程： + +1. 当可以通过添加更多相同的东西来处理增长时，体系结构就做对了。 您希望能够通过在问题上投入资金来扩展规模，这意味着您可以根据需要在问题上投入更多的资金。 如果您的架构能够做到这一点，那么您就很聪明。 +2. 当您将某些事情推到极限时，所有技术都会以自己的特殊方式失败。 这导致他们在评估工具选择时偏向于成熟的工具； 真的很好，很简单； 众所周知和喜欢 良好的支持； 始终表现出色； 尽可能无故障； 自由。 他们使用这些条件选择了：MySQL，Solr，Memcache 和 Redis。 卡桑德拉（Cassandra）和蒙哥（Mongo）被撤职。 + +这两个课程是相互关联的。 遵循（2）中原理的工具可以通过添加更多框来扩展。 随着负载的增加，成熟的产品应该会遇到更少的问题。 当您遇到问题时，至少会有一个社区来解决问题。 这是因为您的工具过于棘手又太挑剔，以至于撞到了很高的墙壁，无法攀爬。 + +在整个讨论中，我认为这是最好的部分，在讨论分片为什么比群集更好的过程中，您会看到通过增加资源，少量故障模式，成熟，简单和良好的支持来实现增长的主题， 取得成果。 请注意，他们选择的所有工具都是通过添加分片而不是通过集群来扩展的。 关于为什么他们更喜欢分片以及如何分片的讨论确实很有趣，并且可能涵盖了您以前从未考虑过的领域。 + +现在，让我们看看 Pinterest 如何扩展： + +## 基础知识 + +* 引脚是一幅包含其他信息位的图像，描述了对用户重要的内容，并链接回其找到位置。 + +* Pinterest 是一个社交网络。 您可以关注他人和董事会。 + +* 数据库：他们的用户拥有板，板具有引脚； 追踪并保持关系； 认证信息。 + +## 于 2010 年 3 月推出-寻找自我的时代 + +此时，您甚至都不知道要制造什么产品。 您有想法，因此可以快速迭代和更改。 因此，您最终遇到了许多奇怪的小 MySQL 查询，这些查询在现实生活中是永远不会做的。 + +此早期日期的数字： + +* 2 位创始人 + +* 1 位工程师 + +* 机架空间 + +* 1 个小型网络引擎 + +* 1 个小型 MySQL 数据库 + +## 2011 年 1 月 + +仍处于隐身模式，并且该产品正在根据用户反馈发展。 数字： + +* Amazon EC2 + S3 + CloudFront + +* 1 个 NGinX，4 个 Web 引擎（用于冗余，而不是用于负载） + +* 1 个 MySQL DB + 1 个读从站（以防主机崩溃） + +* 1 个任务队列+ 2 个任务处理器 + +* 1 个 MongoDB（用于计数器） + +* 2 个工程师 + +## 到 2011 年 9 月-实验时代 + +他们疯狂地奔跑着，他们每个月都翻一番。 疯狂的增长。 + +* 当您快速成长时，每个晚上和每个星期都会崩溃。 + +* 此时，您阅读了许多白皮书，说仅是一个盒子，您就完成了。 因此，他们开始增加很多技术。 他们都坏了。 + +* 结果，您最终得到了非常复杂的图片： + + * Amazon EC2 + S3 + CloudFront + + * 2NGinX，16 个 Web 引擎+ 2 个 API 引擎 + + * 5 个功能明确的 MySQL DB + 9 个读取从站 + + * 4 个 Cassandra 节点 + + * 15 个 Membase 节点（3 个独立的群集） + + * 8 个 Memcache 节点 + + * 10 个 Redis 节点 + + * 3 个任务路由器+ 4 个任务处理器 + + * 4 个弹性搜索节点 + + * 3 个 Mongo 群集 + + * 3 个工程师 + +* 仅针对数据的 5 种主要数据库技术。 + +* 增长如此之快，以至于 MySQL 变得炙手可热，所有其他技术也被推向了极限。 + +* 当您将某些技术推向极限时，所有这些技术都会以自己的特殊方式失败。 + +* 开始放弃技术并问自己自己真正想要成为什么。 对所有内容进行了大规模的重新架构。 + +## 2012 年 1 月-成熟期 + +* 重新整理一切之后，系统现在看起来像： + + * 亚马逊 EC2 + S3 + Akamai，ELB + + * 90 个 Web 引擎+ 50 个 API 引擎 + + * 66 个 MySQL DB（m1.xlarge）+每个从站 1 个 + + * 59 个 Redis 实例 + + * 51 个 Memcache 实例 + + * 1 个 Redis 任务管理器+ 25 个任务处理器 + + * 碎片 Solr + + * 6 位工程师 + +* 现在使用分片的 MySQL，Redis，Memcache 和 Solr。 而已。 优势在于它是非常简单和成熟的技术 + +* Web 流量一直以相同的速度增长，而 iPhone 流量开始上升。 + +## 2012 年 10 月 12 日-回归的时代 + +大约是一月份的四倍。 + +* The numbers now looks like: + * 3 级，Akamai，Amazon EC2 + S3 + Edge Cast + + * 180 个 Web 引擎+ 240 个 API 引擎 + + * 88 个 MySQL DB（cc2.8xlarge）+每个 1 个从数据库 + + * 110 个 Redis 实例 + + * 200 个 Memcache 实例 + + * 4 个 Redis 任务管理器+ 80 个任务处理器 + + * 碎片索尔 + + * 40 名工程师（并且正在不断增长） + +* 请注意，该架构正在做正确的事情。 增长是通过添加更多相同的东西。 您希望能够通过花钱解决问题来扩展规模。 您只需要在需要时就可以扔出更多盒子。 + +* 现在移至 SSD + +## 为什么选择 Amazon EC2 / S3？ + +* 相当不错的可靠性。 数据中心也会崩溃。 多租户会增加一些风险，但这还不错。 + +* 良好的报告和支持。 他们的架构师非常好，他们知道问题 + +* 不错的外围设备，尤其是在您成长的时候。 您可以启动 App Engine 并与他们的托管缓存，负载平衡，地图缩减，托管数据库以及您无需自己编写的所有其他部分进行对话。 您可以引导亚马逊的服务，然后在拥有工程师的情况下对其进行改进。 + +* 数秒内即可使用新实例。 云的力量。 特别是有了两名工程师，您不必担心容量规划或等待两周来获取内存缓存的情况。 只需几分钟即可添加 10 个内存缓存。 + +* 缺点：选择有限。 直到最近，您才能获得 SSD，并且无法获得大容量 RAM 配置。 + +* 优点：选择有限。 您最终不会得到很多配置不同的盒子。 + +## 为什么选择 MySQL？ + +* 真的很成熟。 + +* 非常牢固。 对于他们来说，它永远不会失败，并且永远不会丢失数据。 + +* 您可以租用它。 许多工程师都了解 MySQL。 + +* 对请求速率的响应时间线性增加。 当请求率达到峰值时，某些技术的响应也不会很好。 + +* 很好的软件支持-XtraBackup，Innotop，Maatkit + +* 很棒的社区。 回答问题很容易。 + +* Percona 等公司提供了很好的支持。 + +* 免费-当您最初没有任何资金时很重要。 + +## 为什么使用 Memcache？ + +* 非常成熟。 + +* 真的很简单。 这是一个哈希表，其中插入了一个套接字。 + +* 始终表现出色 + +* 众所周知，很喜欢。 + +* 始终表现良好。 + +* 永不崩溃。 + +* 免费 + +## 为什么要使用 Redis？ + +* 还不成熟，但确实非常好，非常简单。 + +* 提供各种数据结构。 + +* 具有持久性和复制性，可以选择实现它们的方式。 如果您想要 MySQL 样式的持久性，可以拥有它。 如果您不需要持久性，可以拥有它。 或者，如果您想要 3 个小时的持久性，则可以拥有它。 + + * 您的家庭供稿位于 Redis 上，每 3 小时保存一次。 没有 3 小时的复制。 他们仅每 3 小时备份一次。 + + * 如果将数据存储在模具上的盒子中，则它们仅备份了几个小时。 它并不完全可靠，但更简单。 您不需要复杂的持久性和复制。 它的架构更简单，更便宜。 + +* 众所周知，很喜欢。 + +* Consistently good performance. + +* 少数故障模式。 您需要了解一些微妙的故障模式。 这就是成熟的源头。只是学习它们并超越它。 + +* Free + +## Solr + +* 很棒的起床型产品。 安装它，几分钟后您将建立索引。 + +* 不能超过一个框。 （最新版本并非如此） + +* 尝试了弹性搜索，但从规模上看，它遇到了很多小文档和很多查询的麻烦。 + +* 现在使用 Websolr。 但是他们有一个搜索小组，并且会自己动手。 + +## 聚类与分片 + +* 在快速增长期间，他们意识到他们将需要平均分布数据以应对不断增长的负载。 + +* 定义了一个讨论该问题的频谱，他们提出了“聚类”和“分片”之间的一系列选择。 + +### 群集-一切都是自动的： + +* 示例：Cassandra，MemBase，HBase + +* 判决：太可怕了，也许在将来，但是现在它太复杂了，故障模式太多了。 + +* 属性： + + * 数据自动分发 + + * 数据可以移动 + + * 重新平衡以分配容量 + + * 节点相互通信。 大量的串扰，闲聊和谈判。 + +* 优点： + + * 自动扩展您的数据存储。 白皮书至少是这样说的。 + + * 易于设置。 + + * 在空间上分布和放置数据。 您可以将数据中心放置在不同的区域，而数据库则由它来处理。 + + * 高可用性 + + * 负载平衡 + + * 没有单点故障 + +* 缺点（根据第一手经验）： + + * 还很年轻。 + + * 从根本上讲复杂。 整个节点必须对称一致，这是生产中很难解决的问题。 + + * 较少的社区支持。 社区的产品线不同，因此每个阵营的支持都较少。 + + * 具有工作知识的工程师更少。 可能大多数工程师都没有使用 Cassandra。 + + * 困难而令人恐惧的升级机制。 可能与它们都使用 API​​并相互之间进行交谈有关，所以您不希望它们混淆。 这导致复杂的升级路径。 + + * 集群管理算法是 SPOF。 如果有错误，它将影响每个节点。 这使他们失望了 4 次。 + + * 群集管理器是在具有以下故障模式的所有节点上复制的复杂代码： + + * 数据重新平衡中断。 带来一个新盒子，数据开始复制，然后被卡住。 你是做什么？ 没有工具可以弄清楚发生了什么。 没有社区可以帮助，所以他们陷入了困境。 他们回到了 MySQL。 + + * 所有节点上的数据损坏。 如果存在一个错误，该错误会在所有日志中将错误注入到写入日志中，并且压缩或其他机制停止了，该怎么办？ 您的阅读延迟会增加。 您所有的数据都被搞砸了，数据消失了。 + + * 无法轻松解决的不正确平衡。 很常见的。 您有 10 个节点，并且注意到所有节点都在一个节点上。 这是一个手动过程，但是它将负载重新分配回一个节点。 + + * 数据授权失败。 群集方案非常聪明。 在一种情况下，他们带来了新的中学。 大约 80％的辅助节点表示它是主要节点，而主要节点转到辅助节点，您已经丢失了 20％的数据。 丢失 20％的数据比丢失所有数据更糟糕，因为您不知道丢失了什么。 + +### 分片-一切都是手动的： + +* 裁决：获胜者。 注意，我认为它们的分片架构与 [Flickr 架构](http://highscalability.com/blog/2007/11/13/flickr-architecture.html) 有很多共同点。 + +* Properties: + + * 摆脱所有您不喜欢的聚类属性，即可进行分片。 + + * 手动分发的数据 + + * 数据不动。 尽管有些人这样做，但他们从未移动数据，这使它们在频谱上处于更高的位置。 + + * 拆分数据以分配负载。 + + * 节点彼此之间不认识。 一些主节点控制一切。 + +* Pros: + + * 可以拆分数据库以增加容量。 + + * 在空间上分配和配置您的数据 + + * High availability + + * Load balancing + + * 放置数据的算法非常简单。 主要原因。 有 SPOF，但只有半页代码，而不是非常复杂的 Cluster Manager。 在第一天之后，它会起作用或不起作用。 + + * ID 生成很简单。 + +* 缺点： + + * 无法执行大多数加入。 + + * 失去了所有交易功能。 成功写入另一个数据库时，对一个数据库的写入可能会失败。 + + * 必须将许多约束移到应用程序层。 + + * 模式更改需要更多计划。 + + * 报表需要在所有分片上运行查询，然后自己执行所有聚合。 + + * 联接在应用程序层中执行。 + + * 您的应用程序必须容忍所有这些问题。 + +### 什么时候分片？ + +* 如果您的项目将有几 TB 的数据，则应尽快分片。 + +* 当 Pin 表达到 10 亿行时，索引用完了内存，它们正在交换到磁盘。 + +* 他们选择了最大的表并将其放在自己的数据库中。 + +* 然后它们在单个数据库上用完了空间。 + +* 然后他们不得不分片。 + +### 转换为分片 + +* 从冻结功能开始过渡过程。 + +* 然后，他们决定了如何分片。 想要执行最少数量的查询并转到最少数量的数据库以呈现单个页面。 + +* 删除了所有 MySQL 连接。 由于可以将表加载到单独的分区中，因此联接将不起作用。 + +* 添加了大量的缓存。 基本上每个查询都必须被缓存。 + +* 步骤如下： + + * 1 个 DB +外键+加入 + + * 1 个 DB +规范化+缓存 + + * 1 个 DB +读取从站+缓存 + + * 几个功能分区的 DB +读取从站+缓存 + + * ID 分片的 DB +备份从属+缓存 + +* 由于奴隶滞后，较早读取的奴隶成为一个问题。 读取将发送给从属设备，而主设备尚未复制记录，因此看起来好像丢失了记录。 解决这个问题需要缓存。 + +* 他们具有后台脚本，该脚本重复了数据库过去的工作。 检查完整性约束，参考。 + +* 用户表未分片。 他们只是使用大型数据库，并且对用户名和电子邮件具有唯一性约束。 如果不是唯一的，则插入用户将失败。 然后，他们在分片数据库中进行了大量写操作。 + +### 如何分割？ + +* 看了 Cassandra 的戒指模型。 看着 Membase。 并看着 Twitter 的 Gizzard。 + +* 确定：跨节点移动的数据最少，体系结构就更稳定。 + +* Cassandra 存在数据平衡和权限问题，因为节点不确定谁拥有数据的哪一部分。 他们决定应用程序应该决定数据应该去哪里，所以永远不会有问题。 + +* 预测了他们未来五年的增长，并牢记这一容量计划。 + +* 最初创建了许多虚拟分片。 8 台物理服务器，每个服务器有 512 个 DB。 所有数据库都有所有表。 + +* 为了获得高可用性，它们始终在多主复制模式下运行。 每个主服务器都分配到一个不同的可用区。 发生故障时，切换到另一个主节点，并引入一个新的替换节点。 + +* 当数据库上的负载增加时： + + * 查看代码提交，以查看是否发生了新功能，缓存问题或其他问题。 + + * 如果只是增加负载，他们就会拆分数据库，并告诉应用程序在新主机上查找数据。 + + * 在拆分数据库之前，它们会启动这些主服务器的从服务器。 然后，他们用新的数据库分配交换应用程序代码。 在过渡期间的几分钟内，写入仍将写入旧节点，并被复制到新节点。 然后在节点之间切割管道。 + +### ID 结构 + +* 64 位： + + * 分片 ID：16 位 + + * 类型：10 位-引脚，板，用户或任何其他对象类型 + + * 本地 ID-表中 ID 的其余位。 使用 MySQL 自动递增。 + +* Twitter 使用映射表将 ID 映射到物理主机。 这需要查找。 由于 Pinterest 在 AWS 上并且 MySQL 查询花费了大约 3 毫秒，因此他们决定这种额外级别的间接操作将不起作用。 他们将位置内置到 ID 中。 + +* 新用户随机分布在各个分片上。 + +* 用户的所有数据（引脚，板等）都位于同一分片上。 巨大的优势。 例如，呈现用户个人资料不会进行多个交叉分片查询。 它很快。 + +* 每个板都与用户并置，因此可以从一个数据库中呈现板。 + +* 足以容纳 65536 个分片的分片 ID，但最初它们仅打开 4096，它们将水平扩展。 用户数据库用完后，他们将打开更多的分片，并允许新用户访问新的分片。 + +### 查找 + +* 例如，如果他们有 50 个查询，他们将拆分 ID 并并行运行所有查询，因此等待时间是最长的等待时间。 + +* 每个应用程序都有一个配置文件，该文件将分片范围映射到物理主机。 + + * “ sharddb001a”：：( 1，512） + + * “ sharddb001b” ：：（513，1024）-备份热备机 + +* 如果要查找 ID 属于 sharddb003a 的用户： + + * 将 ID 分解为各个部分 + + * 在分片图中执行查找 + + * 连接到分片，转到类型的数据库，然后使用本地 ID 查找合适的用户并返回序列化的数据。 + +### 对象和映射 + +* 所有数据都是对象（引脚，面板，用户，注释）或映射（用户具有面板，引脚具有点赞）。 + +* 对于对象，本地 ID 映射到 MySQL Blob。 Blob 格式以 JSON 开头，但现在已转为序列化节俭。 + +* 对于映射，有一个映射表。 您可以要求用户提供所有板。 这些 ID 包含时间戳记，因此您可以查看事件的顺序。 + + * 有一个反向映射（多对多表），用于回答该类型的查询，这给了我所有喜欢此引脚的用户。 + + * 模式命名方案为 noun_verb_noun：user_likes_pins，pins_like_user。 + +* 查询是主键或索引查找（无联接）。 + +* 数据不会像集群一样在数据库中移动。 例如，一旦用户登陆到分片 20，并且所有用户数据都并置在一起，它将永远不会移动。 64 位 ID 包含分片 ID，因此无法移动。 您可以将物理数据移动到另一个数据库，但仍与同一分片关联。 + +* 所有表都存在于所有分片上。 没有特殊的分片，不计算用于检测用户名冲突的庞大用户表。 + +* 无需更改架构，并且新索引需要新表。 + + * 由于键的值为 blob，因此您可以添加字段而不会破坏架构。 每个 Blob 上都有版本控制，因此应用程序将检测版本号，并将记录更改为新格式并写回。 无需一次更改所有数据，将在读取时进行升级。 + + * 巨大的胜利，因为更改桌子需要数小时或数天的锁定。 如果要新索引，只需创建一个新表并开始填充它。 当您不再需要时，请将其放下。 （没有提及这些更新如何确保交易安全）。 + +### 呈现用户个人资料页面 + +* 从 URL 获取用户名。 转到单个大型数据库以查找用户 ID。 + +* 获取用户 ID 并将其拆分为各个组成部分。 + +* 选择分片并转到该分片。 + +* 来自用户的 SELECT 正文，其中 id = < local_user_id > + +* 从 user_has_boards 中选择 board_id，其中 user_id = < user_id > + +* 从 ID 为 IN 的板子中选择主体（< boards_ids >） + +* 从 board_has_pins 中选择 pin_id，而 board_id = < board_id > + +* 从 ID 为 IN 的引脚（PIN_ID）中选择主体 + +* 大多数调用是通过缓存（内存缓存或 Redis）提供的，因此实际上并没有很多数据库查询。 + +### 脚本编写 + +* 迁移到分片式架构时，您有两种不同的基础结构，一种是旧的非分片系统，另一种是新的分片系统。 脚本是将旧内容转移到新内容的所有代码。 + +* 他们移动了 5 亿个引脚和 16 亿个追随者行，等等 + +* 低估了项目的这一部分。 他们认为将数据放入碎片中需要 2 个月，而实际上需要 4-5 个月。 记住，这是在功能冻结期间。 + +* 应用程序必须始终写入新旧基础结构。 + +* 一旦确定所有数据都在新的基础架构中，然后将您的读取指向新的基础架构，然后慢慢增加负载并测试后端。 + +* 建立了脚本农场。 动员更多的工人来更快地完成任务。 他们将执行诸如将这些表移至新基础架构之类的任务。 + +* 窃取了 Pyres 副本，这是 Github Resque 队列的 Python 接口，该队列基于 Redis 构建。 支持优先级和重试。 太好了，他们用 Pyres 代替了 Celery 和 RabbitMQ。 + +* 该过程中有很多错误。 用户发现错误，例如缺少板。 必须多次运行该过程，以确保没有暂时性错误阻止数据正确移动。 + +## 开发 + +* 最初尝试为开发人员提供系统的一部分。 每个服务器都有自己的 MySQL 服务器等，但是事情变化如此之快，因此无法正常工作。 + +* 转到 Facebook 的模式，每个人都可以访问所有内容。 因此，您必须非常小心。 + +## 未来方向 + +* 基于服务的体系结构。 + + * 随着他们开始看到大量的数据库负载，他们开始产生许多应用程序服务器和许多其他服务器。 所有这些服务器都连接到 MySQL 和内存缓存。 这意味着内存缓存上有 30K 连接，占用了数 GB 的 RAM，并导致内存缓存守护进程交换。 + + * 作为解决方法，它们正在迁移到服务体系结构。 例如，有一个追随者服务，它将仅回答追随者查询。 这样可以将访问数据库和缓存的计算机数量限制为 30，从而减少了连接数量。 + + * 帮助隔离功能。 帮助围绕服务和支持这些服务组织团队。 开发人员无法访问其他服务，从而提高了安全性。 + +## 获得的经验教训 + +* 将失败。 把事情简单化。 + +* 保持乐趣。 有很多新人加入这个团队。 如果您只是给他们一个庞大的复杂系统，那将不会很有趣。 保持架构简单是一个巨大的胜利。 从第一周开始，新工程师就开始提供代码。 + +* When you push something to the limit all these technologies fail in their own special way. + +* 当可以通过添加更多相同的东西来处理增长时，体系结构就做对了。 您希望能够通过在问题上投入更多盒子来解决问题，从而根据需要扩展规模。 如果您的架构能够做到这一点，那么您就很聪明。 + +* Cluster Management Algorithm is a SPOF. If there’s a bug it impacts every node. This took them down 4 times. + +* 要应对快速增长，您需要平均分配数据以应对不断增长的负载。 + +* 跨节点移动的数据最少，体系结构就更稳定。 这就是为什么他们在群集上进行分片。 + +* 面向服务的体系结构规则。 它隔离功能，帮助减少连接，组织团队，组织支持并提高安全性。 + +* 问自己，你真正想要成为什么。 即使您必须重新构建所有架构，也要删除符合该愿景的技术。 + +* 不要害怕丢失一些数据。 它们将用户数据保留在内存中并定期将其写出。 丢失意味着仅丢失了几个小时的数据，但是最终的系统却变得更加简单和强大，这才是重要的。 ## 相关文章 -* [在 Reddit 上](http://www.reddit.com/r/programming/comments/1v4gzj/nytimes_architecture_system_doesnt_fail_users_can/) +* [讨论黑客新闻](https://news.ycombinator.com/item?id=5552504) +* [Pinterest 体系结构更新-1800 万访问者，增长 10 倍，拥有 12 名员工，410 TB 数据](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) +* [用于处理 3 百万以上用户的 Pinterest 堆栈中的一个短项](http://highscalability.com/blog/2012/2/16/a-short-on-the-pinterest-stack-for-handling-3-million-users.html) +* [Pinterest 通过自动关闭系统将费用从每小时 54 美元降低到 20 美元](http://highscalability.com/blog/2012/12/12/pinterest-cut-costs-from-54-to-20-per-hour-by-automatically.html) +* [Instagram 体系结构更新：Instagram 有何新功能？](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html) +* [Facebook 过去曾增长到 5 亿用户的 7 种扩展策略](http://highscalability.com/blog/2010/8/2/7-scaling-strategies-facebook-used-to-grow-to-500-million-us.html)和 [Facebook](http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html) 扩展的四个元秘密-我认为您会在他们的方法中找到一些相似之处。 + +一个小的更正，“ Web Solr”应实际读取为“ Websolr”，如 http://websolr.com/ + +非常感谢你的这篇文章。 简单明了地指出了每个方面：） + +没有提及实际的 Web 应用程序使用什么编程语言和框架。 请告诉我他们没有在 PHP 中执行此操作... + +Python ... Pinterest 一直被吹嘘为 DJango 实现。 看到这里：http://www.quora.com/Pinterest/What-technologies-were-used-to-make-Pinterest + +有人知道他们是否仍将 Nginx 用作应用服务器负载平衡器吗？ + +在“为什么要 Amazon EC2 / S3”部分下，提到了“ App Engine”。 这让我感到困惑（因为 App Engine 是 Google，而不是 Amazon）。 有人可以澄清吗？ + +交换？ 删除交换，交换比失败诱饵更糟糕。 +停机服务器比 ssssllllllooooooowwwww 服务器更好。 + +绕开 CDN 的原因是什么？ + +有人知道他们如何存储图像吗？ 在 mysql，磁盘还是其他地方？ +例如，URL“ http://media-cache-ec4.pinimg.com/736x/cf/d7/49/cfd74959947950dd0c3c1ef8ef2f1582.jpg”中的 imageid 可能包含一些信息？ 谢谢 + +很想知道更多有关 Mongo 为什么被删除的信息，以支持在 MySQL 中存储无模式的 Blob。 这仅仅是错误，性能低下的问题吗？ 好像 Mongo 是为这种 BASE 体系结构设计的，如果它可以很好地运行，则无需在应用程序层手动管理索引的开销。 + +小修正：在您喜欢的讲座的 2 课中的第 1 课中，您说“您是建筑”而不是“您的建筑”。 + +非常有趣的阅读。 + +谁能解释： +对于对象，本地 ID 映射到 MySQL Blob。 Blob 格式以 JSON 开头，但现在已转为序列化节俭。 + +为什么本地 ID 映射到 mysql Blob？ + +感谢您发布此信息。 看到架构的潮起潮落总是让人着迷。 但是，我不同意本文的最后一点。 + +> 不要害怕丢失一些数据。 + +该陈述完全取决于所讨论数据的使用。 在 Pinterest 的情况下，我可以看到它完全可以实现。 所涉及的数据没有货币价值，如果丢失了任何人的生命都不会受到特别的影响。 但是，我认为区分不重要的数据丢失和重要的数据非常重要。 + +当您说“ Web Engine”时，您指的是什么？ 这是否意味着另一个克隆了主应用程序的云实例？ -一篇非常有趣的文章。 只是有机会略读，但我期待学习更多。 +你好 -一个快速的问题：我注意到报价的字符集似乎存在问题（也许是从复制/粘贴时起？）。 NYTimes 架构名称周围有一些奇怪的符号。 +我很好奇，当一个用户数据过大而又无法容纳一个分片时，会发生什么？ -我已将图像上传到 imgur，并提供了它对我的外观的屏幕截图。 没什么大不了的，但以为您可能想知道。 您可以在 [http://imgur.com/9IfuLX5](http://imgur.com/9IfuLX5) 上看到图像。 +此致 +拉希德 -肖恩，可能是因为您的浏览器未设置为查看或接受 utf-8 字符？ +有人能粗略估计一下这些设置每个月要花费多少吗？ -托德（Todd），带有说明链接的错字-文章将其拼写为解密 +为什么同时使用 Memcache 和 Redis？ Redis 几乎可以完成 Memcache 可以做的所有事情，还有其他用途。 -这就是将字符发布到邮件列表的方式 \ No newline at end of file +即使在这些年之后，这篇文章也很有意义。 感谢您抽出宝贵的时间，并详细说明了构建简单的可伸缩 Web 平台需要花费的一切！ \ No newline at end of file diff --git a/docs/117.md b/docs/117.md index 2720d25..b590b99 100644 --- a/docs/117.md +++ b/docs/117.md @@ -1,282 +1,58 @@ -# HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息 +# Facebook 的网络秘密 -> 原文： [http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html](http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html) +> 原文： [http://highscalability.com/blog/2013/4/23/facebook-secrets-of-web-performance.html](http://highscalability.com/blog/2013/4/23/facebook-secrets-of-web-performance.html) -![](img/1f990901f6dd64766ac61ad0b37e95a1.png) +![](img/9e91ed9216d56753c708d226148e5656.png) -*本文来自 [Zuhaib Siddique](http://www.linkedin.com/in/zuhaib) 的采访， [HipChat ]](https://www.hipchat.com/) ， 团队聊天和即时消息的制造商。* +*这是我为[边界博客](http://boundary.com/blog/)所做的采访[的第 1 部分的转贴。](http://boundary.com/blog/2013/04/22/todd-hoff-on-facebook-secrets-of-web-performance/)* -HipChat 始于一个不寻常的领域，您可能认为它没有太大的希望，即企业组消息传递，但是随着我们了解到那里有金 [企业群 [](http://www.developereconomics.com/still-building-consumer-apps-enterprise-pays-4x/) 。 这就是为什么 Atlassian 是 JIRA 和 Confluence 之类的工具开发者，他们 [在 2012 年收购了 HipChat](http://blog.hipchat.com/2012/03/07/weve-been-acquired-by-atlassian/) 。 +**边界：** **如果要在网络上管理最大的大数据项目，Facebook 的秘诀是什么？** -在一个不经常听到的故事中，大父母的资源和联系实际上帮助 HipChat 进入了 [指数增长周期](https://s3.amazonaws.com/uploads.hipchat.com/10804/368466/10joz8sztfw4dfc/HipChat1B.jpg) 。 他们已达到 12 亿条消息存储标记，现在正每隔几个月发送，存储和建立索引的消息数量就增加一倍。 +**Hoff：**我们从前几位工程总监的 Facebook 内幕人物 [Aditya Agarwal](http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html) 和 [Robert Johnson](http://highscalability.com/blog/2010/8/2/7-scaling-strategies-facebook-used-to-grow-to-500-million-us.html) 了解到了他们的秘密： -这种增长给曾经足够的基础架构带来了巨大压力。 HipChat 展示了一种常见的缩放模式。 从简单开始，经历流量激增，然后思考我们现在该怎么办？ 通常，使用大型计算机是最佳的选择。 他们做到了。 这给了他们一些喘息的空间，以便弄清楚下一步该怎么做。 在 AWS 上，在某个拐点之后，您将开始使用 Cloud Native，即水平扩展。 这就是他们所做的。 +* **缩放需要迭代**。 解决方案通常从一开始就起作用，但是您必须随时进行修改。 例如，PHP 最初很容易使用，但是当您拥有成千上万的 Web 服务器时，不是一个好的选择。 -但是故事有一个转折。 除了云/ SaaS 版本之外，安全方面的考虑还推动了本地版本的 HipChat 的开发。 我们将在本周晚些时候的[帖子](http://highscalability.com/blog/2014/1/8/under-snowdens-light-software-architecture-choices-become-mu.html)中详细讨论这一有趣的发展。 +* **缩放需要迭代**。 你可以再说一遍。 -虽然 HipChat 并非 Google 规模，但可以从 HipChat 中学习很多有关它们如何及时索引和搜索数十亿条消息的知识，这是 IRC 和 HipChat 之类的主要区别。 在不丢失消息的情况下索引和存储负载下的消息是挑战。 +* **不要过度设计**。 在扩展系统时，只需使用所需的内容即可。 找出您需要在解决方案上进行迭代，优化的地方或自己完全构建堆栈的一部分的位置。 -这是 HipChat 走的路，您可以学到什么？ 让我们看看… +* **为作业**选择合适的工具。 意识到任何选择都会带来开销。 如果您确实需要使用 Python，请继续，我们将尽力帮助您成功。 但是，有了这种选择，通常会在部署，监视，操作等方面产生开销。 -## 统计信息 +* **获得正确的文化。** 在内部建立环境，以促进首先构建正确的事物并根据需要进行修复。 不要担心创新，大事，大胆思考以及在建造第一件东西之后需要建造的下一件东西。 隔离您重视并希望保留的文化部分。 它不会自动发生。 -* 每秒 60 条消息。 +* **快速移动**。 首先进入市场。 没事就可以了 例如，Facebook 在由三个人开发的 HipHop 上运行其整个 Web 层。 这是一个冒险的策略。 它会定期关闭网站（内存不足，无限循环），但他们发现如何使网站正常运作，因此有很大的潜在收益。 -* 已存储 12 亿个文档 +* **授权小型团队**。 小团队可以做伟大的事情。 Facebook 搜索，照片，聊天和 HipHop 都是小团队的结果。 找到合适的人，赋予他们权力，让他们工作。 -* 4TB EBS 突袭 +* **人们最重要**。 是构建和运行系统的人。 最好的扩展工具是能够处理任何事情的工程和运营团队。 -* AWS 上的 8 台 ElasticSearch 服务器 +* **水平缩放**。 要处理指数级增长的流量，需要在许多计算机之间任意分配负载。 -* 26 个前端代理服务。 在后端应用服务器中将其翻倍。 +* **测量所有内容**。 生产是真正有用的数据的来源。 测量系统和应用程序级别的统计信息，以了解正在发生的事情。 -* 18 人 +* **赋予团队控制权和责任感**。 责任需要控制。 如果团队负责某件事，他们也必须控制它。 -* 0.5 TB 的搜索数据。 +所有这些原则共同作用，形成一个自我强化的良性循环。 除非您有一支拥有控制和责任感的小型团队，否则您将无法快速前进。 除非您将这些更改投入生产并衡量结果，否则您将无法知道更改的工作方式。 除非人们对移出工作代码负责，否则您无法将代码移入生产环境。 除非您弄清楚如何水平缩放，快速移动并测量所有内容，否则您将无法处理磅秤，所有这些都取决于好人。 -## 平台 +但是，以上并非全部。 机会的作用并不那么明显。 我们经常看到的一种模式是，处于领先地位的公司先于其他所有人看到问题，因此他们首先解决了所有其他问题。 我们看到来自 Google，Netflix，Twitter 和 Facebook 等技术热点的创新浪潮。 -* **托管**：带有 75 个实例的 AWS EC2 East 当前全部为 Ubuntu 12.04 LTS +**边界：您认为其他哪些主要网站在按需扩展，保持用户满意和高响应时间方面做得很好？** -* **数据库**：当前用于聊天记录的 CouchDB，正在过渡到 ElasticSearch。 MySQL-RDS 的其他所有功能 +**Hoff：**我们的行业很棒。 人们总是愿意分享他们的经验，分享他们的代码并谈论有效的方法。 我的妻子是一名税务会计师，他们肯定没有相同的氛围，这让人有点难过。 在这个领域有很多令人难以置信的聪明和热情的人，总的质量只会随着越来越多的人谈论如何制造好东西而提高。 -* **缓存**：Redis +对我来说，显而易见的是，拥有一个优质的网站和共享的意愿是相互联系的。 我可以列出许多公司属于此类，但这些公司比较突出：Twitter，Etsy，Facebook，Google，Netflix，Amazon 和 StackExchange。 其他一些重要的贡献者包括：Airbnb，Tumblr，Instagram，TripAdvisor，Heroku，Prismatic，37signals，Pinterest 和 Yahoo。 -* **搜索**：ElasticSearch +从字面上可以提到其他数百个，但是这些公司为推动 Web 性能的发展不断做出了积极的贡献。 不过，我已经很难过，因为我知道我想念一些。 -* **队列/工作服务器**：Gearman（队列）和 [Curler](https://github.com/powdahound/curler) ，（工作人员） +我不得不说，这篇文章中的建议是完全没有价值的！ 真是浪费时间！ -* **语言**：Twisted Python（XMPP 服务器）和 PHP（Web 前端） +是的-太棒了 完美主义是一个大问题，它使许多组织瘫痪。 -* **系统配置**：开源 Chef + Fabric +而且我喜欢，如果他们对现有技术不满意，他们会无所畏惧地自行构建堆栈。 IT 界流传的最糟糕的城市神话之一是，如果存在与您所做的工作遥不可及的事情，那么您应该毫无疑问地使用它。 大人物没有遵循这个神话-这是他们是大人物的原因之一。 :) -* **代码部署**：Capistrano +谢谢你！ -* **监视**：Sensu 和 monit 泵送警报到 Pagerduty +没错，凯尔（Kyle），最糟糕的神话是：“不要发明轮子”！ +有时您不得不一次又一次地重新发明轮子：) -* **图表**：statsd + Graphite - -## 产品 - -* 交通非常繁忙。 在周末和节假日，这里会很安静。 在高峰负载期间，每秒数百个请求。 聊天消息实际上并不占流量的大部分; 它是状态信息（离开，空闲，可用），人们在连接/断开连接等。因此，每秒 60 条消息可能看起来很低，但这只是一个平均值。 - -* HipChat 希望成为您的通知中心，您可以在这里与团队合作，并从工具和其他系统获得所有信息。 帮助使每个人都处于循环中。 特别是在远程办公室。 - -* 之所以在 IRC 上使用 HipChat 的主要原因是，HipChat 可以存储和索引每个会话，以便以后可以搜索它们。 强调搜索，因此您可以留在 HipChat 中。 使用此功能对团队来说是个胜利，您可以随时返回并记住发生了什么以及您同意做什么。 它还会将消息路由到同一用户拥有的多个设备，并在发送消息时无法访问您的设备时进行临时消息缓存/重试。 - -* 增长来自更多的客户，但随着更多的客户在每个站点使用该产品，其参与度也随之提高。 他们的 API 集成也看到了增长。 - -* 消息的存储和搜索是其系统中的主要可伸缩性瓶颈。 - -* HipChat 使用 XMPP，因此任何 XMPP 客户端都可以连接到系统，这对于采用是一个巨大的胜利。 他们建立了自己的本机客户端（Windows，Linux，Mac，iOS，Android），并具有扩展功能，例如 PDF 查看，自定义表情符号，自动用户注册等。 - -* 不久前，将 Wiki 之类的工具引入企业文化几乎是不可能的。 现在，企业级工具似乎已被接受。 为什么现在？ - - * 基于文本的通信现在很普遍并且被接受。 我们拥有短信，IM 和 Skype，因此现在很自然地使用聊天工具。 - - * 分散的工作团队的兴起。 团队越来越分散。 我们不能只是一起坐下来听讲座。 需要记录所有内容，这意味着组织交流被视为一项重要资产。 - - * 增强功能。 内嵌图像，gif 动画等功能使它变得有趣，吸引了更广泛的人群。 - -* HipChat 具有 [API](https://www.hipchat.com/docs/api) ，该 API 使得可以编写类似于 [IRC 机器人](http://en.wikipedia.org/wiki/Internet_Relay_Chat_bot)的工具。 示例用法用于 Bitbucket 提交。 在 10:08，开发人员 X 提交了一些代码来修复错误。 它通过 HipChat 发送，并直接链接到代码提交和提交日志。 全部自动化。 Bitbucket 提交击中了 Web 钩子，并使用其中一个插件发布信息。 插件可帮助您编写自己的机器人。 转到您的 Bitbucket 帐户。 假设我有我的 API 令牌，并且每次提交时都想发布到此 API。 对于 GitHub 类似地工作。 - -* 从客户端上的 Adobe Air 开始，它泄漏了内存并会关闭计算机。 因此移至本机应用程序。 痛苦，但很好。 他们在公司各个部门的所有平台上都有用户。 您需要成为用户所在的地方。 希望用户在所有操作系统上都拥有出色的体验。 用户是所有人，而不仅仅是技术专家。 - -## XMPP 服务器体系结构 - -* HipChat 基于 XMPP，消息是 [XMPP 节](http://xmpp.org/rfcs/rfc3920.html) 内的任何内容，可以是一行文本或日志的较长部分 输出。 他们不想谈论他们的 XMPP 体系结构，因此没有很多细节。 - -* 他们没有使用第三方 XMPP 服务器，而是使用 Twisted Python 和 XMPP 库构建了自己的服务器。 这允许创建可扩展的后端，用户管理以及轻松添加功能，而无需与其他人的代码库抗衡。 - -* AWS 上的 RDS 用于用户身份验证以及事务和 SQL 有用的其他区域。 这是一项稳定，可靠的技术。 对于本地产品，他们使用 MariaDB。 - -* Redis 用于缓存。 诸如哪些用户位于哪个房间，状态信息，谁在线等信息，因此与连接到哪个 XMPP 服务器无关紧要，XMPP 服务器本身不是限制。 - - * 痛点是 Re​​dis 尚未聚类（尚未）。 为了实现高可用性，使用了热/冷模型，因此从器件可以使用了。 从主节点到从节点的故障转移大约需要 7 分钟。 奴隶促销是手工完成的，不是自动化的。 - -* 增加的负载暴露了代理服务器以及它们可以处理多少个客户端的弱点。 - - * 这是一个实际的问题，因为不丢失消息是一个高度优先事项。 客户表示不丢弃消息比低延迟更重要。 用户宁愿迟到也不愿迟到。 - - * 使用 6 个 XMPP 服务器，系统运行良好。 随着连接数量的增加，他们开始看到不可接受的延迟。 连接不仅来自客户端，还包括支持其编程界面的机器人。 - - * 作为第一步，他们将前端服务器和应用程序服务器分开。 代理处理连接，后端应用程序处理节。 前端服务器的数量由活动的侦听客户端的数量决定，而不是由发送的消息数决定。 在提供及时服务的同时保持如此多的连接打开是一个挑战。 - - * 解决数据存储问题后，计划将研究如何优化连接管理。 Twisted 效果很好，但是它们之间有很多联系，因此必须弄清楚如何更好地处理它。 - -## 存储体系结构 - -* 在 HipChat 上增长的 10 亿条消息不断增长的同时，他们突破了 CouchDB 和 Lucene 解决方案存储和搜索消息的限制。 - - * 认为 Redis 将是失败点。 以为 Couch / Lucene 就足够了。 没有进行适当的容量规划，也没有查看邮件的增长率。 增长速度超出了他们的想象，因此不应该过多地关注 Redis 而是关注数据存储。 - - * 当时，他们相信通过增加更多的功能进行扩展，然后再升级到越来越大的 Amazon 实例。 他们认为，随着这种方法的发展，这种方法只能再使用 2 个月。 因此，他们必须做一些不同的事情。 - - * Couch / Lucene 一年未更新，因此无法进行修改。 另一个原因的另一个原因。 - -* 在亚马逊上大约有十亿条消息是一个转折点。 有了专用服务器和 200 Gig 的 RAM，它们以前的体系结构可能仍然有效，但在资源有限的云中却无法实现。 - -* 他们想留在亚马逊上。 - - * 喜欢它的灵活性。 只需旋转一个新实例并进行调整即可。 - - * 亚马逊的脆弱让您发展得更好。 不要将所有鸡蛋都放在一个篮子里，如果某个节点出现故障，您已经处理好了，否则某些用户的流量将会丢失。 - - * 使用动态模型。 可以快速丢失实例并启动新实例。 云原生类型的东西。 随时杀死一个节点。 杀死 Redis 大师。 5 分钟后恢复。 目前已划分为所有四个美国东部可用区，但尚未跨多个区域。 - - * EBS 仅使您拥有 1TB 的数据。 他们碰到这个限制时还不知道这个限制。 使用 Couch，他们遇到了 EBS 磁盘大小限制的问题。 HipChat 的数据为 0.5 TB。 要进行压缩，Couch 必须将数据复制到压缩文件中，从而使空间增加了一倍。 在周末进行压缩时，在 2 TB RAID 上达到极限。 不需要 RAID 解决方案。 - -* 无法选择 Amazon DynamoDB，因为他们正在启动 HipChat 服务器，这是防火墙后面的托管服务。 - - * HipChat Server 推动技术堆栈上的决策。 私有版本是您自己的解决方案的主机。 某些客户无法使用云/ SaaS 解决方案，例如银行和金融机构。 NSA 吓坏了国际客户。 雇用了两名工程师来创建产品的可安装版本。 - - * Redis Cluster 可以是自托管的，并且可以像 ElasticSearch 一样在 AWS 上运行。 他们使用本地版本的 MariaDB 代替 RDS。 - - * 无法考虑完整的 SaaS 解决方案，因为这将是一个锁定。 - -* 现在过渡到 ElasticSearch。 - - * 已移至 ElasticSearch 作为其存储和搜索后端，因为它可以吃掉他们可以提供的所有数据，它具有很高的可用性，只需添加更多节点即可透明地进行扩展，它是多租户的，可以通过分片和透明方式进行透明 复制处理节点丢失，它建立在 Lucene 之上。 - - * 确实不需要 MapReduce 功能。 研究了 BigCouch 和 Riak Search（看起来效果不佳）。 但是 GET 上的 ES 性能相当不错。 喜欢删除组件的想法，少了一件麻烦的事。 ES HA 使他们对系统的可靠性感到非常有信心。 - - * 与 Lucene 兼容是一个巨大的胜利，因为他们所有的查询都已经与 Lucene 兼容，因此这是自然的迁移途径。 - - * 客户数据千差万别，从聊天记录到图像，因此响应类型无处不在。 他们需要能够快速引导来自超过 12 亿个文档的查询数据。 - - * 在一个越来越普遍的举动中，HipChat 也将 ElasticSearch 用作其键值存储，从而减少了所需的数据库系统数量，从而降低了整体复杂性。 性能和响应时间是如此之好，他们以为为什么不使用它呢？ 响应时间在 10 毫秒至 100 毫秒之间。 它在某些区域击败了 Couch，而前面没有任何缓存。 为什么要使用多种工具？ - - * 使用 ES 时，节点可能会宕机而没有人注意，您将在重新平衡时收到有关 CPU 使用率过高的警报，但它一直在困扰。 - - * 有 8 个 ES 节点来处理流量的增长。 - - * 与所有基于 Java 的产品一样，JVM 调整可能很棘手。 - - * 要使用 ES，必须对您要使用的堆空间进行容量规划 - - * 测试缓存。 ES 可以缓存过滤器结果，速度非常快，但是您需要大量的堆空间。 在 8 个盒子上有 22 个堆的内存时，打开了缓存后，内存耗尽。 因此，除非有计划，否则请关闭缓存。 - - * 缓存出现问题，因为它会遇到内存不足错误，然后失败。 群集在几分钟内自我修复。 只有少数用户注意到了问题。 - -* 由于网络不可靠，Amazon 上的自动故障转移是有问题的。 在集群中，这可能会导致选举错误地发生。 - - * 用 ElasticSearch 解决这个问题。 最初有 6 个 ES 节点作为主节点运行。 节点将耗尽内存或遇到 GC 暂停，最重要的是网络丢失。 然后其他人将不再能看到主人，也无法举行选举并宣布自己为主人。 他们的选举架构存在缺陷，即他们不需要法定人数。 因此，出现了脑裂。 两位大师。 造成了很多问题。 - - * 解决方案是在专用节点上运行 ElasticSearch 主服务器。 他们要做的就是成为主人。 从那以后一直没有问题。 母版负责处理分片的分配方式（主要是谁），并映射副本分片的位置。 由于主机可以以出色的性能处理所有重新平衡，因此使重新平衡更加容易。 可以从任何节点查询，并将自己做内部路由。 - -* 使用月份索引。 每个月都是一个单独的索引。 每个主索引都有 8 个分片，然后在其上有两个副本。 如果一个节点丢失，系统仍然可以运行。 - -* 没有将 RDS 移入 ES。 他们需要 SQL 的东西留在 RDS / MariaDB 中，通常是用户管理数据。 - -* 在主/从设置中，Redis 中有大量缓存，直到发布 Redis Cluster。 有一个 Redis stat 服务器，它在一个房间里，并且离线。 Redis 历史记录会缓存最后 75 条消息，以防止在首次加载会话时不断访问数据库。 内部状态或快速数据的状态，例如登录的人数。 - -## 常规 - -* Gearman 用于异步工作，例如 iOS 推送和传递电子邮件。 - -* AWS West 用于灾难恢复。 一切都会复制到 AWS West。 - -* Chef 用于所有配置。 ElasticSearch 为厨师提供了不错的食谱。 易于上手。 与 Chef 一样，因为您可以开始编写 Ruby 代码，而不使用 Puppet 风格的 DSL。 它还有一个不错的活跃社区。 - -* 采集经验。 他们现在可以使用公司的核心资产和人才，但是 Atlassian 不会弄乱什么可行，我们出于某种原因向您购买了。 可以在内部询问，例如，如何扩展 ElasticSearch 以及 Atlassian 中的其他人何时需要帮助才能介入。总体而言，良好的经验。 - -* 团队结构扁平。 还是一个小团队。 目前约有 18 人。 两个人在发展。 平台，iOS，Android，服务器端的一些开发人员以及 Web 开发工程师（法国）。 - -* Capistrano 用于部署到所有盒子。 - -* Sensu 用于监视应用程序。 忘记监视 ElasticSearch 节点的堆空间，然后遇到 OOM 问题，而没有任何通知。 当前占堆的 75％，这是他们想要的最佳位置。 - -* Bamboo 用于连续集成。 - -* 客户端尚未正式发布，由开发人员驱动。 有一个测试的暂存区。 - -* 组标志。 可以控制哪些组获得功能以测试功能，以缓慢释放功能并控制包装盒上的负载。 - -* 功能标志。 例如，非常适合在 ElasticSearch 推出期间提供保护。 如果他们发现错误，则可以关闭功能并回滚到 Couch。 用户不会注意到差异。 在 Couch 和 ElasticSearch 之间的过渡阶段，他们将应用程序复制到两个商店。 - -* 新的 API 版本将使用 Oauth，因此开发人员可以使用 HipChat API 在自己的服务器上进行部署。 让客户使用自己的服务器是一种更具可扩展性的模型。 - -## 未来 - -* 将在几个月内达到 20 亿条消息，并且估计 ElasticSearch 可以处理大约 20 亿条消息。 不确定如何处理预期的负载增加。 期望去 Amazon West 以获得更多的数据中心可用性，并可能使更多的用户进入不同的数据中心。 - -* 希望使用 AWS 的自动扩展功能。 - -* 进入语音，私人 1-1 视频，音频聊天，基本会议。 - -* 将来可能会使用 RabbitMQ 进行消息传递。 - -* 与 Confluence（Wiki）进一步集成。 使用 HipChat 交谈，然后使用 Confluence 页面捕获详细信息。 - -## 课程 - -* **企业应用程序**中有很多钱。 向企业推销可能会遭受酷刑。 较长的销售周期意味着可能会遇到麻烦。 但是如果你成功了，那将是一个有利可图的关系。 因此，您可能要考虑企业市场。 时代在变。 企业的发展可能仍然缓慢而缓慢，但是他们也正在采用新的工具和做事方式，那里有机会。 - -* **隐私变得越来越重要，并且在出售给企业**时会影响您的堆栈选择。 HipChat 正在制作其产品的内部版本，以满足不信任公共网络或云数据的客户的需求。 对于程序员来说，云作为平台是非常有意义的。 对于企业而言，云可能是邪恶的。 这意味着您必须做出灵活的技术堆栈选择。 如果您 100％依赖 AWS 上的服务，则几乎不可能将系统移至另一个数据中心。 对于 Netflix 而言，这可能并不重要，但是如果您想向企业市场销售产品，那就很重要。 - -* **放大以获得一些呼吸空间**。 在等待弄清楚体系结构的下一步工作时，只需很少的钱，您就可以扩大规模，并给自己提供几个月的呼吸空间。 - -* **选择不能失败的内容**。 HipChat 将永不丢失用户聊天历史记录作为优先级，因此其体系结构将此优先级反映到将聊天记录保存到磁盘，然后在宕机的系统恢复后重新加载。 - -* **转到本地** 。 您的客户在许多不同的平台上，本机应用程序将提供最佳体验。 对于拥有大量资源的创业公司来说，太多了​​。 因此，在某个时候，将产品出售给拥有更多资源的公司是有意义的，以便您可以开发出更好的产品。 - -* **功能和组标志是更好的发行实践** 。 如果您可以选择要查看功能的组，并且可以在生产和测试中关闭功能，那么您不必担心发布新版本。 - -* **选择您真正对** 充满信心的技术。 ElasticSearch 横向扩展以应对增长的能力使 HipChat 对他们的解决方案充满信心。 那个用户会很高兴的。 感觉很好。 - -* **成为过程流的一部分，您变得更有价值，并且很难删除** 。 HipChat 作为人与工具之间的自然交汇点，也是编写实现各种有用的工作流程 hack 的机器人的自然点。 这使 HipChat 成为企业中的平台。 它启用了原本无法构建的功能。 而且，如果您能够做到这一点，那么就很难摆脱它。 - -* **AWS 需要单独的节点存在总线** 。 荒谬的是，在云本身本身就是一件事，就是无法从客观的第三方来源获得机器状态信息。 如果您查看机架，它将经常有一条单独的状态总线，因此插槽可以知道其他插槽是否可用。 这样，您不必猜测。 在云中，软件使用基于 TCP 的原始连接技术和心跳来猜测另一个节点何时关闭，这可能导致脑裂问题和故障转移时的数据丢失。 现在是时候发展，并朝着可靠性迈出重大一步。 - -* **产品决策驱动器堆栈决策** 。 HipChat 服务器在技术堆栈上驱动决策。 Redis Cluster 可以是自托管的。 不能选择 Amazon DynamoDB，因为他们正在防火墙后启动托管服务。 - -* **在问题上投入很多精力只会使您到目前为止**。 您甚至需要在云中制定容量计划。 除非您的架构从一开始就完全是 Cloud Native，否则任何架构都将具有负载拐点，在这些拐点处其架构将不再能够处理负载。 看增长率。 投影出来。 什么会坏？ 您将如何处理？ 而且不要再犯同样的错误。 HipChat 将如何处理 40 亿条消息？ 不清楚。 - -* **知道系统的限制** 。 EBS 的存储限制为 1 TB，这很多，但是如果您的存储量接近该限制，则需要制定计划。 同样，如果您的数据库（如 Couch）在压缩阶段使用两倍的磁盘空间，这将影响您的限制。 - -* **世界会让您感到惊讶**。 六个月前，HipChat 认为 Redis 将是最弱的一环，但它仍将保持强劲，而 Couch 和 EBS 是最弱的一环。 - -## 相关文章 - -* [在 Reddit 上](http://www.reddit.com/r/programming/comments/1ujzel/scaling_hipchat_with_elasticsearch_and_redis/) / [在黑客新闻](https://news.ycombinator.com/item?id=7015179)上 -* [为什么您仍在构建消费者应用程序？ 企业支付的费用是原来的 4 倍！](http://www.developereconomics.com/still-building-consumer-apps-enterprise-pays-4x/) -* [HipChat 如何扩展到 10 亿条消息](http://blog.hipchat.com/2013/10/16/how-hipchat-scales-to-1-billion-messages/) -* Reddit on [HipChat 如何扩展到 10 亿条消息-HipChat 的工程师 Zuhaib Siddique 解释了其如何使用 CouchDB，ElasticSearch 和 Redis 来处理站点的负载](http://www.reddit.com/r/programming/comments/1svjjo/how_hipchat_scales_to_1_billion_messages_zuhaib) 。 -* [HipChat 搜索现在由 Elasticsearch 支持](http://blog.hipchat.com/2013/08/12/hipchat-search-now-powered-by-elasticsearch/) -* [HipChat ElasticSearch 聚会视频+幻灯片](http://zuhaiblog.com/2013/12/04/hipchat-elasticsearch-meetup-video-slides/) -* [SF ElasticSearch Meetup-HipChat 如何扩展为 1B 消息](http://www.youtube.com/watch?v=K2P7l98Uj9c) - -26 台前端服务器，每秒 60 条消息，似乎很重。 - -不错的诚实写作，谢谢。 非常丰富。 - -是的 每秒 60 条消息是不够的。 这是错字吗？ - -嗯 RTFA。 - -60 是平均，而不是一周中的全部 604800 秒。 有山峰。 - -我确定大多数前端服务器都用于与客户端的连接。 每个开放的客户端都需要维护与服务器的连接才能获取聊天消息。 每秒那 60 条消息是进来，而不是出去。 我猜如果所有的客户都在投票的话将会高出一吨。 - -这是最好的文章，我已经读过很长时间 -Mirza Tarkash - -我不知道从持久性的角度来看，它们如何处理 Redis 固有的 50％故障率。 或者也许对他们是否看到类似的表现发表评论... - -从 http://www.infoq.com/articles/jepsen - -在 2000 次写入中，Redis 声称其中 1998 年已成功完成。 但是，最终集中只有 872 个这些整数。 Redis 放弃了声称成功的 56％的写入。 - -Alex，绝对没有“ Redis 固有的 50％失败率” ...我不确定您是否正确地理解了这一点。 特别是在（希望！）罕见的“裂脑”问题中，这是一个关于他们使用它的目的（并且希望每个人都将它用于轻量级工作队列）的完全可以接受的问题。 我很高兴将 Redis 用于 API 服务器上的作业队列以及从 Logstash 进行提取，其失败率为 0。 - -此外，本文还特别提到海拔是手动的，这种情况不会发生。 更进一步，没关系，除了后端的负载。 这些是缓存服务器，而不是关键任务数据。 这确实是您完全不用担心 ACID 合规性或幻像写操作的情况。 - -很棒的文章。 肯定有帮助。 - -我确实要指出，尽管最后一段存在一些拼写和语法问题： - -> 这个世界会让您感到惊讶。 六个月前，HipChat 虽然 Redis 可能是最薄弱的一环，但它的表现仍然很强劲，而 Couch 和 EBS 是最薄弱的一环。 - -非常好的文章，但与许多服务器相比，数字 60 很小。 可能在“高峰时段”运送 600 或 6000 - -是否曾经考虑过将 Cloudant 作为扩展 CouchDB 的选择？ 它适用于 Hothead Games。 \ No newline at end of file +Facebook 可以承受破坏-“没事就可以了”-因为它并不重要！ \ No newline at end of file diff --git a/docs/118.md b/docs/118.md index 1d92f74..c19737a 100644 --- a/docs/118.md +++ b/docs/118.md @@ -1,131 +1,109 @@ -# Bazaarvoice 的架构每月发展到 500M 唯一用户 +# 神话：埃里克·布鲁尔（Eric Brewer）谈银行为什么不是碱-可用性就是收入 -> 原文： [http://highscalability.com/blog/2013/12/2/evolution-of-bazaarvoices-architecture-to-500m-unique-users.html](http://highscalability.com/blog/2013/12/2/evolution-of-bazaarvoices-architecture-to-500m-unique-users.html) +> 原文： [http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html](http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html) -![](img/0d0ef50ef3231d56345ff504f3af735a.png) +![](img/3af2dd88395161aee34fceeaed862790.png) -*这是由 [Victor Trac](http://victortrac.com) ，的云架构师 [Bazaarvoice](http://www.bazaarvoice.com) 撰写的客座 。* +在 [NoSQL：过去，现在，未来](http://www.infoq.com/presentations/NoSQL-History) [Eric Brewer](https://twitter.com/eric_brewer) 中，关于解释 [BASE 的观念通常很难理解的部分特别细腻](http://queue.acm.org/detail.cfm?id=1394128) （基本可用，软状态，最终一致）， [酸](http://en.wikipedia.org/wiki/ACID) （原子性，一致性，隔离性，耐久性）， [CAP [](http://en.wikipedia.org/wiki/CAP_theorem) （一致性可用性，分区容限），这是关于银行业一致性的神圣性的长期存在的神话。 -Bazaarvoice 是一家与人们定期进行互动但从未听说过的公司。 如果您在 bestbuy.com，nike.com 或 walmart.com 等网站上阅读了客户评论，则说明您正在使用 Bazaarvoice 服务。 这些站点以及其他数千个站点都依赖 Bazaarvoice 提供软件和技术，以收集和显示有关产品和服务的用户对话。 所有这些意味着 Bazaarvoice 会处理我们每天使用的大多数产品的很多情绪数据。 +**神话** ：金钱很重要，因此银行 必须 使用交易来保持金钱安全和一致，对吗？ -Bazaarvoice helps our clients make better products by using a combination of machine learning and natural language processing to extract useful information and user sentiments from the millions of free-text reviews that go through our platform. This data gets boiled down into reports that clients can use to improve their products and services. We are also starting to look at how to show personalized sortings of reviews that speak to what we think customers care about the most. A mother browsing for cars, for example, may prefer to read reviews about safety features as compared to a 20-something male, who might want to know about the car’s performance. As more companies use Bazaarvoice technology, consumers become more informed and make better buying decisions. +**现实** ：银行交易不一致，尤其是对于 ATM 而言。 ATM 被设计为具有正常情况下的行为和分区模式的行为。 在分区模式下，可用性是通过一致性来选择的。 -![](img/ac88b43fe350d28090d38c18fb2cd82e.png) +**为什么？** **1）**可用性与收入相关，而一致性通常不相关。 **2）**历史上从来没有完美交流的想法，所以一切都被分割了。 -*红色的框由 Bazaarvoice 提供* +您的 ATM 交易必须经过，因此可用性比一致性更重要。 如果自动柜员机（ATM）处于关闭状态，那么您就无法赚钱。 如果您可以保持一致性，坚持不懈，并弥补其他错误（这种情况很少发生），那么您将获得更多的收入。 这是大多数企业发现的空间，因此 BASE 比以前更受欢迎。 -Bazaarvoice 已集成到全球数千个网站中。 在任何给定的月份，我们将为超过 4.75 亿的唯一身份访问者提供流量。 这些访问者将浏览，阅读和贡献我们的内容，包括从产品评论到问题&答案，甚至是我们客户产品和服务的视频等内容。 这五亿人口将在我们的平台上花费大量时间，每个月的浏览量达到数百亿。 而且由于我们在众多人流量众多的商业站点上，因此我们的可靠性和正常运行时间至关重要。 如果 Bazaarvoice 平台发生故障，我们将影响成千上万依赖我们的网站。 为了快速，可靠地完成所有这些工作，我们设计了一个高度冗余的堆栈，该堆栈主要建立在 Amazon Web Services 之上。 +对于金融业来说，这不是一个新问题。 他们从来没有保持过一致，因为历史上他们从来没有过完美的沟通。 相反，金融业依赖审计。 导致银行数据一致性的原因不是其数据库的一致性，而是所有事实都被 [写下两次，然后稍后使用](https://en.wikipedia.org/wiki/Double-entry_bookkeeping_system) 进行整理。 不可更改的记录，以后再进行核对。 对错误进行财务补偿的想法是深深植根于金融系统的想法。 -假期购物旺季是我们基础设施最繁忙的时间。 在“黑色星期五”和“网络星期一”，我们会看到流量非常高，从今年年底到 1 月，我们的负荷一直很高。 这就提出了一个独特的扩展挑战，因为我们必须在一年中的 3-4 个月内处理几乎两倍于正常（并且一直在增长）的流量。 今年，我们预计在假日购物旺季每秒将收到 6 万至 6.5 万次请求。 +在文艺复兴时期，当[现代银行系统](http://en.wikipedia.org/wiki/Luca_Pacioli)初具规模时，一切都被分割了。 如果信件（您的数据）是通过马或轮船运输的，那么您的数据可能会保持非常低的一致性，但是它们仍然拥有令人惊讶的丰富而成功的银行系统。 交易是不必要的。 -![](img/2d16b3bf996e1933bc61dc768241e956.png) +例如， ATM 选择了 [交换操作](http://en.wikipedia.org/wiki/Serializability) 之类的递增和递减操作，因此操作顺序无关紧要。 它们是可重新排序的，以后可以使其保持一致。 如果 ATM 与网络断开连接，并且当分区最终恢复正常时，ATM 发送将操作列表发送到银行，并且期末余额仍然正确。 问题很明显，您可能会提取比您更多的钱，因此最终结果可能是一致的，但为负数，无法通过要求退款来弥补，因此，银行将向您奖励透支罚款。 -*假期前到我们平台的带宽和 HTTP 请求的一周视图* +隐藏的哲学是您试图 **约束并管理风险，** 仍然可以进行所有操作。 在 ATM 机中，这将限制您一次可以提取的最大金额。 风险不大。 自动取款机是有利可图的，因此偶尔的损失仅仅是开展业务的风险。 -## 卑微的开端 +事实证明，这不是圣杯。 胜过一致性的是： -与大多数大型软件堆栈一样，我们从一个非常简单的体系结构开始。 我们最初的应用程序是使用 MySQL 作为数据存储的单个整体 Java 应用程序，所有这些程序都在托管主机环境中运行。 随着我们这些年来的成长，我们在相同的代码库上构建了其他应用程序，并增加了新功能。 我们是 Solr 的早期用户，它使我们能够将 MySQL 主要转变为键值存储。 除了 Solr，我们通过仅给 JVM 更多的 RAM 或将 MySQL 服务器放在更快的盒子上来垂直扩展。 +* 审核 +* 风险管理 +* 可用性 -然而，正如一位经验丰富的工程师所知道的那样，垂直缩放所带来的容易的早期收益很快变得难以实现。 因此，我们通过简单地复制整个堆栈开始水平扩展。 我们称这些为“集群”，它们使我们无需进行较大的应用程序更改即可实现水平扩展。 +在以写可用性为关键的后互联网世界中，现实世界看起来更像*弱一致性+延迟异常+补偿*，而不是完美的沟通和交易的无错误世界。 就像过去一样，但现在您在 ACID <-> CAP 频谱上有更多选择。 -![](img/c6bd7774dfcea43b9076ec0362aa58be.png) +## 相关文章 -*每个群集都是具有不同数据的整个堆栈的副本。* +* [关于 HackerNews 2](https://t.co/VMC2IA1K0I) +* [讨论黑客新闻](https://news.ycombinator.com/item?id=5642010) +* [](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html)[Google Spanner 最令人惊讶的启示：NoSQL 出炉了，而 NewSQL 出现了](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html) -在 2008 年，Bazaarvoice 大约 3 岁时，我们在托管数据中心经历了一些停机时间，这使我们面临着更多冗余的挑战。 一种选择是简单地在另一个地理区域中找到另一个托管服务提供商，然后复制我们所有的服务器。 但是，由于我们使用的是 MySQL，因此我们无法轻松地跨地区使用多主机。 因此，我们最初的计划只是从主托管数据中心运行 MySQL 复制，并保持足够的容量以热备份方式在备份区域中为生产流量提供服务。 如果我们的主数据中心发生故障，我们将更新 DNS 以指向备份数据中心。 但是，这将意味着很难进行单向故障转移，因为 MySQL 从属服务器将被提升为主服务器。 +真的很有趣。 当然，课程必须实施广泛的审核功能，以弥补潜在的不一致问题，并在发现问题时尝试和纠正流程 -为使从属数据中心在灾难中真正发挥作用，我们需要保留足够的备用容量来服务我们 100％的生产流量，从而在不增加生产能力的情况下有效地使托管成本增加一倍。 +这带来了银行认为可以接受的复杂程度，因为收益非常可观。 但是并不是每个组织或其应用程序都可以忍受这一点-因此仍然有很多地方需要保持一致性 -### 输入 AWS +嗨，托德， -作为当时的年轻创业公司，我们无法简单地将托管成本提高一倍。 Amazon Web Services 在一个月前（即 2008 年 10 月）刚刚从 EC2 删除了“测试版”标签，因此我们认为这可能是一个绝佳的机会，可以利用这种新型云技术在我们的备用站点上节省资金。 +我不确定您的所在地，但该示例在英国似乎并不成立。 我不知道实际的实现方式，但是在免费的 ATM 交易环境中，可用性似乎并不是主要问题。 自动柜员机停运并不罕见，而且，超出您的限额将导致机器拒绝为您提供所要求的现金。 -在 EC2 上构建冗余备份站点时，我们的策略与使用备份数据中心基本相同，除了不必为机架中准备就绪的服务器付费，我们只需要运行 MySQL 从属即可。 。 当我们需要故障转移到 EC2 时，我们可以按需启动实例。 这样做的成本只是在另一个数据中心复制整个生产堆栈的成本的一小部分。 +尽管如此，有关换向运算的有趣观点。 -![](img/fc5acb3d325b9272d01cb23ce2503d14.png) +干杯， +蒂姆 -*我们最初尝试使用 MySQL 从站进入 Amazon Web Services。* +我不知道这是否可行，因为钱是可替代的-银行从我那里获得的 1 美元报酬与自动柜员机应支付的 1 美元没有明显的不同。 -幸运的是，我们无需执行故障转移计划。 但是，当我们决定要在托管数据中心和 Amazon us-east-1 地区之外提供实时流量时，我们使用 EC2 的经验使我们有足够的信心继续使用它。 我们的数据已经被复制到 us-east-1 中，因此我们只需要启动应用程序实例并在应用程序堆栈上进行一些小的工程设计即可使其适合实时请求。 +如果我使用了错误的约会资料并承诺“以后再补”，则效果不一样。 :) -AWS us-east-1 设计为只读，可与 MySQL 复制完美配合。 当最终用户向 AWS 提交新的内容时，这变得更加复杂，因为 AWS 中的 MySQL 是只读的。 我们通过编写一个基于 MQ 的提交队列解决了这个问题，该队列将写操作复制回我们的主数据中心，在此我们在 MySQL Master 上执行写操作。 在几秒钟内，更改将被复制回 AWS。 此设置运行良好，使我们能够将生产能力提高一倍，同时仍然使我们能够在必要时完全故障转移到 AWS。 不久之后，我们决定将 us-east-1 集群复制到 us-west-2，从而为我们提供了三个实时生产区域。 +蒂姆 -[ ![](img/0aebf030454a13f9c9b7b60774a640d4.png) +我也在英国，并且同意 ATM 系统乍看之下在英国似乎并不那么清楚，但我相信它仍然是正确的。 -*MySQL 从我们的托管数据中心复制到两个 AWS 区域。* +我相信，使 ATM 脱机的原因是 ATM 与它用于验证卡号并快速检查卡是否被举报为欺诈性的服务之间的断开连接。 每个 ATM 提供商（实际上是银行组）似乎确实要分别运行其系统，然后再将它们一起应用。 -为了在两个 AWS 区域与我们的托管 DC 之间路由请求，我们采用了基于 DNS 的健康检查系统。 在 EC2，我们使用在具有 EIP 的实例上运行的 HAProxy 作为负载均衡器。 这使我们在 EC2 的每个区域的每个群集获得一个公共 IP，在我们的托管数据中心的每个群集获得一个公共 IP。 我们将这些原始 IP 添加到了我们的 DNS 服务的基于 DNS 的运行状况检查池中，该池定期向每个原始 IP 发出 HTTP 请求。 DNS 服务器会拉出所有在运行状况检查中失败的原始 IP，同时平衡到其他区域的流量。 这样做的一个附带好处是，我们可以轻松地拆除一个区域并一次滚动部署（一个区域一次），让 DNS 处理流量的转移。 +我当然已经看过自动取款机说不能显示我的余额，但是可以提款。 -多年来，随着我们获得成千上万的客户并将流量扩展到每月数十亿的页面浏览量，我们最终获得了运行在 3 个 AWS 区域和受管理数据中心的 7 个集群中的数百个应用程序服务器。 每个集群都有一个主数据库，在三个区域中都有大量的从属链。 如果沿链上的中继从机死亡，我们将必须重建所有下游从机以重置主机位置。 从操作的角度来看，这变得非常难以管理。 我们还有两个重要的写流量瓶颈：在托管数据中心运行的 MySQL 主服务器和在所有从服务器上的 MySQL 单线程复制。 当我们不得不摄取大量新数据时，奴隶通常会落后一些，有时甚至要花 10 个小时或更长时间。 我们需要重新考虑整个堆栈。 +如果这样的分区是为什么在周末/银行假日不进行任何交易，而您仍然可以使用您的卡，我不会感到惊讶。 -## 从干净的板岩开始 +另一个蒂姆 -在 2011 年底，我们的堆栈正在工作，但我们希望将其提升到更高的灵活性，性能和可靠性水平。 我们想解决我们的多区域复制问题。 我们希望摆脱单个集群，以便我们可以做更多有趣的跨集群数据关系。 我们想更快地发布。 我们希望成为更多的云原生用户，以便能够利用自动扩展等 AWS 功能。 这是很大的变化，但是我们从 Amazon Web Services 获得了一个新的 CTO，他非常支持这些计划。 +A 罐（应该）仍代表原子。 谁想要一半的交易伪装成整个交易？ -### 组织和技术变更 +我在 atm 网络上工作了多年，是的，它们都像这样工作。 今天，大多数网络都以在线模式工作。 但是协议支持脱机交易。 请记住，这些网络也支持信用卡交易（可以在授权交易后应用提示）。 脱机模式可用于支持断开连接的情况或启用可伸缩性，验证是联机的，但金融交易是分批的。 完全断开连接的可能性较小，因为必须在线检查引脚（至少直到芯片和引脚为止）。 -我们的整体 Java 应用程序分为一组小型服务，每个小型服务均由分散的工程团队提供支持。 这些团队负责从开发到质量检查再到运营的整个服务生命周期。 此外，工程学采用敏捷作为开发方法，以前我们是在瀑布驱动下进行的。 这些更改使我们能够从高度协调的 8-12 周发布周期转变为允许任何团队随时发布。 一些团队继续进行完整的持续集成。 +从 atm 到后台，事务不是原子的，如果发生通信错误，则可以撤消事务。 一些自动取款机交易被标记为强制过帐，以表明已经发放了款项，即使它们违反了办公室规定（如不透支）也已得到处理。 -在技术方面，我们决定在新堆栈中全力支持 AWS。 对于我们的记录系统，我们选择 Cassandra 是因为它具有多区域复制功能（DynamoDB 在这里失败）和云原生操作质量。 出于类似原因，ElasticSearch 取代了 Solr。 +这些细节中的一些是西方过去的遗迹，但是在非洲，南美和印度，长距离通信可能非常繁琐，因此中断的操作仍然非常重要。 -### 云工程师 +尽管 Atm 交易是免费的，但信用卡交易涉及银行收费和商人收入。 当服务不可用时，也会损害声誉。 在金融危机爆发的第一年左右，有很多关于不同机构的传言。 这些机构非常担心服务中断会触发其银行挤兑。 -我们成立了一个名为 Platform Infrastructure 的团队，负责构建 AWS 基础设施和云工具。 平台基础架构团队选择使用 CloudFormation 在 Amazon 的虚拟私有云环境中的三个区域（us-west-2，us-east-1 和 eu-west-1）中构建 AWS。 然后，平台基础架构团队构建了有用的微服务，例如内部 VPC DNS，内部监控，集中式日志记录，成本分析，甚至是受 Netflix 启发的“猴子”，以执行标签一致性实施。 由于所有内容都使用 CloudFormation，因此我们能够在几个小时内迅速为三个区域的 Dev，QA 和 Prod 环境启动相同的 VPC。 这个内部称为 Nexus 的新平台负责“繁重”的基础架构，并为应用程序团队构建服务奠定了坚实的基础。 +干得好，保持下去 -![](img/2135e8becff618ccfdcc34b1170ad9af.png) +好的文章，内容翔实，有趣，重点突出。 -*Nexus：三个 AWS 区域中跨九个 VPC 的三个环境。 来自类似环境的 VPN。* +Tim, -### VPC 基础架构 +>可用性似乎并不是主要问题。 自动柜员机停运并不罕见 -除了环境标签，IP 范围（当然还有数据集）之外，每个 VPC 看起来都相同。 每个 VPC 使用一个/ 20 子网，分为三个/ 24 公共子网和三个/ 22 私有子网，每个 VPC 使用三个可用区。 我们的 CloudFormation 模板还使用自动缩放组 1 来为每个可用区配置 1 台 NAT 服务器，并设置路由，以便每个专用子网使用其自己的 NAT 服务器进行出站连接。 这允许 AZ 级别的隔离，并使 NAT 带宽增加三倍，而不是每个 VPC 使用单个 NAT 服务器。 +高不可用性率并不能证明可用性不是 OP 中规定的最高优先级。 它只是表明所讨论的网络在实现该优先级方面很差。 -![](img/eb5c1b211a11153c77f396b631550918.png) +>超出您的限制将导致机器拒绝为您提供所要求的现金。 +同样，这并不是可用性优先于一致性的禁忌。 本文的风险管理部分对此进行了介绍。 -*每个 VPC 使用三个可用区，每个可用区都有自己的 NAT 实例。* +本文缺少的是认识到，在银行发布的实际财务更新包含的内容远不止简单的余额更新。 可能会有几十个表被更新，甚至更多。 所有这些工作必须是原子的。 ATM 网络具有备用功能，可以在多个级别上进行不可靠的通信或主机丢失，但是当消息到达银行时，它最终是一个很好的老式 ACID 更新。 ATM 和在线信用卡交易系统及其支持的登录，强制发布，预授权，部分和增量授权等功能，使网络变得非常可用，这仅仅是因为各机构已选择达成一项协议 彼此都很好。 银行系统不太愿意让提款部分过帐。 -我们为每个工程师提供了一个完整的 AWS IAM 帐户，使他们可以不受限制地访问 Amazon 的各种更高级别的服务，例如简单工作流程服务，Elastic MapReduce 和 Redshift。 我们选择优化工程师敏捷性而不是效率。 但是为了确保我们的成本不会完全失控，平台基础架构团队会强制执行标签一致性。 为了保持一致，每个团队必须在其所有资源中使用两个标签：team 和 VPC。 没有适当标签的任何 AWS 资源都会自动终止。 拥有一致且强制的标记的一个巨大好处是，我们能够确定每个团队的确切成本。 +谢谢，不错的帖子 -### 数据层 +有趣的文章，感谢您提供信息。 -我们的数据团队提供了三项服务来处理我们的海量数据集，所有这些服务均针对开发人员的生产力和易于管理进行了优化。 为了存储通用的内容类型而不需要进行模式迁移，并且能够表达性地查询我们的数据，EmoDB 和 Polloi 诞生了。 在 Cassandra 的支持下，EmoDB 设计为使用最终一致性（AP）和多主机冲突解决方案来跨越多个数据中心。 它公开了一个非常简单的 RESTful API，允许用户创建“表”（不需要模式-仅表名和表放置），并将文档存储在这些表中。 +真正不幸的是，信息开发人员必须受到来自 Web 开发社区的此类论点的轰炸。 -EmoDB 仍然缺少 SQL 语义，例如 where，join，group by-基本上是除主键查找和表扫描之外的任何其他语义。 这就是 Polloi 的来历。 +经典的 ATM 示例不应该从字面上理解，而是重要交易的象征。 最容易理解的一种。 -Polloi 将实体流索引到 ElasticSearch 集群中。 每个表的索引是根据用非常简单的域特定语言（DSL）指定给 Polloi 的规则完成的。 一旦 Polloi 根据这些用户指定的规则为数据建立了索引，我们最终将获得一个功能强大的 ElasticSearch 集群，该集群不仅可以处理主键查找。 而且由于每个 Polloi 集群都有一个自定义的规则集，所以我们有多个 Elasticsearch 集群，每个集群都针对使用它们的应用程序的需求进行了调整。 应用程序可以利用 ElasticSearch 的强大功能来对 PB 级数据进行超快速的查询响应。 +现代银行机构已经实施了风险管理以促进可用性的事实，并没有改变任何与 ACID 兼容的交易的重要性！ -ElasticSearch 仍需要与 EmoDB 保持同步，因此我们创建了数据总线以将 EmoDB 和 Polloi 结合在一起。 Databus 允许应用程序监视 EmoDB 表和文档上的更新事件，而 Polloi 侦听 Databus 上的实时更新并适当地索引数据。 +在我的银行存款，我每 24 小时只能提取 500 美元（风险）（保持一致的时间）。 让我们想象一下一项新法律，银行将不再采取此类措施？ 哪里有人可以拿出大笔现金？ 银行将很快从 BASE 变为 ACID！ -![](img/dd67ceeca2fe2bab9d388a27bae14377.png) +今天的最终一致性如何？ -*EmoDB，Polloi 和数据总线* +这是关于分发帐单，以及在有人关心的情况下移动零碎的东西。 -简而言之，EmoDB 提供了一种简单的方法来存储 JSON 对象，对特定应用程序很重要的 Polloi 索引字段，并且 Databus 会将数据的更改通知 Polloi 以及其他任何人。 - -### 应用层 - -随着转向面向服务的体系结构，我们的工程师不再受限于特定的技术堆栈。 服务团队可以选择最适合他们的语言和组件。 尽管大多数团队仍然选择使用 Java 来实现其服务，但 Python 和 node.js 是另外两个受欢迎的选择。 - -此外，团队可以自由选择 Amazon 的更高级别的服务，例如简单队列服务（SQS），简单通知服务（SNS）甚至简单工作流服务（SWF）。 现在，我们最成功的服务之一就是很大程度上基于 SWF，使 Bazaarvoice 成为亚马逊最大的 SWF 用户之一。 使用这些 AWS 服务使团队能够比以前更快地构建其服务。 - -### CDN & DNS - -我们遗留在堆栈中的两个组件是 CDN 和基于 DNS 的全局流量管理层。 他们俩都运作良好，因此我们不认为需要为改变而做出改变。 - -![](img/8e2a1eb1f33f3816c5780b3d1324c6e9.png) - -*Bazaarvoice 的新堆栈的高级概述。* - -## 未来 - -随着我们在新堆栈上增加生产工作量，我们一直在寻找改进的地方。 我们计划在应用程序部署，基于代理的异常检测方面实现更多自动化，并提高我们的运营效率。 我们还构建了一些有用的 AWS 工具，希望在不久的将来开源。 - -如果您对我们架构的任何方面都感兴趣，请发表评论或 [直接与我联系](http://twitter.com/victortrac) 。 - -很好的文章。 我很喜欢阅读您如何将可搜索性与可伸缩键值存储合并。 - -解释得很好，路径清楚地显示了简单应用程序如何转换为大型企业应用程序。 - -喜欢该架构的详细视图，并且通过视觉插图更容易理解。 写得很好 - -做得好！ 我希望这会不断发展！ 这非常有帮助。 很棒的博客！ \ No newline at end of file +考虑到关于 ACID 的评论中的论点，我真的很想读这本书的续集。 \ No newline at end of file diff --git a/docs/119.md b/docs/119.md index c2d9727..e05f8bb 100644 --- a/docs/119.md +++ b/docs/119.md @@ -1,193 +1,313 @@ -# 如何制作无限可扩展的关系数据库管理系统（RDBMS） +# 一千万个并发连接的秘密-内核是问题，而不是解决方案 -> 原文： [http://highscalability.com/blog/2013/11/25/how-to-make-an-infinitely-scalable-relational-database-manag.html](http://highscalability.com/blog/2013/11/25/how-to-make-an-infinitely-scalable-relational-database-manag.html) +> 原文： [http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html](http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html) -![](img/47662846edb26e957c51b995b2f12179.png) + -*这是 [InfiniSQL](@infinisq) 的创始人 [Mark Travis](@infinisq) 的来宾帖子。* +现在我们遇到了 [C10K 并发连接问题](http://www.kegel.com/c10k.html) ，我们如何升级并支持 1000 万个并发连接？ 你说不可能。 不，目前，系统正在使用可能不熟悉的根本技术提供 1000 万个并发连接。 -[](http://www.infinisql.org)InfiniSQL 是标题所指的特定“无限扩展 RDBMS”。 它是免费软件，有关其获取，构建，运行和测试的说明，请参见[指南](http://www.infinisql.org/docs/guide/)。 [基准测试](http://www.infinisql.org/blog/2013/1112/benchmarking-infinisql)显示，一个 InfiniSQL 群集每秒可以处理 500,000 个复杂事务，并具有 100,000 多个并发连接，所有这些都位于十二台小型服务器上。 测试的方法已记录在案，并且所有代码都可用，因此任何从业人员都可以取得类似的结果。 InfiniSQL 具有两个主要特征： +要了解其操作方法，我们求助于 Errata Security 的首席执行官 [Robert Graham](https://twitter.com/ErrataRob) ，以及他在 [上的精彩演讲 Shmoocon 2013](https://www.shmoocon.org/) 被称为 [C10M 大规模防御互联网](http://www.youtube.com/watch?v=73XNtI0w7jA#!) 。 -1. 它比任何集群/分布式 RDBMS 更好地执行在多个节点上具有记录的事务 -2. 它是免费的开放源代码。 不仅仅是具有专有技术的预告片“社区”版本。 准备就绪时，InfiniSQL 的社区版本也将是企业版本。 +罗伯特有一个绝妙的方式来解决我从未听说过的问题。 他从一些历史开始，讲述了最初不是将 Unix 设计为通用服务器操作系统，而是将其设计为电话网络的控制系统。 电话网络实际上是在传输数据，因此控制平面和数据平面之间存在清晰的分隔。 **问题是我们现在将 Unix 服务器用作数据平面**的一部分，我们根本不应该这样做。 如果我们要设计一个内核来为每个服务器处理一个应用程序，那么它的设计将与多用户内核的设计大不相同。 -InfiniSQL 仍处于开发的早期阶段-它已经具有许多功能，但是要使其在生产环境中有用，还需要更多的功能。 +这就是为什么他说关键是要理解： -## 谁会做这种事情？ +* 内核不是解决方案。 **内核是问题**。 -我的职业背景可以在 [LinkedIn](http://www.linkedin.com/pub/mark-travis/1/a3a/1a2) 上找到。 我已经为一些相当大的事务处理环境进行了容量规划，系统工程，性能工程等工作，其中几秒钟的停机时间使成千上万的客户损失了成本。 保姆式的环境告诉我，传统的企业数据库基础结构非常适合需要 24x7 全天候运行，持续增长并快速响应新业务需求的现代环境。 这确实是一个典型的故事-我们都知道 70 年代设计的系统无法满足当今的需求。 因此，我决定构建适合现代事务处理环境的东西。 +表示： -## 目标用户/用例 +* **不要让内核完成所有繁重的工作**。 将数据包处理，内存管理和处理器调度从内核中移出，然后将其放入应用程序中，从而可以高效地完成它。 让 Linux 处理控制平面，让应用程序处理数据平面。 -我敢肯定，大多数[高可扩展性](http://highscalability.com/)的读者都会理解为什么新的数据库体系结构如此必要的原因，而且我们当中许多人也认为更快，更大的规模是自我调整的价值。 我们就像赛车手。 但是重要的是要知道用例，以帮助其他人学习如何利用我们正在构建的强大功能。 就 InfiniSQL 而言，有几种主要客户类型，每种类型都有各种特定的用例。 我将简要介绍一下客户类型，以及我如何看待 InfiniSQL 为他们解决业务问题。 +结果将是一个系统可以处理 1000 万个并发连接，其中 200 个时钟周期用于数据包处理，而 1400 个时钟周期用于应用程序逻辑。 由于主存储器访问需要 300 个时钟周期，因此设计的关键在于最大程度地减少代码和缓存丢失。 -* Look no further than the example application cited in [Design Decisions For Scaling Your High Traffic Feeds](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html), which is a very recent entry on this site. Imagine there's no *Part Two* and *Part Three*, meaning that their original RDBMS of choice was able to perform "`select * from love where user_id in (...)`" well beyond 100M rows and 1M users. There'd be no need to design a new framework from scratch, or to rip and replace two back ends before settling on one that seems fine for the time being. InfiniSQL is capable of performing that kind of query. I haven't benchmarked that specific workload--but it's the type of thing that I designed InfiniSQL for: transactions with records distributed across multiple nodes. +使用面向 **数据平面的系统** ，您每秒可以处理 1000 万个数据包。 使用面向控制平面的系统，您每秒只能获得一百万个数据包。 - 成功的 Internet 应用程序几乎不可避免地从它们启动时所使用的基础结构中发展而来。 RDBMS 通常是首选的初始数据库-但实现了变通方法，并且实现了完全不同的体系结构-所有这些都是因为原始数据库无法处理成功。 那是一个非常破坏性的过程。 InfiniSQL 适用于具有 RDBMS 工作负载但由于其原始 RDBMS 不能随业务增长而被迫实施变通方法的任何公司。 这些解决方法包括分拆 SQL 数据库以及将一些工作负载迁移到各种 NoSQL Point 解决方案。 实际上，InfiniSQL 应该成为公司开始使用的数据库，以避免将来的迁移成本。 +如果这看起来很极端，请记住一句老话： **可伸缩性是专业化** 。 要做到出色，就不能将性能外包给操作系统。 你必须自己做。 -* InfiniSQL 的另一类目标用户包括那些在单片平台上负责每秒处理数以万计的复杂事务的应用程序的用户。 这种工作负载很难脱离大型系统架构。 这类公司包括信用卡协会，旅行预订系统和交易所。 这些不是新的业务模型。 数十年来，他们的基础设施一直在挣扎。 他们执行的每项操作都代表着（至少）两方之间的资金转移-他们转移了人们的资金。 稳定性和数据完整性是最重要的价值。 InfiniSQL 能够以预期的数量和更高的容量执行此类工作负载，但可以在运行 Linux 而不是大型的超昂贵平台的 x86_64 服务器上执行。 实际上，InfiniSQL 会进一步扩展-因为这些大型的整体平台在其扩展插槽用完的情况下会用光。 +现在，让我们学习 Robert 如何创建一个能够处理 1000 万个并发连接的系统... -## 问题及其原因（以及几个相关问题） +## C10K 问题-过去十年 -（如果我能找到其他在我之前说过的夸夸其谈的声明，我会编成信誉，否则，我会接受-每个人都需要报价，对吗？我会接受。） +十年前，工程师解决了 C10K 可伸缩性问题，该问题阻止服务器处理 10,000 多个并发连接。 通过修复操作系统内核并从线程服务器（如 Apache）移至事件驱动的服务器（如 Nginx 和 Node），解决了该问题。 随着人们从 Apache 转移到可伸缩服务器，此过程已花费了十年的时间。 在过去的几年中，我们看到了可扩展服务器的更快采用。 -*问题*使多个节点全部组成一个数据库。 通过将静态 Web 服务器与数据库进行比较，可以轻松说明此问题。 通过简单地将 Web 服务器的内容镜像到不同的盒子上，然后以循环方式或其他方式向它们喷射流量，来扩展 Web 服务器很简单。 简单。 但是对于数据库而言，并不是那么简单。 取两个盒子，然后将您喜欢的数据库放在上面。 给每个相同的模式。 然后，连接到框 A 并插入一条记录-任何旧记录。 然后连接到方框 B 并查找该记录。 当然不存在！ 这就是水平扩展数据库的问题：逻辑和数据都在同一个盒子中！ +### Apache 问题 -### 锁定主要是坏的 +* Apache 问题是连接越多，性能越差。 -传统数据库设计在性能方面的另一个问题是锁定。 为了数据完整性，每个工作程序（线程或进程）都锁定与其操作的记录关联的内存或存储区域。 这些不是高级数据锁，例如行或表锁（尽管它们也可能有问题）。 不，它们被实现为互斥或信号量。 互斥体和信号量是多线程/进程应用程序阻止其他线程/进程踩踏共享数据的方式。 随着共享内存区域的锁争用增加，性能下降。 锁定争用的一个很可能的指标是数据库速度很慢，但是有大量可用的 CPU，并且没有 I / O 瓶颈。 +* 关键见解： **性能和可伸缩性或正交概念** 。 他们不是同一回事。 人们谈论规模时，通常是在谈论绩效，但是规模和绩效之间是有区别的。 正如我们将在 Apache 中看到的那样。 -### I / O 慢，没有问题，它有多快 +* 对于持续几秒钟的短期连接（例如快速交易）来说，如果您要执行 1000 TPS，则与服务器的并发连接数只有 1000。 -传统数据库的另一个大性能问题是事务日志瓶颈。 为了[持久性](http://en.wikipedia.org/wiki/Durability_(database_systems))，传统数据库在完成事务之前，会将包含书面记录的所有事务实时实时写入等效于日志文件的日志。 当电源关闭时，当指示灯重新点亮时，数据仍将存在。 问题在于这会减慢写入速度。 在最快的固态存储和海量 I / O 总线上使用任何经过调整的数据库。 它将成为写入事务日志的瓶颈。 +* 将交易时间更改为 10 秒，现在以 1000 TPS 的速度打开了 1 万个连接。 尽管 Apache 的性能下降了很多，但这使您容易受到 DoS 攻击。 只需进行大量下载，Apache 就会崩溃。 -## InfiniSQL 解决这些问题的方法 +* 如果每秒处理 5,000 个连接，并且要处理 10K，该怎么办？ 假设您升级硬件并将处理器速度提高了一倍。 怎么了？ 您可以获得双倍的性能，但规模却没有双倍。 规模只能达到每秒 6K 个连接。 如果您继续加倍，也会发生同样的事情。 性能提高了 16 倍，但您仍未达到 1 万个连接。 性能与可伸缩性不同。 -InfiniSQL 并不是解决某些或所有这些问题并成功实现集群 RDBMS 的唯一项目。 我敢肯定，此博客的大多数读者都知道这样的各种系统，即使它们还不是用户。 我正在描述如何解决这些问题，以及它们如何有助于 InfiniSQL 的独特优势。 其他人则以自己的方式解决了这些问题。 +* 问题是 Apache 会派生一个 CGI 进程，然后将其杀死。 这没有规模。 -### 演员们 +* 为什么？ 由于内核中使用 O（n ^ 2）算法，服务器无法处理 10K 并发连接。 -InfiniSQL 在并发编程的[参与者模型](http://en.wikipedia.org/wiki/Actor_model)上实现了一种变体。 C ++是用于创建 InfiniSQL 的主要语言，该语言本身不支持 actor 模型。 实现 InfiniSQL 的许多工作涉及使角色在 C ++中工作。 actor 模型通过将事务处理逻辑与存储断开耦合并且不锁定内存区域来解决上述前两个问题。 有关详细信息，请阅读[概述](http://www.infinisql.org/docs/overview/)。 这与传统的 RDBMS 体系结构完全不同。 + * 内核中的两个基本问题： -角色模型解决了[问题](#0.1_theproblem)，因为处理逻辑由一组角色处理，而数据存储由另一组角色处理。 它们的功能在 InfiniSQL 中松散耦合。 无论参与者位于哪个节点，消息传递都是在参与者之间进行的：管理特定事务的参与者不知道或不在乎数据是驻留在本地还是远程。 并且管理特定数据分区的参与者响应消息，而不管其来源。 从理论上讲，参与者模型允许 InfiniSQL 无限扩展。 基于其第一字段的哈希值将每个记录分配给特定的数据区域，并且基于索引值的哈希将每个索引记录分配给一个区域。 + * 连接=线程/进程。 当一个数据包进入时，它将遍历内核中的所有 10K 进程，以确定哪个线程应该处理该数据包 -actor 模型的另一个有益效果是它解决了低级别锁定的问题。 由于每个数据区域仅具有一个关联的参与者，因此不需要互斥或信号量来限制访问。 分区的参与者根据来自交易参与者的消息来处理对数据操作的请求。 发送方参与者无需等待（阻止）等待响应，而是可以自由地处理其他任务。 当分区的 actor 用数据响应时，发出请求的事务 actor 从中断的地方继续。 它要么完成交易并向客户端发送回复，要么与其他参与者保持互动。 + * 连接=选择/轮询（单线程）。 同样的可扩展性问题。 每个数据包都必须经过一个套接字列表。 -下面的示例试图以图形方式说明数据库设计的传统共享内存模型与 InfiniSQL 的参与者模型之间的区别： -![](img/367dba9abe58928326d901f36d675357.png) -对于参与者，没有 锁定。 当需要更多处理时，将添加更多的参与者，每个参与者*大致*最佳对应于单个 CPU 线程或内核。 随着内核的添加，基于角色的体系结构可以保持很好的状态。 但是，传统的锁定共享内存模型在添加内核方面会遭受更多的痛苦-因为锁争用只会增加。 大型整体数据库具有非常复杂的锁管理方法，可以最大程度地减少此问题。 + * 解决方案：修复内核以在恒定时间内进行查找 -actor 模型的另一个好处是它支持大量并发。 InfiniSQL 实现角色的方式与传统角色模型略有不同，但是在保持高吞吐量的同时，它仍然可以实现很高的连接速率。 大多数传统数据库都有一个连接阈值，超过此阈值，聚合系统的性能将大大降低。 这主要与已经描述的争用有关，并且还因为每个连接的成本都很高-如果每个客户端在服务器端都需要专用的进程（或线程），则会消耗大量内存。 此外，高度多线程的应用程序会遭受过多的上下文切换。 内核调度程序始终必须使线程进入睡眠状态，复制它们的状态，然后复制并激活另一个线程。 使用 InfiniSQL，维护每个连接的成本相对较低-内核必须管理一个开放的套接字。 另外，将创建一个用于管理连接的对象。 添加了两个地图条目，以允许相关角色识别连接。 与必须启动一个新线程（更不用说进程）相比，每个连接的开销要低得多。 为了最大程度地减少上下文切换，每个参与者大致对应一个 CPU 线程，因此等待 CPU 的线程更少。 + * 现在，无论线程数量如何，线程都会进行恒定时间上下文切换。 -为了解决 I / O 缓慢的问题，InfiniSQL 目前已成为内存数据库，从而避免了这种情况。 与块支持的存储相比，在内存中实现起来更简单，尤其是使用 actor。 但这显然带来了一些问题。 即，耐久性和成本。 如果断电，则内存中数据库的单个副本将消失。 并且 RAM 的成本高于磁盘的成本。 [概述](http://www.infinisql.org/docs/overview/)描述了计划在开发工作中花时间解决这些问题的计划。 + * 引入了新的可扩展 epoll（）/ IOCompletionPort 恒定时间套接字查找。 -InfiniSQL 计划的内存持久性的关键在于强调-它是从高端存储领域借来的。 高端存储系统之所以表现出色，是因为它们将更改写入内存中，并且仅在以后将这些更改写入磁盘中。 他们可以避免这种情况，因为它们具有冗余的备用电池系统，并且每次写入都分布在多个缓存区域中。 断电或单点故障都不会导致高端存储系统中的数据丢失，这才是真正重要的。 世界上最大的交易处理平台依赖于这种存储阵列。 除了冗余和电源管理将保护数据库服务器节点本身以外，InfiniSQL 打算实现相同的模型。 这尚未完全实现，但是如果可用，将意味着 InfiniSQL 将提供持久的内存性能。 +* 线程调度仍无法扩展，因此服务器使用带有套接字的 epoll 进行扩展，从而导致 Node 和 Nginx 中体现了异步编程模型。 这将软件转移到不同的性能图表。 即使在服务器速度较慢的情况下添加更多连接，性能也不会下降。 连接数为 10K 时，笔记本电脑甚至比 16 核心服务器还要快。 -## 事务处理 +## C10M 问题-下一个十年 -事务处理的详细信息在[概述](http://www.infinisql.org/docs/overview/)中进行了描述。 我发现使用参与者实现 ACID 功能的原因是还需要实现其他技术。 即，参与者间远程过程调用（RPC）是一种在 OSI 模型和后续版本上受到宽松启发的本地协议栈。 这引入了一定程度的实现复杂性-我正在寻找重构和降低复杂性的方法。 但是所有的 ACID 特性（如上所述的耐用性除外）都可以发挥作用。 +在不久的将来，服务器将需要处理数百万个并发连接。 使用 IPV6，来自每台服务器的潜在连接数达到数百万，因此我们需要进入下一个可伸缩性级别。 -## 基于行的表，索引和类似的东西 +* 需要此类可伸缩性的应用程序示例：IDS / IPS，因为它们连接到服务器主干。 其他示例：DNS 根服务器，TOR 节点，Internet 的 Nmap，视频流，银行业务，运营商 NAT，Voip PBX，负载均衡器，Web 缓存，防火墙，电子邮件接收，垃圾邮件过滤。 -基于参与者的核心和事务处理功能*可以与任何数量的不同类型的数据库一起使用。 基于列的简单密钥库，xml 文档库，graphdb。 任何需要扩展并从并行性中受益的事物。 但是我选择实现基于行的 RDBMS 作为 InfiniSQL 的第一个底层存储方案。 尽管有其他类型，该模型仍支持多种应用程序。 大多数备用数据组织类型都针对特定类型的工作负载进行了优化，而其他类型的组织则非常糟糕。 例如，列数据存储不适合事务处理。 除了获取/设置简单对象之外，密钥库实际上不能做任何其他事情。 关于 InfiniSQL 组织和操作数据的方式，没有什么破天荒的创新，但是底层体系结构克服了许多限制，这些限制促使采用许多备用数据库类型。* +* 通常，看到 Internet 规模问题的人是设备而不是服务器，因为他们出售的是硬件和软件。 您购买设备并将其插入数据中心。 这些设备可能包含英特尔主板或网络处理器以及用于加密，数据包检查等的专用芯片。 -PostgreSQL 客户端用于执行 SQL 查询，因此实际上任何平台和语言都应该能够使用 InfiniSQL。 他们已经很好地记录了[前端/后端协议](http://www.postgresql.org/docs/7.4/static/protocol.html)，因此为 InfiniSQL 实施它非常简单。 （InfiniSQL 和 PostgreSQL 是完全独立的项目。） +* 截至 2013 年 2 月，Newegg 的 X86 价格为$ 5K（40gpbs，32 核，256gigs RAM）。 服务器可以执行超过 10K 的连接。 如果不能，那是因为您在软件方面做出了错误的选择。 问题不在于底层硬件。 该硬件可以轻松扩展到 1000 万个并发连接。 -## 摘要 +### 10M 并发连接挑战的含义是： -就 InfiniSQL 的介绍以及如何将其设计为无限可扩展的 RDBMS 而言，这几乎就是如此。 到目前为止，从字面上看，这是一个人在他的客厅里全天候敲出代码的工作。 请喜欢 InfiniSQL，并从中学习，如果您想谈论它，请在上述链接中找到我！ 另外，请考虑参与-它仍处于早期状态，并且正在积极寻求贡献。 它是免费的开放源代码，并且有很大的发展空间。 愿意进行此项目的 Alpha 测试的人们也很受欢迎-如果您认为 InfiniSQL 可以解决您的某些问题，请与我谈谈！ +1. 1000 万个并发连接 -[关于黑客新闻](https://news.ycombinator.com/item?id=6795263) +2. 1 百万个连接/秒-大约 10 秒的持续速率 -*主页： [http://www.infinisql.org](http://www.infinisql.org/) -博客： [http://www.infinisql.org/blog/](http://www.infinisql.org/blog/) -IRC： [irc.freenode.net](http://irc.freenode.net/) #infinisql -Twitter：@infinisql -论坛： [https://groups.google.com/forum/#!forum/infinisql](https://groups.google.com/forum/#!forum/infinisql)* +3. 10 吉比特/秒的连接-快速连接到 Internet。 -虽然这是一个有趣的开始，但我最想知道 InfiniSQL 如何计划处理聚合功能和大表的联接。 尤其是联接是使关系数据库吸引人的原因，但是当您扩展规模时，尤其是对于复杂数据，它们也是最难的事情之一。 +4. 1000 万个数据包/秒-期望当前的服务器每秒处理 5 万个数据包，这将达到一个更高的水平。 过去服务器每秒能够处理 100K 次中断，每个数据包都会引起中断。 -我很好奇，想知道 InfiniSQL 是否计划提供某种东西来比在外部进行连接（例如在 map reduce 中）或购买带有硬件的数据库设备来使更大的连接成为可能。 +5. 10 微秒延迟-可伸缩服务器可能会处理规模，但延迟会增加。 -您的徽标与 VoltDB 有点类似：http://i.imgur.com/93x1CWJ.jpg +6. 10 微秒抖动-限制最大延迟 -嗨，戈登。 对于聚合，我认为它应该相对简单： -向每个分区发送一条消息，以使其返回其自身数据集的聚合结果。 然后让交易代理收集结果，并简化为正确的答案。 地图/缩小效果如何？ ;-)我还在考虑为每个表（甚至字段）提供一个选项，以便在每个插入/更新/删除操作中更新其聚合值，以节省聚合查询的时间。 +7. 10 个一致的 CPU 内核-软件应扩展到更大数量的内核。 通常，软件只能轻松扩展到四个内核。 服务器可以扩展到更多的内核，因此需要重写软件以支持更大的内核计算机。 -对于联接，我正在考虑让每个分区创建一个临时表，该表代表相关表中的联接值，并将这些值返回给事务代理。 +### 我们已经学习了 Unix 非网络编程 -在 InfiniSQL 上，某些大规模的多方联接很可能无法很好地完成工作-这很可能是只有整体数据库（或 MPP 数据仓库）才能很好地工作的领域。 我认为 InfiniSQL 至少对于现有的基于行的存储而言，并不是真正繁重，长时间运行的分析的最佳选择。 现在，对于柱状存储，可能会有不同的故事。 +* 一代程序员已经通过阅读 W. Richard Stevens 的 Unix Networking Programming 学习了网络编程。 问题在于这本书是关于 Unix 的，而不仅仅是网络编程。 它告诉您让 Unix 承担所有繁重的工作，而您只需要在 Unix 之上编写一个小型服务器即可。 但是内核无法扩展。 解决方案是移出内核，自己做所有繁重的工作。 -我还编写了大多数代码来支持子查询，但尚未对其进行完整的测试。 因此，几乎*支持子查询。 +* 这种影响的一个例子是考虑每个连接模型的 Apache 线程。 这意味着线程调度程序根据到达的数据确定下一步要调用的 read（）。 **您正在使用线程调度系统作为数据包调度系统** 。 （我真的很喜欢这个，以前从未想过）。 -您想帮忙吗？ :-) +* Nginx 所说的它不使用线程调度作为数据包调度程序。 自己安排数据包。 使用 select 查找套接字，我们知道它有数据，因此我们可以立即读取它并且不会阻塞，然后处理该数据。 -我真的不认为可以基于“ 12 台小型服务器”来“证明”“无限可扩展性”。 在那 12 之后再加上两个零； 如果每个服务器的数量看起来仍然相同，那将更有说服力。 +* 课程：**让 Unix 处理网络堆栈，但是从那时起，您将处理**上的所有内容。 -如果我没记错的话，VoltDB 说了类似的话，第三方稍后显示当您达到 50 到 100 台服务器（不确定精确限制）时，数字下降了。 +### 您如何编写可扩展的软件？ -I don't really think that "infinite scalability" can be "proved" based on "12 small servers." Add another two zeros after that 12; if the numbers per server *still looked the same*, that would be a lot more convincing. +如何更改软件以使其可扩展？ 关于硬件可以处理多少的很多经验法则都是错误的。 我们需要知道实际的性能能力。 -If I remember well, VoltDB said something similar, with third party showing later that the numbers went down when you reached 50 to 100 servers (not sure about precise limit). +要进入下一个级别，我们需要解决的问题是： ------- +1. 包可扩展性 +2. 多核可扩展性 +3. 内存可扩展性 -嗨，塞巴斯蒂安。 我认为演员模型很适合扩展规模。 本质上，限制因素将是节点间通信。 我不确定随着节点的增加，效率会降低多少。 另外，诸如高性能节点间联网之类的技术将改善这一状况。 有一次，我正在研究 Infiniband 动词作为集群间通信协议，但是 TCP / IP 更容易并且无处不在。 但是我想为 InfiniSQL 实现一个选项，以使其本机使用 Infiniband 进行群集通信-我认为这对于扩展可伸缩性将大有帮助。 +### 数据包扩展-编写自己的自定义驱动程序以绕过堆栈 -我不认为我们不同意-至少，到目前为止，我已经很清楚自己已经能够走多远了，我希望有机会进一步走好。 如果像 SGI 这样的人能像为 VoltDB 一样借给我无数的服务器，那就太好了。 ;-) +* 数据包的问题是它们通过 Unix 内核。 网络堆栈复杂且缓慢。 数据包到您的应用程序的路径需要更直接。 不要让操作系统处理数据包。 -我也不认为我们不同意。 我只是指出“ 12 台小型服务器”。 不是那么...令人印象深刻。 +* 实现此目的的方法是编写自己的驱动程序。 驱动程序所做的只是将数据包发送到您的应用程序，而不是通过堆栈发送。 您可以找到驱动程序：PF_RING，Netmap，Intel DPDK（数据平面开发套件）。 英特尔是封闭源代码，但周围有很多支持。 -我也是 Actor 模型的忠实拥护者，因为我是新的（仍然是 1.0 之前的版本）Actor API 的提交者。 但是对于许多 DB 而言，节点间的通信很快成为瓶颈，因此需要 12 个以上的节点来说明是否（或以何种大小）这种情况。 +* 多快？ 英特尔有一个基准，该基准在相当轻巧的服务器上每秒处理 8000 万个数据包（每个数据包 200 个时钟周期）。 这也是通过用户模式。 数据包一直向上进入用户模式，然后再次下降出去。 当 UDP 数据包恢复到用户模式并再次输出时，Linux 每秒处理的数据包不超过一百万。 性能是 Linux 客户驱动程序的 80-1。 -> 如果像 SGI 这样的人能像为 VoltDB 一样借给我无数的服务器，那就太好了。 ;-) +* 对于每秒 1000 万个数据包的目标，如果使用 200 个时钟周期来获取离开 1400 个时钟周期以像 DNS / IDS 那样实现功能的数据包。 -：D +* 使用 PF_RING 可以获取原始数据包，因此必须执行 TCP 堆栈。 人们在做用户模式栈。 对于英特尔，有一个可用的 TCP 堆栈可提供真正可扩展的性能。 ->我还在考虑为每个表（甚至字段） ->提供一个选项，以便在每次插入/更新/删除时将其汇总值更新为 ->，从而节省汇总时间 查询。 +### 多核可扩展性 -您是说要维护每个表的每个字段的*每个*汇总值？ 我认为这没有太大意义。 例如，您将使用以下查询做什么： -从员工那里选择 AVG（薪水）WHERE employee_name LIKE'H％'; -？ +多核可扩展性与多线程可扩展性不同。 我们都对处理器的想法并不熟悉，但是越来越多。 -或者您将如何处理用户创建的聚合函数？ 当将记录插入表中时，这些功能甚至不存在。 只要考虑一下 postgresql 的 CREATE AGGREGATE 语句。 +大多数代码无法扩展到 4 个内核以上。 随着我们添加更多内核，不仅性能会下降，而且添加更多内核会越来越慢。 那是因为软件写得不好。 我们需要软件，因为我们添加了更多的内核以几乎线性地扩展。 希望随着我们添加更多核心而变得更快。 -我有一个问题，这个帖子没有答案 --根据文档，每个写入都可以同步复制。 但是，即使在内存中，同步复制也很难扩展（CAP 定理？）。 尽管该功能尚未完成，但我认为这可能是对无限可扩展性的很大限制。 +#### 多线程编码不是多核编码 -你同意吗 ？ +* 多线程： -Csongor 说： + * 每个 CPU 内核有多个线程 -“您是说要维护每个表的每个字段的*每个*聚合值？我认为这样做没有太大意义。” + * 锁定以协调线程（通过系统调用完成） --------------- + * 每个线程有不同的任务 -仅作为选择。 该用例适用于希望为每个插页上的列收集 AVG 的人员。 保存每个分区的滚动总条目数和条目数量会节省计算时间。 但是对于您提到的情况，不，这不是一个好主意。 +* 多核： -主要是想表达我在 InfiniSQL 中进行聚合没有问题。 + * 每个 CPU 内核一个线程 -slefebvr 说： + * 当两个线程/内核访问相同的数据时，它们将无法停止并互相等待 -我有一个问题，这个帖子没有答案 --根据文档，每个写入都可以同步复制。 但是，即使在内存中，同步复制也很难扩展（CAP 定理？）。 尽管该功能尚未完成，但我认为这可能是对无限可扩展性的很大限制。 + * 所有线程属于同一任务 -Do you agree ? +* 我们的问题是如何在多个内核之间分布应用程序。 ---------------- +* Unix 中的锁是在内核中实现的。 使用锁的 4 个核心发生的事情是，大多数软件开始等待其他线程放弃锁。 因此，内核开始消耗更多的性能，而不是拥有更多 CPU 所获得的性能。 -不，我不同意。 我几乎完成了同步复制。 扩展并不难-尽管它会消耗一定数量的系统资源才能完成。 但是随着节点的增加，每个节点的系统资源有望保持稳定。 +* 我们需要的是一种比起停车灯控制的交叉路口，更像是高速公路的建筑。 我们不想等待每个人按照自己的步调以尽可能少的开销继续前进。 -我看到的关于可伸缩性的唯一硬性限制是打开的可用 TCP / IP 套接字的数量-副本中的每个节点都连接到网格中的每个其他节点。 类似 UNIX 的系统不能同时处理无限数量的 TCP / IP 连接。 我认为极限是无限 10。 ;-) +* 解决方案： -塞巴斯蒂安写道： + * 保持每个核心的数据结构。 然后在聚合时读取所有计数器。 + * 原子学。 可以从 C 调用的 CPU 支持的指令。保证是原子的，永不冲突。 昂贵，所以不想用所有的东西。 + * 无锁数据结构。 永不停止并等待彼此的线程可以访问。 不要自己做。 跨不同的架构工作非常复杂。 + * 线程模型。 流水线与工作线程模型。 问题不只是同步，而是线程的架构方式。 + * 处理器亲和力。 告诉操作系统使用前两个内核。 然后设置线程在哪些内核上运行的位置。 您也可以对中断执行相同的操作。 因此，您拥有这些 CPU，而 Linux 没有。 -I'm a believer in the Actor model too, as I'm a commiter to a new (still pre-1.0) Actor API. But for many DB, inter-node communication quickly becomes a bottleneck, and a lot more then 12 nodes are needed to show if (or at which size) this is the case. +## 内存可扩展性 ---------------------- +* 问题是，如果您有 20gig 的 RAM，并且假设每个连接使用 2k，那么如果您只有 20meg 的 L3 缓存，则这些数据都不会在缓存中。 进入主内存需要 300 个时钟周期，这时 CPU 无法执行任何操作。 -InfiniSQL 批处理节点间消息并使用 LZ4 压缩。 它牺牲了一些延迟，但是在我看来，吞吐量的增加是值得的。 同样，10GB 以太网比 1GB 更好，多个 NIC RX 队列比单个更好。 我想使用 Infiniband Verbs API（https://www.openfabrics.org/index.php）来实现 RDBMA，但是 TCP / IP 较容易编码，并且用户基础更加广泛。 但是我认为 Infiniband 可以大大减少集群内部的通信开销。 +* 考虑每个数据包 1400 个时钟周期的变化。 请记住 200 个时钟/每包的开销。 每个数据包只有 4 个高速缓存未命中，这是一个问题。 -有趣的项目。 +* 并置数据 -在许多情况下，您可以将聚合推送到参与者。 AVG 怎么了？ 您从每个演员返回计数和平均值，然后根据计数加权最终平均值。 感觉就像一个很简单的地图/缩小模型。 + * 不要通过指针在整个内存上写数据。 每次跟随指针将导致高速缓存未命中：[哈希指针]-> [任务控制块]-> [套接字]-> [应用程序]。 那是四个缓存未命中。 -正如其他人所提到的，问题可能是节点间通信，尤其是在某些联接情况下。 我喜欢您已经认识到这一点，但是您可以将 10GB 扩展到某种上限。 我不知道我会称其为无穷大，但“高”似乎是可能的。 + * 将所有数据保存在一块内存中：[TCB | 插座 应用]。 通过预分配所有块来保留内存。 这样可以将缓存未命中次数从 4 个减少到 1 个。 -期待看到这片土地，尤其是当您获得 ACID 中的 D 以后，您会发现更多。 +* 分页 -干杯! + * 用于 32gigs 的分页表需要 64MB 的分页表，该页面不适合缓存。 因此，您有两个未命中的缓存，一个是针对分页表的缓存，另一个是其指向的缓存。 对于可扩展软件，这是我们不能忽略的细节。 -- 八月 + * 解决方案：压缩数据； 使用高速缓存有效的结构，而不是具有大量内存访问权限的二进制搜索树 ->如果像 SGI 这样的人像为 VoltDB 一样借给我无数的服务器，那就太好了。 ;-) + * NUMA 体系结构使主存储器访问时间加倍。 内存可能不在本地套接字上，但在另一个套接字上。 -EC2 FTW :-) +* 内存池 -FWIW，我认为正确处理节点故障和分区，最终获得一个可靠且性能良好的系统至关重要。 没有人愿意为后者牺牲前者。 + * 启动时一次预分配所有内存。 -第一部分是所有群集节点必须在配置上达成一致。 如果您以前从未接触过它，则可能想看看[木筏](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)算法作为 Multi-Paxos 的替代方法。 + * 在每个对象，每个线程和每个套接字的基础上分配。 -但是，为了确定哪些写入已传播到副本节点，还需要在某种程度上进行类似的操作。 您可以确定，每种可能的故障模式-节点消失并在事务处理周期的不同点返回-*或早或晚都会发生。 \ No newline at end of file +* 超线程 + + * 网络处理器每个处理器最多可以运行 4 个线程，英特尔只有 2 个。 + + * 这样可以掩盖例如内存访问的延迟，因为当一个线程等待另一个线程全速运行时。 + +* 大页面 + + * 减小页表大小。 从一开始就保留内存，然后由应用程序管理内存。 + +### 摘要 + +* 没什么 + + * 问题：通过内核无法正常运行。 + + * 解决方案：使用您自己的驱动程序将适配器从操作系统中取出，并自行管理它们 + +* CPU + + * 问题：如果您使用传统的内核方法来协调应用程序，则效果不佳。 + + * 解决方案：为 Linux 提供前两个 CPU，然后您的应用程序将管理其余的 CPU。 在您不允许的 CPU 上不会发生中断。 + +* 内存 + + * 问题：要格外小心，以使其正常工作。 + + * 解决方案：在系统启动时，以您管理的大页面分配大部分内存。 + +控制平面留给 Linux 使用，对于数据平面则什么也没有。 数据平面以应用程序代码运行。 它从不与内核交互。 没有线程调度，没有系统调用，没有中断，什么都没有。 + +但是，您所拥有的是可以在 Linux 上正常运行的代码，您可以对其进行正常调试，这不是您需要定制工程师使用的怪异硬件系统。 通过熟悉的编程和开发环境，您可以获得数据平面所期望的自定义​​硬件的性能。 + +## 相关文章 + +* 阅读 [Hacker News](https://news.ycombinator.com/item?id=5699552) 或 [Reddit](http://www.reddit.com/r/programming/comments/1e90q7/the_secret_to_10_million_concurrent_connections/) ， [Hacker News Dos](https://news.ycombinator.com/item?id=7697483) +* [是时候摆脱云中的 Linux OS 模型了吗？](http://highscalability.com/blog/2012/1/19/is-it-time-to-get-rid-of-the-linux-os-model-in-the-cloud.html) +* [机器虚拟机+云 API-从头开始重写云](http://highscalability.com/blog/2010/10/21/machine-vm-cloud-api-rewriting-the-cloud-from-scratch.html) +* [Exokernel](http://en.wikipedia.org/wiki/Exokernel) +* [关于 C10M 的博客](http://c10m.robertgraham.com/) +* [多核缩放：它不是多线程的](http://erratasec.blogspot.com/search/label/Shmoocon2013) ，具有良好的注释功能。 +* [英特尔®DPDK：数据平面开发套件](http://dpdk.org/) + +瓶颈的分解令人印象深刻，阅读这种正确的东西令人耳目一新。 + +现在我想扮演魔鬼的拥护者（主要是因为我完全同意这个家伙）。 提出的解决方案听起来像是定制的特定于硬件的解决方案，听起来就像是回到过去，那时您不能只是将一些相当随机的硬件放在一起，将 linux 打在上面然后继续前进……这将是对此的最大反对， 人们担心电器/供应商/驾驶员被锁住，这是一种理性的恐惧。 + +有什么计划使外行可以使用这些非常正确的体系结构实践。 需要某种 API，因此各个硬件堆栈都可以对其进行编码，并且此 API 一定不能是重量级的抽象。 这是一个艰巨的挑战。 + +最好的是，C10M 运动很幸运，如果我能在未来几年的某个时间里将一个可运行 C10M 的系统组装在一起，我将是一个快乐的程序员。 + +很棒的文章！ 总的来说，我总是发现规模引人入胜。 Postgres 9.2 增加了对多达 64 个内核的支持（真正的支持），这确实使我很高兴。 业界似乎在“只是向它扔更多便宜的服务器...它们很便宜”和“让我们看看我们可以将其堆叠多高，因为很难将其拆分”之间来回切换。 我更喜欢后者，但是将它们结合在一起，再加上您所说的优化（不只是将大规模网络等任务委派给内核），往往会使我们朝着 roboblypse 前进：） + +好贴。 对于内存可伸缩性，您还可以考虑通过使用 libnuma / numactl 之类的控件来控制进程亲和力，从而提高内存的局部性。 + +关于本次会议的非常好的总结 + +关于 DPDK，您可以从 http://dpdk.org 获得源代码。 它提供 git，邮件列表和良好的支持。 看来它是由 6WIND 驱动的。 + +尽管[通用可扩展性法律](http://is.gd/3N2Iia)（USL）在视频演示中显示的时间约为 30:00 分钟，但他声明可扩展性和性能无关。 请注意，由于多核一致性延迟的出现而导致的最大性能。 在 Velocity 2010 上提出了对[内存缓存](http://www.perfdynamics.com/Manifesto/USLscalability.html#tth_sEc4.3)的类似效果进行量化的方法。 + +这很有趣。 标题可能会更好，因为“ Linux 内核是问题”，因为其他内核则有所不同。 举个例子，我上次检查时，Linux 用了 29 个堆栈帧从 syscalls 转到 start_xmit（）。 illumos / Solaris 内核的相似路径（对 mac_tx（）的系统调用）采用 16。 FreeBSD 用了 10 个（对 ether_output（）的系统调用）。 这些可以有所不同。 检查您的内核版本和工作量。 我已经将它们作为堆栈差异的示例。 这也应该使 Linux 堆栈更昂贵-但我需要分析（基于周期）以进行量化。 + +内存访问确实是大敌，您谈论的是保存缓存未命中，但是在 Linux（和其他内核）中，已经为 CPU 亲和力和内存局部性做了很多工作。 是行不通还是行不通？ 是否有可以修复的错误？ 分析这个问题并找出问题的根本原因将是非常好的。 在 Linux 上，运行 perf 并查看内核堆栈以查找缓存未命中。 更好的办法是量化 TCP / IP 中的内核堆栈，以获取内存访问停顿周期-并查看它们是否累加并解释了问题。 + +现在，我正在研究内核网络性能问题（我正在做内核工程）。 我认为我发现了一个内核错误，通过对问题进行根本原因分析，可以发现该内核错误可以将我正在运行的基准测试的网络堆栈延迟提高（减少）约 2 倍。 + +这样的胜利不会改变绕开堆栈的整体潜在胜利。 但是最好是先了解内核的限制是什么，然后再根源进行此操作。 + +绕过内核还意味着您可能需要重新发明一些工具集以进行性能分析（我使用了许多自定义工具，这些工具在系统调用和设备之间工作，用于分析 TCP 延迟和丢包，超出了网络嗅探的范围）。 + +让我想起了范雅各布森在 LCA2006 上的演讲。 谈论将工作推向端点。 而内核确实不是终结点（尤其是使用 SMP），而应用程序就是。 + +Unix 最初并未用于控制电话网络。 通常是一个用于编辑文档的分时系统（带标记的 ASCII 文本）。 这是从 CACM 纸的 BSTJ 纸版本中提取的。 +http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html。 + +自 1971 年 2 月 PDP-11 Unix 投入使用以来，已有 600 多个安装投入使用。 他们中的大多数人从事诸如计算机科学教育，文档和其他文本材料的准备和格式化，从 Bell 系统内的各种交换机收集和处理故障数据以及记录和检查电话服务订单等应用程序。 我们自己的安装程序主要用于操作系统，语言，计算机网络和计算机科学中的其他主题的研究，还用于文档准备。 + +让我们来看看 EZchip NPS，它实现了上面的大多数想法。 + +这并不奇怪：通用软件（例如内核）适用于“标准”应用程序。 为了达到最高性能，定制的，经过微调的软件总是可以击败它。 + +[Netmap](http://info.iet.unipi.it/~luigi/netmap/) 是否也不能很好地解决数据包 I / O 效率问题？ + +恩，我讨厌将其分解给你们，但是这个问题及其解决方案[早已为 exokernel 社区所熟知。](http://pdos.csail.mit.edu/exo.html) 虽然我承认 Linux 和 BSD 的商标意义是“不是 Unix”，但它们仍然基于不低于 60 年历史的 OS 体系结构（我们为之付出的大部分努力） 授予是来自 Multics 的某种形式的）。 现在是进行重大更新的时候了。 :) + +@Russell Sullivan +与本文无关的是外行。 + +“ Unix 最初并不是被设计为通用服务器操作系统，而是被设计为电话网络的控制系统。” + +呃，不，这是完全错误的。 由于 Linux 内核是独立开发的，因此谈论 UNIX 是无关紧要的。 + +这并不是说技术论点是不正确的，但是这种荒谬的废话无助于信誉。 + +一个问题是用户空间和内核空间中存在的阻塞点（无论是共享数据结构还是互斥体，是否可并行化）。 外来内核和其他方法只是通过转移负担（IP 堆栈打包功能）来选择做同一件事的不同方法。 最终，硬件（真实或虚拟）在解决方案上呈现出最明显的有限瓶颈。 + +在包括硅在内的其他方法的最高端，http：//tabula.com 以网络为中心的应用程序编译为带有功能样式编码的特定于应用程序的 OS 框架。 这不仅对利基问题是有前途的，而且似乎是解决时间/空间数据流问题的许多传统瓶颈的最深层方法。 对于 99％的解决方案，从用尽垂直规模的 LMAX 嵌入式系统开始使用 http://martinfowler.com/articles/lmax.html 开始，在精疲力尽商用设备之后，可能更明智。 + +回到商业规模，对于 Xen，有一些无操作系统的运行时： + +Erlang-LING VM +Haskell-Halvm + +“ Unix 中的锁是在内核中实现的”主张对于当今的系统而言并非绝对正确。 如 http://en.wikipedia.org/wiki/Futex 中所述，我们具有轻巧的用户土地锁。 尽管我同意应用程序在执行网络数据包处理方面可能带来的速度提升，但是内存管理（包括分页）和 CPU 调度几乎不在应用程序的范围内。 这类事情应该留给对底层硬件有更好了解的内核开发人员。 + +有趣的是，“控制和数据分离”的架构模式多久出现一次。 前几天，我在一个充满高管人员的房间里发表了讲话，指出在我们正在开发的产品中这种模式是如何发生的（事实证明是不正确的）。 您可以在我在 NCAR 上工作过的各种大型海量存储系统中看到它（控制 IP 链接，但是使用专用硬件通过高速 I / O 通道进行数据处理），而在我当时工作过的各种大型电信系统中 在贝尔实验室（再次通过 IP 链路“发送信号”，但通过专用交换结构使用完全不同的传输机制在所有“承载”流量），在 VOIP 系统中（使用 SIP 进行控制并由软件处理，但 RTP 尽可能地桥接） 即使在嵌入式系统中（直接从 A / D 芯片通过 TDM 总线承载，但通过 SPI 串行总线通过控制消息进行控制），也可以直接在端点之间进行操作，而无需软件堆栈进行处理。 这种模式至少自 1960 年代就已经存在，甚至在更早的其他非数字控制环境中也是如此。 这实际上是专业劳动理念的一个部门，可以追溯到数千年前。 + +仅供参考：我们使用一台运行标准 Linux 的 1U 服务器（未更改源代码）实现了 1200 万个并发连接，同时以 1Gbps 以上的速度发布数据。 查看更多详细信息： + +http://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/ + +但是，我同意，就大量套接字而言，Linux 内核仍应提供实质性的改进。 很高兴看到新版本的 Linux 内核（从 3.7 版开始）在套接字相关的内存占用方面有了一些重要的改进。 然而。 更多优化是必要且可能的。 如我的帖子所述，1200 万个并发连接的内存占用量约为 36 GB。 Linux 内核肯定可以增强此功能。 + +通过阅读本文，我得出结论，这是从头开始进行未来 OS 设计的新时代。 + +我尝试使用 lwip PF_RING，但失败了，从北京 IDF 2013 获悉 windriver 开发了它自己的用户空间堆栈，在 2 年内花费了 20 个开发人员。 + +这很棒！ 对于我打算稍后用于商业用途的学校项目，我做错了方法（每个连接一个线程）。 + +这很棒！ 我已经使用 nio 实现了 Java Web 服务器，并且可以在具有 5 年历史的 8GB ram 台式机上实现 10K +的连接-但是 10M 太疯狂了。 在 Linux 上，开放套接字的数量似乎受到 ulimit 的限制-并且不确定如果没有内核调整，是否甚至可以实现 10M。.我想您的方法并不重要。 + +很棒的帖子。 英特尔正在招聘 DPDK 和网络开发人员。 如果您知道有人对此空间感兴趣，请传递 +http://jobs.intel.com/job/Santa-Clara-Networking-Developer-Evangelist-Job-CA-95050/77213300/ + +“ 1400 个时钟周期” + +这是什么样的愚蠢，模棱两可的数字表达方式？ 您是否在故意混淆 peple？ 在整篇文章中，您应该*一贯*地使用数字或单词，更不用说相同的数字了。 \ No newline at end of file diff --git a/docs/12.md b/docs/12.md index a8667b0..bdb7e00 100644 --- a/docs/12.md +++ b/docs/12.md @@ -1,103 +1,135 @@ -# 美国大选期间城市飞艇如何扩展到 25 亿条通知 +# Fotolog 扩展成功的秘诀 -> 原文： [http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html](http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html) +> 原文： [http://highscalability.com/blog/2007/10/2/secrets-to-fotologs-scaling-success.html](http://highscalability.com/blog/2007/10/2/secrets-to-fotologs-scaling-success.html) -![](img/8a073c8483bfc1f227aed0829dbb7f84.png) +Fotolog 是一个以照片为中心的社交博客网站，从 2004 年的 30 万用户增长到 2007 年的 1100 万用户。尽管他们最初经历了快速增长的不可避免的痛苦，但他们克服了问题，现在管理着 3 亿张照片和 80 万张照片 每天都会添加新照片。 产生如此美妙的内容的是每月有 2000 万唯一身份访问者，以及每天由 30,000 新用户组成的志愿军。 他们的表现如此出色，一个令人印象深刻的求婚者以 9000 万美元的高价买下了他们。 这样的规模可以满足任何人的成功标准。 他们是如何做到的呢？ -*这是 Urban Airship 的来宾帖子。 贡献者：亚当·洛瑞（Adam Lowry），肖恩·莫兰（Sean Moran），迈克·赫里克（Mike Herrick），丽莎·奥尔（Lisa Orr），托德·约翰逊（Christine Ciandrini），阿什什·沃蒂（Ashish Warty），尼克·阿德雷德（Nick Adlard），梅勒·萨克斯·巴尼特（Mele Sax-Barnett），尼尔·凯利（Niall Kelly），格雷厄姆·福里斯特（Graham Forest）和加文·麦奎兰* +网站：http：//www.fotolog.com -Urban Airship 受到数以千计希望通过移动技术发展的企业的信任。 Urban Airship 是一家成立 7 年的 SaaS 公司，拥有免费增值业务模式，因此您可以免费试用 [](https://www.urbanairship.com/lps/best-push-notification-service)。 有关更多信息，请访问 [www.urbanairship.com](http://www.urbanairship.com/) 。 目前，城市飞艇平均每天发送的推送通知超过 10 亿条。 这篇文章重点介绍了 2016 年美国大选的城市飞艇通知使用情况，探讨了系统的架构-核心传递管道-为新闻发布者提供数十亿次实时通知。 +## 信息来源 -## 2016 年美国大选 +* [扩展世界上最大的照片博客社区](http://www.slideshare.net/frankmashraqi/fotolog-scaling-the-worlds-largest-photo-blogging-community)* [祝贺 Fotolog 向 Hi-Media 出售$ 90mm 的交易](http://www.beyondvc.com/2007/08/congrats-to-fot.html)* [Fotolog 超越 Flickr 吗？](http://www.kottke.org/07/01/fotolog-overtaking-flickr)* [Fotolog 吸引了 1100 万会员和 3 亿张照片](http://www.stockphototalk.com/the_stock_photo_industry_/2007/09/fotolog-hits-11.html)* [本周网站：PC Magazine 的 Fotolog.com](http://www.pcmag.com/article2/0,1895,2150030,00.asp)* [CEO John Borthwick 的博客](http://www.borthwick.com/weblog/category/fotolog/)。* [DBA Frank Mash 的博客](http://mysqldatabaseadministration.blogspot.com)* [Fotolog, lessons learnt](http://www.borthwick.com/weblog/2008/01/09/fotolog-lessons-learnt/) by John Borthwick -在选举日前后的 24 小时内，Urban Airship 发出了 25 亿条通知，这是有史以来的最高日发送量。 这相当于在美国每人 8 条通知，或者世界上每部活动的智能手机 1 条通知。 虽然 Urban Airship 在每个行业垂直领域为超过 45,000 个应用程序提供支持，但对选举使用情况数据的分析显示，超过 400 种媒体应用程序占了这一记录量的 60％，随着跟踪选举结果并在一天之内发送 15 亿条通知 报告。 + ## 该平台 -![](img/36ce3f158f2a647278f8b998ea2b34fc.png) + * 爪哇* 的 PHP* Sun* Solaris 10* 的 MySQL* 阿帕奇* 冬眠* 记忆快取* [3PAR](http://www.3par.com/index.php) （用于实用程序计算的简单，高效且可扩展的分层存储阵列）* [IBRIX](http://www.ibrix.com/) （单个名称空间并行文件系统，可伸缩的卷管理器，高可用性功能）* 强邮* CDN: Akamai/Panther -总统选举结束时，通知量稳定并达到顶峰。 + ## 统计资料 -![election-urbanairship-notification.png](img/ed7aba40e08757f46f3ab55d602e8ec5.png) + * 从 2002 年开始。在 2004 年，他们有大约 30 万或 40 万成员，3 名员工，没有可扩展的基础架构，也没有收入模型。* 由于快速增长，该站点经常遇到技术问题，2005 年他们不得不将新的免费成员限制为每天 1,000 名。* 2007 年，他们拥有超过 1100 万用户，并以 9000 万美元的价格卖给了 Hi-Media。* 成员来自 200 多个国家/地区，多数在南美。 超过 20％的网页浏览量来自欧洲。 他们拒绝了以美国为中心的战略，而是建立了一个全球性和互动性的受众。* 每月产生超过 35 亿的页面浏览量，每月接待超过 2000 万的唯一身份访问者，并获得了 Alexa 排名前 20 位。* 管理超过 3 亿张照片，每天上传超过 500,000 张照片。* 每天新增 30,000 多个新成员，每天吸引 460 万以上的用户。 无需市场营销或会员激励即可扩展。* 超过 500 个用户生成的社区。* 20％的成员每天访问该网站，平均花费 24 分钟。* 32 个 MySQL 服务器和 30 个 memcached 服务器群集。 -到城市飞艇的 HTTPS 入口流量 [API](http://docs.urbanairship.com/api/ua.html) 在选举期间达到了每秒近 75,000 的峰值。 这些流量大部分来自城市飞艇 [SDK](http://docs.urbanairship.com/dev-resources.html) 与城市飞艇 [API](http://docs.urbanairship.com/api/ua.html) [ 。 + ## 架构 -![election-urbanairship-HTTPS.png](img/f308127dc795976d958424e5b22196a5.png) + * 网站最初是用 PHP 编写的。 + -他们的新“ Fotolog 成员页面”功能是用 Java 编写的，具有显着的性能改进。 页面更清洁，响应时间更短。 + -他们现在使用不到一半的盒子为网站提供服务。 + -由于性能提高以及需要注册才能发布留言簿消息，因此每日注册量增加了 35％以上。 + -新的代码库使他们可以在会员体验方面进行更多创新。 -推送通知量一直在迅速增加。 最近的主要推动力是英国退欧，奥运会和美国大选。 2016 年 10 月，每月通知量同比增长 150％。 + * 他们已经超过 Flickr，成为了牢固的 Web 1.0 应用程序。 + -没有标签，没有 API，没有 JavaScript 窗口小部件，也没有 Ajax。 + -他们具有西班牙语选项，可以将网站扩展到广泛的用户群。 + -他们使用的文字很少。 它主要是可视的，因此可以被广泛的用户使用。 + -他们的界面是可定制的，许多人喜欢表达自己的身份。 + -他们的唯一访问者比 Yahoo 的访问者少 1 毫米，但网站上的总访问时间却是 Yahoo 的两倍，网页的访问时间是 3 倍。 -![monthly-sends.png](img/edd6f898ff8977d6b6b3e7259682ce3e.png) + * 收入模式： + -金牌会员（每月约 5 美元）意味着您每天可以上传 6 张照片，而不是 1 张，每张照片有 200 条评论，而不是 20 条，这是您个人资料的自定义标题图片，是您的微型缩略图 留言簿中您名字旁边显示的最新照片，以及在首页上显示您的照片的可能性。 + -Adsense。 考虑到来自来宾簿的其他上下文数据，来自 Google 的收入增长趋势预计约为 15％。 + -将在其成员中转向点对点广告。 + -会员将能够使用小额付款服务买卖真实和虚拟物品。 -## 核心交付管道架构概述 + * 他们有每天发布一次的规则，即用户每天只能发布一张照片。 该规则不会抑制增长，而是通过增加观看照片的机会并吸引正面评论来确保质量并产生出色的用法。 人们通常会在博客上说不出话来，而人们总是可以找到要拍照，上传和谈论的图片。* 只能上传小于 2,000 kb 的照片。 它们会自动调整为 500x500 格式。 页面看起来更整洁，加载速度更快。* 模型正在浏览搜索。 鼓励机会性的偶然性寻宝活动。* 无需许可即可自动添加朋友。 这会为您的照片吸引观众。* 支持按组浏览功能，该功能具有“颜色”和“情感”等类别。* 该网站特意简单。 + -他们抵制了一个又一个地添加功能的诱惑。 相反，他们的愿景是提供一些功能，类似于 Craig 的列表，重点是内容和对话。 + -页面必须具有社交性。 + -页面不仅需要包含您的图片，还需要包含来自整个网络的图片，以提供可视化导航，从而今天可以驱动他们的会员在网站上花费的大部分时间，这是一个自我形成的有机分布系统，让会员可以看到 并被看到。 + -注释和留言簿条目是对这种图像社交网络的补充，使这种体验成为媒体与交流相交的地方，每天都有数以百万计的图像与数十亿次对话相撞。* Photobucket 与 Fotolog + -Photobucket 存储基于图像的媒体，然后将其分发到 Myspace，Bebo，Piczo，Friendster 等社交网站上的页面上。 + -Fotolog 是目标。 + -第一代社交网站强调通过连接（从 Geocities，Tripod 到 Blogger）进行自我发布。 下一代主要关注人际关系（六度和 Friendster 是这里的经典示例-收集朋友和人际关系的工具，因为社会资本在理论上是与人际关系最多的人积累的）。 第三代和当前的站点将媒体与联系融合在一起-每个站点都有不同的侧重点。 -核心交付管道（CDP）是城市飞艇系统，负责从观众选择器中实现设备地址，并传递通知。 无论我们同时发送给数千万用户，针对多个复杂的子细分受众群，包含个性化内容或介于两者之间的任何内容，我们发送的所有通知都期望低延迟。 这是我们的架构的概述，以及我们在此过程中学到的一些知识。 + * 备份：Sun 6540 磁盘阵列* 他们的 32 台 SQL 服务器分为四个集群 + -用户，GB（来宾），PH（照片），FF（朋友和收藏夹列表） + -使用非持久连接。 + -Java 端的连接池。 + -InnoDB + -分区由应用程序层处理。* 每个群集： + -带有一组应用程序服务器。 + -分为一组碎片。 + -每个分片都有 MySQL 只读主-主配置，该配置提供了几个只读从属。 + -应用服务器将其读取请求发送到从属服务器，并将其写入请求发送给主服务器。 + -基于某种特定于群集的分区密钥将数据分配给共享。 幼稚的分区算法可能会导致非常不均匀的分片负载，您希望每个分片上的负载更加均衡。* MySQL 仅用于存储图像元数据。 这似乎很标准。 几乎没有人似乎在数据库中存储重要的 Blob，因为它会减慢数据库操作的速度。* 照片存储使用 3PAR 和 IBRIX。 CDN 用于热点内容。* 虚拟存储系统尽管价格昂贵，但运行良好。* 随着更多选择的使用，自动递增密钥的锁争用也会增加。* 通过数据库优化，他们已经能够在同一 32 台数据库服务器上从 400 万成员增长到 1100 万成员。 这也提高了在 Solaris 10 上运行 MySQL 的效率，并增加了内存缓存群集，移植到 Java 并增加了 RAM。* Happy with memcached. + - Created a distributed cluster of 50 memcached servers with a total cache size of approximately 150 gigabytes, supporting around 4 billion page views/month. Peak load times dropped from 10 seconds to 2 seconds. + - Quote from [CTO](http://mashraqi.com/labels/memcached.html) : -### 我们是如何开始的 + > *我有一个新的内存缓存用户要添加到您的列表中：我们在世界最大的照片博客社区 Fotolog 上使用它，我们很喜欢。 我刚刚滚动了我们的第一个代码以将其用于今天的生产，它一直是救生员。 我迫不及待地开始在依靠伯克利数据库来分担某些数据库工作的地方开始使用它。 我们也不是每天浏览数百万页的网站。 Fotolog 是一个每月十亿页以上的网站（每天对我们而言典型的浏览量是 35 到 4000 万）。 最近，我们克服了一些与数据库相关的重大性能问题，这些问题使我们的网站流量激增，并且在流量负载沉重的情况下再次陷入停滞（恢复到 10 秒，有时在高峰时段加载页面）。 每次可以轻松地以相同的形式共享列表至少 5 到 10 分钟时，服务器就会浪费时间重新创建列表。 因此，我们引入了内存缓存，创建了一个总共有 4 个演出的分布式 30 服务器集群，并制作了一个非常小的代码 mod 以使用内存缓存，并且我们的高峰时段加载时间回落到 2 秒左右。 它允许持续增长和令人难以置信的效率。 我无法说何时对如此简单的作品感到满意。”* -最初从 2009 年开始是一个 Web 应用程序，当时有些工人已经转变为面向服务的体系结构。 随着旧系统的各个部分开始遇到规模问题，我们将它们提取到了一个或多个新服务中，这些服务旨在满足相同的功能集，但规模更大且性能更好。 我们许多原始的 [API](http://docs.urbanairship.com/api/ua.html) API 和工作人员都是用 Python 编写的，然后将它们提取到高并发 Java 服务中。 在最初将设备数据存储在一组 Postgres 分片中的地方，我们的规模迅速超过了添加新分片的能力，因此我们转向使用 HBase 和 Cassandra 的多数据库体系结构。 + ## 得到教训 -CDP 是处理分段和推送通知传递的服务的集合。 这些服务根据请求提供相同类型的数据，但是出于性能原因，每个服务都以非常不同的方式对数据进行索引。 例如，我们有一个系统负责处理广播消息，向注册到相关应用程序的每个设备传递相同的通知有效负载。 该服务及其底层数据存储区的设计与我们负责根据位置或用户个人资料属性传递通知的服务的设计有很大不同。 + * 受欢迎程度是由活跃的用户群驱动的，而不是丰富的炫酷功能。* 网络是全球性的，它的尾巴很长。 通过以语言和特定于文化的设计吸引美国以外的用户，您可以与大个子竞争。 对于 Google，Yahoo 等而言，最艰难的竞争来自本地初创公司，他们着眼于当地人的需求。* 如果您想获得大量嗡嗡声，请执行 alpha 怪胎希望您做的任何事情。 如果您想让很多快乐的用户去做他们想要您做的事情。* 像诗歌一样，网站中的约束可以使事情变得出乎意料的更好。 每天只允许用户发布一张照片的规则创建了一个环境，使人们对彼此的照片发表更多评论，从而创建了一个更加互动的社区。 谁知道？* 限制您的网站。 限制图片，评论等的大小，以免资源使用量急剧增加。* 有远见。 对您的网站应该是什么以及为什么要有一个深刻的认识，然后利用这一愿景来决定您应该构建什么以及应该如何构建它。 他们围绕每日照片构建的社交网站的愿景导致了一个与您的目标是存储所有照片的网站截然不同的网站。* 可以添加创收功能，而不会破坏网站的完整性。 我非常喜欢他们如何免费为人们提供合理的功能集，然后为他们需要的更多资源收取费用。 这些功能还有助于扩展和增强其网站的社交视野。 看看他们的新获利策略如何发挥作用将很有趣。* 不要害怕扩大规模。 通过添加更多的缓存，更多的 RAM，更多的 CPU 和更高效的 CPU，您可以在相同数量的计算机上处​​理更多的负载。 从数据中心空间和强大的 POV 来看，这是一件好事。* 使 MySQL 执行： + -查找问题的根源。 + -成熟的系统主要是磁盘绑定的。 + -查询缓存可能会伤害您。 + -添加 RAM 以帮助躲避子弹。 + -分割磁盘。 + -重组表以获得最佳性能。 + -使用 libumem.so 查找内存泄漏。* 要记住的事情： + -了解问题 + -了解您的应用程序 + -了解您的存储引擎 + -了解您的要求 + -了解您的预算 + -使用所有这些信息来决定 系统的哪些部分真正需要投入时间，金钱和测试才能实现高可用性。 -我们将任何长期存在的进程视为一项服务。 这些长期存在的过程遵循有关度量，配置和日志记录的通用模板，以简化部署和操作。 通常，我们的服务属于以下两类之一：RPC 服务或使用者服务。 RPC 服务使用非常类似于 GRPC 的内部库提供命令来与服务进行同步交互，而消费者服务则处理来自 Kafka 流的消息，并对这些消息执行特定于服务的操作。 + ## 相关文章 -![urbanairship-cdp.png](img/8f0bf13a515234268219ff976be393a9.png) + * [Flickr 架构](http://highscalability.com/flickr-architecture)* [数据库设计的非传统方法：碎片](http://highscalability.com/unorthodox-approach-database-design-coming-shard)的来临 -### 数据库 +托德 -为了满足我们的性能和规模要求，我们严重依赖 HBase 和 Cassandra 来满足我们的数据存储需求。 尽管 HBase 和 Cassandra 都是列式 NoSQL 存储，但它们的取舍却大不相同，这些折衷影响我们使用哪个存储以及用于什么目的。 +嗨，我是 Fotolog 的 CTO，您在组装和分析所有这些信息方面做得非常出色。 知道那里仍有记者愿意做腿法，这真是令人鼓舞。 我只想做几个小笔记。 在统计方面：我们现在每天大约增加 800,000 张照片...主页计数器有时可能会滞后。 此外，我们首次实现内存缓存时就写了内存缓存引号。 我们目前对它的使用更为广泛。 现在，我们在大约 50 台服务器上运行它，总缓存大小约为 150 GB，每月支持大约 40 亿的页面浏览量。 此外，我们仍处于 ibrix 实现的中间。 -HBase 非常适合高通量扫描，响应的预期基数很高，而 Cassandra 非常适合低基数查找，其中响应仅包含少量结果。 两者都允许大量的写入吞吐量，这是我们的要求，因为来自用户手机的所有元数据更新都是实时应用的。 +再次，伟大的工作。 -它们的故障特性也不同。 在发生故障时，HBase 支持一致性和分区容忍度，而 Cassandra 则支持可用性和分区容忍度。 每个 CDP 服务都有一个非常特定的用例，因此具有高度专业化的架构，旨在促进所需的访问模式并限制存储空间。 通常，每个数据库仅由单个服务访问，该服务负责通过不太专门的界面提供对其他服务的数据库访问。 +-沃伦 -加强服务与其支持数据库之间的 1：1 关系具有许多好处。 +感谢您的晋升，但我只是一个可替换的程序员部门：-)我必须承认，直到您被收购时，我才听说过 Fotolog，但这是一个有趣的故事。 您如何将愿景和网站完美地结合在一起，可以学到很多东西。 -* 通过将服务的支持数据存储视为实现细节而不是共享资源，我们可以获得灵活性。 +并感谢您的更新。 那是很多照片，我想您为什么选择 Ibrix。 您能否谈谈为什么要使用 Ibrix，希望完成什么以及如何为您工作？ -* 我们可以在不更改服务代码的情况下调整服务的数据模型。 +嗯，内存缓存。 当我*没有*看到它部署时，我感到很惊讶。 -* 使用情况跟踪更为直接，这使容量规划更加容易。 +另一方面，我认为这很有趣：“他们有一个每天发布一次的规则，即用户每天只能发布一张照片。” 我从未听说过如此严格的限制。 -* 故障排除更加容易。 有时服务代码存在问题，而其他时候则是备份数据库问题。 将服务和数据库作为逻辑单元可以极大地简化故障排除过程。 我们不必怀疑“还有谁可以访问该数据库以使其表现为这种方式？” 相反，我们可以依靠服务本身的应用程序级指标，而只担心一组访问模式。 +- +Dustin Puryear +作者，“管理 Linux 和 UNIX 服务器的最佳实践” +[http://www.puryear-it.com/pubs/linux-unix-best-practices](http://www.puryear-it.com/pubs/linux-unix-best-practices) -* 因为只有一种服务与数据库交互，所以我们几乎可以执行所有维护活动，而无需停机。 繁重的维护任务成为服务级别的问题：可以在不中断服务的情况下完成数据修复，模式迁移，甚至切换到完全不同的数据库。 +>我从未听说过如此严格的限制。 -的确，在将应用程序拆分为较小的服务时，可能需要进行一些性能折衷。 但是，我们发现，在满足高可伸缩性和高可用性要求方面获得的灵活性远远超过了其价值。 +我认为这不是资源 POV 的局限性，而是创建某种社区的一种方式。 这就是为什么我认为这是一个如此出色的举动。 -### 数据建模 +信息太少：） +您是否正在使用 memched 将数据缓存在前端 Web 服务器，数据库或应用程序服务器（或全部）上。 您正在使用哪种应用服务器。 您在应用服务器上使用哪种缓存提供程序？ 它是事务性的吗（如果不是，您是否在应用程序本身中管理事务，例如通过使用 EJB3 版本注释）？ -我们的大多数服务都处理相同的数据，只是格式不同。 一切都必须保持一致。 为了使所有这些服务的数据保持最新，我们严重依赖 Kafka。 Kafka 非常快，也很耐用。 速度需要权衡。 仅保证 Kafka 邮件至少发送一次 ，并且不能保证依次发送。 +感谢您撰写此摘要。 -我们如何处理？ 我们已将所有变异路径建模为可交换的：可以以任何顺序应用操作并最终得到相同的结果。 它们也是幂等的。 这有一个很好的副作用，我们可以重放 Kafka 流以进行一次性数据修复作业，回填甚至迁移。 +我喜欢普及性是关于用户而不是功能，以及愿景应对公司产生的影响。 我最近在 [http://trooji.wordpress.com/2007/12/04/soviet-vs-us-design-philosophy/](http://trooji.wordpress.com/2007/12/04/soviet-vs-us-design-philosophy/) 阅读了类似的文章 -为此，我们利用了 HBase 和 Cassandra 中都存在的“单元版本”的概念。 通常，这是一个时间戳，但可以是您想要的任何数字（有一些例外；例如，MAX_LONG 可能会导致一些奇怪的行为，具体取决于您的 HBase 或 Cassandra 的版本以及架构如何处理删除）。 +嗨，沃伦，Fotolog 的 CTO，您将休眠与 memcached 一起使用还是开发了自己的缓存管理系统？ -对我们来说，这些单元格的一般规则是它们可以具有多个版本，而我们订购版本的方式则取决于它们提供的时间戳。 考虑到这种行为，我们可以将传入的消息分解为一组特定的列，然后将该布局与自定义应用程序逻辑结合起来进行逻辑删除，同时考虑时间戳。 这样可以在保持数据完整性的同时盲写基础数据存储。 +我想知道是否有人使用 memcached 作为休眠的缓存解决方案。 -仅仅盲目地将更改写入 Cassandra 和 HBase 并非没有问题。 一个很好的例子是在重放事件中重复写入相同数据的情况。 尽管由于我们努力使记录成为幂等，数据的状态不会改变，但必须压缩重复的数据。 在最极端的情况下，这些额外的记录可能会导致大量的压缩延迟和备份。 由于这个细节，我们密切监视压缩时间和队列深度，因为在 Cassandra 和 HBase 中落后于压缩会导致严重的问题。 +问题：在此过程中，PNG 是否被用作扩大成功的手段？ 如果是这样，请描述可能的过程。 -通过确保流中的消息遵循一组严格的规则，并设计使用服务以预期乱序和重复的消息，我们可以使大量不同的服务仅与一两秒钟保持同步 滞后的更新。 +感谢您撰写此摘要。 -### 服务设计 +Fotolog 的惊人发展。 出于好奇，我想知道它使用了哪些收入流来产生收入。 他们打算使用 [http://www.stumblehere.com“](在线分类还是基于广告的获利解决方案？ -我们的大多数服务都是用 Java 编写的，但是使用的是一种自以为是的现代风格。 在设计 Java 服务时，我们要考虑一组通用准则： +这全都与名声有关。 即使您的网站没有任何内容，如果您拥有良好的搜索引擎优化 +----- +[http://underwaterseaplants.awardspace.com“](海洋植物 +[http://underwaterseaplants.awardspace.com/seagrapes.htm“](海葡萄... [http://underwaterseaplants.awardspace.com/plantroots.htm “](植物根 -* **做一件事，做好它。** -设计服务时，它应该承担单一责任。 实施者可以决定职责中包括的内容，但是她或他将需要准备在代码审查情况下证明其合理性。 - -* **没有共享的操作状态** -设计服务时，假定将始终至少有三个实例在运行。 服务需要能够在没有任何外部协调的情况下处理任何其他实例可以处理的相同确切请求。 那些熟悉 Kafka 的人会注意到，Kafka 使用者在外部协调对 topic：group 对的分区所有权。 本指南涉及特定于服务的外部协调，而不是利用可能在幕后进行外部协调的库或客户端。 - -* **约束您的队列** -我们在所有服务中使用队列，它们是将请求分批并将其散布到最终将完成任务的工作人员的好方法 从外部阻止。 所有队列都应有界。 边界队列确实引发了许多问题，但是： - - * 当队列已满时，生产者会怎样？ 他们应该阻止吗？ 除？ 下降？ - - * 我的队列应该有多大？ 要回答此问题，有助于假设队列始终已满。 - - * 如何完全关闭？ - - * 根据确切的用例，每个服务将针对这些问题提供不同的答案。 - -* **命名自定义线程池并注册 UncaughtExceptionHandler** -如果最终创建自己的线程池，则使用 [的构造函数或帮助器方法 ]执行器](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html) ，以便我们提供 ThreadFactory。 使用该 ThreadFactory，我们可以正确地命名线程，设置线程的守护进程状态，并注册 [UncaughtExceptionHandler](https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler-) 以处理将异常置于顶部的情况 堆栈。 这些步骤使调试我们的服务变得更加容易，并且使我们避免了深夜的挫败感。 - -* **优先于可变状态而不是可变状态** -在高度并发的环境中，可变状态可能很危险。 通常，我们使用可以在内部子系统和队列之间传递的不可变数据对象。 拥有不变对象是子系统之间通信的主要形式，这使得并发使用的设计更加简单，并且使故障排除更加容易。 - -## 我们从这里去哪里？ - -凭借 Urban Airship 通过移动钱包通行证发送通知的功能，对 Web 通知和 Apple News 通知的新支持以及其将通知发送到任何平台，设备或营销渠道的开放渠道功能，我们预计通知量将成倍增长 。 为了满足这一需求，我们将继续在“核心交付管道”架构，服务，数据库和基础架构上进行大量投资。 要了解有关我们技术的更多信息以及前进的方向，请参阅 [GitHub](https://github.com/urbanairship) ， [开发人员资源](http://docs.urbanairship.com/dev-resources.html) ， [文档](http://docs.urbanairship.com/index.html) 和我们的 [职位页面](https://www.urbanairship.com/careers) 。 \ No newline at end of file +这真的是很棒的信息，谢谢，这正是我所需要的 \ No newline at end of file diff --git a/docs/120.md b/docs/120.md index 5422445..eeb692c 100644 --- a/docs/120.md +++ b/docs/120.md @@ -1,361 +1,74 @@ -# ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行 +# GOV.UK-不是你父亲的书库 -> 原文： [http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html) +> 原文： [http://highscalability.com/blog/2013/6/3/govuk-not-your-fathers-stack.html](http://highscalability.com/blog/2013/6/3/govuk-not-your-fathers-stack.html) -![](img/f404c63d80f6d9b153a926d699db0a09.png) +![](img/0df17cabb1cc47fff35a9eaa7db8ac1b.png) -ESPN 于 1978 年播出 [](http://en.wikipedia.org/wiki/History_of_ESPN)。 在过去的 30 多年中，请想一想我们所见过的奇观！ 当我想到 ESPN 时，我想到的是一个全球性品牌，这正是黄金时段的定义。 它显示在他们的统计数据中。 ESPN.com 的峰值是每秒 100,000 个请求。 毫无疑问，他们的巅峰赛事是世界杯。 但是，如果您知道 ESPN 仅由几百台服务器和数十名工程师提供支持，您会感到惊讶吗？ 我曾是。 +我不确定在启动时使用的堆栈 [GOV.UK 是什么样的。 也许有一些信使猫头鹰和许多蜘蛛网？ 但事实并非如此。 没那么多，所以我认为任何在自己的构架中寻找想法的组织都可以从他人的明智选择中学习一些东西。](http://digital.cabinetoffice.gov.uk/govuk-launch-colophon/) -您是否会惊讶于 ESPN 正在经历从企业架构到能够处理由于移动使用，个性化和服务导向的增长而驱动的 Web 规模负载的根本转变？ 再一次，我以为 ESPN 只是想看电视上的体育节目而感到惊讶。 ESPN 的意义远不止于此。 ESPN 正在成为一个运动平台。 +使用的技术的多样性令人惊讶。 他们使用“至少五种不同的编程语言，三种独立的数据库类型，两种版本的操作系统”。 有些人可能认为这是一个弱点，但他们认为这是一个优点： -ESPN 如何处理所有这些复杂性，责任，变更和负载？ 与 HighScalability 上的大多数其他配置文件不同。 ESPN 的迷人故事由 [Manny Pelarinos](http://www.linkedin.com/in/manole) ，ESPN 工程部高级总监在 InfoQ 演讲中讲述 [Architecture ESPN](http://www.infoq.com/presentations/Architecture-Scale-ESPN) 的规模。 来自 [Max Protect 的信息：ESPN.com 上的可伸缩性和缓存](http://www.infoq.com/presentations/Max-Protect-Scalability-and-Caching-at-ESPN) 也已纳入其中。 +> 我们之所以经营如此多样化的生态系统，是因为我们专注于解决实际问题。 我们的首要任务是了解问题或我们正在解决的需求，然后为工作选择最佳工具。 如果我们将自己的需求限制在已有工具的基础上，那么我们就有可能无法以最佳方式解决用户最初的问题。 通过限制软件的多样性或在项目上执行严格的组织标准，就有可能沦为货物狂热者，在这种情况下，我们只需对所做的一切重复相同的模式和错误。 -在个人前计算机时代开始，ESPN 建立了创新的有线和卫星电视体育帝国。 从最初的 30 分钟计划中回顾了当天的运动，他们继续与 NBA， [USFL](http://en.wikipedia.org/wiki/United_States_Football_League) ，NHL 达成交易，后来成为大鱼 美国国家橄榄球联盟的所有运动。 +博客文章[中概述了这种“无论如何都使用最佳工具”的政策。 在现代初创公司中找不到的唯一选择是使用 Skyscape 作为其云提供商。 我假设这与有关数据主权的法律问题有关，因为这是政府站点，但除此之外，这完全不符合标准的现代网络实践：监视，仪表板，连续发布，多语言持久性，分布式源代码控制等。 看到政府得到它。](http://digital.cabinetoffice.gov.uk/2013/06/03/benefits-of-diversity/) -逐项体育交易的目的是从所有可能的来源中获取体育数据，以便 ESPN 可以报告比分，播放电影片段，并通常成为一站式购物，包括电视和后来的网络体育节目。 +他们正在使用什么堆栈？ （这是直接副本，请随时阅读原始文档） -这是一个需要理解的复杂系统。 他们在电视&广播，现场评分，编辑和发布，数字媒体，体育比分，网络和移动，个性化，幻想游戏等方面进行了大量工作，他们还希望将 API 访问权限扩展到第三方开发人员。 与大多数关于 HighScalability 的配置文件不同，ESPN 具有企业传统。 它是一个 Java Enterprise 堆栈，因此您将看到 Oracle 数据库，JMS 代理，Java Bean 和 Hibernate。 +### 前端： -我们将学习的一些最重要的课程： +* HTML / CSS / JS-在适当的地方使用 HTML5，重点放在可访问性上，并在哪里可以验证 +* 我们使用 [jQuery](http://en.wikipedia.org/wiki/Jquery) 作为我们的主要 JavaScript 库 +* 使用 [Nomensa 可访问媒体播放器](https://github.com/nomensa/Accessible-Media-Player)播放视频 +* 后端管理系统使用 [Twitter Bootstrap](http://twitter.github.com/bootstrap/) +* 我们使用 [SCSS](http://en.wikipedia.org/wiki/Scss) ，如前端工具包的[中所示](https://github.com/alphagov/govuk_frontend_toolkit) +* 我们已经使用 [A2-Type 进行字体制作](http://www.a2-type.co.uk/)。 -* **平台更改了所有内容** 。 ESPN 将自己视为内容提供商。 这些天的内容可以通过多种途径访问。 它可以在电视，ESPN.com 或移动设备上显示，但内容也正被越来越多的内部应用程序（例如 Fantasy Games）所占用。 他们还希望提供一个外部 API，以便开发人员可以在 ESPN 资源上构建。 ESPN 希望成为建立在体育内容平台上的围墙花园，该平台可以集中利用其对所有人的主要优势，这是对体育相关内容和数据的前所未有的访问。 ESPN 希望在体育领域做到这一点：Facebook 为社交服务，苹果为应用服务，谷歌为 AI 服务。 问题正在从企业架构过渡到基于 API 和服务的平台，这是一个艰难的转变。 他们可以做到。 他们正在这样做。 但这将很难。 +### 服务器的核心： -* **网络规模改变了所有内容** 。 如今，许多 Web 属性都使用 Java 作为其标准的后端开发环境，但是在 Java Enterprise 时代成长的 ESPN.com 完全采用了规范的 Enterprise 体系结构。 而且效果很好。 直到出现了从相对可预测的 ESPN.com 经历的企业级负载到由高移动流量，大规模定制和平台问题所主导的世界的阶段过渡。 我们在本机 Web 属性中看到的许多体系结构选择现在必须由 ESPN.com 使用。 +* 我们正在使用 [Skyscape](http://digital.cabinetoffice.gov.uk/2012/09/18/introducing-a-new-supplier-skyscape/) 中的[基础架构即服务](http://digital.cabinetoffice.gov.uk/2012/09/25/why-iaas/) +* 我们使用 [Akamai](http://en.wikipedia.org/wiki/Akamai_Technologies) 作为我们的内容分发网络 +* 我们的服务器正在运行 [Ubuntu GNU / Linux 10.04](http://en.wikipedia.org/wiki/Ubuntu_(operating_system)) ，我们希望尽快升级到 12.04。 +* 使用 PuppetDB 通过 [Puppet](http://en.wikipedia.org/wiki/Puppet_(software)) 管理服务器 +* Web 服务由 [nginx](http://en.wikipedia.org/wiki/Nginx) 处理，代理[独角兽](http://unicorn.bogomips.org/)用于我们的红宝石应用程序。 我们还使用 [gunicorn](http://gunicorn.org/) 来运行一些支持服务。 团队之一写了 [Unicorn Herder](https://github.com/alphagov/unicornherder) ，使 Unicorn 与[新贵](http://en.wikipedia.org/wiki/Upstart)保持良好的配合。 +* 我们内部使用 [haproxy](http://haproxy.1wt.eu/) 进行内部负载平衡，并使用 [Varnish](http://en.wikipedia.org/wiki/Varnish_(software)) 缓存请求 -* **个性化更改了所有内容** 。 当为每个用户动态构造所有内容，并且必须在每种访问方式（.com，手机，电视）上跟随您时，曾经保存数据库的缓存现在变得不那么有用了。 +### 重定向： -* **Mobile 改变了所有内容** 。 它给您的架构带来无处不在的压力。 在只有网络架构的情况下，这没什么大不了的，因为用户减少了，服务器也减少了。 在移动用户和服务器数量如此之多的移动时代，这种架构决定产生了巨大的变化。 +* nginx 值得一提，因为[让我们进行所有重定向](http://digital.cabinetoffice.gov.uk/2012/10/11/no-link-left-behind/) +* 我们正在使用 [perl](http://www.perl.org/) 来管理和测试重定向 +* 有一些 [php](http://en.wikipedia.org/wiki/Php) 可将有用的链接添加到已淘汰 DirectGov 和 Businesslink 内容的“已消失”页面 +* [node.js](http://en.wikipedia.org/wiki/Node.js) 被用来构建用于查看重定向的并排浏览器 -* **伙伴关系就是力量** 。 ESPN 可以创建一个有围墙的花园，因为多年来，他们建立了合作伙伴关系，使他们可以特别访问其他人没有的数据。 最好先做到最好。 NFL 和 MLB 之类的个人体育项目试图通过自己的网络来获取这一价值，这在某种程度上削弱了这一优势，但是每个人都需要相处的力量，如果 ESPN 能够执行的话，这将使他们成为强大的平台竞争者 。 +### 应用范围： -## 统计信息 +* 我们的大多数应用程序都是基于 [ruby​​](http://en.wikipedia.org/wiki/Ruby_(programming_language)) 编写的，基于 [Ruby on Rails](http://en.wikipedia.org/wiki/Ruby_on_rails) 或 [Sinatra](http://en.wikipedia.org/wiki/Sinatra_(software)) 。 +* 一些组件是用 [Scala](http://en.wikipedia.org/wiki/Scala_(programming_language)) 编写的，并基于 [Play 2.0](http://www.playframework.org/) 构建 +* 我们正在运行 MySociety 中的 [Mapit，它基于](http://mapit.mysociety.org/) [Django](http://en.wikipedia.org/wiki/Django_(web_framework)) 构建 -* 互联网上排名第一的体育网站。 所有网站的前 10 名。 18-54 岁男性中排名第五的网站（Facebook，Google，Microsoft，Yahoo 更大）。 +### 数据库和其他存储： -* 仅由几百台服务器供电。 +* 对于大多数系统，我们使用 [MongoDB](http://en.wikipedia.org/wiki/Mongodb) ，一些应用程序也使用 [MySQL](http://en.wikipedia.org/wiki/Mysql) 。 [Mapit 和 Puppet 使用 PostgreSQL](http://en.wikipedia.org/wiki/Postgresql) 。 +* 尽管 [solr](http://en.wikipedia.org/wiki/Solr) 目前是 Need-o-tron 的后端，但该网站上的大多数搜索是由 Elasticsearch 支持的[。](http://digital.cabinetoffice.gov.uk/2012/08/03/from-solr-to-elasticsearch/) +* 一些事件驱动系统使用 [RabbitMQ](http://en.wikipedia.org/wiki/Rabbitmq) -* 有几十个服务站点的主要部分，例如首页服务。 +### 监视，管理和警报： -* 只有几十名工程师。 +* 我们使用 [statsd](https://github.com/etsy/statsd) 从我们的应用中收集指标 +* 我们使用 [logstash](http://logstash.net/) 收集日志 +* 我们使用[神经节](http://en.wikipedia.org/wiki/Ganglia_(software))监视系统 +* [石墨](http://graphite.wikidot.com/start)帮助我们制作许多图表来了解发生的情况 +* [Nagios](http://en.wikipedia.org/wiki/Nagios) 告诉我们是否需要对任何数据采取行动 -* 峰值为每秒 100,000 个请求。 高峰赛事是世界杯。 +### 配套工具： -* 体育专用数据的大小为千兆字节。 - -## 堆栈 - -* 基于 Java。 - -* Oracle 数据库， - -* AQ 流 - -* 消息代理 - -* WebSphere MQ - -* 有趣的是将地面人员集成为数据源和自动提要 - -* JMS Broker - -* Microsoft SQL Server - -* 休眠 - -* Ehcache - -* 我们 - -* IBM eXtreme Scale - -* 服装 - -* F5 负载均衡器 - -## 架构 - -![](img/2dd46c5fd8c738fa425d80d3174bf74d.png) - -* 十年前与 Paul Allen 的一家创业公司 Starwave 一起成立，因此他们在 Microsoft 技术方面大受好评，但选择了 Java。 Java 还很年轻，因此他们必须自己独立完成大部分工作。 该站点已发展了 100 多次和 100 多次迭代。 - -* 通过更多服务进行了扩展，例如 Watch ESPN 是一项新的专用服务。 在数百台服务器上部署了 100 多个逻辑数据库和 200 多个不同的应用程序。 - -* ESPN.com 的目标是为体育迷随时随地在任何设备上提供准确及时的数据，并访问更深的内容。 分数，统计数据和更深层次的内容必须准确，即时。 就像电视一样，没有中断。 - -* 不要认为自己是一家技术公司。 他们是媒体和内容提供商。 由迪士尼拥有，未公开交易。 - -* 数字属性：ESPN.com，奇幻游戏，移动设备（WAP，iPad，iPhone 等），WatchESPN（手机上的手表电缆），ESPN Ocho（物品，W，HS 等）。 不同的体系结构和服务为每个属性提供动力。 ESPN.com 是本演讲的主要内容。 - -* 例如波士顿和纽约的不同本地站点。 庞大的编辑团队会为每个本地站点提供本地版本，因此不同的粉丝群体会在游戏中产生不同的倾向。 - -* 以低硬件占用空间处理高负载的关键是复杂的页面和片段缓存系统。 实时更新（例如得分，统计信息，时间表）具有不同的缓存系统。 个性化也有其自己的缓存系统。 - -* 开发人员通常没有登录生产机器的权限。 - -## 架构是围绕应用程序和数据库组织的 - -* 数十个逻辑数据库。 MLB，NFL，NHL 等的数据库，以及每个数据库的应用程序，包括诸如 Frontpage 的更抽象的服务，用于为主要网站提供服务。 - - * 进程隔离。 如果部署了错误的代码，则不会破坏网站的其他部分。 - - * 不是整体架构，有不同的系统用于不同的运动。 - - * 历史上原始的 SOA 模型。 Frontpage 对返回 XML 的不同服务进行了多个 HTTP 调用，并且调用者对其所需的内容进行了解析。 不同服务之间的大量互连。 - - * Frontpage 计分板具有来自所有不同联赛的所有不同分数。 每种运动都有单独的应用程序。 单击 NHL 会通过负载均衡器点击 [VIP](http://en.wikipedia.org/wiki/Virtual_IP_address) ，将您带到 NHL 应用程序。 - - * 有一个首页应用程序，可通过调用其他服务来服务首页小部件。 - - * 应用程序服务。 数据库前面是 Web 应用程序服务器，其中包含这项运动的所有业务逻辑。 - - * 通常一项运动只有一项应用程序服务。 - - * 应用程序已集群，因此集群中有 6-10 个应用程序实例，因此它们可以水平扩展 - - * 例如，当足球比赛是季节性的时候，根据季节需求的指示，应用实例的数量将增加，而应用实例的数量将减少。 - - * 迪士尼数据中心具有一些弹性功能，但希望亚马逊在此领域进行改进。 - -* 所有提要都流入体育数据存储库（SDR）。 - - * 一个非常大的 Oracle 数据库。 - - * 您在.com 网站上看到的相同统计信息与在电视和 Sports Center 上的某些面板上用于创建最低报价的统计信息相同。 - - * 使用 Web 服务呼叫的电视访问统计信息。 - - * 电视&广播不需要以与其他属性相同的方式进行缩放，因此它们可以直接使用 Oracle 数据库中的数据。 - - * Oracle AQ 流用于在 Oracle 端分发消息。 - - * 消息网关将消息分发到具有自己的 JMS 代理的数字媒体端。 - - * 位于康涅狄格州布里斯托尔。 - - * 像 ESPN.com 这样的数字媒体，都以创建提要和标准化消息以供企业内部消费的系统为前端。 - - * JMS Broker（WebSphere MQ）用于分发消息。 - - * 位于拉斯维加斯数据中心。 - - * .com 和 TV 位于不同的数据中心。 两个数据中心之间的延迟为 80 毫秒。 这两个 JMS 代理经过高度优化，可以尽快发送更新。 - - * PubSub 是 JMS 代理之上的体系结构。 应用程序侦听不同的主题，从队列中读取消息，解组到 JavaBeans 中，保留到数据库中，然后将数据直接推送到 Web 应用程序服务器中。 - -## 统计资料从何而来？ （数据提取） - -* 每个数据库都有一个批处理或提要处理服务，负责更新所有统计信息，进度表，排名，得分等。 - -* 大多数数据来自第三方供应商或职业联赛本身。 - -* 直接进纸。 例如，他们与 MLB 有合作关系，数据直接从 MLB 发送。 使它们比其他服务具有更大的延迟优势。 - -* 体育馆供稿。 音高效果（音高位置）数据是从体育场发送的。 - -* 手动进纸。 ESPN 人员对游戏进行评分并手动将数据输入系统。 - - * 大学橄榄球没有统计信息供您查看，因此观看者可以输入数据。 - - * 故障转移。 如果自动馈送发生故障，它还可以用作备用故障转移系统。 出现问题时，可以手动接管游戏。 - -* 几乎每夜都有来自第三方的“官方”统计数据被覆盖。 有很多工具和系统可以确保提要正确，但更正后的数据会在晚上出现。 - -* 除非游戏正在进行，否则消息速率相对较低。 复杂，因为所有游戏事件都需要按顺序处理。 - -* 与.com 相同的统计信息也可以为 TV 供电，但是访问方式不同。 - -## 应用程序服务 - -* 服务之间通过本地服务，远程 EJB 或 REST 进行直接呼叫，从而彼此对话。 - -* 数据中心内的首选模式是具有复杂缓存层的 EJB。 从 Java 客户端访问。 - -* 对于 REST 服务，有一个基于 TTL 的简单缓存层。 可从 PHP，Javascript 等访问。 - -* 在数字媒体方面，他们使用 Microsoft SQL Server，并在该 Java 应用程序服务器之上。 之所以进行扩展，是因为他们尝试不接触数据库。 它们会缓存所有内容，因此不会命中数据库。 - -## 应用程序级别缓存 - -* 从历史上看，Web 应用程序中的对象缓存会保留表对象的内存哈希图。 W 将游戏永久缓存在哈希图中，直到游戏填满或通过数据库触发器到期为止。 缓存是按应用程序服务器复制的。 - -* 这种方法简单易行，在移动设备激增之前就可以使用，因为相对容易预测为 NFL 流量等服务所需的服务器数量。由于移动流量如此之大，过期消息不断涌现。 例如，随着游戏统计信息的更新，到期时间将过去，并且所有服务器都要求更新游戏分数。 现在将推送更改而不是过期。 - -## 页面缓存框架 - -* 高性能页面和片段缓存。 - -* 缓存是另一种称为 Stout 的自有技术。 将 IIS Web 服务器与 ISAPI 页面缓存插件一起使用。 用 C ++编写。 在便宜的低端硬件上运行，因此极具成本效益。 仅使用 TTL 缓存。 每秒查看 1000 多个请求。 应用层每秒收到 100 多个请求。 应用程序层具有自己的缓存层。 数十个 Stout 服务器保护应用程序层。 应用服务器层保护数据库层，因此无需横向扩展数据库。 粗壮的应用程序服务器从循环中退出。 看清漆似乎更快。 - -* 缓存为王。 该体系结构最重要的部分是页面缓存层。 尽可能大量使用页面缓存。 - -* 每个 URI，基于 TTL 的到期时间。 透明地与负载平衡器进行对话，并说对于某些 URI，我们希望缓存一定的时间。 - -* 最高精度是低 TTL，并且会阻塞直到它返回数据。 访问速度最慢。 例如，用于记分板数据。 - -* 最低精度是指高 TTL 不会阻塞，它会返回脏数据。 最快的访问速度，用于不经常更新的数据。 例如，用于计划数据。 - -* 编辑内容和其他不经常更改的内容可以使用更长的 TTL 进行缓存。 - -* 自动降级无响应的服务器。 - -* 基于 TTL 的缓存不能很好地工作，因为它会导致频繁访问数据库。 想象一下，数十台服务器上的 TTL 为几秒钟，那么效果不佳。 - -* 在每个运动的高峰时间每秒节省数百万的数据库访问。 巨大的胜利。 当只有网络时，这一切都无关紧要，因为用户减少了，服务器也减少了。 在拥有更多用户和 50 多个服务器的移动时代，这些架构决定将产生巨大的变化。 - -* 他们的自定义解决方案的优势在于它可以在便宜/低端的硬件上运行。 - - * 负载均衡器的十万个请求 - - * 实际应用服务器的请求数为 100 - - * 10 个 MLB 服务器，而不是 50 个意味着节省大量资金 - -## 通用对象模型 - -* 尽管他们有许多不同的数据库对应不同的运动，但在它们前面却有一个共同的对象模型。 在通用模型中尽可能多地添加跨运动项目通用的内容。 - -* 每个游戏都有一队，通常两队。 奥林匹克运动有竞争者。 通用供稿中的代码是相同的，它允许进行强大的操作，例如为我获取所有体育页面的所有比赛成绩，而不论运动如何。 - -* 在特定运动中，他们具有特定运动模型。 适用于 NFL，MLB 等。当他们详细了解某项运动的今天页面时，将使用运动专用模型。 - -* 一层隐藏了复杂性，然后在必要时退回特定于运动的模型。 - -## 休眠 - -* TTL 缓存不起作用，因为数据在一天中并不经常更改，而在游戏中则经常更改。 - -* 很少是按标识查找的，它们大多是按查询查找的，例如给我提供整周的比赛次数，以便显示时间表，或者向我显示特定团队正在比赛的所有比赛。 数以百计的查询。 - -* 首先易于使用。 当事情变得更加复杂或您需要最佳性能时，很难有效地使用它。 - -* Ehcache 用作实体更新的二级缓存，效果很好。 - -* Hibernate 查询缓存机制不足，因此它们构建了 JPA 查询复制器。 - - * 状态经常更改（例如游戏得分），但是每个人的更改都是相同的。 不适用于个性化数据或幻想，不适用于所有用户的更改。 - - * 在获取更新的过程中，他们在实体端的侦听器使用规则引擎监视他们关心的所有更新。 根据更新内容过滤掉查询。 自特定时间开始，针对特定游戏的更新不应触发要求数据的查询。 该查询将重新运行并推出集群，因此所有用户都将得到更新，这将使数据库不堪重负。 - -## 内容管理系统 - -* UI 不太好，重点是性能和规模。 - -* 两个子系统：CMS 和 DCS（动态内容系统）。 - -* CMS 编辑人员。 高度优化的查询。 针对更改故事的用户的优化 UI。 完整的关系数据库模型（SQL Server）。 只有几百个编辑器，因此它不需要水平缩放。 - -* DCS 使用 SQL Server，但已被规范化并存储为 Blob 类型。 检索速度很快。 编辑的数据在 CMS 中继续。 发布文章时，内容将序列化并放入 DCS。 DCS 是 10 个可以水平扩展的服务器的集群。 - -* 所有 76 个服务（MLB，NFL 等）都有一个知道如何与 DCS 对话的插件。 该插件还具有一个缓存。 因此，在发布时，将过期发送给每个客户端，以便它将从 DCS 中获取新内容。 - -* 由迪士尼 Internet Group 构建的模板引擎。 迪士尼拥有 ABC 和 ESPN。 十年前建立了称为 T 的语言。高性能。 比 JSF 更像 JSP。 多年来已经建立了十万个模板。 - -* 硬件方面便宜，因此它们必须在软件方面高效，这就是为什么他们没有迁移到其他速度较慢的模板系统的原因。 - -## 实时比分（ESPN.com） - -* 大多数内容都不会很快更新。 编辑内容无法快速更新。 对于分数，他们希望获得最快的分数，因此前端和后端的处理方式有所不同。 - -* 主供稿模板，其中包含游戏的所有数据。 一个进程轮询模板以获取更新，并将更改放入数据库的快照表中。 一切都被称为 Caster 的东西。 这是一种自定义技术，就像网络套接字存在之前的网络套接字一样。 从前端到后端有一个开放的套接字连接，这是大量的 Caster 服务器集群，并且更新通过该流传输。 前端有一个 Flash 连接器。 高端服务器除了管理与前端闪存连接器的连接外，什么也不做。 它可以进行 10 万多个并发的开放套接字连接。 每次更新快照时，都会通过适当的连接发送快照。 页面上运行的 JavaScript 读取更新并将其显示在页面上。 - -* Flash 连接器会每隔 30 或 60 秒降级为轮询。 糟糕的带宽使用率。 将网络套接字视为替换项。 - -## 个性化设置 - -* 个性化就是告诉他们您最喜欢的东西是什么：体育，球员，球队，幻想数据。 这些是您特有的。 - -* 与 ESPN.com 的其余部分完全不同，并且有很多特定要求。 - -* 难以缓存，因为与其他缓存方案一样，它是 1-1 而不是 1。 并且数据必须在任何地方（.com，手机，电视）都跟随您 - -* 有很多个性化数据。 超过 500GB。 无法适应单个 JVM 或数据库，而该 JVM 或数据库无法按每秒 10 万个请求的吞吐量进行扩展。 - -* 使用 IBM eXtreme Scale 构建数据网格。 - - * 这是一个分布式的内存哈希图。 购买了 7 台服务器，每台服务器具有 96GB 的 RAM。 软件自动平衡数据并将其分区到 JVM。 - - * JVM 的最大问题是垃圾收集，因此每个服务器上运行 100 个 JVM，以最大程度地减少垃圾收集，并且软件会自动分片所有内容。 - - * 仅存储您独有的东西。 如果您是洋基队的粉丝，他们只是存储洋基队的 ID，而不是存储有关洋基队的所有数据。 - - * eXtreme Scale 的设置比 Coherence 困难，但价格便宜，并且它们从 IBM 获得的支持比 Oracle 多。 - -* Composer 系统知道如何与 NFL 和 MLB 等所有服务进行对话，并且知道如何与网格进行对话。 因此，要构建个性化页面，他们将转到网格并为您喜欢的团队提供正确的服务，并以 JSON 供稿的形式构建时间表，得分，幻想数据，专栏作家等。 在客户端，数据被组装。 借助 6 个用于 Composer 的商用服务器，每秒可处理数以万计的请求。 - -## 奇幻游戏 - -* 非常不同的用例。 幻想数据是根据实际统计数据计算得出的，然后转换为“组合”数据，因此它们具有不同的提取过程。 - -## API - -* 用于编辑内容的 API。 数据权利很棘手，但它们拥有内容，因此就是发布的内容。 - -* 他们面临的最大问题之一是招募新人并入职。 拥有文档和一致的 API 可以在防火墙之外为开发人员提供 API 的帮助，但在内部却可以帮助，因为它更易于构建应用程序。 - -* EJB 层的一些技巧无法应用到 API，因此尚未完全弄清。 - -* 弄清楚 API 很困难。 开发人员希望一次调用所有数据。 但是他们倾向于更细粒度的 API，这将需要更多的调用和开发人员的更多工作。 - -* Mashery 用于通过 TTL 缓存保护 API。 不同级别的轮询。 外部用户每分钟只能处理这么多请求。 在内部，限制不太严格。 - -* 最复杂的运动是足球，因为有这么多的提要提供商必须与他们合作来获取数据。 特别提款权团队将所有提要标准化为足球提要。 如果 Feed 出现问题，他们可以接管 Feed 并将其手动添加到系统中。 - -## 特殊效果 - -中的 [ESPN 新兴技术对高分辨率图像](http://on-demand.gputechconf.com/gtc/2013/presentations/S3487-ESPN-NVIDIA-GPUs-High-Res-Imagery.pdf) 的 NVIDIA GPU 解决方案的使用。 细节不多，因此这些基本上只是幻灯片中的要点，但这很酷，看上去就像是屏幕上的魔术。 - -* ESPN 是高级实时图形的创新者，他们将 GPU 用于高价值功能，例如 Huck-O-Meter，HRD Ball Track，Snap Zoom，Ref Mics，Sky Cam，Ultra-Mo，播放器跟踪， 1st &十号线，K 区，获得艾美奖的 EA 虚拟剧本以及更多其他东西 - -* 系统中的每个 GPU 分为输入，输出，输入/输出或计算引擎 - -* 所有 GPU 均可通过 CUDA 进行对等访问 - -* 可以将多个输入卡和输出卡分配给 GPU - -* 硬件抽象层允许通过 gpuDirect 来自多个制造商的视频 I / O 硬件 - -* 每个 GPU 管道均可处理输入和输出的独特视频格式 - -## 未来 - -* 如有必要，对于具有运动专用扩展名的所有数据都具有通用的 API 。 - -* 移至缓存推送模型 （不会过期）。 借助移动和水平模型以及越来越多的服务器，越来越多的服务器将通过数据库进行更新。 由于他们没有庞大的数据库，因此这成为了瓶颈。 如果在 NFL 周日停止更新分数，那将是不好的一天。 - - * 随着数据的传入，将其整理成通用的对象模型格式。 它异步保存到数据库，也异步推送到集群的其余部分。 例如，当发生某些更改时，源服务器将直接发送给使用者，而不是 6 台服务器，而无需将其发送到数据库。 - -* 更松散耦合的服务 。 通过 Java 远程处理，在本地（相同的 JVM）。 - -* 为所有运动创建一项服务 。 - -* 利用泛型和代码生成 加快转换其余部分的过程。 - -* 到处缓存 以保护所有组件免受负载的影响。 - -* 提供更多个性化的内容 ，并随处可见（.com，手机，电视）。 - -## 经验教训 - -* **缓存推送模型**。 随着数据的传入，异步地保留到数据库中，并且也异步地推送到集群的其余部分。 更改被直接推送给使用者，这意味着使用者可以踩踏数据库以获取新的更改。 在可预测资源的更静态世界中不是必需的，而是在移动世界中可伸缩性的关键。 - -* **足够好就足够** 。 当您刚开始使用某项技术时，您必须自己构建很多东西，以后随着新的更好的代码的出现，它们看起来会很愚蠢。 但是您需要编码并使其正常工作，因此足够了。 - -* **您可以做一些** 。 您想到了 ESPN，又想到了行业领导者。 但是，ESPN 很少使用计算资源，也很少使用开发人员来创建高价值，高度可见的系统。 他们考虑效率。 一家拥有网络遗产的公司可能只是以机器便宜为由添加了所需的机器，而 ESPN 实际上考虑节省金钱以获取利润。 一个奇怪的概念。 - -* **了解您的听众** 。 决策是由目标决定的。 随处可见的设备，快速准确的数据，广泛的覆盖范围和高可用性。 这些价值反映在体系结构和决策过程中。 - -* **手动故障转移** 。 他们的系统架构的一个有趣的方面是，既包括手动输入游戏数据，又包括自动订阅源失败时的手动故障转移策略。 大多数人可能不会考虑将其作为一种选择，但是它对实现拥有快速准确数据的目标高度奉献。 - -* **针对不同用例的定制系统** 。 他们让不同运动和服务的需求来驱动体系结构。 这样就可以进行并行开发并完成工作。 例如，他们建立了一个查询缓存机制，专门针对游戏更新和发行进行了优化，因为这是他们的事。 - -* **使不同的事物看起来相同** 。 尽管千变万化的架构方法在巨大的变化和发展中非常有用，但当您想要创建通用的 API 服务层或响应移动或个性化等压力因素而进行系统范围的优化时，它确实很烂。 因此，相反的作用是建立通用的体系结构，通用的数据模型，然后在必要时退回特定类型的模型。 - -* **缓存以保护数据库** 。 根本不是一个新主意，但这是一个对 ESPN 来说非常有效的核心可伸缩性策略。 这使他们不必在数据库层上投入大量资金。 但是，个性化，这是未来的潮流，是缓存破坏者。 - -* **一致性可帮助所有开发人员** 。 拥有文档和一致的 API 可以在防火墙之外为开发人员提供 API，但在内部也可以提供帮助，因为构建应用程序更加容易。 - -很棒的帖子，关于 ESPN 从未想过/知道的东西，在网络/数据库相关技术上发挥了如此重要的作用。 不过有一个问题。 如今，在大数据和网络规模方面存在很多障碍。 您提到它们主要依赖于 Oracle 数据库以及 MS SQL Server 数据库上的某些其他服务。 关于 NoSQL，网络规模以及传统 RDBMS 如何无法扩展的关系，有很多可以说是“大战”。 ESPN 会考虑吗？ 这些天，我在工作中进行了一些友好的讨论，因为他们正试图强加 mongo db，仅仅是因为 MS SQL Server“无法扩展” ... ejem？ - -如果您不打算透露有关该基础架构的详细信息，则无需说明在如此小的基础架构上要完成多少工作。 - -并不是说他们正在运行带有 8 gig RAM 的四核 Xeon。 \ No newline at end of file +* 我们所有的代码都经过 [Jenkins](http://en.wikipedia.org/wiki/Jenkins_(software)) 的测试，我们也将其部署到服务器上 +* 我们通过 Google Analytics（分析）跟踪网站的使用情况，并大量使用其 API 来构建信息中心 +* 我们有时会使用 [New Relic RPM](http://en.wikipedia.org/wiki/New_Relic) 进行性能评估 +* DNS 由 ja.net / Dyn 托管 +* 通过 [Amazon SES](http://aws.amazon.com/ses/) 发送的电子邮件（内部警报） +* 使用 [FontForge](http://fontforge.org/) 和 [FontTools](http://sourceforge.net/projects/fonttools/) 进行字体处理和准备 +* 我们使用 Google Apps，Pivotal Tracker 和 Campfire 保持联系并保持联系 +* Github 帮助我们管理和讨论我们的代码 +* Zendesk 使反馈保持畅通 +* 我们使用 [jekyll](http://jekyllrb.com/) & [heroku](http://www.heroku.com/) 进行一些原型设计 +* 我们建立了各种内部仪表板。 它们是我们的游乐场，您可以发现它们是用 Ruby， [Clojure，Node.JS 和 PHP](http://digital.cabinetoffice.gov.uk/2012/02/08/radiating-information/) 的混合物编写的 \ No newline at end of file diff --git a/docs/121.md b/docs/121.md index e251bba..ed7bd10 100644 --- a/docs/121.md +++ b/docs/121.md @@ -1,116 +1,39 @@ -# 扩大流量的设计决策 +# 缩放邮箱-在 6 周内从 0 到 100 万用户，每天 1 亿条消息 -> 原文： [http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html) +> 原文： [http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html](http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html) -![](img/4d2c9efe35022d4b456cdd4f9c5e6185.png) +![](img/7a05816f41b7aec7082ab24fd1746c24.png) -*Fashiolista.com 的创始人/ CTO Thierry Schellenbach 的来宾帖子，在 Twitter 和 Github 上关注@tschellenbach* +当大多数[早期博客文章](http://www.mailboxapp.com/blog/)处理着急于等待下载您产品的数十万用户的等待列表时，您就会知道您的产品运行良好。 这是一个令人羡慕的职位 [Mailbox](http://www.mailboxapp.com/) ，这是一个免费的移动电子邮件管理应用程序，在发布周期的早期就发现了自己。 -[Fashiolista](http://www.fashiolista.com/) 最初是我们在侧面开发的一项业余爱好项目。 我们绝对不知道它将成长为最大的在线时尚社区之一。 整个第一个版本的开发花费了大约两周的时间，而我们的 feed 实现却非常简单。 自那时以来，我们已经走了很长一段路，我想分享我们在缩放 Feed 系统方面的经验。 +电子邮件还没有完成吗？ 显然不是。 邮箱[小组大约 14 人](http://www.mailboxapp.com/blog/?p=1#to-grow-even-faster-mailbox-is-joining-dropbox)，在短短的六个星期内，邮箱的规模扩大到了 100 万用户。 截至 4 月，他们每天交付超过 [1 亿条消息](http://www.mailboxapp.com/blog/?p=1#mailbox-now-available-without-the-wait)。 -Feed 是 Pinterest，Instagram，Wanelo 和 Fashiolista 等许多大型初创公司的核心组成部分。 在 Fashiolista，供稿系统为[统一供稿](http://www.fashiolista.com/feed/?feed_type=F)，[聚合供稿](http://www.fashiolista.com/feed/?feed_type=A)和[通知](http://www.fashiolista.com/my_style/notification/)系统提供动力。 本文将说明在扩展 Feed 时遇到的麻烦以及与构建自己的解决方案有关的设计决策。 随着越来越多的应用程序依赖它们，了解这些供稿系统如何工作的基础至关重要。 +他们是如何做到的呢？ 邮箱工程负责人 [Sean Beausoleil](https://twitter.com/SeanBeaus) 在 readwrite.com 上进行了[内容丰富的采访，内容涉及邮箱如何计划扩展...](http://readwrite.com/2013/06/05/from-0-to-1-million-users-in-six-weeks-how-mailbox-planned-for-scale) -此外，我们开源了 [Feedly](https://github.com/tschellenbach/Feedly) ，它是为 Feed 提供动力的 Python 模块。 在适用的情况下，我将参考如何使用它来快速构建自己的供稿解决方案。 +* **提前发信号通知**。 发行前的发布视频有助于引起人们的兴趣，但也使他们能够在发行前就及早评估兴趣。 从热烈的反响中，他们知道他们将需要迅速扩大规模。 +* **具有一些独特的**。 一般人可能不认为邮箱应用程序将是一个肥沃的产品空间。 有很多竞争，但大多数都是 la 脚。 邮箱具有许多创新想法，其基于待办事项列表的电子邮件处理方法和有效的 UI 刷卡操作。 这有助于产生大量的早期嗡嗡声。 +* **了解产品的性质**。 电子邮件对业务至关重要，而且资源很重，因此他们计划必须尽早扩展。 没有让我们把它弄出来的，然后计划扩大以后的态度。 +* **目标**。 当 Mailbox 发布时，它只能在 Gmail 和 iPhone 上使用，显然是针对精通大型技术的市场，它将对 Mailbox 的新收件箱方法开放。 +* **扩展**。 邮箱不是新的邮件服务。 它是现有高质量邮件系统 Gmail 的更好界面。 感谢 Google 提供了使之成为可能的 API。 用户可以采用邮箱，而不必担心电子邮件会丢失。 +* **调制和迭代**。 他们遵循系统设计中明确的最佳实践，即设计模块化组件并根据需要迭代这些组件。 +* **原型**。 构建了一个使用 IMAP 的测试系统，以识别生产负荷下的瓶颈。 这些测试发现了在生产中很难修复的问题。 这是初创公司通常会跳过的成熟而重要的步骤。 +* **将技术数量保持在最低水平**。 他们不想成为许多不同系统的专家，他们想专注于产品的开发。 +* **通过预订系统**限制新客户的价格。 早于 Mailbox 的预订系统可能比该产品更为知名。 它有助于通过感知到的稀缺来刺激需求，同时还可以控制客户，因此可以以可控的方式缓慢添加负载。 首先是人们使用系统的经验，而不是获得新用户。 天才四处。 +* **疯狂的虔诚**。 开发人员不断努力解决问题并改进系统。 专注于开发的早期阶段。 它可能是整个产品生命周期中效率最高的。 +* **注意用户的操作**。 响应于用户使用模式，对核心基础结构进行了调整，分片或删除。 +* **事情不可避免地会失败，需要修复。 即使进行测试，生产中也会出现问题。 这只是您大规模发布任何内容时可以期望的。 迭代并继续迭代。 当您了解有关系统，数据和用户的更多信息时，系统会变得更好。** +* **玩弄技术**。 如果您拥有旧技术，或者做出了不再起作用的堆栈或工艺选择，则将其替换为可行的东西。 花时间进行新技术选择。 然后与他们一起跑步。 +* **利用先前的产品**。 创建 iPhone 待办事项应用程序时使用的经验和代码直接用于引导邮箱。 这为他们提供了使应用程序从一开始就感觉很快所需的经验。 +* **云是经济高效的**。 非常适合资源有限且期限紧迫的初创企业。 云中的服务器[“执行诸如发送推送通知，尽快下载电子邮件以及处理“被延缓”的消息等操作。”](http://www.mailboxapp.com/blog/?p=2#were-ramping-up) +* **这是旅程**。 团队构建，设计和修复产品的阶段是必不可少的学习，可以在产品的整个生命周期中获得回报。 它不能真正短路或在堆栈选择方面步履蹒跚。 这是一个优秀的团队和产品形成一个整体的一部分。 +* [被 Dropbox](http://www.mailboxapp.com/blog/?p=1#mailbox-now-available-without-the-wait) 收购。 产品发布大约一个月后，Dropbox 购买了 Mailbox。 这个想法是 Dropbox 将帮助他们成长更快。 +* **传达**。 如果您查看 [Mailbox 的博客](http://www.mailboxapp.com/blog)，他们会非常详细地解释发生的事情，以使客户感到安心而不是困惑。 -## 提要简介 +不幸的是，我们没有很多技术细节。 不难想象，邮箱的体系结构是高度并行且分片的，因为可以轻松地以无共享方式并行处理各个邮箱。 即使没有技术细节，它仍然是成功的云移动应用程序如何诞生的迷人肖像。 -缩放进纸系统的问题已被广泛讨论，但让我首先阐明基础知识。 该解决方案旨在使诸如 Facebook 新闻提要，Twitter 流或 [Fashiolista](http://www.fashiolista.com/) feed 之类的页面在高流量条件下工作。 所有这些系统的共同点在于，它们显示了您所关注的人的活动。 在我们的案例中，我们基于活动流的标准将活动对象基于[。 活动示例包括“ Thierry 在 Fashiolista 上的列表中添加了项目”或“ Tommaso 发了一条消息”。](http://activitystrea.ms/specs/atom/1.0/) +## 相关文章 -There are two strategies for building feed systems: +* [缩放 Pinterest-两年内每月从 0 到十亿的网页浏览量](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html) +* [邮箱如何在六周内扩展到一百万用户](http://readwrite.com/2013/06/05/from-0-to-1-million-users-in-six-weeks-how-mailbox-planned-for-scale) -1. **拉**，读取时将在其中收集提要 - -2. **按下**，在写入期间所有提要均已预先计算。 - -大多数实际的实时应用程序将结合使用这两种方法。 将活动推向所有关注者的过程称为扇出。 - -## 历史&背景 - -Fashiolista 的 Feed 系统经历了三项重大的重新设计。 第一个版本在 PostgreSQL 数据库上工作，第二个版本在 Redis 上使用，第三个当前版本在 Cassandra 上运行。 为了让您了解这些解决方案何时以及为什么会失败，我将简要介绍一些历史。 - -### 第一部分-数据库 - -我们的第一个设置只是查询了一个 PostgreSQL 数据库，看起来像这样 - -选择* from love，其中 user_id 位于（...） - -最令人惊讶的是该系统的强大功能。 我们通过了 1M 的爱，并且继续发挥作用，在达到 5M 的爱之后，它仍然继续起作用。 我们敢打赌，经过一千万次恋爱，它会破裂，但它一直保持平稳运行。 进行了一些数据库调整，但是这个简单的系统在大约 1 亿个爱人和 1 百万个用户中占有优势。 大约在那时，该解决方案的性能开始波动。 通常，它可以继续工作，但是对于某些用户而言，延迟会飙升至数秒。 阅读了许多有关 feed 设计的文章之后，我们使用 Redis 构建了 Feedly 的第一个版本。 - -### 第二部分-Redis & Feedly - -我们的第二种方法是在 Redis 中为每个用户存储一个提要。 当您喜欢某件商品时，此活动就会散发给所有关注者。 我们使用了一些巧妙的技巧来保持较低的内存使用率，这将在下一部分中介绍。 Redis 真的很容易设置和维护。 我们使用 Nydus 在数台 Redis 机器上进行了分片，并使用 [Sentinel](http://redis.io/topics/sentinel) 进行自动故障转移。 （当前，我们建议使用 [Twemproxy](https://github.com/twitter/twemproxy) 代替 [Nydus](https://github.com/disqus/nydus) ） - -Redis was a good solution, but several reasons made us look for an alternative. Firstly we wanted to support multiple content types, which made falling back to the database harder and increased our storage requirements. In addition the database fallback we were still relying on became slower as our community grew. Both these problems could be addressed by storing more data in Redis, but doing so was prohibitively expensive. ### 第三部分-Cassandra & Feedly - -We briefly looked at [HBase](http://hbase.apache.org/), [DynamoDB](http://aws.amazon.com/dynamodb/) and [Cassandra 2.0](http://cassandra.apache.org/download/). Eventually we opted for Cassandra since it has few moving parts, is used by Instagram and is supported by [Datastax](http://www.datastax.com/). Fashiolista currently does a full push flow for the flat feed and a combination between push and pull for the aggregated feed. We store a maximum of 3600 activities in your feed, which currently takes up 2.12TB of storage. The fluctuations caused by high profile users are mitigated using priority queues, overcapacity and auto scaling. - -## 饲料设计 - -我认为我们的历史可以很好地代表其他公司所经历的过程。 当需要构建自己的供稿系统（希望使用 Feedly）时，需要考虑一些重要的设计决策。 - -### 1.归一化与归一化 - -There are two approaches you can choose here. The feed with the activities by people you follow either contains the ids of the activities (normalized) or the full activity (denormalized). - -仅存储 ID 会大大减少您的内存使用量。 但是，这也意味着每次加载 Feed 时都要再次访问数据存储。 要考虑的因素之一是非规范化时多久复制一次数据。 如果您要构建通知系统或新闻提要系统，则将产生巨大的变化。 对于通知，您通常会针对发生的每个操作通知 1 或 2 个用户。 但是，对于基于关注的 Feed 系统，该操作可能会复制到数千个关注者中。 - -此外，最佳选择实际上取决于您的存储后端。 使用 Redis，您需要注意内存使用情况。 另一方面，Cassandra 具有足够的存储空间，但是如果您对数据进行规范化，则很难使用。 - -对于通知供稿和基于 Cassandra 构建的供稿，我们建议对数据进行非规范化。 对于基于 Redis 的供稿，您希望最大程度地减少内存使用并使数据规范化。 [Feedly](https://github.com/tschellenbach/Feedly) 允许您选择自己喜欢的方法。 - -### 2.基于生产者的选择性扇出 - -In their paper [Yahoo’s Adam Silberstein et.al.](http://research.yahoo.com/files/sigmod278-silberstein.pdf ) argue for a selective approach for pushing to users feeds. A similar approach is currently used by [Twitter](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html ). The basic idea is that doing fan-outs for high profile users can cause a high and sudden load on your systems. This means you need a lot of spare capacity on standby to keep things real time (or be ok with waiting for autoscaling to kick in). In their paper they suggest reducing the load caused by these high profile users by selectively disabling fanouts. Twitter has apparently seen great performance improvements by disabling fanout for high profile users and instead loading their tweets during reads (pull). - -### 3.基于消费者的选择性扇出 - -Another possibility of selective fanouts is to only fan-out to your active users. (Say users who logged in during the last week). At Fashiolista we used a modified version of this idea, by storing the last 3600 activities for active users, but only 180 activities for inactive ones. After those 180 items we would fallback to the database. This setup slows down the experience for inactive users returning to your site, but can really reduce your memory usage and costs. - -Silberstein 等。 通过查看消费者和生产者对，使事情变得更有趣。 基本直觉是，在以下情况下，推送方法最有意义： - -Fortunately such a complex solution hasn’t been needed yet for Fashiolista. I’m curious at which scale you need such solutions. Be sure to let us know in the comments. - -### 4.优先事项 - -An alternative strategy is using different priorities for the fan-out tasks. You simply mark fan-outs to active users as high priority and fan-outs to inactive users as low priority. At Fashiolista we keep a higher buffer of capacity for the high priority cluster allowing us to cope with spikes. For the low priority cluster we rely on autoscaling and spot instances. In practice this means that less active user’s feeds may occasionally lag a few minutes behind. Using priorities reduces the impact high profile users have on system load. It doesn’t solve the problem, but greatly reduces the magnitude of the spikes. - -### 5\. Redis vs 卡桑德拉 - -Both Fashiolista and [Instagram](http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings) started out with Redis but eventually switched to Cassandra. I would recommend starting with Redis as it’s just so much easier to setup and maintain. - -但是，Redis 有一些限制。 您的所有数据都需要存储在 RAM 中，这最终会变得昂贵。 此外，Redis 中不支持分片。 这意味着您必须滚动自己的系统才能在节点之间进行分片。 （ [Twemproxy](https://github.com/twitter/twemproxy) 是一个很好的选择）。 在节点之间进行分片非常容易，但是在添加或删除节点时移动数据很麻烦。 您可以通过使用 Redis 作为缓存并回退到数据库来解决这些限制。 一旦难以回退到数据库，我会考虑从 Redis 迁移到 Cassandra。 - -Cassandra Python 生态系统仍在快速变化。 [CQLEngine](https://github.com/cqlengine/cqlengine) 和 [Python-Driver](https://github.com/datastax/python-driver) 都是出色的项目，但是它们需要一些[分叉](https://github.com/tbarbugli/cqlengine)才能一起工作。 如果您选择 Cassandra，则需要准备好花一些时间来了解 Cassandra 并为客户库做贡献。 - -## 结论 - -There are many factors to take into account when building your own feed solution. Which storage backend do you choose, how do you handle spikes in load caused by high profile users and to what extend do you denormalize your data? I hope this blogpost has provided you with some inspiration. - -[Feedly](https://github.com/tschellenbach/Feedly) 不会为您做出任何选择。 这是一个构建供稿系统的框架，由您自己决定哪种方法最适合您的用例。 有关 Feedly 的介绍，请阅读[自述文件](https://github.com/tschellenbach/Feedly)或本教程，以构建 [Pinterest](http://www.mellowmorning.com/2013/10/18/scalable-pinterest-tutorial-feedly-redis/) [样式](http://www.mellowmorning.com/2013/10/18/scalable-pinterest-tutorial-feedly-redis/) [应用程序](http://www.mellowmorning.com/2013/10/18/scalable-pinterest-tutorial-feedly-redis/)。 如果您尝试一下，请务必在遇到问题时通知我们。 - -请注意，只有在数据库中获得数百万个活动后，才需要解决此问题。 在 Fashiolista，简单的数据库解决方案使我们接触到了最初的 1 亿爱人和 100 万用户。 - -要了解有关 Feed 设计的更多信息，我强烈建议您阅读我们基于 Feedly 的一些文章： - - * [Yahoo Research Paper](http://research.yahoo.com/files/sigmod278-silberstein.pdf) -* [Twitter 2013](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) 基于 Redis，具有后备功能 -* [Instagram 上的 Cassandra](http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings) -* [Etsy Feed 缩放比例](http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture/) -* [Facebook 历史记录](http://www.infoq.com/presentations/Facebook-Software-Stack) -* [Django 项目，具有良好的命名约定。](http://justquick.github.com/django-activity-stream/) （但仅限数据库） -* [http://activitystrea.ms/specs/atom/1.0/](http://activitystrea.ms/specs/atom/1.0/) （演员，动词​​，宾语，目标） -* [有关最佳做法的 Quora 帖子](http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed?q=news+feeds) -* [Quora 扩展了社交网络供稿](http://www.quora.com/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed) -* [Redis 红宝石示例](http://web.archive.org/web/20130525202810/http://blog.waxman.me/how-to-build-a-fast-news-feed-in-redis) -* [FriendFeed 方法](http://backchannel.org/blog/friendfeed-schemaless-mysql) -* [Thoonk 设置](http://blog.thoonk.com/) -* [Twitter 的方法](http://www.slideshare.net/nkallen/q-con-3770885) - -很棒的文章！ 我经常想知道为什么要对大规模流立即做出扇出的决定。 [Collabinate](http://www.collabinate.com "Collabinate") 活动供稿 API 使用了 Rene Pickhardt 令人惊叹的 [Graphity 算法](http://www.rene-pickhardt.de/graphity-an-efficient-graph-model-for-retrieving-the-top-k-news-feeds-for-users-in-social-networks "Graphity")，这是一种图形数据库支持的 Feed 算法，具有极高的吞吐量，且无需重复。 它依靠图数据库通过 n 路合并（“拉”）完成所有操作。 我想谈谈您在原始实现中看到的延迟峰值，Redis 遇到的内存利用率问题以及现在的情况。 它将真正帮助我们的未来客户过渡到 Collabinate。 我会大声疾呼，以谈论有关 Feedly 的更多信息。 - -是否考虑使用 Postgresql 复制？ -一个写 DB 和多个从数据库为只读。 - -Feedly 开源软件包一直在快速增长。 目前，我们正在对 Feedly 背后的团队构建的托管解决方案进行 Beta 测试。 您可以在 https://getstream.io 上找到它 - -我一直想学习如何做到这一点！ 你是最好的！ 感谢您提供这个值得推荐的帖子。 \ No newline at end of file +因此，他们建立了一个 Gmail 客户端，并且没有猜测到该死的事情，队列只是一些非常明智的营销。 虽然所有尊重。 他们引起了轰动，很快就成功兑现了。 \ No newline at end of file diff --git a/docs/122.md b/docs/122.md index ec28597..9ce0e22 100644 --- a/docs/122.md +++ b/docs/122.md @@ -1,200 +1,72 @@ -# Salesforce Architecture-他们每天如何处理 13 亿笔交易 +# 在 Yelp 上利用云计算-每月访问量为 1.02 亿，评论量为 3900 万 -> 原文： [http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html](http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html) +> 原文： [http://highscalability.com/blog/2013/6/26/leveraging-cloud-computing-at-yelp-102-million-monthly-visto.html](http://highscalability.com/blog/2013/6/26/leveraging-cloud-computing-at-yelp-102-million-monthly-visto.html) -![](img/cd1c1c540f70b4a63925781e16857370.png) +![](img/f8bad06a01e3b7dcfc5004dec36459bf.png) -*这是由 [salesforce.com](http://www.linkedin.com/profile/view?id=3158913) 的首席站点可靠性工程师 [Claude Johnson](http://www.linkedin.com/profile/view?id=3158913) 撰写的来宾帖子。* +*这是 Yelp 的， [Jim Blomo](https://twitter.com/jimblomo) 的来宾帖子。 Jim 管理着一个不断发展的数据挖掘团队，该团队使用 Hadoop ， mrjob 和奇数作业处理 TB 数据。 在 Yelp 之前，他为初创公司和亚马逊建立了基础架构。* *在即将举行的 [OSCON 2013 上发表演讲，内容涉及在 Yelp](http://www.oscon.com/oscon2013/public/schedule/detail/29387) 建立云文化。* -以下是 salesforce.com 的核心平台和应用程序的体系结构概述。 其他材料（例如，Heroku 的 Dyno 架构）或其他产品的子系统（例如，work.com 和 do.com）不在本材料中，尽管 database.com 不在其中。 想法是与技术社区分享有关 salesforce.com 如何执行工作的一些见解。 任何错误或遗漏是我的。 +在 2013 年第一季度，Yelp 的**唯一身份访问者为[1.05 亿]** （来源：Google Analytics（分析）），其中每月平均有大约 1000 万使用 Yelp 应用程序的独特移动设备。 Yelpers 甚至 ve 撰写的内容超过 **3,900 万篇丰富的本地评论**，这使 Yelp 成为了从精品店，技工到餐厅和牙医等各个领域的领先本地指南 。 关于数据，关于 Yelp 的最独特的事情之一就是数据的多样性：评论，用户个人资料，业务描述，菜单，签到，食物照片……清单还在继续。 我们有很多处理数据的方法，但是今天我将重点介绍如何处理离线数据处理和分析。 -这绝不是全面的，但是如果有兴趣，作者将很乐意解决 salesforce.com 运作的其他领域。 Salesforce.com 希望与以前未与之互动的技术社区更加开放。 这是关于“如何打开和服”的开始。 +在 2009 年底，Yelp 使用亚马逊的 Elastic MapReduce （ EMR ）作为备用计算机构建的内部集群的替代和进行了调查。 到 2010 年中，我们已经将生产处理完全转移到 EMR ，并关闭了 Hadoop 集群。 今天，我们从集成测试到广告指标，每天要处理 **500 个工作** 。 ve 在此过程中吸取了一些教训，希望对您有所帮助，因为我们 ll 。 -自 1999 年以来，salesforce.com 一直专注于构建通过 Internet 交付的业务技术，以取代传统的企业软件。 我们的客户通过按月订阅付费，以通过网络浏览器随时随地访问我们的服务。 我们希望这种对 salesforce.com 核心体系结构的探索将是对该社区做出的许多贡献的第一步。 +## 工作流池 -## 定义 +EMR 的最大优势之一是即时可伸缩性：每个作业流可以配置有任务所需的多个实例。 但是可伸缩性并不是免费的。 主要缺点是 1）分解群集可能需要 5 至 20 分钟，2）每小时需要支付**或不足一小时**的费用。 这意味着，如果您的工作在 2 小时 10 分钟内完成，则将向您收取整整三个小时的费用。 -让我们从一些基本的 salesforce.com 术语开始： +![](img/9edb1d9f3836bf33e890aa110760b6b4.png) -* **实例**-共享和非共享的完整的系统，网络和存储基础结构集，可为部分客户提供 salesforce.com 服务。 例如，na14.salesforce.com 是一个实例。 -* **Superpod** -一组系统，网络和存储基础结构，包括出站代理服务器，负载平衡器，邮件服务器，SAN 结构和支持多个实例的其他基础结构。 Superpods 在数据中心内提供服务隔离，因此共享或复杂组件的问题不会影响该数据中心中的每个实例。 -* **机构**（又称组织）-Salesforce 应用程序的单个客户。 从 www.salesforce.com 或 developer.force.com 开始的每次试用都会产生一个新的组织。 组织是高度可定制的，并且可以具有不同的安全设置，记录可见性和共享设置，UI 外观，工作流，触发器，自定义对象，标准 salesforce.com CRM 对象上的自定义字段，甚至是自定义 REST API。 组织可以支持从一百万到数百万个许可的个人用户帐户，门户网站用户帐户和 Force.com 网站用户帐户。 -* **沙箱**-salesforce.com 服务的一个实例，该实例托管用于客户应用程序开发目的的生产组织的完整副本。 使用我们平台的客户可以拥有完整的应用程序开发生命周期。 这些是供客户在将更改部署到其生产组织中之前对其应用程序进行用户验收测试的测试环境。 +在您开始运行数百个作业并且作业流程结束时所浪费的时间开始累积之前，这似乎并不重要。 为了减少浪费的计费时间， mrjob 实现了“作业流池”。 mrjob 而不是在工作结束时关闭工作流，以防其他工作想要使用它，而保持工作流 ve 的状态。 如果随之而来的另一个作业具有相似的群集要求，则 mrjob wi ll 将重用作业流程。 -## 统计信息（截至 2013 年 8 月） +![](img/06ca7b6e6bb2098fceb4d0e2637dce6a.png) -* 17 个北美实例，4 个 EMEA 实例和 2 个 APAC 实例 -* 20 个沙箱实例 -* 1,300,000,000 笔以上的每日交易 -* 高峰时每秒 24,000 个数据库事务（相当于其他站点上的页面浏览） -* 15,000 多个硬件系统 -* > 22 PB 的原始 SAN 存储容量 -* > 5K SAN 端口 +实施此操作有一些微妙之处：1）具有“相似的集群要求”是什么意思，2）如何避免多个作业之间的竞争状况，以及 3）集群何时最终关闭？ -## 使用的软件技术 +定义了满足以下条件的类似工作流程： -* 用于开发和初级生产系统的 Linux -* 带 ZFS 的 Solaris 10 -* 码头 -* 索尔 -* 记忆快取 -* Apache QPID -* 质量体系 -* 剃刀木偶 -* Perl，Python -* 纳吉奥斯 -* Perforce，Git，Subversion +* 相同的 Amazon Machine Image（AMI）版本 +* 相同的 Hadoop 版本 +* 相同的 mrjob 版本 +* 相同的引导步骤（引导步骤可以设置 Hadoop 或群集选项） +* 每种节点类型具有相同或更大的 RAM 和计算单元（例如。 Hadoop 主服务器与工人） +* 接受新作业（作业流程最多可处理 256 个步骤） -## 硬件/软件架构 +通过使用锁定避免了竞争情况。 默认情况下，在支持一致性的区域（美国西部）中使用 S3 **实施锁定。 作业使用有关作业名称和群集类型的信息写入特定的 S3 密钥。 如果发生故障，锁定可能会超时，从而使其他作业或作业终止者可以收回作业流。** -### 登录到 salesforce.com 服务 +作业流终止由 cron 作业处理，该作业每 5 分钟运行一次，检查是否有闲置的作业流即将达到 **每小时的费用，并终止它们** 。 这样可以确保从不共享工作流的最坏情况不会比默认情况下代价高。 -我们维护一个服务器池来处理所有实例的登录流量。 来自许多（但不是全部）实例的少数服务器接受登录请求，并将会话重定向到用户的家庭实例。 当您通过 login.salesforce.com 登录时，会发生这种情况。 +为了进一步提高作业流的利用率，作业可以等待预定时间，以找到可以重用的作业流。 例如，对于开发作业， mrjobs wi ll 尝试在开始新作业之前先寻找 30 秒钟的空闲作业流。 在生产中，没有到严格期限的工作可能会将等待时间设置为几个小时。 -客户流量始于我们的外部 DNS。 查找成功返回实例的 IP 地址后，标准 Internet 路由会将其定向到适当的数据中心。 +我们估计通过使用工作流池 可以节省大约 **10％的成本。 从开发人员的角度来看到，这种节省成本几乎是免费的：通过设置一些配置设置，这些更改无需开发人员的任何操作即可生效。 实际上，我们看到了一个附带好处：迭代 ve 作业的开发速度大大加快，因为修改后的 MapReduce 作业的后续运行可以重用集群，并且消除了集群启动时间。** -一旦流量进入该数据中心中的网络，它将被定向到该 IP 所在的负载平衡器对。 我们所有面向 Internet 的 IP 都是在一对主用/备用负载均衡器上配置的 VIP。 +## 预留实例 -### 在实例内部 +默认情况下， AWS 每机器小时收费，但它提供了其他一些可以降低成本的购买选项。 [预留实例](http://aws.amazon.com/ec2/reserved-instances/) 是更直接的选择之一：先付钱，再收取每小时较低的每小时费用。 在将 AWS 价格与购买服务器进行比较时，我鼓励人们研究此选项：与购买服务器的资本成本和承诺相比，这是一个更为公平的比较。 -负载平衡器将流量定向到给定实例的应用程序层。 在这一层，我们既提供标准网页流量，也提供我们的 API 流量。 API 流量占我们应用程序层总体服务的流量的 60％以上。 根据客户请求的需求，它将被定向到用于各种类型的后端处理的其他服务器层。 +![](img/c0f7f8cc00a9bc77a6026caa87b28c44.png) -### 核心应用 +什么时候比保留实例便宜一些 ll ？ 这取决于实例在一年中使用多少小时。 ve 上的图显示了使用不同的 reser ve 实例定价选项运行大型标准实例的成本：轻，中或重度使用。 您可以按需支付价格，即$ 0.26 /小时，但在大约 3000 小时（4 个月）后，支付$ 243 的 Reser ve 价格会变得更加便宜，仅需为预留的临时使用量支付$ 0.17 / hour 实例。 每年使用 3000 多个小时？ 然后是时候研究增加的使用计划了，“重载”是最大的前期，但每小时计划最低。 -核心应用程序层包含十到 40 个应用程序服务器，具体取决于实例。 每个服务器运行一个配置有多达 14 GiB 堆的 Hotspot JVM，具体取决于服务器硬件配置。 +您的公司应购买多少个预留实例？ 这取决于您的用法。 与其试图预测我们将要使用的 **wi ll** 多少，我们而是编写了一个工具来分析**过去的**使用情况并建议购买计划 **会 ve** 为我们节省最多的钱。 假设我们的未来使用率 ll 看起来与我们过去的使用情况相似，并且额外的工作和预测风险不值得相对多的支出。 ve 。 该工具的名称为 ll [EMRio](https://github.com/Yelp/EMRio) ，我们去年开放了来源。 它分析 EMR 的用法，并建议购买多少个预留实例，因为我们 ll 会生成一些漂亮的图形。 -批处理服务器负责在数据库层上运行计划的自动化过程。 例如，每周导出过程，该过程用于以单一存档文件格式导出客户数据作为备份形式。 +![](img/0ab080d5917c053ed97f8311b519beb9.png) -Salesforce.com 提供许多服务，包括基本和高级内容管理。 我们有一个内容搜索服务器和一个内容批处理服务器，用于管理内容应用程序层上的异步过程。 内容批处理服务器计划内容类型的处理，包括诸如某些文件类型的渲染预览和文件类型转换之类的功能。 +请务必注意，预留实例定价是一种计费方式。 也就是说，您并不是在物理上预订机器。 在月底，Amazon 仅查看您使用了多少实例小时，并将保留的实例费率应用于正在运行的任何实例，直到购买的实例数量为止。 -### 数据库 +## 得到教训 -主要数据流发生在核心应用服务器层和数据库层之间。 从软件的角度来看，所有内容都通过数据库，因此数据库性能至关重要。 每个主要实例（例如 NA，AP 或 EU 实例）都使用 8 节点集群数据库层。 客户沙箱（例如 CS 实例）具有 4 节点集群数据库层。 +**了解迁移到云解决方案** 时的权衡。 对于 Yelp，使用 AWS 的主要好处是通过降低协调成本和功能延迟来提高开发人员的生产力。 协调成本来自要求产品团队预测和请求系统团队的资源。 购买资源（无论是服务器机架还是网络容量）可能要花费数周的时间，并增加了功能启动的延迟。 延迟有其自身的相关成本，这些成本降低了道德水平（伟大的开发商（HTG5）至运输产品）以及项目之间的上下文切换。 AWS 的美元成本可能高于完全利用的，定制的内部解决方案的成本，但是您的想法是 ve 购买了更多的生产力。 -由于 salesforce.com 是一个非常受数据库驱动的系统，因此减少数据库负载至关重要。 为了减少数据库层的负载，我们开发了 ACS-API Cursor Server。 这是对两个问题的解决方案，使我们能够显着提高核心数据库性能。 首先，我们曾经将游标存储在数据库中，但是删除操作会影响性能。 其次，在使用数据库表保存游标之后，DDL 开销变成了负面影响。 因此诞生了 ACS。 ACS 是在一对服务器上运行的游标缓存，提供了一种从数据库层卸载游标处理的方法。 +**专注于大赢家** ：可以逐步采用云技术-我们正在这样做！ Yelp 从 EMR 开始，因为这是我们最大的胜利。 离线处理具有尖峰的负载特性，通常不需要团队之间的协调，并且通过为开发人员提供实验的杠杆作用，可以使开发人员获得更高的生产率和。 为了更好地使用云，请集中精力一次解决最严重的瓶颈。 -### 搜索 +**建立在抽象** 之上：不要在 ll 上让所有人都了解云服务的细节，就像您不要在[数据中心。 记住您的权衡：目标是使开发人员的工作效率更高，而不是与流行语兼容。 如果开发人员不能像本地脚本那样轻松地使用它，那么拥有可扩展的，适应性强的或基础架构并不重要。 我们最喜欢的抽象是 [mrjob](https://github.com/Yelp/mrjob) ，它使我们可以在 Python 中编写和运行 MapReduce 作业。 在与 EMR 群集的本地计算机上运行作业是更改两个命令行参数的问题。 -我们的搜索层运行在商用 Linux 主机上，每台主机上都配备了 640 GiB PCI-E 闪存驱动器，该驱动器充当搜索请求的缓存层。 这些主机通过 NFS 文件系统从共享的 SAN 阵列中获取数据。 搜索索引存储在闪存驱动器上，以提高搜索吞吐量的性能。 +**建立策略和集成计划** ：旋转单个实例很容易，但是什么时候旋转机器？ 每天处理的日志很简单，但是如何可靠地将日志传输到 S3？ 已对 ll 的支持工程计划，使系统正常工作：数据集成，测试，备份，监视和警报。 Yelp 围绕 PII 制定了政策，将生产环境与开发区分开来，并使用 mrjob 软件包中的工具来监视失控的集群。 -搜索索引当前在转换服务器上进行，转换服务器通过光纤通道 SAN 从存储阵列安装 LUN。 这些 LUN 组成一个 QFS 文件系统，该文件系统允许单写程序但多读程序访问。 像大多数其他关键系统一样，我们以主动/被动方式运行它们，而被动节点则执行一些低优先级的搜索索引工作。 然后将其结果发送给活动伙伴以写入 QFS 文件系统。 +**稳定后优化** 。 有许多削减成本的方法，但是大多数方法都需要一定的复杂性和未来的灵活性。 在执行之前，请确保已使用了有效的抽象解决方案，以便评估的投资回报率。 Yelp 写了 EMRio 的数据，这是我们有 EMR 与 mrjob 结合使用的几个月的数据。 在看到我们实际使用 EMR 之前先进行优化，可能会甚至在黑暗中拍摄。 -当这些相同的 LUN 从一组在 SPARC 上运行 Solaris 10 的四个 NFS 服务器以只读方式装入时，就会发生转换。 然后，这些通过 SAN 安装的文件系统通过 NFS 共享到先前描述的搜索层。 - -### Fileforce - -我们维护一层提供对象存储的服务器，其概念与亚马逊的 S3 或 OpenStacks 的 Swift 项目相似。 Fileforce 这个系统是内部开发的，目的是减少数据库层的负载。 在引入 Fileforce 之前，所有二进制大对象（BLOB）都直接存储在数据库中。 Fileforce 联机后，所有大于 32 KiB 的 BLOB 都已迁移到其中。 小于 32 KiB 的 BLOB 继续存在于数据库中。 Fileforce 中的所有 BLOB 在数据库中都有一个引用，因此为了从备份中还原 Fileforce 数据，我们必须基于来自同一还原点的数据库备份来启动数据库实例。 - -Fileforce 包括捆绑程序功能，旨在减少 Fileforce 服务器上的磁盘查找负载。 如果数据库中存储了 100 个以上小于 32 KB 的对象，则将在应用服务器上运行一个进程，以将这些对象捆绑到一个文件中。 对捆绑文件的引用与捆绑中的查找偏移量一起保留在数据库中。 这类似于 Facebook 的 Haystack 图像存储系统，但内置于对象存储系统中。 - -### 支持 - -每个实例包含其他各种支持角色的服务器，例如调试应用程序服务器和应用程序层中的“ Hammer 测试”应用程序服务器，监视每个实例运行状况的中心服务器以及监视运行 Nagios 的服务器。 实例本身之外还包含支持服务器，例如存储管理，数据库管理，日志聚合，生产访问身份验证和其他功能。 +**评估 ROI** ：通过一些优化，成本评估非常简单：如果两个月前我们都保留实例，我们将节省多少？ 有些更困难：开发过程中的瓶颈是什么？云解决方案能否消除它们？ 容易或困难，但是在执行之前对其进行评估很重要。 优化之前的配置文件代码我想你是说什么？ 如果不是的话，我不希望您使用此分析器:) ## 未来发展方向 -在数据库层，我们正在仔细检查数据存储系统的几种选项。 我们还在评估更高速度，更低延迟的互连，例如与现有数据库解决方案的集群互连的 Infiniband。 - -将来，我们希望使搜索主机能够进行所有读写操作。 我们正在为搜索索引推出 Apache Solr。 Solr 在我们现有的搜索主机上本地运行。 SAN，NFS 服务器和基于 SPARC 的索引器主机将全部消失，这将大大降低整个搜索层的复杂性。 - -我们的应用程序容器以前是 Resin，但在过去的一年中，我们一直在迁移到 Jetty。 我们还在对应用层硬件进行硬件更新，这将使 RAM 大小增加 30％-266％，并将 Sandy Bridge 处理器引入我们的堆栈。 - -我希望对 salesforce.com 技术架构和堆栈的概述能使您有趣且有益。 如果您对其他访客帖子感兴趣，请深入评论我们广泛的技术基础架构的其他部分。 谢谢阅读！ - -## 相关文章 - -* [Force.com 多租户架构的内部设计](http://www.infoq.com/presentations/SalesForce-Multi-Tenant-Architecture-Craig-Weissman) -* [Salesforce.com 架构](http://www.scribd.com/doc/145879736/Salesforce-com-Architecture) -* [单元架构](http://highscalability.com/blog/2012/5/9/cell-architectures.html) - -克劳德 - -感谢您抽出宝贵时间发布此信息。 我想对您如何使用 Solaris 和 ZFS 的更多信息非常感兴趣。 另外，如果必须全部这样做，是否会再次使用 QFS？ - -谢谢！ - -你们正在使用什么数据库？ - -此外，您提到了 Resin 和 Jetty，但在语言列表中没有提及 Java。 如果使用 Java，则正在使用 Java EE 的哪些部分？ - -他们没有提到它，但我可以想象它是神谕！ - -@MiddleAgedGeek - -他们使用 Oracle 或曾经使用 Oracle：http://www.dbms2.com/2012/06/26/is-salesforce-com-going-to-stick-with-oracle/ - -?？ 每秒有 24,000 个数据库事务（24k TPS）由多少台数据库机处理？ 还是每个数据库服务器处理多少 TPS？ -另外，我们是否在这里谈论纯 OLTP，OLAP 和混合液？ - -韦斯 - -FIleforce 在 Solaris 10 上运行，并且 Fileforce 数据存储在从镜像 VDEV 创建的 ZFS 池中。 （镜像 VDEV 的数量取决于服务器的型号。） - -我开始之前就选择了 QFS。 由于 salesforce.com 是 Sun 商店，并且搜索索引是在具有 SAN 存储的 SPARC 服务器上运行的，因此 QFS 是操作人员轻松实现高吞吐量，可靠的搜索索引文件系统的方式。 NFS 将其安装到搜索层的唯一原因是字节顺序问题。 如前所述，我们正在转向一种更易于推理，故障排除和支持的体系结构。 - -MiddleAgedGeek 和 ymo， - -请参阅 http://www.salesforce.com/company/news-press/press-releases/2013/06/130625.jsp，但我们确实使用 Oracle 数据库。 我们确实将其他数据存储用于不同的应用程序，但是上述核心数据库是 Oracle。 - -至于 Java，我们将 Jetty 用作容器，但是我们并未使用大多数核心 Java EE 功能。 Java 是我们内部构建的核心应用服务器的选择语言。 - -普热梅克 - -24000 个事务/秒是我们所有实例中高峰事务速率的平均值。 工作量主要是 OLTP，但是由于客户使用我们服务的方式，肯定有 OLAP 组件。 - -Claude, - -很棒的文章，感谢您在幕后进行的深入探寻，我期待更深入的潜水。 社区绝对可以从 SF 经验中学习。 - -1.3B 事务...是否还可以将其定义为单个客户端请求（网页浏览，ajax 请求）以及服务器的相应响应？ - -以后的文章建议对实例进行检测和监视。 数据量，脱机处理，什么类型的数据（http 日志，代码跟踪语句，度量标准等）。 - -嗨，克劳德， -感谢您分享此信息。 它真的很有帮助:-) - -彼得 - -是的，交易是对实例的应用层的请求/响应。 - -我也一定会通过这个建议。 我希望我的团队和其他人能看到更多类似的帖子。 我很高兴得到如此积极的回应。 谢谢你们！ - -惊人的帖子比我以前看到的要详细得多。 谢谢！ - -您今年要参加 Dreamforce 吗？ - -我使用该平台已有几年了，我一直想知道它是如何在后台运行的。 处理的数据量以及所有响应的响应速度简直太疯狂了。 - -很棒的帖子！ 感谢分享！ - -惊人的帖子， - -在注释部分提到的是 Oracle DB。 我猜一个实例中的群集。 您如何处理 HA 和 DR？ -例如，如何将 Appexchange 部署添加到不同的位置，例如在同一地点？ -是否存在共享实例，还是仅在所有实例中都复制了？ - -感谢您的评论。 - -有趣的文章-感谢分享。 您如何监视系统-性能和中断。 除了 Nagios 之外，您还使用其他监视工具吗？ Splunk，仙人掌等？ - -感谢您分享知识。 - -有许多服务器可为来自不同大陆的客户提供应用程序层服务。 - -您是否为每个新的注册客户端创建单独的数据库？ 或每个服务器的数据库有一定限制。 在数据库层部分找不到太多有关如何进行负载平衡的信息？ - -引人入胜的文章，并保持他们的到来。 我经常推测出幕后的魔力，这绝对是一本好书。 我希望类似的帖子将继续围绕这样的主题-它们不仅通过透明性建立信任-它们还有助于增进我们的集体工程知识。 谢谢！ - -嗨 -非常有启发性的文章！ -我想深入了解 Force.com 网站如何与整个事情联系在一起。 它托管在 DMZ 区域中吗？ -谢谢！ - -是否考虑过像事务服务器集群这样的单独层来减少会话负载？ 当然，我假设在数据库层而不是在应用程序服务器层运行存储过程。 - -您可以在以下位置找到 Salesforce.com 架构幻灯片：http://www.slideshare.net/gueste35dd2/salesforcecom-corporate-presentation-july-2009?next_slideshow=1-上面的划线链接要求我注册&，但要付费 。 - -很棒的架构概述！ 要求：这是 2 岁。 请分享过去两年中的体系结构和基础架构升级。 谢谢 ！ - -现在的堆栈是什么样的？ 它是如何成长的？ 什么是新的，什么掉了？ 软件堆栈必须已大修几次。 -从接收的客户数量来看，SFDC 的技术足迹必须每年增长 10-20％？ \ No newline at end of file +随着 Yelp 面向服务架构的发展，我们在脱机批处理中遇到了类似的瓶颈：资源协调，测试思路，在启动新功能之前预测使用情况。 因此，我们再次将目光投向了云，以为广告选择，搜索和数据提取等服务带来巨大的成功。 [期待 Yelp 工程博客上有关](http://engineeringblog.yelp.com/) [Asgard](http://netflix.github.io/asgard/) 未来的帖子用于构建和部署服务，评估 Python 框架 服务器到 RESTful API ，并构建抽象使其易于使用 ll 。 当然，如果您想帮助建立这个未来，请 [告诉我们！](http://www.yelp.com/careers) \ No newline at end of file diff --git a/docs/123.md b/docs/123.md index 9145ebb..181f143 100644 --- a/docs/123.md +++ b/docs/123.md @@ -1,231 +1,49 @@ -# Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户，300K QPS，22 MB / S Firehose 以及发送推文 - -> 原文： [http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) - -[![](img/175760828c3825c5257e29ae94d31d40.png)](http://www.flickr.com/photos/13733851@N00/9235686327/sizes/o/in/photostream/) - -解决 Twitter“问题”的玩具解决方案是最受欢迎的可伸缩性。 每个人都认为 Twitter 很容易。 挥舞着一点建筑手，我们就拥有了一个可扩展的 Twitter，就这么简单。 好吧，这不是那么简单，就像 Twitter 的工程副总裁 [Raffi Krikorian](https://twitter.com/raffi) 在他对 [时间轴的出色且详尽的介绍中所描述的那样 规模](http://www.infoq.com/presentations/Twitter-Timeline-Scalability) 。 如果您想了解 Twitter 的工作原理，请从这里开始。 - -它是逐渐发生的，所以您可能会错过它，但是 Twitter 已经成长。 它最初是一个苦苦挣扎的 [三层 Ruby on Rails](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster) 网站，现在已经成为一个精美的服务驱动核心，我们现在实际去看看其他服务是否已关闭。 很大的变化。 - -Twitter 现在拥有 1.5 亿全球活跃用户，处理 300K QPS 来生成时间线，以及每秒输出 22 MB 速度的流水线。 每天有 4 亿条推文通过该系统，从 Lady Gaga 的手指到 3100 万追随者的推文最多可能需要 5 分钟。 - -有几点值得注意： - -* Twitter 不再希望成为网络应用程序。 Twitter 希望成为为全球移动客户端提供动力的一组 API，充当地球上最大的实时事件总线之一。 -* Twitter 主要是一种消费机制，而不是生产机制。 300K QPS 用于读取时间轴，而每秒仅 6000 个请求用于写入。 -* 具有大量关注者名单的离群值正在成为一种常见情况。 从具有大量关注者的用户发送推文（即扇出大）可能会很慢。 Twitter 尝试在 5 秒内做到这一点，但它并不总是有效，特别是当名人互相推 t 时，这种情况越来越多。 结果之一是，回复可能会在收到原始推文之前到达。 Twitter 正在从对写入的所有工作转变为对高价值用户进行更多的读取工作。 -* 您的家庭时间轴位于 Redis 集群中，最多包含 800 个条目。 -* Twitter 从您关注的人以及单击的链接上对您了解很多。 当双向遵循不存在时，隐式社会契约可以暗示很多。 -* 用户关心推文，但是推文的文本与 Twitter 的大多数基础结构几乎无关。 -* 它需要一个非常复杂的监视和调试系统来跟踪复杂堆栈中的性能问题。 过去遗留决策的幽灵总是困扰着系统。 - -Twitter 如何运作？ 阅读 Raffi 精彩演讲的内容，并发现... - -## 挑战 - -* 1.5 亿用户的时间轴（首页和搜索）的 300K QPS 可能会很慢。 -* 幼稚的物化是整个 Twitter 上大量的精选声明。 它被审判并死亡。 -* 解决方案是基于写的扇出方法。 推文到达时要进行大量处理，以找出推文应该去哪里。 这样可以快速轻松地读取时间。 不要对读取进行任何计算。 在写路径上执行所有工作后，摄取速率比读路径慢，约为 4000 QPS。 - -## 团体 - -* 平台服务小组负责 Twitter 的核心可扩展基础架构。 - * 他们运行称为“时间轴服务”，“推文服务”，“用户服务”，“社交图谱服务”的东西，这些工具为 Twitter 平台提供了强大的支持。 - * 内部客户端使用与外部客户端大致相同的 API。 - * 已针对第三方 API 注册了超过 1 百万个应用 - * 与产品团队签订合同是他们不必担心规模。 - * 进行容量规划，设计可扩展的后端系统，随着站点以意想不到的方式不断增长而不断替换基础架构。 -* Twitter 有一个架构小组。 有关 Twitter 的整体整体架构。 维护技术债务清单（他们希望摆脱的清单）。 - -## 推我拉我 - -* 人们一直在 Twitter 上创建内容。 Twitter 的工作是弄清楚如何将内容联合起来。 如何将其发送给您的关注者。 -* 真正的挑战是实时约束。 目标是在不超过 5 秒的时间内将消息流传递给用户。 - * 交付意味着收集内容并在 Internet 上施加压力，以使其尽快恢复。 - * 传递到内存中的时间轴群集，推式通知，已触发的电子邮件，所有 iOS 通知以及 Blackberry 和 Android，SMS。 - * Twitter 是按世界上任何活跃用户的最大 SMS 生成器。 - * 选举可能是内容进入和内容散播的最大驱动力之一。 -* 时间线的两种主要类型：用户时间线和主时间线。 - * 用户时间轴是特定用户已发送的所有推文。 - * 主时间轴是您正在关注的人的所有用户时间轴的时间合并。 - * 业务规则被应用。 @您不认识的人的回复被删除。 可以过滤掉来自用户的转发。 - * 在 Twitter 规模上做到这一点具有挑战性。 -* 拉式 - * 目标时间表。 诸如 twitter.com 和 home_timeline API 之类的东西。 发推文是因为您要求查看而发给您的。 基于拉式的传递：您正在通过 REST API 调用从 Twitter 请求此数据。 - * 查询时间轴。 搜索 API。 针对语料库的查询。 尽快返回与特定查询匹配的所有推文。 -* 基于推送 - * Twitter 运行着最大的实时事件系统之一，通过 Firehose 以 22 MB /秒的速度推送推文。 - * 打开一个 Twitter 套接字，他们将在 150 毫秒内将所有公开推文推送给您。 - * 在任何给定时间，推集群都可以打开约一百万个套接字。 - * 面向搜索引擎之类的客户。 所有公开推文都来自这些插座。 - * 不，你不能拥有它。 （您无法处理/承担事实。） - * 用户流连接。 Powers TweetDeck 和适用于 Mac 的 Twitter 也经历了这里。 当您登录时，他们会查看您的社交图，仅从您所关注的人那里发送消息，从而重新创建家庭时间轴体验。 通过持久连接，无需轮询即可获得相同的时间轴体验。 - * 查询 API。 发出关于推文的常规查询。 创建推文并找到与查询匹配的推文后，会将它们路由到查询的注册套接字中。 - -## 高水平的基于拉的时间轴 - -* 通过写 API 发出推文。 它通过负载平衡器和 TFE（Twitter 前端）以及其他无法解决的问题。 -* 这是一条非常有方向的道路。 完全预先计算的家庭时间表。 随着推文的出现，所有业务规则都将执行。 -* 立即发生扇出过程。 传入的推文放置在庞大的 Redis 集群中。 每个推文在 3 台不同的计算机上复制 3 次。 在 Twitter 规模上，许多机器每天都会发生故障。 -* 扇出查询基于[群](https://github.com/twitter/flockdb)的社交图服务。 Flock 维护关注者和关注者列表。 - * Flock 返回收件人的社交图，并开始遍历 Redis 集群中存储的所有时间轴。 - * Redis 群集具有几个 TB 的 RAM。 - * 一次流水线式 4k 目的地 - * Redis 内部使用本机列表结构。 - * 假设您发了推文，并且有 2 万名关注者。 扇出守护程序将执行的操作是查找 Redis 集群中所有 20K 用户的位置。 然后，它将开始在整个 Redis 集群的所有这些列表中插入 tweet 的 Tweet ID。 因此，在 Redis 集群中，每条推文写入操作都会产生多达 20K 次插入。 - * 存储的内容是生成的推文的推文 ID，该推文发起人的用户 ID，以及用于标记是转推，回复还是其他内容的 4 个字节的位。 - * 您的家庭时间轴位于 Redis 集群中，长度为 800 个条目。 如果翻页时间足够长，您将达到限制。 RAM 是确定当前 tweet 集可以持续多长时间的限制资源。 - * 每个活动用户都存储在 RAM 中，以降低延迟。 - * 活动用户是指在 30 天内登录 Twitter 的用户，该用户可能会根据缓存容量或 Twitter 的使用情况而变化。 - * 如果您不是活跃用户，则该推文不会进入缓存。 - * 只有您的家庭时间轴命中磁盘。 - * 如果您从 Redis 集群中掉出来，那么您将经历一个称为重建的过程。 - * 针对社交图服务查询。 找出您关注的人。 为它们中的每一个命中磁盘，然后将它们推回 Redis。 - * 它是 MySQL 通过 [Gizzard](https://github.com/twitter/gizzard) 处理磁盘存储的功能，该存储区提取了 SQL 事务并提供了全局复制。 - * 如果一台机器有问题，则通过复制 3 次，则他们不必为每个数据中心重新创建该机器上所有时间线的时间线。 - * 如果推文实际上是转发，则将指针存储到原始推文。 -* 当您查询家庭时间轴时，将查询时间轴服务。 然后，“时间线服务”只需要查找一台带有您自己的家庭时间线的机器。 - * 有效地运行 3 个不同的哈希环，因为您的时间轴位于 3 个不同的位置。 - * 他们找到第一个可以最快到达的人，并尽快返回。 - * 权衡是扇出需要更长的时间，但是读取过程很快。 从冷缓存到浏览器大约 2 秒钟。 对于 API 调用，大约需要 400 毫秒。 -* 由于时间轴仅包含推文 ID，因此它们必须“水合”那些推文，即找到这些推文的文本。 给定一个 ID 数组，他们可以执行一次 multiget 并从 T-bird 并行获取这些推文。 -* Gizmoduck 是用户服务，而 Tweetypie 是推特对象服务。 每个服务都有自己的缓存。 用户缓存是具有整个用户库的内存缓存群集。 Tweetypie 大约有一个月的推文和一半的推文存储在其 Memcache 集群中。 这些暴露给内部客户。 -* 一些读取时间过滤发生在边缘。 例如，在法国过滤掉纳粹的内容，因此在内容被发送出去之前会进行读取。 +# 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips -## 高级搜索 +> 原文： [http://highscalability.com/blog/2013/7/3/5-rockin-tips-for-scaling-php-to-30000-concurrent-users-per.html](http://highscalability.com/blog/2013/7/3/5-rockin-tips-for-scaling-php-to-30000-concurrent-users-per.html) -* 与拉力相反。 所有这些都在读取路径上计算得出，这使写入路径变得简单。 -* 当出现一条推文时，Ingester 会标记化并找出他们想要索引的所有内容，并将其填充到一台 Early Bird 机器中。 Early Bird 是 Lucene 的修改版本。 索引存储在 RAM 中。 -* 在扇出状态中，一条推文可能会存储在 N 个关注您的家庭时间轴中，在 Early Bird 中，一条推文仅存储在一台 Early Bird 计算机中（复制除外）。 -* Blender 创建搜索时间线。 它必须在数据中心内分散聚集。 它会查询每个 Early Bird 碎片，并询问您是否有与此查询匹配的内容？ 如果您要求“纽约时报”，则查询所有分片，然后将结果返回，排序，合并和重新排序。 重新排名是通过社交方式证明的，这意味着要查看转发，收藏和回复的数量。 -* 活动信息是在写入的基础上计算的，其中有一个活动时间表。 当您偏爱和回复推文时，将维持活动时间线，类似于家庭时间线，它是一系列活动的 ID，因此有收藏夹 ID，回复 ID 等。 -* 所有这些都送入搅拌机。 在读取路径上，它会重新计算，合并和排序。 返回您所看到的搜索时间轴。 -* 发现是根据他们对您的了解进行的定制搜索。 他们之所以知道很多，是因为您关注了很多人，单击链接，这些信息将用于发现搜索。 它会根据收集到的有关您的信息进行排名。 +![](img/f566686494a57f3d41c1c50751d6f818.png) -## 搜索和拉是反函数 +[众筹公司 RockThePost.com 的首席技术官 Jonathan Block](http://www.linkedin.com/pub/jonathan-block/57/a70/b02) 为较小的站点编写了一套不错的技巧，以帮助他们了解如何使用 一个小的两人开发团队。 -* 搜索和拉动看起来非常相似，但是它们具有彼此相反的属性。 -* 在主时间轴上： - * 写。 当有一条推文出现时，会有一个 O（n）进程写入 Redis 集群，其中 n 是跟随您的人数。 令 Lady Gaga 和 Barack Obama 感到痛苦的是，他们在整个集群中进行了数以千万计的插入操作。 所有 Redis 群集都在备份磁盘，Flock 群集将用户时间线存储到磁盘，但是通常在 Redis 群集的 RAM 中找到时间线。 - * 读。 通过 API 或网络查找合适的 Redis 机器为 0（1）。 Twitter 经过优化，可以在家庭时间轴上的读取路径上高度可用。 读取路径以 10 毫秒为单位。 Twitter 主要是一种消费机制，而不是生产机制。 每秒读取 300K 请求，写入每秒 6000 RPS。 -* 在搜索时间轴上： - * 写。 当一条推文进入并击中 Ingester 时，仅击中一台 Early Bird 机器。 写入时间路径为 O（1）。 在排队和处理之间的 5 秒钟内，将提取一条推文，以找到要写入的一条“早起的鸟儿”。 - * 读。 当读取进来时，它必须在整个群集中读取 0（n）。 大多数人不使用搜索，因此他们可以有效地存储推文以进行搜索。 但是他们及时付款。 读数约为 100 毫秒。 搜索从不打磁盘。 整个 Lucene 索引都位于 RAM 中，因此散点式聚集读取非常有效，因为它们从未命中磁盘。 -* 推文几乎与大多数基础架构无关。 [T 鸟存储](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html) 整个推文集。 一条推文的大部分内容都在 RAM 中。 如果没有，请打 T-bird 并执行选择查询以再次将它们退回。 文字几乎无关紧要，除了搜索，趋势或正在发生的事情之外。 家庭时间表几乎根本不在乎。 +他们的服务具有典型的小规模结构： -## 未来 +* PHP 的 Zend Framework 2 +* 两个用于 Web 服务器的 m1.medium +* ELB 拆分负载 +* 主/从 MySQL 数据库 +* 围攻进行负载测试 -* 如何使该管道更快，更高效？ -* 扇出动作可能很慢。 尝试在 5 秒内完成操作，但有时不起作用。 非常辛苦，尤其是在名人鸣叫时，这种情况越来越多。 -* Twitter 关注图是不对称关注。 仅在给定时间关注的人上呈现推文。 Twitter 对您了解很多，因为您可能关注 Lance Armstrong，但他没有关注您。 当双向遵循不存在时，隐式社会契约可以暗示很多。 -* 问题在于大型基数图。 @ladygaga 有 3100 万粉丝。 @katyperry 有 2800 万关注者。 @justinbieber 有 2800 万关注者。 @barackobama 有 2300 万关注者。 -* 这些人之一发推文时，要在数据中心中写很多推文。 当他们开始互相交谈时，这尤其具有挑战性，这种情况一直存在。 -* 这些高扇出用户是 Twitter 面临的最大挑战。 在名人的原始推文发布之前，一直都有回复。 他们介绍了整个站点的比赛条件。 如果从 Lady Gaga 发推文到宣告发散花几分钟的时间，那么人们会在不同的时间点看到她的推文。 最近关注 Lady Gaga 的人可能比过去关注她的人早 5 分钟看到她的推文。 假设某人在早期接收列表中进行了回复，然后在仍在进行扇出操作的同时对该回复的扇出进行了处理，因此该回复会在接收到其推文的人的原始推文之前注入。 引起很多用户混乱。 由于推文主要是单调增加的，因此在发布前按 ID 对其进行排序，但这并不能解决该范围的问题。 高价值扇出始终排队备份。 -* 试图弄清楚如何合并读写路径。 不再分散高价值用户。 对于像泰勒·斯威夫特（Taylor Swift）这样的人，不再烦恼扇出，而在阅读时将其合并到时间表中。 平衡读写路径。 节省百分之十的计算资源。 +每个 Web 服务器可以处理 30,000 个并发用户的非常明智的技巧： -## 去耦 +* **使用 PHP 的 APC 功能**。 APC 是操作码缓存，“ 确实是一个要求，以便网站有机会表现良好。” +* **将不是.php 请求的所有内容放在 CDN** 上。 不要从您的 Web 服务器提供静态文件。 他们将所有内容放到 S3 上，并使用 CloudFront 作为 CDN。 最近的 CloudFront 问题导致它们直接从 S3 服务。 +* **不要使用 PHP 代码**与其他服务器建立连接。 与其他服务器建立连接会阻塞服务器并减慢处理速度。 使用 APC 键/值存储区进行数据存储，使用 Varnish 缓存整页。 +* **使用清漆**。 在负载测试下，使用清漆法师对其性能的最大不同。 +* **使用 c1.xlarge** 。 c1.xlarge 具有 8 个 CPU，在负载下确实有帮助。 m1.medium 只有 1 个 CPU 用于处理请求。 -* 推文以许多不同的方式分叉，主要是使团队彼此分离。 搜索，推送，关注电子邮件和家庭时间轴团队可以彼此独立工作。 -* 由于性能原因，系统已被解耦。 Twitter 以前是完全同步的。 由于性能原因，这种情况在 2 年前就停止了。 将推文吸收到推文 API 中最多需要 145 毫秒，然后所有客户端都将断开连接。 这是出于遗留原因。 Ruby 通过 MRI（单线程服务器）为写入路径提供动力，每次分配 Unicorn 工作者时，处理能力就被消耗 eat 尽。 他们希望能够尽快释放客户端连接。 出现一条推文。Ruby 将其吸收。 将其放入队列并断开连接。 他们每个盒子只运行大约 45-48 个进程，因此每个盒子只能同时摄取那么多推文，因此他们希望尽快断开连接。 -* 这些推文将传递到异步途径，我们一直在讨论的所有内容都将在其中传递。 +非常简单，但很好的建议。 [的原始文章](https://coderwall.com/p/__z9ia)具有更多详细信息，非常值得阅读。 -## 监控方式 +有趣。 去表明我们落后了多远。 我们当前的应用程序大约有 6 个 c1.xlarge 和 10 个 fm.medium 服务器。 它运行缓慢，大约有 100 个用户。 将阅读全文。 -* 办公室周围的仪表板显示了系统在任何给定时间的运行情况。 -* 如果您有 100 万关注者，则需要花费几秒钟来散布所有推文。 -* 推文输入统计：每天 4 亿条推文； 日均 5K /秒； 每日峰值 7K /秒； >在大型活动中为 12K / sec。 -* 时间轴交付统计：每天 30b 次交付（〜21m / min）； 3.5 秒@ p50（第 50 个百分位数），传送到 1m； 30 万次/秒； @ p99，最多可能需要 5 分钟 -* 名为 VIZ 的系统监视每个群集。 向时间线服务请求以从 Scala 群集中获取数据的平均时间为 5 毫秒。 @ p99 是 100 毫秒。 @ p99.9 是它们命中磁盘的位置，因此需要花费几百毫秒的时间。 -* [Zipkin](https://twitter.com/zipkinproject) 基于 Google 的 Dapper 系统。 有了它，他们可以对请求进行污染并查看其命中的每个服务以及请求时间，因此他们可以对每个请求的性能有非常详细的了解。 然后，您可以深入查看并查看每个单个请求，并了解所有不同的时间。 通过查看在请求上花费的时间来花费大量时间来调试系统。 他们还可以按阶段显示汇总统计信息，以查看扇出或交付所需的时间。 这是一个为期 2 年的项目，目的是使活动用户的时间线降低到 2 毫秒。 花了很多时间来解决 GC 暂停问题，解决内存缓存查找问题，了解数据中心的拓扑结构以及为这种成功设置集群。 +但这只是外部站点。 原始文章指出，一旦用户登录到“内部”网站，每个服务器只能处理 1,000 个？ 那不是很多。 -## 相关文章 +耶勒特， -* [为什么 Facebook，Digg 和 Twitter 很难扩展？](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) -* [在 Reddit 上](http://www.reddit.com/r/programming/comments/1hve87/the_architecture_twitter_uses_to_deal_with_150m/) -* [关于黑客新闻](https://news.ycombinator.com/item?id=6007650) -* [Twitter 上的实时交付体系结构](http://www.infoq.com/presentations/Real-Time-Delivery-Twitter) -* [论文：疯狂的饲料：有选择地实现用户的事件 Feed](http://highscalability.com/blog/2012/1/17/paper-feeding-frenzy-selectively-materializing-users-event-f.html) -* [Google：驯服长时延的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) -* [Facebook 是否开发了自定义的内存数据库来管理其新闻提要？](http://www.quora.com/Facebook-Engineering/Did-Facebook-develop-a-custom-in-memory-database-to-manage-its-News-Feeds) （阅读时扇出） +您的网站是什么？ -我不会将 22MB / s 称为“ firehose”，这确实占用很少的带宽……您确定您有权利吗？ +乔恩 -我虽然说“不会再有类似的东西了” +我很震惊，没有看到本文中提到的 PHP-FPM。 事实是否真的如此，以至每个人都认为它已被使用，或者（更可能提到 APC）它被完全忽略了吗？ 即使在 Apache 中，PHP-FPM 的性能优势也令人惊讶，我确实希望所有 PHP 呈现的文件的性能都能提高 2 倍，而无需进行任何其他更改。 -然后我虽然是 NSA Prism 的一员。 +这篇文章关于将站点扩展到 30,000，而不是关于 PHP 扩展。 PHP-FPM 在一台服务器上每秒可处理 350-400 个最大请求 -@吉姆·柯林斯（Jim Collins）：假设每条推文都是最大长度，即每秒约 144,179 条推文。 显然，并非所有的推文都具有最大长度，因此可能要大得多。 +“不要在 PHP 代码中与其他服务器建立连接。 +与其他服务器建立连接会阻塞服务器并减慢处理速度。请使用 APC 密钥/值存储来存储数据，并使用 Varnish 来缓存整个页面。” -回复：Firehose +逻辑页面始终需要连接到后端，例如数据库，内存缓存或其他后端服务， +缓存是提高性能的好方法， -吉姆（Jim），推特（Twitter）从一开始就一直将其称为“火柴”。 要记住的是，它是每条公共推文（每天删除）中大约每天 1-2kb 大小的连续推文流，每条每天 10-20k /秒。 没有休息，没有暂停。 典型的消费者将实时（或接近）实时处理该卷，因为从历史上看，您不应该保存推文内容。 +但是您怎么可能在没有后端的情况下提供页面？ 许多 Web 应用程序远非一个简单的页面。 嗯，我不明白。 有人可以解释吗？ -以 22 兆/秒的速度，这对客户端来说是 57 TB /月的入口。 但是，Twitter 需要将相同的数据发送给多个客户（此计数尚未公开），这就是他们向该服务收费的原因之一（如果我没记错的话，每月收费约 2 万美元）。 - -嗯是的。 你笑了，但这不是一个小问题。 - -Scala 规则 - -不是“公共汽车”-不仅仅是一个吻。 是“公共汽车”。 - -如果您认为 22MB /秒是小带宽，那么您是新手。 一年的 31,536,000 秒中的每个秒为 22MB /秒。 是的，这是 3150 万 x 22MB。 - -关键确实在于它是不间断的。 您的 USB 密钥以 22MB /秒的速度持续一分钟，与发送数万条消息的 22MB /秒的流无关。 -这是疯狂的并发，它的工作原理令人惊讶。 - -亲爱的 Pedantic，公车是公车的正确复数形式。 在幸灾乐祸之前先查一下。 - -在 Fashiolista，我们已经建立了一个类似的解决方案，我们正在开源中。 对于早期预览，请查看： -https://github.com/tschellenbach/Feedly - -经过数百万用户的考验。 （不是成千上万的推特：）） -我们仍在与 Fashiolista 完全分离的过程中，第一个用户友好的 Beta 版将于 7 月底完成。 目前，您可以将其用作灵感来源。 - -QPS ==每秒查询吗？ - -> >一条推文最多可能需要 5 分钟才能从 Lady Gaga 的手指流到她的 3100 万关注者。 - -你的意思是 5 秒，不是吗？ - -“应用了业务规则。删除了您不关注的人的回复。可以过滤掉来自用户的转发。在 Twitter 范围内做到这一点具有挑战性。” - -嗯...当他们做出这个改变，杀死了我的“新人”之后，发现率就死了，他们说这是因为它没有扩展？ 现在他们说进行这种过滤具有挑战性吗？ - -此外，所有帐户的 firehose 客户最多不超过 20 个，但有趣的是（请看他们的招聘模式和客户列表）是 dataminr - -处理 Ruby 的单线程需要相当多的技巧。 - -Matz 在 2009 年中旬访问了 Moffett Field 的 SV RoR 聚会时说，并行化是 Ruby 的第一要务。 但是已经四年了... - -不要使用独角兽，使用彪马。 MRI 会尖叫。 - -看起来像是该课程的所有数据 http://blogs.ischool.berkeley.edu/i290-abdt-s12/ - -公交车与公交车 -在 21 世纪的英语中，公交车是名词公交车的首选复数形式。 总线偶尔出现，并且字典将其列为辅助拼写，但是一个多世纪以来一直不受青睐。 在所有主要英语版本中都是如此。 - -在 19 世纪以公车的缩写出现公共汽车之后，公共汽车和公共汽车（逻辑上是公共汽车的复数形式，是公共汽车的早期替代拼写）争夺了几十年的统治地位。 但是，到 20 世纪初，公共汽车已成为明显的赢家，并且它已经逐渐流行。 如今，对于每种实例，公交车都会在网络上出现 15 次。 - -“扇出”，“扇出”到底是什么意思？？？？ - -Gizzard 已退休： [https://github.com/twitter/gizzard](Gizzard on GitHub) - -似乎需要更新。 但是，Twitter 的体系结构可能正在不断发展。 - -如果您正在阅读此文章，则 Stream-Framework 和 Stream 可能会派上用场： -https://getstream.io/ -https://github.com/tschellenbach/stream-framework - -基于拉取的时间轴的高级错误： - -这是不正确的： - -只有您的家庭时间轴命中磁盘。 - -正确的是： - -只有您的用户时间轴命中磁盘。 您的主时间轴都不会命中磁盘，而只会在 Redis 集群中。 - -“由于您的时间轴位于 3 个不同的位置，因此有效地运行 3 个不同的哈希环。” -为什么三声响？ 每个副本集都有一个不同的哈希表环吗？ -缓存如何分片？ 通过 userId？ \ No newline at end of file +@reeze：可能是静态页面！ \ No newline at end of file diff --git a/docs/124.md b/docs/124.md index 181f143..9145ebb 100644 --- a/docs/124.md +++ b/docs/124.md @@ -1,49 +1,231 @@ -# 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips +# Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户，300K QPS，22 MB / S Firehose 以及发送推文 + +> 原文： [http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) + +[![](img/175760828c3825c5257e29ae94d31d40.png)](http://www.flickr.com/photos/13733851@N00/9235686327/sizes/o/in/photostream/) + +解决 Twitter“问题”的玩具解决方案是最受欢迎的可伸缩性。 每个人都认为 Twitter 很容易。 挥舞着一点建筑手，我们就拥有了一个可扩展的 Twitter，就这么简单。 好吧，这不是那么简单，就像 Twitter 的工程副总裁 [Raffi Krikorian](https://twitter.com/raffi) 在他对 [时间轴的出色且详尽的介绍中所描述的那样 规模](http://www.infoq.com/presentations/Twitter-Timeline-Scalability) 。 如果您想了解 Twitter 的工作原理，请从这里开始。 + +它是逐渐发生的，所以您可能会错过它，但是 Twitter 已经成长。 它最初是一个苦苦挣扎的 [三层 Ruby on Rails](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster) 网站，现在已经成为一个精美的服务驱动核心，我们现在实际去看看其他服务是否已关闭。 很大的变化。 + +Twitter 现在拥有 1.5 亿全球活跃用户，处理 300K QPS 来生成时间线，以及每秒输出 22 MB 速度的流水线。 每天有 4 亿条推文通过该系统，从 Lady Gaga 的手指到 3100 万追随者的推文最多可能需要 5 分钟。 + +有几点值得注意： + +* Twitter 不再希望成为网络应用程序。 Twitter 希望成为为全球移动客户端提供动力的一组 API，充当地球上最大的实时事件总线之一。 +* Twitter 主要是一种消费机制，而不是生产机制。 300K QPS 用于读取时间轴，而每秒仅 6000 个请求用于写入。 +* 具有大量关注者名单的离群值正在成为一种常见情况。 从具有大量关注者的用户发送推文（即扇出大）可能会很慢。 Twitter 尝试在 5 秒内做到这一点，但它并不总是有效，特别是当名人互相推 t 时，这种情况越来越多。 结果之一是，回复可能会在收到原始推文之前到达。 Twitter 正在从对写入的所有工作转变为对高价值用户进行更多的读取工作。 +* 您的家庭时间轴位于 Redis 集群中，最多包含 800 个条目。 +* Twitter 从您关注的人以及单击的链接上对您了解很多。 当双向遵循不存在时，隐式社会契约可以暗示很多。 +* 用户关心推文，但是推文的文本与 Twitter 的大多数基础结构几乎无关。 +* 它需要一个非常复杂的监视和调试系统来跟踪复杂堆栈中的性能问题。 过去遗留决策的幽灵总是困扰着系统。 + +Twitter 如何运作？ 阅读 Raffi 精彩演讲的内容，并发现... + +## 挑战 + +* 1.5 亿用户的时间轴（首页和搜索）的 300K QPS 可能会很慢。 +* 幼稚的物化是整个 Twitter 上大量的精选声明。 它被审判并死亡。 +* 解决方案是基于写的扇出方法。 推文到达时要进行大量处理，以找出推文应该去哪里。 这样可以快速轻松地读取时间。 不要对读取进行任何计算。 在写路径上执行所有工作后，摄取速率比读路径慢，约为 4000 QPS。 + +## 团体 + +* 平台服务小组负责 Twitter 的核心可扩展基础架构。 + * 他们运行称为“时间轴服务”，“推文服务”，“用户服务”，“社交图谱服务”的东西，这些工具为 Twitter 平台提供了强大的支持。 + * 内部客户端使用与外部客户端大致相同的 API。 + * 已针对第三方 API 注册了超过 1 百万个应用 + * 与产品团队签订合同是他们不必担心规模。 + * 进行容量规划，设计可扩展的后端系统，随着站点以意想不到的方式不断增长而不断替换基础架构。 +* Twitter 有一个架构小组。 有关 Twitter 的整体整体架构。 维护技术债务清单（他们希望摆脱的清单）。 + +## 推我拉我 + +* 人们一直在 Twitter 上创建内容。 Twitter 的工作是弄清楚如何将内容联合起来。 如何将其发送给您的关注者。 +* 真正的挑战是实时约束。 目标是在不超过 5 秒的时间内将消息流传递给用户。 + * 交付意味着收集内容并在 Internet 上施加压力，以使其尽快恢复。 + * 传递到内存中的时间轴群集，推式通知，已触发的电子邮件，所有 iOS 通知以及 Blackberry 和 Android，SMS。 + * Twitter 是按世界上任何活跃用户的最大 SMS 生成器。 + * 选举可能是内容进入和内容散播的最大驱动力之一。 +* 时间线的两种主要类型：用户时间线和主时间线。 + * 用户时间轴是特定用户已发送的所有推文。 + * 主时间轴是您正在关注的人的所有用户时间轴的时间合并。 + * 业务规则被应用。 @您不认识的人的回复被删除。 可以过滤掉来自用户的转发。 + * 在 Twitter 规模上做到这一点具有挑战性。 +* 拉式 + * 目标时间表。 诸如 twitter.com 和 home_timeline API 之类的东西。 发推文是因为您要求查看而发给您的。 基于拉式的传递：您正在通过 REST API 调用从 Twitter 请求此数据。 + * 查询时间轴。 搜索 API。 针对语料库的查询。 尽快返回与特定查询匹配的所有推文。 +* 基于推送 + * Twitter 运行着最大的实时事件系统之一，通过 Firehose 以 22 MB /秒的速度推送推文。 + * 打开一个 Twitter 套接字，他们将在 150 毫秒内将所有公开推文推送给您。 + * 在任何给定时间，推集群都可以打开约一百万个套接字。 + * 面向搜索引擎之类的客户。 所有公开推文都来自这些插座。 + * 不，你不能拥有它。 （您无法处理/承担事实。） + * 用户流连接。 Powers TweetDeck 和适用于 Mac 的 Twitter 也经历了这里。 当您登录时，他们会查看您的社交图，仅从您所关注的人那里发送消息，从而重新创建家庭时间轴体验。 通过持久连接，无需轮询即可获得相同的时间轴体验。 + * 查询 API。 发出关于推文的常规查询。 创建推文并找到与查询匹配的推文后，会将它们路由到查询的注册套接字中。 + +## 高水平的基于拉的时间轴 + +* 通过写 API 发出推文。 它通过负载平衡器和 TFE（Twitter 前端）以及其他无法解决的问题。 +* 这是一条非常有方向的道路。 完全预先计算的家庭时间表。 随着推文的出现，所有业务规则都将执行。 +* 立即发生扇出过程。 传入的推文放置在庞大的 Redis 集群中。 每个推文在 3 台不同的计算机上复制 3 次。 在 Twitter 规模上，许多机器每天都会发生故障。 +* 扇出查询基于[群](https://github.com/twitter/flockdb)的社交图服务。 Flock 维护关注者和关注者列表。 + * Flock 返回收件人的社交图，并开始遍历 Redis 集群中存储的所有时间轴。 + * Redis 群集具有几个 TB 的 RAM。 + * 一次流水线式 4k 目的地 + * Redis 内部使用本机列表结构。 + * 假设您发了推文，并且有 2 万名关注者。 扇出守护程序将执行的操作是查找 Redis 集群中所有 20K 用户的位置。 然后，它将开始在整个 Redis 集群的所有这些列表中插入 tweet 的 Tweet ID。 因此，在 Redis 集群中，每条推文写入操作都会产生多达 20K 次插入。 + * 存储的内容是生成的推文的推文 ID，该推文发起人的用户 ID，以及用于标记是转推，回复还是其他内容的 4 个字节的位。 + * 您的家庭时间轴位于 Redis 集群中，长度为 800 个条目。 如果翻页时间足够长，您将达到限制。 RAM 是确定当前 tweet 集可以持续多长时间的限制资源。 + * 每个活动用户都存储在 RAM 中，以降低延迟。 + * 活动用户是指在 30 天内登录 Twitter 的用户，该用户可能会根据缓存容量或 Twitter 的使用情况而变化。 + * 如果您不是活跃用户，则该推文不会进入缓存。 + * 只有您的家庭时间轴命中磁盘。 + * 如果您从 Redis 集群中掉出来，那么您将经历一个称为重建的过程。 + * 针对社交图服务查询。 找出您关注的人。 为它们中的每一个命中磁盘，然后将它们推回 Redis。 + * 它是 MySQL 通过 [Gizzard](https://github.com/twitter/gizzard) 处理磁盘存储的功能，该存储区提取了 SQL 事务并提供了全局复制。 + * 如果一台机器有问题，则通过复制 3 次，则他们不必为每个数据中心重新创建该机器上所有时间线的时间线。 + * 如果推文实际上是转发，则将指针存储到原始推文。 +* 当您查询家庭时间轴时，将查询时间轴服务。 然后，“时间线服务”只需要查找一台带有您自己的家庭时间线的机器。 + * 有效地运行 3 个不同的哈希环，因为您的时间轴位于 3 个不同的位置。 + * 他们找到第一个可以最快到达的人，并尽快返回。 + * 权衡是扇出需要更长的时间，但是读取过程很快。 从冷缓存到浏览器大约 2 秒钟。 对于 API 调用，大约需要 400 毫秒。 +* 由于时间轴仅包含推文 ID，因此它们必须“水合”那些推文，即找到这些推文的文本。 给定一个 ID 数组，他们可以执行一次 multiget 并从 T-bird 并行获取这些推文。 +* Gizmoduck 是用户服务，而 Tweetypie 是推特对象服务。 每个服务都有自己的缓存。 用户缓存是具有整个用户库的内存缓存群集。 Tweetypie 大约有一个月的推文和一半的推文存储在其 Memcache 集群中。 这些暴露给内部客户。 +* 一些读取时间过滤发生在边缘。 例如，在法国过滤掉纳粹的内容，因此在内容被发送出去之前会进行读取。 -> 原文： [http://highscalability.com/blog/2013/7/3/5-rockin-tips-for-scaling-php-to-30000-concurrent-users-per.html](http://highscalability.com/blog/2013/7/3/5-rockin-tips-for-scaling-php-to-30000-concurrent-users-per.html) +## 高级搜索 -![](img/f566686494a57f3d41c1c50751d6f818.png) +* 与拉力相反。 所有这些都在读取路径上计算得出，这使写入路径变得简单。 +* 当出现一条推文时，Ingester 会标记化并找出他们想要索引的所有内容，并将其填充到一台 Early Bird 机器中。 Early Bird 是 Lucene 的修改版本。 索引存储在 RAM 中。 +* 在扇出状态中，一条推文可能会存储在 N 个关注您的家庭时间轴中，在 Early Bird 中，一条推文仅存储在一台 Early Bird 计算机中（复制除外）。 +* Blender 创建搜索时间线。 它必须在数据中心内分散聚集。 它会查询每个 Early Bird 碎片，并询问您是否有与此查询匹配的内容？ 如果您要求“纽约时报”，则查询所有分片，然后将结果返回，排序，合并和重新排序。 重新排名是通过社交方式证明的，这意味着要查看转发，收藏和回复的数量。 +* 活动信息是在写入的基础上计算的，其中有一个活动时间表。 当您偏爱和回复推文时，将维持活动时间线，类似于家庭时间线，它是一系列活动的 ID，因此有收藏夹 ID，回复 ID 等。 +* 所有这些都送入搅拌机。 在读取路径上，它会重新计算，合并和排序。 返回您所看到的搜索时间轴。 +* 发现是根据他们对您的了解进行的定制搜索。 他们之所以知道很多，是因为您关注了很多人，单击链接，这些信息将用于发现搜索。 它会根据收集到的有关您的信息进行排名。 -[众筹公司 RockThePost.com 的首席技术官 Jonathan Block](http://www.linkedin.com/pub/jonathan-block/57/a70/b02) 为较小的站点编写了一套不错的技巧，以帮助他们了解如何使用 一个小的两人开发团队。 +## 搜索和拉是反函数 -他们的服务具有典型的小规模结构： +* 搜索和拉动看起来非常相似，但是它们具有彼此相反的属性。 +* 在主时间轴上： + * 写。 当有一条推文出现时，会有一个 O（n）进程写入 Redis 集群，其中 n 是跟随您的人数。 令 Lady Gaga 和 Barack Obama 感到痛苦的是，他们在整个集群中进行了数以千万计的插入操作。 所有 Redis 群集都在备份磁盘，Flock 群集将用户时间线存储到磁盘，但是通常在 Redis 群集的 RAM 中找到时间线。 + * 读。 通过 API 或网络查找合适的 Redis 机器为 0（1）。 Twitter 经过优化，可以在家庭时间轴上的读取路径上高度可用。 读取路径以 10 毫秒为单位。 Twitter 主要是一种消费机制，而不是生产机制。 每秒读取 300K 请求，写入每秒 6000 RPS。 +* 在搜索时间轴上： + * 写。 当一条推文进入并击中 Ingester 时，仅击中一台 Early Bird 机器。 写入时间路径为 O（1）。 在排队和处理之间的 5 秒钟内，将提取一条推文，以找到要写入的一条“早起的鸟儿”。 + * 读。 当读取进来时，它必须在整个群集中读取 0（n）。 大多数人不使用搜索，因此他们可以有效地存储推文以进行搜索。 但是他们及时付款。 读数约为 100 毫秒。 搜索从不打磁盘。 整个 Lucene 索引都位于 RAM 中，因此散点式聚集读取非常有效，因为它们从未命中磁盘。 +* 推文几乎与大多数基础架构无关。 [T 鸟存储](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html) 整个推文集。 一条推文的大部分内容都在 RAM 中。 如果没有，请打 T-bird 并执行选择查询以再次将它们退回。 文字几乎无关紧要，除了搜索，趋势或正在发生的事情之外。 家庭时间表几乎根本不在乎。 -* PHP 的 Zend Framework 2 -* 两个用于 Web 服务器的 m1.medium -* ELB 拆分负载 -* 主/从 MySQL 数据库 -* 围攻进行负载测试 +## 未来 -每个 Web 服务器可以处理 30,000 个并发用户的非常明智的技巧： +* 如何使该管道更快，更高效？ +* 扇出动作可能很慢。 尝试在 5 秒内完成操作，但有时不起作用。 非常辛苦，尤其是在名人鸣叫时，这种情况越来越多。 +* Twitter 关注图是不对称关注。 仅在给定时间关注的人上呈现推文。 Twitter 对您了解很多，因为您可能关注 Lance Armstrong，但他没有关注您。 当双向遵循不存在时，隐式社会契约可以暗示很多。 +* 问题在于大型基数图。 @ladygaga 有 3100 万粉丝。 @katyperry 有 2800 万关注者。 @justinbieber 有 2800 万关注者。 @barackobama 有 2300 万关注者。 +* 这些人之一发推文时，要在数据中心中写很多推文。 当他们开始互相交谈时，这尤其具有挑战性，这种情况一直存在。 +* 这些高扇出用户是 Twitter 面临的最大挑战。 在名人的原始推文发布之前，一直都有回复。 他们介绍了整个站点的比赛条件。 如果从 Lady Gaga 发推文到宣告发散花几分钟的时间，那么人们会在不同的时间点看到她的推文。 最近关注 Lady Gaga 的人可能比过去关注她的人早 5 分钟看到她的推文。 假设某人在早期接收列表中进行了回复，然后在仍在进行扇出操作的同时对该回复的扇出进行了处理，因此该回复会在接收到其推文的人的原始推文之前注入。 引起很多用户混乱。 由于推文主要是单调增加的，因此在发布前按 ID 对其进行排序，但这并不能解决该范围的问题。 高价值扇出始终排队备份。 +* 试图弄清楚如何合并读写路径。 不再分散高价值用户。 对于像泰勒·斯威夫特（Taylor Swift）这样的人，不再烦恼扇出，而在阅读时将其合并到时间表中。 平衡读写路径。 节省百分之十的计算资源。 -* **使用 PHP 的 APC 功能**。 APC 是操作码缓存，“ 确实是一个要求，以便网站有机会表现良好。” -* **将不是.php 请求的所有内容放在 CDN** 上。 不要从您的 Web 服务器提供静态文件。 他们将所有内容放到 S3 上，并使用 CloudFront 作为 CDN。 最近的 CloudFront 问题导致它们直接从 S3 服务。 -* **不要使用 PHP 代码**与其他服务器建立连接。 与其他服务器建立连接会阻塞服务器并减慢处理速度。 使用 APC 键/值存储区进行数据存储，使用 Varnish 缓存整页。 -* **使用清漆**。 在负载测试下，使用清漆法师对其性能的最大不同。 -* **使用 c1.xlarge** 。 c1.xlarge 具有 8 个 CPU，在负载下确实有帮助。 m1.medium 只有 1 个 CPU 用于处理请求。 +## 去耦 -非常简单，但很好的建议。 [的原始文章](https://coderwall.com/p/__z9ia)具有更多详细信息，非常值得阅读。 +* 推文以许多不同的方式分叉，主要是使团队彼此分离。 搜索，推送，关注电子邮件和家庭时间轴团队可以彼此独立工作。 +* 由于性能原因，系统已被解耦。 Twitter 以前是完全同步的。 由于性能原因，这种情况在 2 年前就停止了。 将推文吸收到推文 API 中最多需要 145 毫秒，然后所有客户端都将断开连接。 这是出于遗留原因。 Ruby 通过 MRI（单线程服务器）为写入路径提供动力，每次分配 Unicorn 工作者时，处理能力就被消耗 eat 尽。 他们希望能够尽快释放客户端连接。 出现一条推文。Ruby 将其吸收。 将其放入队列并断开连接。 他们每个盒子只运行大约 45-48 个进程，因此每个盒子只能同时摄取那么多推文，因此他们希望尽快断开连接。 +* 这些推文将传递到异步途径，我们一直在讨论的所有内容都将在其中传递。 -有趣。 去表明我们落后了多远。 我们当前的应用程序大约有 6 个 c1.xlarge 和 10 个 fm.medium 服务器。 它运行缓慢，大约有 100 个用户。 将阅读全文。 +## 监控方式 -但这只是外部站点。 原始文章指出，一旦用户登录到“内部”网站，每个服务器只能处理 1,000 个？ 那不是很多。 +* 办公室周围的仪表板显示了系统在任何给定时间的运行情况。 +* 如果您有 100 万关注者，则需要花费几秒钟来散布所有推文。 +* 推文输入统计：每天 4 亿条推文； 日均 5K /秒； 每日峰值 7K /秒； >在大型活动中为 12K / sec。 +* 时间轴交付统计：每天 30b 次交付（〜21m / min）； 3.5 秒@ p50（第 50 个百分位数），传送到 1m； 30 万次/秒； @ p99，最多可能需要 5 分钟 +* 名为 VIZ 的系统监视每个群集。 向时间线服务请求以从 Scala 群集中获取数据的平均时间为 5 毫秒。 @ p99 是 100 毫秒。 @ p99.9 是它们命中磁盘的位置，因此需要花费几百毫秒的时间。 +* [Zipkin](https://twitter.com/zipkinproject) 基于 Google 的 Dapper 系统。 有了它，他们可以对请求进行污染并查看其命中的每个服务以及请求时间，因此他们可以对每个请求的性能有非常详细的了解。 然后，您可以深入查看并查看每个单个请求，并了解所有不同的时间。 通过查看在请求上花费的时间来花费大量时间来调试系统。 他们还可以按阶段显示汇总统计信息，以查看扇出或交付所需的时间。 这是一个为期 2 年的项目，目的是使活动用户的时间线降低到 2 毫秒。 花了很多时间来解决 GC 暂停问题，解决内存缓存查找问题，了解数据中心的拓扑结构以及为这种成功设置集群。 -耶勒特， +## 相关文章 -您的网站是什么？ +* [为什么 Facebook，Digg 和 Twitter 很难扩展？](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) +* [在 Reddit 上](http://www.reddit.com/r/programming/comments/1hve87/the_architecture_twitter_uses_to_deal_with_150m/) +* [关于黑客新闻](https://news.ycombinator.com/item?id=6007650) +* [Twitter 上的实时交付体系结构](http://www.infoq.com/presentations/Real-Time-Delivery-Twitter) +* [论文：疯狂的饲料：有选择地实现用户的事件 Feed](http://highscalability.com/blog/2012/1/17/paper-feeding-frenzy-selectively-materializing-users-event-f.html) +* [Google：驯服长时延的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) +* [Facebook 是否开发了自定义的内存数据库来管理其新闻提要？](http://www.quora.com/Facebook-Engineering/Did-Facebook-develop-a-custom-in-memory-database-to-manage-its-News-Feeds) （阅读时扇出） -乔恩 +我不会将 22MB / s 称为“ firehose”，这确实占用很少的带宽……您确定您有权利吗？ -我很震惊，没有看到本文中提到的 PHP-FPM。 事实是否真的如此，以至每个人都认为它已被使用，或者（更可能提到 APC）它被完全忽略了吗？ 即使在 Apache 中，PHP-FPM 的性能优势也令人惊讶，我确实希望所有 PHP 呈现的文件的性能都能提高 2 倍，而无需进行任何其他更改。 +我虽然说“不会再有类似的东西了” -这篇文章关于将站点扩展到 30,000，而不是关于 PHP 扩展。 PHP-FPM 在一台服务器上每秒可处理 350-400 个最大请求 +然后我虽然是 NSA Prism 的一员。 -“不要在 PHP 代码中与其他服务器建立连接。 -与其他服务器建立连接会阻塞服务器并减慢处理速度。请使用 APC 密钥/值存储来存储数据，并使用 Varnish 来缓存整个页面。” +@吉姆·柯林斯（Jim Collins）：假设每条推文都是最大长度，即每秒约 144,179 条推文。 显然，并非所有的推文都具有最大长度，因此可能要大得多。 -逻辑页面始终需要连接到后端，例如数据库，内存缓存或其他后端服务， -缓存是提高性能的好方法， +回复：Firehose -但是您怎么可能在没有后端的情况下提供页面？ 许多 Web 应用程序远非一个简单的页面。 嗯，我不明白。 有人可以解释吗？ +吉姆（Jim），推特（Twitter）从一开始就一直将其称为“火柴”。 要记住的是，它是每条公共推文（每天删除）中大约每天 1-2kb 大小的连续推文流，每条每天 10-20k /秒。 没有休息，没有暂停。 典型的消费者将实时（或接近）实时处理该卷，因为从历史上看，您不应该保存推文内容。 -@reeze：可能是静态页面！ \ No newline at end of file +以 22 兆/秒的速度，这对客户端来说是 57 TB /月的入口。 但是，Twitter 需要将相同的数据发送给多个客户（此计数尚未公开），这就是他们向该服务收费的原因之一（如果我没记错的话，每月收费约 2 万美元）。 + +嗯是的。 你笑了，但这不是一个小问题。 + +Scala 规则 + +不是“公共汽车”-不仅仅是一个吻。 是“公共汽车”。 + +如果您认为 22MB /秒是小带宽，那么您是新手。 一年的 31,536,000 秒中的每个秒为 22MB /秒。 是的，这是 3150 万 x 22MB。 + +关键确实在于它是不间断的。 您的 USB 密钥以 22MB /秒的速度持续一分钟，与发送数万条消息的 22MB /秒的流无关。 +这是疯狂的并发，它的工作原理令人惊讶。 + +亲爱的 Pedantic，公车是公车的正确复数形式。 在幸灾乐祸之前先查一下。 + +在 Fashiolista，我们已经建立了一个类似的解决方案，我们正在开源中。 对于早期预览，请查看： +https://github.com/tschellenbach/Feedly + +经过数百万用户的考验。 （不是成千上万的推特：）） +我们仍在与 Fashiolista 完全分离的过程中，第一个用户友好的 Beta 版将于 7 月底完成。 目前，您可以将其用作灵感来源。 + +QPS ==每秒查询吗？ + +> >一条推文最多可能需要 5 分钟才能从 Lady Gaga 的手指流到她的 3100 万关注者。 + +你的意思是 5 秒，不是吗？ + +“应用了业务规则。删除了您不关注的人的回复。可以过滤掉来自用户的转发。在 Twitter 范围内做到这一点具有挑战性。” + +嗯...当他们做出这个改变，杀死了我的“新人”之后，发现率就死了，他们说这是因为它没有扩展？ 现在他们说进行这种过滤具有挑战性吗？ + +此外，所有帐户的 firehose 客户最多不超过 20 个，但有趣的是（请看他们的招聘模式和客户列表）是 dataminr + +处理 Ruby 的单线程需要相当多的技巧。 + +Matz 在 2009 年中旬访问了 Moffett Field 的 SV RoR 聚会时说，并行化是 Ruby 的第一要务。 但是已经四年了... + +不要使用独角兽，使用彪马。 MRI 会尖叫。 + +看起来像是该课程的所有数据 http://blogs.ischool.berkeley.edu/i290-abdt-s12/ + +公交车与公交车 +在 21 世纪的英语中，公交车是名词公交车的首选复数形式。 总线偶尔出现，并且字典将其列为辅助拼写，但是一个多世纪以来一直不受青睐。 在所有主要英语版本中都是如此。 + +在 19 世纪以公车的缩写出现公共汽车之后，公共汽车和公共汽车（逻辑上是公共汽车的复数形式，是公共汽车的早期替代拼写）争夺了几十年的统治地位。 但是，到 20 世纪初，公共汽车已成为明显的赢家，并且它已经逐渐流行。 如今，对于每种实例，公交车都会在网络上出现 15 次。 + +“扇出”，“扇出”到底是什么意思？？？？ + +Gizzard 已退休： [https://github.com/twitter/gizzard](Gizzard on GitHub) + +似乎需要更新。 但是，Twitter 的体系结构可能正在不断发展。 + +如果您正在阅读此文章，则 Stream-Framework 和 Stream 可能会派上用场： +https://getstream.io/ +https://github.com/tschellenbach/stream-framework + +基于拉取的时间轴的高级错误： + +这是不正确的： + +只有您的家庭时间轴命中磁盘。 + +正确的是： + +只有您的用户时间轴命中磁盘。 您的主时间轴都不会命中磁盘，而只会在 Redis 集群中。 + +“由于您的时间轴位于 3 个不同的位置，因此有效地运行 3 个不同的哈希环。” -为什么三声响？ 每个副本集都有一个不同的哈希表环吗？ +缓存如何分片？ 通过 userId？ \ No newline at end of file diff --git a/docs/125.md b/docs/125.md index 9ce0e22..ec28597 100644 --- a/docs/125.md +++ b/docs/125.md @@ -1,72 +1,200 @@ -# 在 Yelp 上利用云计算-每月访问量为 1.02 亿，评论量为 3900 万 +# Salesforce Architecture-他们每天如何处理 13 亿笔交易 -> 原文： [http://highscalability.com/blog/2013/6/26/leveraging-cloud-computing-at-yelp-102-million-monthly-visto.html](http://highscalability.com/blog/2013/6/26/leveraging-cloud-computing-at-yelp-102-million-monthly-visto.html) +> 原文： [http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html](http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html) -![](img/f8bad06a01e3b7dcfc5004dec36459bf.png) +![](img/cd1c1c540f70b4a63925781e16857370.png) -*这是 Yelp 的， [Jim Blomo](https://twitter.com/jimblomo) 的来宾帖子。 Jim 管理着一个不断发展的数据挖掘团队，该团队使用 Hadoop ， mrjob 和奇数作业处理 TB 数据。 在 Yelp 之前，他为初创公司和亚马逊建立了基础架构。* *在即将举行的 [OSCON 2013 上发表演讲，内容涉及在 Yelp](http://www.oscon.com/oscon2013/public/schedule/detail/29387) 建立云文化。* +*这是由 [salesforce.com](http://www.linkedin.com/profile/view?id=3158913) 的首席站点可靠性工程师 [Claude Johnson](http://www.linkedin.com/profile/view?id=3158913) 撰写的来宾帖子。* -在 2013 年第一季度，Yelp 的**唯一身份访问者为[1.05 亿]** （来源：Google Analytics（分析）），其中每月平均有大约 1000 万使用 Yelp 应用程序的独特移动设备。 Yelpers 甚至 ve 撰写的内容超过 **3,900 万篇丰富的本地评论**，这使 Yelp 成为了从精品店，技工到餐厅和牙医等各个领域的领先本地指南 。 关于数据，关于 Yelp 的最独特的事情之一就是数据的多样性：评论，用户个人资料，业务描述，菜单，签到，食物照片……清单还在继续。 我们有很多处理数据的方法，但是今天我将重点介绍如何处理离线数据处理和分析。 +以下是 salesforce.com 的核心平台和应用程序的体系结构概述。 其他材料（例如，Heroku 的 Dyno 架构）或其他产品的子系统（例如，work.com 和 do.com）不在本材料中，尽管 database.com 不在其中。 想法是与技术社区分享有关 salesforce.com 如何执行工作的一些见解。 任何错误或遗漏是我的。 -在 2009 年底，Yelp 使用亚马逊的 Elastic MapReduce （ EMR ）作为备用计算机构建的内部集群的替代和进行了调查。 到 2010 年中，我们已经将生产处理完全转移到 EMR ，并关闭了 Hadoop 集群。 今天，我们从集成测试到广告指标，每天要处理 **500 个工作** 。 ve 在此过程中吸取了一些教训，希望对您有所帮助，因为我们 ll 。 +这绝不是全面的，但是如果有兴趣，作者将很乐意解决 salesforce.com 运作的其他领域。 Salesforce.com 希望与以前未与之互动的技术社区更加开放。 这是关于“如何打开和服”的开始。 -## 工作流池 +自 1999 年以来，salesforce.com 一直专注于构建通过 Internet 交付的业务技术，以取代传统的企业软件。 我们的客户通过按月订阅付费，以通过网络浏览器随时随地访问我们的服务。 我们希望这种对 salesforce.com 核心体系结构的探索将是对该社区做出的许多贡献的第一步。 -EMR 的最大优势之一是即时可伸缩性：每个作业流可以配置有任务所需的多个实例。 但是可伸缩性并不是免费的。 主要缺点是 1）分解群集可能需要 5 至 20 分钟，2）每小时需要支付**或不足一小时**的费用。 这意味着，如果您的工作在 2 小时 10 分钟内完成，则将向您收取整整三个小时的费用。 +## 定义 -![](img/9edb1d9f3836bf33e890aa110760b6b4.png) +让我们从一些基本的 salesforce.com 术语开始： -在您开始运行数百个作业并且作业流程结束时所浪费的时间开始累积之前，这似乎并不重要。 为了减少浪费的计费时间， mrjob 实现了“作业流池”。 mrjob 而不是在工作结束时关闭工作流，以防其他工作想要使用它，而保持工作流 ve 的状态。 如果随之而来的另一个作业具有相似的群集要求，则 mrjob wi ll 将重用作业流程。 +* **实例**-共享和非共享的完整的系统，网络和存储基础结构集，可为部分客户提供 salesforce.com 服务。 例如，na14.salesforce.com 是一个实例。 +* **Superpod** -一组系统，网络和存储基础结构，包括出站代理服务器，负载平衡器，邮件服务器，SAN 结构和支持多个实例的其他基础结构。 Superpods 在数据中心内提供服务隔离，因此共享或复杂组件的问题不会影响该数据中心中的每个实例。 +* **机构**（又称组织）-Salesforce 应用程序的单个客户。 从 www.salesforce.com 或 developer.force.com 开始的每次试用都会产生一个新的组织。 组织是高度可定制的，并且可以具有不同的安全设置，记录可见性和共享设置，UI 外观，工作流，触发器，自定义对象，标准 salesforce.com CRM 对象上的自定义字段，甚至是自定义 REST API。 组织可以支持从一百万到数百万个许可的个人用户帐户，门户网站用户帐户和 Force.com 网站用户帐户。 +* **沙箱**-salesforce.com 服务的一个实例，该实例托管用于客户应用程序开发目的的生产组织的完整副本。 使用我们平台的客户可以拥有完整的应用程序开发生命周期。 这些是供客户在将更改部署到其生产组织中之前对其应用程序进行用户验收测试的测试环境。 -![](img/06ca7b6e6bb2098fceb4d0e2637dce6a.png) +## 统计信息（截至 2013 年 8 月） -实施此操作有一些微妙之处：1）具有“相似的集群要求”是什么意思，2）如何避免多个作业之间的竞争状况，以及 3）集群何时最终关闭？ +* 17 个北美实例，4 个 EMEA 实例和 2 个 APAC 实例 +* 20 个沙箱实例 +* 1,300,000,000 笔以上的每日交易 +* 高峰时每秒 24,000 个数据库事务（相当于其他站点上的页面浏览） +* 15,000 多个硬件系统 +* > 22 PB 的原始 SAN 存储容量 +* > 5K SAN 端口 -定义了满足以下条件的类似工作流程： +## 使用的软件技术 -* 相同的 Amazon Machine Image（AMI）版本 -* 相同的 Hadoop 版本 -* 相同的 mrjob 版本 -* 相同的引导步骤（引导步骤可以设置 Hadoop 或群集选项） -* 每种节点类型具有相同或更大的 RAM 和计算单元（例如。 Hadoop 主服务器与工人） -* 接受新作业（作业流程最多可处理 256 个步骤） +* 用于开发和初级生产系统的 Linux +* 带 ZFS 的 Solaris 10 +* 码头 +* 索尔 +* 记忆快取 +* Apache QPID +* 质量体系 +* 剃刀木偶 +* Perl，Python +* 纳吉奥斯 +* Perforce，Git，Subversion -通过使用锁定避免了竞争情况。 默认情况下，在支持一致性的区域（美国西部）中使用 S3 **实施锁定。 作业使用有关作业名称和群集类型的信息写入特定的 S3 密钥。 如果发生故障，锁定可能会超时，从而使其他作业或作业终止者可以收回作业流。** +## 硬件/软件架构 -作业流终止由 cron 作业处理，该作业每 5 分钟运行一次，检查是否有闲置的作业流即将达到 **每小时的费用，并终止它们** 。 这样可以确保从不共享工作流的最坏情况不会比默认情况下代价高。 +### 登录到 salesforce.com 服务 -为了进一步提高作业流的利用率，作业可以等待预定时间，以找到可以重用的作业流。 例如，对于开发作业， mrjobs wi ll 尝试在开始新作业之前先寻找 30 秒钟的空闲作业流。 在生产中，没有到严格期限的工作可能会将等待时间设置为几个小时。 +我们维护一个服务器池来处理所有实例的登录流量。 来自许多（但不是全部）实例的少数服务器接受登录请求，并将会话重定向到用户的家庭实例。 当您通过 login.salesforce.com 登录时，会发生这种情况。 -我们估计通过使用工作流池 可以节省大约 **10％的成本。 从开发人员的角度来看到，这种节省成本几乎是免费的：通过设置一些配置设置，这些更改无需开发人员的任何操作即可生效。 实际上，我们看到了一个附带好处：迭代 ve 作业的开发速度大大加快，因为修改后的 MapReduce 作业的后续运行可以重用集群，并且消除了集群启动时间。** +客户流量始于我们的外部 DNS。 查找成功返回实例的 IP 地址后，标准 Internet 路由会将其定向到适当的数据中心。 -## 预留实例 +一旦流量进入该数据中心中的网络，它将被定向到该 IP 所在的负载平衡器对。 我们所有面向 Internet 的 IP 都是在一对主用/备用负载均衡器上配置的 VIP。 -默认情况下， AWS 每机器小时收费，但它提供了其他一些可以降低成本的购买选项。 [预留实例](http://aws.amazon.com/ec2/reserved-instances/) 是更直接的选择之一：先付钱，再收取每小时较低的每小时费用。 在将 AWS 价格与购买服务器进行比较时，我鼓励人们研究此选项：与购买服务器的资本成本和承诺相比，这是一个更为公平的比较。 +### 在实例内部 -![](img/c0f7f8cc00a9bc77a6026caa87b28c44.png) +负载平衡器将流量定向到给定实例的应用程序层。 在这一层，我们既提供标准网页流量，也提供我们的 API 流量。 API 流量占我们应用程序层总体服务的流量的 60％以上。 根据客户请求的需求，它将被定向到用于各种类型的后端处理的其他服务器层。 -什么时候比保留实例便宜一些 ll ？ 这取决于实例在一年中使用多少小时。 ve 上的图显示了使用不同的 reser ve 实例定价选项运行大型标准实例的成本：轻，中或重度使用。 您可以按需支付价格，即$ 0.26 /小时，但在大约 3000 小时（4 个月）后，支付$ 243 的 Reser ve 价格会变得更加便宜，仅需为预留的临时使用量支付$ 0.17 / hour 实例。 每年使用 3000 多个小时？ 然后是时候研究增加的使用计划了，“重载”是最大的前期，但每小时计划最低。 +### 核心应用 -您的公司应购买多少个预留实例？ 这取决于您的用法。 与其试图预测我们将要使用的 **wi ll** 多少，我们而是编写了一个工具来分析**过去的**使用情况并建议购买计划 **会 ve** 为我们节省最多的钱。 假设我们的未来使用率 ll 看起来与我们过去的使用情况相似，并且额外的工作和预测风险不值得相对多的支出。 ve 。 该工具的名称为 ll [EMRio](https://github.com/Yelp/EMRio) ，我们去年开放了来源。 它分析 EMR 的用法，并建议购买多少个预留实例，因为我们 ll 会生成一些漂亮的图形。 +核心应用程序层包含十到 40 个应用程序服务器，具体取决于实例。 每个服务器运行一个配置有多达 14 GiB 堆的 Hotspot JVM，具体取决于服务器硬件配置。 -![](img/0ab080d5917c053ed97f8311b519beb9.png) +批处理服务器负责在数据库层上运行计划的自动化过程。 例如，每周导出过程，该过程用于以单一存档文件格式导出客户数据作为备份形式。 -请务必注意，预留实例定价是一种计费方式。 也就是说，您并不是在物理上预订机器。 在月底，Amazon 仅查看您使用了多少实例小时，并将保留的实例费率应用于正在运行的任何实例，直到购买的实例数量为止。 +Salesforce.com 提供许多服务，包括基本和高级内容管理。 我们有一个内容搜索服务器和一个内容批处理服务器，用于管理内容应用程序层上的异步过程。 内容批处理服务器计划内容类型的处理，包括诸如某些文件类型的渲染预览和文件类型转换之类的功能。 -## 得到教训 +### 数据库 -**了解迁移到云解决方案** 时的权衡。 对于 Yelp，使用 AWS 的主要好处是通过降低协调成本和功能延迟来提高开发人员的生产力。 协调成本来自要求产品团队预测和请求系统团队的资源。 购买资源（无论是服务器机架还是网络容量）可能要花费数周的时间，并增加了功能启动的延迟。 延迟有其自身的相关成本，这些成本降低了道德水平（伟大的开发商（HTG5）至运输产品）以及项目之间的上下文切换。 AWS 的美元成本可能高于完全利用的，定制的内部解决方案的成本，但是您的想法是 ve 购买了更多的生产力。 +主要数据流发生在核心应用服务器层和数据库层之间。 从软件的角度来看，所有内容都通过数据库，因此数据库性能至关重要。 每个主要实例（例如 NA，AP 或 EU 实例）都使用 8 节点集群数据库层。 客户沙箱（例如 CS 实例）具有 4 节点集群数据库层。 -**专注于大赢家** ：可以逐步采用云技术-我们正在这样做！ Yelp 从 EMR 开始，因为这是我们最大的胜利。 离线处理具有尖峰的负载特性，通常不需要团队之间的协调，并且通过为开发人员提供实验的杠杆作用，可以使开发人员获得更高的生产率和。 为了更好地使用云，请集中精力一次解决最严重的瓶颈。 +由于 salesforce.com 是一个非常受数据库驱动的系统，因此减少数据库负载至关重要。 为了减少数据库层的负载，我们开发了 ACS-API Cursor Server。 这是对两个问题的解决方案，使我们能够显着提高核心数据库性能。 首先，我们曾经将游标存储在数据库中，但是删除操作会影响性能。 其次，在使用数据库表保存游标之后，DDL 开销变成了负面影响。 因此诞生了 ACS。 ACS 是在一对服务器上运行的游标缓存，提供了一种从数据库层卸载游标处理的方法。 -**建立在抽象** 之上：不要在 ll 上让所有人都了解云服务的细节，就像您不要在[数据中心。 记住您的权衡：目标是使开发人员的工作效率更高，而不是与流行语兼容。 如果开发人员不能像本地脚本那样轻松地使用它，那么拥有可扩展的，适应性强的或基础架构并不重要。 我们最喜欢的抽象是 [mrjob](https://github.com/Yelp/mrjob) ，它使我们可以在 Python 中编写和运行 MapReduce 作业。 在与 EMR 群集的本地计算机上运行作业是更改两个命令行参数的问题。 +### 搜索 -**建立策略和集成计划** ：旋转单个实例很容易，但是什么时候旋转机器？ 每天处理的日志很简单，但是如何可靠地将日志传输到 S3？ 已对 ll 的支持工程计划，使系统正常工作：数据集成，测试，备份，监视和警报。 Yelp 围绕 PII 制定了政策，将生产环境与开发区分开来，并使用 mrjob 软件包中的工具来监视失控的集群。 +我们的搜索层运行在商用 Linux 主机上，每台主机上都配备了 640 GiB PCI-E 闪存驱动器，该驱动器充当搜索请求的缓存层。 这些主机通过 NFS 文件系统从共享的 SAN 阵列中获取数据。 搜索索引存储在闪存驱动器上，以提高搜索吞吐量的性能。 -**稳定后优化** 。 有许多削减成本的方法，但是大多数方法都需要一定的复杂性和未来的灵活性。 在执行之前，请确保已使用了有效的抽象解决方案，以便评估的投资回报率。 Yelp 写了 EMRio 的数据，这是我们有 EMR 与 mrjob 结合使用的几个月的数据。 在看到我们实际使用 EMR 之前先进行优化，可能会甚至在黑暗中拍摄。 +搜索索引当前在转换服务器上进行，转换服务器通过光纤通道 SAN 从存储阵列安装 LUN。 这些 LUN 组成一个 QFS 文件系统，该文件系统允许单写程序但多读程序访问。 像大多数其他关键系统一样，我们以主动/被动方式运行它们，而被动节点则执行一些低优先级的搜索索引工作。 然后将其结果发送给活动伙伴以写入 QFS 文件系统。 -**评估 ROI** ：通过一些优化，成本评估非常简单：如果两个月前我们都保留实例，我们将节省多少？ 有些更困难：开发过程中的瓶颈是什么？云解决方案能否消除它们？ 容易或困难，但是在执行之前对其进行评估很重要。 优化之前的配置文件代码我想你是说什么？ 如果不是的话，我不希望您使用此分析器:) +当这些相同的 LUN 从一组在 SPARC 上运行 Solaris 10 的四个 NFS 服务器以只读方式装入时，就会发生转换。 然后，这些通过 SAN 安装的文件系统通过 NFS 共享到先前描述的搜索层。 + +### Fileforce + +我们维护一层提供对象存储的服务器，其概念与亚马逊的 S3 或 OpenStacks 的 Swift 项目相似。 Fileforce 这个系统是内部开发的，目的是减少数据库层的负载。 在引入 Fileforce 之前，所有二进制大对象（BLOB）都直接存储在数据库中。 Fileforce 联机后，所有大于 32 KiB 的 BLOB 都已迁移到其中。 小于 32 KiB 的 BLOB 继续存在于数据库中。 Fileforce 中的所有 BLOB 在数据库中都有一个引用，因此为了从备份中还原 Fileforce 数据，我们必须基于来自同一还原点的数据库备份来启动数据库实例。 + +Fileforce 包括捆绑程序功能，旨在减少 Fileforce 服务器上的磁盘查找负载。 如果数据库中存储了 100 个以上小于 32 KB 的对象，则将在应用服务器上运行一个进程，以将这些对象捆绑到一个文件中。 对捆绑文件的引用与捆绑中的查找偏移量一起保留在数据库中。 这类似于 Facebook 的 Haystack 图像存储系统，但内置于对象存储系统中。 + +### 支持 + +每个实例包含其他各种支持角色的服务器，例如调试应用程序服务器和应用程序层中的“ Hammer 测试”应用程序服务器，监视每个实例运行状况的中心服务器以及监视运行 Nagios 的服务器。 实例本身之外还包含支持服务器，例如存储管理，数据库管理，日志聚合，生产访问身份验证和其他功能。 ## 未来发展方向 -随着 Yelp 面向服务架构的发展，我们在脱机批处理中遇到了类似的瓶颈：资源协调，测试思路，在启动新功能之前预测使用情况。 因此，我们再次将目光投向了云，以为广告选择，搜索和数据提取等服务带来巨大的成功。 [期待 Yelp 工程博客上有关](http://engineeringblog.yelp.com/) [Asgard](http://netflix.github.io/asgard/) 未来的帖子用于构建和部署服务，评估 Python 框架 服务器到 RESTful API ，并构建抽象使其易于使用 ll 。 当然，如果您想帮助建立这个未来，请 [告诉我们！](http://www.yelp.com/careers) \ No newline at end of file +在数据库层，我们正在仔细检查数据存储系统的几种选项。 我们还在评估更高速度，更低延迟的互连，例如与现有数据库解决方案的集群互连的 Infiniband。 + +将来，我们希望使搜索主机能够进行所有读写操作。 我们正在为搜索索引推出 Apache Solr。 Solr 在我们现有的搜索主机上本地运行。 SAN，NFS 服务器和基于 SPARC 的索引器主机将全部消失，这将大大降低整个搜索层的复杂性。 + +我们的应用程序容器以前是 Resin，但在过去的一年中，我们一直在迁移到 Jetty。 我们还在对应用层硬件进行硬件更新，这将使 RAM 大小增加 30％-266％，并将 Sandy Bridge 处理器引入我们的堆栈。 + +我希望对 salesforce.com 技术架构和堆栈的概述能使您有趣且有益。 如果您对其他访客帖子感兴趣，请深入评论我们广泛的技术基础架构的其他部分。 谢谢阅读！ + +## 相关文章 + +* [Force.com 多租户架构的内部设计](http://www.infoq.com/presentations/SalesForce-Multi-Tenant-Architecture-Craig-Weissman) +* [Salesforce.com 架构](http://www.scribd.com/doc/145879736/Salesforce-com-Architecture) +* [单元架构](http://highscalability.com/blog/2012/5/9/cell-architectures.html) + +克劳德 + +感谢您抽出宝贵时间发布此信息。 我想对您如何使用 Solaris 和 ZFS 的更多信息非常感兴趣。 另外，如果必须全部这样做，是否会再次使用 QFS？ + +谢谢！ + +你们正在使用什么数据库？ + +此外，您提到了 Resin 和 Jetty，但在语言列表中没有提及 Java。 如果使用 Java，则正在使用 Java EE 的哪些部分？ + +他们没有提到它，但我可以想象它是神谕！ + +@MiddleAgedGeek + +他们使用 Oracle 或曾经使用 Oracle：http://www.dbms2.com/2012/06/26/is-salesforce-com-going-to-stick-with-oracle/ + +?？ 每秒有 24,000 个数据库事务（24k TPS）由多少台数据库机处理？ 还是每个数据库服务器处理多少 TPS？ +另外，我们是否在这里谈论纯 OLTP，OLAP 和混合液？ + +韦斯 + +FIleforce 在 Solaris 10 上运行，并且 Fileforce 数据存储在从镜像 VDEV 创建的 ZFS 池中。 （镜像 VDEV 的数量取决于服务器的型号。） + +我开始之前就选择了 QFS。 由于 salesforce.com 是 Sun 商店，并且搜索索引是在具有 SAN 存储的 SPARC 服务器上运行的，因此 QFS 是操作人员轻松实现高吞吐量，可靠的搜索索引文件系统的方式。 NFS 将其安装到搜索层的唯一原因是字节顺序问题。 如前所述，我们正在转向一种更易于推理，故障排除和支持的体系结构。 + +MiddleAgedGeek 和 ymo， + +请参阅 http://www.salesforce.com/company/news-press/press-releases/2013/06/130625.jsp，但我们确实使用 Oracle 数据库。 我们确实将其他数据存储用于不同的应用程序，但是上述核心数据库是 Oracle。 + +至于 Java，我们将 Jetty 用作容器，但是我们并未使用大多数核心 Java EE 功能。 Java 是我们内部构建的核心应用服务器的选择语言。 + +普热梅克 + +24000 个事务/秒是我们所有实例中高峰事务速率的平均值。 工作量主要是 OLTP，但是由于客户使用我们服务的方式，肯定有 OLAP 组件。 + +Claude, + +很棒的文章，感谢您在幕后进行的深入探寻，我期待更深入的潜水。 社区绝对可以从 SF 经验中学习。 + +1.3B 事务...是否还可以将其定义为单个客户端请求（网页浏览，ajax 请求）以及服务器的相应响应？ + +以后的文章建议对实例进行检测和监视。 数据量，脱机处理，什么类型的数据（http 日志，代码跟踪语句，度量标准等）。 + +嗨，克劳德， +感谢您分享此信息。 它真的很有帮助:-) + +彼得 + +是的，交易是对实例的应用层的请求/响应。 + +我也一定会通过这个建议。 我希望我的团队和其他人能看到更多类似的帖子。 我很高兴得到如此积极的回应。 谢谢你们！ + +惊人的帖子比我以前看到的要详细得多。 谢谢！ + +您今年要参加 Dreamforce 吗？ + +我使用该平台已有几年了，我一直想知道它是如何在后台运行的。 处理的数据量以及所有响应的响应速度简直太疯狂了。 + +很棒的帖子！ 感谢分享！ + +惊人的帖子， + +在注释部分提到的是 Oracle DB。 我猜一个实例中的群集。 您如何处理 HA 和 DR？ +例如，如何将 Appexchange 部署添加到不同的位置，例如在同一地点？ +是否存在共享实例，还是仅在所有实例中都复制了？ + +感谢您的评论。 + +有趣的文章-感谢分享。 您如何监视系统-性能和中断。 除了 Nagios 之外，您还使用其他监视工具吗？ Splunk，仙人掌等？ + +感谢您分享知识。 + +有许多服务器可为来自不同大陆的客户提供应用程序层服务。 + +您是否为每个新的注册客户端创建单独的数据库？ 或每个服务器的数据库有一定限制。 在数据库层部分找不到太多有关如何进行负载平衡的信息？ + +引人入胜的文章，并保持他们的到来。 我经常推测出幕后的魔力，这绝对是一本好书。 我希望类似的帖子将继续围绕这样的主题-它们不仅通过透明性建立信任-它们还有助于增进我们的集体工程知识。 谢谢！ + +嗨 +非常有启发性的文章！ +我想深入了解 Force.com 网站如何与整个事情联系在一起。 它托管在 DMZ 区域中吗？ +谢谢！ + +是否考虑过像事务服务器集群这样的单独层来减少会话负载？ 当然，我假设在数据库层而不是在应用程序服务器层运行存储过程。 + +您可以在以下位置找到 Salesforce.com 架构幻灯片：http://www.slideshare.net/gueste35dd2/salesforcecom-corporate-presentation-july-2009?next_slideshow=1-上面的划线链接要求我注册&，但要付费 。 + +很棒的架构概述！ 要求：这是 2 岁。 请分享过去两年中的体系结构和基础架构升级。 谢谢 ！ + +现在的堆栈是什么样的？ 它是如何成长的？ 什么是新的，什么掉了？ 软件堆栈必须已大修几次。 +从接收的客户数量来看，SFDC 的技术足迹必须每年增长 10-20％？ \ No newline at end of file diff --git a/docs/126.md b/docs/126.md index ed7bd10..e251bba 100644 --- a/docs/126.md +++ b/docs/126.md @@ -1,39 +1,116 @@ -# 缩放邮箱-在 6 周内从 0 到 100 万用户，每天 1 亿条消息 +# 扩大流量的设计决策 -> 原文： [http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html](http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html) +> 原文： [http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html) -![](img/7a05816f41b7aec7082ab24fd1746c24.png) +![](img/4d2c9efe35022d4b456cdd4f9c5e6185.png) -当大多数[早期博客文章](http://www.mailboxapp.com/blog/)处理着急于等待下载您产品的数十万用户的等待列表时，您就会知道您的产品运行良好。 这是一个令人羡慕的职位 [Mailbox](http://www.mailboxapp.com/) ，这是一个免费的移动电子邮件管理应用程序，在发布周期的早期就发现了自己。 +*Fashiolista.com 的创始人/ CTO Thierry Schellenbach 的来宾帖子，在 Twitter 和 Github 上关注@tschellenbach* -电子邮件还没有完成吗？ 显然不是。 邮箱[小组大约 14 人](http://www.mailboxapp.com/blog/?p=1#to-grow-even-faster-mailbox-is-joining-dropbox)，在短短的六个星期内，邮箱的规模扩大到了 100 万用户。 截至 4 月，他们每天交付超过 [1 亿条消息](http://www.mailboxapp.com/blog/?p=1#mailbox-now-available-without-the-wait)。 +[Fashiolista](http://www.fashiolista.com/) 最初是我们在侧面开发的一项业余爱好项目。 我们绝对不知道它将成长为最大的在线时尚社区之一。 整个第一个版本的开发花费了大约两周的时间，而我们的 feed 实现却非常简单。 自那时以来，我们已经走了很长一段路，我想分享我们在缩放 Feed 系统方面的经验。 -他们是如何做到的呢？ 邮箱工程负责人 [Sean Beausoleil](https://twitter.com/SeanBeaus) 在 readwrite.com 上进行了[内容丰富的采访，内容涉及邮箱如何计划扩展...](http://readwrite.com/2013/06/05/from-0-to-1-million-users-in-six-weeks-how-mailbox-planned-for-scale) +Feed 是 Pinterest，Instagram，Wanelo 和 Fashiolista 等许多大型初创公司的核心组成部分。 在 Fashiolista，供稿系统为[统一供稿](http://www.fashiolista.com/feed/?feed_type=F)，[聚合供稿](http://www.fashiolista.com/feed/?feed_type=A)和[通知](http://www.fashiolista.com/my_style/notification/)系统提供动力。 本文将说明在扩展 Feed 时遇到的麻烦以及与构建自己的解决方案有关的设计决策。 随着越来越多的应用程序依赖它们，了解这些供稿系统如何工作的基础至关重要。 -* **提前发信号通知**。 发行前的发布视频有助于引起人们的兴趣，但也使他们能够在发行前就及早评估兴趣。 从热烈的反响中，他们知道他们将需要迅速扩大规模。 -* **具有一些独特的**。 一般人可能不认为邮箱应用程序将是一个肥沃的产品空间。 有很多竞争，但大多数都是 la 脚。 邮箱具有许多创新想法，其基于待办事项列表的电子邮件处理方法和有效的 UI 刷卡操作。 这有助于产生大量的早期嗡嗡声。 -* **了解产品的性质**。 电子邮件对业务至关重要，而且资源很重，因此他们计划必须尽早扩展。 没有让我们把它弄出来的，然后计划扩大以后的态度。 -* **目标**。 当 Mailbox 发布时，它只能在 Gmail 和 iPhone 上使用，显然是针对精通大型技术的市场，它将对 Mailbox 的新收件箱方法开放。 -* **扩展**。 邮箱不是新的邮件服务。 它是现有高质量邮件系统 Gmail 的更好界面。 感谢 Google 提供了使之成为可能的 API。 用户可以采用邮箱，而不必担心电子邮件会丢失。 -* **调制和迭代**。 他们遵循系统设计中明确的最佳实践，即设计模块化组件并根据需要迭代这些组件。 -* **原型**。 构建了一个使用 IMAP 的测试系统，以识别生产负荷下的瓶颈。 这些测试发现了在生产中很难修复的问题。 这是初创公司通常会跳过的成熟而重要的步骤。 -* **将技术数量保持在最低水平**。 他们不想成为许多不同系统的专家，他们想专注于产品的开发。 -* **通过预订系统**限制新客户的价格。 早于 Mailbox 的预订系统可能比该产品更为知名。 它有助于通过感知到的稀缺来刺激需求，同时还可以控制客户，因此可以以可控的方式缓慢添加负载。 首先是人们使用系统的经验，而不是获得新用户。 天才四处。 -* **疯狂的虔诚**。 开发人员不断努力解决问题并改进系统。 专注于开发的早期阶段。 它可能是整个产品生命周期中效率最高的。 -* **注意用户的操作**。 响应于用户使用模式，对核心基础结构进行了调整，分片或删除。 -* **事情不可避免地会失败，需要修复。 即使进行测试，生产中也会出现问题。 这只是您大规模发布任何内容时可以期望的。 迭代并继续迭代。 当您了解有关系统，数据和用户的更多信息时，系统会变得更好。** -* **玩弄技术**。 如果您拥有旧技术，或者做出了不再起作用的堆栈或工艺选择，则将其替换为可行的东西。 花时间进行新技术选择。 然后与他们一起跑步。 -* **利用先前的产品**。 创建 iPhone 待办事项应用程序时使用的经验和代码直接用于引导邮箱。 这为他们提供了使应用程序从一开始就感觉很快所需的经验。 -* **云是经济高效的**。 非常适合资源有限且期限紧迫的初创企业。 云中的服务器[“执行诸如发送推送通知，尽快下载电子邮件以及处理“被延缓”的消息等操作。”](http://www.mailboxapp.com/blog/?p=2#were-ramping-up) -* **这是旅程**。 团队构建，设计和修复产品的阶段是必不可少的学习，可以在产品的整个生命周期中获得回报。 它不能真正短路或在堆栈选择方面步履蹒跚。 这是一个优秀的团队和产品形成一个整体的一部分。 -* [被 Dropbox](http://www.mailboxapp.com/blog/?p=1#mailbox-now-available-without-the-wait) 收购。 产品发布大约一个月后，Dropbox 购买了 Mailbox。 这个想法是 Dropbox 将帮助他们成长更快。 -* **传达**。 如果您查看 [Mailbox 的博客](http://www.mailboxapp.com/blog)，他们会非常详细地解释发生的事情，以使客户感到安心而不是困惑。 +此外，我们开源了 [Feedly](https://github.com/tschellenbach/Feedly) ，它是为 Feed 提供动力的 Python 模块。 在适用的情况下，我将参考如何使用它来快速构建自己的供稿解决方案。 -不幸的是，我们没有很多技术细节。 不难想象，邮箱的体系结构是高度并行且分片的，因为可以轻松地以无共享方式并行处理各个邮箱。 即使没有技术细节，它仍然是成功的云移动应用程序如何诞生的迷人肖像。 +## 提要简介 -## 相关文章 +缩放进纸系统的问题已被广泛讨论，但让我首先阐明基础知识。 该解决方案旨在使诸如 Facebook 新闻提要，Twitter 流或 [Fashiolista](http://www.fashiolista.com/) feed 之类的页面在高流量条件下工作。 所有这些系统的共同点在于，它们显示了您所关注的人的活动。 在我们的案例中，我们基于活动流的标准将活动对象基于[。 活动示例包括“ Thierry 在 Fashiolista 上的列表中添加了项目”或“ Tommaso 发了一条消息”。](http://activitystrea.ms/specs/atom/1.0/) -* [缩放 Pinterest-两年内每月从 0 到十亿的网页浏览量](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html) -* [邮箱如何在六周内扩展到一百万用户](http://readwrite.com/2013/06/05/from-0-to-1-million-users-in-six-weeks-how-mailbox-planned-for-scale) +There are two strategies for building feed systems: -因此，他们建立了一个 Gmail 客户端，并且没有猜测到该死的事情，队列只是一些非常明智的营销。 虽然所有尊重。 他们引起了轰动，很快就成功兑现了。 \ No newline at end of file +1. **拉**，读取时将在其中收集提要 + +2. **按下**，在写入期间所有提要均已预先计算。 + +大多数实际的实时应用程序将结合使用这两种方法。 将活动推向所有关注者的过程称为扇出。 + +## 历史&背景 + +Fashiolista 的 Feed 系统经历了三项重大的重新设计。 第一个版本在 PostgreSQL 数据库上工作，第二个版本在 Redis 上使用，第三个当前版本在 Cassandra 上运行。 为了让您了解这些解决方案何时以及为什么会失败，我将简要介绍一些历史。 + +### 第一部分-数据库 + +我们的第一个设置只是查询了一个 PostgreSQL 数据库，看起来像这样 + +选择* from love，其中 user_id 位于（...） + +最令人惊讶的是该系统的强大功能。 我们通过了 1M 的爱，并且继续发挥作用，在达到 5M 的爱之后，它仍然继续起作用。 我们敢打赌，经过一千万次恋爱，它会破裂，但它一直保持平稳运行。 进行了一些数据库调整，但是这个简单的系统在大约 1 亿个爱人和 1 百万个用户中占有优势。 大约在那时，该解决方案的性能开始波动。 通常，它可以继续工作，但是对于某些用户而言，延迟会飙升至数秒。 阅读了许多有关 feed 设计的文章之后，我们使用 Redis 构建了 Feedly 的第一个版本。 + +### 第二部分-Redis & Feedly + +我们的第二种方法是在 Redis 中为每个用户存储一个提要。 当您喜欢某件商品时，此活动就会散发给所有关注者。 我们使用了一些巧妙的技巧来保持较低的内存使用率，这将在下一部分中介绍。 Redis 真的很容易设置和维护。 我们使用 Nydus 在数台 Redis 机器上进行了分片，并使用 [Sentinel](http://redis.io/topics/sentinel) 进行自动故障转移。 （当前，我们建议使用 [Twemproxy](https://github.com/twitter/twemproxy) 代替 [Nydus](https://github.com/disqus/nydus) ） + +Redis was a good solution, but several reasons made us look for an alternative. Firstly we wanted to support multiple content types, which made falling back to the database harder and increased our storage requirements. In addition the database fallback we were still relying on became slower as our community grew. Both these problems could be addressed by storing more data in Redis, but doing so was prohibitively expensive. ### 第三部分-Cassandra & Feedly + +We briefly looked at [HBase](http://hbase.apache.org/), [DynamoDB](http://aws.amazon.com/dynamodb/) and [Cassandra 2.0](http://cassandra.apache.org/download/). Eventually we opted for Cassandra since it has few moving parts, is used by Instagram and is supported by [Datastax](http://www.datastax.com/). Fashiolista currently does a full push flow for the flat feed and a combination between push and pull for the aggregated feed. We store a maximum of 3600 activities in your feed, which currently takes up 2.12TB of storage. The fluctuations caused by high profile users are mitigated using priority queues, overcapacity and auto scaling. + +## 饲料设计 + +我认为我们的历史可以很好地代表其他公司所经历的过程。 当需要构建自己的供稿系统（希望使用 Feedly）时，需要考虑一些重要的设计决策。 + +### 1.归一化与归一化 + +There are two approaches you can choose here. The feed with the activities by people you follow either contains the ids of the activities (normalized) or the full activity (denormalized). + +仅存储 ID 会大大减少您的内存使用量。 但是，这也意味着每次加载 Feed 时都要再次访问数据存储。 要考虑的因素之一是非规范化时多久复制一次数据。 如果您要构建通知系统或新闻提要系统，则将产生巨大的变化。 对于通知，您通常会针对发生的每个操作通知 1 或 2 个用户。 但是，对于基于关注的 Feed 系统，该操作可能会复制到数千个关注者中。 + +此外，最佳选择实际上取决于您的存储后端。 使用 Redis，您需要注意内存使用情况。 另一方面，Cassandra 具有足够的存储空间，但是如果您对数据进行规范化，则很难使用。 + +对于通知供稿和基于 Cassandra 构建的供稿，我们建议对数据进行非规范化。 对于基于 Redis 的供稿，您希望最大程度地减少内存使用并使数据规范化。 [Feedly](https://github.com/tschellenbach/Feedly) 允许您选择自己喜欢的方法。 + +### 2.基于生产者的选择性扇出 + +In their paper [Yahoo’s Adam Silberstein et.al.](http://research.yahoo.com/files/sigmod278-silberstein.pdf ) argue for a selective approach for pushing to users feeds. A similar approach is currently used by [Twitter](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html ). The basic idea is that doing fan-outs for high profile users can cause a high and sudden load on your systems. This means you need a lot of spare capacity on standby to keep things real time (or be ok with waiting for autoscaling to kick in). In their paper they suggest reducing the load caused by these high profile users by selectively disabling fanouts. Twitter has apparently seen great performance improvements by disabling fanout for high profile users and instead loading their tweets during reads (pull). + +### 3.基于消费者的选择性扇出 + +Another possibility of selective fanouts is to only fan-out to your active users. (Say users who logged in during the last week). At Fashiolista we used a modified version of this idea, by storing the last 3600 activities for active users, but only 180 activities for inactive ones. After those 180 items we would fallback to the database. This setup slows down the experience for inactive users returning to your site, but can really reduce your memory usage and costs. + +Silberstein 等。 通过查看消费者和生产者对，使事情变得更有趣。 基本直觉是，在以下情况下，推送方法最有意义： + +Fortunately such a complex solution hasn’t been needed yet for Fashiolista. I’m curious at which scale you need such solutions. Be sure to let us know in the comments. + +### 4.优先事项 + +An alternative strategy is using different priorities for the fan-out tasks. You simply mark fan-outs to active users as high priority and fan-outs to inactive users as low priority. At Fashiolista we keep a higher buffer of capacity for the high priority cluster allowing us to cope with spikes. For the low priority cluster we rely on autoscaling and spot instances. In practice this means that less active user’s feeds may occasionally lag a few minutes behind. Using priorities reduces the impact high profile users have on system load. It doesn’t solve the problem, but greatly reduces the magnitude of the spikes. + +### 5\. Redis vs 卡桑德拉 + +Both Fashiolista and [Instagram](http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings) started out with Redis but eventually switched to Cassandra. I would recommend starting with Redis as it’s just so much easier to setup and maintain. + +但是，Redis 有一些限制。 您的所有数据都需要存储在 RAM 中，这最终会变得昂贵。 此外，Redis 中不支持分片。 这意味着您必须滚动自己的系统才能在节点之间进行分片。 （ [Twemproxy](https://github.com/twitter/twemproxy) 是一个很好的选择）。 在节点之间进行分片非常容易，但是在添加或删除节点时移动数据很麻烦。 您可以通过使用 Redis 作为缓存并回退到数据库来解决这些限制。 一旦难以回退到数据库，我会考虑从 Redis 迁移到 Cassandra。 + +Cassandra Python 生态系统仍在快速变化。 [CQLEngine](https://github.com/cqlengine/cqlengine) 和 [Python-Driver](https://github.com/datastax/python-driver) 都是出色的项目，但是它们需要一些[分叉](https://github.com/tbarbugli/cqlengine)才能一起工作。 如果您选择 Cassandra，则需要准备好花一些时间来了解 Cassandra 并为客户库做贡献。 + +## 结论 + +There are many factors to take into account when building your own feed solution. Which storage backend do you choose, how do you handle spikes in load caused by high profile users and to what extend do you denormalize your data? I hope this blogpost has provided you with some inspiration. + +[Feedly](https://github.com/tschellenbach/Feedly) 不会为您做出任何选择。 这是一个构建供稿系统的框架，由您自己决定哪种方法最适合您的用例。 有关 Feedly 的介绍，请阅读[自述文件](https://github.com/tschellenbach/Feedly)或本教程，以构建 [Pinterest](http://www.mellowmorning.com/2013/10/18/scalable-pinterest-tutorial-feedly-redis/) [样式](http://www.mellowmorning.com/2013/10/18/scalable-pinterest-tutorial-feedly-redis/) [应用程序](http://www.mellowmorning.com/2013/10/18/scalable-pinterest-tutorial-feedly-redis/)。 如果您尝试一下，请务必在遇到问题时通知我们。 + +请注意，只有在数据库中获得数百万个活动后，才需要解决此问题。 在 Fashiolista，简单的数据库解决方案使我们接触到了最初的 1 亿爱人和 100 万用户。 + +要了解有关 Feed 设计的更多信息，我强烈建议您阅读我们基于 Feedly 的一些文章： + + * [Yahoo Research Paper](http://research.yahoo.com/files/sigmod278-silberstein.pdf) +* [Twitter 2013](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) 基于 Redis，具有后备功能 +* [Instagram 上的 Cassandra](http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings) +* [Etsy Feed 缩放比例](http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture/) +* [Facebook 历史记录](http://www.infoq.com/presentations/Facebook-Software-Stack) +* [Django 项目，具有良好的命名约定。](http://justquick.github.com/django-activity-stream/) （但仅限数据库） +* [http://activitystrea.ms/specs/atom/1.0/](http://activitystrea.ms/specs/atom/1.0/) （演员，动词​​，宾语，目标） +* [有关最佳做法的 Quora 帖子](http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed?q=news+feeds) +* [Quora 扩展了社交网络供稿](http://www.quora.com/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed) +* [Redis 红宝石示例](http://web.archive.org/web/20130525202810/http://blog.waxman.me/how-to-build-a-fast-news-feed-in-redis) +* [FriendFeed 方法](http://backchannel.org/blog/friendfeed-schemaless-mysql) +* [Thoonk 设置](http://blog.thoonk.com/) +* [Twitter 的方法](http://www.slideshare.net/nkallen/q-con-3770885) + +很棒的文章！ 我经常想知道为什么要对大规模流立即做出扇出的决定。 [Collabinate](http://www.collabinate.com "Collabinate") 活动供稿 API 使用了 Rene Pickhardt 令人惊叹的 [Graphity 算法](http://www.rene-pickhardt.de/graphity-an-efficient-graph-model-for-retrieving-the-top-k-news-feeds-for-users-in-social-networks "Graphity")，这是一种图形数据库支持的 Feed 算法，具有极高的吞吐量，且无需重复。 它依靠图数据库通过 n 路合并（“拉”）完成所有操作。 我想谈谈您在原始实现中看到的延迟峰值，Redis 遇到的内存利用率问题以及现在的情况。 它将真正帮助我们的未来客户过渡到 Collabinate。 我会大声疾呼，以谈论有关 Feedly 的更多信息。 + +是否考虑使用 Postgresql 复制？ +一个写 DB 和多个从数据库为只读。 + +Feedly 开源软件包一直在快速增长。 目前，我们正在对 Feedly 背后的团队构建的托管解决方案进行 Beta 测试。 您可以在 https://getstream.io 上找到它 + +我一直想学习如何做到这一点！ 你是最好的！ 感谢您提供这个值得推荐的帖子。 \ No newline at end of file diff --git a/docs/127.md b/docs/127.md index eeb692c..5422445 100644 --- a/docs/127.md +++ b/docs/127.md @@ -1,74 +1,361 @@ -# GOV.UK-不是你父亲的书库 +# ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行 -> 原文： [http://highscalability.com/blog/2013/6/3/govuk-not-your-fathers-stack.html](http://highscalability.com/blog/2013/6/3/govuk-not-your-fathers-stack.html) +> 原文： [http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html) -![](img/0df17cabb1cc47fff35a9eaa7db8ac1b.png) +![](img/f404c63d80f6d9b153a926d699db0a09.png) -我不确定在启动时使用的堆栈 [GOV.UK 是什么样的。 也许有一些信使猫头鹰和许多蜘蛛网？ 但事实并非如此。 没那么多，所以我认为任何在自己的构架中寻找想法的组织都可以从他人的明智选择中学习一些东西。](http://digital.cabinetoffice.gov.uk/govuk-launch-colophon/) +ESPN 于 1978 年播出 [](http://en.wikipedia.org/wiki/History_of_ESPN)。 在过去的 30 多年中，请想一想我们所见过的奇观！ 当我想到 ESPN 时，我想到的是一个全球性品牌，这正是黄金时段的定义。 它显示在他们的统计数据中。 ESPN.com 的峰值是每秒 100,000 个请求。 毫无疑问，他们的巅峰赛事是世界杯。 但是，如果您知道 ESPN 仅由几百台服务器和数十名工程师提供支持，您会感到惊讶吗？ 我曾是。 -使用的技术的多样性令人惊讶。 他们使用“至少五种不同的编程语言，三种独立的数据库类型，两种版本的操作系统”。 有些人可能认为这是一个弱点，但他们认为这是一个优点： +您是否会惊讶于 ESPN 正在经历从企业架构到能够处理由于移动使用，个性化和服务导向的增长而驱动的 Web 规模负载的根本转变？ 再一次，我以为 ESPN 只是想看电视上的体育节目而感到惊讶。 ESPN 的意义远不止于此。 ESPN 正在成为一个运动平台。 -> 我们之所以经营如此多样化的生态系统，是因为我们专注于解决实际问题。 我们的首要任务是了解问题或我们正在解决的需求，然后为工作选择最佳工具。 如果我们将自己的需求限制在已有工具的基础上，那么我们就有可能无法以最佳方式解决用户最初的问题。 通过限制软件的多样性或在项目上执行严格的组织标准，就有可能沦为货物狂热者，在这种情况下，我们只需对所做的一切重复相同的模式和错误。 +ESPN 如何处理所有这些复杂性，责任，变更和负载？ 与 HighScalability 上的大多数其他配置文件不同。 ESPN 的迷人故事由 [Manny Pelarinos](http://www.linkedin.com/in/manole) ，ESPN 工程部高级总监在 InfoQ 演讲中讲述 [Architecture ESPN](http://www.infoq.com/presentations/Architecture-Scale-ESPN) 的规模。 来自 [Max Protect 的信息：ESPN.com 上的可伸缩性和缓存](http://www.infoq.com/presentations/Max-Protect-Scalability-and-Caching-at-ESPN) 也已纳入其中。 -博客文章[中概述了这种“无论如何都使用最佳工具”的政策。 在现代初创公司中找不到的唯一选择是使用 Skyscape 作为其云提供商。 我假设这与有关数据主权的法律问题有关，因为这是政府站点，但除此之外，这完全不符合标准的现代网络实践：监视，仪表板，连续发布，多语言持久性，分布式源代码控制等。 看到政府得到它。](http://digital.cabinetoffice.gov.uk/2013/06/03/benefits-of-diversity/) +在个人前计算机时代开始，ESPN 建立了创新的有线和卫星电视体育帝国。 从最初的 30 分钟计划中回顾了当天的运动，他们继续与 NBA， [USFL](http://en.wikipedia.org/wiki/United_States_Football_League) ，NHL 达成交易，后来成为大鱼 美国国家橄榄球联盟的所有运动。 -他们正在使用什么堆栈？ （这是直接副本，请随时阅读原始文档） +逐项体育交易的目的是从所有可能的来源中获取体育数据，以便 ESPN 可以报告比分，播放电影片段，并通常成为一站式购物，包括电视和后来的网络体育节目。 -### 前端： +这是一个需要理解的复杂系统。 他们在电视&广播，现场评分，编辑和发布，数字媒体，体育比分，网络和移动，个性化，幻想游戏等方面进行了大量工作，他们还希望将 API 访问权限扩展到第三方开发人员。 与大多数关于 HighScalability 的配置文件不同，ESPN 具有企业传统。 它是一个 Java Enterprise 堆栈，因此您将看到 Oracle 数据库，JMS 代理，Java Bean 和 Hibernate。 -* HTML / CSS / JS-在适当的地方使用 HTML5，重点放在可访问性上，并在哪里可以验证 -* 我们使用 [jQuery](http://en.wikipedia.org/wiki/Jquery) 作为我们的主要 JavaScript 库 -* 使用 [Nomensa 可访问媒体播放器](https://github.com/nomensa/Accessible-Media-Player)播放视频 -* 后端管理系统使用 [Twitter Bootstrap](http://twitter.github.com/bootstrap/) -* 我们使用 [SCSS](http://en.wikipedia.org/wiki/Scss) ，如前端工具包的[中所示](https://github.com/alphagov/govuk_frontend_toolkit) -* 我们已经使用 [A2-Type 进行字体制作](http://www.a2-type.co.uk/)。 +我们将学习的一些最重要的课程： -### 服务器的核心： +* **平台更改了所有内容** 。 ESPN 将自己视为内容提供商。 这些天的内容可以通过多种途径访问。 它可以在电视，ESPN.com 或移动设备上显示，但内容也正被越来越多的内部应用程序（例如 Fantasy Games）所占用。 他们还希望提供一个外部 API，以便开发人员可以在 ESPN 资源上构建。 ESPN 希望成为建立在体育内容平台上的围墙花园，该平台可以集中利用其对所有人的主要优势，这是对体育相关内容和数据的前所未有的访问。 ESPN 希望在体育领域做到这一点：Facebook 为社交服务，苹果为应用服务，谷歌为 AI 服务。 问题正在从企业架构过渡到基于 API 和服务的平台，这是一个艰难的转变。 他们可以做到。 他们正在这样做。 但这将很难。 -* 我们正在使用 [Skyscape](http://digital.cabinetoffice.gov.uk/2012/09/18/introducing-a-new-supplier-skyscape/) 中的[基础架构即服务](http://digital.cabinetoffice.gov.uk/2012/09/25/why-iaas/) -* 我们使用 [Akamai](http://en.wikipedia.org/wiki/Akamai_Technologies) 作为我们的内容分发网络 -* 我们的服务器正在运行 [Ubuntu GNU / Linux 10.04](http://en.wikipedia.org/wiki/Ubuntu_(operating_system)) ，我们希望尽快升级到 12.04。 -* 使用 PuppetDB 通过 [Puppet](http://en.wikipedia.org/wiki/Puppet_(software)) 管理服务器 -* Web 服务由 [nginx](http://en.wikipedia.org/wiki/Nginx) 处理，代理[独角兽](http://unicorn.bogomips.org/)用于我们的红宝石应用程序。 我们还使用 [gunicorn](http://gunicorn.org/) 来运行一些支持服务。 团队之一写了 [Unicorn Herder](https://github.com/alphagov/unicornherder) ，使 Unicorn 与[新贵](http://en.wikipedia.org/wiki/Upstart)保持良好的配合。 -* 我们内部使用 [haproxy](http://haproxy.1wt.eu/) 进行内部负载平衡，并使用 [Varnish](http://en.wikipedia.org/wiki/Varnish_(software)) 缓存请求 +* **网络规模改变了所有内容** 。 如今，许多 Web 属性都使用 Java 作为其标准的后端开发环境，但是在 Java Enterprise 时代成长的 ESPN.com 完全采用了规范的 Enterprise 体系结构。 而且效果很好。 直到出现了从相对可预测的 ESPN.com 经历的企业级负载到由高移动流量，大规模定制和平台问题所主导的世界的阶段过渡。 我们在本机 Web 属性中看到的许多体系结构选择现在必须由 ESPN.com 使用。 -### 重定向： +* **个性化更改了所有内容** 。 当为每个用户动态构造所有内容，并且必须在每种访问方式（.com，手机，电视）上跟随您时，曾经保存数据库的缓存现在变得不那么有用了。 -* nginx 值得一提，因为[让我们进行所有重定向](http://digital.cabinetoffice.gov.uk/2012/10/11/no-link-left-behind/) -* 我们正在使用 [perl](http://www.perl.org/) 来管理和测试重定向 -* 有一些 [php](http://en.wikipedia.org/wiki/Php) 可将有用的链接添加到已淘汰 DirectGov 和 Businesslink 内容的“已消失”页面 -* [node.js](http://en.wikipedia.org/wiki/Node.js) 被用来构建用于查看重定向的并排浏览器 +* **Mobile 改变了所有内容** 。 它给您的架构带来无处不在的压力。 在只有网络架构的情况下，这没什么大不了的，因为用户减少了，服务器也减少了。 在移动用户和服务器数量如此之多的移动时代，这种架构决定产生了巨大的变化。 -### 应用范围： +* **伙伴关系就是力量** 。 ESPN 可以创建一个有围墙的花园，因为多年来，他们建立了合作伙伴关系，使他们可以特别访问其他人没有的数据。 最好先做到最好。 NFL 和 MLB 之类的个人体育项目试图通过自己的网络来获取这一价值，这在某种程度上削弱了这一优势，但是每个人都需要相处的力量，如果 ESPN 能够执行的话，这将使他们成为强大的平台竞争者 。 -* 我们的大多数应用程序都是基于 [ruby​​](http://en.wikipedia.org/wiki/Ruby_(programming_language)) 编写的，基于 [Ruby on Rails](http://en.wikipedia.org/wiki/Ruby_on_rails) 或 [Sinatra](http://en.wikipedia.org/wiki/Sinatra_(software)) 。 -* 一些组件是用 [Scala](http://en.wikipedia.org/wiki/Scala_(programming_language)) 编写的，并基于 [Play 2.0](http://www.playframework.org/) 构建 -* 我们正在运行 MySociety 中的 [Mapit，它基于](http://mapit.mysociety.org/) [Django](http://en.wikipedia.org/wiki/Django_(web_framework)) 构建 +## 统计信息 -### 数据库和其他存储： +* 互联网上排名第一的体育网站。 所有网站的前 10 名。 18-54 岁男性中排名第五的网站（Facebook，Google，Microsoft，Yahoo 更大）。 -* 对于大多数系统，我们使用 [MongoDB](http://en.wikipedia.org/wiki/Mongodb) ，一些应用程序也使用 [MySQL](http://en.wikipedia.org/wiki/Mysql) 。 [Mapit 和 Puppet 使用 PostgreSQL](http://en.wikipedia.org/wiki/Postgresql) 。 -* 尽管 [solr](http://en.wikipedia.org/wiki/Solr) 目前是 Need-o-tron 的后端，但该网站上的大多数搜索是由 Elasticsearch 支持的[。](http://digital.cabinetoffice.gov.uk/2012/08/03/from-solr-to-elasticsearch/) -* 一些事件驱动系统使用 [RabbitMQ](http://en.wikipedia.org/wiki/Rabbitmq) +* 仅由几百台服务器供电。 -### 监视，管理和警报： +* 有几十个服务站点的主要部分，例如首页服务。 -* 我们使用 [statsd](https://github.com/etsy/statsd) 从我们的应用中收集指标 -* 我们使用 [logstash](http://logstash.net/) 收集日志 -* 我们使用[神经节](http://en.wikipedia.org/wiki/Ganglia_(software))监视系统 -* [石墨](http://graphite.wikidot.com/start)帮助我们制作许多图表来了解发生的情况 -* [Nagios](http://en.wikipedia.org/wiki/Nagios) 告诉我们是否需要对任何数据采取行动 +* 只有几十名工程师。 -### 配套工具： +* 峰值为每秒 100,000 个请求。 高峰赛事是世界杯。 -* 我们所有的代码都经过 [Jenkins](http://en.wikipedia.org/wiki/Jenkins_(software)) 的测试，我们也将其部署到服务器上 -* 我们通过 Google Analytics（分析）跟踪网站的使用情况，并大量使用其 API 来构建信息中心 -* 我们有时会使用 [New Relic RPM](http://en.wikipedia.org/wiki/New_Relic) 进行性能评估 -* DNS 由 ja.net / Dyn 托管 -* 通过 [Amazon SES](http://aws.amazon.com/ses/) 发送的电子邮件（内部警报） -* 使用 [FontForge](http://fontforge.org/) 和 [FontTools](http://sourceforge.net/projects/fonttools/) 进行字体处理和准备 -* 我们使用 Google Apps，Pivotal Tracker 和 Campfire 保持联系并保持联系 -* Github 帮助我们管理和讨论我们的代码 -* Zendesk 使反馈保持畅通 -* 我们使用 [jekyll](http://jekyllrb.com/) & [heroku](http://www.heroku.com/) 进行一些原型设计 -* 我们建立了各种内部仪表板。 它们是我们的游乐场，您可以发现它们是用 Ruby， [Clojure，Node.JS 和 PHP](http://digital.cabinetoffice.gov.uk/2012/02/08/radiating-information/) 的混合物编写的 \ No newline at end of file +* 体育专用数据的大小为千兆字节。 + +## 堆栈 + +* 基于 Java。 + +* Oracle 数据库， + +* AQ 流 + +* 消息代理 + +* WebSphere MQ + +* 有趣的是将地面人员集成为数据源和自动提要 + +* JMS Broker + +* Microsoft SQL Server + +* 休眠 + +* Ehcache + +* 我们 + +* IBM eXtreme Scale + +* 服装 + +* F5 负载均衡器 + +## 架构 + +![](img/2dd46c5fd8c738fa425d80d3174bf74d.png) + +* 十年前与 Paul Allen 的一家创业公司 Starwave 一起成立，因此他们在 Microsoft 技术方面大受好评，但选择了 Java。 Java 还很年轻，因此他们必须自己独立完成大部分工作。 该站点已发展了 100 多次和 100 多次迭代。 + +* 通过更多服务进行了扩展，例如 Watch ESPN 是一项新的专用服务。 在数百台服务器上部署了 100 多个逻辑数据库和 200 多个不同的应用程序。 + +* ESPN.com 的目标是为体育迷随时随地在任何设备上提供准确及时的数据，并访问更深的内容。 分数，统计数据和更深层次的内容必须准确，即时。 就像电视一样，没有中断。 + +* 不要认为自己是一家技术公司。 他们是媒体和内容提供商。 由迪士尼拥有，未公开交易。 + +* 数字属性：ESPN.com，奇幻游戏，移动设备（WAP，iPad，iPhone 等），WatchESPN（手机上的手表电缆），ESPN Ocho（物品，W，HS 等）。 不同的体系结构和服务为每个属性提供动力。 ESPN.com 是本演讲的主要内容。 + +* 例如波士顿和纽约的不同本地站点。 庞大的编辑团队会为每个本地站点提供本地版本，因此不同的粉丝群体会在游戏中产生不同的倾向。 + +* 以低硬件占用空间处理高负载的关键是复杂的页面和片段缓存系统。 实时更新（例如得分，统计信息，时间表）具有不同的缓存系统。 个性化也有其自己的缓存系统。 + +* 开发人员通常没有登录生产机器的权限。 + +## 架构是围绕应用程序和数据库组织的 + +* 数十个逻辑数据库。 MLB，NFL，NHL 等的数据库，以及每个数据库的应用程序，包括诸如 Frontpage 的更抽象的服务，用于为主要网站提供服务。 + + * 进程隔离。 如果部署了错误的代码，则不会破坏网站的其他部分。 + + * 不是整体架构，有不同的系统用于不同的运动。 + + * 历史上原始的 SOA 模型。 Frontpage 对返回 XML 的不同服务进行了多个 HTTP 调用，并且调用者对其所需的内容进行了解析。 不同服务之间的大量互连。 + + * Frontpage 计分板具有来自所有不同联赛的所有不同分数。 每种运动都有单独的应用程序。 单击 NHL 会通过负载均衡器点击 [VIP](http://en.wikipedia.org/wiki/Virtual_IP_address) ，将您带到 NHL 应用程序。 + + * 有一个首页应用程序，可通过调用其他服务来服务首页小部件。 + + * 应用程序服务。 数据库前面是 Web 应用程序服务器，其中包含这项运动的所有业务逻辑。 + + * 通常一项运动只有一项应用程序服务。 + + * 应用程序已集群，因此集群中有 6-10 个应用程序实例，因此它们可以水平扩展 + + * 例如，当足球比赛是季节性的时候，根据季节需求的指示，应用实例的数量将增加，而应用实例的数量将减少。 + + * 迪士尼数据中心具有一些弹性功能，但希望亚马逊在此领域进行改进。 + +* 所有提要都流入体育数据存储库（SDR）。 + + * 一个非常大的 Oracle 数据库。 + + * 您在.com 网站上看到的相同统计信息与在电视和 Sports Center 上的某些面板上用于创建最低报价的统计信息相同。 + + * 使用 Web 服务呼叫的电视访问统计信息。 + + * 电视&广播不需要以与其他属性相同的方式进行缩放，因此它们可以直接使用 Oracle 数据库中的数据。 + + * Oracle AQ 流用于在 Oracle 端分发消息。 + + * 消息网关将消息分发到具有自己的 JMS 代理的数字媒体端。 + + * 位于康涅狄格州布里斯托尔。 + + * 像 ESPN.com 这样的数字媒体，都以创建提要和标准化消息以供企业内部消费的系统为前端。 + + * JMS Broker（WebSphere MQ）用于分发消息。 + + * 位于拉斯维加斯数据中心。 + + * .com 和 TV 位于不同的数据中心。 两个数据中心之间的延迟为 80 毫秒。 这两个 JMS 代理经过高度优化，可以尽快发送更新。 + + * PubSub 是 JMS 代理之上的体系结构。 应用程序侦听不同的主题，从队列中读取消息，解组到 JavaBeans 中，保留到数据库中，然后将数据直接推送到 Web 应用程序服务器中。 + +## 统计资料从何而来？ （数据提取） + +* 每个数据库都有一个批处理或提要处理服务，负责更新所有统计信息，进度表，排名，得分等。 + +* 大多数数据来自第三方供应商或职业联赛本身。 + +* 直接进纸。 例如，他们与 MLB 有合作关系，数据直接从 MLB 发送。 使它们比其他服务具有更大的延迟优势。 + +* 体育馆供稿。 音高效果（音高位置）数据是从体育场发送的。 + +* 手动进纸。 ESPN 人员对游戏进行评分并手动将数据输入系统。 + + * 大学橄榄球没有统计信息供您查看，因此观看者可以输入数据。 + + * 故障转移。 如果自动馈送发生故障，它还可以用作备用故障转移系统。 出现问题时，可以手动接管游戏。 + +* 几乎每夜都有来自第三方的“官方”统计数据被覆盖。 有很多工具和系统可以确保提要正确，但更正后的数据会在晚上出现。 + +* 除非游戏正在进行，否则消息速率相对较低。 复杂，因为所有游戏事件都需要按顺序处理。 + +* 与.com 相同的统计信息也可以为 TV 供电，但是访问方式不同。 + +## 应用程序服务 + +* 服务之间通过本地服务，远程 EJB 或 REST 进行直接呼叫，从而彼此对话。 + +* 数据中心内的首选模式是具有复杂缓存层的 EJB。 从 Java 客户端访问。 + +* 对于 REST 服务，有一个基于 TTL 的简单缓存层。 可从 PHP，Javascript 等访问。 + +* 在数字媒体方面，他们使用 Microsoft SQL Server，并在该 Java 应用程序服务器之上。 之所以进行扩展，是因为他们尝试不接触数据库。 它们会缓存所有内容，因此不会命中数据库。 + +## 应用程序级别缓存 + +* 从历史上看，Web 应用程序中的对象缓存会保留表对象的内存哈希图。 W 将游戏永久缓存在哈希图中，直到游戏填满或通过数据库触发器到期为止。 缓存是按应用程序服务器复制的。 + +* 这种方法简单易行，在移动设备激增之前就可以使用，因为相对容易预测为 NFL 流量等服务所需的服务器数量。由于移动流量如此之大，过期消息不断涌现。 例如，随着游戏统计信息的更新，到期时间将过去，并且所有服务器都要求更新游戏分数。 现在将推送更改而不是过期。 + +## 页面缓存框架 + +* 高性能页面和片段缓存。 + +* 缓存是另一种称为 Stout 的自有技术。 将 IIS Web 服务器与 ISAPI 页面缓存插件一起使用。 用 C ++编写。 在便宜的低端硬件上运行，因此极具成本效益。 仅使用 TTL 缓存。 每秒查看 1000 多个请求。 应用层每秒收到 100 多个请求。 应用程序层具有自己的缓存层。 数十个 Stout 服务器保护应用程序层。 应用服务器层保护数据库层，因此无需横向扩展数据库。 粗壮的应用程序服务器从循环中退出。 看清漆似乎更快。 + +* 缓存为王。 该体系结构最重要的部分是页面缓存层。 尽可能大量使用页面缓存。 + +* 每个 URI，基于 TTL 的到期时间。 透明地与负载平衡器进行对话，并说对于某些 URI，我们希望缓存一定的时间。 + +* 最高精度是低 TTL，并且会阻塞直到它返回数据。 访问速度最慢。 例如，用于记分板数据。 + +* 最低精度是指高 TTL 不会阻塞，它会返回脏数据。 最快的访问速度，用于不经常更新的数据。 例如，用于计划数据。 + +* 编辑内容和其他不经常更改的内容可以使用更长的 TTL 进行缓存。 + +* 自动降级无响应的服务器。 + +* 基于 TTL 的缓存不能很好地工作，因为它会导致频繁访问数据库。 想象一下，数十台服务器上的 TTL 为几秒钟，那么效果不佳。 + +* 在每个运动的高峰时间每秒节省数百万的数据库访问。 巨大的胜利。 当只有网络时，这一切都无关紧要，因为用户减少了，服务器也减少了。 在拥有更多用户和 50 多个服务器的移动时代，这些架构决定将产生巨大的变化。 + +* 他们的自定义解决方案的优势在于它可以在便宜/低端的硬件上运行。 + + * 负载均衡器的十万个请求 + + * 实际应用服务器的请求数为 100 + + * 10 个 MLB 服务器，而不是 50 个意味着节省大量资金 + +## 通用对象模型 + +* 尽管他们有许多不同的数据库对应不同的运动，但在它们前面却有一个共同的对象模型。 在通用模型中尽可能多地添加跨运动项目通用的内容。 + +* 每个游戏都有一队，通常两队。 奥林匹克运动有竞争者。 通用供稿中的代码是相同的，它允许进行强大的操作，例如为我获取所有体育页面的所有比赛成绩，而不论运动如何。 + +* 在特定运动中，他们具有特定运动模型。 适用于 NFL，MLB 等。当他们详细了解某项运动的今天页面时，将使用运动专用模型。 + +* 一层隐藏了复杂性，然后在必要时退回特定于运动的模型。 + +## 休眠 + +* TTL 缓存不起作用，因为数据在一天中并不经常更改，而在游戏中则经常更改。 + +* 很少是按标识查找的，它们大多是按查询查找的，例如给我提供整周的比赛次数，以便显示时间表，或者向我显示特定团队正在比赛的所有比赛。 数以百计的查询。 + +* 首先易于使用。 当事情变得更加复杂或您需要最佳性能时，很难有效地使用它。 + +* Ehcache 用作实体更新的二级缓存，效果很好。 + +* Hibernate 查询缓存机制不足，因此它们构建了 JPA 查询复制器。 + + * 状态经常更改（例如游戏得分），但是每个人的更改都是相同的。 不适用于个性化数据或幻想，不适用于所有用户的更改。 + + * 在获取更新的过程中，他们在实体端的侦听器使用规则引擎监视他们关心的所有更新。 根据更新内容过滤掉查询。 自特定时间开始，针对特定游戏的更新不应触发要求数据的查询。 该查询将重新运行并推出集群，因此所有用户都将得到更新，这将使数据库不堪重负。 + +## 内容管理系统 + +* UI 不太好，重点是性能和规模。 + +* 两个子系统：CMS 和 DCS（动态内容系统）。 + +* CMS 编辑人员。 高度优化的查询。 针对更改故事的用户的优化 UI。 完整的关系数据库模型（SQL Server）。 只有几百个编辑器，因此它不需要水平缩放。 + +* DCS 使用 SQL Server，但已被规范化并存储为 Blob 类型。 检索速度很快。 编辑的数据在 CMS 中继续。 发布文章时，内容将序列化并放入 DCS。 DCS 是 10 个可以水平扩展的服务器的集群。 + +* 所有 76 个服务（MLB，NFL 等）都有一个知道如何与 DCS 对话的插件。 该插件还具有一个缓存。 因此，在发布时，将过期发送给每个客户端，以便它将从 DCS 中获取新内容。 + +* 由迪士尼 Internet Group 构建的模板引擎。 迪士尼拥有 ABC 和 ESPN。 十年前建立了称为 T 的语言。高性能。 比 JSF 更像 JSP。 多年来已经建立了十万个模板。 + +* 硬件方面便宜，因此它们必须在软件方面高效，这就是为什么他们没有迁移到其他速度较慢的模板系统的原因。 + +## 实时比分（ESPN.com） + +* 大多数内容都不会很快更新。 编辑内容无法快速更新。 对于分数，他们希望获得最快的分数，因此前端和后端的处理方式有所不同。 + +* 主供稿模板，其中包含游戏的所有数据。 一个进程轮询模板以获取更新，并将更改放入数据库的快照表中。 一切都被称为 Caster 的东西。 这是一种自定义技术，就像网络套接字存在之前的网络套接字一样。 从前端到后端有一个开放的套接字连接，这是大量的 Caster 服务器集群，并且更新通过该流传输。 前端有一个 Flash 连接器。 高端服务器除了管理与前端闪存连接器的连接外，什么也不做。 它可以进行 10 万多个并发的开放套接字连接。 每次更新快照时，都会通过适当的连接发送快照。 页面上运行的 JavaScript 读取更新并将其显示在页面上。 + +* Flash 连接器会每隔 30 或 60 秒降级为轮询。 糟糕的带宽使用率。 将网络套接字视为替换项。 + +## 个性化设置 + +* 个性化就是告诉他们您最喜欢的东西是什么：体育，球员，球队，幻想数据。 这些是您特有的。 + +* 与 ESPN.com 的其余部分完全不同，并且有很多特定要求。 + +* 难以缓存，因为与其他缓存方案一样，它是 1-1 而不是 1。 并且数据必须在任何地方（.com，手机，电视）都跟随您 + +* 有很多个性化数据。 超过 500GB。 无法适应单个 JVM 或数据库，而该 JVM 或数据库无法按每秒 10 万个请求的吞吐量进行扩展。 + +* 使用 IBM eXtreme Scale 构建数据网格。 + + * 这是一个分布式的内存哈希图。 购买了 7 台服务器，每台服务器具有 96GB 的 RAM。 软件自动平衡数据并将其分区到 JVM。 + + * JVM 的最大问题是垃圾收集，因此每个服务器上运行 100 个 JVM，以最大程度地减少垃圾收集，并且软件会自动分片所有内容。 + + * 仅存储您独有的东西。 如果您是洋基队的粉丝，他们只是存储洋基队的 ID，而不是存储有关洋基队的所有数据。 + + * eXtreme Scale 的设置比 Coherence 困难，但价格便宜，并且它们从 IBM 获得的支持比 Oracle 多。 + +* Composer 系统知道如何与 NFL 和 MLB 等所有服务进行对话，并且知道如何与网格进行对话。 因此，要构建个性化页面，他们将转到网格并为您喜欢的团队提供正确的服务，并以 JSON 供稿的形式构建时间表，得分，幻想数据，专栏作家等。 在客户端，数据被组装。 借助 6 个用于 Composer 的商用服务器，每秒可处理数以万计的请求。 + +## 奇幻游戏 + +* 非常不同的用例。 幻想数据是根据实际统计数据计算得出的，然后转换为“组合”数据，因此它们具有不同的提取过程。 + +## API + +* 用于编辑内容的 API。 数据权利很棘手，但它们拥有内容，因此就是发布的内容。 + +* 他们面临的最大问题之一是招募新人并入职。 拥有文档和一致的 API 可以在防火墙之外为开发人员提供 API 的帮助，但在内部却可以帮助，因为它更易于构建应用程序。 + +* EJB 层的一些技巧无法应用到 API，因此尚未完全弄清。 + +* 弄清楚 API 很困难。 开发人员希望一次调用所有数据。 但是他们倾向于更细粒度的 API，这将需要更多的调用和开发人员的更多工作。 + +* Mashery 用于通过 TTL 缓存保护 API。 不同级别的轮询。 外部用户每分钟只能处理这么多请求。 在内部，限制不太严格。 + +* 最复杂的运动是足球，因为有这么多的提要提供商必须与他们合作来获取数据。 特别提款权团队将所有提要标准化为足球提要。 如果 Feed 出现问题，他们可以接管 Feed 并将其手动添加到系统中。 + +## 特殊效果 + +中的 [ESPN 新兴技术对高分辨率图像](http://on-demand.gputechconf.com/gtc/2013/presentations/S3487-ESPN-NVIDIA-GPUs-High-Res-Imagery.pdf) 的 NVIDIA GPU 解决方案的使用。 细节不多，因此这些基本上只是幻灯片中的要点，但这很酷，看上去就像是屏幕上的魔术。 + +* ESPN 是高级实时图形的创新者，他们将 GPU 用于高价值功能，例如 Huck-O-Meter，HRD Ball Track，Snap Zoom，Ref Mics，Sky Cam，Ultra-Mo，播放器跟踪， 1st &十号线，K 区，获得艾美奖的 EA 虚拟剧本以及更多其他东西 + +* 系统中的每个 GPU 分为输入，输出，输入/输出或计算引擎 + +* 所有 GPU 均可通过 CUDA 进行对等访问 + +* 可以将多个输入卡和输出卡分配给 GPU + +* 硬件抽象层允许通过 gpuDirect 来自多个制造商的视频 I / O 硬件 + +* 每个 GPU 管道均可处理输入和输出的独特视频格式 + +## 未来 + +* 如有必要，对于具有运动专用扩展名的所有数据都具有通用的 API 。 + +* 移至缓存推送模型 （不会过期）。 借助移动和水平模型以及越来越多的服务器，越来越多的服务器将通过数据库进行更新。 由于他们没有庞大的数据库，因此这成为了瓶颈。 如果在 NFL 周日停止更新分数，那将是不好的一天。 + + * 随着数据的传入，将其整理成通用的对象模型格式。 它异步保存到数据库，也异步推送到集群的其余部分。 例如，当发生某些更改时，源服务器将直接发送给使用者，而不是 6 台服务器，而无需将其发送到数据库。 + +* 更松散耦合的服务 。 通过 Java 远程处理，在本地（相同的 JVM）。 + +* 为所有运动创建一项服务 。 + +* 利用泛型和代码生成 加快转换其余部分的过程。 + +* 到处缓存 以保护所有组件免受负载的影响。 + +* 提供更多个性化的内容 ，并随处可见（.com，手机，电视）。 + +## 经验教训 + +* **缓存推送模型**。 随着数据的传入，异步地保留到数据库中，并且也异步地推送到集群的其余部分。 更改被直接推送给使用者，这意味着使用者可以踩踏数据库以获取新的更改。 在可预测资源的更静态世界中不是必需的，而是在移动世界中可伸缩性的关键。 + +* **足够好就足够** 。 当您刚开始使用某项技术时，您必须自己构建很多东西，以后随着新的更好的代码的出现，它们看起来会很愚蠢。 但是您需要编码并使其正常工作，因此足够了。 + +* **您可以做一些** 。 您想到了 ESPN，又想到了行业领导者。 但是，ESPN 很少使用计算资源，也很少使用开发人员来创建高价值，高度可见的系统。 他们考虑效率。 一家拥有网络遗产的公司可能只是以机器便宜为由添加了所需的机器，而 ESPN 实际上考虑节省金钱以获取利润。 一个奇怪的概念。 + +* **了解您的听众** 。 决策是由目标决定的。 随处可见的设备，快速准确的数据，广泛的覆盖范围和高可用性。 这些价值反映在体系结构和决策过程中。 + +* **手动故障转移** 。 他们的系统架构的一个有趣的方面是，既包括手动输入游戏数据，又包括自动订阅源失败时的手动故障转移策略。 大多数人可能不会考虑将其作为一种选择，但是它对实现拥有快速准确数据的目标高度奉献。 + +* **针对不同用例的定制系统** 。 他们让不同运动和服务的需求来驱动体系结构。 这样就可以进行并行开发并完成工作。 例如，他们建立了一个查询缓存机制，专门针对游戏更新和发行进行了优化，因为这是他们的事。 + +* **使不同的事物看起来相同** 。 尽管千变万化的架构方法在巨大的变化和发展中非常有用，但当您想要创建通用的 API 服务层或响应移动或个性化等压力因素而进行系统范围的优化时，它确实很烂。 因此，相反的作用是建立通用的体系结构，通用的数据模型，然后在必要时退回特定类型的模型。 + +* **缓存以保护数据库** 。 根本不是一个新主意，但这是一个对 ESPN 来说非常有效的核心可伸缩性策略。 这使他们不必在数据库层上投入大量资金。 但是，个性化，这是未来的潮流，是缓存破坏者。 + +* **一致性可帮助所有开发人员** 。 拥有文档和一致的 API 可以在防火墙之外为开发人员提供 API，但在内部也可以提供帮助，因为构建应用程序更加容易。 + +很棒的帖子，关于 ESPN 从未想过/知道的东西，在网络/数据库相关技术上发挥了如此重要的作用。 不过有一个问题。 如今，在大数据和网络规模方面存在很多障碍。 您提到它们主要依赖于 Oracle 数据库以及 MS SQL Server 数据库上的某些其他服务。 关于 NoSQL，网络规模以及传统 RDBMS 如何无法扩展的关系，有很多可以说是“大战”。 ESPN 会考虑吗？ 这些天，我在工作中进行了一些友好的讨论，因为他们正试图强加 mongo db，仅仅是因为 MS SQL Server“无法扩展” ... ejem？ + +如果您不打算透露有关该基础架构的详细信息，则无需说明在如此小的基础架构上要完成多少工作。 + +并不是说他们正在运行带有 8 gig RAM 的四核 Xeon。 \ No newline at end of file diff --git a/docs/128.md b/docs/128.md index e05f8bb..c2d9727 100644 --- a/docs/128.md +++ b/docs/128.md @@ -1,313 +1,193 @@ -# 一千万个并发连接的秘密-内核是问题，而不是解决方案 +# 如何制作无限可扩展的关系数据库管理系统（RDBMS） -> 原文： [http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html](http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html) +> 原文： [http://highscalability.com/blog/2013/11/25/how-to-make-an-infinitely-scalable-relational-database-manag.html](http://highscalability.com/blog/2013/11/25/how-to-make-an-infinitely-scalable-relational-database-manag.html) - +![](img/47662846edb26e957c51b995b2f12179.png) -现在我们遇到了 [C10K 并发连接问题](http://www.kegel.com/c10k.html) ，我们如何升级并支持 1000 万个并发连接？ 你说不可能。 不，目前，系统正在使用可能不熟悉的根本技术提供 1000 万个并发连接。 +*这是 [InfiniSQL](@infinisq) 的创始人 [Mark Travis](@infinisq) 的来宾帖子。* -要了解其操作方法，我们求助于 Errata Security 的首席执行官 [Robert Graham](https://twitter.com/ErrataRob) ，以及他在 [上的精彩演讲 Shmoocon 2013](https://www.shmoocon.org/) 被称为 [C10M 大规模防御互联网](http://www.youtube.com/watch?v=73XNtI0w7jA#!) 。 +[](http://www.infinisql.org)InfiniSQL 是标题所指的特定“无限扩展 RDBMS”。 它是免费软件，有关其获取，构建，运行和测试的说明，请参见[指南](http://www.infinisql.org/docs/guide/)。 [基准测试](http://www.infinisql.org/blog/2013/1112/benchmarking-infinisql)显示，一个 InfiniSQL 群集每秒可以处理 500,000 个复杂事务，并具有 100,000 多个并发连接，所有这些都位于十二台小型服务器上。 测试的方法已记录在案，并且所有代码都可用，因此任何从业人员都可以取得类似的结果。 InfiniSQL 具有两个主要特征： -罗伯特有一个绝妙的方式来解决我从未听说过的问题。 他从一些历史开始，讲述了最初不是将 Unix 设计为通用服务器操作系统，而是将其设计为电话网络的控制系统。 电话网络实际上是在传输数据，因此控制平面和数据平面之间存在清晰的分隔。 **问题是我们现在将 Unix 服务器用作数据平面**的一部分，我们根本不应该这样做。 如果我们要设计一个内核来为每个服务器处理一个应用程序，那么它的设计将与多用户内核的设计大不相同。 +1. 它比任何集群/分布式 RDBMS 更好地执行在多个节点上具有记录的事务 +2. 它是免费的开放源代码。 不仅仅是具有专有技术的预告片“社区”版本。 准备就绪时，InfiniSQL 的社区版本也将是企业版本。 -这就是为什么他说关键是要理解： +InfiniSQL 仍处于开发的早期阶段-它已经具有许多功能，但是要使其在生产环境中有用，还需要更多的功能。 -* 内核不是解决方案。 **内核是问题**。 +## 谁会做这种事情？ -表示： +我的职业背景可以在 [LinkedIn](http://www.linkedin.com/pub/mark-travis/1/a3a/1a2) 上找到。 我已经为一些相当大的事务处理环境进行了容量规划，系统工程，性能工程等工作，其中几秒钟的停机时间使成千上万的客户损失了成本。 保姆式的环境告诉我，传统的企业数据库基础结构非常适合需要 24x7 全天候运行，持续增长并快速响应新业务需求的现代环境。 这确实是一个典型的故事-我们都知道 70 年代设计的系统无法满足当今的需求。 因此，我决定构建适合现代事务处理环境的东西。 -* **不要让内核完成所有繁重的工作**。 将数据包处理，内存管理和处理器调度从内核中移出，然后将其放入应用程序中，从而可以高效地完成它。 让 Linux 处理控制平面，让应用程序处理数据平面。 +## 目标用户/用例 -结果将是一个系统可以处理 1000 万个并发连接，其中 200 个时钟周期用于数据包处理，而 1400 个时钟周期用于应用程序逻辑。 由于主存储器访问需要 300 个时钟周期，因此设计的关键在于最大程度地减少代码和缓存丢失。 +我敢肯定，大多数[高可扩展性](http://highscalability.com/)的读者都会理解为什么新的数据库体系结构如此必要的原因，而且我们当中许多人也认为更快，更大的规模是自我调整的价值。 我们就像赛车手。 但是重要的是要知道用例，以帮助其他人学习如何利用我们正在构建的强大功能。 就 InfiniSQL 而言，有几种主要客户类型，每种类型都有各种特定的用例。 我将简要介绍一下客户类型，以及我如何看待 InfiniSQL 为他们解决业务问题。 -使用面向 **数据平面的系统** ，您每秒可以处理 1000 万个数据包。 使用面向控制平面的系统，您每秒只能获得一百万个数据包。 +* Look no further than the example application cited in [Design Decisions For Scaling Your High Traffic Feeds](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html), which is a very recent entry on this site. Imagine there's no *Part Two* and *Part Three*, meaning that their original RDBMS of choice was able to perform "`select * from love where user_id in (...)`" well beyond 100M rows and 1M users. There'd be no need to design a new framework from scratch, or to rip and replace two back ends before settling on one that seems fine for the time being. InfiniSQL is capable of performing that kind of query. I haven't benchmarked that specific workload--but it's the type of thing that I designed InfiniSQL for: transactions with records distributed across multiple nodes. -如果这看起来很极端，请记住一句老话： **可伸缩性是专业化** 。 要做到出色，就不能将性能外包给操作系统。 你必须自己做。 + 成功的 Internet 应用程序几乎不可避免地从它们启动时所使用的基础结构中发展而来。 RDBMS 通常是首选的初始数据库-但实现了变通方法，并且实现了完全不同的体系结构-所有这些都是因为原始数据库无法处理成功。 那是一个非常破坏性的过程。 InfiniSQL 适用于具有 RDBMS 工作负载但由于其原始 RDBMS 不能随业务增长而被迫实施变通方法的任何公司。 这些解决方法包括分拆 SQL 数据库以及将一些工作负载迁移到各种 NoSQL Point 解决方案。 实际上，InfiniSQL 应该成为公司开始使用的数据库，以避免将来的迁移成本。 -现在，让我们学习 Robert 如何创建一个能够处理 1000 万个并发连接的系统... +* InfiniSQL 的另一类目标用户包括那些在单片平台上负责每秒处理数以万计的复杂事务的应用程序的用户。 这种工作负载很难脱离大型系统架构。 这类公司包括信用卡协会，旅行预订系统和交易所。 这些不是新的业务模型。 数十年来，他们的基础设施一直在挣扎。 他们执行的每项操作都代表着（至少）两方之间的资金转移-他们转移了人们的资金。 稳定性和数据完整性是最重要的价值。 InfiniSQL 能够以预期的数量和更高的容量执行此类工作负载，但可以在运行 Linux 而不是大型的超昂贵平台的 x86_64 服务器上执行。 实际上，InfiniSQL 会进一步扩展-因为这些大型的整体平台在其扩展插槽用完的情况下会用光。 -## C10K 问题-过去十年 +## 问题及其原因（以及几个相关问题） -十年前，工程师解决了 C10K 可伸缩性问题，该问题阻止服务器处理 10,000 多个并发连接。 通过修复操作系统内核并从线程服务器（如 Apache）移至事件驱动的服务器（如 Nginx 和 Node），解决了该问题。 随着人们从 Apache 转移到可伸缩服务器，此过程已花费了十年的时间。 在过去的几年中，我们看到了可扩展服务器的更快采用。 +（如果我能找到其他在我之前说过的夸夸其谈的声明，我会编成信誉，否则，我会接受-每个人都需要报价，对吗？我会接受。） -### Apache 问题 +*问题*使多个节点全部组成一个数据库。 通过将静态 Web 服务器与数据库进行比较，可以轻松说明此问题。 通过简单地将 Web 服务器的内容镜像到不同的盒子上，然后以循环方式或其他方式向它们喷射流量，来扩展 Web 服务器很简单。 简单。 但是对于数据库而言，并不是那么简单。 取两个盒子，然后将您喜欢的数据库放在上面。 给每个相同的模式。 然后，连接到框 A 并插入一条记录-任何旧记录。 然后连接到方框 B 并查找该记录。 当然不存在！ 这就是水平扩展数据库的问题：逻辑和数据都在同一个盒子中！ -* Apache 问题是连接越多，性能越差。 +### 锁定主要是坏的 -* 关键见解： **性能和可伸缩性或正交概念** 。 他们不是同一回事。 人们谈论规模时，通常是在谈论绩效，但是规模和绩效之间是有区别的。 正如我们将在 Apache 中看到的那样。 +传统数据库设计在性能方面的另一个问题是锁定。 为了数据完整性，每个工作程序（线程或进程）都锁定与其操作的记录关联的内存或存储区域。 这些不是高级数据锁，例如行或表锁（尽管它们也可能有问题）。 不，它们被实现为互斥或信号量。 互斥体和信号量是多线程/进程应用程序阻止其他线程/进程踩踏共享数据的方式。 随着共享内存区域的锁争用增加，性能下降。 锁定争用的一个很可能的指标是数据库速度很慢，但是有大量可用的 CPU，并且没有 I / O 瓶颈。 -* 对于持续几秒钟的短期连接（例如快速交易）来说，如果您要执行 1000 TPS，则与服务器的并发连接数只有 1000。 +### I / O 慢，没有问题，它有多快 -* 将交易时间更改为 10 秒，现在以 1000 TPS 的速度打开了 1 万个连接。 尽管 Apache 的性能下降了很多，但这使您容易受到 DoS 攻击。 只需进行大量下载，Apache 就会崩溃。 +传统数据库的另一个大性能问题是事务日志瓶颈。 为了[持久性](http://en.wikipedia.org/wiki/Durability_(database_systems))，传统数据库在完成事务之前，会将包含书面记录的所有事务实时实时写入等效于日志文件的日志。 当电源关闭时，当指示灯重新点亮时，数据仍将存在。 问题在于这会减慢写入速度。 在最快的固态存储和海量 I / O 总线上使用任何经过调整的数据库。 它将成为写入事务日志的瓶颈。 -* 如果每秒处理 5,000 个连接，并且要处理 10K，该怎么办？ 假设您升级硬件并将处理器速度提高了一倍。 怎么了？ 您可以获得双倍的性能，但规模却没有双倍。 规模只能达到每秒 6K 个连接。 如果您继续加倍，也会发生同样的事情。 性能提高了 16 倍，但您仍未达到 1 万个连接。 性能与可伸缩性不同。 +## InfiniSQL 解决这些问题的方法 -* 问题是 Apache 会派生一个 CGI 进程，然后将其杀死。 这没有规模。 +InfiniSQL 并不是解决某些或所有这些问题并成功实现集群 RDBMS 的唯一项目。 我敢肯定，此博客的大多数读者都知道这样的各种系统，即使它们还不是用户。 我正在描述如何解决这些问题，以及它们如何有助于 InfiniSQL 的独特优势。 其他人则以自己的方式解决了这些问题。 -* 为什么？ 由于内核中使用 O（n ^ 2）算法，服务器无法处理 10K 并发连接。 +### 演员们 - * 内核中的两个基本问题： +InfiniSQL 在并发编程的[参与者模型](http://en.wikipedia.org/wiki/Actor_model)上实现了一种变体。 C ++是用于创建 InfiniSQL 的主要语言，该语言本身不支持 actor 模型。 实现 InfiniSQL 的许多工作涉及使角色在 C ++中工作。 actor 模型通过将事务处理逻辑与存储断开耦合并且不锁定内存区域来解决上述前两个问题。 有关详细信息，请阅读[概述](http://www.infinisql.org/docs/overview/)。 这与传统的 RDBMS 体系结构完全不同。 - * 连接=线程/进程。 当一个数据包进入时，它将遍历内核中的所有 10K 进程，以确定哪个线程应该处理该数据包 +角色模型解决了[问题](#0.1_theproblem)，因为处理逻辑由一组角色处理，而数据存储由另一组角色处理。 它们的功能在 InfiniSQL 中松散耦合。 无论参与者位于哪个节点，消息传递都是在参与者之间进行的：管理特定事务的参与者不知道或不在乎数据是驻留在本地还是远程。 并且管理特定数据分区的参与者响应消息，而不管其来源。 从理论上讲，参与者模型允许 InfiniSQL 无限扩展。 基于其第一字段的哈希值将每个记录分配给特定的数据区域，并且基于索引值的哈希将每个索引记录分配给一个区域。 - * 连接=选择/轮询（单线程）。 同样的可扩展性问题。 每个数据包都必须经过一个套接字列表。 +actor 模型的另一个有益效果是它解决了低级别锁定的问题。 由于每个数据区域仅具有一个关联的参与者，因此不需要互斥或信号量来限制访问。 分区的参与者根据来自交易参与者的消息来处理对数据操作的请求。 发送方参与者无需等待（阻止）等待响应，而是可以自由地处理其他任务。 当分区的 actor 用数据响应时，发出请求的事务 actor 从中断的地方继续。 它要么完成交易并向客户端发送回复，要么与其他参与者保持互动。 - * 解决方案：修复内核以在恒定时间内进行查找 +下面的示例试图以图形方式说明数据库设计的传统共享内存模型与 InfiniSQL 的参与者模型之间的区别： +![](img/367dba9abe58928326d901f36d675357.png) +对于参与者，没有 锁定。 当需要更多处理时，将添加更多的参与者，每个参与者*大致*最佳对应于单个 CPU 线程或内核。 随着内核的添加，基于角色的体系结构可以保持很好的状态。 但是，传统的锁定共享内存模型在添加内核方面会遭受更多的痛苦-因为锁争用只会增加。 大型整体数据库具有非常复杂的锁管理方法，可以最大程度地减少此问题。 - * 现在，无论线程数量如何，线程都会进行恒定时间上下文切换。 +actor 模型的另一个好处是它支持大量并发。 InfiniSQL 实现角色的方式与传统角色模型略有不同，但是在保持高吞吐量的同时，它仍然可以实现很高的连接速率。 大多数传统数据库都有一个连接阈值，超过此阈值，聚合系统的性能将大大降低。 这主要与已经描述的争用有关，并且还因为每个连接的成本都很高-如果每个客户端在服务器端都需要专用的进程（或线程），则会消耗大量内存。 此外，高度多线程的应用程序会遭受过多的上下文切换。 内核调度程序始终必须使线程进入睡眠状态，复制它们的状态，然后复制并激活另一个线程。 使用 InfiniSQL，维护每个连接的成本相对较低-内核必须管理一个开放的套接字。 另外，将创建一个用于管理连接的对象。 添加了两个地图条目，以允许相关角色识别连接。 与必须启动一个新线程（更不用说进程）相比，每个连接的开销要低得多。 为了最大程度地减少上下文切换，每个参与者大致对应一个 CPU 线程，因此等待 CPU 的线程更少。 - * 引入了新的可扩展 epoll（）/ IOCompletionPort 恒定时间套接字查找。 +为了解决 I / O 缓慢的问题，InfiniSQL 目前已成为内存数据库，从而避免了这种情况。 与块支持的存储相比，在内存中实现起来更简单，尤其是使用 actor。 但这显然带来了一些问题。 即，耐久性和成本。 如果断电，则内存中数据库的单个副本将消失。 并且 RAM 的成本高于磁盘的成本。 [概述](http://www.infinisql.org/docs/overview/)描述了计划在开发工作中花时间解决这些问题的计划。 -* 线程调度仍无法扩展，因此服务器使用带有套接字的 epoll 进行扩展，从而导致 Node 和 Nginx 中体现了异步编程模型。 这将软件转移到不同的性能图表。 即使在服务器速度较慢的情况下添加更多连接，性能也不会下降。 连接数为 10K 时，笔记本电脑甚至比 16 核心服务器还要快。 +InfiniSQL 计划的内存持久性的关键在于强调-它是从高端存储领域借来的。 高端存储系统之所以表现出色，是因为它们将更改写入内存中，并且仅在以后将这些更改写入磁盘中。 他们可以避免这种情况，因为它们具有冗余的备用电池系统，并且每次写入都分布在多个缓存区域中。 断电或单点故障都不会导致高端存储系统中的数据丢失，这才是真正重要的。 世界上最大的交易处理平台依赖于这种存储阵列。 除了冗余和电源管理将保护数据库服务器节点本身以外，InfiniSQL 打算实现相同的模型。 这尚未完全实现，但是如果可用，将意味着 InfiniSQL 将提供持久的内存性能。 -## C10M 问题-下一个十年 +## 事务处理 -在不久的将来，服务器将需要处理数百万个并发连接。 使用 IPV6，来自每台服务器的潜在连接数达到数百万，因此我们需要进入下一个可伸缩性级别。 +事务处理的详细信息在[概述](http://www.infinisql.org/docs/overview/)中进行了描述。 我发现使用参与者实现 ACID 功能的原因是还需要实现其他技术。 即，参与者间远程过程调用（RPC）是一种在 OSI 模型和后续版本上受到宽松启发的本地协议栈。 这引入了一定程度的实现复杂性-我正在寻找重构和降低复杂性的方法。 但是所有的 ACID 特性（如上所述的耐用性除外）都可以发挥作用。 -* 需要此类可伸缩性的应用程序示例：IDS / IPS，因为它们连接到服务器主干。 其他示例：DNS 根服务器，TOR 节点，Internet 的 Nmap，视频流，银行业务，运营商 NAT，Voip PBX，负载均衡器，Web 缓存，防火墙，电子邮件接收，垃圾邮件过滤。 +## 基于行的表，索引和类似的东西 -* 通常，看到 Internet 规模问题的人是设备而不是服务器，因为他们出售的是硬件和软件。 您购买设备并将其插入数据中心。 这些设备可能包含英特尔主板或网络处理器以及用于加密，数据包检查等的专用芯片。 +基于参与者的核心和事务处理功能*可以与任何数量的不同类型的数据库一起使用。 基于列的简单密钥库，xml 文档库，graphdb。 任何需要扩展并从并行性中受益的事物。 但是我选择实现基于行的 RDBMS 作为 InfiniSQL 的第一个底层存储方案。 尽管有其他类型，该模型仍支持多种应用程序。 大多数备用数据组织类型都针对特定类型的工作负载进行了优化，而其他类型的组织则非常糟糕。 例如，列数据存储不适合事务处理。 除了获取/设置简单对象之外，密钥库实际上不能做任何其他事情。 关于 InfiniSQL 组织和操作数据的方式，没有什么破天荒的创新，但是底层体系结构克服了许多限制，这些限制促使采用许多备用数据库类型。* -* 截至 2013 年 2 月，Newegg 的 X86 价格为$ 5K（40gpbs，32 核，256gigs RAM）。 服务器可以执行超过 10K 的连接。 如果不能，那是因为您在软件方面做出了错误的选择。 问题不在于底层硬件。 该硬件可以轻松扩展到 1000 万个并发连接。 +PostgreSQL 客户端用于执行 SQL 查询，因此实际上任何平台和语言都应该能够使用 InfiniSQL。 他们已经很好地记录了[前端/后端协议](http://www.postgresql.org/docs/7.4/static/protocol.html)，因此为 InfiniSQL 实施它非常简单。 （InfiniSQL 和 PostgreSQL 是完全独立的项目。） -### 10M 并发连接挑战的含义是： +## 摘要 -1. 1000 万个并发连接 +就 InfiniSQL 的介绍以及如何将其设计为无限可扩展的 RDBMS 而言，这几乎就是如此。 到目前为止，从字面上看，这是一个人在他的客厅里全天候敲出代码的工作。 请喜欢 InfiniSQL，并从中学习，如果您想谈论它，请在上述链接中找到我！ 另外，请考虑参与-它仍处于早期状态，并且正在积极寻求贡献。 它是免费的开放源代码，并且有很大的发展空间。 愿意进行此项目的 Alpha 测试的人们也很受欢迎-如果您认为 InfiniSQL 可以解决您的某些问题，请与我谈谈！ -2. 1 百万个连接/秒-大约 10 秒的持续速率 +[关于黑客新闻](https://news.ycombinator.com/item?id=6795263) -3. 10 吉比特/秒的连接-快速连接到 Internet。 +*主页： [http://www.infinisql.org](http://www.infinisql.org/) +博客： [http://www.infinisql.org/blog/](http://www.infinisql.org/blog/) +IRC： [irc.freenode.net](http://irc.freenode.net/) #infinisql +Twitter：@infinisql +论坛： [https://groups.google.com/forum/#!forum/infinisql](https://groups.google.com/forum/#!forum/infinisql)* -4. 1000 万个数据包/秒-期望当前的服务器每秒处理 5 万个数据包，这将达到一个更高的水平。 过去服务器每秒能够处理 100K 次中断，每个数据包都会引起中断。 +虽然这是一个有趣的开始，但我最想知道 InfiniSQL 如何计划处理聚合功能和大表的联接。 尤其是联接是使关系数据库吸引人的原因，但是当您扩展规模时，尤其是对于复杂数据，它们也是最难的事情之一。 -5. 10 微秒延迟-可伸缩服务器可能会处理规模，但延迟会增加。 +我很好奇，想知道 InfiniSQL 是否计划提供某种东西来比在外部进行连接（例如在 map reduce 中）或购买带有硬件的数据库设备来使更大的连接成为可能。 -6. 10 微秒抖动-限制最大延迟 +您的徽标与 VoltDB 有点类似：http://i.imgur.com/93x1CWJ.jpg -7. 10 个一致的 CPU 内核-软件应扩展到更大数量的内核。 通常，软件只能轻松扩展到四个内核。 服务器可以扩展到更多的内核，因此需要重写软件以支持更大的内核计算机。 +嗨，戈登。 对于聚合，我认为它应该相对简单： +向每个分区发送一条消息，以使其返回其自身数据集的聚合结果。 然后让交易代理收集结果，并简化为正确的答案。 地图/缩小效果如何？ ;-)我还在考虑为每个表（甚至字段）提供一个选项，以便在每个插入/更新/删除操作中更新其聚合值，以节省聚合查询的时间。 -### 我们已经学习了 Unix 非网络编程 +对于联接，我正在考虑让每个分区创建一个临时表，该表代表相关表中的联接值，并将这些值返回给事务代理。 -* 一代程序员已经通过阅读 W. Richard Stevens 的 Unix Networking Programming 学习了网络编程。 问题在于这本书是关于 Unix 的，而不仅仅是网络编程。 它告诉您让 Unix 承担所有繁重的工作，而您只需要在 Unix 之上编写一个小型服务器即可。 但是内核无法扩展。 解决方案是移出内核，自己做所有繁重的工作。 +在 InfiniSQL 上，某些大规模的多方联接很可能无法很好地完成工作-这很可能是只有整体数据库（或 MPP 数据仓库）才能很好地工作的领域。 我认为 InfiniSQL 至少对于现有的基于行的存储而言，并不是真正繁重，长时间运行的分析的最佳选择。 现在，对于柱状存储，可能会有不同的故事。 -* 这种影响的一个例子是考虑每个连接模型的 Apache 线程。 这意味着线程调度程序根据到达的数据确定下一步要调用的 read（）。 **您正在使用线程调度系统作为数据包调度系统** 。 （我真的很喜欢这个，以前从未想过）。 +我还编写了大多数代码来支持子查询，但尚未对其进行完整的测试。 因此，几乎*支持子查询。 -* Nginx 所说的它不使用线程调度作为数据包调度程序。 自己安排数据包。 使用 select 查找套接字，我们知道它有数据，因此我们可以立即读取它并且不会阻塞，然后处理该数据。 +您想帮忙吗？ :-) -* 课程：**让 Unix 处理网络堆栈，但是从那时起，您将处理**上的所有内容。 +我真的不认为可以基于“ 12 台小型服务器”来“证明”“无限可扩展性”。 在那 12 之后再加上两个零； 如果每个服务器的数量看起来仍然相同，那将更有说服力。 -### 您如何编写可扩展的软件？ +如果我没记错的话，VoltDB 说了类似的话，第三方稍后显示当您达到 50 到 100 台服务器（不确定精确限制）时，数字下降了。 -如何更改软件以使其可扩展？ 关于硬件可以处理多少的很多经验法则都是错误的。 我们需要知道实际的性能能力。 +I don't really think that "infinite scalability" can be "proved" based on "12 small servers." Add another two zeros after that 12; if the numbers per server *still looked the same*, that would be a lot more convincing. -要进入下一个级别，我们需要解决的问题是： +If I remember well, VoltDB said something similar, with third party showing later that the numbers went down when you reached 50 to 100 servers (not sure about precise limit). -1. 包可扩展性 -2. 多核可扩展性 -3. 内存可扩展性 +------ -### 数据包扩展-编写自己的自定义驱动程序以绕过堆栈 +嗨，塞巴斯蒂安。 我认为演员模型很适合扩展规模。 本质上，限制因素将是节点间通信。 我不确定随着节点的增加，效率会降低多少。 另外，诸如高性能节点间联网之类的技术将改善这一状况。 有一次，我正在研究 Infiniband 动词作为集群间通信协议，但是 TCP / IP 更容易并且无处不在。 但是我想为 InfiniSQL 实现一个选项，以使其本机使用 Infiniband 进行群集通信-我认为这对于扩展可伸缩性将大有帮助。 -* 数据包的问题是它们通过 Unix 内核。 网络堆栈复杂且缓慢。 数据包到您的应用程序的路径需要更直接。 不要让操作系统处理数据包。 +我不认为我们不同意-至少，到目前为止，我已经很清楚自己已经能够走多远了，我希望有机会进一步走好。 如果像 SGI 这样的人能像为 VoltDB 一样借给我无数的服务器，那就太好了。 ;-) -* 实现此目的的方法是编写自己的驱动程序。 驱动程序所做的只是将数据包发送到您的应用程序，而不是通过堆栈发送。 您可以找到驱动程序：PF_RING，Netmap，Intel DPDK（数据平面开发套件）。 英特尔是封闭源代码，但周围有很多支持。 +我也不认为我们不同意。 我只是指出“ 12 台小型服务器”。 不是那么...令人印象深刻。 -* 多快？ 英特尔有一个基准，该基准在相当轻巧的服务器上每秒处理 8000 万个数据包（每个数据包 200 个时钟周期）。 这也是通过用户模式。 数据包一直向上进入用户模式，然后再次下降出去。 当 UDP 数据包恢复到用户模式并再次输出时，Linux 每秒处理的数据包不超过一百万。 性能是 Linux 客户驱动程序的 80-1。 +我也是 Actor 模型的忠实拥护者，因为我是新的（仍然是 1.0 之前的版本）Actor API 的提交者。 但是对于许多 DB 而言，节点间的通信很快成为瓶颈，因此需要 12 个以上的节点来说明是否（或以何种大小）这种情况。 -* 对于每秒 1000 万个数据包的目标，如果使用 200 个时钟周期来获取离开 1400 个时钟周期以像 DNS / IDS 那样实现功能的数据包。 +> 如果像 SGI 这样的人能像为 VoltDB 一样借给我无数的服务器，那就太好了。 ;-) -* 使用 PF_RING 可以获取原始数据包，因此必须执行 TCP 堆栈。 人们在做用户模式栈。 对于英特尔，有一个可用的 TCP 堆栈可提供真正可扩展的性能。 +：D -### 多核可扩展性 +>我还在考虑为每个表（甚至字段） +>提供一个选项，以便在每次插入/更新/删除时将其汇总值更新为 +>，从而节省汇总时间 查询。 -多核可扩展性与多线程可扩展性不同。 我们都对处理器的想法并不熟悉，但是越来越多。 +您是说要维护每个表的每个字段的*每个*汇总值？ 我认为这没有太大意义。 例如，您将使用以下查询做什么： +从员工那里选择 AVG（薪水）WHERE employee_name LIKE'H％'; +？ -大多数代码无法扩展到 4 个内核以上。 随着我们添加更多内核，不仅性能会下降，而且添加更多内核会越来越慢。 那是因为软件写得不好。 我们需要软件，因为我们添加了更多的内核以几乎线性地扩展。 希望随着我们添加更多核心而变得更快。 +或者您将如何处理用户创建的聚合函数？ 当将记录插入表中时，这些功能甚至不存在。 只要考虑一下 postgresql 的 CREATE AGGREGATE 语句。 -#### 多线程编码不是多核编码 +我有一个问题，这个帖子没有答案 +-根据文档，每个写入都可以同步复制。 但是，即使在内存中，同步复制也很难扩展（CAP 定理？）。 尽管该功能尚未完成，但我认为这可能是对无限可扩展性的很大限制。 -* 多线程： +你同意吗 ？ - * 每个 CPU 内核有多个线程 +Csongor 说： - * 锁定以协调线程（通过系统调用完成） +“您是说要维护每个表的每个字段的*每个*聚合值？我认为这样做没有太大意义。” - * 每个线程有不同的任务 +-------------- -* 多核： +仅作为选择。 该用例适用于希望为每个插页上的列收集 AVG 的人员。 保存每个分区的滚动总条目数和条目数量会节省计算时间。 但是对于您提到的情况，不，这不是一个好主意。 - * 每个 CPU 内核一个线程 +主要是想表达我在 InfiniSQL 中进行聚合没有问题。 - * 当两个线程/内核访问相同的数据时，它们将无法停止并互相等待 +slefebvr 说： - * 所有线程属于同一任务 +我有一个问题，这个帖子没有答案 +-根据文档，每个写入都可以同步复制。 但是，即使在内存中，同步复制也很难扩展（CAP 定理？）。 尽管该功能尚未完成，但我认为这可能是对无限可扩展性的很大限制。 -* 我们的问题是如何在多个内核之间分布应用程序。 +Do you agree ? -* Unix 中的锁是在内核中实现的。 使用锁的 4 个核心发生的事情是，大多数软件开始等待其他线程放弃锁。 因此，内核开始消耗更多的性能，而不是拥有更多 CPU 所获得的性能。 +--------------- -* 我们需要的是一种比起停车灯控制的交叉路口，更像是高速公路的建筑。 我们不想等待每个人按照自己的步调以尽可能少的开销继续前进。 +不，我不同意。 我几乎完成了同步复制。 扩展并不难-尽管它会消耗一定数量的系统资源才能完成。 但是随着节点的增加，每个节点的系统资源有望保持稳定。 -* 解决方案： +我看到的关于可伸缩性的唯一硬性限制是打开的可用 TCP / IP 套接字的数量-副本中的每个节点都连接到网格中的每个其他节点。 类似 UNIX 的系统不能同时处理无限数量的 TCP / IP 连接。 我认为极限是无限 10。 ;-) - * 保持每个核心的数据结构。 然后在聚合时读取所有计数器。 - * 原子学。 可以从 C 调用的 CPU 支持的指令。保证是原子的，永不冲突。 昂贵，所以不想用所有的东西。 - * 无锁数据结构。 永不停止并等待彼此的线程可以访问。 不要自己做。 跨不同的架构工作非常复杂。 - * 线程模型。 流水线与工作线程模型。 问题不只是同步，而是线程的架构方式。 - * 处理器亲和力。 告诉操作系统使用前两个内核。 然后设置线程在哪些内核上运行的位置。 您也可以对中断执行相同的操作。 因此，您拥有这些 CPU，而 Linux 没有。 +塞巴斯蒂安写道： -## 内存可扩展性 +I'm a believer in the Actor model too, as I'm a commiter to a new (still pre-1.0) Actor API. But for many DB, inter-node communication quickly becomes a bottleneck, and a lot more then 12 nodes are needed to show if (or at which size) this is the case. -* 问题是，如果您有 20gig 的 RAM，并且假设每个连接使用 2k，那么如果您只有 20meg 的 L3 缓存，则这些数据都不会在缓存中。 进入主内存需要 300 个时钟周期，这时 CPU 无法执行任何操作。 +--------------------- -* 考虑每个数据包 1400 个时钟周期的变化。 请记住 200 个时钟/每包的开销。 每个数据包只有 4 个高速缓存未命中，这是一个问题。 +InfiniSQL 批处理节点间消息并使用 LZ4 压缩。 它牺牲了一些延迟，但是在我看来，吞吐量的增加是值得的。 同样，10GB 以太网比 1GB 更好，多个 NIC RX 队列比单个更好。 我想使用 Infiniband Verbs API（https://www.openfabrics.org/index.php）来实现 RDBMA，但是 TCP / IP 较容易编码，并且用户基础更加广泛。 但是我认为 Infiniband 可以大大减少集群内部的通信开销。 -* 并置数据 +有趣的项目。 - * 不要通过指针在整个内存上写数据。 每次跟随指针将导致高速缓存未命中：[哈希指针]-> [任务控制块]-> [套接字]-> [应用程序]。 那是四个缓存未命中。 +在许多情况下，您可以将聚合推送到参与者。 AVG 怎么了？ 您从每个演员返回计数和平均值，然后根据计数加权最终平均值。 感觉就像一个很简单的地图/缩小模型。 - * 将所有数据保存在一块内存中：[TCB | 插座 应用]。 通过预分配所有块来保留内存。 这样可以将缓存未命中次数从 4 个减少到 1 个。 +正如其他人所提到的，问题可能是节点间通信，尤其是在某些联接情况下。 我喜欢您已经认识到这一点，但是您可以将 10GB 扩展到某种上限。 我不知道我会称其为无穷大，但“高”似乎是可能的。 -* 分页 +期待看到这片土地，尤其是当您获得 ACID 中的 D 以后，您会发现更多。 - * 用于 32gigs 的分页表需要 64MB 的分页表，该页面不适合缓存。 因此，您有两个未命中的缓存，一个是针对分页表的缓存，另一个是其指向的缓存。 对于可扩展软件，这是我们不能忽略的细节。 +干杯! - * 解决方案：压缩数据； 使用高速缓存有效的结构，而不是具有大量内存访问权限的二进制搜索树 +- 八月 - * NUMA 体系结构使主存储器访问时间加倍。 内存可能不在本地套接字上，但在另一个套接字上。 +>如果像 SGI 这样的人像为 VoltDB 一样借给我无数的服务器，那就太好了。 ;-) -* 内存池 +EC2 FTW :-) - * 启动时一次预分配所有内存。 +FWIW，我认为正确处理节点故障和分区，最终获得一个可靠且性能良好的系统至关重要。 没有人愿意为后者牺牲前者。 - * 在每个对象，每个线程和每个套接字的基础上分配。 +第一部分是所有群集节点必须在配置上达成一致。 如果您以前从未接触过它，则可能想看看[木筏](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)算法作为 Multi-Paxos 的替代方法。 -* 超线程 - - * 网络处理器每个处理器最多可以运行 4 个线程，英特尔只有 2 个。 - - * 这样可以掩盖例如内存访问的延迟，因为当一个线程等待另一个线程全速运行时。 - -* 大页面 - - * 减小页表大小。 从一开始就保留内存，然后由应用程序管理内存。 - -### 摘要 - -* 没什么 - - * 问题：通过内核无法正常运行。 - - * 解决方案：使用您自己的驱动程序将适配器从操作系统中取出，并自行管理它们 - -* CPU - - * 问题：如果您使用传统的内核方法来协调应用程序，则效果不佳。 - - * 解决方案：为 Linux 提供前两个 CPU，然后您的应用程序将管理其余的 CPU。 在您不允许的 CPU 上不会发生中断。 - -* 内存 - - * 问题：要格外小心，以使其正常工作。 - - * 解决方案：在系统启动时，以您管理的大页面分配大部分内存。 - -控制平面留给 Linux 使用，对于数据平面则什么也没有。 数据平面以应用程序代码运行。 它从不与内核交互。 没有线程调度，没有系统调用，没有中断，什么都没有。 - -但是，您所拥有的是可以在 Linux 上正常运行的代码，您可以对其进行正常调试，这不是您需要定制工程师使用的怪异硬件系统。 通过熟悉的编程和开发环境，您可以获得数据平面所期望的自定义​​硬件的性能。 - -## 相关文章 - -* 阅读 [Hacker News](https://news.ycombinator.com/item?id=5699552) 或 [Reddit](http://www.reddit.com/r/programming/comments/1e90q7/the_secret_to_10_million_concurrent_connections/) ， [Hacker News Dos](https://news.ycombinator.com/item?id=7697483) -* [是时候摆脱云中的 Linux OS 模型了吗？](http://highscalability.com/blog/2012/1/19/is-it-time-to-get-rid-of-the-linux-os-model-in-the-cloud.html) -* [机器虚拟机+云 API-从头开始重写云](http://highscalability.com/blog/2010/10/21/machine-vm-cloud-api-rewriting-the-cloud-from-scratch.html) -* [Exokernel](http://en.wikipedia.org/wiki/Exokernel) -* [关于 C10M 的博客](http://c10m.robertgraham.com/) -* [多核缩放：它不是多线程的](http://erratasec.blogspot.com/search/label/Shmoocon2013) ，具有良好的注释功能。 -* [英特尔®DPDK：数据平面开发套件](http://dpdk.org/) - -瓶颈的分解令人印象深刻，阅读这种正确的东西令人耳目一新。 - -现在我想扮演魔鬼的拥护者（主要是因为我完全同意这个家伙）。 提出的解决方案听起来像是定制的特定于硬件的解决方案，听起来就像是回到过去，那时您不能只是将一些相当随机的硬件放在一起，将 linux 打在上面然后继续前进……这将是对此的最大反对， 人们担心电器/供应商/驾驶员被锁住，这是一种理性的恐惧。 - -有什么计划使外行可以使用这些非常正确的体系结构实践。 需要某种 API，因此各个硬件堆栈都可以对其进行编码，并且此 API 一定不能是重量级的抽象。 这是一个艰巨的挑战。 - -最好的是，C10M 运动很幸运，如果我能在未来几年的某个时间里将一个可运行 C10M 的系统组装在一起，我将是一个快乐的程序员。 - -很棒的文章！ 总的来说，我总是发现规模引人入胜。 Postgres 9.2 增加了对多达 64 个内核的支持（真正的支持），这确实使我很高兴。 业界似乎在“只是向它扔更多便宜的服务器...它们很便宜”和“让我们看看我们可以将其堆叠多高，因为很难将其拆分”之间来回切换。 我更喜欢后者，但是将它们结合在一起，再加上您所说的优化（不只是将大规模网络等任务委派给内核），往往会使我们朝着 roboblypse 前进：） - -好贴。 对于内存可伸缩性，您还可以考虑通过使用 libnuma / numactl 之类的控件来控制进程亲和力，从而提高内存的局部性。 - -关于本次会议的非常好的总结 - -关于 DPDK，您可以从 http://dpdk.org 获得源代码。 它提供 git，邮件列表和良好的支持。 看来它是由 6WIND 驱动的。 - -尽管[通用可扩展性法律](http://is.gd/3N2Iia)（USL）在视频演示中显示的时间约为 30:00 分钟，但他声明可扩展性和性能无关。 请注意，由于多核一致性延迟的出现而导致的最大性能。 在 Velocity 2010 上提出了对[内存缓存](http://www.perfdynamics.com/Manifesto/USLscalability.html#tth_sEc4.3)的类似效果进行量化的方法。 - -这很有趣。 标题可能会更好，因为“ Linux 内核是问题”，因为其他内核则有所不同。 举个例子，我上次检查时，Linux 用了 29 个堆栈帧从 syscalls 转到 start_xmit（）。 illumos / Solaris 内核的相似路径（对 mac_tx（）的系统调用）采用 16。 FreeBSD 用了 10 个（对 ether_output（）的系统调用）。 这些可以有所不同。 检查您的内核版本和工作量。 我已经将它们作为堆栈差异的示例。 这也应该使 Linux 堆栈更昂贵-但我需要分析（基于周期）以进行量化。 - -内存访问确实是大敌，您谈论的是保存缓存未命中，但是在 Linux（和其他内核）中，已经为 CPU 亲和力和内存局部性做了很多工作。 是行不通还是行不通？ 是否有可以修复的错误？ 分析这个问题并找出问题的根本原因将是非常好的。 在 Linux 上，运行 perf 并查看内核堆栈以查找缓存未命中。 更好的办法是量化 TCP / IP 中的内核堆栈，以获取内存访问停顿周期-并查看它们是否累加并解释了问题。 - -现在，我正在研究内核网络性能问题（我正在做内核工程）。 我认为我发现了一个内核错误，通过对问题进行根本原因分析，可以发现该内核错误可以将我正在运行的基准测试的网络堆栈延迟提高（减少）约 2 倍。 - -这样的胜利不会改变绕开堆栈的整体潜在胜利。 但是最好是先了解内核的限制是什么，然后再根源进行此操作。 - -绕过内核还意味着您可能需要重新发明一些工具集以进行性能分析（我使用了许多自定义工具，这些工具在系统调用和设备之间工作，用于分析 TCP 延迟和丢包，超出了网络嗅探的范围）。 - -让我想起了范雅各布森在 LCA2006 上的演讲。 谈论将工作推向端点。 而内核确实不是终结点（尤其是使用 SMP），而应用程序就是。 - -Unix 最初并未用于控制电话网络。 通常是一个用于编辑文档的分时系统（带标记的 ASCII 文本）。 这是从 CACM 纸的 BSTJ 纸版本中提取的。 -http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html。 - -自 1971 年 2 月 PDP-11 Unix 投入使用以来，已有 600 多个安装投入使用。 他们中的大多数人从事诸如计算机科学教育，文档和其他文本材料的准备和格式化，从 Bell 系统内的各种交换机收集和处理故障数据以及记录和检查电话服务订单等应用程序。 我们自己的安装程序主要用于操作系统，语言，计算机网络和计算机科学中的其他主题的研究，还用于文档准备。 - -让我们来看看 EZchip NPS，它实现了上面的大多数想法。 - -这并不奇怪：通用软件（例如内核）适用于“标准”应用程序。 为了达到最高性能，定制的，经过微调的软件总是可以击败它。 - -[Netmap](http://info.iet.unipi.it/~luigi/netmap/) 是否也不能很好地解决数据包 I / O 效率问题？ - -恩，我讨厌将其分解给你们，但是这个问题及其解决方案[早已为 exokernel 社区所熟知。](http://pdos.csail.mit.edu/exo.html) 虽然我承认 Linux 和 BSD 的商标意义是“不是 Unix”，但它们仍然基于不低于 60 年历史的 OS 体系结构（我们为之付出的大部分努力） 授予是来自 Multics 的某种形式的）。 现在是进行重大更新的时候了。 :) - -@Russell Sullivan -与本文无关的是外行。 - -“ Unix 最初并不是被设计为通用服务器操作系统，而是被设计为电话网络的控制系统。” - -呃，不，这是完全错误的。 由于 Linux 内核是独立开发的，因此谈论 UNIX 是无关紧要的。 - -这并不是说技术论点是不正确的，但是这种荒谬的废话无助于信誉。 - -一个问题是用户空间和内核空间中存在的阻塞点（无论是共享数据结构还是互斥体，是否可并行化）。 外来内核和其他方法只是通过转移负担（IP 堆栈打包功能）来选择做同一件事的不同方法。 最终，硬件（真实或虚拟）在解决方案上呈现出最明显的有限瓶颈。 - -在包括硅在内的其他方法的最高端，http：//tabula.com 以网络为中心的应用程序编译为带有功能样式编码的特定于应用程序的 OS 框架。 这不仅对利基问题是有前途的，而且似乎是解决时间/空间数据流问题的许多传统瓶颈的最深层方法。 对于 99％的解决方案，从用尽垂直规模的 LMAX 嵌入式系统开始使用 http://martinfowler.com/articles/lmax.html 开始，在精疲力尽商用设备之后，可能更明智。 - -回到商业规模，对于 Xen，有一些无操作系统的运行时： - -Erlang-LING VM -Haskell-Halvm - -“ Unix 中的锁是在内核中实现的”主张对于当今的系统而言并非绝对正确。 如 http://en.wikipedia.org/wiki/Futex 中所述，我们具有轻巧的用户土地锁。 尽管我同意应用程序在执行网络数据包处理方面可能带来的速度提升，但是内存管理（包括分页）和 CPU 调度几乎不在应用程序的范围内。 这类事情应该留给对底层硬件有更好了解的内核开发人员。 - -有趣的是，“控制和数据分离”的架构模式多久出现一次。 前几天，我在一个充满高管人员的房间里发表了讲话，指出在我们正在开发的产品中这种模式是如何发生的（事实证明是不正确的）。 您可以在我在 NCAR 上工作过的各种大型海量存储系统中看到它（控制 IP 链接，但是使用专用硬件通过高速 I / O 通道进行数据处理），而在我当时工作过的各种大型电信系统中 在贝尔实验室（再次通过 IP 链路“发送信号”，但通过专用交换结构使用完全不同的传输机制在所有“承载”流量），在 VOIP 系统中（使用 SIP 进行控制并由软件处理，但 RTP 尽可能地桥接） 即使在嵌入式系统中（直接从 A / D 芯片通过 TDM 总线承载，但通过 SPI 串行总线通过控制消息进行控制），也可以直接在端点之间进行操作，而无需软件堆栈进行处理。 这种模式至少自 1960 年代就已经存在，甚至在更早的其他非数字控制环境中也是如此。 这实际上是专业劳动理念的一个部门，可以追溯到数千年前。 - -仅供参考：我们使用一台运行标准 Linux 的 1U 服务器（未更改源代码）实现了 1200 万个并发连接，同时以 1Gbps 以上的速度发布数据。 查看更多详细信息： - -http://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/ - -但是，我同意，就大量套接字而言，Linux 内核仍应提供实质性的改进。 很高兴看到新版本的 Linux 内核（从 3.7 版开始）在套接字相关的内存占用方面有了一些重要的改进。 然而。 更多优化是必要且可能的。 如我的帖子所述，1200 万个并发连接的内存占用量约为 36 GB。 Linux 内核肯定可以增强此功能。 - -通过阅读本文，我得出结论，这是从头开始进行未来 OS 设计的新时代。 - -我尝试使用 lwip PF_RING，但失败了，从北京 IDF 2013 获悉 windriver 开发了它自己的用户空间堆栈，在 2 年内花费了 20 个开发人员。 - -这很棒！ 对于我打算稍后用于商业用途的学校项目，我做错了方法（每个连接一个线程）。 - -这很棒！ 我已经使用 nio 实现了 Java Web 服务器，并且可以在具有 5 年历史的 8GB ram 台式机上实现 10K +的连接-但是 10M 太疯狂了。 在 Linux 上，开放套接字的数量似乎受到 ulimit 的限制-并且不确定如果没有内核调整，是否甚至可以实现 10M。.我想您的方法并不重要。 - -很棒的帖子。 英特尔正在招聘 DPDK 和网络开发人员。 如果您知道有人对此空间感兴趣，请传递 -http://jobs.intel.com/job/Santa-Clara-Networking-Developer-Evangelist-Job-CA-95050/77213300/ - -“ 1400 个时钟周期” - -这是什么样的愚蠢，模棱两可的数字表达方式？ 您是否在故意混淆 peple？ 在整篇文章中，您应该*一贯*地使用数字或单词，更不用说相同的数字了。 \ No newline at end of file +但是，为了确定哪些写入已传播到副本节点，还需要在某种程度上进行类似的操作。 您可以确定，每种可能的故障模式-节点消失并在事务处理周期的不同点返回-*或早或晚都会发生。 \ No newline at end of file diff --git a/docs/129.md b/docs/129.md index c19737a..1d92f74 100644 --- a/docs/129.md +++ b/docs/129.md @@ -1,109 +1,131 @@ -# 神话：埃里克·布鲁尔（Eric Brewer）谈银行为什么不是碱-可用性就是收入 +# Bazaarvoice 的架构每月发展到 500M 唯一用户 -> 原文： [http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html](http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html) +> 原文： [http://highscalability.com/blog/2013/12/2/evolution-of-bazaarvoices-architecture-to-500m-unique-users.html](http://highscalability.com/blog/2013/12/2/evolution-of-bazaarvoices-architecture-to-500m-unique-users.html) -![](img/3af2dd88395161aee34fceeaed862790.png) +![](img/0d0ef50ef3231d56345ff504f3af735a.png) -在 [NoSQL：过去，现在，未来](http://www.infoq.com/presentations/NoSQL-History) [Eric Brewer](https://twitter.com/eric_brewer) 中，关于解释 [BASE 的观念通常很难理解的部分特别细腻](http://queue.acm.org/detail.cfm?id=1394128) （基本可用，软状态，最终一致）， [酸](http://en.wikipedia.org/wiki/ACID) （原子性，一致性，隔离性，耐久性）， [CAP [](http://en.wikipedia.org/wiki/CAP_theorem) （一致性可用性，分区容限），这是关于银行业一致性的神圣性的长期存在的神话。 +*这是由 [Victor Trac](http://victortrac.com) ，的云架构师 [Bazaarvoice](http://www.bazaarvoice.com) 撰写的客座 。* -**神话** ：金钱很重要，因此银行 必须 使用交易来保持金钱安全和一致，对吗？ +Bazaarvoice 是一家与人们定期进行互动但从未听说过的公司。 如果您在 bestbuy.com，nike.com 或 walmart.com 等网站上阅读了客户评论，则说明您正在使用 Bazaarvoice 服务。 这些站点以及其他数千个站点都依赖 Bazaarvoice 提供软件和技术，以收集和显示有关产品和服务的用户对话。 所有这些意味着 Bazaarvoice 会处理我们每天使用的大多数产品的很多情绪数据。 -**现实** ：银行交易不一致，尤其是对于 ATM 而言。 ATM 被设计为具有正常情况下的行为和分区模式的行为。 在分区模式下，可用性是通过一致性来选择的。 +Bazaarvoice helps our clients make better products by using a combination of machine learning and natural language processing to extract useful information and user sentiments from the millions of free-text reviews that go through our platform. This data gets boiled down into reports that clients can use to improve their products and services. We are also starting to look at how to show personalized sortings of reviews that speak to what we think customers care about the most. A mother browsing for cars, for example, may prefer to read reviews about safety features as compared to a 20-something male, who might want to know about the car’s performance. As more companies use Bazaarvoice technology, consumers become more informed and make better buying decisions. -**为什么？** **1）**可用性与收入相关，而一致性通常不相关。 **2）**历史上从来没有完美交流的想法，所以一切都被分割了。 +![](img/ac88b43fe350d28090d38c18fb2cd82e.png) -您的 ATM 交易必须经过，因此可用性比一致性更重要。 如果自动柜员机（ATM）处于关闭状态，那么您就无法赚钱。 如果您可以保持一致性，坚持不懈，并弥补其他错误（这种情况很少发生），那么您将获得更多的收入。 这是大多数企业发现的空间，因此 BASE 比以前更受欢迎。 +*红色的框由 Bazaarvoice 提供* -对于金融业来说，这不是一个新问题。 他们从来没有保持过一致，因为历史上他们从来没有过完美的沟通。 相反，金融业依赖审计。 导致银行数据一致性的原因不是其数据库的一致性，而是所有事实都被 [写下两次，然后稍后使用](https://en.wikipedia.org/wiki/Double-entry_bookkeeping_system) 进行整理。 不可更改的记录，以后再进行核对。 对错误进行财务补偿的想法是深深植根于金融系统的想法。 +Bazaarvoice 已集成到全球数千个网站中。 在任何给定的月份，我们将为超过 4.75 亿的唯一身份访问者提供流量。 这些访问者将浏览，阅读和贡献我们的内容，包括从产品评论到问题&答案，甚至是我们客户产品和服务的视频等内容。 这五亿人口将在我们的平台上花费大量时间，每个月的浏览量达到数百亿。 而且由于我们在众多人流量众多的商业站点上，因此我们的可靠性和正常运行时间至关重要。 如果 Bazaarvoice 平台发生故障，我们将影响成千上万依赖我们的网站。 为了快速，可靠地完成所有这些工作，我们设计了一个高度冗余的堆栈，该堆栈主要建立在 Amazon Web Services 之上。 -在文艺复兴时期，当[现代银行系统](http://en.wikipedia.org/wiki/Luca_Pacioli)初具规模时，一切都被分割了。 如果信件（您的数据）是通过马或轮船运输的，那么您的数据可能会保持非常低的一致性，但是它们仍然拥有令人惊讶的丰富而成功的银行系统。 交易是不必要的。 +假期购物旺季是我们基础设施最繁忙的时间。 在“黑色星期五”和“网络星期一”，我们会看到流量非常高，从今年年底到 1 月，我们的负荷一直很高。 这就提出了一个独特的扩展挑战，因为我们必须在一年中的 3-4 个月内处理几乎两倍于正常（并且一直在增长）的流量。 今年，我们预计在假日购物旺季每秒将收到 6 万至 6.5 万次请求。 -例如， ATM 选择了 [交换操作](http://en.wikipedia.org/wiki/Serializability) 之类的递增和递减操作，因此操作顺序无关紧要。 它们是可重新排序的，以后可以使其保持一致。 如果 ATM 与网络断开连接，并且当分区最终恢复正常时，ATM 发送将操作列表发送到银行，并且期末余额仍然正确。 问题很明显，您可能会提取比您更多的钱，因此最终结果可能是一致的，但为负数，无法通过要求退款来弥补，因此，银行将向您奖励透支罚款。 +![](img/2d16b3bf996e1933bc61dc768241e956.png) -隐藏的哲学是您试图 **约束并管理风险，** 仍然可以进行所有操作。 在 ATM 机中，这将限制您一次可以提取的最大金额。 风险不大。 自动取款机是有利可图的，因此偶尔的损失仅仅是开展业务的风险。 +*假期前到我们平台的带宽和 HTTP 请求的一周视图* -事实证明，这不是圣杯。 胜过一致性的是： +## 卑微的开端 -* 审核 -* 风险管理 -* 可用性 +与大多数大型软件堆栈一样，我们从一个非常简单的体系结构开始。 我们最初的应用程序是使用 MySQL 作为数据存储的单个整体 Java 应用程序，所有这些程序都在托管主机环境中运行。 随着我们这些年来的成长，我们在相同的代码库上构建了其他应用程序，并增加了新功能。 我们是 Solr 的早期用户，它使我们能够将 MySQL 主要转变为键值存储。 除了 Solr，我们通过仅给 JVM 更多的 RAM 或将 MySQL 服务器放在更快的盒子上来垂直扩展。 -在以写可用性为关键的后互联网世界中，现实世界看起来更像*弱一致性+延迟异常+补偿*，而不是完美的沟通和交易的无错误世界。 就像过去一样，但现在您在 ACID <-> CAP 频谱上有更多选择。 +然而，正如一位经验丰富的工程师所知道的那样，垂直缩放所带来的容易的早期收益很快变得难以实现。 因此，我们通过简单地复制整个堆栈开始水平扩展。 我们称这些为“集群”，它们使我们无需进行较大的应用程序更改即可实现水平扩展。 -## 相关文章 +![](img/c6bd7774dfcea43b9076ec0362aa58be.png) -* [关于 HackerNews 2](https://t.co/VMC2IA1K0I) -* [讨论黑客新闻](https://news.ycombinator.com/item?id=5642010) -* [](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html)[Google Spanner 最令人惊讶的启示：NoSQL 出炉了，而 NewSQL 出现了](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html) +*每个群集都是具有不同数据的整个堆栈的副本。* -真的很有趣。 当然，课程必须实施广泛的审核功能，以弥补潜在的不一致问题，并在发现问题时尝试和纠正流程 +在 2008 年，Bazaarvoice 大约 3 岁时，我们在托管数据中心经历了一些停机时间，这使我们面临着更多冗余的挑战。 一种选择是简单地在另一个地理区域中找到另一个托管服务提供商，然后复制我们所有的服务器。 但是，由于我们使用的是 MySQL，因此我们无法轻松地跨地区使用多主机。 因此，我们最初的计划只是从主托管数据中心运行 MySQL 复制，并保持足够的容量以热备份方式在备份区域中为生产流量提供服务。 如果我们的主数据中心发生故障，我们将更新 DNS 以指向备份数据中心。 但是，这将意味着很难进行单向故障转移，因为 MySQL 从属服务器将被提升为主服务器。 -这带来了银行认为可以接受的复杂程度，因为收益非常可观。 但是并不是每个组织或其应用程序都可以忍受这一点-因此仍然有很多地方需要保持一致性 +为使从属数据中心在灾难中真正发挥作用，我们需要保留足够的备用容量来服务我们 100％的生产流量，从而在不增加生产能力的情况下有效地使托管成本增加一倍。 -嗨，托德， +### 输入 AWS -我不确定您的所在地，但该示例在英国似乎并不成立。 我不知道实际的实现方式，但是在免费的 ATM 交易环境中，可用性似乎并不是主要问题。 自动柜员机停运并不罕见，而且，超出您的限额将导致机器拒绝为您提供所要求的现金。 +作为当时的年轻创业公司，我们无法简单地将托管成本提高一倍。 Amazon Web Services 在一个月前（即 2008 年 10 月）刚刚从 EC2 删除了“测试版”标签，因此我们认为这可能是一个绝佳的机会，可以利用这种新型云技术在我们的备用站点上节省资金。 -尽管如此，有关换向运算的有趣观点。 +在 EC2 上构建冗余备份站点时，我们的策略与使用备份数据中心基本相同，除了不必为机架中准备就绪的服务器付费，我们只需要运行 MySQL 从属即可。 。 当我们需要故障转移到 EC2 时，我们可以按需启动实例。 这样做的成本只是在另一个数据中心复制整个生产堆栈的成本的一小部分。 -干杯， -蒂姆 +![](img/fc5acb3d325b9272d01cb23ce2503d14.png) -我不知道这是否可行，因为钱是可替代的-银行从我那里获得的 1 美元报酬与自动柜员机应支付的 1 美元没有明显的不同。 +*我们最初尝试使用 MySQL 从站进入 Amazon Web Services。* -如果我使用了错误的约会资料并承诺“以后再补”，则效果不一样。 :) +幸运的是，我们无需执行故障转移计划。 但是，当我们决定要在托管数据中心和 Amazon us-east-1 地区之外提供实时流量时，我们使用 EC2 的经验使我们有足够的信心继续使用它。 我们的数据已经被复制到 us-east-1 中，因此我们只需要启动应用程序实例并在应用程序堆栈上进行一些小的工程设计即可使其适合实时请求。 -蒂姆 +AWS us-east-1 设计为只读，可与 MySQL 复制完美配合。 当最终用户向 AWS 提交新的内容时，这变得更加复杂，因为 AWS 中的 MySQL 是只读的。 我们通过编写一个基于 MQ 的提交队列解决了这个问题，该队列将写操作复制回我们的主数据中心，在此我们在 MySQL Master 上执行写操作。 在几秒钟内，更改将被复制回 AWS。 此设置运行良好，使我们能够将生产能力提高一倍，同时仍然使我们能够在必要时完全故障转移到 AWS。 不久之后，我们决定将 us-east-1 集群复制到 us-west-2，从而为我们提供了三个实时生产区域。 -我也在英国，并且同意 ATM 系统乍看之下在英国似乎并不那么清楚，但我相信它仍然是正确的。 +[ ![](img/0aebf030454a13f9c9b7b60774a640d4.png) -我相信，使 ATM 脱机的原因是 ATM 与它用于验证卡号并快速检查卡是否被举报为欺诈性的服务之间的断开连接。 每个 ATM 提供商（实际上是银行组）似乎确实要分别运行其系统，然后再将它们一起应用。 +*MySQL 从我们的托管数据中心复制到两个 AWS 区域。* -我当然已经看过自动取款机说不能显示我的余额，但是可以提款。 +为了在两个 AWS 区域与我们的托管 DC 之间路由请求，我们采用了基于 DNS 的健康检查系统。 在 EC2，我们使用在具有 EIP 的实例上运行的 HAProxy 作为负载均衡器。 这使我们在 EC2 的每个区域的每个群集获得一个公共 IP，在我们的托管数据中心的每个群集获得一个公共 IP。 我们将这些原始 IP 添加到了我们的 DNS 服务的基于 DNS 的运行状况检查池中，该池定期向每个原始 IP 发出 HTTP 请求。 DNS 服务器会拉出所有在运行状况检查中失败的原始 IP，同时平衡到其他区域的流量。 这样做的一个附带好处是，我们可以轻松地拆除一个区域并一次滚动部署（一个区域一次），让 DNS 处理流量的转移。 -如果这样的分区是为什么在周末/银行假日不进行任何交易，而您仍然可以使用您的卡，我不会感到惊讶。 +多年来，随着我们获得成千上万的客户并将流量扩展到每月数十亿的页面浏览量，我们最终获得了运行在 3 个 AWS 区域和受管理数据中心的 7 个集群中的数百个应用程序服务器。 每个集群都有一个主数据库，在三个区域中都有大量的从属链。 如果沿链上的中继从机死亡，我们将必须重建所有下游从机以重置主机位置。 从操作的角度来看，这变得非常难以管理。 我们还有两个重要的写流量瓶颈：在托管数据中心运行的 MySQL 主服务器和在所有从服务器上的 MySQL 单线程复制。 当我们不得不摄取大量新数据时，奴隶通常会落后一些，有时甚至要花 10 个小时或更长时间。 我们需要重新考虑整个堆栈。 -另一个蒂姆 +## 从干净的板岩开始 -A 罐（应该）仍代表原子。 谁想要一半的交易伪装成整个交易？ +在 2011 年底，我们的堆栈正在工作，但我们希望将其提升到更高的灵活性，性能和可靠性水平。 我们想解决我们的多区域复制问题。 我们希望摆脱单个集群，以便我们可以做更多有趣的跨集群数据关系。 我们想更快地发布。 我们希望成为更多的云原生用户，以便能够利用自动扩展等 AWS 功能。 这是很大的变化，但是我们从 Amazon Web Services 获得了一个新的 CTO，他非常支持这些计划。 -我在 atm 网络上工作了多年，是的，它们都像这样工作。 今天，大多数网络都以在线模式工作。 但是协议支持脱机交易。 请记住，这些网络也支持信用卡交易（可以在授权交易后应用提示）。 脱机模式可用于支持断开连接的情况或启用可伸缩性，验证是联机的，但金融交易是分批的。 完全断开连接的可能性较小，因为必须在线检查引脚（至少直到芯片和引脚为止）。 +### 组织和技术变更 -从 atm 到后台，事务不是原子的，如果发生通信错误，则可以撤消事务。 一些自动取款机交易被标记为强制过帐，以表明已经发放了款项，即使它们违反了办公室规定（如不透支）也已得到处理。 +我们的整体 Java 应用程序分为一组小型服务，每个小型服务均由分散的工程团队提供支持。 这些团队负责从开发到质量检查再到运营的整个服务生命周期。 此外，工程学采用敏捷作为开发方法，以前我们是在瀑布驱动下进行的。 这些更改使我们能够从高度协调的 8-12 周发布周期转变为允许任何团队随时发布。 一些团队继续进行完整的持续集成。 -这些细节中的一些是西方过去的遗迹，但是在非洲，南美和印度，长距离通信可能非常繁琐，因此中断的操作仍然非常重要。 +在技术方面，我们决定在新堆栈中全力支持 AWS。 对于我们的记录系统，我们选择 Cassandra 是因为它具有多区域复制功能（DynamoDB 在这里失败）和云原生操作质量。 出于类似原因，ElasticSearch 取代了 Solr。 -尽管 Atm 交易是免费的，但信用卡交易涉及银行收费和商人收入。 当服务不可用时，也会损害声誉。 在金融危机爆发的第一年左右，有很多关于不同机构的传言。 这些机构非常担心服务中断会触发其银行挤兑。 +### 云工程师 -干得好，保持下去 +我们成立了一个名为 Platform Infrastructure 的团队，负责构建 AWS 基础设施和云工具。 平台基础架构团队选择使用 CloudFormation 在 Amazon 的虚拟私有云环境中的三个区域（us-west-2，us-east-1 和 eu-west-1）中构建 AWS。 然后，平台基础架构团队构建了有用的微服务，例如内部 VPC DNS，内部监控，集中式日志记录，成本分析，甚至是受 Netflix 启发的“猴子”，以执行标签一致性实施。 由于所有内容都使用 CloudFormation，因此我们能够在几个小时内迅速为三个区域的 Dev，QA 和 Prod 环境启动相同的 VPC。 这个内部称为 Nexus 的新平台负责“繁重”的基础架构，并为应用程序团队构建服务奠定了坚实的基础。 -好的文章，内容翔实，有趣，重点突出。 +![](img/2135e8becff618ccfdcc34b1170ad9af.png) -Tim, +*Nexus：三个 AWS 区域中跨九个 VPC 的三个环境。 来自类似环境的 VPN。* ->可用性似乎并不是主要问题。 自动柜员机停运并不罕见 +### VPC 基础架构 -高不可用性率并不能证明可用性不是 OP 中规定的最高优先级。 它只是表明所讨论的网络在实现该优先级方面很差。 +除了环境标签，IP 范围（当然还有数据集）之外，每个 VPC 看起来都相同。 每个 VPC 使用一个/ 20 子网，分为三个/ 24 公共子网和三个/ 22 私有子网，每个 VPC 使用三个可用区。 我们的 CloudFormation 模板还使用自动缩放组 1 来为每个可用区配置 1 台 NAT 服务器，并设置路由，以便每个专用子网使用其自己的 NAT 服务器进行出站连接。 这允许 AZ 级别的隔离，并使 NAT 带宽增加三倍，而不是每个 VPC 使用单个 NAT 服务器。 ->超出您的限制将导致机器拒绝为您提供所要求的现金。 -同样，这并不是可用性优先于一致性的禁忌。 本文的风险管理部分对此进行了介绍。 +![](img/eb5c1b211a11153c77f396b631550918.png) -本文缺少的是认识到，在银行发布的实际财务更新包含的内容远不止简单的余额更新。 可能会有几十个表被更新，甚至更多。 所有这些工作必须是原子的。 ATM 网络具有备用功能，可以在多个级别上进行不可靠的通信或主机丢失，但是当消息到达银行时，它最终是一个很好的老式 ACID 更新。 ATM 和在线信用卡交易系统及其支持的登录，强制发布，预授权，部分和增量授权等功能，使网络变得非常可用，这仅仅是因为各机构已选择达成一项协议 彼此都很好。 银行系统不太愿意让提款部分过帐。 +*每个 VPC 使用三个可用区，每个可用区都有自己的 NAT 实例。* -谢谢，不错的帖子 +我们为每个工程师提供了一个完整的 AWS IAM 帐户，使他们可以不受限制地访问 Amazon 的各种更高级别的服务，例如简单工作流程服务，Elastic MapReduce 和 Redshift。 我们选择优化工程师敏捷性而不是效率。 但是为了确保我们的成本不会完全失控，平台基础架构团队会强制执行标签一致性。 为了保持一致，每个团队必须在其所有资源中使用两个标签：team 和 VPC。 没有适当标签的任何 AWS 资源都会自动终止。 拥有一致且强制的标记的一个巨大好处是，我们能够确定每个团队的确切成本。 -有趣的文章，感谢您提供信息。 +### 数据层 -真正不幸的是，信息开发人员必须受到来自 Web 开发社区的此类论点的轰炸。 +我们的数据团队提供了三项服务来处理我们的海量数据集，所有这些服务均针对开发人员的生产力和易于管理进行了优化。 为了存储通用的内容类型而不需要进行模式迁移，并且能够表达性地查询我们的数据，EmoDB 和 Polloi 诞生了。 在 Cassandra 的支持下，EmoDB 设计为使用最终一致性（AP）和多主机冲突解决方案来跨越多个数据中心。 它公开了一个非常简单的 RESTful API，允许用户创建“表”（不需要模式-仅表名和表放置），并将文档存储在这些表中。 -经典的 ATM 示例不应该从字面上理解，而是重要交易的象征。 最容易理解的一种。 +EmoDB 仍然缺少 SQL 语义，例如 where，join，group by-基本上是除主键查找和表扫描之外的任何其他语义。 这就是 Polloi 的来历。 -现代银行机构已经实施了风险管理以促进可用性的事实，并没有改变任何与 ACID 兼容的交易的重要性！ +Polloi 将实体流索引到 ElasticSearch 集群中。 每个表的索引是根据用非常简单的域特定语言（DSL）指定给 Polloi 的规则完成的。 一旦 Polloi 根据这些用户指定的规则为数据建立了索引，我们最终将获得一个功能强大的 ElasticSearch 集群，该集群不仅可以处理主键查找。 而且由于每个 Polloi 集群都有一个自定义的规则集，所以我们有多个 Elasticsearch 集群，每个集群都针对使用它们的应用程序的需求进行了调整。 应用程序可以利用 ElasticSearch 的强大功能来对 PB 级数据进行超快速的查询响应。 -在我的银行存款，我每 24 小时只能提取 500 美元（风险）（保持一致的时间）。 让我们想象一下一项新法律，银行将不再采取此类措施？ 哪里有人可以拿出大笔现金？ 银行将很快从 BASE 变为 ACID！ +ElasticSearch 仍需要与 EmoDB 保持同步，因此我们创建了数据总线以将 EmoDB 和 Polloi 结合在一起。 Databus 允许应用程序监视 EmoDB 表和文档上的更新事件，而 Polloi 侦听 Databus 上的实时更新并适当地索引数据。 -今天的最终一致性如何？ +![](img/dd67ceeca2fe2bab9d388a27bae14377.png) -这是关于分发帐单，以及在有人关心的情况下移动零碎的东西。 +*EmoDB，Polloi 和数据总线* -考虑到关于 ACID 的评论中的论点，我真的很想读这本书的续集。 \ No newline at end of file +简而言之，EmoDB 提供了一种简单的方法来存储 JSON 对象，对特定应用程序很重要的 Polloi 索引字段，并且 Databus 会将数据的更改通知 Polloi 以及其他任何人。 + +### 应用层 + +随着转向面向服务的体系结构，我们的工程师不再受限于特定的技术堆栈。 服务团队可以选择最适合他们的语言和组件。 尽管大多数团队仍然选择使用 Java 来实现其服务，但 Python 和 node.js 是另外两个受欢迎的选择。 + +此外，团队可以自由选择 Amazon 的更高级别的服务，例如简单队列服务（SQS），简单通知服务（SNS）甚至简单工作流服务（SWF）。 现在，我们最成功的服务之一就是很大程度上基于 SWF，使 Bazaarvoice 成为亚马逊最大的 SWF 用户之一。 使用这些 AWS 服务使团队能够比以前更快地构建其服务。 + +### CDN & DNS + +我们遗留在堆栈中的两个组件是 CDN 和基于 DNS 的全局流量管理层。 他们俩都运作良好，因此我们不认为需要为改变而做出改变。 + +![](img/8e2a1eb1f33f3816c5780b3d1324c6e9.png) + +*Bazaarvoice 的新堆栈的高级概述。* + +## 未来 + +随着我们在新堆栈上增加生产工作量，我们一直在寻找改进的地方。 我们计划在应用程序部署，基于代理的异常检测方面实现更多自动化，并提高我们的运营效率。 我们还构建了一些有用的 AWS 工具，希望在不久的将来开源。 + +如果您对我们架构的任何方面都感兴趣，请发表评论或 [直接与我联系](http://twitter.com/victortrac) 。 + +很好的文章。 我很喜欢阅读您如何将可搜索性与可伸缩键值存储合并。 + +解释得很好，路径清楚地显示了简单应用程序如何转换为大型企业应用程序。 + +喜欢该架构的详细视图，并且通过视觉插图更容易理解。 写得很好 + +做得好！ 我希望这会不断发展！ 这非常有帮助。 很棒的博客！ \ No newline at end of file diff --git a/docs/13.md b/docs/13.md index 18ab7b2..87e3a3a 100644 --- a/docs/13.md +++ b/docs/13.md @@ -1,188 +1,81 @@ -# QuickBooks 平台 +# 普恩斯的教训-早期 -> 原文： [http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html](http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html) +> 原文： [http://highscalability.com/blog/2007/10/8/lessons-from-pownce-the-early-years.html](http://highscalability.com/blog/2007/10/8/lessons-from-pownce-the-early-years.html) -![](img/f467ec8cf4d38d56b883aa13f1ef804a.png) +Pownce 是一种新的社交消息传递应用程序，它与 Twitter 和 Jaiku 之类的微消息竞争微消息。 仍处于封闭测试中，Pownce 慷慨地分享了到目前为止所学到的一些知识。 就像去桶中品尝年轻的葡萄酒，然后在陈酿后品尝相同的葡萄酒一样，我认为真正有趣的是跟随 Pownce，并将今天的 Pownce 与明天的 Pownce 进行比较，将其花了几年的时间。 桶。 等待 Pownce 成长，有什么教训？ -*这是 Siddharth Ram –小型企业首席架构师的特邀帖子。 [[受电子邮件保护]](/cdn-cgi/l/email-protection#c497ada0a0aca5b6b0ac9bb6a5a984adaab0b1adb0eaa7aba9) 。* +网站：http：//www.pownce.com -QuickBooks 生态系统是最大的小型企业 SaaS 产品。 QuickBooks 平台支持面向全球范围内的小型企业，其客户和会计师的簿​​记，薪资和付款解决方案。 由于 QuickBooks 还是合规&纳税申报平台，因此报告的一致性非常重要。财务报告需要灵活的查询-给定的报告可能具有数十种可以调整的不同维度。 协作需要员工，会计师和企业所有者同时进行多次编辑，从而导致潜在的冲突。 所有这些都导致在 Intuit 解决有趣的缩放问题。 +## 信息来源 -解决可伸缩性需要考虑多个时间范围和轴。 扩展不仅涉及扩展软件，还涉及人员可扩展性，流程可扩展性和文化可扩展性。 所有这些轴都在 Intuit 进行了积极的研究。 我们与员工的目标是营造一种氛围，使他们能够尽其所能。 +* [经验教训-FOWA 2007](http://www.leahculver.com/2007/10/08/pownce-lessons-learned-fowa-2007/)* [Twitter 上的 Scoble 与 Pownce](http://scobleizer.com/2007/07/04/twitter-vs-pownce/)* [Founder Leah Culver's Blog](http://www.leahculver.com) -# 背景 + ## 该平台 -QuickBooks Online 产品已有十年半的历史了。 它是作为整体构建的，没有明确的关注点分离。 整体服务良好地服务于 Intuit –每天有数百万的客户使用它进行数亿笔交易。 这部分是可能的，因为产品内置了泳道。 这样就可以按公式拆分（客户在特定分片中“归位”）进行缩放。 如今，我们正在努力将整体拆分为多种服务，并迁移到 AWS 作为主要托管解决方案。 + * 蟒蛇* Django 用于网站框架* [Amazon S3](http://www.highscalability.com/build-infinitely-scalable-infrastructure-100-using-amazon-services) 用于文件存储。* [适用于桌面应用程序的 Adobe AIR](http://labs.adobe.com/technologies/air/) （Adobe Integrated Runtime）* 记忆快取* 在 Facebook 上可用* [Timeplot](http://simile.mit.edu/timeplot/) for charts and graphs. -## 数字 + ## 统计资料 -* 全球小型企业最大的 SaaS 产品 + * 经过 4 个月的开发，并于 6 月进行了仅限受邀发布。* 最初是 Leah 的业余爱好项目，然后与 Digg 的 [Daniel Burka](http://deltatangobravo.com/) 和 [Kevin Rose](http://kevinrose.com/) 一起滚雪球成为一匹真正的马。* 小型 4 人团队和一位网站开发人员。* 自筹资金。* 一个 MySQL 数据库。* 功能包括： + -短消息，邀请事件，链接，文件共享（例如，您可以将 mp3 附加到消息中）。 + -您可以将用法限制为特定的朋友子集，并且可以将朋友分组。 因此，您可以将 mp3 发送给特定的朋友组。 + -它没有 SMS 网关，IM 网关或 API。 -* 超过 500 万的台式机和网络客户 + ## 架构 -* 每天处理 250M +请求 + * 选择 Django 是因为它具有活跃的社区，良好的文档，良好的可读性，可扩展且可自动生成管理。* 选择 S3 是因为它最小化了维护并且价格便宜。 对他们来说是可靠的。* 选择 AIR 是因为它具有良好的嗡嗡声，易于开发，创建了不错的 UI 且是跨平台的。* 数据库一直是主要瓶颈。 攻击并修复缓慢的查询。* 静态页面，对象和列表使用 memcached 进行缓存。* 排队用于将更复杂的工作（例如发送便笺）推迟到以后。* 使用分页和良好的 UI 来限制执行的工作量。* 良好的索引有助于提高好友搜索的性能。* 在社交网站中： + -轻松创建和销毁关系。 + -朋友关系是正确显示最重要的信息，因为人们真的很在乎它。 + -在线世界中的朋友会产生现实效果。* 功能“偏向”于可伸缩性 + -您必须收到已经在 Pownce 上的人的邀请。 + -受邀者的数据中心只能承受增加的负载。 盲目上传地址簿可以成倍地吸引新用户。 限制不自然的增长是一个好主意。* 它们的功能集将扩展，但尚未准备好提交给 API。* Revenue model: ads between posts. -* 年增长率超过 40％ + ## 得到教训 -* 通过 AWS 进行全球扩展 + * 到目前为止，他们经历了四大课程： + -考虑技术选择。 + -多做点事。 + -善待您的数据库。 + -期待任何事情。* 拥有一个小的敬业团队，人们可以处理多个工作。* 使用开源。 它有很多，它是免费的，并且有很多很好的帮助。* 使用您的资源。 从网站文档中学习，使用 IRC，建立网络，参与社区和知识交流。* 通过确保在实现复杂功能之前确实需要它们，从而减少了数据库的工作量。* 培养有准备的头脑。 期待意料之外的事情，并迅速对不可避免的问题做出反应。* 使用版本控制并进行备份。* 维护大量与性能相关的统计信息。* 不要向用户承诺最后期限，因为您可能没有做到。* 与您的社区交流。 我特别喜欢这个，希望以后能做得更多。 我希望这种态度能够在增长中生存。 + -让他们知道您在做什么，以及有关新功能和错误修复的信息。 + -亲自回应各个错误创建者。* 看一下框架的自动生成的查询。 他们可能会吮吸。* 性感的用户界面和良好的动态营销活动可以吸引大量用户。 -* 全球约有 2,000 名工程师在产品上工作。 + ## 相关文章 -* 2000+ 3 个基于 Intuit 平台构建的 和 参与者应用程序 + * [扩展 Twitter：使 Twitter 速度提高 10000％](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster)。 -## 技术 +您在本文中多久一次错误地将 Pownce 拼写错误？ -* Java / JVM 是主要服务/后端 +喜欢这个网站。 注意您在帖子标题中拼写了 Pownce。 应该是 Pownce 而不是 Pounce。 -* 多语言持久性–不同的用例需要使用不同的存储技术，QuickBooks 平台将 RDBMS（Oracle / MySQL），Neo4J 和 Cassandra 用于 OLTP 和 Hadoop & Vertica 进行分析 +大卫 -* 前端已使用 ReactJS 进行了重建，我们了解到扩展不仅适用于后端-前端扩展是我们开发的一项新技能。 +>您在本文中多久一次错误地将 Pownce 拼写错误？ -* 监控是使用多个内部和现成的工具完成的，现成的主要工具是 Splunk 和 New Relic +哦，看起来真的很蠢。 从好的方面来说，它进行了拼写检查:-) -* 通过企业 github 进行代码管理 +请不要让该站点陷入另一个 Web 2.0 圈套。 我对 Pownce 没什么兴趣-如今提到的一切都是必要的。 我们是否可以有更多有关具有实际扩展问题，新颖的解决方案和有趣的知识的网站的文章？ -* ActiveMQ 和 Kafka 处理异步消息 +事先道歉，但我已经了解有关 pownce 的足够信息了……从中学到任何东西都是最重要的。 pownce 教给所有人的唯一一件事是，如果您的人脉关系良好，那么您就可以为任何垃圾而大肆宣传。 哇，我永远都无法想象。 这肯定在硅谷从未发生过。 -* Ansible 和 Chef 用于配置管理 +-4 个人不是一个小团队。 一个 4 人的团队可以构建比 pownce 还要多得多的真实软件。 -* 大量使用边缘缓存和 Akamai WAA +-使用开源。 它有很多，它是免费的，并且有很多很好的帮助。 +好的。 他们看了什么封闭源技术？ 它要多少钱？ 它可能提供什么好处？ 或者，也许您只是想拍打自己的背部。 多一点。 -## 文化 +-使用版本控制并进行备份。 +谢谢。 我有没有告诉你你是多么的出色和聪明？ -* 每个服务都有定义了 RTO 和 RPO 的 HA / DR。 我们每周执行 HA / DR 计划，以确保在发生常规事件时对客户的影响很小甚至没有。 这是所有 SaaS 产品都需要计划和执行的最佳实践。 +-数据库一直是主要瓶颈。 攻击并修复缓慢的查询。 +-查看框架的自动生成的查询。 他们可能会吮吸。 +好吧，我猜想如果我 24 岁的话，这对我也是一个重要的学习。哦，对不起，我的意思是 24 岁而毫无头绪。 -* 高度重视弹性。 服务不可用通常并不意味着客户知道它。 +即使作为 DeVry 技术学院的家庭作业，Pownce 也不是什么了不起的。 +只是工作中的名人-硅谷的洛杉矶化-事实是，这并不是天生的错误。 只是不要将其与任何实际的软件工程相混淆。 -* 服务在内部服务门户中发布。 这使工程师可以重用其他团队构建的服务，并减少服务克隆。 +正如我在介绍中提到的那样，很有趣的是看到它们随着时间的变化和发展。 一些通常可能很有趣的事情：它们与台式机组件一起使用，这在如今已经很少见了； 从一开始就使用 S3； 以客户为中心 以及任何创业公司都会死的蜂鸣器。 从技术上讲可能还不是很多，但是事情的开始是最美好的，我喜欢抓住初创公司的时代精神。 -* 性能是根据 TP99，TP90 和 TP50（通常更高）来衡量的。 TP50 代表第 50 个 第 个百分位客户体验的体验。 我们的目标是 1 秒的 TP50 和 2 秒的 TP90。 （即少于 10％的客户在任何给定页面上的页面加载时间超过 2 秒）。 +>查看框架自动生成的查询。 他们 +>可能会吮吸。 -* 客户互动失败（FCI）是我们跟踪的另一个关键指标。 与客户的每次失败交互（HTTP 4xx / 5xx）都被视为失败的交互。 我们的目标是使每项服务的 FCI 都低于 0.025％。 - -* 服务团队拥有端到端的服务。 他们负责与 devops 模型一致的服务维护和正常运行时间。 PagerDuty 用于提醒呼叫人员出现问题和参与恢复。 - -* 您无法改善无法测量的内容。 通过近乎实时的仪表板，可以在公司的可用性，性能，可扩展性和质量指标方面广泛了解公司。 这是驱动组织行为的关键。 - -* 我们正在过渡到反应性，松散耦合的系统 ，该系统可增强扩展能力。 但是，这需要仔细考虑如何处理系统中最终的一致性。 - -* 工程师对系统中的每个故障执行 RCA（根本原因分析）。 RCA 已由工程领导审核。 我们将 5 个“为什么”和“鱼骨”应用于每个 RCA。 失败是一位出色的老师 。 - -* 强烈的代码意识和域所有权。 - -* 任务驱动。 当人们看到自己对客户的影响时，便会尽自己最大的努力。 - -* 在质量，性能，可用性和安全性上丝毫不妥协。 - -* 持续部署和功能切换使我们能够快速交付 - -## 可伸缩性中的有趣挑战 - -# 缩放比例特性 - -QuickBooks Online 之类的产品具有与其他 SaaS 产品不同的缩放特性。 报表查询可能已应用了许多其他过滤器。 这些查询在公司之间通常是不同的。 报告会产生税收后果，因此必须始终与账簿保持一致。 会计和小型企业所有者可能同时进行多次编辑，才能进行协作。 该软件需要确定如何处理冲突。 所有这些导致在 Intuit 的 QuickBooks 平台上进行扩展的有趣方式。 - -# 变量 - -QuickBooks 平台为全球数百万家小型企业，其客户和会计师提供服务。 为客户提供各种用例：产品需要解决的可变性包括： - -* 设备多样性–我们根据需要为客户提供服务-台式机，移动设备，在线 - -* 地理多样性–在全球范围内使用，伴随着法规的复杂性，要​​解决的税收往往非常本地化和专业化 - -* 合规性多样性–不同的政府机构（例如工资税）对合规性有不同的规定 - -* 产品多样性–根据员工人数，他们要解决的市场性质（例如，基于产品的业务与基于服务的业务），不同的客户群具有不同的需求 - -* 工作流的多样性–公司可能拥有执行（并被授予）产品子集的工人。 例如，应收账款业务员将仅看到应收帐款流量。 员工通常不执行业务报告。 - -这是我们处理的多样性的子集。 尽管解决了很多多样性问题，但平台始终需要解决一些基本问题。 安全性，隐私性，可伸缩性和质量是软件基本构建模块的一部分。 - -# 缩放哲学 - -QuickBooks 平台通常在以下三个方面进行扩展，从而遵循“可扩展性多维数据集” 模型： - -![](img/e14850f4600ff2e4f07d4add57be0c4a.png) - -## X 轴–只读副本 - -X 轴主要用于只读副本。 与许多 SaaS 产品一样，与写入次数相比，读取次数很多。 常见的且相对昂贵的读取操作是报告。 小型企业和会计师需要了解他们的业务状况。 我们通过 QuickBooks Money Bar 提供见解，并通过大量报告（例如资产负债表，损益报告）提供更详细的见解。 只读副本使我们既可以减少访问的热点，又可以提供预先计算的报告 - -## Y 轴-服务 - -扩展的第二个方面是在不同的服务中破坏产品。 QuickBooks 平台建模为 14 个不同的域，这些域组成了产品。 服务 API 现在是第四个修订版– V3 QuickBooks API 可以在 [http://developer.intuit.com](http://developer.intuit.com) 中找到。 - -### Z 轴-公式拆分 - -Z 轴指的是“分片”（sharding）-允许大范围缩放的非规范化数据。 QuickBooks 根据公司的属性来拆分客户。 然后，每个分片将与具有类似属性的其他公司共享。 - -### C 轴 - -除了这些方面，我们经常谈论“ C”轴-文化轴，这是我们扩展规模的关键方法。 在 C 轴上对我们的主要增强是（a）度量文化–您无法解决无法观察到的问题（b）通过 devops 模型拥有所有权的文化，以及（c）我们做任何事情的客户支持的思想。 - -### 缩放前端 - -在 200KLOC 以上，QuickBooks onlike 具有非常大的 Javascript 占用空间。 扩展前端的一部分意味着要理解如何确保更改被隔离并且组件可重复使用–到 3 rd 参与者可以直接插入前端的地步，并且 任何遵循规则的人都可以贡献力量。 缩放还意味着在样式上具有统一性，易于坚持。 - -## 公有云之旅 - -Intuit 的一项关键策略是将所有软件资产移至 AWS。 在公共云中，给定共享的基础架构，还需要考虑安全性和隐私性。 在将软件迁移到 AWS 时，我们使用以下一般原则： - -* 必须保护每个端点。 在公共云中，我们不能假设服务之间的链接是安全的端点。 - -* 每个 Intuit 和 AWS 平台服务都必须是可观察的。 这种可观察性是能够分析欺诈和安全性访问的关键。 - -* 提升并移动+分解。 在适当的情况下，我们将分解为服务并迁移到公共云。 对于较大的系统，我们进入 AWS 基础架构并就地分解。 - -* 多区域 DR。 区域中断发生。 我们希望即使在单个地区受到影响时也能够提供服务。 - -* 在本地服务客户。 安全港 和性能都决定了靠近客户的数据存储。 这就要求客户必须在本地区域“居住”（例如，在欧洲的 AWS 数据中心之外服务的欧盟客户）。 - -* 爆炸半径遏制。 “无共享”方法可确保我们限制爆炸半径。 系统中断应该导致本地事件，而不是全局事件。 - -## 主要课程 - -* 3 轴缩放是关键。 知道哪些轴适用于正确缩放有助于缩放。 - -* 确保可以控制影响。 必须充分理解和测试系统的爆炸半径。 - -* RCA –失败是一位了不起的老师。 浪费失败的教训是可耻的。 架构师负责分析故障并找出根本原因。 - -* 不要低估了对在公共云中保护软件的重新思考的程度。 - -* Dogfood。 公司工程师使用的服务应与为 3 个 和 参与方开发人员提供的服务相同。 - -* 了解您的 KPI 并能够预测性能曲线的样子–这有助于快速识别出问题所在。 - -* 也可以缩放前端，而不仅仅是后端。 - -嗨，感谢您的帖子，它非常有用。 我想知道为什么您同时使用 ansible 和 Chef，因为我希望一家公司同时使用其中一种？ - -嗨，查理， - -并没有 Ansible 和 Chef 的强烈技术理由。 不同的团队使用了不同的技术。 随着时间的流逝，我们将逐步淘汰其中之一。 - -悉达思 - -您好 Siddharth， - -感谢您花时间描述系统。 由于您将整体拆分为服务，因此如何管理服务之间的安全性和身份验证？ - -嗨，knguyen， - -好问。 在整体中，通信相对容易-只需进行另一个函数调用即可。 在分布式系统中，难度会增加一些-但技术仍然非常相似。 - -身份验证和安全协议是非常标准的。 Intuit 管理自己的身份系统。 每个请求必须具有身份验证上下文-包括服务器-服务器调用。 这些将很快到期，并分配新的票证。 SSL / TLS 是用于有线加密，客户端-服务器以及服务器-服务器通信的标准问题。 分析/监视查找访问模式中的异常。 - -您如何管理服务之间的安全性和身份验证？ - -据我所知，Intuit 使用 google oauth1.0 进行身份验证，这基本上是基于令牌的身份验证系统。 例如，您有一个使用者密钥和一个使用者密钥，您将获得一个请求密钥和请求令牌，然后吐出一个访问令牌和访问密钥。 令牌有效期为 6 个月，不确定令牌何时到期才能访问那些基于 JAVA 的 REST API 和安全标准 SHA2 算法。 我写了一篇关于 SSL 握手的文章。 它应该有助于提供见解。 - -参考： -https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/ - -嗨， -很棒的文章，感谢您的分享，您可以解释一下是否有建立另一个 QuickBooks 或 Zoho Books 的余地？ -谢谢 -Divya， -[Quickbook Developer](http://www.catchexperts.com/quickbook-online-training) \ No newline at end of file +这是 Ruby on Rails Active Record 的开掘吗？ ;） \ No newline at end of file diff --git a/docs/130.md b/docs/130.md index b590b99..2720d25 100644 --- a/docs/130.md +++ b/docs/130.md @@ -1,58 +1,282 @@ -# Facebook 的网络秘密 +# HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息 -> 原文： [http://highscalability.com/blog/2013/4/23/facebook-secrets-of-web-performance.html](http://highscalability.com/blog/2013/4/23/facebook-secrets-of-web-performance.html) +> 原文： [http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html](http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html) -![](img/9e91ed9216d56753c708d226148e5656.png) +![](img/1f990901f6dd64766ac61ad0b37e95a1.png) -*这是我为[边界博客](http://boundary.com/blog/)所做的采访[的第 1 部分的转贴。](http://boundary.com/blog/2013/04/22/todd-hoff-on-facebook-secrets-of-web-performance/)* +*本文来自 [Zuhaib Siddique](http://www.linkedin.com/in/zuhaib) 的采访， [HipChat ]](https://www.hipchat.com/) ， 团队聊天和即时消息的制造商。* -**边界：** **如果要在网络上管理最大的大数据项目，Facebook 的秘诀是什么？** +HipChat 始于一个不寻常的领域，您可能认为它没有太大的希望，即企业组消息传递，但是随着我们了解到那里有金 [企业群 [](http://www.developereconomics.com/still-building-consumer-apps-enterprise-pays-4x/) 。 这就是为什么 Atlassian 是 JIRA 和 Confluence 之类的工具开发者，他们 [在 2012 年收购了 HipChat](http://blog.hipchat.com/2012/03/07/weve-been-acquired-by-atlassian/) 。 -**Hoff：**我们从前几位工程总监的 Facebook 内幕人物 [Aditya Agarwal](http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html) 和 [Robert Johnson](http://highscalability.com/blog/2010/8/2/7-scaling-strategies-facebook-used-to-grow-to-500-million-us.html) 了解到了他们的秘密： +在一个不经常听到的故事中，大父母的资源和联系实际上帮助 HipChat 进入了 [指数增长周期](https://s3.amazonaws.com/uploads.hipchat.com/10804/368466/10joz8sztfw4dfc/HipChat1B.jpg) 。 他们已达到 12 亿条消息存储标记，现在正每隔几个月发送，存储和建立索引的消息数量就增加一倍。 -* **缩放需要迭代**。 解决方案通常从一开始就起作用，但是您必须随时进行修改。 例如，PHP 最初很容易使用，但是当您拥有成千上万的 Web 服务器时，不是一个好的选择。 +这种增长给曾经足够的基础架构带来了巨大压力。 HipChat 展示了一种常见的缩放模式。 从简单开始，经历流量激增，然后思考我们现在该怎么办？ 通常，使用大型计算机是最佳的选择。 他们做到了。 这给了他们一些喘息的空间，以便弄清楚下一步该怎么做。 在 AWS 上，在某个拐点之后，您将开始使用 Cloud Native，即水平扩展。 这就是他们所做的。 -* **缩放需要迭代**。 你可以再说一遍。 +但是故事有一个转折。 除了云/ SaaS 版本之外，安全方面的考虑还推动了本地版本的 HipChat 的开发。 我们将在本周晚些时候的[帖子](http://highscalability.com/blog/2014/1/8/under-snowdens-light-software-architecture-choices-become-mu.html)中详细讨论这一有趣的发展。 -* **不要过度设计**。 在扩展系统时，只需使用所需的内容即可。 找出您需要在解决方案上进行迭代，优化的地方或自己完全构建堆栈的一部分的位置。 +虽然 HipChat 并非 Google 规模，但可以从 HipChat 中学习很多有关它们如何及时索引和搜索数十亿条消息的知识，这是 IRC 和 HipChat 之类的主要区别。 在不丢失消息的情况下索引和存储负载下的消息是挑战。 -* **为作业**选择合适的工具。 意识到任何选择都会带来开销。 如果您确实需要使用 Python，请继续，我们将尽力帮助您成功。 但是，有了这种选择，通常会在部署，监视，操作等方面产生开销。 +这是 HipChat 走的路，您可以学到什么？ 让我们看看… -* **获得正确的文化。** 在内部建立环境，以促进首先构建正确的事物并根据需要进行修复。 不要担心创新，大事，大胆思考以及在建造第一件东西之后需要建造的下一件东西。 隔离您重视并希望保留的文化部分。 它不会自动发生。 +## 统计信息 -* **快速移动**。 首先进入市场。 没事就可以了 例如，Facebook 在由三个人开发的 HipHop 上运行其整个 Web 层。 这是一个冒险的策略。 它会定期关闭网站（内存不足，无限循环），但他们发现如何使网站正常运作，因此有很大的潜在收益。 +* 每秒 60 条消息。 -* **授权小型团队**。 小团队可以做伟大的事情。 Facebook 搜索，照片，聊天和 HipHop 都是小团队的结果。 找到合适的人，赋予他们权力，让他们工作。 +* 已存储 12 亿个文档 -* **人们最重要**。 是构建和运行系统的人。 最好的扩展工具是能够处理任何事情的工程和运营团队。 +* 4TB EBS 突袭 -* **水平缩放**。 要处理指数级增长的流量，需要在许多计算机之间任意分配负载。 +* AWS 上的 8 台 ElasticSearch 服务器 -* **测量所有内容**。 生产是真正有用的数据的来源。 测量系统和应用程序级别的统计信息，以了解正在发生的事情。 +* 26 个前端代理服务。 在后端应用服务器中将其翻倍。 -* **赋予团队控制权和责任感**。 责任需要控制。 如果团队负责某件事，他们也必须控制它。 +* 18 人 -所有这些原则共同作用，形成一个自我强化的良性循环。 除非您有一支拥有控制和责任感的小型团队，否则您将无法快速前进。 除非您将这些更改投入生产并衡量结果，否则您将无法知道更改的工作方式。 除非人们对移出工作代码负责，否则您无法将代码移入生产环境。 除非您弄清楚如何水平缩放，快速移动并测量所有内容，否则您将无法处理磅秤，所有这些都取决于好人。 +* 0.5 TB 的搜索数据。 -但是，以上并非全部。 机会的作用并不那么明显。 我们经常看到的一种模式是，处于领先地位的公司先于其他所有人看到问题，因此他们首先解决了所有其他问题。 我们看到来自 Google，Netflix，Twitter 和 Facebook 等技术热点的创新浪潮。 +## 平台 -**边界：您认为其他哪些主要网站在按需扩展，保持用户满意和高响应时间方面做得很好？** +* **托管**：带有 75 个实例的 AWS EC2 East 当前全部为 Ubuntu 12.04 LTS -**Hoff：**我们的行业很棒。 人们总是愿意分享他们的经验，分享他们的代码并谈论有效的方法。 我的妻子是一名税务会计师，他们肯定没有相同的氛围，这让人有点难过。 在这个领域有很多令人难以置信的聪明和热情的人，总的质量只会随着越来越多的人谈论如何制造好东西而提高。 +* **数据库**：当前用于聊天记录的 CouchDB，正在过渡到 ElasticSearch。 MySQL-RDS 的其他所有功能 -对我来说，显而易见的是，拥有一个优质的网站和共享的意愿是相互联系的。 我可以列出许多公司属于此类，但这些公司比较突出：Twitter，Etsy，Facebook，Google，Netflix，Amazon 和 StackExchange。 其他一些重要的贡献者包括：Airbnb，Tumblr，Instagram，TripAdvisor，Heroku，Prismatic，37signals，Pinterest 和 Yahoo。 +* **缓存**：Redis -从字面上可以提到其他数百个，但是这些公司为推动 Web 性能的发展不断做出了积极的贡献。 不过，我已经很难过，因为我知道我想念一些。 +* **搜索**：ElasticSearch -我不得不说，这篇文章中的建议是完全没有价值的！ 真是浪费时间！ +* **队列/工作服务器**：Gearman（队列）和 [Curler](https://github.com/powdahound/curler) ，（工作人员） -是的-太棒了 完美主义是一个大问题，它使许多组织瘫痪。 +* **语言**：Twisted Python（XMPP 服务器）和 PHP（Web 前端） -而且我喜欢，如果他们对现有技术不满意，他们会无所畏惧地自行构建堆栈。 IT 界流传的最糟糕的城市神话之一是，如果存在与您所做的工作遥不可及的事情，那么您应该毫无疑问地使用它。 大人物没有遵循这个神话-这是他们是大人物的原因之一。 :) +* **系统配置**：开源 Chef + Fabric -谢谢你！ +* **代码部署**：Capistrano -没错，凯尔（Kyle），最糟糕的神话是：“不要发明轮子”！ -有时您不得不一次又一次地重新发明轮子：) +* **监视**：Sensu 和 monit 泵送警报到 Pagerduty -Facebook 可以承受破坏-“没事就可以了”-因为它并不重要！ \ No newline at end of file +* **图表**：statsd + Graphite + +## 产品 + +* 交通非常繁忙。 在周末和节假日，这里会很安静。 在高峰负载期间，每秒数百个请求。 聊天消息实际上并不占流量的大部分; 它是状态信息（离开，空闲，可用），人们在连接/断开连接等。因此，每秒 60 条消息可能看起来很低，但这只是一个平均值。 + +* HipChat 希望成为您的通知中心，您可以在这里与团队合作，并从工具和其他系统获得所有信息。 帮助使每个人都处于循环中。 特别是在远程办公室。 + +* 之所以在 IRC 上使用 HipChat 的主要原因是，HipChat 可以存储和索引每个会话，以便以后可以搜索它们。 强调搜索，因此您可以留在 HipChat 中。 使用此功能对团队来说是个胜利，您可以随时返回并记住发生了什么以及您同意做什么。 它还会将消息路由到同一用户拥有的多个设备，并在发送消息时无法访问您的设备时进行临时消息缓存/重试。 + +* 增长来自更多的客户，但随着更多的客户在每个站点使用该产品，其参与度也随之提高。 他们的 API 集成也看到了增长。 + +* 消息的存储和搜索是其系统中的主要可伸缩性瓶颈。 + +* HipChat 使用 XMPP，因此任何 XMPP 客户端都可以连接到系统，这对于采用是一个巨大的胜利。 他们建立了自己的本机客户端（Windows，Linux，Mac，iOS，Android），并具有扩展功能，例如 PDF 查看，自定义表情符号，自动用户注册等。 + +* 不久前，将 Wiki 之类的工具引入企业文化几乎是不可能的。 现在，企业级工具似乎已被接受。 为什么现在？ + + * 基于文本的通信现在很普遍并且被接受。 我们拥有短信，IM 和 Skype，因此现在很自然地使用聊天工具。 + + * 分散的工作团队的兴起。 团队越来越分散。 我们不能只是一起坐下来听讲座。 需要记录所有内容，这意味着组织交流被视为一项重要资产。 + + * 增强功能。 内嵌图像，gif 动画等功能使它变得有趣，吸引了更广泛的人群。 + +* HipChat 具有 [API](https://www.hipchat.com/docs/api) ，该 API 使得可以编写类似于 [IRC 机器人](http://en.wikipedia.org/wiki/Internet_Relay_Chat_bot)的工具。 示例用法用于 Bitbucket 提交。 在 10:08，开发人员 X 提交了一些代码来修复错误。 它通过 HipChat 发送，并直接链接到代码提交和提交日志。 全部自动化。 Bitbucket 提交击中了 Web 钩子，并使用其中一个插件发布信息。 插件可帮助您编写自己的机器人。 转到您的 Bitbucket 帐户。 假设我有我的 API 令牌，并且每次提交时都想发布到此 API。 对于 GitHub 类似地工作。 + +* 从客户端上的 Adobe Air 开始，它泄漏了内存并会关闭计算机。 因此移至本机应用程序。 痛苦，但很好。 他们在公司各个部门的所有平台上都有用户。 您需要成为用户所在的地方。 希望用户在所有操作系统上都拥有出色的体验。 用户是所有人，而不仅仅是技术专家。 + +## XMPP 服务器体系结构 + +* HipChat 基于 XMPP，消息是 [XMPP 节](http://xmpp.org/rfcs/rfc3920.html) 内的任何内容，可以是一行文本或日志的较长部分 输出。 他们不想谈论他们的 XMPP 体系结构，因此没有很多细节。 + +* 他们没有使用第三方 XMPP 服务器，而是使用 Twisted Python 和 XMPP 库构建了自己的服务器。 这允许创建可扩展的后端，用户管理以及轻松添加功能，而无需与其他人的代码库抗衡。 + +* AWS 上的 RDS 用于用户身份验证以及事务和 SQL 有用的其他区域。 这是一项稳定，可靠的技术。 对于本地产品，他们使用 MariaDB。 + +* Redis 用于缓存。 诸如哪些用户位于哪个房间，状态信息，谁在线等信息，因此与连接到哪个 XMPP 服务器无关紧要，XMPP 服务器本身不是限制。 + + * 痛点是 Re​​dis 尚未聚类（尚未）。 为了实现高可用性，使用了热/冷模型，因此从器件可以使用了。 从主节点到从节点的故障转移大约需要 7 分钟。 奴隶促销是手工完成的，不是自动化的。 + +* 增加的负载暴露了代理服务器以及它们可以处理多少个客户端的弱点。 + + * 这是一个实际的问题，因为不丢失消息是一个高度优先事项。 客户表示不丢弃消息比低延迟更重要。 用户宁愿迟到也不愿迟到。 + + * 使用 6 个 XMPP 服务器，系统运行良好。 随着连接数量的增加，他们开始看到不可接受的延迟。 连接不仅来自客户端，还包括支持其编程界面的机器人。 + + * 作为第一步，他们将前端服务器和应用程序服务器分开。 代理处理连接，后端应用程序处理节。 前端服务器的数量由活动的侦听客户端的数量决定，而不是由发送的消息数决定。 在提供及时服务的同时保持如此多的连接打开是一个挑战。 + + * 解决数据存储问题后，计划将研究如何优化连接管理。 Twisted 效果很好，但是它们之间有很多联系，因此必须弄清楚如何更好地处理它。 + +## 存储体系结构 + +* 在 HipChat 上增长的 10 亿条消息不断增长的同时，他们突破了 CouchDB 和 Lucene 解决方案存储和搜索消息的限制。 + + * 认为 Redis 将是失败点。 以为 Couch / Lucene 就足够了。 没有进行适当的容量规划，也没有查看邮件的增长率。 增长速度超出了他们的想象，因此不应该过多地关注 Redis 而是关注数据存储。 + + * 当时，他们相信通过增加更多的功能进行扩展，然后再升级到越来越大的 Amazon 实例。 他们认为，随着这种方法的发展，这种方法只能再使用 2 个月。 因此，他们必须做一些不同的事情。 + + * Couch / Lucene 一年未更新，因此无法进行修改。 另一个原因的另一个原因。 + +* 在亚马逊上大约有十亿条消息是一个转折点。 有了专用服务器和 200 Gig 的 RAM，它们以前的体系结构可能仍然有效，但在资源有限的云中却无法实现。 + +* 他们想留在亚马逊上。 + + * 喜欢它的灵活性。 只需旋转一个新实例并进行调整即可。 + + * 亚马逊的脆弱让您发展得更好。 不要将所有鸡蛋都放在一个篮子里，如果某个节点出现故障，您已经处理好了，否则某些用户的流量将会丢失。 + + * 使用动态模型。 可以快速丢失实例并启动新实例。 云原生类型的东西。 随时杀死一个节点。 杀死 Redis 大师。 5 分钟后恢复。 目前已划分为所有四个美国东部可用区，但尚未跨多个区域。 + + * EBS 仅使您拥有 1TB 的数据。 他们碰到这个限制时还不知道这个限制。 使用 Couch，他们遇到了 EBS 磁盘大小限制的问题。 HipChat 的数据为 0.5 TB。 要进行压缩，Couch 必须将数据复制到压缩文件中，从而使空间增加了一倍。 在周末进行压缩时，在 2 TB RAID 上达到极限。 不需要 RAID 解决方案。 + +* 无法选择 Amazon DynamoDB，因为他们正在启动 HipChat 服务器，这是防火墙后面的托管服务。 + + * HipChat Server 推动技术堆栈上的决策。 私有版本是您自己的解决方案的主机。 某些客户无法使用云/ SaaS 解决方案，例如银行和金融机构。 NSA 吓坏了国际客户。 雇用了两名工程师来创建产品的可安装版本。 + + * Redis Cluster 可以是自托管的，并且可以像 ElasticSearch 一样在 AWS 上运行。 他们使用本地版本的 MariaDB 代替 RDS。 + + * 无法考虑完整的 SaaS 解决方案，因为这将是一个锁定。 + +* 现在过渡到 ElasticSearch。 + + * 已移至 ElasticSearch 作为其存储和搜索后端，因为它可以吃掉他们可以提供的所有数据，它具有很高的可用性，只需添加更多节点即可透明地进行扩展，它是多租户的，可以通过分片和透明方式进行透明 复制处理节点丢失，它建立在 Lucene 之上。 + + * 确实不需要 MapReduce 功能。 研究了 BigCouch 和 Riak Search（看起来效果不佳）。 但是 GET 上的 ES 性能相当不错。 喜欢删除组件的想法，少了一件麻烦的事。 ES HA 使他们对系统的可靠性感到非常有信心。 + + * 与 Lucene 兼容是一个巨大的胜利，因为他们所有的查询都已经与 Lucene 兼容，因此这是自然的迁移途径。 + + * 客户数据千差万别，从聊天记录到图像，因此响应类型无处不在。 他们需要能够快速引导来自超过 12 亿个文档的查询数据。 + + * 在一个越来越普遍的举动中，HipChat 也将 ElasticSearch 用作其键值存储，从而减少了所需的数据库系统数量，从而降低了整体复杂性。 性能和响应时间是如此之好，他们以为为什么不使用它呢？ 响应时间在 10 毫秒至 100 毫秒之间。 它在某些区域击败了 Couch，而前面没有任何缓存。 为什么要使用多种工具？ + + * 使用 ES 时，节点可能会宕机而没有人注意，您将在重新平衡时收到有关 CPU 使用率过高的警报，但它一直在困扰。 + + * 有 8 个 ES 节点来处理流量的增长。 + + * 与所有基于 Java 的产品一样，JVM 调整可能很棘手。 + + * 要使用 ES，必须对您要使用的堆空间进行容量规划 + + * 测试缓存。 ES 可以缓存过滤器结果，速度非常快，但是您需要大量的堆空间。 在 8 个盒子上有 22 个堆的内存时，打开了缓存后，内存耗尽。 因此，除非有计划，否则请关闭缓存。 + + * 缓存出现问题，因为它会遇到内存不足错误，然后失败。 群集在几分钟内自我修复。 只有少数用户注意到了问题。 + +* 由于网络不可靠，Amazon 上的自动故障转移是有问题的。 在集群中，这可能会导致选举错误地发生。 + + * 用 ElasticSearch 解决这个问题。 最初有 6 个 ES 节点作为主节点运行。 节点将耗尽内存或遇到 GC 暂停，最重要的是网络丢失。 然后其他人将不再能看到主人，也无法举行选举并宣布自己为主人。 他们的选举架构存在缺陷，即他们不需要法定人数。 因此，出现了脑裂。 两位大师。 造成了很多问题。 + + * 解决方案是在专用节点上运行 ElasticSearch 主服务器。 他们要做的就是成为主人。 从那以后一直没有问题。 母版负责处理分片的分配方式（主要是谁），并映射副本分片的位置。 由于主机可以以出色的性能处理所有重新平衡，因此使重新平衡更加容易。 可以从任何节点查询，并将自己做内部路由。 + +* 使用月份索引。 每个月都是一个单独的索引。 每个主索引都有 8 个分片，然后在其上有两个副本。 如果一个节点丢失，系统仍然可以运行。 + +* 没有将 RDS 移入 ES。 他们需要 SQL 的东西留在 RDS / MariaDB 中，通常是用户管理数据。 + +* 在主/从设置中，Redis 中有大量缓存，直到发布 Redis Cluster。 有一个 Redis stat 服务器，它在一个房间里，并且离线。 Redis 历史记录会缓存最后 75 条消息，以防止在首次加载会话时不断访问数据库。 内部状态或快速数据的状态，例如登录的人数。 + +## 常规 + +* Gearman 用于异步工作，例如 iOS 推送和传递电子邮件。 + +* AWS West 用于灾难恢复。 一切都会复制到 AWS West。 + +* Chef 用于所有配置。 ElasticSearch 为厨师提供了不错的食谱。 易于上手。 与 Chef 一样，因为您可以开始编写 Ruby 代码，而不使用 Puppet 风格的 DSL。 它还有一个不错的活跃社区。 + +* 采集经验。 他们现在可以使用公司的核心资产和人才，但是 Atlassian 不会弄乱什么可行，我们出于某种原因向您购买了。 可以在内部询问，例如，如何扩展 ElasticSearch 以及 Atlassian 中的其他人何时需要帮助才能介入。总体而言，良好的经验。 + +* 团队结构扁平。 还是一个小团队。 目前约有 18 人。 两个人在发展。 平台，iOS，Android，服务器端的一些开发人员以及 Web 开发工程师（法国）。 + +* Capistrano 用于部署到所有盒子。 + +* Sensu 用于监视应用程序。 忘记监视 ElasticSearch 节点的堆空间，然后遇到 OOM 问题，而没有任何通知。 当前占堆的 75％，这是他们想要的最佳位置。 + +* Bamboo 用于连续集成。 + +* 客户端尚未正式发布，由开发人员驱动。 有一个测试的暂存区。 + +* 组标志。 可以控制哪些组获得功能以测试功能，以缓慢释放功能并控制包装盒上的负载。 + +* 功能标志。 例如，非常适合在 ElasticSearch 推出期间提供保护。 如果他们发现错误，则可以关闭功能并回滚到 Couch。 用户不会注意到差异。 在 Couch 和 ElasticSearch 之间的过渡阶段，他们将应用程序复制到两个商店。 + +* 新的 API 版本将使用 Oauth，因此开发人员可以使用 HipChat API 在自己的服务器上进行部署。 让客户使用自己的服务器是一种更具可扩展性的模型。 + +## 未来 + +* 将在几个月内达到 20 亿条消息，并且估计 ElasticSearch 可以处理大约 20 亿条消息。 不确定如何处理预期的负载增加。 期望去 Amazon West 以获得更多的数据中心可用性，并可能使更多的用户进入不同的数据中心。 + +* 希望使用 AWS 的自动扩展功能。 + +* 进入语音，私人 1-1 视频，音频聊天，基本会议。 + +* 将来可能会使用 RabbitMQ 进行消息传递。 + +* 与 Confluence（Wiki）进一步集成。 使用 HipChat 交谈，然后使用 Confluence 页面捕获详细信息。 + +## 课程 + +* **企业应用程序**中有很多钱。 向企业推销可能会遭受酷刑。 较长的销售周期意味着可能会遇到麻烦。 但是如果你成功了，那将是一个有利可图的关系。 因此，您可能要考虑企业市场。 时代在变。 企业的发展可能仍然缓慢而缓慢，但是他们也正在采用新的工具和做事方式，那里有机会。 + +* **隐私变得越来越重要，并且在出售给企业**时会影响您的堆栈选择。 HipChat 正在制作其产品的内部版本，以满足不信任公共网络或云数据的客户的需求。 对于程序员来说，云作为平台是非常有意义的。 对于企业而言，云可能是邪恶的。 这意味着您必须做出灵活的技术堆栈选择。 如果您 100％依赖 AWS 上的服务，则几乎不可能将系统移至另一个数据中心。 对于 Netflix 而言，这可能并不重要，但是如果您想向企业市场销售产品，那就很重要。 + +* **放大以获得一些呼吸空间**。 在等待弄清楚体系结构的下一步工作时，只需很少的钱，您就可以扩大规模，并给自己提供几个月的呼吸空间。 + +* **选择不能失败的内容**。 HipChat 将永不丢失用户聊天历史记录作为优先级，因此其体系结构将此优先级反映到将聊天记录保存到磁盘，然后在宕机的系统恢复后重新加载。 + +* **转到本地** 。 您的客户在许多不同的平台上，本机应用程序将提供最佳体验。 对于拥有大量资源的创业公司来说，太多了​​。 因此，在某个时候，将产品出售给拥有更多资源的公司是有意义的，以便您可以开发出更好的产品。 + +* **功能和组标志是更好的发行实践** 。 如果您可以选择要查看功能的组，并且可以在生产和测试中关闭功能，那么您不必担心发布新版本。 + +* **选择您真正对** 充满信心的技术。 ElasticSearch 横向扩展以应对增长的能力使 HipChat 对他们的解决方案充满信心。 那个用户会很高兴的。 感觉很好。 + +* **成为过程流的一部分，您变得更有价值，并且很难删除** 。 HipChat 作为人与工具之间的自然交汇点，也是编写实现各种有用的工作流程 hack 的机器人的自然点。 这使 HipChat 成为企业中的平台。 它启用了原本无法构建的功能。 而且，如果您能够做到这一点，那么就很难摆脱它。 + +* **AWS 需要单独的节点存在总线** 。 荒谬的是，在云本身本身就是一件事，就是无法从客观的第三方来源获得机器状态信息。 如果您查看机架，它将经常有一条单独的状态总线，因此插槽可以知道其他插槽是否可用。 这样，您不必猜测。 在云中，软件使用基于 TCP 的原始连接技术和心跳来猜测另一个节点何时关闭，这可能导致脑裂问题和故障转移时的数据丢失。 现在是时候发展，并朝着可靠性迈出重大一步。 + +* **产品决策驱动器堆栈决策** 。 HipChat 服务器在技术堆栈上驱动决策。 Redis Cluster 可以是自托管的。 不能选择 Amazon DynamoDB，因为他们正在防火墙后启动托管服务。 + +* **在问题上投入很多精力只会使您到目前为止**。 您甚至需要在云中制定容量计划。 除非您的架构从一开始就完全是 Cloud Native，否则任何架构都将具有负载拐点，在这些拐点处其架构将不再能够处理负载。 看增长率。 投影出来。 什么会坏？ 您将如何处理？ 而且不要再犯同样的错误。 HipChat 将如何处理 40 亿条消息？ 不清楚。 + +* **知道系统的限制** 。 EBS 的存储限制为 1 TB，这很多，但是如果您的存储量接近该限制，则需要制定计划。 同样，如果您的数据库（如 Couch）在压缩阶段使用两倍的磁盘空间，这将影响您的限制。 + +* **世界会让您感到惊讶**。 六个月前，HipChat 认为 Redis 将是最弱的一环，但它仍将保持强劲，而 Couch 和 EBS 是最弱的一环。 + +## 相关文章 + +* [在 Reddit 上](http://www.reddit.com/r/programming/comments/1ujzel/scaling_hipchat_with_elasticsearch_and_redis/) / [在黑客新闻](https://news.ycombinator.com/item?id=7015179)上 +* [为什么您仍在构建消费者应用程序？ 企业支付的费用是原来的 4 倍！](http://www.developereconomics.com/still-building-consumer-apps-enterprise-pays-4x/) +* [HipChat 如何扩展到 10 亿条消息](http://blog.hipchat.com/2013/10/16/how-hipchat-scales-to-1-billion-messages/) +* Reddit on [HipChat 如何扩展到 10 亿条消息-HipChat 的工程师 Zuhaib Siddique 解释了其如何使用 CouchDB，ElasticSearch 和 Redis 来处理站点的负载](http://www.reddit.com/r/programming/comments/1svjjo/how_hipchat_scales_to_1_billion_messages_zuhaib) 。 +* [HipChat 搜索现在由 Elasticsearch 支持](http://blog.hipchat.com/2013/08/12/hipchat-search-now-powered-by-elasticsearch/) +* [HipChat ElasticSearch 聚会视频+幻灯片](http://zuhaiblog.com/2013/12/04/hipchat-elasticsearch-meetup-video-slides/) +* [SF ElasticSearch Meetup-HipChat 如何扩展为 1B 消息](http://www.youtube.com/watch?v=K2P7l98Uj9c) + +26 台前端服务器，每秒 60 条消息，似乎很重。 + +不错的诚实写作，谢谢。 非常丰富。 + +是的 每秒 60 条消息是不够的。 这是错字吗？ + +嗯 RTFA。 + +60 是平均，而不是一周中的全部 604800 秒。 有山峰。 + +我确定大多数前端服务器都用于与客户端的连接。 每个开放的客户端都需要维护与服务器的连接才能获取聊天消息。 每秒那 60 条消息是进来，而不是出去。 我猜如果所有的客户都在投票的话将会高出一吨。 + +这是最好的文章，我已经读过很长时间 +Mirza Tarkash + +我不知道从持久性的角度来看，它们如何处理 Redis 固有的 50％故障率。 或者也许对他们是否看到类似的表现发表评论... + +从 http://www.infoq.com/articles/jepsen + +在 2000 次写入中，Redis 声称其中 1998 年已成功完成。 但是，最终集中只有 872 个这些整数。 Redis 放弃了声称成功的 56％的写入。 + +Alex，绝对没有“ Redis 固有的 50％失败率” ...我不确定您是否正确地理解了这一点。 特别是在（希望！）罕见的“裂脑”问题中，这是一个关于他们使用它的目的（并且希望每个人都将它用于轻量级工作队列）的完全可以接受的问题。 我很高兴将 Redis 用于 API 服务器上的作业队列以及从 Logstash 进行提取，其失败率为 0。 + +此外，本文还特别提到海拔是手动的，这种情况不会发生。 更进一步，没关系，除了后端的负载。 这些是缓存服务器，而不是关键任务数据。 这确实是您完全不用担心 ACID 合规性或幻像写操作的情况。 + +很棒的文章。 肯定有帮助。 + +我确实要指出，尽管最后一段存在一些拼写和语法问题： + +> 这个世界会让您感到惊讶。 六个月前，HipChat 虽然 Redis 可能是最薄弱的一环，但它的表现仍然很强劲，而 Couch 和 EBS 是最薄弱的一环。 + +非常好的文章，但与许多服务器相比，数字 60 很小。 可能在“高峰时段”运送 600 或 6000 + +是否曾经考虑过将 Cloudant 作为扩展 CouchDB 的选择？ 它适用于 Hothead Games。 \ No newline at end of file diff --git a/docs/131.md b/docs/131.md index 08cfe35..e18df66 100644 --- a/docs/131.md +++ b/docs/131.md @@ -1,596 +1,61 @@ -# 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量 - -> 原文： [http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html) - -![](img/824ae269f3bd907a2a05b2053f990ad9.png) - -Pinterest 一直处于指数增长曲线，每个月半翻倍。 两年来，他们的浏览量已经从每月 0 增至 100 亿，从 2 位创始人和一位工程师到 40 多位工程师，从一台小型 MySQL 服务器到 180 个 Web 引擎，240 个 API 引擎，88 个 MySQL DB（cc2。 8xlarge），每个+ 1 个从属，110 个 Redis 实例和 200 个 Memcache 实例。 - -惊人的增长。 那么 Pinterest 的故事是什么？ 告诉他们的故事，我们有我们的吟游诗人，Pinterest 的 [Yashwanth Nelapati](http://www.linkedin.com/in/yashh) 和 [Marty Weiner](http://pinterest.com/martaaay/) ，他在 [Scaling Pinterest](http://www.infoq.com/presentations/Pinterest) 演讲中讲述了 Pinterest 架构演变的戏剧性故事。 这是一年半前他们想要快速扩展并且有很多选择的时候他们希望听到的演讲。 他们做出了许多错误的选择。 - -这是一个很棒的话题。 它充满了惊人的细节。 它也是非常实用，扎根的，并且包含几乎任何人都可以采用的策略。 强烈推荐。 - -我在演讲中最喜欢的两个课程： - -1. 当可以通过添加更多相同的东西来处理增长时，体系结构就做对了。 您希望能够通过在问题上投入资金来扩展规模，这意味着您可以根据需要在问题上投入更多的资金。 如果您的架构能够做到这一点，那么您就很聪明。 -2. 当您将某些事情推到极限时，所有技术都会以自己的特殊方式失败。 这导致他们在评估工具选择时偏向于成熟的工具； 真的很好，很简单； 众所周知和喜欢 良好的支持； 始终表现出色； 尽可能无故障； 自由。 他们使用这些条件选择了：MySQL，Solr，Memcache 和 Redis。 卡桑德拉（Cassandra）和蒙哥（Mongo）被撤职。 - -这两个课程是相互关联的。 遵循（2）中原理的工具可以通过添加更多框来扩展。 随着负载的增加，成熟的产品应该会遇到更少的问题。 当您遇到问题时，至少会有一个社区来解决问题。 这是因为您的工具过于棘手又太挑剔，以至于撞到了很高的墙壁，无法攀爬。 - -在整个讨论中，我认为这是最好的部分，在讨论分片为什么比群集更好的过程中，您会看到通过增加资源，少量故障模式，成熟，简单和良好的支持来实现增长的主题， 取得成果。 请注意，他们选择的所有工具都是通过添加分片而不是通过集群来扩展的。 关于为什么他们更喜欢分片以及如何分片的讨论确实很有趣，并且可能涵盖了您以前从未考虑过的领域。 - -现在，让我们看看 Pinterest 如何扩展： - -## 基础知识 - -* 引脚是一幅包含其他信息位的图像，描述了对用户重要的内容，并链接回其找到位置。 - -* Pinterest 是一个社交网络。 您可以关注他人和董事会。 - -* 数据库：他们的用户拥有板，板具有引脚； 追踪并保持关系； 认证信息。 - -## 于 2010 年 3 月推出-寻找自我的时代 - -此时，您甚至都不知道要制造什么产品。 您有想法，因此可以快速迭代和更改。 因此，您最终遇到了许多奇怪的小 MySQL 查询，这些查询在现实生活中是永远不会做的。 - -此早期日期的数字： - -* 2 位创始人 - -* 1 位工程师 - -* 机架空间 - -* 1 个小型网络引擎 - -* 1 个小型 MySQL 数据库 - -## 2011 年 1 月 - -仍处于隐身模式，并且该产品正在根据用户反馈发展。 数字： - -* Amazon EC2 + S3 + CloudFront - -* 1 个 NGinX，4 个 Web 引擎（用于冗余，而不是用于负载） - -* 1 个 MySQL DB + 1 个读从站（以防主机崩溃） - -* 1 个任务队列+ 2 个任务处理器 - -* 1 个 MongoDB（用于计数器） - -* 2 个工程师 - -## 到 2011 年 9 月-实验时代 - -他们疯狂地奔跑着，他们每个月都翻一番。 疯狂的增长。 - -* 当您快速成长时，每个晚上和每个星期都会崩溃。 - -* 此时，您阅读了许多白皮书，说仅是一个盒子，您就完成了。 因此，他们开始增加很多技术。 他们都坏了。 - -* 结果，您最终得到了非常复杂的图片： - - * Amazon EC2 + S3 + CloudFront - - * 2NGinX，16 个 Web 引擎+ 2 个 API 引擎 - - * 5 个功能明确的 MySQL DB + 9 个读取从站 - - * 4 个 Cassandra 节点 - - * 15 个 Membase 节点（3 个独立的群集） - - * 8 个 Memcache 节点 - - * 10 个 Redis 节点 - - * 3 个任务路由器+ 4 个任务处理器 - - * 4 个弹性搜索节点 - - * 3 个 Mongo 群集 - - * 3 个工程师 - -* 仅针对数据的 5 种主要数据库技术。 - -* 增长如此之快，以至于 MySQL 变得炙手可热，所有其他技术也被推向了极限。 - -* 当您将某些技术推向极限时，所有这些技术都会以自己的特殊方式失败。 - -* 开始放弃技术并问自己自己真正想要成为什么。 对所有内容进行了大规模的重新架构。 - -## 2012 年 1 月-成熟期 - -* 重新整理一切之后，系统现在看起来像： - - * 亚马逊 EC2 + S3 + Akamai，ELB - - * 90 个 Web 引擎+ 50 个 API 引擎 - - * 66 个 MySQL DB（m1.xlarge）+每个从站 1 个 - - * 59 个 Redis 实例 - - * 51 个 Memcache 实例 - - * 1 个 Redis 任务管理器+ 25 个任务处理器 - - * 碎片 Solr - - * 6 位工程师 - -* 现在使用分片的 MySQL，Redis，Memcache 和 Solr。 而已。 优势在于它是非常简单和成熟的技术 - -* Web 流量一直以相同的速度增长，而 iPhone 流量开始上升。 - -## 2012 年 10 月 12 日-回归的时代 - -大约是一月份的四倍。 - -* The numbers now looks like: - * 3 级，Akamai，Amazon EC2 + S3 + Edge Cast - - * 180 个 Web 引擎+ 240 个 API 引擎 - - * 88 个 MySQL DB（cc2.8xlarge）+每个 1 个从数据库 - - * 110 个 Redis 实例 - - * 200 个 Memcache 实例 - - * 4 个 Redis 任务管理器+ 80 个任务处理器 - - * 碎片索尔 - - * 40 名工程师（并且正在不断增长） - -* 请注意，该架构正在做正确的事情。 增长是通过添加更多相同的东西。 您希望能够通过花钱解决问题来扩展规模。 您只需要在需要时就可以扔出更多盒子。 - -* 现在移至 SSD - -## 为什么选择 Amazon EC2 / S3？ - -* 相当不错的可靠性。 数据中心也会崩溃。 多租户会增加一些风险，但这还不错。 - -* 良好的报告和支持。 他们的架构师非常好，他们知道问题 - -* 不错的外围设备，尤其是在您成长的时候。 您可以启动 App Engine 并与他们的托管缓存，负载平衡，地图缩减，托管数据库以及您无需自己编写的所有其他部分进行对话。 您可以引导亚马逊的服务，然后在拥有工程师的情况下对其进行改进。 - -* 数秒内即可使用新实例。 云的力量。 特别是有了两名工程师，您不必担心容量规划或等待两周来获取内存缓存的情况。 只需几分钟即可添加 10 个内存缓存。 - -* 缺点：选择有限。 直到最近，您才能获得 SSD，并且无法获得大容量 RAM 配置。 - -* 优点：选择有限。 您最终不会得到很多配置不同的盒子。 - -## 为什么选择 MySQL？ - -* 真的很成熟。 - -* 非常牢固。 对于他们来说，它永远不会失败，并且永远不会丢失数据。 - -* 您可以租用它。 许多工程师都了解 MySQL。 - -* 对请求速率的响应时间线性增加。 当请求率达到峰值时，某些技术的响应也不会很好。 - -* 很好的软件支持-XtraBackup，Innotop，Maatkit - -* 很棒的社区。 回答问题很容易。 - -* Percona 等公司提供了很好的支持。 - -* 免费-当您最初没有任何资金时很重要。 - -## 为什么使用 Memcache？ - -* 非常成熟。 - -* 真的很简单。 这是一个哈希表，其中插入了一个套接字。 - -* 始终表现出色 - -* 众所周知，很喜欢。 - -* 始终表现良好。 - -* 永不崩溃。 - -* 免费 - -## 为什么要使用 Redis？ - -* 还不成熟，但确实非常好，非常简单。 - -* 提供各种数据结构。 - -* 具有持久性和复制性，可以选择实现它们的方式。 如果您想要 MySQL 样式的持久性，可以拥有它。 如果您不需要持久性，可以拥有它。 或者，如果您想要 3 个小时的持久性，则可以拥有它。 - - * 您的家庭供稿位于 Redis 上，每 3 小时保存一次。 没有 3 小时的复制。 他们仅每 3 小时备份一次。 - - * 如果将数据存储在模具上的盒子中，则它们仅备份了几个小时。 它并不完全可靠，但更简单。 您不需要复杂的持久性和复制。 它的架构更简单，更便宜。 - -* 众所周知，很喜欢。 - -* Consistently good performance. - -* 少数故障模式。 您需要了解一些微妙的故障模式。 这就是成熟的源头。只是学习它们并超越它。 - -* Free - -## Solr - -* 很棒的起床型产品。 安装它，几分钟后您将建立索引。 - -* 不能超过一个框。 （最新版本并非如此） - -* 尝试了弹性搜索，但从规模上看，它遇到了很多小文档和很多查询的麻烦。 - -* 现在使用 Websolr。 但是他们有一个搜索小组，并且会自己动手。 - -## 聚类与分片 - -* 在快速增长期间，他们意识到他们将需要平均分布数据以应对不断增长的负载。 - -* 定义了一个讨论该问题的频谱，他们提出了“聚类”和“分片”之间的一系列选择。 - -### 群集-一切都是自动的： - -* 示例：Cassandra，MemBase，HBase - -* 判决：太可怕了，也许在将来，但是现在它太复杂了，故障模式太多了。 - -* 属性： - - * 数据自动分发 - - * 数据可以移动 - - * 重新平衡以分配容量 - - * 节点相互通信。 大量的串扰，闲聊和谈判。 - -* 优点： - - * 自动扩展您的数据存储。 白皮书至少是这样说的。 - - * 易于设置。 - - * 在空间上分布和放置数据。 您可以将数据中心放置在不同的区域，而数据库则由它来处理。 - - * 高可用性 - - * 负载平衡 - - * 没有单点故障 - -* 缺点（根据第一手经验）： - - * 还很年轻。 - - * 从根本上讲复杂。 整个节点必须对称一致，这是生产中很难解决的问题。 - - * 较少的社区支持。 社区的产品线不同，因此每个阵营的支持都较少。 - - * 具有工作知识的工程师更少。 可能大多数工程师都没有使用 Cassandra。 - - * 困难而令人恐惧的升级机制。 可能与它们都使用 API​​并相互之间进行交谈有关，所以您不希望它们混淆。 这导致复杂的升级路径。 - - * 集群管理算法是 SPOF。 如果有错误，它将影响每个节点。 这使他们失望了 4 次。 - - * 群集管理器是在具有以下故障模式的所有节点上复制的复杂代码： - - * 数据重新平衡中断。 带来一个新盒子，数据开始复制，然后被卡住。 你是做什么？ 没有工具可以弄清楚发生了什么。 没有社区可以帮助，所以他们陷入了困境。 他们回到了 MySQL。 - - * 所有节点上的数据损坏。 如果存在一个错误，该错误会在所有日志中将错误注入到写入日志中，并且压缩或其他机制停止了，该怎么办？ 您的阅读延迟会增加。 您所有的数据都被搞砸了，数据消失了。 - - * 无法轻松解决的不正确平衡。 很常见的。 您有 10 个节点，并且注意到所有节点都在一个节点上。 这是一个手动过程，但是它将负载重新分配回一个节点。 - - * 数据授权失败。 群集方案非常聪明。 在一种情况下，他们带来了新的中学。 大约 80％的辅助节点表示它是主要节点，而主要节点转到辅助节点，您已经丢失了 20％的数据。 丢失 20％的数据比丢失所有数据更糟糕，因为您不知道丢失了什么。 - -### 分片-一切都是手动的： - -* 裁决：获胜者。 注意，我认为它们的分片架构与 [Flickr 架构](http://highscalability.com/blog/2007/11/13/flickr-architecture.html) 有很多共同点。 - -* Properties: - - * 摆脱所有您不喜欢的聚类属性，即可进行分片。 - - * 手动分发的数据 - - * 数据不动。 尽管有些人这样做，但他们从未移动数据，这使它们在频谱上处于更高的位置。 - - * 拆分数据以分配负载。 - - * 节点彼此之间不认识。 一些主节点控制一切。 - -* Pros: - - * 可以拆分数据库以增加容量。 - - * 在空间上分配和配置您的数据 - - * High availability - - * Load balancing - - * 放置数据的算法非常简单。 主要原因。 有 SPOF，但只有半页代码，而不是非常复杂的 Cluster Manager。 在第一天之后，它会起作用或不起作用。 - - * ID 生成很简单。 - -* 缺点： - - * 无法执行大多数加入。 - - * 失去了所有交易功能。 成功写入另一个数据库时，对一个数据库的写入可能会失败。 - - * 必须将许多约束移到应用程序层。 - - * 模式更改需要更多计划。 - - * 报表需要在所有分片上运行查询，然后自己执行所有聚合。 - - * 联接在应用程序层中执行。 - - * 您的应用程序必须容忍所有这些问题。 - -### 什么时候分片？ - -* 如果您的项目将有几 TB 的数据，则应尽快分片。 - -* 当 Pin 表达到 10 亿行时，索引用完了内存，它们正在交换到磁盘。 - -* 他们选择了最大的表并将其放在自己的数据库中。 - -* 然后它们在单个数据库上用完了空间。 - -* 然后他们不得不分片。 - -### 转换为分片 - -* 从冻结功能开始过渡过程。 - -* 然后，他们决定了如何分片。 想要执行最少数量的查询并转到最少数量的数据库以呈现单个页面。 - -* 删除了所有 MySQL 连接。 由于可以将表加载到单独的分区中，因此联接将不起作用。 - -* 添加了大量的缓存。 基本上每个查询都必须被缓存。 - -* 步骤如下： - - * 1 个 DB +外键+加入 - - * 1 个 DB +规范化+缓存 - - * 1 个 DB +读取从站+缓存 - - * 几个功能分区的 DB +读取从站+缓存 - - * ID 分片的 DB +备份从属+缓存 - -* 由于奴隶滞后，较早读取的奴隶成为一个问题。 读取将发送给从属设备，而主设备尚未复制记录，因此看起来好像丢失了记录。 解决这个问题需要缓存。 - -* 他们具有后台脚本，该脚本重复了数据库过去的工作。 检查完整性约束，参考。 - -* 用户表未分片。 他们只是使用大型数据库，并且对用户名和电子邮件具有唯一性约束。 如果不是唯一的，则插入用户将失败。 然后，他们在分片数据库中进行了大量写操作。 - -### 如何分割？ - -* 看了 Cassandra 的戒指模型。 看着 Membase。 并看着 Twitter 的 Gizzard。 - -* 确定：跨节点移动的数据最少，体系结构就更稳定。 - -* Cassandra 存在数据平衡和权限问题，因为节点不确定谁拥有数据的哪一部分。 他们决定应用程序应该决定数据应该去哪里，所以永远不会有问题。 - -* 预测了他们未来五年的增长，并牢记这一容量计划。 - -* 最初创建了许多虚拟分片。 8 台物理服务器，每个服务器有 512 个 DB。 所有数据库都有所有表。 - -* 为了获得高可用性，它们始终在多主复制模式下运行。 每个主服务器都分配到一个不同的可用区。 发生故障时，切换到另一个主节点，并引入一个新的替换节点。 - -* 当数据库上的负载增加时： - - * 查看代码提交，以查看是否发生了新功能，缓存问题或其他问题。 - - * 如果只是增加负载，他们就会拆分数据库，并告诉应用程序在新主机上查找数据。 - - * 在拆分数据库之前，它们会启动这些主服务器的从服务器。 然后，他们用新的数据库分配交换应用程序代码。 在过渡期间的几分钟内，写入仍将写入旧节点，并被复制到新节点。 然后在节点之间切割管道。 - -### ID 结构 - -* 64 位： - - * 分片 ID：16 位 - - * 类型：10 位-引脚，板，用户或任何其他对象类型 - - * 本地 ID-表中 ID 的其余位。 使用 MySQL 自动递增。 - -* Twitter 使用映射表将 ID 映射到物理主机。 这需要查找。 由于 Pinterest 在 AWS 上并且 MySQL 查询花费了大约 3 毫秒，因此他们决定这种额外级别的间接操作将不起作用。 他们将位置内置到 ID 中。 - -* 新用户随机分布在各个分片上。 - -* 用户的所有数据（引脚，板等）都位于同一分片上。 巨大的优势。 例如，呈现用户个人资料不会进行多个交叉分片查询。 它很快。 - -* 每个板都与用户并置，因此可以从一个数据库中呈现板。 - -* 足以容纳 65536 个分片的分片 ID，但最初它们仅打开 4096，它们将水平扩展。 用户数据库用完后，他们将打开更多的分片，并允许新用户访问新的分片。 - -### 查找 - -* 例如，如果他们有 50 个查询，他们将拆分 ID 并并行运行所有查询，因此等待时间是最长的等待时间。 - -* 每个应用程序都有一个配置文件，该文件将分片范围映射到物理主机。 - - * “ sharddb001a”：：( 1，512） - - * “ sharddb001b” ：：（513，1024）-备份热备机 - -* 如果要查找 ID 属于 sharddb003a 的用户： - - * 将 ID 分解为各个部分 - - * 在分片图中执行查找 - - * 连接到分片，转到类型的数据库，然后使用本地 ID 查找合适的用户并返回序列化的数据。 - -### 对象和映射 - -* 所有数据都是对象（引脚，面板，用户，注释）或映射（用户具有面板，引脚具有点赞）。 - -* 对于对象，本地 ID 映射到 MySQL Blob。 Blob 格式以 JSON 开头，但现在已转为序列化节俭。 - -* 对于映射，有一个映射表。 您可以要求用户提供所有板。 这些 ID 包含时间戳记，因此您可以查看事件的顺序。 - - * 有一个反向映射（多对多表），用于回答该类型的查询，这给了我所有喜欢此引脚的用户。 - - * 模式命名方案为 noun_verb_noun：user_likes_pins，pins_like_user。 - -* 查询是主键或索引查找（无联接）。 - -* 数据不会像集群一样在数据库中移动。 例如，一旦用户登陆到分片 20，并且所有用户数据都并置在一起，它将永远不会移动。 64 位 ID 包含分片 ID，因此无法移动。 您可以将物理数据移动到另一个数据库，但仍与同一分片关联。 - -* 所有表都存在于所有分片上。 没有特殊的分片，不计算用于检测用户名冲突的庞大用户表。 - -* 无需更改架构，并且新索引需要新表。 - - * 由于键的值为 blob，因此您可以添加字段而不会破坏架构。 每个 Blob 上都有版本控制，因此应用程序将检测版本号，并将记录更改为新格式并写回。 无需一次更改所有数据，将在读取时进行升级。 - - * 巨大的胜利，因为更改桌子需要数小时或数天的锁定。 如果要新索引，只需创建一个新表并开始填充它。 当您不再需要时，请将其放下。 （没有提及这些更新如何确保交易安全）。 - -### 呈现用户个人资料页面 - -* 从 URL 获取用户名。 转到单个大型数据库以查找用户 ID。 - -* 获取用户 ID 并将其拆分为各个组成部分。 - -* 选择分片并转到该分片。 - -* 来自用户的 SELECT 正文，其中 id = < local_user_id > - -* 从 user_has_boards 中选择 board_id，其中 user_id = < user_id > - -* 从 ID 为 IN 的板子中选择主体（< boards_ids >） - -* 从 board_has_pins 中选择 pin_id，而 board_id = < board_id > - -* 从 ID 为 IN 的引脚（PIN_ID）中选择主体 - -* 大多数调用是通过缓存（内存缓存或 Redis）提供的，因此实际上并没有很多数据库查询。 - -### 脚本编写 - -* 迁移到分片式架构时，您有两种不同的基础结构，一种是旧的非分片系统，另一种是新的分片系统。 脚本是将旧内容转移到新内容的所有代码。 - -* 他们移动了 5 亿个引脚和 16 亿个追随者行，等等 - -* 低估了项目的这一部分。 他们认为将数据放入碎片中需要 2 个月，而实际上需要 4-5 个月。 记住，这是在功能冻结期间。 - -* 应用程序必须始终写入新旧基础结构。 - -* 一旦确定所有数据都在新的基础架构中，然后将您的读取指向新的基础架构，然后慢慢增加负载并测试后端。 - -* 建立了脚本农场。 动员更多的工人来更快地完成任务。 他们将执行诸如将这些表移至新基础架构之类的任务。 - -* 窃取了 Pyres 副本，这是 Github Resque 队列的 Python 接口，该队列基于 Redis 构建。 支持优先级和重试。 太好了，他们用 Pyres 代替了 Celery 和 RabbitMQ。 - -* 该过程中有很多错误。 用户发现错误，例如缺少板。 必须多次运行该过程，以确保没有暂时性错误阻止数据正确移动。 - -## 开发 - -* 最初尝试为开发人员提供系统的一部分。 每个服务器都有自己的 MySQL 服务器等，但是事情变化如此之快，因此无法正常工作。 - -* 转到 Facebook 的模式，每个人都可以访问所有内容。 因此，您必须非常小心。 - -## 未来方向 - -* 基于服务的体系结构。 - - * 随着他们开始看到大量的数据库负载，他们开始产生许多应用程序服务器和许多其他服务器。 所有这些服务器都连接到 MySQL 和内存缓存。 这意味着内存缓存上有 30K 连接，占用了数 GB 的 RAM，并导致内存缓存守护进程交换。 - - * 作为解决方法，它们正在迁移到服务体系结构。 例如，有一个追随者服务，它将仅回答追随者查询。 这样可以将访问数据库和缓存的计算机数量限制为 30，从而减少了连接数量。 - - * 帮助隔离功能。 帮助围绕服务和支持这些服务组织团队。 开发人员无法访问其他服务，从而提高了安全性。 - -## 获得的经验教训 - -* 将失败。 把事情简单化。 - -* 保持乐趣。 有很多新人加入这个团队。 如果您只是给他们一个庞大的复杂系统，那将不会很有趣。 保持架构简单是一个巨大的胜利。 从第一周开始，新工程师就开始提供代码。 - -* When you push something to the limit all these technologies fail in their own special way. - -* 当可以通过添加更多相同的东西来处理增长时，体系结构就做对了。 您希望能够通过在问题上投入更多盒子来解决问题，从而根据需要扩展规模。 如果您的架构能够做到这一点，那么您就很聪明。 - -* Cluster Management Algorithm is a SPOF. If there’s a bug it impacts every node. This took them down 4 times. - -* 要应对快速增长，您需要平均分配数据以应对不断增长的负载。 - -* 跨节点移动的数据最少，体系结构就更稳定。 这就是为什么他们在群集上进行分片。 - -* 面向服务的体系结构规则。 它隔离功能，帮助减少连接，组织团队，组织支持并提高安全性。 - -* 问自己，你真正想要成为什么。 即使您必须重新构建所有架构，也要删除符合该愿景的技术。 - -* 不要害怕丢失一些数据。 它们将用户数据保留在内存中并定期将其写出。 丢失意味着仅丢失了几个小时的数据，但是最终的系统却变得更加简单和强大，这才是重要的。 +# NYTimes 架构：无头，无主控，无单点故障 + +> 原文： [http://highscalability.com/blog/2014/1/13/nytimes-architecture-no-head-no-master-no-single-point-of-fa.html](http://highscalability.com/blog/2014/1/13/nytimes-architecture-no-head-no-master-no-single-point-of-fa.html) + +![](img/e344a023a89234e354fd84f1c9ab2deb.png) + +纽约时报（NYTimes）的系统架构师 Michael Laing 向[表示了极大的敬意](http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2014-January/032920.html)，使他们了解 [RabbitMQ](http://www.rabbitmq.com/) 的使用以及 RabbitMQ 邮件列表中的整体体系结构。 结束语表明这绝对是一个可以学习的架构： + +> 尽管 Fabrik 看起来很复杂，但它具有简单的组件，并且主要是原理和管道。 掌握的关键点是没有头脑，没有主人，没有单点故障。 在撰写本文时，我可以看到组件发生故障（不是 RabbitMQ），并且我们正在对其进行修复，以使它们更加可靠。 但是系统不会失败，用户可以连接，并且消息可以传递，无论如何-所有这些都在设计参数之内。 + +由于很短，因此，我不能说得更好，这里我只复制几个原始资源： + +> 简短说明一下，感谢 RabbitMQ 团队的出色产品。 +> +> 我们一流的在线产品 www.nytimes.com 具有新外观和新基础，现在包括使用 RabbitMQ 实现的消息传递体系结构。 +> +> 这种架构- Fabrik -在俄勒冈州和都柏林的 6 个 AWS 区域中分布了数十个 RabbitMQ 实例。 实例分为“批发”和“零售”两层。 通过 websockets / sockjs 连接到客户端。 +> +> 该系统自今天启动以来，已自动扩展到约 500,000 个用户。 连接时间保持在 200ms 左右。 +> +> Fabrik 提供突发新闻，视频提要等订阅服务，并将添加更多基于事件的服务。 它还支持与注册用户的订阅状态有关的个人消息传递。 +> +> 没有 RabbitMQ，该系统将无法实现。 这是一个无处不在的组件，从未动摇或失败过。 +> +> We are using: a single Amazon Linux AMI, RabbitMQ, Cassandra 2, python 2 +> +> 我们将皮卡搭配龙卷风和 libev 用于 nytuseaбrik 批发和零售产品； 我们的内部客户使用 Java 和 PHP。 +> +> 我们使用 Rabbit MQ 作为消息传递系统。 目前，我们处理的消息包括突发新闻警报和实时视频警报。 我们的内部客户通过 AMQP 向 fabrik 发送这些消息。 然后，我们将它们发送到堆栈中，以确保它们已交付。 +> +> 我们在堆栈的所有层都有 Rabbit，并用铁锹将它们连接起来。 我们自己的内部代码有助于根据那里的服务级别路由消息。 某些消息（例如突发新闻）必须尽快发出。 因此，我们将它们散布到整个群集中，然后将它们铲到其他区域的群集中进行处理。 消息从那里发送到前端进行传递。 +> +> 我们还将 Rabbit 用于个别邮件。 如果您是 NYTimes 的注册用户，我们可以亲自向您发送消息。 信用卡到期之类的事情。 +> +> 在生产中，我们在 c1-xlarges 的每个区域都有一个 RabbitMQ 客户端 3 集群和一个核心 3 集群。 弗吉尼亚州 c1 介质的代理群集将客户端连接到客户端群集。 所有服务都是并行的，因此我们可以添加更多的核心和客户端。 +> +> 零售层会自动缩放并使用 c1-medium，并且将单个兔子铲子连接到其中一只核心兔子。 每个 python websocket / sockjs 网关最多支持 10 万个客户端。 +> +> 我们将自动部署到 AWS 虚拟私有云中的子网中。 客户端通过最小的延迟被路由到最快的健康区域。 +> +> 在技​​术组件中，网关是最复杂的。 我们将逐步将其转移到开源中，并且第一部分可能是 python websocket / sockjs 库，坦率地说，它击败了大多数其他内容，并完全符合相关标准。 可以粗略地认为它是由 python 管理的 C 协同进程，因此，可以在其他语言/环境中重用。 +> +> 我们在 2 个区域/ 6 个区域中有一个 12 节点的 Cassandra 集群。 它用于消息的持久性和缓存。 我们不在 RabbitMQ 中使用持久性。 我们的服务是幂等的，重要的消息可能会被多次复制，从而创造有意竞速的条件，从而以最快的速度获胜。 +> +> Although it may seem complex, Fabrik has simple components and is mostly principles and plumbing. The key point to grasp is that there is no head, no master, no single point of failure. As I write this I can see components failing (not RabbitMQ), and we are fixing them so they are more reliable. But the system doesn't fail, users can connect, and messages are delivered, regardless - all within design parameters. ## 相关文章 -* [讨论黑客新闻](https://news.ycombinator.com/item?id=5552504) -* [Pinterest 体系结构更新-1800 万访问者，增长 10 倍，拥有 12 名员工，410 TB 数据](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) -* [用于处理 3 百万以上用户的 Pinterest 堆栈中的一个短项](http://highscalability.com/blog/2012/2/16/a-short-on-the-pinterest-stack-for-handling-3-million-users.html) -* [Pinterest 通过自动关闭系统将费用从每小时 54 美元降低到 20 美元](http://highscalability.com/blog/2012/12/12/pinterest-cut-costs-from-54-to-20-per-hour-by-automatically.html) -* [Instagram 体系结构更新：Instagram 有何新功能？](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html) -* [Facebook 过去曾增长到 5 亿用户的 7 种扩展策略](http://highscalability.com/blog/2010/8/2/7-scaling-strategies-facebook-used-to-grow-to-500-million-us.html)和 [Facebook](http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html) 扩展的四个元秘密-我认为您会在他们的方法中找到一些相似之处。 - -一个小的更正，“ Web Solr”应实际读取为“ Websolr”，如 http://websolr.com/ - -非常感谢你的这篇文章。 简单明了地指出了每个方面：） - -没有提及实际的 Web 应用程序使用什么编程语言和框架。 请告诉我他们没有在 PHP 中执行此操作... - -Python ... Pinterest 一直被吹嘘为 DJango 实现。 看到这里：http://www.quora.com/Pinterest/What-technologies-were-used-to-make-Pinterest - -有人知道他们是否仍将 Nginx 用作应用服务器负载平衡器吗？ - -在“为什么要 Amazon EC2 / S3”部分下，提到了“ App Engine”。 这让我感到困惑（因为 App Engine 是 Google，而不是 Amazon）。 有人可以澄清吗？ - -交换？ 删除交换，交换比失败诱饵更糟糕。 -停机服务器比 ssssllllllooooooowwwww 服务器更好。 - -绕开 CDN 的原因是什么？ - -有人知道他们如何存储图像吗？ 在 mysql，磁盘还是其他地方？ -例如，URL“ http://media-cache-ec4.pinimg.com/736x/cf/d7/49/cfd74959947950dd0c3c1ef8ef2f1582.jpg”中的 imageid 可能包含一些信息？ 谢谢 - -很想知道更多有关 Mongo 为什么被删除的信息，以支持在 MySQL 中存储无模式的 Blob。 这仅仅是错误，性能低下的问题吗？ 好像 Mongo 是为这种 BASE 体系结构设计的，如果它可以很好地运行，则无需在应用程序层手动管理索引的开销。 - -小修正：在您喜欢的讲座的 2 课中的第 1 课中，您说“您是建筑”而不是“您的建筑”。 - -非常有趣的阅读。 - -谁能解释： -对于对象，本地 ID 映射到 MySQL Blob。 Blob 格式以 JSON 开头，但现在已转为序列化节俭。 - -为什么本地 ID 映射到 mysql Blob？ - -感谢您发布此信息。 看到架构的潮起潮落总是让人着迷。 但是，我不同意本文的最后一点。 - -> 不要害怕丢失一些数据。 - -该陈述完全取决于所讨论数据的使用。 在 Pinterest 的情况下，我可以看到它完全可以实现。 所涉及的数据没有货币价值，如果丢失了任何人的生命都不会受到特别的影响。 但是，我认为区分不重要的数据丢失和重要的数据非常重要。 - -当您说“ Web Engine”时，您指的是什么？ 这是否意味着另一个克隆了主应用程序的云实例？ +* [在 Reddit 上](http://www.reddit.com/r/programming/comments/1v4gzj/nytimes_architecture_system_doesnt_fail_users_can/) -你好 +一篇非常有趣的文章。 只是有机会略读，但我期待学习更多。 -我很好奇，当一个用户数据过大而又无法容纳一个分片时，会发生什么？ +一个快速的问题：我注意到报价的字符集似乎存在问题（也许是从复制/粘贴时起？）。 NYTimes 架构名称周围有一些奇怪的符号。 -此致 -拉希德 +我已将图像上传到 imgur，并提供了它对我的外观的屏幕截图。 没什么大不了的，但以为您可能想知道。 您可以在 [http://imgur.com/9IfuLX5](http://imgur.com/9IfuLX5) 上看到图像。 -有人能粗略估计一下这些设置每个月要花费多少吗？ +肖恩，可能是因为您的浏览器未设置为查看或接受 utf-8 字符？ -为什么同时使用 Memcache 和 Redis？ Redis 几乎可以完成 Memcache 可以做的所有事情，还有其他用途。 +托德（Todd），带有说明链接的错字-文章将其拼写为解密 -即使在这些年之后，这篇文章也很有意义。 感谢您抽出宝贵的时间，并详细说明了构建简单的可伸缩 Web 平台需要花费的一切！ \ No newline at end of file +这就是将字符发布到邮件列表的方式 \ No newline at end of file diff --git a/docs/132.md b/docs/132.md index ffd18c8..c472f72 100644 --- a/docs/132.md +++ b/docs/132.md @@ -1,62 +1,128 @@ -# 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段 +# 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放，喜欢和更多内容 -> 原文： [http://highscalability.com/blog/2013/4/10/check-yourself-before-you-wreck-yourself-avocados-5-early-st.html](http://highscalability.com/blog/2013/4/10/check-yourself-before-you-wreck-yourself-avocados-5-early-st.html) +> 原文： [http://highscalability.com/blog/2014/1/28/how-next-big-sound-tracks-over-a-trillion-song-plays-likes-a.html](http://highscalability.com/blog/2014/1/28/how-next-big-sound-tracks-over-a-trillion-song-plays-likes-a.html) -![](img/d02a7ba0dcd059b036ce353085ef0a44.png)在[中不要惊慌！ 这是如何快速扩展您的移动应用](http://venturebeat.com/2013/04/06/dont-panic-heres-how-to-quickly-scale-your-mobile-apps/)的方法。 [Mike Maelzer](http://www.linkedin.com/in/maelzer) 描绘了 [Avocado](https://avocado.io/) （一种用于连接情侣的移动应用程序）是如何发展的，可在几周内处理 30 倍的流量。 如果您只是入门，那么这是一个值得学习的好例子。 +![](img/7983a905c376ef6b7f410040a654d96a.png) -我喜欢的东西：写得很好，在一个很小的空间中包装了很多有用的信息； 它是由故障驱动的，显示了有目的的测试和生产经验所驱动的增量变化的过程； 它显示出对于重要的用户（对于他们而言）注册的意识； 使用副本设置进行测试，这是一个不错的云优势。 +*这是 Next Big Sound 的首席架构师 [Eric Czech](http://www.linkedin.com/profile/view?id=26317730) 的来宾帖子，讨论了解决音乐分析中可伸缩性挑战的一些独特方法。* -他们从中学到的最大的教训是一个很好的教训： +跟踪在线活动并不是什么新主意，但是要在整个音乐行业中做到这一点并不容易。 每天有五十亿个音乐视频流，曲目下载和艺术家页面喜欢出现，并且衡量跨 Spotify，iTunes，YouTube，Facebook 等平台的所有活动的可能性带来了一些有趣的可扩展性挑战。 Next Big Sound 从一百多个来源收集此类数据，将所有内容标准化，并通过基于 Web 的分析平台提供该信息以记录唱片公司，乐队经理和艺术家。 -> 最好早得多开始扩展过程。 由于时间紧迫，我们不得不做出让步-例如放下四个媒体缩放器盒。 虽然在某些扩展问题上投入更多的硬件确实可以，但是这并不理想。 +尽管我们的许多应用程序都使用诸如 Hadoop，HBase，Cassandra，Mongo，RabbitMQ 和 MySQL 之类的开源系统，但是我们的用法是相当标准的，但是我们这样做的一个方面是非常独特的。 我们从 100 多个来源收集或接收信息，我们很早就努力寻找一种方法来处理这些来源的数据随时间变化的方式，最终我们决定需要一个可以代表这些变化的数据存储解决方案。 基本上，我们需要能够以与使用修订控制（通过 Git）控制创建数据的代码几乎相同的方式对这些源中的数据进行“版本化”或“分支化”。 为此，我们在 Cloudera 发行版中添加了一个逻辑层，并将该层集成到 Apache Pig，HBase，Hive 和 HDFS 中之后，我们现在有了一个基本的版本控制框架，可用于 Hadoop 集群中的大量数据。 -这是我对这篇文章的介绍： +作为一种 [Moneyball for Music，](http://www.forbes.com/sites/zackomalleygreenburg/2013/02/13/moneyball-for-music-the-rise-of-next-big-sound/)“ Next Big Sound 已经从 MySpace 上的一台服务器 LAMP 站点跟踪播放（开始之初很酷）发展为少数艺术家，从而发展了整个行业[ 广告牌的流行度图表[以及在 Spotify](http://www.digitaltrends.com/social-media/billboard-social-networking-music-chart-debuts/) 上播放的每首歌曲的[摄取记录。 数据的增长速度已接近指数级，而分布式系统的早期采用对于保持数据的更新至关重要。 跟踪了来自公共和私有提供商的 100 多个来源，处理音乐分析的异质性需要一些新颖的解决方案，这些解决方案超出了现代分布式数据库免费提供的功能。](http://www.spotifyartists.com/spotify-next-big-sound-artist-analytics/) -## 进化一-使之工作 +Next Big Sound 也已经在全云提供商（Slicehost），混合提供商（Rackspace）和托管（ [Zcolo](http://www.zayo.com/services/colocation) ）之间进行了过渡，而这些工作全部由小型工程人员使用，除了开放源码系统外什么也没有。 在这个过程中我们不乏经验教训，我们希望其他人可以从我们的成功和失败中汲取教训。 -刚开始时，您只想完成工作，无论完成多少。 您如何确定需要解决的问题？ Avacodo 所做的是有目的地测试他们的软件，寻找弱点，修复它们，然后进行迭代。 一个非常明智的增量过程。 您可能会想，为什么不跳到最终结果，但是那永远不会真正解决。 敏捷/精益思维的所有观点都有很多真理。 每个大型系统都是从较小的系统演变而来的。 +## 统计信息 -* 第一个问题：您真的需要扩展吗？ 为什么要经历所有这些努力？ Avocado 正在促销中，他们希望带来更多的流量，而他们负担不起那些潜在的新用户带来的不良体验。 因此，必须应对大量的流量高峰。 -* 他们从典型的拥有每种功能设置的服务器开始：1 前端服务器（存储：API，Web 状态，socket.io，HAProxy，隧道/ SSL 加密）； 1 个 Redis 服务器; 1 个 MySQL 服务器； 1 个批处理服务器（正在运行其他守护程序）。 -* 复制测试设置用于运行常见的方案，例如帐户创建。 -* 在测试环境中使用较小的 EC2 实例可以节省资金，并且可以消除与资源相关的错误。 -* 使用 [jmeter](http://jmeter.apache.org/) 构建的测试脚本每分钟模拟成千上万的用户注册。 -* 测试旨在使用不同的场景来发现薄弱环节，例如添加第二台服务器并使用服务器上的所有 CPU。 -* 通过数千个同时注册来提高性能： - * 由于创建新的 Python 进程来发送电子邮件验证和调整个人资料图片的大小而导致的 CPU 高峰。 - * 所有这些都发生在一个盒子上。 - * 一些 MySQL 查询需要很长时间。 - * SSL 是主要的 CPU 负载 +* 40 个节点 Hadoop 集群（150TB 容量），约 60 个 OpenStack 虚拟机 -## 进化二-测试驱动的变更 +* 10TB 的未复制压缩指标数据（原始 6TB，已索引 4TB） -根据测试结果，他们： +* 10 名工程师，共 22 人 -* 添加了一些数据库索引以加快访问速度。 创建表时，您是否不应该知道要添加哪些索引？ 这不是很明显吗？ 有时是，有时不是。 让您的数据库告诉您哪些缓慢的方法也适用，尤其是在游戏初期。 -* 重新编写电子邮件验证以使用 node.js 的异步功能，而不是每次都派生一个单独的 Python 进程。 吞吐量提高了 3 到 5 倍。 他们为什么首先使用 Python 方法？ 看来显然是浪费。 也许他们已经有了代码？ 也许他们知道如何用 Python 做到这一点？ 在较大的计算机上可能没有关系。 但这是明智的渐进式变化。 采取可行的措施，并在无法解决时进行修复。 尽管他们在这里仍然有巨大的失败漏洞。 如果进程终止，则用户注册状态机将停止。 -* SSL 已移至其自己的服务器。 同样，这很明显是一个问题，而更大的机器可能会成为一个问题，但是从一台机器上启动肯定更容易。 -* 对于促销，分配了四个新实例来调整图像大小。 晋升后将其删除。 处理预期流量高峰的好策略。 +* 5 年的发展 -## 进化三-生产驱动型变化 +* 每天 30 万次时序查询 -随着我们对生产经验的深入了解，我们可以看到问题的类型正在变为那些很难预测并且似乎只有修复的奇怪问题。 +* 每天有 400G 新数据，处于峰值 -* 在促销监视期间，警报提示响应时间较慢，因此添加了第二台前端服务器。 因此要进行监控。 最终添加了 15 台服务器。 -* 注意到在较大的 EC2 实例上，仅使用一个 CPU，node.js 是单处理器解决方案，并且 HAProxy 每个框仅路由到一个实例。 重新启动 HAProxy 以读取新配置以解决此问题花费了几秒钟，因此他们创建了冗余 HAProxy 服务器以减少停机时间。 -* ELB 用于将流量路由到两个 HAProxy 服务器并处理 SSL，从而减少了代理箱的数量并节省了资金。 -* 这导致 socket.io 出现多服务器问题，因为用户需要与一台服务器维护一个会话。 因此，他们参加了粘性会议，需要做一些棘手的更改。 -* 有趣的发现：Websockets 不能在所有的蜂窝网络上工作。 由于这是至关重要的移动应用程序。 另外，ELB 不支持 websocket。 因此他们使用了 XHR 轮询。 命运的惊人转折。 -* 将 Socket.io 移动到具有 8 个 socket.io 服务器（每个 CPU 一个）的自己的盒子中，总共有 16 个 socket.io 服务器实例。 -* 似乎很多套接字服务器。 为了减少数量，使用了数据库连接池。 最初，每个 socket.io 服务器都有一个数据库连接，该数据库连接将工作排队到数据库中，从而使 socket.io 使用了 8 个 CPU 中的 60％。 每个服务器实例使用 2 至 10 个数据库连接池将 CPU 使用率降至 3％，并显着缩短了响应时间。 -* 为什么不从一开始就使用连接池？ 这是很标准的。 他们没有，我感到很惊讶，但是会出现各种各样的问题，重点不是他们是哪个问题，而是您找到并解决这些问题。 +* 为超过 100 万名艺术家录制了超过 1 万亿个事件，包括 YouTube 音乐视频观看次数（ [Kris Schroder 的 Google I / O 演讲](http://commondatastorage.googleapis.com/io-2013/presentations/1122%20-%20Find%20the%20next%20big%20thing%20with%20the%20YouTube%20Analytics%20API.pdf) [ [GNIP](http://gnip.com/sources/twitter/) ），iTunes 购买和在线广播流（通过[与 Spotify](http://www.spotifyartists.com/spotify-next-big-sound-artist-analytics/) 的合作伙伴关系） -## 进化四-走向全球 +## 平台 -* 移动对夫妇遍布世界各地，因此他们也通过在全球范围内启动服务器进行调整，以指导亚马逊按时进行路由。 注意这有多疯狂。 一次国际发行本来是一笔大买卖。 现在，这只是您要做的另一件事。 -* 他们应该早些时候走向全球吗？ 毕竟，移动性能是应用的关键。 但这太疯狂了，您必须具有系统使用经验，然后才能前往多个位置。 +* **托管**：通过 [ZColo](http://www.zcolo.com/) 托管 -## 进化五-现在使它更好地工作 +* **操作系统**：适用于 VM 和物理服务器的 Ubuntu 12.04 LTS -* 在处理了最初的促销任务，了解了其系统的工作原理并解决了问题之后，现在该考虑自动化和自动部署策略了。 慢慢来，这样您就可以一次担心一种问题。 从一开始就进行自动化将使事情变得非常复杂，因为您甚至在不知道应该如何工作的情况下尝试进行自动化。 更好的渐进式思维。 +* **虚拟化**：OpenStack（2 个 Dell R720 计算节点，96GB RAM，2 个 Intel 8 核 CPU，15K SAS 驱动器） -我读了“ CPU”，但我怀疑很多时候它应该是 CPU“线程”。 在体系结构规模上迭代的一个很好的例子，并且不会感到被堆栈的任何特定部分所束缚。 \ No newline at end of file +* **服务器**：主要是 Dell R420、32GB RAM，4 个 1TB 7.2K SATA 数据驱动器，2 个 Intel 4 核 CPU + +* **部署**：詹金斯 + +* **Hadoop** ： [Cloudera（CDH 4.3.0）](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh.html) + +* **配置**：厨师 + +* **监控**：Nagios，神经节，Statsd +石墨， [Zenoss](http://www.zenoss.com/) ，[立方体](http://square.github.io/cube/)，[口红](http://techblog.netflix.com/2013/06/introducing-lipstick-on-apache-pig.html) + +* **数据库**：HBase，MySQL，MongoDB，Cassandra（最近放弃使用 HBase） + +* **语言**：PigLatin + Java 用于数据收集/集成，Python + R + SQL 用于数据分析，PHP（ [Codeigniter](http://ellislab.com/codeigniter) + [Slim](http://www.slimframework.com/) ），JavaScript（ [AngularJS](http://angularjs.org/) + [Backbone.js](http://backbonejs.org/) + [D3](http://d3js.org/) ） + +* **处理**：黑斑羚，猪，蜂巢， [Oozie](http://oozie.apache.org/) ， [RStudio](http://www.rstudio.com/ide/docs/server/configuration) + +* **联网**：瞻博网络（10Gig，带自动故障转移功能的冗余核心层，机架上有 1 个 Gig 访问交换机） + +## 存储体系结构 + +使用 Cassandra 和 HBase 等分布式系统存储时间序列数据相对简单，但是管理数据随时间变化的方式则要简单得多。 在 Next Big Sound，来自 100 多个源的数据聚合涉及某种传统的 Hadoop [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) 管道，其中原始数据通过 MapReduce 应用程序，Pig 或 Hive 处理，并将结果写入 HBase，以便以后通过[进行检索。 Finagle](http://twitter.github.io/finagle/) / [节俭](http://thrift.apache.org/)服务； 但有一个转折。 Hadoop / HBase 中存储的所有数据均由特殊的版本控制系统维护，该系统支持 ETL 结果随时间的变化，从而允许定义处理管道的代码中的变化与数据本身保持一致。 + +我们在 Hadoop 中管理数据的“版本”方法是对 [Linked.in 数据周期](http://data.linkedin.com/blog/2009/06/building-a-terabyte-scale-data-cycle-at-linkedin-with-hadoop-and-project-voldemort)中所用技术的扩展，其中 Hadoop 的结果将定期重复进行完全重新计算并自动替换 [Voldemort](http://www.project-voldemort.com/voldemort/) 中的旧结果集具有可恢复的版本控制。 我们系统的区别在于版本控制不仅发生在全局级别，还发生在许多可配置的更深层次上。 例如，这意味着，如果我们在 Twitter 上记录艺术家所在国家/地区的转推数，并且发现对推文位置进行地理编码的逻辑在几天内是错误的，那么我们只需创建新的数据版本即可 那些日子，而不是重建整个数据集。 现在，这些新版本中的每一个都将具有不同的值，并且可以将某些版本的访问权限限制为某些用户。 开发人员可能只会看到最新版本，而普通用户将看到旧版本，直到确认新数据正确为止。 像这样的“分支”数据对于跟上数据源和客户请求的变化以及支持有效的增量数据管道至关重要。 + +有关该系统的更多详细信息，此图描绘了上述一些关键差异。 + +[](https://dl.dropboxusercontent.com/u/65158725/hadoop_arch.png) + +有关更多详细信息，请查看 [论文：HBlocks：用于迭代数据工程的 Hadoop 子系统](https://dl.dropboxusercontent.com/u/65158725/hblocks.pdf) 。 + +除了 Hadoop 基础架构，我们还面临许多其他挑战。 跨社交网络和内容分发站点映射音乐行业中实体的关系，构建 Web 应用程序以对数百万个数据集进行排序/搜索，以及通过数百万个 API 调用和 Web 爬网管理信息收集，都需要专门的解决方案。 我们仅使用开源工具来完成所有这些工作，下面简要介绍了这些系统之间的相互关系。 + +[![](img/71a5dfef96b935acef0ce26a6451573f.png)](https://dl.dropboxusercontent.com/u/65158725/nbs_arch.png) + +* **数据表示**：我们的指标仪表板的构建一直是一个正在进行的项目，大部分都是由我们的客户指导的。 要在灵活性和学习曲线之间取得适当的平衡，是一个移动目标，其中有许多不同的数据集，并且维护一致的 JavaScript / PHP 代码库来管理这些代码，这对每个新客户和新功能都将变得更加困难。 以下是到目前为止我们如何处理的一些要点： + + 1. 从简单的 Codeigniter 应用开始，尝试尽可能多地整合 Backbone，现在（积极地）转向 Angular + 2. 大型静态对象的内存缓存（例如国家/地区与州之间的映射） + 3. 用于指标数据缓存和历史记录的本地存储（即，当您重新加载页面时，这就是我们之前所知道的方式） + 4. 用以前使用过的[人力车](http://code.shutterstock.com/rickshaw/)进行的 D3 绘制图形 + + 同样，我们对功能标志不做任何花哨的事情，但是我们不断地使用它们的基本实现。 在一直被重写的代码库中，它们一直是一个至关重要的（尽管有时是混乱的）常量，如果没有它们，我们将无法完成许多工作。 + +* **查找**：我们已投入巨资开发产品，使我们的用户能够根据多种标准在我们的数据中搜索有趣的歌手或歌曲（我们称其为“ “查找”产品）。 与音乐的股票筛选器类似，该产品可让用户按“在以前从未出现在某种流行度图表上的 YouTube 视频观看次数的 30％-40％范围内说唱艺术家”等条件过滤后对结果进行排序。 此基础结构的大部分驻留在 MongoDB 中，该位置由 MapReduce 作业提供索引丰富的集合，并在数百万个实体中提供近乎即时的搜索功能。 + + 在 MongoDB 上构建这种类型的产品效果很好，但是索引限制一直是一个问题。 我们目前正在探索更适合这种用例的系统，特别是 ElasticSearch。 + +* **内部服务**：我们的产品和 API 使用的所有度量标准数据均从内部 Finagle 服务提供，该服务从 HBase 和 MySQL 读取。 这项服务分为多个层（所有层都运行相同的代码），在这些层中，我们的产品直接使用了更关键的低延迟层，而第二层则具有更高的吞吐量，但具有更高的 90％延迟 程序化客户。 两者中的后者往往更加突发和不可预测，因此使用这样的单独层有助于使客户的响应时间尽可能短。 这也是一种方便的拆分方式，因为这意味着我们可以为关键层构建更小的虚拟机，然后将其他 Finagle 服务器阵列并置在我们的 Hadoop / HBase 计算机上。 + +* **下一个 Big Sound API** ：我们已经在对外公开以及在内部为产品提供动力的主要 API 上进行了许多迭代。 以下是一些我们发现最有影响力的最佳做法： + + 1. 不要构建仅公开方法的 API，不要构建对系统中的实体建模的 API，并让 HTTP 动词（例如 GET，PUT，POST，HEAD，PATCH，DELETE）暗示这些实体的行为。 这使得 API 的结构更容易推断和试验。 + 2. 对于需要实体*关系*的方法，请对主要实体使用类似“字段”参数的方法，并让该参数中的字段存在暗示实际上需要查找什么关系。 对我们来说，这意味着我们的 API 公开了带有“ fields”参数的“ artist”方法，该方法仅在将字段设置为“ id，name”时返回艺术家的姓名，但也可能返回有关 YouTube 艺术家的数据 频道及其上的所有视频（如果字段设置为“ id，名称，个人资料，视频”）。 获取实体之间的关系可能很昂贵，因此这是保存数据库查询的好方法，而无需编写一堆丑陋的组合方法，例如“ getArtistProfiles”或“ getArtistVideos”。 + 3. 使用外部公开的 API 来构建自己的产品始终是一个好主意，但是我们看到的另一个微妙的优势是新加入 Web 开发人员。 过去，我们在 JS 代码和 API 调用之间放置了很多 PHP 代码，但现在试图将交互作用严格地限制在 JavaScript 和 API 之间。 这意味着网络开发人员可以将精力集中在他们熟知的浏览器代码上，并且可以与他们喜欢的 Backbone 和 Angular 框架更好地协作。 +* **警报和基准**：音乐世界中总是发生着很多事情，我们尝试在所有噪声中挖掘重大事件的一种方法是通过对整个平台的数据进行基准测试（例如 确定每天发生的 Facebook 喜欢次数的总体趋势），并在客户关心的艺术家看到活跃的活动高峰时提醒我们的客户。 我们在此方面存在一些早期的可伸缩性问题，但我们已经解决了大多数问题，致力于将仅 Pig / Hadoop 用于其结果存储在 MongoDB 或 MySQL 中。 剩下的问题集中在如何为“重要”设置阈值上，到目前为止，我们最大的收获是在线活动趋向于全球趋势和峰值，因此基准必须考虑尽可能多的数据，而不能仅仅关注 在单个实体（或本例中的艺术家）上。 与这些更全面的基线的偏离是*实际*行为变化的良好指示。 + +* **Billboard Charts** ：我们向 Billboard 杂志授予了两张图表，一张用于在线艺术家的整体流行度（[社交 50 图表](http://www.billboard.com/charts/social-50)），而另一张基本上是试图预测哪些艺术家最有可能 以便将来列出该列表（[下一个大声音图表](http://www.billboard.com/charts/next-big-sound-25)）。 计算这些图表不会带来任何重大的缩放挑战，因为它只是对所有艺术家的计算得分进行反向排序，但是生成经过精打细算，具有重复数据删除功能且值得生产的列表是需要考虑的。 我们系统中的重复或几乎重复的艺术家以及这些艺术家与他们的在线个人资料的关联存在很多问题（例如，贾斯汀·比伯的 Twitter 用户名是“ justinbieber”，“ bieber”还是“ bieberofficial”？）。 解决这样的问题通常需要自动化和人机交互的结合，但是当在过滤例程中避免误报非常重要（即，即使删除一个合法的艺术家是一个大问题）时，手动管理也是必要的。 但是，我们发现，通过记住执行的动作然后具有重播这些动作的功能的系统来增加这种管理是非常有效且易于实现的。 + +* **预测性广告牌得分**：我们产生的更有趣的分析结果之一是[专利算法](http://making.nextbigsound.com/post/68287169332/predicting-next-years-breakout-artists)，用于计算艺术家在下一次“突破”时的可能性 年。 此过程涉及[随机梯度增强](http://astro.temple.edu/~msobel/courses_files/StochasticBoosting(gradient).pdf)技术的应用，以基于不同社交媒体号码的“病毒性”来预测这种可能性。 除了数学之外，这很难做到，因为我们使用的许多工具都没有 Hadoop 友好的实现，并且我们发现 [Mahout](http://mahout.apache.org/) 不能在基本应用程序之外运行。 然后，我们针对此类过程的体系结构包括通过 MapReduce 作业构建并写入 MongoDB 或 Impala 的输入数据集，然后通过 [R-Mongo](http://cran.r-project.org/web/packages/RMongo/index.html) 和 [R-Impala](http://cran.r-project.org/web/packages/RImpala/index.html) 引入 R 中，然后进行处理 在单个巨型服务器上使用 R 的一些并行处理库，例如[多核](http://cran.r-project.org/web/packages/multicore/index.html)。 使用 Hadoop 进行大多数繁重的工作，并将其余的工作留给单个服务器存在一些明显的局限性，目前尚不清楚我们最终将如何解决这些问题。 [RHadoop](https://github.com/RevolutionAnalytics/RHadoop/wiki) 可能是我们最大的希望。 + +## 托管 + +* 推出自己的网络解决方案很糟糕。 如果您要组成一个小型团队，请确保您已经有人专心完成以前完成的任务，否则请找人。 这很容易成为我们托管的最大痛苦（也是一些令人恐惧的中断的原因）。 + +* 在托管服务提供商之间移动总是很棘手，但如果您预算要在运行于两种环境中的机器上不可避免地花费的额外资金，则不必冒险，它们或多或少地在做同一件事。 除了一些不可避免的例外，我们总是最终在关闭任何旧资源之前，在新的提供程序中完整地复制体系结构，并且通常会进行一些增强。 供应商之间的共享系统似乎永远无法正常运行，通常节省下来的钱不值得缺少睡眠和正常运行时间。 + +* 由于我们约有 90％的容量专用于 Hadoop / HBase，并且工作负载真正稳定，因此很难超越拥有自己的服务器所带来的价格。 由于用户流量，我们的工作量并不是每天都突发，因为与正在进行的所有内部号码处理相比，该流量很小。 我们确实必须定期增加容量，但是将其作为步进功能很好，因为这些增加通常与大客户或数据合作伙伴的收购相吻合。 这就是为什么我们继续使用自己的硬件每月可节省约 2 万美元的原因。 + +## 获得的经验教训 + +* 如果您要汇总来自许多来源的数据并对其进行适度的转换，那么您将犯错误。 在大多数情况下，这些错误可能很明显，您可以在将它们投入生产之前将其修复，但是在其余时间中，一旦它们出现，您将需要适当的地方来对其进行处理。 这是我们在意识到这一点之前经历了很多次的场景： + + 1. 为 Twitter 艺术家的追随者收集 TB 级的数据集，在一两天内将其加载到数据库中。 + 2. 让客户知道数据已经准备好了，而让我们知道这些数据真是太棒了。 + 3. （一个月后）等等，为什么所有追随者中有 20％生活在堪萨斯州的大黄？ + 4. 哦，将位置名称转换为坐标的代码会将“ US”转换为该国家中部的坐标。 + 5. 好的，既然客户仍在使用数据集的正确部分，我们就不能删除整个内容，而只能对其进行重新处理，将其写入新表中，更新所有代码以读取两个表中的所有代码，仅从中获取记录 如果新表中不存在旧表，则在重新处理完成后删除旧表（容易吗？）。 + 6. 一百行骇人的意大利面条代码（永不消失），几天后，工作完成。 + + 在某些情况下，可能有一种更聪明的处理方式，但是当您遇到足够多的情况时，很显然，您需要一种更新生产数据的好方法，而不仅仅是将其完全删除和重建。 这就是为什么我们要为它构建系统的麻烦。 + +* 我们的大多数数据都是使用 Pig 生成和分析的。 它功能强大，几乎我们所有的工程师都知道如何使用它，并且它作为我们存储系统的中坚力量发挥了很好的作用。 搞清楚它到底在做什么，到底有什么进展，我们发现 Netflix 的 Lipstick 对此很有帮助。 我们还发现，用 Pig 来缩短开发迭代的时间很重要，而不是具有较高的可见性。 必须花时间在运行时间更长的脚本上智能地构建示例输入数据集，这些脚本会生成 20 多个 Hadoop 作业，然后再尝试对其进行测试。 + +* 从 0.4 版本开始，我们就使用了 Cassandra 多年，尽管初期经历过恐怖的经历，但是当我们离开它时，它确实很棒。 这一举动与 Cassandra 并没有多大关系，而实际上只是由于我们在重建存储架构时希望使用 Cloudera 平台的结果。 在广泛使用 HBase 和 HBase 之后，我们吸取的教训是，对于大多数人来说，争论使用哪种可能只是浪费时间。 一旦我们了解如何对其进行调整，它们都可以可靠地工作并表现良好，并且专注于我们的数据模型（例如，键压缩方案，行大小上限，使用可变长度整数，查询访问模式）产生的变化要大得多。 + +[下一个 Big Sound Blog](http://blog.nextbigsound.com/) 也有一些关于音乐行业数据挖掘的有趣帖子，如果您真的喜欢这种事情，我们总是[招聘](https://www.nextbigsound.com/about#join)！ + +因此，这些算法将以博弈数据为基础来制定自我强化的商业决策，而这将花费所有人类的技巧和投入。 知道了，商业音乐变得更加孤立和注重结果，而计算机会告诉我们我们想要什么，然后我们就会喜欢它。 明白了，音乐品味的天网。 \ No newline at end of file diff --git a/docs/133.md b/docs/133.md index 1278e22..ead81ff 100644 --- a/docs/133.md +++ b/docs/133.md @@ -1,102 +1,304 @@ -# 可汗学院支票簿每月在 GAE 上扩展至 600 万用户 +# Google 如何备份 Internet 和数十亿字节的其他数据 -> 原文： [http://highscalability.com/blog/2013/4/1/khan-academy-checkbook-scaling-to-6-million-users-a-month-on.html](http://highscalability.com/blog/2013/4/1/khan-academy-checkbook-scaling-to-6-million-users-a-month-on.html) +> 原文： [http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html) - +![](img/e618cf11a7e558cbccc35dc3c895b625.png) -[可汗学院](https://www.khanacademy.org/) 是由 [Salman Khan](https://www.khanacademy.org/talks-and-interviews/key-media-pieces/v/salman-khan-talk-at-ted-2011--from-ted-com) 创立的一家非营利性公司，其目标是向所有人，任何地方，任何时间提供免费的世界一流的教育。 那是很多知识。 长期以来，我受汗学院的启发和迷住，我真的很想知道他们打算如何去做。 [可汗学院的首席开发人员 Ben Kamens](https://twitter.com/kamens) 在一次采访中给出了令人惊讶的答案：[如何将您的初创企业扩展到数百万的用户](http://www.youtube.com/watch?v=r7hC0oVPTVs)。 +[Raymond Blum](https://plus.google.com/115038404694487056892/posts?hl=en) 领导了一组站点可靠性工程师，负责对 Google 的数据保密并确保其安全。 当然，Google 永远不会说这实际上有多少数据，但是从评论看来，它还不是 [约字节](http://en.wikipedia.org/wiki/Yottabyte) ，但很多 [艾字节](http://en.wikipedia.org/wiki/Exabyte) 大小。 仅 GMail 就要处理近几十亿字节的数据。 -**简短答案**：组建一支强大的团队，专注于功能，让 [Google App Engine](https://appengine.google.com/) 负责。 +Blum 先生在视频中 [Google 如何备份互联网](http://www.youtube.com/watch?v=eNliOm9NtCM) 解释了常见的备份策略不适用于 Google 原因：通常他们以容量 扩展规模 **。 如果备份两倍的数据需要两倍的工作量（时间，精力，空间等），那么它将无法正常工作，并且无法扩展。 您必须找到效率，以便容量可以比支持该容量所需的努力更快地扩展。 从备份一个 EB 备份到备份两个 EB 时，需要一个不同的计划。 谈论主要是关于 Google 如何做到这一点。** -在采访中，有些人似乎被 GAE 的全部爱拒之门外。 部分原因在于，面试官是 Google App Engine 的开发倡导者 Fred Sauer，因此两者之间有一定程度的熟悉度。 但是最大的原因是，由于您应该喜欢 GAE 的所有原因，他们真的很喜欢 GAE。 没关系。 在这个时代，您可以自由选择任何平台。 +演讲的一些主要主题： -**最大的惊喜**： +* **从来没有数据丢失** 。 即使是臭名昭著的 GMail 中断也没有丢失数据，但是故事远不只是大量的磁带备份而复杂。 从整个堆栈中检索数据，这需要在各个层面（包括人员）进行工程设计。 -* “ 60 分钟”上的个人资料所带来的访问量比 TechChrunch，HackerNews 和其他所有内容的总和还多。 旧媒体还没有死。 +* **备份无用**。 这是您关心的还原。 这是一个还原系统，而不是备份系统。 备份是您为还原的奢侈而支付的一种税。 将工作转移到备份上，并根据需要使其变得复杂，以使还原如此简单，一只猫就可以做到。 -第一部分**最喜欢**： +* **您无法线性缩放**。 您无法拥有 100 倍的数据或 100 倍的人员或机器资源。 寻找力的乘数。 自动化是提高利用率和效率的主要方法。 -* GAE 是所有典型可扩展性问题的抽象，让您专注于业务问题。 所有 [抽象泄漏](http://www.joelonsoftware.com/articles/LeakyAbstractions.html) ，无论您选择什么，都将不得不处理问题，但是您正在选择要处理的问题类型 根据您选择的平台。 这全都在于了解您要进行的权衡。 +* **冗余**。 Google 的东西总是失败。 废话 人体细胞死亡的方式相同。 Google 并不梦想事情不会消亡。 它计划。 -以下是我对访谈的主要要点： +* **所有事物的多样性** 。 如果您担心站点的位置，请将数据放在多个站点中。 如果您担心用户错误，请与用户交互隔离。 如果要防止软件错误，请把它放在其他软件上。 将东西存储在不同的供应商设备上，以减少大的供应商错误影响。 -* 汗学院（Khan Academy）每月大约有 600 万用户，也许是 1500 万注册用户。 为了进行比较，Coursera [共有 600 万用户](http://news.illinois.edu/ii/12/1115/coursera_daphne_koller.html) ，但我不确定这些用户的活跃程度。 +* **将人类带出循环** 。 GMail 保留多少电子邮件副本？ 这不是人类应该关心的事情。 一些参数是由 GMail 配置的，系统会处理。 这是一个不变的主题。 制定了高级策略，系统也这样做了。 如果发生超出规范的事情，只会打扰到人。 -* 演变： +* **证明** 。 如果您不尝试，将无法使用。 不断测试备份和还原，以验证它们是否有效。 - * 最初，创建了视频以支持学习如何解决数学问题。 这些视频托管在 YouTube 上。 YouTube 没有扩展问题。 +对于任何规模的组织，这里都有很多值得学习的地方。 布拉姆先生的 [演讲](http://www.youtube.com/watch?v=eNliOm9NtCM) 具有娱乐性，内容丰富，值得一看。 他似乎确实很喜欢工作中的挑战。 - * 但是 YouTube 不是交互式的，他们要做的很大一部分是向用户展示学习树，进行测验，管理结果等。因此，他们首先尝试了一个基于 Java 的自托管网站，但该网站被压碎了。 加载。 +这是我对这个非常有趣的演讲的掩饰，我们从野兽内部学习了许多秘密： - * 然后切换到 GAE。 可汗学院与许多初创公司不同，因为它已经在 YouTube 上建立了一个现成的受众群体。 数十万用户从 YouTube 切换到 GAE。 他们缓慢地建立了可以处理新用户的非 YouTube 网站的基础。 在 YouTube 上引导客户可能是一个不错的一般策略。 +* **数据可用性必须为 100％ 。** **从来没有数据丢失**。 - * 有很多新闻报道，整个事情如雪球般滚滚，而且还在不断增长。 + * 从统计上讲，如果您从 2GB 的文件中丢失了 200K，这听起来不错，但是该文件现在可能已无用，请考虑执行文件或纳税申报单。 -* 为什么选择 GAE？ + * 数据的可用性对访问的可用性更为重要。 如果系统出现故障，那不是世界末日。 如果数据丢失，那就是。 - * 对于任何一家初创公司来说，不要使用 GAE 或 EC2 之类的提供商都是没有道理的。 它们有助于解决许多您不需要解决的可伸缩性问题。 轻而易举。 如果您吸引了很多注意力，则可以立即投入更多资金并扩大规模。 + * Google 保证在所有可能的组合中为您提供以下所有服务： - * Spectrum：您想要开箱即用的控制权与可伸缩性的要求是多少？ 控制得越多，您越有可能朝自己的脚开枪，做错事。 + * 位置隔离 - * GAE 为您提供了开箱即用的可扩展性。 只要插入信用卡，就不会有很多可扩展性问题。 这为我提出了一个要点：他们如何负担 GAE？ 有趣的是，非营利性经济学可以使人们摆脱对每个新客户获取成本的关注，而不必担心货币化策略。 + * 与应用层问题的隔离 - * 使用 AWS，您必须更多地玩游戏，知道如何处理实例，这需要花费更多时间。 + * 与存储层问题的隔离 - * 他们不携带传呼机，不用担心复制，不需要重启实例，也不需要应用操作系统补丁。 他们与 GAE 并不需要做很多事情。 + * 与媒体故障隔离 - * Khan Academy 的暑期实习生 Dylan Vassallo 参与了多个 App Engine 项目，并在 Hacker News 主题 中发表了出色的评论 [像 GAE：我是可汗学院的暑期实习生，从事各种 App Engine 项目。 我没有根据的猜测是我们是该平台的大客户之一。 GAE 最大的缺点之一就是缺乏控制：与 EC2 不同，在 EC2 中，您需要根据自己的需要来模制原始的 Linux 安装，而您的应用程序必须始终符合 GAE 的服务模型。 但是，通过放弃其中一些自由，您会得到很多很棒的回报。 可汗学院（Khan Academy）已成功利用 App Engine 扩展到数百万用户，而无需雇用一个系统管理员或花费太多时间担心与操作相关的任何事情。 我们能够毫不费力地应对流量高峰，例如 60 分钟的外观和新计算机科学课程的发布（http://khanacademy.org/cs）。 要部署站点，任何开发人员（或我们友好的 CI 机器人）都可以简单地运行我们的“ deploy.py”并等待几分钟，然后回到花时间在产品上。 我们不必再考虑数据库是否可以处理我们向其抛出的写负载。 就此而言，App Engine 数据存储区是独一无二的无后顾之忧。 （嗯，我敢肯定 Google SRE 对此非常担心，但我们不必这样做。）](about:blank) + * **考虑可以在** 上移动滑块的尺寸。 将软件垂直放置，水平放置。 如果要涵盖所有内容，则需要在不同位置复制该软件层。 您可以在不同位置的 VM 上执行此操作。 -* 为什么旧媒体仍然有意义。 与 60 分钟驱动的流量相比，来自 TechCrunch，HackerNews 等的所有流量都不算什么。 差远了。 +* **冗余与可恢复性** 不同。 - * 他们知道他们将获得大量流量，因此他们准备好转弯右拨盘，以快速启动新实例。 这就是他们所做的一切。 这是一个错误。 + * 多份复印无助于达到无损保证。 - * 他们最终为这些新用户做了很多不必要的工作。 他们需要简化体验。 例如，他们认为对于所有这些新流量来说，这将是运行该平台的好时机，这是第一次使用其新的测试基础架构来跟踪所有这些美味数据的 A / B 测试。 失败了 + * 许多副本对某些类型的中断有效。 如果小行星撞击数据中心，并且您的副本很远，您就会被覆盖。 - * 只要确保主要体验干净整洁。 如果您必须跟踪数据，请确保它非常重要，并使用经过良好测试的数据跟踪解决方案。 + * 如果存储堆栈中有错误，则复制到 N 个位置无济于事，因为该错误会损坏所有副本。 以 GMail 中断为例。 - * 不要一次增加流量运行新代码。 您只会得到一次。 如果有一半的国家因为您试图跟踪太多数据而无法访问该网站，那么这是不值得的。 + * 小行星的数量不及代码错误，用户错误或缓冲区写入错误。 - * 他们现在要做的是使主页尽可能静态，简单，快速地加载，如果您分支出主页，则可以获得完整的体验。 简化传入流量。 + * 冗余有利于参考位置。 当您希望所有数据引用都尽可能靠近使用数据的位置时，复制就很好。 -* 没有进行足够的负载测试。 60 分钟带来了很多流量，并且没有经过测试。 但是它们具有一致的高流量负载，当不同时区的用户上线时，流量每天都会激增。 交通也是季节性的。 他们通过自然流量模式获得了很多有用的压力测试。 他们必须处理高峰，低谷，人流量少的月份，然后人流量大的时候。 因此，他们知道必须在 GAE 中配置其代码才能处理该峰值。 +* **整个系统非常强大，因为其中有很多**。 -* 将您的工作尽可能多地转移给其他人。 他们适合哪个 GAE。 巨大的胜利。 在有 9 名或 10 名员工的情况下，他们认为不再需要解决性能问题，并希望下一次能够解决问题。 他们将人们奉献给表演。 他们建立仪表板以提前预测问题。 试图更加积极地关注性能和可伸缩性问题。 + * **Google 内容始终失败**。 废话 人体细胞死亡的方式相同。 我们没有梦想事情不会消亡。 我们为它计划。 机器一直死掉。 -* 2 至 5 人的小组不关注可扩展性问题。 专注于功能。 使您的产品很棒。 让人们回到它。 成功开展业务后，您就可以对所有想要的东西进行过度设计。 当您有机会构建成功的产品时，请担心问题。 + * **冗余就是答案** 。 总的来说，结果比一台高质量机器更可靠。 一架机器可以被小行星摧毁。 放置在 50 个不同位置的机器更难销毁。 -* 绩效是每个人的工作，每个人都被分配给它。 尝试在整个团队中建立对绩效的总体意识。 +* **大规模并行系统有更多的损失机会** 。 - * 您将遇到大获胜的性能问题，然后这是一个反复的较小的改进游戏，每次改进.25％，. 5％导致性能提高，因此这必须是每个人的工作。 人们不仅可以投入额外的 JavaScript 或进行新的数据库查询，还只会使您的网站运行缓慢。 + * 可以在 30K 台计算机上运行的 MapReduce 非常棒，直到出现错误为止。 您有相同的错误等待立即在任何地方运行，从而扩大了影响。 - * 他们有一个或两个人的团队专注于表现的宿舍。 可能是性能改进，也可能是工具，可以使他们更加了解性能。 +* **本地副本无法防止站点中断** 。 -* 收集大量数据。 他们想向老师和其他人报告数据。 他们的旧数据存储系统无法汇总所有数据。 因此，他们致力于： + * 如果服务器机房中有洪灾，RAID 将无济于事。 - * 汇总数据 + * 大约一年前，在整个 Google 上使用的 Google 文件系统（GFS）将 RAID 的概念提升了一个档次。 使用 [编码技术](http://en.wikipedia.org/wiki/Erasure_code) 一次写入不同城市中的多个数据中心，因此您只需要 N-1 个片段即可重建数据。 因此，有了三个数据中心，一次就可以消亡，您仍然可以获得可用的数据。 - * 在写入上做更多的工作，因此读取速度很快。 重新配置数据。 复制到任何地方。 使其真正快速地进行以后的分析。 +* **可用性和完整性是组织范围内的特征** 。 - * 对于分析而言，它们似乎可能不在 GAE 范围内，但这并未具体说明。 + * Google 工程师，BigTable，GFS，Colossus 都知道数据持久性和完整性是第一要务。 有很多系统可以检查和纠正数据可用性和完整性方面的任何失误。 -* 在需求旺盛之前，请不要着迷于棘手的问题，例如即时重新配置功能。 +* **您想要所有事物的多样性** 。 -* 它们足够小，每个人都应对 DevOps 负责，以保持系统正常运行。 将来，GAE 之外可能会有足够的系统，他们将拥有独立的团队，但目前还没有。 + * 如果您担心站点的位置，请将数据放在多个站点中。 -* 在技术和产品上都使事情变得简单，直到您完全知道需要构建什么为止。 从长远来看，他们为解决问题和解决问题而构建的许多功能会导致真正的问题。 构建后很难将其关闭。 + * 如果您担心用户错误，请与用户交互隔离。 -* 懒惰。 使用其他人的工具。 在您的企业表现出色之前，请不要害怕使用他人的工作。 + * 如果要防止软件错误，请将其放在其他软件上。 将东西存储在不同的供应商设备上，以减少大的供应商错误影响。 + +* **用来备份内容的磁带确实非常好** 。 + + * **磁带很棒，因为它不是磁盘** 。 如果可以的话，他们会使用打孔卡。 + + * 想象一下您是否在 SATA 磁盘的设备驱动程序中存在错误。 磁带可以帮助您避免麻烦。 因为不同的媒体意味着不同的软件，所以它增加了您的多样性。 + + * 磁带容量遵循摩尔定律，因此尽管他们正在研究替代方案，但他们对磁带作为备份介质感到非常满意，但他们不会说它们是什么。 + + * 磁带已加密，这意味着邪恶力量很难从中获得有用的东西。 + +* **备份无用。 这是您关心的** 还原。 + + * 在有人需要数据之前先确定是否存在问题。 当您需要还原时，您确实需要它。 + + * **运行连续还原** 。 不断随机选择 5％的备份并还原它们以进行比较。 为什么？ 在数据丢失之前找出备份是否有效。 抓了很多问题。 + + * **运行自动比较** 。 由于原件已更改，因此无法与原件进行比较。 因此，对所有内容进行校验和并比较校验和。 将其返回到源介质，磁盘或闪存，或它来自何处。 确保数据可以往返。 这一直都在做。 + +* **出现故障率变化的警报** 。 + + * **如果有所不同，您可能想了解一下** 。 如果一切正常，请不要告诉我。 + + * 可能会出现一些故障，但不要针对第一次尝试后无法还原的文件发出警报。 + + * 假设第一次尝试的失败率通常是 N。第二次尝试的失败率是 Y。如果失败率发生变化，则说明出现了问题。 + +* **一切都破裂了** 。 + + * 磁盘一直损坏，但是您知道它发生的时间，因为您正在监视它。 + + * 使用磁带之前，您不知道它已损坏，直到尝试使用它为止。 磁带可以使用很长时间，但是您需要先对其进行测试。 + +* 磁带 上的 **[RAID4](http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_4) 。** + + * 不要只写一盘磁带。 它们是墨盒。 机器人可能会掉落它们，或者可能会产生一些磁通量。 不要碰碰运气 + + * 写入磁带 **时，告诉编写者保留数据** ，直到可以更改为止。 如果这样做，您就违反了合同。 + + * 建立 4 个完整的磁带，然后通过将所有内容异或来生成第 5 个代码带。 您可以丢失 5 盘磁带中的任何一盘并恢复数据。 + + * 现在告诉编写者他们可以更改源数据，因为数据已经将其移到了最终的物理位置，并且现在是冗余的。 + + * Google 备份的每一位数据都经过此过程。 + + * 一个月会丢失数百个磁带，但是由于这个过程，每月不会有数百个数据丢失案例。 + + * 如果丢失了一条磁带，则可以使用连续还原检测到该磁带，并使用同级磁带重建另一条磁带，一切正常。 在极少的情况下，如果两个磁带都损坏，则只有在磁带上的相同两个点都损坏的情况下，数据才会丢失，因此在磁带级进行重建。 + + * 由于这些技术，不会造成数据丢失。 这很昂贵，但这是做生意的成本。 + +* **备份是您为还原**所支付的奢侈税。 + + * **这是一个还原系统，而不是备份系统** 。 恢复是不可屏蔽的中断。 他们胜过一切。 恢复备份。 + + * 使备份变得复杂并且需要的时间很长。 使恢复尽可能快和自动。 + + * 恢复应该是愚蠢的，快速且简单的。 希望一只猫能够触发集中还原。 + + * 当您休息好或狗累了时，恢复可能会发生。 因此，您不希望人为因素决定还原服务数据副本是否成功。 你压力很大。 因此，在进行备份的所有时间中，所有工作和思考都要做。 + + * 大量系统以这种方式工作。 + + * 数据源可能必须能够存储一段时间（也许几天），然后才能保证已备份数据。 但是一旦备份，便可以快速还原和还原。 + + * 不再最有效地利用备份上的介质来加快还原速度。 花两个小时读磁带是不好的。 只写一半的磁带并并行读取它们，这样您就可以在一半的时间内取回数据。 + +* **秤是一个问题** 。 + + * 当您有 EB 级数据时，会有现实世界的限制。 如果您必须复制 10 EB，那么每天备份数据可能需要 10 周的时间。 + + * 在全球的数据中心中，您有几种选择。 您是否给每个站点近乎无限的备份能力？ 您是否按地区对所有备份进行群集？ 运送数据的带宽呢？ 您不需要带宽来赚钱吗？ + + * 查看相关费用。 有妥协。 并非每个站点都具有备份功能。 必须平衡网络上的可用容量。 您从哪里获得最大的收益。 例如，备份必须在站点 X 上进行，因为它具有带宽。 + +* **您无法线性缩放**。 + + * 不能只是说您想要更多的网络带宽和更多的磁带驱动器。 驱动器损坏，因此，如果驱动器数量为 10,000，则需要的操作员数量是驱动器数量的 10,000 倍。 您是否有 10,000 倍的装载台来放置磁带驱动器，直到卡车将其捡起。 这些都不是线性的。 + + * 尽管磁带库的数量增加了一个完整的数量级，但涉及的人数却没有 10 倍。 还有更多的数字，但远非线性增长。 + + * 例子是一个早期的预测，随着电话数量的增长，美国人口的 30％将被用作电话接线员。 他们看不到的是自动切换。 + +* **自动化所有** 。 + + * 调度是自动的。 如果您有一项服务，则说我有一个数据存储，并且每个 N 都需要一个副本，并且还原必须在 M 中进行。在内部，系统会做到这一点。 计划备份，运行还原测试以及运行完整性测试等。当检测到损坏的磁带时，将自动对其进行处理。 + + * 您作为人类没有看到任何这些。 您可能有一天会问平均多少磁带断裂。 否则，如果磁带损坏率从每天 100 条磁带更改为每天 300 条磁带，可能会发出警报。 但是在此之前，请不要告诉我每天是否有 100 盘磁带破损，如果这超出了正常范围。 + +* **人体不应参与稳态操作** 。 + + * 包装和运输驱动器仍然是人类的活动。 自动化的界面可以准备运输标签，获取 RMA 编号，检查包裹是否已外出，获得收据确认，以及是否发生这种情况，必须由人工干预。 + + * **库软件维护同样** 。 如果要进行固件更新，则不会有人在每个系统上运行并执行升级。 下载它。 让它推送到金丝雀图书馆。 让它进行测试。 让结果验证为准确。 然后将其推出。 没有人参与正常操作。 + +* **自动处理机器死亡** 。 + + * 机器每分钟死两次。 如果一台机器在使用 30,000 台机器的 MapReduce 工作中快要死了，请不要告诉我，只需处理并继续前进即可。 查找另一台机器，移动工作，然后重新启动。 + + * **如果存在依赖项，则安排等待时间**。 如果您等待太久，请告诉我。 您可以自己安排时间。 这是算法的工作，而不是人类的工作。 + +* **随着增长不断提高效率** 。 + + * 大大提高了利用率和效率。 不能有 100 倍的数据需要 100 倍的人员或机器资源。 + +* **2011 年的重大 GMail 中断和恢复** 。 关于 Google 如何删除数据并取回数据的故事。 + + * 在星期日的上午 10:31，他得到了一个页面，上面写着“ Holly Crap call xxx-xxxx”。 有关中断的更多信息 [此处](http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html) 。 + + * Gmail 的数据量已接近 EB。 磁带很多。 + + * 100％恢复。 可用性不是 100％。 在第一天或第二天还没有全部。 但是到了一段时期的尽头。 + + * 在复制发生的层中发生了一系列的错误和不幸。 是的，我们有三个相同的文件，但它们都是空的。 即使进行单元测试，系统测试和集成测试，错误也可以解决。 + + * 从磁带恢复。 大量工作。 这是恢复时间与规模有关的地方。 取回千兆字节可以在几毫秒到几秒钟内完成。 取回 200,000 个各个演出的收件箱将需要一段时间。 + + * 在欧洲唤醒了几个同事，因为他们比较新鲜。 分布式劳动力的优势。 + + * 已从许多磁带上还原了数据并进行了验证。 没花几个星期或几个月，只花了几天。 他们对此感到满意。 其他处于类似情况的公司花了一个月的时间才意识到他们无法取回数据。 已采取步骤来确保下一次该过程将更快。 + + * 一个磁带机需要 2 个小时才能读取。 磁带遍布各处。 否则，任何一个位置都将没有足够的能力来读取还原过程中涉及的所有磁带。 + + * 使用压缩和校验和，他们实际上不需要读取 200K 磁带。 + + * 从那时起，恢复流程已得到很大改善。 + +* **优先还原** 。 + + * 可以在保存更重要的数据（例如当前收件箱和发送的电子邮件）之后恢复已存档的数据。 + + * 一个月内没有被触摸过的帐户可以等待，直到更活跃的用户被首先还原。 + +* **备用系统被视为巨大的全球生物** 。 + + * 不想仅在纽约进行 GMail 备份，因为如果该数据中心增长或收缩，则备份需要适当扩展。 + + * 将备份视为一个巨大的全球跨越系统。 进行备份时，它可能完全位于其他位置。 + + * 必须在磁带所在的位置进行磁带还原。 但是在制作磁带之前，数据可能在纽约，而备份在俄勒冈州，因为那里有足够的存储空间。 位置隔离是自动处理的，不会告诉客户端其数据备份的位置。 + + * 容量可以移动。 只要具有全球容量并且网络可以支持它，磁带位于何处都没有关系。 + +* **您拥有的数据越多，保留它就越重要** 。 + + * 通常，越大的东西越重要。 Google 过去只是搜索。 现在是 Gmail，存储在驱动器，文档等中的东西。它既更大，也越来越重要。 + +* **拥有良好的基础架构** 。 + + * 可以使用通用的瑞士军刀真的很不错。 编写 MapReduce 时，他们可能从未想到过将其用于备份。 但是，如果没有 MapReduce，就不可能出现将其用于备份的想法。 + +* **缩放比例确实很重要，您无法拥有任何无法扩展的部分-软件，基础架构，硬件，流程-**。 + + * 您不能说我将在拥有操作人员的情况下部署更多的磁带机。 如果您要雇用两倍的人，您有两倍的停车位吗？ 自助餐厅的房间？ 洗手间？ 一切都必须扩大规模。 您将遇到一个瓶颈，它将阻止您。 + +* **证明** 。 + + * 不要将任何事情视为理所当然。 希望不是战略。 + + * 如果不尝试，将无法使用。 必须进行还原才能验证备份。 直到最后，您还没有证明任何东西。 这种态度发现了很多失败。 + +* **DRT。 灾难恢复测试** 。 + + * 每 N 个月就会发布一次灾难场景。 模拟组织各个级别的响应。 + + * 在灾难不带走任何损失的情况下，公司将如何生存？ 必须学会适应。 + + * 发现基础结构和物理安全方面的巨大漏洞。 + + * 想象一下，一个数据中心有一条通向它的道路，并且有卡车在路上装载着备用发电机的燃料。 路迷路了怎么办？ 最好有一条道路和另一家柴油燃料供应商。 + + * 确实有供应链冗余策略。 + +* **在不同时间点在不同位置的不同软件堆栈中的冗余** 。 + + * **不要只让数据在堆栈中迁移** 。 将数据保留在堆栈的不同层中一段特定的驻留时间。 因此，如果您丢失了该数据，则此数据会重叠。 时间，位置和软件。 + + * 考虑 GMail 中断示例。 如果复制损坏了，怎么也不会丢失数据？ 这是听众提出的问题，他真的不想透露细节。 数据一直在备份。 假设我们有截至 9PM 的数据。 假设损坏发生在晚上 8 点，但尚未录制到磁带上。 腐败被制止了。 软件已回滚到工作版本。 在堆栈中的某个时刻，所有数据仍然存在。 磁带上有东西。 有东西正在复制。 前端有东西。 日志中有东西。 所有这些来源都有重叠之处，有可能重建所有数据。 对于这种情况，政策是直到将数据放入另一个堆栈中 N 个小时后，才从一个卡住的数据中取出数据。 + +* **删除问题** 。 + + * 我要删除它。 不会为了删除数据而重写磁带。 大规模而言太昂贵了。 + + * 一种方法是对加密密钥进行智能处理。 他没有告诉我们 Google 做什么。 也许丢失了有效删除数据的密钥？ + +* **当您信任同事并分担责任时，一个庞大的组织就可以工作。** 。 + + * 相信他们了解自己的部分。 + + * 确保组织和软件接口定义正确。 在各层之间实施验证测试。 + +* **白名单和黑名单**。 + + * 确保数据位于保证的位置，并保证不在某个位置，这与其余的哲学原理（即位置多样性和位置独立性）背道而驰。 + + * 最初不是堆栈的功能。 必须添加以支持政府要求。 + + * 在堆栈中将责任降低得越低越好。 填写正确的个人资料，它就会神奇地发生。 ## 相关文章 -* [Ben Kamens 博客](http://bjk5.com/) 中，关于可汗学院的话题很多。 非常可爱的狗。 他在 [亚马逊的 Mega Dropdown](http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown) 上写了一篇很棒的文章。 -* [GitHub 上的可汗学院](https://github.com/Khan) -他们的所有代码均为 [开源](https://khanacademy.kilnhg.com/) -* 如果 GAE 对您中的某些人来说太过分了，这是关于 [的好消息，有关 Google App Engine](https://news.ycombinator.com/item?id=4403739) 的隐藏成本 -* [我在可汗学院（Khan Academy）做过的事情](http://jamie-wong.com/2012/08/22/what-i-did-at-khan-academy/) -虽然视频内容很笼统，但这是关于团队所做工作的具体内容 -* Google Group for [Khan Academy Developers](https://groups.google.com/forum/?fromgroups#!forum/khanacademy-developers) -* [可汗学院使用 GAE / Bingo 进行的 A / B 测试课程](http://bjk5.com/post/28269263789/lessons-learned-a-b-testing-with-gae-bingo) -* [Khan Academy Docs](https://sites.google.com/a/khanacademy.org/forge/home) -很多果汁详细信息 -* [可汗学院使用 Google App Engine](https://cloud.google.com/files/KhanAcademy.pdf) 来扩展和简化 -* [有关可汗学院开发工作原理的大图片](http://www.brianbondy.com/blog/id/109/) [图](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions) -* [GAE 调整应用性能](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions) [调节](https://developers.google.com/appengine/docs/adminconsole/performancesettings) -您的旋钮，如果您知道 [如何调整它们](http://bjk5.com/post/40833194761/pending-queues-and-loading-requests-on-app-engine) 。 -* [第 1 部分：可汗学院首席开发人员 Ben Kamens 访谈](http://www.youtube.com/watch?v=BXxYEhwDh28) -* [访谈：可汗学院首席开发人员 Ben Kamens 回答了您的问题](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions) \ No newline at end of file +* [在 Reddit 上](http://www.reddit.com/r/programming/comments/1wzsmk/how_google_backs_up_the_internet_along_with/) + +“如果您想对软件错误进行“保护”，那么？？？ + +嘿托德， + +这是一个令人难以置信的帖子，其中包含许多有用的信息，非常感谢您将其组合在一起！ + +嘿， + +我想知道更多有关 Google 备份的内容。 是完整的档案备份，以便保存在 google 中创建的每个文件，还是更多的滚动备份，其中删除了未使用的数据，仅备份了最近的几周。 + +另外，是 Google 对数据进行重复数据删除，还是每个用户的每个文件等等，都是单独保存的。 + +呵呵，所以安全是一个问题。 +这是我在网上找到的最佳信息之一，谢谢分享 \ No newline at end of file diff --git a/docs/134.md b/docs/134.md index b92edcd..383baea 100644 --- a/docs/134.md +++ b/docs/134.md @@ -1,65 +1,43 @@ -# Iron.io 从 Ruby 迁移到 Go：减少了 28 台服务器并避免了巨大的 Clusterf ** ks +# 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧 -> 原文： [http://highscalability.com/blog/2013/3/13/ironio-moved-from-ruby-to-go-28-servers-cut-and-colossal-clu.html](http://highscalability.com/blog/2013/3/13/ironio-moved-from-ruby-to-go-28-servers-cut-and-colossal-clu.html) +> 原文： [http://highscalability.com/blog/2014/2/10/13-simple-tricks-for-scaling-python-and-django-with-apache-f.html](http://highscalability.com/blog/2014/2/10/13-simple-tricks-for-scaling-python-and-django-with-apache-f.html) -![](img/60fa20df9697ae26cfa43f92f27f70a6.png) +![](img/8790837ab14b40922ff5236ee8cf66d7.png) [HackerEarth](http://www.hackerearth.com/) 是一项编码技能实践和测试服务，在一系列写得很好的文章中描述了构建站点的试验和磨难，以及它们如何克服它们：[使用以下方法扩展 Python / Django 应用程序： Apache 和 mod_wsgi](http://engineering.hackerearth.com/2013/11/21/scaling-python-django-application-apache-mod_wsgi/) ，[编程方面的挑战，正常运行时间和错误（2013 年）](http://engineering.hackerearth.com/2014/01/22/programming-challenges-uptime-mistakes/)，P [ ost-mortem：2014 年 1 月 25 日的大故障](http://engineering.hackerearth.com/2014/01/27/big-outage-25-january/)，[强大的实时服务器](http://engineering.hackerearth.com/2013/05/31/the-robust-realtime-server/) ， [100,000 个强大的 CodeFactory 服务器](http://engineering.hackerearth.com/2013/03/12/100000-strong/)，[具有 Django 和 HAProxy 的扩展数据库](http://engineering.hackerearth.com/2013/10/07/scaling-database-with-django-and-haproxy/)，[连续部署系统](http://engineering.hackerearth.com/2013/08/05/continuous-deployment-system/)， [HackerEarth 技术堆栈](http://engineering.hackerearth.com/2013/03/20/hackerearth-technology-stack/)。 -在过去的几个月中，我一直在使用 Go 编写系统程序，因此我一直在寻找信息以补充我的确认偏见。 当 Iron.io 用 Go 重写他们原来忙于工作的作业执行系统 IronWorker 时，Iron.io 写下了他们的[经验，这时机会突然出现，最初是用 Ruby 编码的。](http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html) +这些文章的特征并使其特别有用，是对改进的驱动力和对报告哪些无效以及如何确定哪些有效的开放态度。 -结果： +正如他们所说的那样，当您仅由 3-4 名工程师组成的团队来构建复杂的产品时，就会发生错误，但是对基础架构的投资使他们可以进行更多的休息，在班加罗尔的街道上漫游，而他们的服务器每分钟很高兴地为成千上万的请求提供服务 ，同时轻松达到 50,000 个用户群。 -* 从 30 台服务器降至 2 台，第二台服务器仅用于冗余。 -* CPU 利用率降至 5％以下。 -* 内存使用率下降。 只有“几百 KB 的内存（在启动时）与我们的 Rails 应用程序（约 50 MB）（在启动时）”。 -* 级联故障现在已成为过去。 -* 在数百台服务器上运行的新服务全部用 Go 编写。 -* 他们相信使用 Go 可以使他们“制造出色的产品，成长和扩展并吸引 A 级人才。而且我相信它将继续帮助我们在可预见的未来发展。” 通常，建议根据人才库的规模选择一种语言，他们发现选择 Go 语言可以帮助他们吸引顶尖人才。 -* 部署很容易，因为 Go 可以编译为一个静态映像。 -* Go 的次要缺点：学习新语言和有限的库。 -* 对于将获得大量流量的服务器以及要为突然增长做好准备的服务器，Go 是一个不错的选择。 +这是他们做事的方式： -当然，不受第二系统效果影响的重写速度可能要快得多，但您可能还记得，LinkedIn 也有类似的经历： [LinkedIn 从 Rails 迁移到节点：27 台服务器被削减，速度提高了 20 倍](http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html) +**HackerEarth 的当前体系结构：**前端服务器； API 服务器； 代码检查器服务器； 搜索服务器-Apache Solr &弹性搜索； 实时服务器-使用 Tornado 编写； 状态服务器； 工具链服务器（主要用于持续部署）； 集成测试服务器； 日志服务器； Memcached 服务器； 很少有服务器可以处理数据分析数据库和后台作业。 RabbitMQ，Celery 等粘合许多服务器； 监控服务器； 数据库经过分片并通过 HAProxy 进行负载平衡。 -这是 Go 问题解决的解释： +1. **删除不必要的 Apache 模块**。 节省内存并提高性能。 通过只包含您需要的内容，您可以将加载的模块数量减少一半。 +2. **使用 Apache MPM（多处理模块）工作者**。 通常，对于高流量服务器来说，这是一个更好的选择，因为它比前叉 MPM 占用的内存少。 +3. **保持活动状态**。 CloudFront 提供了静态文件，实验表明，这样做效率更高，进程/线程可以自由地即时处理新请求，而不必等待请求到达较旧的连接。 +4. **mod_wsgi** 的守护程序模式。 线程和进程的数量是恒定的，这可以使资源消耗可预测，并防止流量高峰。 +5. **调整 mpm-worker 配置**。 他们在经过大量试验后显示了他们使用的配置，这有利于他们的应用程序类型，这种类型的应用程序比 CPU 占用更多的内存。 +6. **检查配置**。 启用模块 mod_status.so 和 mod_info.so 以查看 Apache 的运行方式。 这些信息帮助他们大大减少了我们必须运行的服务器数量，并使应用程序更稳定，更能抵抗流量突发。 +7. **不会自动缩放**。 100％的正常运行时间是不断的斗争。 卷起袖子，朝着这个目标努力。 +8. **不要为运行 100 台服务器**而感到自豪。 编写更好的代码并调整系统。 向大量请求抛出服务器并不引以为豪。 例如，这意味着确保请求不会查询数据库 20 次。 +9. **异步代码检查器服务器排队系统**。 重写代码检查器服务器排队系统以使其异步，从而大大减少了其前端服务器上的处理开销。 +10. **使用龙卷风进行认真的平行作业**。 “ socket.io”模块无法扩展到超过 150 个同时连接。 Nowjs 还泄漏了文件描述符。 +11. **分片数据库和数据库路由器**。 对数据库进行分片可减少单个数据库的开销，并进一步减少查询延迟。 +12. **缓存它**。 在内存缓存中有超过一百万个键值对，会话以 redis 维护，其他任何持久性数据都进入 MySQL 或 S3，但是大多数缓存都保留了适当的生命周期。 +13. **持续部署**。 手动更新生产中的代码更改会使他们发疯，这将完全浪费时间。 -* 使用 Ruby，持续的服务器 CPU 使用率介于 50％和 60％之间。 添加服务器以将 CPU 使用率保持在 50％，以便可以正常处理流量高峰。 这种方法的缺点是需要水平扩展昂贵的服务器。 -* 他们有一个非常有趣的失败模式。 当流量激增时，Rails 服务器将达到 100％CPU。 这导致服务器出现故障，这导致负载均衡器将流量路由到其余服务器，这导致更多服务器的 CPU 使用率达到 100％。 最终结果是级联失败。 +我实际上很喜欢这篇文章，但是请不要开始使用链接诱饵标题。 我通常会忽略带有此类标题的内容，直到我意识到它具有高可伸缩性，我几乎跳过了这一标题。 -使用 Ruby 的上市时间论点很有道理。 性能并不是一切，但在这里我们看到了性能的价值，尤其是在 Web 层之外。 优质的服务是鲁棒性和成本上的双赢。 +确实。 这不是一些愚蠢的嗡嗡声。这些文章的内容并不保证会被贬低为“＃X 的简单技巧”标题。 -通常，弱点被数量掩盖，数量昂贵且并不总是有效。 +实际上，我尝试了各种各样的内容。 有些长，有些短。 一些原始的，一些其他的。 如果您感兴趣的话，有些则精心策划了其他细节，有些则是独立的。 有些是针对初学者的，有些是针对专家的。 一些非常具体，一些非常笼统。 -性能起到缓冲的作用，使系统能够吸收流量而不会中断，而在打卡机打孔后又能承受打卡机的冲击。 即时分配，拆分新实例需要花费时间，时间足够长，以至于流量峰值可能会导致级联故障。 通过为性能而不是上市时间进行编码，可以防止这些问题的发生。 +因此，任何一篇帖子都可能不是您的事，但这并不意味着它不会成为某人的事。 -## 去并不完美 +项目符号格式是传达特定想法的最快方法。 这些想法可能对许多人来说都是旧帽子，或者是新的有趣的东西。 如果有兴趣，您可以参阅参考的源材料以获取更多详细信息，这正是这个主意。 否则，您可以继续前进，这确实是个主意。 -如果您查看 Go 的 Google 小组，Go 并非没有[性能问题](https://groups.google.com/forum/?fromgroups#!searchin/golang-nuts/performance$20problem)。 这些问题通常可以被编码。 例如，使用 bufio.ReadSlice 而不是 bufio.ReadString 可以删除数据副本，神奇的是您的代码快了 X 倍。 +我认为前两个评论仅表示他们不喜欢标题，因为它看起来像是个骗人的把戏。 但正如他们也指出的那样，您的文章始终都是出色的，这就是为什么继续阅读它的原因。 -学习这些技巧需要时间，尤其是使用这种新语言时。 +确实，内容没有问题。 只是 linkbait 的头衔（不公正地）。 -Go 绝对处于劣势的地方是 JVM 和 V8 JavaScript Engine 多年来优化垃圾收集和代码生成的地方。 Go 可能需要一段时间才能赶上。 - -表演从来都不是免费的。 您必须编写聪明的代码。 最小化共享状态，不要浪费内存，不要像地狱那样配置文件，了解您的语言并通过它来做正确的事情。 - -## 相关文章 - -* [低级可伸缩性解决方案-条件收集](http://highscalability.com/blog/2013/3/11/low-level-scalability-solutions-the-conditioning-collection.html)-将工作盲目地排入队列并不总是最好的方法。 -* [规模甚大甚至赢不了-Google 和 Facebook 示例](http://highscalability.com/blog/2013/2/11/at-scale-even-little-wins-pay-off-big-google-and-facebook-ex.html) -* [Google：驯服长时延的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) -* [黑客新闻](https://news.ycombinator.com/item?id=5365096)的原始文章 -* [发生了什么](http://jmoiron.net/blog/whats-going-on/)-现代语言中的 Hash 成瘾探索 -* [分析 Go 程序](http://blog.golang.org/2011/06/profiling-go-programs.html) - -为什么去？ 为什么不选择 Erlang？ - -Go 与这个故事无关。 根本原因是 Ruby。 当 Ruby 消失并被任何工业语言（可能是 Java，C＃或任何经过验证的语言）取代时，问题也就消失了。 - -对于那些决定迁移到 Go 的用户，有[高度优化的库用于进程内缓存](https://github.com/valyala/ybc/tree/master/bindings/go/ybc)，[快速 Memcache 客户端库](https://github.com/valyala/ybc/tree/master/libs/go/memcache)和[为 SSD](https://github.com/valyala/ybc/tree/master/apps/go/memcached) 优化的 Memcache 服务器，全部以 走 ：） - -仍然不知道您的问题是来自红宝石还是铁轨 - -为什么不使用 Python？ - -Waaat？ 从解释代码移至编译代码，并且性能得到改善？！ 这些“工程师”一定是天才！！！ - -它们从 30 台服务器减少到 2 台服务器，这一事实证明了 Ruby 最初的选择是多么的糟糕。 但是现在他们正在转向 Go-一种更加晦涩的语言？ 这使我怀疑他们是否考虑了客户的需求，或者他们是否只是想炫耀自己在最新技术方面的优势。 \ No newline at end of file +jpj，完全是。 :) \ No newline at end of file diff --git a/docs/135.md b/docs/135.md index 6bfc17b..7130f03 100644 --- a/docs/135.md +++ b/docs/135.md @@ -1,31 +1,149 @@ -# SongPop 在 GAE 上可扩展至 100 万活跃用户，表明 PaaS 未通过 +# AOL.com 体系结构如何发展到 99.999％的可用性，每天 800 万的访问者和每秒 200,000 个请求 -> 原文： [http://highscalability.com/blog/2013/2/25/songpop-scales-to-1-million-active-users-on-gae-showing-paas.html](http://highscalability.com/blog/2013/2/25/songpop-scales-to-1-million-active-users-on-gae-showing-paas.html) +> 原文： [http://highscalability.com/blog/2014/2/17/how-the-aolcom-architecture-evolved-to-99999-availability-8.html](http://highscalability.com/blog/2014/2/17/how-the-aolcom-architecture-evolved-to-99999-availability-8.html) -![](img/4831f5897791fb0ce4c74a47a1d343de.png) +![](img/fcdd630ddc84ef7497d6c5ee8be15365.png) -您应该在下一个项目中使用 PaaS 吗？ 通常，答案是“否”，因为您想要控制，但这是 [SongPop](http://www.songpop.fm/) 中的一个示例，显示了为什么 PaaS 的承诺没有通过。 SongPop 能够自动扩展到 6000 万用户，100 万每日活跃用户，每天在全球范围内提供 17 TB 的歌曲和图像，每秒处理 10k +次查询，所有这些都由 6 人的工程团队组成，并且只有一名工程师全职工作 后端。 +*这是 AOL 的 [Dave Hagler](http://www.linkedin.com/in/hagler) 系统架构师的特邀帖子。* -不幸的是，这里并没有很多细节，但是可以在[通过 App Engine 和 Google Cloud Storage](http://googleappengine.blogspot.com/2013/02/scaling-songpop-to-60-million-users.html) 将 SongPop 扩展到 6000 万用户中找到。 大纲遵循脚本。 你从小开始。 让 PaaS 做繁重的工作。 而当您需要扩展时，您只需购买更多资源并进行一些调整（也许很多）。 收获是，您可以专注于功能开发，并且可以与一个小型团队合作。 +AOL 主页每天收到超过 **800 万名访客**。 与《美国早安》或电视上的《今日秀》相比，每天的观看者更多。 每月提供的网页浏览量超过十亿。 自 1996 年以来，AOL.com 一直是主要的互联网目的地，并且仍然拥有大量忠实用户。 -这是他们的体系结构图： +**AOL.com 的架构是第 5 代**。 在过去的 20 年中，它已经从头开始进行了 5 次重建。 当前的体系结构是 6 年前设计的。 零件已升级，并在此过程中添加了新组件，但总体设计仍保持完整。 经过 6 年的持续改进，对代码，工具，开发和部署过程进行了高度调整，使 AOL.com 体系结构经过了测试，并且非常稳定。 -![](img/1ab5b01808e0961190f9d2178e03350f.png) +工程团队由开发人员，测试人员和运营人员组成，**总共约有 25 人**。 大多数人在弗吉尼亚州的杜勒斯，在爱尔兰的都柏林有一个较小的团队。 -一些经验教训： +通常，使用的技术是 **Java，JavaServer Pages，Tomcat，Apache，CentOS，Git，Jenkins，Selenium 和 jQuery** 。 在该堆栈之外还使用了其他一些技术，但是这些是主要组件。 -* **首要支持。** 这听起来有点像销售推销，但是一旦他们的每日活跃用户达到 10 万，他们就开设了“高级支持”帐户，从而使他们可以与现实生活中的人交谈并快速解决停机问题。 -* **使**归一化。 为了减少就绪延迟，他们将跨多个模型散布的数据收集到一个实体中。 老歌，但仍然是一个巨大的胜利。 -* **缓存**。 为了减少查询，将用户的反对者列表缓存到 memcache 中，这是 GAE 的功能。 这个和非规范化更改花费了一名工程师 4 天的时间。 -* **截止日期**。 一旦操作的性能超过阈值，就该回落到另一个更可预测的策略了。 -* **综合索引**。 查询速度很慢，其原因可追溯到正在使用的许多索引属性。 解决方案是使用复合索引或将数据合并到单个实体中。 借助 Premier Support 的帮助可以追溯到此问题，Premier Support 也显示了 PaaS 的弱点，程序员不应该找到这些问题吗？ 也许查询日志很慢？ -* **易于与其他服务**集成。 亚马逊和谷歌等公司的一个优势是，他们可以创建功能强大的协作服务套件。 由于 SongPop 需要每天在世界范围内消费和分发 17 TB 的歌曲和图像，因此他们发现 Google Cloud Storage 价格合理，并且可以从 GAE 轻松使用。 而且，当您想做一些 BigData 时，已经内置了 Google BigQuery。 设计要点。 -* **位置标头**。 GAE 请求会自动包含标头，这些标头包含基于客户端请求的 IP 地址的位置信息。 SongPop 使用此信息选择对手并建立个人资料。 -* **同步模拟游戏。** Song Pop 使用的一种有意义的策略是[同步模拟游戏](http://uncrunched.com/2012/06/22/980/)。 可扩展的，一致的，低延迟的游戏很难，那么为什么要那么做呢？ SongPop 所做的是录制游戏，然后在您玩游戏时与您对战。 您似乎是在和一个真实的人比赛，但是没有一个讨厌的工程挑战。 您只需要存储声音片段和游戏结果，将玩家匹配到游戏，然后答复游戏即可。 相当聪明。 +## 设计原则 -显然，这是您的标准 Facebook 风格游戏，因此它不是复杂的应用程序，但将其包含在体系结构决策矩阵中是一个很好的存在证明。 +有一些重要的总体原则可以驱动体系结构。 首先，所有都有**冗余。 即使出现故障或需要维修时，仍然存在冗余。 要求有 5 个 9 的可用性，每年大约需要 5 分钟的停机时间。** -## 相关架构 +第二个原则是 AOL.com **不应依赖任何共享基础结构**来传递其页面。 如果其他 AOL 属性或系统出现故障，则 AOL.com 需要保持正常运行。 一段历史：在开发此体系结构时，大多数 AOL Web 属性只有一个共享的基础架构，称为 Big Bowl，这是一个反复出现的问题，其中一个属性会影响其他属性。 结果，当前的 AOL.com 专门设计为通过隔离自身来解决此问题。 对 AOL.com 的任何依赖都以保护服务为前提，该保护服务将对下游系统的调用集中在较小的服务器上。 下游系统没有从数千个服务器接收请求，而是从大约 20 个不同的服务器获得呼叫。 并且响应被缓存以进一步防止不堪重负。 此外，外部数据库被复制以提供给 AOL.com 自己的副本，并由其自己的运营团队进行管理。 关于唯一共享的组件是网络和身份验证服务。 -* [通过 App Engine 和 Google Cloud Storage 将 SongPop 扩展到 6000 万用户](http://googleappengine.blogspot.com/2013/02/scaling-songpop-to-60-million-users.html) -* [Song Pop 每天吸引 200 万活跃用户，其中许多人可能在调情](http://techcrunch.com/2012/07/03/song-pop/) \ No newline at end of file +另一个原理是**缓存用于优化性能，但不是系统以**规模运行的要求。 该基础结构的大小可在不进行缓存的情况下承受全部流量，同时仍可确保足够的冗余度以容忍中断。 缓存是一种奖励，但不是必需的。 + +## 物理基础架构 + +在 3 个数据中心中为 AOL.com 服务。 其中两个位于北弗吉尼亚州，一个位于加利福尼亚州，均由 AOL 拥有和运营。 所有 3 个数据中心都在积极地为流量提供服务，但是每个数据中心的大小都使其能够自行处理全部流量。 这样可以使一个数据中心脱机以进行维护，并且在发生故障的情况下仍具有冗余数据中心。 + +收到请求后， **Akamai GSLB 处理整个数据中心**的负载平衡，并将用户定向到最近的一个。 Akamai CDN 用于静态内容。 一旦进入数据中心，对服务或数据库的任何进一步请求将保留在该数据中心内。 用户会话信息保存在 cookie 中，并在请求中传递，因此任何服务器都可以为任何请求提供服务而不会保留任何状态。 + +![](img/405b9912b048be40b59c33cdc6de1e1b.png) + +在每个数据中心内，Netscaler 设备接收**请求并将其负载均衡到许多前端应用程序服务器**之一。 所有数据中心大约有 **700 个前端服务器。 前端是虚拟服务器，操作员可以根据需要通过扩展其他服务器来快速增加容量。 前端的虚拟主机分别配置有 2 个虚拟 CPU，4GB RAM 和 80GB 磁盘空间。 每个前端服务器都运行 Apache 和 Tomcat 的单个实例。 Apache 将请求传递给在本地主机上运行的 Tomcat。 **Tomcat 处理大量请求**，调用数据库和服务，并执行所有应用程序逻辑。** + +## 流量 + +AOL.com 的访问量出人意料地可预测，遵循与互联网使用情况类似的模式。 重大世界事件将导致峰值，但否则模式将非常一致。 + +每天的流量从凌晨 3 点到 6 点是最低的，直到上午 10 点才急剧增加，**大约以 200,000 次点击/秒的速度徘徊 7 小时**，然后在下午 5 点之后开始下降。 每天重复相同的周期。 + +![](img/2d8a3b3966866cfb64f4511c53152938.png) + +在工作日中，到 AOL.com 的流量比周末高。 每周中没有一个特定的工作日始终高于其他工作日。 换句话说，星期一与星期二或星期五没有什么不同。 但是周末总是比工作日低。 + +![](img/8b1027eb76bddcc988a96f30d2290e3c.png) + +流量分布在 3 个数据中心的 2,000 台前端服务器中。 东海岸的两个数据中心分别接收约 40％的流量**，而 20％的流量到达西海岸**。 分布不均是因为 Akamai 将用户路由到最近的数据中心，并且在美国东部地区有更多的最终用户。 此外，流向国际站点 aol.ca，aol.co.uk，aol.fr，aol.de 的流量都流向美国的东海岸数据中心。 + +## 监控 + +AOL 数据中心（包括 AOL.com）中运行的所有应用程序均由自主开发的工具监视**，该工具已开发了多年，其功能类似于 Amazon 的 CloudWatch。 硬件和软件指标可以实时收集和汇总。 客户端应用程序提供报告，图形和仪表板。 提供了主机，CPU，接口，网络设备，文件系统，Web 流量，响应代码，响应时间，应用程序度量标准和其他信息。 每分钟检查一次服务器端点，并在未达到可用性和响应时间的某些阈值时发出警报。** + +![](img/170b823bf1899c1b28782495f8d38030.png) + +## 内容管理系统 + +AOL.com 的大部分内容以及很多业务逻辑都来自**内容管理系统**。 CMS 是基于相同的 **Java / JSP 技术堆栈**构建的本地应用程序。 它具有除典型 CMS 之外的许多功能。 编辑者使用它来创建您在 AOL.com 上看到的内容。 开发人员使用它来配置应用程序。 它还是一个指标仪表板，供编辑人员提供有关页面上每个内容的性能如何的实时数据。 + +AOL 主页不仅仅是一个页面，而且位于单个域 www.aol.com。 它实际上由相同内容的数十个不同版本组成，它们在不同的域上，可能有许多可见或细微的差异。 CMS 允许在一个地方对主页的这些不同版本进行编程，并从层次结构中的多个父级继承特定版本的内容。 版本之间的差异可以很简单，例如页面上的不同品牌徽标，不同的跟踪 ID，或者某些或全部内容可以完全不同。 例如，用作美国主页（www.aol.com）的 AOL.com 版本可能与加拿大版本（aol.ca）不同，而加拿大版本可能与移动版本（m.aol。）不同。 com）。 还有供合作伙伴使用的品牌版本，例如 Verizon 的移动门户。 + +![](img/3b81271e9d2c67779494b4317543f820.png) + +这样，**内容会滴入**，从而消除了对大量手动复制内容的需要。 以仅与美国站点相关的突发新闻事件为例。 编辑人员将在“美国”部分对突发新闻进行编程，并将其编入所有从美国继承的网站。 如果由于某种原因突发新闻仅针对 Verizon 门户，则编辑者可以在该级别进行编程，并将其下放到各个 Verizon 站点。 + +在将 **推广给更广泛的受众**之前，我们**测试每个功能以查看其性能。 为了方便测试，CMS 中内置了一个多变量测试工具，该工具允许任意数量的测试单元并行运行。 我们会不断测试不同的内容和设计元素，以优化体验。 定义为访问量百分比的测试受众将获得该网站的其他版本。 将用户随机放入测试单元中，并使用浏览器 cookie 进行跟踪。 测试可能是按钮颜色的微小外观变化，可能是内容的不同布局，也可能是完全不同的体验。 在应用结果之前，测试通常会运行数周。** + +## 数据库 + +AOL.com 上的内容是高度动态的，并且需要访问数据库并为每个页面视图应用规则。 除了您在页面上看到的标记外，CMS 还包含许多规则和条件内容。 例如，如果您使用的是较旧的浏览器，则可能在页面顶部看到“浏览器升级”标语。 因此，CMS 数据库需要快速，能够处理极端流量突发并且始终可用。 我们正在运行 **MySQL 5** ，并且与虚拟化的前端服务器不同，**数据库服务器更大，具有 16 个 CPU 和额外磁盘空间的物理主机**。 + +CMS 数据库有 **30 个从属副本，每个数据中心**中有 10 个。 单个主服务器位于其中一个数据中心，而备用主服务器位于同一数据中心中，以防发生故障。 除了主服务器和从属服务器之外，每个数据中心中都有一个与主服务器进行复制的中继器，并且该中继器在其数据中心中充当从属服务器的主服务器。 中继器的目的是减少跨数据中心的复制流量。 发生故障时，每个数据中心中都有一个备用转发器。 如果主主机及其备份发生故障，则将其中一个转发器指定为新主机。 + +应用程序**通过 HTTP 接口**访问数据库。 AOL 开发了一个 apache 模块，用作 MySQL 的接口。 每个数据库主机上都有一个安装有模块的 Web 服务器。 管理员管理与其数据库的连接池，将 sql 查询作为 GET 请求，然后以 XML 格式返回结果。 对于 AOL.com 之类的 Java 应用程序，有一个 Java 客户端库可将 HTTP 调用和 XML 解析抽象为类型化的对象。 + +HTTP 数据库接口有多个原因。 首先，它使客户端的数据库访问更加简单。 任何使用任何编程语言的应用程序都可以进行 HTTP 调用，而无需担心 MySQL 客户端驱动程序或连接池。 其次，扩展应用程序也很容易。 应用程序通过单个 URL（指向负载均衡器虚拟 IP 地址的 URL）访问数据库。 添加新的从属服务器后，客户端应用程序无需将其添加到其配置中。 HTTP 接口的另一个好处是用于监视。 标准的 Web 服务器访问日志和监视工具可以提供数据库事务量，查询响应时间和错误。 整个 SQL 查询都作为参数包含在 URL 中，因此可以轻松地在日志中使用。 apache 模块中还内置了一个管理界面，可以从任何 Web 浏览器获取数据库诊断信息。 + +## 缓存 + +在体系结构中，有几个区域使用了缓存。 CMS 中有**个二级缓存。 首先，访问数据的 CMS Java 代码利用内存缓存。 由于**的内容在 CMS 中的每个内容都是**版本，并且从未更新过，而是一个新版本，因此可以轻松地缓存数据以减少对数据库的查找。 这种类型的缓存位于 Tomcat 实例级别，每个 700 个实例均保留其自己的缓存。** + +但是仍然需要为每个页面加载检查数据库，以查看是否有新的内容修订版。 这会转化为许多数据库查询，通常结果相同。 由于我们的数据库查询全部由 HTTP 接口通过前面描述的 apache mod 代理，因此我们可以使用 Varnish Cache 轻松地**缓存请求。 数据库查询是简单的 HTTP GET 请求，URL 中带有完整的 SQL 查询，因此 Varnish 可以很好地工作，从而大大减少了到数据库服务器的流量。** + +**Akamai CDN 用于缓存所有静态资产**。 除了静态资产缓存之外，Akamai 还每隔几分钟就会缓存一个精简的 AOL.com 静态版本。 当所有数据中心均无法访问时，这是灾难情况下很少使用的后备。 用户将直接从 Akamai 获取缓存的页面，直到实际页面重新联机。 + +缓存的最终区域在 AOL.com **前端 JSP 代码**中。 前端的工作是从 CMS 收集大量的小片段内容，并将它们组装成 HTML 页面。 我们开发了一个 JSP 标记库，使开发人员可以在页面上缓存任何组合的 HTML 块。 例如，要指定要缓存的页面部分，请用< cache：cache > < / cache：cache >包围它。 + +![](img/f88580f3eef6b3cc4afdcf5a59615af9.png) + +## 开发流程 + +对于需要更改编码的主要功能，开发团队会松懈地遵循 **Scrum 流程**。 冲刺通常需要 3 到 4 周，具体取决于业务承诺。 有时，可能同时处理多个 Sprint，例如某个功能需要花费 4 个多星期的开发时间。 + +仅通过 CMS 发布即可完成许多**网站更改，而无需构建或代码部署过程。 这些是经常发生的事件，它们作为非周期过程处理，请求通过电子邮件列表发送给团队。 这些更改全天部署，每天变化范围从几到十几个或更多。 这些更改的周转时间为几分钟到几天。** + +开发**小组每周轮换一个 iPhone，以作为应用程序随时待命**。 触发应用程序级别监视时，应用程序呼叫会收到警报。 例如，来自下游系统的数据可能已停止流动。 对于最终用户而言，这不会造成明显的问题，因为在这种情况下会有冗余和适度的后备，但是它会在问题变得严重之前主动发出警告。 除了应用程序待命之外，运营团队还可以待命以解决网络，主机和数据库问题。 有明确定义的上报途径和团队来处理任何情况。 + +开发人员**在其本地环境**中工作。 大多数使用 Macbook Pro 笔记本电脑和 Netbeans 或 Eclipse。 在开发过程中使用了 6 种非生产环境。 所有环境都与生产环境匹配相同的配置，但规模较小。 有 2 个 Dev Integration，4 个 QA 和 1 个 Staging 环境。 多个 QA 环境对于同时支持 2 个 sprint 以及必要时的生产修复都必不可少。 通常，在任何给定时间仅使用 1 或 2 个 QA 环境。 国际版本也有单独的 Dev，QA 和 Staging，它们分别运行同一代码库的单独实例来服务 aol.co.uk，aol.fr 和 aol.de。 + +在安装新代码之前， **QA 流程相当严格**。 这些年来，已经建立了许多回归测试，不仅有大量的自动化测试，而且还有许多手动测试。 硒用于自动化测试。 有一个自定义的屏幕截图工具，可以快速捕获各种浏览器/操作系统组合中的页面外观。 与典型的网站相比，AOL 使用较旧系统的用户更多，而我们的回归测试套件则包括 IE7，AOL 桌面浏览器以及模拟缓慢的 Internet 连接。 我们还测试了浏览器/操作系统/设备组合的广泛矩阵。 在装有 Windows 7 的 IE9 上看起来有些不错，但在装有 Windows XP 的 IE9 上却坏了。 它增加了很多额外的时间来对浏览器和操作系统的所有排列进行站点回归测试，但是事实证明，多年来，它是必要的。 Windows XP 和旧版 IE 构成了最大的问题。 AOL.com 倾向于在这些较旧的系统上吸引更多用户，因此我们会更加注意它。 + +完整的安装过程从开始到结束大约需要 2 个小时，整个开发团队都在听电话会议。 当流量最低时，安装通常在美国东部时间上午 6 点完成。 在安装过程中，站点或 CMS 不会停机。 即使大多数安装步骤都是脚本化的，但每个步骤都由操作员单独运行并在执行过程中进行验证。 在生产安装的前一天，在登台环境中练习了整个安装过程和脚本。 备份数据库后，将部署并验证各种组件。 + +更新网站的一个挑战是 CDN 交付的 CSS，图像和 Javascript 会缓存在浏览器中。 这样，用户可能会遇到糟糕的体验，直到缓存的元素过期为止。 我们遵循消除此问题的过程。 首先，将新的**静态内容推送到新版本路径**下的 CDN，从而使旧资产和新资产均可用。 接下来，将生产环境中运行的旧代码配置为指向新资产。 为了使它起作用，我们确保所有静态内容都向后兼容。 一旦有新资产可用，就将新代码部署到前端 Tomcat 服务器。 对于每台服务器安装，Apache 都会停止运行，这会告诉负载平衡器停止旋转并停止发送流量。 然后停止 Tomcat，安装新代码，重新启动 Tomcat，最后重新启动 Apache，这触发负载均衡器开始发送流量。 **使用 AOL 基于 RPM 软件包**定制开发的部署系统，通常需要 20 到 30 分钟才能在所有数据中心（总共超过 2000 台服务器）中部署新代码。 + +## 来回回顾 + +AOL.com 的技术堆栈已经成熟并且运行良好。 就像任何使用 6 年以上的系统一样，如果我们今天才开始，我们可能不会做出相同的选择。 Java / Tomcat / JSP 已被 Web 应用程序的 Python 和 PHP 取代。 Nginx 的性能可能优于 Apache，并且出现了 NoSQL 数据库。 许多这些技术已在 AOL 的其他领域中使用。 这是成功软件系统的经典难题。 相同的健壮功能使当今的体系结构如此灵活和可靠，这使得利用新技术变得困难。 + +但是我们在此过程中做出了一些有影响力的更改。 仅举几个例子，包括从物理主机到虚拟主机的转换。 添加清漆缓存； 并将 Jenkins 引入构建过程。 我们正在对前端 HTML 和 CSS 进行完全重写，以清理大量旧代码并促进响应性设计，而这几年前还没有考虑过。 我们的道路仍然是发展体系结构，在合理的时候重建零件并适应行业不断变化的需求。 + +感谢您提供非常有趣的信息:-) + +我感觉合理。 简单，无聊且有效。 同样，虽然有人将 Java 称为新的 COBOL，但这并不总是一件坏事-许多语言设计使其能够很好地处理 5 年未修改的代码的维护工作，这对于像这样的大型项目来说是一个重大问题。 + +即使它是免费的，在系统重写后，任何问题所涉及的风险似乎也超过了任何财务收益。 + +像将其作为寻呼机一样旋转物理 iPhone 似乎有些愚蠢。 也许你们可能想研究一下 PagerDuty 这样的更好的解决方案。 + +做得好！ + +确实很有趣，有很多好处。 我真的很喜欢这篇文章。 谢谢戴夫。 + +鉴于该站点全天仅执行 8 毫米操作，因此每秒 200k 次的命中率似乎太高了。 在这段时间内，按照 200k /秒的文章进行 8 个小时的数学运算，将获得 84MM 的点击。 所以有些事了。 + +@EJ-200,000 次命中/秒是对前端服务器的所有请求。 对该页面的访问会产生许多服务器调用，因为在后台还会发生其他 ajax 调用。 另外，其他 AOL 属性正在使用 api，这些 api 会导致访问前端服务器的流量，但不会注册用户访问。 + +@ EJ 每天有 800 万访客，相对于每秒 20 万页面请求。 它没有详细介绍每个用户获得多少页面请求。 + +戴夫，感谢您花费时间和精力来教育我们所有人。 您参与设计的过程令人印象深刻，您的雇主也允许您提高人们的数字敏感性，这也说明了他们的数量。 + +嗨，戴夫， + +我希望您能透露更多有关您如何授权用户的信息。 您正在使用 cookie，并且有一些身份验证服务。 是否在每个请求（如果适用）上调用这些服务？ 解决方案是自家生产的吗？ + +我知道这个主题有点...嗯...很敏感，所以我会尽我所能。 + +谢谢 + +数据库设计更引人入胜。 有人知道我们是否也可以采用类似的设计进行交易处理吗？ + +很棒的文章，非常感谢。 +一件特别的事引起了我的注意，因为我们一直都在努力解决它： +“对于每台服务器安装，Apache 都停止了，这告诉负载均衡器使其停止旋转并停止发送流量。” + +为了将其从负载均衡器池中删除，Apache 实际上是否已停止运行？ 还是为了在停止 Apache 之前将其删除而做些什么？ +显然，仅停止 Apache，将导致所有活动用户断开连接。 +除非使用“平稳停止”？ + +Thanks \ No newline at end of file diff --git a/docs/136.md b/docs/136.md index e25206f..1036047 100644 --- a/docs/136.md +++ b/docs/136.md @@ -1,262 +1,532 @@ -# DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长 +# Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构 -> 原文： [http://highscalability.com/blog/2013/1/28/duckduckgo-architecture-1-million-deep-searches-a-day-and-gr.html](http://highscalability.com/blog/2013/1/28/duckduckgo-architecture-1-million-deep-searches-a-day-and-gr.html) +> 原文： [http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) -![](img/0fc8c666278eef1071727bcc17340365.png) *这是对 [Gabriel Weinberg](https://twitter.com/yegg) ， [Duck Duck Go](https://duckduckgo.com/) 的创建者和一般[的创始人的访谈，内容涉及创业大师](http://www.gabrielweinberg.com/blog/)，关于 DDG 的架构是什么样的 在 2012 年。* +![](img/fb94c22e828546d379d859ae77268cf7.png) -创新的搜索引擎新贵 DuckDuckGo 在 2012 年 2 月获得了 [3000 万次搜索](https://duckduckgo.com/traffic.html) ，平均每天超过 100 万次搜索。 [超级投资者 Fred Wilson](http://www.avc.com/a_vc/2012/02/duck-duck-go-passed-1mm-searches-per-day.html) 将其定位为干净，私有，公正且快速的搜索引擎。 与加布里埃尔交谈之后，我喜欢弗雷德·威尔逊（Fred Wilson）先前所说的话，这似乎更接近问题的核心： [我们为 Reddit，Hacker News 无政府主义者](http://venturebeat.com/2012/05/21/fred-wilson-duckduckgo-reddit-hacker-news/) 投资了 DuckDuckGo。 +[Rick Reed](http://www.linkedin.com/pub/rick-reed/2/186/427) 在 3 月即将举行的演讲中，标题为 [，即“十亿”和“ B”：在 WhatsApp 上扩展到新的水平](http://lanyrd.com/2014/erlangfactory/scwqrt/) 令人眼前一亮 [WhatsApp](http://en.wikipedia.org/wiki/WhatsApp) 统计信息： -选择 DuckDuckGo 不仅可以视为一项技术选择，而且可以视为一场革命的投票。 在这个时代，您知道自己的本质不关乎爱情或友谊，而是更有效地将您卖给广告商，因此 DDG 将自己定位为 [不追踪替代方案](http://whatisdnt.com/) ， [隐私标记](https://duckduckgo.com/privacy)。 当然，您仍然可以通过获利来获利，但方式会更加文明和匿名。 +> 拥有数百个节点，数千个内核，数百 TB 的 RAM 的东西，并希望为不久将在全球范围内成为现实的数十亿智能手机提供服务？ WhatsApp 上基于 Erlang / FreeBSD 的服务器基础结构。 在满足对消息传递服务不断增长的需求方面，我们面临着许多挑战，但是随着我们不断扩大服务范围（> 8000 核）和速度（>每秒 70M Erlang 消息）， 系统。 -推进隐私权是一种与 Google 等人竞争的利基市场的好方法，因为从定义上讲，他们永远无法在隐私权上竞争。 我明白了。 但是我发现最引人注目的是 DDG 的强大愿景，即将一群垂直数据供应商捆绑到他们的搜索框架中，从而使众包插件网络提供更广泛的搜索范围。 例如，有一个专门的 Lego 插件，可针对完整的 Lego 数据库进行搜索。 例如，在您的搜索查询中使用香料的名称，然后 DDG 会识别出它的名称，并可能触发对高度调整的配方数据库的更深入的搜索。 每次搜索都可以触发许多不同的插件，这些插件都可以实时处理。 +但是由于我们还没有那个话题，让我们来看一下 Rick Reed 两年前在 WhatsApp 上的演讲： [扩展到数百万个同时连接](http://vimeo.com/44312354) 。 -无法搜索 Open Web 提供所有这些数据吗？ 不完全是。 这是具有语义的结构化数据。 不是 HTML 页面。 您需要一个能够对更丰富的数据集进行分类，映射，合并，过滤，确定优先级，搜索，格式化和消除歧义的搜索引擎，而关键字搜索无法做到这一点。 您需要 DDG 在其搜索引擎中内置的智能工具。 当然，现在的问题之一是，数据已经变得非常有价值，许多成年人不再愿意共享它们。 +在 Yahoo 期间，Rick Reed 用 C ++构建了高性能的消息总线，对于高可伸缩性体系结构并不是陌生的。 创始人也是前雅虎人，他们在缩放系统方面经验不多。 因此，WhatsApp 凭借其扩展能力诚实地表现出来。 而且由于他们的目标是在世界上每部智能手机上都拥有大毛毛的大胆目标，因此几年之内可能会增加 50 亿部手机，因此他们需要充分利用这种体验。 -获得广告支持会使 DDG 处于棘手的位置。 定向广告更有利可图，但具有讽刺意味的是，DDG 不跟踪政策意味着它们无法收集定向数据。 对于那些对隐私感兴趣的人来说，这也是一个卖点。 但是，由于搜索是出于意图驱动而著名的，因此 DDG 的对查询进行分类并将其与数据源进行匹配的技术已经成为一种高价值的定位方式。 +在我们弄清事实之前，让我们先讨论一下这个绝对迷人的难题：WhatsApp 对 Facebook 可能价值 190 亿美元？ -看到这些力量如何发挥作用将令人着迷。 现在，让我们看看 DuckDuckGo 如何实现他们的搜索引擎魔力... +作为一名程序员，如果您问我 WhatsApp 是否值那么多，我会回答否定！ 它只是通过网络发送内容。 变得真实。 但是我也是那个认为我们不需要博客平台的人，因为远程登录到您自己的服务器，用 vi 编辑 index.html 文件然后用 HTML 编写帖子有多难？ 我花了相当长的时间才意识到这不是愚蠢的代码，而是让所有这些用户都喜欢并使用您的产品才是最困难的部分。 您无法购买爱情 -## 信息源 +是什么让 WhatsApp 如此有价值？ 技术？ 忽略所有说可以使用 PHP 在一周内编写 WhatsApp 的人。 那根本不是真的。 就像我们将看到的很酷的技术一样。 但可以肯定的是，如果他们愿意的话，Facebook 有足够的能力来构建 WhatsApp。 -* 对 Gabriel Weinberg 的个人采访。 -* 在 **相关文章下列出的资源。** +让我们看一下功能。 我们知道 WhatsApp 是 [无头](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) （无广告，无头，无游戏）的产品，其忠实的 [用户 世界](http://www.wired.com/wiredenterprise/2014/02/whatsapp-rules-rest-world/) 。 它在残酷的 SMS 收费世界中提供免费短信。 作为一个庇护的美国人，最令我惊讶的是，有多少真实的人使用 WhatsApp 与家人和朋友保持联系。 因此，当您使用 WhatsApp 时，您认识的人很可能已经在使用它，因为每个人都拥有一部电话，从而缓解了空社交网络的问题。 它积极地跨平台运行，因此您认识的每个人都可以使用它，并且它将正常工作。 它“行之有效”是经常使用的短语。 它功能齐全（共享位置，视频，音频，图片，一键通，语音消息和照片，阅读回执，群组聊天，通过 WiFi 发送消息，并且无论收件人是否在线，都可以完成所有操作） 或不）。 它很好地处理了本地语言的显示。 使用您的手机号码作为身份并将您的联系人列表作为社交图表非常简单。 无需电子邮件验证，用户名和密码，也不需要信用卡号。 这样就可以了。 -## 统计资料 +令人印象深刻，但那不值 190 亿美元。 其他产品可以在功能上竞争。 -* 2012 年 2 月的 3 千万次搜寻 -* 每天平均超过一百万次搜索 -* 每天 12M API 请求 +[Google 想要](https://www.theinformation.com/Google-Was-Willing-to-Beat-Facebook-s-19-Billion-Offer-for-WhatsApp) 是可能的原因。 这是 [威胁](http://www.forbes.com/sites/parmyolson/2013/12/19/watch-out-facebook-whatsapp-climbs-past-400-million-active-users/) 的威胁。 费用为每位用户 0.99 美分。 Facebook 是 [绝望的](http://www.foxbusiness.com/technology/2014/02/21/facebook-buying-whatsapp-is-desperate-move/) 。 适用于 [您的电话簿](http://www.theregister.co.uk/2014/02/20/facebook_whatsapp_19bn_buy_also_45_for_your_phonebook/) 。 用于元数据（即使 WhatsApp 不保存任何元数据）。 + +适用于 [4.5 亿活跃用户](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) ，用户基础每天增长一百万，潜在的十亿用户。 Facebook 需要其下一个十亿用户使用 WhatApp。 当然，如果有的话，那一定是一部分。 每位用户约 40 美元的成本似乎并不合理，尤其是在大量库存支付的情况下。 Facebook 以 [每位用户 30 美元的价格收购了 Instagram](http://finance.fortune.cnn.com/2012/04/10/why-instagram-is-worth-1b-to-facebook/) 。 Twitter 用户为 [，价值$ 110](http://www.forbes.com/sites/georgeanders/2013/11/07/a-twitter-user-is-worth-110-facebooks-98-linkedins-93/) 。 + +本尼迪克特·埃文斯 [很好地证明了](https://www.youtube.com/watch?v=VnhbvS0MBXE) 移动业务是一个价值 1 万亿美元的业务，WhatsApp 正在扰乱该行业的 SMS 部分，全球范围内 全球短信系统每天仅发送 200 亿条短信，每天发送 180 亿条短信，从而实现超过 1000 亿美元的收入。 从 PC 到几乎普及的智能手机的过渡发生了根本变化，机遇的规模是一个比 Facebook 正常运营的市场更大的可寻址市场。 + +但是 Facebook 承诺不会投放广告，也不会出现干扰，那么胜利在哪里？ + +[商业使用移动](http://www.happymarketer.com/singapore-is-progressively-doing-business-over-whatsapp-are-you) 的有趣发展。 WhatsApp 用于为项目团队创建小组对话，风险投资家通过 WhatsApp 进行交易流程对话。 + +Instagram 用于科威特 [出售绵羊](http://storify.com/cbccommunity/kuwait-entrepreneurs-use-instagram-to-sell-sheep) 。 + +WhatsApp 的竞争对手微信在 1 月份推出了出租车出租车服务。 在第一个月， [接待了 2100 万辆出租车](http://www.techinasia.com/wechat-21-million-taxi-rides-booked/) 。 + +电子商务的未来似乎将通过移动消息传递应用程序进行传播，它一定是电子商务吗？ + +不仅仅是使用 WhatsApp 的企业曾经在台式机或网络上使用过这些应用程序。 西班牙的警务人员使用 WhatsApp 来抓捕罪犯。 意大利的人们使用它来组织篮球比赛。 + +出于显而易见的原因，商务和其他应用程序正在向移动设备转移。 每个人都拥有移动设备，这些消息传递应用程序功能强大，免费且使用便宜。 您不再需要桌面或 Web 应用程序即可完成工作。 许多功能可以叠加在消息传递应用程序上。 + +因此，消息传递对 Google 和 Facebook 构成了威胁。 桌面已死。 网络快要死了。 消息传递+移动是 [整个生态系统，它们避开了其渠道](https://news.ycombinator.com/item?id=7282876) 。 消息传递已经成为[在移动而不是搜索上的参与中心](http://cubed.fm/2014/02/cubed-episode-18-the-paradigm-shift-of-mobile-engagement-models/)，它改变了事物的发现方式以及改变应用程序将赢得未来的本质。 我们不仅是前网页排名，而且是网络前。 + +Facebook 是否需要进入这个市场或变得无关紧要？ + +随着移动技术的发展，我们看到了 Facebook 的无人化。 Facebook 的桌面 Web 界面是门户样式的界面，可访问后端提供的所有功能。 它很大，很复杂而且吱吱作响。 谁真正喜欢 Facebook UI？ + +当 Facebook 转向移动设备时，他们尝试了门户方法，但这种方法无效。 因此，他们采用的策略是更小，更集中，[专用的应用](http://www.theverge.com/2014/1/16/5269664/facebook-plans-suite-of-standalone-mobile-apps-for-2014)。 移动第一！ 在小屏幕上，您只能做很多事情。 在移动设备上，找到特殊的应用程序要比在复杂的门户风格的应用程序中找到深深的菜单要容易得多。 + +但是 Facebook 向前迈进了一步。 他们不仅在创建专用的应用程序，而且还在提供具有相似功能的多个竞争应用程序，而这些应用程序甚至可能没有共享后端基础架构。 我们通过 Messenger 和 WhatsApp，Instagram 和 Facebook 的照片应用程序看到了这一点。 Paper 是 Facebook 的备用界面，功能非常有限，但它做得很好。 + +康韦定律可能在这里适用。 “设计系统的组织受约束以产生作为这些组织的通信结构副本的设计”的想法。 借助整体后端基础架构，我们获得了类似于 Borg 的门户设计。 向移动的转变使组织摆脱了这种思维方式。 如果可以构建仅提供一部分 Facebook 基础结构视图的应用程序，则可以构建完全不使用 Facebook 基础结构的应用程序。 而且如果他们不需要 Facebook 的基础架构，那么它们完全可以免费完全不由 Facebook 构建。 那么，Facebook 到底是什么？ + +Facebook 首席执行官马克·扎克伯格（Mark Zuckerberg）有他自己的看法，他在移动世界大会 上的 [主旨演讲中说，Facebook 收购 WhatsApp 与该公司密切相关。 Internet.org 愿景：](http://techcrunch.com/2014/02/24/whatsapp-is-actually-worth-more-than-19b-says-facebooks-zuckerberg/) + +> 的想法是开发一组免费使用的基本互联网服务-“互联网 911”。这些服务可能是社交网络服务，例如 Facebook，消息服务，搜索或其他 像天气一样。向用户免费提供这些捆绑服务将像各种网关药物一样工作-那些如今可能能够负担数据服务和电话费用的用户根本看不出为什么要为这些数据付费 这将为他们提供为何重要的一些背景信息，这将使他们为此类更多的服务付费（或者希望如此） + +这是长距离比赛，这是一种游戏，拥有大量有价值的股票，您可以玩。 + +我们得出结论了吗？ 我不这么认为。 如此惊人的美元金额加上如此微弱的明显立即回报，以至于长期游戏的解释实际上确实是有道理的。 我们还处在移动的初期。 没有人知道未来会是什么样，所以不必费力强迫未来看起来像您的过去。 Facebook 似乎就是这样做的。 + +但是足够了。 仅 32 位工程师如何支持 4.5 亿活跃用户？ 让我们找出... + +## 来源 + +这里的警告是，我们对所有架构的 WhatsApp 知之甚少。 只是零零碎碎地从各种来源收集而来。 Rick Reed 的主要演讲是关于使用 Erlang 时使服务器达到 200 万连接的优化过程，这很有趣，但这不是完整的体系结构。 + +* [从 2012 年起缩放至数百万个同时连接](http://vimeo.com/44312354) （ [幻灯片](http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf) ），作者：瑞克·里德 + +* [Erlang Factory 对 Rick Reed 的采访](http://mirkobonadei.com/interview-with-rick-reed/)。 + +* [对来自 Erlang 的 WhatsApp](http://pdincau.wordpress.com/2013/03/27/an-interview-with-eugene-fooksman-erlang/) 的 Eugene Fooksman 的采访。 + +* [DLD14-WhatsApp 怎么了？ （Jan Koum，David Rowan）](http://www.youtube.com/watch?v=WgAtBTpm6Xk&feature=youtu.be) + +* [yowsup](https://github.com/tgalal/yowsup/wiki/Yowsup-Library-Documentation) 是 WhatsApp API 的开源版本。 由于 DMCA 移除，该存储库现在不可用[，但是它们确实记录了 WhatsApp 的一些内部工作原理。 万物的多样性。](http://openwhatsapp.org/blog/2014/02/13/mass-dmca-takedowns-whatsapp/) + +* 在 *相关文章下列出的一些来源。* + +## 统计信息 + +这些统计信息通常适用于当前系统，而不是我们正在讨论的系统。 当前系统的讨论将包括有关数据存储，消息传递，元集群以及更多 BEAM / OTP 补丁的黑客技巧。 + +* 4.5 亿活跃用户，并且达到这个数字的速度超过历史上任何其他公司。 + +* 32 位工程师，一名开发人员支持 1400 万活跃用户 + +* 每天在七个平台上（入站+出站）发送 500 亿条消息 + +* 每天有超过一百万的用户注册 + +* 为广告投入了$ 0 + +* 来自红杉资本的 6000 万美元[投资； 红杉将赚 34 亿美元](http://techcrunch.com/2011/04/08/sequoia-whatsapp-funding/) + +* 35％是 Facebook 现金中的[被用于交易](http://finance.fortune.cnn.com/2014/02/19/facebook-whatsapp-the-other-numbers/) + +* 数百个节点 + +* > 8000 色 + +* 数百兆字节的 RAM + +* >每秒 70M Erlang 消息 + +* 在 2011 年，WhatsApp 在具有内存和 CPU 的单台计算机上实现了 [100 万个已建立的 tcp 会话](http://blog.whatsapp.com/index.php/2011/09/one-million/) 。 在 2012 年，它被推翻了 [200 万 tcp 连接](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/) 。 2013 年，WhatsApp [发了推文](https://twitter.com/WhatsApp/status/286591302185938946) ：12 月 31 日，我们创下了新的记录天：入站 7B 消息，出站 11B 消息=一天处理的总消息量为 180 亿 ！ 2013 年快乐！！！ ## 平台 -* EC2 -* Ubuntu -* Perl & CPAN -* [服务器密度](http://www.serverdensity.com/) -监控 -* Solr -* PostgreSQL -* Memcached -* [Bucardo](http://bucardo.org/) -异步 PostgreSQL 复制系统 -* [全球流量管理器](http://www.dnsmadeeasy.com/services/global-traffic-director/) -区域之间的负载平衡 -* Nginx -* [getFavicon](http://getfavicon.appspot.com/) -提供收藏夹图标 -* [daemontools](http://en.wikipedia.org/wiki/Daemontools) -用于管理 Unix 服务的免费工具 -* 转到 -* [Asana](http://asana.com/) -项目管理。 -* HipChat-内部通讯 -* Yammer -* JavaScript -* YUI（移至 jQuery） - -## 内部内容 - -* Gabriel 喜欢他们的系统： - * 非常简单，尽管随着时间的推移它们变得越来越复杂。 一切都是模块化的，可以减轻复杂性。 Daemontools 用于保持服务运行，一切都通过 Nginx 运行。 有很多不同的服务，但是架构使它们都保持不变。 - * 主要目标是 100％的正常运行时间和速度。 降低复杂度有助于实现这两个目标。 - -## 走出地下室并进入 AWS（主要是） - -* DuckDuckGo 过去耗尽了加百利的地下室。 现在，大多数组件（包括所有前端组件）都在 AWS 上。 - * 一些“持久性机器”仍然存在于地下室，因为没有令人信服的理由来移动这些组件，例如 Git 存储库，爬网以及更新[零点击连接](http://dhruvbird.com/ddb/zc.html)的实时 Wikipedia 索引。 - * Linode 用于托管一些社区功能，例如翻译。 - * 作为迁移到 AWS 的一部分，从 FreeBSD 迁移到 Ubuntu。 -* 移动到多个区域以获得更好的前端性能。 使 DDG 遍地快速，用户将来。 - * 用户抱怨的一项是速度。 通过在 4 个 AWS 数据中心（加利福尼亚，弗吉尼亚，新加坡，爱尔兰）中运行，DDG 可以更接近其全球用户。 - * 相同的软件在所有数据中心中运行。 - * Global Traffic Director 用于其 DNS，并在区域之间平衡用户负载。 DDG 希望使用更多的区域（南美和另一个亚洲数据中心），但是 Traffic Director 目前仅在四个区域工作。 -* 由于 EBS 参与了大多数大型故障，因此完全退出了 EBS。 EBS 也经历了性能差异。 - * 本来应该可以使用新的 Provisioned IOP，但是在体系结构中具有较少的额外移动部件会更好。 - * 尽管当前的非 EBS 体系结构运行良好，但将来可能会尝试使用 PIOP。 -* 主要在超大型计算机上运行，​​因为它们似乎是网络高 IO 的最佳选择，并且它们具有 4 个临时磁盘。 - * 基准测试表明，超大型机器的性能差异最低。 - * 发现 4 个临时磁盘的性能比条带化 8 个 EBS 磁盘的性能要好。 - * 对高 IO 实例类型不感兴趣，因为目标是在内存中保留尽可能多的数据。 高事务处理率不是问题，并且数据将尽快缓存。 另外，机器的 IO 使用率也不高。 -* 中型实例用于开发人员计算机。 每个人都有自己的中等开发实例。 临时实例用于测试，足以模拟实际环境。 -* 数据中心同步。 - * 主要处理只读数据。 更新会一直发布，但不必立即发布。 意味着数据中心之间的同步不是数据中心问题。 确实没有任何一致性问题。 - * 后端系统（非 AWS）具有主数据库，可将更新推送到区域。 -* 分布式缓存系统使用 memcached。 - * 高内存 m2.xlarge 用于缓存。 - * 大小约为 100GB，在 m2.xlarge 机器上分片。 - * 缓存某些内容时，它将推送到所有其他缓存系统。 没有主人。 - * 自定义 Perl 解决方案。 - * 缓存是通过 Nginx 路由的，因此如果数据在缓存中，请求将完全绕过 Perl 后端。 - * 不受大小限制，它们可以根据需要添加任意数量的缓存计算机，挑战是弄清楚要放入缓存中的内容，这样将很有用，并且不会产生不良结果。 - * 研究更智能的缓存老化算法。 查看返回的有机链接。 您可以从其相关的代码片段和域中找到很多有关链接的信息。 问题在于此信号仅在结果返回后才可用，因此 UI 速度较慢，但​​对缓存非常有用。 - * 优先考虑的是在所有区域中正确同步。 现在，他们将致力于制作更智能的缓存。 -* 使用了许多数据库，包括 PostgreSQL，Solr，Berkeley 和平面文件。 - * Bucardo 用于 PostgreSQL 复制。 - * Solr 同步是通过自己的过程进行的，而不是内置的复制。 - * PostgreSQL 主服务器在地下室，而从服务器在每个区域。 - * PostgreSQL 保存即时答案和实体数据。 例如，如果您输入“ duckduckgo”，那么您会从 Wikipedia 中获得某些东西，而这是来自 PostgreSQL 的。 - * PostgreSQL 数据库有大约 100 个数据源。 这些由后端爬网并存储在数据库中。 - -## 搜寻-非常复杂 - -* 高级别：尝试弄清楚查询的含义，然后将其路由到适合该查询的适当数据存储区和 API。 在某些情况下，请将其带回，并行化并混合在一起。 -* 零点击实例答案框可以由 PostgreSQL，Solr，即时 API，平面文件或组合提供动力。 -* 链接结果是由 API 驱动的，尽管顶部链接可能来自其他来源。 [链接源包括](http://help.duckduckgo.com/customer/portal/articles/216399-sources) ：Bing，Yahoo，Yandex，Blekko，WolframAlpha 等。 -* 所有解析和合并逻辑都在 Perl 中。 -* 合并的两个级别：后端和客户端。 - * 在后端，将来自不同 API 的对链接结果的异步请求合并，然后再将其返回给客户端。 - * 在客户端上，向可能在不同计算机上的模块化组件发出了异步 JavaScript 请求。 包括广告请求，搜索结果，搜索建议。 由于它们具有不同的延迟，因此将它们保持分开。 - * 这些请求均独立缓存。 可以缓存的所有内容都会被缓存。 任何涉及外部请求的操作都可能很慢。 如果来自他们的数据存储区，Instant Answer 将很快返回。 - * 通过流水线化和缓存可以更快地发出请求。 - * 缓存服务器是按区域划分的，它们会尝试尽可能多地填充它们。 大大缩短了响应时间。 - * 目标缓存命中率为 50％。 目前为 30％。 问题是结果被缓存的时间长度。 结果会发生变化，因此，当您遇到突发新闻时，您不希望出现 5 天前的结果。 他们正在尝试提高 差异缓存 的性能，学习何时将某些内容缓存一周而不是更长或更短。 - * 搜索建议的缓存命中率更高，因为并非每次查询都出现，并且可以缓存更长的时间。 - * 广告未缓存。 供应商具有点击欺诈检测功能。 广告会留有空间，因此，当广告可用时，页面显示不会出现毛刺。 缓存有关搜索的内部指标，以便更好地呈现页面。 -* Nginx 仍然可以提供所有服务。 - * 由于出于隐私方面的考虑，他们不想在其域外拨打电话，因此所有路由和代理均通过其 Nginx 服务器进行路由。 最大的示例是 URL 的图标。 getFavicon 服务用于获取网站图标。 它们被缓存了大约一天，因此速度很快，因此搜索结果不会 [泄漏给提供者](http://www.gabrielweinberg.com/blog/2011/01/search-leakage-is-not-fud-google-et-al-please-fix-it.html) 。 - * Nginx 缓存由于错误而受到限制。 大小约为一档。 -* [DuckDuckHack](http://duckduckhack.com/) 是新的即时应答平台。 - * 4 种插件类型。 Fathead 类型（查询空间的胖头）是 PostgreSQL 存储，它实际上是关键字数据库。 - * 比赛不一定要完全击中。 它是定义，链接类别，消歧页面以及它们具有的许多其他功能的大数据存储。 - * 梦想是吸引更多的细分受众，以更好地为关心特定主题的人们提供服务。 例如：乐高零件。 例如，有一个乐高零件数据库。 零件图片和零件编号可以通过搜索自动显示。 - * 很难集成插件，因此尽管有很多需求，但采用速度比他们希望的慢。 仍在学习如何使其最佳发挥作用。 - * 对结果进行两个级别的过滤。 如果使用了严格的触发器，并且插件返回某些内容的可能性很高，那么结果的页面上将留有空间，并在结果返回时进行填充。 如果相关性很低并且结果经常被过滤掉，那么就不会再有空格了，因为页面上似乎有很大的空白。 涉及很多个案逻辑。 -* 引擎的核心正在决定如何将搜索路由到正确的后端组件。 - * 这个主题上有一个知识产权墙，但仍有许多细节。 - * 两种查询：长尾巴和胖尾巴。 粗尾查询针对 PostgreSQL，长尾查询针对 Solr。 对于较短的查询，PostgreSQL 优先。 长尾填补了“实例答案”的所有其他内容。 - * 不像其他搜索引擎那样以机器学习为中心。 启发式用于将查询空间划分为不同的部分，它们专注于那些特定的部分以找出如何最好地对其进行分类。 - * 示例：输入豆腐生姜。 香料插件会根据 DDG 认为这是食谱搜索的事实，即时获取结果。 DDG 与插件提供商合作，从其抓取中提取好成分关键字。 为它们的数据存储区构建了一个非常具体的分类器，它们在每个查询上运行。 - * 有时会触发多个类别，并且它们必须是优先顺序才能对结果进行排序。 会变得很复杂。 - * 一些分类器要简单得多。 插件接口支持关键字触发器，这相对简单。 比赛不一定是准确的。 例如，匹配可以在单词的开头或结尾。 它是哈希系统。 您查看所有单词并根据哈希进行匹配。 真快。 - * 正则表达式插件较慢。 尝试转换为哈希，或在其下使用带有正则表达式的更广泛的哈希。 - * 核心代码在插件执行之前运行，以进行分类。 像“豆腐”这样的单词查询更多地依赖于 the 头。 首先运行，其余所有短路。 - * 有很多情况，您很快就会陷入困境。 - * 诸如“ 60 分钟”之类的查询会产生歧义，这意味着它询问您是指哪个“ 60 分钟”，这是来自 PostgreSQL 的。 还触发了一个插件，可在节目实际播放时为您提供。 - * 存在用于调整插件的元语言。 例如，假设数据是否与此插件匹配，那么即使有另一个即时答案，数据也足以显示。 - * 赞助商链接被联合到 Microsoft Yahoo! 搜索联盟。 - * 在我们的示例查询页面中，“即时答案”框可能转到 PostgreSQL 和 Solr 数据库以及其他存储。 “ 60 分钟”部分，该部分实时进行服务，以使用 JavaScript API 提取数据。 - * Dream 要在 Instant Answers 中获得 80％的覆盖率，每个初创公司都将创建一个插件，以利用其专业的数据来改善搜索结果。收益是流量，因为即时答案甚至显示在广告上方。 并非所有信息都显示在框中。 预计点击率将达到 50％。 -* 搜索建议来自一个完全不同的本地组件。 - * 有些人对事物使用不同的单词。 目标不是重写查询，而是提供有关如何做得更好的建议。 - * 例如，“电话评论”将用电话代替电话。 这是通过 NLP 组件发生的，该组件试图弄清楚您的电话意思以及查询中是否应该使用任何同义词。 - * 希望探索更多此查询构建组件，但尚未找到最佳的 UI。 -* 许多盲人用户写有关可用性问题的文章。 由于信息隐藏在脚本中，因此很容易意外破坏可用性。 屏幕阅读器可能对呈现的内容感到困惑，因为需要适当的标题标签。 例如，很容易忘记放入 ALT 标签。 -* 目标是通过添加 1000 多个来源以提供所有内容的即时解答，以达到 80％的搜索覆盖率。 维基百科使您达到 20％。 添加更多的长尾巴，您最多可以得到 30％。 长长的尾巴表示它与任何内容都不完全匹配，但是 Wikipedia 中有一段与该问题完全匹配。 它不会直接打到 Wikipedia 主题，而是在 Wikipedia 中。 - * Google 收购了 MetaWeb 作为填写其知识图谱的手段。 - * Google 在页面右侧有更多信息，并显示更多信息。 DDG 将信息推到顶部，而信息却更少。 - * 何时显示即时答案的标准是，它们应该比链接要好得多。 在 DDG 右手边扔很多可能对某人感兴趣的东西。 -* 滤泡。 当您单击一个链接时，会显示更多类似该链接的链接。 您的点击和搜索历史记录将您锁定在过滤器气泡中。 您会看到越来越多的内容。 搜索和点击历史记录不用于定位结果。 过滤器气泡破裂。 他们可能会在将来提供此功能，但必须选择加入。 - -## 开发 - -* 团队处于 50％远程状态。 全职 10-15 人。 20 至 25 人是固定供款人。 有些人在兼职做非常具体的功能。 对他们来说很棒。 -* 用于源代码控制的 Git。 使用标签发布。 部署系统可以访问所有计算机并安装软件。 自插件启动以来，情况更加复杂。 -* 每个开发人员都有一个中等云实例。 -* Asana 用于项目管理。 -* HipChat 和 Yammer 用于内部通信 -* 前端开发使用很多底层 JavaScript。 从 YUI 迁移到 jQuery 的思考。 - -## 获利策略- [广告](http://help.duckduckgo.com/customer/portal/articles/216405-advertising) - -* 目标是避免混乱，因此请尽量减少广告。 如果广告有用，那么它们实际上可以改善结果。 -* 在广告定位更精准之前，不会有更多的广告。 这将需要更好的广告网络后端。 -* 搜索广告供稿不多，因此选择不多。 要在搜索空间中实际投放广告，您需要大量的广告客户。 可以将整个查询类别组合在一起，例如财务查询，但随后广告变得不那么相关了。 -* 考虑到与其他搜索引擎相比，广告商在 DDG 上投放广告系列的动机仍然很低。 -* 开放数据比以往任何时候都多，但是仍有一些数据被锁定并且无法通过插件获得：飞行，电影和体育。 有些公司对数据拥有垄断权，这就是他们的业务。 初创企业通常更愿意共享数据。 -* 搜索供应商没有要求使用特定的广告网络。 - -## 观众提问 - -* 延迟管理？ - * 可能时管道请求。 - * 受亚马逊网络的限制，但主要的事情是将事物分成不同的区域。 - * 使用异步。 - * 使用内存缓存。 - * 为 Nginx 评估 SPDY。 -* 最大的扩展挑战？ - * 没什么大不了的，主要是因为他们已经对架构进行了模块化。 拆下组件并放入其自己的堆栈很简单。 前端需求是单独完成的。 只需更改主机名，然后指向其他位置即可。 - * 降低必要的数据集复制的复杂度，并尝试使其尽可能保持只读。 -* 如果 Yahoo 和 Bing 关闭您会怎样？ - * 还有其他提供商，因此没有即时问题。 - * 总体而言，风险随着时间的推移而降低，因为 DDG 是这些公司的资产，因为 DDG 正在从 Google 手中抢占份额。 DDG 正在使用他们的广告网络。 - * 未被视为威胁，因此不太可能出现结果。 -* 您会赚足够的钱生存吗？ - * 不用担心！ - * 搜索广告可赚钱。 他们希望通过减少他们的 cr 脚，使他们更有利可图。 - * 他们的方法并没有那么昂贵。 他们不需要赚大笔的钱就可以继续营业。 -* 从长远来看，您如何计划与 Google 脱颖而出？ - * 专注于 Google 无法轻松复制的功能，并非出于技术原因，而是出于商业和文化原因。 - * 长尾答案功能。 - * 真正的隐私。 - * 缺乏混乱-链接结果不会因其他属性的插入而混乱，因此请保持干净。 - * 更积极地删除垃圾邮件。 Google 做得不好。 - * 即时答案在移动设备上很棒。 构建新的移动应用程序，但是移动设备在发行方面更具挑战性。 所谓分发，是指电话具有内置的搜索提供程序，这是使用阻力最小的途径。 即使使用非常出色的搜索应用，也很难吸引人们使用它们。 Siri 是使搜索难以使用的另一个示例。 - -## 获得的经验教训 - -* **保持简单** 。 他们没有大量的负载均衡器和许多子系统。 模块化组件，使其独立。 -* **用户关心性能** 。 通过复制到多个区域并包括一个缓存层，使其更接近用户，从而大大提高了性能。 -* **缓存只是故事的开始** 。 缓存后，您必须找出如何最好地构造缓存以及何时使数据过期。 保留数据的时间过长，用户将获得不良结果。 因此，必须将数据仔细分类为特定的缓存策略。 -* **只读架构很不错** 。 DDG 方法的强大功能是因为它们具有很大程度上只读的数据集。 -* [**众包插件**](http://idealab.talkingpointsmemo.com/2012/05/duckduckgo-wants-developers-to-hack-its-search-results.php) **获得更大的搜索范围是一个好主意**。 实时集成这么多数据源将是一个很大的挑战，但是拥有一个能够正确处理这么多种不同类型数据的搜索引擎的愿景真是太棒了。 希望世界不会破坏计划。 -* **使用这么多第三方服务是优势和劣势** 。 之所以有实力，是因为这些联盟使 DDG 能够访问比以往更多的数据。 就像一个较弱的国家与其他较弱的国家结盟，共同对抗一个较大的国家。 不利之处在于，由于信息源具有更高的延迟，必须将它们合并在一起以使一切看起来像一个统一的整体，因此使系统的设计更加困难。 -* **启发式工作** 。 您最终会遇到一个复杂的基于规则的体系结构，但是启发式方法可以让您微调所有不同搜索结果源之间的关系。 诀窍是获取查询并将其正确映射到所有插件。 与普通的机器学习方法相比，做得好是一个非常有价值的解决方案，当它碰上时会很棒，但是错过时会卡住。 -* **与巨人** 竞争时，您需要一个角度。 DDG 正在追求他们不希望 Google 复制的功能，并保持较低的成本，以便他们有能力继续获得更合理的收入。 -* **移动是挑战和机遇** 。 移动设备上的搜索引擎锁定使其难以竞争。 具有讽刺意味的是，“即时答案”是一项出色的移动功能，因为您无需分页浏览大量文本即可找到所需内容。 - -非常感谢 Gabriel Weinberg 抽出宝贵的时间进行采访。 他非常有耐心，对答案很开放。 我们花了很长时间，但我认为结果值得。 如果您有兴趣，DuckDuckGo 正在寻找移动开发人员。 +### 后端 + +* Erlang + +* FreeBSD + +* 偏航，lighttpd + +* PHP + +* 自定义补丁 [BEAM](http://www.erlang-factory.com/upload/presentations/708/HitchhikersTouroftheBEAM.pdf) （BEAM 类似于 Java 的 JVM，但适用于 Erlang） + +* 自定义 XMPP + +* 托管[可能位于软件层](http://www.ip-adress.com/whois/whatsapp.com) 中 + +### 前端 + +* 七个客户端平台：iPhone，Android，Blackberry，诺基亚 Symbian S60，诺基亚 S40，Windows Phone 、？ + +* SQLite + +### 硬件 + +* 面向用户的标准服务器： + + * Dual Westmere Hex-core（24 个逻辑 CPU）； + + * 100GB RAM，SSD； + + * 双网卡（公用面向用户的网络，专用后端/分发）； + +## 产品 + +* **重点是消息传递**。 不管人们身在何处，都可以联系世界各地的人们，而不必花很多钱。 创始人扬·库姆（Jan Koum）记得 1992 年与全世界的家人建立联系有多么困难。 + +* **隐私** 。 由扬·库姆（Jan Koum）在乌克兰度过的成长经历所塑造，那里没有什么私人物品。 消息不存储在服务器上； 聊天记录未存储； 目标是尽可能少地了解用户； 您的姓名和性别未知； 聊天记录仅在您的手机上。 + +## 常规 + +* WhatsApp 服务器几乎完全在 Erlang 中实现。 + + * 执行后端消息路由的服务器系统是在 Erlang 中完成的。 + + * 伟大的成就是，使用很小的服务器空间就可以管理活动用户的数量。 团队的共识是，这很大程度上是因为 Erlang。 + + * 值得一提的是 [Facebook 聊天室](http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)于 2009 年用 Erlang 编写，但由于很难找到合格的程序员，他们放弃了它。 + +* WhatsApp 服务器已从 ejabberd 启动 + + * Ejabberd 是用 Erlang 编写的著名开源 Jabber 服务器。 + + * 最初选择是因为它开放，受到开发人员的好评，易于启动以及 Erlang 对于大型通信系统的长期适用性的保证。 + + * 接下来的几年用于重写和修改 ejabberd 的相当多的部分，包括从 XMPP 切换到内部开发的协议，重组代码库和重新设计一些核心组件，并对 Erlang VM 进行很多重要的修改，以 优化服务器性能。 + +* 为了每天处理 500 亿条消息，重点是建立一个可靠的有效系统。 获利是一个值得关注的问题，它远未实现。 + +* 系统运行状况的主要衡量标准是消息队列长度。 节点上所有进程的消息队列长度将得到持续监控，如果它们积压的积压超过预设阈值，则会发出警报。 如果一个或多个进程落后，则会发出警报，这将提供指向下一个攻击瓶颈的指针。 + +* 通过上载图像，音频或视频以发送到 HTTP 服务器，然后发送指向内容的链接及其 Base64 编码缩略图（如果适用）来发送多媒体消息。 + +* 通常每天都会推送一些代码。 通常，一天要多次，但通常可以避免高峰时段。 Erlang 有助于积极地将修补程序和功能投入生产。 热加载意味着可以推送更新而无需重启或流量转移。 通常，再次通过热加载可以很快消除错误。 系统趋向于松散耦合，这使得很容易以增量方式推出更改。 + +* Whatsapp 应用程序使用什么协议？ WhatsApp 服务器池的 SSL 套接字。 所有消息都会在服务器上排队，直到客户端重新连接以检索消息为止。 消息的成功检索将发送回 whatsapp 服务器，该服务器将该状态转发回原始发件人（它将在消息旁边显示为“复选标记”图标）。 客户端接受消息后，就会从服务器内存中清除消息 + +* 在 Whatsapp 中，注册过程如何在内部进行？ WhatsApp 曾经根据电话 IMEI 号码创建用户名/密码。 最近更改了。 WhatsApp 现在使用应用程序的一般请求发送唯一的 5 位数 PIN 码。 然后，WhatsApp 将 SMS 发送到指定的电话号码（这意味着 WhatsApp 客户端不再需要在同一部电话上运行）。 然后，根据密码，该应用会向 WhatsApp 请求一个唯一的密钥。 该密钥用作将来所有呼叫的“密码”。 （此“永久”密钥存储在设备上）。 这也意味着注册新设备将使旧设备上的密钥无效。 + +* Android 上使用了 Google 的推送服务。 + +* Android 上的更多用户。 Android 更加令人愉快。 开发人员可以对功能进行原型设计，并在一夜之间将其推销给数亿用户，如果有问题可以迅速解决。 iOS，不是很多。 + +## 每服务器 2 百万个以上的连接 + +* 经历了很多用户增长，这是一个好问题，但这也意味着必须花钱购买更多的硬件，并增加管理所有这些计算机的操作复杂性。 + +* 需要针对流量增加进行规划。 例如足球比赛和西班牙或墨西哥的地震。 这些发生在高峰流量负载附近，因此需要有足够的备用容量来处理高峰和颠簸。 最近的一场足球比赛在每日高峰时出站邮件率激增了 35％。 + +* 初始服务器装入是每台服务器 200 个同时连接。 + + * 推断出来将意味着很多服务器都有望实现增长。 + + * 面对突发负载，服务器很脆弱。 网络故障和其他问题将会发生。 需要解耦组件，以免大容量情况下变脆。 + + * 目标是每服务器一百万个连接。 当它们以 200K 连接运行时，给出了一个宏伟的目标。 运行具有裕量的服务器以允许发生世界性事件，硬件故障以及其他类型的故障，将需要足够的弹性来处理高使用率水平和故障。 + +## 用于提高可伸缩性的工具和技术 + +* 编写了系统活动报告程序工具（wsar）： + + * 记录整个系统的系统统计信息，包括 OS 统计信息，硬件统计信息，BEAM 统计信息。 它是经过构建的，因此很容易从其他系统（例如虚拟内存）中插入指标。 跟踪 CPU 利用率，总体利用率，用户时间，系统时间，中断时间，上下文切换，系统调用，陷阱，已发送/已接收的数据包，所有进程中队列中消息的总数，繁忙的端口事件，流量速率，输入/输出字节 ，排程统计资料，垃圾收集统计资料，收集的字词等。 + + * 最初每分钟运行一次。 由于系统的驱动更加困难，因此需要一秒钟的轮询分辨率，因为如果一分钟内看不到该事件，则该事件将在空间中发生。 真正细粒度的统计数据，以查看一切运行情况。 + +* CPU 中的硬件性能计数器（pmcstat）： + + * 以时间百分比查看 CPU 的位置。 可以知道执行仿真器循环花费了多少时间。 在他们的情况下，这是 16％，告诉他们只有 16％的人在执行仿真代码，因此即使您能够删除所有 Erlang 代码的所有执行时间，也只能节省总运行时间的 16％。 这意味着您应该专注于其他领域以提高系统效率。 + +* dtrace，内核锁计数，fprof + + * Dtrace 主要用于调试，而不是性能。 + + * 在 FreeBSD 上修补了 BEAM 以包括 CPU 时间戳。 + + * 编写脚本以创建所有进程的汇总视图，以查看例程在所有时间上所花费的时间。 + + * 最大的获胜是在打开锁定计数的情况下编译模拟器。 + +* 一些问题： + + * 较早的时候，在垃圾回收例程上花费了更多时间，这被减少了。 + + * 看到已调离的网络堆栈有一些问题。 + + * 大多数问题与模拟器中的锁争用有关，这在锁计数的输出中表现出强烈的作用。 + +* 测量： + + * 合成工作负载（意味着从您自己的测试脚本生成流量）对于以极大规模调整面向用户的系统的价值很小。 + + * 非常适合简单的界面（例如用户表），可以尽快生成插入和读取。 + + * 如果要在一台服务器上支持一百万个连接，则将需要 30 台主机打开足够的 IP 端口以生成足够的连接来仅测试一台服务器。 对于 200 万台服务器，它将占用 60 个主机。 只是很难产生这种规模。 + + * 在生产期间看到的流量类型很难生成。 可以猜测正常的工作量，但是实际上可以看到网络事件，世界事件，因为多平台可以看到客户端之间行为的变化以及国家/地区的变化。 + + * Tee 的工作量： + + * 进行正常的生产流量并将其通过管道传输到单独的系统。 + + * 对于可能限制副作用的系统非常有用。 不想散布流量并做会影响用户永久状态或导致向用户发送多条消息的事情。 + + * Erlang 支持热加载，因此可以在完整的生产负载下运行，有一个想法，进行编译，在程序运行时加载更改并立即查看更改的好坏。 + + * 添加了旋钮以动态更改生产负载，并查看其如何影响性能。 将跟踪 sar 输出，以查看诸如 CPU 使用率，VM 使用率，侦听队列溢出以及转动旋钮以查看系统如何做出反应。 + + * 实际生产负荷： + + * 终极测试。 同时进行输入工作和输出工作。 + + * 将服务器放入 DNS 两次，这样它将获得正常流量的两倍或三倍。 由于客户端不遵守 DNS TTL 且存在延迟，因此造成了 TTL 问题，因此无法迅速做出反应以获取更多无法处理的流量。 + + * IPFW。 将流量从一台服务器转发到另一台服务器，这样可以为主机提供所需客户端连接的确切数量。 一个错误导致内核崩溃，因此无法很好地工作。 + +* 结果： + + * 开始于每个服务器 200K 个并发连接。 + + * 第一个瓶颈出现在 425K。 系统出现了很多争论。 工作停止了。 对调度程序进行检测，以衡量正在执行的工作，休眠或旋转的工作量。 在负载下，它开始达到休眠状态，因此整个系统使用了 35-45％的 CPU，但调度程序的利用率为 95％。 + + * 第一轮修复程序已超过一百万个连接。 + + * VM 使用率为 76％。 CPU 占 73％。 BEAM 模拟器以 45％的利用率运行，这与用户百分比非常接近，这很好，因为该模拟器以用户身份运行。 + + * 通常，CPU 利用率不是衡量系统繁忙程度的好方法，因为调度程序使用 CPU。 + + * 一个月后，解决瓶颈问题的原因是每个服务器有 200 万个连接。 + + * BEAM 利用率为 80％，接近 FreeBSD 可能开始分页的位置。 CPU 大致相同，连接增加了一倍。 调度程序遇到了争用，但运行得很好。 + + * 似乎是个停止的好地方，因此开始分析 Erlang 代码。 + + * 最初每个连接有两个 Erlang 进程。 切成一个。 + + * 使用计时器做了一些事情。 + + * 每个服务器的连接数达到 280 万峰值 + + * 571k pkts / sec，> 200k dist msgs / sec + + * 进行了一些内存优化，因此 VM 负载降至 70％。 + + * 尝试了 3 百万个连接，但失败了。 + + * 当系统出现问题时，请查看长消息队列。 单个消息队列或消息队列的总和。 + + * 已添加到 BEAM 工具中有关每个进程的消息队列统计信息。 发送/接收多少消息，速度有多快。 + + * 每 10 秒采样一次，可以看到一个进程在其消息队列中有 600K 条消息，出队列率为 40K，延迟为 15 秒。 预计排水时间为 41 秒。 + +* 调查结果： + + * Erlang + BEAM 及其修复-具有出色的 SMP 可扩展性。 几乎线性的可伸缩性。 卓越。 在 24 路机器上，可以以 85％的 CPU 使用率运行系统，并且可以保持生产负荷。 它可以像这样整天运行。 + + * 证明 Erlang 的程序模型。 + + * 服务器启动的时间越长，它将积累长期处于运行状态的连接（大多数情况下处于空闲状态），因此它可以处理更多的连接，因为这些连接对每个连接而言并不那么忙。 + + * 竞争是最大的问题。 + + * 他们的 Erlang 代码中进行了一些修复，以减少 BEAM 的争用问题。 + + * 一些已修补到 BEAM。 + + * 对工作负载进行分区，因此无需过多地处理处理器。 + + * 时间锁定。 每次从端口传递消息时，它看起来都会更新一天中的时间，这是所有调度程序中的一个锁，这意味着所有 CPU 都在打一个锁。 + + * 优化使用计时器轮。 删除了 bif 计时器 + + * 检查 IO 时间表在算术上增长。 创建的 VM 崩溃将在各个点重新分配哈希表。 改进以使用表格的几何分配。 + + * 添加了写入文件，该文件占用一个您已经打开的端口，以减少端口争用。 + + * Mseg 分配是所有分配器之间的单点争用。 按调度程序进行。 + + * 接受连接时有很多端口事务。 设置选项以减少昂贵的端口交互。 + + * 当消息队列积压很大时，垃圾回收将破坏系统的稳定性。 因此，暂停 GC 直到队列缩小。 + + * 避免付出一些常见的代价。 + + * 将 TSE 时间计数器从 FreeBSD 9 反向移植到了 8。读取计时器更便宜。 快速获取时间，比购买芯片便宜。 + + * 从 FreeBSD 9 向后移植 igp 网络驱动程序，因为在 NIC 锁定时存在多个队列问题。 + + * 增加文件和套接字的数量。 + + * Pmcstat 显示花费了大量时间来查找网络堆栈中的 PCB。 因此，增加哈希表的大小可以使查找更快。 + + * BEAM 补丁 + + * 先前提到的检测补丁。 仪器调度程序可获取利用率信息，消息队列的统计信息，睡眠次数，发送速率，消息计数等。可以使用 procinfo 以 Erlang 代码进行操作，但是连接数百万时非常慢。 + + * 统计信息收集非常有效，因此可以在生产中运行。 + + * 统计信息以 3 个不同的衰减间隔保持：1、10、100 秒间隔。 允许随着时间推移查看问题。 + + * 使锁计数适用于较大的异步线程数。 + + * 为调试锁定计数器添加了调试选项。 + + * 调整 + + * 将调度程序的唤醒阈值设置为低，因为调度程序会进入睡眠状态并且永远不会唤醒。 + + * 优先使用 mseg 分配器，而不是 malloc。 + + * 每个调度程序的每个实例都有一个分配器。 + + * 配置载波大小从大到大。 使 FreeBSD 使用超级页面。 降低了 TLB 跳动率，并提高了同一 CPU 的吞吐量。 + + * 以实时优先级运行 BEAM，以使诸如 cron 作业之类的其他事情不会中断计划。 防止可能导致重要用户流量积压的故障。 + + * 修补程序可记录旋转计数，以便调度程序不会旋转。 + + * 失忆症 + + * 首选 os：timestamp 而不是 erlang：now。 + + * 不使用事务，但是使用远程复制遇到了积压。 每个表的并行复制可提高吞吐量。 + + * 实际上还有很多更改。 + +## 课程 + +* **优化是一项仅适用于巨魔和工程师的深色球衣工作。** 。 当 Rick 进行他为获得 200 万个服务器连接所做的所有更改时，我很麻木。 请注意，编写工具，运行测试，向后移植代码，将测试对象添加到几乎每个堆栈级别，调试系统，查看痕迹，处理非常低级的细节并试图理解所有内容都需要大量工作 。 这就是消除瓶颈，以将性能和可伸缩性提高到极限的方法。 + +* **获取所需的数据**。 **编写工具。 补丁工具。 添加旋钮。** Ken 坚持不懈地扩展系统以获取他们所需的数据，不断为他们管理和优化系统所需的数据编写工具和脚本。 尽一切努力。 + +* **测量。 消除瓶颈。 测试。 重复。** 这就是您的操作方式。 + +* **二郎岩石！** Erlang 继续证明其作为通用，可靠，高性能平台的能力。 尽管就个人而言，所需的所有调优和补丁处理都对该主张造成了怀疑。 + +* **破解病毒代码并获利** **。** 病毒性是一种寓言性的品质，但是正如 WhatsApp 所显示的，如果您确实发现了，伙计，它值得很多钱。 + +* **价值和员工人数现已正式离婚** **。** 当今世界上有很多倍增力。 先进的全球电信基础设施使类似 WhatsApp 的应用成为可能。 如果 WhatsApp 必须建立网络或电话等，那将永远不会发生。 强大的廉价硬件和开放源代码软件的可用性当然是另一个倍数。 就像在正确的时间，正确的位置，正确的产品出现在正确的购买者面前一样。 + +* **这种对用户想法** **的残酷关注。** WhatsApp 专注于成为一个简单的消息传递应用程序，而不是游戏网络，广告网络或消失的照片网络。 那为他们工作。 它指导了他们的无广告立场，在添加功能时保持应用程序简单的能力，以及总体而言，它在任何手机上都可以正常工作。 + +* **简单原因的限制是可以的** **。** 您的身份与电话号码相关，因此，如果更改电话号码，则您的身份将消失。 这非常像计算机。 但这确实使整个系统的设计更加简单。 + +* **年龄不是没有** **。** 如果是年龄歧视导致 WhatsApp 联合创始人布莱恩·阿克顿（Brian Acton）在 2009 年无法在 Twitter 和 Facebook 上找到工作，那真可耻，可耻，可耻。 + +* **简单开始，然后自定义** **。** 最初启动聊天时，服务器端基于 ejabberd。 此后已被完全重写，但这是向 Erlang 方向迈出的第一步。 在最初的用例中，Erlang 的可伸缩性，可靠性和可操作性方面的经验导致了越来越广泛的使用。 + +* **保持服务器计数低** **。** 不断努力将服务器数量保持在尽可能低的水平，同时为产生短期使用高峰的事件留有足够的空间。 分析和优化，直到这些工作受到收益递减的影响，然后再部署更多硬件。 + +* **故意过度配置硬件。** 这可确保用户在庆祝活动期间获得不间断的服务，并且员工能够享受假期，而不必花费所有时间解决过载问题。 + +* **当您收取费用** **时，增长停滞。** 当免费使用 WhatsApp 时，增长非常快，早期每天有 10,000 次下载。 然后，当切换到付费时，每天的费用下降到 1,000。 到了年底，在添加了图片消息后，他们决定收取一次性的下载费用，后来又改为年度付款。 + +* **灵感来自最陌生的地方** **。** 忘记了 Skype 帐户上的用户名和密码的经验驱使人们使应用程序“正常运行”。 ## 相关文章 -* [关于黑客新闻](http://news.ycombinator.com/item?id=5129530) -* [Duck Duck 在 Twitter 上转到](https://twitter.com/duckduckgo) -* [2009 Duck Duck Go Architecture](http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-architecture.html) （ [Hacker News](http://news.ycombinator.com/item?id=525048) ） -* [2011 架构更新](http://help.duckduckgo.com/customer/portal/articles/216392-architecture) -* [DuckDuckGo 过去用光了我的地下室](http://www.gabrielweinberg.com/blog/2011/12/duckduckgo-used-to-run-out-of-my-basement.html) -* [用 Perl 编写的 Duck Duck Go](http://news.ycombinator.com/item?id=1500487) -* [用 Bucardo 复制 PostgreSQL](http://www.gabrielweinberg.com/blog/2011/05/replicating-postgresql-with-bucardo.html) -* [PostgreSQL 技巧和窍门](http://www.gabrielweinberg.com/blog/2011/05/postgresql.html) -* [nginx JSON 骇客](http://www.gabrielweinberg.com/blog/2011/07/nginx-json-hacks.html) -* [我是我自己经营的搜索引擎（Duck Duck Go）的创始人，AMA](http://www.reddit.com/r/IAmA/comments/bbqw7/i_am_the_founder_of_a_search_engine_duck_duck_go/) -* [DuckDuckGo 爆炸](http://news.ycombinator.com/item?id=3770958) -关于 DDG 流量增加的黑客新闻讨论 -* [Gabriel Weinberg 的博客](http://www.gabrielweinberg.com/blog/) -在创业公司和其他主题上经常要说的有趣的事情 -* Tech Spot [DuckDuckGo 创始人加布里埃尔·温伯格的访谈](http://www.techspot.com/article/559-gabriel-weinberg-interview/) -* [DuckDuckGo 创始人加布里埃尔·温伯格（Gabriel Weinberg）谈论创建更多私有搜索引擎](http://techland.time.com/2012/03/23/duckduckgo-founder-gabriel-weinberg-talks-about-creating-a-more-private-search-engine/) -* [在搜索引擎中隐藏 Google](http://articles.washingtonpost.com/2012-11-09/business/35505935_1_duckduckgo-search-engine-search-results) -* [没有目标广告的 Google 的免费跟踪替代品](http://www.heavychef.com/search-engines-a-track-free-alternative-to-google-with-no-targeted-ads/) -* [Duck Duck Go 开源](https://github.com/duckduckgo/duckduckgo/wiki) -DDG 是封闭源，但具有一些开放源代码组件 -* [DataSift 架构：每秒 120,000 条推特的实时数据挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) -* [Google 和搜索的未来：阿米特·辛格（Amit Singhal）和知识图](http://m.guardiannews.com/technology/2013/jan/19/google-search-knowledge-graph-singhal-interview) -* [DuckDuckGo 可以挑战在位搜索冠军吗？](http://www.business2community.com/seo/can-duckduckgo-challenge-the-reigning-champions-of-search-0382883) +* [关于黑客新闻](https://news.ycombinator.com/item?id=7306066) + +* [主题演讲：Benedict Evans-InContext 2014](https://www.youtube.com/watch?v=VnhbvS0MBXE) （相关的 [幻灯片](http://ben-evans.com/presentations/2013/11/5/mobile-is-eating-the-world-autumn-2013-edition) ） + +* [Whatsapp 和 190 亿美元](http://ben-evans.com/benedictevans/2014/2/19/whatsapp-and-19bn) ，作者：Benedict Evans + +* [WhatsApp 的博客：一家市值 160 亿美元的初创企业的精彩日记](http://www.slideshare.net/socialmarketingfella/the-diary-of-a-16-billion-startup-31457350) -Andre Bourque 的精彩活动时间表。 + +* Rick 在 GitHub 上对 [Erlang 的更改](https://github.com/reedr) + +* [WhatsApp 博客](http://blog.whatsapp.com/) ： + + * [一百万！](http://blog.whatsapp.com/index.php/2011/09/one-million/) （ [Hacker News](https://news.ycombinator.com/item?id=3028547) ） + + * [一百万就是 2011 年](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/) + + * [4 亿个故事](http://blog.whatsapp.com/index.php/2013/12/400-million-stories/) + +* [WhatsApp：内幕](http://www.wired.co.uk/news/archive/2014-02/19/whatsapp-exclusive) + +* [WhatsApp](http://www.whatsapp.com/opensource/) 使用的开源项目 + +* [Whatsapp，Facebook，Erlang 和实时消息传递：一切都始于 ejabberd](http://blog.process-one.net/whatsapp-facebook-erlang-and-realtime-messaging-it-all-started-with-ejabberd/) + +* Quora： [WhatsApp 如何工作？](http://www.quora.com/How-does-WhatsApp-work-1) ， [WhatsApp 如何在移动网络中工作？](http://www.quora.com/How-does-WhatsApp-work-out-of-mobile-network) ， [WhatsApp 如何成长得如此之大？](http://www.quora.com/WhatsApp-Messenger/How-did-WhatsApp-grow-so-big) + +* [WhatsApp 已损坏，实际上已损坏](http://fileperms.org/whatsapp-is-broken-really-broken/) -早期的安全问题 + +* [WhatsApp 首席执行官 Jan Koum Hates Advertising 和 Tech Rumor Mill（全潜视频）](http://allthingsd.com/20130510/whatsapp-ceo-jan-koum-hates-advertising-and-the-tech-rumor-mill-full-dive-video/) + +* [新加坡正在逐步通过 WhatsApp 开展业务。 你是？](http://www.happymarketer.com/singapore-is-progressively-doing-business-over-whatsapp-are-you) + +* [四个数字解释了 Facebook 为什么收购 WhatsApp](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) + +* [马克·扎克伯格的公告](https://www.facebook.com/zuck/posts/10101272463589561?stream_ref=10) + +* [带有 Mochiweb 的百万用户彗星应用程序，第 3 部分](http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3) + +* [Erlang 内部，WhatsApp 成功背后的罕见编程语言](http://www.fastcolabs.com/3026758/inside-erlang-the-rare-programming-language-behind-whatsapps-success) + +* [Facebook 的扎克伯格说，WhatsApp 的价值实际上超过 19B 美元，并且是 Internet.org 达成了交易](http://techcrunch.com/2014/02/24/whatsapp-is-actually-worth-more-than-19b-says-facebooks-zuckerberg/) + +* [Facebook 以 190 亿美元收购 Whatsapp：价值与定价观点](http://aswathdamodaran.blogspot.in/2014/02/facebook-buys-whatsapp-for-19-billion.html) + +* [Facebook 的 190 亿美元渴望，马克·扎克伯格（Mark Zuckerberg）解释](http://www.forbes.com/sites/georgeanders/2014/02/19/facebook-justifies-19-billion-by-awe-at-whatsapp-growth/) + +* [恕我直言：从 WhatsApp 汲取的教训](http://blog.mindcrime-ilab.de/2012/12/16/imho-lessons-learned-from-whatsapp/) + +* [您可能不会使用 WhatsApp，但世界其他地区肯定会使用](http://www.wired.com/wiredenterprise/2014/02/whatsapp-rules-rest-world/) + +* [WhatsApp 的故事挑战了山谷的一些传统智慧](http://techcrunch.com/2014/02/23/the-whatsapp-story-challenges-the-valleys-conventional-wisdom/) + +* [根据 Jan Koum（视频）的说法，WhatsApp 做了正确的事](http://recode.net/2014/02/20/what-whatsapp-did-right-according-to-jan-koum-video/) + +* [Facebook 为什么要购买 WhatsApp？](http://kottke.org/14/02/why-did-facebook-buy-whatsapp) + +* [有人可以向我解释 WhatsApp 的估值吗？](http://www.linkedin.com/today/post/article/20140220134541-79695780-can-someone-explain-whatsapp-s-valuation-to-me) + +* [Google 对 WhatsApp 的不寻常出价](https://www.theinformation.com/Google-s-Unusual-Offer-to-WhatsApp) 。 + +我理解正确吗？ WS 正在一台唯一的服务器上运行？ 真？ 那简直是疯了，O_o 正常，它总是掉下来... + +伊凡，你是怎么得出这个结论的？ +是从哪儿说的？ + +> 数百个节点 +> > 8000 个内核 +> 数百兆字节的 RAM + +谢谢！ 这是我今年（2014 年）阅读的最好的，最有趣，最令人鼓舞和最具挑战性的文章之一。 我喜欢看到其他人所做的既平凡（或使复杂的平凡）又令人惊奇。 我的团队将继续使用 Java，但是看到另一个团队不仅在财务上如此成功，而且能够满足数亿用户的需求是令人鼓舞的。 太棒了！ 谢谢！ + +800 万资金是错误的。 他们筹集了大约六千万。 + +yowsup 在这里可用：https：//github.com/nprasan/yowsup + +我赞同 Kevin 的评论-一篇非常出色的文章。 实际上在 1 篇文章中有 3 篇很棒的文章：移动应用程序市场分析，深入的技术探讨，一般课程。 非常感谢！ 会在这里上班... + +您说：“尽管就个人而言，所需的所有调优和修补工作都对该主张造成了一些怀疑。” 这种怀疑似乎基于 Erlang / OTP 静止不动的假设，而事实上一段时间前 WhatsApp 的 Erlang / OTP 补丁已被并入 Erlang / OTP 中。 Erlang / OTP 是开源的，社区补丁很常见，爱立信的 OTP 团队在社区的帮助下继续在功能，性能和可伸缩性方面推动平台向前发展。 我相信 WhatsApp 最初是在 Erlang / OTP 的 R14B 版本上开发补丁的，但是下个月（2014 年 3 月），OTP 团队将发布 17.0 版，再次达到了每年生产 Erlang / OTP 的新主要版本的正常时间表。 + +很棒的帖子！ +时间过长 + +到目前为止，我几个月来读的最好的文章。 +做得好，可扩展性高。 + +首先，很棒的文章。 whatsapp 的工程设计以及他们对细节的关注给我留下了深刻的印象。 拥有内部外观很酷。 + +但是，对于涉及“ 200 万个 TCP 连接”的测试，我感到困惑。 我不清楚这到底是什么意思。 我的理解是，无效的 TCP 连接理论上只需要 R​​AM，而对 CPU 或带宽的影响很小。 + +如果是这样，我很难怀疑该基准所达到的目标。 在大多数情况下，RAM 不是限制因素吗？ 我不清楚 Erlang 在这里有什么特别的帮助，或者说 200 万个连接测试的实际含义是，CPU 和带宽是否应该处于闲置状态。 在演示文稿中，听起来好像 CPU 的使用率为 85％，但我不清楚 CPU 的实际功能。 谁能启发我？ + +优秀的文章。 + +谈到隐私，“邮件未存储在服务器上” -@Gabriel Weinberg： -好的帖子。 谢谢！ :) -为什么不将 Rout 53 用于全局 DNS？ 我认为它的区域比 Global Traffic Director 多，不是吗？ +不对 -这肯定是一篇精彩的文章！ 大量和合成。 深入了解 DDG 使我意识到每个方面都有多么复杂。 +至少，视频和 img 消息将发送到服务器，然后进行压缩，然后转发给您的联系人。 +如果 whatsapp 在此之后将其删除，我相信这取决于 NSA。 -首先，我已经进行了 6 个月的测试，最后才恢复使用 Mountain View 的功能。 用英语使用 DDG 通常是准确的，但是以我的语言（法语）显示的结果不够可靠。 现在，我了解到，映射和合并数十个源以及它们的元数据，实时翻译所有内容都是一项艰巨的任务。 +很棒的文章！ 感谢您分享。 -然后，让我将“一个投诉用户**认为**太快”改成“加布里埃尔，请到欧洲旅行，每次搜索都享受±.5s-±.8s 的时间。我认为亚马逊的网络速度更快（ 好吧，考虑到我当地的 Amazon 商店的性能），但是一天要进行±50 次搜索，有时我不得不重新输入“！g < search >”，以便在非常简单的搜索（例如商店名称， 知名品牌或艺术家）。 +优秀的文章...！ 感谢分享。 -最后，几乎没有与法语查询相关的广告。 这非常舒适，但我想还不能使收入最大化。 +绝对惊人的文章！ 我喜欢它，每一行，每一句话！！！ -我希望 DDG 能够在所有语言和所有大洲不断进步，并且我会不时检查... +伟大的伟大伟大的职位。 我在 2009 年从事类似项目的工作，我知道所有这些技术讲座，并且帖子中的细节非常详尽。 我非常感谢作为技术部分的商业观点和经验教训...很好的结论。 +值得花时间阅读。 谢谢。 -感谢您的采访！ +不要相信会告诉您的人会花费 30 台主机打开足够的 IP 端口来生成足够的连接来测试具有一百万个并发连接的服务器。 这是完全错误的，并且仅仅是对知识缺失的证明。 ;） -感谢您的文章。 它们用于离线数据处理？ +已收藏。 这是非常棒的信息，感谢您的分享， -很棒的文章！ 对您为什么选择 Ubuntu 而不是 AWS 中提供的其他免费 Linux 操作系统有任何见解？ 例如，Fedora，OpenSUSE，Amazon Linux？ +由于不熟悉此类工程的尖端人员，这是一本有趣的文章。 +谁能回答一个愚蠢的问题？ -很生气的 DDG 不支持 IPv6。 bing，yahoo 和 google 支持 IPv6。...DDG 向后。 +我很欣赏从单个服务器中获得如此高的效率必然需要大量的工作，这是一项巨大的成就，但是为什么这样的消息传递应用程序原则上会带来巨大的可扩展性挑战？ 为什么最小数量的服务器很重要？ 在我的手机上看到自己的小 WhatsApp 气泡时，我经常只与约 20 个人联系，很少能以每小时 4 个以上的速度进行完整的对话。 +因此，如果我不得不从视觉上代表整个网络，我会猜想有很多自然的分区，而不是像 bittorrent 这样的大规模且不可预测的互连。 并不是说这将是一个小的编程任务，但是原则上，通用框架不能通过遵循然后预测用户的自然分区来将连接分配给服务器。 例如。 我和我的伦敦哥们都乱伦，与圣保罗的交通突然中断为零。 -Gabriel-您愿意在 Lucene / Solr Revoltuion 上发表有关 DDG 如何使用 Solr 的论文吗？ 我很肯定社区会很感兴趣。 Lucene / Solr Revolution 将于 4 月底在圣地亚哥举行。 我们已经将您的博客发布到 SearchHub.org 上，这是所有 Lucene / Solr 的地方。 +因此，一旦最佳地分配了连接，服务器之间的剩余最小流量就不会成为问题-尤其是当您看到我突然尝试与 Sao Paolo 进行实时聊天时，您将我们切换到同一台服务器进行一次 。 -theipv6guy： +我不是在问为什么 WhatsApp 没有尝试构建这种复杂的东西，而是我是否对社交网络连接的预测分区的 Hadoop 需求未得到满足是正确的？ （是的，我意识到这比 hadoop 要复杂得多） -就我而言，就 IPv6 而言，这是一些相当有力的评论。 DuckDuckGo 使用 AWS，仅在某些产品上支持 IPv6。 正如我希望 DDG 赶上潮流一样，我不怪他们没有转换托管服务提供商，甚至只是在一切面前 shoe 脚 Akamai 或双栈 ELB。 +当客户端收到消息后，消息将被删除，这听起来很完美，但是如果出现群发消息怎么办？ 它会一直持续到小组的所有成员都收到吗？ -您应该将怒火引向亚马逊。 +不错的文章。 让您欣赏系统的复杂性，并像 Whatsapp 一样被我们视为日常用户。 -（不过，是否在其 Linode 上启用了 IPv6？：D） +嘿，这是很酷的文章。 -很棒的帖子，谢谢。 有关我所遇到的问题和我没有遇到的问题的许多详细信息。 +我有一个问题，我还没有完全明白。 那么，客户端建立的每个套接字连接都将在一个单独的过程中结束吗？ 如果是这样，那么服务器如何创建一百万个：/进程中的消息队列如何一次可能达到 20 万条消息？ -优秀的文章。 我不了解所有技术，但细节令人着迷。 +谢谢 -很难击败 Google。 干净利落。 \ No newline at end of file +Facebook 没有购买 Whatsapp 的建筑，而是购买了 10 亿以上的昏迷用户 \ No newline at end of file diff --git a/docs/137.md b/docs/137.md index 9dd95ab..fe7b43c 100644 --- a/docs/137.md +++ b/docs/137.md @@ -1,37 +1,73 @@ -# 每天处理 1 亿个像素-少量竞争会导致大规模问题 +# 使用 AWS，Scala，Akka，Play，MongoDB 和 Elasticsearch 构建社交音乐服务 -> 原文： [http://highscalability.com/blog/2013/1/21/processing-100-million-pixels-a-day-small-amounts-of-content.html](http://highscalability.com/blog/2013/1/21/processing-100-million-pixels-a-day-small-amounts-of-content.html) +> 原文： [http://highscalability.com/blog/2014/3/11/building-a-social-music-service-using-aws-scala-akka-play-mo.html](http://highscalability.com/blog/2014/3/11/building-a-social-music-service-using-aws-scala-akka-play-mo.html) -![](img/5088f2340fb872cea42ebbdd8c5dbfc1.png) +![](img/7887820329b58171ca35d8132a92ae4c.png) -*这是 [Gordon Worley](http://www.linkedin.com/pub/gordon-worley/39/977/257) 的来宾帖子， [Korrelate](http://korrelate.com/) 的软件工程师在其中将在线购买与离线购买相关联（查看他们在这里做了什么）。* +*这是[前 Roem Hermon](https://twitter.com/margolis20) ， [serendip.me](http://serendip.me) 的首席架构师 [Rotem Hermon](https://twitter.com/margolis20) 的来宾转贴，涉及在进行启动音乐服务后的体系结构和扩展注意事项 。* -几周前，我们一天早上来到办公室，发现所有服务器警报都响了。 像素日志处理落后了 8 个小时，并且没有取得进展。 查看日志后，我们发现有一个大客户在夜间上线，为我们提供的流量比最初告诉我们的要多 10 倍。 我不会说我们感到惊慌，但办公室肯定比平时更加​​紧张。 但是，在接下来的几个小时中，由于有远见和快速的思考，我们得以扩大规模以处理增加的负载并清除积压的日志，以使日志处理恢复到稳定状态。 +[serendip.me](http://serendip.me) 是一项社交音乐服务，可以帮助人们发现朋友分享的美妙音乐，还可以将他们介绍给他们的“音乐灵魂伴侣”，即他们社交圈之外的人，他们在音乐方面有着相似的品味。 -在 Korrelate，我们部署了[跟踪像素](http://en.wikipedia.org/wiki/Web_bug)（也称为信标或网络错误），我们的合作伙伴将其用于向我们发送有关其用户的信息。 这些微小的 Web 对象不包含可见内容，但可以包含透明的 1 乘 1 gif 或 Javascript，并允许我们的合作伙伴在有人看到广告或采取与广告相关的操作时通知我们，而无需向我们发送广告服务器日志。 例如，当我们的一个合作伙伴展示广告时，他们通过将展示跟踪像素作为图像包含在 iframe 中或嵌入以我们的像素为源的脚本标签来触发我们的展示跟踪像素。 他们的广告会动态生成像素的网址，因此可以在查询字符串中向我们传递有关所展示广告的信息。 对于选择接受第三方 cookie 的用户，我们还可以在用户上设置和读取 Korrelate 用户 ID cookie，以便我们可以跟踪他们的活动，并在[聚合和匿名化](http://korrelate.com/privacy/)之后使用它，以提供我们的 分析产品。 +Serendip 在 AWS 上运行，并基于以下堆栈构建： [scala](http://www.scala-lang.org/) （和某些 Java）， [akka](http://akka.io/) （用于处理并发性），[播放框架](http://www.playframework.com/)（用于 Web 和 API 前端）， [MongoDB](http://www.mongodb.org/) 和 [Elasticsearch](http://elasticsearch.org/) 。 -在早期，甚至在 Korrelate 成为 Korrelate 之前，我们就知道有一天我们需要每天摄取数十亿个跟踪像素。 因此，当我们开始编写像素对数处理器时，我们进行了架构选择，使其可以扩展。 +### 选择堆栈 -最初，日志处理器是用 Java servlet 编写的，但是事实证明这很难在服务器上进行管理，而且我们都不满意使用 Java 进行编程。 寻找替代方案，因为当时我们使用 [Pentaho](http://www.pentaho.com/) 分析工具套件来生成有关原始数据的报告，所以我们转向了[水壶](http://kettle.pentaho.com/)（俗称 Pentaho 数据集成） 数据。 +建立 serendip 的挑战之一是从第一天起就需要处理大量数据，因为 serendip 的主要特征是它收集**并从公共音乐服务在 Twitter** 上共享的每一首音乐。 因此，当我们讨论选择要使用的语言和技术的问题时，一个重要的考虑因素就是扩展能力。 -Kettle 是在 JVM 上运行的提取转换加载工具，可以充分利用多线程来快速处理大量数据。 它还具有一个称为 Spoon 的易于使用的 GUI 工具，用于设计 Kettle 程序，该程序需要大量的配置，而编程却相对较少。 我们非常享受使用 Kettle 创建和部署日志处理的速度。 随着时间的流逝，我们意识到了水壶的局限性。 +JVM 似乎是我们系统经过验证的性能和工具的正确基础。 它也是许多开源系统（例如 Elasticsearch）的选择语言，这使**使用其本机客户端**-很大的优势。 -通过 Kettle 作业运行大量数据需要大量内存（在我写这篇文章时，日志处理器需要 8 GB 内存来处理 250,000 条记录的文件）。 在开发方面，使用 Spoon 易用性的缺点是源文件仅是人类可编辑的 XML，因此我们无法利用 Git 正常工作流来轻松合并并发开发分支，从而迫使我们 就像有人处理日志处理器时源被锁定一样。 但是尽管有这些限制，我们仍继续使用 Kettle，因为它正在工作，我们还有很多其他工作要做，并且我们知道我们可以在需要时扩大规模，即使它会很昂贵。 +当我们研究 JVM 生态系统时，scala 脱颖而出，成为一种有趣的语言选择，它允许现代方法编写代码，同时保持与 Java 的完全互操作性。 支持 scala 的另一个论点是 **akka actor 框架，它似乎非常适合流处理基础结构**（确实如此！）。 Play 网络框架才刚刚开始被采用，并且看起来很有希望。 早在 2011 年初我们刚开始时，这些仍然是最前沿的技术。 因此，我们当然非常高兴，到 2011 年底，scala 和 akka 合并成为 [Typesafe](http://typesafe.com/) ，随后不久 Play 就加入了。 -几个月前，我们不得不开始同时运行两个日志处理器，以适应我们的负载。 这是一个很好的体验，因为它有助于揭示日志处理中的问题区域。 +**选择 MongoDB 是因为它结合了开发人员的友好性，易用性**，功能集和可能的可伸缩性（使用自动分片）。 我们很快了解到，要使用和查询数据的方式将需要在 MongoDB 上创建很多大索引，这将使我们很快遇到性能和内存问题。 因此，我们一直主要将 MongoDB 用作键值文档存储，还依赖于其原子增量来获取需要计数器的多个功能。 +通过这种使用，MongoDB 变得非常可靠。 它也很容易操作，但是主要是因为我们设法*避免使用分片*并使用单个副本集（MongoDB 的分片架构非常复杂）。 -当只有一个日志处理器运行时，我们遇到的唯一性能问题与过程的各个部分有关，需要很长时间才能完成。 例如，我们发现对数据库中表的更新花费了很长时间，因此我们几乎将所有存储像素数据的表都转换为仅追加，以便快速插入。 某些表不能仅作追加操作，因此要与我们创建的加载表一起使用，日志处理将快速将数据插入到表中，然后稍后再回过头来将加载表与数据库中的主表进行同步 比我们执行 upsert 的速度快。 +为了查询我们的数据，我们需要一个具有完整搜索功能的系统。 在可能的开源搜索解决方案中， **Elasticsearch 成为最具扩展性和面向云的系统**。 它的动态索引架构以及它提供的许多搜索和构面功能使我们可以在其之上构建许多功能，从而使其成为我们体系结构的核心组成部分。 -调出第二个日志处理器会使我们面临新的问题。 尽管由于对仅追加表的非阻塞写入而使我们能够快速写入数据库，但是需要与加载表同步的少数几个表引起了足够的争用，两个日志处理器在运行一个日志处理器时几乎没有任何收益。 为了解决这个问题，我们将日志处理分为两部分：仅写到仅追加表的部分和需要插入堆表的部分。 这样，我们就可以打开仅追加日志处理器的两个实例（仅是堆表日志处理器之一），并获得良好的吞吐量，因为堆表从每个需要插入或更新的日志文件接收的数据相对较少，而追加- 只有表从每个日志文件接收很多数据。 +我们选择**自己管理 MongoDB 和 Elasticsearch** ，并且出于两个主要原因，不使用托管解决方案。 首先，我们希望完全控制两个系统。 我们不想依靠其他因素进行软件升级/降级。 其次，我们处理的数据量意味着托管解决方案比直接在 EC2 上直接管理它要昂贵。 -因此，在像素大量涌入的早晨，我们认为我们已经做好了扩大规模的准备。 我们在几个小时之内启动了运行其他附加仅日志处理器实例的其他服务器，并开始处理日志（堆表日志处理器自行继续足够快地运行以保持运行状态）。 但是，我们很快发现，日志处理器中仍然存在争用。 +### 一些数字 -为了跟踪日志处理的方式，我们将一些基本统计信息写到了几个审计表中，这些统计信息涉及日志处理需要多长时间以及处理多少像素。 为了收集这些数据，我们使用了 Kettle 的内置日志记录功能将信息写入表格，然后将其合并为对我们有用的摘要形式。 事实证明，Kettle 的编写方式要求在审计表上请求排他表级锁以将其写入。 而且由于在日志处理器实例的每次运行中都会发生数十次，因此对于相同的表，我们有数百个请求彼此等待。 每个请求的清除速度都很快，但是加了一点点延迟，导致日志处理器实例在应在 2 中完成时需要花费 15 分钟的时间来运行。 +Serendip 的“泵”（处理 Twitter 公众流和 Facebook 用户供稿的部分）**每天大约消化 5,000,000 个项目**。 这些项目通过一系列“过滤器”传递，这些过滤器检测并解析受支持服务（YouTube，Soundcloud，Bandcamp 等）的音乐链接，并在它们之上添加元数据。 泵和过滤器作为 akka actor 运行，并且整个过程由单个 **m1.large EC2 实例**管理。 如果需要，可以通过使用 akka 的远程角色将系统分发到处理器集群来轻松扩展。 -我们关闭了 Kettle 的内置日志记录功能，将其替换为我们自己的一些不需要表级锁定的代码，并且日志处理器之间的数据库争用消失了。 我们以艰难的方式学到了我们经常听到的智慧，但显然还没有被内在化：**少量争用可能成为大规模的问题**。 +在这些项目中，我们每天大约可获得 850,000 个有效项目（即真正包含相关音乐链接的项目）。 这些项目在 Elasticsearch 中（以及在 MongoDB 中用于备份和保持计数器）都已建立索引。 由于每个有效项都意味着更新多个对象，因此在 Elasticsearch 中我们获得的**索引速率为〜40 / sec** 。 +我们**在 Elasticsearch 中保留项目（推文和帖子）的每月索引**。 每个月度索引包含**〜2500 万个项目，并具有 3 个碎片**。 群集以 **4 个节点运行，每个节点在 m2.2xlarge 实例**上。 此设置有足够的内存来运行我们需要的数据搜索。 -通过从日志处理中完全消除争用，我们能够快速启动十多个日志处理器实例，并使用它们来快速处理积压的事务，然后将其调节回稳定状态。 在短短 24 小时内，一切恢复正常，节省了一些额外的硬件和日志处理器。 +我们的 MongoDB 集群处理更多数据类型，计数器和统计信息更新时，每秒**为 100 个写入/秒，每秒 300 次为**读取。 副本集具有在 **m2.2xlarge 实例上运行的主节点，在 m1.xlarge 实例**上运行的辅助节点。 -尽管日志处理器现在可以处理高级别的并发性，但仍需要对其进行重建以处理更多的像素，而无需当前日志处理器的高昂成本。 调出当前日志处理器的新实例意味着添加具有大量 RAM 的服务器（通常大约需要 24 GB，以便我们在每台服务器上运行两个日志处理器，以及用于其他进程的额外 RAM），这是很昂贵的。 而且，当前的日志处理器在与数据库的有限连接上仍然面临潜在的争用。 为了解决这个问题，我们需要寻找减少需要向数据库传递数据的进程数量的方法。 +### 建立一个提要 -我们还希望从 Kettle 转移到一个使代码管理更容易的系统。 为此，我们已开始使用 [Storm](http://storm-project.net/) 构建新的日志处理器，该处理器提供了用于创建自定义实时流处理工作流的灵活框架，类似于 [Hadoop](http://hadoop.apache.org/) 提供了灵活框架的方式 用于批处理。 尽管仅 Storm 本身提供的内置功能要比 Kettle 少得多，但也不必这样做，因为 Storm 工作流可以用任何语言编写，也可以使用我们想要的任何现有库。 由于我们的大多数代码已经在 Ruby 中，因此我们能够利用现有的代码库在 Ruby 中构建 Storm 工作流。 基于其他使用 Storm 的[其他人](https://github.com/nathanmarz/storm/wiki/Powered-By)，我们希望看到我们的 Storm 日志处理器每天可以扩展到数十亿像素。 \ No newline at end of file +当我们开始设计 Serendip 的主要音乐供稿的体系结构时，我们知道我们希望供稿是动态的并对用户的动作和输入做出反应。 如果用户给某首歌“加油”或“播放”特定艺术家，我们希望该动作立即反映在提要中。 如果用户“不喜欢”艺术家，则我们不应再次播放该音乐。 + +我们还希望提要是来自多个来源的音乐的组合，例如朋友共享的音乐，喜爱的艺术家的音乐以及具有相同音乐品味的“建议”用户共享的音乐。 +这些要求意味着采用“ [扇出即写](http://www.quora.com/What-is-the-best-storage-solution-for-building-a-news-feed-MongoDB-or-MySQL)”的方法来创建提要是不可行的。 我们需要一个选项，以使用与用户有关的所有信号实时构建提要。 Elasticsearch 提供的功能集使我们能够构建这种实时提要生成。 + +提要算法包含几种“策略”，用于选择要在每次提要中以不同比率动态组合的项目。 每种策略都可以考虑到最新的用户操作和信号。 将策略的组合转换为对实时数据的几次搜索，这些搜索由 Elasticsearch 不断索引。 由于数据是基于时间的，并且索引是每月创建的，因此**我们始终只需要查询完整数据**的一小部分。 + +幸运的是，Elasticsearch 可以很好地处理这些搜索。 它还提供了扩展此体系结构的已知途径-**写入可以通过增加分片**的数量进行缩放。 可以通过添加更多副本和物理节点来扩展搜索范围。 + +查找“音乐灵魂伴侣”（通过音乐品味匹配用户）的过程很好地利用了 Elasticsearch 的**构面（聚合）功能。 作为持续的社交流处理的一部分，该系统通过计算遇到的社交网络用户的顶级共享艺术家（使用对共享音乐的多面搜索）来准备数据。** + +当偶然的用户发出信号（通过播放音乐或与提要互动）时，它可以触发对该用户的音乐灵魂伴侣的重新计算。 该算法会根据喜欢的艺术家列表（不断更新）找到最匹配的其他用户，并权衡受欢迎程度，分享数量等其他参数。然后应用另一组算法来过滤垃圾邮件发送者（是的， 是音乐垃圾邮件发送者……）和离群值。 + +我们发现，此过程可为我们提供足够好的结果，同时又使我们免于需要其他可以运行更复杂的群集或推荐算法的系统。 + +### 监控和部署 + +Serendip 正在使用 [ServerDensity](http://www.serverdensity.com/) 进行监视和警报。 这是一款易于使用的托管解决方案，具有不错的功能集和合理的启动价格。 ServerDensity 本机提供服务器和 MongoDB 监视。 我们还大量使用了向其中报告自定义指标的功能，以报告内部系统统计信息。 + +内部统计信息收集机制为系统中发生的每个操作收集事件，并将其保存在 MongoDB 收集中。 定时作业每分钟一次从 MongoDB 中读取这些统计信息，并将其报告给 ServerDensity。 这使我们可以使用 ServerDensity 监视和警告 Elasticsearch 以及我们的运营数据。 + +使用 Amazon Elastic Beanstalk 完成服务器和部署的管理。 Elastic Beanstalk 是 AWS 的受限 PaaS 解决方案。 它非常容易上手，尽管它并不是真正功能齐全的 PaaS，但其基本功能足以满足大多数常见用例的需要。 它提供了简单的自动缩放配置，还可以通过 EC2 进行完全访问。 + +使用驻留在 EC2 上的 [Jenkins](http://jenkins-ci.org/) 实例完成应用程序的构建。 Play Web 应用程序打包为 WAR。 [构建后脚本](https://github.com/rore/beanstalk-upload)将 WAR 作为新的应用程序版本推送到 Elastic Beanstalk。 新版本不会自动部署到服务器，而是手动完成的。 通常将其首先部署到登台环境中进行测试，然后将其批准部署到生产环境中。 + +### 外卖 + +总结一下，这是从构建 serendip 中学到的一些重要经验教训，而不是通过任何特殊命令得出的。 + +1. **知道如何缩放**。 您可能不需要从第一天开始进行扩展，但是您需要知道系统的每个部分如何扩展以及扩展到什么程度。 如果扩展需要时间，请提前给自己足够的时间。 +2. **准备峰**。 特别是在初创企业的生命中，如果您始终以接近最高的容量运行，那么一个救生员或 reddit 帖子就会使您的系统瘫痪。 保持足够的余量，以便您可以处理突然的负载或准备好快速扩展。 +3. **选择一种不会阻碍您的语言**。 确保要使用的技术使用您的语言的本地客户端，或者至少具有主动维护的客户端。 不要卡在等待库更新。 +4. **相信炒作**。 您需要一种将随您的产品一起增长并且不会过早死亡的技术。 一个充满活力，活跃的社区以及对该技术的一些质疑可以很好地表明其生存。 +5. **不要相信炒作**。 查找有关您正在评估的技术的简报。 他们可以教您有关它的弱点。 但也不要太当真，当事情无法按预期进行时，人们往往会情绪激动。 +6. **玩得开心**。 选择一种使您兴奋的技术。 一个让您认为“哦，太酷了，我该怎么办”。 毕竟，这也是我们的目标。 \ No newline at end of file diff --git a/docs/138.md b/docs/138.md index 554b224..bf80bdb 100644 --- a/docs/138.md +++ b/docs/138.md @@ -1,67 +1,102 @@ -# MongoDB 和 GridFS 用于内部和内部数据中心数据复制 +# 大，小，热还是冷-条带，Tapad，Etsy 和 Square 的健壮数据管道示例 -> 原文： [http://highscalability.com/blog/2013/1/14/mongodb-and-gridfs-for-inter-and-intra-datacenter-data-repli.html](http://highscalability.com/blog/2013/1/14/mongodb-and-gridfs-for-inter-and-intra-datacenter-data-repli.html) +> 原文： [http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html](http://highscalability.com/blog/2014/3/24/big-small-hot-or-cold-examples-of-robust-data-pipelines-from.html) -![](img/8bf2ff01d2394d7e2b94688b0b76f3d8.png) *这是 LogicMonitor 副总裁 [Jeff Behl](jbehl@logicmonitor.com) 的来宾帖子。 [在过去 20 年中，Jeff](@jeffbehl) 有点过时，他为许多基于 SaaS 的公司设计和监督基础架构。* +[![](img/d95d6fc5fd7b47e48afbe6d9bd2b671b.png)](http://surf.transworld.net/1000104592/features/the-10-best-surf-photos-in-the-history-of-transworld-surf/) -## 用于灾难恢复的数据复制 +*这是 [Hakka Labs](https://twitter.com/petesoder) 的创始人 [Pete Soderling](https://twitter.com/petesoder) 的[访客转发](http://www.hakkalabs.co/articles/big-small-hot-cold-data-needs-robust-pipeline)，创建了软件工程师成长的社区。* -灾难恢复计划的必然部分是确保客户数据存在于多个位置。 对于 LogicMonitor，这是一个基于 SaaS 的物理，虚拟和云环境的监视解决方案，我们希望在数据中心内外都可以复制客户数据文件。 前者用于防止设施中的单个服务器丢失，而后者用于在数据中心完全丢失的情况下进行恢复。 +针对 MongoHQ 最近发表的题为“ [您没有大数据](http://blog.mongohq.com/you-dont-have-big-data/)”的帖子，我通常会同意作者的许多观点。 -## 我们在哪里：Rsync +但是，无论您称其为大数据，小数据，热数据还是冷数据-我们都有能力承认*更多*数据将保留下来-这是由于许多不同的因素造成的。 -像大多数在 Linux 环境下工作的人一样，我们使用了可信赖的朋友 rsync 来复制数据。 +如本文所述，可能主要是由于存储成本随着时间的推移而降低。 其他因素包括对开放 API 的访问，在线上不断增长的消费者活动的数量，以及公司相互“共享”数据时在幕后形成的（主要是）幕后发展的大量其他激励措施。 （您知道[他们这样做](http://www.theguardian.com/business/2013/jun/24/barclays-bank-sell-customer-data)，对吧？） -![](img/5d8418f63b8ea168deb7b0bafc7c4dce.png) +但是，过去两年来我学到的最重要的事情之一是，对于具有远见卓识的公司而言，开始设计更强大的数据管道以收集，汇总和处理不断增长的数据量至关重要。 这样做的主要原因是能够以一致的方式准备好看似神奇的类似量子的操作的数据，这些操作可以推断数据之间的关系，否则这些关系肯定不会引起注意-在引用的文章中巧妙地描述为“ 从针头堆中确定针头的性质。” -Rsync is tried, true and tested, and works well when the number of servers, the amount of data, and the number of files is not horrendous.  When any of these are no longer the case, situations arise, and when the number of rsync jobs needed increases to more than a handful, one is inevitably faced with a number of issues: +但这提出了一个问题-精心设计的数据管道的特征是什么？ 您难道不可以将所有数据都放入 Hadoop 并称之为一天吗？ -* 备份作业重叠 -* 备份作业时间增加 -* 过多的同时作业使服务器或网络超载 -* 完成 rsync 作业后，没有简单的方法来协调所需的其他步骤 -* 没有简便的方法来监视作业计数，作业统计信息并在发生故障时得到警报 +正如许多工程师所发现的那样-答案是巨大的“不！” 我们汇总了 Stripe，Tapad，Etsy & Square 的智能工程师的四个示例，这些示例展示了您实际上可以在野外看到的一些实际数据管道的各个方面。 -Here at LogicMonitor [our philosophy](http://blog.logicmonitor.com/2012/07/17/our-philosophy-of-monitoring/) and reason for being is rooted in the belief that everything in your infrastructure needs to be monitored, so the inability to easily monitor the status of rsync jobs was particularly vexing (and no, we do not believe that emailing job status is monitoring!).  We needed to get better statistics and alerting, both in order to keep track of backup jobs, but also to be able to put some logic into the jobs themselves to prevent issues like too many running simultaneously.The obvious solution was to store this information into a database. A database repository for backup job metadata, where jobs themselves can report their status, and where other backup components can get information in order to coordinate tasks such as removing old jobs, was clearly needed.  It would also enable us to monitor backup job status via simple queries for information such as the number of jobs running (total, and on a per-server basis), the time since the last backup, the size of the backup jobs, etc., etc.    +## **Stripe 如何做到？** -## MongoDB 作为备份作业元数据存储 +我们在 [Stripe](http://www.hakkalabs.co/companies/stripe) 上与 Avi Bryant 进行了交谈，后者为我们很好地描述了 Stripe 进行数据管道构建的方式。 -The type of backup job statistics was more than likely going to evolve over time, so MongoDB came to light with its “[schemaless](http://blog.mongodb.org/post/119945109/why-schemaless)” document store design.  It seemed the perfect fit: easy to setup, easy to query, schemaless, and a simple JSON style structure for storing job information.  As an added bonus, MongoDB replication is excellent:  it is robust and extremely easy to  implement and maintain.  Compared to MySQL, adding members to a MongoDB replica set is auto-magic.So the first idea was to keep using rsync, but track the status of jobs in MongoDB. But it was a kludge to have to wrap all sorts of reporting and querying logic in scripts surrounding rsync.  The backup job metainfo and the actual backed up files were still separate and decoupled, with the metadata in MongoDB and the backed up files residing on a disk on some system (not necessarily the same).  How nice it would be if the the data and the database were combined.  If I could query for a specific backup job, then use the same query language again for an actual backed up file and get it.  If restoring data files was just a simple query away...  [Enter GridFS](http://docs.mongodb.org/manual/applications/gridfs/). +> Stripe 从各种来源向 HDFS 馈送数据，其中许多是非结构化或半结构化的 +> -例如服务器日志或 JSON +> 和 BSON 文档。 在每种情况下，第一步都是将 +> 转换为结构化格式。 我们已经标准化了使用 Thrift 来定义 +> 的逻辑结构，并使用 Parquet 作为磁盘上的存储 +> 格式。 +> +> 我们选择 Parquet 是因为它是 Cloudera Impala 查询引擎固有的高效列格式 +> ， +> 使我们可以快速关联数据访问临时报告。 +> Parquet 和 Thrift 的组合也可以有效地使用，并且 +> 可以从 Twitter 的 Scalding 框架中惯用，这是我们为复杂批处理选择的 +> 工具。 +> +> 下一阶段是``非规范化''：为了保持我们的分析工作和 +> 查询快速，我们会在 Scalding 中提前进行最常见的联接， +> 写入新的 Thrift 模式集。 同时，我们进行了大量的 +> 增强和注释数据：例如，对 IP +> 地址进行地理编码，解析用户代理字符串或清除丢失的值。 +> +> 在许多情况下，这会导致结构具有嵌套结构， +> 在 Scalding 中效果很好，并且哪个 Parquet 很高兴存储，但是 +> 目前 Impala 无法查询。 我们开发了一个简单的工具 +> ，该工具可将任意嵌套的 Parquet 数据转换为等效的 +> 扁平化架构，并在必要时使用它来 +> 维护每个数据源的并行副本以供 Impala 使用。 +> 我们期待着 Impala 的未来版本，该版本可能会删除 +> 这个额外的步骤。 -## 为什么选择 GridFS +## **Tapad 的数据管道** -You can read up on the details GridFS on the MongoDB site, but suffice it to say it is a simple file system overlay on top of MongoDB (files are simply chunked up and stored in the same manner that all documents are).  Instead of having scripts surround rsync, our backup scripts store the data and the metadata at the same time and into the same place, so everything is easily queried. +[Tapad](http://www.hakkalabs.co/companies/tapad) 是纽约市的一家广告技术公司，在过去几年中，其流量和数据均实现了大幅增长。 因此，我联系了他们的 CTO [Dag Liodden](http://www.hakkalabs.co/engineers/dag-liodden) ，以了解他们如何构建数据管道以及他们使用的一些策略和工具。 用达格的话来说，这是他们的做法： -当然，MongoDB 复制可与 GridFS 一起使用，这意味着备份的文件可立即在数据中心内和异地复制。 通过 Amazon EC2 内部的副本，可以拍摄快照以保留所需的尽可能多的历史备份。 现在，我们的设置如下所示： +* 所有摄取的数据都以 pub-sub 方式流过消息队列（我们使用 Kafka 并每小时通过它推送多个 TB 数据） +* 所有数据均使用支持架构演进的一致的非规范化架构进行编码（我们使用 Avro 和 Protocol Buffers） +* 我们的大多数数据存储都从消耗消息队列的流程进行实时更新（将热数据推送到 Aerospike 和 Cassandra，将实时可查询的数据推送到 Vertica，并且原始事件通常存储有来自 Aerospike 集群的数据， 在 HDFS 中） +* 高级分析和数据科学计算通常在 HDFS 中对非规范化数据执行 +* 实时更新始终可以通过脱机批处理作业复制到 HDFS 存储的数据上。 我们努力使我们的计算逻辑，使其可以在流中*和*以批处理 MR 模式运行，而无需进行任何修改 -![](img/3c3ccfd357f047d89266ff1df34f8b30.png) +他指出，最后一点使他们可以随意更改其流计算，然后用更新的预测回填其他数据存储。 -优点 +Dag 还解释了在存储方面使用多种类型的数据技术背后的“原因”，并解释了它们中的每一个都有其自己的特定“最佳位置”，这使其对它们具有吸引力： -* 作业状态信息可通过简单查询获得 -* 备份作业本身（包括文件）可以通过查询检索和删除 -* 复制到异地位置实际上是立即的 -* 分片可能 -* 借助 EBS 卷，通过快照进行 MongoDB 备份（元数据和实际备份数据）既简单又无限 -* 自动化状态监控很容易 +* Kafka：高吞吐量并行发布订阅，但宽松的传递和延迟保证，有限的数据保留和无查询功能。 +* Aerospike：按键（我们拥有 32 亿个键和 4TB 复制数据），跨数据中心复制，高可用性但查询功能非常有限，按键具有极快的随机访问读/写性能 +* Cassandra：中等的随机访问读/写性能，原子计数器和数据模型，非常适合时间序列存储。 灵活的一致性模型和跨数据中心复制。 +* HDFS：高吞吐量和廉价的存储。 +* Vertica：快速和强大的即席查询功能，用于交互式分析，高可用性，但不支持嵌套的数据结构，多值属性。 基于存储的定价使我们限制了我们在此处放置的数据量。” -## 通过 LogicMonitor 进行监控 +## **Etsy 如何处理数据** -LogicMonitor 认为，从物理级别到应用程序级别的基础架构的所有方面都应位于同一监视系统中：UPS，机箱温度，OS 统计信息，数据库统计信息，负载平衡器，缓存层，JMX 统计信息，磁盘 写入延迟等）。所有都应该存在，其中包括备份。 为此，LogicMonitor 不仅可以监视 MongoDB 的常规统计信息和运行状况，还可以对 MongoDB 执行任意查询。 这些查询可以查询任何内容，从登录静态信息到页面视图，再到最后一个小时内完成的（猜测是什么？）备份作业。 +再举一个例子，我们联系了 [Etsy 的](http://www.hakkalabs.co/companies/etsy)数据团队的工程经理 Rafe Colburn，并询问他们如何处理他们的管道。 这是 Rafe 的独家新闻： -Now that our backups are all done via MongoDB, I  can keep track of (and more importantly, be alerted on): +> Etsy 的分析渠道不是特别线性。 它从我们的工具开始，它由一个事件记录器组成，该事件记录器在浏览器中运行，而另一个事件记录器可以从后端调用。 两者都 ping 一些内部“信标”服务器。 +> +> 实际上，我们使用良好的旧 logrotate 程序将生成的 Apache 访问日志在达到一定大小时运送到 HDFS，并使用 Hadoop 处理它们。 我们还将每晚对生产数据（驻留在 MySQL 中）进行快照，并将其复制到 HDFS 中，以便我们可以将点击流数据添加到事务数据中。 +> +> 通常，我们会将 Hadoop 作业的输出发送到 Vertica 数据仓库，在该仓库中我们也复制生产数据，以进行进一步分析。 我们使用这些数据来提供我们自己的报告和分析工具。 +> +> 对于 [etsy.com](http://etsy.com/) 上使用从 Hadoop 作业生成的数据的功能，我们有一个自定义工具，该工具获取作业的输出并将其存储在分片的 MySQL 集群中，可以在该集群上进行大规模访问。 今年，我们正在考虑将 Kafka 集成到管道中，以将数据从我们的工具移至 Hadoop（以及流分析工具），并将数据从我们的分析平台发送回公共站点。 -* 每台服务器运行的备份作业数 -* 所有服务器之间同时执行的备份数 -* 任何未备份超过 6 个小时的客户门户 -* MongoDB 复制滞后 +## **Square 的方法** -### 复制滞后 +拥有复杂数据管道的公司的另一个示例是 [Square](http://www.hakkalabs.co/companies/square) 。 我们与他们的工程经理之一 [Pascal-Louis Perez](http://www.hakkalabs.co/engineers/pascal-louis-perez) 取得了联系，他们为我们提供了他们的管道架构的战略视图。 -![](img/5a3a770e6603b39a268e7856bbd86972.png) +由于支付在整个系统中的重要性，Square 已在整个数据管道中扩展了“对帐”的概念； 每个转换数据必须能够被审核和验证。 据 Pascal 称，这种方法的主要问题在于扩展规模可能具有挑战性。 对于收到的每笔付款，“大约需要 10 到 15 个会计分录，对帐系统的规模因此必须比处理的帐目规模大一个数量级，而处理的帐目已经非常大。” -### 工作完成 +Square 解决此问题的方法利用流处理，这使他们可以将相应的数据域映射到不同的流。 用 Pascal 的话来说，“流表示将数据流水线与数据源的多样性区分开的第一层抽象。下一层是将多个流之一组合在一起并产生一个或多个流的运算符。一个示例运算符是” “匹配器”，它接收两个流，从中提取相似种类的密钥，并根据匹配条件产生两个流。 -![](img/501c0f8d17f23d06dd79c7855378d1ad.png) +Pascal 指出，流处理和基于流的运算符的系统类似于关系代数及其运算符，但是在这种情况下，它是实时的并且具有无限关系。 -您是否正在使用保险丝访问 GridFS，或者是否正在根据 API 编写所有代码？ \ No newline at end of file +很明显，将数据塞入 Hadoop 并不会为您提供这些功能！ + +有趣的例子特别时髦。 在前端，您会看到艺术家和手工艺人像在线公开市场一样出售其商品。 可以很好地了解后端的工作方式。 + +这是一个非常有用的技术概述，它对我来说是个新名词-数据管道如何工作。 我最近一直在使用 [TitanDB](http://thinkaurelius.github.io/titan/ "TitanDB") 和 hbase 来处理图形方面，您可以在此处阅读[，尽管它不是真实的示例。](http://tjadclark.com/blog/article/11-big-data-putting-it-in-a-graph "Big data in a graph") + +看到在现实世界中有使用 HBase 的用例，这使我对将来使用 HBase 的决策更有信心。 \ No newline at end of file diff --git a/docs/139.md b/docs/139.md index 9ad076b..a76d0b5 100644 --- a/docs/139.md +++ b/docs/139.md @@ -1,139 +1,301 @@ -# 分析数十亿笔信用卡交易并在云中提供低延迟的见解 +# WhatsApp 如何每秒吸引近 5 亿用户，11,000 内核和 7,000 万条消息 -> 原文： [http://highscalability.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html](http://highscalability.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html) +> 原文： [http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html](http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html) -![](img/99cc6b2427bd4e7b9d56427444015cb7.png) +![](img/6ed8bd179e354645ecb9c3ffe096b700.png) -*这是 [Ivan de Prado](http://www.linkedin.com/in/ivanprado) 和 [Pere Ferrera](http://www.linkedin.com/in/pedroferrera) 的来宾帖子， [Datasalt](http://www.datasalt.com) 的创始人， [Pangool](http://pangool.net) 和 [Splout SQL](http://sploutsql.com) 大数据开源项目。* +上次[访问 WhatsApp](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) 时，他们刚刚被 Facebook 以 190 亿美元的价格收购。 我们了解了他们的早期体系结构，该体系结构主要集中于优化 Erlang，以处理服务器上的 200 万个连接，使用 All The Phones 并通过简单性使用户满意。 -使用信用卡支付的金额巨大。 显然，可以通过分析所有交易得出数据中的内在价值。 客户忠诚度，人口统计，活动热点图，商店推荐以及许多其他统计数据对于改善客户与商店之间的关系都非常有用。 在 [Datasalt](http://www.datasalt.com) ，我们与 [BBVA 库](http://www.bbva.com)合作开发了一个系统，该系统能够分析多年的数据并为不同的低延迟 Web 和移动应用程序提供见解和统计信息。 +两年后，流量增长了 10 倍。 WhatsApp 如何使它跃升到新的可扩展性水平？ -除了处理大数据输入外，我们面临的主要挑战是**的输出也是大数据，甚至比输入**还大。 并且此输出需要在高负载下快速提供服务。 +[Rick Reed](http://www.linkedin.com/pub/rick-reed/2/186/427) 在 Erlang 工厂的一次演讲中告诉我们： [这是“十亿”，带有“ B”： WhatsApp 的下一个级别](https://www.youtube.com/watch?v=c12cYAUTXXs) （ [幻灯片](https://github.com/reedr/reedr/blob/master/slides/efsf2014-whatsapp-scaling.pdf) ），这显示了 WhatsApp 的统计数据： -由于使用了[云（AWS）](http://aws.amazon.com)， [Hadoop](http://hadoop.apache.org/) 和 [Voldemort](http://www.project-voldemort.com/voldemort/) ，我们开发的解决方案每月的基础设施成本仅为数千美元。 在下面的几行中，我们将解释所提出的体系结构的主要特征。 +> 拥有数百个节点，数千个内核，数百 TB 的 RAM 的东西，并希望为不久将在全球范围内成为现实的数十亿智能手机提供服务？ WhatsApp 上基于 Erlang / FreeBSD 的服务器基础结构。 在满足对消息传递服务不断增长的需求方面，我们面临着许多挑战，但是随着我们不断扩大服务范围（> 8000 核）和速度（>每秒 70M Erlang 消息）， 系统。 -## 数据，目标和首要决策 +与两年前相比，最显着的变化是什么？ -该系统使用 BBVA 在世界各地的商店中进行的信用卡交易作为分析的输入源。 显然，数据是匿名的，非个人的，并且可以进行隔离以防止任何隐私问题。 信用卡号被散列。 任何产生的见解始终是汇总，因此无法从中获得任何个人信息。 +* 显然，除了工程师数量之外，每个维度都更大。 更多的盒子，更多的数据中心，更多的内存，更多的用户以及更多的扩展问题。 Rick 最引以为傲的是，用很少的工程师来处理这种增长水平：每个工程师 4000 万用户。 这是云计算胜利的一部分。 他们的工程师在他们的软件上工作。 网络，硬件和数据中心由其他人处理。 -我们为每个商店和不同时间段计算许多统计数据和数据。 这些是其中一些： +* 由于需要有足够的头部空间来处理每个盒子上增加的总体负载，因此他们放弃了尝试为每个盒子尽可能多地支持连接。 尽管他们通过增加大型机箱并在 SMP 机器上高效运行来降低管理开销的一般策略仍然保持不变。 -* 每个商店的付款金额直方图 -* 客户保真 -* 客户人口统计 -* 店铺推荐（在这里购买的客户也可以在...购买）。 按位置，商店类别等过滤。 +* 瞬态很好。 如今，多媒体，图片，文本，语音，视频已成为其体系结构的一部分，而不必长期存储所有这些资产，极大地简化了系统。 该体系结构可以围绕吞吐量，缓存和分区展开。 -该项目的主要目标是通过低延迟的 Web 和移动应用程序向所有代理（商店，客户）提供所有这些信息。 因此，一项苛刻的要求是能够在高负载下以亚秒级的延迟提供结果。 由于这是一个研究项目，因此需要处理代码和要求方面的高度灵活性。 +* Erlang 是它自己的世界。 听了这个谈话，很清楚您在 Erlang 的世界观中所做的一切都多少，这可能会令人迷惑。 尽管最终是一个分布式系统，所有问题都与其他任何分布式系统相同。 -因为一天仅更新数据不是问题，所以我们选择了面向批处理的架构（Hadoop）。 我们选择 Voldemort 作为只读存储来提供 Hadoop 生成的见解，这是一个简单但超快速的键/值存储，可以与 Hadoop 很好地集成。 +* Erlang 数据库 Mnesia 似乎是造成大规模问题的重要原因。 这让我想知道是否还有其他一些数据库可能更合适，是否需要留在 Erlang 解决方案系列中是否会有点盲目呢？ -## 该平台 +* 您可能会想到很多与规模有关的问题。 不稳定的连接问题，队列太长以至于它们会延迟高优先级的操作，定时器的抖动，在一种流量级别上正常工作的代码在较高流量级别上严重中断，高负载下的高优先级消息无法得到服务，阻塞其他操作的问题 意外的方式，导致资源问题的故障等等。 无论您使用什么系统，这些事情都会发生，并且必须通过它们来解决。 -该系统基于 [Amazon Web Services](http://aws.amazon.com/) 构建。 具体来说，我们使用 S3 存储原始输入数据，使用 Elastic Map Reduce（亚马逊提供的 Hadoop）进行分析，并使用 EC2 提供结果。 使用云技术使我们能够快速迭代并快速交付功能原型，这正是我们这类项目所需的。 +* 我对 Rick 跟踪并修复问题的能力感到震惊和惊讶。 非常令人印象深刻。 -## 架构 +瑞克总是讲好话。 他非常慷慨地提供具体细节，这些细节显然直接来自生产中遇到的问题。 这是我对他的讲话的掩饰… -![](img/1e99350f5920f4f713d11ef7c9d510e4.png) +## 统计信息 -该体系结构包含三个主要部分： +* 每月有 4.65 亿用户。 -* **数据存储**：用于维护原始数据（信用卡交易）和生成的 Voldemort 存储。 -* **数据处理**：在 EMR 上运行的 Hadoop 工作流，执行所有计算并创建 Voldemort 所需的数据存储。 -* **数据服务**：Voldemort 群集，用于服务来自数据处理层的预先计算的数据。 +* 每天& 40B 中有 19B 条消息 -银行每天都将当天发生的所有交易上载到 S3 中的文件夹中。 这使我们能够保留所有历史数据-每天执行的所有信用卡交易。 所有这些数据都是处理层的输入，因此我们**每天都重新计算所有内容**。 重新处理所有数据可以使我们变得非常敏捷。 如果需求发生变化或发现一个愚蠢的错误，我们只需更新项目代码，并在下一批之后修复所有数据。 这是一项发展决定，为我们带来了： +* 600M 图片，2 亿语音，1 亿视频 -* 简化的代码库&架构， -* 灵活性&适应变化， -* 轻松处理人为错误（只需修复错误并重新启动过程）。 +* 147M 高峰并发连接-手机已连接到系统 -每天一次，控制器在 EMR 上启动新的 Hadoop 集群并启动处理流程。 此流程由大约 16 个[元组 MapReduce 作业](http://www.datasalt.com/2012/02/tuple-mapreduce-beyond-the-classic-mapreduce/)组成，这些作业计算各种洞察力。 流的最后一部分（Voldemort 索引器）负责构建数据存储文件，该文件随后将部署到 Voldemort。 流程完成后，结果数据存储文件将上传到 S3。 控制器关闭 Hadoop 集群，然后将部署请求发送到 Voldemort。 然后，Voldemort 从 S3 下载新的数据存储并执行热交换，完全替换旧的数据。 +* 230K 高峰登录/秒-电话连接和断开连接 -## 技术 +* 342K 峰值 msgs in / sec，712K 峰值 -### Hadoop 和 Pangool +* 大约有 10 位团队成员在 Erlang 上工作，他们既处理开发工作，又处理操作。 -整个分析和处理流程是使用 Hadoop 之上的 [Pangool Jobs](http://pangool.net) 实现的。 这使我们在性能，灵活性和敏捷性之间取得了良好的平衡。 元组的使用使我们能够使用简单的数据类型（int，字符串）在流之间传递信息，同时我们还可以将其他复杂的对象（如直方图）包含在其自己的自定义序列化中。 +* 假期多媒体使用率最高。 -另外，由于 Pangool 仍然是低级 API，因此我们可以在需要时对每个 Job 进行很多微调。 + * 输出 146Gb / s（圣诞节前夕），电话的带宽相当大 -### 伏地魔 + * 已下载 360M 视频（圣诞节偶数） -![](img/1ebd61748cea4343d7797358d63067a3.png) [Voldemort](http://www.project-voldemort.com/voldemort/) 是 LinkedIn 基于 [Amazon Dynamo](http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html) 概念开发的键/值 NoSql 数据库。 + * 已下载 2B 张图片（46k / s）（除夕） -Voldemort 背后的主要思想是将数据分成多个块。 每个块都被复制并在 Voldemort 群集的节点中提供服务。 每个 Voldemort 守护程序都可以将查询路由到保留特定键值的节点。 Voldemort 支持快速读取和随机写入，但是对于此项目，我们将 Voldemort 用作只读数据存储区，在每次批处理之后替换所有数据块。 因为数据存储是由 Hadoop 预先生成的，所以查询服务不受部署过程的影响。 这是使用这种只读批处理方法的优点之一。 我们还具有灵活性，可以在需要时更改集群拓扑并重新平衡数据。 + * 1 张图片已下载 3200 万次（除夕） -Voldemort 提供了一个 Hadoop MapReduce 作业，该作业在分布式集群中创建数据存储。 每个数据块只是一个 [Berkeley DB](http://www.oracle.com/technetwork/products/berkeleydb/overview/index-093405.html) [B 树](http://en.wikipedia.org/wiki/B-tree)。 +## 堆栈 -Voldemort 的接口是 TCP，但我们想使用 HTTP 服务数据。 VServ 是一个简单的 HTTP 服务器，它将传入的 HTTP 请求转换为 Voldemort TCP 请求。 负载平衡器负责在所有 VServ 之间共享查询。 +* Erlang R16B01（加上自己的补丁） -## 计算数据 +* FreeBSD 9.2 -### 统计 +* Mnesia（数据库） -分析的一部分在于计算简单的统计信息：平均值，最大值，最小值，标准偏差，唯一计数等。它们是使用众所周知的 MapReduce 方法实现的。 但是我们也计算一些直方图。 为了在 Hadoop 中有效地实现它们，我们创建了一个自定义直方图，该直方图只能通过一次计算。 而且，我们可以在一个 MapReduce 步骤中，在任意数量的时间段内，为每个商务计算所有简单的统计数据以及相关的直方图。 +* 偏航 -为了减少直方图使用的存储量并改善其可视化效果，将由许多分箱组成的原始计算出的直方图转换为可变宽度的分箱直方图。 下图显示了特定直方图的 3 槽最佳直方图： +* SoftLayer 是他们的云提供商，裸机，网络内相当隔离的双数据中心配置 -![](img/779804f408b769317f66c7adeabf68c9.png) +## 硬件 -使用[随机重启爬山](http://en.wikipedia.org/wiki/Hill_climbing)近似算法计算出最佳直方图。 下图显示了每次爬山迭代中可能的移动： +* 〜550 个服务器+备用设备 -![](img/98213b36ae6dffee5c9e390d629df3f5.png) + * 约 150 个聊天服务器（每个约 100 万个电话，1.5 亿个高峰连接） -该算法已被证明非常快速和准确：与精确的动态算法（由[本文](http://cosco.hiit.fi/Articles/aistat07.pdf)实现）相比，我们达到了 99％的精度，速度提高了一个因子。 + * 〜250 毫米（多媒体）服务器 -### 商业建议 + * 2x2690v2 Ivy Bridge 10 核（超线程总共 40 个线程） -推荐使用共现进行计算。 也就是说，**如果有人在商店 A 和 B 中都购买了商品，则存在 A 和 B 之间的同现**。 即使购买者在 A 和 B 都购买了几次，也仅考虑一次共现。给定商店的顶级共同商店是该商店的推荐。 + * 数据库节点具有 512GB 的 RAM -但是需要对共现这一简单概念进行一些改进。 首先，因为几乎每个人都在其中购物，所以通过简单的降频来过滤掉最受欢迎的商店。 因此，推荐它们没有任何价值。 按位置（商店彼此靠近），商店类别或两者过滤推荐也可以改善推荐。 与“总是真实的”建议相比，基于时间的同现产生了更热烈的建议。 限制共现的时间会导致人们建议在第一次购买后立即购买的商店。 + * 标准计算节点具有 64GB RAM -Hadoop 和 Pangool 是计算共现并生成建议的理想工具，尽管有些挑战并不容易克服。 特别是，如果一个买家在许多商店付款，则此信用通知的同现次数将显示二次增长，从而使分析不能线性扩展。 因为这种情况很少见，所以我们只考虑每张卡的并发数量，只考虑购买者购买最多的那些卡。 + * SSD 主要用于可靠性，但由于需要更多存储空间而存储视频时除外 -## 成本&一些数字 + * 双链路 GigE x2（面向用户的公共&面向后端系统的私有） -BBVA 在西班牙进行的一年信用卡交易在 Voldemort 上提供的信息量为 270 GB。 整个处理流程将在 24 个“ m1.large”实例的群集上运行 11 小时。 整个基础设施，包括为生成的数据提供服务所需的 EC2 实例，每月费用约为 3500 美元。 +* > 11,000 个内核运行 Erlang 系统 -仍有优化的空间。 但是考虑到该解决方案敏捷，灵活且可在云中运行，价格相当合理。 在内部基础架构中运行的系统的成本将便宜得多。 +## 系统概述 -## 结论&的未来 +* 二郎的爱。 -由于使用了 Hadoop，Amazon Web Services 和 NoSQL 数据库等技术，因此可以快速开发可扩展，灵活的解决方案，并准备以合理的成本承受人为的失败。 + * 很棒的语言，只用很少的工程师就能支持这么多的用户。 -未来的工作将涉及用 [Splout SQL](http://sploutsql.com) 代替 Voldemort，它允许部署 Hadoop 生成的数据集，并将低延迟键/值扩展到低延迟 SQL。 由于可以“即时”执行许多聚合，因此可以减少分析时间并减少数据量。 例如，它将允许在任意时间段内汇总统计信息，而这是无法预先计算的。 + * 强大的 SMP 可扩展性。 可以运行非常大的盒子并保持较低的节点数。 操作复杂性随节点数（而不是核心数）而定。 -在“ LinkedIn 开发的键/值 NoSql 数据库”之后，我停止阅读 + * 可以即时更新代码。 -对那些什至不知道如何添加用户密码哈希的白痴都不感兴趣。 +* 可扩展性就像清除雷区。 他们通常能够在爆炸之前发现并清除问题。 测试系统的事件是世界性事件，尤其是足球，这会产生较大的垂直负载峰值。 服务器故障，通常是 RAM。 网络故障。 和不良的软件推动。 -这是一个令人困惑的描述，并且体系结构似乎布局/解释不当。 另外，如何处理节点故障？ +* 传统外观架构： -回答“ dev”的评论：EMR 下的节点故障由 Amazon 透明处理，而 Voldemort 群集中的节点故障由 Voldemort 的故障转移功能处理。 我们只需要指定所需的复制因子，就可以相应地部署数据块。 + * 电话（客户端）连接到聊天和 MMS（多媒体）。 -随意问您可能感兴趣的其他问题，并且您认为这些解释不够充分。 + * 聊天连接到瞬时离线存储。 后端系统在用户之间传递消息时会保留它们。 -感谢 Ivan 和 Pere，这非常有趣！ 我有一个快速的问题。 270 GB 的数据集并不是很大，并且由于您最终要使用 HTTP，所以我想知道是什么导致您选择 Voldermort 而不是像 Sofadb 这样的东西？ 我也对 Splout（您似乎是内部开发的）感到好奇。 在给定数据量的情况下，这似乎代表了相当大的工程努力-您能解释一下 Splout 在此特定用例与（敢于说）分片 RDBMS 的优势吗？ 非常感谢！ + * 聊天连接到数据库，例如帐户，个人资料，推送，群组等。 -嗨斯蒂芬，谢谢你的评论和问题。 我们选择 Voldemort 的原因有三个：速度，简单性以及与 Hadoop 的良好集成。 我们认为很少有数据库可以有效地从 Hadoop 提取数据。 我们对那些其数据结构可以由 Hadoop 预先生成并且可以以全有或全无的方式部署 Hadoop 文件且不影响查询服务的数据库感兴趣。 这为系统增加了安全层，并使后端与前端完全脱开。 反过来，这使体系结构更简单，从而消除了在处理和服务之间逐渐增加流状态的需要。 +* 发给手机的消息： -ElephantDB 是另一个可以满足这些要求并且可以选择的数据库，但是我们以前在 Voldemort 方面已有过积极的经验。 + * 实际短信 -我不确定您的问题是否更像我们是否可以使用以 CouchDB 为中心的系统来替代 Hadoop + Voldemort。 如果真是这样，我们目前没有足够的 CouchDB 经验来判断这是否是一个有趣的选择。 + * 通知：小组主题，个人资料照片更改等 -关于 Splout SQL，实际上您实际上可以将其视为分片的 RDBMS，但它是只读的，并且与 Hadoop 紧密集成，这正是我们所需要的。 通过成为只读文件，它实际上比传统的 RDBMS 变得更易于管理，并且通过将其与 Hadoop 集成，我们使应用程序能够轻松，安全地将数据从处理过程转移到服务过程中，而这正是我上面提到的所有好处。 + * 存在消息：键入，空闲，已连接/未连接等 -关于数据大小，请考虑到 270 GB 仅是西班牙的一年数据，但是该应用程序可能会服务数年和多个国家/地区的数据。 此外，由于需求变化很快，因此输出幅度仍然未知，因为每次添加新功能时输出幅度可能都会增加。 +* 多媒体数据库： -希望这能回答您的问题，否则请随时提出。 + * 内存中 [Mnesia 数据库](http://www.erlang.org/doc/man/mnesia.html) 使用大约 2TB 的 RAM 在 16 个分区上分片，以存储约 180 亿条记录。 -谢谢 Pere，这很有道理-我现在意识到 Splout 或 ElephantDB 的优点是不必通过 MR 对初始数据存储进行处理，然后再将 ETL 转换为需要自己维护和明显的性能优势的单独存储 是只读+（我想）要维护的代码库较小（显然 Elephant 是 2k LoC！）。 干杯! + * 消息和多媒体仅在传递时存储，而在传递媒体时，有关媒体的信息存储在数据库中。 -这是一个有趣的问题，但我只是希望对它进行更多的解释。 +* 每台服务器的连接数为 100 万，而不是两年前的每台服务器 200 万的连接数，通常是因为服务器繁忙得多： -使用这种类型的数据时（除规模之外），您遇到的最困难的事情是什么？ + * 随着更多的用户，他们希望在每台服务器上以更多的净空运行，以吸收峰值负载。 -我自己花了 10 多年的时间分析信贷/借记数据，我很好奇:) + * 用户比两年前更加活跃。 他们正在发送更多消息，因此服务器正在执行更多操作。 -谢谢 -Jon Wren \ No newline at end of file + * 这些服务器之外的功能已移至它们上运行，因此它们可以做更多的事情。 + +## 去耦 + +* 隔离瓶颈，使它们不会在系统中传播 + + * 紧密耦合会导致级联故障。 + + * 堆栈中较深的后端系统不应冒充前端。 + + * 所有内容均已分区，因此，如果一个分区出现问题，其他分区将不会受到影响。 + + * 解决问题时，请保持尽可能多的吞吐量。 + +* 异步性可最大程度地减少延迟对吞吐量的影响 + + * 即使在系统中的各个点存在等待时间或等待时间无法预测时，也可以保持尽可能高的吞吐量。 + + * 减少耦合，并使系统尽可能快地工作。 + +* 避免 [行头阻塞](http://en.wikipedia.org/wiki/Head-of-line_blocking) + + * 行头块是在队列中对第一个数据包进行处理而使在其后排队的所有那些项目饿死的地方。 + + * 分离的读写队列。 特别是在表上执行事务的地方，因此，如果在写侧存在任何延迟，则不会阻塞读侧。 通常，读取端的运行速度要快得多，因此任何阻塞都会堆积读取器。 + + * 单独的节点间队列。 如果某个节点或连接节点的网络出现故障，则可能会阻止应用程序中的工作。 因此，当将消息发送到不同的节点时，会将消息传递给不同的 [进程](http://www.erlang.org/doc/reference_manual/processes.html) （Erlang 中的轻量级并发），因此仅备份发往问题节点的消息。 这允许发送到健康节点的消息自由流动。 问题被隔离到问题所在。 修补的 mnesia 在 async_dirty 复制时可以很好地做到这一点。 发送消息的应用程序与发送程序是分离的，并且如果节点出现问题，则不会感到任何背压。 + + * 当使用不确定的延迟时，使用“队列” FIFO 工作程序分配模型。 + +* 元集群 + + * 请注意，本节仅在演讲开始约 29 分钟时进行，非常简短，很不幸。 + + * 需要一种方法来包含单个群集的大小，并允许其跨越很长的距离。 + + * 构建了 wandist，这是 gen_tcp 上类似 dist 的传输，它由需要相互通信的节点的网格组成。 + + * pg2 之上的透明路由层创建了一个单跳路由调度系统。 + + * 示例：两个数据中心中的两个主要群集，两个不同数据中心中的两个多媒体群集，以及两个数据中心之间的共享全局群集。 它们之间都有广电连接。 + +* 示例： + + * 通过使用 async_dirty 避免进行 Mnesia 事务耦合。 大多数交易未使用。 + + * 仅在从数据库取回时使用调用，否则将强制转换所有内容以保留异步操作模式。 在 Erlang 中，handle_call 会阻止响应，并且消息已排队，而 handle_cast 不会阻止，因为操作结果无关紧要。 + + * 呼叫使用超时，而不是监控器。 减少远端 proc 上的竞争，并减少分发渠道上的流量。 + + * 当只需要尽力而为时，请在演员表上使用 nosuspend。 如果一个节点有问题或网络有问题，这会将一个节点与下游问题隔离开，在这种情况下，分发缓冲区会在发送节点上备份，并且尝试发送的 proc 会被调度程序挂起，从而导致级联失败，每个人 正在等待，但尚未完成任何工作。 + + * 使用大型分配缓冲区来吸收网络和下游节点中的问题。 + +## 并行化 + +* 工作分配： + + * 需要分配超过 11,000 个核心的工作。 + + * 从单线程 [gen_server](http://www.erlang.org/doc/man/gen_server.html) 开始。 然后创建一个 gen_factory 以将工作分散到多个工作人员。 + + * 在一定的负载下，调度过程本身成为了瓶颈，而不仅仅是执行时间。 繁琐的操作使许多节点进入了盒子的调度过程，过程的锁定成为分配端口和过程本身进入的瓶颈。 + + * 如此创建了 gen_industry，位于 gen_factory 之上的一层，因此有多个调度过程，允许对进入包装盒的所有输入以及对工人本身的调度进行并行化。 + + * 通过一个键选择工作程序进行数据库操作。 对于 IO 等不确定的延迟情况，使用 FIFO 模型分配工作量以防止行首阻塞问题。 + +* 分区服务： + + * 在 2 到 32 种方式之间进行分区。 大多数服务是按 32 种方式分区的。 + + * [pg2 寻址](http://erlang.org/doc/man/pg2.html) ，它们是分布式进程组，用于寻址整个群集中的分区。 + + * 节点成对运行。 一个是小学，另一个是中学。 如果一个或另一个发生故障，它们将处理主要和次要流量。 + + * 通常尝试将访问单个 [集合](http://www.erlang.org/doc/man/ets.html) （内置术语存储）或单个记忆缺失片段的进程数限制为 8。 锁争用在控制之下。 + +* Mnesia： + + * 因为他们不使用事务来获得尽可能高的一致性，所以他们通过哈希将对单个节点上单个进程的记录的访问序列化。 哈希到一个分区，该分区映射到 [记忆缺失片段](http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html) ，最终被分派到一个工厂，一个工人中。 因此，对单个记录的所有访问都将进入单个 erlang 进程。 + + * 每个记忆缺失片段仅在一个节点上的应用程序级别被写入或读取，这使得复制流只能在一个方向上进行。 + + * 当同级之间存在复制流时，片段更新的速度会遇到瓶颈。 他们修补 OTP，以使多个事务管理器仅针对 async_dirty 运行，因此记录更新并行发生，从而提供了更多的复制吞吐量。 + + * 修补程序，用于将 mnesia 库目录拆分为多个库，这意味着可以将其写入多个驱动器，从而增加了磁盘的吞吐量。 真正的问题是何时从对等方加载了失忆症。 将 IO 分散在多个驱动器（甚至是 SSD）上，就数据库加载速度而言，提供了更大的可伸缩性。 + + * 将记忆缺失的岛屿缩小到每个岛屿的两个节点。 岛屿是记忆障碍的群集。 即使有 32 个分区，也将有 16 个支持一个表的岛。 由于只有两个节点需要完成架构操作，因此有更好的机会在负载下支持架构操作。 如果尝试同时启动一个或两个节点，则减少了加载时间协调。 + + * 通过快速警报来处理 Mnesia 中的网络分区。 他们继续运行。 然后进行手动对帐，以将它们合并在一起。 + +## 优化 + +* 离线存储系统曾经是负载高峰期间的一个大瓶颈。 只是无法将内容快速推入文件系统。 + + * 用户可以快速读取大多数邮件，例如 60 秒内可以读取 50％。 + + * 添加了回写缓存​​，因此可以在必须将消息写入文件系统之前将其传递。 98％的缓存命中率。 + + * 如果由于负载而备份了 IO 系统，则在 IO 系统追赶时，缓存会提供额外的缓冲以全速传输消息。 + +* 通过将 BEAM（Erlang VM）打补丁到所有异步工作线程中的循环文件端口请求，从而解决了异步文件 IO 中的行头阻塞问题，该问题在出现大邮箱或慢速磁盘的情况下可简化写操作 。 + +* 将大型邮箱保留在缓存之外。 有些人处于大量群组中，每小时收到数千封邮件。 他们污染了缓存并放慢了速度。 从缓存中逐出它们。 请注意，处理不成比例的大型用户是每个系统（包括 Twitter ）的问题。 + +* 缓慢访问带有很多碎片的失忆表 + + * 帐户表分为 512 个片段，这些片段被划分为多个孤岛，这意味着用户到这 512 个片段的稀疏映射。 大多数片段将是空的和空闲的。 + + * 主机数量加倍导致吞吐量下降。 事实证明，记录访问的速度确实很慢，因为当目标为 7 时，哈希链的大小超过了 2K。 + + * 发生的是散列方案导致创建了大量的空存储桶，而很少的存储桶非常长。 两行更改将性能提高了 4 比 1。 + +## 修补 + +* 争夺计时器轮。 在一台主机中有几百万个连接，并且每当特定电话发生任何事情时，每个连接都在设置和重置计时器，因此，结果是每秒成千上万个计时器设置和重置。 一个计时器轮和一个锁，这是一个重要的竞争来源。 解决方案是创建多个计时器轮以消除竞争。 + +* mnesia_tm 是一个很大的选择循环，在尝试加载表时，由于选择接收，积压可能会导致无法返回的点。 修补程序将物料从传入的事务流中拉出并保存以供以后处理。 + +* 添加多个 mnesia_tm async_dirty 发件人。 + +* 为 prim_file 命令添加标记/设置。 + +* 有些星团横跨整个大陆，因此，健忘症应该从附近的节点而不是整个国家/地区加载。 + +* 为异步文件 IO 添加循环调度。 + +* 种子和哈希散列以破坏与 phash2 的重合。 + +* 优化主要/名称表的比例。 + +* 如果已经遗失，请不要将其遗忘在队列中。 无法完成具有待处理的转储的架构操作，因此如果排队了很多转储，则无法进行架构操作。 + +## 2/22 中断 + +* 即使所有这些工作都发生了。 它发生在最坏的时间，在 Facebook 收购之后，发生了 210 分钟的中断[。](http://techcrunch.com/2014/02/22/whatsapp-is-down-facebooks-new-acquisition-confirms/) + +* 由于负载未发生。 它始于后端路由器问题。 + +* 路由器丢弃了 VLAN，该 VLAN 导致整个集群中大量节点断开/重新连接。 当一切重新连接时，它处于不稳定状态，他们从未见过。 + +* 最终决定，他们必须停止所有操作并将其恢复，这是他们多年来没有做过的事情。 花了一段时间才将所有内容放回原处并重新保存。 + +* 在此过程中，他们发现了一个过度耦合的子系统。 通过断开连接和重新连接，pg2 可以进入 n ^ 3 消息传递状态。 他们看到 pg2 消息队列在几秒钟内从零增加到 400 万。 推出补丁。 + +## 版本 + +* 无法模拟这种规模的流量，尤其是在高峰时段，例如午夜的新闻除夕。 如果他们尝试的是极具破坏性的措施，则推出的速度将非常缓慢。 只需要一小部分流量。 然后快速迭代，直到效果良好为止，然后部署到集群的其余部分。 + +* 推出是滚动升级。 一切都是多余的。 如果他们要进行 BEAM 升级，则会先安装 BEAM，然后逐步在集群中执行重新启动以获取新更改。 有时，它只是一个热补丁，无需全面重启就可以推出。 这是罕见的。 通常升级整个事情。 + +## 尚待解决的挑战 + +* 由于升级，数据库会定期刷新。 数据量太大的问题需要花费很长时间才能加载，并且由于各种原因，加载会在较大规模下失败。 + +* 实时集群状态&大规模控制。 旧的 shell 窗口方法不再起作用。 + +* 2 次幂分割。 现在有 32 个分区。 下一步是 64，这将起作用，但是 128 分区将是不切实际的。 关于这一点没有太多讨论。 + +对 whatapp 与其他聊天应用说微信/行比较的兴趣，是否有关于此的博客/文章/文档？ + +Softlayer 的路由器只是“丢弃” VLAN。 + +他们可以通过廉价找到的 LCD（最低公分母）人员联网的另一朵云。 + +检查我们。 我们可以做的更好：) + +是的，乔，让我们使用您的小公司。 这并不是说 Softlayer 并不是一个存在时间更长的大型企业集团。 他们并不便宜。 他们很容易成为更高端的提供商之一。 他们知道自己在做什么。 一个问题并不大。 AWS 遇到了一些问题。 + +您的帖子只是展示您的天真，给您的公司起了坏名声。 我建议不要发布有关其他提供商的负面评论，以使自己看起来不错。 \ No newline at end of file diff --git a/docs/14.md b/docs/14.md index 846ad82..9154b96 100644 --- a/docs/14.md +++ b/docs/14.md @@ -1,378 +1,12 @@ -# 从将 Uber 扩展到 2000 名工程师，1000 个服务和 8000 个 Git 存储库获得的经验教训 +# 论文：Wikipedia 的站点内部，配置，代码示例和管理问题 -> 原文： [http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) +> 原文： [http://highscalability.com/blog/2007/10/26/paper-wikipedias-site-internals-configuration-code-examples.html](http://highscalability.com/blog/2007/10/26/paper-wikipedias-site-internals-configuration-code-examples.html) - - -为了让 Uber 看到增长的景象，请看一下以上视频的前几秒钟。 它将在正确的位置开始。 它来自[和 Uber 的首席系统架构师](https://www.linkedin.com/in/mranney) [Voxer](http://www.voxer.com/) 的联合创始人 Matt Ranney 发表的精彩演讲：[我希望在将 Uber 扩展到 1000 个服务之前知道些什么[](https://www.youtube.com/watch?v=kb-m2fasdDY) 幻灯片）。 - -它显示了中国一些城市不断增长的，有节奏的，波动的交通网络。 世界各地的城市都在发生这种爆炸性增长的方式。 实际上，Uber 现在已遍布 400 个城市和 70 个国家/地区。 他们有 6000 多名员工，其中 2000 名是工程师。 仅仅一年半的时间，只有 200 名工程师。 这些工程师已经产生了 1000 多种微服务，这些微服务存储在 8000 多个 git 存储库中。 - -在短时间内疯狂增长 10 倍。 谁经历过？ 不太多。 就像您可能期望的那样，这种独特的，压缩的，快节奏的，高风险的经验必须教会您一些新知识，比以前理解的要深刻。 - -马特不是这个游戏的新手。 他是 Voxer 的共同创始人，Voxer 经历了[的快速增长](http://www.marketwired.com/press-release/walkie-talkie-app-voxer-soars-past-billion-operations-per-day-powered-basho-riak-1603652.htm)，但这是不同的。 您可以在观看视频时告诉您 Matt 试图对他们所取得的成就表示满意。 - -马特是一个有思想的人，这是有根据的。 在[最近的一次采访](https://www.infoq.com/articles/podcast-matt-ranney)中，他说： - -> 在 QCon 和其他活动上进行的许多架构讨论使我感到不足够。 像其他人（例如 Google）一样，一切都明白了，但我却没有。 - -马特（Matt）在这次演讲中走出了漩涡，试图从某种意义上讲出一种经验，试图弄清一切。 他成功了。 疯狂地。 - -这部分是智慧的谈话，部分是悔。 马特说：“一路上犯了很多错误，而这些正是从中汲取教训的。 - -演讲的脚手架挂在 WIWIK（我希望我知道的）设备上，该设备已成为互联网的模因。 这是他建议给自己幼稚的一年半的幼稚自我，尽管当然，像我们所有人一样，他当然不会听。 - -而且他不会孤单。 许多人批评 Uber（ [HackerNews](https://news.ycombinator.com/item?id=12597232) ， [Reddit](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) ）。 毕竟，这些数字实在是太疯狂了。 两千名工程师？ 八千个存储库？ 一千个服务？ 一定是很严重的错误，不是吗？ - -也许。 令人惊讶的是，马特对整个事情没有判断力。 他的询问方式更多是质疑和搜索，而不是寻找绝对值。 他本人似乎对存储库的数量感到困惑，但是他给出了更多存储库与较少存储库的优缺点，而没有说哪个更好，因为鉴于 Uber 的情况：您如何定义更好？ - -优步正在全球范围内展开激烈的战斗，以构建一个能够占领赢家通吃的市场的行星尺度系统。 那就是商业模式。 成为最后一个服务站。 在这种情况下，更好的意思是什么？ - -赢家通吃意味着您必须快速成长。 您可能会变慢并显得更有条理，但如果变慢，就会迷失方向。 因此，您可以在混乱的边缘保持平衡，并将您的脚趾或整个身体浸入混乱中，因为这将成为您扩展成为全球主导服务的方式。 这不是一条缓慢的增长之路。 这敲门，采取一切策略。 认为您可以做得更好？ 真？ - -微服务非常适合 Uber 想要实现的目标。 塞住你的耳朵，但这是康威定律的事情，你会获得如此多的服务，因为这是那么多人被雇用并提高生产力的唯一途径。 - -如此多的服务没有技术原因。 没有这么多存储库的技术原因。 这一切都是关于人的。 [老婆婆](https://news.ycombinator.com/item?id=12598893)很好地总结了一下： - -> 扩展流量不是问题。 扩大团队规模和产品功能发布率是主要因素。 - -演讲的一个一致主题是*不错，但是有一些折衷，通常是令人惊讶的折衷，而您实际上只能在规模上体验*。 这引出了我从演讲中得出的两个最大构想： - -* **微服务是一种用 API 协调**代替人类交流的方式。 与人们谈论和处理团队政治相比，团队更容易编写新代码。 它使我想起了我很久以前读过的一本书，不记得这个名字了，人们居住在戴森球体内部，并且因为球体内部空间如此之大，自由能量如此之多，以至于当任何一个群体与另一个群体发生冲突时， 他们可能会分裂并适应新的领域。 这是否更好？ 我不知道，但这确实可以并行完成许多工作，同时又避免了很多人的开销。 -* **纯胡萝卜，不粘**。 关于命令和控制的作用如此广泛，这是一个很深的观点。 您会很想执行政策。 *例如，您应该以这种方式记录*。 如果您不这样做，将会有后果。 那是棍子。 马特说不要那样做。 改用胡萝卜。 每当棍棒冒出来都是不好的。 因此没有任何授权。 您想要处理它的方式是提供非常明显且易于使用的工具，以至于人们不会以其他任何方式使用它。 - -这是您必须真正了解的那些谈话之一，因为除了文本以外，还有很多其他方面的交流。 当然，我仍然鼓励您阅读我的演讲的掩饰:-) - -## 统计信息（2016 年 4 月） - -* 优步遍布全球 400 个城市。 - -* 70 个国家。 - -* 6000 多名员工 - -* 2000 名工程师（一年半前有 200 名工程师） - -* 1000 个服务（数量近似） - - * 不同服务的数量变化如此之快，以至于很难准确计算生产中的实际服务数量。 许多团队正在建立很多东西。 甚至都不在乎实际的数字。 - -* 超过 8000 个 git 回购。 - -## 微服务 - -* 很高兴将您所有的整体分解成更小的东西。 甚至这个名字听起来也很糟糕。 但是微服务有其不利的一面。 - -* 事情最有可能破裂的时间就是您进行更改的时间。 即使是在 Uber 最忙的时候，周末 Uber 在工程师不做更改的时候也是最可靠的。 - -* 每当您进行更改时，都有可能破坏它。 永远不要接触微服务是否有意义？ 也许。 - -* 好 - - * 值得质疑的是，为什么我们要在微服务上投入如此多的精力？ 这不是偶然的，有很多好的结果。 - - * 微服务允许团队快速组建并独立运行。 人们一直在被添加。 团队需要迅速组建起来，并在可以推断边界的地方开展工作。 - - * 拥有自己的正常运行时间。 您运行您编写的代码。 所有服务团队都在征求他们在生产中运行的服务。 - - * 使用最佳工具进行作业。 但是最好的方式是什么？ 最好写？ 最好跑？ 最好，因为我知道吗？ 最好，因为有图书馆？ 当您深入研究时，最好并不意味着什么。 - -* 明显的成本 - - * 运行大型微服务部署的成本是多少？ - - * 现在，您正在运行分布式系统，这比使用整体系统更难。 - - * 一切都是 RPC。 您必须处理所有这些疯狂的失败模式。 - - * 如果中断怎么办？ 您如何排除故障？ 您如何确定中断在服务链中的何处发生？ 如何确保合适的人得到传呼？ 采取了正确的纠正措施来解决问题？ - - * 这些仍然都是显而易见的成本。 - -* 不太明显的费用 - - * 一切都是权衡，即使您没有意识到自己正在做到。 作为所有这些微服务的交换，您可以获得某些东西，但是您也放弃了一些东西。 - - * 通过对所有事物进行超级模块化，我们引入了一些细微而不明显的问题。 - - * 您可能选择构建新服务，而不是修复已损坏的内容。 在某些时候，始终围绕问题解决和清理旧问题的成本已成为一个因素。 - - * **您发现自己为政治**交易很复杂。 您不必编写笨拙的对话，而充满了人类的情感，而是可以编写更多的软件而避免说话。 - - * **您可以保持自己的偏见**。 如果您喜欢 Python 以及与您喜欢的节点打交道的团队，则可以使用自己喜欢的语言来构建新的东西，而不必使用其他代码库。 即使对于组织或整个系统而言，这可能并不是最好的事情，但您仍要继续做自己认为最好的事情。 - -## 拥有多种语言的成本 - -* 史前史：最初，Uber 被 100％外包。 看来这似乎不是技术问题，所以一些公司编写了移动应用程序的第一个版本和后端。 - -* 调度：内部进行开发时，它是用 Node.js 编写的，现在正在迁移到 Go。 - -* 核心服务：系统的其余部分，最初是用 Python 编写的，现在正在迁移到 Go。 - -* Maps 最终被引入内部，那些团队正在使用 Python 和 Java。 - -* 数据工程团队使用 Python 和 Java 编写代码。 - -* 内部度量系统用 Go 编写。 - -* 您开始注意到有很多语言。 微服务使您可以使用多种语言。 - -* 团队可以用不同的语言编写并且仍然可以相互交流。 它可以工作，但是需要付费： - - * 难以共享代码。 - - * 难以在团队之间移动。 在一个平台上积累的知识不会转移到另一平台上。 任何人当然都能学到，但是要付出一定的代价。 - -* **我希望知道的内容**：拥有多种语言会破坏文化。 通过在任何地方都接受微服务，您最终可以扎营。 有一个节点营，一个 Go 营，等等。人们在部落周围组织自然是很自然的，但是要接受在各处都拥有多种语言的策略是有代价的。 - -## RPC 的成本 - -* 团队使用 RPC 相互通信。 - -* 大量的人很快就真正加入了 HTTP 的弱点。 像什么状态代码？ 标头是做什么用的？ 查询字符串中包含什么？ 这是 RESTful 吗？ 这是什么方法 - -* 所有这些事情在执行浏览器编程时看上去确实很酷，但是在进行服务器编程时却变得非常复杂。 - -* 您真正想说的是在那里运行此功能，并告诉我发生了什么。 相反，使用 HTTP / REST 会遇到所有这些细微的解释问题，而这一切都非常昂贵。 - -* JSON 很棒，您可以用眼球看一下并阅读它，但是如果没有类型，这是一团糟，但不是马上，问题随后就会出现。 当某人更改某些内容并在下游跳了几跳时，他们依赖于对空字符串与 null 的某种微妙解释，或者某种语言对另一种语言的某种类型的强制转换，这会导致巨大的混乱，需要花费很长的时间才能解决。 接口上的类型将解决所有这些问题。 - -* RPC 比过程调用慢。 - -* **我希望知道的内容**：服务器不是浏览器。 - - * 当在数据中心中进行交谈时，将所有内容都视为函数调用而不是 Web 请求，这更加有意义。 当您控制对话的双方时，您并不需要所有多余的浏览器内容。 - -## 储存库 - -* 最好的回购数量是多少？ 他认为最好的是一个，但许多人不同意。 - -* 许多人认为很多回购是最好的。 每个项目可能一个，甚至每个项目多个。 - -* 具有许多存储库是遵循具有许多小型模块的行业趋势。 小型模块易于开源或交换。 - -* 一个仓库很不错，因为您可以进行跨领域更改。 您想要进行更改，可以轻松找到所有需要更改的代码。 浏览代码也很容易。 - -* 有很多不好的地方，因为这会给您的构建系统带来压力。 这会损害您浏览代码的能力。 确保正确完成跨领域更改很痛苦。 - -* 一个不好的原因是，它将变得如此之大，除非您在顶部拥有一些疯狂的精心设计的系统，否则您将无法构建或检验您的软件。 如果没有特殊工具，一个仓库可能无法使用。 Google 有一个存储库，但它使用虚拟文件系统，好像您已检出整个存储库。 - -* 超过 8000 个 git 回购。 一个月前有 7000。 - - * 有些人有自己的仓库。 - - * 一些团队使用单独的存储库与服务本身分开跟踪服务配置。 - - * 但是大多数是生产仓库。 - -* 很多回购。 - -## 操作问题 - -* 事情破裂了怎么办？ 大型微服务部署会带来一些令人惊讶的问题。 - -* 如果其他团队无法使用您的服务，而该服务尚未准备好发布，那么其他团队是否可以在您的服务中添加修复程序并将其发布？ - - * 即使您的所有测试都通过了，您拥有的正常运行时间也可以与其他发布您服务的团队兼容吗？ 自动化是否足够好，团队可以相互发布软件？ - - * 在 Uber，这取决于情况。 有时是的，但通常答案是“否”，团队将只需要阻止此修复程序。 - -* 大而小的团队，每个人都在快速前进，所有功能都超级快地发布，但是有时您必须将整个系统理解为一台大型机器连接在一起的一件事。 当您花费所有时间将其分解为微服务时，这很难。 - - * 这是一个棘手的问题。 希望将更多的时间花在保持上下文关联上。 - - * 应该仍然能够理解整个系统的整体功能。 - -## 性能问题 - -* 鉴于微服务之间的相互依赖程度，性能肯定会提高。 - -* RPC 昂贵，尤其是当存在多种语言时，如何理解性能的答案完全取决于语言工具，并且工具都是不同的。 - -* 您已经让每个人都以自己的语言进行编程，现在了解这些语言的性能是一个真正的挑战。 - -* 尝试使用 [火焰图](http://www.brendangregg.com/flamegraphs.html) 使所有语言具有通用的分析格式。 - -* 当您想了解系统的性能时，尝试解决性能问题时，一个很大的摩擦就是工具的差异。 - -* 每个人都想要一个仪表盘，但是如果没有自动生成仪表盘，团队将只把他们认为重要的东西放在仪表盘上，因此当您想追逐一个团队的仪表盘时，问题看上去将与另一个团队完全不同。 - -* 每个服务在创建时都应该具有一个标准的仪表板，其中包含相同的有用数据集。 应该能够创建一个完全没有工作的仪表板。 然后，您可以浏览其他团队的服务，并且看起来都一样。 - -* **我希望知道的内容**：不需要良好的表现，但您需要知道自己的立场。 - - * 一个大争论是，您是否应该关心性能。 “过早的优化是万恶之源”的类型思维催生了反对优化的人们非常奇怪的亚文化。 没关系，服务并不那么忙。 我们应该始终针对显影剂速度进行优化。 购买计算机比雇用工程师便宜。 - - * 对此有一定道理。 工程师非常昂贵。 - - * 问题在于，性能要紧要紧。 有一天，您将遇到绩效问题，如果已建立起一种无关紧要的文化，那么突然之间变得至关重要很困难。 - - * 您想根据创建的所有内容获得某种性能的 SLA，以便有一个数字。 - -## 扇出问题-跟踪 - -* 扇出会导致很多性能问题。 - -* 想象一个典型的服务，即 99％的时间在 1 毫秒内做出响应。 它在一秒钟内响应的时间为 1％。 还算不错。 用户有 1％的时间会遇到这种情况。 - -* 现在，我们假设服务开始大张旗鼓，推出了许多其他服务。 响应时间变慢的机会迅速增加。 至少在 1 秒钟内使用 100 个服务和 63％的响应时间（1.0-.99 ^ 100 = 63.4％）。 - -* 分发跟踪是您跟踪扇出问题的方式。 如果无法理解整个体系结构中的请求，将很难跟踪扇出问题。 - - * Uber 正在使用 [OpenTracing](https://github.com/opentracing) 和 [Zipkin](https://github.com/openzipkin/zipkin) 。 - - * 另一种方法是使用日志。 每个日志条目都有一个公共 ID，该 ID 将所有服务组合在一起。 - -* 给出了一个棘手的例子。 顶层对所有相同服务均具有大量扇出。 当您查看服务时，它看起来不错。 每个请求都是快速且一致的。 问题是顶级服务获得了 ID 列表，并正在为每个 ID 调用服务。 即使同时进行，也将花费太长时间。 只需使用批处理命令即可。 如果不进行跟踪，很难找到这个问题。 - -* 另一个示例是进行了数千次服务调用的服务。 尽管每个呼叫都很快，但大量呼叫却使服务变慢。 事实证明，遍历列表并更改属性后，它神奇地变成了数据库请求。 但是数据库团队说，由于每个操作都很快，所以数据库运行良好，但是他们会想知道为什么会有这么多操作。 - -* 跟踪的开销可以更改结果。 跟踪是很多工作。 一种选择是不跟踪所有请求。 跟踪请求的统计显着部分。 Uber 跟踪约 1％的请求。 - -* **我希望知道的内容**：跟踪需要跨语言上下文传播。 - - * 因为所有这些不同的语言都在所有这些不同的框架中使用，所以获取请求的上下文（例如请求的用户是谁），是否经过身份验证，所处的地理位置是什么，如果无处可放，则会变得非常复杂 将会传播的上下文。 - - * 服务提出的任何依赖请求都必须传播上下文，即使他们可能不理解上下文也是如此。 如果很久以前添加此功能，它将节省大量时间。 - -## 正在记录 - -* 拥有一堆不同的语言，一群团队和许多新人，一半的工程团队已经存在了不到 6 个月，每个人可能都倾向于以完全不同的方式登录。 - -* 任务授权是一个棘手的单词，但这是您真正想要做的，需要一种通用的日志记录方法。 更为可接受的说法是，它提供的工具显而易见且易于使用，人们不会以任何其他方式来获得一致且结构化的日志记录。 - -* 多种语言使得难以记录。 - -* 如果存在问题，日志记录本身可能会使日志记录过多而使这些问题更加严重。 日志中需要背压以在过载时删除日志条目。 希望早些时候已放入系统中。 - -* **我希望知道的内容**：关于日志消息大小的一些概念，以便可以跟踪谁产生了过多的日志数据。 - - * 所有日志发生的事情是通过某种工具将它们编入索引，以便人们可以搜索它们并学习事物。 - - * 如果免费记录，则记录的数据量是可变的。 有些人会记录很多数据，使系统不堪重负。 - - * 对于计费系统，当将日志数据发送到群集以建立索引时，可以将帐单发送到服务以进行支付。 - - * 的想法是给开​​发人员以更大的压力，使他们更聪明地记录日志，而不是更难。 - - * Uber 创建了 [uber-go / zap](https://github.com/uber-go/zap) 用于结构化日志记录。 - -## 负载测试 - -* 想要在将服务投入生产之前进行负载测试，但是无法构建与生产环境一样大的测试环境。 - -* 这也是生成实际测试数据以测试系统所有部分的问题。 - -* 解决方案：在非高峰时段对生产进行测试。 - -* 引起很多问题。 - -* 它炸毁所有指标。 - - * 您不希望人们认为负载多于实际负载。 为了解决该问题，它又回到了上下文传播问题。 - - * 确保所有测试流量请求都具有表示此测试请求的上下文，因此以不同的方式处理指标。 这必须贯穿整个系统。 - -* **我希望知道的是**：我们真正想要做的是始终在所有服务中运行负载，因为许多错误仅在流量达到峰值时才会出现。 - - * 希望将系统保持在峰值附近，并随着实际流量的增加而退缩。 - - * 希望该系统很早以前就已建立，可以处理测试流量并以不同的方式处理它。 - -## 故障测试 - -* **我希望知道的内容**：并非每个人都喜欢 Chaos Monkey 等失败测试，​​尤其是如果您稍后要添加它时。 - - * 如果您不喜欢，我们应该做的是对您进行故障测试。 这只是生产的一部分。 您的服务只需要承受随机的杀戮，运行减慢和干扰。 - -## 迁移 - -* 我们所有的东西都是遗产。 全部都是迁移。 通常，从事存储工作的人们正在做的事情是从一个旧版迁移到另一个旧版。 - -* 有人总是在某处迁移某物。 不管人们在会议上怎么说，这就是每个人都在做的事情。 - -* 旧的东西必须保持工作状态。 业务仍然必须运行。 不再有维护窗口之类的东西。 可接受的停机时间。 - -* 随着您成为一家全球企业，没有高峰时间。 总是高峰时间在某个地方。 - -* **我希望知道的内容**：迁移的要求很糟糕。 - - * 没有人希望被告知必须采用某种新系统。 - - * 使某人发生变更是因为组织需要进行变更，而不是提供一个更好的新系统，因此显然您需要接受这一新事物。 - - * 纯胡萝卜，不粘。 无论何时出现问题，除非与安全性或合规性有关，否则这是不好的，强迫人们做事可能是可以的。 - -## 开源 - -* 没有人同意建立/购买权衡。 你什么时候建造？ 你什么时候应该买？ - -* 属于基础架构的任何东西，看起来像是平台的一部分而不是产品的一部分的任何事物，在某个时候都将成为无差异的商品。 亚马逊（或某人）将提供它作为服务。 - -* 最终，您花了所有时间在做这件事，其他人会以更便宜和更好的方式来做。 - -* **我希望知道的内容**：如果人们正在使用某种平台类型的功能，那么听到亚马逊刚刚发布您的服务即服务听起来并不好。 - - * 您仍在尝试合理化为什么应将自己的私人物品用作服务。 - - * 事实证明，那些人在这些文本编辑器的另一端。 人们对构建/购买权衡的判断方式存在巨大差异。 - -## 政治 - -* 通过将所有内容分解为小型服务，可以使人们玩政治。 - -* 每当您做出违反此属性的决定时，就会发生政治事件：公司>团队>自我。 - - * 您将自己的价值观置于团队之上。 - - * 团队的价值高于公司。 - -* 政治不只是您不喜欢的决定。 - -* 通过拥抱高度模块化的快速发展，非常快地雇用人员并尽快发布功能，人们开始倾向于违反此属性。 - - * 当您重视以较小的个人成就来交付产品时，很难确定对公司更有利的优先事项。 令人惊讶的权衡。 - -## 权衡取舍 - -* 一切都是权衡。 - -* **我希望知道的内容**：如何更好地有意进行这些折衷。 - - * 当事情在没有明确决定的情况下发生时，因为这似乎是事情的发展方向，即使没有明确做出决定，也要考虑做出什么权衡。 +Wikipedia 和 [Wikimedia](http://highscalability.com/wikimedia-architecture) 拥有一些有关如何构建高度可扩展系统的最佳，最完整的真实文档。 Domas Mituzas 撰写的这篇论文涵盖了有关 Wikipedia 如何工作的许多细节，包括：所使用的不同软件包的概述（Linux，PowerDNS，LVS，Squid，lighttpd，Apache，PHP5，Lucene，Mono，Memcached），它们如何使用它们。 CDN，缓存如何工作，他们如何配置代码，如何存储媒体，如何构造数据库访问，如何处理搜索，如何处理负载平衡和管理。 全部带有真实的代码示例和配置文件示例。 这是一个非常有用的资源。 ## 相关文章 -* [关于 HackerNews](https://news.ycombinator.com/item?id=12697006) - -* 关于在 HackerNews 和 [上的视频](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) [的精彩讨论，关于[Reddit]](https://news.ycombinator.com/item?id=12597232) - -* [扩展流量高的 Feed 的设计决策](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html) - -* [Google 延迟容忍系统：将不可预测的部分做成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) - -* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) - -* [Uber 变得与众不同：使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) - -* [Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理百万个写入](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) - -* [用 Matt Ranney 缩放 Uber](http://softwareengineeringdaily.com/2015/12/04/engineering-at-uber-with-matt-ranney/) - -* [InfoQ 播客：Uber 的首席系统架构师，介绍其架构和快速发展](https://www.infoq.com/articles/podcast-matt-ranney) - -* [分布式 Web 架构：Matt Ranney，Voxer](https://gaming.youtube.com/watch?v=pXT0mF9bMyA) - -* [Riak at Voxer-Matt Ranney，RICON2012](https://vimeo.com/52827773) - -优步遍布 400 多个城市。 因此，请在帖子中更正此问题。 - -谢谢 - -这是我一生中读过的最好的经验教训文章之一。 这是一项毫不废话，诚实和实践的知识共享活动。 许多公司正在努力适应不断变化的新技术，例如微服务，CI / CD，Paas，Saas 和带有 Docker 的 Cass。 正如他在视频中正确指出的那样，这始终是一种思维方式/文化挑战，每个人对编程语言，方法等都有自己的看法。认识到这一事实并引导每个人完成业务需求的共同目标很重要。 - -难以置信！ 从头到尾纯粹基于经验的演讲 - -很棒的文章，有非常有用的信息。 +* [Wikimedia 架构](http://highscalability.com/wikimedia-architecture)* [Domas Mituzas 的博客](http://dammit.lt) -完全基于经验非常坦率非常实用。 他吸取的教训是休息的智慧。 \ No newline at end of file +非常详细的文档确实涵盖了帖子中提到的大多数（或所有？）主题。 +我尚未读完它，仍在进行中，但是已经非常清楚，值得阅读，谢谢您的链接！ \ No newline at end of file diff --git a/docs/140.md b/docs/140.md index 4b2cf97..b312f00 100644 --- a/docs/140.md +++ b/docs/140.md @@ -1,140 +1,259 @@ -# BigData 使用 Erlang，C 和 Lisp 对抗移动数据海啸 +# Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理 -> 原文： [http://highscalability.com/blog/2012/11/26/bigdata-using-erlang-c-and-lisp-to-fight-the-tsunami-of-mobi.html](http://highscalability.com/blog/2012/11/26/bigdata-using-erlang-c-and-lisp-to-fight-the-tsunami-of-mobi.html) +> 原文： [http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html](http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html) -![](img/d7393e0f00b2136eb372dc5f189c4a3d.png) +![](img/169da6be29a418ae00a0c92191729dff.png) -*这是 [Jon Vlachogiannis](http://www.linkedin.com/in/johnvlachoyiannis) 的来宾帖子。 Jon 是 [BugSense](http://www.bugsense.com/) 的创始人和首席技术官。* +*这是关于[的 Disqus 更新：它仍然是实时的，但是 Go 拆除了 Python](http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html) 。* -BugSense，是一个错误报告和质量指标服务，每天跟踪数千个应用程序。 当移动应用崩溃时，BugSense 可帮助开发人员查明并解决问题。 该初创公司向其客户提供一流的服务，其中包括 VMWare，三星，Skype 和数以千计的独立应用程序开发人员。 跟踪超过 200M 的设备需要快速，容错和廉价的基础架构。 +您如何向 Web 规模应用程序添加实时功能？ 这就是 [Adam Hitchcock](https://www.linkedin.com/in/adamhitchcock) ，在 Disqus 上，Disqus 的一名软件工程师在精彩的演讲中谈到：[使 DISQUS Realtime](https://www.youtube.com/watch?v=5A5Iw9z6z2s) （[幻灯片](https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock)）。 -最近六个月，我们决定使用我们的 BigData 基础架构，向用户提供有关其应用性能和稳定性的指标，并让他们知道错误如何影响他们的用户群 和收入。 +Disqus 必须采用他们的评论系统并为其添加实时功能。 在谈话之时（2013 年），他们每月只有 10 亿的唯一身份访问者，这并非易事。 -我们知道我们的解决方案应该从第一天开始就可以扩展，因为超过 4％的智能手机将开始使用 DDOS 向我们提供数据。 +Disqus 开发的是一种称为“实时”的实时评论系统，该系统经过测试可处理 150 万个并发连接的用户，每秒 45,000 个新连接，每秒 165,000 条消息，并且端到端的延迟少于 0.2 秒。 -我们希望能够： +评论系统的本质是它受 IO 约束并且具有很高的扇出度，这是评论的传入，必须将其发送给许多读者。 这个问题与 Twitter 必须解决的[非常相似。](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) -* 提取应用程序逻辑并使用 JSON 填充浏览器 -* 快速运行复杂算法 -* 无需专用 Hadoop 集群即可进行数据实验 -* 预处理数据，然后将其存储（减少存储） -* 能够在每个节点上处理超过 1000 个并发请求 -* 每个应用程序“加入”超过 1.25 亿行 -* 做到这一点，而无需花费大量的服务器时间 +Disqus 的解决方案及其解决之道非常有趣。 他们尝试了不同的体系结构，但选择了基于 Python，Django，Nginx Push Stream Module 和 Thoonk 构建的解决方案，这些解决方案均通过灵活的管道体系结构进行了统一。 在此过程中，我们能够大幅减少其服务器数量并轻松处理高流量负载。 -该解决方案使用： +在演讲的某一时刻，亚当问管道式架构是否是一个好的架构？ 对于 Disqus 消息，通过一系列转换进行过滤是完美的选择。 这是一个非常古老的想法。 Unix 系统 5 长期以来具有 [Streams 功能](http://infohost.nmt.edu/~eweiss/222_book/222_book/0201433079/ch14lev1sec4.html)用于创建灵活的管道体系结构。 这是组织代码的一种非常灵活而强大的方式。 -* 在 Azure 上运行的大型实例不到 20 个 -* 内存数据库 -* 一种用 C 语言编写的功能齐全的自定义 LISP 语言，用于实现查询，这比始终使 VM（带有垃圾收集器）联机的速度快很多倍 -* Erlang 用于节点之间的通信 -* 修改后的 TCP_TIMEWAIT_LEN 可以惊人地减少 40K 连接，节省了 CPU，内存和 TCP 缓冲区 +因此，让我们看看 Disqus 如何发展其实时评论架构并在此过程中创建新旧事物。 -## 内存数据库万岁 +## 统计资料 -我们知道，处理所有这些流量的唯一方法是使用内存数据库。 +* 当前： -不仅要处理巨大的数据集上的即席问题（例如，“有多少个使用三星设备的唯一用户在一个星期内有此特定错误”）， 内存限制还与数据处理前后的数据序列化和反序列化有关。 因此，我们启动了 LDB 项目。 + * 300 万个网站使用 Disqus 作为其评论系统 -## LDB 项目 + * 每月有十亿人参与对话 -您是否相信可以将来自各种来源（成千上万种不同资源，如移动设备）的数据馈送到系统中，在几行代码中描述要提取的信息，然后将所有这些信息掌握在您的指尖中 ？ 实时。 系统持续运行时？ -LDB 不仅是数据库，更是一个应用程序服务器。 即使是内存中数据，实际上也将数据存储在硬盘驱动器中并在其他节点之间复制。 + * 每月有 2000 万条评论 -对于 LDB，我们不会运行查询。 **我们之所以运行算法，是因为我们拥有用 C 语言编写的完整的自定义 LISP 语言，该语言可以访问与数据库**相同的地址空间。 这意味着您可以非常快速地搜索数据，增加计数器，获取/放置等。 +* 截至 2013 年 3 月： -拥有 LISP 的优点是，您可以轻松地像 Hive 这样创建类似于 SQL 的语言并实时查询数据，如下所示： + * 每月有十亿独立访客。 -![](img/4f86c5099d53bd29080e5c65dc645ef5.png) + * 18 位工程师 -LDB 的工作方式如下： +## 平台 -每个应用都有自己的 LDB。 这意味着它自己的内存空间。 这样，我们可以轻松地将较大的应用程序（在流量方面）移动到不同的计算机上。 +* Python（Disqus 是一项服务，用 Python 和其他语言编写） -［HTG1］ ［HTG2］ ［HTG3］ ［HTG4］ ［HTG5］ ［HTG6］ ［HTG7］ ［HTG8］ ［HTG9］当请求来自移动设备时，主 LDB 节点接受连接（使用 erlang 线程池）并将数据转发到特定的数据库。 此请求处理机制用少于 20 行的 Erlang 代码实现。 我们选择 Erlang 进行节点间通信的另一个原因。 +* Django -当请求“流式传输”到 LDB 时，名为“ process.lql”的文件负责分析，标记数据并创建任何计数器。 所有这些都是即时完成的，并可满足每个请求。 +* [Thoonk Redis 队列](http://blog.thoonk.com/) -Redis 之上的队列库。 -![](img/21f3217c4f84d924505193761bfaba1b.png) +* Nginx [推流模块](http://wiki.nginx.org/HttpPushStreamModule) -用于 Nginx 设置的纯流 http 推技术。 Comet 变得简单且真正可扩展。 -我们能够做到这一点，因为启动 LISP-VM 并针对每个请求执行所有这些过程仍然很多次 始终使 VM（带有垃圾回收器）联机的速度更快。 +* [Gevent](http://www.gevent.org/) -基于协程的 Python 网络库，该库使用 greenlet 在 libev 事件循环的顶部提供高级同步 API。 -使用 LDB，我们可以使用不超过 3 行代码来创建时间序列和汇总数据。 -例如。 这样会为唯一用户创建 7 天的时间序列： +* 使用 EventSource 的长轮询（在浏览器中） -![](img/2e1e91d523a2dd76b05398fc2faee593.png) +* [Sentry](https://github.com/getsentry/sentry) -一个与平台无关的实时错误记录和聚合平台。 -## 备择方案 +* [缩放比例](https://github.com/Cue/scales) -跟踪服务器状态和统计信息，使您可以查看服务器的运行状况。 -在我们的测试中，我们发现 SQL 数据库不太适合，因为我们的数据是非结构化的，并且我们需要很多复杂的“联接”（和许多索引）。 另一方面，对于 NoSQL 数据库，我们无法在数据上运行算法（在系统运行时），而使用映射器/约简器会使整个过程变得复杂而缓慢。 我们需要一个没有大锁或 DB 锁的高并发系统，该系统可以在仅几个 KB 的时间内跟踪数百万个唯一事件，并且非常容易扩展。 +* 在原始金属（而非 EC2）上运行。 -一个很好的替代方法是使用 Stream 数据库（例如 [Storm](http://storm-project.net/) ）。 我们的主要问题是有很多活动部件和单个节点的性能。 使用 LDB，我们的优势是能够非常快速地处理数据（它们驻留在相同的内存空间中），将它们存储为聚合计数器或符号（因此，千兆字节的数据以 KB 为单位），然后让 DSL 执行任何关联 我们要在飞行中。 没有序列化/反序列化，没有网络调用，也没有垃圾收集器。 就像将汇编代码映射到您的数据上一样。 +## 架构 -在 LDB 之上，我们还有可以缩放和处理传入数据的接收器，一个流组件，其中的所有内容都在几行代码中定义，一个存储引擎和一个复制 发动机。 +* 实时动机： -## 优化内核-TCP 的 UDP 行为 + * **参与度** 。 评论的实时分发鼓励用户在页面上停留更长的时间。 实时评论后的人比以前多。 -与每秒处理大量请求的其他服务相比，进行分析时的独特之处在于，移动设备与服务器之间的对话非常小（3 个 TCP 握手数据包，1 个有效负载数据包和 3 个 TCP 终止数据包 ）。 + * **买卖数据** 。 从全局评论流中创建消防软管产品。 -但是，TCP 在设计时并未考虑到类似问题（即设备之间的小对话框），并实现了称为 TIME_WAIT 的状态（持续时间约为 1） 分钟 （在 2.6 Linux 内核中），在该时间之后，最后一个 FIN 数据包发送之后，该特定连接元组的 TCP 状态保持打开状态一段时间，以便接收可能已延迟的任何杂散数据包（即 连接关闭）。 在我们的例子中，这有点没用（我们想要类似于 UDP 行为但具有 TCP 保证的东西），因为有效负载只有 1 个数据包（对于查看请求，最多 4 或 5 个数据包），因此我们决定修改内核源并减少 常量，此常量降至 20 英寸。结果是惊人地减少了 40K 连接，节省了 CPU，内存和 TCP 缓冲区。 +* 旧的实时系统： -我们应用的补丁在文件中： -linux-kernel-source / include / net / tcp.h + * 用 Django 编写的 Disqus 应用程序将通过许多键发布到内存缓存：Forum：id，thread：id，user：id，post：id。 也许将来有人会觉得有趣。 由于 pub / sub 的价格便宜，因此可以进行以后的创新。 -#define TCP_TIMEWAIT_LEN（[ 60 * HZ ） -至 -#define TCP_TIMEWAIT_LEN（ 20 * HZ ） + * 前端客户端每隔几秒钟会轮询一次内存缓存密钥。 -使用此架构，我们可以为所有付费客户（运行少于 20 个大型实例）提供有关移动应用程序的实时分析和见解。 在 Azure 上，包括后备和备份服务器。 + * 客户端将显示任何新评论。 -## 相关文章 + * 问题：根本没有缩放。 一次只有 10％的网络可以使用该产品。 + +* 第一种解决方法： + + * 新帖-> Disqus-Redis [发布/订阅](http://redis.io/topics/pubsub) -> [烧瓶](http://en.wikipedia.org/wiki/Flask_(web_framework)) （一个 Web 框架）前端集群<-HAProxy <-客户端。 + + * 客户端将连接到 HAProxy。 HAProxy 用于处理数百万个连接。 + + * 问题：由于烧瓶计算机正在执行冗余工作，因此它们很快耗尽了 CPU。 如果两个订户正在侦听同一线程，则该消息将被格式化两次。 + +* 第二种方法： + + * 已创建后端服务器以执行重复数据删除格式化工作。 + + * 新流程：新帖子-> Disqus-> redis 队列->“ python 胶” Gevent 格式服务器（2 个服务器用于冗余）-> redis 发布/订阅（6 个服务器） -> Flask FE（前端）群集（14 个大服务器）<-HA 代理（5 个服务器）<-客户端 + + * 效果很好。 除了扩展外，它使用的服务器越来越多，尤其是 Flask 集群。 Redis 发布/订阅集群也迅速增长。 + +## 第三种制胜法则： + +* 使用 [流水线架构](http://www.cs.sjsu.edu/~pearce/modules/patterns/distArch/pipeline.htm) ，其中消息在过滤器作用下从一个队列传递到另一个队列。 + +* 切换到 Nginx +推送流模块。 这取代了 redis pub / sub，flask 服务器和 HAProxy 集群。 + +* 新流程如下所示：新帖子-> Disqus-> redis 队列->“ python 胶” Gevent 格式服务器（2 个服务器）-> http 帖子-> nginx pub 端点- > nginx +推送流模块（5 个服务器）<-客户端 + +* 仅使用了 redis 的 pub / sub，并且 nginx 推送流模块支持相同的功能。 + +* 由于内核中的网络内存限制，需要 5 个推送流服务器。 这是一个套接字分配问题，即有很多套接字打开。 否则可以在 3 台服务器上运行，包括冗余。 + +* 流程中的 Disqus 部分是 Django Web 应用程序，它使用 post_save 和 post_delete 挂钩将内容放入 thunkk 队列中。 这些挂钩对于生成实时数据通知非常有用。 + +* Thoonk 是 Redis 之上的队列库。 + + * 他们已经有了 thunkk，因此可以使用它来代替分解 RabbitMQ 计算机的 HA 集群。 最终真的很喜欢它。 + + * Thoonk 被实现为状态机，因此很容易查看已声明或未声明哪些作业，等等。使故障后的清除变得容易。 + + * 由于使用 zset 将队列存储在 Redis 中，因此可以在队列上执行范围查询。 例如，您可以询问哪些消息已被处理，并采取适当的措施，因此对实施端到端的确认很有用。 + +* python 胶水程序。 + + * 收听 thoonk 队列。 + + * 为客户端执行所有格式化和计算。 包括清洁和格式化数据。 + + * 最初是在 Flask 群集中进行格式化的，但是这占用了太多 CPU。 + + * 发现用 gzip 压缩单个邮件并不成功，因为邮件中没有足够的冗余来从压缩中节省足够的钱。 + + * 对于这样的 IO 绑定系统，Gevent 的运行速度非常快。 + + * 看门狗确保 [绿色](https://pypi.python.org/pypi/greenlet) 始终在运行，也就是说，始终在执行工作。 Greenlet 是没有隐式调度的微线程： [协程](http://en.wikipedia.org/wiki/Coroutine) 。 + + * 监视器监视许多故障，然后在观察到时发出警报。 + +* 流水线架构。 + + * python 胶水程序的结构是一个数据管道，数据必须经过几个阶段：解析，计算，发布到另一个地方。 这些在 greenlet 中运行。 + + * [Mixins](http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful) 用于实现阶段功能：JSONParserMixin，AnnomizeDataMixin，SuperSecureEncryptDataMixin，HTTPPublisher，FilePublisher。 + + * 这个想法是组成管道。 一条消息将从 thunkk 中传出并通过以下管道运行：JSONAnnonHTTPPipeline，JSONSecureHTTPPipeline，JSONAnnonFilePipeline。 + + * 管道可以共享它们的大多数功能，但是仍然是专门的。 启用新功能时很棒，您可以创建一个新的管线阶段，创建一个新的管线，并使旧管线与新管线并排运行。 新旧功能愉快地共存。 + + * 测试也可以在管道中进行。 要运行测试，只需在管道中插入 filter / module / mixin 即可运行测试。 -* [关于 HackerNews](http://news.ycombinator.com/item?id=4833052) + * 容易推断。 每个 mixin 都很容易理解。 它做一件事。 项目中的新工程师使用这种方法设计的系统要容易得多。 + +* Nginx 推送流 + + * 处理系统的发布/订阅方面和 Web 服务方面。 并且都很好。 + + * 最近通过 5 台服务器吸引了 200 万并发用户。 CPU 使用率低于 15％时，每台计算机的用户数量达到约 950K 的峰值，每台计算机达到 40 MB /秒。 + + * 持续将数据写入套接字以测试套接字是否仍然打开。 如果不是，则将其清理以为下一次连接腾出空间。 + + * 配置是发布端点和订阅端点，以及如何在它们之间映射数据。 + + * 内置良好的监视功能，可通过推送流状态端点进行访问。 + + * 模块中的内存泄漏需要全天滚动重启，尤其是当每个进程有数十万个并发连接时。 浏览器将在断开连接时迅速知道，因此它将重新启动并重新连接。 + +* 较长的轮询 + + * 这是在浏览器/ JavaScript 客户端上。 + + * 当前使用 WebSocket 的原因是它们速度很快，但由于它内置在浏览器中并且可以处理所有内容，因此正在迁移到 EventSource。 只需注册消息类型并为其提供回调处理程序即可。 + +## 测试 + +* 黑暗时间测试。 Disqus 已安装在数百万个网站上，因此需要对数百万个并发连接进行测试。 使用现有网络进行负载测试，而不是在 EC2 中创建伪设置。 + +* 例如，有条理的客户说只有 10％的用户或恰好这个网站应该流经新系统。 + +* 最暗时间。 世界上发生了一些重要的事情，而且两个网站的流量也很大。 因此，他们接受了所有流量，并通过系统中的单个 pub / sub 密钥发送了流量。 这有助于识别代码中的许多热点。 + +## 度量 + +* 测量所有东西。 在流水线系统中，您只需测量每个阶段的输入和输出，即可与 HAProxy 等其他系统协调数据。 没有测量数据，就无法向下钻取并找出谁是错的。 + +* 尽可能将指标表示为+1 和-1。 （我不太了解这一点） + +* Sentry 帮助查找代码中的问题。 + +* 通过测量，可以轻松创建漂亮的图形。 + +* 当选择教皇并看到白色烟雾时，流量峰值达到每秒 245 MB，当天传输了 6 TB 数据，峰值 CPU 为 12％。 + +## 获得的经验教训 + +* **一次工作**。 在大型扇出架构中，在一个地方进行工作，然后将其发送给所有消费者。 不要为每个消费者重复工作。 + +* **最有可能失败的代码是您的代码**。 您很聪明，但是很聪明的人写了 redis 和其他产品，所以要比系统的其他部分更关心您的代码。 + +* **端到端的支架不错，但价格昂贵**。 想要 100％交付的客户所必需。 无法为每个前端用户做到这一点。 + +* **Greenlets 是免费的**。 使用它们。 它们使代码更易于阅读。 + +* **发布是免费的**。 发布到所有频道。 由于消息已通过所有渠道发布，因此他们无需事先进行计划就可以制作出实时的流量大图。 + +* **有时候会有个大胜利。** 发现 Nginx 推送流模块简化了其系统的巨大块并减少了服务器数量。 + +* **了解负载测试时的用例，以便您可以真正测试系统**。 + +* **使用实际流量进行测试**。 当您的系统变大并且生成合成负载本身就是一个巨大的项目时，这是一种容易得多的方法。 + +* **使用 Python** 。 他们确实喜欢 Python 和 Django，尽管其中一些后端内容现在是用 Go 编写的。 + +* **响应规模而增加的服务器数量是您的体系结构可能需要进行一些调整的标志。 看一看，您可以更改架构并更有效地使用资源。** + +* **使用现成的技术**。 不必觉得您必须从头开始构建所有内容。 利用代码，使您的团队规模变小。 + +## 相关文章 -既然没有垃圾收集器，如何在 LISP 实现中回收内存？ 谢谢。 +* [将 DISQUS 扩展到 7500 万评论和 17,000 RPS](http://highscalability.com/blog/2010/10/26/scaling-disqus-to-75-million-comments-and-17000-rps.html) （2010） -好贴！ 我特别喜欢 TCP 技巧。 您能否分享每天有多少事件和多少数据进入？ 另外，您要从中提供查询的内存数据集大小是多少？ 我对您正在执行的联接大小特别感兴趣。 +* Disqus [nginx-push-stream-module 配置](https://gist.github.com/dctrwatson/0b3b52050254e273ff11) 适用于> 1MM 并发用户。 -噢亲爱的。 `tcp_tw_reuse`或`tcp_tw_recycle`有什么问题？ +* [通过](https://www.youtube.com/watch?v=5A5Iw9z6z2s) [Adam 制作 DISQUS 实时](https://www.linkedin.com/in/adamhitchcock) （ [幻灯片](https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock) ） 希区柯克 ，软件工程师，〜2013 年 3 月 -何俊！ +* [将 Django 扩展到 80 亿页面浏览量](http://blog.disqus.com/post/62187806135/scaling-django-to-8-billion-page-views) [Matt Robenolt](https://www.linkedin.com/in/mattrobenolt) ，运筹领先，2013 年 9 月 -我非常喜欢阅读！ 我是一位经验丰富的 Erlang 程序员，我很想阅读有关 Lisp 实际使用的更多信息。 如果您有任何有关 List 的良好介绍性文章的链接，那就太好了！ +* [HTTP for Great Good](https://www.youtube.com/watch?v=HAjOQ09I1UY) （[幻灯片](https://speakerdeck.com/mattrobenolt/http-for-great-good)），作者：Matt Robenolt，2013 年 10 月 -非常感谢您的精彩文章！ +* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) -本文充满了不寻常的陈述和设计决策，我怀疑 BugSense 是由外星人控制的：） +* [Twitter 用来处理 1.5 亿活跃用户，300K QPS，22 MB / S Firehose 的架构，并在 5 秒内发送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) -有什么问题：echo“ 20” > / proc / sys / net / ipv4 / tcp_fin_timeout？ 不工作？ +* John Watson 的 [C1MM 和 NGINX](https://www.youtube.com/watch?v=yL4Q7D4ynxU) （[[幻灯片](https://speakerdeck.com/dctrwatson/c1m-and-nginx)）-Disqus 结构的更新。 -在每个请求上启动 LISP VM 的速度要比一直保持 VM 联机的速度快？ 好的，我明白了，Lisp VM 不能很好地完成 GC。 但是有一个 JVM 和 Clojure（Lisp 方言顺便说一句） +* [试试这个 Go 事情…](http://blog.disqus.com/post/51155103801/trying-out-this-go-thing) -LISP + Erlang 的组合？ 有人非常了解 Lisp 和 Erlang :)。 +引用“如果可以的话，将指标表示为+1 和-1。（我不太了解这一点）” -嗯-而不是在服务器上浪费 TCP 时间，您难道不就让客户端在服务器之前关闭 TCP 连接吗？ 这将给客户端增加“等待时间”的负担。 +这不仅仅是计数指标吗？也就是说，因为您正在使用链接的消息队列，因为消息到达您对计数器+1 的每个点，而消息离开您-1 的另一个计数器。 您可以在每个节点/队列的输入和输出处执行此操作。 +每个点+1 的变化，每个点-1 的变化告诉您每个时间间隔（传入和传出）的消息吞吐量，总+1 和总-1 的差告诉您消息' 在队列中”。 -我猜您的协议目前已经广泛部署，因此更改它为时已晚？ +好读！ -我愿意在这方面寻找另一面，但是我仍然看不到在提出了如此精美高效的体系结构之后，您选择使用 Windows Azure，这是最糟糕的此类产品（IaaS / PaaS） -。 ..我一直在烦我..这似乎引入了各种性能和财务瓶颈。 除非您对支持 Windows Phone 设备有何需求（极不可能）。 因此，我得出的结论是，您获得了免费优惠或其他优惠。请帮助我理解。 +好东西。 -对于建议使用 tcp_tw_reuse 的人： +现在，他们需要解决垃圾邮件问题。 -http://serverfault.com/questions/303652/time-wait-connections-not-being-cleaned-up-after-timeout-period-expires +这看起来像一团糟。 在这家公司工作会很害怕。 这就是为什么您需要良好的系统架构师的原因。 如果您不能用 c / c ++自己编写（暗示理解）这些工具的一半，则需要重新考虑领导该项目。 现在您有了一个巨大的泥球，上帝知道有多少种不同类型的“粘土”。 +http://en.wikipedia.org/wiki/Big_ball_of_mud -tcp_fin_timeout 设置套接字在 FIN-WAIT-2 状态下花费的时间。 此参数不会影响在 TIME_WAIT 状态下花费的时间。 尝试 netstat -o 并观察处于 TIME_WAIT 状态的套接字的计时器值（选择 tcp_fin_timeout 值）。 +我很好奇他们是否会考虑为此使用 elixir 以及 phoenix 框架。 流水线方法，大规模，并发性和容错性固有地内置于长生不老药中，并且不需要像这样做的一整套分散的组件。 话虽如此。 做到这一点仍然是一个了不起的壮举，我敢肯定，出于很多原因，研究长生不老药可能不是他们追求的解决方案。 -@Sumit R：你的意思是...？ 您是否阅读了整个 serverfault 线程，特别是有关`tcp_tw_reuse`问题的答案？ 您实际上曾经使用过`tcp_tw_reuse=1`吗？ +这看起来很混乱。 会害怕在这个组织工作。 这就是为什么您需要好的程序设计师。 如果您不能在 c / c ++中自己创建（暗示理解）这些资源的 50％，则需要重新评估获得的资源。 现在您有了一个伟大的泥泞足球，上帝知道有多少种“粘土”。 -Lisp 解释器的内存处理由我们完成。 我们使用世代容器，并在每个“简短”脚本完成时回收分配的内存（对于“年轻”条目。由于系统体系结构/设计，无需收集“顽固”条目。通常，我们分为三代） 有自己的收集策略）。 因此，无需拥有成熟的垃圾收集器。 +我很好奇你们在 django 中存储持久连接的位置，这是我们的主要问题，我们的队列（我们使用 Rabbitmq）连接快要死了并且无法恢复。 -我们不使用 JVM 或任何其他托管 VM 解决方案（Clojure，F＃等），因为我们只希望每个 VM（以及特定 VM 上的语言）提供的功能的子集，并且有大量空间可以优化 满足我们自己的“特殊”需求。 此外，Scheme（Lisp）还提供了构建具有表达力的程序所需的一切，这些程序通常具有功能范式的抽象和形式/模式。 +现在他们需要解决垃圾邮件问题。这就是为什么您需要优秀的程序设计师。 如果您不能在 c / c ++中自己创建（暗示理解）这些资源的 50％，则需要重新评估获得的资源。 +好东西。 -你好 +从它的声音来看，它听起来像是一个混乱的机构，但是，从它提供的服务的种类来看，我相信他们可能已经将其微调到可以接受的水平。 -真的很想知道有关 Lisp（方案）实现以及它们如何与 Erlang 一起工作的更多信息。 您是否有可能开源示例或框架的一部分？ +我喜欢这篇文章，但有一个问题。 +Disqus 使用的数据库是什么？ -无论如何，感谢您的文章。 +该帖子解释了如何保存新帖子，但是当我打开网站并打开 Disqus 评论时。 获取所有评论并显示在网站上的过程是什么？ -此致 -尼古拉斯 \ No newline at end of file +谢谢这个 \ No newline at end of file diff --git a/docs/141.md b/docs/141.md index b4ca57c..8219637 100644 --- a/docs/141.md +++ b/docs/141.md @@ -1,191 +1,63 @@ -# Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序 - -> 原文： [http://highscalability.com/blog/2012/10/22/spanner-its-about-programmers-building-apps-using-sql-semant.html](http://highscalability.com/blog/2012/10/22/spanner-its-about-programmers-building-apps-using-sql-semant.html) - -![](img/e618cf11a7e558cbccc35dc3c895b625.png)很多人似乎都非常讨厌 [NewSQL](http://blogs.the451group.com/information_management/2011/04/06/what-we-talk-about-when-we-talk-about-newsql/) 这个词，或者几乎是这个词的任何新造词，但是在看过高级软件工作人员 Alex Lloyd 之后 Google 工程师，就 Building Spanner 进行了精彩的演讲 [ ，这是最适合 Spanner 的术语。](http://vimeo.com/43759726) - -Spanner 将 OldSQL 的 SQL +事务模型包装在全球分布式 NoSQL 系统的重新设计的骨骼上。 在我看来，这是 NewSQL。 - -由于 Spanner 不是 BigTable 的近亲，因此 NoSQL 组件应该不足为奇。 Spanner 负责在任意数量的地理分布数据中心内跨越数百万台计算机。 令人惊讶的是，OldSQL 是如何被接受的。 Alex 在 HotStorage 会议上发表的 [](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf)早期演讲中，采用 OldSQL 的原因是希望使程序员更轻松，更快速地构建应用程序 。 主要思想似乎很熟悉： - -* 小型复杂数据库与庞大，可扩展，简单的数据库之间存在错误的二分法。 我们可以拥有功能并对其进行扩展。 -* 复杂性可以保留，可以放到某个地方，因此，如果不在数据库中，则将其推送给开发人员。 -* 将复杂性降低到堆栈中，以便开发人员可以专注于构建功能而不是数据库而不是基础结构。 -* 创建快速发展的应用团队的关键：ACID 交易； 全局可序列化； 编写第一步交易，而不是十步工作流程； 编写查询而不是代码循环； 加盟 没有用户定义的冲突解决功能； 标准化同步； 即付即用，获得可预期的性能所需的费用。 - -Spanner 并非以成为 NewSQL 明星为目标。 Spanner 最初是 BigTable 克隆，带有分布式文件系统隐喻。 然后，Spanner 演变为全局 ProtocolBuf 容器。 最终，Spanner 受到 Google 内部客户的推动，以变得与关系和应用程序程序员更加友好。 - -显然，在 Google 内部使用 [Dremel](http://highscalability.com/blog/2010/8/4/dremel-interactive-analysis-of-web-scale-datasets-data-as-a.html) 已向开发人员表明，可以大规模使用 OLAP 和 SQL，他们希望 OLTP 应用具有相同的易用性和上市时间。 看来 Google 有很多应用程序可供开发，程序员不喜欢处理在最终一致的系统之上生产可靠产品的现实世界中的复杂性。 - -诀窍是弄清楚如何使 SQL 真正大规模地工作。 为了表明我们仍处于编程经验阶段的深度，该过程甚至花费了 Google 五年的开发时间。 亚历克斯说，真正的工作实际上是建立一个复杂的，可靠的分布式系统。 那是很难正确的部分。 - -在谈论原子钟等所有内容时，您可能会感到系统中存在魔力。 您可以进行巨大的跨表，跨数百万条记录的数据中心事务处理而不会受到任何损失。 那是不对的。 Spanner 是 OLTP 系统。 它使用两阶段提交，因此长时间的大型更新仍将锁定和阻止，程序员仍处于进入和退出的困境。 想法是这些限制值得程序员提高生产力，并且确实出现的任何瓶颈都可以逐案处理。 通过演讲，我逐渐感觉到，Spanner 的域中将包含诸如 pub-sub 之类的专用应用程序域。 尽管事务方面可能是常规事务，但除了所有的全局重新分区魔术在幕后透明进行之外，它们的事务时间戳方法在读取路径上确实具有很多不错的功能。 - -为说明每个 Paxos 组很难扩展到大量副本的困难，Alex 转向了水文隐喻： - -> 您可以将 Spanner 分区用作一种有序的 pub-sub 方案，在该方案中，您在某个分区的所有位置都有只读副本，并且您正试图使用​​它来以有序方式将数据分配给很多 不同的数据中心。 这带来了不同的挑战。 如果您没有足够的带宽访问那些数据中心的某些子集，该怎么办？ 您不希望数据在领导者中缓冲太久。 如果您将其溢出到磁盘上，那么当带宽可用时，您就不会招致搜索损失。 它变得像水文学。 您需要将所有这些数据在不同的时间发送到不同的位置，并且希望在变化的条件下使所有流平稳地移动。 平稳地意味着更少的服务器重启，意味着更好的延迟尾部，意味着更好的编程模型。 - -这也许是我最喜欢的部分。 我只是喜欢数据流过的图像，就像水滴从数百万台机器和网络中滴落，暂时聚集在内存和磁盘的洞穴中，总是分裂，总是重组，总是不断变化，总是不断进步，是巨大的不断流动的一部分 [数据周期](http://en.wikipedia.org/wiki/Water_cycle)永不丢失。 太棒了。 - -如果您有机会观看视频，我强烈建议您这样做，这的确很好，根本没有什么毛病。 关于在分布式事务中使用时钟的部分做得特别好。 但是，如果您时间紧缺，可以参考以下内容： - -* 5 年的努力。 -* NoSQL 规模的 SQL 语义。 -* 试图获得一个看起来像单个巨型 MySQL 的抽象。 -* 关系数据库是一个非常熟悉的生产环境，可以在其中建立应用程序。 -* Spanner 是存在证明，可以将关系数据库扩展到全局分布式存储系统。 -* 编写应用时无需考虑事务语义。 正确无误。 然后，您返回并优化一些高事务写入，这些优化将真正获得回报。 -* 希望向应用程序开发人员提供真正直接的语义。 应用程序开发人员应考虑业务逻辑而不是并发性。 -* 他们这样做的方式是通过构建具有绝对绝对误差的时钟。 然后将它们与时间戳分配集成在并发控制中： - * 时间戳的总顺序遵循事务的部分顺序。 如果交易 A 在交易 B 之前发生，我们知道交易 A 的时间戳小于交易 B 的时间戳。 - * 这意味着对所有内容进行有效的可序列化查询。 您可以将跨越数十个数据中心的 PB 级数据库的总和提高到一分钱。 可能需要一段时间才能获取所有数据。 但是您可以期望答案是正确的。 -* BigTable 早期的 NoSQL 数据库。 论文于 2006 年问世。 -* MegaStore 建立在 BigTable 之上。 它添加了 Paxos 同步层和更丰富的数据模型。 论文在 2011 年问世。 -* 底层架构中的 Spanner 很像 BigTable。 更新会附加到数据中心本地分布式文件系统中的日志中。 定期将它们压缩为不可变的 b 树（SSTables），并定期将这些 SSTable 合并在一起。 Leveldb 是一个开源版本。 -* 开发人员仍必须考虑如何对数据进行分区以提高效率，但开发人员应尽可能地专注于业务逻辑。 -* 目标不是数据重新分区的停机时间。 **Google 所做的一切都与数据移动息息相关，因为在数据中心之间移动用户和重新分片是一项持续的后台活动。** **因为这是一个连续的过程，所以各种并发性错误不断出现**。 事务有助于正确地分配其连续的分区流逻辑。 在进行交易之前，他们有很多错误，这就是为什么花了 5 年的时间的一部分。 -* 希望程序员减少在设计过程中早期做出的分区决策的束缚。 -* 希望获得 Megastore 最成功的部分： - * 处理大规模数据中心中断，而不会给用户带来明显影响。 - * 处理单元内部较小的中断，微中断。 示例：底层平板电脑因过载或损坏而中断，仅一个机架上的电源就中断了，等等。 - * 用户可能会在计时器触发时看到延迟增加，并且他们移至另一个数据中心，但看不到对事务语义的影响。 -* 但是 Megastore 有一些问题： - * 数据库被划分为一堆实体组。 实体组是他们自己的交易域，您不能跨实体组进行交易。 - * 它使用乐观并发。 当副本之间的传播间隔为 50 毫秒，而您正在执行同步复制时，写入将至少花费 50 毫秒，这将为乐观并发故障创建一个很大的漏洞窗口。 - * 将分层系统整合为单个集成系统的好处。 与 Megastore 和 Bigtable 之间的接口相比，Spanner 与物理存储之间的接口要丰富和优化。 -* 向 SQL 的文化转变 - * 基于 SQL 的分析系统 Dremel 在 Google 上进行了许多 SQL 转换，因为它可以将查询的语义向下推送到存储系统中，并让其确定该怎么做。 - * 这种文化根深蒂固，您可以扩展，也可以使用 SQL。 Dremel 表明，对于分析，您可以同时拥有。 Spanner 显示您可以同时使用 OLTP。 -* 由于业务问题，人们要求简化地理分区。 例如，将用户数据从一个区域移动到另一区域。 - * 法律问题 - * 产品增长意味着您想要尽可能高效地将多少人放到 -* 扳手的数据模型 - * 并不总是具有关系模型。 与 Jeff Dean 在 2009 年提出的内容完全不同。 - * 带有单个用户关系表的示例，每个用户都有一个名称和家庭区域。 - * User 数据库可以分为几个分区。 美国的一个只读分区，欧洲的另一个分区。 大型数据库将具有数百万个分区。 分区 1 在美国将具有三个副本。 另一个分区在欧洲具有三个副本。 美国有一个只读副本。 这很有用，因此您可以在欧洲拥有一个书面仲裁，这意味着您永远不会阻塞跨大西洋的 RPC 调用，但是在美国，尽管它可能有些陈旧，但您仍然可以查询所有数据。 - * 主细节层次结构在物理上被聚在一起。 在分布式系统上，更为重要的是记录将存储在其他服务器上。 - * 关系抽象的底层是程序员如何将密钥手动编码到 Bigtable 中。 每个表格单元格都只有一个条目，例如： - - * @ 10 部分是时间戳。 - * 在 Bob 记录开始之前，Alice 的订单将与 Alice 一起存储。 -* 并发 - * 在较高级别，Spanner 使用两阶段锁定和快照隔离的组合。 - * 并未尝试创建疯狂的新模型。 旨在找出如何扩展已验证模型的目标。 - * 此模型最适合读取为主的工作负载。 您将大部分时间花在便宜的快照隔离读取上，而不花大量时间在悲观主义事务写入上。 - * Blogger 示例，它首先担心正确性，然后担心优化。 - * Blogger 有 280 个 Servlet。 低频高复杂度操作，例如用户通过发送文本消息来创建博客，然后他们希望将该博客合并到现有博客中。 - * 花费大量的时间才能将其创建为由精心设计的工作流程精心安排的一系列幂等操作。 - * 使用 ACID 交易，Blogger 会更快。 在没有性能优势的情况下花费在这些复杂的编程任务上的时间本来可以减少某些高频页面的 50 毫秒，从而产生更大的整体影响。 - * 与在单台计算机上编程相同的过程。 您从互斥锁开始，然后才尝试原子操作。 - * 仅执行弱一致性的 NoSQL 数据库正在对整个系统实施广泛应用的过早优化。 应该选择值得的页面。 -* 在 Google 看到的模式中保留提交顺序 - * 他们在设计过程中考虑的经验法则： - * 如果 T1 在 T2 之前完成，那么他们想保留这一事实。 T2 与 T1 之间存在提交顺序相关性。 - * 假设 T3 写了一些 T4 读取的内容，因此存在传统的数据依赖性，因此 T3 必须始终在 T4 之前发生。 - * T1 和 T2 在 T3 和 T4 之间没有关系。 - * **系统性能来自并发运行没有依赖性的事务。** - * **目标是保留与原始历史记录相同的依存顺序。** - * 可序列化是一个带有大量变化的重载术语。 - * 线性化是从并发编程中借鉴的一种思想，并且很好地适用于在分布式数据库之上对分布式系统进行编程。 - * 包含可序列化性，无法上下班提交顺序。 - * 即使没有可检测的依存关系，即使一笔交易发生在另一笔交易之前，也必须保留该订单，即使该交易发生在不同的机器上。 - * 示例架构： - * 一个分区是购买的广告表。 在美国写仲裁，在欧洲写只读副本。 - * 这些广告的展示在美国的一个分区。 例如，在 2:00 和 2:01，有人观看了小狗广告。 - * 欧洲的一个分区，用于展示广告。 - * **在美国有一个只读的欧洲数据副本，反之亦然。 这样可以使双方进行过时的读取和快速的写入，而无需越过池塘。 您仍然可以在任何一侧高效地使用 MapReduce。** - * 交易示例： - * 交易 1：用户购买了广告。 - * 在后台，广告投放系统正在不断扫描分区以显示广告，并发送检索广告查询。 - * 广告投放系统会随着时间累积其要保存在数据库中的一批展示次数。 - * 事务 2：服务器写入印象分区以记录印象。 - * 这是两个不同的分区，不同的副本，不同的数据中心以及潜在的不同大陆。 - * 现在，您想编写一个 SQL 查询来审核小时级别的展示次数。 选择一个时间戳。 - * 根据时间戳记只有三个合法结果： - * 既看不到广告也看不见。 - * 看到广告，但没有展示。 - * 查看添加和所有展示。 - * 在所有系统中，他们都在替换 MapReduce 或查询必须容忍结果的无限变化。 - * 它可能会看到展示，但看不到广告。 - * **针对这种弱语义编写查询意味着很难分辨出腐败，错误或并发异常之间的区别。** - * 解决此问题的方法是通过单个中央服务器序列化每个更新。 如果更新位于一起，则有效，但不适用于分区遍布全球的分散式模型。 -* 在全球分布式数据库中扩展 Spanner 所需语义的选项： - * **一个分区模型** 。 大量的 WAN 通信。 将所有分区都包含在每个事务中。 - * **集中时间戳预言** 。 如果您同时在两个不同的大陆上进行更新，则效果不佳。 - * **Lamport 时钟** 。 通过每个外部系统和协议传播时间戳。 如果您的系统数量和协议数量都不足，则此方法有效，当您拥有大量不受控制的分布式系统或协议（例如与贸易伙伴一起使用）或它们只是协议时，您将无法正常工作 不碰。 在 Google 进行了几次尝试，但是在复杂的系统中始终无法成功完成时间戳。 - * **建立一个分布式时间戳预告片** 。 其中的一个 TrueTime 是 Google 常规时间清理产生的。 时间有一个 epsilon 时间，因此您知道进行现在呼叫的实时时间在该时间间隔内。 源自一堆不同数据中心中的 GPS 接收器，这些数据中心由原子钟备份。 GSP 系统有时确实存在错误。 一次代码推送可以消除大量卫星，因此备份非常有用。 -* TrueTime - * 目标不变式：写 A 和 B，如果 A 发生在 B 之前，则意味着 A 在 B 开始之前完成，那么 A 的时间戳应小于 B。完成意味着任何人都可以看到效果。 不仅是客户，还有 Paxos 奴隶。 - * 使用此不变式，意味着您可以说在特定时间戳记下的快照读取是可序列化的。 - * TrueTime 与天体导航的工作原理类似，只是那是硬错误界限，而不仅仅是猜测。 - * 每台 Google 服务器中都有一个时间守护程序，每台服务器中都有一个水晶，每个数据中心都有一些来自不同制造商的 GPS 的时间主控器，以解决错误的多样性，其中一些具有原子钟来交叉检查 GPS。 - * 守护程序每 30 秒与时间主对话，并获得时间修复。 在两者之间，死者根据自己的晶体进行侦察。 服务器错误容限随着时间的推移而扩大，他们选择了百万分之 200。 - * 现在几点了？ 在本地计算机上读取时间。 将 GetTime 发送到时间主机。 返回时间为 T。再次读取本地服务器时间。 你得到一些增量。 然后，您可以扩展该增量以获得所需的任何误差范围。 回来了一个ε。 现在您可以说时间在[t t + e）]中。 时间不早于 t，因为时间主因您收到 t 的回应而报告了 t 的因果关系。 但是会有很多偏差，因为邮件可能是在 epsilon 之前发送的。 您不知道往返 t 产生的位置。 开始漂移之前的主要错误是与主设备的往返时间。 - * 您可以建立 GPS 以外的其他系统来分配时间。 例如，LED 闪烁并为所有系统提供时钟脉冲。 使用心跳系统，该系统定期与中央服务器对话，并且在这些心跳之间，所有服务器都认为时间是固定的。 GPS 在那并且可以工作。 原子钟是一种方便的交叉检查。 而且所有硬件都不贵。 -* 当 Paxos 领导程序从客户端接收到提交请求时，该分区的 Paxos 领导程序流 - * 接收开始提交。 - * 获取事务锁定。 任何两阶段提交系统中的典型值。 抓住读写锁，以确保冲突的事务不会同时执行。 - * 选择一个时间戳记，以使 true.max 大于当前时间。 - * 并行执行两件事：运行 Paxos 以就写入内容达成共识，等待真正的时间肯定超过该写入时间戳记。 - * 通常，Paxos 将花费比等待更长的时间，因此它不会增加额外的开销。 - * 通知 Paxos 奴隶解锁。 - * 确认返回客户端。 -* 为什么起作用？ 通过等到提交时间戳记过去，我们将所有将来的事务推向更大的时间戳记。 保证下一个事务的时间戳大于前一个事务的时间戳。 **每个事务都同意选择一个比其起始点大的时间戳，并且每个事务都同意将其提交推迟到自己的提交时间戳记过去。** - * 当 Paxos 进行得太快或只有一个副本，而您只是要提交到本地磁盘时，TrueTime epsilon 可能比提交该提交所需要的时间大。 - * 当 TrueTime epsilon 达到峰值时发生，例如 TrueTime 母版下降并且您必须转到更远程的 TrueTime 母版的情况下。 或者当 Paxos 副本异常关闭时。 - * 现实中的 epsilon 在 1 到 7 毫秒之间反弹。 - * 当通过使用具有更高 QoS 的时间数据包来改进网络时，尾部延迟降低了。 < SDN 的一个论点，即通过系统以更高的 QoS 获得诸如时间和 Paxos 之类的控制数据包。 - * 通过更频繁地轮询时间主数据，以高 QoS 轮询，改善内核处理，在 NIC 驱动程序中记录时间戳，购买更好的振荡器，注意内核错误（节能模式（您使用的时钟））来减少 epsilon。 - -## 读取路径 - -* 类型： - * 在读取-修改事务中，看起来与标准的两阶段锁定相同，只是它发生在 Paxos 领导者身上。 获取读锁。 - * 不属于事务的强读取，客户端不会基于该读取进行写入。 Spanner 将选择一个更大的时间戳并在该时间戳上进行读取。 - * 当您只想知道数据已使用 5 或 10 秒时，就会读取陈旧的数据。 Spanner 将选择落入陈旧范围内的最大已提交时间戳。 - * MapReduce /批量读取-不在乎数据是否新鲜。 例如，让客户选择一个时间戳并说我想知道所有事情。 -* 为强读而选择的时间戳记： - * 问 TrueTime，现在的时间比现在大。 您知道这也大于所有先前提交的事务的提交时间戳。 并非总是最好的时间戳，因为您希望最大化能够在该时间戳上进行读取的副本。 - * 查看提交历史记录。 从最近的文章中选择一个时间戳。 - * 强制声明预读的范围。 例如，这 5 个用户和该系列产品。 范围的概念高于分区的概念。 - * 准备的分布式事务。 由于分布式事务必须在每个分区上同时提交时间戳，因此存在一个不确定性窗口，在此窗口中，您不会为某些对象提交什么数据来提交时间戳。 -* 有效使用原则： - * 数据局部性仍然很重要。 从一台机器上读取一堆东西比从一堆机器上读取要好。 将客户和订单放在同一分区中。 - * 大用户将跨越多个分区，但是跨分区在事务级别上不会产生语义影响。 - * 设计应用的正确性。 处理数百个需要处理但不需要那么快的细腻坚硬的角落案件。 例如，您一天更改几次 Gmail 过滤器？ - * 放宽仔细审核的高流量查询的语义。 也许在某些情况下，阅读会过时。 您过去读得越远，越能提供更多副本。 - * Spanner 中的默认语义是它们是可线性化的。 - * 使用闪存备份将允许毫秒写入。 -* 第一个大用户：F1 - * 已将对收入至关重要的共享 MySQL 实例迁移到 Spanner。 对 Spanner 数据模型的影响很大。 F1 需要一个强大的 MySQL。 - * Spanner 最初是 BigTable 之子 - * 包含许多分叉的 BigTable 代码，并带有分布式文件系统隐喻。 您有一棵目录树，每个目录都是地理位置的单位。 这与建立数据库的人无关。 - * 他们添加了结构化密钥，但最终他们只是在构建下一个 Megastore。 - * 他们决定 Spanner 需要更丰富的数据模型，从而确定 Spanner 是协议缓冲区的存储库。 Spanner 将是一个巨大的协议缓冲区。 这似乎是合理的，但同样，它不是用户建模数据的方式。 - * 他们认为 F1 是更好的模型，因此最终他们转向了关系数据模型。 - -## 他们现在在做什么？ - -* **完善 SQL 引擎**。 时间戳加迭代器的位置足以重启跨分区查询。 如果查询需要一分钟，并且负载平衡器在那一刻将您依赖的平板电脑移动到另一台服务器，或者该服务器被抢占，因为您正在共享单元中运行，并且抢占迫使这些平板电脑移动，查询会 不必中止，也不必扔掉工作。 像这样移动服务器很难工作，但对用户而言确实有价值。 -* **对内存使用情况的精细控制**，因此您无需创建分布式死锁，因为当一堆服务器都依赖于它们时，它们都需要内存才能取得进展，而它们都需要取得进展才能释放该内存 。 -* **细粒度的 CPU 调度**。 即使出现大得慢的大查询，也要保持快的查询快。应该对无希望的慢查询进行时间划分，以使快的查询保持快。 保持延迟的尾巴。 -* **基于快照隔离的强读取仍然非常绿色**。 这些正在以越来越多的用例进入生产。 -* **缩放到每个 Paxos 组**的大量副本。 您可以将 Spanner 分区用作严格有序的 pub-sub 方案，在该方案中，您在某个分区的所有位置都有只读副本，并且您正尝试使用它来以有序方式将数据分配到许多不同的数据中心。 这带来了不同的挑战。 如果您没有足够的带宽访问那些数据中心的某些子集，该怎么办？ 您不希望数据在领导者中缓冲太久。 如果您将其溢出到磁盘上，那么当带宽可用时，您就不会招致搜索损失。 它变得像水文学。 您需要将所有这些数据在不同的时间发送到不同的位置，并且希望在变化的条件下使所有流平稳地移动。 平稳地意味着更少的服务器重启，意味着更好的延迟尾部，意味着更好的编程模型。 - -## Q & A - -* 您如何证明交易之间没有依赖关系？ 假设某人通过电子邮件向某人发送了一些数据，然后该人单击了基于该数据的链接，从而导致了另一个数据中心的写入。 很难说两个不同中心之间的交易之间没有因果关系。 他们希望您能够在整个系统之间建立因果关系的前提下关联整个系统中事务的顺序。 -* 最终的一致性和交易模型的空间。 - * 移动是一种情况，用户在更新本地缓存，并且数据将其返回服务器，因此您不必依赖事务，因此必须具有某种最终的一致性机制来合并更改并处理冲突。 - * 允许并发编辑的 Google 文档是另一种情况。 您有五个打开的窗口，它们每个都在进行本地更新。 这些更新异步地冒泡回到服务器。 应用用于合并更新的可操作转换代数，然后才将这些更新应用于数据库的规范副本。 +# 关于 Disqus 的更新：它仍然是实时的，但是 Go 摧毁了 Python + +> 原文： [http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html](http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html) + +[![](img/c586fc50f256a62f6bb89ab1a5abdb14.png)](https://farm3.staticflickr.com/2937/14110625651_4d66420224_o.png) 我们上次在 Disqus 上发表的文章： [Disqus 如何以每秒 165K 消息且小于.2 秒的延迟](http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html)进行实时处理，虽然有些过时了，但是 Disqus 上的人们 一直在忙于实现，而不是在谈论，所以我们对他们现在在做什么并不了解，但是我们确实对 John Watson 的 [C1MM 和 NGINX](https://www.youtube.com/watch?v=yL4Q7D4ynxU) 作了简短的更新，并撰写了一篇文章 [出这个 Go 东西](http://blog.disqus.com/post/51155103801/trying-out-this-go-thing)。 + +因此，Disqus 增长了一些： + +* 13 亿独立访客 +* 100 亿页面浏览量 +* 5 亿用户参与讨论 +* 300 万个社区 +* 2500 万条评论 + +他们仍然都是关于实时的，但是 Go 在其 Realtime 系统中取代了 Python： + +* 原始的实时后端是用非常轻量级的 Python + gevent 编写的。 +* 实时服务是 CPU 密集型任务与大量网络 IO 的混合体。 Gevent 可以毫无问题地处理网络 IO，但是在更高的竞争中，CPU 阻塞了一切。 切换到 Go 消除了该争用，这是所看到的主要问题。 +* 仍可在 5 台 Nginx 机器上运行。 + * 使用 NginxPushStream，它支持 EventSource，WebSocket，Long Polling 和 Forever Iframe。 + * 所有用户都已连接到这些计算机。 + * 在正常的一天中，每台计算机看到 3200 个连接/秒，100 万个连接，150K 包/秒的 TX 和 130K 包/秒的 RX，150 mbit / s 的 TX 和 80 mbit / s 的 RC，从头到尾的< 15ms 延迟 结束（比 Javascript 渲染评论要快） + * 一开始有很多资源枯竭的问题。 给出了 Nginx 和 OS 的配置，可帮助缓解问题，对其进行调整以应对许多连接移动少量数据的情况。 +* 优先使用网络带宽。 + * 使用 10 千兆位网络接口卡很有帮助。 + * 启用 gzip 很有帮助，但是 Nginx 为 gzip 的每个连接预先分配了很多内存，但是由于注释很小，所以这太过分了。 降低 Nginx 缓冲区大小可以减少内存不足的问题。 +* 随着消息速率的提高，在每秒处理 10k +消息的高峰时，计算机达到了极限，在最坏的情况下，端到端延迟达到了数秒和数分钟。 +* 切换到 Go。 + * 节点未选择，因为它不能很好地处理 CPU 密集型任务。 + * Go 不能直接访问数据库。 它消耗 RabbitMQ 的队列并发布到 Nginx 前端。 + * 没有使用 Go 框架。 这是一个很小的组件，Disqus 的其余部分仍然是 Django。 + * 之所以喜欢 Go，是因为它的性能，本机并发性以及对 Python 程序员的熟悉程度。 + * 在短短一周内就建立了替换系统，并取得了令人瞩目的成果： + * 端到端延迟平均不到 10 毫秒。 + * 当前消耗大约 10-20％的可用 CPU。 大幅减少。 +* 他们想更好地利用资源，而不是增加更多机器： + * 对于已经完成的工作量，我们不想横向扩展更多。 向问题扔出越来越多的硬件并不总是最好的解决方案。 最后，拥有更快的产品也会产生自己的利益。 ## 相关文章 -* [Alex Lloyd-建筑扳手](http://vimeo.com/43759726) 视频（ [幻灯片](http://berlinbuzzwords.de/sites/berlinbuzzwords.de/files/slides/alex_lloyd_keynote_bbuzz_2012.pdf) ） -* [Google Spanner 的最令人惊讶的启示：NoSQL 出现了，NewSQL 出现了](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html) -* [面板：大数据，无需 SQL，大问题，无需担心](http://static.usenix.org/multimedia/hotstorage11seltzer) （ [幻灯片](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf) ）（ [视频](https://www.usenix.org/conference/hotstorage11/panel-big-data-no-sql-big-problems-no-worries) ） -* [互联网规模的企业问题](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf) +* [在黑客新闻](https://news.ycombinator.com/item?id=7711110)上/ [在 Reddit](http://www.reddit.com/r/Python/comments/2504ni/update_on_disqus_its_still_about_realtime_but_go/) 上 -伟大的帖子托德。 这些方法正在合并！ +对评论感兴趣的是，“ Go 不能直接访问数据库。它会占用 RabbitMQ 的队列并发布到 Nginx 前端”，但是我很难想象那里到底发生了什么。 可以再充实一点吗？ -您的文章内容丰富，但有时我会觉得有些困惑。 谢谢托德。 \ No newline at end of file +理查德：链接的谈话可能是您获得更多细节的最佳选择，但我认为想法是，Disqus 的实时系统通过 RabbitMQ 获得新评论并通过 nginx 发送通知-它不具有长期状态 数据库。 因为我们实质上是在这里讨论通知系统，所以这很有意义。 + +我和理查德在一起。 对发生故障时会发生什么感到好奇。 + +因此，您用流队列替换了 Django（ORM），您的结论是 Go 的性能优于 Python？ 它甚至与编程语言有什么关系？ + +通常，当人们更改语言时，他们也会更改应用程序的架构 + +但是很难看出提速的百分比来自于语言 + +@Velko，不，不是这样。 通过阅读有关其先前设置的文章，了解有关哪些部分发生了变化的更多信息。 + +我想知道他们是否尝试过使用 pypy。 以我的经验，使用 pypy 的 Python 和 Go 一样快。 + +[PyPy](http://pypy.org/) + +PyPy 是 Python 语言（2.7.9 和 3.2.5）的一种快速，兼容的替代实现。 它具有几个优点和独特的功能 + +通过阅读有关其先前设置的文章，了解有关哪些部分发生了变化的更多信息。 \ No newline at end of file diff --git a/docs/142.md b/docs/142.md index b361a41..1d37111 100644 --- a/docs/142.md +++ b/docs/142.md @@ -1,265 +1,65 @@ -# 更简单，更便宜，更快：Playtomic 从.NET 迁移到 Node 和 Heroku +# 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明 -> 原文： [http://highscalability.com/blog/2012/10/15/simpler-cheaper-faster-playtomics-move-from-net-to-node-and.html](http://highscalability.com/blog/2012/10/15/simpler-cheaper-faster-playtomics-move-from-net-to-node-and.html) +> 原文： [http://highscalability.com/blog/2014/5/19/a-short-on-how-the-wayback-machine-stores-more-pages-than-st.html](http://highscalability.com/blog/2014/5/19/a-short-on-how-the-wayback-machine-stores-more-pages-than-st.html) -![](img/f9ab322d6775cffd84a15e52504cfff4.png) +[![](img/6e2c7ef262b0ce58d944b649ddaa220d.png)](https://farm6.staticflickr.com/5524/14195687156_f1ff1631aa_o.jpg) -*这是 [Playtomic](https://playtomic.com/) 首席执行官 Ben Lowry 的特邀帖子。 Playtomic 是一项游戏分析服务，每天大约有 2 千万人在大约 8000 种移动，网络和可下载游戏中实施。* +[Wayback Machine](https://archive.org/web/web.php) 如何工作？ 现在，有超过[个索引](http://blog.archive.org/2014/05/09/wayback-machine-hits-400000000000/)的网页达 4000 亿个，可以一直浏览到 1996 年的互联网，这是一个更加引人注目的问题。 我看了好几次，但是我从来没有找到一个很好的答案。 -*这是 [Ben Lowry 在 Hacker News](http://news.ycombinator.com/item?id=4458124) ：*上的一个很好的摘要语录 +这是来自 Hacker News 上一个线程的一些信息。 它以 [mmagin](https://news.ycombinator.com/item?id=7723291) 开头，前存档员工： -> 昨天有超过 2 千万的人点击了我的 API 700,749,252 次，玩了我的分析平台集成的大约 8,000 款游戏，总播放时间不到 600 年。 就是昨天 有许多不同的瓶颈在等着人们大规模经营。 在我的用例中，Heroku 和 NodeJS 最终以非常便宜的价格缓解了很多。 - -Playtomic 始于几乎唯一的 Microsoft.NET 和 Windows 体系结构，该体系结构保持了 3 年，然后被 NodeJS 完全重写所取代。 在整个生命周期中，整个平台从单个服务器上的共享空间发展为完全专用，然后扩展到第二专用，然后将 API 服务器卸载到 VPS 提供程序和 4-6 个相当大的 VPS。 最终，API 服务器安装在 Hivelocity 的 8 台专用服务器上，每个服务器都具有超线程+ 8gb ram +运行 500 或 3 个 API 堆栈实例的双 500gb 磁盘的四核。 - -这些服务器通常为 30,000 至 60,000 个并发游戏玩家提供服务，每秒最多接收 1500 个请求，并通过 DNS 轮询实现负载平衡。 - -7 月，整个服务器群被 Heroku 托管的 NodeJS 重写所取代，以节省大量资金。 - -## 使用 NodeJS 扩展 Playtomic - -迁移包括两个部分： - -1. **专用于 PaaS** ：优势包括价格，便利性，利用其负载平衡和降低总体复杂性。 缺点包括没有用于 NodeJS 的 New Relic，非常小的崩溃以及通常不成熟的平台。 -2. **.NET 到 NodeJS** ：将具有本地 MongoDB 实例和服务预处理事件数据的 ASP.NET/C#体系结构切换到本地，然后将其发送到集中式服务器以完成操作； 到 Heroku + Redis 上的 NodeJS 以及 SoftLayer 上的预处理（请参见 Catalyst 程序）。 - -## 专用于 PaaS - -复杂性的降低是显着的； 我们在托管合作伙伴 Hivelocity 拥有 8 台专用服务器，每台服务器运行 3 或 4 个 API 实例。 每个人都运行一小套软件，其中包括： - -* MongoDB 实例 -* 日志预处理服务 -* 监视服务 -* 带有 api 网站的 IIS - -部署是通过 FTP 脚本完成的，该脚本将新的 api 站点版本上载到所有服务器。 服务更讨厌部署，但很少更改。 - -MongoDB 对于在预处理和发送日志之前临时保存日志数据是一个糟糕的选择。 它提供了最初只写内存的巨大速度优势，这意味着写请求几乎立即就“完成”了，这远远优于 Windows 上的常见消息队列，但是它从未回收已删除数据留下的空间，这意味着 db 大小会膨胀到 如果不定期压缩，则超过 100 GB。 - -PaaS 提供商的优势是众所周知的，尽管它们似乎最成熟并且拥有广泛的技术支持，但对 Heroku 和 Salesforce 的信心最容易，尽管看上去最相似。 - -过渡到 PaaS 的主要挑战是，人们像在专用服务器上那样，可以与网站一起运行辅助软件的想法已经动摇。 大多数平台都提供了一些可以利用的后台工作线程，但这意味着您需要通过 3 rd 第三方服务或服务器来路由 Web 线程中的数据和任务。 - -我们最终选择在 Softlayer 上的大型服务器上运行了十二个特定目的的 Redis 实例和一些中间件，而不是后台工作程序。 Heroku 不对出站带宽收费，而 Softlayer 不对入站带宽收费，这巧妙地避免了所涉及的大量带宽。 - -## 从.NET 切换到 NodeJS - -在服务器端使用 JavaScript 是一种混合体验。 一方面，缺乏形式和样板正在解放。 另一方面，没有 New Relic，也没有编译器错误，这使所有事情都变得比原本困难。 - -有两个主要优点，这使得 NodeJS 对于我们的 API 极为有用。 - -1. **后台工作程序**与 Web 服务器位于相同的线程和内存中 -2. **与 Redis 和 mongodb 的持久共享连接** - -### 后台工作者 - -NodeJS 具有非常有用的功能，可以独立于请求继续工作，允许您预取数据和其他操作，这些操作可以让您非常早地终止请求，然后完成对它的处理。 - -对于我们而言，将整个 MongoDB 集合复制到内存中（定期刷新）是特别有利的，这样，整个工作类都可以访问当前数据，而不必使用外部数据库或本地/共享缓存层 。 - -在以下条件下，我们每秒总共节省 100 至 1000 的数据库查询： - -* 主 api 上的游戏配置数据 -* 数据导出 api 上的 API 凭据 -* GameVars，开发人员用来存储配置或其他数据以将其热加载到他们的游戏中 -* 排行榜得分表（不包括得分） +> 我不能说说他们目前的基础架构（尽管现在更多的是开源的-http://archive-access.sourceforge.net/projects/wayback/），但是就回溯机器而言， 任何地方都没有 SQL 数据库。为了使 Wayback 机器运行： +> +> * 存档数据为 ARC 文件格式（http：// en 的前身）。 wikipedia.org/wiki/Web_ARChive），实质上是单独压缩的记录的串联。 也就是说，您可以寻求特定的偏移量并开始对记录进行解压缩。 因此，您可以使用三元组（服务器，文件名，文件偏移量）访问任何已归档的网页，从而将其散布在许多商品级机器上。 +> * 构建了所有内容的排序索引，该索引使您可以查找（url）并提供时间列表或（url，time）到（文件名，文件偏移）。 它是通过构建一个排序的文本文件（首先在 url 上排序，第二次在时间上排序）并通过简单地将其拆分为 N 个大致相等的大小在多台计算机上分片来实现的。 在排序后的文本文件中进行二进制搜索的速度之快令人惊讶，部分原因是您在文件中查看的前几点仍然被缓存在 RAM 中，因为您经常点击它们。 +> * （这是我有点生锈的地方），Web 前端会收到一个请求，查询适当的索引机。 然后，它将使用一种小机制（可能是网络广播？）来查找（唯一）文件名所在的服务器，然后从该服务器请求特定记录。 +> * （编辑：仅供参考，我的知识已有 5 年了。我知道他们做了一些事情，以使该指数比当时更先进。） +> +> 至少，我会考虑将 blob 移出 MySQL 并将其放入文件系统中。 文件系统擅长于此。 您当然可以做一些像文件名一样的内容的 SHA-1 哈希这样简单的事情，然后根据文件系统的性能特征，在存储它们的树中可以有几个级别。 da39a3ee5e6b4b0d3255bfef95601890afd80709 进入目录 da / 39 /，然后将 da39a3ee5e6b4b0d3255bfef95601890afd80709 插入表的“指针”字段中，以替换实际数据。 显然，此设计假定 _that_ 文件的内容不变。 如果要更改表中该行的数据，则必须在文件系统中写入一个新文件并更新“指针”。 -基本模型是： +互联网档案[的 sam 和 raj 回复了](https://news.ycombinator.com/item?id=7723726)： -> var cache = {}; +> Thanks! We were writing up a response at the same time:The Wayback Machine data is stored in WARC or ARC files[0] which are written at web crawl time by the Heritrix crawler[1] (or other crawlers) and stored as regular files in the archive.org storage cluster. > -> module.exports = function（request，response）{ -> response.end（cache [“ x”]）; -> } +> 播放是通过对 WARC 数据中的指针的 2 级索引进行二进制搜索来完成的。 该索引的第二层是一个 20TB 压缩的（URL，日期，指针）元组的排序列表，称为 CDX 记录[2]。 第一级适合核心，它是 CDX 索引中每 3000 个条目的 13GB 排序列表，并带有指向较大 CDX 块的指针。 > -> 函数 refresh（）{ +> 索引查找的工作方式是二进制搜索存储在核心中的第一级列表，然后 HTTP 范围请求从 CDX 索引加载适当的第二级块。 最后，通过 CDX 记录指向的范围请求 WARC 数据加载网页数据。 在最终输出之前，将应用链接重写和其他转换以使回放在浏览器中正常工作。 > -> //从数据库中获取更新的数据，存储在缓存对象 -> 中。cache [“ x”] =“ foo”; -> setTimeout（refresh，30000）; -> } +> 服务器堆栈： > -> refresh（）; - -这样做的优点是，您可以与后端数据库建立单个连接（每个 dyno 或实例），而不是每个用户建立一个连接，并且具有非常快的本地内存缓存，该缓存始终具有新数据。 - -注意事项是您的数据集必须很小，并且此线程与其他所有线程都在同一线程上运行，因此您需要意识到阻塞线程或执行过多的 CPU 工作。 - -### 持久连接 - -NodeJS 通过.NET 为我们的 API 提供的另一个巨大好处是持久性数据库连接。 在.NET（等）中进行连接的传统方法是打开您的连接，进行操作，然后将您的连接返回到池中，以便在短期内不再使用或不再使用时可以重新使用。 - -这是很常见的，除非达到很高的并发性，否则它将正常工作。 并发率很高，因此连接池无法足够快地重用连接，这意味着它会生成新连接，数据库服务器必须扩展这些连接才能处理。 +> * 前端：Tengine + HAProxy 到 Wayback Tomcat 应用程序服务器池[3] +> * 后端：Redis 支持的 archive.org 元数据 API [4]用于对象定位，而 nginx 在 linux 上（通过 ext4）用于数据服务 +> +> * [0] http://en.wikipedia.org/wiki/Web_ARChive +> * [1] https://github.com/internetarchive/heritrix3 +> * [2] https://github.com/internetarchive/CDX-Writer +> * [3] https://github.com/internetarchive/wayback +> * [4] http://blog.archive.org/2013/07/04/metadata-api/ -在 Playtomic，我们通常有数十万并发游戏玩家正在发送事件数据，这些事件数据需要被推回到不同数据中心中的 Redis 实例，而使用.NET 则需要大量 连接数量–这就是为什么我们在每台旧专用服务器上本地运行 MongoDB 的原因。 +sytelus [问](https://news.ycombinator.com/item?id=7724051)：为什么不使用哈希表而不是二进制搜索？ -使用 NodeJS，每个 dyno /实例具有单个连接，该连接负责推送特定 dyno 接收的所有事件数据。 它位于请求模型之外，如下所示： +gojomo [回复了](https://news.ycombinator.com/item?id=7724347)： -> var redisclient  = redis.createClient(….); +> 这里是前存档员工（&还是偶尔的合同贡献者）。 这是我在 2003 年加入时的第一个问题！ > -> module.exports = function（request，response）{ +> 某些 Wayback Machine 查询需要经过排序的键遍历：列出可以捕获 URL 的所有日期，发现 URL 的最近日期，并列出所有以某个 URL 前缀开头的可用 URL。 > -> var eventdata =“ etc”; +> 维护（URL，日期，指针）的规范排序主索引（20TB 二级索引 rajbot 提到）可以满足两种查询。 一旦有了该工件，就可以相当高效地满足各个捕获查找的需求。 （然后，分布式哈希表将需要额外维护。） > -> redisclient.lpush（“ events”，eventdata）; +> 同样，查询也不是随机的：存在热范围，甚至单个用户的会话都从范围查询（URL 的所有日期）开始，然后访问相同范围的一个 URL。 然后，加载页面内联资源的最近日期捕获开始达到相似的范围，后续点击链接或附近日期也是如此。 因此，即使主索引仍在旋转的磁盘上（除非最近发生了一次重大的 SSD 升级，以免引起了我的注意），但浏览范围却经常出现在主内存缓存中。 > -> } - -### 最终结果 - -**高负载：** - -最后一刻的要求 - -* * * - -_exceptions：75 （0.01％） _ 失败：5 （0.00％） 总计：537,151 （99.99％） data.custommetric.success：1,093 （0.20％） data.levelaveragemetric.success ：2,466 （0.46％） data.views.success：105 （0.02％） events.regular .invalid_or_deleted_game＃2：3,814 （0.71％） events.regular.success：527,837 （98.25％） gamevars.load.success：1,060 （0.20％） geoip.lookup.success：109 （0.02％） Leaderboards.list.success：457 （0.09％） Leaderboards.save.missing_name_or_source＃201：3 （0.00％） 排行榜。保存。成功：30 （0.01％） 。 -排行榜.saveandlist。成功：102 （0.02％） playerlevels.list.success：62 （0.01％） playerlevels.load.success：13 （0.00％） - -* * * - -此数据来自在每个实例的后台运行的一些负载监控，将计数器推送到 Redis，然后将其汇总并存储在 MongoDB 中，您可以在 [上查看它们的运行情况 https://api.playtomic.com/load.html](https://api.playtomic.com/load.html) 。 - -该数据中有几种不同的请求类别： - -* **事件** 从 MongoDB 检查游戏配置，执行 GeoIP 查找（开源的非常快速的实现，网址为 https://github.com/benlowry/node-geoip-native） ，然后推送到 Redis -* **GameVars ， 排行榜，玩家级别** 都从 MongoDB 中检查游戏配置，然后再检查相关的 MongoDB 数据库 -* **数据** 查找被代理到 Windows 服务器，因为 NodeJS 对存储过程的支持不佳 - -The result is 100,000s of concurrent users causing spectactularly light Redis loads fo 500,000 – 700,000 lpush’s per minute (and being pulled out on the other end): - - 1  [||                                                                                      1.3%]     Tasks: 83; 4 running - 2  [|||||||||||||||||||                                                                    19.0%]     Load average: 1.28 1.20 1.19 - 3  [||||||||||                                                                              9.2%]     Uptime: 12 days, 21:48:33 - 4  [||||||||||||                                                                           11.8%] - 5  [||||||||||                                                                              9.9%] - 6  [|||||||||||||||||                                                                      17.7%] - 7  [|||||||||||||||                                                                        14.6%] - 8  [|||||||||||||||||||||                                                                  21.6%] - 9  [||||||||||||||||||                                                                     18.2%] - 10 [|                                                                                       0.6%] - 11 [                                                                                        0.0%] - 12 [||||||||||                                                                              9.8%] - 13 [||||||||||                                                                              9.3%] - 14 [||||||                                                                                  4.6%] - 15 [||||||||||||||||                                                                       16.6%] - 16 [|||||||||                                                                               8.0%] - Mem[|||||||||||||||                                                                 2009/24020MB] - Swp[                                                                                    0/1023MB] - - PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command -12518 redis     20   0 40048  7000   640 S  0.0  0.0  2:21.53  `- /usr/local/bin/redis-server /etc/redis/analytics.conf -12513 redis     20   0 72816 35776   736 S  3.0  0.1  4h06:40  `- /usr/local/bin/redis-server /etc/redis/log7.conf -12508 redis     20   0 72816 35776   736 S  2.0  0.1  4h07:31  `- /usr/local/bin/redis-server /etc/redis/log6.conf -12494 redis     20   0 72816 37824   736 S  1.0  0.2  4h06:08  `- /usr/local/bin/redis-server /etc/redis/log5.conf -12488 redis     20   0 72816 33728   736 S  2.0  0.1  4h09:36  `- /usr/local/bin/redis-server /etc/redis/log4.conf -12481 redis     20   0 72816 35776   736 S  2.0  0.1  4h02:17  `- /usr/local/bin/redis-server /etc/redis/log3.conf -12475 redis     20   0 72816 27588   736 S  2.0  0.1  4h03:07  `- /usr/local/bin/redis-server /etc/redis/log2.conf -12460 redis     20   0 72816 31680   736 S  2.0  0.1  4h10:23  `- /usr/local/bin/redis-server /etc/redis/log1.conf -12440 redis     20   0 72816 33236   736 S  3.0  0.1  4h09:57  `- /usr/local/bin/redis-server /etc/redis/log0.conf -12435 redis     20   0 40048  7044   684 S  0.0  0.0  2:21.71  `- /usr/local/bin/redis-server /etc/redis/redis-servicelog.conf -12429 redis     20   0  395M  115M   736 S 33.0  0.5 60h29:26  `- /usr/local/bin/redis-server /etc/redis/redis-pool.conf -12422 redis     20   0 40048  7096   728 S  0.0  0.0 26:17.38  `- /usr/local/bin/redis-server /etc/redis/redis-load.conf -12409 redis     20   0 40048  6912   560 S  0.0  0.0  2:21.50  `- /usr/local/bin/redis-server /etc/redis/redis-cache.conf - -and very light MongoDB loads for 1800 – 2500 crud operations a minute: - -insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time -    2      9      5      2       0       8       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     7k   116   01:11:12 -    1      1      5      2       0       6       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     2k     3k   116   01:11:13 -    0      3      6      2       0       8       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k     6k   114   01:11:14 -    0      5      5      2       0      12       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     5k   113   01:11:15 -    1      9      7      2       0      12       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     4k     6k   112   01:11:16 -    1     10      6      2       0      15       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     1|0     4k    22k   111   01:11:17 -    1      5      6      2       0      11       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k    19k   111   01:11:18 -    1      5      5      2       0      14       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     3k   111   01:11:19 -    1      2      6      2       0       8       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k     2k   111   01:11:20 -    1      7      5      2       0       9       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     2k   111   01:11:21 -insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time -    2      9      8      2       0       8       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     5k   111   01:11:22 -    3      8      7      2       0       9       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     9k   110   01:11:23 -    2      6      6      2       0      10       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k     4k   110   01:11:24 -    2      8      6      2       0      21       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k    93k   112   01:11:25 -    1     10      7      2       3      16       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     4m   112   01:11:26 -    3     15      7      2       3      24       0  6.67g  14.8g  1.23g      0      0.2          0       0|0     0|0     6k     1m   115   01:11:27 -    1      4      8      2       0      10       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     2m   115   01:11:28 -    1      6      7      2       0      14       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     3k   115   01:11:29 -    1      3      6      2       0      10       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k   103k   115   01:11:30 -    2      3      6      2       0       8       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k    12k   114   01:11:31 -insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time -    0     12      6      2       0       9       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k    31k   113   01:11:32 -    2      4      6      2       0       8       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k     9k   111   01:11:33 -    2      9      6      2       0       7       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     3k    21k   111   01:11:34 -    0      8      7      2       0      14       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     4k     9k   111   01:11:35 -    1      4      7      2       0      11       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     3k     5k   109   01:11:36 -    1     15      6      2       0      19       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     5k    11k   111   01:11:37 -    2     17      6      2       0      19       1  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     6k   189k   111   01:11:38 -    1     13      7      2       0      15       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     1|0     5k    42k   110   01:11:39 -    2      7      5      2       0      77       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     2|0    10k    14k   111   01:11:40 -    2     10      5      2       0     181       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0    21k    14k   112   01:11:41 -insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time -    1     11      5      2       0      12       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     0|0     4k    13k   116   01:11:42 -    1     11      5      2       1      33       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     3|0     6k     2m   119   01:11:43 -    0      9      5      2       0      17       0  6.67g  14.8g  1.22g      0      0.1          0       0|0     1|0     5k    42k   121   01:11:44 -    1      8      7      2       0      25       0  6.67g  14.8g  1.22g      0      0.2          0       0|0     0|0     6k    24k   125   01:11:45 - -## 相关文章 - -* [新的 API 服务器：Heroku 和 NodeJS 与专用和.NET](https://playtomic.com/blog/post/86-the-new-api-server-heroku-an) -* [日志处理，从无到有，每天发生十亿个事件](https://playtomic.com/blog/post/68-log-processing-from-nothing) -* [每天在预算范围内实时处理超过 3 亿个事件](https://playtomic.com/blog/post/53-handling-over-300-million-ev) -* [回顾 2010 年-从每月 4000 万事件到每天 3 亿](https://playtomic.com/blog/post/46-looking-back-on-2010) -* [四种让玩家爱上您的游戏的方式](http://www.gamasutra.com/blogs/BenLowry/20111116/8914/Four_ways_to_keep_players_in_love_with_your_game.php) -* [已发布 InkTd Flash 游戏源代码](http://www.emanueleferonato.com/2012/04/19/inktd-flash-game-source-code-released/) -* [黑客新闻主题](http://news.ycombinator.com/item?id=4615799)的相关评论 -* [Heroku 成功案例页面](http://success.heroku.com/playtomic) -* [关于黑客新闻](http://news.ycombinator.com/item?id=4655718) - -Redis 和 MongoDB 嗯...。 好文章 - -这是一篇很棒的文章，感谢您的分享。 - -因此，您切换了三件事：体系结构，部署/操作模型和运行时。 -多汁的标题指的是第三部分，它可能是更改的最不重要的部分，而成本最高的部分（因为它需要完全重写）。 - -不要误会我的意思-我爱我一些 node.js，并且我是 Heroku 的忠实拥护者，但是.NET impl 中指出的所有警告很容易（或不太容易，但比完全重写要容易得多） ）可寻址。 因此，您*可以*通过优化现有代码库（而不是重写）并迁移到具有 AppHarbor，Azure 的易于部署的模型（或在 Heroku 上运行 Mono）来获得类似的结果。 而且您还会有 New Relic :) - -很想听听您对完整重写的成本收益平衡的看法 - -写得好！，我们曾经做过类似的事情。 当我们的集合太大时，Node GC 将暂停很长一段时间，并最终会因 JS 内存不足错误（大约 2 Gig）而崩溃。 我们最终创建了一个 NodeJS C ++插件来存储 V8 堆之外的数据，这实际上使我们可以将驻留在内存中的缓存扩展到超过 10 个 Gig。 - -我对 Node.JS 不太了解，但是 devdazed 的评论提出了我无法解决的问题。 在哪个星球上，NodeJS 内置的 GC 比 JVM（或.NET）更好？ - -我猜不能与成功争辩-这对他们是有用的。 但是很难相信在 JVM 或.NET 环境中无法轻松实现同一目标，在这些环境中，您不会遇到与 GC 相关的陷阱。 或者至少您发现的那些是众所周知的。 - -这是一本不错的书，但是我没有得到一些要点： -1.后台工作者。 通过创建一个新线程，Asp.net 可以轻松地做到这一点。 唯一应注意的事情是不会在该线程中引发未处理的异常。 -2.持久连接。 为什么不仅仅拥有一个静态的 MongoServer 实例（它是线程安全的类）呢？ MongoCollection 类也是线程安全的。 所以我们甚至可以有一个静态的集合实例 - -究竟是什么使您用 Node.js 取代.NET？ ASP.NET 完全支持异步。 通过从.NET 切换到节点，您还可以获得“沉重”（如 3-10 倍）的性能。 如果您的应用切换到 node.js 之后变得更快，那么您首先在.net 方面做错了什么。 - -您也可以随意处理数据库连接。 您可以使用[ThreadStatic]或其他某种机制使每个线程保持一个打开状态。 - -@Dmitry： - -并不是说我是该领域的专家（也不认为 Node 是灵丹妙药），但也许我会说一些话来为您澄清一下： - -1.我不会依赖 ASP.NET 来执行后台任务，因为该实现通常非常脆弱。 ASP.NET 根本不是为此目的而设计的，我想如果您想通过 ASP.NET 应用程序上下文中的线程 API 实现后台工作程序，则需要一个非常非常好的理由。 我宁愿选择 WCF 服务作为 Windows 服务托管，它更可靠。 - -2.的确如此，拥有静态的 MongoServer / MongoDatabase 实例将使您在应用程序域的整个生命周期中都具有持久的连接。 最后一部分很重要，因为 ASP.NET 应用程序可以出于多种原因（计划的应用程序池回收，web.config 或应用程序文件夹更改等）重新启动。 而且我认为 Node 在这方面更可靠。 - -但总的来说，我同意其他人的观点，即完全没有必要完全重写（以及移至 Node）（但我认为他们也知道自己在做什么）。 - -What on earth made you replace .NET with Node.js? ASP.NET supports asynchrony to the fullest. You also take a *heavy* (like 3-10x) perf hit by switching to node from .NET. If your app got faster after switching to node.js you did something wrong on the .net side in the first place. - -You are also free to handle your DB connections however you want. You could have kept one open per thread for example with [ThreadStatic] or some other mechanism. +> 毫无疑问，有许多地方可以改进，但是这种基本的排序索引模型已经很适合该应用程序很长时间了，避免了过多的特定于领域的复杂性，并且适用于许多代索引/分片/复制/内部- API 调整。 +> +> 顺便说一句，Archive 正在招聘多个技术职位，其中包括负责开发下一代 Wayback Machine 的高级职位：https：//archive.org/about/jobs.php -最近所有的 node.js 文章都有什么？ +[Vecrios](https://news.ycombinator.com/item?id=7723794) 中的一个有趣的问题：我仍然无法理解它们如何存储大量数据并且不会用完空间？ -是的，node.js 速度很快，但是它缺少太多基本功能，因此当您重写所有模块时，“神奇”的速度优势将不复存在，而且整个代码库将成为一堆不断调用自身的回调 ，进行简单的更改需要您分析整个过程，就像穿针一样。 +dwhly [回答](https://news.ycombinator.com/item?id=7724035)： -Node.js 令人头疼。 +> 几年前与 Brewster 的一次对话中：磁盘驱动器的密度加倍使它们在 Wayback 机器的空间方面保持相对中性。 它仍然占据着与过去 10 年大致相同的尺寸，我认为这实际上是一组大约 15-20 英尺长的机架。 +> +> 但是，新的电视新闻和搜索功能所需的空间甚至远远超过 IIRC 档案库，或者肯定正在朝这个方向发展。 -我们正在将 StatsD + Graphite 与我们的企业 Node 应用一起使用。 有了它，您可以轻松免费地免费获得 New Relic。 +并感谢 [rietta](https://news.ycombinator.com/item?id=7724313) 所说的 Wayback Machine 如何在银河系中存储比星星更多的页面。 神话般的图像。 -哇，这家伙真的很喜欢过度设计！ 在 API 客户端中使用 boost（并迫使 android 用户使用自定义 SDK 进行编译，这对于使用 malkade skd 的用户而言更加痛苦）。 \ No newline at end of file +据我了解，大约在 2000 年开始出现 GMR（巨磁阻比）读取磁头，从而使硬盘容量每年翻一番（甚至更多）。 我记得在 2000 年，典型的硬盘驱动器为 2 到 4 GB。 当然，现在是 5 到 10 TB，而它们增加到约 20 TB。 因此，我完全不难理解 Wayback 机器如何在硬盘大小相同的情况下保存“足够”的数据。 \ No newline at end of file diff --git a/docs/143.md b/docs/143.md index ece939d..d8e2c36 100644 --- a/docs/143.md +++ b/docs/143.md @@ -1,104 +1,170 @@ -# UltraDNS 如何处理数十万个区域和数千万条记录 +# 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集 -> 原文： [http://highscalability.com/blog/2012/10/8/how-ultradns-handles-hundreds-of-thousands-of-zones-and-tens.html](http://highscalability.com/blog/2012/10/8/how-ultradns-handles-hundreds-of-thousands-of-zones-and-tens.html) +> 原文： [http://highscalability.com/blog/2014/6/16/migrating-to-xtradb-cluster-in-ec2-at-pagerduty.html](http://highscalability.com/blog/2014/6/16/migrating-to-xtradb-cluster-in-ec2-at-pagerduty.html) -![](img/b27dad94d59a8812e517ea44a846a9a9.png) +![](img/cdb2e4247da951758fbc13791ce84010.png) -*这是 [Neustar](http://twitter.com/jeffreydamick) 的首席软件工程师 [Jeffrey Damick](http://twitter.com/jeffreydamick) 的来宾帖子。 Jeffrey 在过去两年半的时间里，对 [UltraDNS](http://www.ultradns.com) 的软件体系结构进行了全面的复兴。* +*这是软件通才 [Doug Barth](https://twitter.com/dougbarth) 的来宾帖子，他目前发现自己在 [PagerDuty](https://www.pagerduty.com/) 从事运营工作。 在加入 PagerDuty 之前，他曾在芝加哥的 Signal 和在线旅游公司 Orbitz 任职。* -UltraDNS 是顶级 DNS 提供商之一，为许多[顶级域（TLD）](http://en.wikipedia.org/wiki/Top-level_domain)以及[二级域（SLD）](http://en.wikipedia.org/wiki/Second-level_domain)提供服务。 这需要处理数十万个区域，每个区域包含数百万个记录。 尽管 UltraDNS 取得了全部成功，但几年前它却陷入了一片混乱，其发布计划充其量只是一个杂乱无章的事情，并且该团队仍在努力以瀑布式开发风格满足功能要求。 +大约六个月前，PagerDuty 将其生产 MySQL 数据库切换为在 EC2 内部运行的 [XtraDB 群集](http://www.percona.com/software/percona-xtradb-cluster) 。 这是我们为什么以及如何进行更改的故事。 -## 发展历程 +## 在之前的数据库外观 -意识到必须要做的事情，团队聚在一起，确定了首先要进攻的最重要区域。 我们从代码库入手，稳定了我们的旗舰专有 C ++ DNS 服务器，建立了通用的最佳实践和自动化。 测试是非常手工的，并且不容易重现，因此我们将质量检查工程师和开发人员紧密联系在一起，以创建和审查设计，代码和自动化测试。 他们的目标是消除交付物的可变性。 我们介绍了以下工具： +PagerDuty 的 MySQL 数据库是相当典型的部署。 我们有： -* 单元测试：gtest -* 性能测试：dnsperf（已修改）&定制 pcap 工具 -* 静态分析：cppcheck -* 测试&构建自动化：Jenkins -* 任务跟踪：吉拉 -* 代码评论：鱼眼和坩埚 -* 通用框架：基于 Boost 的选定部分 +* 一对 Percona 服务器将数据写入支持 [DRBD](http://www.drbd.org/) 的卷。 -## 环境 +* 支持 DRBD 卷的主服务器和辅助服务器的 EBS 磁盘。 -我们的各种部署环境（包括生产环境）是另一个需要立即关注的领域。 这些环境缺乏任何同质性。 数十种口味和版本的 Linux 被积极使用。 由于目标数量众多，没有统一性的开发非常复杂且容易出错，因此我们对 1 个发行版的 1 个版本进行了标准化。 为了获得更好的安装和相关软件包的可复制性，我们选择 puppet 来管理此任务。 我们采用了以下内容： +* 生产数据库的两个同步副本。 （如果主服务器发生故障，我们希望能够快速切换到辅助服务器而不丢失任何数据。） -* 发行：RHEL（移至 Ubuntu） -* 配置管理：人偶 -* 指标制图：石墨 -* 监控：Nagios +* 许多异步复制从属服务器，用于灾难恢复，备份和意外修改恢复。 -## 建筑 +## 旧设置出现问题 -为了保持市场竞争力，需要 DNSSEC，增强的定向答案和增强的流量服务等功能。 当前的体系结构很大程度上基于 Oracle，以至于它直接影响了我们 DNS 服务器的每秒查询（QPS）速率。 +我们的数据库设置已经为我们服务了好几年，但是它提供的故障转移架构没有达到我们的可靠性目标。 另外，更改主机很麻烦：要从一台 DRBD 主机切换到另一台主机，我们必须在主服务器上停止 MySQL，卸载 DRBD 卷，将辅助服务器更改为主服务器状态，在该辅助服务器上安装该卷并启动 MySQL。 该设置需要停机-并且一旦 MySQL 在新服务器上启动并运行，我们就有了一个冷缓冲池，需要在应用程序性能恢复正常之前进行预热。 -UltraDNS DNS 服务器需要有效地支持具有独特使用模式的 TLD 和 SLD。 TLD 通常包含数百万条记录，并且不经常（通常每天）更改，但是更改可能占记录的很大一部分。 SLD 是较小的区域，记录在数万至数十万之间，但变化率较高，占记录的百分比较小。 +我们尝试使用 Percona 的 buffer-pool-restore 功能来缩短停机时间，但是我们的缓冲池太大了。 我们发现，恢复保存的缓冲池页面使用的系统资源要比缓慢处理传入请求的流量要多。 -所有类型都要求尽快在全局范围内传播更改。 DNSSEC 带来了额外的麻烦，因为签名记录集以及对它们进行签名的密钥必须一起在边缘可用。 因此，我们构建了 DNSSEC 区域签名服务来满足我们对速度和扩展功能的要求。 +另一个问题：如果发生计划外的翻转，我们的异步奴隶将无法恢复。 我们将 binlog 存储在单独的，非 DRBD 支持的磁盘上，并禁用了 sync_binlog（由于引入了性能上的损失）。 这种设置意味着我们需要在计划外翻转之后从备份中还原异步从属服务器。 -但是我们仍然需要确保将区域的正确状态呈现给我们的 DNS 服务器并以有效的方式进行传输，因此我们用 Java 创建了专门的数据馈送服务。 我们利用 Thrift 及其基于 HTTP 的紧凑编码，使我们能够轻松地使用标准 Web 缓存进行扩展。 +## 我们喜欢 XtraDB 群集 -### 数据馈送服务： +关于 XtraDB Cluster 的一些事情很突出。 -* 数据存储：嵌入式 OrientDB -* 传输：使用码头& apache-cxf 通过类似 HTTP REST 的接口进行节俭 -* 测试：Cucumber-jvm -* 静态分析：pmd，checkstyle -* 代码覆盖率：JaCoCo -* 依赖管理：常春藤 +* 不用拥有主动和被动服务器对，我们可以让 三个 实时服务器在彼此之间同步复制更改。 这将使我们能够更快地移动连接。 -结果，我们的 DNS 服务器能够迁移到一个模型，该模型将几乎每个区域都保留在内存中，同时通过无锁管道提供数据。 这带来了显着的性能改进，从而使每个 DNS 服务器的> QPS 处理能力提高了 7 倍。 +* 由于 XtraDB 群集是多主服务器，因此它使我们可以将流量发送到多台服务器，从而确保每台服务器始终具有暖缓冲区。 在 XtraDB 群集中，异步从属服务器可以将任何节点用作主服务器，并且可以在节点之间移动而不会破坏复制流。 -现在，我们不再依赖数据库复制，因为我们只将所需的数据传输到边缘，因此我们的数据传播更加可预测和稳定。 +* 群集的自动节点配置非常适合我们现有的自动化。 配置新节点后，我们要做的就是提供另一个节点的地址-新节点将自动接收数据集的副本（并在同步后加入集群）。 -这两项增强功能使我们的节点数几乎增加了一倍，并改善了 DDoS 缓解措施，因为我们必须不断处理每秒每秒数十吉比特的攻击流量。 +## 我们准备了什么 -## 人 +为 XtraDB Cluster 准备我们的应用程序确实涉及一些新的约束。 其中一些是简单的 MySQL 调整，大部分对应用程序逻辑是隐藏的，而另一些则是更基本的更改。 -技术只是被攻击的一个方面，我们也转向使用瀑布模型中的 scrum。 这种变化花费了相当长的时间，并且在今天仍在发展，但是它已经带来了可观的收益。 另一个重要的变化是收紧我们的招聘流程，以确保我们雇用的人员符合我们的流程和技术目标。 我们从其他大公司吸取了一些教训，并完善了招聘流程，以解决候选人的技术和非技术方面的问题。 结果，我们建立了一支强大的团队，能够复兴该产品。 +在 MySQL 方面： -## 结论 +* 我们需要确保仅使用具有主键的 InnoDB 表。 -路上遇到了许多坎 bump，但现在我们处于一个更好的地方，可以快速适应和调整。 现在，我们的发布时间表大约是在 sprint 快要结束时每两周发布一次，但是通常会有临时更改始终在所有时间推出。 为了跟踪自己，我们现在旨在收集所有方面的指标，包括我们的软件，硬件，网络，支持问题以及交付情况，以便我们不断改进。 +* 我们必须确保我们的应用程序不依赖于启用的查询缓存（因为集群不支持它）。 -## 服务可用性 +* 我们必须从基于语句的复制切换到基于行的复制。 -*为说明我们的改进，以下是来自加利福尼亚圣何塞的单个节点内的图表* +除了这些 MySQL 配置更改（我们能够在 DRBD 服务器端隔离测试）之外，还需要更改应用程序逻辑： -### 稳定度： +* 我们需要使用分布式锁定机制，因为 MySQL 锁定（例如 SELECT FOR UPDATE 语句）对于群集节点而言是本地的。 -![](img/9f72a2ed0087165b5167901234cc30a0.png) +* 因此，我们用 [Zookeeper](http://zookeeper.apache.org/) 锁替换了我们的 MySQL 锁（Zookeeper 已在该系统的其他部分中用于该目的）。 -### 最新版本（2012）： +* 考虑到需要将写入集同步发送到所有节点这一事实，我们更改了进行较大更改的作业（通常是存档作业）的逻辑，以使用许多较小的事务而不是一个较大的事务。 -![](img/dbede9913e6e3405f8ba3254639474fe.png) +## 我们如何处理架构变更 -*如果听起来有意思，我们正在[招聘](http://www.neustarlife.biz/job-openings/)！* +模式更改在 XtraDB 群集中尤其重要。 有两个选项可用于控制如何在集群中应用架构更改：总订单隔离（TOI）和滚动架构升级（RSU）。 -嗨，谢谢你的这篇非常有趣的文章！ +RSU 允许您单独升级每个节点，在 DDL 语句运行时从群集中取消该节点的同步，然后重新加入群集。 但是这种方法可能会带来不稳定性-RSU 无法避免大型表上的架构更改带来的操作问题（因为它会在 DDL 语句完成之前将写集缓冲在内存中）。 -您能否提供一些详细信息，说明为什么从 RHEL 迁移到 Ubuntu？ +相比之下， TOI 在所有 集群节点上同时对 应用模式升级，阻塞集群直到更改完成。 我们决定将 TOI 与 Percona 的在线模式更改工具（pt-online-schema-change）一起使用。 它确保任何阻塞操作都很快，因此不会阻塞群集。 -谢谢！！ -卡尔 +## 迁移过程 -我们已经评估了 ubuntu 12.x 和 rhel 上较新的工具，库和内核所带来的任何性能优势，但更重要的是，这对于已经在本地计算机上运行 ubuntu 的开发人员来说更容易了。 +建立了 XtraDB Cluster 引入的约束后，我们开始了推广过程。 -啊，好吧，:-) +首先，我们在生产中建立了一个集群，作为现有 DRBD 数据库的从属。 通过使该群集在生产环境中运行并接收所有写入流量，我们可以开始了解它在实际生产负载下的行为。 我们还设置了指标收集和仪表板来关注集群。 -谢谢！ +与此同时，我们花了一些时间对测试集群进行负载测试，以量化其相对于现有 DRBD 设置的性能。 -好的，我花了一秒钟的时间阅读了更改颜色（或颜色）编码的 b / c 图形。 +运行这些基准测试使我们发现，必须对一些 MySQL 配置进行调整才能获得我们一直喜欢的性能水平： -非常令人印象深刻。 +* 将 innodb_flush_log_at_trx_commit 设置为 0 或 2 可获得最佳写入性能（相反，将其设置为 1，则将测试可扩展性限制为只能在我们的测试 VM 上使用 4 个线程）。 由于所有更改都被复制到 3 个节点，因此即使出现单个节点的磁盘一致性宽松的情况，我们也不会丢失任何数据。 --XC +* 需要一个大的 innodb_log_file_size 值。 我们最终为生产服务器提供了 1GB 的文件。 -我想知道您还在使用 orient db 吗？ +在让我们感到满意的是 XtraDB Cluster 能够处理我们的生产负荷之后，我们开始了将其移入生产用途的过程。 -你好。 -请您详细说明 OrientDB 的使用方式和性能如何？ -我们目前正在研究 OrientDB。 +首先将所有测试环境切换到群集设置（并针对它们运行负载和故障测试）。 如果集群挂起，我们需要一种方法来快速将我们的系统重新配置为回退到单节点集群。 我们编写了该过程的脚本，并在负载下对其进行了测试。 -感谢您分享。 \ No newline at end of file +实际上，将生产服务器移动到集群是一个多步骤的过程。 我们已经将生产集群设置为现有 DRBD 服务器的从属服务器，因此我们站起来并从属另一对 DRBD。 （这台 DRBD 服务器在那里，以防万一切换出现严重错误，我们需要退回到基于 DRBD 的解决方案，幸好我们最终不必这样做。） + +然后，我们将其余的异步从属设备（灾难恢复，备份等）移到了 XtraDB 集群后面。 那些奴隶坐在 XtraDB 集群后面，我们执行了正常的奴隶升级过程，将生产流量转移到新系统。 + +![](img/08676a1cb3f98f192c2bd2f90463450c.png) + +![](img/7a770bcb799c0ccf8a0b22a6bc4e84a6.png) + +## 实际效果：收益 + +经过六个多月的生产使用，我们发现在 XtraDB 群集上运行有很多好处： + +* 我们已经成功执行了生产集群的滚动重启和升级，而没有停止生产流量。 + +* 我们已经使用 pt-online-schema-change 在生产系统上执行了模式修改。 + +* 我们已经优化了如何处理写冲突。 XtraDB Cluster 在遇到冲突时会返回死锁错误-即使使用 pt-online-schema-change 执行快速 DDL 语句时也是如此。 冲突导致我们的应用服务器返回 503 响应，负载平衡层将捕获该响应。 负载平衡器随后将在另一台服务器上重试该请求。 + +## 现实世界的表现：烦恼 + +在此过程中，我们还发现了一些令人沮丧的问题： + +* 某些集群的关键状态计数器是有状态的，这意味着它们在运行“ SHOW GLOBAL STATUS”后重置为零。 这使得很难监视系统中的关键计数器（例如流量控制），这些计数器很少增加，但对于了解系统的行为至关重要。 （但是，此问题已在 XtraDB Cluster 5.6 使用的 Galera 3.x 中修复。） + +* ActiveRecord 的 MySQL 适配器隐藏了事务语句引发的异常，这些异常在发生写入集冲突时发生。 （此错误已在 Rails 4.1 中修复了 [。）](https://github.com/rails/rails/pull/12779) + +* 我们还有很多工作要做，以解决服务器不正常的问题。 当前，我们的应用程序服务器连接到本地 HAproxy 实例，该实例将其连接转发到单个群集节点。 为了进行计划内的维护，我们在将流量完全分配给另一个群集节点之前，先将其缓慢释放到另一个群集节点以对其缓冲池进行预热。 将来，我们计划切换到完全多主机设置，以确保所有节点都具有热缓冲池。 + +很棒的帖子！ + +出于好奇，您是否发现具有 RBR 的集群提高了总体交易吞吐量？ 您有可衡量的性能提升吗？ + +在查看 pt-online-schema-change 时，看来基于行的复制格式可能存在一些问题，尤其是在涉及触发器时（pt-osc 用于确保将更改写入新的临时表） 。 这是您必须处理的事情吗？ + +http://dev.mysql.com/doc/refman/5.5/en/replication-features-triggers.html + +＃1221372 如果服务器是基于行的复制中的从服务器 +，则 pt-online-schema-change 应该会出错 +https://bugs.launchpad.net/percona-toolkit/+bug/1221372 + +＃1225577 pt-online-schema-change 可以静默删除行 +https://bugs.launchpad.net/percona-toolkit/+bug/1225577 + +对于使用 pxc 的人来说，架构更新过程是什么样的？ + +问候。 + +集群中有多少数据（大致数字）？ 我正在尝试将数据迁移到具有非常大的表的类似设置（大约 60 GB）中，并始终使用临时空间来打不同类型的障碍，并且在使用 mysqldumps 时集群不响应。 旧设置包含一个相当旧的 MySQL 版本。 + +香港专业教育学院 + +在为群集提供生产写入流量之前，我们仅对群集运行人为基准。 这些基准测试表明群集的性能与独立服务器一样，但应注意，sysbench 不会强调 RBR 与 SBR 的局限性。 （在单个事务中修改的行数很大） + +因为我们的表都没有使用触发器，所以我们不需要处理任何触发器问题。 如果您在表上定义了触发器，则 pt-osc 将不起作用。 错误＃1221372 不会影响我们，因为我们总是在主服务器上运行 pt-osc。 + +根据操作类型的不同，我们的架构升级会有所不同。 使用 Rails 迁移运行创建/删除表。 Alter 表是使用 pt-osc 运行的，我们手动插入 Rails 迁移行以将该迁移标记为完成。 + +什么， + +我们的数据库有几百个 GB，表的大小各不相同（几兆最大> 100 GB）。 我还没有遇到任何有关临时空间的问题。 对于 mysqldump，也许您遇到流控制问题？ 如果让 mysqldump 针对群集节点运行并且执行 FTWRL，则由于该节点无法提交挂起的写集，因此将迅速启动流控制。 + +如果要从群集节点提取备份，则需要处理该问题。 您可以在备份期间将节点从群集中取消同步，切换到另一个备份系统（如 xtrabackup），或使用事务进行一致的备份（仅需要 InnoDB 表）。 对于我们来说，我们有一个专用于备份的主机，它是集群的异步从机。 这样，备份过程带来的任何额外负担都不会影响我们的生产集群。 + +希望有帮助！ + +Mika, + +我们正在运行一个非常相似的系统。 从 Doug 的描述中，听起来就像他们遵循了 PXC“参考体系结构”一样。 对我们来说，无论数据集大小如何，它都可以完美地工作。 一些现成的 Web 应用程序不能很好地与 PXC 配合使用，并且其中的大多数约束已在 OP 中列出。 我想在几点上进行扩展： +1-最新版本支持“更多”查询缓存，并且可以在启动配置中对其进行配置。 我们通过在 MySQL 进程启动后让操作员将 QC 大小设置为非零来解决早期的限制。 +2-临时 MyISAM 表不复制。 当 DDL 指向其他表时，这将导致在其他节点上记录错误。 它还可以防止依赖临时表的应用程序扩展到单个节点之外。 +3-编码不正确的应用程序可能会在群集上遇到认证错误（冲突），并且不会重试该语句。 可以将自动提交配置为对依赖它的应用程序自动重试。 +InnoDB 上的 4- FULLTEXT 索引仅在 5.6 上受支持。 但是 5.6 对我来说似乎还不完全成熟-从 PXC 版本中已修复的错误数量来看。 但是至少 Percona 似乎在努力工作。 + +有一个仅在 5.6 中修复的 bug 击中了我们，但它本身表现为在群集的滚动更新期间 mysql 进程崩溃，因此该更新仅在零停机时间内回滚。 Percona 很快就解决了这个问题，即使我们不是付费客户，我也非常满意他们的沟通（可以为从事 PXC 工作的人员找到联系信息）。 + +要回答您的问题（部分是这样）：Percona 创建了一个出色的工具“ XtraBackup”，可以进行在线备份。 在体验了 XtraBackup 之后，真的没有回过 mysqldump 了。 看看，确实没有与该工具进行备份的比较。 + +道格， + +如果使用 PHP，是否尝试在客户端主机上使用 mysqlnd_ms 而不是 HAProxy？ 关于 mysqlnd_ms 的任何评论？ 看起来很有趣，但是我不确定我是否愿意放弃客户端主机上 HAProxy 提供的稳定性，控制性和可见性。 + +-V + +我们在一个国家/地区中确实有一个 percona Xtra 数据库集群（Master-Master -Master）设置，而我们希望在其他国家/地区中设置灾难恢复设置。请提出一种最佳的实现方法吗？ 提前致谢！ \ No newline at end of file diff --git a/docs/144.md b/docs/144.md index beeb085..400343c 100644 --- a/docs/144.md +++ b/docs/144.md @@ -1,257 +1,116 @@ -# 史诗般的 TripAdvisor 更新：为什么不在云上运行？ 盛大的实验 +# 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序 -> 原文： [http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html](http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html) +> 原文： [http://highscalability.com/blog/2014/7/7/scaling-the-world-cup-how-gambify-runs-a-massive-mobile-bett.html](http://highscalability.com/blog/2014/7/7/scaling-the-world-cup-how-gambify-runs-a-massive-mobile-bett.html) -![](img/f5d73e9a698265918ca5768397e905ed.png) +![](img/e4028d1797a9d7ec80e7ae1eee87fd4d.png) -*这是 [Shawn Hsiao](http://www.linkedin.com/in/phsiao) ， [Luke Massa](http://www.princeton.edu/rocky/people/residential-college-advis/luke-massa/) 和 [Victor Luu](http://www.linkedin.com/pub/victor-luu/57/243/91a) 的来宾帖子。 肖恩负责运行[，TripAdvisor](http://www.tripadvisor.com/) 的技术运营团队，卢克和维克托在去年夏天加入了他的团队。 该帖子由 TripAdvisor 的工程负责人 [Andy Gelfond](http://www.linkedin.com/in/andrewgelfond) 介绍。* +*这是 [cloudControl](https://www.cloudcontrol.com) 的 Elizabeth Osterloh 和 Tobias Wilke 的来宾帖子。* -距离我们上一篇关于 [TripAdvisor 建筑](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html)的帖子已经过去了一年多。 这是令人兴奋的一年。 我们的业务和团队不断增长，我们现在是一家独立的上市公司，随着我们的发展，我们继续保持/扩展我们的开发流程和文化-我们仍然经营着数十个独立团队，每个团队继续在整个 整个堆栈。 唯一改变的是数字： +初创企业在构建软件时所面临的问题与大公司完全不同。 较大的公司在更长的时间范围内开发项目，并且通常拥有整个 IT 部门来支持它们创建定制的体系结构。 当初创公司有一个好主意，它广受欢迎并且需要快速扩展时，情况就完全不同了。 -* 每月 5600 万访客 -* 每天有 350M +页的请求 -* 120TB +的仓库数据在大型 Hadoop 集群上运行，并且迅速增长 +Gambify 就是这种情况，Gambify 是一种组织投注游戏的应用程序，适时发布了世界杯足球赛。 该公司成立于德国，仅由两个人经营。 当他们设法获得一些主要认可（包括阿迪达斯和德国队明星托马斯·穆勒）时，他们不得不为突然涌现的用户以及非常特定的高峰时间做好准备。 -我们还有一个非常成功的大学实习计划，该计划于去年夏天招募了 60 多名实习生，所有这些人很快就入职，并且与我们的全职工程师一样从事相同的工作。 +## Gambify 应用：基本架构 -这里反复出现的一个想法是，为什么不在云上运行？ 我们的两个暑期实习生 Luke Massa 和 Victor Luu 通过在 Amazon Web Services 上部署我们网站的完整版本来认真研究这个问题。 用他们自己的话说，以及很多技术细节，这里是他们去年夏天所做的事情的故事。 +Gambify 的核心是基于 Symfony2 的 PHP 后端，该后端通过 Rest API 将数据提供给前端。 前端是用于桌面浏览器的 Ember.js 应用程序，其中的 PhoneGap 包装用于移动应用程序。 -## 在 AWS 上运行 TripAdvisor +Gambify 代码库分为多个包，可用于不同的场景，例如 随后是世界杯的比赛场景，然后是德国国家联赛或其他欧洲联赛的联赛场景。 为了存储数据，Gambify 除了使用结果表之外，还使用常规的 MySQL 数据库。 在这里，他们将赌注汇总到 Redis 中。 -今年夏天，我们在 TripAdvisor 开展了一个实验项目，以评估在亚马逊的弹性云计算（EC2）环境中运行整个生产站点的情况。 当我们第一次尝试在 EC2 环境中托管 www.tripadvisor.com 和所有国际域时，我们工程组织的许多成员的回应非常简单：当我们已经拥有自己的硬件时，真的值得向 Amazon 付钱吗？ 而且效果还可以吗？ +## 主要挑战 -几个月后，随着我们在云端的伟大实验即将结束，**答案当然是肯定的，**是。 在这段时间内，我们学到了很多东西，不仅是关于 AWS 的惊人好处和严重的陷阱，而且还了解了如何在我们自己的传统托管环境中改进架构。 尽管我们还没有准备好翻转 DNS 并通过 AWS 发送所有流量，但事实证明，它的灵活性是一种非常有用和实用的学习工具！ +* **在没有专门团队的情况下实现可用于生产的基础架构**。 最初，团队从托管在专用服务器上的较小，较不高级的应用程序版本开始。 他们面临配置和维护它的困难，因此决定专注于开发应用程序本身。 他们需要一个易于维护和扩展的解决方案。 -## 项目目标 +* **规划基于需求的资源使用，尤其是在比赛**之后的高峰时段。 用户倾向于在游戏后立即登录以查看比赛结果及其排名-此时，负载可能会增加到每分钟 10.000 个请求。 -* 使用 EC2 构建整个站点，并演示我们可以获取生产级流量 -* 为此操作建立成本模型 -* 确定有助于降低成本和提高可伸缩性的体系结构更改 -* 使用此迁移到新平台可以发现我们当前架构的可能改进。 +* **最大化应用速度，** **，尤其是在更新匹配结果和排名**时。 用户期望在使用该应用程序时将延迟降到最低，并在访问当前结果和排名时获得快速响应。 -## 建筑 +## 与云基础架构集成 -我们的目标是为现场站点建立一个功能完备的镜像，以实现生产级流量。 我们将其称为“ Project 700k”，因为我们试图每分钟处理 700k HTTP 请求，并且具有与我们的实时站点相同的用户体验。 用户体验将通过请求响应时间统计信息来衡量。 经过大量的摆弄和调整，我们最终提出了以下系统架构： +Gambify 决定在如此小的团队中配置和维护专用服务器很困难，因此决定搜索平台即服务提供商。 他们决定使用 cloudControl PaaS。 -**虚拟私有云**-我们所有的服务器都托管在单个 VPC 或虚拟私有云中。 这是亚马逊在单个地理区域内提供虚拟网络的方式（我们碰巧在美国东部弗吉尼亚州，但理论上我们可以在加利福尼亚州，爱尔兰等地启动一个全新的 VPC），所有实例都使用私有 IP 相互寻址 。 +**Buildpacks** ：Gambify 是用 PHP 编写的，最初在 Apache 服务器上运行以进行测试。 cloudControl 平台使用 Buildpack 系统，这是一种用于准备要部署的映像的开放标准，它已成为事实上的云平台之间互操作性的行业标准。 cloudControl PHP buildpack 提供了与原始设置相同的开源组件，因此 Gambify 能够将其现有应用程序“插入”到 cloudControl 平台，而无需进行任何重大更改。 -**子网**-在 VPC 内，我们有两个子网，为简单起见，每个子网当前位于同一可用区域中，但我们计划稍后将它们扩展以实现冗余。 第一个子网具有其安全设置，允许来自 Internet（我们称为公共子网）的传入和传出流量。 第二个私有子网，仅允许来自公共子网的流量。 Public Subnet 包含一个登台服务器，它使我们可以通过 SSH 进入私有子网，以及一组稍后将要介绍的负载均衡器。 我们所有的服务器，内存缓存和数据库都位于专用子网中。 +**容器**：cloudControl 平台基于容器。 容器基于 LXC 技术，并且包含堆栈映像，部署映像和配置。 堆栈映像提供了底层操作系统和通用库。 部署映像包含现成的应用程序。 这些配置可以包括数据库和其他第三方服务的访问凭据。 -**前端和后端服务器**-前端负责接受用户请求，处理请求，然后向用户显示请求的数据，并提供正确的 HTML，CSS 和 javascript 。 前端使用 Java 处理大多数此类处理，并且可以查询内存缓存或后端以获取其他数据。 假设服务器正确地进行了负载平衡，那么所有前端的创建方式都是相同的，并且应该承载相似的流量。 +可以垂直缩放容器（跨多个实例）或水平缩放容器（通过增加内存和处理能力）。 Gambify 能够在单个容器上测试其应用程序，然后使用 cloudControl 的粒度扩展功能根据需要进行扩展。 -后端实例被配置为托管特定服务，例如媒体或度假租赁。 由于这种分布，一些服务器配置为执行多个较小的作业，而其他服务器配置为执行一个较大的作业。 这些服务器还可以进行内存缓存或数据库调用来执行其工作。 +**路由&请求分发**：cloudControl 路由层使用反向代理负载平衡器集群来管理用户请求的接受和转发到平台上运行的应用程序。 智能 DNS 以循环方式提供快速可靠的域名解析服务。 所有节点均等地分配到三个不同的可用区域，但可以将请求路由到任何其他可用区域中的任何容器。 为了保持较低的延迟，除非没有可用的路由层，否则路由层将尝试将请求路由到相同可用性区域中的容器。 这是自动处理的，因此 Gambify 可以将此方面外包给 cloudControl 作为服务提供商。 -**负载均衡器**-为了充分利用弹性，我们使用 Amazon 的 ELB（弹性负载均衡器）来管理前端和后端服务器。 前端专门属于一个池，因此仅在一个负载平衡器下列出。 但是，后端可以执行多种服务，因此在多个负载平衡器下列出。 例如，后端可能负责搜索，论坛和社区服务，然后成为这三个负载平衡器的一部分。 之所以可行，是因为每个服务都在唯一的端口上进行通信。 所有前端服务器和后端服务器都配置为发送和接收来自负载平衡器的请求，而不是直接与其他实例进行通信。 +## 优化基于需求的资源使用 -**登台服务器**-另一个登台实例，我们称为 stage01x，用于处理进入 VPC 的请求。 它备份代码库，收集时序和错误日志，并允许 ssh 进入实例。 由于 stage01x 必须位于公共子网中，因此它会从 Amazon 那里获得一个弹性 IP，该 IP 还在早期阶段就将面向公众的负载均衡器服务于托管在其背后的 AWS 站点。 stage01x 还会维护一个 Postgresql 数据库，其中包含服务器的主机名和服务。 这在添加新实例并在其整个生命周期内进行管理方面起着至关重要的作用，我们将在后面讨论。 +Gambify 使用 New Relic 监视其性能。 这有助于他们确定游戏之前，之中和之后的用户高峰模式。 他们还实时使用 Google Analytics（分析）来查看用户负载何时增加，而请求负载却没有增加。 -### VPC 站点架构图 +Gambify 优化的主要部分已预先完成，并通过使用 Loader.io 的负载测试进行了说明。 这样一来，Gambify 就可以在客户群过大而无法处理工作负载之前发现瓶颈。 -![](img/463acdb6deab4bdc0a2f69fb29aa7ffc.png) -（[原尺寸](http://farm9.staticflickr.com/8450/8044909998_04e8375ef7_o.png)） +**Gambify 应用：原始状态** -**示例 HTTP 请求**-为了更全面地了解该体系结构，让我们逐步浏览一下互联网上的 HTTP 请求（用红线标出）。 它通过弹性 IP 在作为运行 NGinx 的公共子网中的负载平衡器的登台实例处进入 VPC。 然后，负载平衡器将流量路由到前端负载平衡器之一。 然后，ELB 重定向到它们后面的前端服务器，这些前端服务器开始处理请求。 在这里，我们有两个负载均衡级别，可以将请求分为不同的池以进行 AB 测试。 +-10 个容器@ 512 mb -然后，前端服务器决定它需要向后端服务发出请求，该服务也由 ELB 后面的许多后端服务器运行。 后端处理该请求（可能向其他后端发出请求）或数据库服务器（其结果存储在内存缓存服务器中），然后将信息发送回前端，该信息通过负载均衡器发回 给用户。 +-数据库：MySQLd“微型”附加组件 -**实例类型**-EC2 具有极好的可扩展性，因此，使用某些脚本，我们能够快速更改网络中后端服务器和前端服务器的数量。 因为所有后端和前端都在负载均衡器后面，所以没有人需要直接解决它们或知道它们是什么。 +![](img/c550fd9b9963aa48ed21e58372f081a8.png) -但是，数据库更难扩展，因为它们不在负载均衡器的后面。 可以预料，memcache 会根据实例数和每个实例上的 RAM 对键值绑定进行哈希处理，并假定两者都是固定的。 内存缓存的版本允许添加/删除成员资格，但是我们目前不在应用程序堆栈中使用它。 因此，memcache 的实时扩展将不是简单或有效的。 +（Loader.io：60 秒内有 2000 个客户端） -我们为前端，后端和内存缓存实例选择了 m2.xlarge（超大内存）实例，因为它们具有适当的内存量和较高的 CPU。 我们的数据库使用 cc2.8xlarge（群集计算八个额外的大实例）实例，这些实例需要极高的 iops 才能处理整个站点的空缓存而导致的冷启动。 +从优化角度来看，Gambify 主要通过使用索引字段查询来优化数据库访问，将对时间不敏感的部分移动到异步处理中，并在某些请求中跳过一些抽象层（ORM）。 这些优化有助于缩短单个请求的加载时间。 -## 这个怎么运作 +为了处理高峰时间，他们使用 cloudControl 的粒度扩展功能来进行扩展，尤其是在人们登录游戏后立即查看结果和得分时。 然后，负载可以增加到每分钟 10.000 个请求。 -**TACL** -我们的前端和后端服务器通过 TACL（TripAdvisor 配置语言）进行配置，TripAdvisor 配置语言描述了如何设置实例。 本质上，我们创建了一个“ aws.ini”文件，该文件定义了在何处发送和接收某些请求。 +白天，Gambify 只能由一名工人在六个（128mb）容器上运行。 在比赛中，比赛后八名工人将它们最多扩展到 18（1024mb）个容器。 MySQL 数据库在扩展方面面临挑战，因此他们决定使用一种大型 RDS 设置。 对于未来，他们正在考虑迁移到可伸缩数据库。 -例如，论坛数据（DEV_DB_FORUMS_HOST）存储在 dbs001x 上，社区数据（DEV_DB_COMMUNITY_HOST）存储在 dbs003x 上。 Memcache 实例通过其主机名直接引用。 ![](img/02c19b7722d8bb65e9a2c6999a8f7561.png) +**Gambify 应用：当前状态** -如前所述，每个前端池和后端服务组由一个负载均衡器表示，我们分别以 lbf 或 lb 作为前缀。 +-18 个容器（512 mb） -![](img/a953bfc4fa06d8519b780c4bbd83a307.png) +-MySQLd“中”加载项 -每个需要 aws.ini 中信息的服务器都将其主机名添加到文件头中。 例如，这就是 web110x 的 aws.ini 文件的标题。 设置 +![](img/012c917d86d8faf361b2b698749b65aa.png) -TACL，以便服务器在配置，启动和提供服务时引用此 aws.ini 文件。 为了进行架构更改（例如添加新数据库），我们将修改并分发此 aws.ini 文件，并启动相关实例。 通过这种负载均衡器抽象，添加新的前端和后端实例非常容易，因为它们将被适当的 ELB 包含。 +(Loader.io: 2000 clients in 60 seconds) -**Naming_service DB** -我们当前的活动站点使用托管在托管数据中心中的物理服务器。 因此，扩展或升级实例非常昂贵且耗时。 使用 Amazon EC2 的主要优势在于，我们可以廉价，快速地做到这一点，以应对流量的逐分钟变化。 为了对此进行管理，我们在 stage01x 上保留了一个存储命名数据库的数据库。 +## 最大化应用速度 -由于 EC2 实例具有相对短暂的性质，因此该数据库对于我们的运营需求至关重要。 我们偶尔会终止实例，并可能启动替换实例。 开发与此数据库一起使用的 API 可确保正确“重构”系统，例如，将旧实例从负载均衡器中删除。 当然，通过启动新实例进行扩展时，此数据库是必需的。 它为每个给定的前端和后端实例存储主机名，实例 ID 和服务。 stage01x 上的脚本用于为新启动的实例查找和分配主机名。 +Gambify 的许多应用程序速度优化都是通过异步作业处理来完成的，以便保持主要请求的快速。 为此，Gambify 使用了几个与 cloudControl 平台集成的第三方附加服务。 作业队列通过 Redis 处理。 -![](img/bfbd43b49ddb60c727c1f9df2dadacaf.png) -![](img/a0bceec44cd36f7912c47102a3ca2423.png) +**用户搜索**：异步处理的部分之一是外部 Web 服务，例如用户搜索功能。 用户与搜索索引（Searchly）同步，该索引使人们可以找到他们的朋友。 -**定制服务器映像**-我们为前端和后端服务器创建了两个定制的 CentOS 5.7 映像。 在他们的/etc/rc.local 中，我们添加了一个脚本，该脚本负责完全配置和启动实例。 启动后，它将在 stage01x 上的命名数据库中查询其主机名和服务，将其添加到适当的负载均衡器中，然后对其进行配置和反弹。 “反弹”是指启动或重新启动需要在服务器上运行的应用程序的过程。 +**用户内容**：Amazon S3 用于存储用户内容，例如。 个人资料图片。 图片上传被异步处理并调整大小，以防止移动客户端在仅需要显示缩略图时加载更大的原始图片。 -我们对这种模块化的启动感到特别兴奋，因为它使测试后端服务更加容易。 从事度假租赁服务的团队可以在 EC2 上启动一个度假租赁实例，并专门在不影响整个测试环境的情况下工作，而不是在一个开发人员的工作站上启动和启动整个网站。 +**下注包装**：Gambify 能够非常快速地处理赌注并发布结果，因为所有赌注都分组为 1000 个赌注的包装。 然后从 Redis 的作业队列中处理这些。 因为他们知道最大的工作量是在每次比赛之后发生的，所以他们启动了多个工作人员来尽快处理结果。 这些作业将加载所有赌注，并为每个单独的赌注计算分数，然后重新计算表格中的相应分数。 -**时间和错误日志**-我们的前端服务器在接收和处理请求时生成日志。 使用 stage01x 和某些 ssh 隧道传输，我们可以远程压缩这些日志文件，并将它们发送回本地工作站进行分析。 +## 解决方案摘要 -## 一路走来的问题 +* **在没有专门团队的情况下实现可用于生产的基础架构**。 Gambify 团队决定专注于开发应用程序本身，并将基础架构外包给 cloudControl。 通过 cloudControl，资源分配，路由和请求分配得以自动化。 -**停电**-2012 年 6 月 15 日，EC2 美东地区发生故障，我们失去了生产力。 2012 年 6 月 29 日，EC2 US-East 发生故障，我们丢失了一些实例。 Amazon 确实提供了可用区（相隔 20 或 30 英里）以实现冗余，因此这会稍微减轻影响。 但是，总的来说，亚马逊可能会以其数据一致性而不是数据可用性而闻名。 -[](http://technewspedia.com/wp-content/uploads/2012/06/6522_Chaiten-660x350.jpg) +* **规划基于需求的资源使用，尤其是在比赛**之后的高峰时段。 通过使用 New Relic 监控性能，Gambify 能够确定比赛之前，之中和之后的高峰时间。 他们使用 cloudControl 的细化缩放功能在比赛后的高峰时段直接放大，然后在一天的其余时间进行缩减。 -**磁盘空间不足**-如上所述，我们的服务器生成计时，错误和许多其他类型的日志。 在测试的早期阶段，我们的日志（尤其是错误日志）将快速增长，并占用数 GB 的磁盘空间。 我们决定利用 m2.xlarge 的 420GB 临时存储空间。 之前，我们完全避免使用临时存储，因为它是临时存储（重新启动后数据不会持续存在）。 但是，这对于存储日志很好。 Cronjobs 每小时都会将日志发送到本地工作站，因此我们仍然能够收集和备份重要数据。 -[](http://kpao.typepad.com/.a/6a015392891771970b01543663249d970c-pi) +* **最大化应用速度，** **，尤其是在更新匹配结果和排名**时。 Gambify 使用了几种集成的第三方服务来最大化其应用程序中的响应时间，特别是通过使用 Redis 进行异步作业处理。 -**实例不可用**-我们尝试在 us-east-1b 中使用新的 SSD hi1.4xlarge 实例，但这些实例通常在高峰时段不可用。 我们的 Amazon 联系人告诉我们，由于需求旺盛，这些实例确实不可用。 我们在 us-east-1d 中遇到了类似的问题，其中我们未能启动 m1.xlarge 实例。 这提醒我们，EC2 尚不具有无限的服务规模，因此需要在操作模型中建立实例类型及其数量的必需储备。 +## 在比赛结束时 -作为附带说明，每个 Amazon AWS 帐户均以 20 个实例上限开始，随着我们的实验的进行，我们需要与我们的 Amazon 联系人合作以将限制增加到 60 个实例，然后增加到 600 个。 我们的 ELB 遇到了类似的限制。 同样，我们的联系很快就使我们获得了批准，从而使我们可以使用 20-30 个负载均衡器。 -[](http://media.amazonwebservices.com/blog/console_ec2_hello_hi1_mndoci_1.png) +这就是在德国比赛之后，对于 Gambify 来说，真正的请求高峰看起来是什么样的-特别是 6 月 30 日对阿尔及利亚的比赛。 有趣的事实：根据 Gambify 的说法，这场比赛的顶峰略低，因为当德国获胜时，人们会庆祝而不是检查结果。 -**未充分利用的，配置错误的数据库**-简而言之，我们发现我们需要对 postgresql 数据库（位于 cc2.8xlarge 实例中）进行其他修改，以使其在 EC2 环境中正常工作。 下面列出了其中一些。 这些变化帮助我们了解了自己的环境与亚马逊环境相比的工作方式。 +![](img/5577bfeddfb12ef440ac03397f234b5b.png) -* enable_hashjoin = off（最初为 on） -* enable_mergejoin =关（开） -* shared_buffers = 4GB（8GB） -* Effective_cache_size = 48GB（16GB） +## 目标！ -**丢失的数据**-EC2 通过 EBS 卷为数据存储提供了很好的抽象级别。 为了扩展数据库实例的存储，我们只需为每个数据库实例创建 1 TB EBS 卷，将其附加到实例上，然后使用``mkfs''和``mount''Unix 命令将其装入。 +垂直扩展不是要向同一台机器增加更多功率，水平扩展不是要添加新机器吗？ 您在 cloudControl 容器部分中说了另一种方法。 -使用 EBS 卷时，我们遇到了一些问题。 当我们将一个 EBS 卷重新装载到另一个实例时，在将一个 EBS 卷转移到另一个实例时，云以某种方式删除了所有还原的成员数据，我们不得不花半天的时间在该实例上还原数据库。 此外，在尝试使用“ tunefs”和“ resize2fs”之类的命令从快照调整 EBS 卷大小时，我们遇到了问题。 使用这些调整大小的卷的实例在一天后遇到实例可达性错误，我们不得不运行“ e2fsck”几个小时来清理它们。 +非常有趣的文章，因为我目前在相同情况下（仅一名开发人员）开发服务。 -当然，我们在安装和调整大小过程中可能犯了一些严重的错误，因此不必过分担心 EC2 的这种行为。 我们发现，一般来说，AMI 和 EBS 快照的可用性有助于我们快速启动新的数据库实例。 例如，如果我们想将 dbs001x 上的数据分成两台机器，则只需创建 dbs001x 的映像，从中启动一个新实例，然后适当地重定向流量。 显然，此功能仅限于只读数据库，创建 1 TB 设备的映像通常是一夜之间的工作。 我们仍在寻找提高数据库冗余性和可伸缩性的其他方法。 我们当前的实时站点使用心跳和 DRDB 进行恢复，并且希望了解如何将其应用于 EC2。 +只是一个错误：“容器可以垂直缩放（跨多个实例）或水平缩放（通过增加内存和处理能力）” -**不相等的实例**-一方面，我们尝试对前端和后端服务器的 CPU 性能进行基准测试，所有这些服务器的大小均为 m2.xlarge。 我们使用命令 bc 设置了一个简单的数学运算 2 ^ 2 ^ 20 的时间，发现该时间分为两组，具有统计意义。 我们在测试的实例上运行 cpuid，更快的组在双 2.40 GHz 处理器上运行，而较慢的组在双 2.66 GHz 处理器上运行。 尽管这不是我们网站功能的主要问题，但它使确定我们可以使用的计算能力变得更加困难。 +垂直扩展：增加内存和 CPU +水平扩展：添加更多服务器实例 -另外，即使我们的前端计算机都具有相同的大小和相同的 AMI，大约 10％的前端计算机也无法正常弹跳。 同样，这可能是我们配置而不是 Amazon 的无法预料的问题。 +我很好奇这种设置的成本，以及它们在高峰时段如何变化？ 与类似的专用服务器解决方案（具有如此规模）的成本有何比较？ -**负数时间**-通常情况下，低俗的时间值得庆祝。 但是，当我们分析一些最近的计时日志时，我们发现某些最小服务呼叫时间为负数。 这些计时统计信息是通过调用 Java.currentTimeMillis（）来计算的。 我们仍在对此进行调查，并且有兴趣尝试通过一个简单的 Java 应用程序来复制问题。 +实际上，缩放是错误的方法。 非常不幸的混搭...我们将联系 HS 进行修复。 -**窃取周期**-运行 m2.xlarge 实例时，我们预期窃取周期为 1％或 2％。 但是，当前端处于负载状态时，我们在一两分钟内会遇到高达 7-8％的抖动。 我们的 Amazon 联系人告诉我们，这仅仅是由于每个实例的负载。 +通常，云服务提供更大的灵活性，而 PaaS 通常专注于在整个应用程序生命周期中提供自动化和编排，以帮助开发人员提高其日常工作效率。 -另外，我们在 m1.small 实例上进行了实验，并通过数学计算接管了它的 CPU 使用率。 跑马场表明，其中 98％用于数学计算，另有 2％被盗。 但是，在 Amazon 的监视服务 Cloudwatch 上，该实例似乎以 98％的 CPU 利用率运行，而不是 100％的全部利用率。 这可能会导致较大的窃用周期问题，因为无法确定某个实例是否由于窃用周期而被用完，或者是否“未充分利用”。 通常，我们希望看到更多有关 CPU 性能的保证。 +成本收益通常不在于购买的每台原始计算能力的价格比，而在于效率的提高，更多的是效率的提高，即通过使用该服务节省的时间，您可以专注于重要的事情。 -**组播**-不支持。 我们使用 JGroups，这取决于它的工作。 有人告诉我们使用 vCider 或 vpncubed 来模拟多播。 vCider 要求我们升级到 CentOS 6，并且 vpncubed 的安装时间很长。 在我们的优先级列表中，该级别较低，但是我们将来希望进一步探索这些选项。 +可以这样想：使用专用服务器，为服务器支付的费用较低，但是会附加大量的运营成本。 对于 PaaS，部分运营成本包含在使用服务的成本中。 但是总体而言，PaaS 的成本应该更便宜，因为运营商由于规模经济而降低了运营成本。 -**ELB 延迟**-尽管我们将所有后端置于特定负载均衡器之后的体系结构对于 50-60k reqs / min 以下的流量非常有效，但我们发现 ELB 大大降低了我们的后端响应时间，尤其是对于 二手服务。 为了测试这一点，我们让一个前端直接将流量发送到后端，而不是通过 ELB。 我们在下午 4:50 左右更改了此设置，使负载测试流量保持不变，并发现服务时间显着减少。 - -![](img/aeec3c71a61cd03e1cc18f3f990c0e63.png) - -我们的亚马逊联系人告诉我们，ELB 可能需要预热。 我们怀疑负载平衡器也是云平台，默认情况下可能是小型实例。 预热可能只是将这个给定平台升级为可以处理更高流量负载的平台的问题。 - -## 负载测试 - -该网站的原始设置存在一些问题。 我们无法在前端使用 Amazon 的 ELB，因为我们的前端实例隐藏在私有 VPC 中。 我们发现有些公司通过将前端实例保留在公共 EC2 网络中来解决此问题，但是这种架构会使我们的 VPC 设置无效。 - -我们使用了另一位工程师先前开发的负载测试系统，该系统获取了真实现场流量的存档日志，并以一定的请求数/分钟发送。 最初，我们将此流量定向到 stage01x 实例。 但是，到我们达到 20k reqs / min 时，很明显我们需要专用的实例来处理流量。 我们将这些实例命名为 lod01x 至 lod04x ，这些实例负责将 HTTP 通信发送到六个前端 ELB。 - -**VPC 带宽问题**-在测试的早期阶段，我们在 VPC 之外的实例将流量发送到 VPC。 但是，我们发现，无论我们如何扩展站点，负载测试的上限均为每分钟 5 万请求。 平均页面大小为 18KB，看来 VPC 仅接受 100Mbps 的流量。 我们的 Amazon 联系人向我们保证没有此限制，但是为了确保所有负载测试都保留在 VPC 中。 - -**NGinx 问题**-在我们的早期阶段，我们还为每个 lod 实例安装了 NGinx 负载平衡器。 但是，后来发现这成为我们测试的瓶颈，因为小型实例无法处理这么多的“打开文件”。 我们将其抓取，然后将流量直接发送到负载均衡器，而没有初始的 NGinx 负载均衡。 - -这是我们网站的配置，最高可达 70 万请求/分钟。 在提高请求率的过程中，我们无法保持相同的用户体验。 请求响应统计随着请求率的提高而恶化，我们将在后面详细讨论。 - -![](img/85cd8fbdd58983b90edd9cb4077d6ce8.png) - -**现场比较**-我们的现场有 80 个前端和 52 个后端，每个都有 24 个核心。 总共增加了 3168 个内核。 在我们的最高 AWS 配置下，每个 270 个前端和 70 个后端分别具有 2 个核心，我们只有 680 个核心。 这导致了后端垃圾回收的问题，我们将在后面讨论。 - -我们的 Amazon 内存缓存的运行情况相当不错。 我们通过 libmemcached-tools 附带的 memslap 实用程序进行了基准测试，发现使用 12 个中等的物理服务器，我们最初的 12 个 Amazon memcache 实例的性能大约是我们 Memcache 集群容量的 80-90％。 - -![](img/b8089280ce17cabf61bc0bd770793b66.png) -![](img/8cc4733ffe4a0454c7ac45cf2ab4621c.png) - -## 时间和错误编号 - -每个前端服务器都会自动记录发送和接收的每个请求的计时数据。 压缩后每小时发送一次到“伐木工人”服务器，在其中计算基本统计信息，并将请求时间细分为各个部分，例如 google，数据库和 xml 调用。 在评估站点性能时，我们主要关注平均总时间和 cpu 时间。 - -![](img/8afc1f118d7ded8e3815ce1c0ff7d379.png) -（[原尺寸](http://farm9.staticflickr.com/8320/8044985089_c26e7e7a98_o.png)） - -[![](img/27c03f4a1751e7b77eeedf992c25e325.png) -（](http://farm9.staticflickr.com/8320/8044985089_c26e7e7a98_o.png) [全尺寸](http://farm9.staticflickr.com/8310/8044991710_8b0bdfcd23_o.png)） - -这两个图表显示了我们从 20k reqs / min 扩展到 60k reqs / min 时，Hotel Reviews Servlet 的时间统计信息（并非所有请求都与酒店评论有关）。 根据数据，向上扩展发生在星期五的 3-4pm 之间，直到 5pm 才稳定下来。 我们关闭了网站过夜，然后在周六中午左右将其恢复，请求数量大约增加了两倍，请求时间大致保持相同，平均大约 200 毫秒。 - -在较低的负载下，这些延迟数与我们的实时站点相当，因为我们每分钟最多扩展 15 万个请求，因此延迟显着增加。 我们的主要 servlet（例如，Hotel Reviews 或 Typeahead）的时间比我们的实时站点慢了近 10 倍，后者的运行时间是此请求级别的两倍，并且在显示出更高的延迟之前，已经经过了四倍于此请求级别的测试。 - -ELB 是问题的一部分，如前所述。 但是，我们怀疑根本原因是垃圾回收开销超过了后端服务器的 CPU 数量。 仅使用两个内核，我们的 m2.xlarge 实例就没有足够的计算能力来跟上高请求速率的 GC 需求，这不足以实现高应用程序吞吐量和低应用程序延迟。 为了解决这个问题，我们很可能需要将后端数量加倍，或者使用功能更强大的实例以及更多的内核。 在这两种情况下，重点都将放在支持获得更高请求率并执行更多工作的服务上。 - -## 成本 - -### EC2 - -EC2 的付款包括三个主要部分：实例使用情况，EBS 使用情况和网络输出使用情况。 在生产级别上假定网络输出率为 200 GB /小时，每小时的成本约为 14.30 美元。 可以预见，前端服务器和后端服务器的实例使用对总成本的贡献最大。 - -### 现场比较 - -我们每个托管数据中心的初始设置约为 220 万美元，加上每年约 30 万美元的升级和扩展费用。 如果我们假设初始安装成本在三年内摊销，则资本支出每年约为 100 万美元。 运营支出（包括空间，功率和带宽）每年约为 30 万美元。 每个数据中心每年的总成本约为 130 万美元。 每个数据中心有 200 多台机器来支持我们的运营。 每台机器的成本通常为 7,000 美元。 - -如果我们每年在完整的 EC2 站点上花费 130 万美元，那么我们可以负担得起以下架构，前提是我们使用了一年的预留实例。 - -* 550 前端和后端 -* 64 个 Memcache -* 10 个数据库 - -的价格为$ 1,486,756.96 - -这意味着我们可以为当前配置添加更多 60％的容量（340 个前端和后端，32 个内存缓存，5 个数据库）。 - -如果我们使用三年的预留实例合同，那么这种配置每年将花费 88 万美元。 如果我们想在三年内花费 390 万美元，我们可以负担得起这样的架构： - -* 880 前端和后端 -* 64 个 Memcache -* 20 数据库 - -有趣的是，即使有这个数目，我们也只能获得 1760 个服务器核心（每台计算机上有 2 个），而我们的现场站点则可以运行 3500 个核心。 **不过，我们有信心，有了这样的资源，我们将能够正确解决我们目前在生产级流量**上遇到的垃圾收集和延迟问题。 - -### 降低总成本 - -* 预留实例-我们计算出，仅在 1 年的合同上使用预留实例将使我们的年度总费用减少一半。 我们也不需要为高峰流量保留所有实例，而是利用按需或利用率较低的保留实例来降低总成本。 -* 仅将实例调整为必要的容量。 现在，这可以通过启动不同比例的后端来完成。 -* 放置组-在我们知道将永远存在的实例组之间获得更好的性能。 - -## 故障点 - -* 前面有某种“类似于 BigIP”的实例。 当这种情况发生时，我们该怎么办？ -* 我们的负载均衡器由 Amazon 管理，当它们出现故障时会发生什么？ 引用完整的 DNS 名称而不是 IP 地址是有希望的，但这通常是未知的。 -* 自动缩放有助于前端池和后端池，确保它们都保持在一定数量。 但是，将内存缓存恢复到命中率将非常耗时，并且我们需要依靠复制的热备用数据库。 - -## 最佳实践 - -* 可以通过 AWS 管理控制台执行的所有操作都可以通过提供的命令行工具来完成。 准备好**来使**尽可能多的启动过程自动化。 -* 在自动化过程中，请确保**等待足够长的时间，以使实例既运行又可访问：** - * “ ec2-describe-instances”告诉您实例是否正在运行 - * 较新版本的“ ec2-describe-instance-status”会告诉您实例是否已通过实例以及系统可达性状态检查 -* 早期，**开发了一些用于跟踪所有实例**的系统。 这与 GUI 问题有关。 尽管您可以使用标签和名称来跟踪所有内容，但通常需要一种更加自动化的方式将所有内容组合在一起。 例如，我们在登台服务器上有一个 postgresql 数据库来管理它。 -* **停止的实例也可以是终止的实例**。 云计算的优势在于，当某个实例出现问题时，通常更容易在其位置启动新实例，而不是重新启动。 显然，请尝试找出潜在的问题！ - * 在此注意，请注意，``终止的实例''仍会在您的控制台中闲逛，并且如果您运行 ec2-describe-instances 将会显示出来。 如果您使用实例名称来区分实例，这将是一个问题，因为两个实例都会出现。 -* **清理 EBS 卷**，如站点所建议。 存储成本会迅速增加。 另外，请确保您清理快照，因为快照的收费与卷的 GB /月价格相同 -* **不要忘记短暂存储**，但不要忘记它的短暂存储。 对于累积的文件（例如错误日志）很有用。 使用 crontabs 保存重要数据。 -* **利用图像和快照快速放大**。 -* 详细的监视非常酷，但是我们发现 CloudWatch / monitoring 的免费层**足够**。 在 1 分钟和 5 分钟之间查看统计信息对于总体扩展决策而言并不那么重要。 但是，当然可以帮助对实例的代表性子集进行详细监视。 -* **ELB 也是监视实例状态**的好方法，即使它们实际上并没有使用（在更改架构后我们仍在使用它们）。 适当配置健康检查/阈值。 -* 通过**更加关注安全组设置**，可以解决许多令人沮丧的网络问题。 - -时间向后移动是虚拟化的经典问题，特别是如果 VM 从一个物理主机移动到另一物理主机上，或者仅仅是由于 VM 时钟漂移和重置而造成的。 最好也使用 nanotime API 进行时序实验-并尝试查看系统负载是否也很重要-因此生成 IO 和 CPU 负载以查看会发生什么。 如果您可以在测试 VM 的任一端请求其他实例，希望将它们分配在同一物理主机上，则可以查找相关行为 - -“暂时的（重新启动后数据不会持续存在）” - -临时磁盘在重新启动后仍然存在。 当您为实例快照时，它们只是不会被复制。 我在 EC2 上运行 Windows 操作系统，当我重新启动任何安全补丁时，非启动驱动器又回来了。 - -必填： -xkcd on the“ Cloud” -http://xkcd.com/908/ - -很棒的帖子！ 很好地了解了将应用程序完全迁移到云中的成本和收益。 - -迁移到云+自动化部署的每个部分的另一方面是能够迫使开发人员在交付给发布代码流之前，在以 1：1 的生产环境中测试其更改的能力。 自动化整个部署的能力是我对于开发团队的云所看到的最大好处之一。 - -感谢您提供的信息非常丰富。 您能否扩展一下创建 TACL 的原因？ TACL 提供的 AWS 缺少什么，或者 TACL 有什么更好的表现？ - -我觉得这是一个非常有趣的概念。 我认为您提出了一些很棒的观点，即 aws 没有婴儿规模，有些跌倒了。 我想用负数来解决您的问题，我不确定您是否跟踪多个实例的时间，希望您设置 ntp 服务器并定期同步服务器。 - -我工作的一家公司遇到了一个同样的问题，即日志时间到处都是，因为用户将访问一台后端服务器，并且它将一个时间写入 db，然后使用会回来，并再次记录 db，但是因为第一个服务器关闭了时间同步，所以它写的数量比第二个服务器大 - -成本模型中缺少的是建立和管理 DC 基础结构所需的人员。 而且，它只谈论核心，没有网络成本。 - -[摘自 PlanForCloud-RightScale]这篇文章启发我们写博客文章，比较在 AWS On-Demand 实例与预留实例上 TripAdvisor 的部署成本：http://blog.planforcloud.com/2012/10/tripadvisor-and -pinterest-costs-on-aws.html - -非常翔实！ 该实验需要多长时间才能完成？ 两个暑期实习生 8 周？ - -您好 -我们是否可以获取实时 xml tripadvisor 供稿？ - -提前谢谢！ -SJ \ No newline at end of file +小型项目通常可以很便宜地启动并利用收益。 当您成长时，它通常会保持很长一段时间的经济性。 最终可能会有一点，DIY 再次变得更加高效。 但这是一个问题，一旦您足够大就可以轻松解决。 \ No newline at end of file diff --git a/docs/145.md b/docs/145.md index 56de01b..bdf3d1f 100644 --- a/docs/145.md +++ b/docs/145.md @@ -1,92 +1,230 @@ -# WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量 +# 一点点：建立一个可处理每月 60 亿次点击的分布式系统的经验教训 -> 原文： [http://highscalability.com/blog/2012/9/26/wordpresscom-serves-70000-reqsec-and-over-15-gbitsec-of-traf.html](http://highscalability.com/blog/2012/9/26/wordpresscom-serves-70000-reqsec-and-over-15-gbitsec-of-traf.html) +> 原文： [http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html](http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html) -*这是 [Barry Abrahamson](http://barry.wordpress.com/) ，Automattic 的 Chief Systems Wrangler 和 *Nginx 的共同创始人* Andrew Alexeev 的特邀帖子。* +![](img/d8f15c5b26ebe6302516a72aa276f0fa.png) -[WordPress.com](http://wordpress.com/) 每月服务超过 3300 万个网站，吸引了 3.39 亿人和 34 亿页。 自 2008 年 4 月以来，WordPress.com 的页面浏览量增长了约 4.4 倍。 [WordPress.com VIP](http://vip.wordpress.com/) 托管了许多受欢迎的网站，包括 CNN 的政治通讯器，NFL，Time Inc.的 The Page，People Magazine 的 Style Watch，Flickr 和 KROQ 的企业博客，等等。 Automattic 在全球分布的十二个数据中心中运行两千台服务器。 WordPress.com 客户数据可立即在不同位置之间复制，从而为数亿访问者提供极其可靠和快速的 Web 体验。 +您是否想知道 [有点](http://bitly.is/1g3AhR6) 赚钱吗？ 一个 [URL 缩短器](http://en.wikipedia.org/wiki/URL_shortening) 不会那么难写，对吧？ bitt 的首席应用开发人员 [Sean O'Connor](http://linkd.in/1nt6KTN) 回答了如何立即在 [中产生一点可赚钱的问题 他在](http://bit.ly/1iuEAlb) [培根会议](http://devslovebacon.com/) 上发表的 演讲。 -### 问题 +肖恩说，写一个可行的 URL 缩写很容易，写一个可缩放且高度可用的 URL 缩写并不容易。 -WordPress.com 始于 2005 年，始于共享托管，就像所有 [WordPress.org](http://wordpress.org/) 网站一样。 很快将其移至单个专用服务器，然后移至两个服务器。 2005 年底，WordPress.com 向公众开放，到 2006 年初，它已扩展到四个 Web 服务器，并使用循环 DNS 分配了流量。 此后不久，WordPress.com 扩展到第二个数据中心，然后扩展到第三个数据中心。 很快，轮询 DNS 不再是可行的长期解决方案。 +Bitly 不会通过“缩短服务”服务获利，而是在分析产品上获利，该产品将 URL 点击数据与他们从网络上抓取的数据融合在一起，以帮助客户了解人们在网络上关注的内容 。 ， -虽然像 F5 BIG-IP 这样的硬件设备提供了 WordPress.com 所需的许多功能，但由 5 名成员组成的自动系统团队决定评估基于现有开源软件构建的不同选项。 在商品硬件上使用开源软件可以提供最高的灵活性，并且还可以节省成本。*“为单个数据中心在故障转移配置中购买一对有能力的硬件设备可能会有点昂贵，但是购买和维修 10 套 10 个数据中心的 10 套很快变得非常昂贵。”* +Analytics 产品最初是一种用于爬网 Web 服务器日志的后端服务。 日志包含来自带注释的链接的数据以及 cookie 数据，以指示单击链接的页面，在何处单击，链接的内容等。但是，所有链接都回到了网站的域。 建立链接与您的域到另一个域以使第三者可以进行分析的想法是一个可怕的主张，但这也是一种天才。 -最初，WordPress.com 团队选择 Pound 作为软件负载平衡器，因为它易于使用且内置 SSL 支持。 在使用 Pound 大约两年后，WordPress.com 需要其他功能和可伸缩性，即： +尽管此话题不是关于尖锐的体系结构的，但它是对分布式系统的性质以及如何解决分布式系统的大难题的有思想的探索。 -* 快速重新配置功能，而不会中断实时流量。 -* 更好的运行状况检查机制，允许从后端故障平稳逐步恢复，而不会因意外负载而使应用程序基础结构过载。 -* 更好的可伸缩性-每秒请求数和并发连接数。 庞德基于线程的模型无法在每个负载均衡实例每秒可靠地处理超过 1000 个请求。 +也许我从他的演讲中最喜欢的一课是这个（我的光泽）： -### 解 +**SOA +队列+异步消息传递确实很强大** 。 这种方法可以隔离组件，让工作同时进行，让盒子独立发生故障，同时使组件仍然易于推理。 -在 2008 年 4 月，Automattic 将所有 WordPress.com 负载平衡器从 Pound 转换为 [NGINX](http://nginx.com/) 。 在此之前，Automattic 工程师一直在将 NGINX 用于 [Gravatar](http://gravatar.com/) ，并且对其性能和可伸缩性印象深刻，因此自然而然地下一步就是迁移 WordPress.com。 在将 WordPress.com 切换到 NGINX 之前，Automattic 评估了其他几种产品，包括 HAProxy 和 LVS。 选择 NGINX 的原因如下： +我也非常喜欢他的解释，说明为什么事件样式消息比命令样式消息更好。 我从来没有听过这样的话。 -* 简单，灵活和合理的配置。 -* 能够即时重新配置和升级 NGINX 实例，而无需删除用户请求。 -* 通过 FastCGI，uwsgi 或 SCGI 协议路由应用程序请求； NGINX 还可以直接从存储中提供静态内容，以实现其他性能优化。 -* 唯一经过测试的软件能够每秒可靠地处理从单个服务器到 WordPress 应用程序的 10,000 个实时流量请求。 -* NGINX 的内存和 CPU 占用空间极小且可预测。 切换到 NGINX 之后，负载平衡服务器上的 CPU 使用率下降了三倍。 +肖恩（Sean）从真实的经验谈起。 如果您想从单一思维方式转变为多思维方式，那么此演讲非常值得一看。 ， -总体而言，WordPress.com 的峰值负载来自 NGINX 负载均衡器，服务于大约 70,000 req / sec，超过 15 Gbit / sec 的流量，还有很大的增长空间。 硬件配置是运行 Debian Linux 6.0 的具有超线程功能的 Dual Xeon 5620 4 核 CPU，8-12GB RAM。 作为高可用性设置的一部分，WordPress.com 以前使用 Wackamole / Spread，但最近开始迁移到 Keepalived。 跨入基于 NGINX 的 Web 加速和负载平衡层的入站请求的平均分配基于 DNS 轮询机制。 +因此，让我们看看 Sean 对分布式系统有何感想…… -### 参考资料 +## 统计信息 -* [关于黑客新闻](http://news.ycombinator.com/item?id=4578258) -* [WordPress 上的 Barry。 负载均衡器更新](https://barry.wordpress.com/2008/04/28/load-balancer-update/) -* [WordPress 上的 Barry。 磅](https://barry.wordpress.com/2007/11/01/static-hostname-hashing-in-pound/)中的静态主机名哈希 -* [WordPress 上的 Barry。 WordPress.com 的新服务器](https://barry.wordpress.com/2007/01/31/new-servers-for-wordpresscom/) -* [WordPress 上的 Barry。 负载均衡器测试](https://barry.wordpress.com/2006/08/30/load-balancer-testing/) -* [由 Matt Mullenweg 打开](http://en.blog.wordpress.com/2005/11/23/opening-it-up/) -* [Quantcast 提供的 WordPress.com 流量和人口统计](https://www.quantcast.com/wordpress.com) +* 每月有 60 亿点击 -NGINX 自几年以来进展顺利。 每秒的请求量和最小的硬件使我印象深刻。 +* 6 亿个每月缩短 -我希望有一天能看到某种适用于.Net 的轻型服务器，并具有这种结果。 +* 公司内 50 名员工和大约 20 名工程师 -他们的数据库系统如何工作？ +* 400 台服务器。 并非所有 400 台服务器都在处理重定向。 约 30 台服务器处理来自外界的所有传入流量，包括缩短，重定向，api 请求，Web ui 等.400 台服务器的其余部分专用于存储和组织用户数据或提供各种形式的处理和分析（数据库）的各种服务 ，指标，网页抓取，文本分析等）。 -@Seun。 我无法想象平台的大部分将需要提供需要数据库命中的动态数据。 博客文章发布后，它基本上是静态的。 提供静态文件/数据非常容易，而且成本也不高。 这种模式的难点在于增加每台服务器的密度，但这实际上只是为了大规模地降低成本，并且只有当站点达到 wordpress 拥有的规模时才值得付出努力。 总之，如果提供静态数据是他们的问题，那么扩展数据库很容易，不需要任何特殊操作。 主从服务器或将表移动到专用服务器的基本内容。 +* 每月抓取一亿个网页。 -应用程序更具动态性，难以扩展数据层。 +## 来源 -我会对数据库分片更感兴趣。 +* [经验教训，了解建筑物的分布式系统](http://devslovebacon.com/conferences/bacon-2014/talks/lessons-learned-building-distributed-systems-at-bitly) -您是否真的需要 2000 台服务器来处理这么多的静态流量？ 还是它们还充当自托管 CDN，包括备份和冗余？ +## 平台 [ -看看 Barry 的博客。 他（和其他人）分享了很多有关 WordPress.com 环境的信息。 +请注意，这些只是谈话中提到的内容，而不是完整的列表。 -WP.com 似乎在 550 台 mySQL 服务器上使用了 HyperDB 复制（截至 2011 年 7 月）-[链接](https://barry.wordpress.com/2011/07/20/hyperdb-lag-detection/) +* HDFS -嗨，达里安， +* S3 -您想特别了解数据库分片什么？ 很乐意对此发表评论。 +* Nagios -是的，我们需要所有服务器。 流量通常不是静态的。 请记住，从 WordPress.com 提供的图像中有 85％是动态转换的-即时进行的。 相信我，如果我们不需要那么多服务器，我会很乐意摆脱它们；） +* 实时使用的实时分布式消息系统是 [Nsq](https://github.com/bitly/nsq) 。 -哇！ 这非常好。 我认为 Apache 基金会现在需要改进 Apache。 +* 稍微使用 [主机池](https://github.com/bitly/go-hostpool) 来管理主机池。 -WordPress.com 使用 WordPress-multisite。 -WordPress-multisite 通过 PHP 处理静态文件，可以减少您使用 Nginx 的麻烦。 +* 谈话的结尾已结束，但提到使用了很多不同的数据库。 ， -因此，要获得像 wordpress.com 一样的性能，请在 nginx 的前面放置清漆以缓存静态内容，或者使用 [nginx-maps 指令](http://rtcamp.com/tutorials/nginx-maps-wordpress-multisite-static-files-handling/)。 +## 关于分布式系统的性质 -这也是我最喜欢的有关可伸缩性的视频之一-http://2011.sf.wordcamp.org/session/ask-barry/。 -谢谢 Barry！ +* 任何真正高度可用的东西都将被固有地分发。 为了达到一定程度的可用性，您必须具有地域多样性。 根据定义，如果您在不同区域中具有独立的操作系统，则必须将其分发。 -他们用什么来运行实际的 WordPress 应用程序？ 我曾经在 nginx 后面尝试过 PHP-FPM，但取得了一些成功，但我想知道他们是否在 nginx 后面有完整的 Apache 堆栈。 +* 创建分布式系统的旧方法。 创建抽象，让您假装实际上没有分发。 -我们在 Web /应用程序服务器上使用 Nginx + PHP-FPM。 + * 例如，NetApp 会产生无限磁盘的错觉。 -您为什么不赞成使用 haproxy，而选择 nginx 代替 LB？ -您对 GSLB 使用什么？ + * Oracle，是一个高度可用的数据库，可让您假装世界与实际不同。 -只是一个问题：WordPress 是否使用 nginx 作为负载均衡器，并且背后是 Apache，还是 nginx 是本机？ + * 两者都可以解决实际问题，但是两者都很昂贵，因此请另辟 different 径。 -谢谢 +* 新方法。 通过接受分布式系统的固有特性来解决问题，并将其内置到它们作为工具提供的抽象中。 -@ Lord2y：请阅读 Barry 的答案，在您的上方仅两篇文章：） + * 您对事物的看法发生了重大变化。 由于您的抽象与所构建内容的实际情况更加紧密一致，因此您可以进行更强大的折衷，从而更高效地完成工作。 -@Rahul Bansal：为什么要在 nginx 前面使用清漆？ 您可以使用 nginx 缓存... +* 带有 1x RAM 的 4 盒总是比带有 4x RAM 的 1 盒便宜。 这意味着分布式系统是扩展和实现高可用性的方法。 -@Barry：“请记住，从 WordPress.com 提供的图像中有 85％是动态转换的-即时进行的。” ：我不明白。 什么是动态转换的？ 无论如何，如果您需要对图像做一些事情（例如缩放，压缩），则可能是在第一次调用图像时完成了，然后将结果缓存了，还是我错过了一些东西？ \ No newline at end of file +* 分布式系统出现问题，因为您要从一台计算机迁移到 N 台计算机。 + + * **组件的并发** 。 机器 A 与机器 B 同时工作。这就是获得水平缩放的方式。 功能强大，但代价是需要在机器之间进行协调。 例如，在锁定数据时，使框彼此等待，您将不再并发。 + + * **缺少全局时钟** 。 每个盒子的时钟都不完美。 如果有一台以上的机器，那么每台机器都会有自己的时间感。 这意味着无法根据时间对在不同计算机上发生的事件进行排序。 如果事件之间相隔 1 或 2 秒，则他们不知道先发生哪些事件。 + + * **独立故障** 。 如果方框 A 失败，则方框 B 应该继续工作。 + +* 有些问题（例如分析）太大，无法在一台计算机上处​​理。 或至少这样的机器不会在预算内。 + +## 实施分布式系统的策略 + +### 面向服务的体系结构 + +没有一个整体式的应用程序。 网络上有数十种相互通信的小型服务。 + +* 这是一种抽象，非常类似于代码中的功能，但是是系统级的。 + +* 不必将系统的所有细节都保留在脑海中。 可以只注意 API 边界和合同。 + +* 强大的开发和运营能力。 + +* Bitly 是一家拥有 6 年历史的公司，并且具有很多代码。 您无需查看每一行代码。 您只使用该服务。 + +* 设计良好的服务仅几百行代码。 + +* 在操作上，很容易确定哪个系统有问题。 然后，您可以深入研究该系统以查找问题。 + +* 故障现在意味着功能减少而不是停机。 通常，每个服务都旨在回答特定问题。 由于如果其中之一发生故障，它们将完全与自己的持久层隔离，那么唯一丢失的就是回答该问题的能力，但是总体而言，服务仍处于运行状态。 出现故障的度量系统永远不会影响 URL 缩短请求。 ， + +### 异步消息传递 + +* 发送消息而无需等待回复。 + +* 真的很容易在组件之间放置队列。 如果框 A 正在向框 B 发送邮件，并且框 B 出现问题，则框 B 恢复后，这些邮件将排队并且可以进行处理。 + +* 处理错误的更多选项。 如果包装盒出现问题，该消息将稍后处理。 方框 A 不必了解或关心方框 B 的麻烦。 + +* 不利的一面是，将执行的操作更自然地建模为同步请求。 + +* URL 缩短请求是一个完全同步的过程，因为： + + * **速度**。 希望尽快返回答复。 例如，不想处理队列备份。 + + * **一致性**。 不想将相同的缩写网址提供给多个用户。 而是提供一个错误而不是一个无效的链接。 + +* 指标系统完全异步。 单击一个小链接后，它会翻译并通过 HTTP 返回。 有关转换的数据会弹出到分析和其他下游系统的队列中。 如果在处理指标方面有一点延迟，那就不是世界末日了。 + +* 可以将消息视为命令或事件。 + + * 命令说“做 X”。 + + * 一个事件说“ X 发生了”。 + +* 事件比命令更有用。 + + * **可以更好地隔离系统**。 命令意味着知道谁接收命令，否则将毫无意义。 说了些什么意味着您不必在乎谁在使用消息。 只要宣告发生了 X，其他服务就可以增加统计信息或执行任何操作。 + + * **事件自然映射为让多个使用者处理消息**。 将位 URL 解码为 HTTP 重定向后，会将消息发送到多种服务：将其保存到 HDFS 和 S3 的存档服务，实时分析服务，长期历史记录分析，注释服务。 解码服务只需要发布事件，而无需了解下游服务。 下游服务只是收到一个事件，他们不在乎发送方式或发送者。 + + * **添加新消费者很容易**。 可以创建新服务，并且可以注册活动，而制作人不知道或不在乎。 服务处理事件的方式的变化同样也不是生产者所关心的。 生产者和消费者是孤立的，只能通过事件指定的合同进行联系。 + +## 使服务发挥出色 + +* **在服务**之间使用背压。 如果某个服务繁忙，则应告知其他请求服务以限制其请求，从而减少它们在出现问题的服务上的负担。 例如，指数补偿。 帮助防止通过系统的级联错误。 还可以帮助系统更快地恢复。 例如，依赖缓存的服务需要一个预热期，如果请求的服务在预热期间没有回退，则数据库可能会崩溃。 + +* **绕过故障**。 例如，服务之间的负载平衡。 Bitly 使用 [主机池](https://github.com/bitly/go-hostpool) 管理主机池。 客户端向主机请求服务。 然后，客户端会在每个请求上告诉 hostpool 请求是否失败。 基于此反馈，主机池可以管理主机分配以路由到更健康的主机。 + +## 监视 [ + +* 使用一台或两台服务器，不难知道何时发生故障，但是当您拥有数百台服务器时，就需要帮助。 + +* **使用 Nagios 之类的工具检查服务器运行状况**。 检查统计信息，例如“盒子是否在交换？” + +* **运行完整性检查**。 例如，服务正在响应，但是返回的数据已损坏。 + +* **集中记录**。 之所以重要，是因为您可以跨多个主机检测故障。 如果一个用户造成了您所有的错误，那么通过在机器之间跳来跳去将很难检测到。 集中式日志使检测整体问题变得更加容易，例如所有错误都来自一个 ip 地址。 + +* **人机界面**。 您如何在正确的时间向正确的人获取正确的信息。 如何从工具中公开信息？ + + * 例如， Nsq 有一个不错的管理界面，可提供有关队列行为的反馈。 这样您就可以看到队列正在备份，但这是因为一个主机。 + + * 部署系统的 Web UI。 使部署和查看部署历史记录变得容易。 如果 Nagios 快要疯了并且刚刚部署了某人，则可能与他们有关。 + +## 经验教训 [ + +* **知识就是力量** 。 您越了解工作性质，可以做出更好的决策，工作效率就越高。 效率意味着您可以以更低的成本制造更大，更快的系统。 + +* **构建处理泄漏抽象的内容** 。 如果您正在使用抽象层来隐藏系统的基础分布式特性，那么它将最终冒泡。 您的代码必须理解并处理所有泄漏。 + +* **如果可以将** 全部放在一个盒子中。 如果您不需要分布式系统，请不要构建一个。 它们复杂且建造昂贵。 + +* **在面向服务的体系结构中，故障意味着功能减少而不是停机**。 + +* **SOA +队列+异步消息传递确实很强大** 。 这种方法可以隔离组件，让工作同时进行，让盒子独立发生故障，同时使组件仍然易于推理。 + +* **当速度和一致性至关重要时，请使用同步请求。** 。 给用户一个错误，而不是缓慢或错误的答案。 + +* **事件样式消息比命令样式消息** 更好。 它们允许更好地隔离系统之间，并自然支持多个使用者。 帮助保持服务重点，而不用担心服务超出预期范围。 + +* **注释而不是过滤器** 。 生产者级别的筛选器基于对下游服务关心的假设进行烘烤。 例如公共链接与私有链接。 从流中过滤出私人链接意味着对私人链接感兴趣的服务将无法获得所需的链接。 相反，请使用链接是私有链接还是公共链接来注释事件，并让服务仅在他们关心的事件类型上运行。 + +* **服务应该相互配合** 。 使用反压可防止服务过载，并绕过故障服务。 + +* **如果没有 Nagios 检查，则几乎可以确定是** 。 您只是还不知道。 + +* **工具应将信息公开给人类** 。 在正确的时间向正确的人提供正确的信息。 + +## 相关文章 + +* [关于黑客新闻](https://news.ycombinator.com/item?id=8031606) + +假设所有负载平均分布在 8 个高峰时段，即每秒仅 17 个请求（6000000000/400/30/8/3600）。 他们在用 400 台服务器做什么？ 考虑到缩短的请求几乎不会导致负载，因此每秒 17 个请求是什么。 每个 CPU 内核应为> 100，并每秒。 + +这里是原始演讲的作者。 真的很受宠若惊。 + +首先，对文章进行了较小的更正，是〜20 名工程师（50 人公司）而不是 50 名工程师。 + +第二个建议：tobi，并非所有 400 台服务器都在处理重定向。 约 30 台服务器处理来自外界的所有传入流量，包括缩短，重定向，api 请求，Web ui 等。其余 400 台服务器专用于各种服务，包括存储和组织用户数据或提供各种形式的处理和分析（数据库） ，指标，网页抓取，文本分析等）。 + +@tobi 400 可能包括质量保证和生产环境，并且将分布在 HDFS /数据库集群，队列处理器，应用服务器等上。此外，该帖子似乎表明他们正在使用商品硬件，这可能意味着它们的主机不在 不是多租户。 + +tobi，“ 400 台服务器”！= 400 台 Web 服务器。 + +是的，加上单击！=流程，并且在 8 个小时内完全均匀地加载是一个可怕的假设（考虑到即使在 Twitter 高峰期间，他们也希望获得低延迟的同步响应，而互联网上没有“营业时间”之类的东西）。 + +这是一个仍然人为但更现实的示例： + +[6000000000（点击）x 4（每次点击的平均进程数）] +/ [400/3]（每个进程平均 3 个服务器层） +/ 30（每月天数） +/ 24（小时） 每天） +* 10（峰值时间突发） +/ 3600（每小时秒数） + +在突发期间没有故障的情况下，向任何特定服务器提供 700 msgs /秒的速度。 + +6B req / sec == 200M / day 平均值 + +尽管这可以达到〜3000 / sec，但必须意识到平均值和峰值相差很大。 您不能为平均水平设计架构师。 峰值可以提高 10 倍。 + +像这样的分布式系统最大的麻烦就是一致性：确保不会将相同的短 URL 分配给两个不同的 URL。 我想您可以通过规范化和哈希 URL 并在哈希上共享来缓解这种情况... + +适用于所有 API 和 Web 的 30 台服务器非常合理。 用于分析和相关服务的 370 台服务器（占 92.5％）揭示了赚钱的地方。 + +我同意，仅 1 核 CPU 可以很好地满足 17 rps 的要求。 @bitlydevs，您应该阅读 snabswitch 如何仅通过一个节点即可提供 10M rps。 + +http://highscalability.com/blog/2014/2/13/snabb-switch-skip-the-os-and-get-40-million-requests-per-sec.html + +“带有 1x RAM 的 4 盒总是比带有 4x RAM 的 1 盒便宜。” + +怎么/为什么？ + +是的，在这里听 santosh，老兄显然知道更好 \ No newline at end of file diff --git a/docs/146.md b/docs/146.md index adafa8a..0871b1a 100644 --- a/docs/146.md +++ b/docs/146.md @@ -1,60 +1,464 @@ -# Zoosk-实时通信背后的工程 +# StackOverflow 更新：一个月有 5.6 亿次网页浏览，25 台服务器，而这一切都与性能有关 -> 原文： [http://highscalability.com/blog/2012/8/27/zoosk-the-engineering-behind-real-time-communications.html](http://highscalability.com/blog/2012/8/27/zoosk-the-engineering-behind-real-time-communications.html) +> 原文： [http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html](http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html) -![](img/efefbfdcf2cb4bd5b05bf84c461508eb.png) +![](img/85ffbec924f9896a08e0740e47a435dc.png) -*这是 [Peter Offringa 的来宾帖子，](http://www.linkedin.com/in/peteroffringa) [Zoosk](https://www.zoosk.com/) 的工程副总裁。 Zoosk 是一个拥有 5000 万会员的浪漫社交网络。* +Stack Overflow 的员工对于他们的工作以及原因仍然保持着开放的态度。 因此，该进行另一个[更新](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html)了。 堆栈溢出到底在做什么？ -当我们的会员可以实时互动时，他们会从 Zoosk 中获得最大的收获。 毕竟，用户建立的每个连接的另一端可能是将来的关系。 这种情况的刺激性和丰富性只能实时实现。 实时通信（RTC）的一般说明引用了促进这些交互的 Zoosk 服务套件。 这些通信使用 XMPP 协议进行传递，该协议还为其他流行的即时消息传递产品提供了支持。 Zoosk 成员在三种不同的交互中体验实时通信： +构成[，StackExchange](http://stackexchange.com/) 的站点网络（包括 StackOverflow）在全球流量中排名第 54； 它们有 110 个站点，并且以每月 3 或 4 个的速度增长； 400 万用户； 4000 万个答案； 每月有 5.6 亿次网页浏览。 -* **存在**。 当成员主动连接到 Zoosk RTC 基础结构时，其公开身份显示为“可用”。 如果它们闲置了一段时间，它们的状态将转换为“离开”。 当他们关闭或断开客户端应用程序的连接时，其状态会自动变为“离线”。 成员还可以选择对其他用户“不可见”。 此选项允许他们保留在 Zoosk 服务上并查看其他在线成员，但不会在其他用户的花名册中出现。 -* **通知**。 重要的交互在视觉上被打包为“敬酒”，并附带短消息。 敬酒向用户表示事件，例如收到调情，查看其个人资料或与其他用户匹配。 Zoosk 服务利用这些通知包来通知客户端应用程序更新与 UI 相关的徽章的值，例如来自另一个用户的未读消息的数量。 -* **消息传递**。 如果两个用户同时在线，则他们可以以熟悉的“即时消息”聊天格式相互发送消息。 这些消息通过 RTC 基础结构实时传输。 如果用户将来使用其他客户端应用程序重新连接，则消息内容也将保留到数据库中，以供将来检索消息历史记录。 +这只有 25 台服务器。 为了一切。 那就是高可用性，负载平衡，缓存，数据库，搜索和实用程序功能。 全部都有相对少数的员工。 现在就是质量工程。 -目前，这些通信已通过网络浏览器，iPhone 应用程序，iPad，Android 和可下载的桌面应用程序传递给 Zoosk 所有主要产品上的用户-Zoosk.com 网站和 Facebook 应用程序。 +此更新基于 Marco Cecconi 的 [StackOverflow](http://www.dev-metal.com/architecture-stackoverflow/) 的体系结构（视频）和 Nick Craver 的[进行 Stack Overflow](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/) 的体系结构。 此外，我还合并了来自各种来源的评论。 毫无疑问，某些细节已经过时了，就像我早在写这篇文章时所说的那样，但它仍然具有代表性。 -### RTC 基础结构 +堆栈溢出仍使用 Microsoft 产品。 Microsoft 基础架构可以正常运行且价格便宜，因此没有令人信服的理由进行更改。 SO 是务实的。 他们在合理的地方使用 Linux。 没有纯粹的动力来使所有 Linux 或保留所有 Microsoft。 那不会有效。 -这些 RTC 服务是通过高性能和可扩展的基于 XMPP 的基础结构提供的。 由开源 Jabber 服务器 [Tigase](http://www.tigase.org) 支持的聊天服务是此服务的核心。 Tigase 用 Java 编写，我们的平台团队创建了许多自定义扩展来处理 Zoosk 特定的业务逻辑。 +堆栈溢出仍使用放大策略。 网站上没有云。 由于其 SQL Server 装有 384 GB 的 RAM 和 2TB 的 SSD，AWS 会付出巨大的代价。 云还会降低它们的速度，从而更难优化和解决系统问题。 另外，SO 不需要水平扩展策略。 可以在横向扩展中使用的最大峰值负载没有问题，因为它们在正确调整系统大小方面非常成功。 -Tigase 部署在基于 Linux 的标准 8 CPU 应用服务器类计算机上。 Tigase 服务器配置在成对的群集中，主要和次要节点通过负载平衡器进行管理。 所有连接一次都定向到主节点。 如果对主服务器的服务检查失败，则负载平衡器将立即开始将用户流量重定向到辅助服务器。 +因此，杰夫·阿特伍德（Jeff Atwood）的话似乎很：“硬件便宜，程序员昂贵”，这似乎仍然是该公司的绝大部分。 -这些成对的群集中有 18 个，每个群集可随时处理 4,000 至 8,000 个连接。 除了用于传输 XMPP 流量的套接字连接之外，Tigase 还包括一项用于支持 HTTP 上的 BOSH 连接的服务。 +Marco Ceccon 在演讲中说，在谈论体系结构时，您需要首先回答这个问题：正在解决哪种问题？ -BOSH 是我们允许网络浏览器浏览 Zoosk.com 和我们的 Facebook 应用程序以保持与 Tigase 的持久连接的协议。 我们的桌面应用程序和移动应用程序使用标准的 TCP-IP 套接字连接。 +首先是简单的部分。 StackExchange 做什么？ 它需要主题，在主题周围创建社区，并创建很棒的问答站点。 -[![](img/f5fca2a57132c5608226dc08f283b7b8.png) ](http://farm9.staticflickr.com/8297/7872925374_a93ee99bf9_o.png) 全尺寸 +第二部分涉及规模。 就像我们将看到的那样，StackExchange 的增长非常快，可以处理大量流量。 它是如何做到的？ 让我们来看看...。 -Tigase 服务器通过 Tigase 和客户端应用程序（Web 浏览器，移动设备，桌面应用程序）之间的持久连接实时进行实时传输。 Zoosk 的许多核心产品功能，包括搜索结果，配置文件视图和消息传递，都需要确保在所有客户端应用程序上几乎实时地反映这种状态。 为使此状态在 Zoosk 基础结构的其余部分中保持一致，用户数据库中的用户记录将更新以反映其当前的在线状态，包括其最新在线转换的时间戳。 +## 统计资料 -用户的在线状态也存储在我们搜索基础架构的缓存中，以便搜索结果可以考虑在线状态。 Zoosk 搜索功能由一层 SOLR 服务器提供支持。 我们已经扩展了每个 SOLR 服务器，以包括一个 ehcache 实例来存储当前在线的那些用户。 通过称为在线状态管理器（OSM）的专用 Tigase 实例实时更新此在线状态缓存。 +* StackExchange 网络有 110 个站点，并且每月以 3 或 4 的速度增长。 -OSM 从主要的 Tigase 聊天服务器接收指示用户在线状态的自定义 XMPP 数据包，然后进行网络调用以更新每个 SOLR 服务器上的 ehcache 实例。 在高峰流量期间，每分钟大约有 8,000 个这些在线状态转换。 通过在 SOLR 索引之外维护此缓存，可以实时更新用户的状态，而与从主节点到从节点的定期索引复制快照分开。 然后，在查询时将用户的状态与搜索结果结合起来，以根据用户当前是否在线对结果进行过滤或排名。 搜索算法更喜欢在线用户，因为这会鼓励实时通信并为其他用户提供更丰富的体验。 -[ +* 400 万用户 -核心 RTC 功能之外的用户与 Zoosk 服务的交互也可以触发业务逻辑，该逻辑会向连接的用户生成实时通知。 例如，如果另一个用户查看了我们的用户个人资料，或者接受了该用户的好友请求，我们希望立即将该操作通知我们的用户。 基于 PHP 的 Web 应用程序将触发异步作业，该异步作业将打开与 Tigase 服务器的网络连接，并将 XMPP 数据包传递到服务器，而自定义消息有效负载将为通知提供数据。 此数据包由 Tigase 处理，并路由到当前连接用户的客户端应用程序。 +* 800 万个问题 -然后，用户的客户端应用程序将处理此自定义数据包，并向用户显示适当的“祝酒”，或更新“徽章”，以反映特定功能指标的当前值（配置文件视图数，未读消息等）。 如果用户当时处于脱机状态，则 Tigase 将存储数据包，直到用户重新连接为止。 届时，它将自定义数据包传递给用户的客户端应用程序。 +* 4000 万答案 -### 监视和测试 +* 作为全球排名第 54 的网络流量站点 -Zoosk 技术运营团队已经建立了多种方法来测试和监视 RTC 基础结构的运行状况，以确保响应能力和可用性。 这些测试主要涉及各种机制来从 Tigase 服务器收集性能数据，或模拟实际的用户交互。 如果特定的运行状况检查失败或性能数据超出既定阈值，则我们的 Nagios 安装将生成警报。 +* 同比增长 100％ -* **Tigase Monitor** -这是一个每 10 分钟在 cron 上运行的脚本。 它登录到所有主要的聊天服务器，并测试连接和状态传输。 它记录这些测试的结果，并将更新发送给 Nagios，以确定是否生成警报。 -* **Tigase 的性能指标**-这些内容涵盖了各种内部 Tigase 指标，包括执行关键功能的时间，消息计数，队列大小，内存消耗等。这些值每 2 分钟由临时统计收集一次 通过 XMPP 管理界面命令。 然后将这些度量传递到 Ganglia 进行绘图。 -* **商业智能报告**-脚本每小时检查一次与每个主 Tigase 服务器的活动连接数，以及它在前一个小时内传递的消息数。 该数据被加载到数据库中。 定制的 Excel 报告可以连接到该数据源，并提供具有易于比较的历史趋势的数据摘要视图。 -* **Tigase 测试套件**-这是一个无头 XMPP 客户端，它登录到每个 Tigase 服务器并模拟真实的交互。 然后，TTS 将记录其功能测试的结果，以供团队审核。 +* 每月 5.6 亿次网页浏览 -### [![](img/fe4a02128277bf91affecfdf14f5e31e.png) ](http://farm9.staticflickr.com/8296/7872943312_1d3a7026d0_o.png) 全尺寸 -下一步 +* 在大多数工作日，高峰更像是 2600-3000 请求/秒。 编程是一种职业，意味着工作日比周末要忙得多。 -展望未来，我们将继续积极探索为 Zoosk 会员提供实时体验的新方法。 我们将在下个月向我们的移动 Web 应用程序（Touch）推出 RTC 支持。 交付 Zoosk 应用程序的其他设备或介质将类似地进行实时连接。 随着我们的成员增加主动连接到 Zoosk 应用程序的时间，我们计划增强基于 RTC 的功能，以促进成员之间的发现和通信。 +* 25 台服务器 -这里的图形（可能是无意间）泄漏了 Zoosk.com 上的活动用户数。 +* 2 TB SQL 数据全部存储在 SSD 上 -实际上，它泄漏的是任何一次活动用户的数量。 马特假设同一个人整天都保持登录状态。 但是当涉及到[扩展其实时平台](http://zooskdev.wordpress.com/2011/09/13/4-tricks-to-going-real-time-for-tech-ops/)时，Zoosk 并不太紧。 +* 每个 Web 服务器在 RAID 1 中具有 2 个 320GB SSD。 -18 个服务器之间仅 150k 并发用户的负载平衡又如何呢？ 仅一个 tigase 实例就够这么低的容量吗？ 也许这只是出于过现实的冗余因素？ +* 每个 ElasticSearch 盒都有 300 GB，也使用 SSD。 -我可以为这样的公司工作！ \ No newline at end of file +* 堆栈溢出的读写比率为 40:60。 + +* 数据库服务器平均 10％的 CPU 使用率 + +* 11 个 Web 服务器，使用 IIS + +* 2 个负载均衡器，其中 1 个处于活动状态，并使用 HAProxy + +* 4 个活动数据库节点，使用 MS SQL + +* 3 个应用服务器实现标签引擎，任何通过标签命中进行搜索 + +* 3 台机器使用 ElasticSearch 进行搜索 + +* 2 台使用 Redis 进行分布式缓存和消息传递的机器 + +* 2 个网络（每个 Nexus 5596 +光纤扩展器） + +* 2 个 Cisco 5525-X ASA（认为防火墙） + +* 2 个 Cisco 3945 路由器 + +* 2 个只读 SQL Server，主要用于 Stack Exchange API + +* 虚拟机还执行诸如部署，域控制器，监视，用于系统管理员的操作数据库等功能。 + +## 平台 + +* 弹性搜索 + +* 雷迪斯 + +* HAProxy + +* MS SQL + +* [观察者](https://github.com/opserver/Opserver) + +* 团队城市 + +* [Jil](https://github.com/kevin-montrose/Jil) -基于 Sigil 构建的快速.NET JSON 序列化器 + +* [Dapper](https://code.google.com/p/dapper-dot-net/) -微型 ORM。 + +## UI [ + +* UI 具有消息收件箱，当您获得新徽章，收到消息，重大事件等时，将向该消息收件箱发送消息。使用 WebSockets 完成并由 Redis 驱动。 + +* 搜索框由 ElasticSearch 使用 REST 接口提供动力。 + +* 由于有如此多的问题，因此不可能仅显示最新的问题，它们会变化得太快，每秒都会出现一个问题。 开发了一种算法来查看您的行为方式，并向您显示您最感兴趣的问题。它使用了基于标签的复杂查询，这就是开发专门的标签引擎的原因。 + +* 服务器端模板用于生成页面。 + +## 服务器 + +* 这 25 台服务器的工作量不大，即 CPU 负载低。 据估算，SO 只能在 5 台服务器上运行。 + +* 数据库服务器的利用率为 10％，除非在执行备份时服务器突然崩溃。 + +* 有多低 数据库服务器具有 384GB 的 RAM，Web 服务器的 CPU 使用率为 10％-15％。 + +* 放大仍然有效。 其他具有类似浏览量的横向扩展站点通常可以在 100、200，最多 300 台服务器上运行。 + +* 系统简单。 建立在.Net 上。 只有 9 个项目，其他系统有 100 个。 之所以拥有很少的项目，是因为编译如此迅速，这需要在开始时就进行规划。 在一台计算机上，编译需要 10 秒钟。 + +* 110K 行代码。 给出了它的作用的一小部分。 + +* 这种简约的方法存在一些问题。 一个问题是测试不多。 不需要测试，因为那里有一个很棒的社区。 Meta.stackoverflow 是社区的讨论站点，并且报告了错误。 Meta.stackoverflow 还是新软件的测试版站点。 如果用户发现任何问题，他们会报告所发现的错误，有时还会报告解决方案/补丁。 + +* 纽约已使用 Windows 2012，但正在升级到 2012 R2（俄勒冈已经在使用它）。 对于 Linux 系统，它是 Centos 6.4。 + +* 实际上，负载几乎遍布 9 台服务器，因为 10 台和 11 台仅用于 meta.stackexchange.com，meta.stackoverflow.com 和开发层。 这些服务器还运行约 10-20％的 CPU，这意味着我们还有很多可用空间。 + +## 固态硬盘 + +* Intel 330 作为默认设置（网络层等） + +* 英特尔 520 用于中级写入，例如 Elastic Search + +* 用于数据库层的 Intel 710 & S3700。 S3700 只是高耐用性 710 系列的后继产品。 + +* 独家 RAID 1 或 RAID 10（10 是具有 4 个以上驱动器的任何阵列）。 故障已经不是问题，即使有数百个 intel 2.5 英寸固态硬盘投入生产，也没有一个故障。每种型号都保留一个或多个备件，但是多个驱动器故障并不是一个问题。 + +* 鉴于非常频繁的 SO 写/重新索引，ElasticSearch 在 SSD 上的性能要好得多。 + +* SSD [更改搜索](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/#comment-1201059884)的使用。 由于锁定问题，Lucene.net 无法处理 SO 的并发工作负载，因此将其转移到 ElasticSearch。 事实证明，在所有 SSD 环境中，实际上都不需要对二进制读取器进行锁定。 + +* 到目前为止，唯一的纵向扩展问题是 SQL 盒上的 SSD 空间，这是由于可靠性与非消费空间中的空间的增长方式所致，即驱动器具有用于功率损耗等的电容器。 + +## 高可用性 [ + +* 主数据中心在纽约，备用数据中心在俄勒冈。 + +* Redis 具有 2 个从属，SQL 具有 2 个副本，标记引擎具有 3 个节点，elastic 具有 3 个节点-任何其他服务也具有高可用性（并且都存在于两个数据中心中）。 + +* 并非所有数据中心之间都存在从属关系（不需要通过同步来占用带宽的非常临时的高速缓存数据等），而是大数据项，因此在活动数据中心发生故障时，仍然存在共享的高速缓存。 没有缓存就可以开始，但这不是很优雅。 + +* Nginx 用于 SSL，但是已经过渡到使用 HAProxy 终止 SSL。 + +* 发送的 HTTP 总流量仅占发送总流量的 77％。 这是因为正在向俄勒冈州的辅助数据中心以及其他 VPN 通信进行复制。 这些流量的大部分是到俄勒冈州 SQL 复制副本和 Redis 从站的数据复制。 + +## 数据库 + +* MS SQL Server。 + +* Stack Exchange 每个站点有一个数据库，因此 Stack Overflow 获取一个，超级用户获取一个，Server Fault 获取一个，依此类推。 这些的架构是相同的。 具有不同数据库的这种方法实际上是分区和水平缩放的一种形式。 + +* 在主要数据中心（纽约）中，每个集群通常有 1 个主数据库和 1 个只读副本。 在 DR 数据中心（俄勒冈州）中还有 1 个只读副本（异步）。 在俄勒冈州运行时，主要目录在那里，并且两个纽约副本均为只读且异步。 + +* 有一些皱纹。 有一个“网络范围的”数据库，其中包含登录凭据和聚合数据（主要通过 stackexchange.com 用户配置文件或 API 公开）之类的东西。 + +* 职业生涯 Stack Overflow，stackexchange.com 和 Area 51 都有各自独特的数据库架构。 + +* 所有架构更改将同时应用于所有站点数据库。 它们需要向后兼容，因此，例如，如果您需要重命名一列-最坏的情况-这是一个多步骤的过程：添加新列，添加适用于两列的代码，回填新列，更改 代码，使其仅适用于新列，请删除旧列。 + +* 不需要分区。 索引可以处理所有事情，并且数据还不够大。 如果需要过滤索引，为什么不提高效率呢？ 仅在 DeletionDate = Null 上建立索引，这是一个常见的模式，其他则是枚举中特定的 FK 类型。 + +* 每个项目 1 张表中有投票，例如 1 张表用于投票，1 张表用于评论投票。 我们大多数页面都是实时呈现的，仅为匿名用户缓存。 鉴于此，没有要更新的缓存，只需重新查询即可。 + +* 分数是非规范化的，因此经常需要查询。 所有的 ID 和日期，职位投票表目前只有 56,454,478 行。 由于建立索引，大多数查询仅需几毫秒。 + +* 标记引擎完全是独立的，这意味着不必依赖外部服务来获得非常核心的功能。 这是一个巨大的内存结构数组结构，针对 SO 用例和针对重击组合的预计算结果进行了优化。 这是一个简单的 Windows 服务，在冗余团队中的几个盒子上运行。 CPU 几乎总是占 2-5％。 负载不需要三个盒子，只是冗余。 如果所有这些操作一次都失败，则本地 Web 服务器将标记引擎加载到内存中并继续运行。 + +* 与传统的 ORM 相比，Dapper 缺少编译器来检查查询。 编译器正在检查您告诉数据库的内容。 这可以帮助很多事情，但是仍然存在运行时遇到的根本断开问题。 权衡的一个巨大问题是所生成的 SQL 令人讨厌，并且查找其来源的原始代码通常并非易事。 尝试优化查询时，缺乏提示查询，控制参数化等功能的问题也很大。 例如。 文字替换已添加到 Dapper，以帮助进行查询参数化，从而允许使用诸如过滤索引之类的内容。 Dapper 还拦截了对 Dapper 的 SQL 调用，并添加了 add 的确切来源。 它节省了很多时间来追踪事物。 + +## 编码 + +* 过程： + + * 大多数程序员都在远程工作。 程序员在自己的蝙蝠洞中编码。 + + * 编译非常快。 + + * 然后运行他们已经进行的一些测试。 + + * 编译后，代码将移至开发登台服务器。 + + * 新功能通过功能开关隐藏。 + + * 在与其他站点相同的硬件上运行。 + + * 然后将其移至 Meta.stackoverflow 进行测试。 每天有 1000 个用户使用该网站，因此它是一个很好的测试。 + + * 如果通过，它将在网络上发布并由更大的社区进行测试。 + +* 大量使用静态类和方法，以简化操作并提高性能。 + +* 代码很简单，因为复杂的位打包在一个库中，并且是开源和维护的。 .Net 项目的数量保持较低，因为使用了社区共享的代码部分。 + +* 开发人员可以获得两到三个监视器。 屏幕很重要，它们可以帮助您提高工作效率。 + +## 快取 + +* 缓存所有东西。 + +* 5 级缓存。 + +* 第一个：网络级缓存：在浏览器，CDN 和代理中进行缓存。 + +* 第二名：.Net 框架免费提供的，称为 HttpRuntime.Cache。 内存中的每个服务器缓存。 + +* 第三名：Redis。 分布式内存键值存储。 在为同一站点提供服务的不同服务器之间共享缓存元素。 如果 StackOverflow 有 9 台服务器，则所有服务器都将能够找到相同的缓存项。 + +* 第四：SQL Server 缓存。 整个数据库都缓存在内存中。 整个事情。 + +* 第五名：SSD。 通常仅在 SQL Server 缓存预热时命中。 + +* 例如，每个帮助页面都被缓存。 访问页面的代码非常简洁： + + * 重用了静态方法和静态类。 从 OOP 的角度来看，这确实很糟糕，但是对于简洁的代码却非常快速且非常友好。 所有代码都直接寻址。 + + * 缓存由 Redis 的库层和微型 ORM [Dapper](https://code.google.com/p/dapper-dot-net/) 进行处理。 + +* 为了解决垃圾回收问题，仅创建模板中使用的类的一个副本并将其保存在缓存中。 从统计数据中可以测量所有内容，包括 GC 操作，已知间接层会增加 GC 压力到明显的缓慢点。 + +* 由于查询字符串哈希值基于文件内容，因此 CDN 命中数有所不同，因此只能在构建中重新获取它。 300 至 600 GB 的带宽通常每天点击 30-50 百万次。 + +* CDN 不用于 CPU 或 I / O 负载，而是用于帮助用户更快地找到答案。 + +## 部署 [ + +* 想要每天部署 5 次。 不要建立宏伟的宏伟的东西，然后再活下来。 重要原因： + + * 可以直接衡量性能。 + + * 被迫制造可能起作用的最小的东西。 + +* 然后，通过 Powershell 脚本构建 TeamCity，然后将其复制到每个 Web 层。 每个服务器的步骤是： + + * 告诉 HAProxy 通过 POST 使服务器停止旋转 + + * 延迟让 IIS 完成当前请求（约 5 秒） + + * 停止网站（通过以下所有操作使用相同的 PSSession） + + * Robocopy 文件 + + * 启动网站 + + * 通过另一个 POST 在 HAProxy 中重新启用 + +* 几乎所有内容都是通过 puppet 或 DSC 进行部署的，因此升级通常仅包括对 RAID 阵列进行核对并从 PXE 引导进行安装。 它的速度非常快，而且您知道它做得正确/可重复。 + +## 团队合作 + +* 队伍： + + * SRE（系统可靠性工程）：-5 人 + + * 核心开发人员（Q & A 网站）：〜6-7 人 + + * 核心开发人员：6 人 + + * 仅针对 SO Careers 产品进行开发的职业团队：7 人 + +* Devops 和开发人员团队确实紧密相连。 + +* 团队之间有很多变动。 + +* 大多数员工都在远程工作。 + +* 办公室主要是销售部门，丹佛和伦敦则完全是这样。 + +* 在所有其他条件相同的情况下，在纽约市更喜欢有一些人，因为面对面的时间对于“完成任务”之间的偶然互动是加分的。 但是，这种设置可以进行实际工作，并且官方团队合作几乎可以完全在线进行。 + +* 他们了解到，亲自聘用能够在任何地方热爱该产品的最佳人才所带来的收益远远超过其个人收益，而不仅仅是愿意住在您所在城市的人才。 + +* 某人偏远的最常见原因是建立家庭。 纽约很棒，但宽敞却不是。 + +* 办公室在曼哈顿，那里有很多人才。 由于数据中心总是在不断完善，因此它不必离疯狂的距离。 与 NYC 位置的许多骨干网的连接速度也稍快-尽管我们在这里谈论的只是几毫秒（如果有的话）的差异。 + +* 组建一支很棒的团队：爱极客。 例如，早期的 Microsoft 充满了极客，他们征服了整个世界。 + +* 从 Stack Overflow 社区雇用。 他们寻求对编码的热情，对他人的热情以及对沟通的热情。 + +## 预算 + +* 预算几乎是基于项目的。 仅在为新项目添加基础结构时才花钱。 利用率如此低的 Web 服务器与 3 年前建造数据中心时购买的 Web 服务器相同。 + +## 测验 + +* 快速行动并破坏事物。 现场直播。 + +* 重大更改通过推送进行测试。 开发具有功能相同的 SQL Server，并且它在同一 Web 层上运行，因此性能测试也不错。 + +* 很少的测试。 由于 Stack Overflow 的活动社区和大量使用静态代码，因此它们不使用许多单元测试。 + +* 基础架构发生变化。 共有 2 种，因此只要有可能，就可以使用旧配置进行备份，并具有快速故障回复机制。 例如，keepalived 会在负载均衡器之间快速进行故障回复。 + +* 冗余系统通常只是为了进行定期维护而进行故障转移。 通过拥有专用的服务器来不断测试 SQL 备份，该服务器用于不断地还原它们（这是免费许可证，可以执行此操作）。 计划每 2 个月左右启动一次完整的数据中心故障转移-辅助数据中心在所有其他时间都是只读的。 + +* 每次推送都会运行单元测试，集成测试和 UI 测试。 所有测试必须成功，才能进行生产构建。 因此，关于测试的信息有些混杂。 + +* 显然应该进行测试的事物具有测试。 这意味着在 Careers 产品上涉及金钱的大多数事物，以及在 Core 端上易于进行单元测试的功能（具有已知输入的事物，例如标记，我们的新顶部栏等），而对于大多数其他事情，我们只是做一个功能 手动进行测试并将其推送到我们的孵化站点（以前称为 meta.stackoverflow，现在称为 meta.stackexchange）。 + +## 监控/记录 + +* 现在考虑使用 http://logstash.net/进行日志管理。 当前，专用服务将 syslog UDP 通信插入 SQL 数据库。 网页添加了用于出站计时的标头，这些标头由 HAProxy 捕获并包含在 syslog 通信中。 + +* [Opserver](https://github.com/opserver/Opserver) 和 Realog。 有多少度量标准浮出水面。 Realog 是由 Kyle Brandt 和 Matt Jibson 在 Go 中构建的日志显示系统 + +* 通过 syslog 而不是 IIS 从 HAProxy 负载平衡器进行日志记录。 它比 IIS 日志具有更多的通用性。 + +## 阴天 + +* 硬件比开发人员便宜且代码高效。 您的速度只有最慢的瓶颈，而且当前所有的云解决方案都具有基本的性能或容量限制。 [ +* 如果从第一天开始构建云，您能否构建得那么好？ 最有可能。 您能否一致性地渲染所有页面，以执行多个最新查询并跨您无法控制的云网络缓存获取数据，并获得不到 50 毫秒的渲染时间？ 那是另一回事。 除非您谈论的是更高的成本（至少 3-4 倍），否则答案是否定的-SO 托管在自己的服务器中仍然更加经济。 + +## 性能为特征 + +* StackOverflow 非常重视性能。 主页的目标是在 50 毫秒内加载，但可以低至 28 毫秒。 + +* 程序员热衷于减少页面加载时间并改善用户体验。 + +* 记录到网络的每个请求的时间。 借助这些指标，您可以决定改进系统的位置。 + +* 其服务器以如此低的利用率运行的主要原因是高效的代码。 Web 服务器的平均 CPU 率为 5-15％，使用的 RAM 为 15.5 GB，网络流量为 20-40 Mb / s。 SQL 服务器平均约有 5-10％的 CPU，365 GB 的 RAM 和 100-200 Mb / s 的网络流量。 这具有三个主要优点：一般的增长空间和升级的必要性； 当事情发疯时（查询错误，代码错误，攻击等等），可以保持在线的余地； 以及在需要时恢复供电的能力。 + +## 经验教训 [ + +* **如果使用 MS 产品，为什么要使用 Redis？** [gabeech](http://www.reddit.com/r/programming/comments/1r83x7/what_it_takes_to_run_stack_overflow/cdkpv7w) ：这与 OS 宣传无关。 我们在运行效果最佳的平台上运行事物。 期。 C＃在 Windows 计算机上运行最好，我们使用 IIS。 Redis 在我们使用* nix 的* nix 机器上运行得最好。 + +* **作为策略过度杀伤**。 尼克·克雷弗（Nick Craver）解释了为什么他们的网络被过度配置了：20 Gb 大规模杀伤力大吗？ 您敢打赌，在 20 Gb 管道中，活动的 SQL 服务器平均大约 100-200 Mb。 但是，由于存在大量内存和 SSD 存储，因此备份，重建等操作可能会使它完全饱和，因此确实可以达到目的。 + +* **SSD 摇滚**。 数据库节点均使用 SSD，平均写入时间为 0 毫秒。 + +* [了解您的读/写工作量](http://sqlblog.com/blogs/louis_davidson/archive/2009/06/20/read-write-ratio-versus-read-write-ratio.aspx)。 + +* **保持高效运行意味着经常不需要新机器。 只有当由于某种原因需要不同硬件的新项目出现时，才添加新硬件。 通常会添加内存，但是除了该高效代码和低利用率以外，它不需要替换。 因此，通常谈论的是添加 a）SSD 以获得更多空间，或 b）为新项目添加新硬件。** + +* **不要害怕专长**。 SO 使用基于标签的复杂查询，这就是为什么要开发专门的标签引擎的原因。 + +* **仅执行需要做的事情**。 不需要测试，因为活跃的社区已经为它们进行了验收测试。 仅在需要时添加项目。 仅在必要时添加一行代码。 您没有需要它确实有效。 + +* **重新发明可以**。 通常的建议是不要重新发明轮子，例如，将其变成正方形只会使它变得更糟。 在 SO 上，他们不必担心制作“方轮”。 如果开发人员可以编写比已经开发的替代方案更轻巧的东西，那就去做。 + +* **转到裸机**。 进入 IL（.Net 的汇编语言）。 一些编码使用 IL，而不是 C＃。 查看 SQL 查询计划。 进行 Web 服务器的内存转储，以查看实际情况。 例如，发现拆分呼叫会产生 2GB 的垃圾。 + +* **没有官僚机构**。 您的团队总是需要一些工具。 例如，编辑器，Visual Studio 的最新版本等。只需进行很多操作即可。 + +* **垃圾收集驱动的编程**。 SO 竭尽全力减少垃圾收集成本，跳过诸如 TDD 之类的做法，避免抽象层，并使用静态方法。 虽然极端，但结果却是高性能的代码。 当您在短窗口中处理数亿个对象时，实际上可以测量 GC 运行时应用程序域中的暂停时间。 这些对请求性能有相当不错的影响。 + +* **低效代码的成本可能比您认为的**高。 高效的代码进一步扩展了硬件，减少了功耗，并使程序员更易于理解代码。 + +## 相关文章 + +* [关于黑客新闻](https://news.ycombinator.com/item?id=8064534) + +* [运行堆栈溢出所需的时间[Nick Craver]](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/) + + * [在 Reddit 上](http://www.reddit.com/r/programming/comments/1r83x7/what_it_takes_to_run_stack_overflow/) + +* 视频 [StackOverflow](http://www.dev-metal.com/architecture-stackoverflow/) 的体系结构，作者 Marco Cecconi + + * [关于 HackerNews](https://news.ycombinator.com/item?id=7052835) + + * [演示幻灯片](https://speakerdeck.com/sklivvz/the-architecture-of-stackoverflow-developer-conference-2013) + +* [Stackoverflow.com：通往 SSL 的道路](http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/) + +* [哪些工具和技术用于构建 Stack Exchange 网络？](http://meta.stackexchange.com/questions/10369/which-tools-and-technologies-are-used-to-build-the-stack-exchange-network) + +* [被 GC 攻击](http://blog.marcgravell.com/2011/10/assault-by-gc.html) + +* [StackOverflow 上的 Microsoft SQL Server 2012 AlwaysOn AG](http://www.brentozar.com/archive/2012/09/microsoft-sql-server-alwayson-ags-at-stackoverflow/) + +* [为什么我们（仍然）相信远程工作](http://blog.stackoverflow.com/2013/02/why-we-still-believe-in-working-remotely/) + +* [运行堆栈溢出 SQL 2014 CTP 2](http://nickcraver.com/blog/2013/11/18/running-stack-overflow-sql-2014-ctp-2/) + +* 多年来，HighScalability 在 StackOverflow 上有几篇文章：[堆栈溢出体系结构](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html)， [StackOverflow 的扩展野心](http://highscalability.com/blog/2010/2/15/scaling-ambition-at-stackoverflow.html)，[堆栈溢出体系结构更新](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)， [StackExchange 体系结构更新[](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html) 。 + +这里有 Stack 开发人员-还有一个单独的 Careers 团队，专门为 SO Careers 产品进行开发。 也大约有 7 位开发者。 + +有关首次出现在堆栈上的某些情况，请访问： [http://www.jonhmchan.com/blog/2014/1/16/my-first-six-weeks-working-at-stack-overflow](http://www.jonhmchan.com/blog/2014/1/16/my-first-six-weeks-working-at-stack-overflow) + +“快如闪电”？ 真？ 在称自己为作家之前，请先了解“闪电”和“闪电”之间的区别 + +我从来不知道他们在大多数网站上都使用 C＃编写代码，考虑到他们仅使用 25 台服务器，看到这样的项目进行扩展，真是令人震惊！ （哇） +我对数据库的低延迟感到惊讶，即使它全部在内存中，也有一些物理瓶颈无法让您处理超过 20gb / sec 的速度（不确定是什么，取决于内存速度） ）。 + +很棒的帖子，很惊讶地看到它们继续运行。 令我的公司感到羞耻的是，我们的服务器从左到右落在中间，仅运行了一部分 SO 运行！ + +在 MS SQL 停止读取 + +不是.net 人，但是许多项目如何影响编译时间？ + +非常有趣-感谢您的总结！ + +很好的简历，它很棒的 stackoverflow 原理！ 高性能！ + +“下降到裸机。进入 IL”。 IL 中的 I 代表中级。 因此，也许应该将其改写为“更紧密地接近裸机”，但实际上并非如此。 + +“大多数程序员都在远程工作。程序员在自己的蝙蝠洞中编写代码。” + +有点违背 + +“在其他所有条件相同的情况下，在纽约市更倾向于有人陪伴，因为面对面的时间是在“完成工作”之间进行的随意互动的加分。但是，这种设置可以进行真正的工作和 官方团队合作几乎完全在线上进行。” + +“他们已经了解到，亲自聘用能够在任何地方钟情于该产品的最优秀人才而获得的收益远远超过个人受益，而不仅仅是愿意住在您所居住的城市的人才。 ” + +出色而翔实，因此令人大开眼界。 对于那些讨厌微软技术栈的人……包括我在内，这是有教益的。 真的很棒。 + +关于编译速度和项目数量。 如果在 Visual Studio 中“卸载项目”，则可以禁用该项目的编译。 我有一个包含 14 个项目的解决方案，而卸载我不从事的项目可以节省大量时间。 + +>看到这样的项目可以扩展，考虑到他们仅使用 25 台服务器，这真是令人震惊 + +>很棒的帖子，很高兴看到他们的运行量 + +你疯了吗？！ 他们在每个数据库服务器上都有 384GB 的内存。 他们甚至在 Web 服务器上都有 SSD。 他们每个月提供的访问量仅为 5.6 亿，这是整个服务的 560000000 / 30/24/3600 = 216 RPS，如果将其除以 Web 服务器数量，则每个 Web 服务器将为 19 RPS ，而且它不是廉价服务器，甚至在 Raid 1 和 shit 中甚至都有 SSD。 给定像这样的数字，我会很高兴我没有使用 IIS 或任何 Microsoft 软件来提供 Web 应用程序... + +大量使用静态类和方法会产生代码异味 + +我发现 Marco Cecconi 在 SpeakerDeck 上有一些更新的幻灯片：[](https://speakerdeck.com/sklivvz "https://speakerdeck.com/sklivvz") + +@Nikita 哦，拜托，你知道数学很愚蠢。 流量显然遵循模式，几乎可以肯定，他们在峰值负载下的速度明显超过 216 RPS。 对于一个相当复杂，写繁重的网站而言，5.6 亿的页面浏览量是非常可观的。 + +>停止在 MS SQL 中阅读 + +当然可以 + +> 你疯了吗？！ 他们在每个数据库服务器上都有 384GB 的内存。 他们甚至在 Web 服务器上都有 SSD。 他们每个月提供的访问量仅为 5.6 亿，这是整个服务的 560000000 / 30/24/3600 = 216 RPS，如果将其除以 Web 服务器数量，则每个 Web 服务器将为 19 RPS ，而且它不是廉价服务器，甚至在 Raid 1 和 shit 中甚至都有 SSD。 给定像这样的数字，我会很高兴我没有使用 IIS 或任何 Microsoft 软件来提供 Web 应用程序... + +您的计算基于以下假设：这是其硬件堆栈可以管理的最大数量。 它在文章中多次声明，所有内容都超量配置，正常运行负载约为 10％。 +您所做的重大损害会导致类似的结论。 + +如果他们具有关于在最高性能下可以处理多少页面请求的任何统计信息，那将更加有趣。 即使这样，它也说明了他们特定的软件堆栈，将他们认为缺乏 RPS 归因于 IIS 是愚蠢的 + +正如 Nikita 所说，这些数字似乎并不令人印象深刻。 我在 SQL 部分中不知道，但是在 HTTP 部分中，只有一台具有 apache 和 php 的 1GB ram 双核服务器可以完成这项工作。 + +Nick Craver-此处的堆栈溢出系统管理员。 + +我以为我会在这些评论中消除一些混乱和不好的数字。 + +页面浏览量仅占我们负载的一小部分。 我们为许多 AJAX / JSON 路由和 API 请求提供服务，在任何给定的工作日总计超过 1.3 亿个请求。 例如，昨天我们处理了 150,091,472 个请求，平均约为 1730 RPS。 当然，我们有高峰时间与非高峰时间，所以这不是一个很好的指标。 在高峰期，我们通常会在 9 个主要 Web 服务器中的每一个上看到 2600-3000 RPS，负载约为 15％。 供参考：过去 30 天内，我们处理了 3,710,241,322（37 亿）个请求。 + +注意：这些 Web 服务器可能已经使用了 4 年，订购时并没有达到最高级的水平（Intel E5640 处理器）。 而且，这些数字不包括每个页面视图附带的我们的 Websocket 连接，它们将使数字甚至更高，并且它们由相同的 9 台 Web 服务器提供服务。 + +IIS 和 Microsoft 堆栈并不是所有时间都花在哪里（只有一小部分时间花在这里），它存在于我们的代码，API 调用，DB 查询，标签引擎请求等中。 对我们的网络的每个请求的*时序细分。 然后，每隔一段时间我们就会通过调整传递来发疯，并取得巨大的性能胜利……这是我们有一段时间没做过了。 在下一次优化通过之后，我将尝试发布更新的利用率数字。 同样值得注意的是，我们提供的几乎所有内容都不是静态内容，这些请求由我们的 CDN 处理的时间超过 99.97％。* + +@bob-托德是一位优秀作家。 但是他可能会考虑雇用编辑。 看来错别字已得到纠正。 您必须是一个很好的编辑才能赶上这一点。 也许你应该申请这份工作。 + +有人能解释为什么“堆栈溢出的读写比率为 40:60”吗？ 如何测量？ 什么构成读写操作？ 我对该统计数据感到非常惊讶。 我以为它将具有 99：1 的读写比。 与一小部分人发布新问题，答案，投票赞成/反对等等相比，不是大多数人只是查看答案而进行的操作。 + +很棒的帖子。 作为 stackoverflow 的粉丝，我只是喜欢这个极富启发性和内容丰富的博客。 + +很棒的文章，我很奇怪地从工程学的角度看待目前的体系结构。 11 万行和对抽象的厌恶通常不是成功的工程运动的先兆。 至少在一起时 我希望安装一些非常有趣的过程来帮助保持平稳运行。 + +但丁·埃里克（Dante Elrik） + +谢谢。 很高兴看到有人放弃了他们的基础架构和方法论。 对于所有批评家：他们所做的都是有效的。 成功了 很稳定 谁在乎这是怎么做的。 他们就是这样做的，而且显然很成功。 我敢肯定，如果您想像这些人一样详细描述它，那么高可扩展性将发布您的“高级”技术堆栈和公司文化。 就我自己而言，从物理基础结构到开发人员与“站点可靠性工程师”的比例，我发现这是一本有趣的文章。 \ No newline at end of file diff --git a/docs/147.md b/docs/147.md index fa00b4d..a62f6a8 100644 --- a/docs/147.md +++ b/docs/147.md @@ -1,26 +1,154 @@ -# 棱镜更新：基于文档和用户的机器学习 +# Tumblr：哈希处理每秒 23,000 个博客请求的方式 -> 原文： [http://highscalability.com/blog/2012/8/1/prismatic-update-machine-learning-on-documents-and-users.html](http://highscalability.com/blog/2012/8/1/prismatic-update-machine-learning-on-documents-and-users.html) +> 原文： [http://highscalability.com/blog/2014/8/4/tumblr-hashing-your-way-to-handling-23000-blog-requests-per.html](http://highscalability.com/blog/2014/8/4/tumblr-hashing-your-way-to-handling-23000-blog-requests-per.html) -![](img/70ac891b8ff6179d45189f15eaa4af67.png) +![](img/b53e7c03eb181dee4f3635b07ef4a84e.png) -在 [Prismatic Architecture-使用社交网络上的机器学习确定您应该在网络上阅读的内容](http://highscalability.com/blog/2012/7/30/prismatic-architecture-using-machine-learning-on-social-netw.html)的同时，Jason Wolfe 甚至面对漫长的夜晚将 iPhone 应用程序投入使用而感到疲倦的感觉， 英勇地同意谈论 Primatic 的机器学习方法。 +*这是 Tumblr 的 SRE 工程师 [](http://michael.tumblr.com/) [Michael Schenck](http://michael.tumblr.com/) 的特邀帖子。* -文档和用户是 Prismatic 应用 ML（机器学习）的两个领域： +在 Tumblr，博客（或 Tumblelog）是我们互联网上访问量最高的面孔之一。 tumblelogs 最方便的方面之一是其高度可缓存的特性，这是奇妙的，因为 Tumblr 网络为我们的用户提供了很高的视图/发布比率。 就是说，扩展边界代理层（更不用说缓存层）对满足所有这些请求是必需的，这并非完全简单。 -### 文件 ML +本文介绍了负责博客服务的外围部分的体系结构，这是我们流量更大的外围端点之一。 -* 给定一个 HTML 文档： - * 了解如何提取页面的主要文本（而不是侧边栏，页脚，注释等），标题，作者，最佳图像等 - * 确定相关功能（例如，文章的主题，主题等） -* 其中大多数任务的设置非常典型。 使用其他机器上的大批作业对模型进行训练，这些机器从 s3 读取数据，将学习到的参数文件保存到 s3，然后在摄取管道中从 s3 读取（并定期刷新）模型。 -* 流出系统的所有数据都可以反馈到该管道中，这有助于了解更多有趣的内容，并随着时间的推移从错误中学习。 -* 从软件工程的角度来看，Prismatic 编写的最有趣的框架之一是“ flop”库，该库实现了最先进的 ML 训练和推理代码，看起来与精美的普通 Clojure 代码非常相似，但是可以编译（使用 宏的魔力）到低级数组操作循环，这些循环与 Java 一样接近金属而无需借助 JNI。 -* 与相应的 Java 相比，该代码可以紧凑和易于阅读，并且执行速度基本相同。 -* 创建[快速运行的故事聚类组件](http://blog.getprismatic.com/blog/2012/4/17/clustering-related-stories.html)付出了很多努力。 +这是我们的方法。 -### 用户 ML +### 统计信息 -* 猜测用户对社交网络数据感兴趣的内容，并使用应用内的显式信号（+ /删除）完善这些猜测。 -* 使用显式信号的问题很有趣，因为用户输入应该很快反映在其提要中。 如果用户连续从给定的发布者中删除了 5 篇文章，请立即停止向他们展示该发布者的文章，而不是明天。 这意味着没有时间在所有用户上运行另一个批处理作业。解决方案是在线学习：立即根据用户提供给我们的观察结果更新用户模型。 -* 用户交互事件的原始流已保存。 这样可以在以后发生机器故障或类似情况时通过原始数据上的松散写回缓存丢失任何数据，从而在以后的原始事件中重新运行用户感兴趣的 ML。 在线学习中的漂移可以得到纠正，并且可以计算出更准确的模型。 \ No newline at end of file +* 共有 278 名员工，团队中有 6 名员工负责 Tumblr 的所有外围（Perimeter-SRE），包括一名经理。 + +* 超过 2800 台服务器中，不到 20％的服务器用于博客服务功能 + +* 每秒（峰值）超过 23,000 个博客请求 + +* 每秒（峰值）超过 6,500 个博客缓存清除事件 + +* 超过 1.96 亿个博客 + +* 超过 930 亿个帖子 + +### 平台 + +* [HAProxy](http://www.haproxy.org/) + +* [清漆](https://www.varnish-cache.org/) + +* [鸟](http://bird.network.cz/) + +### 我们在哪里-基于地图的分区 + +在早期，我们只需要一台活动和一台备用代理服务器以及清漆节点。 两者都很容易管理，监视和高度可用。 + +但是，由于要满足所有用户请求，因此将达到容量限制，并且由于流行而导致停机前，必须准备好下一步步骤（即使不是理想的部署）。 + +### 超出单个代理节点 + +超出单个 活动 代理服务器的数量非常普遍，并且通常涉及 DNS。 像循环 A 记录这样基本的东西可能会满足您的需求，但通常值得花额外的钱进行健康检查 GSLB 配置（即使您只有一个地理位置）。 + +DNS 的缺点是，尽管名称服务器将以相当均匀的速率对每个 IP 进行响应，但不能保证每个查找都将用于相同数量的请求。 用户 A 可能在一分钟内向解析的 IP 发出 10 个请求，而机器人 B 可能在同一分钟内发出 100 个请求。 如果您有两个 IP，则用户 A 获得一个 IP，而机器人 B 获得另一个 IP，而它们是仅有的两个发出请求的客户端，那么您的一个代理的请求速率是另一个的 10 倍。 + +较低的 TTL 可以减轻此影响，以便 30 秒 TTL 可以平衡两个代理之间的那 110 个请求。 在最初的 30 秒内，用户 A 将转到代理 P1，而机器人 B 将转到代理 P2。 然后，他们的下一个解决方案可能会交换 IP，以便用户 A 将其请求发送到代理 P2，而机器人 B 将其请求发送到代理 P1。 在该分钟窗口结束时，每个代理将处理大约 60 个请求。 TTL 较低的缺点是查找更多，因此 DNS 成本较高（但 DNS 通常是您较便宜的第三方服务之一）。 + +### 超出单个清漆节点 + +虽然 DNS 可以为您增加代理层的时间，但是缩放清漆要复杂一些。 即使您使用单个清漆节点的容量限制围绕请求并发进行，您也不希望简单地在循环中添加两个清漆节点。 这降低了缓存命中率，清除了更多的资源/时间，并且实际上并没有增加缓存的工作量（仅复制它）。 + +超出单个清漆节点的最简单迭代是 静态分区 。 这涉及确定您的唯一标识符，并在两个清漆节点之间划分此空间。 + +对于 Tumblelogs，这是博客的主机名。 由于 DNS 不区分大小写，因此您只需要担心 40 个字符即可。 字母数字（a-z 和 0-9）和四个允许的字符（-_。〜）。 因此，对于两个清漆节点，博客主机名在这两个缓存节点之间被分割（在第一个字符上）。 + +### 均匀分布的分区-通过一致的哈希 + +前面的两个示例（DNS 循环和静态分区）都是朝着正确方向迈出的一步，但是在分区方面却提供了非常粗糙的粒度。 在足够小的规模上，这种粒度不一定是有问题的，但是随着您的流量开始增长，方差变得更加明显。 结果，减少最不热和最热节点处理的流量差异变得越来越重要。 这就是一致性哈希真正可以发挥作用的地方。 + +### 分区代理流量 + +如果您的服务器所处的环境可以影响服务器前面的路由器，用户和代理服务器之间的路由器的路由表，那么您可以利用等价的多 -路径路由（ECMP）。 ECMP 使您能够将代理视为同一哈希环中的多个切片，然后在这些切片之间映射请求者。 + +这是通过通知到特定目标 IP（高可用性 IP）的多个路径（代理服务器）的路由基础结构来实现的。 然后，ECMP 将对请求源进行哈希处理，以确定哪个代理应接收此请求会话的数据包。 典型的 ECMP 实现提供第 3 层（仅 IP）和第 3 + 4 层（IP：端口）哈希选项。 第 3 层意味着来自特定 IP 的所有请求将转到特定的代理，这可能有助于调试，但与使用单个 NAT IP 的大型网络不平衡。 第 3 + 4 层通常提供最佳的分发，但是调试特定的客户端变得更具挑战性。 + +有多种方法可以 通知 路由器多个路径，但是我建议使用 OSPF 或 iBGP 进行动态路由通告。 一个人只需要在环回接口上侦听高度可用的 IP，启用内部路由以及将自己的 IP 作为下一跃点广告到该高度可用的 IP。 我们发现 BIRD 提供了一种轻巧可靠的方式来执行来自代理的路由广告。 + +### 划分清漆流量 + +Tumblelog 通过其完全限定的域名（FQDN）进行标识，因此，博客的所有 URI 路径将始终在该博客 FQDN 下找到。 Tumblelog 的大部分是 tumblr.com 的子域，例如 [engineering.tumblr.com](http://engineering.tumblr.com/) ，但是我们也支持用户携带自己的自定义域名 。 + +考虑各种 FQDN 时，很明显，TLD 的变体数量最少，然后是域名（特别是由于绝大多数是 tumblr.com），然后是子域。 因此，我们最重要的位出现在可变长度字符串的最左侧。 + +### 了解问题域 + +![](img/acbf9820b55f36b5e6df32353fdd183a.png) + +* 完美-演示将散列函数应用于我们的测试数据集时，其散列函数是否为 完美 + +* constant_hdr-主机标头上的一致性哈希（最佳现实结果） + +* constant_hdr_use_domain_only-基本域名（即 tumblr.com 或 foo.net）上的一致性哈希，只有两个阵营 tumblr.com 和所有其他域名 + +* mapbased_firstchar-将主机标头的第一个字符映射到清漆节点（我们的原始静态分区实现） + +* mapbased_hdr-基于主机标头的映射 + +虽然一致的散列显然是 tumblelog FQDN 的最平均分布的领先者，但是我们接着确定散列函数是否合适。 默认情况下，HAProxy 使用 SDBM 哈希函数。 但是，在进一步研究后，通过比较 SDBM，CRC，MD5，DJB2 等，我们确定 DJB2 提供了更好的分布。 这导致我们向 HAProxy 提交了补丁，以使哈希函数可配置（有关更多信息，请参见“感谢”部分）。 + +### 比较静态分区和一致性哈希 + +![](img/92b6bf9ab0a831619ca9f08d88d90435.png) + +这显示了在移至最佳匹配哈希函数之前和之后，每个清漆节点每秒请求之间的方差变化。 + +### 其他注意事项 + +### 节点增长 + +在任一模型中，节点增长将意味着键空间移位，从而导致缓存失效。 在一致的哈希模型中，预测将失效的键的百分比要容易得多。 基本上为 1 / N（N 是添加新节点之前的缓存节点数）。 使用静态分区模型，除非您对要从中获取键空间的节点的请求进行分析，否则最糟糕的情况是小于或等于键上键的总百分比。 您从中获取键空间的节点。 + +### 节点故障 + +使用静态分区时，除非您提供故障转移选项，否则单节点故障将导致无法访问 1 / N 密钥。 HAProxy 确实允许您拥有一个备用节点，但是现在您可以决定了。 每个密钥空间有 2N 个缓存节点（一个活动，一个备用）或共享的备用节点。 一种极端情况是 浪费 占硬件的 50％，其中频谱的另一端（所有活动节点之间共享 1 个备用节点）意味着两个故障节点导致备用 支持其他活动节点的密钥空间的 2 倍。 + +使用一致的哈希，将自动处理节点故障。 删除一个节点后，将移动 1 / N 个键（导致 1 / N 个键无效），并且每个剩余的活动节点的键空间均匀增加。 + +### 正在清除缓存 + +将清除请求发送到单个清漆节点很容易，但是从多个清漆节点清除也应该很容易。 不必使代理服务器和清除服务器保持同步，最简单的方法是通过同一代理服务器发送所有清除请求。 + +拒绝来自非本地 IP 空间的清除尝试非常重要，以防止任何恶意的批量清除。 + +### 获得的经验教训 + +* 您知道尚未回答的问题的答案。 面对扩展挑战时，请不要忽视您已经在其他地方使用的模式。 + +* 通过简单扩展。 在短期内可能会增加复杂性以克服可伸缩性挑战，但最终会赶上您。 + +* 了解您的哈希函数。 您使用的哈希函数与决定如何处理哈希值同样重要。 + +* 降级，不失败。 建议您的代理人监视自己达到后端的能力。 如果不能，则不要停止发布路由，而只是发布非优先级路由（例如，使用 OSPF 会增加路径成本）。 这样，如果所有后端都无法正常运行，您仍然可以提供错误页面，而不是无法访问。 + +### 谢谢 + +## * [Blake Matheny](http://tumblr.mobocracy.net/) 和 [Andrew Terng](http://andrew.tumblr.com/) 进行了散列函数比较并为 HAProxy 创建了补丁。 + +* [Bhaskar Maddala](http://maddalab.tumblr.com/) 与 HAProxy 社区合作，以获取 [此功能已添加到 HAProxy 1.5 版本](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-hash-type) 。 + +* [Arnoud Vermeer](http://blog.arnoudvermeer.nl/) 和 [Aaron Prat](http://aaronprat.tumblr.com/) 与 ECMP / OSPF 流量分配有关。 + +## 相关文章 [ + +* [关于 HackerNews](https://news.ycombinator.com/item?id=8132473) +* [雅虎以 10 亿美元的价格收购了 Tumblr 架构](http://highscalability.com/blog/2013/5/20/the-tumblr-architecture-yahoo-bought-for-a-cool-billion-doll.html) +* [Tumblr Architecture-150 亿页面浏览量一个月，比 Twitter 难扩展](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) + +对于任何混乱，我们深表歉意，共有 278 位 Tumblr 员工。 + +负责 Tumblr 所有外围（Perimeter-SRE）的团队由 6 人组成（包括一名经理）。 + +本文介绍了负责博客服务的外围部分的体系结构，这是我们流量更大的外围端点之一。 + +对于那些不了解哈希的人来说，它会使您变得 O（1）复杂，并且比对普通 b 树数据库的搜索要快。 令人惊讶的结果，我想这就是您扩展 tumblr 之类的方式的原因：） + +非常有趣的文章。 +但是有一个问题：您提到 BIRT 是 IP 平衡器，尽管 Haproxy 也是平衡器，但是对于 TCP / HTTP 级别，不是 IP。 那么负载均衡人员到底是谁呢？ + +感谢您分享这个幕后或“后台”视图。 “ 1.96 亿个博客”数量巨大，接近 1000 亿个帖子表明这些博客已被实际使用，而不是像其他平台那样，通常一旦注册就此后一直处于闲置状态。 + +从网络工程的角度来看，这非常有趣。 我猜想您的 HAProxy 框上正在运行 BIRD，然后将散列的流量平衡到 Varnish？ 是否还可以通过 Varnish 服务器从您的边缘路由器提供网络图？ 谢谢！ \ No newline at end of file diff --git a/docs/148.md b/docs/148.md index 592724b..bb0705a 100644 --- a/docs/148.md +++ b/docs/148.md @@ -1,206 +1,298 @@ -# 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容 +# 使用 HAProxy，PHP，Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构 -> 原文： [http://highscalability.com/blog/2012/7/30/prismatic-architecture-using-machine-learning-on-social-netw.html](http://highscalability.com/blog/2012/7/30/prismatic-architecture-using-machine-learning-on-social-netw.html) +> 原文： [http://highscalability.com/blog/2014/8/11/the-easy-way-of-building-a-growing-startup-architecture-usin.html](http://highscalability.com/blog/2014/8/11/the-easy-way-of-building-a-growing-startup-architecture-usin.html) -![](img/70ac891b8ff6179d45189f15eaa4af67.png) +![](img/84668570dbc912809cd435a8992b89f2.png) -*关于 [Prismatic](http://getprismatic.com/) 的体系结构的帖子改编自与 Prismatic 程序员 [Jason Wolfe](http://w01fe.com/berkeley/)* 的电子邮件对话。 - -您今天应该在网上阅读什么？ 任何一个完全现代的人都必须每天解决这个难题，通常使用一些神秘的方法来判断他们的许多供稿中的重要内容：Twitter，RSS，Facebook，Pinterest，G +，电子邮件，Techmeme，以及无数其他信息来源。 - -Prismatic 的 Jason Wolfe 慷慨地同意使用机器学习，社交图谱，BigData，函数式编程和内存实数等性感词来描述其彻底的现代解决方案，以回答“读什么” 及时饲料加工。 结果可能更加隐秘，但是这或类似的事情将是我们如何面对寻找隐藏在无限深的信息池中的有趣主题和故事的挑战。 - -关于 Prismatic，有两点很突出。 他们想让您知道 Prismatic 是由一个由四名计算机科学家组成的小组组成的，其中三名来自斯坦福大学和伯克利分校的非常强大的年轻 PHD。 半危险的方法不会起作用。 他们正在为解决信息过载问题带来大脑力量。 但是这些 PHD 还是程序员，他们从事网站，iOS 编程以及性感的 BigData / ML 后端编程等所有工作。 - -使 Prismatic 作为一种体系结构令我兴奋的一件事是，将来需要一遍又一遍解决的问题是将机器学习实时应用于大量的社会中介信息流 。 保密性使他们无法对自己的机器学习技术说太多话，但是我们的确在幕后高峰。 - -正如您所期望的，他们在做事上有些不同。 他们选择了 Clojure（一种可编译为 Java 字节码的现代 Lisp）作为他们的编程语言。 这个想法是使用函数式编程来构建细粒度，灵活的抽象，这些抽象被组成来表达特定于问题的逻辑。 - -一个功能强大的例子是它们的图形库，他们在各处使用它们。 例如，可以描述计算图以为每个用户创建等效于低延迟，流水线化的 map-reduce 作业集。 另一个示例是使用子图以模块化方式紧凑地描述服务配置。 - -鉴于对功能阐述的关注，他们避免使用诸如 Hadoop 之类的大型框架，而是选择了一个更小，更可靠，更易于调试，更易于扩展且更易于理解的代码库。 - -对 Prismatic 方法的批评是要取得成果需要很长时间的培训。 首先，他们说开始获取优质的内容根本不需要花费很长时间。 其次，我要补充一点，开始使用 Long Sight 考虑这些类型的系统。 基于 ML 的推荐器将从儿童期开始接受培训，并将与您一生保持在一起。 您头脑中的可扩展数字模拟物将同时充当信息守卫和边锋。 - -在 [Tech Crunch 文章](http://techcrunch.com/2012/06/07/in-the-studio-prismatics-bradford-cross-wants-to-reinvent-social-news/)中，Prismatic 创始人 Bradford Cross pithily 将 Prismatic 描述为“围绕复杂的系统构建，该系统可提供大规模，实时，动态的个性化信息重新排名， 很好地将主题分类和归类为本体。” 现在，让我们看看该系统是什么样的... +此案例研究是 [Antoni Orfin](http://labs.octivi.com/author/aorfin/) 的来宾帖子， [Octivi](http://octivi.com/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 的联合创始人兼软件架构师。 -## 统计资料 - -* 每天都会从 Twitter，Facebook，Google Reader 和网络上获取并分析成千上万种社交信号，并分析成千上万的新新闻文章，博客文章和其他共享内容。 -* 在用户注册 Prismatic 的几秒钟内，就提取并分析了他们足够的历史活动，以提供非常可靠的主题和发布者建议。 消化了他们的社交网络以寻找似乎分享最相关内容的朋友。 用户在 Prismatic 上进行的每个交互也是一个学习的机会。 -* 在访问家庭供稿后的十分之几秒内，通过将用户兴趣模型与所有这些内容进行匹配，生成了最有趣的故事的供稿。 -* 每周为用户提供数百万的文章展示次数 +在文章中，我将向您展示我们基于 HAProxy，PHP，Redis 和 MySQL 开发非常简单的架构的方式，该架构每周无缝处理大约 10 亿个请求。 还应注意进一步扩展该模式和指出不常见模式的可能方法，这些方法特定于该项目。 -## 平台 +## 统计： -* 托管在 EC2 / Linux 上。 -* 99.9％的后端管道和 API 服务器是用 Clojure 编写的，Clojure 是一种现代 Lisp，可以编译为 Java 字节码。 -* 所有繁重的工作都发生在 JVM 内部。 -* MongoDB -* 的 MySQL -* S3 -* 发电机 -* 专注于构建自定义代码以有效解决特定问题。 +* 服务器： -## 数据存储和 IO + * 3 个应用程序节点 -* 系统不是围绕每个服务在数据库或分布式文件系统之间读取和写入实时数据的典型体系结构，而是围绕数据设计系统。 -* 大多数数据通过后端管道从一项服务流向另一项服务，而没有任何磁盘往返。 -* 在管道的最后，API 机器严重依赖于自定义的内存数据结构，这些数据结构会定期快照到磁盘。 -* 通过使数据尽可能靠近 CPU，大多数 API 请求几乎没有 IO 即可得到服务。 这样可以以非常低的延迟提供提要，从而使 API 机器保持 CPU 绑定，并可以轻松扩展以更轻松地处理更多用户。 -* 使用了许多现成的存储解决方案：MongoDB，MySQL 和 Amazon 的 S3 和 Dynamo。 每一个都经过仔细选择，以匹配要存储的数据的大小，访问模式和其他特征。 - -## 服务 - -* 从较高的层次上看，该体系结构分为大约 10 种不同的服务类型，大致分为 5 种不同的类别：数据摄取-后端； 入职； API-面向客户； 其他服务-面向客户； 批处理和其他服务。 -* 每个服务被设计为执行一种操作，可以以特定方式进行水平扩展，并且通常受到一种或两种特定资源类型（IO，CPU，RAM）的限制。 -* 经济因素偏向于大型机器，因此服务是单身人士，但没有重大瓶颈会阻止水平扩展的预期。 + * 2 个 MySQL + 1 个备份 -## 数据提取-后端 - -* 每天都会创建大量有趣的内容（新闻文章，博客文章，其他网页等），并且 Prismatic 希望尽可能多地了解它。 -* 对于每个内容，必须知道谁在共享它，以及他们在说什么，以便可以在文章旁边显示相关评论，从而可以向用户显示由其朋友或具有相似品味的人共享的内容。 -* 此过程的第一步是摄取和分析内容和社交数据。 采集管道的顶部是轮询器： - * RSS 轮询器在供稿中循环查找新文章 - * Twitter 和 Facebook 轮询器连接到相应的 API，并从用户及其朋友那里获取评论/推文。 - * 这些服务非常简单，并且大多数都是无状态的。 - * 唯一的真实状态和有趣的部分是弄清楚已经看到的内容，并智能地确定接下来要轮询的内容的优先级。 - * 实际上，最困难的问题之一是在每次社交互动流入管道的其余部分之前，先确定其内容是什么。 这很困难，因为人们可能会共享同一篇文章的许多版本（缩短的链接，移动版本和常规版本等）。 -* 从这里，RSS 条目和评论/共享/推文（具有正确规范的 URL）流入障碍，在障碍中确定实际获取和分析的内容。 - * 垃圾邮件和其他垃圾将在稍后的版本中消除，但是最好的伟哥垃圾邮件文章是不会浪费更多的周期的文章。 - * 进行剪切的 URL 传递到获取/分析管道 - * 此阶段的 URL 进入获取/分析管道。 这是许多魔术开始发生的地方。 - * 保留一个 URL 队列，每个 URL 都通过一个“图”运行，该“图”依次详细说明 URL，获取其 HTML，应用机器学习算法提取文章文本，识别最佳图像，提取发布者，并标记适用的标签 主题等等。 - * 为了使这些算法能够快速运行，适合内存并且性能良好，已经进行了大量的工程设计。 处理所有 URL 本身的问题当然令人尴尬地是并行的。 -* 提取阶段的末尾是 doc master，其工作是接收有关它们的精心撰写的文章和社交环境（随着时间的推移不断滴入），进行匹配，将文章（以在线方式）聚集到故事中 集群，确定当前有效的文档集，并管理 API 机器的索引。 - -## 入门-后端 - -* 入职是吸收有关新用户的数据，因此可以在注册该应用后的几秒钟内为他们提供出色的个性化体验。 这有两个主要组成部分： - * 根据用户在 Twitter，Facebook 或 Google 阅读器上的活动，为用户找出建议的主题和发布者， - * 分析用户的社交图谱，以推断出哪些朋友的分享是他们喜欢文章的最有力信号。 -* 这些服务令人尴尬地是并行的，这次是跨用户的。 除了有效的社交图分析的复杂性（Prismatic 不想说太多）之外，关键是如何将这些服务调整为具有非常低的延迟和合理的吞吐量： - * 例如，对于活跃于 Twitter，Facebook 或 Google Reader 的用户，可以在 15 秒或更短的时间内计算出一百多个准确的主题和发布者建议。 这足够快，可以在用户 OAuth 登录后开始计算建议，并且通常在用户完成创建帐户（选择句柄和密码）并进入演练时就可以使用个性化建议。 - * 在这 15 秒内，发生了很多事情： - * 用户最近的帖子可在 Twitter 和 Facebook 上获取，他们喜欢的文章可在 Google Reader 上获取，等等。 这本身可能需要 10 秒钟或更长时间才能完成。 - * 标识用户，她的朋友等共享的多达一千个左右唯一 URL 的集合。 - * 这些流进入获取/分析管道的版本中，在该版本中，所有 URL 都使用上述相同的 ML 堆栈进行提取和详细说明 - * 该分析的结果被汇总，后处理并保存到 DynamoDB 和 S3 -* 此过程的延迟确实很关键，因此这些过程无法串行执行-必须尽可能地进行流水线化和并行化。 -* 吞吐量也很重要，因为该过程非常繁琐，并且在进行大量注册时，需要花费大量精力来降低延迟。 这正是 Prismatic 的流处理和聚合库真正发挥作用的地方，它为每个用户（并行供多个用户）使用接近全容量的低延迟，流水线化的 map-reduce 作业集提供了等效的性能。 机。 + * 2 个 Redis -## API-面向客户 +* 应用程序： -* API 机器中包含了 Onboarding 和 Data Ingest 服务。 -* 除了实际的提要生成过程外，不会说太多，只是它是一个复杂且高度优化的过程，该过程具有许多阶段，这些阶段与用户的“指纹”相匹配，并针对索引进行查询，检索，排序和分页生成的提要。 几百毫秒。 -* 从系统角度来看，这里的主要设计目标/挑战是： - * 必须将最新文章编入索引，并且可以用于生成低延迟的提要 - * 该索引非常大（许多 GB），并且必须实时更新，以便用户可以找到重大新闻 - * 用户应在各台计算机之间实现负载平衡，并且响应负载而将新计算机启动（并关闭）相对容易和快速。 - * 产生良好的用户供稿不仅需要索引-我们还需要用户的“指纹”-他们的兴趣，社交关系，他们最近看过的文章等等。 - * 该指纹非常大，并且随着用户查看站点上的内容并与之交互而不断变化。 -* 前几个问题的解决方案涉及 doc-master。 - * doc-master 机器会整理我们当前的文档集，对文档进行预处理，然后每隔几分钟就会将一组准备好的索引文件写入 S3。 - * 当新的 API 机器启动时，它首先读取这些文件并将其转储到内存中，从而为其提供索引的近乎最新的副本。 - * doc-master 还向所有实时 API 机器实时发布用于索引更改（文档/注释添加和删除，故事集群更改等）的命令。 - * 当一台新机器出现时，它会重放最近几分钟的更改历史，以使索引保持最新状态。 - * 机器所需的其他一般状态（非特定于用户的状态）也将从 S3 读取到内存中并定期刷新，或者如果数据较大且访问频率较低，则存储在发电机中。 -* 剩下的问题是如何有效地为用户提供提要，而又不会产生 IO 成本以及在每个请求上获取和更新指纹的延迟。 - * 这里的方法是使用将用户绑定到 API 机器的粘性会话 - * 用户首次登录时，他们的数据都将在过期的刷新回写缓存中全部加载到内存中 - * 在整个用户会话中，此数据保留在内存中，并用于生成其供稿 - * 在整个会话过程中，所有用户操作均通过此同一 API 机器 - * 会话到期或计算机关闭时，每隔几分钟就对指纹中次要部分的更新进行批处理并刷新到冗余存储中 - * 更重要的更新是同步完成的，或者至少使用直接写缓存进行。 -* 在整个会话过程中仅读取一次用户指纹就需要付出很高的 IO 费用，这笔费用会在（通常）相对大量的 Feed 点击，页面，文章点击，共享等用户所获得的费用中摊销，并且 限制此数据的回写次数。 当一台计算机宕机时，数据将被刷新并将用户转移到另一台计算机上-在最坏的情况下，对于某些用户而言，几分钟的非关键数据将会丢失，这对于简单性和可伸缩性的好处是值得的 。 始终可以通过以后的原始事件日志上的批处理作业来弥补此损失。 + * 应用程序每周处理 1,000,000,000 个请求 -## 其他服务-面向客户 - -还有其他一些单独的面向客户的服务： - -* 公共提要-对未登录的用户进行主题和发布者提要的智能缓存，根据需要从常规 API 获取它们，并允许对每个提要的多个年龄进行分页。 -* 身份验证-处理帐户创建，登录等。 通常是 SQL 数据库前面的薄层，用于存储需要定期快照和备份的关键用户数据。 -* URL 缩短器 - -## 批处理及其他服务 - -* 机器语言培训，数据归档和事件跟踪/分析的其他服务。 -* MongoDB 用于存储服务器指标和用户分析，主要是因为它支持一个很好的低麻烦的故事，用于发送不同形状的原始事件，维护正确的索引以及保持在线汇总计数。 - -## 图库 - -* 这是一种很好地声明式描述计算图的方法，它发挥了 Clojure 的优势。 图只是 Clojure 映射，其中的键是关键字，而值是关键字函数，这些关键字函数采用由映射中的其他函数计算的值以及外部参数。 -* 它在各处使用。 例如，文档分析管道是一个图形，其中文档的每个详细说明都可能取决于之前的内容（例如，确定文档的主题取决于是否已提取其文本）； 新闻提要生成过程是一个由许多查询和排名步骤组成的图形； 每个生产服务本身就是一个图，其中每个资源（例如数据存储，内存索引，HTTP 处理程序等）都是可以依赖于其他资源的节点。 -* 这样可以轻松地执行以下操作： - * 以模块化方式（例如，使用子图）紧凑地描述服务配置 - * 产生图表，描绘出流程或服务的依赖性 - * 测量诸如文档分析之类的复杂计算中每个节点上发生的计算时间和错误，或诸如 API 之类的复杂服务的每个资源上的活动 - * 在不同的线程（或理论上甚至是机器）上智能地调度此类计算的不同节点 - * 通过使用模拟替换图表中的几个节点（例如伪造存储空间）等，轻松编写我们整个生产服务的测试。 - -## 基于文档和用户的机器学习 - -文档和用户是 Prismatic 应用 ML（机器学习）的两个领域： - -### 文件 ML - -* 给定一个 HTML 文档： - * 了解如何提取页面的主要文本（而不是侧边栏，页脚，注释等），标题，作者，最佳图像等 - * 确定相关功能（例如，文章的主题，主题等） -* 其中大多数任务的设置非常典型。 使用其他机器上的大批作业对模型进行训练，这些机器从 s3 读取数据，将学习到的参数文件保存到 s3，然后在摄取管道中从 s3 读取（并定期刷新）模型。 -* 流出系统的所有数据都可以反馈到该管道中，这有助于了解更多有趣的内容，并随着时间的推移从错误中学习。 -* 从软件工程的角度来看，Prismatic 编写的最有趣的框架之一是“ flop”库，该库实现了最先进的 ML 训练和推理代码，看起来与精美的普通 Clojure 代码非常相似，但是可以编译（使用 宏的魔力）到低级数组操作循环，这些循环与 Java 一样接近金属而无需借助 JNI。 -* 与相应的 Java 相比，该代码可以紧凑和易于阅读，并且执行速度基本相同。 -* 创建[快速运行的故事群集组件](http://blog.getprismatic.com/blog/2012/4/17/clustering-related-stories.html)付出了很多努力。 - -### 用户 ML - -* 猜测用户对社交网络数据感兴趣的内容，并使用应用内的显式信号（+ /删除）完善这些猜测。 -* 使用显式信号的问题很有趣，因为用户输入应该很快反映在其提要中。 如果用户连续从给定的发布者中删除了 5 篇文章，请立即停止向他们展示该发布者的文章，而不是明天。 这意味着没有时间在所有用户上运行另一个批处理作业。解决方案是在线学习：立即根据用户提供给我们的观察结果更新用户模型。 -* 用户交互事件的原始流已保存。 这样可以在以后发生机器故障或类似情况时通过原始数据上的松散写回缓存丢失任何数据，从而在以后的原始事件中重新运行用户感兴趣的 ML。 在线学习中的漂移可以得到纠正，并且可以计算出更准确的模型。 - -## 得到教训 - -* **查找您的故事**。 请仔细考虑整个管道以及流经该管道的所有数据。 使用针对特定问题的解决方案来应对可伸缩性挑战。 每个服务都内置了自己的扩展故事，并且这些服务以一种通信方式进行通信，应该可以轻松地扩展每个组件，而又不会给其他组件带来太多压力。 相反，从围绕 Hadoop 作业构建的系统开始，将所有数据以原始格式存储在分布式数据库/文件系统中，Prismatic 会讲一个不同的故事。 -* **尴尬地发现并行的机会并加以利用**。 -* **在用户等待**的同时并行工作。 例如，入职流程会吸收有关新用户的数据，以便可以在注册该应用后的几秒钟内为他们提供出色的个性化体验。 -* **使用函数式编程**构建细粒度，灵活的抽象。 这些抽象构成为表达特定于问题的逻辑。 -* **避免使用大型，整体式框架**，例如 Hadoop。 这样就产生了一个较小的代码库，在所有条件相同的情况下，它更不容易出错，更易于理解并且更易于扩展。 之所以建立自己的库，仅仅是因为开源代码的许多功能都被锁定在整体框架中，并且在某些问题中断或无法扩展时，不容易重用，扩展或调试。 -* **合适的人对于使这一切都至关重要。 当前的后端团队由三位 CS 博士组成，他们从事从 ML（机器语言）算法到低级系统工程到 Web 和 iPhone 客户端代码的所有工作。** -* **所有代码都尽早投入生产，**通常是通过对使构建和调试生产服务变得简单而有趣的工具进行投资。 -* **保持简单**。 不要为简单的东西承担复杂的库或框架的负担，并且当一个简单得多的解决方案就足够好的时候也不要幻想。 例如，使用简单的基于 HTTP 的消息传递协议，而不是流行的框架之一。 在合理的情况下，乐于为刚刚可用的托管解决方案（例如 S3 或 Dynamo）支付更多费用。 -* **投资构建出色的工具和库**。 例如，Prismatic 的“触发器”库使他们可以在代码的 1/10 中编写与 Java 一样快的数字运算机器学习算法。 “存储”将键值存储的许多不重要的细节抽象掉，从而允许编写用于缓存，批处理和刷新的高级抽象，这些抽象可在各种情况下在各种存储引擎中工作。 “图形”使编写，测试和监视分布式流处理服务变得轻而易举。 -* **仔细考虑每种数据类型**，不要指望找到一种适用于 IO 和存储的千篇一律的解决方案。 - -## 相关文章 + * 单个 Symfony2 实例高达 700 req / s（平均工作日-550 req / s） -* [Prismatic 希望成为数字时代的报纸](http://gigaom.com/2012/05/03/prismatic-wants-to-be-the-newspaper-for-a-digital-age/) -* [棱柱形博客](http://blog.getprismatic.com/) -* [关于 Clojure 的主题演讲](https://github.com/strangeloop/clojurewest2012-slides) -* [棱柱形希望创建一个新类别的社会新闻](http://bits.blogs.nytimes.com/2012/04/03/prismatic-hopes-to-offer-a-new-category-of-social-news/) -* [Prismatic 的布拉德福德·克罗斯（Bradford Cross）在工作室里想重塑社交新闻](http://techcrunch.com/2012/06/07/in-the-studio-prismatics-bradford-cross-wants-to-reinvent-social-news/ ) -* [Prismatic 的软件工程](http://blog.getprismatic.com/blog/2012/4/5/software-engineering-at-prismatic.html) -* [Prismatic 如何处理数据存储和聚合](http://blog.getprismatic.com/blog/2012/4/9/how-prismatic-deals-with-data-storage-and-aggregation.html) -* [DataSift 架构：每秒 120,000 条推文的实时数据挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html ) + * 平均响应时间-30 毫秒 -好看！ + * 清漆-超过 12,000 req / s（在压力测试过程中达到） -半危险=危险？ 我第一次听到这个词。 +* 数据存储区： -干杯， + * Redis-160,000,000 条记录，100 GB 数据（我们的主要数据存储！）， ---rj + * MySQL-300,000,000 条记录-300 GB（第三缓存层） -罗杰击败了我，但是： +## 平台： -“半危险的方法不会起作用。” 那么好吧，我想什至根本不考虑那些完全危险的方法。 = P +## ![logical architecture.png](img/56cb99c8dcdf79a30dcf13134a25c750.png) -我每天都会使用 getprismatic.com 数周，我必须承认，现在它已成为新闻探索的一部分。 梦幻般的建筑，当我想到它们如何实时带来如此优质的内容时，甚至让我惊讶。 +* 监控： -感谢您对他们的文章进行了详细的高级介绍。 很棒的文章！ + * 伊辛加 -好读！ :) + * 已收集 -这都是有点老的学校。 机器学习= 1980。 +* Application: -您是否考虑过将 Redis 用于内存中的数据结构？ 听起来很合适。 \ No newline at end of file + * 带有 Keepalived 的 HAProxy + + * 清漆 + + * 带有 Symfony2 框架的 PHP（PHP-FPM） + +* Data store: + + * 具有 HAProxy 负载平衡的 MySQL（主-主） + + * Redis（主从） + +# 背景 + +大约一年前，我们的朋友带着一个苛刻的问题来到我们的办公室。 他们经营着一家快速成长的电子商务初创公司，当时他们想扩展到国际市场。 + +由于它们仍然是一家初创型公司，因此建议的解决方案必须具有成本效益，以免在下一台服务器上用完钱。 旧版系统是使用标准 LAMP 堆栈构建的，他们已经拥有强大的 PHP 开发人员团队。 引入新技术必须很聪明，以免使体系结构过于复杂，并让他们与现有人员进一步维护平台。 + +系统架构必须以可扩展的方式设计，以实现其扩展到下一个市场的计划。 所以我们来检查他们的基础设施... + +![soa-after.png](img/12c817cd917203ed7b1bc8c3efab4761.png) ![soa-before.png](img/164417ce7d2ca4bf693993b632bc38a2.png) + +以前的系统是单片设计的。 在后台有一些单独的基于 PHP 的 Web 应用程序（该创业公司有许多所谓的前端网站）。 他们中的大多数使用单个数据库，他们共享一些处理业务逻辑的通用代码。 + +此类应用程序的进一步维护可能是一场噩梦。 由于必须重复某些代码，因此在一个网站中进行更改将导致业务逻辑不一致-他们始终必须在所有 Web 应用程序中进行相同的更改。 + +从项目管理的角度来看，这也是一个问题-谁负责跨多个代码库分布的那部分代码？ + +根据这些观察，我们的第一步是将核心业务关键功能提取到单独的服务中（这是本文的范围）。 这是**面向服务的体系结构**的模式。 考虑“关注点分离”原则，但要考虑整个系统。 该服务保持一种特定的高级业务功能的逻辑。 举一个真实的例子-服务可以是搜索引擎，销售系统等。 + +前端网站正在通过 **REST API** 与服务进行通信。 响应基于 **JSON** 格式。 我们选择它是为了简单起见，而不是像 SOAP 那样对开发人员来说是苛刻的（没人喜欢解析 XML…;-)） + +提取的服务无法处理身份验证和会话管理之类的事情。 必须在更高层次上处理这些事情。 前端网站对此负责，因为只有他们才能识别其用户。 这样，我们使服务变得更简单-在进一步扩展问题和编写代码方面。 没什么不好的，因为它需要处理不同类型的思考任务。 + +## 好处： + +-完全独立的开发团队可以轻松开发单独的子系统（Service）。 开发人员不要互相干扰。 + +-**它不处理用户身份验证**和会话，因此这个常见的扩展问题消失了。 + +-**业务逻辑保存在一个地方**-跨不同前端网站的功能不再多余。 + +-**易于使服务公开访问**。 + +## 缺点： + +-**为系统管理员**做的更多工作-服务位于其自己的基础结构中，需要管理员额外注意。 + +-**保持向后兼容**-在一年的维护之后，API 方法发生了无数变化。 事实是，它们一定不能破坏向后兼容性，因为这会导致对每个前端网站的代码进行更改-以及一次部署所有网站的繁琐工作……一年之后，所有方法仍与 文档的第一版。 + +# 应用层 + +![physical architecture.PNG](img/03f05424f01e13f6dedef14ccab41d1c.png) + +与请求流一起，第一层是应用程序。 HAProxy 负载平衡器，Varnish 和 Symfony2 Web 应用程序位于此处。 + +来自前端网站的请求首先到达 HAProxy，然后将其分发到应用程序节点。 + +## 应用程序节点配置 + +* Xeon [[受电子邮件保护]](/cdn-cgi/l/email-protection) ，64GB RAM，SATA + +* 漆 + +* 阿帕奇 2 + +* PHP 5.4.X 作为 PHP-FPM 运行，具有 APC 字节码缓存 + +我们有三个这样的应用服务器。 双活模式下的 **N + 1 冗余-“备份”服务器正在积极处理请求。** + +在每个节点上保留**单独的 Varnish 可以降低缓存命中率，但是这样我们在这里没有 SPOF（单点故障）。 我们这样做是为了保持可用性而不是性能（在我们的案例中这不是问题）。** + +已选择 Apache2，因为旧版前端网站服务器也使用了 Apache2。 避免混合使用多种技术，使管理员更易于维护系统。 + +## Symfony2 应用 + +该应用程序本身建立在 Symfony2 之上。 这是一个 PHP 全栈框架，提供了许多有用的组件，可加快开发过程。 由于通常将 REST 服务基于复杂框架的决定对于某人来说听起来很奇怪，所以让我澄清一下背后的原因： + +* **访问 PHP / Symfony 开发人员**-客户的 IT 团队由 PHP 开发人员组成。 引入新技术（例如 Node.js）将导致需要雇用能够进一步维护系统的新开发人员。 + +* **干净的项目结构**-Symfony2 并不强加完整的项目结构，但具有非常明智的默认结构。 向新开发人员介绍该项目很简单，因为他们对代码很熟悉。 + +* **现成的组件**-遵循 DRY 概念...没有人想要重新发明轮子，所以我们没有。 我们广泛使用 Symfony2 控制台组件，它是一个不错的框架，可用于制作 CLI 命令，用于分析应用程序的工具（调试工具栏），记录器等。 + +在选择使用它之前，我们已经对**进行了性能测试**，以确保它能够处理计划的流量。 我们已经开发了概念证明，并对其进行了 JMeter 的测试。 结果令人印象深刻-700 req / s，响应时间高达 50ms。 它使我们确认，可以将这种复杂的框架用于此类项目。 + +## 应用程序配置文件&监视 + +我们正在使用 Symfony2 工具来监视应用程序。 有一个很好的事件探查器组件，我们可以用来收集特定方法的执行时间，尤其是与第三方网络服务进行通信的方法。 这样，我们可以发现潜在的弱点和应用程序中最耗时的部分。 + +详细日志记录也是必须的。 为此，我们使用了 PHP Monolog 库，该库使我们能够创建格式良好的日志行，开发人员和系统管理员完全可以理解。 必须始终记住要添加尽可能多的细节，我们发现越详细越好。 我们使用不同的日志级别： + +* **调试**-即将发生的事情-例如 在调用外部 Web 服务之前请求信息； 刚刚发生的事情-API 调用的响应 + +* **错误**-出了点问题，但请求流没有停止（例如，来自第三方 API 的错误响应）。 + +* **严重**-糟糕…应用程序刚刚崩溃了：-) + +因此，在生产环境中，您可以看到诸如 Error 之类的痕迹，并且在其下-Critical。 在开发/测试环境中，还记录了调试信息。 + +我们还将**日志分为单独的文件**（在 Monolog 库中，它们称为“通道”）。 有一个主日志文件，其中记录了所有应用程序范围内的错误以及来自特定渠道的简短日志。 我们将通道中的详细日志保存在它们各自的文件中。 + +## 可扩展性 + +扩展应用程序平台层并不困难。 HAProxy 的性能**不会长期耗尽**，我们正在考虑的唯一事情就是使它们冗余以避免 SPoF。 + +因此，当前模式只是添加下一个应用程序节点。 + +# 资料层 + +我们正在使用 Redis 和 MySQL 来存储所有数据。 **MySQL** 主要用作**第三层缓存**层，而 **Redis 是我们的主要数据存储区**。 + +## 雷迪斯 + +在设计系统时，我们正在考虑选择合适的数据库来满足计划的需求： + +* 保留大量数据（约 250,000,000 条记录）时不会失去性能 + +* 通常基于特定资源 ID 的简单 GET（无需查找或复杂的 SELECT） + +* 可以在单个请求中检索大量资源以最小化延迟 + +经过调查，我们决定使用 Redis。 + +* 我们执行的所有操作的复杂度为 O（1）或 O（N），其中 N 是要检索的键的数量。 也就是说，键空间的大小不会影响性能。 + +* 我们主要使用 MGET 命令来一次检索> 100 个键。 与在循环中进行多个 GET 相比，这可以省去网络延迟。 + +当前，我们有两台 Redis 服务器以主从复制模式运行。 它们每个都具有以下配置：Xeon [[受电子邮件保护]](/cdn-cgi/l/email-protection) ，128GB，SSD。 内存限制设置为 100 GB ...并且始终被完全消耗:-) + +![](img/cadc56a7a57d3c98a76004e613d0956d.png) + +由于应用程序并没有穷尽单个 Redis 服务器的性能限制，因此从服务器主要用作备份并保持高可用性。 如果主机崩溃，我们可以轻松地切换应用程序以使用从机。 复制在执行某些维护任务或迁移服务器时也很方便-轻松切换服务器。 + +您可能想知道我们的 Redis 一直处于 maxmemory 极限的情况。 大多数键是持久类型的-大约占键空间的 90％。 但是它们的其余部分是纯缓存，我们为其设置了到期 TTL。 现在，密钥空间分为两部分：一部分已设置 TTL（缓存），第二部分未设置（持久数据）。 由于可以设置“ volatile-lru” maxmemory 策略，因此会不断自动删除使用较少的缓存键（只有它们已过期）。 + +这样，我们就可以**仅保留一个既充当主存储又充当典型缓存**的 Redis 实例。 + +使用此模式时，必须始终记住监视“过期”键的数量： + +db.redis1：6379 >信息键空间 + +＃键空间 + +db0：keys = 16XXXXXXX，expires = 11XXXXXX，avg_ttl = 0 + +当您发现该数字危险地接近零时，请开始分片或增加内存;-) + +我们如何监控它？ 有一个 Icinga 支票，用于监视“到期”数是否达到临界点。 我们还收集了 Redis 图，以可视化“丢失键”的比率。 + +![redis-expires.png](img/8225dac1f9e2514be1c9702b51b1b0cf.png) + +一年后，我可以说我们完全加入了 Redis。 从项目一开始，就没有让我们感到失望-没有任何中断或其他问题。 + +## 的 MySQL + +除了 Redis，我们还使用传统的 MySQL 数据库。 罕见的是，我们通常将其用作第三个缓存层。 我们将最近未使用过的 MySQL 对象存储在其中，而将它们存储在 Redis 中会占用过多的内存，因此我们将它们保存在硬盘上。 这里没有什么花哨的技术，但是我们希望将堆栈保持尽可能简单，以便于维护。 + +我们有 2 台使用 Xeon [[受电子邮件保护]](/cdn-cgi/l/email-protection) ，64GB RAM，SSD 的 MySQL 服务器。 它们上有一个本地的异步主-主复制。 另外，我们保留单个从节点仅用于备份。 + +## MySQL 的高可用性 + +正如您在物理体系结构图上看到的那样，在每个 MySQL 框上，HAProxy 也处于保持状态。 与 MySQL 的连接通过 HAProxy 进行。 + +在每台数据库服务器中安装 HAProxy 的模式导致保持堆栈的高可用性，并且无需为负载平衡器添加添加下一个服务器。 + +HAProxy 以主动-被动模式运行（一次仅使用其中之一）。 对它们的可用性的控制是通过保持机制进行的。 在 keepalived 的控制下有一个浮动 IP（VIP）。 它检查主负载均衡器节点的可用性。 发生故障时，第二个（被动）HAProxy 节点将接管 IP。 + +## Scalability + +数据库始终是应用程序中最难的瓶颈。 目前，不需要任何横向扩展操作-到**为止，我们正在通过将 Redis 和 MySQL 移至更大的框来垂直扩展**。 仍有空间，例如 Redis 在具有 128 GB 内存的服务器上运行-可以将其迁移到 256 GB 的节点上。 当然，这种笨重的盒子在快照或仅运行服务器等操作中也有缺点-启动 Redis 服务器将花费更长的时间。 + +放大（垂直）后，横向扩展。 令人高兴的是，我们已经准备好**易于分片的数据**结构： + +Redis 中有 4 种“大量”记录。 可以根据数据类型在 4 台服务器上分片它们。 我们会避免基于散列进行分区，而倾向于**将数据除以记录类型**。 这样，我们仍然可以运行始终在一种类型的键上执行的 MGET。 + +在 MySQL 中，表是以这种方式进行结构化的，从而可以轻松地将其中的某些表迁移到不同的服务器上-也基于记录类型（表）。 + +在无法进一步按数据类型进行分区之后，我们将进行散列处理：-) + +# 得到教训 + +* **不要共享您的数据库**-一次，一个前端网站希望将其会话处理切换为 Redis。 所以他们已经连接到我们的了。 这导致 Redis 缓存空间用尽，并拒绝了我们的应用程序来保存下一个缓存键。 所有缓存已开始仅存储在 MySQL 服务器上，这导致大量的开销。 + +* **制作详细的日志**-在日志行中没有太多信息，您将无法快速调试问题所在。 在一种情况下，由于缺乏单一信息，我们无法找到导致问题的原因，因此不得不等待其他问题的发生（在添加了丢失数据的日志之后）。 + +* **使用复杂的框架并不会自动意味着“降低网站速度”** -有些人感到惊讶的是，使用全栈框架可以每秒处理如此多的请求。 一切都与智能使用您拥有的工具有关–您甚至可以在 Node.js 中使其运行缓慢：-)选择一种提供良好开发环境的技术，没有人愿意为不友好的工具而烦恼（降低 devops 的士气！）。 + +## 谁在应用程序背后 + +该平台由波兰软件公司 [Octivi](http://octivi.com/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 设计。 我们专注于构建注重高性能和可用性的可扩展架构。 我们还要感谢与 IT 部门在客户端方面的大力合作！ + +# 相关文章 + +* [使用 Symfony2](http://labs.octivi.com/handling-1-billion-requests-a-week-with-symfony2/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 一周处理 10 亿个请求-我们整个应用程序的概述 + +* [将其推向极限-满足高性能需求的 Symfony2](http://symfony.com/blog/push-it-to-the-limits-symfony2-for-high-performance-needs) -描述了具有 Symfony2 功能的软件体系结构的详细信息 + +标题是； + +“使用 HAProxy，PHP，Redis 和 MySQL 构建增长的启动体系结构的简便方法，每周可处理 10 亿个请求” + +在文章中描述了 Varnish 的用法。 我认为标题需要更新。 + +为什么只有一台 Haproxy 服务器？ 您正在为应用程序节点使用 N + 1，但是前面只有一个负载均衡器吗？ 如果此关键服务器出现故障，将会发生什么？ + +那么“平均响应时间-30 毫秒”呢？该统计数据是在清漆前面或没有清漆的情况下计算的？ + +马丁 + +谁能回答这些初学者的问题？ + +1）由于 Redis 都在内存中，所以我假设持久保存数据以防两个 Redis 节点都掉下来是 MySQL 的工作吗？ + +2）如果要使该系统更大，更可扩展，是否会引入消息队列？ + +3）您是否具有到两个 Mysql 实例以及将来的分片 Redis 节点的单独数据库连接池？ + +1\. Redis 可以将数据持久保存到磁盘。 它只是不能增长到大于 memory_size +2。如果它需要在请求之外做一些事情而不是 +3.不知道。 + +在“ MySQL 的高可用性”中，我不明白您为什么使用 HAProxy，仅 Keepalived 可以解决问题（主动-被动和热备用）。 有什么原因吗？ + +Kakwa：HAProxy 允许以下几项： +1\. MySQL 处于主动-主动模式，不仅是主动-被动模式（也可以使用 keepalived 和多个浮动 IP） +2\. HAProxy 之后的 MySQL 服务器权重（服务器不支持） （必须具有相同的硬件） +3.使用“ mysql-check”就可以更轻松地切换到维护模式 + +@Al： +1-Redis 提供可配置的将数据推送到磁盘。 因此，如果 Redis 发生故障，那么它将与 MISS 缓存和 MySQL 的工作相同，是的。 +2-我认为是正确的，甚至他们实际上正在使用消息/作业队列，但在本文中未提及 +3-不知道：) + +伟大的 AI 问题！ + +1）不，Redis 可提供存储数据的完全持久性。 您可以在两种模式下进行设置： +RDB-在配置的时间范围内将整个键空间转储到一个文件中 +AOF-将每个“查询”保存到文件中 +我们正在使用 RDB，但是您可以使用两种模式 与此同时。 + +2）当然！ 在 Canhnm 之后，的确，我们在 Redis 之上建立了一些队列，因为它为此类事情提供了专用的数据结构。 我们将消息传递用于最耗时的任务。 + +3）不 + +嗨，这真的很有趣，谢谢！ 但这只是架构的一部分：提供 JSON 响应的后端服务。 应用程序如何处理该数据并将其提供给最终用户？ 是否有 JS 框架或另一个 PHP 应用程序层？ 谢谢！ + +几乎找不到您所有的图像 404 :( + +您正在使用哪个 PHP 的 Redis 扩展在 PHP 网站中实现 [redis 缓存？ 我知道两个扩展：Predis 和 PHPRedis。 以我的经验，在启用了 varnish 和 memcached 的同一台服务器上，事实证明 Predis 真的很容易配置，并且比 PHPRedis 提供更好的性能。](https://www.cloudways.com/blog/redis-cache-with-custom-php/) \ No newline at end of file diff --git a/docs/149.md b/docs/149.md index a5ee855..cce273b 100644 --- a/docs/149.md +++ b/docs/149.md @@ -1,93 +1,140 @@ -# Cinchcast 体系结构-每天产生 1,500 小时的音频 +# MixRadio 体系结构-兼顾各种服务 -> 原文： [http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html](http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html) +> 原文： [http://highscalability.com/blog/2014/8/25/mixradio-architecture-playing-with-an-eclectic-mix-of-servic.html](http://highscalability.com/blog/2014/8/25/mixradio-architecture-playing-with-an-eclectic-mix-of-servic.html) -![](img/133810bdcaf72132b08eba8a2df17f5d.png) +![](img/b715dfb0071d9887a35ee1ed3a975e2d.png) -*这是 [Aleksandr Yampolskiy 博士](http://www.twitter.com/ayampolskiy)， [Cinchcast](http://www.cinchcast.com/) 和 [BlogTalkRadio](http://www.blogtalkradio.com/) 的 CTO 的嘉宾帖子，他负责工程，质量检查，TechOps，电话和 产品团队。* +*这是 [MixRadio](https://twitter.com/sr_gb) 的首席架构师 Steve Robbins 的来宾[重新发布](http://dev.mixrad.io/blog/2014/08/22/MixRadio-Architecture-Overview/)。* -[Cinchcast](http://www.cinchcast.com) 提供的解决方案使公司能够创建，共享，衡量和货币化音频内容，以吸引和吸引对其业务最重要的人们。 我们的技术将会议桥与实时音频流集成在一起，以简化在线事件并增强与会人员的参与度。 Cinchcast 技术还用于为全球最大的音频社交网络 [Blogtalkradio](http://www.blogtalkradio.com) 提供动力。 今天，我们的平台每天制作和分发超过 1500 小时的原始内容。 在本文中，我们描述了为了扩展平台以支持这种数据规模而做出的工程决策。 +At MixRadio, we offer a free music streaming service that learns from listening habits to deliver people a personalised radio station, at the single touch of a button. MixRadio marries simplicity with an incredible level of personalization, for a mobile-first approach that will help everybody, not just the avid music fan, enjoy and discover new music. It's as easy as turning on the radio, but you're in control - just one touch of Play Me provides people with their own personal radio station.The service also offers hundreds of hand-crafted expert and celebrity mixes categorised by genre and mood for each region. You can also create your own artist mix and mixes can be saved for offline listening during times without signal such as underground travel, as well as reducing data use and costs.Our apps are currently available on Windows Phone, Windows 8, Nokia Asha phones and the web. We’ve spent years evolving a back-end that we’re incredibly proud of, despite being British! Here's an overview of our back-end architecture. -## 统计信息 +# 架构概述 -* 每月浏览量超过 5000 万 -* 已创建 50,000 小时的音频内容 -* 15,000,000 个媒体流 -* 175,000,000 次广告展示 -* 每秒 40,000 个并发请求的峰值速率 -* MSSQL，Redis 和 ElasticSearch 群集中每天存储的数据量为 TB /天 -* 由 10 位工程师组成的团队（在 20 位技术人员中）。 -* 大约有 100 个硬件节点正在生产中。 +我们有机会在 2009 年重新设计后端。今天，我们的后端核心是 RESTful 服务的集合，其模式称为['微服务'](http://martinfowler.com/articles/microservices.html)。 这些服务的大小，功能，开发语言和数据存储各不相同，但都具有共同的属性，例如公开定义良好的 RESTful API，可独立扩展的功能（包括监视功能），我们将在下面介绍更多功能。 围绕这些核心服务，我们有两个类似的代理服务，它们是通过配置驱动的，以公开用于不同目的的 RESTful 资源的子集。 “内部工具 API”代理内部 API 的工具，以涵盖客户服务，内容管理，发布组合，监控和许多其他情况。 在公开场合，我们通过“外部 API 身份验证层”服务公开了针对客户端应用和第三方开发人员的 RESTful API。 此服务还具有执行适当的权限和授权方案的工作，例如 [OAuth2](http://en.wikipedia.org/wiki/OAuth) 。 -## 数据中心 +对于最终用户，我们的 API 服务的应用范围非常广泛。 我们提供 [HTML5 网站](http://www.mixrad.io/)，适用于所有不同类型诺基亚手机的设备应用程序，Windows 8 应用程序，并且我们还向第三方开发人员提供了相同 API 的子集。 我不会在本文中详细介绍我们的应用架构，因为我们团队的内森（Nathan）先前曾写过[。](http://dev.mixrad.io/blog/2014/02/24/Bringing-MixRadio-to-the-new-Nokia-X-family/) -* 生产网站是从布鲁克林的数据中心运行的。 我们喜欢控制自己的命运，而不是将数据委托给云。 -* Amazon EC2 实例主要用于质量检查和登台环境。 +下图概述了系统的主要领域，其中驻留了五十多个微服务： -## 硬件 +![](img/a64ef4f603f8083cf2ca61e79a344875.png) -* 大约 50 台 Web 服务器 -* 15 个 MS SQL 数据库服务器 -* 2 个 Redis NOSQL 键值服务器 -* 2 个 NodeJS 服务器 -* 2 个用于弹性搜索集群的服务器 +# 使用的技术 -### 开发工具 +我们采取务实的方法，即针对开源技术使用正确的工具来完成这项工作。 目前，我们正在积极使用： -* .NET 4 C＃：ASP.NET 和 MVC3 -* Visual Studio 2010 Team Suite 作为 IDE -* StyleCop，用于加强代码标准的 Res​​harper -* 敏捷开发方法，Scrum 用于大型功能，看板任务板用于较小的任务 -* Jenkins + Nunit 用于测试和持续集成 -* 按需调味–自动化测试用硒 +## 语言能力 -## 使用的软件和技术 +* [Clojure](http://clojure.org/) 用于我们的微服务。 +* C＃用于我们的设备应用程序和媒体交付服务。 +* HTML5 / CSS / JavaScript 用于我们的网络体验。 -* **Windows Server 2008 R2 x64** ：操作系统 -* **SQL Server 2005** 在 **Microsoft Windows Server 下运行 2008 年** Web 服务器 -* **均衡器负载均衡器** ：用于负载均衡 -* **REDIS** ：用作分布式缓存层并用于消息发布-子队列 -* **NODEJS** **用于实时分析和更新 Studio 仪表板** -* **ElasticSearch** ：用于节目搜索 -* **Sawmill +自定义解析器脚本：** 用于日志分析 +## 存储 -## 监控 +* [MySQL](http://www.mysql.com/) +* [Solr](http://lucene.apache.org/solr/) +* [MongoDB](http://www.mongodb.org/) +* [Redis](http://redis.io/) +* [Elasticsearch](http://www.elasticsearch.org/) +* [ZooKeeper](http://zookeeper.apache.org/) +* [SQLServer](http://www.microsoft.com/sqlserver) -* **NewRelic** 用于性能监控 -* **Chartbeat** 对性能对 KPI（转化，页面浏览）的影响 -* **Gomez，WhatsupGold 和 Nagios 提供各种警报功能** -* **SQL Monitor：** 来自 Red Gate-用于 SQL Server 监视 +## 基础设施 -## 我们的方法 +* [适用于 Linux 微服务的 AWS](https://aws.amazon.com/) 。 +* [Azure](http://azure.microsoft.com/) 用于 Windows 和媒体存储上运行的媒体服务。 +* [GitHub Enterprise](https://enterprise.github.com/) 用于源代码控制。 +* [Packer](http://www.packer.io/) 用于创建机器映像。 +* [人偶](http://puppetlabs.com/)，用于调配和检查机器映像。 -* “简短，聪明，消失”：尊重他人的时间。 不要有问题，要有解决方案。 -* 不要去追逐当今的热门技术。 而是“缓解您的主要问题”。 我们采用新技术，但是在业务案例需要时采用新技术。 当您有数百万个用户时，生产中断的需求就会大大降低。 -* 达到“基本”，然后担心“优秀”。 -* 成为“如何团队”而不是“没有团队”。 -* 将安全性纳入软件开发生命周期。 您需要培训开发人员如何编写安全软件，并使之从一开始就成为企业的优先事项。 +## 监控方式 -## 架构 +* [Nagios](http://www.nagios.org/) +* [石墨](http://graphite.wikidot.com/) +* [Tasseo](https://github.com/obfuscurity/tasseo) +* [塞伦](https://github.com/scobal/seyren) +* [篝火](https://campfirenow.com/) +* [PagerDuty](http://www.pagerduty.com/) +* [主题演讲](http://www.keynote.com/) +* [Logstash](http://logstash.net/) +* [Kibana](http://www.elasticsearch.org/overview/kibana/) -* 所有 Javascript，CSS 和图像都缓存在 CDN 级别。 DNS 指向将请求传递到原始服务器的 CDN。 我们使用 Cotendo 是因为它允许在 CDN 上做出 L7 路由决策。 -* Web 服务器的单独群集用于为常规用户和广告用户提供服务，以 Cookie 区分。 -* 我们正在朝着面向服务的体系结构发展，该体系的关键部分（例如搜索，身份验证，缓存）是以各种语言实现的 RESTFUL 服务。 这些服务还提供了一个缓存层。 -* REDIS NOSQL 键值存储（redis.io）用作数据库调用之前的缓存层。 -* 横向扩展用于在整个 Web 服务器花园中维护会话状态。 但是，我们正在考虑切换到 REDIS。 +# 建筑原理 -![](img/ed592e2401d3b5991b70f1e4330edc7d.png) +为了使 API 与五十多种微服务保持一致，我们制定了有关 URI 结构，分页，排序，大小写，处理语言代码等方面的标准； 但是在开放的文化中，我们通常使用原则而不是硬性规则来获得一致性。 我们的服务应： -## 获得的经验教训 +* 松散耦合，无状态，并通过 HTTP 提供 JSON 的 RESTful 接口。 +* 单独部署并拥有自己的数据，即其他服务通过 API（而不是数据库连接）访问数据。 这允许单独的规模以及持久性技术和数据结构的更改。 +* 当我们为每个服务使用一个机器实例时，它既不会太大以致于变得笨拙，又不会太小而使其浪费计算资源。 +* 实施用于检查的 Healthcheck API，并负责确定健康状况。 +* 永远不要破坏他们的消费者。 我们很早就同意一个标准，在资源路径中有一个版本号（例如`/1.x/products/12345/`），这样如果需要进行重大更改，则可以并行部署新版本并被上游消费者采用 。 即使我们仍然保留此功能，多年来也不需要使用它。 -* **无法在 SQL Server 数据库中搜索文本**。 它阻塞了 CPU，所以我们切换到 ElasticSearch（Lucene 派生的）。 -* **Microsoft 的内置会话模块容易出现死锁**，因此我们最终将其替换为 AngiesList 会话模块，并将数据存储到 REDIS。 -* **日志记录是检测问题的关键。** -* **重塑车轮可能是一件好事**。 例如，最初我们使用供应商产品将 JS / CSS 捆绑在一起，这开始导致性能问题。 然后，我们重新编写了捆绑包，并显着提高了我们网站的性能。 -* **并非所有数据都是相关的**，所以数据库并不总是一个好的媒介。 一个很好的类比是“假设您有水顺着管道流下。 管道的顶部较宽，而底部则较窄。” 顶部是 Web 服务器（其中有很多），底部是数据库（很少，并且被阻塞了）。 -* **在开发过程中不使用指标就像试图在高度计不起作用的情况下将飞机降落在风暴中**。 在整个开发过程中，计算指标，例如站点吞吐量，修复 Blocker /关键 bug 的时间，代码覆盖率，并使用它们来衡量性能。 +除了这些内部原则外，对于面向公众的 API，我们还添加了以下内容： -感谢您的有趣帖子。 您如何处理 sql 数据库的复制？ 谢谢！ +* API 已针对移动设备进行了优化：我们使用 JSON，因为与低功耗设备上的 XML 相比，它解析所需的内存要少于 XML，并尽可能使用 GZIP 编码响应，最重要的是-如果不需要数据，则不会返回。 最后一点是与 API 一致性的良好平衡。 +* 尽可能使用缓存； API 返回适当的缓存头，以便将内容缓存在最终用户设备和浏览器以及[内容分发网络（CDN）](http://en.wikipedia.org/wiki/Content_delivery_network)上，从而首先使内容更接近我们的消费者。 +* 云中会保留尽可能多的逻辑和数据真实性，以减少应用程序中逻辑的重复并提供一致的体验。 +* 相同的 API 用于所有客户端-网络，移动，桌面和第三方子集。 但是，为了针对不同的屏幕尺寸和要求进行优化，我们使用了一些技巧。 一个明显的例子是“ itemsperpage” querystring 参数，用于调整返回的内容数量。 另一个适用于 RESTful API 设计，其中资源返回隔离的内容。 我们经常将内容分组为所谓的“视图”，以减少所需的请求数量。 -有趣的 -您模型的“关系”部分是什么？ +使用视图 API 的一个示例是我们应用程序中的艺术家详细信息页面，该页面包含来自许多资源的数据-艺术家传记，图像，推文，演出，并混合了其中的专辑，热门专辑，热门歌曲和类似歌手。 通过将其组合成一个“视图”，应用程序可以一击即获得约 5KB 的数据。 -将记录保留在 Disc 阵列中并在 DB 中保留位置不是一个更好的设计。 另外，您也不要在 CDN 服务器上复制脱机内容。 只是好奇 \ No newline at end of file +# 快速微服务 + +在过去的几年中，我们已经在 [Clojure](http://clojure.org/) 而非 Java 中构建了微服务。 Clojure 是一种动态语言，仍然可以在 Java 虚拟机（JVM）上运行，并且还允许访问 Java 框架。 我们的后端团队出于开发速度和运行时的速度选择使用 Clojure。 Clojure 比 Java 简明得多-例如，这是我们在 Clojure 中重新开发的 Java 服务之一，其代码行数从 44,000 行增加到 4,000 行（包括所有配置，测试和其他工件）。 我们使用 [Leiningen](http://leiningen.org/) 来加快开发速度-Leiningen 提供的一个方面是自定义项目模板，我们有一个名为`cljskel`的模板为我们创建框架服务。 我们打算在以后的帖子中再次使用该模板，但是为了说明使用，我们能够运行以下命令，并具有带有监控 API 的功能性 RESTful 服务： + +``` +lein new cljskel +``` + +如果您对我们如何进入 Clojure 感兴趣，您可能想观看我们两位工程师去年在伦敦所做的演讲。 + +# 数据 + +我们处理的两个最大数据源是我们拥有的 32+百万首曲目的内容元数据（以及相关的艺术家，专辑，混音等）以及来自我们的应用程序的分析数据，例如播放事件，大拇指向上/向下 和导航事件。 + +Catalog 服务（请参见下图）为我们的消费者体验提供内容元数据和搜索功能。 “主目录”服务存储来自各种来源的原始数据，例如记录标签，我们的内部内容团队和互联网资源（例如 Wikipedia）。 配置驱动的数据模型指定了如何合并来源（例如，优先考虑从我们的内容团队得到更正的某些字段，而不是其他来源），哪些字段可搜索以及哪些字段返回给调用者。 我们可以返回不同的字段来满足不同的用例。 例如，我们不需要搜索结果中的专辑曲目列表，但在显示专辑详细信息时确实需要它们。 主目录服务不会直接为用户流量提供服务，而是“搜索和查询” API 是其余后端的接口。 搜索和查询服务基于 [Apache Solr](http://lucene.apache.org/solr/) 构建，“索引后台程序”服务对主目录进行爬网以获取发布到 Solr 搜索索引的更新。 + +[![](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/catalogue.png)](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/catalogue.png) + +收集分析和使用数据对于驱动个性化体验，进行 A / B 测试，CRM，计算业务指标和合同报告至关重要。 随着数据全天不断地从各种应用程序进入后端，许多服务需要同时访问同一数据。 一个例子是用户在曲目上按下了“ thumbs down”按钮，这对于当前播放曲目的混合很重要*和*到用户的整体口味，重复的拇指 下降表示不喜欢艺术家。 为了能够处理我们期望的数据量，去年初我们决定需要一个发布-订阅模型，该模型将： + +* 高可用性，无单点故障。 +* 通过解耦和暂停传入消息的能力为整个系统提供可伸缩性。 +* 与消息格式无关。 +* 写延迟低（即“即发即弃”的语义）。 +* 为订户提供快速吞吐量。 +* 提供简单的发布和订阅 API。 +* 支持多个用户使用相同的数据，每个用户可能具有不同的体系结构，并以不同的速度和时间表运行。 例子是实时处理与批处理聚合或归档。 + +我们从 LinkedIn 选择了 [Apache Kafka](http://kafka.apache.org/documentation.html#introduction) ，因为它非常适合我们的需求。 特别是它是一个持久的消息传递系统，旨在支持许多具有自己状态（例如读取数据的位置）的消费者，而不是假设订户永久存在并以相同速率消费数据。 + +# 监控方式 + +我们针对关键用例的<延迟时间为 0.8 秒，在为期 90 天的滚动期内达到 99.99％的可用性-相当于每月停机 4.3 分钟。 因此，当出现问题时，我们如何知道何时出现问题并迅速做出反应？ 我们具有多层监视功能，可以提醒开发人员和操作工程师。 + +在最低级别上，我们使用 [Nagios](http://www.nagios.org/) 检查虚拟机的基本运行状况，并使用 [PagerDuty](http://www.pagerduty.com/) 来提醒运维工程师。 我们利用每个微服务实现的运行状况检查 API，让 AWS 负载均衡器确定盒子是否需要回收（您可以在此[上一篇文章](http://dev.mixrad.io/blog/2014/05/16/How-we-use-cluppet/)中阅读有关如何配置 AWS 负载均衡器的更多信息）。 [石墨](http://graphite.wikidot.com/)用于收集操作系统级别的指标，例如 CPU 使用率，磁盘空间等。但是，每个微服务也记录自定义指标，这对所涉及的工程师很有帮助。 我们收集的服务指标从低级项目（例如 HTTP 500 错误计数）到高级抽象（激活的订阅数），不计其数。 这是一个石墨仪表板示例： + +[![](img/bc1240be40ba1da5b232e050e5180017.png) ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-graphite.png) + +我们在 Graphite 顶部使用 [Tasseo](https://github.com/obfuscurity/tasseo) 提供漂亮的仪表板数据摘要视图，并使用 [Seyren](https://github.com/scobal/seyren) 根据阈值变化发出警报。 Seyren 由我们的一些工程师创立，并在一篇有关 [2012 年奥巴马连任竞选](http://arstechnica.com/information-technology/2012/11/how-team-obamas-tech-efficiency-left-romney-it-in-dust/)中使用的技术的文章中得到提及。 + +[![](img/6c0a928dace7db3e5f427535cb762426.png) ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-seyren.png) + +在最高级别上，我们使用[主题演讲](http://www.keynote.com/)来监控全球的用例和响应时间： + +[![](img/83227356cbfcd6cf1bd280078debc881.png) ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-keynote.png) + +最后，对于详细的诊断，我们避免了必须通过日志传送连接到特定服务器。 我们使用 [Logstash](http://logstash.net/) 将系统，请求，错误和特定于应用程序的日志收集到中央位置，并与自定义仪表板一起使用 [Kibana](http://www.elasticsearch.org/overview/kibana/) 来跟踪特定的错误或查看趋势。 该示例是几年前我们试图减少应用程序错误噪声时的自定义仪表板： + +[![](img/fb06a3e22974f5a6b53ae1162bcba2ec.png) ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-errors.png) + +# 持续交付 + +连续交付是一种通过自动化部署和测试以可重复的方式快速发布软件的实践。 从大爆炸发布开始，我们花费了数年的时间来改进我们的流程； 迁移到部署管道，然后使用 AWS 中的 Netflix“红/黑”样式模型迁移到今天的状态。 我们工程团队的 Joe 在 6 月的[伦敦持续交付聚会](http://vimeo.com/100788786)上谈到了这一点。 + +通过查看过去五年中完成的部署次数，可以了解我们的进展情况： + +![](img/c501f46a3ef3035f7bed9683c4ed53b5.png) + +## 相关文章 + +* [MixRadio 历史记录](http://dev.mixrad.io/blog/2014/08/05/MixRadio-History/) \ No newline at end of file diff --git a/docs/15.md b/docs/15.md index 0df947b..49b1834 100644 --- a/docs/15.md +++ b/docs/15.md @@ -1,287 +1,80 @@ -# Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入 +# 扩大早期创业规模 -> 原文： [http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) +> 原文： [http://highscalability.com/blog/2007/10/28/scaling-early-stage-startups.html](http://highscalability.com/blog/2007/10/28/scaling-early-stage-startups.html) -![](img/40038672dfc38e0094e8da51e713355b.png) +[的 Mark Maunder 不需要 VC](http://novcrequired.com) -倡导不收取 VC 资金，以免您变成青蛙，而不是您梦 dream 以求的王子（或公主）–具有出色的[滑盖[](http://novcrequired.com/scalingEarly.ppt) ，了解如何扩展早期启动。 他的博客还提供了一些不错的 SEO 技巧和一个非常怪异的小部件，显示了读者的地理位置。 完美的万圣节！ 马克对创业公司的其他世俗化扩张策略是什么？ -如果您是 Uber，并且需要存储驾驶员和驾驶员应用程序每 30 秒发送一次的位置数据，该怎么办？ 大量实时数据需要实时使用。 +网站：http：//novcrequired.com/ -Uber 的解决方案是全面的。 他们构建了自己的系统，该系统在 Mesos 之上运行 Cassandra。 Uber 的软件工程师 [Abhishek Verma](https://www.linkedin.com/in/verma7) 在一个很好的演讲中都进行了解释： [Cassandra 在跨多个数据中心的 Mesos 上 Uber](https://www.youtube.com/watch?v=4Ap-1VT2ChU&feature=youtu.be) （ [幻灯片](http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016) ）。 +## 信息来源 -您也应该这样做吗？ 在听 Abhishek 的演讲时，会想到一个有趣的想法。 +* [西雅图技术启动对话](http://novcrequired.com/scalingEarly.ppt)的幻灯片。* [扩展早期创业[Mark Marker]的博客文章](http://novcrequired.com/2007/scaling-early-stage-startups/)。 -这些天来，开发人员有很多艰难的选择。 我们应该全力以赴吗？ 哪一个？ 太贵了吗？ 我们担心锁定吗？ 还是我们应该尝试同时兼顾并打造混合架构？ 还是我们应该自己做所有事情，以免由于未达到 [50％](http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/) 毛利率而被董事会蒙羞？ + ## 该平台 -Uber 决定建立自己的公司。 或者更确切地说，他们决定将两个功能强大的开源组件融合在一起，从而将自己的系统焊接在一起。 所需要的是一种使 Cassandra 和 Mesos 协同工作的方法，而这正是 Uber 的基础。 + * Linxux* ISAM 类型数据存储。* 佩尔* [Httperf](http://www.hpl.hp.com/research/linux/httperf) 用于基准测试。* [Websitepulse.com](http://websitepulse.com/) 用于性能监控。 -对于 Uber 的决定并不那么困难。 他们资金充裕，可以访问创建，维护和更新这类复杂系统所需的顶尖人才和资源。 + ## 架构 -由于 Uber 的目标是使所有人在任何地方的运输都具有 99.99％的可用性，因此在扩展到无限远及更高水平时，希望能够控制您的成本确实很有意义。 + * 性能很重要，因为速度过慢可能会浪费您 20％的收入。 UIE 的人不同意这不一定。 他们在[可用性工具播客：页面下载时间的真相](http://www.uie.com/brainsparks/2007/09/24/usability-tools-podcast-the-truth-about-page-download-time/)中解释了其原因。 这个想法是：“我们的研究还有另一个令人惊讶的发现：下载时间与用户是否在网站上成功完成任务之间存在很强的相关性。但是，实际下载时间与任务成功之间没有相关性，这导致我们 放弃我们最初的假设。似乎，当人们完成了他们打算在某个网站上进行的工作时，他们会认为该网站是快速的。” 因此，最好将时间用于改进前端而不是后端。 -但是，当您听演讲时，您会意识到制作此类系统所付出的巨大努力。 这真的是您的普通商店可以做的事情吗？ 不，不是。 如果您是那些希望每个人都在裸露的金属之上构建自己的所有代码的云专家之一，请记住这一点。 + * MySQL 因性能问题而被弃用：MySQL 无法处理大型表上的大量写入和删除操作，写入操作浪费了查询缓存，不完全支持大量小表（超过 10,000 个），使用了大量内存 高速缓存索引，以每秒 200 个并发读/写查询的最大速度，记录超过 100 万条记录。 -以金钱换时间通常很划算。 通常，以技能交易金钱是绝对必要的。 + * 对于数据存储，它们演变成固定长度的 ISAM 样记录方案，允许直接查找数据。 仍然使用文件级锁定，其基准测试为 20,000 多个并发读取/写入/删除。 考虑使用性能非常好并且被许多大型网站使用的 BerkelyDB，尤其是当您主要需要键值类型查询时。 我认为，如果很多数据最终显示在网页上，则存储 json 可能会很有趣。 -鉴于 Uber 的可靠性目标，即 10,000 个请求中只有一个可能失败，因此他们需要在多个数据中心中用完。 由于事实证明 Cassandra 可以处理巨大的负载并且可以跨数据中心工作，因此将其作为数据库选择是有意义的。 + * 已移至 httpd.prefork for Perl。 在应用程序服务器上没有 keepalive 的服务器使用更少的 RAM，并且运行良好。 -如果您想使所有人，任何地方的运输都可靠，则需要有效地利用您的资源。 这就是使用像 Mesos 这样的数据中心操作系统的想法。 通过在同一台计算机上统计复用服务，您需要的计算机数量减少了 30％，从而节省了资金。 之所以选择 Mesos，是因为当时 Mesos 是经证明可与数以万计的计算机集群大小一起工作的唯一产品，这是 Uber 的要求。 优步的工作量很大。 + ## 得到教训 -有哪些更有趣的发现？ + * 正确配置数据库和 Web 服务器。 MySQL 和 Apache 的内存使用很容易失控，随着交换的增加，导致网格性能缓慢下降。 以下是一些有助于解决[配置问题](http://www.possibility.com/epowiki/Wiki.jsp?page=VpsConfiguration)的资源。 -* 您可以在容器中运行有状态服务。 Uber 发现，在裸机上运行 Cassandra 与在 Mesos 管理的容器中运行 Cassandra 之间几乎没有任何区别，开销为 5-10％。 + * 只服务您关心的用户。 阻止使用大量有价值的资源免费爬行您网站的内容主题。 监视他们每分钟获取的内容页面的数量。 如果超过阈值，然后对它们的 IP 地址进行反向查找并配置防火墙以阻止它们。 -* 性能良好：平均读取延迟：13 毫秒，写入延迟：25 毫秒，P99 看起来不错。 + * 尽可能多地缓存数据库数据和静态内容。 Perl 的 Cache :: FileCache 用于在磁盘上缓存数据库数据和呈现的 HTML。 -* 对于最大的群集，他们能够支持超过一百万次写入/秒和约 10 万次读取/秒。 + * 在 URL 中使用两个不同的主机名，以使浏览器客户端可以并行加载图像。 -* 敏捷性比性能更重要。 通过这种架构，Uber 获得的就是敏捷性。 跨集群创建和运行工作负载非常容易。 + * 使内容尽可能静态创建单独的 Image 和 CSS 服务器以提供静态内容。 对静态内容使用 keepalive，因为静态内容每个线程/进程占用的内存很少。 -这是我的演讲要点： + * 留下大量的备用内存。 备用内存允许 Linux 在文件系统缓存之前使用更多内存，从而使性能提高了约 20％。 -## 开头 + * 关闭动态内容的 Keepalive。 增加的 http 请求可能会耗尽为它们服务所需的线程和内存资源。 -* 跨不同服务的静态分区机器。 + * 您可能不需要复杂的 RDBMS 来访问数据。 考虑一个重量更轻的数据库 BerkelyDB。 -* 50 台机器可能专用于 API，50 台机器专用于存储，等等，并且它们没有重叠。 +“它们演变为固定长度的 ISAM（如记录方案）”-我不清楚，这是哪个应用程序？ 他们不再使用 BerkleyDB，而不再使用 MySQL，他们说他们正在使用什么吗？ -## 即时 +[http://www.callum-macdonald.com/“]( Callum -* 希望在 [Mesos](http://mesos.apache.org/) 上运行所有内容，包括诸如 Cassandra 和 Kafka 之类的有状态服务。 +嗨，卡勒姆， - * Mesos 是数据中心操作系统，可让您像单一资源池一样针对数据中心进行编程。 +我收到了托德发来的关于您问题的电子邮件。 :) - * 当时，事实证明 Mesos 可以在成千上万的计算机上运行，​​这是 Uber 的要求之一，因此这就是他们选择 Mesos 的原因。 今天，Kubernetes 可能也可以工作。 +我们从头开始构建了自己的快速文件存储例程。 它宽松地基于 ISAM 或 MySQL 的 MyISAM，因为它使用固定长度的顺序记录。 对于我们需要的某些特定操作，它要快得多。 不幸的是，目前它还不是开源的，但也许我们会在将来发布它。 - * Uber 在 MySQL 之上构建了自己的分片数据库，称为 [Schemaless](https://eng.uber.com/schemaless-part-one/) 。 这个想法是 Cassandra 和 Schemaless 将成为 Uber 中的两个数据存储选项。 现有的 Riak 装置将移至 Cassandra。 +问候， -* 一台机器可以运行各种服务。 +Mark Maunder +FEEDJIT 创始人& CEO -* 同一台机器上的统计复用服务可能会导致 的机器数量减少 30％ 。 这是 Google 在 Borg 上运行的 [实验](http://research.google.com/pubs/pub43438.html) 的发现。 +他在幻灯片“幻灯片”中谈到 MySQL，“ MySQL 不支持大量小表（超过 10,000 个）。” -* 例如，如果一项服务使用大量 CPU，并且与使用大量存储或内存的服务非常匹配，那么这两项服务可以在同一服务器上有效运行。 机器利用率上升。 +为什么地球上会有超过 10,000 张桌子？ 这听起来像是糟糕的设计。 -* Uber 现在有大约 20 个 Cassandra 集群，并计划在将来有 100 个。 +@Dimitri：加入有点晚，但是为了回答您的问题，使用多个小表而不是一个大表可以更有效地解决某些情况。 -* 敏捷性比性能更重要。 您需要能够管理这些集群并以平滑的方式对其执行不同的操作。 +一个典型的例子是 WordPress 多用户（ [http://mu.wordpress.org/faq/）](http://mu.wordpress.org/faq/))为每个博客创建表。 -* **为什么在容器中而不是在整个机器上运行 Cassandra？** +以防万一您不想点击链接:-) - * 您想存储数百 GB 的数据，但您还希望将其复制到多台计算机上以及跨数据中心。 +*WordPress MU 为每个博客创建表，这是我们发现的系统，在经过大量测试，反复试验后，对于插件的兼容性和扩展性而言，其工作效果最佳。 这利用了现有的 OS 级和 MySQL 查询缓存，还使分割用户数据变得更加容易，这是超出单个功能范围的所有服务最终都必须要做的。 我们是实际的人，所以我们将使用最有效的方法，对于 WordPress.com 上的 2.3m 数据，MU 一直是冠军。* - * 您还希望跨不同群集进行资源隔离和性能隔离。 +We built our own fast file storage routines from the ground up. It's loosely based on ISAM or MySQL's MyISAM in that it uses fixed length sequential records. It's a lot faster for certain specific operations that we require. Unfortunately it's not open source at this time but perhaps we'll release it in future. - * 很难在一个共享群集中获得所有这些。 例如，如果您制作了一个 1000 节点的 Cassandra 群集，它将无法扩展，或者跨不同群集也会产生性能干扰。 +初学者的好起点 +----- +[http://underwaterseaplants.awardspace.com“](海洋植物 +[http：//underwaterseaplants.awardspace .com / seagrapes.htm“](海葡萄... [http://underwaterseaplants.awardspace.com/plantroots.htm”](植物根 -## 量产中 - -* 在两个数据中心（西海岸和东海岸）中复制约 20 个群集 - -* 最初有 4 个集群，包括中国，但由于与滴滴合并，这些集群被关闭了。 - -* 跨两个数据中心的 300 台机器 - -* 最大的 2 个集群：每秒超过 100 万次写入和每秒 10 万次读取 - - * 群集之一正在存储驾驶员和骑乘者应用程序每 30 秒发送一次的位置。 - -* 平均读取延迟：13 毫秒，写入延迟：25 毫秒 - -* 通常使用 [LOCAL_QUORUM](https://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html) 一致性级别（表示强一致性） - -## 月背景资料 - -* Mesos 将 CPU，内存和存储从计算机中分离出来。 - -* 您不是在查看单个计算机，而是在查看资源并对其进行编程。 - -* 线性可伸缩性。 可以在数以万计的计算机上运行。 - -* 高度可用。 Zookeeper 用于在可配置数量的副本中进行领导者选举。 - -* 可以启动 Docker 容器或 Mesos 容器。 - -* 可插拔资源隔离。 用于 Linux 的 Cgroups 内存和 CPU 隔离器。 有一个 Posix 隔离器。 不同的操作系统有不同的隔离机制。 - -* 两级调度程序。 来自 Mesos 代理的资源被提供给不同的框架。 框架在这些提议的基础上安排自己的任务。 - -## Apache Cassandra Backgrounder - -* Cassandra 非常适合 Uber 的用例。 - -* 水平可扩展。 随着新节点的添加，读写规模呈线性增长。 - -* 高度可用。 具有可调一致性级别的容错能力。 - -* 低延迟。 在同一数据中心内获得亚毫秒级的延迟。 - -* 操作简单。 这是同质的簇。 没有主人。 集群中没有特殊的节点。 - -* 足够丰富的数据模型。 它具有列，组合键，计数器，二级索引等 - -* 与开源软件的良好集成。 Hadoop，Spark，Hive 都具有与 Cassandra 进行通信的连接器。 - -## 中层+ Uber + Cassandra = dcos-cassandra-service - -* Uber 与 Mesosphere 合作生产了 [mesosphere / dcos-cassandra-service](https://github.com/mesosphere/dcos-cassandra-service) -一种自动化服务，可轻松在 Mesosphere DC /上进行部署和管理 操作系统。 - -![29683333130_0478a29f4f.jpg](img/838bef48b4379bab5211f9b9f159d7c8.png) - -* 顶部是 Web 界面或 Control Plane API。 您指定所需的节点数； 您想要多少个 CPU； 指定 Cassandra 配置； 然后将其提交给 Control Plane API。 - -* 使用 Uber 的部署系统，它在 [Aurora](http://aurora.apache.org/) 之上启动，用于运行无状态服务，用于引导 dcos-cassandra 服务框架。 - -* 在示例 dcos-cassandra-service 框架中有两个与 Mesos 主服务器通信的集群。 Uber 在其系统中使用了五个 Mesos 母版。 Zookeeper 用于领导者选举。 - -* Zookeeper 还用于存储框架元数据：正在运行的任务，Cassandra 配置，集群的运行状况等。 - -* Mesos 代理在群集中的每台计算机上运行。 代理将资源提供给 Mesos 主服务器，主服务器以离散报价分发它们。 报价可以被框架接受或拒绝。 多个 Cassandra 节点可以在同一台计算机上运行。 - -* 使用 Mesos 容器，而不是 Docker。 - - * 覆盖配置中的 5 个端口（storage_port，ssl_storage_port，native_transport_port，rpcs_port，jmx_port），因此可以在同一台计算机上运行多个容器。 - - * 使用永久卷，因此数据存储在沙箱目录外部。 万一 Cassandra 失败，数据仍将保留在持久卷中，如果崩溃并重新启动，则将数据提供给同一任务。 - - * 动态预留用于确保资源可用于重新启动失败的任务。 - -* Cassandra 服务操作 - - * Cassandra 有一个 [种子节点](https://www.quora.com/What-is-a-seed-node-in-Apache-Cassandra) 的想法，它为加入集群的新节点引导八卦过程。 创建了自定义 [种子提供程序](https://mesosphere.github.io/cassandra-mesos/docs/configuration-and-state.html) 来启动 Cassandra 节点，该节点允许 Cassandra 节点自动在 Mesos 群集中推出。 - - * 可以使用 REST 请求增加 Cassandra 群集中的节点数。 它将启动其他节点，为其提供种子节点，并引导其他 Cassandra 守护程序。 - - * 可以更改所有 Cassandra 配置参数。 - - * 使用 API​​可以替换死节点。 - - * 需要修复才能跨副本同步数据。 维修在每个节点的主键范围内进行。 这种方法不会影响性能。 - - * 清除将删除不需要的数据。 如果已添加节点，则数据将被移动到新节点，因此需要清理才能删除移动的数据。 - - * 可以通过框架配置多数据中心复制。 - -* 多数据中心支持 - - * 在每个数据中心中独立安装 Mesos。 - - * 在每个数据中心中设置框架的独立实例。 - - * 框架互相交谈并定期交换种子。 - - * 这就是 Cassandra 所需要的。 通过引导其他数据中心的种子，节点可以八卦拓扑并找出节点是什么。 - - * 数据中心之间的往返 ping 延迟为 77.8 ms。 - - * P50 的异步复制延迟：44.69 毫秒； P95：46.38ms; P99：47.44 毫秒； - -* 计划程序执行 - - * 调度程序的执行被抽象为计划，阶段和块。 调度计划具有不同的阶段，一个阶段具有多个块。 - - * 调度程序启动时要经过的第一阶段是协调。 它将发送给 Mesos 并找出已经在运行的内容。 - - * 有一个部署阶段，检查集群中是否已存在配置中的节点数，并在必要时进行部署。 - - * 块似乎是 Cassandra 节点规范。 - - * 还有其他阶段：备份，还原，清理和修复，具体取决于命中的 REST 端点。 - -* 集群可以每分钟一个新节点的速率启动。 - - * 希望每个节点的启动时间达到 30 /秒。 - - * 在 Cassandra 中不能同时启动多个节点。 - - * 通常给每个 Mesos 节点 2TB 的磁盘空间和 128GB 的 RAM。 每个容器分配 100GB，每个 Cassandra 进程分配 32GB 堆。 （注意：目前尚不清楚，因此可能有错误的细节） - - * 使用 G1 垃圾收集器代替 CMS，它具有更好的 99.9％延迟（16x）和性能，无需任何调整。 - -## 裸机 vs Mesos 托管群集 - -* 使用容器的性能开销是多少？ 裸机意味着 Cassandra 不在容器中运行。 - -* 读取延迟。 几乎没有什么区别：5-10％的开销。 - - * 在裸机上平均为 0.38 ms，而在 Mesos 上为.44 ms。 - - * 在 P99 上，裸机为.91 毫秒，在 Mesos 上，P99 为.98 毫秒。 - -* 读取吞吐量。 差别很小。 - -* 写入延迟。 - - * 在裸机上平均为 0.43 ms，而在 Mesos 上为.48 ms。 - - * 在 P99 上，裸机为 1.05 毫秒，在 Mesos 上，P99 为 1.26 毫秒。 - -* 写入吞吐量。 差别很小。 - -## 相关文章 - -* [关于 HackerNews](https://news.ycombinator.com/item?id=12600298) - -* [使用 Borg 在 Google 进行大规模集群管理](http://research.google.com/pubs/pub43438.html) - -* [Google 的三个时代-批处理，仓库，即时](http://highscalability.com/blog/2011/8/29/the-three-ages-of-google-batch-warehouse-instant.html) - -* [Google 延迟容忍系统：将不可预测的部分做成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) - -* [Google：驯服长时间延迟的尾巴-当更多机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) - -* [Google 从单一数据中心到故障转移再到本地多宿主体系结构的过渡](http://highscalability.com/blog/2016/2/23/googles-transition-from-single-datacenter-to-failover-to-a-n.html) - -* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) - -* [Uber 变得与众不同：使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) - -* [为在现代时代构建可扩展的有状态服务提供依据](http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html) - -* [我也想运行有状态容器](https://techcrunch.com/2015/11/21/i-want-to-run-stateful-containers-too/) - -* [Uber 工程技术堆栈，第一部分：基础](https://eng.uber.com/tech-stack-part-one/) - -* [Uber，Twitter，PayPal 和 Hubspot 使用 Apache Mesos 的 4 种独特方式](https://www.linux.com/news/4-unique-ways-uber-twitter-paypal-and-hubspot-use-apache-mesos) - -链接到代码：https://github.com/mesosphere/dcos-cassandra-service - -顺便说一句，在文章中有一个链接。 - -有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。 - -我认为 ELK 不能跟上步伐。 - -@bob。 Uber 确实使用 ELK 进行记录。 它具有最大的 ELK 日志搜索安装之一。 - -我想知道他们是否正在使用 Mesos 卷进行持久数据存储。 - -是的，我们正在使用持久卷（https://mesos.apache.org/documentation/latest/persistent-volume/）进行数据存储。 - -你好 - -您能否阐明查询的性质？ - -聚合或联接或基于纬度的查询？ - -是否想知道 solr 是否可以根据您的用例进行选择？ - -> >有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。 - -如今，许多人用来实现此目的的模式是使用 kafka 日志记录库，该库挂接到其微服务中，并使用 spark 等将来自 Kafka 的日志消耗到 elasticsearch 中。 我们在一个很小的〜8 节点 ES 集群上每秒处理数十万个事件。 - --SRE @ Orchard 平台 - -您能否分享 DC 之间的延迟时间？ - -Uber 使用 DC / OS 很有意思，但选择使用 Aurora 而非马拉松。 我上次查看极光时（大约 18 到 24 个月前），它的发展程度不及马拉松。 我想知道何时做出决定？ Aurora 文档得到了很大的改进。 - -很棒的帖子！ 使用 Mesos 代替 Hadoop YARN 是否有任何特殊原因？ Mesos 是否更适合您的需求？ - -YARN 只能运行 Hadoop 工作负载 Mesos 允许您运行任何类型的工作负载。 - -谢谢您，先生，非常有信息。 -Mesos 可以在没有 docker 容器安装 Cassandra 的情况下运行吗？ -我们可以使用 Mesos 默认容器安装 cassandra 吗？ - -很棒的翔实文章。 做得好！ - -怎么可能有 100 万次写入但每秒 10 万次读取？ 支持多于读比写有意义吗？ \ No newline at end of file +如果您是一家公司，请阅读本书： +[http://www.amazon.com/gp/product/0470345233?ie=UTF8 &标签= innoblog-20 & linkCode = as2 &营地= 1789 & creative = 9325 & creativeASIN = 0470345233“](如何 Cast 割公牛：有关风险，增长和业务成功的意外教训![](img/18d8730cd6a019f27b42227378225f3e.png) http： //www.assoc-amazon.com/e/ir?t=innoblog-20 & l = as2 & o = 1 & a = 0470345233“ width =” 1“ height =” 1“ border = “ 0” alt =“” style =“ border：none！important; margin：0px！important;” / NetApp 创始人 Dave Hitz 的>提供了直接，诚实，周到的业务建议，适用于整个业务成长周期中的业务创始人和领导者。 他特别强调艰难的选择和决策过程，并从冒险的一生中获得了一种理解。 如果您是第一次创业，请阅读本书。 如果您正在进入公司的成长阶段，请阅读本书。 如果您第一次尝试失败并想了解原因，请阅读本书。 如果您想笑些，请读这本书。 这样可以使您的公司扩展过程更有趣。 \ No newline at end of file diff --git a/docs/150.md b/docs/150.md index 6e5ea78..901d72e 100644 --- a/docs/150.md +++ b/docs/150.md @@ -1,38 +1,222 @@ -# FictionPress：在网络上发布 600 万本小说 +# Twitter 如何使用 Redis 进行扩展-105TB RAM，39MM QPS，10,000 多个实例 -> 原文： [http://highscalability.com/blog/2012/7/11/fictionpress-publishing-6-million-works-of-fiction-on-the-we.html](http://highscalability.com/blog/2012/7/11/fictionpress-publishing-6-million-works-of-fiction-on-the-we.html) +> 原文： [http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html](http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html) -![](img/6f37b298e9264b0bac14f3459012960d.png) +[姚悦](https://twitter.com/thinkingfish)自 2010 年以来一直在 Twitter 的 Cache 团队工作。 当然，这是关于 Redis 的，但不仅是关于 Redis 的。 -FictionPress 同时经营 FictionPress.com 和 FanFiction.net，拥有超过 600 万种小说作品，来自世界各地的数百万作家/读者以 30 多种语言参加。 +姚明已经在 Twitter 工作了几年。 她看过一些东西。 她看到 Twitter 上缓存服务的增长从仅由一个项目使用到迅速增加到将近 100 个项目。 那就是成千上万台机器，许多集群和数 TB 的 RAM。 -**已解决的问题**： +从她的讲话中可以很明显地看出，她来自一个真正的个人经历的地方，并且以一种探索问题的实用方式闪耀出来。 这个话题值得一看。 -* 支持 100+百万行的复杂高效索引。 -* 不管数据大小如何增长，可预测且一致的性能。 -* 快速恢复。 -* 确保大规模的可预测性能 +如您所料，Twitter 具有大量缓存。 -**挑战**： +Timeline Service for one datacenter using Hybrid List: -FictionPress 为庞大的用户群提供了许多交互式功能。 其中包括讨论论坛，现场消息传递和用户评论。 FictionPress 决定建立自己的讨论论坛，以满足其严格的安全性和性能要求。 FictionPress 的首席技术官邢力指出，该网站“需要举办成千上万个论坛。 现有的论坛软件无法达到我们的性能和安全目标。” +* 约 40TB 分配的堆 +* 〜30MM qps +* > 6,000 个实例 -为了确保论坛的实时响应性，FictionPress 需要具有创建和有效维护复杂索引并能够支持数百万个小行的能力。 此外，它需要能够对它们建立索引，并且对资源成本和性能的影响最小。 “使所有这些工作并提供良好的客户体验的唯一方法是，即使行数超过 1 亿，也要保证我们的数据库后端能够提供可预测的稳定性能。” +Use of BTree in one datacenter: -FictionPress 考虑使用 InnoDB，它是 MySQL 的默认存储引擎，但它无法提供可预测的大规模性能。 随着行数的增加，索引变得非常慢，从而导致读写性能下降。 InnoDB 还没有提供多个聚簇索引的性能增强功能。 +* 约 65TB 的已分配堆 +* 〜9MM qps +* > 4,000 个实例 -**解决方案**： +稍后，您将了解有关 BTree 和 Hybrid List 的更多信息。 -FictionPress 使用 MariaDB 和 TokuDB 管理其讨论论坛，评论和现场消息传递系统。 +有几点值得注意： -FictionPress 在具有专用硬件的 Linux 环境中安装了 TokuDB。 每种配置都有一个主机，其中有多个读取从机。 Li 说：“ TokuDB 的高写入并发性和对多个聚簇索引的支持使我们可以自由地设计和部署性能更好的大规模查询。” 这对于 FictionPress 很重要，因为其环境在不断扩大。 +* Redis 是一个绝妙的主意，因为它占用服务器上未充分利用的资源并将其转变为有价值的服务。 +* Twitter 对 Redis 进行了专门化，提供了两种完全适合其用例的新数据类型。 因此他们获得了所需的性能，但是将它们锁定在基于旧代码的代码中，因此很难合并到新功能中。 我想知道，为什么要使用 Redis 这样的东西？ 只需使用您自己的数据结构创建时间轴服务即可。 Redis 真的为聚会增添了什么吗？ +* 在网络饱和之前，请使用本地 CPU 功能汇总节点上的大量日志数据。 +* 如果您想要高性能的产品，请将快速路径（即数据路径）与慢速路径（即命令和控制路径）分开， +* Twitter 正在以 Mesos 作为作业调度程序进入容器环境。 这仍然是一种新方法，因此了解它的工作方式很有趣。 一个问题是 Mesos 浪费问题，该问题源于在复杂的运行时世界中指定硬资源使用限制的要求。 +* 中央集群管理器对于使集群保持易于理解的状态非常重要。 +* JVM 慢，C 快。 他们的缓存代理层正在回到 C / C ++。 -可预测的性能：“虽然原始性能很重要，但是响应时间的可预测性是我们对系统进行缩放的一个重点”。 “ InnoDB 只能有一个聚簇索引，但是 TokuDB 基本上为您提供了无限数量。 此外，MyISAM 和 InnoDB 都由于我们大小的数据库上的许多索引而变慢。 MyISAM 还由于并发而导致复制滞后。 最后，TokuDB 为我们提供了可预测性，大规模性能以及更灵活的索引编制，而没有其他 MySQL 选项所具有的限制。” +考虑到这一点，让我们进一步了解 Twitter 上 Redis 的用法： -成本：“要获得更高的性能，总可以向问题扔硬件”，李说。 “相反，通过使用 TokuDB，我们提高了可伸缩性，同时节省了额外的服务器硬件的成本，如果 TokuDB 不在图中，则需要额外的服务器硬件。 此外，由于改进了压缩，与 MyISAM 相比，磁盘空间减少了 8 倍。 节省硬件成本使迁移到 TokuDB 成为一个容易的决定。” +## 为什么要使用 Redis？ -崩溃恢复：FictionPress 最初一直在使用 MyISAM。 Li 表示：“我们需要替换 MyISAM 来处理较小的 BLOB 数据。” “事实上，我们希望尽可能远离 MyISAM，以缩短其长时间的崩溃恢复。 InnoDB 是一种选择，但是 TokuDB 为我们自己的数据集提供了更好的压缩和更小的核心数据和索引数据存储空间。” +* Redis 驱动着 Twitter 最重要的服务时间轴。 时间轴是由 ID 索引的推文索引。 在列表中将推文链接在一起会生成“主页时间轴”。 用户时间轴（由用户已发布的推文组成）只是另一个列表。 -热模式更改：“出于性能原因，我们需要大量索引，但也需要快速添加和维护这些索引，” Li 表示。 “ TokuDB 是我发现的唯一提供热模式更改（例如热索引）的 MySQL 解决方案。 热模式更改是一项强大的功能，我们可以使用它来最大程度地减少系统范围内升级期间的停机时间，并缩短我们的应用程序/架构开发周期。” +* 为什么考虑使用 Redis 而不是 Memcache？ 网络带宽问题和长通用前缀问题。 -李说：“我写的是关于我自己的，但是是第三人称的。” \ No newline at end of file +* 网络带宽问题。 + + * Memcache 在时间表上不如 Redis 正常工作。 问题在于处理扇出。 + + * Twitter 读取和写入**的次数是递增的**，它们很小，但时间表本身却很大。 + + * 生成推文时，需要将其写入所有相关的时间轴。 推文是一小块数据，附加到某些数据结构。 阅读时，最好加载一小部分推文。 向下滚动会加载另一个批次。 + + * 本地时间行可能比较大，这对于观看者一组阅读是合理的。 例如，也许有 3000 个条目。 由于性能原因，应避免访问数据库。 + + * 在大对象（时间轴）上进行增量写入和小型读取的读取-修改-写入周期太昂贵，并且会造成网络瓶颈。 + + * 在每秒 100K +的千兆链接读写中，如果平均对象大小大于 1K，则网络将成为瓶颈。 + +* 长通用前缀问题（确实是两个问题） + + * 灵活的架构方法用于数据格式。 对象具有可能存在或可能不存在的某些属性。 可以为每个单独的属性创建一个单独的键。 这要求针对每个单独的属性发出单独的请求，并且并非所有属性都可以在缓存中。 + + * 随时间推移观察到的度量标准具有相同的名称，每个样本具有不同的时间戳。 如果单独存储每个度量标准，则长公共前缀会被存储很多次。 + + * 为了在两种情况下都更加节省空间，对于指标和灵活的架构，希望有一个分层的密钥空间。 + +* **下的专用缓存群集 利用 CPU** 。 对于简单的情况，内存中的键值存储是 CPU 轻的。 对于较小的键值，一个盒子上 1％的 CPU 时间可以每秒处理超过 1K 个请求。 尽管对于不同的数据结构，结果可能有所不同。 + +* **Redis 是个绝妙的主意** 。 它可以看到服务器可以做什么，但不能做什么。 对于简单的键值存储，服务器端在 Redis 等服务上有很多 CPU 余量。 + +* Redis 于 2010 年在 Twitter 中首次用于时间轴服务。 广告服务中也使用它。 + +* 未使用 Redis 的磁盘功能。 部分原因是因为在 Twitter 内部，缓存和存储服务位于不同的团队中，因此他们使用他们认为最佳的任何机制。 部分原因可能是因为存储团队认为其他服务比 Redis 更适合他们的目标。 + +* Twitter 分叉了 Redis 2.4 并为其添加了一些功能，因此它们停留在 2.4（2.8.14 是最新的稳定版本）上。 更改为：Redis 中的两个数据结构功能； 内部集群管理功能； 内部日志记录和数据洞察力。 + +* 热键是一个问题，因此它们正在构建具有客户端缓存的分层缓存解决方案，该解决方案将自动缓存热键。 + +## 混合列表 + +* 为**增加了可预测的内存性能**，为 Redis 添加了 Hybrid List。 + +* 时间轴是 Tweet ID 的列表，因此是整数列表。 每个 ID 都很小。 + +* Redis 支持两种列表类型：ziplist 和 linklist。 Ziplist 节省空间。 链表是灵活的，但是由于双链表每个键都有两个指针的开销，因此给定 ID 的大小开销非常大。 + +* 为了有效利用内存，仅使用 ziplist。 + +* Redis ziplist 阈值设置为时间轴的最大大小。 永远不要存储比压缩列表中更大的时间轴。 这意味着产品决策（时间轴中可以包含多少条推文）已链接到低级组件（Redis）。 通常不理想。 + +* 添加或删除 ziplist 效率低下，尤其是列表很大时。 从 ziplist 删除使用 memmove 来移动数据，以确保该列表仍然是连续的。 添加到 ziplist 需要内存重新分配调用，以为新条目腾出足够的空间。 + +* 由于时间轴大小，写入操作可能会出现**高延迟。 时间线的大小差异很大。 大多数用户的推文很少，因此他们的用户时间轴很小。 家庭时间表，尤其是那些涉及名人的时间表。 当更新较大的时间线并且高速缓存用完了堆时，这通常是在使用高速缓存时的情况，在有足够的连续 RAM 来处理一个大 ziplist 之前，将淘汰非常大的**小时间线** 。 由于所有这些缓存管理都需要时间，因此写操作可能会具有较高的延迟。** + +* 由于写入被散布到许多时间轴，因此由于内存用于扩展时间轴，因此更有可能陷入**写等待时间陷阱**。 + +* 鉴于写入延迟的高度可变性，**很难为写入操作创建 SLA** 。 + +* 混合列表是 ziplist 的链接列表。 阈值设置为每个 ziplist 可以以字节为单位的大小。 以字节为单位，因为对于**内存有效**而言，它有助于**分配和取消分配相同大小的块**。 当列表经过时，它将溢出到下一个 ziplist 中。 ziplist 直到列表为空时才被回收，这意味着可以通过删除使每个 ziplist 只有一个条目。 实际上，推文并不是经常被删除。 + +* 在“混合列表”之前，一种变通方法是使较大的时间轴更快地过期，这为其他时间轴释放了内存，但是当用户查看其时间轴时，这是昂贵的。 + +## BTree + +* 在 Redis 中添加了 BTree 以支持对层次结构键的范围查询，以返回结果列表。 + +* 在 Redis 中，处理辅助键或字段的方法是哈希映射。 为了对数据进行排序以便执行范围查询，使用了一个排序集。 排序后的订单按双倍得分排序，因此不能使用任意的辅助键或任意的名称进行排序。 由于哈希图使用线性搜索，因此如果有很多辅助键或字段，那就不好了。 + +* BTree 是尝试解决哈希映射和排序集的缺点。 最好让**一个可以完成您想要的内容的数据结构**。 更容易理解和推理。 + +* 借用了 BTree 的 BSD 实现，并将其添加到 Redis 中以创建 BTree。 支持键查找以及范围查询。 具有良好的查找性能。 代码相对简单。 缺点是 **BTree 的内存效率不高**。 由于指针，它具有大量的元数据开销。 + +## 集群管理 + +* 集群出于单一目的使用多个 Redis 实例。 如果数据集大于单个 Redis 实例可以处理的数据量或吞吐量高于单个实例可以处理的数据量，则需要对键空间进行分区，以便可以将数据存储在一组实例中的多个分片中 。 路由选择一个密钥，并弄清楚该密钥的数据在哪个分片上。 + +* 认为集群管理是 Redis 采用率未激增的**首要原因。 当群集可用时，没有理由不**将所有用例迁移到 Redis** 。** + +* Tricky 正确安装 Redis 群集。 人们之所以使用 Redis 是因为作为数据结构服务器的想法是执行频繁的更新。 但是很多 Redis 操作都不是幂等的。 如果出现网络故障，则需要重试，并且数据可能会损坏。 + +* Redis 集群**倾向于使用** **集中管理器** **来规定全局视图**。 对于内存缓存，很多集群都使用基于一致性哈希的客户端方法。 如果数据不一致，那就这样。 为了提供真正好的服务，集群需要一些功能，例如检测哪个分片已关闭，然后重播操作以恢复同步。 经过足够长的时间后，应清除缓存状态。 Redis 中的损坏数据很难检测。 当有一个列表并且缺少一个大块时，很难说出来。 + +* Twitter 多次尝试构建 Redis 集群。 [Twemproxy](https://github.com/twitter/twemproxy) 并未在 Twitter 内部使用，它是为 [Twemcache](https://github.com/twitter/twemcache) 构建的 和 Redis 支持增加了。 另外两个解决方案基于代理样式路由。 其中一项与时间轴服务相关，并不意味着具有普遍性。 第二个是对 Timeline 解决方案的概括，该解决方案提供了群集管理，复制和碎片修复。 + +* **群集中的三个选项**：服务器相互通信以达成群集外观的共识； 使用代理； 或进行客户端集群的客户端集群管理。 + +* 并非采用服务器方法，因为其理念是**使服务器保持简单** **，笨拙且快速**。 + +* 不接受客户端，因为 **更改很难传播** 。 Twitter 中约有 100 个项目使用缓存集群。 要更改客户端中的任何内容，必须将其推送到 100 个客户端，更改可能要花费数年的时间才能传播。 快速迭代意味着几乎不可能将代码放入客户端。 + +* 之所以使用代理样式路由方法和分区，有两个原因。 缓存服务是一种高性能服务。 如果您想要**高性能的产品，请将快速路径（即数据路径）与慢速路径** **（即命令和控制路径**）分开。 如果将群集管理合并到服务器中，则会使作为有状态服务的 Redis 代码变得复杂，每当您想要**修复错误或为群集管理代码提供**升级时，有状态 Redis 服务必须 也需要重新启动，这可能会丢弃大量数据。 群集的滚动重启很痛苦。 + +* 使用代理方法存在一个问题，即在客户端和服务器之间插入了另一个网络跃点。 **分析显示额外的跃点是一个神话**。 至少在他们的生态系统中。 通过 Redis 服务器的等待时间不到 0.5 毫秒。 在 Twitter 上，大多数后端服务都是基于 Java 的，并使用 Finagle 进行对话。 通过 Finagle 路径时，延迟接近 10 毫秒。 因此，额外的跃点并不是问题。 **JVM 内部是问题**。 在 JVM 之外，您几乎可以做任何您想做的事情，除非您当然要通过另一个 JVM。 + +* 代理失败并不重要。 在数据路径上引入代理层还不错。 客户不在乎与之交谈的代理。 如果超时后代理失败，则客户端将转到另一个代理。 在代理级别没有分片操作，它们都是无状态的。 要扩展吞吐量，只需添加更多代理。 权衡是额外的成本。 代理层被分配用于执行转发的资源。 群集管理，分片和查看群集的操作均在代理服务器外部进行。 代理不必彼此同意。 + +* Twitter 的实例具有 **100K 开放连接** ，并且工作正常。 只是有开销要支付。 没有理由关闭连接。 只要保持打开状态，就可以改善延迟。 + +* 缓存集群用作 [后备缓存](http://www.quora.com/Is-Memcached-look-aside-cache) 。 缓存本身不负责数据补充。 客户端负责从存储中获取丢失的密钥，然后将其缓存。 如果某个节点发生故障，则分片将移至另一个节点。 出现故障的计算机恢复运行时将被刷新，因此不会留下任何数据。 所有这些都是由**集群负责人**完成的。 集中观点对于使集群保持易于理解的状态非常重要。 + +* 用 C ++编写的代理进行了实验。 **C ++代理看到** **性能显着提高**（未给出编号）。 代理层将移回 C 和 C ++。 + +## Data Insight + +* 当有电话说缓存系统在大多数情况下都无法正常运行**时，缓存就很好**。 通常，客户端配置错误。 或者他们通过请求太多密钥来滥用缓存系统。 或一遍又一遍地请求相同的密钥，并使服务器或链接饱和。 + +* 当您告诉某人他们正在滥用您的系统**时，他们需要证明**。 哪个键？ 哪个分片不好？ 什么样的流量导致这种行为？ 证明需要可以显示给客户的指标和分析。 + +* SOA 架构不会给您问题隔离或自动调试的便利。 您必须对组成系统的每个组件具有良好的可见性**。** + +* 决定将 Insight 内置到缓存中。 缓存是用 C 语言编写的，并且速度很快，因此可以提供其他组件无法提供的数据。 其他组件无法处理为每个请求提供数据的负担。 + +* **可以记录每个命令**。 缓存可以 100K qps 记录所有内容。 仅记录元数据，不记录值（关于 NSA 的笑话）。 + +* **避免锁定和阻止**。 特别是不要阻止磁盘写入。 + +* 以 100 qps 和每条日志消息 100 字节的速度，每个盒子每秒将记录 10MB 数据。 开箱即用的大量数据。 万一出现问题，将使用 10％的网络带宽。 **在经济上不可行**。 + +* **预计算日志可降低成本** 。 假设它已经知道将要计算什么。 进程读取日志并生成摘要，并定期发送该框视图。 与原始数据相比，该视图很小。 + +* View 数据由 Storm 汇总，存储并在顶部放置一个可视化系统。 您可以获取数据，例如，这是您的前 20 个键； 这是您的点击量的第二个，并且有一个高峰，这表示点击量模式很尖锐； 这是唯一键的数量，这有助于容量规划。 当捕获每个日志时，可以做很多事情。 + +* 洞察力对于运营非常有价值。 如果存在丢包现象，通常可以将其与热键或尖刻的流量行为相关联。 + +## Redis 的愿望清单 + +* 显式内存管理 。 + +* **可部署（Lua）脚本** 。 刚开始谈论。 + +* **多线程** 。 将使群集管理更加容易。 Twitter 有很多“高个子”，其中主机具有 100+ GB 的内存和许多 CPU。 要使用服务器的全部功能，需要在物理机上启动许多 Redis 实例。 使用多线程，将需要启动更少的实例，这更易于管理。 + +## 获得的经验教训 + +* **量表要求可预测性** 。 集群越大，客户越多，您希望服务成为更具可预测性和确定性的对象。 当有一个客户并且有问题时，您可以深入研究问题，并且很有趣。 当您有 70 个客户时，您将无法跟上。 + +* **尾部延迟很重要** 。 当您扇出很多分片时，如果分片缓慢，则整个查询将变慢。 + +* 确定性配置在操作上很重要 。 Twitter 正朝着容器环境迈进。 Mesos 用作作业计划程序。 调度程序满足对 CPU，内存等数量的请求。监视器将杀死超出其资源需求的任何作业。 Redis 在容器环境中引起问题。 Redis 引入了外部碎片，这意味着您将使用更多内存来存储相同数量的数据。 如果您不想被杀死，则必须通过供过于求来弥补。 您必须考虑我的内存碎片率不会超过 5％，但我会多分配 10％作为缓冲空间。 甚至 20％。 或者，我想每台主机将获得 5000 个连接，但以防万一我为 10,000 个连接分配内存。 结果是巨大的浪费潜力。 如今，超低延迟服务在 Mesos 中不能很好地发挥作用，因此这些工作与其他工作是隔离的。 + +* **在运行时了解您的资源使用情况确实很有帮助** 。 在大型集群中，会发生坏事。 您认为自己很安全，但是事情会发生，行为是无法预料的。 如今，大多数服务无法正常降级。 例如，当 RAM 达到 10GB 的限制时，请求将被拒绝，直到有可用的 RAM。 这只会使与所需资源成比例的一小部分流量失败。 很好 垃圾收集问题不是很正常，流量只是掉在地上，这个问题每天都会影响许多公司中的许多团队。 + +* **将计算推入数据** 。 如果查看相对的网络速度，CPU 速度和磁盘速度，那么在进入磁盘之前进行计算并在进入网络之前进行计算是有意义的。 一个示例是在将节点上的日志推送到集中式监视服务之前对其进行汇总。 Redis 中的 LUA 是将计算应用于数据附近的另一种方法。 + +* **LUA 今天尚未在 Redis 中投入生产** 。 按需脚本编写意味着服务提供商无法保证其 SLA。 加载的脚本可以执行任何操作。 哪个服务提供商会愿意冒别人代码的风险承担违反 SLA 的风险？ 部署模型会更好。 它将允许代码审查和基准测试，因此可以正确计算资源使用情况和性能。 + +* **Redis 是下一代高性能流处理平台** 。 它具有 pub-sub 和脚本。 为什么不？ + +## 相关文章 + +* [Google：驯服长时间延迟的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) [架构](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) +* [Twitter 用于处理 1.5 亿活跃用户，300K QPS，22 MB / S 的 Firehose，并在 5 秒内发送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) +* [带有碎片的问题-我们可以从 Foursquare 事件中学习到什么？](http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-from-the-foursquare.html) +* [始终记录所有内容](http://highscalability.com/blog/2007/8/30/log-everything-all-the-time.html) +* [低级可伸缩性解决方案-聚合集合](http://highscalability.com/blog/2013/3/6/low-level-scalability-solutions-the-aggregation-collection.html) + +万一 Twitter 上有人读过我：为什么不禁用 EVAL（不是 EVALSHA），重命名 SCRIPT 并使用它来预加载脚本？ 然后，您可以发布您的客户端可以使用的 SHA 目录。 + +“ Redis 是下一代高性能流处理平台。它具有 pub-sub 和脚本功能。为什么不呢？” + +更重要的是，2.8.9 在 PFADD / PFCOUNT / PFMERGE 命令中添加了 HyperLogLog（当然，Twitter 被困在 2.4 中）。 这样就可以在恒定内存中非常精确地近似估计流中唯一键的数量，而不必存储整个数据集。 例如，每天/每周/每月的唯一身份访问者数量。 这使大量分析成为可能，而不必使用像 Hadoop 这样的大数据大炮。 + +@Pierre Chapuis：我认为您的建议会奏效。 我认为这不是最干净的方法，但是：SCRIPT *是一个在线命令，如果我要离线加载（或者至少不通过数据路径完成加载），我会强烈建议这样做。 可能添加了一个配置选项，例如 SCRIPT_LOAD_PATH，以按照您的建议从目录中读取它们。 + +现在，如果我们允许即时重新加载配置（我在当前项目中已经计划过的事情），您甚至可以更新脚本而不会丢失所有数据或阻止流量。 + +MM 被用作百万的缩写吗？ 在技​​术环境中看到它似乎有些奇怪……这不是更多的财务缩写吗？ Just M 对我来说更容易。 + +我喜欢这样的观察：面向服务的体系结构的优点（概括地说）仅与您在服务边界处所做的工作一样好。 她说这是出于监视的目的（SOA 并没有因为服务 A 而神奇地将服务 B 隔离出问题）。 但这似乎同样适用于记录清晰的 API 合同，保持代码库清晰等。我在阐明将应用程序分解为服务方面对我有吸引力的方面时遇到了一些麻烦，而我认为那是缺少的部分-仅仅是 SOA 的概念不能提供大多数价值； 在边界上应用的整套实践可以提供帮助。 + +还发人深省（且合理）：像 Redis 这样的代码库往往不会由委员会维护，您需要进行认真的审查才能阻止糟糕的代码。 （最近阅读了很多 golang 的代码审查/变更列表流，因为它是公开的，有时它是保持语言状态最简单的方法，并且通常给它留下深刻的印象。） + +关于脚本，我想知道如何在包装盒上找到包含数据的脚本，作为具有自己的容器和资源限制的普通 Redis 客户端。 您可以避免带宽限制； 您可以控制资源的使用（也许在分配内核的级别？）； 您不仅可以使用 Lua，还可以使用 Scala 或其他任何方法（尽管如此，但是，GC）。 Redis 的进程内 Lua 脚本可能没有通信成本，而它们会占用宝贵的 RAM 来存储数据，但这是一件容易的事。 + +对于 Twitter 开放源代码混合列表/树，这听起来像是最好的“自私”论据，它最终意味着更快地加入 2.8。 :) + +@姚谢谢您的回答。 我同意选择离线加载（“东京霸王”）会更好。 另外，为 SHA 赋予别名是经常需要的功能，这将大有帮助，并使得可以以向后兼容的方式更新脚本的实现。 + +阅读这篇文章会让我觉得自己生活在一个平行的宇宙中，并且做着非常相似的事情。 + +嗨， +不错的演示。 我曾经遇到的一个问题是-您是否将 ssl 与 redis 一起使用？ \ No newline at end of file diff --git a/docs/151.md b/docs/151.md index 83f14b5..cf35bad 100644 --- a/docs/151.md +++ b/docs/151.md @@ -1,163 +1,164 @@ -# StubHub 体系结构：全球最大的票务市场背后的惊人复杂性 - -> 原文： [http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html](http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html) - -![](img/4fbc80a9b3d12c301a08338a63eea311.png) - -StubHub 是一个有趣的架构，因为作为门票的做市商，他们所从事的业务与我们通常考虑的业务不同。 - -StubHub 规模惊人，每年以 20％的速度增长，每小时可处理 80 万个复杂页面，每年可售出 500 万张门票，每小时可处理 200 万次 API 调用。 - -票务空间异常复杂。 StubHub 的流量非常棘手。 突发性，围绕不可预测的游戏结果，事件，时间表和季节。 涉及很多钱。 有很多不同的参与者。 涉及许多复杂的业务流程。 StubHub 在业务上有几个互补但又截然不同的部分：它们有一个广告服务器组件，可为 ESPN 等网站提供广告，丰富的交互式 UI 和实时门票市场组件。 - -对我而言，最有趣的是 StubHub 如何将票务，销售点系统，FedEx 交付，买卖双方以及金钱等曾经一度是高接触的实体世界带入数字领域。 他们通过与组织（例如美国职业棒球大联盟）的深度电子集成以及将复杂业务流程移出应用程序空间的生命周期总线来实现这一目标。 - -这是一个很有趣的问题，因为在处理业务构建功能成为首要任务时必须继续处理构建的旧系统，这使问题变得更加复杂。 让我们看看 StubHub 如何使其全部工作... - -## 资源 - -* 查理·芬曼（Charlie Fineman）在 QCon 上的演讲： [StubHub：为全球最大的票务市场](http://www.infoq.com/presentations/StubHub-Designing-for-Scale-and-Innovation-for-the-World-s-Largest-Ticket-Marketplace)设计规模和创新 - -## 商业模式 - -* **StubHub 是用于门票** 的 eBay。 为门票买卖双方提供一个市场。 他们不像 Ticketmaster 。 -* **托管模型用于为卖家** 提供信任和安全。 信用卡记录在 StubHub 上，当确认订单已收到时，才转移款项。 -* **门票不是商品** 。 买家想要特定的门票，而不是看台座位。 数量有限，没有滞票。 卖方不断更新价格和数量以响应市场力量。 这是一个非常活跃的市场。 - -## 统计信息 - -* 每年 500 万订单 -* 200 万个活动列表/门票。 -* 门票围绕 45,000 个赛事进行。 美国职业棒球大联盟的职缺赛季和超级碗是最活跃的时期。 -* 销售额每年以 20％的速度增长。 -* 每小时可处理 600k-800k 复杂页面。 在后期赛季每小时爆破一百万。 -* 在美国 10 到 12 个核心醒着时间的狭窄时段中，流量突发。 例如，季后赛结束后，会有买家为下一场比赛疯狂。 -* 每小时有 200 万来自会员的 API 调用。 -* 24-36 工程师。 -* 这是一项高触感的业务。 交易的支持电话过去是 1-1，但现在好多了。 员工最大的部分是客户服务和后台业务运营支持。 - -## 平台 - -* Java -* 冷融合（旧版） -* ActiveMQ -* [SEDA](http://www.eecs.harvard.edu/~mdw/proj/seda/) （分段事件驱动的体系结构） -* Lucene / Solr -* Jboss -* 内存缓存 -* Infiniband -到 SAN 的快速网络 -* XSL -* Oracle 的高级队列 -* TeamWorks -IBM 工作流构建器 -* Splunk -* Apache HttpClient -* Log4j（使用消息格式） -* 挂毯 - -## 架构 - -* 门票的三种购买来源：Web，销售点系统，批量上传。 批量上传允许将票证单上传到系统中。 -* Manager 层在 Ticket 数据库上方提供了业务对象抽象。 它调解了所有与票证表的对话。 -* 票务表会因买卖双方的活动以及事件周围的自然流量突发性而受到影响。 -* 活跃的市场可能导致移动客户端与系统的当前状态过时，因此买家对旧数据做出反应。 -* 两个数据泵将来自 Tickets 数据库的数据馈送到内部和外部系统：我的帐户，查找和公共馈送。 我的帐户是用户帐户的界面。 查找是一种搜索功能。 Public Feeds 为 ESPN 和 eBay 等网站提供支持。 - * 内部供稿-包含用于仪表板，卖家是谁，销售情况，销售速度，热图等敏感信息，例如帐户信息。它还根据敏感的市场数据供稿主页的某些部分， 例如热门话题，他们不想与公众分享。 - * 外部供稿（LCS）-广告商，例如 ESPN ，都通过此供稿供稿。 广告是通过 IP 地址映射的地理位置。 -* LCS （上市目录服务）： - * 我在这里道歉，幻灯片有些偏离，并且很难使演讲者与演示文稿匹配。 所有错误都是我的。 - * 触发器用于使修改表保持最新状态，以进行数据库中发生的更改。 - * 更改数据捕获作业不断轮询更改，并将消息注入到 ActiveMQ 代理中。 这是路由的第一级，包含 sma ll 有效负载：对象 ID，对象类型和更改日期。 - * 更改数据被路由到主服务器，这是在数据中心之间进行复制的基本机制。 辅助数据中心订阅了这些主题，这就是在数据中心之间复制数据的方式。 - * 进入主数据后，数据将被注入 SEDA 队列中进行处理（稍后会有更多介绍）。 - * 未使用管理器是因为存在许多不使用管理器而直接进入数据库的旧系统，因此数据库是分发增量的常见点。 - * 他们的大多数广告是 Flash，但有些广告使用 HTML 呈现。 - * LCS 提供了购物体验，例如从体育场的交互式图形中选择门票。 Solr 使添加这样的新功能非常容易。 -* SEDA （分段事件驱动的体系结构）在主服务器中使用 - * 主服务器接收 sma ll 更新并弄清楚如何 构建进入内存缓存的内容，以便最终将路由到 Solr 。 - * 使用协议缓存格式将消息缓存在 memcached 中。 - * 消息发送到第二个代理，该代理将消息分散到边缘，即 Lucene / Solr。 - * 消息使用者从代理接收消息。 - * 从数据库加载实体。 - * 确定更新是否有任何级联影响。 因为 Solr 和其他 NoSQL 数据库不进行联接，所以例如，如果更改了乐队名称，则该更改必须传播到 ll 事件。 - * 序列化实体。 将其存储在内存缓存中。 - * 将消息发送到第二个 ActiveMQ 代理，该代理将消息路由到边缘，即 Solr。 - * 通过单独的路由处理代理侦听代理。 这曾经在 Jboss 中，但是 Jboss 会不知所措，他们遇到了饥饿问题，因此将其移出 Jboss。 该侦听器成为系统中用于操作管理的有用阀门。 如果他们需要换出新的 Solr 索引以放入新架构，则可以关闭阀门，让消息在消息代理中备份，然后再次打开阀门，消息将再次开始流动。 从 Solr 故障中恢复，复制索引和更新模式时，这些阀门对其操作稳定性产生了巨大影响。 - * A ll 这些都是阻塞操作，因此使用线程池可以防止数据库连接风暴。 - * SEDA 是一种平滑负载的技术。 从资源管理的角度来看，这对他们是有效的。 想法是将工作分解成足够小的部分，以至于缓慢的工作不会窃取其他用户的线程。 工作是分阶段建模的，每个阶段都有自己的线程池，可作为工作节流阀。 -* Solr - * Solr 提供了一个不错的文档存储和自然语言文本查询功能。 - * 所有搜索都基于 Solr，包括构面。 - * 快速。 查询以 10 毫秒或更短的时间返回。 他们在 SAN 上使用了 Infiniband 网络，发现他们不需要在内存中缓存数据，他们可以通过快速的网络以足够快的速度为 SAN 提供数据服务。 - * 潜力。 灵活的查询语言，可以使用 ll 文本搜索以及 geo -特殊搜索。 - * 支持许多输出格式：XML，Atom， RSS ，CSV， Json 。 使与各种客户端的集成变得更加容易。 - * 高频写入不是很好。 在高频写入下复制似乎集成得不好。 看到成千上万的更改时执行 rsync 不起作用。 您会获得真正过时的数据。 因此，他们必须建立自己的复制机制。 - * 平面数据结构。 仍然几乎是面向行的。 他们希望支持结构更复杂的文档。 -* DCL -双击介绍浏览 - * URL 映射到 ID ：类型 ID，地理位置 ID，渲染类型 ID。 - * DCL （仅是 XSL ）使用类型 ID 和 Geo ID 为 LCS 创建查询。 然后可以一般性地呈现返回的数据。 因此 ll footba ll 小组可以使用 URL 映射 XSL 和 LCS 为他们生成具有完全相同结构的相似页面 ]。 - * 巨大的生产率提高，使添加新功能变得更加容易。 页面中的每个块都是通过 CMS 管理的单个资产。 它们是 XSL 的大块，针对从 LCS 中检索到的上下文文档进行渲染。 - * A RenderChunkByName ca ll 使在 Facebook 等其他服务上呈现事件变得容易。 - * 在后端进行所有这些操作以实现 SEO 目的。 当搜索引擎可以为 Ajax 编制索引时，他们可能不需要这样做。 -* gifs ，样式表等的边缘缓存，但是数据缓存在它们的服务器上。 -* 减少每笔交易的客户互动次数： - * 客户互动是其营业收入的最大消耗。 当情况恶化时，需要与买卖双方共同努力以解决问题。 - * 增加客户自助服务。 顾客想知道什么时候拿到钱和票。 MyAccount 屏幕允许客户在不使用客户服务的情况下检查订单进度。 - * 向卖家公开 API ，以便他们可以将这些功能集成到他们的系统中。 - * IVR -集成的语音识别系统支持客户打电话以查找其帐户状态。 - * 现金流量对供应商很重要，因此他们致力于更快地付款。 - * 与美国职棒大联盟（Major League Baseball）的电子集成，因此他们可以在卖方实际拥有票证之前直接从卖方将票证转让给买方。 即时交付并极大地提高了客户满意度并消除了故障点。 -* 生命周期总线 - * 用于防止硬链接应用程序中的复杂工作流。 签出应用程序不必担心 ll 下游存在的不同业务流程。 您只需要担心已验证的信用卡和订单，而不要担心配送和电子邮件之类的问题。 - * 在处理遗留问题和管理站点更改时很有用。 - * 有关于 ll 主要生命周期事件的主题。 代理在 Oracle 队列中侦听主题。 下订单时，它将进入未确认状态。 侦听器将收听“未经确认”的主题，并通过电子邮件向卖方发送电子邮件以访问该站点并确认订单。 当卖方确认订单后，那里的代理商将从买方的托管账户中提取款项，向买方发送电子邮件，说明卖方已确认并在何处找到机票。 确认票证后，付款便退给了卖方。 - * 所有这些逻辑都与面向网站的最终用户分离。 这些都是后台引擎。 - * TeamWorks 为这些流程建模，发现弱点，监视流程，检查 SLA 并触发操作。 帮助更好地优化后台业务流程。 由于他们每年以 20％的速度增长，因此他们不希望运营团队的年增长率达到 20％。 - * FedEx 是最初的履行方式。 电子实现已添加。 业务流程如下：未确认->自动确认； 已确认->条码重发和付款 PDF； 实现。 您要做的就是编写在相同订单生命周期内生存的代理，以实现新的实现模式。 该逻辑不在应用程序中。 它在代理中，是一个可单独部署和测试的单元。 - * 避免欺诈。 使用相同的生命周期模型来实现，但增加了两个新状态：已购买和已批准。 他们无需进行任何更改即可添加避免欺诈的功能。 他们只需要更改状态机即可。 代理决定将其移至批准状态或未批准状态。 -* 销售点系统集成 - * 使用两个阶段的提交：在外部系统上预订票证，将其标记为 StubHub 中声明的内容，在外部系统上提交购买。 - * 希望对此进行概括，以便其他系统可以在交易中购买门票。 将门票与旅行或酒店购买捆绑在一起。 -* Splunk 和染料 - * 在 StubHub 上最大的投资回报率项目之一。 节省了很多调试时间。 - * 染色-工件被放置在每个请求的 HTTP 标头中。 - * 这些使用 Log4j 记录。 - * 使用 Splunk ，如果订单有问题，您可以使用染料标记查看日志行以向后推 ll ，然后查看 ll 属于请求的呼叫，包括对 LCS 之类的其他服务的二次呼叫。 追溯活动很容易。 - * 确实类似于 Splunk 。 就像日志行的文档存储。 将染料标记和 ID 排序到日志行，就像一系列键值对一样， Splunk 使得查看日志变得非常容易。 他们的仪表板是使用 Splunk 编写的，用于统计信息，例如每分钟的事务，每分钟的失败。 您可以根据需要对数据进行切片和切块。 - * 将 Log4j 与消息格式一起使用，以便它不会创建动态字符串。 - -## 得到教训 - -* **可扩展性是专业化** 。 每个问题空间都有其独特的特征，必须构建任何系统来解决该特定问题。 StubHub 受制于对安全购买体验的需求，票务市场的独特性质，突发流量以及事件多变的局面。 他们的系统必须反映这些要求。 -* **从一开始就使用抽象层** 。 否则，您将无法继续为旧客户提供支持，而超出了您的承受能力。 -* **生产中的烘烤** 。 实施多种解决方案，并在生产中进行审核，以确定哪个版本更好。 StubHub 在生产中测试了两个不同的数据泵版本，以发现哪种版本更合适。 您不想支持多种基础架构。 -* **将工作移出 Jboss** 。 大量请求可能会导致 Jboss 饿死，因此他们将工作移到 Jboss 之外。 -* **通过因果链** 渗滤染料。 检测请求，以便可以在整个堆栈中跟踪请求。 这是一个巨大的投资回报，能够调试整个堆栈中的问题。 -* **优化业务流程。** 系统之间的电子集成。 通过充当卖方，买方和 MLB 之间的协调者，他们能够提高客户满意度并消除交易中的大量可能失败点。 购买了受欢迎的销售点程序，以便他们可以与它集成。 -* **建立在您自己的 API** 上。 他们花费大量时间尝试在自己的 API 上构建自己的应用程序，以便他们可以更好地管理其用户和合作伙伴的体验。 -* **一般定义资产** 。 定义资产以便可以在任何上下文中呈现它们，可以轻松组成不同格式的页面并在其他网站上呈现事件。 -* **从 ROI 透视图** 最大化开发。 寻找可提高开发人员 ROI 的项目。 使用 Solr 对他们来说是一个巨大的胜利。 它易于使用，快速且非常实用，可以立即满足许多类型的查询。 -* **SEDA 适合阻止读取** 。 他们的许多系统都基于阻止读取，因此 SEDA 非常适合该用例。 线程池可防止淹没他们要使用的资源。 -* **在客户端** 上呈现。 对于像体育场馆地图这样非常酷的交互式地图，在客户端上通过 ll 处理 ll 的 UI 交互可节省大量服务器负载。 即使对于具有 10-20K 列表的大型活动，下载整个列表也是一个更好的解决方案。 -* **比重框架**更薄。 沉重的框架易于使用和滥用。 隐藏的复杂性使您很快失去对站点的控制。 示例：Hibernate 和基于组件的框架。 验证和业务逻辑可能会泄漏到表示层中。 做出明智的决定。 了解遗留问题方面的问题。 -* **糟糕的经历是最好的训练** 。 就像没有教给如何正确做事一样。 刚开始 StubHub 的家伙正在通过尽快发布功能来建立业务，但这留下了一笔遗产。 管理遗留物的关键是管理依赖关系。 使用基于代理的 Lifecycle Bus 样式解决方案可帮助他们了解对遗留系统的依赖性。 -* **使用工作流将状态机与应用程序分离。** 不要在应用程序逻辑中嵌入复杂的流。 外部化逻辑，以便业务流程可以更灵活的方式耦合在一起。 这使系统在未来变得无限灵活和适应性强。 -* **避免使用 ETL** 。 它引入了许多您不想处理的依赖项。 有风险。 当您尝试确定财务上依赖的变更对您而言是否很大时，旧式数据模型可以真正占用资源。 -* **不要缩短 CM 和部署**。 当前，对于开发人员来说，这是最大的浪费时间。 非常痛苦 现在投资您的 CM 和部署系统。 -* **投资持续改进** 。 它不是免费提供的。 在项目上运行验尸。 确保问题不再出现。 随着公司的发展，这些东西无法扩展。 立即做出正确的决定，否则将来 ll 需要花费 3 到 5 倍来解决。 -* **在系统** 中建立操作阀。 例如，如果您需要换出新的架构，请使用一个阀门，您可以在其中关闭事件并重新启动它们。 - -该 Java Framework Tapestry 在哪里使用？ - -您是在我们网站上还是其他地方？ - -“当您试图找出变更是否会带来巨大收益时，它们将成为您财务上依赖的系统。” - -句子里有错字，对不对？ 难道不是“当您试图确定变更是否会创建您在财务上依赖的系统时”吗？ 谢谢。 - -爱德华 - -我认为这个家伙在获得我的要点方面做得很好，但是在这种情况下...是的...这很想念...我认为不是错字。 :-)在不返回原始录音版本的情况下，它应该类似于： - -“当您试图确定更改是否会在您所依赖的系统中造成回归时” - -我真的想了解更多有关如何在 HTTP 标头中使用 splunk 和 dye 来跟踪整个堆栈中的每个请求的信息，从调试的角度来看，这是非常有用的功能。 \ No newline at end of file +# 正确处理事情：通过即时重放查看集中式系统与分散式系统 + +> 原文： [http://highscalability.com/blog/2014/9/15/getting-things-right-a-look-at-centralized-vs-decentralized.html](http://highscalability.com/blog/2014/9/15/getting-things-right-a-look-at-centralized-vs-decentralized.html) + +*三个棒球裁判坐在酒吧周围，谈论他们如何在每个球场上打电话：第一裁判：有些是球，有些是打击，我将它们原样称呼。 第二位裁判：有些是球，有些是罢工，我称它们为“ em”。 第三次裁判：有些是球，有些是罢工，但直到我叫“ em”，它们才算是什么。* + +| ![](img/e9f57dcfbaa4ae4f974182c381d64d9f.png) +AT&T's Global [Network Operations Center](http://www.nj.com/business/index.ssf/2011/08/att_gnoc_earthquake.html) | ![](img/2e0523f20e3b155cee6e86dbdec861dd.png) +MLB 的[即时重播掩体](http://sports.yahoo.com/news/inside-look-at-mlb-s-new-instant-replay-bunker-032951044.html) | ![](img/7d078afdb4b153b2a46d7fdd99d65438.png) +NHL 的[情况室](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/) | + +**更新**：[在 NFL 重放命令中心内](http://mmqb.si.com/2014/11/11/inside-the-nfls-replay-command-center/) + +看一下我们认为主要属于计算机科学领域的概念在其他领域如何发挥作用很有趣。 一个有趣的例子是 [Instant Repla](http://en.wikipedia.org/wiki/Instant_replay) y 如何通过实现重播来反映甚至帮助[塑造](http://www.nfl.com/videos/nfl-network-top-ten/09000d5d811133e8/Top-Ten-Things-that-Changed-the-Game-Instant-replay)体育文化：[去中心化](http://en.wikipedia.org/wiki/Distributed_computing)或[集中化](http://en.wikipedia.org/wiki/Centralized_computing)。 + +有利可图的电视交易为专业体育运动注入了大量资金。 有了这么多钱，体育运动已经从纯粹的娱乐变成了**使事情变得正确**。 打个坏电话的代价太高了，无法让人为因素决定泰坦的命运。 + +正确处理事情也是计算机科学领域的热门话题。 在 CS 中，正确处理语言使用诸如事务，回滚，仲裁，乐观复制，线性化，同步，锁定，最终一致，补偿事务等术语。 + +在体育界为了使事情变得正确，裁判员使用诸如举旗，罚则，规则，裁决立场，重设时钟，向下和距离，取得线，吹哨，确认裁决以及推翻裁决等术语。 + +尽管词汇不同，但意图却是相同的。 正确性。 + +目的并非所有技术和体育都有共同点。 随着技术的发展，我们看到体育运动正在发生变化，以利用技术所提供的新功能。 这些变化应该是软件中任何人都熟悉的。 体育已经从完全分散的司法体制转变为现在我们看到的 [NBA](http://www.si.com/nba/point-forward/2014/05/18/nba-instant-replay-off-site-review-adam-silver) ， [NFL](http://espn.go.com/nfl/story/_/id/10670707/nfl-owners-allow-centralized-system-aid-instant-replay) ， [MLB](http://sports.yahoo.com/news/inside-look-at-mlb-s-new-instant-replay-bunker-032951044.html) 和 [NHL](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/) ， 融合到某种形式的集中式系统上。 + +NHL 是创新者，于 2011 年启动了他们的集中式即时重放系统。它的工作原理类似于...官员坐在位于多伦多的作战室中，该作战室看起来非常类似于曾经建立的每个[网络运营中心](http://en.wikipedia.org/wiki/Network_operations_center)。 所有游戏的视频源都流进了房间。 如果存在争议或明显值得回顾的游戏，则会与多伦多联系，以对正确的电话进行快速回顾和判断。 每个运动都会以自己的方式实现自己的集中式重播系统，但这就是要旨。 + +我们已经看到了完全相同的转变，例如电子邮件之类的联合服务已被 Twitter 和 Facebook 等集中式服务所取代。 事实证明，体育和计算机科学具有更深的相似之处。 那可能是什么？ + +## 发明了即时重播功能，以正确处理事情 + +多年来，正确处理事情一直在发展。 首先，您需要一套规则。 没有规则，就不可能把事情做好。 使用一套适当的规则，游戏可以属于以下几类之一：自引游戏，无引荐游戏或引荐游戏。 + +**无裁判游戏**的示例在 [Outlander 电视节目](http://www.imdb.com/title/tt3006802/)的一集中进行了描绘，该剧集主要设置于 18 世纪。 它有一个很棒的场景，显示正在玩的游戏看起来像是苏格兰风格的曲棍球。 两支球队用大棒子打了一个球。 到目前为止还很熟悉。 然而不久之后，这些棍子就被用作武器，并且球员们到处互相棍打。 它造就了一场血腥的好游戏，但并没有过多地强调正确的事情。 变得...是的。 + +**休闲游戏**是一种玩足球，篮球或其他类型的接力游戏的聚会，它遵循一组规则，但通常都是自参考的。 没有裁判可以打电话。 游戏不是那么重要。 玩家会自称犯规，或者对方会称对方为犯规，但这都是非常非正式的，可能导致激烈的分歧。 + +## 游戏是去中心化且无锁的 + +在游戏发展的这一点上，游戏完全**去中心化**。 游戏彼此完全独立。 可以同时玩任何数量的游戏。 您需要的是足够的玩家和一个玩耍的地方。 + +还要注意，游戏是**无锁**，完全没有任何形式的货币控制。 场上的所有活动并行进行，场上的游戏状态是场上发生的一切。 + +对于无裁判员比赛，事后无法修复违反规则的情况。 对于自引游戏，修复违反规则的能力很有限。 部分原因是休闲游戏的规则不够详尽，部分原因是没有人玩游戏会接受其他玩家的这种判断。 + +## 最终推荐的游戏是一致的 + +这在游戏中发挥了客观的第三方裁判的作用。 或称他们为[裁判](http://en.wikipedia.org/wiki/Referee)。 裁判员可以制定更加详尽的规则集，因为只有专业人士才能了解所有规则并具有运用规则的技能。 + +在游戏中增加独立裁判员也可以使事情变得更加微妙，从某种意义上说，所有值最终都收敛于正确的值，这使得游戏成为[最终保持一致](http://en.wikipedia.org/wiki/Eventual_consistency)。 这是考虑引荐游戏的有趣方式。 + +游戏状态是上述值，可以通过在场上的游戏进行修改，但是可以说，这些更改不是已提交的事务。 裁判员可以使用相当于[补偿交易](http://en.wikipedia.org/wiki/Compensating_transaction)的补偿来弥补可能的违规行为，从而可能改变比赛状态。 + +例如，在 NFL 中，裁判决定球的放置位置，时间，得分，顺序以及通常在球场上发生的所有其他事情。 裁判需要告诉您比赛中实际发生的事情，他们需要确定认可系统中的可见性的东西。 + +思考裁判的另一种方法是，它们充当[寻求原谅编程](http://highscalability.com/blog/2012/3/6/ask-for-forgiveness-programming-or-how-well-program-1000-cor.html)中描述的**读取和修复**机制。 这篇文章展示了我们如何有效地对具有 1000 多个内核的处理器进行编程。 这个想法是让所有这些内核同时，并行运行，然后通过后台任务不断使答案更接近正确性，这些任务负责找出问题所在并进行调整。 + +这听起来不像游戏在肉类世界中的运作方式明显吗？ 在游戏中，每个实体（球员，教练，裁判员，摄像机等）都是网络中连接的核心。 消息是通过手势或无线电信号进行的口头表达。 播放映射到协议。 + +在游戏中，由于实体的动作，状态在核心之间流动。 一些活动直接关联。 有些是间接链接的。 有些是独立的。 + +参加复杂的 NFL 比赛。 放一个球（或者是什么？），有一个拦截（在那里？），然后将球弄乱了（或者是吗？），又有一个忽悠了（或者在那里？），有人捡起球并跑了 在 TD。 最重要的是，该剧在该领域的完全不同的部分上有两个标志。 + +剧中到底发生了什么？ + +为了决定裁判们是否达到法定人数。 在解决冲突会议之后，这可能根本不会花费时间，也可能永远不会消失，裁判将得出结论。 裁判本质上是在阅读他们头脑中的“日志”中的事件，确定顺序，将事件与规则进行比较，确定哪些规则适用，哪些规则优先，然后确定正式发生了什么。 + +一旦确定，新游戏状态即已提交。 将通过补偿交易进行必要的维修。 可能会标出 15 码的罚款。 也许已经宣布了一个转身，球现在属于另一支球队。 裁判可以断定数百种潜在结果。 裁判说的是法律。 + +注意，像软件一样，正确性的代价是增加了延迟。 无裁判系统的延迟时间最短，因为比赛结束后，比赛不会停止，无法解决问题。 有了裁判，潜伏期有了巨大的飞跃。 决定处罚并实施任何更正需要大量时间。 + +裁判说的是真的吗？ 这是一个关于“真相”的深刻问题，我们将完全忽略。 任何球迷当然不会告诉你的。 裁判一直吹牛。 但这没关系。 在游戏中（例如在数据库中），在解决冲突后，合并结果变为新状态。 没有更高的权威。 + +## 视频创建了可以挑战的共享内存日志 + +可是等等。 NFL 已经开发了一种**质询机制**，因此可以在事后查看通话。 教练发出红旗，并且将再次检查最后一次提交的事务，以查看是否犯了错误。 其他运动也有类似的机制。 + +挑战系统是**技术创新**的结果。 录制了游戏之后，就可以记录下来并在以后重播。 视频在时空上扩展并解耦了事件的“日志”。 在太空中，因为可以观看比赛的角度数量仅受摄像机数量的限制。 及时播放，因为可以在慢动作中实时或实时查看播放。 + +有了这个新工具，裁判员可以在几十年前完成几乎无法想象的事情，他们可以在一场比赛结束后再看一眼。 即时重播诞生了！ + +如果裁判在看比赛时发现打错了电话，他们将发出更多命令以纠正引起的任何问题，从而使比赛进入更加正确和一致的状态。 使用**读取修复**并补偿事务以解决问题的一个好例子。 + +重播后更改游戏状态就像 Amazon 出售系统认为可用但实际上缺货的商品一样。 如果您购买了缺货商品，世界会终结吗？ 一点也不。 亚马逊会礼貌地通知您，该产品不再可用，您的订单已撤消。 对于亚马逊而言，获得销售要比每次犯错和改正错误更有利可图。 在比赛结束后，让比赛实时展开在场上也是值得的。 + +通常情况下，裁判员发出的用于解决先前问题的命令本身不可审查。 尽管许多体育运动都有一个上诉程序，联盟办公室可以先看电话然后说是，但裁判员犯了错，但是我们对此无能为力。 有时，极少数情况下，挑战会导致游戏从错误通话的角度重新开始。 + +在抗议之后，旧金山巨人队和芝加哥小熊队之间的最近一场比赛重新开始[。 这场比赛是在小熊队主场进行的，由于场地上的一些设备问题而被称为。 巨人当时正在输球，所以对他们来说这将是巨大的损失。 巨人上诉。 并荣获。 装备问题会给主队带来不当的胜利，这种力量被认为是不公平的。](http://espn.go.com/chicago/mlb/story/_/id/11384538/san-francisco-giants-win-appeal-finish-game-vs-chicago-cubs) + +**正义不是上诉系统**的目标。 玩完游戏后很少能解决问题。 可能会发送道歉信。 也许规则委员会将在明年研究改变规则。 也许可以减少罚款或取消暂停。 亚马逊可能会在您下次购买时给您折扣。 但是通常，一旦响起最后的哨声，便确定了游戏状态，并且游戏交易以成功返回码返回。 + +到目前为止，在运动场上发生的事情与计算机科学中发生的事情之间存在着一些有趣的相似之处。 这是因为在所有引用的系统下都是**通用结构。** 有规则，状态，活动和裁判员，他们解释如何将规则应用于状态活动的结果。 + +数据库只是一大类引用系统的示例。 房屋检查，审判，经过同行审查的学术论文，保险索赔调整，参加比赛的电影-只有在法官说出自己的真实情况时才有意义。 + +请注意，即时重播延迟又增加了。 观看视频要花费很多时间，比没有裁判员系统甚至只有裁判员系统的时间要多得多。 + +## 更多技术意味着更多正确处理事情-集中式系统 + +技术在未来飞跃发展，并拖累了社会。 + +摄像头和视频回放是实现现场即时回放的技术。 形成我认为的联合架构。 每个游戏都是自治的和分散的组织，但是规则和信息在游戏之间共享。 + +自从开始重放以来，我们已经看到了**快速互联网**的发明，功能强大的计算机，甚至还有更多的野外摄像头，以及创建复杂软件的能力。 因此，可以立即发明一种新的即时重放方式。 是的。 这次它使用集中式体系结构。 实际上，NBA，NHL，MLB 和 NFL 都已经转移到集中式即时重播方法，或者正在转移到一种。 + +这个想法很简单。 现在，可以将**的每个游戏**传输到中央运营中心，该中心可以让专门的专家团队观看视频并查看通话。 + +再次注意，集中式即时重放延迟又增加了。 现在，我们必须去中央重放中心进行判断。 我们真的必须认为正确性很重要吗？ + +## 游戏外的读取和修复机制 + +即时重放并不是唯一可用的读取和修复机制。 + +例如，在棒球和橄榄球中，比赛统计之后经常对比赛统计数据进行校正。 并非所有内容都可以在游戏环境中正确列出。 例如，稍微反射一下，一个麻袋可能会变成一个完整的麻袋。 + +场地上发生了很多事情，所以即使裁判员也看不到所有令人讨厌的事情。 这就是为什么存在**精细机制**的原因。 即使未在游戏中要求罚款，也可以在比赛结束后对背景一致性进行罚款。 + +## 深度学习，无人机，传感器和更多摄像头-混合还是闭环？ + +技术的下一次发展可能涉及**先进的机器人**，**深度学习系统**，甚至还有**更多的摄像机**，因为传感器和无人机将覆盖整个领域。 您可以想象有 1000 个摄像机覆盖每个游戏，而 AI 则在每个流中检查是否存在违规行为。 游戏的 AI 可以对违规行为进行投票，并以最高的信心将这些呼叫冒出来，直至引起人们的注意。 人类可能会做出最后决定，也可能不会做出决定。 + +网球中目前使用机器人作为[电子线路裁判](http://en.wikipedia.org/wiki/Electronic_line_judge)。 + +有些机器人可以在棒球中叫[球，对](http://bleacherreport.com/articles/1942413-should-major-league-baseball-ever-bother-with-a-robotic-strike-zone)进行击打，但是由于棒球具有使用裁判员的悠久传统，因此没有被使用。 + +**人类自负**将决定如何使用下一代技术。 如果体育中的人为因素被重视超过正确性，那么可能会发展出一种混合系统，该系统在概念上与现代软件系统有很多共同点。 我们仍然会有人工裁判，机器人会选择他们的位置。 集中的 AI 中介组件将承担大部分繁重的工作，而人工将在适当时提供监督。 毕竟，人类仍然必须感到重要。 + +技术趋于发展。 因此，如果有一点技术增加了系统延迟，并且将精力从分散的架构转移到了集中式架构，那么更多的技术可能会逆转这些发展。 + +一个闭环系统，每个运动场都有自己的摄像头和自己的 AI，其中 AI 可以直接拨打电话，这将创建一个低延迟系统，与无裁判系统相当，并且完全删除了集中式组件。 **每个游戏都会再次变得快速且分散**。 + +无论系统多么复杂，在我们眼中，我们始终会知道真正发生了什么。 + +## 相关文章 + +* [经进一步审核：即时重播的简要历史记录](http://mentalfloss.com/article/26075/upon-further-review-brief-history-instant-replay) + +* [为什么所有体育活动都不使用 NHL 的“控制室”重播审核系统？](http://www.thesportsfanjournal.com/columns/the-rev/all-sports-should-use-the-nhl-control-room-replay-review-system) + +* [对 NFL 重播系统](http://espn.go.com/nfl/story/_/id/10670707/nfl-owners-allow-centralized-system-aid-instant-replay)所做的更改 + +* [特殊报告：在 NHL 的中央视频审核操作中。 它可以在 NFL 中使用吗？ 通过调整，可以确定](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/) + +* [美国职业棒球大联盟必须求助于 NHL 风格的即时重播系统，以解决问题](http://bleacherreport.com/articles/1634267-mlb-must-turn-to-nhl-style-instant-replay-system-to-fix-umpiring) + +* [球员，裁判员现在比以往更需要重播](http://sports.yahoo.com/news/players--umpires-need-replay-now-more-than-ever.html) + +* [如何结束棒球史诗般的主持人改组：使用即时重播裁判员](http://www.theatlantic.com/entertainment/archive/2013/05/how-to-end-baseballs-epic-officiating-screwups-use-instant-replay-umpires/275726/)-反映组织的结构和文化。 + +* [彼得·加蒙斯（Peter Gammons）：忽略重播的天使埃尔南德斯（Angel Hernandez Blew）打电话了](http://deadspin.com/peter-gammons-angel-hernandez-blew-that-call-after-ign-499913975) + +* [美国职业棒球大联盟（MLB）的胡扯重播技术：曾经获得通话权的奇迹之王](http://deadspin.com/mlbs-crappy-replay-tech-its-a-miracle-umps-ever-get-499041275) + +* [小心您想要的东西](http://www.sportsonearth.com/article/70183162/major-league-baseball-instant-replay-may-be-overwhelming)-想您知道如何观看棒球比赛吗？ 只需等到从每个可能的角度进行其他重放即可。 （美联社） + +* [MLB 2014：棒球的即时重播如何工作？](http://online.wsj.com/news/articles/SB10001424052702304688104579465230759769104) + +* [“在我叫它之前什么都没有！”](http://bill37mccurdy.wordpress.com/2010/08/23/it-aint-nothing-until-i-call-it/) -有关如何通过在球场上让裁判神神拯救棒球的故事。 + +* [要求宽恕编程-或我们将如何编程 1000 个内核](http://highscalability.com/blog/2012/3/6/ask-for-forgiveness-programming-or-how-well-program-1000-cor.html) + +* [您实际上使用 NoSQL 的目的是什么？](http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html) + +多么手淫 \ No newline at end of file diff --git a/docs/152.md b/docs/152.md index b8f01ec..9ce457b 100644 --- a/docs/152.md +++ b/docs/152.md @@ -1,95 +1,135 @@ -# iDoneThis-从头开始扩展基于电子邮件的应用程序 +# Instagram 提高了其应用程序的性能。 这是如何做。 -> 原文： [http://highscalability.com/blog/2012/6/20/idonethis-scaling-an-email-based-app-from-scratch.html](http://highscalability.com/blog/2012/6/20/idonethis-scaling-an-email-based-app-from-scratch.html) +> 原文： [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) -![](img/d32057557a700194022c0bb38a729ee5.png) +![](img/e7b70a6c02b1e7425849dd6d1af801f2.png) -*这是 [iDoneThis](http://idonethis.com) 的首席技术官 Rodrigo Guzman 的来宾帖子，它使您的公司状态报告可以最轻松地进行。* +[平面设计](http://en.wikipedia.org/wiki/Flat_UI_Design)只是另一张漂亮的面孔，还是作为 UI 革命掩盖的巨大性能突破？ 事实证明，扁平化设计是赢得冷战的坚石。 -**iDoneThis** 是一个简单的管理应用程序，每天结束时都会通过电子邮件向您的团队发送电子邮件，询问您：“今天您做了什么？” 只需回答几行即可完成。 第二天早上，您团队中的每个人都了解了团队在前一天的成就，以使每个人都参与其中，并开始新的一天。 +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 进行，主题是如何为全球范围内的移动应用程序设计现实，与美国相比，这种手机的速度较慢，屏幕较小，网络速度较慢。 。 -在我们推出之前，我们在一个周末以最基本的方式构建了 iDoneThis。 不好意思，我们使用 Gmail 收件箱的“密件抄送”字段发送了前几批每日电子邮件。 结果是，从网站存在的第 3 天开始，我们就已经在该网站上吸引了用户。 +为典型的手机而不是高端手机进行设计需要 Instagram 团队深入思考其设计。 泰勒（Tyler）演讲的启示之一是**向平面设计**的转移极大地提高了应用程序的美观性，可用性和实用性，并且极大地提高了性能。 -从 2011 年 1 月推出以来，我们每天手动发送数百封电子邮件，到每月发送超过 100 万封电子邮件和处理超过 20 万封传入电子邮件。 总共，客户记录了 170 万次完成。 +这真是一个惊喜。 我只是将平面设计视为思考如何构建漂亮的 UI 的一种方式。 傻我 感谢泰勒（Tyler）如此清晰，有力地解释了平面设计的好处，并使用 Instagram 作为可能的典范。 -## 统计资料 +平面设计是反拟态的，它是数字化本地人，避免了对现实外观的痴迷，采用简单的元素，简单的版式，平面颜色和简单的设计。 -* 每天 1 万封入站电子邮件 -* 每天发送 40k 电子邮件，其中大部分发生在美国高峰时段，时间是美国的 6 便士，预计会如期到达。 -* 每秒几个 Web 请求，突发。 Web 服务器大部分闲置。 -* 1GB 的用户内容，5GB 的数据库 -* 为文档建立索引以进行实时搜索 -* 所有这些都使用单个 xlarge EC2 实例处理。 +使用平面设计，Instagram 可以从冷启动时间缩短 120 毫秒。 它还能够将显示提要屏幕所需的资产数量从 29 个减少到 8 个。 同时，使应用程序更美观，更易用，并更加关注不同手机尺寸的内容。 -## 叠放 +平面设计如何使这一切成为可能？ -* python 几乎所有内容 -* django 用于网络界面 -* apache + mod_wsgi -* PostgreSQL -* 传入的电子邮件由 sendgrid 解析 API 和内部用 python 编写的自定义电子邮件处理器处理 -* coffeescript，骨干，jquery 和 sass -* lucene + solr 用于在码头实例后面搜索运行 +## 转向平面设计 -## 电子邮件-从 Gmail 到 SendGrid +* Instagram 改写了他们的 UI，以专注于 Android 上提供的各种 UI 的更好性能。 -我们从 Gmail 中的密件抄送开始，因为如果我们从应用程序服务器发送电子邮件，则它们都将被标记为垃圾邮件。 Mailchimp 不允许我们在电子邮件中进行大量更改，因为它是为传统电子邮件营销而构建的。 +* Instagram 于 2012 年在 Android 上发布时，它是由 3 个人在大约 4 个月内建成的。 两名工程师和一名设计师。 Android 版本使用与 iOS 版本相同的设计。 -当令人惊讶的是，成百上千的人注册了该服务时，我们使用 [SendGrid](http://sendgrid.com) 在 cronjob 上切换到了自定义脚本（“ sendmail”）。 Sendmail 是我们今天仍然使用的，通过迭代改进来处理出现的错误情况。 +* 该设计使用了甜美的渐变色和许多 UI 元素。 -它曾经每周崩溃一次，现在几乎从未发生过。 为了实现这一目标，sendmail 从简单的 for 循环变为使用数据库来跟踪每封电子邮件的状态，并具有可以优雅地处理不同状态转换的逻辑。 不过，起初让它成为一个简单的 for 循环对我们很有帮助-在观察了所有常见的失败方式之后，设计机械使其可靠的要容易得多。 +* 向 iOS7 过渡到平面设计，使产品变得更加简单和美观。 没有更多的渐变。 拿出箱子。 没有更多的阴影。 -为了处理传入的电子邮件，我们从 200 行脚本（称为“ getmail”）开始，以通过 IMAP 访问 Gmail 收件箱。 该过程不可靠，在引发异常后会使数据库处于不良状态，因此必须由保姆亲自操作。 不仅如此，还要有人从条目中删除不需要的行（签名，回复文本等）。 我们使用标准库构建了一个传入解析器，这使我们的 getmail 过程更加可靠。 800 行 Python 代码非常混乱，这些 Python 代码专用于正确处理编码，部分和启发式方法，从而使不需要的行成为可能。 +* 他们从适应平面设计**的经验中学到了**： -我们从 getmail 迁移到 SendGrid 的传入解析 API，该 API 基本上将传入电子邮件转换为 HTTP POST 请求，因此我们只需要担心编写 Web 应用程序。 我们之所以进行切换是因为由于 Google 的速率限制，getmail 无法足够快地处理传入的电子邮件。 更糟糕的是，getmail 的设计目的不是让它同时运行多个副本，当传入电子邮件的速率太大时，getmail 会开始引发很多问题。 + * **平面设计是减少**，更快开发代码和更快交付产品的机会。 这对开发人员来说很棒。 -## 扩展流程 + * **平面设计的性能更高**。 开发人员不仅做得更少，而且手机在显示 UI 方面也做得更少。 -可伸缩性是一件有趣的事。 早期，我们面临的主要瓶颈本身不是技术性的，而是开发人员的时间-面对大量电子邮件，这仅仅是我的问题！ 今天基本上也是这样。 这意味着性能和可伸缩性基于代码设计中的简单性，周到的抽象性和敏捷性的原则。 +* 使用从 iOS7 平面设计重新设计中学到的新 Android 版本的目标： -首先要毫不留情地将功能范围限制到最低限度或将其全部外包。 只有在该功能发布并且我们看到它被使用后，我们才对其进行优化以确保其性能（例如，我们添加了 [Celery](http://celeryproject.org/) 以异步发送通知电子邮件，之后该通知已成为 UX 的重要组成部分） 。 + * **使其平坦，使其更快**。 这不是重写。 导航模式没有改变。 -其次，使代码尽可能简单（写和读）。 这通常涉及牺牲性能。 例如，对于复杂的查询，ORM 并不总是产生最高效的 SQL，但是我们将其搁置一旁，直到该功能投入生产为止。 诚然，这导致了一些尴尬的时刻，但是更多的时候它使我们远离过早的优化，并且我们的代码库相对干净并且易于使用。 + * **注意屏幕空间**。 重新浏览每个屏幕，并弄清楚如何更好地适应所有屏幕尺寸。 -随着传入和传出电子邮件的数量增加，我们考虑切换到多服务器体系结构。 但是，这开始给我们的连续部署库增加了很多复杂性。 因此，我们没有进行优化，而是购买了一台更大的计算机，并构建了一个负载和性能监视系统。 当前，iDoneThis 在单个 xlarge EC2 实例上运行。 我们可以通过做一些工作来摆脱一些小实例，但我们更愿意为简单起见和开发人员时间进行优化。 + * **变得漂亮**。 这是他们在 Instagram 上所做的一切的基础。 -但是，我们流程中最重要的部分可能是我们拥有非常好的连续部署。 每个开发人员都可以使用一个简短的命令将 git repo 的任何分支部署到生产中，该过程需要几秒钟。 这意味着生产中和我们开发中的产品永远不会有太大差异。 这也意味着我们可以在实时观察发生的情况后快速进行迭代。 +* 总体效果是极大的简化。 进行了哪些更改？ -## 重新构建现代网络 + * **将所有内容从 Chrome** 中删除。 拿出所有渐变和光泽按钮。 去勾勒形状而不是图标的渐变按钮。 剩下的是纯色和扁平形状。 希望用户界面淡入背景。 -iDoneThis 的 Web 界面最初是一个非常简单的 Django 项目。 只是一些模型，视图和模板。 随着产品的发展，我们继续采用 Web 应用程序开发的旧范式：所有事情都与页面加载和表单提交有关。 这在一段时间内为我们提供了很好的服务，但是当我们的用户将数据放入我们的系统时，他们需要更好的界面来访问它。 + * **拿出注释图标**，使注释全屏显示，为注释文本留出更多空间。 使内容在屏幕上脱颖而出。 用户界面越少，使用小屏幕的人就有更多的空间阅读文本。 -我们慢慢开始堆积 jQuery 意大利面条以及支持它的后端功能。 结果是一团糟。 一种有效，但是很难调试和迭代。 + * **分叉了用于拍照的手机布局**。 在小型电话上，他们使用在屏幕顶部带有动作按钮的设计。 对于较大的屏幕，所有命令都在底部。 -同样，选择只引入绝对必要的复杂性，我们使用 CoffeeScript 和 Backbone.js 重新编写了前端，从而产生了更易管理的组织代码。 当我们采取这一步骤时，我们很大程度上将后端留给了自己，仅根据需要添加了对前端新功能的支持。 事实证明这是有问题的。 + * **删除了整个应用程序不必要的 UI，以使内容更加集中**。 搜索屏幕上的三层铬减少到两层。 这在小型电话上腾出了很多空间。 由于三星 Galaxy 的按钮纤薄，采用扁平化设计很容易以编程方式进行操作，从而为内容腾出了很多空间。 -由于 iDoneThis 主要基于电子邮件，后来又推出了 iPhone 应用程序，因此我们最终获得了三个用于用户数据 I / O 的渠道：电子邮件，Web 和 iPhone 应用程序-每个渠道都有其自己的细微差别。 对我们来说，这使得我们的一些用户交互和流程不能像您在普通网络应用程序上所期望的那样完全正常工作，而 Django 抽象使这种工作变得容易。 例如，当一个用户被邀请加入一个团队时，他开始接收来自我们的电子邮件，并且可以像其他任何人一样回复它们，但是他从未访问过该站点来设置帐户。 + * 请注意，演讲中有很多关于不同设计的精美图片，因此非常值得观看之前和之后的图片。 -随着我们构建后端以支持所有这些功能，代码变得越来越不规则。 我们尽可能地接受 TDD 来帮助解决这一问题，但更重要的是，我们决定切换到基于 API 的体系结构-我们仍在进行此切换。 +## 为什么要进行平面设计？ -看起来，方式是 Django 后端主要由两个组件组成：一个负责提供可由 Backbone.js 和 iPhone 应用程序使用的 json API，以及一组负责提供给前端的简单视图和模板。 代码和 html 占位符。 +* **使用资产着色**运送更少的资产。 这意味着 APK 的大小较小，这在小型网络上非常有用。 魔术是**资产着色** **（**我以前从未听说过）。 [资产着色](http://blog.danlew.net/2014/08/18/fast-android-asset-theming-with-colorfilter/)表示资产（在这种情况下为图像）可以通过程序进行着色。 例如，可以通过编程方式将灰色的心脏染成红色。 资产着色意味着需要运输的资产更少。 传统上，每种按钮状态（按下，未按下，选择等）都需要单独的图像。通过着色，可以将不同状态的所有图像都不再需要运送了。 仅需要图像，并且可以设置不同的状态。 -到目前为止，用这种风格编写的代码比老式的代码要简单得多，并且更易于测试。 但是，弄清进行切换的来龙去脉是一笔相当大的时间投资，因为 django 并不是针对这种范例而设计的。 新代码更简洁的事实使我认为，最终它们在迭代速度方面都将获得回报。 +* **加载更少的资产**。 这意味着 UI 显示速度更快，并且用于存储位图的内存更少。 必须从闪存中读取每个需要显示的资产，并将其解码为位图。 完成的次数越少，应用程序变得越快。 -## 得到教训 +* **更快的迭代时间**。 如果您要更改颜色或进行新开发，则不再需要设计师。 只需更改代码并重新编译即可。 + +* 结果： + + * **在进行平面设计之前，需要 29 种不同的资源来显示供稿屏幕**。 平面设计后， **8 个资产**显示同一页面。 仅需要形状即可显示图标和徽标。 其他所有内容均以代码形式绘制为纯色和矩形。 仅仅是从所有设备的冷启动时间起将**缩短了 120ms** 。 + + * **采用扁平化设计，整个应用变得更快**。 每个屏幕的工作量都减少了。 更少的资产被加载，整个应用变得更加生气。 评论中的用户评论了应用程序在重新设计后的感觉。 人们真的很喜欢它。 人们赞赏与平台匹配的设计所带来的速度提升。 + +## 缩短冷启动时间 + +* 冷启动时间是应用程序启动并变得响应所需的时间。 从点击图标到在应用程序周围单击，它均有效。 我们的目标是让**应用能够超快速地启动**，以便使用低端手机的用户拥有丰富的体验。 + +* 几年前，在低端 Galaxy Y 上，Instagram 的启动时间为 3 秒。 在高端 Galaxy S5 上，启动时间为 750 毫秒。 + +* 现在，在 Galaxy Y 上，Instagram 需要 1.5 秒才能启动。 在 Galaxy S5 上，需要花费 **400 毫秒**。 + +* 怎么样？ （除去资产） + + * **对应用程序**进行配置。 + + * 找出导致应用速度下降的原因。 + + * 在 Android 上，您可以使用**方法跟踪**，并且可以在代码中放置计时语句。 方法跟踪数较小的方法。 **时序声明**是墙上时钟时间，而不是机器时间。 同时使用这两种功能可以让您对缓慢的情况有良好的感觉。 + + * **解决最慢的问题**。 -* **外包辛勤工作，尽可能外包**。 即使对于基于电子邮件的产品，也要对发送和接收的电子邮件都使用 sendgrid，这就是我们要做的。 当然，在某些时候，内部做这些事情是有意义的，但是对于一家初创公司而言，那一点可能就是 t =无穷大。 -* **性能上的简化**：我们可能会放弃使用较小的 EC2 实例并使用 nginx，但是使用 mod_wsgi 的默认 apache 配置工作得很好，并且更易于自动化。 我们经常做这样的事情：让最简单最容易的事情出现，担心它的性能，然后再进行抛光。 -* 短时间内，我们朝着将组件拆分为在其自己的服务器中运行的方向发展。 这开始造成的麻烦超出其应有的价值，因此，我们最终获得了**单个 EC2 实例**。 + * **延迟加载**。 从冷启动路径中删除项目。 + + * **重写慢速代码**。 例如，慢速 JSON 解析代码被重写为更快。 + + * **延迟到后台线程**。 不要在 UI 线程中执行操作，而可以在后台执行。 + + * **迭代**。 再次开始配置文件步骤。 + +* **应用范围内的单身人士发现速度很慢**。 通过计时发现。 + + * 在应用启动之前，已经启动了许多**重单例**：HTTP 客户端，Cookie 存储，图像缓存，视频缓存。 确实不需要这些东西即可向用户显示用户界面。 它们可以并行加载到后台。 + + * **两部分延迟加载** + + * 想要**在后台**中初始化单例，但程序员仍将其视为始终可用于该应用的单例。 不想让程序员必须检查单例是否可用，因为那不是单例。 + + * **在 UI 线程**上创建足够的对象，以便公共 API 完全起作用，并且可供程序员使用。 将艰苦的工作推迟到后台线程。 对于高速缓存，这意味着打开和读取磁盘存储。 对于客户端，证书将在后台加载。 Cookies 在后台反序列化和解码。 通过这些更改，UI 可以更快地出现在屏幕上。 + +* **Newsview 运行缓慢**。 通过方法跟踪找到。 + + * 新闻视图最初显示为网络视图，其中显示了您的所有喜欢和评论。 需要在启动时加载它以尽快向用户显示其数据。 + + * 问题是无法控制 Webview。 它具有自己的堆栈和缓存系统。 **将其转换为本地**。 花了 2-4 周的时间。 原始转换后，冷启动时间将**降低了 30％**。 + +## 得到教训 -单个 EC2 实例使我感到恐惧。 当您丢失该实例时会发生什么？ +* **可以实现快速的冷启动时间**。 如果他们很快，他们甚至会变得更快。 剖析，修复，迭代。 -@布兰登：我认为他们应该有某种备份，并有恢复计划。 -即使您有多个实例，也存在“丢失实例”问题。 归结为拥有可恢复的备份。 +* **谨慎使用像素**。 查看每个屏幕，查看不需要的内容。 与美国相比，其他国家/地区的用户使用的手机要小得多。 -很抱歉...一个 5GB 的数据库和每秒几个 Web 请求*这些天*是“高可扩展性”？ 新闻日慢多少？ +* 移动电话喜欢简单的设计，移动开发人员也喜欢。 这要容易得多，也要快得多。 -那么，告诉我，如何运行单个 EC2 实例“可伸缩”？ +## 相关文章 -@Hrish：备份将使您得以恢复，但它们并不会采取任何措施来防止服务中断。 +* [在 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) -AWS 有时会发生中断，但是它们几乎总是被隔离到一个实例区域中-也就是说，区域故障彼此独立。 如果任何区域发生故障的概率为 p，则由于区域发生故障而导致单个实例设置脱机的概率也为 p。 但是，如果应用程序是从两个区域提供服务的，并且可以在那些区域之一的消失中幸存下来，则应用程序因区域故障而脱机的可能性为 p ^ 2。 通过扩展到第二个可用性区域，可以将故障风险降低一个数量级。 +我发现有趣的是，这种平面设计运动是由 Microsoft 与 Windows Phone 一起发起的。 +总是会有更多的高档用户界面（如游戏中），但从总体上看，功能正在取代形式。 我喜欢那个。 -使用 Django 应用程序，这应该相当容易。 Web 服务器不应存储状态，因此丢失服务器不会使应用程序脱机。 可以使用 Elastic Load Balancer 来放置 Web 服务器的前端，而 ELB 可以在区域中断中幸存下来。 可以跨区域以镜像配置设置 PostgreSQL，或者可以将 PostgreSQL 换成 MySQL，并为数据库使用多可用区 RDS 实例。 +它以功能为基础，对我有很多帮助。 直到观看了这个出色的演示，我才知道平面设计是什么。 现在，在许多不同的层次上它变得更加有意义。 -对于像我们在 6 月 14 日看到的那样的故障可以恢复的应用程序，差异可能是每月数百美元。 \ No newline at end of file +正如文章所提出的那样，功能必须战胜视觉障碍。 但是作为仍然使用 iOS6.1.3 的匕首，我必须要求您承认，自 iOS7 以来，奇怪而与众不同的选择令人困惑：白色文本的鲜绿色背景，窄字体，细腻的灰色阴影以及总体而言太多了 屏幕上呈鲜亮的白色，而对于发现此效果实际上令人痛苦的用户则无能为力。 而且，即使使用 iOS8.0.2，提供的修改也是如此之小，以至于令人怀疑。 +好吧，渐变对处理程序征税-如果处理器不能比程序员领先一步，就消除渐变。 但是至少要为用户提供背景颜色选项。 给一些真实的对比度控制。 为需要的人提供一些粗细的字体。 +我们生活在一个这样的世界中，所有用户都将以正确的视线来到餐桌上，这一假设和期望越来越普遍。 但这是一个精英主义的假设。 使它精简，使其快速，但不要把我们中的很多人甩在后面。 \ No newline at end of file diff --git a/docs/153.md b/docs/153.md index c782757..04fbed4 100644 --- a/docs/153.md +++ b/docs/153.md @@ -1,63 +1,126 @@ -# 搜索技术剖析：使用组合器爬行 +# Clay.io 如何使用 AWS，Docker，HAProxy 和 Lots 建立其 10 倍架构 -> 原文： [http://highscalability.com/blog/2012/5/28/the-anatomy-of-search-technology-crawling-using-combinators.html](http://highscalability.com/blog/2012/5/28/the-anatomy-of-search-technology-crawling-using-combinators.html) +> 原文： [http://highscalability.com/blog/2014/10/6/how-clayio-built-their-10x-architecture-using-aws-docker-hap.html](http://highscalability.com/blog/2014/10/6/how-clayio-built-their-10x-architecture-using-aws-docker-hap.html) -![](img/36ab01ea97bfa8e04f1ca36ac0ea0183.png) +*这是 [Zoli Kahan](http://insignia.zolmeister.com/#/) 来自 [Clay.io](http://clay.io/) 的[客人转发。](http://zolmeister.com/)* -*这是垃圾邮件免费搜索引擎 blekko 的首席技术官 Greg Lindahl 撰​​写的系列文章中的第二个来宾帖子（[第 1 部分](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html )，[第 3 部分](http://highscalability.com/blog/2012/7/9/data-replication-in-nosql-databases.html)）。 之前，Greg 是 PathScale 的创始人兼杰出工程师，当时他是 InfiniPath 低延迟 InfiniBand HCA 的架构师，该架构用于构建紧密耦合的超级计算集群。* +![](img/cd6b3aa23bad6407251bf52fac9d1a68.png) -## 搜寻网路有什么困难？ +这是我的新系列`10x`中的第一篇文章，我在 [Clay.io](http://clay.io/) 中分享我的经验以及如何做事，以与一个小组一起大规模发展。 如果您觉得这些事情有趣，我们正在招聘- [[受电子邮件保护]](/cdn-cgi/l/email-protection) -Web 搜寻器的存在时间与 Web 差不多，在网络出现之前，就存在用于 gopher 和 ftp 的搜寻器。 您可能会认为 25 年的经验将使您能够解决已解决的问题，但是网络的迅猛发展以及垃圾邮件技术和其他不良内容的新发明不断带来新的挑战。 紧密耦合的并行编程的普遍困难也抬起了头，因为网络已从数百万个页面扩展到数千亿个页面。 +## 云端 -## 现有的开源爬网程序和爬网 +### 云耀斑 -本文主要讨论 blekko 的搜寻器及其组合器的用法，但是，如果您想对搜寻的困难部分进行更一般的介绍，建议您查看以下内容： +[![CloudFlare](img/7b159cb72a76c78e5442df11e7e0f8dd.png)](https://www.cloudflare.com/) -* [信息检索简介](http://nlp.stanford.edu/IR-book/) -* [Apache Nutch](http://nutch.apache.org/) 开源搜寻器 -* 来自 [](http://archive.org/) 的开源抓取工具 [Heritrix](http://crawler.archive.org/) -* [50 亿页](http://archive.org/) [常见爬网](http://commoncrawl.org/) +[CloudFlare](https://www.cloudflare.com/) 处理我们所有的 DNS，并充当具有某些其他 DDOS 保护功能的分布式缓存代理。 它还处理 SSL。 -## 定向爬行 +### Amazon EC2 + VPC + NAT 服务器 -打算不对整个 Web 进行爬网的爬网程序的最重要功能是仅对最重要的页面进行爬网的能力。 有传言称，谷歌的网络爬虫和索引超过了 1000 亿个网页，而谷歌在 2008 年宣布其“爬虫前沿”（他们在其他网页上看到的所有网址的列表）已经结束。 +[![Amazon Web Services](img/4d99eeaece9082339db02fb5f4acd2f6.png)](http://aws.amazon.com/) -blekko 知道我们只想为仅数十亿个网页的索引编制索引并提供结果。 那只是 Google 抓取边界中网页的一小部分，因此我们需要非常擅长抓取最好的页面，并且只抓取最好的页面。 一种方法是在爬网时计算网页的排名，包括尚未爬网的页面的排名。 +我们几乎所有服务器都生活在 Amazon EC2 上，其中大多数是中型或大型实例。 我们还使用 Amazon VPC 将我们的某些服务器托管在外部无法访问的专用网络中。 为了进入这个专用网络，我们有一个 NAT 服务器，它也用作我们的 VPN 端点，在与内部网络配合使用时使用。 （[指南](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html)， [OpenVPN](https://openvpn.net/index.php/open-source/documentation/howto.html) ） -页面的等级取决于传入链接的数量和质量，以及许多其他页面上的度量，例如页面上的文字，与文字数量相比的广告数量等等。 在首次抓取页面之前无法知道页面上的度量值，但是从抓取其他页面开始就可以知道传入的链接。 +### 亚马逊 S3 -当然，使用入站链接对网页进行排名是很多互联网垃圾邮件发送者已经精心设计的方法。 这些虚假链接中的一些来自其他垃圾邮件发送者网站，而某些来自具有合理内容的合法网站。 我有一堆关于各种主题的旧的，排名靠前的网页，而且我收到了无穷无尽的“链接交易”电子邮件，这些电子邮件大多是由自动执行链接交易游戏的软件包发送的。 查找和忽略来自合法网站的错误链接要困难得多，而且通常要等到许多链接页面被完全爬网后才能完成。 +我们将 Amazon S3 用作 CDN 后端，该后端托管了我们的所有静态内容。 为此，我们使用一个单独的域：`cdn.wtf`（出于安全和性能方面的考虑）（无 cookie 的域）。 -## 组合器 +### HAProxy -现在，让我们看看**组合器**（我们在[先前的博客文章](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html)中进行了讨论）如何使这些计算变得更加容易。 +[HAProxy](http://www.haproxy.org/) 是一种性能卓越的反向代理，可用于将流量路由到我们的不同服务。 由于 Clay.io 的性质及其对平台支持的关注（以及对遗留代码的支持），这项工作并不轻松，我将在以后的文章中详细介绍。 -首先，我们想对许多事物进行独特计数：传入链接的地理多样性，传入链接的网络多样性等等。 如果所有传入链接都来自同一个 C 类 IP 网络，那么包含大量传入链接的页面就不会那么有趣。 我们使用**对数计数**组合器来有效地计数这些数量（在时间和空间上-每个计数 16 个字节），而不会在我们爬行和重新爬行 Web 时重复计数任何东西。 使用 logcount 的缺点是计数是近似值。 对于一些重要的数量，我们选择 logcount 的变体，它们需要多达 256 个字节的状态，以便更好地近似精确的答案。 +当前，我们在 m3.medium 实例上只有一个 HAProxy 服务器，但是会随着流量的增加而升级。 此外，如有必要，我们可以在前面添加 Amazon ELB 以水平缩放。 -接下来，我们经常需要操纵到网页的传出和传入链接列表。 在大多数关系数据库中，此数据通常由表中的一系列行表示，并且我们将通过查询链接的目的地等于特定 URL 的所有记录来获取此数据。 这是一项昂贵的操作，并且由于入站链接的数量可能很大（在许多情况下为数百万个），因此我们需要某种方式摆脱该表中次重要（排名较低）的行，以便 保持表格大小合理。 +### 应用服务器-Docker -**TopN** 组合器解决了这两个问题。 作为一个有限大小的列表，可以通过一次操作读取它，并且它的大小是自动修整的。 作为我们为什么要在抓取时操作此传入网页列表的示例，请考虑以下事实：交易或购买的链接通常具有相同的[锚文本](http://en.wikipedia.org/wiki/Anchor_text)。 通过在爬网页面之前检查传入的锚文本，我们可以完全避免爬网。 索引时间检查可以发现锚文本的相似性，但是为时已晚，要避免浪费资源对其进行爬网。 +[![Docker](img/0c5a4e266f51da3a4d7f5aae1cc6abd3.png)](https://www.docker.com/) -除了 url 级别的信息外，我们还保留爬网程序所学内容的主机级别摘要。 例如，我们有一个 TopN 摘要以及主机到主机链接的数量。 该摘要对于发现具有大量组内链接的主机组很有用。 我们使用此数据来打折这些链接的价值。 +[Docker](https://www.docker.com/) 是用于管理 Linux 容器的工具，该工具类似于虚拟机，但开销较小（并且没有隔离和安全保证）。 Docker 的关键在于，无论主机看起来如何，容器内部交付的代码都应运行相同的代码。 -## 所有其他的东西 +当前，我们通过 Docker 在`app server`上运行大多数计算服务。 可以轻松地复制该服务器以满足弹性需求，并且可以轻松地上下移动服务。 最终，我们希望使用 Kubernetes 之类的工具来管理这些应用服务器。 （请参阅文章底部） -除了我们已经讨论的内容（查找传出链接并计算未爬网页面的等级）外，blekko 的搜寻器还完成了许多其他工作。 如果在网页上找到日期，则搜寻器会立即将要创建索引的页面发送给其他支持 blekko 的/ date 和/ daterange 功能的索引（有关 blekko 的高级功能，请参阅此 +### 登台 App Server-Docker -## 爬行经验 +我们的登台环境服务器与我们的应用程序服务器相同，并且运行与生产环境中完全相同的 docker 二进制文件。 这种环境对于防止生产系统不必要的损坏和停机至关重要。 -我们在此过程中吸取了一些教训。 一个重要的教训是，至关重要的是，拥有一个电子邮件地址，网站管理员可以在存在抓取工具问题时可以私下与我们联系。 由于此，我们修复了一些错误。 最令人惊讶的是，网站管理员（和主要的抓取工具）未严格遵守 robots.txt 规范，并期望其 robots.txt 中的空白行无效。 我们还发现，很大一部分网站（包括许多美国政府网站）仅允许一小部分爬虫白名单来爬网其页面。 这些网站很多都是很小的，并且没有明显的联系方式联系他们的网站管理员以要求将其添加到白名单中。 +## 数据 -## 未来发展方向 +### 的 MySQL -将来，我们想在爬网系统中添加一件主要的事情：执行 JavaScript 的能力。 越来越多的网络隐藏在 javascript 之后，尽管网站管理员谨慎地将其内容隐藏在大多数搜索引擎无法看到的地方，但许多网站管理员确实有动机隐藏其分析和广告 ID，以便他们 不那么明显。 +[![MySQL](img/526eb85ffee8f9921ad1d216295ced15.png)](http://www.mysql.com/) -## 相关文章 +[MySQL](http://www.mysql.com/) 是生产强化的关系 SQL 数据库。 目前，我们的绝大多数数据都位于主从 MySQL 群集中。 我们有一个主服务器和两个从属服务器，它们为我们的用户提供大部分查询。 最终，我们可能不得不移动表或将单个主服务器分片，但希望一段时间不会。 -* [关于黑客新闻](http://news.ycombinator.com/item?id=4033983) -* [搜索技术剖析：Blekko 的 NoSQL 数据库](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html) +### Logstash -Heritrix 和 Common Crawl 项目的链接周围有些破损。 +[![logstash](img/49b14bb47630fed69c350a87ba95f9aa.png)](http://logstash.net/) -爬网一章的链接已断开。 这是正确的链接：http://nlp.stanford.edu/IR-book/html/htmledition/web-crawling-and-indexes-1.html（看起来连字符可能在错误的位置）。 \ No newline at end of file +[Logstash](http://logstash.net/) 是一种日志聚合工具，具有 Kibana 集成用于分析。 它基本上处理了我们所有的应用程序日志，并为我们提供了在出现问题时检查错误的地方。 它使我们不必通过 SSH 进入计算机来检查日志。 + +### MongoDB + +[![MongoDB](img/844d05fb05599f4bb0cfc0e38f860a89.png)](http://www.mongodb.org/) + +[MongoDB](http://www.mongodb.org/) 是 NoSQL 文档存储数据库。 当前，我们将 mongodb 用于某些开发人员端点以及 A / B 测试框架 [Flak Cannon](https://github.com/claydotio/flak-cannon) 。 + +### 记忆快取 + +[Memcached](http://memcached.org/) 是一个键值存储，主要用于缓存。 在许多方面，它与 Redis 类似。 当前，我们在旧版 Web 应用程序中使用 Memcached 来缓存 MySQL 查询结果。 最终，我们希望将其替换为 Redis。 + +## 开发运维 + +### Ansible + +[![Ansible](img/f3476ebde9aa1381944d20baed0f9259.png)](http://www.ansible.com/home) + +[Ansible](http://www.ansible.com/home) 已成为我们管理服务器的首选工具。 对于大多数开发人员而言，它非常简单，可以快速学习并乐于使用，并且对于自动化通常由运营团队管理的许多流程至关重要。 + +## 其他服务 + +### 的 GitHub + +[GitHub](https://github.com/) -很棒的源代码管理，已经足够了。 + +### 正常运行时间机器人 + +[正常运行时间机器人](https://uptimerobot.com/)是免费的监控服务，我们用于监控我们的健康检查和端点。 如果有任何问题，它将在 5 分钟内通过电子邮件和短信发送给我们。 + +### Drone.io + +[Drone.io](https://drone.io/) 是一项持续集成服务，我们使用该服务为各种项目持续运行我们的测试套件。 它类似于 TravisCI，并且最近发布了一个开源的可自我托管版本。 + +### Docker 注册表 + +我们目前使用官方 [Docker 注册表](https://registry.hub.docker.com/)管理我们的 Docker 容器。 除了 Docker 容器外，它与 GitHub 类似。 + +### 新遗物 + +[New Relic](http://newrelic.com/) 是服务器和应用程序监视服务，我们主要用于监视服务器，以便在计算机磁盘或内存不足时通知我们 + +### 谷歌分析 + +[Google Analytics](http://www.google.com/analytics/) 是我们的主要网站分析跟踪工具。 为了跟踪我们特定于站点的功能，我们使用自定义事件功能。 + +### Google Apps + +[Google Apps](http://www.google.com/enterprise/apps/business/) 为我们的域 clay.io 提供电子邮件，并为我们的组织提供了共享的 Google 云端硬盘设置。 + +### 最后通行证 + +[Last Pass](https://lastpass.com/) 是一种密码管理服务，使我们可以在团队中轻松共享上述所有其他服务的公司凭据。 + +## 未来 + +虽然我们目前对今天的设置感到满意，但我们希望在接下来的几个月中对其进行改进。 最初的基础架构版本缺少一些功能，这些功能并不需要花足够的时间来证明，但是随着我们的扩展，我们最终将需要重新使用它们。 + +[Kubernetes](https://github.com/GoogleCloudPlatform/kubernetes) 希望成为一个令人惊叹的大规模管理 Docker 容器的项目和工具。 我们将密切关注其发展，并希望随着项目的成熟将其投入生产。 + +[Amazon Glacier](http://aws.amazon.com/glacier/) 是我们一直在寻找的用于进行数据库备份的另一项技术，并希望在不久的将来实现。 + +[RethinkDB](http://rethinkdb.com/) 虽然还很不成熟，但却是一个非常有趣的项目。 我们肯定会关注它的进展，并且随着我们离开 MySQL，最终可能会将一些数据移入其中。 + +好奇如果 NewRelic 也可以进行可用性监视，为什么他们使用 Uptime Robot？ +单个 HAProxy 服务器听起来像是发生故障，等待中..：/ + +考虑到 clay.io 的 Alexa 排名超过 100,000，这似乎有点过分设计。 请问您每月在托管上花费多少？ \ No newline at end of file diff --git a/docs/154.md b/docs/154.md index bafeaa5..cb6f78d 100644 --- a/docs/154.md +++ b/docs/154.md @@ -1,70 +1,207 @@ -# Pinterest 体系结构更新-1800 万访问者，增长 10 倍，拥有 12 名员工，410 TB 数据 +# 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。 -> 原文： [http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) +> 原文： [http://highscalability.com/blog/2014/10/13/how-league-of-legends-scaled-chat-to-70-million-players-it-t.html](http://highscalability.com/blog/2014/10/13/how-league-of-legends-scaled-chat-to-70-million-players-it-t.html) -![](img/824ae269f3bd907a2a05b2053f990ad9.png) +![](img/e90ef6d617446977b0276db0871cfb81.png) -关于 Pinterest 的更新：[自从我们上一篇文章以来，Pinterest 的增长是由亚马逊云可扩展性](http://news.techworld.com/storage/3352613/pinterest-growth-driven-by-amazon-cloud-scalability/)驱动的：[处理 3 百万以上用户](http://highscalability.com/blog/2012/2/16/a-short-on-the-pinterest-stack-for-handling-3-million-users.html)的 Pinterest 堆栈短缺。 +您将如何构建一个聊天服务，每天需要处理 750 万并发玩家，2,700 万每日玩家，每秒 11,000 条消息和每台服务器 10 亿个事件？ -通过 Pinterest，我们看到了一个非常类似于 [Instagram](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html) 的故事。 巨大的增长，大量的用户，大量的数据以及非常少的员工，全部都在云上。 +什么会产生这么多的流量？ 当然是游戏。 [英雄联盟](http://leagueoflegends.com) 。 英雄联盟是一款基于团队的游戏，一种多人在线战斗竞技场（ [MOBA](http://en.wikipedia.org/wiki/Multiplayer_online_battle_arena) ），其中两支五人的队伍互相对抗，以控制地图和 实现目标。 -的确，Pinterest 和 Instagram 都没有在[科学技术](http://www.theatlantic.com/business/archive/2012/05/the-golden-age-of-silicon-valley-is-over-and-were-dancing-on-its-grave/257401/)上取得重大进步，但这更多地表明了当今商品环境的便捷力量，而不是硅谷缺乏创新的迹象。 数字如此之大，估值如此之高，我们自然希望某种基本的技术革命成为其增长的基础。 革命更加微妙。 如果您能够执行正确的想法，那么如今实现这样的增长确实很容易。 习惯它。 这是新常态。 +对于团队而言，成功的沟通至关重要。 我从 [Michal Ptaszek](https://twitter.com/michalptaszek) 中了解到，在关于 [扩展英雄联盟的有趣演讲中，与 7,000 万玩家聊天](https://www.youtube.com/watch?v=_jsMpmWaq7I) （ [幻灯片](http://www.slideshare.net/michalptaszek/strange-loop-presentation) ）在 [Strange Loop 2014](https://thestrangeloop.com/) 会议。 Michal 很好地说明了为什么多人团队游戏需要玩家之间的良好沟通。 想象一下没有打篮球的篮球比赛。 这是行不通的。 因此，这意味着聊天至关重要。 聊天不是“很好”的功能。 -这是 Pinterest 今天的样子： +Michal 以一种有趣的方式构建了对话，将以下表达用作模板：使之起作用。 改正它。 快一点。 -* S3 中存储了 8000 万个对象，具有 410 TB 的用户数据，是 8 月份的十倍。 EC2 实例增长了 3 倍。 ：S3 约$ 39K，EC2 约$ 30K。 -* 截至去年 12 月，共有 12 名员工。 使用云，站点可以保持巨大的规模，同时保持很小的团队。 *看起来像 [31 名员工](http://pinterest.com/about/team/)，到目前为止*。 -* 为您所用的东西付费可以省钱。 大多数流量发生在下午和晚上，因此它们将夜间的实例数量减少了 40％。 在高峰时段，EC2 每小时花费$ 52，而在非高峰时段的晚上，每小时花费仅为$ 15。 -* Web 层中的 150 个 EC2 实例 -* 90 个实例用于内存中缓存，从而消除了数据库负载 -* 35 个用于内部目的的实例 -* 70 个主数据库，在全球不同地区具有一组并行的备份数据库，以实现冗余 -* 用 Python 和 Django 写 -* 使用分片，当数据库达到容量的 50％时将对其进行拆分，从而易于扩展并提供足够的 IO 容量 -* ELB 用于跨实例进行负载平衡。 ELB API 使您可以轻松地将实例移入和移出生产环境。 -* 历史上发展最快的网站之一。 引用 AWS 使其 3 月份可处理 1800 万访客的情况，与上个月相比增长了 50％，而 IT 基础设施却很少。 -* 云支持简单而低成本的实验。 无需购买新服务器即可测试新服务，并且无需支付大量前期费用。 -* 基于 Hadoop 的 Elastic Map Reduce 用于数据分析，每月仅花费几百美元。 +使其工作意味着从 XMPP 开始作为聊天的基础。 WhatsApp 遵循 [相同的策略](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) 。 开箱即用，您将获得可以正常使用和扩展的功能……直到用户数真正增加。 为了使其正确而快速，例如 WhatsApp，《英雄联盟》发现自己自定义了 Erlang VM。 添加许多监视功能和性能优化，以消除破坏大规模性能的瓶颈。 -## 相关文章 +他们聊天架构中最有趣的部分可能是使用 Riak 的 [CRDT](http://blog.joeljacobson.com/riak-2-0-data-types/) （会聚复制数据类型）来实现 他们没有共享的目标助长了大规模线性水平可伸缩性。 CRDT 仍然很深奥，因此您可能还没有听说过它们，但是如果您可以让它们为您服务，那么它们将是下一件很酷的事情。 这是处理写入的另一种思考方式。 + +让我们了解一下英雄联盟如何构建他们的聊天系统来处理 7000 万玩家... + +## 统计信息 + +* 每月有 6700 万唯一身份玩家（不包括聊天中的其他服务） + +* 每天有 2700 万玩家 + +* 750 万并发玩家 + +* 仅使用 20％到 30％的可用 CPU 和 RAM，每天每台服务器路由 10 亿个事件。 + +* 每秒 11K 条消息 + +* 全世界部署了数百个聊天服务器。 由 3 个人管理。 + +* 99％的正常运行时间。 + +## 平台 + +* [Ejabberd](https://www.ejabberd.im/) （基于 Erlang）XMPP 服务器 + +* 修复 + +* 负载均衡器 + +* 石墨 + +* Zabbix + +* Nagios + +* 詹金斯 + +* 汇合 + +## 聊天 + +* 可以是一对一或群聊。 + +* 聊天充当在线状态服务，并且还维护好友列表。 它知道播放器是在线还是离线。 他们在玩吗？ 他们玩了多久了？ 他们在玩什么冠军？ + +* REST API 提供聊天作为其他 LoL 服务的后端服务。 例如，商店通过聊天来验证友谊。 联赛使用聊天社交图谱将新玩家分组在一起，以便他们可以更频繁地比赛并相互竞争。 + +* 聊天必须以低且稳定的延迟运行。 如果聊天不起作用，游戏体验会下降。 + +* 选择 [XMPP](http://xmpp.org/) 作为协议。 提供消息传递，状态信息，并维护联系人列表。 + +* 由于性能原因和实施新功能，它们必须与核心 XMPP 协议有所不同。 + +* 选择 Ejabberd 作为他们的服务器。 一开始它运作良好。 Erlang 有很多好处。 它的构建考虑了并发性，分发性和可伸缩性。 它支持热代码重载，因此可以在不停止服务的情况下修补错误。 + +* 目标是 [不共享任何体系结构](http://en.wikipedia.org/wiki/Shared_nothing_architecture) 以实现大规模线性水平可伸缩性。 还可以实现更好的错误隔离和可追溯性。 尚不存在，但正在朝着这个目标取得进展。 + +* 拥有数百个聊天服务器，只有几个人可以管理它们，因此服务器必须具有容错能力，这一点很重要。 并非每一次失败都需要人工干预。 + +* 让它崩溃。 不要试图从重大故障中缓慢恢复。 而是从已知状态重新启动。 例如，如果有大量待处理查询积压到数据库中，则数据库将重新启动。 所有新查询都会实时处理，而排队的查询将重新安排进行处理。 + +* 每个物理服务器都运行 Ejabberd 和 Riak。 Riak 用作数据库。 可以根据需要水平添加服务器。 Ejabberd 在集群中运行。 风险服务器也运行在它们自己的群集中。 + +* Riak 服务器使用多数据中心复制将持久性数据导出到辅助 Riak 群集。 像社交图查询一样，昂贵的 ETL 查询在辅助群集上运行，而不会中断主要群集。 备份也会在辅助群集上运行。 + +* 随着时间的流逝，由于必须关注可伸缩性，性能和容错能力，因此大部分 Ejabberd 都被重写。 + + * 重写以符合他们的要求。 例如，在 LoL 友谊仅是双向的，XMPP 允许非对称友谊。 XMPP 友谊的创建需要客户端和服务器之间大约有 16 条消息，这对数据库造成了打击。 新协议是三个消息。 + + * 删除了不必要的代码。 + + * 优化了协议本身。 + + * 写了很多测试以确保没有损坏。 + +* 配置文件代码可消除明显的瓶颈。 + +* 避免共享可变状态，因此它可以在单个服务器上以及在集群环境中线性扩展。 -* [关于黑客新闻](http://news.ycombinator.com/item?id=4003863) -* [在 GigaOM 上](http://gigaom.com/cloud/innovation-isnt-dead-it-just-moved-to-the-cloud/) -* [新兴企业正在为 IT 创建新的世界体系](http://highscalability.com/blog/2012/5/7/startups-are-creating-a-new-system-of-the-world-for-it.html) -* [亚马逊的成功秘诀是什么？为什么 EC2 是失控的火车？](http://www.cloudscaling.com/blog/cloud-computing/what-is-amazons-secret-for-success-and-why-is-ec2-a-runaway-train/) + * 多用户聊天（MUC）。 每个聊天服务器都可以处理数十万个连接。 对于每个用户连接，都有一个会话过程。 每次用户想要更新其状态或向房间发送消息时，事件都必须转到称为 MUC 路由器的单个进程中。 然后它将消息中继到相关的群聊。 这是一个明显的瓶颈。 解决方案是并行化路由。 现在，在用户会话中查找群组聊天室。 能够使用所有可用的内核。 -用于分片的数据库是什么？ 70 大师似乎更高。 他们在 VM 中吗？ 保留 400 + tb 数据需要多少成本？ + * 每个 Ejabberd 服务器都包含会话表的副本，该表包含用户 ID 和会话之间的映射。 发送消息需要查看用户会话在集群中的位置。 消息已写入会话表。 通过检查会话是否存在，检查存在优先级以及其他一些检查，分布式写操作的数量减少了 96％。 巨大的胜利。 更多的用户可以更快地登录，并且状态更新可以更频繁地发生。 -*“将 AWS 变为可能的站点”* +* 新增的功能使您可以更好地了解已升级到生产中的代码。 因此，可以在事务上下文中一次在多个服务器上更新代码。 -*引用 +* 为了优化服务器，调试功能已添加到 Erlang VM 中。 需要具有查看会话中内存使用情况的能力，以便他们可以更好地优化内存使用率。 -我认为您的意思是* cites，而不是“倒数第二个”中的“ Site for AWS”。 +* 从一开始就设计了数据库可伸缩性。 从 MySQL 开始，但是遇到了多个性能，可靠性和可伸缩性问题。 例如，不可能足够快地更新架构以跟踪代码中所做的更改。 -看到这些东西总是很有趣，410TB 是海量的 S3 数据！ + * 因此，他们选择了 Riak。 Riak 是分布式，容错的键值存储。 真正的无主，所以没有单点故障。 即使两台服务器故障也不会降低服务质量或丢失数据。 -那么，每月$ 31K +的存储空间（这减少了冗余），每月$ 3K 的 EC2 计算能力？ + * 必须在聊天服务器上花费大量工作来实现最终的一致性。 实现了 Ejabberd [CRDT 库](http://blog.joeljacobson.com/riak-2-0-data-types/) （会聚复制数据类型）。 负责所有写冲突。 尝试将对象收敛到稳定状态。 -因此，对于 EC2 实例和 410TB 的存储（甚至不试图猜测带宽），他们的亚马逊每月费用约为 6 万美元，而且他们的工资单至少还需要 10 万美元。 据我所知，他们的收入为 0 美元。 这里的模型到底是什么？ + * CRDT 如何工作？ 与其将新玩家直接添加到好友列表中，不如保留对象的操作日志。 日志中有“添加播放器 1”和“添加播放器 2”之类的条目。 下次读取该对象时，将查阅该日志并解决所有冲突。 然后将日志以任何顺序应用于对象，因为顺序无关紧要。 这样，朋友列表就处于一致状态。 想法是在适当的位置更新值，而不是为对象建立一长串的操作日志，并且只要读取对象就应用该操作。 -EC2 具有非常差的 I / O 性能的最新想法是什么？ 添加更多实例是否可以经济有效地弥补这一不足？ 谢谢。 + * Riak 取得了巨大的成功。 允许线性缩放。 还提供了方案灵活性，因为可以随时更改对象。 + + * 这是一个巨大的思想转变和大量的工作。 它改变了他们测试服务并围绕它构建工具的方式。 + +## 监控 + +* 内置了超过 500 个实时计数器，每分钟收集一次并发布到监视系统（Graphite，Zabbix，Nagios）中。 + +* 计数器具有阈值，在超过阈值时会生成警报。 在玩家注意到任何服务问题之前就可以解决问题。 + +* 例如，最近的客户端更新进入了广播自己存在状态的无限循环。 观察 Graphite，立即可以看出聊天服务器受到了从新客户端版本开始的状态更新的冲击。 + +## 实现功能切换（功能标志） + +* 能够即时打开和关闭新功能，而无需重新启动服务。 + +* 开发新功能时，将通过开/关开关将其包围。 如果某个功能导致问题，则可以将其禁用。 + +* 部分部署。 只能为某些用户启用新代码，或者一定比例的用户可以激活新代码。 这样可以在远低于满载的情况下测试潜在危险功能。 如果新功能有效，则可以为所有人打开。 + +## 快速重新加载代码 + +* Erlang 的一大特色是能够即时热加载新代码。 + +* 在一种情况下，第三方客户（如 pidgin）没有经过良好的测试，结果证明他们发送的事件与官方客户不同。 可以将这些修补程序部署并集成到聊天服务器中，而不必重新启动整个聊天。 这意味着减少了玩家的停机时间。 + +## 正在记录 + +* 记录所有异常情况，例如错误和警告。 + +* 服务器还报告运行状况良好，从而可以查看日志并确定服务器是否正常，因为它正在记录用户，接受新连接，修改好友列表。 + +* 内置进入所选用户会话的调试模式的功能。 如果有可疑用户或实验用户（在生产服务器上进行质量检查），即使聊天服务器上有 100,000 个会话，也只需记录特定的会话即可。 日志记录包括 XML 流量，事件和指标。 这样可以节省大量的日志存储空间。 + +* 通过功能切换，部分部署和选择性日志记录的组合，可以将功能部署到生产服务器，因此只能由几个人进行测试。 可以收集和分析相关日志，而不会受到所有用户的干扰。 + +## 负载测试代码 + +* 每天晚上，自动验证系统都会将所有更改的构建部署到负载测试环境，并运行一系列负载测试。 + +* 在测试过程中监视服务器的运行状况。 指标被提取和分析。 将生成一个 Confluence 页面，其中包含所有指标和测试结果。 将发送电子邮件摘要以及测试结果摘要。 + +* 可以将更改与以前的版本进行比较，因此可以跟踪代码更改对测试的影响，发现灾难或诸如内存使用量减少了 X％之类的更改。 + +## 未来 + +* 从 MySQL 迁移数据。 + +* 希望在游戏外提供聊天功能，以便玩家无需登录游戏即可享受友谊。 + +* 想使用社交图谱来改善体验。 分析玩家之间的联系，并了解其如何影响游戏的乐趣。 + +* 计划将游戏内聊天迁移到游戏外聊天服务器。 + +## 获得的经验教训 + +* **事情将失败**。 您没有完全的控制权。 即使您的代码没有错误，如果 ISP 的路由器死亡并且同时失去 100,000 个播放器，会发生什么情况？ 做好准备 确保您的系统可以一次处理掉一半的玩家。 或者在 20 个聊天服务器中损失 5 个而不会降低性能。 + +* **缩放表面虫** 。 即使一个错误仅发生十亿次，这意味着在英雄联盟的规模下，该错误每天也会发生一次。 随着时间的流逝，甚至不太可能发生的事件。 + +* **成功的关键是了解系统实际上在做什么** 。 了解您的系统是否处于健康状态或即将崩溃。 + +* **制定策略** 。 大声笑有一种横向扩展其聊天服务的策略。 为了支持他们的策略，他们做了一些不同的事情。 他们不仅使用 Riak 购买了 NoSQL，而且改变了利用 CRDT 的方法，以使水平扩展尽可能无缝和强大。 + +* **使它起作用** 。 从某个地方开始发展。 埃贾伯德把他们弄倒了。 从头开始会更容易吗？ 也许可以，但是当他们了解了需求是什么时，他们便能够开发出满足他们需求的系统。 + +* **使其可见** 。 添加跟踪，日志记录，警报，监视，图形以及所有这些好东西。 + +* **使其成为 DevOps** 。 LoL 在软件更新，功能标记，热更新，自动负载测试，高度可配置的日志级别等中添加了事务，以使系统更易于管理。 + +* **减少聊天协议** 。 根据系统需求定制功能。 例如，如果您的系统仅支持双向友谊，那么您就不会采用更为通用和昂贵的协议。 + +* **避免共享可变状态** 。 这是一种常见的策略，但是看到共享状态如何在每次扩大规模时引起越来越多的问题总是很有趣的。 + +* **利用您的社交图** 。 聊天服务自然会提供社交图。 该信息可用于改善用户体验和实现新颖的新功能。 + +## 相关文章 -为了提高 I / O 性能，请创建多个卷并使用软件 RAID 对其进行条带化。 +* [在 Reddit 上](http://www.reddit.com/r/programming/comments/2j95dv/how_league_of_legends_scaled_chat_to_70_million/) -是每月或每年约$ 69K 的存储空间？ +* [使用 Erlang 的新 Facebook 聊天功能可扩展至 7000 万用户](http://highscalability.com/blog/2008/5/14/new-facebook-chat-feature-scales-to-70-million-users-using-e.html) （2008） -@Joe：Pinterest 过去曾尝试过会员链接，因此他们获得的收入微不足道，但似乎[仍在积极地解决它](http://llsocial.com/2012/02/pinterest-adds-disclosure-and-info-from-ceo/)。 +* [HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息](http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html) （使用 XMPP） ->这是 Pinterst 今天的样子： +* [Facebook 以 190 亿美元的价格收购了 WhatsApp 架构](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) （使用 XMPP） -** Pinterest 的 +* [误区：埃里克·布鲁尔（Eric Brewer）论为何银行不使用碱-可用性是收入](http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html) -我们的私有云团队研究了上述配置和价格。 根据我们的经验，私有云基础架构将在大约 20 个月内提供 ROI。 从 Amazon 迁移到私有云时，由于 I / O 和计算能力的提高，我们通常还会看到迁移后实例的 3：1 合并。 +* [英雄联盟内部，电子竞技的主要赛事](http://www.nytimes.com/2014/10/12/technology/riot-games-league-of-legends-main-attraction-esports.html) -因此，您拆分了数据库，使其达到当前服务器的 50％。 你是什​​么意思？ 记忆还是？ +很棒的文章，谢谢！ 一个小小的更正：Riak（还有问题）中的 CRDT 风格是收敛的复制数据类型，而不是您的文章所说的可交换的 -410TB 中的 90％可能侵犯了版权。 他们绝对无权将全尺寸照片复制到其服务器。 +从某种意义上讲，CRDT 并不是新事物：您的银行分类帐是事件日志，并且在存在所有此类即时网络之前，银行分支机构通常会在一天结束时合并其日志，以获取权威的银行余额。 但是显然，分布式数据库专家并没有永远谈论 CRDT，所以我知道您的意思。 -是 1800 万唯一身份访问者吗？ +很酷的文章！ 作为每天使用 Erlang 的人，看到越来越多的知名项目/公司使用它总是很有趣。 感觉就像总是隐藏在 XD 中的那些语言之一 -他们现在有 152 名员工，多么增长！ \ No newline at end of file +想一想游戏的持续发展速度如何，而且除了 DDOS 攻击之外，几乎没有打 h 过，这真是令人惊讶。 \ No newline at end of file diff --git a/docs/155.md b/docs/155.md index 69a853a..496ed06 100644 --- a/docs/155.md +++ b/docs/155.md @@ -1,131 +1,235 @@ -# 搜索技术剖析：blekko 的 NoSQL 数据库 +# Wix 的 Nifty Architecture 技巧-大规模构建发布平台 -> 原文： [http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html) +> 原文： [http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html](http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html) -![](img/36ab01ea97bfa8e04f1ca36ac0ea0183.png) +![](img/51ad9a97b669a9cbea8846d65dbba291.png) -*这是 blekko 的首席技术官 Greg Lindahl 的来宾帖子（[第 2 部分](http://highscalability.com/blog/2012/5/28/the-anatomy-of-search-technology-crawling-using-combinators.html)，[第 3 部分](http://highscalability.com/blog/2012/7/9/data-replication-in-nosql-databases.html)），该网站是垃圾邮件免费搜索引擎，3 月的独立访问者超过 350 万。 Greg Lindahl 是 PathScale 的创始人兼杰出工程师，当时他是 InfiniPath 低延迟 InfiniBand HCA 的架构师，该架构用于构建紧密耦合的超级计算集群。* +[Wix](http://www.wix.com/) 长期运营网站。 作为基于 HTML5 的所见即所得（WYSIWYG）网络发布平台，他们已经创建了超过 5400 万个网站，其中大多数网站每天的网页浏览量不到 100。 因此，传统的缓存策略不适用，但仅需四个 Web 服务器即可处理所有流量。 这需要一些聪明的工作。 -想象一下，您已经疯狂到足以考虑构建搜索引擎了。 这是一项艰巨的任务：回答大多数查询所需的最小索引大小是数十亿个网页。 要对数十亿个网页进行爬网和建立索引，就需要一个群集，其中包含几 PB 的可用磁盘（即几千个 1 TB 的磁盘），并且产生的索引大小约为 100 TB。 +[Wix 后端工程负责人 Aviran Mordo](https://twitter.com/aviranm) 在精彩的演讲中描述了他们的解决方案：[规模](http://www.infoq.com/presentations/wix-architecture)的 Wix 体系结构。 他们开发的最佳传统就是专业化。 他们仔细分析了他们的系统，并弄清楚了如何以一些最有趣的方式实现其积极的高可用性和高性能目标。 -快速提供查询结果涉及将大多数索引放在 RAM 或固态（闪存）磁盘上。 如果您可以以 3,000 美元的价格购买具有 100 GB RAM 的服务器，那么这 1,000 台服务器的资本成本为 300 万美元，加上每年服务器托管成本（电源/散热/空间）约为 100 万美元。SSD 替代方案需要 更少的服务器，但是每秒提供更少的查询，因为 SSD 比 RAM 慢得多。 +Wix 使用**多个数据中心和云**。 我之前从未见过的是它们将数据复制到多个数据中心，Google Compute Engine 和 Amazon。 并且在失败的情况下它们之间具有备用策略。 -您可能会认为，亚马逊的 AWS 云将是降低启动搜索引擎成本的好方法。 不是，原因有四个： +Wix **不使用交易**。 相反，所有数据都是不可变的，并且它们使用简单的最终一致性策略来完美匹配其用例。 -1. 爬网和建立索引一直需要大量资源； 您有时无法仅通过租用大多数服务器来省钱。 -2. 亚马逊目前不出租带有 SSD 的服务器。 将索引放入 Amazon 的 RAM 中非常昂贵，并且仅对拥有几％市场份额的搜索引擎有意义。 -3. 亚马逊仅出租有限数量的磁盘 I / O 与内存大小与核心数量的比率。 事实证明，相对于其他所有产品，我们需要大量的磁盘 I / O，这使 Amazon 的成本效益降低。 -4. 在某种集群规模下，一家初创公司具有足够的规模经济优势，可以超过亚马逊的成本+利润率。 在发布时（2010 年 11 月），blekko 拥有 700 台服务器，而我们目前有 1,500 台。 这远远超出了收支平衡点。 +Wix **不缓存**（就像在大缓存层中一样）。 取而代之的是，他们非常注意优化渲染路径，以便每个页面的显示时间均不到 100ms。 -## 软件 +Wix 从一开始就具有单一的体系结构，并有意识地**迁移到了服务体系结构**，该过程使用了一种非常刻意的过程来识别服务，该服务可以帮助任何考虑同一步骤的人。 -那仅仅是硬件：我们还需要一个软件系统来管理存储以及对集群中 Web 爬网和索引数据的访问。 我们的目标之一是设计一种存储体系结构，当在搜索引擎环境中使用 Web 大小的数据集时，将为程序员带来生产力上的优势。 +这不是您的传统 LAMP 堆栈或本机云。 Wix 有点不同，您可以在这里学到一些东西。 让我们看看他们是如何做到的... -我们的目标是： +## 统计信息 -* 一种将数据存储在类似于数据库表的系统中 -* 同一集群中的实时（查询服务）和批处理（爬网和索引）处理 -* 添加对倒排索引的直接支持的能力，该索引非常适合系统的其余部分 -* 出色的程序员生产力，包括： - * 无缝集成主要实现语言的数据存储和数据结构 - * 抵抗常见的数据库和群集数据库问题，例如热点和死锁/活锁 - * 数据存储区，可实现常规数据库操作（如 BASE 和 CRUD），并有效地实现并协助并行编程结构（如工作队列）。 - * 支持快速完成初始批处理作业结果的周转时间，从而使程序员可以快速发现其批处理作业做错了什么 -* 可扩展到数千个磁盘设备： - * 磁盘故障是将群集扩展到大尺寸时最常见且令人讨厌的问题 - * 面对故障逐渐退化 - * 理想情况下，群集故障 1％只会使处理能力和存储量减少 1％。 例如，在节点上重建 RAID 卷期间，服务器上 RAID 的使用不当会导致吞吐量降低超过 1％。 此外，磁盘故障在大型集群中非常常见，以至于我们希望在准备好一次，一周或一个月后修复多个节点之前就不需要人工干预。 -* 由于可用性的原因，我们希望使用群体算法来实现尽可能多的子系统，而不是使用 Paxos 来选择主节点。 [https://zh.wikipedia.org/wiki/Paxos_algorithm](https://en.wikipedia.org/wiki/Paxos_algorithm) +* 54 个以上的网站，每月有 100 万个新网站。 -## 组合器 +* 超过 800 TB 的静态数据，每天有 1.5 TB 的新文件 -在传统的数据库系统中，对数据库的更新是在事务中完成的，其中程序锁定数据库的一行或多行，进行一些更改，然后提交或中止整个事务。 大多数 NoSQL 数据库都将事务限制为锁定&来修改单个行，并限制可以在事务内完成的计算类型。 +* 3 个数据中心+ 2 个云（Google，Amazon） -在 blekko 的数据存储区中，我们严重依赖于称为合并器的构造在数据库单元级别进行处理。 组合器是对数据库单元进行的原子操作，该操作是关联的，最好是可交换的。 “ Add（n）”是一个简单组合器的示例； 它将 n 加到单元格中的任何数字上。 至关重要的是，它不会将总和返回给调用方。 它只是启动加法。 +* 300 台服务器 -如果一堆数据库节点想在数据库的同一单元中加 1，而又不了解该单元的最终值是什么，则可以将这些操作组合到集群中的层次结构中，从而进行最终的磁盘操作 是一个将初始增量之和相加的操作。 +* 每天有 7 亿个 HTTP 请求 -![](img/786fcb4b60e4084b2df67361ef0746a5.png) +* 共 600 人，R 区& D 共 200 人 -加法是关联和可交换的事实意味着我们（最终）将在此单元格的所有 3 个副本中获得相同的答案。 组合的层次结构意味着与天真的实现相比，事务总数大大减少了，因为天真的实现每个过程都直接与单元的 3 个副本进行对话，而每个加法操作都会导致 3 个立即事务。 +* 约有 50 个服务。 -### 日志计数组合器 +* 需要 4 个公共服务器才能为 4500 万个网站提供服务 -搜索引擎经常需要计算一组中的唯一项。 示例包括计算网站的链接数，链接到该网站的唯一地理区域的数量以及链接到该网站的唯一的 C 类 IP 网络的数量等等。 尽管我们总是可以运行 MapReduce 作业来获得这些项目的准确计数，但我们希望在任何时间点都知道这些计数。 保持完美的计数将需要保留大量数据，因此我们发明了一种**近似方法**，该方法仅用 16 个字节就可以对多达十亿个事物进行计数，精度为±50％。 +## 平台 [ -该组合器（我们称为对数计数）以可交换和关联的方式实现-您可以将其中两个的位与进行组合以合并其计数。 它还具有以下属性：如果您多次计数任何字符串，则最多只能更改一次答案。 最后一个属性意味着它是可重新运行的，即如果在数据库中进行了两次相同的事务，则答案不会改变。 +* MySQL -### TopN 组合器 +* Google 和亚马逊云 -搜索引擎的另一种常见操作是记住集合中最重要的 N 个项目。 这用于我们不想记住集合中的所有项目以减小尺寸的情况。 例如，我们可能希望经常将最重要的 2500 个传入 URL 的[锚文本]( https://en.wikipedia.org/wiki/Anchor_text)访问到我们曾经抓取过的每个 URL。 +* CDN -TopN 组合器可以在适合数据库的单个单元格的有限大小的数组中表示前 N 个 URL： +* 厨师 -![](img/0ba465d712fdf97b661484e69f880c5b.png) +## 进化 [ -随着我们抓取新的网页，可以对 TopN 组合器进行增量更新，并且这些更新的价格不昂贵。 可以在单个磁盘操作中读取它，而无需索引或排序或读取不位于前 N 个位置的 URL 的任何数据。感谢用于决定哪个 URL 最适合 N 的行列，它是可交换的 和关联。 而且它可以重新运行。 +* 简单的初始整体架构。 从一台应用服务器启动。 这是最简单的入门方法。 进行快速更改并部署。 它使您到达特定的位置。 -如果我们使用时间作为排名，则可能会有其他技巧。 这使我们能够有效地记住最近的 N 个事物或最早的 N 个事物。 + * Tomcat，Hibernate，自定义 Web 框架 -到目前为止，我们已经在数据库表中将组合器用作单个单元格。 也可以在我们程序中的变量中使用**； 它们的实现将它们存储为字符串，读取值需要调用“ finalize”函数。 例如，此功能将日志计数中的 16 个字节的位字段转换为整数的近似项目数。** + * 使用的状态登录。 -### 元组合器：哈希组合器 + * 忽略了性能和扩展性的任何概念。 -如果数据库中的一个单元格包含（键，值）对的哈希，则哈希元组合器可用于原子地仅更新一些（键，值）对，其余的保持不变。 这给了我们极大的自由，可以将数据库中的列设置为对程序员有意义的列，而不必为了使原子地进行更改而必须将多余的内容提升为列。 +* 快进了两年。 -### 减少地图/缩小 + * 仍然是一台完成所有任务的单片服务器。 -由于我们用组合器表示数据库表，为什么不使用组合器来改组并减少 MapReduce 作业的输出？ 然后我们可以编写遍历数据库中某个表的 MapJob，然后使用组合器将其输出写回到数据库中。 让我们对网络进行字数统计： + * 在一定规模的开发人员和客户眼中，它们阻碍了他们的发展。 -> “ / crawl / url”中的 foreach 行 -> -> html 列中的 foreach 单词 -> -> comb_add（“ / wordcount”，word，1） + * 功能之间的依存关系问题。 一处的更改导致整个系统的部署。 不相关区域的故障导致整个系统停机。 -在此伪代码中，我们遍历表/ crawl / url 中的所有 html 文档，对于找到的每个单词，我们在表“ / wordcount”中增加相应的行。 编程人员不再需要考虑改组/减少步骤应以哪种**中间形式**作为输入，或指定减少功能。 +* 是时候把系统分开了。 -这种单词计数方法的第二个特点是，上述功能还可以在流上下文中使用**，将新抓取的文档的单词计数添加到表“ / wordcount”中的现有计数。 表示 MapReduce 计算的通常方法不能在流计算中使用相同的代码。** + * 采用了一种服务方法，但这并不容易。 您如何将功能分解为服务？ -第三个功能是该 MapJob 的第一个输出在 MapJob 启动后的几分钟后出现在/ wordcount 表中。 大多数 MapReduce 系统直到每个分片完成后才开始随机播放和还原。 具有**快速，部分答案**可使程序员更快地找到其 MapJob 中的错误。 + * 查看了用户在系统中的工作，并确定了三个主要部分：编辑网站，查看由 Wix 创建的网站，提供媒体。 -## 我们是否实现了所有要求？ + * 编辑网站包括服务器中数据的数据验证，安全性和身份验证，数据一致性以及许多数据修改请求。 -现在，我们已经在这个本地数据存储上拥有近 3 年的运营经验，现在很高兴回头看看，我们基本上满足了我们预先设定的所有要求。 在本文的初始篇中，我们仅讨论了数据存储的部分功能，但是我们在这里讨论的内容已广为人知。 我们的数据存储区： + * 网站制作完成后，用户将对其进行查看。 观看者比编辑者多 10 倍。 所以现在的问题是： -* 看起来像表格数据库 -* 在同一集群中支持实时和批处理 -* 支持高程序员效率 + * 高可用性。 高可用性是最重要的功能，因为它是用户的业务。 -在本系列的下一部分中，我们将更详细地研究 Web 爬网，并使用组合器实现爬网程序。 + * 高性能 -这篇文章中的所有内容看起来都很简单容易。 我希望人们不要错过这里介绍的算法和数据库调用的类型具有可伸缩性。 经验法则（我刚刚完成）是只要您将数据存储区调用的大部分都考虑为可交换的，您做对了，它就会扩展并可以期望。 我敢打赌，该系统不仅可以在水平方向上很好地缩放，而且可以在单台机器上高效地运行，并且在垂直方向上也可以很好地缩放。 这个系统不仅是 BIG-DATA，它还是 EFFICIENT-BIG-DATA，这更重要，因为它的大小:)不错的文章，加上 plus100 也可避免沉迷于流行词的不必要使用:) + * 高流量 ->快速提供查询结果涉及将大多数索引放在 RAM 或固态（闪存）磁盘上。 + * 长尾巴。 有很多网站，但是它们很小。 每个站点每天可能会获得 10 或 100 个页面浏览量。 长长的尾巴使缓存不适合可伸缩性策略。 缓存变得非常低效。 -仅当查询在查询空间之间均匀分布时，这才是正确的。 在现实生活中，查询空间由一小部分“热”（经常请求）查询和一长串“冷”（很少请求）查询组成。 因此，在从 I / O 绑定存储中服务“冷”查询的同时，可以在 RAM 中仅缓存一小部分索引，这对应于“热”查询。 这可以显着减少索引所需的 RAM 量，同时保持良好的 qps。 + * 媒体服务是下一个重要服务。 包括 HTML，javascript，css，图像。 需要一种在大量请求下为文件提供 800TB 数据的方法。 胜利是静态内容是高度可缓存的。 -搜索查询往往有一个“长尾巴”，因此专用于仅服务于头部的 ram 会使大多数查询脱离缓存。 我们努力在所有查询的 95/99％上实现目标延迟-我们在办公室的大型状态监视器上具有跟踪此延迟的图形，以及在我们掉线时会唤醒人们的操作警报。 对于主流搜索服务而言，在 50％的查询上实现合理的延迟是不够的。 具有 SLA 的合作伙伴也不会接受该级别的性能。 + * 新系统**看起来像**，位于三个网段服务下面的网络层：编辑器网段（任何编辑数据的文件），媒体网段（处理静态文件，只读），公共网段（文件的第一位是 已查看，只读）。 -日志计数组合器上的准确性是否正确？ 那么，100,000 意味着 50,000 至 150,000 之间的东西？ 如果是这样，我很好奇具有这种准确性的计数将达到什么目的。 另外，我应该首先说这看起来很酷。 是否有计划实施后续文章，还是 Blekko 秘密调味酱过多？ 谢谢。 +## 如何构建服务的准则 [ -让我们做简单的数学。 100Tb 索引对应于 50 x 2Tb HDD。 每个 HDD 可以执行 100 IOPS（10 毫秒随机搜寻延迟）。 因此 50 个 HDD 可以执行 5K qps。 这意味着该应用程序可以轻松地每秒处理 5K 个“冷”索引查询，每个查询具有 10ms 的延迟，而无需计算从 RAM 执行的数百万个“热”索引查询。 如果将 HDD 替换为 SSD，则“冷”索引查询的性能可以轻松提高到 500K qps 甚至更高。 +* 每个服务都有自己的数据库，只有一个服务可以写入数据库。 -日志计数示例：计算到 URL 的入站链接数。 在 0 和 1（合格）入站链接之间的差值中大约有与在 128 和 256 之间相同的信号。对于像这样的对数分布上出现的现象，用两个作品的渐进幂中的误差进行近似计数。 +* 仅通过服务 API 访问数据库。 这支持将关注点分离并从其他服务隐藏数据模型。 -实际上，我们有一个新的组合器，该组合器在我们的系统中大部分已替换为 logcount，称为 adapcount。 您以字节为单位指定要使用的空间量，使用的空间越多，精度越好。 因此，对于 2k，您可以有+/- 5％的值（我忘了细节）。 +* 出于性能原因，授予其他服务只读访问权限，但只能写入一个服务。 （是的，这与之前所说的相矛盾） -噢，是的，我完全忘记提及 logcount 有很多朋友，这些朋友更大，更精确。 最不精确的版本用于我们拥有大量统计数据的地方，就像我们为 180 亿个网页所保留的统计数据一样，我们已经看到了链接但尚未抓取。 +* **服务是无状态的**。 这使得水平缩放变得容易。 只需添加更多服务器。 -当第一句话包含“无垃圾邮件搜索引擎”时，我差点弯腰阅读。 但是哎呀，我束手无策： -http://blekko.com/ws/site:bigresource.com +* **没有交易**。 除帐单/金融交易外，所有其他服务均不使用交易。 这个想法是通过消除事务开销来提高数据库性能。 这使您考虑如何在不使用数据库事务的情况下将数据建模为具有逻辑事务，避免出现不一致的状态。 -这是一个非常有趣的帖子。 您是否会碰巧有更多关于组合器和系统技术细节的文章/白皮书或其他资源？ 听起来很有趣:) +* 设计新服务**时，缓存不属于体系结构**。 首先，使服务尽可能地具有性能，然后部署到生产环境，看看其性能，然后，如果存在性能问题，并且您无法优化代码（或其他层），则只能添加缓存。 -感谢分享 +## 编辑器细分 -艺术 +* 编辑器服务器必须处理大量文件。 -听起来像一个有趣的小项目。 +* 在 MySQL 中存储为不可变 JSON 页（每天约 250 万个）的数据。 -如果要为职位实施垂直搜索引擎，应该使用哪个数据库？ \ No newline at end of file +* **MySQL 是一个很棒的键值存储**。 密钥基于文件的哈希函数，因此密钥是不可变的。 通过主键访问 MySQL 非常快速高效。 + +* **可伸缩性与权衡**有关。 我们要进行哪些权衡？ 不想使用 NoSQL，因为它们会牺牲一致性，并且大多数开发人员都不知道该如何处理。 因此，请坚持使用 MySQL。 + +* **活动数据库**。 网站建成后发现，只有 6％的网站仍在更新中。 这样，这些活动站点就可以存储在一个真正快速且存储量相对较小（2TB）的数据库中。 + +* **存档数据库**。 对于不经常访问的站点，所有过时的站点数据都移至相对较慢但具有大量存储空间的另一个数据库中。 三个月后，数据被推送到该数据库，因为访问率低。 （可能会说这是一种隐式缓存策略）。 + +* 为呼吸提供了很大的成长空间。 大型归档数据库的速度很慢，但这没关系，因为数据使用的频率不高。 首次访问时，数据来自存档数据库，但是随后将其移至活动数据库，因此以后的访问速度很快。 + +## 编辑器细分市场的高可用性 + +* 拥有大量数据，很难为所有内容提供高可用性。 因此，**查看关键路径**，对于网站而言，该路径就是网站的内容。 如果小部件出现问题，则大多数网站仍将正常工作。 在保护关键路径上投入了大量资金。 + +* 防止数据库崩溃。 想要快速恢复。 复制数据库并将故障转移到辅助数据库。 + +* **防止数据损坏和数据中毒**。 不必一定是恶意的，一个漏洞足以破坏枪管。 所有数据都是不可变的。 修订存储了所有内容。 如果无法修复损坏，最坏的情况是还原到数据可以正常使用的版本。 + +* 防止不可用。 网站必须一直工作。 这推动了**在不同地理位置和多个云**之间复制数据的投资。 这使得系统非常有弹性。 + + * 在网站编辑会话上单击保存会将 JSON 文件发送到编辑器服务器。 + + * 服务器将页面发送到活动 MySQL 服务器，该服务器已复制到另一个数据中心。 + + * 将页面保存到本地后，将启动一个异步过程，将数据上传到静态网格（即媒体段）。 + + * 将数据上传到静态网格后，系统会将通知发送到在 Google Compute Engine 上运行的存档服务。 存档会转到网格，下载页面，然后将副本存储在 Google 云中。 + + * 然后，通知会发送回编辑器，说明页面已保存到 GCE。 + + * 另一个副本已从 GCE 保存到 Amazon。 + + * 收到最后一条通知，这表示当前数据修订版有三份副本：一份在数据库，静态网格中，以及在 GCE 上。 + + * 当前版本有 3 个副本。 对于旧版本，有两个版本（静态网格，GCE）。 + + * 该过程是自修复的。 如果失败，则下次用户更新其网站时，所有未上传的内容都会重新上传。 + + * 孤立文件被垃圾回收。 + +## 没有数据库事务的数据建模 + +* 不想出现这样的情况，即用户编辑了两个页面，而数据库中只保存了一个页面，这是一种不一致的状态。 + +* 获取所有 JSON 文件，并将它们一个接一个地粘贴在数据库中。 保存所有文件后，将发出另一个保存命令，其中**包含上载到的已保存页面的所有 ID** （这是内容的哈希，是静态服务器上的文件名）的清单。 静态服务器。 + +## 媒体段 [ + +* 存储大量文件。 800TB 的用户媒体文件，每天上传的 3M 文件和 500M 的元数据记录。 + +* 图像被修改。 它们针对不同的设备调整了大小并进行了锐化。 可以插入水印，还可以进行音频格式转换。 + +* 构建了一个最终一致的分布式文件系统，该系统具有多数据中心感知能力，并且可以跨 DC 自动回退。 这是在亚马逊之前。 + +* 难以忍受。 32 台服务器，每 9 个月翻一番。 + +* 计划将内容推送到云以帮助扩展。 + +* **供应商锁定是一个神话**。 全部都是 API。 只需更改实施，您就可以在几周内迁移到不同的云。 + +* **真正使您失望的是数据**。 将 800TB 的数据转移到另一个云上真的很困难。 + +* **当他们将所有数据移至 GCE 时，他们破坏了 Google Compute Engine** 。 他们达到了 Google 云的极限。 经过 Google 的一些更改后，它现在可以使用了。 + +* 文件是不可变的，因此高度可缓存。 + +* 图像请求首先进入 CDN。 如果映像不在 CDN 中，则请求将转到其位于奥斯丁的主数据中心。 如果图片不在 Austin 中，则请求转到 Google Cloud。 如果不在 Google 云中，它将转到坦帕的数据中心。 + +## 公共细分 + +* 解析 URL（其中的 4500 万个），分派到适当的渲染器，然后渲染为 HTML，站点地图 XML 或机械手 TXT 等。 + +* **公共 SLA 是在高峰流量**时，响应时间为< 100ms。 网站必须可用，而且速度也要很快。 记住，不要缓存。 + +* 当用户在编辑页面后单击“发布”时，包含对页面的引用的清单将被推送到“公共”。 路由表也已发布。 + +* **最小化服务中断跳**。 需要 1 个数据库调用才能解析路由。 1 RPC 调用，将请求分派到渲染器。 1 个数据库调用以获取站点清单。 + +* 查找表缓存在内存中，每 5 分钟更新一次。 + +* 数据存储的格式与编辑器使用的格式不同。 **以非规范化格式**存储，已针对主键读取进行了优化。 所需的所有内容都在单个请求中返回。 + +* **最小化业务逻辑**。 数据将被规格化和预先计算。 当您大规模处理每项操作时，每增加一毫秒，这就是 4,500 万次，因此必须证明在公共服务器上发生的每项操作都是合理的。 + +* 页面渲染。 + + * 公用服务器返回的 html 是 **bootstrap html** 。 这是一个包含 JavaScript 导入和 JSON 数据（引用网站清单和动态数据）的外壳。 + + * **渲染已卸载到客户端**。 笔记本电脑和移动设备非常快，可以处理渲染。 + + * 选择 JSON 是因为它易于解析和可压缩。 + + * **更容易修复客户端**上的错误。 只需重新部署新的客户端代码。 在服务器上完成渲染后，将缓存 html，因此，修复错误需要**再次重新渲染数百万**个网站。 + +## 公共段的高可用性 + +* 目标是永远可用，但事情还是会发生。 + +* **在**美好的一天：浏览器发出请求，该请求通过负载平衡器到达数据中心，到达公共服务器，解析路由，到达渲染器，html 返回到 浏览器，然后浏览器运行 javascript。 javascript 会获取所有媒体文件和 JSON 数据，并呈现一个非常漂亮的网站。 然后，浏览器向存档服务发出请求。 存档服务以与浏览器相同的方式重放请求，并将数据存储在缓存中。 + +* 在糟糕的日子**，数据中心丢失**，这确实发生了。 所有不间断电源系统都死了，数据中心关闭了。 DNS 已更改，然后所有请求都转到了辅助数据中心。 + +* 在糟糕的日子**公众失去了**。 当负载均衡器获得一半配置，因此所有公共服务器都消失了时，就会发生这种情况。 或者可以部署一个错误版本，该版本开始返回错误。 如果公共服务器不可用，负载平衡器中的自定义代码通过路由到存档服务以获取缓存的缓存来解决此问题。 这种方法意味着即使 Public 崩溃，客户也不会受到影响，即使当时系统正在响起警报。 + +* 糟糕的一天**，互联网糟透了**。 浏览器发出请求，转到数据中心，转到负载平衡器，获取 html。 现在，JavaScript 代码必须获取所有页面和 JSON 数据。 转到 CDN，转到静态网格并获取所有 JSON 文件以呈现站点。 在这些过程中，Internet 问题可能会阻止文件被返回。 JavaScript 中的代码表示如果您无法到达主要位置，请尝试从存档服务获取它，如果失败，请尝试编辑器数据库。 + +## 吸取的教训 [ + +* **确定您的关键路径和关注点**。 想一想您的产品如何运作。 制定使用方案。 将精力集中在这些方面，因为它们可以带来最大的收益。 + +* **转到多数据中心和多云。** 在关键路径上构建冗余（以提高可用性）。 + +* **对数据进行非规范化并最小化进程外跳数（以提高性能）**。 进行预校正并尽一切可能使网络颤动最小化。 + +* **利用客户端的 CPU 能力**。 这样可以节省服务器数量，并且更容易修复客户端中的错误。 + +* **从小处着手，完成任务，然后找出下一步**的去向。 Wix 做了他们需要做的事情，以使其产品正常工作。 然后，他们有条不紊地迁移到复杂的服务体系结构。 + +* **长尾巴需要其他方法**。 Wix 不会缓存所有东西，而是选择优化渲染路径之外的内容，并将数据保留在活动数据库和存档数据库中。 + +* **变为不可变**。 不变性对体系结构具有深远的影响。 它影响从客户端到后端的所有内容。 这是解决许多问题的理想解决方案。 + +* **供应商锁定是一个神话**。 全部都是 API。 只需更改实施，您就可以在几周内迁移到不同的云。 + +* **真正使您失望的是数据**。 将大量数据转移到不同的云真的很困难。 + +有一个问题：每天的流量如何达到 700 M？ StackExchange 每天有 1.5 亿，而 Alexa 评级更高。 \ No newline at end of file diff --git a/docs/156.md b/docs/156.md index 3b86b76..ce6982c 100644 --- a/docs/156.md +++ b/docs/156.md @@ -1,131 +1,255 @@ -# Instagram 架构更新：Instagram 有何新功能？ - -> 原文： [http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html) - -![](img/e7b70a6c02b1e7425849dd6d1af801f2.png) - -对 Instagram 的迷恋仍在继续，幸运的是，我们有了一些新的信息流来满足人们的疯狂需求。 因此，请考虑对 [Instagram 架构 Facebook 的收购，以 10 亿美元的价格](http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html) 为基础，主要基于 [扩展 Instagram](http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram) ，Instagram 联合创始人 Mike Krieger 为 AirBnB 技术演讲提供的幻灯片。 本文底部还列出了其他几种信息来源。 - -不幸的是，我们只有一个幻灯片，因此缺少演讲的结缔组织，但它仍然非常有趣，以开发人员出现后我们经常看到的相同的智慧演讲的精神 在战 significant 中花费大量时间后获得空气。 - -如果您希望深入了解技术细节并找到收购 Instagram 的十亿原因，您会感到失望的。 在所有用户和产品之间的关系投入的情感投入中，而不是在如何管理字节方面，可以发现这种魔力。 - -那么 Instagram 有什么新功能？ - -* 一些统计信息： - * Instagram 在不到两年的时间内就达到了 30+百万用户，然后在其 Android 应用程序发布 10 天后猛增至 4000 万用户。 - * Android 发行后，他们在 12 小时内拥有 100 万新用户。 -* Instagram 的使命是交流和分享现实世界。 -* 世界已经改变。 现在有 2 位后端工程师可以将系统扩展到 30+百万用户： - * 最初是两个没有后端经验的人 - * 托管在洛杉矶的一台计算机上，功能不如 MacBook Pro - * 第一天注册 25K，使机器融化，因此他们迁移到了亚马逊 - * 2 位工程师在 2010 年。 - * 2011 年有 3 名工程师 - * 5 位工程师，2012 年，后端 2.5。 这包括 iPhone 和 Android 开发。 - * 稀缺性引起关注。 -* 您最初遇到的大多数扩展问题都不会很吸引人： - * 缩放就像在以 100 mph 的速度行驶时更换汽车上的所有组件。 - * 缺少的 favicon.ico 在 Django 中引起了很多 404 错误 - * memcached -t 4 - * 前叉/后叉 - * 不幸的是，我们没有有关问题所在的详细信息 -* Instagram 哲学： - * 简单 - * 经过优化，可最大程度地减少操作负担 - * 可以检测所有内容 -* 当用户上传带有可选标题和位置的照片时会发生什么？ - * 为用户同步写入媒体数据库。 - * 如果对异步处理进行了地理标记，则将图像发布到 Solr 进行索引。 - * 通过 Redis 中存储的列表传递给关注者。 对于跟随该用户的每个人，媒体 ID 都会被推送到列表中。 在渲染提要时，它们会获取少量 ID，并在内存缓存中查找它们。 -* 扩展数据库： - * Django ORM 和 PostgreSQL - * 选择 Postgres 是因为它具有 PostGIS（PostgreSQL 的空间数据库扩展）。 - * 将数据库移到了自己的计算机上，但是照片不断增长，EC2 中最大的计算机上的内存限制为 68GB - * 下一个策略是垂直分区，将功能转移到自己的服务器上。 Django DB 路由器非常简单，例如，将照片映射到 photodb。 - * 然后，当照片数据库达到 60GB 并且无法再在一台计算机上运行该数据库时，他们开始使用分片。 - * PostgreSQL 可以通过使用 memcached 进行轻度缓存来处理数万个请求。 - * 所有快照均来自从属服务器，从属服务器在拍摄快照之前已停止，然后 XFS 冻结所有驱动器，然后拍摄快照以确保其一致性。 - * 在 EBS 驱动器上使用 Software-RAID 可获得更好的写入吞吐量。 预写日志（WAL）与主数据库位于不同的 RAID 中。 -* 使用了预拆分逻辑分片策略： - * 基于用户 ID 的分片。 - * 分片的问题之一是，分片比机器大。 因此，他们制作了成千上万个逻辑分片，映射到更少的物理节点。 - * 保留逻辑碎片到物理的映射。 - * 当机器装满时，可以将逻辑碎片移动到新机器上以减轻压力。 优点是无需重新分配任何内容。 按间接级别保存。 - * PostgreSQL 的 [模式](http://www.postgresql.org/docs/9.0/static/ddl-schemas.html) 功能非常有帮助，但是我无法从幻灯片中确切地看出来。 - * Membase 使用类似[的方法](http://www.couchbase.com/docs/membase-manual-1.7/membase-architecture.html)。 -* 如下图： - * V1：简单数据库表：（源 ID，目标 ID，状态） - * 需要回答以下问题：我应该关注谁？ 谁跟着我？ 我会遵循 X 吗？ X 跟随我吗？ - * 随着数据库繁忙，他们开始在 Redis 中存储跟随图的并行版本。 这导致一致性问题，这需要引入缓存无效化和许多额外的逻辑。 -* Love Redis 的目标： - * 将复杂的对象缓存到您想做的事中：GET，计数，子范围，成员资格测试 - * 快速插入和快速子集 - * 大小相对有界的数据结构 - * 当 Redis 实例超过 40k req / s 并开始成为瓶颈时，启动另一台计算机，即 SYNCing to master，并向其发送读取查询不到 20 分钟。 -* 监视所有内容。 - * 提出类似问题：系统现在如何？ 这与历史趋势相比如何？ - * [Statsd](http://github.com/etsy/statsd/) -一种网络守护程序，可将数据聚合并汇总为石墨 - * 具有两种统计信息：计数器和计时器。 - * 统计信息可以动态添加 - * 计数器存储着从每秒注册次数到点赞次数的所有内容 - * 计时提要的生成时间，关注用户所需的时间以及任何其他主要操作。 - * 实时允许立即评估系统和代码更改 - * 日志记录调用以较低的采样率插入整个 Web 应用程序，因此不会影响性能。 - * [Dogslow](http://blog.bitbucket.org/2011/05/17/tracking-slow-requests-with-dogslow/) -监视正在运行的进程，如果发现任何花费超过 N 秒的时间，它将快照当前进程并将文件写入磁盘。 - * 找到的响应要花 1.5 秒钟以上的时间才能返回，响应通常卡在 memcached set（）和 get_many（）中。 - * 他们使用 Munin 看到 Redis 正在处理 50k req / s -* node2dm-一个 node.js 服务器，用于向 Android 的 C2DM 服务传递推送通知 - * 由 Instagram 撰写，因为他们找不到其他东西。 - * 处理了超过 500 万个推送通知 - * 它是 [开源](http://github.com/Instagram/node2dm) -* 与出色的顾问团聚。 Instagram 从一个好的堆栈和糟糕的配置开始。 他们最终在两方面都做得很好。 现在，他们几乎没有停机时间，每小时部署几次，而综合测试仅需 5 分钟即可运行。 其中一些来自技能和先验知识，但大部分来自适应性和当顾问（例如，亚当·德安杰洛）提出更好的选择时愿意迅速转换的意愿。 （此摘要来自参加演讲的 [鲜寿](http://news.ycombinator.com/item?id=3832556) ）。 -* 您无法经常使用的工程师解决方案，因为它们已损坏： - * 进行广泛的单元和功能测试 - * 保持干燥-不要重复自己 - * 使用通知和信号拥抱松散耦合。 - * 用 Python 完成大部分工作，并在必要时使用 C 语言 - * 使用频繁的代码检查和拉取请求将事情留在共享的头脑中 -* 可以动态添加的实时统计信息，使您无需等待接收新数据即可进行诊断和交火。 -* 如果可能要考虑读取容量，则理想的是提前提起读取从属设备并使其轮换使用； 但是，如果出现任何新的读取问题，请提前了解如何轮换使用更多读取容量的选择。 -* 通常，后端基础架构中的一个成为瓶颈。 弄清楚实际的实时应用服务器遇到的问题可以帮助解决这个问题。 -* 使用您知道的技术/工具，然后首先尝试使其适应简单的解决方案。 -* 对 Redis 等核心数据存储有多种补充。 -* 尽量不要让两个工具完成相同的工作。 -* 如果需要，知道在哪里卸载负载。 例如，显示较短的提要。 -* 不要重新发明轮子。 例如，如果应用服务器快要死了，请不要编写其他监视系统。 HAProxy 已经执行了此操作，因此请使用它。 -* 专注于让自己拥有更好的东西：快速，美观，照片共享。 使快速零件更快。 我们所有的请求都可以占用 50％的时间吗？ -* 保持敏捷，提醒自己重要的事情。 -* 用户不在乎您编写自己的数据库。 -* 不要将自己的内存数据库作为主要数据库存储的解决方案。 -* 遇到扩展挑战时，您别无选择。 -* 不要过度优化或期望提前知道网站的规模 -* 不要以为会有其他人加入并对此进行照顾。 -* 对于社交创业公司来说，解决扩展方面的挑战很少（如果有的话） -* 仅将经过优化以简化操作的软件添加到堆栈中 -* 玩得开心。 -* Instagram 在理解设计中的心理学力量而非技术方面取得了更多成功。 -* 想法是可抛弃的：如果一个想法行不通，您很快就会转向另一个想法。 -* 关键字是简单性。 -* 时间很重要。 你自己做运气。 -* 社交网络的真正社交部分： - * 出席斯坦福大学，全球最大的风险投资家的注意力将转移到您身上。 - * 在竞争激烈的初创企业中，成功与您所认识的人和所认识的人同样重要。 谈话后，请务必花一些时间来认识您周围的人。 - * 您建立的社交关系与成功直接相关。 企业家有一些偶然性，但是造雨者是企业家需要见面的人，以便建立成功的联系。 （摘自尤因·马里昂·考夫曼基金会资深研究员特德·佐勒）。 +# Aeron：我们真的需要另一个消息传递系统吗？ + +> 原文： [http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html](http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html) + +![](img/3172dea1863b98ea825fe6957b36e4bf.png) + +我们真的需要 [另一个](https://www.youtube.com/watch?v=dq4aOaDXIfY) 消息传递系统吗？ 如果它承诺使用创新的设计，以每秒一百万微秒的延迟在机器之间以百万微秒的延迟将数百万条消息以一致的响应时间传递给大量客户端，那么我们可能会做到。 + +这就是 [Aeron](https://github.com/real-logic/Aeron) （凯尔特神 战斗，而不是主持人，尽管告诉搜索引擎），这是 [Todd Montgomery](https://twitter.com/toddlmontgomery) 团队开发的一种新型高性能开源消息传输库， 多播和可靠协议专家，编译器优化专家 [Richard Warburton](http://insightfullogic.com/blog/) 和 [Martin Thompson [](https://twitter.com/mjpt777) ，这是面糊的表演黑帮。 + +声称 Aeron 已经在吞吐量方面击败了最好的产品，并且延迟匹配了最高达 90％的最佳商业产品。 Aeron 可以以每秒 600 万条消息的速度推送 40 字节的小消息，这是非常困难的情况。 + +以下是马丁在 Strangeloop 上对 Aeron 的演讲： [Aeron：开源高性能消息传递](https://www.youtube.com/watch?v=tM4YskS94b0) 。 我将简要介绍他的演讲，并整合到本文末尾列出的信息源中。 + +Martin 和他的团队处于令人羡慕的位置，拥有一个需要像 Aeron 这样的产品的客户，并愿意为其开发提供资金，同时也使其开源。 因此，在 GitHub 上运行 git [Aeron](https://github.com/real-logic/Aeron) 。 请注意，对于 Aeron 来说还处于初期，他们仍处于繁重的优化阶段。 + +世界已经改变，因此端点需要前所未有的扩展。 这就是为什么马丁说我们需要一个新的消息传递系统的原因。 现在是一个多面的世界。 我们拥有多核，多插槽，多云，数十亿用户计算，通讯一直在发生。 大量的消费者定期对要从同一发布者读取的频道进行捣乱，这会导致锁争用，排队效应，从而导致吞吐量下降和延迟高峰。 + +我们需要一个新的消息库来充分利用这个新世界。 [转向微服务](https://groups.google.com/forum/#!topic/mechanical-sympathy/fr7moLcsuiI) 仅增加了需求： + +当我们进入微服务世界时，我们需要从通信中获得非常低且可预测的延迟，否则 [USL](http://www.perfdynamics.com/Manifesto/USLscalability.html) 的一致性部分将会出现 雨火和硫磺在我们的设计上。 + +使用 Aeron 的目标是保持事物的纯正和专注。 到目前为止，我们所做的基准测试表明吞吐量和延迟方面的进步。 十分独特的是，您不必在吞吐量和延迟之间进行选择。 对于其他高端消息传输，这是一个独特的选择。 Aeron 使用的算法可提供最大的吞吐量，同时将直到饱和的等待时间最小化。 + +“许多通讯产品都是瑞士军刀； [说](https://groups.google.com/d/msg/mechanical-sympathy/fr7moLcsuiI/IMvQY_bCQf8J) Martin，这是了解 Aeron 的好方法。 它不是您习惯的全功能消息传递产品，例如 [Kafka](http://kafka.apache.org/) 。 Aeron 不保留消息，不支持有保证的传递，也不支持群集，也不支持主题。 Aeron 不会知道客户端是否崩溃了，也无法从历史记录同步备份或从历史记录初始化新客户端。 + +将 Aeron 置于心理矩阵中的最佳方法可能是将其作为面向消息的 TCP 替代品，并在其上写入更高级别的服务。 Todd Montgomery [扩展了](https://groups.google.com/d/msg/mechanical-sympathy/fr7moLcsuiI/XsKndzoR6ycJ) 的构想： + +Aeron 是 ISO 第 4 层协议，它提供了许多消息传递系统无法提供的功能，也没有提供某些消息传递系统可以提供的功能.... 让我稍微解释一下所有典型的消息传递系统（不仅是 Kafka 和 0MQ）。 + +一种更多考虑 Aeron 适合何处的方法是 TCP，但是可以选择可靠的多播传送。 但是，这在一定程度上是有限的，因为 Aeron 在设计上也具有许多可能的用途，这些用途远远超出了 TCP 的功能范围。 以下是一些要考虑的事项： + +Todd 继续提供更多详细信息，因此请继续阅读文章以了解更多有关该主题的信息。 + +Aeron 的核心是 **复制的消息持久记录** 。 通过非常有意识的设计过程，消息从发布到接收的整个过程都是无等待的，零复制。 这意味着延迟非常好并且非常可预测。 + +总结 Aeron 简而言之。 它是由一支经验丰富的团队创建的，使用了以前许多项目中都得到强化的扎实的设计原则，并得到了并非所有人都拥有的技术支持。 每个方面都经过精心设计，干净，简单，高性能和高度并发。 + +如果说简单与聪明是无法区分的，那么 Aeron 就有很多聪明之处。 让我们看看他们是如何做到的... + +请注意，Martin Thompson 的 [这个话题](https://www.youtube.com/watch?v=tM4YskS94b0) 正在进行中。 我尽了最大的努力来捕捉想法，但是您没有得到的感觉就是它们融合在一起的程度。 马丁在传达这种整体感方面做得很出色，这就是为什么这次演讲值得一看。 + +## 其他 + +* *Todd Montgomery 继续说。*。关于 Aeron 适合何处的一种思考方式是 TCP，但可以选择可靠的多播传递。 但是，这在一定程度上是有限的，因为 Aeron 在设计上也具有许多可能的用途，这些用途远远超出了 TCP 的功能范围。 这里有几件事情要考虑： + + * 及时识别具有完整记录边界的“持久”数据流。 这是{channel，sessionId，channelId，offset，length}元组，它是日志缓冲区策略的核心。 这使得具有任意回放的流的非易失性存储能够掉出……这非常有趣。 这导致以真正机械的同情方式进行数据流的重新连接和持久化。 我对此压力太大了。 实际上，这也为传输协议提供了真正的位置透明性。 即本地订户可以直接从发布者的日志缓冲区中读取，而驱动程序则透明地将数据发送给现成的订户。 到目前为止，我们已经确定了这些内容，但是我认为这也可以应用于处理主动/被动前​​向纠错，轮播，任意重放等的独特方法。 + + * Aeron 没有主题。 它具有单独的非竞争流。 大多数消息传递系统都提供主题空间。 这是一种祝福和诅咒。 通过为 Aeron 故意保留有界的实现方式（但不受设计限制）的流空间，Aeron 允许在顶部构建主题空间（这使 0MQ 和许多其他系统可以利用它）而不会将实现锁定在浪费资源上 对于那些不需要它的用例。 + + * 可靠的单播设计是一种模仿 TCP 的熟悉的防火墙可穿越设计。 但是可靠的多播设计允许发布/订阅语义具有无限可配置的流控制策略。 这不仅提供了普通的消息传递，流传输等各种用例可能性。 + +* 传输媒体已更改。 消息不再只是通过 TCP。 更多的多播正在发生。 Infiniband 正在高性能领域起飞。 [PCI Express](http://en.wikipedia.org/wiki/PCI_Express) 3.0 具有内置的内存模型，因此可以在计算机之间的总线之间传输字节。 这就是许多高性能空间的去向。 + +* 我们需要在同一台机器上的进程和套接字之间进行通信。 随着使用越来越多的内核构建机器，它们实际上成为了一个盒子中的数据中心。 英特尔的新款 [Haswell CPU](http://www.extremetech.com/computing/189518-intels-new-18-core-haswell-xeon-chips-will-try-to-preempt-the-arm-server-onslaught) 每个插槽具有 18 个内核，每个内核具有两个超线程。 在一台计算机上可能同时运行 240 个线程，我们需要一种方法来分工并有效地进行通信。 + +* 用纯 Java 8 编写，并利用了该版本新引入的 lambda 表达式。 + +* 对等而不是代理解决方案，这是它具有如此低的延迟的原因之一。 + +* 使用 UDP 并将很快拥有 SHM IPC 和 Infiniband。 + +* 构建高性能系统的秘诀在于简单性。 复杂性会降低性能。 追求简洁的简洁设计。 + +* 通过提供替代算法提供带有可插拔钩子的自己的流控制。 + +* 不支持群集和存档的消息，尽管将来的项目可能会添加一些此功能。 + +* 可靠的多播传递。 + +* Aeron 本质上将日志缓冲区从一台机器复制到另一台机器。 从功能上来说，缓冲区是持久的，因为存储的记录不会发生突变，也不会持久存储到磁盘。 + +* 提供可靠的交货，但不能保证。 如果订户死亡并超时，则将不会重试消息传递。 可以在 Aeron 之上分层协议以存档已发布的消息，以便订户可以恢复，但这不在基本功能之内。 + +* 不提供交易担保。 因此，要约完成后，当要约返回时，要么被拒绝，要么被放置在共享内存日志缓冲区中，由驱动程序发送。 在流量控制允许的范围内，驱动程序会尽力发送。 但是，Aeron 确实尽力将其提供给订户。 这是一种尽力而为的传递保证，就像 TCP 一样，但是要好一点，因为它可以处理 TCP 无法实现的某些连接故障。 但这并不能保证。 + +* 为了测试捕获完整的等待时间直方图，同时尝试多个线程同时发布从而发生竞争的情况。 还要与许多其他消息传递因素进行比较。 例如 IPC /单播/多播，不同的消息大小等。 + +## 基本操作 + +* 发布者通过一个频道发送消息，供订阅者阅读。 频道内是流向订户的流。 + + * 通道保持消息有序。 信息流彼此独立，因此它们不会相互阻塞。 + + * 检测到损失并以对延迟和吞吐量的最小影响进行处理。 + + * 使用流量控制和背压以免淹没客户。 + + * 拥塞避免和控制处理经过拥塞网络的数据包。 它被认为是高性能领域中的一项可选服务。 当发生拥塞时，需要此服务，但是在等待时间需要尽可能低的情况下，拥塞控制算法会使您减速。 一个示例是 TCP 的 [慢启动](http://en.wikipedia.org/wiki/Slow-start) 问题，因为 TCP 试图避免用流量淹没网络。 + + * 在处理非常大的消息，处理碎片并避免 [行头阻塞](http://en.wikipedia.org/wiki/Head-of-line_blocking) 的同时，在通道中对流进行多路复用和多路分解。 + +* 不是框架，而是图书馆。 这是一种可组合的设计，因此可以在其之上构建其他层。 + +* 设计大约涉及三件事：系统架构，数据结构和协议交互。 + + * 正确构建架构，并使其美观整洁。 + + * 数据结构非常重要。 + + * 如今，人们不再强调良好的协议工作，这是分布式代理进行通信和合作时的基础。 + +## 架构 [ + +* 发布者发布，订阅者订阅。 您可以在两台计算机之间进行双向通信，但是每台计算机都需要分别注册一个发布者和一个订阅者。 一对发布者和订阅者只是一种通信方式。 + +* 通信通过 UDP，UDP 多播，Infiniband，PCI-e 3.0，RDMA 等媒体进行。 + +* 发送者负责通过媒体发送数据，而接收者则通过媒体接收数据。 发送者和接收者是在各自的线程中运行各自工作的独立代理。 现代处理器确实擅长于一遍又一遍地执行相同的操作，因为它们的高速缓存中存储着指令和数据。 + +* 导体是独立的代理，可以完成所有不在 A 和 B 之间发送字节的工作。这包括内部管理和管理员（如用户设置，新出版物的事件，新的订阅以及告诉系统正在发生的事情）。 + +* 发送方和接收方保持非常简单和整洁，因此它们可以使用最佳方法在媒体上的两点之间尽快传输数据。 + +* 在同一进程中没有共享数据结构。 通信正在使用消息传递。 导体使用消息通过非阻塞结构进行通信。 这允许使用干净的单线程代码，该代码可以运行得很快。 避免了并发和使用队列的锁定。 + +* 明确分开的关注点意味着可以选择零件的放置位置。 它们都是独立的代理程序，具有自己的线程，运行自己的代码，具有自己的内部数据结构，这些数据结构不共享，因此它们不需要并发，不需要锁，因此可以实现令人难以置信的执行 快速。 + + * 导体分为为发送者和接收者提供服务所需的内容以及为客户端提供服务所需的内容。 而且由于通讯不使用共享内存，而是在队列中，因此可以将 Conductor 的这些部分拆分为单独的进程。 媒体驱动程序可以处于自己的进程中，客户端可以处于其自己的进程中。 或者，媒体驱动程序可能位于内核中。 或在 FPGA 中。 + +## 数据结构 + +* Java 中的数据结构过于复杂，间接性太多，这意味着性能低下，因此他们构建了自己的映射，IPC 环形缓冲区，IPC 广播缓冲区，ITC 队列，动态数组，日志缓冲区。 + +* 环形缓冲区用于在导体，客户端和驱动程序之间进行通信。 + +* 还需要将事件从驱动程序发送到多个客户端，而不会降低驱动程序的速度，而不考虑客户端的数量，因此广播用于事件。 + +* 许多数据结构在动态变化，例如给定订阅的订阅者数量，发布的发布者数量，这些数据结构必须是动态的且无阻塞的。 日志缓冲区用于将消息从发布移动到订阅。 + +## 永久日志 + +* 消息与标头一起存储在持久日志结构中。 （更多关于日志结构[在此处](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)的介绍）。 + +* 日志已映射到磁盘，但使用内存映射文件保存在内存中。 日志活在文件中，因为文件可跨进程使用。 文件被映射到内存中，从而避免了必须进行系统调用才能进入磁盘的过程。 + +* 不变的数据结构可以安全无锁地读取，因为它们会随着时间增长。 + +* 描述了添加消息的协议和状态机。 添加消息不涉及任何锁。 + + * 首先，将尾部原子地向前移动，以便另一个线程可以在同一时间添加一条消息。 + + * 现在可以添加消息了。 该消息被复制到缓冲区。 + + * 为了表示一条消息已完成，将单个字操作写入消息头中的字段。 + + * 消息标头已完全写入日志，因此向发送方发送消息只需要编写标头和消息的连续字节，无需动态编写，因此将消息发送至发布者非常有效 很多客户。 + +* 日志不仅仅是随时间增长的单个文件。 单一文件设计虽然很常见，但存在很多问题。 因为页面错误会一直发生，并且页面错误非常昂贵，这会增加 VM 压力和页面搅动（这是 [页面错误成本](https://plus.google.com/+LinusTorvalds/posts/YDKRFDwHwr6) 上的 Linus Torvalds） ）。 页面错误并没有变得越来越快，过程也越来越快，因此差距是巨大的（尽管这一直是正确的，为什么页面错误总是要避免的原因）。 + +* 单个文件方法的替代方法是保留三个缓冲区：干净，脏，活动。 活动缓冲区是您正在写入的缓冲区。 肮脏是永恒的历史。 清除是下一个变为活动状态的缓冲区。 导体可以在后台进行清理，因此写入它们不会造成等待时间的损失。 缓冲区在缓存中都很热，因此没有页面缓存正在进行。 另一个线程可以将脏缓冲区存档到另一个数据存储中，以便可以永久保存消息。 + +* 这是免等待时间的实现方式。 假设有两个编写者试图在两个不同的线程中由两个不同的发布者同时将消息 X 和 Y 写入日志，可能是在不同的过程中写入同一驱动程序。 由于驱动程序用尽了进程，因此可以在多个进程之间共享。 Y 赢得比赛以增加尾巴。 然后 X 递增尾部，但是尾部越过缓冲区的末端。 Y 可以使用它分配的空间。 填充记录放置在 Y 的末尾与缓冲区的末尾之间，因此缓冲区始终是连续且完整的。 X 负责旋转到下一个缓冲区，在该缓冲区中它将消息从缓冲区的开头写入新的尾部。 所有这些工作并没有导致线程的任何延迟。 它完全独立发生，没有阻塞操作。 如果某个进程中断，则其他所有线程均不会阻塞。 + +## 发送消息 ， + +* 标头包含版本信息； 旗; 消息类型； 帧长 术语“偏移量”，即到缓冲区的偏移量，这是将其复制到另一端的位置； 会话 ID，流 ID； 条款 ID； 编码的消息。 所需的所有内容都在标头中，因此可以将其直接写入网络。 写入帧长字节后，消息已发送。 + +* 标头设计的有趣含义是，流中的每个字节在整个时间上都有唯一的标识符，这是 streamId，sessionId，termId，termOffset 的复合键。 稍后将使用此功能，以便接收者可以告诉发送者日志的哪个区域被删除，因此发送者可以从该点重新发送。 + +* 使用消息协议在发送方和接收方之间复制日志。 发送方要发送消息时，会向接收方发送设置消息。 接收方发回状态消息。 发送方开始向接收方发送数据。 接收方发送更多状态消息，告诉发送方它还有 X 的剩余空间，因此您可以继续发送。 消息不被确认，NAK 代替。 为了最小化[内爆效应](ftp://www-net.cs.umass.edu/pub/Rubenst98:Proact-TR-98-19.ps.gz)，大多数现代组播协议使用 NAK 代替 ACK。 接收者告诉发送者它还剩下多少空间，这比基于 ack 的方法所需的消息更少。 它为您提供了一种实现流量控制和背压的机制。 + +* 发送方将其作为心跳发送的最后一条消息发送给接收方。 这种方法还可以处理丢弃最后一条消息的情况（请记住，正在使用 UDP）。 + +* 当接收者知道有一条消息被丢弃时，它将向发送者发送一个 NAK，用于查找丢失的术语区域。 在这一点上，请记住，正在复制的是日志，因此接收方可以假定整个日志可用，而不仅仅是很小的窗口大小。 + +* 接收者具有发送者中相同数据结构的副本。 标头和消息被写入日志。 有两个计数器：已完成和高水位标记。 假设已写入消息 1，消息 3 出现在消息 2 之前，因为存在订购问题。 完成的计数器指向消息 1 的末尾。高水位标记指向消息 3 的末尾。消息 2 应该有一个孔。 已完成指向连续的消息流。 如果消息 2 到达完成，则向前移动以指向消息 3 的末尾。 + +* 使用这种方法，您无需保留遗漏邮件的跳过列表或历史记录中有空白的地方。 这些额外的数据结构很复杂，而且速度很慢。 它们导致并发问题和高速缓存未命中。 + +* 日志缓冲区在内存中是完全线性的。 访问它们只需要向前迈进内存，这确实是硬件友好的。 指针追逐在性能上确实很糟糕，因为它们会导致页面错误。 + +* 此表示形式也非常紧凑。 您可以通过记忆尖叫。 + +* 此设计是回到基础的结果。 考虑如何解决丢失，重新排序，保留历史记录，同时保持内存和并发友好的问题。 结果是一个持久的数据结构，其速度比任何现有方法都要快。 [持久数据结构](http://en.wikipedia.org/wiki/Persistent_data_structure) 是一种数据结构，在修改后始终保留其自身的先前版本。 从轨道的功能角度来看，这是一个想法。 学科合作时，有很多东西要学习。 只执行功能性技术或忽略功能性技术是愚蠢的。 + +* 导体始终在完成和高水位线之间寻找间隙。 它将发送 NAK，因此发送方将重新发送日志的该部分。 这是简单且易于调试的。 + +* 要了解消耗了哪些消息，请使用指向字节流中某个位置的计数器。 发布者，发送者，接收者和订阅者都在字节流中保留位置计数器。 这使得监视，应用流量控制和拥塞控制变得容易。 这些计数器在另一个内存映射文件中可用，因此它们可用于单独的监视应用程序。 + +* 协议很难。 您需要注意大规模的自相似行为。 例如，在多播世界中，当出现问题时，您会得到一种称为自相似行为的信息，这种行为会开始发生模式并建立起共振。 因此必须将随机性注入系统。 NAK 必须在将来的某个随机点发送。 这样可以防止订户立即全部锤击源。 + +## 吸取的教训 [ + +* **人们以** n 估算值吸吮。 即使有团队的丰富经验，他们的估计也全都没有了。 估算只是人类不擅长的事情。 + +* **构建分布式系统非常困难** 。 只有不想构建分布式系统的人才有资格构建一个分布式系统，因为他们至少对工作的辛苦程度有所了解。 您只是不能说嘿，让我们创建一个分布式的并发系统。 首先制作一个单线程系统，然后再进行其余工作。 + +* **我们的防御代码比特征代码** 更多。 在分布式系统上，事情可能会大规模出错，并且那些故障需要得到处理。 这并不意味着代码中充满了异常处理程序。 他们知道很多失败案例，但是仍然有很多防御性代码。 + +* **建立分布式系统是对** 的奖励。 看到整个机器网络针对注入的故障进行调整并全部得到纠正是一件很美好的事情。 + +* **从一开始就设计监视和调试** 。 从一开始就让一切可见。 无锁方法的优点之一是，您实际上可以从另一个线程观察状态，这使调试更加容易。 + +* **由于配置** ，我们将 3x-4x 的性能留在桌面上。 程序员和系统管理员的分离是一种反模式。 开发人员不会与没有 root 访问权限的人交谈，而不会与拥有网络访问权限的人交谈。 这意味着系统永远不会配置正确，这会导致大量数据包丢失。 丢失，吞吐量和缓冲区大小都与 密切相关。 我们需要锻炼如何弥合差距，知道参数是什么，以及如何解决它们。 因此 知道您的 OS 网络参数以及如何对其进行调整 。 + +* **Java 的某些部分确实很烂** 。 无符号类型； NIO 系统布满了锁； 很难在沙盒模型中进行堆外工作并获得所需的性能； 字符串编码不应要求复制缓冲区三次； 有些人是成年人，让我们映射和取消映射内存映射文件，并像成年人一样使用套接字。 哈希图周围的垃圾回收问题是痛苦的； 或字节标志会将字节提升为整数，因此您无法将结果分配回一个字节； + +* **Java 的不错部分** 。 工具。 Java 是世界上最糟糕的语言，拥有世界上最好的工具链：IDE，Gradle，HdrHistogram。 Java 的 lambda 和方法句柄非常好。 字节码检测对于调试确实很有用。 例如，Java 8 中的不安全性非常好，这就是计数器无锁递增的方式，并且可以在 CPU 上很好地扩展，并且内存栅栏使构建广播缓冲区成为可能。 优化器很棒。 垃圾回收对于某些类的算法非常有用。 + +* **平均值绝对没有意义** 。 注意百分位数。 + +## 未来 [ + +* 现在功能已完成。 现在进行大量的分析和优化。 + +* 情况看起来很好。 在吞吐量方面已经击败了最好的产品。 可以以每秒 600 万条消息的速度发送 40 字节的小消息，这是非常困难的情况。 时延看起来很棒，那里有最好的商业产品，高达 90％。 除了 90％的百分位数之外，还有很多工作要做，部分是基于算法，​​还有 NIO，选择器和锁。 + +* 接下来是 C ++端口。 + +* Infiniband 和 IPC。 ## 相关文章 -* [Slidedeck](http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram) -在 Airbnb 技术讲座上，Instagram 的 Mike Krieger 在扩展 Instagram 上 -* [如何扩展 10 亿美元的创业公司：Instagram 联合创始人的指南](http://techcrunch.com/2012/04/12/how-to-scale-a-1-billion-startup-a-guide-from-instagram-co-founder-mike-krieger/) -* [在 HackerNews 上](http://news.ycombinator.com/item?id=3831865) ， [在 HackerNews 上](http://news.ycombinator.com/item?id=3804351) -* [成为 Instagram 成功背后的老路](http://www.nytimes.com/2012/04/14/technology/instagram-founders-were-helped-by-bay-area-connections.html) -* [Instagram 的用户数现在达到 4000 万，在过去 10 天内吸引了 1000 万新用户](http://techcrunch.com/2012/04/13/instagrams-user-count-now-at-40-million-saw-10-million-new-users-in-last-10-days/) -* [在十二小时内使 Instagram 拥有超过一百万的新用户](http://instagram-engineering.tumblr.com/post/20541814340/keeping-instagram-up-with-over-a-million-new-users-in) +* [在 Reddit](http://www.reddit.com/r/programming/comments/2ml0gb/aeron_do_we_really_need_another_messaging_system/) 上/ [在黑客新闻](https://news.ycombinator.com/item?id=8619735)上 + +* [Aeron 高性能开源消息传输](http://gotocon.com/dl/goto-berlin-2014/slides/MartinThompson_AeronTheNextGenerationInOpenSourceHighPerformanceMessaging.pdf) + +* [Martin Ahompson 撰写的“ Aeron：开源高性能消息传递”](https://www.youtube.com/watch?v=tM4YskS94b0) + +* [GitHub 上的 Aeron](https://github.com/real-logic/Aeron) + +* Aeron [协议规范](https://github.com/real-logic/Aeron/wiki/Protocol-Specification) 和 [设计概述](https://github.com/real-logic/Aeron/wiki/Design-Overview) 。 + +* [日志：每位软件工程师应了解的有关实时数据统一抽象的知识](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying) + +* [Google：驯服长时间延迟的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) + +* [伟大的微服务与整体应用 Twitter 近战](http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html) + +* [简单二进制编码](http://mechanical-sympathy.blogspot.com/) + +* [本周要去 Strangeloop 吗？ 您的“必看”清单上有哪些讲座？](https://groups.google.com/forum/#!topic/mechanical-sympathy/fr7moLcsuiI) + +* [Aeron 性能测试](https://groups.google.com/forum/#!topic/mechanical-sympathy/GrEce0gP7RU) + +* [策略：利用处理器亲和力实现高性能和可预测的性能](http://highscalability.com/blog/2012/3/29/strategy-exploit-processor-affinity-for-high-and-predictable.html) + +* [12 种将吞吐量提高 32 倍，将延迟降低 20 倍的方法](http://highscalability.com/blog/2012/5/2/12-ways-to-increase-throughput-by-32x-and-reduce-latency-by.html) + +* [破坏了 4 个现代硬件神话-内存，HDD 和 SSD 真的是随机访问吗？](http://highscalability.com/blog/2013/6/13/busting-4-modern-hardware-myths-are-memory-hdds-and-ssds-rea.html) + +* [对 Apache Kafka 进行基准测试：每秒 200 万次写入（在三台便宜的机器上）](http://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines) + +* [HdrHistogram](https://github.com/HdrHistogram/HdrHistogram) -高动态范围（HDR）直方图。 + +非常感谢您提供大量信息来总结并做得很好，但是声明“发布者和订阅者之间的全双工通信”并不是很准确。 发布者发布，订阅者订阅。 您可以在两台计算机之间进行双向通信，但是每台计算机都需要分别注册一个发布者和一个订阅者。 一对发布者和订阅者只是一种通信方式。 -> 通过存储在 Redis 中的列表传递给关注者。 对于跟随该用户的每个人，媒体 ID 都会被推送到列表中。 在渲染提要时，它们会获取少量 ID，并在 memcached 中查找它们 +另外，当您说“并非所有邮件都被确认”时，我们不会确认数据包。 我们使用 NAK 代替，我的理解是实际上大多数现代多播协议使用 NAK 代替 ACK 来最小化内爆效应。 -我是 Web 技术的新手，很好奇：在服务器上已经设置 Redis 时使用 memcached 有什么意义？ 谢谢。 +太好了，谢谢理查德的改正！ -@Oleg：我认为 user_id 可能在存储的 redis 中，并且 memcache 将使整个用户记录+来自主数据存储的联接数据。 +“面对面”，认真吗？ -知道 Instagram 图片的磁盘平均大小是多少吗？ \ No newline at end of file +是的，我猜这翻译得不好。 它引用了犹他爵士乐团的约翰·斯托克顿（John Stockton），他是 NBA 历史上最好的球员之一。 因此，这是一个受人尊敬的术语，这就是它的意思。 \ No newline at end of file diff --git a/docs/157.md b/docs/157.md index 25d14bd..f63715e 100644 --- a/docs/157.md +++ b/docs/157.md @@ -1,111 +1,103 @@ -# YouPorn-每天定位 2 亿次观看 - -> 原文： [http://highscalability.com/blog/2012/4/2/youporn-targeting-200-million-views-a-day-and-beyond.html](http://highscalability.com/blog/2012/4/2/youporn-targeting-200-million-views-a-day-and-beyond.html) - -![](img/05b77736b31c0df92d092c23258b4c43.png) - -**更新**：这是演讲的[视频。](http://www.youtube.com/watch?v=RlkCdM_f3p4) - -YouPorn.com 的首席开发人员 [Erick Pickup](https://twitter.com/#!/EricPickupYP) 在 [建立可扩展规模的网站](https://joind.in/6123) 的演讲中介绍了其架构。 HTG8] ConFoo 会议。 如您所料，YouPorn 是一头野兽，每秒流传输三张完整的 DVD 视频，每秒处理 300K 查询，每小时产生多达 15GB 的日志数据。 - -不幸的是，我们只有演讲的幻灯片，因此本文并不像我想的那么技术性，例如在视频处理方面完全不可见，但我们确实得到了一些有趣的细节 。 - -最有趣的方法是，YouPorn 是一个非常传统的 LAMP 堆栈，具有 NoSQL 的功能，因为 Redis 现在在实时数据路径中替换了 MySQL。 简单地让我想起 [YouTube](http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html) 。 - -第二个最有趣的收获是**出色的转换**。 众所周知，永远不要重写，但在 2011 年，YouPorn 重新编写了整个站点，以使用 PHP + Redis，而不是基于 Perl + MySQL 的复杂体系结构。 所有人都认为切换非常顺利。 该站点的速度提高了 10％，他们迁移了 6 年的旧数据，没有停机时间。 - -继续阅读以了解有关 YouPorn 架构的更多信息... - -## 统计信息 - -* 于 2006 年推出，于 2011 年被收购。 -* 2008 年每天 1 亿次页面浏览 -* 30 万个查询/秒 -* 100 Gb / s-每秒流传输 3 张完整 DVD -* 每小时记录 8GB-15GB 数据 - -## 堆栈 - -* 最初用 Perl 编写（具有 DBIx :: Class 后端的 Catalyst 应用程序） -* 现在 [PHP-FPM](http://php-fpm.org/) （FastCGI 流程管理器）-是另一种 PHP FastCGI -* HAProxy -* ActiveMQ -* 清漆 -* Redis -* Nginx -* MySQL -* Syslog-ng -* [Symfony2](http://symfony.com/) -一个 PHP Web 开发框架。 - -## 架构 - -* **大切换** 。 整个站点在 2011 年进行了重写，以使用 PHP 代替复杂的 Perl 架构，并使用 Redis 代替 MySQL 和 ActiveMQ。 - * 定位到 200+百万的每日请求 - * 移动了 6 年的旧数据而没有停机 - * 新网站的速度提高了 10％。 - * 该过程花费了比预期更长的时间： - * 必须决定要使用哪些技术 - * 超出预期的学习曲线 - * 将数据从 MySQL 移动和重组到 Redis - * 人员配备 -* **HAProxy** -提供负载平衡，智能负载分配和运行状况检查 - * 维护两个服务器池：一个具有故障转移到备份主服务器的写池，一个读取池将管理除主服务器之外的服务器。 -* **清漆** -反向代理有助于加快站点速度并减少服务器负载。 还用于缓存管理，边缘包括（ESI）和 Web 服务器上的运行状况检查。 -* **系统记录**-收集页面浏览量数据，并用于查看计数器和相关视频。 -* **Nginx** -高性能 Web 服务器，运行 PHP-FPM，并充当 CSS，图像和 JS 等静态文件的外部 CDN。 -* **Symfony** -快速且功能丰富，带有大量库。 - * 认为 Symfony2 + Redis =快速开发+可扩展网站-一个很好的平衡方程。 - * 喜欢依赖注入。 - * 选择 Web 框架并不意味着要破坏性能，只要您在其前面使用可靠的体系结构即可。 -* **ActiveMQ** -为大型站点设计的消息总线，用于写入 MySQL 和 Redis。 - * 他们发现，对于一个不断变化的站点来说，它太僵化了，所获得的收益不足以维持一个单独的 Java 基础架构。 - * 希望解决问题，因为问题可能更多是开发人员而不是技术人员。 -* **Redis** -一种快速的开源 KV 存储，现在是主要数据源。 - * 实时更新。 - * 已排序的集合用于所有列表 - * [流水线化](http://rediscookbook.org/pipeline_multiple_commands.html) ，用单个原子命令执行多个 Redis 命令，是提高性能的关键 - * 切换后，添加了其他 Redis 节点，这不是因为 Redis 劳累过度，而是因为网卡无法跟上 Redis 的步伐。 - * 所有读取均来自 Redis - * MySQL 用于允许根据需求更改构建新的排序集。 - * [仅附加文件（AOF）[H​​TG2]](http://redis.io/topics/persistence) 格式用于增量备份，并且无 IO 痛苦 - * 考虑将 Redis 用作 Redis 持久性存储之前的临时缓存，以提高性能和减少负载。 -* **MySQL** -支持 Redis 的支持角色 - * 高度规范化，因为它没有直接用于网站。 - * 一些表有 100+百万行。 - * 用于使用新功能填充 Redis 列表 -* 同时使用了 GIT 和 SVN，效果不佳。 -* 在其 CMS 中使用 [教义](http://www.doctrine-project.org/) 。 节省了数周开发时间的强大工具。 +# 机器：惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化 -## 相关文章 +> 原文： [http://highscalability.com/blog/2014/12/15/the-machine-hps-new-memristor-based-datacenter-scale-compute.html](http://highscalability.com/blog/2014/12/15/the-machine-hps-new-memristor-based-datacenter-scale-compute.html) + +> 摩尔定律的终结是过去 50 年来计算机发生的最好的事情。 摩尔定律一直是安慰的专制。 您可以放心，您的筹码会不断进步。 每个人都知道即将发生什么以及何时发生。 整个半导体行业都被迫遵守摩尔定律。 在整个过程中没有新的发明。 只需在跑步机上踩一下，然后执行预期的操作即可。 我们终于摆脱了束缚，进入了自 1940 年代后期以来我们看到的最激动人心的计算时代。 最终，我们处于人们可以发明的阶段，将尝试并尝试这些新事物并找到进入市场的方式。 我们最终将以不同的方式和更聪明的方式做事。 +> +> - [Stanley Williams](http://en.wikipedia.org/wiki/R._Stanley_Williams) （措辞） + +![](img/017f2bcbb550b25f03cd84cdfa8f614b.png) + +惠普一直在开发一种全新的计算机，其名称为*机器*（不是 [这台机器](http://personofinterest.wikia.com/wiki/The_Machine) ）。 该机器可能是惠普历史上最大的 R & D 项目。 这是对硬件和软件的彻底重建。 巨大的努力。 惠普希望在两年内启动并运行其数据中心规模产品的小版本。 + +故事始于大约四年前我们在 [中首次遇到惠普的](http://highscalability.com/blog/2010/5/5/how-will-memristors-change-everything.html) [Stanley Williams](http://en.wikipedia.org/wiki/R._Stanley_Williams) ？ 在忆阻器故事的最新一章中，威廉姆斯先生发表了另一篇令人难以置信的演讲： [机器：用于计算大数据的 HP 忆阻器解决方案 [](https://mediacosmos.rice.edu/app/plugin/embed.aspx?ID=vVUTzFCE006yZu3TF1sXKg&displayTitle=false&startTime=0&autoPlay=false&hideControls=false&showCaptions=false&width=420&height=236&destinationID=URka-_E5-0-e4girH4pDPQ&contentID=vq2oQtAqPkeAqm5F6uSnqA&pageIndex=1&pageSize=10) ，进一步揭示了机器的工作方式。 + +机器的目标是**折叠内存/存储层次结构**。 今天的计算是低能效的。 **消耗了 80％的能量**和大量时间**在硬盘，内存，处理器和多层高速缓存之间移动位**。 客户最终花在电费上的钱比买机器本身要多。 因此，该计算机没有硬盘，DRAM 或闪存。 数据保存在高能效忆阻器，基于离子的非易失性存储器中，数据通过光子网络移动，这是另一种非常省电的技术。 当一小部分信息离开核心时，它就以光脉冲的形式离开。 + +在图形处理基准上，据报道，“机器”基于能效的性能要好 2-3 个数量级，而基于时间的性能要好一个数量级。 这些基准没有详细信息，但这就是要点。 + +**机器首先放置数据** 。 其概念是围绕非易失性存储器构建一个系统，在整个存储器中自由分配处理器。 当您要运行程序时，请 **将程序发送到内存** 附近的处理器，在本地进行计算，然后将结果发送回去。 计算使用了各种各样的异构多核处理器。 与仅移动 TB 或 PB 的数据相比，仅传输程序所需的位和结果可节省大量资金。 + +机器不针对标准 HPC 工作负载。 这不是 LINPACK 破坏者。 HP 试图为客户解决的问题是客户要执行查询并通过搜索大量数据来找出答案。 随着新数据的出现，需要存储大量数据并进行实时分析的问题 + +**为什么构建计算机需要非常不同的体系结构？** 计算机系统无法跟上不断涌入的大量数据。惠普从其客户那里得知，他们需要能够处理越来越多的数据的能力。 **与晶体管的制造速度**相比，收集的位数呈指数增长。 另外，信息收集的增长速度快于硬盘的制造速度。 惠普估计，人们真正想做的事有 250 万亿张 DVD 数据。 全世界从未收集过大量数据，甚至从未查看过。 + +因此，需要一些新的东西。 至少这是惠普的赌注。 尽管很容易对 HP 正在开发的技术感到兴奋，但至少在本世纪末之前，这对您和我来说都不是。 这些将在相当长一段时间内都不是商业产品。 惠普打算将它们用于自己的企业产品，在内部消耗所制造的一切。 我们的想法是，我们还处于技术周期的初期，因此首先要构建高成本的系统，然后随着数量的增长和流程的改进，该技术将可以进行商业部署。 最终，成本将下降到足以出售更小尺寸的产品。 + +有趣的是，HP 本质上是在构建自己的云基础架构，但是他们没有利用商品硬件和软件，而是在构建自己最好的定制硬件和软件。 云通常提供大量的内存，磁盘和 CPU 池，这些池围绕通过快速网络连接的实例类型进行组织。 最近，有一种将这些资源池视为独立于基础实例的方法。 因此，我们看到诸如 [Kubernetes 和 Mesos](https://mesosphere.com/2014/07/10/mesosphere-announces-kubernetes-on-mesos/) 之类的高级调度软件正在成为行业中的更大力量。 惠普必须自己构建所有这些软件，以解决许多相同的问题，以及专用芯片提供的机会。 您可以想象程序员对非常专业的应用程序进行编程以从 The Machine 获得每盎司的性能，但是 HP 更有可能必须创建一个非常复杂的调度系统来优化程序在 The Machine 上的运行方式。 **软件的下一步是一种全息应用程序体系结构的演进，其中功能在时间和空间上都是流动的，并且身份在运行时由二维结构产生。** 日程安排优化是云上正在探索的下一个领域。 + +演讲分为两个主要部分：硬件和软件。 该项目的三分之二是软件，但威廉姆斯先生是硬件专家，所以硬件占了大部分。 硬件部分基于**优化围绕**可用的物理原理的各种功能的思想：**电子计算； 离子存储 光子通信**。 + +这是我对威廉姆斯先生的发言 [讲话](https://mediacosmos.rice.edu/app/plugin/embed.aspx?ID=vVUTzFCE006yZu3TF1sXKg&displayTitle=false&startTime=0&autoPlay=false&hideControls=false&showCaptions=false&width=420&height=236&destinationID=URka-_E5-0-e4girH4pDPQ&contentID=vq2oQtAqPkeAqm5F6uSnqA&pageIndex=1&pageSize=10) 。 像往常一样，面对如此复杂的主题，可能会错过很多东西。 另外，威廉姆斯先生在煎饼周围扔出了很多有趣的主意，因此强烈建议您观看演讲。 但是在那之前，让我们来看看 HP 认为机器将是计算的未来……。 + +## 为什么构建计算机需要不同的体系结构？ + +计算架构在 60 年来从未改变。 [Von Neumann 架构](http://en.wikipedia.org/wiki/Von_Neumann_architecture) 仅打算使用几年，但我们仍在使用它。 数据必须在内存，处理器和硬盘之间来回移动。 **如今，移动数据的过程已完全主导了计算**。 这就是在数据中心中花费大量时间并消耗大量电力的原因。 + +摩尔定律即将终结。 我们已经达到了 14 nm（约 50 个原子）的晶体管。 7 nm 被认为是物理极限。 10 纳米将在两年内准备就绪，而 7 纳米将在 2020 年之前准备就绪。 这将使计算效率提高 10 个数量级，这是人类技术有史以来最大的改进。 + +我们如何看待突破摩尔定律范式？ **围绕可用的**优化物理的各种功能。 50 年来，我们附属于计算机的东西是电子。 那不会改变。 电子是执行计算过程的理想选择。 它们很小，很轻，您施加了电压，移动很快，但是它们的质量足以使它们位于一个很小的空间中，并且相互作用非常强，因此您可以对电子进行逻辑运算。 电子将继续成为引擎的计算部分。 + +**我们将使用离子** 而不是使用电子进行存储。 原因是离子是经典的机械粒子，它们很重，将它们放在某个地方并留在那儿，您可以回到一个世纪后，将离子放在那儿的位置仍然存在。 离子确实是非易失性存储信息的一种方法。 可以将离子放在小盒子中，然后可以将盒子堆叠起来，与电子相比，可以实现高密度，低成本的存储。 -* [什么是 Symfony2？ Fabien Potencier 的](http://fabien.potencier.org/article/49/what-is-symfony2) -* [Youporn 堆栈上的超级空缺-每天 300K QPS 和 1 亿页面浏览量](http://highscalability.com/blog/2012/2/16/a-super-short-on-the-youporn-stack-300k-qps-and-100-million.html) -* [在 Reddit 上](http://www.reddit.com/r/programming/comments/rvw6q/youporn_scaling_to_200_million_views_a_day_and/) +**数据将使用光子** 移动。 其原因是光子没有质量，因此它们以光速运动。 可以在同一波导中放置许多不同颜色的光，因此可以节省大量空间和能源。 更高的通信带宽和更低的功耗。 -演讲视频将很快到来。 +正在围绕这些功能中的每一个对机器周围的硬件进行优化，以便进行计算，存储和通信。 通过适当地构建它们，存在有利的非线性相互作用。 -我没有太多内容可以讨论。 我的计划是显示可能的结果，并在以后的讲座/文章中介绍细节。 我正在处理这些。 +**通过异构多核芯片的扩散，电子将继续成为未来** 的计算引擎。 由于摩尔定律的失败，如今存在多核芯片。 我们之所以拥有多核芯片，是因为一个大而快的芯片的功耗会使其蒸发。 为了解决该问题，将芯片切成小块。 问题是多核更难编程，但是我们开始弄清楚，人们现在认为多核是一件好事。 -〜埃里克 +并非所有核心都相同，而是核心将有所不同。 代替在芯片上具有相同的 256 个内核，将针对不同类型的功能优化不同的内核。 -没有批评的意图，我只是想解释为什么为什么可能没有读者想要的那么多细节。 我知道这需要大量工作，并且期待更多细节。 谢谢。 +**挑战是 Dark Silicon** 。 如果同时点亮一个芯片上的所有内核，则**芯片将被蒸发**。 您实际上从未真正使用过芯片上的所有内核。 与 14nm 相比，在 10nm 下，您必须一次使用一半的内核。 如果内核是特定于功能的，则在不使用内核时将它们变暗是有意义的。 专用加速器是可以超级高效地运行一种类型的计算的核心，但是它只能完成一件事。 对于求解晶体结构，如果您有一个可以在一个时钟周期内完成傅立叶变换的专用内核，那将非常有帮助。 -很棒的文章，很棒的幻灯片。 期待观看视频。 -听到有关 svn / git 项目符号的更多详细信息将很有趣。 +您不需要庞大的团队来设计处理器。 有些公司出售处理器设计。 您可以只设计几个专门的加速器。 这些设计可以招标。 力量的平衡将转移给设计师，而不是制造商，他们将成为低成本的竞标者。 -Youporn 最初是使用 Perl Catalyst 框架开发的（请参阅 http://www.technewsworld.com/story/70236.html?wlc=1276880514） -Manwin 在 2010 年 4 月收购了 youporn。那时，Youporn 已经是一个 BIG 网站。 +## **忆阻器是离子盒** -根据介绍，他们决定将 Perl Catalyst 框架更改为 PHP Symphony 框架的决定并不是为了获得性能，而是为了使新收购方的非 Perl 开发人员获得陡峭的学习曲线。 +**DRAM 本质上吸收电子并将其放入盒子中** 。 随着盒子的尺寸越来越小，将电子保持在内部的难度越来越大，这意味着 DRAM 必须更频繁地刷新。 可靠地将电子存储在 DRAM 或闪存中变得越来越困难。 -我似乎认为 MySQL，ActiveMQ-> Redis 更改带来了 10％的性能提升。 即使这似乎不是很大的改进。 +**解决方案是在存储介质中使用作为带电原子的离子代替电子** 。 原子比电子的行为更好，因为它们的质量大得多。 原子是经典的机械粒子，因此即使在 10nm 的盒子中，原子也很高兴成为粒子。 将离子放入盒子中，在盒子上施加电压，离子将在盒子内移动。 关闭电压，即使在很小的盒子中，离子也将保持原状，甚至持续数百万年。 这是非常稳定的非易失性类型的内存。 + +**可以通过在盒子上施加小电压并测量电阻**来读取离子状态 **。 由于电压不够高，离子不会移动。 盒子的电阻取决于离子在里面的位置。 当离子在盒子中均匀分布时，您会得到一个低电阻，您可以将其称为 1。如果将所有离子推到盒子的一侧，则电阻将非常高，您可以将其称为 0。** + +**离子盒是忆阻器**。 与 DRAM 忆阻器相比，**因子**慢 4 倍，可以通过并行访问来缓和。 忆阻器的功率要求要低得多，因为离子不会泄漏，因此无需刷新。 **的位密度要比**高得多，因为可以将盒子堆叠在一起。 芯片**每位**便宜得多。 基于这些想法，他们多年来一直在制造芯片。 在演讲中，显示的芯片使用了 2.5 年，并使用了 50nm 技术，这意味着当前的迭代要好得多，但是他们无法发表评论。 + +想法是折叠内存/存储层次结构，并消除在系统中所有层之间移动数据的所有开销和时间。 今天的计算问题是能源效率低下。 花费了 80％的能量，并花费了大量时间来获取位，然后将它们从硬盘，内存，处理器，多层高速缓存中移出，然后再向下移出。 大多数操作系统都关心所有这些数据处理的机制。 + +## 使用光子进行通信 + +光子破坏距离。 没有什么比光速快。 + +那么为什么我们不像在电信网络中那样已经在芯片上使用光子学呢？ 互连的成本将是计算机本身成本的一千倍。 **通过机架移动的数据量大于通过北美电信网络**的数据量。 + +**惠普一直在努力降低成本**。 光线是移动数据的一种上乘方式。 它具有高带宽（单根导线中有多个波长），高能效（无能量损失），低延迟（无中继器）和空间高效（节省了引脚数）。 + +他们现在正在使用标准硅工艺在硅晶片上集成光子学。 + +此技术用于在计算机中创建通信结构。 电脑是一个装有刀片的盒子。 刀片服务器具有忆阻器存储芯片和多核处理器。 插入刀片时，刀片会自动重新配置光子网络，以便一切都能相互通信。 接下来要做的是把盒子拿起来并堆放在一起，形成一个架子。 同样，网络会自动进行自我配置。 接下来是能够组装一个数据中心的机架，然后将它们全部抬起并正确配置。 + +![](img/ef7fa9f1d9f2fec0ad587f22ccb7b621.png) + +## 软件-三分之二 + +到目前为止，所有硬件仅占项目的 1/3。 The Machine 之上必须装有操作系统。 一个操作系统可能需要数十年的开发时间。 **惠普正在开发精简版的 Linux** ，该版本非常快，因为处理掉了数据内部移动的所有逻辑都已被剔除。 他们还创建了**开源社区，以构建操作系统**的本机版本，以及所有最重要的应用程序，例如分析，可视化，艾字节级算法和百万节点管理。 + +试图缩短从研究，开发到产品生产的时间范围。 大量的工作。 这是一个非常冒险的项目。 规模庞大。 雄心勃勃。 巨大的风险。 + +## 对任何尝试进行全新工作的人来说，都是一个重大警告。 + +**经验教训**：他们遇到了无法预料的问题。 然后要做很多工作，以确保可以使用标准制造流程来构建其流程。 + +如果您尝试引入真正不同的东西，例如碳纳米管或石墨烯，会发生什么？ 他们使用所有标准材料所面临的挑战是巨大的。 引入异国情调的东西将需要数十年的时间才能真正通过实际的制造过程进行构建。 如果您打算深入研究并大胆地做，则必须**做一些与现有**尽可能接近的事情。 你离那不可能走得太远。 + +## 相关文章 -不要怪罪 Perl 具有复杂性和低性能。 :) +* [忆阻器将如何改变一切？](http://highscalability.com/blog/2010/5/5/how-will-memristors-change-everything.html) -我很高兴视频播放完了。 +* [我们比光而不是电的超高速计算机更近一步](http://www.fastcolabs.com/3039445/were-one-step-closer-to-superfast-computers-that-run-on-light-instead-of-electricity) -在演示过程中的某些时候，埃里克（Eric）曾将 2 个小错误称为 dns 服务器，网络服务器和内存缓存 Redis。 +* Google 押注 [Quantum Computers](https://plus.google.com/+QuantumAILab/posts) -我想知道的部分，视频搜索如何工作？ Redis 有可能吗？ 还是仍然使用 MySQL 文本搜索？ +* [图灵大教堂](http://www.amazon.com/dp/0375422773) -乔治·戴森 -这一切都在什么硬件上运行？ 它是自托管的吗？ \ No newline at end of file +* [IT 的新风格](http://www.hipeac.net/system/files/HiPEAC14-faraboschi-pub.pdf) \ No newline at end of file diff --git a/docs/158.md b/docs/158.md index d65c2ec..9015aa4 100644 --- a/docs/158.md +++ b/docs/158.md @@ -1,136 +1,202 @@ -# 在 30 分钟内进行 7 年的 YouTube 可扩展性课程 - -> 原文： [http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html](http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html) - -![](img/037ab09a00de464dc99a6ba677f01263.png) - -如果您开始建立约会网站，而最终建立了每天处理 40 亿次观看次数的视频共享网站（YouTube），那么您可能会在此过程中学到一些东西。 确实，YouTube 的原始工程师之一 Mike Solomon 确实学到了很多东西，他在 [PyCon](https://us.pycon.org/2012/) ： [在 YouTube 上的可扩展性上做了演讲](http://www.youtube.com/watch?v=G-lGCC4KKok) 。 - -这不是架构驱动的讨论，我们将通过介绍许多盒子相互连接的方式进行介绍。 迈克可以这样讲。 他致力于建立 YouTube 的 Servlet 基础结构，视频索引功能，视频转码系统，全文搜索，CDN 等。 但是，相反，他退后了一步，仔细研究了工作时间，并分享了一些深刻的经验教训，这些经验教训显然是来之不易的。 - -对我来说，要讲的主要内容是使用非常简单的工具完成了**。 尽管许多团队都在转向更复杂的生态系统，但 YouTube 确实做到了简单。 他们主要使用 Python 进行编程，使用 MySQL 作为其数据库，他们一直使用 Apache，甚至对于一个如此庞大的站点来说，新功能都始于非常简单的 Python 程序。 - -这并不意味着 YouTube 不会做酷的事情，而是做的，但是使所有事情协同工作的更多的是哲学或做事方式，而不是技术专长。 是什么使 YouTube 成为世界上最大的网站之一？ 继续阅读并查看...** - -## 统计信息 - -* 每天 40 亿次观看 -* 每分钟上传 60 个小时的视频 -* 350+百万台设备启用了 YouTube -* 2010 年收入翻了一番 -* 视频的数量增加了 9 个数量级，而开发人员的数量仅增加了 2 个数量级。 -* 一百万行 Python 代码 - -## 堆栈 - -* **Python-** YouTube 的大部分代码行仍在 Python 中。 每次观看 YouTube 视频时，您都在执行一堆 Python 代码。 -* **Apache** -当您认为需要摆脱它时，则不需要。 Apache 是​​YouTube 上真正的摇滚明星技术，因为它们保持了简单。 每个请求都通过 Apache。 -* **Linux** -Linux 的好处是总有一种方法可以进入并查看您的系统运行情况。 无论您的应用程序表现多么糟糕，您都可以使用 strace 和 tcpdump 之类的 Linux 工具对其进行查看。 -* **MySQL** -使用很多。 观看视频时，您正在从 MySQL 获取数据。 有时它使用关系数据库或 Blob 存储。 这是关于调整和选择组织数据的方式。 -* [**Vitess**](http://code.google.com/p/vitess/) -YouTube 发布的新项目，用 Go 编写，它是 MySQL 的前端。 它动态地进行了很多优化，它重写查询并充当代理。 目前，它可以处理每个 YouTube 数据库请求。 它基于 RPC。 -* **Zookeeper** -分布式锁定服务器。 用于配置。 真正有趣的技术。 难以正确使用，因此请阅读手册 -* **Wiseguy** -一个 CGI Servlet 容器。 -* **Spitfire** -一个模板系统。 它有一个抽象的语法树，让他们进行转换以使处理更快。 -* **序列化格式** -无论使用哪种格式，它们都非常昂贵。 测量。 不要用泡菜 不是一个好选择。 找到的协议缓冲区很慢。 他们编写了自己的 BSON 实现，比您可以下载的实现快 10-15 倍。 - -## 一般课程 - -* YouTube 的 **Tao** ：选择最简单的解决方案，并附带最实际的保证。 您需要所有这些东西的原因是您需要灵活性来解决问题。 在您指定的那一刻，您就会把自己粉刷成一个角落。 您不会做出这些保证。 尝试做出所有这些保证时，您的问题会自动变得更加复杂。 您不会离开自己。 -* **整个过程就是**的可伸缩性。 可扩展的系统是您所无法企及的。 您没有意识到。 这不是流行语。 这是解决精神问题的一般问题。 -* **大型系统设计的标志**：每个系统都是根据其特定要求量身定制的。 一切都取决于构建的细节。 -* **YouTube 不是异步的**，所有内容都处于阻塞状态。 -* **相信哲学胜于教义**。 简单点。 那是什么意思？ 当您看到它时，您就会知道。 如果执行代码检查会更改数千行代码和许多文件，则可能是一种更简单的方法。 您的第一个演示应该很简单，然后进行迭代。 -* **解决一个问题：一个字-简单**。 寻找最简单的方法来解决问题空间。 有很多复杂的问题，但是第一个解决方案并不需要复杂。 随着时间的流逝，复杂性自然会到来。 -* **许多 YouTube 系统都是从一个 Python 文件**开始的，并在许多年后变成了大型生态系统。 他们所有的原型都是用 Python 编写的，并且存活了惊人的时间。 -* **在设计审查**中： - * 什么是第一个解决方案？ - * 您打算如何迭代？ - * 我们对该数据将如何使用了解多少？ -* **事情随时间而变化**。 YouTube 如何起步与以后发生的事情无关。 YouTube 最初是一个约会网站。 如果他们为此设计，他们将有不同的对话。 保持灵活性。 -* **YouTube CDN** 。 最初是外包出去的。 非常昂贵，所以他们自己做。 如果您有不错的硬件伙计，则可以构建一个不错的视频 CDN。 您建立了一个非常大的机架，将机器插入其中，然后进行 lighttpd 处理，然后覆盖 404 处理程序以查找未找到的视频。 这花了两个星期的时间，而且第一天的服务量为 60 吉比特。 使用非常简单的工具，您可以做很多事情。 -* **您必须测量**。 Vitess 换出了一个协议来进行 HTTP 实现。 即使在 C 语言中，它的速度也很慢。 因此，他们剥离了 HTTP 并使用 python 进行了直接套接字调用，这在全局 CPU 上便宜了 8％。 HTTP 的封装确实非常昂贵。 - -## 可扩展性技术 - -* 这些不是新主意，但令人惊讶的是，一些核心主意如何在许多不同的方面得到应用。 -* **分而治之-可伸缩性技术** - * 这是可伸缩性技术。 一切都是关于划分工作。 确定如何执行它。 从 Web 层开始，适用于许多事物，您拥有许多 Web 服务器，这些 Web 服务器或多或少完全相同且独立，并且可以水平扩展它们。 那是分而治之。 - * 这是数据库分片的关键。 您如何划分内容，并在细分的部分之间进行交流。 这些是您想尽早解决的事情，因为它们会影响您的成长方式。 - * 简单而松散的连接确实很有价值。 - * Python 的动态特性在这里是一个胜利。 不管您的 API 有多糟糕，您都可以存根或修改或修饰自己的方式来解决许多问题。 -* **近似正确性-稍作弊** - * 另一个喜欢的技术。 系统的状态就是它所报告的状态。 如果用户不能告诉系统的一部分是歪斜和不一致的，那不是。 - * 一个真实的例子。 如果您写评论，但有人同时加载该页面，则他们可能会在 300-400 毫秒内没有收到该评论，正在阅读的用户将不在乎。 评论的作者会在意，因此您确保撰写评论的用户会看到它。 所以你有点作弊。 您的系统不必具有全局一致的交易记录。 那将是非常昂贵和过度的。 并非每条评论都是金融交易。 所以知道什么时候可以作弊。 -* **专家旋钮切换** - * 问，您对一致性模型了解多少？ 对于评论的最终一致性是否足够好？ 租电影是不同的。 租房时有钱，所以我们会尽力做到永不丢失。 根据数据需要不同的一致性模型。 -* **抖动-向系统中添加熵** - * 始终是他们小组中的热门词。 如果您的系统没有抖动，那么您会得到 [雷电群](http://highscalability.com/blog/2008/3/14/problem-mobbing-the-least-used-resource-error.html) 。 分布式应用程序实际上是天气系统。 调试它们与确定天气一样具有确定性。 抖动引入了更多的随机性，因为令人惊讶的是，事情趋于堆积。 - * 例如，缓存过期。 对于流行视频，他们会尽其所能地缓存内容。 他们可能会缓存 24 小时的最受欢迎的视频。 如果所有内容一次到期，则每台计算机将同时计算到期时间。 这产生了一个雷电群。 - * 抖动表示您在 18-30 小时之间随机失效。 这样可以防止事情堆积。 他们在各处使用它。 当操作排队并试图破坏自身时，系统倾向于自我同步。 令人着迷的观看。 一台计算机上的磁盘系统运行缓慢，每个人都在等待一个请求，因此所有其他计算机上的所有其他请求突然之间完全同步。 当您有很多机器并且有很多事件时，就会发生这种情况。 每个人实际上都从系统中删除了熵，因此您必须重新添加一些熵。 -* **作弊-知道如何伪造数据** - * 很棒的技术。 最快的函数调用是不会发生的。 当您拥有一个单调递增的计数器（例如电影观看次数或个人资料观看次数）时，您可以在每次更新时进行一次交易。 或者，您可以不时进行一次交易，并随机更新一次，只要交易从奇数变为偶数，人们可能会认为这是真实的。 知道如何伪造数据。 -* **可扩展组件-自己创造运气** - * **您可以查看一个 API 并获得良好的感觉**。 输入是否定义明确？ 你知道你要出去吗？ 其中很多最终都与数据有关。 严格说明每个函数将输出什么数据以及它如何流动，实际上可以帮助您在没有文档的情况下理解应用程序。 您可以分辨出在调用函数之前和之后发生的情况。 - * **在 Python 中，事情倾向于向 RPC** 发展。 代码的结构基于程序员的纪律。 因此要建立良好的约定，当所有其他方法都失败时，就会出现 RPC 隔离墙，以便您了解其中的内容和结果。 - * **您的组件将不完美**。 知道，一个组件可能会持续一个月或六个月。 通过画出这些线条，您正在自己赚一些钱。 当事情发展到南方时，您可以将其换成其他东西。 有时用 python 和 C 重写某些内容，有时则意味着完全摆脱它。 直到您能够观察到，您才知道。 - * **团队中有这么多人，没人知道整个系统**，因此您需要定义组件。 这是视频转码，与视频搜索不同。 您需要定义明确的子组件。 好的软件设计。 这些事情最终导致彼此交谈，因此拥有一个良好的数据规范将很有帮助。 他最大的罪过是 Servlet 层和模板层之间的通信，使之成为字典。 好主意。 应该添加一个 WatchPage 并说一个观看页面有一个视频，一些评论和一些相关视频。 这引起了很多问题，因为字典可以具有数百个属性。 他们并不总是做出正确的选择。 -* **效率-以可扩展性为代价** - * **效率是以可伸缩性** 为代价的。 最有效的方法是用 C 编写并将其塞入一个进程，但这是不可扩展的。 - * **关注宏级别** **，您的组件以及它们如何分解**。 将此做为 RPC 还是以内联方式有意义？ 将其分成一个子包，就可能有一天可能会有所不同。 - * **关注算法** 。 在 Python 中，实现良好算法的工作量很低。 例如，有 bisect 模块，您可以在其中获取列表，做一些有意义的事情，并将其序列化到磁盘上，然后再次读回。 对 C 有罚款，但这很容易。 - * **测量** 。 在 Python 中，测量就像阅读茶叶一样。 Python 中有很多与直觉相反的东西，例如抓斗成本。 他们的大多数应用程序都花时间进行序列化。 对序列化进行概要分析非常取决于您要插入的内容。对 int 进行序列化与对大 blob 进行序列化有很大不同。 -* **Python 的效率-知道不该做什么** - * **有关了解不要做什么的更多信息** 。 您制作事物的动态程度与运行 Python 应用程序的昂贵程度相关。 - * **Dummer 代码更易于 grep 且易于维护** 。 代码越神奇，就越难弄清楚其工作原理。 - * **他们并没有做很多 OO** 。 他们使用很多命名空间。 使用类来组织数据，但很少用于 OO。 - * **您的代码树是什么样的？** 他希望用以下词语来形容它：简单，实用，优雅，正交，可组合。 这是一个理想，现实有点不同。 +# AWS 的惊人规模及其对云的未来意味着什么 + +> 原文： [http://highscalability.com/blog/2015/1/12/the-stunning-scale-of-aws-and-what-it-means-for-the-future-o.html](http://highscalability.com/blog/2015/1/12/the-stunning-scale-of-aws-and-what-it-means-for-the-future-o.html) + +![](img/9507f1ccc471853c743c9069de138100.png) + +[James Hamilton](http://www.mvdirona.com/jrh/work/) ，亚马逊副总裁兼杰出工程师，以及[博主](http://perspectives.mvdirona.com/)长期从事有趣的话题，在 [AWS 上进行了热情洋溢的演讲：](https://reinvent.awsevents.com/) [AWS 创新规模](https://www.youtube.com/watch?v=JIQETrFC_SQ) 上的 Invent 2014 。 他显然为他们正在做的工作感到自豪，这表明了。 + +James 分享了有关 AWS 的一些惊人数据： + +* 1 百万活跃客户 +* 所有其他 14 个云提供商的总和是 AWS 总容量的 1/5（2013 年 Gartner 估计） +* 2014 年发布了 449 种新服务和主要功能 +* 作为一家年收入达 7 亿美元的企业（2004 年），AWS 每天都会增加足够的新服务器容量来支持亚马逊的全球所有基础架构。 +* S3 的数据传输同比增长 132％ +* 数据中心的网络容量为 102Tbps。 + +演讲的主题是云是一个不同的世界。 这是一个特殊的环境，允许 AWS 大规模地做伟大的事情，而您做不到的事情，这就是为什么从内部 x86 服务器到公共云的过渡正以惊人的速度发生的原因。 公有云具有如此众多的规模驱动优势，这是无法停止的过渡。 云将以您无法开始与有限资源，通才装备，膨胀的软件堆栈，缓慢的供应链和过时的创新范式匹配的速度，变得越来越可靠，功能更多，价格更低。 + +至少是 PR 消息。 但是您可以说的关于亚马逊的一件事就是他们正在生活。 他们使它成为现实。 因此，一个健康的怀疑是健康的，但推断命运的界限也是明智的。 + +AWS 拥​​有命运决定权的多变之一是资源。 在拥有一百万个客户的情况下，他们有足够的规模来保持扩展和改善的动力。 利润没有被提取出来，金钱被重新投资了。 这也许是规模最重要的优势。 + +但是没有聪明人的钱简直就是浪费。 亚马逊希望您知道他们有聪明人。 我们听说过 Google 和 Facebook 如何建立自己的设备，亚马逊也是如此。 他们构建了自己的网络设备，网络软件，机架，并且与 Intel 合作获得了比市场上更快的处理器版本的处理器。 关键是他们对环境一无所知，并且可以控制一切，因此他们可以制造出更简单的设备来实现自己想要的功能，从而最终变得更便宜，更可靠。 + +完全控制允许将质量指标内置到所有内容中。 指标推动系统各个部分的质量不断提高，这就是为什么在创新步伐加快的情况下，AWS 变得更加可靠的原因。 大量可操作的数据转化为知识是规模的另一个巨大优势。 + +AWS 不能做的另一件事是可用区架构本身。 每个可用区都是其自己的数据中心，一个区域内的可用区非常靠近。 这减少了消息传递延迟，这意味着可以在 AZ 之间同步复制状态，与冗余数据中心相距甚远的典型方法相比，这可以大大提高可用性。 + +这是一次充满信息的演讲，而且……实在太夸张了。 演讲的真正元主题是亚马逊如何有意识地利用规模来获得竞争优势。 对于亚马逊来说，扩展规模不仅是要花的钱，如果您知道如何扩展规模，它就是一种资源。 + +这是詹姆斯·汉密尔顿令人难以置信的谈话的掩饰... + +## 对话中的所有内容都具有规模 + +* 当 AWS 成为年收入 7B 的企业（2004 年）时，每天都会增加足够的新服务器容量来支持 Amazon 的所有全球基础架构。 + +* 一年 365 天，组件制造商必须与服务器和存储制造商联系，服务器和存储制造商必须生产齿轮并将其推入物流渠道，必须将其从物流渠道转移到正确的数据中心 ，它必须到达装货平台，人们必须在那里将机架轮到 DC 中的正确位置，必须有电源，散热，网络连接，必须加载应用堆栈，必须进行测试 ，它必须发布给客户。 + +* S3 使用率：数据传输量同比增长 132％； EC2 使用量：使用量同比增长 99％； AWS 的整体业务：超过一百万的活跃客户。 + +* 所有其他 14 个云提供商的总和是 AWS 总容量的 1/5（Gartner 在 2013 年估计） + +* 拥有超过一百万的客户，这意味着您处于一个丰富的生态系统中。 您可以选择软件供应商，如果您以前遇到过别人可能遇到的问题，则可以更快地完成工作。 + +* 如此高的增长速度意味着亚马逊拥有资源，可以通过增加其提供的服务的广度和深度来继续进行再投资和创新。 + +* 通常，经济效益要好得多时，例如从大型机到 UNIX 服务器，然后从 UNIX 服务器到 x86 服务器，就会发生大的转变。 这些过渡通常需要 10 年以上的时间。 x86 本地迁移到云的不同之处在于它发生的速度。 云迁移的速度是具有很高的经济价值的功能，而且采用的摩擦也很低。 您不需要软件，不需要硬件，就可以做到。 + +## 联网中存在较大的成本问题 + +* 联网是整个行业的红色预警情况。 这是一场完美的风暴。 + +* **问题 1** ：相对于所有其他设备的成本，网络成本正在不断上升。 这是反摩尔定律。 所有其他设备的成本都在下降，随着时间的流逝，网络变得越来越昂贵。 每月相对费用：服务器：57％； 网络设备：8％； 功率分配和冷却：18％； 功率：13％; 其他：4％。 + +* **问题 2** ：在网络变得越来越昂贵的同时，网络与计算的比率也在上升。 部分原因是摩尔定律在服务器上仍在起作用，并且计算密度也在不断提高。 部分原因是，随着计算成本的下降，执行的高级分析数量将增加，并且分析需要占用大量网络资源。 解决使用大量服务器的大问题需要大量的网络。 网络流量已向东西方向移动，而不是传统的 [南北方向](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) 。 + +* 5 年前，Amazon 的解决方案是数据驱动的并且是激进的：**他们根据自己的网络设计**构建。 建立了特殊路由器。 雇用了一个团队来构建协议栈，一直到顶部。 他们自己将所有这些都部署在了网络中。 全球所有服务都在此设备上运行。 + + * **这种策略原来便宜得多**。 仅网络设备的支持合同就花费了数千万美元。 + + * **可用性提高了**。 改进的来源是简单性。 AWS 试图解决的问题比企业齿轮要解决的问题更简单。 企业设备必须遵守许多未使用的复杂规范，只会使系统更加脆弱。 仅实现所需的功能就意味着可以简化系统，从而提高可用性。 任何取胜的方法都是取胜的好方法。 + + * **指标**的聚宝盆。 他们衡量一切。 规则是，如果客户在使用他们的系统时体验不好，他们的指标必须显示出来。 这意味着指标一直在提高，因为客户问题推动了指标的提高。 一旦有了可以准确反映客户体验的指标，就可以设定目标，以使系统变得更好。 每周都会进行改进，以使事情变得更好。 如果代码起步不好，那么随着时间的推移它就会变得更好。 + + * **可测试性**。 他们的装备更好，因为他们进行了更好的测试。 企业级设备很难进行大规模测试。 他们创建了一个耗资 4000 万美元的测试平台，其中包含 8000 台服务器（3 兆瓦）。 但是由于这是云，他们有效地租用了几个月的服务器，因此价格相对便宜。 + +## 从最上层到网络接口卡的逐层网络解释 + +### AWS 全球网络骨干 + +* 全球 11 个 AWS 区域。 根据与客户的接近程度或所需的管辖范围选择要使用的那些。 + +* 专用光纤链路将大多数主要区域互连。 这样可以避免所有容量规划问题（Amazon 可以进行更好的容量规划），对等问题以及在公共链接上发生的缓冲问题。 因此，运行自己的网络速度更快，更可靠，更便宜且延迟更短。 + +### 示例 AWS 区域（美国东部（（弗吉尼亚北部）） + +* 所有区域至少都有两个可用区。 美国东部有五个可用区。 + +* 冗余路径通向运输中心。 + +* 每个区域都有冗余的运输中心。 转运中心将专用链接连接到其他 AWS 区域，将专用链接连接到 AWS Direct Connect 客户，并通过对等和付费转接连接到 Internet。 + +* 如果一个可用区发生故障，所有其他可用区继续工作。 + +* 可用区之间的城域 DWDM 链接 + +* 区域中有 82,864 根纤维束 + +* AZ 间隔小于 2ms，通常间隔小于 1ms。 从等待时间的角度来看，它们在几公里之内非常接近。 相隔足够远以确保安全，相隔足够远以获得良好的延迟。 + +* 可用区之间的峰值流量为 25Tbps + +* AWS 提供可用区，因为： + + * 使用单个加固的数据中心，您将获得的最佳可靠性约为 [99.9％](http://en.wikipedia.org/wiki/High_availability) 。 高可靠性要求在两个数据中心中运行。 传统上，数据中心的多样性来自相距很远的两个数据中心，因为保持数据中心相互靠近的成本效益不高。 这意味着更长的等待时间。 LA 到 NEW 是往返 74ms。 提交给 SSD 的时间为 1 到 2 毫秒。 您不能等待 70 毫秒以上的时间才能提交交易。 这意味着应用程序在本地提交，然后复制到第二个数据中心。 在故障情况下，这种设计会在故障转移期间丢失数据。 尽管真正的故障很少发生，例如建筑物烧毁，但瞬态故障更常​​见，例如负载平衡器问题。 那么，您是否会在 3 分钟内对您的连接进行故障转移？ 不可以，因为数据将丢失，并且需要很长时间才能从其他来源恢复该数据。 因此，您将失去常见事件的可用性。 + + * 可用区间隔为毫秒，因此您可以同时提交两个可用区。 这意味着，如果您进行故障转移，则由于数据复制是同步的，客户将无法得知。 它是不可见的。 很难为该模型编写代码，因此您不会为所有事情做到这一点。 对于某些应用程序，对多可用区故障的担心也可能会阻止您使用多个可用区，但是对于其余应用程序，这是一个非常强大的模型。 成本更高，但是它为 AWS 提供了某些优势。 + +### 示例 AWS 可用区 + +* 可用区始终是完全独立的建筑物中的数据中心。 + +* 亚马逊拥有 28 多个数据中心。 加号表示 AZ 中有更多数据中心，作为扩展 AZ 能力的一种方式。 在可用区中添加了更多数据中心以扩展可用区的容量。 否则，即使您不想这样做，也将不得不将应用程序划分为多个可用区。 + +* 一些可用区具有相当大的数据中心大小。 + +* AZ 中的 DC 间隔小于 1/4 毫秒。 + +### 示例数据中心 + +* AWS 数据中心故意不是巨大的。 单个数据中心的功率为 25-30 兆瓦，具有 50,000-80,000 台服务器 + +* 数据中心规模的回报减少。 随着您构建的规模越来越大，数据中心扩展的优势下降了。 早期的优势是巨大的。 后来的优势很小。 从 2000 机架增加到 2500 机架要好一些。 一个很小的数据中心太昂贵了。 真正的大型数据中心仅比机架中型数据中心贵一点。 + +* 数据中心越大，风险越大。 爆炸半径如果出现问题并破坏了数据中心，则损失太大。 + +* 到数据中心的网络容量为 102Tbps。 + +### 机架示例，服务器& NIC + +* 唯一重要的延迟是连接两端的软件延迟。 发送消息时，两个服务器之间的延迟： + + * 您的应用->来宾操作系统->虚拟机管理程序-> NIC：延迟为毫秒 + + * 通过网卡：延迟为微秒 + + * 光纤上的：等待时间为纳秒 + +* SR-IOV（ [单根 I / O 虚拟化](http://www.redbooks.ibm.com/abstracts/redp5065.html?Open) ）允许 NIC 在硬件网卡中提供虚拟化。 每个来宾都有自己的网卡。 好处是>平均延迟减少 2 倍，>延迟抖动增加 10 倍。 这意味着离群值下降到原来的 1/10。 SR-IOV 现在正在新的实例类型上部署，并且最终将在任何地方使用。 困难的部分不是添加 SR-IOV，而是添加了隔离，计量，DDoS 保护以及容量限制，这使得 SR-IOV 在云环境中很有用。 + +## AWS Custom Server &存储设计 + +* 负面情况的成本不高，因此可以取消昂贵的不需要的保护。 服务器是针对其功能而设计的，而不是针对一般用户。 亚马逊确切地知道服务器将在什么环境中运行，他们会确切地知道何时出现问题，因此可以在设计时减少工程空间。 对于他们来说，服务器故障的代价并不是很大。 它们已经在现场，并且非常擅长更换硬盘等。因此，企业设备中的许多注意事项都是不必要的。 + +* **可以用力推动处理器**。 他们知道散热要求，影响机械设计，他们只是设计好的服务器，因此可以从服务器中获得更多性能。 尽管与英特尔亚马逊的合作关系使处理器的运行速度比在公开市场上购买的处理器要快。 + +* 例如，他们自己的储物架设计。 它重达一吨，宽 19 英寸，可容纳 864 个磁盘驱动器。 对于某些工作负载而言，这是一款出色的改变游戏规则的设计，可帮助他们在某些地区获得更高的价格。 + +## 电源基础架构 + +* 亚马逊已经设计并建造了自己的变电站。 它只节省一点钱，但是他们可以更快地构建它们。 公用事业公司不习惯应对 AWS 的增长速度，因此他们不得不自己建立。 + +* 3 个 100％碳中和地区：美国西部（俄勒冈州），AWS GovCloud（美国），欧盟（法兰克福） + +## 创新的快节奏 + +* 2014 年发布了 449 个新服务和主要功能。2008 年为 24 个，2009 年为 48 个，2010 年为 61 个，2011 年为 82 个，2012 年为 159 个，2013 年为 280 个。 + +* 随着创新步伐的加快，AWS 变得越来越可靠。 他们的目标是向客户提供与实现这种创新速度和高质量相同的工具。 ## 相关文章 -* [使用 Python 调整 YouTube 大小](http://www.slideshare.net/didip/super-sizing-youtube-with-python) -* [扩展 Web 的 MySQL 数据库](http://www.percona.com/live/mysql-conference-2012/sessions/scaling-mysql-databases-web) -* [YouTube 架构](http://highscalability.com/youtube-architecture) -* [关于 HackerNews](http://news.ycombinator.com/item?id=3757456) +* 在[黑客新闻](https://news.ycombinator.com/item?id=8875549)上/在 [reddit](http://www.reddit.com/r/programming/comments/2s6nf6/the_stunning_scale_of_aws_and_what_it_means_for/) 上 + +* James Hamilton 的 [博客](http://perspectives.mvdirona.com/) 以及其他 [讨论和幻灯片](http://mvdirona.com/jrh/work/) + +* [深入了解 AWS 的大规模规模](http://www.enterprisetech.com/2014/11/14/rare-peek-massive-scale-aws/) 和 [，有关黑客新闻](https://news.ycombinator.com/item?id=8643248) / [on reddit](http://www.reddit.com/r/programming/comments/2n5p8c/a_rare_peek_into_the_massive_scale_of_aws/) + +* [十亿个数据包生命中的一天](https://www.youtube.com/watch?v=Zd5hsL-JNY4) -不错。 可以使用一些校对方法，因为我不得不在某些语言被弄乱的地方放慢脚步，例如“那些东西你想早点弄清楚，因为它们会影响你的成长方式。” 否则，有趣的阅读使我想给 python 多一点关注。 +* [亚马逊如何以及为什么进入云计算业务？](http://www.quora.com/How-and-why-did-Amazon-get-into-the-cloud-computing-business) -嗯，但公平地说，YouTube 使用 lighttpd 吗？ 通过萤火虫：http://i.imgur.com/ClSH4.png +轻微错字。 “到数据中心的 10Tbps 网络容量。” 它应显示为“到数据中心的 102Tbps 网络容量”。 参考：https：//www.youtube.com/watch？v = JIQETrFC_SQ（26:40） -“ Apache 是​​YouTube 上真正的摇滚明星技术，因为它们使它保持简单。每个请求都通过 Apache 进行。” +更正，谢谢乔尔 -“您建立了一个非常大的机架，将机器插入其中，然后进行 lighttpd” +还有“每周 365 天零件制造商”-我认为应该是“一年 365 天” ...？ -如果 Apache 很棒，为什么他们选择 lighttpd 代替呢？ +已更正，谢谢 Krys。 我读了十遍，每次都错过了。 -这是否还意味着“每个请求都通过 Apache”的语句不正确？ +只是澄清一下，Gartner 的确切报价是：“ AWS 是压倒性的市场领导者，使用的计算能力是其他 14 家提供商的总和的五倍多”，并且在 2013 年。情况可能已经发生变化。 自 2013 年以来，随着 Azure 和 App Engine 的增长， -好文章。 还有一些 UX 良好做法。 +来源： [http://www.theregister.co.uk/2013/08/19/amazon_gartner_magic_quadrant/](http://www.theregister.co.uk/2013/08/19/amazon_gartner_magic_quadrant/) -@ Michal，@ Andy：这些语句是在 CDN 的上下文中的，因此您可以假定它们意味着 CDN 将 lighttpd 用于静态内容，而将 Apache 用于其余内容。 +“ spunk”是在池塘的这一侧具有完全不同含义的单词之一。 也许要避免:) -前 YouTuber 在这里... +关于“快速创新步伐”的注释很有趣，因为尽管 AWS 每周发布新功能（有时还发布服务），但我们发现所发布的内容缺乏质量。 -Apache 是​​他们处理动态 Web 请求的方式。 主页，观看页面，用户页面等。在早期，视频流媒体，视频上传者和图像上传者在 Lighthttpd 上运行，因为它能够更好地处理非交互式数据流。 +我们不断有大量的公开支持案例，其中发现了我们使用的服务中的错误。 让 AWS 确认问题的存在通常很痛苦，然后要花几周甚至几个月才能解决问题。 有时这些问题似乎很关键，有时很烦人。 -当我两年多前离开时，他们正处于将大多数视频流切换到基于 Google 的基础架构的过程中，因为 Google 基础架构具有对等协议和更高的带宽成本。 在此过程中，他们似乎决定保留旧的视频流，并将其用于静态内容服务（Lighthttpd 做得很好）。 +如果我们不订阅他们的支持产品，我不确定如何获得答案。 -顺便提及，随机更新事物最近已获得专利。 +很多时候，即使我不得不承认该部分是值得商—的，功能似乎也没有经过深思熟虑，这可能是过早发布，经常发布的情况。 -@michal @andy，听起来好像 apache 是​​他们的 Web 服务器，而 lighttpd 驱动了 CDN，因此在外部您会收到 lighttpd 标头，但 apache 确实在做这项工作。 +最重要的是，我宁愿看到不太快速的创新，而将重点放在提供稳定的基础架构服务上。 稳定地说，我并不是在指 EC2 的普遍可用性（我同意这要好得多），而是要提供更多的质量保证和更快的错误修复时间。 -作为对 YouTube 的致敬，您可以将其制作成 30 分钟的视频吗？ 大声笑 +精彩演讲的精彩文章。 感谢您编写它，它给了我时间慢慢进行所有操作，总的来说，这真是令人印象深刻:) -您可以同时使用 apache 和 lighttpd 来实现目标。 如果这篇文章更详细地解释每一个 YouTube 服务的内容，那将是很好的。 看起来.ligspd 至少提供了.css 文件，这是其静态内容。 +嘿，您可能希望对本文进行快速的复制编辑，因为其中有很多语言/语法故障，使您分心。 除此之外，还不错的文章。 在公开发布它并从 reddit 之类的站点进行链接之前，只需确保您已经通过了一个不错的复制编辑器。 -“ YouTube 不是异步的，一切都在阻塞。” 为什么？ 我以为大家都同意，最好的办法就是去医院。 +你能举个乔纳森的例子吗？ 这比一般的批评更有帮助。 文本特意简短且断断续续，以供快速浏览，这是一种样式选择，它不是典型的文章格式，因此为简洁起见，经常会忽略语法。 在我的网站上只有我一个人，所以我成为了自己的副本编辑器，所以有时我会犯错。 -也许它可以防止出现错误： -“所有形式的异步 I / O 都会打开应用程序，直至出现潜在的资源冲突和相关的故障。需要仔细的编程（通常使用互斥，信号量等）来防止这种情况。” +如今，您自己的专用服务器 8GB RAM 2TB 磁盘的价格每月不到 30 美元，而类似的 Amazon 机器则要贵 6 倍。 除了超成功的创业公司的微不足道的优势（可能需要在一小时内购买 100 台机器）外，没有任何优势。 -资料来源：http://en.wikipedia.org/wiki/Asynchronous_I/O +这很令人着迷，但我也对许多普通用户的成本效益表示怀疑。 我有客户在亚马逊上花费数万美元，并在亚马逊之上构建服务，这些服务可以复制到机架中拥有的设备成本的十分之一。 这些是有利可图的服务，具有可观但可预测的流量，并且并没有疯狂增长。 甚至那个 Facebook 游戏公司都说他们在亚马逊上发布，但是一旦游戏达到可预测的增长曲线，他们就会转向拥有的便宜基础设施。 现在，您可以在低功耗但完全适合典型 Web 工作负载的商品消费硬件上使用开源资源构建类似 AWS 和 Heroku 的私有功能……甚至还可以获取每个节点都被视为一次性使用的 HA 功能。 如果正确地构建自己的东西，则可以通过这些公共云服务节省大量资金。 -谈到简单而可靠的工具：Youtube 什么时候切换到 PostgreSQL？ +> >如果正确构建架构，则可以通过这些公共云服务节省大量资金。 -感谢您的出色总结！ +是的，不是，如果您像迅猛发展一样，并且/或者计算需求出现非常不可预测的高峰和下降，那么除非您想拥有数十台或数百台服务器，否则您可能无法以更低的价格或足够快的速度进行调整 ，未充分利用大量时间，因此您有足够的能力来满足这些需求。 -哇，什么是“夏季代号”？ \ No newline at end of file +另一方面，如果您的工作负载处于稳定状态，则只要没有问题，就可以节省一些钱。 只要确保您正在比较苹果之间。 不要将您拥有的 10 个服务器放在一个区域内的数据中心中，与在全球范围内分布在具有独立电源，冗余连接路径的多可用性区域中的 10 台服务器相同，如果架构正确， 可以在几分钟内将容量翻倍，翻倍或翻倍。 \ No newline at end of file diff --git a/docs/159.md b/docs/159.md index 619733e..ea75d5a 100644 --- a/docs/159.md +++ b/docs/159.md @@ -1,177 +1,356 @@ -# LinkedIn：使用 Databus 创建低延迟更改数据捕获系统 +# Vinted 体系结构：每天部署数百次，以保持繁忙的门户稳定 + +> 原文： [http://highscalability.com/blog/2015/2/9/vinted-architecture-keeping-a-busy-portal-stable-by-deployin.html](http://highscalability.com/blog/2015/2/9/vinted-architecture-keeping-a-busy-portal-stable-by-deployin.html) + +![](img/94c1673242b5990d73da86cff661af23.png) + +*这是 [Vinted](https://www.vinted.com/) 的 [NerijusBendžiūnas](https://www.linkedin.com/profile/view?id=48589106)和 [Tomas Varaneckas](https://twitter.com/spajus) 的来宾帖子。* + +[Vinted](https://www.vinted.com/) 是一个对等市场，用于出售，购买和交换衣服。 它允许成员直接通信，并具有社交网络服务的功能。 + +它始于 2008 年，最初是一个立陶宛女孩的小社区，后来发展成为一个全球性项目，为 8 个不同国家/地区的 700 万用户提供服务，并且这一需求正在不断增长，每天处理超过 2 亿个请求。 + +## 统计资料 + +* 700 万用户，并且还在不断增长 +* 每月 250 万活跃用户 +* 每天 2 亿个请求（浏览量+ API 调用） +* 9.3 亿张照片 +* 80 TB 原始空间用于图像存储 +* 60 TB HDFS 原始空间用于分析数据 +* 70％的流量来自移动应用（API 请求） +* 每位成员每周花费 3 个小时以上的时间 +* 2500 万个上市项目 +* 超过 220 台服务器： + * 47 用于内部工具（vpn，厨师，监视，开发，制图，构建，备份等） + * Hadoop 生态系统 38 + * 34 用于图像处理和存储 + * 独角兽和微服务 30 + * 28 个用于 MySQL 数据库，包括副本 + * 19 用于狮身人面像搜索 + * 10 个用于背景工作 + * 10 用于使用 Nginx 进行负载平衡 + * 卡夫卡 6 + * Redis 4 + * 4 用于电子邮件传递 + +## 技术栈 + +### 第三方服务 + +* [GitHub](https://github.com/) ，用于代码，问题和讨论 +* [NewRelic](http://newrelic.com/) 用于监视应用程序响应时间 +* [CloudFlare](https://www.cloudflare.com/) 用于 DDoS 保护和 DNS +* [Amazon Web Services](http://aws.amazon.com/) （SES，Glacier），用于通知和长期备份 +* [闲暇](https://slack.com/)用于工作对话和“聊天操作” +* [Trello](https://trello.com/) 完成任务 +* [Pingdom](http://pingdom.com/) 用于正常运行时间监控 + +### 核心应用和服务 + +* [Ruby](https://www.ruby-lang.org/) 用于服务，脚本和主应用 +* [主应用程序和内部应用程序的 Rails](http://rubyonrails.org/) +* [独角兽](http://unicorn.bogomips.org/)服务于主应用 +* [Percona MySQL 服务器](http://www.percona.com/software/percona-server/ps-5.6)作为主数据库 +* [Sphinx 搜索](http://sphinxsearch.com/)用于全文搜索并减少 MySQL 的负载（测试 [ElasticSearch](http://www.elasticsearch.org/) ） +* [Capistrano](http://capistranorb.com/) 用于部署 +* [Jenkins](http://jenkins-ci.org/) 用于运行测试，部署和其他各种任务 +* [Memcached](http://memcached.org/) 用于缓存 +* [请求](http://resquework.org/)进行后台作业 +* [Redis](http://redis.io/) 用于 Resque 和 Feed +* [RabbitMQ](http://www.rabbitmq.com/) 用于将消息传递到服务 +* [HAproxy](http://www.haproxy.org/) 提供高可用性和负载平衡 +* [GlusterFS](http://www.gluster.org/) 用于分布式存储 +* [Nginx](http://nginx.org/) 投放 Web 请求 +* [Apache Zookeeper](http://zookeeper.apache.org/) 用于分布式锁定 +* [Flashcache](https://github.com/facebook/flashcache/) 可提高 I / O 吞吐量 + +### 数据仓库堆栈 + +* [Clojure](http://clojure.org/) 用于数据提取服务 +* [Apache Kafka](http://kafka.apache.org/) ，用于存储飞行中的数据 +* [Camus](https://github.com/linkedin/camus) 用于将数据从 Kafka 卸载到 HDFS +* [Apache Hive](https://hive.apache.org/) 作为 SQL-on-Hadoop 解决方案 +* [Cloudera CDH](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh.html) Hadoop 发行版 +* [Cloudera Impala](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html) 作为低延迟 SQL-on-Hadoop 解决方案 +* [Apache Spark](https://spark.apache.org/) 处于实验阶段 +* [Apache Oozie](http://oozie.apache.org/) 作为工作流调度程序（研究替代方案） +* [扩展](https://github.com/twitter/scalding)用于数据转换 +* [Avro](http://avro.apache.org/) 用于数据序列化 +* [Apache Parquet](http://parquet.incubator.apache.org/) 用于数据序列化 + +### 服务器和资源调配 + +* 多为裸金属 +* 多个数据中心 +* [CentOS](http://www.centos.org/) +* [厨师](https://www.chef.io/)用于配置几乎所有内容 +* [Berkshelf](http://berkshelf.com/) ，用于管理 Chef 依赖项 +* [测试厨房](http://kitchen.ci/)，用于在 VM 上运行基础结构测试 +* [Ansible](http://www.ansible.com/) 用于滚动升级 + +### 监控方式 + +* [Nagios](http://www.nagios.org/) 用于常规操作监控 +* [仙人掌](http://www.cacti.net/)用于图形和容量规划 +* [Graylog2](https://www.graylog2.org/) 适用于应用程序日志 +* 用于服务器日志的 [Logstash](http://logstash.net/) +* [Kibana](http://www.elasticsearch.org/overview/kibana/) 用于查询 logstash +* [统计信息](https://github.com/etsy/statsd)，用于从应用程序收集实时指标 +* [石墨](http://graphite.wikidot.com/)，用于存储应用程序中的实时指标 +* [Grafana](http://grafana.org/) 用于创建带有应用指标的精美仪表板 +* [集线器](https://hubot.github.com/)用于基于聊天的监视 + +## 架构概述 + +* 裸机服务器被用作云提供商的更便宜，更强大的替代产品。 +* 在欧洲和美国的 3 个不同数据中心托管服务器。 +* Nginx 前端将 HTTP 请求路由到独角兽工作者并执行 SSL 终止。 +* [Pacemaker](http://clusterlabs.org/) 用于确保 Nginx 服务器的高可用性。 +* 在不同的国家/地区，每个 Vinted 门户网站都有自己单独的部署和资源集。 +* 为了提高机器利用率，属于多个门户的大多数服务可以在单个裸机服务器上彼此并行运行。 主厨配方负责唯一的端口分配和其他分离问题。 +* 通过为每个门户网站使用单独的数据库来避免 MySQL 分片。 +* 在我们最大的门户中，功能性分片已经在发生，距离单个最大表无法容纳在服务器中的点还差几个月。 +* Rails 应用程序中的缓存使用带有 L2 缓存的自定义机制，可以防止主缓存过期时出现峰值。 使用了几种缓存策略： + * 远程（在 memcached 中） + * 本地（在独角兽工作者的记忆中） + * 半本地（在独角兽工作器内存中，当本地缓存到期时回退到 memcached）。 +* 围绕核心 Rails 应用程序构建了几个微服务，它们都有明确的用途，例如发送 iOS 推送通知，存储和提供品牌名称，存储和提供标签。 +* 微服务可以是按端口，按数据中心或全局的。 +* 每个微服务的多个实例正在运行以实现高可用性。 +* Nginx 平衡了基于 HTTP 的微服务。 +* 使用 Redis 实现每个成员的自定义 feed。 +* 使用过滤器（自定义大小，颜色等）时，从 Sphinx 索引而不是 MySQL 加载目录页面。 +* 图像由单独的 Rails 应用处理。 +* 处理后的图像存储在 GlusterFS 中。 +* 第 3 次匹配后会缓存图片，因为前几次匹配通常来自上传者，并且图片可能会旋转。 +* 使用 [twemproxy](https://github.com/twitter/twemproxy) 分割 Memcached 实例。 + +## 球队 + +* 超过 150 名全职员工 +* 30 位开发人员（后端，前端，移动） +* 5 名现场可靠性工程师 +* 立陶宛维尔纽斯的总部 +* 在美国，德国，法国，捷克共和国和波兰设有办事处 + +## 公司的运作方式 + +* 几乎所有信息对所有员工开放 +* 使用 GitHub 进行几乎所有操作（包括讨论公司问题） +* Slack 中的实时讨论 +* 每个人都可以自由参加他们感兴趣的事情 +* 自治队 +* 没有资历等级 +* 跨职能开发团队 +* 没有强制执行的流程，团队可以决定如何管理自己 +* 团队致力于解决高层问题，并决定如何解决它们 +* 每个团队都决定如何，何时何地工作 +* 团队在需要时自行雇用 + +## 开发周期 + +* 开发人员从主人处分支。 +* 更改成为 GitHub 中的请求请求。 +* Jenkins 运行 [Pronto](https://github.com/mmozuras/pronto) 进行静态代码和样式检查，在 pull request 分支上运行所有测试，并使用状态更新 GitHub pull request。 +* 其他开发人员查看更改，添加评论。 +* 拉取请求可能会使用各种修复程序多次更新。 +* 每次更新后，Jenkins 都会运行所有测试。 +* 在与 master 合并之前清理 Git 历史，以保持 master 历史的简洁性。 +* 接受的请求请求将合并到主服务器中。 +* Jenkins 使用所有测试运行主版本，并触发部署作业以推出新版本。 +* 几分钟后，代码到达 master 分支后，将其应用于生产中。 +* 拉取请求通常很小。 +* 每天部署约 300 次。 + +## 避免失败 + +每天部署数百次并不意味着总是必须破坏所有东西，但是保持站点稳定需要一定的纪律。 + +* 如果测试失败，则不会进行部署。 没有方法可以覆盖它，母版必须为绿色才能进行部署。 +* 每天晚上和周末自动部署锁定。 +* 任何人都可以通过 Slack 聊天手动锁定部署。 +* 部署锁定后，可以从 Slack 聊天中手动“强制”部署。 +* 在审查代码时，团队非常挑剔。 质量标准设置得很高。 测试是强制性的。 +* 在 Unicorn 重新加载代码之前，将在生产中进行预热。 它包括对门户网站各个关键部分的若干请求。 +* 在预热期间，如果任何一个请求均未返回 200 OK，则旧代码将保留，并且部署将失败。 +* 有时，测试/预热未发现问题，并且已损坏的代码发布到了生产环境中。 +* 错误将流式传输到 Graylog 服务器。 +* 如果错误率超过阈值，则会触发警报。 +* 错误率警报和失败的构建通知会立即报告给 Slack 聊天。 +* 所有错误都包含额外的元数据：Unicorn worker 主机和 pid，HTTP 请求详细信息，导致问题的代码的 git 修订版，错误回溯。 +* 某些类型的“致命”错误也直接报告给 Slack 聊天。 +* 每个部署日志都包含带有所有更改的 GitHub 差异 URL。 +* 如果生产中出现问题，由于变更集和即时错误反馈的原因，很容易快速查明问题。 +* 部署详细信息会报告给 NewRelic，从而可以轻松解决性能瓶颈的引入。 + +## 减少生产时间 + +快速发布和稳定发布都非常受关注，团队一直在努力使构建和部署时间尽可能短。 + +* 完整的测试套件包含> 7000 个测试，运行时间约为 3 分钟。 +* 不断添加新的测试。 +* Jenkins 在具有 32 个 CPU，128G RAM 和 SSD 驱动器的裸机上运行。 +* Jenkins 将所有测试分成多个块，并并行运行它们，以汇总最终结果。 +* 在没有并行化的情况下，测试将在一台普通计算机上运行 1 个小时以上。 +* 在 Jenkins 中，对于 master 分支中的每次提交，Rails 资产都是预先构建的。 +* 在部署期间，从 jenkins 下载预建资产，并将其上载到所有目标服务器。 +* 将版本上载到目标服务器时使用 BitTorrent。 + +## 运行实时数据库迁移 + +在大多数情况下，即使在高峰时间，我们也可以在不停机的情况下更改生产 MySQL 数据库的结构。 + +* 在任何部署期间都可能发生数据库迁移 +* Percona 工具箱的 pt-online-schema-change 用于在表的副本上运行更改，同时使其与原始副本保持同步，并在更改完成后将副本与原始副本切换 + +# 运作方式 + +## 服务器配置 + +* Chef 用于提供我们基础架构的几乎所有方面。 +* SRE 团队确实会提出对基础结构更改的请求，就像开发团队对代码更改所做的一样。 +* 詹金斯（Jenkins）正在验证所有 Chef 拉取请求，运行交叉依赖关系检查，食品评论等。 +* 团队在 GitHub 上审查了厨师代码的更改。 +* 开发人员可以向 Chef 存储库发出基础结构更改请求请求。 +* 合并拉取请求时，Jenkins 上载更改后的 Chef 食谱并将其应用于生产中。 +* 计划产生 DigitalOcean 小滴以与 Jenkins 一起进行 Chef 厨房测试。 +* Jenkins 本身是使用 Chef 配置的，而不是使用 Web UI。 + +## 监控方式 + +* 仙人掌图服务器端指标 +* Nagios 检查可能出现的所有故障 +* Nagios 健康检查，用于我们的某些应用程序和服务 +* Statsd / Graphite，用于跟踪应用程序指标，例如成员登录，注册，数据库对象创建 +* Grafana 用于漂亮的仪表板 +* 可以使用 Chef 动态描述和创建 Grafana 仪表板 + +## 聊天操作 + +* Hubot 坐在 Slack 中。 +* 松弛房间通过 [hubot-pubsub](https://github.com/spajus/hubot-pubsub) 订阅了各种事件通知。 +* #deploy 会议室显示有关部署的信息，并提供指向 GitHub diff，Jenkins 控制台输出等的链接。在这里，可以使用简单的聊天命令来触发，锁定和解锁部署。 +* ＃deploy-fail 会议室仅显示部署失败。 +* #failboat 会议室显示有关错误率和生产中个别错误的公告。 +* 有多个＃failboat- *房间，其中提供有关 cron 故障，卡住的 resque 作业，nagios 警告，newrelic 警报的信息。 +* 每天两次将 Graylog 错误与 GitHub 进行处理和交叉检查，生成报告并将其提交给开发团队。 +* 如果有人在 GitHub 上提到您，Hubot 会在 Slack 上的私人消息中为您提供该问题的链接。 +* 在 GitHub 中创建问题或请求请求时，提到的团队会在其适当的 Slack 会议室中收到 ping 命令。 +* 可以通过 Hubot 在 Slack 聊天中查询并显示石墨图。 +* 您可以向 Hubo​​t 询问有关基础设施的问题，即有关部署特定服务的机器的问题。 Hubot 查询 Chef 服务器以获取数据。 +* 开发人员将 Hubot 通知用于我们应用中发生的某些事件。 例如，向客户支持聊天室自动通知可能的欺诈案件。 +* Hubot 与 Office [netatmo](https://www.netatmo.com/) 模块集成在一起，可以告诉所有人什么是 CO2，噪声，温度和湿度水平。 + +# 数据仓库堆栈 + +* 我们从两个来源提取数据： + * 网站事件跟踪数据：印象数，点击数等 + * 数据库（MySQL）更改。 +* 大多数事件跟踪数据都从 JavaScript / Android / iOS 前端应用程序发布到 HTTP 端点。 一些事件由我们的核心 Ruby on Rails 应用程序发布到本地 UDP 套接字。 我们选择 UDP 以避免阻塞请求。 +* 有一种服务可以监听 UDP 套接字上的新事件，对它们进行缓冲，并定期在 Kafka 中发出原始事件的主题。 +* 流处理服务使用原始事件主题，验证事件，将它们编码为 Avro 格式，然后发出特定于事件的主题。 +* 我们将事件的 Avro 模式保存在单独的集中式模式注册表服务中。 +* 无效事件被置于单独的 Kafka 主题中，以进行可能的更正。 +* 我们使用 LinkedIn 的 Camus 作业将事件从特定于事件的主题逐步转移到 HDFS。 事件到 Hadoop 的时间通常最多为一个小时。 +* 使用 Hive 和 Impala 进行临时查询和数据分析。 +* 研究基于伸缩的数据处理解决方案。 +* 报告使用我们内部开发的，用 Ruby 编写的类似 OLAP 的报告系统运行。 -> 原文： [http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html) +# 得到教训 -![](img/0455a7ccb5ea7807b8e9bf566b5ae473.png) +## 产品开发 -*这是 LinkedIn 分布式数据系统团队的高级成员 [Siddharth Anand](http://practicalcloudcomputing.com/) 的特邀帖子。* +* 投资代码质量。 +* 通过测试涵盖所有内容。 +* 发布小更改。 +* 使用功能开关将未完成的功能部署到生产中。 +* 开发某些东西时，不要保留长时间运行的代码分支。 +* 投资一个快速的发布周期。 +* 首先构建移动产品。 +* 设计 API 从一开始就很好，以后很难更改。 +* 在 RabbitMQ 消息中包含发件人主机名和应用程序名称可以节省生命。 +* 不要猜测或做假设，请进行 [AB](https://github.com/vinted/ab) 测试并检查数据。 +* 如果您打算将 Redis 用于更大的事情，请从一开始就考虑分片。 +* 如果您计划使 Rails 保持最新状态，则切勿使用叉状和稍作修饰的红宝石宝石。 +* 通过社交网络尽可能轻松地共享您的内容。 +* 搜索引擎优化是一项全职工作。 -在过去的三年中，我很幸运能够与许多新兴的 NoSQL 产品一起使用，以支持高流量，面向客户的网站的需求。 +## 基础设施和运营 -在 2010 年，我帮助 Netflix 成功 [将其 Web 规模用例从 Oracle 转换为 AWS 的托管数据库服务 SimpleDB](http://highscalability.com/blog/2010/10/22/paper-netflixs-transition-to-high-availability-storage-syste.html) 。 迁移完成后，我们开始了第二次迁移，这次是从 SimpleDB 到 Cassandra 的迁移。 第一次过渡是我们从自己的数据中心迁移到 AWS 的云的关键。 第二个是我们从一个 AWS 区域扩展到多个地理分布区域的关键-今天，Netflix 为两个 AWS 区域提供流量，一个在弗吉尼亚州，另一个在爱尔兰（ [F1](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Footnote_1) ）。 这两个过渡都是成功的，但都涉及集成难题，例如创建数据库复制技术。 +* 经常部署以提高系统稳定性。 起初听起来可能违反直觉。 +* 自动化一切。 +* 监视所有可能发生的故障。 +* 网络交换缓冲区很重要。 +* 容量规划很困难。 +* 从一开始就考虑 HA。 +* RabbitMQ 集群不值得付出努力。 +* 测量并绘制所有图形：HTTP 响应时间，Resque 队列大小，模型持久率，Redis 响应时间。 您无法改善无法衡量的东西。 -2011 年 12 月，我加入了 LinkedIn 的分布式数据系统（ DDS ）团队。 DDS 开发了数据基础结构，包括但不限于 NoSQL 数据库和数据复制系统。 LinkedIn 对构建和开放源代码创新项目并不陌生，它正在加倍使用 NoSQL 来加速其业务-DDS 正在开发一个名为 Espresso（ [R1](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Reference_1) ）的新 NoSQL 数据库，这是以后的主题。 +## 数据仓库堆栈 -观察到两家流量大的网络公司解决了类似的问题之后，我不禁注意到了一系列的创新。 这些问题中有些是困难的，对于每个公司来说，单独解决其问题确实是不幸的。 同时，由于缺乏可靠的开源替代方案，每个公司都不得不解决这些问题。 这显然对一个以快速发展的新兴企业为主导的行业产生了影响，这些行业无法建立 50 人的基础设施开发团队，也无法花数月的时间来构建功能。 +* Hadoop 生态系统中有许多工具。 很难选择合适的。 +* 如果您正在为 Hive 编写用户定义函数（UDF），那么该考虑使用非 SQL 解决方案进行数据转换了。 +* “ Hadoop 应用程序”概念含糊不清。 通常，我们需要手动将应用程序组件粘合在一起。 +* 每个人都编写自己的工作流管理器。 并且有充分的理由。 +* 分布式系统监视非常困难。 异常检测和作图很有帮助。 +* 核心 Hadoop 基础架构（HDFS，YARN）坚如磐石，但较新的工具通常会有细微差别。 +* 卡夫卡很棒。 -## **更改数据捕获系统** +这个网站是关于高可扩展性还是如何浪费服务器？ 您是否真的需要 220 台服务器来服务〜2300req / sec？ -今天，我想重点介绍一种这样的创新：Change Data Capture 系统 +他了解了其中一些服务器使用情况。 这是 Ruby on Rails，所以这就是原因。 -关系数据库已经存在很长时间了，已经成为公司所有数据的可靠存储介质。 换句话说，它是公司业务关键数据的真实来源。 通常，数据会从此主要数据存储中提取，转换并存储在辅助数据存储中，例如数据仓库。 该二级存储通常支持推动业务洞察力和方向的数据分析。 在此方案中，这两个存储分别称为 OLTP 存储和 OLAP 存储。 （ [F2](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Footnote_2) ） +您能否详细说明“ RabbitMQ 集群不值得付出”？ 您在运行时遇到问题吗？ -所有这些已经存在了数十年，那么有什么新东西？ 来自主存储的数据越来越多地用于提供业务决策之外的其他信息。 在 LinkedIn 上，它还提供实时搜索索引，实时网络图索引，缓存一致性，数据库只读副本等。这些都是 LinkedIn 的近实时数据需求的示例。 +@Peter-与其他高可用性站点一样，它们可以使用少于十个服务器来为流量提供服务。 +从文章看来-其余内容涉及（a）收集和分析数据； （b）监督和监督系统； （c）确保高可用性。 +在三个区域中只有 10 台边缘（缓存/ nginx）服务器（由于 HA，30 台独角兽是自然扩展）。 鉴于流量不统一（因此 200M req / day 不能转换为 2300 req / s），这似乎是适中的，因为在任何区域中，请求都只能由几个端点服务器之一来处理。 再次-这就是您在 HA 设置中所期望的-2 个以上的服务器用于任何潜在的传入（请求）请求。 -如果您曾经从事过将数据从主存储转移到辅助存储的工作，那么您无疑会熟悉可用的选项。 +我必须同意彼得的观点。 在最近阅读了此处的 Stack Exchange 文章之后，很难不认为此设置会浪费一些资源。 -例如，如果您在 OLTP 到 OLAP 的空间中工作，则使用某种 ETL（提取，转换和加载）技术。 这个领域已经看到了围绕工具（，例如，使用 GUI 拖放工具轻松定义转换）和跨供应商集成（，例如从 Oracle 到 Teradata，Aster Data 等）的创新。 .. ）。 该行业通常使用 ETL 进行夜间工作，以使高管可以了解前一天，一周，一个月，一年的业务表现。 +感谢分享。 +您似乎正在使用大量的开源项目。 我对你的决定感到好奇。 团队成员一开始是否已经熟悉大多数技术？ 如果没有，那么在这么多方面加强工作是否有点势不可挡？ -如果需要从主数据存储中获取近实时更新流（如下所示）以解决 LinkedIn 的近实时需求，该怎么办？ +大家好， -![Databus_Use_Cases](img/9d4afc940734b06775db5cf4aa4aeee1.png) +Vaidotas，这里的 Vinted 工程师之一。 -除了昂贵且专有的特定于供应商的产品外，几乎没有其他选择。 +想对服务器数量发表评论。 如果您查看详细信息，将会看到很多服务器专用于分析数据收集。 而且我认为分析数据可能是单独的主题。 -## **引入数据总线** +如果您查看运行 Vinted 应用程序所需的服务器及其所有内容，则会看到以下内容： -Databus 是该领域的创新解决方案。 +34 个用于图像处理和存储（9.3 亿张照片） +30 个用于 Unicorn 和微服务（每天 2 亿个请求） +28 个用于 MySQL 数据库，包括副本 +19 个用于 Sphinx 搜索（2500 万个列出的项 索引） +10，用于可处理的后台作业 +10，用于与 Nginx 进行负载平衡（充当代理和一些缓存，可能会更少，但在我们运营所在的不同国家/地区需要它们）。 +Redis 4 -它具有以下功能： +因此，这就是 135 台运行应用程序基础结构的服务器。 现在请记住，所有内容都必须具有高可用性。 这意味着至少所有内容的 2 倍，即使您目前不需要/不使用它也是如此。 -* Pub-sub 语义 -* 订单内交付保证 -* 源处的提交按事务分组 - * ACID 语义在整个管道中得以保留 -* 支持流分割 - * 然后按分区确定订购保证 -* 像其他消息传递系统一样，为最近发布的消息提供了非常低的延迟消耗 -* 与其他邮件系统不同，它提供任意长的回溯，而不会影响源 -* 高可用性和可靠性 +希望能解释一下服务器数量。 -## 数据总线如何工作？ +另外，您的行动小组的规模如何，才能维持这种运营/基础架构？ 仅列出了 SRE。5\. DevOps 工程师，系统管理员和/或 DBA 怎么样？ -数据总线由 3 个重要部分组成： +您的 Jenkins 并行化设置似乎很有趣。 你是如何做到的？ 也许不久之后还会有另一篇专门针对此的博客文章？ -* 继电器 -* 引导程序 -* 客户资料库 +乔恩，我们有 5 位站点可靠性工程师来维护所有基础架构。 我们执行从服务器引导到数据库管理的所有工作。 我们严重依赖自动化:) -下图显示了 Databus 架构。 数据总线中继将从源数据库（例如 Oracle，MySQL 等... ）（ **步骤 1** ）中拉出最近提交的事务。 中继会将这些数据反序列化为紧凑形式（Avro 等），并将结果存储在循环的内存缓冲区中。 侦听事件的客户端（订户）将拉动最近在线的更改，因为它们出现在中继中（ **步骤 2** ）。 Bootstrap 组件还在监听中继中出现的在线更改。（ **步骤 3** ） +我真正无法理解的是-每天 200 M 的请求如何转换为实际的 Internet 流量？ StackExchange 的请求量为 1.5 亿，在 Alexa 评分中排名第 53，vinted.com 在 38763 上排名较高，但 RPS 较高。 +与 http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html（wix）相同-他们要求 700M 请求/ 一天，但肯定无法将 Alexa 评级与 StackExchange 相比。 -![Databus_Operation](img/d7b71c157addeb8bce27a9854cf6b250.png) +谁能澄清？ -如果订户落在后面，以致其请求的数据不再位于中继的内存缓冲区中，则订户可以请求从过去的时间 T 开始出现的合并增量（ **步骤 4** ）。 这将返回自时间 T 以来发生的所有更改的有效表示。 +@tao，一开始只有一个开发人员（CEO，联合创始人），而且技术堆栈要小得多。 您的问题的答案是否定的。 -![Databus_Operation](img/f255cfed148c4910c091f130a49bc609.png) +当项目开始发展时，出现了一些东西。 我们雇用了更多的开发人员，工程师等。我们选择雇用最聪明的工程师。 之所以使用某些技术是因为他们具有经验，而其他技术则是“试验和错误”（尤其是大数据的东西）。 我们在解决问题的过程中一直在解决它们。 我们仍然有需要解决的问题。 这就是新技术出现的方式。 我相信，一年后，我们可以写一篇关于我们如何做事的文章。 -如果没有数据集先验知识的新订户要加入聚会，则需要完全引导。 首先，订户的 Databus 客户端库将在过去的某个时间 T 请求一个一致的快照（ **步骤 5** ）。 然后，自该时间 T 起，客户端库将请求合并 Delta（ **步骤 6** ）。 在订阅服务器应用合并增量之后，客户端库将切换为侦听来自中继的联机更改（ **步骤 7** ）。 客户端库帮助订户获得自时间 T 以来的所有更改，时间 T 可以是任意时间点，从而使订户不受更改来源的详细信息的影响。 +@lan：RabbitMQ 非常棒，我们正在使用它，但是在分析事件方面，我们遇到了一些限制，因此选择 kafka 作为事件发射。 RabbitMQ 集群的东西很容易破解。 正如文档所述-“ RabbitMQ 群集不能很好地容忍网络分区”，这并不像我们希望的那样罕见。 -![Databus_Operation](img/69f0bbc5a6594315e3884e18bbad2fe9.png) +@Tim：我们使用 https://github.com/grosser/parallel_tests 的稍加修改版本 -## **Databus 的自举组件** +@安东：不确定“转换”的含义，但我们为女孩提供了超过 10 Gigs 的流量。 在谈论 Alexa 时，目前我们有 8 个不同的国家，例如，我们的一个国家（http://kleiderkreisel.de）的排名为 7,468，因此没有一个汇总排名。 另一件事是，70％的流量来自移动应用程序，我不确定 Alexa 是否会对此进行计数。 -Databus 最具创新性的功能之一是其 Bootstrap 组件。 数据变更捕获系统已经存在了很长时间（，例如 Oracle Streams ）。 但是，当使用者落后时，所有这些系统都会在主数据存储上增加负载。 - -引导一个全新的消费者是另一个问题。 它通常涉及一个非常手动的过程-即在一个临时的 Oracle 实例上恢复前一晚的快照，转换数据并将其传输给使用者，然后应用自快照以来的更改等... - -Databus 的 Bootstrap 组件以无缝，自动化的方式处理上述两个用例。 - -## Databus 的自举组件如何工作？ - -Databus Bootstrap 组件由两种类型的存储组成：日志存储和快照存储。 日志存储服务于合并增量，而快照存储服务于一致的快照。 - -![Databus_Bootstrap](img/45e073fbad31fdbe5e8eba31757bd984.png) - -1. 如前所述，Bootstrap 组件侦听中继中发生的在线更改。 LogWriter 将这些更改附加到日志存储。 -2. 日志应用程序将日志存储中的最新操作应用于快照存储 -3. 如果新订户连接到 Databus，则该订户将从运行在 Bootstrap 组件中的 Bootstrap 服务器进行引导。 -4. 客户端将首先从快照存储中获取一致的快照 -5. 然后，客户端将从日志存储中获得出色的合并增量 -6. 客户端赶上中继的内存缓冲区窗口后，客户端将切换为从中继读取 - -## 数据总线的未来计划 - -Databus 和 Espresso（我们下一个 NoSQL 商店的的工程师，足够说）的团队一直在不懈地努力以支持 Espresso 中的 Databus 复制-Databus 将成为 Espresso 的本机内部复制技术。 此外，一旦团队找到了一些空闲时间，他们将对其进行开源。 - -我们正在寻找在解决棘手问题方面有良好记录的工程师加入我们的 DDS。 如果您有兴趣，可以随时在 [LinkedIn](http://www.linkedin.com/in/siddharthanand) 上 ping 我。 - -## 这对 NoSQL 意味着什么 - -与 Databus 一样酷，它不适用于所有 NoSQL 存储。 当前，许多 NoSQL 技术（尤其是许多 Dynamo 风格的键-值存储）提供的功能集之间存在很大差距。 它们没有提供 Databus 可以提取的时间轴一致的更改流。 - -没有这种支持，将有两个未实现的用例： - -* 支持向现有商业智能基础架构（，即每晚，面向 ETL 的负载）中的出站提要 -* 支持向二级索引（例如搜索，网络图，缓存等）的出站近实时提要... - -最近，对于 Cassandra，Netflix 和 Ooyala 都分别解决了这个问题。 Netflix 发布了一个有关 [Aegisthus](http://techblog.netflix.com/2012/02/aegisthus-bulk-data-pipeline-out-of.html) 的技术博客，该系统将最终一致的数据文件集转换为时间轴一致的流。 该流当前由 Business Intelligence 消耗-它不是实时的，因为它取决于内存刷新间隔。 但是，通过一些调整，它可以接近实时。 我们期待该技术的开源。 - -更重要的是，我们希望 NoSQL 供应商为其产品解决此问题。 - -## 更多资源 - -* [数据基础结构@ LinkedIn](http://www.slideshare.net/r39132/linkedin-data-infrastructure-qcon-london-2012) -QCON London 2012，Sid Anand，LinkedIn 高级会员 -* [数据总线：用于时间线一致的更改数据捕获的系统](http://www.slideshare.net/dtunkelang/databus-a-system-for-timelineconsistent-lowlatency-change-capture) -CIKM 2011，Chavdar Botev，LinkedIn 高级会员 -* LinkedIn 上的 [数据基础结构](http://www-conf.slac.stanford.edu/xldb2011/talks/xldb2011_tue_1005_LinkedIn.pdf)-XLDB 2011，Shirshanka Das，LinkedIn 高级成员 -* [LinkedIn 基础设施](http://qconsf.com/dl/QConSF2007/slides/public/JeanLucVaillant_LinkedIn.pdf) -QCON SF 2007，Jean-Luc Vaillant，LinkedIn 联合创始人兼前首席技术官 - -## 致谢 - -我要感谢构建此系统的工程师们的不懈努力： - -阿迪亚·奥拉德卡（Aditya Auradkar），查夫达尔·博特夫（Chavdar Botev），席尔香卡·达斯（Shirshanka Das），戴夫·德马格（Dave DeMaagd），亚历克斯·费恩伯格（Alex Feinberg），潘宁德拉·甘蒂（Phanindra Ganti），雷·高（Bhaskar Ghosh），基肖尔·戈帕拉克里希纳（Kishore Gopalakrishna），米希尔·甘地（Mihir Gandhi），布伦丹·哈里斯（Broaddan Harris），斯沃洛普·贾加迪什（Swaroop Jagadish），乔尔·科西（Joel Koshy），凯文·克鲁瓦兹（Jay Lua Naga） ，Neha Narkhede，Sasha Pachev，Igor Perisic，Lin Qiao，Tom Quiggle，Jun Rao，Bob Schulman，Abraham Sebastian，Oliver Seeliger，Adam Silberstein，Boris Shkolnik，Chinmay Soman，Subbu Subramaniam，Roshan Sumbaly，Kapil Surlaker，Sajid Topiwala Tran，Balaji Varadarajan，Jemiah Westerman，Zach White，David Zhang，Jason Zhang，Agila Devi，Neil Pinto，Ramana Ramakrishnan，Sai Sundar，Nishant Vyas，Agila Devi，Neil Pinto，Ramana Ramakrishnan，Sai Sundar 和 Nishant Vyas。 - -我还要特别感谢 Bob Schulman，Kapil Surlaker 和 Shirshanka Das 对本文的帮助。 - -## 脚注 - -1. 就快速延迟而言，Netflix 的英国和爱尔兰客户受益于 Netflix 在本地的区域性业务。 如果您不熟悉 AWS 区域，则区域可为最终用户提供地理位置优势。 区域本身由几个数据中心组成，这些数据中心在 AWS 中称为“可用区”。 顾名思义，可用区在托管区域内提供灾难恢复。 对于像网站这样的对延迟敏感的应用程序，跨区域灾难恢复从来都不是一个好主意。 -2. OLTP（在线事务处理）与 OLAP（在线分析处理）：这区分了它们的用途-OLTP 用于主数据服务，OLAP 用于主数据的修改后的副本的分析处理。 - -“ Databus 简介” ...这可用开源吗？ 那将会？ - -我们想开始讨论。 它将很快开源。 人们对此有何看法？ 人们将如何使用它？ 等等... - -我们计划在今年晚些时候开源 Databus。 - -我期待它被开源。 我认为许多人（包括我自己在内）都将使用它从旧版源数据库中将其用于 ETL，在这些旧版源数据库中，架构不太适合加载增量数据集。 那里的商业 CDC 产品（例如 Attunity）使开发人员难以自定义和做出贡献。 我正在研究一种通过对 SQL Server 事务日志进行反向工程来获取 CDC 数据的解决方案，并且很乐意遵循常见的 CDC 抽象。 - -我看到这被用于将交易从关系业务软件数据库中引入并进入多个专用系统-图形数据库，统计平台，HDFS 存储，内存 BI 存储和流数据库-都在同一时间 时间。 我很高兴听到这一消息，因为它是我对商业软件的未来愿景的关键部分。 - -首先，感谢您与我们分享。 - -我对 ETL 方面的理解不够充分，但是我尝试查看 MongoDB 如何适合此方案。 我很可能在这里简化了一些事情，但是请忍受。 :) - -因此，我们都知道有一个常规数据库存储主要数据。 该数据库按顺序发布它的更改，这些更改被捕获并保存在固定大小的缓冲区中，并可供订户使用。 更改的缓冲区定期备份到磁盘上。 打算进行完全同步的新成员可以从备份副本中提取更改。 与订户一起的数据可以被用来导出其他有意义的数据。 - -在我看来，MongoDB 提供了所有这些功能，或者至少提供了构建此类系统的基本基础结构。 - -常规数据库是 MongoDB。 它以 oplog 的形式发布更改-通常是内存映射。 客户端可以打开一个尾部游标到 oplog 集合，并在更改发生时将更改流式传输到数据库中。 客户端可以与作为副本集的一部分安排的辅助 DB 相关联，在该副本集上可以运行 Map-Reduce 或 Aggregation 任务。 辅助服务器之一可以充当“ Bootstrap 服务器”。 （通过执行完全同步，可以从另一个辅助节点启动新的辅助节点）。 特殊辅助节点的操作日志可能类似于“中继”，以避免在主节点上加载。 - -这有道理吗？ MongoDB 是否为此项目进行了评估？ - -任何想法，将不胜感激。 - -OTOH，现在，如果这必须与特定的数据库一起使用，那么每个数据库都将有“ Databus 驱动程序”吗？ 例如，如果必须与 MongoDB 一起使用，则必须有一个 MongoDB 驱动程序，该驱动程序可以理解 MongoDB 发布的 oplog 格式并以通用格式提供给客户端。 - -还是您要发布标准并要求数据库开发人员根据该标准进行更改？ - -再次感谢您。 - -顺便说一句，我也正在等待有关 Espresso 的帖子。 :) - --婆罗门 - -席德，不错的帖子 在 Yammer，我们正在为近实时搜索做类似的事情。 Databus 看起来更广泛，但是原理相似。 我们正在使用 BDB JE 作为本质上是变更集服务的后备存储。 在更新 ActiveRecord 模型时，Rails 应用程序将更改为变更集服务的信标。 变更集服务为变更建立索引。 另一个服务遍历更改集索引并生成 Lucene 索引。 模型之间存在一些额外的依赖关系，因此，当依赖模型更新时，依赖于该模型的模型将“失效”，因此将其重新索引。 - -我真的很想了解更多信息，并且对开放源代码有所了解。 我们所提供的大部分服务满足了我们的需求，但是绝对可以改善。 - -席德 - -好的帖子，并感谢分享。 我们正在寻求重新发明轮子，以创建与您上面描述的非常相似的东西。 您是否知道何时可以尝试使用这些位？ 我们将非常有兴趣了解更多有关该产品的信息，并看一看开放源代码并在适用的情况下做出贡献。 - -我试图找到有关中继如何将已提交的更改从数据库中拉出的详细信息。 -是否有任何视频或文档对此进行了详细说明？ -据我了解，今天它已在 Oracle 上使用。 该技术是否取决于特定的 Oracle 功能，或者可以在“通用” RDBMS 上实现？ - -Databus Relay 可以从 MS SQL Server（源数据库）中提取事务。 \ No newline at end of file +希望大家，Vinted 回答了您所有的问题:) \ No newline at end of file diff --git a/docs/16.md b/docs/16.md index b264bde..e06484c 100644 --- a/docs/16.md +++ b/docs/16.md @@ -1,239 +1,78 @@ -# The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购 +# Feedblendr 架构-使用 EC2 进行扩展 -> 原文： [http://highscalability.com/blog/2016/9/13/the-dollar-shave-club-architecture-unilever-bought-for-1-bil.html](http://highscalability.com/blog/2016/9/13/the-dollar-shave-club-architecture-unilever-bought-for-1-bil.html) +> 原文： [http://highscalability.com/blog/2007/10/30/feedblendr-architecture-using-ec2-to-scale.html](http://highscalability.com/blog/2007/10/30/feedblendr-architecture-using-ec2-to-scale.html) -![](img/5b7af8042fb8d87998d9de26b181d823.png) +一个男人做了一个梦。 他的梦想是将一堆 RSS / Atom / RDF 提要混合到一个提要中。 这个人是 [Feedville](http://feedville.com/) 的 Beau Lebens，并且像大多数梦想家一样，他的硬币有些短缺。 因此，他在廉价的托管服务提供商的家中避难，而 Beau 实现了他的梦想，创建了 [FEEDblendr](http://feedblendr.com/) 。 但是 FEEDblendr 消耗了太多 CPU 来创建混合供稿，以至于廉价的托管服务提供商命令 Beau 来寻找另一个家。 博去哪儿了？ 他最终在亚马逊 EC2 的虚拟机室内找到了一个新家。 这是关于 Beau 最终如何能够在负担得起的 CPU 周期的摇篮中安全地创建自己的供稿的故事。 -*这是 [Jason Bosco](https://www.linkedin.com/in/jasonbosco) ， [Dollar Shave Club [ HTG12 的核心平台&基础架构工程总监，介绍其电子商务技术的基础架构。](https://www.dollarshaveclub.com/)* +网站：http：//feedblendr.com/ -Dollar Shave Club 拥有 300 万以上的会员，今年的收入将超过 2 亿美元。 尽管大多数人都熟悉该公司的市场营销，但是自成立以来短短几年内的巨大增长主要归功于其 45 名工程师的团队。 +## 该平台 -Dollar Shave Club 工程学的数字： +* EC2（Fedora Core 6 Lite 发行版）* S3* 阿帕奇* 的 PHP* 的 MySQL* DynDNS (for round robin DNS) -## 核心统计信息 + ## 统计资料 -* 超级碗广告的投放没有停机时间：1 + * Beau 是具有一些系统管理员技能的开发人员，而不是 Web 服务器管理员，因此创建 FEEDblendr 涉及很多学习。* FEEDblendr 使用 2 个 EC2 实例。 两个实例都使用相同的 Amazon 实例（AMI）。* 已经创建了 10,000 多个混合，其中包含 45,000 多个源 feed。* 每天大约创建 30 个混合。 实际上，这两个实例上的处理器被钉得很高（大部分时间的平均负载为 10 到 20）。 -* 每月流量带宽：9 TB + ## 架构 -* 通过 Arm 处理的订单：3800 万张订单 + * 轮询 DNS 用于在实例之间进行负载平衡。 + -手动更新 DNS，因为在更新 DNS 之前验证实例可以正常工作。 + -实例现在看起来比以前更稳定，但是您仍然必须假设它们随时都可能丢失，并且两次重启之间不会保留任何数据。* 由于 EC2 没有像样的持久性存储系统，因此数据库仍托管在外部服务上。* AMI 保持最小。 这是一个干净的实例，带有一些自动部署代码，可从 S3 加载应用程序。 这意味着您不必为每个软件版本创建新实例。* 部署过程为： + -软件是在笔记本电脑上开发的，并存储在 Subversion 中。 + -Makefile 用于获取修订，修复权限等，打包并推送到 S3。 + -AMI 启动时，它将运行脚本以从 S3 获取软件包。 + -打开包装包，并执行其中的特定脚本以继续安装过程。 + -Apache，PHP 等的配置文件已更新。 + -固定了服务器特定的权限，符号链接等。 + -Apache 重新启动，并使用该计算机的 IP 发送电子邮件。 然后使用新的 IP 地址手动更新 DNS。* 提要独立于每个实例进行智能缓存。 这是为了尽可能减少对饲料的昂贵轮询。 尝试将 S3 作为两个实例的通用提要缓存，但是速度太慢。 也许可以将提要写入每个实例，以便将它们缓存在每台计算机上？ -* 发现的错误总数：4,566 + ## 学过的知识 -* 自动化测试成绩：312,000 + * 低预算的启动可以使用 EC2 和 S3 有效地引导。* 对于精打细算的人，免费的 ZoneEdit 服务可能与每年 50 美元的 DynDNS 服务（效果很好）一样好。* 循环负载平衡缓慢且不可靠。 即使 DNS 的 TTL 较短，某些系统仍会长时间使用寻址的 IP，因此新计算机无法实现负载平衡。* RSS 实施存在许多问题，无法有效地合并摘要。 因为没有可靠的交叉实现方式来判断提要何时真正更改，所以不必要地花费大量 CPU 读取和混合提要。* 考虑到实例可以随时消失，这确实是一个很大的观念转变。 您必须更改您的架构和设计以适应这一事实。 但是，一旦将此模型内部化，就可以解决大多数问题。* EC2 较差的负载平衡和持久性功能使开发和部署变得异常困难。* 使用 AMI 的能力来传递参数，以选择要从 S3 加载的配置。 这样，您就可以测试不同的配置，而无需移动/删除当前活动的配置。* 创建一个自动化测试系统以在实例启动时对其进行验证。 如果测试通过，则自动更新 DNS。 这使得创建新实例变得容易，并且使慢速人员脱离了循环。* 始终从 S3 加载软件。 您想要发生的最后一件事是实例加载，由于某种原因无法联系您的 SVN 服务器，因此无法正确加载。 将其放在 S3 中实际上消除了这种情况的发生，因为它在同一网络上。 -* 通过语音发送的电子邮件：1.95 亿封电子邮件 + ## 相关文章 -* 处理并存储在海马中的 Analytics（分析）数据点：5.34 亿 + * [什么是“新闻河”风格的聚合器？](http://www.reallysimplesyndication.com/riverOfNews)* [使用亚马逊服务以 100 美元的价格构建无限可扩展的基础架构](http://highscalability.com/build-infinitely-scalable-infrastructure-100-using-amazon-services) -* 海马中的数据集大小：1.5TB +我可能会缺少一些东西，但我看不出这是“使用 EC2 进行扩展”的有趣示例。 -* 当前已部署的应用程序/服务：22 +在 Beau 使用 EC2 的方式使用 EC2 和从正常提供商设置两个租用服务器之间似乎没有什么区别。 实际上，获得租用服务器可能会更好，因为成本可能更低（EC2 实例的成本为每月 72 美元/月+带宽），并且数据库将位于同一网络上。 -* 服务器数量：325 +Beau 似乎没有做任何利用 EC2 的事情，例如根据需求动态创建和丢弃实例。 -## 技术堆栈 +我在这里想念什么吗？ 这是使用 EC2 进行扩展的有趣用法吗？ -* 前端框架的 Ember +>我可能缺少一些东西，但是我看不出这是“使用 EC2 进行缩放”的有趣示例。 -* 主要在后端上使用 Ruby on Rails +我承认在发现有趣的事情上有些变态，但从博人的立场（这是很多人的观点）来看，这部戏令人激动。 故事始于冲突：如何实现这个想法？ 第一种选择是传统的廉价主机选择。 长期以来，故事的结局已经到了。 具有高端 CPU，RAM 和持久存储的专用服务器仍然不便宜。 因此，如果您不赚钱，那将是故事的结局。 通过添加越来越多的专用服务器进行扩展是不可能的。 希望新的网格模型将使很多人继续写自己的故事。 他创建系统的学习曲线是最有趣的。 弄清楚如何进行设置，负载均衡，软件加载，测试，常规的螺母和螺栓开发工作。 这样一来，他就可以在需要的时候立即获得更多的 CPU。 他已经可以进行基础工作，因此能够快速添加该功能。 但是现在它运行良好。 计划中的扳手是数据库，它指出了 EC2 的致命缺陷，即数据库。 如果该部分工作得更好，则该计划看起来会更成功，但事实并非如此，这也很有趣。 -* 用于高吞吐量后台处理需求的 Node.js（例如：在语音中） +@Todd，感谢您的撰写，并进行了一些快速更正/澄清： -* 用于基础结构软件的 Golang +-“ Beau 是具有某些 sysadmin 技能的开发人员，而不是 Web 服务器管理员，因此在创建 FEEDblendr 时需要进行很多学习。” -需要明确的是，学习曲线主要是在处理 EC2 及其工作原理，而不是 FeedBlendr，它的核心是相对简单的。 -* 用于基础架构的 Python &数据科学 +-“重新启动之间不会保留任何数据”，这并非完全正确。 重新引导将保留数据，但是真正的“崩溃”或实例的终止将丢弃所有内容。 -* 用于 1 个内部应用程序的 Elixir +-“由于 EC2 没有像样的持久性存储系统，数据库仍托管在外部服务上”-此处的情况更多是我不想处理（或付费）设置某些东西来满足 他们没有持久性存储。 它是由其他人完成的，并且可以完成，这似乎对我所做的事情来说太过分了。 -* 用于测试自动化的 Ruby +-“ EC2 较差的负载平衡和持久性功能使开发和部署比原本要难得多”-很明显，EC2 没有**内在**固有的负载平衡，因此，这取决于您（开发人员/管理员） 自己提供某种方式。 有很多不同的方法可以使用，但是我选择动态 DNS 是因为我很熟悉它。 -* 适用于本机 iOS 应用程序的 Swift 和 Objective C +@Greg 在回答您的问题时-我想这里的重点是，即使 FeedBlendr **当前不是**的扩展子代，这也很重要。 正如 Todd 所说的，这是关于学习曲线以及达到**可扩展**的程度的尝试和磨难。 没有什么阻止我（除了预算！）立即启动另外 5 个实例并将它们添加到 DNS 中，然后我突然扩展了规模。 从那里，我可以终止一些实例并进行缩减。 这就是要达到我什至拥有该选项的地步，尤其是在 EC2 上是如何实现的。 -## 基础结构 +干杯， -* 完全托管在 AWS 上 +英俊 -* Ubuntu & CoreOS +漂亮的文章和鼓舞人心的故事。 很高兴读到这个小家伙正在构建具有扩展能力的东西。 -* 用于配置管理的&地形 +但是，如果我能提供一点反馈意见，则每台机器上独立缓存数据将不会随着应用程序的开发而扩展。 那会引起问题。 如何将 EC2 实例作为专用缓存运行？ 它不是持久性的，如果失败了，那么您将不得不重建现金。 但是假设它是一种简单的存储机制，则应该保持一致。 我认为他们有很多慷慨的储物津贴。 -* 过渡到基于 Docker 的部署 +无论哪种方式，几分钟之内能够打开另外 3 个实例的想法绝对是不错的，尤其是当您遇到“斜杠” /“ dugg” /之类的东西时。 如果实例可以检测到自己的高负载并自动启动新实例，那就特别好。 -* Jenkins 用于部署协调 +好故事- [http://www.callum-macdonald.com/“]( Callum。 -* Nginx &清漆 +> > >需要明确的是，学习曲线主要是在处理 EC2 及其工作方式，而不是 FeedBlendr，它的核心是相对简单的。 -* 快速交付应用程序 +我的帽子对你好！ 很少有人会保持自己的观点。 -* 摘要汇总日志 - -* 用于安全监视的 CloudPassage - -* HashiCorp 的保管箱，用于秘密存储&设置 - -## 数据存储 - -* 主要是 MySQL 托管在 RDS 上 - -* 托管在 Elasticache 上的 Memcached 用于缓存 - -* 自托管 Redis 服务器主要用于排队 - -* 有点 Kinesis，用于处理来自尖峰流量的订单 - -* Amazon Redshift 用于数据仓库 - -## 消息传递&排队 - -* Resque 和 Sidekiq 用于异步作业处理&消息传递 - -* 用于消息传递的 RabbitMQ - -* Kafka 用于流处理 - -## 分析&商业智能 - -* 扫雪机&用于网络/移动分析的 Adobe Analytics - -* AWS Elastic MapReduce - -* 将 FlyData 从 MySQL 转换为 ETL 数据到 Redshift - -* 托管 Spark Databricks - -* Looker 作为 BI 前端 - -* 用于报告的近实时数据可用性 - -## 监控 - -* Rollbar，哨兵&用于异常跟踪的 Crashlytics - -* 用于自定义应用程序指标的 DataDog &指标聚合 - -* SysDig 用于基础结构度量&监视 - -* 用于应用程序性能监视的 NewRelic - -* Site24x7，用于可用性监视 - -* PagerDuty，用于通话提醒 - -## 质量检查和测试自动化 - -* CircleCI 用于运行单元测试 - -* Jenkins + TestUnit + Selenium + SauceLabs 用于基于浏览器的自动化测试 - -* Jenkins + TestUnit +硒+ SauceLabs 用于大脑自动测试 - -* 用于 API 功能测试的 Jenkins + TestUnit - -* Jenkins + TestUnit + Appium + SauceLabs 用于原生 Android 自动化测试 - -* Jenkins + TestUnit + Appium + SauceLabs 用于本地 iOS 自动化测试 - -* Jenkins + TestUnit +硒+ SauceLabs +用于 BI 测试自动化的代理服务器 - -* SOASTA +正则表达式脚本，用于压力，浸泡，负载和性能测试。 - -## 工程工作流程 - -* 跨团队交流的时间 - -* Trello，用于任务跟踪 - -* 具有自定义插件的 Hubot 作为我们的聊天机器人 - -* Github 作为我们的代码存储库 - -* ReviewNinja 与 Github Status API 集成，用于代码审核 - -* 连续部署-通常每天进行多次部署 - -* 转向持续交付 - -* 用于功能开发的即时沙盒环境 - -* 目前，使用 Jenkins 的单按钮推送部署正在朝着持续交付的方向发展 - -* 运行 docker 容器的游民箱= >为新工程师提供的功能齐全的开发环境，第一天就开始 - -## 架构 - -* 事件驱动的架构 - -* 从单片架构转变为通过公共消息总线进行交互的“中型”服务 - -* CDN 边缘上基于 VCL 的边缘路由，就像其他任何应用程序一样部署。 - -* Web 和移动前端与 API 层进行对话 - -* API 层与服务进行对话，聚合数据并为客户端格式化数据 - -* 服务与数据存储和消息总线进行对话 - -* 计划任务作为一项主任务运行，并在 resque / sidekiq 中分解为较小的任务 - -* 技术组件包括用于客户服务（Brain），市场营销自动化平台（Voice），履行系统（Arm），订阅计费系统（Baby Boy）和我们的数据基础架构（Hippocampus）的内部工具。 - -## 小组 - -* 45 位顶尖的企业家和高技能工程师在加利福尼亚总部玛丽娜·德尔·雷伊工作 - -* 工程师与产品经理，设计师，UX 和利益相关者一起参与称为小分队的跨职能团队，以提供端到端功能。 - -* 团队根据域被垂直划分为前端，后端和质量检查& IT。 - -* 前端团队拥有 DSC.com &内部工具的 Web UI 和我们的 iOS & Android 应用。 - -* 后端团队拥有 DSC.com &内部工具，内部服务（计费和履行），数据平台&基础结构的 Web 后端。 - -* 质量检查团队拥有所有数字产品的测试和自动化基础架构。 - -* IT 团队拥有办公室& Warehouse IT。 - -* 工程师每年参加一次公司赞助的会议。 - -* 工程师可以购买所需数量的书籍/学习资源。 - -* 所有人的站立式办公桌。 目前可提供一张跑步机作为飞行员。 - -* 每周的工程团队午餐。 - -* Tech Belly 每隔一周举行一次活动，工程师们在午餐时间就技术主题进行演讲。 - -* 鼓励工程师尝试最前沿的技术，并通过提案请求（RFC）创建提案。 - -* 鼓励工程师在有意义的地方开源工具和库 - -* 每位工程师都会获得标准版的 15 英寸 Mac Book Pro，27 英寸 Mac Display 和 24 英寸显示器。 - -* 一台 3D 打印机可用于打印道具和更多 3D 打印机。 - -## 获得的经验教训 - -* 当您要扩展的组件由简单的小型服务组成时，扩展将变得更加容易。 - -* 文档&知识共享对于快速成长的团队至关重要。 - -* 培养良好的测试套件对于快速发展的系统至关重要。 - -* Redis 使用一种近似的 LRU 算法，因此如果您对缓存有明确的 LRU 要求，则不适合使用 - -* 网络性能至关重要，尤其是在移动设备上-每毫秒都会使我们损失收入 - -* 可用性&即使对于内部工具，用户体验也很重要：高效的工具=生产力更高的团队 - -[关于 HackerNews](https://news.ycombinator.com/item?id=12490369) - -您为什么决定自己托管 Redis？ 我假设您将在 ElastiCache 上运行 Redis（使用复制组以提高可用性）。 此外，为什么还要在 Elasticache 上托管 memcached？ - -似乎是一个非常标准的现代堆栈。 很高兴为他们工作！ 真正的问题是，他们向联合利华公司技术堡垒的过渡将是什么样子。 - -我想我的问题是，为什么您需要 45 名工程师才能完成基本上是一个带有订阅选项的小型目录？ - -文档首次出现很重要。 您使用什么基础设施和流程来保持其相关性？ - -为什么这家公司需要运行这么复杂的系统？ 并不是实时地有成千上万个请求的技术公司。 似乎是一种听起来过于酷炫的过度设计的解决方案。 也许他们在做一些我看不到的大而复杂的事情。 所以我很好奇。 \ No newline at end of file +谢谢（你的）信息。 顺便说一句，我已将其标记为@ [http://www.searchallinone.com/Other/Blogging_Locally_with_Outside-in_Founders_and_Only_the_Blog_Knows_Brooklyn__Brian_Lehrer_Live/](http://www.searchallinone.com/Other/Blogging_Locally_with_Outside-in_Founders_and_Only_the_Blog_Knows_Brooklyn__Brian_Lehrer_Live/) \ No newline at end of file diff --git a/docs/160.md b/docs/160.md index 0c11a7c..dddcdee 100644 --- a/docs/160.md +++ b/docs/160.md @@ -1,64 +1,61 @@ -# Pixable Architecture-每天对 2000 万张照片进行爬网，分析和排名 +# 将 Kim Kardashian 扩展到 1 亿个页面 -> 原文： [http://highscalability.com/blog/2012/2/21/pixable-architecture-crawling-analyzing-and-ranking-20-milli.html](http://highscalability.com/blog/2012/2/21/pixable-architecture-crawling-analyzing-and-ranking-20-milli.html) +> 原文： [http://highscalability.com/blog/2015/2/16/scaling-kim-kardashian-to-100-million-page-views.html](http://highscalability.com/blog/2015/2/16/scaling-kim-kardashian-to-100-million-page-views.html) -*这是 Pixable 的 CTO PHD 的 Alberto Lopez Toledo 和 Pixable 的工程副总裁 Julio Viera 的来宾帖子。* +![](img/54b0726e5abf8094b9c2fe6b6d888d4b.png) -![](img/c757a58e9a5343904e20bc929f9dc75a.png) [可混合](http://new.pixable.com/)汇总来自您不同社交网络的照片，并找到最佳照片，因此您永远不会错过重要时刻。 这意味着当前每天要处理超过 2000 万张新照片的元数据：对它们以及已经存储在我们数据库中的其他 5+十亿张图像进行爬网，分析，排名和排序。 弄清所有数据都面临挑战，但尤其要强调两个挑战： +[PAPER](http://www.papermag.com/) 小组估计他们的 [文章](http://www.papermag.com/2014/11/kim_kardashian.php) （NSFW）包含 非常裸露的 [Kim Kardashian](http://en.wikipedia.org/wiki/Kim_Kardashian) 的图片将很快获得超过 1 亿的页面浏览量。 突发性病毒驱动流量的非常定义。 -1. 如何每天以最有效的方式从 Facebook，Twitter，Instagram 和其他服务访问数百万张照片。 -2. 如何处理，组织，索引和存储与那些照片相关的所有元数据。 +与 2013 年相比， [估计为](http://www.cnet.com/news/google-search-scratches-its-brain-500-million-times-a-day/) Google 每天处理超过 5 亿次搜索。 因此，裸露的金·卡戴珊（Kim Kardashian）值得拥有 Google 的五分之一。 奇怪的是，我可以相信。 -当然，Pixable 的基础架构正在不断变化，但是去年我们学到了一些东西。 因此，我们已经能够构建可扩展的基础架构，以利用当今的工具，语言和云服务，所有这些都在 Amazon Web Services 上运行，其中我们有 80 多个服务器在运行。 本文档简要介绍了这些课程。 +他们如何处理这个交通金矿？ 保罗·福特（Paul Ford）在 [中完整讲述了幕后的故事，《 PAPER Magazine》的网络工程师如何为 Kim Kardashian](https://medium.com/message/how-paper-magazines-web-engineers-scaled-kim-kardashians-back-end-sfw-6367f8d37688) （SFW）扩展后端 。 （顺便说一句，在这个故事中，只有一个双关语是故意制作的，其他都是偶然的）。 -## 后端架构-一切都会发生 +我们可以从经验中学到什么？ 我知道你在想什么 这只是一个静态页面，带有一些静态图片。 这不是一个复杂的问题，例如 [搜索](http://highscalability.com/display/Search?moduleId=4876569&searchQuery=google) 或 [社交网络](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) 。 像样的 CDN 不足以处理这个问题吗？ 您是正确的，但这还不是全部内容： -### 基础架构-喜欢 Amazon EC2 +1. **突发流量**。 有一个非正式的规则，即网站的设计应能处理比一般流量大一个数量级的突发事件。 PAPER 通常在给定的月份中可以处理数十万人，因此在压缩的时间内增加两个数量级的流量无疑是值得担心的事情。 -我们使用 CentOS Linux，使用从 t1.micro 到 m2.2xlarge 的各种实例在 Amazon EC2 上维护所有服务器。 设置服务器后，我们将创建自己的内部 AMI（每种类型的服务器一个）。 我们总是准备好在负载增加时立即部署它们，从而始终保持最低性能标准。 +2. **提前计划** 。 PAPER 并不信任命运，而是知道他们有一个大故事，因此他们联系了他们的 Web 基础架构团队，并给了他们五天的准备时间，以确保该网站能够处理即将来临的观众。 -为了补偿这些负载波动，我们开发了自己的自动伸缩技术，该技术可以根据一天中特定时间的当前和历史负载来预测每种类型的服务器数量。 然后，我们启动或终止实例只是为了保持正确的配置水平。 这样，我们就可以通过在不需要服务器时缩减服务器规模来节省资金。 在亚马逊中自动缩放并非易事，因为要考虑许多变量。 +3. **卡戴珊前堆栈**。 PAPER 在单个实例上运行在单个 AWS 区域（大小未知）中，MySQL 可能是数据库， [可移动类型](https://movabletype.org/) 是 CMS， [龙卷风](http://www.tornadoweb.org/en/stable/) 是 Web 服务器， [Varnish](https://www.varnish-cache.org/) 是缓存。 该设置每月可为 50 万至 100 万的唯一身份访问者提供服务。 -例如：由于 Amazon 会收取整个小时的费用，因此终止仅运行了半个小时的实例是没有意义的。 此外，亚马逊可能需要 20 多分钟才能启动即时实例。 因此，对于流量的突然激增，我们对按需实例（启动速度更快）进行了一些巧妙的启动调度，然后在接下来的一个小时内将它们替换为现场实例。 这是纯粹的运营研究的结果，其目的是为了以适当的金额获得最佳性能。 可以把它想像成电影《 Moneyball》，但它带有虚拟服务器而不是棒球运动员。 +4. **后卡戴珊式堆栈**。 Kardashian 之前的站点已转换为使用预热的负载平衡器，四台前端计算机，共享文件系统和 Amazon 的 CloudFront CDN 的站点。 这是用于处理照片释放的 PAPER 纸叠的 [漂亮图](https://d262ilb51hltx0.cloudfront.net/max/2000/1*NRRjxiTzjIFBK4UlJ3m2ww.jpeg) 。 添加了四台 m3.large 前端计算机，用于托管可移动类型，龙卷风和光油。 然后，在横向扩展的网络附加存储文件系统 [GlusterFS](http://glusterfs) 上构建分布式文件系统层。 将所有媒体复制到运行在 m3.xlarge 上的 Gluster Filesystem Server。 可以根据需要添加更多的存储节点，这就是 Gluster 带来的好处。 前端计算机将 Gluster 用作其虚拟磁盘。 ELB 用于平衡前端计算机之间的流量。 -我们的 Web 服务器当前运行 Apache + PHP 5.3（最近我们一直在微调一些 Web 服务器以运行 nginx + php-fpm，它将很快成为我们的标准配置）。 这些服务器平均分布在 Amazon Elastic Load Balancer 后面的不同可用性区域中，因此我们可以吸收 Amazon 的停机时间和价格波动。 我们的静态内容存储在 Amazon Cloud Front 上，并且我们将 Amazon Route 53 用于 DNS 服务。 是的，确实……我们爱亚马逊。 +5. **测试** 。 CDN 将处理静态内容的负载，Varnish 将缓存网站的动态内容，ELB 将分发流量，但网站仍必须处理流量。 [带机枪的蜜蜂](https://github.com/newsapps/beeswithmachineguns) 以每秒 2,000 个请求的速度测试系统。 目标是每秒测试 10,000 个请求，但显然无法使用该工具来达到该速度。 -### 工作队列-用于抓取照片并对其进行排名，发送通知等的工作 +6. **应急响应计划** 。 据估计，该系统在第一个小时内可接待 3000 万访客，但已计划如何根据需要启动更多的前端服务器。 该计划没有使用 Chef，Puppet 甚至 Docker，显然所需的命令存储在 Google Docs 文档中。 -实际上，Pixable 的所有处理都是通过异步作业完成的（例如，从 Facebook 抓取来自不同用户的新照片，发送推送通知，计算朋友排名等）。 我们有数十个工作服务器，它们从不同服务的照片中抓取元数据并处理该数据。 这是一个连续的，全天候的过程。 +7. **Instagram 偷走了流量！** 内容创建者通常会输给内容聚合者。 到 PAPER 网站的访问量远远低于预期。 这就说明了一切。 她的 2500 万关注者去了那里，而不是去 PAPER 的网站。” 明智的选择：推出计划的**部分应包括确保您从工作**中获得最大收益的策略。 -不出所料，我们有不同类型的工作：一些优先级高的工作，例如实时用户呼叫，消息收发以及为当前活动用户抓取照片。 优先级较低的作业包括脱机爬网和长时间的数据密集型延迟任务。 尽管我们使用功能强大的 [beantalkd](http://kr.github.com/beanstalkd/) 作为我们的作业队列服务器，但我们在其之上开发了自己的管理框架。 我们将其称为自动驾驶仪，它会自动管理优先级的处理，例如 通过将作业服务器时间用于高优先级作业，并在满足平台范围的某些条件时暂停低优先级作业。 +8. **纸张通过完全正面** 进行报复。 PAPER 通过发布 Kardashian 的全额裸照从 Instagram 收回了主动权。 Instagram 不允许这类图片，因此这次访问量流向了 PAPER。 几天来，访问量激增，有 3000 万独立访问者。 该站点可以毫无问题地处理所有流量。 -我们开发了非常复杂的规则来处理这些优先级，同时考虑了影响系统性能和影响用户感知速度的指标。 有些是显而易见的，例如作业的平均等待时间或从属服务器的滞后时间（ssshhh，我们从不滞后于从属服务器:-)），而更复杂的指标则是分布式分布式 PHP 同步互斥锁的状态。 环境。 我们会尽力在效率和绩效之间做出公平的权衡。 +9. **返回到卡戴珊前堆栈**。 几周后，新堆栈被拆除，旧堆栈又重新运行了该站点。 不完全是自动可伸缩性的先驱者，但是灵活性仍然很高。 -### 抓取引擎-在 Facebook，Twitter 等 24/7 上抓取新照片 +10. **您的评论系统可以处理负载吗？** 这种文章将获得很多评论。 不要忘记评论系统的负担。 如果失败，即使网站的其余部分运行正常，您也会看起来很糟糕。 PAPER 使用 Facebook 的评论插件，该插件似乎可以毫无问题地处理 5,100 多个评论。 -我们一直在不断改进抓取技术，这是一种复杂的并行算法，它使用内部开发的互斥锁库来为特定用户同步所有进程。 自推出以来，该算法已帮助我们将 Facebook 的抓取速度提高了至少 5 倍。 现在，我们每天可以轻松获取超过 2000 万张新照片。 考虑到事实上，对 [Facebook API](http://developers.facebook.com/) 的任何大数据查询都可能需要几秒钟的时间，因此这是非常出色的。 我们将在一个辅助文档中更深入地了解我们的抓取引擎。 +11. **估算？** 我感兴趣的故事之一是 PAPER 如何将页面浏览量预测为 1 亿？ 这个估计推动了所有变化。 如果太大，他们会浪费很多钱。 如果它太小，它们将以不止一种方式被压碎。 这种预测的过程是什么？ -### 数据存储-索引照片和元数据 +本文非常独特，我认为我从未读过类似的文章。 它将许多不同的主题和受众聚集到一个地方，并试图将它们联系在一起……同时保持娱乐性。 如果您是 DevOp，那么这篇文章对您来说就没什么用了。 但是，它在与普通观众打交道方面做得很好，向他们解释了运行网站所需的资源。 或者作为匿名恩人写给我： -自然，我们的数据存储每天都在增长。 目前，我们使用两组服务器将 90％的数据存储在 MySQL 中（其顶部是 memcached 层）。 第一组是 2 主 2 从配置，该配置存储几乎每个系统访问的更规范化的数据，例如用户配置文件信息，全局类别设置和其他系统参数。 +> 我之所以喜欢它，是因为几乎所有人（包括需要理解有关使用云资源进行扩展的信息的许多非技术人员）都可以阅读它，以了解构建基于 Java 的动机，活动和收益。 云平台，并将其用于可能破坏非云 IT 基础架构的挑战。 一个很好的故事，讲述得足够详细，传达了有关缩放的有用信息。 -第二个服务器组包含手动分片服务器，我们在其中存储与用户照片有关的数据，例如照片 URL。 此元数据已高度反规范化，以至于我们实际上仅以 MySQL 表（NoSQL-in-MySQL）的形式将存储作为 NoSQL 解决方案（如 MongoDB）运行。 因此，您可以猜测其他 10％的数据存储在什么地方，对吗？ 是的，在 MongoDB 中！ 我们将部分存储移至 MongoDB，主要是因为它提供了简单灵活的分片和复制解决方案。 +毫无疑问，某些决定值得商,，但总是如此。 保罗·福特（Paul Ford）对这种攻势做出了强烈回应： -### 记录，分析和分析 +> 书呆子喜欢做的事情之一就是看着别人的筹码，然后说：“纸牌屋！” 实际上，我完全希望人们链接到本文，并写出诸如“听起来还不错，但他们本应在所有串流中都使用带有 Zastring 扩展名的 Jizzawatt 和 Graunt.ns 的东西。” -我们开发了高度灵活的日志记录和性能分析框架，该框架使我们能够以高粒度记录事件-只需一行代码。 每个日志事件均按一组我们稍后查询的标签进行分类（例如，用户 X 的事件或模块 Y 中的调用）。 最重要的是，我们可以动态地分析任何日志记录事件之间的时间，从而使我们能够构建整个系统的实时性能分析。 日志记录和概要分析系统在存储系统上的负担非常重（每秒数千次更新），因此我们开发了两级 MySQL 表（基于内存的快速缓冲区，用作实际数据的泄漏存储区）的混合体 存储），再结合一些分区的 MySQL 表，这些表稍后会异步填充。 这种架构使我们每秒可以处理 15,000 多个日志条目。 我们还拥有自己的事件跟踪系统，其中记录了从登录到共享到单个点击的每个用户操作，以便以后可以使用复杂的查询进行分析。 +## 相关文章 -我们还严重依赖于出色的 [Mixpanel](http://www.mixpanel.com/) 服务，这是一个基于事件的跟踪系统，我们在其中执行大部分高级分析和报告。 +* [在 Reddit 上](http://www.reddit.com/r/programming/comments/2w3mis/scaling_kim_kardashian_to_100_million_page_views/) -## 前端-简单的可视化设备 +* [策略：通过快速扩展您的网站来缓解流量激增的三种技术](http://highscalability.com/blog/2014/3/19/strategy-three-techniques-to-survive-traffic-surges-by-quick.html) -Pixable 可在多个（前端）设备中运行，最受欢迎的设备是 iPhone 和 iPad。 我们也有加载简单索引页的 Web 和移动 Web 站点，其他所有操作都通过广泛使用 jQuery 和 Ajax 调用在客户端中执行。 我们所有的 Web 前端都将很快运行一个可自动适应移动或桌面屏幕的代码库（尝试一下！ [http://new.pixable.com](http://new.pixable.com/) ）。 这样，我们可以在我们的主站点，Android 设备或 Chrome 浏览器扩展程序上运行相同的代码！ 实际上，我们的 Android 应用是原生应用和我们的移动网络前端的结合。 Android 应用程序使用最少的控件来渲染框架，并仅在其中显示移动 Web 视图。 +* [超级碗广告商准备好了流量吗？ 不，它熄灭了](http://highscalability.com/blog/2013/2/6/super-bowl-advertisers-ready-for-the-traffic-nopeits-lights.html) 。 -听起来有些刺耳，但是我们所有的前端都是“哑巴”。 所有繁重的工作都在后端执行，所有事情都通过我们自己的私有 API 连接。 这使我们能够快速进行开发和部署，而不必更改已安装的用户群。 敏捷，宝贝！ +* [关于构建有效的高流量 Web 软件的 22 条建议](http://highscalability.com/blog/2013/12/16/22-recommendations-for-building-effective-high-traffic-web-s.html) -## API-连接我们的前端和后端 +* [StubHub 架构：全球最大的票务市场背后的惊人复杂性](http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html) -API 是使一切保持协同工作的粘合剂。 使用 [Tonic PHP](http://peej.github.com/tonic/) ，我们开发了自己的私有 RESTful API，该 API 公开了我们的后端功能。 另外，我们扩展了 [Tonic](http://peej.github.com/tonic/) ，使其支持内置版本控制。 这样一来，在开发新功能或更改 API 中的响应格式时，我们很容易保持向后兼容性。 我们只配置哪个设备版本支持哪些版本的 API 调用。 无论版本多旧，我们都有不留设备的政策！ +* [使用内存网格](http://highscalability.com/handle-1-billion-events-day-using-memory-grid) 每天处理 10 亿个事件 -但是 API 并没有做任何实际的工作。 它仅依赖于来自前端的信息，并将其传递给实际的 Pixable 心脏：后端。 +* [技术星期二：我们的技术堆栈](http://imgur.com/blog/2013/06/04/tech-tuesday-our-technology-stack/) -每天排名 2000 万张照片？ 真的很棒 - -值得读。 谢谢你的好文章。 \ No newline at end of file +* [在 ELB 前面放上清漆的两个问题](http://www.reddit.com/r/devops/comments/2t8ib2/how_paper_magazines_web_engineers_scaled_their/cnx7n13) \ No newline at end of file diff --git a/docs/161.md b/docs/161.md index 2136d75..5b2bc36 100644 --- a/docs/161.md +++ b/docs/161.md @@ -1,26 +1,62 @@ -# Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL +# HappyPancake：建立简单可扩展基金会的回顾 -> 原文： [http://highscalability.com/blog/2012/2/20/berkeley-db-architecture-nosql-before-nosql-was-cool.html](http://highscalability.com/blog/2012/2/20/berkeley-db-architecture-nosql-before-nosql-was-cool.html) +> 原文： [http://highscalability.com/blog/2015/2/23/happypancake-a-retrospective-on-building-a-simple-and-scalab.html](http://highscalability.com/blog/2015/2/23/happypancake-a-retrospective-on-building-a-simple-and-scalab.html) -![](img/c5609977746e08c737e71118996cd87c.png) +![](img/6501d09f8bcc4bdec007a12721e5b098.png) -在文件系统和简单的库包之后，例如 [dbm](http://en.wikipedia.org/wiki/Dbm) ， [Berkeley DB](http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html) 是最初被应用程序广泛用作其核心数据库引擎的豪华嵌入式数据库。 NoSQL 比 NoSQL 还酷。 使复杂的应用程序唱歌的隐藏秘密。 如果您希望免除基于服务器的系统的所有网络开销，那么它仍然是一个不错的选择。 +*这是 [Rinat Abdullin](http://abdullin.com/about-me/) 的来宾转发，他曾从事 *[HappyPancake](http://www.happypancake.com/) 和*的工作，这是瑞典最大的免费约会网站。 最初是用 ASP.NET 和 MS SQL 数据库服务器编写的，但最终变得过于复杂和扩展成本很高。 这是近两年来有关该项目发展的一系列引人入胜的文章中的最后一篇。 有关完整列表，请参见本文结尾。* -[《开源应用程序的体系结构](http://astore.amazon.com/possiboutpos-20/detail/1257638017)》一书中对 Berkeley DB 背后的体系结构进行了大量撰写。 如果您想了解有关数据库如何工作的更多信息，或者如果您正在考虑如何构建自己的数据库，那么它的详细信息，说明和课程将非常丰富。 这是本书中的 [Berkeley DB](http://www.aosabook.org/en/bdb.html) 章节。 它涵盖了以下主题：建筑概述； 访问方法：Btree，Hash，Reno，Queue； 库接口层； 缓冲区管理器：Mpool； 预写日志记录； 锁管理器：锁； 日志管理器：日志； 事务管理器：Txn。 +我们在 HappyPancake 上的项目已于本周完成。 我们为瑞典最大的免费约会网站的下一个版本**（在挪威和芬兰开展业务）提供了一个简单且可扩展的基础。** -## 相关文章 +## 旅程 + +以下是该旅程的简短地图。 它列出了我们为该项目评估的技术和方法。 黄色区域突出显示了进入最终设计的项目。 + +![](img/bea501f4d8228089cf0819c38337c2f7.png) + +## 项目交付 + +**项目可交付成果**包括： + +* 具有主要功能的可部署全栈应用程序。 +* 在软件设计（后端和前端）和一组声明性用例（充当活动文档，系统概述和行为测试套件）中捕获的领域模型。 +* 用于开发和持续集成的已配置环境（docker 容器）。 +* 进一步发展和扩展系统的策略。 +* 用于将现有生产部署迁移到新版本软件的代码。 + +最终的高层**体系结构很容易推断和扩展**。 它就是这样设计的。 + +![](img/89c7299bcde61247cdce911184e02b93.png) + +从逻辑上讲，整个解决方案由后端模块（由 golang 包表示）和 Facebook Flux 体系结构的元素（通过命名约定在命名空间中组合在一起）组成。 -* [伯克利 DB：Margo Seltzer 的回顾性](http://sites.computer.org/debull/a07sept/seltzer.pdf) -* [在维基百科](http://en.wikipedia.org/wiki/Berkeley_DB)上 -* [LevelDB-MapReduce 和 BigTable 作者的快速轻量级键/值数据库。](http://highscalability.com/blog/2011/8/10/leveldb-fast-and-lightweight-keyvalue-database-from-the-auth.html) +随着项目规模和复杂性的增长，这种结构有助于维护项目。 -当然，如果您的方案是非分片的单个 Web 服务器，那么 BerkeleyDB 的速度将惊人地快。 我在 BookMooch.com 上使用 BerkeleyDB 已有 6 年了，对于单个网页来说，现实世界中每秒 200 万次查询的查询速度是很典型的。 这些不是模拟的速度：在锁定，窃听等之后，它是真实的速度。这种速度让我可以使用 BerkeleyDB 代替内存中的数组，然后获得自动持久性（就像 Perl 一样）。 +![](img/9809c2865415feb94c07ab2c1dc903b1.png) --约翰 +此设计还有助于扩展部署以处理更高的负载。 -首先，让我说“ NoSQL 比 NoSQL 还酷”的名字是 MarkLogic 很久以来提出的（[，我有衬衫来证明它](http://contentmangler.wordpress.com/2012/02/25/marklogic-nosql-before-nosql-was-cool/?preview=true&preview_id=35&preview_nonce=9757b1bfd1)）。 话虽如此，在速度和可伸缩性方面，MarkLogic 是事实上的 XML 数据库。 MarkLogic 不需要水平分片，因为它是为群集和协调数千个节点和 PB 级数据而构建的。 MarkLogic 在一些内容/数据非常复杂的大型公司中安装了设备，并且可以对任何节点或文档执行亚秒级的查询。 我认为伯克利是一个很棒的工具，但充其量只是新颖，我会对企业中谁在使用它以及在什么规模上使用它感兴趣。 成为与 MarkLogic 紧密合作的人。 我知道它可以扩展并解决很多信息问题，无论您拥有 100 GB 还是 100 TB 的内容。 +我们可以通过以下方式**扩展后端**： + +* 将单个模块移至更大的服务器； +* 启动单个模块的多个实例； +* 将单个模块的存储切换到集群解决方案，将其移动到更大的服务器，甚至推送到云。 + +我们可以通过简单地在负载均衡器后面启动新实例来扩展**前端**。 + +![](img/8f6a49f157b87680cb4e15f0a572d639.png) + +解决方案结构还提供了一种在开发人员之间分配工作的自然方法。 给定已建立的发布语言（API 和事件的合同），我们还可以引入更多开发人员，将他们分配给在单个后端模块或前端命名空间上工作。 + +## 得到教训 + +* 选择正确的技术可以减少开发工作。 +* 在我的下一个项目中，我将尝试着重于分而治之的方法-先隔离一小部分然后进行改进，以限制进行中的工作量。 +* 尽早建立所有利益相关者参与的反馈循环至关重要。 这可以建立信任并有助于避免意外。 + +## 相关文章 --加里·维达尔 +* [关于黑客新闻](https://news.ycombinator.com/item?id=9101133) +* 完整的 HappyPancake 文章系列。 仅标题即可指示项目之字形随时间变化的方式。 [简介](http://abdullin.com/happypancake/intro/)； [新团队](http://abdullin.com/happypancake/2013-12-17/)； [语言是实现细节](http://abdullin.com/happypancake/2013-12-23/)； [与 Golang 一起前进](http://abdullin.com/happypancake/2014-01-18/)； [从 FoundationDB](http://abdullin.com/happypancake/2014-02-02/) 开始； [逐步发展堆栈并学习 Nanomsg](http://abdullin.com/happypancake/2014-02-08/) ； [设计用于吞吐量和低延迟](http://abdullin.com/happypancake/2014-02-17/)； [容器，虚拟化和集群](http://abdullin.com/happypancake/2014-02-24/)； [基准测试和调整堆栈](http://abdullin.com/happypancake/2014-03-19/)； [计划变更](http://abdullin.com/happypancake/2014-04-07/)； [返回基础](http://abdullin.com/happypancake/2014-04-14/)； [消息传递-社交网站的心脏](http://abdullin.com/happypancake/2014-04-21/)； [事件驱动的一周](http://abdullin.com/happypancake/2014-04-28/)； [反应性原型](http://abdullin.com/happypancake/2014-05-05/)； [战术 DDD](http://abdullin.com/happypancake/2014-05-12/) ； [Emergend Design 面对现实](http://abdullin.com/happypancake/2014-05-24/)； [最小可行产品](http://abdullin.com/happypancake/2014-06-01/)； [Almost Demo](http://abdullin.com/happypancake/2014-06-09/) ; [我们的第一个演示](http://abdullin.com/happypancake/2014-06-13/)； [Scala，模块化设计和 RabbitMQ](http://abdullin.com/happypancake/2014-06-30/) ，[分配工作](http://abdullin.com/happypancake/2014-07-06/)； [更智慧的发展](http://abdullin.com/happypancake/2014-07-21/)； [提供功能和测试](http://abdullin.com/happypancake/2014-07-29/)； [数据，用例和新模块](http://abdullin.com/happypancake/2014-08-02/)； [从假期回来](http://abdullin.com/happypancake/2014-08-16/)； [原生性能](http://abdullin.com/happypancake/2014-08-25/)； [功能，用例，Rendr](http://abdullin.com/happypancake/2014-09-07/) ； [Node.js 入门，Lazojs](http://abdullin.com/happypancake/2014-09-15/) ； [Web 开发的好部分](http://abdullin.com/happypancake/2014-09-23/)； [响应式用户体验](http://abdullin.com/happypancake/2014-09-29/)； [供稿，聊天，在线列表和 CSS](http://abdullin.com/happypancake/2014-10-07/) ； [发送给 ReactJS 和 Facebook Flux](http://abdullin.com/happypancake/2014-10-27/) ； [项目完成](http://abdullin.com/happypancake/2014-11-06/)。 -请查看 Bangdb。 当前，嵌入式版本已在 www.iqlect.com 上发布。 BerkleyDB 和 LevelDB 有一个有趣的性能比较文档。 请在可能的情况下退房。 -谢谢 \ No newline at end of file +喜欢可视化。 您在其中创建了什么软件？ \ No newline at end of file diff --git a/docs/162.md b/docs/162.md index a63d449..b09f480 100644 --- a/docs/162.md +++ b/docs/162.md @@ -1,336 +1,251 @@ -# Tumblr Architecture-150 亿页面浏览量一个月，比 Twitter 更难扩展 - -> 原文： [http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) - -![](img/3f4661baa53cbc9eae481b3c2ce15bb3.png) - -Tumblr 每月拥有超过 150 亿的页面浏览量，已成为一个非常流行的博客平台。 用户可能会喜欢 Tumblr 的简单性，美观性，对用户体验的高度关注或友好而参与的社区，但他们喜欢。 - -每月以 30％以上的速度增长并非没有挑战。 其中一些可靠性问题。 它有助于认识到 Tumblr 的运行规模惊人地惊人：每天有 5 亿次页面浏览，每秒约有 4 万个请求的峰值速率，每天约有 3TB 的新数据存储，所有这些都在 1000 多个服务器上运行。 - -成功创业公司的常见模式之一是从创业公司到疯狂成功创业的危险鸿沟。 寻找人员，不断发展的基础架构，为旧的基础架构提供服务，同时处理每月逐月的巨大流量增长（全都只有四名工程师），这意味着您必须对工作内容做出艰难的选择。 这就是 Tumblr 的情况。 现在，拥有 20 名工程师，他们有足够的精力来解决问题并开发一些非常有趣的解决方案。 - -Tumblr 开始时是一种非常典型的大型 LAMP 应用程序。 他们现在的发展方向是朝着围绕 Scala，HBase，Redis，Kafka，Finagle 构建的分布式服务模型以及为仪表板提供动力的有趣的基于单元的体系结构。 现在，我们正在努力解决其 PHP 应用程序中的短期问题，将其撤出并使用服务来正确完成。 - -Tumblr 的主题是大规模过渡。 从 LAMP 堆栈过渡到有点出血的边缘堆栈。 从小型启动团队过渡到配备齐全的现成开发团队，以开发新功能和基础架构。 为了帮助我们理解 Tumblr 的生活方式，Tumblr 的分布式系统工程师，资深的初学者 [Blake Matheny](http://www.linkedin.com/in/bmatheny) 。 布雷克（Blake）对 Tumblr 之家的评价如下： - -网站： [http://www.tumblr.com/](http://www.tumblr.com/) - -## 统计信息 - -* 每天有 5 亿页面浏览量 -* 每月浏览量超过 15B -* 〜20 名工程师 -* 每秒约 40k 请求的峰值速率 -* 每天有 1 TB 以上的数据进入 Hadoop 集群 -* 每天有许多 TB 进入 MySQL / HBase / Redis / Memcache -* 以每月 30％的速度增长 -* 正在生产的〜1000 个硬件节点 -* 每个工程师每月有数十亿的页面访问 -* 帖子每天大约 50GB。 关注者列表每天更新约 2.7TB。 -* 仪表板每秒运行一百万次写入，每秒 50K 读取，并且还在不断增长。 - -## 软件 - -* OS X 用于开发，Linux（CentOS，科学版）投入生产 -* Apache -* PHP，Scala，Ruby -* Redis，HBase，MySQL -* Varnish，HA 代理，nginx， -* Memcache，Gearman，Kafka， Kestrel，Finagle -* 节俭，HTTP -* [Func](http://func.et.redhat.com/) -安全，可编写脚本的远程控制框架和 API -* Git，Capistrano，木偶，詹金斯 - -## 硬件 - -* 500 台 Web 服务器 -* 200 个数据库服务器（其中许多是我们因故障而从备用池中抽出的一部分） - * 47 个池 - * 30 个碎片 -* 30 个内存缓存服务器 -* 22 个 Redis 服务器 -* 15 个清漆服务器 -* 25 个代理节点 -* 8 nginx -* 14 个作业队列服务器（红 est + Gearman） - -## 架构 - -* Tumblr 具有与其他社交网络不同的使用模式。 - * 每天有 50+百万个帖子，平均帖子数达数百人。 拥有数百万关注者的不仅仅是一两个用户。 Tumblr 用户的图表有数百个关注者。 这与任何其他社交网络都不同，这就是使 Tumblr 如此难以扩展的原因。 - * 在用户花费的时间方面排名第二。 内容很吸引人。 它是图片和视频。 帖子没有字节大小。 它们并不都是长格式，但是它们有能力。 人们会写一些值得一读的深入内容，因此人们会呆上几个小时。 - * 用户与其他用户建立连接，因此他们将数百页返回到仪表板以读取内容。 其他社交网络只是您采样的流。 - * 的含义是，鉴于用户数量，用户的平均覆盖范围以及用户的高发布活动，需要处理大量更新。 -* Tumblr 在一个托管站点中运行。 设计在将来会考虑地理分布。 -* 以 Tumblr 为平台的两个组件：公共 [Tumblelogs](http://www.tumblr.com/tagged/tumblelogs) 和 [信息显示板](http://www.tumblr.com/tagged/tumblr+dashboard) - * 公众 Tumblelog 是公众根据博客处理的内容。 易于缓存，因为它不是那么动态。 - * 仪表板类似于 Twitter 时间线。 用户从他们关注的所有用户那里获取实时更新。 - * 与博客的缩放特性非常不同。 缓存并不是那么有用，因为每个请求都是不同的，尤其是对于活跃的关注者而言。 - * 需要实时且一致。 不应显示过时的数据。 而且有很多数据要处理。 帖子每天只有大约 50GB。 关注者列表每天更新 2.7TB。 媒体全部存储在 S3 中。 - * 大多数用户都将 Tumblr 用作消费内容的工具。 每天的 500+百万页面浏览量中，有 70％用于仪表板。 - * 仪表板的可用性非常好。 Tumblelog 表现不佳，因为它们具有难以迁移的旧式基础架构。 与一个小团队一起，他们必须选择并解决扩展问题。 - -### 旧 Tumblr - -* 当公司开始使用 Rackspace 时，它给每个自定义域博客一个 A 记录。 当他们超过 Rackspace 时，太多的用户无法迁移。 这是 2007 年。他们在 Rackspace 上仍具有自定义域。 他们使用 HAProxy 和 Varnish 将 Rackspace 路由回到其 colo 空间。 这样的遗留问题很多。 -* 传统的 LAMP 进展。 - * 历史上是用 PHP 开发的。 几乎每个工程师都使用 PHP 进行编程。 - * 从 Web 服务器，数据库服务器和 PHP 应用程序开始，然后开始发展。 - * 要扩展规模，他们开始使用内存缓存，然后放入前端缓存，然后在缓存之前放入 HAProxy，然后使用 MySQL 分片。 MySQL 分片非常有用。 - * 充分利用单个服务器的方法。 在过去的一年中，他们在 C 语言中开发了一些后端服务： [ID 生成器](http://engineering.tumblr.com/post/10996371189/blake-matheny-id-generation-at-scale) 和 [楼梯](http://engineering.tumblr.com/post/7819252942/staircar-redis-powered-notifications) ，使用 Redis 为仪表板通知供电 -* 仪表板使用分散收集方法。 当用户访问其仪表板时，将显示事件。 将拉出并显示您关注的用户的事件。 这将再扩展 6 个月。 由于数据是按时间排序的分片方案，因此效果不佳。 - -### 新 Tumblr - -* 由于招聘和开发速度原因，已更改为以 JVM 为中心的方法。 -* 目标是将所有内容从 PHP 应用程序移到服务中，并使该应用程序成为确实需要身份验证，表示等的服务的薄层。 -* Scala 和 Finagle 选择 - * 内部，他们有很多具有 Ruby 和 PHP 经验的人，因此 Scala 颇具吸引力。 - * Finagle 是选择 Scala 的重要因素。 它是 Twitter 的图书馆。 它处理大多数分布式问题，例如分布式跟踪，服务发现和服务注册。 您不必实现所有这些东西。 它只是免费提供的。 - * 在 JVM 上，Finagle 提供了所需的所有原语（Thrift，ZooKeeper 等）。 - * Foursquare 和 Twitter 正在使用 Finagle。 Meetup 也正在使用 Scala。 - * 类似于 Thrift 应用程序界面。 它具有非常好的性能。 - * 喜欢 Netty，但是想要退出 Java，因此 Scala 是一个不错的选择。 - * 之所以选择 Finagle，是因为它很酷，并且认识一些人，它不需要很多网络代码就可以工作，并且可以完成分布式系统中所需的所有工作。 - * 未选择 Node.js，因为使用 JVM 基础更容易扩展团队。 Node.js 开发不够完善，无法提供标准和最佳实践以及大量经过测试的代码。 使用 Scala，您可以使用所有 Java 代码。 关于如何以可扩展的方式使用它的知识并不多，它们的目标是 5 毫秒的响应时间，4 个 9s HA，每秒 40K 个请求，还有一些每秒 40 万个请求。 他们可以利用 Java 生态系统中的很多功能。 -* 内部服务正在从基于 C / libevent 的状态转变为基于 Scala / Finagle 的状态。 -* 正在使用更新的非关系数据存储，例如 HBase 和 Redis，但它们的大部分数据当前存储在高度分区的 MySQL 体系结构中。 不使用 HBase 替换 MySQL。 -* HBase 支持数十亿个 URL 以及所有历史数据和分析的 URL 缩写。 一直坚如磐石。 HBase 用于具有较高写入要求的情况，例如替换仪表板每秒写入一百万次。 未部署 HBase 而不是部署 MySQL，因为他们无法与他们所拥有的人押宝 HBase 上的业务，因此他们开始将其用于规模较小，不太关键的项目中以获取经验。 -* MySQL 和时间序列数据分片的问题一直是一个热点。 由于从属服务器上的插入并发性，还遇到了读取复制滞后的问题。 -* 创建了一个公共服务框架。 - * 花了很多时间来预先解决如何管理分布式系统的操作问题。 - * 建造了一种 Rails 脚手架，但用于服务。 模板用于在内部引导服务。 - * 从操作角度来看，所有服务看起来都是相同的。 检查统计信息，监视，启动和停止所有服务的工作方式相同。 - * 工具是围绕 [SBT](https://github.com/harrah/xsbt/wiki) （一种 Scala 生成工具）的构建过程使用的，它使用插件和帮助程序来处理一些常见的活动，例如在其中标记内容 git，发布到存储库等。大多数开发人员不必进入构建系统的胆量。 -* 前端层使用 HAProxy。 Varnish 可能会受到公共博客的欢迎。 40 台机器。 -* 500 个运行 Apache 的 Web 服务器及其 PHP 应用程序。 -* 200 个数据库服务器。 使用许多数据库服务器是出于高可用性的原因。 使用了商品硬件，MTBF 令人惊讶地低。 丢失的硬件比预期的要多得多，因此在发生故障的情况下有许多备用件。 -* 6 个支持 PHP 应用程序的后端服务。 一个团队致力于开发后端服务。 每 2-3 周推出一项新服务。 包括仪表板通知，仪表板二级索引，URL 缩短器和用于处理透明分片的内存缓存代理。 -* 在 [MySQL 分片](http://assets.en.oreilly.com/1/event/74/Massively%20Sharded%20MySQL%20at%20Tumblr%20Presentation.pdf) 中投入了大量时间和精力。 尽管 MongoDB 在纽约（其所在地）很受欢迎，但并未使用。 MySQL 可以很好地扩展。. -* Gearman 是一种工作队列系统，用于长时间的开火和忘却式工作。 -* 可用性是根据覆盖范围衡量的。 用户可以访问自定义域或仪表板吗？ 同样在错误率方面。 -* 历史上最高优先项是固定的。 现在，对故障模式进行了系统地分析和处理。 目的是从用户角度和应用程序角度衡量成功。 如果无法满足要求的一部分，则为 -* 最初，Actor 模型与 Finagle 一起使用，但已被删除。 为了免于失火，使用作业队列。 此外，Twitter 的 [实用程序库](http://twitter.github.com/util/util-core/target/site/doc/main/api/com/twitter/util/package.html) 包含 [期货](http://twitter.github.com/util/util-core/target/site/doc/main/api/com/twitter/util/package.html) 实现和服务 就期货而言。 在需要线程池的情况下，将期货传递到期货池中。 一切都提交给将来的池以异步执行。 -* Scala 鼓励没有共享状态。 Finagle 被认为是正确的，因为它已经在 Twitter 上进行了生产测试。 使用 Scala 或 Finagle 中的构造避免了可变状态。 不再使用长时间运行的状态机。 状态从数据库中拉出，使用，然后写回数据库。 优势在于，开发人员无需担心线程或锁。 -* 22 个 Redis 服务器。 每个服务器有 8-32 个实例，因此生产中使用了 100 个 Redis 实例。 - * 用于仪表板通知的后端存储。 - * 通知就像用户喜欢您的信息一样。 通知会显示在用户的仪表板上，以指示其他用户对其内容执行的操作。 - * 高写入率使 MySQL 不适合使用。 - * 通知是短暂的，因此删除通知不会太可怕，因此 Redis 是此功能的可接受选择。 - * 让他们有机会了解 Redis 并熟悉它的工作原理。 - * Redis 完全没有问题，社区很棒。 - * 为 Redis 创建了一个基于 Scala 期货的界面。 现在，此功能正在迁移到其单元架构中。 - * URL 缩短器使用 Redis 作为第一级缓存，使用 HBase 作为永久存储。 - * 信息中心的二级索引围绕 Redis 构建。 - * 使用由 Finagle 构建的内存缓存代理，Redis 用作 Gearman 的持久层。 - * 从 Memcache 缓慢移至 Redis。 最终希望仅依靠一种缓存服务。 性能与 Memcache 相当。 - -### 内部消防水带 - -* 内部应用程序需要访问活动流。 活动流是有关用户创建/删除帖子，喜欢/取消喜欢帖子等的信息。一个挑战是实时分发如此多的数据。 希望能够在内部进行扩展并且可以可靠地扩展应用程序生态系统。 需要一个中心分发点。 -* 以前，此信息是使用 Scribe / Hadoop 分发的。 服务将登录到 Scribe 中并开始拖尾，然后将该数据通过管道传输到应用程序中。 此模型几乎立即停止了扩展，特别是在人们每秒创建数千个帖子的高峰期。 不想让人们将文件和管道拖到 grep。 -* 创建了一个内部 firehose 作为消息总线。 服务和应用程序通过 Thrift 与 Firehose 对话。 -* LinkedIn 的 Kafka 用于存储邮件。 在内部，消费者使用 HTTP 流从 Firehose 读取数据。 未使用 MySQL 是因为分片实现经常更改，因此使用巨大的数据流来实现它不是一个好主意。 -* firehose 模型非常灵活，与假定数据丢失的 Twitter firehose 不同。 - * 消防水带可以及时退绕。 它保留一周的数据。 在连接时，可以指定开始阅读的时间点。 - * 多个客户端可以连接，并且每个客户端都不会看到重复的数据。 每个客户端都有一个客户端 ID。 卡夫卡支持一个消费者群体的想法。 消费者组中的每个消费者都有自己的消息，不会看到重复的消息。 可以使用相同的使用者 ID 创建多个客户，并且客户不会看到重复的数据。 这样就可以独立并并行地处理数据。 Kafka 使用 ZooKeeper 定期检查消费者阅读的距离。 - -### 仪表板收件箱的单元格设计 - -* 当前用于提供仪表板功能的分散收集模型的跑道非常有限。 它不会持续更长的时间。 - * 解决方案是移至使用类似于 [Facebook 消息](http://www.facebook.com/note.php?note_id=454991608919) 的基于单元的架构实现的收件箱模型。 - * 收件箱与分散收集相反。 用户的仪表板由跟随的用户的帖子和其他用户采取的操作组成，按时间顺序逻辑存储在一起。 - * 解决了分散收集问题，因为它是一个收件箱。 您只需要问收件箱中的内容，就可以节省费用，然后便宜得多。 这将扩展很长时间。 -* 很难重写仪表板。 数据具有分布式性质，但具有交易质量，用户无法部分获得更新。 - * 数据量令人难以置信。 消息必须平均发送给数百个不同的用户，这与 Facebook 面临的问题截然不同。 大日期+高分发率+多个数据中心。 - * 规格为每秒写一百万，每秒读 50K。 数据集大小为 2.7TB 的数据增长，未启用任何复制或压缩。 百万写秒是从 24 字节行键写入的，它指示收件箱中的内容。 - * 在已经流行的必须保持运行的应用程序上执行此操作。 -* 细胞 - * 单元是一个独立的安装，其中包含适用于一系列用户的所有数据。 呈现用户仪表板所需的所有数据都在单元格中。 - * 用户被映射到单元格中。 每个数据中心存在许多单元。 - * 每个单元都有一个 HBase 群集，服务群集和 Redis 缓存群集。 - * 用户被安置在一个单元中，并且所有单元都通过 firehose 更新消耗所有帖子。 - * 每个单元都基于 Finagle，并通过 Thrift 上的 firehose 和服务请求填充 HBase。 - * 用户进入仪表板，用户位于某个特定的单元格内，服务节点通过 HBase 读取其仪表板，并将数据传回。 - * 后台任务从防火墙中消耗掉，以填充表和处理请求。 - * Redis 缓存层用于单元内的帖子。 -* 请求流：用户发布帖子，该帖子被写入 firehose，所有单元格消耗该帖子并将该帖子内容写到帖子数据库中，单元格查找以查看帖子创建者是否有任何关注者 在单元格中，如果是的话，则跟随者收件箱将更新为帖子 ID。 -* 电池设计的优势： - * 大规模规模需要并行化，而并行化要求组件彼此隔离，因此没有相互作用。 单元提供一个并行化单元，可以随着用户群的增长而调整为任意大小。 - * 细胞隔离故障。 一个单元故障不会影响其他单元。 - * 单元可以实现一些不错的功能，例如测试升级，实施滚动升级以及测试软件的不同版本的能力。 -* 容易遗漏的关键思想是： 所有帖子都复制到所有单元格 。 - * 每个单元格都存储所有帖子的单个副本。 每个单元格可以完全满足仪表板渲染请求。 应用程序不要求提供所有帖子 ID，然后要求提供这些 ID 的帖子。 它可以为用户返回仪表板内容。 每个单元都具有完成仪表板请求所需的所有数据，而无需进行任何跨单元通信。 - * 使用了两个 HBase 表：一个存储每个帖子的副本。 与存储该单元内每个用户的每个帖子 ID 的另一个表相比，该数据很小。 第二张表告诉用户仪表板的外观，这意味着他们不必获取用户关注的所有用户。 这也意味着跨客户，他们将知道您是否阅读了帖子，并且在其他设备上查看帖子并不意味着您阅读了相同的内容两次。 使用收件箱模型，状态可以保持在您已阅读的内容上。 - * 帖子太大，因此无法直接放入收件箱。 因此，将 ID 放入收件箱，并将帖子内容仅放入单元格一次。 该模型大大减少了所需的存储空间，同时使返回用户收件箱的按时间顺序的视图变得简单。 缺点是每个单元格包含完整的呼叫记录副本。 令人惊讶的是，帖子比收件箱映射要小。 每天的后期增长是每个单元 50GB，收件箱每天增长 2.7TB。 用户消费超过他们生产的东西。 - * 用户的信息中心不包含帖子的文本，仅包含帖子的 ID，而大部分增长都来自 ID。 - * 随着关注者的更改，设计是安全的，因为所有帖子均已在单元格中。 如果只有关注者帖子存储在一个单元格中，那么随着关注者的更改，该单元格将过时，并且需要某种回填过程。 - * 替代设计是使用单独的帖子群集来存储帖子文本。 这种设计的缺点是，如果群集出现故障，则会影响整个站点。 使用单元设计并向所有单元复制后，将创建一个非常强大的体系结构。 -* 拥有数百万个真正活跃的关注者的用户可以通过根据其访问模型选择性地实现用户供稿来处理（请参见 [Feeding Frenzy](http://highscalability.com/blog/2012/1/17/paper-feeding-frenzy-selectively-materializing-users-event-f.html) ）。 - * 不同的用户具有适当的不同访问模型和分发模型。 两种不同的分发模式：一种用于流行用户，另一种用于其他人。 - * 数据的处理方式取决于用户类型。 来自活跃用户的帖子实际上不会发布，而帖子将有选择地实现。 - * 关注数百万用户的用户与拥有数百万关注者的用户类似。 -* 单元大小难以确定。 单元的大小是故障的影响点。 影响到一个单元的用户数量。 要权衡他们愿意接受的用户体验以及相应的费用。 -* 从 firehose 读取是最大的网络问题。 在一个小区内，网络流量是可管理的。 -* 随着添加更多的细胞，可以将细胞放入一个从火喉读取的细胞组中，然后复制到该组中的所有细胞中。 分层复制方案。 这也将有助于转移到多个数据中心。 - -### 关于在纽约创业 - -* NY 是一个不同的环境。 很多财务和广告。 招聘具有挑战性，因为没有太多的启动经验。 -* 在过去的几年中，NY 致力于帮助初创企业。 纽约大学和哥伦比亚大学推出的计划旨在使学生在初创企业中获得有趣的实习机会，而不仅仅是去华尔街。 彭博市长正在建立一个专注于技术的本地校园。 - -### 团队结构 - -* 团队：基础架构，平台，SRE，产品，网络运营，服务。 -* 基础结构：第 5 层及以下。 IP 地址及以下，DNS，硬件配置。 -* 平台：核心应用程序开发，SQL 分片，服务，Web 操作。 -* SRE：位于服务团队和网络运营团队之间。 在可靠性和可伸缩性方面专注于更迫切的需求。 -* 服务团队：专注于更具战略意义的工作（一个月或两个月）。 -* Web 操作：负责问题检测和响应以及调整。 - -### 软件部署 - -* 从一组 rsync 脚本开始，这些脚本将 PHP 应用程序分布在各处。 一旦计算机数量达到 200，系统就开始出现问题，部署需要很长时间才能完成，并且计算机将处于部署过程的各种状态。 -* 下一阶段使用 Capistrano 将部署过程（开发，登台，生产）构建到其服务堆栈中。 可以在数十台计算机上使用服务，但是通过 SSH 连接后，在部署到数百台计算机上时再次开始出现故障。 -* 现在，所有计算机上都运行一个协调软件。 基于 RedHat 的 Func，这是一种用于向主机发出命令的轻量级 API。 缩放内置于 Func 中。 -* 通过在一组主机上执行 X 来在 Func 上进行构建部署，这避免了 SSH。 假设您要在组 A 上部署软件。主服务器伸向一组节点并运行 deploy 命令。 -* deploy 命令通过 Capistrano 实现。 它可以进行 git checkout 或从存储库中提取。 易于扩展，因为他们正在使用 HTTP。 他们喜欢 Capistrano，因为 Capistrano 支持基于简单目录的版本控制，该版本与他们的 PHP 应用程序很好地兼容。 向版本更新迈进，每个目录包含一个 [SHA](http://book.git-scm.com/1_the_git_object_model.html) ，因此可以轻松检查版本是否正确。 -* Func API 用于报告状态，即这些机器具有这些软件版本。 -* 可以安全地重新启动其所有服务，因为它们会清空连接，然后重新启动。 -* 激活之前，所有功能均在暗模式下运行。 - -### 开发 - -* 从这样的哲学开始：任何人都可以使用他们想要的任何工具，但是随着团队的成长，这种想法不起作用了。 新员工的入职非常困难，因此他们已经在堆栈上进行了标准化，以便他们能与之相处，快速发展团队，更快地解决生产问题并围绕他们开展业务。 -* 流程大致类似于 Scrum。 轻巧。 -* 每个开发人员都有一个预先配置的开发计算机。 它通过 Puppet 获取更新。 -* 开发人员机器可以滚动更改，进行测试，然后将其部署到阶段，然后将其部署到生产中。 -* 开发人员使用 vim 和 Textmate。 -* 测试是通过 PHP 应用程序的代码审查进行的。 -* 在服务方面，他们已经实现了具有提交挂钩，Jenkins 以及持续集成和构建通知的测试基础架构。 +# 阿尔及利亚分布式搜索网络的体系结构 -### 招聘流程 +> 原文： [http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) -* 面试通常避免数学，困惑和脑筋急转弯。 试着针对候选人实际要做的工作提出问题。 他们聪明吗？ 他们会把事情做好吗？ 但是衡量“完成工作”的难度很难评估。 目标是找到优秀的人才，而不是将人才拒之门外。 -* 专注于编码。 他们会要求提供示例代码。 在电话采访中，他们将使用 Collabedit 编写共享代码。 -* 面试不是对抗性的，他们只是想找到最好的人。 面试期间，候选人可以使用他们的所有工具，例如 Google。 他们的想法是，开发人员在拥有工具时才能发挥最大作用，这就是他们进行采访的方式。 -* 挑战是找到在 Tumblr 的流量水平下具有所需扩展经验的人员。 世界上很少有公司致力于解决他们所面临的问题。 - * 例如，对于一个新的 ID 生成器，他们需要一个 JVM 进程以小于 1ms 的速率生成服务响应，速率为每秒 10K 请求和 500 MB RAM 限制并具有高可用性。 他们发现串行收集器在此特定工作负载下的延迟最小。 在 JVM 调整上花费了很多时间。 -* 在 Tumblr 工程博客上，他们张贴了悼念词，表达对 [Dennis Ritchie](http://engineering.tumblr.com/post/11381547149/derekg-rip-dennis-ritchie-he-gave-us-such) & [[ John McCarthy](http://engineering.tumblr.com/post/11893095969/john-mccarthy-widely-considered-the-father-of) 。 这是一种怪异的文化。 +![](img/0acb25cc63067792b06b2ee28cf1b8a7.png) -## 获得的经验教训 +*[Julien Lemoine](https://www.linkedin.com/in/julienlemoine) 的共同发布者的 CTO [阿尔及利亚 ]](http://www.algolia.com/) ，开发人员友好的搜索即服务 API。* -* 到处都是自动化。 -* MySQL（加上分片）可扩展，而应用则不能。 -* Redis 很棒。 -* Scala 应用程序表现出色。 -* 当您不确定项目是否可行时，请报废项目。 -* 请勿通过无用的技术手腕来依靠他们的生存来雇用人员。 雇用他们是因为他们适合您的团队并且可以胜任。 -* 选择一个可以帮助您招聘所需人员的堆栈。 -* 建立团队的能力。 -* 阅读论文和博客文章。 像电池体系结构和选择性实现这样的关键设计思想都来自其他地方。 -* 询问您的同龄人。 他们与来自 Facebook，Twitter，LinkedIn 的工程师进行了交流，并交流了经验。 您可能没有权限访问此级别，但可以与某人联系。 -* 韦德，不要涉足技术领域。 他们在尝试将 HBase 和 Redis 投入生产之前，通过在试点项目或损害程度可能有限的角色中使用它们来学习。 +Algolia 于 2012 年作为移动设备的离线搜索引擎 SDK 开始。 目前，我们还不知道在两年内我们将建立一个全球分布式搜索网络。 -非常感谢 Blake 的采访。 他对时间很宽容，对解释也很耐心。 如果您想谈谈您的架构配置文件，请 [与我联系](http://highscalability.com/contact/) 。 +如今，阿尔戈利亚每月在全球 12 个地区提供超过 20 亿个用户生成的查询，我们的平均服务器响应时间为 6.7 毫秒，其中 90％的查询在不到 15 毫秒内得到答复。 我们的搜索不可用率低于 10 -6 ，这表示每月少于 3 秒。 -## 相关文章 +离线移动 SDK 面临的挑战是移动性质带来的技术限制。 这些挑战迫使我们在开发算法时会采取不同的思路，因为经典的服务器端方法无法正常工作。 -* [Tumblr Engineering Blog](http://engineering.tumblr.com/) -包含很多优秀文章 -* [与 Nathan Hamblen 一起使用 Finagle 和 Ostrich 构建网络服务](http://vimeo.com/29763331) -Finagle 很棒 -* [鸵鸟](https://github.com/twitter/ostrich/) -Scala 服务器的统计收集器&报告程序 -* [规模为](http://tumblr.mobocracy.net/post/10984130543/id-generation-at-scale) 的 ID 生成，作者 Blake Matheny -* [Finagle](http://twitter.github.com/finagle/) -JVM 的网络堆栈，可用于构建 Java，Scala 或任何 JVM 托管语言的异步远程过程调用（RPC）客户端和服务器 。 Finagle 提供了一组丰富的独立于协议的工具。 -* [来自 Tumblr 的 Finagle Redis 客户端](https://github.com/twitter/finagle/commit/c30ba58acfc19b96807f72162dcdd913365e2de2) -* [Tumblr。 Evan Elias 撰写的大量分片的 MySQL](http://assets.en.oreilly.com/1/event/74/Massively%20Sharded%20MySQL%20at%20Tumblr%20Presentation.pdf) -关于 MySQL 分片的更好的演示之一 -* [Staircar：由 Redis 驱动的通知](http://engineering.tumblr.com/post/7819252942/staircar-redis-powered-notifications) ，作者：布莱克·马森尼（Blake Matheny） -* [Flickr 架构](http://highscalability.com/flickr-architecture)-谈论 Flickr 的单元架构 +从那时起，我们的产品有了很大的发展。 我们想分享我们在这些算法之上构建和扩展 REST API 的经验。 -是否有关于此基于单元的体系结构的更多信息？ 这些关键字对于 Google 来说是非常通用的... +**我们将说明我们如何使用分布式共识来实现全球不同地区的数据的高可用性和同步，以及如何通过任意播 DNS** 将查询路由到最近的位置 。 -如果您还要存储数百万个非法 mp3，也很难扩展。 -查看 ex.fm API 关于 Tumblr 作为侵犯版权的避风港所暴露的内容。 在音乐方面，它们比 megaupload 更糟糕 +# 数据大小误解 -我不知道该体系结构是否有一个标准术语 Andrew。 Salesforce 做类似的事情，例如使用术语 Pod。 Flickr 称之为联合方法。 +在设计架构之前，我们首先必须确定我们需要支持的主要用例。 在考虑我们的扩展需求时尤其如此。 我们必须知道我们的客户是否需要索引千兆字节，太字节或 PB 的数据。 架构会有所不同，具体取决于我们需要处理多少个用例。 -似乎大多数服务器都包含： +当人们想到搜索时，大多数人会想到非常大的用例，例如 Google 的网页索引或 Facebook 的数万亿帖子索引。 如果停下来想一想每天看到的搜索框，则大多数搜索框都不会搜索大型数据集。 **Netflix 搜索约 10,000 种图书，亚马逊在美国的数据库包含约 200,000,000 种产品。 这两种情况下的数据都可以存储在单台机器** **中！** 我们并不是说拥有一台计算机是一个很好的设置，但是要记住所有数据都可以在一台计算机上存储是非常重要的，因为跨计算机同步是复杂性和性能损失的主要来源。 -500 台运行 Apache 及其 PHP 应用程序的 Web 服务器。 +# 高可用性之路 -使用 Nginx / PHP-FPM 代替 Apache / mod_php 是否有意义，因为事实证明，这可以显着提高并发请求和服务整个页面的时间？ +构建 SaaS API 时，高可用性是一个大问题，因为消除所有单点故障（SPOF）极具挑战性。 我们花了数周的时间为我们的服务集体讨论理想的搜索架构，同时牢记我们的产品将面向面向用户的搜索。 -您为什么选择 CentOS / Scientific 而不是 RHEL？ +## 主从与主从 -> 最初，Finagle 使用了 Actor 模型，但该模型已被删除。 +通过将问题暂时限制为存储在单个计算机上的每个索引，我们将高可用性设置简化为托管在不同数据中心的多台计算机。 通过这种设置，我们想到的第一个解决方案是进行主从设置，其中一台主机接收所有索引操作，然后将它们复制到一个或多个从机。 使用这种方法，我们可以轻松地在所有计算机之间负载均衡搜索查询。 -Anywhere I can read up on the issues they had with this approach? +这种主从方法的问题在于我们的高可用性仅适用于搜索查询。 所有索引操作都需要转到主服务器。 对于服务公司来说，这种架构风险太大。 要做的只是使主服务器停机，这将发生，并且客户端将开始出现索引错误。 -@meh：RHES 会带来什么好处？ 这将是相当标准的安装映像/配置。 任何操作系统问题，重新安装都很简单（为什么要进行故障排除，当您可以使用 PXE + config 管理在< 10m 中重新创建时）。 如此规模的 RHES 似乎是一笔不菲的巨额支出。 +**我们必须实现主-主架构** **！** 启用主-主设置的关键要素是要在一组机器之间就单个结果达成一致。 我们需要在所有机器之间共享**知识，这些知识在所有情况下**都保持一致，即使机器之间存在网络分离。 -关于 tumblr 内部技术的真棒读物。 感谢您发布文章，这一点非常有用。 +## 引入分布式一致性 -虚拟化呢？ 他们仅使用硬件服务器吗？ +对于搜索引擎，引入此共享知识的最佳方法之一是**将写入操作视为必须按特定顺序应用的唯一操作流**。 当我们有多个操作恰好同时出现时，我们需要为其分配一个序列 ID。 然后，可以使用该 ID 来确保将序列完全相同地应用于所有副本。 -管理所有这些的成本必须是巨大的。 该公司得到了风险投资公司的支持，但我想知道他们为保持运营状况每年亏损多少钱？ +为了分配序列 ID（每个作业后一个数字递增 1），我们需要在机器之间的下一个序列 ID 上具有共享的全局状态。 [ZooKeeper](http://zookeeper.apache.org/) 开源软件是针对集群中分布式知识的实际解决方案，我们最初开始按以下顺序使用 ZooKeeper： -> 是否有关于此基于单元的体系结构的更多信息？ 这些关键字对于 Google 来说是非常通用的... +1. 当机器收到作业时，它将使用临时名称将作业复制到所有副本。 -还可以在该网站上查看 Evernote 上的文章； 它们具有类似的“单元”架构。 +2. 然后，该机器将获得分布式锁。 -马特，感谢您提供有关 Evernote 的提示。 我看了一下这篇文章：http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150million-reques.html，假设它是您本人 在想什么？ +3. 读取 ZooKeeper 中的最后一个序列 ID，并发送命令以在所有机器上将临时文件复制为序列 ID + 1。 这等效于两阶段提交。 -我真的希望有人可以链接到受访者提到的实际论文。 +4. 如果我们从计算机（定额）中获得大多数肯定答案，则将序列 ID +1 保存在 Zookeeper 中。 -关于可伸缩性的噪音太多了，即使在这个级别上，也确实没有那么困难。 +5. 然后释放分布式锁。 -本文所显示的所有内容是，您可以拥有一个真正糟糕的体系结构，并且仍然维持相当大的流量。 +6. 最后，将结果通知发送作业的客户端。 如果有大多数提交，这将是成功的。 -这篇文章说 +不幸的是，此顺序不正确，因为如果获取锁的机器在步骤 3 和 4 之间崩溃或重新启动，我们可能会以作业在某些机器上提交的状态结束，这需要更复杂的顺序。 -> MySQL（加上分片）可扩展，而应用则不能。 +ZooKeeper 通过 TCP 连接作为外部服务打包非常困难，并且需要使用较大的超时（默认超时设置为 4 秒，表示两个滴答声，每个滴答声为 2 秒）。 -在多个地方，但是 MySQL 没有分片。 这不是 MySQL 的功能，永远不会。 +因此，无论是硬件还是软件，每个失败事件都将在此超时时间内冻结整个系统。 这似乎是可以接受的，但在我们的案例中，我们想经常在生产中测试故障（例如 Netflix 的 Monkey 测试方法）。 -应用程序在将数据发送到 MySQL 之前先对其进行分区。 这要求应用程序（或应用程序层）完全了解分区并进行管理。 这样，您现在已经删除了 RDBMS 的大多数核心功能（联接，事务，外键完整性）。 这就引出了一个问题，当我们在追求扩展到所需容量的过程中，已经中止了 SQL 的所有基本功能时，为什么要全部使用 SQL。 +## 木筏共识算法 -是的，可以使用 MySQL 技术来执行此操作，但是最终您不再像 RDMBS 那样使用它。 它具有您无法使用的所有功能，现在严重依赖于应用程序。 似乎仅仅使用为这种操作而设计的数据库并从头开始扩展会更聪明。 +大约在我们遇到这些问题的时候， [RAFT 共识算法](https://raftconsensus.github.io/) 已发布。 显然，该算法非常适合我们的用例。 RAFT 的状态机是我们的索引，日志是要执行的索引作业的列表。 我已经知道 PAXOS 协议，但是对它以及所有变体的理解不够深刻，不足以使我自己有信心实施它。 另一方面，RAFT 更清晰。 如果可以完美地满足我们的需求，即使当时没有稳定的开源实现，我也有足够的信心将其实现为我们架构的基础。 -@本·乌雷茨基 +实现共识算法最困难的部分是确保系统中没有错误。 为了解决这个问题，我选择了一种猴子测试方法，即在重新启动之前使用睡眠方式随机杀死进程。 为了进一步测试，我模拟了通过防火墙的网络掉线和性能下降。 这种测试有助于我们发现许多错误。 一旦我们运行了几天，没有任何问题，我非常有信心实施正确。 -使用 nginx / php-cgi 的性能更高，但是您必须注意： --您的脚本必须绝对无锁且响应迅速。 一个“较长的”执行时间脚本（但< 1s）可能会阻止一个 CGI 进程，这对于整个服务器来说应该是不完整的。 --您需要找到一个“完美”的 php 版本，因为一个进程将执行的请求比使用 apache 重新发出的请求要多。 对于某些版本，您可能会感到有些意外。 +## 在应用程序或文件系统级别复制吗？ -根据我自己的经验，在（nginx）/ fastcgi 上具有良好的可靠性需要花费更多时间。 +我们选择将写操作分配给所有计算机并在本地执行，而不是在文件系统上复制最终结果。 我们做出此选择的原因有两个： -架构...对...根本不起作用的功能呢，例如...搜索！ 还是不存在...像在主题开发人员的情况下清理上传的资源？ +* 更快。 索引在所有计算机上并行完成，比复制可能很大的二进制文件要快 -附言 不要误会我的意思-我喜欢 Tumblr 的简单性，但有些事情确实会踩到您的脚趾... +* 它与多个区域兼容。 如果我们在建立索引后复制文件，则需要一个将重写整个索引的过程。 这意味着我们可能要传输大量数据。 如果您需要将数据传输到世界各地（例如纽约到新加坡），则传输的数据量非常低。 -令人印象深刻的是，只有 15 位以上的网页浏览工程师才 20 名。 令人印象深刻。 +每台机器将以正确的顺序接收所有写操作作业，并独立于其他机器尽快处理它们。 **这意味着确保所有机器处于相同状态，但不必同时处于同一状态** 。 这是因为更改可能不会在同一时间在所有计算机上提交。 -根据文章 HBASE 的使用： -支持 URL 缩短， -存储历史数据和分析 -仪表板替换 -我希望这意味着，所有博客 URL，博客数据都存储在 HBASE 中。 如果我错了，请纠正我。 +## 一致性的妥协 -文章还说， -大量数据存储在 MySQL 中。 +在分布式计算中， [CAP 定理](http://en.wikipedia.org/wiki/CAP_theorem) 指出，分布式计算系统不可能同时提供以下三个功能： -那么 MySQL 是否用于存储在引入 HBASE 之前创建的旧博客？ 如果是这样，服务节点是否将决定在何处加载仪表板？ -如果有人清楚，请解释。 +* 一致性：所有节点同时看到相同的数据。 -当整个小区停止服务时会发生什么？ 该单元中的用户是否已重新归宿？ 由于所有这些信息都存储在故障节点中，这将如何影响那些用户的收件箱？ +* 可用性：确保每个请求都收到有关成功还是失败的响应。 -“内部服务正在从基于 C / libevent 的方式转变为基于 Scala / Finagle 的方式” +* 分区容限：尽管任意消息丢失或系统部分出现故障，系统仍可继续运行。 -您能描述使用 Scala / Finagle 而不是 C / libevent 的原因吗？ -谢谢！ +根据该定理，我们在一致性 上折衷了 **。 我们不保证所有节点都能在同一时间看到完全相同的数据，但是它们都将收到更新。 换句话说，在少数情况下，机器不同步。 实际上，这不是问题，因为当客户执行写操作时，我们将该作业应用于所有主机。** **在第一台机器和最后一台机器上的应用时间之间相距不到一秒钟，因此最终用户通常看不到它。 唯一可能的矛盾是上一次收到的更新是否已经应用，这与我们客户的用例兼容。** -将这样的系统以及支持该系统的业务基础结构整合在一起需要做很多工作。 可能需要花费大量时间进行阅读和编码。 我说，恭喜 Tumblr 和 CEO Karp。 继续做您所做的伟大工作。 :) +# 通用体系结构 -本文提到了 Nginx，但没有说明如何使用它。 Varnish 用于缓存，HAProxy 用于 LB，Nginx 呢？ +## 集群的定义 -感谢您的发布。 非常全面，连贯，详细。 可以确定的时间是 Verizon 之前的收购。 我想知道老电话公司做了什么来弄乱这个漂亮的沙箱。 另一个奇迹：他们赚钱了吗？ \ No newline at end of file +为了拥有高可用性基础结构，必须在机器之间拥有分布式共识，但是遗憾的是存在很大的缺陷。 **此共识需要机器** **之间进行多次往返，因此每秒可能达成共识的数量与不同机器**之间的延迟直接相关。 他们需要接近才能每秒获得大量共识。 为了能够支持多个区域而不牺牲可能的写入操作的数量，这意味着我们需要有多个集群，每个集群将包含三台充当完美副本的机器。 + +每个区域只有一个集群是达成共识所需的最低要求，但仍远非完美： + +* 我们无法使所有客户都适合一台机器。 + +* 我们拥有的客户越多，每个唯一客户每秒可以执行的写操作数量就越少。 这是因为每秒的最大共识数是固定的。 + +为了解决此问题，我们决定在区域级别应用相同的概念： **每个区域将具有由三个计算机组成的几个群集** 。 一个集群可以容纳一个到几个客户，具体取决于他们拥有的数据大小。 这个概念与虚拟化在物理机上所做的事情很接近。 我们能够将几个客户放在一个集群上，但一个客户可以动态增长并更改其使用情况。 为此，我们需要开发和自动化以下过程： + +* 如果群集中的数据太多或写入操作数量过多，则将其迁移到另一群集。 + +* 如果查询量太大，则将新计算机添加到群集。 + +* 如果数据量太大，则更改分片的数量或将一个客户分散在多个群集中。 + +如果我们拥有这些流程，则不会将客户永久分配给集群。 分配将根据其自身的使用以及集群的使用而变化。 这意味着我们需要一种将客户分配给集群的方法。 + +## 将客户分配给集群 + +管理此分配的标准方法是每个客户拥有一个唯一的 DNS 条目。 这类似于 Amazon Cloudfront 的工作方式。 每个客户都被分配一个格式为 customerID.cloudfront.net 的唯一 DNS 条目，然后可以根据该客户针对不同的计算机集。 + +我们选择了相同的方法。 **为每个客户分配一个唯一的应用程序 ID，该 ID 链接到格式为 APPID.algolia.io 的 DNS 记录**。 该 DNS 记录以特定群集为目标，该群集中的所有计算机都是 DNS 记录的一部分，因此可以通过 DNS 进行负载平衡。 我们还使用运行状况检查机制来检测计算机故障，并将其从 DNS 解析中删除。 + +即使 DNS 记录上的 TTL 值非常低（TTL 是允许客户端保留 DNS 答复的时间），运行状况检查机制仍不足以提供良好的 SLA。 问题在于主机可能会关闭，但用户仍将主机保留在缓存中。 用户将继续向其发送查询，直到缓存过期。 更糟糕的是，因为 TTL 并不是一门精确的科学。 在某些情况下，系统不遵守 TTL。 我们已经看到一些 DNS 服务器将一分钟 TTL 转换为 30 分钟 TTL 的 DNS 记录。 + +为了进一步提高高可用性并避免机器故障影响用户，我们为每个客户生成了另一组 DNS 记录，格式为 APPID-1.algolia.io，APPID-2.algolia.io 和 APPID- 3.algolia.io。 这些 DNS 记录的思想是允许我们的 API 客户端在达到 TCP 连接超时（通常设置为一秒）时重试其他记录。 我们的标准实现是对 DNS 记录列表进行混洗，并按顺序尝试它们。 + +与我们的 API 客户端中精心控制的重试和超时逻辑相结合，这被证明是比使用专门的负载平衡器更好，更便宜的解决方案。 + +后来，我们发现时髦的.IO TLD 并不是性能的理想选择。 与.NET 相比，.IO 的任意播网络中的 DNS 服务器更少，并且那里的服务器已经饱和。 这导致大量超时，从而减慢了名称解析的速度。 此后，我们通过切换到 algolia.net 域解决了这些性能问题，同时通过继续支持 algolia.io 来保持向后兼容性。 + +# 集群的可伸缩性如何？ + +我们选择使用多个集群使我们能够添加更多客户，而不会因为集群之间的隔离而对现有客户造成太大的风险。 但是我们仍然担心需要解决的一个集群的可伸缩性。 + +群集可伸缩性中的第一个限制因素是由于共识而导致的每秒写入操作数。 为了缓解这一因素，我们从共识的角度出发，在 API 中引入了批处理方法，该方法将一组写操作封装在一个操作中。 问题在于，某些客户仍然不分批地执行写操作，这可能会对群集的其他客户的索引速度产生负面影响。 + +为了减少对性能的影响，我们对体系结构进行了两项更改： + +* 我们从共识的角度出发，通过在一个唯一的操作中自动聚合每个客户的所有写操作，从而在共识存在争议时添加了批处理策略。 在实践中，这意味着我们正在重新排列作业的顺序，但不影响操作的语义。 例如，如果有 1,000 个待达成共识的作业，而 990 个来自一个客户，则即使有其他客户的作业交错在一起，我们也会将 990 个写入操作合并为一个。 + +* 我们添加了一个共识调度程序，该调度程序控制每秒为每个应用程序 ID 输入共识的写入操作数。 这避免了一个客户能够使用共识的所有带宽。 + +在实施这些改进之前，**我们通过返回 429 HTTP 状态代码**尝试了限速策略。 很快就很明显，这对于我们的客户来说太痛苦了，以至于不得不等待这种响应并实施重试策略。 如今，我们最大的客户每天在三台计算机的单个群集上执行超过 10 亿次写操作，平均每秒执行 11,500 次操作，突发次数超过 15 万次。 + +第二个问题是找到最佳的硬件设置，并避免可能影响群集可伸缩性的任何潜在瓶颈（例如 CPU 或 I / O）。 从一开始，我们就选择使用自己的裸机服务器，以完全控制我们的服务性能并避免浪费任何资源。 选择正确的硬件被证明是一项艰巨的任务。 + +在 2012 年底，我们从一个小型设置开始，包括：Intel Xeon E3 1245v2、2 个 Intel RAID 320 系列，RAID 0 中的 120GB 和 32GB RAM。 该硬件价格合理，比云平台更强大，使我们能够在欧洲和美国东部启动该服务。 + +此设置使我们能够调整内核的 I / O 调度和虚拟内存，这对于我们利用所有可用的物理资源至关重要。 即使这样，我们很快发现我们的限制是 RAM 和 I / O 的数量。 我们使用了大约 10GB 的 RAM 来建立索引，而仅剩下 20GB 的 RAM 用于缓存用于执行搜索查询的文件。 我们的目标一直是在内存中存储客户索引，以便针对毫秒级的响应时间优化服务。 当前的硬件设置是为 20GB 的索引数据而设计的，该数据太小了。 + +首次设置后，我们尝试了具有单插槽和双插槽 CPU，128GB 和 256GB RAM 以及不同型号/大小的 SSD 的不同硬件机器。 + +我们终于找到了一台包含 Intel Xeon E5 1650v2、128GB RAM 和 2x400GB Intel S3700 SSD 的机器的最佳设置。 SSD 的型号对于耐用性非常重要。 在找到可以在生产中使用多年的正确型号之前，我们烧掉了许多 SSD。 + +最后，我们构建的最终体系结构使我们仅需一个条件即可在所有领域进行良好的扩展：我们需要随时拥有免费资源。 在 2015 年，要处理必须管理裸机服务器的痛苦似乎有些疯狂，但是我们在为客户提供的服务质量和价格方面所获得的收益是值得的。 我们能够提供一个完全打包的搜索引擎，该引擎可以复制到三个不同的位置（在内存索引中），并且在比 AWS 更高的位置上具有出色的性能！ + +# 操作复杂吗？ + +## 限制进程数 + +**每台机器仅包含三个进程** 。 第一个是 Nginx 服务器，其中所有查询解释代码均作为模块嵌入其中。 为了回答查询，我们在内存中映射了索引文件并直接在 nginx worker 中执行查询，而无需与其他进程或机器进行通信。 唯一的例外是，当客户数据不适合一台机器时，这种情况很少发生。 + +第二个过程是 Redis 键/值存储，我们使用它来检查速率和限制以及存储每个应用程序 ID 的实时日志和计数器。 这些计数器用于构建我们的实时信息中心，当您连接到帐户时可以查看。 这对于可视化您的最后一个 API 调用和调试很有用。 + +最后一个过程是构建器。 这是负责处理所有写入操作的过程。 当 nginx 进程接收到写操作时，它将操作转发给构建器以执行共识。 它还负责构建索引，并包含许多监视代码，用于检查我们的服务中的错误，例如崩溃，索引编制缓慢，索引编制错误等。根据问题的严重性，SMS 通过 Twilio 的 API 报告某些错误 而其他则直接报告给 PagerDuty。 每次在生产中检测到新问题且未报告时，我们确保将来添加一个新探针以监视此类错误。 + +## 易于部署 + +**此堆栈的简单性使部署变得容易** 。 在部署任何代码之前，我们应用一堆单元测试和非回归测试。 一旦所有这些测试通过，我们便逐渐部署到集群。 + +我们的部署永远不会影响生产，也不会对最终用户可见。 同时，我们还希望以协商一致的方式产生主机故障，以便检查一切是否按预期进行。 为了实现这两个目标，我们独立部署群集的每台计算机，并应用以下过程： + +1. 获取新的 Nginx 和生成器二进制文件。 + +2. [正常重启 nginx](http://nginx.org/en/docs/control.html#upgrade) Web 服务器，并使用新的二进制文件重新启动 nginx，而不会丢失任何用户查询。 + +3. 杀死构建器并使用新的二进制文件将其启动。 这会触发每台计算机部署 RAFT 失败，从而使我们能够确保故障转移按预期进行。 + +操作系统的简单性是我们体系结构的重要目标。 我们既不希望也不相信部署应该受到体系结构的限制。 + +## 实现良好的全球覆盖范围 + +服务正在变得越来越全球化。 仅在全球一个地区提供搜索查询远非最佳。 例如，在美国东部地区托管搜索将在可用性方面有很大不同，具体取决于用户从何处进行搜索。 对于美国东部用户来说，延迟时间将从几毫秒到亚洲用户的数百毫秒，这还不包括饱和的海外光纤的带宽限制。 + +我们已经看到一些公司在搜索引擎之上使用 CDN 来解决这些问题。 最终，这给我们带来了比价值更大的问题，因为使缓存无效是一场噩梦，并且仅提高了很少一部分频繁执行的查询的速度。 我们很清楚，为了解决这个问题，我们需要将索引复制到不同的区域，并将它们加载到内存中，以便有效地回答用户查询。 + +我们需要的是在现有群集复制之上的 **区域间复制** 。 副本可以存储在一台机器上，因为该副本仅用于搜索查询。 所有写操作仍将转到客户的原始群集。 + +**每个客户都可以选择他们希望拥有的一组数据中心** 作为复制对象，因此特定区域中的复制计算机可以从多个群集中接收数据，并且一个群集可以 将数据发送到多个副本。 + +此架构的实现是基于我们基于共识的操作流建模的。 在达成共识之后，每个集群都将其自己的写操作流转换为每个副本的版本，以确保用无操作作业替换与此副本无关的作业。 然后，此操作流作为一批操作发送到所有副本，以避免尽可能多的延迟。 一次发送作业将导致重复的往返次数过多。 + +在群集上，写操作将保留在计算机上，直到所有复制对其进行确认为止。 + +DSN 的最后一部分是将最终用户直接重定向到最近的位置。 为此，我们以 APPID-dsn.algolia.net 的形式添加了另一个 DNS 记录，该记录负责解决最接近的数据中心的问题。 我们首先使用了 Amazon 的 Route53 DNS 服务，但很快达到了极限。 + +* 基于延迟的路由仅限于 AWS 区域，并且我们有印度，香港，加拿大和俄罗斯等 AWS 未覆盖的位置。 + +* 基于地理位置的路由非常糟糕。 您需要为每个国家/地区指定 DNS 解析度。 这是许多托管 DNS 提供商所采用的经典方法，但是对于我们而言，这将是一个噩梦，无法提供足够的相关性。 例如，我们在美国有几个数据中心。 + +经过大量基准测试和讨论，出于以下几个原因，我们决定使用 [NSOne](http://www.nsone.net) 。 + +* 对我们来说，他们的 Anycast 网络非常出色，并且比 AWS 更好的平衡。 例如，他们在印度和非洲拥有 POP。 + +* 他们的滤波器逻辑非常好。 对于每个客户，我们可以指定与其关联的机器（包括复制机器）列表，并使用地理位置过滤器按距离对它们进行排序。 这样我们就可以保持最好的状态。 + +* 它们支持 EDNS 客户端子网。 这对我们来说很重要，以便更具针对性。 我们使用最终用户的 IP 而不是其 DNS 服务器的 IP 进行解析。 + +在性能方面，我们已经能够在第二级达到全球范围内的全球同步。 您可以在 [Product Hunt 的搜索](http://www.producthunt.com/) （托管在美国东部，美国西部，印度，澳大利亚和欧洲）或 [Hacker News 上进行尝试。 搜索](https://hn.algolia.com/) （托管在美国东部，美国西部，印度和欧洲）。 + +## 结论 + +我们花费了大量时间来构建我们的分布式和可伸缩体系结构，并且遇到了许多不同的问题。 我希望本文能使您更​​好地了解我们如何解决这些问题，并提供有关如何设计自己的服务的有用指南。 + +我看到越来越多的服务目前正面临着与我们类似的问题，全世界的受众都拥有多区域的基础架构，但是却拥有一些全球一致的信息，例如登录名或内容。 为了获得出色的用户体验，如今必须拥有多区域基础架构。 例如，可以使用这种方法来分发在全球范围内一致的只读数据库副本！ + +如果您有任何问题或意见，我将很乐意回答。 + +[在 HackerNews 上](https://news.ycombinator.com/item?id=11185713) + +FWIW，Raft 和 Paxos 之间的主要区别在于，如果在故障转移期间发生写操作，则 Raft 保证数据丢失。 Paxos 直接将写入与主选举过程联系在一起，以使写入不会丢失。 两者还可以在部分网络故障的情况下锁定到位； 根据具体实施情况，Raft 倾向于留在那里并接受数据一段时间。 因此，尽管 Raft 更简单/更轻松，但这是因为它使您能够以非常糟糕的方式破坏 Paxos 明智地处理的事情。 + +这篇文章将来会发表。 可能弄乱了一些提要阅读器。 + +您是否考虑过使用 Kafka 在集群中实现“状态机”复制？ + +我是作者，并回复评论： + +以色列：RAFT 和 Paxos 的保证是相同的：当共识成功时，就可以保证没有数据丢失。 您能否详细说明为什么您认为并非如此？ + +凯恩：由于多个地区的部署，卡夫卡不是一个选择。 我们需要对复制的序列 ID 分配进行更底层的控制 + +您在搜索引擎中使用什么技术？ + +@Jeyendran 如简介中所述，这是我们自己的引擎，以低级 C ++开发，并作为模块嵌入在 nginx 中。 由于以下几个原因，我们不是基于像 lucene / sphinx 这样的开源引擎： +-我们处理关联性的方式非常不同，这意味着对现有引擎 +进行了巨大的重构-在即时搜索中具有非常好的性能 用例（键入时进行搜索），我们具有不同的数据结构。 我将尝试写一篇博客文章来解释我们所有的算法/数据结构差异 + +可能是我读过的最好的文章！ + +我很高兴看到其他人考虑了“三个进程”机制，并在 nginx 和其他进程之间使用了 mmap 文件。 和强大的）集群技术。 + +谢谢您的出色工作。 + +您提到过，在使用 RAFT 协议的一致性上存在折衷。 根据我的理解，RAFT 并没有给出分区容限，因为每个状态机都需要互相交谈以复制状态。 因此，这是 CAP 定理的 CA 系统，在这里我们可以最终保持一致。 + +我喜欢你的文章。 感谢分享 ：）） + +嗯，是的，Raft 和 Paxos 都提供了类似的一致性保证。 甚至还有自动的正确性证明：https://github.com/uwplse/verdi/pull/16 + +该帖子说他们使用 Raft 来协调故障转移，并且分别决定损害一致性，而不是他们使用 Raft 损害了的一致性*。 您可以维护有关某些事物（例如，当前哪个节点是主节点）的始终一致的信息，而不能维护其他事物（例如，您正在服务的索引的实际内容）。* + +也许 Raft 不一致的想法来自对 https://aphyr.com/posts/316-jepsen-etcd-and-consul 的误解，（正确地）它说 Raft 的两个广泛使用的实现缺少了使 读取速度较慢，但​​有必要避免以下情况：1）您在分区的少数一方 2）先前的主机太 3）选出新的主机，并且有人在第一秒内向其中写入新数据，或者 因此，4）您在写完之后阅读。 + +两种系统最终都提供了没有异常的模式，这是由于 Raft 的实现不完整所致，而不是 Raft 本身的缺陷。 + +非常感谢您的帖子。 我学到了很多。 \ No newline at end of file diff --git a/docs/163.md b/docs/163.md index bc384ff..29fe732 100644 --- a/docs/163.md +++ b/docs/163.md @@ -1,60 +1,402 @@ -# 99designs 的设计-数以千万计的综合浏览量 - -> 原文： [http://highscalability.com/blog/2012/2/6/the-design-of-99designs-a-clean-tens-of-millions-pageviews-a.html](http://highscalability.com/blog/2012/2/6/the-design-of-99designs-a-clean-tens-of-millions-pageviews-a.html) - -![](img/a183daad868477437902751c2609ac97.png) [99designs](http://99designs.com/) 是基于澳大利亚墨尔本的众包设计竞赛市场。 这样的想法是，如果您有需要的设计，就可以创建比赛，而设计师可以通过竞争在预算范围内为您提供最佳设计。 - -如果您是中型商业网站，那么这是一个干净的网站示例架构，可可靠地支持许多用户并在云上提供复杂的工作流。 Lars Yencken 在 99designs 上对[基础架构中的 99designs 背后的体系结构做了很好的书面介绍。 这是他们的架构的亮点：](http://99designs.com/tech-blog/blog/2012/01/30/infrastructure-at-99designs/) - -## 统计资料 - -* 团队有 8 个开发人员，2 个开发运营人员，2 个辅助/设计师 -* 一个月成千上万的独立访客 -* 每月千万浏览量 - -## 叠放 - -* 很大程度上是基于 Amazon 的堆栈 -* 弹性负载平衡器（ELB） -* 漆 -* PHP 与 Apache / mod_php -* S3 -* 使用 Pheanstalk 绑定进行内存队列查询的 Beanstalk -* 亚马逊的 RDS（MySQL） -* 记忆快取 -* MongoDB -* 雷迪斯 -* 右秤/厨师 -* NewRelic，CloudWatch，Statsd - -## 基础设施 - -* 分层体系结构：负载平衡，加速，应用程序，异步任务，存储和瞬时数据。 -* ELB 是可靠的，并且可以处理负载平衡和终止 SSL 连接，以便在 ELB 下方对流量进行不加密。 每个域使用单独的 ELB。 -* Varnish 用于提供基于文件的长尾媒体。 -* Varnish 快速，可配置，具有 DSL，并且具有用于调试实时流量的有用命令行工具。 -* 动态和未缓存的请求是从 PHP 应用程序提供的。 -* 设计存储在 S3 上。 -* S3 延迟很差，因此在每个请求之后都会在本地缓存设计。 -* 可能需要很长时间的请求被异步排队到使用 Beanstalk 实现的内存队列中，该队列轻巧且性能良好。 -* PHP 工作者从队列中读取工作并执行所需的功能。 -* 已计划的作业在适当的时间使用 cron 排队。 -* Amazon 的 RDS 用作数据库，并使用跨多个可用性区域的主-主复制来实现冗余。 -* 滚动 RDS 备份用作灾难发现。 -* 随着负载增加，请求将在读取的从属设备之间实现负载平衡。 -* S3 存储媒体文件和数据文件。 -* 备份到 Rackspace 和 Cloudfiles 以进行灾难恢复。 -* Memcached 在每台服务器上运行，用于缓存查询。 -* MongoDB 中的上限集合用于记录错误和统计信息。 -* Redis 按用户存储有关为用户启用哪些功能的信息。 -* 每个用户配置用于深色启动，软启动和增量功能推出。 -* 亚马逊允许他们不拥有任何硬件，并保持灵活性。 -* 强调使用“软件作为基础结构”精神的自动化。 -* Rightscale 使用 Chef 管理服务器配置。 服务器是一次性的。 -* 使用 NewRelic，CloudWatch，Statsd 实施监视。 两个大的监视屏幕显示站点行为的仪表板。 - -## 得到教训 - -* **测试以按比例缩小**。 高度可变的负载意味着它们大量使用了云的按比例缩减功能，这需要大量测试才能正常工作。 -* **国际客户需要 CDN** 。 他们有很多国际客户，由于他们不在美国东部服务，因此这些客户并不总是能获得优质的体验。 他们正在寻找各种 CDN，以便为国际客户提供更好的服务。 -* **在增长过程中保持稳定性需要测试和自动化。 为了支持频繁发布，他们实施了验收测试和更多的自动化功能。 基于每个用户打开和关闭功能的能力允许针对一部分用户测试新功能。** \ No newline at end of file +# AppLovin：通过每天处理 300 亿个请求向全球移动消费者进行营销 + +> 原文： [http://highscalability.com/blog/2015/3/9/applovin-marketing-to-mobile-consumers-worldwide-by-processi.html](http://highscalability.com/blog/2015/3/9/applovin-marketing-to-mobile-consumers-worldwide-by-processi.html) + +![](img/860869409851e105796fdbcb7d6221ce.png) + +*这是来自 [AppLovin](http://www.applovin.com/) 的工程副总裁 [Basil Shikin](https://www.linkedin.com/in/basilshikin) 的来宾帖子，内容涉及其移动营销平台的基础架构。 Uber，迪士尼，Yelp 和 Hotels.com 等主要品牌都使用 AppLovin 的移动营销平台。 每天处理 300 亿个请求，每天处理 60 TB 的数据。* + +AppLovin 的营销平台为想要通过移动设备吸引消费者的品牌提供营销自动化和分析。 该平台使品牌商可以使用实时数据信号在全球十亿移动消费者中做出有效的营销决策。 + +# 核心统计信息 + +* 每天 300 亿个广告请求 + +* 每秒 300,000 个广告请求，最高为每秒 500,000 个广告请求 + +* 5 毫秒平均响应延迟 + +* 每秒 3 百万个事件 + +* 每天处理 60TB 数据 + +* 〜1000 台服务器 + +* 9 个数据中心 + +* 〜40 个报告维度 + +* 每分钟 500,000 个指标数据点 + +* 1 Pb 火花簇 + +* 所有服务器上的峰值磁盘写入速度为 15GB / s + +* 所有服务器上的峰值磁盘读取速度为 9GB / s + +* AppLovin 成立于 2012 年，总部位于帕洛阿尔托，并在旧金山，纽约，伦敦和柏林设有办事处。 + +# 技术堆栈 + +## 第三方服务 + +* [Github](https://github.com/) 用于代码 + +* [Asana](https://asana.com/) 用于项目管理 + +* [HipChat](https://www.hipchat.com/) 用于通信 + +## 数据存储 + +* [Aerospike](http://www.aerospike.com/) 用于用户个人资料存储 + +* [Vertica](http://www.vertica.com/) ，用于汇总统计信息和实时报告 + +* 每秒聚合 350,000 行，并以每秒 34,000 行的速度写入 Vertica + +* 每秒写入 Aerospike 的峰值为 12,000 个用户个人资料 + +* 适用于广告数据的 MySQL + +* [Spark](https://spark.apache.org/) 用于离线处理和深度数据分析 + +* [Redis](http://redis.io/) 用于基本缓存 + +* [节俭](https://thrift.apache.org/) 用于所有数据存储和传输 + +* 每个数据点在 4 个数据中心中复制 + +* 每个服务至少在 2 个数据中心中复制（最多 8 个） + +* 用于长期数据存储和备份的 Amazon Web Services + +## 核心应用和服务 + +* 自定义 C / C ++ Nginx 模块，用于高性能广告投放 + +* 用于数据处理和辅助服务的 Java + +* 用于 UI 的 PHP / Javascript + +* [Jenkins](http://jenkins-ci.org/) 用于持续集成和部署 + +* Zookeeper，用于分布式锁定 + +* 具有高可用性的 HAProxy 和 IPVS + +* Java / C ++静态代码分析的覆盖范围 + +* Checkstyle 和 PMD 用于 PHP 静态代码分析 + +* DC 集中式日志服务器的系统日志 + +* 休眠，用于基于事务的服务 + +## 服务器和资源调配 + +* Ubuntu + +* 用于裸机置备的补鞋匠 + +* 用于配置服务器的厨师 + +* Berkshelf 适用于 Chef 依赖项 + +* 带有 Test Kitchen 的 Docker，用于运行基础结构测试 + +* 软件（ipvs，haproxy）和硬件负载平衡器的组合。 计划逐步摆脱传统的硬件负载平衡器。 + +# 监视堆栈 + +## 服务器监视 + +* 所有服务器的 [Icinga](https://www.icinga.org/) + +* 约 100 个自定义 Nagios 插件，用于深度服务器监视 + +* 每个服务器 550 个各种探针 + +* [石墨](http://graphite.wikidot.com/) 作为数据格式 + +* [Grafana](http://grafana.org/) 用于显示所有图形 + +* [PagerDuty](http://www.pagerduty.com/) 用于问题升级 + +* [冒烟](http://oss.oetiker.ch/smokeping/) 用于网络网格监视 + +## 应用程序监视 + +* [VividCortex](https://vividcortex.com/) 用于 MySQL 监控 + +* 每个服务上的 JSON / health 端点 + +* 跨 DC 数据库一致性监视 + +* 9 个 4K 65 英寸电视，用于显示办公室中的所有图表 + +* 统计偏差监视 + +* 欺诈性用户监视 + +* 第三方系统监视 + +* 部署记录在所有图表中 + +## 智能监控 + +* 具有反馈回路的智能警报系统：可以自省一切的系统可以学到任何东西 + +* 还会监控有关 AppLovin 的第三方统计信息 + +* 警报是跨团队的活动：开发人员，操作人员，业务，数据科学家都参与其中 + +# 体系结构概述 + +## 一般注意事项 + +* 将所有内容存储在 RAM 中 + +* 如果不合适，请将其保存到 SSD + +* L2 缓存级别优化很重要 + +* 使用正确的工具完成正确的工作 + +* 体系结构允许交换任何组件 + +* 仅当替代方案好 10 倍时才升级 + +* 如果没有合适的组件，请编写自己的组件 + +* 复制重要数据至少 3 倍 + +* 确保可以在不破坏数据的情况下重播每条消息 + +* 自动化所有内容 + +* 零拷贝消息传递 + +## 消息处理 + +* 保证消息传递的自定义消息处理系统 + +* 每封邮件进行 3 倍复制 + +* 发送消息=写入磁盘 + +* 任何服务都可能失败，但是没有数据丢失 + +* 消息调度系统将所有组件连接在一起，提供了系统的隔离和可扩展性 + +* 跨 DC 故障容忍度 + +## 广告投放 + +* Nginx 的速度非常快：可以在不到一毫秒的时间内投放广告 + +* 将所有广告投放数据保留在内存中：只读 + +* jemalloc 将速度提高了 30％ + +* 将 Aerospike 用于用户个人资料：不到 1 毫秒即可获取个人资料 + +* 将所有广告投放数据预先计算在一个盒子上，并在所有服务器上分发 + +* 洪流用于在所有服务器之间传播服务数据。 与基于 HTTP 的分发相比，使用 Torrent 导致原始服务器上的网络负载下降 83％。 + +* mmap 用于在 Nginx 进程之间共享广告投放数据 + +* XXHash 是具有低冲突率的最快的哈希函数。 计算校验和的速度比 SHA-1 快 75 倍 + +* 实际流量的 5％进入登台环境 + +* 能够一次运行 3 个 A / B 测试（三个独立测试的流量为 20％/ 20％/ 10％，对照为 50％） + +* A / B 测试结果可在常规报告中查看 + +# 数据仓库 + +* 所有数据都已复制 + +* 运行大多数报告所需的时间不到 2 秒 + +* 聚合是允许快速报告大量数据的关键 + +* 最近 48 小时的非汇总数据通常可以解决大多数问题 + +* 7 天的原始日志通常足以调试 + +* 一些报告必须预先计算 + +* 始终考虑多个数据中心：每个数据点都到达多个位置 + +* S3 中的备份用于灾难性故障 + +* 所有原始数据都存储在 Spark 集群中 + +# 小组 + +## 结构 + +* 70 名全职员工 + +* 15 个开发人员（平台，广告投放，前端，移动） + +* 4 位数据科学家 + +* 5 开发。 行动。 + +* 加利福尼亚帕洛阿尔托的工程师 + +* 加利福尼亚州旧金山市的业务 + +* 在纽约，伦敦和柏林的办事处 + +## 互动 + +* 讨论最多问题的 HipChat + +* Asana，用于基于项目的通信 + +* 所有代码均已审核 + +* 常见的组代码审核 + +* 公司季度郊游 + +* 与首席执行官定期举行市政厅会议 + +* 所有工程师（CTO 初级）都写代码 + +* 面试很难：要价实在难得 + +## 开发周期 + +* 开发人员，业务部门或数据科学团队提出了一个想法 + +* 提案已审核并计划在星期一的会议上执行。 + +* 功能是在分支中实现的； 开发环境用于基本测试 + +* 创建拉取请求 + +* 代码经过审核，并在上进行迭代 + +* 对于大型功能，组代码审核很常见 + +* 该功能已合并到母版 + +* 该功能已部署到下一个版本 + +* 该功能已在 5％的实际流量上进行了测试 + +* 已检查统计信息 + +* 如果功能成功，则将逐步量产 + +* 连续几天监控功能 + +## 避免出现问题 + +* 该系统旨在处理任何组件的故障 + +* 单个组件的故障都不会损害广告投放或数据一致性 + +* 全能监控 + +* 工程师观看并分析关键业务报告 + +* 高质量的代码至关重要 + +* 某些功能在毕业之前需要经过多次代码审查和迭代。 + +* 在以下情况下触发警报： + + * 分期统计数据与生产数据不同 + + * 关键服务出现致命错误 + + * 错误率超过阈值 + + * 检测到任何不规则活动 + +* 数据永不丢失 + +* 大多数日志行都可以轻松解析 + +* 通过设计，回滚任何更改都很容易 + +* 每次失败后：修复，确保将来不会发生相同的事情，并添加监视 + +# 获得的经验教训 + +## 产品开发 + +* 轻松交换任何组件是增长的关键 + +* 故障推动了创新解决方案 + +* 过渡环境必不可少：始终准备放松 5％ + +* A / B 测试必不可少 + +* 监视所有内容 + +* 建立智能警报系统 + +* 工程师应了解业务目标 + +* 商界人士应意识到工程学的局限性 + +* 使构建和持续集成快速。 Jenkins 在 2 台裸机服务器上运行，这些服务器具有 32 个 CPU，128G RAM 和 SSD 驱动器 + +## 基础结构 + +* 监视所有数据点至关重要 + +* 自动化很重要 + +* 每个组件在设计上均应支持 HA + +* 内核优化可将性能提高多达 25％ + +* 流程和 IRQ 平衡又使性能提高了 20％ + +* 省电功能会影响性能 + +* 尽可能使用 SSD + +* 优化时，分析所有内容。 火焰图很棒！ + +[关于黑客新闻](https://news.ycombinator.com/item?id=9171871) + +它们如何在服务器之间平衡请求的负载？ + +@une：我们结合使用了软件（ipvs，haproxy）和硬件负载平衡器。 我们计划逐步摆脱传统的硬件负载平衡器。 + +您多久发布一次新功能到生产环境？ +您能否详细描述代码审查的执行方式，是正式的还是非正式的，重点是什么。 + +嗨，罗勒，非常感谢。 + +我现在对您的“暂存”环境特别感兴趣，因为我们正在以类似的规模开展工作，并想出如何管理这种环境。 + +您能否进一步评论它的“深度”？ 即是否仅复制了您的前端/应用服务器并且“登台”仍共享生产数据库？ 还是您以某种方式拥有一个完全独立的环境，直到数据库和其他后端服务？ + +如果您在暂存中有任何有状态服务，那么如何管理诸如一致性/模式更改/仅部分可用数据之类的问题？ 如果不这样做，您将如何为这些服务进行集成测试/部署-尤其是日志摄取管道之类的事情，这似乎对您的工作至关重要？ + +谢谢！ + +@Wes +我们的发布时间表很忙。 通常每周 2-3 次。 +我们使用 [GitHub Flow](https://guides.github.com/introduction/flow/) 进行代码审查和讨论。 我们致力于以最简单的方式实现该功能。 + +@Paul Banks +我们的暂存环境很深。 我们试图确保每个生产服务都有一个临时的对等设备，可以获取 5-10％的真实数据。 + +我们确实需要共享一些状态以使登台环境变得全面。 某些棘手的问题只能用真实数据才能解决。 +由于登台环境可以运行实验代码，因此我们确保采取适当的措施，以方便分离生产和登台数据。 + +此设置还有助于我们进行监视：在大多数情况下，预期生产和登台环境的行为类似。 偏差可能表明存在潜在问题。 + +您好，能否请您简单说明一下如何处理 40 个基于维度的指标。 我们有一个类似的维度大小系统，我正在尝试使用 hbase 和 redis 在每分钟只有 200 万个指标点的情况下使用很少的服务器。 \ No newline at end of file diff --git a/docs/164.md b/docs/164.md index 27b49cf..8bcebd4 100644 --- a/docs/164.md +++ b/docs/164.md @@ -1,72 +1,137 @@ -# 数据范围项目-6PB 存储，500GBytes / sec 顺序 IO，20M IOPS，130TFlops +# Swiftype 如何以及为何从 EC2 迁移到真实硬件 -> 原文： [http://highscalability.com/blog/2012/2/2/the-data-scope-project-6pb-storage-500gbytessec-sequential-i.html](http://highscalability.com/blog/2012/2/2/the-data-scope-project-6pb-storage-500gbytessec-sequential-i.html) +> 原文： [http://highscalability.com/blog/2015/3/16/how-and-why-swiftype-moved-from-ec2-to-real-hardware.html](http://highscalability.com/blog/2015/3/16/how-and-why-swiftype-moved-from-ec2-to-real-hardware.html) -![](img/142377d6ed7c155435afaec71c9789ac.png) +![](img/bd13f7a734bb8c2326b8a527a50cfa1f.png) -“ **数据无处不在，永远不在单个位置。 无法扩展，无法维护。** ， –Alex Szalay +*这是 [Oleksiy Kovyrin](https://twitter.com/kovyrin) 的来宾帖子， [Swiftype](https://swiftype.com/) 。 Swiftype 目前为超过 100,000 个网站提供搜索功能，每月提供超过 10 亿个查询。* -尽管伽利略在望远镜揭示的奥秘上进行了生死教义的比赛，但又没有引起另一场革命，显微镜在奥秘之后放弃了奥秘 还没有人知道它所揭示的内容具有颠覆性。 这些新的感知增强工具首次使人类能够窥见外表的面纱。 数百年来，驱动人类发明和发现的崭新视角。 +当 Matt 和 Quin 在 2012 年创立 Swiftype 时，他们选择使用 Amazon Web Services 建立公司的基础架构。 云似乎是最合适的选择，因为它很容易在不管理硬件的情况下添加新服务器，并且没有前期成本。 -数据是隐藏的另一种 [](http://highscalability.com/blog/2009/11/16/building-scalable-systems-using-data-as-a-composite-material.html)数据，仅当我们查看不同的比例并调查其底层时才显示自身 模式。 如果宇宙是由信息 真正构成的 [，那么我们正在研究真正的原始事物。 数据需要一个新的眼睛，一个雄心勃勃的项目称为](http://www.scientificamerican.com/article.cfm?id=is-space-digital) [数据范围](https://wiki.pha.jhu.edu/escience_wiimg/7/7f/DataScope.pdf) 旨在成为镜头。 +不幸的是，尽管某些服务（如 Route53 和 S3）最终对我们来说确实非常有用且非常稳定，但使用 EC2 的决定却在我们成立的第一年困扰了团队一些主要问题。 -详细的 [论文](https://wiki.pha.jhu.edu/escience_wiimg/7/7f/DataScope.pdf) 进一步说明了它的含义： +Swiftype 的客户需要卓越的性能和始终可用的可用性，而我们能否提供这些功能在很大程度上取决于我们基础架构的稳定性和可靠性。 在 Amazon 中，我们**遇到了网络问题，VM 实例挂起，不可预测的性能下降（可能是由于嘈杂的邻居共享我们的硬件**，但没有办法知道）以及许多其他问题。 无论我们遇到什么问题，亚马逊始终有相同的解决方案：通过购买冗余或高端服务向亚马逊支付更多钱。 -> 数据范围是一种新型的科学工具，能够“观察”来自各个科学领域的大量数据，例如天文学，流体力学和生物信息学。 系统将具有超过 6PB 的存储空间，每秒约 500GB 的聚合顺序 IO，约 20M IOPS 和约 130TFlops。 Data-Scope 不是传统的多用户计算集群，而是一种新型仪器，使人们能够使用 100TB 至 1000TB 之间的数据集进行科学研究。 如今，数据密集型科学 计算中存在真空，类似于导致 BeoWulf 集群发展的过程：基于商品组件的廉价而高效的模板，用于学术环境中的数据密集型计算。 拟议的数据范围旨在填补这一空白。 +我们花在解决 EC2 问题上的**时间越多，我们为客户开发新功能**的时间就越少。 我们知道可以使我们的基础架构在云中工作，但是要做的工作，时间和资源远比迁移要大得多。 -Nicole Hemsoth 对 Data-Scope 团队负责人 Alexander Szalay 博士的访问非常方便，可以在 [计算的新时代：《 Data 博士》](http://www.datanami.com/datanami/2012-01-23/the_new_era_of_computing:_an_interview_with_dr._data.html) 。 Roberto Zicari 在 [空间物体与 Facebook 好友](http://www.odbms.org/blog/2011/04/objects-in-space-vs-friends-in-facebook/) 中也对 Szalay 博士进行了很好的采访。 +经过一年的云斗争，**我们决定将 EC2 保留为真正的硬件**。 幸运的是，这不再意味着要购买您自己的服务器并将它们放在机架中。 托管主机提供商有助于物理硬件，虚拟实例和快速配置之间的良好平衡。 鉴于我们以前在托管服务提供商方面的经验，我们决定选择 SoftLayer。 他们出色的服务和基础架构质量，供应速度以及客户支持使其成为我们的最佳选择。 -本文针对其硬件选择和体系结构提供了许多非常具体的建议，因此，请阅读本文以获取更深入的信息。 许多 BigData 操作都具有 Data-Scope 正在解决的相同 IO /规模/存储/处理问题，因此非常值得一看。 以下是一些要点： +经过一个多月的辛苦工作，准备进行数据中心间迁移，我们能够以零停机时间执行迁移，并且对客户没有负面影响。 **从第一天开始，向真实硬件的迁移就极大地改善了服务的稳定性，为所有关键基础架构组件带来了巨大的（〜2 倍）性能提升，并将每月托管费用降低了约 50％**。 -* 高性能系统的计算能力和 I / O 能力之间的距离越来越大。 随着多核和基于 GPU 的混合系统的规模不断扩大，我们正在讨论明年的许多 Petaflops -* 该系统将传统磁盘驱动器的高 I / O 性能与少量具有高性能 GPGPU 卡和 10G 以太网互连的超高吞吐量 SSD 驱动器集成在一起。 -* 我们需要具有以比今天更大的 I / O 带宽进行读取和写入的能力，并且我们还需要能够以非常高的聚合速率处理传入和传出的数据流。 -* 通过使用直接连接的磁盘，消除了存储系统中的许多系统瓶颈，在磁盘控制器，端口和驱动器之间取得了良好的平衡。 如今，构建便宜的服务器并不难，廉价的商业 SATA 磁盘每台服务器可以流超过 5GBps。 -* GPGPU 非常适合于数据并行 SIMD 处理。 这正是许多数据密集型计算的目的。 将 GPGPU 与快速本地 I / O 并置的构建系统将使我们能够以每秒数 GB 的速度将数据流传输到 GPU 卡，从而充分利用其流处理功能。 -* 在健康的生态系统中，所有事物都是 1 / f 幂定律，[在数据库选项中]我们将看到更大的多样性。 -* 它需要一种整体方法：必须首先将数据带到仪器，然后进行分段，然后再移到同时具有足够的计算能力和足够的存储带宽（450GBps）来执行典型分析的计算节点上， （复杂）分析必须执行。 -* 人们普遍认为索引是有用的，但是对于大规模数据分析而言，我们不需要完整的 ACID，交易带来的负担多于好处。 -* 实验和仿真数据正在快速增长。 数据集的大小遵循幂定律分布，并且在这种分布的两个极端都面临着巨大的挑战。 -* 不同架构组件的性能以不同的速率提高。 - * CPU 性能每 18 个月翻一番 - * 磁盘驱动器的容量正在以类似的速度增加一倍，这比原始 Kryder 定律的预测要慢一些，这是由更高密度的磁盘驱动的。 - * 在过去十年中，磁盘的旋转速度几乎没有变化。 这种差异的结果是，虽然顺序 IO 速度随密度增加，但随机 IO 速度仅发生了适度的变化。 - * 由于磁盘的顺序 IO 和随机 IO 速度之间的差异越来越大，因此只能进行顺序磁盘访问-如果 100TB 的计算问题主要需要随机访问模式，则无法完成。 - * 即使在数据中心，网络速度也无法跟上数据大小翻倍的步伐。 -* PB 级数据，我们无法将数据移动到计算所在的位置，而必须将计算引入数据中。 -* 现有的超级计算机也不太适合进行数据密集型计算。 它们最大程度地延长了 CPU 周期，但缺少大容量存储层的 IO 带宽。 而且，大多数超级计算机缺乏足够的磁盘空间来存储多个月期间的 PB 大小的数据集。 最后，至少在今天，商业云计算平台不是答案。 与购买物理磁盘相比，数据移动和访问费用过高，它们提供的 IO 性能明显较低（〜20MBps），并且提供的磁盘空间数量严重不足（例如，每个 Azure 实例约 10GB）。 -* 硬件设计 - * 数据范围将包含 90 个性能和 12 个存储服务器 - * 数据范围设计背后的驱动目标是，在使用商品组件保持较低购置和维护成本的同时，最大化 TBsize 数据集的流处理吞吐量。 - * 直接在服务器的 PCIe 背板上执行数据的首次传递比将数据从共享的网络文件服务器提供给多个计算服务器的速度要快得多。 - * Data-Scope 的目标是提供大量廉价和快速的存储。 没有满足所有三个条件的磁盘。 为了平衡这三个要求，我们决定将仪器分为两层：性能和存储。 每一层都满足两个标准，而第三层则有所妥协。 - * Performance Server 将具有高速和廉价的 SATA 驱动器，但会影响容量。 - * 存储服务器将具有更大但更便宜的 SATA 磁盘，但吞吐量较低。 存储层的磁盘空间增加了 1.5 倍，以允许数据分段以及往返于性能层的数据复制。 - * 在性能层中，我们将确保可达到的聚合数据吞吐量保持在理论最大值附近，该最大值等于所有磁盘的聚合顺序 IO 速度。 每个磁盘都连接到一个单独的控制器端口，并且我们仅使用 8 端口控制器来避免控制器饱和。 我们将使用新的 LSI 9200 系列磁盘控制器，该控制器提供 6Gbps SATA 端口和非常高的吞吐量 - * 每个性能服务器还将具有四个高速固态磁盘，用作临时存储的中间存储层和用于随机访问模式的缓存。 - * 性能服务器将使用 SuperMicro SC846A 机箱，具有 24 个热交换磁盘托架，四个内部 SSD 和两个基于 GTX480 Fermi 的 NVIDIA 图形卡，每个图形卡具有 500 个 GPU 内核，为浮点运算提供了出色的性价比。 每张卡估计可运行 3 teraflops。 - * 在存储层中，我们将容量最大化，同时保持较低的购置成本。 为此，我们使用带有 SATA 扩展器的背板在尽可能多的磁盘中分摊主板和磁盘控制器，同时仍为每台服务器保留足够的磁盘带宽以进行有效的数据复制和恢复任务。 我们将使用本地连接的磁盘，从而使性能和成本保持合理。 所有磁盘都是可热交换的，从而使更换变得简单。 一个存储节点将由 3 个 SuperMicro SC847 机箱组成，一个包含主板和 36 个磁盘，另外两个包含 45 个磁盘，总共 126 个驱动器，总存储容量为 252TB。 -* 鉴于可移动媒体（磁盘）的改进速度快于网络，因此，sneakernet 将不可避免地成为大型临时还原的低成本解决方案， -* 我们为仪器中的数据设想了三种不同的生命周期类型。 首先是永久性数据，海量数据处理管道以及对超大型数据集的社区分析。 +本文将解释我们如何计划和实施迁移过程，详细介绍在过渡后我们看到的性能改进，并为年轻的公司提供有关何时执行此操作的见解。 -## 相关文章 +## 准备交换机 -* [计算的新纪元：《数据博士》专访](http://www.datanami.com/datanami/2012-01-23/the_new_era_of_computing:_an_interview_with_dr._data.html) -* [MRI：数据范围的发展–科学的多 PB 通用数据分析环境](https://wiki.pha.jhu.edu/escience_wiimg/7/7f/DataScope.pdf) -* [GrayWulf：用于数据密集型计算的可伸缩群集体系结构](http://research.microsoft.com/apps/pubs/?id=79429) -* [空间中的对象与 Facebook 中的好友](http://www.odbms.org/blog/2011/04/objects-in-space-vs-friends-in-facebook/) ，作者：Roberto V. Zicari -* [极限数据密集型计算](http://salsahpc.indiana.edu/tutorial/slides/0726/szalay-bigdata-2010.pdf) -* [Alex Szalay 主页](http://www.sdss.jhu.edu/~szalay/) +迁移之前，我们在 Amazon EC2 上有大约 40 个实例。 我们每周至少 2-3 次（有时每天）会遇到严重的生产问题（实例中断，网络问题等）。 一旦决定迁移到真正的硬件，我们就知道我们的工作已经完成，因为我们需要在不中断服务的情况下切换数据中心。 准备过程涉及两个主要步骤，每个步骤在下面的单独部分中都有专门的解释： -两个注意事项： +1. **连接 EC2 和 SoftLayer** 。 首先，我们在 SoftLayer 的数据中心中构建了新基础架构的骨架（最小的服务器子集，能够以开发级的负载运行所有关键的生产服务）。 一旦建立了新的数据中心，我们就会在新旧数据中心之间建立一个 VPN 隧道系统，以确保两个数据中心中组件之间的透明网络连接。 -1.由于耐用性极低，因此无法在缓存方案中使用消费者 SSD（Vertex 2）。 企业级 SSD 是这里必不可少的 -2。对于在新项目中将使用哪种类型的文件系统（分布式），请不要多说。 5PB 的存储空间，FS 上没有任何单词。 +2. **对我们的应用程序**的架构更改。 接下来，我们需要对应用程序进行更改，以使它们既可以在云中也可以在我们的新基础架构上运行。 一旦应用程序可以同时存在于两个数据中心中，我们便建立了一条数据复制管道，以确保云基础架构和 SoftLayer 部署（数据库，搜索索引等）始终保持同步。 -很棒的文章和有趣的项目！ +### 步骤 1：将 EC2 和 Softlayer 连接 -请注意，“有关 Data-Scope 的详细*文件* ...”中缺少该链接，现在具有：about：blank。 +为迁移做准备的第一件事之一就是弄清楚如何将 EC2 和 SoftLayer 网络连接在一起。 不幸的是，使用 EC2 的虚拟私有云（VPC）功能将一套 EC2 服务器连接到另一个专用网络的“正确”方法对我们来说不是一种选择，因为如果没有以下方法，我们无法将现有实例集转换为 VPC 停机时间。 经过一番考虑和周密的计划，我们意识到，真正需要能够跨越数据中心边界相互连接的唯一服务器是我们的 MongoDB 节点。 我们可以做的其他所有事情都可以使数据中心本地化（Redis 群集，搜索服务器，应用程序群集等）。 -否则，一篇很好的文章。 +![diagram_1.png](img/db67558249d985fb5bb46058eabda8ee.png) -帕特里克 \ No newline at end of file +由于我们需要互连的实例数量相对较少，因此我们实施了一个非常简单的解决方案，事实证明，该解决方案对于我们的需求是稳定且有效的： + +* 每个数据中心中都部署了专用的 OpenVPN 服务器，该服务器将所有客户端流量 NAT NAT 到其专用网络地址。 + +* 每个需要能够连接到另一个数据中心的节点都将在此处建立 VPN 通道并设置本地路由，以将指向另一个 DC 的所有连接正确转发到该隧道。 + +以下功能使我们的配置非常方便： + +* 由于我们没有控制任何一方的网络基础架构，因此我们无法真正迫使任一端的所有服务器通过连接到另一个 DC 的中央路由器来集中其流量。 在我们的解决方案中，每个 VPN 服务器（在某种自动化的帮助下）决定通过隧道路由哪些流量，以确保所有客户端的完整 DC 间连接。 + +* 即使 VPN 隧道崩溃了（令人惊讶的是，这仅在项目的几周内发生了几次），这仅意味着一台服务器失去了与另一 DC 的传出连接（一个节点从 MongoDB 集群中退出，有些 工作服务器将失去与中央 Resque 框的连接，等等）。 那些一次性的连接丢失不会影响我们的基础架构，因为所有重要的基础架构组件的两端都具有冗余服务器。 + +### 步骤 2：对我们的应用程序进行架构更改 + +在准备迁移的几周内，我们必须对基础架构进行许多小的更改，但是对它的每个组成部分都有深刻的了解有助于我们做出适当的决策，从而减少了过渡期间发生灾难的可能性 。 我认为，几乎所有复杂性的基础架构都可以通过足够的时间和工程资源进行迁移，以仔细考虑在应用程序和后端服务之间建立的每个网络连接。 + +![diagram_2.png](img/a6eaf06da9cd2cef1e72de6700d336fa.png) + +以下是我们为确保平稳透明迁移所必须采取的主要步骤： + +* 所有无状态服务（缓存，应用程序集群，Web 层）均独立部署在每一侧。 + +* 对于每个有状态后端服务（数据库，搜索集群，异步队列等），我们都必须考虑是否要（或可以负担得起）将数据复制到另一端，或者是否必须引起数据中心间的延迟 对于所有连接。 一直以来，依靠 VPN 一直是最后的选择，最终我们能够将数据中心之间的流量减少到一些小的复制流（主要是 MongoDB）以及与无法复制的服务的主/主副本的连接 。 + +* 如果可以复制服务，则可以这样做，然后使应用程序服务器始终使用或偏爱该服务的本地副本，而不是转到另一端。 + +* 对于我们无法使用其内部复制功能进行复制的服务（例如我们的搜索后端），我们对应用程序进行了更改，以实现数据中心之间的复制，在此数据中心的每一侧的异步工作人员都将从各自的队列中提取数据， 总是将所有异步作业都写入两个数据中心的队列中。 + +### 步骤 3：翻转开关 + +当双方都准备好为 100％的流量提供服务时，我们通过将 DNS TTL 降低到几秒钟来确保快速的流量变化，为最终的切换做好了准备。 + +最后，我们将流量切换到新的数据中心。 将请求切换到新基础架构，对客户的影响为零。 一旦流向 EC2 的流量耗尽，我们便禁用了旧数据中心，并将所有剩余的连接从旧基础结构转发到了新基础结构。 DNS 更新需要时间，因此在截止时间之后至少一周的时间内，我们的旧服务器上会看到一些剩余流量。 + +### 明显的改进：从 EC2 迁移到实际硬件后的结果 + +**稳定性提高了**。 每周我们要避免 2-3 次严重的故障（大多数故障对于客户而言是不可见的，因为我们尽了最大的努力使系统能够应对故障，但是许多故障会唤醒某人或迫使某人放弃家庭时间） 每月 1-2 次中断，我们可以通过花费工程资源来提高系统对故障的适应性，并减少故障对我们客户可见的可用性产生影响的机会，从而更彻底地处理故障。 + +**性能提高了**。 多亏了 SoftLayer 提供的现代硬件，我们看到了所有后端服务（尤其是 IO 绑定的服务，例如数据库和搜索集群，但也有 CPU 绑定的应用程序服务器）的性能持续提高，更重要的是， 性能更可预测：没有与我们的软件活动无关的突然下降或上升。 这使我们可以开始进行实际容量规划，而不必在所有性能问题上抛出更慢的实例。 + +**成本降低**。 最后，但同样重要的是，对于一家年轻的初创公司而言，我们的基础架构每月成本下降了至少 50％，这使我们能够过度配置某些服务，从而进一步提高性能和稳定性，从而使客户受益匪浅。 + +**供应灵活性提高了，但是供应时间却增加了**。 现在，我们可以精确地指定服务器以满足其工作量（大量磁盘并不意味着我们需要功能强大的 CPU）。 但是，我们无法再通过 API 调用在几分钟内启动新服务器。 SoftLayer 通常可以在 1-2 个小时内将新服务器添加到我们的机队中。 对于某些公司来说，这是一个很大的折衷，但是对于 Swiftype 来说，这是一个很好的选择。 + +## 结论 [ + +自从改用真正的硬件以来，我们有了长足的发展-我们的数据和查询量增长了 20 倍-但我们的 API 性能比以往任何时候都要好。 确切了解服务器的性能将使我们以前所未有的方式规划增长。 + +根据我们的经验，当您需要快速启动新硬件时，云可能是个好主意，但只有在您做出巨大努力（Netflix 级）以在其中生存时，它才能很好地工作。 如果您的目标是从一开始就建立企业，而您又没有多余的工程资源可用于支付“云税”，那么使用真实的硬件可能是一个更好的主意。 + +*如果您对软件和基础架构交叉领域的工程技术充满热情，Swiftype 将聘请高级技术运营工程师。* + +[关于黑客新闻](https://news.ycombinator.com/item?id=9212467) + +[上 reddit](http://www.reddit.com/r/programming/comments/2z9xwp/how_and_why_swiftype_moved_from_ec2_to_real/) + +很棒的文章。 我只需要添加 Google 工程师的一些明智的话即可（我忘了看到它的地方，但一定是演示文稿）：不要期望在距离上同步复制数据。 编码应用程序以解决此问题是更好的方法。 您可能会失去性能，但最终不会出现数据不一致的情况 + +嗨，有趣的文章，您使用的实例类型和操作系统是什么？ 您使用的是原始 AMI 还是其他东西？ + +每当我看到公司何时离开亚马逊并经历成本下降时，我都会大笑和哭泣：)我来自波兰，但是许多国家/地区都有自己的云服务提供商，因此每个人都应该检查他们，然后再寻求更大的参与者。 我为数百个客户和平均值进行了许多计算。 波兰云与亚马逊的成本比较表明，亚马逊的价格比我选择的提供商高 7 到 20 倍。 我知道这些提供商无法扩展到 1000Gbps 或 PB 数据，但是如果人们遇到网络问题和性能下降，他们仍然使用如此糟糕的提供商真是可笑。 + +我为几天的活动做了很多设置，并且它总是像魅力一样发挥作用。 两种设置工作了几个月（一切都按计划进行），我没有遇到任何问题。 + +你们有什么特殊的原因要选择 DigitalLacean 而不是 SoftLayer。 根据 DigitalOcean 网站的性能基准，它们便宜 90％，但性能更好。 + +只是好奇。 + +有趣的帖子，Oleksiy。 我自己广泛使用 EC2 和 Softlayer，得出了不同的结论。 + +Softlayer 的后端网络并不如我所愿稳定。 我曾尝试在其中运行分布式文件系统（例如 glusterfs），但不得不放弃-网络太不可靠了。 尽管值得，但 Ceph 能够更好地应对夜晚的颠簸，但它们仍然存在。 + +上次我检查（最近几个月内）无法从 SL 获得 10G 网络。 它来自 EC2。 此外，如果您自己想要一台服务器，这是相当普遍的常识，您可以在 EC2 上配置哪些实例大小。 + +很高兴到目前为止您的客户服务经验非常好。 物理服务器的问题之一是发生故障，并且在租用服务器时，您会被这些位卡住。 打开故障单，尝试更换驱动器/任何部件，希望支持技术人员能够充分了解并进行处理，而不是尝试进行故障排除并告诉您系统是否正常。 我建议您记住短语“请升级”，并毫不犹豫地使用它。 在云环境中，您将启动一个新实例并恢复工作，让其他人处理硬件问题。 + +也就是说，与 EC2 相比，通过电话从 SL 中找到某人要容易得多。 :) + +您没有提到的一件事是，如果您想在 SL 获得合理的价格，则需要从销售代表处获取报价。 根据我的经验，这通常会大大降低系统的价格。 + +我认为最重要的是，如果您要为云构建应用程序，则需要设计一个解决方案，该解决方案在 Amazon 重新启动您所使用的系统时不会崩溃。 但是，这不是唯一的情况-实例崩溃比服务器崩溃要痛苦得多。 + +很高兴为您解决！ + +众所周知，Netflix 拥有 EC2 上所有最好的服务器。 他们引导 30,000 台计算机并运行性能测试，然后仅保留前 5％的数据并关闭所有其他实例。 但是，请注意，您的开发团队可能经验不足，无法充分利用 EC2。 Netflix 和 Reddit 在 EC2 上运行没有问题。 + +当您谈到降低成本时，你们与 SoftLayer 达成任何特别交易，合同等吗？ 还是仅通过支付公共价格表就可以从 AWS 跳到 SoftLayer？ + +由于 Softlayer 确实是 IBM 的事实，他们可能确实获得了更好的交易。 + +我认为对于 Netflix 和 reddit，他们肯定可以通过联系人访问特殊服务器。 + +我不确定为什么甚至可以与数字海洋进行比较，我们不要忘记 softlayer 托管了 whatsapp。 + +对于如此大的环境，停机率令我感到惊讶。 该基础结构是作为现代临时和自动伸缩堆栈实现的，还是传统堆栈设计？ 我已经管理了 AWS 中成千上万个节点的平台，故障率低得多。 + +没有任何基础设施是完美的。 我想知道该平台在传统环境中的长期故障率，尤其是 MTTR。 此外，在较慢的物理环境中进行创新的机会成本是多少？ + +我们在 EC2 上运行了 14K 实例。 如果仅在 40 个实例上看到 VM 挂起等问题，则不确定部署是否正确。 这种迁移对于小型环境是可行的。 除了 AWS 或自己推出自己的服务以外，没有太多其他用于大规模操作的选项 + +我希望您也杀了您的主要帐户。 :) \ No newline at end of file diff --git a/docs/165.md b/docs/165.md index ac7c548..8d3d935 100644 --- a/docs/165.md +++ b/docs/165.md @@ -1,140 +1,350 @@ -# Etsy Saga：从筒仓到开心到一个月的浏览量达到数十亿 +# 我们如何扩展 VividCortex 的后端系统 -> 原文： [http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html) +> 原文： [http://highscalability.com/blog/2015/3/30/how-we-scale-vividcortexs-backend-systems.html](http://highscalability.com/blog/2015/3/30/how-we-scale-vividcortexs-backend-systems.html) -![](img/9e364140091b80d83d988a6634e2f7c6.png) +![](img/3bd3303bcbae5781c18559acca255282.png) -我们很少听到有关流行网站在其形成时期所获得的颠簸和擦伤的故事。 [Etsy 的高级软件工程师 Ross Snyder](http://ross-snyder.com/) 通过在 [Surge 2011](http://omniti.com/surge/) ：[扩展 Etsy：什么地方出错了，什么地方正确了](http://www.youtube.com/watch?v=eenrfm50mXw)。 +*这是 [Baron Schwartz](https://twitter.com/xaprb) ， [VividCortex](https://vividcortex.com/about-us/) 的创始人& CEO 的来宾帖子，这是专门为当今的大型，多语种持久层设计的首个统一的性能管理工具套件 。* -罗斯详细而诚实地描述了 Etsy 从 2005 年的原始创业公司到 2007 年为成功而苦苦挣扎的创业公司，再到 2011 年成为普通的手工，超级缩放，ops 驱动的机器。 +VividCortex 是用于数据库性能管理的云托管 SaaS 平台。 我们的客户安装了代理，以衡量其服务器执行的工作（查询，流程等），并从中频繁地生成度量和事件。 代理将结果数据发送到我们的 API，在此托管我们的分析后端。 后端系统是数据库，内部服务（准微服务）和面向 Web 的 API 的集合。 这些 API 也为我们的 AngularJS 前端应用程序提供了动力。 -从这个富有启发性的变革故事中可以学到很多东西： +我们处理大量数据。 我们高速摄取指标和事件。 我们还执行以交互方式接触大量数据的分析。 我们不是唯一的，我不想暗示我们在事物计划方面给人留下深刻的印象。 我们尚未以“网络规模”运作。 尽管如此，我们的工作负载具有一些相对不寻常的特征，我们已经能够扩展到最大程度，同时在成本和基础架构方面仍然保持相当高的效率。 我的咨询生涯告诉我，建立这样的系统通常对公司来说是一个挑战（对我们来说一直如此）。 我们的故事可能对其他人有用。 因此，我将不必要地详细介绍工作负载的特定部分及其带来的挑战。 -## 起源故事 +## 我们所做的 -* [Etsy](http://www.etsy.com/) 是手工制品的市场。 他们与买卖双方建立联系，类似于 eBay，他们不处理商品。 -* 开始时间：2005 年 6 月， [3 个人住在一个​​公寓里](http://www.seomoz.org/web2.0/interview/etsy/2006)。 -* 如今：250 名员工，每月浏览量达数十亿。 总共 6 年。 +VividCortex 是一个复杂的系统，具有很多功能，但是热门查询（以及我们为实现此目的而捕获的数据）很容易成为对我们的后端产生重大影响的最重要的功能。 热门查询是一个查询类别的表，按所选维度从大到小排列，并显示一个综合行，该行显示的类别不符合前 N 个。 -## 2007 年–当时的架构 +[![top-queries](img/83a1ff858257bc3a2449da40823c3587.png)](https://camo.githubusercontent.com/2f0d8f8246190511ec9d7a5b99ed48b3d939fdc1/68747470733a2f2f636c6f75642e67697468756275736572636f6e74656e742e636f6d2f6173736574732f3237393837352f363838393234382f38353663663566612d643636302d313165342d383565312d6131393330653962636139662e706e67) -* Ubuntu，PostgreSQL，lighttpd，PHP，Python -* PostgreSQL 存储过程中全部包含业务逻辑。 一次非常常见的体系结构。 -* 前端使用包装在 PHP 中的存储过程调用与数据库进行了交互。 -* 大型中央数据库，具有按功能进行分区。 分区给他们买了一些时间。 -* 网站正常运行时间不是很好，这需要为电子商务网站付费。 -* 定期维护窗口意味着该站点将定期关闭。 -* 大爆炸软件部署通常会导致中断。 +屏幕截图（顺便说一下，来自我们自己的工作量）显示了此功能，并精简了其基本功能。 热门查询实际上是我们的应用程序可以实现的一般任务类别的特定示例：您可以对查询，用户，流程，数据库等的度量进行排名，排序，过滤，切片和切块。 您可以同时在一台或多台主机上执行此操作，因此可以获取全局视图，然后向下钻取到特定主机或主机组。 您可以从许多不同的维度中进行选择。 所有这些本质上都采用度量类别，并按维度对其进行排名，保留前 N 个，最后将其余的折叠到所有行中。 -## 2008-失败的 Sprouter 实验 +我们还有很多其他的事情要做，但大多数事情在后端实现方面与许多指标和监视系统所做的并没有很大不同。 与“热门查询”相比，这不是一项重大的工程挑战。 -* 现阶段仍是一家初创企业，最高人数为 20-30 人。 -* 康威定律：当团队生产产品时，产品最终类似于生产产品的团队。 - * 团队看起来像：开发人员，DBA，运营人员。 开发人员编写代码，DBA 编写存储的 proc，Ops 部署的代码。 一个筒仓组织，团队之间有很多墙。 -* 为了解决其可伸缩性问题，他们创建了中间件层，称为 Sprouter-存储过程路由器。 -* Sprouter 是位于 Web 服务器和数据库之间的 Python 守护程序。 给它一些参数，它调用存储过程，并返回结果。 从理论上讲，它可以进行一些缓存和分片，但是这些功能并未实现。 -* 希望 Sprouter 比数据库更容易扩展，因为围绕存储过程构建的体系结构几乎是不可能的。 -* 已于 08 年秋季准备就绪。自 09 年起弃用，此方法无效。 -* Sprouter 仍然是一个筒仓架构，类似于他们拥有的团队。 - * 由于 DBA 忙于所有数据库工作，这给开发人员带来了很多麻烦，这与时间表的依赖关系很大。 请记住，只有 DBA 才能进行数据库工作。 - * 已弃用 Ops 仍必须处理依赖项。 事实证明，Sprouter 依赖于 Python 的早期版本，这意味着他们无法升级 Python。 因此，有很多运营开销。 - * 由于 Sprouter 缓存了存储过程标识符（在升级期间无效），因此 Made 的部署情况更糟。 部署几乎每次都中断。 - * 没有分片，数据库仍然是单点故障。 +## 时间序列数据 -## 2008 年-大文化转变 +我们的时间序列指标是属于序列的带有时间戳的 float64 值。 该系列由度量标准名称和测量它们的主机标识。 时间戳当前是 UTC 中的 uint32 UNIX 时间戳。 -* [Chad Dickerson](http://blog.chaddickerson.com/) 被聘为首席技术官，后来成为首席执行官。 他带来了新的文化，以前的文化不再存在于 Etsy。 -* 删除旧文化也被删除： - * 致力于 PostgreSQL 和存储过程。 - * 担心开发人员使用 SQL 编码。 - * 通常，开发人员都不会接触该产品。 - * 不频繁和大型部署是将代码移入生产环境的想法。 - * 美国国立卫生研究院的一般态度。 +指标名称是点分隔的字符串。 我们从许多来源收集了大量指标，所有指标均以 1 秒为单位。 -## 2009 年春季-前进的方式：第 1 部分 +* 每个数据库状态指标。 例如，对于 MySQL，这包括来自 SHOW STATUS 的数百个计数器，以及来自其他来源的数百个计数器。 +* 每个 CPU，每个网络设备以及每个块/磁盘设备，内存等的操作系统指标。 +* 操作系统中的进程级别指标，包括每个进程的 CPU，内存，IO，打开的文件句柄，网络套接字等。 -* DevOps 救援 - * DevOps 是同时也是工程师和 Ops 的 Ops 人员。 - * 筒仓变坏了。 - * 信任，合作，透明和共同承担责任变得良好。 - * 我们在一起。 让我们互相帮助，共同完成任务。 +但最重要的是，我们嗅探网络流量并解码流行数据库产品的有线协议。 目前，我们提供针对 MySQL 和 PostgreSQL 的 GA 支持，Redis 和 MongoDB 处于 beta 测试阶段，并且还有更多。 我们测量入站查询（或视情况而定的请求/命令/等；因产品而异）和响应延迟时间，并提取各种有用的细节（例如错误等）。 在无法监听网络的情况下，可以使用内置的工具，例如 MySQL 的`PERFORMANCE_SCHEMA`和 PostgreSQL 的`pg_stat_statements`视图。 这使我们能够支持诸如 Amazon RDS 之类的部署方案。 -* 稳定网站： - * **安装/改进指标并监视**。 - * 尽可能垂直升级数据库。 还是不够，但是买了一些呼吸的空间。 - * 使开发人员生产**访问正在运行的代码**，以便他们可以帮助解决问题。 开发了一个名为 [StatsD](https://github.com/etsy/statsd) 的工具。 虽然并非所有开发人员都扎根于生产机器。 +> 顺便说一句，捕获这些数据本身会带来有趣的问题，并且我们之前已经在博客上进行了介绍（两个示例： [netlink](https://vividcortex.com/blog/2014/09/22/using-netlink-to-optimize-socket-statistics/) 和 [perf 模式](https://vividcortex.com/blog/2014/11/03/mysql-query-performance-statistics-in-the-performance-schema/)）。 在这里，Go 是我们的一大财富。 -## 持续部署-前进的方向：第 2 部分 +最明显的挑战可能是我们收集的系列数量之多。 我们通过消化可变部分，然后对抽象查询进行 md5sum，将相似查询分类。 我们对此进行十六进制编码（对此我感到遗憾并为自己负责，这是一个愚蠢的决定），并将结果嵌入到指标名称中，例如 `host.queries.c.1374c6821ead6f47.tput`。 最后一个要素是维度，在这种情况下，是吞吐量（每秒的速率），但是它可能是诸如延迟，错误率，受影响的行数之类的许多东西之一。 此特定度量标准名称中的可变部分是`c`，它表示这是什么类型的操作（查询，准备好的语句执行等）和`1374c6821ead6f47`，它是摘要查询的校验和。 -* 添加了**连续部署**。 Etsy 中的任何工程师都可以随时将整个站点部署到生产中。 每天发生 25 次，因为它很容易。 这是**一键部署**。 -* 开发了一个名为 [Deployinator](https://github.com/etsy/deployinator) 的工具。 **Chef** 用于配置管理。 -* 最大的收获是，**小更改集**一直在淘汰，而不是大规模部署。 如果出现问题，他们可以迅速找出问题所在并加以解决。 -* 添加了对代码运行的测试，以在部署之前验证代码是否正常运行。 -* 小组**始终在 **IRC** 上与彼此**进行交谈。 -* **质量检查由开发人员**执行。 在此过程中，没有单独的质量检查小组或阶段。 开发人员负责确保代码可靠。 较小的变更集使此操作变得容易。 -* 在持续不断的部署过程中，数据库架构更改是异常的。 他们每周有一天，即**模式更改日**。 功能标志用于打开和关闭功能，因此它们可以翻转标志，并且架构在适当的位置可以打开标志。 -* A / B 测试方案允许仅为管理员打开功能或将其发布给一定比例的用户。 他们创建一个**功能标记**，提交一堆代码，然后打开该标记，以便只有开发人员才能看到它。 -* 每年的一周内，每个开发人员都在寻求**支持。 他们将在假期前后加倍。 Ops 有自己的轮换方式，因此开发人员和 Ops 总是随时待命。** +您可能会猜到，度量标准名称的可变部分可能是高基数的。 我们的一些客户生成了数千万种不同类型的查询，这导致时间序列的组合爆炸式增长。 在最坏的情况下，它是度量标准名称的每个可变部分的叉积，通常包括 2、3、4 或有时更多的可变部分。 -## 2009 年春季-Sprouter 之死-前进的方向：第 3 部分 +我们还生成并存储许多其他数据。 关于查询之类的描述性指标还不够。 我们通过查询事件本身和各种其他事件（例如，为响应系统故障或配置更改而引发的事件）的单个样本来补充这一点。 事实证明，对这些数据进行缩放并不像时间序列度量标准那么困难，这主要是因为这些数据的读取工作负载并不难于扩展。 -* 使用**对象关系映射器**绕过 Sprouter。 他们写了自己的。 -* 现在（再次），前端 PHP 代码通过 ORM 直接与数据库对话。 -* 使用 ORM 将一些工作转移到了易于扩展的 Web 服务器上。 -* ORM 进行一些前端缓存。 -* ORM 是一个臭名昭著的瓶颈，但还没有解决这个问题，但他们意识到了这一潜力。 +## 写工作量 -## 分片的到来-前进的方向：第 4 部分 +按原始事实存储量，后端的写入工作量中最大的部分是时间序列指标。 查询样本和事件在磁盘上构成了很多数据，但这是因为它比时间序列数据紧凑得多。 许多小数据比中等数量的大数据更难处理。 -* 在 Sprouter 被中和后，数据库仍然是单点故障。 -* 由于 **Flickr** 的很多人都去了 Etsy，因此他们采用了 Flickr 的[分片方案。](http://highscalability.com/flickr-architecture) -* 基于 **MySQL** 作为简单的数据存储。 **经过 Flickr 的战斗测试**。 -* 将数据库**沿水平方向**缩放到无穷远甚至更大。 -* **主-主**复制用于删除 SPOF。 +数据库内部和存储引擎的学生将了解，读取优化存储和写入优化存储在某些方面存在冲突。 如果要读取优化的数据，则可能需要在写入时进行额外的工作。 我们绝对需要一些读取优化，您将在后面看到。 -## 2011 年春季-关闭 Sprouter +写入特性非常简单：数据按时间戳顺序到达，而主要的挑战只是将其持久化以及读取优化所需的放大。 如您所见，我们做了很多事情来回避这一点。 -* Sprouter 使用停止所有策略释放。 当人们在基础架构上工作时，功能开发几乎停止了，大型部署在您的面前爆炸了。 -* 为了证明文化是如何发生变化的，有几个人在一边进行 Sprouter 的替换，然后他们**逐渐逐步使用**。 即使他们愿意，他们也不能只专注于 Sprouter。 -* 终于在 2011 年春季，从代码库中删除了 Sprouter。 +我们将 1 秒分辨率的数据存储 3 天。 我们还将下采样分辨率降低到 1 分钟，并保持更长的时间。 两种保留限额均可在客户合同中协商。 在我们自己的系统中，我们保留 10 天的 1 秒分辨率。 -## 2011-现在的 Etsy 体系结构 +## 读取工作量 -* CentOS，MySQL，Apache，PHP。 -* **逐步淘汰 PostreSQL** 。 仍然没有完成。 迁移基于每个功能。 -* **Python 不见了**。 他们需要让人们参与进来，以便在 PHP 和 MySQL 上实现标准化。 +我们的时间序列指标有两个主要的读取工作负载。 它们揭示了关于数据库的普遍真理之一：许多不同类型的数据通常可以放入数据库中，甚至是专用数据库。 对于完全不同的目的而言，彼此相邻的数据位可能很重要，并且涉及到完全不同的问题的答案。 这是要提防的。 -## 获得的经验教训 +工作负载 1（我称为范围读取）是在一个时间范围内以所需的分辨率读取一个或多个单独指定的指标。 一个明显的例子是绘制一个具有单个度量标准的时间序列图：宽 600 像素，上周的数据； 在时间戳 1426964208 和 1427569008 之间以主机 100 的 600 个间隔向我提供来自主机 Y 的度量 X。 原则上，读取路径并不十分复杂：找出数据所在的位置以及适合的分辨率（在这种情况下，可以使用 1 分钟的数据），找到起点，并读取终点直到终点 。 根据需要重新采样并将其流回客户端。 -* **开放和信任**比封闭和恐惧好得多。 -* 如果您聪明地执行**，则可能是错误的**。 如果您打算扩展规模，请不要冒险使用未经测试的前端到数据库交互方法。 Etsy 是一个电子商务网站，他们没有向月球发射火箭。 他们在做什么并没有那么大的争议，但这也不是那么普遍。 -* 在您离开后很长时间，今天做出的架构决策将产生重大影响。 -* 没有漏洞那么深，以至于可靠的缩放策略无法将您排除在外。 -* 没有前进的道路。 没有计划。 在文化转变开始后的几年中，这种情况逐渐发生。 - -尽管 Etsy 并未完全履行其 NIH 承诺，但由于他们自己构建了大多数内容，因此有关团队结构如何决定软件结构的文化/团队观察是一个深刻的问题。 [如上，](http://en.wikipedia.org/wiki/Hermeticism)以下，古人举行了会议。 在实践中如此清晰地看到它是很了不起的。 有趣的是，我们在网络开发团队中看到的全面变革-敏捷，叛乱，小组，独立行动，松散协调，目标驱动-与[第四代战争](http://en.wikipedia.org/wiki/Fourth_generation_warfare)的战斗策略和战术平行 。 我们看到集中化让位于分布式核心。 似乎复杂的不断变化的景观触发了并行的演变。 +实际上，有很多细微差别，但它们并不能从根本上改变我刚才描述的内容。 细微差别包括多个指标（有时数百个左右），知道什么时间范围已被完全下采样，调整采样参数，同时从许多来源（包括可能会延迟的副本）读取数据范围等等。 这些都不是什么大不了的。 -## 相关文章 +只要对数据进行读取优化，范围读取工作负载就没有什么特别困难的了。 即使在很长的时间范围内和多个指标上，它通常也不是大量数据。 我们发现很难快速响应此类读物的大量请求。 稍后我将讨论我们如何确保数据经过读取优化。 + +2 号工作量比较难。 这是热门查询用例，我将其称为批量读取。 看起来是这样的：从时间戳 A 到 B 读取大量未指定的指标，并对它们进行汇总，排序，返回前 N 位，并包含计算通用行所需的数据。 可以通过解释范围读取的方法来获取跟踪数据，例如在前 N 个数据中显示每个结果的迷你图所需的跟踪数据。 “热门查询”工作负载还包括相同的注意事项，例如在可用时使用较粗的粒度，同时读取等等。 + +批量读取工作负载的难点在于，它涉及许多指标-可能达数千万甚至更多。 读取单个指标的速度很快-足够快，我们可以以比客户习惯更快的速度呈现充满图表的页面。 （我们经常收到有关图表运行速度的评论。）但是有数千万个图表？ 即使每公制是微秒，不是，我们已经在谈论数十秒。 我们通过这种批量读取获得的数据也非常大。 这就是当“粪便变得虚构”的时候。 + +还要注意，尽管这些指标受批量读取的影响，但它们也受各个范围读取的影响。 它不是“或”，所以我们无法进行简单的优化，例如将属于类别的度量标准与总是由完全合格的度量标准名称查找的度量标准分开存储。 我们可以复制它们，但这会带来不小的成本。 + +最后，批量读取的一些挑战性特征似乎几乎是偶然的。 例如，包罗万象的行似乎没什么大不了的，但对于用户界面来说，这两者都是至关重要的，在用户界面中，提供有关用户正在分析的应用程序工作负载以及我们的后端的上下文信息至关重要， 它可以代表大量工作。 请注意，在屏幕截图中，我们正在显示 159 个其他查询，这些查询被分组到了 catchall 行中。 这个数字可能高达数百万。 + +## 数据分布特征 + +除了大容量读取工作负载呈现的有趣读取特性外，数据本身还具有一些不寻常的属性，尤其是在值的分布和密度方面。 + +大多数监视系统和时间序列数据库都是为密集指标（例如 CPU 或内存利用率）构建的。 密集度量标准属于可以依靠其存在的事物，并且在度量它时，总会得到一个值。 大多数用于监视数据的用例都隐式地假设所有指标都是密集的。 这说明了 RRDTool，Graphite 的 Whisper 后端等的设计。 + +现代应用程序体系结构已经对这些时间序列数据库提出了重大挑战，因为一切都变得高度动态且短暂。 在目前的极端情况下，我们拥有诸如 Docker 和微服务之类的东西，最终我们将拥有许多像亚马逊的 Lambda 那样运行的系统，其中计算节点本身的存在是非常短暂的。 目前，在这种环境中进行监视的挑战已基本解决。 我认为没有一个流行的时间序列数据库可以处理它。 + +但是在 VividCortex，高度稀疏和动态的数据不是理论上或新兴的用例，而是我们目前的现实。 查询，流程以及我们监控的所有其他各种可变活动，都会生成具有这些特征的监控数据。 如果我们要处理的一件事很不寻常，那很有可能。 （再次，我不主张唯一性，只是不寻常）。 + +这也是一个程度的问题。 在具有这种数据的*中，我们并不是唯一的，但我们受到的打击可能会比看上去相似的其他公司/产品受到更大的打击。 部分原因是大多数从查询角度衡量产品的产品都是从应用程序的角度来看的。 应用程序代码是有限的，并且不是临时性的，这会生成数量有限的不同类型的查询和其他要度量的内容。* + +但是，我们有坐在服务器上的代理，并且正在看到服务器的全部工作负载，而不仅仅是来自已检测应用程序的工作负载。 除非您看到典型服务器从不受监视的来源获得多少工作量，否则这种区别似乎并不重要。 这包括人工活动和其他临时活动，监视系统本身，后端应用程序，cron 作业等。 实际上，仅用于衡量应用程序生成的查询的典型 APM 工具确实存在很多盲点。 + +无论如何，我们系列的大部分内容（即基数）都是稀疏的，有时仅以相隔几天或几周的间隔记录点。 + +因为这构成了系列的大部分，但仅占数据的一小部分，所以任何假设将某个块/页面/范围用于一个系列的系统（假设以后将被填充）都是行不通的。 那里几乎是空白。 + +## 读或写优化？ + +在存储和检索我们一直在讨论的数据类型时，存在着一个巨大的，存在的，生存或死亡的问题来回答：读取优化还是写入优化？ 通过研究折衷，您可以轻松地建立事业。 + +如果对其进行了读取优化，则将面临巨大的写扩展挑战。 如果它是写优化的，将存在读取挑战。 让我们看看为什么。 + +如果我们认为主机和指标是真正一起构成系列 ID 的，那么问题就等同于询问我们要存储按时间戳排序还是按系列排序的数据。 + +对于（概念上）仅追加的不可变存储（例如我们的时间序列数据），我们将按照时间戳顺序对其进行读取（对吗？），乍一看，写优化似乎是理想的选择，因为数据将自动按照时间戳顺序进行存储。 只需在数据末尾附加点： + +``` + v host metric ts value + | 1 a.b.c.d 1426964208 123 + | 1 d.e.f.g 1426964208 87654 + t 2 a.b.c.d 1426964208 19283 + i 2 d.e.f.g 1426964208 183 + m 3 a.b.c.d 1426964208 9876 + e 4 l.m.n.o 1426964208 72736 + | 5 a.b.c.d 1426964208 17364 + | 1 a.b.c.d 1426964209 129 + | 1 d.e.f.g 1426964209 87656 + v 5 q.q.q.q 1426964209 9988 +``` + +问题在于我们想要一起读取的数据没有聚集在一起。 如果要读取主机 1，从给定的时间戳到另一个时间戳的度量`a.b.c.d`，我将遍历*大量*不需要的数据来执行此操作。 利用上面描述的稀疏特性，您可以轻松地计算出，我可能比我关心的多读取了几个数量级的数据。 这是*读扩增。* + +自然，索引是解决此问题的方法。 这就是发明索引的目的。 + +但是索引将复制数据并写入，并为写入引入随机 I / O。 当工作集超出内存时，B 树索引的性能和开销也会大大降低，并且我们的数据比内存大。 诸如 LSM 树之类的新一代索引并不能解决所有这些问题。 无论我们怎么看，我们都不会免费获得读取优化和写入优化。 一定会有一些读取，写入和/或空间放大。 + +鉴于纯写优化存储将无法正常工作，正确权衡的问题至关重要。 如何在不对写入造成严重影响的情况下对数据进行读取优化？ 换句话说，用于读取优化的数据的正确组织是什么？ + +通过在上面的示例中显示时间序列表的架构，我已经部分给出了我们答案的早期版本。 我们以`(host, metric, timestamp)`顺序在数据上定义了集群主键。 因此，这些点按主机和指标分组在一起，并且在其中按时间戳排序。 这样可以在一段时间内针对一组单独识别的系列的范围读取工作量优化数据。 + +但是，此群集对批量读取工作没有任何作用。 对于该工作负载，我们正在一系列时间戳上读取大量数据，并且正如我所提到的，这些系列构成了大多数数据。 因此，最有效的方法可能就是扫描整个范围，并丢弃不需要的数据。 二级索引（时间戳优先）可能是诀窍。 我们走了这条路，事实证明，由于要捕获的指标多种多样，因此此处的数学也不可行。 因为我们捕获了许多不同的批量指标组，但一次只查看一组，所以我们仍在检查少数数据，并且仍将极大地放大读数。 + +在早期，随着我们继续向捕获的数据集中添加越来越多的数据，这个问题变得更加严重。 回想一下，这是我们客户最有价值的用例。 这使其成为非常重要的问题。 我将回到这个问题，稍后再解释我们的解决方案。 现在，我想探索更多我们的架构，并为其他各种有趣的事物设置背景。 + +## 分片和分区 + +正如您所期望的，我们拥有多租户分片存储架构。 分片有助于满足我们的几种需求：写入扩展，读取扩展，数据隔离和租期以及安全性。 + +通常，只能通过分片来实现写缩放。 实际上，这确实是在全局中进行分片的唯一原因。 可以通过“横向扩展”复制来很好地解决读取扩展问题，这可以提供更多的读取容量。 + +数据隔离对我们很重要。 有时，SaaS 供应商会在所有客户中展示诸如实时分析之类的信息。 这种功能意味着一定程度的混合和缺乏隔离，我觉得有些不安。 我们正在努力防止某人获得广泛，不受限制的访问他们不应看到的数据的可能性。 在安全性与便利性之间取得平衡，我们倾向于使针头远离便利性。 （我们还[对敏感数据](https://vividcortex.com/blog/2014/11/11/encrypting-data-in-mysql-with-go/)进行加密，例如在飞行中和静止时的 SQL 端到端示例。[在即将举行的 Percona Live MySQL 会议](https://www.percona.com/live/mysql-conference-2015/sessions/encrypting-data-mysql-go)中，我将对此进行讨论。） + +为此，我们的分片单位是客户的“环境”-考虑分期，生产等。 主机属于一个且只有一个环境，并且所有 API 访问都被隔离到一个环境中。 API 令牌被定义为只能访问一个环境，因此在逻辑级别和物理级别上，每个环境都与所有其他环境隔离。 有时我们谈论按环境和主机进行重新分片，但到目前为止，即使是最大的客户环境也没有问题。 + +分片实际上是分区，我刚刚描述了按环境分区。 由于多种原因，我们还按时间范围划分数据。 一种是使清除过期数据变得容易。 删除数据的成本太高了，在许多系统中，至少要使系统的写入工作量增加一倍，甚至更多。 取消链接文件要好得多。 从本质上讲，它是免费的。 + +按时间分区是我们满足批量读取工作负载需求的方法之一。 按时间进行的分区本质上是一个粗粒度，开销少，时间戳优先的索引。 起初，我们一次分配一天； 现在，我们一次分配一个小时用于 1 秒数据，一天一次分配一个 1 分钟数据。 + +我们最初进行分区的方式是我要承担个人责任的另一个错误。 开始时，我们使用本机 MySQL 分区。 这有一些好处，我认为这些好处将胜过任何缺点： + +* MySQL 本机修剪不包含请求时间戳的分区 +* 分区表隐藏了应用程序代码的复杂性 +* MySQL 5.6 为分区添加了许多不错的功能，例如拉出一个分区并分别对其进行操作，然后将其交换回（EXCHANGE PARTITION）的功能。 + +我还认为，随着 MySQL 5.6 的改进，我们不会遇到早期版本的 MySQL 分区遇到的问题。 我是对的，我们不是。 我们遇到了其他人！ 哎呀。 分区维护作业（删除旧分区并创建新分区以保存将来的数据）将阻止长时间运行的查询，从而导致一切停止，并使服务器无法连接。 模式更改曾遇到类似的问题，在确定大容量读取工作负载无法正常工作并试图修复它时，我们不得不做几次。 模式更改还消耗了大量时间，并且由于元数据锁定等原因，模式更改永远不可能完全熄灭。 这些都是无聊的可预测的事情，只是因为我对它的思考不够深而发生。 + +因此，我们基本上遇到了几次“ ALTER TABLE 死机”和“分区维护死机”，然后从一开始就切换到应该做的事情。 我们为每个时间范围创建了单独的表，并使用表名对架构版本，数据分辨率和时间范围进行了编码。 1 秒数据的架构版本 1 的示例表名称为`observation_1_s_1424444400_1424448000`。 （我们将时间序列指标称为“观测值”，因为命名很困难，而且我当时还没有想到“点”。） + +新的模式版本只是被写入新表中，并且当从所有环境中清除旧数据时，我们最终可以删除旨在处理该模式版本的代码。 我们不再更改。 旧数据将长期存在。 + +这类似于我在 New Relic 上看到的情况，并且我认为此博客上有较早的文章对此进行了讨论（我也曾在 New Relic 进行过咨询），但是我认为分区的改进使其变得不必要。 为我们。 不幸的是，这是成为顾问的缺点之一。 您认为您了解系统方面的知识，但您不了解 jack，因为您只是在系统附近，您自己还没有操作过它。 活到老，学到老。 + +## 紧凑的存储 + +我们的架构看起来并不像我之前显示的那样。 如果考虑以下伪代码之类的模式及其包含的数据，则会发现效率低下： + +``` +observation ( + host number + metric string + ts number + value number + primary key(host, metric, ts) +) +``` + +首先，将有很多主机重复。 接下来，您将获得指标，这些指标也将疯狂地复制。 时间戳也将基本相似。 而且大多数时间序列值都为零。 + +最后，最重要的是，每个点将有一行。 这本质上是行标头的疯狂数目，最后附加了一些小数值。 + +为了解决这个问题并更紧凑地存储我们的数据，我们做了几件事： + +* 我们使用主机 ID 和度量 ID，而不使用诸如主机名和度量名称之类的文本字符串。 +* 我们以向量的形式将值分批处理，因此它不是每秒一行，而是每更长的时间范围（当前是每分钟，但将来可能会改变）一行。 这将分摊行中键的成本，这是我使用多年的技术。 它确实使某些事情不太方便，但是值得这样做，因为它使行数减少了 60 倍。 +* 我们并不总是存储确切的值。 我们使用一种定制的压缩算法，该算法利用了我们看到的时间序列数据的特征。 这进一步减少了我们价值观的存储空间。 某些高动态范围指标有时可能只占误差的一小部分，但没人在乎。 +* 我们存储大多数指标的增量，这些指标通常很小且易于压缩。 没有人会像查询数量一样在乎计数器的实际值。 无论如何，它将重置并重新启动。 人们关心的是这类数据的费率，而不是价值。 我们通过计算时间范围内的增量（例如每秒）来生成速率。 我们将某些类型的数据计算为值和费率，但这只是少数。 +* 我们不存储零。 一个“心跳”度量标准（例如系统时间戳或正常运行时间计数器）足以确定我们是否及时测量了一批值，因此我们可以分辨出零值与缺失值之间的差异。 这有助于逐步改变度量标准，其中有很多。 +* 我们计算各种汇总指标，位图等，并将它们与向量一起存储。 这对于不需要访问每个点的操作很有用，例如批量读取。 它还使我们能够进行诸如下采样之类的事情，而不会犯诸如“平均值”问题之类的愚蠢数学错误。 + +## API 和服务 + +我们的外部和内部 API 主要是基于 HTTPS 的 JSON。 一些内部服务使用协议缓冲区而不是 JSON，但是这些附加的依赖项和模式定义是我们仅在需要时添加的内容，并且在我们认为事情已经解决了足够的时间之后，我们就不会浪费额外的程序员时间来重做我们没有做的事情。 没错。 + +我们最初只有一个整体的 API 流程来处理所有内容。 当然，这仅仅是原型，我们很快就放弃了。 整体式 API 存在许多问题，例如成为单点故障。 + +我想建议一些通用的良好 API 做法； + +* 想一想 API 设计。 不要为自己设计 API，而是为可能想要创建一个假设的应用程序来做与您自己的工作截然不同的人设计 API。 请参阅 [Interagent 指南](https://github.com/interagent/http-api-design)。 +* 分离出您的读写路径。 读取和写入工作负载通常非常不同。 对于我们这样的服务，最重要的是我们不会丢失传入的数据。 长时间运行的繁重请求在某些情况下会轻易导致读取错误影响写入，并因此而丢失数据的情况。 使用单独的进程，甚至可能使用单独的服务器进行读写。 +* 构建 12 要素应用程序。 首先，我不理解或不同意 12 因子原则，尤其是日志记录，守护进程和配置准则。 我已悔改了自己的罪过。 +* 使用“干净”的体系结构，并像洋葱一样分层。 拒绝让内部层的任何事物知道，更不用说与外部事物进行交互。 这意味着内部工作或服务不应与您的公共端点进行交互。 将相同的原理应用于您的代码：代码中的依赖项应仅指向内部，而不能指向外部。 + +随着时间的推移，我们已经转向了一组准微服务的外部 API，其中（通常是很小的）一组相关端点位于单个二进制文件和进程中，但通过读写分开。 我们通过在某些代码库中构建读写路径来重用某些代码，但是通过 a）仅启用一组读写功能的配置和 b）代理规则，仅激活一组。 + +当此类服务成为我们要在内部构建的东西时，我们将进行下推重构，充分利用此 API 的实质并将其作为内部服务提供。 然后，外部服务将其大部分工作委托给该内部服务，我们也可以在内部其他地方使用它。 + +我们还将视情况处理特殊类型的数据和工作负载。 我们有专门用于时间序列数据提取的 API 和内部服务的单独集合，以确保我们可以快速而可靠地持久保存数据，并将写回确认给发送数据的代理或其他 API 客户端。 这些 API 是相当薄的前端：它们将写操作发送到 Kafka，然后完成。 + +然后，Kafka 使用者将数据从 Kafka 中流回并保留下来，大部分存储到 MySQL 中。 还有少量的 Redis。 -* [Etsy 博客](http://codeascraft.etsy.com/) -* [Flickr 架构](http://highscalability.com/flickr-architecture) -* [优化开发人员的幸福感](http://codeascraft.etsy.com/2011/06/06/optimizing-for-developer-happiness/) -* [推送：Facebook，Flickr，Etsy](http://codeascraft.etsy.com/2011/06/01/pushing-facebook-flickr-etsy/) -* [不断变化的战争面孔：进入第四代](http://globalguerrillas.typepad.com/lind/the-changing-face-of-war-into-the-fourth-generation.html) +卡夫卡很棒。 我希望它不使用 Zookeeper，并且对分区管理和故障转移有些不满意，但总的来说它是简单而可靠的。 但是，更重要的是它启用和鼓励的架构模式。 如果您还没有研究 [Jay Kreps 的有关基于日志的体系结构](https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)的博客文章，我鼓励您这样做。 尤其是如果您不希望消息队列/总线使您的整体体系结构更加简单明了，则应独立于 Kafka 本身考虑该文章中的想法。 -我很好奇要了解有关为什么分片 PostgreSQL 在 2011 年不如分片 MySQL 来证明引入第二个数据库系统的理由的更多详细信息吗？ +我们非常感谢 Kafka 的 Go Sarama 客户。 非常感谢 Shopify 团队和其他人编写它。 没有它，Kafka 对我们来说将不是一个可用的解决方案。 -我不知道 PostgreSQL 是否有问题，因为 Flickr 系统是建立在 MySQL 之上的，因此这显然是实现其方案的选择。 +通过使用 VividCortex，我们发现并解决了 VividCortex 的许多问题。 我们使用暂存来监视生产。 我强烈推荐这种模式。 生产永远不要自我监控，因为如果出现问题，您将无权访问数据以对其进行诊断。 -Etsy 工程团队还有一个博客，标题为“ Code as Craft”。 -= > http://codeascraft.etsy.com +我们还依赖于许多外部服务，包括 GitHub，HipChat，Dyn，Pingdom，CircleCI，VictorOps，BugSnag，还有很多我可能会为遗漏而感到不适。 最重要的两个是 GitHub 和 CircleCI。 我们还有一个几乎完全自动化的测试，构建和部署系统，我们可以通过 Hubot 聊天机器人（chatops）对其进行控制。 它与各种服务交互，包括自定义 Go 内部服务，Jenkins 和 Ansible。 CircleCI 立即对新代码进行了测试-我是否提到了它们的惊人程度-如果通过了，则取决于是否在分支中，将其部署到开发或暂存中。 + +在“穷人的 Heroku”之后，我们创建了一个称为“ Pooroku”的系统，以将每个人的 dev 分支推送到我们 dev 服务器的适当命名的子域。 合并的主人可能会自动将其部署到生产中，具体取决于相关代码的重要性和潜在后果。 如果没有自动部署到生产环境，则快速`/deploy foo to prod`会处理它。 + +所有这一切都发生在我们的聊天频道中，因此每个人都可以准确了解正在发生的事情并学习如何做。 如果您不熟悉 ChatOps 的好处，我建议您在[上写 Owen 的博客文章](https://vividcortex.com/blog/2014/06/02/chatops-at-vividcortex/)。 我们每天使用 Owen 等人构建的出色系统部署代码数十次。 我们还做大量其他事情。 在经历了 ChatOps 和持续交付之前，我不知道自己缺少什么。 + +## 使用围棋 + +我们从一开始就是 Go 用户，我们很自豪以各种方式支持 Go 社区并为 Go 社区做出贡献。 我们所有的外部和内部 API，服务，Kafka 使用者，工作者和其他系统程序都是用 Go 编写的。 这是我们能够扩展到已经达到的点的一个重要原因。 它的效率，对并发的支持，简单明了，出色的标准库以及静态编译的二进制文件，使它通过多种方式实现了梦想。 + +如果不是 Go 语言，那么我们在产品开发方面的距离可能只有一半，所支付的费用是 EC2 账单的五倍，或两者兼而有之。 + +我们在 Go 和数据库上写了[电子书](https://vividcortex.com/resources/building-database-driven-apps-with-go/)。 我们犯了很多错误，而这本书主要是关于我们在此过程中学到的知识。 + +## 硬件 + +我们将整个应用程序托管在 EC2 中。 我们故意使用相对弱的实例，这些实例具有有限的 CPU，RAM 和 EBS 卷，且配置的 IOPS 数量适中。 这在很多方面都是错误的。 面对大多数人关于在 EC2 中运行数据库的建议，这种说法不成立。 值得注意的是，这正是我 5 年前谴责的那种情况。 但是，它运作良好，并且是一门金融学科。 这也是避免短期解决硬件问题并突然意识到我们远远不能扩展以满足严重问题的需求的一种方法。 + +我最近没有看我们正在摄取多少数据（这是那些不方便的跨环境任务之一），但是截至几个月前，我们平均每秒摄取 332,000 个时间序列点，或每天超过 280 亿个 。 那时我们只有三个分片，因此从本质上讲，每台服务器每秒存储大约 100,000 点。 除了执行扇出批量查询时，服务器几乎完全处于空闲状态。 请记住，这是完全 ACID 事务存储，而不是希望与祈祷。 + +我们还在本地和跨区域复制每个分片，以进行读取扩展，故障转移/ DR 和进行备份，因此，我们的基础架构中实际上有 3 台以上的服务器！ + +对于读者来说，将这个数字与与此主题相关的类似博客文章进行比较，以了解我们在原始硬件效率和成本方面的表现如何，可能是一个有趣的练习。 我认为，将我们与其他公司进行比较的要点之一是，您经常可以进行很多优化，并且可以获得 1-2 个数量级的效率，甚至更多。 同时，我的诚实评估是，相对于我们的同龄人，我们既不是超效率的，也不是完全低效率的； 我们有点中间。 + +很好 但是精益运营需要付出一定的代价，您必须全面优化业务，而不仅仅是 EC2 账单。 上市速度是其中的一个重要因素。 + +## 没有银弹 + +在我描述我们的系统（尤其是我们的时间序列后端系统）的很多时候，人们会问：“为什么不只使用 X？” 该建议通常听起来很合理，直到您更深入地了解我们的要求为止。 这不足为奇，因为我们很长时间都不知道我们的要求。 + +我写了的[博客文章中解释了许多要求。 该职位似乎引起了很多人和公司的共鸣。 我认为在问我们为什么不使用特定解决方案之前，有必要先了解我们要解决的一些问题。 （建议卖方在阅读一些愚蠢的解决方案之前，先阅读该文章并进行每节点每秒的运算，以使我们使用的服务器数量是目前的 100,000 倍。）](http://www.xaprb.com/blog/2014/06/08/time-series-database-requirements/) + +我不想表现出防御性，好像我的自我让我不愿意考虑更好的解决方案的可能性。 但是请记住，实际上有数百种可能的解决方案需要考虑和/或评估。 那是不切实际的。 快速淘汰是我的首选策略。 + +人们提出的许多银弹包括 HBase，OpenTSDB，Cassandra 和 Hadoop。 这并不是要批评他们中的任何一个。 结合数学，基准测试和对我们发现的要求的检查，我得出的结论是，其中一些条件较差，一些条件相同，有时甚至更好，但没有一个是即用型的 证明切换的合理性。 + +某些解决方案可能会取得成功，但这样做的代价是要通过大量的缓存和批处理使事情进一步复杂化，换句话说，不是交钥匙的解决方案。 当然，我们不使用 MySQL 作为统包解决方案，但它仍然设置了很高的标准。 同样，保持技术表面积简单和清洁本身也是我们的一大胜利。 + +我的确会继续关注特定的解决方案或组合以及某些数据库中正在出现的工作。 我对 NDB（MySQL Cluster，您从未听说过的最令人难以置信的分布式实时数据库），InfluxDB，Cassandra 和 Spark 尤其感兴趣。 + +否定所有选项的详细信息将花费很长时间，但是作为特定反驳的*样本*，使用 Cassandra（通常用于时间序列数据）将需要传输数百 GB（或更多）的数据 通过网络为我们的一些客户提供服务。 那是因为它尚不支持对数据库本身内的表达式求值。 人们建议的大多数系统通常都存在类似的反对意见。 通常的解释是，当人们将解决方案 X 应用于一个类似的问题并获得成功时，规模的一个维度是他们处境中的 O（1），而这是我们的交叉乘积因子。 许多事情在许多情况下都可以很好地工作，但是当您将一个或三个额外的叉积投入组合时，将变得很困难。 + +有其他公司存在的证据，证明它们对非常大的数据集进行批量读取类型的查询并使其快速。 例如， [Scalyr 在智能暴力数据处理](http://blog.scalyr.com/2014/05/searching-20-gbsec-systems-engineering-before-algorithms/)上有一篇不错的博客文章。 New Relic Analytics（nee Rubicon）使用蛮力。 我的一些顾问还熟悉内部系统，这些内部系统会在非常大的公司内部大规模进行这种分析。 我们已经详细讨论了技术，成本和结果。 + +关于这一点，需要注意几件事。 一是我们已经自己做了很多扇出。 Go 使此操作非常容易。 当我们进行批量读取查询时，大量的计算和存储变得很忙，而且我们的处理效率很高，因此我认为没有很多未开发的潜力。 但是，另一件事是，您可以执行 100％扇出的数量有实际限制。 如果设计使一个庞大的查询停止了除一个用户之外的所有用户的访问，那么您将遇到可伸缩性问题。 这就是至少其中一些系统的工作方式； Scalyr 博客文章很好地解释了这里的一些细微差别和折衷。 最后，大规模扇出自动需要大量数据复制，这加剧了写入扩展问题。 + +最后，尽管有一小段时间我以为使用批量读取查询可能会使用蛮力，但我坚信这不会。 后来，我的一位顾问向我介绍了一位存储专家，他比我更了解硬件的物理功能。 我们在白板上重新进行了数学运算，并找到了类似的答案-要用数千美元的最昂贵的机器以不可思议的成本运行最先进的 PCIe 存储，以足够快地对它进行暴力破解，以满足我们的要求。 正如他所说的那样，“离可行的解决方案还有很多零”。 + +## 批量读取优化的演变 + +通过上述上下文，您可能会看到，我们基本上是在使用 MySQL 而不是简单地将其用作构建为分布式 Go 服务集的大规模时间序列数据库的存储引擎。 我们利用 SUM（）和其他几个函数使计算尽可能地靠近数据并避免网络传输，并且利用了 InnoDB 的聚集索引，这是一个巨大的胜利。 否则，我们将在 MySQL 之外进行很多繁重的工作。 + +希望批量读取的一些挑战现在对您显而易见。 您可能可以做一些数学运算，并弄清楚存储多少数据，拥有多少行等等的粗略数。 但是，批量读取操作的实际实现具有许多重要的细节。 冒着太多的香肠制作方法的风险，我将更深入地研究其中的一些。 + +回顾一下： + +* 可以按多种维度对多种事物进行排名 +* 很多稀疏指标 +* 很多主持人 +* 时间范围大 +* 搭配包包的 Top-N + +早在最初只是原型时，我们的第一个实现在每个地方都存在很大的效率低下的问题。 我们基本上采用了您可以想象的最简单的嵌套循环方法，如下所示： + +1. 查询指标表并找到与所需模式匹配的所有可能指标。 +2. 对于每个主机，每个指标， +3. 获取时间范围内的指标并对其重新采样。 +4. 使用插入排序来保留前 N 个。 +5. 总结剩下的全部内容。 +6. 返回。 + +即使对于较小的数据集，这也需要花费很长时间，并且往往会使内存不足。 我们立即注意到的最大的效率低下之一是，在大多数情况下，步骤 3 不会返回任何数据。 另一个明显的问题是，即使查询非常快，对数据库执行如此多的查询确实非常耗时。 + +下一步是停止执行单指标读取，并在查询中使用指标/主机对的组合，例如`metric IN(...) and host IN(...)`。但是，这些列表非常大。 MySQL 基本上将此类列表的每种组合视为单独的查询，就像在将其推送到数据库中之前所做的一样。 很好，除了用于此类查询的计划过程一次重新计划每个组合而且在 InnoDB 中并不便宜。 我在高性能 MySQL 中写了更多有关此的内容。 这些查询花了很长时间来计划，即使我们是小批量地进行。 同样，由于数据的稀疏性质，大多数组合在任何给定的时间范围内都没有产生任何行。 + +显然，我们需要粗粒度的时间戳优先索引只是为了消除考虑中的查询组合，因此我们没有尝试寻找它们。 我们仍将大部分时间用于寻找不存在的数据。 + +知道这并不是一个真正的大胜利，但是还没有找到更好的方法，所以我们引入了今天内部称为“选择不同”的内容。 针对我们的数据库可能有很多 SELECT DISTINCT 查询，但是这个臭名昭著，以至于用这两个词就足以识别它。 该查询找到了一个时间范围内存在的指标和主机的不同组合。 过了不久，我们才找到解决方案，对此进行了很大的改进，因此我们遭受了如此之久的痛苦，难以接受。 + +要解决此问题，我们需要一种时间序列事实，即“在时间范围 X 内，主机 Z 上的指标 Y 具有值”。 理想情况下，我们可以问“对于时间范围 X 和主机 Z，存在哪些度量标准”的问题。 一种方法是在时间序列指标表上创建二级索引，但这是一种超昂贵的方法。 另一个方法是创建大致的时间段（例如，按小时计算），并针对在该小时内进入我们的 API 的主机/指标的每种组合简单地记录“是”。 即使已设置为真，也要设置为真，这种行为在 MySQL 中是残酷的低效，因为它仍然是事务，它仍然会被记录下来，并且还会执行许多其他工作。 我们添加了 Redis 来处理该索引。 这大大改善了情况，使我们能够更快地制定特定客户的热门查询。 + +我们还向指标表添加了 firstseen / lastseen 列，我们在嵌套循环算法的第 1 步中使用了它来进一步修剪。 我们也将 Redis 用作更新这些列的写缓冲区，因为使用每个传入指标更新这些行将花费太多精力。 + +另一个改进是在重新采样和生成前 N 个和总体的过程中。 我们消除了重采样，只是寻找所需维度的前 N 个最大和。 直接将其推入 MySQL 是简单有效的，查询类似于 + +``` +SELECT host, metric, SUM(val) FROM tbl +WHERE ts BETWEEN x AND y +GROUP BY host, metric +ORDER BY SUM(val) DESC LIMIT N +``` + +我们利用向量的摘要列和其他一些次要的东西来尽可能地改善此问题，但是当我们开始计算每个类别的摘要序列并使用它们来避免产生总包时，取得了巨大的成功。 以前我们需要包包，所以我们可以显示每个系列构成了多少。 这一点很重要，因为没有它，您将不知道是否要优化等其他不重要的东西。 由于总系列只是类别中所有系列的总和，我们可以通过将前 N 个加在一起并从总数中减去它们来消除此步骤。 这消除了对单个系列的绝大多数访问，因为对于大多数客户而言，大多数数据都处于拖尾状态。 + +另一个优化来自观察大多数客户要么查看所有主机上的热门查询，要么仅查看一台或几台主机。 当然，最坏的情况是查看所有这些。 为解决此问题，我们引入了由该系列的所有主机聚合启用的所有主机快速路径。 通过这种优化，Top Queries 对于 1000 个主机的效率几乎与单个主机一样。 （这是读者要弄清楚为什么它效率不高的一种练习。） + +最后，我们消除了与查找与类别模式匹配的指标相关的效率低下的问题，并消除了将系列数据归为一个类别时将其数据聚类的方法。 为此，我们识别并编号了指标的类别，并在“观察”表中添加了类别列作为主键的一部分。 这再次依赖于 InnoDB 的集群主键存储的有效性。 它还使 Redis 成为 MySQL 外部的“存在”索引而过时了，从而消除了整个类别的故障场景和不一致情况。 Redis 很棒，但是更少就是更多。 + +所有这些优化都有很多很多细节，我在掩盖一些细节并引入了不准确性，但是我已经涉及了很多细节，所以我就此止步。 + +所有这些的要点在于，我们现在能够支持跨大量的稀疏指标与大量主机交叉产生的批量读取，以及通过利用数据中的各种模式来优化单个指标的读取 各种汇总指标，数学和 InnoDB 的聚集索引。 + +## 集群主键 + +集群主键是 MySQL + InnoDB 的巨大好处之一。 我[在其他地方](https://vividcortex.com/blog/2014/04/30/why-mysql/)写了关于为什么使用 MySQL 的信息。 + +我们将数据存储在 MySQL 中的方式，使它为数据进行索引以进行读取优化，同时使写入尽可能地高效，其工作方式比我们期望的要好。 它之所以如此出色的原因之一是 InnoDB 是一个非常复杂的存储引擎。 相对于您认为效率更高的许多数据库和存储引擎，您会惊讶于 InnoDB 算法的真正先进程度以及使用它免费获得的收益。 这包括事务日志记录，写优化，检查点和缓冲池管理等。 如果我们必须自己构建这些东西，或者使用诸如新一代 LSM 存储引擎之类的东西，那么我们几乎肯定会遇到诸如可怕的边缘情况，大量的写入停顿以及极其不稳定的性能之类的事情。 我们采用 VividCortex 进行设计的原因之一是[，因此我们可以准确地检测出这类问题](https://support.vividcortex.com/faults/)。 对于 InnoDB 和 MySQL 工程师来说，我们在低端 EC2 实例上获得了出色的性能，这证明了这一点。 + +运作良好的另一个原因是我们分割数据的方式。 这使索引树足够小，以至于当它们的工作集大于内存时，我们不会碰到写悬崖。 其结果与 InnoDB 复杂的刷新算法相结合，是我们的读取优化实际上并没有对我们的写入造成太大的损失。 + +最后，InnoDB 的聚集索引。 如果我们没有使用按索引顺序对数据进行物理聚类的数据库，那么它的工作效率将不那么高。 在 MongoDB 或 Postgres 中可能有多种方法可以做（在 Postgres 中有一些功能，例如部分索引，可以为我们提供更多优化）。 但是，如果没有集群主键，很难想象如何使另一个基础数据库对我们来说像 InnoDB 一样高效。 + +但是，MySQL 和 InnoDB 中的某些功能仍然不尽如人意。 存储引擎接口固有的效率低下，并且存在许多种锁定方式。 对于我们根本不需要的许多 ACID 东西，还有额外的开销； 如果它们能够更好地工作，那么某些事情将使我们受益，例如数据压缩（在 InnoDB 中，这对我们来说不是胜利，但可以实现更好的实现）。 这种低效率的清单很长，我怀疑机会成本是几个数量级。 不过，与我研究过的几乎所有其他广泛使用的数据库技术相比，MySQL / InnoDB 似乎处于良好的状态。 + +## 结论 + +希望您发现这对我们扩展服务规模以满足不断增长的客户群和异常需求是一个有用且有趣的旅程。 + +我们一直在改进我们的系统。 可以这么说，我们还有很多干粉，但是我们并没有过早地解决我们既看不到开始发生又无法避免的问题。 + +最后，这不是魔术。 有很多创造力和很多数学，大部分是餐巾纸。 数据受物理学定律的约束，我们可以在很大程度上预测挑战的规模以及解决挑战所应采用的技术的局限性。 更加困难的是预测客户将为产品找到的用例类型，以及由此需要向数据库提出的问题类型。 + +VividCortex 的出色团队给我留下了深刻的印象，他们每天都在解决棘手的问题，并且看起来很容易。 非常感谢他们，我们的投资者和顾问，许多慷慨的朋友和客户。 + +## 相关文章 -你好 +* [关于黑客新闻](https://news.ycombinator.com/item?id=9291237) +* [GopherCon 2014 使用数据库/ SQL 构建数据库应用程序](https://www.youtube.com/watch?v=m879N2rzn2g)，作者：Baron Schwartz +* [男爵 Schwartz：2014 年及以后的 MySQL，SQL，NoSQL 和开源](https://www.youtube.com/watch?v=f1hSvfDIfbo) +* [MySQL 中的时间序列数据](https://www.youtube.com/watch?v=kTD1NuQXr4k) by Baron Schwartz +* [转到数据库/ SQL 教程](http://go-database-sql.org/) +* [VividCortex / dbcontrol](https://github.com/VividCortex/dbcontrol) -Go 的数据库/ sql 程序包的包装，提供了连接池限制 -我想知道 postgres 是否不适用于可扩展性高的网站。 +HighScalability 很幸运能够担任该职位-Baron 的文章中总结了很多经验。 :) -谢谢 +不能再同意兰德尔了。 男爵是个地狱的家伙。 -tan +运气还不止于此。 如此之多的人选择在 HighScalability 上共享如此高质量的内容，这让我感激不已。 -有趣的是有人从 python 转向 php。 \ No newline at end of file +很棒的文章，内容丰富！ +我有一个问题。 +对于此类数据，TokuDB 似乎是一个很好的解决方案。 是否有不使用它的特定原因，或者只是不考虑使用它？ \ No newline at end of file diff --git a/docs/166.md b/docs/166.md index fb91bd6..03af153 100644 --- a/docs/166.md +++ b/docs/166.md @@ -1,28 +1,147 @@ -# PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片 +# Appknox 架构-从 AWS 切换到 Google Cloud -> 原文： [http://highscalability.com/blog/2011/12/27/plentyoffish-update-6-billion-pageviews-and-32-billion-image.html](http://highscalability.com/blog/2011/12/27/plentyoffish-update-6-billion-pageviews-and-32-billion-image.html) +> 原文： [http://highscalability.com/blog/2015/5/25/appknox-architecture-making-the-switch-from-aws-to-the-googl.html](http://highscalability.com/blog/2015/5/25/appknox-architecture-making-the-switch-from-aws-to-the-googl.html) -![](img/683d302405d99b27394fdf717b1498a9.png) +![](img/2ab3836af16dc4a8c0191aacd62b0e46.png) -Markus 在其 [PlentyOfFish 体系结构](http://highscalability.com/plentyoffish-architecture)上有一个简短的[更新](http://plentyoffish.wordpress.com/2011/12/27/32-billion-images-a-month/)。 令人印象深刻的 11 月统计数据： +*这是来自 Appknox 的全栈& DevOps 工程师 [dhilipsiva](http://dhilipsiva.com/) 的来宾帖子。* -* 提供 60 亿次网页浏览 -* 提供了 320 亿张图片 -* [n 天](http://plentyoffish.wordpress.com/2011/05/16/yay-finally-passed-6-million-loginsday/)中有 600 万次登录 -* IM 服务器可处理约 300 亿次浏览量 -* 11 个网络服务器（其中 5 个可以删除） -* 7 月雇用了第一位 [DBA](http://plentyoffish.wordpress.com/2011/07/30/hiring-my-first-dba/) 。 他们目前只有少数员工[。](http://news.ycombinator.com/item?id=3400649) -* 所有托管/ cdn 费用加起来每月都低于 7 万美元。 +[Appknox](https://www.appknox.com/) 帮助检测和修复移动应用程序中的安全漏洞。 保护您的应用程序就像提交商店链接一样简单。 我们上传您的应用程序，扫描安全漏洞，然后报告结果。 -**课程**：对于原始硬件而言，小型组织，简单架构，仍然是 PlentyOfFish 的丰厚利润。 +What's notable about our stack: -## 相关文章 +* **模块化设计**。 到目前为止，我们已经对模块进行了模块化，因此我们将前端与后端分离了。 这种架构具有许多优点，我们将在后面的文章中讨论。 +* **从 AWS 切换到 Google Cloud** 。 我们使代码在很大程度上与供应商无关，因此我们能够轻松地从 AWS 切换到 Google Cloud。 -* [关于 HackerNews](http://news.ycombinator.com/item?id=3400450) -* [每月 Markus Frind 提供 320 亿张图像](http://plentyoffish.wordpress.com/2011/12/27/32-billion-images-a-month/)。 +## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#primary-languages)主要语言 -哇，您每个月能得到 7 万美元吗？ 某处有成本细分吗？ +1. 后端的 Python & Shell +2. 前端的 CoffeeScript 和 LESS -代理广告。 +## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#our-stack)我们的堆栈 -您忘记了：“大量伪造的轮廓捕获了很多鱼”。 \ No newline at end of file +1. Django 的 +2. Postgres（从 MySQL 迁移） +3. 兔子 MQ +4. 芹菜 +5. 雷迪斯 +6. 记忆快取 +7. 漆 +8. Nginx 的 +9. 人的 +10. Google 计算 +11. 谷歌云存储 + +## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#architecture)架构 + +[![Architecture at AppKnox](img/5df684f185c981a66de5905c90b17b2e.png)](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/sourimg/architecture-at-appknox.jpg) + +### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#how-it-works)它是如何工作的？ + +我们的后端架构由 3 个子系统组成：客户端，数据和工作程序。 + +### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#client-subsystem)客户端子系统 + +客户端子系统由两个不同的负载平衡，自动扩展的 App &套接字服务器组成。 这是所有用户交互的地方。 我们非常注意不要在此处进行任何阻塞调用，以确保将延迟降至最低。 + +**App Server** ：每个 App 服务器都是单个计算单元，装有 Nginx 和 Django-gunicorn 服务器，由超级用户管理。 用户请求在此提供。 当用户提交其应用程序的网址时，我们会将其提交给 RabbitMQ `download`队列，并立即让用户知道该网址已提交。 如果上载任何应用程序，将从服务器获取签名的 URL。 浏览器将使用此签名 URL 将数据直接上传到 S3，并在完成后通知应用服务器。 + +**套接字服务器**：每个套接字服务器都是一个装有 Nginx 和一个节点（socket-io）服务器的计算单元。 该服务器使用 Redis 作为其适配器。 是的，当然，这用于实时更新。 + +### 数据子系统 + +#### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#data-subsystem) + +该系统用于数据存储，排队和发布/订阅。 这也负责解耦架构。 + +**数据库群集**：我们使用 Postgres。 不言而喻，它由一个“重写入”母版和几个“重读取”副本组成。 + +**RabbitMQ** ：我们芹菜工人的经纪人。 对于不同的工人，我们有不同的队列。 主要是`download`，`validate`，`upload`，`analyse`，`report`，`mail`和`bot`。 Web 服务器将数据放入队列，芹菜工作者将其拾取并运行。 + +**Redis** ：这充当套接字 io 服务器的适配器。 每当我们想要通知用户任何工作人员的更新时，我们都会将其发布到 Redis，Redis 随后将通过 Socket.IO 通知所有用户。 + +### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#worker-subsystem)工作者子系统 + +这是所有繁重的起重工作完成的地方。 所有工作人员均通过 Redis 从 RabbitMQ 和已发布更新中获取任务给用户。 + +**静态扫描仪**：这是一个自动缩放的计算单元组。 每个单位由 4-5 名芹菜工人组成。 每个芹菜工人一次扫描一个应用程序。 + +**其他任务**：这是一个自动缩放的计算单元组。 每个单位由 4-5 名芹菜工作者组成，他们执行各种任务，例如从商店下载应用程序，生成报告 pdf，上传报告 pdf，发送电子邮件等。 + +**动态扫描**：这是特定于平台的。 每个 Android 动态扫描程序都是一个按需计算实例，该实例具有 android 模拟器（带有 SDK）和一个捕获数据的脚本。 该模拟器显示在浏览器的画布上，供用户进行交互。 每个 iOS 扫描仪都位于托管的 Mac-Mini 服务器场中，该服务器场具有支持 iOS 平台的脚本和模拟器。 + +## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#reasons-for-choosing-the-stack)选择堆栈的原因 + +我们选择 **Python** 是因为我们用于扫描应用程序的主要库位于 python 中。 而且，我们比已知的任何其他语言都更喜欢 python。 + +我们选择 **Django** 是因为它具有模块化功能。 + +**灰烬**-我们认为这是目前最强大的前端框架。 是的，学习曲线比其他任何曲线都陡峭，但是一旦您爬上那座陡峭的山峰，您将绝对喜欢余烬。 这是很自以为是的。 因此，只要您遵守它的约定，就可以减少编写工作。 + +**Postgres** -最初，我们选择 MySQL 是因为它是事实。 在甲骨文收购 Sun Microsystems（MySQL 的母公司）之后，MySQL 陷入停滞。 我想我们都期望如此。 因此，我们确实使用了社区维护的 MariaDB（MySQL 的一个分支）。 后来，我们需要持久键值存储，这是 Postgres 开箱即用的。 它在 Python 中发挥的非常好。 我们使用 UUID 作为主键，这是 Postgres 中的本机数据类型。 另外，`uuis-ossp`模块提供了在数据库级别生成和操作 UUID 的功能，而不是在应用程序级别创建它们的功能，这更加昂贵。 因此我们切换到 Postgres。 + +其余的都是事实。 **RabbitMQ** 用于任务队列。 **Celery** 用于任务管理。 **Redis** 用于发布/订阅。 **Memcached &清漆**用于缓存。 + +## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#things-that-didnt-go-as-expected)事情未按预期进行 + +未能按预期进行的事情之一是**缩放套接字**。 我们最初使用的是 Django-socket.io。 我们意识到这无法扩展到多个服务器。 因此，我们将其编写为单独的节点模块。 我们使用了支持 Redis-adapter 的节点的 socket-io 库。 客户端连接到节点的套接字服务器。 因此，我们现在从 python 代码发布到 Redis。 Node 只会将通知推送给客户端。 可以独立于充当客户端 JSON 端点的应用程序服务器进行扩展。 + +## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#notable-stuff-about-our-stack)关于堆栈的显著资料 + +我们喜欢**模块化设计**。 到目前为止，我们一直在对模块进行模块化，以至于我们将前端与后端分离。 是的，你没有看错。 所有 HTML，CoffeeScript 和 LESS 代码都是独立于后端开发的。 前端开发不需要服务器在运行。 在开发过程中，我们依靠前端设备来获取假数据。 + +我们的**后端命名为** **Sherlock** 。 我们检测移动应用程序中的安全漏洞。 所以这个名字似乎很贴切。 Sherlock 很聪明。 + +我们的**前端称为 Irene** 。 还记得艾琳·阿德勒（Irene Adler）吗？ 她美丽，多彩，并告诉我们用户出了什么问题。 + +我们的**管理员名为 Hudson** 。 还记得哈德森夫人吗？ 夏洛克的女房东？ 考虑到我们应该为可怜的沃森博士扮演什么角色。 也许我们会。 + +因此，Sherlock 不提供任何 HTML / CSS / JS 文件。 我再说一遍，它**不提供任何单个静态文件/ HTML 文件**。 夏洛克和艾琳都是独立开发的。 两者都有单独的部署过程。 两者都有自己的测试用例。 我们将 Sherlock 部署到**计算实例**，并将 Irene 部署到 **Google Cloud Storage** 。 + +这种架构的**优势在于：** + +1. 前端团队可以**独立于后端的**工作，而无需互相踩脚。 +2. 从服务器移除**等繁重的工作，例如在服务器上呈现页面。** +3. 我们可以**开放源代码的前端代码**。 轻松雇用前端人员。 只需要求他们修复存储库中的错误，便可以雇用他们。 毕竟，即使您不开源它，任何人都可以读取前端代码？ + +## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#our-deployment-process)我们的部署流程 + +该代码是从`master`分支自动部署的**。 我们遵循 [Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/) 的 Git 分支模型。 Jenkins build 提交到`develop`分支。 如果成功，我们将进行另一项手动测试，只是要确保将其与`master`分支合并并自动部署。** + +## 最初使用的 AWS。 我们决定使用 Google Cloud 的原因有 3 个。 + +1. 我们喜欢基于**基于项目的方法来管理不同应用程序的资源**。 它使访问基础架构更加实用。 由于我们的“动态扫描”功能的复杂性，它使识别实例更加容易。 +2. 当我们受到打击时，它具有**令人敬畏的文档**，并获得了 Google 工程师的私人 1：1 帮助。 +3. 我们收到了一些**重要的 Google 积分**，这有助于我们在早期阶段削减成本。 + +我始终远离 IaaS 提供商提供的特殊服务。 例如，我们没有使用 Amazon RDS 或 SQS。 配置了我们自己的数据库服务器，RabbitMQ 和 Redis 实例。 这样做的原因是-这些服务相对较慢（且成本较高），并且您的产品依赖于供应商。 我们将所有这些抽象为独立于供应商的。 我们忘了抽象的一件事就是存储。 + +我们直接消耗了 S3。 当我们尝试迁移到 Google Cloud 时，这只是一个小小的选择。 因此，当我们决定迁移到 Google Storage 时，我们对存储层进行了抽象，并遵循了 Google [Storage Migration docs](https://cloud.google.com/storage/docs/migrating) 的要求。 而且一切正常。 现在，无需更改代码即可将代码库托管在 Google Cloud 和 AWS 上。 当然，您将不得不更改配置。 但不是代码。 + +感谢您的来信。 因此，迁移到 Google 云的原因就在于此。 但是，需要对第 1 点进行说明。 + +你说什么意思 + +“我们喜欢基于“项目”的方法来管理不同应用程序的资源。它使访问基础架构更加务实。由于“动态扫描”功能的复杂性，它使识别实例更加容易。” + +谢谢 +anand + +@anand + +你好 这里是“ dhilipsiva”。 + +对于我们的“动态扫描”功能，我们动态创建一个新实例，进行扫描，并在完成扫描后终止它（出于安全原因）。 + +在 AWS 中，您将必须创建一个网络接口并将其分配给应该属于同一 VPN 的实例（在创建实例时）。 使用 AWS 时，我们必须等待设备启动，获取 IP 并在启动后继续启动扫描过程。 + +但是在 Google Cloud 中，无论何时创建实例，该实例都将自动可见，并且对同一 Project 中的其他实例也可以访问[它会自动进行联网]。 而且我们不必检测 IP，我们可以将实例的“名称”用作其他实例的域并进行访问。 IP 不是必需的。 在这种情况下，我们不必等待任何事情。 只需将一些启动脚本放入“动态扫描”实例中，一切便是事件驱动的。 + +不知道这是否能正确解释这一点，但可悲的是，这就是我可以分享的所有信息：P + +您可以寻找 Nginx + lua-resty-redis 而不是 nodejs。 +缩放效果更好且非常轻便 + +嗨，吉里达尔，那是一个非常好的建议。 感谢分享。 一定会调查一下。 + +架构图未完整显示，工作子系统被隐藏了！如果显示完整，将会更好！ \ No newline at end of file diff --git a/docs/167.md b/docs/167.md index c036483..1cbf657 100644 --- a/docs/167.md +++ b/docs/167.md @@ -1,83 +1,123 @@ -# Instagram 架构：1400 万用户，1 TB 的照片，数百个实例，数十种技术 - -> 原文： [http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html) - -![](img/e7b70a6c02b1e7425849dd6d1af801f2.png) - -[Instagram](http://instagr.am/) 是为您的 iPhone 提供的免费照片共享和社交网络服务，已获得[即时成功](http://techcrunch.com/2011/08/03/instagram-150-million/)。 在短短一年内增长到 [1400 万用户](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of)的情况下，他们在 8 月达到了 1.5 亿张照片，同时积累了数 TB 的照片，而他们仅用了 3 个 Instaneers 做到了，所有这些都存储在 Amazon 堆栈中。 - -Instagram 团队已经撰写了可以被视为该时代早期创业公司的典型描述：[推动 Instagram 运转的因素：数百个实例，数十种技术](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of)。 - -Instagram 使用不同技术和策略的模仿。 团队虽小，但经历了快速的增长，摆脱了不断上升的社交和移动浪潮的影响，它使用 SQL 和 NoSQL 的混合体，使用了大量的开源项目，他们选择了基于云的云服务，亚马逊的服务得到了充分利用 可靠性不是通过构建它们自己的，而是通过可用性区域，异步工作计划将组件链接在一起，系统由尽可能多的服务公开，这些服务公开了不需要构建的 API 和外部服务，数据存储在内存中， 在云中，大多数代码都是动态语言，对自定义位进行了编码以将所有内容链接在一起，并且它们运行得很快并且体积很小。 非常现代的建筑。 - -我们只是在这里博士文章，它写得很好并且很切题。 绝对值得一读。 这里是要领： - -* 获得的经验教训：1）保持简单 2）不要重新发明轮子 3）尽可能使用成熟可靠的技术。 -* 3 名工程师。 -* 亚马逊商店。 他们使用许多亚马逊的服务。 仅有 3 位工程师，因此没有时间研究自我托管。 -* 出于各种目的，总共有 100 多个 EC2 实例。 -* Ubuntu Linux 11.04（“ Natty Narwhal”）。 稳定，其他 Ubuntu 版本冻结了。 -* 亚马逊的 Elastic Load Balancer 路由请求，并且 3 个 nginx 实例位于 ELB 的后面。 -* SSL 在 ELB 处终止，这减轻了 nginx 上的 CPU 负载。 -* 亚马逊的 DNS 的 Route53。 -* 高 CPU 超大型计算机上的 25 多个 Django 应用程序服务器。 -* 流量是受 CPU 限制的，而不是受内存限制的，因此，高 CPU 超大型计算机是内存和 CPU 的良好平衡。 -* [Gunicorn](http://gunicorn.org/) 作为其 WSGI 服务器。 Apache 较难配置且占用更多 CPU。 -* [结构](http://fabric.readthedocs.org/en/1.3.3/index.html)用于在所有计算机上并行执行命令。 部署仅需几秒钟。 -* PostgreSQL（用户，照片元数据，标签等）在 12 个四倍超大内存实例上运行。 -* 十二个 PostgreSQL 副本在不同的可用性区域中运行。 -* PostgreSQL 实例使用[流复制](https://github.com/greg2ndQuadrant/repmgr)在主副本设置中运行。 EBS 用于快照，以进行频繁备份。 -* EBS 部署在软件 RAID 配置中。 使用 [mdadm](http://en.wikipedia.org/wiki/Mdadm) 获得不错的 IO。 -* 它们的所有工作集都存储在内存中。 EBS 不支持每秒足够的磁盘搜寻。 -* [Vmtouch](http://hoytech.com/vmtouch/vmtouch.c) （便携式文件系统缓存诊断）用于管理内存中的数据，尤其是当[将](https://gist.github.com/1424540)从一台机器故障转移到另一台机器时，尚无活动内存配置文件。 -* XFS 作为文件系统。 用于在快照时通过冻结和解冻 RAID 阵列来获取一致的快照。 -* [Pgbouncer](http://pgfoundry.org/projects/pgbouncer/) 用于[池连接](http://thebuild.com/blog/)到 PostgreSQL。 -* 几 TB 的照片存储在 Amazon S3 上。 -* 将 Amazon CloudFront 作为 CDN。 -* Redis 支持其主要供稿，活动供稿，会话系统以及[其他服务](http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value-pairs)。 -* Redis 在多个四倍超大内存实例上运行。 有时跨实例进行分片。 -* Redis 在主副本设置中运行。 副本不断地保存到磁盘。 EBS 快照备份数据库转储。 在主数据库上的 DB 上转储太费力了。 -* Apache [Solr]为[地理搜索 API](http://instagram.com/developer/endpoints/media/#get_media_search) 提供了支持。 就像简单的 JSON 接口一样。 -* 6 个用于缓存的 memcached 实例。 使用 pylibmc & libmemcached 连接。 Amazon Elastic Cache 服务再便宜不过了。 -* [Gearman](http://gearman.org/) 用于：将照片异步分享到 Twitter，Facebook 等； 通知实时订户新发布的照片​​； 送纸扇出。 -* 200 名 Python 工作者从 Gearman 任务队列中消耗任务。 -* [Pyapns](https://github.com/samuraisam/pyapns) （Apple 推送通知服务）处理超过十亿个推送通知。 坚如磐石。 -* [Munin](http://munin-monitoring.org/) 可以绘制整个系统的指标图并警告问题。 使用 [Python-Munin](http://samuelks.com/python-munin/) 编写许多自定义插件，以图形化显示，每分钟注册数，每秒发布的照片​​等。 -* [Pingdom](http://pingdom.com/) 用于服务的外部监视。 -* [PagerDuty](http://pagerduty.com/) 用于处理通知和事件。 -* [Sentry](http://pypi.python.org/pypi/django-sentry) 用于 Python 错误报告。 +# 阿尔及利亚通往全球 API 的愤怒之路 -## 相关文章 +> 原文： [http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html) + +![](img/f1addf57e7f14a4a7ca0bc885af700ca.png) + +*由 [Algolia](https://www.linkedin.com/in/julienlemoine) 的联合创始人& CTO Julien Lemoine 做客，这是一个开发人员友好的搜索即服务 API。* + +我们为开发人员和开发人员回答的最常见问题是关于 [我们的架构](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 以及我们如何实现如此高的可用性。 他们中的一些人对裸机服务器的高可用性持怀疑态度，而另一些人则对我们如何在全球范围内分发数据持怀疑态度。 但是，我更喜欢的问题是“初创企业如何建立这样的基础架构”。 的确，对于一个年轻的公司，我们当前的架构令人印象深刻： + +* 我们的高端专用计算机在全球 13 个地区托管，拥有 25 个数据中心 + +* 我们的主从设置会在至少 3 台不同的计算机上复制我们的搜索引擎 + +* 我们每个月处理超过 60 亿个查询 + +* 我们每个月接收和处理超过 200 亿次写操作 + +就像罗马不是一天建成的，我们的基础架构也不是很好。 本系列文章将探讨我们在构建基础架构时采取的 15 个工具步骤。 我什至将讨论我们的中断和错误，以便您了解我们如何使用它们来改进我们的体系结构。 + +第一部分将重点介绍我们在 2013 年 3 月至 2013 年 8 月处于测试阶段时构建服务时所采取的前三个步骤。 + +# 云端与裸机之争 + +在深入探讨我们的架构之旅的细节之前，我想谈一谈对其他基础架构产生重大影响的选择。 我们需要决定是否应该使用基于云的基础架构或裸机。 在技​​术讨论中经常讨论的热门话题。 + +对于大多数用例，尤其是在早期阶段，云基础架构是一个很好的解决方案。 它们在提高许多服务的高可用性方面发挥了作用。 在多个可用区（AZ）上运行数据库或在不同 AZ 上运行多个实例的数据库同时将其所有状态存储在多个 AZ 数据库中的解决方案就是一个很好的例子。 这是许多工程师使用的标准设置，几分钟即可轻松部署。 + +裸机基础架构要求您了解并设计一些小细节，以便自己构建高可用性。 这是一种“自己动手”的方法，仅对一小部分用例有意义。 我们经常遇到在单个数据中心中使用裸机部署的情况。 这没有意义，因为它的容错性不如在云提供商上进行快速部署，数据中心是单点故障（SPoF）。 + +对于与硬件相关的企业，裸机硬件仍然是一个有趣的选择，这正是我们的情况。 通过选择裸机基础架构，我们可以购买比云提供商所提供的性能更高的硬件。 除了性能提升之外，成本也要便宜得多。 我们之所以选择此选项，是因为我们充分意识到我们将需要自己构建高可用性！ + +# 早期：2013 年 3 月至 8 月 + +## 步骤 1：2013 年 3 月 + +设计了高可用性，未实现！ + +目前，我们首次运行了搜索即服务 API 的私人 Beta 版。 在这个时候，我们只能衡量我们的表现。 我们尚未开发产品的高可用性部分。 我们对我们的市场遍及全球充满信心，因此我们在加拿大/东部和欧洲/西部两个不同的地方推出了单机，其规格如下： + +* 32G 内存 + +* Xeon E3-1245 v2（4 核，8 线程，3.4Ghz-3.8Ghz） + +* 2 个 Intel RAID 320 系列 120GB 的 Raid-0 + +每台计算机根据其位置托管不同的用户集。 在我们的私人测试版中，性能集中在 100％上，这就是时钟速度是我们做出决定的主要因素的原因（对于同一代 CPU，时钟速度与搜索引擎中搜索查询的速度直接相关）。 从一开始，我们就在一个单独的过程中完成了索引，其级别为 5。 所有搜索查询都是在 nginx 内部直接处理的，我们将其设置为零（进程的良好级别越低，它获得的 CPU 时间就越多）。 此设置使我们能够通过为搜索分配最高的分配 CPU 优先级来有效地处理流量高峰。 与其他引擎使用的方法相比，此方法效果很好。 + +我们感到非常惊讶的是，我们的第一批 Beta 测试人员之一在生产中将其替换为以前的解决方案，因为他们对性能和相关性感到非常满意。 如您所料，我们对此感到非常压力。 由于未实现高可用性，因此我们担心会影响它们的潜在停机时间，并解释说该产品尚未投入生产！ 客户告诉我们，风险与回报对他们来说是可以接受的，因为如果需要，他们可以回滚到以前的提供商。 附带说明，这个故事帮助我们在产品推出之前获得了第一轮资金。 最终成为我们对市场适应性的第一个证明。 更好的是，我们可以称其为“问题解决方案”！ 我们不能感激那个客户：) -* [在 Redis 中存储数亿个简单键值对](http://instagram-engineering.tumblr.com/post/12651721845/instagram-engineering-challenge-the-unshredder) -* [简化 EC2 SSH 连接](http://instagram-engineering.tumblr.com/post/11399488246/simplifying-ec2-ssh-connections) -* [在 Instagram 上拆分& ID](http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram) -* [EC2 或 Amazon ElastiCache 上的 Membase 群集？](http://nosql.mypopescu.com/post/13820225002/membase-cluster-on-ec2-or-amazon-elasticache) 来自 Alex Popescu +## 第 2 步：2013 年 6 月 -嘿托德， +在我们的体系结构中实现高可用性 -来自 Instagram 的 Mike。 感谢您的撰写。随着我们不断发展的基础架构，高可伸缩性一直是我们的绝佳资源，感谢您编译的所有出色信息！ +经过三个月的开发和大量测试（猴子测试方法真的很有趣！），我们在 Beta 中引入了高可用性支持。 您可以在 [体系结构文章](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 中阅读更多有关它的内容。 这个想法是由三台相同的机器组成的集群，而不是一台机器，其中每台机器都是所有数据的完美副本，并且能够充当主服务器。 这意味着每个人都可以接受来自 API 用户的写入操作。 每个写操作都会触发共识，以确保所有计算机都具有所有作业，并以相同顺序应用它们。 -迈克，我很高兴。 我真的很感谢你们的开放程度。 好东西。 谢谢。 +我们使用了第一个 Beta 的初步结果来设计新的硬件设置。 我们发现以下内容： -@Mike（instagram） -我读到您使用 solr 进行地理搜索。 您能解释一下您的解决方案吗？ 您将 solr 3.1 与 geofilt 一起使用还是开发了一些特殊的东西？ +* 32G 的内存不足，当从多个用户那里接收大索引作业时，索引最多使用 10G，这只能让 22G 缓存磁盘 IO + +* 磁盘空间不足，无法实现高可用性，因为计算机需要在磁盘上保留多个作业才能处理节点故障 + +* 拥有更多的内存，我们需要迁移到 Xeon E5 系列（E3 仅可寻址 32G 的内存）。 由于时钟速度很重要，我们决定选择 Xeon E5 1600 系列，该系列提供了非常好的时钟速度，并且能够比 Xeon E3 拥有更多的内存。 + +通过这些发现，我们的设备演变为三台具有以下规格的机器： + +* 64G 内存 + +* Xeon E5-1650（6 核，12 线程，3.2Ghz 至 3.8Ghz） + +* 2 个 Intel RAID 320 系列 300GB 的 Raid-0 + +至此，我们能够忍受硬件故障！ 但是，我们离提供多个可用区域的云提供商还差得远。 我们所有的机器都在同一个数据中心中，只有一个提供商，而对基础架构一无所知。 + +同时，我们研究了是否应使用硬件或软件来处理机器之间的负载平衡和检测失败。 我们测试了几种方法，发现所有硬件负载平衡器几乎都无法使用多个提供程序。 我们最终在 API 客户端中实施了基本的重试策略。 每个 API 客户端的开发都能够访问三台不同的计算机。 三个不同的 DNS 记录代表每个用户： [USERIDID-1.algolia.io](http://useridid-1.algolia.io) ， [USERID-2.algolia.io](http://userid-2.algolia.io) 和 [USERID-3.algolia.io](http://userid-3.algolia.io) 。 我们的第一个实现是随机选择其中一个记录，然后在失败的情况下重试另一个记录。 + +## 第 3 步：2013 年 8 月 + +正式启动服务 + +在夏季，我们将 API 客户端的数量增加到 10 个（JS，Ruby，Python，PHP，Objective-C，Java，C＃，Node.js ...）。 我们决定避免使用自动代码生成，而是手动开发 API 客户端。 尽管还有更多工作要做，但我们需要确保网络代码对于 HTTPS 保持活动状态，正确使用 TLS，以正确的超时正确实施重试策略等保持良好状态。 + +我们于 2013 年 8 月底在我们的两个位置（欧洲/西方和加拿大/东方）正式启动了该服务。 每个位置包含三个相同主机的群集，它们具有以下规格： + +* 128G RAM + +* E5-2687W（8 核，16 线程，从 3.1Ghz 到 3.8Ghz） + +* 2 个 Intel S3500 系列 300GB Raid-0 + +与以前的配置相比，我们所做的主要更改是增加内存大小并使用更好的 SSD。 基于观察到 SSD 是索引编制过程中的瓶颈，并且内存不足以将所有用户的数据缓存在内存中的发现，完成了这两项更改。 对于 CPU 升级，更大的问题是要确保我们拥有足够的资源。 + +在这一点上，我们要重点关注的下一个大项目是为我们的部署实施可用性区域。 我们需要在不同的网络设备和电源单元上运行三台机器。 希望我们的提供商对他们的基础架构以及机器的分配位置保持透明。 它不是完美的，但是我们能够实现与其他云提供商类似的解决方案。 我们怀疑云提供者所做的事情与我们实施的类似，但尚未找到有关此主题的任何详细文档！ + +### 下一个 + +与大多数其他初创公司一样，我们从粗略的 MVP 开始测试市场。 我们最终不得不做一些认真的工作来开发更加成熟和强大的体系结构。 通过这些最初的几个步骤，我们从 MVP 过渡到可用于生产的 API。 + +到目前为止，我们已经介绍了该博客系列 15 个步骤中的 3 个。 在下一个博客中，您将了解生产的前 18 个月以及我们所面临的所有意外问题，包括首次停机！ + +*以下是该系列的所有三个部分：[第 1 部分](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html)，[第 2 部分](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html)，[第 3 部分](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html)* + +## 相关文章 -这个多少钱？ 只是有一个想法。 +* [关于 HackerNews](https://news.ycombinator.com/item?id=9899794) -亲爱的迈克， +期待其他 12 个步骤：） -您是否掌握有关 Instagram 服务器基本硬件数据的信息？ 我们必须在大学的“信息管理”讲座中找到 CPU，RAM，固定磁盘存储和处理器等数据。 +优秀的文章！ 感谢分享。 -如果您能帮助我们，我们将非常高兴。 +当您说“ ..所有搜索查询都直接在 Nginx 内部处理..”时，我无法理解。 你能更好地解释吗？ -非常感谢！ +问候！ -J，J 和 L +@Mauro Herrera：当然，我们处理查询的代码是用 C ++开发的，并且直接作为模块嵌入在 nginx 中。 查询到达后，它会由 nginx 直接处理，而无需与任何其他进程进行通信（唯一的例外是我们的客户在自定义 API 密钥中自定义了速率限制，在这种情况下，我们与存储在 同一台机器）。 +您可以在[我们的体系结构帖子](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html)上获得更多详细信息，它们描述了我们所有的堆栈。 -CDN 需要内容可以公开阅读。 -然后，Instagram 如何处理仅应与少数人共享的图像 +“除了性能提高之外，成本也要便宜得多。” +在人们将大量精力转移到云计算以体现零 CAPEX 和低 OPEX 收益的时代，裸机基础设施如何降低成本？ 你能解释一下吗？ -您可以在 S3 上拥有一个私有存储桶项目，尽管直到在 S3 中生成签名密钥，该私有桶项目才可以通过 CDN 路由。 每个被授予权限的用户都可以收到一个签名的密钥。 我不知道这是否是他们具体的做法。 +阿尔戈利亚很棒。 在 Stamplay，我们将他们的搜索 API 集成到了开发平台中，因此我们的用户只需单击几下便可以将超快速搜索添加到他们的应用程序中，这比他们自己集成 API 的速度要快。 它对我们用户的应用程序的搜索性能产生了巨大的影响。 -相关文章中“在 Redis 中存储数亿个简单键/值对”的链接不正确。 它重定向到其他一些中等职位。 实际链接是 https://instagram-engineering.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c \ No newline at end of file +如果有人想了解 Stamplay 的 Algolia API 集成的工作原理，我们实际上创建了一个非常有用的教程，以演示如何快速设置和运行它：https://blog.stamplay.com/how-to-create-a- 带有 AngularJS 条纹阿尔及利亚和 stamplay 教程的书俱乐部应用程序/ \ No newline at end of file diff --git a/docs/168.md b/docs/168.md index 8a4f643..ad8d75d 100644 --- a/docs/168.md +++ b/docs/168.md @@ -1,341 +1,121 @@ -# DataSift 体系结构：每秒进行 120,000 条推文的实时数据挖掘 +# 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分 -> 原文： [http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) +> 原文： [http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html) -![](img/a850e4e8776a07063949e480bd50d469.png) +![](img/914d4bdf9db5c148d642dcbfb590ddac.png) -我记得 Twitter 首次开放他们的消防水带时的兴奋。 作为 Twitter API 的早期采用者，我可以轻松想象可以对所有这些数据执行的一些很酷的事情。 我还记得在大数据领域，数据是有代价的，而对于像我这样的小鱼来说，代价太高了，我对此感到失望。 这就像第一次学习，不会有 BigData 圣诞老人。 +我们为开发人员和开发人员回答的最常见问题是关于[我们的体系结构](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html)以及我们如何实现如此高的可用性。 他们中的一些人对裸机服务器的高可用性持怀疑态度，而另一些人则对我们如何在全球范围内分发数据持怀疑态度。 但是，我更喜欢的问题是“初创企业如何建立这样的基础架构”。 的确，对于一个年轻的公司，我们当前的架构令人印象深刻： -尽管有一段时间，我很高兴思考如何处理所有数据。 这是一个令人着迷的问题。 您必须能够可靠地使用它，对其进行规范化，将其与其他数据合并，在其上应用功能，对其进行存储，进行查询，对其进行分发，然后再将其货币化。 大部分都是实时的。 而且，如果您试图创建一个平台，以允许整个 Internet 对防火墙执行相同的操作，则挑战将成倍增加。 +* 我们的高端专用计算机在全球 13 个地区托管，拥有 25 个数据中心 -DataSift 处于创建这样的烟火，数据斩波机器的令人兴奋的位置。 您会看到，DataSift 已从 Twitter 购买了多年的重新组织权，这使他们可以访问完整的 Twitter 消防水带，并能够将其子集转售给其他各方（可能是任何人），但主要目标当然是企业。 [Gnip](http://gnip.com/) 是唯一拥有这些权利的其他公司。 +* 我们的主从设置会在至少 3 台不同的计算机上复制我们的搜索引擎 -DataSift 是由 DataSift 的创始人兼首席技术官 Nick Halstead 在 [TweetMeme](http://tweetmeme.com/) 的经验基础上创建的，HTHT 是一种流行的实时 Twitter 新闻聚合器，一次可以处理每天 11 亿的页面浏览量。 TweetMeme 以发明社交信号机制而著称，该机制被称为“ retweet”，带有“ retweet”按钮，这个想法来自更早的名为 [fav.or.it](http://www.webonorme.net/blogging/launched-favorit-nick-halstead.htm) 的创业公司。 想象一下您是否会在*之前的某个时间像在整个虚拟地方贴上*按钮一样。 +* 我们每个月处理超过 60 亿个查询 -因此，大规模处理 TweetMeme 对 DataSift 的员工来说并不是什么新鲜事，而面临的挑战是将这种经验转变为 Internet 规模的平台，以便其他人也可以做同样的事情。 那是一个多年的冒险之旅。 +* 我们每个月接收和处理超过 200 亿次写操作 -DataSift 将自己定位为实时数据挖掘平台。 这里的平台角度确实是带回家的关键信息。 他们正在追求用于处理实时流的真正平台策略。 TweetMeme 虽然取得了成功，但它并不是一家[十亿美元的公司](http://www.youtube.com/watch?v=MowmiwavILM)，但是 BigData 平台可以发展到如此之大，这就是他们前进的方向。 尼克（Nick）的货币报价突出了霓虹灯的逻辑：“按钮上没有钱，数据上有钱。” +就像罗马不是一天建成的，我们的基础架构也不是很好。 本系列文章将探讨我们在构建基础架构时采取的 15 个工具步骤。 我什至将讨论我们的中断和错误，以便您了解我们如何使用它们来改进我们的体系结构。 -平台游戏背后的部分策略是，通过围绕您的核心价值主张构建巨大的技术护城河，从而成为老牌玩家。 当其他人来敲门时，由于您进入的技术壁垒过高，他们无法越过您的护城河。 这就是 DataSift 试图做的。 护城河上的吊桥更适合使用 Twitter 的 firehose，但真正的强大之处在于他们正在尝试创建的 Google 质量实时数据处理平台基础架构。 +该系列的 [第一篇博客文章](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html) 专注于我们 Beta 的早期。 这篇博客文章将重点介绍从 2013 年 9 月到 2014 年 12 月我们服务的前 18 个月，甚至包括我们的首次停机！ -DataSift 的真正创新在于创建一个 Internet 规模的过滤系统，该系统可以快速评估非常大的过滤器（认为 Lady Gaga 的追随者规模），并结合虚拟化带来的经济效益，在这种情况下，拥有更多客户的客户可以分享资源，因此您赚得更多的钱。 +## 步骤 4：2014 年 1 月 -他们如何使所有这些魔术发生？ 让我们来看看... +### 部署是高可用性的大风险 -Site: [http://DataSift.com](http://DataSift.com) +目前，我们的主要关注之一是确保我们的发展敏捷，同时又不以牺牲稳定性为代价。 因此，我们开发了一个包含 6,000 多个单元测试和 200 多个非回归测试的测试套件，以确保代码更改不会引入新的错误。 不幸的是，这还不够。 通过我们所有测试的一项新功能引入了一个生产错误，该错误导致 [八分钟的索引停机时间](https://blog.algolia.com/postmortem-todays-8min-indexing-downtime/) 。 值得庆幸的是，由于我们的体系结构旨在将搜索查询与索引分开，因此不会影响搜索查询。 -## 信息来源 +此问题帮助我们确定了高可用性设置中的几个问题： -* 本文末尾列出的文章和视频。 -* 主要来源是对以下人员的采访： [Nick Halstead](http://datasift.com/user/nickhalstead) ，DataSift 的创始人兼 CTO; [DataSift 的首席架构师 Lorenzo Alberton](http://www.alberton.info/) 。 +* 回滚需要很快，因此我们开发了使用单个命令行执行回滚的功能。 -## 统计资料 +* 部署脚本需要执行完整性检查，并在出现错误时自动回滚，因此我们将其添加到了部署过程中。 -* 您无法获得整个 Twitter 的水火。 如果这样做，每千条推文将收取 10 美分的费用。 每天有 2.5 亿条推文。 每天需要 2 万 5 千美元的许可费用。 -* 936 个 CPU 内核 -* 每台服务器支持 16,000 个数据流 -* 每天处理整个 Twitter Firehose 250+百万条推文。 相比之下，Visa 说，在 2007 年，他们处理了 276.12 亿笔交易，估计在一天中最繁忙的 8 小时内每秒处理 2100 笔交易。 这些都是完整的交易。 -* 当前峰值每秒传递 120,000 条推文（260Mbit 带宽） -* 执行 250+百万次情感分析，延迟不到 100 毫秒 -* 每天通过平台传输 1TB 的增强数据（包括性别，情感等） -* 数据过滤节点最多可以处理 10,000 个唯一流（每秒流过 8000+条推文的峰值） -* 可以实时对 10,000,000 个以上的用户名列表进行数据查找 -* 链接增强每天执行 2700 万个链接解析+查找，以及 15+百万个完整的网页聚合。 -* 30 名员工 -* 4 年的发展 +* 我们不应该仅仅因为测试通过 而部署到所有生产集群。 在此问题之后，我们对集群进行了一系列部署。 我们从测试集群开始，然后是社区集群（免费客户），最后是付费用户集群。 -## 平台 [ +今天，当要测试一项新功能时，我们的部署有所不同。 我们选择一组集群进行测试，然后使用以下步骤进行部署： -### 使用的语言 +1. 部署到所选集合的所有群集中的第一台计算机。 -* C ++用于关键性能组件，例如核心过滤引擎（自定义虚拟机） -* 用于站点的 PHP，外部 API 服务器，大多数内部 Web 服务以及定制的高性能作业队列管理器。 -* Java / Scala，用于与 HBase 通信，Map / Reduce 作业以及处理来自 Kafka 的数据 -* Ruby 为我们的厨师食谱 +2. 监视 24 小时，然后部署到所选集中所有群集中的第二台计算机。 -### 资料储存库 +3. 监视 24 小时，然后部署到所选集中所有群集中的第三台计算机。 -* SSD 驱动器上的 MySQL（Percona 服务器） -* HBase 集群（当前，约 30 个 hadoop 节点，400TB 存储） -* Memcached（缓存） -* Redis（仍用于某些内部队列，但可能很快将被撤消） +4. 几天后，我们部署到了所有生产集群。 -### 消息队列 +使用这种方法，我们能够在几个小时内检测到几乎不可能通过单元测试发现的错误。 由于我们每月有数十亿的查询，因此这种检测是可能的。 -* 0mq（来自最新的 alpha 分支的自定义版本，已进行一些稳定性修复，以使用发布者端过滤），并用于不同的配置中： - * PUB-SUB 用于复制/消息广播； - * PUSH-PULL 用于循环工作负载分配； - * REQ-REP 用于不同组件的运行状况检查。 -* Kafka（LinkedIN 的持久性和分布式消息队列），用于高性能持久性队列。 -* 在这两种情况下，他们都与开发人员合作，并提供错误报告/跟踪/修复/客户端库。 +# 第 5 步：2014 年 3 月 -### CI / Deployments +### 管理大量写操作 -* 每 5 分钟（如果有更改）从 Jenkins 的回购中提取所有代码（无论使用哪种语言），并使用几种 QA 工具自动进行测试和验证。 -* 每个项目都以 RPM 的形式构建和打包，然后移至 dev 软件包仓库。 -* 多个环境（开发，集成，QA，分段，生产）或不同的策略和测试级别。 -* Chef 自动执行部署和管理配置。 +当我们在加拿大/东部和欧洲/西部的集群很好地处理了我们的增长时，我们开始解决一个新问题：延迟。 来自亚洲的集群的延迟太高，无法获得令人满意的性能。 我们决定首先通过在 AWS 中部署计算机来测试市场。 我们不愿意做出选择，因为即使使用 AWS 提供的最佳 CPU（当时的 E5-2680），搜索查询的性能也比 E5-2687W CPU 低 15％！ 我们这样做是为了减少启动实验的时间，但要确保不引入对 AWS 的任何依赖关系。 如果测试成功，这使我们可以轻松地迁移到其他提供商。 在纸上，一切看起来都不错。 当我们发现他们的虚拟化不支持 AVX 指令时，我们遇到了一个问题，这对我们来说是重要的功能。 我们必须生成没有 AVX 指令集的二进制文件（这再次降低了搜索查询的性能）。 -### 监控方式 +在享受我们最近在新加坡推出的服务时，我们开始收到一些来自欧洲客户的投诉，他们抱怨他们的搜索查询延迟时间增加。 我们很快发现它与大量的索引操作相关联，这很奇怪，因为我们确信索引和搜索 CPU 使用率之间的体系结构划分正常工作。 经过调查，我们发现用于处理写操作的整个集群的分布式一致性的共识算法存在潜在的瓶颈。 当出现瓶颈时，它将阻塞 HTTP 服务器线程。 然后，这将导致搜索查询需要等待线程。 我们是无意中设计造成的！ -* 所有服务都会发出 StatsD 事件，这些事件与其他系统级检查结合在一起，添加到 Zenoss 中并与 Graphite 一起显示。 +我们通过在达成共识之前实施队列来解决此问题。 它使我们能够收到大量的写操作，进行批处理，然后将其发送给共识。 共识不再存在于 HTTP 服务器的序列中，因此写操作无法再冻结 HTTP 服务器线程。 在正常操作期间，除了将作业传递给共识以外，队列什么都不做。 在出现峰值的情况下，它允许我们在达成共识之前进行缓冲和批量处理。 进行此更改后，我们没有冻结任何群集。 -## 图片中的建筑 +## 步骤 6：2014 年 4 月 -DataSift 为其整体架构创建了一张很棒的图片。 这是一个小版本，要查看完整版本，请在处转到[。](http://farm8.staticflickr.com/7159/6408735793_0fa14eedf6_o.png) +### 一个数据中心几乎无法实现网络高可用性 -![](img/aca6888e6964bb61c0b4df68f993db88.png) +从 2014 年 4 月开始，我们开始收到使用在加拿大/东部使用集群的美国东部客户的投诉。 我们在美国西部的用户没有受到影响。 我们立即怀疑加拿大和美国东部之间存在网络问题，并发现我们的提供商正在报告同一问题。 一场车祸使蒙特利尔和纽约之间的一根含 120 根纤维的管道破裂。 所有的交通都在经过芝加哥的不同路径上进行。 不幸的是，带宽不足以防止数据包丢失。 中断不仅影响了我们的提供商，而且影响了加拿大和美国东部之间的所有流量。 这类事故可能会破坏我们经常忘记的互联网，但仍然可能发生。 那天我们除了帮助每个客户并通知他们当前的情况外，无能为力。 -* 该图分为两半：左边的所有内容都是数据处理，右边的所有内容都是数据传递。 系统中运行 40 多种服务，其中包括：许可证服务，监视服务，限制服务等。 -* 整个系统有许多不同的扩展挑战，必须几乎同时解决：处理 firehose，低延迟的自然语言处理和推文上的实体提取，低延迟的推文内联增强，低延迟处理非常大的单个过滤器 ，对来自大量客户的大量复杂过滤器进行低延迟评估，链接解析和缓存，并通过保留每天发送的 1TB 数据来保留防火墙的历史记录，从而可以根据 firehose，实时计费，实时身份验证和授权，可让客户了解其流状态的仪表板，将过滤器结果流式传输到数千个客户端，监视每个机器，每个过滤器和每个子系统，负载和性能测试， 网络流量和服务之间的消息传递以低延迟的容错方式。 -* 我们不会涵盖它们所做的每一行或每一行，但我们将重点介绍。 +就在这一天，我们开始了一场大型基础设施讨论。 我们需要依靠更多的提供商，数据中心和网络提供商来提高高可用性。 更重要的是，我们需要在美国拥有基础设施。 通过从加拿大为美国服务，我们可以削减成本，但高可用性受到了影响。 我们需要真正分布我们的基础架构。 我们不能再在一个提供商上拥有多个可用区！ -## 基本思路 +## 步骤 7：2014 年 7 月 -* **全部的要点**： - * **数据访问**的民主化。 消费者可以自己进行数据处理和分析。 如果他们愿意，一个人应该能够确定哪种早餐谷物得到的推文最多，处理数据，制作图表并将其出售给品牌。 有了一个可能的平台，而如果您必须建立自己的 tweet 处理基础架构，那几乎是不可能的。 - * **作为数据**服务的软件。 将信用卡放入一个小时或几个月的数据中。 Amazon EC2 模型。 收取使用费用。 没有巨大的注册期或费用。 可以是小型或大型播放器。 - * **您确实不需要大数据，需要洞察力**。 现在我们如何处理数据？ 自己创建见解的工具。 数据毫无价值。 数据必须在上下文中使用。 - * 这个想法是**创建一个全新的应用程序**，这是 Twitter API 所无法提供的。 -* [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) （提取，转换，加载）。 可以将 DataSift 视为一种 [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) 样式的系统，将实时数据流作为输入，将应用程序作为输出。 -* **提取** - * 数据是从多个来源读取的，但是目前主要吸引 Twitter 的 firehose 许可访问。 Twitter 是 Twitter 的所有公开推文。 您还可以访问 Digg 和 MySpace 数据。 - * 身份不是在不同的数据源之间建立的，但是它们会规范化所有数据，因此您可以知道用户名的位置，从而可以匹配身份。 -* **转换** - * 数据从防火墙中提取出来并进行标准化。 Twitter 数据具有高度维度，具有 [30 个属性和](http://www.readwriteweb.com/archives/this_is_what_a_tweet_looks_like.php)属性，您可以访问所有这些属性。 这些属性包括地理位置，名称，配置文件数据，推文本身，时间戳，关注者数量，转发数，已验证的用户状态，客户端类型等。 - * 实体提取和自然语言处理应用于推文。 例如，确定语言，并在元数据中提供该结果。 - * 当一条 tweet 进入时，他们必须查询 5 种不同的服务才能用更多数据扩展 tweet。 包括情绪分析，性别检测和 Klout 得分。 - * 解析每个链接并提取内容，以便可以将过滤器应用于内容和链接本身。 - * 他们计划随着时间的流逝增加更多的服务。 - * 在过滤过程发生之前，数据已被详细阐述。 -* **过滤** - * 您无法支付全部费用，因此使用了一种相对简单的声明性语言，称为 [CSDL](http://dev.datasift.com/csdl) ，以过滤掉不需要的 Tweets 并保留您想要的 Tweets。 - * 过滤器如下所示： *interact.content 包含“ apple”，而 interaction.content 包含“ orange”* - * 与过滤器匹配的所有推文形成一个流。 每个流都分配有一个标识符，该标识符看起来像“ 4e8e6772337d0b993391ee6417171b79” - * 随处可见对话流。 流是应用于输入的 CSDL 过滤器的输出。 通过过滤器，您可以创建您感兴趣的事件流。 - * 流标识符包含在规则中，以进一步限定流中应包含哪些推文。 规则以过滤器和其他规则为基础：*规则“ 4e8e6772337d0b993391ee6417171b79”和 language.tag ==“ en”* - * 可扩展筛选是 DataSift 的主要创新。 他们使用编译器在整个集群中高效地调度过滤器。 他们花了 3 年时间开发了可伸缩的规则评估解决方案。 - * 规则由过滤器的[组合组成，可以包含 1000 千个潜在的数百万项。 可以在数百台计算机上计划一次评估数百万条规则。 规则可以重复使用并按层次排序。](http://blog.datasift.com/wp-content/DataSift-Introduction-Webinar-small.pdf) - * 过滤器包括正则表达式，例如，您可以基于配置文件中的文本过滤掉推文。 有许多不同的目标和运算符。 -* **加载** - * 外部应用程序可以通过 REST API，HTTP 流或 Websocket 访问与过滤器匹配的推文。 - * 客户端库适用于：PHP，Ruby，C＃，Java，Node.js。 自己保存编写 HTTP 请求。 - * 您收到的是 JSON 对象，其中包含所有数据的规范化，完全增强格式。 您会在信息流中获取性别，地理位置，兴趣点，国家/地区，作者，推文，关注者数量，Klout 得分等。 每个消息最多有 80 个字段。 -* **应用程序** - * 应用程序通过一种出口策略接收一个详细阐述的 JSON 对象。 DataSift 只是筛分，它不会烘烤。 因此，如果您希望使用默认转换之外的 tweet 来完成某些工作，则必须编写一个应用程序来完成。 - * 不能保证以任何顺序发送推文，也不能保证您看到有史以来发送的所有推文。 应用程序必须在聚合/采样的基础上工作。 -* **结算** - * 计费以称为 **DPU** s 的神奇单位表示-数据处理单位。 每个过滤器都分配有一个 DPU。 每 DPU 每小时收费 20 美分。 您可以运行的最便宜的是 1 个 DPU，一整个月运行一个流将花费 150 美元。 - * 这个想法是，您使用的资源越多，您应该支付的费用就越多。 -* **开发** - * 寄存器。 查看[示例流](http://datasift.com/solutions/prebuiltstreams/)。 - * 学习 [CSDL](http://dev.datasift.com/csdl) 。 写你的过滤器。 - * [在线预览](http://console.datasift.com/)过滤器，以查看获得的结果的质量。 他们不仅返回原始数据。 他们有一个流浏览器，它具有地图视图，词云视图以及显示情感和性别的图表等。 - * 微调。 获得所需的结果，并查看 DPU，看您是否负担得起。 - * 使用您选择的 API 收集数据并对其进行处理。 您如何处理数据取决于您自己。 您可以实时内联处理。 也许显示一些图形。 将其存储在您自己的数据库中以进行后期处理。 - -## 关键思想 - -### 用例 - -考虑到大多数推文在每个人看来都是多么愚蠢，几乎很难想象它们具有共同的价值，因此看看人们可能希望将这些系统用于什么的目的是很清醒的： - -* 广泛的趋势是将数据集合并在一起。 将筒仓数据集整合在一起，以获得更好的见解。 将社交媒体数据与客户数据进行大规模合并，您可以开始看到行为模式与两个数据集之间的见解之间的相关性。 -* 策展，监视，警报。 -* 跟踪：电视节目，政治，天气，感冒等 -* 金融。 查看人们对公司的反应。 -* 每个人买什么？ 在逐月范围内寻找广泛的趋势。 -* 使用 Google 搜索来自世界各地所有星巴克附近拥有 500 多个关注者的文字推文。 -* 减灾。 知道需求在哪里。 -* 将所有百思买的位置放到规则中，这样您就可以在百思买中查看推文，而不必知道使用井号来自百思买的推文。 适用于任何事件或位置。 -* 策划新闻。 查看具有一定数量转推的信息源。 看主题说是否技术。 全部实时，以毫秒为单位。 - -小牛肉通常的混合加上深奥的味道。 如何使用此电源取决于您。 - -### 实时只有远距离的后果 - -DataSift 作为实时过滤系统的性质具有深远的影响。 请记住，它没有内存。 它没有历史。 您没有看到可以在任何方向进行迭代的有序流。 您正在从防火墙上获取实时数据。 这些推文指向过滤器，通过过滤器，然后像夜晚一样消失了。 - -这是一个采样模型。 您无法认为您正在消耗整个流。 任何希望按顺序查看帐户中所有推文的应用程序都将无法正常工作。 面向的应用程序类型是可以准确采样高度针对性的数据的应用程序。 - -例如，如果您想使用 DataSift 将 Twitter 用作消息总线来构建实时控制系统，则它将无法正常工作。 您不能保证可以看到一个帐户中的每个命令，也不能保证这些命令的顺序正确。 +### 首次在两个数据中心中部署 -您可以解决的问题类型是创建一个过滤器，该过滤器将在 10 秒内提及 100 次“地震”一词时触发。 然后，您可以使用地理位置信息来确定发生地震的位置。 不需要任何鸣叫顺序，也就可以看到每条鸣叫。 这是另一种心态。 +我们发现在单个数据中心中进行部署是不够的。 我们决定从最大的客户之一开始，在两个不同的数据中心（它们之间相距 100 公里以上）部署一台机器。 这两个数据中心使用的是同一提供程序（相同的自治系统），并且已经提供了高可用性级别，比云提供程序的多个可用性区域略高一点。 这是由于两个数据中心位置在网络链接和电源单元方面完全不同。 -### 仅过滤器具有远距离后果 - -让我感到惊讶的是，DataSift 仅是一个实时过滤引擎（因此名称中带有“ sift”一词）。 合作伙伴应提供更高级别的服务。 +根据我们过去的经验，我们花了这段时间来设计具有下一代 CPU 和 SSD 的硬件的下一版本： -我期望 DataSift 成为一个有状态的细分平台，使人们能够回答“居住在美国的 18-24 岁男性有多少？”之类的问题。 DataSift 不计数，因此它不能具有细分平台的滑动窗口计数功能。 +* Xeon E5-1650v2（6 核，12 线程，3.5Ghz-3.9Ghz） -这是因为它是**无状态**的结果。 从技术上讲，DataSift 也无法识别年龄段，这主要是因为 Twitter 具有相当贫乏的个人资料功能。 DataSift 将 Firehose 存储在 HBase / Hadoop 中，以进行离线分析，但这不是实时的。 +* 128G RAM -因此，您必须将头围绕过滤器模型。 在 DataSifts 的平台上无法执行任何应用程序逻辑。 没有存储过程。 可以通过诸如情感分析之类的增值服务在线增加推文，但这是一个高度结构化和受限的过程，而不是您的应用程序。 而且，如果您期望使用某种管道模型，那么也可以。 流无法通过一系列换能器通过管道进行编织。 - -之所以说 DataSift 是有原因的。 DataSift 是高度复杂且可扩展的过滤器系统。 它过滤掉了 firehose 中的 tweet，以创建针对性强的 tweet 流，供您在单独的应用程序中进行处理。 他们的工作是使数据深入到执行分析所需的 tweet 的横截面。 数据进入并根据规则进行匹配，如果不匹配，则将其丢弃，如果匹配，则将其放入您的存储桶中。 过滤器就像一个手套，只有最值得的通过。 - -仅过滤器模型的驱动程序是： **firehose scale 和低延迟**。 消防水带以很高的速率产生事件。 您将如何构建一个互联网扩展平台，该平台可将应用程序逻辑折叠成潜在的数百万客户？ 您如何做到这一点，并建立一个可以保持低延迟保证的端到端系统？ 你不能 - -你能做什么？ 评估大型过滤器。 快速。 下一节将对此进行更多介绍。 - -### **过滤引擎** - -* **当人们想到过滤器时，他们可能会想到 SQL select 语句，这些语句出于性能原因不建议使用大的“ where”子句。 DataSift 采用相反的方法，它们假定了非常多的过滤条件集，并且使评估具有可扩展性和效率。 他们的目标示例包括监视世界上每个星巴克的所有推文，或将 Lady Gaga 的关注者列表加载到过滤器中。 过滤器中可能有数百万个术语，它们是实时评估的。** -* **如此规模的过滤需要使用其他方法。 他们** 从他们在 TweetMeme 所做的工作开始。 核心过滤器引擎使用 C ++，称为“ Pickle Matrix”。 -* 三年多来，他们已经开发了编译器和自己的虚拟机。 我们不知道他们的技术到底是什么，但可能类似于带有查询重写的[分布式复杂事件处理。](http://www.doc.ic.ac.uk/~migliava/papers/09-debs-next.pdf) -* 编译器采用过滤器并以 Manager 和 Node 服务器为目标群集。 经理的工作是确定规则是否在其他任何地方加载，以及是否可以放置在高度优化的地方，例如靠近运行类似流的其他人。 Node 的工作是在规则上发布推文，获取匹配项列表，然后将匹配项推入管道。 -* 他们具有巧妙的算法来消除工作负载的重复数据，因此可以尽可能多地共享规则。 每个过滤器都不是孤立运行的。 过滤器形成一个共享空间。 如果有一个仅针对 Lady Gaga 引用进行过滤的过滤器，则该过滤器将在每个推特上运行一次，并使用同一过滤器在所有规则之间共享结果。 要完成这项工作，需要非常聪明的编译器和调度算法。 回报是惊人的。 不再持续运行重复的过滤器，它们仅运行一次。 -* 规则可以是分层的，编译器很聪明地尝试将它们放在一起，以便它们共享规则评估。 如果节点已经有一个规则，那么它将吸引使用该规则的过滤器。 该规则仅对节点上的所有筛选器运行一次。 -* 这是一种虚拟化方式。 通过将多个客户的工作负载组合在一起，他们可以利用过滤器中的任何共性。 即使每个操作只运行一次，DataSift 也会为每个操作付费。 例如，如果共享一个正则表达式，则仅运行一次。 它无法始终以这种方式工作，也许节点已加载，因此无法使用其他客户端，因此它必须在另一台计算机上运行。 -* 整个配置在运行时可以动态更改。 他们的调度算法一直在关注监视数据。 如果等待时间超过阈值，则将重新配置系统。 -* 过滤器会立即在内存中处理。 例如，每台服务器可以运行 10,000 个流。 -* 节点具有规则缓存，因此可以共享它们。 -* 编译器支持短路以优化滤波器。 -* 例如，如果一个正则表达式大于整个机器，则它们将自动在节点之间进行负载平衡。 请记住，大型过滤器是预期的标准。 如果要对 Lady Gaga 的所有关注者进行过滤，则过滤器的可伸缩性必须是核心功能。 - * 筛选引擎已分片。 每个分片都接收完整的流水线，并且所有分片都将处理每个``交互''（即``tweet''或``FB status''或``blog post''），整理其结果后再发送到下游。 - * 单个分片中的 N 个节点中的每个节点（都是彼此的副本）以循环方式接收到 1 / N 的软管。 - * 因此，假设有 2 个分片，每个分片 3 个节点，则每个分片上将找到 50％的过滤器。 分片中的每个节点都将接受软管的 1/3（并且上面将有 50％的过滤器）。 它将是该碎片中其他节点的副本。 - * 因此，如果加载了非常重的过滤器，则可以通过将更多的节点添加到重规则加载到的分片中来平衡，从而减少单个节点必须处理的消防水带数量。 - * 到目前为止，还没有单个过滤器对于单个节点来说太沉重，但是他们正在考虑拆分过滤器处理，因此先对子谓词进行大规模处理，然后再对所得的过滤器进行单独处理。 他们已经针对嵌入式规则进行了此操作（例如，给定一个过滤器，例如“让我获取所有包含'apple'AND 匹配规则 XYZ 的推文”，过滤器 XYZ 会分别处理）。 -* 客户需要大力推动创建可重用的公共规则，以鼓励数据流的可重用性。 人们可以按照自己的规则使用任何公共流。 例如，某人可能制作了一个肮脏的单词过滤器来创建流。 您可以使用它来构建该流。 每个人都共享同一流，因此，如果有 1000 个用户使用脏字过滤器，则该过滤器不会得到 1000 次评估。 该过滤器将为每个人进行一次评估，非常高效。 - -### 每个推文的增强管道 - -推文增加了第三方数据集。 使这些扩充具有低延迟是一个主要的痛点。 - -* 当一条 tweet 进入时，他们必须查询 5 种不同的服务才能用更多数据扩展 tweet。 例如，Klout 有 1 亿个 Twitter 个人资料，因此它们在内部针对 Klout 数据库的本地副本执行数据库请求。 他们将数据集带入系统，而不是通过 Internet 进行 API 服务调用。 -* 为了将数据集引入他们的系统，他们需要建立紧密的伙伴关系。 他们的情绪分析引擎已获得许可，快速，可集群化，并且适合于每天处理 5 亿次点击，且延迟低。 -* 每个服务必须具有< 100 毫秒的响应时间。 500 毫秒后，它就会被丢弃。 -* 每 10 条推文中就有 1 条是链接。 这样他们就可以获取内容，并根据您的内容进行过滤。 因此，如果提及某个品牌，则可以根据实际内容进行解析，以找出所有含义。 - -### 没有云为他们 - -* AWS 曾用于生成测试流量，但对于分布式应用程序，他们认为 AWS 太有限了，尤其是在网络中。 当节点连接在一起并且需要彼此通信时，AWS 的表现不佳。 没有足够低的延迟网络。 他们的客户关心延迟。 -* 他们必须注意一些细节，例如如何设置交换机以及如何通过主负载均衡器路由它们。 -* 从 Twitter 了解有关使用自定义数据包大小的信息。 他们正在使用巨型帧。 -* 由于规模的原因，Twitter 可能会在未来细分市场。 -* 他们与 Twitter 的联系是通过 Internet 进行的，没有对等关系。 - -### 平台意味着开放 - -* 首先构建一个 API，然后在该 API 上构建网站。 您可以使用 GUI 制作自己的导入工具，这些工具很酷。 -* 目的是通过让开发人员将 DataSift 嵌入其应用程序来使其不可见。 这是一个平台，该平台的工作是消除处理海量数据的难题。 其他人可以在其他系统中建立桥梁。 DataSift 希望专注于过滤和数据处理。 让其他人提供 GUI 等。 +* 英特尔 SSD S3500（2x480G）或 S3700（2x400G）。 我们将 intel S3700 用于每天写入量较高的计算机，因为它们更耐用 -### 开票 +我们所做的更改主要围绕 CPU。 我们从未在 E5-2687W 上使用 100％的 CPU。 E5-1650v2 是下一代 CPU，并提供了更高的时钟速度。 结果是，与以前的 CPU 相比，我们的服务速度提高了近 15％。 毫秒很重要！ -* 负担得起的实时计费产品不存在，因此它们构建了自己的产品。 面临的挑战是使人们对实时计费解决方案感到满意。 -* 客户是实时计费的。 您可以查看您的仪表板，以了解正在花费什么。 亚马逊和 Google App Engine 的经验表明，这是系统中非常重要且非常棘手的部分。 钱就在这里。 -* 他们使用称为 DPU 的定义单位-数据处理单位进行收费。 您让他们使用的资源越多，过滤器的成本就越高。 -* 每个过滤器都分配有一个 DPU。 -* 每 DPU 每小时收费 20 美分。 10 DPU 过滤器的价格为 2 美元/小时。 -* 您可以运行的最便宜的是 1 个 DPU，一整个月运行一个流将花费 150 美元。 -* 在 1 万个地理位置上进行过滤将非常昂贵。 查找一个正则表达式会很便宜。 -* 正则表达式很便宜，但是时间越长，处理时间就越长，这意味着它们更昂贵。 地理多边形的处理相当复杂。 一长串关键字非常便宜，因为它们使用散列。 词组匹配和近词匹配稍微贵一些。 -* 这样做的想法是，与为不需要的数据支付许可费用相比，过滤尽可能小的数据集要便宜得多。 -* 如果您运行 10,000 个数据流，但最终只占到了 Firehose 的 50％，但是他们不只是出售了 50％的 Firehose，而没有数据处理，因为这与他们的平台无关。 -* 他们希望客户尽可能详细地描述他们想要从过滤器中获取的数据。 -* 由于 Twitter 上有 50 至 50 位男性和女性之间的对等关系，因此，所有男性都将占流水线的 50％或 1.25 亿条推文。 为男性制作的所有推文创建过滤器并不是一件容易的事。 这将是非常昂贵的。 您要做的就是查看用例。 您是银行吗？您是药店吗？要弄清楚您对什么感兴趣。 要尽可能具体。 一些公司每天只会发送一条推文。 每天 2.5 亿条推文中，问题是如何创建过滤器以获取所需的两个或三个。 -* 客户可以设置阈值，以便他们可以决定每天花费多少。 您不想运行会在几秒钟内耗尽预算的流。 -* 为了准确计费，系统具有广泛的监视功能。 仪表板显示整个平台的运行状况。 可以看到系统中任何点之间的流程，每个点之间的延迟。 所有服务器的运行状况，吞吐量，流量变化都可能突出问题。 +## 步骤 8：2014 年 9 月 -### 输出侧 +### 在美国的存在！ -* 真正的痛点是输出端。 您如何将推文从中心位置传递到用户所连接的正确服务器上？ 最终使用 0mq。 使用发布和订阅可以大大减少内部网络流量，延迟和软件复杂性。 他们现在几乎在任何地方都使用它。 非常灵活 为了获得高可用性，它们广播给几个听众。 -* 尝试了几种技术来移动数据。 最初在所有地方都使用 HTTP，但这太慢了，并且具有很高的代码复杂性。 然后他们尝试使用 Redis 作为队列，虽然速度更快，但是无法处理规模。 他们每天通过 0mq 发送数十亿条消息。 -* Node.js 在其前端使用，用于 HTTP 流和 Web 套接字连接的端点。 Node.js 的强大功能令人惊讶，它可以进行网络数据传递。 该层很简单，它只是将数据直接传递，将套接字插入套接字。 他们为 Node 构建了自己的多线程模型。 -* 事件系统的问题是知道您为什么收到事件，以便可以将其分派到正确的处理逻辑。 例如，同一条 Tweet 可以匹配性别规则和脏话规则，并且每种情况下，Tweet 的处理方式必须不同。 DataSift 有几种方法可以使这项工作完成，但是它们具有非常智能的标记功能。 一旦子过滤器匹配，就可以对该事实进行标记并在元数据中传递。 该引擎允许您创建规则的任何层次结构，以便可以将规则结合在一起，然后使用标记来创建类别。 +在与数家提供商进行了数月的讨论之后，我们于 2014 年 9 月在美国东部（弗吉尼亚州）和美国西部（加利福尼亚州）与一家新提供商一起启动了该服务。 由于更好的延迟和带宽，第一步是改善我们在美国搜索体验的好方法。 高可用性方面的改进并不大，但是确实有助于我们更灵活地应对加拿大和美国东部之间过去的问题。 我们使用的方法与以前的位置相同：一家提供商内的可用区域不同（不同的网络设备和电源单元）。 -### 测验 +## 步骤 9：2014 年 10 月 -* EC2 用于生成流量。 防火墙为 60 Mbps。 -* 为了测试他们的系统，他们一次要运行相当于 11 台消防车的系统。 1000 个流，每个消防站的 1％将其传送到 1000 个连接。 他们遇到的瓶颈是托管提供商的网络带宽，而不是平台。 +### 通过厨师进行自动化 -### 将溪流汇入湖中 +随着我们需要管理的计算机数量的大量增加，我们将管理迁移到了 Chef。 以前，我们使用 Shell 脚本管理计算机，但是与 Chef 进行自动化相比，修复 Heartbleed（OpenSSL 漏洞）等安全问题非常耗时。 -DataSift 还支持非实时处理。 HBase 中存储了两个主要的推文集合： +Chef 所提供的自动化功能在配置数百台机器时非常有用，但它也有缺点。 迁移到 Chef 几个月后，菜谱中的错字导致某些生产服务器崩溃。 幸运的是，我们能够尽早发现问题。 由于推出了厨师客户的 CRON 工作具有非侵略性，因此对生产没有太大影响。 我们有足够的时间来做出反应并解决问题。 -* 过滤器可以具有侦听器，因此推文直接存储在 HBase 中，允许以后下载数据。 可以安排流的录制，然后稍后浏览/使用它。 -* 录制整个消防水带是一项巨大的技术挑战。 在两个月内，他们将使人们可以在存储在 HBase / Hadoop 中的持久性版本的 firehose 上运行其筛选器。 这个想法是能够对您感兴趣的任何方面进行分析。 扩充所有数据后，每天通过该平台的数据总计将增加 1 TB，因此要存储大量数据。 +我们非常幸运遇到此问题，因为该错误可能会破坏生产。 为了避免再次发生此类问题，我们决定将生产手册分为两个版本： -### 你如何赚钱？ +* 第一个版本（稳定版）已部署到所有集群的第一台和第二台计算机上 -作为开发人员，我一直对如何使用平台和服务为开发人员（不仅是创造者）赚钱感兴趣。 我的角度是，如果您在通过收取足够的钱来赚钱的服务之上构建服务，是否可以构建有利可图的服务，或者成本太高，或者您是否真的必须将高价值目标定为高 保证金产品证明成本合理？ 换句话说，例如，TweetMeme 可以基于 DataSift 获利吗？ 建立或购买问题始终是一个棘手的问题。 +* 第二个版本（生产版本）已部署在所有集群的第 3 台计算机上 -* **内部使用**。 如果您是使用 DataSift 来了解自己的产品的企业，那么您所获得的任何价值都可以证明其成本是合理的。 这很简单。 -* **服务**。 DataSift 认为自己可以提供商品化的数据交付，并且其成本只是从 Twitter 获取数据和开发人员所需时间来处理这些数据所需的基础结构成本的一小部分。 据他们估计，要建立一个像 Radian6 这样的社交监控服务，需要在系统上花 3 个月的时间。 您只需要专注于界面。 数据收集和处理部分得到处理。 如果您能找到合适的市场，那将具有很大的价值。 -* [App Store](http://blog.datasift.com/2010/11/02/datasift-app-store/) 。 DataSift 计划为第三个部分开发人员提供一个应用程序商店。 -* **增强服务**。 DataSift 将支付服务费用以作为其扩充渠道的一部分。 该模型是收益分成。 如果有人使用像 Klout 这样的平台，他们将收益分享给他们。 问题是找到可以扩展到 Twitter 级别的合作伙伴。 +对我们的菜谱进行任何修改时，我们首先将修改应用于生产版本。 经过几天的测试，我们将修改应用于稳定的食谱版本。 高可用性需要在所有级别上应用！ -## 得到教训 +## 第 10 步：2014 年 11 月 -* **平台和生态系统的力量。** 如果平台策略执行得当，它将成为进入市场的巨大障碍。 它也是观察下一波趋势发展的最高观察站。 这是[创新/杠杆/商品化](http://www.youtube.com/watch?v=Y_F6nFIp_dA)模型。 DataSift 已经拥有 LinkSift 之类的域名，因此这是该大计划的一部分，该计划是使用他们的底层平台来提供更高价值的服务，以他们从平台市场中收集的情报为指导。 -* **按钮没有钱，数据没有钱。** 跟随钱**。** 您现在正在做的事情可能不在钱中，但是它可以指导您找到钱的地方。 -* **质量胜过废话。** 趋势是发布几乎不可行的软件，然后使用用户反馈迭代地对其进行改进。 DataSift 没有走这条路。 他们从一开始就发布了复杂的可扩展产品，其原因有两个：1）他们在 TweetMeme 的经验基础； 2）他们不觉得自己可以从小做起并立即重新构建。 -* **从结构上来说，无国籍状态是一个巨大的胜利。 DataSift 仅是实时的，因此不必在内存中保留很多状态，也不必担心按顺序传递事件而不会丢失甚至不会容忍任何错误。 计时是他们的痛点，可以降低端到端的延迟。 当然，这将状态负担推给了应用程序开发人员。** -* **从别人的错误中学习。** 当 Twitter 从 TweetMeme 许可了转发技术时，他们实际上并没有重用 TweetMeme 的代码。 Twitter 从该代码中学到了知识，并将 TweetMeme 用作咨询服务，这有助于 Twitter 在发布时立即进行转发。 相反，当 DataSift 学习如何处理防火墙时，DataSift 可以从 Twitter 犯下的所有早期错误中吸取教训，因此 DataSift 可以在发布时正确解决。 -* **服务**。 从一开始就很难使用服务进行设计。 他们从一开始就拥有一个体系结构，但是如何连接这些服务，如何使这些服务冗余，如何使这些服务响应故障以及如何在某件事失败的情况下使一切都不会失败-所有这些类型的问题都有 一直是痛点。 将组件划分为服务是解决这些分布式编程问题的关键。 服务还使每个组件都可以独立扩展。 -* **消息系统**。 以 0mq 为核心的消息传递系统将服务联系在一起并实现可靠性。 它的工作非常出色。 比使用 HTTP 好 1000 倍。 他们喜欢不同通信模式（发布-订阅，请求-响应等）的灵活性。 HTTP 在性能和使用它所需的代码量方面都有太多开销。 只需将消息传递到需要处理的代码即可。 它使接口保持异步，解耦和基于队列而不是阻塞。 -* **连接管理**。 实时流的最大瓶颈之一是如何处理连接和断开连接。 他们从 Twitter 中学到了很多东西。 建立连接时，它会触发大量下游活动来激活连接，例如身份验证，验证流请求，确定负载，计费服务，审计跟踪等。每秒能够运行数千个连接/断开连接是一个挑战。 从 PHP 重写为 C ++，并使其成为多线程。 -* **将常用案例折叠到平台**中。 在他们的人员期间，他们喜欢在列表中加载数百万的人员。 就像 Lady Gaga 的所有追随者一样。 指向列表并将其自动下载到规则中。 -* **指标比记录**更重要。 记录中总是会填满您不使用的内容。 能够为超出范围的指标创建警报更加有效。 当指标触发对问题的意识时，您可以查看日志。 -* **遵循 Salesforce 和 Amazon 模型**。 他们是一个按需云平台，它们将在开始的基础上构建层。 因此，DataSift 是引擎，他们将制造其他产品，如 UserSift 和 LinkSift。 -* **易货**。 不必花钱。 通过物物交换引导。 他们获得了赞助。 他们出售了旧域名，以资助购买新域名。 -* **将一种产品的经验转化为另一种**。 TweetMeme 使用基于 RSS 提要的 fav.or.it 基础结构。 这使 TweetMeme 得以快速开发。 同样，构建 TweetMeme 的经验使跳转到 DataSift 变得容易得多。 他们从 TweetMeme 学习了可伸缩性，并建立了一流的工程团队。 -* **一切都至关重要**。 例如，他们在整个网络设备中都遇到帧缓冲区大小的问题。 他们发现，开放 HTTP 流连接比简单的 REST 调用更难扩展，因为它带来了网络中的许多潜在问题。 当他们使用 REST API 时，他们没有看到这些问题。 +### DNS 是体系结构中的 SPoF -从我的采访，阅读和查看十几个其他采访中，我对 DataSift 的思维和努力质量印象深刻。 我不知道它是否当然会成功，或者是否会成功，但是如果我失败了，那是因为缺乏专业精神。 企业家转变为 VC 的 Mark Suster 解释说，他对 DataSift 的投资是[在 Twitter 生态系统](http://www.bothsidesofthetable.com/2011/07/10/why-im-doubling-down-on-the-twitter-ecosystem/)上的投入增加了一倍。 我认为这是错误的观察方式。 DataSift 可以快速轻松地与任何流一起使用。 也许更好的方法是将 DataSift 加倍。 +随着时间的流逝，我们开始收到越来越多的用户反馈，指出我们的服务间歇性地变慢，尤其是在亚洲。 经过调查，我们发现.io TLD 的使用是造成此问题的原因。 事实证明，.io TLD 的任意播网络的位置少于主要 TLD（.net，.com 和.org）的位置，并且 DNS 服务器超载。 用户有时在 DNS 解析期间会遇到超时。 -## 相关文章 +我们与 CDN 提供程序讨论了此问题，他们都告诉我们最佳实践是使用.net TLD。 我们需要从.io 迁移到.net！ 在准备发布分布式搜索网络时，我们决定迁移到另一个 DNS 提供商。 该新提供商提供了链接域功能，这意味着它们将处理 [algolia.io](http://algolia.io) 和 [algolia 之间的同步。 net](http://algolia.net) ，这样我们就可以轻松地保持向后兼容性。 -* [这篇关于黑客新闻](http://news.ycombinator.com/item?id=3292604)的文章 -* [具有查询重写功能的分布式复杂事件处理](http://www.doc.ic.ac.uk/~migliava/papers/09-debs-next.pdf)，作者：Nicholas PoulSchultz-Møller，Matteo Migliavacca，Peter Pietzuch -* [推文可以告诉您什么](http://www.readwriteweb.com/archives/what_a_tweet_can_tell_you.php)，作者：Marshall Kirkpatrick -* [Gnip 和 DataSift 有什么区别？](http://www.quora.com/What-is-the-difference-between-Gnip-and-DataSift) -* [DataSift 链接分辨率]( http://www.youtube.com/watch?v=JAN47Hw6o8w) -* [可扩展性的艺术-管理增长](http://www.alberton.info/talks/show/id/3)，作者：Lorenzo Alberton -* [有关“类固醇轨道：” DataSift]( http://www.youtube.com/watch?v=X7aiKaCi8O8) 的更多详细信息-采访 Robert Scoble -* [DataSift 的定价是否会对初创企业起到威慑作用？](http://www.quora.com/Is-DataSifts-pricing-a-deterrent-for-startups) -* [在 Twitter 提要之上的应用程序的基础架构（带宽）有多昂贵？](http://www.quora.com/How-expensive-is-the-infrastructure-bandwidth-of-an-app-on-top-of-Twitter-feeds) -* [问&答：尼克·霍尔斯特德（Nick Halstead）使用 Datasift](http://www.wired.co.uk/news/archive/2011-10/12/nick-halstead-mining-twitter ) 挖掘 Twitter 的火喉。 -* 要点：[将 Paul S. Watson 的 DataSift Twitter 交互流记录到 Google Fusion Table](https://gist.github.com/1389349) 中 -* [新的 DataSift 首席执行官表示，Twitter 的未来在于数据，而非广告](http://www.themediabriefing.com/article/2011-11-17/the-future-of-twitter-is-in-data-not-advertising-says-new-datasift-ceo) -* [Twitter 是一个信息流，但它也是一个蓄水池](http://gigaom.com/2011/11/17/twitter-is-a-stream-but-its-also-a-reservoir-of-data)，作者：Mathew Ingram -* [DataSift API 演示](http://www.slideshare.net/nickhalstead/datasift-api) -* [Cassandra vs HBase](http://skillsmatter.com/podcast/home/cassandra-hbase) ，作者：尼克·特尔福德（Nick Telford）（DataSift 平台架构师） -* [Twitter 上的 DataSift 开发](https://twitter.com/#!/datasiftdev) -* [第四次 DataSift 网络研讨会视频，“目标”](http://blog.datasift.com/2011/07/28/fourth-datasift-webinar-video-%E2%80%9Ctargets%E2%80%9D/) -* [MediaSift / DataSift（Genesys Guru 的作者）](http://genesysguru.com/blog/blog/2011/05/27/mediasift-datasift/) -* [为什么我在 Twitter 生态系统上加倍关注](http://www.bothsidesofthetable.com/2011/07/10/why-im-doubling-down-on-the-twitter-ecosystem/)，作者：Mark Suster -* [在 Mozilla 音乐节](http://blog.pusher.com/2011/11/3/ways-to-use-pusher-at-the-mozilla-festival)上使用 Pusher 的方法，Phil Leggetter -* [10 个高流量流的 IPTraf 统计信息的视频](http://www.twitvid.com/QQK7M)-这是使用 10 个流进行的测试-一台服务器的吞吐量约为 3Mb / s。 +我们从不同的位置对该迁移进行了广泛的测试，并感到一切正常。 不幸的是，在完成迁移之后，我们发现了一些影响我们某些用户的问题。 您可以在 [此博客文章](https://blog.algolia.com/black-thursday-dns-issue/) 中阅读详细的报告。 DNS 比我们意识到的要复杂得多。 DNS 提供程序有许多不同的行为，我们的测试并未涵盖所有这些行为（例如，首先使用 IPv6 解析，在 TTL 上使用不同行为等） -感谢您发布此信息。 他们庞大的过滤框架听起来非常令人印象深刻。 +这个问题也改变了我们识别 SPoF 的想法。 只有一个 DNS 提供程序是 SPoF，由于没有回退，因此迁移非常关键。 我们开始制定一项计划，以删除架构中的任何 SPoF。 -谢谢，这是一篇有趣的文章。 我有一些关于数字的查询： +## 下一个 --您说他们每天处理 250+百万条推文，每秒不到 3k。 当有关碧昂斯的婴儿的消息传出时，Twitter 的峰值每秒不到 9000 条。 那么每秒 12 万条推文的峰值来自何处？ +至此，我们已经涵盖了本系列 15 个步骤中的 10 个。 正如您所看到的，我们推出后的头 18 个月并非一帆风顺。 我们经历了几次故障，不得不重新考虑基础架构的几个部分。 这些改进的目的是始终确保我们的基础架构将来几乎不可能面临类似的问题。 --每 1000 条推文 10c 似乎太糟糕了，这笔费用还包括结果权吗？ 如果是这样，您对完全访问没有转售权的费用有任何想法。 +本博客系列的下一部分和最后一部分将重点介绍 DSN（分布式搜索网络），它是我们最引以为傲的功能，并提高了我们的高可用性。 两者都有一个目标：在可靠性和性能方面满足大型上市公司的期望。 -谢谢！ - -感谢您使用 0mq 并作出贡献。 有了这些类型的数据流和量度指标，它肯定会得到“真正的”锻炼！ 我想这种压力也会很快消除错误！ - -非常好写托德。 我一直在与 DataSift 一起工作，因为他们在 Alpha 阶段完成了一个我正在为客户准备的项目，该项目很快就要出炉了（几周）。 他们做得很好，这是一个令人印象深刻的平台，可以肯定它具有巨大的潜力。 有一些优点和缺点，但您要指出其中的一些优点（有些却不知道），但总体而言，我很喜欢使用该服务，并且愿意承担这种情况下的早期采用者的风险。 - -干杯， - -肯特郡 - -Thanks it is an interesting article. I have a couple of queries about numbers though: - -- You said that they process 250+ million tweets per day, which works out to be just under 3k per second. Twitter had a peak of just under 9k tweets per second when the news about Beyonce's baby broke. So where does the peak of 120k tweets per second come from? - -- 10c per 1000 tweets seems like an awful lot, does this fee include result rights as well though? If so do you have any ideas about the fees for full access without resale rights. - -Thanks! - -非常感谢您发表这篇深入的文章，非常感谢您描述整个公司的方式，从技术细节到业务建议。 -您是否想在 4 年后写一份跟进报告？ 考虑到他们所面临的所有挑战，看看他们如何扩展其体系结构和/或流目录非常有趣。 - -+ \ No newline at end of file +*以下是该系列的所有三个部分：[第 1 部分](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html)，[第 2 部分](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html)，[第 3 部分](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html)* \ No newline at end of file diff --git a/docs/169.md b/docs/169.md index 68fbb31..ddd1f87 100644 --- a/docs/169.md +++ b/docs/169.md @@ -1,105 +1,183 @@ -# StackExchange 体系结构更新-平稳运行，Amazon 4x 更昂贵 - -> 原文： [http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html) - -![](img/5d52bff8ca298ab4abacb8a0ce387401.png) - -我们已经发表了几篇关于 [StackOverlflow Architecture](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 和 [Stack Overflow Architecture Update 的文章-每月浏览量为 9500 万页](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)。 是时候进行另一次更新了。 这次来自播客。 杰夫，乔尔（Jeff，Joel）和客人每星期大约坐在一起交谈。 结果是[播客](http://blog.stackoverflow.com/category/podcasts/)。 在最近的[播客](http://blog.stackoverflow.com/2011/09/se-podcast-17/)中，他们讨论了他们最近的一些体系结构问题，问题和更新。 自从我在休假前写这篇文章以来，他们还发布了新的体系结构更新文章： [The Stack Exchange Architecture – 2011 Edition，Episode 1](http://blog.serverfault.com/post/the-stack-exchange-architecture-2011-edition-episode-1/) 。 - -我的总体印象是他们在一个舒适的地方，添加了新的网站，添加了新的功能，使房屋成为了家。 - -以他们的向上扩展架构而闻名，您可能会期望随着他们的成长，他们会撞墙。 不是这样 他们已经能够通过增加更多的 CPU 和 RAM 来扩展单个服务器的功能。 在某些情况下已添加 SSD。 甚至他们的旗舰产品 StackOverflow 产品都在单个服务器上运行。 已经购买了新机器，但数量很少。 - -因此，StackOverflow 实验表明，即使是规模较大的站点，也都应按比例放大策略。 没错，就像早期的 Facebook 一样，他们的产品自然按照主题分开，但是摩尔定律和质量工程是您的朋友。 他们估计亚马逊将花费他们四倍的钱。 - -这是 StackExchange 所做的： - -* 他们在俄勒冈州有一个机架，在纽约的 Peer1 有两个笼子。 - * 检查电源并不会全部故障转移到单个电源，如果实际发生故障，该电源将发生故障 - * 新建了 10 台服务器 约克。 9 个生产服务器。 1 个质量检查服务器。 - * 堆栈溢出具有大型服务器，SSD 和更多 RAM。 他们在某些计算机上添加了更多的处理器和更多的 RAM，以便可以运行 Lucene - * Oregon 运行数据浏览器并进行聊天。 如果您无法到达纽约，您仍然可以聊天。 堆栈交换博客在俄勒冈运行，所有其他博客在纽约。 - * 机架非常狭窄，尤其是具有大量用于冗余电源和网络连接的电缆。 - * 应该在 Peer1 处购买机架而不是笼子。 那会给更多的空间。 - * 纽约的存在使他们更接近欧洲用户。 - * 保留俄勒冈州的位置，因为它很便宜，而且拥有另一个位置很方便。 -* 考虑具有故障转移模式，以便所有 NY 通信量都可以只读模式故障转移到俄勒冈州。 您不能提出新的问题，但是由于该站点的大部分价值都来自于阅读，因此只读站点具有价值。 - * 他们具有以下只读模式： - * 当他们将 Stack Overflow 移至其自己的数据库服务器时。 - * 当他们从俄勒冈州移居到纽约时。 - * 具有两个站点都可以处理写入的双活体系结构太复杂了。 - * 您不知道与主服务器的连接将关闭多长时间。 找出错误原因可能需要很长时间。 因此，在备份服务器上进入只读模式是正确的事情。 如果您在备用服务器上进入读写模式，那么您将更不愿意返回主服务器，直到您确定它完全死了。 - * 他们在代码中写入数据库的每个地方都实现了只读模式。 -* 运行状况仪表板提供了所有系统的总体状态。 从 SQL 数据库查询。 将所有内容存储在 SQL 中，使构建工具变得更加容易，并且可以针对当前的流量负载进行适当扩展。 - * 三个图形：CPU，内存，网络。 - * 运行大部分网络的 10 台服务器几乎未加载。 一种是峰值 16％。 即使翻了一番，他们也被严重超支。 - * 它们一次没有被过度配置。 - * 服务器已经重新配置了很多。 - * 他们已将 CPU 添加到 Web 层。 他们达到了 60％的峰值，这令人不舒服。 - * 在 Web 层中添加了 SSD，因此它们可以： - * 提高 Lucene 索引速度。 - * 加快启动 Web 层时的启动时间。 - * 固态硬盘在生命周期中处于起步阶段，要轻而易举。 - * SSD 不应使您的计算机运行得更快，因为您应该已经在 RAM 中运行了。 当数据库太大而无法放入 RAM 时，则不适用。 希望您最活跃的数据可以放入 RAM。 -* 使用商业 Orion 网络监视器。 从本质上讲，它是在为时间付费，因为它比 Nagios 更容易设置和使用。 - * 将所有数据保留在 SQL Server 上。 - * SQL 意味着很容易访问和查询。 - * Web 日志也存储在 SQL Server 中。 -* 在 SQL Server 中拥有所有数据的长期趋势。 - * 买了一台重型服务器，只是为了保存所有这些数据并能够执行实时查询。 2 个处理器，大量 RAM。 放入 13TB 的存储空间，这是一年的日志文件。 每天有 20 个演出进入 SQL Server。 - * 之所以提供帮助，是因为他们可以实时告知正在发生的事情。 当他们推出一项新功能时，他们可以知道使用了多少功能，从而告诉他们是否需要保留该功能。 他们可以通过简单的查询来完成此任务，而无需查看日志或访问 Google Analytics（分析）。 - * 他们每天创建 1 张表格来存储统计信息。 - * 他们都知道 SQL，因此可以相对轻松地提出要回答的问题。 -* Redis 服务器 - * 用作 10 个服务器之间的共享状态缓存。 可以跨服务器平衡请求。 他们不想每次都访问数据库，因此它将进入缓存。 - * 仍然是网络热议。 他们将处理粘性 IP，以便请求可以使用 Web 服务器上的内存中缓存。 这样可以消除网络命中的速度，该命中要快得多，可以直接在内存中使用它。 - * 将所有内容都放入缓存时，会遇到网络可伸缩性问题。 这不是一个无限快的管道。 -* 网络启示录 - * [微爆](http://blog.serverfault.com/post/per-second-measurements-dont-cut-it/)出现问题。 在很短的时间内爆发高达千兆位的速度，这使队列充满了。 - * 从未找到根本原因。 - * 改变了网络架构的方式。 所有网络都集中路由。 Web 服务器和数据库/ redis 服务器位于不同的网络上，因此它们摆脱了两侧之间的路由器和防火墙。 - * 他们更改了 NIC 配置。 他们联手进行了故障转移。 他们将配置更改为双活模式，并通过 NIC 负载均衡请求。 他们希望不再使用单个网卡来防止微爆。 - * 导致成本增加的原因是，如果它们从交换机运行了 10 条网络线，因为您按端口付费。 -* 令人惊讶的是，他们的流量混合了 40％的读取和 60％的写入。 -* 他们的观众中有 60％是国际观众。 -* StackExchange 大约有 45 个人。 -* CDN 使您可以处理在多个区域中运行的国际用户的 80％的方式。 - * 拥有 CDN 服务器的大部分静态资源。 - * 两个数据中心中的实时数据太难了。 需要足够的 DBA 24x7 覆盖，并在支持方面进行了大量代码更改。 -* 进入两个数据中心可能需要一个客户端引擎，例如 Facebook。 - * 客户与 10 台服务器进行对话，并说您有什么需要帮助的。 - * 客户端合并数据并显示一些结果。 - * HTML 页面是几个 div。 每个 div 独立出去都会获取页面的该部分。 页面的每个部分可能来自不同的服务器，并且全部集中在客户端。 - * StackExchange 并不是高度定制的，用户可以看到大致相同的站点，因此这并不是一个大赢家。 -* 迁移到亚马逊并不是一个好主意： - * 无法相信亚马逊的故障。 - * 亚马逊的[价格将比](http://meta.stackoverflow.com/questions/73969/what-would-stack-exchanges-yearly-expenses-be-if-it-were-to-be-using-a-third-par/73978#73978)高出 3 倍以上。 亚马逊最初购买硬件后，每月需要花费 17,000 美元，而现在每月需要支付 4,000 美元。 - * 亚马逊拥有 2007 年的旧技术，因此要实现类似的性能，他们将需要比现在更多的服务器。 - * 期望从每台计算机获得 5 年的服务。 较旧的计算机将投入使用或承担较少的任务。 - * 如果去了亚马逊，他们是否需要另一个系统管理员？ 他们可能没有想到。 亚马逊存在许多无法追踪的随机网络延迟问题。 对于高容量服装，并非全都是玫瑰。 - * 对于控制怪胎，这不是最好的模型。 他们想知道网络中正在发生的一切。 他们不断观察性能，调整 NIC 配置等。无法控制所有内容并不适合他们的工作方式。 - * 想要最好的硬件并关心每个小细节。 当您去亚马逊时，您说的是我不在乎。 - * 云是一个冗余的故事。 这就像买一千个汉堡包，而不关心 5 个腐烂的汉堡包。 那不是他们选择的模型。 - * 他们有一个重要的故事，尤其是在数据库方面。 大铁还没死。 摩尔定律还没有死。 您实际上不必花费太多时间来获得功能更强大的服务器。 不断前进。 - * 他们真正担心的唯一事情是，如果数据库中的 RAM 用完了。 他们按主题有单独的数据库，但是 Stack Overflow 太大了，它装满了一台机器，无法分片。 他们可以获得一台具有 256GB RAM 的服务器。 - -StackExchange 令人耳目一新。 他们有意识地尝试通过在[他们的博客](http://blog.serverfault.com/)中发布​​或在其[网站](http://serverfault.com/)之一上提问来公开问题。 也许您的组织可能想效仿他们的榜样？ 这是一种建立意识和信任的好方法。 - -感谢您的出色总结-非常有趣。 - -AWS 上的成本计算不是最新的或完全正确的。 我已经对原始的 SO 问题发布了更新的细分：http://meta.stackoverflow.com/questions/73969/what-would-stack-exchanges-yearly-expenses-be-if-it-were-to-be- 使用三分之一 pa / 110201＃110201 - -因此，一旦 SO 工作集通过 256GB 而又不分割所有内容，则进一步扩展工作是一个有趣的思想实验。 也许您要分解数据库，但要按功能而不是按哈希-这里是全文索引，这里是详细的表决/用户/统计数据，此处显示问题页面所需的计数和文本。 或者，如果有很多鲜为人知的档案数据，则可能在其他地方。 或者，也许您发现站点的一个或两个方面比分片*一切*（投票，统计？）更容易分片，并且减轻了关系母权带来的大量负载/ RAM 压力。 - -Randall，我同意，当数据集太大时，分离数据（而不是分片）是一种更好/更容易的启动方法。 Netflix 不久前就这样做了，这就是为什么他们的网站会因服务故障而正常降级的原因。 - -例如，“评论”可能不会显示在电影页面上，但是您仍然可以流式传输。 - -看到此博客上的“无法相信亚马逊的故障”，真是令人震惊。 - -首先，您是否真的要宣称可以比 AWS 建立更多的冗余和更多的容错能力？ 您了解如何在所有 AWS 数据中心之间进行分配吗？ - -其次，该声明是不真实的，事实是您不能 100％信任任何系统。 你建立宽容。 您是否声称无法在 AWS 上建立容忍度？ 让我们进行讨论。 - -这是另一个更新： -http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/ \ No newline at end of file +# 为社交产品设计后端 + +> 原文： [http://highscalability.com/blog/2015/7/22/architecting-backend-for-a-social-product.html](http://highscalability.com/blog/2015/7/22/architecting-backend-for-a-social-product.html) + +![](img/8fee856c39b9795d6939cfabda5e19da.png) + +旨在帮助您做出关键的体系结构决策，这将使社交应用程序成为真正的下一代社交产品。 提议的更改解决了以下属性： a）可用性 b）可靠性 c）可扩展性 d）扩展的性能和灵活性（非修改） + +## 目标 + +a）确保用户的内容易于发现并且始终可用。 + +b）确保推送的内容不仅在语义上相关，而且从用户的设备角度来看也相关。 + +c）确保生成，推送和分析实时更新。 + +d）着眼于尽可能节省用户的资源。 + +e）无论服务器负载如何，用户的体验都应保持不变。 + +f）确保整体应用程序安全性 + +总而言之，我们要应对一个巨大的挑战，我们必须应对庞大的海量，不断扩大的用户生成内容，不断增加的用户数量以及源源不断的新商品，同时还要确保出色的性能。 考虑到上述挑战，我们必须研究某些会影响整个系统设计的关键体系结构元素。 以下是一些关键决策&分析。 + +### 数据存储 + +数据存储和数据建模是要做出的关键决定之一。 社交产品有望处理多种类型的数据，因此，在为每种类型选择模型和存储之前，我们必须全面分析和理解数据，这一点至关重要。 + +第一步是确定哪些是最频繁查询的数据，哪些不是那么频繁需要的数据（用于分析的存档数据）。 对于期望以较高频率查询的数据，需要将其放置在始终可用的位置，以便更快地读写和水平扩展。 现在，即使我们的用例并未强制使用基于 RDBMS 的系统，我们仍将 MySQL 用于所有用例。 随着数据的增长，我们的读写将成为应用程序性能的瓶颈。 我们应该准备好每秒处理数十亿次查询。 + +让我们对数据进行分类： + +a）主数据或静态形式的数据，例如用户个人资料 + +b）语义数据 + +c）用户生成的内容 + +d）会话数据 + +对于我们来说，要找到对所有这些类型的数据都具有高性能的数据存储确实是很难的。 因此，我们将需要为每个数据库选择特定的数据存储。 + +**静态数据**：对于静态数据，最好选择基于文档的键和值都可查询的存储。 我们可以在这里选择建立良好的基于​​文档的存储，例如 MongoDB。 选择 MongoDB 的最大优点是它在文档级别提供 ACID 属性。 + +它可以轻松地在多个分布式数据中心内和跨多个数据中心进行扩展。 这将使我们能够使用副本集轻松维护冗余，从而解决我们的可用性问题。 + +分片是另一个要考虑的大因素，这对于确保规模&速度至关重要。 幸运的是，MongoDB 支持透明地分片。 + +**关联数据或关系数据（核心数据）**：我们的数据的大部分将在自然界中关联，例如，A 是 B 的朋友，C 是 A 和 B 的朋友。此类数据是高度语义化的数据 最适合建模为图形。 我们应该将这些数据存储在像 Neo4j 这样的图形数据库中。 优势显而易见； 它将使我们能够存储节点的所有连接以及节点本身，从而节省了计算连接数据之间关系的额外步骤。 图形数据模型还将在这里帮助我们捕获关系的属性。 当尝试探索连接的数据时，属性丰富的关系绝对至关重要。 GraphDB 支持 ACID 规则和自动索引。 + +同样，我们在可用性和可伸缩性方面的要求是相同的。 我们可以有成百上千的并发事务全部同时写入数据库以及成千上万的读取。 它应该扩展为每秒处理多个 PB 数据集中的十亿次读取。 + +我们需要一个允许动态缩放读写的系统。 要考虑的另一个因素是分片，这对于扩展我们的系统至关重要。 + +Neo4j 已经设计成可水平扩展，并具有复制功能以保证可用性。 但截至目前，它不支持分片。 选择一个时，我们可能需要更多分析。 其他选项是 FlockDB，AllegroGraph 和 InfiniteGraph。 + +**二进制数据（UGC）**：我们还必须处理与用户相关的大量二进制数据。 考虑到二进制数据的大小，要处理它并不容易。 像上面讨论的那样，我们的系统是一个需求可以在几秒钟之内运行的很高的系统（峰值），规模和可用性是决定存储位置时要考虑的最关键因素。 我们不能在这里依靠文件系统来存储我们的二进制数据。 我们必须考虑可用性和可伸缩性。 文件系统的缓存可能受 CPU 限制，因此使其冗余将需要大量的簿记工作。 相反，我们应该依靠已经可用的系统。 例如，Amazon S3，这是非常受欢迎的对象存储，具有保证的可用性，并且具有弹性。 + +我们也可以考虑使用 Google Cloud Storage 或 Rackspace Cloud Files 等。但是就报价而言，S3 显然是赢家。 + +S3 已经支持数据分区。 它根据高请求率和分区中的键数，通过将数据连续拆分为多个分区，从而水平扩展 S3。 但是重要的是要意识到仅存储内容是不够的，与这些内容相关联的元数据需要可搜索，并且搜索必须足够扩展和足够快。 我们还可以在这里尝试一些新事物，例如从图像自动识别尺寸，基于上下文自动标记等，然后使用它们来驱动图像的键*。 这是一个潜在的 IP 领域。 我们将在索引部分下研究索引需求。 但是现在，让我们仅注意，我们将使用标识符存储内容，该标识符可以在其他地方建立索引。 亚马逊的 S3 似乎最适合这种情况。 + +### 会话数据 + +重要的是认识并理解为什么我们需要考虑会话数据。 会话数据将帮助我们维护用户的状态。 而且这种状态应该以与服务器无关的方式持续，以使我们的部署规模扩大。 这将有助于我们使设计保持足够的灵活性，从而确保会话不会停留在特定的节点或服务器上。 + +我们必须以一种可以重新生成用户实际会话的方式来保存会话信息，如果用户会话终止，我们仍然可以帮助用户从他离开的地方开始。 + +在我们的市场中，连接不那么可靠，并且通常会丢包，这一点尤其重要。 这些数据需要在我们的所有节点上都可用，因此需要可用性和可伸缩性。 首先，我们可以很好地将其保存在我们的 MongoDB 中。 稍后我们可以考虑将其转移到像 REDIS 这样的纯键值存储中。 + +注意：所有推荐和脱机作业都应仅在非服务节点上运行。 + +### 索引编制 + +索引对于我们的系统至关重要。 用户可以搜索任何内容，这是我们的主要用例之一。 为了提高搜索性能，我们必须非常重视索引编制。 这里有两件事要考虑。 首先是创建索引本身，其次是创建索引系统。 + +为了使有意义的可搜索系统，我们必须设计一个实时索引，该索引被倒置并在生成的内容窗口上工作。 首先，我们可以编写一个非常简单的系统，在内容摄取期间，该系统可以负责根据内容生成反向索引。 后来，随着内容摄取负载的增加，我们可以简单地用实时数据处理引擎（例如 Apache Storm）来代替它，这是一个分布式，容错且高度可扩展的系统。 它可以接管索引逻辑的生成。 + +索引系统：Lucene 因其受欢迎程度和速度而成为显而易见的选择。 其性能无与伦比。 我们应该选择 SolrCloud。 它已经支持透明分片，复制，并且具有读写侧容错功能。 + +### 排队&推送通知 + +每次在我们的应用中触发事件时，我们都将被要求以通知的形式将该事件散发给他/她的关注者/朋友。 重要的是，我们的系统不要错过任何这些信号，万一发生故障，恢复这些事件至关重要。 为了做到这一点，我们必须寻找一个排队解决方案。 我们可以使用 ActiveMQ，这是最可靠的排队软件。 它允许群集以实现高可用性，并支持分布式排队。 + +推送通知是另一个要向我们的用户发送通知的区域。 在这里，我们需要寻找规模。 我们应该为数十亿个 nps 的规模做好准备。 这里有很多选项，但也许 pyapns，CommandIQ 和 App Booster 是最受欢迎的选项。 + +我们将需要专门管理一些事务，以确保即使用户的设备处于离线状态，也能确保通知的传递。 我建议我们实现一个基于双指针的系统，该系统维护通知的状态并在后台将其写入磁盘。 因此，每次通知失败时，都会维护其状态并使用状态标志将其添加到重试队列中。 最终，在传递通知时，将其出队。 + +### 缓存策略 + +像我们这样的系统，我们的目标是使其扩展到十亿 rps，因此智能缓存至关重要。 我们的设计将需要逻辑以多层缓存并智能地逐出它们。 让我们从顶级看什么要缓存和在哪里缓存。 + +*应用程序级缓存（内容缓存）* ：为了最大程度地减少缓存未命中并确保缓存始终保持最新的可用数据，我们必须寻找永不过时且始终可用的缓存 数据。 从本质上讲，这意味着在我们所有的一般用例中，我们将不必查询数据库，从而节省了大量资源。 我们还应确保缓存的数据始终采用不需要任何消息传递且可以随时呈现的格式。 实质上，这意味着我们会将在线负载转换为离线负载，从而节省了延迟。 为此，我们必须确保每次将内容提取到系统中时，我们都要做两件事 + +a）以一种在服务阶段不需要任何消息传递的方式对原始内容进行非规范化，然后将其保存到缓存中。 为了安全起见，我们将始终设置一个有效期限，该期限可以足够高。 + +b）原始内容也按原样写入我们的数据存储中。 + +我们非常可以依靠 REDIS 来获得此缓存，这是具有良好故障恢复能力的内存缓存。 它具有高度的可扩展性，较新的版本也允许透明分片。 并且它也支持主从节点配置。 最好的部分是它将使我们能够按原样保留本地数据结构，这使得增量写入非常容易，并且对我们支持内容提要（扇出）至关重要。 + +还要注意的是，我们将需要在大型内容对象上进行大量的读取-修改-写入操作和少量读取操作，以支持实时扇出，并且从速度的角度来看，REDIS 最适合这些操作。 + +*代理缓存 e* ：反向代理级别的缓存也很关键。 它有助于减少服务器的负载，从而保持延迟。 但是，要使代理服务器真正有效地进行缓存，正确设置 HTTP 响应标头至关重要。 有很多选择，但流行的是 nginx 和 ATS。 + +*二级缓存（代码级缓存）* ：这是实体数据的本地存储，以提高应用程序的性能。 通过减少昂贵的数据库调用，使实体数据保持在应用程序本地，它有助于提高性能。 EhCache 是​​该领域的热门选择。 + +*客户端缓存* ：这是实际的设备或浏览器缓存。 所有静态项目应尽可能多地被高速缓存。 如果 API 响应设置了正确的 HTTP 缓存头，则已经缓存了许多与资源相关的项目。 我们应该确保它按预期工作。 除此之外，我们应该使用设备自己的内存或使用 sqlite 来缓存尽可能多的其他内容。 所有昂贵的对象都应缓存。 例如 NSDateFormatter & NSCalendar，它的初始化速度很慢，应尽可能重复使用。 iOS Lot 可以在这里进行调整和使用，但这不在我们的研究范围之内。 + +### 内容压缩 + +考虑到以下事实：我们主要希望用户处理大量图像和视频，而这些图像和视频需要下载大量数据，因此优化下载大小至关重要。 它将为用户节省数据并提高应用程序性能。 + +要考虑的其他方面是我们的网络，我们的用户主要使用 2.5g 或 3g 的非 LTE 网络，其中带宽通常是一个问题，并且连接不可靠。 数据使用成本也很高。 在这种情况下，智能压缩是至关重要的。 + +但是压缩图像和视频并不是那么简单，通常需要更深入的分析。 我们处理的图像和视频可能是无损的，也有损的，这取决于用户的设备质量。 因此，我建议使用多种压缩技术来处理这种情况。 在这种情况下，我们可以尝试帧内压缩和帧间压缩技术。 + +但是总的来说，我们可以为所有压缩需求使用 zpaq 和 fp8。 我们也可以尝试 WebP，这可能对我们的市场有利。 通常，我们将在整个过程中始终使用 GZIP，所有 API 响应都将始终进行 GZIP 处理。 + +### 内容转码 + +考虑到我们将需要处理具有多个 OS 和屏幕分辨率的多个设备，因此我们的内容存储和处理应与设备无关。 但是服务层应根据具体情况而定，并应根据用户的设备功能理解并提供正确的内容。 这使得对我们的图像和视频进行转码至关重要。 + +我们的应用应收集有关内存，编码和屏幕分辨率的设备功能，并将其作为上下文传递给我们的 API。 我们的 API 应该使用此上下文来修改/选择内容版本。 根据收到的设备上下文，我们可以将内容预转码为几个最受请求的版本。 + +对于转码，我们可以使用 FFMPEG，这是最可靠，使用最广泛的框架。 我们可以根据需要修改 FFMPEG。 这也必须在摄取侧完成。 + +### 传输协议 + +考虑到我们的网络场景（非 LTE，不可靠的连接等），至关重要的是要尽可能智能地节省资源并尽可能减少通信量。 我建议对所有 HTTP 请求都使用 OkHttp 客户端，而反过来又使用 SPDY，SPDY 可以很好地抵抗连接失败并透明地恢复。 + +对于我们所有的消息传递需求，我们应该切换到 MQTT，这是一种轻量级的机器到机器连接协议。 + +### 安全 + +保护我们的应用程序确实很重要。 我们的整体体系结构应适应这一重要属性。 在这里，我仅讨论支持安全性所需的体系结构更改，而不会涉及实现性更改。 + +我们必须在架构中添加以下内容： + +1.我们所有的用户数据都必须加密。 MongoDB 和 Neo4j 已经支持存储加密。 根据情况，我们可以决定对关键用户信息进行加密。 必须为所有与数据库相关的调用启用传输加密。 + +2.安全套接字层：到我们的代理服务器的所有呼叫均应进行 SSL 加密。 代理服务器可以充当 SSL 终止点。 + +3.我们所有的 api 端点都应在非默认端口上运行，并且应实现 Oauth 而不失败。 + +4.从 DB 进行的所有读取应始终通过其余端点进行。 + +5.保存密码的配置必须特别处理。 必须对密码进行哈希处理，并且文件应被限制为只有应用程序才能在启动时读取该密码。 这使我们可以通过文件系统权限来控制应用程序身份实例。 只有应用程序用户可以阅读，但不能写，其他任何人都不能阅读。 所有这些配置都可以打包在 keydb 下，并受 pwd 限制。 + +## 组件 + +这是我们架构的组成部分： + +1.负载均衡器：这是一层，它根据确定的策略确定将请求转发到哪个代理服务器。 该层还将通过基于容量重定向流量来帮助我们保证可用性。 + +2.代理服务器：所有来电都必须在此处登陆。 这也是我们的 SSL 终止点。 它根据定义的策略缓存 HTTP 请求。 FE 层：此层运行节点服务器。 + +3.提取引擎：此组件处理所有传入的内容。 它包含与非规范化，代码转换，缓存等有关的策略。将来，如果需要，可以在此处完成所有内容的充实。 + +4\. REST Server：这是与所有 DB 进行对话并生成响应的层。 其访问受 Oauth 保护。 它可能是一个已实现边缘缓存的 tomcat 容器。 + +5.事件处理器：此层处理所有事件，并且主要负责扇出功能。 它读取 ActiveMQ 并使用通知引擎生成通知。 + +6.推荐引擎：此组件通过分析从用户活动中收集到的所有信号来推动推荐。 根据收集到的实际信号，我们可以部署各种基于亲和力的算法。 我们可以在 Apache Mahout 上进行回复，首先它已经提供了各种算法接口 + +系统的逻辑视图： + +![](img/56ca2c72ce745e5aafa4658ffa8905fd.png) + +# 结论 + +这更多是对关键组件的高级分析。 如果需要实施该建议，则不必一 implemented 而就，可以分阶段进行，但是如果我们需要扩展和支持实际用例，则必须遵循我在此处提出的模式。 我没有涉及任何设计领域。 那是在设计阶段，将需要更深入的分析和了解系统的当前状态。 + +[On HackerNews](https://news.ycombinator.com/item?id=9930752) + +谁写的？ 让他们停下来。 当他们说“很幸运，mongodb 音阶”时，我停止阅读（意译） + +写得好。 非常喜欢阅读。 这可能不适用于所有但定义良好的设计替代方案和分析。 爱它。 + +我很喜欢它。 仅需注意一点，ActiveMQ 既好又稳定，但值得探索 Kafka。 我觉得在可伸缩性方面要好得多。 总体来说真的很喜欢你的逻辑。 + +本文概述了针对特定功能（缓存，反向代理，负载平衡，通知等）的推荐软件/应用程序，并在某种程度上说明了选择的原因。 但是我认为，如果将组件抽象出来并且将更多的注意力放在系统的实际体系结构上，将会更有帮助。 例如，我在架构图上看不到任何特定于领域的语言（我无法确定应用程序在做什么），而是一组完成功能的工具。 + +非常丰富。 您是否考虑使用关系数据库而不是使用 mongodb 进行分片？ 还是其他任何数据库才可以进入？ \ No newline at end of file diff --git a/docs/17.md b/docs/17.md index e15d670..aac65e7 100644 --- a/docs/17.md +++ b/docs/17.md @@ -1,105 +1,125 @@ -# 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事，以及 Tarantool 与此相关的内容 - -> 原文： [http://highscalability.com/blog/2016/8/30/the-cat-and-mouse-story-of-implementing-anti-spam-for-mailru.html](http://highscalability.com/blog/2016/8/30/the-cat-and-mouse-story-of-implementing-anti-spam-for-mailru.html) - -![](img/1295631a0c5a13e4ec2d6e35538297c0.png) - -大家好！ - -在本文中，我想向您介绍一个为 Mail.Ru Group 的电子邮件服务实现反垃圾邮件系统的故事，并分享我们在此项目中使用 [Tarantool](https://tarantool.org/) 数据库的经验：Tarantool 的任务是什么 ，我们面临的局限性和整合问题，陷入的陷阱以及我们最终如何得到启示。 - -让我从简短的回溯开始。 大约十年前，我们开始为电子邮件服务引入反垃圾邮件。 我们的第一个过滤解决方案是卡巴斯基反垃圾邮件和 RBL（*实时黑洞列表-*是与垃圾邮件发送有关的 IP 地址的实时列表）。 这样可以减少垃圾邮件的发送，但是由于系统的惯性，我们无法足够快地（即实时）抑制垃圾邮件的邮寄。 另一个未满足的要求是速度：用户应该以最小的延迟接收经过验证的电子邮件，但是集成解决方案的速度还不足以赶上垃圾邮件发送者。 垃圾邮件发件人发现垃圾邮件未送达时，他们会很快更改其行为模型和垃圾邮件内容的外观。 因此，我们无法忍受系统的惯性，而是开始开发自己的垃圾邮件过滤器。 - -我们的第二个系统是 MRASD-Mail.Ru 反垃圾邮件守护程序。 实际上，这是一个非常简单的解决方案。 客户的电子邮件到达 [Exim](http://www.exim.org) 邮件服务器，并通过充当主要过滤器的 RBL 到达，然后到达 MRASD，在那里发生了所有不可思议的事情。 反垃圾邮件守护程序将邮件分解为几部分：标头和正文。 然后，它使用基本算法对每个片段进行归一化，例如对字符大小写进行归一化（全部以小写或大写形式），将外观相似的符号转换为特定形式（例如，使用一个符号表示俄语和英语“ O”）等 标准化后，守护程序提取了所谓的“实体”或电子邮件签名。 我们的垃圾邮件过滤器会分析电子邮件的不同部分，并在发现任何可疑内容时将其阻止。 例如，我们可以为“ viagra”一词定义一个签名，所有包含该词的消息都会被阻止。 实体也可以是 URL，图像，附件等。 在反垃圾邮件检查过程中完成的另一件事是为已验证的电子邮件计算指纹。 计算为少数棘手的哈希函数的指纹是邮件的独特特征。 基于计算的哈希值和收集的哈希统计信息，反垃圾邮件系统可以将邮件过滤为垃圾邮件或让其通过。 当哈希值或实体达到某个频率阈值时，服务器开始阻止所有匹配的电子邮件。 为此，我们维护了统计数据（计数器）来跟踪遇到某个实体的频率，接收者抱怨该实体的频率，并设置了一个实体标志 SPAM / HAM（在与垃圾邮件相关的术语中，“ ham”与“ 垃圾邮件”，表示经过验证的电子邮件不包含垃圾内容。 - -MRASD 的核心部分是使用 C ++实现的，而其相当多的业务逻辑是使用解释性语言 Lua 来实现的。 正如我已经说过的那样，垃圾邮件发送者是非常有活力的人，他们会很快改变其行为。 我们的目标是对垃圾邮件发送者方面的每项更改做出快速响应，这就是为什么我们使用解释性语言实施业务逻辑的原因（对于 Lua，我们不必每次都在所有服务器上重新编译系统并进行更新）。 另一个要求是速度：Lua 中的代码在性能测试中显示出良好的结果。 最后，很容易与 C ++中的代码集成。 - -![](img/0e0752752d353aa16839d288763f4911.png) - -上面的方案说明了我们的反垃圾邮件过滤器的简化工作流程：电子邮件从发件人发送到我们的邮件服务器； 如果该消息已成功通过主过滤器（1），则它进一步进入 MRASD（2）。 MRASD 将其检查结果返回到邮件服务器（3），并根据这些结果将邮件传递到收件人的“垃圾邮件”文件夹或收件箱中。 - -MRASD 允许我们将未过滤的垃圾邮件数量减少十倍。 随着时间的流逝，我们不断改进系统：添加了新的子系统和组件，引入了新的工具。 因此，系统不断发展，变得更加复杂，反垃圾邮件任务也变得更加多样化。 这些变化无助于影响我们的技术堆栈。 这就是本故事的下一部分。 - -**技术堆栈的演进** - -在电子邮件服务时代的曙光中，消息流以及消息内容比今天明显稀缺。 但是工具和计算能力的选择也较差。 从上面描述的 MRASD 的“父母”模型可以看出，有必要存储各种统计数据。 这些数据的相当一部分是“热”的（即经常使用），这对数据存储系统提出了某些要求。 结果，我们选择了 MySQL 作为“冷”数据的存储系统，但对于“热”统计数据仍然不确定。 我们分析了所有可能的解决方案（它们的性能和功能适用于“热”数据，但不适用于关键任务数据），最终到达 [Memcached](https://memcached.org/) -那时，此解决方案已经足够稳定。 但是我们在存储“热”和关键数据方面仍然存在问题。 与任何其他缓存解决方案一样，Memcached 也有其局限性，包括不进行复制以及缓存关闭（并刷新）后的长时间预热时间。 我们的进一步搜索将我们带到了[京都内阁](http://fallabs.com/kyotocabinet/)，这是一个非关系键值数据库系统。 - -时间过去了，电子邮件工作量增加了，反垃圾邮件工作量也增加了。 出现了需要存储更多数据的新服务（Hadoop，Hypertable）。 顺便说一句，当今的高峰处理工作量达到每分钟 55 万封电子邮件（如果我们每天计算平均值，则每分钟约有 35 万封电子邮件），每天要分析的日志文件量超过 10 TB。 让我们回到过去：尽管工作量不断增加，但我们对数据处理（加载，保存）的要求却保持不变。 有一天，我们意识到京都议定书无法管理所需的数据量。 此外，我们需要一种存储系统，它具有针对“热”和关键数据的更广泛功能。 也就是说，是时候到处寻找更好的替代方案了，这些替代方案将更灵活，更易于使用，并具有更高的性能和故障转移功能。 那时，一个名为 Tarantool 的 NoSQL 数据库在我们公司中获得了普及。 Tarantool 是公司内部开发的，完全满足了我们的“ wannas”。 顺便说一句，我最近一直在修改我们的服务，当我遇到最早的 Tarantool 版本之一时 [Tarantool / Silverbox](http://www.slideshare.net/fuenteovehuna/tarantool-silverbox) ，我感到自己是一名考古学家。 我们决定尝试一下 Tarantool，因为它的基准测试涵盖了我们所需的数据量（我当时没有确切的工作量数据），并且也满足了我们对内存使用的要求。 另一个重要因素是项目团队位于隔壁，我们可以使用 JIRA 快速提出功能请求。 我们是决定在他们的项目中尝试使用 Tarantool 的先驱者之一，我认为我们向 Tarantool 迈出的第一步受到了其他先驱者的积极经验的鼓舞。 - -那就是我们的“ Tarantool 时代”开始的时候。 我们积极地将 Tarantool 引入到我们的反垃圾邮件体系结构中。 今天，我们有了基于 Tarantool 的队列，用于存储各种统计数据的高工作量服务：用户信誉，发件人 IP 信誉，用户可信度（“业力”统计信息）等。我们目前的活动是将升级的数据存储系统集成到我们的 实体统计处理器。 您可能想知道为什么我们只针对我们的反垃圾邮件项目专注于一个数据库解决方案，而不考虑迁移到其他存储。 嗯，事实并非如此。 我们也考虑和分析竞争系统，但是暂时，Tarantool 可以很好地处理项目中所需的所有任务和工作负载。 引入新的（未知的，以前未使用的）系统总是有风险的，并且会花费大量时间和资源。 同时，Tarantool 是我们（以及许多其他项目）的知名工具。 我们的开发人员和系统管理员已经了解使用和配置 Tarantool 的所有知识，以及如何充分利用它。 另一个优势是 Tarantool 的开发团队不断改进其产品并提供良好的支持（这些人正在隔壁工作，这很不错:)）。 当我们仍在实施另一个基于 Tarantool 的解决方案时，我们获得了所有必要的帮助和支持（我稍后会告诉您）。 - -接下来，我将为您概述我们的反垃圾邮件项目中使用 Tarantool 的几个系统，这些系统将涉及我们面临的问题。 - -**我们使用 Tarantool** 的系统概述 - -**业力** - -**业力**是一个数字值，表示用户的信任度。 它最初是为不需要复杂的依赖系统的用户提供的通用“胡萝卜和棍子”系统的基础。 业力是基于从其他用户信誉系统接收到的数据的汇总值。 业力系统背后的想法很简单：每个用户都有其业力-越高，我们对这个用户的信任就越高； 越低，我们在反垃圾邮件检查期间评估他们的电子邮件时就越严格。 例如，如果发件人发送的电子邮件中包含可疑内容，并且发件人的业障评分很高，则此类邮件会打入收件人的收件箱。 较低的业障评级将是反垃圾邮件系统的悲观因素。 这个系统使我想到了老师在学校考试中查阅的一本考勤书。 参加所有班级的学生只会得到几个额外的问题，然后去度假，而错过许多班级的学生则必须回答很多问题才能获得高分。 - -![](img/7bf90374f27a6f0f5e8309a6c0d7f616.png) - -用于存储与业力相关的数据的 Tarantool 在单个服务器上工作。 下图说明了每分钟一个这样的实例执行的请求数。 - -![](img/98697072a85fdef53622b857c064baf5.png) - -**RepIP / RepUser** - -**RepIP** 和 **RepUser** （信誉 IP 和信誉用户）是一种高工作负载服务，用于处理与具有特定 IP 以及与发送者（用户）的活动和动作有关的统计信息 与用户在一段时间内使用电子邮件服务的强度有关的统计信息。 该系统使我们知道用户已发送了多少电子邮件，其中有多少已被阅读，以及有多少被标记为垃圾邮件。 该系统的优势在于，它提供了时间轴，而不是用户活动的快照。 为什么这对于行为分析很重要？ 想象一下，您在没有任何交流的情况下搬到了国外，而您的所有朋友都留在家里。 然后，几年后，您的小屋里有了网线。 哇！ 您浏览到自己喜欢的社交网络的网站，然后看到朋友的照片-嗯，他已经改变了很多……您可以从该照片中获得多少信息？ 我想不是太多。 现在想象一下，您观看了一个视频，该视频显示了您的朋友变迁，结婚等等……-那是一段简短的传记片段。 我敢打赌，在第二种情况下，您会更好地了解朋友的生活。 数据分析也是如此：我们拥有的信息越多，我们就可以更好地评估用户的行为。 我们可以注意到发件人的邮件活动趋势，了解发件人的习惯。 根据这种统计信息，为每个用户和 IP 地址分配“信任等级分数”和一个特殊标志。 此标志用于主要过滤器中，该过滤器甚至可以在垃圾邮件到达我们的邮件服务器之前过滤掉多达 70％的垃圾邮件。 这个百分比说明信誉服务的重要性。 这就是为什么此服务需要最大的性能和容错能力的原因。 这就是为什么我们在这里使用 Tarantool 的原因。 - -![](img/51db83a4a247d755fc55d4a15b7e2177.png) - -信誉统计信息存储在两台服务器上，每台服务器有四个 Tarantool 实例。 下图说明了每分钟 RepIP 请求的平均数量。 - -![](img/83d0a0db50b56264fc18f1a63bc54062.png) - -在实施信誉服务时，Tarantool 遇到了许多配置问题。 与我们之前讨论的系统不同，RepIP / RepUser 的数据包更大：这里的平均包大小为 471,97 字节（最大大小为 16 KB）。 从逻辑上讲，数据包包括两个部分：一个小的“基本”部分（标志，汇总统计信息）和一个很大的统计部分（详细的按动作统计信息）。 对整个数据包进行寻址会导致大量的网络使用，因此加载和保存记录会花费更多时间。 许多系统仅需要数据包的基本部分，但是如何将其从元组中剥离（“元组”是 Tarantool 的记录术语）？ 这是存储过程很方便的地方。 我们在 Tarantool 的 **init.lua** 文件中添加了所需的函数，并从客户端对其进行了调用（从 Tarantool 1.6 版开始，您可以使用纯 C 语言编写存储过程）。 - -**1.5.20 之前的 Tarantool 版本存在问题** - -说我们从未遇到过 Tarantool 问题是错误的。 是的，我们有一些。 例如，在计划的重新启动后，Tarantool 客户端（超过 500 个）由于超时而无法重新连接。 当出现故障后，下次尝试重新连接的尝试被延迟了一段时间后，我们尝试引入渐进式超时，但这无济于事。 我们发现，问题在于 Tarantool 在其事件循环的每个周期内仅接受一个连接请求，尽管有数百个请求在等待。 我们有两种选择：安装新的 Tarantool 版本（1.5.20 或更高版本）或修改 Tarantool 的配置（禁用 *io_collect_interval* 选项可以解决此问题）。 Tarantool 开发人员很快修复了此错误，因此 Tarantool 1.6 或 1.7 将不会提供它。 - -**RepEntity-实体信誉** - -当前，我们正在集成一个用于存储实体统计信息（URL，图像，附件等）的新组件。 **RepEntity** 。 RepEntity 的目的类似于已经讨论的 RepIP / RepUser 的目的：它提供有关实体行为的详细信息，这是我们的反垃圾邮件过滤器的决策标准。 借助 RepEntity 统计信息，我们可以根据电子邮件的实体过滤出垃圾邮件。 例如，邮件可能包含可疑的 URL（例如，其中可能包含垃圾内容或导致[网络钓鱼](https://en.wikipedia.org/wiki/Phishing)网站），而 RepEntity 可以帮助我们更快地注意到和阻止此类邮件。 怎么样？ 我们可以看到该 URL 的动态发送，并且可以检测到其行为的变化，这对于“固定”计数器是不可能的。 - -除了不同的数据包格式外，RepEntity 和 RepIP 系统之间的基本区别是 RepEntity 在我们的服务上产生了明显更高的工作负载（处理和存储的数据量更大，请求数量也更多）。 一封电子邮件最多可以包含一百个实体（最多 10 个 IP 地址），对于这些实体中的大多数，我们必须加载并保存完整的统计信息包。 值得注意的是，数据包由特殊的聚合器保存，该聚合器首先等待累积足够的统计信息。 因此，所有这些都意味着数据库系统要承担更多的工作量，并且需要准确的设计和实现。 **让我强调一下，由于某些项目限制，对于 RepEntity，我们使用了 Tarantool 1.5（因此，我将继续撰写此版本）。** - -首先，我们估计了存储所有统计信息所需的内存量。 为了更好地说明此任务的重要性，让我带来一些数字：在预期的工作量下，将数据包增加 1 个字节意味着将数据总量增加 1 GB。 如您所见，我们的任务是以最紧凑的方式将数据存储在一个元组中（正如我已经说过的，我们无法将整个数据包存储在一个元组中，因为我们经常要求仅检索一部分数据包数据） 。 要计算要存储在 Tarantool 中的数据量，我们还需要考虑： - -* 存储索引的额外空间 -* 在元组中存储数据大小的额外空间（1 个字节） -* 最大元组大小的限制为 1 MB（对于 1.7 版，请参见 [http://tarantool.org/doc/book/box/limitations.html](http://tarantool.org/doc/book/box/limitations.html) ） - -Tarantool 增加了各种请求（读取，插入，删除）的数量，从而产生超时错误。 我们的调查表明，在频繁插入和删除的情况下，Tarantool 启动了一个复杂的树重新平衡过程（我们所有的索引都是 TREE 类型的）。 Tarantool 中的树索引具有棘手的自平衡逻辑，只有在满足某些“不平衡”条件时才会启动。 因此，当一棵树“失去足够的平衡”时，Tarantool 启动了重新平衡过程，这使得 Tarantool 变得口吃。 在日志中，我们发现消息*资源暂时不可用（errno：11）*在几秒钟后消失了。 但是，尽管发生了这些错误，客户端仍无法获取请求的数据。 Tarantool 团队的同事提出了一个解决方案：尝试使用其他类型的树索引 AVLTREE，该索引在每次插入/删除/更改时都会重新平衡。 实际上，尽管重新平衡呼叫的数量有所增加，但其总成本却更低。 在更新架构并重新启动数据库之后，该问题永远消失了。 - -我们面临的另一个问题是清理过时的记录。 不幸的是，Tarantool（据我所知，对于 1.7 版也是如此）不允许为某个记录定义 TTL（生存时间），而忘记了它，而所有清理活动都委托给了数据库。 好了，您仍然可以自己使用 Lua 和 [box.fiber](http://stable.tarantool.org/doc/mpage/stored-procedures.html#sp-box-fiber) 实现所需的清理逻辑。 从好的方面来说，这提供了更大的灵活性：您可以定义复杂的清除条件，而不仅仅是基于 TTL 的条件。 但是，要正确实现清除逻辑，您需要注意一些细微差别。 我实施的第一根清洁纤维使 Tarantool 的速度非常慢。 事实是，我们可以删除的数据量大大少于记录的总数。 为了减少要删除的记录候选者的数量，我引入了基于所需字段的二级索引。 之后，我实现了一个遍历所有候选对象的光纤（其上次修改的时间戳早于指示的时间戳），检查了其他清除条件（例如，当前是否为记录设置了“正在进行写入”标志），并且 如果满足所有条件，则光纤会删除该记录。 当我在零工作负载下测试逻辑时，一切工作正常。 在低工作量的情况下也很好。 但是当我将工作量增加到预期水平的一半时，我遇到了问题。 我的请求开始失败，并显示超时错误。 我知道我一定已经溜了。 当我深入研究这个问题时，我意识到我对光纤的工作方式有一个错误的认识。 在我的世界中，光纤是一个独立的线程，对接收和处理客户端请求没有任何影响（上下文切换除外）。 但是不久，我发现我的光纤使用了与请求处理线程相同的事件循环。 这样，我在一个循环中遍历大量记录，而又不删除任何内容，只是阻塞了事件循环，因此未处理客户端请求。 为什么提到删除操作？ 您会看到，每次删除某些记录时，都会发生一次 yield 操作，该操作解除了事件循环的阻塞并允许处理下一个事件。 在这一点上，我得出的结论是，如果执行了一些 N 操作（其中 N 是一个经验推导的值，我取 N = 100）而没有产生屈服，则有必要强制屈服（例如，使用 *wrap.sleep（ 0）*）。 要记住的另一件事是，记录删除可能会触发索引更新，因此在遍历记录时我可能会丢失一些要删除的数据。 这是另一个解决方案。 在一个周期中，我可以选择一小部分元素（小于 1000 个）并遍历这些元素，删除需要的元素，并跟踪最后一个未删除的元素。 在下一次迭代中，我将从最后一个未删除的元素中选择另外一小部分元素。 - -我们也尝试过实施一种解决方案，该解决方案将来可以平滑地进行分片，但是此尝试失败了：实现的机制开销太大，因此我们暂时放弃了分片。 希望我们可以在较新的 Tarantool 版本中找到重新分片功能。 - -这是一些性能提示。 - -要提高 Tarantool 的性能，您可以禁用* .xlog 文件。 但是请记住，在这种情况下，Tarantool 仅作为高速缓存工作，并具有所有的限制（我的意思是没有复制，重新启动后需要很长的预热时间）。 这里的解决方法是不时制作快照，并在需要时使用它来还原数据。 - -如果一台计算机上有多个 Tarantool 实例，则可以将每个实例“精确定位”到某个 CPU 内核以提高性能。 但是，如果您说 12 个物理内核，那么开始 12 个实例就不好了，因为每个 Tarantool 实例连同执行线程也都有一个 WAL 线程。 - -所需功能： - -* 分片。 -* 基于集群的方法，可以进行动态集群配置，例如在添加节点或节点出现故障的情况下派上用场，类似于 MongoDB（mongos）和 Redis（redis sentinel）。 -* 可以为记录清除定义 TTL（生存时间）。 - -**的结论** - -Tarantool 是我们反垃圾邮件系统的基石，我们许多重要的高工作量服务都基于此。 现成的[连接器](http://stable.tarantool.org/doc/mpage/connectors.html)使轻松将 Tarantool 与使用不同编程语言实现的组件集成在一起成为可能。 Tarantool 的成功历史悠久：多年来，在我们的反垃圾邮件项目中使用 Tarantool 以来，我们在操作或稳定性方面都没有遇到严重问题。 但是要充分利用该数据库，您需要考虑一些配置上的细微差别（在这里，我们一直在谈论 Tarantool 1.5 版的细微差别）。 - -关于我们未来计划的几句话： - -* 在我们的项目中增加基于 Tarantool 的服务的数量。 -* 迁移到 Tarantool 1.7。 -* 开始使用 Vinyl 引擎，尤其是对于 RepEntity，那里的真正“热”数据量并不大。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=12397570) - -保存 - -反垃圾邮件系统内部邮件处理的平均延迟是多少？ 是否有关于典型请求分解的任何分析信息？ \ No newline at end of file +# Slashdot Architecture-互联网的老人如何学会扩展 + +> 原文： [http://highscalability.com/blog/2007/11/12/slashdot-architecture-how-the-old-man-of-the-internet-learne.html](http://highscalability.com/blog/2007/11/12/slashdot-architecture-how-the-old-man-of-the-internet-learne.html) + +**Slashdot effect**: overwhelming unprepared sites with an avalanche of reader's clicks after being mentioned on Slashdot. Sure, we now have the "Digg effect" and other hot new stars, but Slashdot was the original. And like many stars from generations past, Slashdot plays the elder statesman's role with with class, dignity, and restraint. Yet with millions and millions of users Slashdot is still box office gold and more than keeps up with the young'ins. And with age comes the wisdom of learning how to handle all those users. Just how does Slashdot scale and what can you learn by going old school? + +Site: http://slashdot.org + +## 信息来源 + +* [Slashdot 的设置，第 1 部分-硬件](http://meta.slashdot.org/article.pl?sid=07/10/18/1641203&tid=124) + * [Slashdot 的设置，第 2 部分，软件](http://meta.slashdot.org/article.pl?sid=07/10/22/145209) + * [Slashdot 第 3 部分的历史-成为公司](http://meta.slashdot.org/article.pl?sid=07/10/17/1412245) + * [Slashdot 的历史第 4 部分-昨天，今天，明天](http://meta.slashdot.org/article.pl?sid=07/10/31/1631213) + + ## 该平台 + + * MySQL + * Linux（CentOS / RHEL） + * 磅 + * Apache + * Perl + * 内存缓存 + * LVS + + ## 统计资料 + + * 从 1999 年开始构建系统。 + * 每月有 550 万用户访问。 + * 每天增加 7,000 条评论。 + * 每天的浏览量超过 900 万。 + * 超过 2100 万条评论。 + * 平均每月带宽使用量约为 40-50 兆位/秒。 + * 对于同一故事[，Kottke.org](http://www.kottke.org/06/01/digg-vs-slashdot) 发现 Slashdot 交付的用户是 Digg 的 4 倍。 因此，Slashdot 还没有死。 + * 摘自 **Slashdot 的历史第 4 部分**：*在[9 月 11 日]，主流新闻网站陷入了困境，尽管我们不得不关闭日志记录功能，但我们还是设法保持运转，在一个站点中共享新闻。 通常很难获得的时间。 那一天，使该站点发生的工程师团队齐心协力，做了不可能的事情，迫使我们有限的小型硬件集群处理的流量可能是正常一天的三倍或四倍。* + + ## 硬件架构 + + * 数据中心的设计与所有其他 SourceForge，Inc.站点相似，并且已证明可以很好地扩展。 + * 两个主动-主动千兆位上行链路。 + * 一对 Cisco 7301 作为网关/边界路由器。 执行一些基本过滤。 过滤是分层的，以分散负载。 + * 铸造厂 BigIron 8000 充当核心交换机/路由器。 + * Foundry FastIron 9604s 用作某些机架的交换机。 + * 一对可机架系统（1U； P4 Xeon 2.66Gz，2G RAM，2x80GB IDE，运行 CentOS 和 LVS）用作负载平衡防火墙，将流量分配到 Web 服务器。 [BIG-IP F5](http://www.f5.com/products/big-ip/) 正在其新数据中心中部署。 + * 所有服务器均至少为 RAID1。 + * 16 个 Web 服务器： + -运行 Red Hat9。 + -带有 2 个 Xeon 2.66Ghz 处理器，2GB RAM 和 2x80GB IDE 硬盘的机架式 1U 服务器。 + -两个提供静态内容：javascript，图像和非登录用户的首页。 + -前四个页面用于登录用户 + -10 个处理注释页面。 + -主机角色根据负载而更改。 + -所有 NFS 挂载均处于只读模式。 + * NFS 服务器是具有 2 个 Xeon 2.4Ghz 处理器，2GB RAM 和 4x36GB 15K RPM SCSI 驱动器的 Rackable 2U。 + * 7 个数据库服务器： + -全部运行 CentOS4。 + -2 个在主-主配置中： + -具有 16GB RAM，4x36GB 15K RPM SCSI 的 Dual Opteron 270， + -一个主服务器 只写数据库。 + -一个主数据库是只读数据库。 + -他们可以随时进行故障转移并切换角色。 + -2 个读取器数据库： + -具有 8GB RAM，4x36GB 15K RPM SCSI 驱动器 + 的 Dual Opteron 270，每个数据库均从一个主数据库进行同步。 + -可以增加更多规模，但目前足够快。 + -3 个其他数据库 + -具有 4GB RAM，8x36GB 10K RPM SCSI 驱动器的 Quad P3 Xeon 700Mhz + -Accesslog 写入器和 accesslog 读取器。 使用单独的数据库是因为审核和统计信息需要大量的 CPU 时间进行计算。 + -搜索数据库。 + + ## 软件架构 + + * 已登录用户和未登录用户的处理方式有所不同。 + -未登录的用户将看到同一页面。 此页面是静态页面，每两分钟更新一次。 + -登录的用户具有无法缓存的自定义选项，因此为这些用户生成页面会占用更多资源。 + * 6 磅服务器（对于 SSL 为 1 磅）用作反向代理： + -如果无法处理请求，则将其转发到 Web 服务器。 + -磅服务器与 Web 服务器在同一台计算机上运行。 + -分发它们是为了实现负载平衡和冗余。 + -SSL 由磅服务器处理，因此 Web 服务器不需要支持 SSL。 + * 16 个 apache Web 服务器（1.3 版）： + -从/ usr / local 挂载软件到只读 NFS 服务器上。 + -图像保持简单。 编译的全部内容是： + -mod_perl + -挥之不去地在交付过程中释放了 RAM。 + -mod_auth_useragent 阻止机器人。 + -1 用于 SSL。 + -2 用于静态（.shtml）请求。 + -4 为动态首页。 + -6 个用于动态评论传递页面（评论，文章，pollBooth.pl）。 + -3 用于所有其他动态脚本（ajax，标签，书签，firehose）。 + * 将 apache 服务器划分为不同角色的原因： + -隔离服务器，以防在特定页面上出现性能问题或 DDoS 攻击。 即使一部分出现故障，系统的其余部分也将起作用。 + -由于效率原因，例如 httpd 级别的缓存和 MaxClients 调整。 可以针对每个角色对 Web 服务器进行不同的调整。 对于动态 Web 服务器，MaxClients 设置为 5-15，对于静态服务器，MaxClients 设置为 25。 瓶颈是 CPU，而不是 RAM，因此，如果不能快速处理请求，那么出了点问题，排队更多的请求将无法帮助 CPU 更快地处理它们。 + * 使用只读安装有助于提高系统的稳定性。 写入/ usr / local 的任务（例如，每秒更新 index.html）在 NFS 服务器上运行。 + * 使用在 DBD :: mysql 和 DBI.pm 之上构建的自己的 SQL API。 + * 通过使用 memcached 缓存用户，故事和评论文本，极大地提高了性能。 + * 大多数数据访问是通过为每种数据类型定制的 get 和 set 方法以及执行一个特定更新或选择的方法进行的。 + * 多主复制体系结构即使在阻止查询（如 ALTER TABLE）期间也可以保持站点完全正常运行。 + * [多遍日志处理](http://slashdot.org/journal.pl?op=display&nick=jamie&uid=78724&id=93006&)用于检测滥用情况并挑选哪些用户获得了 Mod 积分。 + * 创建了针对垃圾邮件的审核系统。 起初只是几个朋友，然后是很多朋友。 这没有扩展。 因此，引入了“ mod points”系统，以便对系统做出贡献的任何用户都可以审核该系统。 + * 禁止活动用户防止机器人过度使用。 + + ## 得到教训 + + * 最富创造力的时期是资金紧缺，团队规模很小，每个人都在帮助其他人做任何需要做的事情。 + * 不要浪费时间优化代码，因为您太便宜了，无法购买更多机器。 购买硬件并花时间在功能上。 + * 卖给一家大公司，您将失去控制。 不断面临着去开发新产品，融合广告商提供的内容以及投放大型广告的阴暗面的压力。 + * 对希望您变得像其他所有人一样的力量说不。 尽管许多竞争对手来来去去，但 Slashdot 仍然存在，因为他们：*继续保持编辑独立性，适度的广告数量，广告和内容之间有明显的区别，当然，我们继续选择合适的故事来吸引人们 给我们现有的听众...不要花我们的时间去吸引其他听众，这些听众只会淡化讨论，从而使日复一日的你们中的许多人到来。* + * 将服务器隔离到不同的策略域中，以便您可以优化它们的配置。 + * 优化通常意味着缓存，缓存，缓存。 + * 表不完整，但大多已归一化。 在大多数情况下，这可以提高性能。 + * 在过去的七年中，开发数据库支持的网站的过程发生了变化：*数据库曾经是瓶颈：集中化，难以扩展，运行缓慢。 现在，如果您进行防御性编码，那么即使是便宜的 DB 服务器也可以运行一个相当大的站点，并且由于摩尔定律，内存缓存和开源数据库软件的改进，在您不进行扩展的情况下，扩展问题才真正成为问题。 实际上是 eBay 的大小。 这是编写 Web 应用程序的激动人心的时刻。* + +“对于动态 Web 服务器，MaxClients 设置为 5-15，对于静态服务器，MaxClients 设置为 25。” + +只有 15 点？ 我们在每个 Apache 上有 256 个（1u 服务器 2xOpteron 双核 4GB RAM），并使用 PHP 提供 9-10 倍的页面 + +取决于 apache 进程在做什么。例如，它们可以等待 SQl 结果。因此，最好等待更多的进程。 他们也在等待客户端获取所有发送的数据-速度较慢的客户端，需要更多进程来保持 CPU 利用率。 +但是 AFAIK slashdot 使用的是反向代理，到 apache 仅以全 CPU 速度运行 PHP 代码，并立即将数据返回给代理。 代理然后等待慢速客户端... + +Slashdot 不使用 PHP，而是使用 mod_perl。 + +他们如何将 NFS 只读安装在 Web 服务器上并仍然写入其中？ 他们是否首先从 Web 服务器到 NFS 服务器使用 ssh？ +谢谢， \ No newline at end of file diff --git a/docs/170.md b/docs/170.md index cf8766a..7ea791b 100644 --- a/docs/170.md +++ b/docs/170.md @@ -1,34 +1,93 @@ -# 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术 +# 阿尔及利亚通往全球 API 第 3 部分的愤怒之路 -> 原文： [http://highscalability.com/blog/2011/9/26/17-techniques-used-to-scale-turntablefm-and-labmeeting-to-mi.html](http://highscalability.com/blog/2011/9/26/17-techniques-used-to-scale-turntablefm-and-labmeeting-to-mi.html) +> 原文： [http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html) -![](img/3f78e30a68add9fe1ac9979800d3adf4.png) +![](img/46cc8fc72a878ff2f3c224caacde9f99.png) -在[如何在一个月内启动并扩展到一百万用户](http://www.jperla.com/blog/post/how-to-launch-in-a-month-scale-to-a-million-users)，[前技术副总裁兼 Turntable.fm 的创始团队 Joseph Perla](http://twitter.com/jperla) 分享了他用来构建和快速扩展的技术 他的创业公司。 该帖子写得很好，必须阅读。 这里是要领： +我们为开发人员和开发人员回答的最常见问题是关于 [我们的架构](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 以及我们如何实现如此高的可用性。 他们中的一些人对裸机服务器的高可用性持怀疑态度，而另一些人则对我们如何在全球范围内分发数据持怀疑态度。 但是，我更喜欢的问题是“初创企业如何建立这样的基础架构”。 的确，对于一个年轻的公司，我们当前的架构令人印象深刻： -1. **保持简单。** 在制作网站或移动应用之前，请构建 API。 保持界面小巧，用途单一。 -2. **正确处理。** 从一开始就内置自动化测试。 创建功能测试，模块级别测试和完全集成测试。 对每个提交运行测试。 存在错误时，无需编写新代码。 -3. **不要隐藏力量。** 使用 [Pebbles](http://www.jperla.com/blog/post/write-bug-free-javascript-with-pebbles) 编写无错误的 Javascript，该库通过在代码中添加一些额外的 HTML 标记来编写 0 个 javascript，从而创建复杂的 AJAX 交互。 -4. **使用过程参数可提供接口的灵活性。** 通过函数而不是参数来支持复杂的场景。 例如，过滤器函数返回布尔值。 -5. **留给客户端。** 保持服务器简单，并将尽可能多的功能移至客户端。 -6. **连续性。** 保持接口稳定。 版本从一开始就是接口。 -7. **保守实现的秘密。** 保持服务实现完全独立，以提供最大的灵活性来处理需求更改，即使这意味着性能会略有下降。 -8. **再次使用一个好主意，而不是一概而论。** 复制和专用化类似代码而不是创建一个更通用的库是可以的。 -9. **通常分别处理正常情况和最坏情况。** 代码应该清楚地显示特殊情况，而不是使用更通用的算法来删除特殊情况。 -10. **如果有疑问，请以固定方式拆分资源。** 服务器应为单一用途。 例如，将数据库索引和搜索索引保留在单独的计算机上。 然后可以独立缩放它们，而不会彼此脚。 -11. **如果可以，请使用静态分析。** 在签入时运行对代码的堆栈分析工具，以查找错误和性能问题。 -12. **从方便的表示形式动态转换为可以快速解释的形式。** 例如，用于 tweet 过滤的 Python 特定于域的语言易于编程，可以直接转换为 python 字节码。 -13. **缓存可解决昂贵的计算问题。** 不言自明，，但请注意缓存失效问题。 -14. **如有疑问，请使用蛮力。** 最好使用简单的算法更快地完成功能，而不是延迟实现聪明的算法。 -15. **尽可能在后台计算。** 在 Web 服务器中做尽可能少的工作，将其排队到后台进程。 -16. **尽可能使用批处理。** 加载单个数据项的速度很慢，请大批量加载它们。 -17. **减少负载以控制需求。** 可以有限制。 选择使您的软件正常工作的限制，而无需经过巨大的努力或更改堆栈。 +* 我们的高端专用计算机在全球 13 个地区托管，拥有 25 个数据中心 -## 相关文章 +* 我们的主从设置会在至少 3 台不同的计算机上复制我们的搜索引擎 -* [有关计算机系统设计的提示](http://research.microsoft.com/en-us/um/people/blampson/33-Hints/WebPage.html)，作者：Butler W. Lampson +* 我们每个月处理超过 60 亿个查询 -如果说基于 JavaScript 构建一个 api，则不确定“将其交给客户端”始终是正确的方法。 -如果该产品在紧凑型市场中，您将考虑使用一个简单的 api 来快速实施，并使用更复杂的服务器端 +* 我们每个月接收和处理超过 200 亿次写操作 -＃8 是最简单但经常被忽略的问题之一。 开发人员通常尝试在模式中寻找任何类型的通用性，以证明将抽象功能集成到单个通用组件中是合理的。 有时这是一个好主意，但有时它只会创建难以管理的代码，并且可能对性能产生负面影响。 做好一件事情，而不是少做一件事情。 \ No newline at end of file +就像罗马不是一天建成的，我们的基础架构也不是很好。 本系列文章将探讨我们在构建基础架构时采取的 15 个工具步骤。 我什至将讨论我们的中断和错误，以便您了解我们如何使用它们来改进我们的体系结构。 + +此系列的 [第一篇博客文章](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html) 专注于我们早期的 Beta 版， [第二篇文章](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html) 在服务的前 18 个月，包括我们的首次停机。 在上一篇文章中，我将描述我们如何将“启动”架构转换为能够满足大型上市公司期望的新事物。 + +## 步骤 11：2015 年 2 月 + +### 启动我们的全球同步基础架构 + +在这个月中，我们实现了自 2014 年 4 月以来一直致力于的愿景，即“向全球扩展以更好地为我们的用户服务”。 + +该网络由 12 个不同的位置组成：美国东部（弗吉尼亚州），美国西部（加利福尼亚州），澳大利亚，巴西，加拿大，法国，德国，香港，印度，日本，俄罗斯和新加坡。 最重要的是，我们还启动了“分布式搜索”功能。 使用此功能，只需单击几下，您就可以设置网络中应该自动复制数据的位置。 您将使用与以前相同的 API，查询将自动从最终用户的浏览器或移动应用程序路由到最近的位置。 + +这是减少最终用户延迟并通过全球搜索分布提高我们的高可用性的重要一步。 由于互联网链接的距离和饱和度，从一个位置为国际用户提供服务会导致非常不同的服务质量。 现在，我们为用户提供了解决该问题的方法！ 除了减少延迟之外，这还提高了我们搜索基础架构的高可用性，因为它不再依赖于单个位置。 遍布全球！ + +有些人将我们的 DSN（分布式搜索网络）与 CDN（内容交付网络）进行了比较，但这是非常不同的。 我们不会在每个边缘存储您经常查询的缓存。 我们存储您所有数据的完整副本。 我们可以从边缘位置本身响应任何查询，而不仅仅是最流行的查询。 这意味着，当您选择三个 POP（美国东部，德国，新加坡）时，欧洲的用户将前往德国，亚洲的用户将前往新加坡，美国的用户将前往美国东部。 所有 POP 都将响应查询，而不必与其他边缘进行通信。 这在用户体验和高可用性方面产生了巨大的差异。 + +为了支持此更改，我们更新了 API 客户端中的重试逻辑，以首先定位 [APPID-dsn.algolia.net](http://appid-dsn.algolia.net) 主机名， 使用基于 geoip 的 DNS 将其路由到最近的位置。 如果最接近的主机关闭，则更新 DNS 记录以在不到一分钟的时间内删除该主机，以便返回下一个最接近的主机。 这就是为什么我们在每条记录上使用 1 分钟的低 TTL 的原因。 如果发生故障，如果主机关闭并且 DNS 尚未更新，我们将通过 [APPID-1.algolia.net](http://appid-1.algolia.net) 上的重试将流量重定向到主区域。 ， [APPID-2.algolia.net](http://appid-2.algolia.net) 和 [APPID-3.algolia.net [ 我们的官方 API 客户端中的](http://appid-3.algolia.net) 。 这种方法是我们在高性能和高可用性之间找到的最佳平衡，万一发生故障，我们只会在一分钟内降低性能，但 API 仍可以运行&！ + +## 步骤 12：201 年 3 月 + +### 每个位置的更高可用性 + +分布式搜索网络选项可改变游戏规则，以实现高可用性，但仅适用于搜索用户和国际用户。 为了提高主要区域的高可用性，我们在两个完全独立的提供商中分布了我们的美国集群： + +* 两个不同位置的数据中心（例如：Manassas 中的 COPT-6 & Ashburn 中的 Equinix DC-5：彼此之间 24 英里，延迟为 1ms） + +* 三台不同的计算机-就像以前一样（两台在不同可用性区域中的第一个数据中心，另一台在第二个数据中心中的） + +* 两个不同的自治系统（所以两个完全不同的网络提供商） + +这些更改提高了我们对遇到的某些问题（例如提供商和 AWS 之间的对等链接的饱和）做出反应的能力。 拥有不同的提供商可以使我们选择将流量重新路由到其他提供商。 就提高一个位置的高可用性而言，这是一大进步。 + +## 步骤 13：2015 年 4 月 + +### 随机文件损坏头痛 + +对于我们的制作团队来说，2015 年 4 月是一个黑色的月份。 由于某些 SSD 的 TRIM 实现中存在错误，我们开始观察生产机器上的随机文件损坏。 您可以在 [此博客文章](https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/) 中详细阅读该问题。 我们花了大约一个月的时间来跟踪问题并正确识别。 在这段时间里，我们怀疑一切，从我们自己的软件开始！ 这也是对我们的体系结构的重大考验。 在磁盘上随机破坏文件不是一件容易的事。 通知我们的用户由于磁盘已损坏而需要重新索引其数据也不容易。 幸运的是，我们从未丢失任何客户数据。 + +我们的架构中有两个重要因素使我们能够面对这种情况而不会丢失任何数据： + +* 我们存储了三个数据副本。 在三台计算机上随机破坏相同数据的可能性几乎为零（并且没有发生）。 + +* 更重要的是，我们没有复制索引结果。 相反，我们复制了从用户那里收到的操作，并将其应用于每台计算机。 由于一台受影响的机器无法“污染”另一台机器，因此这种设计使几台机器具有相同损坏的可能性非常低。 + +设计架构时，我们从未考虑过这种情况！ 即使我们试图考虑所有类型的网络和硬件故障，我们也从未想象过内核错误甚至固件错误的后果。 我们的设计要有独立的机器，这是我们能够最小化问题影响的原因。 对于任何需要高可用性的系统，我强烈建议这种独立性。 + +## 步骤 14：2015 年 5 月 + +### 引入了多个 DNS 提供商 + +由于 NSONE 出色的 DNS API，我们决定将其用作 DNS 提供程序。 我们能够配置我们希望如何通过他们的 API 路由每个用户的查询。 我们也非常喜欢他们如何支持 edns-client-subnet，因为这对于提高地理路由的准确性至关重要。 这些功能使 NSONE 成为了出色的提供商，但是我们在架构中仅拥有一个提供商就不会给自己带来风险。 + +面临的挑战是在不损失 NSONE 的所有强大功能的情况下引入第二个 DNS 提供商。 这意味着不能在同一域上拥有两个 DNS 提供程序。 + +我们决定在 API 客户端中使用重试策略来引入第二个 DNS 提供程序。 所有 API 客户端首先尝试与 [APPID-dsn.algolia.net](http://appid-dsn.algolia.net) 联系，如果有任何问题，他们将在其他域，TLD 和 提供者。 我们决定使用 AWS Route 53 作为我们的第二个提供商。 如果有任何问题，API 客户端将在 [APPID-1.algolianet.com](http://appid-1.algolianet.com) ， [APPID- 2.algolianet.com](http://appid-2.algolianet.com) 和 [APPID-3.algolianet.com](http://appid-3.algolianet.com) 定位于主群集的 3 台计算机。 这种方法使我们能够将 NSONE 的所有有趣的地理路由功能保留在 algolia.net 域上，同时引入第二个提供商以在 algolianet.com 域上提供更高的高可用性。 + +## 步骤 15：2015 年 7 月 + +### 每个群集三个完全独立的提供程序 + +您现在可以考虑使用我们开发的基础架构，我们现在完全可以应对任何问题……但是实际情况有所不同。 即使使用由具有多个可用区的 Cloud Provider 托管的服务，您也可能会停机。 我们看到两个主要原因： + +* 链接/路由器开始产生数据包丢失。 我们已经在美国东部和美国西部之间多次看到这种情况，包括大型云提供商的边界 ISP 路由器，尽管他们甚至没有意识到这一点。 + +* 路由泄漏。 这尤其影响了很大一部分 Internet 依赖的大型参与者。 + +现在，我们在美国改进的设置使我们能够构建跨多个数据中心，多个自治系统和多个上游提供商的集群。 就是说，为了接受索引操作，我们需要配置大多数计算机，这意味着三台计算机中的两台。 当使用两个提供程序时，如果我们的一个提供程序出现故障，尽管搜索仍然可用，但我们可能会失去索引服务。 这就是为什么我们决定进一步在三个完全独立的提供商（在相互靠近的位置上依赖于不同上游提供商和自治系统的位置的不同数据中心）中托管群集的原因。 这种设置使我们能够通过超冗余基础架构提供高可用性的搜索和索引。 我们提供所有这些以及相同的易于使用的 API！ + +## 建立高度可用的架构需要时间 + +我希望我们的旅程细节能够启发人心，并提供有关我们的开始方式和今天的状况的有用信息。 如果您是一家初创企业，请不要担心一开始就没有完善的基础架构。 这是意料之中的！ 但是您应该考虑您的体系结构以及如何尽早扩展它。 我什至建议您在 Beta 版之前进行操作！ + +尽早设计**架构是我们的秘密武器**。 一旦市场适应，我们就可以专注于执行。 即使在今天，我们在可伸缩性/可用性方面仍具有一些功能，这些功能在很早之前就已设计并尚未实现。 但是他们肯定会在不久的将来到来的:) + +*以下是该系列的所有三个部分：[第 1 部分](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html)，[第 2 部分](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html)，[第 3 部分](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html)* + +*[关于 HackerNews](https://news.ycombinator.com/item?id=9956097)* \ No newline at end of file diff --git a/docs/171.md b/docs/171.md index fb62175..aa4003f 100644 --- a/docs/171.md +++ b/docs/171.md @@ -1,45 +1,288 @@ -# Pud 是反堆栈-Windows，CFML，Dropbox，Xeround，JungleDisk，ELB +# Google 如何创造只有他们才能创造的惊人的数据中心网络 -> 原文： [http://highscalability.com/blog/2011/8/31/pud-is-the-anti-stack-windows-cfml-dropbox-xeround-jungledis.html](http://highscalability.com/blog/2011/8/31/pud-is-the-anti-stack-windows-cfml-dropbox-xeround-jungledis.html) +> 原文： [http://highscalability.com/blog/2015/8/10/how-google-invented-an-amazing-datacenter-network-only-they.html](http://highscalability.com/blog/2015/8/10/how-google-invented-an-amazing-datacenter-network-only-they.html) -![](img/3df181c2449112fc84fefff148fcc943.png) +![](img/03f45e60840ae56bc19c78b74d32e42f.png) -[f * ckedcomany.com](http://www.fuckedcompany.com/) （FC）的知名度，点炸弹时代最喜欢的网站以及在我公司成为特色公司之前我一直很喜欢的网站，让我们看看他的后端：[为什么您必须嘲笑我的后端](http://blog.pud.com/post/9582597828/why-must-you-laugh-at-my-back-end)。 对于那些不记得 FC 的历史的人，TechCrunch 发布了[合适的悼词](http://techcrunch.com/2007/03/31/techcrunch-has-acquired-fuckedcompanycom/)： +最近以自己的骄傲而自豪的 Google [宣布了](http://googlecloudplatform.blogspot.com/2015/06/A-Look-Inside-Googles-Data-Center-Networks.html) ： -> [FC]于 2000 年首次上线，在网络泡沫破灭之后，以失败者和陷入困境的公司以其独特而粗糙的风格来记录。 不到一年的时间，它吸引了众多观众，并受到了主流媒体的严重关注。 随着 2004 年创业经济的好转，该网站获得的大部分关注都消失了。 但是，仍然有大量忠实的观众留在网站上，由于其在新闻上的独特倾向，日复一日地回来。 在鼎盛时期，FC 每月有 400 万独立访问者。 +> 今天在 2015 年开放网络峰会上，我们将首次揭示五代内部网络技术的详细信息。 从十年前我们的第一个内部数据中心网络 Firehose 到最新一代的 Jupiter 网络，我们已经将单个数据中心网络的容量提高了 100 倍以上。 我们当前的产品-Jupiter 织物-可以提供超过 1 PB / sec 的总 对等带宽 。 从角度来看，这样的容量足以使 100,000 台服务器以 10Gb / s 的速度交换信息，足以在不到 1/10 秒的时间内读取国会图书馆的全部扫描内容。 -令人高兴的是，FC 并非实名网站。 顽强的机智犬儒主义统治了一切，看不到一只猫的照片。 当周围都是黑暗时，这真是一种乐趣。 +Google 的数据中心网络是使 Google 真正发挥作用的背后的魔力。 但是什么是“双向带宽”，为什么重要呢？ 早在 [不断变化的架构中，我们讨论了双向带宽：新的数据中心网络将使您的代码和数据免费](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) 。 简而言之，双向带宽是指 Google 服务器用来相互通信的网络。 -因此，当我看到 Pud 的帖子时，我很感兴趣地看看他在做什么。 我没有失望。 这是适当的特质： +历史上，数据中心网络的定位是与用户交谈。 假设某网页请求来自浏览器。 该请求将发送到服务器，并通过仅与其他几台服务器（甚至根本没有服务器）进行通信来制作答复，然后将答复发送回客户端。 这种类型的网络称为面向北方/南方的网络。 实施请求几乎不需要内部沟通。 -* **Windows Server 2008** -像 GUI，几乎像 AWS 上的 Linux 一样便宜，可以完成您需要的所有东西 -* **IIS 7** -完成您需要的所有内容 -* **ColdFusion 标记语言**-完成您需要的所有内容 -* **Xeround.com 用于数据库**-看起来很有趣 -* **5 个 EC2 微型实例**-每个服务器每月$ 20。 发现 micro 的性能和 xlarge 实例的性能一样好，所花的钱更少。 另外，您还将获得 5 倍的冗余。 可以在需要时插入弹性酱。 -* **弹性负载平衡**-用于将 5 个微型实例连接在一起。 -* **Dropbox** -更改代码后，所有服务器都使用 Dropbox 进行同步。 更改几乎立即同步到所有框。 不要忘记，[亚马逊的 Werner Vogels](http://highscalability.com/blog/2011/8/22/strategy-run-a-scalable-available-and-cheap-static-site-on-s.html) 也使用了 Dropbox。 巧合还是光彩？ -* **备份**-默认情况下，DropBox 保留异地备份。 JungleDisk 还每天晚上运行并通过电子邮件发送结果。 +随着网站和 API 服务的日趋丰富，这一切都发生了变化。 现在，可以进行 [数以千计的](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) 后端请求来创建单个网页。 令人振奋。 这意味着通信已从与用户交谈的主导转变为与数据中心内其他计算机的交谈。 因此，这些被称为东西方网络。 -毫无疑问，Pud 期待着这种反感： +向东方/西方主导的通信方式的转变意味着数据中心网络需要不同的 [拓扑结构](https://en.wikipedia.org/wiki/Network_topology) 。 旧的传统 [胖树](https://storagemojo.com/2008/08/24/fat-trees-and-skinny-switches/) 网络设计已经淘汰，需要采取一些新的方法来代替它。 -* 这些应用程序可以自行运行并具有可扩展性。 -* 可以不要酷。 +Google 一直处于开发新的丰富服务支持网络设计的最前沿，这主要是因为他们的指导思想是将 [数据中心视为计算机](http://research.google.com/pubs/pub35290.html) 。 一旦您的数据中心成为计算机，您的网络就相当于一台计算机上的 [背板](https://en.wikipedia.org/wiki/Backplane) ，因此它必须尽可能快且可靠，因此远程磁盘 并且可以像访问本地存储一样访问远程存储。 -评论和 [Reddit](http://www.reddit.com/r/programming/comments/jz7p9/why_must_you_laugh_at_my_back_end/) 和 [HackerNews](http://news.ycombinator.com/item?id=2942129) 上的很多人都陶醉于此堆栈的 s 谐之中。 但这真的很烂吗？ +Google 的工作围绕着三个有计划的攻击计划：使用 [Clos 拓扑结构](https://en.wikipedia.org/wiki/Clos_network) ，使用 [SDN](https://www.youtube.com/watch?v=ED51Ts4o3os) （软件定义网络），并以自己的 Googlish 方式构建自己的自定义设备。 -* 他知道堆栈。 -* 他得到了它的工作。 -* 它适用于预期的目的。 -* 他有时间去做更重要的事情。 -* 他赚钱。 +到目前为止，我们对 Google 的网络设计的了解有限。 Google 研究员和 Google 联网技术负责人 [Amin Vahdat](http://research.google.com/pubs/AminVahdat.html) 虽然没有完全访问权限，但在 精彩演讲： [ONS [开放网络峰会] 2015：星期三主题演讲](https://www.youtube.com/watch?v=FaAZAII2x0w) 。 还有一篇论文： [Jupiter Rising：Google 数据中心网络](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf) 的 Clos 拓扑和集中控制的十年。 -Pud 的体系结构中显然有一个自然的过程正在起作用，这表明。 它不是使用最佳实践或参考设计来定义的，而是根据需求和能力明确展现出来的。 我在此设置中看到很多 [wabi-sabi](http://en.wikipedia.org/wiki/Wabi-sabi) ：*一种“不完美，无常和不完整”的美。 wabi-sabi 美学的特征包括不对称，粗糙（粗糙或不规则），简单，经济，紧缩，谦虚，亲密和欣赏自然物体和过程的固有完整性。* +为什么要比通常提前发布细节？ 谷歌与亚马逊之间存在真正的竞争，因此他们需要找到引人注目的差异化点。 谷歌希望他们的数据中心网络就是其中之一。 -那很烂吗？ 绝对。 为了我。 一千个“假设”很容易想到。 但这有效，这是其真正的艺术。 +那么，是什么让 Google 与众不同？ 整体讯息： -附言 +* 摩尔定律的终结意味着程序的构建方式正在发生变化。 -即使这只是一些精心设计的笑话，结论仍然适用。 选择任何堆栈，您可以进行相同的讨论，只是争论不同的观点。 +* Google 知道了。 Google 知道如何建立良好的网络并实现适当的数据中心平衡。 -哇，我差点忘了这个网站。 我听说有关该想法的最新观点，http：//www.officeleaks.com \ No newline at end of file +* 您可以利用 Google 的云平台（与支持 Google 搜索的平台相同）的创新和功能来实现繁荣。 + +* 所以爬上去，网络很好！ + +够了吗？ 也许这不是一个具有广泛吸引力的信息，但它可能会找到有区别的买家的房屋。 + +我的演讲重点： + +* **我们不知道如何构建可提供大量带宽的大型网络**。 Google 说，他们的网络提供了 1 Pb / sec 的总二等分带宽，但事实证明这还远远不够。 为了支持数据中心的大型计算服务器，您需要 5 Pb / sec 的网络。 请记住，今天整个互联网可能接近 200Tb / s。 + +* **在大型群集**上安排作业效率更高。 否则，您会将 CPU 留在一个地方，将内存留在另一个地方。 因此，如果您可以正确地构建系统，那么数据中心规模的计算机将为您带来确定的规模经济。 + +* **Google 利用从服务器和存储世界中汲取的经验教训构建了数据中心网络系统**：横向扩展，逻辑上集中化，使用商品组件，从不管理任何单一组件。 统一管理所有服务器，存储和网络。 + +* **I / O 差距很大**。 阿明说必须解决，如果没有解决，我们将停止创新。 通过分类可以增加存储容量。 机会是像访问本地数据中心一样访问全局数据中心存储。 使用 Flash 和 NVM 会越来越难。 闪存和 NWM 的新层将完全改变编程模型。 注意：很遗憾，他没有扩大这个概念，我非常希望他能这样做。 阿敏，我们可以谈谈吗？ + +在一个好故事中，您所寻找的是扮演核心身份角色的角色。 在这里，我们看到 Google 运作的独特愿景来自其在构建可扩展软件系统方面的丰富经验而有机发展。 也许只有 Google 才能勇于遵循自己的愿景，并建立与公认的智慧完全不同的数据中心网络。 这需要巨大的精力。 这造就了一个好故事。 + +这是我在演讲中毫无希望的不足： + +* 十年来，数百人为这项工作做出了贡献。 + +* 自从大约 30 年前将套接字引入 BSD 以来，分布式编程就面临着同样的挑战。 这将改变。 + +* 随着摩尔定律的结束，我们对计算的思考方式必须改变，而分布式计算的方式将要改变。 + +* 计算的关键部分以及人们如何构建自己的系统都围绕存储。 + +* 我们已经看到，遵循摩尔定律，存储容量有了巨大的增长。 + +* I / O 间隙仍然存在。 处理器与他们需要处理的基础数据之间的距离正在不断增加。 + +* 我们可以认为遍布整个建筑物的磁盘可用于任何服务器。 这是太棒了。 同时，鉴于我们拥有的处理能力，它们正在越来越远地寻找。 + +* 分布式计算环境中的大规模下一代闪存仍未开发。 + +* 在计算的未来意义上，网络将扮演至关重要的角色。 + +* 联网处于拐点。 计算手段将在很大程度上取决于您构建强大网络的能力。 + +* 因此，数据中心网络是关键的区别因素。 + +* Google 建造了建筑规模的计算机。 计算一行一行，存储一行一行。 + +* 多年来，Google 建立了软件基础架构以利用其硬件基础架构： + + * GFS（2002），MapReduce（2004），BigTable（2006），Borg（2006），Pregel（2008），Colossus（2010），FlumeJava（2012），Dremel，Spanner。 + + * 这些努力中的许多已经定义了当今进行分布式计算的含义。 + +* 没有世界一流的网络基础架构，您将无法建立世界一流的分布式计算基础架构。 您如何构建像 GFS 这样的系统来利用 100,000 个磁盘，而没有世界一流的网络将它们整合在一起？ + +* Google 在网络方面的创新： + + * Google Global Cache（2006 年）：如何交付内容，包括来自世界各地的视频和静态内容） + * 守望台（2008） + * Freedome：校园级互连 + * Onix（2010 年 + * BwE（2010） + * B4：Google 的软件定义 WAN，可将全球所有数据中心连接在一起。 它比面向公众的网络更大，并且增长速度更快。 + * Jupiter（2012）：高带宽数据中心规模联网 + * Andromeda（2014）：网络虚拟化。 我们如何利用我们的基础网络基础架构，并将其拆分成单个虚拟机，以至于它们拥有自己的高性能网络？ 我们如何打开 Goog​​le 一直用于其服务（例如负载平衡，DDoS 保护，访问控制列表，VPN，路由等）的相同类型的网络虚拟化，以及如何使这些隔离网络在原始硬件上运行（如果可用） ？ + * QUIC + * gRPC：Google 内部使用的多平台 RPC，负载平衡，应用程序级流控制，取消调用，序列化，开源，HTTP / 2。 构建分布式服务的良好基础。 + +## 数据中心网络 + +* 数据中心网络与传统 Internet 网络不同。 + + * 由单个组织运营，并且已预先计划。 必须发现互联网才能看到它的外观。 您实际上知道网络在数据中心中的外观。 您已经计划好了。 您建立了它。 因此，您可以集中管理它，而不用随便发现它。 由于它是在单一组织的控制下，因此您可以运行的软件可能会大不相同。 它无需与 20 年的历史遗存进行互操作，因此可以针对您的需要对其进行优化。 + + * 吸引人们加入网络的通常是问题的美。 美丽可能意味着这是一个难题。 是否可以将问题定义为更简单，更可扩展且更容易？ + +* Google 需要一个新的网络。 大约十年前，谷歌发现传统的网络架构，包括硬件和软件，**无法满足**的带宽需求以及数据中心中分布式计算基础架构的规模。 + +* 我们可以买吗？ + + * Google 无法以任何价格购买能够满足 Google 分布式系统要求的数据中心网络。 + +* 我们可以运行它吗？ + + * 以箱为中心的部署产生了高**操作复杂性**的成本。 即使 Google 买了他们能买到的最大的数据中心网络，用于操作这些网络的模型还是围绕着具有单独命令行界面的单个盒子。 + + * Google 已经知道如何处理成千上万的服务器，就像它们是一台计算机一样，如何处理成千上万的磁盘，就像它们是一个存储系统一样。 必须像管理一千个交换机一样管理一千个交换机**的想法没有多大意义，而且似乎不必要地困难**。 + +* 我们将构建它。 + + * 受服务器和存储领域的经验启发： **横向扩展** 。 + + * 无需弄清楚如何购买下一个最大的网络或下一个最大的路由器，而是可以像使用服务器和存储一样，通过使用**个附加商品元素**来扩展交换和路由基础结构。 + + * 当出现需要**插入另一个网络元素**以提供更多端口和更多带宽时，为什么不这样做呢？ + +* 允许 Google 建立横向扩展数据中心网络的三个关键原则： + + * **Clos 拓扑结构** 。 这个想法是利用小型商品交换机来构建一个可以无限扩展的无阻塞超大型交换机。 + + * **商业硅** 。 由于 Google 并未建立广域网互联网基础架构，因此他们不需要庞大的路由表或深度缓冲。 这意味着商业硅芯片可以完成在数据中心中构建基于 Clos 的拓扑的工作。 + + * **集中控制** 。 软件代理知道网络的外观，设置路由，并对基础计划中的异常做出反应。 知道网络的形状后，管理网络要比不断尝试发现其外观要容易得多。 如果要更改网络，则可以告诉集中控制软件更改网络。 + +* 数据中心网络的方法也适用于园区网络，将建筑物连接在一起并连接到广域网。 B4 和 Andromeda 受到数据中心网络工作的启发和启发，他们多年来一直在练习构建自己的硬件和集中控制基础结构。 + +* 在过去 6 年中，数据中心带宽增长了 50 倍。 + + * 需要交付给 Google 服务器的带宽超过了摩尔定律。 + + * 这意味着要满足 Google 必须能够扩展的带宽需求，就不可能不断地淘汰旧设备并建立新的网络。 + +* 规模驱动架构。 + + * 当今的典型网络（不一定是 Google）可能具有 10K +交换机，250K +链接，10M +路由规则。 **如此规模的网络处理方式与规模较小的网络**根本不同。 + +* 为什么要建立整个数据中心规模的网络？ + + * 一些最大的数据中心拥有 10 兆瓦和 10 兆瓦的计算基础架构。 + + * 如果您无法大规模调度，则有大量的 **资源搁浅** 。 想象一下需要在共享基础结构上运行的许多不同的作业。 如果必须在一个群集的边界内调度作业，并且您有 101,000 个服务器群集，而您有 110,000 个服务器群集，那么如果可以在 10,000 个服务器群集中任意调度，则效率会好得多。 如果您可以将作业放置在 10,000 台服务器中的任何位置，而不必放在 1,000 台服务器中，那么这个数字就显得非常少。 因此，如果可以构建一个网络以扩展到整个建筑物，那么从计算和磁盘上获得的效率将更高。 这些最终成为主要成本。 该网络可能非常便宜，并且可以成为计算和存储的促成因素。 + + * “资源搁浅”是指将一个 CPU 留在一个地方，而将内存留在另一个地方（ [源](http://jturgasen.github.io/2014/10/26/tech-takeaway-012-cluster-management-at-google/) ）。 + +* 平衡您的数据中心。 + + * 一旦达到建筑物的规模，就必须确保提供足够的带宽。 + + * 不平衡的数据中心缺少**某些资源，这限制了您的价值**。 如果一种资源稀缺，则意味着其他一些资源处于闲置状态，这会增加您的成本。 + + * 通常，在数据中心规模上，最稀缺的资源是网络。 由于我们不知道如何构建可提供大量带宽的大型网络，因此网络配置不足。 + +* 带宽。 阿姆达尔还有另一部法律。 + + * 对于并行计算，每 1 Mhz 计算需要 1 Mbit / sec 的 IO。 + + * 举例来说，仅在您附近的未来数据中心中，计算服务器具有 64 * 2.5 Ghz 内核，然后为了平衡每个服务器大约需要 100 Gb / s 的带宽。 这不是本地 IO。 本地 IO 无关紧要。 您需要访问数据中心范围的 IO。 数据中心可能有 5 万台服务器； 100k + IOPS 的闪存存储，100 毫秒的访问时间，PB 级存储； 将来，其他一些非易失性存储器技术将具有 1M + IOPS，10 微秒的访问时间和 TB 的存储量。 + + * 因此，您将需要 5 Pb / s 的网络和具有相应功能的交换机。 即使超额预订比率为 10：1，这也意味着您将需要 500Tb / s 的数据中心网络来接近平衡。 从角度来看，一个 500Tb / s 的网络比今天的整个 Internet 容量更大（可能接近 200Tb / s）。 + +* 延迟。 为了实现存储基础架构分解的目标，您需要可预测的低延迟。 + + * 磁盘速度很慢，访问延迟为 10 毫秒，因此很容易使它们看起来很本地。 网络比这快。 + + * Flash 和 NVM 困难得多。 + +* 可用性。 您的计算价值很高，需要不断引入新服务器，需要将服务器升级到 1G-> 10G-> 40G-> 100G->？ + + * 无法拆除建筑物以进行升级。 投资太大了。 刷新网络和服务器必须保持不变。 旧的必须与新的一起生活，而不能完全中断很大的容量。 + + * 扩展网络无效。 无法在遍布整个数据中心的网络上进行焦土升级。 + +* Google Cloud Platform 建立在支持 Google 规模，性能和可用性的数据中心网络基础架构上。 这是向公众开放的。 希望下一个出色的服务可以利用此基础结构而无需发明它。 + +* 关键的挑战是在提供隔离的同时打开硬件的原始容量。 + +## 软件定义的网络 + +* 网络是实现下一代计算机体系结构的关键因素。 SDN 将扮演关键角色。 + +* SDN 是关于抽象并管理复杂性的软件 [控制平面](http://sdntutorials.com/difference-between-control-plane-and-data-plane/) 。 这是要超越框框。 这是关于将网络接口更改为标准协议而不是标准协议，而是关于管理复杂性，将其隐藏并可以使 10,000 台交换机看起来像一个的软件控制平面。 + +* 硬件将在那里。 您如何管理它，就像它是一个大实体一样？ 这就是服务器端，存储端和网络端的问题。 + +* Google 开始了，每个人都开始使用四柱集群网络来构建数据中心网络。 网络的大小和带宽由他们可以购买的最大路由器决定。 当需要更多容量时，他们需要使用更大的路由器来构建另一个数据中心网络。 + +* 围绕 Clos 拓扑的方法是使用商用交换芯片，并构建超过 5 代的网络，如下所示： + +## ![](img/f40720a8eb01e83f28000a41bb8fa046.png) + +* 基于 Clos 的分层拓扑结构表示在 Clos 拓扑结构中利用了商户硅片，可在建筑物规模上提供高带宽。 为机架式交换机顶部供电的同一交换机芯片将服务器连接在一起，也为聚合模块供电，这些聚合模块可在一定数量的机架之间提供连接。 相同的硅为将边缘聚合层连接在一起的脊柱层提供动力。 + +* 十年前，总带宽为 2 兆比特/秒。 最新一代的 Jupiter 结构提供 1.3 Pb / s 的带宽。 他们的 Jupiter Superblock 交换机提供 80Tb / s 的带宽，它通过 OpenFlow 托管 SDN 软件堆栈，并受到远程控制。 交换机将利用 Google 已获得的余额为所有数据中心供电。 + +## 网络控制 + +* 早期，Google 面临着如何构建其控制平面的选择。 使用现有的服务提供商相关的 OSPF，ISIS，BGP 等堆栈。或者构建自己的堆栈。 + +* 他们出于多种原因选择构建自己的。 + + * Google 十年前考虑的拓扑需要多路径转发才能起作用。 为了获得所需的带宽，需要在源目标之间建立很多路径。 现有协议不支持多路径。 他们是关于连通性的。 查找从源到目的地的路径，而不是最佳路径，而不是多个路径。 + + * 十年前，还没有高质量的开源堆栈。 + + * 所有协议都是基于广播的，而 Google 希望以此规模运作，他们担心基于广播的协议的可扩展性。 + + * 安装基于广播的协议后，您必须配置每个单独的框以使用它们，而 Google 对此并不满意。 + +* 将这一切与从 Google 学到的新常规知识结合在一起，以大规模构建大规模系统： + + * **逻辑上将** （这并不意味着单个服务器）集中在具有点对点数据平面的分层控制平面的情况下。 看到它一遍又一遍地播放，并且也与数据中心网络一起播放。 + + * **向外扩展** 比向上扩展方便得多。 使用 GFS，MapReduce，BigTable 和 Andromeda 可以看到这种情况。 + + * **集中式配置和管理** 大大简化了系统的所有方面以及部署。 + +## 相关文章 + +* [在 HackerNews](https://news.ycombinator.com/item?id=10037960) 上/ [木星在 HackerNews](https://news.ycombinator.com/item?id=9977414) 上崛起 + +* [Google 在大规模定义软件定义的网络功能虚拟化方面的经验](https://www.youtube.com/watch?v=n4gOZrUwWmc) （Google 视频，2014 年） + +* [直观地了解 Google 在全球网络基础架构中的创新](http://googlecloudplatform.blogspot.com/2015/08/a-visual-look-at-googles-innovation-in.html) + +* [撤消 Google 网络基础架构上的帷幕](http://googleresearch.blogspot.com/2015/08/pulling-back-curtain-on-googles-network.html) + +* [Google 数据中心网络内部的外观](http://googlecloudplatform.blogspot.com/2015/06/A-Look-Inside-Googles-Data-Center-Networks.html) （Google 博客文章 [在 HackerNews](https://news.ycombinator.com/item?id=9734305) 和 [在 Reddit 上](https://www.reddit.com/r/sysadmin/comments/3a7kwc/a_look_inside_googles_data_center_networks/) ） + +* [木星崛起：Google 数据中心网络中 Clos 拓扑和集中控制的十年](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf) （Google 论文，2015 年） + +* [服务提供商网络的 SDN 堆栈](https://www.youtube.com/watch?v=ED51Ts4o3os) （Google 视频，2012 年）。 + +* [Show 222-介绍 OpenClos 项目](http://packetpushers.net/show-222-introducing-openclos-project/) （来自 Packet Pushers 的网络实体） + +* [Google 向其最高机密的数据中心敞开大门](http://www.wired.com/2012/10/ff-inside-google-data-center/) （有线，2012 年） + +* [不断变化的体系结构：新的数据中心网络将使您的代码和数据自由自如](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) （来自 HighScalability） + +* [VL2：可扩展且灵活的数据中心网络](http://research.microsoft.com/apps/pubs/default.aspx?id=80693) （微软提供的文件） + +* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) （来自 HighScalability） + +* [介绍数据中心结构，下一代 Facebook 数据中心网络](https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network) + +* [云系统管理的实践：设计和操作大型分布式系统](http://the-cloud-book.com/) （看起来像一本好书） + +* [十年来 Google 自家的数据中心网络](http://www.theplatform.net/2015/06/19/inside-a-decade-of-google-homegrown-datacenter-networks/) + +* [技术要点 012：Google 的集群管理](http://jturgasen.github.io/2014/10/26/tech-takeaway-012-cluster-management-at-google/) + +* [评估仓库规模计算中的工作包装](http://www.e-wilkes.com/john/papers/2014-IEEECluster-job-packing.pdf) + +* [万亿级计算-事实还是虚构？](http://www.ipdps.org/ipdps2013/SBorkar_IPDPS_May_2013.pdf) + +* [使数据中心的高效率和低延迟实现协调](http://web.stanford.edu/~davidlo/resources/2015.thesis.pdf) + +* [ONS 2015：星期三主题演讲-Mark Russinovich](https://www.youtube.com/watch?v=RffHFIhg5Sc) -微软在网络领域的发展。 + +这是对现代 Web 规模数据中心网络的很好描述。 Clos 面料又是新的了。 + +除了谷歌，其他大公司也在做类似的事情。 例如，Microsoft 正在将 BGP 与 SDN 控制器一起使用。 + +至少可以说，这是进入数据中心工程的激动人心的时刻！ + +去年在英特尔开发人员论坛（IDF 2014）上宣布了“ Fabrics 上的 NVMe”协议。 它应该标准化对低延迟 NVM 设备的远程访问。 + +在您写“今天整个互联网可能接近 200Tb / s”的地方，您的意思可能是 200Pb / s，对吗？ + +一篇关于 CloS 面料的好文章。 + +Google 的体系结构可能适合搜索，但是 Google 的后端存在可靠性问题，只需浏览一下 Google Drive 论坛，所有用户报告丢失的数据即可。 + +非常有趣的细节！ + +亚历山德罗，我回去检查。 他肯定说大约在 19:26 时，Internet 的速度约为每秒 200 兆位，尽管他说很难知道确切的数字。 + +@Alessandro Alinone，那条大约 200Tb / s 的线路也把我甩了！ + +非常好的描述。 \ No newline at end of file diff --git a/docs/172.md b/docs/172.md index 5e788bb..65c338f 100644 --- a/docs/172.md +++ b/docs/172.md @@ -1,129 +1,67 @@ -# 策略：在 S3 或 GitHub 上运行可扩展，可用且廉价的静态站点 +# Autodesk 如何在 Mesos 上实施可扩展事件 -> 原文： [http://highscalability.com/blog/2011/8/22/strategy-run-a-scalable-available-and-cheap-static-site-on-s.html](http://highscalability.com/blog/2011/8/22/strategy-run-a-scalable-available-and-cheap-static-site-on-s.html) +> 原文： [http://highscalability.com/blog/2015/8/17/how-autodesk-implemented-scalable-eventing-over-mesos.html](http://highscalability.com/blog/2015/8/17/how-autodesk-implemented-scalable-eventing-over-mesos.html) -我曾经从事过的最好的项目之一是创建一个几乎完全静态的大规模网站发布系统。 一支由非常有才华的创意团队组成的庞大团队进行了艺术创作，作者撰写了内容，设计师生成了模板。 所有资产均由数据库控制。 然后，在应用了许多不同的过滤器之后，所有内容都被提取到了一个静态站点，该站点通过 ftp 上传到了数十个 Web 服务器。 效果很好。 可靠，快速，便宜且简单。 更新有些麻烦，因为它需要将大量文件推送到许多服务器，这需要时间，但要有一个可靠的系统。 +![](img/8984f7f1f052261aa848f938774e4d89.png) -A，这个优雅的系统被替换为一个新的基于动态数据库的动态系统。 内容是使用动态语言生成的前端从数据库中提取的。 借助 Amazon 的沃纳·沃格斯（Werner Vogels）的最新系列文章，记载了他利用 S3 的网页服务能力将他的 [All Things Distributed](http://www.allthingsdistributed.com/) 博客转换为静态站点的经验，我很高兴 问：我们又回到静态网站了吗？ +*这是 [Autodesk](http://www.autodesk.com/) Cloud 的软件架构师 [Olivier Paugam](https://www.linkedin.com/pub/olivier-paugam/2/214/475) 的来宾帖子。 我真的很喜欢这篇文章，因为它显示了如何将基础架构（Mesos，Kafka，RabbitMQ，Akka，Splunk，Librato，EC2-）组合在一起以解决实际问题。 如今，一个小团队可以完成多少工作，真是令人惊讶。* -提出这个问题很高兴，因为在许多方面，完全静态的站点是内容繁重站点的圣杯。 静态站点是其中文件（html，图像，声音，电影等）位于文件系统中的站点，并且 Web 服务器直接将 URL 转换为文件，然后直接从文件系统读取文件并将其吐出到 浏览器通过 HTTP 请求。 **在此路径中，**不会出错。 没有太多的错误是一种美德。 这意味着您无需担心任何事情。 它将正常工作。 而且它会随着时间的推移继续工作，产生一些误点，并为繁重的站点提供服务，而静态站点则要困难得多。 +几个月前，我受命提出一个*中央事件系统*，该系统可以使我们的各种后端相互通信。 我们正在谈论活动流后端，渲染，数据转换，BIM，身份，日志报告，分析等。 而且，我们的工程团队也可以轻松地进行交互。 当然，系统的每个部分都应能够*自行扩展。* -这是 Werner 使网站静态的方式： +我显然没有时间写太多代码，而是选择 [Kafka](http://kafka.apache.org/) 作为我们的存储核心，因为它稳定，广泛使用并且可以正常工作（请注意，我并不一定要使用它，并且可以切换 到别的东西）。 现在，我当然不能直接公开它，而必须使用一些 API 对其进行前端处理。 不用多考虑，我也拒绝让后端管理偏移量的想法，因为它对例如处理故障的方式施加了太多约束。 -* S3-存储文件并为网站提供服务，创建没有服务器的网站。 S3 不是您唯一的选择，但对他而言显然是一个选择。 我们还将讨论更多有关使用 Github 和 Google App Engine 的信息。 -* [Disqus](http://disqus.com/) -以获得评论。 -* 必应-[网站搜索](http://www.orangetreeweb.com/articles/installing-bing-site-search.html)。 Google 希望网站搜索功能每年收费 100 美元。 我记得 Google 免费的时候... -* [DropBox](http://www.google.com/url?sa=t&source=web&cd=1&ved=0CCcQFjAA&url=http%3A%2F%2Fwww.dropbox.com%2F&ei=CfBRTvHINLDUiALTrdiHAQ&usg=AFQjCNGLRmWLy_c8ebbz09BgsukcLpmnwQ&sig2=m9cVWrbTNKXcHuxN6HRXoQ) -用于将网站文件同步到他所在的任何计算机上，以便可以在本地对其进行编辑。 然后，在文件上运行静态站点生成器。 然后将文件复制到 S3，这使它们可以使用 S3 在 Internet 上使用。 -* [Jekyll](http://jekyllrb.com/) -静态网站生成器。 用 Ruby 编写，并使用 [YAML](http://yaml.org/) 进行元数据管理，并使用 [Liquid 模板引擎](http://www.liquidmarkup.org/)处理内容。 -* [s3cmd](http://s3tools.org/s3tools) -将文件推送到 S3。 -* [http://wwwizer.com](http://wwwizer.com) -免费服务，可满足 S3 要求您的网站在域名中包含 www 的要求。 该服务会将一个裸域名重定向到 www.domain，因此一切正常。 [Joseph Barillari](http://jbarillari.blogspot.com/2011/02/why-you-cant-run-your-website-from.html) 对此问题进行了很好的讨论。 +那我最终得到了什么？ 分为两个单独的层：**首先是处理传入流量的 API 层，然后是托管与 Kafka（例如，实现生产者&消费者）交谈的长期的有状态流处理程序**的后端层。 这两层都可以独立扩展，只需要在它们之间进行一致的路由即可确保客户端继续与同一个后端流处理进行对话。 -描述他的旅程的文章包括： [AWS 的新功能：从 Amazon S3](http://www.allthingsdistributed.com/2011/02/website_amazon_s3.html) 运行您的网站，[最后免费-在 Amazon S3](http://www.allthingsdistributed.com/2011/02/weblog_in_amazon_s3.html) 中运行的完全自我维持的博客，以及[否 服务器必需-Jekyll & Amazon S3](http://www.allthingsdistributed.com/2011/08/Jekyll-amazon-s3.html) 。 +这些层在 **Scala** 中实现了 100％，并使用[播放！ 框架](https://www.playframework.com/)。 他们也严重依赖 **Akka actor 系统**（每个节点通常运行数百个 actor）。 后端层实现了一组自定义的 Kafka 生产者&使用者，并使用一组专用的参与者来管理预读&写缓冲区。 一切都实现为嵌套的有限状态机（我喜欢这个概念）。 分析会转到 **Splunk** ，而指标会转到 **Librato** （*收集的*在容器中运行）。 -对我来说，使用 DropBox 是一个聪明的地方。 DropBox 可以使文件跟随您，因此您可以在任何计算机上对其进行编辑。 这也是该方法的缺点。 您需要具有完整工具集的本地计算机，这很麻烦。 具有讽刺意味的是，这就是为什么我更喜欢基于云的方法。 我想从任何支持 Web 的设备（例如 iPhone 或 iPad）上运行博客，我不想弄乱程序。 +[![1-4](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01bb08323d7f970d-800wi "1-4") ](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01bb08323d7f970d-pi) *发布外观的艺术渲染。* -静态站点是**可伸缩**站点。 Web 服务器或 OS 可以轻松地将受欢迎的页面缓存在内存中，并像肯塔基州德比的薄荷糖一样为它们提供服务。 如果单个服务器不堪重负，则可以轻松地从 CDN 中为静态站点提供服务，也可以将其复制到负载平衡的配置中。 因此，静态站点是**快速**。 如果您在下面使用分布式文件系统，那么甚至可以避免磁盘缓慢成为热点的问题。 +那么，如何在两层之间路由？ 只需使用 [RabbitMQ](https://www.rabbitmq.com/) ，它非常耐用&有弹性，就不好笑了。 AMQP 队列是实现此简单“电话切换”模式的好方法。 通过使用将一组固定的后端节点与一个 RabbitMQ 代理相关联的逻辑分片（例如，对每个事务中存在的某些 Cookie 进行哈希处理或类似操作）来进行扩展也是很简单的。 -您可以使用**最喜欢的文本编辑器**编辑内容。 Nice 和**简单**。 +为什么我不对 RabbitMQ 经纪人进行集群？ 好吧，主要是因为我很懒，也因为这并不是必须的。 **在我看来，分摊单个经纪人**中的流量实际上同样有效，而且更易于控制。 与收益相比，要做的额外工作微不足道。 -文件系统倾向于**可靠**。 使用 S3 更可靠，**也便宜。 如果出现故障，您可以使用一个简单的命令重新发布或还原您的站点。 数据库往往会增加内存容量，填满表，查询速度慢以及其他许多烦人的故障模式。 在静态站点中可以跳过的所有操作。 超越简单文件服务的 Web 服务器也可以发挥作用。** +简而言之，给定一些容器拓扑，我们的请求将遵循特定的路径，具体取决于哪个后端节点承载了什么流会话。 **扩展整个过程就像给定您需要的**独立地扩展每个层一样简单。 唯一实际的限制将来自您的虚拟网络适配器以及可以通过多少带宽。 -静态站点的问题在于它们是静态的。 一旦互联网完全静止，当然还有眨眼标记和动画 gif。 然后，CGI 改变了这一切，此后网络从未停滞不前。 +[![1-3](img/e486bfe35f21fad9f18358c59608a8ec.png "1-3") ](http://a6.typepad.com/6a01b7c766c713970b01bb083239de970d-pi) *虚线显​​示了来自给定会话的路径请求将遵循的路径。* -因此，我们要做的是将**所有**动态位外包给服务，并使内容保持静态。 评论可以由 Disqus 之类的服务处理。 搜索可以由 Bing 处理。 广告投放已经是一项服务。 就像按钮一样，都是无用的 javascript 代码。 并且，将**安全性**的担忧（黑客，SQL 注入等）最小化。 这是混搭文化。 +现在来了有趣的部分：**我们如何保证可靠的流量并避免拜占庭式故障？** Mucho 说的很简单，只需采用简单的两阶段提交式协议，并将客户端和后端建模为镜像状态机（例如，它们始终保持同步）。 这可以通过具有需要显式确认请求的读写操作来实现。 您尝试阅读某些内容，如果失败了，您可以重试，直到您可以放置​​确认，然后更改后端（例如，向前移动 Kafka 偏移量或安排要发布的事件块）为止。 所以我的客户和后端之间的流量实际上就像是“分配会话”，“读取”，“ ack”，“读取”，“ ack” ...“ dispose”。 -而且大多数情况下都有效。 当我不得不将 HighScalability 移出共享托管时，我认真考虑了这种方法。 +这种系统的巨大优势在于，**可以有效地使操作成为幂等，**加上**可以在状态机**中对所有逻辑进行编码，而无需任何烦人的声明性语句（ *对我自己：我应该提供一个纯粹的功能实现，以保持冷静*。 当然，任何网络故障都将适当地重试。 顺便说一下，您还可以获得自由的控制流和背压。 -缺点： +因此，整个事情都以 [Apache Thrift](https://thrift.apache.org/) API 的形式公开（目前已通过 HTTPS 进行了压缩，并且计划将其迁移到纯 TCP）。 我拥有 Python，Scala，.NET 和 Ruby 的客户端 SDK，以配合我们在 Autodesk 使用的各种令人眼花 variety 乱的技术。 请注意，Kafka 偏移量由客户端管理（尽管不透明），这使后端更易于控制。 -* .htaccess 不能做很多事情。 如果您有很多安全检查和 URL 映射魔术，那么您无法使用 S3 做到这一点。 -* 没有 PHP 或任何其他语言使用 Web 服务器调用的语言引起的动态性。 您当然可以完全自由地创建服务并将其混入您的站点。 Google App Engine 仍然是此类迷你服务层的绝佳平台。 +等一下 **如何处理后端节点发生故障的情况？** 多亏了两阶段协议，我们在读取数据时并没有真正遇到问题：客户端反复出现故障，然后使用其当前偏移量重新分配新的流会话。 向 Kafka 写入数据时会担心，因为这是异步的，并且可能会受到下游背压的影响（例如，您的节点发生故障，Kafka 代理也有问题。.urg）。 我为后端节点配备了正常关机功能，它将在等待任何挂起的写操作通过时快速使任何传入请求失败。 最后，我们甚至可以将所有待处理的数据刷新到磁盘（并在以后重新注入）。 -对我来说最大的缺点是： +再说一遍。 **如果部分基础架构爆炸了怎么办？** 。 您与处理您的流会话的实际后端节点之间的任何流量中断都将使您放慢速度，但当然不会受到任何讨厌的影响，这要归功于两阶段协议。 -* **不是多用户**。 这种限制影响了网站的各个方面。 我希望多个人能够向 HighScalability 添加内容。 我想给用户特殊的特权。 我想分配角色。 我想控制某些用户可以看到的内容。 SquareSpace 与其他内容管理系统一样具有此功能。 静态站点生成器生成的站点不具备这些功能。 -* **加入**。 这些工具可让用户与您的网站互动，因此希望他们能坚持更长的时间。 诸如历史上最热门的帖子，文章的阅读次数，最新的帖子列表，标签云等功能。 使用静态生成器更难做到这些。 -* **获利者**。 这些功能可以帮助您赚钱。 它们通常包括参与者，但可以包括诸如电子邮件列表注册，相关内容推荐，白皮书匹配，注册咨询服务，赞助商文本链接等功能。 难以在静态系统上实现。 一个显而易见的解决方案是拥有一个通用的 CMS 元数据服务，所有混搭服务都可以使用该服务，但是这种服务可能不会实现。 +哦，我忘记添加了**数据，该数据在登陆 Kafka 日志之前会自动加密**（AES 256）。 没有更多的 la 脚的密钥共享尝试使用香草卡夫卡的生产者和消费者进行相同的操作。 在安全性主题上，我可以添加我们的流会话通过 OAUTH2 进行身份验证，使用按请求的 MD5-HMAC 质询并通过 TLS 向下访问后端群集。 -对于构建静态网站，S3 并非唯一的游戏。 Github 也可以用来托管静态网站。 可以通过简单的 git push 生成和更新博客。 这样可以将所需的已安装程序集减少到更易于管理的级别。 现在您甚至不需要 git。 您可以使用文件的网络界面直接编辑文件。 它的工作方式是 Github 每次将更改推送到存储库时都会自动构建您的网站。 此处有更多详细信息： [GitHub Pages](http://pages.github.com/) ，[发布带有 GitHub Pages 和 Jekyll](http://blog.envylabs.com/2009/08/publishing-a-blog-with-github-pages-and-jekyll/) 和 [Github 作为 CDN](http://code.lancepollard.com/posts/github-as-a-cdn/) 的博客。 +那么，您现在要问的是如何部署所有这些时髦的系统？ 好吧，我们在普通的 [Mesos / Marathon](https://github.com/mesosphere/marathon) 集群（目前不是 [DCOS](https://mesosphere.com/) ）上 100％运行它，但我们可以切换到它，并从它们令人敬畏的仪表板中受益。 此时，群集是**托管在 AWS EC2** 上的，我们基本上将整个事物复用到了少数 c3.2xlarge 实例上（对于给定区域的小型部署，10 至 20 个实例就足够了）。 请注意，我们可以在 [Kubernetes](http://kubernetes.io/) （EC2 或 GCE）上执行完全相同的操作。 -Google App Engine 还是静态网站的替代方案。 更多详细信息，请访问： [DryDrop，使用 GAE 和 Github](http://openalexandria.com/2010/08/drydrop-manage-static-web-site-with-gae-and-github/) 管理静态网站。 +[![Stack](img/c29061f835160adb9b54403c955c07d9.png "Stack")](http://a4.typepad.com/6a01b7c766c713970b01b7c78e36d4970b-pi) -现在有些推动将博客移至**社交网络**网站，例如 Google+。 优点是您拥有一个内置的机制来吸引更多的读者，强大的讨论功能，增加参与的可能性，无需花费，设备可用性出色且无需维护。 对于不需要获利的博客，这是一个很好的选择。 尽管我确实担心当您想跳到下一个流行的社交网络时发生的情况，而所有旧内容仅仅是灰尘。 +*有点提醒我们堆栈的结构。* -包起来： +一切都使用我们的 [Ochopod](https://github.com/autodesk-cloud/ochopod) 技术（自集群容器）进行了部署，该技术也采用开源的方式。 操作减少到绝对最小值。 例如，例如，对 API 层进行适当的构建推送，只需分配一些新容器，等待它们安顿下来然后逐步淘汰旧容器即可。 所有这些都是通过在集群中运行的专用 Jenkins 从属服务器（本身也是 Ochopod 容器）完成的！ -* 如果您的博客严格讲内容，那么静态网站方法是可伸缩，快速，廉价，灵活和可靠的。 我们现在拥有丰富的工具集，可以使静态网站成为现实。 -* 如果您的博客不在网上，那么请把时间花在社交网络（包括 StackExchage，Quora 等）上而不是博客上。 -* 如果要提高用户参与度或通过其他方式创造性地通过博客获利，则 CMS 是更好的选择。 -* 如果您想在博客上拥有多个用户和内容创建者，那么 CMS 是一个更好的选择。 +我实际上开发了 [Ochothon](https://github.com/autodesk-cloud/ochothon) mini-PaaS，只是为了能够快速开发/运行所有这些容器。 -因此，有关创建静态网站的更多链接： +[![Screen Shot 2015-05-21 at 9.00.31 AM](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01b8d117b6df970c-800wi "Screen Shot 2015-05-21 at 9.00.31 AM")](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01b8d117b6df970c-pi) -* [由 Jean-Michel Lacroix 在 CloudFront](http://jmlacroix.com/archives/cloudfront-hosting.html) 上托管静态网站 -* [在 Jean-Michel Lacroix 上在 CloudFront](http://jmlacroix.com/archives/cloudfront-publishing.html) 上发布静态网站 -* [ponyHost-已死的简单 s3 网站](http://ponyho.st/) -* [Hyde](http://ringce.com/hyde) -Hyde 是由 Python 支持的静态网站生成器& Django -* [Nanoc](http://nanoc.stoneship.org/) -是一种 Ruby 网络发布系统，可在您的本地计算机上运行，​​并将以 Markdown，Textile，Haml 等格式编写的文档编译到由简单 HTML 文件组成的静态网站中，随时可以上传到任何网站 网络服务器。 -* [博客工具](http://joshua.schachter.org/2009/12/blogging-tools.html)，作者：joshua schachter -* [仙人掌](https://github.com/koenbok/Cactus)-静态网站生成器。 -* [jekyll vs. hyde-两个静态网站生成器的比较](http://www.reddit.com/r/programming/comments/hcxvc/jekyll_vs_hyde_a_comparison_of_two_static_site/) -* [jekyll-s3]( https://github.com/versapay/jekyll-s3) -将您的 Jekyll 博客推送到 Amazon S3！ +*Ochothon CLI 显示了我的预生产集群之一。* -嗨，托德，很高兴写出来。 我绝对同意你提到的缺点。 对我来说，这确实是一种锻炼，它使我可以做无服务器工作。 并了解我们可以在 AWS 方面做得更好。 +为了让您了解 Ocho- *平台的全部功能，我只想说**，一个人（我）可以管理 2 个区域（包括所有复制基础设施**）的 5 个系统部署 ……还有时间写博客和编写代码！ -具有静态插件生成器 Jekyll 或 Cactus 的功能完备的多用户 CMS 和 Wordpress 等丰富的插件生态系统仅领先几年。 但是自从我上一篇文章发表以来，人们一直在向我发送其他静态生成器的参考，并且工具的发展也多种多样。 毫无疑问，Jekyll 确实是“像黑客一样博客”，因此具有您所期望的所有粗糙边缘。 例如，一个拥有很多帖子（例如您的帖子）的网站将需要进行认真的组织以使其在 Jekyll 中易于管理。 +因此，总体而言，设计和编码整个过程非常有趣，而且它现在已经在生产中运行，成为我们云基础架构的关键任务部分（这是一个不错的奖励）。 让我们知道，如果您想了解更多有关此异国流媒体系统的信息！ -我确实喜欢这种设置的分散性。 我可以从任何地方写信并更新网站。 鉴于我是唯一的作家，所以自然缺乏并发:-)但是能够在您可能没有本地安装 jekyll 的地方写文章也是我当然也想做的事情。 我喜欢 Ted Kulp 在[《自动化 Jekyll 构建](http://tedkulp.com/2011/05/22/automating-jekyll-builds/)》中所做的工作，他基本上在服务器上有一个进程在监视保管箱文件夹。 当他在其中发布帖子时，网站将重新生成并推送到 S3。 它仍然需要在某个地方的服务器，但是我很确定我可以将其外包给 Heroku，而不必自己运行某些东西。 我只是很开心地看到我可以把它推多远... +## 相关文章 -这就是我对您的文章 Werner 所喜欢的，显然，您可以从整体上解决问题。 一起骑很有趣！ +* [在 Mesos / Marathon 上部署我们的事件基础架构& Ochothon！](http://cloudengineering.autodesk.com/blog/2015/05/after-a-long-day-of-devops-to-inaugurate-the-latest-ochothon-release-i-though-id-share-quick-what-it-feels-like-deploying-ou.html) +* [Ochopod + Kubernetes = Ochonetes](http://cloudengineering.autodesk.com/blog/2015/05/ochopod_plus_kubernetes.html) +* [有限状态机的返回！](http://cloudengineering.autodesk.com/blog/2015/07/fsm.html) -我做了一点测试，浏览了浏览器历史记录的最后一周，并尝试进行反向工程，以通过静态生成器（比 Werner 的更高级的生成器，可以用我的想象力）来提供多少内容，一旦获得 过去搜索引擎的搜索结果，并排除了我的个人网站（电子邮件，Twitter，Facebook 等），基本上所有页面都可以设置（我编造了这个词，需要简短说明）。 +纸上写的很好，但他们的服务影响了现实生活。 看一下 123D Catch，大多数时候您无法将任何数据上传到云中。 -在规模化或系统简化的对话中，几乎从未提及过标准化。 一旦对网站进行了注册，则在提供服务的方式上就根本不同：将 PHP-mysql 堆栈提供的页面与 S3 存储桶或 Akamai 边缘服务器提供的页面进行比较，大约等于 1。 系统资源方面的差异为 10K FOLD（如今，可以通过单核完成 c10K）。 +我有一个基本问题。 您为什么选择使用 RabbitMQ 与 2 层进行黑白通信？ 这与使用 Kafka 进行交流有何不同？ 从理论上讲，Coz 甚至支持在散列上进行分区，并且也很耐用。 -身份认证可以应用于很多网页（不仅是博客），但是 AFAIK 并没有很好的食谱（任何人都知道吗？），并且它似乎并不是大多数开发人员常用的工具（或者也许是 只是不够性感而无法获得大量媒体报道）。 - -就我个人而言，我非常乐于将任何和所有功能（出于某种原因）推到尽可能远地远离后端（即数据库）和尽可能远地进入前端（即浏览器）的位置，这是扩展和尊重数据的关键 本地化，因此感谢你们俩提醒人们使用此技术：多动脑筋意味着多用户 CMS 静态生成器就近了，所以我可以更快地得到我的网页：）。 - -Bing 网站搜索小部件已于 2011 年 2 月撤消。 - -http://www.bing.com/community/site_blogs/b/webmaster/archive/2011/04/19/bing-com-siteowner-shut-down-options-for-search-results.aspx - -关于允许用户向 HighScalability 添加/编辑内容的方式：如果将静态站点文件保存在{git，hg，bzr}存储库中，则可以允许用户克隆本地存储库，进行更改然后推送 它们返回给您，您可以在此处查看并推送到 S3。 这样做甚至可能会为您的 Dropbox 节省一些空间，因为您可以在 Dropbox 上保留一个裸{git，hg，bzr}仓库，然后将其推送并拉到本地计算机上。 我对很多代码都这样做，而且即使我没有互联网连接（因此无法推送到 github），我也很喜欢，我可以做一个`git push dropbox master`并知道下一次我 连接后，我的存储库将备份到我的 Dropbox。 - -关于@Jonathon Prior 的声明，我前不久在 HN 上看到了这一点：http://jeffkreeftmeijer.com/2011/introducing-tapir-simple-search-for-static-sites/ - -保罗，那是硬核，但很有趣。 我的第一个念头是那种方法会使人吓跑，但也许不会。 我没有得到我想要的贡献，也许 git 方法会更有吸引力？ - -乔纳森，谢谢你。 当我可以在 Bing 的网站上找到搜索时，我以为是我。 ir 看起来很有趣。 - -在我看来，最好的方法仍然是在需要时静态使用 AJAX。 IOW，以静态方式提供 html / css / javascript 文件，然后让 javascript 为您创建“动态”页面。 由于客户端计算机正在执行 GUI 处理工作，而不是服务器，因此这有助于扩展。 - -当然，仍然需要“动态” REST 端点等。这种分离对于轻松开发基于同一数据源的多个用户界面也非常有用。 - -我猜这完全符合您提到的“混搭”文化。 :) - -这是一篇很棒的文章，强调了主要提供静态内容的优势。 现实情况是，大多数站点只能以最少的动态内容获得成功，而且很多站点实际上还是静态的。 使用 Bricolage 在 www.groupcomplete.com 上发布我们的网站已经取得了巨大的成功。 Bricolage 并不是新手或花哨的东西，但是在将内容与模板分离，将最终结果内容推送到我们的服务器方面做得非常出色，确实消除了担心动态 CMS 是否崩溃或遭受最新安全漏洞的麻烦。 。 - -“ ... Web 服务器或 OS 可以轻松地将流行的页面缓存在内存中，并像肯塔基州德比的薄荷糖一样为它们提供服务...” - -那接近文学。 做得好。 - -有趣的是，大型企业维护的大多数公司网站都依赖这种方法，而大多数企业级 CMS 实际上是“离线”的。 在 IT 运营和安全性方面，这种方法有很多好处。 但是，主要原因是这些 CMS 具有早期 Web 时代的传统，而动态网站是异国情调的。 这样事情就转了一圈了。 - -您是否可以在某个地方使用私人 CMS 来编辑和维护页面文本（必须通过 Jekyll 或所需的任何生成器来维护授予的 CSS）-这样，如果您在 CMS 中编辑了页面，则可以通过以下方式轻松地更新静态网站： 只是从数据库中实时再生？ - -这可能允许 wordpress 安装在您的桌面安装上变为私有-然后将 static 推送到 S3。 两全其美-在 CMS 中易于使用的编辑-快速的网站服务以及消除了互联网使用的数据库调用？ - -准系统 CMS 是生成 CMS 的静态文件。 内置缓存足以满足大多数用途，但是如果您将 nginx 之类的服务器放在前面，并使用一些特殊规则查找缓存文件，则只需提供直接生成的缓存内容，从而完全绕过 PHP。 这样，除了硬件可以提供静态内容的速度有多快之外，您显然对系统性能没有任何限制。 它尚未完全可以用作博客，但将 Barebones CMS 变成一个似乎并不困难。 - -高可扩展性！ 同类中最好的。 - -进入静态站点-博客引擎 MovableType 支持静态发布-http://www.movabletype.org/documentation/administrator/publishing/static-and-dynamic-publishing.html 用于高流量博客。 如果我们通过 javascript 处理动态内容，则静态发布会非常有用。 - -谢谢 - -甚至以慢而着称的 CMS 都会吃掉几乎所有可能的早餐负载，除非您在体系结构上不满意，例如，将 Apache KeepAlive 保留下来。 - -我想看一个像 jekyll 这样的博客生成器，但是像 frontpage 这样的 gui（显然，生成更好的代码） \ No newline at end of file +同样，在使用 kafka 的情况下，更多的是流处理的情况。 请指教.. \ No newline at end of file diff --git a/docs/173.md b/docs/173.md index fd68762..b1281e4 100644 --- a/docs/173.md +++ b/docs/173.md @@ -1,92 +1,79 @@ -# 论文：Akamai 网络-70 个国家/地区的 61,000 台服务器，1,000 个网络 +# 构建全球分布式，关键任务应用程序：Trenches 部分的经验教训 1 -> 原文： [http://highscalability.com/blog/2011/8/18/paper-the-akamai-network-61000-servers-1000-networks-70-coun.html](http://highscalability.com/blog/2011/8/18/paper-the-akamai-network-61000-servers-1000-networks-70-coun.html) +> 原文： [http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html) -[**更新**](http://news.ycombinator.com/item?id=2900460) ：*截至 2011 年第二季度末， [Akamai 在全球范围内部署了 95,811 台](http://www.quora.com/How-many-servers-does-Akamai-have/answer/Ramakanth-Dorai?__snids__=24359589#comment509067)服务器。* +![](img/0ba113465fbde4f3efaadcbbdac4299c.png) -Akamai 是星星的 CDN。 它声称可以提供所有 Web 流量的 15％到 30％，其主要客户是 Facebook，Twitter，Apple 和美国军方。 从传统上讲，这是非常秘密的事情，我们在本文的后面会窥视一下： [Akamai 网络：高性能互联网应用程序平台](http://www.akamai.com/dl/technical_publications/network_overview_osr.pdf)，作者是 Erik Nygren，Ramesh Sitaraman 和 Jennifer Sun. +*这是 [Kris Beevers](https://www.linkedin.com/pub/kris-beevers/4/a5/113) 的创始人和首席执行官， [NSONE](https://nsone.net/) 的来宾帖子的第 1 部分，下一代智能 DNS 和流量管理平台的提供者。 这是[第 2 部分](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html)。* -Abstract: +每家科技公司都考虑到这一点：随着业务的增长，扩展其应用程序和系统是不可避免的（实际上是令人羡慕的）挑战。 **您如何从一开始就考虑扩展规模，并在不进行过早优化的情况下使公司处于良好的地位？** 在以后咬你之前，有哪些值得考虑的关键挑战？ 当您构建关键任务技术时，这些是基本问题。 在构建分布式基础架构时，无论是可靠性还是性能，或者两者兼而有之，它们都是很难回答的问题。 -> Akamai 平台由遍布全球 70 个国家/地区的近 1,000 个网络的 61,000 多台服务器组成，每天提供数千亿次 Internet 交互，帮助数千家企业提高其 Internet 应用程序的性能和可靠性。 在本文中，我们概述了该大型分布式计算平台的组件和功能，并提供了对其架构，设计原理，操作和管理的一些见解。 +部署正确的体系结构和流程将使您的系统和公司能够抵御分布式，高流量应用面临的常见问题。 这使您能够超越扩展限制，管理不可避免的网络和系统故障，保持冷静并实时调试生产问题，并成功地发展公司和产品。 -通过 Internet 交付应用程序有点像生活在荒野西部，存在一些问题：对等点拥塞，低效的通信协议，低效的路由协议，不可靠的网络，可伸缩性，应用程序局限性以及变更采用的速度缓慢。 CDN 是 White Hat 试图为企业客户消除这些障碍的工具。 他们通过创建作为现有 Internet 上的虚拟网络的交付网络来实现此目的。 本文继续说明了它们如何使用边缘网络和复杂的软件基础架构来实现这一目标。 凭借如此强大的基础平台，Akamai 显然具有类似于 Google 的能力，能够提供其他人望尘莫及的产品。 +## 这是谁？ -详细而清楚地写着，值得一读。 +我长期以来一直在构建遍布全球的大型应用程序。 在第一次互联网泡沫时期，我坚持了一年的大学课程，并为一个文件共享创业公司建立了后端基础架构，该公司成长为数百万用户-直到 RIAA 的律师们大吃一惊并将我们打包回到宿舍 。 公司倒闭了，但我却迷上了规模。 -## 相关文章 +最近，在 Internap 于 2011 年收购的互联网基础架构提供商 Voxel 上，我建立了许多大型 Web 公司使用的全球互联网基础架构–我们建立了全球分布式公共云，裸机即服务，内容交付 网络等等。 我们学到了很多扩展课程，并且很难学到它们。 + +现在，我们在 NSONE 上建立了下一代智能 DNS 和流量管理平台，该平台今天为 Internet 上一些最大的属性提供服务，其中包括许多本身就是关键任务服务提供商的公司。 这是真正分布在全球的关键任务基础架构，在我们构建和扩展 NSONE 平台时，我们在 Voxel 上学到的经验为我们提供了很好的服务-并一次又一次得到了加强。 + +现在该分享一些我们所学的知识，并且很幸运，也许您可​​以在自己的应用程序中应用这些课程中的一些–而不是艰难地学习它们！ + +## 架构优先 + +编写代码时，总是很想集中精力使其变得紧凑和高效，最大限度地减少内存和 CPU 消耗，最大程度地提高软件的“深度”。 停下来。 + +在现代的，分布广泛的系统中，扩展限制几乎不受系统的垂直“深度”和特定角色内的代码优化（尤其是早期）的驱动。 相反，它们是管理交互系统之间的通信以及体系结构中每个角色的水平可伸缩性。 **不要优化您的代码，请优化您的架构。** -* [Akamai 技术出版物](http://www.akamai.com/html/perspectives/techpubs.html) -* [扩展 Akamai 网络](http://www.akamai.com/dl/technical_publications/query_osr.pdf)的监视基础结构 -* [当 Akamai 发生故障时，它会带上互联网](http://gigaom.com/broadband/akamai-dns-issue/)，作者：赖安·劳勒（Ryan Lawler） -* [Akamai 技术回顾](http://www.technologyreview.com/tr50/akamai/)简介 -* [Akamai 的算法](http://www.technologyreview.com/web/12183/) -* 关于 CDN 结帐 [StreamingMediaBlog](http://blog.streamingmedia.com/) 的全部内容，作者 Dan Rayburn -* [Akamai 内部以及流媒体视频](http://gigaom.com/video/inside-akamai-and-the-scary-future-of-streaming-video/)的可怕未来，作者：Stacey Higginbotham -* [Microsoft 研究论文测量了 Limelight 和 Akamai 的网络性能](http://blog.streamingmedia.com/the_business_of_online_vi/2008/10/microsoft-resea.html)，作者 Dan Rayburn -* [Akamai：约 380 万条同时进行的奥巴马广播，详细介绍了客户的限制](http://blog.streamingmedia.com/the_business_of_online_vi/2009/01/akamai-and-numbers.html)，作者丹·雷本（Dan Rayburn） +[微服务](https://en.wikipedia.org/wiki/Microservices) 是个好主意。 它们使应用程序中的独立角色脱钩，并使您能够独立扩展每个角色或层。 **在担心深度之前，计划水平扩展角色。 服务器既便宜又便宜，而且总是越来越便宜。 开发人员时间不是。** 因此，您可以随时进行水平缩放，而仅在找到真正重要的地方时才担心代码优化。 -高峰还是偷看？ ;） +在编写一行代码之前，请花时间考虑一下您的体系结构。 绘制图表，考虑通信和数据约束，并制定计划。 -迈克尔的嘘声:-)谢谢，修正了。 +## 从角色上考虑您的系统 -从丹·斯威尼（Dan Sweeney）： +微服务架构或多或少意味着您正在构建一个由解耦系统组成的应用程序，每个系统都解决一个特定的问题或扮演特定的角色。 但是值得重复的是，您应该以这种方式考虑您的体系结构。 b 不仅因为它**消除了扩展约束，还因为它影响了您开发代码，部署系统和扩展基础结构的方式**。 -不错的论文，但是..大多数 CDN 提供程序设置中都有主要缺点。 +由相互分离，相互通信的角色组成的应用程序可以作为进程，VM 或容器并置放置在单个服务器上。 这使您可以在本地开发环境，小型登台系统和大型生产基础架构中部署应用程序。 -CDN 根据来自使用者 DNS 服务器的 DNS 请求来确定将您定向到哪个缓存站点。 在东南亚，ISP 的 DNS 通常做得不好，因此很大一部分消费者将 Google 或 OpenDNS 用作其 DNS 服务器。 使用 Google 或 OpenDNS 的消费者的最终结果是 CDN 不会将他们引导至最佳性能缓存服务器..而是他们的算法“认为”是最好的。 存取时间少于期望的结果。 +**随着应用程序生产基础架构的发展以及流量和用户的扩展，您可以剥离需要专用系统或系统集群的角色。** 。但是，在您的 MVP 中，您可以将成本降到最低，并且仍然可以通过并置生产角色来进行扩展。 我们在 NSONE 上发布的最早的 alpha 版本托管在 AWS 中的一个单播 t2.small 实例上。 如今，我们具有与开始时基本相同的角色和子系统集（此后又添加了更多的角色和子系统），我们的生产基础架构跨越全球各大洲的数百台服务器和近 30 个不同的生产设施（南极洲除外-抱歉 伙计们）。 随着我们的成长，我们将关键子系统剥离到了它们自己的服务器或群集，并在需要的地方增加了广度和冗余性。 -我提供以下示例： +## 跨全球分布式系统的通信非常困难 -天空宽带 AS23944 -DNS 服务器 114.108.192.30 -DNS 服务器 111.68.59.70 +构建和扩展由子系统组成的应用程序是一回事，这些子系统最初并置在单个服务器上，最终并置在单个数据中心中。 完全解决多数据中心应用交付难题是另一回事。 子系统需要在 LAN 外部进行通信时，该通信的可靠性将大大降低，您不仅需要针对服务器故障，而且还要针对通信故障进行周密的计划。 -结果： +Internet 上的连接脆弱且不可预测。 在 NSONE，我们设计架构的前提是我们的边缘 DNS 交付设施将经常失去与核心设施的连接。 在非洲，巴西和印度等困难的市场中，情况尤其如此。 但是我们还需要确保在恢复通信后快速重新收敛。 仔细考虑命令和控制消息传递以及消息排队是关键。 -Sky Broadband 的 DNS 服务器认为 Farmville 的 IP 是： +对于不同的通信模式，以不同的方式考虑设施间通信也很重要。 **如果要将延迟敏感的关键命令和控制消息推送到一个或多个设备，则可能需要查看功能强大的消息队列系统**（例如，我们大量使用 RabbitMQ）。 如果要将非关键遥测回运到仪表板系统，则**可能会考虑减轻重量，但对网络拆分的影响较小**。 如果您要推送需要在所有交付位置之间紧密同步的持久性应用程序数据，则值得一看。 在设施之间移动钻头时，请使用正确的工具完成正确的工作。 -203.77.188.253 -203.77.188.254 +## 一致性哈希是同步&分片的杀手 tool -这些 IP 实际上属于使用 AS22822 的名为 -LimeLight 的内容交付网络提供商。 我通过他们的香港缓存区获得了 Farmville。 +是时候考虑水平缩放了。 您有一堆子系统，它们都在本地和整个 Internet 上相互通信。 请求飞入您的系统，需要在可以有效地为它们服务的后端节点之间分配，并且您需要一种最大化“请求位置”的方法。 不能期望您所有具有特定角色的服务器都能满足任何请求，这可能是因为必需的数据不能全部存储在一个盒子中的 RAM 中，或者您需要在服务器之间有效地分条存储。 您如何确定水平层中的哪个节点应处理请求或任务？ -跟踪路由到 203.77.188.253（203.77.188.253），最大 64 跳，52 字节数据包 -1 192.168.100.1（192.168.100.1）1.974 ms 1.297 ms 1.308 ms -2 230-182.gw.skybroadband.com。 ph（182.18.230.1）10.278 ms 10.871 ms 10.952 ms -3 ge-1-4.mnd1.skybroadband.com.ph（111.68.59.141）36.232 ms 9.665 ms 11.732 ms -4 10ge0-3-0。 sj1.skybroadband.com.ph（114.108.192.137）32.987 ms 26.559 ms -10ge0-3-3.mnd1.skybroadband.com.ph（111.68.59.137）74.772 ms -5 202.78.101.1（202.78.101.1） ）37.318 毫秒 61.957 毫秒 69.786 毫秒 -6 tengige-1-0-0.gw1.rsv.bayan.net.ph（202.78.96.161）72.134 毫秒* 96.092 毫秒 -7 limelight1-10g.hkix.net（ 202.40.161.92）101.310 ms 110.001 ms 114.412 ms -8 cdn-203-77-188-253.hkg.llnw.net（203.77.188.253）100.429 ms 83.039 ms 105.583 ms +天真的，您可以预先配置请求路由：也许您有一个请求 ID，并且所有以 A-M 开头的请求 ID 都被带到一台服务器，而以 N-Z 开头到另一台服务器。 那可能行得通，但是难以管理和扩展。 您可以将请求 ID 散列到服务器：类似 hash（id）mod N ，其中 N 是要跨越的服务器数量。 在您添加新服务器并且所有请求重新进行条带化，破坏数据或缓存局部性并破坏系统之前，这种方法很有效。 您可以为分布式“协议”实施某种复杂的协商-您的各个子系统和服务器相互通信，以确定哪些请求应该发送到哪里-这是我经常看到的一种方法。 这很复杂，事情会破裂。 -更改为 OpenDNS 服务器 208.67.222.222 +[一致性哈希](https://en.wikipedia.org/wiki/Consistent_hashing) 是一种强大的方式，使分布式系统无需进行实际通信就可以达成对请求到节点的映射等协议。 它易于实施，并且可以根据您的基础架构进行适当扩展，从而最大程度地减少了在子系统中添加或删除节点时的重新分段。 在具有许多交互角色的复杂体系结构中，策略性地使用一致的哈希来跨节点集对消息和请求进行条带化可能是一个巨大的胜利。 -现在，我的机器认为 Farmville 决心解决以下问题： +在 NSONE，**我们以多种方式在整个堆栈中使用一致的哈希，例如将 DNS 查询路由到特定的 CPU 内核以最大化缓存局部性，在不进行显式通信的情况下协商监视节点的任务，跨层拆分大量数据馈送 聚合节点的数量，还有更多**。 -208.111.148.6 -208.111.148.7 +## 测量并监视所有内容 -这是到 208.111.148.6（208.111.148.6）的 LimeLight CDN AS22822 -跟踪路由，最大 64 跳，52 字节数据包 -1 192.168.100.1（192.168.100.1）1.556 ms 1.277 ms 1.232 ms -2 230- 182.gw.skybroadband.com.ph（182.18.230.1）12.541 ms 11.120 ms 11.883 ms -3 114.108.192.153（114.108.192.153）12.625 ms 11.722 ms 11.863 ms -4 114.108.192.133（114.108.192.133） 40.514 毫秒 26.772 毫秒 22.962 毫秒 -5 byt-0027.asianetcom.net（202.147.25.149）30.663 毫秒 50.844 毫秒 28.684 毫秒 -6 po14-0-2.cr1.nrt1.asianetcom.net（202.147.24.222） 80.310 毫秒 77.755 毫秒 76.977 毫秒 +这是一条很常见的建议，似乎有些陈词滥调，但它总是值得重复的。 **您没有测量的内容，您无法理解**。 即使您远未遇到严重的扩展挑战，对系统行为及其交互的深入了解对于了解随着增长将面临的扩展约束也至关重要。 -7 * po7-0-0.gw1.sjc1.asianetcom.net（202.147.0.34）186.193 毫秒 195.764 毫秒 +不只是收集系统指标。 **对您的应用程序进行检测，以了解数据库响应时间，消息传递延迟，高速缓存命中率，内存碎片，磁盘 I / O，以及可能使您洞悉系统性能的所有内容。** 绘制所有图表，并建立对“名义”行为的基本理解。 如果发生异常情况（例如负载峰值，通信故障，子系统中出现某种异常情况），请回头查看您的指标并了解事件的“特征”。 这将帮助您识别将来异常情况下正在发生的事情（同样重要的是，排除不发生的事情）。 它会帮助您了解新型工作负载或其他流量何时给系统带来了意料之外的压力，因此您可以在子系统发生故障之前适当地调整架构或扩展子系统。 -8 208.178.245.9（208.178.245.9）185.150 ms 182.295 ms 196.486 ms -9 64.214.150.94（64.214.150.94）200.577 ms 185.450 ms 196.004 ms -10 cdn-208-111-148-6.sjc.llnw .net（208.111.148.6）198.069 毫秒 209.952 毫秒 280.367 毫秒 +在 NSONE，**我们研究了指标。** 始终在显示它们（我们的办公室到处都是显示 NOC 仪表板的监视器）。 当我们看到一些突如其来的东西时，我们会问为什么，并进行更深入的挖掘。 从这种方法中获得的深刻理解意味着我们可以放心地满足 Internet 上最大客户的 DNS 和流量管理需求，因为我们知道我们的平台将如何应对新的流量和工作量。 + +**与测量同样重要的是监视**。 这是两个不同的事物：我们进行测量以了解我们系统的行为，并且进行监视以检测该行为中的异常。 在您的成长早期就进行监视和警报：它将帮助您了解重要的异常和无关紧要的异常。 您才刚刚开始，可能会错过一些睡眠。 后来，随着业务的增长，管理系统变得比马拉松跑更像一场马拉松，您将希望减少噪音，着眼于影响服务的异常情况，并对系统进行自动化和重新架构以将其最小化。 + +**从多个有利位置**进行监视-不仅在物理上（多个地理位置和网络），而且在逻辑上。 在 NSONE，我们监视内部遥测中的异常情况，利用 Catchpoint 和 Raintank 等第三方服务进行外部监视，并通常利用各种数据源来观察平台和网络事件。 + +同样重要的是，**监视的不仅仅是系统**的“正常性”。 系统提供“优质”服务意味着什么？ 低延迟响应时间？ 高缓存命中率？ 监视那些指标并在它们超出范围时发出警报。 + +*这是本文的[第 2 部分](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html)。* + +## 相关文章 -所以我是 +* [关于黑客新闻](https://news.ycombinator.com/item?id=10147420) -我回应丹·斯威尼的评论。 -使用基于 DNS 的路由非常简单，不是运行 CDN 的唯一方法。 -我的理解是 Akamai 使用 BGP（边界网关协议）路由，该路由告诉网络将对相同 IP 地址的请求定向到最近的服务器。 因此，可以根据您的 ISP 的位置将单个 IP 路由到不同的位置。 \ No newline at end of file +很棒的文章！ 我特别指出，内部遥测和外部监视之间存在差异。 这是我最近与一位近视的领导者失去的论点-他关闭了内部遥测系统以节省几分钱。 但是自那以后，我离开了那家公司，我希望从长远来看，这将使他们停机。 \ No newline at end of file diff --git a/docs/174.md b/docs/174.md index c8639e1..1d32ce7 100644 --- a/docs/174.md +++ b/docs/174.md @@ -1,91 +1,83 @@ -# 标记式架构-扩展到 1 亿用户，1000 台服务器和 50 亿个页面视图 +# 构建全球分布式，关键任务应用程序：Trenches 第 2 部分的经验教训 -> 原文： [http://highscalability.com/blog/2011/8/8/tagged-architecture-scaling-to-100-million-users-1000-server.html](http://highscalability.com/blog/2011/8/8/tagged-architecture-scaling-to-100-million-users-1000-server.html) +> 原文： [http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html) -![](img/f2480e7b24c999cf768852c3e433296f.png) +![](img/0ba113465fbde4f3efaadcbbdac4299c.png) -*这是 [Johann Schleier-Smith](http://www.crunchbase.com/person/johann-schleier-smith) 和 CTO &联合创始人 Tagged 的嘉宾帖子。* +*这是 [Kris Beevers](https://www.linkedin.com/pub/kris-beevers/4/a5/113) 的创始人和首席执行官， [NSONE](https://nsone.net/) 的来宾帖子的第二部分，下一代智能 DNS 和流量管理平台的提供者。 这是[第 1 部分](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html)。* -## 关于 Tagged 如何扩展到 1,000 台服务器的五个快照 +## 集成和功能测试至关重要 -自 2004 年以来，[标记为](http://www.tagged.com/)已从微小的社交实验发展成为最大的社交网络之一，每月向访问与新朋友见面和社交的数百万成员提供 50 亿页。 一次一步，这一演变迫使我们发展自己的体系结构，最终形成了功能强大的平台 [](http://www.stigdb.org) 。 +在每一个现代软件开发课程中，单元测试都受到重创。 这是一个好习惯。 无论您是进行测试驱动的开发，还是只是敲出代码，如果没有单元测试，您都无法确保一段代码能够达到预期的效果，除非您仔细进行测试，并确保这些测试随着代码的发展而不断通过 。 -## V1：PHP Webapp，100k 用户，15 台服务器，2004 年 +在分布式应用程序中，即使您拥有世界上最好的单元测试范围，您的系统也会崩溃。 **单元测试还不够**。 -![](img/64da066a69275d19c7b0e540ba12feb8.png) +您需要**测试子系统**之间的交互。 如果特定的配置数据发生变化，该怎么办–对子系统 A 与子系统 B 的通信有何影响？ 如果您更改了消息格式该怎么办–生成和处理这些消息的所有子系统是否继续互相通信？ 在最新代码更改之后，依赖于四个不同后端子系统的结果的特定类型的请求是否仍会导致正确的响应？ -Tagged 诞生于一个孵化器的快速原型文化中，该孵化器通常每年都会推出两个新概念来寻找大赢家。 LAMP 是这种工作方式的自然选择，当 Java 开发主要面向大型企业的开发，Python 吸引了很少的程序员并且 Perl 带来了错误的排序时，LAMP 强调了灵活性和快速的周转时间。 另外，我们知道 Yahoo 是 PHP 的大力支持者，因此有可能在需要时扩展业务。 +单元测试不能回答这些问题，而集成测试却可以。 **在集成测试套件**中投入时间和精力，并在开发和部署过程的所有阶段都建立了用于集成测试的过程。 理想情况下，始终在您的生产系统上运行集成测试。 -在以前的项目中运行 MySQL 的丰富经验使我对这项技术产生了深恶痛绝的关系。 本着实验的精神，我们为 Tagged 购买了一些入门级 Oracle 许可证，以了解这样做是否更好。 +## 没有服务中断维护 -值得注意的是，仍然建立了许多较小的网站，就像原始的“已标记”一样。 简单有其美，无状态 PHP 和有状态 Oracle 之间的双向划分将最棘手的部分集中在单个服务器中，同时易于添加额外的页面呈现计算能力。 +如果您要构建一个真正的关键任务应用程序，那么您的客户将依靠它来经营自己的业务，那么就没有关闭开关了。 它永远不会停止工作。 您永远不会有服务中断维护。 **即使最复杂的后端体系结构更改也必须毫不夸张地进行**。 -## V2：缓存的 PHP **w** **ebapp，1 百万用户，20 台服务器，2005** +这是您应该**认真思考架构**的原因之一。 数小时的白板可以节省数月的工作量。 -![](img/d9df48fa85ed38b2c8a1905bf77a6d6c.png) +一个例子：在 NSONE，我们很幸运地从一开始就掌握了大部分架构。 **一开始我们没有做对的事情：我们接受平台中的高频数据输入，这会影响我们如何使用复杂的流量管理配置来回答对 DNS 记录的查询。** 数据馈送可以应用于多个 DNS 记录，因此，服务器负载遥测的馈送可以通知与服务器上托管的多个网站有关的流量路由决策。 我们假设您只会将单个数据 Feed 真正连接到一些 DNS 记录。 因此，我们通过将进入系统的数据馈送扩展为多条消息（每个连接的 DNS 记录一条消息）并将其推送到我们的边缘位置，从而节省了一些时间和精力。 我们错误地假设了，一些我们最喜欢的客户将数据源连接到了数千个 DNS 记录！ 我们早期的懒惰使我们不得不内部进行 DoS，我们知道随着我们的不断发展，这种情况只会变得越来越糟。 -即使在 8 台服务器上，Tagged 的 Web 流量也比我们大多数人所知道的要多。 幸运的是，memcached 具有双重优势，可以删除 90％以上的数据库读取，并确保包含各种信息的社交网站页面可以快速呈现。 +问题：我们不能仅仅通过发送更少的控制消息来回溯并解决问题。 我们需要更改数据模型和消息传递模型，以及 4-5 个交互的始终在线系统。 在**初期需要花费 2-3 个小时的额外思考和精力才能变成为期六周的**马拉松：集思广益，深度复杂的重构，大量的正确性测试工作以及一系列精心协调的部署和迁移， 所有人都可以在不中断服务的情况下解决该问题。 -从一开始，我们的对象缓存就着重于显式缓存更新，而采用了更简单的技术，例如删除无效密钥或基于计时器使过期数据过期。 以更复杂的代码为代价，这大大减少了数据库负载并保持了站点的快速运行，尤其是在涉及到频繁更新的对象时。 +虽然这是极端情况，但**新基础架构或代码的每个部署都必须无缝**：精心计划，滚动重启，持续集成测试。 为客户提供服务后，就不会关闭。 -除了标准的社交网络功能（朋友，个人资料，消息）外，我们的网站还不断增加复杂性，并增加了搜索和社交发现功能。 我的团队说服我使用 Java 来构建搜索，以便我们可以从 Lucene 库中受益。 当我们学会很好地运行它时，我感到宽慰，而我对 JDK 1.0 的早期经验所产生的不情愿也转化为对该平台的热情。 +## 极其小心地自动化部署和配置管理 -## V3：数据库可扩展，1000 万用户，100 台服务器，2006 年 +现代化的 devops 生态系统充斥着用于部署自动化和配置管理的工具：Chef，Puppet，Ansible，SaltStack，Terraform，以及似乎更多的东西。 您所使用的工具并不像您想的那么重要–阅读并确定哪种模型对您有意义。 但是**重要的是您正在使用这些工具**。 即使在公司的早期阶段，即使看起来更快或更容易，也不要手工管理您的配置或部署：您会犯错误，限制扩展能力，并且将很难进行扩展 以中等规模将自动化改造为移动目标。 -![](img/8514e77842ec44e2846d160f7c19cf5d.png) +但！ 注意：强大的力量带来巨大的责任。 **部署自动化工具使您可以像其他任何东西一样**在头脑中射击平台。 -随时都有 1000 万注册用户和数千在线用户，我们迎接了我一直在恐惧的挑战。 我们刚刚筹集了资金，并且正在为增长而努力，但是数据库的容量正在爆炸。 我们争先恐后地发布了一个缓存或 SQL 调优优化，但是我们服务器的 CPU 会一次又一次地趋向 100％。 +使用 Chef 管理所有主机的 iptables 规则？ **一个疲惫的 devops 工程师和一个按钮操作都可以全局禁用您的平台**。 推出一个新功能，您保证您在登台环境中上下左右测试过吗？ 当您遇到现实流量与模拟流量之间的细微差别时，端到端的自动化部署将使您的产品死光。 明智地使用自动化。 -扩大规模的想法提供了一个快速解决方案，但是多路服务器硬件可能要花费数百万美元，因此我们选择了 Oracle RAC，这使我们可以使用标准网络连接许多商用 Linux 主机来构建一个大数据库。 结合最新 CPU 的优势，Oracle RAC 的容量比我们的第一台数据库服务器增加了 20 倍，这是至关重要的，并使应用程序开发人员可以专注于构建新功能。 +我们使用 **Ansible 管理 NSONE 的配置和部署。 这是一个很棒的工具，具有很多怪癖。** 我们可以自动完成所有操作，并且只需按一下按钮就可以将新的 DNS 传递代码推送到我们的所有边缘位置，但是我们绝对不会这样做。 **我们从最低流量到最高流量按设施推出部署设施。 在一个设施内，我们逐台服务器甚至逐个核心部署，在此过程的每一步都运行全面的功能测试套件。** 在我们研究指标时，有时可能会影响性能，有时甚至是数小时或数天，然后才转移到更关键的设施上。 在开始部署之前，我们就签署了全面的代码审查，不仅是针对我们的应用程序代码，还包括我们的 Ansible 手册和配置。 -当 Tagged 开始通过将来自大型内存数据集的统计数据缝合在一起来提供个性化的人员匹配建议时，Java 进一步进入了环境，这与 PHP 完全不切实际。 +建立适合您的团队和应用程序的流程，但不要忘记，尽管自动化可以使您快速成长，但也可能使您快速死亡。 -## V4：数据库分片，5000 万用户，500 台服务器，2007 年 +## 进行消防演习 -![](img/ddfb18ca2a28624ee1c4697ce6e14b8b.png) +坏事发生了。 每个科技公司都会使服务器发生故障。 自从我们启动 NSONE **以来，我们已经经历了各种可以想象到的服务器故障**：磁盘故障，NIC 故障，RAM 损坏，内核崩溃，虚拟环境中嘈杂的邻居副作用以及两者之间的一切。 服务器故障很容易发生。 -毫无疑问，对数据库进行分片是扩展 Tagged 中最具挑战性，也是最有意义的一集。 通过将用户分散在多个数据库中，我们最终获得了一种设计，该设计可以在所有地方仅通过添加硬件即可进行扩展。 +电源将熄灭。 还记得桑迪飓风吗？ 在 NSONE 目前在曼哈顿下城的办公室的对面，技术人员正在用柴油在桶中爬楼梯，以保持基础设施在线。 -我们在 Tagged 的规则是将每个表划分为 64 个分区，并且除非有非常有说服力的例外理由，否则我们坚持默认设置。 仅将受益于玩家之间高性能保护交易的某些游戏垂直划分在单独的数据库中。 +光纤将被切断。 BGP 将被劫持。 您将获得 DoSed，其复杂程度各不相同：从脚本小子从其父母的地下室发送 64k ICMP 数据包到全面的 DNS 和 NTP 反射放大攻击，每秒可以以数百万或数亿个数据包的速率对您的基础设施进行 DDoS 处理。 -对现有数据进行分片表示跨数 TB 的复杂转换。 最初，我们一次依靠应用程序代码来替换功能来攻击功能，以替换联接，但最终我们在应用程序的核心遇到了一系列表，这些表对于这种方法过于紧密地联系在一起。 编写迁移软件以生成 SQL，我们使用触发器跟踪源系统上的更改并逐步更新目标，从而导出，转换和重新加载了亿万行，以便最终的同步少于 30 分钟。 +你会怎么做？ -具有许多数据库意味着具有许多数据库连接。 尤其是当我们添加了更多的“社交发现”功能（例如我们的第一个约会功能“遇见我”）时，分片将淹没 PHP，后者缺少 Oracle 连接池。 为了解决这个问题，我们构建了一个 Java 应用程序，该应用程序公开了一个用于运行查询的 Web 服务，该应用程序还将继续提供非常方便的监视点并允许正常处理数据库故障。 +**正确的唯一方法是练习。 在坏事情发生之前进行模拟。** Netflix 的 Chaos Monkey 是一个著名的例子。 您不一定总能直接模拟各种事件，但会尽力模拟响应。 这是确保时机成熟时唯一的方法，您可以保持镇定，使用已安装的工具并在困难的情况下有效地做出反应。 -## V5：完善和扩展功能，8000 万用户，1,000 台服务器，2010 年 +## 最小化表面积 -![](img/95fc1a2a48258c205567527af4f8bfbf.png) +随着您的应用程序分布范围越来越广，除非采取谨慎的预防措施，否则遭受恶意攻击的表面积将急剧增加。 **锁定您的系统，并最小化暴露给 Internet 的攻击面。** -我们在这里前进了几年。 解决了关键数据库可伸缩性问题后，我们发现通过添加硬件来支持扩展很简单。 PHP 和 memcached 继续为我们服务，并支持快速的功能开发。 +**体系结构中的每个角色应仅将其提供的服务公开给需要访问这些服务的系统集。** 您的面向 Internet 的系统应该向您的用户公开您提供的服务，而别无其他。 在后端，您的系统应尽可能在私有 IP 空间上相互交互，并且在不可行的情况下（例如，跨远程设施进行通信），数据应流经加密通道。 无论是通过 AWS 安全组之类的提供程序工具，通过 iptables 规则的自动管理，使用路由器 ACL 或硬件防火墙，还是其他某种机制，都可以积极使用防火墙。 **首先拒绝，然后按角色允许特定流量。** -在这段时间里，可伸缩性的考虑转向了减少故障，从而解决了越来越多的易碎部件的威胁。 通过负载平衡器运行状况检查和无响应服务的自动关闭，可以保护 Web 层免于依赖项的问题。 我们还设计了核心组件以提高弹性，例如，如果 memcached 的连接过载，则必须在减轻负担后立即恢复。 +**切勿允许操作员通过 ssh 等直接访问生产系统。** 人们应该通过高度锁定的堡垒主机进入您的基础架构，并使用多因素身份验证，端口敲门，IP 白名单以及其他相当严苛的安全策略。 确保您的堡垒主机分布在不同的网络和地理位置。 进入其余生产基础架构的操作应仅限于从堡垒主机发起的会话。 -Java 发挥了更加重要的作用，部分原因是接受度和专业知识的提高，但挑战也日益增加。 为了与垃圾邮件和其他滥用作斗争，我们的算法利用了大容量共享内存空间以及计算密集型技术。 社交游戏也得益于 Java 的性能和并发控制，但是代价是复杂性高。 我们现在需要比以前管理更多不同的应用程序池。 +有上百万种策略用于锁定系统。 我已经介绍了一些我们发现有效的做法，但绝非详尽无遗。 阅读并从一开始就考虑安全性：它是体系结构的一部分。 随着系统扩展，不要浪费时间以节省时间。 -## 未来 +## 了解提供商的情况 -如今，Tagged 每月向其数百万成员提供 50 亿页面浏览量。 由于我们已经实现了可扩展的设计，因此我们可以将大部分精力花在创建更好地为用户服务的功能上。 我们拥有创建可扩展软件的有效工具，但是可以想象会有更好的工具，因此当前的投资重点是软件库，以提高程序员的效率和生产率，而我们即将开发的开源，基于图形的数据库项目 [Stig](http://www.stigdb.org) 适用于大型社交网络，实时服务和云应用程序。 +几乎每个现代科技公司都在 AWS，DigitalOcean 或其他一些合理的低成本，低障碍的云基础架构提供商上构建其产品的第一个版本。 互联网在 AWS 之前就已经存在，并且基础设施提供商的多样性在过去十年中已经扩大。 -## 相关文章 +**大多数公司在扩展规模时都不会急于放弃 AWS。 但是每个公司都应尽可能保留可选性**。 -* [Johann Schleier-Smith 对 theCube 的采访](http://siliconangle.tv/video/johann-schleier-smith-cto-cofounder-tagged) +您可能会发现，应用程序中的特定工作负载最好由裸机处理，或者您需要在澳大利亚拥有高吞吐量的 CDN，或者您在没有 AWS 的情况下在市场上拥有关键的一组用户。 花一些时间来熟悉基础架构生态系统的各个方面：IaaS 提供程序，托管，DNS，CDN，监视等等。 在早期考虑架构时，有个想法，可能随着流量的增长和平台的扩展而需要在哪里寻找。 **准备快速移动**。 -PHP 和 Oracle 数据库用户（如 Tagged）的经验导致 Oracle Database 11g 的“数据库常驻连接池”功能。 PHP 现在具有可与 Oracle 数据库一起使用的本机连接池，从而使其具有高度可伸缩性，而无需早期先驱者必须实施的中间解决方案。 关于 PHP 和 Oracle DRCP 的白皮书为： [PHP 可伸缩性和高可用性：数据库常驻连接池和快速应用程序通知](http://www.oracle.com/technetwork/topics/php/whatsnew/php-scalability-ha-twp-128842.pdf)。 +在 NSONE，我们运营着一个复杂的全球任播 DNS 交付网络。 在进行原型设计时，AWS 很有意义，但是在启动平台之前，由于网络需求，我们不得不搬到其他地方。 建立一个具有竞争优势的任播 DNS 网络（针对世界一流的可靠性和性能进行调整），很大程度上取决于我们在复杂的托管和运营商环境中的导航能力，推动基础架构和网络提供商支持我们所需的控制深度的能力。 在许多情况下，我们对提供者进行了教育，并帮助他们建立了我们需要利用的功能。 -享受了这种架构的失败，对非 OSS 堆栈可伸缩系统进行了有趣的研究。 +**不要忘记：基础架构运营商也是极客，他们经常对新想法和挑战持开放态度。** 了解生态系统并参与其中。 -以我的经验，如果您使用 Oracle 的任何东西来尝试“省钱”，您可能犯了一些更深层次的错误。 其中很大一部分可能是出于非操作性原因而不选择 MySQL。 +## 总结 -从长远来看，Oracle 的主要问题是对其平台的大量锁定。 您将无法轻松地从 Oracle 迁移过来，尤其是当您使用 Java 存储过程之类的更独特（且公平，有用的）功能时。 加上他们对自己的企业级 Linux 的热爱，当您吸引 2 亿或 3 亿用户时，确实会使您的财务困难。 +我经历了很多课程，我们学习了构建和扩展分布式，关键任务系统的经验。 从一开始，您将永远不会把所有事情都做好，但是您可以让自己处于一个良好的位置，以便随着公司的发展而优雅而有效地做出反应。 -另一方面，如果它能正确完成工作，并且您的长期扩展和性能不受影响，那么如果您拥有知道如何使用它的人，那么任何工具都将是不错的选择。 +受众是全球性的。 应用程序交付也紧随其后，任何建立在线资源的新公司都应考虑如何以分布式方式进行架构和扩展，以向其用户提供最高质量的服务，从而最大限度地提高性能，可靠性和安全性。 -这很有趣。 节目的王者是 Java，而那个家伙坚持在每张图中都贴上“ PHP”。 那就是您的“架构”。 - -您可能会认为 Oracle 现在已经为您完成了扩展。 考虑到吹牛他们可以在两个 Exadata 系统上运行 Facebook，那么为什么对于带标签的它开箱即用呢？ 还是仅当您立即购买 Exa 东西时才起作用，还是根本不起作用？ 有任何信息/见解吗？ - -PHP 在 Apache 前叉模式下运行，即作为独立进程运行，这在高度可扩展的世界中是相对异常的。 该过程模型意味着 Oracle 的传统基于线程的中间层池解决方案不适用于 PHP。 在 Oracle DB 11g 中引入 Oracle DRCP 连接池之前，被标记为先驱者并实现了其池解决方法，有关链接，请参见我先前的评论。 DRCP 之所以有效，是因为连接池是在数据库服务器上处理的，因此可以在中间层进程和应用程序服务器之间共享该池。 白皮书显示了一个基准，该基准具有由商品服务器上的数据库处理的数以万计的 PHP 连接。 - -JDK 1.0，太慢了。 -但是 JDK 1.6 更好。 -并且您不应该在 1.0 版中想象...看一下 JDK 5 或 6。 \ No newline at end of file +*如果您错过了这篇文章的第一部分，那么[这是第 1 部分](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html)。* \ No newline at end of file diff --git a/docs/175.md b/docs/175.md index 4c4ffe0..93e3aa0 100644 --- a/docs/175.md +++ b/docs/175.md @@ -1,116 +1,45 @@ -# Peecho Architecture-鞋带上的可扩展性 +# 需要物联网吗？ 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式 -> 原文： [http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html](http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html) +> 原文： [http://highscalability.com/blog/2015/9/7/want-iot-heres-how-a-major-us-utility-collects-power-data-fr.html](http://highscalability.com/blog/2015/9/7/want-iot-heres-how-a-major-us-utility-collects-power-data-fr.html) -*这是 [Marcel Panse](http://www.linkedin.com/in/marcelpanse "Marcel Panse") 和 [Sander Nagtegaal](http://www.linkedin.com/in/centrical "Sander Nagtegaal") 来自 [Peecho](http://www.peecho.com) 的来宾帖子。* +[![](img/02aacf89ba2865c3d2f393ed9b481f74.png)](https://farm1.staticflickr.com/735/20975791628_7ef7fcd3f3_o.jpg) -尽管对体系结构的描述很有趣，但是几乎没有解决过初创企业面临的问题。 我们想改变它，所以这是我们的建筑故事。 +*我偶然发现了 [理查德·法利（HT。 关于](https://www.linkedin.com/in/drfarley) [高级计量基础架构](https://en.wikipedia.org/wiki/Smart_meter) 在加利福尼亚如何工作的说明。 这是真正的物联网领域。 因此，如果没有典型的职位结构，这就是原因。 他慷慨地允许通过一些修改将其重新发布。 当您看到“美国主要公用事业”时，请用最有可能的加利福尼亚电力公司代替它。* -## 初创公司介绍 +旧的机械仪表的轴承会随着时间的流逝而磨损，并产生摩擦力，从而导致读数下降。 这种摩擦将导致模拟仪表的旋转速度慢于其应有的速度，从而导致读数低于实际使用情况-从而产生“自由功率”。 这就像时钟在齿轮磨损之后落后时间。 -![Peecho](img/1bc747dd14e44355e996ab9878848537.png) +对于 *美国主要公用事业* 当您的电表由于某种原因而无法读取时，会发生“估计计费”。 [CPUC](http://www.cpuc.ca.gov/PUC/documents/codelawspolicies.htm) 认可的算法几乎总是对消费者有利。 *美国主要公用事业公司* 讨厌必须进行估算的帐单，因为它们几乎总是必须根据算法和 CPUC 规则进行低估。 并非 100％对此表示肯定，但是如果他们低估了这一点，他们就不得不承担成本。 在极少数情况下，他们高估了您的收入（例如，您在错过的假期中正在休假），那么您将在下一个结算周期被“烦恼”。 -阿姆斯特丹的[公司 Peecho](http://www.peecho.com) 提供打印即服务。 我们可嵌入的*打印按钮*使您可以直接在自己的网站上以专业打印产品的形式出售数字内容，例如相簿，杂志或画布。 也有一个 API。 +*美国主要公用程序* 并未实时显示您的实际使用情况。 对于那些对螺母和螺栓感兴趣的人，以下是 *美国主要公用事业* 的 AMI 系统的工作方式（AMI 是高级计量基础设施的缩写）： -Printcloud 是为打印按钮供电的系统。 它仅存在于云中，在需要时会增长，并在可能时变得更小。 该系统可以接收打印订单，神奇地将棘手的数据转换为可打印的文件，并将订单发送到最接近预期收件人的生产设施。 +* 家用电表每小时测量一次过去一小时的用电量，并将其（加密）存储在电表中。 对于商用电表，每 15 分钟进行一次测量。 -为了保护环境，Peecho 的理念是促进全球订购，但仅针对本地生产。 +* 取决于实际的仪表制造商（ *美国主要公用事业* 使用多个），它可能还会记录其他传感器数据，例如温度和电压。 -## 昂贵的东西无法扩展 +* 您的电表已连接到网状网络，该网络包括邻居的所有电表以及多个“接入点”，类似于您在家中为 WiFi 网络运行的网络。 通讯是视线，范围约为数百码。 -我们是一家初创企业，因此在开始之前我们考虑过的最重要的事情就是*资金*-或缺少资金。 尽管我们需要一些强大的火力，但完整的操作系统每月花费不超过几百美元。 +* 您的仪表具有全球唯一的 IPv6 地址，该地址是非常大型的 IPv6 网络的一部分。 -资金问题一直贯穿到我们的技术堆栈中。 我们可以在此处插入一些有关面向对象，代码编译或 MVC 架构的好东西-但最后，我们只需要一个无需花钱的广泛的开发工具包。 因此，我们开发人员社区的计算机科学背景使我们注意到了 Java 平台。 +* 接入点通常位于电线杆的顶部，并为相当大的区域提供服务-*美国主要公用事业*在整个北部和中部 Ca 拥有约 2,000 家，为 550 万户家庭和企业提供服务。 -使用云计算是无用的，因为按需扩展可以消除昂贵的产能过剩。 我们的候选清单包含 [Google App Engine](http://code.google.com/appengine/ "GAE") 和 [Amazon Web Services](http://aws.amazon.com "AWS") 。 这些大分子拥有比我们更多的资源和可扩展性经验。 这就是为什么我们发誓要尽可能多地使用他们的云服务，而不是自己构建东西。 但是，我们需要排队和关系数据存储-退出 Google。 +* 如果您的仪表无法直接连接到接入点，它将通过附近的仪表进行中继。 实际上，大多数仪表至少要经过几跳才能到达接入点，而仪表的传输中很大一部分实际上是在中继相邻流量。 网格非常有弹性，可以根据网络中的故障自动进行重组。 -因此，我们选择使用 SimpleDB，S3，SQS，EC2，RDS，IAM，Route 53 和 Cloudfront 在 Amazon Web Services 之上构建。 它便宜且通常可靠。 可以肯定的是，我们的整个系统在两个 AWS 可用区中同时运行，以确保最大的正常运行时间。 如果我们下去，一半的世界将与我们同在。 +* 接入点通常通过蜂窝网络（有时是卫星，有时甚至是以太网）连接到主要在西海岸的多个数据中心。 -## 如果你慢一点，你就无法成长 +* 数据中心每 4 个小时与您的电表建立连接，并下载自上次下载以来记录的所有电表数据。 这些通信都是加密的。 -但是，技术不是万能的。 小公司的可扩展性很大程度上是通过灵活性获得的。 快点 我们尝试使代码保持简单，因此重构很容易。 结果，我们只能负担所需的最低限度的费用，而无需考虑过多的未来需求。 我们可以稍后解决。 +* 这一切都非常迅速-在 30 分钟内*，美国主要的* *实用程序*已读取了 550 万米中的 95％以上。 每个仪表的读取时间通常不到一秒钟。 -如果您真的想快一点，那么短迭代很重要。 平均而言，我们大约每周一次将新软件发布到生产环境中。 为了跟上这一步，我们每月组织一次晚餐。 届时将展示演示，每个人都为新内容欢呼和鼓掌。 +* AMI 系统为计费系统提供数据。 *美国主要公用事业* 每天使用数小时内从电表下载的最新数据，向约 5％的客户发送账单。 使用手动抄表功能，距离 *最近的读数已经过了几天甚至几周，美国的主要公用事业公司* 能够发出账单并取钱。 “现金到现金”时间。 -有许多负担得起的帮助可帮助您快速入门。 例如，我们根据 [Scrum](http://en.wikipedia.org/wiki/Scrum_(development) "Scrum") 和[测试驱动开发](http://en.wikipedia.org/wiki/Test-driven_development "TDD")进行开发。 我们使用 [Jira](http://www.atlassian.com/software/jira/ "Jira") 和 [Greenhopper](http://www.atlassian.com/software/greenhopper/ "Greenhopper") 进行需求管理，使用 [Bamboo](http://www.atlassian.com/software/bamboo/ "Bamboo") 进行持续集成， [Sonar](http://www.sonarsource.org/ "Sonar") 进行代码质量监控，并使用 [Mercurial](http://mercurial.selenic.com/ "Mercurial") ]进行分布式版本控制。 +您的仪表还有一个电容器，如果您失去市电，它有时间发送“最后一声”消息。 *美国主要公用事业* （通常）知道断电的时间。 通常，这些最后的喘息消息会在 80％的时间内通过>，但它会因区域密度和拓扑结构而异。 成功率部分取决于消息必须中继通过多少个相邻仪表。 当您的电源中断时，通常也对大多数邻居起作用，因此中继链可能会断开。 在停电的边缘，相邻的电表仍然有电，成功会更好。 -顺便说一下，Atlassian 产品的数量众多，部分是由其*廉价的启动许可证*来解释的-但无论如何它都是好东西。 +许多公用事业公司每 15 分钟测量一次住宅用电量，一些试点项目正在每 15 秒进行一次测量，从而启用了所谓的“负载分解”分析功能，即能够根据其使用情况识别单个设备的使用情况 电源签名，甚至确定何时出现设备问题，例如冰箱压缩机坏了。 您可能会想到，这会生成大量数据，以及一些严重的隐私问题！ -## 当然可以，但是架构是什么样的？ +## 相关文章 -打印按钮及其签出作为单独的应用程序存在于我们平台的顶部。 关注点的分离是为了最大程度地减少交互点，从而实现高内聚和低耦合。 该应用程序在 EC2 自动扩展组上运行，顶部带有负载均衡器。 它将订单数据存储在 SimpleDB 中，SimpleDB 是一个可能遭受打击的 AWS No-SQL 数据存储。 静态所有内容都通过 Cloudfront CDN 运行，以避免服务器受到攻击。 +* [关于 HackerNews](https://news.ycombinator.com/item?id=10182054) -![Peecho Printcloud architecture: print button](img/dd654c6a01d7cbd4d8436e8b72e0129d.png) +很酷。 -确认付款后，打印按钮结帐会将每个订单提交给 REST API。 我们的高级用户可以从他们的应用访问相同的 API，因此我们只需要维护一个接口即可。 它负载均衡到可以自动扩展的多个节点。 使用关系数据库服务 RDS，订单数据保存在两个可用性区域中。 - -![Peecho Printcloud architecture: order intake](img/38543b1aba00c73000010fb69aa7e050.png) - -现在，这就是魔术发生的地方。 订单接收机将票证写入处理队列。 每当有足够的票证可用时，新的处理机就会唤醒，获取票证并开始处理糟糕的数据。 我们使用通过竞标未使用的 EC2 容量租用的大型[现货实例](http://aws.amazon.com/ec2/spot-instances/ "spot instances")。 完成这些大炮之后，他们将结果存储在 S3 中，然后自杀。 - -![Peecho Printcloud architecture: processing](img/bc047e89220edd051c9659e6a61de5f8.png) - -因此，使用队列指标，随着队列中项目数的变化，我们可以上下调整处理能力的数量。 这样可以节省资金，并为我们为意外中断做好准备。 在您自己执行此操作之前，请记住，每个组件或模块应仅负责特定的功能。 组件或对象不应了解其他组件或对象的内部详细信息。 - -随后，必须通过将生产票证添加到正确的打印设施队列来将订单路由到正确的生产设施。 通过使用我们的 Adobe AIR Printclient 桌面应用程序或直接集成，该工具可以从队列中检索其作业，并从 S3 文件存储中检索产品文件。 由于不涉及服务器，因此该系统实际上是防弹的。 - -![Peecho Printcloud architecture: Printclient](img/b264b8a39efc7cc89452be47d38cac9c.png) - -作为回报，该设施可以通过将消息发布到中央订单状态队列中来更新 Printcloud 中的作业状态。 异步地，我们读取该队列以更新客户的订单。 如果一切顺利，产品将很快发货。 - -一段时间后，产品文件将从 S3 中删除，以节省存储成本-所有人从此过上幸福的生活。 - -## 做数学 - -让我们快速了解我们的每月 AWS 账单。 您应该了解几件事。 - -* 亚马逊为 SimpleDB 和其他服务提供免费套餐。 -* 我们使用欧洲地区集群，该集群比美国集群贵。 -* EC2 实例被保留[一年](http://aws.amazon.com/ec2/reserved-instances/ "reserved EC2 instances")，因此更便宜。 -* 竞价型实例通常是讨价还价的，我们假设连续的工作负载为 50％。 -* 就像并发 EC2 节点的数量一样，所需的带宽在很大程度上取决于传入的订单数量。 - -| 任务 | 服务 | 成本估算 | -| --- | --- | --- | -| 打印按钮 | 多可用区 EC2 小实例 | $ 96 | -| 订单量 | Multi-AZ EC2 small instances | $ 96 | -| 处理中 | EC2 大现货实例 | $ 84 | -| 数据库 | 多可用区 RDS | $ 160 | -| 其余的部分 | Cloudfront，S3，SimpleDB，SQS 等 | $ 50 | - -一个完全弹性的重型系统每月的总收入为 *486 美元*，该系统具有至少 5 台服务器，2 台数据库服务器，No-SQL 数据存储和外部平面文件存储的功能。 - -我们认为还不错。 - -## 我们希望您有便宜的应用 - -Peecho 证明可以在小范围内创建可扩展的体系结构。 我们希望这些信息对您有用，也将帮助您创建出色的应用程序。 当然，最好带有打印按钮。 - -感谢您分享信息。 很好地利用 AWS 平台。 - -一个问题-您如何解决在共享熨斗上获取信用卡号所涉及的 PCI 问题？ 还是该平台当前足够小以至于这还不是认证问题？ 注意：从服务提供商的角度，而不是从最终商家的角度，我对 PCI 更为熟悉，因此这很可能根本不适用于您的情况，这也很有趣：) - -非常酷的写作。 谢谢。 -您是否使用任何其他工具进行管理/缩放（例如，正确缩放或缩放或类似操作），或者一切都在亚马逊上运行了准系统？ - -@Richard：对于这种设置，我猜他们使用的是支付服务提供商，负责支付的整个过程。 例如。 您将一个 transactionid 推给支付提供商，一旦客户确认交易，支付提供商就会触发回调并将该交易标记为成功（例如 Paypal 交易：） - -@Todd：您已经为 Auto-Scaling 组预先配置了现成的 AMI，还是使用诸如 Chef / Puppet / CFengine 之类的配置管理？ - -理查德，我不认识他们，但我从事电子商务，所以我可以回应。 如果您足够小，则可以使用隐藏的聚会进行货币交易，例如 Paypal，银行或类似的提供者。 -在这种情况下，信用卡号仅由该公司查看和保存，并且您仅收到服务器对服务器的消息，通知付款结果。 他们在文章中说“确认付款后”，所以我想是这样。 -我从未尝试过该网站。 - -我猜他们没有存储任何卡信息，它们可能只是重定向到支付网关 URL，就像贝宝那样。 - -这不是 BOA，而是 Peecho（如果他们只知道捷克语的意思，请使用不同的拼写） - -来自：http://www.pcicomplianceguide.org -问：PCI 适用于谁？ -答：PCI 适用于接受，传输或存储任何持卡人数据的所有组织或商家，无论交易规模或交易数量如何。 换句话说，如果该组织的任何客户曾经使用信用卡或借记卡直接向商家付款，则适用 PCI DSS 要求。 - -您是否发现小型实例的网络带宽足以满足 Web 需求？ - -“传输”是大问题。 但是我刚刚找到了一个相对较新的文档（去年年底），在该文档中，亚马逊的 AWS 环境获得了 PCI 一级服务提供商使用的认证。 那真的很酷。 嗯...现在，这篇文章甚至更发人深省。 - -@Todd: You you got preconfigured ready-to-go AMI's for your Auto-Scaling groups or do you use some kind of configuration management like Chef/Puppet/CFengine? \ No newline at end of file +非常有趣的阅读，谢谢！ \ No newline at end of file diff --git a/docs/176.md b/docs/176.md index 09a1646..7fb058a 100644 --- a/docs/176.md +++ b/docs/176.md @@ -1,157 +1,335 @@ -# 新的文物建筑-每天收集 20 亿多个指标 +# Uber 如何扩展其实时市场平台 -> 原文： [http://highscalability.com/blog/2011/7/18/new-relic-architecture-collecting-20-billion-metrics-a-day.html](http://highscalability.com/blog/2011/7/18/new-relic-architecture-collecting-20-billion-metrics-a-day.html) +> 原文： [http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) -![](img/e9a7fbf44fffff1b84995399759e1ae3.png) +![](img/40038672dfc38e0094e8da51e713355b.png) -*这是 New Relic 应用性能工程师 [Brian Doll](/cdn-cgi/l/email-protection#0e6c7c676f604e606b797c6b62676d206d6163) 的来宾帖子。* +据报道，[优步](https://www.uber.com/)在短短四年中增长了惊人的 [38 倍。 现在，我认为这是第一次，Uber 首席系统架构师](http://www.latimes.com/business/la-fi-0822-uber-revenue-20150822-story.html) [Matt Ranney](https://twitter.com/mranney) 在一个非常有趣且详细的演讲中-[扩展 Uber 的实时市场平台](http://www.infoq.com/presentations/uber-market-platform)- 告诉我们有关 Uber 软件如何工作的很多信息。 -New Relic 的多租户 SaaS Web 应用程序监视服务持续不断地每秒收集并保存超过 100,000 个指标，同时仍提供 1.5 秒的平均页面加载时间。 我们相信，良好的体系结构和良好的工具可以帮助您处理大量数据，同时仍然提供非常快速的服务。 在这里，我们将向您展示我们如何做到的。 +如果您对 Surge 定价感兴趣，则不在讨论之列。 我们确实了解了 Uber 的调度系统，如何实现地理空间索引，如何扩展系统，如何实现高可用性以及如何处理故障，包括使用驱动程序电话作为外部分布式存储系统来处理数据中心故障的惊人方式。 复苏。 -* 新遗物是应用程序性能管理（APM）即服务 -* 应用内代理检测（字节码检测等） -* 支持 5 种编程语言（Ruby，Java，PHP，.NET，Python） -* 全球监控超过 175,000 个应用程序进程 -* 10,000+客户 +演讲的整体印象是非常快速的增长之一。 他们做出的许多架构选择都是由于快速发展并试图授权最近组建的团队尽快行动而造成的。 后端已经使用了许多技术，因为他们的主要目标是使团队尽可能快地提高工程速度。 -## 统计资料 +在一个可以理解的混乱（非常成功）的开始之后，Uber 似乎已经学到了很多关于他们的业务以及他们真正需要成功的知识。 他们的早期派遣系统是一个典型的使其工作正常的事情，在更深的层次上假设它仅在移动人员。 现在，Uber 的使命已经发展为可以处理箱子，杂货以及人员，他们的调度系统已经抽象出来，并奠定了非常坚实和智能的架构基础。 -* 每天收集超过 20 亿个应用程序指标 -* 每周收集超过 1.7 亿个网页指标 -* 每个“时间片”指标约为 250 个字节 -* 每秒插入 10 万个时间片记录 -* 每天有 70 亿条新数据行 -* 由 9 个分片的 MySQL 服务器处理的数据收集 +尽管马特（Matt）认为他们的体系结构可能有点疯狂，但是在他们的用例中似乎使用了带有八卦协议的一致哈希环的想法。 -## 架构概述 +很难不为 Matt 对工作的真正热情着迷。 在谈到 DISCO，即他们的调度系统时，他激动地说道，这就像是学校里的旅行推销员问题。 这是很酷的计算机科学。 即使解决方案不是最佳解决方案，但它还是由在容错范围内的可扩展组件构建的，实时，真实的规模实用的旅行推销员。 多么酷啊？ -* 语言特定的代理（Ruby，Java，PHP..NET，Python）每分钟一次将应用程序指标发送回 New Relic -* “收集器”服务提取应用程序指标并将其保存在正确的 MySQL 分片中 -* 实时用户监控 javascript 代码段针对每个页面浏览将前端性能数据发送到“信标”服务 -* 客户登录 http://rpm.newrelic.com/查看其性能仪表板 -* 我们每天收集的数据量惊人。 最初，每个指标均以全分辨率捕获所有数据。 随着时间的流逝，我们会对数据进行定期处理，从每分钟到每小时，再到每天平均。 对于我们的专业帐户，我们会无限期地存储每日指标数据，因此客户可以看到他们在长期内的改进情况。 -* 我们的数据策略针对读取进行了优化，因为我们的核心应用一直需要按时间序列访问指标数据。 为了使数据保持最佳状态以实现更快的读取速度，更容易在写操作上付出代价，以确保我们的客户可以在一天中的任何时间快速访问其性能数据。 通过将客户分布在多台服务器上，可以对数据库进行分片。 在每个服务器中，每个客户都有单独的表，以使客户数据在磁盘上保持紧密并保持每个表的总行数减少。 -* New Relic 管理用于监视系统的多种警报。 客户可以设置其 APDEX 分数和错误率的阈值。 New Relic 还具有可用性监视功能，因此客户可以在短短 30 秒内收到停机事件的警报。 我们主要发送电子邮件警报，使用我们的 PagerDuty.com 集成向多个客户发送电子邮件，并通过 SMS 集成进行更复杂的通话轮换。 -* 让我们从客户请求一直到 New Relic 堆栈进行一次 Web 交易。 - 1. 最终用户查看 Example.com 上的页面，该页面使用 New Relic 监视其应用程序性能 - 2. 运行 Example.com 的应用程序运行时已安装了 New Relic 代理（适用于 Ruby，Java，PHP，.NET 或 Python） - 3. 为每个事务捕获详细的性能指标，包括每个组件花费的时间，数据库查询，外部 API 调用等 - 4. 这些后端指标在客户的 New Relic 代理中保留最多一分钟，然后将其发送回 New Relic 数据收集服务。 - 5. 同时，嵌入在网页中的是新的 Relic 真实用户监控 JavaScript 代码，该代码可跟踪这种单一客户体验的性能 - 6. 在客户的浏览器中完全呈现页面后，New Relic 信标会收到一个请求，其中提供了有关后端，网络，DOM 处理和页面呈现时间的性能指标。 - 7. 在 Example.com 上工作的工程师登录到 New Relic，并查看了最新的应用程序性能指标以及每位客户的最终用户体验，包括浏览器和地理信息。 +因此，让我们看看 Uber 在内部的工作方式。 这是我对 Matt [演讲](http://www.infoq.com/presentations/uber-market-platform) 的演讲： + +## 统计信息 + +* Uber 地理空间指数的目标是每秒写入一百万次。 阅读的倍数。 + +* 调度系统具有数千个节点。 ## 平台 -### 网页界面 +* Node.js -* Ruby on Rails -* Nginx 的 -* 的 Linux -* 2 个@ 12 核心 Intel Nehalem CPU 带 48Gb RAM +* Python -### 数据收集器和 Web 信标服务 +* Java -* 爪哇 -* 码头上的 Servlet -* 应用指标收集器：每分钟 180k +请求，在 3 毫秒内响应 -* Web 指标信标服务：每分钟 200k +请求，在 0.15 毫秒内响应 -* 使用 Percona 构建的 MySQL 分片 -* 的 Linux -* 9 @ 24 核 Intel Nehalem，带 48GB RAM，SAS 附加 RAID 5 -* 裸机（无虚拟化） +* 转到 -### 有趣的 MySQL 统计资料： +* iOS 和 Android 上的本机应用程序 -* New Relic 每小时为每个帐户创建一个数据库表以保存度量标准数据。 -* 该表策略针对读取和写入进行了优化 -* 始终需要在特定的时间窗口内基于特定帐户的一个或多个指标来绘制图表 -* 指标（指标，代理，时间戳）的主键允许来自特定代理的特定指标的数据一起位于磁盘上 -* 随着时间的推移，当创建新表时，这会在 innodb 中创建更多页面拆分，并且 I / O 操作会在一小时内增加 -* 新帐户将以循环方式分配给特定的分片。 由于某些帐户比其他帐户大，因此有时会将分片从分配队列中拉出，以更均匀地分配负载。 -* 由于表中包含如此多的数据，因此无法进行模式迁移。 而是使用“模板”表，从中创建新的时间片表。 新表使用新定义，而最终从系统中清除旧表。 应用程序代码需要注意多个表定义可能一次处于活动状态。 +* 微服务 -## 挑战性 +* Redis -* 数据清除：汇总指标和清除粒度指标数据是一个昂贵且几乎连续的过程 -* 确定哪些指标可以预先汇总 -* 大帐户：一些客户拥有许多应用程序，而另一些客户拥有数量惊人的服务器 -* MySQL 优化和调整，包括操作系统和文件系统 -* I / O 性能：裸机数据库服务器，每个帐户表与大型表的读取性能 -* 负载均衡碎片：大帐户，小帐户，高利用率帐户 +* Postgres -## 得到教训 +* MySQL -* New Relic 使用 New Relic 监视自己的服务（临时监视生产） -* 旨在随时提高运营效率和简化操作 -* 保持苗条。 New Relic 拥有约 30 名工程师，为 1 万名客户提供支持 -* 时髦！=可靠：高性能系统有许多重要但无聊的方面，但并不是所有时髦的解决方案都可以解决。 -* 使用合适的技术来完成工作。 New Relic 主要 Web 应用程序始终是 Rails 应用程序。 数据收集层最初是用 Ruby 编写的，但最终被移植到 Java。 导致此更改的主要因素是性能。 该层目前每分钟支持超过 18 万个请求，并在大约 2.5 毫秒内做出响应，并具有足够的扩展空间。 +* [修复](http://basho.com/) -## 相关文章 +* Twitter 的 Redis 的 [Twemproxy](https://github.com/twitter/twemproxy) + +* Google 的 [S2 几何库](https://code.google.com/p/s2-geometry-library/) + +* [铃声](https://github.com/uber/ringpop-node) -一致的哈希环 + +* [TChannel](https://github.com/uber/tchannel) -RPC 的网络复用和成帧协议 + +* 节俭 + +## 常规 + +* Uber 是一个运输平台，用于将骑手与驾驶员伙伴联系起来。 + +* 挑战：**将动态需求与动态供应实时匹配**。 在供应方，驾驶员可以自由地做他们想做的任何事情。 在需求方，骑手需要时随时需要运输。 + +* Uber 的 Dispatch 系统是一个实时市场平台，可使用手机将驾驶员与骑手相匹配。 + +* 除夕是 Uber 一年中最繁忙的时间。 + +* 容易忘记该行业取得如此巨大进步的速度。 技术的发展是如此之快，以至于最近令人惊奇的事物很快就消失了。 二十三年前，手机，互联网和 GPS 只是科幻小说，而现在我们几乎没有注意到它。 + +## 体系结构概述 + +* 驱动这一切的是运行本机应用程序的手机上的骑手和驾驶员。 + +* 后端主要为手机流量提供服务。 客户通过移动数据和尽力而为的 Internet 与后端对话。 您能想象 10 年前基于移动数据开展业务吗？ 我们现在可以做这种事情真是太棒了。 没有使用专用网络，没有花哨的 QoS（服务质量），只有开放的 Internet。 + +* 客户连接到与驾驶员和骑手相匹配的调度系统，供需。 + +* Dispatch 几乎完全用 node.js 编写。 + + * 计划将其移至 [io.js](https://iojs.org/en/index.html) ，但是从那时起，io.js 和 node.js [已合并](http://www.infoworld.com/article/2923081/javascript/reunited-io-js-rejoins-with-node-js.html) 。 + + * 您可以使用 javascript 做有趣的分布式系统。 + + * 很难低估**的生产能力，而节点开发人员**非常热情。 他们可以很快完成很多工作。 + +* 整个 Uber 系统似乎非常简单。 为什么您需要所有这些子系统以及所有这些人？ 只要这样，那便是成功的标志。 有很多事情要做，只要看起来很简单，他们就完成了自己的工作。 + +* **地图/ ETA** （预计到达时间）。 为了使 Dispatch 做出明智的选择，必须获取地图和路线信息。 + + * 街道地图和历史旅行时间用于估计当前旅行时间。 + + * 语言在很大程度上取决于要与哪个系统集成。 因此，有 Python，C ++和 Java + +* **服务**。 有大量的业务逻辑服务。 + + * 使用微服务方法。 + + * 主要用 Python 编写。 + +* **数据库**。 使用了许多不同的数据库。 + + * 最古老的系统是用 Postgres 编写的。 + + * Redis 经常使用。 有些落后于 Twemproxy。 有些是自定义群集系统的背后。 + + * MySQL + + * Uber 正在建立自己的分布式列存储，该存储可编排一堆 MySQL 实例。 + + * 某些分派服务在 Riak 中保持状态。 + +* **行程后管道**。 旅行结束后必须进行很多处理。 + + * 收集评分。 + + * 发送电子邮件。 + + * 更新数据库。 + + * 安排付款。 + + * 用 Python 编写。 + +* **金钱**。 Uber 与许多支付系统集成。 + +## 旧派送系统 + +* 最初的 Dispatch 系统的局限性是**开始限制公司**的成长，因此必须进行更改。 + +* 尽管 [Joel Spolsky 说了](http://www.joelonsoftware.com/articles/fog0000000069.html) ，但大部分内容还是重写了整个内容。 其他所有系统都没有被触及，甚至 Dispatch 系统中的某些服务都得以幸存。 + +* 旧系统是为私人交通设计的，它有很多假设： + + * 每辆车一个车手，不适用于 [Uber Pool](https://get.uber.com/cl/uberpool/) 。 + + * 迁移人员的想法已深入到数据模型和接口中。 这限制了向新市场和新产品的转移，例如转移食品和盒子。 + + * 原始版本由城市分片。 这对可伸缩性很有好处，因为每个城市都可以独立运行。 但是，随着越来越多的城市被添加，它变得越来越难以管理。 有些城市很大，有些城市很小。 一些城市的负载高峰很大，而其他城市则没有。 + +* 由于构建速度如此之快，它们没有单点故障，所以它们有多点故障。 + +## 新派送系统 + +* 为了解决城市分片问题并支持更多产品的问题，必须将供求的概念推广起来，因此创建了**供应服务和需求服务**。 + +* 供应服务跟踪所有供应的功能和状态机。 + + * 要跟踪车辆，有许多属性可以模型化：座椅数量，车辆类型，儿童汽车座椅的存在，轮椅是否可以安装等。 + + * 需要跟踪分配。 例如，一辆汽车可能有三个座位，但其中两个就被占用了。 + +* 需求服务跟踪需求，订单以及需求的所有方面。 + + * 如果骑乘者需要汽车安全座椅，则该要求必须与库存相匹配。 + + * 如果车手不介意以便宜的价格共享汽车，则必须建模。 + + * 如果需要移动箱子或运送食物怎么办？ -* [如何在仅 9 台服务器上构建具有类似 Twitter 吞吐量的 SaaS 应用程序](http://www.slideshare.net/newrelic/how-to-build-a-saas-app-with-twitterlike-throughput-on-just-9-servers)作者：Lew Cirne +* 满足所有供求关系的逻辑是称为 DISCO（调度优化）的服务。 -> >为每个事务捕获详细的性能指标，包括在每个组件中花费的时间，数据库查询，外部 API 调用等 + * 旧系统将仅在当前可用供应量上匹配，这意味着正在等待工作的道路上的汽车。 -这种仪器的开销是多少？ 就延迟而言？ + * DISCO 支持对未来进行规划，并在可用信息时加以利用。 例如，修改正在进行的行程中的路线。 -感谢您的详细帖子 + * **按供应商**的地理位置。 DISCO 需要地理空间索引来根据所有供应的位置和预期的位置来做出决策。 -几个问题 + * **按需求分配地理位置**。 需求还需要地理索引 -1.你做后写吗？ 有关的任何细节。 哪种工具/技术 -2.有关“负载平衡分片”的更多详细信息将有所帮助 -3.为什么选择 Java 而不是 Rails ...特定的性能原因。 + * 需要更好的路由引擎来利用所有这些信息。 -谢谢。 +### 调度 -> 在每个服务器中，每个客户都有单独的表，以使客户数据在磁盘上保持紧密并保持每个表的总行数减少。 +* 当车辆四处行驶时，位置更新将通过供应发送到地理位置。 为了使驾驶员与驾驶员匹配或仅在地图上显示汽车，DISCO 通过供应向地理区域发送请求。 -也许他们不知道文件系统如何工作？ 除非您预分配了该块，否则它将像其他所有文件一样随文件的增长而随机写入磁盘。 他们似乎认为，通过使用“ innodb_file_per_table”选项将其放入自己的表中并不保证文件会在磁盘上聚集。 +* 按供应商的地理位置会制作一个粗糙的首过滤波器，以获取附近符合要求的候选对象。 -@Hrish：“这种检测的开销是多少？就延迟而言？” +* 然后，将清单和需求发送到路由/ ETA，以计算它们在地理上而不是在道路系统附近的距离的 ETA。 -我们不断监控仪器的开销，并确保其开销尽可能低。 开销因应用程序而异，但通常在 5％的范围内。 与不了解生产系统的机会成本相比，这种开销显得微不足道。 我已经看到许多公司在使用 New Relic 的短短几天内就大大缩短了他们的响应时间，因此开销远远超过了其本身。 +* 按 ETA 排序，然后将其发送回供应源，以提供给驾驶员。 -@Subhash： -1.您是否在后面写？ 有关的任何细节。 哪种工具/技术 +* 在机场，他们必须模拟虚拟出租车队列。 必须将供应排队，以考虑到货的顺序。 -不，我们不做后写。 +### 地理空间索引 -2.有关“负载平衡分片”的更多详细信息将有所帮助 +* 必须具有超级可扩展性。 设计目标是**每秒处理一百万次写入**。 写入速率来自于驱动程序，驱动程序在移动时每 4 秒发送一次更新。 -我们采用经典的分片模式，因为客户指标对他们来说是唯一的，并且我们不需要在各个帐户之间引用指标。 理想情况下，我们希望将负载分配到每个分片上。 在这种情况下，负载既指数据量（在给定时间段内每个分片接收多少数据），也指查询量（那些客户访问其指标的积极程度）。 我们每个帐户允许无限数量的用户，因此某些帐户有许多用户一次访问其性能数据。 我们一起研究这些指标以及诸如 CPU 和内存之类的系统指标，以确定负载在整个分片上的分布情况。 +* 读取目标是每秒读取的次数多于每秒写入的次数，因为每个打开应用程序的人都在进行读取。 -我们以循环方式将新帐户分配给特定的分片。 这听起来非常简单，而且确实如此。 这里的过早优化可能需要付出很大的努力才能进行管理，而带来的好处却很小。 您只是无法确定注册新帐户后的忙碌程度。 我们会不时注意到特定的分片比其他分片更忙。 这可能是由于新帐户非常庞大，或者是由于现有帐户利用率提高。 为了帮助平衡分片，我们只从分配队列中删除该分片，因此暂时不会获得任何新帐户。 由于我们一直在注册新帐户，因此其余的碎片将赶上来，我们将其重新添加。 +* 通过简化假设，旧的地理空间指数非常有效，它仅跟踪可调度的供应。 供应的大部分都在忙于做某事，因此可用供应的子集易于支持。 在少数几个进程中，全局索引存储在内存中。 进行非常幼稚的匹配非常容易。 -我已经与几个为具有类似数据需求的公司在生产中运行分片的人交谈过，看来这种方法相当普遍。 正如他们所说，做最简单的事情就可以了:) +* 在新世界**中，必须跟踪每个状态下的所有供应**。 此外，还必须跟踪其预计路线。 这是更多的数据。 -3.为什么选择 Java 而不是 Rails ...特定的性能原因。 +* 新服务**在数百个进程**上运行。 -用于数据收集的服务端点已从 Ruby 移植到 Java。 这些服务非常强大，并且不会经常更改。 他们需要从成千上万个应用程序实例中获取指标数据，并将其放入正确的分片中的正确的数据库表中。 除了耐用性，这些保养的最重要特征是原始速度。 使用当前的 ruby 实现，根本不可能与 Java servlet 竞争速度和效率。 我们的 Real User Monitoring 信标服务（作为 Java Servlet 部署）的响应时间为 0.15 毫秒。 十五分之一毫秒！ 这是每分钟 280k +请求。 +* 地球是一个球体。 单纯基于经度和纬度很难进行汇总和近似。 因此，Uber 使用 Google S2 库将地球分成了微小的单元。 每个单元都有唯一的单元 ID。 -您特别强调数据库服务器是裸机。 这是否意味着其他内容已虚拟化？ -我很惊讶您确实运行自己的服务器。 我一直以为您是那些早期的云采用者之一。 :) +* 使用 int64 可以表示地球上每平方厘米。 Uber 会使用 12 级的单元，其大小从 3.31 km（2）到 6.38 km（2），具体取决于您在地球上的哪个位置。 盒子根据它们在球体上的位置而改变形状和大小。 -您是否在单个数据中心中运行？ 您如何处理高可用性？ +* S2 可以提供形状的覆盖范围。 如果要绘制一个以伦敦为中心，半径为 1 公里的圆，S2 可以告诉您需要哪些单元格才能完全覆盖该形状。 -“ [开销]通常在 5％的范围内” +* 由于每个单元都有一个 ID，因此该 ID 被用作分片密钥。 当从供应中获得位置时，将确定该位置的小区 ID。 使用单元 ID 作为分片键，可以更新耗材的位置。 然后将其发送到几个副本。 -除非有人指出执行的检测程度和检测到的主要组件的等待时间，即一个非常慢的 Rails 应用程序甚至更慢的数据库访问，否则这毫无意义。 +* 当 DISCO 需要在某个地点附近寻找补给品时，将以骑手所在的位置为中心，计算一个圆的覆盖范围。 使用圆圈区域中的单元 ID，将所有相关的分片联系起来以返回供应数据。 -与其他产品的单位成本相比，NewRelic 的速度要慢近 10,000-100,000 倍。 -http://williamlouth.wordpress.com/2011/03/17/which-ruby-vm-consider-monitoring/ +* 全部可扩展。 即使效率不如您期望的那样，并且由于扇出相对便宜，所以可以始终通过添加更多节点来扩展写负载。 通过使用副本来缩放读取负载。 如果需要更多的读取容量，则可以增加复制因子。 -顺便说一句，我想知道如何将 NewRelic 下面的屏幕截图中的多个 SQL 语句打包成 250 个字节。 -http://williamlouth.wordpress.com/2010/03/02/does-transaction-tracing-scale-analysis/ +* 一个限制是单元格大小固定为 12 级大小。 将来可能会支持动态单元大小。 需要进行权衡，因为像元大小越小，查询的扇出越大。 -我认为您还应该指出，考虑到发送之前在 1 分钟的示例窗口中对高级度量聚合进行了批处理，因此所测量的页面数与对服务的入站调用数不同。 +### 路由 + +* 从地理空间得到答案后，必须对选项进行排名。 + +* 有几个高级目标： + + * **减少额外的驱动**。 驾驶是人们的工作，因此人们渴望提高生产力。 他们获得额外的出行报酬。 理想情况下，驾驶员应连续行驶。 一堆工作会排队等待，他们将为此获得报酬。 + + * **减少等待**。 骑手应等待的时间尽可能短。 + + * **总体 ETA 最低**。 + +* 旧的系统是让需求搜索当前可用的供应，匹配并完成。 它易于实施且易于理解。 对于私人交通来说，它工作得很好。 + +* 仅查看当前的可用性无法做出好的选择。 + +* 的想法是，与正在远处行驶的驾驶员相比，当前正在运送驾驶员的驾驶员可能更适合要求乘车的顾客。 挑选出行驾驶员可以最大程度地减少客户的等待时间，并可以减少远程驾驶员的额外驾驶时间。 + +* 这种尝试展望未来的模型可以更好地处理动态条件。 + + * 例如，如果某个驾驶员在客户附近上线，但已经从较远的地方派遣了另一个驾驶员，则无法更改分配决策。 + + * 另一个示例涉及愿意共享旅程的客户。 通过尝试在非常复杂的场景中预测未来，可以进行更多优化。 + +* 在考虑运送盒子或食物时，所有这些决定变得更加有趣。 在这些情况下，人们通常还有其他事情要做，因此涉及不同的权衡。 + +## 缩放调度 + +* 使用 node.js 构建调度程序。 + +* 他们正在建立有状态服务，因此无状态扩展方法将行不通。 + +* Node 在单个进程中运行，因此必须设计某种方法以在同一台计算机上的多个 CPU 上以及多个计算机上运行 Node。 + +* 有一个关于在 Javascript 中重新实现所有 Erlang 的笑话。 + +* 用于扩展 Node 的解决方案是 *ringpop* ，这是一种具有八卦协议的一致哈希环，实现了可扩展的，容错的应用程序层分片。 + +* 在 CAP 术语中，ringpop 是 **AP 系统**，为了获得可用性而进行交易。 最好说明一些不一致之处，而不是提供停机服务。 最好起床并偶尔出错。 + +* 铃声是每个 Node 进程中都包含的可嵌入模块。 + +* 节点实例在成员资格集周围闲聊。 一旦所有节点都同意谁是谁，他们就可以独立有效地做出查找和转发决策。 + +* 这确实是可扩展的。 添加更多流程，完成更多工作。 它可用于分片数据，或用作分布式锁定系统，或协调 pub / sub 或长轮询套接字的集合点。 + +* 八卦协议基于 [SWIM](https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf) 。 已经进行了一些改进以缩短收敛时间。 + +* 闲聊的成员列表随处可见。 随着添加更多节点，它是可伸缩的。 SWIM 中的“ S”是可扩展的，确实有效。 到目前为止，**已扩展到数千个节点。** + +* SWIM 将健康检查与成员身份更改结合在一起，作为同一协议的一部分。 + +* 在铃声系统中，所有这些 Node 进程都包含铃声模块。 他们八卦当前成员。 + +* 在外部，如果 DISCO 要消耗地理空间，则每个节点都是等效的。 选择一个随机的健康节点。 请求到达的任何地方都负责使用哈希环查找将请求转发到正确的节点。 看起来像： + +![20783449993_8e0e0491df.jpg](img/d016d61f90e0ba24dafb216e10a828bd.png) + +* 使所有这些跃点和对等体互相交谈可能听起来很疯狂，但是它会产生一些非常好的属性，例如可以通过在任何计算机上添加实例来扩展服务。 + +* ringpop 是基于 Uber 自己的称为 *TChannel* 的 RPC 机制构建的。 + + * 这是一个双向请求/响应协议，其灵感来自 Twitter 的 [Finagle](https://twitter.github.io/finagle/) 。 + + * 一个重要的目标是控制许多不同语言的性能。 特别是在 Node 和 Python 中，许多现有的 RPC 机制无法很好地发挥作用。 想要 redis 级性能。 **TChannel 已经比 HTTP** 快 20 倍。 + + * 想要高性能的转发路径，以便中间人可以非常轻松地做出转发决策，而不必了解完整的有效负载。 + + * 希望进行适当的流水线处理，以免出现线头阻塞，请求和响应可以随时沿任一方向发送，并且每个客户端也是一台服务器。 + + * 希望引入有效负载校验和和跟踪以及一流的功能。 每个请求遍历系统时都应该是可跟踪的。 + + * 想要从 HTTP 清除迁移路径。 HTTP 可以非常自然地封装在 TChannel 中。 + + * **Uber 退出了 HTTP 和 Json 业务**。 一切都在通过 TChannel 进行节俭。 + +* 铃声正在通过基于 TChannel 的持久连接进行所有八卦。 这些相同的持久连接用于扇出或转发应用程序流量。 TChannel 也用于服务之间的通话。 + +## 派送可用性 + +* **可用性很重要**。 优步拥有竞争对手，转换成本非常低。 如果 Uber 暂时倒闭，那笔钱就会流向其他人。 其他产品的粘性更大，客户稍后会再试。 Uber 不一定是这样。 + +* **使所有内容均可重试**。 如果某些操作无效，则必须重试。 这就是解决故障的方法。 这要求所有请求都是幂等的。 例如，重试发送不能将它们发送两次或对某人的信用卡收取两次费用。 + +* **使所有东西都可以杀死**。 失败是常见的情况。 随机杀死进程不应造成损害。 + +* **仅崩溃**。 没有正常关机。 正常关机不是必需的做法。 当意外情况发生时，需要练习。 + +* **小块**。 为了最大程度地减少失败带来的损失，请将它们分成更小的部分。 可能可以在一个实例中处理全局流量，但是当该流量消失时会发生什么呢？ 如果有一对，但其中一个发生故障，则容量将减少一半。 因此，服务需要分解。 听起来像是技术问题，但更多是文化问题。 拥有一对数据库会更容易。 这是很自然的事情，但是配对不好。 如果您能够自动升级一个并重新启动新的辅助节点，则随机杀死它们是非常危险的。 + +* **杀死所有东西**。 甚至杀死所有数据库，以确保有可能幸免于此类失败。 这就需要改变使用哪种数据库的决策，他们选择了 Riak 而不是 MySQL。 这也意味着使用铃声而不是 redis。 杀死 redis 实例是一项昂贵的操作，通常，删除它们的规模很大而且代价很高。 + +* **将其分解为较小的块**。 谈论文化转变。 通常，服务 A 将通过负载平衡器与服务 B 对话。 如果负载均衡器死了怎么办？ 您将如何处理？ 如果您从不走那条路，那您将永远不会知道。 因此，您必须终止负载均衡器。 您如何绕过负载均衡器？ 负载平衡逻辑必须放在服务本身中。 客户需要具有一定的智能才能知道如何解决问题。 这在哲学上类似于 Finagle 的工作方式。 + +* 为了使整个系统扩展并处理背压，已经从一系列的 poppop 节点中创建了一个服务发现和路由系统。 + +## 总数据中心故障 + +* 这种情况很少发生，但是可能会发生意外的级联故障，或者上游网络提供商可能会发生故障。 + +* Uber 维护着一个备份数据中心，并安装了交换机以将所有内容路由到备份数据中心。 + +* 问题是进程内旅行的数据可能不在备份数据中心中。 他们不是使用复制数据，而是使用驾驶员电话作为行程数据的来源。 + +* 发生的情况是调度系统**定期向驱动器电话**发送加密的状态摘要。 现在，假设有一个数据中心故障转移。 下次驾驶员电话向 Dispatch 系统发送位置更新时，Dispatch 系统将检测到该行程不知道，并向州政府索要状态摘要。 然后，派遣系统会根据状态摘要进行自我更新，并且旅行就像没有发生一样继续进行。 + +## 不利之处 + +* Uber 解决可扩展性和可用性问题的方法的弊端是潜在的高延迟，因为 Node 进程之间相互转发请求并发送扇出的消息。 + +* 在扇出系统中，微小的斑点和毛刺会产生惊人的巨大影响。 系统中的扇出程度越高，发生高延迟请求的机会就越大。 + +* 一个好的解决方案是通过跨服务器取消来拥有**备份请求。 这是 TChannel 的一流功能。 将请求与信息一起发送到服务 B（2）的请求一起发送到服务 B（1）。 然后，稍后将请求发送到服务 B（2）。 B（1）完成请求后，将取消 B（2）上的请求。 有了延迟，这意味着在通常情况下 B（2）没有执行任何工作。 但是，如果 B（1）确实失败了，那么 B（2）将处理该请求并以比首先尝试 B（1），发生超时然后再尝试 B（2）更低的延迟返回响应。** + +* 请参见 [Google 延迟容忍系统：将不可预测的部分](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) 制成可预测的整体，以获取更多背景知识。 + +## 相关文章 -如果您打算从事 APM 业务，那么您至少可以尝试对数字的实际含义和关联性进行准确和更加透明的了解。 +* [关于 HackerNews](https://news.ycombinator.com/item?id=10216019) -您是否曾经考虑过使用 Mysql Cluster？ NDB？ 无需分片即可立即获得巨大的读取/写入可扩展性。 +* [S2map.com](http://s2map.com/) -请参见 S2 覆盖率和绘制形状 -我们一直在使用 Galera 群集来处理 1440K 更新，每分钟有足够的净空。 +感谢您写这篇文章。 令人着迷的阅读！ -顺便说一句，恭喜并感谢您分享非常有用的信息。 \ No newline at end of file +很棒的文章，非常有趣，并深入研究@uber 工作中的思想过程。 \ No newline at end of file diff --git a/docs/177.md b/docs/177.md index 1dbfe1d..940e86d 100644 --- a/docs/177.md +++ b/docs/177.md @@ -1,69 +1,185 @@ -# Google+是使用您也可以使用的工具构建的：闭包，Java Servlet，JavaScript，BigTable，Colossus，快速周转 +# 优步变得非常规：使用司机电话作为备份数据中心 -> 原文： [http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-you-can-use-too-closure-java-ser.html](http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-you-can-use-too-closure-java-ser.html) +> 原文： [http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) -![](img/efde67061495354a389ef6f96ab526ce.png) +![](img/e57ca973ce8db179be6e4c55c317fa95.png) -Plaxo 的前首席技术官 Joseph Smarr（解释了我认出他的照片的原因）在[中，我是 Google+团队的技术负责人。 问我什么](http://anyasq.com/79-im-a-technical-lead-on-the-google+-team)，揭示用于构建 Google+的堆栈： +在[中，Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)，最吸引人的提示之一是 Uber 如何使用驱动程序电话作为外部分布式存储系统进行恢复来处理数据中心故障转移。 -> 如今，我们的协议栈是 Google 应用程序的标准价格：我们将 Java servlet 用于服务器代码，将 JavaScript 用于 UI 的浏览器端，很大程度上是由（开源）Closure 框架构建的，其中包括 Closure 的 JavaScript 编译器和模板系统 。 我们采取了一些巧妙的技巧：即使使用的是 AJAX 应用程序，我们也使用 HTML5 历史记录 API 来维护漂亮的 URL（对于较旧的浏览器，它采用哈希碎片）； 并且我们经常在服务器端渲染 Closure 模板，以便在加载任何 JavaScript 之前先渲染页面，然后 JavaScript 找到正确的 DOM 节点并挂接事件处理程序等，以使其具有响应能力（因此，如果您在 缓慢的连接，您很快就会点击内容，您可能会注意到它在执行任何操作之前都存在滞后，但幸运的是，大多数人实际上并没有遇到这种情况）。 我们的后端主要建立在 BigTable 和 Colossus / GFS 之上，并且我们使用了许多其他常见的 Google 技术，例如 MapReduce（同样，与许多其他 Google 应用程序一样）。 +现在我们从 Uber 的 [Nikunj Aggarwal](https://www.linkedin.com/pub/nikunj-aggarwal/20/878/3b4) 和 [Joshua Corbin](https://www.linkedin.com/in/joshuatcorbin) 了解了更多有关该系统的工作原理，他们在 [@Scale](http://www.atscaleconference.com/) 会议上发表了非常有趣的演讲： [。Uber 如何将您的手机用作备份数据中心](https://www.youtube.com/watch?v=0EhTOKcwRok)。 -起初，我读了 Clojure，这真是一个真正的惊喜，但是它是 Closure，这是一套 JavaScript 工具，由[库](http://code.google.com/closure/library/)，[编译器](http://code.google.com/closure/compiler/)和[模板](http://code.google.com/closure/templates/)组成 。 该编译器是用于 JavaScript 的真正编译器，可加快 JavaScript 下载和运行速度。 该库是模块化和跨浏览器的 JavaScript 库。 模板是服务器端模板系统，可帮助您动态构建可重用的 HTML 和 UI 元素。 它都是开源的，因此您也可以使用它。 +Uber 并未使用传统的后端复制方案，在该方案中，数据库在数据中心之间同步状态以实现 [k-safety](https://my.vertica.com/docs/5.0/HTML/Master/10730.htm) 的度量，而 Uber 做了一些不同的事情，他们要做的是将足够的状态存储在驱动程序电话上，以便在数据中心进行故障转移时 发生故障信息不会在故障转移上丢失。 -虽然您没有可用的 Google 堆栈，但确实有一些开源选项。 [HBase](http://wiki.apache.org/hadoop/Hbase) 替代了 BigTable。 然后是 [Hadoop MapReduce](http://hadoop.apache.org/mapreduce/) 。 [Colossus](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) 是 Google 的[下一代文件系统](http://highscalability.com/blog/2010/9/11/googles-colossus-makes-search-real-time-by-dumping-mapreduce.html)，是 GFS 的替代品。 由于我们对 Colossus 知之甚少，因此很难说出合适的替代品。 有 Hadoop 分布式文件系统 [HDFS](http://hadoop.apache.org/hdfs/) 。 如果您正在寻找一些像基础架构胶之类的云，则可以使用 [OpenStack](http://www.openstack.org/) （它也具有存储系统）。 +为什么选择这种方法？ 传统方法会简单得多。 我认为这是要确保客户始终拥有良好的**客户体验**，并且由于主动出行而丢失行程信息会带来可怕的客户体验。 -Google 可能使用了自定义的 [Java servlet](http://en.wikipedia.org/wiki/Java_Servlet) 容器，但是此处的选择并不重要。 大部分工作将以并行方式产生，并在以 [C ++，Java 或 Python](http://www.quora.com/Which-programming-languages-does-Google-use-internally) 实现的其他服务器上执行。 +通过围绕电话建立他们的同步策略，甚至认为它很复杂且需要大量工作，Uber 能够保留旅行数据并即使在数据中心发生故障时也能提供无缝的客户体验。 使客户满意是至关重要的，尤其是在**接近零转换成本**的市场中。 -尽管几乎没有与 Google 的交流，但 Google+开发团队的响应速度明显加快，可以快速，一致地实现明显的改进。 约瑟夫告诉我们原因：*我们特别强调工程速度/敏捷性-我们尝试每天发布代码更新，同时仍保持质量/稳定性/延迟与您对 google 的期望一样高。 这有助于我们快速行动并快速响应用户反馈。 我们尝试（几乎）每天都进行一次完全推送，有时，如果需要，有时我们也会潜入补丁程序发行版中。 但是有很多人参与其中，这不是“如果所有测试都通过都会自动推动”的情况或类似的情况。* +因此，目标是即使在数据中心故障转移时也不会丢失行程信息。 使用传统的数据库复制策略，由于与[网络管理系统](http://whatis.techtarget.com/definition/network-management-system)始终必须工作的方式类似的原因，不可能做出此保证。 让我解释。 -对于 Google+最具创新性的功能，即环聊视频会议，GigaOM 在该堆栈上有一篇[不错的文章，该文章基于由技术负责人 Justin Uberti 撰写的](http://gigaom.com/video/google-hangouts-technology/)[宣布 Google+ Hangouts](http://juberti.blogspot.com/2011/06/announcing-google-hangouts.html) 。 与以经济高效的 P2P 模式运行的 Skype 不同，环聊完全由 Google 托管。 这必须花费惊人的金钱。 你自己一个人在这里。 没有人可以取代 Google 童话捐赠的带宽。 +在网络设备中，状态信息的权威来源是**，例如分组错误，警报，发送和接收的分组等等。 网络管理系统对诸如警报阈值和客户信息之类的配置数据具有权威性。 麻烦的是设备与网络管理系统并不总是保持联系，因此它们不同步，因为它们彼此独立地工作。 这意味着在启动，故障转移和通信重新连接时，所有这些信息都必须使用复杂的舞蹈在两个方向上合并，以确保正确性和一致性。** -那就是 Google。 再一次，一位前 Google 员工认为[您可以使用 MessagePack，JSON，Hadoop，jQuery 和 MongoDB 更好地完成](http://rethrick.com/#waving-goodbye)。 如果您可以为全球十亿用户群做得更好，那将是另一个完全不同的问题。 +Uber 有同样的问题，只有设备是智能手机，而手机所包含的权威状态是出行信息。 因此，在启动，故障转移和通信重新连接时，必须保留行程信息，因为电话**是行程信息**的权威来源。 -## 相关文章 +即使失去连接，电话也能准确记录所有行程数据。 因此，您不希望将行程数据从数据中心向下同步到手机，因为这会清除手机上的正确数据。 正确的信息必须来自电话。 + +Uber 还从网络管理系统中吸取了另一招。 他们定期查询电话以测试数据中心中信息的完整性。 + +让我们看看他们是如何做到的... + +## 将电话用作数据中心故障存储的动机 + +* 不久前，发生故障的数据中心将导致客户旅行丢失。 现在已解决。 在数据中心发生故障时，客户可以立即返回旅途，几乎没有明显的停机时间。 + +* 将旅行的请求，提供给驾驶员的旅行，接受的旅行，上车的乘客以及结束旅行的过程称为**状态更改转换**。 只要行程持续，行程交易就持续。 + +* 从行程开始起，便在后端数据中心中创建了行程数据。 似乎每个城市都有一个指定的数据中心。 + +* **数据中心故障的典型解决方案**：将数据从活动数据中心复制到备份数据中心。 很好理解，并且可以很好地工作，具体取决于您的数据库。 缺点： + + * 超出了两个备份数据中心的复杂性。 + + * 数据中心之间的复制滞后。 + + * 它需要数据中心之间的恒定高带宽，特别是如果您的数据库对数据中心复制没有很好的支持，或者您尚未调整业务模型来优化增量。 + + * （一个尚未被谈论的好处，对于 Uber 而言可能并不重要，但对于较小的参与者而言可能是重要的，因为驾驶员电话计划通过不必为数据中心间的带宽支付那么多钱来补贴带宽成本。 ） + +* **具有创造力的应用程序意识的解决方案**：由于与驾驶员电话的持续通信只是将数据保存到驾驶员电话。 优点： + + * 可以故障转移到任何数据中心。 + + * 避免了电话故障转移到错误的数据中心的问题，这将导致丢失所有行程。 + +* 使用驱动程序电话来保存数据中心备份需要复制协议。 + + * 与数据中心通信时，会发生所有状态转换。 例如，有一个 Begin Trip 或 Begin Drive 请求，这是与手机交换状态数据并拥有手机存储数据的绝佳机会。 + + * 在数据中心故障转移上，当电话 ping 新数据中心时，需要从电话中请求行程数据。 停机时间非常短。 （没有有关如何处理数据中心地图的信息）。 + +* 挑战： + + * 并非驾驶员可以访问所有保存的行程信息。 例如，一次旅行有很多关于所有骑手的信息，这些信息不应该被公开。 + + * 必须假设驱动程序手机可能受到攻击，这意味着必须对数据进行防篡改。 因此，所有数据都在手机上进行了加密。 + + * 希望保持复制协议尽可能简单，以便于推理和调试。 + + * 最小化额外带宽。 使用基于电话的方法，可以调整要序列化的数据和保留的增量，以最大程度地减少移动网络上的流量。 + +* 复制协议 + + * 一个简单的键值存储模型用于键操作的获取，设置，删除，列表。 + + * 只能设置一次密钥，以防止意外覆盖和乱码消息问题。 + + * 设置了一次之后，规则版本控制就必须移入密钥空间。 更新存储的行程的过程如下：set（“ trip1，version2”，“ yyu”）; delete（“ trip1，version1”）。 这样做的好处是，如果在设置和删除之间出现故障，将存储两个值，而不存储任何值。 + + * 故障转移解决方案只需通过以下方法在电话和新数据中心之间合并密钥即可：将存储的密钥与驾驶员已知的任何正在进行的行程进行比较； 对于任何丢失的数据，可能会向手机发送一个或多个 *get* 操作。 + +## 他们如何获得系统大规模运行的可靠性 + +### 目标 + +* **确保系统未阻塞，同时仍提供最终的一致性**。 即使系统关闭，系统中的任何后端应用程序也应能够取得进展。 应用程序应该做出的唯一权衡是，将数据存储在手机上可能要花费一些时间。 + +* **能够在数据中心之间移动而不必担心已有的数据**。 需要一种在驱动程序和服务器之间协调数据的方法。 -* [封闭库](http://code.google.com/closure/library/) / [封闭模板](http://code.google.com/closure/templates/) / [封闭编译器](http://code.google.com/closure/compiler/) -* [VMware 公开了计划成为云操作系统](http://gigaom.com/cloud/vmware-exposes-its-plans-to-be-the-os-for-the-cloud)-另一种基础架构选项。 -* [罗得岛巨像](http://en.wikipedia.org/wiki/Colossus_of_Rhodes)-世界奇观。 -* [Colossus Computer](http://en.wikipedia.org/wiki/Colossus_computer) -英国密码破解者使用的电子计算设备，用于在第二次世界大战期间帮助读取加密的德语消息。 他们使用真空管（热电子阀）进行计算。 -* [巨像：Forbin 项目](http://en.wikipedia.org/wiki/Colossus:_The_Forbin_Project)-一部名为 Colossus 的大型美国防御计算机的科幻电影，引起了人们的注意并决定接管世界。 -* 这篇文章[关于黑客新闻](http://news.ycombinator.com/item?id=2758177) -* 这篇文章[在 Reddit 上](http://www.reddit.com/r/programming/comments/iod09/google_is_built_using_tools_you_can_use_too/) -* [OpenGSE 发布](http://google-opensource.blogspot.com/2009/01/opengse-released.html)-*开放源代码爱好者可能感兴趣的是最近发布的 Open Google Servlet Engine（OpenGSE）。 以前，Google 内的工程师开发了自己的快速，轻量级的 servlet 引擎，我们在 Google 内部将其简称为“ Google Servlet 引擎”或 GSE。* -* 在 Quora 上： *[谷歌的软件基础设施是否已过时？](http://www.quora.com/Google/Is-Googles-software-infrastructure-obsolete)* TLDR：不。 Hector Yee 有一个很好的总结：*与开放源代码变体相比，Google 基础结构要稳定得多，而且文档也要好得多。 他们作为一个整体工作在一起。 在 Google 框架中构建稳定，可大规模扩展的系统要比使用等效的开源工具容易得多。* 另一方面，采用定义的做事方式很容易对大公司施加的限制感到不满。 这两个观点都是正确的。 -* [jQuery vs 闭包](http://news.ycombinator.com/item?id=2758317)上的 nostrademons：基本上每个 Google 产品都使用闭包。 *没有可比性-就网页浏览量，边缘情况和一般现实情况而言，Closure 比其他所有 JS 库都得到更广泛的使用。 我实际上认为他们填补了非常不同的领域。 JQuery 适用于主要是 HTML 但需要通过渐进增强而分层的其他交互功能的网站。 闭包适用于 JavaScript 应用，其中整个客户端基本上都是用 JavaScript 编写的。* -* RyanDScott 在[上解释了为什么 Google 内部没有使用 GWT](http://news.ycombinator.com/item?id=2760822) ：*闭包只是 JavaScript。 无需等待 GWT 团队构建所需的功能，也无需自己构建这些功能。 以我的经验，当我需要使用 GWT 进行最前沿的开发时，我最终为 JavaScript 函数编写了一堆包装程序，这使我想知道为什么我不使用 JavaScript 编写所有内容。 （就像我说的那样，GWT 库非常引人注目，并且在计划大型项目时，Java 对于某些人通常感觉更舒服。）* + * 当故障转移到该数据中心具有活动驱动程序和行程的视图的数据中心时，该数据中心中的任何服务都不知道发生了故障。 -## Related Articles + * 在故障恢复到原始数据中心时，驱动程序和旅行数据过时，这会带来糟糕的客户体验。 -* [从 Google+实验中学习：Stowe Boyd 的操作系统，平台，应用](http://www.stoweboyd.com/post/8129714757/learning-from-the-google-experiment-operating-system)。 *但是，我们正在迈向一个世界，在这个世界上，Google +的大多数基本元素将成为下一代 Android 版本的一部分，并且感觉像 Google+上的应用的东西实际上将是在未来的社交网站上运行的应用 操作系统。* +* **使其可测试**。 数据中心故障很少见，因此通常很难测试。 他们希望能够不断地衡量系统的成功，以便他们可以确信故障转移在发生时将成功。 -整个“前 Googler 认为您可以做得更好”的事情是如此虚假。 我在其他地方对此进行了评论，但是粗略地浏览一下他的主要批评就可以清楚地看出他对这些技术只有肤浅的知识： +### 流程 -“与 MessagePack，JSON 和 Hadoop 相比，协议缓冲区，BigTable 和 MapReduce 都是古老的，吱吱作响的恐龙。与快速而优雅的工具（如 jQuery 和 mongoDB）相比，GWT，Closure 和 MegaStore 之类的新项目速度慢，设计过度，Leviathans” +* 驾驶员进行更新/状态更改，例如，载客。 该更新是对调度服务的请求。 -真？ 实际上，这几乎都不是真的。 协议缓冲区和消息包在大小和效率方面几乎相同，协议缓冲区的文档更好，周围有更强大的社区。 您不一定会知道，如果只是在 MessagePack 网站上做一个表象（无疑是作者所做的），但是如果您实际更深入地使用这些技术，他们的主张是完全虚假的。 JSON 与协议缓冲区？ 好的，比较奇怪，但是首先 Google 到处都使用 J​​SON-他们可能是世界上最大的 JSON 用户。 协议缓冲区也比 JSON 小得多并且快得多。 Hadoop 与 BigTable？ 真的，你要去那里吗？ Hadoop 的整个历史是试图在性能方面赶上 BigTable 并尽可能地复制 BigTable 功能以获得功能之一。 Hadoop 的发展速度很快，但是我所看到的一切都表明 BigTable 的发展速度仍然更快。 +* 调度服务更新了行程的行程模型。 该更新将发送到复制服务。 -它会一直持续下去。 闭包的压缩比 JQuery 好得多。 最新版本的 JQuery 是否更快？ 可能，但这与新的快速，优雅的工具相比，这简直不是“ Leviathan”。 GWT 还执行*浏览器特定的构建*，这是 JQuery 无法触及的，并使它的 JavaScript 变得更小，更快。 MongoDB 当然很酷，但是您真的要把它与 BigTable 相提并论，这是唯一有意义的比较？ 真？ 这甚至不是一条值得走的路。 +* 复制服务将请求排队并返回成功。 -无论如何，仅仅因为有人在 Google 工作过并不意味着您应该坚持自己的每一个字。 这也不意味着他们对 Google 的每个项目都有深入的了解。 在那儿找到工作要容易得多。 还存在编写热门文章的问题。 这家伙的文章提出了一些疯狂的主张，旨在做到他们所做的一切：获取链接。 这是总的 BS，你们应该对 High Scalability 有更好的了解。 认真地说，你们这里有一些杀手 articles，但您不应该链接到这样的虚假信息。 +* 调度服务更新其自己的数据存储并将成功返回给移动客户端。 也可能会返回其他数据，例如，如果是 Uber 泳池旅行，则可能需要接载其他乘客。 -请注意，我在这场战斗中没有狗。 我不在 Google 工作，但我直接使用了其中大多数技术，包括通过大量使用 App Engine 间接地使用了 BigTable。 +* 在后台，复制服务对数据进行加密并将其发送到消息服务。 + +* 消息服务维护所有驱动程序的双向通道。 此通道与驱动程序用来与服务进行通信的原始请求通道分开。 这确保了正常的业务运营不会受到备份过程的影响。 + +* Messenger Service 将备份发送到电话。 + +* 这种设计的好处： + + * **应用程序已与复制延迟和故障**隔离。 复制服务将立即返回。 应用程序只需要进行廉价调用（在同一数据中心内）即可复制数据。 + + * **消息服务支持电话的任意查询，而不会影响正常的业务运营**。 可以将电话视为基本键值存储。 + +### 在数据中心之间移动 + +* 第一种方法是**在故障转移**上手动运行脚本，以从数据库中清除旧状态。 由于有人必须这样做，因此该方法具有**手术疼痛**。 由于可以一次或多次在多个城市进行故障转移，因此脚本变得太复杂了。 + +* 回想一下，它们的键值数据库中的键包含行程 ID 和版本号。 版本号曾经是一个递增号。 更改为**修改矢量时钟**。 使用**手机上的矢量时钟数据可以与服务器**上的数据进行比较。 任何因果关系违规都可以被发现并解决。 这解决了进行中的行程的协调问题。 + +* 传统上，已完成的旅行将从手机中删除，因此复制数据不会无限制地增长。 问题在于，当故障恢复到原始数据中心时，该数据中心将具有陈旧的数据，这可能会导致调度异常。 该修复程序在旅途完成时使用了特殊的[墓碑](https://en.wikipedia.org/wiki/Tombstone_(data_store))键。 该版本带有一个标志，指示旅程已完成。 当复制服务看到该标志时，它可以告诉调度服务该行程已完成。 + +* 存储旅行数据非常昂贵，因为它是 JSON 数据的加密大块。 完成的行程需要更少的存储空间。 可以将一个星期的已完成旅行与一个活动旅行存储在同一空间中。 + +### 确保 99.99％的可靠性 + +* 故障转移系统不断进行测试，以建立其正常工作以及故障转移将成功的信心。 + +* 第一种方法是各个城市的**手动故障转移**。 然后通过查看日志来查看还原和调试问题的成功率。 + + * **高手术疼痛**。 每周手动执行此过程无效。 + + * **糟糕的客户体验**。 对于少数未能正确恢复的行程，必须调整票价。 + + * **低覆盖率**。 一次只能测试几个城市，并且由于某些问题仅针对特定城市，这可能是由于具有特定于城市的新功能所致，这些错误将被忽略。 + + * **不知道备份数据中心是否可以处理负载**。 有一个主数据中心和一个备用数据中心。 即使它们的配置相同，您如何知道备份数据中心可以解决雷电群问题，即故障转移时发生的大量请求。 + +* 为了解决这些问题，他们**研究了他们要测试的系统中的关键概念**。 + + * **确保调度服务中的所有突变实际上都存储在电话中**。 例如，司机接客后可能会失去连接，因此复制数据可能不会立即发送到电话。 需要确保最终将数据发送到手机。 + + * **确保可以将存储的数据用于复制**。 例如，是否存在任何加密/解密问题。 在合并备份数据时是否有任何问题？ + + * **确保备份数据中心可以处理负载**。 + +* 为了监视系统的运行状况，诞生了监视服务。 + + * 服务每小时都会从调度服务中获取所有活动驾驶员和行程的列表。 对于所有驱动程序，消息服务用于获取复制数据。 + + * 然后比较数据以查看数据是否符合预期。 这产生了许多良好的健康指标，例如失败的百分比。 + + * 按地区和应用程序版本划分指标对于查明问题有很大帮助。 + +* **影子恢复**用于测试备份数据中心。 + + * Monitoring Service 收集的数据被发送到备份数据中心以进行影子恢复。 + + * **成功率**是通过使用 Dispatch Service 查询和比较来自主数据中心的快照与活动的驱动程序和来自备份数据中心的行程的数量来计算的。 + + * 还计算了有关备份数据中心如何处理负载的指标。 + + * 这种方法可以解决备份数据中心中的任何配置问题。 + +## 相关文章 -亚当（Adam），很难想象有人在 Google 交付了一个重要的项目，但不值得他们对自己的经验发表意见。 我们必须对此表示不同意见，但是我非常感谢您和您对这两个堆栈的比较，非常有见地，谢谢。 +* [关于 Hacker News 3](https://news.ycombinator.com/item?id=10446835) / [关于 HackerNews](https://news.ycombinator.com/item?id=10253158) / [关于 HackerNews 2](https://news.ycombinator.com/item?id=10271850) / [关于 reddit](https://www.reddit.com/r/programming/comments/3mp4al/uber_goes_unconventional_using_driver_phones_as_a/) +* [数据服务与 Uber 搭便车](https://www.youtube.com/watch?v=Dg76cNaeB4s) -真的很不错，感谢您发布！ +我在职业生涯中花费了大量时间来构建可在对等数据库上运行的应用程序，因此我看到了这种好处。 文章未涉及的一件事是，在多大程度上使用手机上的本地数据可以对开发人员提高生产力。 -前端没有 GWT 吗？ +数据字段可以由应用添加，而无需在客户端/服务器/数据库堆栈之间协调架构。 对等同步在开发环境中也很方便，因此您的手机可以“修复”在开发笔记本电脑上运行的数据中心。 这样，您可以从云中的真实数据中心加载数据，重建应用程序，并将其同步到工作台。 -是的，我已经在自己的 Google+上工作了。 我不会邀请任何人！ 穆哈哈哈... +一旦接受了点对点数据模型，许多拓扑选择就会成为后期绑定。 数据可以根据需要进行分配。 这带来了各种开发和部署灵活性，例如此处所述的故障转移弹性。 -托德（Todd）：作为“最早”出现在前五名站点中的人和作为仍在其市场中处于领先地位的类别站点的唯一启动者，我建议您不要在您从中看到的“前-”观点中投入过多的股票 我认为这些“观点”没有任何值得注意的见解。 *创造*改变游戏规则的技术和从稀薄空气中获得的技术之间的区别很大，而仅仅是在非常引人注目的平台上展示和发布某些东西。 上面对“前 Google 员工”的反驳表明，事实胜过权威，而您现在可能已经发现，并不是每个“老朋友”都是天才 +很好，因此它们不仅是螺丝刀，而且现在也减轻了他们的能源和存储负担。 要走的路，布伯。 -基于权威的论点，提议不听某人大规模交付了复杂且极富创新性的产品，因为它与公认的权威冲突，这是一种令人愉快的策略。 做得好。 +这种方法不是新方法，也无法解决任何问题。 +如果您的数据中心无法处理故障转移，则不妨锁上办公室的门并扔掉钥匙。 -对不起，托德，但由于您已经形成了意见而拒绝接受这样精心撰写的批评/评论，同样令人愉快（使用您的术语）。 从您对亚当评论的回应中，我认为您甚至都没有读过它。 我每天都使用 GWT，将 jQuery 与之比较是可笑的……只是举一个例子。 +一旦计划好行程，很明显电话必须具有离线数据，以确保驾驶员到达目的地不会有问题。 这里的假设是数据中心可能会发生故障，但是设备呢？ 到处都是死区，当您输入死区时，您的设备将没有数据，因此如果没有离线数据，您将陷入死水。 -我了解猛烈抨击 Google 会产生网页点击量（IMO，这就是为什么这位前 Googler 的帖子得到博客作者如此广泛的报道），并且批判性地分析优势/劣势始终是一件好事，但请保持客观。 +与其花时间和精力来想出这种方案，不如研究如何构建坚如磐石的 DC 更好。 -Sekhar，所以您认为我什至不应该链接到它？ 如果您注意到我在帖子的内容上什么也没说，只是质疑那些技术是否可以扩展。 批评甚至涉及到该职位。 那是你的错吗？ \ No newline at end of file +客户体验的这场革命不仅为客户带来了新的便利，而且被证明是一种成功的商业模式。 例如，Uber 已经从仅在旧金山运营，发展成为全球发展最快的企业之一。 您现在可以在 35 个国家/地区“购物”。 同样地，像 Lyft 这样的竞争对手似乎也通过这种新生的客户体验剧变而朝着世界统治方向发展。 \ No newline at end of file diff --git a/docs/178.md b/docs/178.md index 1cdcf9f..617953c 100644 --- a/docs/178.md +++ b/docs/178.md @@ -1,65 +1,181 @@ -# ATMCash 利用虚拟化实现安全性-不变性和还原 +# 在不到五分钟的时间里，Facebook 如何告诉您的朋友您在灾难中很安全 -> 原文： [http://highscalability.com/blog/2011/7/11/atmcash-exploits-virtualization-for-security-immutability-an.html](http://highscalability.com/blog/2011/7/11/atmcash-exploits-virtualization-for-security-immutability-an.html) +> 原文： [http://highscalability.com/blog/2015/9/28/how-facebook-tells-your-friends-youre-safe-in-a-disaster-in.html](http://highscalability.com/blog/2015/9/28/how-facebook-tells-your-friends-youre-safe-in-a-disaster-in.html) -*这是 ATMCash 技术负责人 [Ran Grushkowsky](/cdn-cgi/l/email-protection#6210030c052203160f0103110a4c010d0f) 的来宾帖子。* +![](img/85230d9f3f018016ed7b6b3de14d1500.png) -虚拟化和基于云的系统在业界非常受欢迎。 但是，大多数金融公司偏离了这些解决方案。 在 ATMCash，我们采用虚拟化的原因并非出于可扩展性的通常原因，而是出于通常错过的安全性价值。 +*这是文章更新： [Facebook 的安全检查如何进行](http://highscalability.com/blog/2015/11/14/how-facebooks-safety-check-works.html)。* -在本文中，我将介绍虚拟化利用中安全性增值的概念，以及为什么人们应该考虑为这些用例部署小型云。 +在灾难中，迫切需要立即了解您所爱的人的安全。 在 9/11 期间，我有这种感觉。 我知道在我们地区的下一场野火中，我会有这种感觉。 我生动地记得在 [1989 年洛马普里埃塔地震](https://en.wikipedia.org/wiki/1989_Loma_Prieta_earthquake) 期间的感觉。 -## 虚拟机如何帮助减轻风险？ +大多数地震都没有引起注意。 不是这个，每个人都知道。 在计算机实验室中，天花板不再像雪花一样飘落下来之后，我们确信建筑物不会倒塌，所有想法都转向了亲人的安全。 就像其他人必须拥有的一样。 拨打电话几乎是不可能的，因为电话从全国各地涌入湾区，所以所有电话线都很忙。 信息被卡住了。 由于电视显示出持续不断的死亡和破坏，许多无聊的时光被浪费了。 -我敢肯定，您中的大多数人都听说过金融行业中最近发生的[黑客攻击。 金融公司一直在不断地进行黑客攻击，因此安全性至关重要。 系统部署中最大的风险之一是堆栈组件之一的损坏。 定期的系统修补程序和维护修复了已知的漏洞利用和问题，但是，有时可能为时已晚，并且该组件已被破坏。 如果系统已经在将补丁程序应用于现有系统的自然环境中遭到破坏，则有时补丁程序可能来得太迟，并且已经注入了特洛伊木马或某种恶意代码（如最近的案例所示） 。 虚拟机提供了一个伟大的隐藏宝藏：**不变性和还原映像**。](http://www.latimes.com/business/la-fi-citibank-hack-20110609,0,2504101.story) +25 年后的今天，我们还能做得更好吗？ -## ATMCash 如何将这些功能用于堆栈中的安全性的示例： +Facebook 可以。 通过名为 [安全检查](https://www.facebook.com/about/safetycheck/) 的产品，该产品在灾难期间将亲朋好友联系在一起。 发生灾难时，“安全检查”会提示该地区的人员指示他们是否还可以。 然后，Facebook 通过告诉他们的朋友们如何做来结束担忧循环。 -我们的堆栈包含三个主要组件：前端，后端和数据库。 +[Facebook 工程师经理 Brian Sa](https://www.linkedin.com/pub/brian-sa/2/7a7/a3b) 根据 2011 年日本福岛 [毁灭性地震的经历创建了安全检查](http://www.telegraph.co.uk/news/worldnews/asia/japan/8953574/Japan-earthquake-tsunami-and-Fukushima-nuclear-disaster-2011-review.html) 。 他在@Scale 发表的演讲中讲述了自己的故事，这是他感人至深的故事。 -我们的机器正在运行 VMWare vSphere。 我们已经决定为前端组件安装 4gb / ram 64gb / SSD 服务器。 具有 16gb / ram 的更强大的服务器（用于我们的后端组件）以及具有用户 ID 分片和复制功能的专用 MySQL 数据库服务器。 我们的虚拟机正在运行 CentOS 的修改版本。 我们学会了以相对快速的修补周期和易于修改的配置来喜欢 CentOS。 +地震期间，布莱恩（Brian）在 Facebook 上张贴了一条标语，提供了有用的信息来源，但他被感动找到了一种更好的方式来帮助有需要的人。 那一刻成为安全检查。 -前端和后端是随每个版本更改的静态组件，而数据库是唯一随时更改的动态组件。 我们利用静态特征来增强我们的安全性，并消除感染后被感染的系统受到修补的风险。 +我对安全检查的第一反应是该死，为什么以前没有人想到这个？ 这是一个强大的主意。 -我们拥有尚未部署的每个系统组件的最新映像，但是会不断对其进行修补和更新以反映最新的安全风险。 然后，我们将对该映像进行任何软件更新，并用新更新和修补的映像替换运行中的映像。 通过安装负载平衡器，我们在整个过程中不会停机。 我们通过关闭一台计算机来逐一替换虚拟机，而负载平衡器将流量引向运行中的计算机，并重复该过程，直到所有虚拟机都被替换为止。 交换图像的过程通常每个过程少于 30 秒。 VMWare vSphere 具有一些强大的功能，这些功能使动态替换映像变得非常容易。 这是一个相对较快的重新部署过程。 +当我听 [相同视频](https://www.youtube.com/watch?v=ptsCWGZW_P8) 和 [Peter Cottle ]](https://www.linkedin.com/pub/peter-cottle/a/961/387) ，Facebook 的软件工程师，他还谈到了建筑安全检查。 -## 我们如何使用不变性来提高安全性的示例： +可能只有 Facebook 可以创建安全检查。 此观察与 Brian 在演讲中的主要课程很好地吻合： -在 ATMCash，我们的客户服务和呼叫中心在内部进行处理。 我们还将客户的安全和隐私视为最高优先事项。 为了进一步保护客户，我们开发了自己的 CSR（客户服务代表）系统，该系统利用了各种安全级别。 其中之一是虚拟机的不变性功能。 每个 CSR 工作站都在运行一个主 VM 映像的副本，该副本是不变的（无法修改，并且在每次重新引导后将被重置）。 +* **以只有您可以** 的方式解决实际问题。 与其走传统路线，不如想想您和您的公司可以扮演的独特角色。 -以这种方式部署工作站可提供至关重要的安全级别，以保护我们的系统免受可能进入工作站的恶意代码的侵害。 如今，病毒和恶意脚本以各种方式传播。 从电子邮件附件到 Word 文档，它们无处不在。 如果您认为制定一项政策来指示员工不要从可移动驱动器中加载个人文档，或者甚至限制对社交网络的 Web 访问将消除这种风险，那么事实证明您是错误的。 您应始终假定恶意脚本会找到通往您工作站的路径，并且您的防病毒软件很可能不会检测到它。 使用每次重新启动都会重新启动的不可变映像，不仅提供了更高的安全性，而且还提供了应用补丁程序和在整个系统范围内更新（仅更新一个映像）的能力。 +只有 Facebook 可以创建安全检查，不是因为您可能会想到资源，而是因为 Facebook 允许员工进行诸如安全检查之类的疯狂事情，并且因为只有 Facebook 拥有 15 亿地理分布的用户，而他们之间只有一定程度的分离 4.74 条优势，只有 Facebook 拥有狂热于阅读新闻源的用户。 稍后再详细介绍。 -## 为什么 ATMCash 有自己的私有云而不使用现有的基础架构： +实际上，Peter 在 Facebook 的产品开发 Catch-22 中谈到了资源是如何成为问题的。 安全检查小组很小，没有很多资源。 他们必须先构建产品并在没有资源的情况下证明其成功，然后才能获得构建产品的资源。 必须在不花费大量金钱和资源的情况下大规模有效地解决该问题。 -我们得到了很多问题，答案很简单。 我们从事货币业务，我们需要特别注意客户的信息。 这是真的; 部署自己的小型云的成本比利用任何现有基础架构要高得多，但是安全性的附加价值是无价的。 +通常情况下，约束条件导致了一个明智的解决方案。 一个小的团队无法建立庞大的管道和索引，因此他们编写了一些骇人听闻的 PHP 并有效地大规模完成了这项工作。 -此外，借助戴尔和其他零件制造商提供的财务计划，如果您将付款分散到各处，则您只需支付云服务的费用即可。 价格比较：使用 Rackspace 拥有 10 台 4gb 和 200gb 上/下的 Linux 服务器，每月将花费$ 1804。 在您自己的微型云上使用戴尔服务器配置可比较的服务器，服务器硬件的费用为每月 105 美元，网络配件的费用为每月 400 美元，VMWare 许可的费用为 600 美元/月，数据中心费用可能有所不同，但大约为 400 美元/月。 +那么 Facebook 如何建立安全检查？ 这是我对 Brian 和 Peter 的演讲的掩饰： -最重要的是，您必须维护设置，并且任何可伸缩性都需要购买和设置更多节点。 $ 1505 /月，之前员工维持固定成本的费用略高，但是，特别是在安全方面所享有的收益不容错过。 +* 您可以将 Facebook 视为这种巨大的原始汤。 数十亿人使用 Facebook，随着时间的流逝，各种行为开始浮出水面，有些趋势在不断蔓延。 -## 发生停机时如何处理对帐问题？ + * 一个病毒性的例子是用户如何开始将自己的个人资料图片更新为红色的平等标志，以表示婚姻平等。 -处理金融交易时，不能选择停机。 因此，虚拟化非常重要，而负载均衡器对于任何虚拟化环境都至关重要。 我们设计的系统具有极高的冗余性。 堆栈的每个部分都被复制并旨在处理停机时间。 我们在本地数据中心级别使用物理负载均衡器设备（也执行 SSL 握手）在 DNS 级别使用负载均衡器。 一旦一个组件发生故障，负载均衡器将自动将流量定向到其克隆节点。 + * 在支持下，Facebook 建立了 Rainbow 覆盖工具，使使用个人资料图片进行交流变得更加容易。 这种做法最早起源于 Facebook。 在发明状态消息之前，用户将更改其个人资料图片以传达其当前的时代精神。 -我们使用批处理更新执行大量数据处理，在此我们将重要更新作为增量更新，小的增量更新进行提交，从而无需更新整个数据集。 您只需更新所需的小更改。 例如，提款或大量资金需要立即在整个系统中进行更新以反映余额，但是，交易历史记录的优先级较低。 当在 ATM 级别上发生负载时，请求正在通过我们的系统，以确保交易有效。 + * 轻松自定义个人资料图片**的采用率提高了 1000 倍**。 -交易获得批准后，我们​​将对前端数据库执行增量更新以反映该交易。 然后，我们将触发不同的过程，以警告客户该交易，更新其界面并执行安全性速度检查（检查以确保我们的客户卡的安全性不会被盗）。 +* 这使他们有了 **的概念，使人们在灾难中更容易告诉朋友他们还可以** 。 -当大多数数据作为批处理时，系统将处理关键更新，例如增量更新。 批处理更新的本质是海量数据与增量更新的完整汇总，增量更新仅包含已修改的数据。 为确保整个系统中数据的完整性并允许更快的更新，我们将增量更新用于流水线更新和批处理更新，其中还包括更多对数据完整性检查而言不重要的数据。 迄今为止，由于批量更新不会阻塞系统，因此我们可以安全地使用增量更新来扩展规模，而不会影响系统的稳定性或性能。 + * 在灾难期间，人们会更新状态，说他们还可以。 -## 总结一下： + * 这不是让人们知道您还可以的问题的理想解决方案。 -如果安全性是您业务中不可或缺的一部分，就像 ATMCash 处的业务一样，那么您应该利用虚拟机的附加安全性功能。 您将学习到它所提供的灵活性以及您的版本始终是“无恶意软件”的，让您高枕无忧。 + * 它不是很结构化。 双向都有问题，告诉人们您没事的方向，而您的朋友得到您没事的信息。 -关于公司： [ATMCash.com](http://atmcash.com/) 成立于 2005 年，是全球支付平台和在线汇款服务，服务于 150 多个国家/地区。 使用预付费借记卡代替了传统的基于第三方代理的模型和银行电汇。 没有银行帐户的接收者可以从全球超过 150 万台 ATM 机中提取资金。 [ATMCash.com](http://atmcash.com/) 通过为客户提供更多控制，省心和省钱的方式，改变了人们转移资金和向自由职业者付款的方式。 + * 首先，不是所有的朋友都能看到此更新。 -[](http://payment.atmcash.com/) + * 第二，用户无法获取受灾难影响的所有朋友的名单。 -Centos 和 VMWare 的安全性？ 请查看最近十年影响 VMWare 的漏洞列表，并且不要忘记研究 CentOS 开发人员社区的规模和内部流程。 -将结果与其他虚拟化系统和其他 Linux 发行版进行比较。 请。 + * 在灾难状态通知问题上应用更加结构化的思想导致 [安全检查](https://www.facebook.com/about/safetycheck/) 。 -嘿，巨魔，你为什么不以那种傲慢，模棱两可的态度停下来，并谈谈具体细节。 显示影响 ESXi4.1 的单个报告的未修补 VMWare 漏洞 -与 CentOS / RedHat / Scientific / OEL 相同。 +* 工作原理： -非常有趣，谢谢！ + * 如果您身处灾区，Facebook 会给您发送推送通知，询问您是否还可以。 （关于灾难发生的时间由谁决定什么也没说）。 -花旗银行《洛杉矶时报》的故事链接已断开。 他们可能将链接更改为此 http://www.latimes.com/business/la-fi-citigroup-hacking-20110617,0,1445324.story \ No newline at end of file + * 轻按“我很安全”按钮表示您很安全。 + + * 通知所有朋友您安全。 + + * 朋友还可以查看受灾影响的所有人员及其生活状况的列表。 + +* 您如何在特定区域中建立受灾难影响的人员群体？ 建立地理索引是显而易见的解决方案，但是它有缺点。 + + * 人们在不断移动，因此索引会过时。 + + * 拥有 15 亿人口的地理索引非常庞大，并且会占用很多他们没有的资源。 请记住，这是一个很小的团队，没有大量资源来尝试实施解决方案。 + + * 该解决方案应该始终在发生事件时才起作用，而不是一直保持活动状态很少使用的数据管道。 这要求能够进行动态 **动态即时** 查询。 + +* 解决方案 **利用社交图的形状及其属性** 。 + + * 如果发生灾难，例如尼泊尔的地震，则在每个新闻提要负载 中都会打开 **安全检查钩。** + + * **人们检查其新闻提要时，挂钩将执行**。 如果检查新闻源的人不在尼泊尔，那么什么也不会发生。 + + * 当尼泊尔某人查看其新闻时，就是发生魔术的时候。 + + * 安全检查 **在社交网络上向所有好友** 狂热。 如果朋友在同一地区，则将发送推送通知，询问他们是否可以。 + + * **该过程保持递归重复** 。 对于在灾区找到的每个朋友，都会派出工作来检查他们的朋友。 通知根据需要发送。 + +* 实际上，该**溶液是** **非常有效的**。 因为该算法能很快地找到人，所以产品体验让人感到实时和即时。 例如，同一房间中的每个人似乎都会同时收到他们的通知。 为什么？ + + * 使用新闻提要会给用户提供**随机抽样，偏向于最活跃的用户** **和最多的朋友**。 并且它过滤掉不活动的用户，这是数十亿行不需要执行的计算。 + + * **图是密集且互连的** 。 [六度凯文·培根](https://en.wikipedia.org/wiki/Six_Degrees_of_Kevin_Bacon) 是错误的，至少在 Facebook 上是这样。 Facebook 的 15 亿用户中，任意两个用户之间的 **平均距离为 4.74 边缘** 。 抱歉，凯文。 拥有 15 亿用户，整个图表可在 5 跳内进行浏览。 通过遵循社交图谱可以有效地联系到大多数人。 + + * 使用社交图谱方法免费提供了 **许多并行性** 。 可以将好友分配给不同的计算机并进行并行处理。 他们的朋友一样，依此类推。 + +* **竞争条件成为问题的解决方案** 对解决方案的分布式性质造成了影响。 + + * 两个不同数据中心中的两台机器的用户与同一个人成为朋友。 这意味着要遍历两个边缘，最终会向同一个人发送两个通知。 + + * 认为这没什么大不了的，但实际上，用户发现在灾难情况下获得多个通知确实压力很大。 用户认为如果他们同时收到两个通知，他们一定会遇到麻烦。 而且，您也不希望与安全相关的项目在灾难中感到车祸。 + + * 数据库用于存储状态，因此只有一台计算机可以检查用户。 问题是当您有多个数据中心时，例如在欧洲一个在美国，一个在美国，则传播延迟使确定用户是否正在处理的时间过长。 + + * 为两层解决方案添加了内存中锁定结构。 检查内存中锁定，如果为用户设置了该位，则该用户的作业将中止。 + +* 最大的产品推出是针对尼泊尔地震。 + + * 在不到 5 分钟的时间内，邀请了 300 万人发表他们的身份。 尼泊尔的人口太多，因此要检查 10 亿行。 + + * **在大约 5 分钟内浏览了 Facebook 用户群的 2 / 3rd** 。 + +* 在构建安全检查的第一个版本时遇到一些问题。 + + * 台式机，移动网络和本机应用程序的碎片化在跨多个平台管理内容，功能和操作方面造成了极大的复杂性。 + + * 想要个性化需要手动编码的内容，该编码缓慢，乏味且容易出错。 + + * 当系统仅在紧急情况下处于开机状态时，很难判断它是否在紧急情况下可以正常工作。 + + * 那么，为了构建一个跨平台但仍然可以本地响应的系统，应该采用哪种客户端-服务器模型？ 如何包含动态内容？ 如何测试系统以确保其可靠性？ + +* 选择让服务器负责文本和图像以及配置信息。 客户端将预取数据，处理实时失效，并本地响应客户端事件。 + +* 实时失效。 + + * 每当您处理预取的数据时，务必指定该数据应何时过期。 例如，如果用户打开该应用程序并上传了一些数据，则他们关闭该应用程序并仅在几天后打开它。 如果上载的数据是选举公告，则如果选举通过，则用户不应看到该公告。 + + * TTL（生存时间）参数告诉客户端在需要刷新数据之前可以使用数据多长时间。 + + * 交互计数指示用户可以与数据交互多少次。 + + * 更多可选的过滤器，例如：remaining_battery_percentage，如果设备电量不足，它将告诉客户端不要向用户显示消息。 + +* 强制执行内容限制 + + * 指定文本中的最大行数不是一个好主意。 字符串翻译成其他语言时，可能会急剧增长。 + + * 不同的平台和设备具有不同的屏幕尺寸，因此一个固定的限制无效。 + + * 因此，请在服务器上定义内容长度限制，并内置一个缓冲区以应对较长的翻译。 + +* 动态内容 + + * 这样可以对安全检查消息进行个性化设置，例如在文本中插入用户名。 + + * 提出了一种语言，例如邮件合并，以指定诸如“危机名称”和“危机 URL”之类的替代词。 + +* 正缓存 + + * 您记得以前符合资格的单位 + + * 安全检查是与用户保持固定通信渠道的设备类型。 对于事件持续时间，没有视图限制。 如果在星期五将其打开，则将持续交付直到星期五将其关闭。 + + * 正向缓存有利于长期运行的单元，因为您无需评估任何单元的资格。 您确实需要检查缓存单元的资格，因为您不想显示它超出预期的时间。 + +* 负缓存 + + * 您记得没有单位合格的地方。 + + * 琥珀色警报是一次性消息。 这种类型的设备的负载曲线确实不同。 例如，如果它是在上午 8:50 开启的，那么在上午 9:00 之前它已经达到峰值投放，然后衰减很快。 一小时内达到了一半的人，三小时内几乎达到了所有目标受众。 + + * 负缓存有利于短期运行的单元，因为在大多数情况下，没有可显示的单元。 负缓存记住了这一事实。 + +* 黑暗发射 + + * 使用实时流量测试了系统，以发现意外问题。 使用了一个标志使它对用户隐藏，因此不会对用户造成影响。 + + * 运行测试 24 小时发现了一些意外问题。 产生社交句子的子系统之一的容量不足。 + +* 终止开关 + + * Facebook 由数百个联锁系统组成。 + + * 有时，在发生灾难性故障的情况下，您需要快速减轻负载。 + + * Kill 开关使您可以完全关闭整个系统。 您还可以杀死特定的应用程序版本或设备。 + +## 相关文章 + +* [上 reddit](https://www.reddit.com/r/tech/comments/3mq29e/how_facebook_tells_your_friends_youre_safe_in_a/) \ No newline at end of file diff --git a/docs/179.md b/docs/179.md index 69938a5..84ddac6 100644 --- a/docs/179.md +++ b/docs/179.md @@ -1,353 +1,57 @@ -# TripAdvisor 架构-4,000 万访客，200M 动态页面浏览，30TB 数据 +# Zappos 的网站与 Amazon 集成后冻结了两年 -> 原文： [http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html) +> 原文： [http://highscalability.com/blog/2015/10/7/zapposs-website-frozen-for-two-years-as-it-integrates-with-a.html](http://highscalability.com/blog/2015/10/7/zapposs-website-frozen-for-two-years-as-it-integrates-with-a.html) -![](img/f5d73e9a698265918ca5768397e905ed.png) +![](img/b908cf9bfa36156bb782deeaf588ff49.png) -*这是 TripAdvisor 工程部副总裁 [Andy Gelfond](http://www.linkedin.com/in/andrewgelfond) 的特邀帖子。 安迪（Andy）在 TripAdvisor 呆了六年半，在早期就写了很多代码，并一直在建立和运营一流的工程和运营团队，该团队负责全球最大的旅游网站。 史诗般的 TripAdvisor 更新：[上有此文章的更新：为什么不在云上运行？ 盛大实验](http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html)。* +这是来自 [Roger Hodge](https://twitter.com/rogerdhodge) 在《新共和国》中写的精彩而深刻的文章中的一个有趣的掘金： [Zappos 进行了一项激进的实验，以终止我们所知的办公场所](http://www.newrepublic.com/article/122965/can-billion-dollar-corporation-zappos-be-self-organized)： -对于 [TripAdvisor](http://en.wikipedia.org/wiki/TripAdvisor) 而言，可扩展性已渗透到我们组织的多个层次上-数据中心，软件体系结构，开发/部署/运营，最重要的是在文化和组织内部。 拥有可扩展的数据中心或可扩展的软件架构是不够的。 设计，编码，测试和部署代码的过程也需要可扩展。 所有这一切都始于招聘，一种文化和一个组织，该组织重视并支持复杂，高度可扩展的消费者网站的分布式，快速，有效的开发和运营。 +> Zappos 的面向客户的网站在过去几年中基本上被冻结，而该公司将其后端系统迁移到 Amazon 的平台上，这是一个多年项目，称为 Supercloud。 -## 截至 6/2011 的统计数据 +Zappos 的一个证明是，他们在冻结的网站上仍然卖得很好，而世界上大多数其他地区都采用了跨多个平台持续部署和不断发展的模型。 -* 每月超过 4000 万的唯一身份访问者（Comscore），2000 万成员，4500 万评论和意见 -* 超过 29 种销售点，20 种语言 -* 我们的移动产品可在 iPhone，iPad，Android，诺基亚，Palm 和 Windows Phone 上使用，每月吸引 1000 万用户 -* 每天超过 200M 个动态页面请求，而所有静态资源（例如 js，css，图像，视频等）都通过 CDN 进行服务 -* 每天执行超过 2.5B 的分布式操作（服务，数据库，内存缓存），以满足页面请求 -* 每天流式传输超过 120GB 的日志文件（压缩） -* Hadoop 上 30 TB 的数据，预计明年初将达到 100 TB-每天修补程序，以“需要今天退出”功能/修复 -* 从来没有计划过停机时间，正常运行时间接近 4 9 -* 在北京单独部署以支持 daodao.com -* 每周发布周期，每天发布“补丁”。 开发周期可以是一天，可以是一周，可以是一个月 -* 超过二十个小型团队（略多于 100 名工程师）一次处理 50 多个同步项目，每周部署 20-30 个项目 -* 团队包括：搜索引擎营销（SEM），搜索引擎优化（SEO），内容管理，客户关系管理（CRM），移动网络，移动应用，社交网络（FB），酒店，餐厅，论坛，旅行清单，视频平台，航班，度假租赁，企业列表，内容分发，API，中国 ，亚太地区，销售和营销活动，数据中心运营，开发运营，分析和仓储，质量检查 +亚马逊要求采取此举，否则 Zappos 这样的公司可能会对这种深度整合的隐含对[康韦定律](https://en.wikipedia.org/wiki/Conway%27s_law)敏感。 请记住，据报道 Facebook 正在保持 WhatsApp 和 Instagram [独立](http://techcrunch.com/2014/02/19/facebook-buying-whatsapp-for-16b-in-cash-and-stock-plus-3b-in-rsus/)。 停止世界计划必须意味着某些事情，不幸的是，我没有战略眼光来理解为什么会这样。 有什么想法吗？ -## 一般建筑 +本文提供了有关此举的更多诱人细节： -* 开源 Linux，Apache，Tomcat，Java，Postgres，Lucene，Velocity，Memcached，JGroups -* 保持非常简单-易于构建，调试，部署，维护和操作 -* 非常简单的无状态 Web 服务器库，运行简单的 Java 和 Velocity 模板 -* 每个“功能”区域（媒体，成员，评论，旅行清单等）都打包为服务 -* “服务”库-每个服务都是针对总体性能进行优化的高级，面向业务的 API -* 假设事情失败了。 集群中有大量节点（Web 服务器，服务机），或者具有真正的 N + 1 冗余（数据库和数据中心本身） +> 同时，将 Zappos 的整个 IT 基础架构迁移到亚马逊-这意味着要想出一种方法，将一套极为复杂的自定义软件程序移至每年 10 亿美元的电子商务网站上 全新的环境-继续。 **这项工作的难度几乎无法想象。** 想象一下，拿一百万平方钉并试图将其插入一百万个圆孔中，除非您甚至都不知道是否所有的孔都存在，或者孔可能位于何处，并且您必须协商访问这些孔的方式 与数十个不同的敌对软件工程师团队。 该项目已经消耗了 Zappos 的技术部门超过两年的时间，在此期间，Zappos 站点几乎是完全静态的。 这意味着**没有任何改进或创新，并且仅修复了最少的错误**。 +> +> 该项目的项目经理 Barry Van Beek 告诉我，他认为 Supercloud 是历史上最大的电子商务重组。 “以前没有人尝试过如此大规模。” 曾在 Zappos 待了八年的 Van Beek 说 **Supercloud 有大约 20 个不同的团队，包括承包商的 250 至 350 人，与 100 多个不同的 Amazon 团队合作。** 当他们开始时，他们不知道自己正在进入什么。 花了几个月的时间弄清楚了亚马逊方面的可用功能，并且在一年多的时间里，Van Beek 甚至不确定迁移在技术上是否可行。 但是，他说， **Supercloud 是亚马逊规定的目标**，他们别无选择。 所以他们想通了。 他说：“努力的程度几乎是难以理解的。” +> +> Van Beek 告诉我，他相信 Supercloud 可以完成，但他担心该报价造成的中断以及亚马逊方面的不可预见的延误会减缓其进展。 当 Zappos 确实完成迁移时，他希望技术部门能够将其注意力转移到电子商务领域的创新上，以解决诸如尺寸和装配问题之类的挑战。 **如果客户在订购之前更有可能达到理想的状态，则消除退货以及相关的进货和运输成本将提高利润。** -## 控制流程 +我同意这个项目是疯狂的，这就是为什么我永远不会建议这样做的原因。 我认为它们可以确定推动成功的关键业务流程（例如大约 50 个），并弄清楚如何使用现有的 Amazon 基础架构来实现它们。 然后进行一次大的丑陋转换。 -* 控制流程非常简单：解析请求 URL，从各种服务中收集内容，然后将其应用于模板。 -* 我们的 URL 结构经过深思熟虑，即使在重新设计网站和重构代码的情况下，也能保持很长一段时间的稳定性。 -* 请求通过负载平衡器路由到 Web 服务器。 请求是在基于 cookie 的“池”（服务器的集合）中随机分配的。 池用于部署管理和 A / B 测试。 请求本质上是无状态的-浏览器 cookie 中存储着“会话”信息。 登录的用户将从数据库中获取其他状态。 -* Java servlet 解析 url 和 cookie 信息并确定所需的内容，从而调用各种服务。 服务 API 定义为 Java 接口，而 Servlet 会发出 0 到十几个服务请求。 服务呼叫通常需要 2 到 15 毫秒。 服务调用通过具有可重试逻辑的软件负载平衡器进行，该逻辑可基于每种方法进行定义。 -* 每个服务都具有针对业务和/或使用模式进行了优化的 API，例如，获取成员的评论或位置的评论。 大多数服务本质上是数据库前面的大型智能缓存，例如，局部 LRU，内存缓存，数据库调用在内存部分树/图中。 Jgroups 有时用于在需要时使缓存保持同步。 大多数服务在不同的共享/物理计算机上运行 4 个实例，有时为服务实例分配自己的计算机。 -* 从服务调用返回的内容集经过处理，并由 Java 代码组织成对象集，这些对象集传递给 Velocity 模板（有点像弱 JSP） -* 有多种逻辑可根据上下文选择不同形式的 Servlet 和/或 Velocity 模板，其中可能包括 POS，语言，功能等。还有用于选择 A / B 和其他代码的不同代码和模板路径的基础结构 测试 -* 我们的 Web 服务器排列在“池”中，以允许进行 A / B 测试并控制部署。 我们的每周发布过程将部署到一个小型池中，并让代码运行几个小时，以确保在部署到所有池之前一切正常 +失去的销售绝不会造成该项目成本的损失。 -## 科技类 +另一件事让我印象深刻……这与人们一直希望人们在其界面和所处理的功能中*希望*不断变化的信念形成强烈反差。 我从没想过对消费者如此，对 B2B 软件也是如此。 如果我是一个有钱的人，并且负责一家公开 B2C 公司，那么我会仔细研究这个示例-所有未花费的费用都将落在底线。 -* BigIP 冗余对，Cisco 路由器 -* 64 个无状态 Web 服务器，运行 Java servlet 的 Linux / Apache / Tomcat，每天处理 200M +请求的库 -* 40 台运行约 100 个实例的无状态服务机（约 25 个服务实例），Jetty / Java，每天处理 700M +个请求 -* Postgres，在 6 对（DRDB）机器上运行，每天处理 700M +次查询 -* Memcached，3 个独立的群集，运行在 350GB 以上的 Web 服务器上。 Spy Memcache 客户端的可配置池-异步，NIO 以扩展请求。 进行了优化和其他更改以监视 java 客户端以实现规模和可靠性。 -* Lucene 包含在我们的服务基础结构中，拥有 5000 万个文档，55GB 索引，每天 8M 搜索，每日增量更新，每周一次完全重新生成。 -隐藏引用文字- -* 当没有其他选择时，JGroups 用于服务机之间的状态同步。 -* Hadoop，具有 192TB 原始磁盘存储的 16 个节点群集，192CPU，10GB 网络 -* Java，Python，Ruby，PHP，Perl 等用于工具和支持基础架构 -* 监视-仙人掌，nagios，自定义。 -* 两个数据中心，位于 N + 1 配置中的不同城市，一个以 R / W 模式接收流量，另一个以 R / O 模式同步通信，准备进行 24/7 故障转移，定期按季度交换活动数据 -* 每个数据中心总共约有 125 台计算机，所有标准 Dell 设备 -* 日志记录-120GB（压缩）应用程序日志，apache 访问日志，财务敏感数据的冗余日志记录-流式（记录）和非流式 +-XC -## 发展历程 +这样的项目只会在有钱烧钱的公司发生。 如果他们期望获得回报，我怀疑这种规模是否会平衡这十年。 听起来这似乎是 Bezos 的自我动机，而不是艰难的业务需求。 -* 满载的 Mac 或 Linux 计算机，SVN，Bugzilla，30 英寸显示器 -* 数以百计的虚拟化开发服务器。 每位工程师专用一位，按需提供其他服务 -* 每周部署周期-每个星期一都会发布整个代码库 -* 那些“今天需要离开”的人的每日补丁程序/修复 -* 大约 100 个工程师同时处理 50 多个并发项目，每周部署约 25 个 -* 工程师端到端地工作-设计，代码，测试，监控。 您设计一些东西，然后编写代码。 您编写一些代码，然后进行测试。 -* 工程师跨整个堆栈工作-HTML，CSS，JS，Java，脚本。 如果您不了解某些内容，则可以学习。 -* 发布过程在各个高级工程师和工程经理之间共享和轮换 -* 可用的测试框架多种多样：单元，功能，负载，烟雾，硒，负载和测试实验室。 它是您的代码，选择最适合您的代码。 -* 多种机制可帮助您提供最优质的功能：设计审查，代码审查，部署审查，运营审查 +我想 Zappos 会以与 Tony Hsieh 处理整个公司到 Holacracy 的转换相同的方式对待他们的计算基础架构的转换就不足为奇了，也就是说，这是一个很大的突破。 尽管显然托尼不愿意像在网站上那样“冻结公司”，但他们却想办法。 -## 文化 +我建议冻结网站以完成这种转换在很大程度上是想象力的失败。 即使他们现有的系统是单片的“一级”应用程序（就像亚马逊曾经的那样），也没有技术上的理由，他们不应该将其逐段转换到云平台上。 我的意思是，在现有代码中抛出“ if”语句以将某些服务调用的一部分发送到新系统，从而合理地安全地推出“转换后的”后端有多难？ “范贝克（Van Beek）甚至在技术上都不确定迁移是否可能”中出现的明显场面表明，也许他们选错了人。 不是“技术上可行的”吗？ 请。 我们在这里谈论的是在计算机上运行的代码，而不是光速旅行。 -* 与运行两个同时启动的新兴公司相比，TripAdvisor 的工程技术最好，它们都在同一代码库上运行，并且在一个通用的分布式计算环境中运行。 这些团队中的每个团队都有自己的业务目标，每个团队都有能力并对其业务的各个方面负责。 交付项目的唯一障碍是您，因为您应该在各个级别上工作-设计，代码，测试，监视，CSS，JS，Java，SQL，脚本。 -* TripAdvisor 工程是按业务职能组织的-有两个以上的“团队”，每个团队负责直接与他们的业务同行在 SEM，SEO，移动，商务，CRM，内容，社交应用程序，社区，成员资格，销售和营销解决方案上合作 ，中国，亚太地区，商家信息，度假租赁，航班，内容联合供稿等。 我们没有传统的架构师，编码员，质量检查人员 -* 我们的运营团队是一个团队，负责所有其他团队使用的平台：数据中心，软件基础架构，DevOps，仓储。 您可以将 Operations 视为我们的内部“ AWS”，将我们的 24/7 分布式计算基础架构作为服务提供，并且将代码/开发/测试/部署全部整合为一个。 该团队包括两名负责数据中心和软件基础架构的技术运营工程师和两名现场运营工程师。 -* 每个团队的运作方式都最适合其独特的业务和个人需求，我们的流程被形容为“敏捷后/混乱”。 -* 责任文化-您端到端拥有您的项目，并负责设计，编码，测试，监视。 大多数项目是 1-2 位工程师。 -* 记录和测量-大量数据，大量指标 -* 黑客周-每个工程师每年都有一个星期从事他们想要的任何项目。 您可以与其他人一起解决更大的项目 -* 工程交换。 来自不同团队的工程师对将交换几个星期的时间，以传播知识和文化 -* Web 工程程序。 一个新的计划，适用于希望在许多不同的团队中工作几个月的工程师。 -* 夏季星期五-在夏季改变您的星期几并释放星期五的时间 -* 每年的慈善日-整个公司外出并为当地的慈善机构捐款-绘画，园艺等 -* TripAdvisor 慈善基金会。 员工可获得数百万美元的资助，可以向自己所参与的慈善组织申请赠款。 +关于您关于 Instagram 的观点，我最近在 Facebook 上进行了大约 1 个小时的演讲，他们概述了将 Instagram 从 AWS 迁移到 Facebook 内部计算基础架构所采取的步骤，该功能远不及 AWS 那样丰富或灵活。 。 显然这不是一件容易的事，他们设法做到了不冻结甚至关闭 Instagram。 -## 关于我们学到的东西，我们如何工作的随机想法 +实际上，Instagram 已迁移到 FB 的基础设施 http://engineering.instagram.com/posts/1086762781352542/migrating-from-aws-to-fb/ -* 可扩展性始于您的文化，即您的雇用方式，雇用对象和设定的期望。 -* 工程师。 雇用聪明，快速，灵活的工程师，他们愿意从事任何类型的工作，并为学习新技术而兴奋。 我们没有“建筑师”-在 TripAdvisor 上，如果您设计某些东西，编写代码，然后对它们进行测试。 不喜欢走出舒适区的工程师，或者觉得某些工作在他们“之下”的工程师将很容易受阻。 -* 雇用从交付有用的事物中获得乐趣的人。 技术是达到目的的手段，而不是最终目的。 -* 您拥有自己的代码及其效果-设计，测试，编码，监控。 如果您弄坏了东西，请修复它。 -* 最好是在两天之内交付 20 个带有 10 个错误的项目，而错过 5 个项目，而不是交付 10 个完全且及时的项目。 -* 鼓励学习和突破极限-在这里工作的每个人在开始的几个月中都会犯许多错误，并且随着时间的推移，偶尔还会犯错。 重要的是您学到了多少，不要一次又一次犯同样的错误。 -* 保持设计简单，并着眼于近期业务需求-不要设计得太远。 例如，随着我们的会员功能从数万个扩展到数百万个到数千万个，我们已经重写了我们的成员功能。 当我们需要的数以万计的时候，我们为数千万的设计本来就很糟糕。 我们更快地交付了每个阶段的问题，并且与每个阶段所学的相比，重写的成本很小。 -* 您可以在垂直扩展数据库方面走得很远，尤其是在最小化联接使用的情况下，尤其是可以将所有内容放入 RAM 的情况下。 -* 仅在必要时才进行分片，并保持简单。 我们最大的单个表具有超过 1B 的行，并且可以轻松垂直扩展，直到我们每天需要更新/插入数千万行，达到写入 IOP 限制。 到那时，我们通过将其拆分为 12 个表在服务级别上进行了分片，并且目前在 2 台计算机上（每台都有 6 个表）运行它。 我们可以轻松地将其扩展到 3、4、6，然后是 12 台机器，而无需更改哈希算法或数据分布，只需复制表即可。 我们没有任何可衡量的性能下降（读取或写入），并且执行此操作的代码很小，易于理解且易于调试。 每天有超过 700M 的数据库操作，因此我们离分拆任何其他表都不远。 -* 尽可能避免加入。 我们的内容类型（成员，媒体，评论等）位于单独的数据库中，有时在共享计算机上，有时在其自己的计算机上。 比执行联接要好得多（执行两个查询（获取具有其成员 ID 的评论集，然后从该 ID 集合中获取所有成员并在应用程序级别将其合并））。 通过将数据存储在不同的数据库中，可以轻松地将每个数据库扩展到一台计算机。 保持内容类型的可伸缩性也更加容易-我们可以以模块化的方式添加新的内容类型，因为每种内容类型都是独立的。 这也与我们的面向服务的方法非常吻合，该服务由数据库支持。 -* 承担单个工程师的端到端责任。 当一个人拥有一切（CSS，JS，Java，SQL，脚本）时，就没有等待，瓶颈，调度冲突，管理开销或“所有权”的分配。 可以采用模块化方式添加更多项目/人员，而不会影响其他所有人。 -* 服务。 拥有一组与业务和使用模式对齐的已知的块状协议（针对有线网络进行了优化）协议，使组装页面变得更加容易，并允许您根据业务需求扩展每个服务。 搜索流量大增？ 添加更多搜索服务器。 还可以使您更仔细地考虑使用模式和业务。 -* 硬件-保持非常简单。 没有花哨的硬件-没有 SAN，没有专用设备（用于网络设备）-我们运行所有戴尔的商品。 假定任何组件都会随时发生故障，并且具有 N + 1 设计或足够的资源来弥补故障。 我们的网络服务器库可以处理大量失败-高达 50％。 数据库为 N + 1，具有重复的热（基于 DRDB）故障转移。 服务在多台计算机上运行多个实例。 负载平衡器和路由器均具有热备用和自动故障转移。 我们在不同城市拥有两个完整的数据中心，一个处于活动 R / W 模式，可处理所有流量，另一个处于最新状态，R / O 模式可随时用于流量。 我们每三个月进行一次“故障转移”，以确保随时准备好“备份”，并为我们的数据中心提供连续/增量的维护。 -* 软件-保持非常，非常，非常简单。 有一些您不想自己写的系统-Apache，Tomcat，Jetty，Lucene，Postgres，memcached，Velocity。 我们自己构建了其他所有内容-分布式服务体系结构，Web 框架等。这并不难做到，您可以理解和控制所有内容。 -* 处理。 越少越好。 您需要使用源代码控制。 您需要成为一个良好的代码公民。 您需要交付有效的代码。 您需要传达您的设计及其工作水平。 “需要”或“需要”没有太多其他内容。 如果您很聪明，则将对设计进行审查，对代码进行审查，并编写测试和适当的监视脚本。 雇用了解您想要这些东西的人，因为它们可以帮助您提供更好的产品，而不是因为它们是“必需品”。 如果您犯了一个错误，并且您会犯错，并且将其修复。 重要的是要找到自己的错误，而不要依靠别人为您找到错误。 -* 设计评论。 邀请所有工程师进行每周设计审查。 如果您有一个项目会影响其他项目（数据库，内存使用，新的 servlet，新的库，重要的东西），那么您应该在设计审查时介绍您的设计并进行讨论。 这不仅是对整个系统提供指导和监督的好方法，而且是每个人互相学习并了解正在发生的事情的好方法。 +“这证明了 Zappos 在冻结的网站上仍然能很好地销售产品，而世界上大多数其他地区都采用了跨多个平台的持续部署和不断发展的模型。” -* * * +我知道人们不敢得出另一个结论：大多数开发组织并没有增加底线，应该受到挑战。 -我非常感谢 Andy Gelfond 对 TripAdivsor 所做的工作提供了非常有用的描述。 好工作。 如此注重细节，不难看出为什么 TripAdvisor 如此有用。 谢谢。 TripAdvisor 正在[招聘](http://www.tripadvisor.com/careers/)。 +有谁知道为什么亚马逊要求这种改变或要求改变什么？ -## 相关文章 +我很想知道他们为什么要迁移到亚马逊！ -* [黑客新闻主题](http://news.ycombinator.com/item?id=2701936) +Zappos 在过去几年中失去了我作为客户的机会。 他们的网站在查找产品，评论，订单历史记录等方面不再具有竞争力。（尝试一下-例如，搜索已完全中断。）他们可能失去了大量客户，但由于困难而没有意识到 跟踪此指标。 像我这样的客户由于更好的选择而只是默默地退出使用他们的服务。 -> Postgres，在 6 对（DRDB）机器上运行，每天处理 700M +次查询 +他们确实跟踪客户指标，相信我，我曾经是那里的开发人员。 -是 DRBD（http://en.wikipedia.org/wiki/DRBD），对吗？ +这个举动并不太令人惊讶，但令人遗憾，这可能是他们在过去几年中大量迁移开发人员的原因。 我是将网站从 perl 更新到 Java 的团队的一部分。 我们真正接触的唯一一件事是基础数据库。 我们最终得到了一个更瘦的应用程序，该应用程序使用了更少的资源。 -> 工程师端到端地工作-设计，代码，测试，监控。 您设计一些东西，然后编写代码。 您编写一些代码，然后进行测试。 -> 工程师跨整个堆栈工作-HTML，CSS，JS，Java，脚本。 如果您不了解某些内容，则可以学习。 -> 交付项目的唯一障碍就是您，因为您应该在所有级别上工作-设计，代码，测试，监视，CSS，JS，Java，SQL，脚本。 +至于关于“添加'if'语句”的评论，那并不涵盖所有内容。 从 perl 到 Java 的迁移需要一些计划和协调。 那里最大的障碍是移动/镜像数据。 如果您每天要处理成千上万的订单，那么确保在迁移过程中获得正确的数据并非易事。 然后，您拥有了现在必须在两种体系结构上都可以使用的支持软件（当时全部由内部编写）。 哦，是的，然后您就有了与库存和订单管理数据进行通信的仓库处理程序，这些数据也必须在这两个系统之间都可以工作。 -don't you end up with dissimilar code all over the place? -are you allowing your dev to design the way your apps interact with end users? don't you know that dev rarely design good user interfaces? -if the same dev is also responsible for supporting their code throughout its lifetime, don't you eventually get into a situation where that dev/team will do nothing but fix bugs in their existing code and don't have enough time to work on new projects? - -DRBD 是正确的，谢谢 Progga - -嗨，mxx， - -我们的系统并不完美-每个团队都需要决定对他们而言重要的事情并做出选择。 是的，有时我们确实会得到重复的代码，但这并没有您想的那么糟糕。 我们依靠工程师来做正确的事，并且我们进行了大量的代码审查。 开发人员在其“生命周期”中并不总是对其代码负责，您对您的项目负责，并且各种各样的人可能会介入并使用您的代码来做事-这有其优点和缺点。 系统对我们来说运作良好，而且最重要的是，可以使人们参与其中-您在整个堆栈中工作，并且您可以进行自己的软件设计和测试。 - -而且，不，开发人员不会执行 UI 或图形设计，这种情况在很多年前在我们的网站上有了足够的 wtf 后就结束了。 “设计”是软件设计。 其他团队负责 UI /图形。 - -安迪 - -1）大概是数据库写操作从 R / W 数据中心复制到 R / O 数据中心（通过 Postgresql 9.0 复制？）如何处理复制滞后？ 例如，如果我提交了酒店评论，它将被写入 R / W 数据中心。 现在，如果我再次访问该酒店的页面，则可能会将我路由到 R / O 数据中心，由于复制滞后，该数据中心可能尚未接受新提交的评论。 在这种情况下，用户可能认为他的评论已丢失。 你如何处理？ - -2）为什么每周都要重新生成 Lucene 索引？ - -谢谢。 - -嗨安迪， - -我们使用 Postgres8.x。 复制是通过一种较旧的查询复制方法（类似于 slony）完成的，多年来，我们已对其进行了升级（例如，通过批量查询以提高性能）。 活动数据中心将复制到另一个数据中心和我们的“本地”办公室数据中心。 有一个滞后-每个人可能要花几分钟才能赶上。 - -但是，数据中心处于 N + 1 配置-只有一个（R / W）正在获得流量。 另一个（R / O）处于活动状态并且可以传输流量，但是 DNS 仅指向活动的一个-因此，我们没有遇到您提到的问题，因为我们有两个数据中心用于可靠性，而不是规模。 - -我们研究了日志和/或流复制（我相信这就是 Postgres 9 所做的），但是它并不像我们想要的那样可靠-数据传输中的损坏会产生重大影响。 使用查询复制（并非如此）以及使用查询复制，我们还可以根据需要手动调整数据（我们需要做几次）。 我们在北京也有一个数据中心，该数据中心的延迟和连接性很差-考虑到它的情况，查询复制对我们来说效果更好。 - -Lucene 索引再生-我们发现，随着时间的推移，增量更新会导致索引碎片化和性能下降，因此我们每周进行一次完整重建，以使其保持“干净”。 另外，索引更改（无论是增量重建还是完全重建）都是在脱机状态下完成的，我们每天重新启动 lucene 以使用新索引-我们永远无法获得“实时”的工作。 我们经营一小堆的 Lucene 包裹式服务，因此没有停机时间。 很有可能有一种更好的方法可以做到这一点-我们尝试了许多方法，并且到目前为止，这种方法效果最好。 - -“每个服务都具有针对业务和/或使用模式进行了优化的 API-例如，获取成员的评论或位置的评论。大多数服务本质上都是数据库前面的大型智能缓存，对于 例如，局部 LRU，memcached，数据库调用在内存局部树/图形中； Jgroups 有时在需要时用于使高速缓存保持同步；大多数服务在不同的共享/物理计算机上运行 4 个实例，有时为服务实例分配自己的计算机。 ” - -和： - -“ -40 台无状态服务银行，运行约 100 个实例的〜25 服务，Jetty / Java，每天处理 700M +个请求 - -在 6 对（DRDB）计算机上运行的 Postgres，每天处理 700M +次查询 -“ - -我有些困惑：服务进行大量缓存，但是每天的请求数似乎与数据库上每天的查询数相匹配。 我猜想也许对数据库的大量查询与这些服务无关？ - -1.您最初是如何进行负载测试并选择 Tomcat 进行此类负载的？ -2.当前如何对整个堆栈进行负载测试？ -3.您具有哪些 CI 设置和单元测试？ -4.您是否使用 JMX 或其他方法监视应用程序事件？是否通过 HTTP 将日志事件传输到浏览器以监视批处理程序的进度。 - -Thanks. - -嗨，您好， - -非常感谢您的出色描述！ -来自 Web 公司，我很惊讶地将 Java 视为后端。 您对选择 Java 作为后端语言的满意程度如何？ 我真的很喜欢它，但是我很难抗拒更多“炒作”语言（如 Ruby，Python，Scala，JS 等）的诱惑。 - -我想成千上万的词，您会基于 Java 再做一次，为什么或为什么不呢？ - -> 您是否允许开发人员设计应用程序与最终用户交互的方式？ 您不知道开发人员很少设计良好的用户界面吗？ -> 如果同一个开发人员还负责在其整个生命周期内支持其代码，那么您最终是否会陷入这种情况，即该开发人员/团队除了修复现有代码中的错误之外什么都不做，没有足够的时间来 在新项目上工作？ - -通常，将向开发人员提供图形设计和产品营销团队的模型。 “这是它的外观”。 工程师的职责通常在发布后一周就结束，因为很明显没有与此相关的直接问题（尤其是性能问题）。 到那时，您便可以开始其他工作了。 哪一个确实可能是错误修复或其他人项目的功能增强。 期望所有工程师都可以使用任何代码库工作。 长期代码拥有权比我在其他地方看到的要少得多。 因此，开发人员最终会看到彼此足够多的代码，而这些代码最终不会因阅读或使用而异样。 - -安迪 - -感谢您的解释。 - -> >我们从未能够获得“实时”的工作。 - -您尝试了哪种类型的实时 Lucene 实现，但无法使其正常工作？ - -Lucene 2.9 添加了 NRT（近实时）。 您使用的是早期版本，还是 Lucene NRT 根本不适合您？ 很想在这里详细了解您的经历。 - -安迪，您提到您的运营团队包括两名技术工程师和两名现场工程师-当然，这不能成为整个团队吗？ 您能否提供更多有关团队规模及其组成的见解？ - -谢谢你写的好。 - -罗伯 - -Andy. - -那真是太棒了。 我的问题之一是，您是否在完全使用开源架构运行 4 9 的正常运行时间基础架构？ 以及如何确保应用程序响应时间达到目​​标。 另外，想知道如何监视基础架构？ - -我将尝试回答尽可能多的问题： - -丹： -服务调用和数据库调用的数目大致相同是巧合，并且数据库调用的数目更多是猜测（我们将 db 调用记录在 Java 代码中），但这是正确的。 我们的许多网页进行多个服务调用，而我们的许多服务进行多个数据库调用，但是每天大约有 1B +内存缓存调用保持了数据库的负载。 由于我们缓存对象而不是查询，因此许多对象可能代表几个数据库调用。 如果我们不使用 memcached，则可能一天会执行 2B +查询。 我一直发现有趣的是，将我们从不同来源收集的所有数字进行关联是多么困难。 - -Mohan： --当我们开始（11 年前）时，我们使用了标准的 Linux / Apache / Tomcat / Java / Postgres 堆栈。 那时我还没来得及，但我认为决策周围没有太多的结构化流程，我也不认为当时还有许多其他开源选项 --负载测试是一个有趣的领域。 我们有不同的测试工具和测试，测试实验室，有时我们使用辅助数据中心。 有时我们使用实时数据中心（例如，将 1/2 台 Web 服务器淘汰掉以查看会发生什么）。 负载测试是在我们认为需要的地方进行的，并且说实话，这是一门艺术。 我们了解到的一件事是，即使重放日志文件，也永远无法真正进行负载测试。 我坚信一切都会失败，并确保您有恢复的方法。 --不熟悉“ CI” --监视是通过 Nagios，Cacti 和许多自定义脚本来完成的，这些脚本分析我们的日志并显示数据。 我可以按 servlet，日期和小时向下钻取，以获得页面请求的总时间，cpu，数据库，服务调用数据（经过时间和调用次数）。 - -主持人： --我对 Java 非常满意，尤其是对于服务。 天哪，强大的线程和状态支持对于构建高性能服务至关重要。 我不确定如何实现可共享的进程内缓存以及如何使用其他语言处理线程。 我们的服务机每秒可以处理数千个请求，并且仍以 15％的负载运行。 如果我要再做一遍，我会考虑一些脚本语言用于前端工作（我们在该领域的一些实验并未显示出许多弊端的实际好处），但是对于服务器工作线程却能够保持 状态（共享内存）对于我们的用例至关重要。 - -steveo： -谢谢 SteveO :-) - -Andy： -我们尝试通过 api 逐步更新索引，但存在很多问题。 这是几年前的事，我不记得具体情况。 拥有 NRT 对我们来说很好，但并不关键。 - -Robbo：​​ -我们过去曾为两个数据中心配备一名技术运营工程师，但发现我们需要再增加一名：-) -我们有两个以上的空缺，因为我们计划扩大规模。 - -因此，我们有： -2 位数据中心和我们的开发环境（很多 xen 服务器）的技术运营（数据中心）人员 -2 位负责软件基础架构的“站点运营”工程师。 -发布工程由我们的网站运营工程师和各种技术经理（需要给他们做一些有趣的事情）完成。 -来自各个团队的 10 多位工程师可以访问该网站并提供补丁程序帮助， 发行，软件开发，数据库，数据中心等。 -对于我们的工作方式，重要的是，软件团队从字面上看要是真正的“游戏皮”。 - -“ Dan： -服务调用和数据库调用的数量大致相同是巧合，并且数据库调用的数量更多是猜测（我们将 db 调用记录在 Java 代码中），但这是正确的。许多 我们的网页中有多个服务调用，而我们的许多服务也有多个数据库调用，但每天大约有 1B +内存缓存调用保持了数据库的负载。由于我们缓存对象而非查询，因此许多对象可能代表 几个数据库调用。如果我们不使用 memcached，我们可能一天会进行 2B +查询。我一直发现有趣的是，将我们从不同来源收集的所有数字关联起来是多么困难。” - -谢谢安迪。 - -同意，关联是建立对我们系统的理解的关键挑战。 实际上，我觉得这里总是会有一些近似值，因为数字是由具有不同上下文量的不同层产生的，这是我们用来将事物捆绑在一起的上下文。 即使是简单的东西，例如使用系统时钟来确定时间段内的顺序或相关数据的收集，也是有问题的。 - -另一个挑战是在不影响用户感知性能的情况下捕获信息。 一个人要么避免捕获数据，要么接受其中的某些数据可能丢失。 我倾向于默认使用后者，因为有些信息总比没有好。 - -大话题，值得啤酒讨论！ - -最好， - -Dan. - -克里希纳坎特： - -我们使用多种监视技术，包括用于外部“第三方”监视的 Gomez 以及自定义脚本和工具。 -我们的“ 4 9”并不是统一的衡量标准。 有一些功能对我们的业务很重要（基本站点的建立，商务和评论），这实际上是衡量标准的来源。我们的站点非常复杂，具有许多不同的内容类型和功能。 如果基本站点，商务和评论正在运行，则我认为该站点已“启动”。 更重要的是，我的老板也是如此：-)我不确定其他所有设备的正常运行时间，但是大概是 3 个 9。 - -关于开源与“商业”解决方案-事实是，它们都失败了。 永远不要相信任何组件，尤其是 SAN。 组件声称“完全可靠”的越多，由于最终信任它，您可能会遇到更多麻烦。 设计失败。 - -正常运行时间可以通过多种方式实现： - -三个基本规则：简单性，围绕所有组件均发生故障的事实进行设计，并使软件工程师和管理人员始终承担起运营责任。 - --我们让事情变得非常简单-商品硬件，以及软件的基础知识（Linus / Apache / Tomcat / Java / Postgres / Lucene / Memcached / jgroups）。 我们仅使用简单的系统/软件，我们了解它们的深入工作原理，经过实践证明，具有良好的运营支持，更重要的是，我们知道疣在哪里，因此我们可以对其进行管理。 --保持操作尽可能简单和可见（自动），但请确保您可以在任何步骤进行干预。 --我们的许多工程师都具有丰富的操作知识，可以随时待命，并可以为现场站点及其操作提供帮助。 我们的运维团队非常小，但“虚拟”运维团队非常庞大，其中包括许多经理。 团队中很少有工程师不会感觉到现场的“热度”。 --假设一切失败。 我们不仅对所有“关键”部分（路由器，负载平衡器，数据库和其他“关键”计算机）进行了加倍（N + 1 配置），而且还可以容忍多台计算机宕机的 Web 服务器和服务库。 而且，整个数据中心在 N + 1 配置中翻了一番。 这不仅为我们节省了一些时间（当 BigIP 出现两次故障时您将不胜感激，并且可以在 5-10 分钟的停机时间内解决这个问题），而且还使我们能够进行认真的机器/网络维护和安全性升级。 - -Hi Andy, - -您的 3 层架构（web- >服务-> db）有多严格？ 是为了保持体系结构简单而实施的，还是为了某些本地的简化/可管理性而尝试减少某些地方的层？ - -开发人员如何工作？ 在本地启动这 25 个服务中的一些服务，本地数据库并针对它们开发 Web 服务器？ - -您说过要对服务进行负载平衡：Web 和服务层如何通信？ （http，RMI 甚至是 Corba？）为什么您决定支持硬件的软件负载平衡？ - -感谢您分享所有这些！ -Stefan - -您好 Stefan， - -好问题- - -我们的三层体系结构未强制执行。 我们希望看到所有来自服务的数据库调用。 不幸的是，由于大多数是遗留原因，而且并非所有主要功能都在服务中，有时我们需要做的一些简单事情不值得将服务组合在一起，因此 Web 服务器确实会进行数据库调用。 当解决变得很重要时，那些“优先拥有项目”可能会被优先考虑。 但是，我们确实有所谓的“ DBR” db 读取数据库。 这些是只读数据库，每天更新一次，并且处于负载平衡配置（我认为我们有 3 个），因为我们已经将所有可写操作移到了服务上。 因此，服务获得了令状，大多数读取得到了，并且有些数据可以直接读取。 - -我们有一些常见的服务和数据库库，因此，如果您仅在 Web 层上工作，那么您所需要的只是前端。 如果您正在使用某项服务，则除了运行 Web 服务器或测试工具外，您所需要的只是运行自己的服务版本-您的个人 ini 文件可以访问并混合并与任何地方的服务匹配。 服务接口的更改需要向后兼容，因此效果很好。 - -如果您需要添加/更改表，则可以对共享数据库之一进行操作，因为这些更改还需要向后兼容。 很少有人需要运行自己的数据库服务器。 对于某些不向后兼容的模式更改的项目，还有其他整个流程可付诸实践，因为现在我们面临着巨大的实时站点部署挑战。 这偶尔发生。 - -服务是 XML / HTTP。 这样做的目的很简单，它使我们能够看到正在发生的事情，并轻松生成测试用例。 但是，恕我直言，一旦您有什么值得编码的地方，XML 就会像二进制格式一样流行。 因此，我们现在通过 xstream 进行序列化（那里有很多优点/缺点）。 服务调用是由 Java 接口定义的，我们有一个代理，它将接受方法调用，并根据配置设置将它们分配给服务器。 设置将重试逻辑确定为方法级别（等待时间长短，一台计算机上多少次退休，多少台计算机重试）。 负载平衡是通过生成 ini 文件设置来完成的-例如，给定的服务通常将映射到 4-8 台计算机，并且不同的 Web 服务器将具有不同的顺序。 如果其中一个不起作用，它将尝试下一个，并在一段时间后重置为原始配置。 - -有点笨拙（它是多年来开发的），存在一些问题，但是非常可靠，并且非常容易通过编辑其配置文件来调整计算机。 我们可以通过旋转一台新的服务机并调整一台 Web 服务器来轻松地在站点上测试服务的新代码。 对于本地开发，这也非常有用。 - -由于历史上的增量开发，我们选择了软件负载平衡方，但是我们的负载平衡需求非常复杂，有时需要以临时方式进行调整，需要开发人员进行修改以供本地使用，并且我们也希望能够 打开登录以提供正在发生的事情的详细信息。 我们已经讨论过将其移至负载均衡器的方法，但是我们不了解如何以数据驱动（ini 文件）的方式进行此操作，如何让每个开发人员都有自己的设置，或允许 Web 服务器调出 任何 HTTP 服务（例如，不在同一网络上）。 对于更改负载均衡器上的代码以及如何正确测试它，也存在极大的恐惧。 - -帖子不错，谢谢您的分享。 - -谢谢，安迪， - -特别是您对负载均衡器的洞察力非常有趣。 我在一个非常相似的网站上工作，但是房地产和德语（仅德语），可能占您页面浏览量的十分之一，而且我们确实有硬件负载平衡器。 结果是，即使开发人员几乎不了解 devop，对于开发人员来说，这个主题也是一个（遥远的）黑匣子，并且是唯一的可操作事情。 - -此外，还有很多与“开发人员因为开发环境没有 Big IP 负载平衡器而无法正确测试”有关的问题，您可能可以避免这种情况。 我只能建议您坚持这个决定。 - -最佳 -Stefan - -设计审查实践似乎非常有趣。 -我同意我们不需要“ powerpoint”架构师，但有些开发人员更有经验。 您如何避免没有大的自我冲突导致拼凑而成的设计？ - -Hi Andy, - -您提到您的内容按内容类型（成员，媒体，评论等）分隔，那么您的 20 种语言呢？ 每种语言都有一个数据库吗？ 也就是说，每种内容类型都有 20 个数据库吗？ 还是每种内容类型只有一个数据库（包括所有语言）？ - -Best, - -马蒂亚斯 - -嗨，Uberto， - -您从事和/或领导的项目的类型取决于您对我们系统的经验和知识-这样，如果您是新手或刚离开学校，则可以拥有自己的小型项目，或者与他人一起工作 一个更大的项目的高级工程师。 随着学习，您将获得“更大”的项目。 - -我以与代码审查相同的方式看待设计审查-您之所以不要这样做，不是因为期望，而是因为您真正地感觉到它们是帮助您交付最佳代码的好方法。 我发现，比较成功的工程师是积极寻求代码和设计审查的工程师。 - -关于自我。 通过明确我们的工作方式，许多信息在面试过程中被过滤掉了-许多“非常高级”的工程师不想编写代码或进行测试，因此他们会转到其他公司。 我发现，当有人被迫在同行面前讨论他们的设计，并且他们需要进行自己的编码和测试时，设计往往会更简单，更实用和更清洁。 - -虽然要求人们回头重新考虑其设计的某些方面在某种程度上很普遍，但很少有真正的分歧。 我只能想一想我实际上必须介入并做出决定的地方-团队总是做出一个令我满意的决定（我可能会以相同的方式做）或我足够自在（也许不是） 我会做的方式，但效果很好，至少 imo :-)。 - -我认为这与两件事有关：一是每个人都真正想做正确的事，人们真正尊重彼此的意见，而我们拥有可借鉴的巨大广度和经验。 - -第二个是我们的“设计”专注于方法/操作，这使事情变得实用。 事实是，您可以使任何语言工作和扩展-Python，Perl，Java，PHP，甚至 Ruby :-)-我们关注的重点是内存使用情况，代码所在的位置（Web 服务器，服务，离线）， 数据已存储（数据库，文本文件，日志文件，内存），通过网络传输的内容，什么样的缓存（本地，本地 LRU，memcached 等），算法复杂性以及数据模式是什么。 我们很少涉及类和类结构或特定的代码。 而且，如果您想引进新技术，则需要同时做功课以及为什么不能使我们当前的技术适合您的用例。 - -是的，我们有时最终会在网站的不同部分出现“不同的设计”。 这并没有您想的那么糟糕，最后，我更喜欢为团队提供方法上的灵活性（在多年来已经确定的某些界限之内），尤其是考虑到团队需要真正感受到其工作的主人翁感。 此外，令人惊讶的是您从不同的方法中学到了什么。 - -嗨 Matlias， - -内容不会按语言划分，但是会按语言和 POS 来源进行标记。 - -Hi Andy, - -谢谢回答。 -我明白了，当您说“避免联接”时，您是在谈论数据库之间的联接，不同内容类型之间的联接，但是显然每个内容类型数据库内部都有很多表（包含所有标记为 POS，语言等）。 也就是说，在不同数据库之间进行联接非常昂贵，如果它们位于不同的计算机上，联接成本甚至更高。 -然后，由于使用的是 DRDB，因此可以在许多位置（也许是？）以多种语言提供内容，就像您所说的那样，它可以使您进行重复的热故障转移，同时可以减少对不同国家/地区的延迟，因为 您的服务器位置。 我对么？ - -Hi Andy, - -关于内容，您是否实施了一些用于更改数据的捕获？ 你能评论一下吗？ 知道您如何处理具有成千上万个项目（酒店，评论等）的内容版本化将非常有趣。 - -Best, - -Matias - -我认为允许进行一些不同的设计和代码复制是一个好主意。 否则，您将获得严格的标准，这将使您的应用程序/代码不再发展。 看到这发生在其他地方，这就是为什么我要说。 一旦规则变得比创造力，实时思考更重要，发展就不再与业务联系在一起。 - -此外，DRY 的难看面孔是强耦合。 国际海事组织的最佳选择总是介于极端之间。 \ No newline at end of file +这将是一个很大的挑战。 \ No newline at end of file diff --git a/docs/18.md b/docs/18.md index 8c7815c..c7c2bee 100644 --- a/docs/18.md +++ b/docs/18.md @@ -1,348 +1,200 @@ -# Google 如何针对行星级基础设施进行行星级工程设计？ +# Flickr 架构 -> 原文： [http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html](http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html) +> 原文： [http://highscalability.com/blog/2007/11/13/flickr-architecture.html](http://highscalability.com/blog/2007/11/13/flickr-architecture.html) -![](img/9c7095e31a8c5999cdcef74072ddf82a.png) +**更新：** Flickr 击中[提供了 20 亿张照片](http://www.webware.com/8301-1_109-9816461-2.htm)。 那是很多汉堡包。 -Google 如何保持其所有服务正常运行？ 他们似乎从来没有失败过。 如果您想知道我们在 [GCP NEXT 2016](https://cloudplatformonline.com/next2016-schedule.html) 上发表的演讲中的精彩幕后花絮， [Melissa Binde](https://www.linkedin.com/in/mbinde) ，Google Storage SRE 总监： [Google 如何针对行星级基础架构](https://www.youtube.com/watch?v=H4vMcD7zKM0)进行行星级工程。 +Flickr 既是我最喜欢的[鸟](http://www.birds.cornell.edu/AllAboutBirds/BirdGuide/Northern_Flicker.html)，也是网络上领先的照片共享网站。 Flickr 面临着巨大的挑战，他们必须处理浩如烟海的内容，包括不断扩展的新内容，不断增长的用户群以及不断涌现的新功能，同时还要提供出色的性能。 他们是如何做到的呢？ -梅利莎（Melissa）的讲话很简短，但充满智慧，而且以一种胡说八道的方式表达出来，使您认为服务是否失败梅利莎（Melissa）绝对是您想要的那种人。 +网站：http：//www.flickr.com -哦，什么是 SRE？ 它代表*站点可靠性工程*，但定义却更加难以捉摸。 就像您要求道的定义时得到的答案一样。 正如 Google 的本·斯洛斯（Ben Sloss）24x7 副总裁所明确指出的那样，这不仅仅是一个过程，更是一个过程，他将 SRE 定义为： +## 信息来源 -> 当软件工程师承担了过去称为操作的任务时会发生什么。 +* [Flickr 和 PHP](http://www.niallkennedy.com/blog/uploads/flickr_php.pdf) （早期文档）* [LAMP](http://www.kitchensoap.com/talks/MySQLConf2007-Capacity.pdf) 的容量规划* [Flickr 的联合会：每天进行数十亿次查询](http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html)，作者 Dathan Pattishall。* [构建可扩展网站](http://www.amazon.com/Building-Scalable-Web-Sites-Applications/dp/0596102356)，来自 Flickr 的 Cal Henderson。* [数据库战争故事＃3：Flickr [Tim O'Reilly]](http://radar.oreilly.com/2006/04/database-war-stories-3-flickr.html)* [Cal Henderson 的演讲](http://www.iamcal.com/talks/)。 很多有用的 PowerPoint 演示文稿。 -让它在您的头部反弹一会儿。 + ## 平台 -最重要的是，有一件事很清楚：SRE 是生产的保管人。 SRE 是 google.com 和 GCP 的客户体验的管理者。 + * 的 PHP* 的 MySQL* 碎片* Memcached 用于缓存层。* 乌贼在反向代理为 HTML 和图像。* Linux（RedHat）* 聪明的模板* 佩尔* 用于 XML 和电子邮件解析的 PEAR* ImageMagick，用于图像处理* Java，用于节点服务* 阿帕奇* 用于部署的 SystemImager* Ganglia 用于分布式系统监控* Subcon 将重要的系统配置文件存储在 Subversion 存储库中，以便轻松部署到群集中的计算机上。* Cvsup for distributing and updating collections of files across a network. -对我来说，一些演讲重点： + ## 统计资料 -* **点检正常运行时间的破坏性激励与功能**相比。 SRE 试图解决想要推送功能的开发人员与想要通过不推送功能来维持正常运行时间的系统管理员之间的天然矛盾。 -* **错误预算**。 这是预期会失败的想法。 这不是一件坏事。 用户无法确定服务的运行时间是 100％还是 99.99％，因此您可能会出错。 这减少了开发人员和运营人员之间的紧张关系。 只要维护错误预算，您就可以推出新功能，而运营方也不会受到指责。 -* **目标是立即恢复服务。 故障排除将在稍后进行。** 这意味着在还原服务后，您需要大量日志记录和工具来进行调试。 由于某种原因，这使[较早的文章](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html)上的内容闪烁了起来，同样基于 Google SRE 的讲话：*备份无用。 这是您关心的*还原。 -* **没有无聊的分页哲学**。 当页面进入时，应该是一个有趣的新问题。 您不希望无聊的 SRE 处理重复性问题。 这就是机器人的目的。 + * 每天超过 40 亿个查询。* 鱿鱼缓存中约有 3500 万张照片（总计）* 鱿鱼的 RAM 中有约 200 万张照片* 约 470M 张照片，每张 4 或 5 个尺寸* 38k req / sec 到 memcached（1200 万个对象）* 2 PB 原始存储（周日消耗约 1.5 TB* 每天要添加超过 40 万张照片 -演讲中其他有趣的话题是：SRE 的组织结构如何？ 如何聘用开发人员来专注于生产并使他们满意？ 我们如何保持团队在 Google 内部的价值？ 我们如何帮助我们的团队更好地沟通并解决与数据而非断言或权力夺取的分歧？ + ## 架构 -让我们继续吧。 以下是 Google 如何针对行星级基础设施进行行星级工程... + * 在此[幻灯片](http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches/138)上可以找到 Flickr 架构的漂亮图片。 一个简单的描述是： + -ServerIron 的 + ---- Squid 缓存对 + ------ Net App 的 + ---- PHP App Server + ---- -存储管理器 + ------主-主分片 + ------双树中央数据库 + ------内存缓存群集 + ------ 大型搜索引擎 -## 保持平衡：点检正常运行时间的破坏性动机与功能 + -双树结构是对 MySQL 的一组自定义更改，它允许通过增量添加没有环体系结构的母版进行缩放。 这样可以进行更便宜的扩展，因为与主-主设置相比，您需要的硬件更少，而主-主设置始终需要两倍的硬件。 + -中央数据库包含“用户”表之类的数据，该数据包括主用户 + 键（一些不同的 ID）以及可以在其上找到用户数据的指针。 -* 系统管理员会在站点正常运行时获得 Cookie 的正常运行时间。 当网站停滞不前时，我们会吸引访问者，访问者会给我们钱。 + * 使用专用服务器获取静态内容。* 讨论如何支持 Unicode。* 使用无共享架构。* 一切（照片除外）都存储在数据库中。* 无状态意味着他们可以在服务器周围弹跳人，并且更容易制作他们的 API。* 首先通过复制进行扩展，但这仅有助于读取。* 通过复制他们要搜索的数据库部分来创建搜索服务器场。* 使用水平缩放，因此他们只需要添加更多计算机即可。* 通过解析每封电子邮件（用 PHP 交付）来处理从用户发送的图片。 电子邮件被解析为任何照片。* 早些时候他们遭受了奴隶主的滞后。 负载太多，它们只有一个故障点。* 他们需要能够进行实时维护，修复数据等功能，而又不会导致站点停机。* 关于容量规划的许多优秀资料。 请查看信息源以获取更多详细信息。* 采取联合方法，以便它们可以扩展到更远的将来： + -分片：我的数据存储在我的分片上，但是对您的评论执行操作的记录却在您的分片上。 在他人的博客 + -Global Ring 上发表评论时，就像 DNS 一样，您需要知道该去哪里，以及谁来控制您的去向。 在每个页面视图中，计算当时的数据位置。 + -用于连接至分片并保持数据一致的 PHP 逻辑（带有注释的 10 行代码！）* 碎片： + -主数据库的一部分 + -主动主-主环复制：MySQL 4.1 中的一些缺点，因为尊重主-主中的提交。 AutoIncrement ID 自动执行，以使其保持活动状态。 + -分片分配来自新帐户的随机数。 + -迁移会不时进行，因此您可以删除某些超级用户。 如果您有很多照片，则需要平衡…192,000 张照片，700,000 个标签将花费大约 3-4 分钟。 迁移是手动完成的。* 单击收藏夹： + -从缓存中提取照片所有者帐户，以获取分片位置（例如，在分片 5 上） + -从缓存中提取我的信息，以获取我的分片位置（例如，在分片 13 上） + -开始“分布式交易”-回答以下问题：谁收藏了照片？ 我最喜欢什么？* 可以从任何分片提问，并恢复数据。 它绝对多余。* 要消除复制滞后… + -每个页面加载，都会为用户分配一个存储桶 + -如果主机关闭，请转到列表中的下一个主机； 如果所有主机都关闭，则显示错误页面。 他们不使用持久连接，而是建立连接并将其拆除。 这样，每个页面加载都会测试连接。* 每个用户的读写都保存在一个分片中。 复制滞后的概念消失了。* 分片中的每个服务器已加载 50％。 关闭每个分片中的 1/2 台服务器。 因此，如果该碎片中的一台服务器关闭或处于维护模式，则该碎片中的一台服务器可以承担全部负载。 要升级，您只需要关闭一半的碎片，升级一半，然后重复该过程即可。* 在流量激增的一段时间内，它们违反了 50％的规则。 他们每秒执行 6,000-7,000 个查询。 现在，其每秒最多可查询 4000 个查询，以使其保持 50％的负载。* 每页平均查询为 27-35 条 SQL 语句。 收藏夹计数是实时的。 API 对数据库的访问都是实时的。 达到了实时要求，没有任何缺点。* 每秒超过 36,000 个查询-在容量阈值内运行。 流量爆裂，两倍 36K / qps。* 每个碎片可容纳 40 万多个用户数据。 + -很多数据被存储两次。 例如，评论是评论者和被评论者之间关系的一部分。 评论存储在哪里？ 两个地方怎么样？ 事务用于防止数据不同步：打开事务 1，写命令，打开事务 2，写命令，如果一切都很好，则提交第一个事务，如果第一次提交，则提交第二个事务。 但是在第一次提交期间出现故障时，仍然有失败的可能。* 搜索： + -两个搜索后端：几个分片上的分片 35k qps 和 Yahoo!的（专有）网络搜索 + -所有者的单个标签搜索或批量标签更改（例如，通过 Organizr） 碎片由于实时性的要求，其他一切都归 Yahoo!的引擎处理（可能比实时性差 90％） + -考虑一下，这样您就可以进行类似 Lucene 的搜索* 硬件： + -带 RHEL4 的 EMT64，16GB RAM + -6 磁盘 15K RPM RAID-10。 + -数据大小为 12 TB 用户元数据（这些不是照片，这只是 innodb ibdata 文件-这些照片要大得多）。 + -2U 盒子。 每个分片都有〜120GB 的数据。* 备份过程： + -在 cron 作业上进行 ibbackup，该备份在不同时间跨各种分片运行。 热备份到备用。 + -快照是每晚在整个数据库集群中拍摄的。 + -在一次复制复制文件存储库中一次写入或删除多个大备份文件时，由于复制备份文件，可能会在接下来的几个小时内破坏该文件存储库的性能。 对生产中的照片存储文件管理器执行此操作不是一个好主意。 + -保留所有数据多天备份的成本不菲，这是值得的。 几天后发现有问题时，保留交错备份非常有用。 例如 1 天，2 天，10 天和 30 天的备份。* 照片存储在文件管理器中。 上传后，它会处理照片，为您提供不同的尺寸，然后完成。 元数据和指向文件管理器的点都存储在数据库中。* 聚合数据：非常快，因为它是每个分片的一个过程。 将其粘贴到表中，或从其他用户分片的另一个副本中恢复数据。* max_connections =每个分片 400 个连接，或每个服务器&分片 800 个连接。 大量的容量和连接。 线程缓存设置为 45，因为您同时进行活动的用户不超过 45 个。* 标签： + -标签与传统的标准化 RDBM 架构设计不太匹配。 非规范化或繁重的缓存是在数毫秒内为数亿个标签生成标签云的唯一方法。 + -它们的某些数据视图是由专用处理集群离线计算的，这些集群将结果保存到 MySQL 中，因为某些关系计算起来非常复杂，以至于会吸收所有数据库 CPU 周期。* 未来方向： + -使用实时 BCP 使其速度更快，因此所有数据中心都可以同时接收对数据层（db，memcache 等）的写入。 一切都处于活动状态，不会有任何闲置状态。 -* 开发人员会获得功能的 Cookie。 发布一个新功能，访问者来了，他们给了我们钱。 + ## 得到教训 -* 生产冻结，也就是新功能的冻结，通常映射为增加正常运行时间。 + * **不仅将您的应用程序视为 Web 应用程序**。 您将拥有 REST API，SOAP API，RSS feed，Atom feed 等。 -* 开发人员和系统管理员之间存在天生的紧张关系。 开发人员会获得发布功能的 Cookie。 系统管理员会获取 Cookie 以确保正常运行时间。 + * **进入无状态**。 无状态使系统更简单，更健壮，可以处理升级而不会退缩。 -* 因此，系统管理员因阻止新功能发布而获得奖励。 如果开发人员能够解决系统管理员的问题，他们将获得奖励。 + * 重新架构数据库很烂。 -* 开发人员进行他们所谓的 Beta 测试是为了尽快发布功能。 + * **容量计划**。 尽早将容量规划纳入产品讨论中。 从$$美元的人员（和工程管理人员）那里买到值得关注的东西。 -* 系统管理员执行他们所谓的启动评论，以减慢新功能。 + * **缓慢启动**。 不要仅仅因为害怕/高兴您的网站会爆炸而购买过多的设备。 -* 您的团队将所有的时间都花在彼此抗争上，因此您会增加停机次数，风险，混乱和无政府状态。 + * **测量真实度**。 容量规划数学应该基于真实事物，而不是抽象事物。 -* 您想要的是消除异想天开的命令。 请按规则处理，以便团队可以有目标并共同努力。 + * **内置日志记录和指标**。 使用情况统计信息与服务器统计信息一样重要。 内置自定义指标，以衡量基于服务器统计信息的实际使用情况。 -* 就像 devops 一样，有一种方法可以使开发人员和操作人员一起工作。 问题是，devops 无论走到哪里都有不同的含义。 相反，SRE（站点可靠性工程）定义明确。 + * **缓存**。 缓存和 RAM 是一切的答案。 -* **SRE：** **当您要求软件工程师设计和运行操作时会发生什么？**-Ben Sloss 24x7 VP，Google + * **摘要**。 在数据库工作，业务逻辑，页面逻辑，页面标记和表示层之间创建清晰的抽象层。 这支持快速完成迭代开发。 - * 软件工程师-事实证明，当知道软件的人也运行服务时，服务可以更好地运行。 他们对什么使它打勾有深刻的理解。 + * **层**。 分层使开发人员可以创建页面级逻辑，设计人员可以使用这些逻辑来构建用户体验。 设计人员可以根据需要询问页面逻辑。 这是双方之间的谈判。 - * 设计和运行-实际上是设计您的生产环境，而不是让它成为意外的事故。 + * **经常释放**。 甚至每 30 分钟一次。 -* 假设有 1000 个 SRE 在 Google 的基础架构上工作：网络，计算，存储等。有多少个 SRE 负责云计算？ + * **大约 97％的时间都忘了小效率**。 过早的优化是万恶之源。 - * 所有。 + * **生产中测试**。 内置于体系结构机制（配置标志，负载平衡等）中，通过这些机制，您可以轻松地将新硬件部署到生产中（或从生产中删除）。 - * **google.com 的运行源与 GCP（Google 的云平台）的运行**之间没有界限。 不需要让云团队和内部团队进行沟通的开销。 他们创造了一种环境，可以帮助所有人协同工作。 + * **忘记基准**。 基准可以很好地了解功能，但不适用于规划。 人工测试可以提供人工结果，并且时间可以更好地用于真实测试。 -## 技能：SRE 是一个印章团队和圣职 + * **找出上限**。 + -每个服务器最多可以做些什么？ + -您离该最大值有多近？趋势如何？ + -MySQL（磁盘 IO？） + -SQUID（磁盘 I 或 CPU？） + -内存缓存（CPU？或网络？） -* 本节的标题是我的描述。 具有技能的 SRE 必须是精英。 在工作方面，他们仅致力于这种几乎准神秘的事物，称为生产。 + * **对您的应用程序类型**的使用模式敏感。 + -您有与事件相关的成长吗？ 例如：灾难，新闻事件。 + -Flickr 在一年的第一个工作日获得的上传数量比上一年的任何前一个高峰多 20-40％。 + -周日的上载次数比一周的其余时间平均多 40-50％ -* SRE 必须比开发人员更熟练，才能完成相同的工作： + * **对指数增长的需求敏感**。 更多的用户意味着更多的内容，更多的内容意味着更多的连接，更多的连接意味着更多的使用。 - * 他们需要更大的技能范围。 + * **计划峰**。 能够处理上下堆叠的峰值负载。 - * 所有 SRE 必须通过完整的软件开发人员面试才能被录用。 +Flickr 仅在其数据库中存储对映像的引用，实际文件存储在网络上其他位置的单独存储服务器上。 - * 所有 SRE 必须通过一次非抽象的大型系统设计采访。 +Flickr 图像的典型 URL 如下所示： -* SRE 必须具有相同的软件技能，这是不同的应用领域。 +`[http://farm1.static.flickr.com/104/301293250_dc284905d0_m.jpg](http://farm1.static.flickr.com/104/301293250_dc284905d0_m.jpg)` - * 开发人员专心于产品经理并制作功能。 +如果将其拆分，我们将得到： - * SRE 依赖于生产，以使生产达到最佳状态。 +`farm1` -显然是图像存储所在的服务器场。 我还没有看到其他的价值。 -* **将面向开发和面向生产的观点结合在一起时，最终的设计会更强大**。 +`.static.flickr.com` -相当自我解释。 -* 入职流程示例给出了 SRE 带来的问题的示例，该过程在将团队的项目置于 SRE 的责任之下时发生。 在评估团队的软件时，他们发现： +`/104` -服务器 ID 号。 - * 当达到规模时，它将在生产中失败。 +`/301293250` -图像 ID。 - * 开发人员已隐式假定某种呼叫不会失败。 +`_dc284905d0` -图像“秘密”。 我认为这是为了防止在未首先从 API 获取信息的情况下复制图像。 - * 他们假设请求的分配是统一的。 +`_m`-图像的尺寸。 在这种情况下，“ m”表示中等，但是可以很小，例如拇指。对于标准图像大小，URL 中没有此格式的大小。 - * 他们以为不会受到用户的关注。 +嗨， +很棒的文章。 +我想看看每个点上不同的“选项”在您面前的位置会很有趣。 然后，简短解释为什么选择某些“答案”可能会很有用。 - * 他们假定所有请求的大小均处于平均水平。 +再次感谢您的好东西... - * 他们的两条尾巴都失败了（没有给出解释）。 +我们将进行很多更改，以通过实时 BCP 使其更快，以便所有数据中心都可以同时接收对数据层（db，memcache 等）的写操作，即所有活动的对象都不会处于空闲状态 。 -## 组织：为开发人员提供不让运营工作积聚的理由 +>我们将进行很多更改，以使实时 BCP 更快 -* 该系统必须设计为不增加运营工作，因为如果开发人员不从事工作，他们将不会那么在意。 +很有意思，下一次进化就开始了。 我想知道您如何处理复制。 是在事务上下文中在客户端库中还是在后端服务中进行复制？ 似乎您将有一个主动-主动计划，一个人的家庭数据将驻留在哪里，以及您将如何处理来自多个数据中心的更新中的合并数据？ 数据中心是否有足够的能力来处理所有负载，以防万一发生故障？ 您将如何确定数据中心何时瘫痪以及如何在数据中心之间负载均衡流量？ -* **SRE** 的开发预算。 如果您的系统的运营开销很大，那么您获得的开发人员就不会那么多，那么您就无法推广那么多的功能。 +进入多个数据中心是系统复杂度的巨大飞跃。 听到您对这些问题以及您所面临的其他问题的思考会很有趣。 -* SRE 具有完全不同的命令链。 他们有自己的副总裁，与开发副总裁分开。 这赋予了他们权力和权力。 当生产意味着他们需要拒绝时，它允许他们说不。 一堆不是的传呼猴子。 +嗯...我不能相信写在 php 上的 flickr ... -* 当开发人员说他们可以捐赠人数时，SRE 不必接受。 SRE 可以说服务不够重要，请自己继续提供支持。 +托德- -* SRE 是一种稀缺资源。 并非 Google 的每个团队都有 SRE。 云确实可以，但是不是每个其他团队，甚至不是云中的每个小服务，都只是重要的。 +首先-很棒的博客！ 很高兴在一个地方看到很多这样的东西。 -## 环境：如何使开发人员在生产团队中保持快乐？ +关于 Flickr 和 BCP： +BCP 的数据库部分确实很有趣。 在存储和提供照片方面，我们当然已经拥有 BCP（多个数据中心），因此我们可以为 farmX.static.flickr.com 平衡许多不同数据中心之间的流量。 -* **至少有 50％的工作需要为项目工作**。 不待命。 不是门票。 不开会。 实际上是在做项目工作。 +干杯！ -* 如果项目工作量过多，则开发人员会给 SRE 分配更多的人员，或者将额外的工作流交给开发人员团队。 +好的通道！ +如何理解主-主环复制？ 这个结构是稳定的吗？ 谢谢 -* 什么是项目工作？ +最大的图片网站？ 不。 +据 TechCrunch 报道，Facebook 拥有 40 亿张照片； flickr 有 20 亿美元。 - * 通过切换基础数据库技术来改善服务的延迟。 +每天有 40 亿个查询，并且仍在增长。 建立社区的速度比老牌收集亲朋好友的速度还要快... Flickr 真是一个奇观！ 谢谢，在幕后进行了一次有趣的窥视！ - * 编写自动化以加速部署。 +我很高兴阅读 Flickr 使用 SystemImager 进行部署。 我是该软件的拥护者-它是简单性和功能性的完美结合。 基于 rsync 或 TFTP / DHCP 等知名工具构建。 我记得在不到一个小时的时间内从头开始安装了约 100 台服务器（为此，我们甚至没有使用 systemimager / flamethrower）。 易于安装且非常灵活（如果您有奇特的硬件，只需自行准备内核或手动修复新节点的安装脚本，SI 对此将非常满意）。 还可以看一下 GUI 监视守护程序/工具（si_monitor / si_monitortk）。 - * 跨服务的项目。 Google 作为一项内部服务，可以由其他服务（通常由软件 bot）在内部进行查询，如果可以安全地将计算机停机，可以安全地将机架停机或者将数据中心安全地停机，则可以返回 Google ？ +如何下载图像。 +静态服务器上的 apache 吗？ -* SRE 是一支志愿军。 没有草稿。 +显示您对 php 的了解 - * 您可以随时转入另一个 SRE 团队。 +每天有 40 亿个查询，并且仍在增长。 建立社区的速度比老牌收集亲朋好友的速度还要快... Flickr 真是一个奇观！ 谢谢，在幕后进行了一次有趣的窥视！ - * 您可以随时转移到 dev 中。 +How to download the images. +An apache on static servers ? - * Mission Control 是一个程序，开发人员可以在其中试用 SRE 并查看他们是否喜欢它。 +似乎将您的图像存储在数据库中可能会使站点速度变慢。 -* 团队很流畅。 人们来自团队，分享经验，分享观点。 +似乎将您的图像存储在其中？ -## 预算：您可以支出任意预算的错误预算 +shows what you know about php -* 如果您有 3 个 9 的可用性，目标不是将其提高到 4 个 9，则您有 0.1％的错误预算，请继续努力。 +毫无疑问，Flicr 的架构很棒。 只是想说，聪明人可以由 Blitz 更改，有一些比较表 [http://alexeyrybak.com/blitz/blitz_en.html](http://alexeyrybak.com/blitz/blitz_en.html) -* **如果您想更快地推出功能并使 GCP 变得更好，那就去做吧。 直到用尽错误预算。** +是否有更简单的解决方案来管理数据库和文件的组合图像？ -* 如果您希望进行较差的测试，使软件定期出现故障并且必须不断回滚，则也可以选择该选项，但是错误预算很快就会用完，并且您将无法启动 。 +很好 -* 错误预算按季度循环。 +精彩 -* 有一个逃生阀：三枚银色子弹。 +We are going to change a lot of things, to make it faster with real-time BCP, so all datacenters can receive writes to the datalayer (db, memcache, etc) all at the same time i.e. everything is active nothing will ever be idle. - * 一个开发人员可以说我真的需要推动，请给我一个银弹。 +本文档确实对希望建立大型站点的新手有所帮助。 - * SRE 会说“ OK”，但您必须说服 VP 您实际需要推动。 +显示您对 php 的了解 - * 这个仪式听起来很愚蠢，但功能非常强大。 它将控制权交给开发人员。 他们有 3 个灵丹妙药，由他们的副总裁来决定是否合适。 - -* 错误预算基于每个服务。 因此，如果多个开发团队使用相同的服务，则它们共享相同的预算。 - - * SRE 不在交战的开发团队中间。 他们必须弄清楚如何花费错误预算。 - -* 机外。 如果所有其他方法都失败了，并且开发人员和 SRE 确实不同意，则 SRE 可以派遣开发团队。 - - * 像和睦的离婚。 - - * 这是至关重要的逃生阀门，因此团队在很长一段时间内都不会出现令人讨厌的分歧。 - - * 很少见，但确实发生了。 一个示例场景是，如果团队不想在其 ACID 类型项目中使用 Spanner，如果开发团队说他们想建立自己的团队，那么 SRE 团队可以说他们不想为团队提供支持。 去建立自己的数据库，因为这对生产不利。 - -* SRE 是 google.com 和 GCP 的生产托管人，SRE 是客户体验的托管人。 - -## SRE 支持在频谱上 - -* 聊天和咨询。 与开发人员聊天。 进行白板会议。 - -* 协同设计。 与开发人员一起创建设计。 - -* 完全所有权。 完全拥有的服务。 所有容量，所有供应，所有页面。 - -* 页面是保持诚实的一种方式。 它们不是 SRE 的目的。 - - * 负责制作的人应该拿走页面，因为这样可以使他们的皮肤保持游戏的外观。 - - * 它还有助于使 SRE 的技能，专长和观点保持最新。 - -## 是什么让事情顺利进行？ 文化和过程 - -* Google 会进行常规的培训和通话阴影处理。 - -* Google 也有一个名为：**命运之轮**的过程-卷轴游戏。 - - * 一个人是地牢大师，他们有一个受害者，团队轮流尝试猜测发生了什么。 - - * Google 运行非常复杂的系统。 除了进行培训的人之外，很少有人真正知道发生了什么以及答案是什么。 - - * 对新的来电者来说很好。 让他们在受控环境中进行测试。 - - * 有些团队在某些场景中会破坏生产并让新手修复它。 - - * 对退伍军人也有好处。 最好重新整理您的知识，尤其是在使用非常复杂的系统时。 - -## 事件管理 - -* 场景：您正在呼叫 gmail，并且您获得票证，用户可以看到其他用户的电子邮件。 你是做什么？ 关闭 gmail。 - -* **Oncallers 被完全授权采取一切措施来保护用户，保护信息，保护 Google。** 如果这意味着要关闭 gmail 甚至关闭全部 google.com，那么作为 SRE，您的副总裁将为您提供支持，而您的 SVP 将为保护 Google 提供支持。 - -* **目标是立即恢复服务。 故障排除将在稍后进行。** - - * 有二进制状态的记录。 有日志。 - - * 醒着，开发人员在办公室，所有人都在时，请进行故障排除。 目的是使服务重新启动并运行。 - -## 你该怪谁？ - -* 当“新开发者”推送代码并破坏 google.com 达三个小时时，您应归咎于谁？ a）新开发者 b）代码审查。 c）缺乏测试（或被忽略）的测试。 d）缺乏针对代码的适当的金丝雀程序。 e）缺乏快速回滚工具。 - - * 除了新开发者以外的所有东西。 **如果新开发人员编写的代码会导致网站瘫痪，那不是开发人员的错。 这是开发人员和工作人员之间所有关口的错。** - - * **绝对不允许人为错误传播到人外。** 查看允许部署损坏的代码的过程。 - -## 无罪的岗位形态 - -* 避免责备文化至关重要。 - -* 研究表明，大多数事件是人为错误引起的。 - -* **最好通过了解实际发生的事件来解决事件。** 不知道发生了什么的最好方法？ 通过寻找责任人来揭开每一个事件。 - -* 人们真的很擅长隐藏，并确保没有线索，并确保您实际上不知道发生了什么。 试图找到责任，只会使您的工作更加困难。 - -* 在 Google 谁搞砸了谁写的事后验尸。 这样可以避免命名和遮挡。 使他们有能力纠正错误。 促成失败的每个人都应尽可能诚实地参与进来，并写下您如何陷入困境。 - -* 已在全体会议上给予拆除该站点的奖金，因为他们立即拥有该站点，因此他们拥有了该站点。 他们上了 IRC，并将其回滚。 他们说出来并如此迅速地照顾好他们，便获得了奖金。 - -* 无赖并不意味着没有名称和细节。 这意味着我们不会因为事情出错的原因而选择别人。 不应发生诸如断电之类的事情，应予以解雇。 - -* 深度防御 - - * 由于策略是纵深防御，因此事后评估模板将操作分为预防，检测和缓解措施。 - - * **我们希望防止中断，我们希望更快地检测到它们，并希望减轻影响。** - - * 如果类似的情况再次发生，它将不会传播到很远，持续太久或影响那么多客户。 - -## 分页的无聊哲学 - -* 团队喜欢看什么样的页面？ 新的和有趣的。 - -* 您知道如何解决的页面很无聊。 您应该创建一个机器人来解决该问题。 - -* Google 发明了许多机器人。 他们不喜欢无聊。 - -* 如果您可以写下修复它的步骤，那么您可能可以编写自动化来修复它。 - -* 不要做机器人可以为您做的事情。 - -* 构建机器人的结果是，理想情况下，每个页面都是真正的新页面，因此不会感到无聊。 甚至经验丰富的工程师也可能在每次寻呼机关闭时都看到一些新内容。 - -* **这是哲学的根本变化。 如果一切正常，重复的事件很少，则意味着您在调试系统时不会像以前那样沉迷于此。** - -## 需要更强大的调试工具 - -* **如果所有问题都是新问题，则意味着您需要更强大的调试工具来查找问题。** - -* 文本日志不是调试工具。 如果您不知道要查找的内容，则在日志文件中查找模式的标准调试无法扩展。 使用 GCP 大小的平台，您需要浏览多少个外观才能找到失败的外观？ - -* Google 严重依赖各种可视化工具来解决不熟悉的问题并尽快恢复服务。 - -* 绘图工具：石墨，InfluxDB + Grafana，OpenTSDB。 - - * 这些和其他提到的工具不是 Google 使用的工具，因此不建议使用，但它们是有用工具的开放源代码示例。 - - * 很高兴看到正在发生的一切。 Google 拥有数十亿亿个流程，因此您需要汇总视图才能理解事物。 - - * **Google 在其二进制文件中放置了很多工具。** 在新情况下，您并不总是知道您要寻找的东西。 - -* 创建一个框架，使开发人员可以轻松地插入监视框架。 - -* 大量存储空间专门用于存储监视数据。 - - * **这个想法是您不想在中断期间进行故障排除。 中断仅与恢复服务有关。** - - * 故障排除是您稍后醒来时要执行的操作。 开发人员通常具有很深的系统知识，因此经常参与故障排除过程。 - - * 历史数据必须可用，以便故障恢复后可以进行故障排除。 恢复不会导致中断监视数据丢失。 - - * 这种方法可以使停机时间尽可能短，同时可以在以后解决问题。 - -* 事件绘图-对于关联事件非常有用。 - - * 充分利用人类的模式匹配能力，很难编写机器人来做到这一点。 - - * 给出了一个图表示例，其中每行是一个数据中心，列是时间，单元格中的颜色是事件类型。 - - * 这可以帮助您找到不是单个事件的模式，例如导致级联故障的软件推出，或者一起重复出现的错误簇，或者如果您看到延迟尖峰之后立即出现错误尖峰 重复一遍。 这些都将有助于确定问题的根本原因。 - -* 可视化过程跟踪-有时您需要深入到过程级别以识别性能问题。 - - * 开源选项不多：Performance Co-Pilot + vector。 - - * Google 有一个非常复杂的框架，可将示例查询拉入存储并提供完整的跟踪记录。 - - * 视觉工具的优点是很难理解时间戳。 可视化工具使您可以更轻松地折叠，展开和比较事件。 - -* 网络流量和容量 - - * 开源选项：仙人掌，天文台和 Nagios - - * 事实证明，很多存储缓慢的问题实际上是网络问题。 - - * 如果您正在查看存储系统，但无法弄清为什么它对网络的访问速度很慢。 - - * 您需要一个工具来快速查看网络状态。 哪些链接超载？ 您看到多少个包错误？ 链接断开了吗？ - -* 日志文件-当所有其他失败时 - - * 开源：ElasticSearch + Logstash（+ Kibana） - - * 您不想浏览日志文件。 您需要一个具有更多 SQL 之类的查询的系统，以便您可以挖掘日志。 - - * 日志应易于使用且易于理解。 - -## Stackdriver 错误报告 - -* 如果您想看一下 SRE 所拥有的那种工具的例子，那么请看 [Google Stackdriver 错误报告](https://cloud.google.com/error-reporting/) 。 - - * 这是他们能够用于服务的内部工具。 - - * 通过分析堆栈跟踪将分组错误并进行重复数据删除 - - * 系统了解所使用的通用框架并相应地对错误进行分组。 - -* 该计划将做更多。 Google 内部拥有一套广泛的工具，他们希望向云客户提供这些工具。 - -## 相关文章 [ - -* [在 HackerNews](https://news.ycombinator.com/item?id=12116121) 上/ [在 Reddit](https://www.reddit.com/r/programming/comments/4tg31p/how_does_google_do_planetscale_engineering_for_a/) 上 -* 图书：[网站可靠性工程：Google 如何运行生产系统](https://www.amazon.com/Site-Reliability-Engineering-Production-Systems-ebook/dp/B01DCPXKZ6)。 它是由从事实际 SRE 工作的实际 Google SRE 编写的，是作者 500 年综合经验的结果。 -* [大规模计算，或者说 Google 如何扭曲我的大脑](http://matt-welsh.blogspot.com/2010/10/computing-at-scale-or-how-google-has.html) -* [网站可靠性工程师-使 Google 保持 24/7 全天候运行](http://transcriptvids.com/v2/yXI7r0_J29M.html) -* [服务水平和错误预算](https://www.usenix.org/conference/srecon16/program/presentation/jones) -* [SREcon](https://www.usenix.org/conference/srecon16) 。 会议视频[可用](https://www.usenix.org/conference/srecon16/program)。 看起来内容很多。 -* [小组：谁/什么是 SRE？](https://www.usenix.org/conference/srecon16/program/presentation/definition-of-sre-panel) -* [策略：规划停电的 Google 样式](http://highscalability.com/blog/2010/3/5/strategy-planning-for-a-power-outage-google-style.html) -* [Google 如何备份互联网以及 EB 级其他数据](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html) -* [什么是“网站可靠性工程”？](https://landing.google.com/sre/interview/ben-treynor.html) -* [成为 Google 的网站可靠性工程师（SRE）感觉如何？](https://www.quora.com/What-is-it-like-to-be-a-Site-Reliability-Engineer-SRE-at-Google) -* [我的警惕](https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/preview#)的哲学，作者：Rob Ewaschuk，Google SRE -* [这是 Google 确保（几乎）永不衰败的方式](http://www.wired.com/2016/04/google-ensures-services-almost-never-go/) - -FWIW，Stack Driver 并不是他们能够用于服务的内部工具； 这是 Google 购买的 SaaS 创业公司。 - -https://techcrunch.com/2014/05/07/google-acquires-cloud-monitoring-service-stackdriver/ \ No newline at end of file +Flickr only store a reference to an image in their databases, the actual file is stored on a separate storage server elsewhere on the network. \ No newline at end of file diff --git a/docs/180.md b/docs/180.md index 9a95285..5dae4cd 100644 --- a/docs/180.md +++ b/docs/180.md @@ -1,13 +1,395 @@ -# TripAdvisor 的短 +# 为在现代时代构建可扩展的有状态服务提供依据 -> 原文： [http://highscalability.com/blog/2011/6/14/a-tripadvisor-short.html](http://highscalability.com/blog/2011/6/14/a-tripadvisor-short.html) +> 原文： [http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html](http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html) -有时我会收到文章建议，然后没有后续行动。 尽管这些 TripAdvisor 数据点来自 2010 年，但我认为值得分享： +![](img/6e13e9978e8b0a2796ba7310ca6b4db0.png) -> 我们的网站每天提供超过 1 亿个动态生成的页面浏览量（所有媒体和静态内容均通过 CDN 进行），并且我们使用约 100 台机器（无单点故障）来完成此任务，并由响应超过 2B 的分布式服务体系结构支持 需要一天的时间，以及一个超过 20TB 的数据仓库，用于推动电子邮件活动，搜索引擎营销和常规报告。 我们是 Linux / Java / Apache / Tomcat / Postgres / Lucene 商店，并且已经建立了自己的分布式计算架构。 我们还维护重复的数据中心（一个活动，一个备用），以实现冗余和维护目的。 +长期以来， [无状态服务](https://en.wikipedia.org/wiki/Service_statelessness_principle) 一直是可扩展性的皇家之路。 几乎所有关于可伸缩性的论文都将无状态声明为构建可伸缩系统的最佳实践认可方法。 无状态架构易于水平扩展，只需要简单的循环负载平衡即可。 -Too bad, it sounds like it would have been a good article. +什么是不爱的？ 从往返到数据库的延迟可能增加了。 或者，隐藏数据库延迟问题所需的缓存层的复杂性。 甚至是麻烦的一致性问题。 -## 相关文章 [ +但是有状态服务呢？ 是不是通过将功能传递给数据而不是将数据传递给功能来保留身份，是不是更好的方法？ 通常是这样，但是我们对如何构建有状态服务知之甚少。 实际上，进行搜索后，构建状态服务的系统方法几乎没有。 维基百科甚至没有 *有状态服务* 的条目。 -* [Mac Slocum 在“数据驱动的站点”](http://radar.oreilly.com/2010/09/a-new-twist-on-data-driven-sit.html) 上的新变化。 *十亿个应用程序数据如何塑造 TripAdvisor 的网站。* \ No newline at end of file +[Caitie McCaffrey](https://twitter.com/caitie?lang=en) （Twitter 上的可观察性技术负责人）正在通过 [奇怪循环](http://www.thestrangeloop.com/) 会议，关于 [构建可扩展的有状态服务](https://www.youtube.com/watch?v=H0i_bXKwujQ) （ [幻灯片](https://speakerdeck.com/caitiem20/building-scalable-stateful-services) ）。 + +令人耳目一新，因为我从未听说过以 Caitie 谈论构建有状态服务的方式来构建有状态服务。 您会认识到大多数想法-粘滞会话，数据传送范例，功能传送范例，数据局部性，CAP，集群成员资格，八卦协议，一致性哈希，DHT-但她将它们围绕构建有状态服务的主题进行了编织 以最引人注目的方式 + +对我来说，这次谈话的亮点是，当 Caitie 将整个谈话围绕在讨论她使用 Microsoft 的 [奥尔良](http://dotnet.github.io/orleans) 开发 Halo 4 的经历时 Azure 的。 奥尔良的覆盖面不足。 它基于固有的有状态分布式虚拟 Actor 模型； 集群成员资格使用高度可用的八卦协议； 并使用两层一致性哈希加上分布式哈希表的系统进行工作分配。 使用此方法，当节点发生故障，容量增加/收缩或节点变热时，奥尔良可以重新平衡群集。 结果是 Halo 能够在生产环境中运行有状态的奥尔良群集，整个群集的 CPU 利用率为 90-95％。 + +奥尔良并不是唯一涵盖的示例系统。 还使用 Caitie 的状态架构框架分析了 Facebook 的 Scuba 和 Uber 的 Ringpop。 还有一个非常有趣的部分，介绍 Facebook 如何通过将内存生存期与进程生存期脱钩，为大型内存数据库巧妙地实现快速数据库重启。 + +因此，让我们开始学习如何构建有状态服务... + +## 无状态服务是浪费 + +* 无状态服务运行良好。 通过在需要时添加新的无状态服务实例，将规范的真理源存储在数据库中并进行水平扩展非常有效。 + +* 问题在于我们的应用程序确实具有状态，并且我们达到了一个数据库不再削减的极限。 作为回应，我们将分片关系数据库或使用 NoSQL 数据库。 这会放弃强大的一致性，从而导致部分数据库抽象泄漏到服务中。 + +* **数据传送范例** + + * 客户端发出服务请求。 该服务与数据库对话，并且数据库以一些数据答复。 该服务进行一些计算。 答复将发送到客户端。 然后数据从服务中消失。 + + * 下一个请求将负载平衡到另一台计算机，并且整个过程将再次发生。 + +* **对于涉及在一段时间内在会话中运行的健谈客户端的应用程序，将资源反复提取到负载平衡服务**中非常浪费。 示例：游戏，订购产品，您要更新有关自己的信息的任何应用程序。 + +## 有状态服务更易于编程 + +* 注意：有状态服务不是魔术。 如果需要水平可伸缩性，那么无状态服务仍然非常有效。 但是有状态服务确实提供了很多好处。 + +* **数据位置** 。 将请求发送到保存有操作所需数据的计算机的想法。 优点： + + * **低延迟** 。 不必为每个单独的请求访问数据库。 仅当数据内存不足时才需要访问数据库。 网络访问的数量减少了。 + + * **数据密集型应用程序** 。 如果客户需要处理一堆数据，那么所有数据都将可以访问，因此可以快速返回响应。 + +* **功能传送范例** + + * 客户端发出请求或启动会话，一次访问数据库将获取数据，然后数据移入服务。 + + * 处理请求后，数据留在服务上。 客户端下一次发出请求时，请求将路由到同一台计算机，这样它就可以处理内存中已存在的数据。 + + * 避免了额外的数据库访问，从而减少了延迟。 即使数据库关闭，也可以处理该请求。 + +* 有状态性导致**的使用率更高[​​HTG1] **，并且一致性更高** **模型**。** + + * 在我们有不同级别的一致性的 CAP 世界中，某些级别比其他级别更可用。 当存在分区时，CP 系统选择一致性而不是可用性，而 AP 系统选择可用性而不是一致性。 + + * 如果我们要在 AP 下拥有更多高可用性的系统，我们将获得“读取读取”，“单调读取”，“单调写入”。 （ [用于定义](http://www.cs.rice.edu/~druschel/comp413/lectures/replication.html) ） + + * 如果我们有粘性连接，其中单个用户的数据在单台计算机上，那么您可以拥有更强的一致性保证，例如“读取写入”，“流水线随机存取存储器”。 + + * [Werner Vogel 2007](http://www.allthingsdistributed.com/2007/12/eventually_consistent.html) ：是否可以实现读，写，会话和单调一致性，通常取决于客户端对执行服务器的“粘性” 他们的分布式协议。 如果每次都使用同一台服务器，则保证读取和单调读取相对容易。 这使得管理负载平衡和容错的难度稍大一些，但这是一个简单的解决方案。 使用粘性的会话可以使这一点变得明确，并提供客户可以推理的暴露水平。 + + * **粘性连接使客户可以更轻松地推断** 的模型。 不必担心数据被拉到许多不同的计算机中，也不必担心并发性，您只需要让客户端与同一台服务器通信即可，这更容易考虑，并且在对分布式系统进行编程时会大有帮助。 + +## 建立粘性连接 + +* 客户端向服务器集群发出请求，并且该请求始终路由到同一台计算机。 + +* 最简单的方法是 **打开持久的 HTTP 连接** 或 TCP 连接。 + + * 易于实现，因为连接意味着您始终在与同一台机器通信。 + + * 问题：连接断开后，粘性消失了，下一个请求将被负载平衡到另一台服务器。 + + * 问题：负载平衡。 有一个隐含的假设，即所有粘性会话都将持续大约相同的时间，并产生大约相同的负载。 通常情况并非如此。 如果连接过多的单个服务器，连接持续很长时间或者每个连接都要做很多工作，那么很容易使连接过多的单个服务器不堪重负。 + + * **必须实现背压** **，以便服务器在连接不堪重负时断开连接。 这导致客户端重新连接到希望减轻负担的服务器。 您还可以根据自由分配的资源量进行负载均衡，以更公平地分配工作。** + +* **在集群**中实现路由 **更聪明。 客户端可以与群集中的任何服务器通信，该服务器会将客户端路由到包含正确数据的服务器。 需要两个功能：** + + * **群集成员资格** 。 谁在我的集群中？ 我们如何确定可以与哪些机器通信？ + + * **工作分配** 。 负载如何在整个群集中分配？ + +## 集群成员资格 + +* 群集成员资格系统共有三种常规类型：静态，八卦协议，共识系统。 + +### 静态集群成员资格-最简单的方法 + +* 可以从最笨的事情开始，看看它是否满足您的需求。 + +* 最简单的方法是一个配置文件，其中包含集群中节点的所有地址。 配置文件分发到每台计算机。 + +* 易于执行，但操作起来很痛苦。 + +* 对于必须高度可用的服务不是一个很好的选择。 + +* 它不是容错的。 如果机器出现故障，则必须更换它并更新配置。 + +* 很难扩展集群。 要添加计算机，必须重新启动整个集群，以便可以在整个集群之间正确地重新平衡工作。 + +### 动态集群成员资格 + +* 可以从群集中动态添加或删除节点。 + +* 要增加容量或补偿故障，可以将节点添加到群集并立即开始接受负载。 也可以通过删除节点来减少容量。 + +* 处理集群成员资格的两种主要方法：八卦协议和共识系统。 + +### 八卦协议-强调可用性 + +* 八卦协议通过发送消息在整个小组中传播知识。 + +* 消息中提到了他们可以与谁交谈，谁还活着，谁死了。 每台机器都将自己从数据中找出其收集集群中谁的世界视图。 + +* 在稳定状态下，集群中的所有机器将汇聚在一起，以对谁是活着还是死了的世界具有相同的世界观。 + +* 在网络故障，网络分区或添加或删除容量的情况下，群集中的不同计算机可以对群集的谁拥有不同的世界观。 + +* 需要权衡。 您具有高可用性，因为不需要任何协调，每台机器都可以根据自己的世界观进行决策，但是您的代码必须能够处理在故障期间路由到不同节点的不确定性。 + +### 共识系统-强调一致性 + +* 群集中的所有节点将具有完全相同的世界视图。 + +* 共识系统控制集群中每个人的所有权。 当配置更改时，所有节点都基于拥有真实集群成员资格的共识系统更新其世界观。 + +* 问题：如果无法使用共识系统，则节点将无法路由工作，因为它们不知道集群中的成员。 + +* 问题：由于向系统添加了协调，因此速度会变慢。 + +* 如果您需要高可用性，则除非确实有必要，否则应避免使用共识系统。 + +## 工作分配 + +* 工作分配是指如何在整个集群中移动工作。 + +* 有三种类型的工作分配系统：随机放置，一致哈希，分布式哈希表。 + +### 随机放置 + +* 听起来很傻，但是可以有效。 它适用于在集群中分布着大量数据和查询的情况下处理大量数据的情况。 + +* 写入到具有容量的任何计算机。 + +* 读取操作需要查询集群中的每台计算机，以取回数据。 + +* 这不是固定连接，而是有状态服务。 这是构建内存索引和缓存的好方法。 + +### 一致的哈希-确定性放置 + +* 基于哈希（可能是会话 ID 或用户 ID）的确定性的对节点的放置，具体取决于工作负载的划分方式。 + +* 当节点被映射到集群时，请求也被映射到环，然后您继续向前走以找到将要执行请求的节点。 + +* 由于确定性的位置，像 Cassandra 这样的数据库经常使用这种方法。 + +* 问题：热点。 + + * 许多请求最终可能被散列到同一节点，并且该节点被流量所淹没。 或节点速度可能很慢，也许磁盘坏了，甚至正常数量的请求也淹没了它。 + + * 哈希值不一致，因此无法移动工作以降温热点。 + + * 因此，您必须在群集中分配足够的空间，才能以足够的净空运行，以容忍确定性的放置以及无法移动工作这一事实。 + + * 这种额外的容量是额外的成本，即使在正常情况下也必须承担。 + +### 分布式哈希表（DHT）-非确定性放置 + +* 哈希用于在分布式哈希表中查找，以查找应将工作发送到的位置。 DHT 保留对群集中节点的引用。 + +* 这是不确定的，因为没有任何事情迫使工作去到特定的节点。 重新映射客户端很容易，以便在某个节点不可用或温度过高时将其转到其他节点。 + +## 现实世界中的三个示例状态服务 + +### Facebook 的潜水-写作时随机散布 + +* Scuba 是一个快速可扩展的分布式内存数据库，用于代码回归和分析，错误报告，收入以及性能调试。 （ [更多信息](https://research.facebook.com/publications/456106467831449/scuba-diving-into-data-at-facebook/) ） + +* 它必须非常快并且始终可用。 + +* 想法是它使用静态集群成员身份，尽管本文没有明确说明。 + +* Scuba 在写入时使用随机扇出。 读取时查询每台机器。 所有结果均由运行查询的计算机返回并组成，并将结果返回给用户。 + +* 在现实世界中，机器不可用，因此运行查询时会尽力而为。 如果不是所有节点都可用，则查询将返回可用数据的结果以及有关它们处理的数据百分比的统计信息。 用户可以决定结果是否满足足够高的质量阈值。 + +* 没有使用粘性连接，但数据在内存中，因此查找速度非常快。 + +### Uber 的铃声-八卦协议+一致性哈希 + +* Ringpop 是一个 node.js 库，用于实现应用程序层分片。 （ [更多信息](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) ） + +* Uber 有旅行的概念。 要开始旅行，用户订购一辆需要骑手信息和位置信息的汽车，在整个骑行过程中会更新数据，并且必须在旅行结束时处理付款。 + +* 对于这些更新中的每一个，每次都将负载平衡到不同的无状态服务器将是低效率的。 数据将不断保存到数据库中，然后再次拉回。 这会导致大量延迟和数据库上的额外负载。 + +* 该设计实现了路由逻辑，因此可以将对用户的所有请求定向到单个计算机。 + +* 游泳八卦协议用于维护群集成员身份。 这是 AP 群集成员身份协议，因此不能保证始终正确。 选择可用性而不是正确性是因为用户始终可以订购汽车，这一点更为重要。 + +* 一致性哈希用于在整个群集中路由工作。 这具有热节点问题，并且唯一的补救措施是增加更多的容量，即使没有充分利用其他节点。 + +### 微软的奥尔良-八卦协议+一致的哈希+分布式哈希表 + +* Orleans 是用于基于 Actor 模型构建分布式系统的运行时和编程模型。 （ [更多信息](http://research.microsoft.com/en-us/projects/orleans/) ） + +* 奥尔良来自 Extreme Computing Group 的 Microsoft Research。 演示者（Caitie McCaffrey）与该小组合作，在运送 Halo 4 的过程中使 Orleans 产品化。所有 Halo 4 服务主要在 Orleans 上重建。 + +* Actor 是计算的核心单元。 Actor 使用整个集群中的异步消息相互通信。 当 Actor 收到消息时，它可以执行以下一项或多项操作：发送一条或多则消息，更新其内部状态，创建新的 Actor。 + +* 在基于 Actor 模型的集群中，您有一堆正在运行的状态机，因此，如果 Actor 模型在请求之间保持状态不变，则它们固有地是有状态的。 + +* 在 Halo 4 中，他们将部署一台机器集群，而奥尔良则负责其余的工作。 + +* 请求将发送到群集中的任何计算机。 群集将查找 Actor 在群集中的居住位置，并将消息路由到 Actor。 + +* 成千上万的 Actor 在集群中的单台计算机上运行。 + +* 闲话协议用于集群成员身份，以使其具有较高的可用性。 由于 Orleans 是开源的，因此创建了 Zookeeper 实现，这比较慢。 + +* 对于工作分配，奥尔良使用一致哈希+分布式哈希表的组合。 + + * 将对 Actor 的请求发送到集群时，Orleans 运行时将在 Actor ID 上计算一致的哈希。 哈希映射到具有该 ID 的分布式哈希表的计算机。 + + * Actor 的分布式哈希表知道哪台计算机包含指定 ID 的 Actor。 + + * 在咨询了 DHT 之后，请求被路由到适当的机器。 + +* 一致性哈希用于查找 Actor DHT，因此这是确定性操作。 DHT 在群集中的位置不会更改。 而且，由于 DHT 中的数据量很小并且 Actor DHT 分布均匀，因此热点并不是大问题。 + +* 演员正在做的事情不是均匀分布和平衡的。 + +* 奥尔良能够自动重新平衡群集。 在以下情况下，可以更新 DHT 中的条目以指向新机器： + + * 会话终止。 + + * 机器发生故障，因此必须分配新的机器。 + + * 由于没有人在与演员交谈，因此将其从记忆中逐出。 + + * 机器温度过高，因此奥尔良将 Actor 移到容量更大的另一台机器上，这样热机器就不会发生故障。 + +* Orleans 的重新平衡功能是 Orleans 群集可以在整个群集中以 90-95％的 CPU 利用率在生产中运行的核心原因。 能够以不确定的方式移动工作，这意味着您可以使用盒子的所有容量。 + +* 此方法可能不适用于数据库，但对于将状态引入服务非常有用。 + +## 可能出错的地方 + +### 无限数据结构 + +* 在有状态系统中，无限制的数据结构是消亡的好方法。 示例：无限制的队列，无限制的内存结构。 + +* 在无状态服务中，我们无需经常考虑这一点，因为它们可以从此类短暂故障中恢复。 + +* 在有状态服务中，服务可以获取很多请求，因此必须在数据结构上放置明确的界限，否则它们可能会不断增长。 然后，您可能会用完内存，或者您的垃圾收集器可能会使世界停止运转，并且该节点可能看起来已经死了（我还要补充一点，随着数据结构的增长，锁可以保留很长时间）。 + +* 客户不是您的朋友。 客户不会做您想要他们做的事。 机器可能会死于隐性假设，即我们不会用完内存，否则客户端只会发送合理数量的数据。 代码必须保护自己免受客户侵害。 + +### 内存管理 + +* 因为数据会在会话的整个生命周期内（可能是几分钟，几小时甚至几天）保持在内存中，所以内存将进入寿命最长的垃圾回收。 通常，收集该内存的成本更高，尤其是当存在跨代的引用时。 + +* 您必须更加了解内存在有状态服务中的工作方式，并且实际上需要了解垃圾收集器的运行方式。 + +* 或者，您也可以使用非托管代码（例如 C ++）编写所有内容，因此您不必处理垃圾收集器问题。 + +* 奥尔良运行 [.NET CLR](https://en.wikipedia.org/wiki/Common_Language_Runtime) ，这是一个垃圾收集环境，确实遇到了跨代垃圾收集问题。 + + * 通过调整垃圾收集器来处理。 + + * 这也通过实现许多不必要状态的持久化来处理。 您必须对所保留的内容保持谨慎，因为存在相关的成本。 + +### 重载状态 + +* 通常，在无状态服务中，必须为每个请求查询数据库，因此必须调整等待时间以解决与数据库的往返行程。 或者，您可以使用缓存来使其更快。 + +* 在有状态服务中，可以重新加载状态的时间有很多不同：第一次连接，从崩溃中恢复，部署新代码。 + +#### 首次连接 + +* 通常，这是最昂贵的连接，因为该节点上没有数据。 必须将所有数据拉入数据库，以便可以处理请求。 + +* 这可能需要很长时间，因此您要非常小心启动时加载的内容。 您不希望遇到恰好落在第一个连接上的请求带来高延迟。 + +* 在测试中使用 [百分位数](http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html) 。 平均延迟看起来不错，因为您不必每次都往返于数据库。 第一次连接延迟可能会增加，您不想错过。 + +* 在第一个连接上，如果客户端由于对数据库的访问速度较慢而超时，则您将继续尝试从数据库加载，因为您知道客户端将重试。 客户端的下一次访问将很快，因为数据很可能在内存中。 在无状态服务中，您无法进行这种优化。 + +* 例如，在 Halo 中，当游戏开始时，第一个连接有时会超时。 也许用户有很多游戏状态或连接已加载。 因此，他们会继续输入数据，并且在游戏箱重试时请求会成功。 用户不会注意到延迟，特别是考虑到用户正在观看的漂亮动画。 + +#### 从崩溃中恢复 + +* 如果必须从崩溃中恢复后为整个盒子补水，如果您没有懒惰地加载所有 Actor，这可能会很昂贵。 有时您可以摆脱延迟加载，有时则无法。 + +#### 部署新代码 + +* 要部署新代码，您必须拆卸整个包装箱，然后将其重新备份到另一个包装箱中。 如果您没有不确定的展示位置或动态集群成员身份，可能会出现问题。 + +#### [快速数据库从 Facebook 重新启动](https://research.facebook.com/publications/553456231437505/fast-database-restarts-at-facebook/) + +* Facebook 的 Scuba 产品出现重新启动问题，因为它是一个内存数据库，其中存储了许多保留在硬盘上的数据。 + +* 在崩溃或部署中，他们将关闭当前正在运行的计算机，启动新计算机，然后从磁盘读取所有内容。 每台机器要花几个小时。 而且由于他们的 SLA，Facebook 必须对其集群进行缓慢的滚动更新，这最多需要 12 个小时。 + +* 崩溃不会经常发生，因此缓慢的重启并不是一个大问题。 我们希望代码部署经常发生，以便我们可以更快地迭代，尝试新想法，降低风险部署。 + +* Facebook 做出了一个关键的观察，即您可以 **将内存寿命与进程寿命** 分开，尤其是在有状态服务中。 + +* 当 Facebook 想部署新代码，并且知道这是安全的关闭并且内存没有损坏时，他们将：停止接收请求，将数据从当前运行的进程复制到共享内存，关闭旧进程，引入 启动新进程，然后将共享内存中的数据复制回进程内存空间，然后重新启动请求。 + +* 此过程需要几分钟，因此群集重新启动的时间现在是 2 小时而不是 12 小时。 现在，可以比以前更频繁地部署新代码。 + +* Twitter 正在考虑为有状态索引实施此策略，当整个计算机重新启动时，它必须与他们的 Manhattan 数据库通信，这与内存相比确实很慢。 + +## 总结 + +* 集群成员资格和工作分配中有很多工作和思想。 + + * 没有正确的答案。 + + * 她偏向可用一侧，因此更喜欢八卦协议。 + + * 对于工作分配，取决于工作量。 + +* 在现实世界中运行着许多成功的有状态系统。 事实证明，您可以大规模地进行这项工作，因此尽管它是新领域，但并没有太吓人。 + +* **请谨慎** ，因为如果您以前没有做过有状态服务，那么这就是新领域。 经历不同的地方，发生了什么变化，做出的假设，并确保您的假设明确。 + +* **阅读论文**。 不要重新发明自己的协议。 这实际上不是新领域。 自 60 年代和 70 年代以来，人们一直在为此工作。 大部分讨论来自数据库文献。 这些问题已经解决。 您可以根据您的应用程序挑选您关心的内容。 您不必实施整个文件，只需实施所需的文件即可。 + +## 相关文章 + +* [关于黑客新闻](https://news.ycombinator.com/item?id=10378219) + +* [CaitieM.com](http://caitiem.com/) 是 Caitie McCaffrey 的博客。 + +* [应用英雄模式](https://www.youtube.com/watch?v=xDuwrtwYHu8) + +* [晕 4：高需求，低延迟和高可用性](https://www.youtube.com/watch?v=5P4qMBXT4P8) + +* [奥尔良：云计算框架](https://www.youtube.com/watch?v=pkdeXGg7D98) + +* [架构和启动 Halo 4 服务](https://www.youtube.com/watch?v=fJSnM6CWcAs) + +* [重新平衡群集](https://www.google.com/search?q=rebalancing+clusters&oq=rebalancing+clusters&aqs=chrome..69i57.4116j0j7&sourceid=chrome&es_sm=119&ie=UTF-8) + +* [为什么任何人都不能在没有中断的情况下启动在线服务？](http://www.gamesindustry.biz/articles/2013-11-20-why-cant-anyone-launch-an-online-service-without-outages) + +* [#WindowsAzure 经验教训：保持状态](https://alexandrebrisebois.wordpress.com/2014/02/23/windowsazure-lessons-learned-be-stateful/) + +* [使用开源奥尔良框架](http://www.gamasutra.com/blogs/AshkanSaeediMazdeh/20151008/255588/Creating_scalable_backends_for_games_using_open_source_Orleans_framework.php)创建游戏的可扩展后端 + +无状态服务也很容易，以易于理解和预测的方式交易一些额外的资源，以完全消除所有类的问题（例如，升级期间长期存在的会话会发生什么情况）。 + +对我来说，最重要的是，如果您不是*还是*构建下一个 Halo 或 Twitter，则最初说明的构建 12Factor 应用程序的大多数原因仍然适用。 而且我们大多数人不是。 那是一件好事。 + +与服务满足一个请求后，使用缓存保留数据有何不同？ 只是我没有将应用程序服务器保存数据，而是将其保存在部署在一组专用服务器上的分布式缓存中。 如果状态保持在分布式哈希图中，并保持从服务逻辑（服务）到分布式哈希图（缓存）的持久连接，那它将是有状态服务吗？ + +看看 Azure Service Fabric（https://azure.microsoft.com/zh-cn/campaigns/service-fabric/）。 它带来了奥尔良的一些概念，但是包装得更好，并增加了更多的价值（Actor 提供无状态和 Statefull 可靠服务）。 + +实际上，服务结构在哈希算法上有所不同（它们没有 DHT），并且在某些其他方面，请谨慎选择。 + +这种有状态的应用程序架构可以通过多个缓存层架构轻松实现-缓存数据库中的数据，缓存处理后的数据（信息，结果）以及缓存表示数据（json，xml）。 + +> “如果需要高可用性，除非确实需要，否则应避免使用共识系统。” + +她没有那么说。 + +她说，如果您需要一个高可用性系统，那么共识系统是设计动态集群成员资格的最后手段，因为共识系统本身在故障情况下可能不可用。 + +但是她没有提到像 Hashicorp 的 Consul 这样的高可用性共识系统，在该系统中，您有服务器集群来管理该状态。 我希望她对使用此工具构建分布式系统有意见。 + +通过共识系统，我认为她指的是 Raft 或 Paxos 之类的东西，它们试图变得更加一致而不是可用（来自 CAP）。 Consul 使用 SWIM 协议进行动态成员资格，另一方面，该协议可用而不是一致的。 SWIM 允许部分可用性进行操作，而 Raft 或 Paxos 等系统则不允许。 我相信她只是重新开始了 Peter Bailis 所说的，除非您确实需要，否则不要使用 CP 系统。 + +非常感谢您对 Caitie McCaffrey 演示文稿的写作。 这是一个接近完美的成绩单，而且是一个很好的介绍。 没有它，我可能会错过她的演讲。 + +自 2000 年以来，我一直在从事 MMO 游戏服务器的开发。在大部分时间里，这一直是一个很小的利基市场。 像大多数分布式系统一样，MMO 必须扩展。 但是，与大多数其他分布式体系结构不同，MMO 是高度有状态的。 + +直到最近，我还没有从游戏界之外找到许多解决这些问题的例子。 同样，游戏工作室/发行商传统上也不愿意分享他们的“商业秘密”。 结果，当开发人员在工作室之间移动时，对这些概念的了解往往会缓慢扩散。 + +很高兴看到我们在 MMO 空间中使用的一些以这种方式验证的技术。 看到这些想法得到改进和增强也很酷。 持久连接，是的。 背压是必须的吗？ 嗯..很明显，但是我们没有这样做。 当然，可以通过一致的哈希值进行分片。 分布式哈希表？ 哦，希望我们也这样做。 我们会探索这样的想法，但是常常会发现，在没有证据证明别人已经证明自己的价值的情况下，很难为进行这些工作辩护。 + +我很高兴看到该主题在更广泛的背景下获得了一些“合法性”。 很高兴知道我们 MMO 开发人员并不孤单。 :) + +干杯! + +对不起，如果我错过了什么。 但是，这篇演讲并没有说明如果有状态节点死亡将导致的数据丢失。 FB 的共享内存方法是一种方法，但是在这种方法中，我们是在关闭节点之前显式复制数据/但是什么是节点/ VM / PhysicalMachine 突然崩溃。在这种情况下不会丢失数据 ？ + +> 但是，这篇演讲并没有说明如果有状态节点死亡将导致的数据丢失。 + +如果仅将状态保留在内存中，则只会丢失数据。 您真正要做的是主要使用内存，但也可以在外部存储状态，以便您可以恢复。 例如，Akka 具有持久性的“事件源”模型-参与者可以持久/发出代表其内部状态变化的事件； 如果由于故障或重新平衡而需要重新启动 actor，则将回放这些事件，以便 actor 可以恢复其状态。 \ No newline at end of file diff --git a/docs/181.md b/docs/181.md index 7847cf9..0c9de15 100644 --- a/docs/181.md +++ b/docs/181.md @@ -1,50 +1,217 @@ -# Evernote Architecture-每天有 900 万用户和 1.5 亿个请求 +# 细分：使用 Docker，ECS 和 Terraform 重建基础架构 -> 原文： [http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150-million-reques.html](http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150-million-reques.html) +> 原文： [http://highscalability.com/blog/2015/10/19/segment-rebuilding-our-infrastructure-with-docker-ecs-and-te.html](http://highscalability.com/blog/2015/10/19/segment-rebuilding-our-infrastructure-with-docker-ecs-and-te.html) -![](img/2b7cd4ef58b70bf0a20de70c8654141f.png) +![](img/a939f3fd03c443a26b496a50125abdea.png) -[Evernote](http://evernote.com/) 的人们很友好，可以在标题为 [Architectural Digest](http://blog.evernote.com/tech/2011/05/17/architectural-digest/#) 的帖子中写出他们的体系结构概述。 Dave Engberg 描述了他们的网络，分片，用户存储，搜索和其他自定义服务的方法。 +*这是[段](https://www.linkedin.com/in/calvinfo)的 CTO /联合创始人 [Calvin French-Owen](https://www.linkedin.com/in/calvinfo) 的来宾[重新发布](https://segment.com/blog/rebuilding-our-infrastructure/)。* -Evernote 是一个很棒的应用程序，部分实现了 [Vannevar Bush](http://en.wikipedia.org/wiki/Vannevar_Bush) 对 [memex](http://en.wikipedia.org/wiki/Memex) 的惊人[视觉](http://commons.nwc.hccs.edu/dylla/2011/02/08/6/)。 维基百科简要地描述了 Evernote 的功能： +在 Segment 成立之初，我们的基础设施遭到了相当大的破坏。 我们通过 AWS UI 设置了实例，拥有未使用的 AMI 的墓地，并且通过三种不同的方式实现了配置。 -> Evernote 是一套用于记录和存档的软件和服务。 “注释”可以是一段可格式化的文本，完整的网页或网页摘录，照片，语音备忘录或手写的“墨水”注释。 注释也可以具有文件附件。 然后可以将注释分类到文件夹中，进行标记，添加注释，进行编辑，给定注释并进行搜索。 Evernote 支持多种操作系统平台（包括 Android，Mac OS X，iOS，Microsoft Windows 和 WebOS），并且还提供在线同步和备份服务。 +随着业务开始腾飞，我们扩大了 eng 团队的规模和体系结构的复杂性。 但是，只有少数知道神秘奥秘的人才能从事生产工作。 我们一直在逐步改进流程，但是我们需要对基础架构进行更深入的检查，以保持快速发展。 -这里的关键是 Evernote 存储了大量数据，这些数据必须进行搜索，并通过它们的云同步到您使用的任何设备。 +所以几个月前，我们坐下来问自己：*“如果今天设计基础架构设置会是什么样？”* -另一个关键是 Evernote 的业务模式和成本结构的影响。 Evernote 以其首席执行官的想法为基础，以[免费增值模式](http://www.fastcompany.com/magazine/147/next-tech-remember-the-money.html)的开创而著称：*获得 100 万人付款的最简单方法是让 10 亿人使用。* Evernote 旨在以 1％的转化率实现盈利。 免费的在线服务将用户限制为每月 60 MB，而高级用户每年需支付 45 美元才能使用 1000 MB /月。 为了盈利，他们大多数会存储大量数据而无需花费大量金钱。 没有太多的额外空间，这说明了其架构的简单实用性。 +在 10 周的过程中，我们完全重新设计了基础架构。 我们几乎淘汰了每个实例和旧配置，将服务移至可在 Docker 容器中运行，并切换到使用新的 AWS 账户。 -这篇文章简短明了，因此一定要详细阅读。 一些要点： +我们花了很多时间思考如何制作可审核，简单易用的生产设置，同时仍具有扩展和增长的灵活性。 -* **控制成本**。 Evernote 在加利福尼亚州圣塔克拉拉的数据中心用完了一对专用机架。 使用云将无法以足够便宜的成本提供足够的处理能力和存储，从而无法使 Evernote 的业务模型正常工作。 由于他们的负载似乎并不尖锐，因此使用他们自己的 colo 站点非常有意义，尤其是考虑到他们如何利用 VM 来提高可靠性。 -* **基于数据**的性质的体系结构。 用户注释彼此独立，这对于 Evernote 在 90 个分片中将其 950 万总用户分片非常实用。 每个分片都是一对两个四核 Intel SuperMicro 盒，它们具有大量 RAM 和采用镜像 RAID 配置的 Seagate Enterprise Drive *完整机箱。 所有存储和 API 处理均由分片处理。 他们发现使用直接连接的存储具有最佳的性价比。 使用具有相同冗余级别的远程存储层将花费更多的成本。 将驱动器添加到服务器并使用 DRDB 复制的开销和成本都很低。* -* **应用冗余**。 每个盒子运行两个虚拟机。 主 VM 运行核心堆栈：Debian + Java 6 + Tomcat + Hibernate + Ehcache +条纹+ GWT + MySQL（用于元数据）+分层本地文件系统（用于文件数据）。 DRDB 用于将主 VM 复制到另一个设备上的辅助 VM。 心跳信号用于故障转移到辅助虚拟机，因为主要虚拟机已死。 一种聪明的方式来使用这些功能强大的机器，并使用更少的资源来构建可靠的系统。 -* **数据可靠性**。 用户数据存储在两个不同物理服务器上的四个不同企业驱动器上。 每晚备份通过专用的 1Gbps 链路将数据复制到辅助数据中心。 -* **快速请求路由**。 用户帐户信息（用户名，MD5 密码和用户分片 ID）存储在内存中的 MySQL 数据库中。 可靠性来自 RAID 镜像，到辅助磁盘的 DRBD 复制以及每夜备份。 这种方法使用户向其数据的路由成为一种简单而快速的内存中查找，同时仍然具有很高的可用性。 -* 一个由 28 个 8 核服务器组成的单独池处理图像以进行搜索，手写识别和其他服务。 这是自定义软件，是功能强大的附加值，其他任何人都无法轻易复制。 -* Puppet 用于配置管理。 -* 使用 Zabbix，Opsview 和 AlertSite 进行监视。 +这是我们的解决方案。 -未来的文章有望将重点放在单个子系统上。 我很期待这些，因为您必须欣赏他们为其业务模型创建的系统的优雅性。 一个值得学习的好例子。 +## 单独的 AWS 账户 -## 相关文章 [ +我们没有使用区域或标签来分隔不同的暂存和生产实例，而是切换了完全独立的 AWS 帐户。 我们需要确保我们的配置脚本不会影响我们当前正在运行的服务，并且使用新帐户意味着我们一开始就有空白。 -* [与 Phil Libin 讨论 EverNote 的新 memex](http://blog.jonudell.net/2008/04/07/a-conversation-with-phil-libin-about-evernotes-new-memex/) ，作者：乔恩·乌德尔（Jon Udell） -* [笔记软件](http://en.wikipedia.org/wiki/Comparison_of_notetaking_software)的比较 -* [Evernote 宣布 Dan Dan 的“闪亮的新 Evernote 网站”](http://www.geardiary.com/2011/03/29/evernote-announces-shiny-new-evernote-web/) +![](img/d37692b17ac45e21941737ab00489b4b.png) -嗨，托德-感谢您的客气话。 在阅读您的帖子时，我进行了一些小的更正： --我们的总注册用户略超过 950 万……100k 只是我们在每个分片上输入的数字。 （每月活跃用户超过 3M） --您错过了以我的名字写的'g'...这可能意味着您是体育迷，因为那个 Dick Enberg 家伙总是把它拼错。 :-) +`ops`帐户用作跳转点和集中登录。 组织中的每个人都可以拥有一个 IAM 帐户。 -无需发布此评论，我只是认为我会通过。 -谢谢， -戴夫 +其他环境具有一组 IAM 角色，可以在它们之间进行切换。 这意味着我们的管理员帐户只有一个登录点，并且只有一个位置可以限制访问。 -感谢您所做的更正 Dave。 对那个家伙没有太大的爱，我只是很难打字:-) +例如，爱丽丝可能可以访问所有三个环境，但是鲍勃只能访问开发人员（因为他删除了生产负载平衡器）。 但是它们都通过`ops`帐户输入。 -感谢您的精彩文章！ +无需复杂的 IAM 设置来限制访问，我们可以轻松地按环境锁定用户并按*角色将其分组。* 通过界面使用每个帐户就像切换当前活动角色一样简单。 -只是一个澄清问题； 您写道：“数据可靠性。用户数据存储在两个不同物理服务器上的四个不同企业驱动器上”。 +![](img/46f7e4c58e8e48711e936e7ff2073cca.png) -您是否在此表示它们将数据存储在具有两个驱动器的一个 VM 上，然后将数据复制到另一台物理计算机上的具有两个驱动器的另一 VM 上（如下面的“应用程序冗余”所述）？ \ No newline at end of file +不必担心暂存盒可能不安全或会更改生产数据库，我们免费获得*真正隔离*。 无需额外配置。 + +能够共享配置代码的另一个好处是，我们的登台环境实际上可以反映产品。 配置上的唯一区别是实例的大小和容器的数量。 + +最后，我们还启用了各个帐户的合并结算。 我们使用相同的发票支付每月帐单，并查看按环境划分的费用的详细分类。 + +## Docker 和 ECS + +设置好帐户后，就可以设计服务的实际运行方式了。 为此，我们转向了 [Docker](https://docker.com/) 和 [EC2 容器服务（ECS）](https://aws.amazon.com/ecs/)。 + +截至今天，我们现在在 Docker 容器中运行我们的大多数服务，包括我们的 API 和数据管道。 容器每秒接收数千个请求，每月处理 500 亿个事件。 + +Docker 最大的单一好处是在一定程度上使团队能够从头开始构建服务。 我们不再需要复杂的配置脚本或 AMI，只需将生产集群交给一个映像即可运行。 不再有状态的实例，我们保证在 staging 和 prod 上运行相同的代码。 + +在将我们的服务配置为在容器中运行之后，我们选择了 ECS 作为调度程序。 + +总体而言，ECS 负责在生产中实际运行我们的容器。 它负责调度服务，将它们放置在单独的主机上，并在连接到 ELB 时重新加载零停机时间。 它甚至可以跨可用区进行调度，以提高可用性。 如果某个容器死亡，ECS 将确保将其重新安排在该群集中的新实例上。 + +切换到 ECS 大大简化了服务的运行，而无需担心新贵作业或预配实例。 就像添加一个 [Dockerfile](https://gist.github.com/calvinfo/c9ffb5c28133be525c62) ，设置任务定义并将其与集群关联一样简单。 + +在我们的设置中，Docker 映像是由 CI 构建的，然后被推送到 Docker Hub。 服务启动时，它将从 Docker Hub 中拉出映像，然后 ECS 在机器之间调度它。 + +![](img/839239df2e64e292508c30592e7895f1.png) + +我们会根据服务集群的关注程度和负载情况对其进行分组（例如，针对 API，CDN，App 等的不同集群）。 具有单独的群集意味着我们可以获得更好的可见性，并且可以决定为每个实例使用不同的实例类型（因为 ECS 没有实例相似性的概念）。 + +每个服务都有一个特定的任务定义，该任务定义指示要运行哪个版本的容器，要运行多少个实例以及要选择哪个集群。 + +在运行期间，服务向 ELB 进行自身注册，并使用运行状况检查来确认容器实际上已准备就绪。 我们在 ELB 上指向本地 Route53 条目，以便服务可以相互通信，并仅通过 DNS 进行引用。 + +![](img/fecec45b30faa825726feb884c929eac.png) + +设置很好，因为我们不需要任何服务发现。 本地 DNS 为我们完成所有簿记工作。 + +ECS 运行所有服务，我们从 ELB 获得免费的 cloudwatch 指标。 这比在启动时向中央机构注册服务要简单得多。 最好的部分是我们不必自己处理国家冲突。 + +## 使用 Terraform 进行模板化 + +Docker 和 ECS 描述了如何运行我们的每个服务的地方， [Terraform](https://terraform.io/) 是将它们结合在一起的粘合剂。 从高层次上讲，它是一组配置脚本，用于创建和更新我们的基础架构。 您可以将其视为类固醇上的 Cloudformation 版本，但这并不能使您感到惊讶。 + +除了运行一组用于维护状态的服务器外，还有一组描述集群的脚本。 配置在本地运行（并在将来通过 CI 运行）并致力于 git，因此我们可以连续记录生产基础架构的实际状况。 + +这是用于设置堡垒节点的 Terraform 模块的示例。 它创建了所有安全组，实例和 AMI，因此我们能够轻松地为将来的环境设置新的跳转点。 + +``` +// Use the Ubuntu AMI +module "ami" { + source = "github.com/terraform-community-modules/tf_aws_ubuntu_ami/ebs" + region = "us-west-2" + distribution = "trusty" + instance_type = "${var.instance_type}" +} + +// Set up a security group to the bastion +resource "aws_security_group" "bastion" { + name = "bastion" + description = "Allows ssh from the world" + vpc_id = "${var.vpc_id}" + + ingress { + from_port = 22 + to_port = 22 + protocol = "tcp" + cidr_blocks = ["0.0.0.0/0"] + } + + egress { + from_port = 0 + to_port = 0 + protocol = "-1" + cidr_blocks = ["0.0.0.0/0"] + } + + tags { + Name = "bastion" + } +} + +// Add our instance description +resource "aws_instance" "bastion" { + ami = "${module.ami.ami_id}" + source_dest_check = false + instance_type = "${var.instance_type}" + subnet_id = "${var.subnet_id}" + key_name = "${var.key_name}" + security_groups = ["${aws_security_group.bastion.id}"] + tags { + Name = "bastion-01" + Environment = "${var.environment}" + } +} + +// Setup our elastic ip +resource "aws_eip" "bastion" { + instance = "${aws_instance.bastion.id}" + vpc = true +} +``` + +我们在阶段和产品中使用相同的模块来设置我们的个人堡垒。 我们唯一需要切换的是 IAM 密钥，我们已经准备就绪。 + +进行更改也很轻松。 Terraform 不会总是拆除整个基础架构，而会在可能的地方进行更新。 + +当我们想将 ELB 耗尽超时更改为 60 秒时，只需执行简单的查找/替换操作即可，然后是`terraform apply`。 而且，两分钟后，我们对所有 ELB 进行了完全更改的生产设置。 + +它具有可复制性，可审核性和自我记录性。 这里没有黑匣子。 + +我们将所有配置都放在了`infrastructure`中央存储库中，因此很容易发现如何设置给定的服务。 + +不过，我们还没有达到圣杯。 我们希望转换更多的 Terraform 配置以利用模块，以便可以合并单个文件并减少共享样板的数量。 + +一路上，我们在`.tfstate`周围发现了一些陷阱，因为 Terraform 始终首先从现有基础架构中读取数据，并抱怨状态是否不同步。 我们最终只是将我们的`.tfstate`提交给了仓库，并在进行了任何更改之后将其推送了，但是我们正在研究 [Atlas](https://atlas.hashicorp.com/) 或通过 CI 来解决该问题。 + +## 移至 Datadog + +至此，我们有了基础架构，配置和隔离。 最后剩下的是度量和监视，以跟踪生产中正在运行的所有内容。 + +在我们的新环境中，我们已将所有指标和监视切换到 [Datadog](https://datadog.com/) ，这是出色的。 + +![](img/eb5840233aa77c22a5f2c0cf35c56775.png) + +我们一直对 Datadog 的 UI，API 以及与 AWS 的完全集成感到非常满意，但是要充分利用该工具，需要进行一些关键的设置。 + +我们要做的第一件事是与 AWS 和 Cloudtrail 集成。 它提供了 10,000 英尺的视图，可了解我们在每个环境中发生的情况。 由于我们正在与 ECS 集成，因此 Datadog feed 会在每次任务定义更新时进行更新，因此最终会免费获得部署通知。 惊人地搜索提要很容易，并且可以轻松地追溯到上一次部署或重新安排服务的时间。 + +接下来，我们确保将 Datadog-agent 作为容器添加到基本 AMI（ [datadog / docker-dd-agent](https://hub.docker.com/r/datadog/docker-dd-agent/) ）。 它不仅从主机（CPU，内存等）收集指标，而且还充当我们 statsd 指标的接收器。 我们的每项服务都会收集有关查询，延迟和错误的自定义指标，以便我们可以在 Datadog 中进行浏览并发出警报。 我们的 go 工具包（即将开源）将自动在代码行中收集 [`pprof`](https://golang.org/pkg/net/http/pprof/) 的输出并将其发送，因此我们可以监视内存和 goroutine。 + +更酷的是，代理可以可视化环境中主机之间的实例利用率，因此我们可以对可能存在问题的实例或群集进行高层概述： + +![](img/55569b1423b47df7ebf2a3074e0bf80b.png) + +此外，我的队友文斯（Vince）为 Datadog 创建了 [Terraform 提供程序，因此我们可以完全针对*实际生产配置*编写警报脚本。 我们的警报将被记录，并与产品中正在运行的警报保持同步。](https://github.com/segmentio/terraform-datadog) + +``` +resource "datadog_monitor_metric" "app.internal_errors" { + name = "App Internal Errors" + message = "App Internal Error Alerts" + + metric = "app.5xx" + time_aggr = "avg" + time_window = "last_5m" + space_aggr = "avg" + operator = ">" + + warning { + threshold = 10 + notify = "@slack-team-infra" + } + + critical { + threshold = 50 + notify = "@slack-team-infra @pagerduty" + } +} +``` + +按照惯例，我们指定两个警报级别：`warning`和`critical`。 `warning`可以让当前在线的任何人知道某些东西看起来可疑，应在任何潜在问题发生之前就将其触发。 `critical`警报是为严重的系统故障而“半夜醒来”的问题保留的。 + +更重要的是，一旦我们过渡到 Terraform 模块并将 Datadog 提供程序添加到我们的服务描述中，那么所有服务最终都会获得*免费*的警报。 数据将直接由我们的内部工具包和 Cloudwatch 指标提供动力。 + +## 让好时光泊坞窗运行 + +一旦我们将所有这些组件准备就绪，就可以开始进行转换了。 + +我们首先在新的生产环境和旧的生产环境之间建立了 [VPC 对等连接](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html)-允许我们对数据库进行集群并在两者之间进行复制。 + +接下来，我们对新环境中的 ELB 进行了预热，以确保它们可以处理负载。 亚马逊不会提供自动调整大小的 ELB，因此我们不得不要求他们提前对其进行调整（或缓慢调整规模）以应对增加的负载。 + +从那里开始，只需要使用加权的 Route53 路由将流量从旧环境稳定地增加到我们的新环境，并不断监视一切都看起来不错。 + +如今，我们的 API 蓬勃发展，每秒处理数千个请求，并且完全在 Docker 容器内运行。 + +但是我们还没有完成。 我们仍在微调我们的服务创建，并减少样板，以便团队中的任何人都可以通过适当的监视和警报轻松构建服务。 而且，由于服务不再与实例相关联，因此我们希望围绕容器的使用改进工具。 + +我们还计划关注这一领域的有前途的技术。 [Convox](https://convox.com/) 团队正在围绕 AWS 基础架构构建出色的工具。 [Kubernetes](http://kubernetes.io/) ，[中层](https://mesosphere.com/)， [Nomad](https://nomadproject.io/) 和 [Fleet](https://github.com/coreos/fleet) 看起来像是不可思议的调度程序，尽管我们喜欢 ECS 的简单性和集成性。 看到它们如何被淘汰将是令人兴奋的，我们将继续关注它们以了解我们可以采用什么。 + +在所有这些业务流程变更之后，我们比以往任何时候都更加坚信将基础架构外包给 AWS。 他们通过将许多核心服务产品化而改变了游戏规则，同时保持了极具竞争力的价格。 它正在创建一种新型的初创公司，可以高效而廉价地生产产品，同时减少维护时间。 而且我们看好将在其生态系统之上构建的工具。 + +Datadog 链接已断开，它显示 SSL 错误。 正确的网址是 https://www.datadoghq.com/ + +我们是一家初创公司，我们正在尝试从头开始设置 evyrthing。 感谢您的帖子。 \ No newline at end of file diff --git a/docs/182.md b/docs/182.md index 2626912..8a2cf39 100644 --- a/docs/182.md +++ b/docs/182.md @@ -1,45 +1,39 @@ -# Facebook：用于扩展数十亿条消息的示例规范架构 +# 十年 IT 失败的五个教训 -> 原文： [http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html](http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html) +> 原文： [http://highscalability.com/blog/2015/10/28/five-lessons-from-ten-years-of-it-failures.html](http://highscalability.com/blog/2015/10/28/five-lessons-from-ten-years-of-it-failures.html) -![](img/05b2f60819d28aa5d0e59ecb0a2b699e.png) +![](img/7b85a3888743dc1d181d12abf9d70811.png) -可扩展，实时，高可用性服务的体系结构应该是什么样？ 可供开发人员使用的选项太多，但是如果您要寻找通用模板，则该架构由[后端团队的 Facebook](https://www.facebook.com/notes/facebook-engineering/scaling-the-messages-application-back-end/10150148835363920#) [消息](/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html)后端小组负责人 Prashant Malik 描述。 应用后端是一个很好的示例。 +IEEE 频谱上有一篇很棒的文章系列，介绍了数十年来 IT 失败带来的[。 这不是您的典型系列，因为有非常酷的交互式图形和图表，这些图形和图表基于从过去的项目失败中收集的数据得出。 它们真的很有趣，我只能想象将它们组合在一起需要花费多少工作。](http://spectrum.ieee.org/static/lessons-from-a-decade-of-it-failures) -尽管 Messages 的任务是每月处理来自电子邮件，IM，SMS，文本消息和 Facebook 消息的 135 亿多条消息，但您可能会认为这是 BigArchitecture 的示例，不适用于较小的站点。 不是这样 这是一个很好的，经过深思熟虑的非云架构示例，展现了任何妈妈都会为之骄傲的许多品质： +该系列的 [总收入](http://spectrum.ieee.org/riskfactor/computing/it/the-making-of-lessons-from-a-decade-of-it-failures) 为： -1. **分层**-组件独立且隔离。 -2. **服务/ API 驱动的**-每个层都通过定义明确的接口连接，该接口是访问该服务的唯一入口点。 这样可以避免令人讨厌的复杂相互依赖关系。 客户端隐藏在应用程序 API 的后面。 应用程序使用数据访问层。 -3. **分布式**-层透明地分布在计算机集群之间 -4. **单独的应用程序逻辑**-应用程序逻辑封装在提供 API 端点的应用程序服务器中。 应用程序逻辑是根据其他服务实现的。 应用服务器层还隐藏了直写式高速缓存，因为这是写入或检索用户数据的唯一位置，它是高速缓存的理想之地。 -5. **无状态**-状态保存在数据库层，缓存层或其他服务中，而不保存在应用程序中或塞在本地口袋中。 -6. **可伸缩组件服务**-其他本身可伸缩且高度可用的服务用于实现此服务。 消息还使用：Memcache，用户索引服务和 [HayStack](http://haystacksearch.org/) 。 -7. **完整堆栈操作**-开发了工具来管理，监视，识别性能问题并在整个堆栈中上下扩展整个服务。 -8. **蜂窝**-消息具有称为**单元**的机器和服务群集作为其系统的基本构建块。 如果需要更多的机长，则以递增方式添加单元。 一个单元由 [ZooKeeper 控制器](/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html)，应用服务器集群和[元数据存储](https://www.facebook.com/note.php?note_id=454991608919)组成。 单元提供隔离，因为处理请求的存储和应用程序功能独立于其他单元。 单元可能会发生故障，升级并在与其他单元无关的数据中心之间分布。 +> 即使数据有限，我们从中吸取的教训也表明，IT 项目失败和运营问题的发生频率越来越高，后果也越来越大。 这并不奇怪，因为各种形式的 IT 现在已经渗透到全球社会的各个方面。 很容易忘记，Facebook 于 2004 年推出，YouTube 于 2005 年推出，Apple 的 iPhone 于 2007 年推出，或者自 2005 年以来已经发布了三个新版本的 MicrosoftWindows。IT 系统肯定变得越来越复杂和庞大（就捕获的数据而言） ，存储和操作），这不仅意味着它们的开发难度和成本增加，而且维护起来也更加困难。 -质量 1-7 是众所周知的，并且相当广泛地得到认可并以某种形式或另一种形式部署。 *单元*的想法没有得到广泛应用，因为它使抽象级别提高到 *11* 。 +以下是具体课程： -Salesforce 具有类似的概念，称为[窗格](http://www.salesforce.com/dreamforce/DF09/pdfs/BKSP005_Moldt.pdf) *。* 对于 Salesforce，每个 Pod 包含 50 个节点，Oracle RAC 服务器和 Java 应用程序服务器。 每个吊舱支持成千上万的客户。 我们已经看到其他产品以类似的方式捆绑碎片。 分片将由数据库集群和存储组成，该存储将主从配置或主主配置隐藏到高度可用且可伸缩的单元中。 [Flickr](http://highscalability.com/flickr-architecture) 是此策略的早期且出色的示例。 +1. [错误地破坏了 IT 系统的巨大作用](http://spectrum.ieee.org/static/the-staggering-impact-of-it-systems-gone-wrong) 。 这里有些可怕的数字，正如文章所指出的那样，这只是冰山一角。 -本文真正有趣的一点是如何处理单元中的群集管理以及如何处理作为一个单元的单元管理。 那是很难正确的部分。 + * 主题：IT 系统的现代化既困难又昂贵； 将病历数字化既困难又昂贵； 银行依靠不可靠的技术； 即使是短暂的股票交易故障也很昂贵； 即使是短暂的空中故障也很昂贵。 -在机器集群中，节点以及因此这些节点上的服务可以随时闪烁并消失。 配置可以随时更改也可以更改吗？ 如何使单元中的所有系统保持协调？ ZooKeeper。 ZooKeeper 用于高可用性，分片，故障转移和服务发现。 易碎机器集群的所有基本功能。 在单元应用程序服务器中，服务器形成一致的哈希环，并且用户在这些服务器之间分片。 + * 失败是从几个方面衡量的：金钱，受影响的人，浪费的时间。 例如：2000 亿美元的美国陆军未来战斗系统计划终止； 国防部取消可互操作的电子病历系统项目（13 亿美元）； 新伦敦希思罗机场 T5 行李系统崩溃（3200 万美元，10 天，140,000 人）。 -跨单元操作如何处理？ 消息具有*发现服务*，它是一种用户 DNS，它位于单元上方，并维护用户到单元的映射。 如果要访问用户数据，则必须先使用该服务找到正确的单元格。 在该单元中，*分布式逻辑客户端*充当发现服务的接口并处理 ZooKeeper 通知。 +2. [过于复杂，交付不足](http://spectrum.ieee.org/static/overcomplexifying-underdelivering) 。 用一个系统替换多个系统似乎注定要失败。 在提供预期功能的一小部分的同时，几乎都超过了其最初的预算估算。 -[文章](https://www.facebook.com/notes/facebook-engineering/scaling-the-messages-application-back-end/10150148835363920#)写得很好，并且有很多细节。 非常值得一读，特别是如果您试图弄清楚如何构建自己的服务时。 +3. [失败项目的生命周期](http://spectrum.ieee.org/static/the-life-cycles-of-failed-projects) 。 据我们了解，更多的金钱和更多的时间无法防止项目灾难。 随着时间的流逝，失败变得越来越大，越来越无望。 -## 相关文章 [ +4. [IT 失败指责游戏](http://spectrum.ieee.org/static/the-it-failure-blame-game) 。 故障报告往往将责任归咎于无法捍卫自己或被解雇的无生命技术。 例如：空中客车（Airbus）责备空中客车 A380 两年延迟的设计软件不兼容 -* [Facebook 的新实时消息系统：HBase 每月存储 135 亿条消息](/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html) -* [ZooKeeper-可靠，可扩展的分布式协调系统](/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html) -* [Facebook 关于高可伸缩性的文章](http://highscalability.com/blog/category/facebook) -* [Force.com 基础架构内的外观](http://www.salesforce.com/dreamforce/DF09/pdfs/BKSP005_Moldt.pdf) +5. 失败的纪念碑-即将推出 -您遇到了错误的干草堆：http://planet.admon.org/haystack-new-storage-solution-for-billions-of-photos/ +这是一个系列，您可以花时间去逛逛。 IT 部门虽然经历了许多重大失败，但感觉上却像是陷入了其他人的苦难之中，但是无论如何都要尝试并从中获得乐趣。 我们只是人类。 -谢谢埃利奥特。 我不确定这是怎么回事，可以肯定我只是复制了他们的网址。 无论如何，现在应该修复它。 +## 相关文章 -我认为 Facebook 意味着另一个干草堆 http://www.facebook.com/note.php?note_id=76191543919。 阅读有关 Facebook Messages 存储基础架构的文章，网址为 http://www.facebook.com/note.php?note_id=454991608919，其中包含正确的 URL。 +* [“数十年的 IT 失败经验教训”](http://spectrum.ieee.org/riskfactor/computing/it/the-making-of-lessons-from-a-decade-of-it-failures) -我们的意思是：状态保存在数据库层，缓存层或其他服务中，而不是在应用程序中或塞在本地口袋中。 \ No newline at end of file +* [为什么软件失败](http://spectrum.ieee.org/computing/software/why-software-fails) （2005） + +* [除虫剂](http://spectrum.ieee.org/computing/software/the-exterminators) -一家小型英国公司表明，软件漏洞并非不可避免 + +* [危险因素](http://spectrum.ieee.org/blog/riskfactor) 博客 \ No newline at end of file diff --git a/docs/183.md b/docs/183.md index 63084b6..a0dc967 100644 --- a/docs/183.md +++ b/docs/183.md @@ -1,171 +1,101 @@ -# Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰 - -> 原文： [http://highscalability.com/blog/2011/5/10/viddler-architecture-7-million-embeds-a-day-and-1500-reqsec.html](http://highscalability.com/blog/2011/5/10/viddler-architecture-7-million-embeds-a-day-and-1500-reqsec.html) - -![](img/1f9466f9ca35249e9a853aee49edfb83.png) Viddler 从事高质量视频即服务业务，该业务面向想要支付固定成本，使用它完成并付诸实施的客户。 与 Blip 和 Ooyala 相似，比 YouTube 更侧重于业务。 他们为成千上万的商业客户提供服务，包括 FailBlog，Engadget 和 Gawker 等高流量网站。 - -Viddler 是一个很好的案例，因为它们是一家小型公司，试图在拥挤的领域中提供具有挑战性的服务。 我们正抓住他们，就像他们从一家以 YouTube 竞争者起步的初创公司过渡到一家规模稍大的公司（专注于为企业客户付费）过渡一样。 - -过渡是 Viddler 的关键词：从免费的 YouTube 克隆过渡到高质量的付费服务。 从效果不佳的一些 Colo 站点过渡到新的更高质量的数据中心。 从典型的启动架构过渡到具有冗余，高可用性和自动化功能的架构。 从大量实验过渡到弄清楚他们想如何做并实现这一目标。 过渡到一种架构，在该架构中，功能使用不同的技术栈在地理上分散的团队中分散，以明确定义角色。 - -换句话说，Viddler 就像其他所有即将成熟的初创公司一样，值得一看。 Viddler 的系统架构师 Todd Troxell 非常友好地接受了我们的采访，并分享了有关 Viddler 架构的详细信息。 它是不同技术，组和流程的有趣组合，但似乎可以正常工作。 之所以行之有效，是因为所有活动部件的背后都是一个主意：让客户满意并给予他们想要的东西，无论如何。 这并不总是很漂亮，但是确实可以取得结果。 - -网站： [Viddler.com](http://viddler.com) - -## 统计资料 - -1. 每天大约有 700 万个嵌入视图。 -2. 每天大约上传 3000 个视频。 -3. 最高 1500 req / sec。 -4. 高峰期约有 130 人按下播放按钮。 -5. 2 月份投放了 1PB 视频 -6. 80T 仓储 -7. 最近 30 天内花在视频编码上的 CPU 时间为 45,160 小时 -8. 整天的使用量相对平稳，谷底和高峰之间只有〜33％的差异，这表明它们在全球范围内得到了大量使用。 [图形](http://farm3.static.flickr.com/2704/5705121724_845db30833_o.png)。 - -## 该平台 - -### 软件 - -1. Debian Linux -2. Rails 2.x-仪表板，根页面，竞赛管理器，各种子功能 -3. PHP-使用我们内部 API 的各种旧式子网站 -4. Python / ffmpeg / mencoder / x264lib-视频转码 -5. Java 1.6 / Spring / Hibernate / ehcache- API 和核心后端 -6. MySQL 5.0-主数据库 -7. Munin，Nagios，接站-监控 -8. Python，Perl 和 ruby-许多*许多*监视器，脚本 -9. Erlang - ftp.viddler.com -10. Apache 2 / mod_jk-后端 Java 应用程序的核心头端 -11. Apache / mod_dav-视频存储 -12. Amazon S3-视频存储 -13. Amazon EC2-上传和编码 -14. KVM-临时环境的虚拟化 -15. Hadoop HDFS-分布式视频源存储 -16. Nginx / Keepalived-所有网络流量的负载均衡器 -17. Wowza-RTMP 视频录制服务器 -18. Mediainfo-报告视频元数据 -19. Yamdi-Flash 视频的元数据注入器 -20. 人偶-配置管理 -21. Git / Github https://github.com/viddler/ -22. Logcheck-日志扫描 -23. 重复性-备份 -24. Trac-错误跟踪 -25. Monit-进程状态监视/重启 -26. iptables-用于防火墙-无需硬件防火墙-还可处理内部网络的 NAT。 -27. maatkit，mtop，xtrabackup-数据库管理和备份 -28. [预引导执行环境](http://en.wikipedia.org/wiki/Preboot_Execution_Environment)-计算机的网络引导。 -29. 考虑将 OpenStack 的 [Swift](http://swift.openstack.org/) 作为替代文件存储。 -30. [FFmpeg](http://www.ffmpeg.org/) -完整的跨平台解决方案，用于记录，转换和流传输音频和视频。 -31. 阿帕奇雄猫 -32. [MEncoder](http://en.wikipedia.org/wiki/MEncoder) -一个免费的命令行视频解码，编码和过滤工具。 -33. [EdgeCast](http://www.edgecast.com/) -CDN - -### 硬件 - -1. 他们的 colo 中总共有 20 多个节点： - 1. 2 个 Nginx 负载平衡器。 - 2. 2 个 Apache 服务器。 - 3. 8 个 Java 服务器运行该 API。 - 4. 2 个 PHP / Rails 服务器运行在前端。 - 5. 3 台 HDFS 服务器 - 6. 1 监控服务器。 - 7. 1 个本地编码服务器。 - 8. 2 个存储服务器。 - 9. 2 个 MySQL 数据库服务器以主从配置运行，计划迁移到 6 个服务器。 - 10. 1 个登台服务器。 -2. Amazon 服务器用于视频编码。 - -## 产品 - -注册一个 Viddler 帐户，他们会将您的视频转换为所需的任何格式，并将其显示在任何设备上。 它们提供了嵌入代码，仪表板和分析。 他们的目标是在一个简单的界面后面解决视频问题，使人们可以购买该服务而忘了它，它可以正常工作并完成您需要做的一切。 作为内容提供商，您可以出售视图并将广告添加到内容中。 他们将所有广告网络作为一种元界面引入 Viddler，以执行不同的广告平台。 - -## 架构 - -[![](img/d73001acfb1f94e8103f4873882c4d06.png)](http://farm3.static.flickr.com/2375/5704553989_0e42783c8f_o.png) - -1. 当前时代 - 1. 他们目前的系统运行在美国西部某个地方的可乐中的裸机上。 他们正在搬到纽约的 Internap。 - 2. 1 gbps 链接将它们连接到 Internet。 CDN 提供视频，并将视频直接加载到 Amazon 中进行处理，因此对于他们的主要站点，他们不需要的网络就更多。 - 3. 该系统由 2 个 Nginix 负载平衡器所控制，一个是主动的，另一个是使用 keepalived 的被动的。 选择 Nginix 是因为它是基于 Linux 的开放源代码，并且可以正常工作。 - 4. EdgeCast 用作分发内容的 CDN。 客户将视频直接上传到 Amazon，然后将视频处理并上传到 CDN。 - 5. Nginx 可以故障转移到两个 Apache 服务器。 Apache 服务器可以故障转移到运行 Tomcat 的后端服务器之一。 - 6. 他们的部分架构在 Amazon 中运行：存储以及它们的上载和编码服务。 - 7. 在 Cassandra 中进行了实验，以存储仪表板位置。 非常可靠，但将来可能会迁移到 MySQL。 - 8. Linode 上的两个图像缩放节点，用于为视频创建任意缩略图。 将来将移至纽约。 -2. Internap 的很快时代 - 1. 该网站最初的想法是免费的视频网站 YouTube，但更好。 然后，他们转向提供更高质量的服务，这表明需要更好，更可靠的基础架构。 - 2. 他们正在迁移到 Internap，因此尚未解决所有问题。 他们先前的数据中心中的一些问题促使此举： - 1. 网络问题，某些 [BGP](http://en.wikipedia.org/wiki/Border_Gateway_Protocol) （边界网关协议）提供程序将停止工作，不会自动进行对等，并且最终将死站点一个小时，并且必须真正推动手动建立数据中心 删除对等体。 - 2. 他们被转租给了一家提供商，后者将他们踢出局，这意味着他们不得不在很少的交货时间内移动两个机架的服务器。 - 3. Internap 以其良好的网络而闻名，它是一种更好的工具，并且更可靠。 - 3. 一个主要目标是在其体系结构中具有**完全冗余**。 将 RTMP 服务器，专用错误记录系统的数量加倍，将监视服务器的数量加倍，将 PHP 和 Rails 服务器分开，添加专用图像缩放服务器，并将编码服务器的数量加倍。 - 4. 另一个主要目标是**完全自动化**。 他们将通过网络对计算机进行启动，以获取操作系统，并从 CVS 配置软件包。 目前，他们的系统不可复制，他们想对此进行更改。 - 5. 试用 HDFS 作为视频的文件存储。 他们将其视频的 10％（约 20TB）存储在 3 个 HDFS 节点上，而且从未停机。 - 6. 当前的目标是使一切移交，整个系统要自动构建，并且在版本控制中，确保雇用了操作人员并制定了时间表。 - 7. 观察到他们与亚马逊的业务相似，因为在视频世界中自己完成所有工作要便宜得多，但随后您必须自己完成所有事情。 - 8. 没有计划使用服务体系结构。 它们具有内部 API 和外部 API。 两者都用于创建站点。 与转换为服务方法相比，要实现更高的奖励功能。 -3. 自动化将改变一切。 - 1. 便携式 VM 将允许他们重现构建环境和实时环境。 目前这些是不可复制的。 每个人都使用不同版本的软件包在自己的操作系统上进行开发。 - 2. 将允许他们在体系结构上进行迭代。 只需下载要运行的新 VM，即可尝试新的存储等。 - 3. 简化向 OpenStack 的过渡。 同时考虑 VMware。 -4. 当您上载到 Viddler 时，端点位于运行 Tomcat 的节点上的 Amazon EC2 上。 - 1. 该文件在本地缓存并发送到 S3。 - 2. 该文件从 S3 下拉以进行编码。 - 3. 编码过程在称为 Viddler Core 的模块中拥有自己的队列。 - 4. 他们将在 colo 站点中运行的代码与在 Amazon 中运行的代码分开。 在 Amazon 中运行的代码不会保持状态。 生成的节点可能会死亡，因为所有状态都保留在 S3 或 Viddler Core 中。 - 5. Python 编码守护程序使工作脱离队列： - 1. 运行 FFmpeg，MEncoder 和其他编码器。 - 2. 关于检查 iPhone 视频是否需要在编码和其他测试之前进行旋转，有很多时髦的东西。 - 3. 每个编码节点都在 Amazon 8 核心实例上运行。 一次运行四种编码。 他们还没有尝试优化它。 - 4. 作业按优先级顺序运行。 有人要立即查看的实时上传内容将在批量处理（例如说在其编码中添加 iPhone 支持）之前得到处理。 - 5. Python 守护程序是运行时间很长的守护程序，它们没有看到任何有关内存碎片的问题或其他问题。 -5. 探索实时转码。 - 1. 在实时编码中，节点实例像多部分表单一样被馈送，通过 FFmpeg 进行流传输，然后再次进行流传输。 这可能是其 CDN 的一部分。 - 2. 这种体系结构的最大优点是无需等待。 客户上传视频后，该视频即会直播。 - 3. 这意味着仅需要存储文件的一种视频格式。 它可以按需转码到 CDN。 这样可以为客户节省大量的存储成本。 -6. 储存费用： - 1. CDN 和存储是他们最大的成本。 存储大约占其成本的 30％。 - 2. 希望他们的视频在所有内容上播放的人的平均情况是四种格式。 HTTP 流将是另一种格式。 因此，存储成本是客户的主要支出。 -7. 团队设置： - 1. 本地程序员在 PHP / Rails 中进行前端操作。 他们正在尝试将所有前端移至该堆栈，尽管其中一些当前在 Java 中。 - 2. 核心 Tomcat / Java / Spring / Hibernate 由波兰的一个团队编写。 Java 团队的目标是实现 API 和后端逻辑。 - 3. 为 PHP / Rails 团队计划有一个单独的数据库，因为它们的移动速度比 Java 团队快得多，并且他们希望尽可能地使团队脱钩，以使其彼此不依赖。 -8. 进行可靠性调查，发现大多数故障是由于： - 1. 网络连接问题。 他们正在迁移到新的数据中心来解决此问题。 - 2. 数据库过载。 要解决此问题： - 1. 该数据库包含约 100 个表。 用户表大约有 100 个参数，其中包括诸如编码首选项之类的信息。 从在 Word Perfect 上托管站点以来，该架构仍然具有旧结构。 - 2. 三倍的数据库容量。 - 3. 使用速度更快且具有更多内存的服务器。 - 4. 使用双主设备设置和 4 个读取从设备。 - 5. 两个读取从站将具有较低的交互式通信查询超时。 - 6. 两个从属将专用于报告，并且查询超时时间较长。 慢速报告查询不会使这种方法使网站瘫痪。 他们的热门查询正在处理具有 1000 万行的表，因此计算热门视频所需的时间比以前要长得多，因为它开始创建临时表。 可能导致系统停机 5 秒钟。 -9. 他们正在研究在自己的 colos 中使用 Squid 运行自己的 CDN。 - 1. 也许使用西海岸和东海岸的科鲁斯在地理上分布同伴。 - 2. 对于他们的客户，他们预计他们在美国需要 4 个站点，在欧洲需要 1 个站点。 - 3. EdgeCast 为他们提供了很多优惠，并为他们提供了有用的功能，例如每个 CNAME 的统计数据，但以盈利为基础，构建自己的 CDN 值得开发。 CDN 成本是其成本结构的重要组成部分，随着时间的流逝，值得一试。 -10. **未来的**：长期目标是看退出 Amazon，在本地运行存储，运行 OpenStack 并运行自己的 CDN 可以节省多少钱。 这将节省 80％的与人无关的运营支出。 根据他们自己的计算，他们可以做到比亚马逊便宜。 - -## 得到教训 - -1. **混搭**。 他们正在使用来自不同提供商的节点的组合。 CDN 处理内容。 Amazon 用于无状态操作，例如编码和存储。 colo 中的节点用于其他所有内容。 在几个不同的位置使用功能可能会有些混乱，但是除非有令人信服的业务原因或易用性更改的原因，否则它们会坚持可行的方法。 将所有东西转移到亚马逊也许是有道理的，但是这也会使他们脱离他们的优先事项，这会带来风险，并且会花费更多。 -2. **注意表增长**。 一旦站点变大，过去需要花费相当长的时间的查询便会突然使其崩溃。 使用报告实例可以从交互式流量中分担报告流量。 而且不要写令人讨厌的查询。 -3. **查看成本**。 平衡成本是他们决策过程的重要组成部分。 他们更喜欢通过新功能实现增长，而不是整合现有功能。 这是一项艰难的平衡行为，但是有意识地将其作为一项战略要务可以帮助每个人都知道自己的发展方向。 从长远来看，他们正在考虑如何在利用自己的 colo 较低成本结构的同时获得云运营模型的好处。 -4. **实验**。 Viddler 喜欢实验。 他们将尝试不同的技术以查看有效的方法，然后在生产中实际使用它们。 这使他们有机会了解新技术是否可以帮助他们降低成本并提供新的客户功能。 -5. **按技术堆栈细分团队，并发布灵活性**。 拥有分散的团队可能是一个问题。 在不同的技术堆栈和根本不同的发布周期上部署分布式团队是一个大问题。 拥有具有强大依赖性和跨职能职责的分布式团队是一个巨大的问题。 如果您必须处于这种情况下，那么迁移到组之间具有较少依赖关系的模型是一个很好的折衷方案。 -6. **从中断中学习**。 对您的网站为何崩溃进行调查，并查看可以解决的主要问题。 似乎很明显，但是还不够。 -7. **将免费用户用作豚鼠**。 免费用户对 SLA 的期望较低，因此他们是新基础设施实验的候选人。 拥有免费套餐对于此目的非常有用，可以在不造成重大损害的情况下试用新功能。 -8. **为顶级托管**支付更多费用。 他们遇到的最大问题是选择好的数据中心。 他们的第一个和第二个数据中心有问题。 作为一家蓬勃发展的创业公司，他们寻找可以找到的最便宜但质量最高的数据中心。 事实证明，数据中心质量很难判断。 他们选择了一家名牌设施，并获得了高昂的价格。 这工作了好几个月，然后开始出现问题。 停电，网络中断，他们最终被迫转移到另一家提供商，因为与他们在一起的一家提供商退出了该设施。 如今，任何时间都无法宕机是不可接受的，对于这样一个小组，冗余站点将是很多努力。 从长远来看，为更高质量的数据中心支付更多费用将降低成本。 -9. **最终重要的是用户看到的内容，而不是体系结构**。 迭代并着重于客户体验之上。 客户服务的价值甚至超过理智或可维护的体系结构。 只构建所需的内容。 如果不运行超级草率的业务，他们就无法启动这家维持 100％员工所有权的公司。 他们现在采用的是在草率阶段学到的知识，并在顶级设施中构建非常灵活的多站点架构。 他们的系统并不是最有效或最漂亮的系统，他们采取的方式是客户需要某种东西，因此他们构建了它。 他们追求客户的需求。 他们选择硬件和构建软件（重点是完成工作）的方式就是建立公司的基础。 -10. **自动化**。 尽管所有试验和解决客户问题的直接方法都很好，但是您仍然需要一个自动化的环境，以便可以复制构建，测试软件并提供一致且稳定的开发环境。 从一开始就自动化。 - -我真的很感谢 Todd Troxell 花时间参加这次采访。 - -记住孩子们，如果您正在寻找工作，Viddler 也在为您寻找[。](http://www.indeed.com/q-Viddler-jobs.html) - -## 相关文章 - -1. [我们可以处理您的交通！](http://blog.viddler.com/cdevroe/traffic/) ，作者 Colin Devroe - -很高兴阅读... -我很想了解您不转用云服务的原因，因为从今天起您需要管理和开发许多不同的技术... 大量的金钱和精力？ \ No newline at end of file +# Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售 + +> 原文： [http://highscalability.com/blog/2015/11/2/how-shopify-scales-to-handle-flash-sales-from-kanye-west-and.html](http://highscalability.com/blog/2015/11/2/how-shopify-scales-to-handle-flash-sales-from-kanye-west-and.html) + +![](img/496178f66cd6eb10235644541a56d67d.png) + +*这是[缩放您的代码](https://twitter.com/christophelimp)的创建者 Christophe Limpalair 提出的来宾[重新发布](https://scaleyourcode.com/blog/article/23)。* + +在本文中，我们介绍了 Shopify 使平台具有弹性的方法。 这不仅有趣，而且实用并且可以帮助您开发自己的应用程序。 + +## Shopify 的扩展挑战 + +Shopify 是一个电子商务解决方案，每个月处理大约 3 亿独立访客，但是正如您所看到的，这 3 亿人不会以均匀分布的方式出现。 + +他们的**最大挑战之一是所谓的“闪存销售”** 。 这些快速销售是在非常受欢迎的商店在特定时间销售商品的时候。 + +例如， **Kanye West** 可能会出售新鞋。 结合 **Kim Kardashian** ，仅 Twitter 上的**就有 5000 万人以下**。 + +他们也有在超级碗上做广告的顾客。 因此，他们不知道会有多少流量。 **可能有 200,000 人在 3:00** 出现，并在几个小时内结束特价销售。 + +**Shopify 如何适应这些流量的突然增加？** 即使他们无法在特定销售中很好地扩展规模，也如何确保它不会影响其他商店？ 在简要说明 Shopify 的上下文架构之后，这就是我们将在下一部分中讨论的内容。 + +## Shopify 的架构 + +即使 Shopify **去年移至 Docker** ，他们**仍未脱离 Monolithic 应用程序**。 我问西蒙（Simon）为什么，他告诉我说，他们并不会轻易承担[微服务](http://martinfowler.com/articles/microservices.html "Microservices explanation")的开销。 但是，如果他们决定走这条路，此举使他们在将来可以更轻松地过渡。 + +无论如何，它们的体系结构看起来像这样： + +一个**请求**进入 **Nginx** ，然后进入运行中的**服务器集群 带有 Rails 应用程序**的 Docker。 + +对于**数据层**，他们使用以下方法： + +* 记忆快取 +* 雷迪斯 +* 弹性搜索 +* 的 MySQL +* 卡夫卡 +* 动物园管理员 + +此**的大部分运行在自己的硬件**上。 他们还在 AWS 上运行了**几件事。 + +为了降低成本，Shopify **运行多租户平台**。 这意味着它们在单个服务器上有多个商店-例如，shopA.com 和 shopB.com 是从同一服务器提供服务的。 + +即使迁移到 Docker [并非一帆风顺](https://www.youtube.com/watch?v=Qr0sATj9IVc "Simon Eskildsen on switching to Docker")，他们最终还是从中获得了一些好处： + +迁移到 Docker 使 Shopify 得以运行 **在大约 5 分钟（Docker 之前的 15 分钟）内在数十万行 Ruby 上进行持续集成**，并在 3 个数据中心中将其部署到 300-400 个节点仅需 3 分钟（之前 15 分钟）。 这些是令人印象深刻的变化。** + +## 他们如何处理交通高峰 + +理想情况下，平台可以自行处理峰值。 这还没有完全实现，因此他们在大量销售之前要通过**性能清单**。 + +在 Kanye West 的示例中，他们坐了 2 周，并通过组合平台的关键部分进行了**广泛的被动负载测试和性能优化**。 + +为了运行各种测试，他们使用了称为“弹性矩阵”的工具。 + +![Resiliency Matrix used at Shopify](img/df836800db08262494198fa988c2a99f.png) +（图片来自 [Simon 的会议演讲](https://speakerdeck.com/sirupsen/dockercon-2015-resilient-routing-and-discovery "Simon Eskildsen on Resilient Routing and Discovery and Dockercon 2015")） + +**弹性矩阵**可以帮助确定服务提供时系统发生了什么 下跌降落。 + +说 Redis 失败了，Redis 被用作结帐的组成部分。 您是否将整个站点拆毁并置于维护模式？ 不，您可以退出所有人，仍然允许他们在没有客户帐户的情况下进行结帐。 然后，在 Redis 备份后，将电子邮件地址与客户帐户相关联并填补空白。 + +进入系统列表（如店面，管理仪表板，API 等），然后查看服务中断时会发生什么—系统的其他部分也会受到影响？ 尝试**消除这些依赖关系，您的应用程序弹性将大大提高。** 这就像一条链，您的应用程序的强度仅与最弱的链接一样强。 + +![](img/716fcdec96974486047991f74d3587af.png) + +为了帮助此过程，Shopify 团队**开源了 Toxiproxy 和 Semian** 。 + +[Toxiproxy](https://github.com/Shopify/toxiproxy "Toxiproxy") 会在您选择的任何系统中引入**控制的潜伏期**。 + +![Toxiproxy](img/ae8ce68044fee28650f7401a5458b0f5.png) + +[Semian](https://github.com/Shopify/semian "Semian") 用于验证您没有**单点故障**。 + +![Semian](img/deba378a125528dc13a6b1af404b2c91.png) + +有关弹性的更多信息，请查看 [Simon 的会议演讲](https://speakerdeck.com/sirupsen/dockercon-2015-resilient-routing-and-discovery "Simon Eskildsen on Resilient Routing and Discovery and Dockercon 2015")中的其中之一，他将提供更多详细信息。 超级有趣。 + +在此弹性工作的基础上，Shopify 还能够**超额配置，因为他们拥有自己的硬件**。 对于他们来说这很便宜，但是如果您在云上运行，它可能不会那么便宜。 查看成本与收益的关系，看看是否对您有意义。 + +另一个大挑战是扩展数据存储。 由于 Shopify 处理金融交易，因此其数据库*不能*不同步。 解决方案？ **Shopify 在大约 2 年前对 MySQL** 进行了分片。 他们非常积极地进行分片，并且目标是随着时间的推移增加**和较小的分片**。 + +Simon 继续说**扩展数据库非常困难**-尤其是分片。 它几乎总是应该是不得已的方法。 您可能需要先缓存很多东西。 但是分片的好处是它们有助于隔离事件。 如果一个客户群中发生了一些疯狂的事情，那么整个平台中只有一小部分会受到影响。 + +回到弹性测试，Simon 强调说，大多数**数据库扩展问题已通过许多弹性工作和自动故障转移**得到解决。 + +## 他们计划进行哪些其他改进？ + +展望未来，团队正在研究**相互隔离的**层，它们相互为应用程序提供服务。 他们正在做的另一件事是让**的商店同时用完不同大陆上的多个不同数据中心**。 这对于数据局部性来说非常重要，也可以防止意外事件。 + +杰里米·埃德伯格（Jeremy Edberg）在[的采访](/interviews/interview/11 "Jeremdy")中告诉我，Netflix 也投入了大量资源来防范突发事件。 + +除了这些计划之外，他们还研究**使故障转移变得可以轻松地每天多次执行**。 如果您对它们如何在整个数据中心之间执行故障转移测试感到好奇，请参阅 [Simon 的采访页面](/interviews/interview/14 "Simon Eskildsen interview with ScaleYourCode")。 + +就目前的情况而言，他们无法在不临时取消检出的情况下对整个数据中心进行故障转移。 但是，他们目前正在研究一种解决方案，以解决此问题。 + +## 采取的行动 + +My goal with this article is to give you easily-digestible knowledge you can take action on. What action(s) can you take now? Well, you probably want to avoid sharding, so can you cache more? You may not be able to over-provision due to cost, but what about checking out the resiliency matrix? Even if you don't have the resources to pull this off right now, building one of these matrices or even just thinking about it can be helpful. + +如此高的收益率是您的瓶颈。 没有留下深刻印象 \ No newline at end of file diff --git a/docs/184.md b/docs/184.md index a8c3151..eb73962 100644 --- a/docs/184.md +++ b/docs/184.md @@ -1,174 +1,181 @@ -# Microsoft Stack 是否杀死了 MySpace？ +# 整个 Netflix 堆栈的 360 度视图 -> 原文： [http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html](http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html) +> 原文： [http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html) -![](img/b626d590fe361c0078867635d0de14c3.png) +![](img/55739ecaab704c16a4ff8d5b4688b8f9.png) -罗伯特·斯科布尔（Robert Scoble）撰写了一个引人入胜的案例研究， [MySpace 的死亡螺旋：内部人说，这是赌在洛杉矶和微软](http://scobleizer.com/2011/03/24/myspaces-death-spiral-due-to-bets-on-los-angeles-and-microsoft)上的，他在报告中说 MySpace 内部人将微软[丢掉了很棒的社交网络的原因归咎于微软 种族](http://www.intelligentspeculator.net/investment-talking/why-facebook-is-succeeding-where-myspace-has-failed/)到 Facebook。 +*This is a guest [repost](http://www.scalescale.com/the-stack-behind-netflix-scaling/) by [Chris Ueland](http://twitter.com/ChrisUeland), creator of [Scale Scale](http://scalescale.com/), with a creative high level view of the Netflix stack.* -有没有人知道这是不是真的？ 真实的故事是什么？ +> 随着我们对扩展的研究和深入研究，我们将继续涉足 Netflix。 他们的故事很公开。 这篇文章是我们在 Bryan 的帮助下整理而成的。 我们从互联网上收集了信息。 如果您想了解更多信息，我们将在此附上。 否则请尽情享受！ +> +> –克里斯/ ScaleScale / MaxCDN -我在想，因为它似乎与我在 2009 年所做的 [MySpace Architecture](http://highscalability.com/blog/2009/2/12/myspace-architecture.html) 帖子不一致，他们似乎对他们的选择感到满意，并提供支持其改进的统计数据。 这很重要的原因是，这是初学者可以借鉴的迷人模型。 成功真正需要什么？ 是人员还是堆栈？ 是组织还是技术？ 是过程还是竞争？ 网站的质量还是用户的喜爱？ 有太多需要考虑和学习的地方。 +![](img/589a5c2b0693b041db6f53e8a2dd0957.png) -本文中的一些猜想： +## 看看我们对 Netflix 如何扩展感兴趣的观点 -1. Myspace 没有编程人才能够扩展网站以与 Facebook 竞争。 -2. 选择微软的体系使其很难聘请能够与 Facebook 竞争的人。 .Net 程序员主要是企业程序员，他们的组织结构并非以启动速度创建大型可扩展网站。 -3. 他们的系统具有““数百个骇客，使其规模扩大到没人想碰”，这损害了他们真正竞争的能力。 -4. 由于 MySpace 的基础架构，他们无法更改其技术以使新功能正常工作或带来新的体验。 -5. 激怒了很多人，鼓舞士气，使招聘变得艰难。 （du） -6. 洛杉矶没有能够产生可扩展社交网络系统的创业人才。 -7. Facebook 选择的 LAMP 堆栈使他们可以更快地招聘并找到知道如何扩展的人。 +Netflix 由马克·兰道夫（Marc Randolph）和里德·黑斯廷斯（Reed Hastings）于 1997 年在加利福尼亚州斯科茨谷市成立，最初拥有 30 名员工，其中 925 名从事按租金付费。如今，Netflix 已成为全球领先的互联网电视网络，在 50 个国家/地区拥有 6900 万订户 每月欣赏超过 100 亿小时的电视节目和电影。 它们非常透明，可以在线发布很多信息。 我们已收集并分享了我们认为最有趣的内容： -评论中的一些非常有趣的观点（来自文章，电子邮件， [Hacker News](http://apps.ycombinator.com/item?id=2369343) ， [Hacker News](http://news.ycombinator.com/item?id=2369271) ）： +![](img/84caa622b10cf4f82b4df5547ffa78a8.png) -1. **Nick Kwiatkowski** ：我能够与一些在 MySpace 工作的程序员一起工作，但问题不是引擎（无论是在 ColdFusion 还是.NET 上） ，这是他们选择为其开发人员孕育的环境。 管理层会说“我们现在需要 X 功能才能保持竞争力”。 然后，他们将选择一组开发人员来实现该功能。 最大的问题是他们不允许开发人员进行登台或测试服务器-他们是在第一次尝试时将其部署在生产服务器上的。 有时，这些开发人员只能在很少的时间内获得 5 或 10 个项目的部署。 而这一切都没有变更管理或控制。 也没有版本控制。 MySpace 管理层从不希望回头查看代码或提高代码效率。 他们的解决方案是“更多服务器”。 他们最终雇用了一个唯一的工作就是安装更多服务器的工作人员。 同时，他们让开发人员签入错误代码，并且以惊人的速度累积技术债务。 当时，MySpace 正在运行其应用程序服务器的两个主要版本，而不是建议使用的版本。 微软（HTG8）新亚特兰大市（New Atlanta）问世时，他们跳槽了从本质上出售其技术债务（例如抵押给金融公司的抵押品）的想法，并请其他人来解决他们的问题。 当时的问题是微软没有更新他们的旧代码，他们只是在.NET 上添加了新功能。 这并不能解决他们的问题，而使他们处于仍然需要修复旧内容，同时又要更新新代码的情况。MySpace 的问题是：它们是当您不听并且积累了过多技术债务时的经典示例。 修复旧内容应该是优先事项，并且必须执行诸如变更管理，版本控制，测试和开发服务器等工作。 这就是为什么 Facebook 能够部署几乎没有影响的新更改的原因-他们在让实际用户使用之前对其进行了测试和验证。 -2. **u_fail** ：听起来这一切都是对技术归咎于技术的了解很少甚至根本不了解的商人，而一直以来都是缺乏创新并且高层缺乏决策者。 MySpace 始终像一家娱乐公司一样运作。 -3. **Eric** ：这与技术无关，而与实施技术的人员有关。 -4. **Robert Scoble** ：MySpace 的体系结构使得很难发布新功能和“枢轴”，一旦他们清楚地知道他们正在努力。 -5. MySpace 的核心竞争力依赖于其他人，并且从未在内部扩展过，而且似乎完全无法发挥作用。 -6. **Robert Scoble：**都是关于人才和获得技术帮助的创新。 这些人没有使用微软的系统。 -7. **编码为**：MySpace 在 Microsoft 的堆栈上押注不是问题。 问题在于他们在 Telligent 的社交媒体平台上下注。 MySpace 并未开发自己的平台并向自己拥有和开发的平台添加功能，而是决定让另一家公司的产品为其核心功能集提供创新。 -8. **Hack** ：我记得在某人的页面上浏览了 100 张.gif 文件，并在 25 秒后加载了页面。 Facebook 无疑获得了冠军。 -9. **Marcelo Calbucci** ：这是一个错误的分析。 如果使用 RoR 或 PHP，他们将遭受完全相同的信念。 实际上，一旦 Facebook 改变了社交网络应提供和外观的标准，他们的命运就已经定下来了。 -10. **Sriram Krishnan** ：您对任何堆栈的使用与您所拥有的专业知识成正比。 -11. **S Jain** ：把责任归咎于微软是完全错误的。 我认为这是 MySpace 的一种文化。 我在洛杉矶的一家初创公司工作，在 Myspace 有很多朋友。 我常常会迟到，他们会说向一家大公司求职，为什么迟到了。 -12. **Gregg Le Blanc** ：当 MySpace 在 MIX06 上发表他们为何转用 Microsoft 的主题演讲时，他引用了一个事实，即他们可以在基本上 2/3 的服务器上处理相同的用户负载（246-> 150），将平均 CPU 负载从 85％降低到 27％，以便为 6500 万用户负载的页面提供服务。 因此，我认为这更多地与人员，体系结构和业务计划有关。 他们的战略决策是忘记创新。 那是技术独立的。 -13. Robert Scoble ：马克·扎克伯格（Mark Zuckerberg）表示，要在其他地方建立网络规模的公司要困难得多，因此他从波士顿搬到了硅谷。 -14. **Jebb Dykstra** ：MySpace 在出售给新闻集团的那一刻就迷失了。真正的死亡螺旋就在那一刻开始。 如果像 Richard Rosenblatt 这样的人才留下来，而他们并没有以 670 毫米的价格卖掉自己，那么这些问题中的许多可能就是借口。 -15. **Omar Shahine** ：让我们不要忘记 Twitter 根本无法扩展，并且基本上被破坏了。 它不是建立在 Microsoft 技术之上的，但是他们设法对其进行了修复。 -16. **Sean Scott** ：即使技术和人才匮乏是问题的一部分，而且 MySpace 无法响应 Facebook，最终用户体验还是为此付出了代价。 -17. **DavidNoël**：当他们说这将花费一些点击和页面重载，但会增加用户体验和长期参与度时，NewsCorp 会拒绝，因为担心失去可货币化的指标。 -18. **史蒂夫·史密斯**：MySpace 的代码显然有很多技术上的欠缺，从事物的声音来看，其体系结构是教科书“泥浆大球”。 他们将核心业务押在第三方软件上。 -19. **Scott Stocker** ：愿意为 MySpace 工作的开发人员的可用性是最大的问题。 -20. **琳达·尼古拉**：用户没有因为技术投诉而离开现场，这是因为新来的孩子骑着一辆更加光亮的自行车...缺乏创新，缺乏竞争性， 产品推出有限，高层动荡不安，技术问题，但不要将其归咎于洛杉矶缺乏技术人才 -21. **Dan Bartow** ：阅读本文后的最初印象是，我完全同意 Scoble 所说的有关洛杉矶和人才问题的一切。 MySpace 处于独特的状况，因为它们专注于娱乐行业，主要是音乐行业和相关内容。 由于这种关注，洛杉矶确实是他们所做工作的“理想之地”。 要插入现场并进行艺术家活动，与唱片公司建立联系……还有什么更好的地方？ 如果您是一家金融公司...新英格兰。 娱乐...洛杉矶。 另一方面，它们也是流量最高的网站之一，因此，他们确实需要站在技术的最前沿。 的确，洛杉矶不一定具有像旧金山湾区在尖端网络规模架构方面的工程人才类型。 但是，请认为 MySpace 的问题与其所选择的技术平台选择（微软与其他产品）相比要少得多，而与工程领导力，市场定位和响应时间等有关的更多。我个人对其性能和可伸缩性印象非常深刻 。 他们快速的自动配置和重新配置功能非常出色。 他们能够进行 100 万个并发用户测试，就像没有发生那样，因此非常棒。 我实际上不知道这是微软技术，并且可能永远不会根据他们在其架构中所做的事情来猜测。 作为工程师，您和我俩都知道正确的心态以及强大的领导才能使几乎任何技术都达到最高水平。 PHP 是可扩展性最低，性能最差的语言之一，直到 Facebook 一直将其推向顶峰。 领导。 Microsoft 网站上有很多高流量的站点，所以我认为技术选择不像 Scoble 听起来那么重要，并且基于我在 MySpace 上的工程领导地位，实际上是很糟糕的事情。 人才...当然，洛杉矶不是硅谷，但是相信我，有很多理由选择使用 SoCal。 就我个人而言，我认为 MySpace 的问题一直存在于业务领导地位以及对竞争对手的反应时间较慢。 -22. **Scott Seely** ：MySpace 死亡螺旋上升的原因与技术无关。 是与人类问题有关的一切。 克里斯·德沃尔夫（Chris DeWolfe）和汤姆·安德森（Tom Anderson）离开后，随之而来的是许多重要领导。 此外，许多创意人员（产品经理，开发人员，艺术家等）都看到高管离职，并决定现在是尝试其他方法的好时机。 太多的机构知识留下得太快了，这破坏了 MySpace。 -23. **jdavid** ：MySpace 拥有的是文化债务，并且担心破坏他们的财产。 Facebook 之所以获胜，是因为他们是核心的苏格拉底。 Fox 是一家封闭源代码的公司，因此当我们像 Oauth 和 OpenSocial 小工具服务器这样的开放技术公司工作时，我们必须将其作为封闭源代码软件来进行。 我们没有同行评审。 当您没有 Linkedin，google，bebo 和 twitter 来检查代码时，这真的很难发货和测试。 最重要的是，当这些公司发现错误时，我们必须在.Net 中重新实现该代码。 最重要的是，MySpace 和.Net 是针对强类型化而精心设计的，这些类型与 Java 有点不同。 移植并不需要花费很多时间，所以我们一直这样做，但是您必须考虑一下，您正在与像 Facebook 这样的公司竞争，当时该公司的利润动机为零，并拥有数十亿美元的资金和 地面堆栈。 同时，MySpace 只是在清除冷融合，而我们有真正的旧博客平台，不能仅仅将其删除。 我们还拥有不想激怒用户的管理，因此我们将拥有 2 或 3 个版本的站点，并且我们要求用户升级到新版本。 -24. **jdavid** ：与 Google 的交易失败了，因为这些条款涉及的是浏览量和点击次数。 MySpace 和 Fox 决定以这些条款为目标，以最大限度地提高收入。 结果是 MySpace 几乎为每个用户操作都添加了不必要的页面流。 它摧毁了用户体验并激怒了谷歌。 我们的团队一直在与管理人员开玩笑，说我们将通过 REST API 创建一个 MySpace-Lite 作为辅助项目，并摆脱所有的废话。 我们应该做的。 我们应该创建 MYSPACE-LITE。 与 Google 的交易每年价值 3 亿美元，每年总收入 7.5 亿美元。 MySpace Music 失去了公司的疯狂资金，过去是而且是有缺陷的模型。 我们的团队想创建一个 API，游戏和网站可以访问音乐，并创建开放的播放列表。 我们想将音乐打开，然后进行许可。 有人告诉我们这是不可能的。 -25. **lemmsjid** ：Web 层与可伸缩性几乎没有关系（不要误会我，它与成本有很大关系，只是与可伸缩性没有关系，除非采用诸如数据库连接池这样的更巧妙的方式） 这都是关于数据的。 当 MySpace 达到指数级增长曲线时，几乎没有用于扩展 Web 2.0 stype 公司的解决方案（OSS 或非 OSS）（大量读取，大量写入，大量热数据超过了商品缓存硬件的内存，当时为 32 位） ，并拥有非常昂贵的内存）。 没有 Hadoop，没有 Redis，Memcached 刚刚被释放并且存在现存的问题。 这很有趣，因为今天人们问我：“为什么不使用 Technology X？” 我回答：“好吧，那时还没想到呢：）”。 当时，只有如此规模的地方才出现，例如 Yahoo，Google，EBay，Amazon 等，而且由于它们都在专有堆栈中，因此我们会尽可能多地阅读白皮书，并尽可能多地获得白皮书。 -一起收集信息。 最后，我们编写了一个分布式数据层，消息传递系统等，以处理跨多个数据中心的大量负载。 我们对数据库进行了分区，并编写了一个 etl 层，以将数据从 A 点传送到 B 点，并将索引定位到所需的工作负载。 所有这些都是在每秒数十万次命中的巨大负载下完成的，其中大多数都需要访问多对多数据结构。 我们与之合作的许多初创公司，无论是硅谷还是硅谷，都无法想象将他们的东西扩展到那种负载-许多数据系统供应商在使用它们之前（如果有的话）需要对其东西进行许多修补。 时代已经改变了-现在想象扩展到 MySpace 的初始负载要容易得多（几乎可以接受）。 关键分区数据库层，分布式异步队列，用于聊天会话的大型 64 位服务器等。但是，您要考虑到该系统永远不会脱机-您需要持续 24 小时访问。 当整个系统出现故障时，您将损失大量资金，因为数据库缓存消失了，中间层缓存消失了，等等。这就是操作故事的来历，在此我可以为系统专门介绍其他几段 用于监视，调试和映像服务器。 当然，还有数据故事和 Web 代码故事。 MySpace 是一个非常难以在 Web 端进行进化的平台。 其中一部分是整个站点上用户体验的碎片化，而很大一部分是用户提供的 HTML。 不以微妙或不微妙的方式破坏人们的经历是很难做的。 许多配置文件主题都将图像放置在图像之上，并且 CSS 读取了“ table table table table ...”。 当您不得不处理数百万个 html 变体时，请尝试更改体验。 在这方面，谈到灵活性时，我们挖了自己的坟墓。 不要误会我的意思，系统存在的缺陷多于我所能估计的。 总有事情要做。 但是，作为喜欢在 Microsoft 和 OSS 堆栈上花费时间的人，我可以告诉您问题不是问题在于 MS 技术，也不是缺乏工程技术人才。 我为建立这些系统而工作的人们的素质感到惊讶和谦卑。 -26. n_ar​​e_q 的**：对于在公司工作并关心环顾四周并了解正在发生的事情的任何人来说，MySpace 垮台的原因都是显而易见的-这是灾难性的，缺乏管理和产品的领导力和远见， 瘫痪了政治内斗，以及公司管理层高层普遍缺乏能力。 因此，做出决定的人会不断改变主意和要求。 有许多完整的功能在完成后并没有启动或放弃，因为管理层无法就如何“定位”它们达成共识（它们是很棒的功能）。 高管层一直处于政治内斗状态，这很可能来自狐狸和他们的狗屎行为。 没有人可以在这个级别上判断和奖励能力，这仅仅是关于谁可以更好地掩盖自己的屁股或看起来更好地表现出来。 MySpace 很大，每个人都只想吃一块。 由此产生的问题之一是缺乏对技术的尊重，即更高层次的人都没有将该公司视为技术公司。 他们将其视为娱乐或媒体公司。 这造成了文化上的问题，最终导致不良产品和伪劣实施。 现在，该组织的核心技术部分实际上非常胜任。 在鼎盛时期，MySpace 吸引的流量超过了 Google，那时该网站的规模还算不错。 那不是偶然的，我和那里的一些业内最聪明的人一起工作过。 但是因为技术不是高管的重点，所以这些人受到非技术管理人员的严格控制，因此产品遭受损失。 MySpace 可以（而且仍然）可以扩展任何东西，也就是说，到了达到顶峰时，他们已经遇到了扩展问题，这完全是乱码。 多年来，他们开发了非常成熟的技术堆栈。 没有人知道，因为它是完全专有的。 问题是管理和产品基本上...无能为力，并且缺少适当水平的任何人来照顾和修复它。** -27. **mhewett** ：我不确定这些基于技术的分析是否正确。 当时我有四个少年，他们都从 MySpace 切换到 Facebook，因为 MySpace 的页面上充斥着耀眼的广告。 Facebook 布局更整洁，并且没有广告（当时）。 网站速度没有问题。 -28. **晕眩**：这表明技术和位置的选择不是原因，它们是公司管理层的症状，他们不了解构建简单的 Internet 应用程序（最佳的技术堆栈是什么； 在何处，何时何地聘用开发人员来构建），并保留进行所有技术决策的权限。 与此形成鲜明对比的是，与 Google 等人的 Facebook 相比，在这里设计每个流程（从公司 IT 到生产运营再到人力资源和招聘）时，都必须考虑到工程组织的需求：“想要两个 24”显示器吗？ 没问题。 想要在笔记本电脑上使用 Linux 吗？ 没问题。 想要 ssh 进入生产环境吗？ 没问题。 想参加候选人面试吗？ 没问题。” -29. **sriramk** ：我有来自 MySpace 的一堆朋友，我听到的一个共同主题是，他们认为更好的架构（未连接到堆栈）会让他们更快地发货。 看来您可以忍受的技术债务是有限的。 如果您重写得太快，您会被一家通过大量重写/重新设计工作而杀死其产品的公司取笑。 花了太长时间，像 FB 这样的人很快就发布了功能并跃居您的前面。 -30. **ChuckMcM** ：我认为企业家的见解是“网络”不是“企业”。 微软已经花费了数十亿美元来瞄准“企业”（与 SAP，Oracle，Salesforce 等大型软件公司竞争），其结构和部署与“网络”（大型用户是 Google，Facebook 等）截然不同。 当我在 NetApp 工作时，我们在世界各地都有客户，我们发现**“企业”家伙经常有节奏，例如成长，发现挑战，努力，升级，重复** 。 这个周期是围绕着获取最新版本的“大型播放器”软件，对其进行鉴定，然后使其投入生产，进行一些扩展，确定问题出在哪里，与他们的供应商交谈，等待，获取新版本然后重复来进行的。 周期。 但是“网络”玩家的节奏最好是零星的，并且常常是疯狂的，功能请求，测试，迭代，功能，迭代，测试，海岸，海岸，海岸，功能，功能，功能，测试，海岸等。 他们会立即实现某种原型或测试用例的“网络”基础架构人员，然后迅速提出支持该功能以最大化该功能所需的基础架构功能。 但是有时它们会花费很长时间，几个月，而不会发生任何变化（在基础架构方面，网页，UX 等方面肯定会发生变化，但是服务器和存储资产相同）。 我从中学到的东西是，虽然在运营费用方面拥有其他公司来承担“基础基础架构”的负担真是太好了（但是，如果您不更改该级别的内容，那么您就不需要 Linux 黑客了，所以 节省员工等），这对变更衍生产品施加了硬性限制。 如果您尝试更改的速度快于基础架构的更改速度，结果是您最终会受到限制，并且会积聚技术疤痕组织，随着时间的流逝，这会进一步降低您的移动性。 因此，最重要的是，您将无法继续以比基础架构更快的速度进行枢纽工作，如果您正在围绕基础架构进行变更，那么您的变更能力将因一千次黑客攻击而消失。 如果您发现自己需要思考一下您的基础架构，请听从该警告，并开始规划一个更加敏捷的基础，以便从现在开始工作，而不是当我们在开发一个全新的系统时仍在努力保持旧系统正常运行时。 -31. **phlux** ：确实可以做出一种基础架构选择，即政策，它将为您提供整个公司基础架构生命周期内的最佳可用路径：全面虚拟化 -32. **akshat** ：硅谷的人才也许很棒，但我敢打赌，任何大都会都有足够的优秀开发人员来使任何网络公司成功。 您需要成为一个能够吸引此类人的地方。 -33. **Lukeas14** ：您可以尝试指责 Myspace 的“死亡螺旋式增长”是由于他们的技术堆栈转移到了洛杉矶，但根本原因是他们无法创新。 实际上，2010 年的网站与 2002 年的网站相同。请考虑一下 Facebook 当时发布并重新推出了多少新功能。 曾经有一段时间，许多人喜欢他们自定义设计的个人资料页面。 但是后来他们长大了，而 MySpace 却没有。 +## 规模文化 -我的一些观察： +NetFlix 有一个关于文化的著名演讲。 这些概念是关于重新思考人力资源的。 他们的许多人员都集中在此演示文稿的原理上。 这是一些示例幻灯片和演示。 这为文化提供了重要的背景，以了解他们如何扩展软件堆栈以及其工作原理。 -* 堆栈不是真正的问题。 那简直太傻了。 查看 Windows，.Net 等，如果使用正确，它们都具有相当的伸缩能力。 Facebook 从 LAMP 开始，但是在此过程中，他们改变了一切，因此很难说他们最终仍在使用 LAMP。 Twitter 与 RoR 经历了类似的阶段。 如果没有改变您要触摸的所有东西来满足您的特定需求，您就无法以如此规模生存。 Facbook 还使用非常小的团队，因此您实际上并不需要大量的人才。 您需要一些才华横溢的人才，这些人才应有正确的愿景，支持和支持，让他们自由解决问题。 -* 问题是为什么技术没有正确使用？ 这些评论指出了许多不同的原因，但最终都归结为人们。 他们被不重视技术的管理团队收购了吗？ 如果可以相信某些开发，发布和设计决策，则可能会出现这种情况。 核心竞争力似乎已经转移给了第三方。 像 SAN 这样的技术被引入来解决问题，而不是直接解决问题。 两者都是致命的。 无论使您获得成功，都必须完全拥有。 也许作为“娱乐”公司而不是技术公司会促进这种方法。 但这又会回到所有权和管理上。 人们似乎忘记了，除非他们是魔术师，否则天赋就不能在直筒夹克中发挥作用。 -* 创新问题很有趣。 我们看到 Facebook，Amazon，Google 和 Apple 等公司不断创新。 这对 MySpace 的命运有多重要？ 为什么创新对他们不重要？ +![](img/8d605f04aca2955e4e075846c21344e7.png) -所以发生了什么事？ 更重要的是，公司中的新创业公司和集团如何避免这种命运？ 我们一直都在看。 这让所有参与其中的人感到沮丧。 我们现在不应该过去这种事情吗？ +![](img/1e6dabcae21af4ad40187f8c2abca958.png) -## 相关文章 +完整演示文稿在这里[。](http://www.scalescale.com/the-stack-behind-netflix-scaling/#) -* [StackOverflow](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 和 [PlentyOfFish](http://highscalability.com/plentyoffish-architecture) 是成功使用 Microsoft 技术的公司的著名示例。 但请注意，他们利用了它，这与将王国的钥匙交给没有与您一致的目标的公司不同。 仅将农场押在您身上。 LAMP 堆栈是独立的组件，易于更换和修改。 当您购买完整的堆叠时，遇到问题时就会陷入困境。 您永远不想被困住。 -* 关于[黑客新闻主题](http://apps.ycombinator.com/item?id=2369343)的好的评论 -* [MySpace 如何测试 100 万个并发用户的实时站点](http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html) +## 通过 Amazon 支持许多标题 -我不知道要捍卫.NET 作为初创企业的可行平台有多少次，我自己的初创企业 [SocialDeal.net](http://www.socialdeal.net) 是建立在.NET 上并由 Azure 托管的。 我已经到了这样的地步：我再也很少和平台迷们一起参加火焰战了，这简直是无利可图，我的时间最好花在其他事情上。 只要我看到 Microsoft 像他们使用 MVC 框架和 Azure 所做的那样继续发展它，我就会对.NET 作为启动平台充满信心。 如果我只是尝试在 RoR 或 Python 中构建 SD 只是为了时髦或者试图解决一些虚构的问题以扩展数百万个用户，我根本就不会启动该站点，因为总的时间投入和架构应用程序意味着 它从未完成过，而从未启动过的应用程序所带来的失败远大于后来尝试扩展的问题。 +Netflix 的基础设施位于 Amazon EC2 上，来自电影制片厂的数字电影原版存储在 Amazon S3 上。 使用云上的机器，根据视频分辨率和音频质量，每部电影被编码为 50 多种不同版本。 超过 1 PB 的数据存储在 Amazon 上。 这些数据被发送到内容传递网络，以将内容提供给本地 ISP。 -我认为您是对的，技术堆栈并不是杀死他们的工程文化的原因。 +Netflix 在后端使用了许多开源软件，包括 Java，MySQL，Gluster，Apache Tomcat，Hive，Chukwa，Cassandra 和 Hadoop。 -这是我的全部观点。 Myspace 肿。 到处都是垃圾邮件发送者和骗子。 他们允许人们无限使用 HTML 和 Java 来自定义其页面的事实，这意味着没有一致的用户体验，而且某些自定义页面需要花费几分钟才能加载或挂起 Web 浏览器。 然后是 Facebook。 一切都很干净有光泽，并且很容易找到所有的朋友（新老）。 另外，Facebook 提供了与 Myspace 的骗子和垃圾邮件发送者不同的步伐（是的，Facebook 拥有其中的一些功能，但与 Myspace 的体验完全不同）。 +[![](img/4d386bb464a1074eac1f4f986835c070.png)](http://2zmzkp23rtmx20a8qi485hmn.wpengine.netdna-cdn.com/wp-content/uploads/2015/11/netflix-architecture.png) -不要责怪这里的幕后技术（最终用户只要获得想要的用户体验就可以少在乎幕后的东西），也不要责怪洛杉矶。 洛杉矶有很多非常有才华的开发商。 +## 支持多种设备 -技术堆栈吸引或排斥工程师。 实际上，这确实很重要，最好的工程师想要使用他们认为是最好的工具。 +Netflix 上大量的编解码器和比特率组合意味着“在将相同的标题交付给所有流媒体平台之前，必须对其进行 120 次不同的编码”。 -我想认为.NET 可以根据我们的经验进行扩展，这只是做对的事情。 我们在 Flash / iOS UI，.NET 服务层以及 MySQL（XtraDB）数据库和 MySQL Cluster 数据库的混合堆栈上运行了成功的世界教育游戏。 它可能没有看到像 Facebook 这样庞大的规模，但是它在不到 4 天的时间里成功处理了将近 10 亿个服务器请求，有 250 万孩子参加了舞会，而我们背后的那些人则设法获得了愉快的体验 我们自己，只有 40％的基础架构得到了利用。 +尽管 Netflix 使用自适应比特率流技术来调整视频和音频质量以匹配客户的下载速度，但它们还为用户提供了在其网站上选择视频质量的能力。 -MySpace 失败，因为用户离开了。 用户（包括我自己）没有离开，因为它运行在 Microsoft 堆栈上。 我们离开是因为所有 MySpace 都对成为一家媒体公司感兴趣。 人们想要一个社交网络，而今天，Facebook 或多或少都是这样。 +您可以从提供 Netflix 应用程序的任何与 Internet 相连的设备上立即观看，例如计算机，游戏机，DVD 或蓝光播放器，HDTV，机顶盒，家庭影院系统，电话或平板电脑。 -MySpace 的问题是系统性的，而不是系统性的。 非专业的开发组织。 政治内斗。 诉讼。 他们从不曾是硅谷公司，而是一家以色情，垃圾邮件和恶意软件而诞生的洛杉矶公司，后来想成为好莱坞公司-他们贪婪地追求浮华与魅力，却拥有烂透了的技术核心。 +它们以不同的比特率支持以下编解码器中的每个标题，以使其在设备和连接上工作。 -Myspace 进行了有毒技术管理。 这是我唯一一次接受采访。 他们为才华横溢而不是因为缺乏才华，而是因为 CTO（缺乏个性）和他的兄弟般的小伙子使周围的环境变得可怕。 在洛杉矶，这里有很多伟大的才华，他们根本不愿意成为“好莱坞”。 +* 视频– [VC-1](https://en.wikipedia.org/wiki/VC-1) ， [H.264（AVC）](https://en.wikipedia.org/wiki/H.264)，VC-1， [H.263](https://en.wikipedia.org/wiki/H.263) ， [H.265（HEVC）](https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding) +* 音频– [WMA](https://en.wikipedia.org/wiki/Windows_Media_Audio) ，[杜比数字](https://en.wikipedia.org/wiki/Dolby_Digital)，[杜比数字 Plus](https://en.wikipedia.org/wiki/Dolby_Digital_Plus) ， [AAC](https://en.wikipedia.org/wiki/Advanced_Audio_Coding) 和 [Ogg Vorbis](https://en.wikipedia.org/wiki/Ogg_Vorbis) -我同意新闻集团杀死 MySpace 的想法。 没有互联网的人不应该管理互联网公司。 并不是后端服务器上正在运行的内容，而是当您访问首页时，它们让您头疼的大型恐怖视频广告/横幅广告。 这是设计不足的用户体验。 这是他们基于 Flash 的聊天应用程序从未起作用的事实。 +### Netflix Open Connect CDN -有许多与 Microsoft 堆栈一起工作的人才。 如果您的眼光正确，MS 技术可以使您更快地执行。 +Netflix Open Connect CDN 是为拥有超过 100,000 个订阅者的大型 ISP 提供的。 一种特殊构建的低功耗高存储密度设备可将 Netflix 内容缓存在 ISP 的数据中心内，以降低互联网传输成本。 该设备运行 FreeBSD 操作系统， nginx 和 Bird Internet 路由守护程序。 -简单而失败的原因是用户界面被大量吸引。 您需要登录页面，然后是实际页面，并且必须剪切并粘贴 javascript 代码段和 html 代码段等以使其正常工作。 然后，您必须去寻找其他东西来使这个或那个工作。 +![](img/46e25abc5f6631b9baee6e4c4b6cb016.png) -然后出现了 facebook，您登录时只有一个简单而简单的用户界面，其中包含一小套有效的工具来查找您的朋友。 然后，facebook 将游戏放入其 API 中，这可以让人们了解在何处以及为什么人们真正使用 facebook。 拿走游戏，您可能会失去一半以上的 facebook 人口。 但是总体的关键部分和前进的关键是一个轻巧的用户界面，它不需要您在网上搜索 javascript 小程序或 html 代码来创建 myspace 页面。 您有在 Facebook 中自定义或唯一的自由吗？ 并非完全不一样，对于 Twitter 一样，是的，您可以添加一个后挡板并用颜色标记一些内容，但总体来说，它锁定在用户刚刚使用的 UI 中。 +NetFlix 巴黎公开赛–图片来源：@dtemkintwitter -那是主要的区别，干净，易于使用的 UI 与糟糕的 UI 甚至使我成为 Web 开发人员的疯狂尝试。 如果真能说出我的妻子，更不用说我的母亲使用 myspace 了。 Facebook，尽管嘿，单击此信息选项卡，单击铅笔并填写一些内容，然后单击此查找朋友并享受。 +在处观看 Open Connect 视频[。](https://www.youtube.com/watch?v=mBCXdaukvcc) -@ fatal.error，各个领域都有出色的工程师.... NET，LAMP，JAVA 等... +## 缩放算法 -摘自文章：“这就是为什么 Facebook 能够部署几乎没有影响的新更改的原因-他们在让实际用户使用之前对其进行了所有测试和验证。” +在 2009 年，Netflix 举办了一项名为 [Netflix 奖](https://en.wikipedia.org/wiki/Netflix_Prize)的竞赛。 他们打开了一堆匿名数据，并允许团队尝试得出更好的算法。 获胜团队将现有算法提高了 10.06％。 Netflix 打算再获得一个 Netflix 奖，但最终没有这样做，因为 FTC 担心隐私。 -真？！ 您是否曾经开发过 FB 应用程序？ 您是否曾经听过全球开发人员大喊大叫的声音，是因为 FB 的男孩天才编码员将错误的代码投入了生产，并且破坏了所有人的应用程序？ 您是否曾经需要处理过时，不准确的文档以及不断变化的 API？ 以及如何神奇地实现 oauth。 +Netflix 推荐系统包含许多算法。 生产系统中使用的两个核心算法是受限玻尔兹曼机（RBM）和一种称为 SVD ++的矩阵分解形式。 使用线性混合将这两种算法结合在一起以产生单个更高的准确性估计。 -那篇文章真是太棒了。 我想我现在要去寻找一个著名的基于 Java 的失败... +受限玻尔兹曼机是经过修改以在协同过滤中工作的神经网络。 每个用户都有一个 RBM，每个节点的输入节点代表该用户已评分的电影。 -哈哈，我同意 FredTheKAt +SVD ++是 SVD（奇异值分解）的不对称形式，它利用了 RBM 等隐式信息。 它是由 Netflix 竞赛的获胜团队开发的。 -Facebook 在提供良好的开发人员体验方面毫无用处。 +Netflix 团队在其工程博客上介绍了[学习个性化主页](http://techblog.netflix.com/2015/04/learning-personalized-homepage.html) -然而，尽管应用程序在移动平台上是屈膝的（是的，我曾经使用过），但 Facebook 的抽奖卡是最终用户，可以跟上他们所有的朋友。 如果用户体验始终如一，那将是成功的。 MySpace 失败。 +## 开源项目 -我确实觉得很有趣，尽管认为自己锁定了 FB 个人资料的人现在已经以某种方式神奇地擦除了第三方在锁定之前（实际上是在他们授予游戏/应用访问权限之后）关于他们的所有数据。 数据却没有真正实现！ 如果人们真的了解 FB 的工作原理，我认为它不会那么受欢迎。 +[https://netflix.github.io/](https://netflix.github.io/) 。 Netflix 有一个很棒的工程博客，最近他们在 Netflix 上发表了一篇名为 [The Evolution of Open Source 的文章。](http://techblog.netflix.com/2015/10/evolution-of-open-source-at-netflix.html) -除了所有的技术故障（是的，我认为他们的代码很糟糕）之外，MySpace 的主题始终总是令人感到恶心-允许未成年的孩子不受监督地访问网络。 这些孩子（和我的孩子）长大了，获得了一定的品味，并发现 MySpace 俗气。 当年龄较大的孩子转向 Facebook 时，年龄较小的孩子们紧随其后。 +## 大数据 -MySpace 俗气。 孩子们（年龄较大和较小）不再认为 MySpace 很酷-这是有充分理由的。 +* [Genie](https://github.com/Netflix/genie) -对我们各种数据处理框架（尤其是 Hadoop）的强大，基于 REST 的抽象。 +* [Inviso](https://github.com/Netflix/inviso) -提供有关我们 Hadoop 作业和集群性能的详细见解。 +* [口红](https://github.com/Netflix/lipstick)-以清晰，可视的方式显示 Pig 作业的工作流程。 +* [Aegisthus](https://github.com/Netflix/aegisthus) -启用从 Cassandra 中批量提取数据以进行下游分析处理。 -新闻集团买了一些黏糊糊的东西，现在赔本了。 好。 +## 构建和交付工具 -MySpace 很棒，但是当他们想成为 Facebook 的时候，他们就完全失去了可爱的功能。 这以及对用户的完全不尊重使我停止了回来。 并非所有事情都与竞争相同……要独树一帜，这是我的建议……技术应促进一个目的，而不是目的。 +* [Nebula](https://nebula-plugins.github.io/) -Netflix 努力共享其内部构建基础结构。 +* [代理程序](https://github.com/Netflix/aminator)-用于创建 EBS AMI 的工具。 +* [Asgard](https://github.com/Netflix/asgard) -用于 Amazon Web Services（AWS）中的应用程序部署和云管理的 Web 界面。 -由于放弃了其功能集和可用性，MySpace“丢失了”。 +## 通用运行时服务&库 -如果您无法像 Facebook 一样快增长，那又如何呢？ MySpace 拥有自己的利基市场，并在自己的领域处于领先地位-年轻人的音乐和社交网络。 +* [Eureka](https://github.com/Netflix/eureka) -Netflix 云平台的服务发现。 +* [Archaius](https://github.com/Netflix/archaius) -分布式配置。 +* [功能区](https://github.com/Netflix/ribbon)-弹性和智能的进程间和服务通信。 +* [Hystrix](https://github.com/Netflix/hystrix) -提供超越单次服务呼叫的可靠性。 在运行时隔离等待时间和容错能力。 +* **[Karyon](https://github.com/Netflix/karyon)** 和 **[控制器](https://github.com/Netflix/governator)-** JVM 容器服务。 +* [Prana](https://github.com/Netflix/prana) sidecar - +* [Zuul](https://github.com/Netflix/zuul) -在云部署的边缘提供动态脚本化代理。 +* [Fenzo](https://github.com/Netflix/Fenzo) -为云本机框架提供高级调度和资源管理。 -此故障与 Microsoft 技术无关。 +## 数据持久性 -技术人员不会创新或设计，他们会实施 +* **[EVCache](https://github.com/Netflix/EVCache)** 和 **[炸药](https://github.com/Netflix/dynomite)** **-** 用于大规模使用 Memcached 和 Redis。 +* **[Astyanax](https://github.com/Netflix/astyanax)** 和 **[Dyno](https://github.com/Netflix/dyno)** **-** 客户端库可更好地使用云中的数据存储。 -成功的网站是由用户体验驱动的。 Facebook 和 Twitter 是示例。 因为他们真正关心最终用户，所以他们所做的事情可以提供良好的体验。 设计师和建筑师的工作是否能够提供良好的用户体验，而不是“老板”会感到高兴。 +## 洞察力，可靠性和性能 -因此，这是关于文化和人员（主要是关于大老板，他必须关心最终用户），而不是技术。 +* [Atlas](https://github.com/Netflix/atlas) -时间序列遥测平台 +* [Edda](https://github.com/Netflix/edda) -跟踪云中更改的服务 +* [观众](https://github.com/Netflix/spectator)-Java 应用程序代码与 Atlas 的轻松集成 +* [向量](https://github.com/Netflix/vector)-以最小的开销公开高分辨率的主机级指标。 +* [Ice](https://github.com/Netflix/ice) -揭示了持续的成本和云利用率趋势。 +* [Simian Army](https://github.com/Netflix/SimianArmy) -测试 Netflix 实例是否出现随机故障。 -但是，另一方面，最佳用户体验驱动的网站通常不是基于 MSFT，IBM 或 ORACLE 的 COTS 产品构建的。 那也可以说。 +## 安全性 -“技术不是创新或设计，而是实施” +* [Security Monkey](https://github.com/Netflix/security_monkey) -帮助监视和保护基于 AWS 的大型环境。 +* [Scumblr](https://github.com/Netflix/scumblr) -利用整个 Internet 的针对性搜索来发现特定的安全问题以进行调查。 +* [MSL](https://github.com/Netflix/MSL) -一种可扩展且灵活的安全消息传递协议，可解决许多安全通信用例和要求。 +* [Falcor](https://netflix.github.io/falcor/) -通过虚拟 JSON 图将远程数据源表示为单个域模型。 +* [Restify](https://github.com/restify/node-restify) -专门用于 Web 服务 API 的 node.js REST 框架 +* [RxJS](https://github.com/ReactiveX/RxJS) -用于 JavaScript 的反应式编程库 -@另一个声音：醒来的人..... +## 参考资料 -说.NET 是 MySpace 失败的原因，就像说 MySQL 是 Facebook 成功的原因。 两种说法都是荒谬的。 +1. [关于 HackerNews](https://news.ycombinator.com/item?id=10534219) +2. [https://zh.wikipedia.org/wiki/Netflix](https://en.wikipedia.org/wiki/Netflix) +3. [http://gizmodo.com/this-box-can-hold-an-entire-netflix-1592590450](http://gizmodo.com/this-box-can-hold-an-entire-netflix-1592590450) +4. [http://edition.cnn.com/2014/07/21/showbiz/gallery/netflix-history/](http://edition.cnn.com/2014/07/21/showbiz/gallery/netflix-history/) +5. [http://techblog.netflix.com/2015/01/netflixs-viewing-data-how-we-know-where.html](http://techblog.netflix.com/2015/01/netflixs-viewing-data-how-we-know-where.html) +6. [https://gigaom.com/2013/03/28/3-shades-of-latency-how-netflix-built-a-data-architecture-around-timeliness/](https://gigaom.com/2013/03/28/3-shades-of-latency-how-netflix-built-a-data-architecture-around-timeliness/) +7. [https://gigaom.com/2015/01/27/netflix-is-revamping-its-data-architecture-for-streaming-movies/](https://gigaom.com/2015/01/27/netflix-is-revamping-its-data-architecture-for-streaming-movies/) +8. [http://stackshare.io/netflix/netflix](http://stackshare.io/netflix/netflix) +9. [https://www.quora.com/How-does-the-Netflix-movie-recommendation-algorithm-work](https://www.quora.com/How-does-the-Netflix-movie-recommendation-algorithm-work) +10. [https://netflix.github.io/](https://netflix.github.io/) -没有 1.）任何内幕知识 2.）有很多事实或实质可以支持，但这里有很多观点。 这是一个完全愚蠢的陈述，它既显示了对技术的严重误解，也显示了使业务成功或失败的根本过分简化。 +在哪里提到 Spring？ Netflix 的所有 Java 都在 Spring 框架的上下文中。 -我向所有神圣的事情祈祷，我自己不必再在.NET 中工作。 这不是我的最爱，严格来说，由于许可证成本，它可能不是小型初创公司的好选择，但这只是纯粹的精英 BS 所说的，仅仅是因为您的技术堆栈是.NET，所以您不是创新者或 与竞争对手相比，您在技术上有残障。 +到目前为止，这还不是一个完整的列表。 不好的文章。 -如果您足够愚蠢以至于无法让这些话从您的嘴里溜走，我建议您更好地隐藏内心的障碍。 它正在显示，每个人都可以看到。 +NetFlix 不使用 Spring，至少他们从未在任何演示文稿或白皮书中提及 Spring。 -我在看着你 Scoble。 坚持您所了解的主题。 +我在这里看不到他们使用 Node.JS 吗？ 我记得曾经从他们那里看到幻灯片，谈论他们如何处理 Node.JS 的服务以及如何优化这些服务。 -不是技术，也不是城市。 是福克斯。 +有一些使用 Spring 的应用程序，但是 95％以上的 Java 应用程序直接使用 Guice 或通过 Governor 增强。 -被 Fox 收购后，Myspace 的命运得以终结。 购买后，我们的目标是通过各种方式使网站获利，并尝试为可想象的每种广告资源建立少量的垂直市场... myspace 天气 myspace 汽车 myspace 等等。 他们对用户没有真正的构想，方向或价值主张。 +他们在那里的服务中使用 guice 代替。Governator 是一个很好的 guice 扩展库，尽管将它们标记为已弃用，您仍可以在该库中找到一些硬编码的依赖项。 -一旦来自 Facebook 的威胁得以实现，缺乏真正领导才能的痛苦就变得显而易见。 他们开始复制并关注 Facebook 所做的事情-反应而不是创新。 游戏结束。 +好像他们没有在使用 docker ... -这太糟糕了。 一次 MySpace 是年轻人去表达自己并分享音乐品味的地方。 MySpace 应该完全拥有音乐产业。 +您在“受限玻尔兹曼机器”中写了“玻尔兹曼”错误。 -我将不得不同意 MySp Fox 的购买，但没有做任何其他事情，只是错过了管理其资产的工作，也没有采取任何措施来改善它。 也许他们需要写一些税款。 但是除非您确定自己知道如何使它更好地工作以便可以提高利润，否则您不会购买任何东西。 直到交易完成约 30 天，它的表现都不错。 在[闪光灯](http://www.arcflashstudynow.com)中，您几乎可以看到它开始爆炸。 只是我的想法希望没有人会被他们冒犯。 :)很棒的信息。 +@ cmp，restify 是使用 Node 并为其构建的 Web API 框架。 -在研究（针对单篇论文）关于社交网站的技术含义以及为什么其中一些失败如此之快而另一些却没有这样时，我遇到了这篇文章。 关于它的技术，这种技术是您经常听到的技术，因此这篇文章对我来说是一本好书。 +本文是有缺陷的，它没有说明软件公司最重要的事情，即：他们使用哪个需求管理系统，以及它们如何保持需求与代码之间的可处理性？ -但是，如果它们达到 Facebook 的大小会怎样？ 这样可以达到这样的规模吗？ -这是一个有趣的（研究）问题-也许可以解决技术问题，在这种情况下，更大的问题是“如何向 MS 支付许可费？” -我保证：如果像彼得·泰尔这样的投资者走上原来的道路，他们不会给他们钱？ +他们确实使用 Spring Cloud，这是参考 https://2015.event.springone2gx.com/schedule/sessions/spring_cloud_at_netflix.html -MySpace 允许用户在其页面上放置无限数量的应用之后，立即开始令人垂涎。 它导致页面加载和 Web 服务器无法正常运行。 他们通常不会使 CPU 或内存最大化，但会引发无数错误。 每天都会将网络中断带到一个大房间里，以责骂失败者（员工）。 糟透了。 +炸药列在错误的类别下。 当前，它是一个分布式的内存存储。 -对于 50％负载的计算机，解决方案是对其进行虚拟化，而不是修复奇怪的创可贴和少量垃圾。 +出色的工作！ +从所有者到 Netflix 的内容交付（关系图上的左箭头）使用 SMPTE 的可互操作主格式（IMF）。 视频使用 JPEG-2000 编码，音频未编码（线性 PCM）。 内容使用 MXF 打包（例如，非常类似于 D-Cinema 的内容）。 +SMPTE 当前正在努力扩展此标准，以支持 HDR +视频：高动态范围（HDR）可提供更多的对比度，宽色域（WCG）可提供更多的颜色，高帧速率（HFR）可以每秒 50 帧或更多。 +来自 Netflix 的 Chris Fetner 提供详细信息的柏林论坛 2015 年会议上的详细信息： +http://www.mesclado.com/smpte-forum-2015-future-proofing-media-production-part-3/ ？lang = en -Captcha 被收费低廉的印度人团队殴打（没有冒犯的意思），但他们同意不对进一步揭露他的方法的人采取进一步的法律行动。 并不复杂。 因此，在垃圾用户，垃圾邮件发送者和他们可能会塞进的每一个垃圾功能之间走下坡路。 +Netflix 还使用 Groovy 编程语言和 RxJava 进行功能性反应式编程（请参阅 http://de.slideshare.net/InfoQ/functional-reactive-programming-in-the-netflix-api） -我的 2 美分。 \ No newline at end of file +Netflix 使用 ElasticBox 来管理后台。 他们还在许多地方使用 Docker。 + +Netflix 还运营着一个相当大的 Elasticsearch 集群。 参见 https://www.elastic.co/videos/netflix-using-elasticsearch/和 https://www.elastic.co/elasticon/2015/sf/arrestful-development-how-netflix-uses-elasticsearch-to- 更好地了解 + +Netflix 是 Apache Cassandra 的已知用户。 他们的技术博客对此进行了广泛报道，而 Netflix 对此已经非常公开。 （作为一个旁注，我在同一博客上找不到任何标记 DynamoDB 的帖子）。 + +Netflix 使用 Node.JS。 本文只有 50％正确。 这里的一些内容，我们已经从其他内容切换到了。 我在 Netflix 的工程团队工作。 我们确实使用 Cassandra。 我们还使用 Reactor.JS。 一直在进行变化以适应技术变化。 我们混合使用了 JS 库，并完成了许多自定义工作，例如滑块。 + +netflix 是否使用带有 typescript 的节点，它们如何使用动态类型的 JS 维护大型节点应用程序 + +只需在 github 上的 Netflix 上寻找 Java 技术，他们为 Spring-Cloud 做出了很大贡献。 +另请参阅 OSS：https：//netflix.github.io/ \ No newline at end of file diff --git a/docs/185.md b/docs/185.md index 2d7e2ff..0a989e7 100644 --- a/docs/185.md +++ b/docs/185.md @@ -1,192 +1,181 @@ -# Facebook 的新实时分析系统：HBase 每天处理 200 亿个事件 - -> 原文： [http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html](http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html) - -![](img/dff64aa536c627923d7cfaf30eb1ea94.png) Facebook 再次这样做。 他们建立了另一个系统，能够对大量的实时数据流进行有用的处理。 上次我们看到 Facebook 发布其[新的实时消息系统：HBase 每月存储 135 亿条消息](http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html)。 这次，它是一个实时分析系统，每天处理*超过 200 亿个事件（每秒 200,000 个事件），时延不到 30 秒*。 - -Facebook 工程经理 Alex Himel [解释了他们构建的](http://www.facebook.com/note.php?note_id=10150103900258920)（[[视频](http://www.facebook.com/video/video.php?v=707216889765&oid=9445547199&comments)）以及所需的规模： - -> 在过去的一年中，社交插件已成为数百万网站的重要且不断增长的流量来源。 上周，我们发布了新版本的“网站洞察”，以使网站所有者可以更好地分析人们如何与其内容进行互动，并帮助他们实时优化网站。 为此，我们必须设计一个系统，每天处理 200 亿个事件（每秒 200,000 个事件），而延迟不到 30 秒。 - -亚历克斯在演讲中做得很好。 强烈推荐。 但是让我们更深入地了解发生了什么... - -Facebook 通过通过[社交插件](http://developers.facebook.com/docs/plugins/)的病毒传播，将非 Facebook 网站重新绑定到 Facebook 中，并将 Facebook 网站重新绑定到 Facebook 中，从而实现了这种强大的分析系统的需求，这是 Facebook 出色的计划，旨在实现全球网络统治 非 Facebook 网站。 基本上，人们可以做的任何事情都会被 Facebook 捕获并反馈，而 Facebook 上所做的任何事情都可以显示在您的网站上，从而在两者之间建立更紧密的联系。 - -Facebook 的社交插件是 Roman Empire Management101。您不必征服所有人就可以建立帝国。 您只要控制每个人，使他们意识到自己可以被征服的威胁，同时使他们意识到，哦，与罗马友好可以赚很多钱。 我记得这一策略已经工作了很长时间。 - -毫无疑问，您在网站上看到了社交插件。 社交插件可让您查看朋友喜欢，在网络上的站点上评论或共享的内容。 想法是将社交插件放在网站上，使内容更具吸引力。 您的朋友可以看到您喜欢的东西，而网站可以看到每个人都喜欢的东西。 引人入胜的内容为您带来更多点击，更多喜欢和更多评论。 对于企业或品牌甚至个人而言，内容越具有吸引力，人们看到的内容就越多，新闻源中出现的内容就越多，从而将其吸引到网站的流量也就越大。 - -以前的孤狼网是内容猎人无声无息地跟踪着网站的地方，如今已变成一个迷人的小村庄，每个人都知道您的名字。 这就是社交的力量。 - -例如，此处有关 HighScalability 的帖子现在具有 [Like 按钮](http://developers.facebook.com/docs/reference/plugins/like/)。 TechCrunch 已使用 Facebook 的评论系统移至[。 立即辩论集中在评论系统本身的质量上，但这并不是重点，重点是使 TechCrunch 更深入地投入到 Facebook 的 500+百万用户的生态系统中。 其他插件包括：推荐，活动源，登录，注册，Facepile 和实时流。](http://techcrunch.com/2011/03/01/facebook-rolls-out-overhauled-comments-system-try-them-now-on-techcrunch/) - -除非您能理解所有这些数据，否则它们意义不大，并且还向内容提供商证明了社交插件确实确实使他们的网站更具吸引力。 这就是 Facebook 的[洞察系统](http://www.allfacebook.com/facebook-rolls-out-expanded-insights-for-domains-2011-03)出现的地方。这是一个分析系统，可让您访问所收集的所有多汁数据。 它提供统计信息，例如“赞”按钮分析，“评论”框分析，“热门页面”，“受众特征”和“自然共享”。 - -想象一下，数百万个网站和数十亿个页面以及数百万的人通过这些社交插件不断地流式传输数据。 您如何实时理解所有这些数据？ 这是一个具有挑战性的问题。 - -## 价值主张 - -借助 Insights System，内容生产者可以看到人们喜欢的东西，这将使内容生产者能够产生更多人们喜欢的东西，从而提高网络的内容质量，从而为用户提供更好的 Facebook 体验。 - -## 系统目标 - -* 以非常可靠的方式为人们提供实时计数器，这些计数器涉及许多不同的指标，并解决了数据偏差问题。 -* 提供匿名数据。 您无法弄清这些人是谁。 -* 展示为什么插件很有价值。 您的业​​务从中获得什么价值？ -* 使数据更具可操作性。 帮助用户采取行动，使其内容更具价值。 - * 新的 UI 隐喻。 使用漏斗的想法。 - * 有多少人看到了该插件，有多少人对此采取了行动，以及有多少人转化为访问您网站的流量。 -* 使数据更及时。 - * 他们实时进行。 从 48 小时转向 30 秒。 - * 消除了多个故障点以实现此目标。 - -## 挑战性 - -* **许多事件类型** - * 跟踪 100 多个指标。 - * 插件印象。 - * 喜欢 - * 新闻提要印象 - * 新闻订阅源点击 - * 客层 -* **大量数据** - * 每天 200 亿个事件（每秒 200,000 个事件） -* **数据偏斜-密钥分布不均** - * 喜欢遵循类似幂律分布的方法。 长尾巴很少有人喜欢，但有些资源却得到大量喜欢。 - * 这带来了热区，热键和锁争用的问题。 - -## 实现了一堆不同的原型 - -* **MySQL 数据库计数器** - * 排有一把钥匙和一个柜台。 - * 导致大量数据库活动。 - * 统计信息每天存储在桶中。 每天午夜时分，统计数据都会累积。 - * 当达到过渡期时，这将导致对数据库的大量写入，从而导致大量的锁争用。 - * 尝试通过考虑时区来分散工作。 - * 试图以不同的方式分割事物。 - * 高写入率导致锁争用，很容易使数据库超载，必须不断监视数据库，并且必须重新考虑其分片策略。 - * 解决方案不适合该问题。 -* **内存中计数器** - * 如果您担心 IO 中的瓶颈，则将其全部放入内存中。 - * 没有规模问题。 计数器存储在内存中，因此写入速度快并且计数器易于分片。 - * 由于未说明的原因，感觉到内存中的计数器并不像其他方法那样准确。 甚至只有 1％的失败率也是不可接受的。 Analytics（分析）可以赚钱，所以计数器必须非常准确。 - * 他们没有实现这个系统。 这是一个思想实验，准确性问题导致他们继续前进。 -* **MapReduce** - * 将 Hadoop / Hive 用于先前的解决方案。 - * 灵活。 易于运行。 可以处理大量写入和读取的 IO。 不必知道他们将如何提前查询。 数据可以存储然后查询。 - * 不是实时的。 许多依赖项。 很多失败点。 复杂的系统。 不够可靠，无法达到实时目标。 -* **卡桑德拉** - * 基于可用性和写入率，HBase 似乎是一个更好的解决方案。 - * 写速度是要解决的巨大瓶颈。 - -## 获胜者：HBase + Scribe + Ptail + Puma - -* 在高层次上： - * HBase 在分布式计算机上存储数据。 - * 使用尾部架构，新事件存储在日志文件中，并且尾部有日志。 - * 系统汇总事件并将其写入存储。 - * UI 会拉出数据并将其显示给用户。 -* 数据流 - * 用户在网页上单击“赞”。 - * 向 Facebook 发送 AJAX 请求。 - * 使用 Scribe 将请求写入日志文件。 - * 编写极其精简的日志行。 日志行越紧凑，则可以在内存中存储的越多。 - * 抄写员处理文件翻转之类的问题。 - * Scribe 建立在 Hadoop 建立在同一个 HTFS 文件存储上。 - * 尾巴 - * 使用 Ptail 从日志文件读取数据。 Ptail 是一个内部工具，用于聚合来自多个 Scribe 存储的数据。 它拖尾日志文件并提取数据。 - * Ptail 数据分为三个流，因此最终可以将它们发送到不同数据中心中自己的群集。 - * 插件印象 - * 新闻提要印象 - * 动作（插件+新闻源） - * 彪马 - * 批处理数据可减少热键的影响。 尽管 HBase 每秒可以处理大量写入操作，但它们仍要批处理数据。 热门文章会产生大量的印象和新闻提要印象，这将导致巨大的数据偏斜，从而导致 IO 问题。 批处理越多越好。 - * 批量平均 1.5 秒。 想要批处理更长的时间，但是它们具有太多的 URL，以至于在创建哈希表时它们用尽了内存。 - * 等待上一次刷新完成以开始新批处理，以避免锁争用问题。 - * UI 渲染数据 - * 前端都是用 PHP 编写的。 - * 后端是用 Java 编写的，并且 Thrift 用作消息传递格式，因此 PHP 程序可以查询 Java 服务。 - * 缓存解决方案用于使网页显示更快。 - * 效果因统计信息而异。 计数器可以很快回来。 在域中查找顶级 URL 可能需要更长的时间。 范围从 0.5 到几秒钟。 - * 缓存的数据越长越长，实时性就越差。 - * 在 Memcache 中设置不同的缓存 TTL。 - * MapReduce - * 然后将数据发送到 MapReduce 服务器，以便可以通过 Hive 查询。 - * 这也可以用作备份计划，因为可以从 Hive 恢复数据。 - * 一段时间后，原始日志将被删除。 -* HBase 是分发列存储。 - * Hadoop 的数据库接口。 Facebook 的内部人员在 HBase 上工作。 - * 与关系数据库不同，您不在表之间创建映射。 - * 您不创建索引。 您拥有主行键的唯一索引。 - * 通过行键，您可以拥有数百万个稀疏列的存储。 非常灵活。 您不必指定架构。 您定义列族，可以随时向其中添加键。 - * WAL 预写日志是可伸缩性和可靠性的关键功能，它是应该执行的操作的日志。 - * 根据密钥，数据将分片到区域服务器。 - * 首先写给 WAL。 - * 数据被存入内存。 在某个时间点，或者如果已经积累了足够的数据，则将数据刷新到磁盘。 - * 如果机器出现故障，您可以从 WAL 重新创建数据。 因此，不会永久丢失数据。 - * 结合使用日志和内存存储，它们可以可靠地处理极高的 IO 率。 - * HBase 处理故障检测并自动跨故障路由。 - * 当前，HBase 重新分片是手动完成的。 - * 自动热点检测和重新分片在 HBase 的路线图上，但还没有。 - * 每个星期二，有人查看密钥并决定对分片计划进行哪些更改。 -* **模式** - * 在每个 URL 上存储一堆计数器。 - * 行键是唯一的查找键，是反向域的 MD5 哈希 - * 选择适当的密钥结构有助于扫描和分片。 - * 他们遇到的问题是将数据正确分片到不同的计算机上。 使用 MD5 哈希值可以更容易地说出该范围在此处，该范围在该位置。 - * 对于 URL，它们会执行类似的操作，此外还会在其上添加一个 ID。 Facebook 中的每个 URL 都有一个唯一的 ID，该 ID 用于帮助分片。 - * 使用反向域，例如 *com.facebook /* ，以便将数据聚集在一起。 HBase 确实擅长扫描集群数据，因此，如果他们存储数据以便集群在一起，则它们可以有效地计算整个域的统计信息。 - * 将每行 URL 和每个单元格视为一个计数器，就可以为每个单元格设置不同的 TTL（生存时间）。 因此，如果每小时进行一次计数，则没有必要永久保留每个 URL，因此他们将 TTL 设置为两周。 通常按每个列族设置 TTL。 -* 每个服务器每秒可处理 10,000 次写入。 -* 从日志文件读取数据时，检查点用于防止数据丢失。 - * 裁缝将日志流检查点保存在 HBase 中。 - * 在启动时重播，因此不会丢失数据。 -* 用于检测点击欺诈，但没有内置欺诈检测。 -* **泰勒热点** - * 在分布式系统中，系统的一个部分可能比另一个部分更热。 - * 一个示例是区域服务器可能很热，因为以这种方式定向了更多的密钥。 - * 一个尾巴也可能落后于另一个。 - * 如果一个拖尾落后一个小时，而其他拖尾已经更新，那么您将在 UI 中显示哪些数字？ - * 例如，展示次数比操作要高得多，因此点击率在过去一小时中要高得多。 - * 解决方案是找出最新的拖尾，并在查询指标时使用。 -* **未来方向** - * **热门列表** - * 对于 YouTube 这样的域名，很难找到最喜欢的 URL（最受欢迎的 URL），因为这些 URL 可以快速共享数百万个 URL。 - * 需要更多创新的解决方案来保持内存中的排序并随着数据的变化而保持最新。 - * **不同的用户计数** - * 一个时间窗中**上有多少人喜欢某个 URL。 在 MapReduce 中很容易做到，而在幼稚的计数器解决方案中很难做到。** - * **适用于社交插件**以外的应用程序 - * **移至多个数据中心** - * 当前是单个数据中心，但希望迁移到多个数据中心。 - * 当前的后备计划是使用 MapReduce 系统。 - * 备份系统每晚都会进行测试。 比较针对 Hive 和此新系统的查询，以查看它们是否匹配。 -* **项目** - * 花了大约 5 个月的时间。 - * 首先有两名工程师开始从事该项目。 然后添加了 50％的工程师。 - * 前端有两个 UI 人员​​。 - * 看起来大约有 14 个人从工程，设计，PM 和运营中从事了该产品的工作。 - -当我们查看消息传递系统和此分析系统时，我们注意到两个系统的共同点：大量，HBase，实时。 以可靠，及时的方式处理大量写入负载的挑战是这些问题的共同基础。 Facebook 专注于 HBase，Hadoop，HDFS 生态系统，并指望稍后解决的操作问题。 其他人之所以选择 Cassandra，是因为他们喜欢 Cassandra 的可伸缩性，多数据中心功能以及易于使用的功能，但它并不适合整个分析堆栈。 - -这对您意味着什么？ 即使您不是 Facebook，该体系结构也足够简单，并且由足够多的现成工具组成，甚至可以用于许多小型项目。 - -## 相关文章 - -* [Medialets 体系结构-击败艰巨的移动设备数据洪水](http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html)-分析平台的另一种表现。 -* [Twitter 的计划分析 1000 亿条推文](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) -* [扩展分析解决方案技术讲座（3/2/11）[HQ]](http://www.facebook.com/video/video.php?v=707216889765&oid=9445547199&comments) - -这是一个很棒的文章。 如何在不同的时间范围内进行汇总？ 每个<计数器和时间窗口>对都有单独的单元格吗？ - -好消息是，即使您不是 Facebook 人士，也没有整个工程师团队来构建您的分析平台，您仍然可以使用现有的带有 [OpenTSDB](http://opentsdb.net) 的开源软件来构建类似的平台。 在 StumbleUpon，我们仅使用 20 个节点群集中的 3 个即可轻松地[每秒处理 200,000 个事件](https://issues.apache.org/jira/browse/HBASE-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008872#comment-13008872)，因此，大概您还可以使用更多节点轻松地将其扩展为每天数十亿个事件。 - -当 Facebook 工程师在 6 个月前启动该项目时，Cassandra 没有分布式计数器，该计数器现在已提交到主干中。 Twitter 正在 Facebook 上投入大量资金用于实时分析（请参阅 Rainbird）。 由于计数器写入分散在多个主机上，因此写入速率对于 Cassandra 来说应该不是瓶颈。 对于 HBase，每个计数器仍然受单个区域服务器性能的约束吗？ 两者的性能比较将很有趣。 - -一个简单的问题-如果您拖尾的日志文件可能以不同的速率写入，那么您如何知道从头到尾有多少行？ 尾巴-跟随什么？ 但是，如何将其传送到另一个程序？ - -谢谢 - -HBase 表中的主键不是索引。 由于行以排序顺序存储，因此查找速度很快。 - -这些家伙在做什么只是在计数在线中/事件中的事件.....没什么好说的，这全都取决于一个人可以计数的速度...... -我认为他们也使它变得复杂 只是为了计算这些点击/事件 \ No newline at end of file +# Wistia 如何每小时处理数百万个请求并处理丰富的视频分析 + +> 原文： [http://highscalability.com/blog/2015/11/23/how-wistia-handles-millions-of-requests-per-hour-and-process.html](http://highscalability.com/blog/2015/11/23/how-wistia-handles-millions-of-requests-per-hour-and-process.html) + +*这是来自 [Christophe Limpalair](https://twitter.com/ScaleYourCode) 的来宾[转贴](https://scaleyourcode.com/interviews/interview/18)，他在接受 [Max Schnur](https://twitter.com/maxschnur) 采访时，在 [Wistia [](http://wistia.com/) 。* + +Wistia 是企业视频托管。 他们提供像热图一样的视频分析，并且使您能够添加号召性用语。 我真的很想了解所有不同组件的工作方式以及它们如何流式传输大量视频内容，因此这是本集重点介绍的内容。 + +## Wistia 的堆栈是什么样的？ + +正如您将看到的，Wistia 由不同的部分组成。 以下是支持这些不同部分的一些技术： + +* [HAProxy](http://www.haproxy.org/) +* [Nginx](http://nginx.org/) +* [MySQL](https://www.mysql.com/) （共享） +* [Ruby on Rails](http://rubyonrails.org/) +* [独角兽](http://unicorn.bogomips.org/)和某些服务在 [Puma](http://puma.io/) 上运行 +* [nsq](https://github.com/wistia/nsq-ruby) （他们编写了 Ruby 库） +* [Redis](http://redis.io/) （正在缓存） +* [Sidekiq](http://sidekiq.org/) 用于异步作业 + +## 您的规模是多少？ + +[Wistia](http://wistia.com/) 包含三个主要部分： + +1. Wistia 应用程序（用户登录并与该应用程序互动的“枢纽”） +2. 酒厂（统计处理） +3. 面包店（转码和投放） + +以下是一些统计信息： + +* **每小时加载 150 万个播放器**（加载一个播放器的页面计为一个。两个播放器计为两个，依此类推……） +* **每小时向其 Fastly CDN 发出 1880 万个高峰请求** +* **每小时 740,000 个应用程序请求** +* **每小时转码 12,500 个视频** +* **每小时 150,000 播放** +* **每小时统计 ping 达 800 万次** + +它们在 [Rackspace](http://www.rackspace.com/) 上运行。 + +## 接收视频，对其进行处理然后为它们提供服务会带来什么挑战？ + +1. **They want to balance quality and deliverability**, which has two sides to it: + 1. 原始视频的编码派生 + 2. 知道何时玩哪个衍生品 + + 在这种情况下，衍生产品是视频的不同版本。 具有不同质量的版本很重要，因为它使您可以减小文件的大小。 这些较小的视频文件可以以较少的带宽提供给用户。 否则，他们将不得不不断缓冲。 有足够的带宽？ 大！ 您可以享受更高质量（更大）的文件。 + + 拥有这些不同的版本并知道何时播放哪个版本对于良好的用户体验至关重要。 + +2. **很多 I / O。** 当用户同时上传视频时，最终将不得不在群集之间移动许多繁重的文件。 这里很多事情都会出错。 +3. **波动率。** 请求数量和要处理的视频数量均存在波动。 他们需要能够承受这些变化。 +4. **当然，提供视频也是一个主要挑战。** 幸运的是，CDN 具有不同类型的配置来帮助实现这一目标。 +5. **在客户端，有很多不同的浏览器，设备大小等...** 如果您曾经不得不处理使网站具有响应能力或在较旧的 IE 版本上工作，那么您确切地知道我们 在这里谈论。 + +## 您如何处理视频上传数量的重大变化？ + +他们有被称为 *Primes* 的盒子。 这些 Prime 盒子负责接收用户上传的文件。 + +如果上载开始占用所有可用磁盘空间，则它们可以使用 Chef 食谱启动新的 Prime。 目前，这是一项手动工作，但通常情况下，他们无法达到极限。 他们有很多空间。 + +![](img/73f5f62446151023481c92a8919f5c87.png) + +## 您使用哪种转码系统？ + +转码部分是他们所谓的*面包店*。 + +面包房由我们刚刚看过的 Prime 组成，可以接收和提供文件。 他们也有一群工人。 工作者处理任务并从上传的视频创建派生文件。 + +这部分需要强壮的系统，因为它非常消耗资源。 多强壮 + +我们说的是数百名工人。 每个工人通常一次执行两项任务。 它们都具有 8 GB 的 RAM 和相当强大的 CPU。 + +工人要进行什么样的任务和处理？ 他们主要使用 x264 编码视频，这是一种快速编码方案。 通常可以将视频编码为视频长度的一半或三分之一。 + +视频还必须调整[的大小](http://www.movavi.com/support/how-to/resizing-video.html)，并且它们需要不同的[比特率](http://help.encoding.com/knowledge-base/article/understanding-bitrates-in-video-files/)版本。 + +此外，针对不同设备的编码配置文件也不同，例如 iPhone 的 [HLS](http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-to-Encode-Video-for-HLS-Delivery-95251.aspx) 。 对于同样也是 x264 编码的 Flash 派生，这些编码需要加倍。 + +## 上传视频并对其进行转码的整个过程是什么样的？ + +用户上传视频后，该视频将排队并发送给工作人员进行转码，然后缓慢地转移到 S3。 + +无需立即将视频发送到 S3，而是将其推送到群集中的 Prime，以便客户可以立即提供视频。 然后，在几个小时内，文件被推到 S3 进行永久存储，并从 Prime 清除以腾出空间。 + +## 处理完视频后如何将其提供给客户？ + +当您播放 Wistia 上托管的视频时，您需要请求 embed.wistia.com/video-url，该请求实际上是在播放 CDN（他们使用了几种不同的 CDN。我只是尝试了一下，而我通过了 [Akamai](https://www.akamai.com/) ）。 CDN 可以追溯到 Origin，这就是我们刚刚谈到的 Prime。 + +Primes 通过称为“面包路线”的特殊平衡器运行 HAProxy。 面包路由是位于 Prime 前面并平衡流量的路由层。 + +Wistia 可能将文件本地存储在群集中（这将更快地提供服务），而 Breadroute 足够聪明，可以知道这一点。 如果真是这样，那么 Nginx 将直接从文件系统提供文件。 否则，它们代理 S3。 + +## 您如何分辨要加载的视频质量？ + +这主要是在客户端决定的。 + +Wistia 将在用户点击播放后立即接收有关用户带宽的数据。 在用户甚至没有点击播放之前，Wistia 都会接收有关设备，嵌入视频的大小以及其他启发式方法的数据，以确定该特定请求的最佳资产。 + +仅当用户进入全屏状态时才辩论是否要高清。 当用户第一次单击播放时，这使 Wistia 有机会不中断播放。 + +## 您怎么知道什么时候不加载视频？ 您如何监控呢？ + +他们拥有称为 *pipedream* 的服务，他们在应用程序和嵌入代码中使用该服务来不断地将数据发送回去。 + +如果用户单击播放，则会获得有关其窗口大小，窗口所在位置以及是否缓冲的信息（如果它处于播放状态，但几秒钟后时间没有改变）。 + +视频的一个已知问题是加载时间慢。 Wistia 想知道视频何时加载缓慢，因此他们尝试为此跟踪指标。 不幸的是，他们只知道如果用户实际上在等待负载完成才慢。 如果用户的连接速度确实很慢，他们可能会在此之前离开。 + +这个问题的答案？ 心跳。 如果他们收到心跳，却再也没有收到游戏，那么用户可能会保释。 + +## 您还收集其他哪些分析？ + +他们还为客户收集分析数据。 + +诸如播放，暂停，搜寻，转化（输入电子邮件或点击号召性用语）之类的分析。 其中一些显示在热图中。 他们还将这些热图汇总到显示参与度的图表中，例如人们观看和重看的区域。 + +![](img/09da6a8cd3164a8539ff1ea9e21ed5bc.png) + +## 您如何获得如此详细的数据？ + +播放视频时，他们使用视频跟踪器，该跟踪器是绑定到播放，暂停和搜索的对象。 该跟踪器将事件收集到数据结构中。 每 10 到 20 秒一次，它会回传至 Distillery，该酒厂又找出如何将数据转换为热图。 + +为什么每个人都不这样做？ 我问他，因为我什至没有从 YouTube 获得此类数据。 马克斯说，原因是因为它非常密集。 酿酒厂处理大量的东西，并拥有一个庞大的数据库。 + +![](img/5b080d374f1ec07d3568462b49fa2d75.png) +（ *http://www.cotswoldsdistillery.com/First-Cotswolds-Distillery-Opens* ） + +## 什么是扩展易用性？ + +Wistia 拥有约 60 名员工。 一旦开始扩大客户群，就很难确保继续保持良好的客户支持。 + +它们的最高接触点是播放和嵌入。 这些因素有很多无法控制的因素，因此必须做出选择： + +1. 不要帮助客户 +2. 帮助客户，但需要很多时间 + +这些选择还不够好。 取而代之的是，他们追究导致客户支持问题最多的来源-嵌入式。 + +嵌入经历了多次迭代。 为什么？ 因为他们经常破产。 不管是 WordPress 做一些奇怪的嵌入，还是 Markdown 破坏嵌入，随着时间的推移，Wistia 都遇到了很多问题。 为了解决这个问题，他们最终大大简化了嵌入代码。 + +这些更简单的嵌入代码在客户端遇到的问题更少。 尽管确实在后台增加了更多的复杂性，但是却导致了更少的支持请求。 + +这就是 Max 通过扩展易用性的含义。 使客户更轻松，这样他们就不必经常与客户支持联系。 即使这意味着更多的工程挑战，对他们来说也是值得的。 + +缩放易用性的另一个示例是回放。 Max 确实对实现一种客户端 CDN 负载均衡器感兴趣，该负载均衡器确定了从中提供内容的最低延迟服务器（类似于 Netflix 所做的事情）。 + +## 您现在正在从事哪些项目？ + +Max 计划很快启动的就是他们所说的上载服务器。 这个上载服务器将使他们能够对上载做很多很酷的事情。 + +正如我们所讨论的那样，对于大多数上载服务，您必须等待文件到达服务器，然后才能开始转码并对其进行处理。 + +上传服务器将使上传时可以进行转码。 这意味着客户可以在视频完全上传到系统之前就开始播放他们的视频。 他们还可以获取静止图像并几乎立即嵌入 + +## 结论 + +我必须尝试在此摘要中尽可能多地添加信息，而又不要太长。 这意味着我删去了一些可以真正帮助您的信息。 如果您发现这很有趣，我强烈建议您查看[完整访谈](https://scaleyourcode.com/interviews/interview/18)，因为还有更多隐藏的宝石。 + +您可以观看，阅读甚至收听。 还有一个下载 MP3 的选项，因此您可以聆听自己的工作方式。 当然，该节目也在 [iTunes](https://itunes.apple.com/tt/podcast/scale-your-code-podcast/id987253051?mt=2) 和 [Stitcher](http://www.stitcher.com/podcast/scaleyourcode?refid=stpr) 上进行。 + +Thanks for reading, and please let me know if you have any feedback!- Christophe Limpalair (@ScaleYourCode) + +您好，HS 读者们，我希望您从本集中找到有趣且有用的信息。 在很多（当之无愧的）关注焦点集中在 Netflix 和 YouTube 上的时代，Wistia 感觉就像是一颗隐藏的宝石。 + +我一直在努力改善演出，因此，我敞开双臂欢迎任何反馈。 受访者的建议和一般问题也是如此。 + +谢谢，享受！ + +很棒的帖子... +这些天，每个人都在后端使用 s3，但是为什么他们不使用弹性代码转换器？ + +您好，感谢您的阅读/观看！ + +RE：为什么我们不使用弹性代码转换器。 好吧，如果我们今天要创办一家视频托管公司，我们可能最终会使用诸如弹性代码转换器或 zencoder 之类的服务。 这是因为要获得像大规模构建的那样健壮的系统非常困难，而且这些服务非常好。 + +但是面包店（我们的转码服务）是在弹性转码器或 zencoder 出现之前建立的。 而现在，由于这些年来我们投入了大量工作并实施了自动缩放功能，因此它为我们带来了竞争优势。 也就是说，我们能够快速轻松地实施新的编码方案，并将转码与我们的应用程序体验更加紧密地集成在一起。 例如，我不提一提的服务器允许在仍上传的同时进行转码和回放，这是面包店的特色。 使用任何现有服务都很难做到这一点，但是会极大地改善用户体验。 + +再说一次，我们总是在评估我们的选项，因此，如果有必要将部分或全部转码卸载到另一个服务，我们一定会考虑的。 目前，面包店是秘密武器。 :) + +嗨，好帖子 看起来您正在 Rackspace 上运行，并且存储在 S3 上。 为什么不只在 AWS 和 S3 上运行？ 谢谢！ \ No newline at end of file diff --git a/docs/186.md b/docs/186.md index 036fae4..9de8dfc 100644 --- a/docs/186.md +++ b/docs/186.md @@ -1,181 +1,360 @@ -# Medialets 体系结构-击败艰巨的移动设备数据 +# Google 和 eBay 关于构建微服务生态系统的深刻教训 -> 原文： [http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html](http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html) - -![](img/b609dec47ec10f6f65a98e5a592cac1e.png) - -移动开发人员面临着巨大的扩展问题：对来自数百万个设备的大量连续遥测数据流进行有用的处理。 这是一个非常好的问题。 这意味着智能手机的销售终于实现了他们的命运：[在销售领域屠宰 PC](http://www.mobiledia.com/news/81680.html) 。 这也意味着移动设备不再只是简单的独立应用程序的容器，它们正成为大型后端系统的主要接口。 - -尽管开发人员现在在客户端进行移动开发，但他们面临的下一个挑战是如何对那些棘手的后端位进行编码。 目前面临同样问题的公司是 [Medialets](http://www.medialets.com/) ，这是一种移动富媒体广告平台。 他们所做的是帮助发布商制作高质量的互动广告，尽管就我们的目的而言，他们的广告内容并不那么有趣。 对于他们的系统，我确实感到非常有趣的是他们如何解决克服移动设备数据泛滥的问题。 - -每天，Medialets 都需要处理数十亿个新对象，这些对象嵌入了数百万兆个原始事件数据流中，而这些数据又是从数百万个移动设备流入的。 所有这些数据必须是：在移动设备上生成的； 通过长时间断开连接而中断的有损连接进行传输； 紧缩 提供给报告系统； 反馈到必须能够在几毫秒内响应请求的控制系统中。 - -这将成为具有移动设备的系统的常见范例。 问题是，如何实现它？ - -现在很有趣。 - -为了帮助我们更多地了解 Medialets 的工作原理，Medialets 服务器平台的工程经理 Joe Stein 很友好地向我介绍了他们在做什么。 Joe 还运行了一个出色的 Hadoop 播客和博客，名为 [All Things Hadoop](http://allthingshadoop.com/) ，请查看。 - -Joe 在这个问题上做了很多工作，并且对如何使用诸如 Hadoop，MySQL，HBase，Cassandra，Ruby，Python 和 Java 之类的工具构建有效的移动数据处理器有一些很棒的想法。 - -## 现场 - -* [http://www.medialets.com](http://www.medialets.com/) -主页。 -* [http://www.medialytics.com](http://www.medialytics.com/) -用于分析来自应用程序事件的见解仪表板。 - -## 什么是 Medialets？ - -Medialets 将富媒体广告投放到 iPhone，iPad 和 Android 等移动设备。 富媒体意味着广告可以是使用 SDK，事件生成和广告功能嵌入的复杂应用程序。 这个想法是，广告可以在平台内运行，而不是 being 脚的 adsense 型广告，它们可以完全互动，同时提供与电视相同的品牌质量，但在移动设备上除外。 应用程序可以让您做一些事情，例如摇动设备或与 Michael Strahan 玩足球比赛。 所有这些活动都会生成必须流回其服务器场以进行处理的数据。 - -除了广告外，他们还为发布商提供非常详细的基于[应用程序的分析](http://www.medialytics.com/)。 - -要查看其广告的示例[，请点击此处](http://www.medialets.com/showcase)。 - -## 统计资料 - -* 每天有 2-3 TB 的新数据（未压缩）。 -* 每天创建数百亿个分析事件。 事件表示有人摇晃，关闭，旋转等应用程序。 -* 200 多个高级应用程序在数以千万计的移动设备（iPhone，iPad 和 Android）上运行。 -* 已经处理了超过 7,000 亿个分析事件。 -* 在典型的 MapReduce 作业中，每秒可以处理超过一百万个事件 -* 通常在 [www.medialytics.com](http://www.medialytics.com/) 中可以从移动设备收到数据 -* 总共约有 100 台服务器。 -* 移动电话正在增长。 智能手机[的销售量首次超过了个人电脑](http://www.mobiledia.com/news/81680.html)的销售量，而 Medialets 的销售量却在增长。 iPhone，iPad 和 Android [设备在 2010 年第四季度增长了近](http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/) 300％。Android 继续增长市场份额，但 iOS 仍占据着高端手机库存的主导地位。 -* 有十几个人在从事工程，主要是在客户端和 Medialytics 上。 基础架构团队为 1-2 人。 - -## 基础设施 - -* 在四核 x 16GB / 1TB 上运行的 Ad Server 实例 -* 16 核心 x 12 GB（含 10TB）的事件跟踪服务器 -* 事件处理，作业执行，日志收集&聚合对每个 16 核 24GB RAM / 6TB 空间进行预处理 -* 日志收集&汇总了预处理和后处理。 Hadoop 群集节点各有 16 个核心 x 12GB RAM（含 2x2TB（JBOD））。 -* [www.medialytics.com](http://www.medialytics.com/) 各种配置都具有 16 个内核，从 12 到 96GB RAM 带有 1-2TB - -## 开源系统&生产工具 - -* 的 Linux -* 灭螺 -* 雄猫 -* 的 MySQL -* 阿帕奇 -* 乘客 -* 收益率 -* 记忆快取 -* 德语 -* Hadoop 的 -* 猪 -* 纳吉奥斯 -* 神经节 -* 走 -* 吉拉 - -## 语言能力 - -* C / C ++-广告服务器 -* Java-数据转换 -* Ruby-很多服务器端 Ruby。 Ruby 可能比 C ++更多，但更多地转向了 Python。 -* Python-许多 MapReduce 正在使用 [Python 流](http://allthingshadoop.com/2010/12/16/simple-hadoop-streaming-tutorial-using-joins-and-keys-with-python/)移入 Python。 -* 阶梯 -* 重击 - -## 建筑 - -* 该系统构建了几年，主要使用定制软件，尽管他们使用 Hadoop 来承担分析方面的繁重任务，并使用 MySQL 作为数据库。 定制软件在开始时就需要扩展，但是随着这些产品的发展，他们现在正在考虑使用更多现成的产品。 -* 该系统是实时的，因为随着数据的滴入，报表中的数据将尽可能快且尽可能真实。 -* 不是基于云的。 它们在物理硬件上运行。 他们无法在云中的多租户环境中完成所需的工作。 具有 16 个核和 TB 级磁盘空间的计算机几乎是不够的。 他们花费大量时间来构建软件，以充分利用硬件，磁盘 IO，CPU，并行处理的优势，并充分利用内存。 -* 他们所做的一切（几乎）都是异步的。 您无需连接到网络即可查看广告或让他们捕获分析。 广告可以在广告系列开始之前几周投放（预定），您也可以乘坐地铁，仍然可以看到广告。 广告期间收集的数据最终会传递到服务器端。 -* 发布者负责构建应用程序，并集成到 Medialets SDK 中。 该 SDK 特别适用于分析和广告。 当他们想要运行分析或在广告位中运行广告时，他们使用 Medialets 的工具。 -* 共有三个基本子系统：广告投放，事件处理和报告。 -* 服务器分为以下几层： - * 前向层： - * 广告投放层-专为运行广告服务器而设计。 - * 跟踪层-处理数据转储和数据加载。 - * 异步处理层： - * Hadoop 集群-在其自己的服务器集上运行。 - * Java 和 Ruby 流程-接收传入的数据，并将数据转换为 Hadoop 可用的形式，以进行不同的聚合。 -* 使事情保持精简和卑鄙，并仅根据需要提供尽可能多的冗余。 - * 硬件是根据软件的功能进行配置的。 并非所有机器都是高端或低端。 系统的不同部分具有不同的硬件需求。 - * 响应广告服务请求时，磁盘 IO 或计算量很少。 有一个 C ++服务在静态内存上进行查找。 因此，广告投放机具有大量内存和低端处理器。 - * 在有数据接收的地方，它们有许多套接字阻塞并写入磁盘，因此它们只需要很少的内存。 - * Hadoop MapReduce 层需要您提供的所有功能。 -* 事件处理流程如下所示： - * 移动设备上的应用程序会生成事件。 有应用程序事件，广告事件和自定义事件。 定制事件可以由应用程序创建为键-值对，它们将在此基础上聚合，而无需定制编码。 - * 跟踪服务器接收事件并将其写入对象的日志文件。 这些文件表示收集事件数据的时间快照，例如 7 分钟。 - * Java 服务器读取这些文件，解压缩它们并通过一系列线程池运行对象，以便将它们转换并与所有必要的元数据合并。 不同的流程将拾取不同的事件类型并对其进行处理。 - * 上一步创建一个新文件，其中该事件在与元数据合并后现在已完成。 该新文件被推送到 HDFS（Hadoop 使用的文件系统）中。 - * MapReduce 在这些 HDFS 文件上运行以对数据进行重复数据删除。 重复数据删除发生后，数据集是干净的。 - * MapReduce 作业生成数据，然后将其导入到分析 UI 可提供给客户的数据库中。 运行数十种不同类型的聚合。 通过 Medialytics 提供了标准指标，可以从广告和应用报告的角度显示应用的运行状况。 它们沿着许多不同的维度进行汇总，例如，按设备和平台进行汇总。 其中一些数据是对广告投放系统的反馈。 -* 数据复制是移动设备和异步系统上的关键设计点。 - * 手机操作系统无法保证应用程序会获得时间来生成事件。 在 OnClose 挂钩中，发布者将运行一些清除逻辑，Medialets 具有一些清除逻辑，然后将事件写入服务器，这需要花费几毫秒的时间来响应，然后本地应用程序必须更新本地数据库。 即使这是一个快速的旅程，您仍处于 15 毫秒的窗口中，在该窗口中，操作系统无法保证所有功能都将执行。 操作系统可能会终止进程或崩溃。 根据失败发生的位置，这将导致重播事件重复。 iPhone 的新后台功能使记帐变得复杂。 如果某个应用程序在后台运行了 30 秒或更短的时间，则仍被认为是同一次运行。 有很多变化。 - * 关机 3 个月的手机仍然可以输入数据。 他们必须能够知道自己是否曾经看过这些数据，如果不经常使用应用程序，这种情况很常见。 - * Hadoop 用于计算指标和聚合，但也用于重复数据删除。 在处理数据时，他们每秒查看超过一百万个事件以对数据进行重复数据删除。 他们每天都会收到 100 亿个事件。 他们必须查看每个事件并确定是否：1）他们之前看过事件； 2）他们是否要在他们正在处理的数据集中再次看到该事件。 使用 MapReduce 可以将数据分散在一堆服务器上，这意味着您直到减少所有重复数据的所有工作后才真正知道。 -* 广告 - * 某些类型的事件数据是实时流回的。 对于另一类数据，必须在创建事件之前打开和关闭事件。 例如，要知道某人一天使用一次应用的次数，必须有一个打开事件和一个相应的关闭事件。 - * 移动世界中的用户确实是独一无二的。 在 Internet 世界中，除非已登录，否则几乎无法量化用户。 电脑被很多人使用，您无法真正确定谁在使用设备。 像电话这样的物理设备通常由一个人使用，因此，基于设备的聚合实质上就是基于用户的聚合。 - * 他们可以收集不同维度的统计数据，例如转化数据。 他们可以告知某人从该操作系统的版本升级到另一版本需要多长时间。 谁是不同类型的人？ 然后，他们可以将其覆盖到他们拥有的不同类型的应用程序中。 - * 广告既可以是品牌广告也可以是直接响应广告，两者混合。 例如，当电影广告被点击而不是去网站时，它可以从设备中调出本地应用程序。 这样您就可以在应用程序中直接购买门票。 具有不同的拦截器并具有创建丰富的用户体验的能力，从而可以通过新方式将交互流货币化。 - * 启动应用程序后，应立即显示广告。 异步用于将数据推送到服务器，但可以同步投放广告。 许多应用程序在打开时都会看到赞助商徽标，并且必须立即提供。 第一个 onload 调用是获取广告的同步调用。 他们的广告投放系统可以在 200 毫秒内以 3％的差异投放广告。 -* 由于它们将数据存储在[压缩序列文件](http://blog.mgm-tp.com/2010/04/hadoop-log-management-part2/)中，因此节省了 70％-80％的存储成本。 - * HDFS 具有序列文件格式。 压缩可以基于行或块进行。 假设您有一个包含 10 个块的序列文件，并且一个块定义为将进入映射器的数据（对于 MapReduce）。 如果压缩是在块级别上，并且有 10 个块，则可以将这 10 个块并行推送到映射器，HDFS 将自动处理所有解压缩和流传输。 - * 可将来自 reducer 的数据存储在序列文件中，例如它是重复数据删除过程的结果，或者可以以未压缩的格式存储，可以将其加载到另一个数据库中。 - * 许多人不压缩数据。 要使用 Hive，必须解压缩数据，以便您可以与之交互。 这取决于您要花多少钱以及您希望在哪里发挥系统效率低下的作用。 - * 将大量数据以未压缩格式存储在磁盘上是一个弊端。 他们有选择地决定使用哪种格式，具体取决于与将数据保留在磁盘上多长时间相比，解压缩阶段是否值得承担这些开销。 -* 工作执行系统 - * 内置 Ruby，然后再提供合适的现成系统。 - * 他们建立了作业处理系统来实施工作流处理。 工作流是一组具有不同任务和步骤并针对不同事件进行操作的作业。 必须以许多不同的方式处理应用程序数据，并且结果必须进入几个不同的系统，一些进入表，有些进入其他报告系统。 所有这些都是自动化和脚本化的。 -* 聚合数据存储在 MySQL 中，供发布者和广告商查看。 它们达到了可以分片的极限。 他们正在研究 MongoDB 和 GridFs（属于 MongoDB）。 - * GridF 看起来可以很好地存储，扩展和提供其媒体文件，这使他们考虑使用 MondoDB 来存储聚合结果集。 - * 他们还在寻找 Cassandra 和 HBase 来存储其汇总结果集。 他们会考虑将相同的基础结构也用于其跟踪和事件捕获服务器，这些服务器目前完全是自定义编写的。 - * Cassandra 看起来很有吸引力，因为它可以跨多个数据中心工作。 他们将使用此功能在同一个 dacenter 中拥有多个集群，并在一个集群中进行写操作，而在另一个集群中进行读操作，因此不同的流量负载不会互相影响。 他们不想混合使用不同类型的流量，因此他们不想在同一台计算机上执行 MapReduce 作业，从 HBase 写入和从 HBase 读取。 - * HBase 是一种有吸引力的选择，因为它们已经将大量数据写入 HDFS，以至于那些文件在 HBase 中可用将令人兴奋。 他们在 fsync 方面存在可靠性方面的担忧，以确保将数据写入磁盘，但是这些担忧已在最近的发行版中得到解决。 HBase 不允许按不同用途对数据进行分区，这对 Cassandra 来说是有吸引力的，因为 Cassandra 支持在群集中具有不同种类的机架。 - * 由于他们已经在使用 HDFS，因此在处理完所有数据后将所有数据移入 Cassandra 并不吸引人，这会使他们的硬盘需求增加一倍。 - * 他们喜欢[协处理器](http://highscalability.com/blog/2010/11/1/hot-trend-move-behavior-to-data-for-a-new-interactive-applic.html)的想法，因此不必在网络上移动数据。 每个作业为 2-3 TB，因此真正实现并行化而无需移动数据非常有吸引力。 - * [TTL 删除在 Cassandra 中的](http://www.quora.com/Which-NoSQL-stores-have-good-support-for-LRU-or-TTL-semantics-in-storage)非常吸引人。 Cassandra 可以轻松处理其写负载，因此可以用来存储传入的事件。 然后，所有工作流程都可以从 Cassandra 中取出移动数据，将其与其他数据库中的元数据合并，以创建完全连接的对象，然后可以将其写入 HBase，然后可以进行 MapReduce 聚合并写入结果 到 MongoDB。 - * 另一种重复数据删除设计是将其全部写入 HBase，然后选择最后一个作为赢家。 一旦这些系统就位，他们将重新考虑一些现有流程，以了解如何利用它们。 - * 为了确定他们是否应该保留现有软件，迁移到另一个数据库还是使用 MySQL，进行了大量的原型尝试。 他们可能最终会使用 MongoDB，Cassandra 和 HBase，他们只是想为正在构建的新产品找到正确的功能组合，并弄清楚它们如何能够继续扩展而不会占用大量开发人员时间。 -* AdServer 用 C ++编写 - * 该层提供了标准的广告投放时间安排功能，因此可以将广告映射到广告位，旋转广告，定位广告等。定位可以基于平台，分辨率，地理位置和其他尺寸。 - * 有一个用于数据库数据的对象缓存，用于制定广告投放决策。 - * 99％的时间缓存足够，而他们有 1％的时间访问数据库。 - * 读取时间只有几微秒，但当必须访问数据库时，读取时间会增加到 200 微秒。 - * 还负责安排广告投放进度，以便可以在应用的整个生命周期内投放广告系列。 例如，如果某个应用每天运行一百万次，而该广告系列获得了一百万次展示，则他们不想在一天内耗尽它。 假设广告客户希望广告系列投放一个月。 广告服务器查看分析数据，然后提出费率请求，以计算应投放的步伐广告。 - * 许多决定都是预先计算的。 人将放置目标，说出应在何处显示添加项。 - * 诸如地理分布之类的决策是动态计算的。 例如，如果您要投放一组广告印象，则需要一些去加拿大，一些去美国。 -* Java 服务器 - * 将元数据与传入的数据集连接起来。以 95％的命中率从缓存中提取元数据。 例如，当他们有一个新的广告上线时，他们将访问数据库。 - * 进入数据库后，他们希望尽可能乐观，并尽可能减少线程的中断，因此在进行非常繁重的读取操作和写入次数很少时，它们使用原子变量和 CAS（比较并设置）。 此开关将性能提高了 15％-20％，因为它们不再阻止写入。 - * 他们对读取的数量进行了基准测试，发现 Mutex 花了很长时间。 信号量最终阻止了作者。 假设有 10 个线程，其中 9 个可以读取，因此没有线程会阻塞，但是第 10 个线程必须写入，它将阻塞所有线程。 与循环执行比较和设置相比，这增加了延迟，并且效果不佳。 这是有可能的，因为它们不断处理 JVM 内某些被阻止的千兆字节数据。 - * 使用[并发备注模式](http://javathink.blogspot.com/2008/09/what-is-memoizer-and-why-should-you.html)创建用于处理缓存请求的线程池。 缓存是一个池，将在需要时加载数据。 负载使用 CAS 来阻止正在发生的实际读取。 - * [SEDA](http://www.eecs.harvard.edu/~mdw/proj/seda/) 用于通过所有不同的转换处理数据。 每个线程池对一块数据执行状态转换，然后将数据转发到另一个线程池以进行下一个转换。 例如，第一步是从磁盘读取数据并将其序列化到对象阵列上。 这些操作对延迟不敏感。 -* 使用 Ruby - * 使用 Ruby 时，必须有效地实现真正的多进程功能。 - * [Rinda](http://en.wikipedia.org/wiki/Rinda_(Ruby_programming_language)) 用于在分支过程之间创建并发。 有时使用数据库进行协调。 - * 这隐藏了解释程序常见的任何内存泄漏问题或绿色线程问题。 -* 监控方式 - * 内部工具和 Nagios 的混合。 - * 与 Ganglia 跨所有不同层级对自己的日志进行大量趋势分析。 - * 他们采取了非常主动的监视方法，并花费了大量的 R & D 努力，因此他们可以在发生问题之前就知道他们有问题。 - * 趋势式饲料进入他们的监测。 如果他们的一台广告服务器在 10 毫秒内停止响应，在一秒钟内响应超过 1 或 2 个请求，则他们需要知道这一点。 - * 如果请求延迟平均要从 200 毫秒增加到 800 毫秒，那么他们想知道。 - * 它们记录了很多日志，因此通过日志进行问题调试。 - -## 得到教训 - -* ****将数据转化为产品**。** Development 知道他们拥有的数据。 该知识可用于帮助产品团队创建新产品以销售给客户。 R & D 与业务之间始终存在很大的差距。 帮助企业与 R & D 的工作保持一致。 让他们了解 Hadoop 的功能，处理数据的速度以及处理数据的速度。 新的转化归因产品就是一个很好的例子。 如果用户看到静态广告，点击它并下载该应用程序，则可能不是导致该转化的唯一原因是静态广告。 例如，如果用户在前一天（或两周前）体验了富媒体广告，则根据发布者可配置的标准，该广告将为转化分配一定的功劳。 只有强大的数据处理基础架构才能实现这种功能。 如果没有 R & D 知道这种功能甚至是可能的，那么就不可能开发出这些新型的高附加值产品并将其出售给客户。 -* **探索新工具**。 这是一个由新工具组成的复杂世界。 所有这些新技术使知道在何处放置功能具有挑战性。 一个功能可以通过很多不同的方式完成，并且根据工具（HBase，Cassandra，MongoDB）的不同而有所不同。 重复数据删除是否仍应在 MapReduce 中完成还是应使用协处理器完成？ 通过支持两个不同的数据库值得将磁盘加倍吗？ 按使用模式对数据进行分区是真的还是获胜，或者所有流量模式都可以在同一系统上工作？ 对您的选项进行原型设计，并考虑您的体系结构如何随每个新工具（单独工作或一起工作）而变化。 -* **主动监视和规划容量**。 将监视数据转变为基础架构规划。 如果您不这样做，那您将只保留消防问题。 建立主动警报和趋势数据，以便即使在成为警告之前，您也可以看到它的到来。 有时您只需要另一个服务器。 更多数据仅意味着更多服务器。 这是做生意的成本。 知道要放置在哪个服务器以使所有不同的数据流正常运行的技巧就在于此。 比较 CPU 和负载的趋势，并真正看一下整个基础架构并基于此基础制定计划，这一点很重要。 -* **从产品运营角度来看数据**。 查看新的应用程序，看看它们与以前已实现的功能有何相似之处，以弄清您如何扩展。 仅仅因为有一个新应用程序并不意味着需要添加新的广告服务器，新的数据节点和新的跟踪服务器。 这取决于。 许多不同的广告会发出少量的广告请求，但发送的数据却非常荒谬。 趋势日志可查看数据中的峰值，并查看延迟与峰值之间的关系。 这告诉您系统的不同部分在何处以及如何扩展。 +> 原文： [http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html](http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html) + +![](img/a743567657a0afdf4d56885ba6c39304.png) + +当您查看 Google，Twitter，eBay 和 Amazon 的大型系统时，它们的体系结构已演变为类似的东西：**一组多语言微服务**。 + +当您处于多语言微服务最终状态时，会是什么样？ [Randy Shoup](https://www.linkedin.com/in/randyshoup) 曾在 Google 和 eBay 的高层职位上进行过非常有趣的演讲，探讨了这个想法：[大规模服务体系结构：Google 和 eBay 的经验](http://www.infoq.com/presentations/service-arch-scale-google-ebay)。 + +我真正喜欢 Randy 的演讲的是，他如何自我意识地使您沉浸于您可能没有经验的事物的体验中：创建，使用，持久化和保护大型体系结构。 + +在演讲的*服务生态系统*部分中，Randy 问：拥有一个多语言微服务的大规模生态系统看起来像什么？ 在*大规模运营服务*部分中，他问：作为服务提供商，运营这样的服务感觉如何？ 在*建立服务*部分中，他问：当您是服务所有者时，它是什么样的？ 在 *Service Anti-Patterns* 部分中，他问：哪里会出问题？ + +一个非常强大的方法。 + +对我来说，这次演讲的重点是**，**，**激励动机，**，一致主题的想法，这些主题贯穿了整个工作。 尽管从来没有明确地提出将其作为单独的策略，但这是为什么您希望小型团队开发小型清洁服务，内部服务的收费模型如此强大，架构如何在没有架构师的情况下可以发展，清洁设计可以如何发展的背后动机。 从下至上的过程，以及没有中央委员会如何发展标准。 + +我的收获是**动机的故意调整是您如何扩展大型动态组织和大型动态代码库**。 引入适当的激励措施[会使](https://en.wikipedia.org/wiki/Nudge_(book))事情在没有显式控制的情况下发生，几乎就像在删除锁，不共享状态，与消息进行通信并并行化所有内容时，分布式系统中的更多工作一样 。 + +让我们看看现代系统是如何构建大规模系统的。 + +## 多语言微服务是终局游戏 + +* 大型系统最终演变成看起来非常相似的东西： **一组多语言微服务** 。 多种语言意味着微服务可以用多种语言编写。 + +* **eBay** 成立于 1995 年。根据您的计算方式，它们属于其体系结构的第 5 代。 + + * 最初是创始人在 1995 年劳动节周末写的一个整体式 Perl 应用程序。 + + * 然后，它移至一个整体的 C ++应用程序，最终在单个 DLL 中包含了 340 万行代码。 + + * 以前的经验促使人们转向 Java 中分布更分散的分区系统。 + + * 当今的 eBay 具有相当多的 Java，但是一组多语言的微服务。 + +* **Twitter** 的演变非常相似。 根据您的计算方式，它们取决于其体系结构的第三代。 + + * 开始于单片 Ruby on Rails 应用程序。 + + * 在前端转移到 Javascript 和 Rails 的组合，在后端转移了很多 Scala。 + + * 最终，他们已经迁移到我们今天所说的一套多语言微服务。 + +* **Amazon** 遵循类似的路径。 + + * 从单片 C ++应用程序开始。 + + * 然后用 Java 和 Scala 编写的服务。 + + * 最后得到了一组多语言微服务。 + +## 服务生态系统 + +* 拥有多语种微服务的大规模生态系统看起来如何？ + +* 在 eBay 和 Google 上，成百上千的独立服务一起工作。 + + * 现代大型系统以关系图而不是层次结构或层级集合来构成服务。 + + * 服务依赖于许多其他服务，同时又依赖于许多服务。 + + * 较旧的大型系统通常按严格的等级进行组织。 + +### 如何创建服务生态系统？ + +* 这些性能最佳的系统比智能设计更是进化的**产品。 例如，在 Google，从来没有一个集中的自上而下的系统设计。 随着时间的流逝，它以一种非常有机的方式进化和成长。** + +* 变异和自然选择。 当需要解决问题时，会创建新服务，或更经常地从现有服务或产品中提取新服务。 **服务只要被使用**就可以生存，只要它们能够提供价值，否则它们将被弃用。 + +* 这些大型系统**从下至上**发展。 **干净的设计可以是一种紧急特性，而不是自上而下的设计**的产物。 + +* 作为示例，请考虑 Google App Engine 的一些服务分层。 + + * Cloud Datastore（NoSQL 服务）基于 Megastore（地理规模结构化数据库），Megastore 基于 Bigtable（集群级结构化服务）构建，Bigtable 基于 Colossus（下一代集群文件系统）构建 ）（基于 Borg（集群管理基础架构）构建）。 + + * 分层很干净。 每个图层都会添加不属于下方图层的内容。 它不是自上而下设计的产品。 + + * 它是自下而上构建的。 Colossus，首先建立了 Google 文件系统。 几年后，Bigtable 建成了。 几年后，Megastore 建成了。 几年后，云数据库迁移到 Megastore。 + + * 如果没有自上而下的体系结构，则可以将关注点分离得如此美妙。 + +* **这是没有架构师**的体系结构。 Google 的所有人都没有 Architect 的头衔。 技术决策没有中央批准。 大多数技术决策是由各个团队根据自己的目的在本地做出的，而不是全球范围内做出的。 + +* 与 2004 年的 eBay 形成对比。有一个体系结构审查委员会，该委员会必须批准所有大型项目。 + + * 通常，只有在更改项目为时已晚时，他们才参与项目。 + + * 集中批准机构成为瓶颈。 通常，它唯一的影响是在最后一分钟说不。 + +* eBay 处理此问题的更好方法是**在审查委员会中编码聪明有经验的人的知识**，然后将**放入各个团队可以重用的**。 将这些经验编码到一个库或服务中，或者甚至是一组指南，人们可以自己使用它们，而不必在最后一刻才进入流程。 + +### 没有架构师，标准将如何发展？ + +* 没有中央控制的**可能最终以**标准化。 + + * 服务和公共基础架构之间的通信趋向于发生**标准化。** + + * 标准之所以成为标准，是因为它们比替代的更适合**。** + +* 通常标准化的通信部分： + + * **网络协议**。 Google 使用称为 [Stubby](https://www.quora.com/What-functionality-does-Google-have-around-Protocol-Buffers-that-isnt-included-in-the-current-public-release) 的专有协议。 eBay 使用 REST。 + + * **数据格式**。 Google 使用协议缓冲区。 eBay 倾向于使用 JSON。 + + * **接口模式标准**。 Google 使用协议缓冲区。 对于 JSON，有 JSON 模式。 + +* 通常标准化的常见基础设施： + + * 源代码控制。 + + * 配置管理。 + + * 集群管理器。 + + * 监视系统。 + + * 警报系统。 + + * 诊断工具。 + + * 所有这些组件都可能脱离约定。 + +* 在进化环境中，**通过**来实施标准：代码，鼓励，代码审查和代码搜索。 + + * 鼓励最佳实践的最简单方法是通过实际代码。 这与自上而下的审查或前期的设计无关，而是与某人产生的代码可以轻松完成工作有关。 + + * 鼓励是通过**团队提供一个库**来进行的。 + + * 鼓励也是通过您要依赖于支持 X 协议或 Y 协议的服务获得的。 + + * Google 以**闻名，每一行代码**都已签到至少要由另一位程序员检查过的源代码控件**。 这是交流常规做法的好方法。** + + * 除少数例外，Google 的每个工程师都可以**搜索整个代码库**。 当程序员试图弄清楚如何做某事时，这是一个巨大的附加值。 在拥有 1 万名工程师的情况下，您很可能会尝试做某人以前已经做过的事情。 这允许从一个区域开始的**最佳实践通过代码库**传播。 它还允许错误传播。 + +* 为了鼓励通用做法和标准化约定**，做正确的事情**真的很容易，而做错事情的难度会更大。 + +* 各个**服务彼此独立。** + + * Google 没有**来标准化服务内部**。 服务是外面的黑匣子。 + + * 存在约定和通用库，但是没有编程语言要求。 通常使用四种语言：C ++，Go，Java，Python。 许多不同的服务都以各种语言编写。 + + * 框架或持久性机制尚无标准化。 + +* **在成熟的服务生态系统中，我们标准化了图的弧线，而不是节点本身。** 定义一个通用形状，而不是通用实现。 + +### 创建新服务 + +* 新服务的使用已得到证实，便会创建它们。 + +* 通常针对一个特定用例构建了一项功能。 然后发现功能是通用且有用的。 + + * 组成了一个团队，并将服务分解为自己的独立单元。 + + * 仅当一项功能成功并且适合许多不同的用例时，才会发生这种情况。 + +* 这些**体系结构通过实用主义**得以发展。 没有人坐在高处，说应该增加一项服务。 + +* Google 文件系统支持搜索引擎。 分布式文件系统更普遍可用也就不足为奇了。 + +* Bigtable 最初支持搜索引擎，但用途更为广泛。 + +* Megastore 是作为 Google 应用程序的存储机制而建立的，但用途更为广泛。 + +* Google App Engine 本身由一小组工程师启动，他们认识到需要帮助来构建网站。 + +* Gmail 来自内部项目，该项目在内部非常有用，然后被其他人外部化。 + +### 淘汰旧服务 + +* 如果不再使用服务会怎样？ + +* 可以重新利用的技术被重用。 + +* 人们可以被解雇或重新部署到其他团队。 + +* Google Wave 在市场上并不成功，但是其中一些技术最终出现在 Google Apps 中。 例如，多人编辑文档的能力来自 Wave。 + +* 更常见的情况是核心服务要经过多代，而旧代则已弃用。 Google 经常发生这种情况。 变化是如此之大，以至于 Google 内部的每项服务似乎都已被弃用或尚未准备就绪。 + +## 建立服务 + +* 当您是服务所有者时，在多语言微服务的大规模系统中构建服务时会是什么样？ + +* 大型体系结构中性能良好的服务是： + + * **通用**。 它将具有一个简单的定义明确的界面。 + + * **模块化且独立的**。 我们可以称之为微服务。 + + * **不共享持久层**。 稍后再详细介绍。 + +### 服务所有者的目标是什么？ + +* **满足客户的需求** 。 以适当的质量级别提供必要的功能，同时满足协商的性能级别，同时保持稳定性和可靠性，同时不断改进服务。 + +* **以最小的成本和精力满足需求** 。 + + * 该**目标以鼓励**使用通用基础结构**的方式调整激励**。 + + * 每个团队的资源有限，因此要利用经过战斗测试的通用工具，流程，组件和服务符合他们的利益。 + + * 它还可以激发良好的操作行为。 自动构建和部署服务。 + + * 它还鼓励优化资源的有效利用。 + +### 服务所有者的职责是什么？ + +* **生成并运行**。 + + * 团队通常是一个小团队，拥有从设计到开发和部署，一直到退休的服务。 + + * 没有单独的维护或维护工程团队。 + + * 团队可以自由选择自己的技术，方法和工作环境。 + + * 团队应对自己做出的选择负责。 + +* **服务作为有界上下文**。 + + * 团队的**认知负担是有限的**。 + + * 无需了解生态系统中的所有其他服务。 + + * 团队需要深入了解其服务及其所依赖的服务。 + + * 这意味着**团队可以非常小巧和敏捷**。 一个典型的团队是 3-5 人。 （此外，美国海军陆战队 [消防队](https://en.wikipedia.org/wiki/Fireteam) 有四个人。） + + * 较小的团队规模意味着团队内部的通信具有很高的带宽和质量。 + + * 康韦定律对您有利。 通过组织小型团队，您最终将只有几个单独的组件。 + +### 服务之间是什么关系？ + +* 即使您在同一家公司，也可以将服务之间的**关系视为供应商-客户关系**。 + +* 要非常友好和合作，但在关系中要有条理。 + +* 要非常清楚所有权。 + +* 要非常清楚谁对什么负责。 在很大程度上，这与定义一个清晰的界面并进行维护有关。 + +* **激励措施是一致的，因为客户可以选择是否使用服务**。 这鼓励服务由其客户来做。 这是最终构建新服务的方式之一。 + +* 定义 SLA。 由于服务提供商向其客户承诺一定水平的服务，因此客户可以依赖该服务。 + +* **客户团队为服务**付费。 + + * **为服务收费符合经济激励**。 它激励双方在资源使用方面非常高效。 + + * 当事物为**时，我们倾向于不对其进行估价，也不倾向于对其进行优化**。 + + * 例如，一个内部客户免费使用 Google App Engine，他们使用了大量资源。 要求他们提高其资源使用效率不是一个好策略。 退款开始后一周，他们就可以通过一两个简单的更改将其 GAE 资源消耗减少 90％。 + + * 使用 GAE 的团队并不是邪恶的，他们还有其他优先事项，因此没有动力去优化 GAE 的使用。 事实证明，使用更高效的体系结构，它们实际上获得了更好的响应时间。 + + * **收费还激励服务提供商保持较高的质量**，否则内部客户可能会去其他地方。 这直接激励了良好的开发和管理实践。 代码审查就是一个例子。 Google 的大规模构建和测试系统是另一个。 Google 每天都会运行数百万次自动测试。 每次在存储库中接受代码时，都会对所有相关代码进行验收测试，这有助于所有小型团队保持其服务质量。 + + * 退款模型**鼓励进行小幅增量更改**。 较小的更改更容易理解。 同样，代码更改的影响是非线性的。 千行变更的风险比 100 行变更的风险高 10 倍，而风险高出 100 倍。 + +* **保持接口**的完全向后/向前兼容性。 + + * 请勿破坏客户端代码。 + + * 这意味着维护多个接口版本。 在某些讨厌的情况下，这意味着维护多个部署，一个部署用于新版本，其他部署用于旧版本。 + + * 通常由于增量更改较小，因此不会更改接口。 + +* 具有明确的弃用策略。 然后，强烈希望服务提供商将所有客户端从版本 N 移到版本 N + 1。 + +## 大规模运营服务 + +* 作为服务提供商，在多语言微服务的大规模系统中操作服务的感觉如何？ + +* **可预测的性能是一项要求。** + + * 大规模服务**非常容易受到性能变化**的影响。 + + * **性能的可预测性**比平均性能重要得多。 + + * 性能不一致的低延迟实际上根本不是低延迟。 + + * 当客户提供一致的性能时，对它进行编程很容易。 + + * 由于服务使用许多其他服务来执行其工作，因此尾巴延迟主导着性能。 + + * 想象一下，一个服务在中值处有 1 毫秒的延迟，而在 99.999％的位置（万分之一），延迟是一秒。 + + * 拨打一个电话意味着您的时间慢了 0.01％。 + + * 如果您使用的是 5,000 台计算机（就像 Google 的许多大型服务一样），那么您的速度就会降低 50％。 + + * 例如，memcached 的百万分之一问题被追溯到低级数据结构重新分配事件。 随着等待时间的增加，这个罕见的问题浮出水面。 事实证明，像这样的低级细节在大型系统中非常重要。 + +* 深度弹性。 + + * 服务中断更有可能是由于人为错误而不是硬件或软件故障引起的。 + + * 对机器，群集和数据中心的故障具有弹性。 + + * 调用其他服务时进行负载平衡并提供流量控制。 + + * 能够快速回滚更改。 + +* 增量部署。 + + * **使用金丝雀系统**。 不要一次部署到所有计算机。 选择一个系统，将该软件的新版本放在该系统上，然后查看其在新世界中的行为。 + + * 如果**有效，则开始分阶段推出**。 首先是 10％的机器，然后是 20％的机器，以此类推。 + + * 如果在部署中的 50％点发生问题，那么您应该能够回滚。 + + * eBay 使用**功能标志将代码部署与功能部署**分离。 通常，代码是在功能关闭的情况下部署的，然后可以将其打开或关闭。 这样可以确保在启用新功能之前可以正确部署代码。 这也意味着，如果新功能存在错误，性能问题或业务故障，则可以在不部署新代码的情况下关闭该功能。 + +* 您可能会发出太多警报，而您永远不会受到太多监视。 + +## 服务反模式 + +* **大型服务** + + * 一项服务过多。 您想要的是一个非常小的清洁服务生态系统。 + + * 做得太多的服务就是**只是另一个整体**。 难以推理，难以扩展，难以更改，并且还会创建比您想要的更多的上游和下游依赖项。 + +* **共享持久性** + + * 在分层模型中，服务放在应用程序层中，而持久层则作为通用服务提供给应用程序。 + + * 他们在 eBay 上进行了此操作，但**无效**。 它**破坏了服务的封装**。 应用程序可以通过更新数据库将**后门连接到您的服务**中。 最终导致重新引入服务耦合。 共享数据库不允许松散耦合的服务。 + + * 微服务通过小巧，隔离和独立来防止此问题，这是使生态系统保持健康和成长的方式。 ## 相关文章 -* Joe Stein 的 [AllThingsHadoop Twitter Feed](http://www.twitter.com/allthingshadoop) -* [大规模解决大数据问题](http://www.medialets.com/tackling-big-data-problems-at-scale/) -* 已发布 2010 年第四季度移动人物 [http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/](http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/) -* [Hadoop，BigData 和 Cassandra 与 Jonathan Ellis 在一起](http://allthingshadoop.com/2010/05/17/hadoop-bigdata-cassandra-a-talk-with-jonathan-ellis/)-HBase 适用于 OLAP，Cassandra 适用于 OLTP -* [Twitter 的计划分析 1000 亿条推文](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) +* 关于 [HackerNews](https://news.ycombinator.com/item?id=10657251) +* 兰迪·舒普[在 Twitter](https://twitter.com/randyshoup) 上 +* [微服务-不是免费的午餐！](http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html) +* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) +* [10 个易趣的星球扩展尺度](http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html)（2009） + +像所有其他文章一样。 这篇文章令人着迷。 +我想知道微服务具体做什么？ Gmail 和 Google Wave 听起来不够小，不能被视为可以由小型团队完成的微服务。 + +很棒的帖子！ 我希望您能详细说明不同的工程团队如何“使用服务付费”。 我完全同意，围绕激励机制组织大型团队要比自上而下的设计优越得多，而让团队付费使用其他团队服务是其中的一部分。 但是实际上，您如何实际跟踪服务的“付款”？ 你真的是说钱吗？ 还是您在指其他？ + +-克里斯 + +>定义一个通用形状，而不是通用实现。 + +找出*为什么*被认为是好的，这将更为有用。 我发现本文中的许多建议都缺乏推理。 这使得它们非常无用。 + +信息发布！ 为了回答克里斯的问题，每个拥有很少微服务的产品团队都应该有一个成本中心，可以向其他产品团队收取使用费用。 大多数企业都拥有像 SAP 这样的良好财务系统来跟踪付款。 当为更多新服务提供资金时，这种“按需付费”的模式非常有效。 我希望这回答了你的问题。 -真的很棒。 对团队尝试使用可用的批处理工具（如 MapReduce）构建自己的实时分析体系结构所面临的各种挑战的深入了解。 在 Cloudscale，我们 100％专注于提供实时分析平台，该平台不仅是世界上最快的大数据架构，而且可以在具有 10GigE 网络的商品 Amazon 云集群上运行。 现在，在大数据分析领域处于领先地位的公司可以替代 Medialets 英勇采用的“自己动手”方法，并在此具有高度可扩展性。 随着实时分析继续迅速成为主流，本文将成为爆炸性增长的 Web 公司和企业的关注焦点，这些公司正面临着同样艰巨的挑战，并正在寻找工具，技术和方法。 平台来帮助他们。 +-拉杰什 -真好！ 非常详细和有用。 +所有已知的问题/建议，但仍然是一个很好的谈话，永远不会老。 令人惊讶的是，许多公司没有遵循这些基本原则。 技术演讲的作者很容易理解，值得从事面向服务的体系结构工作的人们阅读一次。 -对于 mysql 替换，我建议您查看 Infobright（www.infobright.com）。 它是一个柱状 mysql 插件引擎，可以很好地替代 mysql（它们也具有开源版本）。 \ No newline at end of file +在 11 月 5 日举行的纽约 Kubernetes 会议上，来自 Google 的一位人士说：“ Gmail 是数百种微服务。” http://www.meetup.com/New-York-Kubernetes-Meetup/events/226173240/ \ No newline at end of file diff --git a/docs/187.md b/docs/187.md index f8e4e36..7da84cc 100644 --- a/docs/187.md +++ b/docs/187.md @@ -1,248 +1,299 @@ -# 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量 +# 无服务器启动-服务器崩溃！ -> 原文： [http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html) +> 原文： [http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html](http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html) -![](img/23e609ef6f02f2890c78b7ea6bbc2d1c.png) +[![teletext.io](img/e44ffec4ff98259588613d9ce8ae51e1.png)](https://teletext.io/ "Teletext.io - content as a service") -自从我的第一篇关于 [Stack Overflow Architecture](/blog/2009/8/5/stack-overflow-architecture.html) 的文章以来发生了很多事情。 与上一篇文章的主题相反，该主题引起了人们对 Stack Overflow 致力于扩大规模战略的关注，但在过去的几年中，Stack Overflow 不断发展壮大。 +*这是来自 [Teletext.io](https://teletext.io/ "Teletext.io") 的 [Marcel Panse](http://www.linkedin.com/in/marcelpanse "Marcel Panse") 和 [Sander Nagtegaal](http://www.linkedin.com/in/centrical "Sander Nagtegaal") 的来宾帖子。* -Stack Overflow 的规模增长了两倍以上，超过 1600 万用户，其页面浏览量几乎翻了六倍，达到每月 9500 万页面浏览量。 +在早期的 [Peecho 时代](http://www.peecho.com/ "Peecho")中，我们[写了一篇文章](http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html "Peeacho architecture - scalability on a shoestring")，解释了如何使用 [Amazon Web Services](http://aws.amazon.com/ "Amazon Web Services") 构建真正可扩展的架构。 自动缩放，无情的解耦，甚至对未使用的服务器容量进行自动出价，都是我们当时用来操纵的技巧。 现在，是时候将其进一步迈出一步了。 -堆栈溢出通过扩展到[堆栈交换网络](http://stackexchange.com/)而得以发展，该网络包括堆栈溢出，服务器故障和超级用户（总共 43 个不同站点）。 进行着很多富有成果的乘法。 +我们想介绍 [Teletext.io](https://teletext.io/ "Teletext.io - content as a service") ，也称为*无服务器启动*-再次完全基于 AWS 构建，但仅利用了 [Amazon API Gateway](https://aws.amazon.com/api-gateway/ "Amazon API Gateway") ， [Lambda](https://aws.amazon.com/lambda/ "AWS Lambda") 函数， [DynamoDb](https://aws.amazon.com/dynamodb/ "AWS DynamoDb") ， [S3](https://aws.amazon.com/s3/ "AWS S3") 和 [Cloudfront](https://aws.amazon.com/cloudfront/ "AWS Cloudfront") 来实现。 -不变的是，Stack Overflow 对他们正在做的事情持开放态度。 这就是促使进行此更新的原因。 最近的一系列帖子讨论了他们如何处理增长问题：[堆栈交换的体系结构以[项目符号]](http://blog.serverfault.com/post/stack-exchanges-architecture-in-bullet-points/) ， [Stack Overflow 的纽约数据中心](http://blog.serverfault.com/2010/10/29/1432571770/)，[为可伸缩性而设计 管理和容错](http://blog.serverfault.com/post/1097492931/)，[堆栈溢出搜索-现在](http://blog.stackoverflow.com/2011/01/stack-overflow-search-now-81-less-crappy/)，[堆栈溢出网络配置](http://blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/)，[减少 81％StackOverflow 是否使用缓存？如果使用缓存，如何使用缓存？](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how) ，[哪些工具和技术构建了堆栈交换网络？](http://meta.stackoverflow.com/questions/10369/which-tools-and-technologies-build-the-stack-exchange-network) 。 +## 约束的美德 -跨时间的一些更明显的差异是： +我们喜欢规则。 在我们之前的初创公司 [Peecho](http://www.peecho.com/ "Peecho printing") 中，产品所有者必须为每个想要添加到正在进行的 sprint 中的用户故事支付*五十次俯卧撑*。 现在，在我们目前的公司 [myTomorrows](https://mytomorrows.com/ "myTomorrows - expanding access to drugs in development") 中，我们的*开发人员舞会*颇具传奇色彩：在每日站立时，您只能在跳舞时讲*- 导致有史以来最高效的会议。* -* **更多**。 更多用户，更多页面视图，更多数据中心，更多站点，更多开发人员，更多操作系统，更多数据库，更多机器。 的数量更多。 -* **Linux** 。 堆栈溢出以其 Windows 堆栈而闻名，现在他们将更多的 Linux 机器用于 HAProxy，Redis，Bacula，Nagios，日志和路由器。 所有支持功能似乎都由 Linux 处理，这需要开发[并行发布过程](http://blog.serverfault.com/post/1097492931/)。 -* **容错**。 现在，堆栈溢出（HTG2）由两个不同 Internet 连接上的两个不同交换机提供服务，它们添加了冗余计算机，并且某些功能已移至另一个数据中心。 -* **NoSQL** 。 Redis 现在用作整个网络的[缓存层](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how)。 之前没有单独的缓存层，所以这是一个很大的变化，就像在 Linux 上使用 NoSQL 数据库一样。 - -不幸的是，我找不到关于我上次遇到的一些未解决问题的报道，例如它们将如何处理这么多不同属性的多租户，但仍然有很多值得学习的地方。 这里汇总了一些不同的来源： - -### 统计资料 - -* 每月 9500 万页面浏览量 -* 每秒 800 个 HTTP 请求 -* 180 个 DNS 请求每秒 -* 每秒 55 兆位 -* 1600 万用户-流量向堆栈溢出的流量在 2010 年增长了 131％，达到每月 1,660 万全球唯一身份用户。 +这种思维方式一直贯穿于我们的产品开发。 乍一看似乎违反直觉，但限制了创造力。 例如，我们所有的徽标设计都是通过技术制图工具 [Omnigraffle](https://www.omnigroup.com/omnigraffle "Omnigraffle") 完成的，因此我们无法使用可怕的*镜头光斑*等。 无论如何-最近，我们发起了另一个计划 [Teletext.io](https://teletext.io/ "Teletext.io") 。 因此，我们需要一个新的限制。 -### 数据中心 +*在 Teletext.io，我们不允许使用服务器。 连一个都没有。* -* 1 个带有 Peak Internet 的机架（或）（托管我们的聊天和数据资源管理器） -* 2 个在纽约拥有对等 1 的机架（托管其余的 Stack Exchange Network） +这是一个不错的选择。 我们将解释原因。 -### 硬件 +## 为什么服务器损坏 -* 10 台 Dell R610 IIS Web 服务器（其中 3 台专用于堆栈溢出）： - * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz 四核，带 8 个线程 - * 16 GB RAM - * Windows Server 2008 R2 +在过去的几年中，Amazon 云已经使我们非常满意能够使用 EC2 服务器实例的自动扩展群集，并在其顶部具有负载平衡器。 这意味着，如果您的一台服务器出现故障，则可以自动启动新服务器。 当出现意外的高峰流量时，也会发生同样的情况。 然后将启动额外的服务器。 -* 2 台 Dell R710 数据库服务器： - * 2 个 Intel Xeon 处理器 X5680 @ 3.33 GHz - * 64 GB 内存 - * 8 锭 - * SQL Server 2008 R2 - -* 2 台 Dell R610 HAProxy 服务器： - * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz - * 4 GB 内存 - * Ubuntu 服务器 - -* 2 台 Dell R610 Redis 服务器： - * 2 个 Intel Xeon 处理器 E5640 @ 2.66 GHz - * 16 GB RAM - * CentOS 的 - -* 1 台运行 Bacula 的 Dell R610 Linux 备份服务器： - * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz - * 32 GB 内存 - -* 1 台用于 Nagios 和日志的 Dell R610 Linux 管理服务器： - * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz - * 32 GB 内存 - -* 2 个 Dell R610 VMWare ESXi 域控制器： - * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz - * 16 GB RAM - -* 2 个 Linux 路由器 -* 5 个 Dell Power Connect 交换机 - -### 开发工具 - -* **C＃**：语言 -* **Visual Studio 2010 Team Suite** ： IDE -* **Microsoft ASP.NET（4.0 版）** ：框架 -* **ASP.NET MVC 3** ： Web 框架 -* **剃刀** ：视图引擎 -* **jQuery 1.4.2** ：浏览器框架： -* **LINQ to SQL，一些原始 SQL** ：数据访问层 -* **水银和窑** ：源代码管理 -* **Beyond Compare 3** ：比较工具 - -### 使用的软件和技术 - -* 堆栈溢出通过 [BizSpark](http://blog.stackoverflow.com/2009/03/stack-overflow-and-bizspark/) 使用 [WISC](http://stackoverflow.com/questions/177901/what-does-wisc-stack-mean) 堆栈 -* **Windows Server 2008 R2 x64** ：操作系统 -* **运行 **Microsoft Windows Server 2008 Enterprise Edition x64** 的 SQL Server 2008 R2** ：数据库 -* Ubuntu 服务器 -* CentOS 的 -* **IIS 7.0** ：Web 服务器 -* **HAProxy** ：用于负载均衡 -* **Redis** ：用作分布式缓存层。 -* **CruiseControl.NET** ：用于构建和自动部署 -* **Lucene.NET** ：进行搜索 -* **Bacula** ：用于备份 -* **Nagios** ：（带有 [n2rrd](http://n2rrd.diglinks.com/cgi-bin/trac.fcgi) 和 drraw 插件）用于监视 -* **Splunk：**用于日志 -* **SQL Monitor：来自 Red Gate 的**-用于 SQL Server 监视 -* **绑定**：用于 DNS -* **[Rovio](http://www.wowwee.com/en/products/tech/telepresence/rovio/rovio)** ：一个小机器人（真正的机器人），允许远程开发人员“虚拟地”访问办公室。 -* **Pingdom** ：外部监视器和警报服务。 - -### 外部钻头 - -开发工具中未包含的代码： - -* 验证码 -* DotNetOpenId -* WMD-现在已开发为开源。 见 github 网络图 -* 美化 -* 谷歌分析 -* 巡航控制.NET -* HAProxy -* 仙人掌 -* 降价锐利 -* 美丽 -* Nginx 的 -* 窑 -* CDN：无，所有静态内容均由 [sstatic.net](http://sstatic.net/) 提供，这是一个快速，无 cookie 的域，用于将静态内容传递给 Stack Exchange 系列网站。 - -### 开发人员和系统管理员 - -* 14 个开发人员 -* 2 个系统管理员 - -### 内容 - -* **许可：**知识共享署名-相同方式共享份额为 2.5 -* **标准：** OpenSearch，Atom -* **主持人：** PEAK Internet - -### 更多架构和经验教训 - -* 使用 HAProxy 而不是 Windows NLB，因为 HAProxy 便宜，简单，免费，可通过 Hyper-V 用作网络上的 512MB VM``设备''。 它也可以在盒子前面使用，因此对它们完全透明，并且更容易作为另一个网络层进行故障排除，而不必与所有 Windows 配置混在一起。 -* 不使用 CDN 是因为，即使像亚马逊这样的“便宜” CDN 相对于捆绑到现有主机计划中的带宽而言也非常昂贵。 根据 Amazon 的 CDN 费率和带宽使用情况，他们每月至少可以支付 1000 美元。 -* 备份到磁盘以进行快速检索，而备份到磁带以进行历史存档。 -* SQL Server 中的全文本搜索集成度很差，有故障，非常不称职，因此他们选择了 Lucene。 -* 人们对峰值 HTTP 请求数据最感兴趣，因为这是他们确保可以处理的需求。 -* 现在，所有属性都在相同的 Stack Exchange 平台上运行。 这意味着堆栈溢出，超级用户，服务器故障，元，WebApp 和元 Web 应用都在同一软件上运行。 -* 有单独的 StackExchange 网站，因为人们有不同的专业知识集，不应跨入不同的主题网站。 [您可以成为世界上最伟大的厨师，但这并不意味着您有资格修理服务器。](http://meta.stackoverflow.com/questions/69422/why-separate-stack-exchange-accounts) -* 他们积极地缓存一切。 -* 通过[输出缓存](http://learn.iis.net/page.aspx/154/walkthrough-iis-70-output-caching/)缓存匿名用户访问（并随后提供给匿名用户）的所有页面。 -* 每个站点都有 3 个不同的缓存：本地，站点，全局。 -* **本地缓存**：只能从 1 个服务器/站点对访问 - * 为了限制网络延迟，他们使用服务器上最近设置/读取的值的本地“ L1”缓存，基本上是 HttpRuntime.Cache。 这会将网络上的高速缓存查找开销减少到 0 字节。 - * 包含用户会话和未决视图计数更新之类的内容。 - * 它完全驻留在内存中，没有网络或数据库访问权限。 -* **网站缓存**：单个网站的任何实例（在任何服务器上）都可以访问 - * 大多数缓存的值都在这里，诸如热门问题 ID 列表和用户接受率之类的例子就是很好的例子 - * 它驻留在 Redis 中（在一个单独的数据库中，纯粹是为了简化调试） - * Redis 是如此之快，以至于缓存查找最慢的部分就是花费的时间在网络上读写字节。 - * 将值压缩后再将其发送到 Redis。 它们具有大量的 CPU，并且大多数数据是字符串，因此它们具有很高的压缩率。 - * 他们的 Redis 计算机上的 CPU 使用率为 0％。 -* **全局缓存**：在所有站点和服务器之间共享 - * 收件箱，API 使用配额和其他一些真正的全局信息都在这里 - * 它位于 Redis 中（在 DB 0 中，同样也便于调试） -* 缓存中的大多数项目会在超时时间（通常为几分钟）后过期，并且永远不会明确删除。 当需要特定的缓存失效时，他们使用 [Redis 消息](http://code.google.com/p/redis/wiki/PublishSubscribe)将删除通知发布到“ L1”缓存。 -* 乔尔·斯波斯基（Joel Spolsky）不是 Microsoft 的忠实拥护者，他没有为 Stack Overflow 做出技术决策，并且认为 Microsoft 授权存在舍入错误。 考虑自己已更正 [Hacker News 评论员](http://news.ycombinator.com/item?id=2284900)。 -* 他们为 IO 系统[选择了](http://blog.serverfault.com/post/our-storage-decision/) RAID 10 阵列，其中 [Intel X25 固态驱动器](http://www.intel.com/design/flash/nand/extreme/index.htm)。 RAID 阵列缓解了对可靠性的任何担忧，并且与 FusionIO 相比，SSD 驱动器的性能确实很好，且价格便宜得多。 -* 他们的 Microsoft 许可的[全船费用](http://news.ycombinator.com/item?id=2285931)约为$ 242K。 由于 Stack Overflow 使用的是 Bizspark，因此他们所支付的价格接近全价，但这是他们所能支付的最高价。 -* [英特尔 NIC 正在取代 Broadcom NIC](http://blog.serverfault.com/post/broadcom-die-mutha/) 及其主要生产服务器。 这解决了他们在连接丢失，数据包丢失和 arp 表损坏时遇到的问题。 +尽管这很酷，但也有缺点。 -## 相关文章 +* 首先，即使您没有任何流量或收入，您**仍需要保持最少数量的服务器实例**处于活动状态，以便能够为任何访问者提供服务。 这要花钱。 +* 其次，由于云实例在操作系统之上运行已安装的软件，因此您不仅需要维护自己的代码，还需要**确保服务器软件保持最新**并可以运行。 +* 第三，您**不能以精细的方式**向上或向下扩展，但一次只能一台完整的服务器。 -* [此帖子上的黑客新闻主题](http://news.ycombinator.com/item?id=2284900) / [Reddit 主题](http://www.reddit.com/r/programming/comments/fwpik/stackoverflow_scales_using_a_mixture_of_linux_and/) -* [项目符号中的堆栈交换体系结构](http://blog.serverfault.com/post/stack-exchanges-architecture-in-bullet-points/) / [HackerNews 线程](http://news.ycombinator.com/item?id=2207789) -* [Stack Overflow 的纽约数据中心](http://blog.serverfault.com/post/1432571770/)-各种计算机的硬件是什么？ -* [设计用于管理和容错的可伸缩性](http://blog.serverfault.com/post/1097492931/) -* [堆栈溢出博客](http://blog.stackoverflow.com/) -* [堆栈溢出搜索-现在减少了 81％的废话](http://blog.stackoverflow.com/2011/01/stack-overflow-search-now-81-less-crappy/)-Lucene 现在正在未充分利用的集群上运行。 -* [2010 年堆栈状态（您的 CEO 的来信）](http://blog.stackoverflow.com/2011/01/state-of-the-stack-2010-a-message-from-your-ceo/) -* [堆栈溢出网络配置](http://blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/) -* [StackOverflow 是否使用缓存？如果使用缓存，如何使用缓存？](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how) -* [Meta StackOverflow](http://meta.stackoverflow.com/) -* [StackOverflow 如何处理缓存失效？](http://meta.stackoverflow.com/questions/6435/how-does-stackoverflow-handle-cache-invalidation) -* [哪些工具和技术构建了堆栈交换网络？](http://meta.stackoverflow.com/questions/10369/which-tools-and-technologies-build-the-stack-exchange-network) -* [堆栈溢出如何处理垃圾邮件？](http://meta.stackoverflow.com/questions/2765/how-does-stack-overflow-handle-spam) -* [我们的存储决策](http://blog.serverfault.com/post/our-storage-decision/) -* [如何选择“热门”问题？](http://meta.stackoverflow.com/questions/4766/how-are-hot-questions-selected) -* [如何选择“相关”问题？](http://meta.stackoverflow.com/questions/20473/how-are-related-questions-selected) -标题，问题正文和标签。 -* [堆栈溢出和 DVCS](http://blog.stackoverflow.com/2010/04/stack-overflow-and-dvcs/) -堆栈溢出选择 Mercurial 进行源代码控制。 -* [服务器故障聊天室](http://chat.stackexchange.com/rooms/127/the-comms-room) -* [C＃Redis 客户端](https://github.com/ServiceStack/ServiceStack.Redis) -* [Broadcom，Die Mutha](http://blog.serverfault.com/post/broadcom-die-mutha/) +在基于带有微服务的 API 的体系结构中，这意味着小任务的开销很大。 幸运的是，现在有解决此问题的选项。 首先让我们看一下眼前的问题。 -他们是否解释了为什么使用 Redis 而不是 Memcached 进行缓存？ 我听说很多人使用 Redis 进行缓存，只是想知道 Redis 做什么，而 Memcached 不会呢？ +## 抓痒 -如果我没记错的话，Redis 不是分布式数据库，对吗？ 使用 memcached 时，如果我添加新节点，客户端将自动重新分发缓存，以利用额外的容量。 Redis 不会那样做。 那么，为什么要使用 Redis？ +我们全新的解决方案源于个人对自定义软件中*内容管理*的不满。 在大多数初创企业中，按钮，仪表板，帮助部分甚至整个网页中的 HTML 文本必须由*程序员*而不是文本编写者来管理和部署。 对于开发人员和编辑人员而言，这确实很烦人。 -> 备份到磁盘以进行快速检索，而备份到磁带以进行历史存档。 +多年来，我们试图找到一种可以正确解决此问题的分布式内容管理服务。 我们失败了。 因此，几个月前，我们受够了，并决定只需要自己构建一些东西。 -真？ 人们还在这样做吗？ 我知道一些组织在自动化的自动磁带备份上投入了大量资金，但是说真的，一个成立于 2008 年的网站正在备份磁带吗？ +## 计划 -为什么有人会在 Linux / Linux 上使用 Windows / asp？ -我真的很惊讶人们仍然在做这样的事情。 +我们计划创建一个非常简单的基于 Java 的服务，该服务可以使用 HTML 的通用数据属性标记元素来注入集中托管的内容。 它应该能够处理本地化和动态插入数据。 最重要的是，它应该为内容编写者提供一种在自己的应用程序中使用嵌入式 WYSIWYG 编辑器随时更改文本的方法。 -*为什么有人会在 Linux / Linux 上使用 Windows / asp？ -确实让我感到惊讶的是，人们仍然在做这样的事情。* +除了一些用户体验警告之外，这里还面临三个技术挑战。 -因为.NET 是目前最好的开发框架之一。 而且用于网络的 linux 便宜，因此结合起来很有意义。 +1. 由于实时网站依靠它来获取内容，因此这种新的商品服务应该永远不会失败。 曾经 +2. 它应该非常非常快，因此您的访问者甚至不会注意到内容正在加载。 +3. 内容应由 Google 编制索引。 -@约翰 +第三个问题与体系结构本身无关。 可信赖的搜索引擎以神秘的方式运转，因此我们所能做的就是[测试假设](http://www.centrical.com/test/google-json-ld-and-javascript-crawling-and-indexing-test.html "Google crawling an indexing test for javacript insertion and JSON-LD structured data")。 剧透：是的，它有效。 不过，前两个问题的解决方案掌握在您自己手中。 这些都可以通过低成本的巧妙解决方案来解决。 -使用 Redis 或 membase 之类的东西而不是 memcached 的优点之一是可以将缓存持久化到磁盘上，这样可以避免缓存脱机然后重新启动时出现缓存风暴问题。 +## 建筑模块 -我猜我们不知道 Redis 框的配置是什么 他们是分片，进行主/从复制等吗？ +让我们深入研究基于 Amazon Web Services 的一些最新功能的系统构建块。 -安迪 +### Amazon API 网关 -@Joe，如果您知道自己的想法，那么逻辑就很容易：Joel 是 MS Excel 团队的成员，该团队编写了 VBA 和 OLE 自动化。 +[Amazon API Gateway](https://aws.amazon.com/api-gateway/ "Amazon API Gateway") 是一项托管的 AWS 服务，允许开发人员在 AWS 管理控制台中单击几下即可创建任意规模的 API。 该服务可以触发其他 AWS 服务，包括 Lambda 函数。 -@Joe-这是我在该网站上看到的最不明智的评论之一。 +### AWS Lambda -詹姆斯：备份到磁带意味着脱机/档案备份。 这通常是值得的花费和麻烦，特别是对于大型重要数据集。 一两三周后，我可以告诉您，Gmail 员工非常非常高兴他们备份到磁带上。 如果您的所有副本都在线，则总是存在一个错误或手指滑动同时擦拭它们的可能性。 +而不是运行云实例，我们使用 [AWS Lambda](https://aws.amazon.com/lambda/ "AWS Lambda") 。 该名称源自希腊字母 lambda（λ），用于表示在函数中绑定变量。 AWS Lambda 使您可以在不维护任何服务器实例的情况下运行代码。 您可能会想到具有单个任务的原子无状态功能，该功能可能会运行有限的时间（当前为一分钟）。 这些功能可以用 Javascript（Node.js），Python 或 Java 编写。 -从技术上讲，IIS 7.0：Web 服务器不正确，在 Windows Server 2008R2 下，它实际上是 IIS 7.5：Web 服务器。 +如果您上传 Lambda 代码，Amazon 将负责以高可用性运行和扩展代码所需的一切。 Lambda 并行执行。 因此，如果发出一百万个请求，则将执行一百万个 Lambda 函数，而不会损失速度或容量。 据亚马逊称，“扩展功能没有基本限制”。 -@Sosh-请放轻松，不要提升自己对 Microsoft 产品的支持。 在最好和最新的开源公司及其社区中运行 MS 产品没有技术上的原因。 实际上，要真正推动这一点，StackOverflow 团队应该在各地使用更多*付费/许可*的 ms 产品来推动其发展。 还有一种观点认为，可以针对工作使用最佳工具组合，因此请参见此处。 答案很简单：StackOverflow 团队了解 MS 产品，Visual Studio，C＃和.NET，因此（对于该团队而言）交付 StackExchange 系列站点是最便宜，最快的。 ^ M +最好的是，从开发人员的角度来看，Lambda 函数在不执行时甚至不存在。 它们仅在需要时出现。 而没有上升的事物，也不会下降的事物。 -他们有明确的绩效目标吗？ 他们如何在负载下监视站点性能？ 对于在 HighScalability.com 上进行介绍的任何网站，这些问题似乎都是重要的问题。 +### DynamoDB -是的，大多数拥有重要数据的人仍然使用磁带。 另外，它们是 Windows，因为创始人是微软的老家伙！ +Lambda 函数将其数据存储在数据存储中。 因为我们的规则说不允许我们使用任何服务器，所以我们不能使用关系数据库服务（RDS）。 相反，我们使用 Amazon 的大型托管数据存储 DynamoDB。 -**[仅使用更好的应用程序，您可以避免软件许可和网络硬件成本。 伺服器：](http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/ "You can avoid software license AND network hhardware costs by just using a better app. server")** +[Amazon DynamoDB](https://aws.amazon.com/dynamodb/ "AWS DynamoDb") 是适用于所有规模的所有应用程序的 NoSQL 数据库服务。 它受到完全管理，并支持文档和键值存储模型。 Netflix，AirBnB 和 IMDb 等其他用户已经证明了该服务的可扩展性。 -每秒服务器请求 +## 建筑 ---------------------------------------------- +我们的系统分为三个部分： -G-WAN Web 服务器....... 142,000 +1. 内容管理 +2. 内容传递 +3. 我们的网站 -Lighttpd Web 服务器........ 60,000 +关注点的分离是设计使然。 内容管理 API 或我们自己的网站中的问题绝不会导致客户网站的中断。 因此，内容的交付应完全自主。 -Nginx Web 服务器............ 57,000 +### 内容管理 -Varnish 缓存服务器....... 28,000 +[![Teletext.io - editing dynamic content with Amazon Gateway API, DynamoDb and Lambda](img/56374d98b147c3272e5c359b88d7a11b.png)](https://teletext.io/help/introduction "Teletext.io - editing dynamic content with Amazon Gateway API, DynamoDb and Lambda") 内容管理部分是编辑者用来编辑 HTML 和文本的部分。 编辑者只能通过连接到 [AWS IAM](https://aws.amazon.com/documentation/iam/ "AWS Identity and Access Management") 的 [AWS Cognito 身份池](https://aws.amazon.com/cognito/ "AWS Cognito")使用他们的 Google 帐户登录，而该池仅使用 Javascript。 为了加载草稿内容，存储编辑并发布结果，将调用 Amazon API Gateway，从而触发 Lambda 函数。 Lambda 函数全部与单个 API 调用有关，并将其数据存储在 DynamoDb 中。 -SQL Server 2008 R2 Standard 或 Enterprise Edition？ +如您所见，没有服务器可能崩溃或卡住。 -“现在他们正在为 HAProxy Redis 使用更多的 Linux 计算机，” +### 内容传送 -http://redis.io/clients +如前所述，我们决定将内容的交付与编辑功能完全脱钩，因此即使灾难来袭，您的应用程序仍能正常工作。 当编辑者决定将新内容发布到他的应用程序的实时版本时，另一位 Lambda 立即将草稿内容作为平面 JSON 文件复制到 [S3](https://aws.amazon.com/s3/ "AWS S3") ，这是亚马逊用于文件的数据存储。 JSON 文件包含元数据和描述内容的 i18n 本地化 HTML 字符串。 -Windows 上运行的 C＃如何与 Linux 上的 Redis 对话？ \ No newline at end of file +[![Teletext.io - publishing static content with S3 and Cloudfront](img/5d8a48f0af1040d1d011158a2b3ba6c0.png)](https://teletext.io/help/introduction "Teletext.io - publishing static content with S3 and Cloudfront") 从此处开始，应用程序中的 Teletext.io 脚本可以通过 [Cloudfront](https://aws.amazon.com/cloudfront/ "AWS Cloudfront") CDN 访问这些文件，从而确保高可用性和高性能。 我们添加了一个巧妙的预取算法，以确保在您需要它们之前在浏览器中检索并缓存了最受欢迎的文件，因此无需实际加载内容即可配置下次点击。 + +由于发布的内容的传递不涉及服务器端逻辑，因此它确实非常快速且实用。 + +### 我们的网站 + +[![Teletext.io static single page app in S3 with proper routing for deeplinking](img/b6e69f89bac3357648c378305d5d719d.png)](https://teletext.io/ "Teletext.io static single page app in S3 with proper routing for deeplinking") 但是[我们的网站](https://teletext.io/ "Teletext.io - content management as a service")呢？ 我们选择了一个简单但有效的概念-再次没有服务器。 该网站是使用 [React 框架](https://facebook.github.io/react/ "Facebook React JS")作为单页应用程序，并使用[作为单个静态文件](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html "Static single-page website in S3")部署到 S3 的。 然后，将 Cloudfront 配置为最上方的内容交付机制，从而确保了来自世界各地许多端点的超快速内容交付。 + +同样，此方法基于平面文件传递，因此非常健壮。 + +静态应用使用 HTML5 pushState 和 React Router 进行 URL 处理。 通常，存在一个问题。 如果您访问根以外的特定 URL，则 Web 服务器必须动态呈现与前端动态呈现的相同的路由。 目前这在 S3 中是不可能的。 但是，我们找到了一个技巧，我们想在这里分享。 + +1. 在 S3 中将应用程序配置为[一个静态网站，其根指向主文件。](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html "Static single-page app in S3") +2. 不要添加任何 S3 重定向规则。 甚至不添加自定义错误页面。 +3. 创建一个指向 S3 存储桶的 Cloudfront 发行版。 +4. 在 Cloudfront 中创建一个自定义错误响应，该响应也指向主文件。 确保执行固定的 200 响应。 + +结果是，所有 URL 路径（根目录除外）均在 S3 中导致 404 响应，然后触发缓存的 Cloudfront 自定义错误响应。 最后的答复只是您的单页应用程序。 现在，在浏览器中，您可以根据当前路径处理所有路由。 + +只有一个缺点。 在任何情况下，您都无法返回实际的 404 HTTP 响应代码。 但是，作为回报，您将获得一个超便宜，超可扩展的单页面应用程序。 + +### 实用津贴 + +使用 Lambda 会对您的开发过程产生影响。 不过，支持正在改善。 例如，以前无法对 Lambda 函数进行版本控制。 这导致测试和部署的风险很大。 但是，亚马逊[最近推出了其版本控制系统](http://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html "Versioning AWS Lambda")，现在我们可以使用*可变别名*。 这意味着现在可以具有可以独立更新的同一功能的不同版本，类似于测试环境还是生产环境。 + +## 结果 + +我们的免费增值服务现已向客户开放。 我们吃自己的狗食，所以我们也用它。 在以下 GIF 中，您可以在我们自己的网站上看到正在使用的功能。 + +[![Teletext.io demo: inline content management inside custom software](img/568b471e6fc11b0d3c14c340d9701f35.png)](https://teletext.io/ "Teletext.io - content management as a service") + +但是，系统的真正可扩展性在我们的每月 AWS 账单中显示。 + +### 成本 + +成本完全取决于实际使用情况。 为简单起见，我们将忽略临时免费层，以及我们使用的许多小型服务。 + +* 使用 **Lambda** ，您**只为您消耗的**计算时间付费-当代码未运行时不收费。 还有一个永久的免费套餐。 +* **Amazon API Gateway** 没有**没有最低费用或启动费用**。 您只需为收到的 API 调用和转移的数据量付费。 +* **DynamoDb** 的费用也基于**按使用量付费**，尽管定价有些复杂。 简而言之，它基于存储，读取和写入。 +* 然后是 S3 和 Cloudfront。 基本上，您需要为存储和带宽付费。 + +我们刚刚开始-为了计算成本，我们做了一些假设。 让我们考虑一个相当大的网站作为我们的普通客户。 我们猜测这样的客户端每月使用 1000 个 API 调用（仅用于编辑），因此需要 1GB 的数据输入，并需要大约 10GB 的与流量相关的数据。 永久性存储我们估计为 500MB。 我们预计 Lambda 执行时间不会超过 2 秒。 + +对于几个不同数量的此类客户，我们的每月费用将如下所示（四舍五入，以美元为单位）。 + +| 顾客 | 网关 API | 拉姆达 | DynamoDb | S3 | 云前 | 总 | +| --- | --- | --- | --- | --- | --- | --- | +| 0 | 0 | 0 | 0 | 0.25 | 1.00 | 1.25 | +| 100 | 9.50 | 0 | 3.50 | 1.50 | 85.00 | 99.50 | +| 1000 | 93.50 | 4.00 | 3.50 | 15.00 | 850.00 | 966.00 | +| 10000 | 935.00 | 35.00 | 3.50 | 150.00 | 8050.00 | 9173.50 | +| 100000 | 9350.00 | 410.00 | 3.50 | 1500.00 | 76700.00 | 87963.50 | + +如您所见，**成本主要由 CDN** 决定，而 CDN 在大流量时变得越来越便宜。 API 和关联的 Lambdas 属性所占的比例要小得多。 因此，如果您构建的服务较少依赖 Cloudfront，则可以做得更好。 + +## 关闭服务器 + +凭借对创造力约束的热爱，我们成功启动了无需维护服务器，自动扩展，负载平衡器和操作系统的初创企业。 这不仅是一个具有几乎无限的峰值容量的真正可扩展的解决方案，而且是一个非常便宜的解决方案-尤其是在牵引力出现之前的早期。 + +所以...服务器崩溃了！ + +[在 HackerNews](https://news.ycombinator.com/item?id=10690842) 上/ [在 Reddit](https://www.reddit.com/r/programming/comments/3vwrf4/on_high_scalability_building_a_company_using_only/) 上 + +先生们， + +很棒的帖子。 我喜欢它！ + +请通过类似的方式检查我们的项目：https://github.com/MitocGroup/deep-microservices-todo-app（无服务器 Web 应用程序）和 https://github.com/MitocGroup/deep-framework（无服务器 Web 框架） 。 如果有兴趣，让我们联系（我的电子邮件地址在 Github 上：） + +最好的祝愿， +尤金一世。 + +由于您没有使用大多数/任何 Cloudfront，因此您是否考虑过改用 Cloudflare 之类的设备，无论系统中有多少客户端，您都需要支付固定费率？ 消除了 Cloudfront 扩展成本 + +耶稣哭了。 + +难以置信。 您能为新手指出一些好的教程吗？ + +可怕。 几乎可以追溯到 80 年代。 + +> 如您所见，没有服务器可能崩溃或卡住。 + +是的，Amazon 完全没有服务器在运行。 而且，您的 Cloudfront 成本是可悲的，并且您不懂工程。 F *** ing 硅谷赶时髦的人。 + +我认为您的 Dynamo 定价不正确。 我无法想象拥有 3.5 万美元/月的 10 万客户的存储和吞吐量。 + +而且，CDN 数量是如此之高，甚至不使用它可能也很有意义。 + +您可以花 7.6 万美元从一级提供商那里购买 10PB CDN 流量。 + +感谢您分享您的故事 Marcel 和 Sander，有趣的方法。 + +请调整您的文章标题，因为*非常*令人误解。 您并不是在谈论无服务器设置，而是在谈论摆脱管理自己的服务器的麻烦。 他们将其称为[平台即服务（PAAS）](https://www.wikiwand.com/en/Platform_as_a_service)。 这不是什么新鲜事物，请参阅已建立的解决方案，例如 [Heroku](https://www.heroku.com/home) 和 [Google App Engine](https://cloud.google.com/appengine/) ，仅提及其中两个。 + +顺便说一句，您还没有真正解决您的大胆挑战＃1（“这项新的商品服务永远都不会失败。 您认为他们不受故障影响吗？ （提示：他们几个月前才遇到问题...）。 通过不必自己维护服务器，当然可以减少错误：许多中断是由系统更新和/或人为错误引起的。 + +我一直在考虑采用这种架构，但我担心的一件事是安全性。 您将所有（通常）服务器端逻辑用于身份验证或数据库访问配置在哪里？ 在每个 lambda 函数内部？ 还是作为每个 lambda 函数随后调用的单独的 lambda 函数（看起来可能是多余的）？ + +我正在为我的雇主开发此模式：API 网关-> Lambda-> DynamoDB。 没有要管理的服务器。 甜。 但这是一个相当新的模式，因此某些主题的文档可能参差不齐。 许可有点麻烦。 但是我明白了：与机架，堆叠和管理我们自己的服务器相比，这看起来更便宜，更可靠（我们每年比 AWS 停机更多）。 可伸缩性问题在该模型中消失了：我可以在免费的 AWS 层上构建整个基于微服务的应用程序，而要将该基础架构扩展到具有数百万用户的全球应用程序所需的唯一事情就是：我的信用卡。 + +哇-一篇相当不错的好文章的评论中有很多无知和仇恨。 + +@Jos de Jung-标题不是*很有误导性，它已经死了。 您只是不了解这些单词的含义，也不了解它们的含义（根据您的其他评论）（提示：它比 PaaS 复杂得多）。 标题为“无服务器**启动**”-表示它们作为启动公司不拥有或租赁任何服务器。 它是 100％准确的。 他们还需要购买在 AWS 服务器上运行的计算时间，存储空间，cdn 等。* + +@the_dude-好像您今天忘记服药了... + +Marcel Panse 和 Sander Nagtegaal-感谢出色的文章和灵感。 我将在下一个项目中积极使用此模型。 祝您好运！ + +嗨，EvanZ，很高兴听到您正在考虑这一点，但您需要做一些阅读工作！ AWS 提供了两种内置机制（Cognito，IAM）以及一种可以调用自己的安全提供者的集成模式。 我当前的实现是使用 Cognito。 + +干杯， + +ws + +这荒谬地更加复杂，并且如果没有更多的话甚至容易失败。 亚马逊仍然可能失败，并且由于使用了这么多服务，因此链中任何地方的任何失败都可能导致问题。 + +小型 EC2 实例可以解决所有这些问题。 为了安全起见，请使用 2 进行故障转移。 对于此应用程序，99％的用户仅在读取数据，因此这两个小型实例将永远永久扩展。 您只需在任何基本的 webapp 框架中进行编程并像往常一样进行部署。 + +Digital Ocean 甚至会更便宜，并且有许多 CDN 都比 CloudFront 便宜。 同样，他们绝对不会推出 50TB 的数据，对于高度可压缩的文本内容来说，这是一个荒谬的带宽。 这就像是说他们将为前 100 个新闻站点提供所有文字一样。 + +另外，他们的商业模式糟透了，因为我看不出谁愿意为此付出代价。 通常，需要编辑的文本（例如 CMS 中的文章）已经具有编辑器。 网站上的文本多长时间随机更改一次？ 即使这样，开发人员仅输入新文本并部署多长时间？ + +糟糕的公司，胡扯的工程和无用的博客文章。 + +我一直在使用相同的模式通过 Angular2 在站点上进行构建。 + +我一直想创建一个个人站点来用作博客，并作为共享项目/设计的垃圾场。 除此之外，我真的不想处理后端的建设，维护和付款。 S3 作为污垢很便宜，并且可以保证 5 9s 的正常运行时间（即比我一个人可以管理的更好）。 + +因此，我创建了一个 Angular2 SPA（单页应用程序），配置了 S3 重定向，并将路径重写添加到了角度路由器。 我真的希望我能引起 Angular 开发团队的注意，以便他们可以改进路由器来处理无服务器的边缘情况，包括 html 历史记录重写。 + +使用 grunt 和 s3 插件可以轻松实现自动化。 就像 Je​​kyll 一样，Markdown 将用作所有内容的格式，不同之处在于没有编译步骤。 我创建了一个 Web 组件，可将 markdown 直接转换为 html（即不久将支持 AJAX 请求的内联缓存）。 + +它正在开发中，但可以在[ [](http://dev.evanplaice.com) 中看到开发版本 + +一旦功能完全正常，我计划写一下该过程：使用 Angular2 / ES6 构建网站； 使用 JSPM； 创建一个 ng2 Web 组件。 在此之前，如果您有兴趣，请随时在 GitHub 上查看我的句柄。 + +这是一个好主意 Giggaflop。 有人在 cloudflare 上这样做吗？ 我很好奇可能会出现什么问题以及它是否会起作用。 谢谢。 + +对于那些正在寻找可以为无服务器架构创建最佳实践的演示 Web 应用程序的人，请查看我们的 SansServer 项目（ [https://github.com/bclemenzi/sans-server](https://github.com/bclemenzi/sans-server) ）。 + +该项目利用在 Maven 安装时使用自定义 Java 注释在 AWS 中自动构建和配置的基于 Java 的 Lambda 函数。 还非常关注支持多个开发人员和环境。 + +我创建了一个新框架，以将 JAVA 应用程序部署到 AWS Lambda + API Gateway 基础架构 + +https://github.com/lambadaframework/lambadaframework + +嘿，马塞尔，感谢您对我们所有人（尤其是我）的教育，这些人在服务器方面都愚蠢，现在我知道很多，这一切都感谢您。 继续写作和分享这样的读物:) + +很棒的帖子。 只是一个问题。 您在项目中的哪里存储图像等？ + +“我们的开发人员舞会具有传奇色彩：在每日站立比赛中，您只能在跳舞时讲话，这是有史以来最高效的会议。” + +你一定是在跟我开玩笑。 + +这是有关此博客文章中涉及的主题的全面分步教程。 + +[http://serverless-stack.com](http://serverless-stack.com) + +后端教程包括有关由 Cognito 保护的 Lambda + API Gateway 的章节。 前端教程包括有关在 S3 + CloudFront + SSL + Route53 自定义域上托管的 React SPA 的章节。 本教程详细介绍了如何构建 CRUD 无服务器 API 并将其完全连接到 AWS 上的 React SPA。 API 函数在 ES6 中，并且已通过 Cognito 用户池进行了身份验证。 它还显示了如何在 S3 上托管您的应用程序以及如何使用 CloudFront 和 Route 53 将其提供服务。这是一个端对端教程，显示了实际的无服务器架构。 + +有趣的帖子。 + +我还在一个后端团队中工作，该团队使用无服务器 AWS Lambda 作为我们的 node.js 后端开发工具。 我们发现，无服务器减轻了我们管理服务器部分（操作部分）的负担。 但是，我们注意到，与使用基于 Express JS 的 node.js 服务器的时间相比，我们的开发速度正在下降。 这是因为我们无法启动在我们自己的本地开发计算机中运行的&服务，也无法在其中调试我们的服务。 无服务器 AWS Lambda 上的调试问题对我们来说很繁琐：它要求我们将代码部署到 AWS 上，调用它，然后通过查看一堆 Cloudwatch 的日志流（我们的代码有一堆 console.log 以了解其中发生了什么）。 基于这个事实，我想听听您的想法，当您无法在本地计算机上运行&无服务器调试代码时，如何提高团队开发效率？ + +干杯。 + +也许尝试从命令行测试代码？ 这是我的方法： + +＃！ / usr / bin / env 节点 + +var question_id =（process.argv.length > = 3）？ process.argv [2]：“ test2”; + +var lambda = require（“ ../ index.js”）; + +var AWS = require（'aws-sdk'）; +AWS.config.loadFromPath（“ ./ awscfg.json”）; + +var context = { +functionName：“ testFunction”， +AWS：AWS， +DB：new AWS.DynamoDB（）， +DBCLIENT：new AWS.DynamoDB.DocumentClient（）， +SES ：新的 AWS.SES（） +}; + +var Decision = {[ +questionId：question_id， +评分：“优秀”， +文本：“哇！” +} + +var request = { +方法：“ acceptProAnswer”， +参数：决策， +ID：1 +} + +lambda.handler（请求，上下文，函数（错误，响应）{ +console.log（“ handler：error：” +错误+“ response：” + JSON.stringify（response））; +}） + +精彩的文章。 对于诸如*不比...* 和*并非真正无服务器*可靠的大量评论，我强烈建议您学习这项技术。 这是我们所有人都使用的技术堆栈-只是配置更智能。 构建 H / A 解决方案并消除 SPOF 几乎是微不足道的。 我关心的是性能，但是在 Lamba 工作了几个月后，我感到非常高兴。 + +很高兴看到其他人继续使用这项技术。 它消除了新技术公司的巨大启动障碍 \ No newline at end of file diff --git a/docs/188.md b/docs/188.md index 4b92561..0b4ea46 100644 --- a/docs/188.md +++ b/docs/188.md @@ -1,60 +1,533 @@ -# Node.js 成为堆栈的一部分了吗？ SimpleGeo 说是的。 +# 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南 -> 原文： [http://highscalability.com/blog/2011/2/22/is-nodejs-becoming-a-part-of-the-stack-simplegeo-says-yes.html](http://highscalability.com/blog/2011/2/22/is-nodejs-becoming-a-part-of-the-stack-simplegeo-says-yes.html) +> 原文： [http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html](http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html) -![](img/1ff747da24156c99060dda1b8dbd71b3.png) +![](img/112a6398214f12a2ed4f02148dcfc30f.png) -这是对 [SimpleGeo](http://simplegeo.com/) 的基础架构工程师 Wade Simmons 的采访，这项服务使*易于开发人员根据[节点的使用情况轻松创建位置感知应用程序](http://nodejs.org/)*。 js 作为后端服务组件，取代了一次用 Java，Python 或 Ruby 编写的代码。 这些天，Node.js 发现它进入了很多堆栈，我很好奇为什么会这样。 我在编写多个消息传递系统时的经验是，程序员不喜欢异步模型，而像 Node.js 这样的纯异步编程模型（尤其是使用服务器端 Javascript 的异步编程模型）将脱颖而出，这真是令人惊讶。 韦德（Wade）足够慷慨地帮助他们解释在 SimpleGeo 使用 Node.js 的背后原因。 我非常感谢 Wade 抽出宝贵时间接受采访。 他做得非常出色，并为现代 Web 堆栈如何在现实生活的坩埚中发展提供了很多见识。 +您如何将系统从一个用户扩展到超过 1100 万用户？ [Joel Williams](https://www.linkedin.com/in/joel-williams-70257b7) ，亚马逊网络服务解决方案架构师，就该主题发表了精彩的演讲： [AWS re：Invent 2015 扩展到您的前 1000 万用户](https://www.youtube.com/watch?v=vg5onp8TU6Q&list=PLhr1KZpdzukdRxs_pGJm-qSy5LayL6W_Y)。 -从这里开始对韦德·西蒙斯的采访： +如果您是 AWS 的高级用户，那么本演讲不适合您，但是如果您是 AWS 的新手，云的新手或的入门者，那么这是上手的好方法 不断涌现的新功能 Amazon 不断涌现。 -从一开始，在 SimpleGeo，我们一直是事件驱动，无阻塞网络服务器的粉丝。 我们的核心 API 服务器是用 Python 编写在 Tornado Web 服务器（ [http://www.tornadoweb.org](http://www.tornadoweb.org) /）之上的。 我们也有使用 Twisted 编写的内部服务器（ [http://twistedmatrix.com/](http://twistedmatrix.com/) ）。 当您的服务器将主要是与 IO 绑定时，事件驱动框架非常有意义，并且我们的许多内部服务基本上都是围绕不同类型的索引和数据库进行包装的。 +正如您可能期望的那样，由于这是 Amazon 的一次讲话，因此 Amazon 服务始终是解决任何问题的中心。 他们的平台表现令人印象深刻且具有启发性。 通过将各个部分组合在一起，很明显，亚马逊在确定用户需求并确保他们拥有该领域的产品方面做得非常出色。 -您可能想知道为什么我们已经在其他人中开发和部署了代码之后，为什么现在要尝试基于事件的不同框架呢？ 答案是我们希望 Node.js 可以避免的其他框架存在一些缺点。 +一些有趣的外卖： -### 未设计为异步的语言将阻塞 +* 从 SQL 开始，仅在必要时移至 NoSQL。 +* 一致的主题是将组件分离出来。 这使这些组件可以独立扩展和失败。 它适用于拆分层并创建微服务。 +* 仅投资于使您的企业与众不同的任务，不要重蹈覆辙。 +* 可伸缩性和冗余不是两个独立的概念，您通常可以同时进行。 +* 没有提及费用。 这将是演讲的一个很好的补充，因为这是对 AWS 解决方案的主要批评之一。 -龙卷风的主要问题是图书馆的支持。 Tornado 提供了一个非阻塞的 HTTP 客户端，但是对其他协议的支持是有限的或不存在的。 这意味着很容易尝试使用大量可用于 Python 的库。 一旦发生这种情况，您将不可避免地开始阻止事件线程，并且到服务器的并发连接将开始彼此阻塞。 这意味着您遇到了两个世界中最糟糕的一个：单线程服务器，没有任何潜在的好处。 +## 基础知识 -### Twisted 与 Python 的配合不佳 +* AWS 在全球 12 个地区中。 -Python 的 Twisted 框架具有更好的库支持，因为已经为其实现了许多协议。 没有我们想要的那样广泛的支持，但是至少它比龙卷风要好得多。 不过，SimpleGeo 上的很多人都不是 Twisted 的粉丝，因为它与 Python 的其余部分无法很好地融合在一起。 例如，方法的命名约定为驼峰式，而不是 python 标准的“带下划线的小写”。 Twisted 的学习曲线也可能更陡峭，因为可以在网上找到更少的示例（尽管确实存在的示例非常好，并且也有一些好书）。 + * 区域是世界上亚马逊具有多个可用区的物理位置。 中有 [地区：北美； 南美洲; 欧洲; 中东; 非洲; 亚太地区。](https://aws.amazon.com/about-aws/global-infrastructure/) -### 协作多任务模型更易于调试 + * 可用区（AZ）通常是单个数据中心，尽管它们可以由多个数据中心构成。 -我们还考虑了协程库，例如 Eventlet（ [http://eventlet.net/](http://eventlet.net/)）。 在 SimpleGeo 中有很多关于协作多任务或协程是否是更好的样式的争论。 决定继续使用 Node.js 的团队喜欢协作方法，因为它使调试并发问题更容易测试。 您确切地知道您的程序将控制权交给其他任务，因此追踪与共享状态有关的问题要容易得多。 + * 每个可用区都足够独立，因此它们具有独立的电源和 Internet 连接。 -### 异步浏览器体验正在转移到服务器 + * 可用区之间的唯一连接是低延迟网络。 例如，可用区可以相隔 5 或 15 英里。 网络足够快，您的应用程序就可以像所有可用区都在同一个数据中心中一样工作。 -我认为 Node.js 受到青睐的主要原因之一是人们已经习惯了 JavaScript 的异步编程风格。 即使是主要从事后端工作的程序员也可能会不时地涉足客户端 JavaScript。 JavaScript 并不是完美的语言，但是它的功能却比大多数更好，并且有许多文献记载的方法可以避免它的陷阱。 离开浏览器世界后，不必再担心向后兼容性，美好的事物就会开始闪耀。 + * 每个区域至少有两个可用区。 共有 32 个可用区。 -### 主要用作服务之间的胶水 + * 使用可用区可以为您的应用程序创建高可用性架构。 -当前，Node.js 的主要用途是作为 API 的入口点。 我们有许多不同的内部服务器，我们不同的 API 端点需要为每个请求命中一个或多个。 Node.js 服务器进行身份验证，发出并行内部请求，然后将结果合并为请求的输出格式。 该服务器还负责记录统计信息并记录详细的请求信息以供以后解析。 + * 2016 年将至少有 9 个可用区和 4 个地区。 -### 易于调试，测试和良好表现 +* AWS 在全球拥有 53 个边缘位置。 -到目前为止，我们的经验是编写 Node.js 代码非常直观并且易于测试。 生产部署非常稳定，我们还没有出现内存泄漏问题或使用如此年轻的平台（敲敲敲打）会遇到的其他问题。 我们计划在内部将 Node.js 用于我们框架的其他一些“胶合”样式； 主要充当后端和客户端之间的路由器/转换器的组件。 这些是已经或将要用 Tornado / Twisted 用 Pyt​​hon 编写的组件。 Python 在我们的堆栈中仍然有很多用途，但是随着我们对它的适应程度不断提高，Node.js 开始渗透。 + * 边缘位置由 Amazon 的内容分发网络（CDN）CloudFront 和 Amazon 的托管 DNS 服务器 Route53 使用。 -### Node.js 没有计划实现 CPU 密集型服务 + * 边缘位置使用户无论身在何处都可以以极低的延迟访问内容。 -我们没有计划在 Node.js 中做任何占用大量 CPU 的工作。 我们正在 Cassandra 之上使用 Java 进行数据库层的开发，我们暂时可能会坚持使用它。 我们正在那里而不是在远程网络服务器上实施空间逻辑，因此我们可以在数据旁边进行尽可能多的处理。 我不相信对 v8 中的内存模型有足够的控制权（某些数据结构实际上可能是肿的），无法完成诸如 Node.js 中的数据库这样的密集型操作。 +* 构建基块服务 -### 代码由 SimpleGeo 提供 + * AWS 创建了许多服务，这些服务在内部使用多个可用区来实现高可用性和容错能力。 [是其中](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) [提供哪些服务的列表](http://docs.aws.amazon.com/general/latest/gr/rande.html) ，其中 可用。 -尽管 Node.js 还很年轻，但社区发展非常迅速，在 github 和 npm（Node 包管理器）上可以找到大量的库。 SimpleGeo 喜欢开源，因此当我们发现缺少或缺少的图书馆时，请确保释放所有改进，以便其他人可以使用它们。 + * 您可以付费在应用程序中使用这些服务，而不必担心使它们自己高度可用。 -从我们的工作中创建的一些库示例： + * 可用区内存在的一些服务：CloudFront，Route 53，S3，DynamoDB，弹性负载平衡，EFS，Lambda，SQS，SNS，SES，SWF。 -* [https://github.com/wadey/node-thrift](https://github.com/wadey/node-thrift) -* [https://github.com/wadey/node-microtime](https://github.com/wadey/node-microtime) -* [https://github.com/wadey/decimaljson](https://github.com/wadey/decimaljson) + * 即使服务位于单个 AZ 中，也可以使用服务创建高可用的体系结构。 -在 [https://github.com/simplegeo](https://github.com/simplegeo) 上可以找到更多内容。 +## 1 个用户 -## 相关文章 +* 在这种情况下，您是唯一的用户，并且您要运行一个网站。 -* Quora： [SimpleGeo 的 API 平台使用哪种语言编码？](http://www.quora.com/What-language-is-SimpleGeos-API-platform-coded-in/answer/Joe-Stump) -* [HackerNews 线程](http://hackerne.ws/item?id=2251490) +* 您的架构将类似于： -“找到 ITS 方式”。 没有撇号。 \ No newline at end of file + * 在单个实例上运行，可能是 [t2.micro](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html) 类型。 实例类型包括 CPU，内存，存储和网络容量的各种组合，使您可以灵活地为应用程序选择适当的资源组合。 + + * 一个实例将运行整个 [Web 堆栈]( http://whatis.techtarget.com/definition/Web-stack) ，例如：Web 应用程序，数据库，管理等。 + + * 将 Amazon [路由 53](https://aws.amazon.com/route53/) 用作 DNS。 + + * 将单个 [弹性 IP](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) 地址附加到实例。 + + * 运作良好，持续了一段时间。 + +## 垂直缩放 + +* 您需要一个更大的盒子。 最简单的扩展方法是选择更大的实例类型。 例如，也许 [c4.8xlarge](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/c4-instances.html) 或 [m3.2xlarge](https://aws.amazon.com/ec2/instance-types/) 。 + +* 这种方法称为 [垂直缩放](https://en.wikipedia.org/wiki/Scalability) 。 + +* 只需停止实例并选择一种新的实例类型，您就可以以更高的功率运行。 + +* 有多种不同的硬件配置可供选择。 您可以拥有一个带有 244 GB RAM 的系统（即将推出 2TB RAM 类型）。 或一个 40 核。 有高 I / O 实例，高 CPU 实例，高存储实例。 + +* 某些 Amazon 服务随附 [预置 IOPS](http://serverfault.com/questions/580568/amazon-how-do-i-know-if-i-need-provisioned-iops) 选项，以确保性能。 这个想法是，您也许可以为服务使用较小的实例类型，并利用 DynamoDB 之类的 Amazon 服务来提供可扩展的服务，因此您不必这样做。 + +* 垂直扩展存在一个大问题：没有故障转移，也没有冗余。 如果实例出现问题，则您的网站将死亡。 你所有的鸡蛋都放在一个篮子里。 + +* 最终，单个实例只能变得如此之大。 您需要做其他事情。 + +## 用户> 10 + +* 将单个 主机分离为多个主机 + + * 该网站的主机。 + + * 数据库的一台主机。 运行所需的任何数据库，但是您需要进行数据库管理。 + + * 使用单独的主机可以使网站和数据库彼此独立地扩展。 例如，也许您的数据库将需要比网站更大的计算机。 + +* 或者，也可以使用数据库服务代替运行自己的数据库。 + + * 您是数据库管理员吗？ 您真的要担心备份吗？ 高可用性？ 补丁？ 操作系统？ + + * 使用服务的一大优势在于，您只需单击即可设置多个可用区数据库。 您无需担心复制或任何此类事情。 您的数据库将高度可用且可靠。 + +* 您可能会想像到亚马逊有几项完全托​​管的数据库服务可以卖给您： + + * [Amazon RDS](https://aws.amazon.com/rds/) （关系数据库服务）。 有很多选项：Microsoft SQL Server，Oracle，MySQL，PostgreSQL，MariaDB，Amazon Aurora。 + + * [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 。 NoSQL 管理的数据库。 + + * [Amazon Redshift](https://aws.amazon.com/redshift/) 。 PB 级数据仓库系统。 + +* 更多 [Amazon Aurora](https://aws.amazon.com/rds/aurora/) ： + + * 自动存储扩展到 64TB。 您不再需要为数据配置存储。 + + * 最多 15 个读只读副本 + + * 连续（增量）备份到 S3。 + + * 跨 3 个 AZ 进行 6 向复制。 这可以帮助您处理故障。 + + * MySQL 兼容。 + +* 从 SQL 数据库而不是 NoSQL 数据库开始。 + + * 建议从 SQL 数据库开始。 + + * 该技术已建立。 + + * 有很多现有的代码，社区，支持小组，书籍和工具。 + + * 您不会破坏前 1000 万用户的 SQL 数据库。 差远了。 （除非您的数据很大）。 + + * 清晰的模式可扩展。 + +* 您何时需要从 NoSQL 数据库开始？ + + * 如果您需要在第一年存储 5 TB 的>数据，或者您的数据处理工作量非常大。 + + * 您的应用程序具有超低延迟要求。 + + * 您需要非常高的吞吐量。 您需要真正调整在读取和写入中都得到的 IO。 + + * 您没有任何关系数据。 + +## 用户> 100 + +* 将 单独的主机用于 Web 层 。 + +* 将 数据库存储在 Amazon RDS 上。 它照顾一切。 + +* 这就是您要做的。 + +## 用户> 1000 + +* 按照架构，您的应用程序存在可用性问题。 如果您的 Web 服务主机出现故障，则您的网站将关闭。 + +* 因此，您 在另一个可用区 中需要另一个 Web 实例。 可以，因为 AZ 之间的等待时间只有几位毫秒，几乎就像它们彼此相邻一样。 + +* 您还需要一个 从属数据库到在另一个 AZ 中运行的 RDS 。 如果主服务器有问题，您的应用程序将自动切换到从属服务器。 故障转移无需对应用程序进行任何更改，因为您的应用程序始终使用相同的端点。 + +* 弹性负载均衡器（ELB）已添加到配置中，以在两个可用区中的两个 Web 主机实例之间负载均衡用户。 + +* 弹性负载平衡器（ELB）： + + * ELB 是高度可用的托管负载均衡器。 ELB 存在于所有可用区中。 它是您的应用程序的单个 DNS 终结点。 只需将其放在 Route 53 中，它将在您的 Web 主机实例之间实现负载平衡。 + + * ELB 具有运行状况检查，以确保流量不会流向发生故障的主机。 + + * 无需任何操作即可缩放。 如果看到额外的流量，它将在水平和垂直方向上扩展到幕后。 您不必管理它。 随着应用程序规模的扩展，ELB 也随之扩展。 + +## 用户> 10,000s-100,000s + +* 先前的配置在 ELB 后面有 2 个实例，实际上，您可以在 ELB 后面有 1000 个实例。 这是 [水平缩放](https://en.wikipedia.org/wiki/Scalability) 。 + +* 您需要向数据库和 RDS 添加更多只读副本。 这将减轻写主机的负担。 + +* 通过将 通过将一些流量转移到其他地方来减轻 Web 层 服务器的负载，从而考虑性能和效率。 将 Web 应用程序中的静态内容移动到 Amazon S3 和 Amazon CloudFront。 CloudFront 是 Amazon 的 CDN，可将您的数据存储在全球 53 个边缘位置。 + +* Amazon S3 是对象库。 + + * 它与 EBS 不同，它不是连接到 EC2 实例的存储，而是对象存储，而不是块存储。 + + * 这是存储静态内容（如 javascript，css，图像，视频）的好地方。 此类内容无需位于 EC2 实例上。 + + * 高度耐用，可靠性 11 9。 + + * 无限扩展，可根据需要抛出尽可能多的数据。 客户在 S3 中存储多个 PB 的数据。 + + * 支持最大 5TB 的对象。 + + * 支持加密。 您可以使用 Amazon 的加密，您的加密或加密服务。 + +* Amazon CloudFront 缓存了您的内容。 + + * 它在边缘位置缓存内容，以为用户提供尽可能低的延迟访问。 + + * 如果没有 CDN，您的用户将遇到对您的内容的更高延迟访问。 您的服务器在提供内容以及处理 Web 请求时也将承受更高的负载。 + + * 一位客户需要以 60 Gbps 的速度提供内容。 网络层甚至都不知道这是怎么回事，CloudFront 处理了所有事情。 + +* 您还可以通过将会话状态移出 Web 层来减轻负载。 + + * 将会话状态存储在 [ElastiCache](https://aws.amazon.com/elasticache/) 或 DynamoDB 中。 + + * 这种方法还可以设置系统以支持将来的自动缩放。 + +* 您还可以通过将数据从数据库缓存到 ElastiCache 中来减轻负载。 + + * 您的数据库不需要处理所有数据获取。 缓存可以处理很多工作，而数据库则可以处理更重要的流量。 + +* Amazon DynamoDB-托管的 NoSQL 数据库 + + * 您可以配置所需的吞吐量。 您可以提高要支付的读写性能。 + + * 支持快速，可预测的性能。 + + * 完全分布式且具有容错能力。 它存在于多个可用区中。 + + * 这是一个键值存储。 支持 JSON。 + + * 支持最大 400KB 的文档。 + +* Amazon Elasticache-托管的 Memcached 或 Redis + + * 管理内存缓存集群并不能为您带来更多收益，因此让 Amazon 为您做到这一点。 那就是球场。 + + * 将自动为您缩放群集。 这是一种自我修复的基础架构，如果节点发生故障，则会自动启动新节点。 + +* 您还可以通过将动态内容转移到 CloudFront 来减轻负载。 + + * 许多人都知道 CloudFront 可以处理静态内容（例如文件），但也可以处理一些动态内容。 谈话中没有进一步讨论该主题，但这里的 [链接](https://aws.amazon.com/cloudfront/dynamic-content/) 。 + +## [自动缩放](https://aws.amazon.com/autoscaling/) + +* 如果您提供足够的容量来始终处理高峰流量，例如黑色星期五，那是在浪费钱。 将计算能力与需求匹配起来会更好。 这就是 Auto Scaling 的工作，即自动调整计算群集的大小。 + +* 您可以定义池的最小和最大大小。 作为用户，您可以确定集群中最少的实例数和最多的实例数。 + +* [CloudWatch](https://aws.amazon.com/cloudwatch/) 是一项管理服务，已嵌入到所有应用程序中。 + + * CloudWatch 事件驱动扩展。 + + * 您要扩展 CPU 使用率吗？ 您要扩展延迟吗？ 在网络流量上？ + + * 您也可以将自己的自定义指标推送到 CloudWatch。 如果要按特定的应用程序扩展，可以将该指标推送到 CloudWatch，然后告诉 Auto Scaling 您要按该指标扩展。 + +## 用户> 500,000+ + +* 从先前配置中添加的是 [自动缩放组](http://docs.aws.amazon.com/gettingstarted/latest/wah/getting-started-create-as.html) 已添加到 Web 层 。 自动缩放组包括两个 AZ，但可以扩展到 3 个 AZ，最多可以位于同一区域。 实例可以在多个可用区中弹出，不仅是为了实现可伸缩性，还在于可用性。 + +* 该示例在每个可用区中都有 3 个 Web 层实例，但可能是数千个实例。 您可以说您要最少 10 个实例，最多 1000 个实例。 + +* ElastiCache 用于卸载数据库中的流行读取。 + +* DynamoDB 用于卸载会话数据。 + +* 您需要添加监视，指标和日志记录。 + + * 主机级别指标。 查看自动扩展组中的单个 CPU 实例，找出问题所在。 + + * 聚合级别指标。 查看 Elastic Load Balancer 上的指标，以了解整个实例集的性能。 + + * 日志分析。 查看应用程序使用 [CloudWatch](https://aws.amazon.com/about-aws/whats-new/2014/07/10/introducing-amazon-cloudwatch-logs/) 日志告诉您什么。 [CloudTrail](https://aws.amazon.com/cloudtrail/) 可帮助您分析和管理日志。 + + * 外部站点性能。 了解您的客户看到的最终用户。 使用新遗物或 Pingdom 之类的服务。 + +* 您需要知道客户在说什么。 他们的延迟不好吗？ 他们转到您的网页时会收到错误消息吗？ + +* 尽可能从配置中压缩性能。 Auto Scaling 可以提供帮助。 您不希望 CPU 使用率达到 20％的系统。 + +## 自动化 + +* 基础架构越来越大，可以扩展到数千个实例。 我们已经阅读过副本，可以水平缩放，但是我们需要一些自动化来帮助管理所有内容，我们不想管理每个实例。 + +* 自动化工具具有层次结构。 + + * 自己做 ：Amazon EC2，AWS CloudFormation。 + + * 更高级别的服务 ：AWS Elastic Beanstalk，AWS OpsWorks + +* [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) ：自动管理应用程序的基础架构。 这很方便，但没有太多控制权。 + +* [AWS OpsWorks](https://aws.amazon.com/opsworks/) ：一个在其中分层构建应用程序的环境，您可以使用 Chef 食谱来管理应用程序的层。 + + * 还使您能够进行持续集成和部署。 + +* [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ：使用时间最长。 + + * 提供了最大的灵活性，因为它提供了堆栈的模板化视图。 它可以用于构建整个堆栈或仅堆栈的组件。 + + * 如果要更新堆栈，请更新 Cloud Formation 模板，它将仅更新应用程序的这一部分。 + + * 有很多控制权，但不太方便。 + +* [AWS CodeDeploy](https://aws.amazon.com/codedeploy/) ：将代码部署到一组 EC2 实例。 + + * 可以部署到一个或数千个实例。 + + * 代码部署可以指向自动扩展配置，因此代码可以部署到一组实例。 + + * 也可以与 Chef 和 Puppet 结合使用。 + +## 解耦基础架构 + +* 使用 [SOA](https://en.wikipedia.org/wiki/Service-oriented_architecture) / [微服务](http://techblog.netflix.com/2015/02/a-microscope-on-microservices.html) 。 从您的层中取出组件并将它们分开。 创建单独的服务 ，就像将 Web 层与数据库层分开一样。 + +* 然后可以独立扩展各个服务。 这为扩展和高可用性提供了很大的灵活性。 + +* SOA 是 Amazon 构建的架构的关键组成部分。 + +* 松耦合使您自由。 + + * 您可以分别缩放组件和使组件失败。 + + * 如果工作程序节点无法从 SQS 提取工作，这有关系吗？ 不，只是开始另一个。 事情将会失败，让我们建立一个处理失败的架构。 + + * 将所有内容设计为黑匣子。 + + * 解耦交互。 + + * 支持具有内置冗余和可伸缩性的服务，而不是自己构建。 + +## 不要重新发明轮子 + +* 仅投资于使您的业务与众不同的任务。 + +* 亚马逊拥有许多固有的容错服务，因为它们跨越多个可用区。 例如：排队，电子邮件，代码转换，搜索，数据库，监视，指标，日志记录，计算。 您不必自己构建这些。 + +* [SQS](https://aws.amazon.com/sqs/) ：排队服务。 + + * 提供的第一个 Amazon 服务。 + + * 它跨越多个可用区，因此具有容错能力。 + + * 它具有可扩展性，安全性和简单性。 + + * 排队可以通过帮助您在基础结构的不同组件之间传递消息来帮助您的基础结构。 + + * 以 Photo CMS 为例。 收集照片并对其进行处理的系统应该是两个不同的系统。 他们应该能够独立扩展。 它们应该松耦合。 摄取照片并将其放入队列中，工作人员可以将照片从队列中拉出并对其进行处理。 + +* [AWS Lambda](https://aws.amazon.com/lambda/) ：您可以在不配置或管理服务器的情况下运行代码。 + + * 出色的工具，可让您解耦应用程序。 + + * 在 Photo CMS 示例中，Lambda 可以响应 S3 事件，因此，当添加 S3 文件时，将自动触发要处理的 Lambda 函数。 + + * 我们已经取消了 EC2。 它可以为您进行扩展，并且无需管理任何操作系统。 + +## 用户> 1,000,000+ + +* 要达到一百万个以上的用户，则需要满足以上所有条件： + + * 多可用区 + + * 层之间的弹性负载平衡。 不仅在 Web 层上，而且在应用程序层，数据层和您拥有的任何其他层上。 + + * 自动缩放 + + * 面向服务的体系结构 + + * 使用 S3 和 CloudFront 巧妙地服务内容 + + * 将缓存放在数据库前面 + + * 将状态移出 Web 层。 + +* 使用 [Amazon SES](https://aws.amazon.com/ses/) 发送电子邮件。 + +* 使用 CloudWatch 进行监视。 + +## 用户> 10,000,000+ + +* 随着规模的扩大，我们会遇到数据层的问题。 与 [写入主机](https://en.wikipedia.org/wiki/Multi-master_replication) 争用时，您的数据库可能会遇到问题。 。 + +* 您如何解决？ + + * 联盟 + + * 分片 + + * 将某些功能移至其他类型的数据库（NoSQL，图形等） + +* 联合身份验证-基于功能分为多个 DB + + * 例如，创建一个论坛数据库，一个用户数据库，一个产品数据库。 您以前可能将它们放在单个数据库中，现在将它们分发出去。 + + * 不同的数据库可以彼此独立地扩展。 + + * 缺点：您无法进行跨数据库查询； 这会延迟进入下一个分片策略。 + +* 分片-在多个主机之间拆分一个数据集 + + * 在应用层更加复杂，但是对可伸缩性没有实际限制。 + + * 例如，在用户数据库中，用户的⅓可能会发送到一个分片，最后三分之一发送到另一个分片，另一个分片发送到另外三分之一。 + +* 将某些功能移至其他类型的数据库 + + * 开始考虑 NoSQL 数据库。 + + * 如果您的数据不需要排行榜，例如排行榜，快速获取点击流/日志数据，临时数据，热点表，元数据/查找表，则可以考虑将其移至 NoSQL 数据库。 + + * 这意味着它们可以彼此独立缩放。 + +## 用户> 1100 万 + +* 缩放是一个迭代过程。 随着您变得更大，总会有更多您可以做。 + +* 微调您的应用程序。 + +* 更多 SOA 的功能/特性。 + +* 从多可用区转到多区域。 + +* 开始构建自定义解决方案，以解决您以前从未有人做过的特定问题。 如果您需要为十亿客户提供服务，则可能需要定制解决方案。 + +* 深入分析整个堆栈。 + +## 审核中 + +* 使用多可用区基础结构来提高可靠性。 + +* 利用自扩展服务，例如 ELB，S3，SQS，SNS，DynamoDB 等。 + +* 在每个级别构建冗余。 可伸缩性和冗余不是两个独立的概念，您通常可以同时进行。 + +* 从传统的关系 SQL 数据库开始。 + +* 在基础结构内部和外部缓存数据。 + +* 在基础架构中使用自动化工具。 + +* 确保您具有良好的指标/监视/日志记录。 确保您正在查找客户对应用程序的体验。 + +* 将层划分为单独的服务（SOA），以便它们可以彼此独立地扩展和失败。 + +* 准备使用自动缩放功能。 + +* 除非绝对必要，否则不要重新发明轮子，而是使用托管服务而不是自己编写代码。 + +* 如果可行，请转移到 NoSQL。 + +## 延伸阅读 + +* [在 HackerNews](https://news.ycombinator.com/item?id=10885727) 上/ [在 Reddit](https://www.reddit.com/r/sysadmin/comments/40hon7/a_beginners_guide_to_scaling_to_11_million_users/) 上 + +* [http://aws.amazon.com/documentation](http://aws.amazon.com/documentation/) + +* [http://aws.amazon.com/architecture](http://aws.amazon.com/architecture/) + +* [http://aws.amazon.com/start-ups](http://aws.amazon.com/start-ups) + +* [http://aws.amazon.com/free](http://aws.amazon.com/free) + +* 从 2007 年开始： [Amazon Architecture](http://highscalability.com/blog/2007/9/18/amazon-architecture.html) + +不错的文章。 请更正用于启动的链接。 （对 http：//aws.amazon.comstart-ups 的开放应该是 http://aws.amazon.com/start-ups/） + +即使对于可伸缩性专业人员来说，这也是一篇出色的，易于上手的文章。 做得好 + +此设置每月将耗费疯狂的$。 AWS 是一种将 VC 美元间接注入亚马逊银行账户的好方法。 + +如果人们实际上对 TCO / ROI 持认真态度，那么人们就必须停止对价格过高的 VM 的炒作，而回到裸机解决方案。 + +这是非常依赖于应用程序的，但是对于每个级别的用户，可以期望每秒钟的事务/请求范围是多少？ + +@帕特里克 + +是的，但是没有。 + +正是在这个主题上，我们进行了荒谬的成本分析。 实际上，在我们系统运营的每个领域中，AWS 都能为我们节省大量资金。 某些 AWS 服务的成本仅为内部成本的 1/3。 + +每当您看到整个世界都朝着某种趋势发展时，尤其是当该“世界”主要由聪明人和百万富翁（他们真的很喜欢保留/赚钱）组成时，您应该假设其可能不仅仅是“炒作”或 “时尚”。 + +五年前的数字有所不同，但是自那时以来，AWS 已将价格降低了一半或更多。 除非您的计算器坏了，否则我将很难得出任何其他结论。 + +我的经验主要是在 AWS ..上，但是 Google 的云的价格相当，并且我认为其他 IaS 和 PaS 提供商的价格差异可以忽略不计。 + +所以，我的建议是：仔细看..然后跳上马车或开始计划退休 + +AWS CloudFormation 的问题一直是大型 JSON 脚本的笨拙-没有一致的添加注释的方式，笨拙的模块化故事以及没有向后引用。 + +通过使用 yaml 编写模板，然后使用 [YAML Stratus](https://github.com/kikinteractive/yaml-stratus) 转换为所需的 JSON，我们一直在解决此问题。 Yaml 支持注释，向后引用，并且 yaml stratus 添加 yaml 扩展以包括其他具有覆盖的 yaml 脚本以及编译时参数化。 + +@卢克·查弗斯 + +是的，但是你错了。 + +AWS 总是比裸机中的裸机贵，大约是 10 到 100 倍。 部署这样的复杂设置（更糟糕的是，大多数应用程序永远都不需要）时，情况更糟。 + +Modern 的速度非常快，基本的中型服务器每天可以支持数百万个请求，而将高可用性加倍则很便宜。 即使在云中，除非您确实需要，最好还是坚持使用基本 VM 而不是所有托管服务。 + +从您的评论来看，好像是您的计算器坏了，或者您只是在为 AWS 工作。 + +我有点不同意 RDS 观点。 如果您甚至具有基本的 db-administraton 技能，请不要使用 RDS。AmazonsRDS 对数据库使用 EBS 驱动器的速度非常非常慢。一种更好的方法是将实例存储 SSD 驱动器用于您不需要的临时存储物 需要持久化（tempdb，事务日志（如果您知道自己在做什么以及如何在没有日志的情况下还原数据库）等）。 + +除了我的这个小小的评论-很棒的帖子，谢谢 + +你好 + +我已经将 RDS 用于我的应用程序之一，该应用程序处理数百万个实时社交媒体数据。 通过所有优化，我们可以在中等亚马逊实例中使用 mysql mysql 来处理 1 或 2 周的数据。 随着数据量的增长，RDS 是我们关系数据库设计的帮助。 + +事实是，与普通解决方案相比，这是非常昂贵的，但是当您必须处理潜在的大量数据时，则值得花费。 + +哈哈@ colo。 当然，如果您喜欢停机和昂贵的带宽费用，请选择合适的颜色！ + +嘿@Alex：这个[1]说 Amazon RDS 是否支持 SSD？ + +[1] http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html + +真正使我担心的是在 AWS 上进行扩展，这就是为什么喜欢 Cloudways 的原因，因为他们可以按比例缩放服务器规模。 + +非常不错的文章，但我会缓和一个事实，那就是我们应该从 SQL DB 开始，然后将可能的方式切换到 No-SQL。 从 SQL 转换为 No-SQL 可能会非常痛苦（模型转换，业务代码重写，数据迁移等），而且风险很大，您永远也不会做。 + +因此，我建议您采取以下措施：如果您怀疑您的应用程序将支持超过 10 万个用户（并且您的业务肯定是与 No-SQL 兼容的），请直接使用 No-SQL 数据库。 您将能够轻松进行分片，使用 No-SQL 进行开发并不昂贵，并且您的应用程序可以自然扩展，而无需重新定义体系结构。 + +让·马克 + +关于裸机颜色的问题是，您需要考虑所有“成本”。 大多数决定采用裸机的人都严重低估了所需的时间和精力，其中最少的是硬件（但是，假设您使用的是专业质量的服务器硬件，而不是垃圾邮件，那么硬件仍然比您想象的要昂贵得多）。 您当地的回收场）。 特别是，您将需要一个实施团队来进行初始部署，然后*至少*由一名工作人员负责，只负责服务器的维护和维护以及最重要的虚拟化基础架构，每年的费用为 15 万美元以上 仅针对一个人-假设您可以和一个人一起停下来。 然后是数据中心不同区域的机架之间的光纤互连成本（数据中心通常具有电源和网络区域-机架位于不同的 UPS 和路由器上，但​​是如果您想在两个前哨站之间实现 10 GB 的快速互连， 您必须为此支付$$）。 当然，硬件本身的成本-用于互连数据库服务器和计算服务器的 10 吉比特交换机，所需的 10 吉比特卡，以及专业质量好的服务器和企业级 SSD 的价格并不便宜。 我已经为自己的业务工作了一个交叉点，这种交叉点在内部而不是通过亚马逊来进行比较便宜，尽管该交叉点的用户数远远少于 1000 万，但肯定比我们现在花费的更多 在 AWS 服务上。 + +关于 NoSQL，最好将其用于大量非结构化数据，例如日志数据（例如 ElasticSearch），但是现代 SQL 数据库的 ACID 保证在许多方面都非常重要。 与将 SQL 数据库简单地优化和扩展到所需的位置相比，尝试将它们横向入侵 NoSQL 数据库通常会花费更多的时间。 Twitter 使用 MySQL 处理 1.5 亿活跃用户。 已为您的时间表授予 Redis 缓存和一些自定义复制代码，但仍然：MySQL。 + +这是一个很棒的帖子！ 我认为在某些时候提高网站效率可能比服务器规模更有效。 例如，有人说通过使用微缓存和 nginx，他们每天可以在微型 VPS 服务器上处理数百万的网页浏览。 + +但是话又说回来，我从来没有承受过太大的服务器负载，所以我知道什么。 + +非常有用的信息，请不断更新我们，..... + +谢谢。 我是这个领域的初学者。 由于 AWS 昂贵，因此我使用 Linode VPS 进行托管。 这将非常有助于我在上下文中使用。 但是，如果您有关于该/其他廉价服务的经验，请与我们分享，因为 Linode 没有 AWS 提供的一些自动化服务。 + +人们没有解决一些问题，亚马逊可能会更昂贵，但是每当怀疑/涉及欺诈时，他们的确会听取买卖双方的意见，而 ebay 不会这样做。 + +超级清晰，写得很好。 谢谢 \ No newline at end of file diff --git a/docs/189.md b/docs/189.md index 026d0d4..f24df5b 100644 --- a/docs/189.md +++ b/docs/189.md @@ -1,61 +1,97 @@ -# Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求 - -> 原文： [http://highscalability.com/blog/2011/2/15/wordnik-10-million-api-requests-a-day-on-mongodb-and-scala.html](http://highscalability.com/blog/2011/2/15/wordnik-10-million-api-requests-a-day-on-mongodb-and-scala.html) - -![](img/c71648a7f74b646cf7cc4c270f00b751.png) - -[Wordnik](http://www.wordnik.com/) is an online dictionary and language resource that has both a website and an API component. Their goal is to *show you as much information as possible, as fast as we can find it, for every word in English, and to give you a place where you can make your own opinions about words known.* As cool as that is, what is really cool is the information they share in their [blog](http://blog.wordnik.com/) about their experiences building a web service. They've written an excellent series of articles and presentations you may find useful: - -* [最近使用](http://blog.wordnik.com/what-has-technology-done-for-words-lately) ne 的技术是什么？ - * **最终一致性**。 使用最终一致的模型，他们可以并行工作，*我们会尽可能地统计尽可能多的单词，并在出现滞后时将它们加起来。 计数总是在球场上，我们永远不必停止* .D - * **面向文档的存储**。 字典条目更自然地建模为分层文档，使用该模型可以更快地找到数据，并且更易于开发。 -* [与 MongoDB 合作 12 个月](http://blog.wordnik.com/12-months-with-mongodb) - * 迁移到 MongoDB 的主要驱动因素是性能。 MySQL 不适用于他们。 - * Mongo 平均每小时处理 50 万个请求。 高峰流量是该流量的 4 倍。 - * > Mongo 中有 120 亿个文档，每个节点的存储量约为 3TB - * 可以轻松维持 8k 文档/秒的插入速度，经常达到 50k /秒 - * 一个 Java 客户端可以维持通过后端（千兆位）网络读取到一个 mongod 的 10MB / sec 的速度。 来自同一客户端的四个读取器通过同一管道以每秒 40MB 的速度传输 - * 每种类型的检索都比 MySQL 实现快得多： - * 示例提取时间从 400ms 减少到 60ms - * 字典条目从 20ms 到 1ms - * 文档元数据从 30 毫秒到.1 毫秒 - * 拼写建议从 10 毫秒到 1.2 毫秒 - * Mongo 的内置缓存使他们可以删除 memcached 层并将呼叫速度提高 1-2ms。 -* [从 MySQL 到 MongoDB-迁移到实时应用程序](http://www.slideshare.net/fehguy/migrating-from-mysql-to-mongodb-at-wordnik)作者：Tony Tam - * 他们从 MySQL 迁移到 MongoDB 的经历的解释。 - * Wordnik 存储单词，层次结构数据和用户数据的语料库。 MySQL 设计要复杂得多，并且需要复杂的缓存层才能良好地运行。 使用 MongoDB，系统速度提高了 20 倍。 现在不再需要连接，也不需要缓存层。 整个系统更加简单。 - * Wordnik 主要是一个只读系统，并且性能主要受磁盘速度限制。 - * 他们使用具有 72GB 内存的双四核 2.4GHz 英特尔 CPU。 它们是物理服务器，处于主从模式，并且在 DAS 上使用 5.3TB LUN。 他们发现虚拟服务器没有所需的 IO 性能。 -* [通过 MongoDB 保持亮灯](http://www.slideshare.net/fehguy/mongo-sv-tony-tam)作者：Tony Tam - * 关于他们如何使用和管理 MongoDB 的演示。 -* [Wordnik API](http://blog.wordnik.com/wordnik-api-has-gone-beta) - * 他们已经在 Scala 中重写了 REST API。 Scala 帮助他们删除了很多代码，并在整个 API 中标准化了“特征”。 -* [](http://blog.wordnik.com/wordnik-api-has-gone-beta)[MongoDB 管理工具](http://blog.wordnik.com/mongoutils) - * Wordnik 已经构建了一些工具来管理 MongoDB 的大型部署并已开源。 -* [Wordnik 克服了 Hadoop 的处理瓶颈](http://www.cloudera.com/blog/2011/02/wordnik-bypasses-processing-bottleneck-with-hadoop/) - * 每秒增加 8000 个单词。 - * Map-reduce 作业在 Hadoop 上运行，以减轻 MongoDB 的负担并防止任何阻塞查询。 数据仅是追加数据，因此没有理由使用 MongoDB。 - * 其数据的增量更新存储在平面文件中，该文件定期导入 HDFS。 - -Overall impressions: - -* Wordnik 有一个非常具体的问题要解决，并着手寻找可以帮助他们解决该问题的最佳工具。 他们愿意围绕发现的所有错误进行编码，并弄清楚如何使 MongoDB 最适合他们。 性能要求推动了一切。 -* 在获得性能之后，文档数据模型的自然性似乎是他们最大的胜利。 轻松地对复杂数据进行分层建模并使其表现良好的能力在整个系统中得到了体现。 -* 现在的代码是：更快，更灵活且更小。 -* 他们选择了专门的工具来完成这项工作。 MongoDB 负责运行时数据的文档存储。 Hadoop 负责分析，数据处理，报告和基于时间的聚合。 - -Definitely an experience report worth keeping an eye on. - -据我所知，Wordnik 是一个只读的应用程序，不需要太多的一致性。 如文章中所述，“他们有一个特定的问题”。 NoSQL 迷们，请不要简单地使用它来攻击 MySQL。 :-) - -高峰使用率为 2M req / hr。 - -只需 550 req / sec。 真的不是那么多。 我已经看到 MySQL 的吞吐量要比那高得多。 - -如果他们甚至不能使 MySQL 仅执行 550 req / sec，我敢打赌他们只是设计不好的数据库 - -@John，我们在 mysql 上遇到的问题是大量读取和写入的结合。 结合 550 req / sec + 8k 插入/ sec，方程式将发生巨大变化。 - -我已经说过很多次了，很可能有人已经调整了我们的 mysql 部署来支持这一点。 我们使用 mongodb 轻松地自己完成了此操作，并且在此过程中获得了许多巨大的好处，如博客文章所述。 - -它不是读 500k / s 而不是 500 / s 吗？ \ No newline at end of file +# 为 David Guetta 建立无限可扩展的在线录制活动 + +> 原文： [http://highscalability.com/blog/2016/1/20/building-an-infinitely-scaleable-online-recording-campaign-f.html](http://highscalability.com/blog/2016/1/20/building-an-infinitely-scaleable-online-recording-campaign-f.html) + +![](img/8d29dd52af7470d0176746037a51e171.png) + +*这是 [Ryan S. Brown](https://twitter.com/ryan_sb)* 最初发布在 [serverlesscode.com](https://serverlesscode.com/post/david-guetta-online-recording-with-lambda/) 上的一次采访*的来宾帖子。 它继续了我们对 Lambda 顶部建筑系统的探索。* + +分页 [David Guetta](https://en.wikipedia.org/wiki/David_Guetta) 粉丝：本周，我们采访了在其最新广告系列背后建立网站的团队。 在网站上，歌迷可以录制自己演唱的单曲“ This One’s For You”，并制作专辑封面。 + +后台**该站点建立在 Lambda，API Gateway 和 CloudFront** 上。 社交广告系列通常会变得很尖刻–当大量媒体报道时，如果您还没有准备好，大量的用户涌入便可以使基础架构开始爬行。 [parall.ax](https://parall.ax/) 的团队之所以选择 Lambda，是因为它没有使用寿命长的服务器，而且他们可以根据亚马逊的需求来分担上下扩展应用程序的所有工作。 + +来自 [parall.ax](https://parall.ax/) 的 James Hall 将会告诉我们他们如何构建一个国际化的应用程序，该应用程序可以在短短六周之内满足任何水平的需求。 + +# 面试 + +## 什么是 [parall.ax](https://parall.ax) ？ 告诉我您的公司（规模，专长等） + +Parallax 是一家数字代理商。 我们提供一系列服务，包括应用程序开发，安全性和设计服务。 我们有 25 名全职员工以及一些外部承包商。 我们专注于提供可大规模扩展的解决方案，尤其专注于体育，广告和快速消费品（FMCG）。 + +## 告诉我一些有关该应用程序的信息，它可以解决什么问题？ + +该应用程序是 David Guetta 的新发行版“ T [他的一生为您](https://www.youtube.com/watch?v=MAQIb2lYFV0)”（这是 2016 年 UEFA EURO 决赛的官方主题曲）的大规模营销活动的一部分。 我们正在邀请粉丝-希望到三月时达到一百万-进入虚拟录音室，并为他们提供与 Guetta 一起唱歌的机会。 不仅他们的声音会出现在最后一首歌中，我们还将用他们的名字和最喜欢的团队创作个性化的专辑插图。 可以在朋友之间共享，从而增加参与度，并允许更多粉丝加入广告系列。 整个网站以十二种语言构建，融合了 DJ 自己的视频内容以及赢得巴黎之旅的机会。 您可以在 [thisonesforyou.com](https://thisonesforyou.com/) 上进行检查。 + +## 除了 Lambda 之外，该应用程序还使用哪些其他技术？ 这包括前端，移动数据库以及任何您可以共享的数据库。 + +![](img/cd0ba5372b9f01f9969fa55640d53dbe.png) *图片来源：Parallax Agency Ltd.* + +在后端，我们使用各种技术来提供完全可伸缩的体系结构。 我们使用[无服务器](http://serverless.com)（以前称为 JAWS）和 CloudFormation 在代码中协调整个平台。 + +请求通过 CloudFront 路由，静态资产缓存在距离请求它们的用户最近的 Edge 位置。 页面首次加载时，所有内容都是完全静态的。 在客户端浏览器中会生成一个 UUID-该 UUID 用于将来的所有 API 请求，并允许我们将页面中的不同操作关联在一起，而不必提供 Cookie。 此值的随机性很重要，因此该库使用计时和加密函数（如果可用）来导出随机种子数据。 + +![](img/b38e059c0a37d515a1464569900bc753.png) *图片来源：Amazon Web Services* + +静态资产的来源是一个简单的 S3 存储桶。 这些通过部署脚本上载。 + +然后，语言检测端点发送回 Accept-Language 标头以及接收请求的国家代码。 这是使用基本的 Lambda 函数。 另一个端点将订户数据添加到 DynamoDB，以及通过 Amazon SES 向他们发送欢迎电子邮件。 为了使录制工作正常进行，我们有一个端点，该端点为以提供的 UUID 命名的路径发行 S3 令牌。 然后，将上传的内容从浏览器直接发布到 S3。 + +Lambda 最有用的应用是图像生成端点。 我们拍摄用户最喜欢的球队标志的图像，覆盖 Guetta 的照片，然后添加他们的名字。 然后将其与 Facebook 和 Twitter 大小的图形一起上传到 S3。 我们还上传了一个静态 HTML 文件，该文件指向此唯一的图形。 这样可以确保当人们共享 URL 时将显示其自定义插图。 为此，我们在页面中使用 Open Graph 图像标签。 + +在前端，我们使用 Brunch 来编译车把模板，编译 SASS，为 CSS 加上前缀以及任何其他构建任务。 + +记录接口本身具有三种实现。 WebRTC 录音机是“ A 级”体验，它使用新的 HTML5 功能直接从麦克风录音。 然后，我们会有一个 Flash 回退来获得相同的体验，这适用于不支持 WebRTC 的桌面浏览器。 最后，我们有一个文件输入，提示用户在手机上进行录制。 + +## 您是否考虑过其他解决方案？ 如果是，还有哪些其他选择？ 如何决定使用 Lambda？ + +是的，一点没错。 我们的常规堆栈是 LAMP，构建在 CloudFront，Elastic Load Balancer 和 EC2 节点之上。 这本来可以扩展，但要像使用基于 Lambda 的体系结构一样快速和简单地扩展，则要困难得多。 我们必须构建一个用于生成图像的排队系统，然后启动专用于根据吞吐量制作这些图像的 EC2 节点。 + +编写简单的 Lambda 函数并让 Amazon 进行所有艰苦的工作似乎是显而易见的选择。 + +## 团队有多大？ 是否有/已经有过 Lambda 的经验，或者他们来自其他专业领域？ + +Parallax 的团队由五人组成。 Tom Faller 是客户经理，负责项目的日常运行。 我是后端开发人员，创建 Lambda 函数并设计云架构。 阿米特·辛格（Amit Singh）主要是前端，但是从事接口和后端 JS 之间的许多粘合部分的工作。 克里斯·米尔斯（Chris Mills）是质量保证和系统部门的负责人，并首先链接到无服务器（以前的 JAWS）项目。 杰米·塞夫顿（Jamie Sefton）是另一位 JS 开发人员，致力于将兼容性后备功能集成到代码库中，包括基于 Flash 和基于输入的录制体验，作为不支持 WebRTC 的设备的后备功能。 我以前有过 Lambda 的经验，但这对其他团队成员来说是新的。 + +## 您花了多长时间开发应用程序？ 它比在其他框架中编写要快吗？ （Express，Rails，无论您的“家庭草皮”是什么） + +我总共要花大约 6 到 7 周的时间，尽管事先进行了大量的研究和原型设计才能得出正确的架构设计。 对于所需的可伸缩性，要使用我们的“家用草皮”确保它具有同等的健壮性，将花费更长的时间。 + +## 您如何部署应用程序？ 您是否正在使用 CI / CD 服务？ + +该应用程序是从 Atlassian Bamboo 部署的。 该代码库位于 Stash 中。 每个分支机构都有自己的部署 URL，一旦构建，该 URL 就会发布到我们公司的聊天室中。 这使我们可以快速测试并确定更改是否可合并。 + +![](img/5177e2e28bb1cbbec46a27665baaf30d.png) *图片来源：Parallax Agency Ltd.* + +## 您有什么监控？ 您有什么要监视但不需要/无法监视的东西吗？ + +对于前端 JS 错误，我们使用 Bugsnag。 对于这种类型的应用程序，这是查看堆栈中是否存在问题的最简单方法。 如果错误峰值大于流量峰值，您就会知道有些问题。 我们通常将 NewRelic 用于后端，但是由于所有后端代码都存在于 Lambda 函数中，因此我们选择使用 CloudWatch。 + +## 在变更投入生产之前，您如何进行测试？ 您有测试/暂存环境吗？ + +是的，绝对是。 推送到 Stash 的每个提交和分支都部署到测试环境。 对于静态资产和前端 JavaScript，它使用 Bamboo，并为每个分支和内部版本号创建一个新文件夹。 对于 lambda 函数，已使用`serverless dash`将其更新到每个环境。 + +## 一路上有什么让您感到惊讶的吗？ 某些任务比您预期的要难还是难？ + +运行 Lambda 的服务器上缺少日文和中文字符的字体，这是可以预料的，但是这并不是我们在开发中计划的。 当操作系统呈现特定字体并且不包含特定字形时，它将回退到系统安装的多语言 Unicode 字体。 这会自动在网络上发生，但是在裸机上的 ImageMagick 内部不会发生。 这意味着我们必须在端点中附带大型 Unicode 字体。 通过仅将非拉丁名称路由到 Unicode 端点，我们减少了此功能对性能的影响。 + +例如， ![](img/249dd8900f5f6134ce3c1e95b92ef84f.png) Helvetica 不包含任何亚洲字形 ![](img/3f89d75ac2597987a5e6caa97f2d2c46.png) + +## 您发现开发过程中有痛点吗？您想如何解决它们？ + +多个分支机构和早期的无服务器（以前的 JAWS）框架存在一些问题。 假设我们要在一个分支中添加一个端点，而在另一个分支中添加另一个端点，则不能将它们都部署到同一环境阶段。 这是我们正在努力解决的问题，我们将寻求为 Serverless 提供一些有用的工具来解决此问题。 + +## 您是否想找到让更多人了解的特别有用的工具或库？ + +我强烈建议您使用几种测试工具。 相机和麦克风在仿真器中的行为有很大不同-有时甚至根本没有仿真！ 这意味着我们必须使用真实的设备进行测试。 我们使用了 [Vanamco 设备实验室](https://www.vanamco.com/devicelab/)以及五个我们认为是很好的传播设备。 我们将其与 Ghostlab 一起使用，这使我们能够在所有设备上打开同一页面，并使它们保持同步。 它包括一个 Web 检查器，用于调整 CSS 并运行调试 JS。 然后，为了增加 Android 覆盖率，我们使用了 [testdroid](http://testdroid.com/) 。 这是一项出色的服务，可让您远程使用真实设备。 打开相机应用程序，您可以在数据中心内看到。 我一直在热切地等待着一个测试机器人工程师，将他的头戳进架子，但是到目前为止，我感到失望！ + +![](img/0fd1ee681f8dc2526e711343f7f73c05.png) * Testdroid 使用 Google Nexus 10* + +# 包起来 + +再次感谢 James Hall 提供有关所有 Lambda 后端的 CI，移动测试和 Unicode 解决方法的内部视图。 要了解有关无服务器应用程序框架的更多信息，请查看其[网站](http://serverless.com)或 [gitter.im 聊天室](https://gitter.im/serverless/serverless)。 + +**披露：**我与 Parallax Agency Ltd.没有关系，但是他们建立了很酷的项目，而这次采访只涉及其中一个。 + +订阅[无服务器代码邮件列表](https://serverlesscode.com/mail/)，以跟上以后的帖子。 如果您有任何建议，问题或意见，请通过 [[受电子邮件保护]](/cdn-cgi/l/email-protection#7b171a16191f1a3b09021a15081955181416) 给我发送电子邮件。 + +[关于 HackerNews](https://news.ycombinator.com/item?id=10955158) \ No newline at end of file diff --git a/docs/19.md b/docs/19.md index 25002a5..4a77648 100644 --- a/docs/19.md +++ b/docs/19.md @@ -1,242 +1,177 @@ -# Facebook 如何向 80 万同时观看者直播 +# Tailrank 架构-了解如何在整个徽标范围内跟踪模因 -> 原文： [http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) +> 原文： [http://highscalability.com/blog/2007/11/19/tailrank-architecture-learn-how-to-track-memes-across-the-en.html](http://highscalability.com/blog/2007/11/19/tailrank-architecture-learn-how-to-track-memes-across-the-en.html) -![](img/98c9699f964c1091947cf4dcdf2cd262.png) +是否曾经觉得 Blogsphere 拥有 5 亿个频道却没有任何信息？ Tailrank 通过每小时索引超过 2400 万个 Web 日志和源来查找互联网上最热门的频道。 这是每月 52TB 的原始博客内容（不浪费），并且需要连续处理 160Mbit 的 IO。 他们是如何做到的？ -与拥有 [以及](https://www.sipri.org/media/press-release/2014/nuclear-forces-reduced-while-modernizations-continue-says-sipri) 核武器的国家相比，很少有公司知道如何建立全球性的分布式服务。 Facebook 是其中一家公司， [Facebook Live](https://www.facebook.com/livemap/) ，Facebook 的 [新](https://live.fb.com/about/) 实时视频 流产品，就是这些服务之一。 +这是 Tailrank.com 创始人兼首席执行官 Kevin Burton 的电子邮件采访。 凯文（Kevin）好心地花时间解释了他们如何扩展索引整个博客圈。 -Facebook CEO [马克·扎克伯格](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)： +## 网站 -> 我们做出的重大决定是将我们的许多视频工作重点转移到 Live 上，因为这是一种新兴的新格式； 而不是过去五到十年一直在线的那种视频……我们正在进入视频的新黄金时代。 如果您快进五年，人们在 Facebook 上看到并每天分享的大部分内容都是视频，那我不会感到惊讶。 +* [Tailrank](http://tailrank.com/) -我们跟踪博客圈中最热门的新闻！* [Spinn3r](http://spinn3r.com/) -您可以用自己的行为来专门研究博客蜘蛛，而不用创建自己的行为。* [凯文·伯顿（Kevin Burton）的博客](http://feedblog.org)-他的博客结合了政治和技术话题。 两者总是很有趣。 -如果您从事的是广告业务，那么比提供永无止境，始终在扩展且可以自由生成的广告就绪内容更好的是什么？ 当 Google [开始在呈指数级增长的网络上投放广告时，就利用了](http://www.wsj.com/articles/SB108319881076696889) 的经济学。 + ## 平台 -Facebook 的流媒体表演的一个例子是两个人在 45 分钟的视频中 [用橡皮筋爆炸西瓜](https://www.buzzfeed.com/brendanklinkenberg/this-exploding-watermelon-was-facebook-lives-biggest-hit-to) 。 它达到了超过 80 万同时观看者的顶峰，这些评论者还收集了 30 万以上的评论。 这就是您可以通过拥有 15 亿用户的社交网络产生的病毒规模。 + * 的 MySQL* 爪哇* Linux（Debian）* 阿帕奇* 乌贼* PowerDNS* 存储。* 联合数据库。* ServerBeach 托管。* 用于工作分配的工作计划系统。 -作为比较 [1.14 亿](http://www.statista.com/statistics/216526/super-bowl-us-tv-viewership/) 观看了 2015 年超级碗的观众，平均 [观看者有 236 万 实时流中的](http://money.cnn.com/2015/10/26/media/nfl-yahoo-live-stream-results/) 。 Twitch 的 [840,000](http://www.geekwire.com/2015/amazons-twitch-attracts-monster-audience-at-e3-with-21m-viewers-tuning-in-online/) 观众人数在 2015 年 E3 达到顶峰。9 月 16 日的共和党辩论在 [921,000 达到顶峰 ]](http://www.politicususa.com/2015/10/14/debate-watched-democratic-debate.html) 同时直播。 + ## 面试 -因此，Facebook 处于最新状态。 请记住，Facebook 也会同时有大量其他流。 + * **您的系统是干什么的？** -有线文章 [引用了](http://www.wired.com/2016/04/facebook-really-really-wants-broadcast-watch-live-video/) Facebook 首席产品官 Chris Cox，他说 Facebook： + Tailrank 最初是一个 memetracker，用于跟踪博客圈中正在讨论的最热门新闻。 -* 拥有**个以上的一百人**进行直播。 （[从[12]开始](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)，现在该项目有 150 多名工程师） + 我们开始收到大量要求许可我们的爬虫的请求，大约 8 个月前，我们以 Spinn3r 的形式发货了。 -* 需要能够提供**数百万个同时流**而不会崩溃。 + Spinn3r 是自包含的搜寻器，适用于希望索引完整徽标和消费者生成的媒体的公司。 -* 需要能够在流上支持**数百万同时观看者，以及全球不同设备和服务提供商之间的无缝流。** + 与 Spinn3r 相比，Tailrank 仍然是一个非常重要的产品，我们正在开发 Tailrank 3.0，该产品应在将来推出。 目前没有 ETA，但正在积极研究中。 -Cox 说：“事实证明这是一个非常困难的基础架构问题。” + * **您的系统面临哪些特定的设计/架构/实施挑战？** -如果我们有一些有关如何解决该基础结构问题的详细信息，这会很有趣吗？ 祸是我们。 但是等等，我们做到了！ + 我们面临的最大挑战是，我们必须处理和保持分布式系统中的数据一致的庞大数据量。 -[Federico Larumbe](https://www.linkedin.com/in/federicolarumbe) 来自 Facebook 的流量小组，该小组致力于为 Facebook 的 CDN 和全球负载平衡系统提供支持的缓存软件，并发表了精彩的演讲： [扩展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) ，他在其中分享了有关 Live 工作方式的一些详细信息。 + 例如，我们每月处理 52TB 的内容。 必须在高度可用的存储体系结构中对其进行索引，以便出现正常的分布式数据库问题。 -这是我在演讲中的发言。 令人印象深刻 + * **您是如何应对这些挑战的？** -## 起源故事 + 我们花了很多时间来构建可以扩展和处理故障的分布式系统。 -* Facebook 是一项新功能，允许人们实时共享视频。 （请注意，这对于 Facebook 来说只是另一个功能）。 + 例如，我们构建了一个名为 Task / Queue 的工具，该工具类似于 Google 的 MapReduce。 它具有集中式队列服务器，可将工作单元交给发出请求的机器人。 -* 于 2015 年 4 月推出，只有名人才能通过 [提及应用程序](https://www.facebook.com/about/mentions/) 用作与粉丝互动的媒介。 + 它对于爬虫非常有效，因为速度较慢的机器以较低的速度获取工作，而更现代的机器（或性能更好的机器）要求以较高的速度工作。 -* 这是产品改进和协议迭代开始的一年。 + 这样可以轻松解决网络异构的​​主要分布式计算谬论之一。 - * 他们以 HTTP 实时流媒体 [HLS](https://en.wikipedia.org/wiki/HTTP_Live_Streaming) 开头。 它受 iPhone 支持，并允许他们使用现有的 CDN 架构。 + 任务/队列足够通用，我们可以实际使用它在系统顶部实现 MapReduce。 - * 同时开始研究 [RTMP](https://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol) （实时消息协议） ，这是一种基于 TCP 的协议。 从电话发送到实时流服务器的是视频流和音频流。 + 我们可能会在某个时候将其开源。 现在它有太多触角缠绕在我们系统的其他部分中。 - * 优点：RTMP 在广播者和观看者之间具有较低的终端等待时间。 在人们相互交流的交互式广播中，这确实有所作为。 然后，降低等待时间并减少几秒钟的延迟，将使体验完全不同。 + * **您的系统多大？** - * 劣势：由于它不是基于 HTTP 的，因此需要一个完整的体系结构。 需要开发新的 RTMP 代理以使其扩展。 + 我们每小时索引 2400 万个 Weblog 和提要，并以大约 160-200Mbps 的速度处理内容。 - * 还研究了 [MPEG-DASH](https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) （基于 HTTP 的动态自适应流）。 + 在原始级别上，我们以大约 10-15MBps 的速度连续写入磁盘。 - * 优势：与 HLS 相比，它的空间效率高 15％。 + * **您提供多少份文件？ 多少张图片？ 多少数据？** - * 优点：它允许自适应比特率。 编码质量可以基于网络吞吐量而变化。 + 现在数据库大约是 500G。 我们预计随着我们扩大产品范围，它的增长将远远超过 2008 年。 - * [吹笛者中出压缩解决方案](https://www.crunchbase.com/organization/pied-piper#/entity) ：（开个玩笑） + * **您的增长率是多少？** -* 于 2015 年 12 月在数十个国家推出。 + 主要是客户功能请求的功能。 如果我们的客户想要更多数据，我们会将其出售给他们。 -![](img/cc9254808fa61d8f01212c2503be1c30.png) + 我们计划在 2008 年扩展集群，以索引网络和消费者生成的媒体的较大部分。 -## 实时视频与众不同，这会引起问题 + * **您的系统的体系结构是什么？** -* 前面提到的西瓜视频的流量模式： + 我们将 Java，MySQL 和 Linux 用于我们的集群。 - * 最初的上升非常陡峭，在几分钟之内达到了每秒 100 多个请求，并持续增长直到视频结束。 + Java 是用于编写搜寻器的出色语言。 库的支持非常牢固（尽管 Java 7 在添加闭包时似乎将成为杀手））。 - * 然后，流量像石头一样下降。 + 我们将 MySQL 与 InnoDB 结合使用。 尽管看起来我最终花费了 20％的时间来解决 MySQL 错误和限制，但我们大多数还是对此感到满意。 - * 换句话说：流量很尖。 + 当然，没有什么是完美的。 例如，MySQL 确实是为在单核系统上使用而设计的。 - ![](img/20bf250cc8477b6987d45ae83f3d37c1.png) + MySQL 5.1 版本在修复多核可伸缩性锁定方面更进一步。 -* 实时视频与普通视频不同：它会导致**尖峰** **流量模式**。 + 我最近在博客中写道，这些新的多核计算机实际上应该被视为 N 台计算机而不是一个逻辑单元：[分布式计算谬误＃9](http://feedblog.org/2007/09/23/distributed-computing-fallacy-9/) 。 - * 实时视频更具吸引力，因此观看**的**比普通视频多 3 倍。 + * **您的系统如何设计以进行扩展？** - * 实时视频出现在新闻源的顶部，因此被观看的可能性更高。 + 我们使用联合数据库系统，以便我们可以在看到更多 IO 的情况下分配写负载。 - * 通知会发送到每个页面的所有粉丝，以便另一组可能会观看视频的人。 + 我们已经在许多基础架构中以开源形式发布了很多代码，并且这些代码也可能会以开源形式发布。 -* 高峰流量会导致缓存系统和负载平衡系统出现问题。 + 我们已经开放了很多基础架构代码：* http://code.tailrank.com/lbpool-与数据库连接池一起使用的负载均衡 JDBC 驱动程序。* http://code.tailrank.com/feedparser-Java RSS / Atom 解析器，旨在优雅地支持所有版本的 RSS* http://code.google.com/p/benchmark4j/-与 Windows 的 perfmon 等效的 Java（和 UNIX）* http://code.google.com/p/spinn3r-client/-用于访问 Spinn3r Web 服务的客户端绑定* http://code.google.com/p/mysqlslavesync/-克隆 MySQL 安装和设置复制。* http://code.google.com/p/log5j/-Logger 门面，它支持 printf 样式的消息格式，以提高性能和易于使用。 -* **缓存问题** + * **您有多少台服务器？** - * 很多人可能希望同时观看直播视频。 这是您的经典 [雷电牧群问题](https://en.wikipedia.org/wiki/Thundering_herd_problem) 。 + 到目前为止大约有 15 台机器。 我们花了很多时间来调整我们的基础架构，因此它非常有效。 也就是说，构建可扩展的爬虫并不是一件容易的事，因此确实需要大量硬件。 - * 尖刻的流量模式给缓存系统带来压力。 + 我们将在 2008 年将 FAR 扩展到此范围之外，并且可能会击中 2-3 机架机器（约 120 箱）。 - * 视频被分割成一秒钟的文件。 当流量激增时，缓存这些段的服务器可能会过载。 + * **您使用什么操作系统？** -* **全局负载平衡问题** + 通过 Debian Etch 在 64 位 Opteron 上运行的 Linux。 我是 Debian 的忠实粉丝。 我不知道为什么更多的硬件供应商不支持 Debian。 - * Facebook 在全球分布 [个存在点](https://en.wikipedia.org/wiki/Point_of_presence) （PoP）。 Facebook 流量在全球范围内分布。 + Debian 是山谷中没人谈论的大秘密。 Technorati，Digg 等大多数大型 Web 2.0 商店都使用 Debian。 - * 挑战在于防止峰值导致 PoP 过载。 + * **您使用哪个 Web 服务器？** -## 大图片架构 + Apache 2.0。 Lighttpd 也看起来很有趣。 -这就是直播流从一个广播公司到数百万观众的方式。 + * **您使用哪个反向代理？** -* 广播员在其手机上开始直播视频。 + 大约 95％的 Tailrank 页面由 Squid 提供。 -* 手机将 RTMP 流发送到实时流服务器。 + * **您的系统如何部署在数据中心中？** -* 实时流服务器解码视频并将代码转换为多个比特率。 + 我们使用 ServerBeach 进行托管。 对于中小型创业公司来说，这是一个很好的模型。 他们将箱子放在架子上，维护库存，处理网络等。我们只需购买新机器并支付固定的加价。 -* 对于每个比特率，都会连续生成一秒的 MPEG-DASH 段。 + 希望 Dell，SUN 和 HP 以这种方式直接出售给客户。 -* 段存储在数据中心缓存中。 + 现在一个。 我们希望将冗余扩展为两个。 -* 来自数据中心的缓存段被发送到位于存在点的缓存（PoP 缓存）。 + * **您的存储策略是什么？** -* 观看者在观看时会收到一个实时故事。 + 直接连接的存储。 我们每盒购买两个 SATA 驱动器，并将它们设置在 RAID 0 中。 -* 他们设备上的播放器开始以每秒 1 个的速率从 PoP 缓存中获取片段。 + 我们使用廉价数据库解决方案的冗余阵列，因此，如果单个计算机出现故障，则会在另一个盒中复制数据。 -## 它如何缩放？ + 便宜的 SATA 磁盘决定了我们的工作。 它们便宜，商品且快速。 -* 数据中心高速缓存与**许多 PoP 高速缓存**之间有一个**乘法点**。 用户访问 PoP 缓存，而不是数据中心，并且全世界分布着许多 PoP 缓存。 + * **您的网站是否有标准 API？** -* 另一个乘数是每个 PoP 中的**。** + Tailrank 每页都有 RSS feed。 - * 在 PoP 内有**两层**：一层 HTTP 代理和一层缓存。 + Spinn3r 服务本身就是一个 API，我们有关于该协议的大量文档。 - * 查看器从 HTTP 代理请求段。 代理检查该段是否在缓存中。 如果它在缓存中，则返回该段。 如果不在缓存中，则将对该段的请求发送到数据中心。 + 研究人员也可以免费使用它，因此，如果您的任何读者正在攻读博士学位并通常从事研究工作，并且需要访问我们喜欢的博客数据以帮助他们。 - * 不同的**段存储在不同的缓存**中，从而有助于跨不同的缓存主机进行负载平衡。 + 我们已经有使用 Spinn3r 在华盛顿大学和马里兰大学（我的母校）的博士学位学生。 -## 保护数据中心免受雷电袭击 + * **您使用哪个 DNS 服务？** -* 当所有观众同时请求相同的片段时会发生什么？ + PowerDNS。 这是一个很棒的产品。 我们仅使用 recursor 守护程序，但它是 FAST。 虽然它使用异步 IO，所以它实际上并不能在多核盒子上的处理器之间扩展。 显然，有一种破解方法可以使其跨内核运行，但这并不是很可靠。 -* 如果该段不在缓存中，则将向每个查看器发送一个请求到数据中心。 + AAA 缓存可能已损坏。 我仍然需要研究这个。 -* **请求合并** 。 通过将请求合并添加到 PoP 缓存中，减少了请求数量。 仅第一个请求发送到数据中心。 其他请求将一直保留，直到第一个响应到达并将数据发送给所有查看者为止。 + * **您欣赏谁？** -* 新的缓存层已添加到代理，以避免 **Hot Server 问题**。 + 唐纳德·克努斯是男人！ - * 所有查看器都发送到一个缓存主机，以等待该片段，这可能会使主机过载。 + * **您如何考虑将来更改架构？** - * 代理**添加了缓存层**。 实际上，只有第一个对代理的请求才向缓存发出请求。 以下所有请求均直接从代理服务。 + 我们仍在努力完善完整的数据库。 MySQL 容错和自动升级也是一个问题。 -## PoP 仍处于危险之中-全局负载平衡可拯救 +MySQL 故障 +容忍度和自动升级也是一个问题。 -* 因此，可以保护数据中心免受雷电群问题的影响，但是 PoP 仍然处于危险之中。 Live 的问题是尖峰非常大，以致 PoP 可能在 PoP 的负载度量达到负载平衡器之前过载。 +当数据库对您如此重要时，您应该将其像已存在可行替代品的任何其他基础结构商品一样对待： -* 每个 PoP 具有数量有限的服务器和连接性。 如何防止峰值导致 PoP 过载？ +吞咽困难，然后小便达到最佳状态。 -* 名为 Cartographer 的系统将 Internet 子网映射到 PoP。 它测量每个子网和每个 PoP 之间的延迟。 这是延迟测量。 +“最好”在旁观者眼中，因此我将其留给读者。 -* 测量每个 PoP 的负载，并将每个用户发送到具有足够容量的最近 PoP。 代理中有一些计数器可以衡量它们承受的负载量。 这些计数器是聚合的，因此我们知道每个 PoP 的负载。 +中文 memeTracker 网站： [http://www.onejoo.com/](http://www.onejoo.com/) +监视超过 500 万博客，论坛和新闻。 -* 现在存在一个优化问题，该问题会考虑容量限制并最大程度地减少延迟。 +您如何使用 InnoDB 支持全文搜索？ -* 使用控制系统时，存在测量延迟和反应延迟。 +-伊沃 -* 他们将负载测量窗口从 1.5 分钟更改为 3 秒，但仍然有 3 秒的窗口。 +[http://www.web20friends.net](http://www.web20friends.net) -* 解决方案是在实际发生负载之前 **预测负载** 。 +嗨，伊沃 -* 实施了**容量估算器**，将每个 PoP 的先前负载和当前负载外推到未来负载。 +我们不在 innodb 上使用全文本搜索。...实际上，我们将数据快照加载到 myisam 中，并将其用于全文本搜索。 - * 如果负载当前正在增加，预测器如何预测负载将减少？ +对于小型文档集，MySQL 全文搜索在某种程度上是可取的。 - * **三次样条**用于 [插值](https://en.wikipedia.org/wiki/Spline_interpolation) 功能。 +tailrank feedparser Wiki 为何以票证的形式充满色情链接？ +[http://code.tailrank.com/feedparser/report/6](http://code.tailrank.com/feedparser/report/6) - * 取一阶和二阶导数。 如果速度为正，则负载将增加。 如果加速度为负，则表示速度正在降低，最终将为零并开始降低。 - - * 三次样条比线性插值预测更复杂的交通模式。 - - * **避免振荡** 。 此插值功能还解决了振荡问题。 - - * 测量和反应的延迟意味着对过时的数据做出决策。 插值可减少误差，更准确地进行预测并减少振荡。 因此负载可以更接近目标容量 - - * 当前预测基于 最近的三个间隔 ，其中每个间隔为 30 秒。 几乎是瞬时负载。 - -## 测试 - -* 您需要能够使 PoP 过载。 - -* 构建了一个负载测试服务，该服务在 PoP 上全局分布，以模拟实时流量。 - -* 能够模拟 10 倍的生产负荷。 - -* 可以模拟一次请求一个片段的查看器。 - -* 该系统有助于揭示和修复容量估计器中的问题，以调整参数并验证缓存层是否解决了雷电群问题。 - -## 上传可靠性 - -* 实时上传视频具有挑战性。 - -* 以具有 100 至 300 Kbps 可用带宽的上载为例。 - -* 音频需要 64 Kbps 的吞吐量。 - -* 标清视频需要 500 Kbps 的吞吐量。 - -* 手机上的自适应编码用于调整视频+音频的吞吐量不足。 视频的编码比特率根据可用的网络带宽进行调整。 - -* 决定上传比特率的方法是在手机中通过测量 RTMP 连接上的上传字节来完成，并且对最后间隔进行加权平均。 - -## 未来方向 - -* 研究一种推送机制，而不是请求拉机制，利用 HTTP / 2 在请求分段之前将其推送到 PoP。 - -## 相关文章 - -* [关于 HackerNews](https://news.ycombinator.com/item?id=11987654) - -* [扩展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) - -* [为什么 Facebook 和 Mark Zuckerberg 都参与直播视频](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video) - -* [连通世界：Facebook 的网络基础架构](http://cs.unc.edu/xcms/wpfiles/50th-symp/Moorthy.pdf) - -* [Gamoloco](https://gamoloco.com/) 跟踪 1476093 个频道的实时视频统计信息。 - -Google Chrome 浏览器告诉我您的网站已感染恶意软件。 也许是个调皮的广告？ - -我很乐意在具有如此高流量的平台上工作。 12 位工程师可以毫无问题地做到这一点。 很少有人可以在应用程序上工作，甚至可以进行额外的数据压缩，而在主平台上则很少。 我什至可以处理 100-200k 观众的实时视频流，唯一的限制是资金有限；）我仍然不明白 150 名工程师在此方面的工作... -一如既往的好文章，我 很抱歉，我目前没有客户，流量非常大。 - -150 名工程师可以同时建立 10 个创业公司！ 没有留下深刻印象。 - -我不知道为什么 Google 网站管理员工具 Dobes 会显示该网站存在我什至无法在该网站上找到的问题，但是却没有说出它是否带有恶意软件。 - -我不知道 Facebook 工程师的自我来自何处。 毫无疑问，这是一个很难解决的问题，但我认为这与核武器的复杂性不相上下。 - -Facebook live 的问题都不是新问题。 它们是成熟的技术，许多公司已经多次解决了它们。 - -规模仍然非常可观，我想你们应该专注于此。 - -我对 MPEG-DASH 感到担心，“它允许自适应比特率。编码质量可以根据网络吞吐量而变化”。 那是优点还是缺点？ 谢谢。 - -自适应比特率通常被认为是一个优势，因为只要带宽高于最小比特率，流就不会中断。 - -顺便说一下，就我所知，MPEG-DASH 与 HLS 本质上相同，都允许自适应比特率。 \ No newline at end of file +现在，世界上大多数参与计算环境的名人都在使用 MYSQL。 我猜它是从它自己的体系结构中获得流行的。 +----- +[http://underwaterseaplants.awardspace.com“](海洋植物 +[http://underwaterseaplants.awardspace.com/seagrapes。 htm“](海葡萄... [http://underwaterseaplants.awardspace.com/seaweed.htm”](海藻 \ No newline at end of file diff --git a/docs/190.md b/docs/190.md index 0694698..df41cfd 100644 --- a/docs/190.md +++ b/docs/190.md @@ -1,205 +1,29 @@ -# Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件 +# Tinder：最大的推荐引擎之一如何决定您接下来会看到谁？ -> 原文： [http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html](http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html) +> 原文： [http://highscalability.com/blog/2016/1/27/tinder-how-does-one-of-the-largest-recommendation-engines-de.html](http://highscalability.com/blog/2016/1/27/tinder-how-does-one-of-the-largest-recommendation-engines-de.html) -![](img/26429ee917d000d853d82c835eb1ab89.png) [Mollom](http://mollom.com/) 是每个开发人员在绞尽脑汁寻找可行的软件即服务创业公司时都梦 of 以求的出色的 SaaS 公司之一。 Mollom 与一小部分地理位置分散的开发人员一起以有益的方式运行有用的服务-[垃圾邮件过滤](http://www.youtube.com/watch?v=anwy2MPT5RE)。 Mollom 帮助保护了近 40,000 个网站免受垃圾邮件的侵扰，其中包括[属于我的](http://biztaxtalk.com/)，这是我第一次了解 Mollom 的地方。 为了在 Drupal 网站上停止垃圾邮件的拼命尝试，在该网站上，所有其他形式的 CAPTCHA 都失败了，我在大约 10 分钟内安装了 Mollom，它立即开始工作。 那是我一直在寻找的开箱即用的体验。 +![](img/2688e3c8765d8fadc182017986ce3866.png) -从 Mollom 开放其数字检查系统开始，他们已经拒绝了超过 3.73 亿封垃圾邮件，在此过程中，他们了解到，惊人的 90％的邮件都是垃圾邮件。 该垃圾邮件洪流仅由两台地理位置分散的计算机处理，这些计算机每秒处理 100 个请求，每个计算机都运行 Java 应用程序服务器和 Cassandra。 因为它们创建了一个非常高效的机器学习系统，所以几乎不需要任何资源。 那不是很酷吗？ 那么，他们怎么做呢？ +我们已经听到很多关于电影的 Netflix [推荐算法](http://www.wired.com/2013/08/qq_netflix-algorithm/)，[亚马逊](https://www.cs.umd.edu/~samir/498/Amazon-Recommendations.pdf)如何与您匹配的东西，以及 Google 臭名昭著的 [PageRank](https://en.wikipedia.org/wiki/PageRank) 的信息。 Tinder 呢？ 事实证明，Tinder 具有令人惊讶的深思熟虑的推荐系统来匹配人员。 -为了找出答案，我采访了 Mollom 的联合创始人 Benjamin Schrauwen，以及 Glassfish 和 Java 企业专家 Johan Vos。 证明软件没有国界，Mollom HQ 位于比利时的[H​​TG0] （来自比利时的其他好东西： [Hercule Poirot](http://en.wikipedia.org/wiki/Hercule_Poirot) ，[巧克力](http://www.google.com/images?q=belgian+chocolate)，[华夫饼](http://www.google.com/images?q=belgium+waffles) ）。 +[（刷卡）先生，对吗？](https://story.californiasunday.com/sean-rad-tinder) ，在 Tinder 创始人 Sean Rad 上： -## 统计 +> 根据 Badeen 所说，用户的目标是让他们忘记三秒钟之内被刷过的人。 但是 Tinder 没有。 他们研究成员滑动的对象，匹配对象。 然后他们看“重新激活”。 年轻的用户将消失几周，然后“重新激活”或再次开始刷卡。 年龄较大的用户会花更多时间查看各个个人资料，并且很可能在重新激活之前消失了几个月。 古尔德说，平均活跃用户每天在 Tinder 上花费一个小时。 （拉德说他上瘾了，花了无数小时来刷卡。） -* 服务于 40,000 个活跃的网站，其中许多是非常大的客户，例如 Sony Music，Warner Brothers，Fox News 和 The Economist。 很多大品牌，有大网站，还有很多评论。 -* 每天查找 1/2 百万封垃圾邮件。 -* 每秒处理 100 个 API 调用。 -* 垃圾邮件检查的延迟很短，大约需要 30-50 毫秒。 最慢的连接将是 500 毫秒。 延迟的第 95 个百分位数是 250 毫秒。 它确实针对速度进行了优化。 -* 垃圾邮件分类效率为 99.95％。 这意味着 Mollom 不会捕获 10,000 个垃圾邮件中的 5 个。 -* [Netlog](http://mollom.com/blog/netlog-using-mollom) 是欧洲的一个社交网站，在其自己的数据中心中拥有自己的 Mollom 设置。 Netlog 每天根据自定义[分类器](http://en.wikipedia.org/wiki/Learning_classifier_system)处理大约 400 万条消息，这些分类器对其数据进行了训练。 +> 邻里模式往往是独特的。 即使是城市中不同街区的人，也会有不同的举止或匹配的可能性较小。 古尔德说：“人们自然在地理上对自己进行分类。” 如果人们旅行，他们的行为就会发生巨大变化。 **“我们了解了一个人的全部知识，”古尔德说，“然后他们去了另一个地方，采取了完全不同的行动**。 古尔德（Goul）负责调整算法，他的头发偏斜一些，衣服比 Rad 和 Badeen 的宽松一些。 也就是说，比赛不是偶然发生的。 Tinder 正在安排您接下来要看的人。 **拥有数十亿个匹配项，因此拥有大量数据**。 Rad 说：“我们可能是世界上最大的推荐引擎之一。” -## 平台 +> **首先，古尔德告诉我，该应用程序的统治类别为“匹配 1％，**”，这些人获得了大量的比赛，并且使其他所有人看起来都比较糟糕。 Tinder 决定**改变趋势，减少显示**的配置文件，特别是向不在 1％范围内的用户展示。 现在，显示出很多向右滑动（是）的人逐渐减少的人，而得到了很多向左滑动（否）的人逐渐表明的人越来越多。 “我称之为累进税制-重新分配比赛。 他们并不是真正要重新分配的人，但我们会尽力而为。”古尔德说。 “这样做是正确的。” **该公司将其称为“智能匹配”：通过平衡游戏环境并确保不太可能获得匹配的成员获得一些东西，从而在约会世界中赢得正义。** “人类状况的一部分是斗争。 如果您除了“维多利亚的秘密（Victoria's Secret）”模特外什么都看不到，那就不一定要脱颖而出。” “当我们介绍不适合您的人时，就会突出那些人。 比赛不是偶然发生的。 Tinder 正在安排您接下来要看的人。 -* 两个生产服务器在两个不同的数据中心中运行以进行故障转移。 - * 一台服务器在东海岸，一台在西海岸。 - * 每个服务器是一个 Intel Xeon Quad 核心，2.8 GHz，16 GB RAM，4 个 300 GB 磁盘，RAID 10。 -* [SoftLayer](http://www.softlayer.com/ ) -机器由 SoftLayer 托管。 -* [Cassandra](http://cassandra.apache.org/) -选择 NoSQL 数据库是因为它具有出色的写入性能和跨多个数据中心进行操作的能力。 -* [Glassfish](http://en.wikipedia.org/wiki/GlassFish) -用于 Java EE 平台的开源应用程序服务器。 他们选择了 Glassfish，因为它具有企业级功能，例如复制和故障转移。 -* [Hudson](http://hudson-ci.org/) -可在所有服务器上进行后端的连续测试和部署。 -* Java-Mollom 从一开始就是用 Java 编写的。 -* [Munin](http://munin-monitoring.org/) -用于测量和绘制有关服务器运行状况的指标。 -* [MySQL](http://www.mysql.com/) -JPA（Java Persistence API）用于常规数据集，而 Cassandra 用于大型数据集。 -* [Pingdom](http://www.pingdom.com/) -用于正常运行时间监视。 -* [Zendesk](http://www.zendesk.com/) -用于支持。 -* [Drupal](http://drupal.org/) -用于具有自定义电子商务模块的主网站。 -* [解除混淆](http://unfuddle.com/)-Subversion 托管由其分布式开发团队用于源代码控制。 +> **他们还更改了不良演员的系统，限制了每天刷卡的次数**。 古尔德说：“我们以前有一群人会向所有人轻扫，然后不回应，所以我们增加了一个限制，以发现未玩游戏的人。” “我很惊讶，但是人们实际上很聪明。 他们发挥自己的才能。 在最初的几天里，这些家伙不断达到极限。 然后，在那之后，他们开始适应。 一旦完成，对话时间就会更长。 -## 什么是 Mollom？ +> **Gould 和 Badeen 将这些干预视为道德义务**。 Badeen 说：“知道它会对人们产生多大的影响，这很令人恐惧。” “我尝试忽略其中的一些，否则我会发疯。 我们正处于对世界负有社会责任的地步，因为我们具有影响世界的能力。 -Mollom 是一项 Web 服务，用于从用户生成的内容中过滤掉各种类型的垃圾邮件：评论，论坛帖子，博客帖子，民意调查，联系表，注册表和密码请求表。 垃圾邮件的确定不仅取决于发布的内容，还取决于张贴者的过去活动和声誉。 Mollom 的[机器学习](http://en.wikipedia.org/wiki/Machine_learning)算法充当您的 24x7 数字主持人，因此您不必这样做。 +> Gould 回应了这一观点：“听着，建筑师设计的建筑物设定了人们的生活方式。 城市规划人员设置城镇和道路。 作为帮助人们约会的系统的设计者，我们有责任建立这些背景-我们每年都要为这个星球上相当比例的婚姻负责。 这是一种荣誉和责任。 -### 如何使用？ +[关于 HackerNews](https://news.ycombinator.com/item?id=10981314) -例如，诸如 Drupal 之类的应用程序使用一个模块将 Mollom 集成，该模块将自身安装到内容编辑集成点中，以便在将内容写入数据库之前可以检查其内容是否为垃圾内容。 该过程看起来像： +它与高可扩展性有何关系？ -* 当用户向网站提交评论时，将对后端服务器进行 API 调用。 -* 会对内容进行分析，如果是垃圾内容，则将告知网站阻止该内容，或者如果后端不确定，它将建议该网站显示 [CAPTCHA](http://en.wikipedia.org/wiki/CAPTCHA) ，它们也可以提供该内容。 -* 正确填写验证码后，内容将被接受。 在大多数情况下，人们不会看到验证码，该内容将直接被视为*火腿*，火腿是好内容，*垃圾邮件*是坏内容。 -* 仅在机器学习算法不是 100％确定的情况下才显示 CAPTCHA，因此在大多数情况下不会给人类带来不便。 +我当然喜欢技术细节，但是我发现这些与政策相关的见解也很重要。 它比我预期的要更加周到和完善，并且有趣地使用大数据来推动产品在面向目标的方向上使用。 -### 仪表板 - -Mollom 的每个帐户都包含一个漂亮的[漂亮的信息中心](http://mollom.com/scorecard)，它向您显示了已接受多少火腿和已拒绝多少垃圾邮件。 在图中看到的垃圾邮件数量确实令人沮丧。 - -### 运作流程 - -**安装。** 对于 Drupal 来说，安装非常容易。 像安装其他模块一样安装它。 在 Mollom 网站上创建一个帐户。 获取一对安全密钥，将这些密钥配置到模块中，然后选择要使用 Mollum 保护的系统部分。 就是这样 - -**每日**。 我定期检查垃圾邮件是否已经通过。 它不是 100％，因此某些垃圾邮件确实可以通过，但很少。 如果垃圾邮件确实通过了，则有一种方法可以告诉 Mollom 该帖子确实是垃圾邮件，应将其删除。 无论如何，这都是您必须要做的，但是在此过程中，您正在帮助培训 Mollom 的机器学习算法，了解什么是垃圾邮件。 - -**允许匿名用户交互**。 有了出色的垃圾邮件检查程序，就有可能建立一个网站，人们可以进行匿名交互，这是许多使用某些类型网站的人真正喜欢的。 一旦您要求注册，参与活动就会减少，并且注册也不会阻止垃圾邮件发送者。 - -### 并非一切都是玫瑰色 - -处理误报是 Mollom 的最大缺点。 垃圾邮件检测是拒绝火腿和接受垃圾邮件之间的困难平衡行为。 Mollom 的机器学习算法似乎运行得很好，但是有时存在一个问题，即好的帖子被拒绝，您会感到恐惧：*您的提交触发了垃圾邮件过滤器，将不被接受*。 目前没有追索权。 对于用户而言，几乎没有什么比让他们的光荣评论被垃圾邮件拒绝更令用户生气的了。 用户只会尝试几次来解决问题，然后他们只会放弃并走开。 - -问题是无法解决此问题。 为了保护机器学习算法不被玩耍，Mollom 不允许您提供一个示例，该示例错误地拒绝了应接受的内容块，尽管他们正在努力在将来添加它。 - -这是一个艰难的决定。 静态 CAPTCHA 系统，即仅要求用户通过测试即可提交内容的系统，一旦将站点定为严重攻击目标就无法正常工作。 用户注册无效。 考虑到一个站点每天可能有成千上万的垃圾邮件，对每个帖子进行审核需要非常高的负担，尤其是对于“爱好”站点。 垃圾邮件完全杀死了一个站点，因此，要平衡激怒某些用户的风险，而不要因为一个被炸毁的站点而最终没有用户。 - -## 商业模式 - -* 让 Mollom 轻松自如的是，它是免费的。 您只需在网站开始每天接受 100 多个火腿消息后付款。 对于小型站点，这可能永远不会发生。 -* 一旦超过免费门槛，便有 Mollom Plus（每天 1 欧元）和 Mollom Premium（3600 欧元/年/站点）的定价层，这似乎很合理。 -* 免费的网站并不会像您期望的那样浪费资源，它们实际上是重要培训数据的来源。 所有使用 Mollom 的网站都在不断将数据反馈给后端分类器。 使用 Mollom 的人越多，通过从用户那里获得的所有反馈进行培训的效果就越好。 没有免费的网站，Mollom 就不会像现在那样准确。 - -## 建筑 - -* Mollom 非常受工程驱动。 主要重点在于使 Mollom 在代码和服务器资源使用上都尽可能高效。 -* 实际上，每个服务器都可以处理所有请求，但是它们具有完整的故障转移。 工作在机器之间分配。 如果其中一个发生故障，则工作移至另一台机器。 - * 他们曾经有 3 台服务器，但是由于它们提高了性能，因此可以将第三台服务器用作登台服务器。 - * 每个服务器每秒可以处理完整的 100 个连接，并且每个连接运行整个管道：全文分析，计算作者的信誉并提供 CAPTCHAS。 -* 真正针对低延迟进行了优化。 由于垃圾邮件检测是内容提交到站点过程的一部分，因此，如果花很长时间，对用户来说真的很烦。 -* 软体动物经历了几个发展阶段： - 1. 最初，一个由两个人组成的小团队在做兼职，负责算法，分类器和他们试图解决的实际业务问题。 为了在后端建立基础架构，他们使用了自己的线程池，连接池，资源管理实现。 他们发现他们花了太多时间来支持所有这些东西并使其扩展。 然后他们切换到 Java 应用程序服务器 Glassfish，因此他们不必担心内存管理，REST 处理，XML 解析和数据库连接池。 - 2. 过去的主要问题是磁盘带宽。 他们需要跟踪 Internet 上所有 IP 地址和所有 URL 的信誉，因此这是一个庞大的数据存储，具有许多随机访问权限。 - 3. 早期，他们使用廉价的虚拟机，而一切都在 MySQL 中进行，但无法扩展。 - 4. 然后，他们将其移至固态磁盘并将所有内容存储在文件中。 固态解决了写问题，但是有一些问题： - 1. 真的很贵。 - 2. 这对安装的文件系统类型非常敏感。 - 3. 写入速度很快，但是遍历数据以清理数据或在数百万个小对象上训练新的分类器仍然非常缓慢。 - 5. 然后他们离开了固态，搬到了卡桑德拉。 -* Cassandra 现在用作写繁重负载的数据库和缓存层： - * 在 [RAID 10](http://www.thegeekstuff.com/2010/08/raid-levels-tutorial/) 磁盘配置（条带化和镜像）上运行，这对于大量读/写非常有用。 - * 卡桑德拉（Cassandra）针对写入进行了优化，而 Mollom 的写入量要大于读取量。 - * 设计为分布在数据中心内部和整个数据中心。 - * 缺点是没有标准的 NoSQL 接口，这使得编写应用程序变得困难。 - * Cassandra 的行缓存使他们不必在系统中添加另一个缓存层，从而消除了大量应用程序代码。 - * Cassandra 具有老化功能，该功能会在一段时间后自动删除数据。 欧洲有严格的隐私法，要求一段时间后删除某些数据。 此功能是一个巨大的胜利。 这是一个非常昂贵的操作，Cassandra 处理它会删除很多应用程序代码。 -* 博客评论通过系统的路径： - * 请求可以来自任何客户端。 客户端跨服务器负载平衡请求。 这部分将在后面说明。 典型的客户端是 Drupal 系统。 请求可以是 XML-RPC 或 REST。 - * 请求由 Glassfish 应用程序服务器处理并遵循典型的应用程序服务器工作流程：请求由 servlet 处理并委托给会话 bean。 - * 付费客户首先得到服务，免费客户可能会遇到更长的延迟。 - * 对该请求进行解析和分析。 稍后再详细介绍。 确定垃圾邮件分数并将其返回给用户。 因此，Mollom 有不同的功能部分：垃圾邮件检查和 CAPTCHA 处理。 CAPTCHA 包括生成，提供和处理响应。 不同的会话 bean 负责 Mollom 功能的各个部分。 - * 分类器完全位于 RAM 中。 一小部分内容被炸裂成数千个可以识别垃圾邮件的小令牌。 这些分类器在 RAM 中具有几百万个令牌。 分类器需要真正快速运行，因此它们必须位于 RAM 中。 - * 卡桑德拉（Cassandra）中保存的是信誉分数，频率，URL 和 IP 地址。 Cassandra 的新行缓存功能现在充当其缓存层。 以前，他们实现了内部缓存，但是已将其删除。 - * 两个数据中心中的两台机器都运行 Cassandra 和 Glassfish 应用程序服务器。 Cassandra 不断在数据中心之间复制数据。 - * 内存中的数据结构不会直接复制。 他们写信给 Cassandra，然后复制。 另一端的缓存超时，因此它将转到 Cassandra 并获取新数据。 最终是一致的。 不一致的窗口很小，但是模型在这么短的时间内不会受到负面影响。 - * 一致性是根据具体情况进行管理的。 对于信誉和 IP 地址，最终的一致性很好。 会话数据（包括 CAPTCHA 会话）保持严格一致，因此当计算机进行故障转移时，它们将正确跟踪。 -* 客户端负载平衡 - * Mollom 使用[客户端负载平衡](http://mollom.com/api/client-side-load-balancing)，该负载平衡基于延迟等进行分配。作为一家初创公司，他们没有钱购买大型负载平衡器。 他们的另一个目标是能够对多个数据中心进行全局负载平衡，这将需要昂贵且复杂的设置。 - * 客户端列表的管理通过 API 进行。 每个客户端都有其可以使用的可用服务器的列表。 - * 每个客户端可以获取要使用的服务器的不同列表。 可以向付费客户提供更近的服务器列表，以减少延迟。 - * 当服务器发生故障时，客户端将尝试列表中的下一个服务器。 - * 客户端负载平衡有助于从旧系统迁移到新的基于 Glassfish 的系统。 将为新用户提供已迁移计算机的地址，而旧用户仍在旧计算机上工作，并且可以通过更新其服务器列表以有序方式进行迁移。 这允许进行测试，以便他们可以测试功能，然后测试伸缩性和性能。 他们查看了响应时间，连接队列中有多少个连接以及队列中将保留多长时间。 他们可以测试如果增加线程池中的线程，更改 JDBC 连接数以及其他配置会发生什么情况。 所有人迁移后，旧服务器将关闭。 过渡期间几乎没有停机时间，这对于高可用性系统至关重要。 当系统关闭时，垃圾邮件正在通过。 - * 客户端方法的缺点是，如果第三方客户端的文字写得不好，就会出现问题。 例如，客户端可以获取服务器列表，并以相反的顺序对其进行迭代，这是错误的。 他们现在与客户开发人员紧密合作，并提供高质量的参考代码示例，以便开发人员可以学习最佳实践。 -* 机器学习 - * Mollom 是一组学习系统。 一个既不考虑用户行为也不考虑起点的 CAPTCHA 解决方案，永远无法达到这种水平的知情保护，并且通常要求用户在每个帖子上都解决 CAPTCHA 问题。 使用 Mollom 的文本分析，仅当 Mollom 不确定帖子时，用户才必须解决验证码。 - * 平均消息长度约为 500 个字符，这被分解为 3,000 个功能。 通过查看 IP 地址或 Open ID 的信誉来确定帖子的混乱状态，可以查看用户 ID，情感，语言，亵渎，特定单词和单词组合，还可以查看文字的写法。 等等。所有这些都是基于分类器的。 一些分类器本质上是统计的，可以自动学习。 一些基于规则的分类器可确保它们永远不会出错。 最终，所有这些测试将决定垃圾邮件得分。 - * 他们从该过程中学习，并实时更新分类器和内部指标。 -* Glassfish 可处理工作计划，并旨在处理多核工作负载。 - * 关键是创建一个尽可能平行的作品设计，并具有尽可能小的锁定窗口。 - * 调整并发 HTTP 连接的数量，以便它们具有适当大小的可用连接池。 - * 每个服务器使用 16 个线程。 - * 大多数调用由无状态会话 Bean 处理，该会话状态可很好地进行并发管理。 - * 他们在池中保留了多个会话 bean，但让 Glassfish 决定池中应包含多少个会话 bean。 在峰值负载下，池中将有更多会话 Bean，因此可以有效地处理请求。 任何给定时刻都可以并行运行 32 个会话 Bean。 - * 所有的分类器实际上都是会话 Bean，它们被不同的线程重用。 - * 每个会话 bean 都有自己的与 Cassandra 的客户端连接，因此它们不会互相阻塞。 - * 当用户不响应 CAPTCHA 时，该会话将被清除，Mollom 得知这可能是垃圾邮件。 - * 每个服务器的每个分类器都有一个实例。 - * 会话清理的锁争用时间很短，其中正在更新分类器。 - * 每 1/2 小时将更新的分类器写回到 Cassandra。 -* 应用整合 - * Mollom 使用开放式 API，可以将其集成到任何系统中。 - * 库：Java，PHP，Ruby 等。 - * 集成解决方案：Drupal，Joomla，Wordpress 和其他内容管理系统。 - * 第三方根据 Mollom 产生的示例代码生成新的绑定。 -* 为了监视服务器的运行状况，他们使用 Munin 进行了持续监视： - * 垃圾回收后堆的大小是多少？ - * 可用连接数是多少？ - * 线程池中可用的线程数是多少？ 确保没有一个线程长时间等待锁。 -* 当您查看他们的体系结构时，Mollom 试图构建一种可以透明地在多个数据中心内工作的体系结构，当它们已经超出单个服务器系统的规模时，它们本身可以向上扩展： - * 客户端负载平衡用于选择和故障转移服务器。 - * Glassfish 群集将用于在应用程序层进行故障转移，并使添加和删除计算机变得容易。 - * Cassandra 将用于跨数据中心管理数据层。 -* Netlog 的 Mollom 安装具有一些有趣的特征。 它比 Mollom.com 主要服务器处理的更多，但是垃圾邮件的分布完全不同，因为他们的人员进行通信是社交网络的一部分。 Netlog 上的垃圾邮件分布为 90％的火腿和 10％的垃圾邮件，而在残酷的博客世界中，这恰恰相反。 有趣的含义是，处理火腿所需的资源较少，因此它们实际上可以在同一服务器上执行更多工作。 -* 他们最初尝试使用虚拟服务器，并考虑使用 Amazon，但是他们发现 IO 是使用共享虚拟服务器的主要瓶颈。 IO 延迟和带宽是真正的问题，因此他们决定扩大规模并使用更大的计算机和更大的磁盘。 - * 令人惊讶的是，它们不受 CPU 限制。 8 个内核中只有两个在计算。 其他人只是在做 IO。 - * Mollom 的流量相当稳定，因此拥有专用服务器更具成本效益。 他们看到亚马逊更多地是一种处理高峰负载的方式。 -* 开发过程 - * 他们是分散的团队。 三个人在比利时，一个在德克萨斯州，波士顿和德国。 - * Scrum 被用作开发过程，他们对此非常满意。 Scrum 会议在下午 2 点通过 Skype 进行。 他们发现随着他们的成长，他们需要更多的过程。 - * 开发人员在本地进行开发，并将代码提交到 Unfuddle 中。 - * Hudson 被用作他们的持续集成环境。 Hudson 使他们从旧系统到新 Glassfish 系统的迁移更加容易，因为必须在部署之前通过测试。 他们并没有浪费太多时间，因为在生产部署之前就发现了问题。 - * 他们有很多测试：单元测试，系统测试，Drupal 测试。 只有当 Hudson 通过了这些测试时，才能部署系统。 - * 仍然可以手动进行部署，以减少潜在的停机时间。 - * 每当他们发现垃圾回收时间出现问题时，这总是归因于其应用程序中的内存泄漏。 万一发生内存泄漏，他们将进行核心转储。 要从 16GB 的计算机分析核心转储不是那么容易，您可能无法在本地计算机上对其进行分析，因此他们要做的是在 Amazon 上租用一个大内存实例来分析转储。 处理堆转储大约需要 2 个小时。 他们比较了两个转储，一个在执行时间 10 小时后，另一个在执行时间 20 小时后。 如果存在重大差异，则可能是由于内存泄漏。 - -## **未来方向** - -* Mollom API 使用 XML-RPC，他们现在正在测试 REST 实现，以使服务更易于使用 Mollom 进行混搭。 -* 现在，他们已经过渡到 Cassandra，在增长需要时，他们可以更轻松地进行横向扩展。 -* 即将发布的企业功能可以将数百个网站作为一个单元进行管理。 通过情绪，垃圾邮件分数或从某些 IP 地址删除所有评论，很容易在一组网站上进行审核。 -* 他们已经进行了有关进入 Twitter 等流数据业务的讨论，但受到欧洲更加严格的隐私政策的限制。 -* 他们将使用 Glassfish 进行实验，以平衡每个数据中心的负载。 -* 如果负载增加 10 倍，则必须添加更多的 Cassandra 节点。 磁盘 IO 是瓶颈。 仅当它们的增长速度必须超过 10 倍时，才需要添加更多的应用程序服务器。 - -## 经验教训 [ - -* ****效率带来幸福。** Mollom 非常重视高性能工程。 他们为 Mollom 极具成本效益而感到自豪。 它可以在一台服务器上处理许多请求，而延迟时间很短，这使客户感到满意，这使他们感到满意，因为他们不必维护大量机器，而且成本很低。 他们从一开始就将其作为优先事项，并选择了正确的技术来实现其目标。 这样一来，他们就可以利用自己赚的钱，在营销，建立用户群以及在 Mollom 之上开发新产品方面进行投资。** -* **广度免费，付出深度**。 机器学习需要大量示例数据才能成功检测到垃圾邮件。 为了获得这些数据，Mollom 为客户提供了免费的服务，他们提供了更好地训练学习算法所需的广泛数据，他们是不断提供情报和反馈的来源。 较大的客户不仅提供收入，而且还可以从免费客户那里学到的数据受益。 该模型似乎是大数据和机器学习所特有的，众所周知，这是一切的未来。 -* **移除非特定领域的障碍物**。 大型系统需要大量基础架构工作。 基础架构的工作通常使工作不再涉及与产品的真正价值产生领域相关的功能（分类器，信誉系统，客户端库）。 Mollom 有意识地尝试通过选择 Cassandra 和 Glassfish 来尽可能地摆脱基础设施业务。 -* **注意客户端代码**。 客户端代码很有吸引力，因为它使用别人的资源而不是您的资源。 问题在于代码编写得不好，这会使您的系统看起来很糟糕。 与客户开发人员紧密合作，并提供高质量的参考代码示例，以便开发人员可以学习最佳实践。 -* **优先考虑付费客户**。 付费客户可以获得更好的服务质量。 它们首先在队列中处理，并且减少了整个系统的延迟。 付费客户可以访问故障转移服务器，而免费客户只能使用一台服务器。 -* **通过让堆栈进行繁重的操作**来减少代码。 在早期，Mollom 代码库比现在大得多。 Cassandra 通过处理复制和行缓存删除了许多复杂的代码，Glassfish 删除了许多应用程序代码，并将处理集群。 随着时间的推移而简化。 -* **最小化锁争用**。 Mollom 花了很多时间来减少 Glassfish 服务器中的锁争用，因为这已成为主要瓶颈。 尽可能少地锁定即可保持完全的并行性。 - -## 相关文章 - -* [Mollom API](http://mollom.com/api) -* [Mollom Drupal 模块](http://drupal.org/project/mollom) -* [Mollom 技术白皮书](http://mollom.com/files/mollom-technical-whitepaper.pdf) -* [Mollom 的 Twitter 帐户](http://twitter.com/#!/mollom) -* [第 072 集-Mollom.com 的 GlassFish 后端，带有 Dries 和 Johan](http://blogs.sun.com/glassfishpodcast/entry/episode_072_mollom_com_s) -* [Mollom 获得了一个新的后端](http://buytaert.net/mollom-gets-a-new-backend) -* [在 Glassfish 上用 Mollom 打击垃圾邮件](http://blogs.lodgon.com/johan/) -* 要了解有关大数据和机器学习的更多信息，请查看 [Strata Conference](http://strataconf.com/strata2011/public/schedule/proceedings) 中的一些资料。 - -好帖子！ - -我想念什么吗？ 100 rps 令人印象深刻吗？ - -托德 - -首先，我是该网站的忠实拥护者，我会定期关注您的帖子。 - -我喜欢这篇文章，但是每秒的请求引起了我的注意。 我很好奇您认为“高吞吐量”服务。 我问是因为我是 Proxomo 的首席软件架构师（http://www.proxomo.com）。 我们的负载测试已在两台服务器（在 Microsoft Azure 上运行）上以每秒超过 500 个请求的速度为 REST 服务提供时钟。 - -谢谢 -Daniel ..... - -丹尼尔，您好，如果您想谈谈您的架构，请给我发电子邮件。 关于您的问题，我认为没有任何特定的阈值定义“高吞吐量服务”。 Mollom 给我留下了深刻的印象，因为它们有一个复杂的机器学习应用程序，可以在一台（大型）机器上运行，它们遵循严格的质量和性能指标，它们是可盈利的，并且它们以正确的方式做事。 有很多人在创建应用程序，不是每个人都是 Google，所以我真的很喜欢这些提供真正价值的更人性化服务的示例。 - -垃圾邮件取决于上下文。 如果我经营一个科技网站，那么政治评论就是垃圾邮件。 如果我经营一个政治网站，那么技术评论就是垃圾邮件。 如果使用“从用户那里获得的所有反馈”对 Mollom 进行培训，如何避免出现问题？ - -如何将其整合到 Drupal 中？？？ \ No newline at end of file +因此，他们有社会责任限制每天比赛的次数，但是如果您为服务付费，您仍然可以做到吗？ 他们的道德晴雨表似乎有问题。 \ No newline at end of file diff --git a/docs/191.md b/docs/191.md index aca3caf..440df88 100644 --- a/docs/191.md +++ b/docs/191.md @@ -1,73 +1,243 @@ -# Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表 +# 如何使用微服务建立财产管理系统集成 -> 原文： [http://highscalability.com/blog/2011/1/10/riaks-bitcask-a-log-structured-hash-table-for-fast-keyvalue.html](http://highscalability.com/blog/2011/1/10/riaks-bitcask-a-log-structured-hash-table-for-fast-keyvalue.html) +> 原文： [http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html](http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html) -![](img/a2a15972237545b2b84c06482305506b.png) +![](img/3331efa5e2d1a2cad2f4cfa4f1aeb70f.png) -如果从头开始，您将如何实现键值存储系统？ Basho 使用 [Bitcask](http://downloads.basho.com/papers/bitcask-intro.pdf) （他们的 Riak 的新后端）决定采用的方法是一种有趣的组合，使用 RAM 存储指向值的文件指针的哈希映射和用于高效写入的日志结构文件系统。 在这次出色的 [Changelog 采访](http://thechangelog.com/post/1525527959/episode-0-4-0-riak-revisited-with-andy-gross-mark-philli)中，来自 Basho 的一些人更详细地描述了 Bitcask。 +*This is a guest post by Rafael Neves, Head of Enterprise Architecture at [ALICE](http://info.aliceapp.com), a NY-based hospitality technology startup. While the domain is **Property Management, it's also a good microservices intro.* 在零散的款待系统世界中，集成是必不可少的。 您的系统将需要与来自不同提供程序的不同系统进行交互，每个提供程序都提供自己的应用程序接口（API）。 不仅如此，而且当您与更多的酒店客户整合时，将需要更多的实例来连接和管理此连接。 物业管理系统（PMS）是任何酒店的核心系统，随着行业变得越来越紧密联系，集成至关重要。 -基本的木桶： +为了在酒店业提供软件解决方案，您肯定需要与 PMS 提供者建立 2 路集成。 挑战在于大规模建立和管理这些连接，并在多个酒店中使用多个 PMS 实例。 您可以采用几种方法来实现这些集成。 在这里，我提出一种简单的架构设计来构建集成基础，随着您的成长，该基础将增加 ROI。 这种方法是微服务的使用。 -* 密钥存储在内存中以便快速查找。 所有密钥必须适合 RAM。 -* 写操作仅是追加操作，这意味着写操作严格是顺序执行的，不需要查找。 写是直写的。 每次更新值时，都会附加磁盘上的数据文件，并使用文件指针更新内存中的索引。 -* O（1）随机磁盘搜寻可满足读取查询的需求。 如果所有密钥都适合内存，则延迟是非常可预测的，因为不会在文件中四处寻找。 -* 对于读取，将使用内核中的文件系统缓存，而不是在 Riak 中编写复杂的缓存方案。 -* 旧值将被压缩或“合并”以释放空间。 Bitcask 具有[窗口合并](http://blog.basho.com/2011/01/05/riak-0.14-released/)： *Bitcask 对所有非活动文件执行定期合并，以压缩旧版本存储数据占用的空间。 在某些情况下，这可能会导致进行合并的 Riak 节点上的某些内存和 CPU 峰值。 为此，我们添加了指定 Bitcask 何时执行合并的功能。* -* 通过 Bitcask 上方的[软件层，使用](http://wiki.basho.com/An-Introduction-to-Riak.html)[向量时钟](http://blog.basho.com/2010/01/29/why-vector-clocks-are-easy/)实现获取和设置并发。 -* 值索引的键存在于内存中以及提示文件中的文件系统中。 数据文件合并时生成提示文件。 重新启动时，仅需要为非合并文件重建索引，该文件应占数据的一小部分。 +## 什么是微服务？ -Eric Brewer（CAP 定理）通过考虑您是否有能力将所有密钥保存在内存中（这在现代系统中很有可能），使 Bitcask 产生了想法，您可以相对容易地设计和实现存储系统。 [提交日志](http://wiki.apache.org/cassandra/Durability)可用作数据库本身，提供了原子性和持久性。 只需写入一次即可保留数据。 单独写入数据文件，不需要提交日志。 +企业软件设计的思想领导者 Martin Fowler 提供了微服务的全面定义[：](http://martinfowler.com/articles/microservices.html) -值更新后，首先将其附加到磁盘提交日志中。 然后，将键映射到磁盘指针的内存中哈希表将更新为指向文件和文件中记录的偏移量。 因此，读取仅需要一个文件 I / O。 哈希键可找到文件指针，您只需查找偏移量并读取该值。 对于写入，它只是文件的追加。 很漂亮 在纯内存数据库和虚拟存储层支持的基于磁盘的数据存储之间，这是一个很好的折衷方案。 +> 在过去的几年中，出现了“微服务体系结构”一词，用于描述将软件应用程序设计为可独立部署的服务套件的特定方式。 尽管没有对此架构风格的精确定义，但围绕业务能力，自动部署，端点中的智能以及对语言和数据的分散控制，组织周围存在某些共同特征。 -一些潜在的问题： +本质上，微服务是很小的软件组件，专注于真正做好一件事情。 不必编写一个大型的整体应用程序，而是可以使用微服务将其分解，每个微服务在给定的域中管理一个集中的功能。 -* 如果您怀疑密钥的数量将超过 RAM，那么将工作集保留在内存中的体系结构将是一个更好的选择。 -* 它比纯内存数据库要慢。 -* 问题通常在垃圾回收阶段作为资源高峰而出现，同时回收用于删除值的空间。 Bitcask 希望通过将垃圾收集的调度安排到特定时期来降低成本，尽管在拥有国际用户的 24x7 物业中，这可能还不够。 -* 在每次写入时进行同步可能会有些痛苦。 如果将写入缓冲并同步复制到备份节点以提高可用性，则可以提高写入吞吐量。 -* 我不相信操作系统缓存。 操作系统缓存不知道您的访问模式。 自定义缓存可能会带来复杂性，但是很难相信当出现问题时它的性能不会更好或无法调整。 Basho 似乎对这种方法感到满意，但仍然让我感到不安。 如果流量具有均匀分布或类似 pareto 的分布，会发生什么？ 对您的应用进行基准测试！ +因此，它们是自治的，彼此独立执行。 因此，对一项服务的更改不应要求对另一项服务的更改。 随着您的成长和进行更改，您无需担心会影响其他微服务。 -## **相关文章** +微服务是： -* [变更日志采访](http://thechangelog.com/post/1525527959/episode-0-4-0-riak-revisited-with-andy-gross-mark-philli)，其中描述了 [Bitcask](http://downloads.basho.com/papers/bitcask-intro.pdf) 。 -* [Bitcask-Justin Sheehy 和 David Smith 编写的用于快速键/值数据的对数结构哈希表](http://downloads.basho.com/papers/bitcask-intro.pdf)，灵感来自 Eric Brewer。 -* [Redis Diskstore](http://groups.google.com/group/redis-db/browse_thread/thread/d444bc786689bde9) 。 这是 Redis 的操作方式。 -* [RethinkDB 内部：缓存体系结构](http://www.rethinkdb.com/blog/2011/01/rethinkdb-internals-the-caching-architecture/#)。 这是 RethingDB 的工作方式。 -* [Bitcask Rocks](http://pl.atyp.us/wordpress/?p=2868) ，作者：Jeff Darcy。 *至少对于这些简单测试而言，Bitcask 的性能与广告中所宣传的相同。 如果不进行调整，则读写操作似乎都在摊销大量操作的查找成本。* -* [克服 I / O 瓶颈：J Ousterhout 的日志结构文件系统](http://www.google.com/url?sa=t&source=web&cd=3&ved=0CCoQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.37.9531%26rep%3Drep1%26type%3Dpdf&ei=n8ckTcS1O46WsgObqPCDAg&usg=AFQjCNFxzphJrEx281Sm9nZuA7iQR1XpBg&sig2=16OP4cTwBPgjjUp1B5Qx4Q)案例 -* [Riak SmartMachine 基准测试：技术细节](http://joyeur.com/2010/10/31/riak-smartmachine-benchmark-the-technical-details/) -* [P O'Neil 的日志结构化合并树（LSM-Tree）](http://www.google.com/url?sa=t&source=web&cd=2&ved=0CB0QFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.44.2782%26rep%3Drep1%26type%3Dpdf&ei=780kTdPyGI7ksQPAvMzNAQ&usg=AFQjCNGGoN9IFTLShcv2HbL0RVQdElfxow&sig2=kO9xiGo1mgbywgsRpPi4Kg) -* [该死的凉爽算法：日志结构化存储](http://blog.notdot.net/2009/12/Damn-Cool-Algorithms-Log-structured-storage)，作者：Nick Johnson -* [HBase Architecture 101-Lars George 的预写日志](http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead-log.html) -* [Cassandra Wiki 耐久性条目](http://wiki.apache.org/cassandra/Durability) -* [Alfred-是 node.js 的快速进程内键值存储。](http://pgte.github.com/alfred/) *Alfred 将数据存储在仅附加文件*中。 -* [Bigtable：结构化数据的分布式存储系统](http://osdi2006.blogspot.com/2006/10/paper-bigtable-distributed-storage.html) +* 小 +* 专注于 +* 松耦合 +* 高凝聚力 -“如果您怀疑您将拥有比 RAM 更多的密钥，那么在内存中保留工作集的体系结构将是一个更好的选择。” +## 为什么微服务功能强大 -是的，DB / Java（http://www.oracle.com/technetwork/database/berkeleydb/overview/index-093405.html）几乎是开箱即用的，并且与 Bitcask 具有相对相似的整体方法。 这些年来，有很多类似系统的例子，Basho 选择了基础知识，并根据自己的需求构建了一些特定的东西。 可以在 Gray 和 Reuter 的“事务处理：概念和技术”中找到许多理论（例如，扎根于 System R（http://zh.wikipedia.org/wiki/IBM_System_R））。 +微服务架构提供了很多好处。 主要优点包括： -“在每次写入时进行同步可能会有些痛苦。如果对写入进行缓冲并且将数据同步复制到备份节点以实现高可用性，则可以提高写入吞吐量。” +### 可扩展性 -好吧，如果您真正是同步的并且不想延迟等待写操作的人，则缓冲的好处有限。 实际上，许多系统都会引入延迟，以便可以进行缓冲。 同步复制到备份节点会带来一系列问题，需要适当调整网络堆栈。 您还面临着处理副本丢失的所有麻烦。 我相信，通常 Riak 会在存储层之外处理该问题。 +* 您的单个系统将与具有不同属性的多个 PMS 实例集成。 从规模上讲，当与 1000 个属性进行集成时，即使它们正在运行来自同一供应商的相同 PMS 系统，您也需要显式管理不同的 1000 个集成。 为了增加复杂性，这些实例可以来自不同的提供程序。 +* 随着您添加许多 PMS 实例和属性，它可以优雅地扩展。 如果您使用的是整体应用程序，则必须将所有内容扩展为一个大块。 在流量高峰期间，可能很难理解性能瓶颈在哪里，而对于微服务而言，透明度要高得多。 +* 当您拥有微服务时，很清楚哪些服务存在性能问题，您可以轻松调整其容量（底层硬件），而不必增加运行正常流量负载的其他服务的容量。 -“将旧值压缩或“合并”以释放空间。”-有些人可能会说这是 DB 语言中的检查点。 +### 弹性 -“我不相信操作系统缓存。OS 缓存不知道您的访问模式。自定义缓存可能会带来复杂性，但是很难相信它会在出现问题时表现不佳或变得更可调。” +* 旅馆的 PMS 实例可能已关闭或出现性能问题，这不会影响系统的性能或正常运行时间。 +* 您可以实现任意数量的微服务。 部署的次数越多，容错和对更改的管理就越多。 -自定义缓存只能在编写或更新之前知道其开发人员所看到的访问模式。 换一种说法，任何高速缓存的性能仅与到目前为止公开和调整的访问模式集一样好。 随着时间的流逝，操作系统缓存已暴露于许多不同的访问模式，并且在大多数情况下都表现出合理的平衡。 我确定在特定情况下自定义缓存会更好，但是 Riak 工作负载是否足够具体/可预测？ 可能不是现在，也许以后。 +### 技术堆栈独立性 -我忘了说了，电池保护的写缓存之类的东西是使磁盘同步更便宜的另一种方法。 +* 您可以具有多个技术堆栈； 每个服务都将拥有最适合的技术堆栈。 您的访客配置文件可能在关系数据库中，而他们的请求可能在 NoSQL 数据库中。 +* 对特定技术栈没有长期的承诺； 毕竟，您可以拥有多个。 -在[文章](http://www.varnish-cache.org/trac/wiki/ArchitectNotes)中比较了 Squid 和 Varnish 的体系结构，作者声称自定义内存管理会因分页而影响性能。 考虑到这一点，他建议您最好将其留给操作系统。 +### 添加，更改或终止功能&重构 [ -这些论点对这里讨论的情况也无效吗？ +* 微服务非常小（通常只有几百行代码）。 +* 由于代码具有内聚性，因此更容易理解：它可以做一件事。 +* 对其所做的更改不会直接影响其他服务。 +* 删除整个微服务更容易，并且不会对整个系统造成风险 -@Hugh Redis 开发人员现在正在考虑他先前决定绕过操作系统页面缓存的决定-https://groups.google.com/d/topic/redis-db/1ES8eGaJvek/discussion +### 部署方式 -去年，我曾提醒他有关那篇不错的 Varnish 文章-请在此处查看评论＃29 http://antirez.com/post/redis-virtual-memory-story.html +* 酒店希望提供卓越的服务。 如果您的系统已关闭或未提供其所有功能（例如，不将来宾登机请求推送到您的 PMS 或从中读取更新），他们将无法交付它。 +* 回滚也更容易。 如果出了问题，回滚一个带有自己数据库的微服务要比回滚一个单个数据库的整个系统要容易。 +* 部署单片应用程序的下一版本时，总是很麻烦：即使您仅添加了一个功能，也必须立即部署整个应用程序。 一起部署所有内容都是有风险的。 ， -好吧，有些人喜欢刻苦学习；-) +请记住，如果仅集成一个 PMS，则微服务是一个过大的杀伤力。 如果要与具有 1000 个不同属性的 1000 个 PMS 实例集成，那么该体系结构的好处就显而易见了。 -与矢量时钟的链接已断开。 正确的链接应该是 http://basho.com/posts/technical/why-vector-clocks-are-easy/ \ No newline at end of file +## 传统方法：单片应用程序 + +借助传统方法（整体应用程序）开始您的业务并开始新产品是很有意义的，因为它更容易。 目前，您仍在学习有关域以及域如何集成的信息。 + +整体更易于开发和部署，采用整体方法，则更容易回答诸如如何建模预订服务以及如何在访客配置文件微服务中实现访客对帐操作之类的问题。 + +但是，就像您的公司一样，整体式增长非常迅速，并且随着系统的增长，很难扩展： + +添加了新功能，推出了新的代码行，并且当系统变得太大时，它变得难以驯服和理解。 更改系统需要进行严格的回归测试，以确保新功能不会破坏系统的其他部分，因为整体应用程序通常不具有内聚力，也没有松散耦合。 + +故障排除和调试更加困难，因为存在更多具有更多相互依赖性的代码。 更新服务可能需要更改共享的基础结构代码，并且在引入错误时可能导致感染。 庞大的代码库使新手开发人员难以入职和培训。 + +它影响部署：应用程序越大，启动时间就越长。 是的，您可以简单地添加更多服务器并在所有服务器上复制应用程序，但是您仍然只有一个数据库。 不仅如此，系统的某些部分可能会更占用内存，而其他部分则需要大量 CPU。 那么，当您无法分别缩放每个组件时该怎么办？ 您添加更多服务器！ + +这是非常昂贵的。 这样，一旦您对域有了更好的了解，就可能想要开始将系统分解为微服务。 + +## 架构概述 + +现在，我们已经解释了采用微服务架构的长期好处，让我们研究一下如何设计微服务框架的一些细节： + +这里的关键是隔离：集成的系统应该彼此独立运行。 IE：您的核心系统独立于在属性 X 上运行的属性管理系统，并且独立于在属性 Y 上运行的系统。 + +可以通过在核心系统和要与其集成的所有资产管理系统之间引入连接器（中间件）来实现这种隔离。 + +中间件由消息队列和后台工作者组成： + +* 可用于实现的服务示例： + * 消息队列：RabbitMQ，IronMQ 等。 + * 背景工作者：IronWorker，AWS Lambda 等。 + +消息队列提供系统之间的异步通信。 发件人系统（例如您的系统）将消息发布到队列中，并一直位于该队列中，直到后台工作人员（订阅该队列）在以后处理该消息为止。 + +然后，后台工作者负责处理消息（解析其内容），然后管理与 PMS API 的集成。 同样，它将数据保存到中间件数据库中。 + +请记住，后台工作人员可以是像 AWS Lambda 这样的云服务，也可以是内部用 Java 开发的应用程序，也可以是在 Windows 服务中开发的应用程序。 正如我们将在下面详细介绍的那样，微服务的技术堆栈并不重要。 + +请记住，一个消息队列保证 FIFO（先进先出），因此队列中的所有消息都按照它们进入的顺序进行处理。如果您有多个队列，则会将一条消息发布到队列中 可以比发布到队列 Y 的消息更早地处理 X，这在您的设计中应予以考虑。 + +另外，尽管 PMS 可能位于酒店的内部，但您的系统也不一定要位于云中或内部。 + +请记住，此服务控制与预订关联的所有生命周期事件，因此它不仅是 CRUD 包装器。 如果您需要为该预订分配房间，添加陪同客人或什至办理入住手续，您将向该工作人员发送适当的请求。 + +现在让我们根据 Martin 的描述来分析微服务的每个主要特征，以及我们的架构如何实现它们： + +## 1-围绕业务能力的组织 + +每个工作人员都实现了与 PMS 集成的部分逻辑。 您可以将多个工作人员插入到属性中的同一 PMS 实例中，在其他酒店中添加更多连接到同一属性管理系统（同一供应商）的工作人员，还可以在以下位置添加连接到不同属性管理系统（不同供应商）的其他工作人员 其他属性。 + +因此，假设您需要更改与某些 API 方法的交互方式，则只需要将新版本部署到其中一个工作程序，而不会影响其他工作程序。 您可以让一个工人来处理预订，另一个可以来宾。 + +可以在 Linux crontab 中安排一些后台工作程序，以按照给定的时间表重复执行。 其他消息始终在运行，在到达队列时处理消息。 其他后台工作人员也可以回调您的核心系统 API，以插入或更新从 PMS 收集的新信息（即，从 PMS 读取/读取数据并将其加载到您的核心系统中）。 + +在萨姆·纽曼（Sam Newman）撰写的 *Building Microservices* 一书中，他指出“在较小代码库上工作的较小的团队往往生产力更高。”这是通过微服务实现的 + +它不仅可以提高生产率，还可以使团队或个人从一种微服务转移到另一种微服务（代码库的通用共享）。 + +它也可以促进创新，因为长期从事同一项目的个人或团队可能只会提出有限范围的新想法。 而如果您允许您的团队在产品和项目之间切换，他们可能会提出成千上万个新想法。 + +## 2-自动部署 + +微服务需要以自动化方式进行部署。 为什么？ 首先，因为您有很多。 如果必须手动部署它们中的每一个，这将很容易出错并且非常耗时。 这取决于您拥有的微服务数量。 您可以彼此独立地分别释放每个服务。 + +请注意，我的意思是在此处将新版本部署到微服务，而不是分解新的工作程序实例。 您已经在运行工作程序，但是您想部署新版本的代码。 让我们用一个例子说明一下： + +* 假设您必须与 1000 个属性集成，其中 500 个属性使用供应商 1（PMS_1）的 PMS，其中 500 个属性使用供应商 2（PMS_2）的 PMS。 +* 由于无论 PMS 供应商如何，这里的域上下文都非常相似，因此每个 PMS 实例将很可能具有相似数量的工作线程，除非您希望通过添加更多相同类型的工作线程来扩展给定的连接。 简单来说，假设每个 PMS 实例有 5 个工作线程（一个用于保留，一个用于来宾配置文件，等等）。 +* 由于 PMS_1 API 与 PMS_2 API 不同，因此与 PMS_1 集成的保留服务的代码与与 PMS_2 集成的保留服务的代码不同。 +* 在 1000 个属性上，您有 5000 个工人，然后： + * 2500 名 PMS_1 员工 + * 500 名预订工人，每个属性中带有 PMS_1 的一名 + * 500 位访客资料工作人员，每个属性中带有 PMS_1 的一名 + * 500 名 X 工人，每个属性为 PMS_1 的一名工人 + * 500 名 Y 工人，每个属性为 PMS_1 的工人 + * 500 名 Z 工人，每个属性中带有 PMS_1 的工人 + * 2500 名 PMS_2 员工 + * 500 名预订工人，每个属性中带有 PMS_2 的一名 + * 500 位访客资料工作人员，每个属性中带有 PMS_2 的一名 + * 500 名 X 工人，每个属性为 PMS_2 的一名工人 + * 500 名 Y 工人，每个属性为 PMS_2 的工人 + * 500 名 Z 工人，每个资产中带有 PMS_2 的一名工人 +* 假设您对与 PMS_1 集成的 Reservation 服务的代码进行了更改，它已经过测试并且可以发布。 +* 假设您最好有一个源代码存储库，并在每个微服务中内置选择的持续集成工具，这是非常明智的选择，那么您需要将代码部署到 500 个工作程序（与 PMS_1 集成的 500 个保留工作程序）。 + +其次，微服务的目的之一是要具有敏捷性，并且要具有敏捷性，您需要自动化。 这就是持续集成（CI）和持续交付（CD）的神奇之处： + +CI 是一种开发实践，要求开发人员一天几次将代码集成到共享存储库中。 然后，提交触发构建。 如果构建失败，则每个人都会收到警报（原则上会发出偏差警报）。 此处的关键是尽早确定提交问题（即代码问题）。 如果构建成功，则可以将其部署到您的应用程序服务器。 这导致我们实现持续交付： + +连续交付是确保成功构建的工件可以快速部署到生产中的一种做法。 这是通过首先将您的应用程序部署到暂存环境（具有与生产环境相同的特征）来实现的。 只需按“部署”按钮，就可以将应用程序部署到生产环境中。 最好的是，因为它只是一个按钮，所以您无需中断软件工程师的工作。 + +* 可用于实现 CI / CD 的服务示例：Atlassian Bamboo，TeamCity，Jenkins 等。 + +虽然，请不要将持续交付与持续部署混淆。 我不会在这里详细介绍它，但是我留下了 PuppetLabs 的[很棒的文章](https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff)，关于持续交付和持续部署之间的区别。 + +还应注意，微服务的部署比单片应用程序安全得多，这应有助于自动化。 + +## 3-端点的智能 + +后台工作人员封装了如何与 PMS 集成的逻辑。 如果我们需要更改逻辑或 PMS API 已更改，我们只需要在一个地方更改-它不在您的主系统中（将其与对下游 API 的更改隔离开来）。 + +另外，每个 PMS 都有自己的 API，因此您可以隔离与核心系统中的每个 API 进行通信的逻辑。 + +## 4-语言和数据的分散控制 + +每个微服务可以拥有自己的技术堆栈。 让您拥抱技术的异质性。 + +例如：如果我们需要提高特定组件的性能，则可以选择能够实现所需性能的其他技术堆栈。 新服务不依赖于较早的技术定义，而是在适当时利用新的语言或技术。 + +每个工作程序可以使用不同的技术构建：工作程序 1 可以使用 Java 开发，带有 MySQL 数据库以处理来宾配置文件，而工作程序 2 可以使用 C＃开发，具有 NoSQL DB 来处理来宾消息。 记住：他们是独立的。 + +您需要担心它们的集成，即它们之间如何实际通信。 您将实现返回 JSON 的 RESTful API 还是使用 XML 的 SOAP API？ + +现在，让我们更深入地研究中间件。 + +## 中间件 + +中间件提供了系统与要集成的多个属性管理系统之间的隔离。 它由消息队列和后台工作者组成。 + +中间件不应保持状态：两端的系统（即您的系统和 PMS 系统）负责保持有关酒店，访客资料，预订等的状态。中间件只是在两者之间创建映射。 这样做的原因是，您不想引入一个新的组件，该组件也存储可能导致一致性问题的状态：您将在 3 个不同的系统（酒店物业管理系统）中存储相同的实体（例如，预订）。 ，中间件和核心应用程序），并且由于集成中的某些错误，它们可能会有所不同。 在这种情况下，谁持有关于保留真实有效状态的真相？ + +中间件必须提供允许您协调核心系统中的内容与 PMS 中的内容的方法。 因此，如果在核心系统中创建了新请求，但是由于某种原因（实例处于脱机状态，软件错误，网络问题等），则该请求未保存到 PMS 中（例如，向来宾作品集收费） ），中间件应提醒用户该问题并提供重新处理集成的方法。 它必须提供清晰的视图，以显示每个消息在队列中的位置以及每个后台工作人员的状态。 它必须允许您查看给定消息失败及其失败的原因，并提供重试（重新处理）给定消息的机制。 + +您可以在中间件数据库的顶部具有一个缓存层，以便更快地访问常见对象，例如城市代码，信用卡类型等。 一些财产管理系统将此作为具有键-值对的枚举来实现。 可用于提供缓存层的工具示例包括：自托管 Redis，托管 Redis 解决方案（例如 AWS Elasticache），Memcache。 + +## 使用微服务的挑战 + +在构建任何软件时，尤其是在大规模集成系统中，总是存在挑战。 + +纽曼在《构建微服务》一书中提醒我们，“故障成为大规模的统计确定性”，而在实现微服务时（这是整体的）肯定是这种情况。 + +接受一切都会失败（硬盘，网络等）并接受这一事实，很难处理多个独立服务的失败。 + +分布式和异步体系结构难以实现且难以调试。 您需要查看散布在多个实例中的日志，并查看分布式事务性，以了解为什么最终会出现古怪的状态。 如果在同步工作流的中间发生错误，则很难回滚状态。 了解故障发生的位置非常困难，因为工作可能并行进行，并且可能引入了难以管理的竞争条件。 + +确保与微服务的大规模一致性是另一个挑战。 想象一下，您有一个管理来宾个人资料的服务，另一个服务来管理预订。 如果新客人首次在您的酒店预订了预订，则预订微服务将创建新的预订记录，而客人资料微服务将需要创建新的客人资料。 如果访客个人资料存在错误并且未成功创建新的访客个人资料怎么办？ 如果管理不正确，最终将导致一个孤立的预订，该预订未绑定任何访客个人资料。 从规模上讲，这可能很难跟踪和管理。 + +异步分布式体系结构可能会导致其他问题。 让我们想象一下系统发送到事务处理队列的某种类型的请求会使您的工作人员崩溃。 另外，假设您添加了多个工作程序，它们从同一队列中提取消息以加快处理速度。 第一个工作人员从队列中提取消息，然后死亡。 当它死亡时，对请求的锁定将超时，并将原始请求消息放回到队列中。 然后，您的下一个工作人员将从队列中提取相同的消息并获得相同的结果：消息将死亡。 + +另一个挑战是，您将不得不监视不断重新部署的数百种服务。 这将促使需要专用的 DevOps 资源或团队来管理大量服务。 + +由于您有许多通过网络进行的远程呼叫，因此还需要考虑整体系统性能。 众所周知，网络不可靠：数据包可能会延迟，丢失等。此外，系统之间的消息不是实时流动的：您将消息发布到队列中，然后在（ 不久），它将得到处理。 + +最后，使用微服务很难有效地实现版本控制：您最终将更改服务的接口。 您将如何处理？ + +使用每种架构方法都需要权衡。 尽管微服务存在挑战，但是每种方法都存在挑战。 当大规模管理多个 PMS 集成时，使用微服务的好处远远超过成本。 + +**考虑大规模实施的经济性：** + +以下是实现微服务时要考虑的一些比较成本： + +* 大规模部署时，100 个不同的 PMS 集成可能需要 100 个服务器。 +* 使用单片方法，这些服务器始终处于运行状态。 +* 在微服务世界中，微服务在需要时唤醒，在不需要时关闭。 +* 借助 AWS Lambda 或 IronMQ 等云服务，您需要为 CPU 时间而非服务器时间付费。 +* 当采用按需供应系统（如 Amazon Web Services 提供的系统）时，我们可以根据需要对需要的那些组件应用此扩展。 这使我们能够更有效地控制成本。 ， + +因此，随着时间的流逝，微服务在为计算能力付费时会更具成本效益，因为有需求可以使您更紧密地管理成本并最终减少浪费。 很少有一种架构方法可以与几乎立即节省成本紧密相关。 + +那么，从这里去哪里呢？ + +## 拆解整体结构 + +我经常听到的一个常见问题是：“我已经构建了整体应用程序。我是否需要从头开始重新构建它以实现微服务架构？” + +简单的答案是：**否**。 + +长的答案是，您可以将您的整体碎片分开。 它应该是一种渐进的方法，以便您可以了解有关核心功能以及它如何与其他核心功能交互的更多信息。 这对于您了解服务应该是什么以及它们如何相互通信至关重要。 采取“边走边学”的方法，逐步定义系统的哪些部分应成为微服务。 我将在以后的文章中保留有关如何设计和实现此策略的详细信息。 + +我希望这可以解释其好处或使用微服务方法来构建 PMS 集成。 随着您的系统和微服务数量的增长，这种方法将帮助您以更灵活，高效和经济高效的方式进行扩展。 + +## 相关文章 + +* [关于 HackerNews](https://news.ycombinator.com/item?id=11074151) +* [微服务-不是免费的午餐！](http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html) +* [伟大的微服务与 Monolithic Apps Twitter 近战](http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html) +* [来自 Google 和 eBay 的关于建立微服务生态系统的深刻教训](http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html) +* [生产中的微服务-好的，坏的，有效的](http://highscalability.com/blog/2014/10/27/microservices-in-production-the-good-the-bad-the-it-works.html) +* [微服务中最讨厌的七个反模式](http://highscalability.com/blog/2015/8/3/seven-of-the-nastiest-anti-patterns-in-microservices.html) +* [改变一切的融合：数据重力+容器+微服务](http://highscalability.com/blog/2015/3/25/the-convergence-that-changes-everything-data-gravity-contain.html) +* [我们如何构建更好的复杂系统？ 容器，微服务和持续交付。](http://highscalability.com/blog/2015/4/27/how-can-we-build-better-complex-systems-containers-microserv.html) + +诸如此类的技术是使物业管理更加有效和高效的好方法。 我们希望将来能看到更多诸如此类的技术创新。 感谢您分享本文，这是设置此集成的不错的教程。 \ No newline at end of file diff --git a/docs/192.md b/docs/192.md index 6f921b7..13cd4fc 100644 --- a/docs/192.md +++ b/docs/192.md @@ -1,29 +1,625 @@ -# BankSimple 迷你架构-使用下一代工具链 +# Egnyte 体系结构：构建和扩展多 PB 分布式系统的经验教训 -> 原文： [http://highscalability.com/blog/2011/1/6/banksimple-mini-architecture-using-a-next-generation-toolcha.html](http://highscalability.com/blog/2011/1/6/banksimple-mini-architecture-using-a-next-generation-toolcha.html) +> 原文： [http://highscalability.com/blog/2016/2/15/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2016/2/15/egnyte-architecture-lessons-learned-in-building-and-scaling.html) -![](img/8a0930329cebce312e044432d002bf09.png) +![](img/6c80e21424564200e0ef4dac300da8ff.png) -I know people are always interested in what others are using to build their systems. [Alex Payne](http://al3x.net/), CTO of the new startup [BankSimple](https://banksimple.com/), gives us a quick hit on their toolchain choices in this [Quora thread](http://www.quora.com/What-languages-and-frameworks-is-BankSimple-built-with/answer/Alex-Payne). BankSimple positions itself as a customer-focused alternative to online banking. You may remember Alex from the [early days of Twitter](http://venturebeat.com/2010/05/17/twitter-alex-payne-bank-simple/). Alex was always helpful to me on Twitter's programmer support list, so I really wish them well. Alex is also a bit of an outside the box thinker, which is reflected in some of their choices: +*这是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的来宾帖子，他是在家工作的建筑师。 他和他的同事们花费大量的工作时间扩展了那里最大的分布式文件系统之一。 他在 [Egnyte](https://www.egnyte.com/) （一家企业文件同步共享和分析启动）中工作，您可以在 [@kpatelwork 与他联系 ]](https://twitter.com/kpatelwork) 。* -* JVM 充当这些语言的融合平台： - * **Scala** -是编写对性能敏感的组件的理想选择，这些组件需要语言高级类型系统的安全性和可表达性。 - * **Clojure** -以更动态的语言快速原型化，同时仍提供函数式编程的优点。 - * **JRuby** -提供了许多出色的库和框架来进行前端 Web 开发，例如 Rails 和 Padrino。 -* **前端**：JavaScript 端的 MooTools。 -* **数据存储**：尝试使用 Postgres 9.0 和 Riak。 -* **平台**：Amazon EC2 +您的笔记本电脑有一个文件系统，该文件系统被数百个进程使用，它受到磁盘空间的限制，无法弹性扩展存储，如果您运行很少的 I / O 密集型进程或尝试与 100 个其他用户共享它，它会很麻烦。 现在解决这个问题，并将其放大为遍布全球的数百万付费用户使用的文件系统，您将可以通过云霄飞车扩展该系统，以满足每月的增长需求并满足 SLA 要求。 -您典型的 Web 启动并不使用 Scala，Clojure 和 JRuby。 你应该？ 如果您正在寻找一种尝试去尝试一些不同的东西，也许就是这样。 毕竟，将不同的语言用于不同的目的与将不同的数据库用于不同的目的一样有意义。 +**Egnyte 是一家企业文件同步和共享创业公司**，成立于 2007 年，当时 Google 硬盘还没有诞生，而 AWS S3 的成本却很高。 我们唯一的选择是放开袖子，自己建立一个对象存储，S3 和 GCS 的超时成本变得合理，并且由于我们的存储层基于插件体系结构，因此我们现在可以插入任何便宜的存储后端。 我们已经多次重新架构了许多核心组件的架构，在本文中，我将尝试分享当前的架构是什么，我们学到的扩展规模的经验教训以及我们仍需改进的内容。 -## 相关文章 +## 平台 -* [节点和小比例缩放与大比例缩放](http://al3x.net/2010/07/27/node.html)，作者：Alex Payne -* [Alex Payne 在 OSCON 2010](http://www.youtube.com/watch?v=0x9k1j9s25A) 上接受了采访。 -* T [他在**雄鹿这里**](http://www.carnegiemellontoday.com/article.asp?aid=977&page=0)停了下来 +* Tomcat -哇，这对初创公司来说是不同的技术堆栈，我可以理解 JRuby，但 Scala 和 Clojure 似乎是非常随机的选择。 +* MySQL -听到更多有关您的启动和将来的可伸缩性的信息，将非常高兴。 +* HAProxy -至少在 IE 中，没有任何链接在其 Beta 网站上起作用。 希望银行应用程序会做得更好;-) \ No newline at end of file +* Nginx + +* Memcached + +* Apache + +* [Elasticsearch](https://www.elastic.co/) + +* Redis + +* RabbitMQ + +* CentOS + +* 人偶 + +* 新遗物 + +* AppDynamics + +* ZooKeeper + +* LDAP + +* Nagios + +* 石墨 + +* 仙人掌 + +* Apache FTP 服务器 + +* OpenTSDB + +* Google BigQuery + +* Google BigTable + +* Google Analytics + +* MixPanel + +* 表格 + +* ReactJS /主干/木偶/ jQuery / npm / nighwatch + +* Rsync + +* [PowerDNS](https://www.powerdns.com/) + +* 服装 + +* 基于 REST API 的 SOA 体系结构。 + +* Java 用于驱动核心文件系统代码 + +* Python 通常用于驱动大多数客户端代码，迁移脚本，内部脚本。 一些 python 代码仍然驻留在服务器上，但是由于我们有更多的 Java 熟悉和扩展经验的服务器开发人员，大多数 python 代码已迁移到 Java。 + +* 原生 Android / iOS 应用 + +* 适用于各种平台的桌面和服务器同步客户端 + +* GCE + +* GCS / S3 / Azure /...。 + +## 统计信息 + +* 3 个主要数据中心，包括欧洲的 1 个（由于安全港规定） + +* 200 多个 Tomcat 服务节点 + +* 由 Tomcat / nginx 提供支持的 300 多个存储节点 + +* 100 多个 MySQL 节点 + +* 50 多个 Elasticsearch 节点 + +* 20 多个 HAProxy 节点 + +* 和许多其他类型的服务节点 + +* 我们服务器和 GCS 中存储了数 PB 的数据 + +* 在 Elasticsearch 中建立索引的数 PB 数据内容 + +* 许多桌面客户端将文件与云同步 + +## 认识您 + +### 您的系统名称是什么，我们在哪里可以找到更多信息？ + +Egnyte 是启动公司的名称，核心系统有很多主要部分，例如 CFS（云文件服务器），EOS（Egnyte 对象存储），事件同步和...。您可以在中找到更多关于这些的内容 [对于技术人员](https://www.egnyte.com/blog/category/for-the-techies/) 部分，在我们的博客中。 + +### 您的系统是干什么的？ + +它推动了成千上万企业的同步和共享需求，而云使它们现有的文件系统可以被 FTP，webdav，移动，公共 api，Web UI 和...等各种端点使用。 + +### 您为什么决定构建此系统？ + +在 2007 年，企业/员工队伍开始变得更加分散，客户正在使用多个设备来访问相同的文件，并且有必要使这种体验尽可能的顺畅 + +### 您的项目经费如何？ + +这是一家自负盈亏的公司，后来我们在过去 8 年中进行了 5 轮募集，筹集了 6250 万美元的 [。](https://www.crunchbase.com/organization/egnyte#/entity) + +### 您的收入模式是什么？ + +我们没有免费用户，但是我们提供 15 天免费试用，之后客户无需支付席位即可付费。 + +### 您如何销售产品？ + +我们从 SEM / SEO 开始，但随着时间的增长，我们通过许多渠道为企业客户争取了诸如社交媒体，Biz 开发，贸易展览，SEM，SEO，入站营销和高联系销售的客户。 + +### 您从事这项工作多久了？ + +它成立于 2007 年，目前已有 8 年的历史。 + +### 您的系统多大？ 尝试感受一下系统的工作量。 + +我们存储数十亿个文件和多个 PB 的数据。 根据 New Relic，我们平均每秒观察到超过 2K 的 api 请求。 由于安全港规定和位置相近，我们将数据存储在 3 个主要数据中心中。 有关更多信息，请参见统计信息部分。 + +### 您的输入/输出带宽使用量是多少？ + +我没有确切的数字，因为它一直在增长，但是客户上个月下载了接近 1 PB 的压缩/未压缩数据。 + +### 您提供多少份文件？ 多少张图片？ 多少数据？ + +我们存储数十亿个文件和多个 PB 的数据。 我们存储各种文件，而我们的前 5 个文件扩展名是 pdf，doc / docx，xl​​s / xlsx，jpeg 和 png。 + +### 免费用户与付费用户的比例是多少？ + +我们所有的用户均为付费用户。 我们提供 15 天的免费试用期，之后将其转换或将其禁用。 + +### 在过去一个月中有多少个帐户处于活动状态？ + +我们所有的客户都是付费帐户，并且每个月几乎所有人都处于活动状态。 我们满足他们文件系统的需求，谁在家不用电？ + +## 您的系统如何设计？ + +### 您的系统的体系结构是什么？ + +我们使用基于 REST 的面向服务的体系结构，它使我们能够独立扩展每个服务。 这也使我们能够将某些后端服务移至公共云中托管。 所有服务都是无状态的，并使用数据库或我们自己的对象存储进行存储。 由于服务众多，因此很难将所有服务都绘制在一张图中。 + +10,000 英尺的 [典型请求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的外观如下 + +![](img/22e68ad1e1e96e52b90aa3482a2446fa.png) + +大约 10000 英尺的 [搜索架构](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下 + +![](img/fd48e5809512b072dec807353c9a0a0a.png) + +### 您的系统面临哪些特定的设计/架构/实施挑战？ + +最大的 架构 挑战包括：- + +1. 节俭地扩展文件存储 + +2. 扩展元数据访问 + +3. 文件与桌面客户端的实时同步 + +### 您是如何应对这些挑战的？ + +1. 对于存储，我们编写了自己的存储，现在我们使用可插拔的存储体系结构来存储到任何公共云，例如 S3，GCS，Azure...。 + +2. 为了扩展元数据，我们移至 Mysql 并开始使用分片。 在某个时候，我们暂时投入了更多的硬件来腾出空间，以便一层一层地剥去鳞屑洋葱。 + +3. 对于实时同步，我们必须更改同步算法，使其更像 Svn，客户端接收增量事件并尝试与云状态进行最终的一致同步。 + +4. 监视，监视和监视。 您无法优化无法衡量的内容。 在某个时刻，我们监控太多，无法专注于所有指标，我们不得不依靠异常检测工具，例如 New Relic，AppDynamics，OpenTSDB 和自定义报告，以使我们能够专注于从绿色变为[...] >黄色->红色。 目的是在客户通知 之前，将它们捕获为黄色， [时捕获它们。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) + +### 您的系统如何发展以应对新的扩展挑战？ + +我们已经多次重新构造了许多层。 我无法在本文中全部说明，但我将尝试列出过去 7 年中核心元数据，存储，搜索层的几次迭代。 + +1. 版本 1：在 Lucene 中搜索文件元数据，通过 NFS 安装在 DRBD Filers 中存储的文件，在 Lucene 中搜索。 阻塞点 ：Lucene 更新不是实时的，必须替换。 + +2. 版本 2：Berkeley db 中的文件元数据，通过 NFS 安装在 DRBD Filers 中的文件，在 lucene 中搜索。 阻塞点 ：我们突破了 NFS 的限制，它在左右两侧都阻塞了，必须用 http 代替。 + +3. Version3：Berkeley db 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 lucene 中搜索。 阻塞点 ：即使分片的 Berkeley DB 在压力下也阻塞，并且数据库崩溃，恢复工作数小时，必须更换它。 + +4. 版本 4：MySQL 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 lucene 中搜索。 阻塞点 ：公共云开始变得便宜。 + +5. 版本 5：MySQL 中的文件元数据，存储在 EOS / GCS / S3 / Azure 中并通过 HTTP 提供的文件，在 lucene 中进行搜索。 阻塞点 ：搜索开始阻塞，必须更换。 + +6. 版本 6：MySQL 中的文件元数据，通过 HTTP 服务的 EOS / GCS / S3 / Azure 中存储的文件，在 Elasticsearch 中搜索。 这是当前的体系结构，很快，其中一个可能需要另一个轮回：)。 + +### 您是否使用任何特别酷的技术或算法？ + +* 在核心服务之间进行呼叫时，我们使用 [指数退避](https://en.wikipedia.org/wiki/Exponential_backoff) 指数断路器，以避免断路器打雷。 + +* 我们在核心服务节点资源上使用公平分配分配方式来处理传入请求。 标记核心服务节点上的每个传入请求并将其分类为不同的组。 每个组都有专用的容量，如果一个客户每秒发出 1000 个请求，而另一个客户每秒发出 10 个请求，则此系统将确保第二个客户不会遇到嘈杂的邻居问题。 诀窍是，由于散列，两个客户都可能偶然巧合地落在某个节点上的同一组上，但是他们不会在所有节点上都落在同一组上，因此我们将节点名称添加为哈希值。 + +* 带有 SLA 的某些核心服务被隔离在 POD 中，这确保了一个不好的客户不会阻塞整个数据中心。 + +* 我们在桌面同步客户端代码中使用基于事件的同步，因为发生服务器事件时，它们会从服务器推送到客户端，并且客户端会在本地重播它们。 + +### 您做什么工作是与众不同的，人们可以从中学到什么？ + +专注于启动的核心功能，如果您必须构建自定义功能，则可以这样做。 有很多独特的东西，但是存储层，基于事件的同步绝对值得学习，在这里有更多详细信息。 [规范文件系统](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 + +## 您学到了什么？ + +* 您无法优化您无法测量的内容：测量所有可能的结果，然后优化系统中使用率最高为 80％的部分。 + +* 当您身材矮小的时候，请慢慢介绍技术，不要试图从中找到解决当前问题的理想工具。 编码是生命周期中最简单的部分，但是如果您最初拥有太多技术，则其维护（如部署/操作/学习曲线）将非常困难。 当您很大时，您将有足够的脂肪来划分服务，并让每个服务使用其自己的技术并进行维护。 + +* 当您是一家初创公司时，有时您需要快速采取行动，介绍您现在可以做的最好的解决方案，如果发现有牵引力，请加班对其进行重新设计。 + +* 寻找单点故障，并不懈地寻找下来。 付出额外的努力来解决使您彻夜难眠的问题，并尽快从防御模式转变为进攻模式。 + +* 在 SOA 中，如果您的服务受阻，则构建断路器以开始发送 503s。 与其惩罚每个人，不如看看是否可以公平分配资源并仅惩罚滥用用户。 + +* 在服务使用者中添加了自动修复功能，服务可能会阻塞，并且桌面客户端或其他服务之类的消费者可以进行指数补偿以释放服务器压力，并在该服务再次运行时自动修复。 + +* 始终可用：请提供服务级别的断路器和客户提供的断路器。 例如 如果通过 webdav 或 FTP 访问文件系统存在性能问题，并且需要 4 个小时进行修复，那么在这 4 个小时内，您只需在防火墙处杀死 FTP / webdav 并要求客户使用 Web ui 或其他机制即可工作。 同样，如果一个客户造成了异常而使系统窒息，则可以暂时禁用该客户或该客户的服务，并在问题解决后重新启用它。 为此，我们使用功能标志和断路器。 + +* 保持简单：每个月都有新工程师加入，因此目标是从第一周开始就提高他们的生产力，简单的架构可确保轻松上岗。 + +### 您为什么成功？ + +牵引力胜过一切。 当 EFSS 市场刚刚爆发时，我们达到了 [产品/市场适合度](https://www.linkedin.com/pulse/marc-andreessen-product-market-fit-startups-marc-andreessen) 。 具有良好执行力的时机，管理团队的财务纪律导致成功。 许多竞争对手采用了免费增值模式，并筹集了大量资金，但是从第一天开始我们就开始收费，这使我们能够专注于根据市场需求发展解决方案/团队。 专注于付费客户使我们能够交付企业级解决方案，而无需支付免费增值罚金。 + +### 您希望自己做些什么？ + +我希望当我们开始时公共云的成本不会过高。 我也希望我们从第一天开始就使用 SOA，花了一些时间才到达那里，但是现在我们就在那里。 + +### 您不会更改什么？ + +目前，我不会替换 MySQL / EOS，因为它允许我们从防御定位转向进攻定位。 我不能在两年后发表评论，我会有相同的想法，我们可能会更改或扩大其中一些想法。 当您遇到下一个增长突增时，架构会发生变化。 + +## 您应该做多少前期设计？ + +很好的问题。 答案是“取决于”， + +* 如果您要设计诸如核心存储层或核心元数据层之类的东西，那么再多花 2 周的时间对设计就不会造成太大的影响。 当我们在核心元数据层上从 Berkeley DB 迁移到 MySQL 时，我承受着很大的压力，我曾想过要走捷径，当我通过首席技术官运行时，他建议花一些时间并“做正确的事”。 作为回顾，这是一个极好的决定。 + +* 对于公共 API，最好做一个不错的前端设计，因为您没有第二次机会对其进行更改，并且必须将其维护 4-5 年。 + +* 但是，如果您要为内部服务设计一些东西并将其迁移到新架构将不会花费一年，那么我建议您进行非常少的前端设计，并快速构建版本并随着使用量的增加对其进行迭代。 + +## 您如何考虑将来更改架构？ + +* 在一周中进行部署（我们快到了） + +* 将更多公共云用于任何新服务，并将更多服务迁移到公共云。 + +* 将其余的源代码从 svn 移至 git + +* 使当前的开发环境尽可能接近生产环境（可以使用 docker 或…）。 + +* 自动化架构管理 + +* 添加更多性能基准测试 + +* 建立持续的交付渠道，以便我们可以将部署增加为每周或每天，而不是每两周一次。 + +* 通过重新构建从某些增长最快的表中删除联接。 + +* 为 Mysql 分片添加自动平衡器，因此我不必担心偶尔出现的热点。 + +* 将某些脂肪服务分成颗粒状 + +* 使用内存缓存代理 + +## 您的团队如何设置？ + +### 您的团队中有多少人？ + +大约有 100 名工程师（devops / ops / qa / developers /…），其余是销售，市场营销，支持和人力资源。 + +### 他们在哪里？ + +最初是分布相当分散的工程团队，但现在主要吸引人是孟买的 [波兹南](https://en.wikipedia.org/wiki/Pozna%C5%84) 。 一些像我这样的远程员工 和其他一些员工在家工作。 + +### 谁扮演什么角色？ + +这是一个很大的团队，我们有产品经理，UX 团队，开发人员，Scrum 团队，架构师，工程师扮演各种角色。 最初，工程团队很平坦，每个人都会向工程副总裁报告，但现在我们在两者之间增加了一层管理。 + +### 您是否有特定的管理理念？ + +如果您开发某些产品，那么您拥有该产品的生命周期，这意味着您将与 QA，devops 一起确保其测试/部署。 投入生产时，您可以使用各种内部工具（例如 New Relic / Nagios）对其进行监视，如果存在回归，则可以对其进行修复。 + +### 如果您有分散的团队，该如何工作？ + +自治，1-1 交流，黑客马拉松使他们具有挑战性，他们会受到激励。 + +### 您的开发环境是什么？ + +* 适用于服务器团队的 Ubuntu + +* UI 团队使用 Windows / mac 并连接到用于 REST API 服务器的本地 Ubuntu VM 或连接到共享的 QA 实例 + +* Eclipse /想法 + +* 适用于构建的 + +* Maven + +* Git / SVN + +* 詹金斯 + +* ReviewBoard / Sonar + +* JIRA + +* Google 文档 + +* Jabber / Slack / Hangouts / Skype + +### 您的开发过程是什么？ + +我们在服务器团队中使用 Scrum，并且每两周发布一次。 长期功能开发人员/团队在沙盒上工作，完成后通过单元测试/硒/手动 QA 对它进行测试，然后合并到主干以捕获 2 周的发布流程。 我们吃了自己的狗粮，代码在发布前 1 周发布到了 UAT（所有员工使用的 egnyte.egnyte.com），我们发现了自动测试未发现的任何意外情况。 我们每个星期五晚上进行生产部署， [每天监视新文物，并报告任何异常的异常报告](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 。 我们正在将部署更改为即将在一周中完成。 + +### 您有什么可以做的不同还是感到惊讶？ + +许多工程师在家工作，令人惊讶的是，有了自主权，许多远程员工像总部员工一样富有生产力和积极性。 + +## 您使用什么基础架构？ + +### 您使用哪种语言来开发系统？ + +大多数是 Java / Python + +### 您有多少台服务器？ + +最后，我知道我们有 700 多个。 100 多个 MySQL 服务器，50 多个 Elasticsearch，200 多个 tomcat 服务节点，300 多个本地存储节点，20 多个 HAProxy 节点和缓存文件管理器，nginx，python 服务器以及其他各种节点。 + +### 如何将功能分配给服务器？ + +我们使用面向服务的体系结构，并根据服务类型分配服务器。 一些顶级服务是： + +* 元数据 + +* 储存空间 + +* 对象服务 + +* Web UI + +* 索引 + +* EventSync + +* 搜索 + +* 审核 + +* 快照/数据监视器 + +* 内容智能 + +* 实时事件传递 + +* 文本提取 + +* 集成 + +* 缩略图生成 + +* 防病毒软件 + +* 垃圾邮件 + +* 预览版 + +* rsync + +* API 网关 + +* 结算 + +* 支持 + +* 销售 + +* 等等。 + +### 如何配置服务器？ + +大多数服务都是伪造的，并在 VM 上运行，我们仅针对 MySQL，memcached，Metadata 服务器，索引之类的少数事物进行物理运行，但是除了数据库/缓存/存储节点之外，大多数服务都会转换为 VM。 我们使用第三方根据模板来配置服务器，并将其放入数据中心，以供使用。 + +### 您使用什么操作系统？ + +CentOS7 + +### 您使用哪个 Web 服务器？ + +Nginx，Apache。 在一些旧的流程中使用了 Apache，但随着时间的流逝，它将被弃用。 + +### 您使用哪个数据库？ + +MySQL。 我们过去曾使用过其他数据库，例如 Berkeley DB，Lucene，Cassandra，但由于开发人员/操作人员的熟悉程度和可伸缩性，我们将所有数据库都超时迁移到了 MySQL。 有关更多信息，请参见 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 + +### 您是否使用反向代理？ + +是 Nginx 和 HAProxy + +### 您是否并置，使用网格服务，使用托管服务等？ + +我们搭配。 + +### 您的存储策略是什么？ + +我们首先创建自己的服务器，然后在机器中打包尽可能多的硬盘驱动器，我们过去将它们称为 DRBD Filers。 我们这样做是因为 AWS 成本过高。 我们已经评估了 [GlusterFS](https://www.gluster.org/) ，但当时它无法扩展以满足我们的需求，因此我们构建了自己的。 加班 S3 变得便宜了，GCS / Azure 诞生了，我们将存储层设计为可插入的，因此现在客户可以决定要使用哪个存储引擎（例如，Egnyte，S3，GCS，Azure 等）。 + +### 您如何增加产能？ + +我们进行能力计划会议，并根据监控指标中的关键指标并预定一些额外的能力得出了一些指标。 现在，某些服务已启用云服务，我们只需单击一下按钮即可提供更多服务。 + +### 您是否使用存储服务？ + +是 Egnyte，S3，GCS，Azure 和 + +### 您如何处理会话管理？ + +我们多次重写了体系结构，目前 99％的服务是无状态的。 只有服务 Web UI 的服务使用会话，我们在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性会话，但最终我的计划是使它也变得无状态 。 + +### 您的数据库是如何设计的？ 主从？ 碎片？ 其他？ + +我们几乎对所有具有自动故障转移功能的数据库都使用了 Master-Master 复制，但是在一些突变程度很大的数据库上的切换是手动完成的，我们遇到了一些问题，其中由于复制滞后，自动切换会导致应用程序数据不一致，我们 需要重新架构一些核心文件系统逻辑来解决此问题，我们最终将完成此工作。 下面是有关处理数据库升级的问题，详细回答了有关数据库体系结构的更多详细信息。 + +### 您如何处理负载平衡？ + +我们根据客户使用 DNS 访问系统的 IP 进行地理平衡，并在数据中心内使用 HAProxy 将其路由到相应的 POD，并在内部 POD 中再次使用 HAProxy 路由他们 + +### 您使用哪个 Web 框架/ AJAX 库？ + +我们已经多次更改了 UI，这是一直在变化的一件事。 过去我们曾经使用过 ExtJS，YUI，JQuery，而没有使用过。 最新的迭代基于 ReactJS / Backbone / Marionette 。 + +### 您使用哪种实时消息框架？ + +我们使用 [大气](https://github.com/Atmosphere/atmosphere) ，但最终我们将其替换为 NodeJS + +### 您使用哪个分布式作业管理系统？ + +为此，我们使用 RabbitMQ 和基于 Java / python 的消费者服务。 + +### 您的网站是否有标准 API？ 如果是这样，您将如何实施？ + +我们的 API 分为 3 种类型：- + +1. 公共 API： 这是我们向第三方应用程序开发人员和集成团队以及我们的移动应用程序公开的 api。 我们会按照正确的弃用工作流程弃用/升级 api 签名，并且更改始终向后兼容。 我们使用 Mashery 作为网关，API 记录在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) + +2. 适用于我们客户的 API： 此 API 对我们客户而言是内部的，如果我们以外的人使用此 api，则我们不保证向后兼容。 + +3. 服务之间的内部受保护的 API ：这是服务在我们的数据中心内部用于彼此通信的 API，无法从外部防火墙调用。 + +### 您的对象和内容缓存策略是什么？ + +我们存储 PB 的数据，但无法缓存所有数据，但是如果客户在给定的 15 天时间内拥有 5000 万个文件，则他可能只使用其中的 100 万个文件。 我们有基于 tomcat / nginx / local 文件系统的缓存文件管理器节点，它以 LRU 方式运行。 我们可以弹性增加减少缓存文件服务器的数量。 我们最大的问题之一是上传速度，如何从世界任何地方尽可能快地将数据上传到 Egnyte，为此，我们构建了特殊的 Network pops。 [为 Egnyte 客户加速数据访问](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) + +Memcached 用于缓存元数据，我们使用单独的 memcached 池来缓存长期存在的静态数据和文件系统元数据。 核心文件系统元数据非常庞大，不适合当前的内存缓存节点，并且会逐出最近使用的其他类型的数据。 为防止这种情况，我们使用 2 种池，应用程序代码决定在哪里查找哪种数据。 我们允许在文件系统 Memcached 缓存中逐出，并在其他种类的 Memcached 池中争取零逐出。 + +### 您的客户端缓存策略是什么？ + +对于我们的 Web ui，我们使用 PageSpeed 进行资源优化，缓存，并使用 requireJS 和其他各种方式仅下载所需的模块。 我们的 Mobile 和 Desktop 客户端丰富使用本地文件系统作为缓存。 + +### 您使用哪些第三方服务来帮助您构建系统？ + +Google BigQuery，New Relic，AppDynamics，MixPanel，Flurry，Tableau 是我们使用的一些分析服务，但大多数核心组件均由我们构建。 + +## 您如何管理系统？ + +### 如何检查全局可用性并模拟最终用户性能？ + +我们使用不同 AWS 区域中的节点来一致地测试带宽性能。 我们还使用内部 haproxy 报告来绘制客户观察到的上载/下载速度，并主动寻找它们，并使用网络弹出消息和其他策略来加速数据包。 + +![](img/6ffa16c86d1956a9ff0be037d6021022.png) + +### 您如何健康检查服务器和网络？ + +使用 Nagios 监视器和 New Relic 以及一些内部主动异常分析。 有关更多详细信息，请参见此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) + +### 如何绘制网络和服务器统计数据以及趋势图？ + +我们使用石墨，仙人掌，Nagios 和 New Relic，AppDynamics。 + +![](img/d7afc2042d53ba5302472ee5be116c5f.png) + +![](img/293ca1407b4f34397f578ec21c96afd2.png) + +### 您如何测试系统？ + +硒，Junit，鼻子，睡表和手动测试。 + +### 您如何分析效果？ + +New Relic，AppDynamics 用于监视生产 tomcat 节点的性能。 我们使用石墨/ nagios /内部工具和其他工具来监视系统其他部分的性能。 有关此问题的更多详细信息，请参见此博客文章 [分布式系统中的调试性能问题](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) + +### 您如何处理安全性？ + +专用安全团队在每个版本之前都会运行自动化的安全基准测试。 连续自动化笔测试已在生产中运行。 我们还使用漏洞赏金计划并与 Whitehat 测试公司合作。 一些客户使用第三方进行自己的安全性测试。 + +### 您如何处理客户支持？ + +我们有专门的 24X7 分布式客户成功团队，我们使用 Zendesk 和 JIRA + +### 您是否实施网络分析？ + +我们使用 Google Analytics（分析），Mixpanel，Flurry 来衡量功能使用情况 + +### 您是否进行 A / B 测试？ + +是的，我们使用功能标记进行 A / B 测试。 有关更多信息，请参见 [在 Egnyte 使用功能标志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) + +### 您要运行多少个数据中心？ + +3 个主要数据中心，其中一个在欧洲（由于安全港规定） ，网络遍布世界各地。 + +### 您的系统如何部署在数据中心中？ + +Puppet 用于部署大多数新代码。 我们仍在重写架构中最后的几篇文章，这些文章目前都是使用 Shell 脚本部署的。 + +### 您使用哪种防火墙产品？ + +我们混合使用了瞻博网络 SRX 和 Fortigate 防火墙。 + +### 您使用哪个 DNS 服务？ + +PowerDNS + +### 您使用哪些路由器？ + +思科 + +### 您使用哪些开关？ + +Arista + +### 您使用哪个电子邮件系统？ + +我们使用自己的 SMTP 服务器来处理出站电子邮件，对于一些内部工具，我们使用 SendGrid，对于入站电子邮件，我们使用 GMail。 + +### 如何备份和还原系统？ + +对于 MySQL，我们使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，对于 Elasticsearch，该数据被复制 3 次，并且我们还使用 ElasticSearch GCS 备份插件将数据备份到 GCS。 对于客户文件，我们将其复制 3 次。 如果存储 Filer 无法恢复，我们将丢弃它，添加一个新 Filer 并再次复制副本。 对于某些客户，我们还会将其数据复制到他们选择的提供者。 对于使用 S3，Azure 或 GCS 作为可插拔存储层的客户，它将确保复制以防止数据丢失。 + +### 如何进行软件和硬件升级？ + +大多数节点是无状态的，并且有状态组件具有主动-主动故障转移。 通过将节点从池中取出并进行升级并将其放回池中来处理升级。 + +### 您如何处理升级时数据库架构的重大更改？ + +不同的服务使用不同类型的数据库，并且它们以不同的方式升级。 在 10000 英尺处，它们如下图所示： + +![](img/1de3f24a7fc5621b61d6e4e7ca1de358.png) + +1. EOS db 存储对象元数据并且增长非常快，它经过分片，并且我们将继续添加更多此类数据。 + +2. MDB 的增长速度更快，经过了分片，并且我们会继续增加更多。 + +3. DC_central 是 dns 数据库，并且保持相当静态。 我们运行了许多此副本以实现可伸缩性。 + +4. Pod_central 具有快速变异的数据，但每个表的增长量不超过 2000 万行。 我们运行了许多此副本以实现可伸缩性。 + +* 每个数据库架构始终是向前和向后兼容的，即我们绝不会在同一发行版中删除列和代码，我们首先在发行版 1 中部署停止使用该列的代码，而在发行版 2 中两周后，我们删除该列。 + +* 非分片数据库每 2 周更新一次。 它们是存储各种功能驱动表的表。 我们目前正在使用脚本升级它们，但现在已更改为使用 [Sqitch](http://sqitch.org/) + +* 使用自动脚本进行分片 db 新列更改 + +* 分片数据库迁移是一件痛苦的事情，因为我们有 7000 多个分片并且还在不断增长，您无法在 1 小时的升级窗口中完成。 方法是： + + * 实时代码根据需要迁移行。 这意味着迁移可能会持续数年。 + + * 使用功能标记迁移，您同时拥有新旧代码，并且在后台迁移客户，然后翻转标记以将其切换到新代码路径而无需停机，更多的是 [ [此处](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此处](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) + + * 当我们从 lucene 迁移到 ElasticSearch 时，除了重新索引所有内容外，我们别无选择，我们使用 [功能标记](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 进行了检索，大约花了 3 -4 个月完成。 + +* 模式一致性检查器报告可确保升级后所有数据中心中的所有模式均相同。 + +### 您是否有单独的运营团队来管理您的网站？ + +是的，我们有一个专门的 devops 团队和一个 IT / Ops 团队，负责监视和管理系统。 + +## 其他 + +### 您欣赏谁？ + +AWS ：他们的创新步伐令人赞叹。 + +Google ：他们的工具，例如 BigQuery，Analytics（分析）都很棒。 + +Elasticsearch ：其余 api 的简单性和架构很棒。 + +MySQL： 即可。 + +Eclipse / Jenkins ：插件架构很好。 + +### 您是否模仿了其他人的公司/方法？ + +我们是 [http://highscalability.com/](http://highscalability.com/) 的常规读者，许多设计都受到它的启发。 + +* POD 架构的灵感来自 Tumblr 的 Cell 架构，虽然不完全匹配，但是隔离故障的概念是相同的。 + +* 受 Facebook 启发的架构在 12 小时后会在内存缓存和刷新键中产生抖动。 + +* 受 [http://highscalability.com/上一些文章的启发，将](http://highscalability.com/) [指纹添加到每个数据库查询](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) + +我们正在招聘，请在 [职位页面](http://www.egnyte.com/jobs/engineering.html) 中查看我们，然后在 [与我们联系 [电子邮件保护的]](/cdn-cgi/l/email-protection) 。 + +[关于 HackerNews](https://news.ycombinator.com/item?id=11104555) \ No newline at end of file diff --git a/docs/193.md b/docs/193.md index de14261..6995a72 100644 --- a/docs/193.md +++ b/docs/193.md @@ -1,119 +1,152 @@ -# Pinboard.in Architecture-付费玩以保持系统小巧 +# Zapier 如何自动化数十亿个工作流自动化任务的旅程 -> 原文： [http://highscalability.com/blog/2010/12/29/pinboardin-architecture-pay-to-play-to-keep-a-system-small.html](http://highscalability.com/blog/2010/12/29/pinboardin-architecture-pay-to-play-to-keep-a-system-small.html) +> 原文： [http://highscalability.com/blog/2016/2/29/a-journey-through-how-zapier-automates-billions-of-workflow.html](http://highscalability.com/blog/2016/2/29/a-journey-through-how-zapier-automates-billions-of-workflow.html) -![](img/9f56768c8255ee971187862f4760c08c.png) +*这是[的来宾](http://stackshare.io/zapier/scaling-zapier-to-automate-billions-of-tasks)[转贴了](http://stackshare.io/zapier/scaling-zapier-to-automate-billions-of-tasks) [Bryan Helmig](http://stackshare.io/bryanhelmig) ，是 [Zapier](http://stackshare.io/zapier) 的共同创始人& CTO，他可以轻松地在 Web 之间自动执行任务 应用。* -如何在保持成功的同时保持足够小的系统规模，以使简单的向上扩展策略成为首选架构？ 例如， [StackOverflow](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 可以坚持使用自己喜欢的工具链，因为他们天生就对自己的增长速度抱有刹车：世界上只有这么多的程序员。 如果这对您不起作用，请考虑以下另一种自然制动策略：**收取服务费用**。 [Paul Houle](http://twitter.com/#!/simonstl/statuses/25587487132880897) 很好地总结为：*通过构建小规模盈利的服务来避免扩展问题*。 +![](img/99150b9925c63916b576766be5cb68de.png) -[Pinboard.in 的联合创始人 Maciej Ceglowski 在](http://pinboard.in/)中接受了 Leo Laporte 和 Amber MacArthur 关于他们的[的采访时提出了这一有趣的观点，我之前没有适当考虑过。 HTG3] [受电子邮件保护]](http://twit.tv/natn182) 显示。 +[Zapier](http://stackshare.io/zapier) 是一项 Web 服务，可自动执行 500 多个 Web 应用程序之间的数据流，其中包括 MailChimp，Salesforce，GitHub，Trello 等。 -插板式纸机是一种精简的，付钱的书签机，可以及时替代快要淘汰的 Delicious。 作为一个自称是反社会书签网站，它*强调社交化*的速度。 Maciej 认为 Pinboard 是个人档案，您可以在其中永久保存所阅读内容的历史记录。 当 Delicious 的灭亡宣布时，如果 Pinboard 曾经是免费站点，那么他们会立即倒闭，但是成为付费站点有助于拉平他们的增长曲线。 +想象一下[建立一个工作流](https://zapier.com/multi-step-zaps/)（或我们称为“ Zap”）的操作，该操作在用户填写您的 Typeform 表单时触发，然后在您的 Google 日历上自动创建事件，发送 Slack 通知并完成以下操作 在 Google 表格电子表格中添加一行。 那是扎皮尔。 即使对于非技术用户来说，构建这样的 Zaps 也非常容易，并且可以无限地自定义。 -过去经常与朋友共享链接的书签站点，但 Twitter 大部分已经接管了该角色。 但是，Twitter 只展示您的推特历史的一小部分而臭名昭著。 您真正想要的是一台大型服务器，它从可能在何处添加书签的地方都吸收了书签，而这正是 Pinboard 的作用。 +作为首席技术官和联合创始人，我构建了许多原始的核心系统，如今领导工程团队。 我想带您**，了解我们的堆栈**，以及我们如何构建它以及如何在今天继续改进它！ -对于 Pinboard 来说，有几点特别令我感到震惊： +## 幕后的团队 -* 它使用基于 MySQL，向上扩展，PHP，Perl 和无框架的传统风格简单体系结构。 -* 它要求支付服务费用以支付费用并保持用户群的可管理性。 -* 它根据用户数量收费以支付费用。 -* 他们缓慢地构建了站点，并希望使其保持小巧，快速，可靠，因为这是一种更好的运行方式。 +使 Zapier 滴答作响需要很多时间，因此我们在工程领域有四个不同的团队： -**网站**： [Pinboard.in](http://pinboard.in/) +* **前端团队**在非常强大的工作流编辑器上工作。 +* **全栈团队**是跨功能的，但专注于工作流引擎。 +* **开发人员小组**保持引擎嗡嗡作响。 +* **平台团队**（可协助质量检查）以及我们开发人员平台的入门合作伙伴。 -## 资料来源 +总而言之，这涉及约 15 名工程师（并且还在不断增加！）。 -* [技术基础](http://pinboard.in/blog/63/) -* [[受电子邮件保护]](http://twit.tv/natn182) 采访 -* 个人电邮 +## 架构 -[](http://pinboard.in/blog/63/) +**我们的堆栈不会赢得任何新奇奖**-我们正在使用一些非常标准的（但很棒的）工具为 Zapier 提供动力。 更有趣的是我们使用它们来解决特定品牌问题的方式，但让我们将基础知识排除在外： -## 统计资料 +### 前端 -* 1,630 万个书签 -* 5200 万个标签 -* 940 万个网址 -* 989 GB 存档内容 -* 自 2010 年 7 月 8 日以来，累计停机时间不到 1 小时。 +从主干**过渡到 React** 的过程中，我们感到有些困惑。 我们使用 ES6 的 [Babel](http://stackshare.io/babel) 和 [Webpack](http://stackshare.io/webpack) + [Gulp](http://stackshare.io/gulp) 来编译前端。 我们严重依赖 [CodeMirror](http://stackshare.io/codemirror) 来做一些我们需要的更复杂的输入小部件，并使用 [React](http://stackshare.io/react) + [Redux](http://stackshare.io/reduxjs) 为超级用户做很多繁重的工作 -强大的 Zap 编辑器。 -## 平台 +### 后端 -* 的 MySQL -* 的 PHP -* 佩尔 -* 的 Ubuntu -* 装甲运兵车 -* 狮身人面像 -* Cron 职位 -* S3 +[Python](http://stackshare.io/python) 为我们的大部分后端提供了动力。 [Django](http://stackshare.io/django) 是 HTTP 方面的首选框架。 [Celery](http://stackshare.io/celery) 是我们分布式工作流程引擎的*大型*部分。 大部分常规 API 工作都是通过具有历史意义的 [`requests`](https://github.com/kennethreitz/requests) 库（带有一堆自定义适配器和抽象）完成的。 -## 硬件 +### 数据 -* 机器 1：64 GB，运行数据库主服务器，存储用户档案并运行搜索 -* 机器 2：32 GB，运行故障转移主机，抓取各种外部提要，执行后台任务 -* 机器 3：16 GB，Web 服务器和数据库从属 +[MySQL](http://stackshare.io/mysql) 是我们的主要关系数据存储-您会在 MySQL 内部找到我们的用户，Zaps 等。 [Memcached](http://stackshare.io/memcached) 和 [McRouter](http://stackshare.io/mcrouter) 看起来像是无处不在的缓存层。 其他类型的数据将进入其他更有意义的数据存储中。 例如，在 [Redis](http://stackshare.io/redis) 中发现了用于计费和节流的飞行中任务计数，而 [Elasticsearch](http://stackshare.io/elasticsearch) 存储了 Zaps 的历史活动提要。 对于数据分析，我们喜欢一些 [AWS Redshift](http://stackshare.io/amazon-redshift) 。 -## 建筑 +### 该平台 -* 数据库的副本保留在所有三台计算机上。 -* 该网站在 16GB 计算机上运行。 数据库完全适合 RAM，页面加载时间提高了 10 倍或更多。 -* 主-主架构，带有一个额外的读取从属。 所有写入均指向一个 DB，其中包括书签，用户和标签表。 -* 第二个主机运行： - * 汇总计算，例如全局链接计数和每用户统计信息。 - * 使用 mysqldump 的每晚数据库备份。 备份以压缩格式存储到 S3。 -* Perl 脚本运行后台任务： - * 下载外部提要，为启用了存档功能的用户缓存页面，处理传入的电子邮件，生成标签云以及运行备份。 - * 选择 Perl 是因为现有的技能和 CPAN 中可用的大型支持库。 - * 诸如大多数流行书签之类的功能是由通常在每晚运行的 cron 作业生成的，但是当负载过高时将其关闭。 -* PHP 用于生成 HTML 页面： - * 不使用模板引擎。 没有使用框架。 - * APC 用于缓存 PHP 文件。 - * 不使用其他缓存。 -* [Sphinx](http://www.sphinxsearch.com/) 用于搜索引擎和全局标签页。 +我们的大多数平台都位于我们相当**的整体式核心 Python 代码库**中，但是有许多有趣的分支提供了专门的功能。 最好的例子可能是我们如何利用 [AWS Lambda](http://stackshare.io/aws-lambda) 运行合作伙伴/用户提供的代码来自定义应用程序行为和 API 通信。 -## 得到教训 +### 基础设施 -* **咒语。** Pinboard 的目标是：快速，可靠和简洁。 他们认为这些是可以赢得并留住客户的素质。 当出现问题时，例如大规模增长，他们总是优先考虑，以便保持这些系统质量。 例如，他们的首要任务是防止数据丢失，这决定了更改其服务器体系结构。 因此，从概念上讲，该站点在增长的时期内是令人困惑的……如果站点可以快速可靠地保存链接，则可以。 -* **从开头**开始作为付费网站。 成为付费网站的好处是您不会急于吸引新用户，因此可以保持小规模。 当 Delicious 的灭亡宣布时，如果他们本来可以成为免费站点，那么它们将立即被关闭，但是成为付费站点有助于平稳增长。 -* **根据用户数量收费**。 Pinboard 具有独特的定价方案，旨在比具有免费帐户的服务更好地扩展。 价格基于当前用户数。 随着用户数量的增加，价格也随之上涨。 人们为使用的资源付费。 这与 Amazon 或 Google App Engine 的付款模式相似，但有很大的不同。 这是一次性费用。 每年只需多花$ 25，就可以缓存和搜索所有书签。 -* **使用无聊和淡入淡出的技术。** 这些有助于确保站点永远不会丢失数据并且非常快。 -* **经验法则**：如果您乐于尝试某些事物，那么它可能不属于生产领域。 -* **使切换尽可能简单**。 Pinboard 通过自动导入和导出到 Delicious 并支持 Delicious API 来消除采用异议。 -* **保持小巧** **更有趣**。 当您可以提供个人客户支持并直接与用户互动时，您会拥有更好的时光。 -* **比较基于每 GB RAM 或存储空间的机器成本**。 Pinboard 最初是在 Slicehost 和 Linode 上运行的，但是当以每 GB RAM 或存储的美元成本表示的费用要高得多而又没有任何可抵消的收益时，他们便转向了另一种服务。 -* **在负载**下关闭功能。 例如，如果您需要其他地方的性能，请关闭搜索。 -* **中到大型站点是最昂贵的**。 小型站点的运行成本相对较低，但是在增长曲线的某个时刻，每个新用户的边际成本都会增加。 由于必须将数据拆分到多台计算机上并且必须购买和管理这些计算机，因此成本更高。 有一个扩展成本。 一旦您接触到数百万的用户，它就会再次变得便宜。 从小型站点到中型站点的第一步是痛苦且昂贵的。 -* **在您自己的产品**上做主。 根据您所相信的人，Delicious 在 Yahoo 的不断裁员中受到了伤害，但真正的问题是 Delicious 团队不是决策者。 新功能优先于可靠性，稳定性和创新性。 当命运掌握在他人手中时，您的工作时间或辛苦时间都没有关系。 -* **Small 并不总是有效**。 新用户席卷了[，增加了超过 700 万个书签，超过了服务整个生命周期中收集的书签，并且该网站的流量是正常流量的 100 倍以上。 结果，正常的后台任务（如搜索，归档和轮询外部提要）被暂停。 弹性的策略来处理像这样的尖峰负载并不都是坏事。](http://pinboard.in/blog/156/) -* **查看异常页面加载时间，而不是中值页面加载时间来判断您的服务质量**。 即使大多数页面加载时间都可以接受，页面加载可能需要花费几秒钟的时间才能接受。 -* **使用功能可快速构建**。 Pinboard 快速建立的部分原因是，社交和发现功能因说``去别的地方''而被推迟了。 其他站点将使您可以与朋友共享链接并发现新的有趣内容，但是没有其他站点像个人存档那样运作，这就是 Pinboard 的利基市场。 -* **通过机器**隔离服务。 当 Web 服务器与其他服务共享计算机时，Web 服务器可能会受到打击。 另一个例子是，每天搜索索引器在进行完整索引重建时都会与 MySQL 争夺内存。 +由于 Zapier **在 AWS** 上运行，因此我们触手可及。 [EC2](http://stackshare.io/amazon-ec2) 和 [VPC](http://stackshare.io/amazon-vpc) 是此处的中心，尽管我们会尽可能使用 [RDS](http://stackshare.io/amazon-rds) 以及大量的自动伸缩组，以确保服务器池处于最佳状态。 顶部形状。 [Jenkins](http://stackshare.io/jenkins) ， [Terraform](http://stackshare.io/terraform) ， [Puppet](http://stackshare.io/puppet) 和 [Ansible](http://stackshare.io/ansible) 都是开发团队的日常工具。 为了监视，我们对 [Statsd](http://stackshare.io/statsd) ， [Graylog](http://stackshare.io/graylog) 和 [Sentry](http://stackshare.io/sentry) （他们*很好*）不够满意。 -## 相关文章 +## 一些粗糙的数字 -* [Erick Schonfeld 将 Pin 大小的竞争对手 Pinboard](http://techcrunch.com/2010/12/29/delicious-exodus-pinboard/) 做成“美味的出埃及记”。 *该服务最初没有处理大量请求（高峰时每分钟处理数百个请求），但该数目增加了约十倍，达到每分钟 2500 个请求。* -* [关于 Pinboard](http://a.wholelottanothing.org/2010/12/quick-thoughts-on-pinboard.html) 的快速思考，作者：Matt Haughey -* [回到基础：Ditch Delicious，使用 Pinboard](http://techcrunch.com/2009/07/06/back-to-basics-ditch-delicious-use-pinboard/) ，作者：Michael Arrington -* [为什么 Pinboard.in 是我最喜欢的书签服务](http://www.messagingnews.com/onmessage/ben-gross/why-pinboardin-is-my-favorite-bookmarking-service)？ -* [del.icio.us，谢谢：插板，欢迎](http://redmonk.com/sogrady/2010/03/05/del-icio-us-pinboard/)，作者：Stephen O'Grady +这些数字代表一个大概的最小值，以帮助读者了解 Zapier 体系结构的总体大小和尺寸： -为什么我不仅可以创建 Google 电子表格和表单，还可以在浏览器栏中创建该表单的书签。 -您可以随时随地从私人 Google 电子表格中获取个人书签。 +* 每天约有超过 800 万个任务自动化 +* 每天超过约 6000 万次 API 调用 +* 每天有超过 1000 万个入站 Webhooks +* 在 [ELB](http://stackshare.io/aws-elastic-load-balancing) 之后运行 HTTP 的〜12 个 c3.2xlarge 框 +* 运行 [Celery](http://stackshare.io/celery) 的大约 100 个 m3.2xlarge 后台工作者（在轮询，挂钩，电子邮件，杂项中分隔） +* 集群中约 3 m3.medium [RabbitMQ](http://stackshare.io/rabbitmq) 节点 +* 〜4 个 r3.2xlarge [Redis](http://stackshare.io/redis) 实例-一个热，两个故障转移，一个备份/映像 +* 〜6 个 c3.xlarge McRouter 实例之后的〜12 m2.xlarge [Memcached](http://stackshare.io/memcached) 实例 +* 〜3 m3.xlarge 无数据 ElasticSearch 实例之后的〜10 m3.xlarge [ElasticSearch](http://stackshare.io/elasticsearch) 实例 +* 〜1 个 c3.2xlarge Graylog 服务器后面的〜6 m3.xlarge ElasticSearch 实例 +* 集群中约 10 个 dc1.large [Redshift](http://stackshare.io/amazon-redshift) 节点 +* 1 个主 db.m2.2xlarge [RDS MySQL](http://stackshare.io/amazon-rds) 实例，带有〜2 个以上的副本，可用于生产读取和分析 +* 少数支持 RDS MySQL 实例（下面有更多详细信息） +* ...以及大量的微服务和杂项专业服务 -您可以轻松地扩展表单/电子表格以在不同选项卡中存储“任务”，“密码”等。 +## 改善架构 -我缺少一个细节。 使用了什么网络服务器？ Apache，nginx 或 lighttpd？ +虽然架构的主要内容保持不变-我们仅执行了几次大规模迁移-但为将产品分为两类进行了大量工作： -作为用户已近一年了，可以肯定地说，Pinboard 是一项出色服务的典范，对它的功能极为有用，并且创始人在产品和技术方面都拥有正确的愿景。 +1. 支持重大新产品功能 +2. 为更多用户扩展应用程序 -从扩展的角度来看，如果您知道如何使用 mysql，那么 mysql 可以很好地进行扩展，而在扩展它的那天，流量将足够高，可以雇用聪明的人来专注于扩展部分。 否则，服务固有存在错误。 +让我们深入研究每个示例，尽可能多地获取细节，而不会陷入困境！ -这三台服务器支持多少总用户和峰值并发用户？ +#### 大型功能，例如多步 Zaps -安迪，您可以在这里尝试：http://techcrunch.com/2010/12/29/delicious-exodus-pinboard/ +当我们在 Startup 周末启动 Zapier（有趣的事实：它首先被称为 Snapier！）时，我们在不到 54 个小时的时间内布置了基本架构（由大量的咖啡和更多的啤酒推动）。 总的来说，这是体面的。 **我们保持设计非常非常简单**，这在当时是正确的选择。 -我不明白：“随着用户数量的增加，价格也随之上升”，这没有任何意义。 -您拥有的用户越多，就越能充分利用基础架构，那么每位用户的成本就会下降，因此您应该能够以相同的功能级别提供更便宜的服务。 您应该利用他们所谓的“规模经济”，并能够提供更好的价格。 +除了**之外，*也是*简单**。 具体来说，我们将 Zaps 分为两步：将触发器与一个动作配对，一个句号。 -这没有商业意义。 \ No newline at end of file +我们很快就意识到了错过的机会，但是过渡将非常复杂。 我们必须实现一个有向树，并支持任意数量的步骤（节点），但要对现有 Zaps（其中已有数十万个）保持 1 对 1 的支持。 我们必须做到这一点，同时还要保留对数百个独立合作伙伴 API 的支持。 + +从数据模型开始，我们在 MySQL 中构建了一个非常简单的有向树结构。 想象一下一个表，其中每行都有一个自引用`parent_id`外键，再加上一个额外的`root_id`外键以简化查询，您几乎就可以了。 我们讨论了切换到适当的图形数据库（例如 neo4j）的决定，但由于我们进行的查询种类简单且遍历较小的孤立图形（大约 2 至 50 个节点），因此决定拒绝这样做。 + +进行此工作的一个关键方面是步骤间的独立性。 每一步都必须消耗一些数据（例如，要读取哪个文件夹或要添加到哪个列表 ID），做一些 API 魔术操作并返回一些数据（例如，创建的新文件或添加到列表的新卡） ，但不知道其在工作流程中的位置。 每个独立的步骤都是愚蠢的。 + +中间是**全知的工作流引擎，该引擎通过将步骤作为任务串在一起来协调独立的 Celery 任务**-一步是由 Zap 的有根树定义的。 这个无所不知的引擎还包含所有其他优点，例如错误&重试处理，报告，日志记录，节流等。 + +即使在获得后端支持之后，我们仍然遇到另一个巨大的问题：**您如何为该对象构建 UI？** + +首先，确保团队中有一些*出色的*设计师和 Javascript 工程师。 然后，您将在嵌套的 Backbone 视图中工作一段时间，然后再进入 React。 :-)认真地说： [React](/react) 是我们正在构建的各种复杂接口的天赐之物。 + +React 的独特之处之一是性能特性对开发人员很友好，但前提是您必须弄清楚数据。 如果您不使用不可变的数据结构，则应使用一些结构共享库来进行所有突变，以及正在开发的深层`Object.freeze()`来捕捉直接尝试突变的地方。 + +构建如此复杂的 UI 面临许多挑战，其中大部分围绕测试和反馈，但要花费大量时间才能从不同的 API 中获取长尾数据，以使其优雅地适合于相同位置。 几乎每种奇怪的数据形状都必须考虑在内。 + +最后，我们的任务是让新编辑器在用户面前进行 alpha 和 beta 测试。 为此，我们同时发布了两个版本的编辑器，并使用功能开关选择了加入用户。在对结果感到满意之前，我们进行了数月的测试和调整，您可以查看 [Multi-Step Zap 发布 页](https://zapier.com/multi-step-zaps/)了解其最终结果。 + +![](img/7faac64c1acccc1743339f5d3bf58370.png) + +## 扩展应用程序 + +如果服务无法正常启动并可靠运行，那将是徒劳的。 因此，我们的大部分注意力集中在支持水平可伸缩性*和*冗余基础结构以确保可用性的应用程序设计上。 + +到目前为止，我们做出的一些更明智的决策是**，使我们对**感到满意的技术倍增，而**遇到瓶颈**时，则会分离出隔离的功能。 关键是**重用完全相同的解决方案，然后将其移动到另一个可以自由漫游 CPU 和 RAM 新鲜牧场的盒子**。 + +例如，在过去一年左右的时间里，我们注意到会话数据耗尽了主数据库的 IO 和存储量。 由于会话数据实际上是具有较弱一致性要求的键/值排列，因此我们对诸如 [Cassandra](http://stackshare.io/cassandra) 或 [Riak](http://stackshare.io/riak) （甚至是 Redis！）之类的方案进行了激烈的辩论，但最终决定站起来 具有单个会话表的 MySQL 实例。 + +作为工程师，我们的本能是找到最适合该工作的工具，但是**作为实际问题**，该工作并不能保证额外的操作复杂性。 我们知道 MySQL，它可以进行简单的键/值存储，我们的应用程序已经支持它。 畅所欲言。 + +此外，仔细设计应用程序可以使水平缩放同样简单。 长期运行的后台任务（例如我们的多步骤 Zaps）不受**轻写模式**的严格一致性要求的约束，因此**使用 MySQL 读操作是微不足道的（而且很安全！）。 仅将**复制为*主要*接触点。 即使我们偶尔在几分钟内得到了可怕的复制品延迟，但 99.9％的 Zaps 并没有改变-并且肯定不会很快改变-因此它们继续嗡嗡作响。 + +另一个好的做法是**假设最坏的**。 从一开始就设计失败。 尽管通常说起来容易做起来难，但如今实际上却很容易做到。 对于初学者：**将自动缩放组与自动替换**一起使用。 一个常见的误解是，ASG 仅用于扩展以适应波动的负载。 **错误！** **ASG + ELB 组合可以成为可靠性的骨干**，它使您可以随意杀死实例，而不必担心，因为它们会迅速被替换。 + +不知何故，我们不断地学习到，系统越简单，您的睡眠就越好。 + +## 日常 + +在本地，我们的工程师享受 [Docker](http://stackshare.io/docker) 提供的功能全面的环境。 `[docker-machine](http://stackshare.io/docker-machine)`和 [`docker-compose`](http://stackshare.io/docker-compose) 一起构成了 MySQL，Memcached，Redis，Elasticsearch 以及所有 Web 和后台工作人员的正确版本。 我们通常建议在本地运行 [`npm`](/npm) 甚至是`runserver`，因为 VirtualBox 会破坏文件监视功能。 + +规范的 [GitHub](http://stackshare.io/github) “拉动请求模型”驱动了我们的大部分工程重点项目，其中记录了日常工作，并在合并之前进行了最终代码审查。 [Hackpad](http://stackshare.io/hackpad) 包含了我们的大部分文档，其中包括大量的入门文档。 + +Zapier 的一大优势是[所有人都支持](https://zapier.com/blog/everyone-on-support/)。 每四到五周，每位工程师都会花费整整一周的支持来帮助调试和解决棘手的客户问题。 这对我们非常重要，因为它为了解客户的痛苦提供了基线（此外，您可能必须处理所运送的错误！）。 + +对于 CI 和部署，我们使用 [Jenkins](http://stackshare.io/jenkins) 对每个 PR 中的每个提交运行测试，并提供公司任何人都可以按下的“一键式部署”。 新工程师在工作的第一周点击部署按钮的情况并不少见！ + +我们在独立的 VPC 中拥有一个**完整的登台环境，以及一些非常适合测试长期拉动请求的独立 Web 框。 金丝雀部署到生产中很常见-完整记录所有错误，由 Graylog 提供。** + +## 你也可以扎皮尔！ + +开发人员可以使用 Zapier 来做一些很棒的事情。 + +除了多步骤 Zaps，我们还启用了将 [Python](https://zapier.com/help/code-python/) 和 [Javascript](https://zapier.com/help/code/) 编写为工作流中的代码步骤的功能。 无需自己托管和运行脚本-我们会处理所有这些。 我们还提供了绑定以调用网络（`requests`和`fetch`），甚至在两次运行之间存储一些状态！ + +我们的用户正在采用代码步骤来构建 [Slack](http://stackshare.io/slack) 机器人（以及游戏！），以替换一次性脚本以及更多其他内容。 我个人使用代码步骤来编写机器人和工具，以将代码&错误度量标准跟踪到电子表格中，转换格式奇怪的数据，并替换*吨* crontabs。 + +或者，如果您具有希望非开发人员能够使用的 API，那么我们也将拥有一个史诗般的[开发人员平台](https://zapier.com/developer/)。 只需定义触发器，搜索和操作，任何用户都可以将您的 API 混合到他们的工作流中，并将您的应用程序与 GitHub，Salesforce，Google Docs 等 500 多种应用程序集成。 + +而且，我们经常在招聘，因此，如果您想帮助我们帮助人们更快地工作并自动执行最繁琐的任务，请关注我们的[工作页面](https://zapier.com/jobs/)！ + +[关于 HackerNews](https://news.ycombinator.com/item?id=11082359) + +链接已断开... + +感谢抓住 Gigi！ + +为什么使用 MySQL？ Postgres 不是它的超集吗？ + +您能否评论一下如何在芹菜上实现编排？ 以我的经验，很难做到这一点，因为很多逻辑是在任务级别定义的，例如，很难在运行时修改任务的行为，因为它的定义是静态的，并且在将模块加载到工作程序时变成静态的。 \ No newline at end of file diff --git a/docs/194.md b/docs/194.md index 4598b84..afec160 100644 --- a/docs/194.md +++ b/docs/194.md @@ -1,96 +1,363 @@ -# Facebook 的新实时消息系统：HBase 每月可存储 135 亿条消息 +# Jeff Dean 在 Google 进行大规模深度学习 -> 原文： [http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html](http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html) +> 原文： [http://highscalability.com/blog/2016/3/16/jeff-dean-on-large-scale-deep-learning-at-google.html](http://highscalability.com/blog/2016/3/16/jeff-dean-on-large-scale-deep-learning-at-google.html) -![](img/05b2f60819d28aa5d0e59ecb0a2b699e.png) + +*If you can’t understand what’s in information then it’s going to be very difficult to organize it.* -您可能已经在某处阅读了 Facebook 推出了一个新的[社交收件箱](http://blog.facebook.com/blog.php?post=452288242130)，该电子邮件集成了电子邮件，IM，SMS，文本消息，Facebook 站点上的消息。 他们每个月总共需要存储 1,350 亿条消息。 他们将所有这些东西存储在哪里？ Facebook 的 Kannan Muthukkaruppan 在[消息的基础技术](http://www.facebook.com/note.php?note_id=454991608919#)： [HBase](http://hbase.apache.org/) 中给出了惊奇的答案。 HBase 击败了 MySQL，Cassandra 等。 +此引用来自 [Jeff Dean](http://research.google.com/pubs/jeff.html) ，现为 Google 系统基础架构小组的向导，研究员，研究员。 摘自他最近的演讲： [智能计算机系统的大规模深度学习](https://www.youtube.com/watch?v=QSaZGT4-6EY) 。 -为什么会有惊喜？ Facebook 创建了 Cassandra，它是专门为收件箱类型的应用程序而构建的，但是他们发现 Cassandra 的最终一致性模型与其新的实时 Messages 产品并不匹配。 Facebook 还拥有广泛的 [MySQL 基础架构](http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html)，但他们发现随着数据集和索引的增大，性能会受到影响。 他们本可以构建自己的，但是他们选择了 HBase。 +自 [AlphaGo 诉 Lee Se-dol](https://gogameguru.com/tag/deepmind-alphago-lee-sedol/) 以来， [John Henry](https://en.wikipedia.org/wiki/John_Henry_(folklore)) 的现代版本 与 的致命一击 [像蒸汽锤一样，已经笼罩了整个世界，人们普遍对 AI 感到恐惧](https://www.youtube.com/watch?v=j3LVFdWBHVM) [[ 启示录](http://thenextweb.com/insider/2014/03/08/ai-could-kill-all-meet-man-takes-risk-seriously/) ，这似乎是掩盖 Jeff 演讲的绝佳时机。 而且，如果您认为 AlphaGo 现在很好，请等到 beta 达到。 -HBase 是 *[扩展表存储，支持对大量数据](http://www.cloudera.com/blog/2010/06/integrating-hive-and-hbase/)* 的很高级别的行级更新。 消息系统确实需要什么。 HBase 还是建立在 [BigTable](http://en.wikipedia.org/wiki/HBase) 模型上的基于列的键值存储。 它擅长通过键获取行或扫描行范围并进行过滤。 消息系统还需要什么。 但是不支持复杂查询。 通常会向查询工具提供诸如 [Hive](http://wiki.apache.org/hadoop/Hive/HBaseIntegration) 之类的分析工具，该工具是 Facebook 创建的，以理解其多 PB 数据仓库，并且 Hive 基于 Hadoop 的文件系统 HDFS，HBase 也使用该文件系统。 +Jeff 当然是指 Google 臭名昭著的 [座右铭](https://www.google.com/about/company/) ： *整理世界各地的信息并将其广泛地传播 可访问且有用的* 。 -Facebook 之所以选择 HBase 是因为他们**监控了其使用情况，并弄清了真正需要的**。 他们需要的是一个可以处理两种数据模式的系统： +从历史上看，我们可能会将“组织”与收集，清理，存储，建立索引，报告和搜索数据相关联。 早期 Google 掌握的所有东西。 完成这项任务后，Google 便迎接了下一个挑战。 -1. 一小段时间数据往往易变 -2. 不断增长的数据集，很少被访问 +现在 **的组织意味着对** 的理解。 -说得通。 您会一次阅读收件箱中的最新信息，然后很少再看一次。 这些是如此不同，可能期望使用两个不同的系统，但是显然 HBase 对于两个系统都足够好。 尽管它们确实与 v [各种搜索系统](http://mail-archives.apache.org/mod_mbox/hbase-user/201006.mbox/%3C149150.78881.qm@web50304.mail.re2.yahoo.com%3E)集成在一起，但它们如何处理通用搜索功能尚不清楚，因为这并不是 HBase 的优势。 +我的演讲重点： -他们系统的一些关键方面： +* **实际的神经网络由数亿个参数**组成。 Google 的技能在于如何在大型有趣的数据集上构建并快速训练这些庞大的模型，将其应用于实际问题，*和*然后将模型快速部署到各种不同平台（电话）中的生产环境中 ，传感器，云等）。 -* HBase： - * 具有比 Cassandra 更简单的一致性模型。 - * 它们的数据模式具有非常好的可伸缩性和性能。 - * 大多数功能满足其需求：自动负载平衡和故障转移，压缩支持，每台服务器多个分片等。 - * HFS 使用的文件系统 HDFS 支持复制，端到端校验和和自动重新平衡。 - * Facebook 的运营团队在使用 HDFS 方面具有丰富的经验，因为 Facebook 是 Hadoop 的大用户，而 Hadoop 使用 HDFS 作为其分布式文件系统。 -* [Haystack](http://www.facebook.com/note.php?note_id=76191543919) 用于存储附件。 -* 从头开始编写了一个自定义应用程序服务器，以服务来自许多不同来源的大量消息流入。 -* 在 [ZooKeeper](http://highscalability.com/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html "http://hadoop.apache.org/zookeeper/") 之上编写了一个用户发现服务。 -* 可以通过以下方式访问基础结构服务：电子邮件帐户验证，朋友关系，隐私决策和传递决策（是否应该通过聊天或 SMS 发送消息？）。 -* 随着他们的小团队以惊人的方式做事，一年内有 15 位工程师发布了 [20 个新的基础架构服务](http://www.theregister.co.uk/2010/11/15/facebooks_largest_ever_engineering_project/)。 -* Facebook 不会在单个数据库平台上实现标准化，他们将使用单独的平台来完成单独的任务。 +* 神经网络在 90 年代没有兴起的原因是**缺乏计算能力，也缺少大型有趣的数据集**。 您可以在 Google 上看到 Google 对算法自然的热爱，再加上庞大的基础架构和不断扩大的数据集，如何为 AI 掀起**完美的 AI 风暴。** -我不会想到 Facebook 已经作为 HBase 的重要推动者，已经在 HDFS / Hadoop / Hive 方面拥有丰富的经验。 任何产品都可以与另一个非常受欢迎的产品合作，以期成为生态系统的一部分，这是梦想。 这就是 HBase 实现的。 鉴于 HBase 如何在持久性频谱中占据一席之地-实时，分布式，线性可伸缩，健壮，BigData，开源，键值，面向列-我们应该看到它变得越来越流行，尤其是在 Facebook 的油膏。 +* Google 与其他公司之间的关键区别在于，当他们在 2011 年启动 Google Brain 项目时， **并未将他们的研究留在象牙塔** 。 项目团队与 Android，Gmail 和照片等其他团队密切合作，以实际改善这些属性并解决难题。 对于每个公司来说，这都是难得的，也是一个很好的教训。 **通过与您的员工合作进行研究** 。 -## 相关文章 +* 这个想法很有效：他们了解到他们可以采用一整套子系统，其中一些子系统可以通过机器学习，并且 **替换为更通用的端到端 终端机器学习资料** 。 通常，当您有很多复杂的子系统时，通常会有很多复杂的代码将它们缝合在一起。 如果您可以用数据和非常简单的算法替换所有内容，那就太好了。 + +* **机器学习只会变得更好，更快。** 。 杰夫的一句话：机器学习社区的发展确实非常快。 人们发表了一篇论文，并且在一周之内，全世界许多研究小组下载了该论文，阅读，进行了剖析，对其进行了理解，对其进行了一些扩展，并在 [上发布了自己的扩展。 arXiv.org](http://arxiv.org/) 。 它与计算机科学的许多其他部分不同，在其他方面，人们将提交论文，六个月后，一个会议将决定是否接受该论文，然后在三个月后的会议中发表。 到那时已经一年了。 将时间从一年缩短到一周，真是太神奇了。 + +* **可以魔术方式组合技术** 。 翻译团队使用计算机视觉编写了可识别取景器中文本的应用程序。 它翻译文本，然后将翻译后的文本叠加在图像本身上。 另一个示例是编写图像标题。 它将图像识别与序列到序列神经网络相结合。 您只能想象将来所有这些模块化组件将如何组合在一起。 + +* **具有令人印象深刻的功能的模型在智能手机** 上足够小。 为了使技术消失，情报必须走到最前沿。 它不能依赖于连接到远程云大脑的网络脐带。 由于 TensorFlow 模型可以在手机上运行，​​因此这可能是可能的。 + +* 如果您不考虑如何使用深度神经网络来解决数据理解问题， **几乎可以肯定是** 。 这条线直接来自谈话，但是在您使用深层神经网络解决了棘手的问题之后，观察到棘手的问题后，事实就很清楚了。 + +Jeff 总是进行精彩的演讲，而这一演讲也不例外。 它简单，有趣，深入并且相对容易理解。 如果您想了解深度学习知识，或者只是想了解 Google 在做什么，那么必须要看的是 。 + +谈话内容不多。 它已经包装好了。 因此，我不确定本文将为您带来多少价值。 因此，如果您只想观看视频，我会理解的。 + +与 Google 对话一样，您会感到我们只被邀请到 Willy Wonka 的巧克力工厂的大厅里。 我们面前是一扇锁着的门，我们没有被邀请进来。那扇门之外的东西一定充满了奇迹。 但是，就连威利旺卡（Willy Wonka）的大厅也很有趣。 + +因此，让我们了解杰夫对未来的看法……这很令人着迷... + +## 理解意味着什么？ + +* 当向人们展示街道场景时，他们可以毫无问题地从场景中挑选文字，了解到一家商店出售纪念品，一家商店的价格确实很低，等等。 直到最近，计算机还无法从图像中提取此信息。 + +![](img/d9c5bdf722db9f4061822228edcff450.png) + +* 如果您真的想从图像中了解物理世界，则计算机需要能够挑选出有趣的信息，阅读并理解它们。 + +* 小型移动设备在当今和将来都主导着计算机交互。 这些设备需要不同类型的接口。 您需要真正能够理解并产生语音。 + +* 进行查询：[待售汽车零件]。 旧的 Google 会匹配第一个结果，因为关键字匹配，但是比较好的匹配是第二个文档。 真正了解查询的含义是深层次而不是肤浅的单词层次，这是构建良好的搜索和语言理解产品所需要的。 + +![](img/0ad48db760cd6b9f0ffb6dacb5986958.png) + +## Google 的深度神经网络简史 + +* [Google Brain 项目](https://en.wikipedia.org/wiki/Google_Brain) 从 2011 年开始，致力于真正推动神经网络技术的发展。 + +* 神经网络已经存在很长时间了。 它们在 60 年代和 70 年代发明，并在 80 年代末和 90 年代初流行，但它们逐渐消失了。 两个问题：1）缺乏训练大型模型所需的计算能力，这意味着无法将神经网络应用于较大的有趣数据集上的较大问题。 2）缺少大量有趣的数据集。 + +* 仅与 Google 的几个产品组合作。 随着时间的流逝，随着小组发布的好消息或解决了以前无法解决的问题的消息，周围的人流连忘返，更多的团队会去帮助他们解决问题。 + +* 一些使用深度学习技术的产品/领域：Android，Apps，药物发现，Gmail，图像理解，地图，自然语言，照片，机器人技术，语音翻译等。 + +* **深度学习可以应用在如此多样化的项目**中的原因是，它们**涉及到适用于不同领域的同一组构建模块**：语音，文本，搜索查询，图像， 视频，标签，实体，单词，音频功能。 您可以输入一种信息，确定要使用的信息，一起收集表示要计算的功能的训练数据集，然后就可以使用了。 + +* 这些模型运作良好，因为 **您以非常原始的数据形式输入** ，您无需手工设计很多有趣的功能， 该模型的强大功能在于它能够通过观察大量示例来自动确定数据集的有趣之处。 + +* 您可以学习通用表示法，可能跨域学习。 例如，“汽车”的含义可能与汽车的图像相同。 + +* 他们已经知道他们可以采用一整套子系统，其中一些子系统可能是机器学习的，因此**替换为更通用的端到端机器学习文章**。 通常，当您有很多复杂的子系统时，通常会有很多复杂的代码将它们缝合在一起。 如果您可以用数据和非常简单的算法替换所有内容，那就太好了。 + +## 什么是深度神经网络？ + +* [神经网络](https://en.wikipedia.org/wiki/Artificial_neural_network) 从数据中学到了非常复杂的功能。 来自一个空间的输入将转换为另一个空间的输出。 + +* 此功能与 x 2 不同，它是一个非常复杂的功能。 例如，当您输入原始像素（例如猫）时，输出将是对象类别。 + +![](img/89ac3f5ffa45828e335ec58c362f89f2.png) + +* 深度学习中的“ **深度**”是指神经网络中的**层数。** + +* 深度的一个不错的特性是该系统由简单且可训练的数学函数 的 **集合组成。** + +* 深度神经网络与许多机器学习风格兼容。 + + * 例如，您有一个输入，即猫的图片，而输出中有人将该图像标记为猫，则称为 [监督学习](https://en.wikipedia.org/wiki/Supervised_learning) 。 您可以为系统提供许多受监管的示例，并且您将学习近似于与在受监管的示例中观察到的功能相似的函数。 + + * 您也可以进行 [无监督训练](https://en.wikipedia.org/wiki/Unsupervised_learning) ，其中仅显示图像，不知道图像中包含什么。 然后，系统可以学习掌握在许多图像中出现的模式。 因此，即使您不知道该怎么称呼图像，它也可以识别出其中所有带有猫的图像都具有共同点。 + + * 还与 [强化学习](https://en.wikipedia.org/wiki/Reinforcement_learning) 等更奇特的技术兼容，这是一种非常重要的技术，已被用作一种 AlphaGo。 + +## 什么是深度学习？ + +* 神经网络模型**宽松地基于我们认为大脑的行为**。 这不是神经元真正工作原理的详细模拟。 这是神经元的简单抽象版本。 ![](img/cdb6dfc91acfa8a69172a2463d25b918.png) + +* 神经元有很多输入。 真实的神经元可以将不同的强度与不同的输入相关联。 人工神经网络尝试学习所有这些边上的权重，这些权重是与不同输入相关的优势。 + +* 真实的神经元会结合其输入和强度，并决定触发或不触发，即尖峰。 + + * 人工神经元不仅发出尖峰，还发出实数值。 这些神经元计算的功能是其输入的加权总和乘以通过某些非线性函数施加的权重。 + + * 通常，当今使用的非线性函数是 [整流线性单元](https://en.wikipedia.org/wiki/Rectifier_(neural_networks)) （最大值（0，x））。 在 90 年代，许多非线性函数是 [更平滑的](https://www.quora.com/What-is-special-about-rectifier-neural-units-used-in-NN-learning) S 型或正弦函数。 它具有不错的特性，即当神经元不触发时提供真实的零，而接近零的值可以在优化系统时为您提供帮助。 + + * 例如，如果神经元作为权重为-0.21、0.3 和 0.7 的三个输入 X1，X1，X3，则计算将为：y = max（0，-.0.21 * x1 + 0.3 * x2 + 0.7 * x3）。 + +* 在确定图像是猫还是狗时，图像将经过一系列图层放置。 一些神经元会根据其输入而激发或不激发。 + ![](img/61db59709a26ec559bff968acd2f37f0.png) + + * 最低层的神经元将看着小块像素。 较高级别的神经元将查看下面的神经元的输出，并决定是否触发。 + + * 该模型将逐步向上移动，例如说它是一只猫。 在这种情况下哪个是错的，那是一条狗（尽管我也以为是猫，还是在篮中的狗？）。 + + * 这是一个错误决策的信号会反馈到系统中，然后该信号将对模型的其余部分进行调整，以使下次查看图像时输出看起来像狗一样。 + + * 这就是神经网络的**目标，** **对整个模型中所有边缘**的权重进行很小的调整 **，以使您更有可能正确理解示例 。 您可以在所有示例中进行汇总，以便正确地使用大多数示例。** + +* 学习算法非常简单。 未完成时： + + * 选择一个随机训练示例“（输入，标签）”。 例如，带有所需输出“ cat”的猫图片。 + + * 在“输入”上运行神经网络，并查看其产生的结果。 + + * 调整边缘的权重以使输出更接近“标签” + +* 如何调整边缘的权重以使输出更接近标签？ + + * [反向传播](http://mattmazur.com/2015/03/17/a-step-by-step-backpropagation-example/) 。 以下是推荐的解释： [计算图上的演算：反向传播](http://colah.github.io/posts/2015-08-Backprop/) 。 + + * 微积分的 [链规则](https://www.khanacademy.org/math/differential-calculus/taking-derivatives/chain-rule/v/chain-rule-introduction) 用于确定当选择的是猫而不是狗时，在神经网络的顶部，您了解如何调整 最顶层的权重使其更可能说狗。 + +![](img/c984e94586f32c795a59ffaf31a30922.png) + +* 您需要使用权重朝箭头方向前进，以使其更有可能说狗。 不要迈出大步，因为它是复杂的不平坦表面。 采取非常小的步骤，使其更有可能在下一次遇到狗。 通过多次迭代并查看示例，结果更有可能成为狗。 + +* 通过链式规则，您可以了解较低层的参数更改将如何影响输出。 这意味着网络中的 **变化可以通过** 一直回荡到输入，从而使整个模型适应并更有可能说狗。 + +* 真正的神经网络是 **，它由数亿个参数组成** ，因此您要在亿维空间中进行调整，并尝试了解其影响 网络的输出。 + +## 神经网络的一些不错的特性 + +* **神经网络可以应用于许多不同类型的问题** （只要您有很多有趣的数据需要理解）。 + + * 文字：英语和其他语言的单词数以万亿计。 有很多对齐的文本，在一个句子的层次上有一种语言的翻译版本和另一种语言的翻译版本。 + + * 视觉数据：数十亿个图像和视频。 + + * 音频：每天数万小时的语音。 + + * 用户活动：有许多不同的应用程序在生成数据。 例如来自搜索引擎的查询或在电子邮件中标记垃圾邮件的人。 您可以学习许多活动并构建智能系统。 + + * 知识图：数十亿标记的关系三倍。 + +* **如果向它们投入更多数据，并使模型更大，则结果往往会更好** 。 -* [集成 Hive 和 HBase](http://www.cloudera.com/blog/2010/06/integrating-hive-and-hbase/) ，作者 Carl Steinbach -* [Adob​​e 选择 HBase](http://highscalability.com/blog/2010/3/16/1-billion-reasons-why-adobe-chose-hbase.html) 的十亿个理由 -* [HBase Architecture 101-预写日志](http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead-log.html)来自 Lars George -* [HBase Architecture 101-存储](http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html)和 Lars George -* [具有 Cassandra 和 HBase 的 BigTable 模型](http://horicky.blogspot.com/2010/10/bigtable-model-with-cassandra-and-hbase.html)，作者 Ricky Ho -* [新的 Facebook 聊天功能可使用 Erlang 扩展到 7000 万用户](http://highscalability.com/blog/2008/5/14/new-facebook-chat-feature-scales-to-70-million-users-using-e.html) + * 如果您在问题上投入了更多数据而又没有使模型更大，则可以通过学习有关数据集的更显而易见的事实来饱和模型的容量。 -似乎每个人都在跳 Cassandra 船：Digg，Twitter，现在甚至是 Cassandra 的原始创建者 facebook + * **通过增加模型的大小，它不仅可以记住明显的事物**，而且可以记住可能仅在数据集中的一小部分示例中出现的细微模式。 -它不是仍然使用案例驱动的 Andy 吗？ 当订单很重要时，收件箱的最终一致性可能不是一个很好的匹配，但这是针对其他问题的。 从操作上看，这两者都不是一件容易的事，因此，利用您的 Hadoop 技术具有很大的价值。 + * 通过在更多数据上构建更大的模型 **，需要进行更多的计算** 。 Google 一直在努力研究如何扩展计算量以解决这些问题，从而训练更大的模型。 -HBase 从 0.20.6 开始不稳定。 我认为他们对此进行了很多修补。 希望他们会尽快发布所有这些内部补丁。 +## 深度学习对 Google 有何重大影响？ -这三个服务都没有停止使用 Andy 的 Cassandra。 Twitter 正在采取缓慢的方法来扩大投资。 Facebook 的投资停滞不前，Digg 看到了一些问题，但仍在继续使用 Cassandra。 每个用例都应单独考虑，但是 FUD 在合理的技术决策中没有位置。 +### 语音识别 -兰迪 +* 这是 Google Brain 团队与之合作部署神经网络的第一批团队之一。 他们帮助他们部署了基于神经网络的新声学模型，而不是他们所使用的 [隐藏马尔可夫模型](https://en.wikipedia.org/wiki/Hidden_Markov_model) 。 -卡桑德拉（Cassandra）正在遭受自己的公关策略。 随着 Facebook，Digg 和 Twitter 使用该系统，它在很大程度上得到了推广。 乍一看，这似乎是一个明智的策略，因为无数行家愚蠢到足以认为，如果某些软件对 Google / Facebook / Twitter 有用，那么对初创公司也将足够。 但是 Cassandra 和 HBase 一样，都是不成熟的软件，因此迟早会遇到麻烦。 怪罪应该提供可扩展性和容错能力的软件基础架构是自然的，尽管不公平。 更糟糕的是，Digg 并未像 Foursquare 或 Google 过去那样发布任何详细的停机后详细信息。 +* 声学模型的问题是要从语音的 150 毫秒转到预测在 10 毫秒的中间发出什么声音。 例如，是 ba 还是 ka 声音？ 然后，您将获得这些预测的完整序列，然后将它们与语言模型结合在一起，以了解用户的意见。 -但是当您说 Twitter 正在投资 Cassandra 时（主要是用于新产品/服务），您说对了。 顺便说一句，我特别好奇地看到他们基于 Cassandra 的实时分析引擎。 希望他们意识到 Cassandra 还不够成熟，无法支持其现在的工作规模，因此他们正在以较小的规模工作，直到 Cassandra 摆脱了问题/限制（自动负载平衡，压缩，内存不足异常，不良的客户端 api） ，数据损坏，gc 风暴，缺少查询语言等）。 这些问题中的一些已经得到解决，而其他一些问题仍然被推迟。 卡桑德拉问题远远超出了 +* 他们的初始模型 **将字识别错误减少了 30％** ，这确实是一个大问题。 从那时起，语音团队一直在研究更复杂的模型和高级网络，以进一步降低错误率。 现在，当您在电话里讲话时，语音识别比三五年前要好得多。 -当谈到 Digg 时，至少有三名 Cassandra 专家退出公司，因此除非另有说明，否则 Digg 中 Cassandra 的未来似乎是有问题的。 但是无论如何，这家公司注定要失败，所以让它永远走下去。 +### ImageNet 挑战 -最后，正如您所指出的那样，Cassandra 在 Facebook 内部的投资已经停止，因此自然而然地假设这将是该系统的遗留系统。 如果我理解正确，FB 将 Cassandra 用于 Inbox 搜索，他们将用 Messages 服务取代它，那么那里的 Cassandra 用途是什么？ +* 大约 6 年前，发布了 [ImageNet](http://image-net.org/) 数据集。 当时大约有 100 万张图像，是计算机视觉的最大数据集之一。 这个庞大的数据集的发布推动了计算机视觉领域的发展。 -不过，我想从现在开始的一年后，我们将更好地了解 Cassandra 在这些公司中的使用情况。 + * 将图像放置在大约 1000 个不同类别中，每个类别大约放置 1000 张图像。 -弗拉基米尔：确实，HBase 0.20.6 的稳定性远不如当前的主干，我们即将发布的主干为 0.90。 Facebook 的所有工作都已经整合到了主干中-他们已经与开源社区合作了几个月。 + * 有上千种不同的豹子，小型摩托车等图片。 --Todd Lipcon（HBase 提交者） + * 一个复杂的因素是并非所有标签都正确。 -Todd，我们都希望 0.90 会比当前版本更稳定。 +* 目标是推广到新型图像。 您可以说是豹子还是樱桃，换个新图片？ -非常有趣的是，他们不需要牺牲一致性，而使用了完全一致的系统 HBase。 +* 在使用神经网络进行挑战之前，错误率约为 26％。 2014 年，Google 以 6.66％ 的 错误率赢得了挑战。 2015 年，错误率降至 3.46％。 + +* 这是一个庞大而深入的模型。 每个盒子都像整个神经元层一样在进行卷积运算。 这是本文： [随着卷积的发展而深入](http://www.cs.unc.edu/~wliu/papers/GoogLeNet.pdf) 。 + +![](img/e058ee738257389490f964a4ac3e11e4.png) + +* 人类 Andrej Karpathy 接受了挑战，错误率为 5.1％。 您可以在以下位置了解他的经验： [我在 ImageNet 上与 ConvNet 竞争所学到的东西。](http://karpathy.github.io/2014/09/02/what-i-learned-from-competing-against-a-convnet-on-imagenet/) + +#### 神经网络模型擅长什么？ + +* 该模型在 **方面表现出色，在**方面有很好的区分。 例如，计算机擅长区分狗的品种，而人类则不如。 当人们看到一朵花并说是一朵花时，计算机可以分辨出它是“芙蓉”还是“大丽花”。 +* 这些模型**擅长于概括**。 例如，看起来不相似的不同种类的餐食仍将正确地标记为“餐食”。 +* 当计算机出错时，错误对于原因是明智的。 例如，sl 看起来很像蛇。 + +### Google 相册搜索 + +* 能够查看像素并了解图像中的内容是一种强大的功能。 + +* Google 相册小组实现了无需标记即可搜索照片的功能。 您可以找到雕像，yoda，图纸，水等的图片，而无需为图片加标签。 + +### 街景图像 + +* 在街景图像中，您希望能够阅读所有文字。 这是更精细的视觉任务。 + +* 您需要首先能够找到图像中的文本。 经过训练的模型可以从本质上预测像素的热图，其中像素包含文本，而像素不包含文本。 训练数据是围绕文本片段绘制的多边形。 + +* 因为训练数据包含不同的字符集，所以以多种语言查找文本没有问题。 它适用于大字体和小字体； 靠近摄像机的单词和远离摄像机的单词； 用不同的颜色。 + +* 这是一种相对容易训练的模型。 这是一个卷积网络，它会尝试预测每个像素是否包含文本。 + +### 在 Google 搜索排名中的 RankBrain + +* [RankBrain](http://searchengineland.com/faq-all-about-the-new-google-rankbrain-algorithm-234440) 于 2015 年推出。它是第三重要的搜索排名信号（100 秒）。 有关更多信息，请访问： [Google 将其获利的 Web 搜索移交给 AI 机器](http://www.bloomberg.com/news/articles/2015-10-26/google-turning-its-lucrative-web-search-over-to-ai-machines) 。 + +* 搜索排名有所不同，因为您希望能够理解该模型，并且希望了解其做出某些决定的原因。 + + * 这是搜索排名小组在使用神经网络进行搜索排名时的不安。 当系统出错时，他们想了解为什么这样做。 + + * 创建了调试工具，并在模型中建立了足够的可理解性，以克服该反对意见。 + + * 通常，您不想手动调整参数。 您试图了解模型为什么要进行这种预测，并弄清楚该模型是否与训练数据有关，是否与问题不匹配？ 您可以训练一种数据分布，然后应用到另一种数据分布。 通过搜索查询的分布，您每天的变化都会有所变化。 由于事件的发生，变化总是在发生。 您必须了解自己的分布是否稳定，例如语音识别，人们发出的声音变化不大。 查询和文档内容经常更改，因此您必须确保模型是最新的。 一般而言，我们需要做得更好的工作构建工具，以了解这些神经网络内部发生的事情，找出导致预测的原因。 + +### 序列到序列模型 + +* 可以将世界上的许多问题构想为将一个序列映射到另一个序列。 Google 的 Sutskever，Vinyals 和 Le 撰写了有关该主题的突破性论文： [序列到神经网络的序列学习](http://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks.pdf) 。 + +* 他们特别关注语言翻译，以及将英语翻译成法语的问题。 翻译实际上只是将英语单词序列映射到法语单词序列。 + +* 神经网络非常擅长学习非常复杂的功能，因此该模型将学习将英语映射到法语句子的功能。 + +![](img/5d060f3fdfb3aa393921d2cd2a835ef3.png) + +* 用 EOS（句子结尾）信号一次输入一种语言的句子。 当看到一个 EOS 以另一种语言开始产生相应的句子时，模型被训练。 训练数据是指意义相同的语言句子对。 它只是试图对该功能建模。 + +* 在每个步骤中，它都会在您词汇表中的所有词汇表项上发出概率分布。 在推论时，您需要做一点搜索而不是训练。 如果您必须最大化每个单词的概率，则不一定要获得最可能的句子。 对联合概率进行搜索，直到找到最大可能的句子。 + +* 该系统在公共翻译任务上达到了最新水平。 大多数其他翻译系统都是针对问题子集的一堆手工编码或机器学习的模型，而不是完整的端到端学习系统。 + +* 该模型引起了人们的广泛关注，因为很多问题都可以映射到这种逐序列方法。 + +#### 智能回复 + +* [智能回复](http://googleresearch.blogspot.com/2015/11/computer-respond-to-this-email.html) 是如何在产品中使用逐个序列的示例。 在电话上，您希望能够快速响应电子邮件，并且打字很麻烦。 + + * 他们与 Gmail 团队合作开发了一个系统来预测邮件的可能回复。 + + * 第一步是训练一个小模型，以预测消息是否是可以简短回复的消息。 如果是这样，则会激活一个更大，计算量更大的模型，该模型将消息作为顺序输入，并尝试预测响应字的顺序。 + + * 例如，在一封询问感恩节邀请的电子邮件中，三种预计的回复是： 我们会去的; 抱歉，我们无法做到。 + + * 使用智能回复可以在收件箱应用中生成令人惊讶的回复数量。 + +#### 图片字幕 + +* 生成图像标题时，您要尝试在给定图像像素的情况下使人可能为该图像写上的标题。 + +* 取得已开发的图像模型和已开发的序列到序列模型，并将它们插入在一起。 图像模型用作输入。 不用一次查看一个英语句子，而是查看图像的像素。 + +* 经过训练可以产生字幕。 训练数据集具有由五个不同的人书写的带有五个不同标题的图像。 共写了大约 700,000 个句子，大约 100,000 至 200,000 张图像。 + +* 关于电脑上写道的一个抱着玩具熊的婴儿的照片：关闭一个抱着毛绒玩具的孩子； 一个婴儿在玩具熊旁边睡着了。 + +* 它没有人的理解水平。 错误的结果可能很有趣。 + +### 组合视觉+翻译 + +* 可以组合技术。 翻译团队使用计算机视觉编写了可识别取景器中文本的应用程序。 它翻译文本，然后将翻译后的文本叠加在图像本身上（看起来非常令人印象深刻，大约为 37:29）。 + +* 这些模型足够小，可以在设备 上运行**和** **！** + +## 周转时间及其对研究的影响 + +* 每天训练一张 GPU 卡需要 6 个星期。 + +* Google 真的很希望能够快速完成研究。 这个想法是要快速训练模型，了解哪些方法行之有效，哪些行之有效，并找出下一组要运行的实验。 + +* 模型应在数小时之内（而不是数天或数周）可训练。 它使每个进行此类研究的人都更有效率。 + +## 如何快速训练大型模型 + +### 模型并行 + +* 神经网络具有许多固有的并行性。 + +* 在计算它们时，所有不同的单个神经元大多彼此独立，尤其是当您具有局部感受野时，其中一个神经元仅接受来自其下方少数神经元的输入。 + +* 可以在不同的 GPU 卡上的不同计算机上划分工作。 只有跨越边界的数据才需要通信。 + +![](img/f1b9a2f1c1b9bec8ef93891e680ea08b.png) + +### 数据并行 + +* 您要优化的模型的参数集不应位于集中服务中的一台计算机中，因此您可以拥有许多不同的模型副本，这些副本将协作以优化参数。 + +* 在训练过程中读取不同的随机数据（示例）。 每个副本都将获取模型中的当前参数集，读取一些有关梯度应为多少的数据，找出要对参数进行哪些调整，然后将调整发送回集中的参数服务器集 。 参数服务器将对参数进行调整。 并重复该过程。 + +![](img/b50e7431d4f5bc620058b52961182f50.png) + +* 这可以跨许多副本完成。 有时，他们在 500 台不同的机器上使用 500 个模型的副本，以便快速优化参数并处理大量数据。 + +* 该过程可以是 **异步** ，其中每个料仓都在其自己的循环中，获取参数，计算梯度并将其发送回去，而无需任何控制或同步 其他的。 不利的一面是，当梯度返回时，参数可能已从计算时移开。 事实证明，对于实际上多达 50 到 100 个副本的多种模型而言，这是可以的。 + +* 该进程可以 **同步** 。 一个控制器控制所有副本。 两者似乎都起作用并且具有不同的优点和缺点（未列出）。 + +演讲的下一部分是关于 TensorFlow 的，我不会在这里讨论。 这篇文章已经太长了。 + +## Q & A + +* **如果您不是 Google 这样的大公司，并且无法访问大数据集，该怎么办？** 从运作良好的模型开始，该模型在公共数据集上经过训练。 公共数据集通常可用。 然后对更适合您的问题的数据进行培训。 从相似且可公开获得的数据集开始时，您可能只需要为特定问题加上标签的 1,000 或 10,000 个示例。 ImageNet 是此过程工作的一个很好的例子。 + +* **作为工程师，您最大的错误是什么？** 不在 BigTable 中放置分布式事务。 如果要更新多个行，则必须滚动自己的事务协议。 不会输入它是因为它会使系统设计变得复杂。 回想起来，许多团队都希望拥有这种能力，并以不同程度的成功建立自己的团队。 我们应该在核心系统中实现事务。 它在内部也将是有用的。 Spanner 通过添加事务来解决此问题。 + +## 相关文章 -曼迪 +* [关于 HackerNews](https://news.ycombinator.com/item?id=11298308) +* Ryan Adams 的 [AlphaGo](http://deepmind.com/alpha-go.html) 的真棒麻瓜可获得的技术解释 [机器学习音乐视频](http://www.thetalkingmachines.com/blog/) [Talking Machines](http://www.thetalkingmachines.com/) 播客的 集。 +* [TensorFlow](https://www.tensorflow.org/) +* [为什么机器学习课程的注册人数激增](http://blogs.nvidia.com/blog/2016/02/24/enrollment-in-machine-learning/) +* [使用深度卷积神经网络](http://arxiv.org/abs/1412.6564) 进行移动评估 +* [捍卫强大的 AI：语法](http://disagreeableme.blogspot.com/2012/11/in-defence-of-strong-ai-semantics-from.html) 的语义 +* [中文会议室参数](http://plato.stanford.edu/entries/chinese-room/) +* [Google：将计算机上的多个工作负荷相乘以提高机器利用率并节省资金](http://highscalability.com/blog/2013/11/13/google-multiplex-multiple-works-loads-on-computers-to-increa.html) +* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) +* [Google DeepMind：它是什么，它如何工作，您应该被吓到吗？](http://www.techworld.com/personal-tech/google-deepmind-what-is-it-how-it-works-should-you-be-scared-3615354/) +* [重塑 Google 帝国的人工大脑内部](http://www.wired.com/2014/07/google_brain/) +* [神经网络揭秘](http://lumiverse.io/series/neural-networks-demystified) +* [神经网络黑客指南](http://karpathy.github.io/neuralnets/) +* [神经网络和深度学习](http://neuralnetworksanddeeplearning.com/) +* [神经网络（常规）](http://colah.github.io/) +* [stephencwelch /神经网络解密](https://github.com/stephencwelch/Neural-Networks-Demystified) +* [加州大学伯克利分校深度学习主题课程](https://github.com/joanbruna/stat212b) +* [机器学习：2014-2015](https://www.cs.ox.ac.uk/people/nando.defreitas/machinelearning/) +* [通过深度强化学习玩 Atari](https://www.cs.toronto.edu/~vmnih/docs/dqn.pdf) +* [通过深度强化学习](https://storage.googleapis.com/deepmind-data/assets/papers/DeepMindNature14236Paper.pdf) 进行人为控制 -“无数的潮人足够愚蠢” +您提到了 arxiv.org，但却错过了 [gitxiv.com](http://gitxiv.com) ，这是机器学习中“真正非常快的”开发周期的下一个演变。 在 Gitxiv 上，您可以在 arxiv.org 上找到某些论文的实现。 这是您希望随论文提供的源代码。 大多数实现是由第三方完成的，但越来越多的是高质量的。 -这种毫无意义的谴责对辩论有何帮助？ +人类如何更好地以最适合 AI（例如 BrainRank 或其他深度神经网络）消费和理解的形式来构造文本？ -坦迪 +“从历史上看，我们可能会将'组织'与收集，清理，存储，建立索引，报告和搜索数据联系在一起。所有 Google 早期掌握的东西。完成这一任务后，Google 便迎接了下一个挑战。 -就这一点而言，这种“毫无意义的抨击”令人大开眼界。 我不知道您在软件行业工作了多长时间，但是*如果您从未见过有人争论“看，Twitter 使用 Ruby on Rails，他们对此很满意，那就让我们使用 现在！”* ，那么您在软件行业的时间还不够长（或者您是一个非常幸运的人）。 +现在组织意味着理解。” -令人惊讶的是，有多少工程师采用**技术，只是因为**“ X”公司（您命名）使用了该技术。 当然，没有人会毫不掩饰地承认这一点，但这是软件业务运作的方式。 仅举几个例子：EJB 被过度炒作，Ruby on Rails 被过度炒作，Linux 被过度炒作，Application Server 被过度炒作，现在轮到 NoSQL 系统了。 +我还没有看过杰夫·迪恩（Jeff Dean）的演讲-但有趣的是，几天前我在 Twitter 上发布了完全相同的内容： -**上面引用的许多技术都相当不错，但是要在开放思想和保守主义之间取得一定的平衡就不能落入陷阱（Digg？）。** +“ IMO Google 的长期目标不仅是“组织世界的信息”，还在于使用#AI 来“理解”它： -随着时间的推移，工程师获得了使用“ A”技术的经验（何时使用，什么时候不使用），赶时髦的人被砍掉了，炒作逐渐消失，一些“ A”系统消失了，而最合适的“ A”系统得以生存并 成长（达尔文主义很棒，不是吗？） +https://twitter.com/arunshroff/status/709072187773349889 -> 卡桑德拉（Cassandra）正在遭受自己的公关策略。 +要点：约翰·亨利的故事是我小时候最喜欢的故事之一。 +尽管这场比赛对他来说是致命的，但他还是*击败了*蒸汽锤。 因此，我不确定您想以此类推论来说明什么。 -卡桑德拉有公关策略吗？ +总体而言，自工业革命以来，我们就发生了人机冲突，这表明发生了棘轮事件。 永远无法退回的齿轮转动。 约翰·亨利（John Henry）是其中一员。 AlphaGo 不是，但是它来了。 -不，我可以这样来命名，但这不是您通常在公司中找到的正式 PR。 **这是一个临时性的口碑广告，是粉丝们在 Twitter，quora 等人身上所做的新闻的无尽回响。“瞧瞧，Twitter 的新实时分析服务得到了 Cassandra 的支持。 是吗？您也应该使用 Cassandra！”** 这个星期几乎快要结束了，但是这个帖子仍然丢失了转发。 :) +约翰·亨利死了。 那不是赢。 充其量是物理上的胜利。 他悲惨的胜利并没有阻止接下来发生的一切。 机器置换人的肌肉。 -尽管如此，这并不是 Cassandra 社区的错，因为到目前为止，这是由所有 NoSQL 系统以及 Hadoop 员工完成的。 问题是，当**与**软件项目一起使用时。 我怀疑 Twitter / Quora 是宣传软件的最佳渠道（最好的选择：技术会议），但是 Twitter 充满了狂热的粉丝，您必须忍受这一点。 :( \ No newline at end of file +好文章。 小重点。 Alpha Go 没有使用强化学习，这很重要。 强化学习是专为单人问题设计的，它在游戏等两人模型中的使用远非直截了当。 最大的问题是，如果自己一个人去，您将探索哪个领域。 因此，Alpha Go 使用（深度）学习来确定要探索的动作，如何评估情况以及何时停止评估，但是总体算法是一种博弈。 重要的是，学习不能解决所有问题，并且有明显的盲点。 其中之一就是结构很多的问题，例如是否有对手试图击败您。 还有其他情况。 \ No newline at end of file diff --git a/docs/195.md b/docs/195.md index d5816e3..77ad12d 100644 --- a/docs/195.md +++ b/docs/195.md @@ -1,12 +1,98 @@ -# 扩展 BBC iPlayer 的 6 种策略 +# 如今 Etsy 的架构是什么样的？ -> 原文： [http://highscalability.com/blog/2010/9/28/6-strategies-for-scaling-bbc-iplayer.html](http://highscalability.com/blog/2010/9/28/6-strategies-for-scaling-bbc-iplayer.html) +> 原文： [http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html](http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html) -英国广播公司（BBC）的 iPlayer 网站平均每天有 130 万用户浏览 800 万次页面。 技术架构师 Simon Frost 在[中描述了他们如何扩展站点，将 BBC iPlayer 缩放以处理需求](http://www.bbc.co.uk/blogs/bbcinternet/2010/07/scaling_the_bbc_iplayer_to_han.html)： +![](img/9e364140091b80d83d988a6634e2f7c6.png) -1. **使用框架**。 框架支持基于组件的开发，这使其便于团队开发，但是会引入必须最小化的延迟。 使用 Zend / PHP 是因为它支持组件且易于招募。 MySQL 用于程序元数据。 CouchDB 用于键值访问，以快速读取/写入以用户为中心的数据。 -2. **在构建架构之前先对其进行验证**。 通过提出其他架构来消除猜测，并创建原型以确定哪个选项最有效。 在性能与易于开发等因素之间取得平衡。 -3. **缓存很多**。 数据会在 memcached 中缓存几秒钟到几分钟。 较短的缓存失效期使用户的数据保持最新，但是即使这些短暂的时期也会在性能上产生巨大差异。 缓存不必花很长时间才能看到好处。 Varnish 用于缓存 HTML 页面。 大多数无效是基于时间或基于动作的（例如，有人添加了新的收藏夹）。 -4. **将页面分为个性化和标准组件**。 创建一个公共主页，以便可以将其与个性化数据分开进行缓存。 这样可以提供更快，更流畅的观看体验。 使用 Ajax 加载个性化元素。 Varnish 的灵活缓存策略用于缓存这些元素。 用户收藏夹列表仅缓存几分钟。 -5. **使用大量服务器**。 使用服务器池可横向扩展。 Web 服务器是无状态的。 页面由两个数据中心提供，以实现高可用性。 -6. **在启动**之前测试站点。 加载测试以在用户看到问题之前跟踪并修复问题。 \ No newline at end of file +*这是 [Christophe Limpalair](https://twitter.com/ScaleYourCode) 的来宾帖子，基于他对 [Jon Cowie](https://twitter.com/jonlives) ，员工运营部所做的[采访](https://scaleyourcode.com/interviews/interview/25)（[视频](https://www.youtube.com/watch?v=3vV4YiqKm1o)） 工程师和 Breaksmith @ Etsy。* + +随着 Etsy 从新平台过渡到稳定且完善的电子商务引擎，Etsy 成为了一个令人着迷的观看和研究平台。 这种转变需要进行很多文化上的改变，但最终结果却是惊人的。 + +如果您还没看过的话，2012 年上有一篇[帖子概述了他们的成长和转变。 但是从那以后发生了什么？ 他们还在创新吗？ 如何制定工程决策，这如何影响他们的工程文化？ 这些是我们与 Etsy 的一名运维工程师，定制厨师的作者 Jon Cowie 在新的播客节目中探讨的问题。](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html) + +## [](#what-does-etsys-architecture-look-like-nowadays)如今 Etsy 的架构是什么样的？ + +自上一次更新可追溯到 2012 年以来（在前面提到的帖子中），他们的体系结构并没有真正改变太多。 尽管这听起来有些无聊，但它概述了一个重要的概念，并为我们提供了对 Etsy 的工程文化的一些见识。 在整篇文章中，我们都会回头介绍这种文化，但这是它们的总体架构： + +Etsy 的生产基础设施全是裸机。 但是，在开发方面，他们可以虚拟化环境。 这为每个开发人员提供了一个代表整个堆栈缩影的虚拟机。 最终，虚拟环境仍在 Etsy 自己的物理硬件上运行。 + +实际的堆栈本身仍然看起来像这样： + +* 的 Linux +* 阿帕奇 +* 的 MySQL +* 的 PHP +* 缓存层 +* F5 负载平衡器 + +它们具有许多具有不同作业的不同缓存层。 他们大量使用 memcached 缓存数据库对象。 + +Etsy 具有面向第三方开发人员的面向公众的 API，并且还具有内部 API。 这些 API 有缓存层，因为有些答案不是短暂的。 例如，如果一个答案生存一个小时或更长时间，他们可能会缓存它。 + +当然，它们也大量缓存图像和静态资产。 + +这里的挑战是缓存失效。 确保您没有向用户提供过时的内容，而是充分利用了缓存以尽可能减少数据库的负载。 另外，请确保您通过将其缓存到更接近最终用户的方式，更快地向用户提供响应。 Etsy 团队还深深地关心着这件事，这在其工程博客 CodeasCraft.com 上的定期性能报告中可以明显看出。 + +尽管总体架构几乎相同，但这并不意味着 Etsy 工程师和 Ops 团队一直坐在那里摆弄他们的拇指。 好吧，也许其中一些有，但是我离题了... + +## [](#so-what-are-their-ops-challenges-do-they-still-have-to-put-out-fires)那么他们的操作挑战是什么？ 他们还必须灭火吗？ + +我们只是看到了它们在成熟可靠的技术方面会如何出错，因此他们不会花费太多时间扑灭火灾。 新问题往往来自引入新系统。 我敢肯定，你们中的许多人以前都读过这篇文章：您介绍了一个新的系统，该系统在纸上可以解决您的所有问题。 除非它对您环境中当前的其他组件具有复杂且“不可能”的反应。 因此，您必须找出导致问题的原因以及解决方法。 + +老实说，如果您从事这一领域，那么您可能会活在当下。 这些有趣的挑战使您抓狂，您真的想弄清楚，以便继续进行下一个挑战。 除非有时花费的时间太长，然后变得很麻烦。 + +大多数公司面临的另一个挑战是试图雇用优秀人才。 您在哪里还能找到优秀的人才？ 如果您正在使用新的“热门功能”，则可能很难找到该人才，而且价格会昂贵得多。 但是，如果您选择像 PHP 这样成熟的东西，它并不是那么困难。 仍然很难，但是不像为 Scala 找到人那样难。 + +到目前为止，已有许多 PHP 工具出现了十年，而语言也是如此。 许多前沿漏洞已被消除。 这意味着更少的难以发现的怪异错误，以及更多的专家可以聘用。 + +## [](#does-that-mean-they-never-change-anything-in-their-architecture)这是否意味着他们从不更改架构中的任何内容？ + +不，绝对不是。 这意味着他们拥有制定使用新技术的决策的明确流程。 + +他们实际上使用一种工具来创建“体系结构评论”，支持者在其中输入支持材料和该思想背后的理论。 然后，一个团队将提出一个他们认为适合 Etsy 当前环境的概念。 + +让我们看一个最近的例子。 他们介绍了 Kafka 用于事件流水线。 为了做到这一点，一个团队提出了一个用例，说明了为什么要使用 Kafka 以及如何解决 Etsy 的实际问题。 然后，他们进行了体系结构审查，高级工程师和所有相关方聚集在一起讨论该提案。 + +它是一种成熟且成熟的技术吗？ + +它会真正解决问题吗？这是解决问题的最佳方法吗？ + +组件将如何与我们的系统反应？ + +谁来支持这个？ + +一旦回答了这些问题，它们便进入实施阶段。 + +在上线之前，它必须经历另一个称为“可操作性审查”的过程，该过程将验证一切是否就绪。 这包括设置适当的监视和警报，为每个待命人员设置适当的程序，等等。 与该实现有关的每个人都必须参与“什么，何时，如何”。 + +另一个重要的考虑因素是：“我们可以通过在已经拥有的工具上构建它来做到这一点吗？” 稍后，我们将详细介绍。 + +这些是在实施建议的技术之前必须回答的问题。 这种彻底的分析可能需要一些时间，但是对于已建立的电子商务平台而言，正常运行时间至关重要。 + +“我们非常重视站点的正常运行时间，可靠性和总体可操作性。” + +## [](#customizing)自定义 + +我们已经看到 Etsy 的文化如何促进稳定。 我们还没有讨论的是它如何鼓励定制现有工具。 + +就像我们刚刚看到的那样，与其实施一个新的工具来解决问题，不如定制一个正在使用的工具，这更有意义。 一个典型的例子是定制 Chef。 乔恩·考伊（Jon Cowie）成为一些有影响力的厨师定制的一部分，例如[刀叉](https://github.com/jonlives/knife-spork)。 这种自定义实际上来自 Etsy 团队试图解决的问题。 当多个开发人员同时对同一 Chef Server 和存储库进行更改时，更改将被覆盖。 Jon 负责这个工具，不仅为一个大型开源社区提供了帮助，而且还解决了 Etsy 的一个关键且局限性的问题。 + +这是激发乔恩（Jon）编写 [Customizing Chef](http://shop.oreilly.com/product/0636920032984.do) 的一部分。 这是他希望自己拥有的书。 + +这也是 Chef 开源文化的一个很好的例子。 乔恩（Jon）强调说，Chef 并非设计为“一刀切”的解决方案。 它旨在为人们提供一个工具包，使我们能够解决自己的自动化问题。 Chef 的想法是，用户是他们自己系统的专家。 虽然它不能告诉您该怎么做，但它为您提供了工具，因此您可以自己做出决定，然后告诉您想要什么。 + +当然，这并不是说定制没有自己的问题。 如果自定义某些内容，则必须“拥有它”。 一旦决定开源该工具或自定义工具，它将变得更加复杂。 实际上，Etsy 在决定开放源代码工具之后就对此产生了疑问。 他们将开放该工具的源代码，但随后工程师将在本地下拉版本，为 Etsy 基础结构对其进行编辑，然后再将其推回主存储库。 许多项目只是没有被更新。 + +他们是如何解决的？ 通过适当的程序。 就像想要在系统中引入新技术一样，如果您想在 Etsy 开放项目的源代码，则需要回答一些有关该项目及其维护方式的问题。 + +它也很多都承认哪些项目不再需要维护了。 他们最终完成了多个项目，并明确表示不再进行更新。 这样一来，他们就可以重新组合并专注于内部实际使用的工具。 + +“因此，我们已经建立的流程更加适合确保我们只开源自己在生产中积极使用的东西。” + +因为归根结底，如果没有人要维护一种工具，那么它可能不会对整个社区有所帮助。 + +## [](#what-about-you)你呢？ + +您的过程和思维方式有何不同？ 您从 Etsy 的方法中学到了什么吗？ 从他们的工程文化和开放源代码实践怎么样？ + +[关于 HackerNews](https://news.ycombinator.com/item?id=11345723) \ No newline at end of file diff --git a/docs/196.md b/docs/196.md index f80705e..82ab136 100644 --- a/docs/196.md +++ b/docs/196.md @@ -1,254 +1,129 @@ -# Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长 - -> 原文： [http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) - -![](img/570f0d0ed652d765e32b52d6ed05e6cd.png)每天有 1000 万玩家，每月超过 5000 万玩家使用 Facebook，MySpace 和 iPhone 等社交平台上的 [Playfish](http://playfish.com) 游戏与朋友进行社交互动。 Playfish 是游戏行业发展最快的细分市场中的早期创新者：[社交游戏](http://radoff.com/blog/2010/05/24/history-social-games/)，这是休闲游戏和社交网络之间的挚爱。 Playfish 还是 Amazon 云的早期采用者，其系统完全在 100 台云服务器上运行。 Playfish 发现自己处于某些热门趋势（可能是 EA 为什么以 [3 亿美元](http://mashable.com/2009/11/09/ea-acquires-playfish-2/)买下它们，并认为 [10 亿美元游戏](http://venturebeat.com/2010/04/20/ea-playfish-president-the-billion-dollar-social-game-is-achievable/)成为可能）的趋势：在社交网络上构建游戏， 在云中构建应用程序，移动游戏，利用数据驱动的设计来不断发展和改进系统，敏捷开发和部署，以及将[出售为商业模型。](http://blogs.forbes.com/velocity/2010/02/23/eas-playfish-big-real-world-sales-in-virtual-goods-game/) - -一家小公司如何实现所有这些目标？ 为了解释这种魔术，我采访了 Playfish 的工程高级总监 Jodi Moran 和 Playfish 的首席建筑师，第一任工程师兼运营总监 Martin Frost。 很多好东西，让我们继续讲究细节。 - -![](img/c91d3416e25166647ae96320f6156952.png) - -网站： [playfish.com](http://playfish.com/) - -## 统计资料 - -1. 每月 5000 万活跃用户 -2. 每天有 1000 万活跃用户 -3. 100 台服务器计算机 -4. 10 款游戏，一直在发布 -5. 已下载，安装和播放了 2 亿个游戏 -6. 服务器与操作人员的比例为 100：1 -7. 4 间工作室中的约 200 名员工和 250 名承包商 - -![](img/1e65da2353b0c34d18ec301ed65e89be.png) - -## 平台 - -1. 客户端上的 Flash -2. 服务器端的 Java -3. 一些 PHP 工具 -4. 亚马逊：EC2，CloudFront，S3，Hadoop /弹性地图简化，Hive，一些 SQS，一些 SimpleDB -5. HAProxy 用于负载平衡 -6. MySQL 用于分片，blob 存储 -7. 码头应用服务器 -8. [YAMI4](http://www.inspirel.com/yami4/) 用于服务传输。 提供点对点连接，低延迟。 - -## 关键力量 - -塑造 Playfish 体系结构的主要力量是什么？ - -1. **游戏是免费（F2P）**。 Playfish 游戏是免费的：它们不需要花钱就可以玩，但仍然需要花钱来运行。 这种模型的结果是不可能简单地将硬件扔到问题上。 成本必须得到控制，因此它们试图精益高效地运行。 与其他游戏机型一起，每月订阅可补贴硬件和产品投资。 [MMO](http://en.wikipedia.org/wiki/Massively_multiplayer_online_game) （大型多人在线游戏），例如，每台服务器可运行数百或数千个用户。 Playfish 的目标是在此数量级以上。 MMO 可提供服务器密集型游戏体验，但它们唯一的方法是每月收取 10 至 50 美元的订阅费，这是一个完全不同的空间。 -2. **游戏是社交游戏**。 Playfish 专注于社交游戏，这意味着您与朋友互动和互动。 实际上，您只能和真正的朋友一起玩，也可以和您的社交游戏一起玩。 游戏并不是真正赢球。 结果是按分数和水平排序的，但是人们会发挥更多的作用来表达自己并炫耀其设计技巧。 这是另一种游戏类型。 例如，在[餐厅城市](http://www.youtube.com/watch?v=a8AyQ7xBAZ0)中，目标不是成为最富有或最好的餐厅，而是拥有最具创意和表现力的餐厅。 较新的游戏甚至不再使用全球排行榜。 较早的游戏使用全球排行榜，每个人都与其他人竞争。 游戏的结构传统上更具挑战性，并且“看我的得分比你的得分还要大”。 现在他们有了一个排行榜，但它只是在您和您的朋友之间。 现在更亲密了。 人们不在乎是否比其他国家的人更好，而在乎是否比朋友的人更好。 -3. **游戏是异步**。 异步游戏是玩家可以在不同时间玩的游戏。 由于您的朋友很少同时在线，因此社交游戏是异步进行的。 你们不必都同时玩。 例如，在类似 MMO 的《魔兽世界》中，玩家同时存在于同一空间中并且可以同时行动，这使得他们对延迟非常敏感并且难以扩展。 Playfish 的游戏有所不同，它们是异步播放的单人或多人游戏。 玩家不会同时出现在同一个游戏空间中，而是在其本地客户端中玩。 与朋友一起玩耍时，您不会受到朋友的阻拦，可以自己进步。 该模型导致各种专业设计的可能性。 异步游戏的例子是熟悉的游戏，如 Scrabble 或 Texas Hold'em，玩家轮流玩。 更具创新性的游戏是 Playfish 的“最大大脑”游戏，该游戏中的朋友不断尝试证明谁更聪明，它使用排行榜显示您的朋友及其分数的图片，因此您始终可以看到谁在领先。 这是异步的，因为每个玩家都独立游戏，但排行榜允许所有玩家检查彼此的进度。 -4. **游戏是休闲游戏**。 异步游戏可以是硬核策略游戏，例如 1950 年代的[外交棋盘游戏](http://en.wikipedia.org/wiki/Diplomacy_(game))。 [社交游戏](http://radoff.com/blog/2010/05/24/history-social-games/)往往是[休闲游戏](http://en.wikipedia.org/wiki/Casual_game)，它们确实很容易玩，只要在短时间内从任何位置单击几下鼠标，就可以玩。 Playfish 通过高产值 3D 图形，易于控制，自定义角色和多人游戏挑战扩展了该模型，从而带来了很高的[用户参与度](http://www.workatplay.com/think/what-user-engagement-anyway-part-1)。 -5. **规模受限于各个社交网络**的规模。 与社交意味着[难以扩展](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html)的其他应用领域相反，对于 Playfish 社交来说，这不仅是一个扩展问题，还是一个扩展解决方案。 Playfish 游戏并不具有全球意义，因为有一百万人不会尝试同时玩同一游戏。 Playfish 游戏是社交性的。 他们与您的朋友一起玩的乐趣更多，而不是艰难和肮脏的比赛。 这样的结果是，个别游戏固有地可扩展，因为它们只涉及很少的玩家。 以一个拥有 5000 万用户的全球排行榜为例。 在单个数据结构上需要大量写入，并且可能需要分片以使其扩展。 由几个参与者组成的社交网络的排行榜更容易实现。 -6. **大量用户**。 积极玩游戏的用户数量众多，这给他们的体系结构带来了压力，要求它们扩展为整个系统。 每个单独的游戏可能都相对容易扩展，但是对于这么多的活动游戏来说，完整的系统并不是那么容易扩展。 -7. **快速增长**。 通过设计，这些游戏具有病毒性，因为它们利用了社交图谱。 它们也很有趣，易于玩耍并有助于维持朋友之间的关系。 所有这些因素都促进了社交游戏的快速发展，这意味着 Playfish 不仅需要应对大量用户，还必须应对持续不断的新用户。 -8. **快速更改**。 游戏市场发展迅速，竞争激烈。 这也是一个非常新的领域，每个人仍在学习什么有效，哪些无效，流失很多。 Playfish 不能等待漫长的采购流程，漫长的设计周期或漫长的发布周期。 他们必须保持敏捷。 -9. **游戏的热门驱动性质**。 很难预测哪些游戏会成功，因此当一款游戏成功起飞时，它必须能够立即扩展。 游戏盛行时，没有时间利用新资源。 为每个游戏的最大预期增长分配资源根本行不通。 他们的游戏太多了，这将需要大量的服务器，而这些服务器很可能将不使用。 -10. **实验性游戏发布**。 游戏可以看作是针对利基市场的实验。 有些实验会比其他实验更成功。 这回到了社交游戏行业非常敏捷的本质。 -11. **多个游戏**。 Playfish 不是一家单一产品公司。 其他公司仅支持一个游戏。 Playfish 必须同时支持和开发多个游戏，并且新游戏总是按计划进行。 这给开发和运营带来很大压力。 -12. **智能客户端**。 Playfish 游戏是用 Flash 编写的，这是一个非常强大的富客户端。 它可以智能地缓存数据，支持本地操作并消除大量服务器负载。 -13. **游戏是应用程序，而不是网站**。 由于智能客户端会删除许多读取，因此大多数数据库活动都是**大量写入**。 典型数据库主机上 60％的负载是写操作，而大多数网站往往读起来很繁琐。 由于游戏是通过网络进行的，因此很容易将它们视为网站，但实际上它们是通过网络交付的应用程序。 -14. **重负载时间延迟**。 Playfish 游戏具有全球用户的意义，因此具有全球性。 由于游戏是在智能客户端中异步进行的，因此游戏等待时间并不重要，这意味着在加载游戏（即 Flash 游戏+资产）时，用户会遇到最明显的等待时间，因此，他们必须尽可能减少这种情况。 -15. **来自用户**的实时反馈。 社交游戏通过网络以数字方式在社交网络上分发，从而完全绕开了通过商店或电信公司的传统分发渠道。 第一次没有中间人控制游戏发行。 任何用户都可以坐在家里，随时随地与他们一起玩。 游戏制作者现在可以以前所未有的方式与观众建立联系。 可以直接与用户群联系，以帮助发展和改进游戏。 用户可以向游戏设计师提供实时反馈，并影响他们玩的游戏的设计。 -16. **社交游戏是服务，而不是盒子**。 传统游戏是在盒子中的架子上购买的，而发行商则控制频道。 他们向同一位 25 岁的硬核游戏玩家销售产品。 社交游戏正在扩展到[新市场](http://venturebeat.com/2010/08/23/one-in-five-americans-plays-games-on-social-networks/)，吸引了从未玩过游戏的人。 作为一项服务的游戏在玩家和游戏背后的创意团队之间建立了非常长的关系。 可以每周发布一次，一起培养游戏，并不断学习玩家的需求。 在拥有多年的开发周期之前，这是不可能的。 -17. **人们已断开连接，正在寻找连接**的方法。 宠物协会是一个虚拟的世界，玩家在这里装饰自己的房屋和朋友的房屋。 在圣诞节前后，他们开始以每个 2 美元的价格出售虚拟圣诞节和装饰品。 他们出售了价值 4000 万美元的虚拟货币。 行为分析的忠实拥护者，他们问用户为什么要这么做？ 归结为与断开联系的人们建立联系。 以前，他们家里会有一棵树，人们会看到树和他们的创造力。 现在人们都断开了连接，因此 3-4 个朋友可以看到真实的圣诞树，而他们所有的朋友都可以看到 Facebook 上的虚拟圣诞树。 在吸引人方面，您的虚拟货币有更大的优势。 推动购买的是对社交表达自我的渴望，虚拟商品是手段，社交网络是新领域。 就像在现实世界中一样，购买虚拟礼物是为了在与朋友互动中获得感知的价值。 -18. **背景模拟**。 像 Restaurant City 这样的游戏开始具有后台模拟组件，即使用户不在网上也可以运行。 这导致游戏以鼓励玩家定期回头的方式发展。 例如，在《餐厅城》中，玩家需要确保为餐厅员工提供食物。 此模拟组件是一个有趣的新负载，必须将其集成到游戏基础结构中。 -19. **需要一次缩放几个不同的维度**。 Playfish 需要扩展以支持更多的用户，更多的游戏，每位用户更多的数据，每位用户更多的访问权限，更多的开发人员和更多的运营人员。 扩展最困难的事情是扩展支持一切的人员。 - -## 关键扩展策略 - -为了应对这些力量，Playfish 遵循了一些关键的扩展策略： - -1. **乐趣**。 为了推动增长，关键的设计指标是创造一款如此有趣的游戏，以至于它会产生强烈的情感，使人们感到他们只需要玩游戏，就必须邀请他们的朋友加入游戏，以获得更多的乐趣。 在朋友的社交网络中分享情感时，情感会最大化。 传统游戏是具有出色声音和图形的沉浸式体验。 Playfish 尝试设计用于社交互动的游戏，通过邀请朋友让您从游戏中受益。 您可以自己玩 Restaurant City，但邀请您的朋友在您的餐厅做饭会更有趣。 通过在游戏中添加朋友，您会逐渐获得更多乐趣。 用户希望与朋友互动以获得更多乐趣的愿望推动了更大的发行量和增长。 -2. **基于微交易的收入模型**。 [微型交易](http://blogcritics.org/gaming/article/microtransactions-in-games/)通常是高交易量，低价值的交易。 为了支付服务费用，Playfish 通过玩家购买游戏内虚拟物品和服务来赚钱。 Playfish 还从广告和[产品展示位置](http://venturebeat.com/2010/04/20/ea-playfish-president-the-billion-dollar-social-game-is-achievable/)中获利。 该策略支持免费游戏模式，同时基于自然游戏收入提供收入。 -3. **云**。 Playfish 从一开始就一直是 100％基于云的，并于 2007 年在 EC2 上发布了他们的第一款测试版游戏。云几乎是我们上一节所介绍的众多力量的完美答案。 我不会谈论云的所有[奇观，但您很容易看到弹性如何帮助解决他们的许多可变需求问题。 如果游戏变得流行，它们可以增加更多资源来处理负载。 无需采购流程。 如果需求下降，他们可以简单地将实例退还给您。 云的 API / IaaS（基础设施即服务）性质可以轻松满足其对敏捷性的需求，保持团队规模的需求以及早期及经常发布的要求。 您可能会认为按使用付费模式的云太昂贵了，我们将在云部分中对此进行更多讨论，但是他们并不这么认为。 他们更加担心无法在快速发展的市场中开发新游戏和改进现有游戏的机会成本。](http://highscalability.com/how-do-you-explain-cloud-computing-your-grandma) -4. **SOA（面向服务的体系结构）**。 他们在 SOA 方面非常重要。 这是他们架构的组织原则以及他们如何构造团队。 每个游戏都被视为单独的服务，并且彼此独立发行。 内部组织成提供 API 的组件的软件，并且这些组件分别进行管理和可伸缩。 -5. **分片**。 Playfish 是一项写重服务。 为了处理写入，Playfish 采用了[分片架构](http://highscalability.com/blog/category/shard)，因为这是扩展写入的唯一真正方法。 -6. **BLOB** 。 没有为用户存储多个记录。 相反，用户数据存储在 MySQL 中的 [BLOB](http://en.wikipedia.org/wiki/Blob_(computing)) （二进制大对象）中，因此可以通过键值方法快速访问它。 -7. **异步**。 在服务器上进行写操作与游戏是异步的。 用户不必等待服务器上的写入完成就可以继续玩游戏。 他们试图尽可能向用户隐藏延迟。 在 MMO 中​​，每一步都必须传达给所有用户，而延迟是关键。 Playfish 游戏并非如此。 -8. **智能客户端**。 通过使用智能 Flash 客户端，Playfish 能够利用客户端计算机上更高的处理能力。 随着他们添加更多用户，他们还增加了更多的计算能力。 他们必须正确平衡服务器端和客户端端的内容。 适当的组合因游戏而异。 智能客户端缓存读取内容，但它也允许游戏在客户端上独立进行，而无需与服务器对话。 -9. **数据驱动的游戏改进**。 Playfish 收集了大量的游戏数据，用于持续改进现有游戏并帮助确定接下来要发明的游戏。 他们正在使用 Amazon 的 Elastic Map Reduce 作为其分析平台。 -10. **敏捷**。 Playfish 的所有思想中的一个共同点是对灵活性的不懈需求，以便能够快速，轻松，高效地应对各种情况。 敏捷性体现在他们对云的选择上，围绕服务进行组织，快速发布周期，保持团队规模小和有能力，并通过数据挖掘和客户反馈不断改进游戏设计。 - -## 基本游戏架构 - -1. 游戏在 Flash 客户端中运行。 -2. 客户端以服务级别 API 的形式将请求发送到 HAProxy 服务器，该服务器在 Amazon 云中运行的 Jetty 应用程序服务器之间负载均衡请求。 -3. 所有后端应用程序均使用 Java 编写，并使用面向服务的体系结构进行组织。 -4. Jetty 服务器都是无状态的，从而简化了部署，升级并提高了可用性。 -5. MySQL 被用作数据层。 数据在 MySQL 服务器之间进行分片，并以 BLOB 格式存储。 -6. Playfish 是 Amazon 云的早期采用者，因此他们无法利用诸如负载平衡之类的 Amazon 后来的开发。 如果他们必须从头开始，他们可能会朝这个方向发展。 -7. 更改被异步推送到服务器。 该系统的设计不是让用户单击按钮，而是将操作发送到服务器以查看发生了什么，而是使系统有权让客户端决定操作是什么，然后由服务器检查该操作是否有效。 处理在客户端。 如果用户和服务之间存在高延迟，则由于异步保存和智能客户端，用户将看不到它。 在一天结束时，用户看到的才是最重要的。 重要的是，当网络中出现故障或等待时间较长时，用户将获得有趣的游戏体验。 -8. Playfish 的前几款游戏是简单的单人游戏，例如《谁拥有最大的大脑》，并具有高分和挑战等功能。 在服务器端不是很复杂，也不是很沉重。 从项目开始到结束，他们只有 5 周的时间。 其中包括对 Facebook API 的学习和编码，对 AWS 的学习和编码，对游戏服务器的编码以及建立生产基础架构。 前三场比赛延续了这种模式：高分和挑战。 这给了他们一些喘息的空间，可以开始建立自己的基础架构。 改变事物的第一款游戏是 2008 年的宠物协会。这是第一款大量使用虚拟物品的游戏。 数据存储从为每个用户存储一些属性（如化身定制和高分）到为每个虚拟项目存储每个用户潜在的数千个项目。 这给系统带来很大压力。 早期，随着服务增长非常迅速，出现了一些大服务问题。 然后他们进行分片，系统变得更加稳定。 但是首先，他们尝试了其他各种技术。 他们尝试一次添加更多的只读副本，例如一次添加 12 个，但这并没有真正起作用。 他们尝试尽最大可能修补系统。 然后他们咬住子弹并放入分片中。 从开始到推出共花了 2 周的时间。 在该游戏中，所有性能问题都消失了。 随着时间的流逝，用户获得了很多虚拟物品，因此行的数量爆炸了。 每个项目都存储在其自己的行中。 即使您将用户划分为旧用户的碎片，即使用户数量保持不变，碎片也会不断增长。 这是转到 BLOB 的原始驱动程序之一。 BLOB 摆脱了导致此类性能问题的多个行。 随着时间的流逝，游戏开始变得越来越复杂。 宠物协会没有任何模拟元素。 然后，他们在 2008 年底推出了“餐厅城市”，该餐厅具有第一个离线模拟元素。 当玩家不在时，您的餐厅继续营业并赚钱。 这带来了挑战，但是在云中添加额外的处理相对简单。 模拟逻辑是在客户端中实现的，服务器将执行诸如检查欺诈的操作。 - -## 面向服务的架构 - -1. Playfish 确实是 SOA 的主要倡导者。 SOA 将数据和功能封装在一起，可以通过分布式系统独立部署。 分布式组件通过称为*服务合同*的 API 进行通信。 -2. 服务确保系统所有部分之间的依赖性是众所周知的，并且尽可能松散耦合。 -3. 支持复杂性管理。 该系统可以组成单独的易于理解的组件。 -4. 组件是独立部署和升级的，这提供了灵活性和敏捷性，并使得扩展开发和运营团队变得更加容易。 -5. 可以独立于其他服务来优化独立服务。 -6. 服务失败时，更容易正常降级。 -7. 每个游戏都被视为一项服务。 UI 和后端是一个包。 他们没有分别发布 UI 和后端。 - -## 云端 - -1. Playfish 从一开始就是 100％基于云的，于 2007 年在 Beta 版 EC2 上发布了他们的第一款游戏。 -2. Cloud 使 Playfish 能够以极低的摩擦力进行创新并尝试新功能和新游戏，这是快速发展的市场的关键。 从他们的多个只读副本系统迁移到分片系统需要 2 个星期，如果没有云的灵活性，这是不可能完成的。 -3. 云使他们能够专注于使他们与众不同的地方，而不是构建和管理服务器。 由于云运营无需专注于机器维护，因此他们可以专注于更高价值的服务，例如跨所有不同服务器和游戏开发自动化。 -4. 现在，在设计应用程序时将容量视为一种商品。 -5. 服务器与操作人员的比例为 100：1。 由于云基础架构，如此高的比率是可能的。 -6. 服务器发生故障，因此必须从头开始计划。 -7. 不可能继续向服务器添加内存，因此您可能必须提前扩展。 -8. 云的关键特征是*灵活性*。 您可以根据需要灵活地进行操作。 当您突然得到大量流量时，您无需感到惊讶。 您不必等待服务器的采购。 -9. 您永远都不知道游戏将以多快的速度起飞。 有时您确实知道，体育游戏发展很快，但其他游戏可能会突然爆炸。 在云中，这不一定是问题。 -10. 从一开始，就从来没有想到它们可以在云中进行扩展。 一切都旨在通过添加更多计算机来扩展。 -11. 他们不能使用所有的 Amazon 服务，因为必须自己滚动。 离开他们所了解的自己的系统会带来不必要的风险。 例如，没有 ELB 和 RDS，因此必须自己构建。 现在切换到那些服务没有任何意义。 -12. Playfish 是云的核心。 他们充分利用了云中的一切。 轻松获取更多容量。 他们根本没有内部服务器。 所有开发机器都在云中。 云使启动新环境变得轻而易举。 例如，要测试分片很容易，只需使用新配置复制所有内容即可。 在数据中心中运行时，这要困难得多。 -13. 考虑到所有因素，**云比裸机更昂贵**。 - 1. 基于带宽和机架空间的单位，裸机可能看起来更便宜，但是如果您查看所获得的所有东西，那将是很多工作。 以高级可用性功能为例。 更改 API 调用，您将获得双数据中心。 在裸机情况下，您无法做到这一点。 仅考虑设置和维护的人员成本。 云看起来确实很昂贵，但是当您获得真正大容量时，中断就开始了。 - 2. 要考虑的主要成本是**机会成本**。 这是最大的优势。 例如，当他们第一次在 Pet Society 中实施分片时，从开始到部署需要 2 周。 用户立即感到高兴。 它们的实现速度取决于能够在生产中激发整个服务器负载以及测试和迁移数据。 如果您有两个月的交货时间，那么您将有两个月不满意的用户。 -14. Playfish 在同一区域内的多个可用区中运行。 服务器相对靠近，这减少了延迟。 它们不会像 MMO 系统那样散布开来。 使用异步写入，客户端中的缓存和 CDN 中的缓存在更高级别上处理延迟。 在服务器上执行游戏操作可能需要 3 秒钟，但是由于它是异步的，因此用户不会注意到。 CDN 有助于减少他们注意到的内容，即资产和游戏的负载。 -15. CloudFront 用于减少负载延迟。 从某种意义上说，Playfish 是全球性的，拥有世界各地的用户。 游戏的加载时间（包括 Flash 代码和游戏资产）是它们最明显的延迟。 CloudFront 可以在分发内容时减少这种延迟。 - -## 数据库系统 - -1. MySQL 被用作存储 BLOB 的分片键值数据库。 -2. 用户跨多个数据库集群进行分片，每个集群都有自己的主副本和只读副本。 - 1. 他们拥有更多副本的好处不多，因为它们写得很重。 几乎所有流量都是写操作。 写入很难缩放。 无法缓存，更多的只读副本无济于事。 - 2. 在较早的体系结构中，他们有一个具有 12 个读取从属设备的主设备，表现不佳。 - 3. 通过分片，他们从一个母版和 12 个只读副本变成了两个母版和两个只读副本，这对读写都有帮助。 -3. 分片意味着索引变小，这意味着它们可以容纳在内存中。 将索引保留在缓存中可确保用户查找不必打到磁盘，可以从 RAM 提供查找。 -4. 通过分片，他们可以控制每个分片中有多少用户，因此，他们可以确保自己不会破坏内存索引缓存并开始访问磁盘。 -5. 他们试图优化用户记录的大小，以便更多用户可以容纳在内存中。 这就是为什么他们去存储 BLOB 而不是使用标准化为行的数据的原因。 现在，每个用户只有一个数据库记录。 -6. 工作从数据库服务器中取出并移到应用程序服务器，这些服务器很容易在云中水平扩展。 -7. 大多数网站都使用诸如内存缓存之类的扩展技术来进行读取缓存，而这些技术对 Playfish 并不那么有用。 使用 Flash 客户端时，将在 memcache 中缓存的大部分内容都将缓存在客户端中。 将其发送到服务器一次并存储。 -8. 分片用于获得更高的写入性能。 - 1. 写操作占 60％的工作量。 通常情况下是 10：1。 他们仍然使用 MySQL 进行数据存储，因为他们对负载等情况下的性能统计非常满意。 - 2. 每个分片都有一个母版，至少在只读副本上。 大多数情况下，只有一个只读副本，但这取决于服务的访问模式。 读取将拆分为读取副本。 对于确实具有更多读取的一些地方，它们具有更多的读取副本。 只读副本还用于远程保留数据作为备份。 -9. Playfish 是由纯粹的必需品驱动的。 他们建立了自己的键值存储，因为必须这样做。 为什么不使用 NoSQL？ 他们正在研究选项，但同时他们有一个可行的解决方案，他们知道它将如何工作。 对 NoSQL 解决方案感兴趣，用于操作端，用于管理多个数据库。 进入运行 NoSQL 的模式并不容易，但这是由其需求驱动的。 -10. 在横向扩展情况下，您必须进行分片之类的操作，此时许多 SQL 功能都将消失。 您必须自己做很多工作。 现在，当您进行大批拆分时，您将无法添加索引。 -11. 使用 NoSQL 时，您将放弃访问模式的灵活性。 关系数据库非常好，因为您可以随时以所需的方式访问数据。 例如，由于他们不能再使用 SQL 来汇总字段，因此它们都可以即时聚合或使用批处理过程进行聚合。 -12. 备份到 S3。 - -## Flash-客户端 - -1. 客户端的 CPU 和资源随用户数量的增加而扩展，因此明智地利用客户端。 将尽可能多的处理推送给客户端。 -2. 更改被异步写回到服务器，这有助于向用户隐藏网络延迟。 -3. 在服务器端检查更改以检测作弊。 -4. Flash 使用服务级别 API 与 Jav​​a 应用程序服务器对话。 -5. 使处理过程更接近客户端可为用户带来更好的体验。 网站使服务器更靠近用户。 Playfish 在客户端上使处理过程更加紧密。 - -## YAMI4-讯息 - -1. 经过长时间的评估，YAMI4 是 Playfish 决定使用的消息传递系统。 它提供点对点连接，低延迟，无单点故障以及异步消息传递，以在多个后端服务中进行事件驱动的处理和并行处理。 -2. 服务经过发现阶段以了解每个端点的位置后，消息将直接在服务之间传输。 这是一种无经纪人的模式。 消息不会集中到集中式服务中，然后再重新分发。 使用此模型，消息传递非常有效，因为没有中间跃点，因此减少了延迟。 他们特别不想让一个单独的组件来处理流量，然后传递消息。 这种方法减少了故障点和延迟。 -3. 被认为是节俭的，但是 YAMI4 因其异步操作而获胜。 Thrift 使用看起来像本地函数调用的 RPC 模型，这使得处理错误，超时等更加困难。YAMI4 是消息传递模型，而不是 RPC 模型。 -4. YAMI4 不处理服务发现方面，而是在发现阶段然后直接与其他服务对话的基础上构建自己的服务。 互联网的运作方式更多。 -5. 作为消息传递系统，消息不会调用对象上的方法。 也没有对象在网络上流动。 对象存在于服务中。 每个服务负责激活，钝化和调度操作。 - -## 处理多个社交网络 - -1. 他们的主要挑战之一是能够支持这么多不同且越来越不同类型的游戏。 -2. 尽可能使用*松耦合*的原理： - 1. 团队拥有的服务使团队结构与体系结构相匹配。 - 2. 服务保持良好定义的接口，以便每个团队可以迭代并部署自己的服务，而不会影响其他团队。 - 3. 当需要更改接口时，将对接口进行版本控制。 他们试图保持向后兼容性，以便其他团队不必推出更改。 -3. 为了促进所有这些，将一套通用的标准应用于所有服务： - 1. 公共服务运输（YAMI4） - 2. 通用操作标准，例如如何配置服务以及它们如何提供监视信息。 -4. 通用标准和松散耦合的结合使开发和运营团队既灵活又高效。 - -## 开发与运营 - -1. 服务彼此独立发布。 -2. 资源按服务分开。 一项服务出现问题不会影响不相关的服务。 -3. 团队是按服务组织的，尽管有一些重叠。 -4. 尽管存在密切的关系，但运营团队与开发团队是分开的。 没有大的交接阶段。 他们不只是在墙上扔一个释放。 操作包括在设计中。 -5. 开发人员不发布代码。 他们将其检入并由操作人员将其捡起。 -6. 团队在部署方面具有很大的灵活性。 大多数游戏每周发布一次。 一切都是迭代的，这意味着代码足以投入使用，但功能不一定完全完成。 每周发布周期对于带有虚拟物品的游戏特别有价值，因为用户喜欢每周都知道有新的令人兴奋的东西。 其他团队可以使用更长的功能块。 这取决于。 这是从事 SOA 的优势之一。 团队可以独立工作。 不需要一个发布周期。 - -## Java-服务器 - -1. Java 支持创建干净的可重用组件。 -2. 有大量的开源库。 -3. Java 是灵活的：它可用于实现 Web 应用程序，流程请求，批处理和事件驱动的系统。 -4. Java 有许多调优选项。 他们做了很多工作来调整垃圾回收以提高性能。 - -## 游戏设计 - -1. 为了使游戏用户享受 Playfish 的乐趣，它将数据驱动的设计与良好的，受人启发的古老游戏设计结合在一起。 数据可用于指导用户制作游戏的许多决策。 他们可以从数据中看到用户最擅长的事情。 这告诉了他们如何使游戏和个人游戏变得更好，以及在设计新游戏时该怎么做。 -2. Playfish 喜欢行为分析。 他们查看人们在游戏中正在做什么，然后问他们为什么。 在支持方面，客户端和服务器具有很大的能力来生成有关用户操作的事件。 然后处理这些事件，以创建有关用户在游戏中所做操作的汇总信息。 他们现在正在使用 EMR / Hadoop / Hive 来通过类似 SQL 的界面访问大量的数据。 在云中使用 EMR 的效果非常好，他们对此非常满意。 大量数据可以粒度形式存储，并且由于所有内容都可以并行工作，因此仍然可以快速找出所需内容，非常适合游戏产生的事件类型数据。 -3. 用户想要什么真是令人惊讶。 他们甚至可能自己都不知道。 人们认为他们想要的与人们实际使用的有所不同。 有时，用户会说他们确实想要一些昂贵的功能，但最终却没有使用它们。 然后是没有人提及但人们一直在使用的功能。 在论坛上发帖的人通常是不喜欢事物的人，因此很容易获得一种非常不平衡的观点，因为他们对游戏充满热情，讨厌任何变化。 数据有助于找出人们真正喜欢的东西。 -4. 游戏设计不能只是数据驱动的，否则游戏将毫无生气。 您必须正确获得数据驱动的平衡。 您不能仅仅按照数据说明的去做。 随您的灵感去增加或增加游戏中的内容，然后使用数据来完善游戏。 -5. 某些功能需要大量的工作来创建，但由于功能太复杂，用户并没有最终完成。 他们设置了渠道，以了解人们是否在完成功能之前就放弃了功能，然后他们就能找出原因。 也许某个功能需要调整或放弃。 参与度是用户对游戏的热爱程度的衡量标准。 然后，他们投资使人们回头的内容，以便生态系统得以发展。 -6. 敏捷+数据+设计=允许快速试用新启发的功能，以查看它们是否有效。 结果是一个有趣的游戏。 -7. 团队分为紧密的小组，这些小组具有完全的创作自由。 所有团队成员都对什么使游戏更有趣发表了意见。 -8. 运行游戏实验是为了寻找合适的位置，以查看合适的位置。 有些会成功，有些会失败。 - -## 得到教训 - -1. **建立一个利用应用程序特殊性质的体系结构。** Playfish 已针对其特定需求量身定制了一种体系结构。 不要尝试构建可以扩展所有内容的通用体系结构。 利用空间的本质，使生活尽可能轻松。 -2. **不用担心第一次正确**。 把东西拿出来，开始学习。 如果他们试图达到 3 年前的现状，那么他们仍然会构建系统。 他们提出了一些根本无法扩展的东西，但他们在 5 周内就解决了。 这是关键。 -3. **不要害怕坚持知道和了解的东西**。 选择您熟悉的东西。 您不需要选择最新和最酷的产品。 充分了解产品并能够预测产品在您的用例中的运作方式具有很多价值。 这样，您将减少很多麻烦。 -4. **首先保持简单，然后在需要时进行扩展**。 利用该提前期来构建您所需的内容。 -5. **碎片和 BLOB** 。 使用分片扩展写操作。 使用 BLOB 将每个用户的记录数减少到一。 这样可以加快对象访问速度，并允许在 RAM 中添加更多对象。 -6. **总是有一个粗略的想法，你将如何扩展**。 不要过早设计功能，但不要创建破坏性的依赖关系。 例如，可以在不进行适当缩放的情况下启动就可以了，拥有在分片后无法使用的功能也不是一件很酷的事情。 -7. **缩放数据比缩放处理**困难。 您在哪里存储数据？ 有多少人需要读写？ 无状态应用程序服务器使添加更多处理变得容易，而数据扩展则困难得多。 -8. **不要过度复杂**。 扩展简单系统更容易。 保持尽可能长的简单性。 这使您可以了解痛点所在，然后可以专门解决这些痛点。 许多人认为他们必须从第一天开始就建造巨大的东西。 例如，如果您不需要多级缓存，则不要放入它，因为您必须支持它。 -9. **使用 SOA 管理复杂性**。 随着新游戏的添加，将代码分成由不同团队管理的不同组件有助于降低系统的整体复杂性，从而使一切易于扩展。 -10. **承担计算的风险**。 Playfish 进入了云环境，但是有一个备份计划，以防万一失败。 这是一种风险，但也有很多好处。 如果亚马逊取消了他们的服务，那么如果他们真的需要，他们可以搬家。 这就是使用“基础架构即服务”的好处。 使用“平台即服务”存在更大的风险，因为您建立了更深的依赖关系。 例如，当 fPlayfish 拥有自己的有效键值数据库时，转移到 NoSQL 产品的风险也太大。 -11. **运营和开发应了解系统如何在生产中工作**。 容易管理吗？ 支持客户容易吗？ 如何配置和监视它？ 开发您需要实现所有这些的东西。 开发人员不能只是在墙上扔代码。 应该没有墙。 -12. **使用数据可以帮助您找到人们真正喜欢的东西。** 用户并不总是知道自己最喜欢什么。 检测您的代码并分析数据以找到有意义的模式，并使用该信息来不断改进系统。 -13. **最难扩展的是人**。 必须使人们的工作变得非常容易。 获得更多的服务器要比获得更多的人容易得多。 - -我要感谢 Playfish 抽出宝贵时间进行了这次翔实而有见地的采访。 如果您希望 HighScalability.com 上具有您的体系结构，请[与我](http://highscalability.com/contact/)联系以开始使用。 - -Playfish 正在寻找人。 有关职业机会，请参见其[职位页面](http://www.playfish.com/?page=jobs)。 从我与几个人的交往中，一个 Playfish，他们似乎把他们的东西放在一起。 值得一看的是，他们有很多空缺职位，他们正在寻找服务器端工程师。 他们希望构建新系统，以使用 EMR / Haddop / Hive 更好地了解用户，并扩展整个系统以添加更多用户和游戏。 - -## 相关文章 +# 我们如何在 Mail.Ru Cloud 中实现视频播放器 -1. [Playfish 展示了“游戏即服务”如何在云中扩展](http://www.readwriteweb.com/cloud/2010/08/playfish-shows-how-games-as-a-.php) -2. [访谈：Playfish 通过我的帝国在简单的动作中寻找意义](http://www.gamesetwatch.com/2010/08/interview_playfish_on_finding.php) -3. [AWS 案例研究：Playfish](http://aws.amazon.com/solutions/case-studies/playfish/) -4. [EA Playfish 高管吹捧下一代 Facebook 游戏](http://venturebeat.com/2010/05/14/ea-playfish-exec-sebastien-dehalleux-touts-next-generation-facebook-games/) -5. [深入了解：Playfish](http://blog.kissmetrics.com/an-in-depth-look-playfish/) -6. [介绍 Playfish](http://www.slideshare.net/sdehalleux/introducing-playfish) -7. [在社交游戏峰会](http://www.insidesocialgames.com/2008/06/13/lives-notes-from-asynchronous-games-on-social-networks-at-social-gaming-summit/)上直播“社交网络异步游戏”的笔记 -8. 视频： [SGS09：大规模构建社交游戏](http://www.youtube.com/watch?v=dLCSGm_tkfM)。 -9. 视频： [SGS2008：社交网络上的异步游戏](http://www.youtube.com/watch?v=3zIXY1upwTI)。 -10. [异步游戏](http://www.cs.vu.nl/~eliens/media/pattern-asynchronousgames.html)。 -11. [异步多人游戏：Ian Bogost 的休闲多人游戏体验](http://www.bogost.com/writing/asynchronous_multiplay_futures.shtml)的未来。 +> 原文： [http://highscalability.com/blog/2016/3/28/how-we-implemented-the-video-player-in-mailru-cloud.html](http://highscalability.com/blog/2016/3/28/how-we-implemented-the-video-player-in-mailru-cloud.html) -非常有趣的东西-感谢分享！ +![](img/4dc85258b3e084ceb6d7575e6f63baf6.png) -我真的没有这样的句子：“要招募更多的人要比招募更多的人容易得多。” 请解释。 +我们最近在 [Mail.Ru Cloud](https://cloud.mail.ru/) 中添加了视频流服务。 开发首先考虑将新功能用作通用的“瑞士军刀”，它将播放任何格式的文件并可以在具有可用云的任何设备上工作。 上传到云端的视频内容大体上属于两类之一：“电影/系列”和“用户视频”。 后者是用户使用手机和相机拍摄的视频，就格式和编解码器而言，这些视频用途最为广泛。 由于许多原因，在没有事先进行标准化的情况下在其他最终用户设备上观看这些视频通常是一个问题：缺少必需的编解码器，或者文件太大而无法下载，等等。 -谢谢托德，它非常有用。 +在本文中，我将详细介绍如何在 Mail.Ru Cloud 中播放视频，以及如何使 Cloud Player“杂食化”并确保对最大数量的最终用户设备的支持 。 -顺便说一句，我喜欢 Playfish 的运作方式： +## 存储和缓存：两种方法 -> 由于您的朋友很少同时在线，因此社交游戏是异步进行的。 +上传后，许多服务（例如 YouTube，社交网络等）会将用户的视频转换为适当的格式。 视频只有在转换后才能播放。 Mail.Ru Cloud 中使用了另一种方法：**原始文件在播放时会进行转换**。 与某些专门的视频托管网站不同，我们无法更改原始文件。 我们为什么选择此选项？ Mail.Ru Cloud 主要是一种云存储，如果用户在下载文件时发现文件质量下降或文件大小发生了一些变化，他们将感到非常惊讶。 另一方面，我们无法承受**存储所有文件的预先转换后的副本：这将需要太多空间**。 我们还必须做很多额外的工作，因为某些存储的文件将永远不会被监视，甚至一次也不会被监视。 -如果您认为 Cloud 最好，那显然是因为您尚未大规模使用它。 我们在亚马逊上运行着数百台服务器，而连接问题的数量（即无法到达实例，x 可用区网络问题）和它们具有的 I / O 性能让我们感到“惊讶”； 在过去的六个月中，他们最长可以无问题地停留的时间是 8 天，这意味着我们每周或更少的时间都会因为亚马逊的“超级云”而获得生产“成功”。 -我的建议：使用云来扩展和稳定，然后移开地狱。 干杯。 +快速转换的另一个优点是：如果我们决定更改转换设置或例如添加其他功能，则无需重新转换旧视频（并非总是如此） 可能，因为原始视频已经消失了）。 在这种情况下，一切都会自动应用。 -这是拼写错误的塞巴斯蒂安，谢谢。 +## 这个怎么运作 -克里斯，那是您的现代时代:-) +我们正在使用 Apple 创建的 HLS（HTTP 实时流）格式[进行在线视频流。 HLS 的思想是将每个视频文件都切成小片段（称为“媒体片段文件”），这些片段会添加到播放列表中，并为每个片段指定名称和时间（以秒为单位）。 例如，将一个两小时的电影切成十秒钟的片段，作为一系列 720 个媒体片段文件。 根据用户希望从哪一刻开始观看视频，播放器会从传输的播放列表中请求适当的片段。 **HLS** 的好处之一是**用户无需在播放器读取文件头时等待视频开始播放**（等待时间可能会很长） 如果是完整版电影且移动互联网速度较慢）。](https://developer.apple.com/streaming/) -很棒的文章 Tood，感谢您提供。 Playfish 在数据库分片方面的经验与我们在快速增长的 dbShards 实现中所发现的完全一样。 如上文所述，由于利用内存来实现数据库平衡，因此我们的社交应用程序以出色的性能运行。 +这种格式提供的另一个重要可能性是**自适应流**，它允许根据用户的 Internet 速度即时更改质量。 例如，您开始使用 3G 以 360p 观看，但是火车驶入 LTE 区域后，您将继续以 720p 或 1080p 观看。 它在 HLS 中非常简单地实现：播放器会获得“主播放列表”，其中包括针对不同带宽的备用播放列表。 加载片段后，播放器会评估当前速度，并据此决定下一个片段的质量：相同，较低或较高。 我们目前支持 240p，360p，480p，720p 和 1080p。 -关于此报价： +## 后端 -> 在横向扩展情况下，您必须进行分片之类的操作，此时许多 SQL 功能都将消失。 您必须自己做很多工作。 现在，当您进行大批拆分时，您将无法添加索引。 +， -我们可以轻松支持混合使用典型表和键/值 blob 数据，就像 Playfish 一样。 +[![](img/879db0a8b28049344985b588f867cedc.png) ](https://habrastorage.org/files/1c6/c3e/67d/1c6c3e67dd6c4b0bbe4c2595aeffd099.png) -我想知道其他人怎么想：传统表结构与键/值 Blob 的无缝结合？ 在这两种情况下，我们都可以支持高可用性操作，而无需开发人员的任何努力。 这样，您可以从常规表中获得所有索引/搜索优势，并且它们可以在适当的地方指向 Blob 值（例如，用户个人资料信息）。 +Mail.Ru 云服务由**三组服务器**组成。 第一组是**应用程序服务器**，它接受视频流请求：它创建一个 HLS 播放列表并将其发送回去，分发转换后的片段，并设置转换任务。 第二组是具有嵌入式逻辑的**数据库（ [Tarantool](http://tarantool.org/) ），用于存储视频信息并管理转换队列。 第三组**转换器**从 Tarantool 中的队列接收任务，然后将任务完成情况再次记录在数据库中。 收到视频文件片段的请求后，我们首先在我们的一台服务器上检查数据库，以获取转换后的质量要求的即用型片段。 这里有两种情况。** -很棒的文章。 +第一种情况：我们确实有一个转换后的片段。 在这种情况下，我们会立即将其寄回。 如果您或其他人最近提出了要求，则该片段将已经存在。 这是第一个缓存级别，适用于所有转换的文件。 值得一提的是，我们还使用了另一种缓存级别，其中经常请求的文件分布在多个服务器上，以避免网络接口过载。 -他们使用什么 Web 服务器？ \ No newline at end of file +第二种情况：我们没有转换后的片段。 在这种情况下，将在数据库中创建一个转换任务，我们等待它完成。 正如我们之前所说，它是 Tarantool（一个非常快速的开源 NoSQL 数据库，可让您在 Lua 中编写存储过程），它负责存储视频信息和管理转换队列。 应用程序服务器和数据库之间的通信如下进行。 应用服务器发出一个请求：“我需要 720p 质量的 movie.mp4 文件的第二个片段； 准备等待的时间不超过 4 秒钟”，并且在 4 秒钟之内它将收到有关从何处获取片段的信息或错误消息。 因此，数据库客户端对立即执行任务或通过一系列复杂的操作不感兴趣如何执行任务：它使用非常简单的界面，可以发出请求并接收所请求的内容。 + +我们提供数据库容错能力的方法是**主副本故障转移**。 数据库客户端仅将请求发送到主服务器。 如果当前的主服务器有问题，我们会将其中一个副本标记为主服务器，然后将客户端重定向到新的主服务器。 当客户端继续与主机交互时，这样的主副本切换对客户端是透明的。 + +除了应用程序服务器之外，还有谁可以充当数据库客户端？ 可能是那些准备开始转换片段的转换器服务器，现在需要到源视频文件的参数化 HTTP 链接。 这种转换器和 Tarantool 之间的通信类似于上述应用服务器的接口。 转换程序发出一个请求：“给我一个任务，我准备等待 10 秒钟”，如果任务在这 10 秒钟内出现，则将任务交给正在等待的转换程序之一。 我们在 Tarantool 内部的 Lua 中使用了 IPC 通道，以轻松实现客户端到转换器的任务转发。 通道允许不同请求之间的通信。 这是一些用于转换片段的简化代码： + +``` +function get_part(file_hash, part_number, quality, timeout) + -- Trying to select the requested fragment + local t = v.fragments_space.index.main:select(file_hash, part_number, quality) + + -- If it exists — returning immediately + if t ~= nil then + return t + end + + -- Creating a key to identify the requested fragment, and an ipc channel, then writing it + -- in a table in order to receive a “task completed” notification later + local table_key = msgpack.encode{file_hash, part_number, quality} + local ch = fiber.channel(1) + v.ctable[table_key] = ch + + -- Creating a record about the fragment with the status “want to be converted” + v.fragments_space:insert(file_hash, part_number, quality, STATUS_QUEUED) + + -- If we have idle workers, let’s notify them about the new task + if s.waitch:has_readers() then + s.waitch:put(true, 0) + end + + -- Waiting for task completion for no more than “timeout” seconds + local body = ch:get(timeout) + + if body ~= nil then + if body == false then + -- Couldn’t complete the task — return error + return box.tuple.new{RET_ERROR} + else + -- Task completed, selecting and returning the result + return v.fragments_space.index.main:select{file_hash, part_number, quality} + end + else + -- Timeout error is returned + return box.tuple.new{RET_ERROR} + end +end + +local table_key = msgpack.encode{file_hash, part_number, quality} +v.ctable[table_key]:put(true, 0) +``` + +实际的代码稍微复杂一点：例如，它考虑了在请求时片段处于“正在转换”状态的场景。 由于采用了这种方案，转换器可以立即收到新任务的通知，而客户端也可以立即收到任务的完成的通知。 这非常重要，因为用户看到视频加载微调器的时间越长，他们甚至有可能在视频开始播放之前就离开页面。 + +如下图所示，大多数转化，因此等待时间不会超过几秒钟。 + +![](img/9aa2115022459dd03949867463346deb.png) + +## 转换次数 + +对于**转换**，我们使用的是根据需要修改的 **FFmpeg** 。 我们最初的计划是使用 FFmpeg 内置工具进行 HLS 转换。 但是，我们的用例遇到了问题。 如果您要求 FFmpeg 将 20 秒的文件转换为具有 10 秒的片段的 HLS，则会得到两个文件和一个播放列表，它们可以毫无问题地播放。 但是，如果您要求先转换 0 至 10 秒，然后再转换 10 至 20 秒（启动 FFmpeg 转换器的另一个实例），则从一个文件转换为另一个文件时（大约在 10 秒），您会听到明显的喀哒声。 我们花了几天时间尝试不同的 FFmpeg 设置，但没有成功。 因此，我们必须进入 FFmpeg 并编写一个小补丁。 它需要一个命令行参数来解决“ click”错误，该错误源于对音频和视频轨道进行编码的细微差别。 + +此外，我们还使用了当时尚未包含在 FFmpeg 上游的其他一些可用补丁。 例如，一个[补丁](https://trac.ffmpeg.org/ticket/2513)，用于解决 MOV 文件转换缓慢的已知问题（由 iPhone 制作的视频）。 一个名为“ Aurora” 的**守护程序控制从数据库获取任务并启动 FFmpeg 的过程。 “ Aurora”守护程序以及位于数据库另一端的守护程序都是用 Perl 编写的，并且与 EV 事件循环和各种有用的模块异步工作，例如： [EV-Tarantool](https://github.com/Mons/EV-Tarantool) 和 [Async :: Chain](https://metacpan.org/pod/Async::Chain) 。** + +有趣的是，**没有为 Mail.Ru Cloud 中的新视频流服务**安装额外的服务器：转换（需要大量资源的部分）在特别隔离的环境中在我们的存储上运行。 日志和图形显示，我们的能力所能承受的负载是我们现在所能承受的几倍。 仅供参考：自我们的视频流媒体服务于 2015 年 6 月启动以来，已请求 **500 万以上的独特视频； 每分钟观看 500–600 个唯一文件**。 + +## 前端 + +如今，几乎每个人都拥有智能手机。 或两个。 为您的朋友和家人制作简短的视频没什么大不了的。 这就是为什么我们准备好有人将视频从手机或平板电脑上传到 Mail.Ru Cloud 并立即从其设备中删除视频以释放空间的情况。 如果用户想向他人展示此视频，则只需使用 Mail.Ru Cloud 应用程序将其打开，或在其桌面上的 Cloud Web 版本中启动播放器。 现在可以不在手机上存储所有视频片段，同时始终可以在任何设备上访问它们。 移动互联网上的流式传输比特率降低了，因此，以兆字节为单位的大小也降低了。 + +此外，在移动平台上播放视频时，我们使用 Android 和 iOS 本机库。 这就是为什么视频可以在移动浏览器中“开箱即用”的智能手机和平板电脑上播放的原因：我们无需为使用的格式创建额外的播放器。 与网络版本相似，在台式计算机上，自适应流机制被激活，并且图像质量动态适应当前带宽。 + +我们的播放器与竞争对手的播放器之间的主要区别之一是我们的视频播放器独立于用户的环境。 在大多数情况下，开发人员会创建两个不同的播放器：一个是带有 Flash 界面的播放器，另一个是（具有本地 HLS 支持的浏览器，例如 Safari），一个是完全相同的，但是用 HTML5 实现，随后上传了适当的文件。 接口。 我们只有一名球员。 我们的目标是可以轻松更改界面。 因此，我们的播放器在视频和音频方面看起来都非常相似-所有图标，布局等均以 HTML5 编写。 播放器不依赖于播放视频所使用的技术。 + +我们使用 Flash 绘制视频，但是整个界面都基于 HTML； 因此，我们不会遇到版本同步问题，因为不需要支持特定的 Flash 版本。 一个开放源代码库足以播放 HLS。 我们编写了一个垫片，将 HTML5 视频元素界面转换为 Flash。 这就是为什么我们可以假设我们将始终使用 HTML5 来编写整个界面的原因。 如果浏览器不支持这种格式，我们只需将本地视频元素替换为自己的实现相同界面的元素。 + +如果用户的设备不支持 Flash，则视频将以具有 HLS 支持的 HTML5 播放（到目前为止，仅在 Safari 中实现）。 使用本地工具在 Android 4.2+和 iOS 上播放 HLS。 如果没有支持且没有本机格式，我们将为用户提供文件下载。 + +## *** + +如果您有实现视频播放器的经验，欢迎访问评论部分：我非常想知道如何将视频分成多个片段，如何在存储和缓存之间进行选择，以及面临的其他挑战。 总之，让我们分享我们的经验。 + +[关于 HackerNews](https://news.ycombinator.com/item?id=11375147) + +很棒的文章！ + +很棒的文章。 您能告诉我们更多有关 ffmpeg 补丁以消除音频点击的信息吗？ + +谢谢。 如此棒的文章。 + +因此，转换的视频（频繁和较少）在 ttl 之后会自动删除吗？ +其次，为什么转换器使用 http 协议从存储中获取视频？ 使用套接字不能更快完成吗？ + +您启动了多少个 tarantool 实例？ TT 集群有多大？ + +对于此特定任务，我们只有两个实例-主实例和副本实例。 我们知道，在 Mail.Ru 集团的在线广告系统上，生产中的 Tarantool 集群的最大规模约为 500 个实例。 + +For this specific task we only have two instances - a master and a replica. The maximum knows to us size of a Tarantool cluster at production is around 500 instances at the Mail.Ru Group's online ad system. \ No newline at end of file diff --git a/docs/197.md b/docs/197.md index f3d8921..dcd0cbe 100644 --- a/docs/197.md +++ b/docs/197.md @@ -1,152 +1,200 @@ -# 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训 +# Twitter 如何每秒处理 3,000 张图像 -> 原文： [http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html](http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html) +> 原文： [http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html) -![](img/9351627c2ec5806610f7f7f5c93909d3.png) [社交新闻网站](http://en.wikipedia.org/wiki/Steve_Huffman) [Reddit](http://www.reddit.com/) 的共同创始人史蒂夫·霍夫曼做了出色的[演示文稿](http://vimeo.com/10506751)。（[幻灯片](http://www.slideshare.net/carsonified/steve-huffman-lessons-learned-while-at-redditcom)和[文字](http://carsonified.com/blog/dev/steve-huffman-on-lessons-learned-at-reddit/) ），学习他在将 Reddit 建立和发展到每月有 750 万用户，每月有 2.7 亿页面浏览以及 20 多个数据库服务器的过程中吸取的教训。 +![](img/500a76b4aabec6690f90dc3c55a27a21.png) -史蒂夫（Steve）说，很多课程确实很明显，因此您可能在演示文稿中找不到很多全新的想法。 但是史蒂夫对他有一种真诚和真诚，这显然是建立在经验基础上的，以至于您不禁要深思一下自己可能会做些什么。 如果史蒂夫不了解这些课程，我敢打赌其他人也不会。 +今天，Twitter 正在每秒创建并永久保存 3,000 张（200 GB）图像。 更好的是，由于媒体存储政策的改进，2015 年 Twitter 节省了 600 万美元。 -有七个课程，每个课程都有自己的摘要部分：第一课：经常崩溃； 第二课：服务分离； 第 3 课：开放式架构； 第四课：保持无状态； 第 5 课：内存缓存； 第 6 课：存储冗余数据； 第 7 课：脱机工作。 +并非总是如此。 2012 年的 Twitter 主要基于文本。 霍格沃茨没有在墙上挂满所有酷炫的动态图像。 现在是 2016 年，Twitter 已经进入了一个拥有丰富媒体的未来。 Twitter 已经通过开发新的*媒体平台*进行了过渡，该平台可以支持带有预览的照片，多张照片，GIF，藤蔓和嵌入式视频。 -到目前为止，其体系结构最令人惊讶的功能是在第六课中，其基本思想是：速度的关键是预先计算所有内容并将其缓存。 他们将预计算[旋钮最多旋转 11](http://en.wikipedia.org/wiki/Up_to_eleven) 。 听起来您在 Reddit 上看到的几乎所有内容都已被预先计算和缓存，无论它们需要创建多少版本。 例如，当有人提交链接时，他们会预先计算所有 15 种不同的排序顺序（热门，新，热门，旧，本周等）以用于列表。 通常，开发人员会害怕走极端，浪费时间。 但是他们认为浪费前期总比拖延慢。 **浪费磁盘和内存比让用户等待**更好。 因此，如果您一直坚持下去，请转到 11，这是一个很好的先例。 +Twitter 的软件开发工程师 [Henna Kermani](https://www.linkedin.com/in/henna-kermani-27701146) 在 [Mobile @上进行了有趣的演讲，讲述了媒体平台的故事 伦敦规模](https://www.atscalelondon.co.uk/) ： [每秒 3,000 张图像](https://code.facebook.com/posts/1566627733629653/mobile-scale-london-recap/) 。 演讲主要集中在图像管道上，但她说大多数细节也适用于其他形式的媒体。 -## 第一课：经常崩溃 +这次演讲中一些最有趣的教训： -本课的实质是：**自动重新启动失败的癌性服务**。 +* **做可能可行的最简单的事情确实会使您陷入困境**。 上载带有图像的 tweet 的简单方法是“全有或全无”操作，是一种锁定形式。 它的伸缩性不好，尤其是在网络较差的情况下，这使得 Twitter 很难添加新功能。 -在 colo 中运行自己的系统的不利之处在于您需要进行维护。 服务中断后，您必须立即修复，即使在凌晨 2 点。 这是您生活中持续不断的紧张感。 您必须随身携带一台计算机，并且您知道，任何时候只要有人打来电话，那都是您必须解决的另一场灾难。 它毁了你的生活。 +* **解耦**。 通过将媒体上传与推文脱钩，Twitter 能够独立地优化每种途径，并获得了许多运营灵活性。 -缓解此问题的一种方法是重新启动过程，该过程已经死亡或变得癌变。 Reddit 使用[监督](http://cr.yp.to/daemontools/supervise.html)自动重启应用程序。 特殊的监视程序会杀死使用过多内存，使用过多 CPU 或无响应的进程。 不必担心，只需重新启动即可启动系统。 当然，您必须阅读日志并找到根本原因，但是在那之前，它会使您保持理智。 +* **移动不处理斑点**。 请勿在系统中传输大量数据。 它占用了带宽，并为每个必须处理数据的服务带来了性能问题。 而是存储数据并使用句柄引用它。 -## 第 2 课：服务分离 +* 移至**分段可恢复上传**导致媒体上传失败率大大降低。 -本课的实质是：**将过程和数据分组在不同的盒子**上。 +* **实验和研究**。 Twitter 通过研究发现，图像变体（缩略图，小图像，大图像等）的 20 天 TTL（生存时间）是一个最佳选择，在存储和计算之间取得了很好的平衡。 映像在 20 天后被访问的可能性很小，因此可以将其删除，**每天节省近 4TB 的数据存储量**，**几乎减少了一半** **所需的计算服务器数量** ，每年可节省数百万美元。 -在一个盒子上做太多的工作会导致**在作业**之间进行大量上下文切换。 尝试使每个数据库服务器以相同的方式服务于相同类型的数据库。 这意味着您的所有索引都将被缓存，并且不会被调入和调出。 保持所有内容尽可能相似。 不要使用 Python 线程。 他们很慢。 他们将所有内容放在单独的多个流程中。 垃圾邮件，缩略图等服务可查询缓存。 它使您可以轻松地将它们放在不同的计算机上。 您已经解决了流程之间通信的问题。 一旦解决，它就可以保持体系结构整洁，并且易于扩展。 +* **按需**。 可以删除旧的图像变体，因为它们可以即时重新创建而不是预先计算。 按需执行服务可提高灵活性，使您对执行任务的方式更加了解，并提供集中控制点。 -## 第 3 课：开放式架构 +* **渐进 JPEG** 作为标准图像格式是真正的赢家。 它具有强大的前端和后端支持，并且在速度较慢的网络上表现非常出色。 -本课程的本质是：**不必担心模式**。 +Twitter 走向富媒体的未来之旅中发生了许多美好的事情，让我们了解一下他们是如何做到的... -他们过去经常花费大量时间来担心数据库，以保持一切正常和正常。 **您不必担心数据库**。 当您变大时，架构更新将非常缓慢。 将一列添加到一千万行需要锁定，因此不起作用。 他们使用复制进行备份和扩展。 模式更新和维护复制是一件痛苦的事情。 他们将不得不重新启动复制，并且可能一天没有备份。 部署是一件痛苦的事情，因为您必须协调新软件和新数据库的升级方式。 +## 旧方法-2012 年的 Twitter -相反，他们保留了事物表和数据表。 Reddit 中的所有内容都是事物：用户，链接，评论，subreddit，奖项等。事物具有共同的属性，例如上下投票，类型和创建日期。 数据表具有三列：事物 ID，键，值。 每个属性都有一行。 标题，URL，作者，垃圾邮件票等都有一行。当他们添加新功能时，他们不必再担心数据库了。 他们不必为新事物添加新表，也不必担心升级。 更易于开发，部署，维护。 代价是您不能使用很棒的关系功能。 数据库中没有联接，您必须手动执行一致性。 没有联接意味着将数据分发到不同的机器真的很容易。 您不必担心外键正在执行联接或如何拆分数据。 工作得很好。 使用关系数据库的烦恼已经成为过去。 +### 写入路径 -## 第 4 课：保持无状态 +* 用户在应用程序中撰写推文，并可能在其中附加图像。 -目标是让每个应用服务器处理每种类型的请求。 随着他们的成长，他们拥有更多的计算机，因此他们不再依赖于应用内服务器缓存。 他们最初将状态复制到每个应用程序服务器，这浪费了内存。 他们无法使用内存缓存，因为它们保留了大量的细粒度文件，这太慢了。 他们重写使用内存缓存，并且不将任何状态存储在应用服务器中。 如果应用服务器发生故障，则很容易。 为了扩展，您可以添加更多应用服务器。 + * 客户端将推文发布到整体端点。 该图像将与所有其他推特元数据捆绑在一起上传，并传递到流程中涉及的每个服务。 -## 第 5 课：内存缓存 + * 这个端点是旧设计中很多问题的根源。 -本课的实质是：**内存缓存所有内容**。 +* **问题＃1** ：大量浪费的网络带宽 -它们将所有内容存储在内存缓存中：1.数据库数据 2.会话数据 3.呈现的页面 4.记忆（记住以前计算的结果）内部功能 5.限制用户操作，爬网程序的速率 6.存储预先计算的列表/页面 7.全局 锁定。 + * 发推文的创建和媒体上载紧密地结合到一个操作中。 -他们现在在 Memcachedb 中存储的数据比 Postgres 多。 就像记忆快取一样，但是会储存在磁碟上。 非常快。 所有查询均由同一控件生成，并缓存在 memcached 中。 更改密码链接和关联状态被缓存 20 分钟左右。 验证码也一样。 用于他们不想永久存储的链接。 + * 正在上传，上传完全成功或完全失败。 由于任何原因导致的故障，网络故障，瞬态错误等，都要求整个上载过程从头开始重新启动，包括媒体上载。 上载可以完成 95％，如果失败，则必须重新上载所有内容。 -他们在其框架中内置了备忘录。 计算结果也将被缓存：标准化页面，列表，所有内容。 +* **问题 2** ：对于新的较大尺寸的介质，无法很好地扩展 -使用 memcache +到期日期对所有内容进行速率限制。 保护您的系统免受攻击的好方法。 没有速率限制子系统，单个恶意用户可能会破坏系统。 不好。 因此，对于用户和爬网程序，他们将很多内容保留在内存缓存中。 如果用户在一秒钟内再次出现，他们将被弹跳。 普通用户的点击速度不太快，因此他们希望引起注意。 Google 搜寻器会以您希望的速度打击您，因此，当速度变慢时，只需提高限速器的速度，即可使系统安静下来而不会伤害用户。 + * 这种方法无法扩展到视频等大型媒体。 较大的文件会增加失败的可能性，尤其是在新兴市场（如巴西，印度，印度尼西亚）网络缓慢且不可靠的地方，他们确实希望提高推文上传成功率。 -Reddit 上的所有内容都是清单：首页，方框中的评论页。 所有这些都预先计算并转储到缓存中。 当您获得列表时，它将从缓存中获取。 每个链接和每个注释可能都存储在 100 个不同的版本中。 例如，具有 30 秒钟旧 2 票的链接是单独呈现和缓存的。 播放 30 秒后会再次呈现。 等等。 HTML 的每个小片段都来自缓存，因此不会浪费 CPU 渲染时间。 当事情变慢时，只需添加更多缓存即可。 +* **问题 3** ：内部带宽使用效率低下 -当弄乱他们脆弱的不一致数据库时，他们使用内存缓存作为全局锁。 为他们工作甚至认为这不是最好的方法。 + * 连接到 TFE 的端点，即 Twitter 前端，用于处理用户身份验证和路由。 用户被路由到图像服务。 -## 第 6 课：存储冗余数据 + * 图像服务与 Variant Generator 对话，后者生成不同大小（例如小，中，大，缩略图）的图像实例。 这些变体存储在 BlobStore 中，BlobStore 是为大型有效负载（如图像和视频）优化的键值存储。 这些图像永远存在。 -本课程的实质是：**速度的关键是预先计算所有内容并将其缓存**。 + * 创建和保留推文的过程中还涉及许多其他服务。 因为端点是整体的，将媒体与推文元数据结合在一起，所以该捆绑包也流经所有服务。 如此大的有效负载被传递给了不直接负责处理图像的服务，它们不是媒体管道的一部分，但仍被迫进行优化以处理大型有效负载。 这种方法在内部带宽方面效率很低。 -建立慢速网站的方法是拥有一个完全标准化的数据库，按需收集所有内容，然后进行渲染。 它永远需要每个单独的请求。 因此，如果您有可能以几种不同格式显示的数据（例如首页，收件箱或个人资料中的链接），请分别存储所有这些表示形式。 因此，当有人来获取数据时，该数据已经存在。 +* **问题 4** ：膨胀的存储空间 -每个列表都有 15 个不同的排序顺序（本周热门，新，热门，旧）。 当某人提交链接时，他们会重新计算该链接可能影响的所有可能的列表。 前期可能有点浪费，但前期浪费比缓慢要好。 浪费磁盘和内存比让用户等待更好。 + * 不再需要几个月和几年前发布的推文中的图像，这些图像将永久存在于 BlobStore 中，从而占用了空间。 即使有时删除推文时，图像也会保留在 BlobStore 中。 没有垃圾收集。 -## 第 7 课：脱机工作 +### 读取路径 -本课程的本质是：**在后端上进行最少的工作，并告诉用户您已完成**。 +* 用户看到一条推文以及与之相关的图像。 图片从何而来？ -如果您需要做某事，请在用户不在等您时进行。 放入队列中。 当用户对可更新列表的 Reddit 进行投票时，该用户的 Karma 以及许多其他内容。 因此，一经表决，数据库便会更新以知道发生了表决，然后将作业放入队列中，该作业知道需要更新的 20 件事。 当用户回来时，一切都已经为他们预缓存了。 +* 客户端从 CDN 请求图像的变体。 CDN 可能需要询问图像的来源 TFE。 这最终将导致在 BlobStore 中直接查找特定大小的 URL 的图像。 -他们离线进行工作：1.预计算清单 2.提取缩略图 3.检测作弊。 4.删除垃圾邮件 5.计算奖励 6.更新搜索索引。 +* **问题 5** ：不可能引入新的变体 -用户正在等待您时，无需执行**这些操作。 例如，随着 Reddit 变得越来越大，现在作弊的动机越来越高，因此当人们投票检测作弊时，他们在后端花费了大量时间。 但是它们确实是在后台运行的，因此不会降低用户体验。 演示文稿中的体系结构图为：![](img/8358e9974e52fb2c996b8842c45df356.png)** + * 设计不是很灵活。 添加新的变体，即大小不同的图像，将需要为 BlobStore 中的每个图像回填新的图像大小。 没有随需应变的设施。 -蓝色箭头表示当请求进入时发生的情况。假设某人提交了链接或投票，它将转到高速缓存，主数据库和作业队列。 然后他们返回给用户。 然后其余的事件会离线发生，这些由粉红色箭头表示。 诸如 Spam，Precomputer 和 Thumnailer 之类的服务从队列中读取，进行工作并根据需要更新数据库。 关键技术是 RabbitMQ。 + * 缺乏灵活性使 Twitter 很难在客户端上添加新功能。 -## 相关文章 +## 新方法-2016 年的 Twitter + +### The Write Path + +#### 将媒体上传与发帖分离。 + +* 上传的内容为头等公民。 创建了一个上传端点，唯一的责任是将原始媒体放入 BlobStore + +* 这在处理上传方式方面提供了很大的灵活性。 + +* 客户端与 TFE 对话，后者与 Image Service 对话，后者将图像放入 BlobStore 中并将数据添加到元数据存储中。 而已。 没有涉及其他隐藏服务。 没有人在处理媒体，没有人在传递媒体。 + +* 从图像服务返回 mediaId（媒体的唯一标识符）。 当客户想要创建推文，DM 或更新其个人资料照片时，mediaId 将用作引用媒体的句柄，而不是提供媒体。 + +* 假设我们要使用刚刚上传的媒体创建一条推文。 流程如下： + + * 客户端点击更新端点，并在发布中传递 mediaId； 它将到达 Twitter 前端； TFE 将路由到适合于所创建实体的服务。 对于推文，它是 TweetyPie。 DM 和配置文件有不同的服务； 所有服务将与图像服务对话； 图像服务器具有处理诸如人脸检测和儿童色情检测之类的功能的后处理队列。 完成此操作后，Image Service 与 ImageBird 对话以获取图像，或与 VideoBird 对话以获取视频； ImageBird 将生成变体； VideoBird 将进行一些转码； 生成的任何媒体都将放入 BlobStore。 + + * 没有媒体通过。 节省了大量浪费的带宽。 + +#### 分段的可恢复上传。 + +* 走进地铁，在 10 分钟后出来，上传过程将从停止的地方恢复。 对用户而言是完全无缝的。 + +* 客户端使用上载 API 初始化上载会话。 后端将为它提供一个 mediaId，该 ID 是整个上传会话中要使用的标识符。 -* [关于可扩展性的队列相关文章](http://highscalability.com/blog/category/queue) -* [](http://highscalability.com/blog/category/queue)**[Reddit 于 2010 年 5 月发布的“服务器状态”报告](http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html)** +* 图像分为多个部分，例如三个部分。 使用 API​​附加分段，每个追加调用给出分段索引，所有附加都针对相同的 mediaId。 上载完成后，上载完成，可以使用媒体了。 -对我而言，最有趣的部分是数据库中糟糕的 EAV 解决方案。 不带模式和模式验证的所有内容都作为字符串。 这通常会导致维护和效率方面的一些可怕问题，但这一次它可以正常工作。 可能是因为该模型非常简单，在其他许多情况下却无法正常工作 +* 这种方法对于网络故障更具弹性。 每个细分都可以重试。 如果网络由于任何原因而掉线，您可以暂停并取回网络恢复时停在的网段。 -很棒的文章！ 绝对提供了一些非常新的性能思考方式。 +* 具有巨大收获的简单方法。 对于文件> 50KB，巴西的图像上传失败率下降了 33％，印度为 30％，印度尼西亚为 19％。 -“但是它们确实是在后台运行的，因此不会降低用户体验” +### The Read Path -“但是他们活着” +#### 推出了名为 MinaBird 的 CDN 原始服务器。 -“现场直播” +* MinaBird 可以与 ImageBird 和 VideoBird 对话，因此，如果不存在图像大小变体和视频格式变体，则可以即时生成它们。 -好文章！ 很好读 +* MinaBird 在处理客户端请求方面更流畅，更动态。 例如，如果有《数字千年版权法案》下架，很容易阻止访问或重新启用对特定媒体的访问。 -对于那些喜欢数学的人来说，每月 2.7 亿的页面浏览量就是每秒 100 个页面浏览量。 绝对不会出现需要 20 台数据库服务器的情况。 +* Twitter 能够即时生成变体和代码转换，因此 Twitter 在存储方面变得更加聪明。 -请谨慎选择您的建议。 互联网上很少有网站像 Reddit 一样频繁出现故障或性能不佳。 + * 按需变量生成意味着不需要将所有变量存储在 BlobStore 中。 巨大的胜利。 -我总觉得这些家伙在后台做些聪明的事。 感谢您告诉我更多有关我最喜欢的社交书签网站的信息！ + * 原始图像将保留直到删除。 变体仅保留 20 天。 Media Platform 团队针对最佳有效期限进行了大量研究。 所有请求的图像中大约有 50％的时间最多为 15 天左右。 保留比这更旧的图像会导致收益递减。 没人会要求使用较旧的媒体。 15 天后尾巴很长。 -哦，我只是喜欢这种性能知识。 + * 由于没有 TTL（生存时间），没有过期，因此媒体存储每天的存储量每天增长 6TB。 这种按需生成所有变体的惰性方法导致每日存储增长 1.5TB。 20 天的 TTL 使用的存储空间不会比惰性方法多得多，因此在存储空间方面并不会花费太多，但是在计算方面这是一个巨大的胜利。 使用懒惰的方法来计算读取的所有变体将需要每个数据中心使用 150 台 ImageBird 机器，而使用 20 天 TTL 则需要 75 台左右。 因此 20 天的 TTL 是最佳选择，可以在存储和计算之间取得良好的平衡。 -我们在设计架构以及随后像 Reddit 一样更新它们时也遇到了很多麻烦。 但是我必须同意 Simon 的观点，Reddit 的解决方案在许多其他情况下都行不通。 + * 由于节省存储空间和计算就是节省资金，2015 年 Twitter 通过引入 20 天 TTL 节省了 600 万美元。 -我同意 Haugeland 先生的观点，即必须拥有 20 台数据库服务器来处理负载似乎太过分了。 通过阅读评论，我看来原始作者未能认识到真正的教训。 这样的设计通常是开发团队不了解如何为底层数据库进行设计和编码的结果。 也许根据预期的使用情况和负载来选择错误的基础数据库。 +#### 客户端改进（Android） -这个已经过期了。 reddit 迁移到 Cassandra。 +* 使用 Google 创建的图像格式 [WebP](https://en.wikipedia.org/wiki/WebP) 进行了为期 6 个月的实验。 -http://www.reddit.com/r/programming/comments/bcqhi/reddits_now_running_on_cassandra/ + * 图像平均比相应的 PNG 或 JPEG 图像小 25％。 -记忆快取不见了 + * 锯增加了用户的参与度，尤其是在新兴市场中，在这些新兴市场中，较小的图像尺寸会降低网络压力。 + + * iOS 不支持。 + + * 仅在 Android 4.0+上受支持。 + + * 缺乏平台支持使 WebP 的支持成本很高。 + +* 渐进 JPEG 是 Twitter 尝试的另一种选择。 它在连续扫描中呈现。 第一次扫描可能是块状的，但是它将通过连续扫描进行完善。 + + * 更好的性能。 + + * 易于在后端支持。 + + * 的编码速度比传统 JPEG 慢 60％。 由于编码只会发生一次，而投放会发生多次，因此这不是一个大问题。 + + * 不支持透明度，因此保留了透明的 PNG，但是其他所有内容都在渐进 JPEG 上收敛。 + + * 在客户端， [Facebook 的 Fresco](https://github.com/facebook/fresco) 库提供了支持。 关于壁画有很多很好的话要说。 2G 连接的结果令人印象深刻。 首次扫描 PJPEG 仅需要大约 10kb，因此加载时间不会很长。 本机管道仍在等待加载，什么也没有显示，而 PJPEG 正在显示可识别的图像。 + + * 在 tweet 详细信息视图中正在进行的负载实验的结果。 p50 加载时间减少了 9％。 p95 加载时间减少了 27％。 故障率降低了 74％。 连接速度较慢的用户确实会获得巨大的成功。 + +## 相关文章 -哇！ 这是一项很好的工作！ +* [关于 HackerNews](https://news.ycombinator.com/item?id=11535418) -换句话说，运行可伸缩网站不该做什么。 我键入此内容时，Reddit 尚未再次打开。 +* [Twitter 用来处理 1.5 亿活跃用户，300K QPS，22 MB / S Firehose 的架构，并在 5 秒内发送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) -我是 Reddit 的粉丝，我希望它会改变其基础设施以提供更多可用性。 +* [Twitter 如何使用 Redis 进行扩展-105TB RAM，39MM QPS，10,000 多个实例](http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html) -MySQL（尤其是 MyISAM）给 RDBMSes 起了一个不好的名字。 +* [DataSift 架构：每秒 120,000 条推特的实时数据挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) -我有一个以 Poststars 为后盾的应用程序，该应用程序以“星型模式”组织，有一个主事件表，我们平均每秒对其进行 200 次 INSERT 插入，例如高峰时为 400 ish，有 24 列，其中大多数是外键 动态增长的查询表，我们在同一秒内结合在一起执行了十二打 INSERT / SELECT。 这些查询表之一具有超过 2.13 亿行。 向该表中添加另一列是即时的，并为应用程序带来了零延迟。 这是因为 Postgres 将列视为元数据。 +“今天，Twitter 正在每秒创建并保留 3,000（200 GB）图像。” -在 MySQL 中尝试这样做确实会“自杀”，而且绝对不是一种选择，因为 MySQL 需要重建整个表。 我不确定你们使用的是哪个版本的 Postgres，但是我发现锁定声明令人惊讶。 +与...不同 -如果您热衷于使用 MySQL，那么请尽一切可能不使用 MyISAM 的方法，尝试将所有基于文本的索引和搜索推迟到 Sphinx 之类。 并尽可能保留尽可能多的表。 +“ Twitter 可以创建大约 3,000 张独特的图像，并每秒传输大约 200 GB 的图像。” -实际上，“对所有内容进行预先计算”实际上是扩展应用程序的第一条规则。 他们只是把它带到了大多数人无法接受的地方。 +请不要更改其含义。 -很棒的帖子！ 我喜欢这种东西。 +我并不是要批评/挑剔这是什么引人入胜的文章，但是开头段落中的 200GB 数字不是很清楚–每秒 200GB：“每秒可保留 3,000（200 GB）图像” 。 -因此，您基本上将简单的键值存储入侵了 MySQL？ 为什么不使用 Cassandra，couchdb，东京暴君，redis？ +除非我缺少任何东西，否则这似乎是不正确的。 对于 3000 张图像，相当于 200GB，它们将需要很大的文件（每个〜68mb），而且每天 6TB 的存储量（无 TTL）将不可用（在 200GB /秒的情况下，它们需要更多 16PB /天，无 TTL）。 -我想知道 Reddit 使用什么队列解决方案，以及迁移到 Cassandra 后是否仍在使用它（我认为它仍然有用） +我尝试过数学，最合乎逻辑的是：200GB /分钟，这将使我们平均获得 1.3MB /图像，这看起来更准确，但仍然是 281TB /天。 -比较 Digg 和 Reddit 的加载时间，我想说 Digg 做得正确，而 Reddit 做错了。 +如果有人可以弄清楚我是不是愚蠢还是真正的价值应该是很棒的。 -您是否真的复制了本文的编辑内容？ 它充满了尴尬的写作，就像您在演示过程中起草并发布时一样，没有进行编辑。 第 4 课几乎是难以理解的。 +我认为 200GB 包含必要的复制。 因此，200GB 可能至少是图像原始大小的 3 倍。 -达克，我同意第 4 课不是很好。 我要做的是总结发言者的发言，使其更简短，更直接地适用。 有时我不知道该怎么做，所以我只保留原理图版本。有几条衬里我认为不值得在一个点上阐述，但我还是留了一点 如果您真的有兴趣，可以决定观看视频。 +另外，Twitter 可能需要每个图像有多个版本，例如 缩略图，原始图片等。每个都有不同的分辨率。 这就增加了很多存储空间。 -哦，瞧，又一家没有实际客户的网络创业公司，因此他们不必担心数据完整性，而且显然无力聘请知道数据库工作原理的人来决定适当的 RDBMS 设计是否起作用 首先，他们的问题显然不适合于关系模型。 现在他们有 40 台服务器从事 2 台服务器的工作，应该给我们留下深刻的印象吗？ 伙计们，雇用 DBA 比重塑持久性存储便宜得多。 +不管 Twitter 进行多少复制，仍然很难相信一张图像会占用约 66 MB 的空间。 数字/单位在这里肯定是错误的。 -开放模式部分使它看起来像是 NoSql 的理想候选者... +哦，这应该是“ Twitter 可以创建约 3,000 个唯一图像，每秒传输约 200 GB 图像。” 正如第一个评论试图指出的那样。 原始来源：https://code.facebook.com/posts/1566627733629653/mobile-scale-london-recap/ -chris h：只有确实要添加列时，Postgres 中的 no-locking 选项才可用。 如果要更改列的数据类型，或将列移到其他表，会发生什么？ +没有狗屎夏洛克，这些都是众所周知的技术，对不起，没什么有趣的。 -ChronicDB 声称将实时模式更改应用于 Postgres。 +你好 -@WayneB-digg 也不正确。 他们有 200 台服务器，现在处理的流量少于 reddit。 +好吧，我不认为客户端改进版在 Android 4.0+上受支持会存在任何问题，因为我记得该版本于 2011 年发布。 因此，可能每个人都拥有较年轻的版本。 -@John Haugeland：我完全同意你的看法。 这是一篇有关开发团队如何找到经验不足的解决方法的文章。 +这句话的意思很明确：“ Twitter 可以创建大约 3,000 个唯一的图像，并每秒传输大约 200 GB 的图像。” -这是一篇很有帮助的文章。 感谢您分享所有这些很棒的技巧。 希望他们能对您有所帮助！ +“创建大约 3,000 张独特的图像”：如果以 3 种不同的尺寸保存图像，则用户上传了 1,000 张图像。 +“每秒传输大约 200 GB 的图像”：并不是说它们存储 200 GB 的图像。 但是他们传输 200 GB。 这意味着它们每秒可交付 200 GB 的图像。 -Reddit 太慢了……我想他们有一些新的挑战和教训要学习，因为在大多数情况下它似乎无法使用。 \ No newline at end of file +他们是否将图像存储两次？ +图片服务将图片上传到 Blob 存储并返回 mediaId。 +mageBird 将生成变体； VideoBird 将进行一些转码； 生成的任何媒体都将放入 BlobStore。 \ No newline at end of file diff --git a/docs/198.md b/docs/198.md index 1a91072..1b38925 100644 --- a/docs/198.md +++ b/docs/198.md @@ -1,286 +1,189 @@ -# Sify.com 体系结构-每秒 3900 个请求的门户 +# 每天可处理数百万个请求的图像优化技术 -> 原文： [http://highscalability.com/blog/2010/5/10/sifycom-architecture-a-portal-at-3900-requests-per-second.html](http://highscalability.com/blog/2010/5/10/sifycom-architecture-a-portal-at-3900-requests-per-second.html) +> 原文： [http://highscalability.com/blog/2016/6/15/the-image-optimization-technology-that-serves-millions-of-re.html](http://highscalability.com/blog/2016/6/15/the-image-optimization-technology-that-serves-millions-of-re.html) -![](img/cfd4275d142a1fcf3dc491330469eee9.png) +![](img/53937b855f4361fee420d17dae2e415d.png) -Sify.com 是印度领先的门户网站之一。 Samachar.com 由同一家公司拥有，是印度顶级的内容汇总网站之一，主要针对来自世界各地的非居民印度人。 Sify 的建筑师 Ramki Subramanian 非常慷慨地描述了这两个站点的通用后端。 他们的架构最值得注意的方面之一是 Sify 不使用传统数据库。 他们查询 Solr，然后从分布式文件系统中检索记录。 多年以来，许多人争相使用数据库之上的文件系统。 文件系统可以用于键值查找，但不适用于查询，使用 Solr 是解决该问题的好方法。 他们系统的另一个有趣的方面是使用 Drools 进行智能缓存无效化。 随着我们在多个专业服务中复制越来越多的数据，如何使它们[同步](http://www.youtube.com/results?search_query=in+sync)成为一个难题。 规则引擎是一种聪明的方法。 +本文将介绍 [Kraken.io](https://kraken.io/) 如何构建和扩展每天可处理数百万个请求的图像优化平台，以保持 始终保持高性能，同时保持尽可能低的成本。 在撰写本文时，我们将介绍当前的基础结构，并介绍一些我们学到的有趣的知识，以便将其运用于此处。 -## **平台/工具** +### 让我们制作一个图像优化器 -* 的 Linux -* [浅色](http://www.lighttpd.net/) -* PHP5 -* 记忆快取 -* 阿帕奇·索尔（Apache Solr） -* Apache ActiveMQ /骆驼 -* GFS（群集文件系统） -* 德语 -* 雷迪斯 -* 带有 ActiveMQ 的子。 -* 漆 -* 流口水 +您想开始在 CDN 帐单上省钱，并且通常通过将较少的字节通过网络推送到用户的浏览器来加快网站速度。 很有可能超过 [的流量有 60％](http://httparchive.org/interesting.php) 仅是图像。 -## 统计资料 +使用 ImageMagick（您确实读过 [ImageTragick](https://imagetragick.com/) ，对吗？），您可以使用以下简单命令降低 JPEG 文件的质量： -* 每月约有 1.5 亿次网页浏览。 -* 服务 3900 请求/秒。 -* 后端在托管约 30 个 VM 的 4 个刀片上运行。 +$ convert -quality 70 original.jpg Optimized.jpg -## 建筑 +$ ls -la -* 该系统已完全虚拟化。 我们还使用了大多数 VM 功能，例如当一个刀片发生故障或需要重新分配负载时，我们在刀片之间移动 VM。 我们已经对虚拟机进行了模板化，因此我们可以在不到 20 分钟的时间内配置系统。 它目前是手动的，但是在系统的下一版本中，我们计划自动化整个供应，调试，退役，在 VM 周围移动以及自动缩放。 -* 没有数据库 -* 100％无状态 -* RESTful 接口支持：XML，JSON，JS，RSS / Atom -* 写入和读取具有不同的路径。 - * 通过 ActiveMQ / Camel 将写入排队，转换并路由到其他 HTTP 服务。 它用作 ESB（企业服务总线）。 - * 像搜索一样的读取操作是由 Web 服务器直接从 PHP 处理的。 -* Solr 用作索引/搜索引擎。 如果有人要求提供密钥的文件，则会直接将其送出存储空间。 如果有人说“给我所有在 author = Todd 处的文件，”它将打到 Solr，然后存储。 使用 Apache Solr 作为我们的搜索引擎来执行查询，并且我们有相同的分布式设置。 -* 所有文件都存储在群集文件系统（GFS）中。 查询打到 Solr，它返回我们想要的数据。 如果我们需要完整的数据，则在从搜索中获取 ID 后，我们将访问存储。 这种方法使系统完全可以水平扩展，并且对数据库的依赖性为零。 升级到最新版本后，对我们来说效果很好。 我们仅运行 2 个节点进行存储，如果需要，我们可以再添加几个节点。 -* 轻巧的前端 GFS。 Lighty 对于提供静态文件确实非常好。 对于我们拥有的文件类型（主要是小的 XML 和图像），每秒可以随意接收 8000 多个请求。 -* 所有最新的 NoSQL 数据库（如 CouchDB，MongoDB，Cassandra 等）都将替代我们的存储层。 在搜索功能上，它们都不接近 Solr / Lucene。 就查询而言，MongoDB 是最好的，但是``包含''之类的搜索需要使用正则表达式来完成，这对 500 万个文档来说是一场灾难！ 我们相信，目前，基于分布式文件系统的方法比许多用于存储的 NoSQL 数据库系统更具可伸缩性。 +-rw-r--r-- 1 matylla 职员 5897 5 月 16 日 14:24 original.jpg -## 未来 +-rw-r--r-- 1 matylla 职员 2995 May 16 14:25 Optimized.jpg -* 用于事件分析（用户点击，实时图表和趋势）的 CouchDB 或 Hadoop 或 Cassandra。 -* 使用 Drools 的智能缓存失效。 数据将通过队列推送，而 Drools 引擎将确定哪些 URL 需要无效。 它将在我们的缓存引擎或 Akamai 中清除它们。 方法是这样的。 查询（URL）到达我们的后端后，我们将记录该查询。 然后，记录的查询将被解析并推送到 Drools 系统中。 如果该输入尚不存在，则系统会将其输入并动态创建规则到系统中。 那是 A 部分。然后，我们的 Content Ingestion 系统将继续将进入 Drools 队列的所有内容推送。 数据输入后，我们将针对内容触发所有规则。 对于每个匹配的规则，生成 URL，然后我们将针对这些 URL 向缓存服务器（Akamai 或 Varnish）发出删除请求。 多数民众赞成在 B 部分。B 部分并不像上面提到的那么简单。 会有很多不同的情况。 例如，我们在查询中支持“ NOW”，大于，小于，NOT 等，这确实会让我们头疼。 - * 我们这样做的主要原因主要有两个，高速缓存命中率极高，并且几乎可以立即更新最终用户。 请记住，过去从未经历过的两个原因！ - * 我认为它将很好并且可以扩展。 Drools 确实擅长解决此类问题。 同样在分析中，我们发现查询在许多天内都是恒定的。 例如，我们每天有将近 40,000 个不同的查询，并且每天都会以几乎相同的模式重复。 对于该查询，只有数据会更改。 因此，我们可以设置多个实例并仅在不同系统中复制规则，这样我们也可以水平扩展它。 -* 同步读取，但是更少的层，更少的 PHP 干预和套接字连接。 -* 使用 Queue / ESB（Mule）进行分布式（写入不同的分片）和异步写入。 -* 使用 Varnish 或 Akamai 进行大量缓存。 -* 杀死 gron 并保持更接近实时的守护进程。 -* 使用 Gearman 进行并行和后台处理，以及用于自动缩放处理的自动附加处理功能。 -* 使用 Kaazing 或 eJabberd 向最终用户和内部系统实时分发内容。 -* Redis 用于缓存内容摘要以确定重复项。 -* 我们正在寻求使整个事情更易于管理，并从 app-admin 内部打开 VM 和进程。 我们研究了 Apache Zookeeper，研究了 VMWare 和 Xen 提供的 RESTful API，并与我们的系统进行了集成。 这将使我们能够进行自动缩放。 -* 我们拥有的最大优势是数据中心的带宽不受限制，因为我们自己就是 ISP。 我正在研究在系统中利用该优势的方法，并了解如何构建可以并行快速处理大量内容的集群。 +恭喜。 通过屠宰 JPEG 的质量，您刚刚将其压缩了约 50％。 图像现在看起来像 Minecraft。 它看起来不是这样-它可以销售您的产品和服务。 理想情况下，Web 上的图像应具有出色的质量，并且不会以过高的质量或 EXIF 元数据的形式出现不必要的膨胀。 -## 得到教训 +现在，您打开自己喜欢的图像编辑软件并开始以 Q 级播放，同时将 JPEG 保存为 Web。 事实证明，您测试的这张特定图片在 Q76 看上去很棒。 您开始以质量设置为 76 保存所有 JPEG。但是请稍等片刻...有些图像即使在 Q80 情况下也看起来很糟糕，而有些图像甚至在 Q60 时也很好。 -* ActiveMQ 多次被证明是灾难性的！ 套接字处理非常差。 从重启开始，我们通常会在不到 5 分钟的时间内达到 TCP 套接字限制。 尽管它声称已在 5.0 和 5.2 中进行了修复，但对我们而言并不起作用。 我们以多种方式尝试使它的寿命更长，至少一天。 我们通过部署带有新版本的旧库来解决问题，并使它的使用时间更长。 毕竟，我们部署了两个 MQ（消息队列），以确保至少对内容进行编辑更新可以正常进行。 - * 后来我们发现问题不仅在于此，而且使用主题也是一个问题。 仅对四个订阅者使用 Topic 会使 MQ 在数小时内挂起。 在大量脱发后，我们取消了整个基于主题的方法，并将它们全部排入队列。 数据进入主队列后，我们将数据推入四个不同的队列。 问题已解决。 当然，在 15 天左右的时间内，它将抛出一些异常或 OOME（内存不足错误），并迫使我们重新启动。 我们只是与它共存。 在下一个版本中，我们将使用 Mule 来处理所有这些问题，并且也将集群同时进行。 我们还试图找到一种方法来按消息顺序摆脱依赖关系，这将使分发变得更容易。 -* 索尔 - * 重新启动。 我们必须非常频繁地重新启动它。 尚不十分清楚原因，但是因为它具有冗余性，所以我们比 MQ 更好。 通过执行查询，我们已达到自动重启的程度，如果没有响应或超时，我们将重启 Solr。 - * 复杂查询。 对于复杂的查询，查询响应时间确实很差。 我们有大约 500 万个文档，并且很多查询的确在不到一秒钟的时间内返回，但是当我们有一个带有几个“ NOT”以及许多字段和条件的查询时，它需要 100 秒钟以上的时间。 我们通过将查询拆分为更简单的查询并将结果合并到 PHP 空间中来解决此问题。 - * 即时的。 我们遇到的另一个严重问题是 Solr 不能实时反映所做的更改。 大约需要 4 分钟到 10 分钟！ 考虑到我们所处的行业和竞争，迟到的新闻 10 分钟使我们变得无关紧要。 看过 Zoie-Solr 插件，但我们的 ID 是字母数字，而 Zoie 不支持。 我们正在寻找自己在 Zoie 中修复的问题。 -* GFS 锁定问题。 对于我们来说，这曾经是一个非常严重的问题。 GFS 将锁定整个群集，这将使我们的存储完全不可访问。 GFS 4.0 出现问题，我们升级到 5.0，从那时起似乎还不错。 -* Lighty 和 PHP 不太融洽。 性能方面都不错，但是 Apache / PHP 更稳定。 由于 PHP_FCGI 进程挂起，Lighty 有时会胡思乱想，CPU 使用率达到 100％。 +好的。 您决定以某种方式使其自动化-谁想要手动测试您拥有维护“特权”的数百万张图像的质量。 因此，您创建了一个脚本，该脚本可以生成不同 Q 级别的输入图像的数十个副本。 现在，您需要一个度量标准，该度量标准将告诉您哪个 Q 级适合特定图像。 MSE？ SSIM？ MS-SSIM？ PSNR？ 您如此绝望，甚至开始计算和比较输入图像不同版本的 [感知哈希](https://en.wikipedia.org/wiki/Perceptual_hashing) 。 -我非常感谢 Ramki 花时间写关于他们的系统如何工作的信息。 希望您能从他们的经验中学到一些有用的东西，这些对您自己的冒险有帮助。 如果您想共享您的优秀系统的架构，请同时向其付费和向后付费，请 [与联系我](../../contact/)，我们将开始。 +有些指标的效果要好于其他指标。 对于某些类型的图像，有些效果很好。 有些非常快，而另一些则需要很长时间才能完成。 您可以通过减少处理每个图像的循环次数来逃脱现实，但是很可能您错过了理想的 Q 级别，并且图像要么重于原来的水平，要么质量下降过高。 -相当有趣的信息！ 谢谢分享！ 每秒 3900 个请求非常棒。 +那么在白色背景下的商品图片呢？ 您真的想减少对象周围的振铃/晕影。 基于每个图像的自定义色度二次采样设置如何？ 如今，白色背景下的那件红色连衣裙看上去已经被洗掉了。 您已经了解到，剥离 EXIF 元数据将使文件大小变小一点，但是您还移除了 Orientation 标签，现在图像旋转不正确。 -目标响应时间是多少？ +那只是 JPEG 格式。 对于您的 PNG，您可能想重新压缩 7-Zip 或 Deflate 压缩后的图像，例如 Google 的 [Zopfli](https://github.com/google/zopfli) 。 您启动脚本并观看 CPU 上的风扇开始熔化。 -拉姆基 +您可能需要一个可靠的工具，该工具可以优化所有图像，无论格式如何。 [Kraken.io](https://kraken.io/) 是一种这样的工具。 -Lighty 曾经有内存泄漏。 Nginx 或 Cherokee 可能值得一看。 将 MogileFS 视为 GFS 的替代品-GFS 更像是 POSIX 文件系统的替代品，但是 MogileFS 可能“足够”，并且应该具有更大的可扩展性。 Solr －也许您需要分片搜索引擎，但这可能比它值得的工作更多。 ;-)使用 ActiveMQ，您是否考虑过将一些较轻的排队需求转移到 Redis？ 它具有可用于某些类型排队的原子构造，并且几乎可以肯定会更快。 +### 关于 Kraken.io -感谢如此出色的文章！ +Kraken.io 是图像优化和压缩 SaaS 平台，具有其他操作功能，例如图像大小调整。 我们的目标是尽可能自动缩小图像的字节大小，同时保持视觉信息的完整性和始终如一的高质量，从而无需手动检查结果的保真度。 -杰米 +### 软件 -精彩的帖子！ 很高兴看到有人实际构建事物而不是遵循流行语。 +除了基于 PHP 的 Kraken.io 前端外，几乎我们所有的软件都是在 [节点](https://nodejs.org/en/) 中编写的。 我们大量使用节点流，因为我们的优化管道可以使用二进制数据流。 -这些“ NoSQL”文档存储为您直接的分布式文件系统添加的功能正是使搜索与数据保持同步的能力。 有趣的是，与“愚蠢”的文档存储（文件系统）相比，您实际上为此功能付出了高昂的代价。 在我看来，保持这种状态的关键是在 Solr 搜索和数据之间出现延迟。 您愿意允许多少时间？ +当图片首次出现在我们的平台上时，首先会通过“ kraken-identify”过程进行抽签，以可靠地检测出最重要的功能-图像格式（JPEG，PNG，GIF，SVG 等），图像类型（逐行/ 基线 JPEG，动画/静态 GIF 等），以及嵌入的颜色配置文件和 EXIF 元数据的存在。 -考虑到这一点，对我来说，将 CouchDB 用作分布式文件系统似乎是个好主意。 我不敢相信它会比您使用的任何工具都要慢。 还有...继续使用 Solr！ 仅在需要同步搜索时才退回到 CouchDB“视图”。 +我们只需要读取几个字节，就不需要解压缩整个图像，也不需要将解压缩的数据加载到内存中。 -这似乎与“ NoSQL”的智慧几乎相反，但是从您的经验来看，这似乎是一个很好的实用结论。 +确定我们刚收到的文件确实是图像后，我们将对其进行进一步处理。 对于某些特定的图像，我们还计算了独特颜色的数量。 唯一色计数是一种直方图类型的操作，它固有的速度很慢，无法对压缩数据进行处理，因此我们仅在非常特定的图像子集上使用它。 -您是在 4 刀片系统上直接处理 3900 Request / second，还是还包括 Akamai 流量？ -您如何处理负载平衡？ +然后，图片会通过 HTTP 通过我们的优化管道传递。 这使我们可以将二进制数据（图像本身）与优化设置（作为字段或标头）一起抽取。 与我们的优化集群的 HTTP 连接保持打开状态，直到该过程完成，并且来自集群的 HTTP 响应被流回磁盘（直接流回 GlusterFS 目标位置），因此我们不会经常接触磁盘。 当我们从群集中流回整个响应时，任何优化后的数据都会通过 HTTP 标头传输。 -> “后端在托管约 30 个 VM 的 4 个刀片上运行。” +（可选），如果 API 用户请求，我们可以将优化的资产存储在他或她选择的外部存储中- [S3](https://kraken.io/docs/storage-s3) ， [Azure](https://kraken.io/docs/storage-azure) ， [云文件](https://kraken.io/docs/storage-cloudfiles) 或 [SoftLayer [](https://kraken.io/docs/storage-softlayer) 。 -what kind of 'front-end' infrastructure do you have? -What kind of VM are you running? VMWare? Xen? KVM? +最后一个任务（用于 API）是终止与 API 客户端的 HTTP 连接，并以优化结果作为响应，例如： -听起来好像他们正在将 HP Blade Matrix 与 VMware 一起使用。 +{ -“每月有 1.5 亿页面浏览量” -“每秒可处理 3900 请求”。 +“ file_name”：“ sku126933.jpg”， -算一下：3900 * 60 * 60 =每小时请求 14.000.000 -每天 8 小时：每天 14.040.000 * 8 = 112.000.000 -因此，其中一个 上面的值 +“ original_size”：35761， -Raghuraman：目标响应时间是多少？ +“ kraked_size”：10799， -拉姆基：我们不需要在后端系统中执行超过数千个 rp，因为前端系统的许多部分速度都较慢。 毕竟，系统中的薄弱环节定义了最终的要求/秒！ 如果我们可以使前端数量相同，那就太好了！ +“ saved_bytes”：22462， -杰米： +“ kraked_url”：“ https://dl.kraken.io/api/3e/db/24/08e20232a13c35fc1a72356537/sku126933.jpg”， -Lighty 曾经有内存泄漏。 Nginx 或 Cherokee 可能值得一看。 +“ original_width”：600， -Ramki：到目前为止，Lighty 对我们的表现一直很好，尽管在某些情况下，lighty 会让我们头疼。 Nginx 是一个不错的选择，我们可以尝试一下。 +“ original_height”：600， -杰米（Jamie）：将 MogileFS 视为 GFS 的替代品-GFS 更像是 POSIX 文件系统的替代品，但 MogileFS 可能“足够”并且应该具有更大的扩展性。 +“成功”：是 -Ramki：该系统的第一个版本在 MogileFS 中运行，并很快成为我们的大问题。 给我，在数据库中存储文件的元信息是一场灾难。 在短短几周内，数据库记录就接近 150 万。 查询变得非常缓慢...但是我喜欢基于 WebDAV 的方法的想法，因此我们尝试了不使用 MogileFS，但是我们的 LB 当时不支持 HTTP 1.1，因此我们取消了整个想法并将其移至文件系统。 +} -杰米（Jamie）：索尔（Solr）-也许您需要分片搜索引擎，但这可能比它的价值还多。 ;-) +对立即解析响应正文不感兴趣的用户可以使用我们的 [Webhook 传递系统](https://kraken.io/docs/wait-callback) 。 通过在请求中指定 callback_url，用户将指示 API 应用程序将优化结果 POST 到其自己的端点。 在这种情况下，我们排队一个 Webhook 任务（使用 Redis 作为代理）。 仅用于 Webhook 交付的其他计算机从队列中使用，POST 优化结果并将一些数据保存在 MongoDB 中。 -拉姆基：是的，我们已经记了这个。 +![](img/475b21b40578cce1b0ca3fb4ad356893.png) -杰米：使用 ActiveMQ，您是否考虑过将一些较轻的排队需求转移到 Redis？ 它具有可用于某些类型排队的原子构造，并且几乎可以肯定会更快。 +在 Kraken.io 帐户中交付了 Webhooks 视图 -Ramki：我们对 ActiveMQ 有点太深了。 它主要执行路由，服务抽象并为我们保证交付。 对于那些，我不会押注 Redis。 希望我回答了你的问题。 +### 硬件 -Tal：这些“ NoSQL”文档存储为您直接的分布式文件系统添加的功能正是使搜索与数据保持同步的能力。 有趣的是，与“愚蠢”的文档存储（文件系统）相比，您实际上为此功能付出了高昂的代价。 在我看来，保持这种状态的关键是在 Solr 搜索和数据之间出现延迟。 您愿意允许多少时间？ +图像优化和重新压缩具有巨大的处理要求。 由于我们一直在努力降低总拥有成本，因此对我们而言，云决不是一个选择。 通过与我们的数据中心签订相当长的合同，我们可以将托管费用减少 30％。 -Ramki：如文章中所述，DFS 用作键值存储。 并且我们已经设置了 MQ 先写入存储然后再写入 Solr。虽然将其推入 Q 使其异步，但数据的移动在 Q 内部是顺序的。这样一来，您将无法获得返回任何不存在的内容的搜索 在存储中。 同样，假设存储节点位于本地附近，则数据会立即反映出来。 希望我回答了你的问题。 +一小会儿，在投资购买自己的硬件之前，我们一直在租用专用机器。 那没有按预期工作。 当时，我们的提供商阻止了 OS 的重新部署，我们不得不采用痛苦而费时的电子邮件通信路径来重新部署系统。 另外，您不知道之前有谁在使用机器，机器的整体运行状况如何，以及内部“确实”安装了哪些组件。 有一天，我们发现，即使所有 API 机器都安装了相同的 CPU，但每台机器都有不同的 CPU 固件，并且 sysbench 的结果因机器而异。 -Tal：考虑到这一点，对我来说，将 CouchDB 用作分布式文件系统似乎是个好主意。 我不敢相信它会比您使用的任何工具都要慢。 还有...继续使用 Solr！ 仅在需要同步搜索时才退回到 CouchDB“视图”。 +幸运的是，这段时间已经过去很久了，我们在自己的硬件上运行，我们可以根据需要微调所有设置（尝试对租用设备进行 CPU 频率缩放）。 -Ramki：我们正在尝试使用 CouchDB 进行分析。 在开发环境中，我们的速度仅为每秒 1000 请求。 有了存储和轻松的设置，我们便可以轻松完成 8000+ reqs / s。 当然，1000 res / s 也是非常好的数字。 +所有单插槽计算机（API，Web，负载均衡器，Webhook Delivery）当前正在运行 Xeon E3-1280 v5（Skylake）。 对于完成所有艰苦工作的 Optimization Cluster，我们每台计算机使用 2 个 Xeon E5-2697 v3，具有 128 GB RAM 和 RAID-1 设置中的四个 SSD 硬盘进行镜像。 在启用 HT 的情况下，上述设置使我们可以在每个群集计算机上访问 28 个物理核心和 56 个线程。 -Tal：这似乎与“ NoSQL”的智慧几乎相反，但是从您的经验来看，这似乎是一个很好的实用结论。 +![](img/d41c0aa27e19d2ca09b52376afced93e.png) -Ramki：不确定是否与 NoSQL 相反。 原则上我们离它更近。 例如：没有“ sql” :)，几乎没有架构。 我说这几乎是因为 Solr 迫使我们拥有一些架构，分布式和键值之类的存储。 +我们的优化人员之一（Xeon E5-2697） -Maxim：您是在 4 刀片系统上直接处理 3900 Request / second，还是还包括 Akamai 流量？ +英特尔最近为 [E5-2600 产品线](http://ark.intel.com/products/family/91287/Intel-Xeon-Processor-E5-v4-Family#@All) 推出了 v4（Haswell），我们正在对此进行研究，但并不急于将群集升级到 v4 。 -Ramki：这里没有 Akamai。 它是我们所有的后端，不在 akamai 上。 一旦我们有了用于 URL 无效的缓存引擎和规则方法，我们将远远超过 3900 r / s。 我们的开发测试是 8500+ r / s 的清漆。 但是请记住，考虑到延迟，这些数字可能并不完全是我们将从外界得到的数字。 +Kraken.io 的平台占用大量 CPU 和 I / O，对大量文件进行繁重的处理。 为了在 I / O 级别获得更高的性能，我们将在接下来的几个月中为 API，集群和存储计算机推出 PCIe-SSD 驱动器。 -Maxim：您如何处理负载平衡？ +![](img/03f3c40b55674ebe74d20048d4ee8179.png) -拉姆基：这现在可以通过一种弯腰/麻木的方式来解决：)。 我们的资源有限，但是我们需要“无 SPOF”，因此我们在同一个 LB 内针对不同层有点循环。 考虑到 H / W LB 的成本，我们可能不得不采用这种方法。 我们正在寻找 S / W LB 作为替代方案，但我们需要使用刀片来部署它们！ :) +API，存储和优化集群 -塔尔：您拥有什么样的“前端”基础架构？ +自己的硬件需要一定的价格。 而且这个价格是，即使在高峰时期，您也需要比实际需要的容量多很多。 订购，压力测试和部署新机器最多需要 7 天的时间。 我们提供了一个定制的 AWS 集成，它将为我们提供计算优化的实例并扩展优化集群。 幸运的是，即使我们发现集群计算机上的负载高达 60（每个线程 1.07），我们也从未使用过它。 该解决方案的缺点是，我们不仅必须为 AWS 实例支付额外费用，而且还必须为数据中心与 AWS 之间的额外流量支付额外费用。 -Ramki：我们也在这里迁移到基于 VM 的环境。 但是再过几个月，我们将完全使用 VM，并在我们现在构建的系统之上运行。 旧系统将被淘汰。 +### 供应，发现和软件部署 -希望我已经回答了问题。 +我们安装的每台新计算机都由 [工头](http://theforeman.org/) 管理和配置。 我们将所有配置都保留在 [Puppet](https://puppet.com/) 中，因此只需单击几下即可使新机器进入生产就绪状态。 在 Puppet 中维护健康的代码库是另一个需要讨论的主题，尤其是在谈论定制软件包时。 -请确保提出建议。 我希望得到社区的反馈。 +通过 [Capistrano](http://capistranorb.com/) 进行软件部署。 因为所有应用程序都是用 Node 编写的，所以几乎所有应用程序都使用类似的配方。 当我们需要查明过去发生的特定部署并将其与 [中的可用数据关联时，与](https://www.serverdensity.com/) [Slack](https://slack.com/) 集成非常有用 ] ServerDensity 或 [ElasticSearch](https://www.elastic.co/) 。 --拉姆基 +![](img/789f0f90cf2f2ae722c7d6ab9b77ab6e.png) -嗨， -我研究的一件事是每秒 3900 req。 +Capistrano 的松弛集成 -您的每日网页价值为 1544943（http://www.websiteoutlook.com/www.sify.com）。 +### 数据存储 -因此，假设每位用户 5 次浏览量将带来每天 30 万用户或每小时 12500 位用户或每分钟 208 位用户。 +我们在三台独立的机器上使用 [副本](https://docs.mongodb.com/manual/replication/) 设置中的 [MongoDB](https://www.mongodb.com/) 作为我们的主要数据存储。 由于我们的数据集相对较小，并且我们对所有时间序列数据都使用了封顶集合，因此我们从未真正考虑过 DB 分片。 当然，看着三分之二的 DB 机器几乎什么也不做，只是等待 Master 失败，这不是我喜欢的事情，但是当时间到来时（而且会这样），我们会睡得很好。 -或大约每秒 3 个用户访问服务器。 +第二个数据存储是 [前哨](http://redis.io/topics/sentinel) 设置中的 [Redis](http://redis.io/) 出于与上述相同的原因）。 主要用作 Kraken.io 前端上的任务队列和会话管理的消息代理。 -所以我的问题是 3 个用户每秒可以生成 3900 个请求吗？ +### 文件存储 -RB & GK：如前所述，整篇文章都是关于后端而不是前端。 正如您在我上面的评论中所看到的那样，“如果我们能够使前端数量大约相同，那将是非常棒的事情！” +在上一代 Kraken.io 中，我们曾经将优化的资产直接存储在执行优化工作的同一台计算机上。 在将角色（API，Web，处理群集和存储）分离之后，我们发现自己迫切需要可扩展的网络文件系统。 [GlusterFS](http://www.gluster.org/) 易于设置且易于维护。 -后端不仅会受到前端的攻击。 后端有许多直接 API 调用。 +从应用程序服务器到 GlusterFS 计算机，我们有数百万个图像通过网络传输。 对于我们而言，非常重要的一点是不要经常移动这些文件。 一旦保存在 Gluster 中，图像将停留在该位置，直到其自动删除为止。 -因此，以上计算并不能完全转换为后端匹配。 +说到-清理作业。 通过 API 优化的图像会在 1 小时后自动删除，而通过 Web Interface 处理的图像会在我们的系统中保留 12 个小时。 在存储计算机上运行的清除脚本需要首先统计所有目录，并选择 mtime > 1hr（或 mtime > 12hr 的 Web Interface）。 当您拥有数百万个目录时，对其进行简单的统计可能会花费大量时间，并且我们希望清理脚本能够快速运行。 可行的简单补救措施是将具有优化映像的目录放入另外三个级别的两字符目录中。 -也就是说，我们已经在开发前端，希望我们能达到接近后端的数字。 +用作目标目录的原始文件 ID，例如 dd7322caa1a2aeb24109a3c61ba970d4 变为 dd / 73/22 / caa1a2aeb24109a3c61ba970d4 -如果你们在同一方面确实有一些投入，那就太好了。 +这样，我们最多可以在第一，第二和第三层上遍历 255 个目录。 --ramki +### 负载均衡器 -工具的传播非常有趣。 您对文件系统复制器有何建议？ 你是怎样做的 ？ -我们在一个城市中拥有 Windows SAN 存储。 我们想将添加和删除的文件实时复制到另一个城市的另一个 Windows 框中。 仅当完全写入文件时，才应复制文件。 +外部和内部负载平衡器都是 [Nginx](http://nginx.org/) -基于 [Keepalived](http://www.keepalived.org/) 。 即使我们的两个外部环境都出现问题，内部的环境也会自动提升自己，也为公共交通服务。 这也有助于我们晚上入睡，并给我们时间用新机器从柏林到法兰克福旅行（飞行 1 小时）。 -杰米：“ Lighty 曾经有内存泄漏。” +我们在内部计算机上未使用任何 HTTP 服务器。 所有内部流量都从负载均衡器直接反向代理到 Node 应用程序。 要记住的一件事-Nginx 默认使用 HTTP 协议 1.0 作为 HTTP 代理。 将 proxy_http_version 标志设置为 1.1 可以节省很多麻烦，并且通常可以提高性能，尤其是对于长时间运行的保持活动连接。 -过去……过去……一段时间以前……这有什么意义？ -Apache 过去有一些问题，nginx 过去有一些问题。 -软件并不完美，并且会通过更新得到修复。 -我运行了一堆 lightys，它们处理几乎相同数量的静态文件请求（8000 req / s）而不会费力。 -以及 PHP 的一些 Hundret re / s 也没有问题。 +### 联网 -很多人将内存泄漏误认为是 Lighty 缓冲来自后端（例如 PHP）的请求。 因此，如果您通过 Lighty 从 PHP 发送 10MB 数据，它将使用 10MB。 并且它将重新使用此内存以供以后的请求使用。 -为什么这样做？ 好吧，它有助于加快请求的速度，因为您只有数量有限的 PHP 后端，否则这些后端将被速度较慢的客户端占用。 它可以更快地释放 PHP“插槽”。 -我会在任何时候减少使用 RAM 的情况。 -要记住的唯一事情是不要通过 lighty 通过 PHP 发送大文件，这反而是一个坏主意，因为它还有其他一些原因（为此使用 X-sendfile 标头或直接提供它们）。 +由于我们在上行链路级别（两个独立的 10 Gbps 上行链路）上也很冗余，因此每个机架至少需要两个交换机，每台机器至少需要两个以太网控制器。 随着机架的增长，每台计算机占用交换机上的五个端口（BMC，到控制器 1 的上行链路 A 和 B 和到控制器 2 的上行链路 A 和 B），当前我们在每个机架上运行四个 HP ProCurve 交换机。 -因此，为了做出决定，而不是走“呃，但我听说有人过去有问题..”，而不得不*立即*并针对您的用例来研究它的工作方式。 +![](img/e10c297d02037a8efb5f0a6b9d03bcee.png) -我想讲的教训是：使用现在（以及将来当然）可以最好地完成任务的工具。 +Kraken.io Architecture，2016 年 5 月 -我以前曾经在 PHP 中看到过 100％CPU 的情况，这很奇怪，在某些情况下更新 PHP 很有帮助。 不幸的是，PHP 的 FastCGI 接口不如 mod_php 稳定。 但是它工作得很好。 +### 监视和警报 -Ramki：感谢您分享您的架构和经验教训，我发现无数据库方法特别有趣和令人耳目一新。 对 NoSQL 想法的深入了解可能不是更好的选择。 荣誉 +在上一代 Kraken.io 中，我们使用了 Sensu，Graphite 和 InfluxDB。 由于我们想将全部注意力转移到产品本身，而不是维护和监视监视工具（谁在监视正在监视它们的监视工具？），因此我们需要一种 SaaS 来减轻这种痛苦。 在测试了几项服务之后，我们最终选择了 [ServerDensity](https://www.serverdensity.com/) 作为我们所有机器的主要监视和警报工具，并且到目前为止，它仍然可以正常工作。 -没有， +![](img/f4965c287ba863ff68f9a572930631d2.png) -我不确定 websiteoutlook 的统计信息，但对于我知道其审计数的几个网站，它们显得有些低（10 倍）。 +ServerDensity 指标始终显示在我们的办公室中 -无论如何，每月有 1.5 亿次页面浏览量（是网站外观数字的 3 倍），平均每秒 57 次页面浏览量。 3900 次/秒是每页浏览 68 次（您的 3 个用户（真正是 3.57 个用户）x 5 页/访问 x 不足 3 的因素）。 头版页面有 80 个元素，即使缓存率很高，考虑到高峰期和一个前端请求也会导致多个后端请求，因此乘数似乎并不是很大的乘数。 +作为一项附加措施，我们使用 [Pingdom](https://www.pingdom.com/) 进行正常运行时间和实时用户监视。 我们已经从 Pingdom 看到了一些误报，而解决之道只是增加警报失败所需的检查数量。 -广泛的数字对我来说似乎很合理。 +### 数据挖掘 -关于进行综合浏览和请求计算的人员： +当我们尝试将支持的技术数量保持在最低限度时，我们使用了外部 ElasticSearch 提供程序。 平均每天，我们会发送 2GB 的日志以进行进一步处理和数据挖掘。 可以这样查询 ES 非常方便： -将网页浏览量视为用户的完整呈现页面是很常见的，这反过来可能转换为针对后端的 1 到 50 个请求，具体取决于呈现页面所需的后端信息源的数量。 +“为我提供 800 Kb 以下的 JPEG 文件的优化结果，该文件具有嵌入式 ICC 配置文件，唯一颜色计数大于 10.000，用户 X 在 3 天前进行了无损优化”。 -您无法对它们进行计算，因为您将对苹果和梨进行计算。 -每月观看次数总计超过 30 天，而 3900 req / s 则是特定时刻的峰值 +在我们不断努力改进优化堆栈时，我们需要能够立即跟踪我们的部署结果。 在峰值负载下，只需在“优化群集”中进行一些细微调整即可，然后在几分钟内获得有意义的数据。 -根据视图的数量和使用情况的一些假设，您可以计算出大约并发用户的平均数，该数量永远不会接近峰值时的并发用户数。 +### 摘要 -您正在运行哪个 GFS 版本的 GFS1 或 GFS2？ 您将在文件系统中存储多少数据？ -我们曾经将许多数据存储在 GFS（1）中，但是由于可伸缩性问题而远离了它。 +如果您到目前为止做的不错，那将涵盖 Kraken.io 基础结构工程的有趣部分。 我们确信，随着我们的发展和订户数量的增长，我们将继续学习更多，希望您喜欢本文。 -主要问题是锁定，无法扩展文件系统而没有停机时间以及对复制/冗余的不良/不存在的支持。 从那时起，我们的数据量已经增长到了惊人的水平。 1 PB。 -我也很好奇您用于在以下位置存储 GFS 数据的基本存储硬件：iscsi，光纤，AoE？ +[关于 HackerNews](https://news.ycombinator.com/item?id=11910151) -拉蒙 +我总是喜欢阅读有关图像优化的文章。 +但是在本文之后，我检查了 kraken.io 网站，以及所有可用的信息... :( -Mohan Radhakrishnan：您对文件系统复制器有何建议？ 你是怎样做的 ？ 我们在一个城市中拥有 Windows SAN 存储。 我们想将添加和删除的文件实时复制到另一个城市的另一个 Windows 框中。 仅当完全写入文件时，才应复制文件。 +总体来说不错。 尽管看到整条文章中散布着大量的“流行语”，这似乎是一种绝技。 不过，请欣赏本文的坦率。 -Ramki：我们已经尝试解决这个问题已有相当长的时间了。 到目前为止，我们仅在一个数据中心上运行，并且 GFS 集群安装在局域网中的 2-3 个节点上，因此其他节点可以立即看到每次写入。 鉴于此，我们没有复制问题。 +对于正在为其 Web 应用程序寻求图像优化服务的人的旁注-现代 CDN 已经将此作为其产品的核心部分。 Instart Logic 特别提供了出色的图像优化服务，您可以利用专有算法利用它来转换图像，调整图像大小并降低图像质量。 -但是，我们已经在寻找在大约 800 英里之外的印度两个城市中部署应用程序的选项，我们希望使用主动-主动设置。 根据上下文，我们要求存储提供商在两个城市之间进行实时复制。 作为 ISP，我们的延迟相对较小（我认为），大约 40 毫秒。 即使有这种延迟，任何存储提供商都无法做到近乎实时。 有一家公司说我们可以做到，并要求他们证明这一点。 他们部署了箱子，这是灾难性的失败！ 当然，这都是异步复制，同步复制是同时关闭两个站点的最佳方法！ 玩笑！ :)同步锁定源文件系统，同步到另一个站点，其他站点锁定文件系统，写入，确认到源，源站点释放锁定。 在这段时间内，编写文件的客户端正在等待……您猜对了。 +您可以在构建时压缩和缩小映像，然后可以由您选择的任何 CDN 进行选择。 这个过程已经使用了数十年。 -总结： --如果您的延迟超过 5 毫秒且实时，则任何存储提供商都无法做到这一点。 即使延迟对您来说较小，也请他们先进行证明。 --构建您自己的复制系统。 保持异步。 +这是我们今天在 [CircleHD](https://circlehd.com "CircleHD") 使用的一些工具 -我们现在正在考虑做的是： +gifsicle-压缩 GIF 图像 +jpegtran-压缩 JPEG 图像 +optipng-压缩 PNG 图像 +svgo-压缩 SVG 图像 -我们已经将内容推送到 MQ。 现在，内容也将被推送到其他城市的另一个队列。 这样，几乎可以立即在两个位置复制数据。 然后我们将接受可能会有的轻微延迟。 我认为延迟将少于 5 秒，这比存储提供商建议的 10-15 分钟复制更好。 无论如何，我们必须自己进行测试。 我们拥有的一大优势是，甚至文件的删除也是 XML 请求，因此也要经过 Q。 - -对于较大的二进制文件（视频&图像），我们采用略有不同的方法。 所有这些都写入临时目录，并且守护程序将文件移动到适当的目录。 我认为有 2 个城市时，这不会给我们带来很多头痛。 除了基于 ESB / MTOM 的方法外，别无其他想法，并通过队列推送元数据。 - -Ramon：您正在运行哪个版本的 GFS 或 GFS2？ 您将在文件系统中存储多少数据？ -我们曾经将许多数据存储在 GFS（1）中，但是由于可伸缩性问题而远离了它。 - -主要问题是锁定，无法扩展文件系统而没有停机时间以及对复制/冗余的不良/不存在的支持。 从那时起，我们的数据量已经增长到了惊人的水平。 1 PB。 - -Ramki：我们在 GFS1 上遇到了同样的问题，我们现在在 GFS2 上。 但是，当我们必须在 VM 上运行节点时，仍然存在扩展问题。 支持的虚拟机数量不超过 2 个，添加集群的第 3 个节点有时会挂起。 也许这也是 GFS1 的问题，我们担心被吊死。 您对此有一些了解吗？ 当前数据大小约为 1.5 Tera。 我们尚未将旧内容迁移到新系统。 - -拉蒙：我也想知道您用来在 GFS 数据上存储 iscsi，光纤，AoE 的底层存储硬件吗？ - -Ramki：iSCSI - -希望答案。 - --ramki - -您还将向用户提供电子邮件。 您是否还保留没有数据库的身份验证记录？ - -另外，你们使用哪个邮件服务器？ - -嗨 Ramki， - -想知道你们是否看过 AWS（http://aws.amazon.com）？ 在它们上运行会简化你们正在做的许多 VM 管理工作吗？ - -它们还提供了负载平衡和自动扩展解决方案（http://aws.amazon.com/autoscaling/）和队列服务（http://aws.amazon.com/sqs/）。 - -嗨，杜沙尔， - -我们查看了 AWS 的其他项目。 我们面临的最大问题是延迟。 我们不能忍受这种延迟。 - -除此之外： --我们有自己的管道 --我们在各个城市都有自己的数据中心。 --我们已经在下文中介绍了许多内容。 - -因此，在我们的案例中，这实际上没有任何意义。 - --ramki \ No newline at end of file +@AgnivaDeSarker：我很好奇您在上一篇文章中有什么资格成为“流行语”？ \ No newline at end of file diff --git a/docs/199.md b/docs/199.md index e6ac0f7..4f9c223 100644 --- a/docs/199.md +++ b/docs/199.md @@ -1,122 +1,241 @@ -# MocoSpace Architecture-一个月有 30 亿个移动页面浏览量 - -> 原文： [http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html](http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html) - -![](img/11ff48d533ea1c680de217f81e0e152a.png) - -这是 [MocoSpace](http://www.mocospace.com/) 的联合创始人&首席技术官 Jamie Hall 的客座帖子，描述了他们的移动社交网络的体系结构。 这是一个及时的体系结构，因为它结合了多个热门趋势：它非常大，具有移动性和社交性。 他们认为对他们的系统特别酷的是：如何针对移动 Web 上的设备/浏览器碎片进行优化； 他们的多层，读/写，本地/分布式缓存系统； 选择 MySQL 之上的 PostgreSQL 作为可扩展的关系数据库。 - -MocoSpace 是一个移动社交网络，每月有 1200 万会员，页面浏览量达 30 亿，这使其成为美国流量最高的移动网站之一。 成员主要通过其手机 Web 浏览器访问该站点，从高端智能手机到低端设备以及 Web 都可以访问。 该网站上的活动包括自定义配置文件，聊天，即时消息，音乐，共享照片&，视频，游戏，电子贺卡和博客。 获利策略的重点是在移动和网站上投放广告，以及虚拟货币系统和少量高级功能升级。 - -## 统计资料 - -1. 每月 30 亿页面浏览量 -2. 仅次于 MySpace，Facebook 和 Google（http://www.groundtruth.com/mobile-is-mobile）的流量最大的 4 个移动网站 -3. 75％的行动网路，25％的网路 -4. 1200 万会员 -5. 每月 600 万唯一身份访问者 -6. 10 万个并发用户 -7. 每月上传 1200 万张照片 -8. 每天收到 200 万封电子邮件，垃圾邮件 90％，每天发送 250 万封 -9. 8 位开发人员，2 位质量检查人员和 1 位系统管理员组成的团队 - -## 平台 - -1. CentOS +红帽 -2. 树脂应用服务器-Java Servlet，JavaServer Pages，Comet -3. PostgreSQL 的 -4. 记忆快取 -5. ActiveMQ 的工作+消息队列，在 Red Hat 集群中以实现高可用性 -6. Squid-静态内容缓存，尝试使用 Varnish 但存在稳定性问题 -7. jQuery + Ajax -8. S3 用于用户照片&视频存储（8 TB），EC2 用于照片处理 -9. F5 BigIP 负载平衡器-粘性会话，所有页面上的 gzip 压缩 -10. Akamai CDN-每天 2 TB，每天有 2.5 亿个请求 -11. 监视-Nagios 发出警报，Zabbix 发出趋势 -12. EMC SAN-通过 RAID（RAID 10）大量磁盘为数据库提供高 IO 性能，用高性能 Fusion-io 固态闪存 ioDrive 代替，成本效益更高 -13. PowerMTA 用于邮件传递，梭子鱼垃圾邮件防火墙 -14. Subversion 源代码控制，Hudson 进行持续集成 -15. FFMPEG 用于移动到 Web 和 Web 到移动视频的转码 -16. 用于浏览器测试用例自动化的硒 -17. 网络层 - 1. 5 个 Dell 1950、2 个双核，16G RAM - 2. 5 个 Dell 6950 / R905、4 个双核，32G RAM -18. 数据库层 - 1. 2 个 Sun Fire X4600 M2 服务器，8 个四核，256G RAM - 2. 2 个 Dell 6950、4 个双核，64G RAM - -## 建筑 - -1. 所有页面都是动态的，具有用户数据和自定义以及许多针对浏览器和设备的优化。 移动设备上的浏览器和设备碎片问题比 Web 上的问题要严重得多。 许多优化，基于浏览器功能的改编，对 CSS / JavaScript 的有限支持，屏幕尺寸等。移动 Web 流量通常通过网络代理（网关）提供，而对 Cookie 的支持较差，因此会话管理和用户标识成为一个挑战。 -2. 一个巨大的挑战是处理移动 Web 上的设备/浏览器碎片-为各种设备功能进行优化（从带触摸屏的 iPhone 到 5 岁摩托罗拉 Razrs 的所有产品），屏幕尺寸，缺乏/不一致的 Web 标准合规性等。 我们将表示层抽象出来，以便我们可以从同一代码库向所有移动设备提供页面，并维护一个大型设备功能数据库（包含诸如屏幕尺寸，支持的文件类型，最大允许的页面尺寸等内容），用于 推动我们网页的生成。 该数据库包含数百种设备和移动浏览器类型的功能详细信息。 -3. 根据用户密钥对数据库进行分片，并具有将用户映射到分片的主查询表。 我们滚动了自己的查询和聚合层，使我们可以跨碎片查询和联接数据，尽管这种方式并不经常使用。 通过分片，我们可以牺牲一些一致性，但是只要您不经营银行就可以。 我们分批离线进行数据一致性检查，目标是最终实现一致性。 大表被分成较小的子表，以提高访问效率，减少了为更新和操作维护活动而锁定表的时间。 用于热备份的日志传送。 -4. 使用了多层缓存系统，数据在应用程序服务器中本地缓存，并通过 Memcached 分发。 进行更新时，我们不仅使缓存无效，然后在再次从数据库中读取后重新填充缓存，而是使用新数据更新 Memcached 并保存另一次数据库访问。 更新缓存时，无效指令会通过消息队列发送到每个应用程序服务器上的本地缓存。 -5. 分布式消息队列用于分布式服务器通信，从用户之间实时发送消息到系统消息（例如本地缓存无效指令），应有尽有。 -6. 专用服务器，用于完全在内存中构建和遍历社交图，用于生成好友推荐等。 -7. 负载平衡器，用于在不影响性能/流量的情况下滚动部署网站的新版本。 -8. 每 2 周发布一次。 较长的发布周期=指数复杂性，更难进行故障排除和回滚。 负责部署和管理生产系统的开发团队（由您构建，管理）。 -9. Kickstart 用于自动从裸机构建服务器。 Puppet 用于将服务器配置为特定的个性，即 Web 服务器，数据库服务器，缓存服务器等，以及将更新的策略推送到正在运行的节点。 - -## 得到教训 - -1. **让您的箱子流汗**。 只要响应时间可以接受，就不要担心系统负载过大。 我们将多达五个应用程序服务器实例包装在一个盒子中，每个实例在不同的端口上运行。 在扩展之前，请先扩展到高端商品硬件。 可以廉价购买二手或翻新的强大 4U 盒子。 -2. **了解您的瓶颈在各个层次中的位置**。 您是否绑定了 CPU 或 IO（磁盘，网络）？ 数据库几乎总是受 IO（磁盘）约束。 一旦数据库无法容纳在 RAM 中，您就会碰壁。 -3. **认真地配置数据库**。 专注于优化数据库。 扩展 Web 层既便宜又容易，而数据库层则又困难又昂贵。 通过执行时间和执行频率，了解系统上最重要的查询。 跟踪和基准化每个版本的主要查询，需要及早发现并解决数据库的性能问题。 我们使用 pgFouine 日志分析器和新的 PostgreSQL pg_stat_statements 实用程序实时生成概要分析快照。 -4. **设计为禁用**。 能够配置和关闭即时发布的任何内容，而无需更改或部署代码。 负载和压力测试很重要，但没有什么比通过逐步分阶段推出的实时生产流量进行测试了。 -5. **仅在绝对必要时才进行同步通信**。 当一个组件或服务发生故障时，不应关闭系统的其他部分。 在后台或作为单独的线程或进程来做您可以做的所有事情，不要让用户等待。 尽可能批量更新数据库。 任何在网络外部发出请求的系统都需要主动监控，超时设置以及故障处理/重试。 例如，我们发现 S3 延迟和故障率可能很高，因此我们将失败的呼叫排队，然后重试。 -6. **考虑在设计期间进行监视，而不是在**之后进行监视。 每个组件都应产生性能，运行状况，吞吐量等数据。 当警报超过阈值时设置警报。 显示所有实例（而不是每个实例）的指标的综合图表对于一目了然地发现问题和趋势特别有帮助，应该每天进行检查-如果不能很好地理解正常的操作行为，则无法识别和应对不正常的情况。 t。 我们尝试了许多监视系统-仙人掌，神经节，Hyperic，Zabbix，Nagios，以及一些定制的解决方案。 无论您使用哪个最重要的东西，都要对它感到舒服，否则您将不会足够使用它。 使用模板等可以轻松监视新包装盒和服务，并在放置它们时迅速进行。 -7. **分布式会话可能会产生很多开销**。 只要有可能就进入无状态状态，但是当您不考虑粘性会话时。 如果服务器发生故障，用户将丢失其状态，可能需要重新登录，但这很少见并且可以接受，具体取决于您需要执行的操作。 -8. **监视并提防 Java** 中的全部/主要垃圾回收事件，该事件最多可以锁定整个 JVM 30 秒。 我们使用并发标记扫描（CMS）垃圾收集器，该垃圾收集器引入了一些额外的系统开销，但能够消除完整的垃圾收集。 -9. 当站点足够大时，无论是站点内部还是外部，通过电子邮件等，它都会吸引垃圾邮件散布者和黑客，而 Captcha 和 IP 监视是不够的。 必须**积极投资于检测和围堵系统**，这是检测可疑用户行为并发出警报和/或尝试自动围堵的内部工具。 -10. **尽可能软删除**。 将数据标记为以后删除，而不是立即删除。 删除的成本可能很高，因此要花几个小时才能排队，此外，如果有人犯了一个错误并删除了他们不应该拥有的东西，那么回滚很容易。 -11. **N + 1 设计**。 不得少于两个。 - -我非常感谢 Jamie 花时间编写此体验报告。 这是对其他人学习的真正有用的贡献。 如果您想共享 fablous 系统的体系结构，请 [与联系我](../../contact/)，我们将开始。 +# Facebook 如何向 80 万同时观看者直播 -## 相关文章 +> 原文： [http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) + +![](img/98c9699f964c1091947cf4dcdf2cd262.png) + +与拥有 核武器的国家相比，很少有公司知道如何建立全球性的分布式服务。 Facebook 是其中一家公司， [Facebook Live](https://www.facebook.com/livemap/) ，Facebook 的 [新](https://live.fb.com/about/) 实时视频 流产品，就是这些服务之一。 + +Facebook CEO [马克·扎克伯格](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)： + +> 我们做出的重大决定是将我们的许多视频工作重点转移到 Live 上，因为这是一种新兴的新格式； 而不是过去五到十年一直在线的那种视频……我们正在进入视频的新黄金时代。 如果您快进五年，人们在 Facebook 上看到并每天分享的大部分内容都是视频，我不会感到惊讶。 + +如果您从事的是广告业务，那么比提供永无止境，始终在扩展且可自由生成的广告就绪内容更好？ 当 Google [开始在呈指数增长的网络上投放广告时，就利用了](http://www.wsj.com/articles/SB108319881076696889) 来进行经济分析。 + +Facebook 的流媒体表演的一个例子是两个人的 45 分钟视频 [用橡皮筋爆炸西瓜](https://www.buzzfeed.com/brendanklinkenberg/this-exploding-watermelon-was-facebook-lives-biggest-hit-to) 。 它达到了超过 80 万同时观看者的顶峰，这些评论者还收集了 30 万以上的评论。 这就是您可以通过拥有 15 亿用户的社交网络产生的病毒规模。 + +作为比较 [1.14 亿](http://www.statista.com/statistics/216526/super-bowl-us-tv-viewership/) 观看了 2015 年超级碗的观众，平均 [观看者有 236 万 实时流中的](http://money.cnn.com/2015/10/26/media/nfl-yahoo-live-stream-results/) 。 Twitch 的 [840,000](http://www.geekwire.com/2015/amazons-twitch-attracts-monster-audience-at-e3-with-21m-viewers-tuning-in-online/) 观众人数在 2015 年 E3 达到顶峰。9 月 16 日的共和党辩论在 [921,000 达到顶峰 ]](http://www.politicususa.com/2015/10/14/debate-watched-democratic-debate.html) 同时直播。 + +因此，Facebook 处于最新状态。 请记住，Facebook 也会同时有大量其他流。 + +一篇有线文章 [引用了](http://www.wired.com/2016/04/facebook-really-really-wants-broadcast-watch-live-video/) Facebook 首席产品官 Chris Cox，他说 Facebook： + +* 有超过**个**现场直播人员。 （[从[12]开始](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)，现在该项目有 150 多名工程师） + +* 需要能够提供**数百万个同时流**而不会崩溃。 + +* 需要能够在流上支持**数百万同时观看者，以及全球不同设备和服务提供商之间的无缝流。** + +Cox 说：“事实证明这是一个非常困难的基础架构问题。” + +如果我们有一些有关如何解决该基础结构问题的详细信息，这会很有趣吗？ 祸是我们。 但是等等，我们做到了！ + +[Federico Larumbe](https://www.linkedin.com/in/federicolarumbe) 来自 Facebook 的流量小组，该小组致力于为 Facebook 的 CDN 和全球负载平衡系统提供支持的缓存软件，并发表了精彩的演讲： [扩展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) ，他在其中分享了有关 Live 工作方式的一些详细信息。 + +这是我在演讲中的发言。 令人印象深刻 + +## 起源故事 + +* Facebook 是一项新功能，允许人们实时共享视频。 （请注意，这对于 Facebook 来说只是另一个功能）。 + +* 于 2015 年 4 月推出，只有名人才能通过 [提及应用](https://www.facebook.com/about/mentions/) 作为与粉丝互动的媒介使用。 + +* 这是产品改进和协议迭代开始的一年。 + + * 他们以 HTTP 实时流媒体 [HLS](https://en.wikipedia.org/wiki/HTTP_Live_Streaming) 开头。 它受 iPhone 支持，并允许他们使用现有的 CDN 架构。 + + * 同时开始研究 [RTMP](https://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol) （实时消息协议） ，这是一种基于 TCP 的协议。 从手机发送到实时流服务器的是视频流和音频流。 + + * 优点：RTMP 在广播者和观看者之间具有较低的终端等待时间。 在人们相互交流的交互式广播中，这确实有所作为。 然后，降低等待时间并减少几秒钟的延迟，将使体验有所不同。 + + * 劣势：由于它不是基于 HTTP 的，因此需要一个完整的体系结构。 需要开发新的 RTMP 代理以使其扩展。 + + * 还研究了 [MPEG-DASH](https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) （基于 HTTP 的动态自适应流）。 + + * 优势：与 HLS 相比，它的空间效率高 15％。 + + * 优点：它允许自适应比特率。 编码质量可以基于网络吞吐量而变化。 + + * [吹笛者中出压缩解决方案](https://www.crunchbase.com/organization/pied-piper#/entity) ：（开个玩笑） + +* 于 2015 年 12 月在数十个国家/地区推出。 + +![](img/cc9254808fa61d8f01212c2503be1c30.png) + +## 实时视频与众不同，这会引起问题 + +* 前面提到的西瓜视频的流量模式： + + * 最初的上升非常陡峭，在几分钟之内达到了每秒 100 多个请求，并持续增长直到视频结束。 + + * 然后，流量像石头一样下降。 + + * 换句话说：流量非常大。 + + ![](img/20bf250cc8477b6987d45ae83f3d37c1.png) + +* 实时视频与普通视频不同：它会导致**尖峰** **流量模式**。 + + * 实况视频更具吸引力，因此观看**的**比普通视频多 3 倍。 + + * 实时视频出现在新闻源的顶部，因此被观看的可能性更高。 + + * 通知会发送到每个页面的所有粉丝，以便另一组可能会观看视频的人。 + +* 高峰流量会导致缓存系统和负载平衡系统出现问题。 + +* **缓存问题** + + * 很多人可能希望同时观看直播视频。 这是您的经典 [雷电牧群问题](https://en.wikipedia.org/wiki/Thundering_herd_problem) 。 + + * 尖刻的流量模式给缓存系统带来压力。 + + * 视频被分割成一秒钟的文件。 当流量激增时，缓存这些段的服务器可能会过载。 + +* **全局负载平衡问题** + + * Facebook 在全球分布 [个存在点](https://en.wikipedia.org/wiki/Point_of_presence) （PoP）。 Facebook 流量在全球范围内分布。 + + * 挑战在于防止峰值使 PoP 过载。 + +## 大图片架构 + +这就是直播流从一个广播公司到数百万观众的方式。 + +* 广播员在其手机上开始直播视频。 -* [移动社交网络 MocoSpace 现已拥有 1100 万会员](http://techcrunch.com/2010/03/17/mobile-social-network-mocospace-now-11-million-members-strong/ "Mobile Social Network MocoSpace Now 11 Million Members Strong") -* [MocoSpace 的工作方式](http://computer.howstuffworks.com/internet/social-networking/networks/mocospace.htm) +* 手机将 RTMP 流发送到实时流服务器。 -我想知道 ActiveMQ 工作意味着什么？ +* 实时流服务器解码视频并将代码转换为多个比特率。 -很棒的帖子。 这是我们真正了解战 the 的帖子。 -保持良好的工作。 -费利佩 +* 对于每个比特率，将连续生成一秒钟的 MPEG-DASH 段。 + +* 段存储在数据中心缓存中。 + +* 从数据中心缓存段被发送到位于存在点的缓存（PoP 缓存）。 + +* 观看者在观看时会收到一个实时故事。 + +* 他们设备上的播放器开始以每秒 1 个的速率从 PoP 缓存中获取片段。 + +## 它如何缩放？ + +* 数据中心高速缓存和**许多 PoP 高速缓存**之间有一个**乘法点**。 用户访问 PoP 缓存，而不是数据中心，并且全世界分布着许多 PoP 缓存。 + +* 另一个乘数是每个 PoP 中的**。** + + * 在 PoP 中有**两层**：一层 HTTP 代理和一层缓存。 + + * 查看器从 HTTP 代理请求段。 代理检查该段是否在缓存中。 如果在缓存中，则返回该段。 如果不在缓存中，则将对该段的请求发送到数据中心。 + + * 不同的**段存储在不同的缓存**中，从而有助于跨不同的缓存主机进行负载平衡。 + +## 保护数据中心免受雷电袭击 + +* 当所有观众同时请求相同的片段时会发生什么？ + +* 如果该段不在高速缓存中，则将向每个查看器发送一个请求到数据中心。 + +* **请求合并** 。 通过将请求合并添加到 PoP 缓存中，减少了请求数量。 仅第一个请求发送到数据中心。 其他请求将一直保留，直到第一个响应到达并将数据发送给所有查看者为止。 + +* 新的缓存层已添加到代理，以避免 **Hot Server 问题**。 + + * 所有查看器都发送到一个缓存主机，以等待该片段，这可能会使主机过载。 + + * 代理**添加了缓存层**。 实际上，只有第一个对代理的请求才向缓存发出请求。 以下所有请求均直接从代理服务。 + +## PoP 仍然处于危险之中-全局负载平衡正在救援 + +* 因此，保护​​数据中心不受雷电群问题的影响，但 PoP 仍然处于危险之中。 Live 的问题是尖峰非常大，以致 PoP 可能在 PoP 的负载度量达到负载平衡器之前过载。 + +* 每个 PoP 具有数量有限的服务器和连接性。 如何防止峰值导致 PoP 过载？ + +* 名为 Cartographer 的系统将 Internet 子网映射到 PoP。 它测量每个子网和每个 PoP 之间的延迟。 这是延迟测量。 + +* 测量每个 PoP 的负载，并将每个用户发送到具有足够容量的最近 PoP。 代理中有一些计数器可以衡量它们承受的负载量。 这些计数器是汇总的，因此我们知道每个 PoP 的负载。 + +* 现在存在一个优化问题，该问题会考虑容量限制并最大程度地减少延迟。 + +* 使用控制系统时，存在测量延迟和反应延迟。 + +* 他们将负载测量窗口从 1.5 分钟更改为 3 秒，但仍然有 3 秒的窗口。 + +* 解决方案是在实际发生负载之前 **预测负载** 。 + +* 实施了**容量估算器**，将每个 PoP 的先前负载和当前负载外推到未来负载。 + + * 如果负载当前正在增加，预测器如何预测负载将减少？ + + * **三次样条**用于 [插值](https://en.wikipedia.org/wiki/Spline_interpolation) 功能。 + + * 取一阶和二阶导数。 如果速度为正，则负载将增加。 如果加速度为负，则表示速度正在降低，最终将为零并开始降低。 + + * 三次样条比线性插值预测更复杂的交通模式。 + + * **避免振荡** 。 此插值功能还解决了振荡问题。 + + * 测量和反应的延迟意味着对过时的数据做出决策。 插值可减少误差，更准确地进行预测并减少振荡。 因此负载可以更接近目标容量 + + * 当前预测是基于 最近的三个间隔 ，其中每个间隔为 30 秒。 几乎是瞬时负载。 + +## 测试 + +* 您需要能够使 PoP 过载。 + +* 构建了一个负载测试服务，该服务在 PoP 上全局分布，以模拟实时流量。 + +* 能够模拟 10 倍的生产负荷。 + +* 可以模拟一次请求一个片段的查看器。 + +* 该系统有助于揭示和修复容量估计器中的问题，以调整参数，并验证缓存层是否解决了雷电群问题。 + +## 上传可靠性 + +* 实时上传视频具有挑战性。 + +* 以具有 100 至 300 Kbps 可用带宽的上载为例。 + +* 音频需要 64 Kbps 的吞吐量。 + +* 标清视频需要 500 Kbps 的吞吐量。 + +* 手机上的自适应编码用于调整视频+音频的吞吐量不足。 视频的编码比特率根据可用的网络带宽进行调整。 + +* 决定上传比特率的方法是在手机中通过测量 RTMP 连接上的上传字节来完成，并且对最后间隔进行加权平均。 + +## 未来方向 + +* 研究一种推送机制，而不是请求拉机制，利用 HTTP / 2 在请求分段之前将其推送到 PoP。 + +## 相关文章 -我很好奇为什么 Sun Fire 支持数据库？ +* [关于 HackerNews](https://news.ycombinator.com/item?id=11987654) -关于第 7 课：粘性会议更好？ 通过将用户锁定到特定服务器，您是否限制了更有效地进行负载平衡的能力？ 你们有 10 台 Web 服务器。 粗略地说，如果您丢失一台服务器，则会损失 10％的容量，并且 10％的当前访问者将丢失会话。 使用无粘性设置，如果您丢失一台服务器，则只会丢失 10％的容量，但不会有用户丢失会话。 从负载平衡设置中删除服务器将更加容易。 +* [扩展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) -您正在使用 F5 进行哪种负载均衡？ 愚蠢的循环赛吗？ 还是从每个服务器收集更具体的指标并基于此加载？ 您是将客户端连接一直传递到每​​个 Web 服务器，还是将 F5 用作反向代理？ +* [为什么 Facebook 和 Mark Zuckerberg 都参与直播视频](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video) -您在哪里进行 ffmpeg 编码？ 在那些列出的服务器上还是其他地方？ +* [连接世界：Facebook 网络基础架构](http://cs.unc.edu/xcms/wpfiles/50th-symp/Moorthy.pdf) -你们为什么要选择 Zabbix 和 Nagios？ 为什么其他解决方案对您不起作用？ +* [Gamoloco](https://gamoloco.com/) 跟踪 1476093 个频道的实时视频统计信息。 -您在地理上分布吗？ +Google Chrome 浏览器告诉我您的网站已感染恶意软件。 也许是个调皮的广告？ -如果您在某些方面使用 S3 和 EC2，为什么不将其余基础架构移至亚马逊或其他云呢？ +我很乐意在具有如此高流量的平台上工作。 12 位工程师可以毫无问题地做到这一点。 很少有人可以在应用程序上工作，甚至可以进行额外的数据压缩，而在主平台上则很少。 我什至可以处理 100-200k 观众的实时流，唯一的限制是资金有限；）我还是不明白 150 位工程师在这方面做了什么... 很抱歉，我目前没有客户，流量非常大。 -即使有所有缓存，你们还是需要 Fusion-io 吗？ +150 名工程师可以同时建立 10 个创业公司！ 没有留下深刻印象。 -这真的是非常有用的帖子。 感谢您分享这一点。 +我不知道为什么 Google 网站管理员工具 Dobes 会显示该网站存在我什至无法在该网站上找到的问题，但是却没有说出它是否带有恶意软件。 -是什么让他们选择了 PostgreSQL 而不是 MySQL？ 使用了什么标准？ -他们使用任何 Java 框架吗？ +我不知道 Facebook 工程师的自我来自何处。 毫无疑问，这是一个很难解决的问题，但我认为这与核武器的复杂性不相上下。 -最好的祝福 +Facebook live 的问题都不是新问题。 它们是成熟的技术，许多公司已经多次解决了它们。 -@Maxim R +规模仍然非常可观，我想你们应该专注于此。 -1.我们不在地理上分布 -2\. F5 是基于会话的负载平衡。 有许多 iRules 导致一些流量直接传递到 Web 服务器，从 F5 缓存提供服务，或从 Squid 缓存提供服务 -3\. ffmpeg 编码在批处理服务器 -上完成。4\. S3 和 EC2 相当 昂贵。 我们可以从戴尔购买一个全新的盒子，然后在几个月内拿回我们的钱，而不是几个大型实例。 由于我们不必处理“嘈杂的邻居” -，因此性能也更可预测。5。显然，使用分布式会话将为我们提供更大的灵活性，但是会带来较大的开销。 使用粘性会话是/有中间立场。 -6.关于 Fusion-IO，所有页面都是动态创建的，因此我们需要很高的 I / O 吞吐量。 随着站点的增长，I / O 要求也随之提高。 +我对 MPEG-DASH 感到担心，“它允许自适应比特率。编码质量可以根据网络吞吐量而变化”。 那是优点还是缺点？ 谢谢。 -您曾想过[哇，这些家伙看起来不错/专业]直到 - `Development team responsible for deploying to and managing production systems "you built it, you manage it"` +自适应比特率通常被认为是一个优势，因为只要带宽高于最小比特率，流就不会中断。 -部分。 如果我是你，我会在投资者会议上保密。 \ No newline at end of file +顺便说一下，就我所知，MPEG-DASH 与 HLS 本质上相同，都允许自适应比特率。 \ No newline at end of file diff --git a/docs/2.md b/docs/2.md index 87cbcbb..09919f4 100644 --- a/docs/2.md +++ b/docs/2.md @@ -1,819 +1,33 @@ -# Egnyte Architecture：构建和扩展多 PB 内容平台的经验教训 +# mixi.jp 体系结构 -> 原文： [http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html) +> 原文： [http://highscalability.com/blog/2007/7/10/mixijp-architecture.html](http://highscalability.com/blog/2007/7/10/mixijp-architecture.html) -![](img/cd669c781d6a9a0f1fd802de7a2578a4.png) +Mixi 是日本快速发展的社交网站。 他们提供的服务包括：日记，社区，消息，评论和相册。 与 LiveJournal 有很多共同之处，他们还开发了许多相同的方法。 他们撰写有关如何扩展系统的文章很容易成为目前最好的之一。 -这是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的来宾帖子，工程师是为 [Egnyte](https://www.egnyte.com/) 在家工作的。 Egnyte 是专门为企业构建的安全内容平台。 他和他的同事们花费大量的时间来扩展大型分布式文件系统。 您可以通过 [@kpatelwork](https://twitter.com/kpatelwork) 与他联系。 +网站：http：//mixi.jp -## 简介 +## 信息来源 -您的笔记本电脑有一个文件系统，该文件系统被数百个进程使用。 但是，如果您希望使用它来支持数以万计的用户在处理同时包含 PB 级数据的数亿个文件时有一些缺点。 它受磁盘空间的限制； 它无法弹性扩展存储空间； 如果您运行一些 I / O 密集型进程或尝试与 100 个其他用户进行协作，就会感到窒息。 让我们来解决这个问题，并将其转换为遍布全球的数百万付费用户使用的云原生文件系统，您将了解我们过山车的规模，可以扩展该系统以满足每月的增长和 SLA 要求，同时提供严格的一致性和 我们都期望笔记本电脑具有出色的耐用性。 +* [mixi.jp](http://www.scribd.com/doc/2684187/mixi-jp-scaling-out-with-open-source) -使用开源 -Egnyte 是一个安全的内容协作和数据治理平台，成立于 2007 年，当时 Google 硬盘还没有诞生，而 AWS S3 却禁止了成本。 我们唯一的选择是袖手旁观，自己构建基本的云文件系统组件，例如对象存储。 随着时间的推移，S3 和 GCS 的成本变得合理，并且借助 Egnyte 的存储插件架构，我们的客户现在可以引入他们选择的任何存储后端。 为了帮助我们的客户管理持续的数据爆炸，我们在过去几年中设计了许多核心组件。 在本文中，我将分享当前的体系结构以及我们所学到的扩展它的一些经验教训，以及我们希望在不久的将来进行改进的一些内容。 + ## 平台 -## Egnyte Connect 平台 + 进行横向扩展* 的 Linux* 阿帕奇* 的 MySQL* 佩尔* 记忆快取* 乌贼* Shard -Egnyte Connect 平台使用 3 个数据中心来满足来自全球数百万用户的请求。 为了增加弹性，可靠性和耐用性，这些数据中心使用高速，安全的 Google 互连网络连接到 Google Cloud 平台。 + ## 里面有什么？ -![](img/b34c983ca54495f680a9dadebfa8f2a4.png) + * 他们在两年内增长到大约 400 万用户，每天增加 15,000 多新用户。* Alexa 排名第 35 位，日本排名第 3 位。* 超过 100 台 MySQL 服务器* 每月添加 10 台以上的服务器* 使用非持久连接。* 日记流量为 85％的读取和 15％的写入。* 消息流量是 75％的读取和 25％的写入。* 遇到复制性能问题，因此他们不得不拆分数据库。* 考虑按用户垂直拆分或按表类型水平拆分。* 最终按表类型和用户进行分区。 因此，一组用户的所有消息都将分配给特定的数据库。 分区键用于确定应在其中存储数据库数据。* 为了进行缓存，他们使用具有 39 台机器 x 2 GB 内存的 memcached。* 存储超过 8 TB 的图像，每天添加约 23 GB。* MySQL 仅用于存储有关图像的元数据，而不用于存储图像本身。* 图像要么经常访问，要么很少访问。* 使用 Squid 将经常访问的图像缓存在多台计算机上。* 很少访问的图像从文件系统提供。 缓存它们没有任何好处。 -Egnyte Connect 运行一个服务网格，该网格从我们自己的数据中心延伸到提供多种服务类别的 Google 云： + ## 得到教训 -### 合作 + * 使用动态分区时，很难选择密钥和算法来存储数据。 -* 文档存储区 + * 对数据进行分区后，就无法再进行联接，并且必须打开与不同数据库的大量连接才能将数据合并回去。 -* 预览版 + * 分区时很难添加新主机并重新排列数据。 例如，假设您的分区算法在主机 1 上存储了用户 1-N 的所有消息。现在，假设主机 1 负担过重，并且您想在更多主机上重新划分用户。 这很难做到。 -* 视频转码 + * 通过使用分布式内存缓存，它们很少访问数据库，平均页面加载时间约为.02 秒。 这减少了与分区相关的问题。 -* 分享 + * 您将常常不得不根据内容类型来制定策略。 例如，图片将与短文字帖子区别对待。 - * 链接 - - * 权限 - -* 标签 - -* 评论 - -* 任务 - -* 建议 - -### 混合同步 - -* 处理 Prem 数据时 - -* 大文件或低带宽 - -* 离线访问 - -* 边缘缓存 - -### 基础架构优化 - -* 迁移到云 - -* 优化保鲜库的成本 - -* 合并存储库 - -通常，Egnyte 连接架构分片并基于以下条件在不同级别缓存数据： - -* 数据量 - -* 数据相互依存 - -* 并发读取的级别 - -* 并发写入级别 - -![](img/f8913d2219c8cabf370072889c0b44fb.png) - -， - -## Egnyte Connect 技术堆栈 - -### 云平台 - -1. Google 云端 - -2. Azure - -3. 托管数据中心 - -### 语言： - -1. Java - -2. Python - -3. 转到 - -4. C - -### 对象存储区 - -* Egnyte 对象存储区 - -* GCS - -* S3 - -* Azure - -### 应用服务器 - -* Tomcat - -### 数据库 - -* MySQL - -* Redis - -* BigTable - -* 数据存储 - -* Elasticsearch - -### 缓存 - -* Memcached - -* Redis - -* Nginx 用于基于磁盘的缓存 - -### 负载平衡器/反向代理 - -* HAProxy - -* Nginx - -### 消息队列 - -* Google Pub / Sub - -* 兔子 - -* 抄写员 - -* Redis - -### 部署管理 - -* 人偶 - -* Docker - -* Ansible - -* 詹金斯 - -* Gitlab - -* 调速器 - -### 分析 - -* 新遗物 - -* OpenTSDB / bosun - -* Grafana - -* MixPanel - -* 表格 - -* BigQuery - -### 其他 - -* ZooKeeper - -* Nagios - -* Apache FTP 服务器 - -* 孔 - -* ReactJS / Backbone / Marionette / JQuery / npm / Nightwatch - -* Rsync - -* PowerDNS - -* 服装 - -* 基于 REST API 的 SOA 体系结构。 - -* Java 用于驱动核心文件系统代码 - -* 用于支持客户端代码，某些微服务，迁移脚本，内部脚本的 Python - -* 原生 Android 和 iOS 应用 - -* 本机桌面和服务器托管的客户端，允许对整个名称空间进行交互以及混合同步访问 - -## 统计信息 - -* 3 个主要地区（其中一个在欧洲）使用 Google 互连连接到相应的 GCP 地区 - -* 500 多个 Tomcat 服务 实例 - -* 由 Tomcat / Nginx 提供支持的 500 多个存储节点 - -* 100 多个 MySQL 节点 - -* 100 多个 Elasticsearch 节点 - -* 50 多个文本提取 实例 （自动缩放） - -* 100 多个 HAProxy 实例 - -* 许多其他类型的服务 实例 - -* 存储在我们服务器和其他对象存储区（例如 GCS，S3 和 Azure Blobstore）中的数十 PB 数据 - -* 在 Elasticsearch 中建立索引的多个 TB 提取内容 - -* 数百万个桌面客户端与云同步文件以进行脱机访问 - -* 数百万台式客户端以交互方式访问文件 - -## 认识您 - -### 您的系统名称是什么，我们在哪里可以找到更多信息？ - -Egnyte Connect 是内容协作和数据管理平台。 CFS（云文件系统），EOS（Egnyte 对象存储），内容安全性，事件同步，搜索服务，基于用户行为的推荐服务构成了系统的主要部分。 您可以在我们博客的 [对于技术人员](https://www.egnyte.com/blog/category/for-the-techies/) 部分中找到更多相关信息。 - -### 您的系统使用什么功能？ - -作为内容协作和数据管理平台的 Egnyte Connect 被成千上万的客户用作唯一的 安全内容平台来满足他们的所有文档管理需求。 它是为承载各种文件服务 并为它们的现有文件存储库启用云而构建的。 可以从各种端点（例如 FTP，WebDAV，移动，公共 API 和浏览器）访问它，并具有强大的审核和安全组件。 - -### 您为什么决定构建此系统？ - -在 2007 年，企业开始变得更加分散。 客户正在使用多种设备来访问他们的文件，因此需要使这种体验尽可能地顺畅。 我们构建了 Egnyte Connect-一种安全的分布式文件系统，该系统将 Hybrid Sync 与 Cloud File System 相结合，可以满足各种业务需求中企业的内容协作需求。 随着本地和云存储库中数据的分散，以及由于 GDPR 等举措而增加的合规性需求，我们构建了 Egnyte Protect 来帮助客户满足其合规性和治理需求。 - -### 您的项目经费如何？ - -Egnyte 最初是一家自举公司。 后来，我们继续从高盛，Google Ventures，KPCB，Polaris Partners 和 Seagate 的多轮融资中筹集了 1.375 亿美元的 [](https://www.crunchbase.com/organization/egnyte#/entity)。 - -### 您的收入模式是什么？ - -Egnyte 不提供免费帐户。 客户从 15 天的免费评估试用期开始，之后，他们将根据席位数量，存储空间和其他企业功能转换为带有收入模型的付费帐户。 - -### 您如何销售产品？ - -我们从 SEM / SEO 开始，但随着时间的增长，我们使用了许多渠道来为社会客户，社交媒体，商务开发，贸易展览，SEM，SEO，入站营销和企业级客户进行高接触销售。 - -### 您从事这项工作多久了？ - -Egnyte 成立于 2007 年。它已有 12 年的历史，现金流量为正。 - -### 您的系统多大？ 尝试感受一下系统的工作量。 - -我们存储数十亿个文件和数十 PB 的数据。 在“ Egnyte connect”中，根据 New Relic，我们平均观察到平均每秒超过 10K API 请求，平均响应时间为< 60ms。 由于安全港规定和位置相近，我们允许从 3 个主要地区访问。 有关更多信息，请参见统计信息部分。 我们的“ Egnyte Protect”解决方案还持续监控内容和对许多客户的合规性，治理和安全漏洞的访问。 - -### 您提供多少份文件？ 多少张图片？ 多少数据？ - -我们存储数十亿个文件和数十 PB 的数据。 我们存储各种文件。 Egnyte 存储的前 5 个文件扩展名是 pdf，doc / docx，xl​​s / xlsx，jpeg 和 png。 - -### 免费用户与付费用户的比例是多少？ - -我们所有的用户均为付费用户。 我们提供 15 天的免费试用期，然后将其转换为付费帐户。 - -### 在过去一个月中有多少个帐户处于活动状态？ - -我们所有的客户都是付费帐户，并且每个月几乎所有人都活跃。 我们满足他们安全的内容平台需求，谁在家不用电？ - -## 您的系统如何设计？ - -### 您的系统的体系结构是什么？ - -我们使用基于 REST 的面向服务的体系结构，它使我们能够独立扩展每个服务。 这也使我们能够将某些后端服务移至公共云中托管。 所有服务都是无状态的，并使用数据库或我们自己的对象存储进行存储。 - -10000 英尺的 Egnyte Connect 服务概述如下所示。 - -![](img/3d5e6054b4bacef5d0f2733fb962651b.png) - -[典型请求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的 10000 英尺总览如下 - -![](img/19d4979dbb2079dbc0eac2371a21067a.png) - -约 10000 英尺的 [搜索架构](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下 - -![](img/c015db1edce1869cc6373704f2683bb5.png) - -### 您的系统面临哪些特定的设计/架构/实施挑战？ - -最大的 架构 挑战包括： - -1. 节俭地扩展文件存储 - -2. 扩展元数据访问 - -3. 文件与桌面客户端的实时同步 - -4. 带宽优化 - -5. 冲击隔离 - -6. 缓存（分布式和内存中） - -7. 功能首次展示 - -### 您是如何应对这些挑战的？ - -1. 对于存储，我们编写了自己的存储，现在我们使用可插拔的存储体系结构来存储到任何公共云，例如 S3，GCS，Azure ... - -2. 为了扩展元数据，我们移至 Mysql 并开始使用分片。 在某个时候，我们暂时投入了更多的硬件来腾出空间，以便一层一层地剥去“鳞屑洋葱”。 - -3. 对于实时同步，我们必须更改同步算法，使其更像 Git，客户端接收增量事件并尝试与云状态进行最终的一致同步。 - -4. 为了推出功能，我们构建了一个自定义设置服务，允许工程师在功能标志后面编写代码。 这样，即使在睡眠者模式下，您也可以释放代码并收集数据，然后按客户，用户或主机组或 POD 或数据中心启用功能。 有了这种控制水平，即使是新工程师也可以放心地在功能标记后面编写代码并将其发布到生产环境中，而不必担心停机时间。 - -5. 监视，监视和监视。 您无法优化无法衡量的内容。 不利的一面是，在某些时候，我们监控得太多了，以致于我们无法专注于所有指标。 我们必须转移注意力，并依靠诸如 New Relic，bosun，ELK，OpenTSDB 和自定义报告之类的异常检测工具，使我们能够专注于从绿色->黄色->红色趋势发展的问题。 目的是在客户通知 之前，将它们捕获为黄色并且 [时捕获它们。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) - -### 您的系统如何发展以应对新的扩展挑战？ - -我们已经多次重新构造了许多层。 我将尝试列出过去 7 年中核心元数据，存储，搜索层的一些迭代。 - -1. 版本 1：在 Lucene 中搜索 Lucene 中的文件元数据，通过 NFS 安装在 DRBD Filer 中存储的文件。 关键点： Lucene 更新不是实时的，必须替换。 - -2. 版本 2：Berkeley DB 中的文件元数据，通过 NFS 挂载的 DRBD Filers 中存储的文件，在 Lucene 中搜索。 关键点： 我们打破了 NFS 的限制，它左右 and 住，必须用 HTTP 代替。 - -3. 版本 3：Berkeley DB 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 Lucene 中搜索。 关键点 ：即使分片的 Berkeley DB 在压力下也令人窒息，并且由于恢复需要数小时而导致数据库崩溃，因此必须更换它。 - -4. 版本 4：MySQL 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 Lucene 中搜索。 关键点： 公共云开始变得便宜。 - -5. 版本 5：MySQL 中的文件元数据，存储在 EOS / GCS / S3 / Azure 中并通过 HTTP 提供的文件，在 Lucene 中搜索。 阻塞点： 搜索开始阻塞，必须替换。 - -6. 版本 6：MySQL 中的文件元数据，通过 HTTP 服务的 EOS / GCS / S3 / Azure 中存储的文件，在 Elasticsearch 中搜索。 这是当前的体系结构。 - -7. 版本 7（未来）：将所有计算移至公共云，提供更多服务以实现影响隔离，动态资源池以有效管理宠物和牛。 - -### 您是否使用任何特别酷的技术或算法？ - -* 我们在核心服务和服务之间进行呼叫时使用指数补偿，以使用断路器来避免打雷。 - -* 我们使用核心服务节点资源上的公平份额分配来处理传入请求。 核心服务节点上的每个传入请求都被标记并分为各种组。 每个组都有专用的容量，如果一个客户每秒发出 1000 个请求，而另一个客户每秒发出 10 个请求，则此系统将确保其他客户不会因为邻居吵闹而挨饿。 诀窍是，如果您是目前使用该系统的唯一客户，则可以全力以赴，但是随着更多客户同时出现，您可以在其中共享容量。 对于某些大型客户，我们会分配专用池以确保一致的响应时间。 - -* 带有 SLA 的某些核心服务被隔离在 POD 中，这确保了一个不好的客户不会阻塞整个数据中心，但是这可能很快就需要轮回。 - -* 我们在桌面同步客户端代码中使用基于事件的同步，因为发生服务器事件时，它们会从服务器推送到客户端，并且客户端会在本地重播它们。 - -* 我们采用大规模数据过滤算法，以使大型客户端集群与 Cloud File System 同步。 - -* 我们根据问题陈述使用不同类型的缓存技术。 很少有以下口味： - - * 传统 - - * 内存中的-简单的 - - * 不可变的对象 - - * 内存中的大型数据集 - - * 用于在各个进程之间实现高度一致性的锁 - - * 已实施部分更新，以避免出现 GC - - * 内存中-高容量变异数据集 - - * 粗粒度无效 - - * 细粒度无效 - - * 基于磁盘的缓存 - -### 您做什么工作是与众不同的，人们可以从中学到什么？ - -专注于启动的核心功能，如果您遇到技术难题，就必须为其构建自定义内容，然后卷起袖子继续前进。 有很多独特的东西，但是基于事件的同步存储层绝对值得学习，这里有更多详细信息。 [Egnyte 对象存储库](https://www.egnyte.com/blog/2013/07/how-egnyte-implements-hybrid-object-stores-using-public-clouds-to-enhance-customer-experience/) 和 Egnyte [规范文件系统](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 - -### 您学到了什么？ - -* 您无法优化您无法测量的内容：测量所有可能且相关的内容，然后首先优化 80％处于使用状态的系统部分。 - -* 当您身材矮小的时候，请慢慢介绍技术，不要试图从中找到解决当前问题的理想工具。 编码是生命周期中最简单的部分，但是如果您拥有太多的技术，则其维护（如部署/操作/学习曲线）将非常困难。 随着您变得更大，您的部署中将有足够的脂肪来逐步进行服务划分。 学习保留一个或两个服务模板来实现微服务，不要为每个服务使用不同的技术堆栈。 - -* 作为初创企业，有时您必须快速行动。 介绍您现在可以做的最好的解决方案，如果发现有牵引力，请随着时间的推移重新设计该解决方案。 您可以尝试 10 种不同的方法，而只有 1 种方法可以看到牵引力，因此请快速进行一些操作，然后在看到牵引力的方法上重新架构，以适应业务规模。 - -* 寻找单点故障，并不懈地追查它们。 付出额外的努力来解决使您彻夜难眠的问题，并尽快从防御性转变为进攻性模式。 - -* 在 SOA 中，构建断路器以尽早减轻负载，如果服务受阻，则开始发送 503s。 与其惩罚所有人，不如看看您是否可以公平分配资源并仅惩罚滥用请求。 - -* 在服务使用者中添加了自动修复功能，服务可能会停止运行，并且像台式机客户端或其他服务这样的使用者可以进行指数补偿以释放服务器上的压力，并在服务再次起作用时自动修复。 - -* 始终可用：请客户提供服务级别的断路器和断路器。 例如，如果通过 WebDAV 或 FTP 访问文件系统存在性能问题，并且需要 4 个小时来修复，那么在这 4 个小时内，您可以在 kong / firewall 杀死 FTP / WebDAV 并要求客户使用 Web UI 或其他 工作机制。 同样，如果一个客户造成了导致系统阻塞的异常，则可以暂时为该客户禁用该客户或服务，并在解决问题后重新启用它。 为此，我们使用功能标志和断路器。 - -* 对于高度可扩展的服务，离开 Java 进程的成本很高，即使去了 Memcache 或 Redis 也是如此，因此我们对某些高度使用的数据结构（如访问控制计算，功能标志，路由元数据等）进行了具有不同 TTL 的内存中缓存。 。 - -* 我们看到一种有关处理大数据集的模式。 优化代码并挤走柠檬中的每一滴都是徒劳的，我们最终可能会使代码变得复杂且柠檬水苦涩。 通常，最简单的解决方案来自返回到绘图板，看看我们是否可以： - - * 通过使用启发式方法来减少我们需要处理的数据集大小 - - * 重组了我们在内存或磁盘中存储数据的方式。 - - * 在写时对数据进行规范化，并避免联接。 - - * 基于时间的过滤，例如存档较早的数据。 - - * 在多租户数据结构中创建较小的碎片。 - - * 使用事件更新缓存数据集，而不是完全重新加载。 - -* 保持简单：每个月都有新工程师加入，因此目标是从第一周开始就提高他们的工作效率-简单的架构可确保轻松上岗。 - -### 您为什么成功？ - -牵引力胜过一切。 当 EFSS 市场刚刚爆发时，我们达到了产品/市场契合度。 良好的执行力，以客户为中心，管理团队遵守财务纪律的时机可以成功。 许多竞争者采用了免费增值模式并筹集了一大笔资金，但是从第一天开始我们就开始收费，这使我们能够专注于随着市场需求的扩大而发展解决方案/团队。 专注于付费客户使我们能够提供企业级解决方案，而无需支付免费增值罚金。 - -### 您希望自己做些什么？ - -我希望当我们开始时，公共云不会像成本那样高。 我也希望我们从第一天开始就使用 SOA，花了一些时间才到达那里，但是现在我们就在那里。 - -### 您不会更改什么？ - -体系结构应具有延展性。 四年前，对于给定的问题，我有不同的答案，但是目前，我不确定。 我的意思是，随着您规模的扩大，过去 2 年前有效的设计模式和策略可能使您从防御性定位转向进攻性定位可能会在压力下屈服或变得成本过高。 只要更改将使系统变得有弹性或带来 10 倍的更改并为我们再购买 3-4 年的规模，我便会继续尝试更改它。 我不能在两年后发表评论，我会有同样的想法，他们可能会改变。 当您遇到下一个增长突增时，架构会发生变化。 - -### 您应该做多少前期设计？ - -很好的问题。 答案是“取决于”， - -* 如果您要设计核心存储层或核心元数据层之类的东西，那么再多花 2 周的时间就不会有多大伤害。 当我们在核心元数据层上从 Berkeley DB 迁移到 MySQL 时，我承受着很大的压力，我想到了一条捷径，当我通过我们的 CTO 运行它时，他建议花一些时间，“做正确的事情”。 ”作为回顾，这是一个极好的决定。 - -* 对于公共 API，最好做一个不错的前端设计，因为您没有第二次机会对其进行更改，并且必须在未来 4-5 年内进行维护。 - -* 如果要处理其 PB 级数据并带来巨大麻烦，那么我将再给它一个月的时间并进行更多的 POC。 - -* 但是，如果您要为内部服务设计一些东西并将其迁移到新的体系结构不会花费一年的时间，那么我建议您进行非常少的前端设计，并且只需快速构建版本并随着使用量的增长对其进行迭代 。 - -### 您如何考虑将来更改架构？ - -* 从静态 POD 转移到动态 POD，并无缝处理宠物和牛。 - -* 提供更具弹性的服务并隔离影响。 - -* 将我们的整个计算移至公共云，同时保留数据中心用于提供文件。 这将使我们能够在负载到来时自动放大/缩小。 我们已经使用公共云来自动扩展一些异步处理，例如视频转码，文本提取，数据迁移，搜索等。 - -* 一旦进入云，请使用更多自动缩放服务，例如 BigTable，PubSub，Spanner 等。 - -* 将我们的部署从 VM 迁移到 Kubernetes 中的容器，以提供挂起的服务。 - -* 自动化剩余数据库的架构管理 - -* 通过重新构建从某些增长最快的表中删除联接。 - -* 重写元数据的缓存层，并使用 Redis 数据结构代替 Memcache。 - -* 将频繁使用的流从强一致性转换为最终一致性。 - -## 您的团队如何设置？ - -### 您的团队中有多少人？ - -大约 700 名员工和承包商。 有 200 名工程师（DevOps / OPS / QA / Developers /…），其余为销售，市场营销，支持，产品管理，人力资源等。 - -### 他们在哪里？ - -最初是一支分布相当分散的工程团队，但现在主要吸引了印度波兰山景城的人。 一些像我这样的远程员工 和其他一些员工在家工作。 - -### 谁扮演什么角色？ - -这是一个很大的团队，我们有产品经理，UX 团队，DevOps，Scrum 团队，架构师，工程师扮演各种角色。 最初，工程团队很平坦，每个人都会向工程副总裁报告，但现在我们在两者之间增加了一层管理。 - -### 您是否有特定的管理理念？ - -如果您开发某些产品，那么您便拥有该产品的生命周期，这意味着您将与质量保证，DevOps 一起使用，以确保产品经过测试/部署。 投入生产时，您可以使用各种内部工具（例如 New Relic / Grafana，Kibana）对其进行监视，如果存在回归，则可以对其进行修复。 我也是 1 人 1 任务理念的忠实拥护者，通过这种方式，如果工程师遇到障碍，他将找到某种最终克服它的方法，而不必太早放弃。 - -### 如果您有分散的团队，该如何工作？ - -自治，1-1 交流给他们带来挑战性的问题，亲自照顾和直接挑战，他们会受到激励。 - -### 您的开发环境是什么？ - -* 适用于服务器团队的 Ubuntu - -* UI 团队使用 Windows / mac 并连接到用于 REST API 服务器的本地 Ubuntu VM 或连接到共享的 QA 实例 - -* Eclipse /想法 - -* 适用于构建的 - -* Maven - -* 码头工人 - -* Gitlab - -* Jenkins - -* 汇合 - -* JIRA - -* Google 办公套件 - -* 松弛 - -### 您的开发过程是什么？ - -我们使用 Scrum，并为云文件系统团队提供每周发布。 我们使用 git-flow 的变体，对于每个票证，我们克隆存储库，并对每个合并请求运行自动化测试。 合并请求必须经过 2 位工程师的批准，然后才能解决 JIRA 故障单。 解决后，我们的管道将接管工作，而票务将接下去的下一班火车。 下一版本的培训已通过自动化 REST API 测试和一些手动烟雾测试进行了验证。 - -我们吃了自己的狗粮，并且代码在发布前 2-3 天送达了 UAT（供所有员工使用），我们发现了自动化测试未发现的任何意外情况。 我们每个星期三进行生产部署， [每天监控新文物，并报告任何异常的异常报告](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 。 我们在一周中更改了部署，以实现工作与生活之间的平衡，并且通过这种方式，我们将让所有工程师可用，以防发布遇到问题。 - -如果这是一项长期运行的功能，则工程师通常会在功能标志后面进行工作，并在各个阶段以 sleeper 模式提交代码，因此，每周（而不是大爆炸）都要测试他的代码。 我们也以一次迁移 1 个客户并仅为该客户打开功能的方式处理大型迁移，我们的一些大型迁移已运行 3-4 个月。 - -### 您有什么可以做的不同还是感到惊讶？ - -许多工程师在家工作，令人惊讶的是，有了自主权，许多远程员工像总部员工一样富有生产力和积极性。 - -## 您使用什么基础架构？ - -### 您使用哪种语言来开发系统？ - -大多数使用 Java / Python 以及 Go / C 中的一些小服务 - -### 您有多少台服务器？ - -我们有约 3000 多个由人偶管理的实例。 - -* 500+ Tomcat service instances - -* 500+ Storage nodes powered by Tomcat/Nginx - -* 100+ MySQL nodes - -* 100+ Elasticsearch nodes - -* 50+ Text extraction instances(autoscaled) - -* 100+ HAProxy instances - -* 和许多其他类型的服务 实例 - -### 如何将功能分配给服务器？ - -我们使用面向服务的体系结构，并根据服务类型分配服务器。 一些顶级服务是： - -* 元数据 - -* 储存空间 - -* 对象服务 - -* Web UI - -* 索引 - -* 同步 - -* 搜索 - -* 审核 - -* 内容智能 - -* 实时事件传递 - -* 文本提取 - -* 集成 - -* 缩略图生成 - -* 防病毒软件 - -* 垃圾邮件 - -* 预览/缩略图 - -* Rsync - -* API 网关 - -* 结算 - -* FTP / SFTP - -* 等等。 - -![](img/3d5e6054b4bacef5d0f2733fb962651b.png) - -### 如何配置服务器？ - -大多数服务都是伪造的，并在 VM 上运行，我们仅针对 MySQL，Memcached 和存储节点等少数设备运行物理服务。 我们使用第三方根据模板来配置服务器，并将其放置在数据中心中，以供使用。 但是我们已经开始将一切迁移到公共云的工作，因此最终，一切都将在 Kubernetes 中运行。 然而，挑战在于如何在不停机的情况下如何在比赛中更换赛车发动机。 - -### 您使用什么操作系统？ - -CentOS7 - -### 您使用哪个 Web 服务器？ - -Nginx，HAproxy。 在一些旧的流程中使用了 Apache，但随着时间的流逝，它将被弃用。 - -### 您使用哪个数据库？ - -MySQL 和 Redis。 我们过去曾使用过其他数据库，例如 Berkeley DB，Lucene，Cassandra，但由于其对工程师/操作人员的熟悉程度和可扩展性，我们逐渐将所有数据库迁移到 MySQL。 有关更多信息，请参见 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 - -对于某些流，我们还使用 OpenTSDB，BigTable，Elasticsearch。 - -### 您是否使用反向代理？ - -是 Nginx 和 HAProxy - -### 您是否并置，使用网格服务，使用托管服务等？ - -我们并置，我们还使用公共云。 - -### 您的存储策略是什么？ - -我们首先创建自己的服务器，然后在机器中打包尽可能多的硬盘驱动器，我们过去将它们称为 DRBD Filers。 我们这样做是因为 AWS 成本过高。 我们已经对 [GlusterFS](https://www.gluster.org/) 进行了评估，但是当时它无法扩展以满足我们的需求，因此我们构建了自己的。 加班 S3 变得便宜了，GCS / Azure 诞生了，我们将存储层设计为可插入的，因此现在客户可以决定要使用哪个存储引擎（例如，Egnyte，S3，GCS，Azure 等）。 此时，我们在公共云中存储了 1 个 DR 副本，并与我们一起存储了 1 个副本，但是最终我们将使用我们的数据中心作为直通缓存，因为云中的计算便宜，但是带宽昂贵。 - -### 您如何增加产能？ - -我们已基于 Newrelic，Grafana 和其他统计数据提供了半自动化的容量规划工具，并根据观察监控报告中的关键指标并预定一些额外的容量，进行了定期的容量规划会议。 现在，某些服务已启用云服务，我们只是根据队列大小自动缩放它们。 - -### 您是否使用存储服务？ - -是 Egnyte，S3，GCS，Azure， - -### 您如何处理会话管理？ - -我们多次重写了体系结构，目前，99％的服务是无状态的。 仅服务 Web UI 服务使用会话，我们在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性会话，但最终，我的计划是使它也 使用 JWT 或类似方法实现无状态。 - -### 您的数据库是如何设计的？ 主从？ 碎片？ 其他？ - -我们对几乎所有具有自动故障转移功能的数据库都使用了 Master-Master 复制，但是某些严重变异的数据库的切换是手动完成的，我们遇到了一些问题，由于复制滞后，自动切换会导致应用程序数据不一致，我们 需要重新架构一些核心文件系统逻辑来解决此问题，我们最终将完成此工作。 下面是有关处理数据库升级的问题，详细回答了有关数据库体系结构的更多详细信息。 - -### 您如何处理负载平衡？ - -我们根据客户使用 DNS 访问系统的 IP 来对客户进行地理平衡，并在数据中心内使用 HAProxy 将其路由到其相应的 POD，在 POD 内部，又使用 HAProxy 对其进行路由 - -### 您使用哪个 Web 框架/ AJAX 库？ - -我们已经多次更改了 UI，这是一直在变化的一件事。 过去，我们不得不使用 ExtJS，YUI，JQuery，而不能使用其他东西。 最新的迭代基于 ReactJS / Redux 以及 Backbone / Marionette 上的一些旧代码。 - -### 您使用哪些实时消息传递框架？ - -我们使用 [大气](https://github.com/Atmosphere/atmosphere) ，但最终，我们将其替换为 NodeJS - -### 您使用哪个分布式作业管理系统？ - -为此，我们使用 Google Pubsub，RabbitMQ 和基于 Java / Python 的消费者服务。 - -### 您的网站是否有标准 API？ 如果是这样，您将如何实施？ - -我们的 API 分为 3 种类型：- - -1. 公共 API： 这是我们向第三方应用程序工程师和集成团队以及我们的移动应用程序公开的 API。 我们会按照适当的弃用工作流程来弃用/升级 API 签名，并且更改始终向后兼容。 我们使用 Mashery 作为网关，API 记录在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) - -2. 适用于我们客户的 API： 此 API 对我们客户而言是内部的，如果我们以外的人使用此 API，我们不保证向后兼容。 - -3. 服务之间的内部受保护的 API： 这是服务在我们的数据中心内部用于相互通信的 API，无法从外部防火墙调用。 - -### 您的对象和内容缓存策略是什么？ - -我们存储了 PB 级的数据，但无法缓存所有数据，但是如果客户在给定的 15 天时间内拥有 5000 万个文件，则他可能只使用其中的 100 万个。 我们有基于 tomcat / Nginx /本地文件系统的缓存文件管理器节点，它以 LRU 方式运行。 我们可以弹性地增加减少缓存文件服务器的数量。 我们最大的问题之一是上传速度，如何从世界任何地方尽可能快地将数据上传到 Egnyte，为此，我们构建了特殊的 Network pops，如果您好奇的话可以在上阅读有关更多内容的信息[ [为 Egnyte 客户加速数据访问](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) - -Memcached / Redis 用于缓存元数据，我们使用单独的 Memcached 池来缓存长期存在的静态数据和文件系统元数据。 核心文件系统元数据非常庞大，不适合当前的 Memcached 节点，并且会逐出最近使用的其他类型的数据。 为了防止这种情况，我们使用 3 种类型的池，应用程序代码决定在哪里查找哪种数据。 我们允许在文件系统 Memcached 缓存中逐出，并在其他种类的 Memcached 池中争取零逐出。 对于不同种类的数据，我们也使用不同的对象到期时间。 对于我们一些频繁使用的数据（例如客户信息或分片映射），即使每个请求都转到 Memcache，也会因某些请求（例如文件夹列表）而减慢速度，因此我们在每个 JVM 上对该数据进行内存内缓存，并刷新数据 基于自定义 TTL 或我们使用某种 pub-sub 机制刷新它。 - -缓存中的两个最大难题是权限和事件。 对于权限数据，我们已经多次重选了该层，最近我们编写了一个 TRIE 来有效地缓存该层。 - -对于事件，我们将其缓存在 Memcache 中，但是有可能在晚上为客户发布了约 10 万个事件，而在早上 9:00 AM 突然有 3 万个人打开了笔记本电脑，现在每个人都希望这些 10 万个事件 使他们的系统一致。 这是一个有趣的规模问题，因为这将需要您在短时间内（例如 15 分钟）处理 30B 事件，并且仅发送用户有权访问的事件。 由于事件是不可变的，我们将它们在 Memcache 中缓存了 12 个小时，但是即使它们从 Memcache 下载相同的事件那么多次也会导致网络问题。 最终，我们在短时间内将事件缓存在内存中，并且随着我们进行许多年轻一代的收集工作，还调整了这些节点上的 GC 设置。 与其他节点相比，我们还将这些节点放置在更快的网络上，但仍然没有解决这个问题:)。 - -### 您的客户端缓存策略是什么？ - -对于我们的 Web UI，我们使用 requireJS 和其他各种方式仅下载所需的模块。 我们的 Mobile 和 Desktop 客户端丰富使用本地文件系统作为缓存。 - -### 您使用哪些第三方服务来帮助您构建系统？ - -我们使用了一些 Google 服务，Azure，New Relic，Authy，MixPanel，Flurry，Tableau，但大多数核心组件都是由我们构建的。 - -## 您如何管理系统？ - -### 您如何检查全局可用性并模拟最终用户性能？ - -我们使用不同 AWS 区域中的节点来一致地测试带宽性能。 我们还使用内部 haproxy 报告来绘制客户观察到的上载/下载速度，并主动寻找它们，并使用网络弹出消息和其他策略来加速数据包。 - -![](img/6ffa16c86d1956a9ff0be037d6021022.png) - -### 您如何健康检查服务器和网络？ - -Nagios，Grafana 和 New Relic 以及一些内部主动异常分析被使用。 有关更多详细信息，请参见此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) - -### 如何绘制网络和服务器统计数据以及趋势图？ - -我们使用 Grafana，Kibana，Nagios 和 New Relic。 - -![](img/dedeb468380c2680e693cd8a5743a335.png) - -![](img/293ca1407b4f34397f578ec21c96afd2.png) - -### 您如何测试系统？ - -硒，Junit，鼻子，Nightwatch 和手动测试。 单元，功能，集成和性能测试的组合。 - -### 您如何分析效果？ - -New Relic 用于监视应用程序性能。 我们还使用本地框架生成了大量内部应用程序指标。 我们使用 Grafana / Nagios / Kibana，内部工具和其他工具来监视系统其他部分的性能。 有关更多详细信息，请参见此博客文章 [分布式系统中的调试性能问题](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) - -### 您如何处理安全性？ - -专门的安全团队在每个版本之前都会运行自动化的安全基准测试。 连续自动笔测试正在生产中运行。 我们还使用漏洞赏金计划，并与 whitehat 测试公司合作。 一些客户使用第三方进行自己的安全性测试。 - -## 您如何处理客户支持？ - -我们有专门的 24X7 分布式客户成功团队，我们使用 Zendesk 和 JIRA - -## 您如何确定要添加/保留的功能？ - -### 您是否实施网络分析？ - -我们使用 Google Analytics（分析），Mixpanel，Flurry 来衡量功能使用情况 - -### 您是否进行 A / B 测试？ - -是的，我们使用功能标记进行 A / B 测试。 有关更多信息，请参见 [在 Egnyte 使用功能标志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) - -### 您要运行多少个数据中心？ - -3 个主要数据中心，包括欧洲的一个（由于安全港规则） 和遍布全球的 pop-pop。 - -### 您的系统如何部署在数据中心中？ - -Puppet / Ansible 用于部署大多数新代码。 - -### 您使用哪种防火墙产品？ - -帕洛阿尔托网络 - -### 您使用哪个 DNS 服务？ - -NS1 - -### 您使用哪些路由器？ - -思科 - -### 您使用哪些开关？ - -Arista - -### 您使用哪个电子邮件系统？ - -我们结合使用 SendGrid 和我们自己的 SMTP 服务器。 - -### 如何备份和还原系统？ - -对于 MySQL，我们使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，对于 Elasticsearch，该数据被复制 3 次。 对于客户文件，我们将其复制 3 次，并将 1 个副本存储在 DR 公共云中。 如果存储 Filer 无法恢复，我们将丢弃它，添加一个新 Filer 并再次复制副本。 对于某些客户，我们还会将其数据复制到他们选择的提供商。 对于使用 S3，Azure 或 GCS 作为可插入存储层的客户，它将确保复制以防止数据丢失。 - -### 如何进行软件和硬件升级？ - -大多数节点是无状态的，并且有状态组件具有主动-主动故障转移。 通过将节点从池中取出并进行升级并将其放回池中来处理升级。 我们使用 jenkins + Ansible + puppet 和自定义自动化。 - -### 您如何处理升级中数据库架构的重大更改？ - -不同的服务使用不同类型的数据库，并且它们以不同的方式升级。 在 10000 英尺处，它们如下图所示： - -![](img/4424662bfcfaca90969ec39e8fa0dbb4.png) - -1. EOS DB 存储对象元数据并且增长非常快，它经过分片，并且我们将继续添加更多此类数据。 - -2. MDB 的增长速度更快，经过了分片，并且我们会继续增加更多。 - -3. DC_central 是一个 DNS 数据库，并且保持相当静态。 我们运行了许多此副本以实现可伸缩性。 - -4. Pod_central 具有快速突变的数据，但每个表的增长量不超过 2000 万行。 我们运行了许多此副本以实现可伸缩性。 - -* 每个数据库模式始终是向前和向后兼容的，即我们绝不会在同一发行版中删除列和代码，我们首先在停止使用该列的发行版 1 中部署代码，而在发行版 2 中我们删除该列。 - -* 非分片数据库每周更新一次。 它们是存储各种功能驱动表的表。 我们目前在生产环境中使用脚本对其进行升级，但是我们在质量检查中使用 Liquibase，并且正在逐步将其应用于生产环境 - -* 使用自动脚本进行分片的数据库新列更改 - -* 分片数据库迁移是一件痛苦的事情，因为我们有 12000 多个分片并且还在不断增长，您无法在 1 小时的升级窗口中完成。 方法是： - - * 实时代码根据需要迁移行。 这意味着迁移可能需要几个月的时间。 - - * 使用功能标记迁移，您同时拥有旧代码/新代码，并且在后台迁移客户，然后翻转标记以将其切换到新代码路径而无需停机，更多的是 [此处](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此处](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) - - * 当我们从 Lucene 迁移到 ElasticSearch 时，除了重新索引所有内容外，我们别无选择，我们使用了 [功能标记](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) ， -4 个月完成。 - -* 模式一致性检查器报告可确保升级后所有数据中心中的所有模式均相同。 - -### 您是否有单独的运营团队来管理您的网站？ - -是的，我们有一个专门的生产工程，SRE 和一个 IT / Ops 团队，负责监视和管理生产。 但是正如我之前所说，构建此功能的工程师负责制定决策，因此他们将深入参与监视指标并解决生产问题。 - -## 其他 - -### 您欣赏谁？ - -AWS ：他们的创新步伐令人赞叹。 - -Google ：BigQuery，Kubernetes 之类的工具很棒。 - -Elasticsearch： 其余的 API 简单性和架构很棒。 我们用一个 TB 的数据和一个工程师来管理一个 100 多个节点的集群。 - -MySQL / Memcache： 它们简单，快速且很棒。 - -Eclipse / Jenkins ：插件架构很好。 - -### 您是否模仿了其他人的公司/方法？ - -我们是 [http://highscalability.com/](http://highscalability.com/) 的常规读者，许多设计都受到它的启发。 - -* POD 架构的灵感来自 Tumblr 的 Cell 架构。 这不是精确匹配，但是隔离故障的概念是相同的。 - -* 受 Facebook 启发的架构在 12 个小时后会在 Memcached 和刷新键中产生抖动。 - -* 受 [http://highscalability.com/上一些文章的启发，将](http://highscalability.com/) [指纹添加到每个数据库查询](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) - -我们正在招聘，请在 [职位页面](https://www.egnyte.com/jobs/) 中查看我们，并在 [与我们联系 [受电子邮件保护]](/cdn-cgi/l/email-protection) 。如果您有兴趣成为 [Egnyte](https://www.egnyte.com) 令人惊叹的团队的一员。 \ No newline at end of file + * 社交网站非常注重时间，因此按时间以及用户和类型对数据进行分区可能很有用。 \ No newline at end of file diff --git a/docs/20.md b/docs/20.md index 55110e1..ab6d206 100644 --- a/docs/20.md +++ b/docs/20.md @@ -1,189 +1,81 @@ -# 每天可处理数百万个请求的图像优化技术 +# Ruby on Rails 如何在 550k 网页浏览中幸存 -> 原文： [http://highscalability.com/blog/2016/6/15/the-image-optimization-technology-that-serves-millions-of-re.html](http://highscalability.com/blog/2016/6/15/the-image-optimization-technology-that-serves-millions-of-re.html) +> 原文： [http://highscalability.com/blog/2008/1/7/how-ruby-on-rails-survived-a-550k-pageview-digging.html](http://highscalability.com/blog/2008/1/7/how-ruby-on-rails-survived-a-550k-pageview-digging.html) -![](img/53937b855f4361fee420d17dae2e415d.png) +Shanti Braford [详细介绍了他基于 Ruby on Rails](http://highscalability.com/links/goto/260/197/links_weblink) 的网站如何在 24 小时 550,000+浏览量 Digg 攻击中幸免于难。 他的帖子清晰地列出了所有多汁的设置细节，所以我没什么可补充的。 -本文将介绍 [Kraken.io](https://kraken.io/) 如何构建和扩展每天可处理数百万个请求的图像优化平台，以保持 始终保持高性能，同时保持尽可能低的成本。 在撰写本文时，我们将介绍当前的基础结构，并介绍一些我们学到的有趣的知识，以便将其运用于此处。 +托管费用为每月 370 美元，包括一台 Web 服务器，一台数据库服务器和足够的带宽。 该站点建立在 RoR，nginx，MySQL 和 7 个杂种服务器上。 他认为 Rails 2.0 改善了性能，并避免了信用数据库和片段缓存，从而在很大程度上提高了性能。 -### 让我们制作一个图像优化器 +请记住，他的系统是相对静态的，但这是一个非常有趣且有用的体验报告。 -您想开始在 CDN 帐单上省钱，并且通常通过将较少的字节通过网络推送到用户的浏览器来加快网站速度。 很有可能超过 [的流量有 60％](http://httparchive.org/interesting.php) 仅是图像。 +更令我惊讶的是，他的系统以前所未有的水平处理了峰值，而没有任何方面的干扰，而不是 RoR 处理 505k 网页浏览量。 响应流量高峰的扩展始终是 bit 子。 在 E3 期间运行游戏网站总是很有趣。 -使用 ImageMagick（您确实读过 [ImageTragick](https://imagetragick.com/) ，对吗？），您可以使用以下简单命令降低 JPEG 文件的质量： +不过要警惕他最后给出的流量比较。 Twitter 每月只做 50 万个独特身份，这听起来很低。 如果您听说过某个网站，那么他们每个月至少要做一百万个，鉴于其受欢迎程度和 alexa 排名，我将 Twitter 推到了接近 5 个磨坊。 不要被欺骗，认为每月 327 美元将托管一个不错的网站。 -$ convert -quality 70 original.jpg Optimized.jpg +本文通过将唯一的页面视图与页面视图相结合而犯了一个大错误。 Twitter 可能轻松拥有 500,000 个唯一身份和 25,000,000 个页面浏览量。 -$ ls -la +24 小时内浏览量达到 550k？ --rw-r--r-- 1 matylla 职员 5897 5 月 16 日 14:24 original.jpg +每小时 22917。 +每分钟 382。 +每秒 6.36。 --rw-r--r-- 1 matylla 职员 2995 May 16 14:25 Optimized.jpg +对不起，没留下深刻的印象。 +除非您从 5 年前开始就坚持使用硬件，否则您的应用程序 +需要非常昂贵的 I / O 或 CPU 工作，那么这简直就是天才。 -恭喜。 通过屠宰 JPEG 的质量，您刚刚将其压缩了约 50％。 图像现在看起来像 Minecraft。 它看起来不是这样-它可以销售您的产品和服务。 理想情况下，Web 上的图像应具有出色的质量，并且不会以过高的质量或 EXIF 元数据的形式出现不必要的膨胀。 +如果 RoR 中的“普通 Web 应用程序”在如此轻的负载下开始发汗，那么，老兄，请更换工具。 -现在，您打开自己喜欢的图像编辑软件并开始以 Q 级播放，同时将 JPEG 保存为 Web。 事实证明，您测试的这张特定图片在 Q76 看上去很棒。 您开始以质量设置为 76 保存所有 JPEG。但是请稍等片刻...有些图像即使在 Q80 情况下也看起来很糟糕，而有些图像甚至在 Q60 时也很好。 +我们的某些 PHP 和 Java 垃圾（实习黑客，postgres 和应用在同一台计算机上，远未优化） +一年前在标准硬件上可轻松处理 30 次以上的命中/秒（2 cpus，2G，6 锭子）。 -好的。 您决定以某种方式使其自动化-谁想手动测试您拥有维护“特权”的数百万张图像的质量。 因此，您创建了一个脚本，该脚本可以生成不同 Q 级别的输入图像的数十个副本。 现在，您需要一个度量标准，该度量标准将告诉您哪个 Q 级适合特定图像。 MSE？ SSIM？ MS-SSIM？ PSNR？ 您如此绝望，甚至开始计算和比较输入图像不同版本的 [感知哈希](https://en.wikipedia.org/wiki/Perceptual_hashing) 。 +每台计算机的击中速度低于 40 次/秒的任何事情，要么做的事情异常昂贵 +，要么一定要做，而不应该放在简历上。 -有些指标的效果要好于其他指标。 对于某些类型的图像，有些效果很好。 有些非常快，而另一些则需要很长时间才能完成。 您可以通过减少处理每个图像的循环次数来逃脱现实，但是很可能您错过了理想的 Q 级别，并且图像要么重于原来的水平，要么质量下降过高。 +就像之前的评论者所说的那样……每天 550K 简直是无济于事。 不久之前，我不得不部署一些 Java 应用程序来完成大量的图像+电影处理（提取一些关键帧并生成一些缩略图= Java + JNI）。 每分钟的平均每日交易量约为 1000，有些高峰为每分钟 2000。 因此，每天点击量为 1.5 到 300 万，并且在 4 台服务器上运行。 +每天 550 K 基本上是当今不断发展的世界中的花生...将其带到 1000 万甚至更多，然后变得很有趣 -那么在白色背景下的商品图片呢？ 您真的想减少对象周围的振铃/晕影。 基于每个图像的自定义色度二次采样设置如何？ 如今，白色背景下的那件红色连衣裙看上去已经被洗掉了。 您已经了解到，剥离 EXIF 元数据将使文件变小一点，但是您还移除了 Orientation 标签，现在图像旋转不正确。 +只是以为我会花点时间回应。 -那只是 JPEG 格式。 对于您的 PNG，您可能想重新压缩 7-Zip 或 Deflate 压缩后的图像，例如 Google 的 [Zopfli](https://github.com/google/zopfli) 。 您启动脚本并观看 CPU 上的风扇开始熔化。 +首先，它不是 550k 在 24 小时内平均分配。 在首页出现的最初几个小时中，大约有 30 万次。 我知道，这仍然不是惊天动地。 -您可能需要一个可靠的工具，该工具可以优化所有图像，无论格式如何。 [Kraken.io](https://kraken.io/) 是一种这样的工具。 +但是人们（尤其是我的客户）对 RoR FUD 的了解尤其深刻，以至于他们在扩展方面没有任何见解。 只有精英的，“成功的” Web 2.0 初创公司才能使它进入每天流量 100-200k 唯一身份的流量平流层。 而且，正如我们所看到的（如果您具有正确的站点配置文件/缓存策略等），可以花$ 400 左右处理！ -### 关于 Kraken.io +客户真正应该问的是，它可以经济/高效地进行扩展吗？ -Kraken.io 是图像优化和压缩 SaaS 平台，具有其他操作功能，例如图像大小调整。 我们的目标是尽可能自动缩小图像的字节大小，同时保持视觉信息的完整性和始终如一的高质量，从而无需手动检查结果的保真度。 +以每千次展示费用 3 美元（对于这些网站我会定期获得），每天 550k 网页浏览量可使您每月获得约 5 万美元的收入。 $ 400 只是其中的 1％。 哪一家科技公司不希望硬件+托管成本占收入的 1％？ -### 软件 +当然，这类网站不是 Google……但它们与 Digg，reddit 等网站所需的编码并没有太大区别。 -除了基于 PHP 的 Kraken.io 前端外，几乎我们所有的软件都是在 [节点](https://nodejs.org/en/) 中编写的。 由于优化流水线能够使用二进制数据流，因此我们大量使用了节点流。 +“通过将唯一的页面视图与页面视图相结合，本文犯了一个大错误。” -从来没有把它混为一谈。 -当图片首次出现在我们的平台上时，首先会通过“ kraken-identify”过程进行抽签，以可靠地检测最重要的功能-图像格式（JPEG，PNG，GIF，SVG 等），图像类型（逐行/ 基线 JPEG，动画/静态 GIF 等），以及嵌入的颜色配置文件和 EXIF 元数据的存在。 +老实说，如果 Twitter 的 Web 前端在一天内看到这么多的流量，我会感到惊讶（它的 API 是另一回事）。 由于他们从未发布过这种效果的原始流量统计信息（至少最近），因此无论如何都是推测。 -我们只需要读取几个字节，就不需要解压缩整个图像，也不需要将解压缩的数据加载到内存中。 +是我，那个“没那么印象深刻”的家伙。 -确定我们刚收到的文件确实是图像后，我们将对其进行进一步处理。 对于某些特定的图像，我们还计算了独特颜色的数量。 唯一色计数是一种直方图类型的操作，它固有的速度很慢，无法对压缩数据进行处理，因此我们仅在非常特定的图像子集上使用它。 +好吧，除了陈述显而易见的事实之外，我不确定该去哪里：硬件和托管很便宜。 +如果您的公司为此支付了超过 1％的费用，则无论哪种方式，您都将面临严重的麻烦 +（当然，除非您的公司正在启动中）。 -然后，图片会通过 HTTP 通过我们的优化管道传递。 这使我们可以将二进制数据（图像本身）与优化设置（作为字段或标头）一起抽取。 与我们的优化集群的 HTTP 连接保持打开状态，直到该过程完成，并且来自集群的 HTTP 响应被流回到磁盘（直接流到 GlusterFS 目标位置），因此我们不会经常接触磁盘。 当我们从群集中流回整个响应时，任何优化后的数据都会通过 HTTP 标头传输。 +我看不到这是什么新闻，因为已经有几年了。 +如果硬件/主机价格昂贵，那么我们不会看到像 del.icio.us 这样的单人秀和其他人脱颖而出。 -（可选），如果 API 用户要求，我们可以将优化的资产存储在他或她选择的外部存储中- [S3](https://kraken.io/docs/storage-s3) ， [Azure](https://kraken.io/docs/storage-azure) ， [云文件](https://kraken.io/docs/storage-cloudfiles) 或 [SoftLayer [](https://kraken.io/docs/storage-softlayer) 。 +维持在线业务的主要成本现在已经不是短时间内的托管或硬件。 -最后一个任务（用于 API）是终止与 API 客户端的 HTTP 连接，并以优化结果做出响应，例如： +那不是完全正确的... -{ +托管对您来说并不是一个大笔开支，但是如果您经营一个视频网站，托管肯定可以。 一个相当不错的规模视频网站可以轻松地每月赚取 50-100k 美元。 如果那是您在该网站规模上的收入的 1％，请向我发送一些投资信息-我参与其中！ -“ file_name”：“ sku126933.jpg”， +就像我之前说过的那样，Shanti 的成功不应仅仅因为他的网站不如我们所研究的网站大或因为我们看到系统在相似的水平上而被抛弃。 关键是他的系统在很大程度上扩展到了他以前从未处理过的水平，而且它“行之有效”。 我对 RoR 的了解还不够，无法知道这是否很常见，或者 Shanti 的系统是否构建良好。 无论哪种方式，恭喜您-不要让我们失望。 -“ original_size”：35761， +@Anonymous-太好了，您现在是在声音较弱的少数族裔中，而在“缩放很便宜”方面。 =） -“ kraked_size”：10799， +我刚刚开始专职咨询，排名第一的问题是“ Rails 可以扩展吗？” 如果不是问题，那我就告诉他们。 但博客圈似乎喜欢 Rails 无法扩展的模因。 -“ saved_bytes”：22462， +谢谢布伦特。 是的，希望有一天我能回顾这一经历，并想“哇，550k，花生！” 但在那之前，这肯定是个人的里程碑。 干杯! -“ kraked_url”：“ https://dl.kraken.io/api/3e/db/24/08e20232a13c35fc1a72356537/sku126933.jpg”， +看来本文中的链接可能已损坏。 想阅读它吗-可以解决？ :) -“ original_width”：600， +谢谢！ 我是这个网站的忠实粉丝。 -“ original_height”：600， - -“成功”：是 - -} - -对立即解析响应正文不感兴趣的用户可以使用我们的 [Webhook 传递系统](https://kraken.io/docs/wait-callback) 。 通过在请求中指定 callback_url，用户将指示 API 应用程序将优化结果 POST 到其自己的端点。 在这种情况下，我们排队一个 Webhook 任务（使用 Redis 作为代理）。 仅用于 Webhook 交付的其他计算机从队列中使用，POST 优化结果并将一些数据保存在 MongoDB 中。 - -![](img/475b21b40578cce1b0ca3fb4ad356893.png) - -在 Kraken.io 帐户中交付了 Webhooks 视图 - -### 硬件 - -图像优化和重新压缩具有巨大的处理要求。 由于我们一直在努力降低总拥有成本，因此对我们而言，云决不是一个选择。 通过与我们的数据中心签订相当长的合同，我们可以将托管费用减少 30％。 - -一小会儿，在投资购买自己的硬件之前，我们一直在租用专用机器。 那没有按预期工作。 当时，我们的提供商阻止了 OS 的重新部署，并且我们不得不采用痛苦而费时的电子邮件通信路径来重新部署系统。 另外，您不知道之前有谁在使用该机器，该机器的整体运行状况如何以及真正*内部*安装了哪些组件。 有一天，我们发现，即使所有 API 机器都安装了相同的 CPU，但每台机器都有不同的 CPU 固件，并且 sysbench 的结果因机器而异。 - -幸运的是，这段时间已经过去很久了，我们在自己的硬件上运行，我们可以根据需要微调所有设置（尝试对租用设备进行 CPU 频率缩放）。 - -所有单插槽计算机（API，Web，负载平衡器，Webhook Delivery）当前正在运行 Xeon E3-1280 v5（Skylake）。 对于完成所有艰苦工作的 Optimization Cluster，我们每台计算机使用 2 个 Xeon E5-2697 v3，具有 128 GB RAM 和 RAID-1 设置中的四个 SSD 硬盘驱动器进行镜像。 在启用 HT 的情况下，上述设置使我们可以在每个群集计算机上访问 28 个物理核心和 56 个线程。 - -![](img/d41c0aa27e19d2ca09b52376afced93e.png) - -我们的优化人员之一（Xeon E5-2697） - -英特尔最近为 [E5-2600 产品线](http://ark.intel.com/products/family/91287/Intel-Xeon-Processor-E5-v4-Family#@All) 推出了 v4（Haswell），我们正在对此进行研究，但没有将群集升级到 v4 的紧迫性 。 - -Kraken.io 的平台占用大量 CPU 和 I / O，并处理大量文件。 为了在 I / O 级别获得更高的性能，我们将在未来几个月内为 API，集群和存储计算机推出 PCIe-SSD 驱动器。 - -![](img/03f3c40b55674ebe74d20048d4ee8179.png) - -API，存储和优化集群 - -自己的硬件需要一定的价格。 而且这个价格是，即使在高峰时期，您也需要比实际需要的容量多很多。 订购，压力测试和部署新机器最多需要 7 天的时间。 我们提供了一个定制的 AWS 集成，它将为我们提供计算优化的实例并扩展优化集群。 幸运的是，即使我们发现集群计算机上的负载高达 60（每个线程 1.07），我们也从未使用过它。 该解决方案的缺点是，我们不仅必须为 AWS 实例支付额外费用，而且还必须为数据中心与 AWS 之间的额外流量支付额外费用。 - -### 供应，发现和软件部署 - -我们安装的每台新计算机都由 [工头](http://theforeman.org/) 管理和配置。 我们将所有配置都保留在 [Puppet](https://puppet.com/) 中，因此只需单击几下即可使新机器进入生产就绪状态。 在 Puppet 中维护健康的代码库是另一个需要讨论的主题，尤其是在谈论定制软件包时。 - -软件部署是通过 [Capistrano](http://capistranorb.com/) 完成的。 因为所有应用程序都是用 Node 编写的，所以几乎所有应用程序都使用类似的配方。 当我们需要查明过去发生的特定部署并将其与 [中的可用数据关联时，与](https://www.serverdensity.com/) [Slack](https://slack.com/) 的集成非常有用。 ] ServerDensity 或 [ElasticSearch](https://www.elastic.co/) 。 - -![](img/789f0f90cf2f2ae722c7d6ab9b77ab6e.png) - -Capistrano 的松弛集成 - -### 数据存储 - -我们在三台独立的机器上使用 [副本](https://docs.mongodb.com/manual/replication/) 设置中的 [MongoDB](https://www.mongodb.com/) 作为我们的主要数据存储。 由于我们的数据集相对较小，并且我们对所有时间序列数据都使用了封顶集合，因此我们从未真正考虑过 DB 分片。 当然，看着三分之二的 DB 机器几乎什么也不做，只是等待主服务器发生故障，这不是我喜欢的事情，但是当时间到来时（并且会），我们会睡得很好。 - -第二个数据存储是 [前哨](http://redis.io/topics/sentinel) 设置中的 [Redis](http://redis.io/) 出于与上述相同的原因）。 主要用作 Kraken.io 前端上的任务队列和会话管理的消息代理。 - -### 文件存储 - -在上一代 Kraken.io 中，我们曾经将优化的资产直接存储在执行优化工作的同一台计算机上。 在将角色（API，Web，处理群集和存储）分离之后，我们发现自己迫切需要可扩展的网络文件系统。 [GlusterFS](http://www.gluster.org/) 易于设置且易于维护。 - -从应用程序服务器到 GlusterFS 计算机，我们有数百万个图像通过网络传输。 对于我们而言，非常重要的一点是不要经常移动这些文件。 一旦保存在 Gluster 中，图像将停留在该位置，直到其自动删除为止。 - -说到-清理作业。 通过 API 优化的图像会在 1 小时后自动删除，而通过 Web Interface 处理的图像会在我们的系统中保留 12 个小时。 在存储计算机上运行的清理脚本需要首先统计所有目录，并选择 mtime > 1hr（对于 Web Interface 为 mtime > 12hr）的目录。 当您拥有数百万个目录时，对它们的简单统计可能会花费大量时间，因此我们希望清理脚本能够快速运行。 可行的简单补救措施是将具有优化映像的目录放入另外三个级别的两字符目录中。 - -用作目标目录的原始文件 ID，例如 dd7322caa1a2aeb24109a3c61ba970d4 变为 dd / 73/22 / caa1a2aeb24109a3c61ba970d4 - -这样，在第一层，第二层和第三层上最多可以遍历 255 个目录。 - -### 负载均衡器 - -外部和内部负载平衡器都是 [Nginx](http://nginx.org/) -基于 [Keepalived](http://www.keepalived.org/) 。 即使我们的两个外部环境都出现问题，内部的环境也会自动提升自己，也为公共交通服务。 这也有助于我们晚上入睡，并给我们时间用新机器从柏林到法兰克福旅行（飞行 1 小时）。 - -我们在内部计算机上未使用任何 HTTP 服务器。 所有内部流量都从负载均衡器直接反向代理到 Node 应用程序。 要记住的一件事-Nginx 默认使用 HTTP 协议 1.0 作为 HTTP 代理。 将 proxy_http_version 标志设置为 1.1 可以节省很多麻烦，并且通常可以提高性能，尤其是对于长时间运行的保持活动连接。 - -### 联网 - -由于我们在上行链路级别（两个独立的 10 Gbps 上行链路）上也很冗余，因此每个机架至少需要两个交换机，每台机器至少需要两个以太网控制器。 随着机架的增长，每台计算机在交换机上占据五个端口（BMC，到控制器 1 的上行链路 A 和 B，到控制器 2 的上行链路 A 和 B），当前我们在每个机架上运行四个 HP ProCurve 交换机。 - -![](img/e10c297d02037a8efb5f0a6b9d03bcee.png) - -Kraken.io Architecture，2016 年 5 月 - -### 监视和警报 - -在上一代 Kraken.io 中，我们使用了 Sensu，Graphite 和 InfluxDB。 由于我们想将全部注意力转移到产品本身，而不是维护和监视监视工具（谁在监视正在监视它们的监视工具？），因此我们需要一种 SaaS 来减轻这种痛苦。 在测试了几项服务之后，我们最终选择了 [ServerDensity](https://www.serverdensity.com/) 作为我们所有机器的主要监视和警报工具，并且到目前为止，它仍然可以正常工作。 - -![](img/f4965c287ba863ff68f9a572930631d2.png) - -ServerDensity 指标始终显示在我们的办公室中 - -作为一项附加措施，我们使用 [Pingdom](https://www.pingdom.com/) 进行正常运行时间和实时用户监视。 我们已经从 Pingdom 看到了一些误报，而解决方法只是增加需要失败的支票的数量才能发出警报。 - -### 数据挖掘 - -当我们尝试将支持的技术数量保持在最低限度时，我们使用了外部 ElasticSearch 提供程序。 平均每天，我们会发送 2GB 的日志以进行进一步处理和数据挖掘。 可以这样查询 ES 非常方便： - -“为我提供 800 Kb 以下 JPEG 文件的优化结果，该文件具有嵌入式 ICC 配置文件，唯一颜色计数大于 10.000，用户 X 在三天前进行了无损优化”。 - -在我们不断努力改进优化堆栈时，我们需要能够立即跟踪我们的部署结果。 在峰值负载下，足以在“优化集群”中进行一些小的调整，并在几分钟之内获取有意义的数据。 - -### 摘要 - -如果您到目前为止做的不错，那将涵盖 Kraken.io 基础结构工程的有趣部分。 我们相信，随着我们的发展和订户数量的增长，我们将继续学习更多，希望您喜欢本文。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=11910151) - -我总是喜欢阅读有关图像优化的文章。 -但是在本文之后，我检查了 kraken.io 网站，以及所有可用的信息... :( - -总体来说不错。 尽管看到整条文章中散布着大量的“流行语”，这似乎是一种绝技。 不过，请欣赏本文的坦率。 - -对于正在为其 Web 应用程序寻求图像优化服务的人的旁注-现代 CDN 已经将此作为其产品的核心部分。 Instart Logic 特别提供了出色的图像优化服务，您可以利用专有算法利用它来转换图像，调整图像大小并降低图像质量。 - -您可以在构建时压缩和缩小映像，然后可以由您选择的任何 CDN 进行选择。 这个过程已经使用了数十年。 - -这是我们今天在 [CircleHD](https://circlehd.com "CircleHD") 使用的一些工具 - -gifsicle-压缩 GIF 图像 -jpegtran-压缩 JPEG 图像 -optipng-压缩 PNG 图像 -svgo-压缩 SVG 图像 - -@AgnivaDeSarker：我很好奇您在上一篇文章中有什么资格成为“流行语”？ \ No newline at end of file +抱歉，我无法找到原始文章。 \ No newline at end of file diff --git a/docs/200.md b/docs/200.md index d0efc55..4aa0274 100644 --- a/docs/200.md +++ b/docs/200.md @@ -1,270 +1,348 @@ -# Poppen.de 建筑 +# Google 如何针对行星级基础设施进行行星级工程设计？ -> 原文： [http://highscalability.com/blog/2010/4/12/poppende-architecture.html](http://highscalability.com/blog/2010/4/12/poppende-architecture.html) +> 原文： [http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html](http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html) -这是 Alvaro Videla 的来宾，他描述了 [Poppen.de](http://www.poppen.de/) 这个流行的德国约会网站的架构。 该站点非常类似于 NSFW，因此在单击链接之前请多加注意。 我发现最有趣的是，他们如何使用 Nginx，MySQL，CouchDB 和 Erlang，Memcached，RabbitMQ，PHP，Graphite，Red5 和 Tung 等技术，成功地将一些旧代码与一些新代码成功融合。 +![](img/9c7095e31a8c5999cdcef74072ddf82a.png) -## 什么是 Poppen.de？ +Google 如何保持其所有服务正常运行？ 他们似乎从来没有失败过。 如果您想知道我们在 [GCP NEXT 2016](https://cloudplatformonline.com/next2016-schedule.html) 上发表的演讲中的精彩幕后花絮， [Melissa Binde](https://www.linkedin.com/in/mbinde) ，Google Storage SRE 总监： [Google 如何针对行星级基础架构](https://www.youtube.com/watch?v=H4vMcD7zKM0)进行行星级工程。 -Poppen.de（NSFW）是德国最热门的约会网站，尽管与 Flickr 或 Facebook 这样的巨头相比，它可能是一个很小的网站，但如果您开始遇到一些扩展问题，我们认为这是一个不错的架构。 +梅利莎（Melissa）的讲话很简短，但充满智慧，而且以一种胡说八道的方式表达出来，使您认为服务是否失败梅利莎（Melissa）绝对是您想要的那种人。 -## 统计资料 +哦，什么是 SRE？ 它代表*站点可靠性工程*，但定义更难以理解。 就像您要求道的定义时得到的答案一样。 正如 Google 的本·斯洛斯（Ben Sloss）24x7 副总裁所明确指出的那样，这不仅仅是一个过程，更是一个过程，他将 SRE 定义为： -* 2.000.000 用户 -* 20.000 个并发用户 -* 每天 300.000 条私人消息 -* 每天 250.000 次登录 -* 我们有一个由 11 个开发人员，2 个设计师和 2 个 sysadmin 组成的项目团队。 +> 当软件工程师承担了过去称为操作的任务时会发生什么。 -## 商业模式 +让它在您的头部反弹一会儿。 -该网站使用免费增值模式，用户可以免费执行以下操作： +最重要的是，有一件事很清楚：SRE 是生产的保管人。 SRE 是 google.com 和 GCP 的客户体验的托管人。 -* 搜索其他用户。 -* 互相写私信。 -* 上传图片和视频。 -* 有朋友 -* 视频聊天。 -* 多得多… +对我来说，一些演讲重点： -如果他们想发送无限制的消息或上传无限制的图片，则可以根据需要为不同类型的成员付费。 视频聊天和网站的其他部分也是如此。 +* **点检正常运行时间的破坏性激励与功能**相比。 SRE 试图解决想要推送功能的开发人员与想要通过不推送功能来维持正常运行时间的系统管理员之间的天然紧张关系。 +* **错误预算**。 这就是预期会失败的想法。 这不是一件坏事。 用户无法确定服务的运行时间是 100％还是 99.99％，因此您可能会出错。 这减少了开发人员和运营人员之间的紧张关系。 只要维持错误预算，您就可以推出新功能，而运营方也不会受到指责。 +* **目标是立即恢复服务。 故障排除将在稍后进行。** 这意味着在恢复服务后，您需要大量日志记录和工具来进行调试。 由于某种原因，这使[较早的文章](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html)上的内容闪烁了起来，同样基于 Google SRE 的讲话：*备份无用。 这是您关心的*还原。 +* **没有无聊的分页哲学**。 当页面进入时，应该是一个有趣的新问题。 您不希望无聊的 SRE 处理重复性问题。 这就是机器人的目的。 -## 工具箱 +演讲中其他有趣的话题是：SRE 的组织结构如何？ 如何聘请开发人员担任侧重于生产的角色并使他们满意？ 我们如何保持团队在 Google 内部的价值？ 我们如何帮助我们的团队更好地沟通并解决与数据而非断言或权力夺取的分歧？ -### Nginx 的 +让我们继续吧。 以下是 Google 如何针对行星级基础设施进行行星级工程... -我们所有的网站都通过 Nginx 提供服务。 我们有 2 台 Nginx 前端服务器，在高峰时间每分钟向 www.poppen.de 发送 150.000 个请求。 它们是使用四年的计算机，每个计算机只有一个 CPU 和 3GB RAM。 然后，我们有单独的机器来提供站点图像。 每分钟由 3 个 nginx 服务器处理* .bilder.poppen.de（图像服务器）有 80.000 个请求。 +## 保持平衡：点检正常运行时间的破坏性动机与功能 -Nginx 让我们做的很酷的事情之一就是从 Memcached 发出很多请求，而无需点击 PHP 机器来获取已经缓存的内容。 因此，例如，用户配置文件是站点中 CPU 占用最大的页面之一。 请求配置文件后，我们会将全部内容缓存在 Memcached 上。 然后 Nginx 服务器将命中 Memcached 并从那里传递内容。 每分钟有 8000 个请求从 Memcached 发送出去。 +* 系统管理员会在站点正常运行时获得 Cookie 的正常运行时间。 当网站停滞不前时，我们会吸引访问者，访问者会给我们钱。 -我们有 3 个 Nginx 服务器正在从本地缓存中传递图像。 用户将他们的图片上传到中央文件服务器。 图片请求将命中 3 台 Nginx 服务器之一。 如果图片不在本地缓存文件系统中，则 Nginx 将从中央服务器下载图片，将其存储在本地缓存中并提供服务。 这使我们可以负载均衡图像分布并减轻主存储机中的负载。 +* 开发人员会获得功能的 Cookie。 发布一个新功能，访问者来了，他们给了我们钱。 -### PHP-FPM +* 生产冻结，也就是新功能的冻结，通常映射为增加正常运行时间。 -该站点在 PHP-FPM 上运行。 我们使用 28 台 PHP 机器，每个机器具有两个 CPU 和 6GB 的内存。 他们每个运行 100 个 PHP-FPM 工作进程。 我们使用启用 APC 的 PHP5.3.x。 PHP 5.3 版本使我们可以减少 30％以上的 CPU 和内存使用率。 +* 开发人员和系统管理员之间存在天生的紧张关系。 开发人员会获得发布功能的 Cookie。 系统管理员会获取 Cookie 以确保正常运行时间。 -该代码是使用 symfony 1.2 PHP 框架编写的。 一方面，这意味着额外的资源占用，另一方面，它使我们可以加快开发速度，并拥有众所周知的框架，可以使我们轻松地将新开发人员集成到团队中。 这里并不是所有的东西都是“花和玫瑰”。 因此，尽管我们拥有该框架提供的许多优势，但我们还是不得不对其进行大量调整，以使其达到服务于 www.poppen.de 的任务。 +* 因此，系统管理员因阻止新功能发布而获得奖励。 如果开发人员能够解决系统管理员的问题，他们将获得奖励。 -我们所做的就是使用 XHProf（Facebook 的 PHP 概要分析库）对站点进行概要分析，然后优化瓶颈。 由于该框架易于自定义和配置，因此我们能够缓存大多数昂贵的计算，这些计算给 APC 中的服务器增加了额外的负载。 +* 开发人员进行他们所谓的 Beta 测试是为了尽快发布功能。 -### 的 MySQL +* 系统管理员执行他们所谓的启动审核，以减慢新功能。 -MySQL 是我们的主要 RDBMS。 我们有几台 MySQL 服务器：一台 32GB 的机器，带有 4 个 CPU，用于存储所有与用户有关的信息，例如个人资料，图片元数据等。该机器已有 4 年的历史。 我们计划将其替换为分片群集。 我们仍在设计此系统，以尽量减少对我们的数据访问代码的影响。 我们希望按用户 ID 对数据进行分区，因为网站上的大多数信息都以用户本身为中心，例如图像，视频，消息等。 +* 您的团队将所有的时间都花在彼此抗争上，因此您会增加停机次数，风险，混乱和无政府状态。 -我们有 3 台机器在用户论坛的主从配置中工作。 然后有一个服务器群集，用作网站自定义消息系统的存储。 目前，它有超过 2.5 亿条消息。 它们是在主从站主/从站从站系统中配置的 4 台机器。 +* 您想要的是消除异想天开的命令。 请按规则处理，以便团队可以有目标并共同努力。 -我们还有一个由 4 台计算机组成的 NDB 集群，用于写入大量数据，例如哪个用户访问了哪个其他用户的个人资料的统计信息。 +* 与 devops 一样，有一种方法可以使开发人员和操作人员一起工作。 问题是，devops 无论走到哪里都有不同的含义。 相反，SRE（站点可靠性工程）定义明确。 -我们尝试尽可能避免像瘟疫这样的联接并缓存。 数据结构被高度非规范化。 为此，我们创建了摘要表，以简化搜索。 +* **SRE：** **当您要求软件工程师设计和运行操作时会发生什么情况**-Ben Sloss 24x7 VP，Google -大多数表都是 MyISAM，可提供快速查找。 我们看到越来越多的问题是全表锁。 我们正在转向 XtraDB 存储引擎。 + * 软件工程师-事实证明，当知道软件的人也运行服务时，服务可以更好地运行。 他们对什么使它打勾有深刻的理解。 -### 记忆快取 + * 设计和运行-实际上是设计您的生产环境，而不是让它成为意外的事故。 -我们大量使用 Memcached。 我们有超过 51 个节点的 45 GB 缓存。 我们将其用于会话存储，视图缓存（如用户配置文件）和函数执行缓存（如查询）等。我们对用户表拥有的大多数按主键进行的查询都缓存在 Memcached 中，然后从那里传递 。 我们拥有一个系统，该系统可在每次修改该表的一条记录时自动使缓存无效。 将来改善缓存失效的一种可能解决方案是使用新的 Redis Hash API 或 MongoDB。 使用这些数据库，我们可以以足够的粒度更新缓存，而无需使其无效。 +* 假设有 1000 个 SRE 在 Google 的基础架构上工作：网络，计算，存储等。有多少个 SRE 负责云计算？ -### 兔子 MQ + * 所有。 -自 2009 年中以来，我们将 RabbitMQ 引入了我们的堆栈。 这是一个易于部署并与我们的系统集成的解决方案。 我们在 LVS 后面运行两个 RabbitMQ 服务器。 在上个月，我们一直在将越来越多的东西移到队列中，这意味着目前 28 台 PHP 前端计算机每天大约发布 50 万个作业。 我们向队列发送日志，电子邮件通知，系统消息，图像上传等等。 + * google.com 和 GCP（HTG1）的运行之间没有界限。 不需要让云团队和内部团队进行沟通的开销。 他们创造了一种环境，可以帮助所有人协同工作。 -为了使消息入队，我们使用了 PHP-FPM 提供的最酷的功能之一，即 fastcgi_finish_request（）函数。 这使我们能够以异步方式将消息发送到队列。 在生成必须发送给用户的 HTML 或 JSON 响应后，我们将调用该函数，这意味着用户不必等待我们的 PHP 脚本清理完毕，例如关闭 Memcached 连接，DB 连接等。 同时，所有保存在内存数组中的消息都将发送到 RabbitMQ。 这样，用户也不必等待。 +## 技能：SRE 是一个印章团队和圣职 -我们有两台专用于处理这些消息的机器，目前总共运行 40 个 PHP 进程以消耗作业。 每个 PHP 进程消耗 250 个工作，然后死亡并重新生成。 我们这样做是为了避免 PHP 出现任何形式的垃圾回收问题。 将来，我们可能会增加每个会话消耗的作业数量，以提高性能，因为事实证明重新分配 PHP 进程会占用大量 CPU。 +* 本节的标题是我的描述。 具有技能的 SRE 必须是精英。 在工作方面，他们仅致力于这种几乎准神秘的事物，称为生产。 -该系统使我们可以改善资源管理。 例如，在高峰时间，我们甚至每分钟可以登录 1000 次。 这意味着我们将对 users 表进行 1000 个并发更新，以存储用户的上次登录时间。 因为现在我们使这些查询入队，所以我们可以依次依次运行每个查询。 如果我们需要更高的处理速度，我们可以将更多的使用者添加到队列中，甚至可以将机器加入集群中，而无需修改任何配置或部署任何新代码。 +* SRE 必须比开发人员更熟练，才能完成相同的工作： -### CouchDB + * 他们需要更大的技能范围。 -为了存储日志，我们在一台计算机上运行 CouchDB。 从那里我们可以按模块/动作查询/分组日志； 事实证明，发现问题出在哪里很有用。 在将 CouchDB 用作日志聚合器之前，我们必须在每台 PHP 机器上登录并拖尾-f，然后从那里尝试找出问题所在。 现在，我们将所有日志中继到队列，然后使用者将它们插入 CouchDB。 这样，我们可以在集中的地方检查问题。 + * 所有 SRE 必须通过完整的软件开发人员面试才能被录用。 -### 石墨 + * 所有 SRE 必须通过一次非抽象的大型系统设计采访。 -我们使用[石墨](http://graphite.wikidot.com/)从网站收集实时信息和统计信息。 从每个模块/动作的请求到 Memcached 命中/未命中，RabbitMQ 状态监视，服务器的 Unix 负载等等。 Graphite 服务器每分钟进行约 4800 次更新操作。 实践证明，该工具对于查看站点中的实际情况非常有用。 它是简单的文本协议，其图形功能使它易于使用，几乎可以即插即用到我们要监视的任何系统。 +* SRE 必须具有相同的软件技能，这是不同的应用领域。 -我们使用 Graphite 做的一件很酷的事情是监视同时运行的网站的两个版本。 去年一月，我们部署了由新版本的 symfony 框架支持的代码。 这意味着我们可能会遇到性能下降的情况。 我们能够在一半的服务器中运行该站点的一个版本，而新版本则在其他服务器中运行。 然后，在 Graphite 中，我们为每半创建 Unix 负载图，然后进行实时比较。 + * 开发人员专心于产品经理并制作功能。 -由于我们发现新版本的 Unix 负载较高，因此我们启动了 XHProf 分析器并比较了这两个版本。 我们使用 APC 存储“标志”，这些标志使我们可以启用/禁用 XHProf，而无需重新部署代码。 我们有一个单独的服务器，在其中发送 XHProf 配置文件，然后从那里汇总它们并进行分析，以找出问题所在。 + * SRE 依赖于生产，以使生产达到最佳状态。 -### 红色 5 +* **当将面向开发和面向生产的观点结合在一起时，最终的设计会更强大**。 -我们的网站还向用户提供视频。 我们有两种。 一种是来自用户配置文件的视频，这些视频是用户制作和上传的电影。 此外，我们还有一个视频聊天功能，可让我们的用户互动并分享他们的视频。 在 2009 年中，我们每月向用户流式传输 17TB 的视频。 +* 入职流程示例给出了 SRE 带来的一个示例，该过程在将团队的项目置于 SRE 的责任之下时发生。 在评估团队的软件时，他们发现： -### 宗宗 + * 当达到规模时，它将在生产中失败。 -Tsung 是用 Erlang 编写的分布式基准测试工具。 我们使用它来进行 HTTP 基准测试，并比较我们计划使用的 MySQL 的不同存储引擎，例如新的 XtraDB。 我们有一个工具可以记录到主 MySQL 服务器的流量，并将该流量转换为 Tsung 基准测试会话。 然后，我们重播了这些流量，并通过 Tsung 生成的数千个并发用户访问了实验室中的计算机。 很棒的事情是，我们可以产生更接近实际生产环境中发生情况的测试方案。 + * 开发人员已隐式假定某种呼叫不会失败。 -## 得到教训 + * 他们假设请求的分配是均匀的。 -* 虽然面向 Buzz 的开发很酷，但**仍在寻找具有重要社区的工具**。 当有问题需要解决时，或者需要将人员纳入团队时，文档和良好的社区将非常宝贵。 symfony 规定，可以免费获得 5 本以上的官方书籍。 CouchDB 和 RabbitMQ 的开发人员也提供了良好的支持，它们具有活跃的邮件列表，可以及时回答问题。 -* **了解您正在使用什么以及这些系统/库的局限性是**。 我们从 symfony 中学到了很多东西。 可以在哪里进行调整以及可以改进什么。 就 PHP-FPM 而言，我们可以这么说，只是通过阅读文档，我们发现强大的 fastcgi_finish_request（）函数被证明是非常有用的。 另一个例子是 Nginx，Nginx 社区已经解决了一些问题，例如我们对图像存储缓存的解释。 -* **扩展工具**。 如果他们运行良好，则无需在当前堆栈中引入新软件。 我们已经编写了几个 Nginx 模块，这些模块甚至已经被 Nginx 社区测试过。 这样，您可以回馈。 -* **D** **对于无关紧要的**并不保守。 石墨似乎是在生产中运行的一种很酷的工具，但是关于它的报道并不多。 我们只需要尝试一下。 如果它不起作用，我们可以禁用它。 如果我们无法在系统中得到一个很好的 Unix Load 图，谁也不会哭。 今天，甚至我们的产品经理都喜欢它。 -* **测量所有**：Unix 负载，站点使用情况，Memcached 命中率/丢失率，每个模块/动作的请求等。学习解释这些指标。 -* **创建工具，使您可以尽快对问题做出反应**。 如果您必须回滚部署，那么您不想花费一秒钟以上的时间。 -* **创建工具，使您可以实时分析网站的情况**。 在实验室中，大多数测试都给出了乐观的信息，但随后却无法应对生产负荷。 + * 他们以为不会受到用户的关注。 -## 未来 + * 他们假定所有请求的大小均处于平均水平。 -* 构建一个新的，更具可伸缩性的消息系统，因为当前版本相当旧，并且并非针对如此大量的消息而设计。 -* 将越来越多的处理任务移至队列系统。 -* 将更多的 Erlang 应用程序添加到我们的系统中。 事实证明，RabbitMQ 对我们和 CouchDB 都适用。 它们是易于安装和部署的系统，从而增加了我们对 Erlang 作为语言/平台的信任。 -* 我们正在寻找 Red5 的替代产品，可能是用 Erlang 编写的 Oneteam Media Server。 目前，当我们使用开源 Erlang 产品时，我们可能会开始使用该语言编写我们自己的应用程序，因为现在我们已经有了使用它的经验。 -* 改进我们的日志可视化工具。 + * 他们在两条尾巴上失败了（没有给出解释）。 -我要感谢 Alvaro Videla 的出色写作。 如果您想共享 fablous 系统的体系结构，请 [与联系我](http://highscalability.com/contact/)，我们将开始。 +## 组织：为开发人员提供不让运营工作积聚的理由 -让我们做数学。 每分钟有 15 万个请求到 www。*，这意味着每秒有 2500 个请求。 -他们有 28 个 PHP 框，每个框有 100 个进程。 这意味着 2800 个 PHP 进程。 -您需要尽可能多的 PHP 进程来处理并发请求（不是每秒）。 这意味着它们的脚本要么花费 1 秒来执行每个脚本，要么它们有很多方法可以执行。 -不管哪种方式，东西都坏了。 +* 该系统必须设计为不增加运营工作，因为如果开发人员不从事工作，他们将不会那么在意。 -我知道有使用 2-4 台服务器使用 PHP 满足此请求数量的网站。 不是 28。 +* **SRE** 的开发预算。 如果您的系统的运营开销很大，那么您获得的开发人员就不会那么多，那么您就无法推广那么多的功能。 -Quote： -**此系统使我们可以改善资源管理。 例如，在高峰时间，我们甚至每分钟可以登录 1000 次。 这意味着我们将对用户表进行 1000 个并发更新，以存储用户的上次登录时间** +* SRE 具有完全不同的命令链。 他们有自己的副总裁，与开发副总裁分开。 这赋予了他们权力和权力。 当生产意味着他们需要拒绝时，它允许他们说不。 一堆不是的传呼猴子。 -不，这并不意味着您有 1000 个并发更新。 这意味着您每秒大约有 16 次登录，这意味着您可能有 10-20 次并发更新。 大多数时候少很多。 +* 当开发人员说他们可以捐赠人数时，SRE 不必接受。 SRE 可以说服务不够重要，请自己继续提供支持。 -还要注意，它们有 50 个 memcached 节点。 他们必须处理多少台服务器来处理这种中等负载？ 太疯狂了 +* SRE 是一种稀缺资源。 并非 Google 的每个团队都有 SRE。 云确实可以，但是不是每个其他团队，甚至不是云中的每个小服务，都只是重要的。 -结论：并不令人印象深刻，我还没有看到任何新见解。 我对他们的代码的效率提出了很多质疑。 +## 环境：如何使开发人员在生产团队中保持快乐？ -您好 Alvaro，感谢您对体系结构的有趣了解。 我提出了两个问题：-如何衡量并发用户（超时？），为什么使用这么小的数据集使用如此多的节点进行内存缓存？ 问候，保罗 +* **至少有 50％的工作需要为项目工作**。 不待命。 不是门票。 不开会。 实际上是在做项目工作。 -您可以提供指向 Graphite 的链接吗？ 听起来很有趣，我们已经开始研究这些系统，但是它的含义如此普遍，以至于简单的 Google 都无法提出我认为正确的任何东西。 +* 如果项目工作量过多，则开发人员会为 SRE 分配更多的人员，或者将额外的工作流转给开发人员团队。 -可以在 [http://graphite.wikidot.com/](http://graphite.wikidot.com/) 上找到石墨网站。 +* 什么是项目工作？ -@霜： + * 通过切换基础数据库技术来改善服务的延迟。 --对 poppen.de 的 150.000 请求并不意味着它们全部都到达了 PHP 后端。 + * 编写自动化以加速部署。 -“我知道使用 2-4 台服务器使用 PHP 满足此请求数量的站点。不是 28 台。” 这取决于他们做什么，他们缓存了什么，可以从请求中缓存多少。 它们显示多少个局部分量？ 网站信息是否完全动态？ 问题列表可以继续。 除此之外，我们将平均负载保持在较低水平，并且我们有足够的服务器来满足计划的增长。 + * 跨服务的项目。 Google 作为一项内部服务，可以由其他服务（通常由软件 bot）在内部进行查询，如果可以安全地将计算机停机，可以安全地将机架停机或者将数据中心安全地停机，则可以返回 Google ？ -除此之外，当您建立网站时，您还必须做出商业决策。 不像您选择有关网站编程理论的最佳书籍。 在我们的例子中，我们使用框架和 ORM。 这使我们发展很快。 您也必须考虑到这一点。 我了解到，在不了解其他公司背后的背景的情况下很难谈论它们。 +* SRE 是一支志愿军。 没有草稿。 -关于对数据库和登录号的并发查询，您是对的，我在编号上犯了一个错误。 我向读者道歉，因为他们提供了误导性的信息。 另一方面，我希望您和该站点的其他读者能够理解使用队列服务器可以完成的工作。 如果您已经知道了这一点，并且不需要向我学习，那么对您会更好。 我希望这对至少一名开发人员有用。 + * 您可以随时转入另一个 SRE 团队。 -50 个 Memcached 节点并不意味着有 50 个专用计算机。 + * 您可以随时转换为 dev。 -@保罗 p： + * Mission Control 是一个程序，开发人员可以在其中试用 SRE 并查看他们是否喜欢它。 -我们有一个“谁在线”服务器来跟踪在线用户。 它使用超时将其标记为已注销。 +* 团队很流畅。 人们来自团队，分享经验，分享观点。 -我们使用几个 Memcached 节点，因为根据要缓存的内容，我们有专门的存储桶。 例如，我们有视图缓存，用于缓存模板。 函数缓存，用于将查询缓存到数据库。 然后，一个 Memcached 专门将查询缓存到一个表等。这样，一个 memcached 的使用不会影响其他表。 +## 预算：您可以支出任意预算的错误预算 -@理查德： +* 如果您有 3 个 9 的可用性，目标是不将其提高到 4 个 9，那么您的错误预算为.1％。 -http://graphite.wikidot.com/ +* **如果您想更快地推出功能并使 GCP 变得更好，那就去做吧。 直到用尽错误预算。** -嗨，阿尔瓦罗 我想向您介绍一个更好的流服务器： [erlyvideo](http://erlyvideo.org) ，值得测试，在您的情况下它将处理多少用户（对我来说，它可以从一台计算机上支持 1800 个连接）。 +* 如果您希望进行较差的测试，使软件定期出现故障并且必须不断回滚，那么您也可以选择该选项，但是错误预算很快就会用光，并且您将无法启动 。 -如果需要，请写 [[受电子邮件保护]](/cdn-cgi/l/email-protection) 。 +* 错误预算按季度循环。 ->我们希望按用户 ID 对数据进行分区，因为网站上的大多数信息都以用户本身为中心，例如图像，视频，消息等。 +* 有一个逃生阀：三枚银子弹。 -哼...这很有趣...会不会创建太多分区？ 我对 Mysql 不太熟悉，但是我正在研究的那个 MySQL 建议我们不要创建超过 2000 个分区。 + * 一个开发人员可以说我真的需要推动，请给我一个银弹。 -但是，在用户 ID 上进行分区将意味着几个 100K +分区。 + * SRE 会说“ OK”，但您必须说服 VP 您实际需要推动。 -@Alvaro： + * 这个仪式听起来很愚蠢，但功能非常强大。 它将控制权交给开发人员。 他们有 3 个灵丹妙药，由他们的副总裁来决定是否合适。 -因此，如果他们甚至不使用 PHP，那么我更正确的是您的脚本太慢，进程太多。 但这不是真正的问题。 +* 错误预算基于每个服务。 因此，如果多个开发团队使用相同的服务，则它们共享相同的预算。 -我正在谈论的站点具有很多动态内容，但是缓存非常聪明，而且它们不使用任何框架或 ORM 包装器。 -这就是我认为您可能损失 90％的性能的地方，这些东西往往是绝对的性能杀手。 -当然，您可以在开发时间上获得一些优势，但是一旦达到一定的规模，就会希望您没有走这条路。 -为使用更智能查询和缓存的对象编写一些类并不难。 + * SRE 不在交战的开发团队中间。 他们必须弄清楚如何花费错误预算。 -您的前端有 2.5k re / s，memcached 可以提供 133 re / s。 这是否意味着您的缓存命中率为 5％？ +* 机外。 如果所有其他方法都失败了，并且开发人员和 SRE 确实不同意，则 SRE 可以派遣开发团队。 -而且请不要使用“每分钟的请求数”，没有人对规模感兴趣。 它主要是“每秒请求数”，突然之间您的数字似乎不再那么大了，因为它只有 60 分之一。 + * 像和睦的离婚。 -@Abhishek： + * 这是至关重要的逃生阀门，因此团队在很长一段时间内都不会出现令人讨厌的分歧。 -他没有说每个用户一个分区，而是说了按用户 ID 划分的分区。 这并没有暗示有关分区大小的任何信息。 每个分区可以是 100 个用户或 100 万个用户。 它仅告诉您使用哪个键来决定将值存储在哪个分区中。 -同样，这与 MySQL 本身无关。 你在做什么？ 还有 2000 个分区？ 是，对.. + * 很少见，但确实发生了。 一个示例场景是，如果团队不想在其 ACID 类型项目中使用 Spanner，如果开发团队说他们想建立自己的团队，那么 SRE 团队可以说他们不想为团队提供支持。 去建立自己的数据库，因为这对生产不利。 -有趣。 -您使用任何类型的虚拟化/云服务还是全部物理硬件？ 任何 CDN？ -什么操作系统/发行版？ +* SRE 是 google.com 和 GCP 的生产托管人，SRE 是客户体验的托管人。 -阿尔瓦罗 +## SRE 支持在频谱上 -很棒的帖子。 我认为阅读和查看如何解决许多问题很有趣。 关于石墨也不错的技巧。 +* 聊天和咨询。 与开发人员聊天。 进行白板会议。 -此致 -尼克拉斯 +* 协同设计。 与开发人员一起创建设计。 -嗨，阿尔瓦罗。 您说过您正在使用 memcached 来缓存诸如用户个人资料之类的视图组件。 您能否说明有关如何使这些视图缓存无效的更多详细信息？ +* 完全所有权。 完全拥有的服务。 所有容量，所有供应，所有页面。 -我了解您在更改数据时编写了自己的代码来使“数据缓存”无效。 但是对于视图缓存，有很多数据，任何数据更改都将使该视图缓存无效。 你是怎样做的？ +* 页面是保持诚实的一种方式。 它们不是 SRE 的目的。 -我的第一感觉：太多的 PHP 服务器。 我认为在这种情况下，Symfony 对于他们来说 PHP 框架太慢了。 从我的经验中得知，Symfony 吃了很多 CPU。 + * 负责制作的人应该抓这些页面，因为这样可以使他们的皮肤保持游戏中的外观。 -我真的认为他们应该用更具扩展性和轻量级的 PHP 框架取代 Symfony + * 它还有助于使 SRE 的技能，专长和观点保持最新。 -@Max Lapshin +## 是什么让事情顺利进行？ 文化和过程 -感谢您对 Erlyvideo 的提示，几个月前我们也对此进行了调查。 我们尚未决定。 +* Google 会进行常规的培训和通话阴影处理。 -@Maxim R +* Google 也有一个名为：**不幸轮盘**的过程-卷轴游戏。 -我们使用 EC2 进行视频传输，其他系统则托管在我们的物理服务器中。 服务器正在运行 SLES10。 + * 一个人是地牢大师，他们有一个受害者，团队轮流尝试猜测发生了什么。 -@尼尔·H + * Google 运行非常复杂的系统。 除了进行培训的人之外，很少有人真正知道发生了什么以及答案是什么。 -我们对键进行“命名空间”，因此可以立即使相关的键集失效。 但这取决于网站的哪一部分。 因此，在这里很难解释所有这一切。 参见此处，了解许多常见模式：http://code.google.com/p/memcached/wiki/FAQ + * 这对新的来电者很有用。 让他们在受控环境中进行测试。 -@pcdinh + * 一些团队在某些场景中会破坏生产并让新手对其进行修复。 -如果您是 http://twitter.com/pcdinh，那么我可以告诉您，我们不使用 16 核 Dell / HP 之类的计算机。 我们使用具有 8 核的 6G Ram 的旧刀片服务器。 除此之外，我们将这些机器的平均负载保持得非常低。 + * 对退伍军人也有好处。 最好重新整理您的知识，尤其是在使用非常复杂的系统时。 -然后，关于 symfony 或任何 PHP 框架，尽管它们不是比普通的 PHP 代码或更轻量级的框架最快的解决方案，但速度并不是选择框架时唯一考虑的问题。 symfony 拥有强大的支持，强大的社区和大量文档。 这意味着我们可以轻松雇用已经知道我们所使用技术的人员。 那么，如果我们使用超快速的自定义框架，然后编写它的“黑客”离开了公司，会发生什么呢？ 谁来维护他的代码？ 从理论上讲，您关于迁移到另一个框架的建议听起来不错，但是您知道将站点代码移植到另一个框架可能需要花费几个月的时间吗？ 我们还必须支付开发人员的薪水，而在大多数情况下，这些薪水都比其中一台刀片服务器贵。 因此，正如我在之前的回答中所说，公司会做出业务决策，而不仅仅是因为速度快而选择了这种框架。 +## 事件管理 -因此，请不要将服务器数量归咎于 symfony，因为虽然 yes 比普通的 PHP 代码重，但这不是我们使用那么多服务器的原因。 如果不是，那为什么要使用 PHP？C 的速度要快得多。 +* 场景：您正在呼叫 gmail，并且您获得了一张票证，用户可以看到其他用户的电子邮件。 你是做什么？ 关闭 gmail。 -Alvaro，我绝不会质疑您的基础架构，因为您比这里的其他任何人都了解它，尤其是其中一些“扶手椅系统架构师”。 :) -但是该语句 +* **Oncallers 被完全授权采取一切措施来保护用户，保护信息，保护 Google。** 如果这意味着要关闭 gmail 甚至关闭所有 google.com，那么作为 SRE，您的副总裁将为您提供支持，而您的 SVP 将为保护 Google 提供支持。 -> 我们还必须支付开发人员的薪水，而在大多数情况下，这些薪水都比其中一台刀片服务器贵。 +* **目标是立即恢复服务。 故障排除将在稍后进行。** -can lead you into a corner. you can throw money at hardware only for so long until your investment start to produce diminishing returns and your infrastructure becomes too unwieldy and then it'll be that much harder to do any meaningful code changes. + * 有二进制状态的记录。 有日志。 -保持服务器负载“ *非常*低”又有什么意义呢？ 如果服务器在可接受的时间内返回数​​据，负载是多少（故障或严重超载除外）有关系吗？ + * 醒着，开发人员在办公室，所有人都在时，请进行故障排除。 目的是使服务重新启动并运行。 -听起来您所有的服务器都在内存缓存池中。 我很好奇，PHP 服务器具有更大的 APC 缓存大小而不是将其用于内存缓存会更好吗？ +## 你该怪谁？ -@马克西姆 R. +* 当“新开发者”推送代码并破坏 google.com 达三个小时时，您应该对谁负责？ a）新开发者 b）代码审查。 c）缺乏测试（或被忽略）的测试。 d）缺乏针对代码的适当的金丝雀程序。 e）缺乏快速回滚工具。 -感谢您的见解。 我同意你的看法。 不是说您去硬件上花钱，应该有一个平衡点。 我们也会在可能的情况下尝试改进代码。 e .：每当我们向站点功能添加功能时，我们都会尝试提高性能，重构代码等，因为我们需要在腐烂之前对其进行维护。 我们正在开发一种用于 SQL 查询的轻量级解决方案，根据我们的基准测试，该解决方案将减轻站点的大量负载，因为我们可以删除我们使用的 ORM，这是很沉重的。 我们的网站在不断发展，我们正在像每个人一样从错误中学习。 + * 除了新开发者以外的所有东西。 **如果新开发人员编写的代码会导致该网站瘫痪，那不是开发人员的错。 这是开发人员和工作人员之间所有关口的错。** -关于平均负载语句，我说过，因为对于某些评论者来说，我们有 28 台完全过载的计算机。 除此之外，我们拥有这些机器是因为我们正在计划未来的增长，如果一切都按计划进行，那么到将来我们的意思是迫在眉睫。 + * **绝对不允许人为错误传播到人外。** 查看允许部署损坏的代码的过程。 -关于 APC 与 Memcache。 我们必须考虑更多。 有时我们讨论的与您刚才所说的相同。 同时，一些经验丰富的 PHP 开发人员告诉我，APC 在拥有大量 RAM 时不能很好地工作。 我没有与此相关的经验可以发表意见。 另外，APC 缓存不共享，如果这也是一个问题，我们必须考虑。 我们也将一些计算缓存到 APC 中。 +## 无罪的岗位形态 -阿尔瓦罗 +* 避免责备文化至关重要。 -感谢**很棒的文章**！ 我对您的 nginx 和 memcached 有一个问题。 您写道，许多请求甚至都没有达到 PHP，因为 Nginx 从 memcached 获取了缓存的内容-您能再描述一下吗？ 您是否缓存 HTML 页面？ +* 研究表明，大多数事件是人为错误引起的。 -问候， +* **最好通过了解实际发生的事件来解决事件。** 不知道发生了什么的最好方法？ 通过寻找责任人来揭开每一个事件。 -@阿尔瓦罗 +* 人们真的很擅长隐藏，并确保没有线索，并确保您实际上不知道发生了什么。 试图怪罪只会使您的工作更加困难。 -Erlyvideo 发展非常迅速。 几个月前，您可以看到它的前一代，什么也做不了。 因此，如果您有兴趣，最好通过电子邮件进行交流。 +* 在 Google 谁搞砸了谁写的事后验尸。 这样可以避免命名和遮挡。 使他们有能力纠正错误。 促成失败的每个人都应尽可能诚实地参与进来，并写下您如何陷入困境。 -+1 感谢您的精彩文章！ +* 已在全体会议上给予拆除该站点的奖金，因为他们立即拥有该站点，因此他们拥有了该站点。 他们上了 IRC，并将其回滚。 他们说出来并如此迅速地照顾好他们，便获得了奖金。 -Alvaro，我认为您应该尝试 Erlyvideo-它在 Erlang 中很烂，而且发展非常迅速。 我认为，erlyvideo 的作者 Max Lapshin（привет，Макс:)可以提供支持并实现所需的所有功能。 +* 无赖并不意味着没有名称和细节。 这意味着我们不会因为事情出错的原因而选择别人。 不应发生诸如断电之类的事情，应予以解雇。 -Alvaro，您尝试过 Facebook 的 HipHopPHP 编译器吗？ +* 深度防御 -> 我发现最有趣的是他们如何成功地将一些旧的和一些新的 + * 由于策略是纵深防御，因此事后评估模板将操作分为预防，检测和缓解措施。 -不，他们没有成功地将新旧融合在一起。 -poppen.de 以运行缓慢而闻名。 它几乎从来没有真正快过，而且每隔几（6-8）周就会额外减速至少几小时，通常是 1-2 周。 -当前的缓慢周期自大约 6 周开始，至今仍未结束。 poppen.de 的性能给 a * s 带来了痛苦。.远非成功... + * **我们希望防止中断，我们希望更快地检测到它们，并希望减轻影响。** -> 我们有 2 个前端 Nginx 服务器 + * 如果类似的情况再次发生，它将不会传播到很远，持续太久或影响那么多的客户。 -Alvaro, are these 2 servers in a master/master setup? Which is the solution to make them highly available/load balanced? Regards \ No newline at end of file +## 分页的无聊哲学 + +* 团队喜欢看什么样的页面？ 新的和有趣的。 + +* 您知道如何解决的页面很无聊。 您应该创建一个机器人来解决该问题。 + +* Google 发明了许多机器人。 他们不喜欢无聊。 + +* 如果您可以写下修复它的步骤，那么您可能可以编写自动化来修复它。 + +* 不要做机器人可以为您做的事情。 + +* 构建漫游器的结果是，理想情况下，每个页面都是全新的，因此不会感到无聊。 甚至经验丰富的工程师也可能在每次寻呼机关闭时都看到一些新内容。 + +* **这是哲学的根本变化。 如果一切正常，重复的事件很少，则意味着您在调试系统时不会像以前那样沉迷于此。** + +## 需要更强大的调试工具 + +* **如果所有问题都是新问题，则意味着您需要更强大的调试工具来查找问题。** + +* 文本日志不是调试工具。 如果您不知道要查找的内容，则无法在日志文件中查找模式的标准调试无法进行。 使用 GCP 大小的平台，您需要浏览多少个外观才能找到失败的外观？ + +* Google 严重依赖于各种可视化工具来解决不熟悉的问题并尽快恢复服务。 + +* 绘图工具：石墨，InfluxDB + Grafana，OpenTSDB。 + + * 这些和其他提到的工具不是 Google 使用的工具，因此不建议使用，但它们是有用工具的开放源代码示例。 + + * 很高兴看到正在发生的一切。 Google 拥有数十亿亿个流程，因此您需要汇总视图才能理解事物。 + + * **Google 在其二进制文件中放置了很多工具。** 在新情况下，您并不总是知道您要寻找的东西。 + +* 创建一个框架，使开发人员可以轻松地插入监视框架。 + +* 大量存储空间专门用于存储监视数据。 + + * **的想法是，您不想在中断期间进行故障排除。 中断仅与恢复服务有关。** + + * 故障排除是您稍后醒来时要执行的操作。 开发人员经常参与故障排除过程，因为他们对系统有更深入的了解。 + + * 历史数据必须可用，以便故障恢复后可以进行故障排除。 恢复不会导致中断监视数据丢失。 + + * 这种方法可以使停机时间尽可能短，同时可以在以后解决问题。 + +* 事件绘图-对于关联事件非常有用。 + + * 充分利用人类的模式匹配能力，很难编写机器人来做到这一点。 + + * 给出了一个图表示例，其中每行是一个数据中心，列是时间，单元格中的颜色是事件类型。 + + * 这可以帮助您找到不是单个事件的模式，例如导致级联故障的软件推出，或者一起重复出现的错误簇，或者如果您看到延迟尖峰之后立即出现错误尖峰 重复一遍。 这些都将有助于确定问题的根本原因。 + +* 可视化过程跟踪-有时您需要深入到过程级别以识别性能问题。 + + * 开源选项不多：Performance Co-Pilot + vector。 + + * Google 有一个非常复杂的框架，可将示例查询拉入存储并提供完整的跟踪记录。 + + * 可视化工具的优点是很难理解时间戳。 可视化工具使您可以更轻松地折叠，展开和比较事件。 + +* 网络流量和容量 + + * 开源选项：仙人掌，天文台和 Nagios + + * 事实证明，很多存储缓慢的问题实际上是网络问题。 + + * 如果您正在查看存储系统，但无法弄清为什么它对网络的访问速度很慢。 + + * 您需要一个工具来快速查看网络状态。 哪些链接超载？ 您看到多少个包错误？ 链接断开了吗？ + +* 日志文件-当所有其他失败时 + + * 开源：ElasticSearch + Logstash（+ Kibana） + + * 您不想遍历日志文件。 您需要一个具有更多类似查询的 SQL 的系统，以便您可以挖掘日志。 + + * 日志应易于使用且易于理解。 + +## Stackdriver 错误报告 + +* 如果您想看看 SRE 所拥有的那种工具的例子，那么请看 [Google Stackdriver 错误报告](https://cloud.google.com/error-reporting/) 。 + + * 这是他们能够用于服务的内部工具。 + + * 通过分析堆栈跟踪将分组错误并进行重复数据删除 + + * 系统了解所使用的通用框架并相应地对错误进行分组。 + +* 该计划将做更多。 Google 内部拥有广泛的工具，他们希望向云客户提供这些工具。 + +## 相关文章 [ + +* [在 HackerNews](https://news.ycombinator.com/item?id=12116121) 上/ [在 Reddit](https://www.reddit.com/r/programming/comments/4tg31p/how_does_google_do_planetscale_engineering_for_a/) 上 +* 图书：[网站可靠性工程：Google 如何运行生产系统](https://www.amazon.com/Site-Reliability-Engineering-Production-Systems-ebook/dp/B01DCPXKZ6)。 它是由从事实际 SRE 工作的实际 Google SRE 编写的，是作者 500 年综合经验的结果。 +* [大规模计算，或者说 Google 如何扭曲我的大脑](http://matt-welsh.blogspot.com/2010/10/computing-at-scale-or-how-google-has.html) +* [网站可靠性工程师-使 Google 保持 24/7 全天候运行](http://transcriptvids.com/v2/yXI7r0_J29M.html) +* [服务水平和错误预算](https://www.usenix.org/conference/srecon16/program/presentation/jones) +* [SREcon](https://www.usenix.org/conference/srecon16) 。 会议视频[可用](https://www.usenix.org/conference/srecon16/program)。 看起来内容很多。 +* [小组：谁/什么是 SRE？](https://www.usenix.org/conference/srecon16/program/presentation/definition-of-sre-panel) +* [策略：规划停电的 Google 样式](http://highscalability.com/blog/2010/3/5/strategy-planning-for-a-power-outage-google-style.html) +* [Google 如何备份互联网以及 EB 级其他数据](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html) +* [什么是“网站可靠性工程”？](https://landing.google.com/sre/interview/ben-treynor.html) +* [成为 Google 的网站可靠性工程师（SRE）感觉如何？](https://www.quora.com/What-is-it-like-to-be-a-Site-Reliability-Engineer-SRE-at-Google) +* [我的警惕](https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/preview#)的哲学，作者：Rob Ewaschuk，Google SRE +* [这是 Google 确保（几乎）永不衰败的方式](http://www.wired.com/2016/04/google-ensures-services-almost-never-go/) + +FWIW，Stack Driver 并不是他们能够用于服务的内部工具； 这是 Google 购买的 SaaS 创业公司。 + +https://techcrunch.com/2014/05/07/google-acquires-cloud-monitoring-service-stackdriver/ \ No newline at end of file diff --git a/docs/201.md b/docs/201.md index 49302c0..2516d33 100644 --- a/docs/201.md +++ b/docs/201.md @@ -1,47 +1,105 @@ -# 策略：缓存 404 在服务器时间上节省了洋葱 66％ +# 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事，以及 Tarantool 与此相关的内容 -> 原文： [http://highscalability.com/blog/2010/3/26/strategy-caching-404s-saved-the-onion-66-on-server-time.html](http://highscalability.com/blog/2010/3/26/strategy-caching-404s-saved-the-onion-66-on-server-time.html) +> 原文： [http://highscalability.com/blog/2016/8/30/the-cat-and-mouse-story-of-implementing-anti-spam-for-mailru.html](http://highscalability.com/blog/2016/8/30/the-cat-and-mouse-story-of-implementing-anti-spam-for-mailru.html) -![](img/cfdc345e67ee6ab77afd7b46784522a3.png) +![](img/1295631a0c5a13e4ec2d6e35538297c0.png) -在 [The Onion Use Django，以及为什么它对我们如此重要](http://www.reddit.com/r/django/comments/bhvhz/the_onion_uses_django_and_why_it_matters_to_us/)一文中，他们提出了许多有趣的观点，说明了他们雄心勃勃的基础架构从 Drupal / PHP 迁移到 Django / Python：这一步并不难， 由于他们之前有移动 AV 的经验，所以花了时间和工作 俱乐部网站； 核心框架 API 的混乱使移动比停留更具吸引力； 支持站点旧版本的结构是一个尚未解决的问题； 内置的 Django 管理员节省了大量工作； 通过“减少专业化或黑客攻击的碎片”，团体开发变得更加容易； 他们使用 IRC 进行分布式开发； 狮身人面像用于全文搜索； nginx 是媒体服务器和反向代理； haproxy 将启动过程设为 5 秒程序； Capistrano 用于部署； 清洁的组件分离使移动更加容易； Git 版本控制； 具有复杂查询集的 ORM 是一个性能问题。 memcached 用于缓存渲染的页面； CDN 每 10 分钟检查一次更新； 视频，文章，图像和 404 页均由 CDN 提供。 +大家好！ -但是最令人惊讶的一点是： +在本文中，我想向您介绍一个为 Mail.Ru Group 的电子邮件服务实现反垃圾邮件系统的故事，并分享我们在此项目中使用 [Tarantool](https://tarantool.org/) 数据库的经验：Tarantool 的任务是什么 ，我们面临的局限性和整合性问题，陷入的陷阱以及我们最终如何得到启示。 -> 最大的性能提升是：缓存 404 并在 404 上将 Cache-Control 标头发送到 CDN。我们多达 66％的服务器时间都花在了从蜘蛛爬取无效的 url 和从野外存在的 url 中提供 404 的服务中 6-10 年前。 [编辑：实施更改后，我们的出站带宽减少了约 66％，Web 服务器群集上的平均负载减少了约 50％]。 -> -> 我们的链接中的一小部分来自旧内容，而我不再知道其网址。 我们重定向了 5 年前的所有内容。 最初在 6 到 10 年前发布的东西可能会被重定向，但是它们都不来自数据库，并且最初都是静态 HTML，在我开始为 The Onion 工作之前就没有维护重定向。 +让我从简短的回溯开始。 大约十年前，我们开始为电子邮件服务引入反垃圾邮件。 我们的第一个过滤解决方案是卡巴斯基反垃圾邮件和 RBL（*实时黑洞列表-*是与垃圾邮件发送有关的 IP 地址的实时列表）。 这样可以减少垃圾邮件的发送，但是由于系统的惯性，我们无法足够快地（即实时）抑制垃圾邮件的邮寄。 另一个没有满足的要求是速度：用户应该以最小的延迟接收经过验证的电子邮件，但是集成解决方案的速度还不足以赶上垃圾邮件发送者。 垃圾邮件发件人在发现垃圾邮件未送达时，可以非常快速地更改其行为模型和垃圾邮件内容的外观。 因此，我们无法忍受系统的惯性，而开始开发自己的垃圾邮件过滤器。 -> 蜘蛛占我 404 的绝大多数。 他们请求的 URI 根本不在我们的标记中。 我无法修复损坏的蜘蛛，并告诉它不要请求甚至不存在的这些链接，但是我仍然必须服务于它们的 404。 +我们的第二个系统是 MRASD-Mail.Ru 反垃圾邮件守护程序。 实际上，这是一个非常简单的解决方案。 客户的电子邮件到达 [Exim](http://www.exim.org) 邮件服务器，并通过充当主要过滤器的 RBL 到达，然后到达 MRASD，在那里发生了所有不可思议的事情。 反垃圾邮件守护程序将邮件分解为几部分：标头和正文。 然后，它使用基本算法对每个片段进行归一化，例如对字符大小写进行归一化（全部以小写或大写形式），将外观相似的符号转换为特定形式（例如，使用一个符号表示俄语和英语“ O”）等 标准化后，守护程序提取了所谓的“实体”或电子邮件签名。 我们的垃圾邮件过滤器会分析电子邮件的不同部分，并在发现任何可疑内容时将其阻止。 例如，我们可以为“ viagra”一词定义一个签名，所有包含该词的消息都会被阻止。 实体也可以是 URL，图像，附件等。 在反垃圾邮件检查过程中完成的另一件事是为已验证的电子邮件计算指纹。 计算为少数棘手的哈希函数的指纹是邮件的独特特征。 基于计算出的哈希值和收集的哈希统计信息，反垃圾邮件系统可以将邮件过滤为垃圾邮件或让其通过。 当哈希值或实体达到某个频率阈值时，服务器开始阻止所有匹配的电子邮件。 为此，我们维护了统计数据（计数器）来跟踪遇到某个实体的频率，接收者抱怨该实体的频率，并设置了一个实体标志 SPAM / HAM（在与垃圾邮件相关的术语中，“ ham”与“ 垃圾邮件”，表示经过验证的电子邮件不包含垃圾内容。 -> CDN 未缓存我们的 404 页。 允许对它们进行缓存，可以将原始渗透率大大降低，与未缓存的 404 相比，输出带宽减少了 66％。 +MRASD 的核心部分是使用 C ++实现的，而其相当多的业务逻辑是使用解释性语言 Lua 来实现的。 正如我已经说过的那样，垃圾邮件发送者是非常有活力的人，他们会很快改变其行为。 我们的目标是尽快对垃圾邮件发送者的每项更改做出响应，这就是为什么我们使用解释性语言实施业务逻辑的原因（借助 Lua，我们不必每次都在所有服务器上重新编译系统并进行更新）。 另一个要求是速度：Lua 中的代码在性能测试中显示出良好的结果。 最后，很容易与 C ++中的代码集成。 -> Edit: This is not to say that our 404s were not cached at our origin. Our precomputed 404 was cached and served out without a database hit on every connection, however this still invokes the regular expression engine for url pattern matching and taxes the machine's network IO resources. +![](img/0e0752752d353aa16839d288763f4911.png) -无意开玩笑，讽刺或讽刺。 这些流量大部分来自蜘蛛，它们正在寻找组成页面，因此保留 URL 并不是问题。 问题是减少了这些有毒蜘蛛的影响，并且将 404 页缓存为解毒剂。 即使您像 The Onion 一样已经有十多年没有上网了，但仍然很容易就可以找到很多东西。 +上面的方案说明了我们的反垃圾邮件过滤器的简化工作流程：电子邮件从发件人发送到我们的邮件服务器； 如果该消息已成功通过主过滤器（1），则它进一步进入 MRASD（2）。 MRASD 将其检查结果返回到邮件服务器（3），并根据这些结果将邮件传递到收件人的“垃圾邮件”文件夹或收件箱中。 -## 相关文章 +MRASD 允许我们将未过滤的垃圾邮件数量减少十倍。 随着时间的流逝，我们不断改进系统：添加了新的子系统和组件，引入了新的工具。 因此，系统不断发展，变得更加复杂，反垃圾邮件任务也变得更加多样化。 这些变化无助于影响我们的技术堆栈。 这就是本故事的下一部分。 -* [文章](http://news.ycombinator.com/item?id=1219133)上的 Hacker News Thread，其中 John Onion 耐心地尝试解释为什么 The Onion 没有惹恼广告收入。 -* [HTTP 404 响应代码](http://en.wikipedia.org/wiki/HTTP_404) -* [Fighting Linkrot](http://www.useit.com/alertbox/980614.html) by **[Jakob Nielsen](http://www.useit.com/jakob/ "Author biography")** +**技术堆栈的演进** -404 占很大比例的原因是因为洋葱是 CDNed：合法的（非 404）请求主要由 CDN 服务。 但是由于 404 被 CDN 缓存，所以 CDN 将请求发送到原始服务器。 因此 404 会在原始服务器上的点击中占不成比例的百分比。 +在电子邮件服务时代的曙光中，消息流以及消息内容比今天明显稀缺。 但是工具和计算能力的选择也较差。 从上面描述的 MRASD“父母”模型可以看出，有必要存储各种统计数据。 这些数据的很大一部分是“热”的（即经常使用），这对数据存储系统提出了某些要求。 结果，我们选择了 MySQL 作为“冷”数据的存储系统，但是对于“热”统计数据仍然不确定。 我们分析了所有可能的解决方案（它们的性能和功能适用于“热”数据，但不适用于关键任务数据），最终到达 [Memcached](https://memcached.org/) -那时，此解决方案已经足够稳定。 但是我们在存储“热”和关键数据方面仍然存在问题。 与任何其他缓存解决方案一样，Memcached 也有其局限性，包括不进行复制以及缓存关闭（并刷新）后的长时间预热时间。 我们的进一步搜索将我们带到了[京都内阁](http://fallabs.com/kyotocabinet/)，这是一个非关系键值数据库系统。 -如何阻止其中一些蜘蛛？ 任何人都有一个很好的坏蜘蛛清单。 -我读过一个博客 Bing Spider，它会在短时间内在某些网页上重复查询，这给网站带来了负担。 因此，所有者必须禁止它。 +时间过去了，电子邮件工作量增加了，反垃圾邮件工作量也增加了。 出现了需要存储更多数据的新服务（Hadoop，Hypertable）。 顺便说一句，今天的高峰处理工作量达到每分钟 55 万封电子邮件（如果我们每天计算平均值，则每分钟大约有 35 万封电子邮件），每天要分析的日志文件量超过 10 TB。 让我们回到过去：尽管工作量不断增加，但我们对数据处理（加载，保存）的要求却保持不变。 有一天，我们意识到京都议定书无法管理所需的数据量。 此外，我们需要一种存储系统，它具有针对“热”和关键数据的更广泛功能。 也就是说，是时候到处寻找更好的替代方案了，这些替代方案将更灵活，更易于使用，并具有更高的性能和故障转移功能。 那时，一个名为 Tarantool 的 NoSQL 数据库在我们公司中获得了普及。 Tarantool 是公司内部开发的，完全满足了我们的“ wannas”。 顺便说一句，我最近一直在修改我们的服务，当我遇到最早的 Tarantool 版本之一时[HT HTG0] Tarantool / Silverbox ，我感到自己是一名考古学家。 我们决定尝试一下 Tarantool，因为它的基准测试涵盖了我们所需的数据量（该时期我没有确切的工作量数据），并且也满足了我们对内存使用的要求。 另一个重要因素是项目团队位于隔壁，我们可以使用 JIRA 快速提出功能请求。 我们是决定在他们的项目中尝试使用 Tarantool 的先驱者之一，我认为其他先驱者的积极经验大大鼓舞了我们迈向 Tarantool 的第一步。 -行动不便的洋葱。.如果那些记忆力很强的爬虫恰好是 googlebot，则您会以 SEO 的形式浪费大量收入。 几年前的旧页等于从 800 磅重的怀抱中走了出来。 大猩猩/蜘蛛/章鱼/大象在房间里。 +那就是我们的“ Tarantool 时代”开始的时候。 我们积极地将 Tarantool 引入了我们的反垃圾邮件体系结构。 今天，我们有了基于 Tarantool 的队列，用于存储各种统计数据的高工作量服务：用户信誉，发件人 IP 信誉，用户可信度（“业力”统计信息）等。我们目前的活动是将升级的数据存储系统集成到我们的 实体统计处理器。 您可能想知道为什么我们只针对我们的反垃圾邮件项目专注于一个数据库解决方案，而不考虑迁移到其他存储。 嗯，事实并非如此。 我们也考虑和分析竞争系统，但是暂时，Tarantool 可以很好地处理项目中所需的所有任务和工作负载。 引入新的（未知的，以前未使用的）系统总是有风险的，并且会花费大量时间和资源。 同时，Tarantool 是我们（以及许多其他项目）的知名工具。 我们的开发人员和系统管理员已经了解使用和配置 Tarantool 的所有知识，以及如何充分利用它。 另一个优势是 Tarantool 的开发团队不断改进其产品并提供良好的支持（这些人正在隔壁工作，这很不错:)）。 当我们仍在实施另一个基于 Tarantool 的解决方案时，我们获得了所有必要的帮助和支持（我稍后会告诉您）。 -“大部分流量来自蜘蛛寻找的组成页面，因此保留 URL 并不是问题。” +接下来，我将为您概述我们的反垃圾邮件项目中使用 Tarantool 的几个系统，这些系统将涉及我们面临的问题。 -如果按您的平均水平说超过 50％，那么他们仍然会丢弃高达 25％的流量。 除此之外，爬虫只会抓取其他网站的链接，因此它们也放弃了传入链接的 SEO 优势。 他们写有趣的故事是一件好事。 :-) +**我们使用 Tarantool** 的系统概述 -“行动不便的洋葱。如果那些记忆力很强的爬虫恰好是 googlebot，您会以 SEO 的形式浪费大量收入。几年前的旧书等于从 800 磅重的大抱抱。大猩猩/蜘蛛/章鱼/大象 -在房间里。” -他们不会放弃，只是将压力从服务器到 CDN 来处理这种 404 页。 -因此，在进行此更改之前，当您从服务器请求某个不存在的站点时，它就像： -客户端-> CDN->源服务器，然后再返回 CDN 和客户端。 -现在，当有人请求页面时，CDN 会检查其缓存（如果找不到或不允许从缓存中提供服务），然后请求为该页面提供服务的 Origin Server，如果那是 404，则发送标头 告诉 CDN 缓存该页面。 -因此，下一次该请求将直接从 CDN 的本地缓存中提供。 +**业力** -泰瑞尔 \ No newline at end of file +**业力**是一个数字值，表示用户的信任度。 它最初是为不需要复杂的从属系统的用户提供的通用“胡萝卜和棍子”系统的基础。 业力是基于从其他用户信誉系统接收到的数据的汇总值。 业力系统背后的想法很简单：每个用户都有其业力-越高，我们对这个用户的信任就越高； 越低，我们在反垃圾邮件检查期间评估他们的电子邮件时就越严格。 例如，如果发件人发送的电子邮件中包含可疑内容，并且发件人的业障评分很高，则此类邮件会打入收件人的收件箱。 较低的业障评级将是反垃圾邮件系统的悲观因素。 这个系统使我想到了老师在学校考试中查阅的一本考勤书。 参加所有班级的学生只会得到几个额外的问题，然后休假，而错过许多班级的学生则必须回答很多问题才能获得高分。 + +![](img/7bf90374f27a6f0f5e8309a6c0d7f616.png) + +用于存储与业力相关的数据的 Tarantool 在单个服务器上工作。 下图说明了每分钟一个这样的实例执行的请求数。 + +![](img/98697072a85fdef53622b857c064baf5.png) + +**RepIP / RepUser** + +**RepIP** 和 **RepUser** （信誉 IP 和信誉用户）是一种高工作负载服务，用于处理与具有特定 IP 以及与发送者（用户）的活动和动作有关的统计信息 与用户在一定时间内使用电子邮件服务的强度有关的统计信息。 该系统使我们知道用户已发送了多少电子邮件，其中有多少已被阅读，以及有多少被标记为垃圾邮件。 该系统的优势在于，它提供了时间轴，而不是用户活动的快照。 为什么这对于行为分析很重要？ 想象一下，您在没有任何沟通手段的情况下已移居国外，所有朋友都留在家里。 然后，几年后，您的小屋里有了网线。 哇！ 您浏览到自己喜欢的社交网络的网站，然后看到朋友的照片-嗯，他已经发生了很大变化……您可以从该照片中获得多少信息？ 我想不是太多。 现在想象一下，您观看了一个视频，该视频显示了您的朋友变迁，结婚等等……-那是一段简短的传记片段。 我敢打赌，在第二种情况下，您会更好地了解朋友的生活。 数据分析也是如此：我们拥有的信息越多，我们就可以更好地评估用户的行为。 我们可以注意到发件人的邮件活动趋势，了解发件人的习惯。 根据这种统计信息，为每个用户和 IP 地址分配“信任等级点”和一个特殊标志。 此标志用于主要过滤器中，该过滤器甚至可以在垃圾邮件到达我们的邮件服务器之前过滤掉多达 70％的垃圾邮件。 这个百分比说明信誉服务的重要性。 这就是为什么此服务需要最大的性能和容错能力的原因。 这就是为什么我们在这里使用 Tarantool 的原因。 + +![](img/51db83a4a247d755fc55d4a15b7e2177.png) + +信誉统计信息存储在两台服务器上，每台服务器有四个 Tarantool 实例。 下图说明了每分钟 RepIP 请求的平均数量。 + +![](img/83d0a0db50b56264fc18f1a63bc54062.png) + +在实施信誉服务时，Tarantool 遇到了许多配置问题。 与我们之前讨论的系统不同，RepIP / RepUser 的数据包更大：这里的平均包大小为 471,97 字节（最大大小为 16 KB）。 从逻辑上讲，数据包包括两个部分：一个小的“基本”部分（标志，汇总统计信息）和一个很大的统计部分（详细的按动作统计信息）。 对整个数据包进行寻址会导致大量的网络使用，因此加载和保存记录会花费更多时间。 许多系统仅需要数据包的基本部分，但是我们如何将其从元组中剥离（“元组”是 Tarantool 的记录术语）？ 这是存储过程很方便的地方。 我们在 Tarantool 的 **init.lua** 文件中添加了所需的函数，并从客户端对其进行了调用（从 Tarantool 1.6 版开始，您可以使用纯 C 语言编写存储过程）。 + +**1.5.20 之前的 Tarantool 版本存在问题** + +说我们从未遇到过 Tarantool 问题是错误的。 是的，我们有一些。 例如，在计划的重新启动后，Tarantool 客户端（超过 500 个）由于超时而无法重新连接。 当出现故障后，下次尝试重新连接的尝试被延迟了一段时间后，我们尝试引入渐进式超时，但这无济于事。 我们发现，问题在于 Tarantool 在其事件循环的每个周期内仅接受一个连接请求，尽管有数百个请求在等待。 我们有两种选择：安装新的 Tarantool 版本（1.5.20 或更高版本）或修改 Tarantool 的配置（禁用 *io_collect_interval* 选项可以解决此问题）。 Tarantool 开发人员很快修复了此错误，因此 Tarantool 1.6 或 1.7 将不会提供它。 + +**RepEntity-实体信誉** + +我们当前正在集成一个新组件，用于存储实体统计信息（URL，图像，附件等）。 **RepEntity** 。 RepEntity 的目的类似于已经讨论的 RepIP / RepUser 的目的：它提供有关实体行为的详细信息，这是我们的反垃圾邮件过滤器的决策标准。 借助 RepEntity 统计信息，我们可以根据电子邮件的实体过滤出垃圾邮件。 例如，邮件可能包含可疑的 URL（例如，其中可能包含垃圾内容或导致[网络钓鱼](https://en.wikipedia.org/wiki/Phishing)网站），而 RepEntity 可以帮助我们更快地注意到并阻止此类邮件。 怎么样？ 我们可以看到该 URL 的动态发送，并且可以检测到其行为的变化，这对于“固定”计数器是不可能的。 + +除了不同的数据包格式外，RepEntity 和 RepIP 系统之间的基本区别是 RepEntity 在我们的服务上产生了明显更高的工作负载（处理和存储的数据量更大，请求数量也更多）。 一封电子邮件最多可以包含一百个实体（最多 10 个 IP 地址），对于大多数这些实体，我们必须加载并保存完整的统计信息包。 值得注意的是，数据包由特殊的聚合器保存，该聚合器首先等待积累足够的统计信息。 因此，所有这些都意味着数据库系统要承担更多的工作量，并且需要准确的设计和实现。 **让我强调一下，由于某些项目限制，对于 RepEntity，我们使用了 Tarantool 1.5（因此，我将继续撰写此版本）。** + +首先，我们估计了存储所有统计信息所需的内存量。 为了更好地说明此任务的重要性，让我带来一些数字：在预期的工作量下，将数据包增加 1 个字节意味着将数据总量增加 1 GB。 如您所见，我们的任务是以最紧凑的方式将数据存储在一个元组中（正如我已经说过的，我们无法将整个数据包存储在一个元组中，因为我们经常要求仅检索一部分数据包数据） 。 要计算要存储在 Tarantool 中的数据量，我们还需要考虑： + +* 存储索引的额外空间 +* 用于在元组中存储数据大小的额外空间（1 个字节） +* 最大元组大小的限制为 1 MB（对于 1.7 版，请参见 [http://tarantool.org/doc/book/box/limitations.html](http://tarantool.org/doc/book/box/limitations.html) ） + +Tarantool 增加了各种请求（读取，插入，删除）的数量，从而产生超时错误。 我们的调查表明，在频繁插入和删除的情况下，Tarantool 启动了一个复杂的树重新平衡过程（我们的所有索引均为 TREE 类型）。 Tarantool 中的树索引具有棘手的自平衡逻辑，仅在满足某些“不平衡”条件时才会启动。 因此，当一棵树“失去足够的平衡”时，Tarantool 启动了重新平衡过程，这使得 Tarantool 变得口吃。 在日志中，我们发现消息*资源暂时不可用（errno：11）*，这些消息在几秒钟后消失了。 但是，尽管发生了这些错误，客户端仍无法获取请求的数据。 Tarantool 团队的同事提出了一个解决方案：尝试使用其他类型的树索引 AVLTREE，该索引在每次插入/删除/更改时都会重新平衡。 实际上，尽管重新平衡呼叫的数量有所增加，但其总成本却更低。 在更新架构并重新启动数据库之后，该问题永远消失了。 + +我们面临的另一个问题是清理过时的记录。 不幸的是，Tarantool（据我所知，对于 1.7 版也是如此）不允许为某个记录定义 TTL（生存时间），而忘记了它，而所有清理活动都委托给了数据库。 好了，您仍然可以自己使用 Lua 和 [box.fiber](http://stable.tarantool.org/doc/mpage/stored-procedures.html#sp-box-fiber) 实现所需的清理逻辑。 从好的方面来说，这提供了更大的灵活性：您可以定义复杂的清除条件，而不仅仅是基于 TTL 的条件。 但是，要正确实现清除逻辑，您需要注意一些细微差别。 我实施的第一根清洁纤维使 Tarantool 的速度非常慢。 事实是，我们可以删除的数据量大大少于记录的总数。 为了减少要删除的记录候选者的数量，我引入了基于所需字段的二级索引。 之后，我实现了一个遍历所有候选对象的光纤（其上次修改的时间戳早于指示的时间戳），检查了其他清除条件（例如，当前是否为记录设置了“正在进行写入”标志），并且 如果满足所有条件，则光纤会删除该记录。 当我在零工作负载下测试逻辑时，一切工作正常。 在低工作量的情况下也很好。 但是，当我将工作量增加到预期水平的一半时，我遇到了问题。 我的请求开始失败，并显示超时错误。 我知道我一定已经溜了。 当我深入研究这个问题时，我意识到我对光纤的工作方式有一个错误的认识。 在我的世界中，光纤是一个独立的线程，对接收和处理客户端请求没有任何影响（上下文切换除外）。 但是不久，我发现我的光纤使用了与请求处理线程相同的事件循环。 这样，我循环遍历大量记录而不删除任何内容，只是阻止了事件循环，因此未处理客户端请求。 为什么提到删除操作？ 您会看到，每次删除一些记录时，都会发生一次 yield 操作，该操作解除了事件循环的阻塞并允许处理下一个事件。 在这一点上，我得出的结论是，如果执行了一些 N 操作（其中 N 是一个经验推导的值，我取 N = 100）而没有产生屈服，则有必要强制屈服（例如，使用 *wrap.sleep（ 0）*）。 要记住的另一件事是，删除记录可能会触发索引更新，因此在遍历记录时我可能会丢失一些要删除的数据。 这是另一个解决方案。 在一个周期中，我可以选择一小部分元素（低于 1000 个）并遍历这些元素，删除所需的元素，并跟踪最后一个未删除的元素。 在下一次迭代中，我将从最后一个未删除的元素中选择另一小部分元素。 + +我们还尝试过实施一种解决方案，该解决方案可以在将来实现平滑的分片，但此尝试失败了：实现的机制开销太大，因此我们暂时放弃了分片。 希望我们可以在较新版本的 Tarantool 中找到重新分片功能。 + +这是一些性能提示。 + +要提高 Tarantool 的性能，您可以禁用* .xlog 文件。 但是请记住，在这种情况下，Tarantool 仅作为高速缓存工作，并具有所有的限制（我的意思是没有复制，重新启动后等待时间很长）。 这里的解决方法是不时制作快照，并在需要时使用它来还原数据。 + +如果一台计算机上有多个 Tarantool 实例，则可以将每个实例“精确定位”到某个 CPU 内核以提高性能。 但是，如果您说 12 个物理内核，那么开始 12 个实例就不好了，因为每个 Tarantool 实例与执行线程一起还具有一个 WAL 线程。 + +所需功能： + +* 分片。 +* 基于集群的方法，可以进行动态集群配置，例如在添加节点或节点出现故障的情况下派上用场，类似于 MongoDB（mongos）和 Redis（redis sentinel）。 +* 可以为记录清除定义 TTL（生存时间）。 + +**的结论** + +Tarantool 是我们反垃圾邮件系统的基石，我们许多重要的高工作量服务都基于此。 现成的[连接器](http://stable.tarantool.org/doc/mpage/connectors.html)使轻松将 Tarantool 与使用不同编程语言实现的组件集成在一起成为可能。 Tarantool 的成功历史悠久：多年来，在我们的反垃圾邮件项目中使用 Tarantool 以来，我们在操作或稳定性方面都没有遇到严重问题。 但是，要充分利用该数据库，您需要考虑一些配置上的细微差别（在这里我们一直在谈论 Tarantool 1.5 版的细微差别）。 + +关于我们未来计划的几句话： + +* 在我们的项目中增加基于 Tarantool 的服务的数量。 +* 迁移到 Tarantool 1.7。 +* 开始使用 Vinyl 引擎，尤其是对于 RepEntity 来说，真正的“热”数据量并不大。 + +[关于 HackerNews](https://news.ycombinator.com/item?id=12397570) + +保存 + +反垃圾邮件系统内部邮件处理的平均延迟是多少？ 是否有关于典型请求分解的任何分析信息？ \ No newline at end of file diff --git a/docs/202.md b/docs/202.md index 9863faa..3ee3092 100644 --- a/docs/202.md +++ b/docs/202.md @@ -1,211 +1,239 @@ -# Justin.tv 的实时视频广播架构 - -> 原文： [http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html) - -![](http://s.justin.tv/jtv_user_pictures/hosted_images/dark-small.png) - -未来是活的。 未来是实时的。 未来是现在。 无论如何，这是炒作。 由于它有做事的习惯，因此炒作正逐渐成为现实。 我们正在看到实时搜索，实时推文，实时位置，实时现实增强，实时螃蟹（新鲜和本地）以及实时事件发布。 所有直播技术中最具挑战性的一项是直播视频广播。 想象一下一个世界，每个人都是实时的广播人和视频流的使用者（< 250 毫秒延迟），所有这些使您可以直接进行对话和交互，而不会感到自己处于时移之中 战争。 实现这一目标所需的资源和工程必须足够。 你是怎样做的？ - -为了找到答案，我与 Justin.tv 创始人兼工程副总裁 Kyle Vogt 进行了交谈。 Justin.tv 当然有这个数字。 据报道，他们每月有 3000 万独立访问者在视频上传游戏中的表现甚至超过了 YouTube，据报道每分钟上传视频的时间比 You​​Tube 的 23 小时多了近 30 小时。我在听了另一位 Justin Kan 的[采访后要求接受采访 同名](http://www.gabrielweinberg.com/blog/2010/03/justin-kan-on-getting-traction.html) [Justin.tv](http://www.justin.tv) 的创始人。 贾斯汀（Justin）谈到实况视频与 YouTube 的批处理视频方法有本质的区别，后者将所有视频存储在磁盘上，然后按需播放。 实时视频无法通过更快地推送视频来制作，它采用了完全不同的架构。 由于 [YouTube 体系结构](http://highscalability.com/youtube-architecture)文章是该网站上最受欢迎的文章，因此我认为人们也可能会喜欢学习视频世界的现场知识。 凯尔（Kyle）投入大量时间和洞察力，对贾斯汀（Justin.tv）如何使所有实时视频魔术发生的事情产生了极大的兴趣，远远超出了通话范围，提供了大量多汁的细节。 任何构建系统的人都可以从他们的业务运作中学习到一些东西。 我非常感谢 Kyle 忍受着我永无止境的努力。 - -随着重点从批处理转移到实时，Justin.tv 正在采取的步骤在整个行业中也正在发生。 我们基本上已经学习了如何创建可伸缩的批处理系统。 实时性需要不同的架构。 例如，LinkedIn 已花费大量精力来构建[实时搜索](http://thenoisychannel.com/2010/01/31/linkedin-search-a-look-beneath-the-hood/)，即使对于复杂的查询，该查询也几乎是即时更新的。 他们通过在内存中对数据进行分区并编写自己的高度专业化的系统来使其工作来实现此目的。 - -Google 也许是实时更改的完美典范。 当 Google 有点笨拙时，他们每个月都会懒惰地更新搜索索引。 这是一个批处理模型，这意味着需要设计用于存储大量数据的基础结构，这需要高吞吐量而不是低延迟。 时代变了。 现在，谷歌大肆宣传[咖啡因](http://www.theregister.co.uk/2009/08/14/google_caffeine_truth)和[不断更新](http://cacm.acm.org/magazines/2010/3/76283-gfs-evolution-on-fast-forward/fulltext)。 他们必须进行许多架构更改，并彻底改革其堆栈，以支持延迟至关重要的面向客户的应用程序（例如 Gmail）。 而且，谷歌将不是唯一必须学习如何处理新实时技术的公司。 - -## 信息来源 - -1. Justin.tv 创始人兼工程副总裁 Kyle Vogt 访谈。 -2. [贾斯汀·坎（Justin Kan）着作加布里埃尔·温伯格（Gabriel Weinberg）的著作](http://www.gabrielweinberg.com/blog/2010/03/justin-kan-on-getting-traction.html) -3. [AWS Kyle Vogt 的启动项目](http://www.slideshare.net/tracylaxdal/justintv-aws-the-startup-project)。 这是 3 年前的 Justin.tv 的体系结构。 -4. [内部实时视频服务 Justin.tv](http://www.building43.com/videos/2010/01/12/inside-live-video-service-justin-tv) 。 Robert Scoble 对 Justin.tv 市场营销副总裁 Evan Solomon 的采访。 - -## 平台 - -1. 两次-自定义 Web 缓存系统。 （http://code.google.com/p/twicecache/） -2. XFS-文件系统。 -3. HAProxy-软件负载平衡。 -4. LVS 堆栈和 ldirectord-高可用性。 -5. Ruby on Rails-应用程序服务器 -6. Nginx-Web 服务器。 -7. PostgreSQL-用于用户和其他元数据的数据库。 -8. MongoDB-用于其内部分析工具。 -9. MemcachedDB-用于处理高写入数据，例如视图计数器。 -10. Syslog-ng-日志记录服务。 -11. RabitMQ-用于作业系统。 -12. 木偶-用于构建服务器。 -13. Git-用于源代码控制。 -14. Wowza-Flash / H.264 视频服务器，以及许多用 Java 编写的定制模块。 -15. Usher-用于播放视频流的自定义业务逻辑服务器。 -16. S3-小图像存储。 - -## 统计资料 - -1. 4 个数据中心遍布全国。 -2. 在任何给定时间，都会有近 2,000 个传入流。 -3. 每天每分钟增加 30 个小时的视频。 -4. 每月有 3000 万独立访问者。 -5. 平均实时带宽约为每秒 45 吉比特。 每日峰值带宽约为 110 Gbps。 最大峰值是 500 Gbps。 -6. 基于商用硬件的大约 200 台视频服务器，每个服务器都可以发送 1Gbps 的视频。 比大多数 CDN 小，但比大多数视频网站大。 -7. 每周可节省约 100TB 的档案存储空间。 -8. 观看者开始失去实时交谈和交互功能之前，完整的视频路径的延迟不得超过 250 毫秒。 - -## 实时视频架构 - -![](img/a01efdd50af991f1296e0a4abee4e706.png) - -1. 为什么直播视频很难？ 似乎您只需要很多带宽，将其全部保留在内存中，将流重新排序，就可以完成了。 简单。 没那么简单。 如果您不能仅通过 YouTube 更快地处理实时视频，是什么使实时视频成为挑战？ - 1. 实时视频不会打 h，这意味着您无法超额订阅带宽。 当 YouTube 从订阅带宽开始时。 他们在 8 个演出管道中有 10 个演出的流量。 那行得通，因为玩家只需要缓冲即可。 使用实时视频，即使您超出网络容量一秒钟，也可以让每个观众同时观看所有视频。 如果您的需求超出容量，它将无法正常工作，每个人都会不断看到缓冲。 拥有网络容量非常重要，他们必须做正确的事情。 因此，他们提出了他们的对等架构。 如果需要，它们还具有比所需可用容量更多的容量。 - 2. 当 CDN 溢出时，它们会优雅地溢出到 CDN。 有时它们确实会用完容量，并且努力地努力使 CDN 溢出。 Usher 处理此逻辑。 一旦容量不足，新的观看者将被发送到 CDN。 - 3. 建筑系统似乎具有 100％的正常运行时间，但能够将机器缓慢地逐步停产以进行维护。 当观众可以迅速注意到任何问题并立即通过聊天与每个人谈论时，这是非常困难的。 使用聊天功能，没有隐藏问题。 用户对服务的期望很高，因此必须妥善处理问题。 他们必须等到每个人都使用完服务器后才能进入维护模式。 旋转速度非常慢。 会话永不中断。 您通常的网站可能会有一些错误，很少有人会注意到。 -2. 当许多人想同时观看同一件事时，他们最大的问题就是控制闪光灯人群。 这是巨大的传入流量。 因此，他们需要创建一种在所有视频服务器和数据中心之间实时调整负载的方法。 该机制就是 Usher。 -3. Usher 是他们创建的自定义软件，用于管理负载均衡，身份验证和其他播放流的业务逻辑。 Usher 会计算要发送每个流的服务器数量，以确保始终保持最佳负载。 这是他们的特殊调味料，也是使他们的系统与众不同的地方。 它基于以下因素实时决定如何将流复制到服务器： - 1. 特定数据中心的负载量。 - 2. 所有服务器的单独负载。 - 3. 延迟优化。 - 4. 流可用的服务器列表。 - 5. 您的 IP 地址，以了解您来自哪个国家。 - 6. 您在其路由数据库中的 IP 地址，以查看他们是否与您的 ISP 对等。 - 7. 请求来自哪个数据中心，他们尝试将您发送到同一数据中心中的视频服务器。 -4. 使用这些指标，Usher 可以优化纯成本，以将您发送到免费的服务器，或者将您发送到最接近要优化其延迟和性能的服务器。 他们有很多拨盘可以转动，并且具有非常精细的控制。 -5. 每个服务器都可以充当边缘服务器（视频在其中流传输到查看器）和原始服务器（视频在其中从广播公司流式传输）。 根据负载，流可能在网络中的一台服务器或每台服务器上可用。 这是一个动态且不断变化的过程。 -6. 服务器之间如何复制流的连接看起来像一棵加权树。 流的数量不断采样。 如果某个流具有很高的新传入查看器速度，则该流将被复制到其他几个服务器。 然后重复该过程，建立树形结构，可能包括网络中的所有服务器。 此过程仅需三秒钟即可执行。 -7. 从命中原始服务器到将其复制到其他服务器以及将其复制到观众时，整个视频流都保留在内存中。 不涉及磁盘路径。 -8. 过去，Flash 尽可能使用 RTMP 协议进行访问。 每个流都有一个独立的会话。 由于该协议，它相当昂贵。 不使用多播或 P2P 技术。 下游 ISP 不支持多播。 他们确实考虑过在内部使用多播在服务器之间复制流，但是由于他们可以控制网络并在内部拥有大量廉价的带宽，因此没有太多好处。 由于它们的算法已经过优化，可以在每台服务器上放置最少数量的流，因此在精细级别上也很难做到。 这比获得的收益要复杂得多。 -9. 通过 HTTP 请求，使用 Usher 来决定使用哪个视频服务器来处理流。 视频服务器相当笨，控制服务拓扑的叠加逻辑由 Usher 管理。 -10. 最初始于 AWS，然后移至 Akamai，然后移至其自己的数据中心。 - 1. 之所以离开 AWS 是因为：1）成本； 2）网络太慢，无法满足他们的需求。 实时视频占用大量带宽，因此拥有快速，可靠，一致，低延迟的网络至关重要。 使用 AWS，您无法控制这些因素。 您的服务器运行在一个共享的网络上，该网络被过度订阅，它们的速度不能超过 300 Mbps。 他们非常喜欢动态扩展和云 API 的功能，但无法解决性能和成本问题。 - 2. 三年前，他们使用以下各种解决方案计算的每位客户成本：CDN $ .135，AWS $ .0074 数据中心$ .0017。 CDN 成本有所下降，但其数据中心成本却大致相同。 -11. 具有多个数据中心的目的不是为了冗余，而应尽可能与所有[主要对等交换](http://en.wikipedia.org/wiki/Peering)（“管理上独立的 Internet 网络的自愿互连，目的是为了在每个客户之间交换流量” 网络”）。 他们选择了该国最好的地理位置，因此可以接触到最多的同行。 - 1. 节约成本。 这意味着它们的大部分流量不会花任何钱，因为它们直接连接到其他网络。 - 2. 性能提升。 它们直接连接到所谓的“眼球”网络。 眼球网络是指网络中有许多有线/ DSL 用户的网络。 与 Justing.tv 主要为最终用户提供流量相比，与“内容”网络（如 CDN，其他网站等）进行对等互连更有意义。 它们距网络仅一跳之遥，这对于性能非常有用。 在大多数情况下，这些安排都是免费的，没有人支付任何钱，您只需挂上电话即可。 -12. 他们有一个骨干网络来获取数据中心之间的视频流。 -13. 查找对等方的选择过程是选择愿意与之对等的人。 很难找到合作伙伴。 -14. 批量购买时，带宽计费非常复杂且不规范。 他们按 90％和 95％的百分比计费，而不是实际使用率。 -15. 虽然没有从磁盘流式传输视频流，但视频已存档到磁盘。 原始服务器是为处理传入流而选择的服务器，它将流记录在本地磁盘上，然后将该记录上载到长期存储中。 - 1. 视频的每一秒都会被记录和存档。 - 2. 存档存储看起来就像 YouTube，只是一堆磁盘。 XFS 用作文件系统。 - 3. 这种体系结构将广播的写入传播到整个服务器。 同时编写数千个流需要大量的工作。 - 4. 默认情况下，流将保留 7 天。 用户可以手动指定可以永久存储的剪辑。 - 5. 视频文件可以轻松地跨磁盘分区。 -16. 他们的操作系统已经过优化，可以应付大量的闪存，因为闪存给系统带来了很大压力。 网络堆栈已调整为每秒处理大量传入连接。 由于它们没有大量的磁盘活动，因此不需要进行其他调整。 -17. 客户端参与负载平衡逻辑，这是他们要求使用自己的播放器的原因之一。 TCP 非常擅长处理几百 kbps 的典型数据速率，因此无需对 TCP 设置进行特殊处理。 -18. 视频服务器的数量似乎很少，因为使用 Usher 可以将每个视频服务器运行到最大容量。 负载平衡确保它们永远不会超出其限制。 负载主要在内存中，因此它们可以以最大容量驱动网络。 -19. 一次从 Rackable 购买整个机架的服务器。 他们只是在所有预接线中滚动它们。 -20. 添加了实时转码功能，可以采用任何格式的流，更改传输层和编解码器，然后以新格式将其流式传输。 有一个代码转换集群可以处理代码转换。 转码会话是通过作业系统安排的，该作业系统在集群中产生转码会话。 如果需求超过其转码服务器场，则它们的所有服务器都可以是转码服务器。 -21. 对于从繁重的协议转向使用 HTTP 流的趋势感到满意，HTTP 流在现有技术的基础上可以很好地扩展。 一个问题是没有重点关注延迟和实时性。 人们忽悠了一下，说它是实时的，如果晚 5 到 30 秒，但是对于成千上万试图实时交谈和互动的人来说，这是不能正常工作的。 延迟不能超过 1/4 秒。 - -## 网络架构 - -![](img/5c831f89d24b37662336b049e84ef886.png) - -1. 高峰请求量是其稳态流量的 10 倍。 他们必须能够处理重大事件。 -2. Ruby on Rails 被用作前端。 -3. 系统中的每个页面都使用其自定义的称为 Twice 的缓存系统进行缓存。 两次充当轻量级反向代理和模板系统的组合。 想法是缓存每个页面，然后使合并每个用户的内容变得容易。 -4. 使用两次，每个进程每秒可以处理 150 个请求，而后端每秒可以处理 10-20 个请求，它们可以服务的网页数量增加了 7 倍至 10 倍。 超过 95％的页面超出了缓存的速度。 -5. 由于所需的处理量很少，因此大多数动态网页浏览均在 5 毫秒内呈现。 -6. Twice 具有插件架构，因此可以支持特定于应用程序的功能，例如： - 1. 添加地理信息。 - 2. 查找两次高速缓存密钥或 MemcacheDB 密钥。 - 3. 自动缓存用户名等数据，而无需触摸应用程序服务器。 -7. 两次量身定制，以适应他们的需求和环境。 如果启动一个新的 Rails 应用程序，一位工程师认为使用 Varnish 可能是一个更好的主意。 -8. Web 流量由一个数据中心提供。 其他数据中心在那里提供视频。 -9. 他们已经添加了对所有内容的监视。 每次点击，页面浏览和操作都会得到衡量，以帮助改善服务。 来自前端，Web 调用或来自应用程序服务器的日志消息将转换为 syslog 消息，并通过 syslog-ng 转发到单个日志主机。 他们扫描数据，将其加载到 MongoDB 中，然后在 MongoDB 上运行查询。 -10. 他们的 API 由与网站相同的应用服务器提供。 它使用相同的缓存引擎，因此可以通过扩展网站来扩展 API。 -11. PostegreSQL 是他们的主要数据库。 具有主控器和一组读取从属器的结构很简单。 -12. 对于他们的网站类型，他们没有太多的写作。 缓存系统处理读取。 -13. 他们发现 PostgreSQL 不能很好地处理大量的少量写入，这确实使它陷入困境。 因此，MemcachedDB 用于处理高写入数据，例如视图计数器。 -14. 他们有一个聊天集群来处理其聊天功能。 如果您转到某个频道，则会被发送到五个不同的聊天服务器。 缩放聊天比缩放视频更容易，因为它是文本并且可以很好地分区。 人们可以分成不同的房间，可以在不同的服务器上使用。 他们也没有与 10 万观看频道的人聊天。 他们所做的是将人员分配到每个 200 人的房间中，以便您可以在较小的组中进行有意义的互动。 这也有助于缩放。 我认为这是一个非常聪明的策略。 -15. AWS 用于存储配置文件图像。 他们没有建立任何可以存储很多小图像的东西，因此使用 S3 更容易。 它非常方便，而且成本也不高，因此没有理由花时间在上面。 如果确实有问题，他们会处理。 它们的图像经常使用，因此非常易于缓存，没有长尾巴问题要处理。 - -## 网络拓扑与设计 - -1. 网络拓扑非常简单且平坦。 每个服务器在机架顶部都有两个 1 gig 卡。 每个机架有多个 10 gig 接口连接到核心路由器。 对于交换机，他们发现了 Dell Power Edge 交换机，它对 L3（TCP / IP）并不是很好，但是对 L2（以太网）则很好。 一整天它将推动每个交换机 20 个演出，而且非常便宜。 核心路由器是 Cisco 6500 系列。 把事情简单化。 他们希望最小化跳数以最小化等待时间，并且还最小化每个数据包的处理量。 Usher 处理所有访问控制和其他逻辑，而不是网络硬件。 -2. 使用多个数据中心来利用对等关系，并能够将流量尽可能移近用户。 -3. 大量的对等和与其他网络的互连。 多个提供程序的供应商，因此他们可以选择最佳路径。 如果他们发现某个网络出现拥塞，则可以选择其他路由。 他们可以查看 IP 地址，查看时间并找出 ISP。 - -## 开发与部署 - -1. Puppet 用于从裸机构建服务器。 他们有大约 20 种不同类型的服务器。 从数据库从站到内存缓存框的任何内容。 有了 Puppet，他们可以将盒子变成想要的东西。 -2. 他们有两个软件团队。 一个是产品团队，另一个是基础架构团队。 团队非常平坦，每个团队大约有七八个人。 每个团队都有一名产品经理。 -3. 他们通常聘请通才，但确实有网络架构和数据库专家。 -4. 使用基于 Web 的部署系统，可以在几分钟之内将任何分支机构推入阶段或生产。 -5. 质量检查必须先签字才能投入生产。 通常需要 5 到 10 分钟。 -6. Git 用于源代码控制。 他们喜欢您可以编写一个分支（20 或 30 行功能），并将其与当前正在生产的其他所有分支合并。 事情是非常独立和模块化的。 您可以轻松地撤回与 Subversion 相适应的某些功能，在该版本中，您必须撤回整个提交，而提交某些非违规代码的任何人都不走运。 -7. 每隔几天，每个人都会尝试合并到 master 分支中，以消除冲突。 -8. 他们发布了许多小功能：每天生产 5 到 15 个部署！ 范围表格 1 行错误修复可用于更大的实验。 -9. 数据库模式升级是手工完成的。 ActiveRecord 迁移的功能强大的版本可在其复制的数据库中工作。 在将变更部署到生产中之前，有许多不同的登台环境在其中进行测试。 -10. 配置文件更改由 Puppet 处理。 -11. 每个功能基本上都是实验。 他们正在跟踪病毒性和对所做的每项重大更改的保留。 这是一个实验，因为他们试图找出哪些更改实际上可以改善他们关注的指标。 - -## 未来 - -他们的目标是增长一个数量级。 为此，他们计划进行以下更改： - -1. 分割他们的视频元数据系统。 元数据负载随流的数量和服务器的数量呈指数增长，因此随着分片的增长，需要扩展以扩展。 正在考虑卡桑德拉。 -2. 分割其 Web 数据库。 -3. 为灾难恢复目的而构建其主数据中心的副本。 - -## 得到教训 - -1. **建立与购买**。 过去，他们在构建自己的产品或购买现成的东西时做出了许多错误的决定。 例如，当他们确实应该购买时，他们首先构建了视频服务器。 软件工程师喜欢构建定制的软件，但是使用开源社区维护的软件有很多好处。 因此，他们提出了一个更好的决策流程： - 1. 这个项目活跃吗？ 保持？ 打补丁？ - 2. 有人在用吗？ 你能问别人如何修改吗？ - 3. 可扩展性很重要。 他们通常需要进行更改。 - 4. 如果我们可以自己构建，可以更快地构建它，获得更好的性能，还是获得我们需要的某些功能？ 这是一个滑坡，因为可以随时使用 feature 参数自行构建它。 现在，与 Usher 一样，他们考虑是否可以在另一个系统的外部和顶部构建功能。 在相对笨拙的视频服务器之上构建 Usher 作为其视频可伸缩性的核心主干，是该策略的一个很好的例子。 -2. **担心您所​​做的事情，而不是别人在做什么**。 他们的目标是拥有最好的系统，最多的运行时间和完善的可伸缩性。 开发该技术以处理数百万个同时广播需要花费 3 年的时间。 -3. **不要外包**。 您学到的东西的价值在于经验。 不在代码或硬件中。 -4. **将所有内容视为实验**。 衡量一切。 拆分测试。 跟踪。 测量。 这很值得。 从头开始。 做好仪器。 例如，他们将＃标签附加到复制的 URL 上，以便告诉您是否共享链接。 他们从没有测量到过度测量的时期。 通过改写广播过程，他们将转换率提高了 700％。 他们希望网站能够快速响应，以使页面加载速度更快，从而更好地提供视频。 从系统中挤出的每毫秒延迟都会带来更多广播公司。 他们希望进行 40 个实验，以使用户成为广播公司。 对于每个实验，他们希望随后查看广播公司的保留率，广播公司的病毒性，转换率，然后做出明智的决定以进行更改。 -5. **最重要的是要了解如何共享您的站点并对其进行优化**。 通过减少共享链接所需的菜单深度，他们能够将共享增加 500％。 -6. **峰的增长速度不及其他峰**快。 提供 10 倍的总视频观看次数，只需要将系统缩放 3 到 4 倍即可。 -7. **使用本地可互换零件**。 使用通用的构建基块和基础结构意味着可以响应动态负载立即重新利用系统。 -8. **确定重要内容并执行**。 网络容量非常重要，从一开始他们就必须做些事情。 -9. **运行系统热**。 利用系统的全部容量。 为什么要把钱放在桌子上？ 构建可以通过适当分配负载来响应负载的系统。 -10. **不要将时间花在无关紧要的**上。 如果它非常方便且成本不高，则没有理由花时间在上面。 对配置文件图像使用 S3 是此策略的一个示例。 -11. **支持用户他们想做的事情，而不是您认为他们应该做的事情**。 Justin.tv 的最终目标似乎是使每个人都成为广播公司。 他们正在尝试通过在用户进行实验时尽可能多地摆脱用户的方式来尽可能简化该过程。 在此过程中，他们发现游戏是一个巨大的用例。 用户喜欢捕获 Xbox 输出并直播并谈论它。 您可能不会想到要纳入业务计划的内容。 -12. **峰值负载**的设计。 如果您只是为稳定状态而设计，那么在出现峰值负载时，您的站点将被压碎。 在现场视频中，这通常是一件大事，如果您搞砸了，很多人都会散布关于您的坏话。 为峰值负载进行设计需要其他技术水平以及在架构上做正确的事情的意愿。 工程问题。 -13. **使网络架构保持简单**。 使用多个数据中心。 使用繁重的对等和网络互连。 -14. **不要害怕将事情分成更多可扩展的块**。 例如，与其在聊天频道上拥有 100,000 个人，不如将他们分成更具社交性和可扩展性的组。 -15. **实时系统无法向用户隐藏任何内容，这可能很难说服用户您的站点可靠**。 用户由于与实时系统保持不断的互动，因此他们会注意到每个问题和每个故障。 你不能躲藏 大家注意。 每个人都可以实时就发生的事情相互交流。 当用户经常遇到问题时，用户很快就会发现您的网站存在问题。 很难说服人们您的站点可靠。 在这种情况下，与用户进行交流变得更加重要。 从头开始建立可靠性，质量，可伸缩性和性能； 并设计尽可能简单且无痛苦的用户体验。 - -## 相关文章 - -1. [YouTube 体系结构](http://highscalability.com/youtube-architecture)。 -2. [热门新趋势：通过廉价的 IP VPN 而非私有线路链接云](http://highscalability.com/blog/2009/6/30/hot-new-trend-linking-clouds-through-cheap-ip-vpns-instead-o.html) -3. [凝视数据中心知识](http://www.datacenterknowledge.com/archives/category/peering/) -4. [Internet 对等知识中心](http://drpeering.net/a/Home.html) -关于对等的非常酷的图表和论文。 -5. [创业时的生活](http://abstractnonsense.com/life-at-a-startup/)，作者 Bill Moorier。 - -托德，很棒的文章。 感谢您的信息。 - -史诗般的帖子。 - -有了对最重要（对我而言）网站之一的惊人见解，您就使这个书呆子感到非常高兴，我很高兴:-)他们提供了出色的服务，其背后的技术令人 jaw 目结舌，但仍然证实了 KISS 的设计 原理。 荣誉！ - -此页面（http://blog.justin.tv/about/）显示了他们的媒体服务器是用 python 编写的，并且他们正在使用 Twisted 聊天服务器。 这仍然准确吗？ - -很棒的帖子！ - -很棒的文章。 谢谢！ - -很棒的文章，谢谢分享。 - -出色的写作。 +# The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购 -我很好奇谁管理他们的“ Usher”系统？ 谁可以转动它支持的所有旋钮？ -知道有关基于 Web 的源部署系统的更多详细信息将很有趣。 它是定制的还是一些现有的产品？ -他们有多少个系统管理员？ -他们使用哪种 Linux（？）发行版？ -nginex 是用作反向代理还是常规的直接 http Web 服务器？ -他们对 flash / h264 / html5 视频标签/ ogg theora 有何想法？ - -哦，还有，他们说他们使用 Amazon S3 托管小型图像，是仅使用 S3 还是 S3 + CloudFront？ - -您提到 Jtv 成功的“数字”大多被夸大了，因为大量的“观看者”从未直接访问该站点，而是通过诸如 ATDHE.net 之类的站点进入。 所有这些所谓的查看器永远不会看到任何 Jtv 广告，也不属于 Jtv 聊天的一部分。 相反，他们是虚假的观众，似乎 Jtv 迫切希望增加其数字... - -谢谢你的好帖子.. +> 原文： [http://highscalability.com/blog/2016/9/13/the-dollar-shave-club-architecture-unilever-bought-for-1-bil.html](http://highscalability.com/blog/2016/9/13/the-dollar-shave-club-architecture-unilever-bought-for-1-bil.html) -这可能是我读过的有关可扩展性的最佳文章。 贾斯汀真的成了流媒体的圣地。 +![](img/5b7af8042fb8d87998d9de26b181d823.png) -有趣的写...有时有点沉重！ 我最基本的观察是广播是关于传输/路由的，而本文在这方面有点过分……似乎主要集中在服务器端的考虑因素和负载平衡上。 当然这些很重要，但是当广播（实时或回放内容）是关键考虑因素时，它们并不是最重要的。 +*这是 [Jason Bosco](https://www.linkedin.com/in/jasonbosco) ， [Dollar Shave Club [ HTG12 的核心平台&基础架构工程总监，介绍其电子商务技术的基础架构。](https://www.dollarshaveclub.com/)* -只有 200 台服务器如何处理如此庞大的客户群和极端的流媒体？ 关于哪种硬件有任何详细信息吗？ 本文只讨论对等和带宽，没有具体介绍 Usher 和如何平衡 200 台服务器上的多个流。 \ No newline at end of file +Dollar Shave Club 拥有 300 万以上的会员，今年的收入将超过 2 亿美元。 尽管大多数人都熟悉该公司的市场营销，但是自成立以来短短几年内的巨大增长主要归功于其 45 名工程师的团队。 + +Dollar Shave Club 工程学的数字： + +## 核心统计信息 + +* 超级碗广告的投放没有停机时间：1 + +* 每月流量带宽：9 TB + +* 通过 Arm 处理的订单：3800 万张订单 + +* 发现的错误总数：4,566 + +* 自动化测试成绩：312,000 + +* 通过语音发送的电子邮件：1.95 亿封电子邮件 + +* 处理并存储在海马中的 Analytics（分析）数据点：5.34 亿 + +* 海马中的数据集大小：1.5TB + +* 当前已部署的应用程序/服务：22 + +* 服务器数量：325 + +## 技术堆栈 + +* 前端框架的 Ember + +* 主要在后端上使用 Ruby on Rails + +* 满足高吞吐量后台处理需求的 Node.js（例如：在语音中） + +* 用于基础结构软件的 Golang + +* 用于基础架构的 Python &数据科学 + +* 用于 1 个内部应用程序的 Elixir + +* 用于测试自动化的 Ruby + +* 适用于本机 iOS 应用程序的 Swift 和 Objective C + +## 基础结构 + +* 完全托管在 AWS 上 + +* Ubuntu & CoreOS + +* 用于配置管理的&地形 + +* 过渡到基于 Docker 的部署 + +* Jenkins 用于部署协调 + +* Nginx &清漆 + +* 快速交付应用程序 + +* 摘要汇总日志 + +* 用于安全监视的 CloudPassage + +* HashiCorp 的保险柜，用于秘密存储&设置 + +## 数据存储 + +* 主要是 MySQL 托管在 RDS 上 + +* 托管在 Elasticache 上的 Memcached 用于缓存 + +* 自托管 Redis 服务器主要用于排队 + +* 有点 Kinesis，用于处理来自尖峰流量的订单 + +* Amazon Redshift 用于数据仓库 + +## 消息传递&排队 + +* Resque 和 Sidekiq 用于异步作业处理&消息传递 + +* 用于消息传递的 RabbitMQ + +* Kafka 用于流处理 + +## 分析&商业智能 + +* 扫雪机&用于网络/移动分析的 Adobe Analytics + +* AWS Elastic MapReduce + +* 将 FlyData 从 MySQL 转换为 ETL 数据到 Redshift + +* 托管 Spark Databricks + +* Looker 作为 BI 前端 + +* 用于报告的近实时数据可用性 + +## 监控 + +* 岗哨哨兵&用于异常跟踪的 Crashlytics + +* 用于自定义应用程序指标的 DataDog &指标聚合 + +* SysDig 用于基础结构度量&监视 + +* 用于应用程序性能监视的 NewRelic + +* Site24x7，用于可用性监视 + +* PagerDuty，用于通话提醒 + +## 质量检查和测试自动化 + +* CircleCI 用于运行单元测试 + +* Jenkins + TestUnit + Selenium + SauceLabs 用于基于浏览器的自动化测试 + +* Jenkins + TestUnit +硒+ SauceLabs 用于大脑自动测试 + +* 用于 API 功能测试的 Jenkins + TestUnit + +* Jenkins + TestUnit + Appium + SauceLabs 用于原生 Android 自动化测试 + +* Jenkins + TestUnit + Appium + SauceLabs 用于本地 iOS 自动化测试 + +* Jenkins + TestUnit + Selenium + SauceLabs +用于 BI 测试自动化的代理服务器 + +* 用于压力，浸泡，负载和性能测试的 SOASTA + Regex 脚本。 + +## 工程工作流程 + +* 跨团队交流的松弛 + +* Trello，用于任务跟踪 + +* 具有自定义插件的 Hubot 作为我们的聊天机器人 + +* Github 作为我们的代码存储库 + +* ReviewNinja 与 Github Status API 集成，用于代码审核 + +* 连续部署-通常每天进行多次部署 + +* 转向持续交付 + +* 用于功能开发的即时沙盒环境 + +* 目前，使用 Jenkins 的单按钮推送部署正在朝着持续交付的方向发展 + +* 运行 docker 容器的游民箱= >为新工程师提供的功能齐全的开发环境，第一天 + +## 架构 + +* 事件驱动的架构 + +* 从单一架构转变为通过公共消息总线进行交互的“中型”服务 + +* CDN 边缘上基于 VCL 的边缘路由，就像其他任何应用程序一样部署。 + +* Web 和移动前端与 API 层进行对话 + +* API 层与服务进行对话，聚合数据并为客户端设置格式 + +* 服务与数据存储和消息总线进行对话 + +* 预定任务作为一项主任务运行，并在 resque / sidekiq 中分解为较小的任务 + +* 技术组件包括用于客户服务（Brain），市场营销自动化平台（Voice），履行系统（Arm），订阅计费系统（Baby Boy）和我们的数据基础结构（Hippocampus）的内部工具。 + +## 小组 + +* 45 位顶尖的企业家和高技能的工程师在加利福尼亚总部玛丽娜·德尔·雷伊工作 + +* 工程师与产品经理，设计师，UX 和利益相关者一起参与称为小分队的跨职能团队，以提供端到端功能。 + +* 团队根据域被垂直划分为前端，后端和质量检查& IT。 + +* 前端团队拥有 DSC.com &内部工具的 Web UI 和我们的 iOS & Android 应用。 + +* 后端团队拥有 DSC.com &内部工具，内部服务（计费和履行），数据平台&基础结构的 Web 后端。 + +* 质量检查团队拥有所有数字产品的测试和自动化基础架构。 + +* IT 团队拥有办公室& Warehouse IT。 + +* 工程师每年参加一次公司赞助的会议。 + +* 工程师可以购买所需数量的书籍/学习资源。 + +* 所有人的站立式办公桌。 目前可提供一张跑步机作为飞行员。 + +* 每周的工程团队午餐。 + +* Tech Belly 每隔一周举行一次活动，工程师们在午餐时间就技术主题进行演讲。 + +* 鼓励工程师尝试最前沿的技术，并通过提案请求（RFC）创建提案。 + +* 鼓励工程师在有意义的地方开源工具和库。 + +* 每位工程师都会获得标准版的 15 英寸 Mac Book Pro，27 英寸 Mac Display 和 24 英寸显示器。 + +* 一台 3D 打印机可用于打印道具和更多 3D 打印机。 + +## 获得的经验教训 + +* 当您要扩展的组件由简单的小型服务组成时，扩展将变得更加容易。 + +* 文档&知识共享对于快速成长的团队至关重要。 + +* 培养良好的测试套件对于快速发展的系统至关重要。 + +* Redis 使用一种近似的 LRU 算法，因此如果您对缓存有明确的 LRU 要求，则不适合使用 + +* 网络性能至关重要，尤其是在移动设备上-每毫秒都会使我们损失收入 + +* 可用性&用户体验对于内部工具也很重要：高效的工具=生产力更高的团队 + +[关于 HackerNews](https://news.ycombinator.com/item?id=12490369) + +您为什么决定自己托管 Redis？ 我假设您将在 ElastiCache 上运行 Redis（使用复制组以提高可用性）。 此外，为什么还要在 Elasticache 上托管 memcached？ + +似乎是一个非常标准的现代堆栈。 很高兴为他们工作！ 真正的问题是，他们向联合利华公司技术堡垒的过渡将是什么样子。 + +我想我的问题是，为什么您需要 45 名工程师才能完成基本上是一个带有订阅选项的小型目录？ + +文档首次出现很重要。 您使用什么基础设施和流程来保持其相关性？ + +为什么这家公司需要运行这么复杂的系统？ 并不是实时地有成千上万个请求的技术公司。 似乎是一种听起来过于酷炫的过度设计的解决方案。 也许他们在做一些我看不到的大而复杂的事情。 所以我很好奇。 \ No newline at end of file diff --git a/docs/203.md b/docs/203.md index 262be8f..c11fea5 100644 --- a/docs/203.md +++ b/docs/203.md @@ -1,77 +1,287 @@ -# FarmVille 如何扩展-后续 +# Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入 -> 原文： [http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html](http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html) +> 原文： [http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) -![](img/4dfef10759448f17402c25ab64e9e4bb.png) +![](img/40038672dfc38e0094e8da51e713355b.png) -针对[，FarmVille 如何扩展以每月收获 7500 万玩家的问题](/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html)，一些读者提出了后续问题。 这是卢克对这些问题（以及我的一些问题）的回答。 +如果您是 Uber，并且需要存储驾驶员和骑乘者应用程序每 30 秒发送一次的位置数据，该怎么办？ 大量实时数据需要实时使用。 -### 社交网络如何使事情变得容易或困难？ +Uber 的解决方案是全面的。 他们构建了自己的系统，该系统在 Mesos 之上运行 Cassandra。 Uber 的软件工程师 [Abhishek Verma](https://www.linkedin.com/in/verma7) 在一个很好的演讲中都做了解释： [Cassandra 在多个数据中心的 Mesos 上 Uber](https://www.youtube.com/watch?v=4Ap-1VT2ChU&feature=youtu.be) （ [幻灯片](http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016) ）。 -社交游戏的主要有趣方面是，如何获得需要经常访问彼此数据的已连接用户的图表。 这使得整个数据集很难甚至不是很难分区。 +您也应该这样做吗？ 在听 Abhishek 的演讲时，会想到一个有趣的想法。 -### 您尝试避免使用 Facebook 通话的哪些例子，以及它们如何影响游戏玩法？ +这些天来，开发人员有很多困难的选择。 我们应该全力以赴吗？ 哪一个？ 太贵了吗？ 我们担心锁定吗？ 还是我们应该尝试同时兼顾并打造混合架构？ 还是我们应该自己做所有事情，以免由于未达到 [50％](http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/) 毛利率而被董事会蒙羞？ -我们可以致电 Facebook 朋友数据，以检索有关您玩游戏的朋友的信息。 通常，我们在游戏底部显示一个朋友梯子，该梯子显示朋友信息，包括姓名和 Facebook 照片。 +Uber 决定建立自己的公司。 或者更确切地说，他们决定将两个功能强大的开源组件融合在一起，从而将自己的系统焊接在一起。 所需要的是一种使 Cassandra 和 Mesos 协同工作的方法，而这正是 Uber 的基础。 -### 您能否说说缓存在哪里，缓存采用什么形式，缓存有多少？ 您是否与 Facebook 建立了对等关系，就像您在该带宽上所期望的那样？ +对于 Uber 的决定并不那么困难。 他们资金充裕，可以访问创建，维护和更新这类复杂系统所需的顶尖人才和资源。 -我们使用内存缓存作为我们的缓存技术。 无法评论对等关系。 +由于 Uber 的目标是使运输在每个地方的每个人都具有 99.99％的可用性，因此在扩展到无限远及更高水平时，希望能够控制您的成本确实很有意义。 -### 禁用功能以响应负载时，对游戏的影响是什么？ +但是，当您听演讲时，您会意识到制作此类系统所付出的巨大努力。 这真的是您的普通商店可以做的事情吗？ 不，不是。 如果您是那些希望每个人都在裸露的金属之上构建自己的所有代码的云专家之一，请记住这一点。 -用户将看到的是应用程序的某些部分无法正常运行。 我们有效地排序了对游戏而言不太重要的事物，并先将其关闭。 例如，在我们的邻居页面和 Flash 应用程序底部的朋友阶梯中，您可以看到朋友在玩游戏及其游戏统计信息的列表。 在某些情况下，当我们有高负载时，我们会关闭它。 它为我们节省了一些后端工作，并且对用户体验的影响相对较小。 +以金钱换时间通常很划算。 通常，以技能交易金钱是绝对必要的。 -### 您如何与 Facebook 集成？ 您是否尝试尽可能远离后端？ 还有与 Facebook 合作的建议？ +鉴于 Uber 的可靠性目标，即 10,000 个请求中只有一个可能失败，因此他们需要在多个数据中心中用完。 由于 Cassandra 被证明可以处理巨大的负载并且可以跨数据中心工作，因此作为数据库选择是有道理的。 -我们通过 REST API 与 Facebook 集成。 由于我们是 Facebook 上的大型应用程序构建者，因此我们就技术问题进行了大量的来回交流。 +如果您想使所有人，任何地方的运输都可靠，则需要有效地利用您的资源。 这就是使用像 Mesos 这样的数据中心操作系统的想法。 通过在同一台计算机上统计复用服务，您需要的计算机数量减少了 30％，从而节省了资金。 之所以选择 Mesos，是因为当时 Mesos 是经证明可与数以万计的计算机集群大小一起工作的唯一产品，这是 Uber 的要求。 优步的工作量很大。 -### 您的可降解方法非常有趣。 听起来您可以在客户端中玩大部分游戏，而无需长时间与后端对话。 我从农场彼此相对隔离的应用程序的性质出发？ 是否有尝试像其他多人游戏一样将农场聚集在一起？ +有哪些更有趣的发现？ -是的，拥有交互式客户端的好处之一是我们在服务器延迟和观察到的客户端延迟之间有些隔离。 我们会验证游戏中执行的每个动作； 但是，我们异步执行此操作，并在客户端上将事务排队。 +* 您可以在容器中运行有状态服务。 Uber 发现在裸机上运行 Cassandra 与在 Mesos 管理的容器中运行 Cassandra 之间几乎没有任何区别，开销为 5-10％。 -### 您使用 MySQL 吗？ 如果使用 SQL，它将如何使用？ +* 性能良好：平均读取延迟：13 毫秒，写入延迟：25 毫秒，P99 看起来不错。 -我们使用 MySql。 +* 对于最大的群集，他们能够支持超过一百万次写入/秒和约 10 万次读取/秒。 -### 您在 LAMP 中使用什么“ P”？ Python 等。 +* 敏捷性比性能更重要。 通过这种架构，Uber 获得的就是敏捷性。 跨集群创建和运行工作负载非常容易。 -Â我们使用 PHP。 +这是我的演讲要点： -### 您如何与后端对话？ 是请求响应，XHR，长轮询，Flash XML 套接字还是“ COMET”？ +## 开头 -我们使用称为 AMF 的标准 HTTP 请求/响应协议。 AMF 事务是从客户端异步发生的，如果服务器看到它认为客户端不应该发送的内容，则会向客户端返回“不同步”消息，告知客户端处于无效状态，并且客户端 重新加载自身。 +* 跨不同服务的静态分区计算机。 -### 您是否运行 200 个（或其他数量的）节点 Vertica 集群？ +* 50 台机器可能专用于 API，50 台机器专用于存储，等等，并且它们没有重叠。 -我们不对 FarmVille 执行此操作 +## 即时 -### 您是在云中运行还是拥有专用服务器？ 您使用 EC2 吗？ +* 希望在 [Mesos](http://mesos.apache.org/) 上运行所有内容，包括诸如 Cassandra 和 Kafka 之类的有状态服务。 -我们确实在云中运行。 这里的主要特征是我们使用商品化的虚拟化硬件。 因此，从我们决定要增加容量到硬件可用的时间，我们大大减少了时间。 + * Mesos 是数据中心操作系统，可让您像单一资源池一样针对数据中心进行编程。 -### 请提供服务降级示例吗？ + * 当时，事实证明 Mesos 可以在成千上万的计算机上运行，​​这是 Uber 的要求之一，因此这就是为什么他们选择 Mesos。 今天，Kubernetes 可能也可以工作。 -FarmVille 内部的一个示例是，页面底部的 Flash 内有一个朋友梯子。 通常，我们向 facebook 查询姓名和个人资料图片，并向我们自己的后端查询游戏统计信息和头像数据。 + * Uber 在 MySQL 之上构建了自己的分片数据库，称为 [Schemaless](https://eng.uber.com/schemaless-part-one/) 。 这个想法是 Cassandra 和 Schemaless 将成为 Uber 中的两个数据存储选项。 现有的 Riak 装置将移至 Cassandra。 -这是应用程序中参与度很高的部分，但优先级低于进行农业活动的用户。 因此，如果我们的后端出现性能问题，我们可以将其关闭，并且朋友阶梯将仅显示 facebook 名称和个人资料图片。 同样，如果 facebook 出现性能问题，我们可以将其关闭，并且朋友梯子不会显示。 +* 一台机器可以运行各种服务。 -结局 +* 同一台机器上的统计复用服务可能会导致 的机器数量减少 30％ 。 这是 Google 在 Borg 上运行的 [实验](http://research.google.com/pubs/pub43438.html) 的发现。 -我错过了昨天 Amitt Mahajan 在 GDC 上的演讲，我很想知道他说过关于懒惰地写入/发自 Farmfield 的内存缓存池及其网络层请求批处理的内容。 有没有人在谈论这个话题或对此有更多了解？ +* 例如，如果一项服务使用大量 CPU，并且与使用大量存储或内存的服务非常匹配，那么这两项服务可以有效地在同一服务器上运行。 机器利用率上升。 -卢克（Luke）在回答云问题时非常有政治性。 根据 Rightscale 上的这篇文章，Farmville 完全在亚马逊的 EC2 上运行：[前三名社交游戏公司管理云上的急剧增长](http://www.rightscale.com/news_events/press_releases/2010/Top-Three-Social-Gaming-Companies-Manage-Steep-Growth-on-the-Cloud-with-RightScale.php) +* Uber 现在有大约 20 个 Cassandra 集群，并计划在将来有 100 个。 -我真的不喜欢采访。 我认为面试官提出了很好的问题，做得很好。 可悲的是，面试官没有付出太多。 +* 敏捷性比性能更重要。 您需要能够管理这些集群并以平滑的方式对其执行不同的操作。 -哇，那真是令人痛苦的采访。 我同意面试官提出了正确的问题，但是答案是可悲的。 +* **为什么在容器中而不是在整个机器上运行 Cassandra？** -“您使用 MySQL 吗？如果您使用 SQL，它将如何使用？” + * 您想存储数百 GB 的数据，但您还希望将其复制到多台计算机上以及跨数据中心。 -“我们使用 MySql。” + * 您还希望跨不同群集进行资源隔离和性能隔离。 -哇，感谢您的惊人见解！！！ + * 很难在一个共享群集中获得所有这些。 例如，如果您制作了一个 1000 节点的 Cassandra 群集，它将无法扩展，或者跨不同群集也会产生性能干扰。 -所有的答案都好像受访者放弃了尽可能少的信息。 +## 量产中 -是的，阅读本访谈内容不多。 一点都没有。 \ No newline at end of file +* 在两个数据中心（西海岸和东海岸）中复制约 20 个群集 + +* 最初有 4 个集群，包括中国，但是由于与滴滴合并，这些集群被关闭了。 + +* 跨两个数据中心的 300 台机器 + +* 最大的 2 个集群：每秒超过 100 万次写入和每秒 10 万次读取 + + * 群集之一正在存储驾驶员和骑乘者应用程序每 30 秒发送一次的位置。 + +* 平均读取延迟：13 毫秒，写入延迟：25 毫秒 + +* 通常使用 [LOCAL_QUORUM](https://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html) 一致性级别（表示强一致性） + +## 月背景资料 + +* Mesos 将 CPU，内存和存储从计算机中分离出来。 + +* 您不是在查看单个计算机，而是在查看资源并对其进行编程。 + +* 线性可伸缩性。 可以在数以万计的计算机上运行。 + +* 高度可用。 Zookeeper 用于在可配置数量的副本中进行领导者选举。 + +* 可以启动 Docker 容器或 Mesos 容器。 + +* 可插拔资源隔离。 用于 Linux 的 Cgroups 内存和 CPU 隔离器。 有一个 Posix 隔离器。 不同的操作系统有不同的隔离机制。 + +* 两级调度程序。 来自 Mesos 代理的资源被提供给不同的框架。 框架在这些提议的基础上安排自己的任务。 + +## Apache Cassandra Backgrounder + +* Cassandra 非常适合 Uber 的用例。 + +* 水平可扩展。 随着新节点的添加，读写规模呈线性增长。 + +* 高度可用。 具有可调一致性级别的容错能力。 + +* 低延迟。 在同一数据中心内获得亚毫秒级的延迟。 + +* 操作简单。 这是同质的簇。 没有主人。 集群中没有特殊的节点。 + +* 足够丰富的数据模型。 它具有列，组合键，计数器，二级索引等 + +* 与开源软件的良好集成。 Hadoop，Spark，Hive 都具有与 Cassandra 进行通信的连接器。 + +## 中层+ Uber + Cassandra = dcos-cassandra-service + +* Uber 与 Mesosphere 合作生产了 [mesosphere / dcos-cassandra-service](https://github.com/mesosphere/dcos-cassandra-service) -一种自动化服务，可轻松在 Mesosphere DC /上进行部署和管理 操作系统。 + +![29683333130_0478a29f4f.jpg](img/838bef48b4379bab5211f9b9f159d7c8.png) + +* 顶部是 Web 界面或 Control Plane API。 您指定所需的节点数； 您想要多少个 CPU； 指定 Cassandra 配置； 然后将其提交给 Control Plane API。 + +* 使用 Uber 的部署系统，它在 [Aurora](http://aurora.apache.org/) 之上启动，用于运行无状态服务，用于引导 dcos-cassandra 服务框架。 + +* 在示例 dcos-cassandra-service 框架中有两个与 Mesos 主服务器通信的集群。 Uber 在其系统中使用了五个 Mesos 母版。 Zookeeper 用于领导者选举。 + +* Zookeeper 还用于存储框架元数据：正在运行的任务，Cassandra 配置，集群的运行状况等。 + +* Mesos 代理在群集中的每台计算机上运行。 代理将资源提供给 Mesos 主服务器，主服务器以离散报价分发它们。 报价可以被框架接受或拒绝。 多个 Cassandra 节点可以在同一台计算机上运行。 + +* 使用 Mesos 容器，而不是 Docker。 + + * 覆盖配置中的 5 个端口（storage_port，ssl_storage_port，native_transport_port，rpcs_port，jmx_port），以便可以在同一台计算机上运行多个容器。 + + * 使用永久卷，因此数据存储在沙箱目录外部。 万一 Cassandra 失败，数据仍将保留在持久卷中，并且如果崩溃并重新启动，则将数据提供给同一任务。 + + * 动态预留用于确保资源可用于重新启动失败的任务。 + +* Cassandra 服务操作 + + * Cassandra 有一个 [种子节点](https://www.quora.com/What-is-a-seed-node-in-Apache-Cassandra) 的想法，它为加入集群的新节点引导八卦过程。 创建了自定义 [种子提供程序](https://mesosphere.github.io/cassandra-mesos/docs/configuration-and-state.html) 来启动 Cassandra 节点，该节点允许 Cassandra 节点自动在 Mesos 群集中推出。 + + * 可以使用 REST 请求增加 Cassandra 群集中的节点数。 它将启动其他节点，为其提供种子节点，并引导其他 Cassandra 守护程序。 + + * 可以更改所有 Cassandra 配置参数。 + + * 使用 API​​可以替换死节点。 + + * 需要修复才能跨副本同步数据。 维修在每个节点的主键范围内进行。 这种方法不会影响性能。 + + * 清除将删除不需要的数据。 如果已添加节点，则数据将被移动到新节点，因此需要清除以删除移动的数据。 + + * 可以通过框架配置多数据中心复制。 + +* 多数据中心支持 + + * 在每个数据中心中独立安装 Mesos。 + + * 在每个数据中心中设置框架的独立实例。 + + * 框架互相交谈并定期交换种子。 + + * 这就是 Cassandra 所需要的。 通过引导其他数据中心的种子，节点可以八卦拓扑并找出节点是什么。 + + * 数据中心之间的往返 ping 延迟为 77.8 ms。 + + * P50 的异步复制延迟：44.69 毫秒； P95：46.38ms; P99：47.44 毫秒； + +* 计划程序执行 + + * 调度程序的执行被抽象为计划，阶段和块。 调度计划具有不同的阶段，一个阶段具有多个块。 + + * 调度程序启动时要经过的第一阶段是协调。 它将发送给 Mesos 并确定已经在运行什么。 + + * 有一个部署阶段，检查集群中是否已存在配置中的节点数，并在必要时进行部署。 + + * 块似乎是 Cassandra 节点规范。 + + * 还有其他阶段：备份，还原，清理和修复，具体取决于所命中的 REST 端点。 + +* 集群可以每分钟一个新节点的速率启动。 + + * 希望每个节点的启动时间达到 30 /秒。 + + * 在 Cassandra 中不能同时启动多个节点。 + + * 通常给每个 Mesos 节点 2TB 的磁盘空间和 128GB 的 RAM。 每个容器分配 100GB，每个 Cassandra 进程分配 32GB 堆。 （注意：目前尚不清楚，因此可能有错误的细节） + + * 使用 G1 垃圾收集器代替 CMS，它具有更好的 99.9％延迟（16x）和性能，无需任何调整。 + +## 裸机 vs Mesos 托管群集 + +* 使用容器的性能开销是多少？ 裸机意味着 Cassandra 不在容器中运行。 + +* 读取延迟。 几乎没有什么区别：5-10％的开销。 + + * 在裸机上平均为 0.38 ms，而在 Mesos 上为.44 ms。 + + * 在 P99 上，裸机为 0.91 毫秒，在 Mesos 上，P99 为 0.98 毫秒。 + +* 读取吞吐量。 差别很小。 + +* 写入延迟。 + + * 在裸机上平均为 0.43 ms，而在 Mesos 上为.48 ms。 + + * 在 P99 上，裸机为 1.05 毫秒，在 Mesos 上，P99 为 1.26 毫秒。 + +* 写入吞吐量。 差别很小。 + +## 相关文章 + +* [关于 HackerNews](https://news.ycombinator.com/item?id=12600298) + +* [使用 Borg 在 Google 进行大规模集群管理](http://research.google.com/pubs/pub43438.html) + +* [Google 的三个时代-批处理，仓库，即时](http://highscalability.com/blog/2011/8/29/the-three-ages-of-google-batch-warehouse-instant.html) + +* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) + +* [Google：驯服长时间延迟的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) + +* [Google 从单一数据中心到故障转移，再到本地多宿主体系结构的过渡](http://highscalability.com/blog/2016/2/23/googles-transition-from-single-datacenter-to-failover-to-a-n.html) + +* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) + +* [Uber 变得与众不同：使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) + +* [为在现代时代构建可扩展的有状态服务提供依据](http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html) + +* [我也想运行有状态容器](https://techcrunch.com/2015/11/21/i-want-to-run-stateful-containers-too/) + +* [Uber 工程技术堆栈，第一部分：基础](https://eng.uber.com/tech-stack-part-one/) + +* [Uber，Twitter，PayPal 和 Hubspot 使用 Apache Mesos 的 4 种独特方式](https://www.linux.com/news/4-unique-ways-uber-twitter-paypal-and-hubspot-use-apache-mesos) + +链接到代码：https://github.com/mesosphere/dcos-cassandra-service + +顺便说一句，在文章中有一个链接。 + +有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。 + +我认为 ELK 不能跟上步伐。 + +@bob。 Uber 确实使用 ELK 进行记录。 它具有最大的 ELK 日志搜索安装之一。 + +我想知道他们是否正在使用 Mesos 卷进行持久数据存储。 + +是的，我们正在使用持久卷（https://mesos.apache.org/documentation/latest/persistent-volume/）进行数据存储。 + +你好 + +您能否阐明查询的性质？ + +聚合或联接或基于纬度的查询？ + +是否想知道 solr 是否可以根据您的用例进行选择？ + +> >有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。 + +如今，许多人用来实现此目的的一种模式是使用 kafka 日志记录库，该库挂接到其微服务中，并使用 spark 等将来自 Kafka 的日志消耗到 elasticsearch 中。 我们在一个很小的〜8 节点 ES 集群上每秒处理数十万个事件。 + +-SRE @ Orchard 平台 + +您能否分享 DC 之间的延迟时间？ + +Uber 使用 DC / OS 很有意思，但选择使用 Aurora 而非马拉松。 我上一次看极光时（大约 18 到 24 个月前），它的发展程度不及马拉松。 我想知道何时做出决定？ Aurora 文档得到了很大的改进。 + +很棒的帖子！ 使用 Mesos 代替 Hadoop YARN 是否有任何特殊原因？ Mesos 是否更适合您的需求？ + +YARN 只能运行 Hadoop 工作负载 Mesos 允许您运行任何类型的工作负载。 + +谢谢您，先生，非常有信息。 +Mesos 是否可以在没有 Docker 容器的情况下运行以安装 Cassandra？ +我们可以使用 Mesos 默认容器安装 cassandra 吗？ + +很棒的翔实文章。 做得好！ + +怎么可能有 100 万次写入但每秒 10 万次读取？ 支持多于读比写有意义吗？ \ No newline at end of file diff --git a/docs/204.md b/docs/204.md index fffcc6b..6d5afe7 100644 --- a/docs/204.md +++ b/docs/204.md @@ -1,223 +1,378 @@ -# MySpace 如何与 100 万个并发用户一起测试其实时站点 +# 从将 Uber 扩展到 2000 名工程师，1000 个服务和 8000 个 Git 存储库获得的经验教训 -> 原文： [http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html](http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html) +> 原文： [http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) -这是 [SOASTA](http://www.soasta.com/) 副总裁 Dan Bartow 的嘉宾帖子，内容是他们如何使用 800 个 EC2 实例与 100 万并发用户共享 MySpace。 我认为这是一个有趣的故事，因为：用户很多，需要花费大量的精力来测试您的实时站点，而并非所有工作都能按预期进行。 我要感谢 Dan 抽出宝贵的时间写和分享这篇文章。 + -![](img/be1ad56cda54486333a6c1aca1ca39cf.png) +为了了解 Uber 的成长情况，请看上述视频的前几秒钟。 它将在正确的位置开始。 它来自[，Uber 首席系统架构师和](https://www.linkedin.com/in/mranney) [Voxer](http://www.voxer.com/) 的共同创始人 Matt Ranney 的精彩演讲：[我希望将 Uber 扩展到 1000 个服务之前想知道的事情](https://www.youtube.com/watch?v=kb-m2fasdDY)（[[幻灯片](https://gotocon.com/chicago-2016/presentation/What%20I%20Wish%20I%20Had%20Known%20Before%20Scaling%20Uber%20to%201000%20Services)）。 -在 MySpace 音乐先前取得成功的基础上，MySpace 在 2009 年 12 月在新西兰掀起了新的流音乐视频产品浪潮。 这些新功能包括观看音乐视频，搜索艺术家的视频，创建收藏夹列表等等的功能。 在 MySpace 等热门网站上，此类功能的预期负载增加是巨大的，他们希望在启用这些功能之前先进行测试。 +它显示了中国一些城市不断增长的，有节奏的，波动的交通网络。 世界各地的城市都在发生这种爆炸性增长的方式。 实际上，Uber 现在已遍布 400 个城市和 70 个国家/地区。 他们有 6000 多名员工，其中 2000 名是工程师。 仅仅一年半的时间，只有 200 名工程师。 这些工程师已经产生了 1000 多种微服务，这些微服务存储在 8000 多个 git 存储库中。 -如果您管理高流量应用程序背后的基础架构，则不会感到意外。 您想了解自己的断裂点，定义容量阈值，并知道在超过这些阈值时如何应对。 用实际的预期负载水平测试生产基础架构是了解高峰流量到达时事物将如何运行的唯一方法。 +在短时间内疯狂增长 10 倍。 谁经历过？ 不太多。 就像您可能期望的那样，这种独特的，压缩的，快节奏的，高风险的经验必须教会您一些新知识，比以前理解的要深刻。 -对于 MySpace，目标是在其实时站点上测试另外的 100 万并发用户，以强调新的视频功能。 这里的关键词是“并发”。 不到一个小时或一天的时间……网站上同时有 100 万用户同时活动。 应当指出，一百万个虚拟用户只是 MySpace 在高峰期通常在站点上拥有的虚拟用户的一部分。 他们想用测试流量来补充实时流量，以了解新产品对整个基础架构的总体性能影响。 这需要大量的负载生成功能，而这正是云计算发挥作用的地方。 为了进行此测试，MySpace 与 SOASTA 一起使用了云作为负载生成平台。 +马特不是这个游戏的新手。 他是 Voxer 的共同创始人，Voxer 经历了[的快速增长](http://www.marketwired.com/press-release/walkie-talkie-app-voxer-soars-past-billion-operations-per-day-powered-basho-riak-1603652.htm)，但这是不同的。 您可以在观看视频时告诉您 Matt 试图对他们所取得的成就表示满意。 -以下是测试过程中生成的负载的详细信息。 所有数字均与虚拟用户的测试流量有关，不包括实时用户的指标： +马特是一个有思想的人，这是有根据的。 在[最近的一次采访](https://www.infoq.com/articles/podcast-matt-ranney)中，他说： -* 100 万个并发虚拟用户 -* 测试用例分为搜索和观看音乐视频，对视频进行评级，将视频添加到收藏夹以及查看艺术家的频道页面。 -* 每秒 16 吉比特的传输速率 -* 每小时传输 6 TB 的数据 -* 每秒点击次数超过 77,000，不包括实时流量 -* 800 个用于生成负载的 Amazon EC2 大型实例（3200 个云计算核心） +> 在 QCon 和其他活动上进行的许多架构讨论使我感到不足够。 和其他人（例如 Google）一样，一切都明白了，但我却没有。 -**测试环境体系结构** +马特（Matt）这次演讲是在大漩涡之外走了一下，试图使自己的经历有意义，并试图弄清一切。 他成功了。 疯狂地。 -SOASTA CloudTest™管理对云提供商（在本例中为 Amazon）的调出，并配置服务器以进行测试。 捕获 800 个 EC2 实例的过程用了不到 20 分钟的时间。 我们对 Amazon EC2 API 进行了调用，并以 25 个为一组请求服务器。在这种情况下，团队正在请求具有以下规范的 EC2 Large 实例充当负载生成器和结果收集器： +这部分是智慧的谈话，部分是悔。 马特说：“一路上犯了很多错误，而这些正是从中汲取教训的。 -* 7.5 GB 内存 -* 4 个 EC2 计算单元（2 个虚拟 CPU 内核，每个虚拟 CPU 内核具有 2 个 EC2 计算单元） -* 850 GB 实例存储（2×420 GB 加上 10 GB 根分区） -* 64 位平台 -* Fedora Core 8 -* 另外，有 2 个 EC2 Extra-Large 实例充当测试控制器实例和结果数据库，其规格如下： -* 15 GB 内存 -* 8 个 EC2 计算单元（4 个虚拟内核，每个虚拟内核具有 2 个 EC2 计算单元） -* 1,690 GB 实例存储（4×420 GB 加上 10 GB 根分区） -* 64 位平台 -* Fedora Core 8 -* PostgreSQL 数据库 +演讲的脚手架挂在 WIWIK（我希望我知道的）设备上，该设备已成为互联网的模因。 这是他建议给自己幼稚的一年半的幼稚自我的建议，尽管当然，像我们所有人一样，他当然不会听。 -一旦拥有测试所需的所有服务器，便开始对它们进行运行状况检查，以确保它们响应并稳定。 当发现死服务器时，它将丢弃它们，并请求其他服务器来填补空白。 设置基础结构相对容易。 下图（图 1）显示了如何在 EC2 上设置测试云以将大量负载推入 MySpace 的数据中心。 +而且他不会孤单。 很多人批评 Uber（ [HackerNews](https://news.ycombinator.com/item?id=12597232) ， [Reddit](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) ）。 毕竟，这些数字实在是太疯狂了。 两千名工程师？ 八千个存储库？ 一千个服务？ 一定是很严重的错误，不是吗？ -![](img/fe16afcae89633adcf761fa1288f9780.png) +也许。 令人惊讶的是，马特对整个事情没有判断力。 他的询问方式更多是质疑和搜索，而不是寻找绝对值。 他本人似乎对存储库的数量感到困惑，但是他给出了更多存储库与更少存储库的优缺点，而没有说哪个更好，因为考虑到 Uber 的情况：您如何定义更好？ -**图 1\.** +优步正在全球范围内展开激烈的战斗，以构建一个能够占领赢家通吃的市场的行星尺度系统。 那就是商业模式。 成为最后一个服务站。 在这种情况下，更好的意思是什么？ -测试运行时，成批的负载生成器将其性能测试指标报告回单个分析服务。 每个分析服务都连接 +赢家通吃意味着您必须快速成长。 您可能会变慢并显得更有条理，但如果变慢，就会迷失方向。 因此，您可以在混乱的边缘保持平衡，并将脚趾或整个身体浸入混乱中，因为这将成为您扩展成为全球主导服务的方式。 这不是一条缓慢的增长之路。 这敲门，采取一切策略。 认为您可以做得更好？ 真？ -到 PostgreSQL 数据库，以将性能数据存储在聚合存储库中。 这是这种规模的测试可以扩展以生成和存储大量数据的方式的一部分-通过将对数据库的访问限制为仅度量指标聚合器并水平扩展。 +微服务非常适合 Uber 想要实现的目标。 塞住你的耳朵，但这是康威定律的事情，你会获得如此多的服务，因为这是那么多人被雇用并提高生产力的唯一途径。 -**挑战** +如此多的服务没有技术原因。 没有这么多存储库的技术原因。 这一切都是关于人的。 [老婆婆](https://news.ycombinator.com/item?id=12598893)很好地总结了一下： -由于规模往往会破坏一切，因此在整个测试过程中会遇到许多挑战。 +> 扩展流量不是问题。 扩大团队规模和产品功能发布率是主要因素。 -**该测试仅限于使用 800 个 EC2 实例** +演讲的一个一致主题是*不错，但存在一些权衡取舍，通常是令人惊讶的权衡，您实际上只是在规模上才能体验到*。 这引出了我从演讲中获得的两个最大想法： -SOASTA 是云计算资源的最大消费者之一，通常在多个云提供商之间一次使用数百台服务器来进行这些大规模负载测试。 在测试时，团队要求提供的 EC2 实例数量上限。 可用硬件的限制意味着每个服务器都需要模拟相对大量的用户。 每个负载生成器模拟了 1,300 至 1,500 个用户。 此负载水平约为典型 CloudTest™负载生成器将驱动的负载的 3 倍，这给产品带来了新的压力，工程团队需要一些创造性的工作来解决。 用于减轻负载生成器压力的一些策略包括： +* **微服务是一种用 API 协调**代替人类交流的方式。 与人们谈论和处理团队政治相比，团队更容易编写新代码。 它使我想起了我很久以前读过的一本书，不记得这个名字了，人们居住在戴森球体内部，并且因为球体内部有太多空间和如此多的自由能，以至于当任何一个团体与另一个团体发生冲突时 他们可能会分裂并适应新的领域。 这是否更好？ 我不知道，但这确实可以并行完成许多工作，同时又避免了很多人的开销。 +* **纯胡萝卜，不粘**。 关于命令和控制的作用如此广泛，这是一个很深的观点。 您会很想执行政策。 *例如，您应该以这种方式记录*。 如果您不这样做，将会有后果。 那是棍子。 马特说不要那样做。 改用胡萝卜。 每当棍棒冒出来都是不好的。 因此没有任何授权。 您想要处理它的方式是提供非常明显且易于使用的工具，以至于人们不会以其他任何方式使用它。 -* 错开了每个虚拟用户的请求，以免每个负载生成器的点击都一次触发 -* 缩减收集的数据，仅包括性能分析所需的内容 +这是您必须真正了解的那些谈话之一，因为除了文本以外，还有很多其他方面的交流。 虽然当然我仍然鼓励您阅读我的演讲掩饰:-) -## **MySpace 资产的很大一部分由 Akamai 提供，并且该测试反复使 Akamai 基础架构** 的部分服务能力最大化。 +## 统计信息（2016 年 4 月） -CDN 通常会根据访问者的地理位置从最接近访问者的位置向他们提供内容。 例如，如果您从亚马逊的东海岸可用区生成所有测试流量，那么您很可能只会遇到一个 Akamai 服务点。 +* 优步遍布全球 400 个城市。 -在负载下，该测试正在向少量 Akamai 数据中心生成大量数据传输和连接流量。 这意味着这些数据中心的负载将超过典型高峰期间可能产生的负载，但是鉴于此功能启动仅针对新西兰流量，因此这不一定是不现实的。 这种压力导致新连接在某些负载水平下被 Akamai 破坏或拒绝，并在测试中产生许多错误。 +* 70 个国家。 -这是在生产现场产生负载时需要克服的常见障碍。 需要设计大规模生产测试，以考虑到这一点并准确地对整个生产生态系统施加压力。 这意味着从多个地理位置生成负载，以便将流量分散到多个数据中心。 最终，了解地理 POPs 的能力是该测试的重要收获。 +* 6000 多名员工 -## **由于额外负载的影响，MySpace 必须即时调整其某些服务器的位置，以支持正在测试的功能** +* 2000 名工程师（一年半前有 200 名工程师） -在测试过程中，额外的虚拟用户流量使 MySpace 基础架构中的一些负担沉重。 MySpace 的运营团队能够在几分钟内从其他功能集群中获取未充分利用的服务器，并使用它们为视频站点集群增加容量。 +* 1000 个服务（数量近似） -也许最令人惊奇的是 MySpace 能够做到这一点。 他们能够实时监控整个基础架构的容量，并在需要时灵活地收缩和扩展。 人们一直在谈论弹性可伸缩性，这在实践中是一件很美的事情。 + * 不同服务的数量变化如此之快，以至于很难准确计算生产中的实际服务数量。 许多团队正在建立很多东西。 甚至都不在乎实际的数字。 -**经验教训** +* 超过 8000 个 git 回购。 -1. 对于高流量网站，在生产中进行测试是准确了解容量和性能的唯一方法。 对于大型应用程序基础结构，如果您仅在实验室中进行测试然后尝试进行推断，那么就会出现太多“看不见的墙”。 -2. 弹性可伸缩性正成为应用程序体系结构中越来越重要的部分。 应该构建应用程序，以便可以独立监视和扩展关键业务流程。 能够相对快速地增加容量将成为来年的关键体系结构主题，而大型企业早就知道了这一点。 Facebook，Ebay，Intuit 和许多其他大型网站都宣扬了这种设计原则。 使事物保持松散耦合具有以前宣传过的许多好处，但是容量和性能正在迅速移到该列表的前面。 -3. 实时监控至关重要。 为了对容量或性能问题做出反应，您需要进行实时监控。 此监视应与您的关键业务流程和功能区域相关联，并且需要尽可能实时。 +## 微服务 -## 相关文章 +* 很高兴将您所有的整体分解成更小的东西。 甚至这个名字听起来也很糟糕。 但是微服务有其不利的一面。 -* [MySpace 体系结构](/blog/2009/2/12/myspace-architecture.html) -* [如何在不进行实际尝试的情况下成功完成容量规划：Flickr 的 John Allspaw 专访他的新书](/blog/2009/6/29/how-to-succeed-at-capacity-planning-without-really-trying-an.html) +* 事情最有可能破裂的时间就是您进行更改的时间。 即使是在 Uber 最忙的时候，周末 Uber 在工程师不进行更改的情况下也是最可靠的。 -另一篇令人失望的简短文章：/ -这篇文章对于学习和观察真实的云一样有用。 -这本来真是令人赞叹的文章，但事实证明，更多的是 soasta 广告：( +* 每当您进行更改时，都有可能破坏它。 永远不要接触微服务是否有意义？ 也许。 -嗯 我也希望有更多细节。 里面没有什么新东西，只是一则广告。 +* 好 -您想要保罗什么细节？ + * 值得质疑，为什么我们要在微服务上投入如此多的精力？ 这不是偶然的，有很多好的结果。 -我想知道这项测试的亚马逊账单是多少？ + * 微服务允许团队快速组建并独立运行。 人们一直在被添加。 团队需要迅速组建起来，并在可以推断边界的地方开展工作。 -虽然可能有点像广告，但我不认为这太过分了。 SOASTA 仅被特别提及了三遍，考虑到它们都执行了测试并撰写了有关测试的文章，这似乎是合理的。 + * 拥有自己的正常运行时间。 您运行您编写的代码。 所有服务团队都在征求他们在生产中运行的服务。 -总体而言，我认为这是一篇相当不错的文章，并为我提供了许多以前所没有的见识。 也许是因为我没有参与需要进行云部署测试的大型站点。 如果是的话，我可能会有所不同。 + * 使用最佳工具进行作业。 但是最好的方式是什么？ 最好写？ 最好跑？ 最好，因为我知道吗？ 最好，因为有图书馆？ 当您深入研究时，最好并不意味着什么。 -根据读者的不同，一篇文章几乎总是细节太少或太多，我认为这篇文章取得了很好的平衡。 +* 明显的成本 -感谢您的撰写。 + * 运行大型微服务部署的成本是多少？ -这听起来像是广告，它实际上是一项糟糕的服务。 -强调 Akamai 在美国的基础设施将如何帮助应对来自新西兰的流量猛增？ 这些新西兰人最终将身处 Akamai 的新西兰基础设施中。 + * 现在，您正在运行分布式系统，这比使用整体系统更难。 -另外，如果要在 MySpace 上对后端进行负载测试，而不是 Akamai 提供内容，则根本不需要测试 Akamai 部分。 只需在 MySpace 网络中内部运行测试即可。 + * 一切都是 RPC。 您必须处理所有这些疯狂的失败模式。 -最后，哪种产品需要 16 GB 的 RAM 才能同时下载一些 http 请求？ 你在开玩笑吧。 Java 用什么写的？ + * 如果中断怎么办？ 您如何排除故障？ 您如何确定中断在服务链中的何处发生？ 如何确保合适的人得到传呼？ 采取了正确的纠正措施来解决问题？ -这篇文章让人印象深刻。 鉴于单核奔腾 M 笔记本电脑可以轻松使千兆位以太网连接（尤其是传入）饱和，因此没有理由使用 16 台以上的服务器。 从亚马逊那里购买它们特别愚蠢，因为与新西兰的 DSL 客户相比，它们往往连接良好。 如果启动该服务确实产生了如此大的影响，那么您将受到新西兰微薄的互联网连接的自然限制，并且必须与所有其他新西兰人共享。 + * 这些仍然是显而易见的成本。 -关于先前的投诉，我认为您至少让读者停滞了一点： +* 不太明显的费用 -（1）对于仅命中一个 Akamai 数据中心的问题有什么解决方案？ 您是否能够克服该瓶颈并测试其他潜在瓶颈？ + * 一切都是权衡，即使您没有意识到自己正在做到。 作为所有这些微服务的交换，您可以获得某些东西，但是您也放弃了一些东西。 -我也想知道： + * 通过对所有事物进行超级模块化，我们引入了一些细微而又不明显的问题。 -（2）是否遇到任何挑战 + * 您可能选择构建新服务，而不是修复已损坏的内容。 在某些时候，始终围绕问题解决和清理旧问题的成本已成为一个因素。 --传输速率为每秒 16 吉比特 --每小时传输 6 TB 数据 + * **您发现自己为政治**交易很复杂。 您不必编写笨拙的对话，而充满人类的情感，而是可以编写更多的软件而避免说话。 -进入 Amazon AWS？ 还是仅仅是产生足够多的实例来获得这种传输速率？ + * **您可以保持自己的偏见**。 如果您喜欢 Python 以及与您喜欢的节点打交道的团队，则可以使用自己喜欢的语言来构建新的东西，而不必使用其他代码库。 即使对于组织或整个系统而言，这可能并不是最好的事情，但您仍要继续做自己认为最好的事情。 -您能否说明一下为什么选择 PostgreSQL 来存储日志数据？ +## 拥有多种语言的成本 -我很确定某些键值存储系统会比常规 SQL 系统更快地占用资源，同时存储日志数据。 +* 史前史：最初，Uber 被 100％外包。 看来这似乎不是技术问题，所以一些公司编写了移动应用程序的第一个版本和后端。 -尽管它没有描述所有细节，但了解/听到使用 EC2 进行这种负载测试的方法仍然非常有趣。 +* 调度：内部开发时，它是用 Node.js 编写的，现在正在迁移到 Go。 -谢谢 +* 核心服务：系统的其余部分，最初是用 Python 编写的，现在正在迁移到 Go。 + +* Maps 最终被引入内部，这些团队正在使用 Python 和 Java。 + +* 数据工程团队使用 Python 和 Java 编写代码。 + +* 内部度量系统用 Go 编写。 + +* 您开始注意到有很多语言。 微服务使您可以使用多种语言。 + +* 团队可以用不同的语言编写并且仍然可以相互交流。 它可以工作，但需要付费： + + * 难以共享代码。 + + * 难以在团队之间移动。 在一个平台上积累的知识不会转移到另一平台上。 任何人当然都能学到，但是要付出一定的代价。 + +* **我希望知道的内容**：拥有多种语言会破坏文化。 通过在任何地方都接受微服务，您最终可以扎营。 这里有一个节点营，一个 Go 营，等等。人们围绕部落组织起来是很自然的事，但是要接受到处都有多种语言的策略是有代价的。 + +## RPC 的成本 + +* 团队使用 RPC 相互通信。 + +* 大量的人很快就真正加入了 HTTP 的弱点。 像什么状态代码？ 标头是做什么用的？ 查询字符串中包含什么？ 这是 RESTful 吗？ 这是什么方法 + +* 所有这些事情在执行浏览器编程时看上去确实很酷，但是在进行服务器编程时却变得非常复杂。 + +* 您真正想说的是在那里运行此功能，并告诉我发生了什么。 相反，使用 HTTP / REST 会遇到所有这些细微的解释问题，这一切都非常昂贵。 + +* JSON 很棒，您可以用眼球看一下并阅读它，但是如果没有类型，这是一个疯狂的混乱，但不是马上，问题随后就会出现。 当某人更改某些内容并在下游跳了几步时，他们依赖于对空字符串与 null 的某种微妙解释，或者某种语言对另一种语言的某种类型的强制转换，这会导致巨大的混乱，需要花费很长的时间才能解决。 接口上的类型将解决所有这些问题。 + +* RPC 比过程调用慢。 + +* **我希望知道的内容**：服务器不是浏览器。 + + * 当在数据中心中进行交谈时，将所有内容都视为函数调用而不是 Web 请求，这更加有意义。 当您控制对话的双方时，您并不需要所有多余的浏览器内容。 + +## 储存库 + +* 最好的回购数量是多少？ 他认为最好的是一个，但许多人不同意。 + +* 许多人认为很多回购是最好的。 每个项目可能一个，甚至每个项目多个。 + +* 具有许多存储库是遵循具有许多小型模块的行业趋势。 小型模块易于开源或交换。 + +* 一个仓库很不错，因为您可以进行跨领域更改。 您想要进行更改，可以轻松找到所有需要更改的代码。 浏览代码也很容易。 + +* 有很多不好的地方，因为这会给您的构建系统带来压力。 这会损害您浏览代码的能力。 确保正确完成跨领域更改很痛苦。 + +* 一个不好的原因是，它将变得如此之大，除非您拥有一些疯狂的精心设计的系统，否则您将无法构建或检验您的软件。 如果没有特殊工具，一个仓库可能无法使用。 Google 有一个存储库，但它使用虚拟文件系统，好像您已检出整个存储库。 + +* 超过 8000 个 git 回购。 一个月前有 7000。 + + * 有些人有自己的仓库。 + + * 一些团队使用单独的存储库与服务本身分开跟踪服务配置。 + + * 但是大多数是生产仓库。 + +* 很多回购。 + +## 操作问题 + +* 事情破裂了怎么办？ 大型微服务部署会带来一些令人惊讶的问题。 + +* 如果其他团队无法使用您的服务，而该服务尚未准备好发布，那么其他团队是否可以在您的服务中添加修复程序并将其发布？ + + * 即使您的所有测试都通过了，您拥有的正常运行时间是否也与其他发布您服务的团队兼容？ 自动化是否足够好，团队可以相互发布软件？ + + * 在 Uber，这取决于情况。 有时是的，但通常答案是“否”，团队将只需要阻止此修复程序。 + +* 大而小的团队，每个人都在快速前进，所有功能都超级快地发布，但是有时您必须将整个系统理解为一台大型机器连接在一起的一件事。 当您花费所有时间将其分解为微服务时，这很难。 + + * 这是一个棘手的问题。 希望将更多的时间花在保持上下文关联上。 + + * 应该仍然能够理解整个系统的整体功能。 + +## 性能问题 + +* 鉴于微服务彼此之间的依赖程度，性能肯定会提高。 + +* RPC 昂贵，尤其是当存在多种语言时，如何理解性能的答案完全取决于语言工具，并且工具都是不同的。 + +* 您已经让每个人都使用自己的语言进行编程，现在了解这些语言的性能是一个真正的挑战。 + +* 尝试使用 [火焰图](http://www.brendangregg.com/flamegraphs.html) 使所有语言具有通用的分析格式。 + +* 当您想了解系统的性能时，在试图解决性能问题时，一个很大的摩擦就是工具的差异。 + +* 每个人都想要一个仪表盘，但是如果没有自动生成仪表盘，团队将只把他们认为重要的东西放在仪表盘上，因此当您要追查一个团队的仪表盘时，问题看上去将与另一个团队完全不同。 + +* 每个服务在创建时都应该具有一个标准的仪表板，其中包含相同的有用数据集。 应该能够创建一个完全没有工作的仪表板。 然后，您可以浏览其他团队的服务，并且看起来都一样。 + +* **我希望知道的内容**：不需要良好的表现，但您需要知道自己的立场。 + + * 一个大争论是，您是否应该关心性能。 “过早的优化是万恶之源”的类型思维催生了反对优化的人们非常奇怪的亚文化。 没关系，服务并不那么忙。 我们应该始终针对显影剂速度进行优化。 购买计算机比雇用工程师便宜。 + + * 对此有一定道理。 工程师非常昂贵。 + + * 问题在于，性能要紧要紧。 有一天，您将遇到绩效问题，如果已经建立起一种无关紧要的文化，那么突然之间变得至关重要很困难。 -费利克斯（Felix），即使您的行为像孩子一样在 YouTube 上匿名发动，我还是决定，我会尽力为您解答问题。 他们来了： + * 您希望根据创建的所有内容获得某种性能的 SLA，以便有一个数字。 ->强调 Akamai 在美国的基础设施将如何帮助应对来自新西兰的流量猛增？ 这些新西兰人最终将身处 Akamai 的新西兰基础设施中。 +## 扇出问题-跟踪 -来自 Akamai 的内容只是正在测试的整个基础架构的一部分。 这是在测试设计期间提出的，并被团队接受，因为： +* 扇出会导致很多性能问题。 -1）没有其他选择-尚无主要的云播放器在新西兰（但是）拥有与某些较大的播放器一样强大的 API，并且具有一定数量的服务器 -2）大多数 Akamai 的存在都相对 在性能方面具有可重复性，因此，由于我们主要测试的不是 Akamai，因此我们假定来自新西兰其他数据中心的性能也与众不同，因为每个人都愿意接受这种风险。 +* 想象一个典型的服务，即 99％的时间在 1 毫秒内做出响应。 它在一秒钟内响应的时间为 1％。 还算不错。 用户有 1％的时间会遇到这种情况。 -有了 SLA，并且对数据中心进行的压力测试比预期的要高得多，这在逻辑上是可以接受的风险。 +* 现在，我们假设服务开始大张旗鼓，开始调用许多其他服务。 响应时间变慢的机会迅速增加。 至少在 1 秒钟内使用 100 个服务和 63％的响应时间（1.0-.99 ^ 100 = 63.4％）。 -> ->如果要在 MySpace 上对后端进行负载测试，而不是 Akamai 提供的内容，则根本不需要测试 Akamai 部分。 只需在 MySpace 网络中内部运行测试即可。 +* 分发跟踪是您跟踪扇出问题的方式。 如果无法理解整个体系结构中的请求，将很难跟踪扇出问题。 -如果您希望基础架构的所有部分都能承受预计的负载的 100％的信心，则每个组件都需要进行测试。 我们经常根据客户的要求测试 CDN。 在这种情况下，没有人想到 CDN 会遇到麻烦，但我们遇到了很多麻烦。 即使我们可能一直在强调一种持久性有机污染物，其强度比预期的要高，但我们观察到一个以前没有人知道的能力点。 + * Uber 正在使用 [OpenTracing](https://github.com/opentracing) 和 [Zipkin](https://github.com/openzipkin/zipkin) 。 -要记住的一件事是，它不仅仅是从容量角度测试 Akamai。 当本应由 Akamai 提供服务但没有提供服务时，会发生不好的事情，最终回到原始服务器并破坏 MySpace 基础结构。 团队需要首先确保内容全部来自 Akamai。 其次，我们需要确保在 Akamai 缓存刷新等过程中没有负载传递到 MySpace。 + * 另一种方法是使用日志。 每个日志条目都有一个公共 ID，该 ID 将所有服务组合在一起。 -同样，在内部运行测试不能像在防火墙外部进行测试那样准确地提供性能信息。 +* 给出了一个棘手的例子。 顶层对所有相同服务均具有大量扇出。 当您查看服务时，它看起来不错。 每个请求都是快速且一致的。 问题是顶级服务获得了 ID 列表，并正在为每个 ID 调用服务。 即使同时进行，也将花费太长时间。 只需使用批处理命令即可。 如果不进行跟踪，很难找到这个问题。 -> ->哪种产品需要 16 gigs RAM 才能同时下载一些 http 请求？ 你在开玩笑吧。 Java 用什么写的？ +* 另一个示例是进行了数千次服务调用的服务。 尽管每个呼叫都很快，但大量呼叫却使服务变慢。 事实证明，遍历列表并更改属性后，它神奇地变成了数据库请求。 但是数据库团队说，由于每个操作都很快，所以数据库运行良好，但是他们会想知道为什么会有这么多操作。 -不值得花时间回答这个问题。 如果听起来读者理解这里发生的一切，就很乐意做出回应；） +* 跟踪的开销可以更改结果。 跟踪是很多工作。 一种选择是不跟踪所有请求。 跟踪请求的统计显着部分。 Uber 跟踪约 1％的请求。 -> ->本文颇为令人印象深刻。 鉴于单核奔腾 M 笔记本电脑可以轻松使千兆位以太网连接（尤其是传入）饱和，因此没有理由使用 16 台以上的服务器。 从亚马逊那里购买它们特别愚蠢，因为与新西兰的 DSL 客户相比，它们往往连接良好。 如果启动该服务确实产生了如此大的影响，那么您将受到新西兰微薄的互联网连接的自然限制，并且必须与所有其他新西兰人共享。 +* **我希望知道的内容**：跟踪需要跨语言的上下文传播。 -在线应用程序的性能测试远不止于饱和。 在下载或流式传输内容时，实际上保持打开状态的打开线程和套接字是您逐个服务器消耗所有容量的地方。 下载内容需要时间，并且在下载或流式传输内容时，您失去了生成负载的能力。 + * 因为所有这些不同的语言都用于所有这些不同的框架，所以获取请求的上下文（例如请求的用户）是经过身份验证的，是在什么地理围栏内，如果没有放置位置，这将变得非常复杂 将会传播的上下文。 -除此之外，对于性能测试，您还不会发出请求以生成负载并将其释放。 您正在记录有关每个用户的大量性能数据。 每次命中所花费的时间，传输的带宽，错误以及类似性质的事情。 + * 服务提出的任何依赖请求都必须传播上下文，即使他们可能不理解上下文也是如此。 如果很久以前添加此功能，它将节省大量时间。 -在 DSL 点上，带宽限制很少在性能测试中完成，因为如果最终用户连接不受应用程序公司的控制，则不会进行限制。 +## 正在记录 -> ->（1）仅命中一个 Akamai 数据中心的问题的解决方案是什么？ 您是否能够克服该瓶颈并测试其他潜在瓶颈？ -> +* 拥有一堆不同的语言，一群团队和许多新人，一半的工程团队已经存在了不到 6 个月，每个人可能都倾向于以完全不同的方式登录。 -我们接受了这样的风险，即我们实际上要测试一个 Akamai 的存在点，其强度要高于此次发布的程度。 但是，识别瓶颈是一项关键的学习，并且随着流量的增长，运营团队和他们的头脑现在已经知道了解其阈值，这可能是需要逐步解决的问题。 +* 任务授权是一个棘手的词，但这就是您真正想要做的事情，它要求一种通用的日志记录方法。 更为可接受的说法是，它提供了如此显而易见且易于使用的工具，人们不会以任何其他方式来获得一致且结构化的日志记录。 ->我也想知道： -> ->（2）在获得 -> ->方面是否存在任何挑战-每 16 吉比特的传输速率 第二 ->-每小时传输 6 TB 的数据 -> ->到 Amazon AWS？ 还是仅仅是产生足够多的实例来获得这种传输速率？ -> +* 多种语言使得难以记录。 -我很想告诉您是否有，但完全没有挑战。 只是产生 EC2 实例就给我们带来了其他一切，包括看似开放的数据传输管道和磁盘访问，以及 I / O 都可以正常工作。 实际上，在与亚马逊合作进行了 3 年这些测试之后，我们从未遇到任何带宽或 I / O 问题。 +* 如果存在问题，日志记录本身可能会使日志记录过多而使这些问题更加严重。 日志中需要背压以在过载时删除日志条目。 希望早些时候已放入系统中。 -我喜欢这篇文章，感谢您撰写。 +* **我希望知道的内容**：关于日志消息大小的一些概念，以便可以跟踪谁在生成过多的日志数据。 -托德（Todd）-如果您要花时间反驳某项陈述，最好花点时间进行拼写检查以提高信誉 + * 所有日志发生的事情是它们被某种工具索引，以便人们可以搜索它们并学习事物。 -除了 MySpace 本身之外，其他各方（Akamai 和/或沿途的其他运营商）是否也了解这种“受控 DoS”？ 是否不增加容量来处理流量的突然增加，但至少要知道这是请求的合法流量，而不是某些 DoS 攻击？ + * 如果免费记录，则记录的数据量是可变的。 有些人会记录很多数据，使系统不堪重负。 -您可以从 Amazon 获得如此多的实例和资源，这没有问题，因为 Amazon 知道您是谁以及这是一家什么样的公司，因此他们消除了对您帐户的任何限制？ 还是亚马逊真的有这么多的产能供任何支付者使用？ + * 对于计费系统，当将日志数据发送到群集以建立索引时，可以将帐单发送到服务以进行支付。 -该测试花了多长时间？ 您准备了多长时间了？ -您是否想念一些后来才意识到有用的数据？ -您是在看到 MySpace 正在处理负载还是在从头到尾从 0 到 1 磨时增加点击量吗？ + * 的想法是给开​​发人员以更大的压力，使他们更聪明地记录日志，而不是更难。 -对于我的一项工作，我们进行了类似的测试； 一切顺利，直到我们开始生产为止。 即将发布的消息是，我们的某些后端日志记录和报告系统正在执行 DNS 反向查找。 由于我们的测试来自有限的 IP 空间，因此查找并不是全部可见-但是由于数千名用户使用不同的 IP 位置，我们发现这造成了巨大的瓶颈。 值得牢记。 + * Uber 创建了 [uber-go / zap](https://github.com/uber-go/zap) 用于结构化日志记录。 -哇，我无法想象必须处理所有的流量以及在“开放”期间可能出现的任何问题。 我已经处理了高流量的网站，但没有像 Myspace 这样的网站。 +## 负载测试 -我从事表演业务，并使用云模拟了 40,000 个虚拟用户。 这篇文章强调了我面临的一些问题-大型数据集，将负载分散到可用区域等。还有一个我还没有解决的问题，那就是 jmeter 无法像浏览器一样进行并行下载。 当下载页面命中的所有资源时，这反映在较大的事务响应时间中。 在澳大利亚和美国西部之间的每次请求中，RTT 为 250 毫秒也会使情况变得更糟。 到目前为止，我不得不在报告中说明这一点，尽管结果表明事务 x 花费了 12 到 15 秒之间的时间，但这实际上相当于 0.5 到 3.5 秒的响应时间，并且总吞吐量并不是瓶颈。 +* 想要在将服务投入生产之前进行负载测试，但是无法构建与生产环境一样大的测试环境。 -SOASTA 加载工具是否可以执行并行下载，您是否考虑了 250 毫秒的 RTT？ +* 这也是生成实际测试数据以测试系统所有部分的问题。 -另一件事-如果同时有 100 万新西兰人同时使用 Myspace，那么那里的街道将空无一人。 +* 解决方案：在非高峰时段对生产进行测试。 -哦，还有一件事。 当然，您可以从一台笔记本电脑运行 1,000 个用户。 您不会达到 1GB /秒的速度。 您的响应时间度量将反映测试硬件（而不是被测系统）中的延迟。 关键在于您的负载生成器是否可以及时处理网卡生成的中断。 +* 引起很多问题。 -SeaPerf，为什么您不阅读他的讲话而不是寻找拼写错误？ 获得生活。 没有人需要互联网上的另一位抱怨拼写的笨蛋。 +* 它炸毁所有指标。 -你好 + * 您不希望人们认为负载多于实际负载。 为了解决该问题，它又回到了上下文传播问题。 + + * 确保所有测试流量请求都具有表示此测试请求的上下文，因此请以不同的方式处理指标。 这必须贯穿整个系统。 + +* **我希望知道的内容**：我们真正想要做的是始终在所有服务中运行负载，因为许多错误仅在流量达到峰值时才会出现。 + + * 希望将系统保持在峰值附近，并随着实际流量的增加而退缩。 + + * 希望该系统很早以前就已建立，可以处理测试流量并以不同的方式处理它。 + +## 故障测试 + +* **我希望知道的内容**：并非每个人都喜欢混沌猴子那样的失败测试，​​尤其是如果您稍后要添加它时。 + + * 如果您不喜欢，我们应该做的是对您进行故障测试。 这只是生产的一部分。 您的服务仅需承受随机的杀戮，操作的减慢和干扰。 + +## 迁移 + +* 我们所有的东西都是遗产。 全部都是迁移。 通常，从事存储工作的人们正在做的事情就是从一个旧版迁移到另一个旧版。 + +* 有人总是在某处迁移某物。 不管人们在会议上怎么说，这就是每个人都在做的事情。 + +* 旧的东西必须保持工作状态。 业务仍然必须运行。 不再有维护窗口之类的东西。 可接受的停机时间。 + +* 随着您成为一家全球企业，没有高峰时间。 总是高峰时间在某个地方。 + +* **我希望知道的内容**：迁移的要求很糟糕。 + + * 没有人希望被告知必须采用某种新系统。 + + * 使某人发生变化是因为组织需要进行变化，而不是提供一个更好的新系统，因此显然您需要接受这一新事物。 + + * 纯胡萝卜，不粘。 无论何时出现问题，除非与安全性或合规性有关，否则这是不好的，强迫人们做事可能是可以的。 + +## 开源 + +* 没有人同意建立/购买权衡。 你什么时候建造？ 你什么时候应该买？ + +* 属于基础架构的任何东西，看起来像是平台的一部分而不是产品的一部分的任何东西，在某个时候都将成为无差别的商品。 亚马逊（或某人）将提供它作为服务。 + +* 最终，您花了所有时间在做这件事，其他人会以更便宜和更好的方式来做。 + +* **我希望知道的内容**：如果人们正在使用某种平台类型的功能，那么听到亚马逊刚刚发布您的服务即服务听起来并不好。 + + * 您仍在尝试合理化为什么应将自己的私人物品用作服务。 + + * 事实证明，那些人在这些文本编辑器的另一端。 人们对构建/购买权衡的判断方式存在巨大差异。 + +## 政治 + +* 通过将所有内容分解为小型服务，可以使人们玩政治。 + +* 每当您做出违反此属性的决定时，就会发生政治事件：公司>团队>自我。 + + * 您将自己的价值观置于团队之上。 + + * 团队的价值高于公司。 + +* 政治不只是您不喜欢的决定。 + +* 通过拥抱高度模块化的快速发展，非常快地雇用人员并尽快发布功能，人们开始倾向于违反此属性。 + + * 当您重视以较小的个人成就来交付产品时，很难确定对公司有利的优先事项。 令人惊讶的权衡。 + +## 权衡取舍 + +* 一切都是权衡。 + +* **我希望知道的内容**：如何更好地有意进行这些折衷。 + + * 当事情在没有明确决定的情况下发生时，因为这似乎是事情的发展方向，即使没有明确做出决定，也要考虑做出什么权衡。 + +## 相关文章 + +* [关于 HackerNews](https://news.ycombinator.com/item?id=12697006) + +* 关于在 HackerNews 和 [上的视频](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) [的精彩讨论，关于[Reddit]](https://news.ycombinator.com/item?id=12597232) + +* [扩展流量高的 Feed 的设计决策](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html) + +* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) + +* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) + +* [Uber 变得与众不同：使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) + +* [Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理百万个写入](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) + +* [与 Matt Ranney 缩放 Uber](http://softwareengineeringdaily.com/2015/12/04/engineering-at-uber-with-matt-ranney/) + +* [InfoQ 播客：Uber 的首席系统架构师，介绍其架构和快速发展](https://www.infoq.com/articles/podcast-matt-ranney) + +* [分布式 Web 架构：Matt Ranney，Voxer](https://gaming.youtube.com/watch?v=pXT0mF9bMyA) + +* [Riak at Voxer-Matt Ranney，RICON2012](https://vimeo.com/52827773) + +优步遍布 400 多个城市。 因此，请在帖子中更正此问题。 + +谢谢 -感谢您的文章，这很有趣。 我正在研究这个主题，并且有一些问题。 也许你可以帮忙。 +这是我一生中读过的最好的经验教训文章之一。 这是一项毫不废话，诚实和实践的知识共享活动。 许多公司正在努力适应不断变化的新技术，例如带有 Docker 的微服务，CI / CD，Paas，Saas 和 Cass。 正如他在视频中正确指出的那样，这始终是一种思维定势/文化的挑战，每个人对编程语言，方法等都有自己的看法。认识到这一事实并引导每个人实现业务需求的共同目标很重要。 -您如何定义我们需要强调的计算机数量。 -例如，如果我在瓶颈所在的位置使用 apache bench，那么我可以同时运行 1000 个用户吗？ -网络，CPU 和 RAM 有一些瓶颈，如何定义它们？ +难以置信！ 从头到尾纯粹基于经验的演讲 -对于较小的压力测试，您建议使用哪种软件？ （Apache Bench，JMeter，Siege 等），以及如何定义场景？ （使用 Jmeter 代理，处理 apache 访问日志吗？） +很棒的文章，有非常有用的信息。 -西里尔 \ No newline at end of file +完全基于经验非常坦率非常实用。 他吸取的教训是休息的智慧。 \ No newline at end of file diff --git a/docs/205.md b/docs/205.md index 1addc26..57c787e 100644 --- a/docs/205.md +++ b/docs/205.md @@ -1,133 +1,188 @@ -# Twitter 计划分析 1000 亿条推文 +# QuickBooks 平台 -> 原文： [http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) +> 原文： [http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html](http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html) -![](img/2ad0f5c434cea68e0d66d5cc1a87723d.png)如果 Twitter 是某些人认为的“网络神经系统”，那么从神经系统来的所有这些信号（推文）的大脑究竟是什么呢？ 大脑就是 Twitter 分析系统，而 Twitter 的分析负责人 Kevin Weil 是负责计算超过 1000 亿条 Tweet（约等于人脑中神经元数量）含义的单元。 +![](img/f467ec8cf4d38d56b883aa13f1ef804a.png) -目前，Twitter 仅占预期的 1000 亿条推文的 10％，但始终要做好计划。 Kevin 在 [Hadoop Meetup](http://www.meetup.com/hadoop/) 上的 Twitter 上发表了 [Hadoop 和协议缓冲区的演讲，解释了 Twitter 如何计划使用所有数据来回答关键业务问题。](http://www.slideshare.net/kevinweil/protocol-buffers-and-hadoop-at-twitter) +*这是 Siddharth Ram –小型企业首席架构师的特邀帖子。 [[受电子邮件保护]](/cdn-cgi/l/email-protection#114278757579706365794e63707c51787f656478653f727e7c) 。* -Twitter 有兴趣回答哪种类型的问题？ 帮助他们更好地了解 Twitter 的问题。 像这样的问题： +QuickBooks 生态系统是最大的小型企业 SaaS 产品。 QuickBooks 平台支持面向全球范围内的小型企业，其客户和会计师的簿​​记，薪资和付款解决方案。 由于 QuickBooks 还是合规&纳税申报平台，因此报告的一致性非常重要。财务报告要求查询具有灵活性-给定的报告可能具有数十种可以调整的不同维度。 协作需要员工，会计师和企业所有者同时进行多次编辑，从而导致潜在的冲突。 所有这些都导致在 Intuit 解决有趣的缩放问题。 -1. 一天我们要处理多少个请求？ -2. 平均延迟时间是多少？ -3. 一天有多少次搜索？ -4. 多少个唯一查询，多少个唯一用户，他们的地理分布是什么？ -5. 作为用户的推文，我们能告诉我们什么？ -6. 谁转发了更多？ -7. 移动用户的用法有何不同？ -8. 同时出了什么问题？ -9. 哪些功能使用户着迷？ -10. 用户的声誉是什么？ -11. 转推的深度有多深？ -12. 哪些新功能有效？ +解决可伸缩性需要考虑多个时间范围和轴。 扩展不仅涉及扩展软件，还涉及人员可扩展性，流程可扩展性和文化可扩展性。 所有这些轴都在 Intuit 进行了积极的研究。 我们与员工的目标是营造一种氛围，使他们能够尽其所能。 -还有更多。 这些问题可以帮助他们理解 Twitter，其分析系统可以帮助他们更快地获得答案。 +# 背景 -## Hadoop 和 Pig 用于分析 +QuickBooks Online 产品已有十年半的历史了。 它是作为整体构建的，没有明确的关注点分离。 整体服务良好地服务于 Intuit –每天有数百万的客户使用它进行数亿笔交易。 这部分是可能的，因为产品内置了泳道。 这允许按公式划分比例（客户在特定分片中“归位”）进行缩放。 如今，我们可以将整体拆分为多种服务，并迁移到 AWS 作为主要托管解决方案。 -您能想到的任何问题都需要分析大数据来寻找答案。 1000 亿是很多推文。 这就是 Twitter 使用 [Hadoop 和 Pig](http://www.slideshare.net/kevinweil/hadoop-pig-and-twitter-nosql-east-2009) 作为其分析平台的原因。 Hadoop 提供：在分布式文件系统上的键值存储，水平可伸缩性，容错性以及用于计算的 map-reduce。 Pig 是一种查询机制，可以在 Hadoop 之上编写复杂的查询。 +## 数字 -说您正在使用 Hadoop 仅仅是故事的开始。 故事的其余部分是使用 Hadoop 的最佳方法是什么？ 例如，如何在 Hadoop 中存储数据？ +* 全球小型企业最大的 SaaS 产品 -这似乎是一个奇怪的问题，但答案却有很大的后果。 在关系数据库中，您不存储数据，数据库存储您，或者，它为您存储数据。 API 以行格式移动数据。 +* 超过 500 万的台式机和网络客户 -Hadoop 并非如此。 Hadoop 的键值模型意味着由您决定如何存储数据。 您的选择与性能，可以存储多少数据以及对将来的变化做出反应的敏捷程度有很大关系。 +* 每天处理 250M +请求 -每个推文都有 12 个字段，其中 3 个具有子结构，并且随着新功能的添加，这些字段可以并且会随着时间而变化。 存储此数据的最佳方法是什么？ +* 年增长率超过 40％ -## 数据存储在协议缓冲区中以保持数据的高效和灵活 +* 通过 AWS 进行全球扩展 -Twitter 认为 CSV，XML，JSON 和协议缓冲区是可能的存储格式。 协议缓冲区*是一种以有效但可扩展的格式对结构化数据进行编码的方法。 Google 几乎所有内部​​RPC 协议和文件格式*都使用协议缓冲区。 BSON（二进制 JSON）尚未进行评估，但可能因为它没有 IDL（接口定义语言）而无法使用。 [Avro](http://hadoop.apache.org/avro/) 是他们将来会考虑的一种潜在选择。 +* 全球约有 2,000 名工程师在产品上工作。 -创建了一个评估矩阵，该矩阵宣布 Protocol Buffers 为获胜者。 赢得协议缓冲区是因为它允许将数据拆分到不同的节点上。 它不仅可用于推文（日志，文件存储，RPC 等），还可用于其他数据； 它有效地解析； 可以添加，更改和删除字段，而无需更改已部署的代码； 编码很小； 它支持层次关系。 所有其他选项均未通过这些条件中的一个或多个。 +* 2000+ 3 个基于 Intuit 平台构建的 和 参与者应用程序 -## IDL 用于 Codegen +## 技术 -出乎意料的是，效率，灵活性和其他神圣的怪胎指标并不是 Twitter 喜欢协议缓冲区的唯一原因。 通常被视为弱点的是，协议缓冲区使用 IDL 来描述数据结构，实际上被 Twitter 视为大赢家。 必须定义数据结构 IDL 通常被视为浪费时间。 但是作为构建过程的一部分，它们从 IDL 中生成所有与 Hadoop 相关的代码：协议缓冲区 InoutFOrmats，OutputFormats，Writables，Pig LoadFuncs，Pig StoreFuncs 等。 +* Java / JVM 是主要服务/后端 -以前为每个新数据结构手动编写的所有代码现在都可以从 IDL 中自动自动生成。 这样可以节省大量精力，并且代码的错误少得多。 IDL 实际上节省了时间。 +* 多语言持久性–不同的用例需要使用不同的存储技术，QuickBooks 平台将 RDBMS（Oracle / MySQL），Neo4J 和 Cassandra 用于 OLTP 和 Hadoop & Vertica 进行分析 -某一时刻，模型驱动的自动生成是许多项目的通用策略。 然后，时尚开始产生一切。 Codegen 似乎还不够敏捷。 一旦生成了所有内容，您就开始真正担心语言的冗长性，这使每个人都转向了更加动态的语言，具有讽刺意味的是，DSL 仍然经常被列为 Ruby 之类的语言的优势。 手编码的另一个后果是周炎的框架。 框架有助于平息认为必须从头开始编写所有内容而造成的损害。 +* 前端已使用 ReactJS 进行了重建，我们了解到缩放不仅适用于后端-前端缩放是我们开发的一项新技能。 -很高兴看到代码生成再次流行。 使用声明性规范，然后编写高效的，特定于系统的代码生成器，功能非常强大。 数据结构是低挂的果实，但是也可以自动化更大，更复杂的过程。 +* 监控是使用多个内部和现成的工具完成的，现成的主要工具是 Splunk 和 New Relic -总体而言，这是一次非常有趣和有益的演讲。 我喜欢看到基于想要的内容和原因对不同选项进行的仔细评估。 令人耳目一新的是，这些明智的选择如何协同作用，并构成了一个更好，更稳定的系统。 +* 通过企业 github 进行代码管理 -## 相关文章 +* ActiveMQ 和 Kafka 处理异步消息 -1. [Twitter 上的 Hadoop 和协议缓冲区](http://www.slideshare.net/kevinweil/protocol-buffers-and-hadoop-at-twitter) -2. [Twitter 背后的窥视](http://borasky-research.net/2010/02/17/a-peek-under-twitters-hood)-Twitter 的开源页面上线了。 -3. [Hadoop](http://hadoop.apache.org/) -4. [协议缓冲区](http://code.google.com/p/protobuf/) -5. [Hadoop 湾区用户组-2 月 17 日在 Yahoo! -RECAP](http://developer.yahoo.net/blogs/hadoop/2010/02/hadoop_bay_area_user_group_feb.html) -6. [Twitter 说](http://blog.twitter.com/2010/02/measuring-tweets.html)“今天，我们每天看到 5000 万条推文，平均每秒 600 条推文。” +* Ansible 和 Chef 用于配置管理 -> 这就是为什么 Twitter 使用 Hadoop 和 Pig 作为分析平台的原因 +* 大量使用边缘缓存和 Akamai WAA -has a broken url +## 文化 -谢谢。 似乎所有 URL 由于某种原因都被转义。 现在应该修复。 +* 每个服务都有定义了 RTO 和 RPO 的 HA / DR。 我们每周执行 HA / DR 计划，以确保在发生常规事件时对客户的影响很小甚至没有。 这是所有 SaaS 产品都需要计划和执行的最佳实践。 -所有这些推文中有 99％是垃圾。 他们究竟将如何分析其中的任何内容？ +* 高度重视弹性。 服务不可用通常并不意味着客户知道它。 -从理论上讲，每条推文都是一种人类思想或一种交流意识。 分析大量数据将意味着识别人脑在各个方面的功能-例如给定的时间，星期几，地理位置，文化，趋势等-因此，了解这种人类行为就构成了识别人的大脑。 在线大众。 （仅限于 Twitter）。 +* 服务在内部服务门户中发布。 这使工程师可以重用其他团队构建的服务，并减少服务克隆。 -最后，它是所有统计信息-一定比例的网络将为这种现象数据做出贡献。 +* 性能是根据 TP99，TP90 和 TP50（通常更高）来衡量的。 TP50 代表第 50 个 第 个百分位数的客户体验。 我们的目标是 1 秒的 TP50 和 2 秒的 TP90。 （即少于 10％的客户在任何给定页面上的页面加载时间超过 2 秒）。 -希望我们能更多地了解人的思想链是如何运作的，并希望这有助于神经科学家作为研究工具。 +* 客户互动失败（FCI）是我们跟踪的另一个关键指标。 与客户（HTTP 4xx / 5xx）的每次失败交互都被视为失败交互。 我们的目标是使每项服务的 FCI 都低于 0.025％。 -我的$ 0.02 +* 服务团队拥有端到端的服务。 他们负责与 devops 模型一致的服务维护和正常运行时间。 PagerDuty 用于提醒呼叫人员出现问题和参与恢复。 -〜Vj +* 您无法改善无法测量的内容。 通过近乎实时的仪表板，可以在公司的可用性，性能，可扩展性和质量指标方面广泛了解公司。 这是驱动组织行为的关键。 -几个月前，奇怪的 Twitter Twitter Tweet ID 泛滥成灾，他们怎么可能拥有 1000 亿条 Tweet？ +* 我们正在过渡到反应性，松散耦合的系统 ，该系统可增强扩展能力。 但是，这需要仔细考虑如何处理系统中最终的一致性。 -我会用“神经系统”代替“神经系统”，“神经系统”将这些信号/推文发送给我们的外行贿赂者，改为“突触发射”，其中指出推文更恰当地是*大脑*内部的信号。 它是对信号触发或重推的分析，我们发现了模式，并且在这些模式中有意义。 +* 工程师对系统中的每个故障执行 RCA（根本原因分析）。 RCA 已由工程领导审核。 我们将 5 个“为什么”和“鱼骨”应用于每个 RCA。 失败是一位出色的老师 。 -有关 Synaptic 网站的更多信息，请访问： +* 强烈的代码意识和域所有权。 -http://synapticweb.pbworks.com/ +* 任务驱动。 当人们看到自己对客户的影响时，便会尽自己最大的努力。 -@khrisloux +* 在质量，性能，可用性和安全性上丝毫不妥协。 -我要说的是 [Vivisimo 的 Velocity 搜索引擎](http://vivisimo.com/)可以为他们提供很多帮助。 +* 持续部署和功能切换使我们能够快速交付 -有趣的帖子，托德。 +## 可伸缩性中的有趣挑战 -您的帖子中有一些复制错误： +# 缩放比例特性 -“ 5.作为用户，我们可以从他们的推特中获得什么？” | 可能应该是：我们能告诉用户什么... +QuickBooks Online 之类的产品具有与其他 SaaS 产品不同的缩放特性。 报表查询可能已应用了许多其他过滤器。 这些查询在公司之间通常是不同的。 报告会产生税收后果，因此必须始终与账簿保持一致。 会计和小型企业所有者可能同时进行多次编辑，才能进行协作。 该软件需要确定如何处理冲突。 所有这些导致在 Intuit 的 QuickBooks 平台上进行扩展的有趣方式。 -“ 8.如果同时出错怎么办？” | 怎么了... +# 变量 -“ 11.转发的深度有多深？” | 有多深... +QuickBooks 平台为全球数百万个小型企业，其客户和会计师提供服务。 为客户提供各种用例：产品需要解决的可变性包括： -不是要分析什么，而是要服务于什么业务目的。 +* 设备多样性–我们根据需要为客户提供服务-台式机，移动设备，在线 -无论如何，tweet 中的 URI 可以为用户分析提供更多的价值。 +* 地理多样性–在全球范围内使用，伴随着法规的复杂性，要​​解决的税收往往非常本地化和专业化 -“ Protocol Buffers 之所以获奖，是因为它允许将数据拆分到不同的节点上；它不仅可以用于推文（日志，文件存储，RPC 等），而且还可以重用；它可以高效地解析；可以添加，更改和删除字段而无需 更改已部署的代码；编码很小；它支持层次关系。所有其他选项都无法通过其中一个或多个条件。” +* 合规性多样性–不同的政府机构（例如工资税）对合规性有不同的规定 -只需用纯文本替换 Protocol Buffer 并享受相同的方法即可：)严重的是，我没有得到 PB 选择背后的基本原理，但最终还是要随心所欲。 除非您在 hdfs 的顶部构建 HBase 之类的东西，否则当您运行冗长的批处理作业时，内部存储格式并不重要。 +* 产品多样性–根据员工人数，他们所针对的市场性质（例如，基于产品的业务与基于服务的业务），不同的客户群具有不同的需求 -“今天，我们每天看到 5000 万条推文，平均每秒 600 条推文。” +* 工作流的多样性–公司可能拥有执行（并被授予）产品子集的工人。 例如，应收账款业务员将仅看到应收帐款流量。 员工通常不执行业务报告。 -什么！？ +这是我们处理的多样性的子集。 尽管解决了很多多样性问题，但平台始终需要解决一些基本问题。 安全性，隐私性，可伸缩性和质量是软件基本构建模块的一部分。 -每秒 600 条推文！？ +# 缩放哲学 -... +QuickBooks 平台通常遵循“可扩展性多维数据集” 模型，在三个维度上进行缩放： -哇...我真是令人难以置信地不知所措...我的意思是我觉得 Twitter 可以解决所有这些可扩展性问题，因为它们每秒有成千上万甚至数十万条推文。 +![](img/e14850f4600ff2e4f07d4add57be0c4a.png) -天哪，如果他们用 C 编写 Twitter 系统，就可以轻松地通过单个服务器处理“所有”流量。 +## X 轴–只读副本 -无论哪种方式，我仍然认为 Twitter 是一个好主意，他们应该得到应有的荣誉，他们在 Twitter 的整个软件包和声誉方面都做得很好。 但是，为什么不聘请 C 程序员来重写他们的堆栈并降低成百上千的成本呢？ +X 轴主要用于只读副本。 与许多 SaaS 产品一样，与写入次数相比，读取次数很多。 常见的且相对昂贵的读取操作是报告。 小型企业和会计师需要了解他们的业务状况。 我们通过 QuickBooks Money Bar 提供见解，并通过大量报告（例如资产负债表，损益报告）提供更详细的见解。 只读副本使我们既可以减少访问的热点，又可以提供预先计算的报告 -@罗伯特·古尔德（Robert Gould）：我也为如此低的数量感到惊讶。 虽然据我了解，问题不在于处理传入的 tweet，而是将它们发送给所有订户。 请记住，某些用户有数千个（或数百万个）关注者。 +## Y 轴-服务 -用 C 重写对可伸缩性没有多大帮助。 它将使系统稍微快一些，但不超过一个数量级，以可维护性，稳定性和开发速度为代价。 +扩展的第二个方面是在不同的服务中破坏产品。 QuickBooks 平台建模为 14 个不同的域，这些域组成了产品。 服务 API 现在是第四个修订版-V3 QuickBooks API 可以在 [http://developer.intuit.com](http://developer.intuit.com) 中找到。 -我认为经过大量分析，并从大型 Twitter 数据库中获取了大量数据之后，我们会发现我们的逻辑性不如我们想像的那样，而且实际上是可预测的。 +### Z 轴-公式拆分 -模式将得出结论，就像地球上所有其他生物一样，我们受到重力，季节，夜晚和白天的影响，x 类型的人更有可能鸣叫 x 等。我认为这一实验肯定会证实人类是 习惯的生物。 \ No newline at end of file +Z 轴指的是“分片”（sharding）-允许大范围缩放的非规范化数据。 QuickBooks 根据公司的属性来拆分客户。 然后，每个分片将与具有类似属性的其他公司共享。 + +### C 轴 + +除了这些方面，我们经常谈论“ C”轴-文化轴，这是我们扩展规模的关键方法。 在 C 轴上对我们的主要增强是（a）度量文化–您无法解决无法观察到的问题（b）通过 devops 模型拥有所有权的文化，以及（c）在我们所做的任何事情中客户支持的思想。 + +### 缩放前端 + +在 200KLOC 以上，QuickBooks onlike 具有非常大的 Javascript 占用空间。 扩展前端的一部分意味着要理解如何确保更改是隔离的并且组件可以重复使用，以至于 3 个 rd 参与者可以直接插入前端，并且 任何遵循规则的人都可以贡献力量。 缩放还意味着在样式上具有统一性，易于坚持。 + +## 公有云之旅 + +Intuit 的一项关键策略是将所有软件资产移至 AWS。 在公共云中，给定共享的基础架构，还需要考虑安全性和隐私性。 在将软件迁移到 AWS 时，我们使用以下一般原则： + +* 必须保护每个端点。 在公共云中，我们不能假设服务之间的链接是安全的端点。 + +* 每个 Intuit 和 AWS 平台服务都必须是可观察的。 这种可观察性是能够分析欺诈和安全性访问的关键。 + +* 提升并移动+分解。 在适当的情况下，我们将分解为服务并迁移到公共云。 对于较大的系统，我们进入 AWS 基础架构并就地分解。 + +* 多区域 DR。 区域中断发生。 我们希望即使在单个地区受到影响时也能够提供服务。 + +* 在本地服务客户。 安全港 和性能都决定了靠近客户的数据存储。 这要求客户必须在本地区域“回国”（例如，在欧洲的 AWS 数据中心外服务的欧盟客户）。 + +* 爆炸半径遏制。 “无共享”方法可确保我们限制爆炸半径。 系统中断应该导致本地事件，而不是全局事件。 + +## 主要课程 + +* 3 轴缩放是关键。 知道哪些轴适用于正确缩放有助于缩放。 + +* 确保可以控制影响。 必须充分理解和测试系统的爆炸半径。 + +* RCA –失败是一位了不起的老师。 浪费失败的教训是可耻的。 架构师负责分析故障并找出根本原因。 + +* 不要低估重新考虑在公共云中保护软件的数量。 + +* Dogfood。 公司工程师使用的服务应与为 3 个 和 参与方开发人员提供的服务相同。 + +* 了解您的 KPI 并能够预测性能曲线的样子–这有助于快速识别出问题所在。 + +* 也可以缩放前端，而不仅仅是后端。 + +嗨，感谢您的帖子，它非常有用。 我想知道为什么您同时使用 ansible 和 Chef，因为我希望一家公司同时使用其中一种？ + +嗨，查理， + +并没有 Ansible 和 Chef 的强烈技术理由。 不同的团队使用了不同的技术。 随着时间的流逝，我们将逐步淘汰其中之一。 + +悉达思 + +您好 Siddharth， + +感谢您花时间描述系统。 由于您将整体拆分为服务，因此如何管理服务之间的安全性和身份验证？ + +嗨， + +好问。 在整体中，通信相对容易-只需进行另一个函数调用即可。 在分布式系统中，难度会增加一些-但技术仍然非常相似。 + +身份验证和安全协议是非常标准的。 Intuit 管理自己的身份系统。 每个请求必须具有身份验证上下文-包括服务器-服务器调用。 这些将很快到期，并分配新的票证。 SSL / TLS 是用于有线加密，客户端-服务器以及服务器-服务器通信的标准问题。 分析/监视查找访问模式中的异常。 + +您如何管理服务之间的安全性和身份验证？ + +据我所知，Intuit 使用 google oauth1.0 进行身份验证，这基本上是基于令牌的身份验证系统。 例如，您有一个使用者密钥和一个使用者密钥，您获得一个请求密钥和请求令牌，然后吐出一个访问令牌和访问密钥。 令牌有效期为 6 个月，不确定令牌何时到期才能访问那些基于 JAVA 的 REST API 和安全标准 SHA2 算法。 我写了一篇关于 SSL 握手的文章。 它应该有助于提供见解。 + +参考： +https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/ + +嗨， +很棒的文章，感谢您的分享，您可以解释一下是否有建立另一个 QuickBooks 或 Zoho Books 的范围？ +谢谢， +Divya， +[Quickbook Developer](http://www.catchexperts.com/quickbook-online-training) \ No newline at end of file diff --git a/docs/206.md b/docs/206.md index d31c717..cd18f01 100644 --- a/docs/206.md +++ b/docs/206.md @@ -1,131 +1,103 @@ -# 《 FarmVille》如何扩展以每月收获 7500 万玩家 +# 美国大选期间城市飞艇如何扩展到 25 亿个通知 -> 原文： [http://highscalability.com/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html](http://highscalability.com/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html) +> 原文： [http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html](http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html) -*一些读者对本文有后续问题。 可以在[《 FarmVille 如何缩放-后续行动》](http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html) 中找到卢克的回应。* +![](img/8a073c8483bfc1f227aed0829dbb7f84.png) -![](img/4dfef10759448f17402c25ab64e9e4bb.png)如果像 Zynga 的大热门《 Farmville 》中的真实耕种一样令人振奋，那么我的家人可能永远不会离开北达科他州那些严酷的冬天。 我的祖母过去讲的关于农业的可怕的睡前故事，在 FarmVille 中都不是真的。 [农民](http://w.good.is/post/What-Does-Farmville-Mean-for-Farmers/)赚钱，植物生长，动物从不拜访[红色谷仓](http://www.youtube.com/watch?v=eUJz3137EQ8)。 我想仅仅是因为保持鞋子干净整洁的魅力，才使得 FarmVille 在如此短的时间内成为“世界上最大的游戏”。 +*这是 Urban Airship 的来宾帖子。 贡献者：亚当·洛瑞（Adam Lowry），肖恩·莫兰（Sean Moran），迈克·赫里克（Mike Herrick），丽莎·奥尔（Lisa Orr），托德·约翰逊（Christine Ciandrini），阿什什·沃蒂（Ashish Warty），尼克·阿德雷德（Nick Adlard），梅勒·萨克斯·巴尼特（Mele Sax-Barnett），尼尔·凯利（Niall Kelly），格雷厄姆·福里斯特（Graham Forest）和加文·麦奎兰* -FarmVille 如何扩展 Web 应用程序以每月处理 7500 万玩家？ 幸运的是，FarmVille 的卢克·拉吉里奇（Luke Rajlich）同意让我们了解他们的一些挑战和秘密。 这是卢克必须说的... +Urban Airship 受到数以千计的希望通过移动技术发展的企业的信任。 Urban Airship 是一家成立 7 年的 SaaS 公司，拥有免费增值业务模式，因此您可以免费试用 [](https://www.urbanairship.com/lps/best-push-notification-service)。 有关更多信息，请访问 [www.urbanairship.com](http://www.urbanairship.com/) 。 目前，城市飞艇平均每天发送的推送通知超过 10 亿条。 这篇文章重点介绍了 2016 年美国大选的城市飞艇通知使用情况，并探讨了系统的架构-核心传递管道-为新闻发布者提供数十亿实时通知。 -采访的形式是，我向卢克发送了一些一般性问题，他回答了以下答复： +## 2016 年美国大选 -> FarmVille 具有一组独特的扩展挑战，这是应用程序所特有的。 游戏必须迅速扩展。 该游戏在 4 天后每天有 100 万玩家，在 60 天后每天有 1000 万玩家。 在发布时，最大的社交游戏是每天 500 万玩家。 目前，《 FarmVille》推出后 9 个月的每日玩家有 2800 万，每月玩家有 7500 万。 这使得 FarmVille 的每月玩家人数超过了法国的全部人口。 FarmVille 有两个基本特征，这是独特的扩展挑战：它是世界上最大的游戏，并且是 Web 平台上最大的应用程序。 这两个方面都带来了 FarmVille 必须克服的一系列独特的扩展挑战。 在技​​术投资方面，FarmVille 主要利用开源组件，并且其核心是基于 LAMP 堆栈构建的。 -> -> 为了使 FarmVille 可扩展为游戏，我们必须适应游戏的工作量要求。 用户状态包含大量具有微妙而复杂的关系的数据。 例如，在服务器场中，对象无法相互碰撞，因此，如果用户在其服务器场上放置房屋，则后端需要检查该用户服务器场中是否没有其他对象占用重叠空间。 与大多数主要网站（如 Google 或 Facebook）读取量大不同，FarmVille 的写入工作量非常大。 数据读取与写入的比率为 3：1，这是令人难以置信的高写入速率。 到达 FarmVille 后端的大部分请求都以某种方式修改了玩游戏的用户的状态。 为了使其具有可扩展性，我们努力使我们的应用程序主要与缓存组件进行交互。 此外，由于我们正在有效地扩展游戏，因此发布新内容和功能往往会导致使用量激增。 新功能发布之日，负载峰值可能高达 50％。 我们必须能够容纳这种高峰流量。 -> -> 另一个方面使 FarmVille 规模成为 Web 平台上最大的应用程序，并且与世界上一些最大的网站一样大。 由于该游戏在 Facebook 平台内运行，因此我们对平台的延迟和性能差异非常敏感。 结果，我们做了很多工作来减轻延迟差异：我们大量缓存 Facebook 数据，并在性能下降时优雅地提高了平台的使用率。 FarmVille 已为 Facebook 平台部署了整个缓存服务器集群。 FarmVille 和 Facebook 平台之间的流量巨大：高峰时，FarmVille 和 Facebook 之间的流量大约为 3 Gigabit / sec，而我们的缓存群集又为应用程序提供了 1.5 Gigabit / sec。 此外，由于性能可以变化，因此应用程序可以动态关闭对平台的任何调用。 我们有一个可以调整的拨号盘，可以逐渐关闭返回平台的更多呼叫。 我们还努力使所有调用都返回平台，以避免阻塞应用程序本身的加载。 这里的想法是，如果其他所有方法都失败了，则玩家至少可以继续玩游戏。 -> -> 对于任何 Web 应用程序，高延迟都会杀死您的应用程序，而高度可变的延迟最终会杀死您的应用程序。 为了解决高延迟问题，FarmVille 致力于在高延迟组件之前放置大量缓存。 高度可变的延迟是另一个挑战，因为它需要重新考虑应用程序如何依赖其体系结构中通常具有可接受的延迟的部分。 几乎每个组件都容易受到这种可变延迟的影响，其中一些比其他组件更容易受到影响。 由于 FarmVille 的性质（工作量非常大且事务繁重），与传统的 Web 应用程序相比，延迟的变化对用户体验的影响更大。 FarmVille 处理这些情况的方式是通过将每个组件都视为可降级的服务来考虑。 Memcache，数据库，REST Apis 等都被视为可降解服务。 服务降级的方式是为该服务的错误限制率并实施服务使用限制。 关键思想是通过使用错误和超时限制来隔离故障和高延迟的服务，以免在其他地方引起延迟和性能问题，并在需要时使用打开/关闭开关和基于功能的调节器禁用应用程序中的功能。 -> -> 为了帮助管理和监视 FarmVille 的 Web 场，我们利用了许多开源的监视和管理工具。 我们使用 nagios 进行警报，使用 munin 进行监视，并使用 puppet 进行配置。 我们大量利用内部统计系统来跟踪应用程序使用的服务（例如 Facebook，DB 和 Memcache）的性能。 此外，当我们发现性能下降时，我们会以采样为基础来分析请求的 IO 事件。 +在选举日前后的 24 小时内，Urban Airship 发出了 25 亿条通知，这是有史以来的最高日发送量。 这相当于在美国每人 8 条通知，或者世界上每部活动的智能手机 1 条通知。 尽管 Urban Airship 在每个行业垂直领域为超过 45,000 个应用程序提供支持，但对选举使用情况数据的分析显示，超过 400 种媒体应用程序占了这一记录量的 60％，随着跟踪选举结果并在一天之内发送 15 亿条通知 报告。 -## 得到教训 +![](img/36ce3f158f2a647278f8b998ea2b34fc.png) -关于某些事情，我没有那么多的细节，但是我认为人们仍然可以从中学习很多有趣的观点： +总统选举结束时，通知量稳定并达到顶峰。 -1. **交互式游戏写得很重**。 典型的 Web 应用程序读取的内容多于编写的内容，因此许多常见的架构可能还不够。 读取繁重的应用程序通常可以通过单个数据库前面的缓存层来解决。 写繁重的应用程序需要分区，以便写操作可以分散和/或使用内存架构。 -2. **将每个组件设计为可降解服务**。 隔离组件，以使一个区域中的延迟增加不会破坏另一个区域。 节气门使用有助于缓解问题。 必要时关闭功能。 -3. **缓存 Facebook 数据**。 当您非常依赖外部组件时，请考虑缓存该组件的数据以提高延迟。 -4. **提前计划新的与发布有关的使用峰值**。 -5. **样本**。 在分析大型数据流时，例如查找问题，并不是每个数据都需要处理。 采样数据可以产生相同的结果，从而减少工作量。 +![election-urbanairship-notification.png](img/ed7aba40e08757f46f3ab55d602e8ec5.png) -我要感谢 Zynga 和 Luke Rajlich 抽出宝贵的时间进行这次采访。 如果其他人有他们想要的架构，请告诉我，我们会进行设置。 +到城市飞艇的 HTTPS 入口流量 [API](http://docs.urbanairship.com/api/ua.html) 在选举期间达到了每秒近 75,000 的峰值。 这些流量大部分来自与城市飞艇 [API](http://docs.urbanairship.com/api/ua.html) [ 。 -## 相关文章 +![election-urbanairship-HTTPS.png](img/f308127dc795976d958424e5b22196a5.png) -1. [建立大型社交游戏](http://www.slideshare.net/amittmahajan/building-big-social-games)-讨论 FarmVille 背后的游戏机制。 -2. [BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展](http://highscalability.com/blog/2010/1/22/how-buddypoke-scales-on-facebook-using-google-app-engine.html) -3. [策略：减少数据集的样本](http://highscalability.com/blog/2008/4/29/strategy-sample-to-reduce-data-set.html) -4. HighScalability 发布了[缓存](http://highscalability.com/blog/category/caching)和[内存缓存](http://highscalability.com/blog/category/memcached)的信息。 -5. HighScalability 发布了[分片](http://highscalability.com/blog/category/sharding)。 -6. 高扩展性发布在[内存网格](http://highscalability.com/blog/category/memory-grid)上。 -7. [如何在不进行实际尝试的情况下成功完成容量规划：Flickr 的 John Allspaw 专访他的新书](../../blog/2009/6/29/how-to-succeed-at-capacity-planning-without-really-trying-an.html) -8. [缩放 FarmVille](http://perspectives.mvdirona.com/2010/02/13/ScalingFarmVille.aspx) ，作者是 James Hamilton +推送通知量一直在迅速增加。 最近的主要推动力是英国退欧，奥运会和美国大选。 2016 年 10 月，每月通知量同比增长 150％。 -哇！ Farville 只是从“最烦人的网络事物”发展为“技术挑战的最酷示例。在我的个人词典中，那是:) +![monthly-sends.png](img/edd6f898ff8977d6b6b3e7259682ce3e.png) -我要做的最后一件事是贬低 Zynga 的优秀人才所取得的成就，但是这里存在一个巨大的疏忽错误……Zynga 运行着一个 200 节点的 Vertica 集群。 数据存储的可伸缩性非常重要，不是吗？ 同事： +## 核心交付管道架构概述 -“运行 Vertica 的 200 个节点...如果您无法进行横向扩展，则应该改用 7-11 计数器工作” +核心交付管道（CDP）是城市飞艇系统，负责从观众选择器中实现设备地址，并传递通知。 无论我们同时发送给数千万用户，针对多个复杂子细分市场，包含个性化内容或两者之间的任何内容，我们发送的所有通知都期望低延迟。 这是我们的架构的概述，以及我们在此过程中学到的一些知识。 -披露：我不为 Vertica 工作，呵呵。 +### 我们是如何开始的 -@森林 +最初始于 2009 年，最初是一个 Web 应用程序，一些工作人员已转变为面向服务的体系结构。 随着旧系统的各个部分开始出现规模问题，我们将它们提取到了一个或多个新服务中，这些服务旨在满足相同的功能集，但规模更大且性能更好。 我们许多原始的 [API](http://docs.urbanairship.com/api/ua.html) API 和工作程序都是用 Python 编写的，然后将它们提取到高并发 Java 服务中。 在最初将设备数据存储在一组 Postgres 分片中的地方，我们的规模迅速超过了添加新分片的能力，因此我们转向使用 HBase 和 Cassandra 的多数据库体系结构。 -有趣。 我认为 200 个节点运行起来不是很昂贵吗？ 否则，似乎值得指出的是开发自己开发的产品还是购买现成产品的决定。 +CDP 是处理分段和推送通知传递的服务的集合。 这些服务根据请求提供相同类型的数据，但是出于性能原因，每个服务都以不同的方式对数据进行索引。 例如，我们有一个系统负责处理广播消息，向注册到相关应用程序的每个设备传递相同的通知有效负载。 该服务及其底层数据存储区的设计与我们负责根据位置或用户个人资料属性传递通知的服务的设计有很大不同。 -令人失望的是，太笼统的:( -会令人着迷，以至于它们实际上没有读懂一些细节。 -他们使用的是云服务器还是专用服务器？有多少服务器？什么数据库？LAMP 中的哪个“ P”（php，perl，python， 等）？降低服务质量的示例？ -多肉，少起毛.. :) -至少与先前 CNBC 文章中详述的内容相同。 +我们将任何长期存在的进程视为一项服务。 这些长期存在的过程遵循有关度量，配置和日志记录的通用模板，以简化部署和操作。 通常，我们的服务属于以下两类之一：RPC 服务或使用者服务。 RPC 服务使用非常类似于 GRPC 的内部库提供命令来与服务进行同步交互，而消费者服务则处理来自 Kafka 流的消息并对这些消息执行特定于服务的操作。 -我怀疑游戏是否触及了 Verica 集群。 那是一个离线处理系统 +![urbanairship-cdp.png](img/8f0bf13a515234268219ff976be393a9.png) -本文并未明确说明使用哪个数据存储来保存每个数据库及其服务器场。 是 MySQL 吗？ MySQL 集群？ 其他一些 NoSQL DB？ +### 数据库 -这是一个很好的简介。 +为了满足我们的性能和规模要求，我们严重依赖 HBase 和 Cassandra 来满足我们的数据存储需求。 尽管 HBase 和 Cassandra 都是列式 NoSQL 存储，但它们的取舍却大不相同，这些折衷影响我们使用哪个存储以及用于什么目的。 -但与往常一样，细节中还是“恶魔”。 +HBase 非常适合高通量扫描，响应的预期基数很高，而 Cassandra 非常适合低基数查找，其中响应仅包含少数结果。 两者都允许大量的写入吞吐量，这是我们的要求，因为来自用户手机的所有元数据更新都是实时应用的。 -我们在哪里可以获得有关实际应用程序堆栈/硬件的更多指标，从而可以很好地了解可扩展性和可扩展性？ +它们的故障特性也不同。 在发生故障时，HBase 支持一致性和分区容忍度，而 Cassandra 支持可用性和分区容忍度。 每个 CDP 服务都有一个非常特定的用例，因此具有高度专业化的架构，旨在促进所需的访问模式并限制存储空间。 通常，每个数据库仅由单个服务访问，该服务负责通过不太专门的界面提供对其他服务的数据库访问。 -显然，它在 Amazon EC2 上运行。 只需在上面放一个嗅探器，您就会看到详细信息。 +增强服务与其支持数据库之间的 1：1 关系具有许多好处。 -因此，他们的 Web 2.0 策略是尽可能利用用户的驱动器和资源并减少净流量。 +* 通过将服务的支持数据存储视为实现细节而不是共享资源，我们获得了灵活性。 -哇。 我永远不会认为它是 2.0，因为所有 0.1 游戏都在本地运行并且 MMRPG 相对较新，但是我知道什么。 +* 我们可以在不更改服务代码的情况下调整服务的数据模型。 -在其他新闻中，显然有 7500 万人需要工作。 我尝试了几种网络应用程序游戏，发现它们乏味，有限且普遍乏味。 我也鄙视 facebook 上不可避免的重复性和不可避免的通知，以至于我不再使用它，而不是每月一次向远处的朋友签入。 +* 使用情况跟踪更为直接，这使容量规划更加容易。 -令人惊讶的是，一个设计欠佳的博客引擎如何将新闻发布为 myspace，以及大量广告如何将数百万个广告吸引到了 Facebook。 我仍然收到不存在者的 Facebook 邀请。 仅在过去的两年中，我就已经拥有了一百多个。 似乎没人对此多说。 +* 故障排除更加容易。 有时服务代码存在问题，而其他时候则是备份数据库问题。 将服务和数据库作为逻辑单元可以极大地简化故障排除过程。 我们不必怀疑“还有谁可以访问该数据库以使其表现为这种方式？” 相反，我们可以依靠服务本身的应用程序级指标，而只担心一组访问模式。 -商业道德规则 1： +* 因为只有一种服务与数据库交互，所以我们几乎可以执行所有维护活动，而无需停机。 繁重的维护任务成为服务级别的问题：可以在不中断服务的情况下完成数据修复，架构迁移，甚至切换到完全不同的数据库。 -如果一家公司必须撒谎，欺骗或窃取才能开展业务，那么您会尽力避免这种情况。 除非，当然，除非您喜欢与它们进行比较，并与 yahoo（启用垃圾邮件的公司），Friendfinder（曾经是世界上最大的垃圾邮件发送者）进行比较。 这些公司通过几乎不提供任何服务来为自己做得很好。 +的确，在将应用程序拆分为较小的服务时，可能需要进行一些性能折衷。 但是，我们发现，在满足高可伸缩性和高可用性要求方面获得的灵活性远远超过了其价值。 -欢迎来到炒作无所不在的美国。 +### 数据建模 -@paul 我想你错过了一些事情。 这些游戏绝对可以打到 Vertica 集群。 Vertica 的一些最大客户是高频交易者，他们使用它来处理实时数据流。 您为什么认为这是一个“离线处理系统”？ 有了这样大小的集群，我相信 Zynga 可以很好地汇总其 3TB 的每日 Farmville 数据。 +我们的大多数服务都处理相同的数据，只是格式不同。 一切都必须一致。 为了使所有这些服务的数据保持最新，我们严重依赖 Kafka。 Kafka 非常快，也很耐用。 速度需要权衡。 Kafka 邮件只能保证至少发送一次 ，并且不能保证依次发送。 -这是一篇带有更多参考数字的文章： +我们如何处理？ 我们已将所有变异路径建模为可交换的：操作可以按任何顺序应用，并最终得到相同的结果。 它们也是幂等的。 这有一个很好的副作用，我们可以重播 Kafka 流以进行一次性数据修复作业，回填甚至迁移。 -http://tdwi.org/Blogs/WayneEckerson/2010/02/Zynga.aspx +为此，我们利用了 HBase 和 Cassandra 中都存在的“单元版本”的概念。 通常，这是一个时间戳，但是可以是您想要的任何数字（有一些例外；例如，MAX_LONG 可能会导致一些奇怪的行为，具体取决于您的 HBase 或 Cassandra 的版本以及您的架构如何处理删除操作）。 -我相信他们正在使用 [Wink Streaming 的 CDN](http://www.winkstreaming.com) 来执行此操作。 我想这都是关于负载分配的。 +对我们来说，这些单元格的一般规则是它们可以具有多个版本，而我们订购版本的方式则取决于其提供的时间戳。 考虑到这种行为，我们可以将传入的消息分解为一组特定的列，然后将布局与自定义应用程序逻辑结合起来进行逻辑删除，同时考虑时间戳。 这样就可以在保持数据完整性的同时盲写基础数据存储。 -麦克风 +盲目地将更改写入 Cassandra 和 HBase 并非没有问题。 一个很好的例子是在重放事件中重复写入相同数据的情况。 由于我们努力使记录成为幂等，虽然数据的状态不会改变，但必须压缩重复的数据。 在最极端的情况下，这些额外的记录可能会导致大量的压缩延迟和备份。 由于这个细节，我们密切监视压缩时间和队列深度，因为在 Cassandra 和 HBase 中落后于压缩会导致严重的问题。 -7500 万听上去很酷，但请想象一下中国网站面临的挑战。 我的未婚夫是中国人，他们玩的农业游戏拥有数亿活跃玩家。 尊重该游戏的编码团队：） +通过确保流中的消息遵循一组严格的规则，并设计使用服务以预期乱序和重复的消息，我们可以使大量不同的服务仅同步一两个秒 滞后的更新。 -我认为这是一个非常有趣的领域（高流量在线游戏） +### 服务设计 -谢谢 +我们的大多数服务都是用 Java 编写的，但是使用的是一种自以为是的现代风格。 在设计 Java 服务时，我们有一组常规准则需要考虑： -我喜欢这篇文章，但是我想了解更多有关如何实现的信息。 使用了什么“胶水”的高层次视图来将所有抽象片段组合在一起？ LAMP 堆栈是一个不错的开始，但是主要零件的快速飞越（使用的设备可获得加分）将非常酷。 +* **做一件事，做好它。** -设计服务时，它应该承担单一责任。 实施者可以决定职责中包括的内容，但是他或他将需要准备在代码审查情况下证明其合理性。 -无论哪种方式，Farmville 绝对是可扩展性的令人印象深刻的示例。 我喜欢它！ +* **没有共享的操作状态** -设计服务时，假定将始终至少有三个实例在运行。 服务需要能够在没有任何外部协调的情况下处理任何其他实例可以处理的相同确切请求。 那些熟悉 Kafka 的人会注意到，Kafka 使用者在外部协调对 topic：group 对的分区所有权。 本指南涉及特定于服务的外部协调，而不是利用可能在幕后进行外部协调的库或客户端。 -> 它是网络平台上最大的应用程序 +* **约束您的队列** -我们在服务中使用队列，它们是将请求分批并将其散布到最终将完成任务的工作人员的好方法 从外部阻止。 所有队列都应有界。 边界队列确实引发了许多问题，但是： -嗯...闻起来像是胡说八道！ + * 当队列已满时，生产者会怎样？ 他们应该阻止吗？ 除？ 下降？ -实际上，他没有办法知道这一点。 即使无法证明，也可以确保“听起来不错”。 + * 我的队列应该有多大？ 要回答此问题，有助于假设队列始终已满。 -可降解服务的概念看起来非常不错。 有谁知道其他案例研究已经解释了吗？ 我当然想了解更多。 + * 如何完全关闭？ -@Robert Schultz -仅在没有最大定义的意义上才是 BS。 即使定义了它，也可能是值得商 bat 的指标。 + * 根据确切的用例，每个服务将针对这些问题提供不同的答案。 -这是故事的另一面： -http://techcrunch.com/2009/10/31/scamville-the-social-gaming-ecosystem-of-hell/ +* **命名自定义线程池并注册 UncaughtExceptionHandler** -如果最终创建自己的线程池，则使用 [的构造函数或帮助器方法 ]执行器](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html) ，以便我们提供 ThreadFactory。 使用该 ThreadFactory，我们可以正确地命名线程，设置线程的守护进程状态并注册 [UncaughtExceptionHandler](https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler-) 以处理将异常置于顶部的情况 堆栈。 这些步骤使调试我们的服务变得更加容易，并且使我们避免了深夜的沮丧。 -Spyder， +* **优先于可变状态而不是可变状态** -在高度并发的环境中，可变状态可能很危险。 通常，我们使用可以在内部子系统和队列之间传递的不可变数据对象。 拥有不变对象是子系统之间通信的主要形式，这使得并发使用的设计更加简单，并且使故障排除更加容易。 -关于技术紧缩的文章充斥着错误的信息。 不良报价在被发现后立即被取消。 制定了一个流程来确保它不再发生。 +## 我们从这里去哪里？ -有趣的文章，但是对他们正在使用的 LAMP 标度的技术方面有更多的了解将是很棒的。 他们正在使用 MySql 群集吗？ MySQL 复制？ 他们如何管理故障转移？ 显然他们也使用 EC2。 -这对我们所有人来说都是一个很好的例子。 - -我真的很喜欢一个网站每天最多可扩展到 2800 万用户的事实，这在游戏界确实是一个庞大的数字，而且写工作量很大。 \ No newline at end of file +凭借 Urban Airship 通过移动钱包通行证发送通知的功能，对 Web 通知和 Apple News 通知的新支持以及其将通知发送到任何平台，设备或营销渠道的开放渠道功能，我们预计通知量将成倍增长 。 为了满足这一需求，我们将继续在“核心交付管道”架构，服务，数据库和基础架构上进行大量投资。 要了解有关我们技术的更多信息以及前进的方向，请参阅 [GitHub](https://github.com/urbanairship) ， [开发人员资源](http://docs.urbanairship.com/dev-resources.html) ， [文档](http://docs.urbanairship.com/index.html) 和我们的 [职位页面](https://www.urbanairship.com/careers) 。 \ No newline at end of file diff --git a/docs/207.md b/docs/207.md index a578872..1900c52 100644 --- a/docs/207.md +++ b/docs/207.md @@ -1,79 +1,530 @@ -# BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展 +# Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题 -> 原文： [http://highscalability.com/blog/2010/1/22/how-buddypoke-scales-on-facebook-using-google-app-engine.html](http://highscalability.com/blog/2010/1/22/how-buddypoke-scales-on-facebook-using-google-app-engine.html) +> 原文： [http://highscalability.com/blog/2017/3/15/architecture-of-probot-my-slack-and-messenger-bot-for-answer.html](http://highscalability.com/blog/2017/3/15/architecture-of-probot-my-slack-and-messenger-bot-for-answer.html) -![](img/451edc7f930a797797870dc54ca1af27.png)您如何扩展一个病毒式 Facebook 应用，该应用激增至令人难以置信的 6500 万次安装（法国人口）？ 那是 [BuddyPoke](http://www.buddypoke.com/) 的共同创始人 Dave Westwood 遇到的问题，他在周三的 [Facebook Meetup](http://www.meetup.com/facebookmeetup/calendar/12179578/) 上谈到了他的解决方案。 完整演讲的幻灯片在此处。 对于那些不太确定 BuddyPoke 是什么的人，它是一个社交网络应用程序，它使用户可以通过在线头像来显示自己的心情，拥抱，亲吻和戳朋友。 +![](img/7217d552460750f7e349311ee16c6eb1.png) -在许多方面，BuddyPoke 是典型的现代 Web 应用程序。 它繁荣发展了社交网络驱动的生态系统。 游戏的机制，病毒循环和创造性的获利策略都是其日常概念化的一部分。 它将不同的技术融合在一起，而不是以黑暗的科学怪人方式，而是以一种聪明的方式获得最大的收益。 它的一部分在 Facebook 服务器上运行（免费）。 它的一部分在浏览器中的 Flash 上​​运行（免费）。 它的一部分在存储云上运行（成本更高）。 并且部分运行在平台即服务环境（GAE）上（低成本）。 它还与 PayPal 等其他服务紧密集成。 通过出售可在戳中兑换的虚拟商品，例如[金币](http://www.humanexperience.nl/wp-content/uploads/2009/06/buddypoke.png)，可以赚取真实的$$$。 用户还可以将他们的化身制作成玩偶，T 恤和其他由 Zazzle 提供动力的礼物。 +我编写了一个东西。 称为 [Probot](https://probot.us/) 。 Probot 是一种快速简便的方法，可为您的会计和税务问题提供高质量的答案。 Probot 将找到一位真正的现场专家来回答您的问题并处理所有细节。 您可以通过 Facebook Messenger，Slack 或 Web 回答问题。 答案最低为 10 美元。 那就是球场。 -这确实是一个了不起的企业，在现代环境下只能说出最愚蠢的感觉。 我只能想象革命时代的农民会怎样做。 BuddyPoke 甚至可以成为十年前存在的东西吗？ 我要问的原因是要处理所有这些用户，BuddyPoke 需要以非常低的成本实现巨大的扩展规模。 如果您必须在数据中心中构建自己的 colo 站点，那么 BuddyPoke 是否可以经济地运作？ 他会得到资金进行扩建吗？ +在这种新的机器人时代似乎很自然，不是吗？ 我还是这么想。 没有那么多（到目前为止），但是稍后会更多。 -BuddyPoke 通过非常巧妙的策略和服务组合来工作。 通过戴夫的讲话可以明显看出，这些都是非常有意识的策略。 Dave 谈论了很多有关在功能上转移到不同位置以最小化成本，选择技术以最小化成本，同时又保持足够高的性能以使用户可以继续戳的技术。 +我认为 Probot 足够有趣，因为它是一个程序员（我）如何使用当今的基础架构可以完成很多工作的一个很好的例子。 -## 一般经验教训 +所有这些新颖的云/无服务器/服务内容实际上都可以工作。 我能够以相对可扩展，可用和负担得起的方式对跨越 Messenger，Slack 和 Web 的系统进行编程，同时只需最少的开发。 -在获得 GAE 的具体建议之前，戴夫做了一些有趣的一般观察： +过去，担心 VPS 限制，开车前往 Colo 站点检查有问题的服务器，甚至担心容器/虚拟机群集自动扩展的日子已经一去不复返了。 至少对于许多用例而言。 -1. BuddyPoke 的 GAE 成本很低。 我试图找出实际成本是多少，因为有些人报告的成本高于预期，而我想知道他的经验表明了什么。 没有人会回答这些类型的问题，戴夫也不例外。 他确实说过，他为每个客户支付的费用不到一美分，但是我不确定这些单位。 每年一分钱？ 每次手术？ 没有意见 ：-） -2. GAE 的持久性即服务模型的吸引力在于它的简单性。 Dave 说他是 3D 图形人员，而不是基础架构人员，因此他不想弄乱系统的那部分。 这是 GAE 的最佳选择。 -3. BuddyPoke 的大部分成本用于内容交付。 BuddyPoke 的主要应用是必须提供 Flash 文件。 这些成本远远高于运行实际应用程序的成本。 Dave 正在研究 Rackspace 的文件服务。 GAE 对于访问内容具有较高的故障率，这在返回化身时是可以接受的，但对于加载初始图像而言并不是很好。 -4. 您不能天真地为 GAE 编码。 为了获得性能，您必须选择最适合 GAE 工作方式的策略。 +多年的编程经验和撰写此博客无法避免犯错误。 在此过程中，我犯了很多愚蠢的愚蠢错误，但是我对最终的想法感到满意。 -## Google App Engine 课程 +这是 Probot 的工作方式。... -以下是 BuddyPoke 用于在 Facebook 和 Google App Engine 上扩展的一些策略： +## 平台 -1. 使用浏览器的 CPU。 这些 CPU 周期是免费的，而您可以在 GAE 中付费。 对于 BuddyPoke，这意味着：1）在 Flash 客户端中执行计算 2）等待客户端中的 Facebook 操作，而不是 GAE。 -2. 设置最大值。 而不是允许用户上传大量图标，例如，最多设置六个左右，否则数据存储和您的成本将爆炸。 -3. [Memcache](http://code.google.com/appengine/articles/scaling/memcache.html) 一切都是为了解决数据存储问题。 -4. 将[分片计数器](http://code.google.com/appengine/articles/sharding_counters.html)用于安装计数之类的统计信息。 否则，争用问题将使一切陷入困境，并激增您的配额。 -5. 发送大量[电子邮件](http://code.google.com/appengine/docs/java/mail/)会占用大量 CPU。 使用任务队列或 cron 作业对它们进行批处理。 -6. 将多个 [appspot](http://code.google.com/appengine/docs/whatisgoogleappengine.html) 应用程序用于不同功能，而不是一个大型应用程序。 例如，错误将发送到特定的错误应用程序。 这样可以使日志和其他统计信息按功能分开。 -7. 将表分为两部分：主模型和附加信息模型。 数据存储看跌期权是您最大的成本，因此您需要尽一切可能使成本最小化。 在主模型中，仅使用键控访问，不使用索引，并且不保留其他字段。 获得将很快而认沽将变得便宜。 编写额外的字段会浪费时间和金钱。 因此，用户模型的“加入日期”字段不属于主表。 它不经常使用，因此将这种数据放入附加的信息模型中。 将您的索引放在该模型上并对其执行查询。 因为附加信息模型具有索引，所以它将导致更多的同步写入，这将花费更多，更慢，并且如果您需要频繁编写此模型，则可以备份处理。 -8. 为了最大程度地减少数据存储跳，请使用批处理获取和放置。 +* 无服务器：AWS Lambda -从表面上看，BuddyPoke 看起来很简单，但是在引擎盖下却存在着一些复杂的策略。 在使其规模和性能最大化的同时将成本最小化并不明显。 谁在做什么，何时，为什么以及如何做让人费解。 当然，这是越来越多的应用程序将来会发现自己使用的一种方法。 +* Web 主机：S3 上的静态站点，单页应用程序 -## 相关文章 +* 语言：Javascript /节点 -1. [谈话的 Ustream 视频](http://www.ustream.tv/recorded/4118948) -2. [在 App Engine](http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html) 上构建可扩展的复杂应用程序，作者 Brett Slatkin -3. [Google App Engine-再看](http://highscalability.com/blog/2009/2/21/google-appengine-a-second-look.html) -4. [Google App Engine](http://www.youtube.com/watch?v=0zz-oSrWfj0) 上的 BuddyPoke +* API：API 网关 -我要补充一点，使用 Guido 的新 AppStats 库可以使您获得有关数据存储性能的真实数字，等等。没有这种自省，这实际上只是一个猜测游戏。 内省还可以让您找到那些地方-哎呀！ -您不小心从 for 循环或其他一些容易解决的问题中调用数据库。 +* DNS：Route53 -TOS 允许第 6 点吗？ 好像没有 +* CDN：CloudFront -http://code.google.com/appengine/terms.html +* 用户登录名： [Cognito](https://github.com/aws/amazon-cognito-identity-js) -4.4。 您不得开发多个应用程序来模拟或充当单个应用程序，或以避免产生费用的方式访问服务。 +* SSL 证书：让我们加密 -我也想知道西尔万，但是我猜是因为他们是分开的服务，所以还可以。 Google 家伙就在那儿，因此一定不能违规。 +* 服务器：EC2，t2.small，Ubuntu -我会问这点给 Google（freenode chat） -对我来说，TOS 很清楚：不同的服务，但最后只有一个应用程序：禁止使用。 +* 信息库：GitHub -否则，创建多个应用程序太容易了，或者我们可以将它们称为“服务” :) --图像的“一项服务” --CSS，js，...的“一项服务” --503、404，...的“一项服务” --发送邮件的“一项服务” --计算...的“一项服务” ... --等，... +* 源代码控制：Git -并最终低于配额。 +* 付款：贝宝 -我认为 BuddyPoke 可以，因为它是主要的应用程序，显示“成功”很重要。 +* Slackbot： [Botkit](https://github.com/howdyai/botkit) -不错的提示，我将其中一些应用到我的应用中。 很快，我还将发布一些有关应用程序可扩展性的新技巧。 但是，GAE 错误级别如此之高... +* 队列：SQS ->我试图找出实际成本是多少，因为有些人报告的成本高于预期，并且我想知道他的经验如何。 没有人会回答这些类型的问题，戴夫也不例外。 +* 备份：AWS Data Pipeline，每周将生产数据保存到 S3 -我从来不明白这一点。 我将自由地告诉任何询问每月运行 reddit 的费用的人。 +* 数据库：DynamoDB -杰里米，每个月运行 Reddit 多少钱？ +* 节点进程管理器： [PM2](http://pm2.keymetrics.io/) -我也对运行 Reddit 花费多少感兴趣。 请告诉我，杰里米。 +* SSL 终止：Nginx -哦...看来杰里米从未回答... \ No newline at end of file +* Web 框架：jQuery，Bootstrap + +* 开发平台：MacBook Air + +* 本地测试 Web 服务器： [http 服务器](https://www.npmjs.com/package/http-server) + +* 测试隧道： [Ngrok](https://ngrok.com/) + +* SQS 轮询： [平方消费](https://www.npmjs.com/package/sqs-consumer) + +* 日志记录：CloudWatch + +## 起源故事 + +我的妻子 [琳达·科尔曼](http://www.possibility.com/Lgc/AcctRes.html) 是一名注册代理，这意味着她是一位了不起的税务会计师，并且在会计专家中都很有经验。 她有一个网站 [BizTaxTalk](http://biztaxtalk.com/) ，在这里她为人们的税收问题提供了很好的答案：免费。 她有很多问题。 有真正问题的人需要帮助，很难找到可以回答这类问题的人。 + +您可能会想像它变得势不可挡。 她最终不得不放弃 BizTaxTalk，因为它占用了她太多的时间。 + +我想为什么不通过它获利？ 琳达可以回答人们的问题并获得报酬。 双赢。 我知道这种类型的质量检查网站不是新手，但机器人程序是解决此问题的新方式，应该是处理此类信息交换的一种很好的方式。 使用文本可以非常方便地异步处理问答流程。 + +因此，Probot 建立了一个双面市场。 有问题的用户（例如约会服务）与能够回答其问题的主题专家（称为 Pro）相匹配。 Probot 处理消息的匹配，计费和协调。 + +尽管我显然会从税务和会计问题入手，但最终可以吸引更多的主题专家，并且话题数目也有所增加。 这就是我编写代码的方式。 它可以轻松扩展以处理新主题和问题树。 + +这就是我要建立的。 + +## 架构 + +*继续阅读* 。 这是一遍又一遍关于 HS 的建议。 那就是我所做的。 我有在 Node 上使用最出色的 [Botkit](https://github.com/howdyai/botkit) 制作 Slackbots 的经验，因此我就从这里开始。 + +我也有使用 AWS Lambda 来开发 Alexa 技能的经验，并且不想管理任何东西-多年玩 sysadmin 就足够了-所以我选择了 AWS。 如果 Google Cloud Functions 是 GA，那么我可能会选择使用 Google Cloud。 + +以下是我们将介绍的所有主题： + +* ProbotService Lambda 函数 + +* Slackbot + +* Messengerbot + +* 网站 + +* PayPal 集成 + +* 测试 + +* 采纳 + +* 获得的经验教训 + +## ProbotService Lambda 函数 + +这是实现 Probot Service 后端的 AWS Lambda 函数。 大多。 这也是我许多愚蠢错误的根源。 让我解释。 + +我为 Slack 编写的第一个 Probot 机器人用于 Slack，并且取得了一些进步，但是 Slackbot 在 EC2 实例上的 Ubuntu 进程中运行。 + +我犯的一个大错误是不首先使用 API​​。 我的大部分职业生涯都是建立另一种消息传递协议。 是我做的吗？ 当然不是。 + +我对所有机器人逻辑进行了编程，因此可以直接在 Slackbot 流程中执行。 这是可能的，因为 AWS 有一个漂亮的 Node API，可以访问 DynamoDB，SQS，Lambda 和其他 AWS 服务。 因此，所有 AWS 访问都直接用 javascript 编码。 效果很好。 没问题 + +当我需要制作 Web 客户端时出现了问题。 嗯，在相同的代码也几乎可以在 Web 客户端中正常工作的意义上，这并不是问题。 真酷。 因此，我浪费了很多时间来建立 Slack 和 Web 客户端可以共享的通用库。 但是我对我的数据库访问代码可以在 Web 上看到的想法感到非常不舒服。 对于 Intranet 服务，我不会担心，但按我的喜好显示数据结构的攻击面太大了。 + +我犯的另一个大错误，也与不首先创建 API 有关，是因为人们对 DynamoDB 在数据库更改时将新值和旧值传递给 Lambda 函数的能力深感兴趣。 我所做的是像状态机一样触发逻辑。 例如，如果旧记录说状态为 PENDING，而新状态为 ASSIGNED，则触发 PENDING 到 ASSIGNED 的转换。 它有效，我认为它真的很聪明。 问题在于，面对许多无法移动状态但仍触发 Lambda 函数的操作，它过于脆弱。 + +解决这两个问题的方法是构建一个 API，我使用 Lambda 做到了。 我选择不使用 API​​网关，因为直接从 Node 调用 Lambda 函数非常容易。 API 网关会增加延迟，复杂性和成本。 也很难使用。 从 HTTP 请求转换参数并将其映射到 Lambda 调用对于任何复杂的事情来说都是非常接近魔术的过程。 回复相同（反方向）。 如果将来需要使用公共 API，则可以重新考虑该决定，但是直接使用 Lambda 是很简单的。 必须更改所有 Slack 和 Web 代码才能使用新的 API。 真痛苦 + +### 如何构建无服务器 API？ + +下一个决定是如何构建 API？ 每个 API 调用都映射到一个单独的函数吗？ 还是将功能归为一个入口？ 还是可能有多个入口点？ + +我选择了一个入口点。 之所以采用这种方法，是因为我不想使用框架来管理 Lambda。 我想知道所有东西如何连接在一起，框架包含很多魔术。 因此，我创建了一个 zip 文件，并使用 AWS 控制台将其上传到 Production 或 Test。 将来，我将使其自动化，但现在可以正常使用。 + +使用单个入口点时的一个问题是如何复用函数调用？ 我选择模仿 [JSON-RPC](http://www.jsonrpc.org/specification) ，这些在过去我已成功用于服务器应用程序。 + +请求包装在 JSON-RPC 负载中。 使用“ method”属性指定要调用的方法，并使用“ params”属性传递任何参数。 ProbotService index.js 文件解压缩 JSON-RPC 请求并调用正确的方法。 看起来像： + +> 如果（request.method ===“ giveAnswerToUser”）{ +> +> var op = new QuestionImpl（appcfg）; +> +> op.giveAnswerToUser（request.params，function（error，data）{ +> +> 返回 sendResponse（错误，数据，请求，回调）； +> +> }） +> +> } + +我以标准的 RPC 方式创建了一个名为 ProbotService 的存根对象，该对象使从客户端代码调用 Lambda 函数变得更加容易。 例如： *service.getQuestion（id，callback）*格式化正确的 JSON-RPC 结构，调用正确的 Lambda 函数，并在返回回复时调用回调。 + +### 共享代码 + +我选择不在 Facebook Messenger 机器人代码中调用 ProbotService Lambda。 而是，服务库代码与 Messenger 代码打包在一起并直接调用。 这是一种代码共享方法。 在 ProbotService 和 Facebook Messenger 之间共享相同的基础代码。 + +原因是 Facebook Messenger Webhook 调用通过 API 网关调用，该 API 网关调用 Lambda 函数。 使用 ProbotService 还会调用 Lambda 函数。 因此，将在另一个 Lambda 函数中调用 Lambda 函数。 这可以正常工作，但最坏的情况是延迟比我希望用户体验到的要高，因此我选择通过共享代码来删除跃点。 我仍然不确定这是否是最好的决定，但是它确实有效，并且 Messenger 机器人的响应时间让人感觉很快。 + +由于 Slackbot 是在自己的进程中运行，因此没有多余的跃点，因此使用 ProbotService 是正确的选择。 Web 客户端代码中也使用了 ProbotService，因此不会泄漏任何内部详细信息。 + +### ProbotService API + +以下是 Probot API 中的一些功能。 我不会使用 Swagger 之类的文档。 + +* updateFromPaypalWebhook + +* getQuestion + +* GiveAnswerToUser + +* GiveAnswerToPro + +* askQuestionOfUser + +* cancelQuestion + +* acceptProAnswer + +## Slackbot + +![](img/40070da02aed39af548489071241ab44.png) + +### 机器人样式 + +对机器人进行编程时，您必须做出的决定之一是：您想要对话式 AI 风格机器人还是结构化命令驱动风格机器人。 + +我采用了结构化的命令驱动方法。 用户选择一个问题主题，然后机器人将引导他们通过问题树收集 Pro 回答此类问题所需的数据。 例如，对于纳税申报表，您需要知道它是哪一年，是个人还是公司，是否是公司的实体类型（合伙企业，C-Corp 等），等等。 + +AI 风格很性感，但如果那不是您的事，那真的很难做得很好。 因此，我想出了一种描述与用户的对话的方法，该对话可以针对每个问题进行定制。 实际上，我提出了几种不同的对话描述符解决方案，但我对其中任何一个都不满意。 这是 Slack 的样子： + +> probot.machine.add（“ ask-return-type”，{ +> +> 操作：probot.machine.askFromOptions， +> +> 选项：[“个人”，“业务”]， +> +> 显示：[“个人”，“业务”]， +> +> 问题：“在回答税收问题时，帮助您的专家了解报税种类会很有帮助。”， +> +> sayOnAccept：“知道了。您选择了 _ {response} _ 选项。”， +> +> 答案：功能（机器，cmd，答案，下一个）{ +> +> console.log（“ ask-return-type：answer：” + answer）; +> +> probot.dto.setReturnType（answer）; +> +> if（answer ===“ individual”） +> +> 的 cmd.next =“询问税年”； +> +> 其他 +> +> cmd.next =“询问实体类型”; +> +> next（null）; +> +> }， +> +>    }) + +我对 Messenger 采取了完全不同的方向。 我也很讨厌这种方式。 + +### 松弛主机 + +使用 Slack 时，webhooks 可以用于实现 Slack 命令，但是对话风格要求代码在流程上下文中运行。 因此，我建立了一个没有任何冗余的小型 EC2 实例。 由于我不希望用户在 Slack 上不断与 Probot 互动，因此我认为停工时间不会造成任何伤害。 所有状态都将在 DynamoDB 中，因此不会丢失任何内容。 弹性 IP 用于访问主机。 + +*保持简单，不要使事情复杂化* 。 关于 HS 的另一个很长的课程。 如果有人最终使用您的系统，则可以稍后再做所有花哨的工作。 + +[PM2](http://pm2.keymetrics.io/) 是出色的 Node 进程管理器，用于在 Slack 进程死后重新启动它。 PM2 还管理日志并执行其他一些精美的操作。 Route53 会 ping 通该过程，并在出现任何问题时向我发送电子邮件。 够好了。 + +Botkit 完成了许多繁重的工作。 它处理程序和 Slack 之间的所有协议工作，同时为身份验证，进行对话之类的事情提供了许多方便的抽象方法。 + +### 互动消息 + +在我完全完成 Slackbot 实现之后，Slack 引入了用户使用按钮而不是输入文本进行选择的功能。 由于我还没有发布任何东西，所以是时候进行更改了。 这些按钮确实使用户更容易。 问题在于按钮需要您的进程实现 HTTPS Webhook，以便 Slack 可以通过按下哪个按钮的信息回调到您的进程中。 这是开发流程的重大变化。 松弛的开发是很好的，以前也包含在内。 现在，您的机器人程序必须可以通过 URL 从外部进行访问。 + +在 EC2 中的生产机器上还不错。 我使用 Nginx 终止 SSL，并将请求传递给 Slackbot 进程。 这需要使用我使用“加密”的 SSL 证书。 由于必须定期更新，这是维护上的麻烦，但它们是免费的，因此请选择毒药。 + +让 Slack 通过 Comcast 路由器访问在笔记本电脑上运行的进程并不容易。 我在各种解决方案上浪费了很多时间。 很多时间。 我最终屈服了，并向 Ngrok 支付了他们的隧道服务。 像魅力一样工作。 花钱。 Slack 应该考虑能够完全在无服务器上工作。 那将是一个更清洁的解决方案。 + +### 身份和验证 + +Probot 没有尝试创建 Slack，Messenger 和网络上常见的用户。 每个都使用其环境固有的身份机制。 对于 Slack，这意味着使用 Slack 分配的团队 ID 和用户 ID。 Probot 询问用户的姓名和电子邮件地址，但不打扰身份和身份验证。 Slack 处理所有这些。 + +### 数据库 + +Slack 提供了自己的数据库抽象，用于存储团队，用户和渠道。 当 Probot 使用 DynamoDB 时，我创建了一个简单的 [适配器](https://github.com/ToddHoff/botkit-storage-dynamodb) ，该适配器允许 Slack 将其数据存储在 DynamoDB 中。 + +通常的做法是在 Slack 的数据结构中插入自己的属性。 因此，用户数据存储在 Slack 的用户对象中。 + +### 从 Pro 向用户发送消息 + +与用户对话时，使用 Botkit 发送消息就像 *bot.say（“某些字符串”）* 一样容易。 在以后的某个时间以异步方式向用户发送消息并非易事。 例如，当专业人士为用户提供答案或想要提出问题时，必须向用户提供消息。 + +我可以弄清楚如何使异步消息传递起作用的唯一方法： + +* 当团队连接到 Probot 时，将 Botkit 机器人 对象存储在内存中。 需要机器人对象才能向用户发送消息。 + +* 每个用户都与一个团队相关联，因此当出现消息时，可以找到正确的机器人对象。 + +* 来自 Pro 的所有消息都排队到 AWS SQS。 + +* Slackbot 进程使用一个名为 sqs-consumer 的漂亮软件包来轮询 SQS 以获取消息。 + +* 使用 bot 对象将消息发送给用户。 + +* 用户调用@probot 进行对话以处理消息。 该消息可能是答案，问题或状态更新。 用户可以对答案进行评分并发表评论。 他们还可以拒绝答案，这意味着用户无需付费。 我不希望别人觉得自己被人扯了。 这是 Pro 承担的风险。 尽管我不这样做，但匹配算法可以在进行匹配时利用评分数据。 + +Sqs 消费者是为什么 Node 对开发人员如此高效的一个示例。 是的，javascript 很烂。 是的，回调编程有点糟。 但是从字面上来看，我需要花五分钟的时间思考*，我需要轮询 SQS* 来找到一个好的 npm 可安装软件包并拥有有效的代码。 Node 一直在发生这种情况。 + +## Messengerbot + +![](img/96ab0db0dea30355d9828a21db9dff88.png) + +Messenger 是与 Slack 完全不同的野兽。 尽管 Botkit 支持 Messenger，但我还是决定直接向 [Messenger API](https://developers.facebook.com/docs/messenger-platform/) 进行编码，因为它比 Slack 简单得多。 这是因为作为团队协作工具，Slack 具有很多功能。 Slack 具有用于与团队，渠道，用户，组，权限，功能等一起使用的各种 API。 + +使用 Facebook Messenger 时，将通过 Webhook 接收消息，并使用 HTTP 调用发送格式化的消息。 那几乎就是您所能做的。 因此，Messenger 机器人可以完全在 Lambda 函数上运行。 如果您不关心团队的所有方面，那么 Messenger 可能是一个更好的起点。 + +回顾一下，这是 和您所知道的 咬住我的地方。 Probot 不是团队工具。 它与用户进行一对一的交互，因此所有开销都没有任何好处，并且需要很长时间才能解决。 另一方面，Slack 的员工非常乐于与他们合作。 如果您有问题，那么有技术印章的真实人将为您提供一个很好的答案。 你可以想象？ + +实际上，我一直在考虑取消对 Slack 的支持，因为没有人在使用它，而且 EC2 实例每月都要花我很多钱。 无服务器可为此类工作量赢得大量时间。 使用 Lambda，我只在人们实际使用 Probot 时付款。 + +### 简化 Messenger + +一件事立即变得很清楚，那就是必须简化 Probot 才能在 Messenger 上正常工作。 使用 Slack 时，复杂的用户交互变得自然。 在 Messenger 上，复杂的问题树根本不起作用。 + +我所做的一个简化是减少用户可以从 Pro 请求的答案类型。 在 Slack 上，用户可以要求以不同的价格快速，完整或深入地回答问题。 添加这一额外的交互层会使整个过程陷入困境，因此，使用 Messenger 时，Pro 可以提供的唯一可能的答案类型是 Quick 类型。 + +无法将简短的文本字符串发送到 Messenger 进一步增强了简短和简单的需求。 松弛搭配文字很棒。 您可以吐出文本页面没问题。 有了 Messenger，您可以发送的最大尺寸。 长字符串必须分成大块，而不是美观。 + +另一个简化是 Messenger 上，用户一次只能回答一个未解决的问题。 在网络和 Slack 上，用户可以一次打开多个问题。 回想起来，这可能也是我应该构建 Slack 的方式。 通过聊天界面管理多个悬而未决的问题很复杂。 + +这是关于 HS 的又一个很长的课程： 保持简单愚蠢 。 说起来容易做起来难。 + +### Facebook Messenger Webhook + +在 Messenger 机器人配置中，指定了一个 Webhook，Facebook 会使用用户相关事件进行调用。 Webhook 使用绑定到 Lambda 函数的 API 网关实现。 Lambda 函数是使用共享代码方法实现的。 它包含了所需的所有源代码，而不是调用其他服务。 + +Lambda index.js 文件中的启动代码负责解析来自 Facebook 的消息并正确分发。 在处理每条消息之前， startSession 被称为发送者 ID，它被用作用户 ID。 startSession 获取用户记录（如果存在），如果不存在，则请求该用户的配置文件并创建用户记录。 如果用户记录中已有问题 ID，则会从数据库中检索该问题，并创建该问题的状态机对象。 传入消息是状态机上的一个事件，它驱动消息的处理方式。 + +使用 startSession 来处理用户消息所需的所有数据均已就绪，因此无需任何较低级别的代码。 同样，在处理完一条消息后，将检查脏标志，并且如果更改了对象，则会在数据库中自动对其进行更新。 我发现这种风格使使用 Lambda 函数更加简洁。 较低级别的代码永远不必担心状态管理。 + +这是 Slack 比 Facebook 更具优势的领域。 Lambda 函数无法存储状态，因此必须激活每个状态并随每个请求将其钝化。 使用 Slack 的状态可以存储在 Slackbot 进程中，尽管如果我要重做一遍，则可能不会将状态保持在 Slack 中。 转到数据库并编辑记录并在下一个请求中提取更改非常方便。 为了使这些更改在 Slackbot 中可见，必须重新启动该过程。 + +Messenger 具有许多不同类型的消息：消息，回发，身份验证，传递确认，消息读取，帐户链接等。 消息类型有几种子类型：快速答复，文本，回声，回执，已读回执，键入，键入，等等。 + +通常，我唯一要注意的消息是与用户的交互。 所有命令源均映射为通用请求格式，并馈入 Question 状态机。 例如，当用户点击“回发”按钮，“入门”按钮，“持久”菜单或“结构化消息”时，发生回发事件。 我认为来自用户的任何纯文本输入都是为了响应我之前提出的问题。 快速回复 只是用户可点击按钮的另一种类型。 + +### Facebook 问题状态机 + +所有问题都存储在 DynamoDB 中。 每个问题都有一个属性，用于指定问题所在的当前状态。将消息标准化为通用请求格式后，将其应用于“问题”状态机，该状态机看起来像： + +> var QuestionDto = require("./QuestionDto");function FacebookQuestionSm(appcfg, startState) {  console.log("FacebookQuestionSm:startState:" + startState);  this.startState = startState;  var self = this;  this.any = {    help: {      action: FacebookQuestionSm.sendHelp,    },    getstarted: {      action: FacebookQuestionSm.sendGetStarted,    },    settings: {      action: FacebookQuestionSm.sendSettings,    },    status: {      action: FacebookQuestionSm.sendStatus,    },  ...  this.states = {    start : {      on : {        accounting: {          forward: "ask_accounting_question"        },        ask_accounting_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_question",          data: { type: "accounting", msg: "Great choice, I see you want to ask an accounting question." }        },        ask_individual_tax_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_tax_year",          data: { type: "tax", returnType: "individual",                   msg: "Great choice, I see you want to ask a tax question for an individual."           }        },        ask_business_tax_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_entity_type",          data: { type: "tax", returnType: "business",             msg: "Great choice, I see you want to ask a business related tax question."           }        }      }    },    ask_tax_year : {      action: FacebookQuestionSm.sendTaxYearQuestion,      on : {        text: {          verify: FacebookQuestionSm.verifyTaxYear,          action: FacebookQuestionSm.saveTaxYear,          next: "ask_question"        }      }    }, +> +>     ... +> +> } +> +> this.on = function（appcfg，userid，request，next）{ +> +> console.log（“ on：userid：” + userid +``“ request：” + JSON.stringify（request））; +> +> } + +上的 *方法接受请求并将其应用于状态定义。 这可以正常工作，但是处理用户可以与机器人进行交互的所有方式都会使代码看起来有些骇人。* + +### Identity and Authentication + +与 Slack 一样，Facebook 提供了专门用于 Messenger 的用户 ID，而我只是使用该 ID。 它不是真实的 Facebook 用户 ID，因此您不能使用 graph API 来获取大量用户信息。 该 ID 与问题一起存储，因此可以将答复直接发送给用户。 + +### Database + +与 Slack 的 Facebook 数据库 API 等效，因此用户数据存储在 DynamoDB 中 Facebook 特定的用户表中。 + +## 网站 + +![](img/f2c70cd017c86d78ddbcadea563ee25a.png) + +[Probot.us](https://probot.us/) 是 S3 上托管的单页应用程序。 作为单页应用程序，所有操作均使用 Slack 使用的相同 ProbotService API 完成。 使用 S3 的优点是我无需管理任何事情。 它是一个与其他网站非常相似的网站，因此我不会在此进行过多介绍，但有一些主题值得注意。 + +### 电子邮件崩溃 + +您是否曾经做过一些您最终不会做的事情，但还是成功了？ 这是另一个浪费时间的大错误。 毫无疑问，我不太擅长制作网站。 我希望这可以解释为什么我真正尝试完全避免制造一个。 + +我所做的是通过电子邮件使所有 Pro 交互工作。 问题将通过电子邮件发送给专业人士。 专业人士会通过电子邮件答复并回答问题。 电子邮件中的关键字使它可以解析和提取数据。 用户没有注意到差异，因为他们仍然会使用 Slack 或 Messenger。 + +这是流程：Probot 向 Pro 发送了电子邮件。 例如，将问题分配给专业人士时，他们将收到一封包含该问题的电子邮件，有关用户的信息以及将电子邮件映射回该问题所需的一些簿记属性。 专业人士会回覆他们的回应，并确保将文字插入正确的位置，以便可以正确解析。 AWS 收到了 Pro 的回复并将其保存到 S3 中。 这导致了 Lambda 函数被调用。 该功能将解析电子邮件，提取所有数据，并相应地更新用户。 + +尽管配置很麻烦，但实际上确实有效，并且编写代码很有趣。 只有我的测试专家讨厌它。 只是讨厌它。 当然，他们做到了，这对他们来说很糟糕。 因此，我最终制作了 Pro 仪表板，以管理我一直知道自己必须解决的所有 Pro 问题。 我还添加了一个收件箱，以便用户可以在网络上提问和管理问题。 同一网站还为 Slack 用户充当着陆页，以便他们可以将 bot 安装到他们的团队中。 + +### [HTG0 BC] + +尽管我已经在 Golang 中使用了完整的用户注册系统，但我希望将所有内容保留在 Node 中。 我决定重试一下，而不是重新发明轮子。 我不想对用户密码的安全性负责，Cognito 可以处理所有这些。 使用起来很棘手，这里的有一些奇怪的问题要弄清楚。 示例代码和文档可能会更好。 但是我最终得到了所有典型的流程-注册，忘记密码，更改密码，重新发送验证码，输入验证码等。 这并不容易，但是似乎可以可靠地工作。 + +### 节点和浏览器之间共享代码 + +这是我犯的另一个错误：我不打算在 Node 和浏览器之间共享代码。 到我意识到可以共享很多代码的时候，采用另一种模块哲学已经太费力了。 我确实共享代码，但是在包含导致在两种情况下都不起作用的依赖项的代码时，我必须非常小心。 + +## PayPal 集成 + +我选择 PayPal 是因为我发现它们的 API 是可以理解的，其仪表板是可以使用的，并且其文档是可以使用的。 支持速度很慢，但通常会有所帮助。 + +当用户接受专业人士对其问题的回答时，付款状态机将启动。在 ProbotService 中，PayPal API 用于创建发票，该发票由 PayPal 发送到用户的电子邮件地址。 通过 PayPal，您可以配置一个 Webhook 来使用发票相关事件。 Webhook 使用绑定到 Lambda 函数的 API 网关。 + +当 Lambda 函数接收发票事件时，它将在事情发生时通知用户和 Pro。 + +* 松弛：通过前面描述的 SQS 机制通知用户。 专业人士会收到一封电子邮件，告知他们应该前往仪表板了解详细信息。 绝不会通过电子邮件发送任何敏感信息。 + +* Messenger：发短信给用户。 请注意，要在上次联系后 24 小时向用户发送消息，您必须对机器人具有特殊权限。 这并不总是容易获得的。 因此，如果您的机器人需要提前进行此类功能计划。 + +* Web：向用户发送电子邮件，并要求用户登录 Probot 以获得其仪表板上的更多信息。 + +这花了一些时间才能开始工作。 如果未调用与 Webhook 关联的 Lambda 函数，则很难理解问题所在。 绝对打开 A​​PI 网关日志记录。 您将需要它。 + +PayPal Lambda 函数使用与前面所述相同的代码共享方法。 无需进行远程 ProbotService 调用，而是直接调用代码。 + +## 测试 + +这里没什么好想的。 + +对于 API 网关，Lambda 和 DynamoDB，有所有版本的测试和生产版本。 根据配置在运行时选择使用哪个。 + +该网站有测试和生产版本。 为了测试它们，我只使用所有功能。 使用 *aws s3* 命令行将文件从开发环境复制到 S3。 对于本地开发，将 http-server 用作 Web 服务器，并且可以通过 localhost 测试所有功能。 + +PayPal 具有测试和生产配置选项。 每个都分别指向测试和生产网络挂钩。 PayPal 具有在调用 Webhooks 时记录的日志，这在调试时很有用。 不幸的是，事件不是实时发送的，因此您必须等待事件发送和日志出现。 + +对于 Slack，有一个单独的机器人，用于测试和生产。 每个都分别指向测试和生产网络挂钩。 Messenger 也是一样。 除了将测试版本和生产版本视为完全不同的漫游器之外，我没有其他更清洁的方法。 + +对于本地开发，Slackbot 在开发计算机上运行。 Ngrok 用作隧道，因此 Slack 可以向该进程发送交互式消息。 使用网站的测试版本将测试机器人安装到团队中。 它具有正确的应用程序令牌，可以识别机器人的测试版本。 安装测试机器人后，您可以通过 Slack 与该机器人对话。 + +对于本地开发测试，通过共享代码使 Lambda 代码变得更加容易。 唯一可以调用的外部服务是其他人的服务，而不是您自己的服务。 因此，要进行测试，根本不需要将代码上传到 Lambda。 Lambda 函数中使用的相同代码可从可从命令行执行的脚本中调用。 为您 API 中的每个函数创建一个相应的脚本，并且可以在本地对其进行完全调试。 + +Messengerbot 的本地开发测试比较棘手，因为将消息发送到 bot 时，消息会显示在 Messenger 中。 当您点击按钮时，回复将返回到您的测试网络挂钩。 据我所知，尚无干净的方法可以以可单元测试的方式进行此操作。 我所做的是将 Bot 的测试版本安装到 Messenger 中并记录了用户 ID。 在为每个方案制作测试脚本时，在运行时选择要使用的用户 ID，测试版本或生产版本。 如果方案涉及要求用户回答问题，则将从脚本中发送问题。 然后，您转到手机上，然后使用测试机器人进行回复。 答复将转到您的测试网络挂钩，以便代码可以正常运行。 我对这种方法不是很满意，但是这种方法行之有效，而且比通过 Messenger 进行的所有测试都更快。 + +总有一天应该从 GitHub 安装所有内容，但是今天不是那天。 + +## 采纳 + +吸收不好。 我希望随着税收季节临近活动的到来。 问题的一部分在于，作为一名程序员，我几乎迷上了营销。 我正在尝试 Messenger Bot 广告，但是这些广告无效。 + +使用尝试使漫游器不转化的渠道隐喻用户，他们在实际转化并提出问题之前已经保释。 可能存在信任问题。 他们不知道他们在问谁或将得到什么样的答案。 我尝试在网站和漫游器页面上解决这些问题。 例如，如果您不喜欢答案，则无需付款，因此无风险。 + +一种可能性是人们并没有真正使用 Messenger 机器人，并且对于此类应用程序的实验失败。 + +另一个可能性是我的机器人不是很好。 完全有可能的事情。 + +如果您有任何想法或疑问，请告诉我。 + +## 获得的经验教训 + +* **不要做您所知道的**。 在盲目做您知道的事情之前，先环顾四周，看看是否有更好的选择。 + +* **API 优先**。 为您的服务提出一个抽象并将其实现在一个地方。 当您必须在不同的平台上实现另一个客户端时，您将感激不尽。 + +* **DTO 首先**。 我犯了通过代码库传播数据库访问代码的错误。 只需创建一个数据传输对象并将代码从一开始就集中在一个地方即可。 然后，可以轻松打包和重用它。 + +* **一次**。 要做的聪明的事情是必须使一个简单的机器人来测试这个概念。 我当时知道这一点，但是我真的很想看看在所有三个平台上开发一个机器人的感觉。 那个决定的人是个白痴。 + +* **吻**。 这么容易说，很难做到。 + +* **提前计划共享节点和浏览器模块**。 一旦已经编写了很多代码，就很难进行改造。 + +* **代码共享**。 在 Lambda 函数之间共享很好的模块化库代码在实践中效果很好。 它使从命令行进行测试变得容易。 + +* **无服务器作品**。 由于种种原因，每个人都在涌动。 它可以让一个人完成很多工作。 您有发展机会，但管理起来却少得多。 对于不可预测的工作负载，它便宜得多且可扩展性更高。 我不能说工具很烂，因为我选择不使用任何工具，但是我们仍然有一种方法可以弄清所有这些在实践中是如何工作的。 + +* **事件> API** 。 使用 webhooks 使用 Serverless 将系统连接在一起非常强大。 相比之下，站起来放一个盒子并运行一个过程来使用 API​​似乎很原始。 + +像大多数课程一样，回想起来，大多数这些令人沮丧的头脑震撼显而易见，但是我想这就是为什么它们是课程。 + +看起来很酷 + +哇听起来真酷 您是独自建造的吗？ 花了多少时间？ + +是的，只有我。 这花了一个令人尴尬的时间:-) + +@ToddHoff 几乎所有编程都可以，尤其是在您必须学习新知识的情况下，这几乎总是这样，因为有各种各样的工具可以完成工作。 + +您的帖子非常有趣。 我正在尝试从中学习。 但是我不明白一件事。 + +您提到了为 lambda 创建单个入口点，然后将请求路由到单独的函数。 但是，如果没有 API 网关，请求如何首先到达 lambda？ + +嗨，杰克， + +可以通过 API 直接调用 Lambda 函数。 他们不需要通过 HTTP。 我大致是这样做的： + +包括适用于您的环境的 AWS API，对于 Web 或节点中的 AWS API 有所不同。 + +appcfg.AWS = require（“ aws-sdk”）; +appcfg.DB =新的 appcfg.AWS.DynamoDB（）; +appcfg.DBCLIENT = new appcfg.AWS.DynamoDB.DocumentClient（）; +appcfg.LAMBDA = new appcfg.AWS.Lambda（）; +appcfg.SES =新的 appcfg.AWS.SES（）; +appcfg.SQS = new appcfg.AWS.SQS（）; + +函数 ProbotService（appcfg）{ +this.id = 0; +var self = this; + +this.invokeLambda = function（method，params，next）{ + +var payload = { +method：method， +params：params， +id：self.id ++ +} + +var params = { +FunctionName：appcfg.Amazon.ProbotService， +Payload：JSON.stringify（payload） +} + +appcfg.LAMBDA.invoke（params，function（error，response）{ +if（error）return next（error）; + +var payload = JSON.parse（response.Payload）; +如果（payload.error）返回 next（payload.error）； +如果（payload.errorMessage）返回 next（new Error（payload.errorMessage））； + +返回 next（空，payload.result）； + +}）//调用 + +} // invokeLambda + +嗨，托德， + +感谢您的广泛回应！ + +实际上，我知道如何调用 lambda。 我从您调用它的地方很好奇。 看来您可能是从客户端调用它的？ + +PS。 我刚刚开始学习 nodejs。 因此，无论我说什么，都可能变得毫无意义。 + +是的，无论是在 Slack 上的 nodejs 内，还是 lambda 本身的 nodejs 内，网站上的客户端都是如此。 尽管几天前我关闭了 slackbot。 太昂贵了，无法继续运行。 + +只需为环境添加正确的库并正确配置即可。 + +在网上： + +<脚本 src =“ js / aws-cognito-sdk.js” > < / script > +<脚本 src =“ js / amazon-cognito-identity.min.js” > < / script > +<脚本 src =“ https://sdk.amazonaws.com/js/aws-sdk-2.3.5.min.js” > < / script > + +在 slack 和 lambda 上，它们将 sdk 安装到 node_modules 中，并且由于用户看不到环境，因此可以从文件加载配置。 +var AWS = require（'aws-sdk'）; +AWS.config.loadFromPath（'cfg.json'）; +appcfg.AWS = AWS; + +我保持对 appcfg 中所有服务的访问权并将其传递。 这样，您可以在启动时以特定于环境的方式配置所有内容。 + +现在，您可以在所有环境中使用相同的 lambda 调用代码。 + +this.giveAnswerToPro = function（answer，next）{ +return self.invokeLambda（“ giveAnswerToPro”，答案，下一步）; +} // GiveAnswerToPro + +这是我的模块问题出现的地方。您必须小心在每个环境中包含的内容。 在网络资料中包含一个在 nodejs 中不可用的模块，您已将其破坏。 + +这很酷。 您是否考虑过在营销中使用会计师的图片和/或个人资料？ 甚至有照片。 主页上显示“真实的会计师”，因此看到它可能会让人放心。 + +Hi Todd, + +感谢您的回复！ + +我知道可能要问很多。 但是，如果您不介意，会介意开放源代码并与我们共享吗？ +对像我这样的人进入 nodejs 和 aws 领域确实很有帮助。 + +谢谢。 + +我得考虑杰克。 我不确定如何将我的东西充分分离出来。 + +有趣的文章。 \ No newline at end of file diff --git a/docs/208.md b/docs/208.md index e94269c..d321da7 100644 --- a/docs/208.md +++ b/docs/208.md @@ -1,51 +1,75 @@ -# 全球范围扩展的 10 个 eBay 秘密 +# AdStage 从 Heroku 迁移到 AWS -> 原文： [http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html](http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html) +> 原文： [http://highscalability.com/blog/2017/5/1/the-adstage-migration-from-heroku-to-aws.html](http://highscalability.com/blog/2017/5/1/the-adstage-migration-from-heroku-to-aws.html) -您甚至不必出价，eBay 杰出建筑师 Randy Shoup 就免费提供了有关如何扩展 eBay 的[演示文稿](http://www.hpts.ws/session9/shoup.pdf)。 Randy 在本演示文稿以及本文结尾处列出的其他演讲中做了出色的工作，成为可伸缩性原理的核心。 与关注特定技术堆栈有关，更多的是关于事物如何协同工作的想法。 +![](img/222acfea60c08f75dd8f5c824f121167.png) -### 令人印象深刻的统计 +*这是 AdStage 网站可靠性工程负责人 [G Gordon Worley III](https://www.linkedin.com/in/gworley3/) 的来宾[重新发布](https://medium.com/adstage-engineering/migrating-from-heroku-to-aws-our-story-80084d31025e)。* -如果您不确定，eBay 很大，有很多：用户，数据，功能和更改... +我在 2013 年秋季加入 [AdStage](https://medium.com/@adstage) 时，我们已经在 Heroku 上运行了。 这是显而易见的选择：超级容易上手，比全尺寸虚拟服务器便宜，并且足够灵活以随着我们的业务发展。 成长，我们做到了。 Heroku 让我们仅专注于构建引人注目的产品，而不会分散管理基础结构，因此，到 2015 年末，我们同时运行了数千个 dynos（容器）以跟上客户的发展。 -* 全球超过 8900 万活跃用户 -* 1.9 亿种商品在 50,000 个类别中销售 -* 每天超过 80 亿个 URL 请求 -* 每季度数百个新功能 -* 每天大约有 10％的项目被列出或终止 -* 在 39 个国家/地区提供 10 种语言 -* 24x7x365 -* 每天 700 亿次读/写操作 -* 每天处理 50TB 的新增量数据 -* 每天分析 50PB 数据 +我们需要所有这些功能，因为在后端，我们看起来很像[细分](https://medium.com/@segment)，并且像它们一样，我们的许多成本[与用户数量](https://segment.com/blog/the-million-dollar-eng-problem/)成线性比例。 以 25 美元/ dyno /月的价格计算，加上其他技术成本，到 2016 年中期，我们的年度基础设施支出将突破 100 万美元，而这占了 COGS 的很大比例，因此需要数年才能实现盈利。 坦率地说，这种情况是不可持续的。 工程团队开会讨论了我们的选择，一些快速计算表明我们为 Heroku 的便利每月要支付超过 10,000 美元，而类似资源将直接在 AWS 上花费。 如果我们从 Heroku 迁移，这足以证明工程师全职从事基础架构工作，因此我的任务是成为第一位运营负责人，并带头进行向 AWS 的迁移。 -### 10 课 +这也是一个很好的时机，因为 Heroku 已成为我们最大的限制。 我们的工程团队采用了[看板](https://en.wikipedia.org/wiki/Kanban_%28development%29)方法，因此理想情况下，我们会不断产生从构思到完成的故事。 不过，当时我们正在生成大量正在进行的工作，这些工作通常会阻塞我们的发布渠道。 进行质量检查的工作很缓慢，并且经常被送回以进行错误修复。 “ [在我的计算机](https://jcooney.net/archive/2007/02/01/42999.aspx)上正常工作”的情况经常出现，但是当暴露在我们的暂存环境中时会失败。 由于 AdStage 是写在不同技术堆栈上的相互依赖的服务的复杂组合，因此每个开发人员都很难使其工作站与生产保持最新状态，这也使部署到生产和生产过程很缓慢，需要大量的人工干预 。 但是，我们在此问题上别无选择，因为我们不得不将每个服务都部署为自己的 Heroku 应用程序，从而限制了自动化的机会。 我们迫切需要找到一种替代方法，使我们能够自动化部署并为开发人员提供更早的访问可靠测试环境的机会。 -该演示文稿很好地解释了每节课，但清单是... +因此，除了通过迁移 Heroku 削减成本外，我们还需要清除质量检查约束。 否则，我可以自由地设计我们的 AWS 部署，只要它以最少的代码更改即可运行我们所有的现有服务，但我添加了一些需求： -1. **对所有内容**进行分区-如果无法拆分，则无法缩放。 按功能和数据将一切划分为可管理的块。 -2. **到处都是异步**-通过事件队列连接独立组件 -3. **自动化所有**-组件应自动调整，系统应学习并自我完善。 -4. **记住所有故障**-监视所有故障，即使零件开始出现故障也要提供服务。 -5. **拥抱不一致**-为需要在 CAP 连续性上使用的每个功能选择，没有分布式事务，可以通过谨慎的操作顺序使不一致最小化，并通过异步恢复和协调最终变得一致。 -6. **预期（R）演进**-更改是恒定不变的，可扩展性设计，应逐步部署更改。 -7. **依赖性问题**-最小化和控制依赖性，使用抽象接口和虚拟化，组件具有 SLA，消费者负责从 SLA 违规中恢复。 -8. **权威**-知道哪些数据是权威的，哪些数据不是权威的，并进行相应的处理。 -9. **数据不足-**数据驱动寻找优化机会，预测和建议，因此请保存所有内容。 -10. **定制基础结构**-最大限度地利用每种资源。 +* **简单的系统管理** ：我以前使用过 Chef 等工具，并希望避免从头开始频繁重建系统的容易出错的过程。 我想通过登录机器并运行命令来更新机器。 +* **无聊** ：我想使用已知有效的“无聊”技术，而不是尝试一些新技术来解决其问题。 我想将风险集中在业务逻辑而不是基础架构中。 +* **零停机时间** ：在 Heroku 上进行部署往往会导致我们的用户遇到“漏洞”，原因是某些用户请求花费的运行时间比 Heroku 允许的连接耗用时间更长。 我希望能够消除这些斑点。 +* **回滚** ：如果部署出现问题，我希望能够退出部署并使用最新的已知工作版本恢复服务。 +* **有限的复杂度** ：我将是唯一一个专职构建和维护我们的基础架构的人，所以我需要确定项目的范围以适应需求。 -### 相关文章 +知道 [Netflix](https://medium.com/@NetflixTechBlog) [设法通过](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)[在 AWS 上运行](http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html)数十亿美元的业务，没有比亚马逊的机器映像和自动缩放组更完美，我决定遵循他们的可靠方法，但绝对没有 意味着“性感”的方法：构建机器映像，使用它在自动伸缩组中创建实例，将其放在弹性负载均衡器之后，并将负载均衡器连接到 DNS 记录，以使我们的客户以及彼此可以访问它们。 -* [eBay 有关高扩展性的帖子](http://highscalability.com/blog/category/ebay) -* [可伸缩性最佳做法：来自 eBay 的经验教训](http://www.infoq.com/articles/ebay-scalability-best-practices)，作者 Randy Shoup -* [第 109 集：eBay 的架构原则](http://odeo.com/episodes/23259163-Episode-109-eBay-s-Architecture-Principles-with-Randy-Shoup)和 Randy Shoup，[成绩单](http://www.se-radio.net/transcript-109-ebay039s-architecture-principles-randy-shoup) +因此，我着手构建我们的 AWS 部署策略。 -我喜欢设计大型系统，但是甚至无法想象 50PB 的数据分析。 哇！ +### 成为 AWS Sumo -具有讽刺意味的是，我在 eBay 遇到与他们的搜索引擎有关的大规模后端故障的那天碰到了这篇文章。 +在对系统进行工程设计时，我喜欢花很多时间在进行设计之前先仔细考虑并测试假设。 Rich Hickey 将此称为[吊床驱动开发](https://www.youtube.com/watch?v=f84n5oFoZBc)。 -任何特殊原因，除了在内存引擎中使用 MySQL 的联接等之外，还不包括用于个人化和会话缓存的内存缓存。 +我们的办公室没有吊床，所以我使用了[相扑躺椅](https://www.sumolounge.com/)。 -@Raj，持久性将是我的猜测，为什么不谈论您提到的 memcache（d）。 +![](img/8e7035455cd1d066981cf95862e69d34.png) -“管理不可用和违反 SLA 的行为是..消费者的责任是什么？” 服务提供商是否应该尽一切可能满足 SLA 中的可用性保证？ 我认为当前 SP 在管理可用性方面做得还不够，这可能是由于它们太难/太昂贵了。 对于他们来说，退还您的钱要容易得多（或更糟糕的是，请您重新开始工作）而无需支付巨额罚款。 \ No newline at end of file +在 2016 年春季的几个月中，我思考并思考并整理了 AWS 部署系统的基础。 它的架构看起来像这样： + +![](img/0c10e55ee443acef0a7f6bd72b5472bf.png) + +它的核心是我们所谓的 AdStage 统一图片。 此机器映像用于为所有环境（从开发和测试到过渡和生产）中的所有服务创建实例。 它上面是我们所有存储库的副本以及运行它们所需的依赖项。 根据一些实例标签的值，实例可以以不同的方式出现以反映其用法。 + +例如，当一个实例以“审阅”模式出现时，所有服务及其从属数据库在该实例上一起运行并相互通信。 这样，进行开发和质量检查的工程师就可以访问运行任意代码版本的完整堆栈的隔离版本。 他们在这些评论框上所做的任何操作均不会影响登台或制作，也不会与其他评论框进行交互，从而完全消除了我们以前的质量检查/登台限制。 另外，只要审核框通过质量检查，就可以对它进行成像，然后将该图像部署到生产中。 + +之所以可行，是因为当实例以“登台”或“生产”模式启动时，它还会告知其应运行的服务。 这是由实例从其自动伸缩组继承的标签确定的，这使我们可以启动运行相同代码的实例队列，以分散客户的负载。 对于服务于 Web 请求的自动伸缩组，它们连接到弹性负载均衡器，该均衡器在我们的服务器之间平均分配请求。 负载平衡器为我们提供了一个固定点，我们可以在该固定点上平稳地交换实例，从而实现零停机时间部署，并使回滚就像将旧版本的统一映像保留在备用数据库中一样容易交换。 + +但是，我们使用的 AWS 资源无法完全协调自身，因此我们编写了一个使用 AWS API 做到的 Ruby [Thor](https://github.com/erikhuda/thor) 应用程序。 它负责启动审阅框，构建映像，然后将这些映像部署到暂存和生产环境中。 它会在将负载均衡器切换到新版本之前自动验证部署是否正常运行，如果部署完成后检测到问题，则会建议回滚。 它还使用一些巧妙的技巧来协调多个部署并锁定关键资源，以防止多个工程师破坏彼此的部署，因此任何人都可以启动部署，尽管如果这会引起冲突，它们将被停止。 + +这涵盖了我们的所有需求：成像实例使系统管理变得容易，设置无聊且被广泛使用，部署过程固有的停机时间为零，支持回滚的部署是自动化的，并且在小于 1500 的情况下并不是很复杂 而且，由于它解决了质量保证约束，并且据我们估计将节省 10,000 美元的运营支出，因此剩下的只是计划从 Heroku 到 AWS 的实时迁移。 + +### 实时迁移 + +2016 年 7 月是旧金山的典型节日。 大部分时间，雾气和寒冷的空气使我一直在里面工作，而在我们办公室对面的街道上，准备不足的游客在 [Dragon's Gate](https://www.lonelyplanet.com/usa/san-francisco/attractions/dragons-gate/a/poi-sig/383985/361858) 上拍了自拍照时发抖。 同样，因为一切都准备从 Heroku 迁移到 AWS，所以我们要做很多工作。 + +我们的客户依靠我们来管理他们的广告活动，自动化他们的广告支出并报告他们的广告效果。 当我们陷入困境时，它们又陷入了直接通过网络界面手动创建和更新广告的黑暗时代。 当我们切换到 AWS 时，他们负担不起我们离线的费用，因此我们将不得不进行实时迁移。 或至少与合理生活一样。 + +我们实施了 1 周的代码冻结，并在星期六的早晨找到了 1 小时的窗口，那时我切换了数据库和其他在运行时不易移动的服务，而 AdStage 进入维护模式。 在准备过程中，我们已经进行了登台系统的迁移，并编写了一部剧本，可用于停产。 我使用代码冻结花了一周的时间来调整 AWS 部署，以匹配 Heroku 部署。 周六上午一切似乎都很好。 我们失败了，我切断了数据库，然后重新启动了 AdStage。 我花了整整一天的时间看监视器，并靠近键盘，以防万一发生任何问题，但是什么也没做。 那天晚上我睡着了，以为一切都很好。 + +在一个 la 懒的星期天早晨之后，我开始在下午收到一些警报，提示我们的进口商正在备份。 当我们研究这个问题时，问题很快就变得显而易见：尽管名义上拥有更多的计算资源，但在某种程度上，我们在 AWS 上的 CPU 数量要少于 Heroku。 结果，我们无法跟上，并且每小时我们都越来越落后。 为了避免队列溢出，我们不得不降低导入的频率，最终我们不得不重新打开 Heroku 应用程序以与 AWS 一起运行以跟上工作量。 这与省钱相反。 + +我们发现，Heroku 一直在告诉我们一个幸福的谎言。 官方每个 dyno 仅获得 2 个 [ECU](https://aws.amazon.com/ec2/faqs/#What_is_an_EC2_Compute_Unit_and_why_did_you_introduce_it) ，但实际情况是，由于我们 Heroku 上的邻居没有充分利用它们的全部份额，我们接近了 6 个。 这意味着我们的 AWS 实例数量太少了 3 倍，尽管 Heroku 确实便宜很多！ 如果只有一种方法可以为更多实例支付更少的费用…… + +那就是我们开始使用竞价型实例的时候。 我们曾考虑过使用它们，因为它们的价格约为按需价格的 1/10，但它们存在一定的风险，因为如果您的底价低于拍卖价，它们可以随时终止。 幸运的是，这种情况很少发生，否则，自动伸缩组会为您管理点实例的复杂性。 另外，如果备份临时扩展组使用按需部署的按需实例，则很容易，如果我们暂时无法获得足够的竞价型实例来满足我们的需求，则可以通过单个命令进行扩展。 我们最终能够将约 80％的机队转换为现场实例，尽管使用的资源比原始预期多了 3 倍，但我们的成本却降低到了预期目标之内。 + +### 结论 + +除了我们对容量的意外低估外，从 Heroku 切换到 AWS 的过程也很顺利。 不过，请不要误会我的意思：这是值得做的，因为我们已经达到了将我们的一些基础设施运营纳入内部的经济规模才有意义。 如果我们不花费至少一名工程师的薪水来购买运营成本，而可以通过改用 AWS 来节省运营成本，并且如果基础架构没有成为核心能力，那么我们将坚持使用 Heroku 并让那个人（我！）来工​​作 在对我们的业务更重要的事情上。 只是由于经济和流程的变化，从 Heroku 迁移到 AWS 成为了我们的故事的一部分。 + +Heroku 在 AWS 上运行，因此您不必进行过多的迁移就可以减少中间商。 + +...或者您雇用知道如何正确运行数据中心的人员。 + +感谢您的帖子。 非常有趣，只是有几个问题：图像如何获得其初始配置？ 您提到要避免使用 Chef / Puppet 之类的东西，但是大概您仍然需要一些可重复的过程来使用初始配置来构建 AMI。 那是雷神应用程序的功能吗？ + +您应该尝试进行性能调整，例如 JVM 调整，线程池调整等，以降低基础架构成本。 + +似乎没有这么多麻烦就节省了很多。 您节省了全职人员成本，但是在 AWS 上通常需要 DevOps 成本，在 Heroku 中，Dev 团队可以解决。 放大/缩小测功机与 EC2 相比，哪一个更容易？ \ No newline at end of file diff --git a/docs/209.md b/docs/209.md index be77880..466f145 100644 --- a/docs/209.md +++ b/docs/209.md @@ -1,102 +1,101 @@ -# 为什么 Facebook，Digg 和 Twitter 很难扩展？ +# 为何将 Morningstar 迁移到云端：降低 97％的成本 -> 原文： [http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) +> 原文： [http://highscalability.com/blog/2017/8/14/why-morningstar-moved-to-the-cloud-97-cost-reduction.html](http://highscalability.com/blog/2017/8/14/why-morningstar-moved-to-the-cloud-97-cost-reduction.html) -实时社交图（人，地方和事物之间的连通性）。 这就是为什么要扩展 Facebook 很难[的原因，Facebook 技术副总裁 Jeff Rothschild](/blog/2009/10/12/high-performance-at-massive-scale-lessons-learned-at-faceboo-1.html) 说。 像 Facebook，Digg 和 Twitter 这样的社交网站要比传统网站难于扩展。 这是为什么？ 为什么社交网站比传统网站更难扩展？ 让我们找出答案。 +![](img/8afe9df981fbc1c7bfcea8286c1586d5.png) -传统网站比社交网站更易于扩展，原因有两个： +企业不会迁移到云。 如果他们这样做，那就等于承认您的 IT 团队很糟糕。 那是常识。 投资研究提供商晨星（Morningstar）正在迁移到云中，他们正变得越来越有企业精神。 他们并没有让我感到无能，他们只是不想再担心所有低级的 IT 问题。 -* 他们通常仅访问自己的数据和公共缓存的数据。 -* 一次只有 1-2％的用户在该站点上处于活动状态。 +晨星（Morningstar）的 CTO Mitch Shue 在 [AWS Summit Series 2017](https://www.youtube.com/watch?v=vhNvhJGOhSw&ab_channel=AmazonWebServices) 上做了简短的演讲。 它并没有完整的技术细节。 那不是有趣的部分。 演讲更多地是关于他们的动机，他们采取行动的过程以及他们所经历的一些结果。 尽管这更有趣，但我们之前已经听到了很多。 -想象一下像 Yahoo 这样的大型网站。 当您来到 Yahoo 时，他们可以一键获取您的个人资料记录，足以为您建立网站视图。 使用[分布式哈希方案](http://highscalability.com/blog/2009/8/5/anti-rdbms-a-list-of-distributed-key-value-stores.html)基于单个记录扩展系统相对简单。 而且由于一次只有很少一部分人同时访问该站点，因此只需较少的 RAM 缓存即可处理所有活动用户。 +我发现最有趣的是晨星作为金丝雀测试的想法。 如果晨星公司成功，那么该死的公司可能破产，我们将看到呆板的主流企业更多地采用云技术。 这是一个复制猫的世界。 这种先例为其他 CTO 提供了做出相同决定所需的掩护。 -现在想想在 Facebook 上发生了什么。 假设您有 200 个朋友。 当您打您的 Facebook 帐户时，必须同时**收集所有 200 个朋友的状态**，以便您可以查看对他们有什么新变化。 这意味着需要同时发出 200 个请求，需要将答复合并在一起，需要联系其他服务以获取更多详细信息，所有这些都需要合并在一起并通过 PHP 和 Web 服务器发送，因此您可以看到 Facebook 页面在合理的时间内。 天啊。 +在整个演讲中，最重要的想法是：迁移到云上可以节省很多成本，但是他们更感兴趣的是“创建无摩擦的开发经验以刺激创新和创造力”。 -这里有几个含义，特别是考虑到在社交网站上一次有大量用户同时在系统上（这是社交部分，人们闲逛）： +软件正在吞噬世界。 毫无疑问，晨星展望未来，看到赢家将是那些能够以最快的速度开发最好的软件的人。 他们需要更好地开发软件。 拥有自己的基础架构是技术债务的一种形式。 是时候偿还债务并开始进行真正的创新工作了，而不是苦苦挣扎。 -* 所有数据始终处于活动状态。 -* 由于每个人都已连接，因此很难对这种系统进行分区。 -* 所有内容都必须保存在 RAM 缓存中，以便可以尽快访问数据。 +这是我的谈话内容： -分区意味着您希望找到某种方法将常用数据聚类在一起，以便可以更有效地对其进行访问。 由于数据的互连性，Facebook 没有找到任何可行的集群方案。 因此，Facebook **不会对数据进行分区和非规范化，而是保持数据规范化，并在数以千计的数据库中随机分配**数据。 +## 基础设施 -这种方法需要非常快的缓存。 Facebook 使用 [memcached](http://highscalability.com/blog/category/memcached) 作为其缓存层。 所有数据都保存在缓存中，并且他们对 memcached 进行了大量修改，以加快数据传输速度并帮助其处理更多请求（所有信息都回馈社区）。 +* 全球 8 个数据中心 +* 11,318 个应用服务器 +* 7,894 个数据库实例 +* 4PB 存储 -他们的**缓存层服务每秒提供 1.2 亿个查询**，这是站点的核心。 问题是 memcached 难以使用，因为它需要程序员的配合。 腐败也很容易。 他们开发了一个复杂的系统，以使缓存层中的数据与数据库保持一致，即使跨多个分布式数据中心也是如此。 请记住，它们是在此处缓存用户数据，而不是 HTML 页面或页面片段。 考虑到他们的数据更改量，将很难使页面缓存起作用。 +## 改变的时候了 -我们在 Digg 看到了类似的问题。 例如，每当凯文·罗斯（Kevin Rose）挖掘链接时，Digg 就必须处理将更新发送给 [40,000 个关注者](http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html)的问题。 Digg 和我认为 Twitter 也采取了与 Facebook 不同的方法。 +* 想象一下在修补，升级，管理和保护 8 个全球数据中心方面所做的工作。 运行非常复杂。 +* 问题不在于他们的 IT 员工。 他们对 IT 感到满意。 +* 想要最大化人才，拥有更少的基础架构并专注于核心业务。 +* 想要简化和减少复杂性。 +* 运行数据中心并不能与它们区分开。 -Facebook 采用**按需拉动**方法。 要重新创建页面或显示片段，他们需要运行完整的查询。 为了确定您的朋友中是否添加了一个新的喜爱的乐队，Facebook 实际查询了所有朋友，以查找最新消息。 他们可以摆脱这种情况，但是由于其强大的基础架构。 +## 改变文化 -但是，如果您曾经想过**，为什么 Facebook 的朋友数限制为 5,000 个用户**，这就是为什么。 在某一点上很难实现“按需”规模。 +* 过渡到云需要来自世界各地的 1400 名技术人员的参与。 不容易做到。 +* 来自世界各地的许多半自治团体都有各自的路线图和团队目标。 +* 既定的高级技术目标：最大化人才，拥有更少的基础设施，减少复杂性，提高产品完整性，产品安全性，产品可恢复性，产品可靠性，更好的正常运行时间，更好的监控和更快的事件响应。 +* 选择目标的目的是易于重复，易于理解且不会过期。 +* 不要对自己的文化感到被动。 通过有目的的重复将这些目标融入您的文化：大量会议，博客文章，演示和对话。 +* 迁移到 AWS 支持这些目标。 -找出新功能的另一种方法是**随推即用**模型。 在此模型中，当用户进行更改时，会将其推送到所有相关用户，并且更改（以某种形式）与每个用户一起存储。 因此，当用户要查看其更新时，他们需要访问的就是他们自己的帐户数据。 无需轮询所有朋友的更改。 +## 策略：快速行动然后优化 -有了安全性和权限，要确定谁应该看到更新，可能会非常复杂。 如果用户拥有 200 万关注者，那么它的速度也可能令人惊讶地慢。 还有一个重复的问题。 存储了大量重复数据（或引用），因此这是一种非规范化方法，可能会导致一些一致性问题。 例如，在生产或使用数据时是否应征得许可？ 或者，如果数据已经被复制后又被删除了怎么办？ +* 数据收集团队最初使用提升和转换方法迁移到 AWS。 那使他们迅速进入了云端。 +* 一旦一切正常，他们就开始降低复杂性。 +* 将 SQL Server 替换为 RDS for PostgreSQL。 +* 添加了用于消息传递的 Kinesis，因此他们可以更好地控制工作负载分配。 +* 由于他们的应用程序每天仅运行 2-4 小时，因此他们用 Lambda 函数替换了所有 EC2 实例。 +* 致力于制定按需创建和销毁整个计算机环境的策略。 +* 将他们的数据湖移至 S3。 +* 不断进行迭代以降低复杂性。 -尽管所有这些一致性和重复性问题都很有趣，但``推动变革''似乎为真正的追随者提供了更具可扩展性的方法。 推动所有更改确实需要很多工作，但是可以由作业排队系统处理，因此工作可以分布在整个集群中。 +## 结果：降低了 97％的成本 -随着我们拥有越来越多的人，越来越多的相互联系，越来越快的变革以及对实时消耗所有这些的渴望，挑战将越来越大。 我们距离能够应对这个勇敢的新世界还有很长的路要走。 +* 当然，该项目是经典的 Lambda 用例。 空闲时间这么多，全时 EC2 实例没有多大意义。 +* 但话又说回来，您可以想象整个企业中有许多这样的潜在优化。 -关于社交网站的整个可伸缩性问题的非常不错的概述。 但是，我确定下一个要紧推模型，特别是在经典聊天应用程序之外使用 XMPP 之类的协议。 +## 未来 -感谢您的精彩文章。 +* 到 2017 年，核心数据 API 将移动数 TB 的数据，每天处理数百万条消息。 +* 到 2018 年，他们将存储超过 2PB 的数据，每天处理超过 20 亿条消息，以支持超过 5 亿美元的产品收入。 +* 到 2020 年将自己的基础设施减少 70％的目标。 +* 悉尼数据中心将于 2018 年关闭。通过迁移非生产环境来缩小深圳的占地面积。 +* 创建了一个卓越的云计算中心，以重新考虑安全性，部署和运营等领域。 +* 将启动再培训计划，以对内部人员的技能进行投资和现代化（不错！）。 +* 成本效率很高，但他们也有兴趣创造一种无摩擦的开发经验以刺激创新和创造力。 他们采取此举似乎是一个重要原因。 -我一直想知道 Facebook 如何摆脱庞大的互连数据库。 +## 为什么选择 AWS？ -“他们的缓存层服务每秒提供 1.2 亿个查询，这是站点的核心。” +* 谈话的这一部分听起来像是 AWS 新闻稿，毕竟这是一次 AWS 会议，但这是企业 CTO 如何思考问题的一个很好的例子。 +* 喜欢 AWS 的步伐创新，服务呼吸和专业支持。 +* 转向 AWS 并拥有更少的基础架构意味着更多的容量，更多的安全性，更高的可靠性，更多的安心和更多的创新自由。 -您可以为此找到参考吗？ 在他的演讲中吗？ 如果是这样，我会去看的。 +[关于 HackerNews](https://news.ycombinator.com/item?id=15010310) -网络行业可以向金融行业学习。 多年来，股票市场一直在以非常低的延迟向大量节点传递消息的股价信息。 有多种商业产品，例如 Tibco Rendezvous，都提供了这样的消息总线。 那时，向 40,000 个关注者（可能驻留在更少的分区上）发布更新不是一个真正的挑战。 +上周没有“互联网说可扩展性”一文。 这是故意遗漏的吗？ :) -Facebook 的限制也反映出我们注意力经济的自然限制：没有人可能知道（或保留）约 5000 名其他人的一切。 +通过重写所有基础架构和代码将成本降低 97％，可以 +迁移到 AWS：昂贵，但不到 2020 年在全球范围内维护 1995 年的基础架构 +投入使用，成本降低了 70％以上 -只要 Web 体系结构只需要围绕我们弱小的人脑扩展，我们就处于相当安全的领域。 +如果您不能让工程师和开发人员升级/优化软件，请上云；如果您不是一家没有客户的初创公司，请始终保持低价…… -我喜欢这篇文章，非常有帮助。 分布式系统和缓存始终是我感兴趣的主题：） +抱歉，该 zbb。 我本来有最好的意图，但我生日那天不在，只是没有足够的时间来完成它。 我们本周上班。 如果我的老手仍然可以输入:-) -好帖子。 +我也错过了星期五的帖子！ -嗯..有趣的点。 -涉及到影响可访问量如此大的站点的可伸缩性的一些重要点。 +希望你生日快乐。 -你好 +我做了卡尔，谢谢！ -我们最近有一篇文章涉及 OSN 的扩展，并且我们处理了 -您提到的一些问题-包括分区问题。 +>如果您不是一家没有客户的初创企业，它总是“低声”。 -可以在以下网站找到该论文：http://bit.ly/18Gqmx +这就是为什么我认为这是一个有趣的案例，修剪。 显然，他们有自己的印章，可以按自己的方式办事。 如果他们认为节省的成本不堪重负，他们会坚持并留下来，但事实并非如此。 -请随时与作者联系以获取更多信息。 +关于它们的“空闲时间优化”，我一无所获：为什么有人需要 11k 的应用程序服务器和 7k 的数据库服务器来处理“每天仅工作 2-4 小时”的应用程序？ -干杯， -欢呼 +我对 Reader 的理解是，这些数字是指他们的整个系统，而空闲时间是指他们最初选择迁移到 AWS 的系统。 -伟大的话题和问题的解释。 如果您对解决此问题的绝佳方法感兴趣，请查看附件链接和网络研讨会。 -http://budurl.com/oct15wbnr - -不错的发人深省的文章。 我想我有一个想法如何处理“同时收集所有 200 个朋友的状态”。 根本不要。 人们不太可能希望甚至无法一次查看全部大小的数据，因此请以不占优势的块形式提供数据。 - -不错的文章，但您错失了 5,000 个用户限制。 我记得前一段时间看过一位 Facebook 工程师的演讲（我认为那是 Yahoo Brickhouse 的 Jeff Hammerbacher 的演讲），他说限制是“产品决定”，而不是工程决定。 他还说，粉丝专页使用的样式与普通人完全一样，那里没有限制。 因此，基本上，5,000 个朋友的限制是完全任意的，明天他们可以毫无问题地将其删除。 - -有趣且很有见地。 从很长时间以来，我一直在寻找可扩展性问题的答案，甚至在博客上都对此发表了看法，但这是我遇到的最好的解释。 - -很棒的帖子。 当我们处理扩展这些大型站点的软件架构时，这真的变得很有趣：) - -首先，facebook 和 dig 使用的方法是最好的方法。 然而，他们寻找更优化的解决方案的努力可能会触发数据管理的新发明。 如您所知，技术是在战争中最发达的，这就是在竞争激烈的市场中为金钱而战：) - -是的，我为 Facebook，Flickr，Digg 等购买此产品。 它们具有相对简单的数据结构和非常小的数据库。 他们最近声称，在迈克尔·杰克逊（Michael Jackson）事件期间，他们每秒最多有 5,000 条消息。 即使我很慷慨地说，他们平均每秒平均连续发送 5,000 条消息，但一年仍然只能收到 20Tb 的消息。 当然他们有很多要求，但是要提取的数据并不多。 如果他们只愿意执行某种形式的实时推送而不是让人们投票，那么他们发现的 api 调用也可能会大大减少。 与 Facebook 相比，Twitter 并没有太多的借口来应对近期的所有故障。 - -帕特里克 - -听起来是时候将某个人的社交网络直接构建到硬件中了。 也许是社交网络 ASIC？ - -极端情况下的社交网络问题最终与神经网络面临的经典问题以及其他大规模并行计算问题（互连的阶乘扩展）密切相关。 每个附加节点 N 将潜在连接数增加 N-1 倍。 在大脑中，典型的神经元与大约 10,000 个接收器和 10,000 个发送器连接，因此乘数仅约为 10,000，而不是数十亿。 因此，Facebook 限制的数量级相似。 有趣的是，分组交换网络比硬交换具有更好的可伸缩性，因此，除非实现了类似于网络的总线层，否则 ASIC 可能不是走的路。 那是我一直在研究的设计。 - -生物神经网络还通过不修剪不带明显信号的互连部分解决了这一问题，而“表决权”得不到定期使用的神经元（它们的输出并未受到任何接收神经元的高度加权）实际上会死亡。 - -可悲的是，用户不在乎并且不容忍由可伸缩性问题（或缺乏可伸缩性问题）引起的可见错误。 - -非常有趣的文章。 谢谢！ \ No newline at end of file +“用 RDS 替换 PostgreSQL 的 SQL Server”可能节省了 50％的 M $ \ No newline at end of file diff --git a/docs/21.md b/docs/21.md index c2ee405..cdd0ff7 100644 --- a/docs/21.md +++ b/docs/21.md @@ -1,200 +1,132 @@ -# Twitter 如何每秒处理 3,000 张图像 +# Mailinator 架构 -> 原文： [http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html) +> 原文： [http://highscalability.com/blog/2008/1/24/mailinator-architecture.html](http://highscalability.com/blog/2008/1/24/mailinator-architecture.html) -![](img/500a76b4aabec6690f90dc3c55a27a21.png) +**更新：**在[中进行应用搜索的有趣探索，如何每秒搜索 185 封电子邮件中的单词“ pen1s”](http://mailinator.blogspot.com/2008/01/how-to-search-for-word-pen1s-in-185.html) 。 如果 indexOf 没有减少，您会更加努力。 -今天，Twitter 正在每秒创建并永久保存 3,000 张（200 GB）图像。 更好的是，由于媒体存储政策的改进，2015 年 Twitter 节省了 600 万美元。 +曾经有一个醉酒的朋友启发您创建了首个受到数百万人喜爱，被数千人颠覆的互联网服务，同时每年通过[欺骗](http://www.flickr.com/photos/arcticstylings/814612466)处理超过 12 亿封电子邮件 ]旧服务器？ 这就是 Paul Tyma 来建立 Mailinator 的方式。 -并非总是如此。 2012 年的 Twitter 主要基于文本。 霍格沃茨没有在墙上挂满所有酷炫的动态图像。 现在是 2016 年，Twitter 已经进入了一个拥有丰富媒体的未来。 Twitter 已通过开发新的*媒体平台*进行了过渡，该平台可支持带有预览的照片，多张照片，gif，藤蔓和嵌入式视频。 +Mailinator 是一项免费的无设置 Web 服务，用于通过创建一次性注册电子邮件地址来阻止恶意垃圾邮件发送者。 如果您不给网站提供真实的电子邮件地址，那么他们就不会向您发送垃圾邮件。 他们反而对 Mailinator 发出垃圾邮件：-) -Twitter 的软件开发工程师 [Henna Kermani](https://www.linkedin.com/in/henna-kermani-27701146) 在 [Mobile @上进行了有趣的演讲，讲述了媒体平台的故事 伦敦规模](https://www.atscalelondon.co.uk/) ： [每秒 3,000 张图像](https://code.facebook.com/posts/1566627733629653/mobile-scale-london-recap/) 。 演讲主要集中在图像管道上，但她说大多数细节也适用于其他形式的媒体。 +我喜欢从角度出发进行设计，而 Mailinator 有一个巨大的挑战：性能第一，第二和最后。 为什么？ 因为 Mailinator 是免费的，所以 Paul 可以展示他对设计的不同看法。 竞争对手购买大型 Iron 来处理负荷时，Paul 却提出了一个大主意：选择正确的问题并设计一个适合该问题的设计。 不再。 不少 结果是一个完美的系统架构十四行诗，在形式的约束之内美。 -这次演讲中一些最有趣的教训： +Mailinator 作为垃圾邮件破坏超级英雄如何开展工作？ -* **做可能可行的最简单的事情确实会使您陷入困境**。 上载带有图像的 tweet 的简单方法是“全有或全无”操作，是一种锁定形式。 它的伸缩性不好，尤其是在网络较差的情况下，这使得 Twitter 很难添加新功能。 +网站：http：//mailinator.com/ -* **解耦**。 通过将媒体上传与推文脱钩，Twitter 能够独立地优化每种途径，并获得了极大的运营灵活性。 +## 信息来源 -* **移动不处理斑点**。 请勿在系统中传输大量数据。 它占用了带宽，并为每个必须处理数据的服务带来了性能问题。 而是存储数据并使用句柄引用它。 +* [Mailinator 的体系结构](http://mailinator.blogspot.com/2007/01/architecture-of-mailinator.html)* [Mailinator's 2006 Stats](http://mailinator.blogspot.com/2007/02/mailinators-2006-stats.html) -* 移至**分段可恢复上传**导致媒体上传失败率大大降低。 + ## 该平台 -* **实验和研究**。 Twitter 通过研究发现，图像变体（缩略图，小图，大图等）的 20 天 TTL（生存时间）是一个最佳选择，在存储和计算之间取得了很好的平衡。 映像在 20 天后被访问的可能性很小，因此可以将其删除，**每天节省近 4TB 的数据存储量**，**几乎减少了一半** **所需的计算服务器数量** ，每年可节省数百万美元。 + * 的 Linux* 雄猫* Java -* **按需**。 可以删除旧的图像变体，因为它们可以即时重新创建而不是预先计算。 按需执行服务可提高灵活性，使您对执行任务的方式更加了解，并提供集中控制点。 + ## 统计资料 -* **渐进 JPEG** 作为标准图像格式是真正的赢家。 它具有强大的前端和后端支持，并且在速度较慢的网络上表现非常出色。 + * 2007 年将处理大约 12.9 亿封电子邮件。2006 年为 450.74 百万封电子邮件。2005 年为 280.68 百万封电子邮件。* 峰值速率为每天 650 万封电子邮件或 4513 个/分钟或 75 个/秒。* Mailinator 运行在非常适度的计算机上，该计算机具有 AMD 2Ghz Athlon 处理器，1GB RAM（使用的内存更少）和低性能的 80G IDE 硬盘驱动器。 而且机器根本不是很忙。* 即使在持续的垃圾邮件攻击和高峰值负载下，Mailinator 也可以无人值守运行数月，并且很少丢失电子邮件。 -Twitter 走向富媒体的未来之旅中发生了很多美好的事情，让我们了解一下他们是如何做到的... + ## 架构 -## 旧方法-2012 年的 Twitter + * 拥有免费系统意味着该系统不一定是完美的。 因此，设计目标是： + -设计一个系统，该系统重视生存，甚至是用户。 生存是关键，因为 Mailinator 必须每天抵御攻击。 + -为用户提供 99.99％的正常运行时间和准确性。 更高的正常运行时间目标将是不切实际且成本高昂的。 而且由于该服务是免费的，因此这对于用户来说只是游戏规则的一部分。 + -支持以下服务模型：用户注册某些内容，转到 Mailinator，单击订阅链接，然后忘记它。 这意味着电子邮件不必永久存储在磁盘上。 电子邮件可以驻留在 RAM 中，因为它是临时的（3-4 小时）。 如果您想要一个真实的邮箱，请使用其他服务。* 电子邮件处理的原始流程是： + -Sendmail 在单个磁盘邮箱中接收到电子邮件。 + -基于 Java 的 Mailinator 使用 IMAP 和/或 POP（随时间变化）抓取电子邮件并将其删除。 + -系统随后将所有电子邮件加载到内存中，然后将其放置在那里。 + -达到 20,000 个内存限制后，最早的电子邮件便被推出。* 原始体系结构运行良好： + -它稳定并且一次可以使用几个月。 + -它几乎使用了所有 1GB 的 RAM。 + -每天收到的电子邮件速率开始超过 800,000 时出现问题。 由于 Mailinator 和电子邮件子系统之间的磁盘争用，系统崩溃了。* 新架构： + -想法是删除磁盘上的路径，这是通过完整的系统重写来完成的。 + -Web 应用程序，电子邮件服务器和所有电子邮件存储都在一个 JVM 中运行。 + -Sendmail 被替换为自定义的 SMTP 服务器。 由于 Mailinator 的性质，因此不需要完整的 SMTP 服务器。 Mailinator 不需要发送电子邮件。 它的主要职责是尽快接受或拒绝电子邮件。 这是分层的缺点。 分层通常是扩展的关键策略，但由于关键决策最好在堆栈的最高级别进行处理，因此会降低性能。 因此，当许多 RAM 和周期窃取操作已经完成时，工作流将流经系统，仅在较低层进行转储。 因此，决定使用定制 SMTP 服务器是一个有趣而勇敢的决定。 此时大多数人只会添加更多硬件。 他们不会错，但是看到这条路也很有趣。 也许有了更多 [DOM 和 AOP](http://radio.weblogs.com/0103955/categories/stupidHumanProgramming/2007/06/20.html#a244) 这样的体系结构，我们可以展平堆栈并在需要时获得更好的性能。 + -现在 Mailinator 直接接收电子邮件，进行解析并将其存储到内存中。 磁盘被完全绕过，并且磁盘仍然相当空闲。 + -系统关闭时，电子邮件将写入磁盘，因此可以在启动时重新加载它们。 + -记录已关闭，以消除传票的风险。 执行日志记录时，日志数据是成批写入的，因此在一次磁盘写入中将写入数千行日志。 这样可以最大程度地减少磁盘争用，否则会丢失有用的诊断信息。 + -系统使用少于 300 个线程。 不需要更多。 + -到达后，每封电子邮件都会通过过滤器系统，如果所有过滤器都通过，则会存储在 RAM 中。 + -每个收件箱仅限于 10 封电子邮件，因此流行的收件箱，例如 [[受电子邮件保护]](/cdn-cgi/l/email-protection) ，无法使系统崩溃。 + -传入的电子邮件不得超过 100k，所有附件都将立即被丢弃。 这样可以节省 RAM。* 电子邮件在 RAM 中压缩： + -由于从未查看过 99％的电子邮件，因此压缩电子邮件可以节省 RAM。 当有人看着它们时，它们只有 + 被解压缩。 + -Mailinator 可以使用不到 300MB 的内存在 RAM 中存储约 80,000 封电子邮件，而原始设计中的 1GB RAM 中存储了 20,000 封电子邮件。 + -使用此池，平均电子邮件寿命约为 3-4 小时。 + -可能有 200,000 封电子邮件可以容纳在内存中，但是并没有真正的需求。 + -这是我喜欢的设计细节之一，因为它基于真实的应用程序使用模式。 RAM 很珍贵，而 CPU 却不是，所以知道大多数情况下您不必将 CPU 命中两次，使用压缩来节省 RAM 却以 CPU 为代价。* Mailinator 不保证匿名和隐私： + -没有隐私。 任何人都可以随时阅读任何收件箱。 + -放宽这些约束，同时又令人震惊，使设计更加简单。 + -对于用户而言，这很简单，因为不需要注册。 当网站要求您提供电子邮件地址时，您只需输入一个 mailinator 地址即可。 您无需创建单独的帐户。 键入电子邮件地址可以有效地创建 mailinator 帐户。 简单。 + -在实践中，用户仍然可以获得高度的隐私。* 可生存性的目标导致积极的垃圾邮件过滤。 + -Mailinator 没有针对 SPAM 的任何内容，但是由于 SPAM 太多，因此在威胁到系统正常运行时必须将其过滤掉。 + -这导致以下规则：如果您做任何事情（无论是否发垃圾邮件）都开始影响系统，则您的电子邮件将被拒绝，您可能会被锁定。* 要被接受，电子邮件必须通过以下过滤链： + -退回：所有退回的电子邮件都会被丢弃。 + -IP：丢弃了来自单个 IP 的过多电子邮件 + -主题：丢弃了有关同一主题的过多电子邮件 + -便笺：包含了表示仇恨或犯罪或仅是彻头彻尾的讨厌表情的主题 。* 从单个 IP 地址 + 中幸存的电子邮件泛滥-AgingHashmap 用于过滤来自特定 IP 地址的垃圾邮件发送者。 当电子邮件到达 IP 地址时，会将 IP 放入地图中，并为所有后续电子邮件增加计数器。 + -在一段时间内没有电子邮件后，计数器将被清除。 + -当发件人达到电子邮件计数阈值时，将阻止该发件人。 这样可以防止发件人淹没系统。 + -许多系统使用这种逻辑来保护各种资源，例如注释。 您可以将 memcached 用于分布式系统中的相同目的。* 防范僵尸攻击： + -垃圾邮件可以从称为 IP 僵尸网络的不同 IP 地址的大型坐标集中发送。 相同的消息是从数千个不同的 IP 地址发送的，因此用于阻止来自单个 IP 地址的电子邮件的技术还不够。 + -这种过滤比 IP 阻止要复杂一些，因为您必须解析足够多的 + 电子邮件才能获得主题行，而匹配主题字符串则需要更多的资源。 + -当 2 分钟之内有 20 封电子邮件发送同一主题时，所有带有该主题的电子邮件将被禁止 1 小时。 + -有趣的是，并没有永远禁止主题，因为这意味着 Mailinator 将不得不永远跟踪主题，并且系统设计固有地是瞬态的。 我认为这很聪明。 通过一些“不好的”电子邮件，通过系统变得简单得多，因为不必管理任何持久性列表，并且该列表肯定会成为瓶颈。 一个具有更严格的 SPAM 过滤目标的系统将不得不创建一个更加复杂且不那么健壮的体系结构。 + -仅有 9％的电子邮件被此过滤器阻止。 + -从我的阅读中，Mailinator 仅针对 IP 和主题进行过滤，因此不必阅读电子邮件正文即可接受或拒绝电子邮件。 当大多数电子邮件将被拒绝时，这可以最大程度地减少资源使用。* 为减轻 DOS 攻击的危险，请执行以下操作： + -丢弃在特定时间段内保持沉默的所有连接。 + -Mailinator 会非常缓慢地（例如 10 或 20 或 30 秒）将回复发送给电子邮件发件人，即使是非常少量的数据也是如此。 这会减慢试图尽快发送垃圾邮件的垃圾邮件发送者的速度，并可能使他们重新考虑再次向该地址发送电子邮件。 繁忙时段的等待时间减少了，因此电子邮件不会丢失。 -### 写入路径 + ## 得到教训 -* 用户在应用程序中撰写推文，并可能在其中附加图像。 + * **完善是陷阱**。 驱动器使 100％的一切变得更加复杂。 如果您去过那些会议，您就会知道他们的样子。 哦，我们不能这样或那样做，因为发生错误的可能性为 0.01％。 而是问：你会多么不完美，不够好？ - * 客户端将推文发布到整体端点。 该图像将与所有其他推特元数据捆绑在一起上传，并传递到流程中涉及的每个服务。 + * **扔掉的东西与**存放的东西一样重要。 我们对如何设计系统有许多先入之见。 我们理所当然地认为您需要横向扩展，几天后需要访问电子邮件，并且必须为每个人提供 + 私人帐户。 但是您真的需要这些东西吗？ 你能扔什么？ - * 此端点是旧设计中很多问题的根源。 + * **了解系统的用途并进行相应设计**。 所有人都拥有一切意味着您对任何人都不是。 将电子邮件保留很短的时间，允许一些 SPAM 通过，并接受少于 100％的正常运行时间，这将为该系统创建一个强大的愿景，从而有助于在各个领域推动设计。 如果您对系统的含义和需求有非常深刻的了解，则只能构建自己的 SMTP 服务器。 我知道这绝不会成为我的主意。 我会增加更多的硬件。 -* **问题＃1** ：大量浪费的网络带宽 + * **对于常见情况，在提交资源**之前快速失败。 很高比例的电子邮件被拒绝，因此在堆栈中尽早拒绝它是有意义的，以最大程度地减少完成任务的资源。 找出如何尽快使经常发生故障的物品短路。 这很重要，并且经常被忽视。 - * 发推文的创建和媒体上载紧密地结合到一个操作中。 + * **效率通常意味着您自己建立**。 现成的工具往往可以完成全部工作。 如果您只需要完成部分工作，则可以编写运行速度更快的自定义组件。 - * 正在上传，上传完全成功或完全失败。 由于任何原因导致的故障，网络故障，瞬时错误等，都要求整个上传过程从头开始重新启动，包括媒体上传。 上传可以完成 95％，如果失败，则必须重新上传所有内容。 + * **自适应地忘记**。 有点失败是可以的。 不需要永远记住所有被阻止的 IP 地址。 让块决策从本地数据而不是全局状态开始。 这是功能强大且简单而强大的体系结构。 -* **问题 2** ：对于新的较大尺寸的介质，无法很好地扩展 + * **Java 不必太慢**。 说够了。 - * 这种方法无法扩展到视频等大型媒体。 较大的文件会增加失败的可能性，尤其是在巴西，印度，印度尼西亚等新兴市场中，网络缓慢且不可靠的地方，他们确实希望提高推文上传成功率。 + * **避开磁盘**。 许多应用程序需要使用磁盘，但是磁盘始终是瓶颈。 您可以使用其他创意策略在磁盘周围进行设计吗？ -* **问题 3** ：内部带宽使用效率低下 + * **限制资源使用量**。 放入约束，例如收件箱大小，这将使您的系统无法控制地突刺。 必须在资源有限的情况下避免无限制的资源使用。 - * 连接到 TFE 的终结点，即 Twitter 前端，用于处理用户身份验证和路由。 用户被路由到图像服务。 + * **压缩数据**。 尝试节省 RAM 时，压缩可能是一大胜利 + 。 我发现使用压缩的开销很少，而内存使用量却下降了一半以上。 如果您是在本地进行通信，则只需让客户端对数据进行编码并保持编码状态即可。 构建 API 无需解码完整的消息即可访问数据。 - * 图像服务与 Variant Generator 对话，后者生成不同大小（例如小，中，大，缩略图）的图像实例。 这些变体存储在 BlobStore 中，BlobStore 是为大型有效负载（如图像和视频）优化的键值存储。 这些图像永远存在。 + * **使用固定大小的资源池来处理负载**。 许多应用程序无法控制资源的使用，例如内存，如果使用过多，它们就会崩溃。 要创建一个真正强大的系统，请修复您的资源，并在这些资源已满时放弃工作。 您可以老化资源，给予优先访问权，给予公平访问权或使用任何其他逻辑来仲裁资源访问权，但是由于资源将受到限制，因此您将承受负载。 - * 创建和保留推文的过程中还涉及许多其他服务。 因为端点是整体的，将媒体与推文元数据结合在一起，所以该捆绑包也流经所有服务。 如此大的有效负载被传递给了不直接负责处理图像的服务，它们不是媒体管道的一部分，但仍被迫对其进行优化以处理大型有效负载。 这种方法在内部带宽方面效率很低。 + * **如果不保留数据，则不会传唤**。 由于 Mailinator 不存储电子邮件或在磁盘上登录日志，因此可以进行传票。 -* **问题 4** ：膨胀的存储空间 + * **使用您所知道的**。 我们已经看过几次这一课了。 保罗比其他任何人都更了解 Java，因此他使用了 Java，使其得以运行，然后他完成了工作。 - * 来自不再需要几个月和几年的推文中的图像将永远存在于 BlobStore 中，从而占用了空间。 即使有时删除推文时，图像也会保留在 BlobStore 中。 没有垃圾收集。 + * **查找您自己的 Mailinators** 。 当然，Mailinator 是一个小型系统。 在大型系统中，这只是一个小功能，但是您的系统由许多 Mailinator 大小的项目组成。 如果您开发了诸如 Mailinator 之类的 + ，该怎么办？ -### 读取路径 + * **KISS 存在，尽管很少见**。 总是谈论保持简单，但是我们很少显示真实的例子。 这主要是因为您的方法很复杂，而我的方法却很简单，因为这是我的方法。 Mailinator 是简单设计的一个很好的例子。 -* 用户看到一条推文以及与之相关的图像。 图片从何而来？ + * **健壮性是体系结构**的功能。 要创建有效利用内存并能抵御大量垃圾邮件攻击的设计，需要一种能够查看整个堆栈的架构方法。 -* 客户端从 CDN 请求图像的变体。 CDN 可能需要询问图像的来源 TFE。 这最终将导致在 BlobStore 中直接查找特定大小的 URL 的图像。 + ## 相关文章 -* **问题 5** ：不可能引入新的变体 + * [PlentyOfFish](http://highscalability.com/plentyoffish-architecture) 拥护直截了当的裸露骨头。* [Varnish](http://highscalability.com/links/goto/117/) 巧妙地使用 OS 功能来找到令人难以置信的性能。* [ThemBid](http://highscalability.com/thembid-architecture) 优雅地将开源组件组合在一起。 - * 设计不是很灵活。 添加新的变体，即大小不同的图像，将需要为 BlobStore 中的每个图像回填新的图像大小。 没有随需应变的设施。 +很棒的阅读。 - * 缺乏灵活性使 Twitter 很难在客户端上添加新功能。 +这属于“我曾想过的想法”的构想。 -## 新方法-2016 年的 Twitter +我不知道他如何获得资助？ -### The Write Path - -#### 将媒体上传与发帖分离。 - -* 上传的内容为头等公民。 创建了一个上传端点，唯一的责任是将原始媒体放入 BlobStore - -* 这在处理上传方式方面提供了很大的灵活性。 - -* 客户端与 TFE 对话，TFE 与 Image Service 对话，后者将图像放入 BlobStore 中并将数据添加到元数据存储中。 而已。 没有涉及其他隐藏服务。 没有人在处理媒体，没有人在传递媒体。 - -* 从图像服务返回 mediaId（媒体的唯一标识符）。 当客户想要创建推文，DM 或更新其个人资料照片时，mediaId 将用作引用媒体的句柄，而不是提供媒体。 - -* 假设我们要使用刚刚上传的媒体创建一条推文。 流程如下： - - * 客户端点击更新端点，并在发布中传递 mediaId； 它将到达 Twitter 前端； TFE 将路由到适合于所创建实体的服务。 对于推文，它是 TweetyPie。 DM 和配置文件有不同的服务； 所有服务将与图像服务对话； 图像服务器具有处理诸如人脸检测和儿童色情检测之类的功能的后处理队列。 完成此操作后，Image Service 会与 ImageBird 取得图像或与 VideoBird 取得视频； ImageBird 将生成变体； VideoBird 将进行一些转码； 生成的任何媒体都将放入 BlobStore。 - - * 没有媒体通过。 节省了大量浪费的带宽。 - -#### 分段的可恢复上传。 - -* 走进地铁，在 10 分钟后出来，上传过程将从停止的地方恢复。 对用户而言是完全无缝的。 - -* 客户端使用上载 API 初始化上载会话。 后端将为它提供一个 mediaId，该 ID 是整个上传会话中要使用的标识符。 - -* 图像分为多个部分，例如三个部分。 使用 API​​附加细分，每个附加调用给出细分索引，所有附加都针对相同的 mediaId。 上载完成后，上载完成，可以使用媒体了。 - -* 这种方法对于网络故障更具弹性。 每个细分都可以重试。 如果网络由于任何原因而掉线，您可以暂停并取回网络恢复时停在的网段。 - -* 具有巨大收获的简单方法。 对于> 50KB 的文件，巴西的图像上传失败率下降了 33％，印度为 30％，印度尼西亚为 19％。 - -### The Read Path - -#### 推出了名为 MinaBird 的 CDN 原始服务器。 - -* MinaBird 可以与 ImageBird 和 VideoBird 对话，因此，如果不存在图像大小变体和视频格式变体，则可以即时生成它们。 - -* MinaBird 在处理客户端请求方面更流畅，更动态。 例如，如果有《数字千年版权法案》下架，则很容易阻止访问或重新启用对特定媒体的访问。 - -* Twitter 能够即时生成变体和代码转换，因此 Twitter 在存储方面更加聪明。 - - * 按需变量生成意味着不需要将所有变量存储在 BlobStore 中。 巨大的胜利。 - - * 原始图像将保留直到删除。 变体仅保留 20 天。 Media Platform 团队针对最佳有效期限进行了大量研究。 所有请求的图像中大约有 50％的时间最多为 15 天左右。 保留比这更旧的图像会导致收益递减。 没人会要求使用较旧的媒体。 15 天后尾巴很长。 - - * 由于没有 TTL（生存时间），没有过期，因此媒体存储每天的存储量每天增长 6TB。 这种按需生成所有变体的惰性方法导致每日存储增长 1.5TB。 20 天的 TTL 使用的存储空间不多于惰性方法，因此在存储空间上并不需要花费太多，但是在计算方面却是一个巨大的胜利。 使用懒惰的方法来计算读取的所有变体将需要每个数据中心使用 150 台 ImageBird 机器，而使用 20 天 TTL 则需要 75 台左右。 因此 20 天的 TTL 是最佳选择，可以在存储和计算之间取得良好的平衡。 - - * 由于节省存储空间和计算就是节省资金，2015 年 Twitter 通过引入 20 天 TTL 节省了 600 万美元。 - -#### 客户端改进（Android） - -* 使用 Google 创建的图像格式 [WebP](https://en.wikipedia.org/wiki/WebP) 进行了为期 6 个月的实验。 - - * 图像平均比相应的 PNG 或 JPEG 图像小 25％。 - - * 锯增加了用户的参与度，尤其是在新兴市场中，在新兴市场中，较小的图像尺寸会减轻网络压力。 - - * iOS 不支持。 - - * 仅在 Android 4.0+上受支持。 - - * 缺乏平台支持使 WebP 的支持成本很高。 - -* 渐进 JPEG 是 Twitter 尝试的另一种选择。 它在连续扫描中呈现。 第一次扫描可能是块状的，但是它将通过连续扫描进行完善。 - - * 更好的性能。 - - * 易于在后端支持。 - - * 的编码速度比传统 JPEG 慢 60％。 由于编码只会发生一次，而投放会发生多次，因此这不是一个大问题。 - - * 不支持透明，因此保留了透明的 PNG，但是其他所有内容都在渐进 JPEG 上收敛。 - - * 在客户端， [Facebook 的 Fresco](https://github.com/facebook/fresco) 库提供了支持。 关于壁画有很多很好的话要说。 2G 连接的结果令人印象深刻。 首次扫描 PJPEG 仅需要大约 10kb，因此加载时间不会很长。 本机管道仍在等待加载，什么也没有显示，而 PJPEG 正在显示可识别的图像。 - - * 正在 tweet 详细信息视图中进行负载实验的结果。 p50 加载时间减少了 9％。 p95 加载时间减少了 27％。 故障率降低了 74％。 连接速度较慢的用户确实会获得巨大的成功。 - -## 相关文章 - -* [关于 HackerNews](https://news.ycombinator.com/item?id=11535418) - -* [Twitter 用来处理 1.5 亿活跃用户，300K QPS，22 MB / S Firehose 的架构，并在 5 秒内发送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) - -* [Twitter 如何使用 Redis 进行扩展-105TB RAM，39MM QPS，10,000 多个实例](http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html) - -* [DataSift 架构：每秒 120,000 条推特的实时数据挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) - -“今天，Twitter 正在每秒创建并保留 3,000（200 GB）图像。” - -与...不同 - -“ Twitter 可以创建大约 3,000 张独特的图像，并每秒传输大约 200 GB 的图像。” - -请不要更改其含义。 - -我并不是要批评/挑剔这是什么引人入胜的文章，但是在开始的段落中 200GB 的数字不是很清楚–它显示为 200GB /秒：“每秒可保留 3,000（200 GB）图像” 。 - -除非我缺少任何东西，否则这似乎是不正确的。 对于 3000 张图像，相当于 200GB，它们将需要很大的文件（每个〜68mb），而且每天 6TB 的存储量（无 TTL）将不可用（在 200GB /秒的情况下，它们需要更多 16PB /天，没有 TTL）。 - -我已经尝试过数学运算，我能得到的最合逻辑的是：200GB /分钟，这将使我们平均获得 1.3MB /图像，这看起来更准确，但是仍然是 281TB /天。 - -如果有人可以弄清楚我是不是愚蠢还是真正的价值应该是很棒的。 - -我认为 200GB 包含必要的复制。 因此，200GB 可能至少是图像原始大小的 3 倍。 - -另外，Twitter 可能需要每个图像有多个版本，例如 缩略图，原始图片等。每个都有不同的分辨率。 这就增加了很多存储空间。 - -无论 Twitter 进行多少复制，仍然很难相信一张图像可能会占用约 66 MB。 数字/单位在这里肯定是错误的。 - -哦，这应该是“ Twitter 可以创建约 3,000 个唯一图像，每秒传输约 200 GB 图像。” 正如第一个评论试图指出的那样。 原始来源：https://code.facebook.com/posts/1566627733629653/mobile-scale-london-recap/ - -没有狗屎夏洛克，这些都是众所周知的技术，对不起，没什么有趣的。 - -你好 - -好吧，我记得自 2011 年该版本于 2011 年发布以来，我认为客户端改进版并没有在 Android 4.0+上受支持的任何问题。 因此，可能每个人都拥有较年轻的版本。 - -这句话的意思很清楚：“ Twitter 可以创建大约 3,000 个唯一的图像，并每秒传输大约 200 GB 的图像。” - -“创建大约 3,000 张独特的图像”：如果以 3 种不同的尺寸保存图像，则用户将上传 1,000 张图像。 -“每秒传输大约 200 GB 的图像”：并不是说它们存储 200 GB 的图像。 但是他们传输 200 GB。 这意味着它们每秒可交付 200 GB 的图像。 - -他们是否将图像存储两次？ -图片服务将图片上传到 Blob 存储并返回 mediaId。 -mageBird 将生成变体； VideoBird 将进行一些转码； 生成的任何媒体都将放入 BlobStore。 \ No newline at end of file +[http://codershangout.com](http://codershangout.com) +编码人员可以进行视频群聊的地方！ + +有资金吗？ 自掏腰包。 这是他的爱好。 \ No newline at end of file diff --git a/docs/210.md b/docs/210.md index 601cf58..85f5a31 100644 --- a/docs/210.md +++ b/docs/210.md @@ -1,181 +1,92 @@ -# Wolfram | Alpha 建筑 +# ButterCMS 体系结构：关键任务 API 每月可处理数百万个请求 -> 原文： [http://highscalability.com/blog/2009/5/15/wolframalpha-architecture.html](http://highscalability.com/blog/2009/5/15/wolframalpha-architecture.html) +> 原文： [http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html](http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html) -### 使世界的知识可计算 +![](img/73b3493317ddb8421dbc8da23b060ef8.png) -今天的 Wolfram | Alpha 是一项雄心勃勃的长期项目的第一步，该项目旨在使任何人都可以立即计算所有系统知识。 输入问题或计算，Wolfram | Alpha 使用其内置算法和不断增长的数据收集来计算答案。 +*这是 [Jake Lumetta](https://twitter.com/jakelumetta) 的来宾帖子， [ButterCMS [](https://buttercms.com/) 。* -### 答案引擎与搜索引擎 +[ButterCMS](https://buttercms.com/) 使开发人员可以在几分钟内将内容管理系统添加到任何网站。 我们的业务要求我们为 API 提供近 100％的正常运行时间，但是在多次中断几乎使我们的业务瘫痪之后，我们开始着迷于消除单点故障。 在这篇文章中，我将讨论如何快速使用 [](https://www.fastly.com/)的边缘云平台和其他策略，以确保我们保持客户网站的正常运行 。 -当 [Wolfram | Alpha](http://www.wolframalpha.com/) 今天晚些时候发布时，它将成为**互联网上计算量最大的网站之一**。 [Wolfram | Alpha 计算知识引擎](http://innowave.blogspot.com/2009/03/wolfram-alpha-computational-knowledge.html)是一个“答案引擎”，能够产生各种问题的答案，例如 +ButterCMS 的核心功能是： -* 法国的国内生产总值是多少？ +* 内容编辑器的仪表板 -* David Ortiz 出生时的天气是斯普林菲尔德 +* 一个 [JSON API](https://buttercms.com/docs/api/) ，用于获取内容 -* 33 克黄金 +* [SDK，用于将 ButterCMS](https://github.com/buttercms) 集成到本机代码中 -* 低密度脂蛋白（LDL）与 150 岁男性吸烟者的血清钾 150 的对比 +## ButterCMS 技术堆栈 -* 男性预期寿命 40 岁芬兰 +ButterCMS 是一个单一的 Django 应用程序，负责营销网站，编辑工具，API 和后台工具，以提供客户支持。 Django 应用程序与 Postgres 数据库一起在 Heroku 上运行。 -* 高中教师工资中位数 +我们还利用以下第三方服务： -Wolfram | Alpha 在数学，统计，物理学，工程学，天文学，化学，生命科学，地质学，商业和金融等不同领域均表现出色，正如 Steven Wolfram 在其[简介截屏视频](http://www.wolframalpha.com/screencast/introducingwolframalpha.html)中所展示的。 +* [文件堆栈](https://www.filestack.com/) 用于为其客户提供图像编辑功能 -### 统计资料 +* [快速](https://www.fastly.com/) 用于外部 API 缓存和交付 -* 推出约 10,000 个 CPU 内核 +* [Cloudfront](https://aws.amazon.com/cloudfront/) 作为客户资产的 CDN -* 10+万亿条数据 +* 用于 DNS 的 [EasyDNS](https://www.easydns.com/) -* 50,000 多种算法 +## 停机时间是致命的 -* 每天可处理约 1.75 亿个查询 +我们的客户通常会建立在请求/响应生命周期内向 ButterCMS 发出 API 请求以获取页面内容的网站。 这意味着，如果他们对 ButterCMS 的 API 请求失败，则他们的页面可能无法呈现。 如果我们的 API 出现故障，那么客户的网站也会与我们发生故障。 -* 5 百万行符号 Mathematica 代码 +这是我们在早期学习的艰辛课程。 不可靠的服务器托管导致频繁的间歇性停机和性能下降，使客户感到沮丧。 糟糕的 DNS 迁移导致 API 停机数小时，从而使数十个客户的网站瘫痪了近半天，并使大量客户质疑他们是否可以继续依赖我们（其中有少数人离开了我们）。 -### 推动可计算知识的计算机 +在此事件之后，我们意识到确保接近 100％的正常运行时间是一个存在的问题。 未来发生的重大故障可能导致我们失去来之不易的客户，并使我们的业务陷入危机。 -无法确切知道期望的流量，尤其是在发射后的最初阶段，但是 Wolfram | Alpha 小组正在努力将合理的容量放到位。 +## 提供全局，快速，弹性的 API -正如 Stephen 在[中所写，Wolfram | Alpha 博客](http://blog.wolframalpha.com/2009/05/12/the-computers-powering-computable-knowledge/) Alpha 将在 5 个分布式托管设备中运行。 他们在发射当天在这些设施中收集了哪些计算能力？ 两台超级计算机，仅约 10,000 个处理器核心，数百 TB 的磁盘，大量带宽，以及似乎足够的空调供撒哈拉沙漠地区举办滑雪胜地。 +无法完全避免失败-您只能尽力减少机会。 -他们的发布合作伙伴之一 [R Systems](http://www.rsystemsinc.com/) 创建了世界第 44 大超级计算机（根据 2008 年 6 月的 TOP500 排行榜-在[最新的 Top500 中排名第 66 位） 列表](http://www.top500.org/list/2008/11/100)）。 他们称其为 [R Smarr](http://www.top500.org/system/9506) 。 它将在发布日运行 Wolfram | Alpha！ 使用 Dell DCS CS23-SH，QC HT 2.8 GHz 计算机，4608 内核，65536 GB RAM 和 Infiniband 互连，R Smarr 的总 Rmax 最大为 39580 GFlops。 +例如，通过运行自己的物理服务器来“控制自己的命运”可以保护您的主机提供商免受崩溃的困扰，但是却使您处于必须处理安全性和可伸缩性的位置，这两者都可以轻松使您崩溃并 很难恢复。 -戴尔是另一个推出合作伙伴，其数据中心充满了四板，双处理器，四核 Harpertown 服务器。 这加起来是什么？ **每天能够处理 1.75 亿个查询（可能产生 10 亿个查询）**-每月超过 50 亿个查询（包括约 300 亿次计算）。 +对于我们的团队而言，始终保持 API 的正常运行并确保其在全球范围内提供高性能至关重要。 但是作为一家较小的公司，我们知道我们没有足够的资源来提供具有近 100％正常运行时间的全球性，高度可扩展的性能。 因此，我们转向了这样做的人： [快速](https://www.fastly.com/) 。 -### Wolfram | Alpha 的发射 +迅速将自己描述为“为全球最受欢迎的企业提供快速，安全和可扩展的数字体验的边缘云平台”。 他们与包括《纽约时报》，BuzzFeed，Pinterest 和 New Relic 等大型客户合作。 我们将 Fast 放在我们的 API 前面作为缓存层，以便所有 API 请求都通过其 CDN 进行处理。 ![](img/23f51f8296408b47a4f28e71b6ffafb1.png) -观看 Wolfram | Alpha 系统的在线实时直播[](http://www.wolfram.com/broadcast/wolframalpha/) +当我们的一位客户在 ButterCMS 中更新其网站内容时，我们将使已编辑内容的特定位的 API 密钥无效。 非缓存的请求命中了我们的服务器，但命中率达到了 94％，因为客户网站上的内容相对于获得的访问者数量很少变化。 这意味着，即使我们的数据库或服务器遇到间歇性的中断，我们的 API 仍然可以运行。 我们不希望这样，但是从理论上讲，只要 Fastly 保持正常运行，服务器可能会完全瘫痪几个小时，而且客户的网站也会保持正常运行。 -* 5 月 15 日，星期五，太平洋标准时间下午 7 点开始 +Fastly 的全球 CDN 为我们带来了另一个好处。 我们的许多客户都有静态 JavaScript 网站，这些 API 网站的访问者访问者是浏览器而不是服务器。 通过 Fastly 的 CDN 提供 API 响应，意味着我们的客户的网站访问者无论身在何处，都能获得快速的加载时间。 -### 新型科学的第一个杀手级应用 +## 消除单点故障 -Wolfram | Alpha 背后的天才是 Stephen Wolfram。 他以其雄心勃勃的项目而闻名： *Mathematica* 和*一种新型科学（NKS）*。 -2009 年 5 月 14 日是他的著作[一种新型科学](http://www.amazon.com/gp/product/1579550088?ie=UTF8&tag=innoblog-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1579550088) ![](img/ff91ab4b9da646c9390cc43d8e306d86.png)出版 7 周年。 斯蒂芬解释说[是他的博客文章](http://blog.wolfram.com/2009/05/14/7-years-of-nksand-its-first-killer-app/)：但是对我来说，今年最大的变化是 Wolfram | Alpha 的出现。 我相信 Wolfram | Alpha 将成为 NKS 的第一个杀手级应用。 +在 ButterCMS 成立之初，我们处理了两次单独的 DNS 事件，这使我们感到恐惧。 在第一起事件中，我们的 DNS 提供商当时不小心从其系统中“取消”了我们的帐户，导致断电花费了将近 6 个小时才能使我们完全恢复。 我们的第二次事件发生在常规 DNS 编辑导致我们的[不同的] DNS 提供程序发生故障时，并且花费了将近半天的时间来解决。 DNS 事件尤其具有破坏性，因为即使在确定并解决问题后，您也必须等待各种 DNS 服务器和 ISP 清除缓存，然后客户才能看到解决方案（DNS 服务器也倾向于忽略您的 TTL 设置并强加 他们自己的政策）。 -### 状态 +我们的经验使我们非常专注于消除整个体系结构中的任何单点故障。 -建造 21 世纪前十年的 Wolfram | Alpha 应该是可行的。 然而，还有更多。 +对于 DNS，我们切换为使用来自不同 DNS 提供商的多个名称服务器。 DNS 提供程序通常允许并鼓励您使用 4-6 个冗余名称服务器（例如 ns1.example.com，ns2.example.com）。 很好：如果一个请求失败，其他请求仍然可以解决。 但是，由于您所有的名称服务器都来自同一家公司，因此您非常相信他们将拥有 100％的正常运行时间。 -到目前为止，Wolfram | Alpha 包含 10+万亿条数据，50,000 +种算法和模型，以及 1000 多个域的语言能力。 用 Mathematica 构建，这本身是 Wolfram Research 20 多年发展的结果，Wolfram | Alpha 的核心代码库现在超过了 500 万行符号 Mathematica 代码。 Wolfram | Alpha 运行在超级计算机类的计算集群上，广泛使用了最新一代的 Web 和并行计算技术，包括 [webMathematica](http://wolfram.com/products/webmathematica/) 和 [gridMathematica](http://wolfram.com/products/gridmathematica/) 。 +对于我们的应用服务器，我们使用 Heroku 的监控和 [自动缩放](https://blog.heroku.com/heroku-autoscaling) 工具，以确保我们的性能不会因流量高峰（或 如果快速崩溃，我们突然需要将所有请求直接路由到我们的服务器）。 除了使用 Fastly 缓存 API 外，我们还使用 Memcached 在应用程序级别缓存 API。 这为间歇性数据库或服务器故障提供了额外的缓冲层。 -### *Mathematica* 如何使 Wolfram | Alpha 成为可能？ +为防止在 Heroku 或 AWS（Heroku 运行于其上）之间发生极少数情况下的总停机，我们在 Google Cloud 上维护了单独的服务器和数据库实例，可以将其快速故障转移。 -Wolfram | Alpha 是一项重要的软件工程开发，旨在使任何人都可以立即计算所有系统知识。 它完全由 Mathematica 开发和部署-实际上，Mathematica 独特地使 Wolfram | Alpha 成为可能。 这就是为什么。 +## 不可避免的是失败 -* 计算知识与智能 +不管我们的 API 有多可靠，我们都必须接受 [不可靠的网络](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) ，并且网络肯定会发生故障。 我们所有人在连接 Wi-Fi 时都遇到了麻烦，或者突然打了个电话。 从统计上讲，中断，路由问题和其他间歇性故障在总体上可能是异常的，但始终会始终以某个环境本底速率发生。 -* 高性能企业部署 +为克服这种本质上不可靠的环境，我们帮助客户构建在出现故障时将变得可靠的应用程序。 我们的 SDK 提供的功能，例如 [在 API 请求失败时自动重试](https://github.com/ButterCMS/buttercms-csharp/pull/2) 或 [支持，可轻松使用故障转移缓存](https://github.com/ButterCMS/buttercms-ruby#fallback-data-store) ，例如客户端上的 Redis。 -* 一种一致的架构 +## 结论 -* 智能方法选择 +没有意识到这一点，我们中的许多人正在将单点故障构建到我们的堆栈中。 在 ButterCMS，我们的成功取决于确保客户的应用程序不会因为我们而出现故障。 为此，我们从后端基础架构中消除了尽可能多的单点故障，并提供了 SDK，可让我们的客户轻松实现其应用程序中的弹性和容错能力。 -* 动态报告生成 +### 关于 ButterCMS -* 数据库连接 +当您听到“ CMS”或“博客”消息时，您可能会想到 WordPress。 ButterCMS 是一种较新的替代方法，它允许开发团队使用 ButterCMS API 将 CMS 和博客功能添加到他们自己的本机代码库中。 -* 内置可计算数据 +ButterCMS 由 [Jake Lumetta](https://twitter.com/jakelumetta) 和 [Abi Noda](https://twitter.com/abi) 发起，因为他们俩都遇到了寻找功能齐全，灵活且未将您绑定到特定 WordPress 的替代品的挑战 像 PHP 这样的编程语言.. -* 高级编程语言 +如今，ButterCMS 为全球数百个网站提供支持，每月帮助处理数百万个请求。 -* 高效的文本处理和语言分析 +你好杰克， -* 广泛的自动化可视化功能 +在本文中，我看到两个语句。 +->快速用于外部 API 缓存和交付 -* 自动导入 +-> Cloudfront 作为客户资产的 CDN -* 开发环境 - -### 信息来源 - -* [Wolfram | Alpha](http://www.wolframalpha.com/) - -* [关于 Wolfram | Alpha](http://www.wolframalpha.com/about.html) - -* [Wolfram | Alpha 博客](http://blog.wolframalpha.com/) - -* [Wolfram | Alpha 截屏简介](http://www.wolframalpha.com/screencast/introducingwolframalpha.html) - -* [一种新型科学](http://www.amazon.com/gp/product/1579550088?ie=UTF8&tag=innoblog-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1579550088) ![](img/ff91ab4b9da646c9390cc43d8e306d86.png) - -* [Wolfram Research](http://wolfram.com/) -Mathematica - -* [Mathematica 如何使 Wolfram | Alpha 成为可能？](http://www.wolfram.com/products/mathematica/madepossible/wolframalpha.html) - [](http://www.wolfram.com/products/mathematica/madepossible/wolframalpha.html) -* [](http://www.wolfram.com/products/mathematica/madepossible/wolframalpha.html)[Wolfram | Alpha 中的计算引擎背后的秘密](http://blog.wolframalpha.com/2009/05/01/the-secret-behind-the-computational-engine-in-wolframalpha/) - -* 预计将在发布后提供更多信息。敬请期待！ - -恭喜，斯蒂芬！ - -有趣的辩论： [http://seekingalpha.com/article/124787-wolfram-alpha-google-killer-or-google-acquisition-target“]( Wolfram Alpha：Google Killer 或 Google Acquisition Target ？ - -在当今的服务器设计中，10,000 个内核并不多。 令人惊讶的是，他们从使用 fbdimms 的 dell 中选择了 harpertown 平台。 圣克莱门特本来会更好。 我还想知道，鉴于性能方面的优势，为什么不选择 nehalems。 - -总计约有 1200 台服务器，每个服务器有 8 个 penryn 核心。 那大约是 30 个服务器机架，可能仅花费 300 万美元。 如今，商品服务器非常便宜。 让我们看看您可以从中获得多少性能。 - -谢谢极客。 走超级计算机路线非常有趣。 有钱真好！ - -听起来像 HAL9000： - -很抱歉，戴夫（Dave），我不能这样做... -Wolfram | Alpha 暂时超出了其当前的最大测试负载。 - -看起来 10000 核暂时还不够:-) - -NKS 可在此处在线获得： [http://www.wolframscience.com/nksonline/toc.html](http://www.wolframscience.com/nksonline/toc.html) - -第 1 章新型科学的基础 1 -第 2 章关键实验 23 -第 3 章简单程序的世界 51 -第 4 章基于数字的系统 115 -第 5 章二维及其他 169 -第 6 章从随机性开始 223 -第 7 章程序和自然机制 297 -第 8 章对日常系统的影响 363 -第 9 章基本物理学 433 -第 10 章感知和分析过程 547 -第 11 章计算概念 637 -第 12 章计算对等原理 715 - -博客样本：在美国东海岸的凌晨 3 点，从 geoIP 数据的样本中我们可以看出，有很多人在使用 Wolfram | Alpha 醒着。 这是地图上 5 秒的示例： -[http://blog.wolframalpha.com/2009/05/18/do-wolframalpha-users-ever-go-to-sleep/](http://blog.wolframalpha.com/2009/05/18/do-wolframalpha-users-ever-go-to-sleep/) - -截至目前，Wolfram | Alpha 每秒可提供 124 个查询。 - -您知道 Wolfram Alpha 架构的软件组件吗？ 它纯粹基于 Mathematica 吗？ 他们是否使用开源软件，例如 apache，mysql，memcached，hadoop 或 highscalability.com 上讨论的其他软件？ - -[http://www.infoq.com/news/2009/05/Wolfram-Alpha](http://www.infoq.com/news/2009/05/Wolfram-Alpha) - -通过 [http://www19.wolframalpha.com/faqs.html 可以部分解决 Wolfram | Alpha 体系结构中有关开源软件的问题。“](常见问题解答： - -Wolfram | Alpha 使用什么网络技术？ -其服务器技术基于访问 WebMathematica 服务器群集的 Apache Web 服务器。 在客户端，它使用 AJAX（JavaScript）。 - -这是新的云市场​​的开始吗：计算即服务？ Wolfram Alpha +开发人员 API：一个不错的组合！ - -[http://web2.sys-con.com/node/970448“]( Wolfram | Alpha 的计算即服务 - -[http://blog.wolframalpha.com/2009/05/26/the-first-week-of-wolframalpha-thank-you/“]( Wolfram | Alpha 的第一周：谢谢 ！： -距我们将 Wolfram | Alpha 正式发布到世界各地已经一周了； -真是很棒的第一周； -接近 1 亿个查询。很多赞美 -但对我而言，最 引人注目的是有多少人希望帮助 Wolfram | Alpha 成功 -使世界的知识可计算是一项艰巨的任务 -很高兴看到我们在这样做方面提供的所有帮助。 我们一直在努力构建一个框架，但是要实现可计算知识的全部承诺，我们需要大量的投入和支持 -而且值得注意的是，在短短的一周内，Wolfram 周围已经出现了一个整个社区 | Alpha，拥有我们自己的社区站点和许多独立站点 -我们收到了很多人的反馈，实际上，在过去 7 天里，我们获得了不少 将 55,000 条反馈消息发布到网站。 -建议。 鼓励。 更正。 显而易见的事情。 令人难以置信的事物。 -从某种程度上讲，它是压倒性的。 但这也是非常有用的。 -... - -来自 W | A 博客：一日打造罗马 - -如果您一直在关注 Wolfram | Alpha 的发布，那么您可能听说过，两个超级计算机级系统是幕后工作的重要组成部分。 其中之一是 R Smarr 系统，属于我们在 R Systems 的好朋友，在 [http://www.youtube.com/watch?hl=zh_CN & v = umEKJrlbw9s“](这部影片。另一部是我们自定义的 Dell 系统，在 [http://www.youtube.com/watch?v=qUFmqshsnXU“]( Rack'n'Roll 视频中突出显示。 在这两者之间，我们每秒可以处理大约 1800 个查询（qps）。 许多人问我们如何将所有这些基础架构整合在一起。 - -在博客上查看详细信息。 \ No newline at end of file +是否有特定原因将 Cloud Front 用作客户资产？ 为什么我们不能快速使用 CDN？ \ No newline at end of file diff --git a/docs/211.md b/docs/211.md index b78f9c1..6db859a 100644 --- a/docs/211.md +++ b/docs/211.md @@ -1,7 +1,699 @@ -# 在 Amazon EC2 中部署大规模基础架构的六个经验教训 +# Netflix：按下 Play 会发生什么？ -> 原文： [http://highscalability.com/blog/2009/4/7/six-lessons-learned-deploying-a-large-scale-infrastructure-i.html](http://highscalability.com/blog/2009/4/7/six-lessons-learned-deploying-a-large-scale-infrastructure-i.html) +> 原文： [http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html](http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html) -从 [OpenX 到 Amazon EC2 的大规模部署](http://agiletesting.blogspot.com/2009/04/experiences-deploying-large-scale.html)的经验教训： +![](img/6a3359436d64c01679e8b1e26e14e3c8.png) -* **预期会失败； 更重要的是，拥抱他们*** **完全自动化您的基础架构部署*** **设计基础架构，使其水平扩展*** **建立明确的可衡量目标*** **准备快速识别并消除瓶颈*** **玩一会儿，直到一切变得稳定** \ No newline at end of file +本文是我新书[中的一章，就像我 10 岁时一样解释云](https://smile.amazon.com/Explain-Cloud-Like-Im-10-ebook/dp/B0765C4SNR)。 第一版是专门为云新手编写的。 我进行了一些更新并添加了几章— *Netflix：按 Play 时会发生什么？* 和*什么是云计算？-*将其升级到比初学者高几个刻度。 我认为即使是经验丰富的人也可以从中受益。 + +我还在独立的 Kindle 电子书中创建了本文的某种扩展版本。 您可以在 [Netflix 上找到该电子书：按下 Play 会发生什么？](https://www.amazon.com/Netflix-What-Happens-When-Press-ebook/dp/B079ZKT9G8/) + +因此，如果您正在寻找关于云的良好介绍或认识某个人，请看一下。 我想你会喜欢的。 我为结果感到非常自豪。 + +我从几十个有时有些矛盾的资料中整理了这一章。 事实随着时间的流逝而变化，并且取决于谁在讲故事以及他们要针对的受众。 我试图创造尽可能连贯的叙述。 如果有任何错误，我很乐意修复。 请记住，本文不是技术性的深入探讨。 这是一篇大图文章。 例如，我什至没有提到*微服务*这个词：-) + +Netflix 似乎很简单。 按播放，视频就会神奇地出现。 容易吧？ 没那么多。 + +![](img/b9d4051f956df6493e0a56c86dec7509.png) + +鉴于我们在*中的讨论，什么是云计算？ 在*一章中，您可能希望 Netflix 使用 AWS 来提供视频。 在 Netflix 应用程序中按新闻播放，存储在 S3 中的视频将通过 Internet 从 S3 直接流式传输到您的设备。 + +完全明智的方法……以提供更小的服务。 + +但这根本不是 Netflix 的运作方式。 它比您想象的要复杂和有趣得多。 + +看看为什么我们来看看 2017 年一些令人印象深刻的 Netflix 统计数据。 + +* Netflix 拥有超过 1.1 亿订户。 +* Netflix 在 200 多个国家/地区运营。 +* Netflix 每季度的收入接近 30 亿美元。 +* Netflix 每季度增加超过 500 万新订户。 +* Netflix 每周播放超过 10 亿小时的视频。 相比之下，YouTube 每天流 10 亿小时的视频，而 Facebook 每天流 1.1 亿小时的视频。 +* Netflix 在 2017 年每天播放 2.5 亿小时的视频。 +* Netflix 占美国峰值互联网流量的 37％以上。 +* Netflix 计划在 2018 年在新内容上花费 70 亿美元。 + +**我们学到了什么？** + +Netflix 非常庞大。 他们是全球性的，拥有很多成员，播放很多视频，并且有很多钱。 + +另一个相关的事实是 Netflix 是基于订阅的。 会员每月支付 Netflix 费用，并可随时取消。 当您按 play 在 Netflix 上放松时，效果会更好。 不高兴的成员退订。 + +**我们要深入** + +Netflix 是我们讨论过的所有想法的绝妙示例，这就是为什么本章比我们介绍的其他云服务要详细得多的原因。 + +深入研究 Netflix 的一个重要原因是，他们可以提供比其他公司更多的信息。 + +Netflix 拥有*通信*作为核心[文化价值](https://www.slideshare.net/BarbaraGill3/netflix-culture-deck)。 Netflix 不仅仅符合其标准。 + +实际上，我要感谢 Netflix 如此开放的架构。 多年来，Netflix 就其运作方式进行了数百次演讲，并撰写了数百篇文章。 整个行业对此都更好。 + +在 Netflix 上进行大量详细介绍的另一个原因是 Netflix 令人着迷。 我们大多数人曾经一次或一次使用 Netflix。 谁会不喜欢在帘子后面偷看，看看是什么让 Netflix 滴答作响？ + +**Netflix 在两个云中运行：AWS 和 Open Connect。** + +Netflix 如何使会员满意？ 当然有了云。 实际上，Netflix 使用两种不同的云：AWS 和 Open Connect。 + +两种云必须无缝协作才能提供无数小时的客户满意视频。 + +**Netflix 的三个部分：客户端，后端，内容交付网络（CDN）。** + +您可以将 Netflix 分为三部分：客户端，后端和内容交付网络（CDN）。 + +*客户端*是用于浏览和播放 Netflix 视频的任何设备上的用户界面。 它可能是 iPhone 上的应用程序，台式计算机上的网站，甚至是智能电视上的应用程序。 Netflix 控制着每个设备的每个客户端。 + +在您按下*播放*之前发生的所有事情都发生在*后端*中，该后端在 AWS 中运行。 这包括准备所有新传入的视频以及处理来自所有应用程序，网站，电视和其他设备的请求。 + +按下*播放*后发生的所有事情均由 Open Connect 处理。 Open Connect 是 Netflix 的自定义全球内容交付网络（CDN）。 Open Connect 将 Netflix 视频存储在世界各地。 当您按播放时，来自 Open Connect 的视频流将进入您的设备，并由客户端显示。 不用担心 我们稍后再讨论 CDN 的含义。 + +有趣的是，在 Netflix，他们实际上并没有说*在视频*上大受欢迎，而是说*单击标题*上的开始。 每个行业都有自己的术语。 + +通过控制所有三个区域（客户端，后端，CDN），Netflix 已实现了完整的垂直整合。 + +Netflix 从始至终控制着您的视频观看体验。 这就是为什么当您从世界任何地方单击播放时，它都可以起作用的原因。 您可以在观看时可靠地获取要观看的内容。 + +让我们看看 Netflix 如何做到这一点。 + +## **在 2008 年，Netflix 开始转向 AWS** + +Netflix 于 1998 年成立。起初，他们通过美国邮政服务公司租借了 DVD。 但是 Netflix 看到了未来的点播视频流。 + +Netflix 在 2007 年推出了其点播流媒体服务，该服务使订户可以通过 Netflix 网站在个人计算机上或在各种受支持的平台上的 Netflix 软件（包括智能手机和平板电脑，数字媒体播放器，视频）流式传输电视连续剧和电影。 游戏机和智能电视。 + +就个人而言，点播视频流是未来，这似乎很明显。 是的。 我曾在几家尝试制作视频点播产品的初创公司工作。 他们失败了。 + +Netflix 成功。 Netflix 的表现肯定不错，但是他们迟到了，这对他们有所帮助。 到 2007 年，互联网已经足够快且便宜，足以支持流视频服务。 以前从未如此。 快速，低成本的移动带宽的增加以及功能强大的移动设备（如智能手机和平板电脑）的推出，使任何人都可以随时随地以流媒体的方式更轻松，更便宜。 时间就是一切。 + +## **Netflix 通过运行自己的数据中心开始** + +EC2 只是在 2007 年才开始使用，大约与 Netflix 的流媒体服务启动的时间相同。 Netflix 不可能使用 EC2 来启动。 + +Netflix 建立了两个彼此相邻的数据中心。 他们经历了我们在前面几章中讨论过的所有问题。 + +建立数据中心需要大量工作。 订购设备需要很长时间。 安装和使所有设备正常工作需要很长时间。 并且，一旦他们一切正常，它们将耗尽容量，整个过程必须重新开始。 + +设备的交货期长，迫使 Netflix 采用所谓的*垂直缩放*策略。 Netflix 制作了在大型计算机上运行的大型程序。 这种方法称为构建*整体*。 一个程序可以完成所有工作。 + +问题是，当您像 Netflix 一样快速成长时， 很难使整体可靠。 事实并非如此。 + +## **服务中断导致 Netflix 迁移到 AWS** + +在 2008 年 8 月的三天内，由于数据库损坏，Netflix 无法运送 DVD。 这是不可接受的。 Netflix 必须做点什么。 + +建立数据中心的经验告诉 Netflix 一个重要的教训-他们不擅长建立数据中心。 + +Netflix 擅长的是向其成员提供视频。 Netflix 宁愿集中精力于更好地提供视频，而不是擅长于构建数据中心。 建立数据中心并不是 Netflix 的竞争优势，而提供视频则是。 + +当时，Netflix 决定迁移到 AWS。 AWS 刚刚成立，因此选择 AWS 是一个大胆的举措。 + +Netflix 之所以选择 AWS，是因为它想要一个更可靠的基础架构。 Netflix 希望从其系统中消除任何单点故障。 AWS 提供了高度可靠的数据库，存储和冗余数据中心。 Netflix 想要云计算，因此不再需要构建大型的，不可靠的整体。 Netflix 希望在不构建自己的数据中心的情况下成为全球服务。 这些功能没有一个在其旧的数据中心中可用，甚至永远都不会。 + +Netflix 选择 AWS 的原因是，它不想做任何*无差别的繁重任务*。 无差别的繁重工作是必须要做的，但并不能为核心业务提供优质视频观看体验带来任何好处。 AWS 为 Netflix 进行了所有不可区分的繁重工作。 这使 Netflix 人专注于提供业务价值。 + +Netflix 花了八年多的时间才能完成从自己的数据中心到 AWS 的迁移过程。 在此期间，Netflix 的流媒体客户数量增长了八倍。 Netflix 现在可以在数十万个 EC2 实例上运行。 + +## **Netflix 在 AWS 中更可靠** + +并不是说 Netflix 从来没有经历过 AWS 停机的情况，但是总的来说，它的服务比以前更加可靠。 + +您再也不会看到这种抱怨了： + +![](img/e27dea3ea51097872f122794c88247ee.png) + +或这个： + +![](img/eb80a1891c5aeb8ed8cc659fcad32d18.png) + +Netflix 之所以如此可靠，是因为他们已采取非常规步骤来确保其服务的可靠性。 + +Netflix 在三个 AWS 区域中运营：一个位于北弗吉尼亚州，一个位于俄勒冈州波特兰市和一个位于爱尔兰都柏林。 在每个区域内，Netflix 在三个不同的可用区中运营。 + +Netflix 表示没有计划在更多地区开展业务。 添加新区域非常昂贵且复杂。 大多数公司在一个地区开展业务，更不用说两个或三个了。 + +具有三个区域的优点是任何一个区域都可能发生故障，而其他区域将介入处理发生故障的区域中的所有成员。 当区域出现故障时，Netflix 将此*撤离*。 + +让我们举个例子。 假设您正在英国伦敦观看新的*纸牌屋*。 因为它距离伦敦最近，所以您的 Netflix 设备很可能已连接到都柏林地区。 + +如果整个都柏林地区失败了怎么办？ 这是否意味着 Netflix 应该停止为您服务？ 当然不是！ + +Netflix 检测到故障后，会将您重定向到弗吉尼亚。 您的设备现在可以与弗吉尼亚州地区通话，而不是都柏林通话。 您甚至可能没有注意到发生了故障。 + +AWS 区域多久发生一次故障？ 每月一次。 嗯，一个地区实际上并不是每个月都会失败。 Netflix 每月进行一次测试。 Netflix 每个月都会故意导致区域故障，以确保其系统可以处理区域级别的故障。 一个区域可以在六分钟内撤离。 + +Netflix 将其称为*全球服务模型*。 任何客户都可以在任何地区以外的地方服务。 这真太了不起了。 而且它不会自动发生。 AWS 无法处理区域故障或为多个区域的客户提供服务。 Netflix 独自完成了所有这些工作。 Netflix 是弄清楚如何使用多个区域创建可靠系统的先驱。 我不知道有其他公司会竭尽所能使他们的服务如此可靠。 + +在这三个地区中的另一个优势是，它使 Netflix 遍及全球。 Netflix 进行了一些测试，发现如果您在世界任何地方使用 Netflix 应用程序，都会从这三个地区之一获得快速服务。 + +## **Netflix 在 AWS 中省钱** + +这可能会让很多人感到惊讶，但是 AWS 比 Netflix 便宜。 每个流视图的云成本最终只是其旧数据中心成本的一小部分。 + +为什么？ 云的弹性。 + +Netflix 可以在需要时添加服务器，并在不需要时将其退还。 Netflix 不必拥有大量额外的计算机，只是为了处理高峰负载而无所事事，而仅在需要时才支付所需的费用。 + +我们在*中讨论的所有内容什么是云计算*？ 章节。 + +## **在按下 Play 之前，AWS 会发生什么？** + +任何不涉及提供视频的内容都将在 AWS 中处理。 + +这包括可伸缩计算，可伸缩存储，业务逻辑，可伸缩分布式数据库，大数据处理和分析，推荐，转码以及数百种其他功能。 + +不用担心，您不需要了解所有这些内容，但是由于您可能会发现它很有趣，因此我将对其进行简要说明。 + +**可扩展计算和可扩展存储。** + +*可伸缩计算*为 EC2，*可伸缩存储*为 S3。 在这里对我们来说没有什么新鲜的。 + +您的 Netflix 设备（iPhone，TV，Xbox，Android 手机，平板电脑等）与 EC2 中运行的 Netflix 服务进行对话。 + +查看可能要观看的视频列表？ 这就是您的 Netflix 设备正在与 EC2 中的计算机联系以获取列表。 + +询问有关视频的更多详细信息？ 这就是您的 Netflix 设备正在与 EC2 中的计算机联系以获取详细信息。 + +就像本书中提到的所有其他云服务一样。 + +**可扩展的分布式数据库。** + +Netflix 将 DynamoDB 和 Cassandra 都用于其分布式数据库。 这些名称对您而言并不意味着什么，它们只是高质量的数据库产品。 + +*数据库*。 数据库存储数据。 您的个人资料信息，帐单信息，您曾经看过的所有电影以及所有此类信息都存储在数据库中。 + +*已分发。* 分布式表示数据库不在一台大型计算机上运行，​​而是在多台计算机上运行。 您的数据将复制到多台计算机，因此，如果一台或什至两台保存数据的计算机发生故障，您的数据将是安全的。 实际上，您的数据已复制到所有三个区域。 这样，如果某个区域发生故障，那么当新区域准备开始使用它时，您的数据就会在那里。 + +*可扩展*。 可伸缩性意味着数据库可以处理您想要放入的尽可能多的数据。 这是分布式数据库的一大优势。 可以根据需要添加更多计算机以处理更多数据。 + +**大数据处理和分析。** + +*大数据*只是意味着有很多数据。 Netflix 收集了大量信息。 Netflix 知道每个人观看时都观看了什么，观看时所处的位置。 Netflix 知道成员观看了哪些视频，但决定不观看。 Netflix 知道每个视频被观看了多少次……还有更多。 + +将所有数据以标准格式放入称为*处理*。 + +理解所有这些数据称为*分析*。 分析数据以回答特定问题。 + +**Netflix 只为您个性化艺术品。** + +这是一个很好的例子，说明 Netflix 如何利用其数据分析功能吸引您观看更多视频。 + +在四处寻找在 Netflix 上观看的内容时，您是否注意到每个视频始终显示一个图像？ 这就是*标头图片*。 + +标题图片旨在吸引您，吸引您选择视频。 这个想法是标题图像越引人注目，您观看视频的可能性就越大。 而且，您观看的视频越多，您退订 Netflix 的可能性就越小。 + +这是*陌生事物*的不同标题图片的示例： + +![](img/bb281d98db0ebb33c7d2e11f52846f41.png) + +了解为每个视频专门选择的显示图像可能会让您感到惊讶。 并非所有人都看到相同的图像。 + +以前每个人都看到相同的标题图像。 运作方式如下。 成员从一组选项中随机显示一张图片，如上面 *Stranger Things* 拼贴中的图片。 Netflix 会在每次观看视频时进行计数，记录选择视频时显示的图片。 + +对于我们的*陌生事物*示例，假设显示了中央的合影时，*陌生事物*被观看了 1,000 次。 对于所有其他图片，每张只被观看了一次。 + +由于组图片是吸引成员观看的最佳方式，因此 Netflix 会使其永远成为 *Stranger Things* 的标题图像。 + +这称为*数据驱动*。 Netflix 以数据驱动公司而闻名。 在这种情况下，将收集数据（在这种情况下为与每张图片关联的视图数），并用于做出最佳决策（选择哪种标题图像）。 + +聪明，但您能想象做得更好吗？ 是的，通过使用更多数据。 这就是未来的主题-通过学习数据来解决问题。 + +你和我可能是截然不同的人。 您是否认为我们受到相同类型的标题图像的激励？ 可能不是。 我们有不同的口味。 我们有不同的偏好。 + +Netflix 也知道这一点。 因此，Netflix 现在可以个性化显示给您的所有图像。 Netflix 会尝试选择与您的视频最相关的艺术品。 他们是如何做到的？ + +请记住，Netflix 记录并统计您在其网站上所做的一切。 他们知道您最喜欢哪种电影，最喜欢哪些演员，等等。 + +假设您的建议之一是电影*善意狩猎*。 Netflix 必须选择标题图像才能显示给您。 目标是显示一张图像，让您了解可能感兴趣的电影。Netflix 应该向您显示哪张图像？ + +如果您喜欢喜剧，Netflix 会向您展示罗宾·威廉姆斯（Robin Williams）的图像。 如果您更喜欢浪漫电影，则 Netflix 会向您显示马特·达蒙（Mat Damon）和米妮·德米妮（Minnie Driver）准备亲吻的图像。 + +![](img/cfb549f0a6707cc5954d71140b5d282e.png) + +通过向罗宾·威廉姆斯（Robin Williams）展示，Netflix 使您知道电影中可能有幽默感，并且因为 Netflix 知道您喜欢喜剧，所以该视频非常适合。 + +Matt Damon 和 Minnie Driver 的图像传达了完全不同的信息。 如果您是喜剧迷并且看到了这张图片，则可以跳过。 + +这就是为什么选择正确的标题图片如此重要的原因。 它发送强烈的个性化信号，指示电影的内容。 + +这是另一个示例*低俗小说*。 + +![](img/d59d96ae3828b0a59384aa94296cbbf1.png) + +如果您看过很多由乌玛·瑟曼（Uma Thurman）主演的电影，那么您很可能会看到乌玛（Uma）的标题图片。 如果您看过很多由约翰·特拉沃尔塔（John Travolta）主演的电影，那么您很可能会看到约翰（John）的标题图片。 + +您能看到选择最佳个性化艺术品如何使您更有可能观看特定视频吗？ + +Netflix 在选择艺术品时会吸引您的兴趣，但 Netflix 也不想骗您。 他们不想显示 clickbait 图片只是为了让您观看您可能不喜欢的视频。 这没有任何动机。 Netflix 不按观看的视频付费。 Netflix 尝试将*的遗憾降到最低。 Netflix 希望您对观看的视频感到满意，因此他们会选择最适合您的标头图像。* + +这只是 Netflix 如何使用数据分析的一个小例子。 Netflix 到处都采用这种策略。 + +**建议。** + +Netflix 通常只会向您显示 40 到 50 个视频选项，但是它们有成千上万个视频可用。 + +Netflix 如何决定？ 使用机器学习。 + +这就是我们刚才讨论的*大数据处理和分析*的一部分。 Netflix 会查看其数据并预测您的需求。 实际上，您在 Netflix 屏幕上看到的所有内容都是使用机器学习专门为您选择的。 + +## **从源媒体到您所观看内容的转码** + +在这里，我们开始过渡到 Netflix 处理视频的方式。 + +Netflix 必须先将视频转换为最适合您的设备的格式，然后才能在您喜欢的所选设备上观看视频。 此过程称为*转码*或*编码*。 + +转码是将视频文件从一种格式转换为另一种格式，以使视频可以在不同平台和设备上观看的过程。 + +Netflix 一次将多达 300,000 个 CPU 的所有视频编码在 AWS 中。 比大多数超级计算机都大！ + +**源媒体的来源。** + +谁向 Netflix 发送视频？ 制作室和工作室。 Netflix 将此视频称为*源媒体*。 新视频将提供给*内容运营团队*进行处理。 + +该视频采用高清格式，大小为 TB 级。 TB 很大。 想象 60 叠像埃菲尔铁塔一样高的纸。 太太了。 + +在您观看视频之前，Netflix 会通过严格的多步骤过程对其进行处理。 + +![](img/8f33c24a44671cd5054d5919397be5d2.png) + +**验证视频。** + +Netflix 要做的第一件事是花费大量时间来验证视频。 它查找可能由先前的代码转换尝试或数据传输问题引起的数字伪像，颜色变化或丢失的帧。 + +如果发现任何问题，视频将被拒绝。 + +**进入媒体管道。** + +验证视频后，将其输入到 Netflix 所谓的*媒体管道*中。 + +*管道*只是一系列步骤，需要经过一系列步骤才能使数据准备就绪，就像工厂的流水线一样。 70 多种不同的软件可帮助您制作每个视频。 + +处理单个多 TB 大小的文件是不切实际的，因此，管道的第一步是将视频分成许多较小的块。 + +然后将视频块通过管道放置，以便可以并行对其进行编码。 并行仅表示在同一时间处理块。 + +让我们用一个例子来说明并行性。 + +![](img/b28fc97bf91bbf4b14de00e2b47f98c5.png) + +假设您有一百只需要洗的脏狗。 一个人一个接一个地洗狗，哪个会更快？ 还是租用一百个洗狗器同时洗一次会更快？ + +显然，同时使用一百只狗狗洗衣机更快。 那是并行性。 这就是 Netflix 在 EC2 中使用如此多服务器的原因。 他们需要大量服务器来并行处理这些巨大的视频文件。 它也可以。 Netflix 表示，可以在短短 30 分钟之内对源媒体文件进行编码并将其推送到 CDN。 + +编码后，将对它们进行验证，以确保没有引入新的问题。 + +然后将这些块组装回一个文件中，并再次进行验证。 + +**结果是一堆文件。** + +编码过程会创建很多文件。 为什么？ Netflix 的最终目标是支持每台联网设备。 + +Netflix 于 2007 年开始在 Microsoft Windows 上流式传输视频。 随着时间的推移，增加了更多设备-Roku，LG，三星蓝光，Apple Mac，Xbox 360，LG DTV，Sony PS3，Nintendo Wii，Apple iPad，Apple iPhone，Apple TV，Android，Kindle Fire 和 Comcast X1。 + +Netflix 总共支持 2200 种不同的设备。 每个设备都具有在该特定设备上看起来最佳的视频格式。 如果您在 iPhone 上观看 Netflix，则会看到一个视频，该视频可为您提供最佳的 iPhone 观看体验。 + +Netflix 将视频的所有不同格式称为*编码配置文件*。 + +Netflix 还创建针对不同网络速度优化的文件。 如果您在快速网络上观看，则观看的视频质量会比在慢速网络上观看时的观看质量更高。 + +也有用于不同音频格式的文件。 音频被编码为不同质量级别和不同语言。 + +也包括字幕文件。 视频可能具有多种不同语言的字幕。 + +每个视频都有很多不同的观看选项。 您看到的内容取决于您的设备，网络质量，Netflix 计划以及您的语言选择。 + +**我们正在讨论多少文件？** + +对于 *The Crown，* Netflix 存储了约 1200 个文件！ + +*陌生人事物*第 2 季有更多文件。 它以 8K 拍摄，有 9 集。 源视频文件有很多太字节的数据。 仅编码一个季节就花费了 190,000 个 CPU 小时。 + +结果？ 9,570 种不同的视频，音频和文本文件！ + +让我们看看 Netflix 如何播放所有视频。 + +## **三种不同的流媒体视频策略** + +Netflix 尝试了自己的小型 CDN 三种不同的视频流策略； 第三方 CDN； 和打开连接。 + +首先定义 CDN。 CDN 是*内容分发网络*。 + +Netflix 的*内容*当然是我们在上一节中讨论的视频文件。 + +*分发*表示视频文件是通过*网络*从中央位置复制的，并存储在世界各地的计算机上。 + +对于 Netflix，存储视频的中心位置是 S3。 + +## **为什么要建立 CDN？** + +CDN 背后的想法很简单：通过在全球范围内传播计算机，使视频尽可能接近用户。 当用户想要观看视频时，请找到带有视频的最近的计算机，然后从那里流式传输到设备。 + +CDN 的最大好处是速度和可靠性。 + +想象一下，您正在伦敦观看视频，并且该视频是从俄勒冈州波特兰市流传输的。 视频流必须通过许多网络，包括海底电缆，因此连接速度慢且不可靠。 + +通过将视频内容尽可能靠近观看者移动，观看体验将尽可能快且可靠。 + +具有存储视频内容的计算机的每个位置称为 PoP 或*存在点*。 每个 PoP 都是提供访问 Internet 的物理位置。 它容纳服务器，路由器和其他电信设备。 稍后我们将详细讨论 PoP。 + +## **第一个 CDN 太小** + +2007 年，当 Netflix 首次推出其新的流媒体服务时，它在 50 个国家/地区拥有 3600 万会员，每月观看超过十亿小时的视频，每秒流式传输数 TB 的内容。 + +为了支持流媒体服务，Netflix 在美国的五个不同位置构建了自己的简单 CDN。 + +当时，Netflix 视频目录足够小，每个位置都包含其所有内容。 + +## **第二个 CDN 太大** + +在 2009 年，Netflix 决定使用第三方 CDN。 大约在这个时候，第三方 CDN 的价格下降了。 + +对于 Netflix，使用第三方 CDN 非常合理。 当您可以使用现有的 CDN 服务立即到达全球时，为什么还要花费所有时间和精力来构建自己的 CDN？ + +Netflix 与 Akamai，Limelight 和 Level 3 等公司签订了合同，提供 CDN 服务。 使用第三方 CDN 没错。 实际上，几乎每个公司都这样做。 例如，NFL 使用 Akamai 直播足球比赛。 + +通过不构建自己的 CDN，Netflix 有更多时间来从事其他更高优先级的项目。 + +Netflix 在开发更智能的客户端上投入了大量时间和精力。 Netflix 创建了适应不断变化的网络条件的算法。 即使面对错误，网络过载和服务器过载，Netflix 仍希望成员始终查看最佳图像。 Netflix 开发的一种技术是切换到另一个视频源（例如另一个 CDN 或另一个服务器），以获得更好的效果。 + +同时，Netflix 还为我们之前提到的所有 AWS 服务投入了大量精力。 Netflix 将 AWS 中的服务称为*控制平面*。 控制平面是一个电信术语，用于标识控制其他所有部分的系统部分。 在你的身体里，你的大脑是控制平面。 它控制着其他一切。 + +然后，Netflix 认为通过开发自己的 CDN 可以做得更好。 + +## **开放式连接正好** + +在 2011 年，Netflix 意识到需要大规模的 CDN 解决方案以最大化网络效率。 视频分发是 Netflix 的核心竞争力，并且可能是巨大的竞争优势。 + +因此，Netflix 开始开发自己的专用 CDN Open Connect。 Open Connect 于 2012 年推出。 + +Open Connect 对于 Netflix 具有很多优势： + +* 不会那么贵。 第三方 CDN 昂贵。 自己做可以节省很多钱。 +* 更好的质量。 通过控制整个视频路径（代码转换，CDN，设备上的客户端），Netflix 认为它可以提供出色的视频观看体验。 +* 更可扩展。 Netflix 的目标是在世界各地提供服务。 快速提供支持，同时提供高质量的视频观看体验，这需要构建自己的系统。 + +第三方 CDN 必须支持用户从世界任何地方访问任何种类的内容。 Netflix 的工作要简单得多。 + +Netflix 确切知道其用户是谁，因为他们必须订阅 Netflix。 Netflix 确切知道需要提供哪些视频。 知道它只需要提供大量视频流，就可以让 Netflix 做出许多其他 CDN 无法做出的明智优化选择。 Netflix 也对会员了解很多。 该公司知道他们喜欢观看哪些视频以及何时观看。 + +有了这种知识，Netflix 就构建了一个非常出色的 CDN。 让我们详细了解 Open Connect 的工作原理。 + +## **开放式连接设备** + +还记得我们怎么说 CDN 的计算机遍布全球吗？ + +Netflix 开发了自己的视频存储计算机系统。 Netflix 称它们为 Open Connect 设备或 OCA。 + +这是在站点中早期安装 OCA 的样子： + +![](img/16f51c928a8c1dfaa02465da7b9a1d58.png) + +上图中有许多 OCA。 OCA 分为多个服务器的群集。 + +每个 OCA 都是一台快速服务器，经过高度优化，可传送大文件，并带有大量用于存储视频的硬盘或闪存驱动器。 + +以下是一台 OCA 服务器的外观： + +![](img/002abec7cdc33524f8bfe96565fe689f.png) + +有几种不同类型的 OCA 用于不同目的。 有大型 OCA 可以存储 Netflix 的整个视频目录。 有较小的 OCA，它们只能存储 Netflix 视频目录的一部分。 小型的 OCA 每天在非高峰时段都通过 Netflix 调用*主动 cachin* g 的过程填充视频。 稍后，我们将详细讨论主动缓存的工作原理。 + +从硬件的角度来看，OCA 没有什么特别的。 它们基于商用 PC 组件，并由各种供应商在定制情况下组装。 如果需要，您可以购买相同的计算机。 + +请注意，所有 Netflix 的计算机都是红色的吗？ Netflix 的计算机经过专门设计以匹配其徽标颜色。 + +从软件角度看，OCA 使用 FreeBSD 操作系统和 NGINX 作为 Web 服务器。 是的，每个 OCA 都有一个 Web 服务器。 使用 NGINX 的视频流。 如果这些名称都没有意义，请放心，我只是为了完整性而将它们包括在内。 + +站点上的 OCA 数量取决于 Netflix 希望站点的可靠性，从该站点传递的 Netflix 流量（带宽）的数量以及站点允许流式传输的流量的百分比。 + +当您按下播放键时，您正在观看附近特定位置来自特定 OCA 的视频流。 + +为了获得最佳的视频观看体验，Netflix 真正想要做的就是将视频缓存在您的房屋中。 但这还不可行。 其次，最好是将迷你 Netflix 尽可能靠近您的房屋放置。 他们是如何做到的？ + +## **Netflix 将 Open Connect Appliances（OCA）放在哪里？** + +Netflix 从全球 1000 多个位置的数千台服务器提供大量视频流量。 看看这张视频投放位置的地图： + +![](img/f05b05fbe69b129c9a82653b9bf65370.png) + +YouTube 和 Amazon 等其他视频服务在其自己的骨干网络上交付视频。 这些公司从字面上构建了自己的全球网络，用于向用户交付视频。 这是非常复杂且非常昂贵的。 + +Netflix 采用了完全不同的方法来构建其 CDN。 + +Netflix 不运营自己的网络； 它也不再运行自己的数据中心。 相反，互联网服务提供商（ISP）同意将 OCA 放入其数据中心。 OCA 是免费提供给 ISP 的，以嵌入其网络。 Netflix 还将 OCA 放置在互联网交换位置（IXP）中或附近。 + +使用这种策略，Netflix 不需要操作自己的数据中心，但是它获得了仅在其他人的数据中心中的常规数据中心的所有好处。 天才！ + +最后两段内容非常密集，因此我们将其分解。 + +**使用 ISP 来构建 CDN。** + +ISP 是您的互联网提供商。 您是从谁那里获得互联网服务的。 它可能是 Verizon，Comcast 或数千种其他服务。 + +这里的要点是 ISP 位于世界各地，并且与客户关系密切。 通过将 OCA 放置在 ISP 数据中心中，Netflix 也遍布全球，并且与客户关系密切。 + +**使用 IXP 构建 CDN。** + +Internet 交换位置是 ISP 和 CDN 在其网络之间交换 Internet 流量的数据中心。 就像参加聚会与您的朋友交换圣诞节礼物一样。 如果每个人都在一个地方，则交换礼物更容易。 如果每个人都在一个地方，则交换网络流量会更容易。 + +IXP 位于世界各地： + +![](img/46644609ddc19a440c5cdc9abd8c40b0.png) + +*TeleGeography 的 Internet 交换图* + +伦敦互联网交易所的外观如下： + +![](img/610a3afc1eed0b08497739c99c9a30cd.png) + +*伦敦互联网交换所（LINX）* + +深入查看那些黄色的光缆，您将在荷兰阿姆斯特丹的 AMS-IX Internet 交换点看到类似的内容： + +![](img/bec41838bb4817de47c185284cec94e7.png) + +*Wikimedia Commons* + +上图中的每条导线将一个网络连接到另一个网络。 这就是不同的网络相互交换流量的方式。 + +IXP 就像高速公路的立交桥，仅使用电线： + +![](img/149f9e40165ba99f24097eb897306995.png) + +*Wikimedia Commons* + +对于 Netflix 而言，这是另一个胜利。 IXP 遍布全球。 因此，通过将其 OCA 放入 IXP 中，Netflix 不必运行自己的数据中心。 + +## **每天都会主动将视频缓存到 OCA** + +Netflix 的所有视频都位于 S3 中。 他们拥有所有这些视频服务计算机，分布在世界各地。 只缺少一件事：视频！ + +Netflix 使用它称为*主动缓存*的过程来有效地将视频复制到 OCA。 + +**什么是缓存？** + +藏匿处是藏有弹药，食物和宝藏的地方，尤其是地下藏身的地方。 + +你知道冬天松鼠会埋坚果吗？ + +![](img/0cf00e4e5c31eec5dbcecf3d6249356f.png) + +他们埋没螺母的每个位置都是*缓存*。 在冬季，任何松鼠都可以找到坚果藏起来并砍掉。 + +北极探险者派小队向前走，沿着他们走的路线储存食物，燃料和其他物资。 后面的较大团队将在每个缓存位置停止并重新供应。 + +松鼠和北极探险家都*活跃*； 他们提前做一些事情，为以后做准备。 + +每个 OCA 都是您最有可能希望观看的视频的视频缓存。 + +**Netflix 通过预测您想要观看的内容来缓存视频。** + +Netflix 在世界任何地方都非常准确地知道其会员喜欢观看什么以及何时观看。 还记得我们曾说过 Netflix 是一家数据驱动公司吗？ + +Netflix 使用其受欢迎程度数据来*预测*成员明天可能希望在每个位置观看的视频。 在此，*位置*表示容纳在 ISP 或 IXP 中的 OCA 集群。 + +Netflix 将预测的视频复制到每个位置的一个或多个 OCA。 这称为*前置*。 视频甚至可以在任何人问到之前放在 OCA 上。 + +这为会员提供了很棒的服务。 他们想要观看的视频已经接近他们，可以进行流式传输了。 + +Netflix 运行所谓的*分层缓存系统。* + +![](img/aae5cd8bf6da74a03477b4761653228e.png) + +我们之前讨论的较小的 OCA 位于 ISP 和 IXP 中。 这些文件太小，无法包含整个 Netflix 视频目录。 其他位置的 OCA 包含 Netflix 大部分视频目录。 尽管如此，其他位置仍具有包含整个 Netflix 目录的大型 OCA。 这些都是从 S3 获得他们的视频。 + +每天晚上，每个 OCA 都会醒来，并向 AWS 的服务询问应包含哪些视频。 AWS 的服务根据我们之前提到的预测向 OCA 发送了应该包含的视频列表。 + +每个 OCA 都负责确保列表中包含所有视频。 如果位于同一位置的 OCA 拥有应有的视频之一，则它将复制本地 OCA 的视频。 否则，将找到并复制带有视频的附近 OCA。 + +由于 Netflix 预测明天会流行什么，因此通常需要一天的时间才能将视频放到 OCA 上。 这意味着可以在安静的非高峰时段复制视频，从而大大减少了 ISP 的带宽使用。 + +Open Connect 中永远不会出现*缓存未命中*的情况。 高速缓存未命中将要求 OCA 提供特定的视频，而 OCA 则说它没有该视频。 高速缓存未命中总是在其他 CDN 上发生，因为您无力将内容复制到任何地方。 由于 Netflix 知道必须缓存的所有视频，因此它始终知道每个视频的确切位置。 如果较小的 OCA 没有视频，则始终可以保证其中一个较大的 OCA 具有视频。 + +Netflix 为什么不将他们的所有视频复制到世界上每个 OCA？ 其视频目录太大，无法在所有位置存储所有内容。 2013 年，Netflix 的视频目录超过 3 PB。 我不知道今天有多大，但我只能假设它很大。 + +这就是为什么 Netflix 开发了一种方法，该方法使用*预测*他们的会员想要观看的数据，选择在每个 OCA 上存储哪些视频。 + +让我们举个例子。 *纸牌屋*是一个非常受欢迎的节目。 应该将其复制到哪些 OCA？ 可能是每个地点，因为全世界的成员都想观看纸牌屋。 + +如果视频不像《纸牌屋》那么受欢迎怎么办？ Netflix 决定应将其复制到哪个位置，以最好地满足附近的会员请求。 + +在一个地点中，像《纸牌屋》这样的热门视频被复制到许多不同的 OCA 中。 视频越受欢迎，它将被复制到更多的服务器。 为什么？ 如果只有一个非常受欢迎的视频的副本，则将视频流传输给成员将使服务器不堪重负。 正如他们所说，许多指针可以使灯工作。 + +将视频仅复制到一个 OCA 时，该视频不会被视为实时视频。 Netflix 希望能够在世界各地同时播放相同的内容。 仅当有足够数量的 OCA，且具有足够的视频副本以适当地提供它时，该视频才被视为直播且可供成员观看。 + +例如，2016 年 *Daredevil* 第 2 季是 Netflix 首次同时在所有国家/地区的所有设备上放映该节目的所有剧集。 + +## **托管 OCA：ISP 中有哪些内容？** + +ISP 为什么会同意将 OCA 群集放入其网络中？ 乍一看，它看起来过于宽大，但是您会很高兴知道它根植于自身利益。 + +要了解原因，我们需要讨论网络的工作方式。 我知道在整本书中我们都说过可以通过互联网访问云服务。 Netflix 并非如此，至少在观看视频时如此。 使用 Netflix App 时，它通过互联网与 AWS 对话。 + +互联网是网络的互连。 您有提供 Internet 服务的 ISP。 我从康卡斯特获得了互联网服务。 那意味着我的房子使用光缆连接到康卡斯特的网络。 Comcast 的网络就是他们的网络； 不是互联网，而是互联网。 + +假设我要进行 Google 搜索，然后在浏览器中输入查询，然后按 Enter。 + +我对 Google 的请求首先通过 Comcast 的网络传输。 Google 不在 Comcast 的网络上。 在某些时候，我的请求必须转到 Google 的网络。 这就是互联网的目的。 + +互联网将 Comcast 的网络连接到 Google 的网络。 这些被称为*路由协议*的事物的行为类似于流量警察，指示网络流量的去向。 + +当我的 Google 查询路由到互联网时，它不再位于 Comcast 的网络上，也不再位于 Google 的网络上。 它位于*互联网主干网*上。 + +互联网由许多选择互操作的私有网络组成。 我们前面介绍的 IXP 是网络相互连接的一种方式。 + +在美国，这是远程光纤网络的地图： + +![](img/764f6ce2c3075b2d60fe480c95a427f9.png) + +*InterTubes：对美国远程光纤基础设施的研究* + +Netflix 对 Open Connect 所做的工作是将其 OCA 群集放置在 ISP 网络内。 这意味着，如果我观看 Netflix 视频，我将与 Comcast 网络中的 OCA 交谈。 我所有的视频流量都在 Comcast 的网络上； 它永远不会上网。 + +扩展视频传输的关键是尽可能接近用户。 执行此操作时，您不会使用 Internet 主干。 在网络的本地部分上满足请求。 + +为什么这是一件好事？ 回想一下，我们说 Netflix 已经消耗了美国 37％以上的互联网流量。 如果 ISP 不合作，Netflix 将使用更多的互联网。 互联网无法处理所有视频流量。 ISP 必须增加更多的网络容量，而这是昂贵的。 + +目前，ISP 网络中最多可提供 Netflix 内容的 100％。 通过减轻 ISP 的互联网拥塞，可以降低成本。 同时，Netflix 会员体验到高质量的观看体验。 网络性能为每个人提高。 + +这是双赢。 + +## **开放连接可靠且具有弹性** + +之前我们讨论了 Netflix 如何通过耗尽三个不同的 AWS 区域来提高其系统的可靠性。 Open Connect 的体系结构实现了相同的目标。 + +可能不是立即显而易见的是，OCA 彼此独立。 OCA 充当自给自足的视频服务群岛。 当其他 OCA 发生故障时，从一个 OCA 流式传输的成员不会受到影响。 + +OCA 失败时会发生什么？ 您使用的 Netflix 客户端会立即切换到另一个 OCA，并恢复流式传输。 + +如果一个地点有太多人使用 OCA，该怎么办？ Netflix 客户端将发现要使用的负载更轻的 OCA。 + +如果成员用来流视频的网络过载了怎么办？ 同样的事情。 Netflix 客户端将在性能更好的网络上找到另一个 OCA。 + +Open Connect 是一个非常可靠且具有弹性的系统。 + +## **Netflix 控制客户端** + +Netflix 可以优雅地处理故障，因为它可以控制运行 Netflix 的每台设备上的客户端。 + +Netflix 自己开发 Android 和 iOS 应用程序，因此您可能希望它们来控制它们。 但是，即使在像 Netflix 这样没有构建客户端的智能电视这样的平台上，Netflix 仍然可以控制它，因为它可以控制*软件开发套件*（SDK）。 + +SDK 是*，一组允许开发应用程序的软件开发工具。* 每个 Netflix 应用都向 AWS 发出请求，并使用 SDK 播放视频。 + +通过控制 SDK，Netflix 可以一致且透明地适应慢速网络，失败的 OCA 以及可能出现的任何其他问题。 + +## **最后：这是您按 Play 时会发生的情况** + +到达这里很漫长。 我们学到了很多。 到目前为止，这是我们学到的知识： + +* Netflix 可以分为三个部分：后端，客户端和 CDN。 +* 来自 Netflix 客户端的所有请求均在 AWS 中处理。 +* 所有视频均来自 Open Connect CDN 中附近的 Open Connect 设备（OCA）。 +* Netflix 在三个 AWS 区域之外运营，通常可以处理任何区域的故障，甚至无需成员注意。 +* Netflix 将新的视频内容转换为多种格式，因此可以根据设备类型，网络质量，地理位置和会员的订阅计划选择最佳格式进行观看。 +* Netflix 每天都会通过 Open Connect，根据他们预测每个位置的会员想要观看的内容在世界各地分发视频。 + +这是 Netflix 如何描述播放过程的图片： + +[ ![](img/a74b8e62b0637c0ce6ea63384200af1b.png) + +现在，让我们完成图片： + +* 您选择要在某些设备上运行的客户端观看的视频。 客户端向在 AWS 中运行的 Netflix 的*回放应用*服务发送*播放*请求，指示您要播放哪个视频。 +* 我们之前没有讨论过，但是在您上演之后发生的大部分事情都与许可有关。 并非世界上每个地方都有观看每个视频的许可证。 Netflix 必须确定您是否具有观看特定视频的有效许可证。 我们不会谈论它是如何工作的-这确实很无聊-但请记住，它一直在发生。 Netflix 开始开发自己的内容的原因之一是避免许可问题。 Netflix 希望同时向全球所有人放映节目。 创建自己的内容是 Netflix 避免担心许可问题的最简单方法。 +* 考虑到所有相关信息，Playback Apps 服务将返回最多十个不同 OCA 服务器的 URL。 这些是您一直在 Web 浏览器中使用的相同 URL。 Netflix 使用您的 IP 地址和来自 ISP 的信息来确定最适合您使用的 OCA 群集。 +* 客户端可以智能地选择要使用的 OCA。 它通过测试与每个 OCA 的网络连接的质量来做到这一点。 它将首先连接到最快，最可靠的 OCA。 客户端会在整个视频流传输过程中继续运行这些测试。 +* 客户端进行调查以找出从 OCA 接收内容的最佳方法。 +* 客户端连接到 OCA，然后开始将视频流式传输到您的设备。 +* 您是否在观看视频时注意到图像质量有所不同？ 有时看起来像是像素化，过了一会儿图像又恢复为高清画质了吗？ 那是因为客户正在适应网络质量。 如果网络质量下降，客户端将降低视频质量以使其匹配。 当质量下降太多时，客户端将切换到另一个 OCA。 + +当您在 Netflix 上按播放时，就会发生这种情况。 谁会想到这么简单的事情，就像观看视频那么复杂？ + +## 相关文章 + +* [在 HackerNews](https://news.ycombinator.com/item?id=15901967) 和[在 HackerNews](https://news.ycombinator.com/item?id=15986753) +* [在 Reddit 上](https://www.reddit.com/r/tech/comments/7j6j99/netflix_what_happens_when_you_press_play/)和[在 Reddit 上](https://www.reddit.com/r/programming/comments/7m1aug/netflix_what_happens_when_you_press_play_high/) + +很好的文章！ + +但是封面选择信息已经过时：https：//medium.com/netflix-techblog/artwork-personalization-c589f074ad76 + +在完成本章后，Netflix 如何粗鲁地改变事情:-) + +看起来是一个很大的变化。 他们不是为所有人选择一张图像，而是对其进行个性化设置。 整 rick + +优秀文章，谢谢 + +感谢您的博客文章，我从开始乞讨到结束 + +我更新了帖子以反映新的标题图像选择信息。 对我而言，最有趣的是选择点击诱饵图像和在给定用户偏好和视频性质的情况下具有实际意义的图像之间的区别。 假设选择正确，该图像将成为快速的个性化滤镜。 + +这是一个非常有趣的阅读。 他们在客户端使用什么技术？ 有什么特别的框架吗？ 有什么特别的方法可以使他们显示 x 个视频而不会导致客户端变慢？ + +很棒的帖子。 感谢您抽出宝贵的时间来撰写本文。 大概念以非常易于理解的格式传达。 + +优秀的职位。 用非常容易理解的单词和有趣的内容进行解释。 + +一个真正的问题-如果 Netflix 占峰值互联网流量的 37％，而 YouTube 的流量是 Netflix 的 7 倍，这是否意味着 YouTube 占峰值互联网流量的 259％？ 不知何故，我看不出数字是如何累加的-真正的问题。 与 YouTube，Facebook 和所有其他大型提供商相比，我之前听说过这个数字为 37％，这个数字似乎始终是> 100％-这意味着有问题。 它是什么？ + +很棒的帖子。 谢谢。 + +不错的文章。 Netfiix 内容交付背后的更详细版本。 + +感谢您的博客，我真的很喜欢阅读它。 + +很棒的文章！ 爱它！ 谢谢 + +就 Netflix 背景发生的事情而言，这只是我还是我还是这篇文章很棒？ +感谢您也分享了服务的发展，我总是给人一种印象，即 AWS 通常比单独托管更昂贵，但我从未真正考虑过正常托管的高峰时间... 您没有其他选择。 + +发送到 Netflix 的源文件通常为千兆字节而不是 TB。 很棒的文章！！！ + +用外行的语言和有趣的方式很好地解释了（考虑到与网络相关的信息通常很无聊）。 甚至连祖父母也可能会理解这篇文章。 +感谢您的努力。 + +一篇写得很好的文章，以这种轻松和交错的流程表达了一个复杂的框架。 + +我把它展示给了我的 CS 新手。 她一直想知道更多有关“云”的知识，这有助于她以相关的方式理解许多基本概念。 + +很酷的文章，但我认为 OCA 必须执行某些类似 AAA 的服务，或者 AWS 服务器必须与 OCA 建立会话以供客户端使用。 即使已加密视频，OCA 也无法立即使用该 URL 为任何人提供服务。 + +“ Netflix 从始至终控制着您的视频观看体验” + +其实并不是。 Netflix 不能通过 ISP 网络控制“最后一英里”上交付内容的质量。 +同时，这篇文章很棒！ 非常感谢。 + +好的帖子，尽管花了太长时间才到达最后的项目符号列表，这毕竟是帖子的本意。 同样，解释性的隐喻充其量也很紧张（洗狗器，松鼠坚果贮藏室，埃菲尔铁塔高度的 50 叠纸）。 + +> Netflix 必须确定您是否具有观看特定视频的有效许可证。 我们不会谈论它是如何工作的，这真的很无聊 + +相反，这听起来很有趣！ 他们使用什么数据源？ 什么是许可区域？ 他们如何处理所有格式重叠的许可证以及来自不同供应商和产品的不兼容许可证的所有奇怪的小巧情况？ + +会，我完全同意你的看法。 在这种情况下，DM 很有趣，但这是我的书中的一章，而这本书是针对云新手的。 对于他们来说，需要更多的解释性材料，我认为 DM 将使您分心。 + +对于问以下问题的人：“真正的问题-Netflix 是否占峰值互联网流量的 37％，而 YouTube 则是 Netflix 最高流量的 7 倍-是否意味着 YouTube 占峰值互联网流量的 259％” + +我的猜测是 avergae youtube 视频的质量不如 netflix。 大量 youtube 播放 480，而大量 netflix 播放 4k + +启发性很好的解释文章-谢谢 + +感谢您的有趣阅读。 广泛的体系结构视角和详细说明之间的完美平衡！ \ No newline at end of file diff --git a/docs/212.md b/docs/212.md index 0d7e79a..7b28f0f 100644 --- a/docs/212.md +++ b/docs/212.md @@ -1,138 +1,208 @@ -# Digg 建筑 +# ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务 -> 原文： [http://highscalability.com/blog/2009/4/4/digg-architecture.html](http://highscalability.com/blog/2009/4/4/digg-architecture.html) +> 原文： [http://highscalability.com/blog/2018/4/2/how-ipdata-serves-25m-api-calls-from-10-infinitely-scalable.html](http://highscalability.com/blog/2018/4/2/how-ipdata-serves-25m-api-calls-from-10-infinitely-scalable.html) -**更新 4：**：[由 Joe Stump 介绍 Digg 的 IDDB 基础结构](http://blog.digg.com/?p=607)。 *IDDB 是一种在多个存储服务器之间分区索引（例如整数序列和唯一字符索引）和实际表的方式（目前支持 MySQL 和 MemcacheDB，后面还会有更多内容）。* -**更新 3：**：[扩展 Digg 和其他 Web 应用程序](http://highscalability.com/scaling-digg-and-other-web-applications)。 -**Update 2：**： [Digg 的工作方式](http://blog.digg.com/?p=168)和 [Digg 的实际工作方式](http://blog.digg.com/?p=177)（佩戴耳塞）。 直接从 Digg 的博客带给您。 在跟踪系统中的请求时，对 Digg 架构的主要元素进行了非常简洁的解释。 我已经使用新信息更新了此配置文件。 -**更新：** [Digg 现在每月获得 2.3 亿以上的页面浏览量和 2600 万独立访问者-流量，这需要进行重大内部升级](http://www.readwriteweb.com/archives/digg_townhall_2_wrapup.php)。 +![](img/935b75bf17fe4d9451cc730fde8b933c.png) -Digg 的超过 2200 万名着急信息的用户和 2.3 亿页面访问量所产生的访问量，可能会毫无疑问地将网站直接撞入其 CPU，内存和带宽限制。 Digg 每月如何处理数十亿个请求？ +*这是 IP 地理位置 API [ipdata](https://ipdata.co/) 的创建者 [Jonathan Kosgei](https://twitter.com/jonathan_trev) 的来宾帖子。* -网站：http：//digg.com +我在去年的黑色星期五醒来，收到了来自用户的大量电子邮件，报告来自 [ipdata](https://ipdata.co/) API 的 503 错误。 -## 信息来源 +我们的用户通常会在其网站上的每个页面请求上调用我们的 API，以对用户进行地理位置定位和本地化其内容。 因此，这一特殊故障在一年中最大的销售日直接影响了我们用户的网站。 -* [Digg 的工作原理](http://blog.digg.com/?p=168)作者 Digg* [Digg.com 如何使用 LAMP 堆栈向上扩展](http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9017778)* [Digg PHP 的可伸缩性和性能](http://www.oreillynet.com/onlamp/blog/2006/04/digg_phps_scalability_and_perf.html) +那天我只失去了一个用户，但差点失去了更多。 - ## 平台 +事件的顺序及其无法解释的性质-cpu，mem 和 i / o 远没有达到容量。 考虑到停机，我们担心扩展规模（如果有的话），这是一个重新考虑现有基础架构的重大呼吁。 - * 的 MySQL* 的 Linux* 的 PHP* Lucene* 蟒蛇* [APC PHP 加速器](http://us.php.net/apc)* [MCache](http://www.mohawksoft.org/?q=node/8)* [Gearman](http://www.danga.com/gearman/) -作业调度系统* [MogileFS](http://www.danga.com/mogilefs/) -开源分布式文件系统* 阿帕奇* Memcached +## 当时的技术堆栈 - ## 统计资料 +![](img/b9a6547c2405674e9b11c2e0b6efb9c8.png) - * 从 2004 年末开始，当时只有一台运行 Apache 1.3，PHP 4 和 MySQL 的 Linux 服务器。 4.0 使用默认的 MyISAM 存储引擎* 超过 2200 万用户。* 每月超过 2.3 亿的页面浏览量* 每月 2600 万唯一身份访问者* 每月数十亿的页面浏览量* 所面临的扩展挑战都与 PHP 没有任何关系。 面临的最大问题是与数据库有关的。* 数十个 Web 服务器。* 数十个数据库服务器。* 六个专门的图形数据库服务器运行推荐引擎。* Six to ten machines that serve files from MogileFS. +* Japronto Python 框架 +* 雷迪斯 +* AWS EC2 节点 +* AWS 弹性负载平衡器 +* 基于 Route53 延迟的路由 - ## 里面有什么 +我已经在几个新的，有希望的 Python 微框架上进行了测试。 - * 专用的负载平衡器设备可监视应用程序服务器，处理故障转移，根据运行状况不断调整群集，平衡传入请求以及缓存 JavaScript，CSS 和图像。 如果您没有合适的负载均衡器，请查看 Linux Virtual Server 和 Squid 作为替代产品。* 请求被传递到 Application Server 群集。 应用程序服务器包括：Apache + PHP，Memcached，Gearman 和其他守护程序。 他们负责协调对不同服务（DB，MogileFS 等）的访问，并创建发送到浏览器的响应。* 使用 MySQL 主从设置。 - -四个主数据库按功能划分：升级，配置文件，注释，主要。 每个主服务器都挂有许多从数据库。 - -写入主机，读取发送给从机。 - -大量事务的服务器使用 InnoDB 存储引擎。 - -OLAP 繁重的服务器使用 MyISAM 存储引擎。 - -他们没有注意到从 MySQL 4.1 到版本 5 的性能下降。 - -与“您的平均数据库设计”相比，该架构的规格化程度更高。 - -分片用于将数据库分为几个较小的数据库。* Digg 的使用模式使他们更易于扩展。 大多数人只是查看首页而离开。 因此，Digg 的数据库访问中有 98％是读取的。 凭借这种平衡的操作，他们不必担心为写入而设计的复杂工作，这使他们进行扩展变得容易得多。* 他们的存储系统出现问题，告诉他们写的确实不在磁盘上。 控制器这样做是为了改善其性能外观。 但是，这样做的结果是在故障场景中保留了巨大的数据完整性。 这确实是一个非常普遍的问题，可能很难解决，具体取决于您的硬件设置。* 为了减轻数据库负载，他们使用了 APC PHP 加速器 MCache。* Memcached 用于缓存，memcached 服务器似乎分布在其数据库和应用程序服务器中。 专门的守护程序监视连接并终止打开时间过长的连接。* 您可以结合使用 Apache 2 的工作线程，FastCGI 和 PHP 加速器，将 PHP 配置为不在每次加载时进行解析和编译。 在页面的第一次加载中，将编译 PHP 代码，因此任何后续页面加载都非常快。* MogileFS 是一种分布式文件系统，提供故事图标，用户图标，并存储每个故事来源的副本。 分布式文件系统在许多磁盘上分布和复制文件，从而支持快速和可扩展的文件访问。* 建立了专门的推荐引擎服务以充当其分布式图形数据库。 关系数据库的结构不佳，无法生成建议，因此创建了单独的服务。 LinkedIn 为他们的图表做了类似的事情。 +在使用 [https://github.com/samuelcolvin/aiohttp-vs-sanic-vs-japronto 对基准 3 进行基准测试后，我在[aiohttp]，[sanic]和[japronto]之间进行选择，选择了](https://github.com/samuelcolvin/aiohttp-vs-sanic-vs-japronto) [Japronto](https://medium.freecodecamp.org/million-requests-per-second-with-python-95c137af319) 。 并发现它具有最高的吞吐量。 - ## 得到教训 +该 API 在 ELB 负载平衡器后面 3 个区域中的 3 个 EC2 节点上运行，并具有基于 Route53 延迟的路由，可将请求路由到距离用户最近的区域，以确保低延迟。 - * 机器的数量并不重要，它们是什么以及它们如何组装在一起。* 不要把数据库当作锤子。 建议与关系模型不符，因此他们提供了专门的服务。* 通过选择数据库引擎来调整 MySQL。 在需要事务时使用 InnoDB，在不需要事务时使用 MyISAM。 例如，主服务器上的事务表可以将 MyISAM 用于只读从服务器。* 在增长曲线的某个时刻，他们无法通过添加 RAM 来增长，因此必须通过架构来增长。* 人们经常抱怨 Digg 很慢。 这可能是由于其庞大的 javascript 库而不是其后端体系结构。* 他们扩展的一种方法是注意在系统上部署的应用程序。 他们注意不要释放使用过多 CPU 的应用程序。 显然，Digg 具有一个相当标准的 LAMP 体系结构，但是我认为这很有趣。 工程师通常有很多很酷的功能要发布，但是如果这些功能不能随功能一起增长，那么这些功能可能会破坏该功能。 因此，请向后推，直到系统可以处理新功能为止。 这涉及容量规划，这是 Flickr 在扩展过程中强调的内容。* 您是否想知道，通过限制新功能以匹配其基础架构，Digg 可能会与其他快速发展的社交书签服务相比而失去优势吗？ 也许，如果基础架构更容易扩展，他们可以更快地添加功能以帮助他们更好地竞争吗？ 另一方面，仅添加功能是因为您也没有任何意义。 +## 选择一个新的技术堆栈 -在数据层中，最容易发现扩展性和性能问题，并且这些问题是特定于语言的。 您将使用 Java，PHP，Ruby 或它们插入您喜欢的语言。 +![](img/35012937655fe0f97f769040dd03a479.png) +An Example Weather API using our current stack -## 相关文章 +大约在这个时候，我开始认真研究将 API 网关与 AWS Lambda 结合使用的原因： -* [LinkedIn 架构](http://highscalability.com/linkedin-architecture-0) -* [](http://highscalability.com/linkedin-architecture-0)[实时日志体系结构](http://highscalability.com/livejournal-architecture) -* [Flickr 架构](http://highscalability.com/flickr-architecture) -* [数据库设计的非传统方法：碎片](http://highscalability.com/unorthodox-approach-database-design-coming-shard)的来临 -* [Ebay 架构](http://highscalability.com/ebay-architecture) +1. 优惠的价格：API 网关每百万美元约 3.50 美元，AWS Lambda 每百万美元约 0.20 美元。 +2. 无限规模和高吞吐量-API API 网关的帐户限制为每秒 10、000 个请求或每天约 864M 调用。 通过打开支持请求可以解除的限制。 -是的，为什么 digg 只有 30 GB 的数据？ 如果这份报告是真实的，我会很高兴。 +这也使在众多 AWS 区域中拥有端点在经济上可行，从而为全球所有用户提供低延迟。 -30gb 是数据库数据，是 HUUUUUGE！ +## 设计多区域 API 网关 API -我已经写博客了将近 4 年，而我只使用了大约 15 mb 的数据库数据。 +为了使之可行，已经解决了许多架构难题。 -30 gb 的数据库数据非常庞大。 +1. 每个区域中的每个 lambda 函数都需要能够在同一区域中的数据库中查找使用情况数据，以最大程度地减少延迟 +2. 我需要找出一种方法来确定每个 IP 地址，引荐来源网址和 API 密钥进行的 API 调用次数。 +3. 一种同步所有区域中的使用情况数据的方法。 例如，如果 Route53 向我们的悉尼端点发送了 10000 个请求，然后决定向其首尔端点发送下一个 50000 个请求（具体取决于那个时间点的网络延迟最小）。 每个 lambda 函数都需要知道用户总共发出了 60 000 个请求才能正确处理速率限制。 +4. 授权-API 网关提供使用计划和 API 密钥生成，并允许您将 API 密钥链接到使用计划。 此外，您无需为用户超出配额的请求付费，而无需支付额外费用。 但是，我无法使用此功能，因为对我来说，提供不注册，不使用信用卡的免费套餐非常重要。 -如果他们仅跟踪有关其 120 万用户的一些历史数据，则 30 gb 的数据库并不多。 +通过大量的工作，我能够以创造性的方式解决这些问题。 -我不相信。 Digg 需要的容量远远超过此处显示的 30GB 数据（无论如何）。 +## 在本地访问使用情况数据（针对每个 lambda 函数） -您想知道为什么“只有” 30GB 吗？ 数据库是文本。 字符是一个字节。 算一算。 +显而易见的解决方案是使用 Dynamodb，它在规模和速度上都具有成本效益！ 每月前 200M 个请求免费。 -也许我会一个人，但对我来说，没有什么值得骄傲的。 它看起来像是标准的美国公司，那里的箱子比人的便宜，因此，购买 EXPLAIN 命令更容易购买 100 台服务器，然后只需支付 10 人即可。 +Dynamodb 还提供 1-2 ms 的始终较低的读取延迟。 -您可能来自某个时代，当时您确实必须竭尽全力从硬件中获得所有性能提升。 但是，（某种程度上）事实是，成本/收益分析正朝着仅将更多硬件投入问题的方向发展。 工程师，特别是优秀的工程师，并不便宜。 硬件是。 因此，虽然您可能不会留下深刻的印象，但我发现知道何时花更少的钱来完成同一任务“智能”。 +![](img/9e083b450183ab840e2ab8eb31c98629.png) -现在，这并不意味着应该放弃适当的数据库设计。 实际上，在关系，约束，索引等方面，我有点加法。但是有时候，做具有成本效益的事情才有意义，我希望这就是 digg 所做的。 +可以使用 [Dynamodb Accelarator](https://aws.amazon.com/dynamodb/dax/) （DAX）将其加速到微秒范围。 -哇，直到现在我才意识到我的最后一个问题有多糟。 +> DAX 通过每秒数百万个请求处理大量读取工作负载的响应时间（以微秒为单位），将性能提升到一个新的水平。 -最后一件事，要水平缩放实际上需要花费很多精力。 仅仅因为他们使用了很多盒子，并不意味着他们没有在整个系统架构和数据库设计上花费很多时间和精力。 这是我目前正在设计的系统可以做到的事情，并不是这样，所以我不必担心优化代码，这样我就可以进行容量规划和购买资源，以逐步处理增加的负载并节省成本。 我发现能够做到这一点令人印象深刻。 +## 收集所有标识符的使用情况数据 -他指的 30 GB 可能是每个群集节点上所需的空间。 OS +应用程序等 +下一个挑战是如何实时计算每个 IP 地址，引荐来源网址或 API 密钥发出的请求数。 -我将是第一个不同意的人。 首先，如果没有合适的人设计整个体系结构，那么在一个问题上丢箱子只会增加您的电费。 我已经看到了与客户的第一手资料。 实际上，我已经看到使用集群的“解决方案”实际上降低了性能，因为设计反表明集群的使用（换句话说，它不是可扩展的设计）。 +最简单，最直接的方法是在每次调用时更新动态表中的计数。 -就个人而言，我宁愿选择一些架构师和管理员以及许多功能强大的机器，而不是忙于工作人员并且没有足够的服务器资源。 :) +但是，这会在每次调用我们的 API 时引入数据库写操作，从而可能导致显着的延迟。 -- -Dustin Puryear -作者， [http://www.puryear-it.com/pubs/linux-unix-best-practices“](管理 Linux 和 UNIX 的最佳做法 服务器 -[http://www.puryear-it.com“]( [http://www.puryear-it.com](http://www.puryear-it.com) +我能够找到一个简单而优雅的解决方案： -Digg 使用哪种负载均衡解决方案/产品？ +1. 首先，在每个请求上打印包含所有请求标识符的日志（JSON 对象）。 这是 IP 地址，引荐来源网址和 API 密钥（如果存在）。 真是 print（事件） +2. 将 [Cloudwatch 订阅过滤器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html)添加到每个区域中每个 Lambda 函数的 Cloudwatch 日志流中，并将所有日志推送到 Kinesis 流中。 这将使我能够处理中心位置中每个区域的日志事件。 由于可以回放事件，因此我选择了 Kinesis 而不是 SQS（亚马逊的简单队列服务）。 SQS 会在使用者读取事件后立即删除事件。 我希望能够从节点故障和数据丢失中恢复。 +3. 从 Kinesis 流中读取并使用使用情况数据更新 [Local Dynamodb](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html) 实例 +4. 使用 [Dynamodb 跨区域复制库](https://github.com/awslabs/dynamodb-cross-region-library)实时将对我的本地 dynamodb 实例的所有更改实时流式传输到所有区域中的所有表。 -确定他们可以廉价地添加服务器，但是每月要有 100 台服务器才能获得 2 亿次观看？ 相比之下，每月有 2 箱装满大量鱼的鱼有 1.1B 次浏览，digg sux？ +## 验证请求 -知道 Digg 使用哪种形式的 FastCGI？ 或者其他人用于 PHP / Apache 配置？ +我通过在注册时将密钥复制到每个区域来处理此问题，因此无论用户点击哪个端点，他们点击的 lambda 函数都可以通过在毫秒内检入本地 Dynamodb 表来验证其密钥。 它还可以存储用户的计划配额，并且可以在一次读取中验证密钥，如果密钥存在，则可以获取计划配额以与使用情况进行比较并确定是否接受或拒绝请求。 -为了清理。 30GB 的数据库*为 closal* 。 在 DIGG 上，您只需要在数据库中存储一个简短的标题，简短的上下文，链接 URL，日期，作者以及 Diggs 的数目，也就是这样。 然后再添加一些用户帐户数据...没什么。 30 GB 为 30,000,000,000 字节（大约），每个字符为一个字节（UTF8） +## 情况如何 -我的意思是，对于**来说，对于**，30GB 听起来可能很小，因为您存储视频/音乐/游戏，但是我们在这里谈论的是纯文本。 克服它。 +今天，我们每月提供 2500 万个 API 调用，每天大约提供 100 万个调用。 -一个 30GB 的数据库确实不是那么大。 +它们中的大多数都在 30 毫秒之内，提供了业界最快的基于 SSL 的 IP 地理位置查找。 -您忘记了该网站不仅存储了数字，还存储了谁，谁评论了哪些评论，最有可能存储点击（我怀疑他们用来检测欺诈）。 一个受欢迎的故事可能包含数千个挖掘，然后评论中包含数千个挖掘。 此数据已全部存储。 +#### [Hyperping.io](https://hyperping.io/) -我们还知道 digg 正在分片，因此我怀疑数据库的大小远大于此大小。 +![](img/57c5d04484b1083938ca36b83e89f8c6.png) -我相信 BIG-IP :) +### [我们的状态页面](https://updown.io/ndkd) -我非常怀疑这是真的，他们使用两个框进行的浏览量可能不足 2000 万。 +![](img/ca63433ee2cce3eba7361c87bb8080dc.png) -我曾与银行的 MS SQL Server 合作，主要开发了业务核心和 BI 应用程序，其中 SQL Server MDF 已达到 100GB 以上。 该数据库在 5 个奇数年的时间内跟踪了每个客户针对每个帐户进行的每笔交易。 那就好 那就是 SQL2000。它的速度非常快。 SQL Server 和可靠，可靠的企业体系结构是在.NET 框架>上开发的。 认为他可以使用其他（劣等）工具集可以做得更好的任何反 MS 专家，只是在做梦。 +延迟几乎是开发人员不愿意使用第三方 API 进行 GeoIP 查找的最大原因。 -如前所述-30GB 是一个很大的数据库。 我不会说巨大，因为（对我而言）意味着在其界限的边缘没有任何增长空间的东西。 但是，数据库很大。 -在 www.freecrm.com 上，我们在 1 台快速服务器上的 mySql 5 设置上达到了 30GB 的数据库大小，但是在修剪了旧的电子邮件日志后，我们将其减少到 18GB 左右。 在超过 60,000 个用户的 CRM 应用程序中，这已超过 4 年的大量使用。 到目前为止，mySql 可以顺利进行，并且到目前为止，任何慢速查询都是由于索引不足。 +但是，我们的低延迟和冗余的全球基础架构正逐渐将大型企业吸引到我们的服务中。 --Harel Malka ------------------------ -[http://www.harelmalka.com](http://www.harelmalka.com) -[http://www.freecrm.com](http://www.freecrm.com) -[http://www.kadoink.com](http://www.kadoink.com) +## 费用 -与我管理的数据库相比，30gb 很小。 +![](img/d349c1a38380cd3fa8195a8783b7bf4c.png) -我管理的大多数生产数据库的范围从 600gb 到 2tb 不等，所有数据库都运行 Oracle 10g。 +## 经验教训 -这些网站大多数都有麻烦，因为他们选择 mysql 而不是真实的数据库。 +1. Cloudwatch 的成本可能出乎意料的高-而不是日志存储-我们只能将 Cloudwatch 日志存储 24 小时。 警报，指标和 cloudwatch 请求确实可以加起来。 +2. 在 API 网关上，由于冷启动次数减少，您获得的请求越少，延迟就越低，因此我发现在我们最繁忙的地区（法兰克福）的延迟低至 17 毫秒，而在悉尼等不那么繁忙的区域则只有 40 毫秒。 +3. Dynamodb 的速度快，花费比您想象的要少（或者不，请参阅 [https://segment.com/blog/the-million-dollar-eng-problem/](https://segment.com/blog/the-million-dollar-eng-problem/) ）。 最初，我认为应该按我提供的 RCU 和 WCU 的数量收费。 但是，计费似乎只是标准用法，因此，如果您提供 1000 个 RCU 和 1000 个 WCU，但仅使用 5 个 RCU 和 WCU，则只需要为使用付费。 Dynamodb 定价的这一方面在刚开始时很难确定。 +4. 增加 lambda RAM 可以使执行时间减半，并使的响应时间更加一致（同时使您的成本增加一倍！） +5. Kinesis 已被证明在高吞吐量下非常可靠。 中继我们的所有日志事件以进行近实时处理。 +6. 本地 Dynamodb 仅受系统资源的限制，这使其非常适合运行表扫描或查询（例如，在生成报告时），否则这些扫描或查询在 AWS 的 Dynamodb 上进行将非常昂贵。 请记住，Local Dynamodb 实际上只是 SQLite 周围的 Dynamo 包装:)。 对于我们的用例来说，它既有用又方便，但对您而言可能并非如此。 -像 Bebo 这样的使用 Oracle 的网站都可以很好地扩展。 Bebo.com 的基础架构每天仅使用 6 cpus 即可支持超过 1 亿个网站页面浏览量和每天约 120 万张图片上传。 +## 笔记 -链接在这里： +* AWS 去年在 Re：invent 上宣布了 Dynamodb Global 表，该表将所有表（“跨区域”）中的所有写入彼此同步。 我们目前不打算使用此功能，因为它仅在 5 个地区提供。 +* 亚马逊还推出了`REQUEST`类型的自定义授权者。 这可能使您可以通过 IP 地址以及任何标头，查询或路径参数对速率进行限制。 -[http://searchoracle.techtarget.com/originalContent/0,289142,sid41_gci1241597,00.html](http://searchoracle.techtarget.com/originalContent/0,289142,sid41_gci1241597,00.html) +[关于 HackerNews](https://news.ycombinator.com/item?id=16745376) -Lucene 数据的大小是多少？ +您的 DynamoDB 成本令人惊讶是因为默认情况下启用了“自动缩放”以读取/写入卷。 只要您的峰值不大，就永远不会看到配置错误... -每个人都可能想注意到任何人说 30gb 是大型甚至中型的。 当涉及到与高可伸缩性相关的任何事情时，您可能不希望听取他们的意见。 对于他们来说，显然并不需要扩展。 +我对此声明感到困惑： -我想进一步了解他们如何/为什么使用 MCache。 APC 应该适合本地服务器缓存，memcached 适合分布式缓存。 MCache 有什么帮助？ 我曾经使用过 msession，在每个页面上都有一些奇怪的启动开销。 我改用 MySQL 进行会话，而不是使用 msession，这很棒。 我不确定为什么他们将 MCache 添加到组合中，并且想知道如何以及为什么... +----- +我最初以为我要提供的 RCU 和 WCU 数量付费。 但是，计费似乎只是标准用法，因此，如果您提供 1000 个 RCU 和 1000 个 WCU，但仅使用 5 个 RCU 和 WCU，则只需要为使用付费。 Dynamodb 定价的这一方面在刚开始时很难确定。 +----- -我猜每个服务器都有 30G +定价页面（https://aws.amazon.com/dynamodb/pricing/）指出，您需要为您提供的吞吐量付费 -我认为将 30GB 的内存称为小型磁盘的意义在于，您可以购买具有 128GB 以上的 RAM 的计算机，并将整个数据库放入缓存中。 +也许因为仍在免费套餐中而未向您收费？ -考虑到戴尔提供的具有 32GB RAM 的四核 opteron 的价格为 6600 美元，看来浪费在 memcached 以及所有这些 Web 服务器上的资源，据我的数学计算，每秒 77 个请求有点过分。 \ No newline at end of file +嘿 Cads， + +我完全理解混乱，我也和您一样。 + +但是我很确定我们不在免费领域，因为我们要为 Dynamodb 付费。 + +而且，我们只收取使用费用，并不超出表中的规定。 + +这似乎与亚马逊的定价页面上所说的相反，但这是我在 AWS 账单上看到的。 + +感谢您的有趣文章。 关于本地 DynamoDB，我有一个问题：您在哪里运行此程序？ 作为 EC2 实例？ + +嗨 Tobi， + +谢谢！ 我实际上在 Azure 节点上运行它。 但是，它可以作为实例在 DO 或 EC2 上运行。 + +该图显然是不真诚的。 从来没有太大的区别。 在这种情况下，可能是因为作者只是在测试管道而不是没有管道。 此外，他将 go pro 限制为 1 cpu。 同样，仓库也不再存在。 我把废话统称为“基准”。 + +顺便说一句，Japronto 主要是 C，请检查代码。 + +（我偏向于 Go，但是这不像 node，其他人无法应付自己） + +我记得在中篇文章上有很多类似的评论，请参阅 https://medium.freecodecamp.org/million-requests-per-second-with-python-95c137af319 + +我还能够找到另一个基准，使 japronto 紧随 Rust +https://github.com/tbrand/which_is_the_fastest + +每月 2500 万个请求是每秒 10 个请求... + +每秒高峰请求呢？ + +写得很好的文章。 感谢您分享您的体验。 我对以下部分有疑问： + +“首先，在每个请求上打印一个带有所有请求标识符的日志（JSON 对象）。这是 IP 地址，引荐来源网址和 API 密钥（如果存在的话）。确实是;```print（event）```“ + +只是想知道为什么不将这些消息直接发送给运动机能？ 为什么要先登录？ + +Esko，API 网关可以处理 10k req / s 的峰值 + +Kaivalya，这会为用户带来延迟，打印日志是最便宜的（就延迟而言）和最简单的解决方案。 + +> > SQS 会在使用者读取事件后立即将其删除。 +这是不正确的，一旦您从 SQS 读取了一条消息，直到可见性超时，任何人都看不到它。 您需要确认对 SQS 的读取，以便它可以删除消息。 我们通常要做的是处理消息，然后仅在处理实例发生故障的情况下进行确认，这样我们的消息仍然完好无损。 只需调整可见性超时以确保提供足够的时间即可。 + +很棒的文章。 感谢您与社区分享。 + +嗨，您如何处理每秒 1,000 个 Lambda 呼叫限制？ AWS 的架构师建议我们不要在具有高使用率和高并发性的大多数项目中使用 Lambda-他们说，这仅对中小型项目更好，并且没有您所说的无限规模-我们被告知的一个大问题 当以最大速度运行时，AWS 团队将耗尽 VPC 中所有可用的 IP 地址。 超出 1,000 个限制的呼叫也会被拒绝，您的客户也会出错。 + +为了计算并发执行的次数，我们使用公式： + +每秒事件（或请求）数*功能持续时间 + +如 https://docs.aws.amazon.com/lambda/latest/dg/scaling.html 所记录。 +自这篇文章上线以来，我们平均每天平均有 2M API 调用，大约每秒 12 次。我们的最大 lambda 使用上面公式中的值，调用时间为 20ms； + +12 * 0.020 + +我们得到的并发级别为 0.24。 + +这意味着我们可以在目前的 1000 lambda 调用限制下，每秒处理 50，000 个请求，每天约 43.2 亿个请求。 + +嗨， +单个订户的运动流事件有多个订户吗？ +只是想知道为什么如果所有数据都存储在一个中央（本地）dynamo 数据库实例中，则跨区域 dynamo 数据库进行复制。 + +因此，您为 9 req / s 支付 150 美元？ + +对于许可证密钥检查，您是否考虑过使用 Bloom 或 Cuckoo 过滤器？ 您可以将过滤器保存在内存中，并避免数据库调用。 + +首次使用 ipdata.co 的用户，我们最近切换到了另一个 IP 地理位置提供商。 延迟在过去几个月中增加了很多，并且在全球范围内不一致（请参阅 https://status.ipdata.co/）。 此外，该服务缺少监视仪表板。 + +如果您处于类似情况，我建议尝试 Ipregistry（https://ipregistry.co），其全局端点延迟实在令人难以置信（https://status.ipregistry.co/）！ 我联系了他们的支持，建议在此博客上写一篇文章，因为他们的体系结构可能很有趣。 \ No newline at end of file diff --git a/docs/213.md b/docs/213.md index 5008828..6892500 100644 --- a/docs/213.md +++ b/docs/213.md @@ -1,146 +1,188 @@ -# 扩展 Digg 和其他 Web 应用程序 +# 每天为 1000 亿个事件赋予意义-Teads 的 Analytics（分析）管道 -> 原文： [http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html](http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html) +> 原文： [http://highscalability.com/blog/2018/4/9/give-meaning-to-100-billion-events-a-day-the-analytics-pipel.html](http://highscalability.com/blog/2018/4/9/give-meaning-to-100-billion-events-a-day-the-analytics-pipel.html) -Digg 的首席架构师 Joe Stump 在 Web 2.0 Expo 上向[进行了此演示](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)。 我找不到实际的演示文稿，但是[克里斯·乔丹](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)记下了一些很棒的笔记。 这样一来，历史上的关键时刻便会永远被意外捕获。 乔也很友好，可以通过电话回答我的电子邮件问题。 +*这是 Teads.tv 的软件工程师* *[Alban Perillat-Merceroz](https://www.linkedin.com/in/albanperillatmerceroz/?locale=en_US)* *的来宾帖子。* -在本篇文章的第一部分中，乔分享了一些您可能没有读过的永恒的智慧。 我当然会花些力气从原始演示文稿中提取所有智慧，而倾向于简单的规则。 然而，真正令我震惊的是 Joe 认为 MemcacheDB *将成为扩展*领域中最大的新手。 MemcacheDB 已经存在了一段时间，但我从未想到过这种方式。 好吧，在帖子结尾处，为什么乔对 MemcacheDB 感到如此兴奋。 +![](img/644055e22dfa3ea31613c9374bdc09b0.png) -## 令人印象深刻的统计 +在本文中，我们描述了如何将 Kafka，Dataflow 和 BigQuery 一起编排以摄取和转换大量事件。 当添加规模和等待时间约束时，对它们进行协调和重新排序成为一个挑战，这是我们如何解决的。 -* 世界第 80 至 100 大网站* 每月 2600 万唯一* 3000 万用户。* 唯一身份流量只有该流量的一半。 流量=唯一的网络访问者+ API + Digg 按钮。* 每月 20 亿个请求* 13,000 请求/秒，高峰时为 27,000 请求/秒。* 3 位系统管理员，2 位 DBA，1 位网络管理员，15 位编码员，质量检查小组* Lots of servers. +![](img/c0187dde2e79208a838aefd0599f99fc.png)Teads for Publisher, one of the webapps powered by Analytics - ## 扩展策略 +在数字广告中，日常运营会产生许多我们需要跟踪的事件，以便透明地报告广告系列的效果。 这些事件来自： - * 缩放是专业化。 当现成的解决方案不再能在一定规模上运行时，您必须创建满足特定需求的系统。* Web 2.0 的教训：人们喜欢胡扯并与世界分享。* Web 2.0 具有可伸缩性。 Web 1.0 平坦，包含大量静态文件。 通过添加更多硬件来处理额外的负载。 Web 2.0 是高度交互的。 内容可以以极低的速率创建。* 语言无法扩展。 100％的时间瓶颈在 - IO 中。 当您同时处理大量请求时，瓶颈就不是语言。 使 PHP 速度提高 300％无关紧要。 当 - 固定数据库时，不要通过使用单引号而不是双引号来优化 PHP。* 不分享状态。 去中心化。 需要分区才能并行处理大量请求。* 向外扩展而不是向上扩展。 期待失败。 只需添加框即可缩放并避免失败。* 需要对数据库驱动的站点进行分区，以在水平和垂直方向上进行扩展。 水平分区意味着将行的子集存储在不同的机器上。 当一台机器上无法容纳的数据量更多时，将使用此功能。 垂直分区意味着将一些列放在一个表中，而将某些列放在另一个表中。 这使您无需停机即可将数据添加到系统。* 数据分为单独的群集：用户操作，用户，注释，项目等。* 构建数据访问层，以便将分区隐藏在 API 的后面。* 带有分区的 [CAP 定理](http://camelcase.blogspot.com/2007/08/cap-theorem.html)：您只能选择以下三个中的两个：强一致性，高可用性，分区容限。* 分区解决方案需要非规范化，这已成为 Digg 的大问题。 非规范化意味着数据被复制到多个对象中，并且必须保持同步。* MySQL 复制用于扩展读取。* 使用异步排队体系结构进行近期处理。 - -这种方法将处理块推向另一个服务，让我们将该服务调度在处理器网格上进行处理。 - -与 cron 相比，它更快，响应速度更快，但与实时响应相比，响应速度却稍慢。 - -例如，发出 5 个同步数据库请求会使您减速。 并行执行。 - -Digg 使用 Gearman。 一个示例用法是获取永久链接。 并行完成三个操作：获取当前记录，获取固定链接并获取注释。 然后将这三个全部合并，以将合并的单个答案返回给客户端。 它也用于网站爬网和日志记录。 这是另一种思维方式。 - -请参阅 [Flickr-先做必要的工作，然后将其余部分排队](http://highscalability.com/strategy-flickr-do-essential-work-front-and-queue-rest)和 [Canonical Cloud Architecture](http://highscalability.com/canonical-cloud-architecture) 了解更多信息。* 瓶颈在 IO 中，因此您已经调整了数据库。 当数据库大于 RAM 时，磁盘会一直处于命中状态，这会降低性能。 随着数据库的变大，无法再扫描该表。 因此，您必须： - -反规范化 - -避免加入 - -避免通过对 - 进行分区来跨数据库进行大型扫描-缓存 - -添加读取从属设备 - -不要使用 NFS* 在尝试解决问题之前，请先编号，以确保事情确实可以进行。* 图标和照片之类的文件是使用分布式文件系统 [MogileFS](http://www.danga.com/mogilefs/) 处理的。 DFS 支持高请求率，因为文件是在网络中分布和复制的。* 缓存永久并且明确过期。* 在基于文件的缓存中缓存相当静态的内容。* 将可变项目缓存在 memcached 中* 在 [APC](http://us2.php.net/apc) 中缓存很少更改的项目。 APC 是本地缓存。 它不是分布式的，因此没有其他程序可以访问这些值。* 对于缓存，请使用[责任链模式](http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern)。 在 MySQL，memcached APC 和 PHP 全局变量中进行缓存。 首先将 PHP 全局变量检查为最快的缓存。 如果不存在，请检查 APC，memcached 并上链。* Digg 的推荐引擎是一个最终保持一致的自定义图形数据库。 最终一致意味着写入一个分区最终将写入所有其他分区。 一次写读后，不必再返回相同的值，因为它们可以由不同的分区处理。 这比严格的一致性要宽松得多，这意味着更改必须在所有分区上同时可见。 接连进行的读取将始终返回相同的值。* 假设每天有 100 万人使用任何新功能，因此从一开始就使其具有可扩展性。 示例：Digg 上的“关于”页面对主数据库进行了实时查询，以显示所有员工。 只是做了一个快速的黑客出去。 然后，一只蜘蛛发疯了，并把该地点倒了。 +* 用户与与浏览器发送的广告的互动。 这些事件称为跟踪事件，可以是标准事件（开始，完成，暂停，继续等），也可以是自定义事件，这些事件来自使用 [Teads Studio](https://teads.tv/studio/) 构建的交互式广告素材。 我们每天大约收到 100 亿个跟踪事件。 +* 来自后端的事件大部分与广告拍卖的详细信息有关（实时出价过程）。 在采样之前，我们每天会产生超过 600 亿个此类事件，并且应当在 2018 年使这一数字增加一倍。 - ## 杂种 +在文章中，我们将重点放在跟踪事件上，因为它们是我们业务中最关键的路径。 - * Digg 按钮是产生点击量的主要关键。* 使用 Debian Linux，Apache，PHP，MySQL。* 选择您喜欢开发的语言，选择编码标准，添加可提取的内联文档，使用代码存储库和错误跟踪器。 喜欢 PHP，Track 和 SVN。* 你和你的人民一样好。 必须相信你旁边的人他在做他的工作。 为了建立信任，人们可以做出 - 决策。 相信人们会处理它，他们会照顾好它的。 减少会议时间，因为您知道人们会做正确的事。* 完全是 Mac 商店。* 几乎所有的开发人员都是本地的。 有些人不愿提供 24 小时支持。* 乔的做法务实。 他没有语言迷恋。 人们从 PHP 到 Python / Ruby，再到 Erlang。 使用 vim。 从命令行开发。 不知道人们如何一直在不断更改工具集。 这不是很有效。* 服务（SOA）分离是一个巨大的胜利。 Digg 使用 REST。 内部服务返回映射到 JSON，XML 等的原始结构。URL 中的版本是因为它不花钱，例如： - /1.0/service/id/xml。 版本内部和外部服务。* 人们不了解网站中有多少活动部件。 某些事情将会发生，并且将会失败。 +![](img/20a9026ebf5723f0f7b7e98193a0f300.png)Simplified overview of our technical context with the two main event sources - ## MemcacheDB：代码的进化步骤，性能的革命步骤 +跟踪事件由浏览器通过 HTTP 发送到专用组件，该组件除其他外将它们排入 [Kafka](https://kafka.apache.org/) 主题。 Analytics 是这些事件的使用者之一（更多内容请参见下文）。 - 想象一下 Digg 的创始人 Kevin Rose，他在本次演讲时拥有 40,000 个关注者。 如果 Kevin 每天只进行一次挖掘，则可写 40,000。 由于最活跃的挖掘者是最紧随其后的，因此它成为巨大的性能瓶颈。 出现两个问题。 +我们有一个分析团队，其任务是处理这些事件，其定义如下： - 您无法一次更新 40,000 个关注者帐户。 幸运的是，我们前面讨论的排队系统已解决了这一问题。 +> 我们摄取了越来越多的原木 - 第二个问题是发生大量写入。 Digg 有写问题。 如果普通用户有 100 个关注者，则一天的收入为 3 亿迪格斯。 那就是每秒 3,000 次写入，每天 7GB 的存储以及 5TB 的数据分布在 50 到 60 台服务器上。 +> 我们将它们转换为面向业务的数据， - 如此繁重的写入负载使 MySQL 无法用于 Digg。 这就是 MemcacheDB 的用武之地。在笔记本电脑上的初始测试中，MemcacheDB 每秒能够处理 15,000 次写入。 MemcacheDB 自己的[基准测试](http://memcachedb.org/benchmark.html)显示其每秒 23,000 次写入和 64,000 次读取/每秒的能力。 以这些写入速度，不难理解为什么乔对 MemcacheDB 的 digg 泛滥能力感到如此兴奋。 +> 我们为每个观众提供高效且量身定制的服务。 - 什么是 [MemcacheDB](http://memcachedb.org/) ？ 这是专为持久性而设计的*分布式键值存储系统。 它不是缓存解决方案，而是持久存储引擎，用于基于键值的快速，可靠的对象存储和检索。 它符合内存缓存协议（未完成，请参见下文），因此任何内存缓存客户端都可以与其建立连接。 MemcacheDB 使用 Berkeley DB 作为存储后端，因此支持许多功能，包括事务和复制*。 +为了完成此任务，我们构建并维护了一组处理工具和管道。 由于公司的有机增长和对新产品的要求，我们经常挑战我们的体系结构。 - 在您太兴奋之前，请记住这是一个键值存储。 您可以通过一个键来读取和写入记录。 没有多个索引，也没有 SQL。 这就是为什么它可以这么快的原因。 +## 为什么我们搬到 BigQuery - Digg 使用 MemcacheDB 扩展了数据非规格化时发生的大量写入。 请记住，这是一个键值存储。 该值通常是一个完整的应用程序级对象，该对象可以从大量标准化表合并在一起。 归一化引入了冗余，因为您将数据副本保留在多个记录中，而不是在一个很好的标准化表中保留一个副本。 因此，非规范化意味着更多的写入操作，因为必须将数据复制到包含副本的所有记录中。 为了跟上他们的发展，他们需要一个能够处理其写负载的数据库。 MemcacheDB 具有这种性能，尤其是当您将 memcached 的常规分区方案放在最顶层时。 +早在 2016 年，我们的 Analytics（分析）堆栈基于 [lambda 架构](http://lambda-architecture.net/)（Storm，Spark，Cassandra），但我们遇到了几个问题： - 我问 Joe 为什么不选择一种内存数据网格解决方案？ 一些原因是：* 此数据是从许多不同的数据库生成的，并且需要很长时间才能生成。 因此，他们希望将其存储在持久性存储中。* MemcacheDB 使用内存缓存协议。 Digg 已经使用 memcache，因此开始使用 MemcacheDB 无疑是很容易的。 它易于使用且易于设置。* 由于它不是新的设置，因此操作人员很乐意将其部署到数据中心。* 他们已经具有内存缓存的高可用性和故障转移代码，因此已经可以使用。* 使用新系统将需要更多的准备时间。* 如果代码有任何问题，您可以看一下。 全部都是开源的。* 不确定其他产品是否足够稳定。 +* 数据规模使得不可能将所有数据都存储在单个 Cassandra 表中，这阻止了有效的交叉查询， +* 这是一个复杂的基础架构，具有用于批处理层和速度层的代码重复，从而阻止了我们有效地发布新功能， +* 最后，难以扩展且成本效益不高， - 因此，这是代码的进化步骤，也是性能的革命步骤。 Digg 正在考虑全面使用 MemcacheDB。 +当时我们有几种可能的选择。 首先，我们可以构建一个增强的 lambda，但这只会推迟我们面临的问题。 - ## 相关文章 +我们考虑了几种有前途的替代方案，例如 [Druid](http://druid.io/druid.html) 和 [BigQuery](https://cloud.google.com/bigquery/) 。 我们最终因其强大的功能而选择迁移到 BigQuery 。 - * [扩展 Digg 和其他 Web 应用程序](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)，作者：Kris Jordan。* [MemcacheDB](http://memcachedb.org/)* [Joe Stump 的博客](http://www.joestump.net/)* [具有与 Memcached 有关的高扩展性标签](http://highscalability.com/tags/memcached)* [高速缓存相关标签](http://highscalability.com/tags/caching)* [BigTable](http://highscalability.com/tags/bigtable)* [SimpleDB](http://highscalability.com/tags/simpledb)* [Anti-RDBMS：分布式键值存储列表](http://highscalability.com/anti-rdbms-list-distributed-key-value-stores)* [数据库设计的非传统方法：碎片](http://highscalability.com/unorthodox-approach-database-design-coming-shard)的来临* [Flickr 架构](http://highscalability.com/flickr-architecture)* [第 4 集：DIGG 首席架构师 Joe Stump 扩展大型网站](http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/) +使用 BigQuery，我们能够： -除非他们想在 RAM 上花很多钱，否则他们会感到意外。 当 RAM 与数据库大小之比降低到 0.8 左右时，Memcachedb / Berkeley 数据库（或基于 B-Tree 的 MySQL，PostgreSQL 或其他传统数据库存储）的性能将大打折扣。 +* 处理原始事件， +* 使用 SQL 作为一种有效的数据处理语言， +* 使用 BigQuery 作为处理引擎， +* 使对日期的解释性访问更容易（与 Spark SQL 或 Hive 相比）， -当前，写解决方案是 Hypertable，即使 RAM 与 DB 的大小比小于 0.1，它也可以每个客户端维持 10k 次写/秒。 +多亏了 [固定费用计划](https://cloud.google.com/bigquery/pricing#flat_rate_pricing) ，我们密集的使用（在查询和存储方面）具有成本效益。 -“搜索”背后的架构是什么。 我假设正在使用某种全文数据库。 有人可以指出在 IIS / ASP.Net 环境中扩展全文本搜索的最佳方法。 我知道 SQL Server 2005 不够好。 +但是，我们的技术背景对于 BigQuery 而言并不理想。 我们想使用它来存储和转换来自多个 Kafka 主题的所有事件。 我们无法将 Kafka 群集移出 AWS 或使用 [Pub / Sub](https://cloud.google.com/pubsub/docs/overview) （在 GCP 上与 Kafka 托管的等效版本），因为这些群集也由我们托管在 AWS 上的某些广告投放组件使用。 结果，我们不得不应对运行多云基础架构的挑战。 -我正在寻找使用基于非 SQL 的后端的东西，例如 berkley db。 +今天， BigQuery 是我们的数据仓库系统，在这里我们的跟踪事件与其他数据源保持一致。 -任何指针将不胜感激？ +## 摄取 -Web 2.0 Expo 笔记的重新组合。 乔的演讲很棒！ 首先请注意，指向我的笔记的链接似乎在 href 中包含一个 -，该链接中断了该链接。 最好！ 克里斯 +在处理跟踪事件时，您面临的第一个问题是您必须无序处理，并且延迟未知。 -哇，对我来说好像他们是在爆发大家伙！ +事件实际发生的时间（事件时间）与系统观察到事件的时间（处理时间）之间的差为毫秒至几小时。 这些大的延迟并不是那么罕见，当用户在两次浏览会话之间失去连接或激活飞行模式时可能会发生。 -RT -www.anon-tools.us.tc +![](img/63b800ae8b1a8a694796b91f7b588eb0.png)Difference between event time and processing time -您应该看一下 SOLR（基于 Lucene 的搜索服务器）。 在 Tomcat 和 Jetty 上运行良好...都在 Windows 上运行。 [http://lucene.apache.org/solr/](http://lucene.apache.org/solr/) +有关流数据处理挑战的更多信息，建议您看一下 Google Cloud Next '17 演讲« [在批处理和流处理之间来回移动](https://www.youtube.com/watch?v=PGTSZvBK8-Y) »，来自 Tyler Akidau （Google 的数据处理技术负责人）和 LoïcJaures（Teads 的联合创始人兼 SVP Technology）。 本文受此演讲启发。 -搜索/数据的 XML 存储是 ASP.net 应用程序的最佳选择，将 LINQ 与.net 3.5 配合使用，XML 比 SQL 快得多。 而且您不必担心整天都会向 ms-sql-s 端口发送垃圾邮件。 +## 流媒体的艰难现实 -[http://www.keyoti.com/products/search/dotNetWeb/index.html](http://www.keyoti.com/products/search/dotNetWeb/index.html) +[数据流](https://cloud.google.com/dataflow/?hl=en)是一种托管流系统，旨在解决事件的混乱性质，以解决我们面临的挑战。 Dataflow 具有统一的流和批处理编程模型，流是旗舰功能。 -这些家伙有一个非常不错的搜索引擎，但是它只能通过爬网来搜索，但是您始终可以调整其源代码，对于应该支持的简单网站，也可以通过 Web 控件运行 +我们按照 Dataflow 的承诺被出售，并坦率地尝试了流模式。 不幸的是，在将其投入实际生产流量后，我们意外地感到惊讶： BigQuery 的流媒体插入成本。 -乔录制了一个非常不错的播客，前段时间他在谈论这个话题。 你可以在找到它 +我们是根据压缩数据大小（即通过网络的实际字节数）而不是 BigQuery 的原始数据格式大小来估算的。 幸运的是，现在已记录在中，用于[每种数据类型](https://cloud.google.com/bigquery/pricing#data)。因此您可以进行数学计算。 -[http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/“]( [http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/](http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/) +那时，我们低估了这笔额外费用 100 倍，这几乎使我们整个提取流程（Dataflow + BigQuery）的费用增加了一倍。 我们还面临其他限制，例如 [100,000 个事件/秒速率限制](https://cloud.google.com/bigquery/quotas#streaminginserts)，这很危险地接近我们所做的事情。 -凉。 谢谢。 有趣的是，这并没有出现在我的搜索中。 +好消息是，有一种方法可以完全避免流插入限制：批量加载到 BigQuery 中。 -“ Digg 使用 MemcacheDB 来扩展数据非规范化时发生的大量写入。” +理想情况下，我们希望将数据流以流方式与 BigQuery 以批处理方式一起使用。 那时，Dataflow SDK 中没有没有 BigQuery 批处理接收器用于无限制的数据流。 -这是个绝妙的主意：**请勿非正规化！** +然后，我们考虑开发自己的自定义接收器。 不幸的是，当时无法向无界数据流添加自定义接收器（请参阅 [Dataflow 计划添加对在未来版本](https://cloud.google.com/dataflow/model/custom-io)中写入无界数据的自定义接收器的支持-BeamBeam 现在有可能 是官方的 Dataflow SDK）。 -[http://kottke.org/04/10/normalized-data](http://kottke.org/04/10/normalized-data) +我们别无选择，只能将我们的数据流作业切换到批处理模式。 多亏了 Dataflow 的统一模型，仅需几行代码即可。 对我们来说幸运的是，我们能够承受因切换到批处理模式而引入的额外数据处理延迟。 -很棒的文章，我非常喜欢 memcache，并已在我的 [http://www.kiran.org.in']( 派上用场的地方。 + +> Helm 网站上的*：Helm 帮助您管理 Kubernetes 应用程序-Helm Charts 帮助您定义，安装和升级最复杂的 Kubernetes 应用程序。* + +Helm 将自己定位为 Kubernetes 的程序包管理器，但我最初只是将其用于模板功能。 现在，我也开始欣赏它的软件包管理器方面，并用它来安装 Grafana [ [2](#_footnotedef_2 "View footnote.") ] 和 Prometheus [ [3](#_footnotedef_3 "View footnote.") ] 。 + +经过一番汗水和几滴眼泪，我们的基础架构现在被整齐地组织为 1 个 Helm 程序包，17 个部署，9 个 ConfigMap，5 个 PersistentVolumeClaims，5 个秘密，18 个服务，1 个 StatefulSet，2 个 StorageClasses，22 个容器映像。 + +剩下的就是迁移到这个新的基础架构并关闭所有硬件服务器。 + +### 正式迁移 + +2017 年 10 月 5 日是夜晚。 + +扣动扳机非常容易，而且顺利进行。 + +我创建了一个新的 GKE 集群，运行`helm install betabrand --name production`，将我们的 MySQL 数据库导入到 Google Cloud SQL 中，然后，实际上花了大约 2 个小时，我们才生活在 Clouds 中。 + +迁移很简单，就是。 + +当然，最有用的是在 Google GKE 中创建多个集群的能力：在迁移产品之前，我能够通过多次测试迁移进行排练，记下成功启动所需的每个步骤。 + +Betabrand 的黑色星期五 2017 年非常成功，我们遇到的一些技术问题与迁移无关。 + +### 开发/分期环境 + +我们的开发机器通过 Minikube [ [4](#_footnotedef_4 "View footnote.") ] 运行 Kubernetes 集群。 + +相同的 YAML 清单用于创建本地开发环境或“类似生产”的环境。 + +在生产环境中运行的所有内容，也在开发环境中运行。 两种环境之间的唯一区别是，我们的开发环境与本地 MySQL 数据库对话，而生产与 Google Cloud SQL 对话。 + +创建登台环境与创建新的生产集群完全相同：所需要做的只是克隆生产数据库实例（只需单击几下或一个命令行），然后通过`--set database`将登台集群指向该数据库。 `helm`中的]参数。 + +### 一年后 + +从我们将基础架构移至 Kubernetes 至今已经一年零两个月了，我再也高兴不起来了。 + +Kubernetes 在生产中一直坚如磐石，我们还没有遇到过停机的情况。 + +预计 2018 年黑色星期五会有大量流量，我们能够在几分钟内创建生产服务的精确副本并进行大量负载测试。 这些负载测试显示特定的代码路径性能非常差，只能显示大量流量，并允许我们在黑色星期五之前修复它们。 + +不出所料，2018 年黑色星期五给 Betabrand.com 带来了比以往更多的访问量，但 k8s 兑现了承诺，而 Horizo​​ntalPodAutoscaler 等功能与 GKE 的节点自动缩放功能相结合，使我们的网站能够毫无问题地吸收峰值负载。 + +K8 与 GKE 相结合，为我们提供了使我们的基础架构可靠，可用，可伸缩和可维护所需的工具。 + +* * * + +[1](#_footnoteref_1). [https://helm.sh/](https://helm.sh/)[2](#_footnoteref_2). [https://grafana.com/](https://grafana.com/)[3](#_footnoteref_3). [https://prometheus.io/](https://prometheus.io/)[4](#_footnoteref_4). [https://github.com/kubernetes/minikube](https://github.com/kubernetes/minikube) + +雨果，好帖子！ 真的很脆，没有花哨/不必要的术语。 + +我很好奇看到您每月帐单的比较-OVH 裸机与 GCP K8S + +I too am curious to see a comparison of your monthly bill - OVH bare-metall vs GCP K8S...😉 + +您认为这对这家公司来说太过分了吗？ 我一直都很喜欢 Kube，不是因为业务需要，而是因为人们喜欢高科技。 IDK，只是想一想 + +为什么不使用不同的名称空间进行测试和暂存，而不是创建不同的集群？ \ No newline at end of file diff --git a/docs/216.md b/docs/216.md index 8ceb84d..0720c3f 100644 --- a/docs/216.md +++ b/docs/216.md @@ -1,193 +1,819 @@ -# Google 架构 - -> 原文： [http://highscalability.com/blog/2008/11/22/google-architecture.html](http://highscalability.com/blog/2008/11/22/google-architecture.html) - -**更新 2：** [使用 MapReduce](http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html) 对 1 PB 进行排序。 PB 并非拼写错误的花生酱和果冻。 它是 1 PB 或 1000 TB 或 1,000,000 GB。 *在 4,000 台计算机上对 1PB（10 万亿条 100 字节的记录）进行分类花费了六个小时又两分钟，并且在 48,000 个磁盘上将结果复制了三次。 -**更新：** [Greg Linden](http://glinden.blogspot.com/2008/01/mapreducing-20-petabytes-per-day.html) 指向 Google 的新文章 [MapReduce：简化了大型集群上的数据处理](http://labs.google.com/papers/mapreduce-osdi04.pdf)。 一些有趣的统计数据：每天执行 10 万个 MapReduce 作业； 每天处理超过 20 PB 的数据； 已经实施了超过 1 万个 MapReduce 程序； 机器是具有千兆位以太网和 4-8 GB 内存的双处理器。 - -Google 是可扩展性之王。 每个人都知道 Google 的庞大，精巧和快速的搜索功能，但他们不仅在搜索中脱颖而出。 他们构建可扩展应用程序的平台方法使他们能够以惊人的高竞争率推出互联网规模的应用程序。 他们的目标始终是建立性能更高，规模更大的基础架构来支持其产品。 他们是如何做到的？* - -## 信息来源 - -1. [视频：在 Google 构建大型系统](http://video.google.com/videoplay?docid=-5699448884004201579) -2. [Google 实验室：Google 文件系统](http://labs.google.com/papers/gfs.html) -3. [Google 实验室：MapReduce：大型集群上的简化数据处理](http://labs.google.com/papers/mapreduce.html) -4. [Google 实验室：BigTable](http://labs.google.com/papers/bigtable.html) 。 -5. [视频：BigTable：一种分布式结构化存储系统](http://video.google.com/videoplay?docid=7278544055668715642)。 -6. [Google 实验室：适用于松耦合分布式系统](http://labs.google.com/papers/chubby.html)的胖锁服务。 -7. [Google 的运作方式[Baseline Magazine]的 David Carr 撰写的](http://www.baselinemag.com/article2/0,1540,1985514,00.asp)。 -8. [Google 实验室：解释数据：使用 Sawzall](http://labs.google.com/papers/sawzall.html) 进行并行分析。 -9. [Dare Obasonjo 关于可伸缩性会议的说明。](http://www.25hoursaday.com/weblog/2007/06/25/GoogleScalabilityConferenceTripReportMapReduceBigTableAndOtherDistributedSystemAbstractionsForHandlingLargeDatasets.aspx) - -## 平台 - -1. 的 Linux -2. 多种语言：Python，Java，C ++ - -## 里面有什么？ - -### 统计资料 - -1. 2006 年估计有 450,000 台低成本商品服务器 -2. 在 2005 年，Google 索引了 80 亿个网页。 现在，谁知道呢？ -3. 目前，Google 有 200 多个 GFS 集群。 一个集群可以具有 1000 甚至 5000 台计算机。 数万台计算机的池从运行高达 5 PB 的 GFS 群集中检索数据。 整个群集的总读/写吞吐量可以高达 40 GB /秒。 -4. 目前，Google 有 6000 个 MapReduce 应用程序，每个月都会编写数百个新应用程序。 -5. BigTable 可扩展以存储数十亿个 URL，数百 TB 的卫星图像以及成千上万用户的首选项。 - -### 堆栈 - -Google 将其基础架构可视化为三层堆栈： - -1. 产品：搜索，广告，电子邮件，地图，视频，聊天，博客 -2. 分布式系统基础架构：GFS，MapReduce 和 BigTable。 -3. 计算平台：一堆不同数据中心中的机器 -4. 确保公司人员易于以较低的成本进行部署。 -5. 查看每个应用程序的价格性能数据。 花更多的钱在硬件上不会丢失日志数据，而花更少的钱在其他类型的数据上。 话虽如此，他们不会丢失数据。 - -### 可靠的 GFS 存储机制（Google 文件系统） - -1. 可靠的可扩展存储是任何应用程序的核心需求。 GFS 是他们的核心存储平台。 -2. Google 文件系统-大型的分布式日志结构化文件系统，在其中可以放入大量数据。 -3. 为什么要构建它而不使用现成的东西？ 因为它们控制着一切，而正是平台才使它们与其他人区分开。 他们需要： - -跨数据中心的高可靠性 - -可扩展到数千个网络节点 - -巨大的读/写带宽要求 - -支持大小为千兆字节的大数据块。 - -跨节点高效分配操作以减少瓶颈 -4. 系统具有主服务器和块服务器。 - -主服务器将元数据保留在各种数据文件中。 数据以 64MB 的块存储在文件系统中。 客户端与主服务器对话，以对文件执行元数据操作，并在磁盘上找到包含其所需需求的块服务器。 - -块服务器将实际数据存储在磁盘上。 每个块都在三个不同的块服务器之间复制，以在服务器崩溃的情况下创建冗余。 一旦由主服务器指示，客户端应用程序将直接从块服务器检索文件。 -5. 即将上线的新应用程序可以使用现有的 GFS 集群，也可以使用自己的集群。 了解他们在整个数据中心使用的配置过程将很有趣。 -6. 关键在于足够的基础架构，以确保人们可以选择其应用程序。 可以调整 GFS 以适合单个应用程序的需求。 - -### 使用 MapReduce 处理数据 - -1. 既然您拥有一个良好的存储系统，那么如何处理如此多的数据呢？ 假设您在 1000 台计算机上存储了许多 TB 的数据。 数据库无法扩展或无法有效地扩展到这些级别。 那就是 MapReduce 出现的地方。 -2. MapReduce 是用于处理和生成大型数据集的编程模型以及相关的实现。 用户指定一个处理键/值对以生成一组中间键/值对的映射函数，以及一个归约函数，该归约函数合并与同一中间键关联的所有中间值。 在此模型中，许多现实世界的任务都是可以表达的。 以这种功能风格编写的程序会自动并行化，并在大型商用机器集群上执行。 运行时系统负责划分输入数据，在一组机器上调度程序的执行，处理机器故障以及管理所需的机器间通信的细节。 这使没有并行和分布式系统经验的程序员可以轻松利用大型分布式系统的资源。 -3. 为什么要使用 MapReduce？ - -在许多机器之间分区任务的好方法。 - -处理机器故障。 - -适用于不同的应用程序类型，例如搜索和广告。 几乎每个应用程序都有 map reduce 类型的操作。 您可以预先计算有用的数据，查找字数，对数据 TB 进行排序等。 - -计算可以自动移近 IO 源。 -4. MapReduce 系统具有三种不同类型的服务器。 - -主服务器分配用户任务以映射和简化服务器。 它还跟踪任务的状态。 - -地图服务器接受用户输入并对其进行地图操作。 结果将写入中间文件 - -Reduce 服务器接受地图服务器生成的中间文件，并对它们执行 reduce 操作。 -5. 例如，您要计算所有网页中的单词数。 您将把存储在 GFS 上的所有页面送入 MapReduce。 这将同时在数千台计算机上发生，并且所有协调，作业调度，故障处理和数据传输将自动完成。 - -步骤如下：GFS->映射->随机播放->缩减->将结果存储回 GFS。 - -在 MapReduce 中，地图将一个数据视图映射到另一个数据视图，生成一个键值对，在我们的示例中为单词和计数。 - -改组聚合密钥类型。 - -减少量汇总所有键值对并产生最终答案。 -6. Google 索引编制管道具有约 20 种不同的简化地图。 管道使用一堆记录和聚合键来查看数据。 第二个 map-reduce 耗时较长，会得到该结果并执行其他操作。 等等。 -7. 程序可能很小。 最少 20 到 50 行代码。 -8. 一个问题是流浪汉。 散乱的人是比其他人慢的计算。 由于 IO 速度慢（例如控制器故障）或 CPU 暂时出现峰值，可能会导致流浪汉。 解决方案是运行多个相同的计算，并在完成一个计算后杀死所有其余计算。 -9. 在 map 和 reduce 服务器之间传输的数据已压缩。 这个想法是因为服务器不受 CPU 的限制，因此有必要花数据压缩和解压缩以节省带宽和 I / O。 +# Egnyte Architecture：构建和扩展多 PB 内容平台的经验教训 -### 在 BigTable 中存储结构化数据 +> 原文： [http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html) -1. BigTable 是一个大型的，容错的，自我管理的系统，其中包括 TB 级的内存和 PB 级的存储。 它每秒可以处理数百万次读/写。 -2. BigTable 是建立在 GFS 之上的分布式哈希机制。 它不是关系数据库。 它不支持联接或 SQL 类型查询。 -3. 它提供了按键访问结构化数据的查找机制。 GFS 存储不透明的数据，许多应用程序需要具有结构的数据。 -4. 商业数据库根本无法扩展到该级别，并且无法在 1000 台计算机上使用。 -5. 通过控制自己的低级存储系统，Google 可以获得更多的控制权和杠杆作用来改进其系统。 例如，如果他们想要使跨数据中心操作更容易的功能，则可以将其内置。 -6. 可以在系统运行时添加和删除计算机，并且整个系统都可以正常运行。 -7. 每个数据项都存储在一个单元格中，可以使用行键，列键或时间戳对其进行访问。 -8. 每行存储在一个或多个平板电脑中。 数位板是一系列 64KB 的块，其数据格式为 SSTable。 -9. BigTable 具有三种不同类型的服务器： - -主服务器将平板电脑分配给平板电脑服务器。 他们跟踪平板电脑的位置，并根据需要重新分配任务。 - -平板电脑服务器处理对平板电脑的读/写请求。 当超出尺寸限制（通常为 100MB-200MB）时，他们会拆分平板电脑。 当平板电脑服务器出现故障时，每台 100 台平板电脑服务器将拾取 1 台新平板电脑，然后系统将恢复。 - -锁定服务器形成分布式锁定服务。 打开平板电脑进行书写，主控权和访问控制检查之类的操作需要相互排斥。 -10. 位置组可用于将数据的相关位物理存储在一起，以实现更好的参考位置。 -11. 平板电脑尽可能多地缓存在 RAM 中。 +![](img/cd669c781d6a9a0f1fd802de7a2578a4.png) -### 硬件 +这是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的来宾帖子，工程师是为 [Egnyte](https://www.egnyte.com/) 在家工作的。 Egnyte 是专门为企业构建的安全内容平台。 他和他的同事们花费大量的时间来扩展大型分布式文件系统。 您可以通过 [@kpatelwork](https://twitter.com/kpatelwork) 与他联系。 -1. 当您有很多机器时，如何构建它们以使其具有成本效益并高效使用电源？ -2. 在顶部使用超廉价的商品硬件和内置软件来应对其死亡。 -3. 如果您使用容易发生故障的基础架构，而不是基于高度可靠的组件构建的基础架构，则可以将计算机功耗提高 1000 倍，而成本却降低了 33 倍。 为了使此策略有效，您必须在不可靠性的基础上建立可靠性。 -4. Linux，内部机架设计，PC 类主板，低端存储。 -5. 基于性能的每瓦价格并没有改善。 有巨大的电源和散热问题。 -6. 混合使用搭配使用自己的数据中心。 +## 简介 -### 杂项 +您的笔记本电脑有一个文件系统，该文件系统被数百个进程使用。 但是，如果您希望使用它来支持数以万计的用户在处理同时包含 PB 级数据的数亿个文件时有一些缺点。 它受磁盘空间的限制； 它无法弹性扩展存储空间； 如果您运行一些 I / O 密集型进程或尝试与 100 个其他用户进行协作，就会感到窒息。 让我们来解决这个问题，并将其转换为遍布全球的数百万付费用户使用的云原生文件系统，您将了解我们过山车的规模，可以扩展该系统以满足每月的增长和 SLA 要求，同时提供严格的一致性和 我们都期望笔记本电脑具有出色的耐用性。 -1. 快速推出更改，而不必等待质量检查。 -2. 图书馆是构建程序的主要方式。 -3. 有些应用程序是作为服务提供的，例如爬网。 -4. 基础结构可处理应用程序的版本控制，因此可以发布它们而不必担心发生问题。 +Egnyte 是一个安全的内容协作和数据治理平台，成立于 2007 年，当时 Google 硬盘还没有诞生，而 AWS S3 却禁止了成本。 我们唯一的选择是袖手旁观，自己构建基本的云文件系统组件，例如对象存储。 随着时间的推移，S3 和 GCS 的成本变得合理，并且借助 Egnyte 的存储插件架构，我们的客户现在可以引入他们选择的任何存储后端。 为了帮助我们的客户管理持续的数据爆炸，我们在过去几年中设计了许多核心组件。 在本文中，我将分享当前的体系结构以及我们所学到的扩展它的一些经验教训，以及我们希望在不久的将来进行改进的一些内容。 -### Google 的未来发展方向 +## Egnyte Connect 平台 -1. 支持地理分布式集群。 -2. 为所有数据创建一个全局名称空间。 当前，数据按群集进行隔离。 -3. 更好，更好的数据和计算自动化迁移。 -4. 解决将广域复制与网络分区结合使用时发生的一致性问题（例如，即使群集因维护而脱机或由于某种故障而保持服务正常运行）。 +Egnyte Connect 平台使用 3 个数据中心来满足来自全球数百万用户的请求。 为了增加弹性，可靠性和耐用性，这些数据中心使用高速，安全的 Google 互连网络连接到 Google Cloud 平台。 -## 得到教训 +![](img/b34c983ca54495f680a9dadebfa8f2a4.png) -1. **基础设施可以成为竞争优势**。 当然是给 Google 的。 他们可以更快，更便宜地推出新的互联网服务，而且在其他竞争者中还可以大规模地推出。 许多公司采用完全不同的方法。 许多公司将基础设施视为支出。 每个小组将使用完全不同的技术，并且几乎没有计划和如何构建系统的共性。 Google 视自己为一家系统工程公司，这是研究构建软件的一种非常新颖的方式。 -2. **跨多个数据中心仍然是一个尚未解决的问题**。 大多数网站位于一个和最多两个数据中心。 我们应该说，如何在一组数据中心之间完全分配网站是很棘手的。 -3. **如果您没有时间自己重新构建所有这些基础架构，请看一下 Hadoop **。 Hadoop 是此处介绍的许多相同想法的开源实现。**** -4. **平台方法的一个令人赞赏的优势**是初级开发人员可以在平台之上快速而自信地创建健壮的应用程序。 如果每个项目都需要创建相同的分布式基础架构轮子，您会遇到困难，因为知道如何做到这一点的人相对很少。 -5. **协同作用并不总是胡扯**。 通过使系统的所有部分协同工作，一项改进可以帮助他们。 改进文件系统，每个人都可以立即透明地受益。 如果每个项目使用不同的文件系统，那么整个堆栈就不会有持续的改进。 -6. **构建无需运行系统即可运行的自我管理系统**。 这使您可以更轻松地在服务器之间重新平衡资源，动态添加更多容量，使计算机脱机并妥善处理升级。 -7. **创建达尔文式基础结构**。 并行执行耗时的操作并赢得优胜者。 -8. **不要忽略学院**。 学术界有很多好的想法，这些想法无法转化为生产环境。 Google 所做的大部分工作都是现有技术，而不是大规模部署。 -9. **考虑压缩**。 当您有大量的 CPU 可供使用且 IO 有限时，压缩是一个不错的选择。 +Egnyte Connect 运行一个服务网格，该网格从我们自己的数据中心延伸到提供多种服务类别的 Google 云： -好文章。 真的很好。 真的非常好文章。 真的真的真的真的好文章。 +### 合作 -亚马逊拥有“云计算”功能，可以在此规模上为您提供更好的性价比。 +* 文档存储区 -真的很好.. / SG +* 预览版 -我喜欢这篇文章...天哪，你知道你的东西。 最好的部分是，由 Google 制作的这些视频是您的参考框架。 我强烈建议您甚至进一步简化它。 我喜欢这些内容，您真的应该在 Scalability 2.0 下将这些内容添加到 iMarketingGuru 中。我将放置有关这些类型的可伸缩性的文章链接，您可以随时给自己很多链接爱，并继续进行下去。 维基。 我喜欢这个东西= o） +* 视频转码 -感谢您分享这些信息。 +* 分享 -真是胡扯。 -Google 只会进行搜索和搜索，它们不会在 gmail，google talk，SDK，电子表格，Checout 或任何其他服务中发挥作用。 -迟早您会弄清楚-当人们变得更聪明并停止按 Google 广告上的链接时-Google 奶牛将停止现金流... + * 链接 -内容丰富，但缺乏细节。 我确实同意上面的那个家伙，他们只是在搜索中大放异彩，他们需要在其他领域大力推广牛奶:) + * 权限 -很棒的内容。 真的很有用。 干杯! +* 标签 -感谢您分享此信息，它非常有用 +* 评论 -很棒的帖子！ -我想 Google 会以某种方式创建 Google 操作系统。 -它只是存在于云中并且可以使用的服务器和集群的集合。 :-) +* 任务 -作为对您的文章的深入研究的副作用，我将其翻译为德语： [http://habacht.blogspot.com/2007/10/google-architecture.html](http://habacht.blogspot.com/2007/10/google-architecture.html) +* 建议 -Google 负担得起所有这种结构^） +### 混合同步 -我将不得不保存并稍后重新阅读。 这里有很多细节可以帮助解释 G 的一些怪癖。 仅仅考虑其背后的庞大体系结构，只会让我的思想融化。 +* 处理 Prem 数据时 -Google 以前已经丢失了其电子邮件客户的数据。 不要对谷歌如此信服。 谷歌是一家拥有其他类似缺陷的公司。 他们还不像微软那么糟糕，但是给它一点时间，他们就会到达那里。 如果您想保护自己的数据安全，请自己做，并确保 99.9999％的时间都可以正常工作。 +* 大文件或低带宽 -非常有趣且内容丰富的文章！ -我发现它是我正在研究的某些项目的体系结构的重要参考。 +* 离线访问 -真的很好！ +* 边缘缓存 -完美的文章，谢谢。 Google 变得比搜索引擎更重要 +### 基础架构优化 -优秀文章 -哪里描述 Google LAB：GWS-Google Web Server？ +* 迁移到云 -Google 只是搜索者中的第一个！ 例如， [http://loadingvault.com](http://loadingvault.com) 或 [http://loadingvault.com]( quickshare search 和 google.com 之间的区别？这两个网站都在搜索 正确的信息！广告管理是一件非常好的事！ +* 优化保鲜库的成本 -好。 谢谢。 :) +* 合并存储库 -Quite informative but lacks the nity grity details. I do agree to the fellow above that they only shine in search they need to pitch hard in other areas to milk :) +通常，Egnyte 连接架构分片并基于以下条件在不同级别缓存数据： -我曾经阅读过有关 MapReduce 体系结构的最佳文章。 +* 数据量 -知道像 Google 这样的大公司如何运作总是很有趣的。 -谢谢.. +* 数据相互依存 -给“什么废话”的人。 多么透明。 如果我们从主流中脱颖而出，就好像我们对某个主题有一些内在的，高超的知识，我们会显得聪明吗？ 本文并不将 Google 定位为最终的所有软件公司。 他们是搜索引擎，而且做得很好。 这是关于他们如何做好的。 真是的 如果它们“不如微软那么糟糕”-??? Microsoft 在 200 个国家/地区拥有 60,000 名员工。 您雇用多少人？ 我对这些消极，无知的人感到厌烦，这些人试图以牺牲别人的工作成果为代价看起来很聪明…… +* 并发读取的级别 -多数民众赞成在一个页面上收集的很好的信息收集。 \ No newline at end of file +* 并发写入级别 + +![](img/f8913d2219c8cabf370072889c0b44fb.png) + +， + +## Egnyte Connect 技术堆栈 + +### 云平台 + +1. Google 云端 + +2. Azure + +3. 托管数据中心 + +### 语言： + +1. Java + +2. Python + +3. 转到 + +4. C + +### 对象存储区 + +* Egnyte 对象存储区 + +* GCS + +* S3 + +* Azure + +### 应用服务器 + +* Tomcat + +### 数据库 + +* MySQL + +* Redis + +* BigTable + +* 数据存储 + +* Elasticsearch + +### 缓存 + +* Memcached + +* Redis + +* Nginx 用于基于磁盘的缓存 + +### 负载平衡器/反向代理 + +* HAProxy + +* Nginx + +### 消息队列 + +* Google Pub / Sub + +* 兔子 + +* 抄写员 + +* Redis + +### 部署管理 + +* 人偶 + +* Docker + +* Ansible + +* 詹金斯 + +* Gitlab + +* 调速器 + +### 分析 + +* 新遗物 + +* OpenTSDB / bosun + +* Grafana + +* MixPanel + +* 表格 + +* BigQuery + +### 其他 + +* ZooKeeper + +* Nagios + +* Apache FTP 服务器 + +* 孔 + +* ReactJS / Backbone / Marionette / JQuery / npm / Nightwatch + +* Rsync + +* PowerDNS + +* 服装 + +* 基于 REST API 的 SOA 体系结构。 + +* Java 用于驱动核心文件系统代码 + +* 用于支持客户端代码，某些微服务，迁移脚本，内部脚本的 Python + +* 原生 Android 和 iOS 应用 + +* 本机桌面和服务器托管的客户端，允许对整个名称空间进行交互以及混合同步访问 + +## 统计信息 + +* 3 个主要地区（其中一个在欧洲）使用 Google 互连连接到相应的 GCP 地区 + +* 500 多个 Tomcat 服务 实例 + +* 由 Tomcat / Nginx 提供支持的 500 多个存储节点 + +* 100 多个 MySQL 节点 + +* 100 多个 Elasticsearch 节点 + +* 50 多个文本提取 实例 （自动缩放） + +* 100 多个 HAProxy 实例 + +* 许多其他类型的服务 实例 + +* 存储在我们服务器和其他对象存储区（例如 GCS，S3 和 Azure Blobstore）中的数十 PB 数据 + +* 在 Elasticsearch 中建立索引的多个 TB 提取内容 + +* 数百万个桌面客户端与云同步文件以进行脱机访问 + +* 数百万台式客户端以交互方式访问文件 + +## 认识您 + +### 您的系统名称是什么，我们在哪里可以找到更多信息？ + +Egnyte Connect 是内容协作和数据管理平台。 CFS（云文件系统），EOS（Egnyte 对象存储），内容安全性，事件同步，搜索服务，基于用户行为的推荐服务构成了系统的主要部分。 您可以在我们博客的 [对于技术人员](https://www.egnyte.com/blog/category/for-the-techies/) 部分中找到更多相关信息。 + +### 您的系统使用什么功能？ + +作为内容协作和数据管理平台的 Egnyte Connect 被成千上万的客户用作唯一的 安全内容平台来满足他们的所有文档管理需求。 它是为承载各种文件服务 并为它们的现有文件存储库启用云而构建的。 可以从各种端点（例如 FTP，WebDAV，移动，公共 API 和浏览器）访问它，并具有强大的审核和安全组件。 + +### 您为什么决定构建此系统？ + +在 2007 年，企业开始变得更加分散。 客户正在使用多种设备来访问他们的文件，因此需要使这种体验尽可能地顺畅。 我们构建了 Egnyte Connect-一种安全的分布式文件系统，该系统将 Hybrid Sync 与 Cloud File System 相结合，可以满足各种业务需求中企业的内容协作需求。 随着本地和云存储库中数据的分散，以及由于 GDPR 等举措而增加的合规性需求，我们构建了 Egnyte Protect 来帮助客户满足其合规性和治理需求。 + +### 您的项目经费如何？ + +Egnyte 最初是一家自举公司。 后来，我们继续从高盛，Google Ventures，KPCB，Polaris Partners 和 Seagate 的多轮融资中筹集了 1.375 亿美元的 [](https://www.crunchbase.com/organization/egnyte#/entity)。 + +### 您的收入模式是什么？ + +Egnyte 不提供免费帐户。 客户从 15 天的免费评估试用期开始，之后，他们将根据席位数量，存储空间和其他企业功能转换为带有收入模型的付费帐户。 + +### 您如何销售产品？ + +我们从 SEM / SEO 开始，但随着时间的增长，我们使用了许多渠道来为社会客户，社交媒体，商务开发，贸易展览，SEM，SEO，入站营销和企业级客户进行高接触销售。 + +### 您从事这项工作多久了？ + +Egnyte 成立于 2007 年。它已有 12 年的历史，现金流量为正。 + +### 您的系统多大？ 尝试感受一下系统的工作量。 + +我们存储数十亿个文件和数十 PB 的数据。 在“ Egnyte connect”中，根据 New Relic，我们平均观察到平均每秒超过 10K API 请求，平均响应时间为< 60ms。 由于安全港规定和位置相近，我们允许从 3 个主要地区访问。 有关更多信息，请参见统计信息部分。 我们的“ Egnyte Protect”解决方案还持续监控内容和对许多客户的合规性，治理和安全漏洞的访问。 + +### 您提供多少份文件？ 多少张图片？ 多少数据？ + +我们存储数十亿个文件和数十 PB 的数据。 我们存储各种文件。 Egnyte 存储的前 5 个文件扩展名是 pdf，doc / docx，xl​​s / xlsx，jpeg 和 png。 + +### 免费用户与付费用户的比例是多少？ + +我们所有的用户均为付费用户。 我们提供 15 天的免费试用期，然后将其转换为付费帐户。 + +### 在过去一个月中有多少个帐户处于活动状态？ + +我们所有的客户都是付费帐户，并且每个月几乎所有人都活跃。 我们满足他们安全的内容平台需求，谁在家不用电？ + +## 您的系统如何设计？ + +### 您的系统的体系结构是什么？ + +我们使用基于 REST 的面向服务的体系结构，它使我们能够独立扩展每个服务。 这也使我们能够将某些后端服务移至公共云中托管。 所有服务都是无状态的，并使用数据库或我们自己的对象存储进行存储。 + +10000 英尺的 Egnyte Connect 服务概述如下所示。 + +![](img/3d5e6054b4bacef5d0f2733fb962651b.png) + +[典型请求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的 10000 英尺总览如下 + +![](img/19d4979dbb2079dbc0eac2371a21067a.png) + +约 10000 英尺的 [搜索架构](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下 + +![](img/c015db1edce1869cc6373704f2683bb5.png) + +### 您的系统面临哪些特定的设计/架构/实施挑战？ + +最大的 架构 挑战包括： + +1. 节俭地扩展文件存储 + +2. 扩展元数据访问 + +3. 文件与桌面客户端的实时同步 + +4. 带宽优化 + +5. 冲击隔离 + +6. 缓存（分布式和内存中） + +7. 功能首次展示 + +### 您是如何应对这些挑战的？ + +1. 对于存储，我们编写了自己的存储，现在我们使用可插拔的存储体系结构来存储到任何公共云，例如 S3，GCS，Azure ... + +2. 为了扩展元数据，我们移至 Mysql 并开始使用分片。 在某个时候，我们暂时投入了更多的硬件来腾出空间，以便一层一层地剥去“鳞屑洋葱”。 + +3. 对于实时同步，我们必须更改同步算法，使其更像 Git，客户端接收增量事件并尝试与云状态进行最终的一致同步。 + +4. 为了推出功能，我们构建了一个自定义设置服务，允许工程师在功能标志后面编写代码。 这样，即使在睡眠者模式下，您也可以释放代码并收集数据，然后按客户，用户或主机组或 POD 或数据中心启用功能。 有了这种控制水平，即使是新工程师也可以放心地在功能标记后面编写代码并将其发布到生产环境中，而不必担心停机时间。 + +5. 监视，监视和监视。 您无法优化无法衡量的内容。 不利的一面是，在某些时候，我们监控得太多了，以致于我们无法专注于所有指标。 我们必须转移注意力，并依靠诸如 New Relic，bosun，ELK，OpenTSDB 和自定义报告之类的异常检测工具，使我们能够专注于从绿色->黄色->红色趋势发展的问题。 目的是在客户通知 之前，将它们捕获为黄色并且 [时捕获它们。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) + +### 您的系统如何发展以应对新的扩展挑战？ + +我们已经多次重新构造了许多层。 我将尝试列出过去 7 年中核心元数据，存储，搜索层的一些迭代。 + +1. 版本 1：在 Lucene 中搜索 Lucene 中的文件元数据，通过 NFS 安装在 DRBD Filer 中存储的文件。 关键点： Lucene 更新不是实时的，必须替换。 + +2. 版本 2：Berkeley DB 中的文件元数据，通过 NFS 挂载的 DRBD Filers 中存储的文件，在 Lucene 中搜索。 关键点： 我们打破了 NFS 的限制，它左右 and 住，必须用 HTTP 代替。 + +3. 版本 3：Berkeley DB 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 Lucene 中搜索。 关键点 ：即使分片的 Berkeley DB 在压力下也令人窒息，并且由于恢复需要数小时而导致数据库崩溃，因此必须更换它。 + +4. 版本 4：MySQL 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 Lucene 中搜索。 关键点： 公共云开始变得便宜。 + +5. 版本 5：MySQL 中的文件元数据，存储在 EOS / GCS / S3 / Azure 中并通过 HTTP 提供的文件，在 Lucene 中搜索。 阻塞点： 搜索开始阻塞，必须替换。 + +6. 版本 6：MySQL 中的文件元数据，通过 HTTP 服务的 EOS / GCS / S3 / Azure 中存储的文件，在 Elasticsearch 中搜索。 这是当前的体系结构。 + +7. 版本 7（未来）：将所有计算移至公共云，提供更多服务以实现影响隔离，动态资源池以有效管理宠物和牛。 + +### 您是否使用任何特别酷的技术或算法？ + +* 我们在核心服务和服务之间进行呼叫时使用指数补偿，以使用断路器来避免打雷。 + +* 我们使用核心服务节点资源上的公平份额分配来处理传入请求。 核心服务节点上的每个传入请求都被标记并分为各种组。 每个组都有专用的容量，如果一个客户每秒发出 1000 个请求，而另一个客户每秒发出 10 个请求，则此系统将确保其他客户不会因为邻居吵闹而挨饿。 诀窍是，如果您是目前使用该系统的唯一客户，则可以全力以赴，但是随着更多客户同时出现，您可以在其中共享容量。 对于某些大型客户，我们会分配专用池以确保一致的响应时间。 + +* 带有 SLA 的某些核心服务被隔离在 POD 中，这确保了一个不好的客户不会阻塞整个数据中心，但是这可能很快就需要轮回。 + +* 我们在桌面同步客户端代码中使用基于事件的同步，因为发生服务器事件时，它们会从服务器推送到客户端，并且客户端会在本地重播它们。 + +* 我们采用大规模数据过滤算法，以使大型客户端集群与 Cloud File System 同步。 + +* 我们根据问题陈述使用不同类型的缓存技术。 很少有以下口味： + + * 传统 + + * 内存中的-简单的 + + * 不可变的对象 + + * 内存中的大型数据集 + + * 用于在各个进程之间实现高度一致性的锁 + + * 已实施部分更新，以避免出现 GC + + * 内存中-高容量变异数据集 + + * 粗粒度无效 + + * 细粒度无效 + + * 基于磁盘的缓存 + +### 您做什么工作是与众不同的，人们可以从中学到什么？ + +专注于启动的核心功能，如果您遇到技术难题，就必须为其构建自定义内容，然后卷起袖子继续前进。 有很多独特的东西，但是基于事件的同步存储层绝对值得学习，这里有更多详细信息。 [Egnyte 对象存储库](https://www.egnyte.com/blog/2013/07/how-egnyte-implements-hybrid-object-stores-using-public-clouds-to-enhance-customer-experience/) 和 Egnyte [规范文件系统](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 + +### 您学到了什么？ + +* 您无法优化您无法测量的内容：测量所有可能且相关的内容，然后首先优化 80％处于使用状态的系统部分。 + +* 当您身材矮小的时候，请慢慢介绍技术，不要试图从中找到解决当前问题的理想工具。 编码是生命周期中最简单的部分，但是如果您拥有太多的技术，则其维护（如部署/操作/学习曲线）将非常困难。 随着您变得更大，您的部署中将有足够的脂肪来逐步进行服务划分。 学习保留一个或两个服务模板来实现微服务，不要为每个服务使用不同的技术堆栈。 + +* 作为初创企业，有时您必须快速行动。 介绍您现在可以做的最好的解决方案，如果发现有牵引力，请随着时间的推移重新设计该解决方案。 您可以尝试 10 种不同的方法，而只有 1 种方法可以看到牵引力，因此请快速进行一些操作，然后在看到牵引力的方法上重新架构，以适应业务规模。 + +* 寻找单点故障，并不懈地追查它们。 付出额外的努力来解决使您彻夜难眠的问题，并尽快从防御性转变为进攻性模式。 + +* 在 SOA 中，构建断路器以尽早减轻负载，如果服务受阻，则开始发送 503s。 与其惩罚所有人，不如看看您是否可以公平分配资源并仅惩罚滥用请求。 + +* 在服务使用者中添加了自动修复功能，服务可能会停止运行，并且像台式机客户端或其他服务这样的使用者可以进行指数补偿以释放服务器上的压力，并在服务再次起作用时自动修复。 + +* 始终可用：请客户提供服务级别的断路器和断路器。 例如，如果通过 WebDAV 或 FTP 访问文件系统存在性能问题，并且需要 4 个小时来修复，那么在这 4 个小时内，您可以在 kong / firewall 杀死 FTP / WebDAV 并要求客户使用 Web UI 或其他 工作机制。 同样，如果一个客户造成了导致系统阻塞的异常，则可以暂时为该客户禁用该客户或服务，并在解决问题后重新启用它。 为此，我们使用功能标志和断路器。 + +* 对于高度可扩展的服务，离开 Java 进程的成本很高，即使去了 Memcache 或 Redis 也是如此，因此我们对某些高度使用的数据结构（如访问控制计算，功能标志，路由元数据等）进行了具有不同 TTL 的内存中缓存。 。 + +* 我们看到一种有关处理大数据集的模式。 优化代码并挤走柠檬中的每一滴都是徒劳的，我们最终可能会使代码变得复杂且柠檬水苦涩。 通常，最简单的解决方案来自返回到绘图板，看看我们是否可以： + + * 通过使用启发式方法来减少我们需要处理的数据集大小 + + * 重组了我们在内存或磁盘中存储数据的方式。 + + * 在写时对数据进行规范化，并避免联接。 + + * 基于时间的过滤，例如存档较早的数据。 + + * 在多租户数据结构中创建较小的碎片。 + + * 使用事件更新缓存数据集，而不是完全重新加载。 + +* 保持简单：每个月都有新工程师加入，因此目标是从第一周开始就提高他们的工作效率-简单的架构可确保轻松上岗。 + +### 您为什么成功？ + +牵引力胜过一切。 当 EFSS 市场刚刚爆发时，我们达到了产品/市场契合度。 良好的执行力，以客户为中心，管理团队遵守财务纪律的时机可以成功。 许多竞争者采用了免费增值模式并筹集了一大笔资金，但是从第一天开始我们就开始收费，这使我们能够专注于随着市场需求的扩大而发展解决方案/团队。 专注于付费客户使我们能够提供企业级解决方案，而无需支付免费增值罚金。 + +### 您希望自己做些什么？ + +我希望当我们开始时，公共云不会像成本那样高。 我也希望我们从第一天开始就使用 SOA，花了一些时间才到达那里，但是现在我们就在那里。 + +### 您不会更改什么？ + +体系结构应具有延展性。 四年前，对于给定的问题，我有不同的答案，但是目前，我不确定。 我的意思是，随着您规模的扩大，过去 2 年前有效的设计模式和策略可能使您从防御性定位转向进攻性定位可能会在压力下屈服或变得成本过高。 只要更改将使系统变得有弹性或带来 10 倍的更改并为我们再购买 3-4 年的规模，我便会继续尝试更改它。 我不能在两年后发表评论，我会有同样的想法，他们可能会改变。 当您遇到下一个增长突增时，架构会发生变化。 + +### 您应该做多少前期设计？ + +很好的问题。 答案是“取决于”， + +* 如果您要设计核心存储层或核心元数据层之类的东西，那么再多花 2 周的时间就不会有多大伤害。 当我们在核心元数据层上从 Berkeley DB 迁移到 MySQL 时，我承受着很大的压力，我想到了一条捷径，当我通过我们的 CTO 运行它时，他建议花一些时间，“做正确的事情”。 ”作为回顾，这是一个极好的决定。 + +* 对于公共 API，最好做一个不错的前端设计，因为您没有第二次机会对其进行更改，并且必须在未来 4-5 年内进行维护。 + +* 如果要处理其 PB 级数据并带来巨大麻烦，那么我将再给它一个月的时间并进行更多的 POC。 + +* 但是，如果您要为内部服务设计一些东西并将其迁移到新的体系结构不会花费一年的时间，那么我建议您进行非常少的前端设计，并且只需快速构建版本并随着使用量的增长对其进行迭代 。 + +### 您如何考虑将来更改架构？ + +* 从静态 POD 转移到动态 POD，并无缝处理宠物和牛。 + +* 提供更具弹性的服务并隔离影响。 + +* 将我们的整个计算移至公共云，同时保留数据中心用于提供文件。 这将使我们能够在负载到来时自动放大/缩小。 我们已经使用公共云来自动扩展一些异步处理，例如视频转码，文本提取，数据迁移，搜索等。 + +* 一旦进入云，请使用更多自动缩放服务，例如 BigTable，PubSub，Spanner 等。 + +* 将我们的部署从 VM 迁移到 Kubernetes 中的容器，以提供挂起的服务。 + +* 自动化剩余数据库的架构管理 + +* 通过重新构建从某些增长最快的表中删除联接。 + +* 重写元数据的缓存层，并使用 Redis 数据结构代替 Memcache。 + +* 将频繁使用的流从强一致性转换为最终一致性。 + +## 您的团队如何设置？ + +### 您的团队中有多少人？ + +大约 700 名员工和承包商。 有 200 名工程师（DevOps / OPS / QA / Developers /…），其余为销售，市场营销，支持，产品管理，人力资源等。 + +### 他们在哪里？ + +最初是一支分布相当分散的工程团队，但现在主要吸引了印度波兰山景城的人。 一些像我这样的远程员工 和其他一些员工在家工作。 + +### 谁扮演什么角色？ + +这是一个很大的团队，我们有产品经理，UX 团队，DevOps，Scrum 团队，架构师，工程师扮演各种角色。 最初，工程团队很平坦，每个人都会向工程副总裁报告，但现在我们在两者之间增加了一层管理。 + +### 您是否有特定的管理理念？ + +如果您开发某些产品，那么您便拥有该产品的生命周期，这意味着您将与质量保证和 DevOps 一起使用，以确保产品经过测试/部署。 投入生产时，您可以使用各种内部工具（例如 New Relic / Grafana，Kibana）对其进行监视，如果存在回归，则可以对其进行修复。 我也是 1 人 1 任务理念的忠实拥护者，通过这种方式，如果工程师碰壁，他将找到某种最终克服它的方法，而不是太早放弃。 + +### 如果您有分散的团队，该如何工作？ + +自治，1-1 交流给他们带来挑战性的问题，亲自照顾和直接挑战，他们会受到激励。 + +### 您的开发环境是什么？ + +* 适用于服务器团队的 Ubuntu + +* UI 团队使用 Windows / mac 并连接到用于 REST API 服务器的本地 Ubuntu VM 或连接到共享的 QA 实例 + +* Eclipse /想法 + +* 适用于构建的 + +* Maven + +* 码头工人 + +* Gitlab + +* Jenkins + +* 汇合 + +* JIRA + +* Google 办公套件 + +* 松弛 + +### 您的开发过程是什么？ + +我们使用 Scrum，并为云文件系统团队提供每周发布。 我们使用 git-flow 的变体，对于每个票证，我们克隆存储库，并对每个合并请求运行自动化测试。 合并请求必须经过 2 位工程师的批准，然后才能解决 JIRA 故障单。 解决后，我们的管道将接管工作，而票务将接下去的下一班火车。 下一版本的培训已通过自动化 REST API 测试和一些手动烟雾测试进行了验证。 + +我们吃了自己的狗粮，代码在发布前 2-3 天送达了 UAT（供所有员工使用），我们发现了自动测试未发现的任何意外情况。 我们每个星期三进行生产部署， [每天监视新文物，并报告任何异常](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 的异常报告。 我们在一周中更改了部署，以实现工作与生活之间的平衡，并且通过这种方式，我们将让所有工程师可用，以防发布出现问题。 + +如果这是一项长期运行的功能，则工程师通常会在功能标志后面进行工作，并在各个阶段以 sleeper 模式提交代码，因此，每周（而不是大爆炸）都要测试他的代码。 我们也以一次迁移 1 个客户并仅为该客户打开功能的方式处理大型迁移，我们的一些大型迁移已运行 3-4 个月。 + +### 您有什么可以做的不同还是感到惊讶？ + +许多工程师在家工作，令人惊讶的是，有了自主权，许多远程员工像总部员工一样富有生产力和积极性。 + +## 您使用什么基础架构？ + +### 您使用哪种语言来开发系统？ + +主要是 Java / Python，以及 Go / C 中的一些小服务 + +### 您有多少台服务器？ + +我们有约 3000 多个由人偶管理的实例。 + +* 500+ Tomcat service instances + +* 500+ Storage nodes powered by Tomcat/Nginx + +* 100+ MySQL nodes + +* 100+ Elasticsearch nodes + +* 50+ Text extraction instances(autoscaled) + +* 100+ HAProxy instances + +* 和许多其他类型的服务 实例 + +### 如何将功能分配给服务器？ + +我们使用面向服务的体系结构，并根据服务类型分配服务器。 一些顶级服务是： + +* 元数据 + +* 储存空间 + +* 对象服务 + +* Web UI + +* 索引 + +* 同步 + +* 搜索 + +* 审核 + +* 内容智能 + +* 实时事件传递 + +* 文本提取 + +* 集成 + +* 缩略图生成 + +* 防病毒软件 + +* 垃圾邮件 + +* 预览/缩略图 + +* Rsync + +* API 网关 + +* 结算 + +* FTP / SFTP + +* 等等。 + +![](img/3d5e6054b4bacef5d0f2733fb962651b.png) + +### 如何配置服务器？ + +大多数服务都是伪造的，并且可以在 VM 上运行，我们仅针对 MySQL，Memcached 和存储节点等少数设备运行物理服务。 我们使用第三方根据模板来配置服务器，并将其放置在数据中心中，以供使用。 但是我们已经开始将一切迁移到公共云的工作，因此最终，一切都将在 Kubernetes 中运行。 但是，挑战在于如何在不停机的情况下如何在比赛中更换赛车发动机。 + +### 您使用什么操作系统？ + +CentOS7 + +### 您使用哪个 Web 服务器？ + +Nginx，HAproxy。 在一些旧的流程中使用了 Apache，但随着时间的流逝，它将被弃用。 + +### 您使用哪个数据库？ + +MySQL 和 Redis。 过去我们曾使用过其他数据库，例如 Berkeley DB，Lucene，Cassandra，但由于其对工程师/操作人员的熟悉程度和可扩展性，我们逐渐将所有数据库迁移到 MySQL。 有关更多信息，请参见 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 + +对于某些流，我们还使用 OpenTSDB，BigTable，Elasticsearch。 + +### 您是否使用反向代理？ + +是 Nginx 和 HAProxy + +### 您是否并置，使用网格服务，使用托管服务等？ + +我们并置，我们还使用公共云。 + +### 您的存储策略是什么？ + +我们首先创建自己的服务器，然后在机器中打包尽可能多的硬盘驱动器，我们过去将它们称为 DRBD Filers。 我们这样做是因为 AWS 成本过高。 我们已经评估了 [GlusterFS](https://www.gluster.org/) ，但当时它无法扩展以满足我们的需求，因此我们构建了自己的。 加班 S3 变得便宜了，GCS / Azure 诞生了，我们将存储层设计为可插入的，因此现在客户可以决定要使用哪个存储引擎（例如，Egnyte，S3，GCS，Azure 等）。 此时，我们在公共云中存储了 1 个 DR 副本，并与我们一起存储了 1 个副本，但是最终我们将使用我们的数据中心作为直通缓存，因为云中的计算便宜，但是带宽昂贵。 + +### 您如何增加产能？ + +我们已基于 Newrelic，Grafana 和其他统计数据提供了半自动化的容量规划工具，并根据观察监控报告中的关键指标并预定一些额外的容量，进行了定期的容量规划会议。 现在，某些服务已启用云服务，我们只是根据队列大小自动缩放它们。 + +### 您是否使用存储服务？ + +是 Egnyte，S3，GCS，Azure， + +### 您如何处理会话管理？ + +我们多次重写了体系结构，目前，有 99％的服务是无状态的。 仅服务 Web UI 的服务使用会话，我们在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性会话，但最终，我的计划是也 使用 JWT 或类似方法实现无状态。 + +### 您的数据库是如何设计的？ 主从？ 碎片？ 其他？ + +我们几乎对所有具有自动故障转移功能的数据库都使用了 Master-Master 复制，但是在一些突变程度很大的数据库上的切换是手动完成的，我们遇到了一些问题，其中由于复制滞后，自动切换会导致应用程序数据不一致，我们 需要重新架构一些核心文件系统逻辑来解决此问题，我们最终将完成此工作。 下面是有关处理数据库升级的问题，详细回答了有关数据库体系结构的更多详细信息。 + +### 您如何处理负载平衡？ + +我们根据客户使用 DNS 访问系统的 IP 进行地理平衡，并在数据中心内使用 HAProxy 将其路由到相应的 POD，并在内部 POD 中再次使用 HAProxy 路由 + +### 您使用哪个 Web 框架/ AJAX 库？ + +我们已经多次更改了 UI，这是一直在变化的一件事。 过去，我们不得不使用 ExtJS，YUI，JQuery，而不能使用其他东西。 最新的迭代基于 ReactJS / Redux 以及 Backbone / Marionette 上的一些旧代码。 + +### 您使用哪些实时消息传递框架？ + +我们使用 [大气](https://github.com/Atmosphere/atmosphere) ，但最终，我们将其替换为 NodeJS + +### 您使用哪个分布式作业管理系统？ + +为此，我们使用 Google Pubsub，RabbitMQ 和基于 Java / Python 的消费者服务。 + +### 您的网站是否有标准 API？ 如果是这样，您将如何实施？ + +我们的 API 分为 3 种类型：- + +1. 公共 API： 这是我们向第三方应用程序工程师和集成团队以及我们的移动应用程序公开的 API。 我们会按照适当的弃用工作流程来弃用/升级 API 签名，并且更改始终向后兼容。 我们使用 Mashery 作为网关，API 记录在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) + +2. 适用于我们客户的 API： 此 API 对我们客户而言是内部的，如果我们以外的人使用此 API，我们不保证向后兼容。 + +3. 服务之间的内部受保护的 API： 这是服务在我们的数据中心内部用于相互通信的 API，无法从外部防火墙调用。 + +### 您的对象和内容缓存策略是什么？ + +我们存储了 PB 级的数据，但无法缓存所有数据，但是如果客户在给定的 15 天时间内拥有 5000 万个文件，则他可能只使用其中的 100 万个。 我们有基于 tomcat / Nginx /本地文件系统的缓存文件管理器节点，它以 LRU 方式运行。 我们可以弹性地增加减少缓存文件服务器的数量。 我们最大的问题之一是上传速度，如何从世界任何地方尽可能快地将数据上传到 Egnyte，为此，我们构建了特殊的 Network pops，如果您好奇的话可以在阅读更多内容 [为 Egnyte 客户加速数据访问](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) + +Memcached / Redis 用于缓存元数据，我们使用单独的 Memcached 池来缓存长期存在的静态数据和文件系统元数据。 核心文件系统元数据非常庞大，不适合当前的 Memcached 节点，并且会逐出最近使用的其他类型的数据。 为了防止这种情况，我们使用 3 种类型的池，应用程序代码决定在哪里查找哪种数据。 我们允许在文件系统 Memcached 缓存中逐出，并在其他种类的 Memcached 池中争取零逐出。 对于不同种类的数据，我们也使用不同的对象到期时间。 对于我们一些频繁使用的数据（例如客户信息或分片映射），即使每个请求都转到 Memcache，也会因某些请求（例如文件夹列表）而减慢速度，因此我们在每个 JVM 上对该数据进行内存内缓存，并刷新数据 基于自定义 TTL 或我们使用某种 pub-sub 机制刷新它。 + +缓存中的两个最大难题是权限和事件。 对于权限数据，我们已经多次重选了该层，最近我们编写了一个 TRIE 来有效地缓存该层。 + +对于事件，我们将其缓存在 Memcache 中，但是有可能在夜间为客户发布了约 10 万个事件，而在早上 9:00 AM 突然有 3 万个人打开了笔记本电脑，现在每个人都希望这些 10 万个事件可以 使他们的系统一致。 这是一个有趣的规模问题，因为这将需要您在短时间内（例如 15 分钟）处理 30B 事件，并且仅发送用户有权访问的事件。 由于事件是不可变的，我们将它们在 Memcache 中缓存了 12 个小时，但是即使它们从 Memcache 下载相同的事件那么多次也会导致网络问题。 最终，我们在短时间内将事件缓存在内存中，并且随着我们进行许多年轻一代的收集工作，还调整了这些节点上的 GC 设置。 与其他节点相比，我们还将这些节点放置在速度更快的网络上，但仍然没有解决这个问题:)。 + +### 您的客户端缓存策略是什么？ + +对于我们的 Web UI，我们使用 requireJS 和其他各种方式来仅下载所需的模块。 我们的 Mobile 和 Desktop 客户端丰富使用本地文件系统作为缓存。 + +### 您使用哪些第三方服务来帮助您构建系统？ + +我们使用了一些 Google 服务，Azure，New Relic，Authy，MixPanel，Flurry，Tableau，但大多数核心组件都是由我们构建的。 + +## 您如何管理系统？ + +### 您如何检查全局可用性并模拟最终用户性能？ + +我们使用不同 AWS 区域中的节点来一致地测试带宽性能。 我们还使用内部 haproxy 报告来绘制客户观察到的上载/下载速度，并主动寻找它们，并使用网络弹出消息和其他策略来加速数据包。 + +![](img/6ffa16c86d1956a9ff0be037d6021022.png) + +### 您如何健康检查服务器和网络？ + +Nagios，Grafana 和 New Relic 以及一些内部主动异常分析被使用。 有关更多详细信息，请参见此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) + +### 如何绘制网络和服务器统计数据以及趋势图？ + +我们使用 Grafana，Kibana，Nagios 和 New Relic。 + +![](img/dedeb468380c2680e693cd8a5743a335.png) + +![](img/293ca1407b4f34397f578ec21c96afd2.png) + +### 您如何测试系统？ + +硒，Junit，鼻子，Nightwatch 和手动测试。 单元，功能，集成和性能测试的组合。 + +### 您如何分析效果？ + +New Relic 用于监视应用程序性能。 我们还使用本地框架生成了大量内部应用程序指标。 我们使用 Grafana / Nagios / Kibana，内部工具和其他工具来监视系统其他部分的性能。 有关更多详细信息，请参见此博客文章 [分布式系统中的调试性能问题](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) + +### 您如何处理安全性？ + +专门的安全团队在每个版本之前都会运行自动化的安全基准测试。 连续自动笔测试正在生产中运行。 我们还使用漏洞赏金计划，并与 whitehat 测试公司合作。 一些客户使用第三方进行自己的安全性测试。 + +## 您如何处理客户支持？ + +我们有专门的 24X7 分布式客户成功团队，我们使用 Zendesk 和 JIRA + +## 您如何确定要添加/保留的功能？ + +### 您是否实施网络分析？ + +我们使用 Google Analytics（分析），Mixpanel，Flurry 来衡量功能使用情况 + +### 您是否进行 A / B 测试？ + +是的，我们使用功能标记进行 A / B 测试。 有关更多信息，请参见 [在 Egnyte 使用功能标志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) + +### 您要运行多少个数据中心？ + +3 个主要数据中心，包括欧洲的一个（由于安全港规则） 和遍布世界的网络流行音乐。 + +### 您的系统如何部署在数据中心中？ + +Puppet / Ansible 用于部署大多数新代码。 + +### 您使用哪种防火墙产品？ + +帕洛阿尔托网络 + +### 您使用哪个 DNS 服务？ + +NS1 + +### 您使用哪些路由器？ + +思科 + +### 您使用哪些开关？ + +Arista + +### 您使用哪个电子邮件系统？ + +我们结合使用 SendGrid 和我们自己的 SMTP 服务器。 + +### 如何备份和还原系统？ + +对于 MySQL，我们使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，对于 Elasticsearch，该数据被复制 3 次。 对于客户文件，我们将其复制 3 次，并将 1 个副本存储在 DR 公共云中。 如果存储 Filer 无法恢复，我们将丢弃它，添加一个新 Filer 并再次复制副本。 对于某些客户，我们还会将其数据复制到他们选择的提供商。 对于使用 S3，Azure 或 GCS 作为可插拔存储层的客户，它将确保复制以防止数据丢失。 + +### 如何进行软件和硬件升级？ + +大多数节点是无状态的，并且有状态组件具有主动-主动故障转移。 通过将节点从池中取出并进行升级并将其放回池中来处理升级。 我们使用 jenkins + Ansible + puppet 和自定义自动化。 + +### 您如何处理升级时数据库架构的重大更改？ + +不同的服务使用不同类型的数据库，并且它们以不同的方式升级。 在 10000 英尺处，它们如下图所示： + +![](img/4424662bfcfaca90969ec39e8fa0dbb4.png) + +1. EOS DB 存储对象元数据并且增长非常快，它经过分片，并且我们将继续添加更多此类数据。 + +2. MDB 的增长速度更快，经过了分片，并且我们会继续增加更多。 + +3. DC_central 是一个 DNS 数据库，并且保持相当静态。 我们运行了许多此副本以实现可伸缩性。 + +4. Pod_central 具有快速变异的数据，但每个表的增长量不超过 2000 万行。 我们运行了许多此副本以实现可伸缩性。 + +* 每个数据库模式始终是向前和向后兼容的，即我们绝不会在同一发行版中删除列和代码，我们首先在停止使用该列的发行版 1 中部署代码，而在发行版 2 中我们删除该列。 + +* 非分片数据库每周更新一次。 它们是存储各种功能驱动表的表。 我们目前在生产环境中使用脚本对其进行升级，但是我们在质量检查中使用 Liquibase，并且正在逐步将其应用于生产环境 + +* 使用自动脚本进行分片的数据库新列更改 + +* 分片数据库迁移是一件痛苦的事情，因为我们有 12000 多个分片并且还在不断增长，您无法在 1 小时的升级窗口中完成。 方法是： + + * 实时代码根据需要迁移行。 这意味着迁移可能需要几个月的时间。 + + * 使用功能标记进行迁移，您同时拥有新旧代码，并且在后台迁移客户，然后翻转标记以将其切换到新代码路径而无需停机，更多的是 [此处](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此处](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) + + * 当我们从 Lucene 迁移到 ElasticSearch 时，除了重新索引所有内容外，我们别无选择，我们使用了 [功能标记](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) ， -4 个月完成。 + +* 模式一致性检查器报告可确保升级后所有数据中心中的所有模式均相同。 + +### 您是否有单独的运营团队来管理您的网站？ + +是的，我们有一个专门的生产工程师，SRE 和一个 IT / Ops 团队，负责监视和管理生产。 但是正如我之前所说，构建此功能的工程师负责制定决策，因此他们将深入参与监视指标并解决生产问题。 + +## 其他 + +### 您欣赏谁？ + +AWS ：他们的创新步伐令人赞叹。 + +Google ：它们的工具如 BigQuery，Kubernetes 很棒。 + +Elasticsearch： 其余的 API 简单性和架构很棒。 我们用一个 TB 的数据和一个工程师来管理一个 100 多个节点的集群。 + +MySQL / Memcache： 它们简单，快速且很棒。 + +Eclipse / Jenkins ：插件架构很好。 + +### 您是否模仿了其他人的公司/方法？ + +我们是 [http://highscalability.com/](http://highscalability.com/) 的常规读者，许多设计都受到它的启发。 + +* POD 架构的灵感来自 Tumblr 的 Cell 架构。 这不是精确匹配，但是隔离故障的概念是相同的。 + +* 受 Facebook 启发的架构在 12 个小时后会在 Memcached 和刷新键中产生抖动。 + +* 受 [http://highscalability.com/上一些文章的启发，将](http://highscalability.com/) [指纹添加到每个数据库查询](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) + +我们正在招聘，请在 [职位页面](https://www.egnyte.com/jobs/) 中查看我们，并在 [与我们联系 [受电子邮件保护]](/cdn-cgi/l/email-protection) 。如果您有兴趣成为 [Egnyte](https://www.egnyte.com) 令人惊叹的团队的一员。 \ No newline at end of file diff --git a/docs/217.md b/docs/217.md index 8d1fe69..72461fd 100644 --- a/docs/217.md +++ b/docs/217.md @@ -1,153 +1,49 @@ -# Notify.me 体系结构-同步性 - -> 原文： [http://highscalability.com/blog/2008/10/27/notifyme-architecture-synchronicity-kills.html](http://highscalability.com/blog/2008/10/27/notifyme-architecture-synchronicity-kills.html) - -开始一个新项目的好处是，您终于有机会正确地做它。 当然，您最终会以自己的方式弄乱一切，但是在那一瞬间，世界有了一个完美的秩序，一种让人感到满足和美好的正义。 全新的实时通知交付服务 notify.me 的 CTO Arne Claassen 现在正处于这个蜜月期。 - -Arne 足够亲切地与我们分享他如何构建通知服务的理念。 我想您会发现它很有趣，因为 Arne 对其系统如何工作进行了许多有用的详细介绍。 - -他的主要设计理念是最小化围绕同步访问形成的瓶颈，即，当*请求了一些资源并且请求者占用更多资源，等待响应时。 如果无法及时交付所请求的资源，则会堆积越来越多的请求，直到服务器无法接受任何新请求为止。 没有人得到他们想要的东西，而您断电了。 通过将请求和响应分为单独的消息传递操作将同步操作分解为异步操作，可以停止资源过载。 它可以使系统尽可能快地处理积压的请求，而不会导致系统因并行请求过多而崩溃。 在大多数情况下，请求/响应周期是如此之快，以至于它们看起来像线性的事件序列。* - -Notify.me 正在采用一种创新且冒险的策略，即使用基于 XMPP 的系统 ejabberd 作为其内部消息传递和路由层。 Erlang 和 Mnesia（Erlang 的数据库）是否能够跟上通信量并在通信量扩展时保持低延迟？ 找出来将会很有趣。 - -如果您对 notify.me 感兴趣，他们已经为 HS 读者提供了 500 个 Beta 帐户： [http://notify.me/user/account/create/highscale](http://notify.me/user/account/create/highscale) - -## 你是谁？ - -我的名字是 notify.me 的首席技术官 Arne Claassen。 在过去的十年中，我一直在致力于高度可扩展的基于 Web 的应用程序和服务。 这些站点采用了各种传统扩展技术的组合，例如服务器场，缓存，内容预生成以及使用复制和群集的高可用性数据库。 所有这些技术都是减轻许多用户争用的稀缺资源（通常是数据库）的方法。 知道了这些技术的好处和陷阱后，我就成为专注于规避稀缺资源场景的架构师系统的焦点。 - -## 什么是 notify.me，为什么创建它，为什么它是一件好事？ - -notify.me 是我们首席执行官 Jason Wieland 的创意。 这是一种近乎实时的通知服务，可提醒用户注意网络上发布的新内容。 - -旨在解决普通用户难以及时掌握网络上发生的时间紧迫事件的麻烦。 例如，一旦发布符合其搜索条件的新公寓，就会在 Craigslist 上搜索公寓的用户收到警报。 notify.me 所做的艰巨工作是反复检查 Craigslist 是否有新列表，并在发布新列表时提醒用户。 通知可以传递到即时通讯程序，桌面应用程序，移动设备，电子邮件和 Web 应用程序。 - -我们的目标是创建和发布开放的 API，使人们能够构建新的有趣的应用程序以生成和传递信息。 - -## 您的服务与人们可能熟悉的其他服务相比如何？ 像 Twitter，Friend Feed，Gnip 或 Yahoo Pipes？ - -有很多公司处于我们的竞争格局中，其中有些是直接竞争对手，例如 yotify.com 或 Alerts.com。 主要区别在于我们的方法。 Yotify 和警报的重点是作为通知门户网站供用户访问。 notify.me 是一个实用程序，重点是通过 XMPP 和 REST API 提供网站上所有可用的功能，允许用户与来自其选择应用程序的通知进行交互。 我们还允许将消息升级到目的地。 例如，如果用户未登录其 IM 或状态为离开，则可以升级通知并将其路由到其移动设备。 - -在消息传递领域，我们几乎与 Twitter 相反。 Twitter 基于其自己的用户生成的内容向内发布模型。 有人发了一条推文，并发布给了他们的关注者。 notify.me 正在创建一个面向外部的消息传递系统。 用户添加支持 Web feed 标准的任何网站，或将现有的通知电子邮件重定向给我们。 如果有的话，我们是一条消息传递管道，是对 titter 的补充（更多内容请参见下文）。 - -Friendfeed 在将您所有的社交网络合并到一个集中区域方面做得很好。 他们的主要重点是构建与捣碎的供稿进行交互的功能和工具。 此供稿非常适合作为 notify.me 的源添加，允许用户通过即时通讯程序接收所有社交网络更新。 社交瘾君子想要的功能是能够实时了解墙上是否有新帖子，以便您可以立即做出响应。 - -雅虎管道将被视为可能的合作伙伴，类似于他们向 Netvibes 和 Newsgator 追加销售的方式。 他们的重点是提供一个直观的编程界面，以便能够操纵提要并创建有用的混搭。 - -例如，[热门交易搜索](http://pipes.yahoo.com/pipes/pipe.info?_id=_E8FgV_42xGWa5pfZVUMqA)是一个漂亮的管道，可在一组网站上搜索最佳交易。 由于目标选项有限，用户可能不想使用 Yahoo 自己的通知选项。 - -在我们的 Beta 组中，我们看到用户添加 eBay 链接的活动类似。 ebay 有一个竞争性的通知管道来通知 notify.me，但是用户仍然在我们的服务中添加 ebay 搜索链接。 事实证明，他们希望在一个中央位置来管理各种新闻源。 - -Gnip 是纯粹的基础设施。 我们有类似的技术，但我们要追求完全不同的市场。 - -我们产品尚未公开的另一个核心功能是，我们的管道是双向的，即任何数据源也可以是目的地，反之亦然。 这样做的主要好处是能够响应消息，例如确认收到的支持通知单。 双向通信将需要与 notify.me API 集成，源可以通过该 API 来传递回复选项。 - -我们目前正在与 Twitter API 进行深度集成，以通过 IM 在您已收到其他通知的同一通道中为推文提供双向功能。 - -## 您能否解释 notify.me 的不同部分以及它们如何连接在一起？ - -一般而言，我们的系统由三个子系统组成，每个子系统都有许多实现。 -1\. **接收**由 rss 和电子邮件接收器组成，它们会不断检查用户的电子邮件地址（ [[受电子邮件保护]](/cdn-cgi/l/email-protection) ）和用户的供稿中是否有新数据。 新数据变成通知，并传播到路由。 -2\. **路由**负责将用户的通知发送到正确的交付组件。 路由是系统中与用户进行交互以进行管理的点，例如更改源和目​​的地以及查看历史记录。 通知历史记录是一个专门的传递组件，即使在通过整个管道后，也可以通过网站仔细阅读所有消息。 -3\. **传递**当前由历史记录（总是获取消息），Xmpp IM，SMS 和电子邮件以及正在开发的私有 RSS，AIM 和 MSN 组成。 从更高的技术层面来看，此系统的拓扑结构由两个单独的消息总线组成： -1\. **存储转发队列**（使用 [simpleMQ](http://sourceforge.net/projects/simpleMQ) ） -2 。 **XMPP** （使用 [ejabberd](http://www.ejabberd.im/) ） - -**摄取端使用存储和转发队列**来分发摄取工作，并且通常在任何地方进行 数据在用户的路由规则可见之前进行处理。 这允许扩展灵活性以及在组件故障期间进行进程隔离。 - -**Xmpp 总线**被称为 Avatar 总线，之所以这样命名，是因为每个数据拥有实体均由守护进程表示，该进程是该实体数据的唯一授权。 我们有四种类型的化身，即 Monitor，Agent，Source 和 User -1。 **Monitor** 化身只是负责观察实例运行状况并根据需要旋转和关闭其他计算节点的负责方。 -2\. **代理**化身是将网关提供给我们用户的状态信息并将消息传递给用户的传递网关。 -3\. **源**化身是摄取器，例如 RSS。 该化身从存储和转发队列中提取新消息，并将新消息通知其订户。 -4\. **用户**化身可保留特定用户的所有配置和消息传递数据。 它负责接收来自摄取头像的新通知，确定路由并将消息推送到适当的传递代理，因为该代理声明了执行该传递的能力。 - -## 您面对哪些特殊挑战，如何克服这些挑战？ 您考虑了哪些选择，为什么决定以其他方式进行选择？ - -从一开始，我们的主要目标就是避免瓶颈和阻碍水平扩展的障碍。 最初，我们计划将整个系统构建为通过队列的无状态消息流，沿线的每个守护程序都负责流经它的数据，然后将其合并，复用和路由到下一个点，直到实现交付为止。 这意味着除了备份队列之外，没有任何一个部件的故障会影响整个部件。 - -但是，我们很早就意识到，一旦为用户指定了一条消息，我们就需要能够跟踪消息的位置并能够根据用户的配置和状态动态地重新路由它。 这导致我们通过 REST API 在守护程序之间添加了一些不适当的耦合。 由于我们仍在将处理迁移到组合队列/异步总线体系结构，因此仍然存在一些这种问题。 - -当我们意识到没有状态的纯消息传递将无法满足我们的动态需求时，简单的解决方案是返回到尝试过的状态保持器，即中央关系数据库。 知道我们的扩展目标后，这会引入一个失败点，我们迟早将无法缓解这一点。 我们决定以不同的方式来看待我们的状态，而不是考虑根据功能（即摄取，解析，转换，路由，交付）基于流过的数据查询状态来创建处理单元，而是想到了这些单元 在数据所有权方面，即来源和目的地（用户）。 一旦走上了轨道，几乎没有共享状态，我们可以更改存储模式，让每个数据所有者对自己的数据负责，从而允许持久层的水平扩展以及更高效的缓存。 - -跨所有者访问数据的其余需求是分析。 在许多系统中，分析是存在中央数据库的主要原因，因为事实和维度经常在生产模式中混杂在一起。 就我们的目的而言，此数据与生产无关，因此永远不会影响活动容量。 用法和状态更改被视为不可变的事件，它们在发生时排队进入我们的存储转发系统。 我们存储转发队列的性质使我们能够自动将所有主机中的所有这些事件收集到中央存档中，然后可以通过 ETL 流程将其处理为事实和维度数据。 这允许对使用情况进行近实时跟踪，而不会影响面向用户的系统。 - -## 您能否再解释一下您对 XMPP 的选择？ 它主要用作 EC2 节点上的联合 XMPP 服务器之间的消息总线吗？ 是否将 XMPP 队列用作来自所有来源的每个用户的消息的队列，然后再将其推送给用户？ - -我们有三个不同的 xmpp 群集，它们利用联合来进行跨阶段的操作：用户，代理和头像总线。 - -### 用户数 - -这是一台常规的 xmpp IM 服务器，我们在该服务器上为每个用户创建帐户，向他们提供可从任何具有 Xmpp 功能的客户端使用的 IM 帐户。 此帐户还用作我们的桌面应用程序登录时的用户，这将成为我们用于第三方消息提取和分发的 API 的身份验证 - -### 代理商 - -连接到该群集的守护程序充当我们的内部 Avatar 总线与外部客户端之间的通信桥。 目前，这主要是用于与聊天客户端进行通信，因为每个用户都被分配了一个他们无需我们即可通过其进行通信的代理，无论他们使用其默认帐户还是使用诸如 jabber.org，googletalk 等的第三方帐户。 通过专用代理的这些代理测试使用 Xmpp RPC 的客户端 API。 将来，我们还将为第三方集成提供完整的 XMPP 和 REST API，这些 API 将使用代理与 Avatar 总线进行通信。 - -我之前提到过，代理程序也是化身，但是它们有点特殊，因为它们在 Avatar 总线上没有用户，而是通过跨服务器联合与其他化身进行对话。 我们目前还在为 Oscar 和 MSN 网络建立代理，由于它们的本机传输不是联邦的，因此它们将直接位于头像总线上。 我们还计划评估其他网络，以获得将来的支持。 - -### 头像 - -头像是我们的内部消息总线，用于路由和处理所有命令和消息。 尽管我们确实利用在线状态进行监视，但我们主要在头像之间使用直接消息传递和基于 IQ 的 RPC 节。 - -那么什么是化身？ 它是一个守护程序（单个物理守护程序进程可以托管许多化身守护程序），是某些外部实体数据的权限。 即 在 notify.me 中注册的每个用户都有一个化身，用于监视代理的状态变化，接收照顾该用户的消息并负责将这些消息路由到适当的传递渠道。 这意味着每个头像都是关于该用户的所有数据的唯一授权者，并负责持久化数据。 如果系统的其他部分想要了解有关该用户的信息或修改其数据，它将使用 Xmpp RPC 与虚拟形象进行对话，而不是与某些中央数据库进行对话。 目前，化身持续存在于磁盘和 SimpleDB 中，同时保持 ttl 管制的高速缓存正在进行中。 由于仅化身可以写入自己的数据，因此无需检查数据库，而是可以将其内存和磁盘缓存视为权威，而 SDB 主要用于写入。 仅在节点发生故障时才需要读取以在另一节点上启动化身。 - -在巴士的另一端，有我们的摄入装置。 摄取器由许多守护程序组成，通常在针对外部源的轮询循环上运行，将新数据排队到我们的存储转发队列中，适当的摄取器头像会拾取新消息并将其分发给其订阅者。 在摄取器头像方案中，它是订阅和路由数据的权限。 - -这是一个典型的用例：用户通过 Web 界面订阅 RSS feed。 Web 界面将请求发送到用户的头像，该头像将保留订阅以供参考，然后从 rss 接收器请求订阅。 随着新的 rss 项目到达，rss 摄入器会将项目多路复用到订阅该供稿的所有用户头像。 用户化身依次确定适当的投放机制并安排投放时间。 一般而言，这意味着用户头像通过``用户代理''订阅了用户的 Xmpp 状态。 在用户处于接受消息的适当状态之前，用户化身排队 rss 项目。 一旦用户准备好接收通知，就将状态更改从代理传播到内部总线，然后用户化身将 rss 项目发送给代理，代理再将其发送给用户。 - -目前，所有头像均始终在线（即使大部分都是空闲的），这对于我们当前的用户群来说还不错。 我们的计划是修改 ejabberd 的脱机存储模块，以便我们可以盲目发射节并使队列中的消息向监视器发出信号以启动用于目标 XmppId 的适当化身。 一旦建立了该系统，我们将能够按需启动化身，并在闲置时将其关闭。 - -## 您希望在什么流量负载下破坏当前的体系结构，您的计划是什么？ - -由于我们的系统是分布式的，并且是设计异步的，因此应避免在负载下发生系统范围的故障。 但是，尽管避免了所有常见的瓶颈，但事实是我们的消息总线使这一切成为可能，这可能成为我们的限制因素，要么是因为它无法处理化身的数量（总线上的节点），要么是因为延迟 巴士变得无法接受。 我们只是开始使用头像系统作为我们的骨干网，所以它仍然有点脆弱，我们仍在对 ejabberd 进行负载测试以确定在什么时候遇到限制因素。 - -虽然我们已经在集群 ejabberd，但 mnesia 数据库复制和跨节点震颤的负载意味着连接数或延迟都将最终导致集群失败或仅消耗太多内存来进行管理。 - -由于我们的消息传递主要是点对点的，因此我们希望可以将用户群划分为头像孤岛，每个孤岛都托管在专用的头像子域群集中，从而减少了消息和连接负载。 只要我们的筒仓经过适当设计，以将跨子域的中断保持在最低水平，我们就应该能够拥有 n 个筒仓来保持负载最大。 - -要避免这种体系结构失败，我们面临的最大挑战就是永远保持警惕，防止引入会造成消息传递瓶颈的功能。 我们通过单个处理器或处理器系列的大量消息流量会引入依赖关系，我们无法通过子域划分来扩展自己。 - -## 相关文章 - -* [notify.me 技术博客-INotification](http://techblog.notify.me/)* [Flickr-预先进行必要的工作并将其余的工作排入队列](http://highscalability.com/strategy-flickr-do-essential-work-front-and-queue-rest) - -好东西！ 很高兴看到 erlang（和 ejabberd）越来越受欢迎！ - -尽早优化，对吧？ 所有的扩展工作，尽管疯狂有趣，并且在智力上令人兴奋，但直到成功真正需要时，它们才如此。 - -您可能还说这是浪费。 :) - -我不认为早期优化在这里是错误的。 由于执行此操作的大多数工具几乎都是“开箱即用”的，因此通常只需要简单（但可能会很耗时）的管道即可。 这个设置似乎没有什么真正复杂的。 - -我想知道在以下情况下 notify.me 采取了哪些措施来克服这种即时性： - -假设那里有 10,000 名程序员从 CraigList 订阅了“高级程序员”。 一旦一家公司在 CraigList 上发布了“高级程序员”的招聘广告，所有这 10,000 名程序员都会收到 IM，SMS 或电子邮件的通知。 （希望我到目前为止是对的），notify.me 如何保证通知将同时（几乎）发送给订阅者？ 如果第一个程序员收到通知的时间与最后一个程序员收到通知的时间之间的时间间隔大于 10 分钟，则这是毫无意义的通知。 - -希望我说得足够清楚。 - -关于早期优化：由于我们没有处理已建立的沟通渠道（就像大多数网络媒体资源一样），因此我们无法明确定义提升的方式。 看看我们从第一种方法中学到的知识，很明显地，我们需要一些可以扩展的基线管道，因为一旦需要，就可能会重新构造我们路由消息的方式 。 - -您好，我叫 Jason Wieland，我是 notify.me 的首席执行官，我只想对所有评论（公开和私人）表示感谢，并回答最后一个帖子。 - -飞行员负责将通知发送给用户。 这些是分布式守护程序，旨在可伸缩且不会过载。 实时消息传递（读取 IM，桌面应用程序）引擎每秒可以处理数千条消息。 电子邮件和短信（在获得简短代码之前）是另一回事。 电子邮件是通过多头 smtp 集群发送的，但是，我们只能依靠 smtp 协议流程的工作方式。 因此可能会有时间波动。 - -我们建议任何想要立即收到通知的人使用 Instant Messenger 或我们的桌面应用程序。 - -谢谢， - -杰森 - -Jason， -谢谢您的答复。 -正如您提到的， - -“实时消息传递（读取 IM，桌面应用程序）引擎每秒可以处理数千条消息。” - -使用 IM 的订户可以同时接收通知吗？ 是否没有循环遍历所有订户并向其发送通知？ 因为我绝对是可伸缩性的新手，所以我能想像出要解决此问题的方法是导入“ fork-join”模型，以同步所有守护程序。 - -祝您一切顺利 -刘浩 - -Hello Hao Liu, - -用户可以在同一批次中收到多个通知。 批处理是我们创建的 2 秒窗口，用于将同时到达的消息分组在一起。 每个用户只有一个轻量级守护程序（称为 Avatar）。 每个用户平均每天会收到 30 条通知，因此大多数时间它处于空闲状态，并且有足够的空间来处理一组消息。 虽然它们要在相同的时间实例中进行处理。 它们将在不到一秒的时间内被处理（我们的目标是每位用户每秒处理约 100 条消息）。 \ No newline at end of file +# 缩放原理 + +> 原文： [http://highscalability.com/blog/2020/5/14/a-short-on-how-zoom-works.html](http://highscalability.com/blog/2020/5/14/a-short-on-how-zoom-works.html) + +![](img/63800fed327b13517b4aa92582805e07.png) + +整个晚上，Zoom 的规模从 2000 万增加到 3 亿。 令人难以置信的是，从外部看，他们并没有表现出明显的成长痛苦，尽管在内部，这是一个很好的押注，很多疯狂还在发生。 + +当然，Zoom 做出了一些设计决策，这些决策对于一个小型的，不起眼的初创公司来说是有意义的，但作为事实上的标准并没有多大意义，但这是可以预期的。 正如许多人所建议的，这并不是不良体系结构的迹象。 这实际上是产品的演变方式，尤其是当它们必须在数周，数天甚至数小时内提升时。 + +突然的成功需要进行仔细的审查，因此每个人都想知道 Zoom 的工作原理。 问题是我们了解的不多，但是我们确实有一些信息来源： + +* [缩放方式可提供业界领先的视频容量](https://blog.zoom.us/wordpress/2019/06/26/zoom-can-provide-increase-industry-leading-video-capacity/) +* [给我们用户的消息](https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/) +* 一年前的营销视频 [Zoom 独特的体系结构如何为您的视频带来最大的 UC 未来](https://www.youtube.com/watch?v=5BMbsFqtD0A) +* 2016 年关于[的文档全球基础设施和安全指南](https://zoom.us/docs/doc/Zoom_Global_Infrastructure.pdf) +* 已有一年的新闻稿 [Zoom 借助 Equinix 扩展，以适应未来需求并扩展其视频优先，云原生架构](https://www.prnewswire.com/news-releases/zoom-expands-with-equinix-to-future-proof-and-scale-its-video-first-cloud-native-architecture-300962299.html) +* [Zoom CFO 解释了公司如何应对不断增长的需求](https://www.cnbc.com/2020/03/18/zoom-cfo-explains-how-the-company-is-grappling-with-increased-demand.html) +* 在线问& A [问 Eric 任何问题](https://www.youtube.com/watch?v=tlC-sEdqY48) +* AWS 说[大多数 Zoom 运行在 AWS 上，而不是 Oracle 上](https://www.datacenterdynamics.com/en/news/most-zoom-runs-aws-not-oracle-says-aws) + +以下是其中一些来源的介绍： + +* 有关 Zoom 的数据中心使用情况有很多争论。 最终的结果是，他们从自己的共享空间开始，然后随着增长的高峰而扩展以使用多个云。 几乎教科书的执行如何处理突如其来的增长。 +* [大多数 Zoom 都在 AWS 上运行，而不是在 Oracle 上运行-AWS 说](https://www.datacenterdynamics.com/en/news/most-zoom-runs-aws-not-oracle-says-aws)：自大流行到来以来，该服务已将大量实时视频会议流量移至 AWS 上，并且容量也有所减少 在 Oracle Cloud 上...首席执行官 Eric Yuan 进一步澄清了这一点，解释说 Zoom 过去在“自己的数据中心”中处理实时视频会议流量...我们的实时流量始终留在我们自己的数据中心内 对于我们的付费客户...在这场大流行危机期间，每天都是新的记录。 我们自己的现有数据中心实际上无法处理此流量...这意味着 AWS 每天都会为 Zoom 旋转成千上万的新服务器...因此最终，我们自己的数据中心（主要是 Amazon）以及 在 Oracle 云中，这三者共同为所有前所未有的流量提供服务。 +* 我们对 Zoom 的架构知之甚少，但此营销视频进行了一些详细介绍： [Zoom 独特的架构如何为您的视频带来最大的 UC Future](https://www.youtube.com/watch?v=5BMbsFqtD0A) 。 +* Zoom 将其架构视为竞争优势。 每个人都将使用视频，那么我们如何扩展到每个人？ 因此 Zoom 始于无处不在的视频目标，并让该目标塑造了他们的架构。 +* 竞争对手通过数据中心进行长号通信，将其转码为其他人的普通视图，然后将混合视频发送给每个参与者。 这引入了延迟，使用了大量的 CPU 资源，并且很难扩展和部署新的数据中心来满足增加的负载。 +* Zoom 选择了 AVC 上的 SVC（可伸缩视频编解码器）编解码器。 AVC 是一种协议，您在其中发送单个流，并且单个流具有比特率。 如果要发送多个比特率，则必须发送多个流。 如果要发送多个比特率，这会增加带宽利用率。 +* SVC 是具有多个层的单个流。 这样就可以发送 1.2 mbs 的流，该流具有您可能需要缩小到给定网络条件的所有分辨率和比特率。 过去，您只能使用 ASIC 进行 SVC。 现在，由于摩尔定律，SVC 可以用软件完成。 +* Zoom 创建了多媒体路由，以解决传统供应商在 AVC 中遇到的问题。 消除转码摆脱了等待时间并增加了规模。 +* 多媒体路由会将用户内容带入他们的云中，当您作为客户端遇到问题时，他们会将另一个视频流切换给您。 如果您需要其他分辨率，则可以订阅该人分辨率的另一层。 +* 缩放不会转码或混合任何内容或形成任何视图。 从字面上看，您实际上是从零处理的路由中直接提取多个人的多个流。 这就是为什么您会看到如此出色的用户切换和语音切换体验以及低延迟的原因。 +* Zoom 开发了在云和客户端之间工作的应用程序层 QoS（服务质量）。 它的工作是检测网络状况。 收集的遥测数据确定将哪个流切换到客户端。 该算法查看 CPU，抖动，数据包丢失等情况。 +* 客户与云对话。 云知道何时不返回某些数据包，因此它将做出决定并将另一种流切换到您。 +* 如果网络环境不好，客户端可以自动缩小您自己的发送视频的大小，因此您不会浪费自己的下行带宽。 +* 客户端和云协同工作，以在正确的网络上交付正确的音频流，正确的视频流，因此用户体验达到最佳状态。 +* 具备网络意识意味着首先尝试最佳体验，即 UDP。 如果 UDP 不起作用，则尝试 HTTPS。 如果 HTTPS 不起作用，则会退回到 HTTP。 客户进行协商。 遥测表明为什么连接不良。 您能做的最糟糕的事情就是给用户带来不一致的体验。 +* 重点是使所有事情都尽可能简单直观地工作。 强调并重复了这一点，这可以解释一些较早的设计决策。 +* 在这一点上，讨论朝着更加注重市场的方向发展。 +* Zoom 通过 40 分钟的视频和聊天会议打乱了市场。 他们增加了免费的电话拨入式会议。 他们提供了市场上最好的 VOIP 体验。 竞争对手的平均 VOIP 采纳率不到 30％，缩放比例为 89％。 每年在音频会议上花费 30 亿美元，而 Zoom 免费提供它。 提供基于软件的视频会议室体验。 为竞争对手提供了一键式推送。 放弃数字标牌和房间展示。 +* Zoom 的竞争对手陷入了无法摆脱的收入模式。 不能创新，因为它们会破坏自己的收入模式。 +* Zoom 破坏了会议市场，音频市场，房间市场，现在他们想破坏电话。 尽管这是 2019 年，但随着大流行，该策略可能正在重新考虑。 +* Zooms 的目标是创建最大的互联协作网络。 他们希望兑现 20 年前 VOIP 的承诺，拆除人们相互协作的所有费用壁垒，推出 PSTN 连接性，通过聊天会议电话通过 IP 以任何网络上最低的速率连接所有人。 + +Zoom 如何满足如此巨大的带宽需求。 我不认为这是视频会议的中断，因为许多其他播放器已经以合理的成本结构提供了不错的视频内容，并且有些免费。 +让我们不要将破坏与谋杀行业混为一谈。 中断是有价值的东西，因为它的第一款产品具有某些技术优势，而该技术以前并未实现过，并且可以帮助用户降低此类服务的成本或通过一些广告收入流免费提供这种服务（尽管不会窃取数据）。 + +Zoom 并未中断，但得到了贪婪的投资者的支持，先杀死了其他视频会议公司，然后在杀死了所有其他小型竞争对手以与 bluejeans 或 google 见面之战后，慢慢开始赚钱。 \ No newline at end of file diff --git a/docs/218.md b/docs/218.md index 7006ab0..223ea6c 100644 --- a/docs/218.md +++ b/docs/218.md @@ -1,76 +1,97 @@ -# EVE 在线架构 +# TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件 -> 原文： [http://highscalability.com/blog/2008/10/22/eve-online-architecture.html](http://highscalability.com/blog/2008/10/22/eve-online-architecture.html) +> 原文： [http://highscalability.com/blog/2020/6/15/how-triplelift-built-an-adtech-data-pipeline-processing-bill.html](http://highscalability.com/blog/2020/6/15/how-triplelift-built-an-adtech-data-pipeline-processing-bill.html) -*抱歉，这篇文章的内容显然没有从旧的 HighScalability 网站过渡，这一切都弄糟了，但仍有一些有用的内容...* +![](img/1963d0fe5c064f572a5ce7f6a9647f17.png) -[EVE Online](http://www.eve-online.com/) 是“世界上最大的游戏宇宙”，这是 CCP 制作的大型多人在线游戏（ [MMO](http://en.wikipedia.org/wiki/MMO) ）。 对于 MMOG，EVE Online 的体系结构不常见，因为它不会将播放器负载分配给不同的服务器或分片。 而是，同一集群处理整个 EVE Universe。 将此与第二生命网格的[体系结构进行比较很有趣。 他们如何设法扩展规模？](http://highscalability.com/second-life-architecture-grid) +*这是 [TripleLift](https://triplelift.com/) 的数据工程师 [Eunice Do](https://www.linkedin.com/in/eunicedo/) 的来宾帖子，该公司领导下一代程序化广告。* -## 信息来源 +## 您的系统名称是什么，我们在哪里可以找到更多信息？ -* [EVE Insider Dev Blog](http://myeve.eve-online.com/devblog.asp) -* [EVE 在线常见问题解答](http://www.eve-online.com/faq/faq_07.asp) -* [大规模-Eve 演变：Eve Online 的服务器模型](http://www.massively.com/2008/09/28/eve-evolved-eve-onlines-server-model/)及其在 Slashdot 上的[讨论](http://games.slashdot.org/games/08/10/02/2137251.shtml) -* [EVE 在线论坛](http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229) -* [大型多人游戏开发 2](http://www.amazon.com/gp/product/1584503904?ie=UTF8&tag=innoblog-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1584503904) +该系统是 TripleLift 上的数据管道。 TripleLift 是一家广告技术公司，与该行业的大多数公司一样，我们每天都要处理大量数据。 在过去的三年中，TripleLift 数据管道的规模从每天处理数百万个事件扩展到处理数十亿个事件。 可以将这种处理总结为以经济高效的方式将报告数据连续聚合和传递给用户。 在本文中，我们将主要关注这一数十亿事件管道的当前状态。 -## 平台 +要跟踪到目前状态的 5 年历程，请查看[，这是我们的工程副总裁关于 TripleLift 管道](https://www.datacouncil.ai/talks/the-highs-and-lows-of-building-an-adtech-data-pipeline)的演变的演讲。 -* [用于服务器和客户端游戏逻辑的无堆栈 Python](http://www.stackless.com/) 。 它使程序员可以享受基于线程的编程的好处，而不会出现与常规线程相关的性能和复杂性问题。 -* SQL 服务器 -* 具有 [SSD](http://en.wikipedia.org/wiki/Solid-state_drive) 的刀片服务器，可实现高 IOPS -* 计划将 [Infiniband](http://en.wikipedia.org/wiki/Infiniband) 互连用于低延迟网络 -* 成立于 1997 年 -* 约 30 万活跃用户 -* 多达 40K 并发用户 -* 涉及数百艘船的战斗 -* 每天 2.5 亿笔交易 -* **代理刀片**-这些是 EVE 集群的面向公众的部分-它们负责建立玩家连接并在集群的其余部分内建立玩家通信。 -* **SOL 刀片**-这些是宁静的主力军。 集群分为 90-100 个 SOL 刀片，每个刀片运行 2 个节点。 节点是在一个核心上运行的主要 CPU 密集型 EVE 服务器进程。 有一些 SOL 刀片专用于一个繁忙的太阳能系统，例如 Jita，Motsu 和 Saila。 -* **数据库群集**-这是 EVE Online 的持久层。 运行中的节点与数据库进行大量交互，当然，与游戏有关的所有事情都驻留在这里。 多亏了固态驱动器，数据库才能够满足 Tranquility 产生的巨大 I / O 负载。 +## 您为什么决定构建此系统？ -* 借助创新理念，MMO 游戏可以在同一场战斗中扩展至数百名玩家。 -* SSD 实际上将在某种程度上弥合内存与磁盘之间巨大的性能差距。 -* 低延迟的 Infiniband 网络互连将支持更大的集群。 +我们需要一个可以实现以下目的的系统： -### 得到教训 +* 随着数据量的快速增长而扩展 +* 以经济高效的方式汇总日志级别的数据 +* 拥有清晰，可管理的工作依赖链 +* 自动化幂等作业运行和重试 +* 在预期的 SLA 中将数据交付给 BI 和报告工具 +* 处理那些报表工具上的查询负载 -* 关于 EVE Online MMOG 的架构，有许多有趣的事实，例如使用 Stackless Python 和 SSD。 -* 查看信息源，以获取有关 EVE Online 游戏的开发和操作的详细见解。 +## 您的系统有多大？ 尝试感受一下系统的工作量。 -* 涉及 1000 多艘战舰的战斗 +大概系统统计-2020 年 4 月左右 -不，不，不超过一千次 如果您想为大多数参与其中的人提供可远程玩的体验，那么我们正在将 400 或 500 场战斗视为绝对最大的战斗。 以上所有内容均无法播放，并可能导致节点/游戏崩溃。 但是我不反对其他任何数字，总的来说，它们都是运行 Eve-O 宇宙的集群怪物。 +* 最大的事件日志每天接收 300 亿个事件 +* 5 个日常聚合作业，最大输出为 7.5 GB +* 每小时 25 个聚合作业，最大输出 2.5 GB +* 15 小时的工作将汇总数据导入 BI 工具 +* 基数最高的归一化聚合具有 75 个维度和 55 个指标 -我打电话给 BS-我们通常会在 60-100 次船战中使节点崩溃。 +## 您的输入/输出带宽使用量是多少？ -感谢您的反馈。 我已经更新了条目。 +数据管道汇总了我们 Kafka 集群收集的事件数据，其 I / O 约为 2.5GB / hr。 -他们最近进行了更新，并设法使系统能够容纳一千艘船，当然，这并不意味着可以进行如此大规模的战斗，而只是意味着我们要说的系统 吉塔，不会崩溃。 但是 400-500 场战役可能还没有我们曾经相信的那么遥远。 他们在 CCP 所做的大量更新，令我感到惊讶的是，定期进行此类战斗。 当然，我不会参加这些活动，因为我是一个胆小鬼，而我更喜欢将我的 HIC 放在一块。 +## 您的成长速度有多快？ -安全飞行。 +在过去的几年中，我们经历了偶然的，快速的同比增长。 从 2016 年到 2017 年，我们管道中处理的数据量增长了 4.75 倍。 然后是 2017 年至 2018 年的 2.5 倍。最后是 2018 年至 2019 年的 3.75 倍。这就是 **3 年后的近 50 倍**！ -是和不是 +## 您的系统架构如何？ -我是 Goonswarm 公司的首席执行官，并在大多数星期内与 1000 多名玩家一起参加战斗。 自从 CCP 启动“无栈 IO”并在服务器端升级到 64 位体系结构以来，我们注意到服务器产生的延迟有了明显的改善。 如果我们在某个节点承受压力之前 24 小时警告 CCP，他们将为我们加强该节点，并且在 99％的时间里战斗将是可玩的。 +在较高级别，我们的数据管道运行批处理，其流程包括： -您还将注意到，无需等待 10 分钟即可加载网格，就可以取消 jita 的对接，而几个月前情况并非如此。 +1. 原始事件收集和持久性 +2. 通过多个聚合级别对数据进行非规范化和规范化 +3. 将聚合数据持久性或摄取到各种数据存储中 +4. 在用户界面和报告工具中展示提取的数据以进行查询 -即使是最高端的图形卡/ CPU 组合也将难以在屏幕上显示和跟踪成千上万的单个对象（船舶，导弹，沉船，太空舱，战斗机&无人机），因此，如今的大型战斗通常都依赖于 您的 PC 而不是服务器响应能力。 +我们从数据收集过程开始，在该过程中，将原始事件数据发布到我们的 50 多个 **Kafka** 主题中。 这些事件由 **Secor** （由 Pinterest 创建的开源使用者）使用，并以实木复合地板格式写到 **AWS S3** 。 -我可以看到服务器体系结构如何应用于第一人称游戏，但是设计上的挑战使正确设置变得异常困难。 这不仅仅是公司从 CCP 购买设计或引擎的问题，对于第一人称视角的游戏，还需要彻底消除和重新设计。 不幸的是，游戏行业的主要投资者似乎不愿意冒险冒险冒险，但是如果有人管理它，那将是一场噩梦。 +我们使用 **Apache Airflow** 来促进步骤 2 和 3 中必需的调度和依赖关系管理。 -[http://www.mustuniversity.com/Schools-Majors/Applied-Arts/Architecture.html“](在线架构学位 +Airflow 通过向 Databricks API 的作业提交请求启动聚合任务。 聚合使用 **Databricks** 群集上的 **Apache Spark** 运行。 首先，通过加入大量原始事件日志将数据归一化为宽表，以完整描绘广告位的拍卖前，拍卖中和拍卖后的情况。 非规范化日志将保留到 S3。 -即使是最高端的图形卡/ CPU 组合也将难以在屏幕上显示和跟踪成千上万的单个对象（船舶，导弹，沉船，太空舱，战斗机&无人机），因此，如今的大型战斗通常依赖于 您的 PC 而不是服务器响应能力。 [http://www.carrentaladvice.net/“](租车 +在非标准化任务进入成功状态之后，Airflow 调度程序将启动其下游标准化任务。 这些聚合中的每一个都会将非规范化数据汇总到更窄范围的维度和指标集中，以适合特定报表的业务环境。 这些最终聚合也将保留到 S3。 -我认为，超过 500 艘船的一切都不过分。 我对当前的限制非常满意，因为无论如何我都会避免出现大规模的污垢。 +成功完成每个最终聚合任务后，Airflow 调度程序将启动其各种下游持久性或摄取任务。 其中一项任务是将汇总数据复制到 **Snowflake** 中，该数据分析平台用作我们的商业智能工具的后端。 另一个任务将数据提取到 **Imply Druid** 中，这是一种托管的云解决方案，由时间优化的列式数据存储组成，支持对大型数据集的即席分析查询。 -戴夫 [http://www.pilkingtonselfcleaningglass.co.uk/where-to-use/glass-doors/index.html](玻璃门 +最后，第 4 步是我们的商业智能和数据工程团队之间的共同努力。 可以查询聚合数据的主要地方是我们的内部报告 API， **Looker** （由 Snowflake 支持）和 **Imply Pivot** （拖放分析 UI 捆绑在 Imply 中 德鲁伊解决方案）。 -如果我们在某个节点承受压力之前 24 小时警告 CCP，他们将为我们加强该节点，并且在 99％的时间里战斗将是可玩的。 [http://www.livescores.com.sg/“](实时比分 +## 您学到了什么？ -Python 非常慢……它是最慢的语言之一。 它可能比 C ++慢 10 倍。 一些用 python 编写的高级科学库实际上是在数学库的后台使用 C ++，但我无法想象在这种情况下。 作为一个业余爱好者的开发人员，我仍然不明白为什么 python 可以用于如此大的任务，特别是因为与更传统的语言相比，编码（IMO）看起来像地狱。 -其次，虽然我没有完全了解此问题，但我想知道它们如何处理跨节点的持久性... +数据决策往往会产生深远的影响。 例如： -在我看来，如果不先从数据库中读取原始位置，您甚至根本无法进行基本的健全性检查。 您可以根据位置和上次输入来假设它们在单个帧中的位置，但是当它们在游戏中越过节点行时，它仍然被写入服务器机架中某个节点上的持久数据库中，而突然之间 在他们的新节点上重新同步。 他们甚至可能会反复跳越节点线，从而滥用这种与冷却时间不同步的方式。 在这种情况下，我假设每个区域都有某种加载屏幕，这可能会解决此问题。 不过，尽管如此，我还是希望有一种方法可以使它更顺畅，以便可以将其集成到比单独的太阳系更为紧密的游戏世界中。.我现在正在研究类似的东西。 如果它平滑地滑行，那么理论上您可以提高节点的分辨率，直到您可以一次处理 2000 个播放器为止，只需横向扩展即可，而不是每次都像 Jita 那样使用大型专用服务器，但是跨节点 通信会很疯狂，但我仍在设法解决这一问题，以避免数据库上出现 IO 问题 \ No newline at end of file +* 一旦定义了现有字段，就很难改变其衍生方式。 这是由于维护该字段的历史连续性的共同需要。 +* 如果多个聚合级别中的任何一个级别的错误都持续运行了一段时间，那么用不正确的数据回填该时间段可能会既耗时又昂贵。 +* 如果提供了不正确或不完整的数据以供查询，则不会告诉您该数据在何处结束。 + +## 您希望自己做些什么？ + +长期以来，我们对于可访问的数据范围或可访问的数据范围尚无明确的方法。 + +* 不存在保留策略，并且无限期地存储了许多数据。 +* 允许用户查询无限期存储的数据，这降低了其他所有人的查询性能。 +* 所有报告工具均支持所有类型的查询。 换句话说，我们无法正确识别内部报告与外部报告以及报告与分析用例。 由于我们缺乏使数据可访问性的纪律性，最终形成了数据。 例如，我们没有热对冷分层，高对低粒度报告数据或合理的数据保留策略。 + +此后，我们对方法进行了更多思考，并采取了一些措施，例如实施 AWS S3 生命周期规则，为每个可查询数据源定义保留策略，以及指定报告工具以处理快速的调查性查询或较长日期范围内的大型报告，但 都。 + +## 您如何考虑将来更改架构？ + +我们计划通过使用 **Kafka Streams** 构建实时流式应用程序来补充批处理管道。 这是从涉及 **Spark 结构化流**， **Kafka 流**和 **KSQL** 的一些概念证明中选择的。 + +## 您如何绘制网络和服务器统计数据及趋势图？ + +我们使用 **Prometheus** 存储应用程序指标。 然后，我们在 **Grafana 仪表板**中汇总指标，并在这些仪表板上设置警报。 + +## 您的团队中有多少人？ + +团队中共有 **4 位数据工程师**，而我们约占整个工程组织的十分之一。 我们经常与之合作的团队是基础架构，解决方案和数据科学。 例如，我们最近通过 Airflow 加入了数据科学团队，并且他们的模型运行现在是自动化的。 + +## 您使用哪种语言来开发系统？ + +**用于气流的 Python** ，用于聚合的 Spark Scala 和用于某些报告工具的 Java。 \ No newline at end of file diff --git a/docs/219.md b/docs/219.md index 87781bf..5849748 100644 --- a/docs/219.md +++ b/docs/219.md @@ -1,7 +1,29 @@ -# Flickr 的联合会：每天进行数十亿次查询 +# Tinder：最大的推荐引擎之一如何决定您接下来会看到谁？ -> 原文： [http://highscalability.com/blog/2008/7/9/federation-at-flickr-doing-billions-of-queries-per-day.html](http://highscalability.com/blog/2008/7/9/federation-at-flickr-doing-billions-of-queries-per-day.html) +> 原文： [http://highscalability.com/blog/2016/1/27/tinder-how-does-one-of-the-largest-recommendation-engines-de.html](http://highscalability.com/blog/2016/1/27/tinder-how-does-one-of-the-largest-recommendation-engines-de.html) -Flickr 独行的数据库专家 Dathan Pattishall 出色地介绍了 Flickr 如何扩展后端以处理巨大负载。 一些信息可以在 [Flickr Architecture](http://highscalability.com/flickr-architecture) 中找到，但是该论文非常好，值得再次阅读。 如果您想查看正确完成的分片，请看一看。 +![](img/2688e3c8765d8fadc182017986ce3866.png) -优秀的阅读！ \ No newline at end of file +我们已经听到很多关于电影的 Netflix [推荐算法](http://www.wired.com/2013/08/qq_netflix-algorithm/)，[亚马逊](https://www.cs.umd.edu/~samir/498/Amazon-Recommendations.pdf)如何与您匹配的东西，以及 Google 臭名昭著的 [PageRank](https://en.wikipedia.org/wiki/PageRank) 的信息。 Tinder 呢？ 事实证明，Tinder 具有令人惊讶的深思熟虑的推荐系统来匹配人员。 + +[（刷卡）先生，对吗？](https://story.californiasunday.com/sean-rad-tinder) ，在 Tinder 创始人 Sean Rad 上： + +> 根据 Badeen 所说，用户的目标是让他们忘记三秒钟之内被刷过的人。 但是 Tinder 没有。 他们研究成员滑动的对象，匹配对象。 然后他们看“重新激活”。 年轻的用户将消失几周，然后“重新激活”，或再次开始刷卡。 年长的用户花更多的时间查看各个个人资料，并且很可能在重新激活之前消失了几个月。 古尔德说，平均活跃用户每天在 Tinder 上花费一个小时。 （拉德说他上瘾了，花了无数小时来刷卡。） + +> 邻里模式往往是独特的。 即使是城市中不同街区的人，也会有不同的举止或匹配的可能性。 古尔德说：“人们自然在地理上对自己进行分类。” 如果人们旅行，他们的行为也会发生巨大变化。 **“我们了解了一个人的全部知识，”古尔德说，“然后他们去了另一个地方，采取了完全不同的行动**。 古尔德（Goul）负责调整算法，该古尔德的头发偏斜一些，衣服比 Rad 和 Badeen 的宽松一些。 也就是说，比赛不是偶然发生的。 Tinder 正在安排您接下来要看的人。 **拥有数十亿个匹配项，因此拥有大量数据**。 Rad 说：“我们可能是世界上最大的推荐引擎之一。” + +> **首先，古尔德告诉我，该应用程序的统治类别为“匹配的 1％，**”，这些人获得了大量的比赛，并且使其他所有人看起来都比较糟糕。 Tinder 决定**改变趋势，减少显示**的配置文件，特别是向不在 1％范围内的用户展示。 现在，显示出很多向右滑动（是）的人逐渐减少的人，而得到了很多向左滑动（否）的人逐渐表明的人越来越多。 “我称之为累进税制-重新分配比赛。 他们并不是真正要重新分配的人，但我们会尽力而为。”古尔德说。 “这样做是正确的。” **该公司将其称为“智能匹配”：通过平衡游戏环境并确保不太可能获得匹配的成员获得一些东西，从而在约会世界中赢得正义。** “人类状况的一部分是斗争。 如果您除了“维多利亚的秘密（Victoria's Secret）”模特外什么都看不到，那就不一定要脱颖而出。” “当我们介绍不适合您的人时，就会着重强调那些人。 比赛不是偶然发生的。 Tinder 正在安排您接下来要看的人。 + +> **他们还更改了不良演员的系统，限制了每天刷卡的次数**。 古尔德说：“我们以前有一群人会向每个人正确滑动，然后不回应，所以我们增加了一个限制，以发现未玩游戏的人。” “我很惊讶，但是人们实际上很聪明。 他们发挥自己的才能。 在最初的几天里，这些家伙不断达到极限。 然后，在那之后，他们开始适应。 一旦完成，对话时间就会更长。 + +> **Gould 和 Badeen 将这些干预视为道德义务**。 Badeen 说：“知道它会对人们产生多大的影响，这很令人恐惧。” “我尝试忽略其中的一些，否则我会发疯。 我们正处于对世界负有社会责任的地步，因为我们具有影响世界的能力。 + +> Gould 回应了这一观点：“听着，建筑师设计的建筑物设定了人们的生活方式。 城市规划人员设置城镇和道路。 作为帮助人们约会的系统的设计者，我们有责任建立这些背景-我们每年都要为这个星球上相当比例的婚姻负责。 这是一种荣誉和责任。 + +[关于 HackerNews](https://news.ycombinator.com/item?id=10981314) + +它与高可扩展性有何关系？ + +我当然喜欢技术细节，但是我发现这些与政策相关的见解也很重要。 它比我预期的要更加周到和复杂，并且有趣地使用大数据来朝着目标导向的方向推动产品的使用。 + +因此，他们有社会责任限制每天比赛的次数，但是如果您为服务付费，您仍然可以做到吗？ 他们的道德晴雨表似乎有问题。 \ No newline at end of file diff --git a/docs/22.md b/docs/22.md index a8b2667..8b25cc8 100644 --- a/docs/22.md +++ b/docs/22.md @@ -1,129 +1,173 @@ -# 我们如何在 Mail.Ru Cloud 中实现视频播放器 +# Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据 -> 原文： [http://highscalability.com/blog/2016/3/28/how-we-implemented-the-video-player-in-mailru-cloud.html](http://highscalability.com/blog/2016/3/28/how-we-implemented-the-video-player-in-mailru-cloud.html) +> 原文： [http://highscalability.com/blog/2008/1/30/how-rackspace-now-uses-mapreduce-and-hadoop-to-query-terabyt.html](http://highscalability.com/blog/2008/1/30/how-rackspace-now-uses-mapreduce-and-hadoop-to-query-terabyt.html) -![](img/4dc85258b3e084ceb6d7575e6f63baf6.png) +您如何每天查询来自 600 多个活动服务器的数百 GB 新数据？ 如果您认为这听起来像是 [MapReduce 与数据库大战](http://highscalability.com/database-people-hating-mapreduce)激烈对峙的完美战场，那么您是正确的。 Mailtrust（Rackspace 的邮件部门）的首席技术官 Bill Boebel 慷慨地提供了一个有趣的说明，说明他们如何将其日志处理系统从存储在每种计算机方法中的早期变形虫文本文件发展到尼安德特人关系 最终无法与之抗衡的数据库解决方案，最后成为基于 Homo sapienic Hadoop 的解决方案，该解决方案对他们来说是明智的选择，并且具有无限的可扩展性潜力。 -我们最近在 [Mail.Ru Cloud](https://cloud.mail.ru/) 中添加了视频流服务。 开发工作首先考虑将新功能用作通用的“瑞士军刀”，它将播放任何格式的文件并可以在具有可用云的任何设备上工作。 上传到云端的视频内容大体上属于两类之一：“电影/系列”和“用户视频”。 后者是用户使用手机和相机拍摄的视频，这些视频在格式和编解码器方面用途最为广泛。 由于许多原因，在没有事先进行标准化的情况下在其他最终用户设备上观看这些视频通常是一个问题：缺少所需的编解码器，或者文件太大而无法下载，等等。 +Rackspace 面临一个现在熟悉的问题。 大量数据流进来。您将所有这些数据存储在哪里？ 您如何使用它呢？ 在他们的系统的第一个版本中，日志存储在纯文本文件中，并且必须由登录到每台机器上的工程师手动搜索。 然后是相同过程的脚本版本。 下一个重大发展是单机 MySQL 版本。 由于大量的数据洪泛导致大量索引混乱，因此插入很快成为瓶颈。 定期散装加载是解决此问题的方法，但分度指数的剪切大小使其减慢了速度。 然后根据时间将数据分为合并表，因此索引更新不是问题。 随着越来越多的数据，此解决方案由于负载和操作问题而崩溃。 -在本文中，我将详细解释如何在 Mail.Ru Cloud 中播放视频，以及如何使 Cloud Player“杂食性”并确保最大数量的最终用户设备上的支持 。 +面对指数级增长，他们花了大约 3 个月的时间使用 Hadoop（Google 文件系统和 MapReduce 的开源实现），Lucene 和 Solr 构建新的日志处理系统。 迁移到已分区的 MySQL 数据集是一种选择，但他们认为，这样做只会花费时间，并且将来无论如何都需要创建更具可扩展性的解决方案。 未来是今年年初。 -## 存储和缓存：两种方法 +他们的新系统的优势在于，他们现在可以按照自己想要的任何方式查看其数据： -上传后，许多服务（例如 YouTube，社交网络等）会将用户的视频转换为适当的格式。 视频只有在转换后才能播放。 Mail.Ru Cloud 中使用了另一种方法：**原始文件在播放时会进行转换**。 与某些专门的视频托管网站不同，我们无法更改原始文件。 我们为什么选择此选项？ Mail.Ru Cloud 主要是一种云存储，如果用户在下载文件时发现文件质量下降或文件大小发生了一些变化，他们将感到非常惊讶。 另一方面，我们无法承受**存储所有文件的预先转换后的副本：这将需要太多空间**。 我们还必须做很多额外的工作，因为某些存储的文件将永远不会被监视，甚至一次也不会被监视。 +* 每晚 MapReduce 作业收集有关其邮件系统的统计信息，例如按域，传输的字节数和登录数的垃圾邮件计数。* 当他们想知道客户从哪个世界登录时，便创建了一个快速的 MapReduce 作业，并在几个小时内得到了答案。 在典型的 ETL 系统中，实际上是不可能的。 -即时转换的另一个优点是：如果我们决定更改转换设置或例如添加其他功能，则无需重新转换旧视频（不一定总是如此） 可能，因为原始视频已经消失了）。 在这种情况下，一切都会自动应用。 + 此开关更改了他们经营业务的方式。 Stu Hood 很好地总结了这种影响：“现在，只要我们想到有关客户使用模式的复杂问题，我们都可以通过 MapReduce 在数小时内从日志中获取答案。这是强大的功能。” -## 这个怎么运作 + 在本文的其余部分中，Bill 描述了其系统的演变以及促使其从关系数据库解决方案迁移到 MapReduce 系统的力量。 -我们正在使用 Apple 创建的 HLS（HTTP 实时流）格式[进行在线视频流。 HLS 的思想是将每个视频文件都切成小片段（称为“媒体片段文件”），这些片段被添加到播放列表中，并为每个片段指定名称和时间（以秒为单位）。 例如，将一个两小时的电影切成十秒钟的片段，作为一系列 720 个媒体片段文件。 根据用户希望从哪一刻开始观看视频，播放器会从传输的播放列表中请求适当的片段。 **HLS** 的好处之一是**用户无需在播放器读取文件头的同时等待视频开始播放**（等待时间可能会非常长 如果是完整版电影且移动互联网速度较慢）。](https://developer.apple.com/streaming/) + 在开始之前，我真的要感谢 Bill Boebel 花了很多时间和精力来创建这份非常有价值的体验报告。 -这种格式提供的另一个重要可能性是**自适应流**，它允许根据用户的 Internet 速度即时更改质量。 例如，您开始使用 3G 以 360p 观看，但是火车进入 LTE 区域后，您将继续以 720p 或 1080p 观看。 它在 HLS 中非常简单地实现：播放器会获得“主播放列表”，其中包括针对不同带宽的备用播放列表。 加载片段后，播放器会评估当前速度，并据此决定下一个片段的质量：相同，较低或较高。 我们目前支持 240p，360p，480p，720p 和 1080p。 + ## 信息来源 -## 后端 + * [Rackspace 上的 MapReduce](http://blog.racklabs.com/?p=66)* Mailtrust（Rackspace 的邮件部门）的首席技术官 Bill Boebel 发送给我的文档。 这篇文章与通常的内容有所不同，因为到目前为止，大多数内容都是由 Bill 撰写的，我对它的组织方式也有所不同。 -， + ## 该平台 -[![](img/879db0a8b28049344985b588f867cedc.png) ](https://habrastorage.org/files/1c6/c3e/67d/1c6c3e67dd6c4b0bbe4c2595aeffd099.png) + * Hadoop 的* Hadoop 分布式文件系统（HDFS）* Lucene* 索尔* Tomcat -Mail.Ru 云服务由**三组服务器**组成。 第一组是**应用服务器**，它接受视频流请求：它创建 HLS 播放列表并将其发送回去，分发转换后的片段并设置转换任务。 第二组是具有嵌入式逻辑的**数据库（ [Tarantool](http://tarantool.org/) ），用于存储视频信息并管理转换队列。 第三组**转换器**从 Tarantool 中的队列接收任务，然后将任务完成情况再次记录在数据库中。 收到视频文件片段的请求后，我们首先在我们的一台服务器上检查数据库，以获取转换后的质量要求的即用型片段。 这里有两种情况。** + ## 统计资料 -第一种情况：我们确实有一个转换后的片段。 在这种情况下，我们会立即将其寄回。 如果您或其他人最近提出了要求，则该片段将已经存在。 这是第一个缓存级别，适用于所有转换的文件。 值得一提的是，我们还使用了另一种缓存级别，其中经常请求的文件分布在多个服务器上，以避免网络接口过载。 + * Rackspace 拥有超过 5 万个设备和 7 个数据中心。* 邮件系统和日志记录服务器当前位于 3 个 Rackspace 数据中心中。* 该系统在 Solr 中存储了 8 亿多个对象（一个对象=用户事件，例如接收电子邮件或登录 IMAP），在 Hadoop 中存储了 96 亿个对象，相当于 6.3 TB 压缩。* 每天会生成数百 GB 的电子邮件日志数据。 -第二种情况：我们没有转换后的片段。 在这种情况下，将在数据库中创建一个转换任务，我们等待它完成。 正如我们前面所说，它是 Tarantool（一个非常快速的开源 NoSQL 数据库，可让您在 Lua 中编写存储过程），它负责存储视频信息和管理转换队列。 应用程序服务器和数据库之间的通信如下进行。 应用服务器发出一个请求：“我需要 720p 质量的 movie.mp4 文件的第二个片段； 准备等待的时间不超过 4 秒钟”，并且在 4 秒钟之内它将收到有关从何处获取片段的信息或错误消息。 因此，数据库客户端对立即执行任务或通过一系列复杂操作不感兴趣如何执行任务：它使用非常简单的界面，可以发送请求并接收请求的内容。 + ## Mailtrust 的背景 -我们提供数据库容错能力的方法是**主副本故障转移**。 数据库客户端仅将请求发送到主服务器。 如果当前的主服务器有问题，我们会将其中一个副本标记为主服务器，然后将客户端重定向到新的主服务器。 当客户端继续与主机交互时，这样的主副本切换对客户端是透明的。 + * 电子邮件托管公司* 成立于 1999 年，于 2007 年与 Rackspace 合并，以前的名称为：Webmail.us* 80K 商业客户，700K 邮箱。* 2 个托管邮件产品：值得注意的，MS Exchange* 值得一提的系统： + *自产，基于 Linux，POP3，IMAP，网络邮件，RSS 提要，共享日历，Outlook 同步，Blackberry 同步。 + *约 600 台服务器和商用硬件，旨在解决常见故障。* MS Exchange 系统： + * MAPI，POP，IMAP，OWA，Blackberry，Goodmail，ActiveSync。 + *约 100 台服务器，高端硬件，SAN & DAS 存储。 -除了应用程序服务器之外，还有谁可以充当数据库客户端？ 可能是那些准备开始转换片段的转换器服务器，现在需要到源视频文件的参数化 HTTP 链接。 这种转换器和 Tarantool 之间的通信类似于上述应用服务器的接口。 转换程序发出一个请求：“给我一个任务，我准备等待 10 秒钟”，如果任务在这 10 秒钟内出现，则会将其分配给一个正在等待的转换程序。 我们在 Tarantool 内部的 Lua 中使用了 IPC 通道，以轻松实现客户端到转换器的任务转发。 通道允许不同请求之间的通信。 这是一些用于转换片段的简化代码： + ## 架构 -``` -function get_part(file_hash, part_number, quality, timeout) - -- Trying to select the requested fragment - local t = v.fragments_space.index.main:select(file_hash, part_number, quality) + 当前基于 Hadoop 的系统的工作方式是：* 原始日志从数百个邮件服务器实时传输到 Hadoop 分布式文件系统（“ HDFS”）。* 计划运行 MapReduce 作业以使用 Apache Lucene 和 Solr 索引新数据。* 一旦建立索引，它们将被压缩并存储在 HDFS 中。* 每个 Hadoop 数据节点都运行一个 Tomcat servlet 容器，该容器承载许多 Solr 实例，这些实例拉并合并新索引，并向我们的支持团队提供真正快速的搜索结果。 - -- If it exists — returning immediately - if t ~= nil then - return t - end + ## 系统替代 - -- Creating a key to identify the requested fragment, and an ipc channel, then writing it - -- in a table in order to receive a “task completed” notification later - local table_key = msgpack.encode{file_hash, part_number, quality} - local ch = fiber.channel(1) - v.ctable[table_key] = ch + ### 问题 - -- Creating a record about the fragment with the status “want to be converted” - v.fragments_space:insert(file_hash, part_number, quality, STATUS_QUEUED) + Mailtrust 是一家非常注重客户服务的公司。 对于我们的支持技术人员而言，能够检查邮件日志以对我们的客户进行故障排除非常重要。 我们的支持技术人员每天需要搜索日志数百次，因此提供此功能的工具必须快速准确。 每天有 600 多个邮件服务器和数百 GB 的原始日志数据产生，因此管理起来很棘手。 这是 Mailtrust 日志记录体系结构的简要历史，我们面临的问题，如何克服它们以及当今系统的外观... - -- If we have idle workers, let’s notify them about the new task - if s.waitch:has_readers() then - s.waitch:put(true, 0) - end + ### 记录 v1.0 - -- Waiting for task completion for no more than “timeout” seconds - local body = ch:get(timeout) + 日志以纯文本格式存储 每个邮件服务器的本地磁盘上的文件，并保留了 14 天。 我们的支持技术人员没有对服务器的登录访问权限，因此，要搜索日志，他们将必须向我们的工程师升级。 然后，工程师将不得不进入每个邮件服务器并使用 grep / var / log / maillog。 - if body ~= nil then - if body == false then - -- Couldn’t complete the task — return error - return box.tuple.new{RET_ERROR} - else - -- Task completed, selecting and returning the result - return v.fragments_space.index.main:select{file_hash, part_number, quality} - end - else - -- Timeout error is returned - return box.tuple.new{RET_ERROR} - end -end + 问题：一旦我们在十几台服务器上发展了很多，这种手动登录每个服务器的过程对于我们的工程师来说就变得很耗时。 -local table_key = msgpack.encode{file_hash, part_number, quality} -v.ctable[table_key]:put(true, 0) -``` + ### 记录 v1.1 -实际的代码稍微复杂一点：例如，它考虑了在请求时片段处于“正在转换”状态的场景。 由于采用了这种方案，转换器可以立即收到新任务的通知，而客户端也可以立即收到任务的完成的通知。 这非常重要，因为用户看到视频加载微调器的时间越长，他们甚至有可能在视频开始播放之前就离开页面。 + 通过编写脚本来加快搜索过程，该脚本将通过从集中式服务器运行的一个命令来搜索多个服务器。 工程师可以告诉脚本要搜索的邮件服务器类型（入站 smtp，出站 smtp，后端邮箱）。 该脚本将在/ etc / hosts 中查找该类型的服务器列表，然后遍历每个服务器，执行 ssh，执行 grep，然后输出结果。 该脚本过去也可以通过“ gunzip -c /var/log/maillog.* | grep”进行搜索。 -如下图所示，大多数转化以及因此等待时间都不会超过几秒钟。 + 问题：支持技术人员仍必须向工程师升级故障单才能执行搜索 。 随着客户和服务器数量的增加，这开始占用了我们工程师的稀缺时间。 另外，在活动服务器上存储和搜索日志会对服务器的性能产生负面影响。 更糟的是，工程团队不断壮大，我们开始遇到问题，两名工程师将同时执行搜索，这实际上使事情变慢了。 -![](img/9aa2115022459dd03949867463346deb.png) + ### 记录 v2.0 -## 转换次数 + 我们发布了一个日志搜索工具，支持技术人员可以直接使用它，而无需工程师参与。 支持团队使用了基于 Web 的工具，可以在其中搜索日志。 它允许按发件人或收件人的电子邮件地址，域名或 IP 地址进行搜索。 所有这些都是 MySQL 数据库中的索引字段。 不允许使用通配符文本搜索（即 MySQL“ LIKE”语句），因为数据集非常大，而且这些查询的速度非常慢。 每天的日志都存储在一个单独的表中，因此我们可以通过简单地删除并重新创建 MySQL 表来清除旧数据。 与在大表上运行条件 DELETE 命令相比，这确实使清除工作非常快。 日志数据仅保留了 3 天，以使 MySQL 数据库减小到合理的大小。 -对于**转换**，我们使用的是根据需要进行修改的 **FFmpeg** 。 我们最初的计划是使用 FFmpeg 内置工具进行 HLS 转换。 但是，我们的用例遇到了问题。 如果您要求 FFmpeg 将 20 秒的文件转换为带有 10 秒的片段的 HLS，则会得到两个文件和一个播放列表，它们可以毫无问题地播放。 但是，如果您要求先转换 0 至 10 秒，然后再转换 10 至 20 秒（启动 FFmpeg 转换器的另一个实例），则从一个文件转换到另一个文件时（大约在 10 秒），您会听到明显的喀哒声。 我们花了几天时间尝试不同的 FFmpeg 设置，但没有成功。 因此，我们必须进入 FFmpeg 并编写一个小补丁。 它需要一个命令行参数来解决“ click”错误，该错误源于对音频和视频轨道进行编码的细微差别。 + 为了使日志进入数据库，每个邮件服务器最初将其日志数据写入本地 16MB tempfs 分区。 每 60 秒钟通过 cron 调用一次 Logrotate 来旋转临时日志文件，然后在将数据发送到集中式日志服务器之前对其进行预处理。 此预处理步骤减少了必须通过网络传输到日志服务器的数据量，并且这也分散了处理工作量，以避免在日志服务器上造成瓶颈。 在本地处理数据之后，脚本会将逗号分隔的日志数据发送回本地服务器上的 syslog-ng，然后 syslog-ng 会通过网络将其发送到集中式日志服务器。 日志服务器配置为在 6 个不同的端口上接收数据，每种类型的日志数据都接收一个端口...入站 smtp，出站 smtp，后端 smtp，垃圾邮件/病毒过滤，POP3 和 IMAP。 接收到日志数据后，将通过 MySQL INSERT 命令将记录一一插入到数据库中。 -此外，我们还使用了当时尚未包含在 FFmpeg 上游的其他一些可用补丁。 例如，一个[补丁](https://trac.ffmpeg.org/ticket/2513)，用于解决 MOV 文件转换缓慢的已知问题（iPhone 制作的视频）。 一个名为“ Aurora” 的**守护程序控制从数据库获取任务并启动 FFmpeg 的过程。 “ Aurora”守护程序以及位于数据库另一端的守护程序都是用 Perl 编写的，并且与 EV 事件循环和各种有用的模块异步工作，例如： [EV-Tarantool](https://github.com/Mons/EV-Tarantool) 和 [Async :: Chain](https://metacpan.org/pod/Async::Chain) 。** + 问题：我们很快意识到，MySQL 插入存在瓶颈。 随着表的增长，对每个条目的索引在插入时变慢。 在测试的最初几个小时内，插入开始变慢，无法跟上接收数据的速度。 记录系统的 2.0 版从未在生产中使用过。 -有趣的是，**在 Mail.Ru Cloud 中没有为新的视频流服务**安装额外的服务器：转换（需要大量资源的部分）在特别隔离的环境中在我们的存储上运行。 日志和图表显示，我们的能力所能承受的负载是我们现在所承受的能力的几倍。 仅供参考：自我们的视频流媒体服务于 2015 年 6 月启动以来，已请求超过 **500 万个独特视频； 每分钟观看 500–600 个唯一文件**。 + ### 记录 v2.1 -## 前端 + 通过对集中式日志服务器上本地文本文件中的日志条目进行排队并定期将其批量加载到数据库中，解决了 MySQL INSERT 瓶颈。 由于 syslog-ng 在其 6 个端口上接收到日志，因此数据将流式传输到 6 个单独的文本文件中。 每隔 10 分钟，脚本将轮换这些文本文件并执行 MySQL LOAD，以将数据加载到数据库中。 这比一次插入一个记录的日志数据快得多。 -如今，几乎每个人都拥有智能手机。 或两个。 为您的朋友和家人制作简短的视频没什么大不了的。 这就是为什么我们准备好有人将视频从手机或平板电脑上传到 Mail.Ru Cloud 并立即从其设备中删除视频以释放空间的情况。 如果用户想向他人展示此视频，则只需使用 Mail.Ru Cloud 应用程序将其打开，或在其桌面上的 Cloud Web 版本中启动播放器。 现在可以不在手机上存储所有视频片段，同时始终可以在任何设备上访问它们。 移动互联网上的流式传输比特率降低了，因此，以兆字节为单位的大小也降低了。 + 问题：随着数据库的增长，LOAD 的速度将逐渐变慢，这是因为随着插入的表变大，MySQL 索引性能会下降。 这个版本的速度足够快，可以发布到生产中，但是我们知道，如果不进行额外的工作，该系统就不会扩展太多。 -此外，在移动平台上播放视频时，我们使用 Android 和 iOS 本机库。 这就是为什么视频可以在移动浏览器中“开箱即用”的智能手机和平板电脑上播放的原因：我们不需要为使用的格式创建额外的播放器。 与网络版本相似，在台式计算机上，自适应流机制被激活，并且图像质量动态适应当前带宽。 + ### 记录 v2.2 -我们的播放器与竞争对手的播放器之间的主要区别之一是我们的视频播放器独立于用户的环境。 在大多数情况下，开发人员会创建两个不同的播放器：一个是带有 Flash 界面的播放器，另一个是（对于具有本地 HLS 支持的浏览器，例如 Safari），一个是完全相同的，但是用 HTML5 实现，随后上传了适当的文件。 接口。 我们只有一名球员。 我们的目标是可以轻松更改界面。 因此，我们的播放器在视频和音频方面看起来非常相似-所有图标，布局等均以 HTML5 编写。 播放器不依赖于播放视频所使用的技术。 + 引入了合并表，以加快将日志数据加载到数据库中的速度。 在此版本中，脚本每 10 分钟会创建一个新的数据库表，然后将文本日志加载到空表中。 这使得 LOAD 命令非常快，因为没有现有的数据库索引可能会对性能产生负面影响。 加载数据后，脚本将修改一组合并表，这些合并表将所有 10 分钟的表合并在一起。 修改了 Web 搜索工具，以允许在以下时间范围内进行搜索：全天，过去 12 小时，过去 6 小时，过去 2 小时。 每个时间段都存在对应的合并表，并且在创建新表时每 10 分钟进行一次修改。 -我们使用 Flash 绘制视频，但是整个界面都基于 HTML； 因此，我们不会遇到版本同步问题，因为不需要支持特定的 Flash 版本。 一个开放源代码库足以播放 HLS。 我们编写了一个垫片，将 HTML5 视频元素界面转换为 Flash。 这就是为什么我们可以假设我们将始终使用 HTML5 来编写整个界面的原因。 如果浏览器不支持这种格式，我们只需将本机视频元素替换为我们自己的实现相同界面的元素。 + 问题：此版本的日志记录系统可靠运行了大约一年。 但是随着我们的支持团队，客户群和服务器数量的增加，我们开始遇到问题。 当我们到达大约 100 台服务器时，数据库 LOAD 操作将需要 2-3 分钟才能运行，这是可以接受的，但是服务器现在始终处于沉重的 cpu 和磁盘 IO 负载之下。 搜索的执行频率更高，并且变得越来越慢。 在尝试创建新表或修改合并表时，我们开始看到一些奇怪的问题，例如随机错误。 这些错误逐渐变得更加频繁，导致丢失日志数据。 支持团队开始对系统的准确性失去信心。 -如果用户的设备不支持 Flash，则视频将以具有 HLS 支持的 HTML5 播放（到目前为止，仅在 Safari 中实现）。 使用本地工具在 Android 4.2+和 iOS 上播放 HLS。 如果没有支持且没有本机格式，我们将为用户提供文件下载。 + 此外​​，在很多情况下，我们的工程师对特定应用程序进行了软件升级，从而改变了日志格式，从而破坏了预处理脚本。 由于我们的原始日志每 60 秒就会从本地邮件服务器中删除一次，因此发生这种情况时，我们将无法恢复丢失的日志。 此外，日志搜索工具对于我们支持团队的日常运营变得越来越重要。 但是，日志系统没有冗余。 没有 RAID，没有备份，没有故障转移系统。 对于将日志系统扩展到单个整体服务器之外，我们也没有一个好的计划。 使用日志系统逐步修补问题和调整性能会占用大量时间，我们需要更好的东西。 我们需要一种新的解决方案，该解决方案必须快速，可靠并且可以随着我们的发展无限扩展。 我们需要真正可扩展的东西。 -## *** + ### 记录 v3.0 -如果您有实现视频播放器的经验，欢迎访问评论部分：我非常想知道如何将视频分成多个片段，如何在存储和缓存之间进行选择，以及面临的其他挑战。 总之，让我们分享我们的经验。 + 在设计 v3.0 时，我们研究了几种商业日志处理应用程序。 Splunk 脱颖而出，几乎完成了我们想要的一切； 但是，我们担心使用这样的供应商产品可能会限制我们在将来构建新功能的能力。 例如，我们想要构建一个工具，使我们的客户可以直接搜索其日志。 自 Apache Hadoop 项目成立以来，我们一直在关注它，其进展和方向给我们留下了深刻的印象。 Hadoop 是 Google File System 和 MapReduce ...的开源实现，该系统是专为大规模分布式数据处理而设计的。 它通过添加服务器并在服务器之间分配数据和 MapReduce 作业来横向扩展其工作负载。 其他公司已经在使用它进行自己的日志处理。 因此选择了 Hadoop。 在大约 3 个月的时间内，我们使用 Hadoop，Lucene 和 Solr 构建了全新的日志处理系统。 该系统的描述如下：http://blog.racklabs.com/?p=66 -[关于 HackerNews](https://news.ycombinator.com/item?id=11375147) + 我们相信随着我们公司的发展，这个新系统将能够与我们一起扩展。 Hadoop 项目背后有很多动力，这使我们对它的可扩展性将继续提高充满信心。 雅虎是该项目的主要贡献者之一，并已构建了包含数千台服务器的 Hadoop 集群，并且他们正积极努力使 Hadoop 支持数以万计的服务器。 -很棒的文章！ + 问题：迄今为止，我们发现的唯一问题是我们自己的错误。 我们会在找到它们后修复它们。 -很棒的文章。 您能告诉我们更多有关 ffmpeg 补丁以消除音频点击的信息吗？ + 今天我们正在积极运行 v3.0，但我们不会在这里停止。 我们有许多新功能的计划... -谢谢。 如此棒的文章。 + ### 未来 -因此，转换的视频（频繁和较少）在 ttl 之后会自动删除吗？ -其次，为什么转换器使用 http 协议从存储中获取视频？ 使用套接字不能更快完成吗？ + 目前正在对 3.1 版进行编码。 它包括支持 Microsoft Exchange 日志处理的新 MapReduce 作业。 （当前，我们仅使用此系统处理值得注意的日志）。 我们计划在三月上线。 -您启动了多少个 tarantool 实例？ TT 集群有多大？ + 在 4.0 版中，我们计划将日志搜索工具交到客户手中，以便他们可以拥有与支持团队相同的故障排除能力。 这很可能需要重新组织我们存储日志索引分片的方式，以便按用户对它们进行分组，而不是让 Solr 将它们随机分组。 我们的经销商对此感到很兴奋，因为它可以使他们更好地为客户提供支持。 谁知道 v4.0 之后会构建什么... -对于此特定任务，我们只有两个实例-主实例和副本实例。 我们知道，在 Mail.Ru Group 的在线广告系统上，生产中的 Tarantool 集群的最大规模约为 500 个实例。 + ## 相关文章 -For this specific task we only have two instances - a master and a replica. The maximum knows to us size of a Tarantool cluster at production is around 500 instances at the Mail.Ru Group's online ad system. \ No newline at end of file + * [Google 体系结构](http://highscalability.com/google-architecture)* [数据库人们讨厌 MapReduce](http://www.highscalability.com/database-people-hating-mapreduce)* [产品：Hadoop](http://www.highscalability.com/product-hadoop)* [在 Amazon EC2 和 Amazon S3 上运行 Hadoop MapReduce](http://www.highscalability.com/running-hadoop-mapreduce-amazon-ec2-and-amazon-s3)* [Solr](http://lucene.apache.org/solr/) + +非常令人印象深刻。 每天在日志文件中有数百演出？！？！？！ 哇，我只能说。 + +那么，是否有任何关系数据库可以使用少量机器来处理这种负载？ 还是对 RDBMS 无法处理的数据存在魔术限制？ + +致敬 Hadoop 人士！ + +[http://codershangout.com](http://codershangout.com) +编码人员可以进行视频群聊的地方！ + +“任何 RDBMS 都能做到这一点？” + +我会以任何合理的费用加价。 该文章缺少的是，这种 Hadoop 基础架构在 Rackspace 的构建和运行上花费了多少成本。 总拥有成本（TCO）是真正强大和改变游戏规则的主要因素。 + +然后要真正回答您的问题，我只是说，不。 + +我唯一知道的甚至可能是祷告，可能是 Vertica（ [http://www.vertica.com/）](http://www.vertica.com/))但是，Vertica 也不是真正的标准 RDBMS 不知道要花多少钱。 + +“这使拥有计算机集群的任何人都可以编写简单的代码来快速，可靠地对海量数据集执行任务”（摘自“ Rackspace 的 MapReduce”）。 + +-任何人 +-带有计算机集群 +-简单的代码（执行“迅速而可靠”） + +哇，这些正是这类 IT 工作/技能，永远不会外包给其他国家/地区。 + +感谢您杀死另一个高端利基市场。 这对于大公司/玩家总是很乐于助人（谷歌，ibm 等），而对那些愿意做完全一样的工作的外包公司也不错，因为它很容易标准化。 + +我们不需要你 我们得到了 Apache Foundation。 + +晚安。 + +如果您的工作安全依赖于您编写糟糕的，复杂的，整体的软件，那么您可能应该重新考虑自己的技能。 + +“绝不会外包给其他国家...” + +许多 Hadoop 提交者位于这些国家/地区。 克服你的偏见。 + +如果您假设如果无法使用 mySQL 和本地磁盘执行此操作，则无法使用数据库执行此操作，这是完全合乎逻辑的。 + +几年前，其他数据库已解决了上述数据库问题：分区表，可靠性，禁用索引（按分区）和启动星型模式。 + +我很好奇是否有任何工具可以帮助创建报告或进行临时查询。 很难想象有必要聘请专门的 map-reduce 开发人员编写自定义代码来回答业务问题。 + +杰瑞 + +[http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html“]( MapReduce：一些数据库专家向后退了一步。我不 知道的东西足以使我同意或不同意，但是我仍然认为这是非常有趣的食物。 + +越来越少的 kkep 每天都会出现，而较老的技术则很快消失 +----- +[http://underwaterseaplants.awardspace.com“](海洋植物 +[http://underwaterseaplants.awardspace.com/seagrapes.htm“](海葡萄... [http://underwaterseaplants.awardspace.com/plantroots.htm”](植物根 + +请参见 CloudBase- +[http://cloudbase.sourceforge.net']( eBay 的两个巨大的数据仓库。 有关 eBay 的两个数据仓库的详细信息。 +* 3 个主要数据中心，包括欧洲的 1 个（根据安全港规定） -eBay 主要 Teradata 数据仓库的指标包括： +* 200 多个 Tomcat 服务节点 -* 2 PB 以上的用户数据 +* 由 Tomcat / nginx 提供支持的 300 多个存储节点 -* 72 个节点 +* 100 多个 MySQL 节点 -eBay 的 Greenplum 数据仓库（或数据集市）的指标包括： +* 50 多个 Elasticsearch 节点 -* 6 1/2 PB 用户数据 +* 20 多个 HAProxy 节点 -* 17 万亿条记录 +* 和许多其他类型的服务节点 -* 每天有 1500 亿条新记录，这似乎表明摄取速率远远超过了 50 TB /天 +* 我们服务器和 GCS 中存储了数 PB 的数据 -* 96 个节点 +* 在 Elasticsearch 中建立索引的数 PB 数据内容 -与 Java 一起使用 MSXML 的优势如何？ \ No newline at end of file +* 许多桌面客户端将文件与云同步 + +## 认识您 + +### 您的系统名称是什么，我们在哪里可以找到更多信息？ + +Egnyte 是启动公司的名称，核心系统有很多主要部分，例如 CFS（云文件服务器），EOS（Egnyte 对象存储），事件同步和...。您可以在中找到更多有关这些的内容。 [对于技术人员](https://www.egnyte.com/blog/category/for-the-techies/) 部分，在我们的博客中。 + +### 您的系统是干什么的？ + +它推动了成千上万企业的同步和共享需求，并且云使它们的现有文件系统可以被 FTP，webdav，移动，公共 api，Web UI 和...等各种端点使用。 + +### 您为什么决定构建此系统？ + +在 2007 年，企业/员工队伍开始变得越来越分散，客户正在使用多个设备来访问相同的文件，并且有必要使这种体验尽可能的顺畅 + +### 您的项目经费如何？ + +这是一家自负盈亏的公司，后来我们在过去 8 年中进行了 5 轮募集，筹集了 6250 万美元[](https://www.crunchbase.com/organization/egnyte#/entity) + +### 您的收入模式是什么？ + +我们没有免费用户，但是我们提供 15 天免费试用，之后客户无需支付席位即可付费。 + +### 您如何销售产品？ + +我们从 SEM / SEO 开始，但随着时间的增长，我们通过许多渠道为企业客户争取了诸如社交媒体，Biz 开发，贸易展览，SEM，SEO，入站营销和高联系销售的客户。 + +### 您从事这项工作多久了？ + +它成立于 2007 年，目前已有 8 年的历史。 + +### 您的系统多大？ 尝试感受一下系统的工作量。 + +我们存储数十亿个文件和多个 PB 的数据。 根据 New Relic，我们平均每秒观察到超过 2K 的 api 请求。 由于安全港规定和位置相近，我们将数据存储在 3 个主要数据中心中。 有关更多信息，请参见统计信息部分。 + +### 您的输入/输出带宽使用量是多少？ + +我没有确切的数字，因为它一直在增长，但是客户上个月下载了接近 1 PB 的压缩/未压缩数据。 + +### 您提供多少份文件？ 多少张图片？ 多少数据？ + +我们存储数十亿个文件和多个 PB 的数据。 我们存储各种文件，而我们的前 5 个文件扩展名是 pdf，doc / docx，xl​​s / xlsx，jpeg 和 png。 + +### 免费用户与付费用户的比例是多少？ + +我们所有的用户均为付费用户。 我们提供 15 天的免费试用期，之后将其转换或将其禁用。 + +### 在过去一个月中有多少个帐户处于活动状态？ + +我们所有的客户都是付费帐户，并且每个月几乎所有人都活跃。 我们满足他们文件系统的需求，谁在家不用电？ + +## 您的系统如何设计？ + +### 您的系统的体系结构是什么？ + +我们使用基于 REST 的面向服务的体系结构，它使我们能够独立扩展每个服务。 这也使我们能够将一些后端服务移至公共云中托管。 所有服务都是无状态的，并使用数据库或我们自己的对象存储进行存储。 由于服务众多，因此很难将所有服务都绘制在一张图中。 + +[典型请求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的 10000 英尺总览如下 + +![](img/22e68ad1e1e96e52b90aa3482a2446fa.png) + +大约 10000 英尺的 [搜索架构](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下 + +![](img/fd48e5809512b072dec807353c9a0a0a.png) + +### 您的系统面临哪些特定的设计/架构/实施挑战？ + +最大的 架构 挑战包括：- + +1. 节俭地扩展文件存储 + +2. 扩展元数据访问 + +3. 文件与桌面客户端的实时同步 + +### 您是如何应对这些挑战的？ + +1. 对于存储，我们编写了自己的存储，现在我们使用可插拔的存储体系结构将其存储到任何公共云，例如 S3，GCS，Azure...。 + +2. 为了扩展元数据，我们移至 Mysql 并开始使用分片。 在某个时候，我们暂时投入了更多的硬件来腾出空间，以便一层一层地剥去鳞屑洋葱。 + +3. 为了进行实时同步，我们必须更改同步算法，使其更像 Svn，客户端接收增量事件并尝试与云状态进行最终的一致同步。 + +4. 监视，监视和监视。 您无法优化无法衡量的内容。 在某些时候，我们监控太多，无法专注于所有指标，我们不得不依靠异常检测工具，例如 New Relic，AppDynamics，OpenTSDB 和自定义报告，以使我们能够专注于绿色问题[ >黄色->红色。 目的是在客户通知 之前，将它们捕获为黄色并且 [时捕获它们。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) + +### 您的系统如何发展以应对新的扩展挑战？ + +我们已经多次重新构造了许多层。 我无法在本文中全部讲述，但我将尝试列出过去 7 年中核心元数据，存储，搜索层的几次迭代。 + +1. 版本 1：在 Lucene 中搜索文件元数据，通过 NFS 安装在 DRBD Filers 中存储的文件，在 Lucene 中搜索。 阻塞点 ：Lucene 更新不是实时的，必须替换。 + +2. 版本 2：Berkeley db 中的文件元数据，通过 NFS 安装在 DRBD Filers 中的文件，在 lucene 中搜索。 阻塞点 ：我们突破了 NFS 的限制，它左右左右都阻塞了，必须用 http 代替。 + +3. Version3：Berkeley db 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 lucene 中搜索。 阻塞点 ：即使分片的 Berkeley DB 在压力下也阻塞，并且数据库崩溃，恢复工作数小时，必须更换它。 + +4. 版本 4：MySQL 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 lucene 中搜索。 阻塞点 ：公共云开始变得便宜。 + +5. 版本 5：MySQL 中的文件元数据，存储在 EOS / GCS / S3 / Azure 中并通过 HTTP 服务的文件，在 lucene 中进行搜索。 阻塞点 ：搜索开始阻塞，必须更换。 + +6. 版本 6：MySQL 中的文件元数据，通过 HTTP 服务的 EOS / GCS / S3 / Azure 中存储的文件，在 Elasticsearch 中搜索。 这是当前的体系结构，很快，其中一个可能需要另一个轮回：)。 + +### 您是否使用任何特别酷的技术或算法？ + +* 在核心服务之间进行呼叫时，我们使用 [指数补偿](https://en.wikipedia.org/wiki/Exponential_backoff) 断路器，以避免断路器打雷。 + +* 我们在核心服务节点资源上使用公平分配分配方式来处理传入请求。 标记核心服务节点上的每个传入请求并将其分类为不同的组。 每个组都有专用的容量，如果一个客户每秒发出 1000 个请求，而另一个客户每秒发出 10 个请求，则此系统将确保第二个客户不会遇到嘈杂的邻居问题。 诀窍是，两个客户都可能由于哈希而巧合地落在某个节点上的同一组上，但他们不会降落在所有节点上的同一组上，因此我们将节点名称作为盐添加到哈希中。 + +* 带有 SLA 的某些核心服务被隔离在 POD 中，这确保了一个糟糕的客户不会阻塞整个数据中心。 + +* 我们在桌面同步客户端代码中使用基于事件的同步，因为发生服务器事件时，它们会从服务器推送到客户端，并且客户端会在本地重播它们。 + +### 您做什么工作是与众不同的，人们可以从中学到什么？ + +专注于启动的核心功能，如果必须构建定制的内容，那就去启动它。 有很多独特的东西，但是存储层，基于事件的同步绝对值得学习，这里有更多详细信息。 [Egnyte 对象存储库](https://www.egnyte.com/blog/2013/07/how-egnyte-implements-hybrid-object-stores-using-public-clouds-to-enhance-customer-experience/) 和 Egnyte [规范文件系统](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 + +## 您学到了什么？ + +* 您无法优化无法测量的内容：测量所有可能的结果，然后优化系统中首次使用 80％的部分。 + +* 当您身材矮小的时候，请慢慢介绍技术，不要试图从中找到解决当前问题的理想工具。 编码是生命周期中最容易的部分，但是如果您最初使用的技术太多，则其维护（如部署/操作/学习曲线）将非常困难。 当您很大时，您将有足够的脂肪来划分服务，并让每个服务使用其自己的技术并进行维护。 + +* 当您是一家初创公司时，有时您必须快速采取行动，介绍您现在可以做的最好的解决方案，如果看到牵引力，则应加班对其进行重新设计。 + +* 寻找单点故障，并不懈地寻找下来。 付出额外的努力来解决使您彻夜难眠的问题，并尽快从防御性转变为进攻性模式。 + +* 在 SOA 中，如果您的服务受阻，则构建断路器以开始发送 503s。 与其惩罚每个人，不如看看是否可以公平分配资源并仅惩罚滥用用户。 + +* 在服务使用者中添加了自动修复功能，服务可能会停止运行，桌面客户端或其他服务之类的消费者可以进行指数补偿以释放服务器压力并在该服务再次运行时自动修复。 + +* 始终可用：请客户提供服务级别的断路器和断路器。 例如 如果通过 webdav 或 FTP 访问文件系统存在性能问题，并且需要 4 个小时进行修复，那么在这 4 个小时内，您只需在防火墙处杀死 FTP / webdav 并要求客户使用 Web ui 或其他机制即可工作。 同样，如果一个客户引起了异常，使系统窒息，则可以暂时为该客户禁用该客户或服务，并在问题解决后重新启用它。 为此，我们使用功能标志和断路器。 + +* 保持简单：每个月都有新工程师加入，因此目标是从第一周开始就提高他们的生产力，简单的架构可确保轻松上岗。 + +### 您为什么成功？ + +牵引力胜过一切。 当 EFSS 市场刚刚爆发时，我们达到了 [产品/市场适合度](https://www.linkedin.com/pulse/marc-andreessen-product-market-fit-startups-marc-andreessen) 。 具有良好执行力的时机，管理团队的财务纪律导致成功。 许多竞争对手采用了免费增值模式，并筹集了大量资金，但是从第一天开始我们就开始收费，这使我们能够专注于根据市场需求发展解决方案/团队。 专注于付费客户使我们能够交付企业级解决方案，而无需支付免费增值罚金。 + +### 您希望自己做些什么？ + +我希望当我们开始时公共云的成本不会过高。 我也希望我们从第一天开始就使用 SOA，花了一些时间才到达那里，但是现在我们就在那里。 + +### 您不会更改什么？ + +目前，我不会替换 MySQL / EOS，因为它允许我们从防御性定位转到进攻性定位。 我不能在两年后发表评论，我会有相同的想法，我们可能会更改或扩大其中的一些想法。 当您遇到下一个增长突增时，架构会发生变化。 + +## 您应该做多少前期设计？ + +很好的问题。 答案是“取决于”， + +* 如果您要设计核心存储层或核心元数据层之类的东西，那么再多花 2 周的时间对您的设计不会有太大的影响。 当我们在核心元数据层上从 Berkeley DB 迁移到 MySQL 时，我承受着很大的压力，我曾想过要走捷径，当我通过首席技术官运行时，他建议花一些时间并“做正确的事”。 作为回顾，这是一个极好的决定。 + +* 对于公共 API，最好做一个不错的前端设计，因为您没有第二次机会对其进行更改，并且必须在未来 4-5 年内进行维护。 + +* 但是，如果您要为内部服务设计某些东西并将其迁移到新架构的时间不超过一年，那么我建议您进行非常少的前端设计，并快速构建版本并随着使用量的增长对其进行迭代。 + +## 您如何考虑将来更改架构？ + +* 在一周中进行部署（我们快到了） + +* 将更多公共云用于任何新服务，并将更多服务迁移到公共云。 + +* 将其余的源代码从 svn 移至 git + +* 使当前的开发环境尽可能接近生产环境（可以使用 docker 或…）。 + +* 自动化架构管理 + +* 添加更多性能基准测试 + +* 建立持续的交付渠道，以便我们可以将部署增加为每周或每天，而不是每两周一次。 + +* 通过重新构建从某些增长最快的表中删除联接。 + +* 为 Mysql 分片添加自动平衡器，因此我不必担心偶尔出现的热点。 + +* 将某些脂肪服务分成颗粒状 + +* 使用内存缓存代理 + +## 您的团队如何设置？ + +### 您的团队中有多少人？ + +大约有 100 名工程师（devops / ops / qa / developers / ...），其余的是销售，市场营销，支持和人力资源。 + +### 他们在哪里？ + +最初是分散的工程团队，但现在主要吸引人是孟买的 [波兹南](https://en.wikipedia.org/wiki/Pozna%C5%84) 。 一些像我这样的远程员工 和其他一些员工在家工作。 + +### 谁扮演什么角色？ + +这是一个很大的团队，我们有产品经理，UX 团队，开发人员，Scrum 团队，架构师，工程师扮演各种角色。 最初，工程团队很平坦，每个人都会向工程副总裁报告，但现在我们在两者之间增加了一层管理。 + +### 您是否有特定的管理理念？ + +如果您开发某些产品，那么您拥有该产品的生命周期，这意味着您将与 QA，devops 一起确保其测试/部署。 投入生产时，您可以使用各种内部工具（例如 New Relic / Nagios）对其进行监视，如果存在回归，则可以对其进行修复。 + +### 如果您有分散的团队，该如何工作？ + +自治，1-1 交流，黑客马拉松使他们具有挑战性，他们会受到激励。 + +### 您的开发环境是什么？ + +* 适用于服务器团队的 Ubuntu + +* UI 团队使用 Windows / mac 并连接到用于 REST API 服务器的本地 Ubuntu VM 或连接到共享的 QA 实例 + +* Eclipse /想法 + +* 适用于构建的 + +* Maven + +* Git / SVN + +* 詹金斯 + +* ReviewBoard / Sonar + +* JIRA + +* Google 文档 + +* Jabber / Slack / Hangouts / Skype + +### 您的开发过程是什么？ + +我们在服务器团队中使用 Scrum，并且每两周发布一次。 长期功能开发人员/团队在沙盒上工作，完成后通过单元测试/硒/手动 QA 对它进行测试，然后合并到主干以捕获 2 周的发布流程。 我们吃了自己的狗粮，代码在发布前 1 周发布到了 UAT（所有员工使用的 egnyte.egnyte.com），我们发现了自动化测试未发现的任何意外情况。 我们在每个星期五晚上进行生产部署，并且 [每天监视新文物，并针对任何异常](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 每天报告异常报告。 我们正在将部署更改为即将在一周中完成。 + +### 您有什么可以做的不同还是感到惊讶？ + +许多工程师在家工作，令人惊讶的是，有了自主权，许多远程员工像总部员工一样富有生产力和积极性。 + +## 您使用什么基础架构？ + +### 您使用哪种语言来开发系统？ + +大多数是 Java / Python + +### 您有多少台服务器？ + +最后，我知道我们有 700 多个。 100 多个 MySQL 服务器，50 多个 Elasticsearch，200 多个 tomcat 服务节点，300 多个本地存储节点，20 多个 HAProxy 节点和缓存文件管理器，nginx，python 服务器以及其他各种节点。 + +### 如何将功能分配给服务器？ + +我们使用面向服务的体系结构，并根据服务类型分配服务器。 一些顶级服务是： + +* 元数据 + +* 储存空间 + +* 对象服务 + +* Web UI + +* 索引 + +* EventSync + +* 搜索 + +* 审核 + +* 快照/数据监视器 + +* 内容智能 + +* 实时事件传递 + +* 文本提取 + +* 集成 + +* 缩略图生成 + +* 防病毒软件 + +* 垃圾邮件 + +* 预览版 + +* rsync + +* API 网关 + +* 结算 + +* 支持 + +* 销售 + +* 等等。 + +### 如何配置服务器？ + +大多数服务都是伪造的，并且可以在 VM 上运行，我们仅针对 MySQL，memcached，Metadata 服务器，索引之类的少数事物运行物理服务，但是除了数据库/缓存/存储节点之外，大多数服务都可以转换为 VM。 我们使用第三方根据模板来配置服务器，并将其放入数据中心，以供使用。 + +### 您使用什么操作系统？ + +CentOS7 + +### 您使用哪个 Web 服务器？ + +Nginx，Apache。 在一些旧的流程中使用了 Apache，但随着时间的流逝，它将被弃用。 + +### 您使用哪个数据库？ + +MySQL。 我们过去曾使用过其他数据库，例如 Berkeley DB，Lucene，Cassandra，但是由于开发人员/操作人员的熟悉程度和可伸缩性，我们将所有数据库都超时迁移到了 MySQL。 有关更多信息，请参见 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 + +### 您是否使用反向代理？ + +是 Nginx 和 HAProxy + +### 您是否并置，使用网格服务，使用托管服务等？ + +我们搭配。 + +### 您的存储策略是什么？ + +我们首先创建自己的服务器，然后在机器中打包尽可能多的硬盘驱动器，我们过去将它们称为 DRBD Filers。 我们这样做是因为 AWS 成本过高。 我们已经对 [GlusterFS](https://www.gluster.org/) 进行了评估，但是当时它无法扩展以满足我们的需求，因此我们构建了自己的。 加班 S3 变得便宜了，GCS / Azure 诞生了，我们将存储层设计为可插入的，因此现在客户可以决定要使用哪个存储引擎（例如，Egnyte，S3，GCS，Azure 等）。 + +### 您如何增加产能？ + +我们进行能力计划会议，并根据监控指标中的关键指标并预定一些额外的能力得出了一些指标。 现在，某些服务已启用云服务，我们只需单击一下按钮即可提供更多服务。 + +### 您是否使用存储服务？ + +是 Egnyte，S3，GCS，Azure 和 + +### 您如何处理会话管理？ + +我们多次重写了体系结构，目前 99％的服务是无状态的。 仅服务于 Web UI 的服务使用会话，我们在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性会话，但最终我的计划是使它也变得无状态 。 + +### 您的数据库是如何设计的？ 主从？ 碎片？ 其他？ + +我们对几乎所有具有自动故障转移功能的数据库都使用了 Master-Master 复制，但是某些严重变异的数据库的切换是手动完成的，我们遇到了一些问题，由于复制滞后，自动切换会导致应用程序数据不一致，我们 需要重新架构一些核心文件系统逻辑来解决此问题，我们最终将完成此工作。 下面是有关处理数据库升级的问题，详细回答了有关数据库体系结构的更多详细信息。 + +### 您如何处理负载平衡？ + +我们根据客户使用 DNS 访问系统的 IP 进行地理平衡，并在数据中心内使用 HAProxy 将其路由到相应的 POD，并在内部 POD 中再次使用 HAProxy 路由 + +### 您使用哪个 Web 框架/ AJAX 库？ + +我们已经多次更改了 UI，这是一直在变化的一件事。 过去我们曾经使用过 ExtJS，YUI，JQuery，而没有使用过。 最新的迭代基于 ReactJS / Backbone / Marionette 。 + +### 您使用哪种实时消息框架？ + +我们使用 [大气](https://github.com/Atmosphere/atmosphere) ，但最终我们将其替换为 NodeJS + +### 您使用哪个分布式作业管理系统？ + +为此，我们使用 RabbitMQ 和基于 Java / python 的消费者服务。 + +### 您的网站是否有标准 API？ 如果是这样，您将如何实施？ + +我们的 API 分为 3 种类型：- + +1. 公共 API： 这是我们提供给第三方应用程序开发人员和集成团队以及我们的移动应用程序的 api。 我们会按照适当的弃用工作流程弃用/升级 api 签名，并且更改始终向后兼容。 我们使用 Mashery 作为网关，API 记录在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) + +2. 适用于我们客户的 API： 此 API 对我们客户而言是内部的，如果我们以外的人使用此 API，我们不保证向后兼容。 + +3. 服务之间的内部受保护的 API ：这是服务在我们的数据中心内部用于彼此通信的 API，无法从外部防火墙调用。 + +### 您的对象和内容缓存策略是什么？ + +我们存储的数据为 PB 级，无法缓存所有数据，但是如果客户在给定的 15 天时间内拥有 5000 万个文件，则他可能只会使用其中的 100 万个。 我们有基于 tomcat / nginx / local 文件系统的缓存文件管理器节点，它以 LRU 方式运行。 我们可以弹性增加减少缓存文件服务器的数量。 我们最大的问题之一是上传速度，如何从世界任何地方尽可能快地将数据上传到 Egnyte，为此，我们建立了特殊的 Network pops，如果您好奇的话可以在阅读更多内容 [为 Egnyte 客户加速数据访问](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) + +Memcached 用于缓存元数据，我们使用单独的 memcached 池来缓存长期存在的静态数据和文件系统元数据。 核心文件系统元数据非常庞大，不适合当前的内存缓存节点，并且会逐出最近使用的其他类型的数据。 为防止这种情况，我们使用两种类型的池，应用程序代码决定在哪里查找哪种数据。 我们允许在文件系统内存缓存中逐出，并在其他种类的内存池中争取零逐出。 + +### 您的客户端缓存策略是什么？ + +对于我们的 Web ui，我们使用 PageSpeed 进行资源优化，缓存，并使用 requireJS 和其他各种方式仅下载所需的模块。 我们的 Mobile 和 Desktop 客户端丰富使用本地文件系统作为缓存。 + +### 您使用哪些第三方服务来帮助您构建系统？ + +Google BigQuery，New Relic，AppDynamics，MixPanel，Flurry，Tableau 是我们使用的一些分析服务，但大多数核心组件均由我们构建。 + +## 您如何管理系统？ + +### 如何检查全局可用性并模拟最终用户性能？ + +我们使用不同 AWS 区域中的节点来一致地测试带宽性能。 我们还使用内部 haproxy 报告来绘制客户观察到的上载/下载速度，并主动寻找它们，并使用网络弹出和其他策略来加速数据包。 + +![](img/6ffa16c86d1956a9ff0be037d6021022.png) + +### 您如何健康检查服务器和网络？ + +使用了 Nagios 监视器和 New Relic，以及一些内部主动式异常分析。 有关更多详细信息，请参见此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) + +### 如何绘制网络和服务器统计数据以及趋势图？ + +我们使用石墨，仙人掌，Nagios 和 New Relic，AppDynamics。 + +![](img/d7afc2042d53ba5302472ee5be116c5f.png) + +![](img/293ca1407b4f34397f578ec21c96afd2.png) + +### 您如何测试系统？ + +硒，Junit，鼻子，睡表和手动测试。 + +### 您如何分析效果？ + +AppDynamics 是 New Relic，用于监视生产 tomcat 节点的性能。 我们使用石墨/ nagios /内部工具和其他工具来监视系统其他部分的性能。 有关此问题的更多详细信息，请参见此博客文章 [分布式系统中的调试性能问题](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) + +### 您如何处理安全性？ + +专用安全团队在每个版本之前都会运行自动化的安全基准测试。 连续自动化笔测试已在生产中运行。 我们还使用漏洞赏金计划并与 Whitehat 测试公司合作。 一些客户使用第三方进行自己的安全性测试。 + +### 您如何处理客户支持？ + +我们有专门的 24X7 分布式客户成功团队，我们使用 Zendesk 和 JIRA + +### 您是否实施网络分析？ + +我们使用 Google Analytics（分析），Mixpanel，Flurry 来衡量功能使用情况 + +### 您是否进行 A / B 测试？ + +是的，我们使用功能标记进行 A / B 测试。 有关更多信息，请参见 [在 Egnyte 使用功能标志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) + +### 您要运行多少个数据中心？ + +3 个主要数据中心，其中一个在欧洲（由于安全港规定） ，网络遍布世界各地。 + +### 您的系统如何部署在数据中心中？ + +Puppet 用于部署大多数新代码。 我们仍在重写体系结构中最后要伪造的部分，而这些部分目前已使用 Shell 脚本进行了部署。 + +### 您使用哪种防火墙产品？ + +我们混合使用了瞻博网络 SRX 和 Fortigate 防火墙。 + +### 您使用哪个 DNS 服务？ + +PowerDNS + +### 您使用哪些路由器？ + +思科 + +### 您使用哪些开关？ + +Arista + +### 您使用哪个电子邮件系统？ + +我们使用自己的 SMTP 服务器来处理出站电子邮件，对于一些内部工具，我们使用 SendGrid，对于入站电子邮件，我们使用 GMail。 + +### 如何备份和还原系统？ + +对于 MySQL，我们使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，对于 Elasticsearch，该数据被复制 3 次，并且我们还使用 ElasticSearch GCS 备份插件将数据备份到 GCS。 对于客户文件，我们将其复制 3 次。 如果存储 Filer 无法恢复，我们将丢弃它，添加一个新 Filer 并再次复制副本。 对于某些客户，我们还会将其数据复制到他们选择的提供者。 对于使用 S3，Azure 或 GCS 作为可插拔存储层的客户，它将确保复制以防止数据丢失。 + +### 如何进行软件和硬件升级？ + +大多数节点是无状态的，并且有状态组件具有主动-主动故障转移。 通过将节点从池中取出并进行升级并将其放回池中来处理升级。 + +### 您如何处理升级中数据库架构的重大更改？ + +不同的服务使用不同类型的数据库，并且它们以不同的方式升级。 在 10000 英尺处，它们如下图所示： + +![](img/1de3f24a7fc5621b61d6e4e7ca1de358.png) + +1. EOS db 存储对象元数据并且增长非常快，它经过分片，并且我们将继续添加更多此类数据。 + +2. MDB 的增长速度更快，经过了分片，并且我们会继续增加更多。 + +3. DC_central 是 dns 数据库，并且保持相当静态。 我们运行了许多此副本以实现可伸缩性。 + +4. Pod_central 具有快速突变的数据，但每个表的增长量不超过 2000 万行。 我们运行了许多此副本以实现可伸缩性。 + +* 每个数据库模式始终是向前和向后兼容的，即我们绝不会在同一发行版中删除列和代码，我们首先在发行版 1 中部署停止使用该列的代码，在发行版 2 中两周后我们删除该列。 + +* 非分片数据库每 2 周更新一次。 它们是存储各种功能驱动表的表。 我们目前使用脚本升级它们，但现在已更改为使用 [Sqitch](http://sqitch.org/) + +* 使用自动脚本进行分片 db 新列更改 + +* 分片数据库迁移是一件痛苦的事情，因为我们有 7000 多个分片并且还在不断增长，您无法在 1 小时的升级窗口中完成。 方法是： + + * 实时代码根据需要迁移行。 这意味着迁移可能会持续数年。 + + * 使用功能标记进行迁移，您同时拥有新旧代码，并且在后台迁移客户，然后翻转标记以将其切换到新代码路径而无需停机，更多的是 [ [此处](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此处](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) + + * 当我们从 lucene 迁移到 ElasticSearch 时，除了重新索引所有内容外，我们别无选择，我们使用 [功能标记](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 进行了重新编码 -4 个月完成。 + +* 模式一致性检查器报告可确保升级后所有数据中心中的所有模式均相同。 + +### 您是否有单独的运营团队来管理您的网站？ + +是的，我们有一个专门的 devops 团队和一个 IT / Ops 团队，负责监视和管理系统。 + +## 其他 + +### 您欣赏谁？ + +AWS ：他们的创新步伐令人赞叹。 + +Google ：他们的工具，例如 BigQuery，Analytics（分析）都很棒。 + +Elasticsearch ：其余 api 的简洁性和架构都很棒。 + +MySQL： 即可。 + +Eclipse / Jenkins ：插件架构很好。 + +### 您是否模仿了其他人的公司/方法？ + +我们是 [http://highscalability.com/](http://highscalability.com/) 的常规读者，许多设计都受到它的启发。 + +* POD 架构的灵感来自 Tumblr 的 Cell 架构，虽然不完全匹配，但是隔离故障的概念是相同的。 + +* 受 Facebook 启发的架构在 12 小时后会在内存缓存和刷新键中产生抖动。 + +* 受 [http://highscalability.com/上一些文章的启发，将](http://highscalability.com/) [指纹添加到每个数据库查询](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) + +我们正在招聘，请在 [职位页面](http://www.egnyte.com/jobs/engineering.html) 中查看我们，并在 [与我们联系 [受电子邮件保护]](/cdn-cgi/l/email-protection) 。如果您有兴趣成为 [Egnyte](https://www.egnyte.com) 令人惊叹的团队的一员。 + +[关于 HackerNews](https://news.ycombinator.com/item?id=11104555) \ No newline at end of file diff --git a/docs/222.md b/docs/222.md index f681cbf..f46ddbb 100644 --- a/docs/222.md +++ b/docs/222.md @@ -1,83 +1,152 @@ -# Skype 计划 PostgreSQL 扩展到 10 亿用户 +# Zapier 如何自动化数十亿个工作流自动化任务的旅程 -> 原文： [http://highscalability.com/blog/2008/4/5/skype-plans-for-postgresql-to-scale-to-1-billion-users.html](http://highscalability.com/blog/2008/4/5/skype-plans-for-postgresql-to-scale-to-1-billion-users.html) +> 原文： [http://highscalability.com/blog/2016/2/29/a-journey-through-how-zapier-automates-billions-of-workflow.html](http://highscalability.com/blog/2016/2/29/a-journey-through-how-zapier-automates-billions-of-workflow.html) -Skype [使用 PostgreSQL 作为后端数据库](https://developer.skype.com/SkypeGarage/DbProjects/SkypePostgresqlWhitepaper)。 PostgreSQL 在数据库世界中没有得到足够的运行，因此我很高兴地看到 PostgreSQL 如何被用作“满足[Skype]大部分业务需求的主要数据库”。 他们的方法是使用传统的存储过程接口来访问数据，并在该层代理服务器之上，该代理服务器将 SQL 请求散列到一组实际执行查询的数据库服务器上。 结果是他们认为水平扩展的系统可以扩展到可处理 10 亿用户。 +*这是[的来宾](http://stackshare.io/zapier/scaling-zapier-to-automate-billions-of-tasks)[转贴了](http://stackshare.io/zapier/scaling-zapier-to-automate-billions-of-tasks) [Bryan Helmig](http://stackshare.io/bryanhelmig) ， [Zapier](http://stackshare.io/zapier) 的联合创始人& CTO，他可以轻松地在 Web 之间自动执行任务 应用。* -* Skype 的目标是一种可以处理 10 亿以上用户的体系结构。 使用一台真正的大型计算机实际上无法解决此级别的缩放问题，因此我们的蒙版超级英雄水平缩放可以解决。* 硬件是带有 SCSI RAID 的双或四皓龙。* 遵循常见的数据库进度：从一个 DB 开始。 添加按功能划分的新数据库。 复制以只读为主的数据，以实现更好的读取访问。 然后跨多个节点水平分区数据。* 无论如何，在此博客的第一篇文章中，Skype 使用传统的数据库体系结构，其中所有数据库访问都封装在存储过程中。 这使他们可以在不影响前端服务器的情况下进行后台性能调整。 而且它很适合使用 PL / Proxy 进行分区的策略。* [PL /代理](https://developer.skype.com/SkypeGarage/DbProjects/PlProxy)用于通过创建水平分区的集群来扩展其系统的 [OLTP](http://en.wikipedia.org/wiki/OLTP) 部分： +![](img/99150b9925c63916b576766be5cb68de.png) - -数据库查询由代理跨 一组数据库服务器。 代理根据字段值（通常是主键）创建分区。 - -例如，您可以根据用户名通过散列在整个群集中对用户进行分区。 根据哈希将每个用户放入一个碎片中。 - -远程数据库调用使用一种称为 plproxy 的新 PostgreSQL 数据库语言执行。 来自[的示例 Kristo Kaiv 的博客](http://kaiv.wordpress.com/category/plproxy/)： +[Zapier](http://stackshare.io/zapier) 是一项 Web 服务，可自动执行 500 多个 Web 应用程序之间的数据流，其中包括 MailChimp，Salesforce，GitHub，Trello 等。 - ``` +想象一下[建立一个工作流](https://zapier.com/multi-step-zaps/)（或我们称为“ Zap”）的操作，该操作会在用户填写您的 Typeform 表单时触发，然后在您的 Google 日历上自动创建一个事件，发送一个 Slack 通知，最后完成 在 Google 表格电子表格中添加一行。 那是扎皮尔。 即使对于非技术用户来说，构建这样的 Zaps 也非常容易，并且可以无限地自定义。 - First, code to insert a user in a database: - CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS text AS $$ - BEGIN - PERFORM 1 FROM users WHERE username = i_username; - IF NOT FOUND THEN - INSERT INTO users (username) VALUES (i_username); - RETURN 'user created'; - ELSE - RETURN 'user already exists'; - END IF; - END; - $$ LANGUAGE plpgsql SECURITY DEFINER; +作为首席技术官和联合创始人，我构建了许多原始的核心系统，如今领导工程团队。 我想带您**，了解我们的堆栈**，以及我们如何构建它以及如何在今天继续改进它！ - Heres the proxy code to distribute the user insert to the correct partition: - queries=# - CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS TEXT AS $$ - CLUSTER 'queries'; RUN ON hashtext(i_username); - $$ LANGUAGE plproxy; +## 幕后的团队 - Your SQL query looks normal: - SELECT insert_user("username"); - ``` +使 Zapier 滴答作响需要很多时间，因此我们在工程领域有四个不同的团队： - -查询的结果与在远程数据库上执行的查询完全相同。 - -当前，他们可以将 Dual Opteron 服务器上的 1000-2000 请求/秒路由到 16 个分区集群。* 他们喜欢 OLTP 的 PL /代理方法，因为： - -PL /代理服务器形成可伸缩且统一的“ DB 总线”。 代理服务器很健壮，因为在冗余配置中，如果一个服务器出现故障，您可以直接连接到另一个服务器。 而且，如果代理层变慢，则可以添加更多代理并在它们之间进行负载平衡。 - -可以添加更多分区以提高性能。 - -故障转移期间，只有故障分区上的数据不可用。 所有其他分区均正常运行。* [PgBouncer](https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer) 用作 PostgreSQL 的连接池。 PL /代理“在打开每个后端进程与每个分区的连接时会浪费一些连接”，因此池管理器有助于减少连接数量。* 使用 [WAL（预写日志）传送](http://www.postgresql.org/docs/8.1/static/wal-intro.html)创建热备用服务器。 这些服务器似乎不能用于只读操作。* 更复杂的组织通常使用 OLTP 数据库系统来处理高性能事务需求，然后创建单独的系统来满足更多非事务性需求。 例如， [OLAP（在线分析处理）](http://en.wikipedia.org/wiki/Online_analytical_processing)系统通常用于处理复杂的分析和报告问题。 这些在模式，索引等方面与 OLTP 系统不同。 Skype 还将单独的系统用于 Web 应用程序的表示层，发送电子邮件和定价发票。 这要求将数据从 OLTP 移至其他系统。 - -最初 [Slony1](http://slony.info/) 用于将数据移至其他系统，但是“随着复杂性和负载的增加，Slony1 开始给我们带来越来越大的痛苦。” - -为解决此问题，Skype 开发了他们的轻量级排队和复制工具包，称为 [SkyTools](https://developer.skype.com/SkypeGarage/DbProjects/SkyTools) 。 +* **前端团队**在非常强大的工作流编辑器上工作。 +* **全栈团队**是跨功能的，但专注于工作流引擎。 +* **开发人员小组**保持引擎嗡嗡作响。 +* **平台团队**（可协助进行质量检查），并为我们的开发人员平台提供了合作伙伴。 - 代理方法很有趣，并且是我们之前从未见过的架构。 它的力量来自使问题解决间接化的另一个层次，它具有以下优点：* 应用程序独立于数据库服务器的结构。 封装在代理服务器中。* 应用程序无需响应分区，映射或其他更改而进行更改。* 负载平衡，故障转移和读/写拆分对于应用程序是不可见的。 +总而言之，这涉及约 15 名工程师（并且还在不断增加！）。 - 的缺点是：* 性能降低。 添加了另一跳，必须解析查询才能执行所有透明的魔术。* 无法跨分区执行联接和其他数据库操作。* 增加了处理代理服务器的代理配置和 HA 的管理复杂性。 +## 架构 - 容易看出优势大于弊端。 在不更改应用程序的情况下，您可以滑入代理层，并以低价获得很多非常酷的功能。 如果您是 MySQL 用户，并且对这种方法感兴趣，那么请查看 [MySQL 代理](海洋植物 -[http://underwaterseaplants.awardspace.com/seagrapes.htm”](海葡萄... [http：// underwaterseaplants。 awardspace.com/plantroots.htm“](植物根 +[MySQL](http://stackshare.io/mysql) 是我们的主要关系数据存储-您会在 MySQL 内部找到我们的用户，Zaps 等。 [Memcached](http://stackshare.io/memcached) 和 [McRouter](http://stackshare.io/mcrouter) 似乎是无处不在的缓存层。 其他类型的数据将进入其他更有意义的数据存储中。 例如，在 [Redis](http://stackshare.io/redis) 中发现了用于计费和节流的飞行中任务计数，而 [Elasticsearch](http://stackshare.io/elasticsearch) 存储了 Zaps 的历史活动提要。 对于数据分析，我们喜欢一些 [AWS Redshift](http://stackshare.io/amazon-redshift) 。 -上面关于万亿用户的评论很有趣，因为目前世界上只有 67 亿人，而问题不是 Skype 是否可以支持一万亿用户，而是我们的星球是否可以支持一万亿人：D +### 该平台 -好文章 +我们的大多数平台都位于相当**的整体式核心 Python 代码库**中，但是有许多有趣的分支提供了专门的功能。 最好的例子可能是我们如何利用 [AWS Lambda](http://stackshare.io/aws-lambda) 运行合作伙伴/用户提供的代码以自定义应用程序行为和 API 通信。 -我们现在有 2 个 PgBouncer，12 个节点和 12 个 WAL 备份服务器，并且一切正常。 -服务器是 1u 双胞胎，双四核 Intel xeon，具有 32GB 内存和 2 x sas，每个双胞胎上的硬件 raid1。 +### 基础设施 ---- -[http://www.unixvps.com](http://www.unixvps.com) +由于 Zapier **在 AWS** 上运行，因此我们触手可及。 [EC2](http://stackshare.io/amazon-ec2) 和 [VPC](http://stackshare.io/amazon-vpc) 是此处的中心，尽管我们会尽可能使用 [RDS](http://stackshare.io/amazon-rds) 以及大量的自动伸缩组，以确保服务器池处于最佳状态。 顶部形状。 [詹金斯](http://stackshare.io/jenkins)，[地形](http://stackshare.io/terraform)，[人偶](http://stackshare.io/puppet)和 [Ansible](http://stackshare.io/ansible) 都是开发团队的日常工具。 为了监视，我们对 [Statsd](http://stackshare.io/statsd) ， [Graylog](http://stackshare.io/graylog) 和 [Sentry](http://stackshare.io/sentry) （他们*很好*）不够满意。 -我想知道为什么您选择 PostgreSQL 而不是 MySQL？ +## 一些粗糙的数字 -如果您需要任何事务性的东西（而不是 MyISAM），那么 PostgreSQL 的伸缩性要好于使用 InnoDB 的 MySQL。 +这些数字代表一个大概的最小值，以帮助读者了解 Zapier 体系结构的总体大小和尺寸： -我还猜想 Skype 中的某些人比 MySQL 更了解 PG，而 MySQL 和 PG 对存储过程，触发器等的支持要好得多， +* 每天自动完成约 800 万个任务 +* 每天超过约 6000 万次 API 调用 +* 每天有超过 1000 万个入站 Webhooks +* 在 [ELB](http://stackshare.io/aws-elastic-load-balancing) 之后运行 HTTP 的〜12 个 c3.2xlarge 框 +* 运行 [Celery](http://stackshare.io/celery) 的约 100 个 m3.2xlarge 后台工作者（在轮询，挂钩，电子邮件，其他杂项之间拆分） +* 集群中约 3 m3.medium [RabbitMQ](http://stackshare.io/rabbitmq) 节点 +* 〜4 个 r3.2xlarge [Redis](http://stackshare.io/redis) 实例-一个热，两个故障转移，一个备份/映像 +* 〜6 m3.xlarge McRouter 实例之后的〜12 m2.xlarge [Memcached](http://stackshare.io/memcached) 实例 +* 〜3 m3.xlarge 无数据 ElasticSearch 实例之后的〜10 m3.xlarge [ElasticSearch](http://stackshare.io/elasticsearch) 实例 +* 〜1 个 c3.2xlarge Graylog 服务器后面的〜6 m3.xlarge ElasticSearch 实例 +* 集群中约 10 个 dc1.large [Redshift](http://stackshare.io/amazon-redshift) 节点 +* 1 个主 db.m2.2xlarge [RDS MySQL](http://stackshare.io/amazon-rds) 实例，带有〜2 个以上的副本，可用于生产读取和分析 +* 少数支持 RDS MySQL 实例（下面有更多详细信息） +* ...以及大量的微服务和杂项专业服务 -里斯 \ No newline at end of file +## 改善架构 + +虽然架构的主要内容保持不变-我们仅执行了几次大规模迁移-但为将产品分为两类进行了大量工作： + +1. 支持重要的新产品功能 +2. 为更多用户扩展应用程序 + +让我们深入研究每个示例，尽可能多地获取细节，而不会陷入困境！ + +#### 大型功能，例如多步 Zaps + +当我们在 Startup 周末启动 Zapier（有趣的事实：它首先被称为 Snapier！）时，我们在不到 54 个小时的时间内布置了基本架构（由大量的咖啡和更多的啤酒推动）。 总的来说，这是体面的。 **我们保持设计非常非常简单**，这在当时是正确的选择。 + +除了**之外，*也是*简单**。 具体来说，我们将 Zaps 分为两步：将触发器与一个动作配对，一个句号。 + +我们很快就意识到了错过的机会，但是过渡将非常复杂。 我们必须实现一棵有向树，并支持任意数量的步骤（节点），但要对现有 Zaps（已经有数十万个）保持 1 对 1 的支持。 我们必须做到这一点，同时还要保留对数百个独立合作伙伴 API 的支持。 + +从数据模型开始，我们在 MySQL 中构建了一个非常简单的有向树结构。 想象一下一个表，其中每行都有一个自引用`parent_id`外键，再加上一个额外的`root_id`外键以简化查询，您几乎可以理解。 我们讨论了切换到适当的图形数据库（例如 neo4j）的决定，但由于我们进行的查询种类简单且遍历较小尺寸的孤立图形（大约 2 至 50 个节点），因此决定不这样做。 + +进行此工作的一个关键方面是步骤间的独立性。 每一步都必须消耗一些数据（例如，要读取哪个文件夹或要添加到哪个列表 ID），进行 API 魔术处理并返回一些数据（例如，创建的新文件或添加到列表的新卡） ，但不知道其在工作流程中的位置。 每个独立的步骤都是愚蠢的。 + +中间存在**全知的工作流引擎，该引擎通过将步骤串联在一起作为任务来协调独立的 Celery 任务**-一步是由 Zap 的有根树定义的。 这个无所不知的引擎还包含所有其他好处，例如错误&重试处理，报告，日志记录，节流等。 + +即使在获得后端支持之后，我们仍然遇到另一个巨大的问题：**您如何为该对象构建 UI？** + +首先，确保团队中有一些*出色的*设计师和 Javascript 工程师。 然后，您将在嵌套的 Backbone 视图中工作一段时间，然后再进入 React。 :-)认真地说： [React](/react) 是我们正在构建的各种复杂接口的天赐之物。 + +React 的独特之处之一是性能特性对开发人员很友好，但前提是您必须弄清楚数据。 如果您不使用不可变的数据结构，则应使用一些结构共享库来进行所有突变，以及正在开发的深层`Object.freeze()`来捕捉直接尝试突变的地方。 + +构建如此复杂的 UI 面临许多挑战，其中大部分围绕测试和反馈，但要花费大量时间才能从不同的 API 中获取长尾数据，以使其优雅地适合于同一位置。 几乎每种奇怪的数据形状都必须考虑在内。 + +最后，我们的任务是让新编辑器在用户面前进行 alpha 和 beta 测试。 为此，我们同时发布了两个版本的编辑器，并使用功能开关选择了加入用户。在对结果感到满意之前，我们进行了数月的测试和调整-您可以查看 [Multi-Step Zap 的发布 页](https://zapier.com/multi-step-zaps/)了解其最终结果。 + +![](img/7faac64c1acccc1743339f5d3bf58370.png) + +## 扩展应用程序 + +如果服务无法正常启动并可靠运行，那将是徒劳的。 因此，我们的大部分注意力集中在支持水平可伸缩性*和*冗余基础结构以确保可用性的应用程序设计上。 + +到目前为止，我们做出的一些更明智的决定是**使我们对**感到满意的技术加倍**遇到瓶颈**时，分离出单独的功能。 关键是**重用完全相同的解决方案，然后将其移到另一个盒子中，可以在其中自由漫游 CPU 和 RAM 的新鲜草场**。 + +例如，在过去的一年左右的时间里，我们注意到会话数据耗尽了我们主数据库的 IO 和存储量。 由于会话数据实际上是具有较弱一致性要求的键/值排列，因此我们对诸如 [Cassandra](http://stackshare.io/cassandra) 或 [Riak](http://stackshare.io/riak) （甚至是 Redis！）之类的方案进行了激烈的辩论，但最终决定站起来 具有单个会话表的 MySQL 实例。 + +作为工程师，我们的本能是找到最适合该工作的工具，但是**作为实际问题**，该工作并不能保证额外的操作复杂性。 我们知道 MySQL，它可以进行简单的键/值存储，我们的应用程序已经支持它。 畅所欲言。 + +此外，仔细设计应用程序可以使水平缩放同样简单。 由于**轻写模式**，长期运行的后台任务（例如我们的多步骤 Zaps）不受严格的一致性要求的约束，因此**使用 MySQL 读操作是微不足道的（而且很安全！）。 仅复制**作为*主要*接触点。 即使我们偶尔在几分钟内得到了可怕的复制品延迟，但 99.9％的 Zaps 并没有改变-并且肯定不会很快改变-因此它们继续嗡嗡作响。 + +另一个好的做法是**假设最坏的**。 从一开始就设计失败。 尽管通常说起来容易做起来难，但如今实际上却很容易做到。 对于初学者：**将自动缩放组与自动替换**一起使用。 一个常见的误解是，ASG 仅用于扩展以适应波动的负载。 **错误！** **ASG + ELB 组合可以成为可靠性的骨干**，它使您可以随意杀死实例，而不必担心，因为它们会被快速替换。 + +不知何故，我们不断地学习到，系统越简单，您的睡眠就越好。 + +## 日常 + +在本地，我们的工程师享受 [Docker](http://stackshare.io/docker) 提供的功能全面的环境。 `[docker-machine](http://stackshare.io/docker-machine)`和 [`docker-compose`](http://stackshare.io/docker-compose) 一起构成了 MySQL，Memcached，Redis，Elasticsearch 以及所有 Web 和后台工作人员的正确版本。 我们通常建议在本地运行 [`npm`](/npm) 甚至是`runserver`，因为 VirtualBox 破坏了文件监视功能。 + +规范的 [GitHub](http://stackshare.io/github) “拉动请求模型”驱动了我们的大部分工程重点项目，其中记录了日常工作，并在合并之前进行了最终代码审查。 [Hackpad](http://stackshare.io/hackpad) 包含了我们的大部分文档，其中包括大量的入门文档。 + +Zapier 的一大优势是[所有人都支持](https://zapier.com/blog/everyone-on-support/)。 每四到五周，每位工程师都会花费整整一周的支持来帮助调试和解决棘手的客户问题。 这对我们非常重要，因为它为了解客户的痛苦提供了基线（此外，您可能必须处理所运送的错误！）。 + +对于 CI 和部署，我们使用 [Jenkins](http://stackshare.io/jenkins) 在每个 PR 中的每个提交上运行测试，并提供公司任何人都可以按下的“一键式部署”。 新工程师在工作的第一周点击部署按钮的情况并不少见！ + +我们在独立的 VPC 中拥有一个**完整的登台环境，以及一些非常适合测试长期拉动请求的独立 Web 框。 金丝雀部署到生产中很常见-完整记录所有错误，由 Graylog 提供。** + +## 你也可以扎皮尔！ + +开发人员可以使用 Zapier 来做一些很棒的事情。 + +除了多步骤 Zaps 之外，我们还启用了将 [Python](https://zapier.com/help/code-python/) 和 [Javascript](https://zapier.com/help/code/) 编写为工作流中的代码步骤的功能。 无需自己托管和运行脚本-我们会处理所有这些。 我们还提供了绑定以调用网络（`requests`和`fetch`），甚至在运行之间存储一些状态！ + +我们的用户正在采用代码步骤来构建 [Slack](http://stackshare.io/slack) 机器人（以及游戏！），以替换一次性脚本以及更多其他内容。 我个人使用代码步骤来编写机器人和工具，以将代码&错误度量标准跟踪到电子表格中，转换格式奇怪的数据，并替换*吨*的 crontabs。 + +或者，如果您拥有希望非开发人员能够使用的 API，那么我们也将拥有一个史诗般的[开发人员平台](https://zapier.com/developer/)。 只需定义触发器，搜索和操作，任何用户都可以将您的 API 混合到他们的工作流中，并将您的应用程序与 GitHub，Salesforce，Google Docs 等 500 多种应用程序集成。 + +而且，我们经常在招聘，因此，如果您想帮助我们帮助人们更快地工作并自动执行最繁琐的任务，请关注我们的[工作页面](https://zapier.com/jobs/)！ + +[关于 HackerNews](https://news.ycombinator.com/item?id=11082359) + +链接已断开... + +感谢抓住 Gigi！ + +为什么使用 MySQL？ Postgres 不是它的超集吗？ + +您能否评论一下如何在芹菜上实现编排？ 以我的经验，很难做到这一点，因为大部分逻辑是在任务级别定义的，例如，很难在运行时修改任务的行为，因为它是定义的，并且在模块加载到工作程序时变为静态。 \ No newline at end of file diff --git a/docs/223.md b/docs/223.md index 54fe86f..8caae40 100644 --- a/docs/223.md +++ b/docs/223.md @@ -1,221 +1,363 @@ -# YouTube 架构 - -> 原文： [http://highscalability.com/blog/2008/3/12/youtube-architecture.html](http://highscalability.com/blog/2008/3/12/youtube-architecture.html) - -**更新 3：** [在 30 分钟内进行 7 年的 YouTube 可扩展性课程](http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html)和 [YouTube 策略：添加抖动不是一个错误](http://highscalability.com/blog/2012/4/17/youtube-strategy-adding-jitter-isnt-a-bug.html) - -[](http://highscalability.com/blog/2012/4/17/youtube-strategy-adding-jitter-isnt-a-bug.html)**更新 2：** [YouTube 每天达到 10 亿观看](http://mashable.com/2009/10/09/youtube-billion-views/)。 *即每秒至少 11574 次观看，每分钟 694444 次观看和每小时 41666666667 次观看。* - -**更新：** [YouTube：平台](http://www.techcrunch.com/2008/03/12/youtube-the-platform/)。 YouTube 添加了一组丰富的新 API，以免费成为您的视频平台领导者。 在您自己的网站上上传，编辑，观看，搜索和评论视频，而无需访问 YouTube。 通过 API 在内部组成您的网站，因为无论如何以后您都需要公开它们。 - -YouTube 的增长速度非常快，每天的视频观看次数超过 1 亿，只有少数人负责网站的扩展。 他们如何设法将所有视频交付给所有这些用户？ 自从 Google 收购以来，它们又如何发展？ - -## 信息来源 - -1. [Google 视频](https://www.youtube.com/watch?v=w5WVu624fY8) - -## 平台 - -1. 阿帕奇 -2. 蟒蛇 -3. Linux（SuSe） -4. 的 MySQL -5. psyco，动态 python- > C 编译器 -6. 用于视频而不是 Apache 的 lighttpd - -## 里面有什么？ - -### 统计资料 - -1. 支持每天交付超过 1 亿个视频。 -2. 成立于 2/2005 -3. 3/2006 每天 3000 万次视频观看 -4. 7/2006 每天有 1 亿次视频观看 -5. 2 位系统管理员，2 位可扩展软件架构师 -6. 2 位功能开发人员，2 位网络工程师，1 位 DBA - -### 处理快速增长的配方 - -`while (true) -{ -identify_and_fix_bottlenecks(); -drink(); -sleep(); -notice_new_bottleneck(); -}` - -该循环每天运行多次。 - -### 网络服务器 - -1. NetScalar 用于负载平衡和缓存静态内容。 -2. 使用 mod_fast_cgi 运行 Apache。 -3. 请求被路由以由 Python 应用服务器处理。 -4. 应用服务器与各种数据库和其他信息源进行对话，以获取所有数据并格式化 html 页面。 -5. 通常可以通过添加更多计算机来扩展 Web 层。 -6. Python Web 代码通常不是瓶颈，它大部分时间都花在了 RPC 上。 -7. Python 允许快速灵活的开发和部署。 考虑到他们面临的竞争，这至关重要。 -8. 通常少于 100 毫秒的页面服务时间。 -9. 使用 psyco，这是一种动态 python- > C 编译器，它使用 JIT 编译器方法来优化内部循环。 -10. 对于诸如加密之类的占用大量 CPU 资源的活动，它们使用 C 扩展名。 -11. 一些预生成的缓存 HTML，用于渲染块很昂贵。 -12. 数据库中的行级缓存。 -13. 完整格式的 Python 对象将被缓存。 -14. 计算一些数据并将其发送到每个应用程序，以便将这些值缓存在本地内存中。 这是一个未被充分利用的策略。 最快的缓存位于您的应用程序服务器中，不需要花费很多时间就可以将预先计算的数据发送到所有服务器。 只需要一个代理来监视更改，预先计算和发送即可。 - -### 影片投放 - -* 成本包括带宽，硬件和功耗。* 每个视频由一个迷你集群托管。 每个视频由一台以上的机器提供。* 使用群集意味着： - -提供内容的更多磁盘意味着更高的速度。 - -净空。 如果机器故障，其他人可以接管。 - -有在线备份。* 服务器将 lighttpd Web 服务器用于视频： - -Apache 的开销太大。 - -使用 epoll 等待多个 fds。 - -从单进程配置切换到多进程配置以处理更多连接。* 最受欢迎的内容已移至 CDN（内容交付网络）： - -CDN 在多个位置复制内容。 更有可能使内容更接近用户，跳数更少，并且内容将在更友好的网络上运行。 - -CDN 机器主要用于内存不足，因为内容是如此受欢迎，几乎没有内容在内存中跳动的情况。* 不太受欢迎的内容（每天 1-20 次观看）在各种 colo 网站中使用 YouTube 服务器。 - -有长尾巴效果。 视频可能有一些播放，但是正在播放很多视频。 正在访问随机磁盘块。 - -在这种情况下，缓存没有太大的用处，因此花钱购买更多的缓存可能没有意义。 这是非常有趣的一点。 如果您的产品尾部很长，那么缓存并不总是您的性能救星。 - -调整 RAID 控制器，并注意其他较低级别的问题以提供帮助。 - -调整每台机器上的内存，所以不要太多也不要太少。 +# Jeff Dean 在 Google 进行大规模深度学习 -### 提供视频关键点 +> 原文： [http://highscalability.com/blog/2016/3/16/jeff-dean-on-large-scale-deep-learning-at-google.html](http://highscalability.com/blog/2016/3/16/jeff-dean-on-large-scale-deep-learning-at-google.html) -1. 保持简单和便宜。 -2. 保持简单的网络路径。 内容和用户之间没有太多设备。 路由器，交换机和其他设备可能无法承受如此多的负载。 -3. 使用商品硬件。 硬件越昂贵，其他所有东西（支持合同）也就越昂​​贵。 您也不太可能在网上找到帮助。 -4. 使用简单的通用工具。 他们使用大多数内置在 Linux 中的工具，并在这些工具之上。 -5. 处理随机寻优（SATA，调整）。 + +*If you can’t understand what’s in information then it’s going to be very difficult to organize it.* -### 服务缩图 +此引用来自 [Jeff Dean](http://research.google.com/pubs/jeff.html) ，目前是 Google 系统基础架构小组的向导，研究员，研究员。 摘自他最近的演讲： [智能计算机系统的大规模深度学习](https://www.youtube.com/watch?v=QSaZGT4-6EY) 。 -* 出人意料的是，很难高效地进行。* 每个视频都有大约 4 个缩略图，因此缩略图比视频要多得多。* 缩略图仅托管在几台计算机上。* 看到了与服务许多小对象相关的问题： - -大量磁盘搜索以及操作系统级别的 inode 高速缓存和页面高速缓存出现问题。 - -进入每个目录文件的限制。 特别是 Ext3。 转移到更分层的结构。 2.6 内核的最新改进可以将 Ext3 大目录处理提高到[的 100 倍](http://ext2.sourceforge.net/2005-ols/paper-html/node3.html)，但是在文件系统中存储大量文件仍然不是一个好主意。 - -大量请求/秒，因为网页可以在页面上显示 60 个缩略图。 - -在如此高的负载下，Apache 的表现很差。 - -在 Apache 前面使用过的鱿鱼（反向代理）。 这工作了一段时间，但是随着负载的增加，性能最终下降了。 从 300 请求/秒增加到 20。 - -使用 lighttpd 尝试过，但是只有一个线程使它停顿了。 在多进程模式下会遇到问题，因为它们每个都会保留一个单独的缓存。 - -设置了如此多的图像后，一台新机器花费了 24 小时。 - -重新启动计算机需要 6 到 10 个小时才能将缓存预热，以使其不进入磁盘。* 为了解决他们所有的问题，他们开始使用 Google 的 BigTable（分布式数据存储）： - -避免小文件问题，因为它将文件聚集在一起。 - -快速，容错。 假定它在不可靠的网络上工作。 - -较低的延迟，因为它使用了分布式多级缓存。 此缓存可在不同的并置站点上工作。 - -有关 BigTable 的更多信息，请查看 [Google 架构](http://highscalability.com/google-architecture)， [GoogleTalk 架构](http://highscalability.com/googletalk-architecture)和 [BigTable](http://highscalability.com/tags/bigtable) 。 +自 [AlphaGo 诉 Lee Se-dol](https://gogameguru.com/tag/deepmind-alphago-lee-sedol/) 以来， [John Henry](https://en.wikipedia.org/wiki/John_Henry_(folklore)) 的现代版本 与 的致命一击 [像蒸汽锤一样，吸引了全世界，对 AI 的普遍恐惧](https://www.youtube.com/watch?v=j3LVFdWBHVM) [[ 启示录](http://thenextweb.com/insider/2014/03/08/ai-could-kill-all-meet-man-takes-risk-seriously/) ，这似乎是掩盖 Jeff 演讲的绝佳时机。 而且，如果您认为 AlphaGo 现在很好，请等到 beta 达到。 -### 资料库 +Jeff 当然是指 Google 臭名昭著的 [座右铭](https://www.google.com/about/company/) ： *整理世界各地的信息并使其广泛传播 可访问且有用的* 。 -1. 早期 - -使用 MySQL 存储元数据，例如用户，标签和说明。 - -从具有 10 个磁盘的单片 RAID 10 卷中提供数据。 - -以信用卡为生，因此可以租用硬件。 当他们需要更多硬件来处理负载时，花了几天时间订购并交付。 - -他们经历了一个共同的演变：单个服务器，转到具有多个读取从属的单个主机，然后对数据库进行分区，然后决定采用分片方法。 - -出现复制延迟。 主机是多线程的，可在大型计算机上运行，​​因此它可以处理大量工作。 从站是单线程的，通常在较小的计算机上运行，​​并且复制是异步的，因此从站可能会大大落后于主站。 - -更新导致高速缓存未命中，而高速缓存 I / O 导致复制缓慢的磁盘丢失。 - -使用复制体系结构，您需要花费大量金钱来增加写入性能。 - -他们的解决方案之一是通过将数据分为两个集群来优先处理流量：视频观看池和通用集群。 这个想法是人们希望观看视频，以便该功能应获得最多的资源。 YouTube 的社交功能不太重要，因此可以将其路由到功能较弱的群集中。 -2. 后来的几年： - -进行数据库分区。 - -分为多个分片，用户分配了不同的分片。 - -传播写入和读取。 - -更好的缓存位置，意味着更少的 IO。 - -导致硬件减少 30％。 - -复制副本延迟减少到 0。 - -现在几乎可以任意扩展数据库了。 +从历史上看，我们可能会将“组织”与收集，清理，存储，建立索引，报告和搜索数据相关联。 早期 Google 掌握的所有东西。 完成这项任务后，Google 便迎接了下一个挑战。 -### 数据中心策略 +现在 **的组织意味着对** 的理解。 -1. 首先使用[管理托管](http://www.webhostingsearch.com/managed-web-hosting.php)提供程序。 以信用卡为生，所以这是唯一的方法。 -2. 托管托管无法随您扩展。 您无法控制硬件或达成有利的网络协议。 -3. 所以他们去了一个代管安排。 现在，他们可以自定义所有内容并协商自己的合同。 -4. 使用 5 或 6 个数据中心以及 CDN。 -5. 视频来自任何数据中心。 没有最接近的匹配或任何内容。 如果视频足够受欢迎，它将移入 CDN。 -6. 与视频带宽有关，而与延迟无关。 可以来自任何 colo。 -7. 对于图像延迟很重要，尤其是当页面上有 60 张图像时。 -8. 使用 BigTable 将图像复制到不同的数据中心。 代码 - 查看不同的指标以了解谁最接近。 +我的演讲重点： -## 得到教训 +* **实际的神经网络由数亿个参数**组成。 Google 的技能在于如何在大型有趣的数据集上构建并快速训练这些巨大的模型，将其应用于实际问题，*和*然后在各种不同平台（电话）上将模型快速部署到生产环境中 ，传感器，云等）。 -1. **停顿时间**。 当您制定长期解决方案时，富有创意和冒险性的技巧可以帮助您在短期内应对。 -2. **确定**的优先级。 知道什么对您的服务至关重要，并根据这些优先级确定资源和工作的优先级。 -3. **选择战斗**。 不要害怕外包一些基本服务。 YouTube 使用 CDN 分发其最受欢迎的内容。 创建自己的网络将花费很长时间并且花费太多。 您的系统中可能会有类似的机会。 查看[软件即服务](http://highscalability.com/tags/saas)，了解更多想法。 -4. **保持简单！** 简单性使您可以更快地重新构造，以便可以对问题进行响应。 确实没有人真正知道简单性是什么，但是如果您不害怕进行更改，那么这表明简单性正在发生。 -5. **分片**。 分片有助于隔离和限制存储，CPU，内存和 IO。 这不仅仅是要获得更多的写入性能。 -6. **瓶颈上的不断迭代**： - -软件：数据库，缓存 - -操作系统：磁盘 I / O - -硬件：内存，RAID -7. **您作为一个团队**成功。 拥有一支优秀的跨学科团队，了解整个系统以及系统的底层内容。 可以设置打印机，机器，安装网络等的人员。 一个好的团队，一切皆有可能。 +* 神经网络在 90 年代没有兴起的原因是**缺乏计算能力，也缺少大型有趣的数据集**。 您可以在 Google 上看到 Google 对算法的天生喜爱，再加上庞大的基础架构和不断扩大的数据集，如何为 AI 掀起一场**完美的 AI 风暴。** -[在[reduce]](http://www.reddit.com/r/programming/comments/2yfab3/the_youtube_architecture_2008/) 上。 +* Google 与其他公司之间的关键区别在于，当他们在 2011 年启动 Google Brain 项目时， **并未将他们的研究留在象牙塔** 。 项目团队与 Android，Gmail 和照片等其他团队密切合作，以实际改善这些属性并解决难题。 对于每个公司来说，这都是难得的，也是一个很好的教训。 **通过与您的员工合作进行研究** 。 -很棒的文章。 +* 这个想法很有效：他们了解到他们可以采用一整套子系统，其中一些子系统可能是机器学习的， **则将其替换为更通用的端到端 终端机器学习资料** 。 通常，当您有很多复杂的子系统时，通常会有很多复杂的代码将它们缝合在一起。 如果您可以用数据和非常简单的算法替换所有内容，那就太好了。 -非常感谢。 +* **机器学习只会变得更好，更快。** 。 杰夫的一句话：机器学习社区的发展确实非常快。 人们发表了一篇论文，并且在一周之内，全世界许多研究小组下载了该论文，阅读，进行了剖析，对其进行了理解，对其进行了一些扩展，并在 [上发布了自己的扩展。 arXiv.org](http://arxiv.org/) 。 它与计算机科学的许多其他部分不同，在其他方面，人们将提交论文，六个月后，一个会议将决定是否接受该论文，然后在三个月后的会议中发表。 到那时已经一年了。 将时间从一年缩短到一周，真是太神奇了。 -Dimitry。 +* **可以魔术方式组合技术** 。 翻译团队使用计算机视觉编写了可识别取景器中文本的应用程序。 它翻译文本，然后将翻译后的文本叠加在图像本身上。 另一个示例是编写图像标题。 它将图像识别与序列到序列神经网络相结合。 您只能想象将来所有这些模块化组件将如何组合在一起。 -真正的目的是跳过两行：将受欢迎的内容保留在 CDN 上。 换句话说，向 Akamai 扔钱，让 Akamai 担心。 +* **具有令人印象深刻的功能的模型在智能手机** 上足够小。 为了使技术消失，情报必须走到最前沿。 它不能依赖于连接到远程云大脑的网络脐带。 由于 TensorFlow 模型可以在手机上运行，​​因此这可能是可能的。 -当然，这是正确的答案，但是无论您使用的是 Python 还是无关紧要的。 如果没有 Akamai 的服务，鉴于上述基础架构，YouTube 将永远无法满足需求。 +* 如果您不考虑如何使用深度神经网络解决您的数据理解问题， **几乎可以肯定是** 。 这条线直接来自谈话，但是在您使用深层神经网络解决了棘手的问题之后，观察到棘手的问题后，事实就很清楚了。 -*-以信用卡为生，因此可以租用硬件。 当他们需要更多硬件来处理负载时，花了几天时间订购并交付。* +Jeff 总是进行精彩的演讲，这一演讲也不例外。 它简单，有趣，深入并且相对容易理解。 如果您想了解深度学习知识，或者只是想了解 Google 在做什么，那么必须要看的是 。 -这到底是如何工作的？ 当我们调查这个问题时，发现由于我们是一家新成立的初创公司，我们没有信誉（我想没有“发现”的意思，这很明显），因此硬件租赁公司只有在我们中一个人亲自支持贷款的情况下才会向我们出租。 。 鉴于启动风险高且费用高昂，我们最终购买了硬件并将其安装在各种低端 APR CC 等产品上。所有大型硬件供应商都表示“除非我们能看到您最近 N 年 纳税申报表等，我们不会向您出租。” 使得租赁似乎不是“靠信用卡生存”创业公司的真正选择。 +谈话内容不多。 它已经包装好了。 因此，我不确定本文将为您带来多少价值。 因此，如果您只想观看视频，我会理解的。 -哇，那是一篇很棒的文章，没想到 CDN：P +与 Google 对话一样，您会感到我们只被邀请到 Willy Wonka 的巧克力工厂的大厅里。 我们面前是一扇锁着的门，我们没有被邀请进来。那扇门之外的东西一定充满了奇迹。 但是，就连威利旺卡（Willy Wonka）的大厅也很有趣。 -一定要接受红杉资本的私人风险投资，红杉资本也是 Google 的最大股东，并控制着其董事会。 红杉资本利用其影响力迫使 Google 大量为 Youtube 多付钱，红杉资本合作伙伴立即获利 5 亿美元。 +因此，让我们了解杰夫对未来的看法……这很有趣... -这篇文章和视频对我正在从事的一些项目非常有希望。 谢谢！ +## 理解意味着什么？ -完全令人惊叹; 100％值得一读。 +* 当向人们展示街道场景时，他们可以毫无疑问地从场景中挑选文字，了解到一家商店出售纪念品，一家商店的价格确实很低，依此类推。 直到最近，计算机还无法从图像中提取此信息。 -哇，真疯狂。 +![](img/d9c5bdf722db9f4061822228edcff450.png) -一篇很好的文章，但我还没有学到任何新知识。 当前的 YouTube 体系结构已被应用于我们的类似 youtube 用户的罗马尼亚网站之一，该网站称为 [http://www.trilulilu.ro/](http://www.trilulilu.ro/) 。 我们的客户尚未实现的唯一一件事就是数据库分片，现在不需要了，因为 MySQL 数据库总数不到 250MB，而 MySQL 服务器处理的速度至少为 650 qps。 +* 如果您真的想从图像中了解物理世界，则计算机需要能够挑选出有趣的信息，阅读并理解它们。 -那是一篇很棒的文章。 +* 小型移动设备在当今和将来都主导着计算机交互。 这些设备需要不同类型的接口。 您需要真正能够理解并产生语音。 -我认为有趣的是，他们使用了 mod_fastcgi。 我的意思是，我之所以使用它，是因为我被迫使用共享主机，但是在尝试进行大规模扩展时，我总是听说过很多问题（即使那是它的设计目标）。 我想，如果做得对，FastCGI 对于服务器场可能是一笔宝贵的财富。 +* 进行查询：[待售汽车零件]。 旧版 Google 会匹配第一个结果，因为关键字匹配，但是比较匹配的是第二个文档。 真正了解查询的含义是深层次而不是肤浅的单词层次，这是您构建良好的搜索和语言理解产品所需要的。 -这是一篇很棒的文章，非常有趣！ +![](img/0ad48db760cd6b9f0ffb6dacb5986958.png) -很想听听更多这样的故事，例如 Flickr，Twitter，MySpace，Meebo ...客户仍然被大型企业参与者洗脑，认为他们需要 BEA Portal Server 或类似的东西来实现强大，可扩展的企业解决方案。 要说服他们不要将钱花在昂贵的事情上，要花费大量时间来部署和花费巨额财富（并且要花费大量时间）以使其从用户体验的角度来做自己想做的事情，这是一场战斗。 我一直在说：“ MySpace 每天注册 350,000 个用户，他们没有使用 Aqualogic-让我们为一些杀手级的 AJAX UI，小部件和一个实际上有用的 API 节省额外的现金。 +## Google 的深度神经网络简史 -您靠个人信用卡为生，这是正确的...肯定也可以追溯到早期的 YouTube ... +* [Google Brain 项目](https://en.wikipedia.org/wiki/Google_Brain) 于 2011 年启动，致力于真正推动神经网络技术的发展。 -谢谢你的好文章 +* 神经网络已经存在很长时间了。 它们在 60 年代和 70 年代发明，并在 80 年代末和 90 年代初流行，但它们逐渐消失了。 两个问题：1）缺乏训练大型模型所需的计算能力，这意味着无法将神经网络应用于较大的有趣数据集上的较大问题。 2）缺少大量有趣的数据集。 -在 LAMP（Linux，Apache，MySQL，PHP）上组织 [http://anton.shevchuk.name/php/php-cookbook-myphptubecom/']( 原文： [http://highscalability.com/blog/2007/11/19/tailrank-architecture-learn-how-to-track-memes-across-the-en.html](http://highscalability.com/blog/2007/11/19/tailrank-architecture-learn-how-to-track-memes-across-the-en.html) +> 原文： [http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) -是否曾经觉得 Blogsphere 拥有 5 亿个频道却没有任何信息？ Tailrank 通过每小时索引超过 2400 万个 Web 日志和源来查找互联网上最热门的频道。 这是每月 52TB 的原始博客内容（不浪费），并且需要连续处理 160Mbit 的 IO。 他们是如何做到的？ +![](img/98c9699f964c1091947cf4dcdf2cd262.png) -这是 Tailrank.com 创始人兼首席执行官 Kevin Burton 的电子邮件采访。 凯文（Kevin）好心地花时间解释了他们如何扩展索引整个博客圈。 +与拥有 [以及](https://www.sipri.org/media/press-release/2014/nuclear-forces-reduced-while-modernizations-continue-says-sipri) 核武器的国家相比，很少有公司知道如何建立全球性的分布式服务。 Facebook 是其中一家公司， [Facebook Live](https://www.facebook.com/livemap/) ，Facebook 的 [新](https://live.fb.com/about/) 实时视频 流产品，就是这些服务之一。 -## 网站 +Facebook CEO [马克·扎克伯格](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)： -* [Tailrank](http://tailrank.com/) -我们跟踪博客圈中最热门的新闻！* [Spinn3r](http://spinn3r.com/) -您可以用自己的行为来专门研究博客蜘蛛，而不用创建自己的行为。* [凯文·伯顿（Kevin Burton）的博客](http://feedblog.org)-他的博客结合了政治和技术话题。 两者总是很有趣。 +> 我们做出的重大决定是将我们的许多视频工作重点转移到 Live 上，因为这是一种新兴的新格式； 而不是过去五到十年一直在线的那种视频……我们正在进入视频的新黄金时代。 如果您快进五年，人们在 Facebook 上看到并每天分享的大部分内容都是视频，那我不会感到惊讶。 - ## 平台 +如果您从事的是广告业务，那么比提供永无止境，始终在扩展且可以自由生成的广告就绪内容更好的是什么？ 当 Google [开始在呈指数级增长的网络上投放广告时，就利用了](http://www.wsj.com/articles/SB108319881076696889) 的经济学。 - * 的 MySQL* 爪哇* Linux（Debian）* 阿帕奇* 乌贼* PowerDNS* 存储。* 联合数据库。* ServerBeach 托管。* 用于工作分配的工作计划系统。 +Facebook 的流媒体表演的一个例子是两个人在 45 分钟的视频中 [用橡皮筋爆炸西瓜](https://www.buzzfeed.com/brendanklinkenberg/this-exploding-watermelon-was-facebook-lives-biggest-hit-to) 。 它达到了超过 80 万同时观看者的顶峰，这些评论者还收集了 30 万以上的评论。 这就是您可以通过拥有 15 亿用户的社交网络产生的病毒规模。 - ## 面试 +作为比较 [1.14 亿](http://www.statista.com/statistics/216526/super-bowl-us-tv-viewership/) 观看了 2015 年超级碗的观众，平均 [观看者有 236 万 实时流中的](http://money.cnn.com/2015/10/26/media/nfl-yahoo-live-stream-results/) 。 Twitch 的 [840,000](http://www.geekwire.com/2015/amazons-twitch-attracts-monster-audience-at-e3-with-21m-viewers-tuning-in-online/) 观众人数在 2015 年 E3 达到顶峰。9 月 16 日的共和党辩论在 [921,000 达到顶峰 ]](http://www.politicususa.com/2015/10/14/debate-watched-democratic-debate.html) 同时直播。 - * **您的系统是干什么的？** +因此，Facebook 处于最新状态。 请记住，Facebook 也会同时有大量其他流。 - Tailrank 最初是一个 memetracker，用于跟踪博客圈中正在讨论的最热门新闻。 +有线文章 [引用了](http://www.wired.com/2016/04/facebook-really-really-wants-broadcast-watch-live-video/) Facebook 首席产品官 Chris Cox，他说 Facebook： - 我们开始收到大量要求许可我们的爬虫的请求，大约 8 个月前，我们以 Spinn3r 的形式发货了。 +* 拥有**个以上的一百人**进行直播。 （[从[12]开始](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)，现在该项目有 150 多名工程师） - Spinn3r 是自包含的搜寻器，适用于希望索引完整徽标和消费者生成的媒体的公司。 +* 需要能够提供**数百万个同时流**而不会崩溃。 - 与 Spinn3r 相比，Tailrank 仍然是一个非常重要的产品，我们正在开发 Tailrank 3.0，该产品应在将来推出。 目前没有 ETA，但正在积极研究中。 +* 需要能够在流上支持**数百万同时观看者，以及全球不同设备和服务提供商之间的无缝流。** - * **您的系统面临哪些特定的设计/架构/实施挑战？** +Cox 说：“事实证明这是一个非常困难的基础架构问题。” - 我们面临的最大挑战是，我们必须处理和保持分布式系统中的数据一致的庞大数据量。 +如果我们有一些有关如何解决该基础结构问题的详细信息，这会很有趣吗？ 祸是我们。 但是等等，我们做到了！ - 例如，我们每月处理 52TB 的内容。 必须在高度可用的存储体系结构中对其进行索引，以便出现正常的分布式数据库问题。 +[Federico Larumbe](https://www.linkedin.com/in/federicolarumbe) 来自 Facebook 的流量小组，该小组致力于为 Facebook 的 CDN 和全球负载平衡系统提供支持的缓存软件，并发表了精彩的演讲： [扩展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) ，他在其中分享了有关 Live 工作方式的一些详细信息。 - * **您是如何应对这些挑战的？** +这是我在演讲中的发言。 令人印象深刻 - 我们花了很多时间来构建可以扩展和处理故障的分布式系统。 +## 起源故事 - 例如，我们构建了一个名为 Task / Queue 的工具，该工具类似于 Google 的 MapReduce。 它具有集中式队列服务器，可将工作单元交给发出请求的机器人。 +* Facebook 是一项新功能，允许人们实时共享视频。 （请注意，这对于 Facebook 来说只是另一个功能）。 - 它对于爬虫非常有效，因为速度较慢的机器以较低的速度获取工作，而更现代的机器（或性能更好的机器）要求以较高的速度工作。 +* 于 2015 年 4 月推出，只有名人才能通过 [提及应用程序](https://www.facebook.com/about/mentions/) 用作与粉丝互动的媒介。 - 这样可以轻松解决网络异构的​​主要分布式计算谬论之一。 +* 这是产品改进和协议迭代开始的一年。 - 任务/队列足够通用，我们可以实际使用它在系统顶部实现 MapReduce。 + * 他们以 HTTP 实时流媒体 [HLS](https://en.wikipedia.org/wiki/HTTP_Live_Streaming) 开头。 它受 iPhone 支持，并允许他们使用现有的 CDN 架构。 - 我们可能会在某个时候将其开源。 现在它有太多触角缠绕在我们系统的其他部分中。 + * 同时开始研究 [RTMP](https://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol) （实时消息协议） ，这是一种基于 TCP 的协议。 从电话发送到实时流服务器的是视频流和音频流。 - * **您的系统多大？** + * 优点：RTMP 在广播者和观看者之间具有较低的终端等待时间。 在人们相互交流的交互式广播中，这确实有所作为。 然后，降低等待时间并减少几秒钟的延迟，将使体验完全不同。 - 我们每小时索引 2400 万个 Weblog 和提要，并以大约 160-200Mbps 的速度处理内容。 + * 劣势：由于它不是基于 HTTP 的，因此需要一个完整的体系结构。 需要开发新的 RTMP 代理以使其扩展。 - 在原始级别上，我们以大约 10-15MBps 的速度连续写入磁盘。 + * 还研究了 [MPEG-DASH](https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) （基于 HTTP 的动态自适应流）。 - * **您提供多少份文件？ 多少张图片？ 多少数据？** + * 优势：与 HLS 相比，它的空间效率高 15％。 - 现在数据库大约是 500G。 我们预计随着我们扩大产品范围，它的增长将远远超过 2008 年。 + * 优点：它允许自适应比特率。 编码质量可以基于网络吞吐量而变化。 - * **您的增长率是多少？** + * [吹笛者中出压缩解决方案](https://www.crunchbase.com/organization/pied-piper#/entity) ：（开个玩笑） - 主要是客户功能请求的功能。 如果我们的客户想要更多数据，我们会将其出售给他们。 +* 于 2015 年 12 月在数十个国家推出。 - 我们计划在 2008 年扩展集群，以索引网络和消费者生成的媒体的较大部分。 +![](img/cc9254808fa61d8f01212c2503be1c30.png) - * **您的系统的体系结构是什么？** +## 实时视频与众不同，这会引起问题 - 我们将 Java，MySQL 和 Linux 用于我们的集群。 +* 前面提到的西瓜视频的流量模式： - Java 是用于编写搜寻器的出色语言。 库的支持非常牢固（尽管 Java 7 在添加闭包时似乎将成为杀手））。 + * 最初的上升非常陡峭，在几分钟之内达到了每秒 100 多个请求，并持续增长直到视频结束。 - 我们将 MySQL 与 InnoDB 结合使用。 尽管看起来我最终花费了 20％的时间来解决 MySQL 错误和限制，但我们大多数还是对此感到满意。 + * 然后，流量像石头一样下降。 - 当然，没有什么是完美的。 例如，MySQL 确实是为在单核系统上使用而设计的。 + * 换句话说：流量很尖。 - MySQL 5.1 版本在修复多核可伸缩性锁定方面更进一步。 + ![](img/20bf250cc8477b6987d45ae83f3d37c1.png) - 我最近在博客中写道，这些新的多核计算机实际上应该被视为 N 台计算机而不是一个逻辑单元：[分布式计算谬误＃9](http://feedblog.org/2007/09/23/distributed-computing-fallacy-9/) 。 +* 实时视频与普通视频不同：它会导致**尖峰** **流量模式**。 - * **您的系统如何设计以进行扩展？** + * 实时视频更具吸引力，因此观看**的**比普通视频多 3 倍。 - 我们使用联合数据库系统，以便我们可以在看到更多 IO 的情况下分配写负载。 + * 实时视频出现在新闻源的顶部，因此被观看的可能性更高。 - 我们已经在许多基础架构中以开源形式发布了很多代码，并且这些代码也可能会以开源形式发布。 + * 通知会发送到每个页面的所有粉丝，以便另一组可能会观看视频的人。 - 我们已经开放了很多基础架构代码：* http://code.tailrank.com/lbpool-与数据库连接池一起使用的负载均衡 JDBC 驱动程序。* http://code.tailrank.com/feedparser-Java RSS / Atom 解析器，旨在优雅地支持所有版本的 RSS* http://code.google.com/p/benchmark4j/-与 Windows 的 perfmon 等效的 Java（和 UNIX）* http://code.google.com/p/spinn3r-client/-用于访问 Spinn3r Web 服务的客户端绑定* http://code.google.com/p/mysqlslavesync/-克隆 MySQL 安装和设置复制。* http://code.google.com/p/log5j/-Logger 门面，它支持 printf 样式的消息格式，以提高性能和易于使用。 +* 高峰流量会导致缓存系统和负载平衡系统出现问题。 - * **您有多少台服务器？** +* **缓存问题** - 到目前为止大约有 15 台机器。 我们花了很多时间来调整我们的基础架构，因此它非常有效。 也就是说，构建可扩展的爬虫并不是一件容易的事，因此确实需要大量硬件。 + * 很多人可能希望同时观看直播视频。 这是您的经典 [雷电牧群问题](https://en.wikipedia.org/wiki/Thundering_herd_problem) 。 - 我们将在 2008 年将 FAR 扩展到此范围之外，并且可能会击中 2-3 机架机器（约 120 箱）。 + * 尖刻的流量模式给缓存系统带来压力。 - * **您使用什么操作系统？** + * 视频被分割成一秒钟的文件。 当流量激增时，缓存这些段的服务器可能会过载。 - 通过 Debian Etch 在 64 位 Opteron 上运行的 Linux。 我是 Debian 的忠实粉丝。 我不知道为什么更多的硬件供应商不支持 Debian。 +* **全局负载平衡问题** - Debian 是山谷中没人谈论的大秘密。 Technorati，Digg 等大多数大型 Web 2.0 商店都使用 Debian。 + * Facebook 在全球分布 [个存在点](https://en.wikipedia.org/wiki/Point_of_presence) （PoP）。 Facebook 流量在全球范围内分布。 - * **您使用哪个 Web 服务器？** + * 挑战在于防止峰值导致 PoP 过载。 - Apache 2.0。 Lighttpd 也看起来很有趣。 +## 大图片架构 - * **您使用哪个反向代理？** +这就是直播流从一个广播公司到数百万观众的方式。 - 大约 95％的 Tailrank 页面由 Squid 提供。 +* 广播员在其手机上开始直播视频。 - * **您的系统如何部署在数据中心中？** +* 手机将 RTMP 流发送到实时流服务器。 - 我们使用 ServerBeach 进行托管。 对于中小型创业公司来说，这是一个很好的模型。 他们将箱子放在架子上，维护库存，处理网络等。我们只需购买新机器并支付固定的加价。 +* 实时流服务器解码视频并将代码转换为多个比特率。 - 希望 Dell，SUN 和 HP 以这种方式直接出售给客户。 +* 对于每个比特率，都会连续生成一秒的 MPEG-DASH 段。 - 现在一个。 我们希望将冗余扩展为两个。 +* 段存储在数据中心缓存中。 - * **您的存储策略是什么？** +* 来自数据中心的缓存段被发送到位于存在点的缓存（PoP 缓存）。 - 直接连接的存储。 我们每盒购买两个 SATA 驱动器，并将它们设置在 RAID 0 中。 +* 观看者在观看时会收到一个实时故事。 - 我们使用廉价数据库解决方案的冗余阵列，因此，如果单个计算机出现故障，则会在另一个盒中复制数据。 +* 他们设备上的播放器开始以每秒 1 个的速率从 PoP 缓存中获取片段。 - 便宜的 SATA 磁盘决定了我们的工作。 它们便宜，商品且快速。 +## 它如何缩放？ - * **您的网站是否有标准 API？** +* 数据中心高速缓存与**许多 PoP 高速缓存**之间有一个**乘法点**。 用户访问 PoP 缓存，而不是数据中心，并且全世界分布着许多 PoP 缓存。 - Tailrank 每页都有 RSS feed。 +* 另一个乘数是每个 PoP 中的**。** - Spinn3r 服务本身就是一个 API，我们有关于该协议的大量文档。 + * 在 PoP 内有**两层**：一层 HTTP 代理和一层缓存。 - 研究人员也可以免费使用它，因此，如果您的任何读者正在攻读博士学位并通常从事研究工作，并且需要访问我们喜欢的博客数据以帮助他们。 + * 查看器从 HTTP 代理请求段。 代理检查该段是否在缓存中。 如果它在缓存中，则返回该段。 如果不在缓存中，则将对该段的请求发送到数据中心。 - 我们已经有使用 Spinn3r 在华盛顿大学和马里兰大学（我的母校）的博士学位学生。 + * 不同的**段存储在不同的缓存**中，从而有助于跨不同的缓存主机进行负载平衡。 - * **您使用哪个 DNS 服务？** +## 保护数据中心免受雷电袭击 - PowerDNS。 这是一个很棒的产品。 我们仅使用 recursor 守护程序，但它是 FAST。 虽然它使用异步 IO，所以它实际上并不能在多核盒子上的处理器之间扩展。 显然，有一种破解方法可以使其跨内核运行，但这并不是很可靠。 +* 当所有观众同时请求相同的片段时会发生什么？ - AAA 缓存可能已损坏。 我仍然需要研究这个。 +* 如果该段不在缓存中，则将向每个查看器发送一个请求到数据中心。 - * **您欣赏谁？** +* **请求合并** 。 通过将请求合并添加到 PoP 缓存中，减少了请求数量。 仅第一个请求发送到数据中心。 其他请求将一直保留，直到第一个响应到达并将数据发送给所有查看者为止。 - 唐纳德·克努斯是男人！ +* 新的缓存层已添加到代理，以避免 **Hot Server 问题**。 - * **您如何考虑将来更改架构？** + * 所有查看器都发送到一个缓存主机，以等待该片段，这可能会使主机过载。 - 我们仍在努力完善完整的数据库。 MySQL 容错和自动升级也是一个问题。 + * 代理**添加了缓存层**。 实际上，只有第一个对代理的请求才向缓存发出请求。 以下所有请求均直接从代理服务。 -MySQL 故障 -容忍度和自动升级也是一个问题。 +## PoP 仍处于危险之中-全局负载平衡可拯救 -当数据库对您如此重要时，您应该将其像已存在可行替代品的任何其他基础结构商品一样对待： +* 因此，可以保护数据中心免受雷电群问题的影响，但是 PoP 仍然处于危险之中。 Live 的问题是尖峰非常大，以致 PoP 可能在 PoP 的负载度量达到负载平衡器之前过载。 -吞咽困难，然后小便达到最佳状态。 +* 每个 PoP 具有数量有限的服务器和连接性。 如何防止峰值导致 PoP 过载？ -“最好”在旁观者眼中，因此我将其留给读者。 +* 名为 Cartographer 的系统将 Internet 子网映射到 PoP。 它测量每个子网和每个 PoP 之间的延迟。 这是延迟测量。 -中文 memeTracker 网站： [http://www.onejoo.com/](http://www.onejoo.com/) -监视超过 500 万博客，论坛和新闻。 +* 测量每个 PoP 的负载，并将每个用户发送到具有足够容量的最近 PoP。 代理中有一些计数器可以衡量它们承受的负载量。 这些计数器是聚合的，因此我们知道每个 PoP 的负载。 -您如何使用 InnoDB 支持全文搜索？ +* 现在存在一个优化问题，该问题会考虑容量限制并最大程度地减少延迟。 --伊沃 +* 使用控制系统时，存在测量延迟和反应延迟。 -[http://www.web20friends.net](http://www.web20friends.net) +* 他们将负载测量窗口从 1.5 分钟更改为 3 秒，但仍然有 3 秒的窗口。 -嗨，伊沃 +* 解决方案是在实际发生负载之前 **预测负载** 。 -我们不在 innodb 上使用全文本搜索。...实际上，我们将数据快照加载到 myisam 中，并将其用于全文本搜索。 +* 实施了**容量估算器**，将每个 PoP 的先前负载和当前负载外推到未来负载。 -对于小型文档集，MySQL 全文搜索在某种程度上是可取的。 + * 如果负载当前正在增加，预测器如何预测负载将减少？ -tailrank feedparser Wiki 为何以票证的形式充满色情链接？ -[http://code.tailrank.com/feedparser/report/6](http://code.tailrank.com/feedparser/report/6) + * **三次样条**用于 [插值](https://en.wikipedia.org/wiki/Spline_interpolation) 功能。 -现在，世界上大多数参与计算环境的名人都在使用 MYSQL。 我猜它是从它自己的体系结构中获得流行的。 ------ -[http://underwaterseaplants.awardspace.com“](海洋植物 -[http://underwaterseaplants.awardspace.com/seagrapes。 htm“](海葡萄... [http://underwaterseaplants.awardspace.com/seaweed.htm”](海藻 \ No newline at end of file + * 取一阶和二阶导数。 如果速度为正，则负载将增加。 如果加速度为负，则表示速度正在降低，最终将为零并开始降低。 + + * 三次样条比线性插值预测更复杂的交通模式。 + + * **避免振荡** 。 此插值功能还解决了振荡问题。 + + * 测量和反应的延迟意味着对过时的数据做出决策。 插值可减少误差，更准确地进行预测并减少振荡。 因此负载可以更接近目标容量 + + * 当前预测基于 最近的三个间隔 ，其中每个间隔为 30 秒。 几乎是瞬时负载。 + +## 测试 + +* 您需要能够使 PoP 过载。 + +* 构建了一个负载测试服务，该服务在 PoP 上全局分布，以模拟实时流量。 + +* 能够模拟 10 倍的生产负荷。 + +* 可以模拟一次请求一个片段的查看器。 + +* 该系统有助于揭示和修复容量估计器中的问题，以调整参数并验证缓存层是否解决了雷电群问题。 + +## 上传可靠性 + +* 实时上传视频具有挑战性。 + +* 以具有 100 至 300 Kbps 可用带宽的上载为例。 + +* 音频需要 64 Kbps 的吞吐量。 + +* 标清视频需要 500 Kbps 的吞吐量。 + +* 手机上的自适应编码用于调整视频+音频的吞吐量不足。 视频的编码比特率根据可用的网络带宽进行调整。 + +* 决定上传比特率的方法是在手机中通过测量 RTMP 连接上的上传字节来完成，并且对最后间隔进行加权平均。 + +## 未来方向 + +* 研究一种推送机制，而不是请求拉机制，利用 HTTP / 2 在请求分段之前将其推送到 PoP。 + +## 相关文章 + +* [关于 HackerNews](https://news.ycombinator.com/item?id=11987654) + +* [扩展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) + +* [为什么 Facebook 和 Mark Zuckerberg 都参与直播视频](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video) + +* [连通世界：Facebook 的网络基础架构](http://cs.unc.edu/xcms/wpfiles/50th-symp/Moorthy.pdf) + +* [Gamoloco](https://gamoloco.com/) 跟踪 1476093 个频道的实时视频统计信息。 + +Google Chrome 浏览器告诉我您的网站已感染恶意软件。 也许是个调皮的广告？ + +我很乐意在具有如此高流量的平台上工作。 12 位工程师可以毫无问题地做到这一点。 很少有人可以在应用程序上工作，甚至可以进行额外的数据压缩，而在主平台上则很少。 我什至可以处理 100-200k 观众的实时视频流，唯一的限制是资金有限；）我仍然不明白 150 名工程师在此方面的工作... +一如既往的好文章，我 很抱歉，我目前没有客户，流量非常大。 + +150 名工程师可以同时建立 10 个创业公司！ 没有留下深刻印象。 + +我不知道为什么 Google 网站管理员工具 Dobes 会显示该网站存在我什至无法在该网站上找到的问题，但是却没有说出它是否带有恶意软件。 + +我不知道 Facebook 工程师的自我来自何处。 毫无疑问，这是一个很难解决的问题，但我认为这与核武器的复杂性不相上下。 + +Facebook live 的问题都不是新问题。 它们是成熟的技术，许多公司已经多次解决了它们。 + +规模仍然非常可观，我想你们应该专注于此。 + +我对 MPEG-DASH 感到担心，“它允许自适应比特率。编码质量可以根据网络吞吐量而变化”。 那是优点还是缺点？ 谢谢。 + +自适应比特率通常被认为是一个优势，因为只要带宽高于最小比特率，流就不会中断。 + +顺便说一下，就我所知，MPEG-DASH 与 HLS 本质上相同，都允许自适应比特率。 \ No newline at end of file diff --git a/docs/229.md b/docs/229.md index c7c2bee..8c7815c 100644 --- a/docs/229.md +++ b/docs/229.md @@ -1,200 +1,348 @@ -# Flickr 架构 +# Google 如何针对行星级基础设施进行行星级工程设计？ -> 原文： [http://highscalability.com/blog/2007/11/13/flickr-architecture.html](http://highscalability.com/blog/2007/11/13/flickr-architecture.html) +> 原文： [http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html](http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html) -**更新：** Flickr 击中[提供了 20 亿张照片](http://www.webware.com/8301-1_109-9816461-2.htm)。 那是很多汉堡包。 +![](img/9c7095e31a8c5999cdcef74072ddf82a.png) -Flickr 既是我最喜欢的[鸟](http://www.birds.cornell.edu/AllAboutBirds/BirdGuide/Northern_Flicker.html)，也是网络上领先的照片共享网站。 Flickr 面临着巨大的挑战，他们必须处理浩如烟海的内容，包括不断扩展的新内容，不断增长的用户群以及不断涌现的新功能，同时还要提供出色的性能。 他们是如何做到的呢？ +Google 如何保持其所有服务正常运行？ 他们似乎从来没有失败过。 如果您想知道我们在 [GCP NEXT 2016](https://cloudplatformonline.com/next2016-schedule.html) 上发表的演讲中的精彩幕后花絮， [Melissa Binde](https://www.linkedin.com/in/mbinde) ，Google Storage SRE 总监： [Google 如何针对行星级基础架构](https://www.youtube.com/watch?v=H4vMcD7zKM0)进行行星级工程。 -网站：http：//www.flickr.com +梅利莎（Melissa）的讲话很简短，但充满智慧，而且以一种胡说八道的方式表达出来，使您认为服务是否失败梅利莎（Melissa）绝对是您想要的那种人。 -## 信息来源 +哦，什么是 SRE？ 它代表*站点可靠性工程*，但定义却更加难以捉摸。 就像您要求道的定义时得到的答案一样。 正如 Google 的本·斯洛斯（Ben Sloss）24x7 副总裁所明确指出的那样，这不仅仅是一个过程，更是一个过程，他将 SRE 定义为： -* [Flickr 和 PHP](http://www.niallkennedy.com/blog/uploads/flickr_php.pdf) （早期文档）* [LAMP](http://www.kitchensoap.com/talks/MySQLConf2007-Capacity.pdf) 的容量规划* [Flickr 的联合会：每天进行数十亿次查询](http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html)，作者 Dathan Pattishall。* [构建可扩展网站](http://www.amazon.com/Building-Scalable-Web-Sites-Applications/dp/0596102356)，来自 Flickr 的 Cal Henderson。* [数据库战争故事＃3：Flickr [Tim O'Reilly]](http://radar.oreilly.com/2006/04/database-war-stories-3-flickr.html)* [Cal Henderson 的演讲](http://www.iamcal.com/talks/)。 很多有用的 PowerPoint 演示文稿。 +> 当软件工程师承担了过去称为操作的任务时会发生什么。 - ## 平台 +让它在您的头部反弹一会儿。 - * 的 PHP* 的 MySQL* 碎片* Memcached 用于缓存层。* 乌贼在反向代理为 HTML 和图像。* Linux（RedHat）* 聪明的模板* 佩尔* 用于 XML 和电子邮件解析的 PEAR* ImageMagick，用于图像处理* Java，用于节点服务* 阿帕奇* 用于部署的 SystemImager* Ganglia 用于分布式系统监控* Subcon 将重要的系统配置文件存储在 Subversion 存储库中，以便轻松部署到群集中的计算机上。* Cvsup for distributing and updating collections of files across a network. +最重要的是，有一件事很清楚：SRE 是生产的保管人。 SRE 是 google.com 和 GCP 的客户体验的管理者。 - ## 统计资料 +对我来说，一些演讲重点： - * 每天超过 40 亿个查询。* 鱿鱼缓存中约有 3500 万张照片（总计）* 鱿鱼的 RAM 中有约 200 万张照片* 约 470M 张照片，每张 4 或 5 个尺寸* 38k req / sec 到 memcached（1200 万个对象）* 2 PB 原始存储（周日消耗约 1.5 TB* 每天要添加超过 40 万张照片 +* **点检正常运行时间的破坏性激励与功能**相比。 SRE 试图解决想要推送功能的开发人员与想要通过不推送功能来维持正常运行时间的系统管理员之间的天然矛盾。 +* **错误预算**。 这是预期会失败的想法。 这不是一件坏事。 用户无法确定服务的运行时间是 100％还是 99.99％，因此您可能会出错。 这减少了开发人员和运营人员之间的紧张关系。 只要维护错误预算，您就可以推出新功能，而运营方也不会受到指责。 +* **目标是立即恢复服务。 故障排除将在稍后进行。** 这意味着在还原服务后，您需要大量日志记录和工具来进行调试。 由于某种原因，这使[较早的文章](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html)上的内容闪烁了起来，同样基于 Google SRE 的讲话：*备份无用。 这是您关心的*还原。 +* **没有无聊的分页哲学**。 当页面进入时，应该是一个有趣的新问题。 您不希望无聊的 SRE 处理重复性问题。 这就是机器人的目的。 - ## 架构 +演讲中其他有趣的话题是：SRE 的组织结构如何？ 如何聘用开发人员来专注于生产并使他们满意？ 我们如何保持团队在 Google 内部的价值？ 我们如何帮助我们的团队更好地沟通并解决与数据而非断言或权力夺取的分歧？ - * 在此[幻灯片](http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches/138)上可以找到 Flickr 架构的漂亮图片。 一个简单的描述是： - -ServerIron 的 - ---- Squid 缓存对 - ------ Net App 的 - ---- PHP App Server - ---- -存储管理器 - ------主-主分片 - ------双树中央数据库 - ------内存缓存群集 - ------ 大型搜索引擎 +让我们继续吧。 以下是 Google 如何针对行星级基础设施进行行星级工程... - -双树结构是对 MySQL 的一组自定义更改，它允许通过增量添加没有环体系结构的母版进行缩放。 这样可以进行更便宜的扩展，因为与主-主设置相比，您需要的硬件更少，而主-主设置始终需要两倍的硬件。 - -中央数据库包含“用户”表之类的数据，该数据包括主用户 - 键（一些不同的 ID）以及可以在其上找到用户数据的指针。 +## 保持平衡：点检正常运行时间的破坏性动机与功能 - * 使用专用服务器获取静态内容。* 讨论如何支持 Unicode。* 使用无共享架构。* 一切（照片除外）都存储在数据库中。* 无状态意味着他们可以在服务器周围弹跳人，并且更容易制作他们的 API。* 首先通过复制进行扩展，但这仅有助于读取。* 通过复制他们要搜索的数据库部分来创建搜索服务器场。* 使用水平缩放，因此他们只需要添加更多计算机即可。* 通过解析每封电子邮件（用 PHP 交付）来处理从用户发送的图片。 电子邮件被解析为任何照片。* 早些时候他们遭受了奴隶主的滞后。 负载太多，它们只有一个故障点。* 他们需要能够进行实时维护，修复数据等功能，而又不会导致站点停机。* 关于容量规划的许多优秀资料。 请查看信息源以获取更多详细信息。* 采取联合方法，以便它们可以扩展到更远的将来： - -分片：我的数据存储在我的分片上，但是对您的评论执行操作的记录却在您的分片上。 在他人的博客 - -Global Ring 上发表评论时，就像 DNS 一样，您需要知道该去哪里，以及谁来控制您的去向。 在每个页面视图中，计算当时的数据位置。 - -用于连接至分片并保持数据一致的 PHP 逻辑（带有注释的 10 行代码！）* 碎片： - -主数据库的一部分 - -主动主-主环复制：MySQL 4.1 中的一些缺点，因为尊重主-主中的提交。 AutoIncrement ID 自动执行，以使其保持活动状态。 - -分片分配来自新帐户的随机数。 - -迁移会不时进行，因此您可以删除某些超级用户。 如果您有很多照片，则需要平衡…192,000 张照片，700,000 个标签将花费大约 3-4 分钟。 迁移是手动完成的。* 单击收藏夹： - -从缓存中提取照片所有者帐户，以获取分片位置（例如，在分片 5 上） - -从缓存中提取我的信息，以获取我的分片位置（例如，在分片 13 上） - -开始“分布式交易”-回答以下问题：谁收藏了照片？ 我最喜欢什么？* 可以从任何分片提问，并恢复数据。 它绝对多余。* 要消除复制滞后… - -每个页面加载，都会为用户分配一个存储桶 - -如果主机关闭，请转到列表中的下一个主机； 如果所有主机都关闭，则显示错误页面。 他们不使用持久连接，而是建立连接并将其拆除。 这样，每个页面加载都会测试连接。* 每个用户的读写都保存在一个分片中。 复制滞后的概念消失了。* 分片中的每个服务器已加载 50％。 关闭每个分片中的 1/2 台服务器。 因此，如果该碎片中的一台服务器关闭或处于维护模式，则该碎片中的一台服务器可以承担全部负载。 要升级，您只需要关闭一半的碎片，升级一半，然后重复该过程即可。* 在流量激增的一段时间内，它们违反了 50％的规则。 他们每秒执行 6,000-7,000 个查询。 现在，其每秒最多可查询 4000 个查询，以使其保持 50％的负载。* 每页平均查询为 27-35 条 SQL 语句。 收藏夹计数是实时的。 API 对数据库的访问都是实时的。 达到了实时要求，没有任何缺点。* 每秒超过 36,000 个查询-在容量阈值内运行。 流量爆裂，两倍 36K / qps。* 每个碎片可容纳 40 万多个用户数据。 - -很多数据被存储两次。 例如，评论是评论者和被评论者之间关系的一部分。 评论存储在哪里？ 两个地方怎么样？ 事务用于防止数据不同步：打开事务 1，写命令，打开事务 2，写命令，如果一切都很好，则提交第一个事务，如果第一次提交，则提交第二个事务。 但是在第一次提交期间出现故障时，仍然有失败的可能。* 搜索： - -两个搜索后端：几个分片上的分片 35k qps 和 Yahoo!的（专有）网络搜索 - -所有者的单个标签搜索或批量标签更改（例如，通过 Organizr） 碎片由于实时性的要求，其他一切都归 Yahoo!的引擎处理（可能比实时性差 90％） - -考虑一下，这样您就可以进行类似 Lucene 的搜索* 硬件： - -带 RHEL4 的 EMT64，16GB RAM - -6 磁盘 15K RPM RAID-10。 - -数据大小为 12 TB 用户元数据（这些不是照片，这只是 innodb ibdata 文件-这些照片要大得多）。 - -2U 盒子。 每个分片都有〜120GB 的数据。* 备份过程： - -在 cron 作业上进行 ibbackup，该备份在不同时间跨各种分片运行。 热备份到备用。 - -快照是每晚在整个数据库集群中拍摄的。 - -在一次复制复制文件存储库中一次写入或删除多个大备份文件时，由于复制备份文件，可能会在接下来的几个小时内破坏该文件存储库的性能。 对生产中的照片存储文件管理器执行此操作不是一个好主意。 - -保留所有数据多天备份的成本不菲，这是值得的。 几天后发现有问题时，保留交错备份非常有用。 例如 1 天，2 天，10 天和 30 天的备份。* 照片存储在文件管理器中。 上传后，它会处理照片，为您提供不同的尺寸，然后完成。 元数据和指向文件管理器的点都存储在数据库中。* 聚合数据：非常快，因为它是每个分片的一个过程。 将其粘贴到表中，或从其他用户分片的另一个副本中恢复数据。* max_connections =每个分片 400 个连接，或每个服务器&分片 800 个连接。 大量的容量和连接。 线程缓存设置为 45，因为您同时进行活动的用户不超过 45 个。* 标签： - -标签与传统的标准化 RDBM 架构设计不太匹配。 非规范化或繁重的缓存是在数毫秒内为数亿个标签生成标签云的唯一方法。 - -它们的某些数据视图是由专用处理集群离线计算的，这些集群将结果保存到 MySQL 中，因为某些关系计算起来非常复杂，以至于会吸收所有数据库 CPU 周期。* 未来方向： - -使用实时 BCP 使其速度更快，因此所有数据中心都可以同时接收对数据层（db，memcache 等）的写入。 一切都处于活动状态，不会有任何闲置状态。 +* 系统管理员会在站点正常运行时获得 Cookie 的正常运行时间。 当网站停滞不前时，我们会吸引访问者，访问者会给我们钱。 - ## 得到教训 +* 开发人员会获得功能的 Cookie。 发布一个新功能，访问者来了，他们给了我们钱。 - * **不仅将您的应用程序视为 Web 应用程序**。 您将拥有 REST API，SOAP API，RSS feed，Atom feed 等。 +* 生产冻结，也就是新功能的冻结，通常映射为增加正常运行时间。 - * **进入无状态**。 无状态使系统更简单，更健壮，可以处理升级而不会退缩。 +* 开发人员和系统管理员之间存在天生的紧张关系。 开发人员会获得发布功能的 Cookie。 系统管理员会获取 Cookie 以确保正常运行时间。 - * 重新架构数据库很烂。 +* 因此，系统管理员因阻止新功能发布而获得奖励。 如果开发人员能够解决系统管理员的问题，他们将获得奖励。 - * **容量计划**。 尽早将容量规划纳入产品讨论中。 从$$美元的人员（和工程管理人员）那里买到值得关注的东西。 +* 开发人员进行他们所谓的 Beta 测试是为了尽快发布功能。 - * **缓慢启动**。 不要仅仅因为害怕/高兴您的网站会爆炸而购买过多的设备。 +* 系统管理员执行他们所谓的启动评论，以减慢新功能。 - * **测量真实度**。 容量规划数学应该基于真实事物，而不是抽象事物。 +* 您的团队将所有的时间都花在彼此抗争上，因此您会增加停机次数，风险，混乱和无政府状态。 - * **内置日志记录和指标**。 使用情况统计信息与服务器统计信息一样重要。 内置自定义指标，以衡量基于服务器统计信息的实际使用情况。 +* 您想要的是消除异想天开的命令。 请按规则处理，以便团队可以有目标并共同努力。 - * **缓存**。 缓存和 RAM 是一切的答案。 +* 就像 devops 一样，有一种方法可以使开发人员和操作人员一起工作。 问题是，devops 无论走到哪里都有不同的含义。 相反，SRE（站点可靠性工程）定义明确。 - * **摘要**。 在数据库工作，业务逻辑，页面逻辑，页面标记和表示层之间创建清晰的抽象层。 这支持快速完成迭代开发。 +* **SRE：** **当您要求软件工程师设计和运行操作时会发生什么？**-Ben Sloss 24x7 VP，Google - * **层**。 分层使开发人员可以创建页面级逻辑，设计人员可以使用这些逻辑来构建用户体验。 设计人员可以根据需要询问页面逻辑。 这是双方之间的谈判。 + * 软件工程师-事实证明，当知道软件的人也运行服务时，服务可以更好地运行。 他们对什么使它打勾有深刻的理解。 - * **经常释放**。 甚至每 30 分钟一次。 + * 设计和运行-实际上是设计您的生产环境，而不是让它成为意外的事故。 - * **大约 97％的时间都忘了小效率**。 过早的优化是万恶之源。 +* 假设有 1000 个 SRE 在 Google 的基础架构上工作：网络，计算，存储等。有多少个 SRE 负责云计算？ - * **生产中测试**。 内置于体系结构机制（配置标志，负载平衡等）中，通过这些机制，您可以轻松地将新硬件部署到生产中（或从生产中删除）。 + * 所有。 - * **忘记基准**。 基准可以很好地了解功能，但不适用于规划。 人工测试可以提供人工结果，并且时间可以更好地用于真实测试。 + * **google.com 的运行源与 GCP（Google 的云平台）的运行**之间没有界限。 不需要让云团队和内部团队进行沟通的开销。 他们创造了一种环境，可以帮助所有人协同工作。 - * **找出上限**。 - -每个服务器最多可以做些什么？ - -您离该最大值有多近？趋势如何？ - -MySQL（磁盘 IO？） - -SQUID（磁盘 I 或 CPU？） - -内存缓存（CPU？或网络？） +## 技能：SRE 是一个印章团队和圣职 - * **对您的应用程序类型**的使用模式敏感。 - -您有与事件相关的成长吗？ 例如：灾难，新闻事件。 - -Flickr 在一年的第一个工作日获得的上传数量比上一年的任何前一个高峰多 20-40％。 - -周日的上载次数比一周的其余时间平均多 40-50％ +* 本节的标题是我的描述。 具有技能的 SRE 必须是精英。 在工作方面，他们仅致力于这种几乎准神秘的事物，称为生产。 - * **对指数增长的需求敏感**。 更多的用户意味着更多的内容，更多的内容意味着更多的连接，更多的连接意味着更多的使用。 +* SRE 必须比开发人员更熟练，才能完成相同的工作： - * **计划峰**。 能够处理上下堆叠的峰值负载。 + * 他们需要更大的技能范围。 -Flickr 仅在其数据库中存储对映像的引用，实际文件存储在网络上其他位置的单独存储服务器上。 + * 所有 SRE 必须通过完整的软件开发人员面试才能被录用。 -Flickr 图像的典型 URL 如下所示： + * 所有 SRE 必须通过一次非抽象的大型系统设计采访。 -`[http://farm1.static.flickr.com/104/301293250_dc284905d0_m.jpg](http://farm1.static.flickr.com/104/301293250_dc284905d0_m.jpg)` +* SRE 必须具有相同的软件技能，这是不同的应用领域。 -如果将其拆分，我们将得到： + * 开发人员专心于产品经理并制作功能。 -`farm1` -显然是图像存储所在的服务器场。 我还没有看到其他的价值。 + * SRE 依赖于生产，以使生产达到最佳状态。 -`.static.flickr.com` -相当自我解释。 +* **将面向开发和面向生产的观点结合在一起时，最终的设计会更强大**。 -`/104` -服务器 ID 号。 +* 入职流程示例给出了 SRE 带来的问题的示例，该过程在将团队的项目置于 SRE 的责任之下时发生。 在评估团队的软件时，他们发现： -`/301293250` -图像 ID。 + * 当达到规模时，它将在生产中失败。 -`_dc284905d0` -图像“秘密”。 我认为这是为了防止在未首先从 API 获取信息的情况下复制图像。 + * 开发人员已隐式假定某种呼叫不会失败。 -`_m`-图像的尺寸。 在这种情况下，“ m”表示中等，但是可以很小，例如拇指。对于标准图像大小，URL 中没有此格式的大小。 + * 他们假设请求的分配是统一的。 -嗨， -很棒的文章。 -我想看看每个点上不同的“选项”在您面前的位置会很有趣。 然后，简短解释为什么选择某些“答案”可能会很有用。 + * 他们以为不会受到用户的关注。 -再次感谢您的好东西... + * 他们假定所有请求的大小均处于平均水平。 -我们将进行很多更改，以通过实时 BCP 使其更快，以便所有数据中心都可以同时接收对数据层（db，memcache 等）的写操作，即所有活动的对象都不会处于空闲状态 。 + * 他们的两条尾巴都失败了（没有给出解释）。 ->我们将进行很多更改，以使实时 BCP 更快 +## 组织：为开发人员提供不让运营工作积聚的理由 -很有意思，下一次进化就开始了。 我想知道您如何处理复制。 是在事务上下文中在客户端库中还是在后端服务中进行复制？ 似乎您将有一个主动-主动计划，一个人的家庭数据将驻留在哪里，以及您将如何处理来自多个数据中心的更新中的合并数据？ 数据中心是否有足够的能力来处理所有负载，以防万一发生故障？ 您将如何确定数据中心何时瘫痪以及如何在数据中心之间负载均衡流量？ +* 该系统必须设计为不增加运营工作，因为如果开发人员不从事工作，他们将不会那么在意。 -进入多个数据中心是系统复杂度的巨大飞跃。 听到您对这些问题以及您所面临的其他问题的思考会很有趣。 +* **SRE** 的开发预算。 如果您的系统的运营开销很大，那么您获得的开发人员就不会那么多，那么您就无法推广那么多的功能。 -嗯...我不能相信写在 php 上的 flickr ... +* SRE 具有完全不同的命令链。 他们有自己的副总裁，与开发副总裁分开。 这赋予了他们权力和权力。 当生产意味着他们需要拒绝时，它允许他们说不。 一堆不是的传呼猴子。 -托德- +* 当开发人员说他们可以捐赠人数时，SRE 不必接受。 SRE 可以说服务不够重要，请自己继续提供支持。 -首先-很棒的博客！ 很高兴在一个地方看到很多这样的东西。 +* SRE 是一种稀缺资源。 并非 Google 的每个团队都有 SRE。 云确实可以，但是不是每个其他团队，甚至不是云中的每个小服务，都只是重要的。 -关于 Flickr 和 BCP： -BCP 的数据库部分确实很有趣。 在存储和提供照片方面，我们当然已经拥有 BCP（多个数据中心），因此我们可以为 farmX.static.flickr.com 平衡许多不同数据中心之间的流量。 +## 环境：如何使开发人员在生产团队中保持快乐？ -干杯！ +* **至少有 50％的工作需要为项目工作**。 不待命。 不是门票。 不开会。 实际上是在做项目工作。 -好的通道！ -如何理解主-主环复制？ 这个结构是稳定的吗？ 谢谢 +* 如果项目工作量过多，则开发人员会给 SRE 分配更多的人员，或者将额外的工作流交给开发人员团队。 -最大的图片网站？ 不。 -据 TechCrunch 报道，Facebook 拥有 40 亿张照片； flickr 有 20 亿美元。 +* 什么是项目工作？ -每天有 40 亿个查询，并且仍在增长。 建立社区的速度比老牌收集亲朋好友的速度还要快... Flickr 真是一个奇观！ 谢谢，在幕后进行了一次有趣的窥视！ + * 通过切换基础数据库技术来改善服务的延迟。 -我很高兴阅读 Flickr 使用 SystemImager 进行部署。 我是该软件的拥护者-它是简单性和功能性的完美结合。 基于 rsync 或 TFTP / DHCP 等知名工具构建。 我记得在不到一个小时的时间内从头开始安装了约 100 台服务器（为此，我们甚至没有使用 systemimager / flamethrower）。 易于安装且非常灵活（如果您有奇特的硬件，只需自行准备内核或手动修复新节点的安装脚本，SI 对此将非常满意）。 还可以看一下 GUI 监视守护程序/工具（si_monitor / si_monitortk）。 + * 编写自动化以加速部署。 -如何下载图像。 -静态服务器上的 apache 吗？ + * 跨服务的项目。 Google 作为一项内部服务，可以由其他服务（通常由软件 bot）在内部进行查询，如果可以安全地将计算机停机，可以安全地将机架停机或者将数据中心安全地停机，则可以返回 Google ？ -显示您对 php 的了解 +* SRE 是一支志愿军。 没有草稿。 -每天有 40 亿个查询，并且仍在增长。 建立社区的速度比老牌收集亲朋好友的速度还要快... Flickr 真是一个奇观！ 谢谢，在幕后进行了一次有趣的窥视！ + * 您可以随时转入另一个 SRE 团队。 -How to download the images. -An apache on static servers ? + * 您可以随时转移到 dev 中。 -似乎将您的图像存储在数据库中可能会使站点速度变慢。 + * Mission Control 是一个程序，开发人员可以在其中试用 SRE 并查看他们是否喜欢它。 -似乎将您的图像存储在其中？ +* 团队很流畅。 人们来自团队，分享经验，分享观点。 -shows what you know about php +## 预算：您可以支出任意预算的错误预算 -毫无疑问，Flicr 的架构很棒。 只是想说，聪明人可以由 Blitz 更改，有一些比较表 [http://alexeyrybak.com/blitz/blitz_en.html](http://alexeyrybak.com/blitz/blitz_en.html) +* 如果您有 3 个 9 的可用性，目标不是将其提高到 4 个 9，则您有 0.1％的错误预算，请继续努力。 -是否有更简单的解决方案来管理数据库和文件的组合图像？ +* **如果您想更快地推出功能并使 GCP 变得更好，那就去做吧。 直到用尽错误预算。** -很好 +* 如果您希望进行较差的测试，使软件定期出现故障并且必须不断回滚，则也可以选择该选项，但是错误预算很快就会用完，并且您将无法启动 。 -精彩 +* 错误预算按季度循环。 -We are going to change a lot of things, to make it faster with real-time BCP, so all datacenters can receive writes to the datalayer (db, memcache, etc) all at the same time i.e. everything is active nothing will ever be idle. +* 有一个逃生阀：三枚银色子弹。 -本文档确实对希望建立大型站点的新手有所帮助。 + * 一个开发人员可以说我真的需要推动，请给我一个银弹。 -显示您对 php 的了解 + * SRE 会说“ OK”，但您必须说服 VP 您实际需要推动。 -Flickr only store a reference to an image in their databases, the actual file is stored on a separate storage server elsewhere on the network. \ No newline at end of file + * 这个仪式听起来很愚蠢，但功能非常强大。 它将控制权交给开发人员。 他们有 3 个灵丹妙药，由他们的副总裁来决定是否合适。 + +* 错误预算基于每个服务。 因此，如果多个开发团队使用相同的服务，则它们共享相同的预算。 + + * SRE 不在交战的开发团队中间。 他们必须弄清楚如何花费错误预算。 + +* 机外。 如果所有其他方法都失败了，并且开发人员和 SRE 确实不同意，则 SRE 可以派遣开发团队。 + + * 像和睦的离婚。 + + * 这是至关重要的逃生阀门，因此团队在很长一段时间内都不会出现令人讨厌的分歧。 + + * 很少见，但确实发生了。 一个示例场景是，如果团队不想在其 ACID 类型项目中使用 Spanner，如果开发团队说他们想建立自己的团队，那么 SRE 团队可以说他们不想为团队提供支持。 去建立自己的数据库，因为这对生产不利。 + +* SRE 是 google.com 和 GCP 的生产托管人，SRE 是客户体验的托管人。 + +## SRE 支持在频谱上 + +* 聊天和咨询。 与开发人员聊天。 进行白板会议。 + +* 协同设计。 与开发人员一起创建设计。 + +* 完全所有权。 完全拥有的服务。 所有容量，所有供应，所有页面。 + +* 页面是保持诚实的一种方式。 它们不是 SRE 的目的。 + + * 负责制作的人应该拿走页面，因为这样可以使他们的皮肤保持游戏的外观。 + + * 它还有助于使 SRE 的技能，专长和观点保持最新。 + +## 是什么让事情顺利进行？ 文化和过程 + +* Google 会进行常规的培训和通话阴影处理。 + +* Google 也有一个名为：**命运之轮**的过程-卷轴游戏。 + + * 一个人是地牢大师，他们有一个受害者，团队轮流尝试猜测发生了什么。 + + * Google 运行非常复杂的系统。 除了进行培训的人之外，很少有人真正知道发生了什么以及答案是什么。 + + * 对新的来电者来说很好。 让他们在受控环境中进行测试。 + + * 有些团队在某些场景中会破坏生产并让新手修复它。 + + * 对退伍军人也有好处。 最好重新整理您的知识，尤其是在使用非常复杂的系统时。 + +## 事件管理 + +* 场景：您正在呼叫 gmail，并且您获得票证，用户可以看到其他用户的电子邮件。 你是做什么？ 关闭 gmail。 + +* **Oncallers 被完全授权采取一切措施来保护用户，保护信息，保护 Google。** 如果这意味着要关闭 gmail 甚至关闭全部 google.com，那么作为 SRE，您的副总裁将为您提供支持，而您的 SVP 将为保护 Google 提供支持。 + +* **目标是立即恢复服务。 故障排除将在稍后进行。** + + * 有二进制状态的记录。 有日志。 + + * 醒着，开发人员在办公室，所有人都在时，请进行故障排除。 目的是使服务重新启动并运行。 + +## 你该怪谁？ + +* 当“新开发者”推送代码并破坏 google.com 达三个小时时，您应归咎于谁？ a）新开发者 b）代码审查。 c）缺乏测试（或被忽略）的测试。 d）缺乏针对代码的适当的金丝雀程序。 e）缺乏快速回滚工具。 + + * 除了新开发者以外的所有东西。 **如果新开发人员编写的代码会导致网站瘫痪，那不是开发人员的错。 这是开发人员和工作人员之间所有关口的错。** + + * **绝对不允许人为错误传播到人外。** 查看允许部署损坏的代码的过程。 + +## 无罪的岗位形态 + +* 避免责备文化至关重要。 + +* 研究表明，大多数事件是人为错误引起的。 + +* **最好通过了解实际发生的事件来解决事件。** 不知道发生了什么的最好方法？ 通过寻找责任人来揭开每一个事件。 + +* 人们真的很擅长隐藏，并确保没有线索，并确保您实际上不知道发生了什么。 试图找到责任，只会使您的工作更加困难。 + +* 在 Google 谁搞砸了谁写的事后验尸。 这样可以避免命名和遮挡。 使他们有能力纠正错误。 促成失败的每个人都应尽可能诚实地参与进来，并写下您如何陷入困境。 + +* 已在全体会议上给予拆除该站点的奖金，因为他们立即拥有该站点，因此他们拥有了该站点。 他们上了 IRC，并将其回滚。 他们说出来并如此迅速地照顾好他们，便获得了奖金。 + +* 无赖并不意味着没有名称和细节。 这意味着我们不会因为事情出错的原因而选择别人。 不应发生诸如断电之类的事情，应予以解雇。 + +* 深度防御 + + * 由于策略是纵深防御，因此事后评估模板将操作分为预防，检测和缓解措施。 + + * **我们希望防止中断，我们希望更快地检测到它们，并希望减轻影响。** + + * 如果类似的情况再次发生，它将不会传播到很远，持续太久或影响那么多客户。 + +## 分页的无聊哲学 + +* 团队喜欢看什么样的页面？ 新的和有趣的。 + +* 您知道如何解决的页面很无聊。 您应该创建一个机器人来解决该问题。 + +* Google 发明了许多机器人。 他们不喜欢无聊。 + +* 如果您可以写下修复它的步骤，那么您可能可以编写自动化来修复它。 + +* 不要做机器人可以为您做的事情。 + +* 构建机器人的结果是，理想情况下，每个页面都是真正的新页面，因此不会感到无聊。 甚至经验丰富的工程师也可能在每次寻呼机关闭时都看到一些新内容。 + +* **这是哲学的根本变化。 如果一切正常，重复的事件很少，则意味着您在调试系统时不会像以前那样沉迷于此。** + +## 需要更强大的调试工具 + +* **如果所有问题都是新问题，则意味着您需要更强大的调试工具来查找问题。** + +* 文本日志不是调试工具。 如果您不知道要查找的内容，则在日志文件中查找模式的标准调试无法扩展。 使用 GCP 大小的平台，您需要浏览多少个外观才能找到失败的外观？ + +* Google 严重依赖各种可视化工具来解决不熟悉的问题并尽快恢复服务。 + +* 绘图工具：石墨，InfluxDB + Grafana，OpenTSDB。 + + * 这些和其他提到的工具不是 Google 使用的工具，因此不建议使用，但它们是有用工具的开放源代码示例。 + + * 很高兴看到正在发生的一切。 Google 拥有数十亿亿个流程，因此您需要汇总视图才能理解事物。 + + * **Google 在其二进制文件中放置了很多工具。** 在新情况下，您并不总是知道您要寻找的东西。 + +* 创建一个框架，使开发人员可以轻松地插入监视框架。 + +* 大量存储空间专门用于存储监视数据。 + + * **这个想法是您不想在中断期间进行故障排除。 中断仅与恢复服务有关。** + + * 故障排除是您稍后醒来时要执行的操作。 开发人员通常具有很深的系统知识，因此经常参与故障排除过程。 + + * 历史数据必须可用，以便故障恢复后可以进行故障排除。 恢复不会导致中断监视数据丢失。 + + * 这种方法可以使停机时间尽可能短，同时可以在以后解决问题。 + +* 事件绘图-对于关联事件非常有用。 + + * 充分利用人类的模式匹配能力，很难编写机器人来做到这一点。 + + * 给出了一个图表示例，其中每行是一个数据中心，列是时间，单元格中的颜色是事件类型。 + + * 这可以帮助您找到不是单个事件的模式，例如导致级联故障的软件推出，或者一起重复出现的错误簇，或者如果您看到延迟尖峰之后立即出现错误尖峰 重复一遍。 这些都将有助于确定问题的根本原因。 + +* 可视化过程跟踪-有时您需要深入到过程级别以识别性能问题。 + + * 开源选项不多：Performance Co-Pilot + vector。 + + * Google 有一个非常复杂的框架，可将示例查询拉入存储并提供完整的跟踪记录。 + + * 视觉工具的优点是很难理解时间戳。 可视化工具使您可以更轻松地折叠，展开和比较事件。 + +* 网络流量和容量 + + * 开源选项：仙人掌，天文台和 Nagios + + * 事实证明，很多存储缓慢的问题实际上是网络问题。 + + * 如果您正在查看存储系统，但无法弄清为什么它对网络的访问速度很慢。 + + * 您需要一个工具来快速查看网络状态。 哪些链接超载？ 您看到多少个包错误？ 链接断开了吗？ + +* 日志文件-当所有其他失败时 + + * 开源：ElasticSearch + Logstash（+ Kibana） + + * 您不想浏览日志文件。 您需要一个具有更多 SQL 之类的查询的系统，以便您可以挖掘日志。 + + * 日志应易于使用且易于理解。 + +## Stackdriver 错误报告 + +* 如果您想看一下 SRE 所拥有的那种工具的例子，那么请看 [Google Stackdriver 错误报告](https://cloud.google.com/error-reporting/) 。 + + * 这是他们能够用于服务的内部工具。 + + * 通过分析堆栈跟踪将分组错误并进行重复数据删除 + + * 系统了解所使用的通用框架并相应地对错误进行分组。 + +* 该计划将做更多。 Google 内部拥有一套广泛的工具，他们希望向云客户提供这些工具。 + +## 相关文章 [ + +* [在 HackerNews](https://news.ycombinator.com/item?id=12116121) 上/ [在 Reddit](https://www.reddit.com/r/programming/comments/4tg31p/how_does_google_do_planetscale_engineering_for_a/) 上 +* 图书：[网站可靠性工程：Google 如何运行生产系统](https://www.amazon.com/Site-Reliability-Engineering-Production-Systems-ebook/dp/B01DCPXKZ6)。 它是由从事实际 SRE 工作的实际 Google SRE 编写的，是作者 500 年综合经验的结果。 +* [大规模计算，或者说 Google 如何扭曲我的大脑](http://matt-welsh.blogspot.com/2010/10/computing-at-scale-or-how-google-has.html) +* [网站可靠性工程师-使 Google 保持 24/7 全天候运行](http://transcriptvids.com/v2/yXI7r0_J29M.html) +* [服务水平和错误预算](https://www.usenix.org/conference/srecon16/program/presentation/jones) +* [SREcon](https://www.usenix.org/conference/srecon16) 。 会议视频[可用](https://www.usenix.org/conference/srecon16/program)。 看起来内容很多。 +* [小组：谁/什么是 SRE？](https://www.usenix.org/conference/srecon16/program/presentation/definition-of-sre-panel) +* [策略：规划停电的 Google 样式](http://highscalability.com/blog/2010/3/5/strategy-planning-for-a-power-outage-google-style.html) +* [Google 如何备份互联网以及 EB 级其他数据](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html) +* [什么是“网站可靠性工程”？](https://landing.google.com/sre/interview/ben-treynor.html) +* [成为 Google 的网站可靠性工程师（SRE）感觉如何？](https://www.quora.com/What-is-it-like-to-be-a-Site-Reliability-Engineer-SRE-at-Google) +* [我的警惕](https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/preview#)的哲学，作者：Rob Ewaschuk，Google SRE +* [这是 Google 确保（几乎）永不衰败的方式](http://www.wired.com/2016/04/google-ensures-services-almost-never-go/) + +FWIW，Stack Driver 并不是他们能够用于服务的内部工具； 这是 Google 购买的 SaaS 创业公司。 + +https://techcrunch.com/2014/05/07/google-acquires-cloud-monitoring-service-stackdriver/ \ No newline at end of file diff --git a/docs/23.md b/docs/23.md index ecdd2b0..f5c598d 100644 --- a/docs/23.md +++ b/docs/23.md @@ -1,98 +1,58 @@ -# 如今 Etsy 的架构是什么样的？ +# Yandex 架构 -> 原文： [http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html](http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html) +> 原文： [http://highscalability.com/blog/2008/2/24/yandex-architecture.html](http://highscalability.com/blog/2008/2/24/yandex-architecture.html) -![](img/9e364140091b80d83d988a6634e2f7c6.png) +**更新：** [用 Django](http://softwaremaniacs.org/blog/2008/02/24/why-offline-crashed-en/) 编写的 Yandex 新部分崩溃的剖析。 写入魔术会话变量会导致对每个请求的 InnoDB 数据库意外写入。 由于重建索引，写入花费了 6-7 秒。 有关系统大小，出了什么问题以及如何修复它的许多有用的细节。 -*这是 [Christophe Limpalair](https://twitter.com/ScaleYourCode) 的来宾帖子，基于他对 [Jon Cowie](https://twitter.com/jonlives) ，员工运营部所做的[采访](https://scaleyourcode.com/interviews/interview/25)（[视频](https://www.youtube.com/watch?v=3vV4YiqKm1o)） 工程师和 Breaksmith @ Etsy。* +Yandex 是俄罗斯的搜索引擎，其搜索索引为 35 亿页。 我们只知道一些有关它们如何工作的有趣事实，而在详细的体系结构级别则一无所知。 希望我们以后能学到更多，但是我认为这仍然很有趣。 从艾伦·斯特恩（Allen Stern）对 Yandex 首席技术官 Ilya Segalovich 的采访中，我们可以了解到： -随着 Etsy 从新平台过渡到稳定且完善的电子商务引擎，Etsy 成为了一个令人着迷的观看和研究平台。 这种转变需要进行很多文化上的改变，但最终结果却是惊人的。 +* 搜索索引中有 35 亿页。* 超过数千台服务器。* 每天有 3500 万次搜索。* 俄罗斯各地的几个数据中心。* 两层体系结构。* 该数据库被分成几部分，当请求搜索时，它从不同的数据库服务器中提取这些位，并为用户组合在一起。* 使用的语言：C ++，Perl 和一些 Java。* FreeBSD 被用作他们的服务器操作系统。* 2006 年的收入为 7200 万美元。 -如果您还没有看到它，2012 年有一篇[文章](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html)概述了他们的成长和转变。 但是从那以后发生了什么？ 他们还在创新吗？ 如何制定工程决策，这如何影响他们的工程文化？ 这些是我们与 Etsy 的一名运维工程师，定制厨师的作者 Jon Cowie 在新的播客节目中探讨的问题。 +Yandex 不仅仅是搜索引擎。 这是一个门户。 我有一个朋友使用 yandex.ru 电子邮件地址。 -## [](#what-does-etsys-architecture-look-like-nowadays)如今 Etsy 的架构是什么样的？ +哇。 -自上一次更新可追溯到 2012 年以来（在前面提到的帖子中），他们的体系结构并没有真正改变太多。 尽管这听起来有些无聊，但它概述了一个重要的概念，并为我们提供了对 Etsy 的工程文化的一些见识。 在整篇文章中，我们都会回头介绍这种文化，但这是它们的总体架构： +我从未听说过 Yandex，但他们显然在那里做得很认真。 看到成功的事物出自俄罗斯/东欧，总是很酷：那里的顶级开发人员实际上真的非常出色：非常聪明和超强硬。 -Etsy 的生产基础设施全是裸机。 但是，在开发方面，他们可以虚拟化环境。 这为每个开发人员提供了一个代表整个堆栈缩影的虚拟机。 最终，虚拟环境仍在 Etsy 自己的物理硬件上运行。 +是的，Yandex 不仅仅是搜索引擎，它还提供了相当长的服务列表，其中包括电子邮件。 +但是从我的角度来看，他们的服务并没有真正提供具有竞争力的质量水平，尤其是与 Google 服务相比：有时候，我认为 Yandex 搜索引擎不是根据相关性而是根据随机数生成器，邮箱来选择结果 经常被垃圾邮件淹没，等等。 +就我而言，即使考虑到我居住在俄罗斯这一事实，我也更喜欢使用国际服务提供商，但 Yandex 仍然是俄罗斯最大的互联网服务提供商，并且由于一些奇怪的事实，确实有大量的俄罗斯人使用它 原因，例如它们只是“用来在 Yandex 中执行搜索”，或者键入 google.com 而不是 ya.ru 可能太耗时了... -实际的堆栈本身仍然看起来像这样： +Google 的俄文搜索不理想，因为俄文有多种形式的单词。 因此，也请使用俄语进行良好的搜索，您应该非常了解俄语。 现在，谷歌搜索俄语，就好像它是英语一样。 -* 的 Linux -* 阿帕奇 -* 的 MySQL -* 的 PHP -* 缓存层 -* F5 负载平衡器 ++可能是俄罗斯支持其搜索引擎来控制互联网的俄罗斯部分。 -它们具有许多具有不同作业的不同缓存层。 他们大量使用 memcached 缓存数据库对象。 +有俄罗斯搜索引擎 yandex 和 ramber，有俄罗斯汇款网络货币和 yander 钱，有俄罗斯社交网络，当然还有 rutube。 -Etsy 具有面向第三方开发人员的面向公众的 API，并且它们还具有内部 API。 这些 API 有缓存层，因为有些答案不是短暂的。 例如，如果一个答案生存一个小时或更长时间，他们可能会缓存它。 +由于您没有俄语键盘，因此您也无法在浏览器中输入俄语域名。 -当然，它们也大量缓存图像和静态资产。 +（俄语）： +[http://www.seotools.ru/biblioteka-optimizatora/yandeks/arhitektura.html](http://www.seotools.ru/biblioteka-optimizatora/yandeks/arhitektura.html) -Yandex 体系结构（2000） -这里的挑战是缓存失效。 确保您没有向用户提供过时的内容，而是充分利用了缓存以尽可能减少数据库的负载。 另外，请确保您通过将其缓存并靠近最终用户来更快地向用户提供响应。 Etsy 团队还深深地关注着这件事，这可以从其工程博客 CodeasCraft.com 上的定期性能报告中看出。 +[http://www.searchrank.ru/arxitektura-yandeks-poiska/](http://www.searchrank.ru/arxitektura-yandeks-poiska/) （2007） -尽管总体架构几乎相同，但这并不意味着 Etsy 工程师和 Ops 团队一直坐在那里摆弄他们的拇指。 好吧，也许其中一些有，但是我离题了... +来自 HighLoad 2007 会议（俄语）的幻灯片 +[http://www.google.ru/url?sa=t & ct = res & cd = 7 & url = http％3A％ 2F％2Fwww.jug.ru％2Fservlets％2Fimages％2Fmeeting_2007_10_13％2Fyandex-search-arch-posthighload.ppt & ei = guy6R46gB6T8wwH88oHGCg & usg = AFQjCNF7f2AHT-Sy2a2Cy2a2C6Y2a2C2Y2a6C2Y2a6C6a7C7a2C6C6Y2A6C7Y2A6C6Y2A6Y2A6Y2C6Y2E7](http://www.google.ru/url?sa=t&ct=res&cd=7&url=http%3A%2F%2Fwww.jug.ru%2Fservlets%2Fimages%2Fmeeting_2007_10_13%2Fyandex-search-arch-posthighload.ppt&ei=guy6R46gB6T8wwH88oHGCg&usg=AFQjCNF7f_AsyqvkjUGje6aPU0q-IGy-aA&sig2=vhyz3MV66M6p7Dgsk2SfCQ) -## [](#so-what-are-their-ops-challenges-do-they-still-have-to-put-out-fires)那么他们的操作挑战是什么？ 他们还必须灭火吗？ +Google 确实为西里尔语（例如俄语或保加利亚语（我的母语））提供了支持。 也许 Yandex 做得更好。 -我们只是看到他们倾向于在成熟和成熟的技术方面犯错误，因此他们不会花费太多时间扑灭火灾。 新问题往往来自引入新系统。 我敢肯定，你们中的许多人以前都读过这篇文章：您介绍了一个新的系统，该系统在纸上可以解决所有问题。 除非它对您环境中当前的其他组件具有复杂且“不可能”的反应。 因此，您必须找出导致问题的原因以及解决方法。 +该死的验证码区分大小写！ 确实不是一个好选择！ -老实说，如果您从事这一领域，那么您可能会活在当下。 这些有趣的挑战使您抓狂，您真的想弄清楚，以便继续进行下一个挑战。 除非有时花费的时间太长，然后变得很麻烦。 +也许我是在挑选东西，但是“崩溃的解剖”一文的摘要中有两件事。 -大多数公司面临的另一个挑战是试图雇用优秀人才。 您在哪里还能找到优秀的人才？ 如果您正在使用新的“热门功能”，那么可能很难找到该人才，而且价格会昂贵得多。 但是，如果您选择像 PHP 这样成熟的东西，它并不是那么困难。 仍然很难，但是不像为 Scala 找到人那样难。 +他们没有写任何魔术变量。 他们正在修改每个请求上的会话数据（不必要），从而将其保存到 DB。 没什么神奇的。 -到目前为止，已有许多 PHP 工具出现了十年，而语言也是如此。 许多前沿漏洞已被消除。 这意味着更少的难以发现的怪异错误，以及更多的专家可以聘用。 +漫长的索引重建是由于使用了非顺序主键（MD5 哈希）导致的-InnoDB，这意味着它将在每个请求上重建整个事物，从而导致性能下降。 -## [](#does-that-mean-they-never-change-anything-in-their-architecture)这是否表示他们从不更改架构中的任何内容？ +对我来说，这是神奇的，因为很难从代码中推断出后果。 而选择具有如此巨大负面影响的关键价值则是另一大法宝。 通过看那条线，会期望这样的效果吗？ 不是我，这就是为什么魔术突然出现。 -不，绝对不是。 这意味着他们拥有制定使用新技术的决策的明确流程。 +Google does make stemming for cyrillic languages like Russian or Bulgarian (my native tongue). Perhaps Yandex does it better. -他们实际上使用工具来创建“体系结构评论”，支持者在其中输入支持材料和该思想背后的理论。 然后，一个团队将提出一个他们认为适合 Etsy 当前环境的概念。 +由于单一原因，我总是在用俄语搜索时使用 Yandex- **Yandex 会说俄语**，而 Google 不会。 -让我们看一个最近的例子。 他们介绍了 Kafka 用于事件流水线。 为了做到这一点，一个团队提出了一个用例，说明了为什么要使用 Kafka 以及如何解决 Etsy 的实际问题。 然后，他们进行了体系结构审查，高级工程师和所有相关方聚集在一起讨论该提案。 +但是 Google 获得了我所有的英语搜索，因为 Yandex 只是在“英语网”中做得不好。 但是，嘿-他们有一个哥哥可以向他学习，所以也许有一天...;） -它是一种成熟且成熟的技术吗？ +yandex 看起来真的很好，并且我肯定它会在将来对我有用 +谢谢 -它会真正解决问题吗？这是解决问题的最佳方法吗？ - -组件将如何与我们的系统反应？ - -谁来支持这个？ - -一旦回答了这些问题，它们便进入实施阶段。 - -在上线之前，它必须经历另一个称为“可操作性审查”的过程，该过程将验证一切是否就绪。 这包括设置适当的监视和警报，为每个待命人员设置适当的程序，等等。 与该实现有关的每个人都必须参与“什么，何时，如何”。 - -另一个重要的考虑因素是：“我们可以通过在已经拥有的工具上构建它来做到这一点吗？” 稍后，我们将详细介绍。 - -这些是在实施建议的技术之前必须回答的问题。 这种彻底的分析可能需要一些时间，但是对于已建立的电子商务平台而言，正常运行时间至关重要。 - -“我们非常重视站点的正常运行时间，可靠性和总体可操作性。” - -## [](#customizing)自定义 - -我们已经看到了 Etsy 的文化如何促进稳定。 我们尚未讨论的是它如何鼓励定制现有工具。 - -正如我们刚刚看到的那样，定制一个已经在使用中的工具有时更有意义，而不是实施一个新的工具来解决问题。 一个典型的例子是定制 Chef。 乔恩·考伊（Jon Cowie）已成为一些有影响力的厨师定制的一部分，例如[刀叉](https://github.com/jonlives/knife-spork)。 该自定义实际上来自 Etsy 团队试图解决的问题。 当多个开发人员同时对同一 Chef Server 和存储库进行更改时，更改将被覆盖。 Jon 负责这个工具，不仅为一个大型开源社区提供了帮助，而且还解决了 Etsy 的一个关键和局限性问题。 - -这是 Jon 启发编写[定制厨师](http://shop.oreilly.com/product/0636920032984.do)的一部分。 这是他希望自己拥有的书。 - -这也是 Chef 开源文化的一个很好的例子。 乔恩（Jon）强调说，Chef 并非旨在成为“一刀切”的解决方案。 它旨在为人们提供一个工具包，使我们能够解决自己的自动化问题。 Chef 的想法是，用户是他们自己系统的专家。 虽然它不能告诉您该怎么做，但它为您提供了工具，因此您可以自己做出决定，然后告诉您想要什么。 - -当然，这并不是说定制没有自己的问题。 如果自定义某些内容，则必须“拥有它”。 一旦决定开源该工具或自定义工具，它将变得更加复杂。 实际上，Etsy 在决定开放源代码工具后就对此产生了疑问。 他们将开放该工具的源代码，但工程师随后将在本地下载一个版本，为 Etsy 基础结构对其进行编辑，然后再将其推回主存储库。 许多项目只是没有被更新。 - -他们是如何解决的？ 通过适当的程序。 就像想要在系统中引入新技术一样，如果您想在 Etsy 中开源项目，则需要回答有关该项目及其维护方式的一些问题。 - -它也很多都承认哪些项目不再需要维护了。 他们最终完成了多个项目，并明确表示不再进行更新。 这样一来，他们就可以重新组合并专注于内部实际使用的工具。 - -“因此，我们已建立的流程更加适合确保我们只开源自己在生产中积极使用的东西。” - -因为归根结底，如果没有人要维护一种工具，那么它可能不会对整个社区有所帮助。 - -## [](#what-about-you)你呢？ - -您的过程和思维方式有何不同？ 您从 Etsy 的方法中学到了什么吗？ 从他们的工程文化和开放源代码实践怎么样？ - -[关于 HackerNews](https://news.ycombinator.com/item?id=11345723) \ No newline at end of file +关于 Yandex 的相当不错的总结。 老实说，我从来不知道这样的网站是在今天之前退出的。 \ No newline at end of file diff --git a/docs/230.md b/docs/230.md index aac65e7..e15d670 100644 --- a/docs/230.md +++ b/docs/230.md @@ -1,125 +1,105 @@ -# Slashdot Architecture-互联网的老人如何学会扩展 - -> 原文： [http://highscalability.com/blog/2007/11/12/slashdot-architecture-how-the-old-man-of-the-internet-learne.html](http://highscalability.com/blog/2007/11/12/slashdot-architecture-how-the-old-man-of-the-internet-learne.html) - -**Slashdot effect**: overwhelming unprepared sites with an avalanche of reader's clicks after being mentioned on Slashdot. Sure, we now have the "Digg effect" and other hot new stars, but Slashdot was the original. And like many stars from generations past, Slashdot plays the elder statesman's role with with class, dignity, and restraint. Yet with millions and millions of users Slashdot is still box office gold and more than keeps up with the young'ins. And with age comes the wisdom of learning how to handle all those users. Just how does Slashdot scale and what can you learn by going old school? - -Site: http://slashdot.org - -## 信息来源 - -* [Slashdot 的设置，第 1 部分-硬件](http://meta.slashdot.org/article.pl?sid=07/10/18/1641203&tid=124) - * [Slashdot 的设置，第 2 部分，软件](http://meta.slashdot.org/article.pl?sid=07/10/22/145209) - * [Slashdot 第 3 部分的历史-成为公司](http://meta.slashdot.org/article.pl?sid=07/10/17/1412245) - * [Slashdot 的历史第 4 部分-昨天，今天，明天](http://meta.slashdot.org/article.pl?sid=07/10/31/1631213) - - ## 该平台 - - * MySQL - * Linux（CentOS / RHEL） - * 磅 - * Apache - * Perl - * 内存缓存 - * LVS - - ## 统计资料 - - * 从 1999 年开始构建系统。 - * 每月有 550 万用户访问。 - * 每天增加 7,000 条评论。 - * 每天的浏览量超过 900 万。 - * 超过 2100 万条评论。 - * 平均每月带宽使用量约为 40-50 兆位/秒。 - * 对于同一故事[，Kottke.org](http://www.kottke.org/06/01/digg-vs-slashdot) 发现 Slashdot 交付的用户是 Digg 的 4 倍。 因此，Slashdot 还没有死。 - * 摘自 **Slashdot 的历史第 4 部分**：*在[9 月 11 日]，主流新闻网站陷入了困境，尽管我们不得不关闭日志记录功能，但我们还是设法保持运转，在一个站点中共享新闻。 通常很难获得的时间。 那一天，使该站点发生的工程师团队齐心协力，做了不可能的事情，迫使我们有限的小型硬件集群处理的流量可能是正常一天的三倍或四倍。* - - ## 硬件架构 - - * 数据中心的设计与所有其他 SourceForge，Inc.站点相似，并且已证明可以很好地扩展。 - * 两个主动-主动千兆位上行链路。 - * 一对 Cisco 7301 作为网关/边界路由器。 执行一些基本过滤。 过滤是分层的，以分散负载。 - * 铸造厂 BigIron 8000 充当核心交换机/路由器。 - * Foundry FastIron 9604s 用作某些机架的交换机。 - * 一对可机架系统（1U； P4 Xeon 2.66Gz，2G RAM，2x80GB IDE，运行 CentOS 和 LVS）用作负载平衡防火墙，将流量分配到 Web 服务器。 [BIG-IP F5](http://www.f5.com/products/big-ip/) 正在其新数据中心中部署。 - * 所有服务器均至少为 RAID1。 - * 16 个 Web 服务器： - -运行 Red Hat9。 - -带有 2 个 Xeon 2.66Ghz 处理器，2GB RAM 和 2x80GB IDE 硬盘的机架式 1U 服务器。 - -两个提供静态内容：javascript，图像和非登录用户的首页。 - -前四个页面用于登录用户 - -10 个处理注释页面。 - -主机角色根据负载而更改。 - -所有 NFS 挂载均处于只读模式。 - * NFS 服务器是具有 2 个 Xeon 2.4Ghz 处理器，2GB RAM 和 4x36GB 15K RPM SCSI 驱动器的 Rackable 2U。 - * 7 个数据库服务器： - -全部运行 CentOS4。 - -2 个在主-主配置中： - -具有 16GB RAM，4x36GB 15K RPM SCSI 的 Dual Opteron 270， - -一个主服务器 只写数据库。 - -一个主数据库是只读数据库。 - -他们可以随时进行故障转移并切换角色。 - -2 个读取器数据库： - -具有 8GB RAM，4x36GB 15K RPM SCSI 驱动器 - 的 Dual Opteron 270，每个数据库均从一个主数据库进行同步。 - -可以增加更多规模，但目前足够快。 - -3 个其他数据库 - -具有 4GB RAM，8x36GB 10K RPM SCSI 驱动器的 Quad P3 Xeon 700Mhz - -Accesslog 写入器和 accesslog 读取器。 使用单独的数据库是因为审核和统计信息需要大量的 CPU 时间进行计算。 - -搜索数据库。 - - ## 软件架构 - - * 已登录用户和未登录用户的处理方式有所不同。 - -未登录的用户将看到同一页面。 此页面是静态页面，每两分钟更新一次。 - -登录的用户具有无法缓存的自定义选项，因此为这些用户生成页面会占用更多资源。 - * 6 磅服务器（对于 SSL 为 1 磅）用作反向代理： - -如果无法处理请求，则将其转发到 Web 服务器。 - -磅服务器与 Web 服务器在同一台计算机上运行。 - -分发它们是为了实现负载平衡和冗余。 - -SSL 由磅服务器处理，因此 Web 服务器不需要支持 SSL。 - * 16 个 apache Web 服务器（1.3 版）： - -从/ usr / local 挂载软件到只读 NFS 服务器上。 - -图像保持简单。 编译的全部内容是： - -mod_perl - -挥之不去地在交付过程中释放了 RAM。 - -mod_auth_useragent 阻止机器人。 - -1 用于 SSL。 - -2 用于静态（.shtml）请求。 - -4 为动态首页。 - -6 个用于动态评论传递页面（评论，文章，pollBooth.pl）。 - -3 用于所有其他动态脚本（ajax，标签，书签，firehose）。 - * 将 apache 服务器划分为不同角色的原因： - -隔离服务器，以防在特定页面上出现性能问题或 DDoS 攻击。 即使一部分出现故障，系统的其余部分也将起作用。 - -由于效率原因，例如 httpd 级别的缓存和 MaxClients 调整。 可以针对每个角色对 Web 服务器进行不同的调整。 对于动态 Web 服务器，MaxClients 设置为 5-15，对于静态服务器，MaxClients 设置为 25。 瓶颈是 CPU，而不是 RAM，因此，如果不能快速处理请求，那么出了点问题，排队更多的请求将无法帮助 CPU 更快地处理它们。 - * 使用只读安装有助于提高系统的稳定性。 写入/ usr / local 的任务（例如，每秒更新 index.html）在 NFS 服务器上运行。 - * 使用在 DBD :: mysql 和 DBI.pm 之上构建的自己的 SQL API。 - * 通过使用 memcached 缓存用户，故事和评论文本，极大地提高了性能。 - * 大多数数据访问是通过为每种数据类型定制的 get 和 set 方法以及执行一个特定更新或选择的方法进行的。 - * 多主复制体系结构即使在阻止查询（如 ALTER TABLE）期间也可以保持站点完全正常运行。 - * [多遍日志处理](http://slashdot.org/journal.pl?op=display&nick=jamie&uid=78724&id=93006&)用于检测滥用情况并挑选哪些用户获得了 Mod 积分。 - * 创建了针对垃圾邮件的审核系统。 起初只是几个朋友，然后是很多朋友。 这没有扩展。 因此，引入了“ mod points”系统，以便对系统做出贡献的任何用户都可以审核该系统。 - * 禁止活动用户防止机器人过度使用。 - - ## 得到教训 - - * 最富创造力的时期是资金紧缺，团队规模很小，每个人都在帮助其他人做任何需要做的事情。 - * 不要浪费时间优化代码，因为您太便宜了，无法购买更多机器。 购买硬件并花时间在功能上。 - * 卖给一家大公司，您将失去控制。 不断面临着去开发新产品，融合广告商提供的内容以及投放大型广告的阴暗面的压力。 - * 对希望您变得像其他所有人一样的力量说不。 尽管许多竞争对手来来去去，但 Slashdot 仍然存在，因为他们：*继续保持编辑独立性，适度的广告数量，广告和内容之间有明显的区别，当然，我们继续选择合适的故事来吸引人们 给我们现有的听众...不要花我们的时间去吸引其他听众，这些听众只会淡化讨论，从而使日复一日的你们中的许多人到来。* - * 将服务器隔离到不同的策略域中，以便您可以优化它们的配置。 - * 优化通常意味着缓存，缓存，缓存。 - * 表不完整，但大多已归一化。 在大多数情况下，这可以提高性能。 - * 在过去的七年中，开发数据库支持的网站的过程发生了变化：*数据库曾经是瓶颈：集中化，难以扩展，运行缓慢。 现在，如果您进行防御性编码，那么即使是便宜的 DB 服务器也可以运行一个相当大的站点，并且由于摩尔定律，内存缓存和开源数据库软件的改进，在您不进行扩展的情况下，扩展问题才真正成为问题。 实际上是 eBay 的大小。 这是编写 Web 应用程序的激动人心的时刻。* - -“对于动态 Web 服务器，MaxClients 设置为 5-15，对于静态服务器，MaxClients 设置为 25。” - -只有 15 点？ 我们在每个 Apache 上有 256 个（1u 服务器 2xOpteron 双核 4GB RAM），并使用 PHP 提供 9-10 倍的页面 - -取决于 apache 进程在做什么。例如，它们可以等待 SQl 结果。因此，最好等待更多的进程。 他们也在等待客户端获取所有发送的数据-速度较慢的客户端，需要更多进程来保持 CPU 利用率。 -但是 AFAIK slashdot 使用的是反向代理，到 apache 仅以全 CPU 速度运行 PHP 代码，并立即将数据返回给代理。 代理然后等待慢速客户端... - -Slashdot 不使用 PHP，而是使用 mod_perl。 - -他们如何将 NFS 只读安装在 Web 服务器上并仍然写入其中？ 他们是否首先从 Web 服务器到 NFS 服务器使用 ssh？ -谢谢， \ No newline at end of file +# 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事，以及 Tarantool 与此相关的内容 + +> 原文： [http://highscalability.com/blog/2016/8/30/the-cat-and-mouse-story-of-implementing-anti-spam-for-mailru.html](http://highscalability.com/blog/2016/8/30/the-cat-and-mouse-story-of-implementing-anti-spam-for-mailru.html) + +![](img/1295631a0c5a13e4ec2d6e35538297c0.png) + +大家好！ + +在本文中，我想向您介绍一个为 Mail.Ru Group 的电子邮件服务实现反垃圾邮件系统的故事，并分享我们在此项目中使用 [Tarantool](https://tarantool.org/) 数据库的经验：Tarantool 的任务是什么 ，我们面临的局限性和整合问题，陷入的陷阱以及我们最终如何得到启示。 + +让我从简短的回溯开始。 大约十年前，我们开始为电子邮件服务引入反垃圾邮件。 我们的第一个过滤解决方案是卡巴斯基反垃圾邮件和 RBL（*实时黑洞列表-*是与垃圾邮件发送有关的 IP 地址的实时列表）。 这样可以减少垃圾邮件的发送，但是由于系统的惯性，我们无法足够快地（即实时）抑制垃圾邮件的邮寄。 另一个未满足的要求是速度：用户应该以最小的延迟接收经过验证的电子邮件，但是集成解决方案的速度还不足以赶上垃圾邮件发送者。 垃圾邮件发件人发现垃圾邮件未送达时，他们会很快更改其行为模型和垃圾邮件内容的外观。 因此，我们无法忍受系统的惯性，而是开始开发自己的垃圾邮件过滤器。 + +我们的第二个系统是 MRASD-Mail.Ru 反垃圾邮件守护程序。 实际上，这是一个非常简单的解决方案。 客户的电子邮件到达 [Exim](http://www.exim.org) 邮件服务器，并通过充当主要过滤器的 RBL 到达，然后到达 MRASD，在那里发生了所有不可思议的事情。 反垃圾邮件守护程序将邮件分解为几部分：标头和正文。 然后，它使用基本算法对每个片段进行归一化，例如对字符大小写进行归一化（全部以小写或大写形式），将外观相似的符号转换为特定形式（例如，使用一个符号表示俄语和英语“ O”）等 标准化后，守护程序提取了所谓的“实体”或电子邮件签名。 我们的垃圾邮件过滤器会分析电子邮件的不同部分，并在发现任何可疑内容时将其阻止。 例如，我们可以为“ viagra”一词定义一个签名，所有包含该词的消息都会被阻止。 实体也可以是 URL，图像，附件等。 在反垃圾邮件检查过程中完成的另一件事是为已验证的电子邮件计算指纹。 计算为少数棘手的哈希函数的指纹是邮件的独特特征。 基于计算的哈希值和收集的哈希统计信息，反垃圾邮件系统可以将邮件过滤为垃圾邮件或让其通过。 当哈希值或实体达到某个频率阈值时，服务器开始阻止所有匹配的电子邮件。 为此，我们维护了统计数据（计数器）来跟踪遇到某个实体的频率，接收者抱怨该实体的频率，并设置了一个实体标志 SPAM / HAM（在与垃圾邮件相关的术语中，“ ham”与“ 垃圾邮件”，表示经过验证的电子邮件不包含垃圾内容。 + +MRASD 的核心部分是使用 C ++实现的，而其相当多的业务逻辑是使用解释性语言 Lua 来实现的。 正如我已经说过的那样，垃圾邮件发送者是非常有活力的人，他们会很快改变其行为。 我们的目标是对垃圾邮件发送者方面的每项更改做出快速响应，这就是为什么我们使用解释性语言实施业务逻辑的原因（对于 Lua，我们不必每次都在所有服务器上重新编译系统并进行更新）。 另一个要求是速度：Lua 中的代码在性能测试中显示出良好的结果。 最后，很容易与 C ++中的代码集成。 + +![](img/0e0752752d353aa16839d288763f4911.png) + +上面的方案说明了我们的反垃圾邮件过滤器的简化工作流程：电子邮件从发件人发送到我们的邮件服务器； 如果该消息已成功通过主过滤器（1），则它进一步进入 MRASD（2）。 MRASD 将其检查结果返回到邮件服务器（3），并根据这些结果将邮件传递到收件人的“垃圾邮件”文件夹或收件箱中。 + +MRASD 允许我们将未过滤的垃圾邮件数量减少十倍。 随着时间的流逝，我们不断改进系统：添加了新的子系统和组件，引入了新的工具。 因此，系统不断发展，变得更加复杂，反垃圾邮件任务也变得更加多样化。 这些变化无助于影响我们的技术堆栈。 这就是本故事的下一部分。 + +**技术堆栈的演进** + +在电子邮件服务时代的曙光中，消息流以及消息内容比今天明显稀缺。 但是工具和计算能力的选择也较差。 从上面描述的 MRASD 的“父母”模型可以看出，有必要存储各种统计数据。 这些数据的相当一部分是“热”的（即经常使用），这对数据存储系统提出了某些要求。 结果，我们选择了 MySQL 作为“冷”数据的存储系统，但对于“热”统计数据仍然不确定。 我们分析了所有可能的解决方案（它们的性能和功能适用于“热”数据，但不适用于关键任务数据），最终到达 [Memcached](https://memcached.org/) -那时，此解决方案已经足够稳定。 但是我们在存储“热”和关键数据方面仍然存在问题。 与任何其他缓存解决方案一样，Memcached 也有其局限性，包括不进行复制以及缓存关闭（并刷新）后的长时间预热时间。 我们的进一步搜索将我们带到了[京都内阁](http://fallabs.com/kyotocabinet/)，这是一个非关系键值数据库系统。 + +时间过去了，电子邮件工作量增加了，反垃圾邮件工作量也增加了。 出现了需要存储更多数据的新服务（Hadoop，Hypertable）。 顺便说一句，当今的高峰处理工作量达到每分钟 55 万封电子邮件（如果我们每天计算平均值，则每分钟约有 35 万封电子邮件），每天要分析的日志文件量超过 10 TB。 让我们回到过去：尽管工作量不断增加，但我们对数据处理（加载，保存）的要求却保持不变。 有一天，我们意识到京都议定书无法管理所需的数据量。 此外，我们需要一种存储系统，它具有针对“热”和关键数据的更广泛功能。 也就是说，是时候到处寻找更好的替代方案了，这些替代方案将更灵活，更易于使用，并具有更高的性能和故障转移功能。 那时，一个名为 Tarantool 的 NoSQL 数据库在我们公司中获得了普及。 Tarantool 是公司内部开发的，完全满足了我们的“ wannas”。 顺便说一句，我最近一直在修改我们的服务，当我遇到最早的 Tarantool 版本之一时 [Tarantool / Silverbox](http://www.slideshare.net/fuenteovehuna/tarantool-silverbox) ，我感到自己是一名考古学家。 我们决定尝试一下 Tarantool，因为它的基准测试涵盖了我们所需的数据量（我当时没有确切的工作量数据），并且也满足了我们对内存使用的要求。 另一个重要因素是项目团队位于隔壁，我们可以使用 JIRA 快速提出功能请求。 我们是决定在他们的项目中尝试使用 Tarantool 的先驱者之一，我认为我们向 Tarantool 迈出的第一步受到了其他先驱者的积极经验的鼓舞。 + +那就是我们的“ Tarantool 时代”开始的时候。 我们积极地将 Tarantool 引入到我们的反垃圾邮件体系结构中。 今天，我们有了基于 Tarantool 的队列，用于存储各种统计数据的高工作量服务：用户信誉，发件人 IP 信誉，用户可信度（“业力”统计信息）等。我们目前的活动是将升级的数据存储系统集成到我们的 实体统计处理器。 您可能想知道为什么我们只针对我们的反垃圾邮件项目专注于一个数据库解决方案，而不考虑迁移到其他存储。 嗯，事实并非如此。 我们也考虑和分析竞争系统，但是暂时，Tarantool 可以很好地处理项目中所需的所有任务和工作负载。 引入新的（未知的，以前未使用的）系统总是有风险的，并且会花费大量时间和资源。 同时，Tarantool 是我们（以及许多其他项目）的知名工具。 我们的开发人员和系统管理员已经了解使用和配置 Tarantool 的所有知识，以及如何充分利用它。 另一个优势是 Tarantool 的开发团队不断改进其产品并提供良好的支持（这些人正在隔壁工作，这很不错:)）。 当我们仍在实施另一个基于 Tarantool 的解决方案时，我们获得了所有必要的帮助和支持（我稍后会告诉您）。 + +接下来，我将为您概述我们的反垃圾邮件项目中使用 Tarantool 的几个系统，这些系统将涉及我们面临的问题。 + +**我们使用 Tarantool** 的系统概述 + +**业力** + +**业力**是一个数字值，表示用户的信任度。 它最初是为不需要复杂的依赖系统的用户提供的通用“胡萝卜和棍子”系统的基础。 业力是基于从其他用户信誉系统接收到的数据的汇总值。 业力系统背后的想法很简单：每个用户都有其业力-越高，我们对这个用户的信任就越高； 越低，我们在反垃圾邮件检查期间评估他们的电子邮件时就越严格。 例如，如果发件人发送的电子邮件中包含可疑内容，并且发件人的业障评分很高，则此类邮件会打入收件人的收件箱。 较低的业障评级将是反垃圾邮件系统的悲观因素。 这个系统使我想到了老师在学校考试中查阅的一本考勤书。 参加所有班级的学生只会得到几个额外的问题，然后去度假，而错过许多班级的学生则必须回答很多问题才能获得高分。 + +![](img/7bf90374f27a6f0f5e8309a6c0d7f616.png) + +用于存储与业力相关的数据的 Tarantool 在单个服务器上工作。 下图说明了每分钟一个这样的实例执行的请求数。 + +![](img/98697072a85fdef53622b857c064baf5.png) + +**RepIP / RepUser** + +**RepIP** 和 **RepUser** （信誉 IP 和信誉用户）是一种高工作负载服务，用于处理与具有特定 IP 以及与发送者（用户）的活动和动作有关的统计信息 与用户在一段时间内使用电子邮件服务的强度有关的统计信息。 该系统使我们知道用户已发送了多少电子邮件，其中有多少已被阅读，以及有多少被标记为垃圾邮件。 该系统的优势在于，它提供了时间轴，而不是用户活动的快照。 为什么这对于行为分析很重要？ 想象一下，您在没有任何交流的情况下搬到了国外，而您的所有朋友都留在家里。 然后，几年后，您的小屋里有了网线。 哇！ 您浏览到自己喜欢的社交网络的网站，然后看到朋友的照片-嗯，他已经改变了很多……您可以从该照片中获得多少信息？ 我想不是太多。 现在想象一下，您观看了一个视频，该视频显示了您的朋友变迁，结婚等等……-那是一段简短的传记片段。 我敢打赌，在第二种情况下，您会更好地了解朋友的生活。 数据分析也是如此：我们拥有的信息越多，我们就可以更好地评估用户的行为。 我们可以注意到发件人的邮件活动趋势，了解发件人的习惯。 根据这种统计信息，为每个用户和 IP 地址分配“信任等级分数”和一个特殊标志。 此标志用于主要过滤器中，该过滤器甚至可以在垃圾邮件到达我们的邮件服务器之前过滤掉多达 70％的垃圾邮件。 这个百分比说明信誉服务的重要性。 这就是为什么此服务需要最大的性能和容错能力的原因。 这就是为什么我们在这里使用 Tarantool 的原因。 + +![](img/51db83a4a247d755fc55d4a15b7e2177.png) + +信誉统计信息存储在两台服务器上，每台服务器有四个 Tarantool 实例。 下图说明了每分钟 RepIP 请求的平均数量。 + +![](img/83d0a0db50b56264fc18f1a63bc54062.png) + +在实施信誉服务时，Tarantool 遇到了许多配置问题。 与我们之前讨论的系统不同，RepIP / RepUser 的数据包更大：这里的平均包大小为 471,97 字节（最大大小为 16 KB）。 从逻辑上讲，数据包包括两个部分：一个小的“基本”部分（标志，汇总统计信息）和一个很大的统计部分（详细的按动作统计信息）。 对整个数据包进行寻址会导致大量的网络使用，因此加载和保存记录会花费更多时间。 许多系统仅需要数据包的基本部分，但是如何将其从元组中剥离（“元组”是 Tarantool 的记录术语）？ 这是存储过程很方便的地方。 我们在 Tarantool 的 **init.lua** 文件中添加了所需的函数，并从客户端对其进行了调用（从 Tarantool 1.6 版开始，您可以使用纯 C 语言编写存储过程）。 + +**1.5.20 之前的 Tarantool 版本存在问题** + +说我们从未遇到过 Tarantool 问题是错误的。 是的，我们有一些。 例如，在计划的重新启动后，Tarantool 客户端（超过 500 个）由于超时而无法重新连接。 当出现故障后，下次尝试重新连接的尝试被延迟了一段时间后，我们尝试引入渐进式超时，但这无济于事。 我们发现，问题在于 Tarantool 在其事件循环的每个周期内仅接受一个连接请求，尽管有数百个请求在等待。 我们有两种选择：安装新的 Tarantool 版本（1.5.20 或更高版本）或修改 Tarantool 的配置（禁用 *io_collect_interval* 选项可以解决此问题）。 Tarantool 开发人员很快修复了此错误，因此 Tarantool 1.6 或 1.7 将不会提供它。 + +**RepEntity-实体信誉** + +当前，我们正在集成一个用于存储实体统计信息（URL，图像，附件等）的新组件。 **RepEntity** 。 RepEntity 的目的类似于已经讨论的 RepIP / RepUser 的目的：它提供有关实体行为的详细信息，这是我们的反垃圾邮件过滤器的决策标准。 借助 RepEntity 统计信息，我们可以根据电子邮件的实体过滤出垃圾邮件。 例如，邮件可能包含可疑的 URL（例如，其中可能包含垃圾内容或导致[网络钓鱼](https://en.wikipedia.org/wiki/Phishing)网站），而 RepEntity 可以帮助我们更快地注意到和阻止此类邮件。 怎么样？ 我们可以看到该 URL 的动态发送，并且可以检测到其行为的变化，这对于“固定”计数器是不可能的。 + +除了不同的数据包格式外，RepEntity 和 RepIP 系统之间的基本区别是 RepEntity 在我们的服务上产生了明显更高的工作负载（处理和存储的数据量更大，请求数量也更多）。 一封电子邮件最多可以包含一百个实体（最多 10 个 IP 地址），对于这些实体中的大多数，我们必须加载并保存完整的统计信息包。 值得注意的是，数据包由特殊的聚合器保存，该聚合器首先等待累积足够的统计信息。 因此，所有这些都意味着数据库系统要承担更多的工作量，并且需要准确的设计和实现。 **让我强调一下，由于某些项目限制，对于 RepEntity，我们使用了 Tarantool 1.5（因此，我将继续撰写此版本）。** + +首先，我们估计了存储所有统计信息所需的内存量。 为了更好地说明此任务的重要性，让我带来一些数字：在预期的工作量下，将数据包增加 1 个字节意味着将数据总量增加 1 GB。 如您所见，我们的任务是以最紧凑的方式将数据存储在一个元组中（正如我已经说过的，我们无法将整个数据包存储在一个元组中，因为我们经常要求仅检索一部分数据包数据） 。 要计算要存储在 Tarantool 中的数据量，我们还需要考虑： + +* 存储索引的额外空间 +* 在元组中存储数据大小的额外空间（1 个字节） +* 最大元组大小的限制为 1 MB（对于 1.7 版，请参见 [http://tarantool.org/doc/book/box/limitations.html](http://tarantool.org/doc/book/box/limitations.html) ） + +Tarantool 增加了各种请求（读取，插入，删除）的数量，从而产生超时错误。 我们的调查表明，在频繁插入和删除的情况下，Tarantool 启动了一个复杂的树重新平衡过程（我们所有的索引都是 TREE 类型的）。 Tarantool 中的树索引具有棘手的自平衡逻辑，只有在满足某些“不平衡”条件时才会启动。 因此，当一棵树“失去足够的平衡”时，Tarantool 启动了重新平衡过程，这使得 Tarantool 变得口吃。 在日志中，我们发现消息*资源暂时不可用（errno：11）*在几秒钟后消失了。 但是，尽管发生了这些错误，客户端仍无法获取请求的数据。 Tarantool 团队的同事提出了一个解决方案：尝试使用其他类型的树索引 AVLTREE，该索引在每次插入/删除/更改时都会重新平衡。 实际上，尽管重新平衡呼叫的数量有所增加，但其总成本却更低。 在更新架构并重新启动数据库之后，该问题永远消失了。 + +我们面临的另一个问题是清理过时的记录。 不幸的是，Tarantool（据我所知，对于 1.7 版也是如此）不允许为某个记录定义 TTL（生存时间），而忘记了它，而所有清理活动都委托给了数据库。 好了，您仍然可以自己使用 Lua 和 [box.fiber](http://stable.tarantool.org/doc/mpage/stored-procedures.html#sp-box-fiber) 实现所需的清理逻辑。 从好的方面来说，这提供了更大的灵活性：您可以定义复杂的清除条件，而不仅仅是基于 TTL 的条件。 但是，要正确实现清除逻辑，您需要注意一些细微差别。 我实施的第一根清洁纤维使 Tarantool 的速度非常慢。 事实是，我们可以删除的数据量大大少于记录的总数。 为了减少要删除的记录候选者的数量，我引入了基于所需字段的二级索引。 之后，我实现了一个遍历所有候选对象的光纤（其上次修改的时间戳早于指示的时间戳），检查了其他清除条件（例如，当前是否为记录设置了“正在进行写入”标志），并且 如果满足所有条件，则光纤会删除该记录。 当我在零工作负载下测试逻辑时，一切工作正常。 在低工作量的情况下也很好。 但是当我将工作量增加到预期水平的一半时，我遇到了问题。 我的请求开始失败，并显示超时错误。 我知道我一定已经溜了。 当我深入研究这个问题时，我意识到我对光纤的工作方式有一个错误的认识。 在我的世界中，光纤是一个独立的线程，对接收和处理客户端请求没有任何影响（上下文切换除外）。 但是不久，我发现我的光纤使用了与请求处理线程相同的事件循环。 这样，我在一个循环中遍历大量记录，而又不删除任何内容，只是阻塞了事件循环，因此未处理客户端请求。 为什么提到删除操作？ 您会看到，每次删除某些记录时，都会发生一次 yield 操作，该操作解除了事件循环的阻塞并允许处理下一个事件。 在这一点上，我得出的结论是，如果执行了一些 N 操作（其中 N 是一个经验推导的值，我取 N = 100）而没有产生屈服，则有必要强制屈服（例如，使用 *wrap.sleep（ 0）*）。 要记住的另一件事是，记录删除可能会触发索引更新，因此在遍历记录时我可能会丢失一些要删除的数据。 这是另一个解决方案。 在一个周期中，我可以选择一小部分元素（小于 1000 个）并遍历这些元素，删除需要的元素，并跟踪最后一个未删除的元素。 在下一次迭代中，我将从最后一个未删除的元素中选择另外一小部分元素。 + +我们也尝试过实施一种解决方案，该解决方案将来可以平滑地进行分片，但是此尝试失败了：实现的机制开销太大，因此我们暂时放弃了分片。 希望我们可以在较新的 Tarantool 版本中找到重新分片功能。 + +这是一些性能提示。 + +要提高 Tarantool 的性能，您可以禁用* .xlog 文件。 但是请记住，在这种情况下，Tarantool 仅作为高速缓存工作，并具有所有的限制（我的意思是没有复制，重新启动后需要很长的预热时间）。 这里的解决方法是不时制作快照，并在需要时使用它来还原数据。 + +如果一台计算机上有多个 Tarantool 实例，则可以将每个实例“精确定位”到某个 CPU 内核以提高性能。 但是，如果您说 12 个物理内核，那么开始 12 个实例就不好了，因为每个 Tarantool 实例连同执行线程也都有一个 WAL 线程。 + +所需功能： + +* 分片。 +* 基于集群的方法，可以进行动态集群配置，例如在添加节点或节点出现故障的情况下派上用场，类似于 MongoDB（mongos）和 Redis（redis sentinel）。 +* 可以为记录清除定义 TTL（生存时间）。 + +**的结论** + +Tarantool 是我们反垃圾邮件系统的基石，我们许多重要的高工作量服务都基于此。 现成的[连接器](http://stable.tarantool.org/doc/mpage/connectors.html)使轻松将 Tarantool 与使用不同编程语言实现的组件集成在一起成为可能。 Tarantool 的成功历史悠久：多年来，在我们的反垃圾邮件项目中使用 Tarantool 以来，我们在操作或稳定性方面都没有遇到严重问题。 但是要充分利用该数据库，您需要考虑一些配置上的细微差别（在这里，我们一直在谈论 Tarantool 1.5 版的细微差别）。 + +关于我们未来计划的几句话： + +* 在我们的项目中增加基于 Tarantool 的服务的数量。 +* 迁移到 Tarantool 1.7。 +* 开始使用 Vinyl 引擎，尤其是对于 RepEntity，那里的真正“热”数据量并不大。 + +[关于 HackerNews](https://news.ycombinator.com/item?id=12397570) + +保存 + +反垃圾邮件系统内部邮件处理的平均延迟是多少？ 是否有关于典型请求分解的任何分析信息？ \ No newline at end of file diff --git a/docs/231.md b/docs/231.md index e06484c..b264bde 100644 --- a/docs/231.md +++ b/docs/231.md @@ -1,78 +1,239 @@ -# Feedblendr 架构-使用 EC2 进行扩展 +# The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购 -> 原文： [http://highscalability.com/blog/2007/10/30/feedblendr-architecture-using-ec2-to-scale.html](http://highscalability.com/blog/2007/10/30/feedblendr-architecture-using-ec2-to-scale.html) +> 原文： [http://highscalability.com/blog/2016/9/13/the-dollar-shave-club-architecture-unilever-bought-for-1-bil.html](http://highscalability.com/blog/2016/9/13/the-dollar-shave-club-architecture-unilever-bought-for-1-bil.html) -一个男人做了一个梦。 他的梦想是将一堆 RSS / Atom / RDF 提要混合到一个提要中。 这个人是 [Feedville](http://feedville.com/) 的 Beau Lebens，并且像大多数梦想家一样，他的硬币有些短缺。 因此，他在廉价的托管服务提供商的家中避难，而 Beau 实现了他的梦想，创建了 [FEEDblendr](http://feedblendr.com/) 。 但是 FEEDblendr 消耗了太多 CPU 来创建混合供稿，以至于廉价的托管服务提供商命令 Beau 来寻找另一个家。 博去哪儿了？ 他最终在亚马逊 EC2 的虚拟机室内找到了一个新家。 这是关于 Beau 最终如何能够在负担得起的 CPU 周期的摇篮中安全地创建自己的供稿的故事。 +![](img/5b7af8042fb8d87998d9de26b181d823.png) -网站：http：//feedblendr.com/ +*这是 [Jason Bosco](https://www.linkedin.com/in/jasonbosco) ， [Dollar Shave Club [ HTG12 的核心平台&基础架构工程总监，介绍其电子商务技术的基础架构。](https://www.dollarshaveclub.com/)* -## 该平台 +Dollar Shave Club 拥有 300 万以上的会员，今年的收入将超过 2 亿美元。 尽管大多数人都熟悉该公司的市场营销，但是自成立以来短短几年内的巨大增长主要归功于其 45 名工程师的团队。 -* EC2（Fedora Core 6 Lite 发行版）* S3* 阿帕奇* 的 PHP* 的 MySQL* DynDNS (for round robin DNS) +Dollar Shave Club 工程学的数字： - ## 统计资料 +## 核心统计信息 - * Beau 是具有一些系统管理员技能的开发人员，而不是 Web 服务器管理员，因此创建 FEEDblendr 涉及很多学习。* FEEDblendr 使用 2 个 EC2 实例。 两个实例都使用相同的 Amazon 实例（AMI）。* 已经创建了 10,000 多个混合，其中包含 45,000 多个源 feed。* 每天大约创建 30 个混合。 实际上，这两个实例上的处理器被钉得很高（大部分时间的平均负载为 10 到 20）。 +* 超级碗广告的投放没有停机时间：1 - ## 架构 +* 每月流量带宽：9 TB - * 轮询 DNS 用于在实例之间进行负载平衡。 - -手动更新 DNS，因为在更新 DNS 之前验证实例可以正常工作。 - -实例现在看起来比以前更稳定，但是您仍然必须假设它们随时都可能丢失，并且两次重启之间不会保留任何数据。* 由于 EC2 没有像样的持久性存储系统，因此数据库仍托管在外部服务上。* AMI 保持最小。 这是一个干净的实例，带有一些自动部署代码，可从 S3 加载应用程序。 这意味着您不必为每个软件版本创建新实例。* 部署过程为： - -软件是在笔记本电脑上开发的，并存储在 Subversion 中。 - -Makefile 用于获取修订，修复权限等，打包并推送到 S3。 - -AMI 启动时，它将运行脚本以从 S3 获取软件包。 - -打开包装包，并执行其中的特定脚本以继续安装过程。 - -Apache，PHP 等的配置文件已更新。 - -固定了服务器特定的权限，符号链接等。 - -Apache 重新启动，并使用该计算机的 IP 发送电子邮件。 然后使用新的 IP 地址手动更新 DNS。* 提要独立于每个实例进行智能缓存。 这是为了尽可能减少对饲料的昂贵轮询。 尝试将 S3 作为两个实例的通用提要缓存，但是速度太慢。 也许可以将提要写入每个实例，以便将它们缓存在每台计算机上？ +* 通过 Arm 处理的订单：3800 万张订单 - ## 学过的知识 +* 发现的错误总数：4,566 - * 低预算的启动可以使用 EC2 和 S3 有效地引导。* 对于精打细算的人，免费的 ZoneEdit 服务可能与每年 50 美元的 DynDNS 服务（效果很好）一样好。* 循环负载平衡缓慢且不可靠。 即使 DNS 的 TTL 较短，某些系统仍会长时间使用寻址的 IP，因此新计算机无法实现负载平衡。* RSS 实施存在许多问题，无法有效地合并摘要。 因为没有可靠的交叉实现方式来判断提要何时真正更改，所以不必要地花费大量 CPU 读取和混合提要。* 考虑到实例可以随时消失，这确实是一个很大的观念转变。 您必须更改您的架构和设计以适应这一事实。 但是，一旦将此模型内部化，就可以解决大多数问题。* EC2 较差的负载平衡和持久性功能使开发和部署变得异常困难。* 使用 AMI 的能力来传递参数，以选择要从 S3 加载的配置。 这样，您就可以测试不同的配置，而无需移动/删除当前活动的配置。* 创建一个自动化测试系统以在实例启动时对其进行验证。 如果测试通过，则自动更新 DNS。 这使得创建新实例变得容易，并且使慢速人员脱离了循环。* 始终从 S3 加载软件。 您想要发生的最后一件事是实例加载，由于某种原因无法联系您的 SVN 服务器，因此无法正确加载。 将其放在 S3 中实际上消除了这种情况的发生，因为它在同一网络上。 +* 自动化测试成绩：312,000 - ## 相关文章 +* 通过语音发送的电子邮件：1.95 亿封电子邮件 - * [什么是“新闻河”风格的聚合器？](http://www.reallysimplesyndication.com/riverOfNews)* [使用亚马逊服务以 100 美元的价格构建无限可扩展的基础架构](http://highscalability.com/build-infinitely-scalable-infrastructure-100-using-amazon-services) +* 处理并存储在海马中的 Analytics（分析）数据点：5.34 亿 -我可能会缺少一些东西，但我看不出这是“使用 EC2 进行扩展”的有趣示例。 +* 海马中的数据集大小：1.5TB -在 Beau 使用 EC2 的方式使用 EC2 和从正常提供商设置两个租用服务器之间似乎没有什么区别。 实际上，获得租用服务器可能会更好，因为成本可能更低（EC2 实例的成本为每月 72 美元/月+带宽），并且数据库将位于同一网络上。 +* 当前已部署的应用程序/服务：22 -Beau 似乎没有做任何利用 EC2 的事情，例如根据需求动态创建和丢弃实例。 +* 服务器数量：325 -我在这里想念什么吗？ 这是使用 EC2 进行扩展的有趣用法吗？ +## 技术堆栈 ->我可能缺少一些东西，但是我看不出这是“使用 EC2 进行缩放”的有趣示例。 +* 前端框架的 Ember -我承认在发现有趣的事情上有些变态，但从博人的立场（这是很多人的观点）来看，这部戏令人激动。 故事始于冲突：如何实现这个想法？ 第一种选择是传统的廉价主机选择。 长期以来，故事的结局已经到了。 具有高端 CPU，RAM 和持久存储的专用服务器仍然不便宜。 因此，如果您不赚钱，那将是故事的结局。 通过添加越来越多的专用服务器进行扩展是不可能的。 希望新的网格模型将使很多人继续写自己的故事。 他创建系统的学习曲线是最有趣的。 弄清楚如何进行设置，负载均衡，软件加载，测试，常规的螺母和螺栓开发工作。 这样一来，他就可以在需要的时候立即获得更多的 CPU。 他已经可以进行基础工作，因此能够快速添加该功能。 但是现在它运行良好。 计划中的扳手是数据库，它指出了 EC2 的致命缺陷，即数据库。 如果该部分工作得更好，则该计划看起来会更成功，但事实并非如此，这也很有趣。 +* 主要在后端上使用 Ruby on Rails -@Todd，感谢您的撰写，并进行了一些快速更正/澄清： +* 用于高吞吐量后台处理需求的 Node.js（例如：在语音中） --“ Beau 是具有某些 sysadmin 技能的开发人员，而不是 Web 服务器管理员，因此在创建 FEEDblendr 时需要进行很多学习。” -需要明确的是，学习曲线主要是在处理 EC2 及其工作原理，而不是 FeedBlendr，它的核心是相对简单的。 +* 用于基础结构软件的 Golang --“重新启动之间不会保留任何数据”，这并非完全正确。 重新引导将保留数据，但是真正的“崩溃”或实例的终止将丢弃所有内容。 +* 用于基础架构的 Python &数据科学 --“由于 EC2 没有像样的持久性存储系统，数据库仍托管在外部服务上”-此处的情况更多是我不想处理（或付费）设置某些东西来满足 他们没有持久性存储。 它是由其他人完成的，并且可以完成，这似乎对我所做的事情来说太过分了。 +* 用于 1 个内部应用程序的 Elixir --“ EC2 较差的负载平衡和持久性功能使开发和部署比原本要难得多”-很明显，EC2 没有**内在**固有的负载平衡，因此，这取决于您（开发人员/管理员） 自己提供某种方式。 有很多不同的方法可以使用，但是我选择动态 DNS 是因为我很熟悉它。 +* 用于测试自动化的 Ruby -@Greg 在回答您的问题时-我想这里的重点是，即使 FeedBlendr **当前不是**的扩展子代，这也很重要。 正如 Todd 所说的，这是关于学习曲线以及达到**可扩展**的程度的尝试和磨难。 没有什么阻止我（除了预算！）立即启动另外 5 个实例并将它们添加到 DNS 中，然后我突然扩展了规模。 从那里，我可以终止一些实例并进行缩减。 这就是要达到我什至拥有该选项的地步，尤其是在 EC2 上是如何实现的。 +* 适用于本机 iOS 应用程序的 Swift 和 Objective C -干杯， +## 基础结构 -英俊 +* 完全托管在 AWS 上 -漂亮的文章和鼓舞人心的故事。 很高兴读到这个小家伙正在构建具有扩展能力的东西。 +* Ubuntu & CoreOS -但是，如果我能提供一点反馈意见，则每台机器上独立缓存数据将不会随着应用程序的开发而扩展。 那会引起问题。 如何将 EC2 实例作为专用缓存运行？ 它不是持久性的，如果失败了，那么您将不得不重建现金。 但是假设它是一种简单的存储机制，则应该保持一致。 我认为他们有很多慷慨的储物津贴。 +* 用于配置管理的&地形 -无论哪种方式，几分钟之内能够打开另外 3 个实例的想法绝对是不错的，尤其是当您遇到“斜杠” /“ dugg” /之类的东西时。 如果实例可以检测到自己的高负载并自动启动新实例，那就特别好。 +* 过渡到基于 Docker 的部署 -好故事- [http://www.callum-macdonald.com/“]( Callum。 +* Jenkins 用于部署协调 -> > >需要明确的是，学习曲线主要是在处理 EC2 及其工作方式，而不是 FeedBlendr，它的核心是相对简单的。 +* Nginx &清漆 -我的帽子对你好！ 很少有人会保持自己的观点。 +* 快速交付应用程序 -谢谢（你的）信息。 顺便说一句，我已将其标记为@ [http://www.searchallinone.com/Other/Blogging_Locally_with_Outside-in_Founders_and_Only_the_Blog_Knows_Brooklyn__Brian_Lehrer_Live/](http://www.searchallinone.com/Other/Blogging_Locally_with_Outside-in_Founders_and_Only_the_Blog_Knows_Brooklyn__Brian_Lehrer_Live/) \ No newline at end of file +* 摘要汇总日志 + +* 用于安全监视的 CloudPassage + +* HashiCorp 的保管箱，用于秘密存储&设置 + +## 数据存储 + +* 主要是 MySQL 托管在 RDS 上 + +* 托管在 Elasticache 上的 Memcached 用于缓存 + +* 自托管 Redis 服务器主要用于排队 + +* 有点 Kinesis，用于处理来自尖峰流量的订单 + +* Amazon Redshift 用于数据仓库 + +## 消息传递&排队 + +* Resque 和 Sidekiq 用于异步作业处理&消息传递 + +* 用于消息传递的 RabbitMQ + +* Kafka 用于流处理 + +## 分析&商业智能 + +* 扫雪机&用于网络/移动分析的 Adobe Analytics + +* AWS Elastic MapReduce + +* 将 FlyData 从 MySQL 转换为 ETL 数据到 Redshift + +* 托管 Spark Databricks + +* Looker 作为 BI 前端 + +* 用于报告的近实时数据可用性 + +## 监控 + +* Rollbar，哨兵&用于异常跟踪的 Crashlytics + +* 用于自定义应用程序指标的 DataDog &指标聚合 + +* SysDig 用于基础结构度量&监视 + +* 用于应用程序性能监视的 NewRelic + +* Site24x7，用于可用性监视 + +* PagerDuty，用于通话提醒 + +## 质量检查和测试自动化 + +* CircleCI 用于运行单元测试 + +* Jenkins + TestUnit + Selenium + SauceLabs 用于基于浏览器的自动化测试 + +* Jenkins + TestUnit +硒+ SauceLabs 用于大脑自动测试 + +* 用于 API 功能测试的 Jenkins + TestUnit + +* Jenkins + TestUnit + Appium + SauceLabs 用于原生 Android 自动化测试 + +* Jenkins + TestUnit + Appium + SauceLabs 用于本地 iOS 自动化测试 + +* Jenkins + TestUnit +硒+ SauceLabs +用于 BI 测试自动化的代理服务器 + +* SOASTA +正则表达式脚本，用于压力，浸泡，负载和性能测试。 + +## 工程工作流程 + +* 跨团队交流的时间 + +* Trello，用于任务跟踪 + +* 具有自定义插件的 Hubot 作为我们的聊天机器人 + +* Github 作为我们的代码存储库 + +* ReviewNinja 与 Github Status API 集成，用于代码审核 + +* 连续部署-通常每天进行多次部署 + +* 转向持续交付 + +* 用于功能开发的即时沙盒环境 + +* 目前，使用 Jenkins 的单按钮推送部署正在朝着持续交付的方向发展 + +* 运行 docker 容器的游民箱= >为新工程师提供的功能齐全的开发环境，第一天就开始 + +## 架构 + +* 事件驱动的架构 + +* 从单片架构转变为通过公共消息总线进行交互的“中型”服务 + +* CDN 边缘上基于 VCL 的边缘路由，就像其他任何应用程序一样部署。 + +* Web 和移动前端与 API 层进行对话 + +* API 层与服务进行对话，聚合数据并为客户端格式化数据 + +* 服务与数据存储和消息总线进行对话 + +* 计划任务作为一项主任务运行，并在 resque / sidekiq 中分解为较小的任务 + +* 技术组件包括用于客户服务（Brain），市场营销自动化平台（Voice），履行系统（Arm），订阅计费系统（Baby Boy）和我们的数据基础架构（Hippocampus）的内部工具。 + +## 小组 + +* 45 位顶尖的企业家和高技能工程师在加利福尼亚总部玛丽娜·德尔·雷伊工作 + +* 工程师与产品经理，设计师，UX 和利益相关者一起参与称为小分队的跨职能团队，以提供端到端功能。 + +* 团队根据域被垂直划分为前端，后端和质量检查& IT。 + +* 前端团队拥有 DSC.com &内部工具的 Web UI 和我们的 iOS & Android 应用。 + +* 后端团队拥有 DSC.com &内部工具，内部服务（计费和履行），数据平台&基础结构的 Web 后端。 + +* 质量检查团队拥有所有数字产品的测试和自动化基础架构。 + +* IT 团队拥有办公室& Warehouse IT。 + +* 工程师每年参加一次公司赞助的会议。 + +* 工程师可以购买所需数量的书籍/学习资源。 + +* 所有人的站立式办公桌。 目前可提供一张跑步机作为飞行员。 + +* 每周的工程团队午餐。 + +* Tech Belly 每隔一周举行一次活动，工程师们在午餐时间就技术主题进行演讲。 + +* 鼓励工程师尝试最前沿的技术，并通过提案请求（RFC）创建提案。 + +* 鼓励工程师在有意义的地方开源工具和库 + +* 每位工程师都会获得标准版的 15 英寸 Mac Book Pro，27 英寸 Mac Display 和 24 英寸显示器。 + +* 一台 3D 打印机可用于打印道具和更多 3D 打印机。 + +## 获得的经验教训 + +* 当您要扩展的组件由简单的小型服务组成时，扩展将变得更加容易。 + +* 文档&知识共享对于快速成长的团队至关重要。 + +* 培养良好的测试套件对于快速发展的系统至关重要。 + +* Redis 使用一种近似的 LRU 算法，因此如果您对缓存有明确的 LRU 要求，则不适合使用 + +* 网络性能至关重要，尤其是在移动设备上-每毫秒都会使我们损失收入 + +* 可用性&即使对于内部工具，用户体验也很重要：高效的工具=生产力更高的团队 + +[关于 HackerNews](https://news.ycombinator.com/item?id=12490369) + +您为什么决定自己托管 Redis？ 我假设您将在 ElastiCache 上运行 Redis（使用复制组以提高可用性）。 此外，为什么还要在 Elasticache 上托管 memcached？ + +似乎是一个非常标准的现代堆栈。 很高兴为他们工作！ 真正的问题是，他们向联合利华公司技术堡垒的过渡将是什么样子。 + +我想我的问题是，为什么您需要 45 名工程师才能完成基本上是一个带有订阅选项的小型目录？ + +文档首次出现很重要。 您使用什么基础设施和流程来保持其相关性？ + +为什么这家公司需要运行这么复杂的系统？ 并不是实时地有成千上万个请求的技术公司。 似乎是一种听起来过于酷炫的过度设计的解决方案。 也许他们在做一些我看不到的大而复杂的事情。 所以我很好奇。 \ No newline at end of file diff --git a/docs/232.md b/docs/232.md index 49b1834..0df947b 100644 --- a/docs/232.md +++ b/docs/232.md @@ -1,80 +1,287 @@ -# 扩大早期创业规模 +# Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入 -> 原文： [http://highscalability.com/blog/2007/10/28/scaling-early-stage-startups.html](http://highscalability.com/blog/2007/10/28/scaling-early-stage-startups.html) +> 原文： [http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) -[的 Mark Maunder 不需要 VC](http://novcrequired.com) -倡导不收取 VC 资金，以免您变成青蛙，而不是您梦 dream 以求的王子（或公主）–具有出色的[滑盖[](http://novcrequired.com/scalingEarly.ppt) ，了解如何扩展早期启动。 他的博客还提供了一些不错的 SEO 技巧和一个非常怪异的小部件，显示了读者的地理位置。 完美的万圣节！ 马克对创业公司的其他世俗化扩张策略是什么？ +![](img/40038672dfc38e0094e8da51e713355b.png) -网站：http：//novcrequired.com/ +如果您是 Uber，并且需要存储驾驶员和驾驶员应用程序每 30 秒发送一次的位置数据，该怎么办？ 大量实时数据需要实时使用。 -## 信息来源 +Uber 的解决方案是全面的。 他们构建了自己的系统，该系统在 Mesos 之上运行 Cassandra。 Uber 的软件工程师 [Abhishek Verma](https://www.linkedin.com/in/verma7) 在一个很好的演讲中都进行了解释： [Cassandra 在跨多个数据中心的 Mesos 上 Uber](https://www.youtube.com/watch?v=4Ap-1VT2ChU&feature=youtu.be) （ [幻灯片](http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016) ）。 -* [西雅图技术启动对话](http://novcrequired.com/scalingEarly.ppt)的幻灯片。* [扩展早期创业[Mark Marker]的博客文章](http://novcrequired.com/2007/scaling-early-stage-startups/)。 +您也应该这样做吗？ 在听 Abhishek 的演讲时，会想到一个有趣的想法。 - ## 该平台 +这些天来，开发人员有很多艰难的选择。 我们应该全力以赴吗？ 哪一个？ 太贵了吗？ 我们担心锁定吗？ 还是我们应该尝试同时兼顾并打造混合架构？ 还是我们应该自己做所有事情，以免由于未达到 [50％](http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/) 毛利率而被董事会蒙羞？ - * Linxux* ISAM 类型数据存储。* 佩尔* [Httperf](http://www.hpl.hp.com/research/linux/httperf) 用于基准测试。* [Websitepulse.com](http://websitepulse.com/) 用于性能监控。 +Uber 决定建立自己的公司。 或者更确切地说，他们决定将两个功能强大的开源组件融合在一起，从而将自己的系统焊接在一起。 所需要的是一种使 Cassandra 和 Mesos 协同工作的方法，而这正是 Uber 的基础。 - ## 架构 +对于 Uber 的决定并不那么困难。 他们资金充裕，可以访问创建，维护和更新这类复杂系统所需的顶尖人才和资源。 - * 性能很重要，因为速度过慢可能会浪费您 20％的收入。 UIE 的人不同意这不一定。 他们在[可用性工具播客：页面下载时间的真相](http://www.uie.com/brainsparks/2007/09/24/usability-tools-podcast-the-truth-about-page-download-time/)中解释了其原因。 这个想法是：“我们的研究还有另一个令人惊讶的发现：下载时间与用户是否在网站上成功完成任务之间存在很强的相关性。但是，实际下载时间与任务成功之间没有相关性，这导致我们 放弃我们最初的假设。似乎，当人们完成了他们打算在某个网站上进行的工作时，他们会认为该网站是快速的。” 因此，最好将时间用于改进前端而不是后端。 +由于 Uber 的目标是使所有人在任何地方的运输都具有 99.99％的可用性，因此在扩展到无限远及更高水平时，希望能够控制您的成本确实很有意义。 - * MySQL 因性能问题而被弃用：MySQL 无法处理大型表上的大量写入和删除操作，写入操作浪费了查询缓存，不完全支持大量小表（超过 10,000 个），使用了大量内存 高速缓存索引，以每秒 200 个并发读/写查询的最大速度，记录超过 100 万条记录。 +但是，当您听演讲时，您会意识到制作此类系统所付出的巨大努力。 这真的是您的普通商店可以做的事情吗？ 不，不是。 如果您是那些希望每个人都在裸露的金属之上构建自己的所有代码的云专家之一，请记住这一点。 - * 对于数据存储，它们演变成固定长度的 ISAM 样记录方案，允许直接查找数据。 仍然使用文件级锁定，其基准测试为 20,000 多个并发读取/写入/删除。 考虑使用性能非常好并且被许多大型网站使用的 BerkelyDB，尤其是当您主要需要键值类型查询时。 我认为，如果很多数据最终显示在网页上，则存储 json 可能会很有趣。 +以金钱换时间通常很划算。 通常，以技能交易金钱是绝对必要的。 - * 已移至 httpd.prefork for Perl。 在应用程序服务器上没有 keepalive 的服务器使用更少的 RAM，并且运行良好。 +鉴于 Uber 的可靠性目标，即 10,000 个请求中只有一个可能失败，因此他们需要在多个数据中心中用完。 由于事实证明 Cassandra 可以处理巨大的负载并且可以跨数据中心工作，因此将其作为数据库选择是有意义的。 - ## 得到教训 +如果您想使所有人，任何地方的运输都可靠，则需要有效地利用您的资源。 这就是使用像 Mesos 这样的数据中心操作系统的想法。 通过在同一台计算机上统计复用服务，您需要的计算机数量减少了 30％，从而节省了资金。 之所以选择 Mesos，是因为当时 Mesos 是经证明可与数以万计的计算机集群大小一起工作的唯一产品，这是 Uber 的要求。 优步的工作量很大。 - * 正确配置数据库和 Web 服务器。 MySQL 和 Apache 的内存使用很容易失控，随着交换的增加，导致网格性能缓慢下降。 以下是一些有助于解决[配置问题](http://www.possibility.com/epowiki/Wiki.jsp?page=VpsConfiguration)的资源。 +有哪些更有趣的发现？ - * 只服务您关心的用户。 阻止使用大量有价值的资源免费爬行您网站的内容主题。 监视他们每分钟获取的内容页面的数量。 如果超过阈值，然后对它们的 IP 地址进行反向查找并配置防火墙以阻止它们。 +* 您可以在容器中运行有状态服务。 Uber 发现，在裸机上运行 Cassandra 与在 Mesos 管理的容器中运行 Cassandra 之间几乎没有任何区别，开销为 5-10％。 - * 尽可能多地缓存数据库数据和静态内容。 Perl 的 Cache :: FileCache 用于在磁盘上缓存数据库数据和呈现的 HTML。 +* 性能良好：平均读取延迟：13 毫秒，写入延迟：25 毫秒，P99 看起来不错。 - * 在 URL 中使用两个不同的主机名，以使浏览器客户端可以并行加载图像。 +* 对于最大的群集，他们能够支持超过一百万次写入/秒和约 10 万次读取/秒。 - * 使内容尽可能静态创建单独的 Image 和 CSS 服务器以提供静态内容。 对静态内容使用 keepalive，因为静态内容每个线程/进程占用的内存很少。 +* 敏捷性比性能更重要。 通过这种架构，Uber 获得的就是敏捷性。 跨集群创建和运行工作负载非常容易。 - * 留下大量的备用内存。 备用内存允许 Linux 在文件系统缓存之前使用更多内存，从而使性能提高了约 20％。 +这是我的演讲要点： - * 关闭动态内容的 Keepalive。 增加的 http 请求可能会耗尽为它们服务所需的线程和内存资源。 +## 开头 - * 您可能不需要复杂的 RDBMS 来访问数据。 考虑一个重量更轻的数据库 BerkelyDB。 +* 跨不同服务的静态分区机器。 -“它们演变为固定长度的 ISAM（如记录方案）”-我不清楚，这是哪个应用程序？ 他们不再使用 BerkleyDB，而不再使用 MySQL，他们说他们正在使用什么吗？ +* 50 台机器可能专用于 API，50 台机器专用于存储，等等，并且它们没有重叠。 -[http://www.callum-macdonald.com/“]( Callum +## 即时 -嗨，卡勒姆， +* 希望在 [Mesos](http://mesos.apache.org/) 上运行所有内容，包括诸如 Cassandra 和 Kafka 之类的有状态服务。 -我收到了托德发来的关于您问题的电子邮件。 :) + * Mesos 是数据中心操作系统，可让您像单一资源池一样针对数据中心进行编程。 -我们从头开始构建了自己的快速文件存储例程。 它宽松地基于 ISAM 或 MySQL 的 MyISAM，因为它使用固定长度的顺序记录。 对于我们需要的某些特定操作，它要快得多。 不幸的是，目前它还不是开源的，但也许我们会在将来发布它。 + * 当时，事实证明 Mesos 可以在成千上万的计算机上运行，​​这是 Uber 的要求之一，因此这就是他们选择 Mesos 的原因。 今天，Kubernetes 可能也可以工作。 -问候， + * Uber 在 MySQL 之上构建了自己的分片数据库，称为 [Schemaless](https://eng.uber.com/schemaless-part-one/) 。 这个想法是 Cassandra 和 Schemaless 将成为 Uber 中的两个数据存储选项。 现有的 Riak 装置将移至 Cassandra。 -Mark Maunder -FEEDJIT 创始人& CEO +* 一台机器可以运行各种服务。 -他在幻灯片“幻灯片”中谈到 MySQL，“ MySQL 不支持大量小表（超过 10,000 个）。” +* 同一台机器上的统计复用服务可能会导致 的机器数量减少 30％ 。 这是 Google 在 Borg 上运行的 [实验](http://research.google.com/pubs/pub43438.html) 的发现。 -为什么地球上会有超过 10,000 张桌子？ 这听起来像是糟糕的设计。 +* 例如，如果一项服务使用大量 CPU，并且与使用大量存储或内存的服务非常匹配，那么这两项服务可以在同一服务器上有效运行。 机器利用率上升。 -@Dimitri：加入有点晚，但是为了回答您的问题，使用多个小表而不是一个大表可以更有效地解决某些情况。 +* Uber 现在有大约 20 个 Cassandra 集群，并计划在将来有 100 个。 -一个典型的例子是 WordPress 多用户（ [http://mu.wordpress.org/faq/）](http://mu.wordpress.org/faq/))为每个博客创建表。 +* 敏捷性比性能更重要。 您需要能够管理这些集群并以平滑的方式对其执行不同的操作。 -以防万一您不想点击链接:-) +* **为什么在容器中而不是在整个机器上运行 Cassandra？** -*WordPress MU 为每个博客创建表，这是我们发现的系统，在经过大量测试，反复试验后，对于插件的兼容性和扩展性而言，其工作效果最佳。 这利用了现有的 OS 级和 MySQL 查询缓存，还使分割用户数据变得更加容易，这是超出单个功能范围的所有服务最终都必须要做的。 我们是实际的人，所以我们将使用最有效的方法，对于 WordPress.com 上的 2.3m 数据，MU 一直是冠军。* + * 您想存储数百 GB 的数据，但您还希望将其复制到多台计算机上以及跨数据中心。 -We built our own fast file storage routines from the ground up. It's loosely based on ISAM or MySQL's MyISAM in that it uses fixed length sequential records. It's a lot faster for certain specific operations that we require. Unfortunately it's not open source at this time but perhaps we'll release it in future. + * 您还希望跨不同群集进行资源隔离和性能隔离。 -初学者的好起点 ------ -[http://underwaterseaplants.awardspace.com“](海洋植物 -[http：//underwaterseaplants.awardspace .com / seagrapes.htm“](海葡萄... [http://underwaterseaplants.awardspace.com/plantroots.htm”](植物根 + * 很难在一个共享群集中获得所有这些。 例如，如果您制作了一个 1000 节点的 Cassandra 群集，它将无法扩展，或者跨不同群集也会产生性能干扰。 -如果您是一家公司，请阅读本书： -[http://www.amazon.com/gp/product/0470345233?ie=UTF8 &标签= innoblog-20 & linkCode = as2 &营地= 1789 & creative = 9325 & creativeASIN = 0470345233“](如何 Cast 割公牛：有关风险，增长和业务成功的意外教训![](img/18d8730cd6a019f27b42227378225f3e.png) http： //www.assoc-amazon.com/e/ir?t=innoblog-20 & l = as2 & o = 1 & a = 0470345233“ width =” 1“ height =” 1“ border = “ 0” alt =“” style =“ border：none！important; margin：0px！important;” / NetApp 创始人 Dave Hitz 的>提供了直接，诚实，周到的业务建议，适用于整个业务成长周期中的业务创始人和领导者。 他特别强调艰难的选择和决策过程，并从冒险的一生中获得了一种理解。 如果您是第一次创业，请阅读本书。 如果您正在进入公司的成长阶段，请阅读本书。 如果您第一次尝试失败并想了解原因，请阅读本书。 如果您想笑些，请读这本书。 这样可以使您的公司扩展过程更有趣。 \ No newline at end of file +## 量产中 + +* 在两个数据中心（西海岸和东海岸）中复制约 20 个群集 + +* 最初有 4 个集群，包括中国，但由于与滴滴合并，这些集群被关闭了。 + +* 跨两个数据中心的 300 台机器 + +* 最大的 2 个集群：每秒超过 100 万次写入和每秒 10 万次读取 + + * 群集之一正在存储驾驶员和骑乘者应用程序每 30 秒发送一次的位置。 + +* 平均读取延迟：13 毫秒，写入延迟：25 毫秒 + +* 通常使用 [LOCAL_QUORUM](https://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html) 一致性级别（表示强一致性） + +## 月背景资料 + +* Mesos 将 CPU，内存和存储从计算机中分离出来。 + +* 您不是在查看单个计算机，而是在查看资源并对其进行编程。 + +* 线性可伸缩性。 可以在数以万计的计算机上运行。 + +* 高度可用。 Zookeeper 用于在可配置数量的副本中进行领导者选举。 + +* 可以启动 Docker 容器或 Mesos 容器。 + +* 可插拔资源隔离。 用于 Linux 的 Cgroups 内存和 CPU 隔离器。 有一个 Posix 隔离器。 不同的操作系统有不同的隔离机制。 + +* 两级调度程序。 来自 Mesos 代理的资源被提供给不同的框架。 框架在这些提议的基础上安排自己的任务。 + +## Apache Cassandra Backgrounder + +* Cassandra 非常适合 Uber 的用例。 + +* 水平可扩展。 随着新节点的添加，读写规模呈线性增长。 + +* 高度可用。 具有可调一致性级别的容错能力。 + +* 低延迟。 在同一数据中心内获得亚毫秒级的延迟。 + +* 操作简单。 这是同质的簇。 没有主人。 集群中没有特殊的节点。 + +* 足够丰富的数据模型。 它具有列，组合键，计数器，二级索引等 + +* 与开源软件的良好集成。 Hadoop，Spark，Hive 都具有与 Cassandra 进行通信的连接器。 + +## 中层+ Uber + Cassandra = dcos-cassandra-service + +* Uber 与 Mesosphere 合作生产了 [mesosphere / dcos-cassandra-service](https://github.com/mesosphere/dcos-cassandra-service) -一种自动化服务，可轻松在 Mesosphere DC /上进行部署和管理 操作系统。 + +![29683333130_0478a29f4f.jpg](img/838bef48b4379bab5211f9b9f159d7c8.png) + +* 顶部是 Web 界面或 Control Plane API。 您指定所需的节点数； 您想要多少个 CPU； 指定 Cassandra 配置； 然后将其提交给 Control Plane API。 + +* 使用 Uber 的部署系统，它在 [Aurora](http://aurora.apache.org/) 之上启动，用于运行无状态服务，用于引导 dcos-cassandra 服务框架。 + +* 在示例 dcos-cassandra-service 框架中有两个与 Mesos 主服务器通信的集群。 Uber 在其系统中使用了五个 Mesos 母版。 Zookeeper 用于领导者选举。 + +* Zookeeper 还用于存储框架元数据：正在运行的任务，Cassandra 配置，集群的运行状况等。 + +* Mesos 代理在群集中的每台计算机上运行。 代理将资源提供给 Mesos 主服务器，主服务器以离散报价分发它们。 报价可以被框架接受或拒绝。 多个 Cassandra 节点可以在同一台计算机上运行。 + +* 使用 Mesos 容器，而不是 Docker。 + + * 覆盖配置中的 5 个端口（storage_port，ssl_storage_port，native_transport_port，rpcs_port，jmx_port），因此可以在同一台计算机上运行多个容器。 + + * 使用永久卷，因此数据存储在沙箱目录外部。 万一 Cassandra 失败，数据仍将保留在持久卷中，如果崩溃并重新启动，则将数据提供给同一任务。 + + * 动态预留用于确保资源可用于重新启动失败的任务。 + +* Cassandra 服务操作 + + * Cassandra 有一个 [种子节点](https://www.quora.com/What-is-a-seed-node-in-Apache-Cassandra) 的想法，它为加入集群的新节点引导八卦过程。 创建了自定义 [种子提供程序](https://mesosphere.github.io/cassandra-mesos/docs/configuration-and-state.html) 来启动 Cassandra 节点，该节点允许 Cassandra 节点自动在 Mesos 群集中推出。 + + * 可以使用 REST 请求增加 Cassandra 群集中的节点数。 它将启动其他节点，为其提供种子节点，并引导其他 Cassandra 守护程序。 + + * 可以更改所有 Cassandra 配置参数。 + + * 使用 API​​可以替换死节点。 + + * 需要修复才能跨副本同步数据。 维修在每个节点的主键范围内进行。 这种方法不会影响性能。 + + * 清除将删除不需要的数据。 如果已添加节点，则数据将被移动到新节点，因此需要清理才能删除移动的数据。 + + * 可以通过框架配置多数据中心复制。 + +* 多数据中心支持 + + * 在每个数据中心中独立安装 Mesos。 + + * 在每个数据中心中设置框架的独立实例。 + + * 框架互相交谈并定期交换种子。 + + * 这就是 Cassandra 所需要的。 通过引导其他数据中心的种子，节点可以八卦拓扑并找出节点是什么。 + + * 数据中心之间的往返 ping 延迟为 77.8 ms。 + + * P50 的异步复制延迟：44.69 毫秒； P95：46.38ms; P99：47.44 毫秒； + +* 计划程序执行 + + * 调度程序的执行被抽象为计划，阶段和块。 调度计划具有不同的阶段，一个阶段具有多个块。 + + * 调度程序启动时要经过的第一阶段是协调。 它将发送给 Mesos 并找出已经在运行的内容。 + + * 有一个部署阶段，检查集群中是否已存在配置中的节点数，并在必要时进行部署。 + + * 块似乎是 Cassandra 节点规范。 + + * 还有其他阶段：备份，还原，清理和修复，具体取决于命中的 REST 端点。 + +* 集群可以每分钟一个新节点的速率启动。 + + * 希望每个节点的启动时间达到 30 /秒。 + + * 在 Cassandra 中不能同时启动多个节点。 + + * 通常给每个 Mesos 节点 2TB 的磁盘空间和 128GB 的 RAM。 每个容器分配 100GB，每个 Cassandra 进程分配 32GB 堆。 （注意：目前尚不清楚，因此可能有错误的细节） + + * 使用 G1 垃圾收集器代替 CMS，它具有更好的 99.9％延迟（16x）和性能，无需任何调整。 + +## 裸机 vs Mesos 托管群集 + +* 使用容器的性能开销是多少？ 裸机意味着 Cassandra 不在容器中运行。 + +* 读取延迟。 几乎没有什么区别：5-10％的开销。 + + * 在裸机上平均为 0.38 ms，而在 Mesos 上为.44 ms。 + + * 在 P99 上，裸机为.91 毫秒，在 Mesos 上，P99 为.98 毫秒。 + +* 读取吞吐量。 差别很小。 + +* 写入延迟。 + + * 在裸机上平均为 0.43 ms，而在 Mesos 上为.48 ms。 + + * 在 P99 上，裸机为 1.05 毫秒，在 Mesos 上，P99 为 1.26 毫秒。 + +* 写入吞吐量。 差别很小。 + +## 相关文章 + +* [关于 HackerNews](https://news.ycombinator.com/item?id=12600298) + +* [使用 Borg 在 Google 进行大规模集群管理](http://research.google.com/pubs/pub43438.html) + +* [Google 的三个时代-批处理，仓库，即时](http://highscalability.com/blog/2011/8/29/the-three-ages-of-google-batch-warehouse-instant.html) + +* [Google 延迟容忍系统：将不可预测的部分做成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) + +* [Google：驯服长时间延迟的尾巴-当更多机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) + +* [Google 从单一数据中心到故障转移再到本地多宿主体系结构的过渡](http://highscalability.com/blog/2016/2/23/googles-transition-from-single-datacenter-to-failover-to-a-n.html) + +* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) + +* [Uber 变得与众不同：使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) + +* [为在现代时代构建可扩展的有状态服务提供依据](http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html) + +* [我也想运行有状态容器](https://techcrunch.com/2015/11/21/i-want-to-run-stateful-containers-too/) + +* [Uber 工程技术堆栈，第一部分：基础](https://eng.uber.com/tech-stack-part-one/) + +* [Uber，Twitter，PayPal 和 Hubspot 使用 Apache Mesos 的 4 种独特方式](https://www.linux.com/news/4-unique-ways-uber-twitter-paypal-and-hubspot-use-apache-mesos) + +链接到代码：https://github.com/mesosphere/dcos-cassandra-service + +顺便说一句，在文章中有一个链接。 + +有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。 + +我认为 ELK 不能跟上步伐。 + +@bob。 Uber 确实使用 ELK 进行记录。 它具有最大的 ELK 日志搜索安装之一。 + +我想知道他们是否正在使用 Mesos 卷进行持久数据存储。 + +是的，我们正在使用持久卷（https://mesos.apache.org/documentation/latest/persistent-volume/）进行数据存储。 + +你好 + +您能否阐明查询的性质？ + +聚合或联接或基于纬度的查询？ + +是否想知道 solr 是否可以根据您的用例进行选择？ + +> >有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。 + +如今，许多人用来实现此目的的模式是使用 kafka 日志记录库，该库挂接到其微服务中，并使用 spark 等将来自 Kafka 的日志消耗到 elasticsearch 中。 我们在一个很小的〜8 节点 ES 集群上每秒处理数十万个事件。 + +-SRE @ Orchard 平台 + +您能否分享 DC 之间的延迟时间？ + +Uber 使用 DC / OS 很有意思，但选择使用 Aurora 而非马拉松。 我上次查看极光时（大约 18 到 24 个月前），它的发展程度不及马拉松。 我想知道何时做出决定？ Aurora 文档得到了很大的改进。 + +很棒的帖子！ 使用 Mesos 代替 Hadoop YARN 是否有任何特殊原因？ Mesos 是否更适合您的需求？ + +YARN 只能运行 Hadoop 工作负载 Mesos 允许您运行任何类型的工作负载。 + +谢谢您，先生，非常有信息。 +Mesos 可以在没有 docker 容器安装 Cassandra 的情况下运行吗？ +我们可以使用 Mesos 默认容器安装 cassandra 吗？ + +很棒的翔实文章。 做得好！ + +怎么可能有 100 万次写入但每秒 10 万次读取？ 支持多于读比写有意义吗？ \ No newline at end of file diff --git a/docs/233.md b/docs/233.md index 9154b96..846ad82 100644 --- a/docs/233.md +++ b/docs/233.md @@ -1,12 +1,378 @@ -# 论文：Wikipedia 的站点内部，配置，代码示例和管理问题 +# 从将 Uber 扩展到 2000 名工程师，1000 个服务和 8000 个 Git 存储库获得的经验教训 -> 原文： [http://highscalability.com/blog/2007/10/26/paper-wikipedias-site-internals-configuration-code-examples.html](http://highscalability.com/blog/2007/10/26/paper-wikipedias-site-internals-configuration-code-examples.html) +> 原文： [http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) -Wikipedia 和 [Wikimedia](http://highscalability.com/wikimedia-architecture) 拥有一些有关如何构建高度可扩展系统的最佳，最完整的真实文档。 Domas Mituzas 撰写的这篇论文涵盖了有关 Wikipedia 如何工作的许多细节，包括：所使用的不同软件包的概述（Linux，PowerDNS，LVS，Squid，lighttpd，Apache，PHP5，Lucene，Mono，Memcached），它们如何使用它们。 CDN，缓存如何工作，他们如何配置代码，如何存储媒体，如何构造数据库访问，如何处理搜索，如何处理负载平衡和管理。 全部带有真实的代码示例和配置文件示例。 这是一个非常有用的资源。 + + +为了让 Uber 看到增长的景象，请看一下以上视频的前几秒钟。 它将在正确的位置开始。 它来自[和 Uber 的首席系统架构师](https://www.linkedin.com/in/mranney) [Voxer](http://www.voxer.com/) 的联合创始人 Matt Ranney 发表的精彩演讲：[我希望在将 Uber 扩展到 1000 个服务之前知道些什么[](https://www.youtube.com/watch?v=kb-m2fasdDY) 幻灯片）。 + +它显示了中国一些城市不断增长的，有节奏的，波动的交通网络。 世界各地的城市都在发生这种爆炸性增长的方式。 实际上，Uber 现在已遍布 400 个城市和 70 个国家/地区。 他们有 6000 多名员工，其中 2000 名是工程师。 仅仅一年半的时间，只有 200 名工程师。 这些工程师已经产生了 1000 多种微服务，这些微服务存储在 8000 多个 git 存储库中。 + +在短时间内疯狂增长 10 倍。 谁经历过？ 不太多。 就像您可能期望的那样，这种独特的，压缩的，快节奏的，高风险的经验必须教会您一些新知识，比以前理解的要深刻。 + +马特不是这个游戏的新手。 他是 Voxer 的共同创始人，Voxer 经历了[的快速增长](http://www.marketwired.com/press-release/walkie-talkie-app-voxer-soars-past-billion-operations-per-day-powered-basho-riak-1603652.htm)，但这是不同的。 您可以在观看视频时告诉您 Matt 试图对他们所取得的成就表示满意。 + +马特是一个有思想的人，这是有根据的。 在[最近的一次采访](https://www.infoq.com/articles/podcast-matt-ranney)中，他说： + +> 在 QCon 和其他活动上进行的许多架构讨论使我感到不足够。 像其他人（例如 Google）一样，一切都明白了，但我却没有。 + +马特（Matt）在这次演讲中走出了漩涡，试图从某种意义上讲出一种经验，试图弄清一切。 他成功了。 疯狂地。 + +这部分是智慧的谈话，部分是悔。 马特说：“一路上犯了很多错误，而这些正是从中汲取教训的。 + +演讲的脚手架挂在 WIWIK（我希望我知道的）设备上，该设备已成为互联网的模因。 这是他建议给自己幼稚的一年半的幼稚自我，尽管当然，像我们所有人一样，他当然不会听。 + +而且他不会孤单。 许多人批评 Uber（ [HackerNews](https://news.ycombinator.com/item?id=12597232) ， [Reddit](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) ）。 毕竟，这些数字实在是太疯狂了。 两千名工程师？ 八千个存储库？ 一千个服务？ 一定是很严重的错误，不是吗？ + +也许。 令人惊讶的是，马特对整个事情没有判断力。 他的询问方式更多是质疑和搜索，而不是寻找绝对值。 他本人似乎对存储库的数量感到困惑，但是他给出了更多存储库与较少存储库的优缺点，而没有说哪个更好，因为鉴于 Uber 的情况：您如何定义更好？ + +优步正在全球范围内展开激烈的战斗，以构建一个能够占领赢家通吃的市场的行星尺度系统。 那就是商业模式。 成为最后一个服务站。 在这种情况下，更好的意思是什么？ + +赢家通吃意味着您必须快速成长。 您可能会变慢并显得更有条理，但如果变慢，就会迷失方向。 因此，您可以在混乱的边缘保持平衡，并将您的脚趾或整个身体浸入混乱中，因为这将成为您扩展成为全球主导服务的方式。 这不是一条缓慢的增长之路。 这敲门，采取一切策略。 认为您可以做得更好？ 真？ + +微服务非常适合 Uber 想要实现的目标。 塞住你的耳朵，但这是康威定律的事情，你会获得如此多的服务，因为这是那么多人被雇用并提高生产力的唯一途径。 + +如此多的服务没有技术原因。 没有这么多存储库的技术原因。 这一切都是关于人的。 [老婆婆](https://news.ycombinator.com/item?id=12598893)很好地总结了一下： + +> 扩展流量不是问题。 扩大团队规模和产品功能发布率是主要因素。 + +演讲的一个一致主题是*不错，但是有一些折衷，通常是令人惊讶的折衷，而您实际上只能在规模上体验*。 这引出了我从演讲中得出的两个最大构想： + +* **微服务是一种用 API 协调**代替人类交流的方式。 与人们谈论和处理团队政治相比，团队更容易编写新代码。 它使我想起了我很久以前读过的一本书，不记得这个名字了，人们居住在戴森球体内部，并且因为球体内部空间如此之大，自由能量如此之多，以至于当任何一个群体与另一个群体发生冲突时， 他们可能会分裂并适应新的领域。 这是否更好？ 我不知道，但这确实可以并行完成许多工作，同时又避免了很多人的开销。 +* **纯胡萝卜，不粘**。 关于命令和控制的作用如此广泛，这是一个很深的观点。 您会很想执行政策。 *例如，您应该以这种方式记录*。 如果您不这样做，将会有后果。 那是棍子。 马特说不要那样做。 改用胡萝卜。 每当棍棒冒出来都是不好的。 因此没有任何授权。 您想要处理它的方式是提供非常明显且易于使用的工具，以至于人们不会以其他任何方式使用它。 + +这是您必须真正了解的那些谈话之一，因为除了文本以外，还有很多其他方面的交流。 当然，我仍然鼓励您阅读我的演讲的掩饰:-) + +## 统计信息（2016 年 4 月） + +* 优步遍布全球 400 个城市。 + +* 70 个国家。 + +* 6000 多名员工 + +* 2000 名工程师（一年半前有 200 名工程师） + +* 1000 个服务（数量近似） + + * 不同服务的数量变化如此之快，以至于很难准确计算生产中的实际服务数量。 许多团队正在建立很多东西。 甚至都不在乎实际的数字。 + +* 超过 8000 个 git 回购。 + +## 微服务 + +* 很高兴将您所有的整体分解成更小的东西。 甚至这个名字听起来也很糟糕。 但是微服务有其不利的一面。 + +* 事情最有可能破裂的时间就是您进行更改的时间。 即使是在 Uber 最忙的时候，周末 Uber 在工程师不做更改的时候也是最可靠的。 + +* 每当您进行更改时，都有可能破坏它。 永远不要接触微服务是否有意义？ 也许。 + +* 好 + + * 值得质疑的是，为什么我们要在微服务上投入如此多的精力？ 这不是偶然的，有很多好的结果。 + + * 微服务允许团队快速组建并独立运行。 人们一直在被添加。 团队需要迅速组建起来，并在可以推断边界的地方开展工作。 + + * 拥有自己的正常运行时间。 您运行您编写的代码。 所有服务团队都在征求他们在生产中运行的服务。 + + * 使用最佳工具进行作业。 但是最好的方式是什么？ 最好写？ 最好跑？ 最好，因为我知道吗？ 最好，因为有图书馆？ 当您深入研究时，最好并不意味着什么。 + +* 明显的成本 + + * 运行大型微服务部署的成本是多少？ + + * 现在，您正在运行分布式系统，这比使用整体系统更难。 + + * 一切都是 RPC。 您必须处理所有这些疯狂的失败模式。 + + * 如果中断怎么办？ 您如何排除故障？ 您如何确定中断在服务链中的何处发生？ 如何确保合适的人得到传呼？ 采取了正确的纠正措施来解决问题？ + + * 这些仍然都是显而易见的成本。 + +* 不太明显的费用 + + * 一切都是权衡，即使您没有意识到自己正在做到。 作为所有这些微服务的交换，您可以获得某些东西，但是您也放弃了一些东西。 + + * 通过对所有事物进行超级模块化，我们引入了一些细微而不明显的问题。 + + * 您可能选择构建新服务，而不是修复已损坏的内容。 在某些时候，始终围绕问题解决和清理旧问题的成本已成为一个因素。 + + * **您发现自己为政治**交易很复杂。 您不必编写笨拙的对话，而充满了人类的情感，而是可以编写更多的软件而避免说话。 + + * **您可以保持自己的偏见**。 如果您喜欢 Python 以及与您喜欢的节点打交道的团队，则可以使用自己喜欢的语言来构建新的东西，而不必使用其他代码库。 即使对于组织或整个系统而言，这可能并不是最好的事情，但您仍要继续做自己认为最好的事情。 + +## 拥有多种语言的成本 + +* 史前史：最初，Uber 被 100％外包。 看来这似乎不是技术问题，所以一些公司编写了移动应用程序的第一个版本和后端。 + +* 调度：内部进行开发时，它是用 Node.js 编写的，现在正在迁移到 Go。 + +* 核心服务：系统的其余部分，最初是用 Python 编写的，现在正在迁移到 Go。 + +* Maps 最终被引入内部，那些团队正在使用 Python 和 Java。 + +* 数据工程团队使用 Python 和 Java 编写代码。 + +* 内部度量系统用 Go 编写。 + +* 您开始注意到有很多语言。 微服务使您可以使用多种语言。 + +* 团队可以用不同的语言编写并且仍然可以相互交流。 它可以工作，但是需要付费： + + * 难以共享代码。 + + * 难以在团队之间移动。 在一个平台上积累的知识不会转移到另一平台上。 任何人当然都能学到，但是要付出一定的代价。 + +* **我希望知道的内容**：拥有多种语言会破坏文化。 通过在任何地方都接受微服务，您最终可以扎营。 有一个节点营，一个 Go 营，等等。人们在部落周围组织自然是很自然的，但是要接受在各处都拥有多种语言的策略是有代价的。 + +## RPC 的成本 + +* 团队使用 RPC 相互通信。 + +* 大量的人很快就真正加入了 HTTP 的弱点。 像什么状态代码？ 标头是做什么用的？ 查询字符串中包含什么？ 这是 RESTful 吗？ 这是什么方法 + +* 所有这些事情在执行浏览器编程时看上去确实很酷，但是在进行服务器编程时却变得非常复杂。 + +* 您真正想说的是在那里运行此功能，并告诉我发生了什么。 相反，使用 HTTP / REST 会遇到所有这些细微的解释问题，而这一切都非常昂贵。 + +* JSON 很棒，您可以用眼球看一下并阅读它，但是如果没有类型，这是一团糟，但不是马上，问题随后就会出现。 当某人更改某些内容并在下游跳了几跳时，他们依赖于对空字符串与 null 的某种微妙解释，或者某种语言对另一种语言的某种类型的强制转换，这会导致巨大的混乱，需要花费很长的时间才能解决。 接口上的类型将解决所有这些问题。 + +* RPC 比过程调用慢。 + +* **我希望知道的内容**：服务器不是浏览器。 + + * 当在数据中心中进行交谈时，将所有内容都视为函数调用而不是 Web 请求，这更加有意义。 当您控制对话的双方时，您并不需要所有多余的浏览器内容。 + +## 储存库 + +* 最好的回购数量是多少？ 他认为最好的是一个，但许多人不同意。 + +* 许多人认为很多回购是最好的。 每个项目可能一个，甚至每个项目多个。 + +* 具有许多存储库是遵循具有许多小型模块的行业趋势。 小型模块易于开源或交换。 + +* 一个仓库很不错，因为您可以进行跨领域更改。 您想要进行更改，可以轻松找到所有需要更改的代码。 浏览代码也很容易。 + +* 有很多不好的地方，因为这会给您的构建系统带来压力。 这会损害您浏览代码的能力。 确保正确完成跨领域更改很痛苦。 + +* 一个不好的原因是，它将变得如此之大，除非您在顶部拥有一些疯狂的精心设计的系统，否则您将无法构建或检验您的软件。 如果没有特殊工具，一个仓库可能无法使用。 Google 有一个存储库，但它使用虚拟文件系统，好像您已检出整个存储库。 + +* 超过 8000 个 git 回购。 一个月前有 7000。 + + * 有些人有自己的仓库。 + + * 一些团队使用单独的存储库与服务本身分开跟踪服务配置。 + + * 但是大多数是生产仓库。 + +* 很多回购。 + +## 操作问题 + +* 事情破裂了怎么办？ 大型微服务部署会带来一些令人惊讶的问题。 + +* 如果其他团队无法使用您的服务，而该服务尚未准备好发布，那么其他团队是否可以在您的服务中添加修复程序并将其发布？ + + * 即使您的所有测试都通过了，您拥有的正常运行时间也可以与其他发布您服务的团队兼容吗？ 自动化是否足够好，团队可以相互发布软件？ + + * 在 Uber，这取决于情况。 有时是的，但通常答案是“否”，团队将只需要阻止此修复程序。 + +* 大而小的团队，每个人都在快速前进，所有功能都超级快地发布，但是有时您必须将整个系统理解为一台大型机器连接在一起的一件事。 当您花费所有时间将其分解为微服务时，这很难。 + + * 这是一个棘手的问题。 希望将更多的时间花在保持上下文关联上。 + + * 应该仍然能够理解整个系统的整体功能。 + +## 性能问题 + +* 鉴于微服务之间的相互依赖程度，性能肯定会提高。 + +* RPC 昂贵，尤其是当存在多种语言时，如何理解性能的答案完全取决于语言工具，并且工具都是不同的。 + +* 您已经让每个人都以自己的语言进行编程，现在了解这些语言的性能是一个真正的挑战。 + +* 尝试使用 [火焰图](http://www.brendangregg.com/flamegraphs.html) 使所有语言具有通用的分析格式。 + +* 当您想了解系统的性能时，尝试解决性能问题时，一个很大的摩擦就是工具的差异。 + +* 每个人都想要一个仪表盘，但是如果没有自动生成仪表盘，团队将只把他们认为重要的东西放在仪表盘上，因此当您想追逐一个团队的仪表盘时，问题看上去将与另一个团队完全不同。 + +* 每个服务在创建时都应该具有一个标准的仪表板，其中包含相同的有用数据集。 应该能够创建一个完全没有工作的仪表板。 然后，您可以浏览其他团队的服务，并且看起来都一样。 + +* **我希望知道的内容**：不需要良好的表现，但您需要知道自己的立场。 + + * 一个大争论是，您是否应该关心性能。 “过早的优化是万恶之源”的类型思维催生了反对优化的人们非常奇怪的亚文化。 没关系，服务并不那么忙。 我们应该始终针对显影剂速度进行优化。 购买计算机比雇用工程师便宜。 + + * 对此有一定道理。 工程师非常昂贵。 + + * 问题在于，性能要紧要紧。 有一天，您将遇到绩效问题，如果已建立起一种无关紧要的文化，那么突然之间变得至关重要很困难。 + + * 您想根据创建的所有内容获得某种性能的 SLA，以便有一个数字。 + +## 扇出问题-跟踪 + +* 扇出会导致很多性能问题。 + +* 想象一个典型的服务，即 99％的时间在 1 毫秒内做出响应。 它在一秒钟内响应的时间为 1％。 还算不错。 用户有 1％的时间会遇到这种情况。 + +* 现在，我们假设服务开始大张旗鼓，推出了许多其他服务。 响应时间变慢的机会迅速增加。 至少在 1 秒钟内使用 100 个服务和 63％的响应时间（1.0-.99 ^ 100 = 63.4％）。 + +* 分发跟踪是您跟踪扇出问题的方式。 如果无法理解整个体系结构中的请求，将很难跟踪扇出问题。 + + * Uber 正在使用 [OpenTracing](https://github.com/opentracing) 和 [Zipkin](https://github.com/openzipkin/zipkin) 。 + + * 另一种方法是使用日志。 每个日志条目都有一个公共 ID，该 ID 将所有服务组合在一起。 + +* 给出了一个棘手的例子。 顶层对所有相同服务均具有大量扇出。 当您查看服务时，它看起来不错。 每个请求都是快速且一致的。 问题是顶级服务获得了 ID 列表，并正在为每个 ID 调用服务。 即使同时进行，也将花费太长时间。 只需使用批处理命令即可。 如果不进行跟踪，很难找到这个问题。 + +* 另一个示例是进行了数千次服务调用的服务。 尽管每个呼叫都很快，但大量呼叫却使服务变慢。 事实证明，遍历列表并更改属性后，它神奇地变成了数据库请求。 但是数据库团队说，由于每个操作都很快，所以数据库运行良好，但是他们会想知道为什么会有这么多操作。 + +* 跟踪的开销可以更改结果。 跟踪是很多工作。 一种选择是不跟踪所有请求。 跟踪请求的统计显着部分。 Uber 跟踪约 1％的请求。 + +* **我希望知道的内容**：跟踪需要跨语言上下文传播。 + + * 因为所有这些不同的语言都在所有这些不同的框架中使用，所以获取请求的上下文（例如请求的用户是谁），是否经过身份验证，所处的地理位置是什么，如果无处可放，则会变得非常复杂 将会传播的上下文。 + + * 服务提出的任何依赖请求都必须传播上下文，即使他们可能不理解上下文也是如此。 如果很久以前添加此功能，它将节省大量时间。 + +## 正在记录 + +* 拥有一堆不同的语言，一群团队和许多新人，一半的工程团队已经存在了不到 6 个月，每个人可能都倾向于以完全不同的方式登录。 + +* 任务授权是一个棘手的单词，但这是您真正想要做的，需要一种通用的日志记录方法。 更为可接受的说法是，它提供的工具显而易见且易于使用，人们不会以任何其他方式来获得一致且结构化的日志记录。 + +* 多种语言使得难以记录。 + +* 如果存在问题，日志记录本身可能会使日志记录过多而使这些问题更加严重。 日志中需要背压以在过载时删除日志条目。 希望早些时候已放入系统中。 + +* **我希望知道的内容**：关于日志消息大小的一些概念，以便可以跟踪谁产生了过多的日志数据。 + + * 所有日志发生的事情是通过某种工具将它们编入索引，以便人们可以搜索它们并学习事物。 + + * 如果免费记录，则记录的数据量是可变的。 有些人会记录很多数据，使系统不堪重负。 + + * 对于计费系统，当将日志数据发送到群集以建立索引时，可以将帐单发送到服务以进行支付。 + + * 的想法是给开​​发人员以更大的压力，使他们更聪明地记录日志，而不是更难。 + + * Uber 创建了 [uber-go / zap](https://github.com/uber-go/zap) 用于结构化日志记录。 + +## 负载测试 + +* 想要在将服务投入生产之前进行负载测试，但是无法构建与生产环境一样大的测试环境。 + +* 这也是生成实际测试数据以测试系统所有部分的问题。 + +* 解决方案：在非高峰时段对生产进行测试。 + +* 引起很多问题。 + +* 它炸毁所有指标。 + + * 您不希望人们认为负载多于实际负载。 为了解决该问题，它又回到了上下文传播问题。 + + * 确保所有测试流量请求都具有表示此测试请求的上下文，因此以不同的方式处理指标。 这必须贯穿整个系统。 + +* **我希望知道的是**：我们真正想要做的是始终在所有服务中运行负载，因为许多错误仅在流量达到峰值时才会出现。 + + * 希望将系统保持在峰值附近，并随着实际流量的增加而退缩。 + + * 希望该系统很早以前就已建立，可以处理测试流量并以不同的方式处理它。 + +## 故障测试 + +* **我希望知道的内容**：并非每个人都喜欢 Chaos Monkey 等失败测试，​​尤其是如果您稍后要添加它时。 + + * 如果您不喜欢，我们应该做的是对您进行故障测试。 这只是生产的一部分。 您的服务只需要承受随机的杀戮，运行减慢和干扰。 + +## 迁移 + +* 我们所有的东西都是遗产。 全部都是迁移。 通常，从事存储工作的人们正在做的事情是从一个旧版迁移到另一个旧版。 + +* 有人总是在某处迁移某物。 不管人们在会议上怎么说，这就是每个人都在做的事情。 + +* 旧的东西必须保持工作状态。 业务仍然必须运行。 不再有维护窗口之类的东西。 可接受的停机时间。 + +* 随着您成为一家全球企业，没有高峰时间。 总是高峰时间在某个地方。 + +* **我希望知道的内容**：迁移的要求很糟糕。 + + * 没有人希望被告知必须采用某种新系统。 + + * 使某人发生变更是因为组织需要进行变更，而不是提供一个更好的新系统，因此显然您需要接受这一新事物。 + + * 纯胡萝卜，不粘。 无论何时出现问题，除非与安全性或合规性有关，否则这是不好的，强迫人们做事可能是可以的。 + +## 开源 + +* 没有人同意建立/购买权衡。 你什么时候建造？ 你什么时候应该买？ + +* 属于基础架构的任何东西，看起来像是平台的一部分而不是产品的一部分的任何事物，在某个时候都将成为无差异的商品。 亚马逊（或某人）将提供它作为服务。 + +* 最终，您花了所有时间在做这件事，其他人会以更便宜和更好的方式来做。 + +* **我希望知道的内容**：如果人们正在使用某种平台类型的功能，那么听到亚马逊刚刚发布您的服务即服务听起来并不好。 + + * 您仍在尝试合理化为什么应将自己的私人物品用作服务。 + + * 事实证明，那些人在这些文本编辑器的另一端。 人们对构建/购买权衡的判断方式存在巨大差异。 + +## 政治 + +* 通过将所有内容分解为小型服务，可以使人们玩政治。 + +* 每当您做出违反此属性的决定时，就会发生政治事件：公司>团队>自我。 + + * 您将自己的价值观置于团队之上。 + + * 团队的价值高于公司。 + +* 政治不只是您不喜欢的决定。 + +* 通过拥抱高度模块化的快速发展，非常快地雇用人员并尽快发布功能，人们开始倾向于违反此属性。 + + * 当您重视以较小的个人成就来交付产品时，很难确定对公司更有利的优先事项。 令人惊讶的权衡。 + +## 权衡取舍 + +* 一切都是权衡。 + +* **我希望知道的内容**：如何更好地有意进行这些折衷。 + + * 当事情在没有明确决定的情况下发生时，因为这似乎是事情的发展方向，即使没有明确做出决定，也要考虑做出什么权衡。 ## 相关文章 -* [Wikimedia 架构](http://highscalability.com/wikimedia-architecture)* [Domas Mituzas 的博客](http://dammit.lt) +* [关于 HackerNews](https://news.ycombinator.com/item?id=12697006) + +* 关于在 HackerNews 和 [上的视频](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) [的精彩讨论，关于[Reddit]](https://news.ycombinator.com/item?id=12597232) + +* [扩展流量高的 Feed 的设计决策](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html) + +* [Google 延迟容忍系统：将不可预测的部分做成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) + +* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) + +* [Uber 变得与众不同：使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) + +* [Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理百万个写入](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) + +* [用 Matt Ranney 缩放 Uber](http://softwareengineeringdaily.com/2015/12/04/engineering-at-uber-with-matt-ranney/) + +* [InfoQ 播客：Uber 的首席系统架构师，介绍其架构和快速发展](https://www.infoq.com/articles/podcast-matt-ranney) + +* [分布式 Web 架构：Matt Ranney，Voxer](https://gaming.youtube.com/watch?v=pXT0mF9bMyA) + +* [Riak at Voxer-Matt Ranney，RICON2012](https://vimeo.com/52827773) + +优步遍布 400 多个城市。 因此，请在帖子中更正此问题。 + +谢谢 + +这是我一生中读过的最好的经验教训文章之一。 这是一项毫不废话，诚实和实践的知识共享活动。 许多公司正在努力适应不断变化的新技术，例如微服务，CI / CD，Paas，Saas 和带有 Docker 的 Cass。 正如他在视频中正确指出的那样，这始终是一种思维方式/文化挑战，每个人对编程语言，方法等都有自己的看法。认识到这一事实并引导每个人完成业务需求的共同目标很重要。 + +难以置信！ 从头到尾纯粹基于经验的演讲 + +很棒的文章，有非常有用的信息。 -非常详细的文档确实涵盖了帖子中提到的大多数（或所有？）主题。 -我尚未读完它，仍在进行中，但是已经非常清楚，值得阅读，谢谢您的链接！ \ No newline at end of file +完全基于经验非常坦率非常实用。 他吸取的教训是休息的智慧。 \ No newline at end of file diff --git a/docs/234.md b/docs/234.md index 87e3a3a..18ab7b2 100644 --- a/docs/234.md +++ b/docs/234.md @@ -1,81 +1,188 @@ -# 普恩斯的教训-早期 +# QuickBooks 平台 -> 原文： [http://highscalability.com/blog/2007/10/8/lessons-from-pownce-the-early-years.html](http://highscalability.com/blog/2007/10/8/lessons-from-pownce-the-early-years.html) +> 原文： [http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html](http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html) -Pownce 是一种新的社交消息传递应用程序，它与 Twitter 和 Jaiku 之类的微消息竞争微消息。 仍处于封闭测试中，Pownce 慷慨地分享了到目前为止所学到的一些知识。 就像去桶中品尝年轻的葡萄酒，然后在陈酿后品尝相同的葡萄酒一样，我认为真正有趣的是跟随 Pownce，并将今天的 Pownce 与明天的 Pownce 进行比较，将其花了几年的时间。 桶。 等待 Pownce 成长，有什么教训？ +![](img/f467ec8cf4d38d56b883aa13f1ef804a.png) -网站：http：//www.pownce.com +*这是 Siddharth Ram –小型企业首席架构师的特邀帖子。 [[受电子邮件保护]](/cdn-cgi/l/email-protection#c497ada0a0aca5b6b0ac9bb6a5a984adaab0b1adb0eaa7aba9) 。* -## 信息来源 +QuickBooks 生态系统是最大的小型企业 SaaS 产品。 QuickBooks 平台支持面向全球范围内的小型企业，其客户和会计师的簿​​记，薪资和付款解决方案。 由于 QuickBooks 还是合规&纳税申报平台，因此报告的一致性非常重要。财务报告需要灵活的查询-给定的报告可能具有数十种可以调整的不同维度。 协作需要员工，会计师和企业所有者同时进行多次编辑，从而导致潜在的冲突。 所有这些都导致在 Intuit 解决有趣的缩放问题。 -* [经验教训-FOWA 2007](http://www.leahculver.com/2007/10/08/pownce-lessons-learned-fowa-2007/)* [Twitter 上的 Scoble 与 Pownce](http://scobleizer.com/2007/07/04/twitter-vs-pownce/)* [Founder Leah Culver's Blog](http://www.leahculver.com) +解决可伸缩性需要考虑多个时间范围和轴。 扩展不仅涉及扩展软件，还涉及人员可扩展性，流程可扩展性和文化可扩展性。 所有这些轴都在 Intuit 进行了积极的研究。 我们与员工的目标是营造一种氛围，使他们能够尽其所能。 - ## 该平台 +# 背景 - * 蟒蛇* Django 用于网站框架* [Amazon S3](http://www.highscalability.com/build-infinitely-scalable-infrastructure-100-using-amazon-services) 用于文件存储。* [适用于桌面应用程序的 Adobe AIR](http://labs.adobe.com/technologies/air/) （Adobe Integrated Runtime）* 记忆快取* 在 Facebook 上可用* [Timeplot](http://simile.mit.edu/timeplot/) for charts and graphs. +QuickBooks Online 产品已有十年半的历史了。 它是作为整体构建的，没有明确的关注点分离。 整体服务良好地服务于 Intuit –每天有数百万的客户使用它进行数亿笔交易。 这部分是可能的，因为产品内置了泳道。 这样就可以按公式拆分（客户在特定分片中“归位”）进行缩放。 如今，我们正在努力将整体拆分为多种服务，并迁移到 AWS 作为主要托管解决方案。 - ## 统计资料 +## 数字 - * 经过 4 个月的开发，并于 6 月进行了仅限受邀发布。* 最初是 Leah 的业余爱好项目，然后与 Digg 的 [Daniel Burka](http://deltatangobravo.com/) 和 [Kevin Rose](http://kevinrose.com/) 一起滚雪球成为一匹真正的马。* 小型 4 人团队和一位网站开发人员。* 自筹资金。* 一个 MySQL 数据库。* 功能包括： - -短消息，邀请事件，链接，文件共享（例如，您可以将 mp3 附加到消息中）。 - -您可以将用法限制为特定的朋友子集，并且可以将朋友分组。 因此，您可以将 mp3 发送给特定的朋友组。 - -它没有 SMS 网关，IM 网关或 API。 +* 全球小型企业最大的 SaaS 产品 - ## 架构 +* 超过 500 万的台式机和网络客户 - * 选择 Django 是因为它具有活跃的社区，良好的文档，良好的可读性，可扩展且可自动生成管理。* 选择 S3 是因为它最小化了维护并且价格便宜。 对他们来说是可靠的。* 选择 AIR 是因为它具有良好的嗡嗡声，易于开发，创建了不错的 UI 且是跨平台的。* 数据库一直是主要瓶颈。 攻击并修复缓慢的查询。* 静态页面，对象和列表使用 memcached 进行缓存。* 排队用于将更复杂的工作（例如发送便笺）推迟到以后。* 使用分页和良好的 UI 来限制执行的工作量。* 良好的索引有助于提高好友搜索的性能。* 在社交网站中： - -轻松创建和销毁关系。 - -朋友关系是正确显示最重要的信息，因为人们真的很在乎它。 - -在线世界中的朋友会产生现实效果。* 功能“偏向”于可伸缩性 - -您必须收到已经在 Pownce 上的人的邀请。 - -受邀者的数据中心只能承受增加的负载。 盲目上传地址簿可以成倍地吸引新用户。 限制不自然的增长是一个好主意。* 它们的功能集将扩展，但尚未准备好提交给 API。* Revenue model: ads between posts. +* 每天处理 250M +请求 - ## 得到教训 +* 年增长率超过 40％ - * 到目前为止，他们经历了四大课程： - -考虑技术选择。 - -多做点事。 - -善待您的数据库。 - -期待任何事情。* 拥有一个小的敬业团队，人们可以处理多个工作。* 使用开源。 它有很多，它是免费的，并且有很多很好的帮助。* 使用您的资源。 从网站文档中学习，使用 IRC，建立网络，参与社区和知识交流。* 通过确保在实现复杂功能之前确实需要它们，从而减少了数据库的工作量。* 培养有准备的头脑。 期待意料之外的事情，并迅速对不可避免的问题做出反应。* 使用版本控制并进行备份。* 维护大量与性能相关的统计信息。* 不要向用户承诺最后期限，因为您可能没有做到。* 与您的社区交流。 我特别喜欢这个，希望以后能做得更多。 我希望这种态度能够在增长中生存。 - -让他们知道您在做什么，以及有关新功能和错误修复的信息。 - -亲自回应各个错误创建者。* 看一下框架的自动生成的查询。 他们可能会吮吸。* 性感的用户界面和良好的动态营销活动可以吸引大量用户。 +* 通过 AWS 进行全球扩展 - ## 相关文章 +* 全球约有 2,000 名工程师在产品上工作。 - * [扩展 Twitter：使 Twitter 速度提高 10000％](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster)。 +* 2000+ 3 个基于 Intuit 平台构建的 和 参与者应用程序 -您在本文中多久一次错误地将 Pownce 拼写错误？ +## 技术 -喜欢这个网站。 注意您在帖子标题中拼写了 Pownce。 应该是 Pownce 而不是 Pounce。 +* Java / JVM 是主要服务/后端 -大卫 +* 多语言持久性–不同的用例需要使用不同的存储技术，QuickBooks 平台将 RDBMS（Oracle / MySQL），Neo4J 和 Cassandra 用于 OLTP 和 Hadoop & Vertica 进行分析 ->您在本文中多久一次错误地将 Pownce 拼写错误？ +* 前端已使用 ReactJS 进行了重建，我们了解到扩展不仅适用于后端-前端扩展是我们开发的一项新技能。 -哦，看起来真的很蠢。 从好的方面来说，它进行了拼写检查:-) +* 监控是使用多个内部和现成的工具完成的，现成的主要工具是 Splunk 和 New Relic -请不要让该站点陷入另一个 Web 2.0 圈套。 我对 Pownce 没什么兴趣-如今提到的一切都是必要的。 我们是否可以有更多有关具有实际扩展问题，新颖的解决方案和有趣的知识的网站的文章？ +* 通过企业 github 进行代码管理 -事先道歉，但我已经了解有关 pownce 的足够信息了……从中学到任何东西都是最重要的。 pownce 教给所有人的唯一一件事是，如果您的人脉关系良好，那么您就可以为任何垃圾而大肆宣传。 哇，我永远都无法想象。 这肯定在硅谷从未发生过。 +* ActiveMQ 和 Kafka 处理异步消息 --4 个人不是一个小团队。 一个 4 人的团队可以构建比 pownce 还要多得多的真实软件。 +* Ansible 和 Chef 用于配置管理 --使用开源。 它有很多，它是免费的，并且有很多很好的帮助。 -好的。 他们看了什么封闭源技术？ 它要多少钱？ 它可能提供什么好处？ 或者，也许您只是想拍打自己的背部。 多一点。 +* 大量使用边缘缓存和 Akamai WAA --使用版本控制并进行备份。 -谢谢。 我有没有告诉你你是多么的出色和聪明？ +## 文化 --数据库一直是主要瓶颈。 攻击并修复缓慢的查询。 --查看框架的自动生成的查询。 他们可能会吮吸。 -好吧，我猜想如果我 24 岁的话，这对我也是一个重要的学习。哦，对不起，我的意思是 24 岁而毫无头绪。 +* 每个服务都有定义了 RTO 和 RPO 的 HA / DR。 我们每周执行 HA / DR 计划，以确保在发生常规事件时对客户的影响很小甚至没有。 这是所有 SaaS 产品都需要计划和执行的最佳实践。 -即使作为 DeVry 技术学院的家庭作业，Pownce 也不是什么了不起的。 -只是工作中的名人-硅谷的洛杉矶化-事实是，这并不是天生的错误。 只是不要将其与任何实际的软件工程相混淆。 +* 高度重视弹性。 服务不可用通常并不意味着客户知道它。 -正如我在介绍中提到的那样，很有趣的是看到它们随着时间的变化和发展。 一些通常可能很有趣的事情：它们与台式机组件一起使用，这在如今已经很少见了； 从一开始就使用 S3； 以客户为中心 以及任何创业公司都会死的蜂鸣器。 从技术上讲可能还不是很多，但是事情的开始是最美好的，我喜欢抓住初创公司的时代精神。 +* 服务在内部服务门户中发布。 这使工程师可以重用其他团队构建的服务，并减少服务克隆。 ->查看框架自动生成的查询。 他们 ->可能会吮吸。 +* 性能是根据 TP99，TP90 和 TP50（通常更高）来衡量的。 TP50 代表第 50 个 第 个百分位客户体验的体验。 我们的目标是 1 秒的 TP50 和 2 秒的 TP90。 （即少于 10％的客户在任何给定页面上的页面加载时间超过 2 秒）。 -这是 Ruby on Rails Active Record 的开掘吗？ ;） \ No newline at end of file +* 客户互动失败（FCI）是我们跟踪的另一个关键指标。 与客户的每次失败交互（HTTP 4xx / 5xx）都被视为失败的交互。 我们的目标是使每项服务的 FCI 都低于 0.025％。 + +* 服务团队拥有端到端的服务。 他们负责与 devops 模型一致的服务维护和正常运行时间。 PagerDuty 用于提醒呼叫人员出现问题和参与恢复。 + +* 您无法改善无法测量的内容。 通过近乎实时的仪表板，可以在公司的可用性，性能，可扩展性和质量指标方面广泛了解公司。 这是驱动组织行为的关键。 + +* 我们正在过渡到反应性，松散耦合的系统 ，该系统可增强扩展能力。 但是，这需要仔细考虑如何处理系统中最终的一致性。 + +* 工程师对系统中的每个故障执行 RCA（根本原因分析）。 RCA 已由工程领导审核。 我们将 5 个“为什么”和“鱼骨”应用于每个 RCA。 失败是一位出色的老师 。 + +* 强烈的代码意识和域所有权。 + +* 任务驱动。 当人们看到自己对客户的影响时，便会尽自己最大的努力。 + +* 在质量，性能，可用性和安全性上丝毫不妥协。 + +* 持续部署和功能切换使我们能够快速交付 + +## 可伸缩性中的有趣挑战 + +# 缩放比例特性 + +QuickBooks Online 之类的产品具有与其他 SaaS 产品不同的缩放特性。 报表查询可能已应用了许多其他过滤器。 这些查询在公司之间通常是不同的。 报告会产生税收后果，因此必须始终与账簿保持一致。 会计和小型企业所有者可能同时进行多次编辑，才能进行协作。 该软件需要确定如何处理冲突。 所有这些导致在 Intuit 的 QuickBooks 平台上进行扩展的有趣方式。 + +# 变量 + +QuickBooks 平台为全球数百万家小型企业，其客户和会计师提供服务。 为客户提供各种用例：产品需要解决的可变性包括： + +* 设备多样性–我们根据需要为客户提供服务-台式机，移动设备，在线 + +* 地理多样性–在全球范围内使用，伴随着法规的复杂性，要​​解决的税收往往非常本地化和专业化 + +* 合规性多样性–不同的政府机构（例如工资税）对合规性有不同的规定 + +* 产品多样性–根据员工人数，他们要解决的市场性质（例如，基于产品的业务与基于服务的业务），不同的客户群具有不同的需求 + +* 工作流的多样性–公司可能拥有执行（并被授予）产品子集的工人。 例如，应收账款业务员将仅看到应收帐款流量。 员工通常不执行业务报告。 + +这是我们处理的多样性的子集。 尽管解决了很多多样性问题，但平台始终需要解决一些基本问题。 安全性，隐私性，可伸缩性和质量是软件基本构建模块的一部分。 + +# 缩放哲学 + +QuickBooks 平台通常在以下三个方面进行扩展，从而遵循“可扩展性多维数据集” 模型： + +![](img/e14850f4600ff2e4f07d4add57be0c4a.png) + +## X 轴–只读副本 + +X 轴主要用于只读副本。 与许多 SaaS 产品一样，与写入次数相比，读取次数很多。 常见的且相对昂贵的读取操作是报告。 小型企业和会计师需要了解他们的业务状况。 我们通过 QuickBooks Money Bar 提供见解，并通过大量报告（例如资产负债表，损益报告）提供更详细的见解。 只读副本使我们既可以减少访问的热点，又可以提供预先计算的报告 + +## Y 轴-服务 + +扩展的第二个方面是在不同的服务中破坏产品。 QuickBooks 平台建模为 14 个不同的域，这些域组成了产品。 服务 API 现在是第四个修订版– V3 QuickBooks API 可以在 [http://developer.intuit.com](http://developer.intuit.com) 中找到。 + +### Z 轴-公式拆分 + +Z 轴指的是“分片”（sharding）-允许大范围缩放的非规范化数据。 QuickBooks 根据公司的属性来拆分客户。 然后，每个分片将与具有类似属性的其他公司共享。 + +### C 轴 + +除了这些方面，我们经常谈论“ C”轴-文化轴，这是我们扩展规模的关键方法。 在 C 轴上对我们的主要增强是（a）度量文化–您无法解决无法观察到的问题（b）通过 devops 模型拥有所有权的文化，以及（c）我们做任何事情的客户支持的思想。 + +### 缩放前端 + +在 200KLOC 以上，QuickBooks onlike 具有非常大的 Javascript 占用空间。 扩展前端的一部分意味着要理解如何确保更改被隔离并且组件可重复使用–到 3 rd 参与者可以直接插入前端的地步，并且 任何遵循规则的人都可以贡献力量。 缩放还意味着在样式上具有统一性，易于坚持。 + +## 公有云之旅 + +Intuit 的一项关键策略是将所有软件资产移至 AWS。 在公共云中，给定共享的基础架构，还需要考虑安全性和隐私性。 在将软件迁移到 AWS 时，我们使用以下一般原则： + +* 必须保护每个端点。 在公共云中，我们不能假设服务之间的链接是安全的端点。 + +* 每个 Intuit 和 AWS 平台服务都必须是可观察的。 这种可观察性是能够分析欺诈和安全性访问的关键。 + +* 提升并移动+分解。 在适当的情况下，我们将分解为服务并迁移到公共云。 对于较大的系统，我们进入 AWS 基础架构并就地分解。 + +* 多区域 DR。 区域中断发生。 我们希望即使在单个地区受到影响时也能够提供服务。 + +* 在本地服务客户。 安全港 和性能都决定了靠近客户的数据存储。 这就要求客户必须在本地区域“居住”（例如，在欧洲的 AWS 数据中心之外服务的欧盟客户）。 + +* 爆炸半径遏制。 “无共享”方法可确保我们限制爆炸半径。 系统中断应该导致本地事件，而不是全局事件。 + +## 主要课程 + +* 3 轴缩放是关键。 知道哪些轴适用于正确缩放有助于缩放。 + +* 确保可以控制影响。 必须充分理解和测试系统的爆炸半径。 + +* RCA –失败是一位了不起的老师。 浪费失败的教训是可耻的。 架构师负责分析故障并找出根本原因。 + +* 不要低估了对在公共云中保护软件的重新思考的程度。 + +* Dogfood。 公司工程师使用的服务应与为 3 个 和 参与方开发人员提供的服务相同。 + +* 了解您的 KPI 并能够预测性能曲线的样子–这有助于快速识别出问题所在。 + +* 也可以缩放前端，而不仅仅是后端。 + +嗨，感谢您的帖子，它非常有用。 我想知道为什么您同时使用 ansible 和 Chef，因为我希望一家公司同时使用其中一种？ + +嗨，查理， + +并没有 Ansible 和 Chef 的强烈技术理由。 不同的团队使用了不同的技术。 随着时间的流逝，我们将逐步淘汰其中之一。 + +悉达思 + +您好 Siddharth， + +感谢您花时间描述系统。 由于您将整体拆分为服务，因此如何管理服务之间的安全性和身份验证？ + +嗨，knguyen， + +好问。 在整体中，通信相对容易-只需进行另一个函数调用即可。 在分布式系统中，难度会增加一些-但技术仍然非常相似。 + +身份验证和安全协议是非常标准的。 Intuit 管理自己的身份系统。 每个请求必须具有身份验证上下文-包括服务器-服务器调用。 这些将很快到期，并分配新的票证。 SSL / TLS 是用于有线加密，客户端-服务器以及服务器-服务器通信的标准问题。 分析/监视查找访问模式中的异常。 + +您如何管理服务之间的安全性和身份验证？ + +据我所知，Intuit 使用 google oauth1.0 进行身份验证，这基本上是基于令牌的身份验证系统。 例如，您有一个使用者密钥和一个使用者密钥，您将获得一个请求密钥和请求令牌，然后吐出一个访问令牌和访问密钥。 令牌有效期为 6 个月，不确定令牌何时到期才能访问那些基于 JAVA 的 REST API 和安全标准 SHA2 算法。 我写了一篇关于 SSL 握手的文章。 它应该有助于提供见解。 + +参考： +https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/ + +嗨， +很棒的文章，感谢您的分享，您可以解释一下是否有建立另一个 QuickBooks 或 Zoho Books 的余地？ +谢谢 +Divya， +[Quickbook Developer](http://www.catchexperts.com/quickbook-online-training) \ No newline at end of file diff --git a/docs/235.md b/docs/235.md index bdb7e00..a8667b0 100644 --- a/docs/235.md +++ b/docs/235.md @@ -1,135 +1,103 @@ -# Fotolog 扩展成功的秘诀 +# 美国大选期间城市飞艇如何扩展到 25 亿条通知 -> 原文： [http://highscalability.com/blog/2007/10/2/secrets-to-fotologs-scaling-success.html](http://highscalability.com/blog/2007/10/2/secrets-to-fotologs-scaling-success.html) +> 原文： [http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html](http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html) -Fotolog 是一个以照片为中心的社交博客网站，从 2004 年的 30 万用户增长到 2007 年的 1100 万用户。尽管他们最初经历了快速增长的不可避免的痛苦，但他们克服了问题，现在管理着 3 亿张照片和 80 万张照片 每天都会添加新照片。 产生如此美妙的内容的是每月有 2000 万唯一身份访问者，以及每天由 30,000 新用户组成的志愿军。 他们的表现如此出色，一个令人印象深刻的求婚者以 9000 万美元的高价买下了他们。 这样的规模可以满足任何人的成功标准。 他们是如何做到的呢？ +![](img/8a073c8483bfc1f227aed0829dbb7f84.png) -网站：http：//www.fotolog.com +*这是 Urban Airship 的来宾帖子。 贡献者：亚当·洛瑞（Adam Lowry），肖恩·莫兰（Sean Moran），迈克·赫里克（Mike Herrick），丽莎·奥尔（Lisa Orr），托德·约翰逊（Christine Ciandrini），阿什什·沃蒂（Ashish Warty），尼克·阿德雷德（Nick Adlard），梅勒·萨克斯·巴尼特（Mele Sax-Barnett），尼尔·凯利（Niall Kelly），格雷厄姆·福里斯特（Graham Forest）和加文·麦奎兰* -## 信息来源 +Urban Airship 受到数以千计希望通过移动技术发展的企业的信任。 Urban Airship 是一家成立 7 年的 SaaS 公司，拥有免费增值业务模式，因此您可以免费试用 [](https://www.urbanairship.com/lps/best-push-notification-service)。 有关更多信息，请访问 [www.urbanairship.com](http://www.urbanairship.com/) 。 目前，城市飞艇平均每天发送的推送通知超过 10 亿条。 这篇文章重点介绍了 2016 年美国大选的城市飞艇通知使用情况，探讨了系统的架构-核心传递管道-为新闻发布者提供数十亿次实时通知。 -* [扩展世界上最大的照片博客社区](http://www.slideshare.net/frankmashraqi/fotolog-scaling-the-worlds-largest-photo-blogging-community)* [祝贺 Fotolog 向 Hi-Media 出售$ 90mm 的交易](http://www.beyondvc.com/2007/08/congrats-to-fot.html)* [Fotolog 超越 Flickr 吗？](http://www.kottke.org/07/01/fotolog-overtaking-flickr)* [Fotolog 吸引了 1100 万会员和 3 亿张照片](http://www.stockphototalk.com/the_stock_photo_industry_/2007/09/fotolog-hits-11.html)* [本周网站：PC Magazine 的 Fotolog.com](http://www.pcmag.com/article2/0,1895,2150030,00.asp)* [CEO John Borthwick 的博客](http://www.borthwick.com/weblog/category/fotolog/)。* [DBA Frank Mash 的博客](http://mysqldatabaseadministration.blogspot.com)* [Fotolog, lessons learnt](http://www.borthwick.com/weblog/2008/01/09/fotolog-lessons-learnt/) by John Borthwick +## 2016 年美国大选 - ## 该平台 +在选举日前后的 24 小时内，Urban Airship 发出了 25 亿条通知，这是有史以来的最高日发送量。 这相当于在美国每人 8 条通知，或者世界上每部活动的智能手机 1 条通知。 虽然 Urban Airship 在每个行业垂直领域为超过 45,000 个应用程序提供支持，但对选举使用情况数据的分析显示，超过 400 种媒体应用程序占了这一记录量的 60％，随着跟踪选举结果并在一天之内发送 15 亿条通知 报告。 - * 爪哇* 的 PHP* Sun* Solaris 10* 的 MySQL* 阿帕奇* 冬眠* 记忆快取* [3PAR](http://www.3par.com/index.php) （用于实用程序计算的简单，高效且可扩展的分层存储阵列）* [IBRIX](http://www.ibrix.com/) （单个名称空间并行文件系统，可伸缩的卷管理器，高可用性功能）* 强邮* CDN: Akamai/Panther +![](img/36ce3f158f2a647278f8b998ea2b34fc.png) - ## 统计资料 +总统选举结束时，通知量稳定并达到顶峰。 - * 从 2002 年开始。在 2004 年，他们有大约 30 万或 40 万成员，3 名员工，没有可扩展的基础架构，也没有收入模型。* 由于快速增长，该站点经常遇到技术问题，2005 年他们不得不将新的免费成员限制为每天 1,000 名。* 2007 年，他们拥有超过 1100 万用户，并以 9000 万美元的价格卖给了 Hi-Media。* 成员来自 200 多个国家/地区，多数在南美。 超过 20％的网页浏览量来自欧洲。 他们拒绝了以美国为中心的战略，而是建立了一个全球性和互动性的受众。* 每月产生超过 35 亿的页面浏览量，每月接待超过 2000 万的唯一身份访问者，并获得了 Alexa 排名前 20 位。* 管理超过 3 亿张照片，每天上传超过 500,000 张照片。* 每天新增 30,000 多个新成员，每天吸引 460 万以上的用户。 无需市场营销或会员激励即可扩展。* 超过 500 个用户生成的社区。* 20％的成员每天访问该网站，平均花费 24 分钟。* 32 个 MySQL 服务器和 30 个 memcached 服务器群集。 +![election-urbanairship-notification.png](img/ed7aba40e08757f46f3ab55d602e8ec5.png) - ## 架构 +到城市飞艇的 HTTPS 入口流量 [API](http://docs.urbanairship.com/api/ua.html) 在选举期间达到了每秒近 75,000 的峰值。 这些流量大部分来自城市飞艇 [SDK](http://docs.urbanairship.com/dev-resources.html) 与城市飞艇 [API](http://docs.urbanairship.com/api/ua.html) [ 。 - * 网站最初是用 PHP 编写的。 - -他们的新“ Fotolog 成员页面”功能是用 Java 编写的，具有显着的性能改进。 页面更清洁，响应时间更短。 - -他们现在使用不到一半的盒子为网站提供服务。 - -由于性能提高以及需要注册才能发布留言簿消息，因此每日注册量增加了 35％以上。 - -新的代码库使他们可以在会员体验方面进行更多创新。 +![election-urbanairship-HTTPS.png](img/f308127dc795976d958424e5b22196a5.png) - * 他们已经超过 Flickr，成为了牢固的 Web 1.0 应用程序。 - -没有标签，没有 API，没有 JavaScript 窗口小部件，也没有 Ajax。 - -他们具有西班牙语选项，可以将网站扩展到广泛的用户群。 - -他们使用的文字很少。 它主要是可视的，因此可以被广泛的用户使用。 - -他们的界面是可定制的，许多人喜欢表达自己的身份。 - -他们的唯一访问者比 Yahoo 的访问者少 1 毫米，但网站上的总访问时间却是 Yahoo 的两倍，网页的访问时间是 3 倍。 +推送通知量一直在迅速增加。 最近的主要推动力是英国退欧，奥运会和美国大选。 2016 年 10 月，每月通知量同比增长 150％。 - * 收入模式： - -金牌会员（每月约 5 美元）意味着您每天可以上传 6 张照片，而不是 1 张，每张照片有 200 条评论，而不是 20 条，这是您个人资料的自定义标题图片，是您的微型缩略图 留言簿中您名字旁边显示的最新照片，以及在首页上显示您的照片的可能性。 - -Adsense。 考虑到来自来宾簿的其他上下文数据，来自 Google 的收入增长趋势预计约为 15％。 - -将在其成员中转向点对点广告。 - -会员将能够使用小额付款服务买卖真实和虚拟物品。 +![monthly-sends.png](img/edd6f898ff8977d6b6b3e7259682ce3e.png) - * 他们有每天发布一次的规则，即用户每天只能发布一张照片。 该规则不会抑制增长，而是通过增加观看照片的机会并吸引正面评论来确保质量并产生出色的用法。 人们通常会在博客上说不出话来，而人们总是可以找到要拍照，上传和谈论的图片。* 只能上传小于 2,000 kb 的照片。 它们会自动调整为 500x500 格式。 页面看起来更整洁，加载速度更快。* 模型正在浏览搜索。 鼓励机会性的偶然性寻宝活动。* 无需许可即可自动添加朋友。 这会为您的照片吸引观众。* 支持按组浏览功能，该功能具有“颜色”和“情感”等类别。* 该网站特意简单。 - -他们抵制了一个又一个地添加功能的诱惑。 相反，他们的愿景是提供一些功能，类似于 Craig 的列表，重点是内容和对话。 - -页面必须具有社交性。 - -页面不仅需要包含您的图片，还需要包含来自整个网络的图片，以提供可视化导航，从而今天可以驱动他们的会员在网站上花费的大部分时间，这是一个自我形成的有机分布系统，让会员可以看到 并被看到。 - -注释和留言簿条目是对这种图像社交网络的补充，使这种体验成为媒体与交流相交的地方，每天都有数以百万计的图像与数十亿次对话相撞。* Photobucket 与 Fotolog - -Photobucket 存储基于图像的媒体，然后将其分发到 Myspace，Bebo，Piczo，Friendster 等社交网站上的页面上。 - -Fotolog 是目标。 - -第一代社交网站强调通过连接（从 Geocities，Tripod 到 Blogger）进行自我发布。 下一代主要关注人际关系（六度和 Friendster 是这里的经典示例-收集朋友和人际关系的工具，因为社会资本在理论上是与人际关系最多的人积累的）。 第三代和当前的站点将媒体与联系融合在一起-每个站点都有不同的侧重点。 +## 核心交付管道架构概述 - * 备份：Sun 6540 磁盘阵列* 他们的 32 台 SQL 服务器分为四个集群 - -用户，GB（来宾），PH（照片），FF（朋友和收藏夹列表） - -使用非持久连接。 - -Java 端的连接池。 - -InnoDB - -分区由应用程序层处理。* 每个群集： - -带有一组应用程序服务器。 - -分为一组碎片。 - -每个分片都有 MySQL 只读主-主配置，该配置提供了几个只读从属。 - -应用服务器将其读取请求发送到从属服务器，并将其写入请求发送给主服务器。 - -基于某种特定于群集的分区密钥将数据分配给共享。 幼稚的分区算法可能会导致非常不均匀的分片负载，您希望每个分片上的负载更加均衡。* MySQL 仅用于存储图像元数据。 这似乎很标准。 几乎没有人似乎在数据库中存储重要的 Blob，因为它会减慢数据库操作的速度。* 照片存储使用 3PAR 和 IBRIX。 CDN 用于热点内容。* 虚拟存储系统尽管价格昂贵，但运行良好。* 随着更多选择的使用，自动递增密钥的锁争用也会增加。* 通过数据库优化，他们已经能够在同一 32 台数据库服务器上从 400 万成员增长到 1100 万成员。 这也提高了在 Solaris 10 上运行 MySQL 的效率，并增加了内存缓存群集，移植到 Java 并增加了 RAM。* Happy with memcached. - - Created a distributed cluster of 50 memcached servers with a total cache size of approximately 150 gigabytes, supporting around 4 billion page views/month. Peak load times dropped from 10 seconds to 2 seconds. - - Quote from [CTO](http://mashraqi.com/labels/memcached.html) : +核心交付管道（CDP）是城市飞艇系统，负责从观众选择器中实现设备地址，并传递通知。 无论我们同时发送给数千万用户，针对多个复杂的子细分受众群，包含个性化内容或介于两者之间的任何内容，我们发送的所有通知都期望低延迟。 这是我们的架构的概述，以及我们在此过程中学到的一些知识。 - > *我有一个新的内存缓存用户要添加到您的列表中：我们在世界最大的照片博客社区 Fotolog 上使用它，我们很喜欢。 我刚刚滚动了我们的第一个代码以将其用于今天的生产，它一直是救生员。 我迫不及待地开始在依靠伯克利数据库来分担某些数据库工作的地方开始使用它。 我们也不是每天浏览数百万页的网站。 Fotolog 是一个每月十亿页以上的网站（每天对我们而言典型的浏览量是 35 到 4000 万）。 最近，我们克服了一些与数据库相关的重大性能问题，这些问题使我们的网站流量激增，并且在流量负载沉重的情况下再次陷入停滞（恢复到 10 秒，有时在高峰时段加载页面）。 每次可以轻松地以相同的形式共享列表至少 5 到 10 分钟时，服务器就会浪费时间重新创建列表。 因此，我们引入了内存缓存，创建了一个总共有 4 个演出的分布式 30 服务器集群，并制作了一个非常小的代码 mod 以使用内存缓存，并且我们的高峰时段加载时间回落到 2 秒左右。 它允许持续增长和令人难以置信的效率。 我无法说何时对如此简单的作品感到满意。”* +### 我们是如何开始的 - ## 得到教训 +最初从 2009 年开始是一个 Web 应用程序，当时有些工人已经转变为面向服务的体系结构。 随着旧系统的各个部分开始遇到规模问题，我们将它们提取到了一个或多个新服务中，这些服务旨在满足相同的功能集，但规模更大且性能更好。 我们许多原始的 [API](http://docs.urbanairship.com/api/ua.html) API 和工作人员都是用 Python 编写的，然后将它们提取到高并发 Java 服务中。 在最初将设备数据存储在一组 Postgres 分片中的地方，我们的规模迅速超过了添加新分片的能力，因此我们转向使用 HBase 和 Cassandra 的多数据库体系结构。 - * 受欢迎程度是由活跃的用户群驱动的，而不是丰富的炫酷功能。* 网络是全球性的，它的尾巴很长。 通过以语言和特定于文化的设计吸引美国以外的用户，您可以与大个子竞争。 对于 Google，Yahoo 等而言，最艰难的竞争来自本地初创公司，他们着眼于当地人的需求。* 如果您想获得大量嗡嗡声，请执行 alpha 怪胎希望您做的任何事情。 如果您想让很多快乐的用户去做他们想要您做的事情。* 像诗歌一样，网站中的约束可以使事情变得出乎意料的更好。 每天只允许用户发布一张照片的规则创建了一个环境，使人们对彼此的照片发表更多评论，从而创建了一个更加互动的社区。 谁知道？* 限制您的网站。 限制图片，评论等的大小，以免资源使用量急剧增加。* 有远见。 对您的网站应该是什么以及为什么要有一个深刻的认识，然后利用这一愿景来决定您应该构建什么以及应该如何构建它。 他们围绕每日照片构建的社交网站的愿景导致了一个与您的目标是存储所有照片的网站截然不同的网站。* 可以添加创收功能，而不会破坏网站的完整性。 我非常喜欢他们如何免费为人们提供合理的功能集，然后为他们需要的更多资源收取费用。 这些功能还有助于扩展和增强其网站的社交视野。 看看他们的新获利策略如何发挥作用将很有趣。* 不要害怕扩大规模。 通过添加更多的缓存，更多的 RAM，更多的 CPU 和更高效的 CPU，您可以在相同数量的计算机上处​​理更多的负载。 从数据中心空间和强大的 POV 来看，这是一件好事。* 使 MySQL 执行： - -查找问题的根源。 - -成熟的系统主要是磁盘绑定的。 - -查询缓存可能会伤害您。 - -添加 RAM 以帮助躲避子弹。 - -分割磁盘。 - -重组表以获得最佳性能。 - -使用 libumem.so 查找内存泄漏。* 要记住的事情： - -了解问题 - -了解您的应用程序 - -了解您的存储引擎 - -了解您的要求 - -了解您的预算 - -使用所有这些信息来决定 系统的哪些部分真正需要投入时间，金钱和测试才能实现高可用性。 +CDP 是处理分段和推送通知传递的服务的集合。 这些服务根据请求提供相同类型的数据，但是出于性能原因，每个服务都以非常不同的方式对数据进行索引。 例如，我们有一个系统负责处理广播消息，向注册到相关应用程序的每个设备传递相同的通知有效负载。 该服务及其底层数据存储区的设计与我们负责根据位置或用户个人资料属性传递通知的服务的设计有很大不同。 - ## 相关文章 +我们将任何长期存在的进程视为一项服务。 这些长期存在的过程遵循有关度量，配置和日志记录的通用模板，以简化部署和操作。 通常，我们的服务属于以下两类之一：RPC 服务或使用者服务。 RPC 服务使用非常类似于 GRPC 的内部库提供命令来与服务进行同步交互，而消费者服务则处理来自 Kafka 流的消息，并对这些消息执行特定于服务的操作。 - * [Flickr 架构](http://highscalability.com/flickr-architecture)* [数据库设计的非传统方法：碎片](http://highscalability.com/unorthodox-approach-database-design-coming-shard)的来临 +![urbanairship-cdp.png](img/8f0bf13a515234268219ff976be393a9.png) -托德 +### 数据库 -嗨，我是 Fotolog 的 CTO，您在组装和分析所有这些信息方面做得非常出色。 知道那里仍有记者愿意做腿法，这真是令人鼓舞。 我只想做几个小笔记。 在统计方面：我们现在每天大约增加 800,000 张照片...主页计数器有时可能会滞后。 此外，我们首次实现内存缓存时就写了内存缓存引号。 我们目前对它的使用更为广泛。 现在，我们在大约 50 台服务器上运行它，总缓存大小约为 150 GB，每月支持大约 40 亿的页面浏览量。 此外，我们仍处于 ibrix 实现的中间。 +为了满足我们的性能和规模要求，我们严重依赖 HBase 和 Cassandra 来满足我们的数据存储需求。 尽管 HBase 和 Cassandra 都是列式 NoSQL 存储，但它们的取舍却大不相同，这些折衷影响我们使用哪个存储以及用于什么目的。 -再次，伟大的工作。 +HBase 非常适合高通量扫描，响应的预期基数很高，而 Cassandra 非常适合低基数查找，其中响应仅包含少量结果。 两者都允许大量的写入吞吐量，这是我们的要求，因为来自用户手机的所有元数据更新都是实时应用的。 --沃伦 +它们的故障特性也不同。 在发生故障时，HBase 支持一致性和分区容忍度，而 Cassandra 则支持可用性和分区容忍度。 每个 CDP 服务都有一个非常特定的用例，因此具有高度专业化的架构，旨在促进所需的访问模式并限制存储空间。 通常，每个数据库仅由单个服务访问，该服务负责通过不太专门的界面提供对其他服务的数据库访问。 -感谢您的晋升，但我只是一个可替换的程序员部门：-)我必须承认，直到您被收购时，我才听说过 Fotolog，但这是一个有趣的故事。 您如何将愿景和网站完美地结合在一起，可以学到很多东西。 +加强服务与其支持数据库之间的 1：1 关系具有许多好处。 -并感谢您的更新。 那是很多照片，我想您为什么选择 Ibrix。 您能否谈谈为什么要使用 Ibrix，希望完成什么以及如何为您工作？ +* 通过将服务的支持数据存储视为实现细节而不是共享资源，我们可以获得灵活性。 -嗯，内存缓存。 当我*没有*看到它部署时，我感到很惊讶。 +* 我们可以在不更改服务代码的情况下调整服务的数据模型。 -另一方面，我认为这很有趣：“他们有一个每天发布一次的规则，即用户每天只能发布一张照片。” 我从未听说过如此严格的限制。 +* 使用情况跟踪更为直接，这使容量规划更加容易。 -- -Dustin Puryear -作者，“管理 Linux 和 UNIX 服务器的最佳实践” -[http://www.puryear-it.com/pubs/linux-unix-best-practices](http://www.puryear-it.com/pubs/linux-unix-best-practices) +* 故障排除更加容易。 有时服务代码存在问题，而其他时候则是备份数据库问题。 将服务和数据库作为逻辑单元可以极大地简化故障排除过程。 我们不必怀疑“还有谁可以访问该数据库以使其表现为这种方式？” 相反，我们可以依靠服务本身的应用程序级指标，而只担心一组访问模式。 ->我从未听说过如此严格的限制。 +* 因为只有一种服务与数据库交互，所以我们几乎可以执行所有维护活动，而无需停机。 繁重的维护任务成为服务级别的问题：可以在不中断服务的情况下完成数据修复，模式迁移，甚至切换到完全不同的数据库。 -我认为这不是资源 POV 的局限性，而是创建某种社区的一种方式。 这就是为什么我认为这是一个如此出色的举动。 +的确，在将应用程序拆分为较小的服务时，可能需要进行一些性能折衷。 但是，我们发现，在满足高可伸缩性和高可用性要求方面获得的灵活性远远超过了其价值。 -信息太少：） -您是否正在使用 memched 将数据缓存在前端 Web 服务器，数据库或应用程序服务器（或全部）上。 您正在使用哪种应用服务器。 您在应用服务器上使用哪种缓存提供程序？ 它是事务性的吗（如果不是，您是否在应用程序本身中管理事务，例如通过使用 EJB3 版本注释）？ +### 数据建模 -感谢您撰写此摘要。 +我们的大多数服务都处理相同的数据，只是格式不同。 一切都必须保持一致。 为了使所有这些服务的数据保持最新，我们严重依赖 Kafka。 Kafka 非常快，也很耐用。 速度需要权衡。 仅保证 Kafka 邮件至少发送一次 ，并且不能保证依次发送。 -我喜欢普及性是关于用户而不是功能，以及愿景应对公司产生的影响。 我最近在 [http://trooji.wordpress.com/2007/12/04/soviet-vs-us-design-philosophy/](http://trooji.wordpress.com/2007/12/04/soviet-vs-us-design-philosophy/) 阅读了类似的文章 +我们如何处理？ 我们已将所有变异路径建模为可交换的：可以以任何顺序应用操作并最终得到相同的结果。 它们也是幂等的。 这有一个很好的副作用，我们可以重放 Kafka 流以进行一次性数据修复作业，回填甚至迁移。 -嗨，沃伦，Fotolog 的 CTO，您将休眠与 memcached 一起使用还是开发了自己的缓存管理系统？ +为此，我们利用了 HBase 和 Cassandra 中都存在的“单元版本”的概念。 通常，这是一个时间戳，但可以是您想要的任何数字（有一些例外；例如，MAX_LONG 可能会导致一些奇怪的行为，具体取决于您的 HBase 或 Cassandra 的版本以及架构如何处理删除）。 -我想知道是否有人使用 memcached 作为休眠的缓存解决方案。 +对我们来说，这些单元格的一般规则是它们可以具有多个版本，而我们订购版本的方式则取决于它们提供的时间戳。 考虑到这种行为，我们可以将传入的消息分解为一组特定的列，然后将该布局与自定义应用程序逻辑结合起来进行逻辑删除，同时考虑时间戳。 这样可以在保持数据完整性的同时盲写基础数据存储。 -问题：在此过程中，PNG 是否被用作扩大成功的手段？ 如果是这样，请描述可能的过程。 +仅仅盲目地将更改写入 Cassandra 和 HBase 并非没有问题。 一个很好的例子是在重放事件中重复写入相同数据的情况。 尽管由于我们努力使记录成为幂等，数据的状态不会改变，但必须压缩重复的数据。 在最极端的情况下，这些额外的记录可能会导致大量的压缩延迟和备份。 由于这个细节，我们密切监视压缩时间和队列深度，因为在 Cassandra 和 HBase 中落后于压缩会导致严重的问题。 -感谢您撰写此摘要。 +通过确保流中的消息遵循一组严格的规则，并设计使用服务以预期乱序和重复的消息，我们可以使大量不同的服务仅与一两秒钟保持同步 滞后的更新。 -Fotolog 的惊人发展。 出于好奇，我想知道它使用了哪些收入流来产生收入。 他们打算使用 [http://www.stumblehere.com“](在线分类还是基于广告的获利解决方案？ +### 服务设计 -这全都与名声有关。 即使您的网站没有任何内容，如果您拥有良好的搜索引擎优化 ------ -[http://underwaterseaplants.awardspace.com“](海洋植物 -[http://underwaterseaplants.awardspace.com/seagrapes.htm“](海葡萄... [http://underwaterseaplants.awardspace.com/plantroots.htm “](植物根 +我们的大多数服务都是用 Java 编写的，但是使用的是一种自以为是的现代风格。 在设计 Java 服务时，我们要考虑一组通用准则： -这真的是很棒的信息，谢谢，这正是我所需要的 \ No newline at end of file +* **做一件事，做好它。** -设计服务时，它应该承担单一责任。 实施者可以决定职责中包括的内容，但是她或他将需要准备在代码审查情况下证明其合理性。 + +* **没有共享的操作状态** -设计服务时，假定将始终至少有三个实例在运行。 服务需要能够在没有任何外部协调的情况下处理任何其他实例可以处理的相同确切请求。 那些熟悉 Kafka 的人会注意到，Kafka 使用者在外部协调对 topic：group 对的分区所有权。 本指南涉及特定于服务的外部协调，而不是利用可能在幕后进行外部协调的库或客户端。 + +* **约束您的队列** -我们在所有服务中使用队列，它们是将请求分批并将其散布到最终将完成任务的工作人员的好方法 从外部阻止。 所有队列都应有界。 边界队列确实引发了许多问题，但是： + + * 当队列已满时，生产者会怎样？ 他们应该阻止吗？ 除？ 下降？ + + * 我的队列应该有多大？ 要回答此问题，有助于假设队列始终已满。 + + * 如何完全关闭？ + + * 根据确切的用例，每个服务将针对这些问题提供不同的答案。 + +* **命名自定义线程池并注册 UncaughtExceptionHandler** -如果最终创建自己的线程池，则使用 [的构造函数或帮助器方法 ]执行器](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html) ，以便我们提供 ThreadFactory。 使用该 ThreadFactory，我们可以正确地命名线程，设置线程的守护进程状态，并注册 [UncaughtExceptionHandler](https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler-) 以处理将异常置于顶部的情况 堆栈。 这些步骤使调试我们的服务变得更加容易，并且使我们避免了深夜的挫败感。 + +* **优先于可变状态而不是可变状态** -在高度并发的环境中，可变状态可能很危险。 通常，我们使用可以在内部子系统和队列之间传递的不可变数据对象。 拥有不变对象是子系统之间通信的主要形式，这使得并发使用的设计更加简单，并且使故障排除更加容易。 + +## 我们从这里去哪里？ + +凭借 Urban Airship 通过移动钱包通行证发送通知的功能，对 Web 通知和 Apple News 通知的新支持以及其将通知发送到任何平台，设备或营销渠道的开放渠道功能，我们预计通知量将成倍增长 。 为了满足这一需求，我们将继续在“核心交付管道”架构，服务，数据库和基础架构上进行大量投资。 要了解有关我们技术的更多信息以及前进的方向，请参阅 [GitHub](https://github.com/urbanairship) ， [开发人员资源](http://docs.urbanairship.com/dev-resources.html) ， [文档](http://docs.urbanairship.com/index.html) 和我们的 [职位页面](https://www.urbanairship.com/careers) 。 \ No newline at end of file diff --git a/docs/236.md b/docs/236.md index 3f96c66..eeb3ce0 100644 --- a/docs/236.md +++ b/docs/236.md @@ -1,211 +1,530 @@ -# 亚马逊建筑 +# Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题 -> 原文： [http://highscalability.com/blog/2007/9/18/amazon-architecture.html](http://highscalability.com/blog/2007/9/18/amazon-architecture.html) +> 原文： [http://highscalability.com/blog/2017/3/15/architecture-of-probot-my-slack-and-messenger-bot-for-answer.html](http://highscalability.com/blog/2017/3/15/architecture-of-probot-my-slack-and-messenger-bot-for-answer.html) -*这是基于乔亚希姆·罗德（Joachim Rohde）对亚马逊 CTO 采访的发现而提供的非常有用的亚马逊更新。 您将了解 Amazon 如何围绕服务组织团队，构建可扩展系统的 CAP 定理，他们如何部署软件等等。 还包括了“ ACM 队列”文章中的许多新功能。* +![](img/7217d552460750f7e349311ee16c6eb1.png) -亚马逊从一个很小的在线书店发展成为地球上最大的商店之一。 他们做到了这一点，同时开创了对产品进行评分，评论和推荐的有趣新方法。 格雷格·林登（Greg Linden）在一系列博客文章中分享的是 Amazon 的出生困境 +我编写了一个东西。 称为 [Probot](https://probot.us/) 。 Probot 是一种快速简便的方法，可为您的会计和税务问题提供高质量的答案。 Probot 将找到一位真正的现场专家来回答您的问题并处理所有细节。 您可以通过 Facebook Messenger，Slack 或 Web 回答问题。 答案最低为 10 美元。 那就是球场。 -网站：http：//amazon.com +在这种新的机器人时代似乎很自然，不是吗？ 我还是这么想。 没有那么多（到目前为止），但是稍后会更多。 -## 信息来源 +我认为 Probot 足够有趣，因为它是一个程序员（我）如何利用当今的基础架构可以完成很多工作的一个很好的例子。 -* [早期亚马逊作家，格雷格·林登](http://glinden.blogspot.com/2006/05/early-amazon-end.html)* [Linux 如何为 Amazon 节省了数百万美元](http://news.com.com/2100-1001-275155.html)* [专访 Werner Vogels](http://www.se-radio.net/index.php?post_id=157593) -亚马逊的 CTO* 异步体系结构-Chris Loosley 的 Werner Vogels 演讲的精彩[摘要](http://www.webperformancematters.com/journal/2007/8/21/asynchronous-architectures-4.html)* [向亚马逊技术平台学习](http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388)-与 Werner Vogels 的对话* [Werner Vogels 的 Weblog](http://www.allthingsdistributed.com) -构建可扩展且强大的分布式系统 +实际上，所有这些新颖的云/无服务器/服务内容都可以正常工作。 我能够以相对可扩展，可用和负担得起的方式对跨越 Messenger，Slack 和 Web 的系统进行编程，同时只需最少的开发。 - ## 平台 +过去，担心 VPS 限制，开车前往 Colo 网站检查有问题的服务器，甚至担心容器/虚拟机集群自动扩展的日子已经一去不复返了。 至少对于许多用例而言。 - * 的 Linux* 甲骨文* C ++* 佩尔* 石匠* 爪哇* 博斯* Servlets +多年的编程经验和撰写此博客无法避免犯错误。 在此过程中，我犯了很多愚蠢的愚蠢错误，但我对最终的想法感到满意。 - ## 统计资料 +这是 Probot 的工作方式。... - * 超过 5500 万活跃客户帐户。* 全球超过 100 万活跃零售合作伙伴。* 访问 100-150 之间的服务以构建页面。 +## 平台 - ## 架构 +* 无服务器：AWS Lambda - * 我们对可伸缩性的真正含义是什么？ 如果我们在系统中增加资源时以与添加资源成比例的方式提高性能，则该服务被称为可伸缩的。 通常，提高性能意味着要服务更多的工作单元，但是也可以处理更大的工作单元，例如数据集增长时。 +* Web 主机：S3 上的静态站点，单页应用程序 - * 亚马逊所做的重大体系结构更改是从两层的整体架构转变为可服务于许多不同应用程序的完全分布式，去中心化的服务平台。* 作为一个与后端通信的应用程序启动。 用 C ++编写。* 它成长了。 多年来，亚马逊的扩展工作一直致力于使后端数据库进行扩展，以容纳更多物品，更多客户，更多订单并支持多个国际站点。 在 2001 年，很明显前端应用程序无法再扩展。 数据库被分成几个小部分，并围绕每个部分创建了一个服务接口，这是访问数据的唯一方法。* 数据库成为共享资源，这使得很难扩展整个业务。 前端和后端流程的发展受到限制，因为它们被许多不同的团队和流程共享。* 它们的体系结构是松散耦合的，并围绕服务构建。 面向服务的体系结构为他们提供了隔离，使他们可以快速，独立地构建许多软件组件。* 聚集了数百个服务和大量应用程序服务器，这些服务服务器汇总了来自服务的信息。 呈现 Amazon.com 网页的应用程序就是这样一种应用程序服务器。 服务 Web 服务接口的应用程序，客户服务应用程序和卖方接口也是如此。* 许多第三方技术很难扩展到亚马逊的规模。 特别是通讯基础设施技术。 它们会在一定规模下正常工作，然后失败。 因此，他们被迫建立自己的。* 不拘泥于一种特定的方法。 在某些地方，他们使用 jboss / java，但仅使用 servlet，而不使用 J2EE 堆栈的其余部分。* C ++用于处理请求。 Perl / Mason 用于构建内容。* 亚马逊不喜欢中间件，因为中间件往往是框架而不是工具。 如果您使用中间件软件包，则会锁定他们选择的软件模式。 您将只能使用他们的软件。 因此，如果您想使用其他软件包，则将无法使用。 你被困住了。 一个事件循环，用于消息传递，数据持久性， - AJAX 等。太复杂了。 如果中间件可以在较小的组件中使用，而更多的是作为工具而不是框架使用，那么他们会更感兴趣。* SOAP Web 堆栈似乎想再次解决所有相同的分布式系统问题。* 同时提供 SOAP 和 REST Web 服务。 30％使用 SOAP。 这些通常是 Java 和.NET 用户，并使用 WSDL 文件生成远程对象接口。 70％的人使用 REST。 这些往往是 PHP 或 PERL 用户。* 在 SOAP 或 REST 中，开发人员都可以获取到 Amazon 的对象接口。 开发人员只想完成工作。 他们不在乎导线上的内容。* 亚马逊希望围绕他们的服务建立一个开放的社区。 选择 Web 服务是因为它很简单。 但是帽子只在外围。 在内部，它是一种面向服务的体系结构。 您只能通过界面访问数据。 WSDL 中对此进行了描述，但是它们使用了自己的封装和传输机制。* 团队很小，并且围绕服务 - 进行组织-服务是在 Amazon 内部提供功能的独立单位。 这也是亚马逊在团队内部进行组织的方式。 - -如果您有一个新的业务构想或问题，您想组成一个团队来解决。 由于沟通困难，团队人数不得超过 8-10 人。 他们被称为两个披萨队。 您可以养活两个比萨饼的人数。 - -团队很小。 他们被授予权限并有权以他们认为合适的方式解决问题，即服务。 - -例如，他们创建了一个小组，以在书中查找文本唯一的短语。 该团队为此功能构建了一个单独的服务接口，他们有权执行所需的操作。 - -广泛的 A / B 测试用于集成新服务。 他们看到了影响并进行了广泛的测量。* 部署 - -他们创建用于管理依赖关系和进行部署的特殊基础结构。 - -目标是将所有合适的服务部署在一个盒子上。 所有应用程序代码，监视，许可等都应放在包装盒中。 - -每个人都有一个解决这些问题的本地系统。 - -部署过程的输出是虚拟机。 您可以使用 EC2 来运行它们。* 从客户后方进行工作以验证是否值得进行一项新服务 - -从客户后方进行工作。 专注于您想要为客户交付 - 的价值。 - -迫使开发人员专注于交付给客户的价值，而不是先构建技术然后再去思考如何使用它。 - -从新闻稿开始，介绍用户将看到的功能并向后工作以检查您是否正在构建有价值的东西。 - -最终以尽可能最小的设计完成。 如果您确实要构建大型分布式系统，那么简单是关键。* 状态管理是大规模系统 - 的核心问题-内部，它们可以提供无限的存储空间。 - -并不是所有的操作都是有状态的。 结帐步骤是有状态的。 - -最近点击的网页服务具有基于会话 ID 的建议。 - -无论如何，他们都会跟踪所有事情，因此保持状态无关紧要。 会话几乎不需要保留单独的状态。 服务将已经保留了信息，因此您只需要使用服务即可。* Eric Brewer 的 CAP 定理或系统的三个属性 - -系统的三个属性：一致性，可用性，对网络分区的容忍度。 - -对于任何共享数据系统，这三个属性中最多可以有两个。 - -可分区性：将节点分为几个小组，可以看到其他小组，但看不到所有人。 - -一致性：写入一个值，然后读取该值，您将获得相同的值。 在分区系统中，存在不正确的窗口。 - -可用性：可能并不总是能够写入或读取。 系统会说您不能写，因为它想保持系统的一致性。 - -要扩展，您必须进行分区，因此您只能为特定系统选择高一致性或高可用性。 您必须找到可用性和一致性的正确重叠。 - -根据服务需求选择特定的方法。 - -对于结帐流程，您始终希望兑现将商品添加到购物车的请求，因为它可以产生收益。 在这种情况下，您选择高可用性。 对客户隐藏错误，并在以后进行分类。 - -当客户提交订单时，您希望保持一致性，因为多项服务（信用卡处理，运输和处理，报告）正在同时访问数据。 +* 语言：Javascript /节点 - ## 得到教训 +* API：API 网关 - * 您必须改变思路，才能构建真正可扩展的系统。 以概率的方式处理混乱，事情会顺利进行。 在传统系统中，我们提供了一个完美的世界，在这个完美的世界上一切都没有失败，然后我们在这个完美的世界上构建了复杂的算法（协议技术）。 相反，将其视为理所当然的东西会失败，这是 - 现实，请接受它。 例如，使用快速重启和快速恢复方法进行更多操作。 随着数据和服务的良好传播，您可能会接近 100％。 创建自我修复，自我组织的熄灯操作。 +* DNS：Route53 - * 创建一个没有共享的基础架构。 基础架构可以成为开发和部署的共享资源，其缺点与逻辑层和数据层中的共享资源相同。 它可能导致锁定和阻塞以及死锁。 面向服务的体系结构允许创建并行且隔离的开发流程，以扩展功能开发以适应您的增长。 +* CDN：CloudFront - * 使用 API​​打开系统，您将在应用程序周围创建一个生态系统。 +* 用户登录名： [Cognito](https://github.com/aws/amazon-cognito-identity-js) - * 管理大型分布式系统的唯一方法是使事情尽可能简单。 通过确保设计中没有隐藏的需求和隐藏的依赖关系，使事情变得简单。 将技术减少到解决您所遇到的问题所需的最低限度。 这无助于公司创建人为的和不必要的复杂性层。 +* SSL 证书：让我们加密 - * 围绕服务进行组织可提供敏捷性。 您可以并行执行的操作是因为输出是服务。 这样可以加快上市时间。 创建一个基础结构，以允许快速构建服务。 +* 服务器：EC2，t2.small，Ubuntu - * 在实际实现之前，任何会引起炒作的问题都存在问题 +* 信息库：GitHub - * 在内部使用 SLA 来管理服务。 +* 源代码控制：Git - * 任何人都可以非常快速地将 Web 服务添加到其产品中。 只需将产品的一部分作为服务实施并开始使用即可。 +* 付款：贝宝 - * 出于性能，可靠性和成本控制的原因，构建自己的基础架构。 通过自己构建它，您不必说您倒闭，因为这是 X 公司的错。 您的软件可能不比其他软件更可靠，但是与第三者合作时，您可以更快地进行修复，调试和部署。 +* Slackbot： [Botkit](https://github.com/howdyai/botkit) - * 用度量和客观辩论将好与坏分开。 我去过前亚马逊的几场演讲，而这正是亚马逊给我的印象，与其他公司截然不同。 他们根深蒂固的道德操守是让真正的客户有选择的余地，看看哪个最有效，并根据这些测试做出决策。 +* 队列：SQS - [Avinash Kaushik](http://highscalability.com/blog-occam-s-razor-avinash-kaushik) 称这摆脱了 HiPPO（房间中收入最高的人）的影响。 这是通过 A / B 测试和 Web Analytics 等技术完成的。 如果您对应该如何编写代码有疑问，请让人们使用它，然后看看哪种选择可以为您提供所需的结果。 +* 备份：AWS Data Pipeline，每周将生产数据保存到 S3 - * 营造节俭文化。 例如，亚马逊使用书桌门。 +* 数据库：DynamoDB - * 知道你需要什么。 亚马逊在一个早期的推荐系统上经历了糟糕的经历，但并没有奏效：“这不是亚马逊所需要的。在亚马逊上进行书推荐需要使用稀疏数据，只需进行几次评级或购买即可。它必须要快。 该系统需要扩展到大量的客户和庞大的目录，还需要增强发现能力，使目录中深处的书籍无法被读者自己找到。” +* 节点进程管理器： [PM2](http://pm2.keymetrics.io/) - * 人们感兴趣的旁人项目通常是您获得最大价值和创新的项目。 永远不要低估您最感兴趣的地方徘徊的力量。 +* SSL 终止：Nginx - * 让每个人都参与制作狗粮。 在圣诞节高峰期间，请进仓库并整理书籍。 那是团队合作。 +* Web 框架：jQuery，Bootstrap - * 创建一个登台站点，在发布到野外之前，您可以在其中进行全面的测试。 +* 开发平台：MacBook Air - * 一个健壮的，集群的，复制的，分布式文件系统非常适合 Web 服务器使用的只读数据。 +* 本地测试 Web 服务器： [http 服务器](https://www.npmjs.com/package/http-server) - * 如果更新不起作用，有一种方法可以回滚。 如有必要，编写工具。 +* 测试隧道： [Ngrok](https://ngrok.com/) - * 切换到基于深度服务的体系结构（http://webservices.sys-con.com/read/262024.htm）。 +* SQS 轮询： [平方英尺消费者](https://www.npmjs.com/package/sqs-consumer) - * 在面试中寻找三件事：热情，创造力，能力。 对 Amazon.com 成功的最大预测是热情。 +* 日志记录：CloudWatch - * 雇用鲍勃。 知道他们的东西，拥有令人难以置信的调试技能和系统知识的人，最重要的是，他们拥有一头石头就能解决仅凭跳进就可以想象到的最严重的高压问题。* 创新只能来自底层。 那些最接近问题的人最有可能解决问题。 任何依赖创新的组织都必须拥抱混乱。 忠诚和服从不是您的工具。 +## 起源故事 - * 创意必须无处不在。 +我的妻子 [琳达·科尔曼](http://www.possibility.com/Lgc/AcctRes.html) 是一名注册代理，这意味着她是一位了不起的税务会计师，并且在会计专家中都很有经验。 她有一个网站 [BizTaxTalk](http://biztaxtalk.com/) ，在这里她为人们的税收问题提供了很好的答案：免费。 她有很多问题。 有真正问题的人需要帮助，很难找到可以回答这类问题的人。 - * 每个人都必须能够进行实验，学习和迭代。 职位，服从和传统不应该拥有任何权力。 为了使创新蓬勃发展，必须衡量。 +您可能会想像它变得势不可挡。 她最终不得不放弃 BizTaxTalk，因为它占用了她太多的时间。 - * 拥抱创新。 在整个公司的面前，杰夫·贝佐斯（Jeff Bezos）会将一双耐克旧鞋授予“勇于创新”的人，以表彰他们的创新精神。 +我想为什么不通过它获利？ 琳达可以回答人们的问题并获得报酬。 双赢。 我知道这种类型的质量检查网站不是新手，但机器人程序是解决该问题的新方式，应该是处理此类信息交换的一种很好的方式。 使用文本可以非常方便地异步处理问答流程。 - * 不要为性能付出代价。 给予良好的待遇和高薪，但保持平稳。 以其他方式认可出色的工作。 绩效工资听起来不错，但是在大型组织中几乎不可能做到。 使用非金钱奖励，例如旧鞋子。 这是说谢谢的方式，有人在乎。 +因此，Probot 建立了一个双面市场。 有问题的用户（例如约会服务）与能够回答其问题的主题专家（称为 Pro）相匹配。 Probot 处理消息的匹配，计费和协调。 - * 快速变大。 像巴恩斯（Barnes）和诺贝尔（Nobel）这样的大人物在你的尾巴上。 亚马逊甚至不是网络上的第一，第二，甚至第三本书店，但最终他们的愿景和驱动力胜出了。 +尽管我显然会从税务和会计问题入手，但最终可以吸引更多的主题专家，并且话题数量也有所增加。 这就是我编写代码的方式。 它可以轻松扩展以处理新主题和问题树。 - * 在数据中心，只有 30％的员工时间花费在与价值创造相关的基础架构问题上，其余 70％专门用于应对硬件采购，软件管理，负载平衡，维护，可扩展性挑战以及 以此类推。 +这就是我要建立的。 - * 禁止客户端直接访问数据库。 这意味着您可以在不涉及客户的情况下扩大服务范围并提高可靠性。 这很像 Google 能够独立地在其堆栈中分发改进以使所有应用程序受益的能力。 +## 架构 - * 创建一个统一的服务访问机制。 这使得服务易于聚合，分散请求路由，分布式请求跟踪以及其他高级基础结构技术。 +*继续阅读* 。 这是一遍又一遍的 HS 建议。 那就是我所做的。 我有在 Node 上使用最出色的 [Botkit](https://github.com/howdyai/botkit) 制作 Slackbots 的经验，因此我就从这里开始。 - * 通过 Web 服务接口向世界上任何开发人员免费提供 Amazon.com 也是一项重大成功，因为它推动了许多创新，他们无法想到或自己建立。 +我也有使用 AWS Lambda 来开发 Alexa 技能的经验，并且不想管理任何东西-玩系统管理员多年就足够了-所以我选择了 AWS。 如果 Google Cloud Functions 是 GA，那么我可能会选择使用 Google Cloud。 - * 开发人员自己最清楚哪些工具使它们最高效，哪些工具最适合工作。 +以下是我们将介绍的所有主题： - * 不要对工程师施加太多限制。 为某些事情提供激励，例如与监视系统和其他基础结构工具集成。 但对于其余部分，允许团队尽可能独立地运作。 +* ProbotService Lambda 函数 - * 开发人员就像艺术家。 只要有自由，他们就可以发挥出自己最好的作品，但是他们需要好的工具。 有许多具有自助性质的支持工具。 为服务开发周围的环境提供支持，而该环境永远不会妨碍开发本身。 +* Slackbot - * 您构建它，然后运行它。 这使开发人员可以接触到他们软件的日常操作。 它还使他们与客户进行日常联系。 客户反馈回路对于提高服务质量至关重要。 +* Messengerbot - * 开发人员应每两年花一些时间在客户服务上。 他们实际上将收听客户服务电话，接听客户服务电子邮件，并真正了解他们作为技术人员所做的各种事情的影响。 +* 网站 - * 使用“客户的声音”，这是客户关于您网站体验的某些特定部分的真实故事。 这可以帮助经理和工程师了解我们为实际人员构建这些技术的事实。 如果您做错了什么或对客户而言真正的痛点是什么，则客户服务统计数据可以作为早期指示。 +* PayPal 集成 - * 像 Google 一样，Amazon 的基础设施具有巨大的竞争优势。 他们可以利用相对简单的原始服务来构建非常复杂的应用程序。 他们可以独立扩展业务规模，保持无与伦比的系统可用性，并快速引入新服务，而无需进行大量重新配置。 +* 测试 -亚马逊的首席技术官沃纳·沃格斯（Werner Vogels）谈到了 SE-Radio 的技术细节。 您可以在[下找到播客，网址为 http://www.se-radio.net/index.php?post_id=157593](http://www.se-radio.net/index.php?post_id=157593) -有趣的一集。 +* 采纳 -那是一次很好的采访。 谢谢。 我将尽快添加新信息。 +* 获得的经验教训 -亚马逊使用 Perl 和 Mason。 -请参阅： [http://www.masonhq.com/?MasonPoweredSites](http://www.masonhq.com/?MasonPoweredSites) +## ProbotService Lambda 函数 -如我所见，他们减少了 c ++部分并转移到 j2ee？ +这是实现 Probot Service 后端的 AWS Lambda 函数。 大多。 这也是我许多愚蠢错误的根源。 让我解释。 -除非您是经理，否则我不确定您怎么能弄错那个错误，但是即使那样，某些工程师还是会在星期日之前教您。 +我为 Slack 编写的第一个 Probot 机器人用于 Slack，并且取得了一些进步，但是 Slackbot 在 EC2 实例上的 Ubuntu 进程中运行。 -感谢您抓住这一点。 我听了几次，有时我只是写我听到的内容，而不是我的意思。 +我犯的一个大错误是不首先使用 API​​。 我的大部分职业都是建立另一种消息协议。 是我做的吗？ 当然不是。 -我实际上在以下位置给出了可扩展性的详细定义： [http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html“](有关可扩展性的信息 +我对所有机器人逻辑进行了编程，因此可以直接在 Slackbot 流程中执行。 这是可能的，因为 AWS 具有用于访问 DynamoDB，SQS，Lambda 和其他 AWS 服务的漂亮 Node API。 因此，所有 AWS 访问都直接用 javascript 编码。 效果很好。 没问题 -我个人喜欢 [http://www.acmqueue.com/modules.php?name=内容& pa =显示页& pid = 388“]( ACM Queue 中的采访最适合 高层视野 +当我需要制作 Web 客户端时出现了问题。 嗯，在相同的代码也几乎可以在 Web 客户端中正常工作的意义上，这并不是问题。 真酷。 因此，我浪费了很多时间来建立 Slack 和 Web 客户端可以共享的通用库。 但是我对我的数据库访问代码可以在 Web 上看到的想法感到非常不舒服。 对于 Intranet 服务，我不会担心，但按我的喜好显示数据结构的攻击面太大了。 --维尔纳 +我犯的另一个大错误，也与不首先创建 API 有关，是因为对 DynamoDB 在数据库更改时将新值和旧值传递给 Lambda 函数的能力深感兴趣。 我所做的是像状态机一样触发逻辑。 例如，如果旧记录说状态为 PENDING，而新状态为 ASSIGNED，则触发 PENDING 到 ASSIGNED 的转换。 它有效，我认为它真的很聪明。 问题在于面对许多无法移动状态但仍触发 Lambda 函数的操作，它过于脆弱。 -似乎他们使用 Java 来完成通常用 Perl 完成的工作。 +解决这两个问题的方法是构建一个 API，我使用 Lambda 做到了。 我选择不使用 API​​ Gateway，因为直接从 Node 调用 Lambda 函数非常容易。 API 网关增加了延迟，复杂性和成本。 也很难使用。 从 HTTP 请求转换参数并将其映射到 Lambda 调用对于任何复杂的事情来说都是非常接近魔术的过程。 回复相同（反方向）。 如果将来需要使用公共 API，则可以重新考虑此决定，但是直接使用 Lambda 是非常简单的方法。 必须更改所有 Slack 和 Web 代码才能使用新的 API。 真痛苦 ->使用非货币奖励，例如旧鞋。 这是 ->说谢谢的一种方式，有人在乎。 +### 如何构建无服务器 API？ -有一次我愚蠢到参加亚马逊全公司会议，而不是将其视为免费的入睡日，我看到贝索斯给了一个男人一双鞋子。 +下一个决定是如何构建 API？ 每个 API 调用都映射到一个单独的函数吗？ 还是将功能归为一个入口？ 还是可能有多个入口点？ -我当时想：“这个家伙造了宇宙飞船，他把臭旧的网球鞋给高成就者？他们不喜欢打他吗？自尊心在哪里？” +我选择了一个入口点。 之所以采用这种方法，是因为我不想使用框架来管理 Lambda。 我想知道所有东西如何连接在一起，框架包含很多魔术。 因此，我创建了一个 zip 文件，并使用 AWS 控制台将其上传到 Production 或 Test。 将来，我将使其自动化，但现在可以正常使用。 -但是我想这就是为什么我是前亚马逊人的原因。 当我放弃他们时，薪水提高了 20％，而且没有传呼机职责。 见，杰夫。 +使用单个入口点时的一个问题是如何复用函数调用？ 我选择模仿 [JSON-RPC](http://www.jsonrpc.org/specification) ，这些在过去我已成功用于服务器应用程序。 -这是我一段时间以来最愚蠢的读物之一。 一家聪明的公司为什么会花钱在员工的“奖励”上，这对除了您从中获得奖励的人以外的任何人都没有帮助？ 当亚马逊表现出色时，他们就会获得真正的高成就，而且股价在 90 美元左右，我知道他们的感觉还不错。 我的猜测是他们想拥抱杰夫。 +请求包装在 JSON-RPC 负载中。 使用“ method”属性指定要调用的方法，并使用“ params”属性传递任何参数。 ProbotService index.js 文件解压缩 JSON-RPC 请求并调用正确的方法。 看起来像： -成就不佳的人很可能会对此表示不满，然后去其他地方，他们在亚马逊工作的事实很可能有助于这项工作，就像我确定的那样。 而且，看来您离开并没有对亚马逊造成太大的伤害:) +> 如果（request.method ===“ giveAnswerToUser”）{ +> +> var op = new QuestionImpl（appcfg）; +> +> op.giveAnswerToUser（request.params，function（error，data）{ +> +> 返回 sendResponse（错误，数据，请求，回调）； +> +> }） +> +> } -以前的 Nikies 面向成就卓越的人的事情听起来像是给 IBM 员工的（愚蠢的）文凭。如果您真的想感谢一个成就卓越的人，请给他们加薪或奖金，或者..不愿意参加巡航。 便秘的旧鞋子..多么可爱:)） +我以标准的 RPC 方式创建了一个名为 ProbotService 的存根对象，该对象使从客户端代码调用 Lambda 函数变得更加容易。 例如： *service.getQuestion（id，callback）*格式化正确的 JSON-RPC 结构，调用正确的 Lambda 函数，并在返回回复时调用回调。 ->而且，看来您离开并未对亚马逊造成太大的伤害:) +### 共享代码 -哦，我敢肯定，没有我，amzn 很好。 但是亚马逊员工的半衰期约为 18 个月，所以认为在那工作很糟糕的不只是我。 想一想，如果不必每 18 个月更换一半的员工，amzn 的运营效率就会提高多少。 我确信这将对其股价产生影响。 :) +我选择不在 Facebook Messenger 机器人代码中调用 ProbotService Lambda。 而是，服务库代码与 Messenger 代码打包在一起并直接调用。 这是一种代码共享方法。 在 ProbotService 和 Facebook Messenger 之间共享相同的基础代码。 ->如果公司 ->表现不错，并且股票价格在 90 美元左右，亚马逊的真正成就就会得到回报，我知道他们对 ->感觉很好。 我的猜测是他们想拥抱杰夫。 +原因是 Facebook Messenger Webhook 调用通过 API 网关调用，该 API 网关调用 Lambda 函数。 使用 ProbotService 还会调用 Lambda 函数。 因此，将在另一个 Lambda 函数中调用 Lambda 函数。 这可以正常工作，但是最坏的情况下的延迟比我希望用户体验到的要高，因此我选择通过共享代码来删除跃点。 我仍然不确定这是否是最好的决定，但是它确实有效，并且 Messenger 机器人的响应时间让人感觉很快。 -当然，现在股价飞涨，我为那里的人感到高兴，他们为此赚了很多钱。 但是 amzn 按照市场标准支付工资，并依靠股票来提高工资。 我对你的薪水赌博并不酷。 +由于 Slackbot 在自己的进程中运行，因此没有多余的跃点，因此使用 ProbotService 是正确的选择。 Web 客户端代码中也使用了 ProbotService，因此不会泄漏任何内部详细信息。 -算上我过去几年的全部收入...如果我的所有 amzn 赠款都以每笔$ 90 支付，如果我呆在那里，我可能会多赚$ 15-25K。 但是，2.5 万美元的保费（或每年 625 万美元，因为需要花费 4 年的归属时间）并不足以让我进入亚马逊，考虑到要换取这笔保费，我需要工作 10- 每周多 30 小时。 我认为基于权益的补偿是针对傻瓜的。 用权益补偿来换取巨大的每周工作量需求是……更大的吸盘。 +### ProbotService API -我目前的公司为我提供了真正的现金红利和额外的带薪休假，以使他们表现良好。 我要把它接在笨拙的旧鞋子上！ 钱用来说话； 像 bulsh * t 这样的鞋子，是用来走路的。 +以下是 Probot API 中的一些功能。 我不会使用 Swagger 之类的文档。 -作为对您的文章的深入研究的副作用，我将其翻译为德语： [http://habacht.blogspot.com/2007/10/amazon-architecture.html](http://habacht.blogspot.com/2007/10/amazon-architecture.html) +* updateFromPaypalWebhook -为什么？ perl 是用于文本处理的常用工具：） java 不仅限于 perl +* getQuestion -由于谦虚，我倾向于说 Java 并不适合所有传统的业务术语。 效率，投资回报。 我今天经营一家公司，并且相信我，从长远来看，Java 并不是设计大型&关键应用程序的最终选择。 只有伪专家和伪 IT 经理才将 Java 视为明天编程问题的第一个答案。 我建议您检查 J2EE 后面的语言/框架环境。 以 Perl 6 为例。 我在开玩笑 ？ 并不是的。 我们的最后一个 Web 服务完全使用 Perl 和 Ruby 中的接口进行了完全设计。 开明的用户想知道它是否是 struts + hibernate + weblogic + oracle（可能带有 SAP R / 3 连接器）。 现在的现实已经大不相同：我们必须考虑纯粹的业务。 Java 的？ 好的，我今天将检查 Sun 的博客。 我也爱 Java。 +* GiveAnswerToUser -真的很有趣，喜欢阅读。 但是，我觉得如果您真的想感谢一个成就卓越的人，请给他们加薪或奖金！ 那就是我最欣赏的，毕竟我们是为了钱而工作。 +* GiveAnswerToPro -大部分内容非常有用（特别是我同意的部分；） +* askQuestionOfUser -梅森对我来说是新的！ 非常好的帖子。 [http://evandro.net/“]( Evandro [http://www.poker73.com/”](坐下&转到 +* cancelQuestion -Very informative for the most part (specially the parts I agree with ;) +* acceptProAnswer -您能否解释一下“ DOM”的含义 +## Slackbot -那是一篇关于亚马逊建筑大师的好书。 在下周对亚马逊的采访中肯定会有所帮助。 +![](img/40070da02aed39af548489071241ab44.png) -亚马逊是一家伟大的公司。 真的启发了我。 [http://www.csscatwalk.com“]( CSS 画廊 +### 机器人样式 -谢谢！ +对机器人进行编程时，您必须做出的决定之一是：您要使用对话式 AI 风格机器人还是结构化命令驱动风格机器人。 -非常感谢您提供如此详细的信息。 它无疑帮助我了解了有关构建可扩展网站的更多事实。 +我采用了结构化的命令驱动方法。 用户选择一个问题主题，然后漫游器会引导他们通过问题树收集 Pro 回答此类问题所需的数据。 例如，对于纳税申报表，您需要知道它是哪一年，是个人还是公司，是否是公司的实体类型（合伙企业，C-Corp 等），等等。 -That was a nice read about amazon architecutre. Would definitely help during the interview with amazon next week. +AI 风格很性感，但如果那不是您的事，那么做起来真的很难。 因此，我想出了一种与用户进行对话的方式，可以针对每个问题进行自定义。 实际上，我提出了几种不同的对话描述符解决方案，但我对其中任何一个都不满意。 这是 Slack 的样子： -大多数情况下非常有用 \ No newline at end of file +> probot.machine.add（“ ask-return-type”，{ +> +> 操作：probot.machine.askFromOptions， +> +> 选项：[“个人”，“业务”]， +> +> 显示：[“个人”，“业务”]， +> +> 问题：“在回答税收问题时，帮助您的专家了解报税种类会很有帮助。”， +> +> sayOnAccept：“知道了。您选择了 _ {response} _ 选项。”， +> +> 答案：功能（机器，cmd，答案，下一个）{ +> +> console.log（“ ask-return-type：answer：” + answer）; +> +> probot.dto.setReturnType（answer）; +> +> if（answer ===“ individual”） +> +> 的 cmd.next =“询问税年”； +> +> 其他 +> +> cmd.next =“询问实体类型”; +> +> next（null）; +> +> }， +> +>    }) + +我对 Messenger 采取了完全不同的方向。 我也很讨厌这种方式。 + +### 松弛主机 + +使用 Slack 时，webhooks 可用于实现 Slack 命令，但是对话风格要求代码在流程上下文中运行。 因此，我建立了一个没有任何冗余的小型 EC2 实例。 由于我不希望用户在 Slack 上不断与 Probot 互动，因此我认为停工时间不会造成任何伤害。 所有状态都将在 DynamoDB 中，因此不会丢失任何内容。 弹性 IP 用于访问主机。 + +*保持简单，不要使事情复杂化* 。 关于 HS 的另一个很长的课程。 如果有人最终使用您的系统，则可以稍后再做所有花哨的工作。 + +[PM2](http://pm2.keymetrics.io/) 是出色的 Node 进程管理器，用于在 Slack 进程死后重新启动它。 PM2 还管理日志并执行其他一些精美的操作。 Route53 会 ping 通该过程，并在出现任何问题时向我发送电子邮件。 够好了。 + +Botkit 完成了许多繁重的工作。 它处理程序与 Slack 之间的所有协议工作，同时为身份验证，进行对话之类的事情提供了许多方便的抽象方法。 + +### 互动消息 + +在我完全完成 Slackbot 实现之后，Slack 引入了用户使用按钮而不是输入文本来进行选择的功能。 由于我还没有发布任何东西，所以是时候进行更改了。 这些按钮确实使用户更容易。 问题是按钮需要您的进程实现 HTTPS Webhook，以便 Slack 可以通过按下哪个按钮的信息回调到您的进程中。 这是开发流程的重大变化。 松弛的开发是很好的，以前也包含在内。 现在，您的机器人程序必须可以通过 URL 从外部进行访问。 + +在 EC2 中的生产机器上还不错。 我使用 Nginx 终止 SSL，并将请求传递给 Slackbot 进程。 这需要使用我使用“加密”的 SSL 证书。 由于必须定期更新，这是维护上的麻烦，但它们是免费的，因此请选择毒药。 + +让 Slack 通过 Comcast 路由器访问在笔记本电脑上运行的进程并不容易。 我在各种解决方案上浪费了很多时间。 很多时间。 我最终屈服了，并向 Ngrok 支付了他们的隧道服务。 像魅力一样工作。 花钱。 Slack 应该考虑能够完全在无服务器上工作。 那将是一个更清洁的解决方案。 + +### 身份和验证 + +在 Probot 中，没有尝试创建 Slack，Messenger 和网络上常见的用户。 每个都使用其环境固有的身份机制。 对于 Slack，这意味着使用 Slack 分配的团队 ID 和用户 ID。 Probot 询问用户的姓名和电子邮件地址，但不打扰身份和身份验证。 Slack 处理所有这些。 + +### 数据库 + +Slack 提供了自己的数据库抽象，用于存储团队，用户和渠道。 当 Probot 使用 DynamoDB 时，我创建了一个简单的 [适配器](https://github.com/ToddHoff/botkit-storage-dynamodb) ，该适配器允许 Slack 将其数据存储在 DynamoDB 中。 + +通常的做法是在 Slack 的数据结构中插入自己的属性。 因此，用户数据存储在 Slack 的用户对象中。 + +### 从 Pro 向用户发送消息 + +与用户对话时，使用 Botkit 发送消息就像 *bot.say（“某些字符串”）* 一样容易。 在以后的某个时间以异步方式向用户发送消息并非易事。 例如，当专业人士为用户提供答案或想要提出问题时，必须向用户提供消息。 + +我可以弄清楚如何使异步消息传递起作用的唯一方法： + +* 当团队连接到 Probot 时，将 Botkit 机器人 对象存储在内存中。 需要机器人对象才能向用户发送消息。 + +* 每个用户都与一个团队相关联，因此当出现消息时，可以找到适当的机器人对象。 + +* 来自 Pro 的所有消息都排队到 AWS SQS。 + +* Slackbot 进程使用一个名为 sqs-consumer 的漂亮软件包来轮询 SQS 以获取消息。 + +* 使用 bot 对象将消息发送给用户。 + +* 用户调用@probot 进行对话以处理消息。 该消息可能是答案，问题或状态更新。 用户可以对答案进行评分并发表评论。 他们还可以拒绝答案，这意味着用户无需付费。 我不希望别人觉得自己被人扯了。 这是 Pro 承担的风险。 尽管我不这样做，但匹配算法可以在进行匹配时利用评分数据。 + +Sqs 消费者是为什么 Node 对开发人员如此高效的一个示例。 是的，javascript 很烂。 是的，回调编程有点糟。 但是从字面上来看，我需要花五分钟的时间思考*，我需要轮询 SQS* 来找到一个好的 npm 可安装软件包并拥有有效的代码。 Node 一直在发生这种情况。 + +## Messengerbot + +![](img/96ab0db0dea30355d9828a21db9dff88.png) + +Messenger 是与 Slack 完全不同的野兽。 尽管 Botkit 支持 Messenger，但我还是决定直接将代码编码到 [Messenger API](https://developers.facebook.com/docs/messenger-platform/) ，因为它比 Slack 简单得多。 那是因为作为团队协作工具，Slack 具有很多功能。 Slack 具有用于与团队，渠道，用户，组，权限，功能等配合使用的各种 API。 + +使用 Facebook Messenger 时，将通过 Webhook 接收消息，并使用 HTTP 调用发送格式化的消息。 那几乎就是您所能做的。 因此，Messenger 机器人可以完全在 Lambda 函数上运行。 如果您不关心团队的所有方面，那么 Messenger 可能是一个更好的起点。 + +回想一下，这是 和您所知道的 咬住我的地方。 Probot 不是团队工具。 它与用户进行一对一的交互，因此所有开销都没有任何好处，并且需要很长时间才能解决。 另一方面，Slack 的员工非常乐于与他们合作。 如果您有问题，那么有技术印章的真实人将为您提供一个很好的答案。 你可以想象？ + +实际上，我一直在考虑取消对 Slack 的支持，因为没有人在使用它，而且 EC2 实例每月都要花我很多钱。 无服务器可为此类工作量赢得大量时间。 使用 Lambda，我只在人们实际使用 Probot 时付款。 + +### 简化 Messenger + +一件事立即变得很清楚，那就是必须简化 Probot 才能在 Messenger 上正常工作。 使用 Slack 时，复杂的用户交互变得自然。 在 Messenger 上，复杂的问题树根本不起作用。 + +我所做的一个简化是减少用户可以从 Pro 请求的答案类型。 在 Slack 上，用户可以要求以不同的价格快速，完整或深入地回答问题。 添加这一额外的交互层会使整个过程陷入困境，因此，使用 Messenger 时，Pro 可以提供的唯一可能的答案类型是 Quick 类型。 + +无法将简短的文本字符串发送到 Messenger 进一步增强了对简短和简单的需求。 松弛搭配文字很棒。 您可以吐出文本页面没问题。 有了 Messenger，您可以发送的最大尺寸。 长字符串必须分成大块，而不是美观。 + +另一个简化是 Messenger 上，用户一次只能回答一个未解决的问题。 在网络和 Slack 上，用户可以一次打开多个问题。 回想起来，这可能也是我应该构建 Slack 的方式。 通过聊天界面管理多个悬而未决的问题很复杂。 + +这是关于 HS 的又一个很长的课程： 保持简单愚蠢 。 说起来容易做起来难。 + +### Facebook Messenger Webhook + +在 Messenger 机器人配置中，指定了一个 Webhook，Facebook 会使用用户相关事件进行调用。 Webhook 使用绑定到 Lambda 函数的 API 网关实现。 Lambda 函数是使用共享代码方法实现的。 它包含了所需的所有源代码，而不是调用其他服务。 + +Lambda index.js 文件中的启动代码负责解析来自 Facebook 的消息并正确分发。 在处理每个消息之前， startSession 与发送者 ID 一起调用，该 ID 被用作用户 ID。 startSession 获取用户记录（如果存在），如果不存在，则请求该用户的配置文件并创建用户记录。 如果用户记录中已有问题 ID，则会从数据库中检索该问题，并创建该问题的状态机对象。 传入消息是状态机上的一个事件，它驱动消息的处理方式。 + +使用 startSession 来处理用户消息所需的所有数据均已就绪，因此任何较低级别的代码都不必担心。 同样，在处理完一条消息后，将检查脏标志，如果对象已更改，则会在数据库中自动对其进行更新。 我发现这种风格使使用 Lambda 函数更加简洁。 较低级别的代码永远不必担心状态管理。 + +这是 Slack 比 Facebook 更具优势的领域。 Lambda 函数无法存储状态，因此必须激活每个状态并随每个请求将其钝化。 使用 Slack，状态可以存储在 Slackbot 进程中，尽管如果我要再做一次，则可能不会将状态保持在 Slack 中。 转到数据库并编辑记录并在下次请求时提取更改非常方便。 为了使这些更改在 Slackbot 中可见，必须重新启动该过程。 + +Messenger 具有许多不同类型的消息：消息，回发，身份验证，传递确认，消息读取，帐户链接等。 消息类型有几种子类型：快速答复，文本，回声，回执，已读回执，键入，键入，等等。 + +通常，我唯一要注意的消息是与用户的交互。 所有命令源均映射为通用请求格式，并馈入 Question 状态机。 例如，当用户点击“回发”按钮，“开始”按钮，“持久”菜单或“结构化消息”时，发生回发事件。 我认为来自用户的任何纯文本输入都是为了响应我之前提出的问题。 快速回复 只是用户可点击按钮的另一种类型。 + +### Facebook 问题状态机 + +所有问题都存储在 DynamoDB 中。 每个问题都有一个属性，用于指定问题所在的当前状态。将消息标准化为通用请求格式后，将其应用于“问题”状态机，该状态机看起来像： + +> var QuestionDto = require("./QuestionDto");function FacebookQuestionSm(appcfg, startState) {  console.log("FacebookQuestionSm:startState:" + startState);  this.startState = startState;  var self = this;  this.any = {    help: {      action: FacebookQuestionSm.sendHelp,    },    getstarted: {      action: FacebookQuestionSm.sendGetStarted,    },    settings: {      action: FacebookQuestionSm.sendSettings,    },    status: {      action: FacebookQuestionSm.sendStatus,    },  ...  this.states = {    start : {      on : {        accounting: {          forward: "ask_accounting_question"        },        ask_accounting_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_question",          data: { type: "accounting", msg: "Great choice, I see you want to ask an accounting question." }        },        ask_individual_tax_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_tax_year",          data: { type: "tax", returnType: "individual",                   msg: "Great choice, I see you want to ask a tax question for an individual."           }        },        ask_business_tax_question: {          action: FacebookQuestionSm.createQuestion,          next: "ask_entity_type",          data: { type: "tax", returnType: "business",             msg: "Great choice, I see you want to ask a business related tax question."           }        }      }    },    ask_tax_year : {      action: FacebookQuestionSm.sendTaxYearQuestion,      on : {        text: {          verify: FacebookQuestionSm.verifyTaxYear,          action: FacebookQuestionSm.saveTaxYear,          next: "ask_question"        }      }    }, +> +>     ... +> +> } +> +> this.on = function（appcfg，userid，request，next）{ +> +> console.log（“ on：userid：” + userid +``request：“ + JSON.stringify（request））; +> +> } + +上的 *方法接受请求并将其应用于状态定义。 这可以正常工作，但是处理用户可以与机器人进行交互的所有方式都会使代码看起来有些骇人。* + +### Identity and Authentication + +与 Slack 一样，Facebook 提供了专门用于 Messenger 的用户 ID，而我只是使用该 ID。 它不是真实的 Facebook 用户 ID，因此您不能使用 graph API 来获取大量用户信息。 该 ID 与问题一起存储，因此可以将答复直接发送给用户。 + +### Database + +Slack 的 Facebook 数据库 API 等效，因此用户数据存储在 DynamoDB 中 Facebook 特定的用户表中。 + +## 网站 + +![](img/f2c70cd017c86d78ddbcadea563ee25a.png) + +[Probot.us](https://probot.us/) 是 S3 上托管的单页应用程序。 作为单页应用程序，所有操作均使用 Slack 使用的相同 ProbotService API 完成。 使用 S3 的优点是我无需管理任何事情。 它是一个与其他网站非常相似的网站，因此我不会在此进行过多介绍，但有一些主题值得注意。 + +### 电子邮件崩溃 + +您是否曾经做过一些您最终不会做的事情，但还是成功了？ 这是另一个浪费时间的大错误。 毫无疑问，我不太擅长制作网站。 我希望这可以解释为什么我真正尝试完全避免制造一个。 + +我所做的是通过电子邮件使所有 Pro 交互工作。 问题将通过电子邮件发送给专业人士。 专业人士会通过电子邮件答复并回答问题。 电子邮件中的关键字使它可以解析和提取数据。 用户没有注意到差异，因为他们仍然会使用 Slack 或 Messenger。 + +这是流程：Probot 向 Pro 发送了电子邮件。 例如，将问题分配给专业人士时，他们将收到一封包含该问题，有关用户的信息以及一些簿记属性的电子邮件，以将电子邮件映射回该问题。 专业人士会回覆他们的回应，并确保将文字插入正确的位置，以便可以正确解析。 AWS 收到了 Pro 的回复并将其保存到 S3 中。 这导致了 Lambda 函数被调用。 该功能将解析电子邮件，提取所有数据，并相应地更新用户。 + +尽管配置很麻烦，但实际上确实有效，并且编写代码很有趣。 只有我的测试专家讨厌它。 只是讨厌它。 当然，他们做到了，这对他们来说很糟糕。 因此，我最终制作了 Pro 仪表板，以管理我一直知道自己必须解决的所有 Pro 问题。 我还添加了一个收件箱，以便用户可以在网络上提问和管理问题。 同一网站还为 Slack 用户充当着陆页，以便他们可以将 bot 安装到他们的团队中。 + +### [HTG0 BC] + +尽管我已经在 Golang 中使用了完整的用户注册系统，但我希望将所有内容保留在 Node 中。 我决定重试一下，而不是重新发明轮子。 我不想对用户密码的安全性负责，Cognito 可以处理所有这些。 使用起来很棘手，这里的有一些奇怪的问题要弄清楚。 示例代码和文档可能会更好。 但是我最终得到了所有典型的流程-注册，忘记密码，更改密码，重新发送验证码，输入验证码等-都可以正常工作。 这并不容易，但是似乎可以可靠地工作。 + +### 节点和浏览器之间共享代码 + +这是我犯的另一个错误：我不打算在 Node 和浏览器之间共享代码。 到我意识到可以共享很多代码的时候，采用另一种模块哲学已经太费力了。 我确实共享代码，但是在包含导致在两种情况下都不起作用的依赖项的代码时，我必须非常小心。 + +## PayPal 集成 + +我选择 PayPal 是因为我发现它们的 API 是可以理解的，其仪表板也可以使用，并且其文档可以使用。 支持速度很慢，但通常会有所帮助。 + +当用户接受专业人士对其问题的回答时，付款状态机将启动。在 ProbotService 中，PayPal API 用于创建发票，该发票由 PayPal 发送到用户的电子邮件地址。 通过 PayPal，您可以配置一个 Webhook 来使用发票相关事件。 Webhook 使用绑定到 Lambda 函数的 API 网关。 + +当 Lambda 函数接收发票事件时，它将在事情发生时通知用户和 Pro。 + +* 松弛：通过前面描述的 SQS 机制通知用户。 会向 Pro 发送电子邮件，告知他们应该访问仪表板以获取详细信息。 绝不会通过电子邮件发送任何敏感信息。 + +* Messenger：发短信给用户。 请注意，要在上次联系后 24 小时向用户发送消息，您必须对机器人具有特殊权限。 这并不总是容易获得的。 因此，如果您的机器人需要提前进行此类功能计划。 + +* Web：向用户发送电子邮件，并要求用户登录 Probot 以获得其仪表板上的更多信息。 + +这花了一些时间才能开始工作。 如果未调用与 Webhook 关联的 Lambda 函数，则很难理解问题所在。 绝对打开 A​​PI 网关日志记录。 您将需要它。 + +PayPal Lambda 函数使用与前面所述相同的代码共享方法。 无需进行远程 ProbotService 调用，而是直接调用代码。 + +## 测试 + +这里没什么好想的。 + +对于 API 网关，Lambda 和 DynamoDB，有所有版本的测试和生产版本。 根据配置在运行时选择使用哪个。 + +该网站有测试和生产版本。 为了测试它们，我只使用所有功能。 使用 *aws s3* 命令行将文件从开发环境复制到 S3。 对于本地开发，将 http-server 用作 Web 服务器，并且可以通过 localhost 测试所有功能。 + +PayPal 具有测试和生产配置选项。 每个都分别指向测试和生产网络挂钩。 PayPal 具有在调用 Webhooks 时记录的日志，这在调试时很有用。 不幸的是，事件不是实时发送的，因此您必须等待事件被发送并显示日志。 + +对于 Slack，有一个单独的机器人，用于测试和生产。 每个都分别指向测试和生产网络挂钩。 Messenger 也是一样。 除了将测试版本和生产版本视为完全不同的漫游器之外，我没有其他更清洁的方法。 + +对于本地开发，Slackbot 在开发计算机上运行。 Ngrok 用作隧道，因此 Slack 可以向该进程发送交互式消息。 使用网站的测试版本将测试机器人安装到团队中。 它具有正确的应用程序令牌，可以识别机器人的测试版本。 安装测试机器人后，您可以通过 Slack 与该机器人对话。 + +对于本地开发测试，通过共享代码使 Lambda 代码变得更加容易。 唯一可以调用的外部服务是其他人的服务，而不是您自己的服务。 因此，要进行测试，根本不需要将代码上传到 Lambda。 Lambda 函数中使用的相同代码可从可从命令行执行的脚本中调用。 为您 API 中的每个函数创建一个相应的脚本，并且可以在本地对其进行完全调试。 + +Messengerbot 的本地开发测试比较棘手，因为将消息发送到 bot 时，消息会显示在 Messenger 中。 当您点击按钮时，回复将返回到您的测试网络挂钩。 据我所知，尚无干净的方法可以以可单元测试的方式进行此操作。 我所做的是将 Bot 的测试版本安装到 Messenger 中并记录了用户 ID。 在为每个方案制作测试脚本时，在运行时选择要使用的用户 ID，测试版本或生产版本。 如果方案涉及要求用户回答问题，则将从脚本中发送问题。 然后，您转到手机上，然后使用测试机器人进行回复。 答复将转到您的测试网络挂钩，以便代码可以正常运行。 我对这种方法不是很满意，但是这种方法确实有效，并且比通过 Messenger 进行的所有测试都更快。 + +总有一天应该从 GitHub 安装所有内容，但今天不是那天。 + +## 采纳 + +吸收不好。 我希望随着税收季节临近活动的到来。 问题的一部分在于，作为一名程序员，我几乎迷上了营销。 我正在尝试 Messenger Bot 广告，但是这些广告无效。 + +使用尝试使漫游器不转化的渠道隐喻用户，他们在实际转化并提出问题之前已经保释。 可能存在信任问题。 他们不知道他们在问谁或将得到什么样的答案。 我尝试在网站和漫游器页面上解决这些问题。 例如，如果您不喜欢答案，则无需付款，因此无风险。 + +一种可能性是人们并没有真正使用 Messenger 机器人，并且对于这种应用程序而言，这是一次失败的实验。 + +另一个可能性是我的机器人不是很好。 完全有可能的事情。 + +如果您有任何想法或疑问，请告诉我。 + +## 获得的经验教训 + +* **不要做您所知道的**。 在盲目做您知道的事情之前，先环顾四周，看看是否有更好的选择。 + +* **API 优先**。 为您的服务提出一个抽象并将其实现在一个地方。 当您必须在不同的平台上实现另一个客户端时，您将感激不尽。 + +* **DTO 首先**。 我犯了通过代码库传播数据库访问代码的错误。 只需创建一个数据传输对象并将代码从一开始就集中在一个地方即可。 然后，可以轻松打包和重用它。 + +* **一次**。 要做的聪明的事情是必须使一个简单的机器人来测试这个概念。 我当时知道这一点，但是我真的很想看看在所有三个平台上开发一个机器人的感觉。 那个决定的人是个白痴。 + +* **吻**。 这么容易说，很难做到。 + +* **提前计划共享节点和浏览器模块**。 一旦已经编写了很多代码，就很难进行改造。 + +* **代码共享**。 在 Lambda 函数之间共享很好的模块化库代码在实践中效果很好。 它使从命令行进行测试变得容易。 + +* **无服务器作品**。 由于种种原因，每个人都在涌动。 它可以让一个人完成很多工作。 您有发展机会，但管理起来却少得多。 对于不可预测的工作负载，它便宜得多且可扩展性更高。 我不能说工具很烂，因为我选择不使用任何工具，但是我们仍然有一种方法可以弄清所有这些在实践中是如何工作的。 + +* **事件> API** 。 使用 webhooks 使用 Serverless 将系统连接在一起非常强大。 相比之下，站起一个盒子并运行一个过程来使用 API​​似乎很原始。 + +像大多数课程一样，回想起来，大多数这些令人沮丧的头脑震撼显而易见，但是我想这就是为什么它们是课程。 + +看起来很酷 + +哇听起来真酷 您是独自建造的吗？ 花了多少时间？ + +是的，只有我。 这花了一个令人尴尬的时间:-) + +@ToddHoff 几乎所有编程都可以，尤其是在您必须学习新知识的情况下，这几乎总是这样，因为有各种各样的工具可以完成工作。 + +您的帖子非常有趣。 我正在尝试从中学习。 但是我不明白一件事。 + +您提到了为 lambda 创建单个入口点，然后将请求路由到单独的函数。 但是，如果没有 API 网关，请求如何首先到达 lambda？ + +嗨，杰克， + +可以通过 API 直接调用 Lambda 函数。 他们不需要通过 HTTP。 我大致是这样做的： + +包括适用于您的环境的 AWS API，对于 Web 或 in 节点而言，有所不同。 + +appcfg.AWS = require（“ aws-sdk”）; +appcfg.DB =新的 appcfg.AWS.DynamoDB（）; +appcfg.DBCLIENT = new appcfg.AWS.DynamoDB.DocumentClient（）; +appcfg.LAMBDA = new appcfg.AWS.Lambda（）; +appcfg.SES =新的 appcfg.AWS.SES（）; +appcfg.SQS = new appcfg.AWS.SQS（）; + +函数 ProbotService（appcfg）{ +this.id = 0; +var self = this; + +this.invokeLambda = function（method，params，next）{ + +var payload = { +method：method， +params：params， +id：self.id ++ +} + +var params = { +FunctionName：appcfg.Amazon.ProbotService， +Payload：JSON.stringify（payload） +} + +appcfg.LAMBDA.invoke（params，function（error，response）{ +if（error）return next（error）; + +var payload = JSON.parse（response.Payload）; +如果（payload.error）返回 next（payload.error）； +如果（payload.errorMessage）返回 next（new Error（payload.errorMessage））; + +返回 next（空，payload.result）； + +}）//调用 + +} // invokeLambda + +嗨，托德， + +感谢您的广泛回应！ + +实际上，我知道如何调用 lambda。 我从您调用它的地方很好奇。 看来您可能是从客户端调用它的？ + +PS。 我刚刚开始学习 nodejs。 因此，无论我说什么，都可能变得毫无意义。 + +是的，无论是网站上的客户端，还是 slack 上的 nodejs 内，还是 lambda 本身的 nodejs 内，都是客户端。 尽管几天前我关闭了 slackbot。 太昂贵了，无法继续运行。 + +只需为环境添加正确的库并正确配置即可。 + +在网上： + +<脚本 src =“ js / aws-cognito-sdk.js” > < / script > +<脚本 src =“ js / amazon-cognito-identity.min.js” > < / script > +<脚本 src =“ https://sdk.amazonaws.com/js/aws-sdk-2.3.5.min.js” > < / script > + +在 slack 和 lambda 上，它们将 sdk 安装到 node_modules 中，并且由于用户看不到环境，因此可以从文件中加载配置。 +var AWS = require（'aws-sdk'）; +AWS.config.loadFromPath（'cfg.json'）; +appcfg.AWS = AWS; + +我保持对 appcfg 中所有服务的访问权并将其传递。 这样，您可以在启动时以特定于环境的方式配置所有内容。 + +现在，您可以在所有环境中使用相同的 lambda 调用代码。 + +this.giveAnswerToPro = function（answer，next）{ +return self.invokeLambda（“ giveAnswerToPro”，答案，下一步）; +} // GiveAnswerToPro + +这是我的模块问题出现的地方。您必须小心在每个环境中包含的内容。 在网络资料中包含一个在 nodejs 中不可用的模块，您已将其破坏。 + +这很酷。 您是否考虑过在营销中使用会计师的图片和/或个人资料？ 甚至有照片。 主页上显示“真实的会计师”，因此看到它可能会让人放心。 + +Hi Todd, + +感谢您的回复！ + +我知道可能要问很多。 但是，如果您不介意，会介意开放源代码并与我们共享吗？ +对像我这样的人进入 nodejs 和 aws 领域确实很有帮助。 + +谢谢。 + +我得考虑杰克。 我不确定如何将我的东西充分分离出来。 + +有趣的文章。 \ No newline at end of file diff --git a/docs/237.md b/docs/237.md index 4833a53..b5c4b72 100644 --- a/docs/237.md +++ b/docs/237.md @@ -1,14 +1,75 @@ -# Joost 网络架构 +# AdStage 从 Heroku 迁移到 AWS -> 原文： [http://highscalability.com/blog/2007/9/7/joost-network-architecture.html](http://highscalability.com/blog/2007/9/7/joost-network-architecture.html) +> 原文： [http://highscalability.com/blog/2017/5/1/the-adstage-migration-from-heroku-to-aws.html](http://highscalability.com/blog/2017/5/1/the-adstage-migration-from-heroku-to-aws.html) -Joost 的网络架构师 Colm MacCarthaigh 在 2007 年 4 月 3 日于曼彻斯特举行的英国网络运营商论坛会议上向[做了本次演讲](http://www.uknof.org.uk/uknof7/MacCarthaigh-Joost.pdf)。 +![](img/222acfea60c08f75dd8f5c824f121167.png) -我没有在上面的文章中看到链接。 但是我有 [http://www.royans.net/files/MacCarthaigh-Joost.pdf](这里有一个副本 [http://www.royans.net/files /MacCarthaigh-Joost.pdf](http://www.royans.net/files/MacCarthaigh-Joost.pdf) +*这是 AdStage 网站可靠性工程负责人 [G Gordon Worley III](https://www.linkedin.com/in/gworley3/) 的来宾[重新发布](https://medium.com/adstage-engineering/migrating-from-heroku-to-aws-our-story-80084d31025e)。* -我在 Joost 论坛上链接了 Colm 的演示视频。 +我在 2013 年秋季加入 [AdStage](https://medium.com/@adstage) 时，我们已经在 Heroku 上运行了。 这是显而易见的选择：超级容易上手，比全尺寸虚拟服务器便宜，并且足够灵活以随着我们的业务发展。 成长，我们做到了。 Heroku 让我们仅专注于构建引人注目的产品，而不会分散管理基础结构，因此，到 2015 年末，我们已同时运行数千个 dynos（容器）以跟上我们的客户。 -[http://www.scaryideas.com/video/2362/](http://www.scaryideas.com/video/2362/) +我们需要所有这些测功机，因为在后端，我们看起来很像[细分](https://medium.com/@segment)，并且像它们一样，我们的许多成本[与用户数量](https://segment.com/blog/the-million-dollar-eng-problem/)成线性比例。 以 25 美元/ dyno /月的价格计算，加上其他技术成本，到 2016 年中期，我们的年度基础设施支出将突破 100 万美元，而这占了 COGS 的很大比例，因此要花费数年才能实现盈利。 坦率地说，这种情况是不可持续的。 工程团队开会讨论了我们的选择，一些快速计算表明我们为 Heroku 的便利每月要支付超过 10,000 美元，而类似资源将直接在 AWS 上花费。 如果我们从 Heroku 迁移，那足以证明工程师专职在基础架构上工作，因此我的任务是成为我们的第一位运营负责人，并带头进行向 AWS 的迁移。 -幻灯片是一样的。 \ No newline at end of file +这也是一个很好的时机，因为 Heroku 已成为我们最大的限制。 我们的工程团队采用了[看板](https://en.wikipedia.org/wiki/Kanban_%28development%29)方法，因此理想情况下，我们会不断产生从构思到完成的故事。 不过，当时我们正在生成大量正在进行的工作，这些工作通常会阻塞我们的发布渠道。 进行质量检查的工作很慢，并且经常被送回以进行错误修复。 “ [在我的计算机](https://jcooney.net/archive/2007/02/01/42999.aspx)上正常工作”的情况经常出现，但是当暴露在我们的暂存环境中时会失败。 由于 AdStage 是写在不同技术堆栈上的相互依赖的服务的复杂组合，因此每个开发人员都很难使其工作站与生产保持最新状态，这也使得部署到分阶段和生产过程很缓慢，需要大量的人工干预 。 但是，我们在此问题上别无选择，因为我们不得不将每个服务都部署为自己的 Heroku 应用程序，从而限制了自动化的机会。 我们迫切需要找到一种替代方法，使我们能够自动化部署并为开发人员提供更早的访问可靠测试环境的机会。 + +因此，除了通过迁移 Heroku 削减成本外，我们还需要清除质量检查约束。 否则，我可以自由地设计我们的 AWS 部署，只要它以最少的代码更改即可运行我们所有的现有服务，但我添加了一些需求： + +* **简单的系统管理** ：我以前使用过 Chef 等工具，并希望避免从头开始频繁重建系统的容易出错的过程。 我想通过登录机器并运行命令来更新机器。 +* **无聊** ：我想使用已知有效的“无聊”技术，而不是尝试一些新技术来解决其问题。 我想将风险集中在业务逻辑而不是基础架构中。 +* **零停机时间** ：在 Heroku 上进行部署往往会导致我们的用户遇到“漏洞”，原因是某些用户请求花费的运行时间比 Heroku 允许的连接耗用时间更长。 我希望能够消除这些斑点。 +* **回滚** ：如果部署出现问题，我希望能够退出部署并使用最新的已知工作版本恢复服务。 +* **有限的复杂度** ：我将是唯一一个专职构建和维护我们的基础架构的人，因此我需要确定项目的范围以适应需求。 + +知道 [Netflix](https://medium.com/@NetflixTechBlog) [设法通过](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)[在 AWS 上运行](http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html)数十亿美元的业务，没有比亚马逊的机器映像和自动缩放组更完美，我决定遵循他们的可靠方法，但绝对没有 意味着“性感”的方法：构建机器映像，使用它在自动伸缩组中创建实例，将其放在弹性负载均衡器之后，并将负载均衡器连接到 DNS 记录，以使我们的客户以及彼此可以访问它们。 + +因此，我着手构建我们的 AWS 部署策略。 + +### 成为 AWS Sumo + +在对系统进行工程设计时，我喜欢花很多时间在进行设计之前先仔细考虑并测试假设。 Rich Hickey 将此称为[吊床驱动的开发](https://www.youtube.com/watch?v=f84n5oFoZBc)。 + +我们的办公室没有吊床，所以我使用了[相扑躺椅](https://www.sumolounge.com/)。 + +![](img/8e7035455cd1d066981cf95862e69d34.png) + +在 2016 年春季的几个月中，我思考并思考并整理了 AWS 部署系统的基础。 它的架构看起来像这样： + +![](img/0c10e55ee443acef0a7f6bd72b5472bf.png) + +它的核心是我们所谓的 AdStage 统一图片。 此机器映像用于为所有环境（从开发和测试到过渡和生产）中的所有服务创建实例。 它上面是我们所有存储库的副本以及运行它们所需的依赖项。 根据一些实例标签的值，实例可以以不同的方式出现以反映其用法。 + +例如，当一个实例以“审阅”模式出现时，所有服务及其从属数据库在该实例上一起运行并相互通信。 这样，进行开发和质量检查的工程师就可以访问运行任意代码版本的完整堆栈的隔离版本。 他们在这些评论框上所做的任何操作都不会影响登台或制作，也不会与其他评论框进行交互，从而完全消除了我们以前的质量检查/登台限制。 另外，只要审核框通过质量检查，就可以对其进行成像，并将该图像部署到生产中。 + +之所以可行，是因为当实例以“登台”或“生产”模式启动时，它还会告知其应运行的服务。 这是由实例从其自动伸缩组继承的标签确定的，这使我们可以启动运行相同代码的实例队列，以分散客户的负载。 对于服务于 Web 请求的自动扩展组，它们连接到弹性负载均衡器，该负载均衡器在我们的服务器之间平均分配请求。 负载平衡器为我们提供了一个固定点，我们可以在该固定点上平稳地交换实例，从而实现零停机时间部署，并使回滚就像将旧版本的统一映像保留在备用数据库中一样容易交换。 + +但是，我们使用的 AWS 资源无法完全协调自身，因此我们编写了一个使用 AWS API 来实现的 Ruby [Thor](https://github.com/erikhuda/thor) 应用程序。 它负责启动审阅框，构建映像，然后将这些映像部署到暂存和生产环境中。 它会在将负载均衡器切换到新版本之前自动验证部署是否正常运行，如果部署完成后检测到问题，则会建议回滚。 它还使用一些巧妙的技巧来协调多个部署并锁定关键资源，以防止多个工程师破坏彼此的部署，因此任何人都可以启动部署，尽管如果这会引起冲突，他们将被停止。 + +这涵盖了我们的所有需求：成像实例使系统管理变得容易，设置很无聊且被广泛使用，部署过程固有的停机时间为零，支持回滚的部署是自动化的，并且在少于 1500 的情况下并不是很复杂 而且，由于它解决了 QA 约束，并且据我们估计将节省 10,000 美元的运营支出，因此剩下的只是计划从 Heroku 到 AWS 的实时迁移。 + +### 实时迁移 + +2016 年 7 月是旧金山的典型节日。 大部分时间，雾气和寒冷的空气使我一直在里面工作，而在我们办公室对面的街道上，准备不足的游客在[龙门](https://www.lonelyplanet.com/usa/san-francisco/attractions/dragons-gate/a/poi-sig/383985/361858)上自拍时发抖。 同样，因为一切都准备从 Heroku 迁移到 AWS，所以我们要做很多工作。 + +我们的客户依靠我们来管理他们的广告活动，自动化他们的广告支出并报告他们的广告效果。 当我们陷入困境时，它们又陷入了直接通过网络界面手动创建和更新广告的黑暗时代。 当我们切换到 AWS 时，他们负担不起我们离线的费用，因此我们将不得不进行实时迁移。 或至少与合理生活一样。 + +我们实施了 1 周的代码冻结，并在星期六的早晨找到了 1 小时的窗口，那时我切换了数据库和其他在运行时不易移动的服务，而 AdStage 进入维护模式。 在准备过程中，我们已经进行了登台系统的迁移，并编写了一部剧本，可以用来削减生产。 我使用代码冻结功能花了一周时间来调整 AWS 部署以匹配 Heroku 部署。 周六上午一切似乎都很好。 我们失败了，我切断了数据库，然后重新启动了 AdStage。 我花了整整一天的时间看监视器，并靠近键盘，以防万一发生任何问题，但是什么也没做。 那天晚上我睡着了，以为一切都很好。 + +在一个 la 懒的星期天早晨之后，我开始在下午收到一些警报，提示我们的进口商正在备份。 当我们研究该问题时，问题很快就变得显而易见：尽管名义上拥有更多的计算资源，但在某种程度上，我们在 AWS 上的 CPU 数量要少于 Heroku。 结果，我们无法跟上，并且每小时我们都越来越落后。 为了避免队列溢出，我们不得不降低导入的频率，最终我们不得不重新打开 Heroku 应用程序以与 AWS 一起运行以跟上工作量。 这与省钱相反。 + +我们发现，Heroku 一直在告诉我们一个幸福的谎言。 官方每个 dyno 仅获得 2 个 [ECU](https://aws.amazon.com/ec2/faqs/#What_is_an_EC2_Compute_Unit_and_why_did_you_introduce_it) ，但实际情况是，由于我们 Heroku 上的邻居没有充分利用它们的全部份额，我们接近了 6 个。 这意味着我们的 AWS 实例数量太小了 3 倍，尽管 Heroku 实际上便宜得多！ 如果只有一种方法可以为更多实例支付更少的费用…… + +那就是我们开始使用竞价型实例的时候。 我们曾考虑过使用它们，因为它们的价格约为按需价格的 1/10，但是它们存在一定的风险，因为如果您的底价低于拍卖价，它们可以随时终止。 幸运的是，这种情况很少发生，否则自动伸缩组会为您管理点实例的复杂性。 另外，如果备份临时扩展组使用按需部署的按需实例，则很容易，如果我们暂时无法获得足够的竞价型实例来满足需求，则可以通过单个命令进行扩展。 我们最终能够将约 80％的机队转换为现场实例，尽管使用的资源比原始预期多了 3 倍，但我们的成本却降低到了预期目标之内。 + +### 结论 + +除了我们对容量的意外低估外，从 Heroku 切换到 AWS 的过程也很顺利。 不过请不要误会我的意思：这是值得做的，因为我们已经达到了将我们的一些基础设施运营纳入内部的经济规模才有意义。 如果我们不花至少一名工程师的薪水来购买可以通过转用 AWS 节省的运营成本，并且如果基础架构没有成为核心能力，那么我们将坚持使用 Heroku 并让那个人（我！）来工​​作 在对我们的业务更重要的事情上。 只是由于经济和流程的变化，从 Heroku 迁移到 AWS 成为了我们的故事的一部分。 + +Heroku 在 AWS 上运行，因此您不必进行过多的迁移就可以减少中间商。 + +...或者您雇用知道如何正确运行数据中心的人员。 + +感谢您的帖子。 非常有趣，只是有几个问题：图像如何获得其初始配置？ 您提到要避免使用 Chef / Puppet 之类的东西，但是大概您仍然需要一些可重复的过程来使用初始配置来构建 AMI。 那是雷神应用程序的功能吗？ + +您应该尝试进行性能调整，例如 JVM 调整，线程池调整等，以降低基础架构成本。 + +似乎没有这么多麻烦就节省了很多。 您节省了全职人员成本，但是在 AWS 上通常需要 DevOps 成本，在 Heroku 中，Dev 团队可以解决。 放大/缩小测功机与 EC2 相比，哪一个更容易？ \ No newline at end of file diff --git a/docs/238.md b/docs/238.md index 7363372..466f145 100644 --- a/docs/238.md +++ b/docs/238.md @@ -1,116 +1,101 @@ -# 维基媒体架构 +# 为何将 Morningstar 迁移到云端：降低 97％的成本 -> 原文： [http://highscalability.com/blog/2007/8/22/wikimedia-architecture.html](http://highscalability.com/blog/2007/8/22/wikimedia-architecture.html) +> 原文： [http://highscalability.com/blog/2017/8/14/why-morningstar-moved-to-the-cloud-97-cost-reduction.html](http://highscalability.com/blog/2017/8/14/why-morningstar-moved-to-the-cloud-97-cost-reduction.html) -Wikimedia 是建立 Wikipedia，Wiktionary 和其他七个 Wiki 矮人的平台。 对于试图扩大巨型网站高度的学生而言，该文档非常有用。 它充满了详细信息和创新思想，这些思想和创新思想已在互联网上一些最常用的网站上得到证明。 +![](img/8afe9df981fbc1c7bfcea8286c1586d5.png) -网站：http：//wikimedia.org/ +企业不会迁移到云。 如果他们这样做，那就等于承认您的 IT 团队很糟糕。 那是常识。 投资研究提供商晨星（Morningstar）正在迁移到云中，他们正变得越来越有企业精神。 他们并没有让我感到无能，他们只是不想再担心所有低级的 IT 问题。 -## 信息来源 +晨星（Morningstar）的 CTO Mitch Shue 在 [AWS Summit Series 2017](https://www.youtube.com/watch?v=vhNvhJGOhSw&ab_channel=AmazonWebServices) 上做了简短的演讲。 它并没有完整的技术细节。 那不是有趣的部分。 演讲更多地是关于他们的动机，他们采取行动的过程以及他们所经历的一些结果。 尽管这更有趣，但我们之前已经听到了很多。 -* [Wikimedia 架构](http://www.nedworks.org/~mark/presentations/san/Wikimedia%20architecture.pdf)* http://meta.wikimedia.org/wiki/Wikimedia_servers* 从 Oracle 到 MySQL 博客中*中的[横向扩展与纵向扩展](http://oracle2mysql.wordpress.com/2007/08/22/12/)。 +我发现最有趣的是晨星作为金丝雀测试的想法。 如果晨星公司成功，那么该死的公司可能破产，我们将看到呆板的主流企业更多地采用云技术。 这是一个复制猫的世界。 这种先例为其他 CTO 提供了做出相同决定所需的掩护。 - ## 平台* * 阿帕奇* 的 Linux* 的 MySQL* 的 PHP* 乌贼* LVS* Lucene 搜索* Memcached 用于分布式对象缓存* Lighttpd Image Server +在整个演讲中，最重要的想法是：迁移到云上可以节省很多成本，但是他们更感兴趣的是“创建无摩擦的开发经验以刺激创新和创造力”。 - ## 统计资料 +软件正在吞噬世界。 毫无疑问，晨星展望未来，看到赢家将是那些能够以最快的速度开发最好的软件的人。 他们需要更好地开发软件。 拥有自己的基础架构是技术债务的一种形式。 是时候偿还债务并开始进行真正的创新工作了，而不是苦苦挣扎。 - * 800 万篇文章遍布数百个语言项目（英语，荷兰语，...）* 世界排名第十繁忙的网站（来源：Alexa）* 指数级增长：每 4-6 个月访问者/流量/服务器增加一倍* 高峰时间 30000 个 HTTP 请求/秒* 3 Gbit / s 的数据流量* 3 个数据中心：坦帕，阿姆斯特丹，首尔* 350 台服务器，范围在 1x P4 至 2x Xeon 四核之间，内存为 0.5-16 GB* 由〜6 人管理* 3 个大洲的 3 个群集 +这是我的谈话内容： - ## 架构 +## 基础设施 - * 地理负载平衡基于客户端解析器的源 IP，将客户端定向到最近的服务器群集。 将 IP 地址静态映射到国家/地区到群集* 使用 Squid 实现的 HTTP 反向代理缓存，按文本分组表示 Wiki 内容，对媒体分组表示图像和大型静态文件。* 当前有 55 个 Squid 服务器，外加 20 个等待设置。* 每个服务器 1,000 个 HTTP 请求/秒，在压力下最多 2500 个* 每个服务器〜100-250 Mbit / s* 每个服务器〜14000-32000 个开放连接* 每个 Squid 服务器最多 40 GB 的磁盘缓存* 每台服务器最多 4 个磁盘（1U 机架服务器）* 8 GB 的内存，Squid 使用的内存的一半* 自使用 CARP 以来，命中率：文本为 85％，媒体为 98％。* PowerDNS 提供地理分布。* 他们在其主要和区域数据中心中构建基于 LVS，CARP Squid，Cache Squid 构建的文本和媒体集群。 在主数据中心中，它们具有媒体存储。* 为了确保提供所有页面的最新版本，将无效请求发送到所有 Squid 缓存。* 一个集中管理的&同步了数百个 Wiki 的软件安装。* MediaWiki 可在多个 CPU 上很好地扩展，因此我们现在购买双四核服务器（每个盒 8 个 CPU 内核）* 与外部存储和 Memcached 任务共享的硬件* Memcached 用于缓存图像元数据，解析器数据，差异，用户和会话以及修订文本。 元数据（例如文章修订历史记录，文章关系（链接，类别等），用户帐户和设置）存储在核心数据库中* 实际修订文本以 blob 形式存储在外部存储中* 静态（上载）文件（例如图像）分别存储在图像服务器上-元数据（大小，类型等）存储在核心数据库和对象缓存中* 每个 Wiki 都有独立的数据库（不是独立的服务器！）* 一个主机，许多复制的从机* 读取操作在从属服务器上实现负载平衡，写入操作转到主服务器* 如果从站尚未更新（滞后），则将主站用于某些读取操作* 外部存储 - -文章文本存储在单独的数据存储群集中，即简单的仅附加 blob 存储。 为大量未使用的数据节省昂贵和繁忙的核心数据库上的空间 - -允许在应用程序服务器上使用备用资源（每个服务器 2x - 250-500 GB） - -当前使用了 3 个 MySQL 主机的复制集群； - 为了更好的可管理性，将来可能会改变 +* 全球 8 个数据中心 +* 11,318 个应用服务器 +* 7,894 个数据库实例 +* 4PB 存储 - ## 得到教训 +## 改变的时候了 - * 专注于体系结构，而不是操作或非技术性内容。 +* 想象一下在修补，升级，管理和保护 8 个全球数据中心方面所做的工作。 运行非常复杂。 +* 问题不在于他们的 IT 员工。 他们对 IT 感到满意。 +* 想要最大化人才，拥有更少的基础架构并专注于核心业务。 +* 想要简化和减少复杂性。 +* 运行数据中心并不能与它们区分开。 - * 有时，缓存比重新计算或查找 - 数据源要花更多的钱……剖析！ +## 改变文化 - * 避免使用昂贵的算法，数据库查询等。 +* 过渡到云需要来自世界各地的 1400 名技术人员的参与。 不容易做到。 +* 来自世界各地的许多半自治团体都有各自的路线图和团队目标。 +* 既定的高级技术目标：最大化人才，拥有更少的基础设施，减少复杂性，提高产品完整性，产品安全性，产品可恢复性，产品可靠性，更好的正常运行时间，更好的监控和更快的事件响应。 +* 选择目标的目的是易于重复，易于理解且不会过期。 +* 不要对自己的文化感到被动。 通过有目的的重复将这些目标融入您的文化：大量会议，博客文章，演示和对话。 +* 迁移到 AWS 支持这些目标。 - * 缓存所有昂贵且具有时间参考性的结果。 +## 策略：快速行动然后优化 - * 关注代码中的热点（概要分析！）。 +* 数据收集团队最初使用提升和转换方法迁移到 AWS。 那使他们迅速进入了云端。 +* 一旦一切正常，他们就开始降低复杂性。 +* 将 SQL Server 替换为 RDS for PostgreSQL。 +* 添加了用于消息传递的 Kinesis，因此他们可以更好地控制工作负载分配。 +* 由于他们的应用程序每天仅运行 2-4 小时，因此他们用 Lambda 函数替换了所有 EC2 实例。 +* 致力于制定按需创建和销毁整个计算机环境的策略。 +* 将他们的数据湖移至 S3。 +* 不断进行迭代以降低复杂性。 - * 通过分开进行缩放： - -读写操作（主/从） - -廉价操作和更频繁操作（查询组）中的昂贵操作 - -小型 Wiki 中的大型，流行 Wiki +## 结果：降低了 97％的成本 - * 改善缓存：参考的时间和空间局部性，并减少每个服务器的数据集大小 +* 当然，该项目是经典的 Lambda 用例。 空闲时间这么多，全时 EC2 实例没有多大意义。 +* 但话又说回来，您可以想象整个企业中有许多这样的潜在优化。 - * 文本被压缩，并且仅存储文章之间的修订。 +## 未来 - * 简单的看似库调用（例如使用 stat 来检查文件的存在）在加载时可能会花费很长时间。 +* 到 2017 年，核心数据 API 将移动数 TB 的数据，每天处理数百万条消息。 +* 到 2018 年，他们将存储超过 2PB 的数据，每天处理超过 20 亿条消息，以支持超过 5 亿美元的产品收入。 +* 到 2020 年将自己的基础设施减少 70％的目标。 +* 悉尼数据中心将于 2018 年关闭。通过迁移非生产环境来缩小深圳的占地面积。 +* 创建了一个卓越的云计算中心，以重新考虑安全性，部署和运营等领域。 +* 将启动再培训计划，以对内部人员的技能进行投资和现代化（不错！）。 +* 成本效率很高，但他们也有兴趣创造一种无摩擦的开发经验以刺激创新和创造力。 他们采取此举似乎是一个重要原因。 - * 磁盘搜寻 I / O 受限，磁盘心轴越多越好！ +## 为什么选择 AWS？ - * 使用商品硬件的横向扩展不需要使用便宜的硬件。 如今，Wikipedia 的数据库服务器是 16GB 的双核或四核机箱，其中有 6 个 15,000 RPM SCSI 驱动器（采用 RAID 0 设置）。 这恰好是他们拥有的工作集和负载平衡设置的最佳选择。 如果可以的话，他们会使用更小/更便宜的系统，但是 16GB 的空间适合工作集大小，这将驱动其余的规范以匹配具有那么多 RAM 的系统的需求。 类似地，Web 服务器目前是 8 个核心设备，因为它恰好可以很好地用于负载平衡，并通过相对容易的负载平衡提供了良好的 PHP 吞吐量。 +* 谈话的这一部分听起来像是 AWS 新闻稿，毕竟这是一次 AWS 会议，但这是企业 CTO 如何思考问题的一个很好的例子。 +* 喜欢 AWS 的步伐创新，服务呼吸和专业支持。 +* 转向 AWS 并拥有更少的基础架构意味着更多的容量，更多的安全性，更高的可靠性，更多的安心和更多的创新自由。 - * 扩大规模是一项艰巨的工作，如果您不是最初设计的，则需要做更多工作。 Wikipedia 的 MediaWiki 最初是为单个主数据库服务器编写的。 然后添加了从属支持。 然后添加了按语言/项目划分。 那时的设计经受住了考验，尽管需要进行更多的改进以解决新的瓶颈。 +[关于 HackerNews](https://news.ycombinator.com/item?id=15010310) - * 任何想要设计数据库体系结构，以便允许它们廉价地从一台机器升级到网络上排名前十或百位的站点的人，都应该从设计它来处理复制从属设备的过时数据开始， 知道如何为所有读取查询负载均衡给从属服务器，并尽可能设计它以便数据块（用户批次，帐户等等）可以放在不同的服务器上。 从第一天开始，您就可以使用虚拟化来完成此工作，并在小巧的时候证明其架构。 当负载每几个月增加一倍时，这比做起来容易得多！ +上周没有“互联网说可扩展性”一文。 这是故意遗漏的吗？ :) -对于那些在有限的预算下处理大量可缓存内容（例如，能够返回有效到期标头的内容）的人来说，我的建议是采用反向代理，如本文所述。 +通过重写所有基础架构和代码将成本降低 97％，可以 +迁移到 AWS：昂贵，但不到 2020 年在全球范围内维护 1995 年的基础架构 +投入使用，成本降低了 70％以上 -在上周，我们有一个站点获得了 AP，在不到 5 小时的时间内触发了 10 万唯一身份访问者访问单个 IIS 服务器。 它取出了 IIS 服务器。 在适中的 Intel IV 3Ghz 上，将服务器的单个鱿鱼放置在服务器的前端即可处理整个攻击，最大服务器负载为 0.10。 +如果您不能让工程师和开发人员升级/优化软件，请上云；如果您不是一家没有客户的初创公司，请始终保持低价…… -对于任何有兴趣的人来说，实现它都是微不足道的。 +抱歉，该 zbb。 我本来有最好的意图，但我生日那天不在，只是没有足够的时间来完成它。 我们本周上班。 如果我的老手仍然可以输入:-) -[http://wiki.squid-cache.org/SquidFaq/ReverseProxy](http://wiki.squid-cache.org/SquidFaq/ReverseProxy) +我也错过了星期五的帖子！ -有很多服务器。 似乎他们比添加慢速的 php 脚本更好地添加新服务器 +希望你生日快乐。 -向我展示服务器数量较少的前十名网站。 只有一个。 如果您发现任何东西，我会感到惊讶。 +我做了卡尔，谢谢！ -我一直对 Wikimedia 架构感到惊讶，他们做得很好。 +>如果您不是一家没有客户的初创企业，它总是“低声”。 -这是一个很好的理由，为什么您不想要选择 squid 作为反向代理。 +这就是为什么我认为这是一个有趣的案例，修剪。 显然，他们有自己的印章，可以按自己的方式办事。 如果他们认为节省的成本不堪重负，他们会坚持并留下来，但事实并非如此。 -[http://varnish.projects.linpro.no/wiki/ArchitectNotes](http://varnish.projects.linpro.no/wiki/ArchitectNotes) +关于它们的“空闲时间优化”，我一无所获：为什么有人需要 11k 的应用程序服务器和 7k 的数据库服务器来处理“每天仅工作 2-4 小时”的应用程序？ -问候， +我对 Reader 的理解是，这些数字是指他们的整个系统，而空闲时间是指他们最初选择迁移到 AWS 的系统。 -斯瑞吉斯 - -Sreejith： - -我不确定在使用持续充满（意味着驱逐不断发生）缓存时，是否证明清漆与鱿鱼一样稳定或快速。 直到最近，清漆才有了驱逐机制。 - -如果您知道这种用法，请分享。 :) - -嗨，有人知道如何扩展 Lucene 吗？ - -他们是否使用在多个盒子之间共享数据的任何文件系统？ - -我认为在这种情况下，成功的重点是地理分布，而不仅仅是缓存或其他。 - -Show me a top-10 website with less servers. Just one. I'd be amazed if you'd find any. - -@以上职位。 -我认为这是不可能的。如果没有至少 3 台服务器，它总是必须经过。 ------ -[http://underwaterseaplants.awardspace.com“](海洋植物 -[http://underwaterseaplants.awardspace.com/seagrapes。 htm“](海葡萄... [http://underwaterseaplants.awardspace.com/seaweed.htm”](海藻 - -不可能 - -更新： - -* [http://www.networkworld.com/news/2009/011309-wikipedia-digital-media.html“]( Wikipedia 为数字媒体的爆炸式发展做好了准备 - -* [http://blogs.sun.com/WebScale/entry/scaling_wikipedia_with_lamp_7“](使用 LAMP 扩展 WikiPedia：每月 70 亿页面浏览量 - -* [http://blogs.sun.com/jonathan/entry/open_storage_wins_at_wikipedia“](开放存储在 Wikipedia 上获胜 - -视频文件的大小正迅速达到数十兆和数百兆字节，而高百万像素相机的普及意味着，即使是小照片也可能占用几兆字节。 Vibber 说，直到 2008 年初，用户生成的百科全书库的主要媒体文件服务器只有 2TB 的总空间。 - -“很长一段时间以来，我们只是没有[处理非常大的媒体文件]的能力，”他说。 - -此后，维基百科已将其主要的中间文件服务器的存储容量从 2TB 扩展到 24TB，现在增加到 48TB，并且最近将文件上传限制从 20MB 提高到了 100MB。 Vibber 说，实际使用的存储量大约为 5TB，但是它将迅速增长。 \ No newline at end of file +“用 RDS 替换 PostgreSQL 的 SQL Server”可能节省了 50％的 M $ \ No newline at end of file diff --git a/docs/239.md b/docs/239.md index aa6f683..85f5a31 100644 --- a/docs/239.md +++ b/docs/239.md @@ -1,46 +1,92 @@ -# TypePad 建筑 +# ButterCMS 体系结构：关键任务 API 每月可处理数百万个请求 -> 原文： [http://highscalability.com/blog/2007/8/20/typepad-architecture.html](http://highscalability.com/blog/2007/8/20/typepad-architecture.html) +> 原文： [http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html](http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html) -TypePad 被认为是世界上最大的付费博客服务。 在经历了因其快速增长而引起的问题之后，他们最终过渡到了以其姊妹公司 LiveJournal 为模式的架构。 +![](img/73b3493317ddb8421dbc8da23b060ef8.png) -网站：http：//www.typepad.com/ +*这是 [Jake Lumetta](https://twitter.com/jakelumetta) 的来宾帖子， [ButterCMS [](https://buttercms.com/) 。* -## 该平台 +[ButterCMS](https://buttercms.com/) 使开发人员可以在几分钟内将内容管理系统添加到任何网站。 我们的业务要求我们为 API 提供近 100％的正常运行时间，但是在多次中断几乎使我们的业务瘫痪之后，我们开始着迷于消除单点故障。 在这篇文章中，我将讨论如何快速使用 [](https://www.fastly.com/)的边缘云平台和其他策略，以确保我们保持客户网站的正常运行 。 -* 的 MySQL* 记忆快取* 佩尔* MogileFS* 阿帕奇* Linux +ButterCMS 的核心功能是： - ## 统计资料 +* 内容编辑器的仪表板 - * 从 2005 年开始，TypePad 使用多个网络管道发送 250mbps 的流量，每天的流量为 3TB。 他们每月增长 10-20％。 我找不到更多最新统计数据。 +* 一个 [JSON API](https://buttercms.com/docs/api/) ，用于获取内容 - ## 架构 +* [SDK，用于将 ButterCMS](https://github.com/buttercms) 集成到本机代码中 - * 原始体系结构： - -运行 Linux，Apache，Postgres，Perl，mod_perl 的单个服务器 - -存储为文件服务器上的 NFS。* 毁灭性的崩溃导致了新的发展方向 - -RAID 控制器发生故障，并在所有 RAID 磁盘上喷射了数据。 - -数据库已损坏，备份也已损坏。 - -他们多余的锉刀患有“裂脑”综合征。* 他们转移到 [LiveJournal Architecture](http://highscalability.com/livejournal-architecture) 类型的体系结构，这并不奇怪，因为 TypePad 和 LiveJounral 都由 Six Apart 拥有。 - -按 ID 分区的复制 MySQL 群集。 - -全局数据库生成全局唯一序列号并将用户映射到分区。 - -其他数据是按角色映射的。* 高度可用的数据库配置： - -使用主-主 MySQL 复制模型。 - -使用[虚拟 IP 地址](http://www.linuxvirtualserver.org/HighAvailability.html)使用 Linux 群集心跳进行故障转移。* MogileFS 用于提供图像。* Perlbal 用作反向代理并负载均衡请求。* 一个称为 TheSchwartz 的可靠的异步作业分配系统用于支持博客，添加注释，将来的发布，缓存失效和发布。* Memcached 用于存储计数，集合，统计信息和重量级数据。* 从旧体系结构到新体系结构的迁移非常棘手： - -所有用户都被迁移而不会中断服务。 - -Postgres 已删除。 - -在迁移期间，从 NFS 和 MogileFS 提供了映像。* 他们的新架构的优点： - -可以轻松添加新机器并调整工作量。 - -更高可用且价格便宜的可伸缩 +## ButterCMS 技术堆栈 - ## 得到教训 +ButterCMS 是一个单一的 Django 应用程序，负责营销网站，编辑工具，API 和后台工具，以提供客户支持。 Django 应用程序与 Postgres 数据库一起在 Heroku 上运行。 - * 小细节很重要。* 每个错误都是学习经验。* Success requires coordination and cooperation. +我们还利用以下第三方服务： - ## 相关文章 +* [文件堆栈](https://www.filestack.com/) 用于为其客户提供图像编辑功能 - * [LiveJournal 体系结构](http://highscalability.com/livejournal-architecture)。* [Linux 高可用性](http://www.linuxvirtualserver.org/HighAvailability.html)。 +* [快速](https://www.fastly.com/) 用于外部 API 缓存和交付 -“ Memcached 用于存储计数，集合，统计信息和重量级数据。” +* [Cloudfront](https://aws.amazon.com/cloudfront/) 作为客户资产的 CDN -我们在 soulcast.com 上做了类似的事情，我很好奇它们如何将计数推到磁盘/数据库上，以及它们执行的频率。 另外，有人知道“集”是什么意思吗？ \ No newline at end of file +* 用于 DNS 的 [EasyDNS](https://www.easydns.com/) + +## 停机时间是致命的 + +我们的客户通常会建立在请求/响应生命周期内向 ButterCMS 发出 API 请求以获取页面内容的网站。 这意味着，如果他们对 ButterCMS 的 API 请求失败，则他们的页面可能无法呈现。 如果我们的 API 出现故障，那么客户的网站也会与我们发生故障。 + +这是我们在早期学习的艰辛课程。 不可靠的服务器托管导致频繁的间歇性停机和性能下降，使客户感到沮丧。 糟糕的 DNS 迁移导致 API 停机数小时，从而使数十个客户的网站瘫痪了近半天，并使大量客户质疑他们是否可以继续依赖我们（其中有少数人离开了我们）。 + +在此事件之后，我们意识到确保接近 100％的正常运行时间是一个存在的问题。 未来发生的重大故障可能导致我们失去来之不易的客户，并使我们的业务陷入危机。 + +## 提供全局，快速，弹性的 API + +无法完全避免失败-您只能尽力减少机会。 + +例如，通过运行自己的物理服务器来“控制自己的命运”可以保护您的主机提供商免受崩溃的困扰，但是却使您处于必须处理安全性和可伸缩性的位置，这两者都可以轻松使您崩溃并 很难恢复。 + +对于我们的团队而言，始终保持 API 的正常运行并确保其在全球范围内提供高性能至关重要。 但是作为一家较小的公司，我们知道我们没有足够的资源来提供具有近 100％正常运行时间的全球性，高度可扩展的性能。 因此，我们转向了这样做的人： [快速](https://www.fastly.com/) 。 + +迅速将自己描述为“为全球最受欢迎的企业提供快速，安全和可扩展的数字体验的边缘云平台”。 他们与包括《纽约时报》，BuzzFeed，Pinterest 和 New Relic 等大型客户合作。 我们将 Fast 放在我们的 API 前面作为缓存层，以便所有 API 请求都通过其 CDN 进行处理。 ![](img/23f51f8296408b47a4f28e71b6ffafb1.png) + +当我们的一位客户在 ButterCMS 中更新其网站内容时，我们将使已编辑内容的特定位的 API 密钥无效。 非缓存的请求命中了我们的服务器，但命中率达到了 94％，因为客户网站上的内容相对于获得的访问者数量很少变化。 这意味着，即使我们的数据库或服务器遇到间歇性的中断，我们的 API 仍然可以运行。 我们不希望这样，但是从理论上讲，只要 Fastly 保持正常运行，服务器可能会完全瘫痪几个小时，而且客户的网站也会保持正常运行。 + +Fastly 的全球 CDN 为我们带来了另一个好处。 我们的许多客户都有静态 JavaScript 网站，这些 API 网站的访问者访问者是浏览器而不是服务器。 通过 Fastly 的 CDN 提供 API 响应，意味着我们的客户的网站访问者无论身在何处，都能获得快速的加载时间。 + +## 消除单点故障 + +在 ButterCMS 成立之初，我们处理了两次单独的 DNS 事件，这使我们感到恐惧。 在第一起事件中，我们的 DNS 提供商当时不小心从其系统中“取消”了我们的帐户，导致断电花费了将近 6 个小时才能使我们完全恢复。 我们的第二次事件发生在常规 DNS 编辑导致我们的[不同的] DNS 提供程序发生故障时，并且花费了将近半天的时间来解决。 DNS 事件尤其具有破坏性，因为即使在确定并解决问题后，您也必须等待各种 DNS 服务器和 ISP 清除缓存，然后客户才能看到解决方案（DNS 服务器也倾向于忽略您的 TTL 设置并强加 他们自己的政策）。 + +我们的经验使我们非常专注于消除整个体系结构中的任何单点故障。 + +对于 DNS，我们切换为使用来自不同 DNS 提供商的多个名称服务器。 DNS 提供程序通常允许并鼓励您使用 4-6 个冗余名称服务器（例如 ns1.example.com，ns2.example.com）。 很好：如果一个请求失败，其他请求仍然可以解决。 但是，由于您所有的名称服务器都来自同一家公司，因此您非常相信他们将拥有 100％的正常运行时间。 + +对于我们的应用服务器，我们使用 Heroku 的监控和 [自动缩放](https://blog.heroku.com/heroku-autoscaling) 工具，以确保我们的性能不会因流量高峰（或 如果快速崩溃，我们突然需要将所有请求直接路由到我们的服务器）。 除了使用 Fastly 缓存 API 外，我们还使用 Memcached 在应用程序级别缓存 API。 这为间歇性数据库或服务器故障提供了额外的缓冲层。 + +为防止在 Heroku 或 AWS（Heroku 运行于其上）之间发生极少数情况下的总停机，我们在 Google Cloud 上维护了单独的服务器和数据库实例，可以将其快速故障转移。 + +## 不可避免的是失败 + +不管我们的 API 有多可靠，我们都必须接受 [不可靠的网络](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) ，并且网络肯定会发生故障。 我们所有人在连接 Wi-Fi 时都遇到了麻烦，或者突然打了个电话。 从统计上讲，中断，路由问题和其他间歇性故障在总体上可能是异常的，但始终会始终以某个环境本底速率发生。 + +为克服这种本质上不可靠的环境，我们帮助客户构建在出现故障时将变得可靠的应用程序。 我们的 SDK 提供的功能，例如 [在 API 请求失败时自动重试](https://github.com/ButterCMS/buttercms-csharp/pull/2) 或 [支持，可轻松使用故障转移缓存](https://github.com/ButterCMS/buttercms-ruby#fallback-data-store) ，例如客户端上的 Redis。 + +## 结论 + +没有意识到这一点，我们中的许多人正在将单点故障构建到我们的堆栈中。 在 ButterCMS，我们的成功取决于确保客户的应用程序不会因为我们而出现故障。 为此，我们从后端基础架构中消除了尽可能多的单点故障，并提供了 SDK，可让我们的客户轻松实现其应用程序中的弹性和容错能力。 + +### 关于 ButterCMS + +当您听到“ CMS”或“博客”消息时，您可能会想到 WordPress。 ButterCMS 是一种较新的替代方法，它允许开发团队使用 ButterCMS API 将 CMS 和博客功能添加到他们自己的本机代码库中。 + +ButterCMS 由 [Jake Lumetta](https://twitter.com/jakelumetta) 和 [Abi Noda](https://twitter.com/abi) 发起，因为他们俩都遇到了寻找功能齐全，灵活且未将您绑定到特定 WordPress 的替代品的挑战 像 PHP 这样的编程语言.. + +如今，ButterCMS 为全球数百个网站提供支持，每月帮助处理数百万个请求。 + +你好杰克， + +在本文中，我看到两个语句。 +->快速用于外部 API 缓存和交付 + +-> Cloudfront 作为客户资产的 CDN + +是否有特定原因将 Cloud Front 用作客户资产？ 为什么我们不能快速使用 CDN？ \ No newline at end of file diff --git a/docs/24.md b/docs/24.md index 8caae40..54fe86f 100644 --- a/docs/24.md +++ b/docs/24.md @@ -1,363 +1,221 @@ -# Jeff Dean 在 Google 进行大规模深度学习 +# YouTube 架构 + +> 原文： [http://highscalability.com/blog/2008/3/12/youtube-architecture.html](http://highscalability.com/blog/2008/3/12/youtube-architecture.html) + +**更新 3：** [在 30 分钟内进行 7 年的 YouTube 可扩展性课程](http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html)和 [YouTube 策略：添加抖动不是一个错误](http://highscalability.com/blog/2012/4/17/youtube-strategy-adding-jitter-isnt-a-bug.html) + +[](http://highscalability.com/blog/2012/4/17/youtube-strategy-adding-jitter-isnt-a-bug.html)**更新 2：** [YouTube 每天达到 10 亿观看](http://mashable.com/2009/10/09/youtube-billion-views/)。 *即每秒至少 11574 次观看，每分钟 694444 次观看和每小时 41666666667 次观看。* + +**更新：** [YouTube：平台](http://www.techcrunch.com/2008/03/12/youtube-the-platform/)。 YouTube 添加了一组丰富的新 API，以免费成为您的视频平台领导者。 在您自己的网站上上传，编辑，观看，搜索和评论视频，而无需访问 YouTube。 通过 API 在内部组成您的网站，因为无论如何以后您都需要公开它们。 + +YouTube 的增长速度非常快，每天的视频观看次数超过 1 亿，只有少数人负责网站的扩展。 他们如何设法将所有视频交付给所有这些用户？ 自从 Google 收购以来，它们又如何发展？ + +## 信息来源 + +1. [Google 视频](https://www.youtube.com/watch?v=w5WVu624fY8) + +## 平台 + +1. 阿帕奇 +2. 蟒蛇 +3. Linux（SuSe） +4. 的 MySQL +5. psyco，动态 python- > C 编译器 +6. 用于视频而不是 Apache 的 lighttpd + +## 里面有什么？ + +### 统计资料 + +1. 支持每天交付超过 1 亿个视频。 +2. 成立于 2/2005 +3. 3/2006 每天 3000 万次视频观看 +4. 7/2006 每天有 1 亿次视频观看 +5. 2 位系统管理员，2 位可扩展软件架构师 +6. 2 位功能开发人员，2 位网络工程师，1 位 DBA + +### 处理快速增长的配方 + +`while (true) +{ +identify_and_fix_bottlenecks(); +drink(); +sleep(); +notice_new_bottleneck(); +}` + +该循环每天运行多次。 + +### 网络服务器 + +1. NetScalar 用于负载平衡和缓存静态内容。 +2. 使用 mod_fast_cgi 运行 Apache。 +3. 请求被路由以由 Python 应用服务器处理。 +4. 应用服务器与各种数据库和其他信息源进行对话，以获取所有数据并格式化 html 页面。 +5. 通常可以通过添加更多计算机来扩展 Web 层。 +6. Python Web 代码通常不是瓶颈，它大部分时间都花在了 RPC 上。 +7. Python 允许快速灵活的开发和部署。 考虑到他们面临的竞争，这至关重要。 +8. 通常少于 100 毫秒的页面服务时间。 +9. 使用 psyco，这是一种动态 python- > C 编译器，它使用 JIT 编译器方法来优化内部循环。 +10. 对于诸如加密之类的占用大量 CPU 资源的活动，它们使用 C 扩展名。 +11. 一些预生成的缓存 HTML，用于渲染块很昂贵。 +12. 数据库中的行级缓存。 +13. 完整格式的 Python 对象将被缓存。 +14. 计算一些数据并将其发送到每个应用程序，以便将这些值缓存在本地内存中。 这是一个未被充分利用的策略。 最快的缓存位于您的应用程序服务器中，不需要花费很多时间就可以将预先计算的数据发送到所有服务器。 只需要一个代理来监视更改，预先计算和发送即可。 + +### 影片投放 + +* 成本包括带宽，硬件和功耗。* 每个视频由一个迷你集群托管。 每个视频由一台以上的机器提供。* 使用群集意味着： + -提供内容的更多磁盘意味着更高的速度。 + -净空。 如果机器故障，其他人可以接管。 + -有在线备份。* 服务器将 lighttpd Web 服务器用于视频： + -Apache 的开销太大。 + -使用 epoll 等待多个 fds。 + -从单进程配置切换到多进程配置以处理更多连接。* 最受欢迎的内容已移至 CDN（内容交付网络）： + -CDN 在多个位置复制内容。 更有可能使内容更接近用户，跳数更少，并且内容将在更友好的网络上运行。 + -CDN 机器主要用于内存不足，因为内容是如此受欢迎，几乎没有内容在内存中跳动的情况。* 不太受欢迎的内容（每天 1-20 次观看）在各种 colo 网站中使用 YouTube 服务器。 + -有长尾巴效果。 视频可能有一些播放，但是正在播放很多视频。 正在访问随机磁盘块。 + -在这种情况下，缓存没有太大的用处，因此花钱购买更多的缓存可能没有意义。 这是非常有趣的一点。 如果您的产品尾部很长，那么缓存并不总是您的性能救星。 + -调整 RAID 控制器，并注意其他较低级别的问题以提供帮助。 + -调整每台机器上的内存，所以不要太多也不要太少。 -> 原文： [http://highscalability.com/blog/2016/3/16/jeff-dean-on-large-scale-deep-learning-at-google.html](http://highscalability.com/blog/2016/3/16/jeff-dean-on-large-scale-deep-learning-at-google.html) +### 提供视频关键点 - -*If you can’t understand what’s in information then it’s going to be very difficult to organize it.* +1. 保持简单和便宜。 +2. 保持简单的网络路径。 内容和用户之间没有太多设备。 路由器，交换机和其他设备可能无法承受如此多的负载。 +3. 使用商品硬件。 硬件越昂贵，其他所有东西（支持合同）也就越昂​​贵。 您也不太可能在网上找到帮助。 +4. 使用简单的通用工具。 他们使用大多数内置在 Linux 中的工具，并在这些工具之上。 +5. 处理随机寻优（SATA，调整）。 -此引用来自 [Jeff Dean](http://research.google.com/pubs/jeff.html) ，目前是 Google 系统基础架构小组的向导，研究员，研究员。 摘自他最近的演讲： [智能计算机系统的大规模深度学习](https://www.youtube.com/watch?v=QSaZGT4-6EY) 。 +### 服务缩图 -自 [AlphaGo 诉 Lee Se-dol](https://gogameguru.com/tag/deepmind-alphago-lee-sedol/) 以来， [John Henry](https://en.wikipedia.org/wiki/John_Henry_(folklore)) 的现代版本 与 的致命一击 [像蒸汽锤一样，吸引了全世界，对 AI 的普遍恐惧](https://www.youtube.com/watch?v=j3LVFdWBHVM) [[ 启示录](http://thenextweb.com/insider/2014/03/08/ai-could-kill-all-meet-man-takes-risk-seriously/) ，这似乎是掩盖 Jeff 演讲的绝佳时机。 而且，如果您认为 AlphaGo 现在很好，请等到 beta 达到。 +* 出人意料的是，很难高效地进行。* 每个视频都有大约 4 个缩略图，因此缩略图比视频要多得多。* 缩略图仅托管在几台计算机上。* 看到了与服务许多小对象相关的问题： + -大量磁盘搜索以及操作系统级别的 inode 高速缓存和页面高速缓存出现问题。 + -进入每个目录文件的限制。 特别是 Ext3。 转移到更分层的结构。 2.6 内核的最新改进可以将 Ext3 大目录处理提高到[的 100 倍](http://ext2.sourceforge.net/2005-ols/paper-html/node3.html)，但是在文件系统中存储大量文件仍然不是一个好主意。 + -大量请求/秒，因为网页可以在页面上显示 60 个缩略图。 + -在如此高的负载下，Apache 的表现很差。 + -在 Apache 前面使用过的鱿鱼（反向代理）。 这工作了一段时间，但是随着负载的增加，性能最终下降了。 从 300 请求/秒增加到 20。 + -使用 lighttpd 尝试过，但是只有一个线程使它停顿了。 在多进程模式下会遇到问题，因为它们每个都会保留一个单独的缓存。 + -设置了如此多的图像后，一台新机器花费了 24 小时。 + -重新启动计算机需要 6 到 10 个小时才能将缓存预热，以使其不进入磁盘。* 为了解决他们所有的问题，他们开始使用 Google 的 BigTable（分布式数据存储）： + -避免小文件问题，因为它将文件聚集在一起。 + -快速，容错。 假定它在不可靠的网络上工作。 + -较低的延迟，因为它使用了分布式多级缓存。 此缓存可在不同的并置站点上工作。 + -有关 BigTable 的更多信息，请查看 [Google 架构](http://highscalability.com/google-architecture)， [GoogleTalk 架构](http://highscalability.com/googletalk-architecture)和 [BigTable](http://highscalability.com/tags/bigtable) 。 -Jeff 当然是指 Google 臭名昭著的 [座右铭](https://www.google.com/about/company/) ： *整理世界各地的信息并使其广泛传播 可访问且有用的* 。 +### 资料库 -从历史上看，我们可能会将“组织”与收集，清理，存储，建立索引，报告和搜索数据相关联。 早期 Google 掌握的所有东西。 完成这项任务后，Google 便迎接了下一个挑战。 +1. 早期 + -使用 MySQL 存储元数据，例如用户，标签和说明。 + -从具有 10 个磁盘的单片 RAID 10 卷中提供数据。 + -以信用卡为生，因此可以租用硬件。 当他们需要更多硬件来处理负载时，花了几天时间订购并交付。 + -他们经历了一个共同的演变：单个服务器，转到具有多个读取从属的单个主机，然后对数据库进行分区，然后决定采用分片方法。 + -出现复制延迟。 主机是多线程的，可在大型计算机上运行，​​因此它可以处理大量工作。 从站是单线程的，通常在较小的计算机上运行，​​并且复制是异步的，因此从站可能会大大落后于主站。 + -更新导致高速缓存未命中，而高速缓存 I / O 导致复制缓慢的磁盘丢失。 + -使用复制体系结构，您需要花费大量金钱来增加写入性能。 + -他们的解决方案之一是通过将数据分为两个集群来优先处理流量：视频观看池和通用集群。 这个想法是人们希望观看视频，以便该功能应获得最多的资源。 YouTube 的社交功能不太重要，因此可以将其路由到功能较弱的群集中。 +2. 后来的几年： + -进行数据库分区。 + -分为多个分片，用户分配了不同的分片。 + -传播写入和读取。 + -更好的缓存位置，意味着更少的 IO。 + -导致硬件减少 30％。 + -复制副本延迟减少到 0。 + -现在几乎可以任意扩展数据库了。 -现在 **的组织意味着对** 的理解。 +### 数据中心策略 -我的演讲重点： +1. 首先使用[管理托管](http://www.webhostingsearch.com/managed-web-hosting.php)提供程序。 以信用卡为生，所以这是唯一的方法。 +2. 托管托管无法随您扩展。 您无法控制硬件或达成有利的网络协议。 +3. 所以他们去了一个代管安排。 现在，他们可以自定义所有内容并协商自己的合同。 +4. 使用 5 或 6 个数据中心以及 CDN。 +5. 视频来自任何数据中心。 没有最接近的匹配或任何内容。 如果视频足够受欢迎，它将移入 CDN。 +6. 与视频带宽有关，而与延迟无关。 可以来自任何 colo。 +7. 对于图像延迟很重要，尤其是当页面上有 60 张图像时。 +8. 使用 BigTable 将图像复制到不同的数据中心。 代码 + 查看不同的指标以了解谁最接近。 -* **实际的神经网络由数亿个参数**组成。 Google 的技能在于如何在大型有趣的数据集上构建并快速训练这些巨大的模型，将其应用于实际问题，*和*然后在各种不同平台（电话）上将模型快速部署到生产环境中 ，传感器，云等）。 +## 得到教训 -* 神经网络在 90 年代没有兴起的原因是**缺乏计算能力，也缺少大型有趣的数据集**。 您可以在 Google 上看到 Google 对算法的天生喜爱，再加上庞大的基础架构和不断扩大的数据集，如何为 AI 掀起一场**完美的 AI 风暴。** +1. **停顿时间**。 当您制定长期解决方案时，富有创意和冒险性的技巧可以帮助您在短期内应对。 +2. **确定**的优先级。 知道什么对您的服务至关重要，并根据这些优先级确定资源和工作的优先级。 +3. **选择战斗**。 不要害怕外包一些基本服务。 YouTube 使用 CDN 分发其最受欢迎的内容。 创建自己的网络将花费很长时间并且花费太多。 您的系统中可能会有类似的机会。 查看[软件即服务](http://highscalability.com/tags/saas)，了解更多想法。 +4. **保持简单！** 简单性使您可以更快地重新构造，以便可以对问题进行响应。 确实没有人真正知道简单性是什么，但是如果您不害怕进行更改，那么这表明简单性正在发生。 +5. **分片**。 分片有助于隔离和限制存储，CPU，内存和 IO。 这不仅仅是要获得更多的写入性能。 +6. **瓶颈上的不断迭代**： + -软件：数据库，缓存 + -操作系统：磁盘 I / O + -硬件：内存，RAID +7. **您作为一个团队**成功。 拥有一支优秀的跨学科团队，了解整个系统以及系统的底层内容。 可以设置打印机，机器，安装网络等的人员。 一个好的团队，一切皆有可能。 -* Google 与其他公司之间的关键区别在于，当他们在 2011 年启动 Google Brain 项目时， **并未将他们的研究留在象牙塔** 。 项目团队与 Android，Gmail 和照片等其他团队密切合作，以实际改善这些属性并解决难题。 对于每个公司来说，这都是难得的，也是一个很好的教训。 **通过与您的员工合作进行研究** 。 +[在[reduce]](http://www.reddit.com/r/programming/comments/2yfab3/the_youtube_architecture_2008/) 上。 -* 这个想法很有效：他们了解到他们可以采用一整套子系统，其中一些子系统可能是机器学习的， **则将其替换为更通用的端到端 终端机器学习资料** 。 通常，当您有很多复杂的子系统时，通常会有很多复杂的代码将它们缝合在一起。 如果您可以用数据和非常简单的算法替换所有内容，那就太好了。 +很棒的文章。 -* **机器学习只会变得更好，更快。** 。 杰夫的一句话：机器学习社区的发展确实非常快。 人们发表了一篇论文，并且在一周之内，全世界许多研究小组下载了该论文，阅读，进行了剖析，对其进行了理解，对其进行了一些扩展，并在 [上发布了自己的扩展。 arXiv.org](http://arxiv.org/) 。 它与计算机科学的许多其他部分不同，在其他方面，人们将提交论文，六个月后，一个会议将决定是否接受该论文，然后在三个月后的会议中发表。 到那时已经一年了。 将时间从一年缩短到一周，真是太神奇了。 +非常感谢。 -* **可以魔术方式组合技术** 。 翻译团队使用计算机视觉编写了可识别取景器中文本的应用程序。 它翻译文本，然后将翻译后的文本叠加在图像本身上。 另一个示例是编写图像标题。 它将图像识别与序列到序列神经网络相结合。 您只能想象将来所有这些模块化组件将如何组合在一起。 +Dimitry。 -* **具有令人印象深刻的功能的模型在智能手机** 上足够小。 为了使技术消失，情报必须走到最前沿。 它不能依赖于连接到远程云大脑的网络脐带。 由于 TensorFlow 模型可以在手机上运行，​​因此这可能是可能的。 +真正的目的是跳过两行：将受欢迎的内容保留在 CDN 上。 换句话说，向 Akamai 扔钱，让 Akamai 担心。 -* 如果您不考虑如何使用深度神经网络解决您的数据理解问题， **几乎可以肯定是** 。 这条线直接来自谈话，但是在您使用深层神经网络解决了棘手的问题之后，观察到棘手的问题后，事实就很清楚了。 +当然，这是正确的答案，但是无论您使用的是 Python 还是无关紧要的。 如果没有 Akamai 的服务，鉴于上述基础架构，YouTube 将永远无法满足需求。 -Jeff 总是进行精彩的演讲，这一演讲也不例外。 它简单，有趣，深入并且相对容易理解。 如果您想了解深度学习知识，或者只是想了解 Google 在做什么，那么必须要看的是 。 +*-以信用卡为生，因此可以租用硬件。 当他们需要更多硬件来处理负载时，花了几天时间订购并交付。* -谈话内容不多。 它已经包装好了。 因此，我不确定本文将为您带来多少价值。 因此，如果您只想观看视频，我会理解的。 +这到底是如何工作的？ 当我们调查这个问题时，发现由于我们是一家新成立的初创公司，我们没有信誉（我想没有“发现”的意思，这很明显），因此硬件租赁公司只有在我们中一个人亲自支持贷款的情况下才会向我们出租。 。 鉴于启动风险高且费用高昂，我们最终购买了硬件并将其安装在各种低端 APR CC 等产品上。所有大型硬件供应商都表示“除非我们能看到您最近 N 年 纳税申报表等，我们不会向您出租。” 使得租赁似乎不是“靠信用卡生存”创业公司的真正选择。 -与 Google 对话一样，您会感到我们只被邀请到 Willy Wonka 的巧克力工厂的大厅里。 我们面前是一扇锁着的门，我们没有被邀请进来。那扇门之外的东西一定充满了奇迹。 但是，就连威利旺卡（Willy Wonka）的大厅也很有趣。 +哇，那是一篇很棒的文章，没想到 CDN：P -因此，让我们了解杰夫对未来的看法……这很有趣... +一定要接受红杉资本的私人风险投资，红杉资本也是 Google 的最大股东，并控制着其董事会。 红杉资本利用其影响力迫使 Google 大量为 Youtube 多付钱，红杉资本合作伙伴立即获利 5 亿美元。 -## 理解意味着什么？ +这篇文章和视频对我正在从事的一些项目非常有希望。 谢谢！ -* 当向人们展示街道场景时，他们可以毫无疑问地从场景中挑选文字，了解到一家商店出售纪念品，一家商店的价格确实很低，依此类推。 直到最近，计算机还无法从图像中提取此信息。 +完全令人惊叹; 100％值得一读。 -![](img/d9c5bdf722db9f4061822228edcff450.png) +哇，真疯狂。 -* 如果您真的想从图像中了解物理世界，则计算机需要能够挑选出有趣的信息，阅读并理解它们。 +一篇很好的文章，但我还没有学到任何新知识。 当前的 YouTube 体系结构已被应用于我们的类似 youtube 用户的罗马尼亚网站之一，该网站称为 [http://www.trilulilu.ro/](http://www.trilulilu.ro/) 。 我们的客户尚未实现的唯一一件事就是数据库分片，现在不需要了，因为 MySQL 数据库总数不到 250MB，而 MySQL 服务器处理的速度至少为 650 qps。 -* 小型移动设备在当今和将来都主导着计算机交互。 这些设备需要不同类型的接口。 您需要真正能够理解并产生语音。 +那是一篇很棒的文章。 -* 进行查询：[待售汽车零件]。 旧版 Google 会匹配第一个结果，因为关键字匹配，但是比较匹配的是第二个文档。 真正了解查询的含义是深层次而不是肤浅的单词层次，这是您构建良好的搜索和语言理解产品所需要的。 +我认为有趣的是，他们使用了 mod_fastcgi。 我的意思是，我之所以使用它，是因为我被迫使用共享主机，但是在尝试进行大规模扩展时，我总是听说过很多问题（即使那是它的设计目标）。 我想，如果做得对，FastCGI 对于服务器场可能是一笔宝贵的财富。 -![](img/0ad48db760cd6b9f0ffb6dacb5986958.png) +这是一篇很棒的文章，非常有趣！ -## Google 的深度神经网络简史 +很想听听更多这样的故事，例如 Flickr，Twitter，MySpace，Meebo ...客户仍然被大型企业参与者洗脑，认为他们需要 BEA Portal Server 或类似的东西来实现强大，可扩展的企业解决方案。 要说服他们不要将钱花在昂贵的事情上，要花费大量时间来部署和花费巨额财富（并且要花费大量时间）以使其从用户体验的角度来做自己想做的事情，这是一场战斗。 我一直在说：“ MySpace 每天注册 350,000 个用户，他们没有使用 Aqualogic-让我们为一些杀手级的 AJAX UI，小部件和一个实际上有用的 API 节省额外的现金。 -* [Google Brain 项目](https://en.wikipedia.org/wiki/Google_Brain) 于 2011 年启动，致力于真正推动神经网络技术的发展。 +您靠个人信用卡为生，这是正确的...肯定也可以追溯到早期的 YouTube ... -* 神经网络已经存在很长时间了。 它们在 60 年代和 70 年代发明，并在 80 年代末和 90 年代初流行，但它们逐渐消失了。 两个问题：1）缺乏训练大型模型所需的计算能力，这意味着无法将神经网络应用于较大的有趣数据集上的较大问题。 2）缺少大量有趣的数据集。 +谢谢你的好文章 -* 仅与 Google 的几个产品组合作。 随着时间的推移，随着小组发布的好消息或解决了以前无法解决的问题的消息，周围的消息传开了，越来越多的团队会去帮助他们解决问题。 +在 LAMP（Linux，Apache，MySQL，PHP）上组织 [http://anton.shevchuk.name/php/php-cookbook-myphptubecom/']( 派上用场的地方。 + +> Helm 网站的*：Helm 帮助您管理 Kubernetes 应用程序-Helm Charts 帮助您定义，安装和升级最复杂的 Kubernetes 应用程序。* + +Helm 将自己定位为 Kubernetes 的程序包管理器，但我最初只是将其用于模板功能。 现在，我也开始欣赏它的软件包管理器方面，并用它来安装 Grafana [ [2](#_footnotedef_2 "View footnote.") ] 和 Prometheus [ [3](#_footnotedef_3 "View footnote.") ] 。 + +经过一番汗水和几滴眼泪，我们的基础架构现在被整齐地组织为 1 个 Helm 程序包，17 个部署，9 个 ConfigMap，5 个 PersistentVolumeClaims，5 个秘密，18 个服务，1 个 StatefulSet，2 个 StorageClasses，22 个容器映像。 + +剩下的就是迁移到这个新的基础架构并关闭所有硬件服务器。 + +### 正式迁移 + +2017 年 10 月 5 日是夜晚。 + +扣动扳机非常容易，而且顺利进行。 + +我创建了一个新的 GKE 集群，运行`helm install betabrand --name production`，将我们的 MySQL 数据库导入到 Google Cloud SQL 中，然后，实际上花费了大约 2 个小时，我们才生活在 Clouds 中。 + +迁移很简单，就是。 + +当然，最有用的是在 Google GKE 中创建多个集群的能力：在迁移产品之前，我能够通过多次测试迁移进行排练，记下成功启动所需的每个步骤。 + +Betabrand 的黑色星期五 2017 年非常成功，我们遇到的一些技术问题与迁移无关。 + +### 开发/分期环境 + +我们的开发机器通过 Minikube [ [4](#_footnotedef_4 "View footnote.") ] 运行 Kubernetes 集群。 + +相同的 YAML 清单用于创建本地开发环境或“类似生产”的环境。 + +在生产环境中运行的所有内容，也在开发环境中运行。 两种环境之间的唯一区别是，我们的开发环境与本地 MySQL 数据库对话，而生产与 Google Cloud SQL 对话。 + +创建登台环境与创建新的生产集群完全相同：所需要做的只是克隆生产数据库实例（只需单击几下或一个命令行），然后通过`--set database`将登台集群指向该数据库。 `helm`中的]参数。 + +### 一年后 + +从我们将基础架构移至 Kubernetes 至今已经一年零两个月了，我再也高兴不起来了。 + +Kubernetes 在生产中一直坚如磐石，我们还没有遇到过停机的情况。 + +预计 2018 年黑色星期五将有大量流量，我们能够在几分钟内创建生产服务的精确副本并进行大量负载测试。 这些负载测试显示特定的代码路径性能非常差，只能显示大量流量，因此我们可以在黑色星期五之前修复它们。 + +不出所料，2018 年黑色星期五给 Betabrand.com 带来了前所未有的流量，但是 k8s 兑现了承诺，而 Horizo​​ntalPodAutoscaler 与 GKE 的节点自动缩放相结合的功能使我们的网站能够毫无问题地吸收峰值负载。 + +K8 与 GKE 相结合，为我们提供了使我们的基础架构可靠，可用，可伸缩和可维护所需的工具。 + +* * * + +[1](#_footnoteref_1). [https://helm.sh/](https://helm.sh/)[2](#_footnoteref_2). [https://grafana.com/](https://grafana.com/)[3](#_footnoteref_3). [https://prometheus.io/](https://prometheus.io/)[4](#_footnoteref_4). [https://github.com/kubernetes/minikube](https://github.com/kubernetes/minikube) + +雨果，好帖子！ 真的很脆，没有花哨/不必要的术语。 + +我很好奇看到您每月帐单的比较-OVH 裸机与 GCP K8S + +I too am curious to see a comparison of your monthly bill - OVH bare-metall vs GCP K8S...😉 + +您认为这对这家公司来说太过分了吗？ 我一直都很喜欢 Kube，不是因为业务需要它，而是因为人们喜欢高科技。 IDK，只是想一想 + +为什么不使用不同的名称空间进行测试和暂存，而不是创建不同的集群？ \ No newline at end of file diff --git a/docs/245.md b/docs/245.md index 09919f4..87cbcbb 100644 --- a/docs/245.md +++ b/docs/245.md @@ -1,33 +1,819 @@ -# mixi.jp 体系结构 +# Egnyte Architecture：构建和扩展多 PB 内容平台的经验教训 -> 原文： [http://highscalability.com/blog/2007/7/10/mixijp-architecture.html](http://highscalability.com/blog/2007/7/10/mixijp-architecture.html) +> 原文： [http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html) -Mixi 是日本快速发展的社交网站。 他们提供的服务包括：日记，社区，消息，评论和相册。 与 LiveJournal 有很多共同之处，他们还开发了许多相同的方法。 他们撰写有关如何扩展系统的文章很容易成为目前最好的之一。 +![](img/cd669c781d6a9a0f1fd802de7a2578a4.png) -网站：http：//mixi.jp +这是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的来宾帖子，工程师是为 [Egnyte](https://www.egnyte.com/) 在家工作的。 Egnyte 是专门为企业构建的安全内容平台。 他和他的同事们花费大量的时间来扩展大型分布式文件系统。 您可以通过 [@kpatelwork](https://twitter.com/kpatelwork) 与他联系。 -## 信息来源 +## 简介 -* [mixi.jp](http://www.scribd.com/doc/2684187/mixi-jp-scaling-out-with-open-source) -使用开源 +您的笔记本电脑有一个文件系统，该文件系统被数百个进程使用。 但是，如果您希望使用它来支持数以万计的用户在处理同时包含 PB 级数据的数亿个文件时有一些缺点。 它受磁盘空间的限制； 它无法弹性扩展存储空间； 如果您运行一些 I / O 密集型进程或尝试与 100 个其他用户进行协作，就会感到窒息。 让我们来解决这个问题，并将其转换为遍布全球的数百万付费用户使用的云原生文件系统，您将了解我们过山车的规模，可以扩展该系统以满足每月的增长和 SLA 要求，同时提供严格的一致性和 我们都期望笔记本电脑具有出色的耐用性。 - ## 平台 +Egnyte 是一个安全的内容协作和数据治理平台，成立于 2007 年，当时 Google 硬盘还没有诞生，而 AWS S3 却禁止了成本。 我们唯一的选择是袖手旁观，自己构建基本的云文件系统组件，例如对象存储。 随着时间的推移，S3 和 GCS 的成本变得合理，并且借助 Egnyte 的存储插件架构，我们的客户现在可以引入他们选择的任何存储后端。 为了帮助我们的客户管理持续的数据爆炸，我们在过去几年中设计了许多核心组件。 在本文中，我将分享当前的体系结构以及我们所学到的扩展它的一些经验教训，以及我们希望在不久的将来进行改进的一些内容。 - 进行横向扩展* 的 Linux* 阿帕奇* 的 MySQL* 佩尔* 记忆快取* 乌贼* Shard +## Egnyte Connect 平台 - ## 里面有什么？ +Egnyte Connect 平台使用 3 个数据中心来满足来自全球数百万用户的请求。 为了增加弹性，可靠性和耐用性，这些数据中心使用高速，安全的 Google 互连网络连接到 Google Cloud 平台。 - * 他们在两年内增长到大约 400 万用户，每天增加 15,000 多新用户。* Alexa 排名第 35 位，日本排名第 3 位。* 超过 100 台 MySQL 服务器* 每月添加 10 台以上的服务器* 使用非持久连接。* 日记流量为 85％的读取和 15％的写入。* 消息流量是 75％的读取和 25％的写入。* 遇到复制性能问题，因此他们不得不拆分数据库。* 考虑按用户垂直拆分或按表类型水平拆分。* 最终按表类型和用户进行分区。 因此，一组用户的所有消息都将分配给特定的数据库。 分区键用于确定应在其中存储数据库数据。* 为了进行缓存，他们使用具有 39 台机器 x 2 GB 内存的 memcached。* 存储超过 8 TB 的图像，每天添加约 23 GB。* MySQL 仅用于存储有关图像的元数据，而不用于存储图像本身。* 图像要么经常访问，要么很少访问。* 使用 Squid 将经常访问的图像缓存在多台计算机上。* 很少访问的图像从文件系统提供。 缓存它们没有任何好处。 +![](img/b34c983ca54495f680a9dadebfa8f2a4.png) - ## 得到教训 +Egnyte Connect 运行一个服务网格，该网格从我们自己的数据中心延伸到提供多种服务类别的 Google 云： - * 使用动态分区时，很难选择密钥和算法来存储数据。 +### 合作 - * 对数据进行分区后，就无法再进行联接，并且必须打开与不同数据库的大量连接才能将数据合并回去。 +* 文档存储区 - * 分区时很难添加新主机并重新排列数据。 例如，假设您的分区算法在主机 1 上存储了用户 1-N 的所有消息。现在，假设主机 1 负担过重，并且您想在更多主机上重新划分用户。 这很难做到。 +* 预览版 - * 通过使用分布式内存缓存，它们很少访问数据库，平均页面加载时间约为.02 秒。 这减少了与分区相关的问题。 +* 视频转码 - * 您将常常不得不根据内容类型来制定策略。 例如，图片将与短文字帖子区别对待。 +* 分享 - * 社交网站非常注重时间，因此按时间以及用户和类型对数据进行分区可能很有用。 \ No newline at end of file + * 链接 + + * 权限 + +* 标签 + +* 评论 + +* 任务 + +* 建议 + +### 混合同步 + +* 处理 Prem 数据时 + +* 大文件或低带宽 + +* 离线访问 + +* 边缘缓存 + +### 基础架构优化 + +* 迁移到云 + +* 优化保鲜库的成本 + +* 合并存储库 + +通常，Egnyte 连接架构分片并基于以下条件在不同级别缓存数据： + +* 数据量 + +* 数据相互依存 + +* 并发读取的级别 + +* 并发写入级别 + +![](img/f8913d2219c8cabf370072889c0b44fb.png) + +， + +## Egnyte Connect 技术堆栈 + +### 云平台 + +1. Google 云端 + +2. Azure + +3. 托管数据中心 + +### 语言： + +1. Java + +2. Python + +3. 转到 + +4. C + +### 对象存储区 + +* Egnyte 对象存储区 + +* GCS + +* S3 + +* Azure + +### 应用服务器 + +* Tomcat + +### 数据库 + +* MySQL + +* Redis + +* BigTable + +* 数据存储 + +* Elasticsearch + +### 缓存 + +* Memcached + +* Redis + +* Nginx 用于基于磁盘的缓存 + +### 负载平衡器/反向代理 + +* HAProxy + +* Nginx + +### 消息队列 + +* Google Pub / Sub + +* 兔子 + +* 抄写员 + +* Redis + +### 部署管理 + +* 人偶 + +* Docker + +* Ansible + +* 詹金斯 + +* Gitlab + +* 调速器 + +### 分析 + +* 新遗物 + +* OpenTSDB / bosun + +* Grafana + +* MixPanel + +* 表格 + +* BigQuery + +### 其他 + +* ZooKeeper + +* Nagios + +* Apache FTP 服务器 + +* 孔 + +* ReactJS / Backbone / Marionette / JQuery / npm / Nightwatch + +* Rsync + +* PowerDNS + +* 服装 + +* 基于 REST API 的 SOA 体系结构。 + +* Java 用于驱动核心文件系统代码 + +* 用于支持客户端代码，某些微服务，迁移脚本，内部脚本的 Python + +* 原生 Android 和 iOS 应用 + +* 本机桌面和服务器托管的客户端，允许对整个名称空间进行交互以及混合同步访问 + +## 统计信息 + +* 3 个主要地区（其中一个在欧洲）使用 Google 互连连接到相应的 GCP 地区 + +* 500 多个 Tomcat 服务 实例 + +* 由 Tomcat / Nginx 提供支持的 500 多个存储节点 + +* 100 多个 MySQL 节点 + +* 100 多个 Elasticsearch 节点 + +* 50 多个文本提取 实例 （自动缩放） + +* 100 多个 HAProxy 实例 + +* 许多其他类型的服务 实例 + +* 存储在我们服务器和其他对象存储区（例如 GCS，S3 和 Azure Blobstore）中的数十 PB 数据 + +* 在 Elasticsearch 中建立索引的多个 TB 提取内容 + +* 数百万个桌面客户端与云同步文件以进行脱机访问 + +* 数百万台式客户端以交互方式访问文件 + +## 认识您 + +### 您的系统名称是什么，我们在哪里可以找到更多信息？ + +Egnyte Connect 是内容协作和数据管理平台。 CFS（云文件系统），EOS（Egnyte 对象存储），内容安全性，事件同步，搜索服务，基于用户行为的推荐服务构成了系统的主要部分。 您可以在我们博客的 [对于技术人员](https://www.egnyte.com/blog/category/for-the-techies/) 部分中找到更多相关信息。 + +### 您的系统使用什么功能？ + +作为内容协作和数据管理平台的 Egnyte Connect 被成千上万的客户用作唯一的 安全内容平台来满足他们的所有文档管理需求。 它是为承载各种文件服务 并为它们的现有文件存储库启用云而构建的。 可以从各种端点（例如 FTP，WebDAV，移动，公共 API 和浏览器）访问它，并具有强大的审核和安全组件。 + +### 您为什么决定构建此系统？ + +在 2007 年，企业开始变得更加分散。 客户正在使用多种设备来访问他们的文件，因此需要使这种体验尽可能地顺畅。 我们构建了 Egnyte Connect-一种安全的分布式文件系统，该系统将 Hybrid Sync 与 Cloud File System 相结合，可以满足各种业务需求中企业的内容协作需求。 随着本地和云存储库中数据的分散，以及由于 GDPR 等举措而增加的合规性需求，我们构建了 Egnyte Protect 来帮助客户满足其合规性和治理需求。 + +### 您的项目经费如何？ + +Egnyte 最初是一家自举公司。 后来，我们继续从高盛，Google Ventures，KPCB，Polaris Partners 和 Seagate 的多轮融资中筹集了 1.375 亿美元的 [](https://www.crunchbase.com/organization/egnyte#/entity)。 + +### 您的收入模式是什么？ + +Egnyte 不提供免费帐户。 客户从 15 天的免费评估试用期开始，之后，他们将根据席位数量，存储空间和其他企业功能转换为带有收入模型的付费帐户。 + +### 您如何销售产品？ + +我们从 SEM / SEO 开始，但随着时间的增长，我们使用了许多渠道来为社会客户，社交媒体，商务开发，贸易展览，SEM，SEO，入站营销和企业级客户进行高接触销售。 + +### 您从事这项工作多久了？ + +Egnyte 成立于 2007 年。它已有 12 年的历史，现金流量为正。 + +### 您的系统多大？ 尝试感受一下系统的工作量。 + +我们存储数十亿个文件和数十 PB 的数据。 在“ Egnyte connect”中，根据 New Relic，我们平均观察到平均每秒超过 10K API 请求，平均响应时间为< 60ms。 由于安全港规定和位置相近，我们允许从 3 个主要地区访问。 有关更多信息，请参见统计信息部分。 我们的“ Egnyte Protect”解决方案还持续监控内容和对许多客户的合规性，治理和安全漏洞的访问。 + +### 您提供多少份文件？ 多少张图片？ 多少数据？ + +我们存储数十亿个文件和数十 PB 的数据。 我们存储各种文件。 Egnyte 存储的前 5 个文件扩展名是 pdf，doc / docx，xl​​s / xlsx，jpeg 和 png。 + +### 免费用户与付费用户的比例是多少？ + +我们所有的用户均为付费用户。 我们提供 15 天的免费试用期，然后将其转换为付费帐户。 + +### 在过去一个月中有多少个帐户处于活动状态？ + +我们所有的客户都是付费帐户，并且每个月几乎所有人都活跃。 我们满足他们安全的内容平台需求，谁在家不用电？ + +## 您的系统如何设计？ + +### 您的系统的体系结构是什么？ + +我们使用基于 REST 的面向服务的体系结构，它使我们能够独立扩展每个服务。 这也使我们能够将某些后端服务移至公共云中托管。 所有服务都是无状态的，并使用数据库或我们自己的对象存储进行存储。 + +10000 英尺的 Egnyte Connect 服务概述如下所示。 + +![](img/3d5e6054b4bacef5d0f2733fb962651b.png) + +[典型请求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的 10000 英尺总览如下 + +![](img/19d4979dbb2079dbc0eac2371a21067a.png) + +约 10000 英尺的 [搜索架构](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下 + +![](img/c015db1edce1869cc6373704f2683bb5.png) + +### 您的系统面临哪些特定的设计/架构/实施挑战？ + +最大的 架构 挑战包括： + +1. 节俭地扩展文件存储 + +2. 扩展元数据访问 + +3. 文件与桌面客户端的实时同步 + +4. 带宽优化 + +5. 冲击隔离 + +6. 缓存（分布式和内存中） + +7. 功能首次展示 + +### 您是如何应对这些挑战的？ + +1. 对于存储，我们编写了自己的存储，现在我们使用可插拔的存储体系结构来存储到任何公共云，例如 S3，GCS，Azure ... + +2. 为了扩展元数据，我们移至 Mysql 并开始使用分片。 在某个时候，我们暂时投入了更多的硬件来腾出空间，以便一层一层地剥去“鳞屑洋葱”。 + +3. 对于实时同步，我们必须更改同步算法，使其更像 Git，客户端接收增量事件并尝试与云状态进行最终的一致同步。 + +4. 为了推出功能，我们构建了一个自定义设置服务，允许工程师在功能标志后面编写代码。 这样，即使在睡眠者模式下，您也可以释放代码并收集数据，然后按客户，用户或主机组或 POD 或数据中心启用功能。 有了这种控制水平，即使是新工程师也可以放心地在功能标记后面编写代码并将其发布到生产环境中，而不必担心停机时间。 + +5. 监视，监视和监视。 您无法优化无法衡量的内容。 不利的一面是，在某些时候，我们监控得太多了，以致于我们无法专注于所有指标。 我们必须转移注意力，并依靠诸如 New Relic，bosun，ELK，OpenTSDB 和自定义报告之类的异常检测工具，使我们能够专注于从绿色->黄色->红色趋势发展的问题。 目的是在客户通知 之前，将它们捕获为黄色并且 [时捕获它们。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) + +### 您的系统如何发展以应对新的扩展挑战？ + +我们已经多次重新构造了许多层。 我将尝试列出过去 7 年中核心元数据，存储，搜索层的一些迭代。 + +1. 版本 1：在 Lucene 中搜索 Lucene 中的文件元数据，通过 NFS 安装在 DRBD Filer 中存储的文件。 关键点： Lucene 更新不是实时的，必须替换。 + +2. 版本 2：Berkeley DB 中的文件元数据，通过 NFS 挂载的 DRBD Filers 中存储的文件，在 Lucene 中搜索。 关键点： 我们打破了 NFS 的限制，它左右 and 住，必须用 HTTP 代替。 + +3. 版本 3：Berkeley DB 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 Lucene 中搜索。 关键点 ：即使分片的 Berkeley DB 在压力下也令人窒息，并且由于恢复需要数小时而导致数据库崩溃，因此必须更换它。 + +4. 版本 4：MySQL 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 Lucene 中搜索。 关键点： 公共云开始变得便宜。 + +5. 版本 5：MySQL 中的文件元数据，存储在 EOS / GCS / S3 / Azure 中并通过 HTTP 提供的文件，在 Lucene 中搜索。 阻塞点： 搜索开始阻塞，必须替换。 + +6. 版本 6：MySQL 中的文件元数据，通过 HTTP 服务的 EOS / GCS / S3 / Azure 中存储的文件，在 Elasticsearch 中搜索。 这是当前的体系结构。 + +7. 版本 7（未来）：将所有计算移至公共云，提供更多服务以实现影响隔离，动态资源池以有效管理宠物和牛。 + +### 您是否使用任何特别酷的技术或算法？ + +* 我们在核心服务和服务之间进行呼叫时使用指数补偿，以使用断路器来避免打雷。 + +* 我们使用核心服务节点资源上的公平份额分配来处理传入请求。 核心服务节点上的每个传入请求都被标记并分为各种组。 每个组都有专用的容量，如果一个客户每秒发出 1000 个请求，而另一个客户每秒发出 10 个请求，则此系统将确保其他客户不会因为邻居吵闹而挨饿。 诀窍是，如果您是目前使用该系统的唯一客户，则可以全力以赴，但是随着更多客户同时出现，您可以在其中共享容量。 对于某些大型客户，我们会分配专用池以确保一致的响应时间。 + +* 带有 SLA 的某些核心服务被隔离在 POD 中，这确保了一个不好的客户不会阻塞整个数据中心，但是这可能很快就需要轮回。 + +* 我们在桌面同步客户端代码中使用基于事件的同步，因为发生服务器事件时，它们会从服务器推送到客户端，并且客户端会在本地重播它们。 + +* 我们采用大规模数据过滤算法，以使大型客户端集群与 Cloud File System 同步。 + +* 我们根据问题陈述使用不同类型的缓存技术。 很少有以下口味： + + * 传统 + + * 内存中的-简单的 + + * 不可变的对象 + + * 内存中的大型数据集 + + * 用于在各个进程之间实现高度一致性的锁 + + * 已实施部分更新，以避免出现 GC + + * 内存中-高容量变异数据集 + + * 粗粒度无效 + + * 细粒度无效 + + * 基于磁盘的缓存 + +### 您做什么工作是与众不同的，人们可以从中学到什么？ + +专注于启动的核心功能，如果您遇到技术难题，就必须为其构建自定义内容，然后卷起袖子继续前进。 有很多独特的东西，但是基于事件的同步存储层绝对值得学习，这里有更多详细信息。 [Egnyte 对象存储库](https://www.egnyte.com/blog/2013/07/how-egnyte-implements-hybrid-object-stores-using-public-clouds-to-enhance-customer-experience/) 和 Egnyte [规范文件系统](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 + +### 您学到了什么？ + +* 您无法优化您无法测量的内容：测量所有可能且相关的内容，然后首先优化 80％处于使用状态的系统部分。 + +* 当您身材矮小的时候，请慢慢介绍技术，不要试图从中找到解决当前问题的理想工具。 编码是生命周期中最简单的部分，但是如果您拥有太多的技术，则其维护（如部署/操作/学习曲线）将非常困难。 随着您变得更大，您的部署中将有足够的脂肪来逐步进行服务划分。 学习保留一个或两个服务模板来实现微服务，不要为每个服务使用不同的技术堆栈。 + +* 作为初创企业，有时您必须快速行动。 介绍您现在可以做的最好的解决方案，如果发现有牵引力，请随着时间的推移重新设计该解决方案。 您可以尝试 10 种不同的方法，而只有 1 种方法可以看到牵引力，因此请快速进行一些操作，然后在看到牵引力的方法上重新架构，以适应业务规模。 + +* 寻找单点故障，并不懈地追查它们。 付出额外的努力来解决使您彻夜难眠的问题，并尽快从防御性转变为进攻性模式。 + +* 在 SOA 中，构建断路器以尽早减轻负载，如果服务受阻，则开始发送 503s。 与其惩罚所有人，不如看看您是否可以公平分配资源并仅惩罚滥用请求。 + +* 在服务使用者中添加了自动修复功能，服务可能会停止运行，并且像台式机客户端或其他服务这样的使用者可以进行指数补偿以释放服务器上的压力，并在服务再次起作用时自动修复。 + +* 始终可用：请客户提供服务级别的断路器和断路器。 例如，如果通过 WebDAV 或 FTP 访问文件系统存在性能问题，并且需要 4 个小时来修复，那么在这 4 个小时内，您可以在 kong / firewall 杀死 FTP / WebDAV 并要求客户使用 Web UI 或其他 工作机制。 同样，如果一个客户造成了导致系统阻塞的异常，则可以暂时为该客户禁用该客户或服务，并在解决问题后重新启用它。 为此，我们使用功能标志和断路器。 + +* 对于高度可扩展的服务，离开 Java 进程的成本很高，即使去了 Memcache 或 Redis 也是如此，因此我们对某些高度使用的数据结构（如访问控制计算，功能标志，路由元数据等）进行了具有不同 TTL 的内存中缓存。 。 + +* 我们看到一种有关处理大数据集的模式。 优化代码并挤走柠檬中的每一滴都是徒劳的，我们最终可能会使代码变得复杂且柠檬水苦涩。 通常，最简单的解决方案来自返回到绘图板，看看我们是否可以： + + * 通过使用启发式方法来减少我们需要处理的数据集大小 + + * 重组了我们在内存或磁盘中存储数据的方式。 + + * 在写时对数据进行规范化，并避免联接。 + + * 基于时间的过滤，例如存档较早的数据。 + + * 在多租户数据结构中创建较小的碎片。 + + * 使用事件更新缓存数据集，而不是完全重新加载。 + +* 保持简单：每个月都有新工程师加入，因此目标是从第一周开始就提高他们的工作效率-简单的架构可确保轻松上岗。 + +### 您为什么成功？ + +牵引力胜过一切。 当 EFSS 市场刚刚爆发时，我们达到了产品/市场契合度。 良好的执行力，以客户为中心，管理团队遵守财务纪律的时机可以成功。 许多竞争者采用了免费增值模式并筹集了一大笔资金，但是从第一天开始我们就开始收费，这使我们能够专注于随着市场需求的扩大而发展解决方案/团队。 专注于付费客户使我们能够提供企业级解决方案，而无需支付免费增值罚金。 + +### 您希望自己做些什么？ + +我希望当我们开始时，公共云不会像成本那样高。 我也希望我们从第一天开始就使用 SOA，花了一些时间才到达那里，但是现在我们就在那里。 + +### 您不会更改什么？ + +体系结构应具有延展性。 四年前，对于给定的问题，我有不同的答案，但是目前，我不确定。 我的意思是，随着您规模的扩大，过去 2 年前有效的设计模式和策略可能使您从防御性定位转向进攻性定位可能会在压力下屈服或变得成本过高。 只要更改将使系统变得有弹性或带来 10 倍的更改并为我们再购买 3-4 年的规模，我便会继续尝试更改它。 我不能在两年后发表评论，我会有同样的想法，他们可能会改变。 当您遇到下一个增长突增时，架构会发生变化。 + +### 您应该做多少前期设计？ + +很好的问题。 答案是“取决于”， + +* 如果您要设计核心存储层或核心元数据层之类的东西，那么再多花 2 周的时间就不会有多大伤害。 当我们在核心元数据层上从 Berkeley DB 迁移到 MySQL 时，我承受着很大的压力，我想到了一条捷径，当我通过我们的 CTO 运行它时，他建议花一些时间，“做正确的事情”。 ”作为回顾，这是一个极好的决定。 + +* 对于公共 API，最好做一个不错的前端设计，因为您没有第二次机会对其进行更改，并且必须在未来 4-5 年内进行维护。 + +* 如果要处理其 PB 级数据并带来巨大麻烦，那么我将再给它一个月的时间并进行更多的 POC。 + +* 但是，如果您要为内部服务设计一些东西并将其迁移到新的体系结构不会花费一年的时间，那么我建议您进行非常少的前端设计，并且只需快速构建版本并随着使用量的增长对其进行迭代 。 + +### 您如何考虑将来更改架构？ + +* 从静态 POD 转移到动态 POD，并无缝处理宠物和牛。 + +* 提供更具弹性的服务并隔离影响。 + +* 将我们的整个计算移至公共云，同时保留数据中心用于提供文件。 这将使我们能够在负载到来时自动放大/缩小。 我们已经使用公共云来自动扩展一些异步处理，例如视频转码，文本提取，数据迁移，搜索等。 + +* 一旦进入云，请使用更多自动缩放服务，例如 BigTable，PubSub，Spanner 等。 + +* 将我们的部署从 VM 迁移到 Kubernetes 中的容器，以提供挂起的服务。 + +* 自动化剩余数据库的架构管理 + +* 通过重新构建从某些增长最快的表中删除联接。 + +* 重写元数据的缓存层，并使用 Redis 数据结构代替 Memcache。 + +* 将频繁使用的流从强一致性转换为最终一致性。 + +## 您的团队如何设置？ + +### 您的团队中有多少人？ + +大约 700 名员工和承包商。 有 200 名工程师（DevOps / OPS / QA / Developers /…），其余为销售，市场营销，支持，产品管理，人力资源等。 + +### 他们在哪里？ + +最初是一支分布相当分散的工程团队，但现在主要吸引了印度波兰山景城的人。 一些像我这样的远程员工 和其他一些员工在家工作。 + +### 谁扮演什么角色？ + +这是一个很大的团队，我们有产品经理，UX 团队，DevOps，Scrum 团队，架构师，工程师扮演各种角色。 最初，工程团队很平坦，每个人都会向工程副总裁报告，但现在我们在两者之间增加了一层管理。 + +### 您是否有特定的管理理念？ + +如果您开发某些产品，那么您便拥有该产品的生命周期，这意味着您将与质量保证，DevOps 一起使用，以确保产品经过测试/部署。 投入生产时，您可以使用各种内部工具（例如 New Relic / Grafana，Kibana）对其进行监视，如果存在回归，则可以对其进行修复。 我也是 1 人 1 任务理念的忠实拥护者，通过这种方式，如果工程师遇到障碍，他将找到某种最终克服它的方法，而不必太早放弃。 + +### 如果您有分散的团队，该如何工作？ + +自治，1-1 交流给他们带来挑战性的问题，亲自照顾和直接挑战，他们会受到激励。 + +### 您的开发环境是什么？ + +* 适用于服务器团队的 Ubuntu + +* UI 团队使用 Windows / mac 并连接到用于 REST API 服务器的本地 Ubuntu VM 或连接到共享的 QA 实例 + +* Eclipse /想法 + +* 适用于构建的 + +* Maven + +* 码头工人 + +* Gitlab + +* Jenkins + +* 汇合 + +* JIRA + +* Google 办公套件 + +* 松弛 + +### 您的开发过程是什么？ + +我们使用 Scrum，并为云文件系统团队提供每周发布。 我们使用 git-flow 的变体，对于每个票证，我们克隆存储库，并对每个合并请求运行自动化测试。 合并请求必须经过 2 位工程师的批准，然后才能解决 JIRA 故障单。 解决后，我们的管道将接管工作，而票务将接下去的下一班火车。 下一版本的培训已通过自动化 REST API 测试和一些手动烟雾测试进行了验证。 + +我们吃了自己的狗粮，并且代码在发布前 2-3 天送达了 UAT（供所有员工使用），我们发现了自动化测试未发现的任何意外情况。 我们每个星期三进行生产部署， [每天监控新文物，并报告任何异常的异常报告](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 。 我们在一周中更改了部署，以实现工作与生活之间的平衡，并且通过这种方式，我们将让所有工程师可用，以防发布遇到问题。 + +如果这是一项长期运行的功能，则工程师通常会在功能标志后面进行工作，并在各个阶段以 sleeper 模式提交代码，因此，每周（而不是大爆炸）都要测试他的代码。 我们也以一次迁移 1 个客户并仅为该客户打开功能的方式处理大型迁移，我们的一些大型迁移已运行 3-4 个月。 + +### 您有什么可以做的不同还是感到惊讶？ + +许多工程师在家工作，令人惊讶的是，有了自主权，许多远程员工像总部员工一样富有生产力和积极性。 + +## 您使用什么基础架构？ + +### 您使用哪种语言来开发系统？ + +大多数使用 Java / Python 以及 Go / C 中的一些小服务 + +### 您有多少台服务器？ + +我们有约 3000 多个由人偶管理的实例。 + +* 500+ Tomcat service instances + +* 500+ Storage nodes powered by Tomcat/Nginx + +* 100+ MySQL nodes + +* 100+ Elasticsearch nodes + +* 50+ Text extraction instances(autoscaled) + +* 100+ HAProxy instances + +* 和许多其他类型的服务 实例 + +### 如何将功能分配给服务器？ + +我们使用面向服务的体系结构，并根据服务类型分配服务器。 一些顶级服务是： + +* 元数据 + +* 储存空间 + +* 对象服务 + +* Web UI + +* 索引 + +* 同步 + +* 搜索 + +* 审核 + +* 内容智能 + +* 实时事件传递 + +* 文本提取 + +* 集成 + +* 缩略图生成 + +* 防病毒软件 + +* 垃圾邮件 + +* 预览/缩略图 + +* Rsync + +* API 网关 + +* 结算 + +* FTP / SFTP + +* 等等。 + +![](img/3d5e6054b4bacef5d0f2733fb962651b.png) + +### 如何配置服务器？ + +大多数服务都是伪造的，并在 VM 上运行，我们仅针对 MySQL，Memcached 和存储节点等少数设备运行物理服务。 我们使用第三方根据模板来配置服务器，并将其放置在数据中心中，以供使用。 但是我们已经开始将一切迁移到公共云的工作，因此最终，一切都将在 Kubernetes 中运行。 然而，挑战在于如何在不停机的情况下如何在比赛中更换赛车发动机。 + +### 您使用什么操作系统？ + +CentOS7 + +### 您使用哪个 Web 服务器？ + +Nginx，HAproxy。 在一些旧的流程中使用了 Apache，但随着时间的流逝，它将被弃用。 + +### 您使用哪个数据库？ + +MySQL 和 Redis。 我们过去曾使用过其他数据库，例如 Berkeley DB，Lucene，Cassandra，但由于其对工程师/操作人员的熟悉程度和可扩展性，我们逐渐将所有数据库迁移到 MySQL。 有关更多信息，请参见 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 + +对于某些流，我们还使用 OpenTSDB，BigTable，Elasticsearch。 + +### 您是否使用反向代理？ + +是 Nginx 和 HAProxy + +### 您是否并置，使用网格服务，使用托管服务等？ + +我们并置，我们还使用公共云。 + +### 您的存储策略是什么？ + +我们首先创建自己的服务器，然后在机器中打包尽可能多的硬盘驱动器，我们过去将它们称为 DRBD Filers。 我们这样做是因为 AWS 成本过高。 我们已经对 [GlusterFS](https://www.gluster.org/) 进行了评估，但是当时它无法扩展以满足我们的需求，因此我们构建了自己的。 加班 S3 变得便宜了，GCS / Azure 诞生了，我们将存储层设计为可插入的，因此现在客户可以决定要使用哪个存储引擎（例如，Egnyte，S3，GCS，Azure 等）。 此时，我们在公共云中存储了 1 个 DR 副本，并与我们一起存储了 1 个副本，但是最终我们将使用我们的数据中心作为直通缓存，因为云中的计算便宜，但是带宽昂贵。 + +### 您如何增加产能？ + +我们已基于 Newrelic，Grafana 和其他统计数据提供了半自动化的容量规划工具，并根据观察监控报告中的关键指标并预定一些额外的容量，进行了定期的容量规划会议。 现在，某些服务已启用云服务，我们只是根据队列大小自动缩放它们。 + +### 您是否使用存储服务？ + +是 Egnyte，S3，GCS，Azure， + +### 您如何处理会话管理？ + +我们多次重写了体系结构，目前，99％的服务是无状态的。 仅服务 Web UI 服务使用会话，我们在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性会话，但最终，我的计划是使它也 使用 JWT 或类似方法实现无状态。 + +### 您的数据库是如何设计的？ 主从？ 碎片？ 其他？ + +我们对几乎所有具有自动故障转移功能的数据库都使用了 Master-Master 复制，但是某些严重变异的数据库的切换是手动完成的，我们遇到了一些问题，由于复制滞后，自动切换会导致应用程序数据不一致，我们 需要重新架构一些核心文件系统逻辑来解决此问题，我们最终将完成此工作。 下面是有关处理数据库升级的问题，详细回答了有关数据库体系结构的更多详细信息。 + +### 您如何处理负载平衡？ + +我们根据客户使用 DNS 访问系统的 IP 来对客户进行地理平衡，并在数据中心内使用 HAProxy 将其路由到其相应的 POD，在 POD 内部，又使用 HAProxy 对其进行路由 + +### 您使用哪个 Web 框架/ AJAX 库？ + +我们已经多次更改了 UI，这是一直在变化的一件事。 过去，我们不得不使用 ExtJS，YUI，JQuery，而不能使用其他东西。 最新的迭代基于 ReactJS / Redux 以及 Backbone / Marionette 上的一些旧代码。 + +### 您使用哪些实时消息传递框架？ + +我们使用 [大气](https://github.com/Atmosphere/atmosphere) ，但最终，我们将其替换为 NodeJS + +### 您使用哪个分布式作业管理系统？ + +为此，我们使用 Google Pubsub，RabbitMQ 和基于 Java / Python 的消费者服务。 + +### 您的网站是否有标准 API？ 如果是这样，您将如何实施？ + +我们的 API 分为 3 种类型：- + +1. 公共 API： 这是我们向第三方应用程序工程师和集成团队以及我们的移动应用程序公开的 API。 我们会按照适当的弃用工作流程来弃用/升级 API 签名，并且更改始终向后兼容。 我们使用 Mashery 作为网关，API 记录在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) + +2. 适用于我们客户的 API： 此 API 对我们客户而言是内部的，如果我们以外的人使用此 API，我们不保证向后兼容。 + +3. 服务之间的内部受保护的 API： 这是服务在我们的数据中心内部用于相互通信的 API，无法从外部防火墙调用。 + +### 您的对象和内容缓存策略是什么？ + +我们存储了 PB 级的数据，但无法缓存所有数据，但是如果客户在给定的 15 天时间内拥有 5000 万个文件，则他可能只使用其中的 100 万个。 我们有基于 tomcat / Nginx /本地文件系统的缓存文件管理器节点，它以 LRU 方式运行。 我们可以弹性地增加减少缓存文件服务器的数量。 我们最大的问题之一是上传速度，如何从世界任何地方尽可能快地将数据上传到 Egnyte，为此，我们构建了特殊的 Network pops，如果您好奇的话可以在上阅读有关更多内容的信息[ [为 Egnyte 客户加速数据访问](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) + +Memcached / Redis 用于缓存元数据，我们使用单独的 Memcached 池来缓存长期存在的静态数据和文件系统元数据。 核心文件系统元数据非常庞大，不适合当前的 Memcached 节点，并且会逐出最近使用的其他类型的数据。 为了防止这种情况，我们使用 3 种类型的池，应用程序代码决定在哪里查找哪种数据。 我们允许在文件系统 Memcached 缓存中逐出，并在其他种类的 Memcached 池中争取零逐出。 对于不同种类的数据，我们也使用不同的对象到期时间。 对于我们一些频繁使用的数据（例如客户信息或分片映射），即使每个请求都转到 Memcache，也会因某些请求（例如文件夹列表）而减慢速度，因此我们在每个 JVM 上对该数据进行内存内缓存，并刷新数据 基于自定义 TTL 或我们使用某种 pub-sub 机制刷新它。 + +缓存中的两个最大难题是权限和事件。 对于权限数据，我们已经多次重选了该层，最近我们编写了一个 TRIE 来有效地缓存该层。 + +对于事件，我们将其缓存在 Memcache 中，但是有可能在晚上为客户发布了约 10 万个事件，而在早上 9:00 AM 突然有 3 万个人打开了笔记本电脑，现在每个人都希望这些 10 万个事件 使他们的系统一致。 这是一个有趣的规模问题，因为这将需要您在短时间内（例如 15 分钟）处理 30B 事件，并且仅发送用户有权访问的事件。 由于事件是不可变的，我们将它们在 Memcache 中缓存了 12 个小时，但是即使它们从 Memcache 下载相同的事件那么多次也会导致网络问题。 最终，我们在短时间内将事件缓存在内存中，并且随着我们进行许多年轻一代的收集工作，还调整了这些节点上的 GC 设置。 与其他节点相比，我们还将这些节点放置在更快的网络上，但仍然没有解决这个问题:)。 + +### 您的客户端缓存策略是什么？ + +对于我们的 Web UI，我们使用 requireJS 和其他各种方式仅下载所需的模块。 我们的 Mobile 和 Desktop 客户端丰富使用本地文件系统作为缓存。 + +### 您使用哪些第三方服务来帮助您构建系统？ + +我们使用了一些 Google 服务，Azure，New Relic，Authy，MixPanel，Flurry，Tableau，但大多数核心组件都是由我们构建的。 + +## 您如何管理系统？ + +### 您如何检查全局可用性并模拟最终用户性能？ + +我们使用不同 AWS 区域中的节点来一致地测试带宽性能。 我们还使用内部 haproxy 报告来绘制客户观察到的上载/下载速度，并主动寻找它们，并使用网络弹出消息和其他策略来加速数据包。 + +![](img/6ffa16c86d1956a9ff0be037d6021022.png) + +### 您如何健康检查服务器和网络？ + +Nagios，Grafana 和 New Relic 以及一些内部主动异常分析被使用。 有关更多详细信息，请参见此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) + +### 如何绘制网络和服务器统计数据以及趋势图？ + +我们使用 Grafana，Kibana，Nagios 和 New Relic。 + +![](img/dedeb468380c2680e693cd8a5743a335.png) + +![](img/293ca1407b4f34397f578ec21c96afd2.png) + +### 您如何测试系统？ + +硒，Junit，鼻子，Nightwatch 和手动测试。 单元，功能，集成和性能测试的组合。 + +### 您如何分析效果？ + +New Relic 用于监视应用程序性能。 我们还使用本地框架生成了大量内部应用程序指标。 我们使用 Grafana / Nagios / Kibana，内部工具和其他工具来监视系统其他部分的性能。 有关更多详细信息，请参见此博客文章 [分布式系统中的调试性能问题](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) + +### 您如何处理安全性？ + +专门的安全团队在每个版本之前都会运行自动化的安全基准测试。 连续自动笔测试正在生产中运行。 我们还使用漏洞赏金计划，并与 whitehat 测试公司合作。 一些客户使用第三方进行自己的安全性测试。 + +## 您如何处理客户支持？ + +我们有专门的 24X7 分布式客户成功团队，我们使用 Zendesk 和 JIRA + +## 您如何确定要添加/保留的功能？ + +### 您是否实施网络分析？ + +我们使用 Google Analytics（分析），Mixpanel，Flurry 来衡量功能使用情况 + +### 您是否进行 A / B 测试？ + +是的，我们使用功能标记进行 A / B 测试。 有关更多信息，请参见 [在 Egnyte 使用功能标志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) + +### 您要运行多少个数据中心？ + +3 个主要数据中心，包括欧洲的一个（由于安全港规则） 和遍布全球的 pop-pop。 + +### 您的系统如何部署在数据中心中？ + +Puppet / Ansible 用于部署大多数新代码。 + +### 您使用哪种防火墙产品？ + +帕洛阿尔托网络 + +### 您使用哪个 DNS 服务？ + +NS1 + +### 您使用哪些路由器？ + +思科 + +### 您使用哪些开关？ + +Arista + +### 您使用哪个电子邮件系统？ + +我们结合使用 SendGrid 和我们自己的 SMTP 服务器。 + +### 如何备份和还原系统？ + +对于 MySQL，我们使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，对于 Elasticsearch，该数据被复制 3 次。 对于客户文件，我们将其复制 3 次，并将 1 个副本存储在 DR 公共云中。 如果存储 Filer 无法恢复，我们将丢弃它，添加一个新 Filer 并再次复制副本。 对于某些客户，我们还会将其数据复制到他们选择的提供商。 对于使用 S3，Azure 或 GCS 作为可插入存储层的客户，它将确保复制以防止数据丢失。 + +### 如何进行软件和硬件升级？ + +大多数节点是无状态的，并且有状态组件具有主动-主动故障转移。 通过将节点从池中取出并进行升级并将其放回池中来处理升级。 我们使用 jenkins + Ansible + puppet 和自定义自动化。 + +### 您如何处理升级中数据库架构的重大更改？ + +不同的服务使用不同类型的数据库，并且它们以不同的方式升级。 在 10000 英尺处，它们如下图所示： + +![](img/4424662bfcfaca90969ec39e8fa0dbb4.png) + +1. EOS DB 存储对象元数据并且增长非常快，它经过分片，并且我们将继续添加更多此类数据。 + +2. MDB 的增长速度更快，经过了分片，并且我们会继续增加更多。 + +3. DC_central 是一个 DNS 数据库，并且保持相当静态。 我们运行了许多此副本以实现可伸缩性。 + +4. Pod_central 具有快速突变的数据，但每个表的增长量不超过 2000 万行。 我们运行了许多此副本以实现可伸缩性。 + +* 每个数据库模式始终是向前和向后兼容的，即我们绝不会在同一发行版中删除列和代码，我们首先在停止使用该列的发行版 1 中部署代码，而在发行版 2 中我们删除该列。 + +* 非分片数据库每周更新一次。 它们是存储各种功能驱动表的表。 我们目前在生产环境中使用脚本对其进行升级，但是我们在质量检查中使用 Liquibase，并且正在逐步将其应用于生产环境 + +* 使用自动脚本进行分片的数据库新列更改 + +* 分片数据库迁移是一件痛苦的事情，因为我们有 12000 多个分片并且还在不断增长，您无法在 1 小时的升级窗口中完成。 方法是： + + * 实时代码根据需要迁移行。 这意味着迁移可能需要几个月的时间。 + + * 使用功能标记迁移，您同时拥有旧代码/新代码，并且在后台迁移客户，然后翻转标记以将其切换到新代码路径而无需停机，更多的是 [此处](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此处](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) + + * 当我们从 Lucene 迁移到 ElasticSearch 时，除了重新索引所有内容外，我们别无选择，我们使用了 [功能标记](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) ， -4 个月完成。 + +* 模式一致性检查器报告可确保升级后所有数据中心中的所有模式均相同。 + +### 您是否有单独的运营团队来管理您的网站？ + +是的，我们有一个专门的生产工程，SRE 和一个 IT / Ops 团队，负责监视和管理生产。 但是正如我之前所说，构建此功能的工程师负责制定决策，因此他们将深入参与监视指标并解决生产问题。 + +## 其他 + +### 您欣赏谁？ + +AWS ：他们的创新步伐令人赞叹。 + +Google ：BigQuery，Kubernetes 之类的工具很棒。 + +Elasticsearch： 其余的 API 简单性和架构很棒。 我们用一个 TB 的数据和一个工程师来管理一个 100 多个节点的集群。 + +MySQL / Memcache： 它们简单，快速且很棒。 + +Eclipse / Jenkins ：插件架构很好。 + +### 您是否模仿了其他人的公司/方法？ + +我们是 [http://highscalability.com/](http://highscalability.com/) 的常规读者，许多设计都受到它的启发。 + +* POD 架构的灵感来自 Tumblr 的 Cell 架构。 这不是精确匹配，但是隔离故障的概念是相同的。 + +* 受 Facebook 启发的架构在 12 个小时后会在 Memcached 和刷新键中产生抖动。 + +* 受 [http://highscalability.com/上一些文章的启发，将](http://highscalability.com/) [指纹添加到每个数据库查询](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) + +我们正在招聘，请在 [职位页面](https://www.egnyte.com/jobs/) 中查看我们，并在 [与我们联系 [受电子邮件保护]](/cdn-cgi/l/email-protection) 。如果您有兴趣成为 [Egnyte](https://www.egnyte.com) 令人惊叹的团队的一员。 \ No newline at end of file diff --git a/docs/25.md b/docs/25.md index f46ddbb..f681cbf 100644 --- a/docs/25.md +++ b/docs/25.md @@ -1,152 +1,83 @@ -# Zapier 如何自动化数十亿个工作流自动化任务的旅程 +# Skype 计划 PostgreSQL 扩展到 10 亿用户 -> 原文： [http://highscalability.com/blog/2016/2/29/a-journey-through-how-zapier-automates-billions-of-workflow.html](http://highscalability.com/blog/2016/2/29/a-journey-through-how-zapier-automates-billions-of-workflow.html) +> 原文： [http://highscalability.com/blog/2008/4/5/skype-plans-for-postgresql-to-scale-to-1-billion-users.html](http://highscalability.com/blog/2008/4/5/skype-plans-for-postgresql-to-scale-to-1-billion-users.html) -*这是[的来宾](http://stackshare.io/zapier/scaling-zapier-to-automate-billions-of-tasks)[转贴了](http://stackshare.io/zapier/scaling-zapier-to-automate-billions-of-tasks) [Bryan Helmig](http://stackshare.io/bryanhelmig) ， [Zapier](http://stackshare.io/zapier) 的联合创始人& CTO，他可以轻松地在 Web 之间自动执行任务 应用。* +Skype [使用 PostgreSQL 作为后端数据库](https://developer.skype.com/SkypeGarage/DbProjects/SkypePostgresqlWhitepaper)。 PostgreSQL 在数据库世界中没有得到足够的运行，因此我很高兴地看到 PostgreSQL 如何被用作“满足[Skype]大部分业务需求的主要数据库”。 他们的方法是使用传统的存储过程接口来访问数据，并在该层代理服务器之上，该代理服务器将 SQL 请求散列到一组实际执行查询的数据库服务器上。 结果是他们认为水平扩展的系统可以扩展到可处理 10 亿用户。 -![](img/99150b9925c63916b576766be5cb68de.png) +* Skype 的目标是一种可以处理 10 亿以上用户的体系结构。 使用一台真正的大型计算机实际上无法解决此级别的缩放问题，因此我们的蒙版超级英雄水平缩放可以解决。* 硬件是带有 SCSI RAID 的双或四皓龙。* 遵循常见的数据库进度：从一个 DB 开始。 添加按功能划分的新数据库。 复制以只读为主的数据，以实现更好的读取访问。 然后跨多个节点水平分区数据。* 无论如何，在此博客的第一篇文章中，Skype 使用传统的数据库体系结构，其中所有数据库访问都封装在存储过程中。 这使他们可以在不影响前端服务器的情况下进行后台性能调整。 而且它很适合使用 PL / Proxy 进行分区的策略。* [PL /代理](https://developer.skype.com/SkypeGarage/DbProjects/PlProxy)用于通过创建水平分区的集群来扩展其系统的 [OLTP](http://en.wikipedia.org/wiki/OLTP) 部分： -[Zapier](http://stackshare.io/zapier) 是一项 Web 服务，可自动执行 500 多个 Web 应用程序之间的数据流，其中包括 MailChimp，Salesforce，GitHub，Trello 等。 + -数据库查询由代理跨 一组数据库服务器。 代理根据字段值（通常是主键）创建分区。 + -例如，您可以根据用户名通过散列在整个群集中对用户进行分区。 根据哈希将每个用户放入一个碎片中。 + -远程数据库调用使用一种称为 plproxy 的新 PostgreSQL 数据库语言执行。 来自[的示例 Kristo Kaiv 的博客](http://kaiv.wordpress.com/category/plproxy/)： -想象一下[建立一个工作流](https://zapier.com/multi-step-zaps/)（或我们称为“ Zap”）的操作，该操作会在用户填写您的 Typeform 表单时触发，然后在您的 Google 日历上自动创建一个事件，发送一个 Slack 通知，最后完成 在 Google 表格电子表格中添加一行。 那是扎皮尔。 即使对于非技术用户来说，构建这样的 Zaps 也非常容易，并且可以无限地自定义。 + ``` -作为首席技术官和联合创始人，我构建了许多原始的核心系统，如今领导工程团队。 我想带您**，了解我们的堆栈**，以及我们如何构建它以及如何在今天继续改进它！ + First, code to insert a user in a database: + CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS text AS $$ + BEGIN + PERFORM 1 FROM users WHERE username = i_username; + IF NOT FOUND THEN + INSERT INTO users (username) VALUES (i_username); + RETURN 'user created'; + ELSE + RETURN 'user already exists'; + END IF; + END; + $$ LANGUAGE plpgsql SECURITY DEFINER; -## 幕后的团队 + Heres the proxy code to distribute the user insert to the correct partition: + queries=# + CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS TEXT AS $$ + CLUSTER 'queries'; RUN ON hashtext(i_username); + $$ LANGUAGE plproxy; -使 Zapier 滴答作响需要很多时间，因此我们在工程领域有四个不同的团队： + Your SQL query looks normal: + SELECT insert_user("username"); + ``` -* **前端团队**在非常强大的工作流编辑器上工作。 -* **全栈团队**是跨功能的，但专注于工作流引擎。 -* **开发人员小组**保持引擎嗡嗡作响。 -* **平台团队**（可协助进行质量检查），并为我们的开发人员平台提供了合作伙伴。 + -查询的结果与在远程数据库上执行的查询完全相同。 + -当前，他们可以将 Dual Opteron 服务器上的 1000-2000 请求/秒路由到 16 个分区集群。* 他们喜欢 OLTP 的 PL /代理方法，因为： + -PL /代理服务器形成可伸缩且统一的“ DB 总线”。 代理服务器很健壮，因为在冗余配置中，如果一个服务器出现故障，您可以直接连接到另一个服务器。 而且，如果代理层变慢，则可以添加更多代理并在它们之间进行负载平衡。 + -可以添加更多分区以提高性能。 + -故障转移期间，只有故障分区上的数据不可用。 所有其他分区均正常运行。* [PgBouncer](https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer) 用作 PostgreSQL 的连接池。 PL /代理“在打开每个后端进程与每个分区的连接时会浪费一些连接”，因此池管理器有助于减少连接数量。* 使用 [WAL（预写日志）传送](http://www.postgresql.org/docs/8.1/static/wal-intro.html)创建热备用服务器。 这些服务器似乎不能用于只读操作。* 更复杂的组织通常使用 OLTP 数据库系统来处理高性能事务需求，然后创建单独的系统来满足更多非事务性需求。 例如， [OLAP（在线分析处理）](http://en.wikipedia.org/wiki/Online_analytical_processing)系统通常用于处理复杂的分析和报告问题。 这些在模式，索引等方面与 OLTP 系统不同。 Skype 还将单独的系统用于 Web 应用程序的表示层，发送电子邮件和定价发票。 这要求将数据从 OLTP 移至其他系统。 + -最初 [Slony1](http://slony.info/) 用于将数据移至其他系统，但是“随着复杂性和负载的增加，Slony1 开始给我们带来越来越大的痛苦。” + -为解决此问题，Skype 开发了他们的轻量级排队和复制工具包，称为 [SkyTools](https://developer.skype.com/SkypeGarage/DbProjects/SkyTools) 。 -总而言之，这涉及约 15 名工程师（并且还在不断增加！）。 + 代理方法很有趣，并且是我们之前从未见过的架构。 它的力量来自使问题解决间接化的另一个层次，它具有以下优点：* 应用程序独立于数据库服务器的结构。 封装在代理服务器中。* 应用程序无需响应分区，映射或其他更改而进行更改。* 负载平衡，故障转移和读/写拆分对于应用程序是不可见的。 -## 架构 + 的缺点是：* 性能降低。 添加了另一跳，必须解析查询才能执行所有透明的魔术。* 无法跨分区执行联接和其他数据库操作。* 增加了处理代理服务器的代理配置和 HA 的管理复杂性。 -**我们的堆栈不会赢得任何新颖性奖项**-我们正在使用一些非常标准的（但很棒的）工具为 Zapier 提供动力。 更有趣的是我们使用它们来解决特定品牌问题的方式，但让我们将基础知识排除在外： + 容易看出优势大于弊端。 在不更改应用程序的情况下，您可以滑入代理层，并以低价获得很多非常酷的功能。 如果您是 MySQL 用户，并且对这种方法感兴趣，那么请查看 [MySQL 代理](海洋植物 +[http://underwaterseaplants.awardspace.com/seagrapes.htm”](海葡萄... [http：// underwaterseaplants。 awardspace.com/plantroots.htm“](植物根 -### 该平台 +上面关于万亿用户的评论很有趣，因为目前世界上只有 67 亿人，而问题不是 Skype 是否可以支持一万亿用户，而是我们的星球是否可以支持一万亿人：D -我们的大多数平台都位于相当**的整体式核心 Python 代码库**中，但是有许多有趣的分支提供了专门的功能。 最好的例子可能是我们如何利用 [AWS Lambda](http://stackshare.io/aws-lambda) 运行合作伙伴/用户提供的代码以自定义应用程序行为和 API 通信。 +好文章 -### 基础设施 +我们现在有 2 个 PgBouncer，12 个节点和 12 个 WAL 备份服务器，并且一切正常。 +服务器是 1u 双胞胎，双四核 Intel xeon，具有 32GB 内存和 2 x sas，每个双胞胎上的硬件 raid1。 -由于 Zapier **在 AWS** 上运行，因此我们触手可及。 [EC2](http://stackshare.io/amazon-ec2) 和 [VPC](http://stackshare.io/amazon-vpc) 是此处的中心，尽管我们会尽可能使用 [RDS](http://stackshare.io/amazon-rds) 以及大量的自动伸缩组，以确保服务器池处于最佳状态。 顶部形状。 [詹金斯](http://stackshare.io/jenkins)，[地形](http://stackshare.io/terraform)，[人偶](http://stackshare.io/puppet)和 [Ansible](http://stackshare.io/ansible) 都是开发团队的日常工具。 为了监视，我们对 [Statsd](http://stackshare.io/statsd) ， [Graylog](http://stackshare.io/graylog) 和 [Sentry](http://stackshare.io/sentry) （他们*很好*）不够满意。 +--- +[http://www.unixvps.com](http://www.unixvps.com) -## 一些粗糙的数字 +我想知道为什么您选择 PostgreSQL 而不是 MySQL？ -这些数字代表一个大概的最小值，以帮助读者了解 Zapier 体系结构的总体大小和尺寸： +如果您需要任何事务性的东西（而不是 MyISAM），那么 PostgreSQL 的伸缩性要好于使用 InnoDB 的 MySQL。 -* 每天自动完成约 800 万个任务 -* 每天超过约 6000 万次 API 调用 -* 每天有超过 1000 万个入站 Webhooks -* 在 [ELB](http://stackshare.io/aws-elastic-load-balancing) 之后运行 HTTP 的〜12 个 c3.2xlarge 框 -* 运行 [Celery](http://stackshare.io/celery) 的约 100 个 m3.2xlarge 后台工作者（在轮询，挂钩，电子邮件，其他杂项之间拆分） -* 集群中约 3 m3.medium [RabbitMQ](http://stackshare.io/rabbitmq) 节点 -* 〜4 个 r3.2xlarge [Redis](http://stackshare.io/redis) 实例-一个热，两个故障转移，一个备份/映像 -* 〜6 m3.xlarge McRouter 实例之后的〜12 m2.xlarge [Memcached](http://stackshare.io/memcached) 实例 -* 〜3 m3.xlarge 无数据 ElasticSearch 实例之后的〜10 m3.xlarge [ElasticSearch](http://stackshare.io/elasticsearch) 实例 -* 〜1 个 c3.2xlarge Graylog 服务器后面的〜6 m3.xlarge ElasticSearch 实例 -* 集群中约 10 个 dc1.large [Redshift](http://stackshare.io/amazon-redshift) 节点 -* 1 个主 db.m2.2xlarge [RDS MySQL](http://stackshare.io/amazon-rds) 实例，带有〜2 个以上的副本，可用于生产读取和分析 -* 少数支持 RDS MySQL 实例（下面有更多详细信息） -* ...以及大量的微服务和杂项专业服务 +我还猜想 Skype 中的某些人比 MySQL 更了解 PG，而 MySQL 和 PG 对存储过程，触发器等的支持要好得多， -## 改善架构 - -虽然架构的主要内容保持不变-我们仅执行了几次大规模迁移-但为将产品分为两类进行了大量工作： - -1. 支持重要的新产品功能 -2. 为更多用户扩展应用程序 - -让我们深入研究每个示例，尽可能多地获取细节，而不会陷入困境！ - -#### 大型功能，例如多步 Zaps - -当我们在 Startup 周末启动 Zapier（有趣的事实：它首先被称为 Snapier！）时，我们在不到 54 个小时的时间内布置了基本架构（由大量的咖啡和更多的啤酒推动）。 总的来说，这是体面的。 **我们保持设计非常非常简单**，这在当时是正确的选择。 - -除了**之外，*也是*简单**。 具体来说，我们将 Zaps 分为两步：将触发器与一个动作配对，一个句号。 - -我们很快就意识到了错过的机会，但是过渡将非常复杂。 我们必须实现一棵有向树，并支持任意数量的步骤（节点），但要对现有 Zaps（已经有数十万个）保持 1 对 1 的支持。 我们必须做到这一点，同时还要保留对数百个独立合作伙伴 API 的支持。 - -从数据模型开始，我们在 MySQL 中构建了一个非常简单的有向树结构。 想象一下一个表，其中每行都有一个自引用`parent_id`外键，再加上一个额外的`root_id`外键以简化查询，您几乎可以理解。 我们讨论了切换到适当的图形数据库（例如 neo4j）的决定，但由于我们进行的查询种类简单且遍历较小尺寸的孤立图形（大约 2 至 50 个节点），因此决定不这样做。 - -进行此工作的一个关键方面是步骤间的独立性。 每一步都必须消耗一些数据（例如，要读取哪个文件夹或要添加到哪个列表 ID），进行 API 魔术处理并返回一些数据（例如，创建的新文件或添加到列表的新卡） ，但不知道其在工作流程中的位置。 每个独立的步骤都是愚蠢的。 - -中间存在**全知的工作流引擎，该引擎通过将步骤串联在一起作为任务来协调独立的 Celery 任务**-一步是由 Zap 的有根树定义的。 这个无所不知的引擎还包含所有其他好处，例如错误&重试处理，报告，日志记录，节流等。 - -即使在获得后端支持之后，我们仍然遇到另一个巨大的问题：**您如何为该对象构建 UI？** - -首先，确保团队中有一些*出色的*设计师和 Javascript 工程师。 然后，您将在嵌套的 Backbone 视图中工作一段时间，然后再进入 React。 :-)认真地说： [React](/react) 是我们正在构建的各种复杂接口的天赐之物。 - -React 的独特之处之一是性能特性对开发人员很友好，但前提是您必须弄清楚数据。 如果您不使用不可变的数据结构，则应使用一些结构共享库来进行所有突变，以及正在开发的深层`Object.freeze()`来捕捉直接尝试突变的地方。 - -构建如此复杂的 UI 面临许多挑战，其中大部分围绕测试和反馈，但要花费大量时间才能从不同的 API 中获取长尾数据，以使其优雅地适合于同一位置。 几乎每种奇怪的数据形状都必须考虑在内。 - -最后，我们的任务是让新编辑器在用户面前进行 alpha 和 beta 测试。 为此，我们同时发布了两个版本的编辑器，并使用功能开关选择了加入用户。在对结果感到满意之前，我们进行了数月的测试和调整-您可以查看 [Multi-Step Zap 的发布 页](https://zapier.com/multi-step-zaps/)了解其最终结果。 - -![](img/7faac64c1acccc1743339f5d3bf58370.png) - -## 扩展应用程序 - -如果服务无法正常启动并可靠运行，那将是徒劳的。 因此，我们的大部分注意力集中在支持水平可伸缩性*和*冗余基础结构以确保可用性的应用程序设计上。 - -到目前为止，我们做出的一些更明智的决定是**使我们对**感到满意的技术加倍**遇到瓶颈**时，分离出单独的功能。 关键是**重用完全相同的解决方案，然后将其移到另一个盒子中，可以在其中自由漫游 CPU 和 RAM 的新鲜草场**。 - -例如，在过去的一年左右的时间里，我们注意到会话数据耗尽了我们主数据库的 IO 和存储量。 由于会话数据实际上是具有较弱一致性要求的键/值排列，因此我们对诸如 [Cassandra](http://stackshare.io/cassandra) 或 [Riak](http://stackshare.io/riak) （甚至是 Redis！）之类的方案进行了激烈的辩论，但最终决定站起来 具有单个会话表的 MySQL 实例。 - -作为工程师，我们的本能是找到最适合该工作的工具，但是**作为实际问题**，该工作并不能保证额外的操作复杂性。 我们知道 MySQL，它可以进行简单的键/值存储，我们的应用程序已经支持它。 畅所欲言。 - -此外，仔细设计应用程序可以使水平缩放同样简单。 由于**轻写模式**，长期运行的后台任务（例如我们的多步骤 Zaps）不受严格的一致性要求的约束，因此**使用 MySQL 读操作是微不足道的（而且很安全！）。 仅复制**作为*主要*接触点。 即使我们偶尔在几分钟内得到了可怕的复制品延迟，但 99.9％的 Zaps 并没有改变-并且肯定不会很快改变-因此它们继续嗡嗡作响。 - -另一个好的做法是**假设最坏的**。 从一开始就设计失败。 尽管通常说起来容易做起来难，但如今实际上却很容易做到。 对于初学者：**将自动缩放组与自动替换**一起使用。 一个常见的误解是，ASG 仅用于扩展以适应波动的负载。 **错误！** **ASG + ELB 组合可以成为可靠性的骨干**，它使您可以随意杀死实例，而不必担心，因为它们会被快速替换。 - -不知何故，我们不断地学习到，系统越简单，您的睡眠就越好。 - -## 日常 - -在本地，我们的工程师享受 [Docker](http://stackshare.io/docker) 提供的功能全面的环境。 `[docker-machine](http://stackshare.io/docker-machine)`和 [`docker-compose`](http://stackshare.io/docker-compose) 一起构成了 MySQL，Memcached，Redis，Elasticsearch 以及所有 Web 和后台工作人员的正确版本。 我们通常建议在本地运行 [`npm`](/npm) 甚至是`runserver`，因为 VirtualBox 破坏了文件监视功能。 - -规范的 [GitHub](http://stackshare.io/github) “拉动请求模型”驱动了我们的大部分工程重点项目，其中记录了日常工作，并在合并之前进行了最终代码审查。 [Hackpad](http://stackshare.io/hackpad) 包含了我们的大部分文档，其中包括大量的入门文档。 - -Zapier 的一大优势是[所有人都支持](https://zapier.com/blog/everyone-on-support/)。 每四到五周，每位工程师都会花费整整一周的支持来帮助调试和解决棘手的客户问题。 这对我们非常重要，因为它为了解客户的痛苦提供了基线（此外，您可能必须处理所运送的错误！）。 - -对于 CI 和部署，我们使用 [Jenkins](http://stackshare.io/jenkins) 在每个 PR 中的每个提交上运行测试，并提供公司任何人都可以按下的“一键式部署”。 新工程师在工作的第一周点击部署按钮的情况并不少见！ - -我们在独立的 VPC 中拥有一个**完整的登台环境，以及一些非常适合测试长期拉动请求的独立 Web 框。 金丝雀部署到生产中很常见-完整记录所有错误，由 Graylog 提供。** - -## 你也可以扎皮尔！ - -开发人员可以使用 Zapier 来做一些很棒的事情。 - -除了多步骤 Zaps 之外，我们还启用了将 [Python](https://zapier.com/help/code-python/) 和 [Javascript](https://zapier.com/help/code/) 编写为工作流中的代码步骤的功能。 无需自己托管和运行脚本-我们会处理所有这些。 我们还提供了绑定以调用网络（`requests`和`fetch`），甚至在运行之间存储一些状态！ - -我们的用户正在采用代码步骤来构建 [Slack](http://stackshare.io/slack) 机器人（以及游戏！），以替换一次性脚本以及更多其他内容。 我个人使用代码步骤来编写机器人和工具，以将代码&错误度量标准跟踪到电子表格中，转换格式奇怪的数据，并替换*吨*的 crontabs。 - -或者，如果您拥有希望非开发人员能够使用的 API，那么我们也将拥有一个史诗般的[开发人员平台](https://zapier.com/developer/)。 只需定义触发器，搜索和操作，任何用户都可以将您的 API 混合到他们的工作流中，并将您的应用程序与 GitHub，Salesforce，Google Docs 等 500 多种应用程序集成。 - -而且，我们经常在招聘，因此，如果您想帮助我们帮助人们更快地工作并自动执行最繁琐的任务，请关注我们的[工作页面](https://zapier.com/jobs/)！ - -[关于 HackerNews](https://news.ycombinator.com/item?id=11082359) - -链接已断开... - -感谢抓住 Gigi！ - -为什么使用 MySQL？ Postgres 不是它的超集吗？ - -您能否评论一下如何在芹菜上实现编排？ 以我的经验，很难做到这一点，因为大部分逻辑是在任务级别定义的，例如，很难在运行时修改任务的行为，因为它是定义的，并且在模块加载到工作程序时变为静态。 \ No newline at end of file +里斯 \ No newline at end of file diff --git a/docs/26.md b/docs/26.md index 1316a09..1be8eb1 100644 --- a/docs/26.md +++ b/docs/26.md @@ -1,625 +1,135 @@ -# Egnyte 体系结构：构建和扩展多 PB 分布式系统的经验教训 +# 易趣建筑 -> 原文： [http://highscalability.com/blog/2016/2/15/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2016/2/15/egnyte-architecture-lessons-learned-in-building-and-scaling.html) +> 原文： [http://highscalability.com/blog/2008/5/27/ebay-architecture.html](http://highscalability.com/blog/2008/5/27/ebay-architecture.html) -![](img/6c80e21424564200e0ef4dac300da8ff.png) +**更新 2：** eBay 的 Randy Shoup 在可伸缩性[最佳做法：eBay](http://www.infoq.com/articles/ebay-scalability-best-practices) 上的 InfoQ 上讲了如何为每天服务数亿用户和超过 20 亿页面浏览量的秘密。 做法：按功能划分，水平拆分，避免分布式事务，异步解耦功能，将处理移至异步流，在各个级别进行虚拟化，适当地缓存。 +**更新：** [eBay 每月提供 50 亿个 API 调用](http://blog.programmableweb.com/2007/11/19/ebay-serves-5-billion-api-calls-each-month/)。 我们不是看到开放式 API 之上的混搭驱动了越来越多的流量吗？ API 不再是束缚，而是您的应用程序。 从体系结构上讲，开发人员和用户使用相同的 API 来实现自己的应用程序。 -*这是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的来宾帖子，他是在家工作的建筑师。 他和他的同事们花费大量的工作时间扩展了那里最大的分布式文件系统之一。 他在 [Egnyte](https://www.egnyte.com/) （一家企业文件同步共享和分析启动）中工作，您可以在 [@kpatelwork 与他联系 ]](https://twitter.com/kpatelwork) 。* +谁不知道 eBay 的业务如何？ 作为世界上负载最大的网站之一，这并不容易。 演讲的字幕暗示了如何创建这样一个庞然大物的系统需要真正的工程：在站点稳定性，特征速度，性能和成本之间取得平衡。 -您的笔记本电脑有一个文件系统，该文件系统被数百个进程使用，它受到磁盘空间的限制，无法弹性扩展存储，如果您运行一些 I / O 密集型进程或尝试与 100 个其他用户共享该文件系统，它会令人窒息。 现在解决这个问题，并将其放大为遍布全球的数百万付费用户使用的文件系统，您将可以通过云霄飞车扩展该系统，以满足每月的增长需求并满足 SLA 要求。 +您可能无法模仿 eBay 如何扩展其系统，但是值得学习的问题和可能的解决方案。 -**Egnyte 是一家企业文件同步和共享创业公司**，成立于 2007 年，当时 Google 硬盘还没有诞生，而 AWS S3 的成本却很高。 我们唯一的选择是放开袖子，自己建立一个对象存储，S3 和 GCS 的超时成本变得合理，并且由于我们的存储层基于插件架构，因此我们现在可以插入任何便宜的存储后端。 我们已经多次重新架构了许多核心组件的架构，在本文中，我将尝试分享当前的架构是什么，我们学到的扩展规模的经验教训以及我们仍需改进的内容。 +网站：http：//ebay.com -## 平台 +## 信息来源 -* Tomcat +* [eBay 架构](http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf)-在网站稳定性，功能速度，性能和成本之间取得平衡。* [播客：eBay 的大规模交易](http://www.uie.com/BSAL/BSAL010_Rohrer_eBayScale_WAS.mp3)* [Dan Pritchett 在 eBay 上的建筑](http://www.infoq.com/interviews/dan-pritchett-ebay-architecture)接受 InfoQ 的采访 -* MySQL + ## 平台 -* HAProxy + * 爪哇* 甲骨文* WebSphere，servlet* 水平缩放* 分片* Mix of Windows and Unix -* Nginx + ## 里面有什么？ -* Memcached + This information was adapted from Johannes Ernst's [Blog](http://netmesh.info/jernst/Comments/sdforum-ebay-architecture.html) -* Apache + ### 统计资料 -* [Elasticsearch](https://www.elastic.co/) + * 平均每天，它会处理 260 亿条 SQL 查询，并保持 1 亿个可供购买的商品的标签。* 注册用户 2.12 亿，照片 10 亿* 每天 10 亿次页面浏览，1.05 亿个列表，2 PB 数据，每月 30 亿次 API 调用* 从 1999 年 6 月到 2006 年第 3 季度，页面浏览量，发送的电子邮件和带宽之类的因素大约为 35。* 99.94％的可用性，衡量为“网站的所有部分对每个人都起作用”与网站的至少一部分对某些地方的某些用户不起作用* 该数据库已虚拟化，并且跨越了 100 多个服务器群集中的 600 个生产实例。* 15,000 个应用程序服务器，全部为 J2EE。 约有 100 组功能，也称为“应用程序”。 “池”的概念：“处理销售的所有机器” ... -* Redis + ### 架构 -* RabbitMQ + * 一切都计划在问题“如果负载增加 10 倍会怎样”。 仅缩放水平，不缩放垂直：许多平行的盒子。* 架构严格分为几层：数据层，应用程序层，搜索，操作，* 利用用于表示层的 MSXML 框架（即使在 Java 中）* Oracle 数据库，WebSphere Java（仍为 1.3.1）* 按主访问路径（以键为模）拆分数据库。* 每个数据库至少有 3 个在线数据库。 分布在 8 个数据中心* 一些数据库副本会在 15 分钟后，4 小时后运行* 数据库按功能进行细分：用户，物料帐户，反馈，交易，共有 70 多个。* 没有使用存储过程。 有一些非常简单的触发器。* 将 cpu 密集型工作从数据库层移到应用程序应用程序层：引用完整性，联接，排序在应用程序层完成！ 推理：应用服务器便宜，数据库是瓶颈。* 没有客户端交易。 没有分布式交易* J2EE：使用 servlet，JDBC，连接池（带有重写）。 没什么。* 应用程序层中没有状态信息。 Cookie 或暂存数据库中保持的瞬态状态。* 应用服务器之间不会互相通信-严格的架构分层* 搜索，在 2002 年：9 小时来更新运行在可用的最大 Sun 盒上的索引-不跟上。* 网站上的普通商品在出售前会更改其搜索数据 5 次（例如价格），因此实时搜索结果非常重要。* “旅行者”：由 eBay 建立的实时馈送器基础结构。使用从主数据库到搜索节点的可靠多播，内存中搜索索引，水平分段，N 个切片，M 个实例上的负载均衡，缓存查询。 -* CentOS + ## 得到教训 -* 人偶 + * **横向扩展，不向上扩展** + –每层的水平扩展。 + –功能分解。 -* 新遗物 + * **首选异步集成** + –最小化可用性耦合。 + –改进缩放选项。 -* AppDynamics + * **虚拟化组件** + –减少物理依赖性。 + –提高部署灵活性。 -* ZooKeeper + * **故障设计** + –自动故障检测和通知。 + –业务功能的“ Limp 模式”操作。 -* LDAP + * **因为数据库是瓶颈**，所以将工作从数据库移到应用程序中。 Ebay 做到了这一点。 我们在使用缓存和文件系统的其他体系结构中看到了这一点，但是 eBay 甚至在应用程序中执行了许多传统的数据库操作（例如联接）。 -* Nagios + * **使用喜欢的东西，扔掉不需要的东西**。 Ebay 并没有强迫使用完整的 J2EE 堆栈。 他们喜欢 Java 和 Servlet，因此仅此而已。 您不必完全购买任何框架。 只需使用对您有用的东西。 -* 石墨 + * **不要害怕建立满足您需求并不断发展的解决方案**。 每种现成的解决方案都会使您失望。 您必须自己走其余的路。 -* 仙人掌 + * **随着您的成长**，操作控件将成为可伸缩性越来越大的一部分。 如何升级，配置和监视将运行实时系统的数千台计算机？ -* Apache FTP 服务器 + * **体系结构不断发展。** 您需要能够更改，完善和开发新系统，同时保持现有站点的运行状态。 这是任何成长中的网站的主要挑战。 -* OpenTSDB + * **从一开始就过于担心可伸缩性是一个错误。 不要因分析而陷入瘫痪，也不必担心流量永远不会到来。** * **完全不担心可伸缩性**也是一个错误。 您需要建立一个能够应对架构演变的组织。 了解您永远不会完成。 您的系统将始终在发展和变化。 从一开始就将这些期望和功能融入您的业务中。 不要让人和组织成为您网站失败的原因。 许多人会认为该系统从一开始就应该是完美的。 那样行不通。 为了应对实际问题和关注，加班开发了一个好的系统。 期待变化并适应变化。 -* Google BigQuery +另一个有趣的问题是：eBay 的体系结构是他们使用 Akamai 托管其静态内容。 这显然不是秘密，但在他们的体系结构幻灯片中并未提及。 -* Google BigTable +nslookup pics.ebaystatic.com +服务器：10.10.1.140 +地址：10.10.1.140＃53 -* Google Analytics +非权威性答案： +pics.ebaystatic.com 规范名称= pics.ebaystatic.georedirector.akadns.net。 +pics.ebaystatic.georedirector.akadns.net 规范名称= pics.ebaystatic.com.edgesuite.net。 +pics.ebaystatic.com.edgesuite.net 规范名称= a1654.g.akamai.net。 +名称：a1654.g.akamai.net +地址：69.8.201.99 +名称：a1654.g.akamai.net +地址：69.8.201.104 -* MixPanel +我看到您在一开始就提到过：“ Windows 和 Unix 的混合体” +，但是后来对于使用 Windows 用于...的想法却没有定论。 +我想所有的 Web 服务器，DB 都是 在 Linux 上。 +有什么想法吗？ -* 表格 +--- +[http://iphone.mybuywatcher.com](http://iphone.mybuywatcher.com) -* ReactJS /主干/木偶/ jQuery / npm / nighwatch +在 Ido 的体系结构部分中，有一个项目“利用用于表示层的 MSXML 框架（甚至在 Java 中）”-这可能意味着 Windows 在应用程序服务器上使用。 -* Rsync +Windows 将成为可扩展性恕我直言的瓶颈。 -* [PowerDNS](https://www.powerdns.com/) +我不同意 Windows 是瓶颈。 特别是如果做对了。 看看“丰盛的鱼”文章。 -* 服装 +- +您编码吗？ 和我们一起出去玩吧！ +[http://codershangout.com](http://codershangout.com) -* 基于 REST API 的 SOA 体系结构。 +I saw that you mention in the beginning: "Mix of Windows and Unix" +But later on there is no idecation for what windows is being used for... +I would guess that all the web servers, DB are on Linux. +Any idea? -* Java 用于驱动核心文件系统代码 +e-bay 架构极大地改善了其技术，并购买了 gittigidiyor.com -* Python 通常用于驱动大多数客户端代码，迁移脚本，内部脚本。 一些 python 代码仍驻留在服务器上，但是由于我们有更多具有 Java 熟悉和扩展经验的服务器开发人员，因此大多数 python 代码已迁移到 Java。 +哇，我知道 ebay 很大，但我从未意识到它是如此之大。 1 亿个物品可供购买...很多物品。 更不用说页面浏览量了。 +我将非常有兴趣学习 ebay 背后的故事，想法及其开始方式。 -* 原生 Android / iOS 应用 +易趣是一家了不起的公司。 他们能够跟踪每日交易的数量这一简单事实证明了他们的体系结构。 日常所需的流量和安全性将使大多数公司屈服。 -* 适用于各种平台的桌面和服务器同步客户端 +约翰·塔舍尔 -* GCE +说的没错。 ebay 仅一天就花在安全方面的费用超过了大多数领先公司的月收入，他们保持了出色的体系结构并实现了预期的目标。 -* GCS / S3 / Azure /...。 +我不知道...虽然我真的很喜欢 eBay 在整个联属网络营销中的发展方向，但我还是有些怀疑。 -## 统计信息 +Ebay 将被 Google 或 Microsoft 接管。 -* 3 个主要数据中心，包括欧洲的 1 个（根据安全港规定） +DBMS2 在[上有新的博客文章，网址为 http://www.dbms2.com/2009/04/30/ebays-two-enormous-data-warehouses/“]( eBay 的两个巨大的数据仓库。 有关 eBay 的两个数据仓库的详细信息。 -* 200 多个 Tomcat 服务节点 +eBay 主要 Teradata 数据仓库的指标包括： -* 由 Tomcat / nginx 提供支持的 300 多个存储节点 +* 2 PB 以上的用户数据 -* 100 多个 MySQL 节点 +* 72 个节点 -* 50 多个 Elasticsearch 节点 +eBay 的 Greenplum 数据仓库（或数据集市）的指标包括： -* 20 多个 HAProxy 节点 +* 6 1/2 PB 用户数据 -* 和许多其他类型的服务节点 +* 17 万亿条记录 -* 我们服务器和 GCS 中存储了数 PB 的数据 +* 每天有 1500 亿条新记录，这似乎表明摄取速率远远超过了 50 TB /天 -* 在 Elasticsearch 中建立索引的数 PB 数据内容 +* 96 个节点 -* 许多桌面客户端将文件与云同步 - -## 认识您 - -### 您的系统名称是什么，我们在哪里可以找到更多信息？ - -Egnyte 是启动公司的名称，核心系统有很多主要部分，例如 CFS（云文件服务器），EOS（Egnyte 对象存储），事件同步和...。您可以在中找到更多有关这些的内容。 [对于技术人员](https://www.egnyte.com/blog/category/for-the-techies/) 部分，在我们的博客中。 - -### 您的系统是干什么的？ - -它推动了成千上万企业的同步和共享需求，并且云使它们的现有文件系统可以被 FTP，webdav，移动，公共 api，Web UI 和...等各种端点使用。 - -### 您为什么决定构建此系统？ - -在 2007 年，企业/员工队伍开始变得越来越分散，客户正在使用多个设备来访问相同的文件，并且有必要使这种体验尽可能的顺畅 - -### 您的项目经费如何？ - -这是一家自负盈亏的公司，后来我们在过去 8 年中进行了 5 轮募集，筹集了 6250 万美元[](https://www.crunchbase.com/organization/egnyte#/entity) - -### 您的收入模式是什么？ - -我们没有免费用户，但是我们提供 15 天免费试用，之后客户无需支付席位即可付费。 - -### 您如何销售产品？ - -我们从 SEM / SEO 开始，但随着时间的增长，我们通过许多渠道为企业客户争取了诸如社交媒体，Biz 开发，贸易展览，SEM，SEO，入站营销和高联系销售的客户。 - -### 您从事这项工作多久了？ - -它成立于 2007 年，目前已有 8 年的历史。 - -### 您的系统多大？ 尝试感受一下系统的工作量。 - -我们存储数十亿个文件和多个 PB 的数据。 根据 New Relic，我们平均每秒观察到超过 2K 的 api 请求。 由于安全港规定和位置相近，我们将数据存储在 3 个主要数据中心中。 有关更多信息，请参见统计信息部分。 - -### 您的输入/输出带宽使用量是多少？ - -我没有确切的数字，因为它一直在增长，但是客户上个月下载了接近 1 PB 的压缩/未压缩数据。 - -### 您提供多少份文件？ 多少张图片？ 多少数据？ - -我们存储数十亿个文件和多个 PB 的数据。 我们存储各种文件，而我们的前 5 个文件扩展名是 pdf，doc / docx，xl​​s / xlsx，jpeg 和 png。 - -### 免费用户与付费用户的比例是多少？ - -我们所有的用户均为付费用户。 我们提供 15 天的免费试用期，之后将其转换或将其禁用。 - -### 在过去一个月中有多少个帐户处于活动状态？ - -我们所有的客户都是付费帐户，并且每个月几乎所有人都活跃。 我们满足他们文件系统的需求，谁在家不用电？ - -## 您的系统如何设计？ - -### 您的系统的体系结构是什么？ - -我们使用基于 REST 的面向服务的体系结构，它使我们能够独立扩展每个服务。 这也使我们能够将一些后端服务移至公共云中托管。 所有服务都是无状态的，并使用数据库或我们自己的对象存储进行存储。 由于服务众多，因此很难将所有服务都绘制在一张图中。 - -[典型请求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的 10000 英尺总览如下 - -![](img/22e68ad1e1e96e52b90aa3482a2446fa.png) - -大约 10000 英尺的 [搜索架构](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下 - -![](img/fd48e5809512b072dec807353c9a0a0a.png) - -### 您的系统面临哪些特定的设计/架构/实施挑战？ - -最大的 架构 挑战包括：- - -1. 节俭地扩展文件存储 - -2. 扩展元数据访问 - -3. 文件与桌面客户端的实时同步 - -### 您是如何应对这些挑战的？ - -1. 对于存储，我们编写了自己的存储，现在我们使用可插拔的存储体系结构将其存储到任何公共云，例如 S3，GCS，Azure...。 - -2. 为了扩展元数据，我们移至 Mysql 并开始使用分片。 在某个时候，我们暂时投入了更多的硬件来腾出空间，以便一层一层地剥去鳞屑洋葱。 - -3. 为了进行实时同步，我们必须更改同步算法，使其更像 Svn，客户端接收增量事件并尝试与云状态进行最终的一致同步。 - -4. 监视，监视和监视。 您无法优化无法衡量的内容。 在某些时候，我们监控太多，无法专注于所有指标，我们不得不依靠异常检测工具，例如 New Relic，AppDynamics，OpenTSDB 和自定义报告，以使我们能够专注于绿色问题[ >黄色->红色。 目的是在客户通知 之前，将它们捕获为黄色并且 [时捕获它们。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) - -### 您的系统如何发展以应对新的扩展挑战？ - -我们已经多次重新构造了许多层。 我无法在本文中全部讲述，但我将尝试列出过去 7 年中核心元数据，存储，搜索层的几次迭代。 - -1. 版本 1：在 Lucene 中搜索文件元数据，通过 NFS 安装在 DRBD Filers 中存储的文件，在 Lucene 中搜索。 阻塞点 ：Lucene 更新不是实时的，必须替换。 - -2. 版本 2：Berkeley db 中的文件元数据，通过 NFS 安装在 DRBD Filers 中的文件，在 lucene 中搜索。 阻塞点 ：我们突破了 NFS 的限制，它左右左右都阻塞了，必须用 http 代替。 - -3. Version3：Berkeley db 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 lucene 中搜索。 阻塞点 ：即使分片的 Berkeley DB 在压力下也阻塞，并且数据库崩溃，恢复工作数小时，必须更换它。 - -4. 版本 4：MySQL 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 lucene 中搜索。 阻塞点 ：公共云开始变得便宜。 - -5. 版本 5：MySQL 中的文件元数据，存储在 EOS / GCS / S3 / Azure 中并通过 HTTP 服务的文件，在 lucene 中进行搜索。 阻塞点 ：搜索开始阻塞，必须更换。 - -6. 版本 6：MySQL 中的文件元数据，通过 HTTP 服务的 EOS / GCS / S3 / Azure 中存储的文件，在 Elasticsearch 中搜索。 这是当前的体系结构，很快，其中一个可能需要另一个轮回：)。 - -### 您是否使用任何特别酷的技术或算法？ - -* 在核心服务之间进行呼叫时，我们使用 [指数补偿](https://en.wikipedia.org/wiki/Exponential_backoff) 断路器，以避免断路器打雷。 - -* 我们在核心服务节点资源上使用公平分配分配方式来处理传入请求。 标记核心服务节点上的每个传入请求并将其分类为不同的组。 每个组都有专用的容量，如果一个客户每秒发出 1000 个请求，而另一个客户每秒发出 10 个请求，则此系统将确保第二个客户不会遇到嘈杂的邻居问题。 诀窍是，两个客户都可能由于哈希而巧合地落在某个节点上的同一组上，但他们不会降落在所有节点上的同一组上，因此我们将节点名称作为盐添加到哈希中。 - -* 带有 SLA 的某些核心服务被隔离在 POD 中，这确保了一个糟糕的客户不会阻塞整个数据中心。 - -* 我们在桌面同步客户端代码中使用基于事件的同步，因为发生服务器事件时，它们会从服务器推送到客户端，并且客户端会在本地重播它们。 - -### 您做什么工作是与众不同的，人们可以从中学到什么？ - -专注于启动的核心功能，如果必须构建定制的内容，那就去启动它。 有很多独特的东西，但是存储层，基于事件的同步绝对值得学习，这里有更多详细信息。 [Egnyte 对象存储库](https://www.egnyte.com/blog/2013/07/how-egnyte-implements-hybrid-object-stores-using-public-clouds-to-enhance-customer-experience/) 和 Egnyte [规范文件系统](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 - -## 您学到了什么？ - -* 您无法优化无法测量的内容：测量所有可能的结果，然后优化系统中首次使用 80％的部分。 - -* 当您身材矮小的时候，请慢慢介绍技术，不要试图从中找到解决当前问题的理想工具。 编码是生命周期中最容易的部分，但是如果您最初使用的技术太多，则其维护（如部署/操作/学习曲线）将非常困难。 当您很大时，您将有足够的脂肪来划分服务，并让每个服务使用其自己的技术并进行维护。 - -* 当您是一家初创公司时，有时您必须快速采取行动，介绍您现在可以做的最好的解决方案，如果看到牵引力，则应加班对其进行重新设计。 - -* 寻找单点故障，并不懈地寻找下来。 付出额外的努力来解决使您彻夜难眠的问题，并尽快从防御性转变为进攻性模式。 - -* 在 SOA 中，如果您的服务受阻，则构建断路器以开始发送 503s。 与其惩罚每个人，不如看看是否可以公平分配资源并仅惩罚滥用用户。 - -* 在服务使用者中添加了自动修复功能，服务可能会停止运行，桌面客户端或其他服务之类的消费者可以进行指数补偿以释放服务器压力并在该服务再次运行时自动修复。 - -* 始终可用：请客户提供服务级别的断路器和断路器。 例如 如果通过 webdav 或 FTP 访问文件系统存在性能问题，并且需要 4 个小时进行修复，那么在这 4 个小时内，您只需在防火墙处杀死 FTP / webdav 并要求客户使用 Web ui 或其他机制即可工作。 同样，如果一个客户引起了异常，使系统窒息，则可以暂时为该客户禁用该客户或服务，并在问题解决后重新启用它。 为此，我们使用功能标志和断路器。 - -* 保持简单：每个月都有新工程师加入，因此目标是从第一周开始就提高他们的生产力，简单的架构可确保轻松上岗。 - -### 您为什么成功？ - -牵引力胜过一切。 当 EFSS 市场刚刚爆发时，我们达到了 [产品/市场适合度](https://www.linkedin.com/pulse/marc-andreessen-product-market-fit-startups-marc-andreessen) 。 具有良好执行力的时机，管理团队的财务纪律导致成功。 许多竞争对手采用了免费增值模式，并筹集了大量资金，但是从第一天开始我们就开始收费，这使我们能够专注于根据市场需求发展解决方案/团队。 专注于付费客户使我们能够交付企业级解决方案，而无需支付免费增值罚金。 - -### 您希望自己做些什么？ - -我希望当我们开始时公共云的成本不会过高。 我也希望我们从第一天开始就使用 SOA，花了一些时间才到达那里，但是现在我们就在那里。 - -### 您不会更改什么？ - -目前，我不会替换 MySQL / EOS，因为它允许我们从防御性定位转到进攻性定位。 我不能在两年后发表评论，我会有相同的想法，我们可能会更改或扩大其中的一些想法。 当您遇到下一个增长突增时，架构会发生变化。 - -## 您应该做多少前期设计？ - -很好的问题。 答案是“取决于”， - -* 如果您要设计核心存储层或核心元数据层之类的东西，那么再多花 2 周的时间对您的设计不会有太大的影响。 当我们在核心元数据层上从 Berkeley DB 迁移到 MySQL 时，我承受着很大的压力，我曾想过要走捷径，当我通过首席技术官运行时，他建议花一些时间并“做正确的事”。 作为回顾，这是一个极好的决定。 - -* 对于公共 API，最好做一个不错的前端设计，因为您没有第二次机会对其进行更改，并且必须在未来 4-5 年内进行维护。 - -* 但是，如果您要为内部服务设计某些东西并将其迁移到新架构的时间不超过一年，那么我建议您进行非常少的前端设计，并快速构建版本并随着使用量的增长对其进行迭代。 - -## 您如何考虑将来更改架构？ - -* 在一周中进行部署（我们快到了） - -* 将更多公共云用于任何新服务，并将更多服务迁移到公共云。 - -* 将其余的源代码从 svn 移至 git - -* 使当前的开发环境尽可能接近生产环境（可以使用 docker 或…）。 - -* 自动化架构管理 - -* 添加更多性能基准测试 - -* 建立持续的交付渠道，以便我们可以将部署增加为每周或每天，而不是每两周一次。 - -* 通过重新构建从某些增长最快的表中删除联接。 - -* 为 Mysql 分片添加自动平衡器，因此我不必担心偶尔出现的热点。 - -* 将某些脂肪服务分成颗粒状 - -* 使用内存缓存代理 - -## 您的团队如何设置？ - -### 您的团队中有多少人？ - -大约有 100 名工程师（devops / ops / qa / developers / ...），其余的是销售，市场营销，支持和人力资源。 - -### 他们在哪里？ - -最初是分散的工程团队，但现在主要吸引人是孟买的 [波兹南](https://en.wikipedia.org/wiki/Pozna%C5%84) 。 一些像我这样的远程员工 和其他一些员工在家工作。 - -### 谁扮演什么角色？ - -这是一个很大的团队，我们有产品经理，UX 团队，开发人员，Scrum 团队，架构师，工程师扮演各种角色。 最初，工程团队很平坦，每个人都会向工程副总裁报告，但现在我们在两者之间增加了一层管理。 - -### 您是否有特定的管理理念？ - -如果您开发某些产品，那么您拥有该产品的生命周期，这意味着您将与 QA，devops 一起确保其测试/部署。 投入生产时，您可以使用各种内部工具（例如 New Relic / Nagios）对其进行监视，如果存在回归，则可以对其进行修复。 - -### 如果您有分散的团队，该如何工作？ - -自治，1-1 交流，黑客马拉松使他们具有挑战性，他们会受到激励。 - -### 您的开发环境是什么？ - -* 适用于服务器团队的 Ubuntu - -* UI 团队使用 Windows / mac 并连接到用于 REST API 服务器的本地 Ubuntu VM 或连接到共享的 QA 实例 - -* Eclipse /想法 - -* 适用于构建的 - -* Maven - -* Git / SVN - -* 詹金斯 - -* ReviewBoard / Sonar - -* JIRA - -* Google 文档 - -* Jabber / Slack / Hangouts / Skype - -### 您的开发过程是什么？ - -我们在服务器团队中使用 Scrum，并且每两周发布一次。 长期功能开发人员/团队在沙盒上工作，完成后通过单元测试/硒/手动 QA 对它进行测试，然后合并到主干以捕获 2 周的发布流程。 我们吃了自己的狗粮，代码在发布前 1 周发布到了 UAT（所有员工使用的 egnyte.egnyte.com），我们发现了自动化测试未发现的任何意外情况。 我们在每个星期五晚上进行生产部署，并且 [每天监视新文物，并针对任何异常](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 每天报告异常报告。 我们正在将部署更改为即将在一周中完成。 - -### 您有什么可以做的不同还是感到惊讶？ - -许多工程师在家工作，令人惊讶的是，有了自主权，许多远程员工像总部员工一样富有生产力和积极性。 - -## 您使用什么基础架构？ - -### 您使用哪种语言来开发系统？ - -大多数是 Java / Python - -### 您有多少台服务器？ - -最后，我知道我们有 700 多个。 100 多个 MySQL 服务器，50 多个 Elasticsearch，200 多个 tomcat 服务节点，300 多个本地存储节点，20 多个 HAProxy 节点和缓存文件管理器，nginx，python 服务器以及其他各种节点。 - -### 如何将功能分配给服务器？ - -我们使用面向服务的体系结构，并根据服务类型分配服务器。 一些顶级服务是： - -* 元数据 - -* 储存空间 - -* 对象服务 - -* Web UI - -* 索引 - -* EventSync - -* 搜索 - -* 审核 - -* 快照/数据监视器 - -* 内容智能 - -* 实时事件传递 - -* 文本提取 - -* 集成 - -* 缩略图生成 - -* 防病毒软件 - -* 垃圾邮件 - -* 预览版 - -* rsync - -* API 网关 - -* 结算 - -* 支持 - -* 销售 - -* 等等。 - -### 如何配置服务器？ - -大多数服务都是伪造的，并且可以在 VM 上运行，我们仅针对 MySQL，memcached，Metadata 服务器，索引之类的少数事物运行物理服务，但是除了数据库/缓存/存储节点之外，大多数服务都可以转换为 VM。 我们使用第三方根据模板来配置服务器，并将其放入数据中心，以供使用。 - -### 您使用什么操作系统？ - -CentOS7 - -### 您使用哪个 Web 服务器？ - -Nginx，Apache。 在一些旧的流程中使用了 Apache，但随着时间的流逝，它将被弃用。 - -### 您使用哪个数据库？ - -MySQL。 我们过去曾使用过其他数据库，例如 Berkeley DB，Lucene，Cassandra，但是由于开发人员/操作人员的熟悉程度和可伸缩性，我们将所有数据库都超时迁移到了 MySQL。 有关更多信息，请参见 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 - -### 您是否使用反向代理？ - -是 Nginx 和 HAProxy - -### 您是否并置，使用网格服务，使用托管服务等？ - -我们搭配。 - -### 您的存储策略是什么？ - -我们首先创建自己的服务器，然后在机器中打包尽可能多的硬盘驱动器，我们过去将它们称为 DRBD Filers。 我们这样做是因为 AWS 成本过高。 我们已经对 [GlusterFS](https://www.gluster.org/) 进行了评估，但是当时它无法扩展以满足我们的需求，因此我们构建了自己的。 加班 S3 变得便宜了，GCS / Azure 诞生了，我们将存储层设计为可插入的，因此现在客户可以决定要使用哪个存储引擎（例如，Egnyte，S3，GCS，Azure 等）。 - -### 您如何增加产能？ - -我们进行能力计划会议，并根据监控指标中的关键指标并预定一些额外的能力得出了一些指标。 现在，某些服务已启用云服务，我们只需单击一下按钮即可提供更多服务。 - -### 您是否使用存储服务？ - -是 Egnyte，S3，GCS，Azure 和 - -### 您如何处理会话管理？ - -我们多次重写了体系结构，目前 99％的服务是无状态的。 仅服务于 Web UI 的服务使用会话，我们在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性会话，但最终我的计划是使它也变得无状态 。 - -### 您的数据库是如何设计的？ 主从？ 碎片？ 其他？ - -我们对几乎所有具有自动故障转移功能的数据库都使用了 Master-Master 复制，但是某些严重变异的数据库的切换是手动完成的，我们遇到了一些问题，由于复制滞后，自动切换会导致应用程序数据不一致，我们 需要重新架构一些核心文件系统逻辑来解决此问题，我们最终将完成此工作。 下面是有关处理数据库升级的问题，详细回答了有关数据库体系结构的更多详细信息。 - -### 您如何处理负载平衡？ - -我们根据客户使用 DNS 访问系统的 IP 进行地理平衡，并在数据中心内使用 HAProxy 将其路由到相应的 POD，并在内部 POD 中再次使用 HAProxy 路由 - -### 您使用哪个 Web 框架/ AJAX 库？ - -我们已经多次更改了 UI，这是一直在变化的一件事。 过去我们曾经使用过 ExtJS，YUI，JQuery，而没有使用过。 最新的迭代基于 ReactJS / Backbone / Marionette 。 - -### 您使用哪种实时消息框架？ - -我们使用 [大气](https://github.com/Atmosphere/atmosphere) ，但最终我们将其替换为 NodeJS - -### 您使用哪个分布式作业管理系统？ - -为此，我们使用 RabbitMQ 和基于 Java / python 的消费者服务。 - -### 您的网站是否有标准 API？ 如果是这样，您将如何实施？ - -我们的 API 分为 3 种类型：- - -1. 公共 API： 这是我们提供给第三方应用程序开发人员和集成团队以及我们的移动应用程序的 api。 我们会按照适当的弃用工作流程弃用/升级 api 签名，并且更改始终向后兼容。 我们使用 Mashery 作为网关，API 记录在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) - -2. 适用于我们客户的 API： 此 API 对我们客户而言是内部的，如果我们以外的人使用此 API，我们不保证向后兼容。 - -3. 服务之间的内部受保护的 API ：这是服务在我们的数据中心内部用于彼此通信的 API，无法从外部防火墙调用。 - -### 您的对象和内容缓存策略是什么？ - -我们存储的数据为 PB 级，无法缓存所有数据，但是如果客户在给定的 15 天时间内拥有 5000 万个文件，则他可能只会使用其中的 100 万个。 我们有基于 tomcat / nginx / local 文件系统的缓存文件管理器节点，它以 LRU 方式运行。 我们可以弹性增加减少缓存文件服务器的数量。 我们最大的问题之一是上传速度，如何从世界任何地方尽可能快地将数据上传到 Egnyte，为此，我们建立了特殊的 Network pops，如果您好奇的话可以在阅读更多内容 [为 Egnyte 客户加速数据访问](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) - -Memcached 用于缓存元数据，我们使用单独的 memcached 池来缓存长期存在的静态数据和文件系统元数据。 核心文件系统元数据非常庞大，不适合当前的内存缓存节点，并且会逐出最近使用的其他类型的数据。 为防止这种情况，我们使用两种类型的池，应用程序代码决定在哪里查找哪种数据。 我们允许在文件系统内存缓存中逐出，并在其他种类的内存池中争取零逐出。 - -### 您的客户端缓存策略是什么？ - -对于我们的 Web ui，我们使用 PageSpeed 进行资源优化，缓存，并使用 requireJS 和其他各种方式仅下载所需的模块。 我们的 Mobile 和 Desktop 客户端丰富使用本地文件系统作为缓存。 - -### 您使用哪些第三方服务来帮助您构建系统？ - -Google BigQuery，New Relic，AppDynamics，MixPanel，Flurry，Tableau 是我们使用的一些分析服务，但大多数核心组件均由我们构建。 - -## 您如何管理系统？ - -### 如何检查全局可用性并模拟最终用户性能？ - -我们使用不同 AWS 区域中的节点来一致地测试带宽性能。 我们还使用内部 haproxy 报告来绘制客户观察到的上载/下载速度，并主动寻找它们，并使用网络弹出和其他策略来加速数据包。 - -![](img/6ffa16c86d1956a9ff0be037d6021022.png) - -### 您如何健康检查服务器和网络？ - -使用了 Nagios 监视器和 New Relic，以及一些内部主动式异常分析。 有关更多详细信息，请参见此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) - -### 如何绘制网络和服务器统计数据以及趋势图？ - -我们使用石墨，仙人掌，Nagios 和 New Relic，AppDynamics。 - -![](img/d7afc2042d53ba5302472ee5be116c5f.png) - -![](img/293ca1407b4f34397f578ec21c96afd2.png) - -### 您如何测试系统？ - -硒，Junit，鼻子，睡表和手动测试。 - -### 您如何分析效果？ - -AppDynamics 是 New Relic，用于监视生产 tomcat 节点的性能。 我们使用石墨/ nagios /内部工具和其他工具来监视系统其他部分的性能。 有关此问题的更多详细信息，请参见此博客文章 [分布式系统中的调试性能问题](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) - -### 您如何处理安全性？ - -专用安全团队在每个版本之前都会运行自动化的安全基准测试。 连续自动化笔测试已在生产中运行。 我们还使用漏洞赏金计划并与 Whitehat 测试公司合作。 一些客户使用第三方进行自己的安全性测试。 - -### 您如何处理客户支持？ - -我们有专门的 24X7 分布式客户成功团队，我们使用 Zendesk 和 JIRA - -### 您是否实施网络分析？ - -我们使用 Google Analytics（分析），Mixpanel，Flurry 来衡量功能使用情况 - -### 您是否进行 A / B 测试？ - -是的，我们使用功能标记进行 A / B 测试。 有关更多信息，请参见 [在 Egnyte 使用功能标志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) - -### 您要运行多少个数据中心？ - -3 个主要数据中心，其中一个在欧洲（由于安全港规定） ，网络遍布世界各地。 - -### 您的系统如何部署在数据中心中？ - -Puppet 用于部署大多数新代码。 我们仍在重写体系结构中最后要伪造的部分，而这些部分目前已使用 Shell 脚本进行了部署。 - -### 您使用哪种防火墙产品？ - -我们混合使用了瞻博网络 SRX 和 Fortigate 防火墙。 - -### 您使用哪个 DNS 服务？ - -PowerDNS - -### 您使用哪些路由器？ - -思科 - -### 您使用哪些开关？ - -Arista - -### 您使用哪个电子邮件系统？ - -我们使用自己的 SMTP 服务器来处理出站电子邮件，对于一些内部工具，我们使用 SendGrid，对于入站电子邮件，我们使用 GMail。 - -### 如何备份和还原系统？ - -对于 MySQL，我们使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，对于 Elasticsearch，该数据被复制 3 次，并且我们还使用 ElasticSearch GCS 备份插件将数据备份到 GCS。 对于客户文件，我们将其复制 3 次。 如果存储 Filer 无法恢复，我们将丢弃它，添加一个新 Filer 并再次复制副本。 对于某些客户，我们还会将其数据复制到他们选择的提供者。 对于使用 S3，Azure 或 GCS 作为可插拔存储层的客户，它将确保复制以防止数据丢失。 - -### 如何进行软件和硬件升级？ - -大多数节点是无状态的，并且有状态组件具有主动-主动故障转移。 通过将节点从池中取出并进行升级并将其放回池中来处理升级。 - -### 您如何处理升级中数据库架构的重大更改？ - -不同的服务使用不同类型的数据库，并且它们以不同的方式升级。 在 10000 英尺处，它们如下图所示： - -![](img/1de3f24a7fc5621b61d6e4e7ca1de358.png) - -1. EOS db 存储对象元数据并且增长非常快，它经过分片，并且我们将继续添加更多此类数据。 - -2. MDB 的增长速度更快，经过了分片，并且我们会继续增加更多。 - -3. DC_central 是 dns 数据库，并且保持相当静态。 我们运行了许多此副本以实现可伸缩性。 - -4. Pod_central 具有快速突变的数据，但每个表的增长量不超过 2000 万行。 我们运行了许多此副本以实现可伸缩性。 - -* 每个数据库模式始终是向前和向后兼容的，即我们绝不会在同一发行版中删除列和代码，我们首先在发行版 1 中部署停止使用该列的代码，在发行版 2 中两周后我们删除该列。 - -* 非分片数据库每 2 周更新一次。 它们是存储各种功能驱动表的表。 我们目前使用脚本升级它们，但现在已更改为使用 [Sqitch](http://sqitch.org/) - -* 使用自动脚本进行分片 db 新列更改 - -* 分片数据库迁移是一件痛苦的事情，因为我们有 7000 多个分片并且还在不断增长，您无法在 1 小时的升级窗口中完成。 方法是： - - * 实时代码根据需要迁移行。 这意味着迁移可能会持续数年。 - - * 使用功能标记进行迁移，您同时拥有新旧代码，并且在后台迁移客户，然后翻转标记以将其切换到新代码路径而无需停机，更多的是 [ [此处](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此处](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) - - * 当我们从 lucene 迁移到 ElasticSearch 时，除了重新索引所有内容外，我们别无选择，我们使用 [功能标记](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 进行了重新编码 -4 个月完成。 - -* 模式一致性检查器报告可确保升级后所有数据中心中的所有模式均相同。 - -### 您是否有单独的运营团队来管理您的网站？ - -是的，我们有一个专门的 devops 团队和一个 IT / Ops 团队，负责监视和管理系统。 - -## 其他 - -### 您欣赏谁？ - -AWS ：他们的创新步伐令人赞叹。 - -Google ：他们的工具，例如 BigQuery，Analytics（分析）都很棒。 - -Elasticsearch ：其余 api 的简洁性和架构都很棒。 - -MySQL： 即可。 - -Eclipse / Jenkins ：插件架构很好。 - -### 您是否模仿了其他人的公司/方法？ - -我们是 [http://highscalability.com/](http://highscalability.com/) 的常规读者，许多设计都受到它的启发。 - -* POD 架构的灵感来自 Tumblr 的 Cell 架构，虽然不完全匹配，但是隔离故障的概念是相同的。 - -* 受 Facebook 启发的架构在 12 小时后会在内存缓存和刷新键中产生抖动。 - -* 受 [http://highscalability.com/上一些文章的启发，将](http://highscalability.com/) [指纹添加到每个数据库查询](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) - -我们正在招聘，请在 [职位页面](http://www.egnyte.com/jobs/engineering.html) 中查看我们，并在 [与我们联系 [受电子邮件保护]](/cdn-cgi/l/email-protection) 。如果您有兴趣成为 [Egnyte](https://www.egnyte.com) 令人惊叹的团队的一员。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=11104555) \ No newline at end of file +与 Java 一起使用 MSXML 的优势如何？ \ No newline at end of file diff --git a/docs/27.md b/docs/27.md index 400b3ee..ae166ee 100644 --- a/docs/27.md +++ b/docs/27.md @@ -1,243 +1,54 @@ -# 如何使用微服务建立财产管理系统集成 +# FaceStat 的祸根与智慧赢得了胜利 -> 原文： [http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html](http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html) +> 原文： [http://highscalability.com/blog/2008/6/9/facestats-rousing-tale-of-scaling-woe-and-wisdom-won.html](http://highscalability.com/blog/2008/6/9/facestats-rousing-tale-of-scaling-woe-and-wisdom-won.html) -![](img/3331efa5e2d1a2cad2f4cfa4f1aeb70f.png) +![](img/22c8de6a3e84ae29ceb53be3ba538190.png) -*This is a guest post by Rafael Neves, Head of Enterprise Architecture at [ALICE](http://info.aliceapp.com), a NY-based hospitality technology startup. While the domain is **Property Management, it's also a good microservices intro.* 在零散的款待系统世界中，集成是必不可少的。 您的系统将需要与来自不同提供程序的不同系统进行交互，每个提供程序都提供自己的应用程序接口（API）。 不仅如此，而且当您与更多的酒店客户整合时，将需要更多的实例来连接和管理此连接。 物业管理系统（PMS）是任何酒店的核心系统，随着行业变得越来越紧密联系，集成至关重要。 +卢卡斯·比瓦尔德（Lukas Biewald）分享了一次令人着迷的[大满贯，他的](http://www.lukasbiewald.com/?p=153) [FaceStat](http://facestat.com/) 网站（上传图片并由大众判断）如何被 Yahoo 的链接重击 导致其网站上几乎瞬间出现 650,000 页浏览量跳升的主页。 雅虎花费了大量的精力来确保自己的属性能够处理来自主页的真正大量流量。 将 Internet 的[大眼睛](http://www.poster.net/lord-of-the-rings-ii/lord-of-the-rings-ii-eye-of-sauron-4900244.jpg)转向毫无疑问的新生儿站点，一定是尿布准备就绪的体验。 Theo Schlossnagle 在[中对这些事件进行了怪异的预言，因为标点符号对网站体系结构的影响](http://highscalability.com/implications-punctuated-scalabilium-website-architecture)：随着变化无常的互联网寻求新的娱乐方式，大规模，意外和突然的流量高峰将变得更加普遍（我的摘要）。 完全是 FaceStat 的情况。 -为了在酒店业提供软件解决方案，您肯定需要与 PMS 提供者建立 2 路集成。 挑战在于大规模建立和管理这些连接，并在多个酒店中使用多个 PMS 实例。 您可以采用几种方法来实现这些集成。 在这里，我提出一种简单的架构设计来构建集成基础，随着您的成长，该基础将增加 ROI。 这种方法是微服务的使用。 +这也是我们首次使用 Ruby on Rails 竞争对手 Merb 编写的应用程序。 对于那些认为 Ruby 是问题的人，他们的体系结构现在提供的服务是原始负载的 100 倍。 -## 什么是微服务？ +我们出色的 FaceStat 研究金如何抵御 Yahoo 的猛攻？ -企业软件设计思想领袖 Martin Fowler 提供了微服务的全面定义[：](http://martinfowler.com/articles/microservices.html) +关于 FaceStat 架构的详细信息并不多，因此不是这样。 让我感兴趣的是，这是 Theo 流量高峰现象的及时例子，而我也被团队处理挑战的能力吸引了我。 很少有人能这么快做得更好。 -> 在过去的几年中，出现了“微服务体系结构”一词，用于描述将软件应用程序设计为可独立部署的服务套件的特定方式。 尽管没有这种架构样式的精确定义，但围绕业务能力，自动部署，端点中的智能以及对语言和数据的分散控制，组织周围存在某些共同特征。 +实际上，让我们将 Theo 的规则应用于如何处理这些情况到 FaceStat： -本质上，微服务是很小的软件组件，专注于真正做好一件事情。 不必编写一个大型的整体应用程序，而是可以使用微服务将其分解，每个微服务在给定的域中管理一个集中的功能。 +* **保持警惕：构建自动化系统，以快速（不到 60 秒）检测并查明这些问题的原因。** 最初没有，但他们正在建立更多的监视以更好地处理未来情况。 更好的监控会在问题真正被警告之前很久就使他们警觉到问题。 也许更多的潜在客户可能已转换为实际客户。 您将永远无法获得足够的监控！* **做好准备：系统地了解服务的瓶颈。** 由于系统相对简单，新颖且变化迅速，我的假设是他们完全意识到系统的缺点，他们只是在忙于添加功能，而不用担心性能和可伸缩性。* **执行分类：了解组成您的网站的各种服务的重要性。** 肯定。 为了响应负载，他们“开始淘汰所有数据库密集型功能”。* **保持冷静：任何未经分析驱动的动作都是在浪费时间和精力。** 从以下引言中可以看出，它们保持了惊人的镇定：“可伸缩地编码并在增加的负载下缓慢增长是一回事，但疯狂地重新构建诸如 FaceStat 之类的活动站点是一整天的事情。” 我不确定他们是如何进行分析的。 -因此，它们是自治的，彼此独立执行。 因此，对一项服务的更改不应要求对另一项服务的更改。 随着您的成长和进行更改，您无需担心会影响其他微服务。 + 总的来说，这是对 Great Eye 始终如一的关注的令人印象深刻的回应。 -微服务是： + 但并不是所有人都给我留下深刻的印象。一位名叫 Bernard 的评论员说：*很抱歉，但这真是一个愚蠢的故事。 考虑到诸如 slicehost 和 linode 这样便宜的东西，发疯了，您启动了一个 Web 应用程序并且还没有准备好冗余的，高度可伸缩的体系结构……我要说您很遗憾，失望的用户终于回来了。* -* 小 -* 专注于 -* 松耦合 -* 高内聚性 + 评论员将认为这是一个“很好的问题！” 当然，被注意到比被忽略更好。 但是 Lukas 感到遗憾的是，当他为过早注意到而感到遗憾时有一个缺点：*在努力吸引用户访问您的网站后，令人惊讶的是，看到成千上万的人突然被封锁。* -## 为什么微服务功能强大 + 显然，开发人员无法像创建探索性系统那样简单地创建可伸缩系统。 来自 Rackspace 的 Ed 表示，他们可以帮助他们实现阵列自动缩放功能。 而 Rackspace 将是一个很好的解决方案，但费用为每月 500 美元和 2500 美元的安装费。 没有任何一家“放映秀”的创业公司能够承担这些费用。 FaceStat 所处的模式是典型的：*我们发现，类似于 Rails 的平台对于快速建立新站点的原型非常有价值，尤其是因为我们将 FaceStat 作为纯粹的实验开始时却不知道人们是否喜欢它，并且 与后来的功能相比，这是一个非常不同的功能。* -微服务架构提供了很多好处。 主要优点包括： + 渐进式付费模型对于可伸缩性至关重要，因为这是一开始就可以增强可伸缩性的唯一方法。 即使该行业取得了令人瞩目的进步，我们仍然没有使扩展成为第二性质的软件基础架构。 -### 可扩展性 + ## 信息来源 -* 您的单个系统将与具有不同属性的多个 PMS 实例集成。 从规模上讲，当与 1000 个属性进行集成时，即使它们正在运行来自同一供应商的相同 PMS 系统，您也需要显式管理不同的 1000 个集成。 为了增加复杂性，这些实例可以来自不同的提供程序。 -* 随着您添加许多 PMS 实例和属性，它可以优雅地扩展。 如果您使用的是整体应用程序，则必须将所有内容扩展为一个大块。 在流量高峰期间，可能很难理解性能瓶颈在哪里，而对于微服务而言，透明度要高得多。 -* 当您拥有微服务时，很清楚哪些服务存在性能问题，您可以轻松调整其容量（底层硬件），而不必增加运行正常流量负载的其他服务的容量。 + * [快速扩展](http://www.lukasbiewald.com/?p=153)，作者：Lukas Biewald* [FaceStat scales!](http://blog.doloreslabs.com/2008/06/facestat-scales/) on Dlores BLog -### 弹性 + ## 平台 -* 旅馆中的 PMS 实例可能已关闭或出现性能问题，这不会影响系统的性能或正常运行时间。 -* 您可以实现任意数量的微服务。 部署的次数越多，容错和对更改的管理就越多。 + * [Merb](http://merbivore.com/) 。 与 ORM 无关的基于 Ruby 的 MVC 框架。* [薄](http://code.macournoyer.com/thin/)。 快速，简单的 Ruby Web 服务器。* [Slicehost](http://www.slicehost.com/) 。 托管服务。 能够根据需要快速配置服务器。* [亚马逊的 S3](http://en.wikipedia.org/wiki/Amazon_S3) 。 图像服务器。 延迟很高，但可以处理负载。* [Capistrano](http://capify.org/) 。 自动化部署。* [Git](http://git.or.cz/) 和 [github](http://github.com/) 。 源代码控制系统。 支持高效的同步开发，快速合并和部署。* [上帝](http://god.rubyforge.org/)。 服务器监视和管理。* [Memcached](http://www.danga.com/memcached/) 。 应用程序缓存层。* [PostgreSQL](http://www.postgresql.org/) -### 技术堆栈独立性 + ## 统计资料 -* 您可以具有多个技术堆栈； 每个服务都将拥有最适合的技术堆栈。 您的访客配置文件可能在关系数据库中，而他们的请求可能在 NoSQL 数据库中。 -* 对特定技术栈没有长期的承诺； 毕竟，您可以拥有多个。 + * 六个应用服务器。* 一台大型数据库机。 -### 添加，更改或取消功能&重构 [ + ## 架构 -* 微服务非常小（通常只有几百行代码）。 -* 由于代码具有内聚性，因此更容易理解：它可以做一件事。 -* 对其所做的更改不会直接影响其他服务。 -* 删除整个微服务更容易，并且不会对整个系统造成风险 + * FaceStat 是一个写繁重的应用程序，并且对数据执行涉及的计算。* S3 用于减轻存储图像的责任。 这使他们摆脱了巨大的带宽需求和管理自己的图像的复杂性。* Memcached 卸载了对数据库的读取，以使数据库有更多时间进行写入。 -### 部署方式 + ## 得到教训 -* 酒店希望提供卓越的服务。 如果您的系统已关闭或未提供其所有功能（例如，不将来宾入住请求推送到您的 PMS 或从中读取更新），他们将无法交付。 -* 回滚也更容易。 如果出了什么问题，回滚一个带有自己数据库的微服务要比回滚一个单个数据库的整个系统要容易。 -* 部署单片应用程序的下一版本时，总是很麻烦：即使您仅添加了一个功能，也必须立即部署整个应用程序。 一起部署所有内容都是有风险的。 ， + * **监视站点**。 您越早知道问题，可以更快地解决它。 不要依赖用户电子邮件或来自异常处理程序的电子邮件，否则您将永远无法解决问题。* **通过错误页面**与您的用户通信。 有意义的错误页面显示您正在关心并且正在解决问题。 对于大多数人来说，第二次机会就足够了。* **使用缓存的静态生成的首页**。 很难击败它的性能。* **大型网站在提及较小的网站**时可能要提请注意。 只要有一封简短而礼貌的电子邮件，说明您的世界很快就会倒过来，就可以了。* **与整体架构**相比，高级平台确实没有关系。 处理写入，读取，缓存，部署，监视等的方式相对独立于框架，这是解决重要问题的方式。* **Ruby 和 Merb** 支持快速原型设计，以实验和创建与他们想要的系统完全不同的系统。 -请记住，如果仅集成一个 PMS，则微服务是一个过大的杀伤力。 如果要与具有 1000 个不同属性的 1000 个 PMS 实例集成，那么该体系结构的好处就显而易见了。 +据博客称，这并不奇怪，因为他们正在 VPS 上运行 FaceStat。 -## 传统方法：单片应用程序 - -借助传统方法（整体应用程序）开始您的业务并开始新产品是很有意义的，因为它更容易。 目前，您仍在学习域以及域如何集成。 - -整体更易于开发和部署，采用整体方法，则更容易回答诸如如何建模预订服务以及如何在访客配置文件微服务中实现访客对帐操作之类的问题。 - -但是，就像您的公司一样，整体式增长非常迅速，并且随着系统的增长，很难扩展： - -添加了新功能，推出了新的代码行，并且当系统变得太大时，它变得难以驯服和理解。 更改系统需要进行严格的回归测试，以确保新功能不会破坏系统的其他部分，因为整体应用程序通常不具有内聚力，也没有松散耦合。 - -故障排除和调试更加困难，因为存在更多具有更多相互依赖性的代码。 更新服务可能需要更改共享的基础结构代码，并且在引入错误时可能导致感染。 庞大的代码库使新手开发人员难以入职和培训。 - -它影响部署：应用程序越大，启动时间就越长。 是的，您可以简单地添加更多服务器并在所有服务器上复制应用程序，但是您仍然只有一个数据库。 不仅如此，系统的某些部分可能会更占用内存，而其他部分则需要大量 CPU。 那么，当您无法分别缩放每个组件时该怎么办？ 您添加更多服务器！ - -这是非常昂贵的。 这样，一旦您对域有了更好的了解，就可能想要开始将系统分解为微服务。 - -## 架构概述 - -现在，我们已经解释了采用微服务架构的长期好处，让我们研究一下如何设计此微服务框架的一些细节： - -这里的关键是隔离：集成的系统应该彼此独立运行。 IE：您的核心系统独立于在属性 X 上运行的属性管理系统，并且独立于在属性 Y 上运行的系统。 - -通过在核心系统和要与之集成的所有资产管理系统之间引入连接器（中间件），可以实现这种隔离。 - -中间件由消息队列和后台工作者组成： - -* 可用于实现的服务示例： - * 消息队列：RabbitMQ，IronMQ 等。 - * 背景工作者：IronWorker，AWS Lambda 等。 - -消息队列提供系统之间的异步通信。 发件人系统（例如您的系统）将消息发布到队列中，并一直位于该队列中，直到后台工作人员（订阅该队列）在以后处理该消息为止。 - -然后，后台工作人员负责处理消息（解析其内容），然后管理与 PMS API 的集成。 同样，它将数据保存到中间件数据库中。 - -请记住，后台工作程序可以是像 AWS Lambda 这样的云服务，也可以是内部用 Java 开发的应用程序，也可以是在 Windows 服务中开发的应用程序。 正如我们将在下面详细介绍的那样，微服务的技术堆栈并不重要。 - -请记住，一个消息队列保证 FIFO（先进先出），因此队列中的所有消息都按照它们进入的顺序进行处理。如果您有多个队列，则将一条消息发布到队列中 可以比发布到队列 Y 的消息更早地处理 X，这在您的设计中应予以考虑。 - -另外，虽然 PMS 可能位于酒店的内部，但您的系统也不一定要位于云中或内部。 - -请记住，此服务控制与预留关联的所有生命周期事件，因此它不仅是 CRUD 包装器。 如果您需要为该预订分配房间，添加陪同客人或什至办理入住手续，则可以将适当的请求发送给该同一工作人员。 - -现在让我们根据 Martin 的描述来分析微服务的每个主要特征，以及我们的架构如何实现它们： - -## 1-围绕业务能力的组织 - -每个工作人员都实现了如何与 PMS 集成的逻辑。 您可以将多个工作人员插入到属性中的同一 PMS 实例中，在其他酒店中添加更多连接到同一属性管理系统（同一供应商）的工作人员，还可以在以下位置添加连接到不同属性管理系统（不同供应商）的其他工作人员 其他属性。 - -因此，假设您需要更改与某些 API 方法的交互方式，则只需将新版本部署到其中一个工作程序，而不会影响其他工作程序。 您可以让一个工人来处理预订，另一个可以来宾。 - -可以在 Linux crontab 中安排一些后台工作程序，以按照给定的时间表重复执行。 其他消息始终在运行，在到达队列时处理消息。 其他后台工作人员也可以回调您的核心系统 API，以插入或更新从 PMS 收集到的新信息（即从 PMS 中获取/读取数据并将其加载到您的核心系统中）。 - -在萨姆·纽曼（Sam Newman）撰写的 *Building Microservices* 一书中，他指出“从事较小代码库的较小团队往往生产力更高。”这是通过微服务实现的 - -它不仅可以提高生产率，还可以使团队或个人从一种微服务转移到另一种（通用共享代码库）。 - -它也可以促进创新，因为长时间从事同一项目的个人或团队可能只会提出有限范围的新想法。 而如果您允许您的团队在产品和项目之间切换，他们可能会提出成千上万个新想法。 - -## 2-自动部署 - -微服务需要以自动化方式进行部署。 为什么？ 首先，因为您有很多。 如果必须手动部署它们中的每一个，这将很容易出错并且非常耗时。 这取决于您拥有的微服务数量。 您可以彼此独立地分别释放每个服务。 - -请注意，我的意思是在此处将新版本部署到微服务，而不是分解新的工作程序实例。 您已经在运行工作程序，但是您想部署新版本的代码。 让我们用一个例子说明一下： - -* 假设您必须与 1000 个属性集成，其中 500 个属性使用供应商 1（PMS_1）的 PMS，其中 500 个属性使用供应商 2（PMS_2）的 PMS。 -* 由于无论 PMS 供应商如何，这里的域上下文都非常相似，因此每个 PMS 实例将很可能具有相似数量的工作线程，除非您想通过添加更多相同类型的工作线程来扩展给定的连接。 简单来说，假设每个 PMS 实例有 5 个工作线程（一个用于保留，一个用于来宾配置文件，等等）。 -* 由于 PMS_1 API 与 PMS_2 API 不同，因此与 PMS_1 集成的保留服务的代码与与 PMS_2 集成的保留服务的代码不同。 -* 在 1000 个属性上，您有 5000 个工作人员，然后： - * 2500 名 PMS_1 员工 - * 500 名预订工人，每个属性中带有 PMS_1 的一名 - * 500 位访客资料工作人员，每个属性中带有 PMS_1 的一名 - * 500 名 X 工人，每个资产带有 PMS_1 的一名工人 - * 500 名 Y 工人，每个属性为 PMS_1 的工人 - * 500 名 Z 工人，每个属性中带有 PMS_1 的一名工人 - * 2500 名 PMS_2 员工 - * 500 名预订工人，每个属性为 PMS_2 的一名 - * 500 位访客资料工作者，每个属性中带有 PMS_2 的一名 - * 500 名 X 工人，每个资产带有 PMS_2 的一名工人 - * 500 名 Y 工人，每个属性为 PMS_2 的工人 - * 500 名 Z 工人，每个资产中带有 PMS_2 的一名工人 -* 假设您对与 PMS_1 集成的 Reservation 服务的代码进行了更改，它已经过测试并且可以发布。 -* 假设您有一个源代码存储库，并且每个微服务都内置有您选择的持续集成工具，这是非常明智的选择，那么您需要将代码部署到 500 个工作程序（与 PMS_1 集成的 500 个保留工作程序）。 - -其次，微服务的目的之一是要具有敏捷性，并且要具有敏捷性，您需要自动化。 这就是持续集成（CI）和持续交付（CD）的神奇之处： - -CI 是一种开发实践，要求开发人员一天几次将代码集成到共享存储库中。 然后，提交触发构建。 如果构建失败，则每个人都会收到警报（原则上会发出偏差警报）。 此处的关键是尽早确定提交问题（即代码问题）。 如果构建成功，则可以将其部署到您的应用程序服务器。 这导致我们实现持续交付： - -连续交付是确保成功构建的工件可以快速部署到生产中的一种做法。 这是通过首先将您的应用程序部署到暂存环境（具有与生产环境相同的特征）来实现的。 只需按“部署”按钮，就可以将应用程序部署到您的生产环境中。 最好的是，因为它只是一个按钮，所以您无需中断软件工程师的工作。 - -* 可用于实现 CI / CD 的服务示例：Atlassian Bamboo，TeamCity，Jenkins 等。 - -虽然，请不要将持续交付与持续部署混淆。 我不会在这里详细介绍它，但是我会留下 PuppetLabs 的[很棒的文章](https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff)来介绍持续交付和持续部署之间的区别。 - -还应注意，微服务的部署要比单片应用程序安全得多，这应有助于自动化。 - -## 3-端点的智能 - -后台工作人员封装了如何与 PMS 集成的逻辑。 如果我们需要更改逻辑或 PMS API 已更改，我们只需要在一个地方进行更改-它不在您的主系统中（将其与对下游 API 的更改隔离开来）。 - -另外，每个 PMS 都有自己的 API，因此您可以隔离与核心系统中的每个 API 进行通信的逻辑。 - -## 4-语言和数据的分散控制 - -每个微服务可以拥有自己的技术堆栈。 让您拥抱技术的异质性。 - -例如：如果我们需要提高特定组件的性能，则可以选择能够实现所需性能的其他技术堆栈。 新服务不依赖于较早的技术定义，而是在适当时利用新的语言或技术。 - -每个工作程序可以使用不同的技术构建：工作程序 1 可以使用 Java 开发，带有 MySQL 数据库以处理来宾配置文件，而工作程序 2 可以使用 C＃开发，具有 NoSQL DB 来处理来宾消息。 记住：他们是独立的。 - -您需要担心它们的集成，即它们之间如何实际通信。 您将实现返回 JSON 的 RESTful API 还是使用 XML 的 SOAP API？ - -现在，让我们更深入地研究中间件。 - -## 中间件 - -中间件提供了系统与要集成的多个属性管理系统之间的隔离。 它由消息队列和后台工作者组成。 - -中间件不应保持状态：两端的系统（即您的系统和 PMS 系统）负责保持有关酒店，访客资料，预订等的状态。中间件只是在两者之间创建映射。 这样做的原因是，您不想引入一个新的组件，该组件还存储可能导致一致性问题的状态：您将在 3 个不同的系统（酒店物业管理系统）中存储相同的实体（例如，预订）。 ，中间件和核心应用程序），并且由于集成中的某些错误，它们可能会有所不同。 在这种情况下，谁持有关于保留真实有效状态的真相？ - -中间件必须提供允许您协调核心系统中的内容与 PMS 中的内容的方法。 因此，如果在核心系统中创建了新请求，但是由于某种原因（实例处于脱机状态，软件错误，网络问题等），则该请求未保存到 PMS 中（例如，向来宾作品集收费） ），中间件应提醒用户该问题并提供重新处理集成的方法。 它必须清楚地显示每条消息在队列中的位置以及每个后台工作人员的状态。 它必须允许您查看给定消息失败及其失败的原因，并提供重试（重新处理）给定消息的机制。 - -您可以在中间件数据库的顶部具有一个缓存层，以便更快地访问常见对象，例如城市代码，信用卡类型等。 一些财产管理系统将此作为具有键-值对的枚举来实现。 可用于提供缓存层的工具示例包括：自托管的 Redis，托管的 Redis 解决方案（例如 AWS Elasticache），Memcache。 - -## 使用微服务的挑战 - -在构建任何软件时，尤其是在大规模集成系统中，总是存在挑战。 - -纽曼在《构建微服务》一书中提醒我们，“故障成为大规模的统计确定性”，而在实现微服务时（这是整体的）肯定是这种情况。 - -接受一切都会失败（硬盘，网络等）并接受这一事实，很难处理多个独立服务的失败。 - -分布式和异步体系结构难以实现且难以调试。 您需要查看散布在多个实例中的日志，并查看分布式事务性，以了解为什么最终会出现古怪的状态。 如果在同步工作流的中间发生错误，则很难回滚状态。 了解故障发生的位置非常困难，因为工作可能并行进行，并且可能引入了难以管理的竞争条件。 - -确保与微服务的大规模一致性是另一个挑战。 想象一下，您有一个管理来宾个人资料的服务，另一个服务来管理预订。 如果新客人首次在您的酒店预订了预订，则预订微服务将创建新的预订记录，而客人资料微服务将需要创建新的客人资料。 如果访客个人资料存在错误并且未成功创建新的访客个人资料怎么办？ 如果管理不正确，最终将导致一个孤立的预订，该预订未绑定到任何访客个人资料。 从规模上讲，这可能很难跟踪和管理。 - -异步分布式体系结构可能会导致其他问题。 让我们想象一下系统发送到事务处理队列的某种类型的请求会使您的工作人员崩溃。 另外，假设您添加了多个工作程序，它们从同一队列中提取消息以加快处理速度。 第一个工作人员从队列中提取消息，然后死亡。 当它死亡时，对请求的锁定将超时，并将原始请求消息放回到队列中。 然后，您的下一个工作人员将从队列中提取相同的消息并获得相同的结果：消息将死亡。 - -另一个挑战是，您将不得不监视不断重新部署的数百种服务。 这将促使需要专用的 DevOps 资源或团队来管理大量服务。 - -您还需要考虑整体系统性能，因为您有很多通过网络进行的远程呼叫。 众所周知，网络不可靠：数据包可能会延迟，丢失等。此外，系统之间的消息不是实时流动的：您将消息发布到队列中，然后在（ 不久），它将得到处理。 - -最后，使用微服务很难有效地实现版本控制：您最终将更改服务的接口。 您将如何处理？ - -使用每种架构方法都需要权衡。 尽管微服务存在挑战，但每种方法都存在挑战。 当大规模管理多个 PMS 集成时，使用微服务的好处远远超过成本。 - -**考虑大规模实施的经济性：** - -以下是实现微服务时要考虑的一些比较成本： - -* 大规模部署时，100 个不同的 PMS 集成可能需要 100 个服务器。 -* 使用单片方法，这些服务器始终处于运行状态。 -* 在微服务世界中，微服务在需要时唤醒，在不需要时关闭。 -* 借助 AWS Lambda 或 IronMQ 等云服务，您需要为 CPU 时间而非服务器时间付费。 -* 当采用按需供应系统（如 Amazon Web Services 提供的系统）时，我们可以根据需要对需要的那些组件应用此扩展。 这使我们能够更有效地控制成本。 ， - -因此，随着时间的流逝，微服务在为计算能力付费时会更具成本效益，因为有需求可以使您更紧密地管理成本并最终减少浪费。 很少有一种架构方法可以与几乎立即节省成本紧密相关。 - -那么，从这里去哪里呢？ - -## 拆解整体结构 - -我经常听到的一个常见问题是：“我已经构建了单片应用程序。我是否需要从头开始重新构建它以实现微服务架构？” - -简短的答案是：**否**。 - -长的答案是，您可以将您的整体碎片分开。 它应该是一种渐进的方法，以便您可以了解有关核心功能以及它如何与其他核心功能交互的更多信息。 这对于您了解服务应该是什么以及它们如何相互通信至关重要。 采取“边走边学”的方法，逐步定义系统的哪些部分应成为微服务。 我将在以后的文章中保留有关如何设计和实现此策略的详细信息。 - -我希望这可以解释其好处或使用微服务方法来构建 PMS 集成。 随着您的系统和微服务数量的增长，这种方法将帮助您以更灵活，高效和经济高效的方式进行扩展。 - -## 相关文章 - -* [关于 HackerNews](https://news.ycombinator.com/item?id=11074151) -* [微服务-不是免费的午餐！](http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html) -* [伟大的微服务与 Monolithic Apps Twitter 近战](http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html) -* [来自 Google 和 eBay 的关于建立微服务生态系统的深刻教训](http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html) -* [生产中的微服务-好的，坏的，有效的](http://highscalability.com/blog/2014/10/27/microservices-in-production-the-good-the-bad-the-it-works.html) -* [微服务中最讨厌的七个反模式](http://highscalability.com/blog/2015/8/3/seven-of-the-nastiest-anti-patterns-in-microservices.html) -* [改变一切的融合：数据重力+容器+微服务](http://highscalability.com/blog/2015/3/25/the-convergence-that-changes-everything-data-gravity-contain.html) -* [我们如何构建更好的复杂系统？ 容器，微服务和持续交付。](http://highscalability.com/blog/2015/4/27/how-can-we-build-better-complex-systems-containers-microserv.html) - -诸如此类的技术是使物业管理更加有效和高效的好方法。 我们希望将来能看到更多诸如此类的技术创新。 感谢您分享本文，这是设置此集成的不错的教程。 \ No newline at end of file +如此，确实有人说对了，“知识就是智慧” +----- +[http://underwaterseaplants.awardspace.com”](海洋植物 +[http ：//underwaterseaplants.awardspace.com/seagrapes.htm“](海葡萄... [http://underwaterseaplants.awardspace.com/seaweed.htm”](海藻 \ No newline at end of file diff --git a/docs/28.md b/docs/28.md index 5849748..87781bf 100644 --- a/docs/28.md +++ b/docs/28.md @@ -1,29 +1,7 @@ -# Tinder：最大的推荐引擎之一如何决定您接下来会看到谁？ +# Flickr 的联合会：每天进行数十亿次查询 -> 原文： [http://highscalability.com/blog/2016/1/27/tinder-how-does-one-of-the-largest-recommendation-engines-de.html](http://highscalability.com/blog/2016/1/27/tinder-how-does-one-of-the-largest-recommendation-engines-de.html) +> 原文： [http://highscalability.com/blog/2008/7/9/federation-at-flickr-doing-billions-of-queries-per-day.html](http://highscalability.com/blog/2008/7/9/federation-at-flickr-doing-billions-of-queries-per-day.html) -![](img/2688e3c8765d8fadc182017986ce3866.png) +Flickr 独行的数据库专家 Dathan Pattishall 出色地介绍了 Flickr 如何扩展后端以处理巨大负载。 一些信息可以在 [Flickr Architecture](http://highscalability.com/flickr-architecture) 中找到，但是该论文非常好，值得再次阅读。 如果您想查看正确完成的分片，请看一看。 -我们已经听到很多关于电影的 Netflix [推荐算法](http://www.wired.com/2013/08/qq_netflix-algorithm/)，[亚马逊](https://www.cs.umd.edu/~samir/498/Amazon-Recommendations.pdf)如何与您匹配的东西，以及 Google 臭名昭著的 [PageRank](https://en.wikipedia.org/wiki/PageRank) 的信息。 Tinder 呢？ 事实证明，Tinder 具有令人惊讶的深思熟虑的推荐系统来匹配人员。 - -[（刷卡）先生，对吗？](https://story.californiasunday.com/sean-rad-tinder) ，在 Tinder 创始人 Sean Rad 上： - -> 根据 Badeen 所说，用户的目标是让他们忘记三秒钟之内被刷过的人。 但是 Tinder 没有。 他们研究成员滑动的对象，匹配对象。 然后他们看“重新激活”。 年轻的用户将消失几周，然后“重新激活”，或再次开始刷卡。 年长的用户花更多的时间查看各个个人资料，并且很可能在重新激活之前消失了几个月。 古尔德说，平均活跃用户每天在 Tinder 上花费一个小时。 （拉德说他上瘾了，花了无数小时来刷卡。） - -> 邻里模式往往是独特的。 即使是城市中不同街区的人，也会有不同的举止或匹配的可能性。 古尔德说：“人们自然在地理上对自己进行分类。” 如果人们旅行，他们的行为也会发生巨大变化。 **“我们了解了一个人的全部知识，”古尔德说，“然后他们去了另一个地方，采取了完全不同的行动**。 古尔德（Goul）负责调整算法，该古尔德的头发偏斜一些，衣服比 Rad 和 Badeen 的宽松一些。 也就是说，比赛不是偶然发生的。 Tinder 正在安排您接下来要看的人。 **拥有数十亿个匹配项，因此拥有大量数据**。 Rad 说：“我们可能是世界上最大的推荐引擎之一。” - -> **首先，古尔德告诉我，该应用程序的统治类别为“匹配的 1％，**”，这些人获得了大量的比赛，并且使其他所有人看起来都比较糟糕。 Tinder 决定**改变趋势，减少显示**的配置文件，特别是向不在 1％范围内的用户展示。 现在，显示出很多向右滑动（是）的人逐渐减少的人，而得到了很多向左滑动（否）的人逐渐表明的人越来越多。 “我称之为累进税制-重新分配比赛。 他们并不是真正要重新分配的人，但我们会尽力而为。”古尔德说。 “这样做是正确的。” **该公司将其称为“智能匹配”：通过平衡游戏环境并确保不太可能获得匹配的成员获得一些东西，从而在约会世界中赢得正义。** “人类状况的一部分是斗争。 如果您除了“维多利亚的秘密（Victoria's Secret）”模特外什么都看不到，那就不一定要脱颖而出。” “当我们介绍不适合您的人时，就会着重强调那些人。 比赛不是偶然发生的。 Tinder 正在安排您接下来要看的人。 - -> **他们还更改了不良演员的系统，限制了每天刷卡的次数**。 古尔德说：“我们以前有一群人会向每个人正确滑动，然后不回应，所以我们增加了一个限制，以发现未玩游戏的人。” “我很惊讶，但是人们实际上很聪明。 他们发挥自己的才能。 在最初的几天里，这些家伙不断达到极限。 然后，在那之后，他们开始适应。 一旦完成，对话时间就会更长。 - -> **Gould 和 Badeen 将这些干预视为道德义务**。 Badeen 说：“知道它会对人们产生多大的影响，这很令人恐惧。” “我尝试忽略其中的一些，否则我会发疯。 我们正处于对世界负有社会责任的地步，因为我们具有影响世界的能力。 - -> Gould 回应了这一观点：“听着，建筑师设计的建筑物设定了人们的生活方式。 城市规划人员设置城镇和道路。 作为帮助人们约会的系统的设计者，我们有责任建立这些背景-我们每年都要为这个星球上相当比例的婚姻负责。 这是一种荣誉和责任。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=10981314) - -它与高可扩展性有何关系？ - -我当然喜欢技术细节，但是我发现这些与政策相关的见解也很重要。 它比我预期的要更加周到和复杂，并且有趣地使用大数据来朝着目标导向的方向推动产品的使用。 - -因此，他们有社会责任限制每天比赛的次数，但是如果您为服务付费，您仍然可以做到吗？ 他们的道德晴雨表似乎有问题。 \ No newline at end of file +优秀的阅读！ \ No newline at end of file diff --git a/docs/29.md b/docs/29.md index 223ea6c..7006ab0 100644 --- a/docs/29.md +++ b/docs/29.md @@ -1,97 +1,76 @@ -# TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件 +# EVE 在线架构 -> 原文： [http://highscalability.com/blog/2020/6/15/how-triplelift-built-an-adtech-data-pipeline-processing-bill.html](http://highscalability.com/blog/2020/6/15/how-triplelift-built-an-adtech-data-pipeline-processing-bill.html) +> 原文： [http://highscalability.com/blog/2008/10/22/eve-online-architecture.html](http://highscalability.com/blog/2008/10/22/eve-online-architecture.html) -![](img/1963d0fe5c064f572a5ce7f6a9647f17.png) +*抱歉，这篇文章的内容显然没有从旧的 HighScalability 网站过渡，这一切都弄糟了，但仍有一些有用的内容...* -*这是 [TripleLift](https://triplelift.com/) 的数据工程师 [Eunice Do](https://www.linkedin.com/in/eunicedo/) 的来宾帖子，该公司领导下一代程序化广告。* +[EVE Online](http://www.eve-online.com/) 是“世界上最大的游戏宇宙”，这是 CCP 制作的大型多人在线游戏（ [MMO](http://en.wikipedia.org/wiki/MMO) ）。 对于 MMOG，EVE Online 的体系结构不常见，因为它不会将播放器负载分配给不同的服务器或分片。 而是，同一集群处理整个 EVE Universe。 将此与第二生命网格的[体系结构进行比较很有趣。 他们如何设法扩展规模？](http://highscalability.com/second-life-architecture-grid) -## 您的系统名称是什么，我们在哪里可以找到更多信息？ +## 信息来源 -该系统是 TripleLift 上的数据管道。 TripleLift 是一家广告技术公司，与该行业的大多数公司一样，我们每天都要处理大量数据。 在过去的三年中，TripleLift 数据管道的规模从每天处理数百万个事件扩展到处理数十亿个事件。 可以将这种处理总结为以经济高效的方式将报告数据连续聚合和传递给用户。 在本文中，我们将主要关注这一数十亿事件管道的当前状态。 +* [EVE Insider Dev Blog](http://myeve.eve-online.com/devblog.asp) +* [EVE 在线常见问题解答](http://www.eve-online.com/faq/faq_07.asp) +* [大规模-Eve 演变：Eve Online 的服务器模型](http://www.massively.com/2008/09/28/eve-evolved-eve-onlines-server-model/)及其在 Slashdot 上的[讨论](http://games.slashdot.org/games/08/10/02/2137251.shtml) +* [EVE 在线论坛](http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229) +* [大型多人游戏开发 2](http://www.amazon.com/gp/product/1584503904?ie=UTF8&tag=innoblog-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1584503904) -要跟踪到目前状态的 5 年历程，请查看[，这是我们的工程副总裁关于 TripleLift 管道](https://www.datacouncil.ai/talks/the-highs-and-lows-of-building-an-adtech-data-pipeline)的演变的演讲。 +## 平台 -## 您为什么决定构建此系统？ +* [用于服务器和客户端游戏逻辑的无堆栈 Python](http://www.stackless.com/) 。 它使程序员可以享受基于线程的编程的好处，而不会出现与常规线程相关的性能和复杂性问题。 +* SQL 服务器 +* 具有 [SSD](http://en.wikipedia.org/wiki/Solid-state_drive) 的刀片服务器，可实现高 IOPS +* 计划将 [Infiniband](http://en.wikipedia.org/wiki/Infiniband) 互连用于低延迟网络 +* 成立于 1997 年 +* 约 30 万活跃用户 +* 多达 40K 并发用户 +* 涉及数百艘船的战斗 +* 每天 2.5 亿笔交易 +* **代理刀片**-这些是 EVE 集群的面向公众的部分-它们负责建立玩家连接并在集群的其余部分内建立玩家通信。 +* **SOL 刀片**-这些是宁静的主力军。 集群分为 90-100 个 SOL 刀片，每个刀片运行 2 个节点。 节点是在一个核心上运行的主要 CPU 密集型 EVE 服务器进程。 有一些 SOL 刀片专用于一个繁忙的太阳能系统，例如 Jita，Motsu 和 Saila。 +* **数据库群集**-这是 EVE Online 的持久层。 运行中的节点与数据库进行大量交互，当然，与游戏有关的所有事情都驻留在这里。 多亏了固态驱动器，数据库才能够满足 Tranquility 产生的巨大 I / O 负载。 -我们需要一个可以实现以下目的的系统： +* 借助创新理念，MMO 游戏可以在同一场战斗中扩展至数百名玩家。 +* SSD 实际上将在某种程度上弥合内存与磁盘之间巨大的性能差距。 +* 低延迟的 Infiniband 网络互连将支持更大的集群。 -* 随着数据量的快速增长而扩展 -* 以经济高效的方式汇总日志级别的数据 -* 拥有清晰，可管理的工作依赖链 -* 自动化幂等作业运行和重试 -* 在预期的 SLA 中将数据交付给 BI 和报告工具 -* 处理那些报表工具上的查询负载 +### 得到教训 -## 您的系统有多大？ 尝试感受一下系统的工作量。 +* 关于 EVE Online MMOG 的架构，有许多有趣的事实，例如使用 Stackless Python 和 SSD。 +* 查看信息源，以获取有关 EVE Online 游戏的开发和操作的详细见解。 -大概系统统计-2020 年 4 月左右 +* 涉及 1000 多艘战舰的战斗 -* 最大的事件日志每天接收 300 亿个事件 -* 5 个日常聚合作业，最大输出为 7.5 GB -* 每小时 25 个聚合作业，最大输出 2.5 GB -* 15 小时的工作将汇总数据导入 BI 工具 -* 基数最高的归一化聚合具有 75 个维度和 55 个指标 +不，不，不超过一千次 如果您想为大多数参与其中的人提供可远程玩的体验，那么我们正在将 400 或 500 场战斗视为绝对最大的战斗。 以上所有内容均无法播放，并可能导致节点/游戏崩溃。 但是我不反对其他任何数字，总的来说，它们都是运行 Eve-O 宇宙的集群怪物。 -## 您的输入/输出带宽使用量是多少？ +我打电话给 BS-我们通常会在 60-100 次船战中使节点崩溃。 -数据管道汇总了我们 Kafka 集群收集的事件数据，其 I / O 约为 2.5GB / hr。 +感谢您的反馈。 我已经更新了条目。 -## 您的成长速度有多快？ +他们最近进行了更新，并设法使系统能够容纳一千艘船，当然，这并不意味着可以进行如此大规模的战斗，而只是意味着我们要说的系统 吉塔，不会崩溃。 但是 400-500 场战役可能还没有我们曾经相信的那么遥远。 他们在 CCP 所做的大量更新，令我感到惊讶的是，定期进行此类战斗。 当然，我不会参加这些活动，因为我是一个胆小鬼，而我更喜欢将我的 HIC 放在一块。 -在过去的几年中，我们经历了偶然的，快速的同比增长。 从 2016 年到 2017 年，我们管道中处理的数据量增长了 4.75 倍。 然后是 2017 年至 2018 年的 2.5 倍。最后是 2018 年至 2019 年的 3.75 倍。这就是 **3 年后的近 50 倍**！ +安全飞行。 -## 您的系统架构如何？ +是和不是 -在较高级别，我们的数据管道运行批处理，其流程包括： +我是 Goonswarm 公司的首席执行官，并在大多数星期内与 1000 多名玩家一起参加战斗。 自从 CCP 启动“无栈 IO”并在服务器端升级到 64 位体系结构以来，我们注意到服务器产生的延迟有了明显的改善。 如果我们在某个节点承受压力之前 24 小时警告 CCP，他们将为我们加强该节点，并且在 99％的时间里战斗将是可玩的。 -1. 原始事件收集和持久性 -2. 通过多个聚合级别对数据进行非规范化和规范化 -3. 将聚合数据持久性或摄取到各种数据存储中 -4. 在用户界面和报告工具中展示提取的数据以进行查询 +您还将注意到，无需等待 10 分钟即可加载网格，就可以取消 jita 的对接，而几个月前情况并非如此。 -我们从数据收集过程开始，在该过程中，将原始事件数据发布到我们的 50 多个 **Kafka** 主题中。 这些事件由 **Secor** （由 Pinterest 创建的开源使用者）使用，并以实木复合地板格式写到 **AWS S3** 。 +即使是最高端的图形卡/ CPU 组合也将难以在屏幕上显示和跟踪成千上万的单个对象（船舶，导弹，沉船，太空舱，战斗机&无人机），因此，如今的大型战斗通常都依赖于 您的 PC 而不是服务器响应能力。 -我们使用 **Apache Airflow** 来促进步骤 2 和 3 中必需的调度和依赖关系管理。 +我可以看到服务器体系结构如何应用于第一人称游戏，但是设计上的挑战使正确设置变得异常困难。 这不仅仅是公司从 CCP 购买设计或引擎的问题，对于第一人称视角的游戏，还需要彻底消除和重新设计。 不幸的是，游戏行业的主要投资者似乎不愿意冒险冒险冒险，但是如果有人管理它，那将是一场噩梦。 -Airflow 通过向 Databricks API 的作业提交请求启动聚合任务。 聚合使用 **Databricks** 群集上的 **Apache Spark** 运行。 首先，通过加入大量原始事件日志将数据归一化为宽表，以完整描绘广告位的拍卖前，拍卖中和拍卖后的情况。 非规范化日志将保留到 S3。 +[http://www.mustuniversity.com/Schools-Majors/Applied-Arts/Architecture.html“](在线架构学位 -在非标准化任务进入成功状态之后，Airflow 调度程序将启动其下游标准化任务。 这些聚合中的每一个都会将非规范化数据汇总到更窄范围的维度和指标集中，以适合特定报表的业务环境。 这些最终聚合也将保留到 S3。 +即使是最高端的图形卡/ CPU 组合也将难以在屏幕上显示和跟踪成千上万的单个对象（船舶，导弹，沉船，太空舱，战斗机&无人机），因此，如今的大型战斗通常依赖于 您的 PC 而不是服务器响应能力。 [http://www.carrentaladvice.net/“](租车 -成功完成每个最终聚合任务后，Airflow 调度程序将启动其各种下游持久性或摄取任务。 其中一项任务是将汇总数据复制到 **Snowflake** 中，该数据分析平台用作我们的商业智能工具的后端。 另一个任务将数据提取到 **Imply Druid** 中，这是一种托管的云解决方案，由时间优化的列式数据存储组成，支持对大型数据集的即席分析查询。 +我认为，超过 500 艘船的一切都不过分。 我对当前的限制非常满意，因为无论如何我都会避免出现大规模的污垢。 -最后，第 4 步是我们的商业智能和数据工程团队之间的共同努力。 可以查询聚合数据的主要地方是我们的内部报告 API， **Looker** （由 Snowflake 支持）和 **Imply Pivot** （拖放分析 UI 捆绑在 Imply 中 德鲁伊解决方案）。 +戴夫 [http://www.pilkingtonselfcleaningglass.co.uk/where-to-use/glass-doors/index.html](玻璃门 -## 您学到了什么？ +如果我们在某个节点承受压力之前 24 小时警告 CCP，他们将为我们加强该节点，并且在 99％的时间里战斗将是可玩的。 [http://www.livescores.com.sg/“](实时比分 -数据决策往往会产生深远的影响。 例如： +Python 非常慢……它是最慢的语言之一。 它可能比 C ++慢 10 倍。 一些用 python 编写的高级科学库实际上是在数学库的后台使用 C ++，但我无法想象在这种情况下。 作为一个业余爱好者的开发人员，我仍然不明白为什么 python 可以用于如此大的任务，特别是因为与更传统的语言相比，编码（IMO）看起来像地狱。 +其次，虽然我没有完全了解此问题，但我想知道它们如何处理跨节点的持久性... -* 一旦定义了现有字段，就很难改变其衍生方式。 这是由于维护该字段的历史连续性的共同需要。 -* 如果多个聚合级别中的任何一个级别的错误都持续运行了一段时间，那么用不正确的数据回填该时间段可能会既耗时又昂贵。 -* 如果提供了不正确或不完整的数据以供查询，则不会告诉您该数据在何处结束。 - -## 您希望自己做些什么？ - -长期以来，我们对于可访问的数据范围或可访问的数据范围尚无明确的方法。 - -* 不存在保留策略，并且无限期地存储了许多数据。 -* 允许用户查询无限期存储的数据，这降低了其他所有人的查询性能。 -* 所有报告工具均支持所有类型的查询。 换句话说，我们无法正确识别内部报告与外部报告以及报告与分析用例。 由于我们缺乏使数据可访问性的纪律性，最终形成了数据。 例如，我们没有热对冷分层，高对低粒度报告数据或合理的数据保留策略。 - -此后，我们对方法进行了更多思考，并采取了一些措施，例如实施 AWS S3 生命周期规则，为每个可查询数据源定义保留策略，以及指定报告工具以处理快速的调查性查询或较长日期范围内的大型报告，但 都。 - -## 您如何考虑将来更改架构？ - -我们计划通过使用 **Kafka Streams** 构建实时流式应用程序来补充批处理管道。 这是从涉及 **Spark 结构化流**， **Kafka 流**和 **KSQL** 的一些概念证明中选择的。 - -## 您如何绘制网络和服务器统计数据及趋势图？ - -我们使用 **Prometheus** 存储应用程序指标。 然后，我们在 **Grafana 仪表板**中汇总指标，并在这些仪表板上设置警报。 - -## 您的团队中有多少人？ - -团队中共有 **4 位数据工程师**，而我们约占整个工程组织的十分之一。 我们经常与之合作的团队是基础架构，解决方案和数据科学。 例如，我们最近通过 Airflow 加入了数据科学团队，并且他们的模型运行现在是自动化的。 - -## 您使用哪种语言来开发系统？ - -**用于气流的 Python** ，用于聚合的 Spark Scala 和用于某些报告工具的 Java。 \ No newline at end of file +在我看来，如果不先从数据库中读取原始位置，您甚至根本无法进行基本的健全性检查。 您可以根据位置和上次输入来假设它们在单个帧中的位置，但是当它们在游戏中越过节点行时，它仍然被写入服务器机架中某个节点上的持久数据库中，而突然之间 在他们的新节点上重新同步。 他们甚至可能会反复跳越节点线，从而滥用这种与冷却时间不同步的方式。 在这种情况下，我假设每个区域都有某种加载屏幕，这可能会解决此问题。 不过，尽管如此，我还是希望有一种方法可以使它更顺畅，以便可以将其集成到比单独的太阳系更为紧密的游戏世界中。.我现在正在研究类似的东西。 如果它平滑地滑行，那么理论上您可以提高节点的分辨率，直到您可以一次处理 2000 个播放器为止，只需横向扩展即可，而不是每次都像 Jita 那样使用大型专用服务器，但是跨节点 通信会很疯狂，但我仍在设法解决这一问题，以避免数据库上出现 IO 问题 \ No newline at end of file diff --git a/docs/3.md b/docs/3.md index 1be8e80..d256949 100644 --- a/docs/3.md +++ b/docs/3.md @@ -1,287 +1,37 @@ -# 从裸机到 Kubernetes +# 友谊建筑 -> 原文： [http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html](http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html) +> 原文： [http://highscalability.com/blog/2007/7/11/friendster-architecture.html](http://highscalability.com/blog/2007/7/11/friendster-architecture.html) -![](img/6a1d9f7a6234c97845d7e14fa51b4df5.png) +Friendster 是网络上最大的社交网站之一。 它强调真正的友谊和通过朋友发现新朋友。 -*这是位于旧金山的零售服装公司和众筹平台 [Betabrand](https://www.betabrand.com) 的首席工程师 [Hugues Alary](https://www.linkedin.com/in/huguesalary/?locale=en_US) 的特邀帖子。 本文最初在此处发表[。](https://boxunix.com/post/bare_metal_to_kube/)* +网站：http：//www.friendster.com/ -* [早期基础架构](#_early_infrastructure) - * [VPS](#_vps) - * [机架空间](#_rackspace) - * [OVH](#_ovh) -* [硬件基础结构](#_hardware_infrastructure) - * [可伸缩性和可维护性问题](#_the_scalability_and_maintainability_issue) - * [扩展开发流程](#_scaling_development_processes) -* [Docker](#_the_advent_ofdocker) 的出现 -* [调速器](#_kubernetes) - * [学习 Kubernetes](#_learning_kubernetes) - * [正式迁移](#_officially_migrating) - * [开发/分阶段环境](#_the_developmentstaging_environments) - * [在](#_a_year_after)之后一年 +## 信息来源 -如何将 [Betabrand](https://www.betabrand.com) 的裸机基础架构迁移到托管在 Google Container Engine 上的 Kubernetes 集群，从而解决了许多工程问题-从硬件故障到生产服务的可伸缩性不足，复杂的配置管理和高度异构的开发 -分阶段生产环境-使我们能够实现可靠，可用和可扩展的基础架构。 +* [Friendster](http://www.mysqluc.com/presentations/mysql05/pattishall_dathan.pdf) -每天扩展 10 亿个查询 -这篇文章将引导您了解 Betabrand 从 2011 年到 2018 年遇到的许多基础架构变更和挑战。 + ## 平台 -* * * + * 的 MySQL* 佩尔* 的 PHP* 的 Linux* Apache -## 早期基础设施 + ## 里面有什么？ -### VPS + * 具有 8 GB RAM 的双 x86-64 AMD 皓龙* 更快的磁盘（SAN）* 优化指标* 传统的 3 层体系结构，数据库前面有硬件负载平衡器* 基于类型的集群：广告，应用程序，照片，监控，DNS，画廊搜索数据库，配置文件数据库，用户信息数据库，IM 状态缓存，消息数据库，推荐数据库，朋友数据库，图形服务器，画廊搜索，对象缓存。 -在我工作的 7 年中，Betabrand 的基础架构发生了许多次变化。 + ## 得到教训 -2011 年，也就是我们的 CTO 雇用我的那一年，该网站托管在具有 Plesk 界面且没有 root 访问权限的共享服务器上（当然）。 每封新闻通讯（最多发送给数百人）都会使该网站屈服并使其爬行，有时甚至完全无响应。 + * 没有持久的数据库连接。* 删除了各种。* 优化指标* 不要先解决最大的问题* 优化而无停机* 分割负载* 将排序查询类型移至应用程序并添加了 LIMITS。* 缩小范围* 主键范围* 基准->进行更改->基准->进行更改（改进周期）* 稳定：始终有回滚的计划* 与团队合作* 评估：定义问题* 新系统的主要设计目标是从维护会话状态转变为无状态架构，该架构将在每次请求后进行清理* [我们的理念]不是购买大型集中式盒子，而是购买大量薄而便宜的盒子。 如果一个失败，则将鼠标移至另一盒。 -我的第一笔生意就是寻找替代品，并将网站转移到自己的专用服务器上。 +您的信息来源是什么？ 许多此类信息很容易推测。 -### 机架空间 +我认为这是来源： +[http://conferences.oreillynet.com/presentations/mysql05/pattishall_dathan.pdf](http://conferences.oreillynet.com/presentations/mysql05/pattishall_dathan.pdf) -经过几天的在线研究，我们在 Rackspace 上安装了 VPS-8GB RAM，320GO 磁盘，4 个虚拟 CPU，150Mbps 带宽。 再过几天，我们就生活在由……1 台服务器组成的新基础架构上； 运行带有 Memcached 提示的典型 Linux，Apache，PHP，MySQL 堆栈。 +这是从 2005 年开始的，否则是好东西。 -毫不奇怪，此基础架构很快就过时了。 +我认为 Friendster 使用 squid 作为反向代理。 -它不仅没有扩展，而且更重要的是，它的每个部分都是单点故障。 阿帕奇下来？ 网站关闭。 Rackspace 实例关闭了吗？ 网站关闭。 MySQL 崩溃了……您明白了。 +这是图片： +[http://wildavy.files.wordpress.com/2008/05/friendster_squid.png]( [http://wildavy.files.wordpress.com /2008/05/friendster_squid.png](http://wildavy.files.wordpress.com/2008/05/friendster_squid.png) -它的另一方面是它的成本。 - -我们的平均每月账单迅速攀升至 1,000 美元以上。 对于一台机器和我们当时产生的低流量来说，这是很昂贵的价格。 - -在运行了该堆栈几年后，即 2013 年中，我决定是时候让我们的网站更具可扩展性，冗余性，并且更具成本效益了。 - -我估计，我们至少需要 3 台服务器才能使我们的网站有些冗余，这在 Rackspace 上每年高达$ 14400。 作为一家非常小的初创公司，我们无法证明基础设施账单的“高价”； 我一直在寻找。 - -最便宜的选择最终导致我们的堆栈在裸机服务器上运行。 - -### OVH - -我过去曾在 OVH 工作过，一直都很满意（尽管在线上有不同的评论）。 我估计以 OVH 运行 3 台服务器每年的费用为 3240 美元，几乎比 Rackspace 便宜 5 倍。 - -OVH 不仅更便宜，而且其服务器的功能也比 Rackspace 的服务器高出 4 倍：32GB RAM，8 个 CPU，SSD 和无限带宽。 - -最重要的是，他们刚刚在北美开设了一个新的数据中心。 - -几周后，Betabrand.com 被托管在加拿大博哈努瓦的 OVH。 - -## 硬件基础架构 - -在 2013 年至 2017 年之间，我们的硬件基础架构经历了一些架构更改。 - -到 2017 年底，无论是在软件还是在硬件方面，我们的堆栈都大大超过了以往。 - -Betabrand.com 在 17 台裸机上运行： - -* 2 台负责 SSL 卸载的 HAProxy 机器配置为热备用 - -* 在我们的 Web 服务器的热备用负载均衡中配置了 2 个清漆缓存计算机 - -* 5 台运行 Apache 和 PHP-FPM 的计算机 - -* 2 个 Redis 服务器，每个服务器运行 2 个独立的 Redis 实例。 1 个实例用于某些应用程序缓存，1 个实例用于我们的 PHP 会话 - -* 3 台配置为 master-master 的 MariaDB 服务器，但以 master-slave 方式使用 - -* 3 个 Glusterd 服务器为我们所有的静态资产服务 - -否则，每台计算机都将运行一个或多个进程，例如 keepalived，Ganglia，Munin，logstash，exim，备份管理器，有监督的，sshd，fail2ban，prerender，rabbitmq 和 docker。 - -但是，尽管此基础架构非常便宜，冗余且没有单点故障，但它仍不可扩展，并且维护起来也非常困难。 - -### 可伸缩性和可维护性问题 - -现在，管理服务器“舰队”需要编写一组 Ansible 脚本并进行维护，尽管 Ansible 是一款出色的软件，但这绝非易事。 - -尽管 Ansible 会竭尽所能，但是 Ansible 不能保证您的系统状态。 - -例如，在由异构 OS（例如 debian 8 和 debian 9）组成的服务器机群上运行 Ansible 脚本，会使所有计算机的状态都接近您定义的状态，但是最终可能会出现差异。 第一个是您在 Debian 8 和 Debian 9 上运行，但是在某些服务器和其他服务器上，软件版本和配置也不同。 - -> 我经常搜索 Ansible 替代品，但从未发现更好。 -> -> 我看了看 Puppet，但发现它的学习曲线太陡峭了，从阅读别人的食谱中，*似乎*似乎以太多不同的方式来做同样的事情。 有些人可能认为这是灵活性，我认为这是复杂性。 -> -> SaltStack 引起了我的注意，但也发现很难学习。 尽管他们进行了广泛而深入的文档编制，但他们的命名选择（矿井，矿井，盐等）从未对我产生影响； 在复杂性方面，它似乎遭受了与 Puppet 相同的问题。 -> -> Nix 软件包管理器和 NixOS 听起来很棒，除了我对学习全新的操作系统感到不舒服（我已经使用 Debian 多年了），并担心尽管选择了大量的软件包，但最终我仍需要软件包 可用，这将成为新的维护对象。 -> -> 这些是我查看过的仅有的 3 个工具，但我敢肯定还有很多其他我可能从未听说过的工具。 - -然而，编写 Ansible 脚本并进行维护并不是我们唯一的问题； 增加容量是另一个。 - -对于裸机，无法即时添加和删除容量。 您需要提前计划好您的需求：购买一台机器-通常租用至少 1 个月-等待其准备就绪-可能需要 2 分钟至 3 天的时间-安装其基本操作系统， 安装 Ansible 的依赖项（主要是 python 和其他一些软件包），然后最后对它运行 Ansible 脚本。 - -对我们来说，整个过程是完全不切实际的，通常发生的事情是，我们会为预期的峰值负载增加容量，但之后再也不会删除它，这反过来又增加了我们的成本。 - -但是，值得注意的是，即使基础架构中未使用的容量类似于在烧钱，但在裸机上的成本仍比在云中便宜得多。 另一方面，使用裸机服务器带来的工程难题只是将成本从纯粹的材料成本转移到了管理成本。 - -在我们的裸机设置容量计划中，服务器管理和 Ansible 脚本只是冰山一角。 - -### 扩展开发流程 - -在 2017 年初，虽然我们的基础架构有所发展，但我们的团队也有所发展。 - -我们又雇用了 7 名工程师，使我们的团队由 9 人组成，其技能组从后端到前端遍布各个领域，并具有不同的资历水平。 - -即使在一个只有 9 人的小型团队中，也要保持生产效率并限制部署到生产中的错误数量，就可以确保简单，易于设置和易于使用的开发，分阶段和生产三联产品。 - -将您的开发环境设置为新员工，无需花费数小时，也无需升级或重新创建它。 - -此外，应该存在公司范围内可访问的登台环境，该环境应与您的产品的 99％（如果不是 100％）相匹配。 - -不幸的是，在我们的硬件基础架构中，达到这种和谐的三重奏是不可能的。 - -### 开发环境 - -首先，我们工程团队中的每个人都使用 MacBook Pro，这是一个问题，因为我们的堆栈基于 Linux。 - -但是，要求所有人切换到 Linux 并可能更改他们宝贵的工作流程并不是一个理想的选择。 这意味着最好的解决方案是提供一个与开发人员的机器偏好无关的开发环境。 - -我只能看到两个明显的选择： - -提供一个可以运行多个虚拟机的 Vagrant 堆栈（实际上更可能是 17 个计算机运行我们的整个堆栈），或者重新使用已经编写的 ansible 脚本，然后对我们的本地 macbook 运行它们。 - -在调查了 Vagrant 之后，我觉得使用虚拟机会严重影响性能，这是不值得的。 我决定（不管是好是坏）走 Ansible 路线（事后看来，这可能不是最好的决定）。 - -我们将在生产，登台和开发中使用相同的 Ansible 脚本集。 当然，我们的开发堆栈虽然接近生产，但并不是 100％匹配。 - -这足够好一段时间了。 但是，这种失配会在以后（例如，我们的开发和生产 MySQL 版本未统一）时引起问题。 一些在开发人员上运行的查询不会在生产环境中使用。 - -#### 暂存环境 - -其次，在不同的软件（mac os 与 debian）上运行开发和生产环境意味着我们绝对需要一个暂存环境。 - -不仅是由于版本不匹配导致的潜在错误，还因为我们需要一种在发布之前与外部成员共享新功能的方法。 - -我再次有多种选择： - -* 购买 17 台服务器并对它们运行 ansible。 但是，这会使我们的成本增加一倍，并且我们试图节省资金。 - -* 在一个可以从外部访问的独特的 linux 服务器上设置我们的整个堆栈。 更便宜的解决方案，但再次没有提供我们生产系统的精确副本。 - -我决定实施节省成本的解决方案。 - -暂存环境的早期版本涉及 3 个独立的 linux 服务器，每个服务器运行整个堆栈。 然后，开发人员会在整个房间（或聊天室）大喊大叫，“接管 dev1”，“有人在使用 dev3 吗？”，“ dev2 关闭了：/”。 - -总体而言，我们的开发，分阶段和生产设置远非最佳：它可以完成工作； 但绝对需要改进。 - -## Docker 的出现 - -2013 年，Dotcloud 发布了 Docker。 - -Docker 的 Betabrand 用例立即显而易见。 我将其视为简化我们的开发和登台环境的解决方案。 通过摆脱烦人的脚本（好吧，差不多；稍后再介绍）。 - -这些脚本现在仅用于生产。 - -当时，团队面临的一个主要痛点是竞争我们的三台物理登台服务器：dev1，dev2 和 dev3；另一台服务器是 dev3。 对我来说，维护这 3 台服务器是一个很大的麻烦。 - -在观察了 docker 几个月后，我决定在 2014 年 4 月试用它。 - -在其中一个登台服务器上安装 docker 之后，我创建了一个包含整个堆栈（haproxy，清漆，redis，apache 等）的 docker 映像，然后在接下来的几个月中编写了一个工具（`sailor`），使我们可以创建 ，销毁和管理可通过单独的唯一 URL 访问的无限数量的登台环境。 - -> 值得一提的是，当时 docker-compose 还不存在； 而且将整个堆栈放入一个 docker 映像中当然是很大的禁忌，但这在这里并不重要。 - -从那时起，团队不再竞争访问登台服务器。 任何人都可以使用 Sailor 从 Docker 映像创建一个完全配置的新登台容器。 我也不再需要维护服务器； 更好的是，我关闭并取消了其中的 2 个。 - -但是，我们的开发环境仍在 macos（当时为“ Mac OS X”）上运行，并使用 Ansible 脚本。 - -然后，大约在 2016 年 docker-machine 被释放。 - -Docker machine 是一种工具，可在您选择的任何堆栈上部署 docker 守护进程：virtualbox，aws，gce，bare-metal，azure（由您命名），docker-machine 可以完成； 在一个命令行中。 - -我将其视为轻松，快速地将基于 ansible 的开发环境迁移到基于 docker 的机会。 我修改了`sailor`以使用 docker-machine 作为其后端。 - -设置开发环境现在只需创建一个新的 docker-machine，然后传递一个标志供水手使用即可。 - -至此，我们的开发阶段流程已大大简化； 至少从开发人员的角度来看：每当我需要将我们的堆栈中的任何软件升级到较新版本或更改配置时，都无需修改我的 ansible 脚本，而是要求所有团队来运行它们，然后自己在所有 3 个设备上运行它们 登台服务器； 我现在可以简单地推送一个新的 docker 映像。 - -具有讽刺意味的是，我最终需要虚拟机（故意避免使用）在我们的 macbook 上运行 docker。 从一开始，使用无业游民而不是 Ansible 是一个更好的选择。 后视总是 20/20。 - -将 docker 用于我们的开发和登台系统为 Betabrand.com 现在运行的更好的解决方案铺平了道路。 - -## 州长 - -由于 Betabrand 主要是一个电子商务平台，因此黑色星期五每年越来越多地出现在我们的网站上。 - -令我们惊讶的是，自 2013 年以来，该网站已处理了越来越多的负载，而没有发生任何重大灾难，但是它确实需要提前一个月的准备：尽可能地增加容量，负载测试和优化我们的结帐代码路径。 - -但是，在为 2016 年黑色星期五做准备之后，很明显基础架构无法在 2017 年黑色星期五进行扩展。 我担心在负载下该网站将无法访问。 - -幸运的是，在 2015 年的某个时候，Kubernetes 1.0 的发布引起了我的注意。 - -就像在 docker 中看到一个明显的用例一样，我知道 k8s 是解决许多问题所需要的。 首先，它最终将使我们能够运行几乎与*相同的 dev-staging-production 环境。 而且，还将解决我们的可伸缩性问题。* - -我还评估了其他两个解决方案，即 Nomad 和 Docker Swarm，但 Kubernetes 似乎是最有前途的。 - -对于 2017 年黑色星期五，我着手将整个基础架构迁移到 k8s。 - -> 尽管我考虑了这一点，但我很快就排除了将我们当前的 OVH 裸机服务器用于 k8s 节点的问题，因为这将与我摆脱 Ansible 而不是处理硬件服务器附带的所有问题的目标背道而驰。 此外，在我开始调查 Kubernetes 之后不久，Google 便发布了托管的 Kubernetes（GKE）产品，我很快就选择了它。 - -### 学习 Kubernetes - -迁移到 k8 首先需要通过阅读在线文档来深入了解其架构和概念。 - -最重要的是了解容器，容器，部署和服务以及它们如何组合在一起。 然后依次执行 ConfigMaps，Secrets，Daemonsets，StatefulSets，Volumes，PersistentVolumes 和 PersistentVolumeClaims。 - -其他概念也很重要，尽管使集群前进的必要性较低。 - -一旦吸收了这些概念，第二个也是最困难的一步就是将我们的裸机架构转换为一组 YAML 清单。 - -从一开始，我就打算只有一套清单，用于创建所有三个开发，登台和生产环境。 我很快就遇到了需要参数化我的 YAML 清单的问题，而 Kubernetes 并不能立即使用它。 这是 Helm [ [1](#_footnotedef_1 "View footnote.") ] 派上用场的地方。 - -> Helm 网站的*：Helm 帮助您管理 Kubernetes 应用程序-Helm Charts 帮助您定义，安装和升级最复杂的 Kubernetes 应用程序。* - -Helm 将自己定位为 Kubernetes 的程序包管理器，但我最初只是将其用于模板功能。 现在，我也开始欣赏它的软件包管理器方面，并用它来安装 Grafana [ [2](#_footnotedef_2 "View footnote.") ] 和 Prometheus [ [3](#_footnotedef_3 "View footnote.") ] 。 - -经过一番汗水和几滴眼泪，我们的基础架构现在被整齐地组织为 1 个 Helm 程序包，17 个部署，9 个 ConfigMap，5 个 PersistentVolumeClaims，5 个秘密，18 个服务，1 个 StatefulSet，2 个 StorageClasses，22 个容器映像。 - -剩下的就是迁移到这个新的基础架构并关闭所有硬件服务器。 - -### 正式迁移 - -2017 年 10 月 5 日是夜晚。 - -扣动扳机非常容易，而且顺利进行。 - -我创建了一个新的 GKE 集群，运行`helm install betabrand --name production`，将我们的 MySQL 数据库导入到 Google Cloud SQL 中，然后，实际上花费了大约 2 个小时，我们才生活在 Clouds 中。 - -迁移很简单，就是。 - -当然，最有用的是在 Google GKE 中创建多个集群的能力：在迁移产品之前，我能够通过多次测试迁移进行排练，记下成功启动所需的每个步骤。 - -Betabrand 的黑色星期五 2017 年非常成功，我们遇到的一些技术问题与迁移无关。 - -### 开发/分期环境 - -我们的开发机器通过 Minikube [ [4](#_footnotedef_4 "View footnote.") ] 运行 Kubernetes 集群。 - -相同的 YAML 清单用于创建本地开发环境或“类似生产”的环境。 - -在生产环境中运行的所有内容，也在开发环境中运行。 两种环境之间的唯一区别是，我们的开发环境与本地 MySQL 数据库对话，而生产与 Google Cloud SQL 对话。 - -创建登台环境与创建新的生产集群完全相同：所需要做的只是克隆生产数据库实例（只需单击几下或一个命令行），然后通过`--set database`将登台集群指向该数据库。 `helm`中的]参数。 - -### 一年后 - -从我们将基础架构移至 Kubernetes 至今已经一年零两个月了，我再也高兴不起来了。 - -Kubernetes 在生产中一直坚如磐石，我们还没有遇到过停机的情况。 - -预计 2018 年黑色星期五将有大量流量，我们能够在几分钟内创建生产服务的精确副本并进行大量负载测试。 这些负载测试显示特定的代码路径性能非常差，只能显示大量流量，因此我们可以在黑色星期五之前修复它们。 - -不出所料，2018 年黑色星期五给 Betabrand.com 带来了前所未有的流量，但是 k8s 兑现了承诺，而 Horizo​​ntalPodAutoscaler 与 GKE 的节点自动缩放相结合的功能使我们的网站能够毫无问题地吸收峰值负载。 - -K8 与 GKE 相结合，为我们提供了使我们的基础架构可靠，可用，可伸缩和可维护所需的工具。 - -* * * - -[1](#_footnoteref_1). [https://helm.sh/](https://helm.sh/)[2](#_footnoteref_2). [https://grafana.com/](https://grafana.com/)[3](#_footnoteref_3). [https://prometheus.io/](https://prometheus.io/)[4](#_footnoteref_4). [https://github.com/kubernetes/minikube](https://github.com/kubernetes/minikube) - -雨果，好帖子！ 真的很脆，没有花哨/不必要的术语。 - -我很好奇看到您每月帐单的比较-OVH 裸机与 GCP K8S - -I too am curious to see a comparison of your monthly bill - OVH bare-metall vs GCP K8S...😉 - -您认为这对这家公司来说太过分了吗？ 我一直都很喜欢 Kube，不是因为业务需要它，而是因为人们喜欢高科技。 IDK，只是想一想 - -为什么不使用不同的名称空间进行测试和暂存，而不是创建不同的集群？ \ No newline at end of file +在显示维护页面之前，我已经收到了该消息。 \ No newline at end of file diff --git a/docs/30.md b/docs/30.md index 72461fd..8d1fe69 100644 --- a/docs/30.md +++ b/docs/30.md @@ -1,49 +1,153 @@ -# 缩放原理 - -> 原文： [http://highscalability.com/blog/2020/5/14/a-short-on-how-zoom-works.html](http://highscalability.com/blog/2020/5/14/a-short-on-how-zoom-works.html) - -![](img/63800fed327b13517b4aa92582805e07.png) - -整个晚上，Zoom 的规模从 2000 万增加到 3 亿。 令人难以置信的是，从外部看，他们并没有表现出明显的成长痛苦，尽管在内部，这是一个很好的押注，很多疯狂还在发生。 - -当然，Zoom 做出了一些设计决策，这些决策对于一个小型的，不起眼的初创公司来说是有意义的，但作为事实上的标准并没有多大意义，但这是可以预期的。 正如许多人所建议的，这并不是不良体系结构的迹象。 这实际上是产品的演变方式，尤其是当它们必须在数周，数天甚至数小时内提升时。 - -突然的成功需要进行仔细的审查，因此每个人都想知道 Zoom 的工作原理。 问题是我们了解的不多，但是我们确实有一些信息来源： - -* [缩放方式可提供业界领先的视频容量](https://blog.zoom.us/wordpress/2019/06/26/zoom-can-provide-increase-industry-leading-video-capacity/) -* [给我们用户的消息](https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/) -* 一年前的营销视频 [Zoom 独特的体系结构如何为您的视频带来最大的 UC 未来](https://www.youtube.com/watch?v=5BMbsFqtD0A) -* 2016 年关于[的文档全球基础设施和安全指南](https://zoom.us/docs/doc/Zoom_Global_Infrastructure.pdf) -* 已有一年的新闻稿 [Zoom 借助 Equinix 扩展，以适应未来需求并扩展其视频优先，云原生架构](https://www.prnewswire.com/news-releases/zoom-expands-with-equinix-to-future-proof-and-scale-its-video-first-cloud-native-architecture-300962299.html) -* [Zoom CFO 解释了公司如何应对不断增长的需求](https://www.cnbc.com/2020/03/18/zoom-cfo-explains-how-the-company-is-grappling-with-increased-demand.html) -* 在线问& A [问 Eric 任何问题](https://www.youtube.com/watch?v=tlC-sEdqY48) -* AWS 说[大多数 Zoom 运行在 AWS 上，而不是 Oracle 上](https://www.datacenterdynamics.com/en/news/most-zoom-runs-aws-not-oracle-says-aws) - -以下是其中一些来源的介绍： - -* 有关 Zoom 的数据中心使用情况有很多争论。 最终的结果是，他们从自己的共享空间开始，然后随着增长的高峰而扩展以使用多个云。 几乎教科书的执行如何处理突如其来的增长。 -* [大多数 Zoom 都在 AWS 上运行，而不是在 Oracle 上运行-AWS 说](https://www.datacenterdynamics.com/en/news/most-zoom-runs-aws-not-oracle-says-aws)：自大流行到来以来，该服务已将大量实时视频会议流量移至 AWS 上，并且容量也有所减少 在 Oracle Cloud 上...首席执行官 Eric Yuan 进一步澄清了这一点，解释说 Zoom 过去在“自己的数据中心”中处理实时视频会议流量...我们的实时流量始终留在我们自己的数据中心内 对于我们的付费客户...在这场大流行危机期间，每天都是新的记录。 我们自己的现有数据中心实际上无法处理此流量...这意味着 AWS 每天都会为 Zoom 旋转成千上万的新服务器...因此最终，我们自己的数据中心（主要是 Amazon）以及 在 Oracle 云中，这三者共同为所有前所未有的流量提供服务。 -* 我们对 Zoom 的架构知之甚少，但此营销视频进行了一些详细介绍： [Zoom 独特的架构如何为您的视频带来最大的 UC Future](https://www.youtube.com/watch?v=5BMbsFqtD0A) 。 -* Zoom 将其架构视为竞争优势。 每个人都将使用视频，那么我们如何扩展到每个人？ 因此 Zoom 始于无处不在的视频目标，并让该目标塑造了他们的架构。 -* 竞争对手通过数据中心进行长号通信，将其转码为其他人的普通视图，然后将混合视频发送给每个参与者。 这引入了延迟，使用了大量的 CPU 资源，并且很难扩展和部署新的数据中心来满足增加的负载。 -* Zoom 选择了 AVC 上的 SVC（可伸缩视频编解码器）编解码器。 AVC 是一种协议，您在其中发送单个流，并且单个流具有比特率。 如果要发送多个比特率，则必须发送多个流。 如果要发送多个比特率，这会增加带宽利用率。 -* SVC 是具有多个层的单个流。 这样就可以发送 1.2 mbs 的流，该流具有您可能需要缩小到给定网络条件的所有分辨率和比特率。 过去，您只能使用 ASIC 进行 SVC。 现在，由于摩尔定律，SVC 可以用软件完成。 -* Zoom 创建了多媒体路由，以解决传统供应商在 AVC 中遇到的问题。 消除转码摆脱了等待时间并增加了规模。 -* 多媒体路由会将用户内容带入他们的云中，当您作为客户端遇到问题时，他们会将另一个视频流切换给您。 如果您需要其他分辨率，则可以订阅该人分辨率的另一层。 -* 缩放不会转码或混合任何内容或形成任何视图。 从字面上看，您实际上是从零处理的路由中直接提取多个人的多个流。 这就是为什么您会看到如此出色的用户切换和语音切换体验以及低延迟的原因。 -* Zoom 开发了在云和客户端之间工作的应用程序层 QoS（服务质量）。 它的工作是检测网络状况。 收集的遥测数据确定将哪个流切换到客户端。 该算法查看 CPU，抖动，数据包丢失等情况。 -* 客户与云对话。 云知道何时不返回某些数据包，因此它将做出决定并将另一种流切换到您。 -* 如果网络环境不好，客户端可以自动缩小您自己的发送视频的大小，因此您不会浪费自己的下行带宽。 -* 客户端和云协同工作，以在正确的网络上交付正确的音频流，正确的视频流，因此用户体验达到最佳状态。 -* 具备网络意识意味着首先尝试最佳体验，即 UDP。 如果 UDP 不起作用，则尝试 HTTPS。 如果 HTTPS 不起作用，则会退回到 HTTP。 客户进行协商。 遥测表明为什么连接不良。 您能做的最糟糕的事情就是给用户带来不一致的体验。 -* 重点是使所有事情都尽可能简单直观地工作。 强调并重复了这一点，这可以解释一些较早的设计决策。 -* 在这一点上，讨论朝着更加注重市场的方向发展。 -* Zoom 通过 40 分钟的视频和聊天会议打乱了市场。 他们增加了免费的电话拨入式会议。 他们提供了市场上最好的 VOIP 体验。 竞争对手的平均 VOIP 采纳率不到 30％，缩放比例为 89％。 每年在音频会议上花费 30 亿美元，而 Zoom 免费提供它。 提供基于软件的视频会议室体验。 为竞争对手提供了一键式推送。 放弃数字标牌和房间展示。 -* Zoom 的竞争对手陷入了无法摆脱的收入模式。 不能创新，因为它们会破坏自己的收入模式。 -* Zoom 破坏了会议市场，音频市场，房间市场，现在他们想破坏电话。 尽管这是 2019 年，但随着大流行，该策略可能正在重新考虑。 -* Zooms 的目标是创建最大的互联协作网络。 他们希望兑现 20 年前 VOIP 的承诺，拆除人们相互协作的所有费用壁垒，推出 PSTN 连接性，通过聊天会议电话通过 IP 以任何网络上最低的速率连接所有人。 - -Zoom 如何满足如此巨大的带宽需求。 我不认为这是视频会议的中断，因为许多其他播放器已经以合理的成本结构提供了不错的视频内容，并且有些免费。 -让我们不要将破坏与谋杀行业混为一谈。 中断是有价值的东西，因为它的第一款产品具有某些技术优势，而该技术以前并未实现过，并且可以帮助用户降低此类服务的成本或通过一些广告收入流免费提供这种服务（尽管不会窃取数据）。 - -Zoom 并未中断，但得到了贪婪的投资者的支持，先杀死了其他视频会议公司，然后在杀死了所有其他小型竞争对手以与 bluejeans 或 google 见面之战后，慢慢开始赚钱。 \ No newline at end of file +# Notify.me 体系结构-同步性 + +> 原文： [http://highscalability.com/blog/2008/10/27/notifyme-architecture-synchronicity-kills.html](http://highscalability.com/blog/2008/10/27/notifyme-architecture-synchronicity-kills.html) + +开始一个新项目的好处是，您终于有机会正确地做它。 当然，您最终会以自己的方式弄乱一切，但是在那一瞬间，世界有了一个完美的秩序，一种让人感到满足和美好的正义。 全新的实时通知交付服务 notify.me 的 CTO Arne Claassen 现在正处于这个蜜月期。 + +Arne 足够亲切地与我们分享他如何构建通知服务的理念。 我想您会发现它很有趣，因为 Arne 对其系统如何工作进行了许多有用的详细介绍。 + +他的主要设计理念是最小化围绕同步访问形成的瓶颈，即，当*请求了一些资源并且请求者占用更多资源，等待响应时。 如果无法及时交付所请求的资源，则会堆积越来越多的请求，直到服务器无法接受任何新请求为止。 没有人得到他们想要的东西，而您断电了。 通过将请求和响应分为单独的消息传递操作将同步操作分解为异步操作，可以停止资源过载。 它可以使系统尽可能快地处理积压的请求，而不会导致系统因并行请求过多而崩溃。 在大多数情况下，请求/响应周期是如此之快，以至于它们看起来像线性的事件序列。* + +Notify.me 正在采用一种创新且冒险的策略，即使用基于 XMPP 的系统 ejabberd 作为其内部消息传递和路由层。 Erlang 和 Mnesia（Erlang 的数据库）是否能够跟上通信量并在通信量扩展时保持低延迟？ 找出来将会很有趣。 + +如果您对 notify.me 感兴趣，他们已经为 HS 读者提供了 500 个 Beta 帐户： [http://notify.me/user/account/create/highscale](http://notify.me/user/account/create/highscale) + +## 你是谁？ + +我的名字是 notify.me 的首席技术官 Arne Claassen。 在过去的十年中，我一直在致力于高度可扩展的基于 Web 的应用程序和服务。 这些站点采用了各种传统扩展技术的组合，例如服务器场，缓存，内容预生成以及使用复制和群集的高可用性数据库。 所有这些技术都是减轻许多用户争用的稀缺资源（通常是数据库）的方法。 知道了这些技术的好处和陷阱后，我就成为专注于规避稀缺资源场景的架构师系统的焦点。 + +## 什么是 notify.me，为什么创建它，为什么它是一件好事？ + +notify.me 是我们首席执行官 Jason Wieland 的创意。 这是一种近乎实时的通知服务，可提醒用户注意网络上发布的新内容。 + +旨在解决普通用户难以及时掌握网络上发生的时间紧迫事件的麻烦。 例如，一旦发布符合其搜索条件的新公寓，就会在 Craigslist 上搜索公寓的用户收到警报。 notify.me 所做的艰巨工作是反复检查 Craigslist 是否有新列表，并在发布新列表时提醒用户。 通知可以传递到即时通讯程序，桌面应用程序，移动设备，电子邮件和 Web 应用程序。 + +我们的目标是创建和发布开放的 API，使人们能够构建新的有趣的应用程序以生成和传递信息。 + +## 您的服务与人们可能熟悉的其他服务相比如何？ 像 Twitter，Friend Feed，Gnip 或 Yahoo Pipes？ + +有很多公司处于我们的竞争格局中，其中有些是直接竞争对手，例如 yotify.com 或 Alerts.com。 主要区别在于我们的方法。 Yotify 和警报的重点是作为通知门户网站供用户访问。 notify.me 是一个实用程序，重点是通过 XMPP 和 REST API 提供网站上所有可用的功能，允许用户与来自其选择应用程序的通知进行交互。 我们还允许将消息升级到目的地。 例如，如果用户未登录其 IM 或状态为离开，则可以升级通知并将其路由到其移动设备。 + +在消息传递领域，我们几乎与 Twitter 相反。 Twitter 基于其自己的用户生成的内容向内发布模型。 有人发了一条推文，并发布给了他们的关注者。 notify.me 正在创建一个面向外部的消息传递系统。 用户添加支持 Web feed 标准的任何网站，或将现有的通知电子邮件重定向给我们。 如果有的话，我们是一条消息传递管道，是对 titter 的补充（更多内容请参见下文）。 + +Friendfeed 在将您所有的社交网络合并到一个集中区域方面做得很好。 他们的主要重点是构建与捣碎的供稿进行交互的功能和工具。 此供稿非常适合作为 notify.me 的源添加，允许用户通过即时通讯程序接收所有社交网络更新。 社交瘾君子想要的功能是能够实时了解墙上是否有新帖子，以便您可以立即做出响应。 + +雅虎管道将被视为可能的合作伙伴，类似于他们向 Netvibes 和 Newsgator 追加销售的方式。 他们的重点是提供一个直观的编程界面，以便能够操纵提要并创建有用的混搭。 + +例如，[热门交易搜索](http://pipes.yahoo.com/pipes/pipe.info?_id=_E8FgV_42xGWa5pfZVUMqA)是一个漂亮的管道，可在一组网站上搜索最佳交易。 由于目标选项有限，用户可能不想使用 Yahoo 自己的通知选项。 + +在我们的 Beta 组中，我们看到用户添加 eBay 链接的活动类似。 ebay 有一个竞争性的通知管道来通知 notify.me，但是用户仍然在我们的服务中添加 ebay 搜索链接。 事实证明，他们希望在一个中央位置来管理各种新闻源。 + +Gnip 是纯粹的基础设施。 我们有类似的技术，但我们要追求完全不同的市场。 + +我们产品尚未公开的另一个核心功能是，我们的管道是双向的，即任何数据源也可以是目的地，反之亦然。 这样做的主要好处是能够响应消息，例如确认收到的支持通知单。 双向通信将需要与 notify.me API 集成，源可以通过该 API 来传递回复选项。 + +我们目前正在与 Twitter API 进行深度集成，以通过 IM 在您已收到其他通知的同一通道中为推文提供双向功能。 + +## 您能否解释 notify.me 的不同部分以及它们如何连接在一起？ + +一般而言，我们的系统由三个子系统组成，每个子系统都有许多实现。 +1\. **接收**由 rss 和电子邮件接收器组成，它们会不断检查用户的电子邮件地址（ [[受电子邮件保护]](/cdn-cgi/l/email-protection) ）和用户的供稿中是否有新数据。 新数据变成通知，并传播到路由。 +2\. **路由**负责将用户的通知发送到正确的交付组件。 路由是系统中与用户进行交互以进行管理的点，例如更改源和目​​的地以及查看历史记录。 通知历史记录是一个专门的传递组件，即使在通过整个管道后，也可以通过网站仔细阅读所有消息。 +3\. **传递**当前由历史记录（总是获取消息），Xmpp IM，SMS 和电子邮件以及正在开发的私有 RSS，AIM 和 MSN 组成。 从更高的技术层面来看，此系统的拓扑结构由两个单独的消息总线组成： +1\. **存储转发队列**（使用 [simpleMQ](http://sourceforge.net/projects/simpleMQ) ） +2 。 **XMPP** （使用 [ejabberd](http://www.ejabberd.im/) ） + +**摄取端使用存储和转发队列**来分发摄取工作，并且通常在任何地方进行 数据在用户的路由规则可见之前进行处理。 这允许扩展灵活性以及在组件故障期间进行进程隔离。 + +**Xmpp 总线**被称为 Avatar 总线，之所以这样命名，是因为每个数据拥有实体均由守护进程表示，该进程是该实体数据的唯一授权。 我们有四种类型的化身，即 Monitor，Agent，Source 和 User +1。 **Monitor** 化身只是负责观察实例运行状况并根据需要旋转和关闭其他计算节点的负责方。 +2\. **代理**化身是将网关提供给我们用户的状态信息并将消息传递给用户的传递网关。 +3\. **源**化身是摄取器，例如 RSS。 该化身从存储和转发队列中提取新消息，并将新消息通知其订户。 +4\. **用户**化身可保留特定用户的所有配置和消息传递数据。 它负责接收来自摄取头像的新通知，确定路由并将消息推送到适当的传递代理，因为该代理声明了执行该传递的能力。 + +## 您面对哪些特殊挑战，如何克服这些挑战？ 您考虑了哪些选择，为什么决定以其他方式进行选择？ + +从一开始，我们的主要目标就是避免瓶颈和阻碍水平扩展的障碍。 最初，我们计划将整个系统构建为通过队列的无状态消息流，沿线的每个守护程序都负责流经它的数据，然后将其合并，复用和路由到下一个点，直到实现交付为止。 这意味着除了备份队列之外，没有任何一个部件的故障会影响整个部件。 + +但是，我们很早就意识到，一旦为用户指定了一条消息，我们就需要能够跟踪消息的位置并能够根据用户的配置和状态动态地重新路由它。 这导致我们通过 REST API 在守护程序之间添加了一些不适当的耦合。 由于我们仍在将处理迁移到组合队列/异步总线体系结构，因此仍然存在一些这种问题。 + +当我们意识到没有状态的纯消息传递将无法满足我们的动态需求时，简单的解决方案是返回到尝试过的状态保持器，即中央关系数据库。 知道我们的扩展目标后，这会引入一个失败点，我们迟早将无法缓解这一点。 我们决定以不同的方式来看待我们的状态，而不是考虑根据功能（即摄取，解析，转换，路由，交付）基于流过的数据查询状态来创建处理单元，而是想到了这些单元 在数据所有权方面，即来源和目的地（用户）。 一旦走上了轨道，几乎没有共享状态，我们可以更改存储模式，让每个数据所有者对自己的数据负责，从而允许持久层的水平扩展以及更高效的缓存。 + +跨所有者访问数据的其余需求是分析。 在许多系统中，分析是存在中央数据库的主要原因，因为事实和维度经常在生产模式中混杂在一起。 就我们的目的而言，此数据与生产无关，因此永远不会影响活动容量。 用法和状态更改被视为不可变的事件，它们在发生时排队进入我们的存储转发系统。 我们存储转发队列的性质使我们能够自动将所有主机中的所有这些事件收集到中央存档中，然后可以通过 ETL 流程将其处理为事实和维度数据。 这允许对使用情况进行近实时跟踪，而不会影响面向用户的系统。 + +## 您能否再解释一下您对 XMPP 的选择？ 它主要用作 EC2 节点上的联合 XMPP 服务器之间的消息总线吗？ 是否将 XMPP 队列用作来自所有来源的每个用户的消息的队列，然后再将其推送给用户？ + +我们有三个不同的 xmpp 群集，它们利用联合来进行跨阶段的操作：用户，代理和头像总线。 + +### 用户数 + +这是一台常规的 xmpp IM 服务器，我们在该服务器上为每个用户创建帐户，向他们提供可从任何具有 Xmpp 功能的客户端使用的 IM 帐户。 此帐户还用作我们的桌面应用程序登录时的用户，这将成为我们用于第三方消息提取和分发的 API 的身份验证 + +### 代理商 + +连接到该群集的守护程序充当我们的内部 Avatar 总线与外部客户端之间的通信桥。 目前，这主要是用于与聊天客户端进行通信，因为每个用户都被分配了一个他们无需我们即可通过其进行通信的代理，无论他们使用其默认帐户还是使用诸如 jabber.org，googletalk 等的第三方帐户。 通过专用代理的这些代理测试使用 Xmpp RPC 的客户端 API。 将来，我们还将为第三方集成提供完整的 XMPP 和 REST API，这些 API 将使用代理与 Avatar 总线进行通信。 + +我之前提到过，代理程序也是化身，但是它们有点特殊，因为它们在 Avatar 总线上没有用户，而是通过跨服务器联合与其他化身进行对话。 我们目前还在为 Oscar 和 MSN 网络建立代理，由于它们的本机传输不是联邦的，因此它们将直接位于头像总线上。 我们还计划评估其他网络，以获得将来的支持。 + +### 头像 + +头像是我们的内部消息总线，用于路由和处理所有命令和消息。 尽管我们确实利用在线状态进行监视，但我们主要在头像之间使用直接消息传递和基于 IQ 的 RPC 节。 + +那么什么是化身？ 它是一个守护程序（单个物理守护程序进程可以托管许多化身守护程序），是某些外部实体数据的权限。 即 在 notify.me 中注册的每个用户都有一个化身，用于监视代理的状态变化，接收照顾该用户的消息并负责将这些消息路由到适当的传递渠道。 这意味着每个头像都是关于该用户的所有数据的唯一授权者，并负责持久化数据。 如果系统的其他部分想要了解有关该用户的信息或修改其数据，它将使用 Xmpp RPC 与虚拟形象进行对话，而不是与某些中央数据库进行对话。 目前，化身持续存在于磁盘和 SimpleDB 中，同时保持 ttl 管制的高速缓存正在进行中。 由于仅化身可以写入自己的数据，因此无需检查数据库，而是可以将其内存和磁盘缓存视为权威，而 SDB 主要用于写入。 仅在节点发生故障时才需要读取以在另一节点上启动化身。 + +在巴士的另一端，有我们的摄入装置。 摄取器由许多守护程序组成，通常在针对外部源的轮询循环上运行，将新数据排队到我们的存储转发队列中，适当的摄取器头像会拾取新消息并将其分发给其订阅者。 在摄取器头像方案中，它是订阅和路由数据的权限。 + +这是一个典型的用例：用户通过 Web 界面订阅 RSS feed。 Web 界面将请求发送到用户的头像，该头像将保留订阅以供参考，然后从 rss 接收器请求订阅。 随着新的 rss 项目到达，rss 摄入器会将项目多路复用到订阅该供稿的所有用户头像。 用户化身依次确定适当的投放机制并安排投放时间。 一般而言，这意味着用户头像通过``用户代理''订阅了用户的 Xmpp 状态。 在用户处于接受消息的适当状态之前，用户化身排队 rss 项目。 一旦用户准备好接收通知，就将状态更改从代理传播到内部总线，然后用户化身将 rss 项目发送给代理，代理再将其发送给用户。 + +目前，所有头像均始终在线（即使大部分都是空闲的），这对于我们当前的用户群来说还不错。 我们的计划是修改 ejabberd 的脱机存储模块，以便我们可以盲目发射节并使队列中的消息向监视器发出信号以启动用于目标 XmppId 的适当化身。 一旦建立了该系统，我们将能够按需启动化身，并在闲置时将其关闭。 + +## 您希望在什么流量负载下破坏当前的体系结构，您的计划是什么？ + +由于我们的系统是分布式的，并且是设计异步的，因此应避免在负载下发生系统范围的故障。 但是，尽管避免了所有常见的瓶颈，但事实是我们的消息总线使这一切成为可能，这可能成为我们的限制因素，要么是因为它无法处理化身的数量（总线上的节点），要么是因为延迟 巴士变得无法接受。 我们只是开始使用头像系统作为我们的骨干网，所以它仍然有点脆弱，我们仍在对 ejabberd 进行负载测试以确定在什么时候遇到限制因素。 + +虽然我们已经在集群 ejabberd，但 mnesia 数据库复制和跨节点震颤的负载意味着连接数或延迟都将最终导致集群失败或仅消耗太多内存来进行管理。 + +由于我们的消息传递主要是点对点的，因此我们希望可以将用户群划分为头像孤岛，每个孤岛都托管在专用的头像子域群集中，从而减少了消息和连接负载。 只要我们的筒仓经过适当设计，以将跨子域的中断保持在最低水平，我们就应该能够拥有 n 个筒仓来保持负载最大。 + +要避免这种体系结构失败，我们面临的最大挑战就是永远保持警惕，防止引入会造成消息传递瓶颈的功能。 我们通过单个处理器或处理器系列的大量消息流量会引入依赖关系，我们无法通过子域划分来扩展自己。 + +## 相关文章 + +* [notify.me 技术博客-INotification](http://techblog.notify.me/)* [Flickr-预先进行必要的工作并将其余的工作排入队列](http://highscalability.com/strategy-flickr-do-essential-work-front-and-queue-rest) + +好东西！ 很高兴看到 erlang（和 ejabberd）越来越受欢迎！ + +尽早优化，对吧？ 所有的扩展工作，尽管疯狂有趣，并且在智力上令人兴奋，但直到成功真正需要时，它们才如此。 + +您可能还说这是浪费。 :) + +我不认为早期优化在这里是错误的。 由于执行此操作的大多数工具几乎都是“开箱即用”的，因此通常只需要简单（但可能会很耗时）的管道即可。 这个设置似乎没有什么真正复杂的。 + +我想知道在以下情况下 notify.me 采取了哪些措施来克服这种即时性： + +假设那里有 10,000 名程序员从 CraigList 订阅了“高级程序员”。 一旦一家公司在 CraigList 上发布了“高级程序员”的招聘广告，所有这 10,000 名程序员都会收到 IM，SMS 或电子邮件的通知。 （希望我到目前为止是对的），notify.me 如何保证通知将同时（几乎）发送给订阅者？ 如果第一个程序员收到通知的时间与最后一个程序员收到通知的时间之间的时间间隔大于 10 分钟，则这是毫无意义的通知。 + +希望我说得足够清楚。 + +关于早期优化：由于我们没有处理已建立的沟通渠道（就像大多数网络媒体资源一样），因此我们无法明确定义提升的方式。 看看我们从第一种方法中学到的知识，很明显地，我们需要一些可以扩展的基线管道，因为一旦需要，就可能会重新构造我们路由消息的方式 。 + +您好，我叫 Jason Wieland，我是 notify.me 的首席执行官，我只想对所有评论（公开和私人）表示感谢，并回答最后一个帖子。 + +飞行员负责将通知发送给用户。 这些是分布式守护程序，旨在可伸缩且不会过载。 实时消息传递（读取 IM，桌面应用程序）引擎每秒可以处理数千条消息。 电子邮件和短信（在获得简短代码之前）是另一回事。 电子邮件是通过多头 smtp 集群发送的，但是，我们只能依靠 smtp 协议流程的工作方式。 因此可能会有时间波动。 + +我们建议任何想要立即收到通知的人使用 Instant Messenger 或我们的桌面应用程序。 + +谢谢， + +杰森 + +Jason， +谢谢您的答复。 +正如您提到的， + +“实时消息传递（读取 IM，桌面应用程序）引擎每秒可以处理数千条消息。” + +使用 IM 的订户可以同时接收通知吗？ 是否没有循环遍历所有订户并向其发送通知？ 因为我绝对是可伸缩性的新手，所以我能想像出要解决此问题的方法是导入“ fork-join”模型，以同步所有守护程序。 + +祝您一切顺利 +刘浩 + +Hello Hao Liu, + +用户可以在同一批次中收到多个通知。 批处理是我们创建的 2 秒窗口，用于将同时到达的消息分组在一起。 每个用户只有一个轻量级守护程序（称为 Avatar）。 每个用户平均每天会收到 30 条通知，因此大多数时间它处于空闲状态，并且有足够的空间来处理一组消息。 虽然它们要在相同的时间实例中进行处理。 它们将在不到一秒的时间内被处理（我们的目标是每位用户每秒处理约 100 条消息）。 \ No newline at end of file diff --git a/docs/31.md b/docs/31.md index 0720c3f..8ceb84d 100644 --- a/docs/31.md +++ b/docs/31.md @@ -1,819 +1,193 @@ -# Egnyte Architecture：构建和扩展多 PB 内容平台的经验教训 +# Google 架构 + +> 原文： [http://highscalability.com/blog/2008/11/22/google-architecture.html](http://highscalability.com/blog/2008/11/22/google-architecture.html) + +**更新 2：** [使用 MapReduce](http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html) 对 1 PB 进行排序。 PB 并非拼写错误的花生酱和果冻。 它是 1 PB 或 1000 TB 或 1,000,000 GB。 *在 4,000 台计算机上对 1PB（10 万亿条 100 字节的记录）进行分类花费了六个小时又两分钟，并且在 48,000 个磁盘上将结果复制了三次。 +**更新：** [Greg Linden](http://glinden.blogspot.com/2008/01/mapreducing-20-petabytes-per-day.html) 指向 Google 的新文章 [MapReduce：简化了大型集群上的数据处理](http://labs.google.com/papers/mapreduce-osdi04.pdf)。 一些有趣的统计数据：每天执行 10 万个 MapReduce 作业； 每天处理超过 20 PB 的数据； 已经实施了超过 1 万个 MapReduce 程序； 机器是具有千兆位以太网和 4-8 GB 内存的双处理器。 + +Google 是可扩展性之王。 每个人都知道 Google 的庞大，精巧和快速的搜索功能，但他们不仅在搜索中脱颖而出。 他们构建可扩展应用程序的平台方法使他们能够以惊人的高竞争率推出互联网规模的应用程序。 他们的目标始终是建立性能更高，规模更大的基础架构来支持其产品。 他们是如何做到的？* + +## 信息来源 + +1. [视频：在 Google 构建大型系统](http://video.google.com/videoplay?docid=-5699448884004201579) +2. [Google 实验室：Google 文件系统](http://labs.google.com/papers/gfs.html) +3. [Google 实验室：MapReduce：大型集群上的简化数据处理](http://labs.google.com/papers/mapreduce.html) +4. [Google 实验室：BigTable](http://labs.google.com/papers/bigtable.html) 。 +5. [视频：BigTable：一种分布式结构化存储系统](http://video.google.com/videoplay?docid=7278544055668715642)。 +6. [Google 实验室：适用于松耦合分布式系统](http://labs.google.com/papers/chubby.html)的胖锁服务。 +7. [Google 的运作方式[Baseline Magazine]的 David Carr 撰写的](http://www.baselinemag.com/article2/0,1540,1985514,00.asp)。 +8. [Google 实验室：解释数据：使用 Sawzall](http://labs.google.com/papers/sawzall.html) 进行并行分析。 +9. [Dare Obasonjo 关于可伸缩性会议的说明。](http://www.25hoursaday.com/weblog/2007/06/25/GoogleScalabilityConferenceTripReportMapReduceBigTableAndOtherDistributedSystemAbstractionsForHandlingLargeDatasets.aspx) + +## 平台 + +1. 的 Linux +2. 多种语言：Python，Java，C ++ + +## 里面有什么？ + +### 统计资料 + +1. 2006 年估计有 450,000 台低成本商品服务器 +2. 在 2005 年，Google 索引了 80 亿个网页。 现在，谁知道呢？ +3. 目前，Google 有 200 多个 GFS 集群。 一个集群可以具有 1000 甚至 5000 台计算机。 数万台计算机的池从运行高达 5 PB 的 GFS 群集中检索数据。 整个群集的总读/写吞吐量可以高达 40 GB /秒。 +4. 目前，Google 有 6000 个 MapReduce 应用程序，每个月都会编写数百个新应用程序。 +5. BigTable 可扩展以存储数十亿个 URL，数百 TB 的卫星图像以及成千上万用户的首选项。 + +### 堆栈 + +Google 将其基础架构可视化为三层堆栈： + +1. 产品：搜索，广告，电子邮件，地图，视频，聊天，博客 +2. 分布式系统基础架构：GFS，MapReduce 和 BigTable。 +3. 计算平台：一堆不同数据中心中的机器 +4. 确保公司人员易于以较低的成本进行部署。 +5. 查看每个应用程序的价格性能数据。 花更多的钱在硬件上不会丢失日志数据，而花更少的钱在其他类型的数据上。 话虽如此，他们不会丢失数据。 + +### 可靠的 GFS 存储机制（Google 文件系统） + +1. 可靠的可扩展存储是任何应用程序的核心需求。 GFS 是他们的核心存储平台。 +2. Google 文件系统-大型的分布式日志结构化文件系统，在其中可以放入大量数据。 +3. 为什么要构建它而不使用现成的东西？ 因为它们控制着一切，而正是平台才使它们与其他人区分开。 他们需要： + -跨数据中心的高可靠性 + -可扩展到数千个网络节点 + -巨大的读/写带宽要求 + -支持大小为千兆字节的大数据块。 + -跨节点高效分配操作以减少瓶颈 +4. 系统具有主服务器和块服务器。 + -主服务器将元数据保留在各种数据文件中。 数据以 64MB 的块存储在文件系统中。 客户端与主服务器对话，以对文件执行元数据操作，并在磁盘上找到包含其所需需求的块服务器。 + -块服务器将实际数据存储在磁盘上。 每个块都在三个不同的块服务器之间复制，以在服务器崩溃的情况下创建冗余。 一旦由主服务器指示，客户端应用程序将直接从块服务器检索文件。 +5. 即将上线的新应用程序可以使用现有的 GFS 集群，也可以使用自己的集群。 了解他们在整个数据中心使用的配置过程将很有趣。 +6. 关键在于足够的基础架构，以确保人们可以选择其应用程序。 可以调整 GFS 以适合单个应用程序的需求。 + +### 使用 MapReduce 处理数据 + +1. 既然您拥有一个良好的存储系统，那么如何处理如此多的数据呢？ 假设您在 1000 台计算机上存储了许多 TB 的数据。 数据库无法扩展或无法有效地扩展到这些级别。 那就是 MapReduce 出现的地方。 +2. MapReduce 是用于处理和生成大型数据集的编程模型以及相关的实现。 用户指定一个处理键/值对以生成一组中间键/值对的映射函数，以及一个归约函数，该归约函数合并与同一中间键关联的所有中间值。 在此模型中，许多现实世界的任务都是可以表达的。 以这种功能风格编写的程序会自动并行化，并在大型商用机器集群上执行。 运行时系统负责划分输入数据，在一组机器上调度程序的执行，处理机器故障以及管理所需的机器间通信的细节。 这使没有并行和分布式系统经验的程序员可以轻松利用大型分布式系统的资源。 +3. 为什么要使用 MapReduce？ + -在许多机器之间分区任务的好方法。 + -处理机器故障。 + -适用于不同的应用程序类型，例如搜索和广告。 几乎每个应用程序都有 map reduce 类型的操作。 您可以预先计算有用的数据，查找字数，对数据 TB 进行排序等。 + -计算可以自动移近 IO 源。 +4. MapReduce 系统具有三种不同类型的服务器。 + -主服务器分配用户任务以映射和简化服务器。 它还跟踪任务的状态。 + -地图服务器接受用户输入并对其进行地图操作。 结果将写入中间文件 + -Reduce 服务器接受地图服务器生成的中间文件，并对它们执行 reduce 操作。 +5. 例如，您要计算所有网页中的单词数。 您将把存储在 GFS 上的所有页面送入 MapReduce。 这将同时在数千台计算机上发生，并且所有协调，作业调度，故障处理和数据传输将自动完成。 + -步骤如下：GFS->映射->随机播放->缩减->将结果存储回 GFS。 + -在 MapReduce 中，地图将一个数据视图映射到另一个数据视图，生成一个键值对，在我们的示例中为单词和计数。 + -改组聚合密钥类型。 + -减少量汇总所有键值对并产生最终答案。 +6. Google 索引编制管道具有约 20 种不同的简化地图。 管道使用一堆记录和聚合键来查看数据。 第二个 map-reduce 耗时较长，会得到该结果并执行其他操作。 等等。 +7. 程序可能很小。 最少 20 到 50 行代码。 +8. 一个问题是流浪汉。 散乱的人是比其他人慢的计算。 由于 IO 速度慢（例如控制器故障）或 CPU 暂时出现峰值，可能会导致流浪汉。 解决方案是运行多个相同的计算，并在完成一个计算后杀死所有其余计算。 +9. 在 map 和 reduce 服务器之间传输的数据已压缩。 这个想法是因为服务器不受 CPU 的限制，因此有必要花数据压缩和解压缩以节省带宽和 I / O。 -> 原文： [http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html) +### 在 BigTable 中存储结构化数据 -![](img/cd669c781d6a9a0f1fd802de7a2578a4.png) +1. BigTable 是一个大型的，容错的，自我管理的系统，其中包括 TB 级的内存和 PB 级的存储。 它每秒可以处理数百万次读/写。 +2. BigTable 是建立在 GFS 之上的分布式哈希机制。 它不是关系数据库。 它不支持联接或 SQL 类型查询。 +3. 它提供了按键访问结构化数据的查找机制。 GFS 存储不透明的数据，许多应用程序需要具有结构的数据。 +4. 商业数据库根本无法扩展到该级别，并且无法在 1000 台计算机上使用。 +5. 通过控制自己的低级存储系统，Google 可以获得更多的控制权和杠杆作用来改进其系统。 例如，如果他们想要使跨数据中心操作更容易的功能，则可以将其内置。 +6. 可以在系统运行时添加和删除计算机，并且整个系统都可以正常运行。 +7. 每个数据项都存储在一个单元格中，可以使用行键，列键或时间戳对其进行访问。 +8. 每行存储在一个或多个平板电脑中。 数位板是一系列 64KB 的块，其数据格式为 SSTable。 +9. BigTable 具有三种不同类型的服务器： + -主服务器将平板电脑分配给平板电脑服务器。 他们跟踪平板电脑的位置，并根据需要重新分配任务。 + -平板电脑服务器处理对平板电脑的读/写请求。 当超出尺寸限制（通常为 100MB-200MB）时，他们会拆分平板电脑。 当平板电脑服务器出现故障时，每台 100 台平板电脑服务器将拾取 1 台新平板电脑，然后系统将恢复。 + -锁定服务器形成分布式锁定服务。 打开平板电脑进行书写，主控权和访问控制检查之类的操作需要相互排斥。 +10. 位置组可用于将数据的相关位物理存储在一起，以实现更好的参考位置。 +11. 平板电脑尽可能多地缓存在 RAM 中。 -这是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的来宾帖子，工程师是为 [Egnyte](https://www.egnyte.com/) 在家工作的。 Egnyte 是专门为企业构建的安全内容平台。 他和他的同事们花费大量的时间来扩展大型分布式文件系统。 您可以通过 [@kpatelwork](https://twitter.com/kpatelwork) 与他联系。 +### 硬件 -## 简介 +1. 当您有很多机器时，如何构建它们以使其具有成本效益并高效使用电源？ +2. 在顶部使用超廉价的商品硬件和内置软件来应对其死亡。 +3. 如果您使用容易发生故障的基础架构，而不是基于高度可靠的组件构建的基础架构，则可以将计算机功耗提高 1000 倍，而成本却降低了 33 倍。 为了使此策略有效，您必须在不可靠性的基础上建立可靠性。 +4. Linux，内部机架设计，PC 类主板，低端存储。 +5. 基于性能的每瓦价格并没有改善。 有巨大的电源和散热问题。 +6. 混合使用搭配使用自己的数据中心。 -您的笔记本电脑有一个文件系统，该文件系统被数百个进程使用。 但是，如果您希望使用它来支持数以万计的用户在处理同时包含 PB 级数据的数亿个文件时有一些缺点。 它受磁盘空间的限制； 它无法弹性扩展存储空间； 如果您运行一些 I / O 密集型进程或尝试与 100 个其他用户进行协作，就会感到窒息。 让我们来解决这个问题，并将其转换为遍布全球的数百万付费用户使用的云原生文件系统，您将了解我们过山车的规模，可以扩展该系统以满足每月的增长和 SLA 要求，同时提供严格的一致性和 我们都期望笔记本电脑具有出色的耐用性。 +### 杂项 -Egnyte 是一个安全的内容协作和数据治理平台，成立于 2007 年，当时 Google 硬盘还没有诞生，而 AWS S3 却禁止了成本。 我们唯一的选择是袖手旁观，自己构建基本的云文件系统组件，例如对象存储。 随着时间的推移，S3 和 GCS 的成本变得合理，并且借助 Egnyte 的存储插件架构，我们的客户现在可以引入他们选择的任何存储后端。 为了帮助我们的客户管理持续的数据爆炸，我们在过去几年中设计了许多核心组件。 在本文中，我将分享当前的体系结构以及我们所学到的扩展它的一些经验教训，以及我们希望在不久的将来进行改进的一些内容。 +1. 快速推出更改，而不必等待质量检查。 +2. 图书馆是构建程序的主要方式。 +3. 有些应用程序是作为服务提供的，例如爬网。 +4. 基础结构可处理应用程序的版本控制，因此可以发布它们而不必担心发生问题。 -## Egnyte Connect 平台 +### Google 的未来发展方向 -Egnyte Connect 平台使用 3 个数据中心来满足来自全球数百万用户的请求。 为了增加弹性，可靠性和耐用性，这些数据中心使用高速，安全的 Google 互连网络连接到 Google Cloud 平台。 +1. 支持地理分布式集群。 +2. 为所有数据创建一个全局名称空间。 当前，数据按群集进行隔离。 +3. 更好，更好的数据和计算自动化迁移。 +4. 解决将广域复制与网络分区结合使用时发生的一致性问题（例如，即使群集因维护而脱机或由于某种故障而保持服务正常运行）。 -![](img/b34c983ca54495f680a9dadebfa8f2a4.png) +## 得到教训 -Egnyte Connect 运行一个服务网格，该网格从我们自己的数据中心延伸到提供多种服务类别的 Google 云： +1. **基础设施可以成为竞争优势**。 当然是给 Google 的。 他们可以更快，更便宜地推出新的互联网服务，而且在其他竞争者中还可以大规模地推出。 许多公司采用完全不同的方法。 许多公司将基础设施视为支出。 每个小组将使用完全不同的技术，并且几乎没有计划和如何构建系统的共性。 Google 视自己为一家系统工程公司，这是研究构建软件的一种非常新颖的方式。 +2. **跨多个数据中心仍然是一个尚未解决的问题**。 大多数网站位于一个和最多两个数据中心。 我们应该说，如何在一组数据中心之间完全分配网站是很棘手的。 +3. **如果您没有时间自己重新构建所有这些基础架构，请看一下 Hadoop **。 Hadoop 是此处介绍的许多相同想法的开源实现。**** +4. **平台方法的一个令人赞赏的优势**是初级开发人员可以在平台之上快速而自信地创建健壮的应用程序。 如果每个项目都需要创建相同的分布式基础架构轮子，您会遇到困难，因为知道如何做到这一点的人相对很少。 +5. **协同作用并不总是胡扯**。 通过使系统的所有部分协同工作，一项改进可以帮助他们。 改进文件系统，每个人都可以立即透明地受益。 如果每个项目使用不同的文件系统，那么整个堆栈就不会有持续的改进。 +6. **构建无需运行系统即可运行的自我管理系统**。 这使您可以更轻松地在服务器之间重新平衡资源，动态添加更多容量，使计算机脱机并妥善处理升级。 +7. **创建达尔文式基础结构**。 并行执行耗时的操作并赢得优胜者。 +8. **不要忽略学院**。 学术界有很多好的想法，这些想法无法转化为生产环境。 Google 所做的大部分工作都是现有技术，而不是大规模部署。 +9. **考虑压缩**。 当您有大量的 CPU 可供使用且 IO 有限时，压缩是一个不错的选择。 -### 合作 +好文章。 真的很好。 真的非常好文章。 真的真的真的真的好文章。 -* 文档存储区 +亚马逊拥有“云计算”功能，可以在此规模上为您提供更好的性价比。 -* 预览版 +真的很好.. / SG -* 视频转码 +我喜欢这篇文章...天哪，你知道你的东西。 最好的部分是，由 Google 制作的这些视频是您的参考框架。 我强烈建议您甚至进一步简化它。 我喜欢这些内容，您真的应该在 Scalability 2.0 下将这些内容添加到 iMarketingGuru 中。我将放置有关这些类型的可伸缩性的文章链接，您可以随时给自己很多链接爱，并继续进行下去。 维基。 我喜欢这个东西= o） -* 分享 +感谢您分享这些信息。 - * 链接 +真是胡扯。 +Google 只会进行搜索和搜索，它们不会在 gmail，google talk，SDK，电子表格，Checout 或任何其他服务中发挥作用。 +迟早您会弄清楚-当人们变得更聪明并停止按 Google 广告上的链接时-Google 奶牛将停止现金流... - * 权限 +内容丰富，但缺乏细节。 我确实同意上面的那个家伙，他们只是在搜索中大放异彩，他们需要在其他领域大力推广牛奶:) -* 标签 +很棒的内容。 真的很有用。 干杯! -* 评论 +感谢您分享此信息，它非常有用 -* 任务 +很棒的帖子！ +我想 Google 会以某种方式创建 Google 操作系统。 +它只是存在于云中并且可以使用的服务器和集群的集合。 :-) -* 建议 +作为对您的文章的深入研究的副作用，我将其翻译为德语： [http://habacht.blogspot.com/2007/10/google-architecture.html](http://habacht.blogspot.com/2007/10/google-architecture.html) -### 混合同步 +Google 负担得起所有这种结构^） -* 处理 Prem 数据时 +我将不得不保存并稍后重新阅读。 这里有很多细节可以帮助解释 G 的一些怪癖。 仅仅考虑其背后的庞大体系结构，只会让我的思想融化。 -* 大文件或低带宽 +Google 以前已经丢失了其电子邮件客户的数据。 不要对谷歌如此信服。 谷歌是一家拥有其他类似缺陷的公司。 他们还不像微软那么糟糕，但是给它一点时间，他们就会到达那里。 如果您想保护自己的数据安全，请自己做，并确保 99.9999％的时间都可以正常工作。 -* 离线访问 +非常有趣且内容丰富的文章！ +我发现它是我正在研究的某些项目的体系结构的重要参考。 -* 边缘缓存 +真的很好！ -### 基础架构优化 +完美的文章，谢谢。 Google 变得比搜索引擎更重要 -* 迁移到云 +优秀文章 +哪里描述 Google LAB：GWS-Google Web Server？ -* 优化保鲜库的成本 +Google 只是搜索者中的第一个！ 例如， [http://loadingvault.com](http://loadingvault.com) 或 [http://loadingvault.com]( quickshare search 和 google.com 之间的区别？这两个网站都在搜索 正确的信息！广告管理是一件非常好的事！ -* 合并存储库 +好。 谢谢。 :) -通常，Egnyte 连接架构分片并基于以下条件在不同级别缓存数据： +Quite informative but lacks the nity grity details. I do agree to the fellow above that they only shine in search they need to pitch hard in other areas to milk :) -* 数据量 +我曾经阅读过有关 MapReduce 体系结构的最佳文章。 -* 数据相互依存 +知道像 Google 这样的大公司如何运作总是很有趣的。 +谢谢.. -* 并发读取的级别 +给“什么废话”的人。 多么透明。 如果我们从主流中脱颖而出，就好像我们对某个主题有一些内在的，高超的知识，我们会显得聪明吗？ 本文并不将 Google 定位为最终的所有软件公司。 他们是搜索引擎，而且做得很好。 这是关于他们如何做好的。 真是的 如果它们“不如微软那么糟糕”-??? Microsoft 在 200 个国家/地区拥有 60,000 名员工。 您雇用多少人？ 我对这些消极，无知的人感到厌烦，这些人试图以牺牲别人的工作成果为代价看起来很聪明…… -* 并发写入级别 - -![](img/f8913d2219c8cabf370072889c0b44fb.png) - -， - -## Egnyte Connect 技术堆栈 - -### 云平台 - -1. Google 云端 - -2. Azure - -3. 托管数据中心 - -### 语言： - -1. Java - -2. Python - -3. 转到 - -4. C - -### 对象存储区 - -* Egnyte 对象存储区 - -* GCS - -* S3 - -* Azure - -### 应用服务器 - -* Tomcat - -### 数据库 - -* MySQL - -* Redis - -* BigTable - -* 数据存储 - -* Elasticsearch - -### 缓存 - -* Memcached - -* Redis - -* Nginx 用于基于磁盘的缓存 - -### 负载平衡器/反向代理 - -* HAProxy - -* Nginx - -### 消息队列 - -* Google Pub / Sub - -* 兔子 - -* 抄写员 - -* Redis - -### 部署管理 - -* 人偶 - -* Docker - -* Ansible - -* 詹金斯 - -* Gitlab - -* 调速器 - -### 分析 - -* 新遗物 - -* OpenTSDB / bosun - -* Grafana - -* MixPanel - -* 表格 - -* BigQuery - -### 其他 - -* ZooKeeper - -* Nagios - -* Apache FTP 服务器 - -* 孔 - -* ReactJS / Backbone / Marionette / JQuery / npm / Nightwatch - -* Rsync - -* PowerDNS - -* 服装 - -* 基于 REST API 的 SOA 体系结构。 - -* Java 用于驱动核心文件系统代码 - -* 用于支持客户端代码，某些微服务，迁移脚本，内部脚本的 Python - -* 原生 Android 和 iOS 应用 - -* 本机桌面和服务器托管的客户端，允许对整个名称空间进行交互以及混合同步访问 - -## 统计信息 - -* 3 个主要地区（其中一个在欧洲）使用 Google 互连连接到相应的 GCP 地区 - -* 500 多个 Tomcat 服务 实例 - -* 由 Tomcat / Nginx 提供支持的 500 多个存储节点 - -* 100 多个 MySQL 节点 - -* 100 多个 Elasticsearch 节点 - -* 50 多个文本提取 实例 （自动缩放） - -* 100 多个 HAProxy 实例 - -* 许多其他类型的服务 实例 - -* 存储在我们服务器和其他对象存储区（例如 GCS，S3 和 Azure Blobstore）中的数十 PB 数据 - -* 在 Elasticsearch 中建立索引的多个 TB 提取内容 - -* 数百万个桌面客户端与云同步文件以进行脱机访问 - -* 数百万台式客户端以交互方式访问文件 - -## 认识您 - -### 您的系统名称是什么，我们在哪里可以找到更多信息？ - -Egnyte Connect 是内容协作和数据管理平台。 CFS（云文件系统），EOS（Egnyte 对象存储），内容安全性，事件同步，搜索服务，基于用户行为的推荐服务构成了系统的主要部分。 您可以在我们博客的 [对于技术人员](https://www.egnyte.com/blog/category/for-the-techies/) 部分中找到更多相关信息。 - -### 您的系统使用什么功能？ - -作为内容协作和数据管理平台的 Egnyte Connect 被成千上万的客户用作唯一的 安全内容平台来满足他们的所有文档管理需求。 它是为承载各种文件服务 并为它们的现有文件存储库启用云而构建的。 可以从各种端点（例如 FTP，WebDAV，移动，公共 API 和浏览器）访问它，并具有强大的审核和安全组件。 - -### 您为什么决定构建此系统？ - -在 2007 年，企业开始变得更加分散。 客户正在使用多种设备来访问他们的文件，因此需要使这种体验尽可能地顺畅。 我们构建了 Egnyte Connect-一种安全的分布式文件系统，该系统将 Hybrid Sync 与 Cloud File System 相结合，可以满足各种业务需求中企业的内容协作需求。 随着本地和云存储库中数据的分散，以及由于 GDPR 等举措而增加的合规性需求，我们构建了 Egnyte Protect 来帮助客户满足其合规性和治理需求。 - -### 您的项目经费如何？ - -Egnyte 最初是一家自举公司。 后来，我们继续从高盛，Google Ventures，KPCB，Polaris Partners 和 Seagate 的多轮融资中筹集了 1.375 亿美元的 [](https://www.crunchbase.com/organization/egnyte#/entity)。 - -### 您的收入模式是什么？ - -Egnyte 不提供免费帐户。 客户从 15 天的免费评估试用期开始，之后，他们将根据席位数量，存储空间和其他企业功能转换为带有收入模型的付费帐户。 - -### 您如何销售产品？ - -我们从 SEM / SEO 开始，但随着时间的增长，我们使用了许多渠道来为社会客户，社交媒体，商务开发，贸易展览，SEM，SEO，入站营销和企业级客户进行高接触销售。 - -### 您从事这项工作多久了？ - -Egnyte 成立于 2007 年。它已有 12 年的历史，现金流量为正。 - -### 您的系统多大？ 尝试感受一下系统的工作量。 - -我们存储数十亿个文件和数十 PB 的数据。 在“ Egnyte connect”中，根据 New Relic，我们平均观察到平均每秒超过 10K API 请求，平均响应时间为< 60ms。 由于安全港规定和位置相近，我们允许从 3 个主要地区访问。 有关更多信息，请参见统计信息部分。 我们的“ Egnyte Protect”解决方案还持续监控内容和对许多客户的合规性，治理和安全漏洞的访问。 - -### 您提供多少份文件？ 多少张图片？ 多少数据？ - -我们存储数十亿个文件和数十 PB 的数据。 我们存储各种文件。 Egnyte 存储的前 5 个文件扩展名是 pdf，doc / docx，xl​​s / xlsx，jpeg 和 png。 - -### 免费用户与付费用户的比例是多少？ - -我们所有的用户均为付费用户。 我们提供 15 天的免费试用期，然后将其转换为付费帐户。 - -### 在过去一个月中有多少个帐户处于活动状态？ - -我们所有的客户都是付费帐户，并且每个月几乎所有人都活跃。 我们满足他们安全的内容平台需求，谁在家不用电？ - -## 您的系统如何设计？ - -### 您的系统的体系结构是什么？ - -我们使用基于 REST 的面向服务的体系结构，它使我们能够独立扩展每个服务。 这也使我们能够将某些后端服务移至公共云中托管。 所有服务都是无状态的，并使用数据库或我们自己的对象存储进行存储。 - -10000 英尺的 Egnyte Connect 服务概述如下所示。 - -![](img/3d5e6054b4bacef5d0f2733fb962651b.png) - -[典型请求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的 10000 英尺总览如下 - -![](img/19d4979dbb2079dbc0eac2371a21067a.png) - -约 10000 英尺的 [搜索架构](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下 - -![](img/c015db1edce1869cc6373704f2683bb5.png) - -### 您的系统面临哪些特定的设计/架构/实施挑战？ - -最大的 架构 挑战包括： - -1. 节俭地扩展文件存储 - -2. 扩展元数据访问 - -3. 文件与桌面客户端的实时同步 - -4. 带宽优化 - -5. 冲击隔离 - -6. 缓存（分布式和内存中） - -7. 功能首次展示 - -### 您是如何应对这些挑战的？ - -1. 对于存储，我们编写了自己的存储，现在我们使用可插拔的存储体系结构来存储到任何公共云，例如 S3，GCS，Azure ... - -2. 为了扩展元数据，我们移至 Mysql 并开始使用分片。 在某个时候，我们暂时投入了更多的硬件来腾出空间，以便一层一层地剥去“鳞屑洋葱”。 - -3. 对于实时同步，我们必须更改同步算法，使其更像 Git，客户端接收增量事件并尝试与云状态进行最终的一致同步。 - -4. 为了推出功能，我们构建了一个自定义设置服务，允许工程师在功能标志后面编写代码。 这样，即使在睡眠者模式下，您也可以释放代码并收集数据，然后按客户，用户或主机组或 POD 或数据中心启用功能。 有了这种控制水平，即使是新工程师也可以放心地在功能标记后面编写代码并将其发布到生产环境中，而不必担心停机时间。 - -5. 监视，监视和监视。 您无法优化无法衡量的内容。 不利的一面是，在某些时候，我们监控得太多了，以致于我们无法专注于所有指标。 我们必须转移注意力，并依靠诸如 New Relic，bosun，ELK，OpenTSDB 和自定义报告之类的异常检测工具，使我们能够专注于从绿色->黄色->红色趋势发展的问题。 目的是在客户通知 之前，将它们捕获为黄色并且 [时捕获它们。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) - -### 您的系统如何发展以应对新的扩展挑战？ - -我们已经多次重新构造了许多层。 我将尝试列出过去 7 年中核心元数据，存储，搜索层的一些迭代。 - -1. 版本 1：在 Lucene 中搜索 Lucene 中的文件元数据，通过 NFS 安装在 DRBD Filer 中存储的文件。 关键点： Lucene 更新不是实时的，必须替换。 - -2. 版本 2：Berkeley DB 中的文件元数据，通过 NFS 挂载的 DRBD Filers 中存储的文件，在 Lucene 中搜索。 关键点： 我们打破了 NFS 的限制，它左右 and 住，必须用 HTTP 代替。 - -3. 版本 3：Berkeley DB 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 Lucene 中搜索。 关键点 ：即使分片的 Berkeley DB 在压力下也令人窒息，并且由于恢复需要数小时而导致数据库崩溃，因此必须更换它。 - -4. 版本 4：MySQL 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 Lucene 中搜索。 关键点： 公共云开始变得便宜。 - -5. 版本 5：MySQL 中的文件元数据，存储在 EOS / GCS / S3 / Azure 中并通过 HTTP 提供的文件，在 Lucene 中搜索。 阻塞点： 搜索开始阻塞，必须替换。 - -6. 版本 6：MySQL 中的文件元数据，通过 HTTP 服务的 EOS / GCS / S3 / Azure 中存储的文件，在 Elasticsearch 中搜索。 这是当前的体系结构。 - -7. 版本 7（未来）：将所有计算移至公共云，提供更多服务以实现影响隔离，动态资源池以有效管理宠物和牛。 - -### 您是否使用任何特别酷的技术或算法？ - -* 我们在核心服务和服务之间进行呼叫时使用指数补偿，以使用断路器来避免打雷。 - -* 我们使用核心服务节点资源上的公平份额分配来处理传入请求。 核心服务节点上的每个传入请求都被标记并分为各种组。 每个组都有专用的容量，如果一个客户每秒发出 1000 个请求，而另一个客户每秒发出 10 个请求，则此系统将确保其他客户不会因为邻居吵闹而挨饿。 诀窍是，如果您是目前使用该系统的唯一客户，则可以全力以赴，但是随着更多客户同时出现，您可以在其中共享容量。 对于某些大型客户，我们会分配专用池以确保一致的响应时间。 - -* 带有 SLA 的某些核心服务被隔离在 POD 中，这确保了一个不好的客户不会阻塞整个数据中心，但是这可能很快就需要轮回。 - -* 我们在桌面同步客户端代码中使用基于事件的同步，因为发生服务器事件时，它们会从服务器推送到客户端，并且客户端会在本地重播它们。 - -* 我们采用大规模数据过滤算法，以使大型客户端集群与 Cloud File System 同步。 - -* 我们根据问题陈述使用不同类型的缓存技术。 很少有以下口味： - - * 传统 - - * 内存中的-简单的 - - * 不可变的对象 - - * 内存中的大型数据集 - - * 用于在各个进程之间实现高度一致性的锁 - - * 已实施部分更新，以避免出现 GC - - * 内存中-高容量变异数据集 - - * 粗粒度无效 - - * 细粒度无效 - - * 基于磁盘的缓存 - -### 您做什么工作是与众不同的，人们可以从中学到什么？ - -专注于启动的核心功能，如果您遇到技术难题，就必须为其构建自定义内容，然后卷起袖子继续前进。 有很多独特的东西，但是基于事件的同步存储层绝对值得学习，这里有更多详细信息。 [Egnyte 对象存储库](https://www.egnyte.com/blog/2013/07/how-egnyte-implements-hybrid-object-stores-using-public-clouds-to-enhance-customer-experience/) 和 Egnyte [规范文件系统](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 - -### 您学到了什么？ - -* 您无法优化您无法测量的内容：测量所有可能且相关的内容，然后首先优化 80％处于使用状态的系统部分。 - -* 当您身材矮小的时候，请慢慢介绍技术，不要试图从中找到解决当前问题的理想工具。 编码是生命周期中最简单的部分，但是如果您拥有太多的技术，则其维护（如部署/操作/学习曲线）将非常困难。 随着您变得更大，您的部署中将有足够的脂肪来逐步进行服务划分。 学习保留一个或两个服务模板来实现微服务，不要为每个服务使用不同的技术堆栈。 - -* 作为初创企业，有时您必须快速行动。 介绍您现在可以做的最好的解决方案，如果发现有牵引力，请随着时间的推移重新设计该解决方案。 您可以尝试 10 种不同的方法，而只有 1 种方法可以看到牵引力，因此请快速进行一些操作，然后在看到牵引力的方法上重新架构，以适应业务规模。 - -* 寻找单点故障，并不懈地追查它们。 付出额外的努力来解决使您彻夜难眠的问题，并尽快从防御性转变为进攻性模式。 - -* 在 SOA 中，构建断路器以尽早减轻负载，如果服务受阻，则开始发送 503s。 与其惩罚所有人，不如看看您是否可以公平分配资源并仅惩罚滥用请求。 - -* 在服务使用者中添加了自动修复功能，服务可能会停止运行，并且像台式机客户端或其他服务这样的使用者可以进行指数补偿以释放服务器上的压力，并在服务再次起作用时自动修复。 - -* 始终可用：请客户提供服务级别的断路器和断路器。 例如，如果通过 WebDAV 或 FTP 访问文件系统存在性能问题，并且需要 4 个小时来修复，那么在这 4 个小时内，您可以在 kong / firewall 杀死 FTP / WebDAV 并要求客户使用 Web UI 或其他 工作机制。 同样，如果一个客户造成了导致系统阻塞的异常，则可以暂时为该客户禁用该客户或服务，并在解决问题后重新启用它。 为此，我们使用功能标志和断路器。 - -* 对于高度可扩展的服务，离开 Java 进程的成本很高，即使去了 Memcache 或 Redis 也是如此，因此我们对某些高度使用的数据结构（如访问控制计算，功能标志，路由元数据等）进行了具有不同 TTL 的内存中缓存。 。 - -* 我们看到一种有关处理大数据集的模式。 优化代码并挤走柠檬中的每一滴都是徒劳的，我们最终可能会使代码变得复杂且柠檬水苦涩。 通常，最简单的解决方案来自返回到绘图板，看看我们是否可以： - - * 通过使用启发式方法来减少我们需要处理的数据集大小 - - * 重组了我们在内存或磁盘中存储数据的方式。 - - * 在写时对数据进行规范化，并避免联接。 - - * 基于时间的过滤，例如存档较早的数据。 - - * 在多租户数据结构中创建较小的碎片。 - - * 使用事件更新缓存数据集，而不是完全重新加载。 - -* 保持简单：每个月都有新工程师加入，因此目标是从第一周开始就提高他们的工作效率-简单的架构可确保轻松上岗。 - -### 您为什么成功？ - -牵引力胜过一切。 当 EFSS 市场刚刚爆发时，我们达到了产品/市场契合度。 良好的执行力，以客户为中心，管理团队遵守财务纪律的时机可以成功。 许多竞争者采用了免费增值模式并筹集了一大笔资金，但是从第一天开始我们就开始收费，这使我们能够专注于随着市场需求的扩大而发展解决方案/团队。 专注于付费客户使我们能够提供企业级解决方案，而无需支付免费增值罚金。 - -### 您希望自己做些什么？ - -我希望当我们开始时，公共云不会像成本那样高。 我也希望我们从第一天开始就使用 SOA，花了一些时间才到达那里，但是现在我们就在那里。 - -### 您不会更改什么？ - -体系结构应具有延展性。 四年前，对于给定的问题，我有不同的答案，但是目前，我不确定。 我的意思是，随着您规模的扩大，过去 2 年前有效的设计模式和策略可能使您从防御性定位转向进攻性定位可能会在压力下屈服或变得成本过高。 只要更改将使系统变得有弹性或带来 10 倍的更改并为我们再购买 3-4 年的规模，我便会继续尝试更改它。 我不能在两年后发表评论，我会有同样的想法，他们可能会改变。 当您遇到下一个增长突增时，架构会发生变化。 - -### 您应该做多少前期设计？ - -很好的问题。 答案是“取决于”， - -* 如果您要设计核心存储层或核心元数据层之类的东西，那么再多花 2 周的时间就不会有多大伤害。 当我们在核心元数据层上从 Berkeley DB 迁移到 MySQL 时，我承受着很大的压力，我想到了一条捷径，当我通过我们的 CTO 运行它时，他建议花一些时间，“做正确的事情”。 ”作为回顾，这是一个极好的决定。 - -* 对于公共 API，最好做一个不错的前端设计，因为您没有第二次机会对其进行更改，并且必须在未来 4-5 年内进行维护。 - -* 如果要处理其 PB 级数据并带来巨大麻烦，那么我将再给它一个月的时间并进行更多的 POC。 - -* 但是，如果您要为内部服务设计一些东西并将其迁移到新的体系结构不会花费一年的时间，那么我建议您进行非常少的前端设计，并且只需快速构建版本并随着使用量的增长对其进行迭代 。 - -### 您如何考虑将来更改架构？ - -* 从静态 POD 转移到动态 POD，并无缝处理宠物和牛。 - -* 提供更具弹性的服务并隔离影响。 - -* 将我们的整个计算移至公共云，同时保留数据中心用于提供文件。 这将使我们能够在负载到来时自动放大/缩小。 我们已经使用公共云来自动扩展一些异步处理，例如视频转码，文本提取，数据迁移，搜索等。 - -* 一旦进入云，请使用更多自动缩放服务，例如 BigTable，PubSub，Spanner 等。 - -* 将我们的部署从 VM 迁移到 Kubernetes 中的容器，以提供挂起的服务。 - -* 自动化剩余数据库的架构管理 - -* 通过重新构建从某些增长最快的表中删除联接。 - -* 重写元数据的缓存层，并使用 Redis 数据结构代替 Memcache。 - -* 将频繁使用的流从强一致性转换为最终一致性。 - -## 您的团队如何设置？ - -### 您的团队中有多少人？ - -大约 700 名员工和承包商。 有 200 名工程师（DevOps / OPS / QA / Developers /…），其余为销售，市场营销，支持，产品管理，人力资源等。 - -### 他们在哪里？ - -最初是一支分布相当分散的工程团队，但现在主要吸引了印度波兰山景城的人。 一些像我这样的远程员工 和其他一些员工在家工作。 - -### 谁扮演什么角色？ - -这是一个很大的团队，我们有产品经理，UX 团队，DevOps，Scrum 团队，架构师，工程师扮演各种角色。 最初，工程团队很平坦，每个人都会向工程副总裁报告，但现在我们在两者之间增加了一层管理。 - -### 您是否有特定的管理理念？ - -如果您开发某些产品，那么您便拥有该产品的生命周期，这意味着您将与质量保证和 DevOps 一起使用，以确保产品经过测试/部署。 投入生产时，您可以使用各种内部工具（例如 New Relic / Grafana，Kibana）对其进行监视，如果存在回归，则可以对其进行修复。 我也是 1 人 1 任务理念的忠实拥护者，通过这种方式，如果工程师碰壁，他将找到某种最终克服它的方法，而不是太早放弃。 - -### 如果您有分散的团队，该如何工作？ - -自治，1-1 交流给他们带来挑战性的问题，亲自照顾和直接挑战，他们会受到激励。 - -### 您的开发环境是什么？ - -* 适用于服务器团队的 Ubuntu - -* UI 团队使用 Windows / mac 并连接到用于 REST API 服务器的本地 Ubuntu VM 或连接到共享的 QA 实例 - -* Eclipse /想法 - -* 适用于构建的 - -* Maven - -* 码头工人 - -* Gitlab - -* Jenkins - -* 汇合 - -* JIRA - -* Google 办公套件 - -* 松弛 - -### 您的开发过程是什么？ - -我们使用 Scrum，并为云文件系统团队提供每周发布。 我们使用 git-flow 的变体，对于每个票证，我们克隆存储库，并对每个合并请求运行自动化测试。 合并请求必须经过 2 位工程师的批准，然后才能解决 JIRA 故障单。 解决后，我们的管道将接管工作，而票务将接下去的下一班火车。 下一版本的培训已通过自动化 REST API 测试和一些手动烟雾测试进行了验证。 - -我们吃了自己的狗粮，代码在发布前 2-3 天送达了 UAT（供所有员工使用），我们发现了自动测试未发现的任何意外情况。 我们每个星期三进行生产部署， [每天监视新文物，并报告任何异常](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 的异常报告。 我们在一周中更改了部署，以实现工作与生活之间的平衡，并且通过这种方式，我们将让所有工程师可用，以防发布出现问题。 - -如果这是一项长期运行的功能，则工程师通常会在功能标志后面进行工作，并在各个阶段以 sleeper 模式提交代码，因此，每周（而不是大爆炸）都要测试他的代码。 我们也以一次迁移 1 个客户并仅为该客户打开功能的方式处理大型迁移，我们的一些大型迁移已运行 3-4 个月。 - -### 您有什么可以做的不同还是感到惊讶？ - -许多工程师在家工作，令人惊讶的是，有了自主权，许多远程员工像总部员工一样富有生产力和积极性。 - -## 您使用什么基础架构？ - -### 您使用哪种语言来开发系统？ - -主要是 Java / Python，以及 Go / C 中的一些小服务 - -### 您有多少台服务器？ - -我们有约 3000 多个由人偶管理的实例。 - -* 500+ Tomcat service instances - -* 500+ Storage nodes powered by Tomcat/Nginx - -* 100+ MySQL nodes - -* 100+ Elasticsearch nodes - -* 50+ Text extraction instances(autoscaled) - -* 100+ HAProxy instances - -* 和许多其他类型的服务 实例 - -### 如何将功能分配给服务器？ - -我们使用面向服务的体系结构，并根据服务类型分配服务器。 一些顶级服务是： - -* 元数据 - -* 储存空间 - -* 对象服务 - -* Web UI - -* 索引 - -* 同步 - -* 搜索 - -* 审核 - -* 内容智能 - -* 实时事件传递 - -* 文本提取 - -* 集成 - -* 缩略图生成 - -* 防病毒软件 - -* 垃圾邮件 - -* 预览/缩略图 - -* Rsync - -* API 网关 - -* 结算 - -* FTP / SFTP - -* 等等。 - -![](img/3d5e6054b4bacef5d0f2733fb962651b.png) - -### 如何配置服务器？ - -大多数服务都是伪造的，并且可以在 VM 上运行，我们仅针对 MySQL，Memcached 和存储节点等少数设备运行物理服务。 我们使用第三方根据模板来配置服务器，并将其放置在数据中心中，以供使用。 但是我们已经开始将一切迁移到公共云的工作，因此最终，一切都将在 Kubernetes 中运行。 但是，挑战在于如何在不停机的情况下如何在比赛中更换赛车发动机。 - -### 您使用什么操作系统？ - -CentOS7 - -### 您使用哪个 Web 服务器？ - -Nginx，HAproxy。 在一些旧的流程中使用了 Apache，但随着时间的流逝，它将被弃用。 - -### 您使用哪个数据库？ - -MySQL 和 Redis。 过去我们曾使用过其他数据库，例如 Berkeley DB，Lucene，Cassandra，但由于其对工程师/操作人员的熟悉程度和可扩展性，我们逐渐将所有数据库迁移到 MySQL。 有关更多信息，请参见 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 - -对于某些流，我们还使用 OpenTSDB，BigTable，Elasticsearch。 - -### 您是否使用反向代理？ - -是 Nginx 和 HAProxy - -### 您是否并置，使用网格服务，使用托管服务等？ - -我们并置，我们还使用公共云。 - -### 您的存储策略是什么？ - -我们首先创建自己的服务器，然后在机器中打包尽可能多的硬盘驱动器，我们过去将它们称为 DRBD Filers。 我们这样做是因为 AWS 成本过高。 我们已经评估了 [GlusterFS](https://www.gluster.org/) ，但当时它无法扩展以满足我们的需求，因此我们构建了自己的。 加班 S3 变得便宜了，GCS / Azure 诞生了，我们将存储层设计为可插入的，因此现在客户可以决定要使用哪个存储引擎（例如，Egnyte，S3，GCS，Azure 等）。 此时，我们在公共云中存储了 1 个 DR 副本，并与我们一起存储了 1 个副本，但是最终我们将使用我们的数据中心作为直通缓存，因为云中的计算便宜，但是带宽昂贵。 - -### 您如何增加产能？ - -我们已基于 Newrelic，Grafana 和其他统计数据提供了半自动化的容量规划工具，并根据观察监控报告中的关键指标并预定一些额外的容量，进行了定期的容量规划会议。 现在，某些服务已启用云服务，我们只是根据队列大小自动缩放它们。 - -### 您是否使用存储服务？ - -是 Egnyte，S3，GCS，Azure， - -### 您如何处理会话管理？ - -我们多次重写了体系结构，目前，有 99％的服务是无状态的。 仅服务 Web UI 的服务使用会话，我们在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性会话，但最终，我的计划是也 使用 JWT 或类似方法实现无状态。 - -### 您的数据库是如何设计的？ 主从？ 碎片？ 其他？ - -我们几乎对所有具有自动故障转移功能的数据库都使用了 Master-Master 复制，但是在一些突变程度很大的数据库上的切换是手动完成的，我们遇到了一些问题，其中由于复制滞后，自动切换会导致应用程序数据不一致，我们 需要重新架构一些核心文件系统逻辑来解决此问题，我们最终将完成此工作。 下面是有关处理数据库升级的问题，详细回答了有关数据库体系结构的更多详细信息。 - -### 您如何处理负载平衡？ - -我们根据客户使用 DNS 访问系统的 IP 进行地理平衡，并在数据中心内使用 HAProxy 将其路由到相应的 POD，并在内部 POD 中再次使用 HAProxy 路由 - -### 您使用哪个 Web 框架/ AJAX 库？ - -我们已经多次更改了 UI，这是一直在变化的一件事。 过去，我们不得不使用 ExtJS，YUI，JQuery，而不能使用其他东西。 最新的迭代基于 ReactJS / Redux 以及 Backbone / Marionette 上的一些旧代码。 - -### 您使用哪些实时消息传递框架？ - -我们使用 [大气](https://github.com/Atmosphere/atmosphere) ，但最终，我们将其替换为 NodeJS - -### 您使用哪个分布式作业管理系统？ - -为此，我们使用 Google Pubsub，RabbitMQ 和基于 Java / Python 的消费者服务。 - -### 您的网站是否有标准 API？ 如果是这样，您将如何实施？ - -我们的 API 分为 3 种类型：- - -1. 公共 API： 这是我们向第三方应用程序工程师和集成团队以及我们的移动应用程序公开的 API。 我们会按照适当的弃用工作流程来弃用/升级 API 签名，并且更改始终向后兼容。 我们使用 Mashery 作为网关，API 记录在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) - -2. 适用于我们客户的 API： 此 API 对我们客户而言是内部的，如果我们以外的人使用此 API，我们不保证向后兼容。 - -3. 服务之间的内部受保护的 API： 这是服务在我们的数据中心内部用于相互通信的 API，无法从外部防火墙调用。 - -### 您的对象和内容缓存策略是什么？ - -我们存储了 PB 级的数据，但无法缓存所有数据，但是如果客户在给定的 15 天时间内拥有 5000 万个文件，则他可能只使用其中的 100 万个。 我们有基于 tomcat / Nginx /本地文件系统的缓存文件管理器节点，它以 LRU 方式运行。 我们可以弹性地增加减少缓存文件服务器的数量。 我们最大的问题之一是上传速度，如何从世界任何地方尽可能快地将数据上传到 Egnyte，为此，我们构建了特殊的 Network pops，如果您好奇的话可以在阅读更多内容 [为 Egnyte 客户加速数据访问](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) - -Memcached / Redis 用于缓存元数据，我们使用单独的 Memcached 池来缓存长期存在的静态数据和文件系统元数据。 核心文件系统元数据非常庞大，不适合当前的 Memcached 节点，并且会逐出最近使用的其他类型的数据。 为了防止这种情况，我们使用 3 种类型的池，应用程序代码决定在哪里查找哪种数据。 我们允许在文件系统 Memcached 缓存中逐出，并在其他种类的 Memcached 池中争取零逐出。 对于不同种类的数据，我们也使用不同的对象到期时间。 对于我们一些频繁使用的数据（例如客户信息或分片映射），即使每个请求都转到 Memcache，也会因某些请求（例如文件夹列表）而减慢速度，因此我们在每个 JVM 上对该数据进行内存内缓存，并刷新数据 基于自定义 TTL 或我们使用某种 pub-sub 机制刷新它。 - -缓存中的两个最大难题是权限和事件。 对于权限数据，我们已经多次重选了该层，最近我们编写了一个 TRIE 来有效地缓存该层。 - -对于事件，我们将其缓存在 Memcache 中，但是有可能在夜间为客户发布了约 10 万个事件，而在早上 9:00 AM 突然有 3 万个人打开了笔记本电脑，现在每个人都希望这些 10 万个事件可以 使他们的系统一致。 这是一个有趣的规模问题，因为这将需要您在短时间内（例如 15 分钟）处理 30B 事件，并且仅发送用户有权访问的事件。 由于事件是不可变的，我们将它们在 Memcache 中缓存了 12 个小时，但是即使它们从 Memcache 下载相同的事件那么多次也会导致网络问题。 最终，我们在短时间内将事件缓存在内存中，并且随着我们进行许多年轻一代的收集工作，还调整了这些节点上的 GC 设置。 与其他节点相比，我们还将这些节点放置在速度更快的网络上，但仍然没有解决这个问题:)。 - -### 您的客户端缓存策略是什么？ - -对于我们的 Web UI，我们使用 requireJS 和其他各种方式来仅下载所需的模块。 我们的 Mobile 和 Desktop 客户端丰富使用本地文件系统作为缓存。 - -### 您使用哪些第三方服务来帮助您构建系统？ - -我们使用了一些 Google 服务，Azure，New Relic，Authy，MixPanel，Flurry，Tableau，但大多数核心组件都是由我们构建的。 - -## 您如何管理系统？ - -### 您如何检查全局可用性并模拟最终用户性能？ - -我们使用不同 AWS 区域中的节点来一致地测试带宽性能。 我们还使用内部 haproxy 报告来绘制客户观察到的上载/下载速度，并主动寻找它们，并使用网络弹出消息和其他策略来加速数据包。 - -![](img/6ffa16c86d1956a9ff0be037d6021022.png) - -### 您如何健康检查服务器和网络？ - -Nagios，Grafana 和 New Relic 以及一些内部主动异常分析被使用。 有关更多详细信息，请参见此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) - -### 如何绘制网络和服务器统计数据以及趋势图？ - -我们使用 Grafana，Kibana，Nagios 和 New Relic。 - -![](img/dedeb468380c2680e693cd8a5743a335.png) - -![](img/293ca1407b4f34397f578ec21c96afd2.png) - -### 您如何测试系统？ - -硒，Junit，鼻子，Nightwatch 和手动测试。 单元，功能，集成和性能测试的组合。 - -### 您如何分析效果？ - -New Relic 用于监视应用程序性能。 我们还使用本地框架生成了大量内部应用程序指标。 我们使用 Grafana / Nagios / Kibana，内部工具和其他工具来监视系统其他部分的性能。 有关更多详细信息，请参见此博客文章 [分布式系统中的调试性能问题](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) - -### 您如何处理安全性？ - -专门的安全团队在每个版本之前都会运行自动化的安全基准测试。 连续自动笔测试正在生产中运行。 我们还使用漏洞赏金计划，并与 whitehat 测试公司合作。 一些客户使用第三方进行自己的安全性测试。 - -## 您如何处理客户支持？ - -我们有专门的 24X7 分布式客户成功团队，我们使用 Zendesk 和 JIRA - -## 您如何确定要添加/保留的功能？ - -### 您是否实施网络分析？ - -我们使用 Google Analytics（分析），Mixpanel，Flurry 来衡量功能使用情况 - -### 您是否进行 A / B 测试？ - -是的，我们使用功能标记进行 A / B 测试。 有关更多信息，请参见 [在 Egnyte 使用功能标志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) - -### 您要运行多少个数据中心？ - -3 个主要数据中心，包括欧洲的一个（由于安全港规则） 和遍布世界的网络流行音乐。 - -### 您的系统如何部署在数据中心中？ - -Puppet / Ansible 用于部署大多数新代码。 - -### 您使用哪种防火墙产品？ - -帕洛阿尔托网络 - -### 您使用哪个 DNS 服务？ - -NS1 - -### 您使用哪些路由器？ - -思科 - -### 您使用哪些开关？ - -Arista - -### 您使用哪个电子邮件系统？ - -我们结合使用 SendGrid 和我们自己的 SMTP 服务器。 - -### 如何备份和还原系统？ - -对于 MySQL，我们使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，对于 Elasticsearch，该数据被复制 3 次。 对于客户文件，我们将其复制 3 次，并将 1 个副本存储在 DR 公共云中。 如果存储 Filer 无法恢复，我们将丢弃它，添加一个新 Filer 并再次复制副本。 对于某些客户，我们还会将其数据复制到他们选择的提供商。 对于使用 S3，Azure 或 GCS 作为可插拔存储层的客户，它将确保复制以防止数据丢失。 - -### 如何进行软件和硬件升级？ - -大多数节点是无状态的，并且有状态组件具有主动-主动故障转移。 通过将节点从池中取出并进行升级并将其放回池中来处理升级。 我们使用 jenkins + Ansible + puppet 和自定义自动化。 - -### 您如何处理升级时数据库架构的重大更改？ - -不同的服务使用不同类型的数据库，并且它们以不同的方式升级。 在 10000 英尺处，它们如下图所示： - -![](img/4424662bfcfaca90969ec39e8fa0dbb4.png) - -1. EOS DB 存储对象元数据并且增长非常快，它经过分片，并且我们将继续添加更多此类数据。 - -2. MDB 的增长速度更快，经过了分片，并且我们会继续增加更多。 - -3. DC_central 是一个 DNS 数据库，并且保持相当静态。 我们运行了许多此副本以实现可伸缩性。 - -4. Pod_central 具有快速变异的数据，但每个表的增长量不超过 2000 万行。 我们运行了许多此副本以实现可伸缩性。 - -* 每个数据库模式始终是向前和向后兼容的，即我们绝不会在同一发行版中删除列和代码，我们首先在停止使用该列的发行版 1 中部署代码，而在发行版 2 中我们删除该列。 - -* 非分片数据库每周更新一次。 它们是存储各种功能驱动表的表。 我们目前在生产环境中使用脚本对其进行升级，但是我们在质量检查中使用 Liquibase，并且正在逐步将其应用于生产环境 - -* 使用自动脚本进行分片的数据库新列更改 - -* 分片数据库迁移是一件痛苦的事情，因为我们有 12000 多个分片并且还在不断增长，您无法在 1 小时的升级窗口中完成。 方法是： - - * 实时代码根据需要迁移行。 这意味着迁移可能需要几个月的时间。 - - * 使用功能标记进行迁移，您同时拥有新旧代码，并且在后台迁移客户，然后翻转标记以将其切换到新代码路径而无需停机，更多的是 [此处](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此处](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) - - * 当我们从 Lucene 迁移到 ElasticSearch 时，除了重新索引所有内容外，我们别无选择，我们使用了 [功能标记](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) ， -4 个月完成。 - -* 模式一致性检查器报告可确保升级后所有数据中心中的所有模式均相同。 - -### 您是否有单独的运营团队来管理您的网站？ - -是的，我们有一个专门的生产工程师，SRE 和一个 IT / Ops 团队，负责监视和管理生产。 但是正如我之前所说，构建此功能的工程师负责制定决策，因此他们将深入参与监视指标并解决生产问题。 - -## 其他 - -### 您欣赏谁？ - -AWS ：他们的创新步伐令人赞叹。 - -Google ：它们的工具如 BigQuery，Kubernetes 很棒。 - -Elasticsearch： 其余的 API 简单性和架构很棒。 我们用一个 TB 的数据和一个工程师来管理一个 100 多个节点的集群。 - -MySQL / Memcache： 它们简单，快速且很棒。 - -Eclipse / Jenkins ：插件架构很好。 - -### 您是否模仿了其他人的公司/方法？ - -我们是 [http://highscalability.com/](http://highscalability.com/) 的常规读者，许多设计都受到它的启发。 - -* POD 架构的灵感来自 Tumblr 的 Cell 架构。 这不是精确匹配，但是隔离故障的概念是相同的。 - -* 受 Facebook 启发的架构在 12 个小时后会在 Memcached 和刷新键中产生抖动。 - -* 受 [http://highscalability.com/上一些文章的启发，将](http://highscalability.com/) [指纹添加到每个数据库查询](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) - -我们正在招聘，请在 [职位页面](https://www.egnyte.com/jobs/) 中查看我们，并在 [与我们联系 [受电子邮件保护]](/cdn-cgi/l/email-protection) 。如果您有兴趣成为 [Egnyte](https://www.egnyte.com) 令人惊叹的团队的一员。 \ No newline at end of file +多数民众赞成在一个页面上收集的很好的信息收集。 \ No newline at end of file diff --git a/docs/32.md b/docs/32.md index d548ebc..1899f85 100644 --- a/docs/32.md +++ b/docs/32.md @@ -1,287 +1,155 @@ -# 从裸机到 Kubernetes +# 第二人生架构-网格 -> 原文： [http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html](http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html) +> 原文： [http://highscalability.com/blog/2008/12/20/second-life-architecture-the-grid.html](http://highscalability.com/blog/2008/12/20/second-life-architecture-the-grid.html) -![](img/6a1d9f7a6234c97845d7e14fa51b4df5.png) +**更新：** [演示：第二人生的体系结构](http://www.infoq.com/news/2008/12/Second-Life-Ian-Wilkes)。 *系统工程副总裁 Ian Wilkes 介绍了流行游戏“第二人生”使用的体系结构。 Ian 介绍了该体系结构首次亮相的过程，以及随着用户和功能的增加，它如何发展了多年。* -*这是位于旧金山的零售服装公司和众筹平台 [Betabrand](https://www.betabrand.com) 的首席工程师 [Hugues Alary](https://www.linkedin.com/in/huguesalary/?locale=en_US) 的特邀帖子。 本文最初在此处发表[。](https://boxunix.com/post/bare_metal_to_kube/)* +[第二人生](http://secondlife.com/whatis/)是由其居民创建的 3D 虚拟世界。 虚拟世界有望在 Internet 上越来越流行，因此其架构可能会引起人们的兴趣。 尤其重要的是开放的虚拟世界或虚拟宇宙的外观。 +*当视频游戏符合 Web 2.0 时会发生什么？ [metaverse](http://www.metaverseroadmap.org/overview/)* 发生了什么。 -* [早期基础架构](#_early_infrastructure) - * [VPS](#_vps) - * [机架空间](#_rackspace) - * [OVH](#_ovh) -* [硬件基础结构](#_hardware_infrastructure) - * [可伸缩性和可维护性问题](#_the_scalability_and_maintainability_issue) - * [扩展开发流程](#_scaling_development_processes) -* [Docker](#_the_advent_ofdocker) 的出现 -* [调速器](#_kubernetes) - * [学习 Kubernetes](#_learning_kubernetes) - * [正式迁移](#_officially_migrating) - * [开发/分阶段环境](#_the_developmentstaging_environments) - * [在](#_a_year_after)之后一年 +# 信息来源 -如何将 [Betabrand](https://www.betabrand.com) 的裸机基础架构迁移到托管在 Google Container Engine 上的 Kubernetes 集群，从而解决了许多工程问题-从硬件故障到生产服务的可伸缩性不足，复杂的配置管理和高度异构的开发 -生产阶段环境-使我们能够实现可靠，可用和可扩展的基础架构。 +* [Second Life 运行 MySQL](http://conferences.oreillynet.com/presentations/mysql06/wilkes_ian.pdf) -这篇文章将引导您了解 Betabrand 从 2011 年到 2018 年遇到的许多基础架构变更和挑战。 +* [采访伊恩·威尔克斯](http://dev.mysql.com/tech-resources/interviews/ian-wilkes-linden-lab.html) -* * * +* [技术趋势：林登实验室内部](http://www.springerlink.com/content/a087424077663u0p/) -## 早期基础设施 +* [市政厅和 Cory Linden](http://blog.secondlife.com/2006/12/20/town-hall-with-cory-introductory-transcript/) -### VPS +* InformationWeek 文章（ [1](http://www.informationweek.com/news/software/hosted/showArticle.jhtml?articleID=197800179) ， [2](http://www.informationweek.com/news/software/open_source/showArticle.jhtml?articleID=198500108) ）和[博客](http://www.informationweek.com/blog/main/archives/2007/05/linden_lab_plan.html
) -在我工作的 7 年中，Betabrand 的基础架构发生了许多次变化。 +* [Second Life Wiki：服务器体系结构](http://wiki.secondlife.com/wiki/Server_architecture) -在 2011 年，即我们的 CTO 雇用我的那一年，该网站托管在具有 Plesk 界面且没有 root 访问权限的共享服务器上（当然）。 每封新闻通讯（最多发送给数百人）都会使该网站屈服并使其爬行，有时甚至完全无响应。 +* [维基百科：第二人生服务器](http://en.wikipedia.org/wiki/Second_Life#Server) -我的第一笔生意就是寻找替代品，并将网站转移到自己的专用服务器上。 +* [第二人生博客](http://blog.secondlife.com/2007/08/24/more-open-source-our-web-services-libraries/) +* [第二人生：虚拟世界指南](http://www.amazon.com/gp/product/0321501667?ie=UTF8&tag=innoblog-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321501667) ![](img/d244572f6732cbaebb79e76ee4f24a68.png) -### 机架空间 +# 平台 -经过几天的在线研究，我们在 Rackspace 上安装了 VPS-8GB RAM，320GO 磁盘，4 个虚拟 CPU，150Mbps 带宽。 再过几天，我们就生活在由……1 台服务器组成的新基础架构上； 运行带有 Memcached 提示的典型 Linux，Apache，PHP，MySQL 堆栈。 +* 的 MySQL -毫不奇怪，此基础架构很快就过时了。 +* 阿帕奇 -它不仅没有扩展，而且更重要的是，它的每个部分都是单点故障。 阿帕奇下来？ 网站关闭。 Rackspace 实例关闭了吗？ 网站关闭。 MySQL 崩溃了……您明白了。 +* 乌贼 -它的另一方面是它的成本。 +* 蟒蛇 -我们的平均每月账单迅速攀升至 1,000 美元以上。 对于一台机器和我们当时产生的低流量来说，这是很昂贵的价格。 +* C ++ -在运行了该堆栈几年后，即 2013 年中，我决定是时候让我们的网站更具可扩展性，冗余性和成本效益了。 +* 单核细胞增多症 -我估计，我们至少需要 3 台服务器才能使我们的网站有些冗余，这在 Rackspace 上每年高达$ 14400。 作为一家非常小的初创公司，我们无法证明基础设施账单的“高价”； 我一直在寻找。 +* 德比安 -最便宜的选择最终导致我们的堆栈在裸机服务器上运行。 +# 里面有什么？ -### OVH +### 统计资料 -我过去曾在 OVH 工作过，一直都很满意（尽管在线上有不同的评论）。 我估计在 OVH 上运行 3 台服务器每年将达到 3240 美元，几乎比 Rackspace 便宜 5 倍。 +* 约 100 万活跃用户 -OVH 不仅更便宜，而且其服务器的功能也比 Rackspace 的服务器强 4 倍：32GB RAM，8 个 CPU，SSD 和无限带宽。 +* 每季度约 9500 万用户小时 -最重要的是，他们刚刚在北美开设了一个新的数据中心。 +* 约 70K 并发用户高峰（年增长率 40％） -几周后，Betabrand.com 被托管在加拿大博哈努瓦的 OVH。 +* 约 12Gbit / sec 的总带宽（2007 年） -## 硬件基础架构 +### 员工（2006 年） -在 2013 年至 2017 年之间，我们的硬件基础架构经历了一些架构更改。 +* 70 FTE + 20 兼职 -到 2017 年底，无论是在软件还是在硬件方面，我们的堆栈都大大超过了以往。 +“大约有 22 位程序员在 SL 上工作。在任何时候，大概 1/3 的团队在基础架构上，1/3 的团队在新功能上，而 1/3 的团队在各种维护任务上（bug 修复 ，总体稳定性和速度方面的改进）或对现有功能的改进。但这差别很大。” -Betabrand.com 在 17 台裸机上运行： +### 软件 -* 2 台负责 SSL 卸载的 HAProxy 机器配置为热备用 +**客户端/查看器** -* 在我们的 Web 服务器的热备份负载平衡中配置了 2 个清漆缓存计算机 +* [开源客户端](http://wiki.secondlife.com/wiki/Source_downloads) -* 5 台运行 Apache 和 PHP-FPM 的计算机 +* 渲染虚拟世界 -* 2 个 Redis 服务器，每个服务器运行 2 个独立的 Redis 实例。 1 个实例用于某些应用程序缓存，1 个实例用于我们的 PHP 会话 +* 处理用户交互 -* 3 台配置为 master-master 的 MariaDB 服务器，但以 master-slave 方式使用 +* 处理对象的位置 -* 3 个 Glusterd 服务器为我们所有的静态资产服务 +* 获取速度并执行简单的物理操作以跟踪移动的位置 -否则，每台机器都将运行一个或多个进程，例如 keepalived，Ganglia，Munin，logstash，exim，备份管理器，有监督的，sshd，fail2ban，prerender，rabbitmq 和 docker。 +* 无碰撞检测 -但是，尽管此基础架构非常便宜，冗余且没有单点故障，但它仍不可扩展，并且维护起来也非常困难。 +**模拟器（Sim）** +《第二人生》中的每个地理区域（256x256 米区域）都在称为模拟器或“ sim”的服务器软件的单个实例上运行。 每个 SIM 卡都在服务器的单独核心上运行。 +模拟器是主要在大多数服务器上运行的 SL C ++服务器进程。 当观众在整个世界中移动时，它会从一个模拟器转到另一个模拟器。 -### 可伸缩性和可维护性问题 +* 运行 [Havok 4](http://en.wikipedia.org/wiki/Havok_(software)) 物理引擎 -现在，管理服务器“舰队”需要编写一组 Ansible 脚本并进行维护，尽管 Ansible 是一款了不起的软件，但这绝非易事。 +* 以 45 帧/秒的速度运行。 如果无法跟上，它将尝试时间拨号而不降低帧速率。 -即使会尽最大努力使您达到目标，Ansible 也不保证您的系统状态。 +* 处理存储对象状态，地块状态和地形高度图状态的句柄 -例如，在由异构 OS 组成的服务器机群（例如 debian 8 和 debian 9）上运行 Ansible 脚本，将使所有计算机的状态都接近您定义的状态，但是最终可能会出现差异。 第一个是您在 Debian 8 和 Debian 9 上运行，但是在某些服务器和其他服务器上，软件版本和配置也不同。 +* 跟踪所有事物的位置以及碰撞检测的位置 -> 我经常搜索 Ansible 替代品，但从未发现更好。 -> -> 我看了看 Puppet，但发现它的学习曲线太陡峭了，从阅读别人的食谱中，*似乎*感到惊讶，因为它们做相同事情的方法太多了。 有些人可能认为这是灵活性，我认为这是复杂性。 -> -> SaltStack 引起了我的注意，但也发现很难学习。 尽管他们进行了广泛而深入的文档编制，但他们的命名选择（矿井，矿井，盐等）从未对我产生影响； 在复杂性方面，它似乎遭受了与 Puppet 相同的问题。 -> -> Nix 软件包管理器和 NixOS 听起来很棒，除了我对学习全新的操作系统感到不舒服（我已经使用 Debian 多年了），并担心尽管选择了巨大的软件包，但最终我仍需要软件包 可用，这将成为新的维护对象。 -> -> 这些是我查看过的仅有的 3 个工具，但我敢肯定还有很多其他工具我可能从未听说过。 +* 将内容的位置发送给查看者 -然而，编写 Ansible 脚本并进行维护并不是我们唯一的问题； 增加容量是另一个。 +* 在优先队列中传输图像数据 -对于裸机，无法即时添加和删除容量。 您需要提前计划好您的需求：购买一台机器-通常租用至少 1 个月-等待其准备就绪-可能需要 2 分钟至 3 天的时间-安装其基本操作系统， 安装 Ansible 的依赖项（主要是 python 和一些其他软件包），然后最后对它运行 Ansible 脚本。 +* 仅在需要时（仅当发生碰撞或方向，速度等发生其他变化时）才将更新发送给查看者 -对我们来说，整个过程是完全不切实际的，通常发生的事情是，我们会为预期的峰值负载增加容量，但之后再也不会删除它，这反过来又增加了我们的成本。 +* 运行 [Linden 脚本语言](http://en.wikipedia.org/wiki/Linden_Scripting_Language)（LSL）脚本 -但是，值得注意的是，即使基础架构中未使用的容量类似于在烧钱，但在裸机上的成本仍然比在云上便宜得多。 另一方面，使用裸机服务器带来的工程难题只是将成本从纯粹的材料成本转移到了管理成本。 +* 脚本最近已升级到更快的 [Mono 脚本引擎](http://wiki.secondlife.com/wiki/Mono) -在我们的裸机设置容量计划中，服务器管理和 Ansible 脚本只是冰山一角。 +* 处理聊天和即时消息 + * * [Eventlet](http://wiki.secondlife.com/wiki/Eventlet) 是用 Python 编写的网络库。 它通过使用非阻塞 io 来实现高可伸缩性，同时通过使用协程使非阻塞 io 操作在源代码级别上表现为阻塞来保持较高的程序员可用性。 -### 扩展开发流程 + * [Mulib](http://wiki.secondlife.com/wiki/Mulib) 是建立在事件 + * 2000 台以上服务器上的 REST Web 服务框架 -在 2017 年初，虽然我们的基础架构有所发展，但我们的团队也有所发展。 + * 大约有 6000 台服务器，在 2008 年初 -我们又雇用了 7 名工程师，使我们的团队由 9 人组成，其技能组从后端到前端遍及各个领域，并具有不同的资历水平。 + * 计划升级到〜10000（？） -即使在一个只有 9 人的小型团队中，也要保持生产效率并限制部署到生产中的错误数量，就可以确保简单，易于设置和易于使用的开发，分期和生产三联产品。 + * 每台计算机 4 个 sims，适用于 4 级和 5 级 -将您的开发环境设置为新员工，无需花费数小时，也无需升级或重新创建它。 + * 使用全 AMD 已有多年，但已从 Opteron 270 迁移到 Intel Xeon 5148 -此外，应该存在公司范围内可访问的登台环境，该环境应与您的产品的 99％（如果不是 100％）匹配。 + * 升级到“ 5 级”服务器使每台计算机的 RAM 从 2GB 翻了一番 到 4GB 并移动到更快的 SATA 磁盘 -不幸的是，在我们的硬件基础架构中，达到这种和谐的三重奏是不可能的。 + * 1-4 类在 100Mb 上具有 1Gb 上行链路到核心。 第 5 类位于纯 1Gb 上 + * 一个大型集群文件系统〜100TB -### 开发环境 + * 存储资产数据，例如纹理。 -首先，我们工程团队的每个人都使用 MacBook Pro，这是一个问题，因为我们的堆栈基于 Linux。 + **Asset Server** -但是，要求所有人切换到 Linux 并可能更改他们宝贵的工作流程并不是一个理想的选择。 这意味着最好的解决方案是提供一个与开发人员的机器偏好无关的开发环境。 + **MySQL database** -我只能看到两个明显的选择： + **Backbone** -提供一个可以运行多个虚拟机的 Vagrant 堆栈（实际上更可能是 17 个计算机运行我们的整个堆栈），或者重新使用已经编写的 ansible 脚本，然后对我们的本地 macbook 运行它们。 + ### 硬件 -在调查了 Vagrant 之后，我觉得使用虚拟机会严重阻碍性能，这是不值得的。 我决定（不管是好是坏）走 Ansible 路线（事后看来，这可能不是最好的决定）。 + *Do you have more details?* -我们将在生产，登台和开发中使用相同的 Ansible 脚本集。 当然，我们的开发堆栈虽然接近生产，但并不是 100％匹配。 +谢谢 geekr，这很有趣。 -这足够好一段时间了。 但是，这种失配会在以后（例如，我们的开发和生产 MySQL 版本未统一）时引起问题。 一些在开发人员上运行的查询不会在生产环境中使用。 +您已经收集了很多不错的事实。 将此与大约 18 个月前的设置进行比较很有趣（请参阅 [http://blogs.computerworld.com/node/5122）。](http://blogs.computerworld.com/node/5122).) -#### 暂存环境 +此外，虽然并发访问者的 40％的年增长率令人鼓舞，但今年以来的峰值货币和其他指标实际上已经趋于平稳（请参见 [http://nwn.blogs.com/nwn/demographics/index.html）](http://nwn.blogs.com/nwn/demographics/index.html)) -其次，在不同的软件（mac os 与 debian）上运行开发和生产环境意味着我们绝对需要一个暂存环境。 +Ian Lamont +行业标准 -不仅是由于版本不匹配导致的潜在错误，还因为我们需要一种在发布之前与外部成员共享新功能的方法。 +托德，很高兴您发现这很有趣。 收集所有这些事实非常具有挑战性：) -我再次有多种选择： +我认为虚拟世界的可伸缩性与网站一样重要。 -* 购买 17 台服务器并对它们运行 ansible。 但是，这会使我们的成本增加一倍，并且我们试图节省资金。 +很棒的文章！ 很高兴读到一些与您的标准网站结构有所不同的内容，尤其是 MMO。 关于如何设置这些浮动的信息不多。 -* 在一个可以从外部访问的独特的 linux 服务器上设置我们的整个堆栈。 更便宜的解决方案，但再次没有提供我们生产系统的精确副本。 +*《第二人生》中的每个地理区域（256x256 米区域）都在称为模拟器或“ sim”的服务器软件的单个实例上运行。 每个 SIM 卡都在服务器的单独核心上运行。* -我决定实施节省成本的解决方案。 +这就解释了为什么热门地区陷入困境。 h！ -暂存环境的早期版本涉及 3 个独立的 linux 服务器，每个服务器运行整个堆栈。 然后，开发人员会在整个房间（或聊天室）大喊大叫，“接管 dev1”，“有人在使用 dev3 吗？”，“ dev2 关闭了：/”。 +SL 有点...停滞不前吗？ -总体而言，我们的开发，分阶段和生产设置远非最佳：它可以完成工作； 但绝对需要改进。 +费耶 -## Docker 的出现 - -2013 年，Dotcloud 发布了 Docker。 - -Docker 的 Betabrand 用例立即显而易见。 我将其视为简化我们的开发和登台环境的解决方案。 通过摆脱烦人的脚本（好吧，差不多；稍后再讲）。 - -这些脚本现在仅用于生产。 - -当时，该团队的一个主要痛点是争夺我们的三台物理登台服务器：dev1，dev2 和 dev3；而另一台则是服务器。 对我来说，维护这 3 台服务器是一个很大的麻烦。 - -在观察了 docker 几个月后，我决定在 2014 年 4 月试用它。 - -在其中一个登台服务器上安装 docker 之后，我创建了一个包含整个堆栈（haproxy，清漆，redis，apache 等）的 docker 映像，然后在接下来的几个月中编写了一个工具（`sailor`），使我们可以创建 ，销毁和管理可通过单独的唯一 URL 访问的无限数量的登台环境。 - -> 值得一提的是，当时 docker-compose 还不存在； 而且将整个堆栈放入一个 docker 映像中当然是一个很大的禁忌，但这在这里并不重要。 - -从那时起，团队不再竞争访问登台服务器。 任何人都可以使用 Sailor 从 Docker 映像创建一个完全配置的新登台容器。 我也不再需要维护服务器； 更好的是，我关闭并取消了其中的 2 个。 - -但是，我们的开发环境仍在 macos（当时为“ Mac OS X”）上运行，并使用 Ansible 脚本。 - -然后，在 2016 年左右的某个时候发布了 docker-machine。 - -Docker machine 是一种工具，可在您选择的任何堆栈上部署 docker 守护进程：virtualbox，aws，gce，bare-metal，azure（由您命名），docker-machine 可以完成； 在一个命令行中。 - -我将其视为轻松，快速地将基于 ansible 的开发环境迁移到基于 docker 的机会。 我修改了`sailor`以使用 docker-machine 作为其后端。 - -设置开发环境现在只需创建一个新的 docker-machine，然后传递一个标志供水手使用即可。 - -至此，我们的开发阶段流程已大大简化； 至少从开发人员的角度来看：每当我需要将我们的堆栈中的任何软件升级到较新版本或更改配置时，都无需修改我的 ansible 脚本，而是要求所有团队来运行它们，然后自己在所有 3 个设备上运行它们 登台服务器； 我现在可以简单地推送一个新的 docker 映像。 - -具有讽刺意味的是，我最终需要虚拟机（故意避免使用）在我们的 macbook 上运行 docker。 从一开始，使用无业游民而不是 Ansible 是一个更好的选择。 后视总是 20/20。 - -将 docker 用于我们的开发和登台系统为 Betabrand.com 现在运行的更好的解决方案铺平了道路。 - -## 州长 - -由于 Betabrand 主要是一个电子商务平台，因此黑色星期五每年越来越多地出现在我们的网站上。 - -令我们惊讶的是，自 2013 年以来，该网站已处理了越来越多的负载，而没有发生任何重大灾难，但是它确实需要提前一个月的准备：尽可能地增加容量，负载测试和优化我们的结帐代码路径。 - -但是，在为 2016 年黑色星期五做准备之后，很明显基础架构无法在 2017 年黑色星期五进行扩展。 我担心在负载下该网站将无法访问。 - -幸运的是，在 2015 年的某个时候，Kubernetes 1.0 的发布引起了我的注意。 - -就像在 docker 中看到一个明显的用例一样，我知道 k8s 是解决许多问题所需要的。 首先，它最终将允许我们运行几乎与*相同的 dev-staging-production 环境。 而且，还将解决我们的可伸缩性问题。* - -我还评估了另外两个解决方案，即 Nomad 和 Docker Swarm，但 Kubernetes 似乎是最有前途的。 - -对于 2017 年黑色星期五，我着手将整个基础架构迁移到 k8s。 - -> 尽管我考虑了这一点，但我很快排除了将我们当前的 OVH 裸机服务器用于 k8s 节点的问题，因为这将与我摆脱 Ansible 而不是处理硬件服务器所带来的所有问题的目标背道而驰。 此外，在我开始调查 Kubernetes 之后不久，Google 便发布了他们的托管 Kubernetes（GKE）产品，我很快就选择了它。 - -### 学习 Kubernetes - -迁移到 k8 首先需要通过阅读在线文档来深入了解其架构和概念。 - -最重要的是了解容器，容器，部署和服务以及它们如何组合在一起。 然后依次执行 ConfigMaps，Secrets，Daemonsets，StatefulSets，Volumes，PersistentVolumes 和 PersistentVolumeClaims。 - -其他概念也很重要，尽管使集群前进的必要性较低。 - -一旦吸收了这些概念，第二个也是最困难的一步就是将我们的裸机架构转换为一组 YAML 清单。 - -从一开始，我就打算只有一套清单用于创建所有三个开发，登台和生产环境。 我很快就遇到了需要参数化我的 YAML 清单的问题，而 Kubernetes 并不能立即使用它。 这是 Helm [ [1](#_footnotedef_1 "View footnote.") ] 派上用场的地方。 - -> Helm 网站上的*：Helm 帮助您管理 Kubernetes 应用程序-Helm Charts 帮助您定义，安装和升级最复杂的 Kubernetes 应用程序。* - -Helm 将自己定位为 Kubernetes 的程序包管理器，但我最初只是将其用于模板功能。 现在，我也开始欣赏它的软件包管理器方面，并用它来安装 Grafana [ [2](#_footnotedef_2 "View footnote.") ] 和 Prometheus [ [3](#_footnotedef_3 "View footnote.") ] 。 - -经过一番汗水和几滴眼泪，我们的基础架构现在被整齐地组织为 1 个 Helm 程序包，17 个部署，9 个 ConfigMap，5 个 PersistentVolumeClaims，5 个秘密，18 个服务，1 个 StatefulSet，2 个 StorageClasses，22 个容器映像。 - -剩下的就是迁移到这个新的基础架构并关闭所有硬件服务器。 - -### 正式迁移 - -2017 年 10 月 5 日是夜晚。 - -扣动扳机非常容易，而且顺利进行。 - -我创建了一个新的 GKE 集群，运行`helm install betabrand --name production`，将我们的 MySQL 数据库导入到 Google Cloud SQL 中，然后，实际上花了大约 2 个小时，我们才生活在 Clouds 中。 - -迁移很简单，就是。 - -当然，最有用的是在 Google GKE 中创建多个集群的能力：在迁移产品之前，我能够通过多次测试迁移进行排练，记下成功启动所需的每个步骤。 - -Betabrand 的黑色星期五 2017 年非常成功，我们遇到的一些技术问题与迁移无关。 - -### 开发/分期环境 - -我们的开发机器通过 Minikube [ [4](#_footnotedef_4 "View footnote.") ] 运行 Kubernetes 集群。 - -相同的 YAML 清单用于创建本地开发环境或“类似生产”的环境。 - -在生产环境中运行的所有内容，也在开发环境中运行。 两种环境之间的唯一区别是，我们的开发环境与本地 MySQL 数据库对话，而生产与 Google Cloud SQL 对话。 - -创建登台环境与创建新的生产集群完全相同：所需要做的只是克隆生产数据库实例（只需单击几下或一个命令行），然后通过`--set database`将登台集群指向该数据库。 `helm`中的]参数。 - -### 一年后 - -从我们将基础架构移至 Kubernetes 至今已经一年零两个月了，我再也高兴不起来了。 - -Kubernetes 在生产中一直坚如磐石，我们还没有遇到过停机的情况。 - -预计 2018 年黑色星期五会有大量流量，我们能够在几分钟内创建生产服务的精确副本并进行大量负载测试。 这些负载测试显示特定的代码路径性能非常差，只能显示大量流量，并允许我们在黑色星期五之前修复它们。 - -不出所料，2018 年黑色星期五给 Betabrand.com 带来了比以往更多的访问量，但 k8s 兑现了承诺，而 Horizo​​ntalPodAutoscaler 等功能与 GKE 的节点自动缩放功能相结合，使我们的网站能够毫无问题地吸收峰值负载。 - -K8 与 GKE 相结合，为我们提供了使我们的基础架构可靠，可用，可伸缩和可维护所需的工具。 - -* * * - -[1](#_footnoteref_1). [https://helm.sh/](https://helm.sh/)[2](#_footnoteref_2). [https://grafana.com/](https://grafana.com/)[3](#_footnoteref_3). [https://prometheus.io/](https://prometheus.io/)[4](#_footnoteref_4). [https://github.com/kubernetes/minikube](https://github.com/kubernetes/minikube) - -雨果，好帖子！ 真的很脆，没有花哨/不必要的术语。 - -我很好奇看到您每月帐单的比较-OVH 裸机与 GCP K8S - -I too am curious to see a comparison of your monthly bill - OVH bare-metall vs GCP K8S...😉 - -您认为这对这家公司来说太过分了吗？ 我一直都很喜欢 Kube，不是因为业务需要，而是因为人们喜欢高科技。 IDK，只是想一想 - -为什么不使用不同的名称空间进行测试和暂存，而不是创建不同的集群？ \ No newline at end of file +通过创新的业务模型方法，这本书 [http://www.amazon.com/gp/product/1418052671?ie=UTF8 &标签= innoblog-20 & linkCode = as2 & 营地= 1789 & creative = 9325 & creativeASIN = 1418052671“](游戏开发要点：在线游戏开发![](img/802585d3c2e9857695089434f58ff522.png) http://www.assoc-amazon.com/e/ir?t= innoblog-20 & l = as2 & o = 1 & a = 1418052671“ width =” 1“ height =” 1“ border =” 0“ alt =”“ style =” border：none！important; margin：0px！重要;“ / >提供了诸如《第二人生》和《魔兽世界》等大型多人在线游戏（MMOG）取得长期成功所需的基本要素。 本书通过将 MMOG 开发作为一个复杂的，多方面的，面向服务的业务来处理，而不是仅仅专注于技术，艺术或设计技术，而与传统游戏开发书相比，具有重要意义和重大意义。 由此产生的多维关注点使读者可以设计游戏并在考虑整个业务的情况下组织其开发过程。 涵盖范围包括单人游戏和 MMOG 之间的主要区别，以及开发过程的各个组成部分（如业务模型，营销计划，游戏社区和技术约束）如何相互影响并确定 MMOG 的成功。 \ No newline at end of file diff --git a/docs/33.md b/docs/33.md index 787f037..0127e6f 100644 --- a/docs/33.md +++ b/docs/33.md @@ -1,183 +1,104 @@ -# Auth0 体系结构：在多个云提供商和地区中运行 +# MySpace 体系结构 -> 原文： [http://highscalability.com/blog/2018/8/27/auth0-architecture-running-in-multiple-cloud-providers-and-r.html](http://highscalability.com/blog/2018/8/27/auth0-architecture-running-in-multiple-cloud-providers-and-r.html) +> 原文： [http://highscalability.com/blog/2009/2/12/myspace-architecture.html](http://highscalability.com/blog/2009/2/12/myspace-architecture.html) -![](img/fb8f8c10f1617deafe6f1d030a44d363.png) +**更新：** [演示：MySpace.com 的幕后](http://www.infoq.com/news/2009/02/MySpace-Dan-Farino)。 MySpace 的首席系统架构师 Dan Farino 分享了 MySpace 的一些出色内部操作工具的详细信息。 -*此文章由 Auth0 的站点可靠性工程师 Dirceu Pereira Tiegs 撰写，最初发表于 [Auth0](https://auth0.com/blog/auth0-architecture-running-in-multiple-cloud-providers-and-regions/) 中。* +MySpace.com 是 Internet 上增长最快的网站之一，每天有 6500 万订户和 260,000 新用户注册。 MySpace 通常因性能不佳而受到批评，不得不解决其他站点很少遇到的可伸缩性问题。 他们是如何做到的呢？ -Auth0 为任何堆栈上的任何类型（移动，Web，本机）的应用程序提供身份验证，授权和单点登录服务。 身份验证对于绝大多数应用程序至关重要。 我们从一开始就设计 Auth0，以便它可以在任何地方运行：在我们的云，您的云甚至您自己的私有基础结构上。 +网站：http：//myspace.com -在这篇文章中，我们将更多地讨论我们的公共 SaaS 部署，并简要介绍 [auth0.com](https://auth0.com/) 背后的基础架构以及我们用来使其保持高可用性和正常运行的策略。 +## 信息来源 -从那时起，Auth0 发生了很多变化。 这些是一些亮点： +* [演示文稿：MySpace.com 的幕后故事](http://www.infoq.com/news/2009/02/MySpace-Dan-Farino)* [Inside MySpace.com](http://www.baselinemag.com/print_article2/0,1217,a=198614,00.asp) -* 我们从每月处理几百万个登录到每月处理 1.5+十亿个登录，为成千上万的客户提供服务，包括 [FuboTV](https://auth0.com/learn/sports-centric-streaming-service-fubotv-sees-50-roi-just-auth0s-security/) ， [Mozilla](https://auth0.com/blog/auth0-mozilla-partnership/) ， [JetPrivilege](https://auth0.com/learn/jetprivilege-case-study/) 和 更多。 + ## 平台 -* 我们实现了新功能，例如[自定义域](https://auth0.com/docs/custom-domains)，[扩展的 bcrypt 操作](https://auth0.engineering/bcrypt-as-a-service-9e71707bda47)，极大地[改进的用户搜索](https://auth0.com/docs/users/search/v3)等。 + * ASP.NET 2.0* 视窗* 其* SQL Server -* 组成我们的产品以扩展我们的组织并处理流量增长的服务数量从不到 10 种增加到 30 多种。 + ## 里面有什么？ -* 云资源的数量也大大增加。 我们曾经在一个环境（美国）中有几十个节点，现在在四个环境（美国，US-2，欧盟，非盟）中有超过一千个节点。 + * 3 亿用户。* 将每秒 100 吉比特的速度推向互联网。 HTML 内容为 10Gb /秒。* 4,500 多个 Web 服务器 Windows 2003 / IIS 6.0 / APS.NET。* 1200 多个运行 64 位 Windows 2003 的缓存服务器。16GB 的对象缓存在 RAM 中。* 500 多个运行 64 位 Windows 和 SQL Server 2005 的数据库服务器。 -* 我们加倍决定在每个环境中使用一个云提供商，并将所有公共云基础架构移至 AWS。 + * MySpace 每天处理 15 亿次页面浏览，并在一天中处理 230 万并发用户* 成员资格里程碑： + -500,000 用户：一个简单的体系结构绊倒 + -100 万用户：垂直分区解决了可伸缩性问题 + -300 万用户：横向扩展胜于向上扩展 + -900 万用户 ：站点迁移到 ASP.NET，添加了虚拟存储 + -2 千 6 百万用户：MySpace 采用 64 位技术* 对于两个 Web 服务器和一个数据库，500,000 个帐户的负载太多。* 在 1-2 百万个帐户 + 下，他们使用了围绕垂直分区概念构建的数据库体系结构，并为网站的各个部分提供了单独的数据库，这些部分提供了不同的功能，例如登录屏幕，用户个人资料和博客。 + -垂直分区方案有助于分担数据库读取和写入的工作量，并且当用户需要新功能时，MySpace 会将新数据库联机以支持它。 + -MySpace 从使用直接连接到其数据库服务器的存储设备切换到存储区域网络（SAN），在该区域中，磁盘存储设备池通过高速专用网络捆绑在一起，并且数据库连接到 SAN。 SAN 的更改提高了性能，正常运行时间和可靠性。* 拥有 300 万个帐户 + 时，垂直分区解决方案并没有持久，因为它们在所有垂直切片中复制了一些水平信息，例如用户帐户。 进行如此多的复制将导致失败并降低系统速度。 + -网站的各个部分上的博客之类的单个应用程序对于单个数据库服务器而言会变得太大。 + -将所有核心数据重新组织成逻辑组织到一个数据库中 + -将其用户群分为 一百万个帐户块，并将所有键入这些帐户的数据放入一个单独的 SQL Server 实例中* 900 万至 1700 万个帐户 + -迁移到 ASP.NET，该站点使用的资源比以前的体系结构少。 运行新代码的 150 台服务器能够完成以前需要 246 台的工作。 + -再次看到存储瓶颈。 实施 SAN 已经解决了一些早期的性能问题，但是现在该网站的需求开始逐渐使 SAN 的 I / O 容量不堪重负-它可以在磁盘存储中读写数据的速度。 + -超过了每个数据库一百万个帐户划分方法的点击次数限制。 + -迁移到虚拟化存储体系结构，其中整个 SAN 被视为一个巨大的存储容量池，而无需特定磁盘专门用于服务特定应用程序。 MySpace 现在针对来自相对较新的 SAN 供应商 3PARdata 的设备进行了标准化* 添加了一个缓存层，即位于 Web 服务器和数据库服务器之间的一层服务器，其唯一的工作就是捕获内存中经常访问的数据对象的副本并将它们提供给 Web 应用程序，而无需数据库查找。* 2600 万个帐户 + -移至 64 位 SQL Server，以解决其内存瓶颈问题。 他们的标准数据库服务器配置使用 64 GB 的 RAM。* **水平联合数据库**。 数据库是按目的分区的。 具有配置文件，电子邮件数据库等。分区基于用户范围。 每个数据库中都有 100 万用户。 因此，由于 Profile1 和 Profile2 一直拥有 3 亿用户，因此一直到 Profile300。* 不使用 ASP 缓存，因为它们的前端命中率不够高。 中间层缓存的命中率确实很高。* **故障隔离**。 通过数据库将请求细分为 Web 服务器。 每个数据库仅允许 7 个线程。 因此，如果数据库运行缓慢，则仅那些线程将变慢，其他线程中的流量将流动。 -## 核心服务架构 + ## 运作方式 -![Auth0.com core service architecture](img/cc4b226277078777fe9c230e973e068d.png) + * **PerfCollector** 。 通过 UDP 集中收集性能数据。 比 Windows 更可靠，并且允许任何客户端连接并查看统计信息。* **基于 Web 的堆栈转储工具**。 可以右键单击有问题的服务器，并获取.Net 托管线程的堆栈转储。 过去必须将 RDC 插入系统并附加调试器，然后在 1/2 以后得到答案。 缓慢，不可扩展且乏味。 不仅仅是堆栈转储，它还提供了有关线程正在做什么的大量上下文信息。 故障排除更加容易，因为您可以看到数据库上有 90 个线程被阻塞，因此数据库可能已关闭。* **Web 库堆转储工具**。 转储所有内存分配。 对开发人员非常有用。 手动节省数小时的时间。* **Profiler** 。 从头到尾跟踪请求并生成报告。 查看网址，方法，状态以及所有可帮助您确定缓慢请求的内容。 查看锁争用，是否抛出了很多异常，可能是有趣的事情。 重量很轻。 它在生产中的每个 VIP（100 个服务器的组）中的一个盒子上运行。 每 10 秒采样 1 个线程。 始终在后台跟踪。* **Powershell** 。 Microsoft 的新外壳，可在进程中运行并在命令之间传递对象，而不是解析文本输出。 MySpace 开发了许多 Commandlet 以支持操作。* 开发了自己的异步通信技术来解决 Windows 网络问题并将服务器视为一个整体。 可以发送.cs 文件，对其进行编译，运行并重新发送响应。* **Codespew** 。 在其通信技术上推送代码更新。 过去每天执行 5 次代码推送，现在每周减少 1 次。 -核心服务由不同的层组成： + ## 得到教训 -* 核心应用程序：自动扩展运行我们堆栈中不同服务（身份验证，管理 API，多因素身份验证 API 等）的服务器组。 + * 您可以使用 Microsoft 技术来建立大型网站。* 从一开始就应该使用缓存。* 缓存是存储不需要在数据库中记录的临时数据的更好的位置，例如，为跟踪网站上特定用户的会话而创建的临时文件。* 内置的 OS 功能可检测拒绝服务攻击，可能会导致莫名其妙的故障。* 将您的数据分发到地理位置不同的数据中心以处理电源故障。* 从一开始就考虑使用虚拟化存储/群集文件系统。 它使您能够大规模并行化 IO 访问，同时能够根据需要添加磁盘而无需任何重组。* 开发在生产环境中工作的工具。 无法在测试环境中模拟所有内容。 在测试过程中，无法在质量保证中模拟 API 的用途和规模。 合法的用户和黑客会遇到在测试中没有遇到的极端情况，尽管质量检查人员会发现大多数问题。* 向硬件抛出问题。 比将其后端软件更改为新的工作方式更容易。 这个例子是他们为每百万个用户添加一个新的数据库服务器。 更改其方法以更有效地使用数据库硬件可能会更有效，但仅添加服务器会更容易。 目前。 -* 数据存储：MongoDB，Elasticsearch，Redis 和 PostgreSQL 的集群，存储用于不同应用程序和功能的各种数据集。 +我从未见过如此专注于网站架构的网站。 它所包含的丰富信息使我感到启发！ -* 传输/队列：Kinesis 流和 RabbitMQ，SNS 和 SQS 队列。 +64 位硬件是这里的关键。 由于使用 32 位硬件，所有不良名称窗口的性能均很差。 大多数 Linux / unix 硬件在更早的时候就迁移到了 64 位硬件。 64 位计算机支持的额外 RAM 完全改变了计算机的性能。 -* 基本服务：限速，bcrypt 群集，功能标记等服务。 +“您可以使用 Microsoft 技术来建立大型网站。” -* 路由：AWS 负载均衡器（AWS 的 ALB，NLB 和 ELB）和一些运行 NGINX 作为代理的节点。 +从个人 Myspace 经验来看，您似乎还是不能。 它无法正常运行，并且各处都出现错误。 通过丢弃每第二个或第三个请求，看起来像“可伸缩性”，从而减少了系统上的负载。 -## 高可用性 +我认为他们宁愿将 ASP.NET 与 Cold Fusion 结合在一起，而不仅仅是.NET -2014 年，我们使用了多云架构（使用 Azure 和 AWS，并在 Google Cloud 上提供了一些额外的资源），多年来一直为我们服务。 随着使用量（和负载）的迅速增加，我们发现自己越来越依赖 AWS 资源。 +MySpace 使用 NewAtlanta 提供的 BlueDragon.NET 在.NET 上运行其 CFML 代码。 在这里了解更多信息； [http://blog.newatlanta.com/index.cfm?mode=entry &条目= 764C1F4A-89D7-A61A-F9F71128027172A7](http://blog.newatlanta.com/index.cfm?mode=entry&entry=764C1F4A-89D7-A61A-F9F71128027172A7) -首先，我们将环境中的主要区域切换到 AWS 中，并将 Azure 保留为故障转移。 随着我们开始使用更多的 AWS 资源（例如 Kinesis 和 SQS），我们开始难以在两个提供商中保持相同的功能集。 随着我们对移动（和扩展）速度的需求增长，我们选择继续以有限的功能奇偶校验来支持 Azure：如果 AWS 上的所有事情都失败了，我们仍然可以使用 Azure 群集来支持核心身份验证功能，但是没有太多新功能 我们一直在发展。 +感谢您发布本系列文章，对于任何想要扩展的人来说，它都是一个巨大的资源。 我在博客中引用了它： -在 2016 年发生严重故障后，我们决定最终在 AWS 上融合。 我们停止了与保持服务和自动化平台无关的所有工作，而是专注于： +[http://smoothspan.wordpress.com/2007/09/17/who-doesnt-love-java-youd-be-surprised-and-part-2-of-the-toolplatform-rants/](http://smoothspan.wordpress.com/2007/09/17/who-doesnt-love-java-youd-be-surprised-and-part-2-of-the-toolplatform-rants/) -* 使用多个区域以及每个区域至少 3 个可用区，从而在 AWS 内部提供更好的故障转移故事。 +干杯， -* 越来越多地使用 AWS 特定资源，例如自动扩展组（而不是使用固定的节点集群），应用程序负载平衡器（ALB）等。 +体重 -* 编写更好的自动化程序：我们改进了自动化程序，完全使用 TerraForm 和 SaltStack 来将基础架构作为代码包含在内，以提供新的 Auth0 环境（并替换现有环境）。 这使我们从每秒约 300 次登录的部分自动化环境发展到每秒约 3.4 千次登录的完全自动化环境。 使用新工具可以更轻松地按比例放大和缩小。 我们实现的自动化水平不是完美的，但是它使我们能够以更便捷的方式发展到新地区并创建新环境。 +150 个服务器可容纳 2600 万个帐户？ -* 编写更好的剧本：我们花了更多的时间和精力，除了自动化之外，还需要更好的剧本，以了解，管理和响应与我们不断增长的服务网格有关的事件。 这极大地提高了可扩展性和可靠性，同时还使我们能够更快地招聘新员工。 +每个服务器 173,333 个帐户。 -[](https://twitter.com/intent/tweet?text=%22Writing+better+automation+let+us+grow+from+partially+automated+environments+doing+%7E300+logins+per+second+to+fully+automated+environments+doing+more+than+%7E3.4+thousand+logins+per+second%22%20via%20@auth0%20http://auth0.com/blog/auth0-architecture-running-in-multiple-cloud-providers-and-regions/) +那真的是一个很好的基准吗？ 我都不知道。 Facebook 使用多少台服务器？ -> 编写更好的自动化软件，使我们从每秒进行 300 次登录的部分自动化环境发展到每秒进行 3.4 千多次登录的全自动化环境 +[http://codershangout.com](http://codershangout.com) +编码人员可以进行视频群聊的地方！ -让我们看一下我们的美国环境架构。 我们具有以下一般结构： +I think they rather combine ASP.NET with Cold Fusion and not only .NET -![Auth0 US Environment Architecture](img/185fa10f53d91f01cc6b371840a40c1a.png) +I think they rather combine ASP.NET with Cold Fusion and not only .NET -这是单个可用区内部的结构： +感谢您提供信息。 -![Auth0 Single Availablity Zone](img/cc6ac1420040762090fac0bcca910d1f.png) +他们的标准数据库服务器配置使用 64 GB 的 RAM。 -哇 64GB 的 RAM，那真是太棒了！ -在这种情况下，我们使用两个 AWS 区域：us-west-2（我们的主要区域）和 us-west-1（我们的故障转移）。 在正常情况下，所有请求都会发送到 us-west-2，由三个单独的可用区提供服务。 +真正有趣且有用的文章，非常感谢！ -这就是我们实现高可用性的方式：所有服务（包括数据库）在每个可用性区域（AZ）上都具有正在运行的实例。 如果由于数据中心故障而使一个可用区关闭，我们仍然有两个可用区来处理来自其的请求。 如果整个区域宕机或有错误，我们可以更新 Route53 以故障转移到 us-west-1 并恢复操作。 +我的空间是有用的网站，例如 facebook -> We achieve high availability by running all services instances on every AWS availability zone +那是一篇引人入胜的文章，也让我看到 SQL Server 和 ASP.Net 可以（尽管拥有聪明的组织和许多硬件）可以支持如此庞大的用户群。 -对于服务故障转移，我们有不同的成熟度级别：某些服务（例如用户搜索 v2（在 Elasticsearch 上构建缓存））可能会起作用，但是数据有些陈旧； 尽管如此，核心功能仍能按预期运行。 +感谢您分享这一信息。 -在数据层中，我们使用： +Myspace 正在成为互联网上领先的社区中心。 其订户比任何其他中心都多。 我猜它甚至击败了 Orkut。 +----- +[http://underwaterseaplants.awardspace.com“](水下海洋植物 +[http://underwaterseaplants.awardspace.com/seaweed .htm“](海藻... [http://underwaterseaplants.awardspace.com/easyaquariumplants.htm”](简易水族馆植物 -* MongoDB 的跨区域集群。 +从什么迁移到 ASP.NET？ -* PostgreSQL 的 RDS 复制。 +我对“投入更多的硬件”而不是“有效地构建代码”的方法感到有些惊讶。 -* 具有自动快照和恢复功能的 Elasticsearch 每个区域的群集定期运行，以解决缺乏跨区域群集的问题。 - -我们每年至少执行一次故障转移，并且我们有剧本和自动化工具可以帮助新的基础架构工程师迅速掌握如何进行故障转移以及所带来的影响。 - -我们的部署通常由 Jenkins 节点触发； 根据服务的不同，我们可以使用 Puppet，SaltStack 和/或 Ansible 来更新单个或一组节点，也可以更新 AMI 并为不可变的部署创建新的自动伸缩组。 对于新旧服务，我们有不同类型的部署，并且由于我们需要维护自动化，文档和监视应统一的内容，因此这种方法在很大程度上无效。 - -我们目前正在为某些核心服务推出蓝色/绿色部署，并且我们打算为每个核心和支持服务实施相同的部署。 - -## 自动化测试 - -除了每个项目的单元测试范围外，我们还有在每个环境中运行的多个功能测试套件； 我们在部署到生产之前在临时环境上运行它，并在完成部署后在生产中再次运行它们以确保一切正常。 - -亮点： - -* 我们在不同的项目中有成千上万的单元测试。 - -* 我们使用每分钟运行一次的 Pingdom 探针来检查核心功能。 - -* 在每次部署之前和之后，我们混合使用基于 Selenium 和 CodeceptJS 的功能测试。 功能测试套件可测试不同的 API 端点，身份验证流程，身份提供者等。 - -> 除了涵盖每个项目的单元测试外，我们还有在每个环境中运行的多个功能测试套件：在部署到生产之前进行过渡，在完成部署之后再次进行生产。 - -## CDN - -直到 2017 年，我们在多个区域中使用 NGINX，Varnish 和 EC2 节点运行了自己的定制 CDN。 从那时起，我们过渡到 CloudFront，这给了我们很多好处，包括： - -* 更多的边缘位置，这意味着对我们的客户的延迟减少。 - -* 降低维护成本。 - -* 易于配置。 - -有一些缺点，例如我们需要运行 Lambda 来执行一些配置（例如向 PDF 文件添加自定义标头之类的事实）。 尽管如此，上行空间肯定可以弥补这一点。 - -## 延伸 - -我们提供的功能之一是能够通过 [*身份验证规则*](https://auth0.com/docs/rules/current) 或 [*定制数据库连接* [](https://auth0.com/docs/connections/database/custom-db) 。 这些功能由 [*Extend*](https://goextend.io/) 提供支持，这是一种基于 Auth0 的可扩展性平台，现在也被其他公司使用。 借助 Extend，我们的客户可以在这些脚本和规则中编写他们想要的任何内容，从而允许他们扩展配置文件，规范化属性，发送通知等等。 - -我们有专门针对 Auth0 的扩展集群； 他们结合使用 EC2 自动扩展组，Docker 容器和自定义代理来处理来自我们租户的请求，每秒处理数千个请求，并快速响应负载变化。 有关如何构建和运行它的更多详细信息，请查看有关[如何构建自己的无服务器平台](https://tomasz.janczuk.org/2018/03/how-to-build-your-own-serverless-platform.html)的文章。 - -## 监控方式 - -我们使用不同工具的组合来监视和调试问题： - -* CloudWatch - -* 数据狗 - -* 平度 - -* 森丁 - -我们的绝大多数警报来自 CloudWatch 和 DataDog。 - -我们倾向于通过 TerraForm 配置 CloudWatch 警报，而我们在 CloudWatch 上保留的主要监视器为： - -* 来自主要负载均衡器的 HTTP 错误。 - -* 目标组中的不正常实例。 - -* SQS 处理延迟。 - -CloudWatch 是基于 AWS 生成的指标（如来自负载平衡器或自动伸缩组的指标）的警报的最佳工具。 CloudWatch 警报通常转到 PagerDuty，从 PagerDuty 转到 Slack / phone。 - -DataDog 是我们用来存储时间序列指标并对其采取行动的一项服务。 我们从 Linux 盒子，AWS 资源，现成的服务（例如 NGINX 或 MongoDB）以及我们已经构建的自定义服务（例如我们的 Management API）发送指标。 - -我们有许多 DataDog 监视器。 一些例子： - -* `$service`中`$environment`中的响应时间增加。 - -* `$instance`（`$ip_address`）中`$volume`上的空间不足。 - -* `$environment` / `$host`（`$ip_address`）上的`$process`问题。 - -* 增加`$environment`上`$service`的处理时间。 - -* NTP 漂移/ `$host`（`$ip_address`）上的时钟问题。 - -* `$environment`上的 MongoDB 副本集更改。 - -从上面的示例中可以看到，我们具有针对低级指标（如磁盘空间）和高级指标（如 MongoDB 副本集更改）的监视器，它们会在主节点定义发生更改时向我们发出警报， 例）。 我们要做的更多，并且围绕某些服务有一些非常复杂的监视器。 - -DataDog 警报的输出非常灵活，我们通常将它们全部发送到 Slack，仅将那些应该“唤醒人们”的人发送给 PagerDuty（例如错误尖峰，或者我们确信会对客户产生影响的大多数事情） 。 - -对于日志记录，我们使用 Kibana 和 SumoLogic。 我们正在使用 SumoLogic 来记录审计跟踪和许多 AWS 生成的日志，并且我们使用 Kibana 来存储来自我们自己的服务以及 NGINX 和 MongoDB 等其他“现成”服务的应用程序日志。 - -## 未来 - -我们的平台进行了相当多的改进，以处理对客户而言很重要的额外负载和各种用例，但我们仍有更多的优化空间。 - -不仅我们的平台在增长，而且我们的工程组织也在扩大规模：我们有许多新团队在构建自己的服务，并且需要有关可伸缩性的自动化，工具和指南。 考虑到这一点，这些举措使我们不仅可以扩展我们的平台，还可以扩展我们的工程实践： - -* 建立一个 PaaS 风格的平台：如前所述，今天我们有不同的自动化和部署流程。 这会引起混乱，并给工程师带来了进入的障碍，因为如果不接触太多的存储库就很难进行试验和扩展。 我们正在为一个平台（当前在 ECS 之上运行）开发 PoC，工程师可以在其中配置 YAML 文件并进行部署，以获取计算资源，监视，日志记录，备份等等。 所有这些都无需显式配置。 这项工作尚处于初期阶段，可能还会改变很多（EKS？）。 但是，鉴于我们不断增长的规模和可伸缩性限制，我们认为我们正在朝着正确的方向发展。 - -* 为每个新的请求请求实施冒烟测试：除了单元测试（已在每个新 PR 上运行）之外，我们还希望在临时环境中运行集成测试。 - -* 将我们的日志记录解决方案集中到一个提供商中。 这可能意味着离开 Kibana 并仅使用 SumoLogic，但是我们仍然需要评估功能集，数据量等。 - -* 自动化指标：我们太多的指标故事现在是手动的：在部署时将与指标相关的调用添加到代码中，以及使用 DataDog 界面构建仪表板和监视器。 如果使用标准格式和命名，则可以执行以下操作：自动构建仪表板/监视器，从日志中提取指标，而不是显式地添加对代码的调用等。 - -* 确保我们在每个核心服务上都有自动扩展和蓝色/绿色部署。 这应该从我们的新平台中直接获得，但是在构建和测试该平台时，我们需要针对仍缺乏这方面的核心服务来改进可伸缩性/部署/回滚的过程。 \ No newline at end of file +这闻起来像是一篇文章，提到了 MS 的优点，却没有提及缺点。为什么不提及它相对于开放平台的成本呢？ 我个人认为，如果有很多高流量网站（如 Facebook）建立在开放平台上，则意味着有可能开放。 那么，为什么我们要向 MS 付款呢？ 要拥有越来越多的专有非标准兼容技术？ 我认为除了微软之外，它不会对其他任何人有利。 \ No newline at end of file diff --git a/docs/34.md b/docs/34.md index 6892500..5008828 100644 --- a/docs/34.md +++ b/docs/34.md @@ -1,188 +1,146 @@ -# 每天为 1000 亿个事件赋予意义-Teads 的 Analytics（分析）管道 +# 扩展 Digg 和其他 Web 应用程序 -> 原文： [http://highscalability.com/blog/2018/4/9/give-meaning-to-100-billion-events-a-day-the-analytics-pipel.html](http://highscalability.com/blog/2018/4/9/give-meaning-to-100-billion-events-a-day-the-analytics-pipel.html) +> 原文： [http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html](http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html) -*这是 Teads.tv 的软件工程师* *[Alban Perillat-Merceroz](https://www.linkedin.com/in/albanperillatmerceroz/?locale=en_US)* *的来宾帖子。* +Digg 的首席架构师 Joe Stump 在 Web 2.0 Expo 上向[进行了此演示](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)。 我找不到实际的演示文稿，但是[克里斯·乔丹](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)记下了一些很棒的笔记。 这样一来，历史上的关键时刻便会永远被意外捕获。 乔也很友好，可以通过电话回答我的电子邮件问题。 -![](img/644055e22dfa3ea31613c9374bdc09b0.png) +在本篇文章的第一部分中，乔分享了一些您可能没有读过的永恒的智慧。 我当然会花些力气从原始演示文稿中提取所有智慧，而倾向于简单的规则。 然而，真正令我震惊的是 Joe 认为 MemcacheDB *将成为扩展*领域中最大的新手。 MemcacheDB 已经存在了一段时间，但我从未想到过这种方式。 好吧，在帖子结尾处，为什么乔对 MemcacheDB 感到如此兴奋。 -在本文中，我们描述了如何将 Kafka，Dataflow 和 BigQuery 一起编排以摄取和转换大量事件。 当添加规模和等待时间约束时，对它们进行协调和重新排序成为一个挑战，这是我们如何解决的。 +## 令人印象深刻的统计 -![](img/c0187dde2e79208a838aefd0599f99fc.png)Teads for Publisher, one of the webapps powered by Analytics +* 世界第 80 至 100 大网站* 每月 2600 万唯一* 3000 万用户。* 唯一身份流量只有该流量的一半。 流量=唯一的网络访问者+ API + Digg 按钮。* 每月 20 亿个请求* 13,000 请求/秒，高峰时为 27,000 请求/秒。* 3 位系统管理员，2 位 DBA，1 位网络管理员，15 位编码员，质量检查小组* Lots of servers. -在数字广告中，日常运营会产生许多我们需要跟踪的事件，以便透明地报告广告系列的效果。 这些事件来自： + ## 扩展策略 -* 用户与与浏览器发送的广告的互动。 这些事件称为跟踪事件，可以是标准事件（开始，完成，暂停，继续等），也可以是自定义事件，这些事件来自使用 [Teads Studio](https://teads.tv/studio/) 构建的交互式广告素材。 我们每天大约收到 100 亿个跟踪事件。 -* 来自后端的事件大部分与广告拍卖的详细信息有关（实时出价过程）。 在采样之前，我们每天会产生超过 600 亿个此类事件，并且应当在 2018 年使这一数字增加一倍。 + * 缩放是专业化。 当现成的解决方案不再能在一定规模上运行时，您必须创建满足特定需求的系统。* Web 2.0 的教训：人们喜欢胡扯并与世界分享。* Web 2.0 具有可伸缩性。 Web 1.0 平坦，包含大量静态文件。 通过添加更多硬件来处理额外的负载。 Web 2.0 是高度交互的。 内容可以以极低的速率创建。* 语言无法扩展。 100％的时间瓶颈在 + IO 中。 当您同时处理大量请求时，瓶颈就不是语言。 使 PHP 速度提高 300％无关紧要。 当 + 固定数据库时，不要通过使用单引号而不是双引号来优化 PHP。* 不分享状态。 去中心化。 需要分区才能并行处理大量请求。* 向外扩展而不是向上扩展。 期待失败。 只需添加框即可缩放并避免失败。* 需要对数据库驱动的站点进行分区，以在水平和垂直方向上进行扩展。 水平分区意味着将行的子集存储在不同的机器上。 当一台机器上无法容纳的数据量更多时，将使用此功能。 垂直分区意味着将一些列放在一个表中，而将某些列放在另一个表中。 这使您无需停机即可将数据添加到系统。* 数据分为单独的群集：用户操作，用户，注释，项目等。* 构建数据访问层，以便将分区隐藏在 API 的后面。* 带有分区的 [CAP 定理](http://camelcase.blogspot.com/2007/08/cap-theorem.html)：您只能选择以下三个中的两个：强一致性，高可用性，分区容限。* 分区解决方案需要非规范化，这已成为 Digg 的大问题。 非规范化意味着数据被复制到多个对象中，并且必须保持同步。* MySQL 复制用于扩展读取。* 使用异步排队体系结构进行近期处理。 + -这种方法将处理块推向另一个服务，让我们将该服务调度在处理器网格上进行处理。 + -与 cron 相比，它更快，响应速度更快，但与实时响应相比，响应速度却稍慢。 + -例如，发出 5 个同步数据库请求会使您减速。 并行执行。 + -Digg 使用 Gearman。 一个示例用法是获取永久链接。 并行完成三个操作：获取当前记录，获取固定链接并获取注释。 然后将这三个全部合并，以将合并的单个答案返回给客户端。 它也用于网站爬网和日志记录。 这是另一种思维方式。 + -请参阅 [Flickr-先做必要的工作，然后将其余部分排队](http://highscalability.com/strategy-flickr-do-essential-work-front-and-queue-rest)和 [Canonical Cloud Architecture](http://highscalability.com/canonical-cloud-architecture) 了解更多信息。* 瓶颈在 IO 中，因此您已经调整了数据库。 当数据库大于 RAM 时，磁盘会一直处于命中状态，这会降低性能。 随着数据库的变大，无法再扫描该表。 因此，您必须： + -反规范化 + -避免加入 + -避免通过对 + 进行分区来跨数据库进行大型扫描-缓存 + -添加读取从属设备 + -不要使用 NFS* 在尝试解决问题之前，请先编号，以确保事情确实可以进行。* 图标和照片之类的文件是使用分布式文件系统 [MogileFS](http://www.danga.com/mogilefs/) 处理的。 DFS 支持高请求率，因为文件是在网络中分布和复制的。* 缓存永久并且明确过期。* 在基于文件的缓存中缓存相当静态的内容。* 将可变项目缓存在 memcached 中* 在 [APC](http://us2.php.net/apc) 中缓存很少更改的项目。 APC 是本地缓存。 它不是分布式的，因此没有其他程序可以访问这些值。* 对于缓存，请使用[责任链模式](http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern)。 在 MySQL，memcached APC 和 PHP 全局变量中进行缓存。 首先将 PHP 全局变量检查为最快的缓存。 如果不存在，请检查 APC，memcached 并上链。* Digg 的推荐引擎是一个最终保持一致的自定义图形数据库。 最终一致意味着写入一个分区最终将写入所有其他分区。 一次写读后，不必再返回相同的值，因为它们可以由不同的分区处理。 这比严格的一致性要宽松得多，这意味着更改必须在所有分区上同时可见。 接连进行的读取将始终返回相同的值。* 假设每天有 100 万人使用任何新功能，因此从一开始就使其具有可扩展性。 示例：Digg 上的“关于”页面对主数据库进行了实时查询，以显示所有员工。 只是做了一个快速的黑客出去。 然后，一只蜘蛛发疯了，并把该地点倒了。 -在文章中，我们将重点放在跟踪事件上，因为它们是我们业务中最关键的路径。 + ## 杂种 -![](img/20a9026ebf5723f0f7b7e98193a0f300.png)Simplified overview of our technical context with the two main event sources + * Digg 按钮是产生点击量的主要关键。* 使用 Debian Linux，Apache，PHP，MySQL。* 选择您喜欢开发的语言，选择编码标准，添加可提取的内联文档，使用代码存储库和错误跟踪器。 喜欢 PHP，Track 和 SVN。* 你和你的人民一样好。 必须相信你旁边的人他在做他的工作。 为了建立信任，人们可以做出 + 决策。 相信人们会处理它，他们会照顾好它的。 减少会议时间，因为您知道人们会做正确的事。* 完全是 Mac 商店。* 几乎所有的开发人员都是本地的。 有些人不愿提供 24 小时支持。* 乔的做法务实。 他没有语言迷恋。 人们从 PHP 到 Python / Ruby，再到 Erlang。 使用 vim。 从命令行开发。 不知道人们如何一直在不断更改工具集。 这不是很有效。* 服务（SOA）分离是一个巨大的胜利。 Digg 使用 REST。 内部服务返回映射到 JSON，XML 等的原始结构。URL 中的版本是因为它不花钱，例如： + /1.0/service/id/xml。 版本内部和外部服务。* 人们不了解网站中有多少活动部件。 某些事情将会发生，并且将会失败。 -跟踪事件由浏览器通过 HTTP 发送到专用组件，该组件除其他外将它们排入 [Kafka](https://kafka.apache.org/) 主题。 Analytics 是这些事件的使用者之一（更多内容请参见下文）。 + ## MemcacheDB：代码的进化步骤，性能的革命步骤 -我们有一个分析团队，其任务是处理这些事件，其定义如下： + 想象一下 Digg 的创始人 Kevin Rose，他在本次演讲时拥有 40,000 个关注者。 如果 Kevin 每天只进行一次挖掘，则可写 40,000。 由于最活跃的挖掘者是最紧随其后的，因此它成为巨大的性能瓶颈。 出现两个问题。 -> 我们摄取了越来越多的原木 + 您无法一次更新 40,000 个关注者帐户。 幸运的是，我们前面讨论的排队系统已解决了这一问题。 -> 我们将它们转换为面向业务的数据， + 第二个问题是发生大量写入。 Digg 有写问题。 如果普通用户有 100 个关注者，则一天的收入为 3 亿迪格斯。 那就是每秒 3,000 次写入，每天 7GB 的存储以及 5TB 的数据分布在 50 到 60 台服务器上。 -> 我们为每个观众提供高效且量身定制的服务。 + 如此繁重的写入负载使 MySQL 无法用于 Digg。 这就是 MemcacheDB 的用武之地。在笔记本电脑上的初始测试中，MemcacheDB 每秒能够处理 15,000 次写入。 MemcacheDB 自己的[基准测试](http://memcachedb.org/benchmark.html)显示其每秒 23,000 次写入和 64,000 次读取/每秒的能力。 以这些写入速度，不难理解为什么乔对 MemcacheDB 的 digg 泛滥能力感到如此兴奋。 -为了完成此任务，我们构建并维护了一组处理工具和管道。 由于公司的有机增长和对新产品的要求，我们经常挑战我们的体系结构。 + 什么是 [MemcacheDB](http://memcachedb.org/) ？ 这是专为持久性而设计的*分布式键值存储系统。 它不是缓存解决方案，而是持久存储引擎，用于基于键值的快速，可靠的对象存储和检索。 它符合内存缓存协议（未完成，请参见下文），因此任何内存缓存客户端都可以与其建立连接。 MemcacheDB 使用 Berkeley DB 作为存储后端，因此支持许多功能，包括事务和复制*。 -## 为什么我们搬到 BigQuery + 在您太兴奋之前，请记住这是一个键值存储。 您可以通过一个键来读取和写入记录。 没有多个索引，也没有 SQL。 这就是为什么它可以这么快的原因。 -早在 2016 年，我们的 Analytics（分析）堆栈基于 [lambda 架构](http://lambda-architecture.net/)（Storm，Spark，Cassandra），但我们遇到了几个问题： + Digg 使用 MemcacheDB 扩展了数据非规格化时发生的大量写入。 请记住，这是一个键值存储。 该值通常是一个完整的应用程序级对象，该对象可以从大量标准化表合并在一起。 归一化引入了冗余，因为您将数据副本保留在多个记录中，而不是在一个很好的标准化表中保留一个副本。 因此，非规范化意味着更多的写入操作，因为必须将数据复制到包含副本的所有记录中。 为了跟上他们的发展，他们需要一个能够处理其写负载的数据库。 MemcacheDB 具有这种性能，尤其是当您将 memcached 的常规分区方案放在最顶层时。 -* 数据规模使得不可能将所有数据都存储在单个 Cassandra 表中，这阻止了有效的交叉查询， -* 这是一个复杂的基础架构，具有用于批处理层和速度层的代码重复，从而阻止了我们有效地发布新功能， -* 最后，难以扩展且成本效益不高， + 我问 Joe 为什么不选择一种内存数据网格解决方案？ 一些原因是：* 此数据是从许多不同的数据库生成的，并且需要很长时间才能生成。 因此，他们希望将其存储在持久性存储中。* MemcacheDB 使用内存缓存协议。 Digg 已经使用 memcache，因此开始使用 MemcacheDB 无疑是很容易的。 它易于使用且易于设置。* 由于它不是新的设置，因此操作人员很乐意将其部署到数据中心。* 他们已经具有内存缓存的高可用性和故障转移代码，因此已经可以使用。* 使用新系统将需要更多的准备时间。* 如果代码有任何问题，您可以看一下。 全部都是开源的。* 不确定其他产品是否足够稳定。 -当时我们有几种可能的选择。 首先，我们可以构建一个增强的 lambda，但这只会推迟我们面临的问题。 + 因此，这是代码的进化步骤，也是性能的革命步骤。 Digg 正在考虑全面使用 MemcacheDB。 -我们考虑了几种有前途的替代方案，例如 [Druid](http://druid.io/druid.html) 和 [BigQuery](https://cloud.google.com/bigquery/) 。 我们最终因其强大的功能而选择迁移到 BigQuery 。 + ## 相关文章 -使用 BigQuery，我们能够： + * [扩展 Digg 和其他 Web 应用程序](http://www.krisjordan.com/2008/09/18/joe-stump-scaling-digg-and-other-web-applications/)，作者：Kris Jordan。* [MemcacheDB](http://memcachedb.org/)* [Joe Stump 的博客](http://www.joestump.net/)* [具有与 Memcached 有关的高扩展性标签](http://highscalability.com/tags/memcached)* [高速缓存相关标签](http://highscalability.com/tags/caching)* [BigTable](http://highscalability.com/tags/bigtable)* [SimpleDB](http://highscalability.com/tags/simpledb)* [Anti-RDBMS：分布式键值存储列表](http://highscalability.com/anti-rdbms-list-distributed-key-value-stores)* [数据库设计的非传统方法：碎片](http://highscalability.com/unorthodox-approach-database-design-coming-shard)的来临* [Flickr 架构](http://highscalability.com/flickr-architecture)* [第 4 集：DIGG 首席架构师 Joe Stump 扩展大型网站](http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/) -* 处理原始事件， -* 使用 SQL 作为一种有效的数据处理语言， -* 使用 BigQuery 作为处理引擎， -* 使对日期的解释性访问更容易（与 Spark SQL 或 Hive 相比）， +除非他们想在 RAM 上花很多钱，否则他们会感到意外。 当 RAM 与数据库大小之比降低到 0.8 左右时，Memcachedb / Berkeley 数据库（或基于 B-Tree 的 MySQL，PostgreSQL 或其他传统数据库存储）的性能将大打折扣。 -多亏了 [固定费用计划](https://cloud.google.com/bigquery/pricing#flat_rate_pricing) ，我们密集的使用（在查询和存储方面）具有成本效益。 +当前，写解决方案是 Hypertable，即使 RAM 与 DB 的大小比小于 0.1，它也可以每个客户端维持 10k 次写/秒。 -但是，我们的技术背景对于 BigQuery 而言并不理想。 我们想使用它来存储和转换来自多个 Kafka 主题的所有事件。 我们无法将 Kafka 群集移出 AWS 或使用 [Pub / Sub](https://cloud.google.com/pubsub/docs/overview) （在 GCP 上与 Kafka 托管的等效版本），因为这些群集也由我们托管在 AWS 上的某些广告投放组件使用。 结果，我们不得不应对运行多云基础架构的挑战。 +“搜索”背后的架构是什么。 我假设正在使用某种全文数据库。 有人可以指出在 IIS / ASP.Net 环境中扩展全文本搜索的最佳方法。 我知道 SQL Server 2005 不够好。 -今天， BigQuery 是我们的数据仓库系统，在这里我们的跟踪事件与其他数据源保持一致。 +我正在寻找使用基于非 SQL 的后端的东西，例如 berkley db。 -## 摄取 +任何指针将不胜感激？ -在处理跟踪事件时，您面临的第一个问题是您必须无序处理，并且延迟未知。 +Web 2.0 Expo 笔记的重新组合。 乔的演讲很棒！ 首先请注意，指向我的笔记的链接似乎在 href 中包含一个 +，该链接中断了该链接。 最好！ 克里斯 -事件实际发生的时间（事件时间）与系统观察到事件的时间（处理时间）之间的差为毫秒至几小时。 这些大的延迟并不是那么罕见，当用户在两次浏览会话之间失去连接或激活飞行模式时可能会发生。 +哇，对我来说好像他们是在爆发大家伙！ -![](img/63b800ae8b1a8a694796b91f7b588eb0.png)Difference between event time and processing time +RT +www.anon-tools.us.tc -有关流数据处理挑战的更多信息，建议您看一下 Google Cloud Next '17 演讲« [在批处理和流处理之间来回移动](https://www.youtube.com/watch?v=PGTSZvBK8-Y) »，来自 Tyler Akidau （Google 的数据处理技术负责人）和 LoïcJaures（Teads 的联合创始人兼 SVP Technology）。 本文受此演讲启发。 +您应该看一下 SOLR（基于 Lucene 的搜索服务器）。 在 Tomcat 和 Jetty 上运行良好...都在 Windows 上运行。 [http://lucene.apache.org/solr/](http://lucene.apache.org/solr/) -## 流媒体的艰难现实 +搜索/数据的 XML 存储是 ASP.net 应用程序的最佳选择，将 LINQ 与.net 3.5 配合使用，XML 比 SQL 快得多。 而且您不必担心整天都会向 ms-sql-s 端口发送垃圾邮件。 -[数据流](https://cloud.google.com/dataflow/?hl=en)是一种托管流系统，旨在解决事件的混乱性质，以解决我们面临的挑战。 Dataflow 具有统一的流和批处理编程模型，流是旗舰功能。 +[http://www.keyoti.com/products/search/dotNetWeb/index.html](http://www.keyoti.com/products/search/dotNetWeb/index.html) -我们按照 Dataflow 的承诺被出售，并坦率地尝试了流模式。 不幸的是，在将其投入实际生产流量后，我们意外地感到惊讶： BigQuery 的流媒体插入成本。 +这些家伙有一个非常不错的搜索引擎，但是它只能通过爬网来搜索，但是您始终可以调整其源代码，对于应该支持的简单网站，也可以通过 Web 控件运行 -我们是根据压缩数据大小（即通过网络的实际字节数）而不是 BigQuery 的原始数据格式大小来估算的。 幸运的是，现在已记录在中，用于[每种数据类型](https://cloud.google.com/bigquery/pricing#data)。因此您可以进行数学计算。 +乔录制了一个非常不错的播客，前段时间他在谈论这个话题。 你可以在找到它 -那时，我们低估了这笔额外费用 100 倍，这几乎使我们整个提取流程（Dataflow + BigQuery）的费用增加了一倍。 我们还面临其他限制，例如 [100,000 个事件/秒速率限制](https://cloud.google.com/bigquery/quotas#streaminginserts)，这很危险地接近我们所做的事情。 +[http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/“]( [http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/](http://deepfriedbytes.com/podcast/deep-fried-bytes-episode-4-scaling-large-web-sites-with-joe-stump-lead-architect-at-digg/) -好消息是，有一种方法可以完全避免流插入限制：批量加载到 BigQuery 中。 +凉。 谢谢。 有趣的是，这并没有出现在我的搜索中。 -理想情况下，我们希望将数据流以流方式与 BigQuery 以批处理方式一起使用。 那时，Dataflow SDK 中没有没有 BigQuery 批处理接收器用于无限制的数据流。 +“ Digg 使用 MemcacheDB 来扩展数据非规范化时发生的大量写入。” -然后，我们考虑开发自己的自定义接收器。 不幸的是，当时无法向无界数据流添加自定义接收器（请参阅 [Dataflow 计划添加对在未来版本](https://cloud.google.com/dataflow/model/custom-io)中写入无界数据的自定义接收器的支持-BeamBeam 现在有可能 是官方的 Dataflow SDK）。 +这是个绝妙的主意：**请勿非正规化！** -我们别无选择，只能将我们的数据流作业切换到批处理模式。 多亏了 Dataflow 的统一模型，仅需几行代码即可。 对我们来说幸运的是，我们能够承受因切换到批处理模式而引入的额外数据处理延迟。 +[http://kottke.org/04/10/normalized-data](http://kottke.org/04/10/normalized-data) -展望未来，我们当前的摄取架构基于 [Scio](https://github.com/spotify/scio) ，这是 Spotify 开源的用于数据流的 Scala API。 如前所述，Dataflow 本机支持 Pub / Sub，但 Kafka 集成还不成熟。 我们必须扩展 Scio 以实现偏移量检查点持久性并实现有效的并行性。 +很棒的文章，我非常喜欢 memcache，并已在我的 [http://www.kiran.org.in']( ->     ... -> -> } -> -> this.on = function（appcfg，userid，request，next）{ -> -> console.log（“ on：userid：” + userid +``“ request：” + JSON.stringify（request））; -> -> } - -上的 *方法接受请求并将其应用于状态定义。 这可以正常工作，但是处理用户可以与机器人进行交互的所有方式都会使代码看起来有些骇人。* - -### Identity and Authentication - -与 Slack 一样，Facebook 提供了专门用于 Messenger 的用户 ID，而我只是使用该 ID。 它不是真实的 Facebook 用户 ID，因此您不能使用 graph API 来获取大量用户信息。 该 ID 与问题一起存储，因此可以将答复直接发送给用户。 - -### Database - -与 Slack 的 Facebook 数据库 API 等效，因此用户数据存储在 DynamoDB 中 Facebook 特定的用户表中。 - -## 网站 - -![](img/f2c70cd017c86d78ddbcadea563ee25a.png) - -[Probot.us](https://probot.us/) 是 S3 上托管的单页应用程序。 作为单页应用程序，所有操作均使用 Slack 使用的相同 ProbotService API 完成。 使用 S3 的优点是我无需管理任何事情。 它是一个与其他网站非常相似的网站，因此我不会在此进行过多介绍，但有一些主题值得注意。 - -### 电子邮件崩溃 - -您是否曾经做过一些您最终不会做的事情，但还是成功了？ 这是另一个浪费时间的大错误。 毫无疑问，我不太擅长制作网站。 我希望这可以解释为什么我真正尝试完全避免制造一个。 - -我所做的是通过电子邮件使所有 Pro 交互工作。 问题将通过电子邮件发送给专业人士。 专业人士会通过电子邮件答复并回答问题。 电子邮件中的关键字使它可以解析和提取数据。 用户没有注意到差异，因为他们仍然会使用 Slack 或 Messenger。 - -这是流程：Probot 向 Pro 发送了电子邮件。 例如，将问题分配给专业人士时，他们将收到一封包含该问题的电子邮件，有关用户的信息以及将电子邮件映射回该问题所需的一些簿记属性。 专业人士会回覆他们的回应，并确保将文字插入正确的位置，以便可以正确解析。 AWS 收到了 Pro 的回复并将其保存到 S3 中。 这导致了 Lambda 函数被调用。 该功能将解析电子邮件，提取所有数据，并相应地更新用户。 - -尽管配置很麻烦，但实际上确实有效，并且编写代码很有趣。 只有我的测试专家讨厌它。 只是讨厌它。 当然，他们做到了，这对他们来说很糟糕。 因此，我最终制作了 Pro 仪表板，以管理我一直知道自己必须解决的所有 Pro 问题。 我还添加了一个收件箱，以便用户可以在网络上提问和管理问题。 同一网站还为 Slack 用户充当着陆页，以便他们可以将 bot 安装到他们的团队中。 - -### [HTG0 BC] - -尽管我已经在 Golang 中使用了完整的用户注册系统，但我希望将所有内容保留在 Node 中。 我决定重试一下，而不是重新发明轮子。 我不想对用户密码的安全性负责，Cognito 可以处理所有这些。 使用起来很棘手，这里的有一些奇怪的问题要弄清楚。 示例代码和文档可能会更好。 但是我最终得到了所有典型的流程-注册，忘记密码，更改密码，重新发送验证码，输入验证码等。 这并不容易，但是似乎可以可靠地工作。 - -### 节点和浏览器之间共享代码 - -这是我犯的另一个错误：我不打算在 Node 和浏览器之间共享代码。 到我意识到可以共享很多代码的时候，采用另一种模块哲学已经太费力了。 我确实共享代码，但是在包含导致在两种情况下都不起作用的依赖项的代码时，我必须非常小心。 - -## PayPal 集成 - -我选择 PayPal 是因为我发现它们的 API 是可以理解的，其仪表板是可以使用的，并且其文档是可以使用的。 支持速度很慢，但通常会有所帮助。 - -当用户接受专业人士对其问题的回答时，付款状态机将启动。在 ProbotService 中，PayPal API 用于创建发票，该发票由 PayPal 发送到用户的电子邮件地址。 通过 PayPal，您可以配置一个 Webhook 来使用发票相关事件。 Webhook 使用绑定到 Lambda 函数的 API 网关。 - -当 Lambda 函数接收发票事件时，它将在事情发生时通知用户和 Pro。 - -* 松弛：通过前面描述的 SQS 机制通知用户。 专业人士会收到一封电子邮件，告知他们应该前往仪表板了解详细信息。 绝不会通过电子邮件发送任何敏感信息。 - -* Messenger：发短信给用户。 请注意，要在上次联系后 24 小时向用户发送消息，您必须对机器人具有特殊权限。 这并不总是容易获得的。 因此，如果您的机器人需要提前进行此类功能计划。 - -* Web：向用户发送电子邮件，并要求用户登录 Probot 以获得其仪表板上的更多信息。 - -这花了一些时间才能开始工作。 如果未调用与 Webhook 关联的 Lambda 函数，则很难理解问题所在。 绝对打开 A​​PI 网关日志记录。 您将需要它。 - -PayPal Lambda 函数使用与前面所述相同的代码共享方法。 无需进行远程 ProbotService 调用，而是直接调用代码。 - -## 测试 - -这里没什么好想的。 - -对于 API 网关，Lambda 和 DynamoDB，有所有版本的测试和生产版本。 根据配置在运行时选择使用哪个。 - -该网站有测试和生产版本。 为了测试它们，我只使用所有功能。 使用 *aws s3* 命令行将文件从开发环境复制到 S3。 对于本地开发，将 http-server 用作 Web 服务器，并且可以通过 localhost 测试所有功能。 - -PayPal 具有测试和生产配置选项。 每个都分别指向测试和生产网络挂钩。 PayPal 具有在调用 Webhooks 时记录的日志，这在调试时很有用。 不幸的是，事件不是实时发送的，因此您必须等待事件发送和日志出现。 - -对于 Slack，有一个单独的机器人，用于测试和生产。 每个都分别指向测试和生产网络挂钩。 Messenger 也是一样。 除了将测试版本和生产版本视为完全不同的漫游器之外，我没有其他更清洁的方法。 - -对于本地开发，Slackbot 在开发计算机上运行。 Ngrok 用作隧道，因此 Slack 可以向该进程发送交互式消息。 使用网站的测试版本将测试机器人安装到团队中。 它具有正确的应用程序令牌，可以识别机器人的测试版本。 安装测试机器人后，您可以通过 Slack 与该机器人对话。 - -对于本地开发测试，通过共享代码使 Lambda 代码变得更加容易。 唯一可以调用的外部服务是其他人的服务，而不是您自己的服务。 因此，要进行测试，根本不需要将代码上传到 Lambda。 Lambda 函数中使用的相同代码可从可从命令行执行的脚本中调用。 为您 API 中的每个函数创建一个相应的脚本，并且可以在本地对其进行完全调试。 - -Messengerbot 的本地开发测试比较棘手，因为将消息发送到 bot 时，消息会显示在 Messenger 中。 当您点击按钮时，回复将返回到您的测试网络挂钩。 据我所知，尚无干净的方法可以以可单元测试的方式进行此操作。 我所做的是将 Bot 的测试版本安装到 Messenger 中并记录了用户 ID。 在为每个方案制作测试脚本时，在运行时选择要使用的用户 ID，测试版本或生产版本。 如果方案涉及要求用户回答问题，则将从脚本中发送问题。 然后，您转到手机上，然后使用测试机器人进行回复。 答复将转到您的测试网络挂钩，以便代码可以正常运行。 我对这种方法不是很满意，但是这种方法行之有效，而且比通过 Messenger 进行的所有测试都更快。 - -总有一天应该从 GitHub 安装所有内容，但是今天不是那天。 - -## 采纳 - -吸收不好。 我希望随着税收季节临近活动的到来。 问题的一部分在于，作为一名程序员，我几乎迷上了营销。 我正在尝试 Messenger Bot 广告，但是这些广告无效。 - -使用尝试使漫游器不转化的渠道隐喻用户，他们在实际转化并提出问题之前已经保释。 可能存在信任问题。 他们不知道他们在问谁或将得到什么样的答案。 我尝试在网站和漫游器页面上解决这些问题。 例如，如果您不喜欢答案，则无需付款，因此无风险。 - -一种可能性是人们并没有真正使用 Messenger 机器人，并且对于此类应用程序的实验失败。 - -另一个可能性是我的机器人不是很好。 完全有可能的事情。 - -如果您有任何想法或疑问，请告诉我。 - -## 获得的经验教训 - -* **不要做您所知道的**。 在盲目做您知道的事情之前，先环顾四周，看看是否有更好的选择。 - -* **API 优先**。 为您的服务提出一个抽象并将其实现在一个地方。 当您必须在不同的平台上实现另一个客户端时，您将感激不尽。 - -* **DTO 首先**。 我犯了通过代码库传播数据库访问代码的错误。 只需创建一个数据传输对象并将代码从一开始就集中在一个地方即可。 然后，可以轻松打包和重用它。 - -* **一次**。 要做的聪明的事情是必须使一个简单的机器人来测试这个概念。 我当时知道这一点，但是我真的很想看看在所有三个平台上开发一个机器人的感觉。 那个决定的人是个白痴。 - -* **吻**。 这么容易说，很难做到。 - -* **提前计划共享节点和浏览器模块**。 一旦已经编写了很多代码，就很难进行改造。 - -* **代码共享**。 在 Lambda 函数之间共享很好的模块化库代码在实践中效果很好。 它使从命令行进行测试变得容易。 - -* **无服务器作品**。 由于种种原因，每个人都在涌动。 它可以让一个人完成很多工作。 您有发展机会，但管理起来却少得多。 对于不可预测的工作负载，它便宜得多且可扩展性更高。 我不能说工具很烂，因为我选择不使用任何工具，但是我们仍然有一种方法可以弄清所有这些在实践中是如何工作的。 - -* **事件> API** 。 使用 webhooks 使用 Serverless 将系统连接在一起非常强大。 相比之下，站起来放一个盒子并运行一个过程来使用 API​​似乎很原始。 - -像大多数课程一样，回想起来，大多数这些令人沮丧的头脑震撼显而易见，但是我想这就是为什么它们是课程。 - -看起来很酷 - -哇听起来真酷 您是独自建造的吗？ 花了多少时间？ - -是的，只有我。 这花了一个令人尴尬的时间:-) - -@ToddHoff 几乎所有编程都可以，尤其是在您必须学习新知识的情况下，这几乎总是这样，因为有各种各样的工具可以完成工作。 - -您的帖子非常有趣。 我正在尝试从中学习。 但是我不明白一件事。 - -您提到了为 lambda 创建单个入口点，然后将请求路由到单独的函数。 但是，如果没有 API 网关，请求如何首先到达 lambda？ - -嗨，杰克， - -可以通过 API 直接调用 Lambda 函数。 他们不需要通过 HTTP。 我大致是这样做的： - -包括适用于您的环境的 AWS API，对于 Web 或节点中的 AWS API 有所不同。 - -appcfg.AWS = require（“ aws-sdk”）; -appcfg.DB =新的 appcfg.AWS.DynamoDB（）; -appcfg.DBCLIENT = new appcfg.AWS.DynamoDB.DocumentClient（）; -appcfg.LAMBDA = new appcfg.AWS.Lambda（）; -appcfg.SES =新的 appcfg.AWS.SES（）; -appcfg.SQS = new appcfg.AWS.SQS（）; - -函数 ProbotService（appcfg）{ -this.id = 0; -var self = this; - -this.invokeLambda = function（method，params，next）{ - -var payload = { -method：method， -params：params， -id：self.id ++ -} - -var params = { -FunctionName：appcfg.Amazon.ProbotService， -Payload：JSON.stringify（payload） -} - -appcfg.LAMBDA.invoke（params，function（error，response）{ -if（error）return next（error）; - -var payload = JSON.parse（response.Payload）; -如果（payload.error）返回 next（payload.error）； -如果（payload.errorMessage）返回 next（new Error（payload.errorMessage））； - -返回 next（空，payload.result）； - -}）//调用 - -} // invokeLambda - -嗨，托德， - -感谢您的广泛回应！ - -实际上，我知道如何调用 lambda。 我从您调用它的地方很好奇。 看来您可能是从客户端调用它的？ - -PS。 我刚刚开始学习 nodejs。 因此，无论我说什么，都可能变得毫无意义。 - -是的，无论是在 Slack 上的 nodejs 内，还是 lambda 本身的 nodejs 内，网站上的客户端都是如此。 尽管几天前我关闭了 slackbot。 太昂贵了，无法继续运行。 - -只需为环境添加正确的库并正确配置即可。 - -在网上： - -<脚本 src =“ js / aws-cognito-sdk.js” > < / script > -<脚本 src =“ js / amazon-cognito-identity.min.js” > < / script > -<脚本 src =“ https://sdk.amazonaws.com/js/aws-sdk-2.3.5.min.js” > < / script > - -在 slack 和 lambda 上，它们将 sdk 安装到 node_modules 中，并且由于用户看不到环境，因此可以从文件加载配置。 -var AWS = require（'aws-sdk'）; -AWS.config.loadFromPath（'cfg.json'）; -appcfg.AWS = AWS; - -我保持对 appcfg 中所有服务的访问权并将其传递。 这样，您可以在启动时以特定于环境的方式配置所有内容。 - -现在，您可以在所有环境中使用相同的 lambda 调用代码。 - -this.giveAnswerToPro = function（answer，next）{ -return self.invokeLambda（“ giveAnswerToPro”，答案，下一步）; -} // GiveAnswerToPro - -这是我的模块问题出现的地方。您必须小心在每个环境中包含的内容。 在网络资料中包含一个在 nodejs 中不可用的模块，您已将其破坏。 - -这很酷。 您是否考虑过在营销中使用会计师的图片和/或个人资料？ 甚至有照片。 主页上显示“真实的会计师”，因此看到它可能会让人放心。 - -Hi Todd, - -感谢您的回复！ - -我知道可能要问很多。 但是，如果您不介意，会介意开放源代码并与我们共享吗？ -对像我这样的人进入 nodejs 和 aws 领域确实很有帮助。 - -谢谢。 - -我得考虑杰克。 我不确定如何将我的东西充分分离出来。 - -有趣的文章。 \ No newline at end of file +哦...看来杰里米从未回答... \ No newline at end of file diff --git a/docs/41.md b/docs/41.md index cd18f01..d31c717 100644 --- a/docs/41.md +++ b/docs/41.md @@ -1,103 +1,131 @@ -# 美国大选期间城市飞艇如何扩展到 25 亿个通知 +# 《 FarmVille》如何扩展以每月收获 7500 万玩家 -> 原文： [http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html](http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html) +> 原文： [http://highscalability.com/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html](http://highscalability.com/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html) -![](img/8a073c8483bfc1f227aed0829dbb7f84.png) +*一些读者对本文有后续问题。 可以在[《 FarmVille 如何缩放-后续行动》](http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html) 中找到卢克的回应。* -*这是 Urban Airship 的来宾帖子。 贡献者：亚当·洛瑞（Adam Lowry），肖恩·莫兰（Sean Moran），迈克·赫里克（Mike Herrick），丽莎·奥尔（Lisa Orr），托德·约翰逊（Christine Ciandrini），阿什什·沃蒂（Ashish Warty），尼克·阿德雷德（Nick Adlard），梅勒·萨克斯·巴尼特（Mele Sax-Barnett），尼尔·凯利（Niall Kelly），格雷厄姆·福里斯特（Graham Forest）和加文·麦奎兰* +![](img/4dfef10759448f17402c25ab64e9e4bb.png)如果像 Zynga 的大热门《 Farmville 》中的真实耕种一样令人振奋，那么我的家人可能永远不会离开北达科他州那些严酷的冬天。 我的祖母过去讲的关于农业的可怕的睡前故事，在 FarmVille 中都不是真的。 [农民](http://w.good.is/post/What-Does-Farmville-Mean-for-Farmers/)赚钱，植物生长，动物从不拜访[红色谷仓](http://www.youtube.com/watch?v=eUJz3137EQ8)。 我想仅仅是因为保持鞋子干净整洁的魅力，才使得 FarmVille 在如此短的时间内成为“世界上最大的游戏”。 -Urban Airship 受到数以千计的希望通过移动技术发展的企业的信任。 Urban Airship 是一家成立 7 年的 SaaS 公司，拥有免费增值业务模式，因此您可以免费试用 [](https://www.urbanairship.com/lps/best-push-notification-service)。 有关更多信息，请访问 [www.urbanairship.com](http://www.urbanairship.com/) 。 目前，城市飞艇平均每天发送的推送通知超过 10 亿条。 这篇文章重点介绍了 2016 年美国大选的城市飞艇通知使用情况，并探讨了系统的架构-核心传递管道-为新闻发布者提供数十亿实时通知。 +FarmVille 如何扩展 Web 应用程序以每月处理 7500 万玩家？ 幸运的是，FarmVille 的卢克·拉吉里奇（Luke Rajlich）同意让我们了解他们的一些挑战和秘密。 这是卢克必须说的... -## 2016 年美国大选 +采访的形式是，我向卢克发送了一些一般性问题，他回答了以下答复： -在选举日前后的 24 小时内，Urban Airship 发出了 25 亿条通知，这是有史以来的最高日发送量。 这相当于在美国每人 8 条通知，或者世界上每部活动的智能手机 1 条通知。 尽管 Urban Airship 在每个行业垂直领域为超过 45,000 个应用程序提供支持，但对选举使用情况数据的分析显示，超过 400 种媒体应用程序占了这一记录量的 60％，随着跟踪选举结果并在一天之内发送 15 亿条通知 报告。 +> FarmVille 具有一组独特的扩展挑战，这是应用程序所特有的。 游戏必须迅速扩展。 该游戏在 4 天后每天有 100 万玩家，在 60 天后每天有 1000 万玩家。 在发布时，最大的社交游戏是每天 500 万玩家。 目前，《 FarmVille》推出后 9 个月的每日玩家有 2800 万，每月玩家有 7500 万。 这使得 FarmVille 的每月玩家人数超过了法国的全部人口。 FarmVille 有两个基本特征，这是独特的扩展挑战：它是世界上最大的游戏，并且是 Web 平台上最大的应用程序。 这两个方面都带来了 FarmVille 必须克服的一系列独特的扩展挑战。 在技​​术投资方面，FarmVille 主要利用开源组件，并且其核心是基于 LAMP 堆栈构建的。 +> +> 为了使 FarmVille 可扩展为游戏，我们必须适应游戏的工作量要求。 用户状态包含大量具有微妙而复杂的关系的数据。 例如，在服务器场中，对象无法相互碰撞，因此，如果用户在其服务器场上放置房屋，则后端需要检查该用户服务器场中是否没有其他对象占用重叠空间。 与大多数主要网站（如 Google 或 Facebook）读取量大不同，FarmVille 的写入工作量非常大。 数据读取与写入的比率为 3：1，这是令人难以置信的高写入速率。 到达 FarmVille 后端的大部分请求都以某种方式修改了玩游戏的用户的状态。 为了使其具有可扩展性，我们努力使我们的应用程序主要与缓存组件进行交互。 此外，由于我们正在有效地扩展游戏，因此发布新内容和功能往往会导致使用量激增。 新功能发布之日，负载峰值可能高达 50％。 我们必须能够容纳这种高峰流量。 +> +> 另一个方面使 FarmVille 规模成为 Web 平台上最大的应用程序，并且与世界上一些最大的网站一样大。 由于该游戏在 Facebook 平台内运行，因此我们对平台的延迟和性能差异非常敏感。 结果，我们做了很多工作来减轻延迟差异：我们大量缓存 Facebook 数据，并在性能下降时优雅地提高了平台的使用率。 FarmVille 已为 Facebook 平台部署了整个缓存服务器集群。 FarmVille 和 Facebook 平台之间的流量巨大：高峰时，FarmVille 和 Facebook 之间的流量大约为 3 Gigabit / sec，而我们的缓存群集又为应用程序提供了 1.5 Gigabit / sec。 此外，由于性能可以变化，因此应用程序可以动态关闭对平台的任何调用。 我们有一个可以调整的拨号盘，可以逐渐关闭返回平台的更多呼叫。 我们还努力使所有调用都返回平台，以避免阻塞应用程序本身的加载。 这里的想法是，如果其他所有方法都失败了，则玩家至少可以继续玩游戏。 +> +> 对于任何 Web 应用程序，高延迟都会杀死您的应用程序，而高度可变的延迟最终会杀死您的应用程序。 为了解决高延迟问题，FarmVille 致力于在高延迟组件之前放置大量缓存。 高度可变的延迟是另一个挑战，因为它需要重新考虑应用程序如何依赖其体系结构中通常具有可接受的延迟的部分。 几乎每个组件都容易受到这种可变延迟的影响，其中一些比其他组件更容易受到影响。 由于 FarmVille 的性质（工作量非常大且事务繁重），与传统的 Web 应用程序相比，延迟的变化对用户体验的影响更大。 FarmVille 处理这些情况的方式是通过将每个组件都视为可降级的服务来考虑。 Memcache，数据库，REST Apis 等都被视为可降解服务。 服务降级的方式是为该服务的错误限制率并实施服务使用限制。 关键思想是通过使用错误和超时限制来隔离故障和高延迟的服务，以免在其他地方引起延迟和性能问题，并在需要时使用打开/关闭开关和基于功能的调节器禁用应用程序中的功能。 +> +> 为了帮助管理和监视 FarmVille 的 Web 场，我们利用了许多开源的监视和管理工具。 我们使用 nagios 进行警报，使用 munin 进行监视，并使用 puppet 进行配置。 我们大量利用内部统计系统来跟踪应用程序使用的服务（例如 Facebook，DB 和 Memcache）的性能。 此外，当我们发现性能下降时，我们会以采样为基础来分析请求的 IO 事件。 -![](img/36ce3f158f2a647278f8b998ea2b34fc.png) +## 得到教训 -总统选举结束时，通知量稳定并达到顶峰。 +关于某些事情，我没有那么多的细节，但是我认为人们仍然可以从中学习很多有趣的观点： -![election-urbanairship-notification.png](img/ed7aba40e08757f46f3ab55d602e8ec5.png) +1. **交互式游戏写得很重**。 典型的 Web 应用程序读取的内容多于编写的内容，因此许多常见的架构可能还不够。 读取繁重的应用程序通常可以通过单个数据库前面的缓存层来解决。 写繁重的应用程序需要分区，以便写操作可以分散和/或使用内存架构。 +2. **将每个组件设计为可降解服务**。 隔离组件，以使一个区域中的延迟增加不会破坏另一个区域。 节气门使用有助于缓解问题。 必要时关闭功能。 +3. **缓存 Facebook 数据**。 当您非常依赖外部组件时，请考虑缓存该组件的数据以提高延迟。 +4. **提前计划新的与发布有关的使用峰值**。 +5. **样本**。 在分析大型数据流时，例如查找问题，并不是每个数据都需要处理。 采样数据可以产生相同的结果，从而减少工作量。 -到城市飞艇的 HTTPS 入口流量 [API](http://docs.urbanairship.com/api/ua.html) 在选举期间达到了每秒近 75,000 的峰值。 这些流量大部分来自与城市飞艇 [API](http://docs.urbanairship.com/api/ua.html) [ 。 +我要感谢 Zynga 和 Luke Rajlich 抽出宝贵的时间进行这次采访。 如果其他人有他们想要的架构，请告诉我，我们会进行设置。 -![election-urbanairship-HTTPS.png](img/f308127dc795976d958424e5b22196a5.png) +## 相关文章 -推送通知量一直在迅速增加。 最近的主要推动力是英国退欧，奥运会和美国大选。 2016 年 10 月，每月通知量同比增长 150％。 +1. [建立大型社交游戏](http://www.slideshare.net/amittmahajan/building-big-social-games)-讨论 FarmVille 背后的游戏机制。 +2. [BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展](http://highscalability.com/blog/2010/1/22/how-buddypoke-scales-on-facebook-using-google-app-engine.html) +3. [策略：减少数据集的样本](http://highscalability.com/blog/2008/4/29/strategy-sample-to-reduce-data-set.html) +4. HighScalability 发布了[缓存](http://highscalability.com/blog/category/caching)和[内存缓存](http://highscalability.com/blog/category/memcached)的信息。 +5. HighScalability 发布了[分片](http://highscalability.com/blog/category/sharding)。 +6. 高扩展性发布在[内存网格](http://highscalability.com/blog/category/memory-grid)上。 +7. [如何在不进行实际尝试的情况下成功完成容量规划：Flickr 的 John Allspaw 专访他的新书](../../blog/2009/6/29/how-to-succeed-at-capacity-planning-without-really-trying-an.html) +8. [缩放 FarmVille](http://perspectives.mvdirona.com/2010/02/13/ScalingFarmVille.aspx) ，作者是 James Hamilton -![monthly-sends.png](img/edd6f898ff8977d6b6b3e7259682ce3e.png) +哇！ Farville 只是从“最烦人的网络事物”发展为“技术挑战的最酷示例。在我的个人词典中，那是:) -## 核心交付管道架构概述 +我要做的最后一件事是贬低 Zynga 的优秀人才所取得的成就，但是这里存在一个巨大的疏忽错误……Zynga 运行着一个 200 节点的 Vertica 集群。 数据存储的可伸缩性非常重要，不是吗？ 同事： -核心交付管道（CDP）是城市飞艇系统，负责从观众选择器中实现设备地址，并传递通知。 无论我们同时发送给数千万用户，针对多个复杂子细分市场，包含个性化内容或两者之间的任何内容，我们发送的所有通知都期望低延迟。 这是我们的架构的概述，以及我们在此过程中学到的一些知识。 +“运行 Vertica 的 200 个节点...如果您无法进行横向扩展，则应该改用 7-11 计数器工作” -### 我们是如何开始的 +披露：我不为 Vertica 工作，呵呵。 -最初始于 2009 年，最初是一个 Web 应用程序，一些工作人员已转变为面向服务的体系结构。 随着旧系统的各个部分开始出现规模问题，我们将它们提取到了一个或多个新服务中，这些服务旨在满足相同的功能集，但规模更大且性能更好。 我们许多原始的 [API](http://docs.urbanairship.com/api/ua.html) API 和工作程序都是用 Python 编写的，然后将它们提取到高并发 Java 服务中。 在最初将设备数据存储在一组 Postgres 分片中的地方，我们的规模迅速超过了添加新分片的能力，因此我们转向使用 HBase 和 Cassandra 的多数据库体系结构。 +@森林 -CDP 是处理分段和推送通知传递的服务的集合。 这些服务根据请求提供相同类型的数据，但是出于性能原因，每个服务都以不同的方式对数据进行索引。 例如，我们有一个系统负责处理广播消息，向注册到相关应用程序的每个设备传递相同的通知有效负载。 该服务及其底层数据存储区的设计与我们负责根据位置或用户个人资料属性传递通知的服务的设计有很大不同。 +有趣。 我认为 200 个节点运行起来不是很昂贵吗？ 否则，似乎值得指出的是开发自己开发的产品还是购买现成产品的决定。 -我们将任何长期存在的进程视为一项服务。 这些长期存在的过程遵循有关度量，配置和日志记录的通用模板，以简化部署和操作。 通常，我们的服务属于以下两类之一：RPC 服务或使用者服务。 RPC 服务使用非常类似于 GRPC 的内部库提供命令来与服务进行同步交互，而消费者服务则处理来自 Kafka 流的消息并对这些消息执行特定于服务的操作。 +令人失望的是，太笼统的:( +会令人着迷，以至于它们实际上没有读懂一些细节。 +他们使用的是云服务器还是专用服务器？有多少服务器？什么数据库？LAMP 中的哪个“ P”（php，perl，python， 等）？降低服务质量的示例？ +多肉，少起毛.. :) +至少与先前 CNBC 文章中详述的内容相同。 -![urbanairship-cdp.png](img/8f0bf13a515234268219ff976be393a9.png) +我怀疑游戏是否触及了 Verica 集群。 那是一个离线处理系统 -### 数据库 +本文并未明确说明使用哪个数据存储来保存每个数据库及其服务器场。 是 MySQL 吗？ MySQL 集群？ 其他一些 NoSQL DB？ -为了满足我们的性能和规模要求，我们严重依赖 HBase 和 Cassandra 来满足我们的数据存储需求。 尽管 HBase 和 Cassandra 都是列式 NoSQL 存储，但它们的取舍却大不相同，这些折衷影响我们使用哪个存储以及用于什么目的。 +这是一个很好的简介。 -HBase 非常适合高通量扫描，响应的预期基数很高，而 Cassandra 非常适合低基数查找，其中响应仅包含少数结果。 两者都允许大量的写入吞吐量，这是我们的要求，因为来自用户手机的所有元数据更新都是实时应用的。 +但与往常一样，细节中还是“恶魔”。 -它们的故障特性也不同。 在发生故障时，HBase 支持一致性和分区容忍度，而 Cassandra 支持可用性和分区容忍度。 每个 CDP 服务都有一个非常特定的用例，因此具有高度专业化的架构，旨在促进所需的访问模式并限制存储空间。 通常，每个数据库仅由单个服务访问，该服务负责通过不太专门的界面提供对其他服务的数据库访问。 +我们在哪里可以获得有关实际应用程序堆栈/硬件的更多指标，从而可以很好地了解可扩展性和可扩展性？ -增强服务与其支持数据库之间的 1：1 关系具有许多好处。 +显然，它在 Amazon EC2 上运行。 只需在上面放一个嗅探器，您就会看到详细信息。 -* 通过将服务的支持数据存储视为实现细节而不是共享资源，我们获得了灵活性。 +因此，他们的 Web 2.0 策略是尽可能利用用户的驱动器和资源并减少净流量。 -* 我们可以在不更改服务代码的情况下调整服务的数据模型。 +哇。 我永远不会认为它是 2.0，因为所有 0.1 游戏都在本地运行并且 MMRPG 相对较新，但是我知道什么。 -* 使用情况跟踪更为直接，这使容量规划更加容易。 +在其他新闻中，显然有 7500 万人需要工作。 我尝试了几种网络应用程序游戏，发现它们乏味，有限且普遍乏味。 我也鄙视 facebook 上不可避免的重复性和不可避免的通知，以至于我不再使用它，而不是每月一次向远处的朋友签入。 -* 故障排除更加容易。 有时服务代码存在问题，而其他时候则是备份数据库问题。 将服务和数据库作为逻辑单元可以极大地简化故障排除过程。 我们不必怀疑“还有谁可以访问该数据库以使其表现为这种方式？” 相反，我们可以依靠服务本身的应用程序级指标，而只担心一组访问模式。 +令人惊讶的是，一个设计欠佳的博客引擎如何将新闻发布为 myspace，以及大量广告如何将数百万个广告吸引到了 Facebook。 我仍然收到不存在者的 Facebook 邀请。 仅在过去的两年中，我就已经拥有了一百多个。 似乎没人对此多说。 -* 因为只有一种服务与数据库交互，所以我们几乎可以执行所有维护活动，而无需停机。 繁重的维护任务成为服务级别的问题：可以在不中断服务的情况下完成数据修复，架构迁移，甚至切换到完全不同的数据库。 +商业道德规则 1： -的确，在将应用程序拆分为较小的服务时，可能需要进行一些性能折衷。 但是，我们发现，在满足高可伸缩性和高可用性要求方面获得的灵活性远远超过了其价值。 +如果一家公司必须撒谎，欺骗或窃取才能开展业务，那么您会尽力避免这种情况。 除非，当然，除非您喜欢与它们进行比较，并与 yahoo（启用垃圾邮件的公司），Friendfinder（曾经是世界上最大的垃圾邮件发送者）进行比较。 这些公司通过几乎不提供任何服务来为自己做得很好。 -### 数据建模 +欢迎来到炒作无所不在的美国。 -我们的大多数服务都处理相同的数据，只是格式不同。 一切都必须一致。 为了使所有这些服务的数据保持最新，我们严重依赖 Kafka。 Kafka 非常快，也很耐用。 速度需要权衡。 Kafka 邮件只能保证至少发送一次 ，并且不能保证依次发送。 +@paul 我想你错过了一些事情。 这些游戏绝对可以打到 Vertica 集群。 Vertica 的一些最大客户是高频交易者，他们使用它来处理实时数据流。 您为什么认为这是一个“离线处理系统”？ 有了这样大小的集群，我相信 Zynga 可以很好地汇总其 3TB 的每日 Farmville 数据。 -我们如何处理？ 我们已将所有变异路径建模为可交换的：操作可以按任何顺序应用，并最终得到相同的结果。 它们也是幂等的。 这有一个很好的副作用，我们可以重播 Kafka 流以进行一次性数据修复作业，回填甚至迁移。 +这是一篇带有更多参考数字的文章： -为此，我们利用了 HBase 和 Cassandra 中都存在的“单元版本”的概念。 通常，这是一个时间戳，但是可以是您想要的任何数字（有一些例外；例如，MAX_LONG 可能会导致一些奇怪的行为，具体取决于您的 HBase 或 Cassandra 的版本以及您的架构如何处理删除操作）。 +http://tdwi.org/Blogs/WayneEckerson/2010/02/Zynga.aspx -对我们来说，这些单元格的一般规则是它们可以具有多个版本，而我们订购版本的方式则取决于其提供的时间戳。 考虑到这种行为，我们可以将传入的消息分解为一组特定的列，然后将布局与自定义应用程序逻辑结合起来进行逻辑删除，同时考虑时间戳。 这样就可以在保持数据完整性的同时盲写基础数据存储。 +我相信他们正在使用 [Wink Streaming 的 CDN](http://www.winkstreaming.com) 来执行此操作。 我想这都是关于负载分配的。 -盲目地将更改写入 Cassandra 和 HBase 并非没有问题。 一个很好的例子是在重放事件中重复写入相同数据的情况。 由于我们努力使记录成为幂等，虽然数据的状态不会改变，但必须压缩重复的数据。 在最极端的情况下，这些额外的记录可能会导致大量的压缩延迟和备份。 由于这个细节，我们密切监视压缩时间和队列深度，因为在 Cassandra 和 HBase 中落后于压缩会导致严重的问题。 +麦克风 -通过确保流中的消息遵循一组严格的规则，并设计使用服务以预期乱序和重复的消息，我们可以使大量不同的服务仅同步一两个秒 滞后的更新。 +7500 万听上去很酷，但请想象一下中国网站面临的挑战。 我的未婚夫是中国人，他们玩的农业游戏拥有数亿活跃玩家。 尊重该游戏的编码团队：） -### 服务设计 +我认为这是一个非常有趣的领域（高流量在线游戏） -我们的大多数服务都是用 Java 编写的，但是使用的是一种自以为是的现代风格。 在设计 Java 服务时，我们有一组常规准则需要考虑： +谢谢 -* **做一件事，做好它。** -设计服务时，它应该承担单一责任。 实施者可以决定职责中包括的内容，但是他或他将需要准备在代码审查情况下证明其合理性。 +我喜欢这篇文章，但是我想了解更多有关如何实现的信息。 使用了什么“胶水”的高层次视图来将所有抽象片段组合在一起？ LAMP 堆栈是一个不错的开始，但是主要零件的快速飞越（使用的设备可获得加分）将非常酷。 -* **没有共享的操作状态** -设计服务时，假定将始终至少有三个实例在运行。 服务需要能够在没有任何外部协调的情况下处理任何其他实例可以处理的相同确切请求。 那些熟悉 Kafka 的人会注意到，Kafka 使用者在外部协调对 topic：group 对的分区所有权。 本指南涉及特定于服务的外部协调，而不是利用可能在幕后进行外部协调的库或客户端。 +无论哪种方式，Farmville 绝对是可扩展性的令人印象深刻的示例。 我喜欢它！ -* **约束您的队列** -我们在服务中使用队列，它们是将请求分批并将其散布到最终将完成任务的工作人员的好方法 从外部阻止。 所有队列都应有界。 边界队列确实引发了许多问题，但是： +> 它是网络平台上最大的应用程序 - * 当队列已满时，生产者会怎样？ 他们应该阻止吗？ 除？ 下降？ +嗯...闻起来像是胡说八道！ - * 我的队列应该有多大？ 要回答此问题，有助于假设队列始终已满。 +实际上，他没有办法知道这一点。 即使无法证明，也可以确保“听起来不错”。 - * 如何完全关闭？ +可降解服务的概念看起来非常不错。 有谁知道其他案例研究已经解释了吗？ 我当然想了解更多。 - * 根据确切的用例，每个服务将针对这些问题提供不同的答案。 +@Robert Schultz +仅在没有最大定义的意义上才是 BS。 即使定义了它，也可能是值得商 bat 的指标。 -* **命名自定义线程池并注册 UncaughtExceptionHandler** -如果最终创建自己的线程池，则使用 [的构造函数或帮助器方法 ]执行器](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html) ，以便我们提供 ThreadFactory。 使用该 ThreadFactory，我们可以正确地命名线程，设置线程的守护进程状态并注册 [UncaughtExceptionHandler](https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler-) 以处理将异常置于顶部的情况 堆栈。 这些步骤使调试我们的服务变得更加容易，并且使我们避免了深夜的沮丧。 +这是故事的另一面： +http://techcrunch.com/2009/10/31/scamville-the-social-gaming-ecosystem-of-hell/ -* **优先于可变状态而不是可变状态** -在高度并发的环境中，可变状态可能很危险。 通常，我们使用可以在内部子系统和队列之间传递的不可变数据对象。 拥有不变对象是子系统之间通信的主要形式，这使得并发使用的设计更加简单，并且使故障排除更加容易。 +Spyder， -## 我们从这里去哪里？ +关于技术紧缩的文章充斥着错误的信息。 不良报价在被发现后立即被取消。 制定了一个流程来确保它不再发生。 -凭借 Urban Airship 通过移动钱包通行证发送通知的功能，对 Web 通知和 Apple News 通知的新支持以及其将通知发送到任何平台，设备或营销渠道的开放渠道功能，我们预计通知量将成倍增长 。 为了满足这一需求，我们将继续在“核心交付管道”架构，服务，数据库和基础架构上进行大量投资。 要了解有关我们技术的更多信息以及前进的方向，请参阅 [GitHub](https://github.com/urbanairship) ， [开发人员资源](http://docs.urbanairship.com/dev-resources.html) ， [文档](http://docs.urbanairship.com/index.html) 和我们的 [职位页面](https://www.urbanairship.com/careers) 。 \ No newline at end of file +有趣的文章，但是对他们正在使用的 LAMP 标度的技术方面有更多的了解将是很棒的。 他们正在使用 MySql 群集吗？ MySQL 复制？ 他们如何管理故障转移？ 显然他们也使用 EC2。 +这对我们所有人来说都是一个很好的例子。 + +我真的很喜欢一个网站每天最多可扩展到 2800 万用户的事实，这在游戏界确实是一个庞大的数字，而且写工作量很大。 \ No newline at end of file diff --git a/docs/42.md b/docs/42.md index 57c787e..1addc26 100644 --- a/docs/42.md +++ b/docs/42.md @@ -1,188 +1,133 @@ -# QuickBooks 平台 +# Twitter 计划分析 1000 亿条推文 -> 原文： [http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html](http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html) +> 原文： [http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) -![](img/f467ec8cf4d38d56b883aa13f1ef804a.png) +![](img/2ad0f5c434cea68e0d66d5cc1a87723d.png)如果 Twitter 是某些人认为的“网络神经系统”，那么从神经系统来的所有这些信号（推文）的大脑究竟是什么呢？ 大脑就是 Twitter 分析系统，而 Twitter 的分析负责人 Kevin Weil 是负责计算超过 1000 亿条 Tweet（约等于人脑中神经元数量）含义的单元。 -*这是 Siddharth Ram –小型企业首席架构师的特邀帖子。 [[受电子邮件保护]](/cdn-cgi/l/email-protection#114278757579706365794e63707c51787f656478653f727e7c) 。* +目前，Twitter 仅占预期的 1000 亿条推文的 10％，但始终要做好计划。 Kevin 在 [Hadoop Meetup](http://www.meetup.com/hadoop/) 上的 Twitter 上发表了 [Hadoop 和协议缓冲区的演讲，解释了 Twitter 如何计划使用所有数据来回答关键业务问题。](http://www.slideshare.net/kevinweil/protocol-buffers-and-hadoop-at-twitter) -QuickBooks 生态系统是最大的小型企业 SaaS 产品。 QuickBooks 平台支持面向全球范围内的小型企业，其客户和会计师的簿​​记，薪资和付款解决方案。 由于 QuickBooks 还是合规&纳税申报平台，因此报告的一致性非常重要。财务报告要求查询具有灵活性-给定的报告可能具有数十种可以调整的不同维度。 协作需要员工，会计师和企业所有者同时进行多次编辑，从而导致潜在的冲突。 所有这些都导致在 Intuit 解决有趣的缩放问题。 +Twitter 有兴趣回答哪种类型的问题？ 帮助他们更好地了解 Twitter 的问题。 像这样的问题： -解决可伸缩性需要考虑多个时间范围和轴。 扩展不仅涉及扩展软件，还涉及人员可扩展性，流程可扩展性和文化可扩展性。 所有这些轴都在 Intuit 进行了积极的研究。 我们与员工的目标是营造一种氛围，使他们能够尽其所能。 +1. 一天我们要处理多少个请求？ +2. 平均延迟时间是多少？ +3. 一天有多少次搜索？ +4. 多少个唯一查询，多少个唯一用户，他们的地理分布是什么？ +5. 作为用户的推文，我们能告诉我们什么？ +6. 谁转发了更多？ +7. 移动用户的用法有何不同？ +8. 同时出了什么问题？ +9. 哪些功能使用户着迷？ +10. 用户的声誉是什么？ +11. 转推的深度有多深？ +12. 哪些新功能有效？ -# 背景 +还有更多。 这些问题可以帮助他们理解 Twitter，其分析系统可以帮助他们更快地获得答案。 -QuickBooks Online 产品已有十年半的历史了。 它是作为整体构建的，没有明确的关注点分离。 整体服务良好地服务于 Intuit –每天有数百万的客户使用它进行数亿笔交易。 这部分是可能的，因为产品内置了泳道。 这允许按公式划分比例（客户在特定分片中“归位”）进行缩放。 如今，我们可以将整体拆分为多种服务，并迁移到 AWS 作为主要托管解决方案。 +## Hadoop 和 Pig 用于分析 -## 数字 +您能想到的任何问题都需要分析大数据来寻找答案。 1000 亿是很多推文。 这就是 Twitter 使用 [Hadoop 和 Pig](http://www.slideshare.net/kevinweil/hadoop-pig-and-twitter-nosql-east-2009) 作为其分析平台的原因。 Hadoop 提供：在分布式文件系统上的键值存储，水平可伸缩性，容错性以及用于计算的 map-reduce。 Pig 是一种查询机制，可以在 Hadoop 之上编写复杂的查询。 -* 全球小型企业最大的 SaaS 产品 +说您正在使用 Hadoop 仅仅是故事的开始。 故事的其余部分是使用 Hadoop 的最佳方法是什么？ 例如，如何在 Hadoop 中存储数据？ -* 超过 500 万的台式机和网络客户 +这似乎是一个奇怪的问题，但答案却有很大的后果。 在关系数据库中，您不存储数据，数据库存储您，或者，它为您存储数据。 API 以行格式移动数据。 -* 每天处理 250M +请求 +Hadoop 并非如此。 Hadoop 的键值模型意味着由您决定如何存储数据。 您的选择与性能，可以存储多少数据以及对将来的变化做出反应的敏捷程度有很大关系。 -* 年增长率超过 40％ +每个推文都有 12 个字段，其中 3 个具有子结构，并且随着新功能的添加，这些字段可以并且会随着时间而变化。 存储此数据的最佳方法是什么？ -* 通过 AWS 进行全球扩展 +## 数据存储在协议缓冲区中以保持数据的高效和灵活 -* 全球约有 2,000 名工程师在产品上工作。 +Twitter 认为 CSV，XML，JSON 和协议缓冲区是可能的存储格式。 协议缓冲区*是一种以有效但可扩展的格式对结构化数据进行编码的方法。 Google 几乎所有内部​​RPC 协议和文件格式*都使用协议缓冲区。 BSON（二进制 JSON）尚未进行评估，但可能因为它没有 IDL（接口定义语言）而无法使用。 [Avro](http://hadoop.apache.org/avro/) 是他们将来会考虑的一种潜在选择。 -* 2000+ 3 个基于 Intuit 平台构建的 和 参与者应用程序 +创建了一个评估矩阵，该矩阵宣布 Protocol Buffers 为获胜者。 赢得协议缓冲区是因为它允许将数据拆分到不同的节点上。 它不仅可用于推文（日志，文件存储，RPC 等），还可用于其他数据； 它有效地解析； 可以添加，更改和删除字段，而无需更改已部署的代码； 编码很小； 它支持层次关系。 所有其他选项均未通过这些条件中的一个或多个。 -## 技术 +## IDL 用于 Codegen -* Java / JVM 是主要服务/后端 +出乎意料的是，效率，灵活性和其他神圣的怪胎指标并不是 Twitter 喜欢协议缓冲区的唯一原因。 通常被视为弱点的是，协议缓冲区使用 IDL 来描述数据结构，实际上被 Twitter 视为大赢家。 必须定义数据结构 IDL 通常被视为浪费时间。 但是作为构建过程的一部分，它们从 IDL 中生成所有与 Hadoop 相关的代码：协议缓冲区 InoutFOrmats，OutputFormats，Writables，Pig LoadFuncs，Pig StoreFuncs 等。 -* 多语言持久性–不同的用例需要使用不同的存储技术，QuickBooks 平台将 RDBMS（Oracle / MySQL），Neo4J 和 Cassandra 用于 OLTP 和 Hadoop & Vertica 进行分析 +以前为每个新数据结构手动编写的所有代码现在都可以从 IDL 中自动自动生成。 这样可以节省大量精力，并且代码的错误少得多。 IDL 实际上节省了时间。 -* 前端已使用 ReactJS 进行了重建，我们了解到缩放不仅适用于后端-前端缩放是我们开发的一项新技能。 +某一时刻，模型驱动的自动生成是许多项目的通用策略。 然后，时尚开始产生一切。 Codegen 似乎还不够敏捷。 一旦生成了所有内容，您就开始真正担心语言的冗长性，这使每个人都转向了更加动态的语言，具有讽刺意味的是，DSL 仍然经常被列为 Ruby 之类的语言的优势。 手编码的另一个后果是周炎的框架。 框架有助于平息认为必须从头开始编写所有内容而造成的损害。 -* 监控是使用多个内部和现成的工具完成的，现成的主要工具是 Splunk 和 New Relic +很高兴看到代码生成再次流行。 使用声明性规范，然后编写高效的，特定于系统的代码生成器，功能非常强大。 数据结构是低挂的果实，但是也可以自动化更大，更复杂的过程。 -* 通过企业 github 进行代码管理 +总体而言，这是一次非常有趣和有益的演讲。 我喜欢看到基于想要的内容和原因对不同选项进行的仔细评估。 令人耳目一新的是，这些明智的选择如何协同作用，并构成了一个更好，更稳定的系统。 -* ActiveMQ 和 Kafka 处理异步消息 +## 相关文章 -* Ansible 和 Chef 用于配置管理 +1. [Twitter 上的 Hadoop 和协议缓冲区](http://www.slideshare.net/kevinweil/protocol-buffers-and-hadoop-at-twitter) +2. [Twitter 背后的窥视](http://borasky-research.net/2010/02/17/a-peek-under-twitters-hood)-Twitter 的开源页面上线了。 +3. [Hadoop](http://hadoop.apache.org/) +4. [协议缓冲区](http://code.google.com/p/protobuf/) +5. [Hadoop 湾区用户组-2 月 17 日在 Yahoo! -RECAP](http://developer.yahoo.net/blogs/hadoop/2010/02/hadoop_bay_area_user_group_feb.html) +6. [Twitter 说](http://blog.twitter.com/2010/02/measuring-tweets.html)“今天，我们每天看到 5000 万条推文，平均每秒 600 条推文。” -* 大量使用边缘缓存和 Akamai WAA +> 这就是为什么 Twitter 使用 Hadoop 和 Pig 作为分析平台的原因 -## 文化 +has a broken url -* 每个服务都有定义了 RTO 和 RPO 的 HA / DR。 我们每周执行 HA / DR 计划，以确保在发生常规事件时对客户的影响很小甚至没有。 这是所有 SaaS 产品都需要计划和执行的最佳实践。 +谢谢。 似乎所有 URL 由于某种原因都被转义。 现在应该修复。 -* 高度重视弹性。 服务不可用通常并不意味着客户知道它。 +所有这些推文中有 99％是垃圾。 他们究竟将如何分析其中的任何内容？ -* 服务在内部服务门户中发布。 这使工程师可以重用其他团队构建的服务，并减少服务克隆。 +从理论上讲，每条推文都是一种人类思想或一种交流意识。 分析大量数据将意味着识别人脑在各个方面的功能-例如给定的时间，星期几，地理位置，文化，趋势等-因此，了解这种人类行为就构成了识别人的大脑。 在线大众。 （仅限于 Twitter）。 -* 性能是根据 TP99，TP90 和 TP50（通常更高）来衡量的。 TP50 代表第 50 个 第 个百分位数的客户体验。 我们的目标是 1 秒的 TP50 和 2 秒的 TP90。 （即少于 10％的客户在任何给定页面上的页面加载时间超过 2 秒）。 +最后，它是所有统计信息-一定比例的网络将为这种现象数据做出贡献。 -* 客户互动失败（FCI）是我们跟踪的另一个关键指标。 与客户（HTTP 4xx / 5xx）的每次失败交互都被视为失败交互。 我们的目标是使每项服务的 FCI 都低于 0.025％。 +希望我们能更多地了解人的思想链是如何运作的，并希望这有助于神经科学家作为研究工具。 -* 服务团队拥有端到端的服务。 他们负责与 devops 模型一致的服务维护和正常运行时间。 PagerDuty 用于提醒呼叫人员出现问题和参与恢复。 +我的$ 0.02 -* 您无法改善无法测量的内容。 通过近乎实时的仪表板，可以在公司的可用性，性能，可扩展性和质量指标方面广泛了解公司。 这是驱动组织行为的关键。 +〜Vj -* 我们正在过渡到反应性，松散耦合的系统 ，该系统可增强扩展能力。 但是，这需要仔细考虑如何处理系统中最终的一致性。 +几个月前，奇怪的 Twitter Twitter Tweet ID 泛滥成灾，他们怎么可能拥有 1000 亿条 Tweet？ -* 工程师对系统中的每个故障执行 RCA（根本原因分析）。 RCA 已由工程领导审核。 我们将 5 个“为什么”和“鱼骨”应用于每个 RCA。 失败是一位出色的老师 。 +我会用“神经系统”代替“神经系统”，“神经系统”将这些信号/推文发送给我们的外行贿赂者，改为“突触发射”，其中指出推文更恰当地是*大脑*内部的信号。 它是对信号触发或重推的分析，我们发现了模式，并且在这些模式中有意义。 -* 强烈的代码意识和域所有权。 +有关 Synaptic 网站的更多信息，请访问： -* 任务驱动。 当人们看到自己对客户的影响时，便会尽自己最大的努力。 +http://synapticweb.pbworks.com/ -* 在质量，性能，可用性和安全性上丝毫不妥协。 +@khrisloux -* 持续部署和功能切换使我们能够快速交付 +我要说的是 [Vivisimo 的 Velocity 搜索引擎](http://vivisimo.com/)可以为他们提供很多帮助。 -## 可伸缩性中的有趣挑战 +有趣的帖子，托德。 -# 缩放比例特性 +您的帖子中有一些复制错误： -QuickBooks Online 之类的产品具有与其他 SaaS 产品不同的缩放特性。 报表查询可能已应用了许多其他过滤器。 这些查询在公司之间通常是不同的。 报告会产生税收后果，因此必须始终与账簿保持一致。 会计和小型企业所有者可能同时进行多次编辑，才能进行协作。 该软件需要确定如何处理冲突。 所有这些导致在 Intuit 的 QuickBooks 平台上进行扩展的有趣方式。 +“ 5.作为用户，我们可以从他们的推特中获得什么？” | 可能应该是：我们能告诉用户什么... -# 变量 +“ 8.如果同时出错怎么办？” | 怎么了... -QuickBooks 平台为全球数百万个小型企业，其客户和会计师提供服务。 为客户提供各种用例：产品需要解决的可变性包括： +“ 11.转发的深度有多深？” | 有多深... -* 设备多样性–我们根据需要为客户提供服务-台式机，移动设备，在线 +不是要分析什么，而是要服务于什么业务目的。 -* 地理多样性–在全球范围内使用，伴随着法规的复杂性，要​​解决的税收往往非常本地化和专业化 +无论如何，tweet 中的 URI 可以为用户分析提供更多的价值。 -* 合规性多样性–不同的政府机构（例如工资税）对合规性有不同的规定 +“ Protocol Buffers 之所以获奖，是因为它允许将数据拆分到不同的节点上；它不仅可以用于推文（日志，文件存储，RPC 等），而且还可以重用；它可以高效地解析；可以添加，更改和删除字段而无需 更改已部署的代码；编码很小；它支持层次关系。所有其他选项都无法通过其中一个或多个条件。” -* 产品多样性–根据员工人数，他们所针对的市场性质（例如，基于产品的业务与基于服务的业务），不同的客户群具有不同的需求 +只需用纯文本替换 Protocol Buffer 并享受相同的方法即可：)严重的是，我没有得到 PB 选择背后的基本原理，但最终还是要随心所欲。 除非您在 hdfs 的顶部构建 HBase 之类的东西，否则当您运行冗长的批处理作业时，内部存储格式并不重要。 -* 工作流的多样性–公司可能拥有执行（并被授予）产品子集的工人。 例如，应收账款业务员将仅看到应收帐款流量。 员工通常不执行业务报告。 +“今天，我们每天看到 5000 万条推文，平均每秒 600 条推文。” -这是我们处理的多样性的子集。 尽管解决了很多多样性问题，但平台始终需要解决一些基本问题。 安全性，隐私性，可伸缩性和质量是软件基本构建模块的一部分。 +什么！？ -# 缩放哲学 +每秒 600 条推文！？ -QuickBooks 平台通常遵循“可扩展性多维数据集” 模型，在三个维度上进行缩放： +... -![](img/e14850f4600ff2e4f07d4add57be0c4a.png) +哇...我真是令人难以置信地不知所措...我的意思是我觉得 Twitter 可以解决所有这些可扩展性问题，因为它们每秒有成千上万甚至数十万条推文。 -## X 轴–只读副本 +天哪，如果他们用 C 编写 Twitter 系统，就可以轻松地通过单个服务器处理“所有”流量。 -X 轴主要用于只读副本。 与许多 SaaS 产品一样，与写入次数相比，读取次数很多。 常见的且相对昂贵的读取操作是报告。 小型企业和会计师需要了解他们的业务状况。 我们通过 QuickBooks Money Bar 提供见解，并通过大量报告（例如资产负债表，损益报告）提供更详细的见解。 只读副本使我们既可以减少访问的热点，又可以提供预先计算的报告 +无论哪种方式，我仍然认为 Twitter 是一个好主意，他们应该得到应有的荣誉，他们在 Twitter 的整个软件包和声誉方面都做得很好。 但是，为什么不聘请 C 程序员来重写他们的堆栈并降低成百上千的成本呢？ -## Y 轴-服务 +@罗伯特·古尔德（Robert Gould）：我也为如此低的数量感到惊讶。 虽然据我了解，问题不在于处理传入的 tweet，而是将它们发送给所有订户。 请记住，某些用户有数千个（或数百万个）关注者。 -扩展的第二个方面是在不同的服务中破坏产品。 QuickBooks 平台建模为 14 个不同的域，这些域组成了产品。 服务 API 现在是第四个修订版-V3 QuickBooks API 可以在 [http://developer.intuit.com](http://developer.intuit.com) 中找到。 +用 C 重写对可伸缩性没有多大帮助。 它将使系统稍微快一些，但不超过一个数量级，以可维护性，稳定性和开发速度为代价。 -### Z 轴-公式拆分 +我认为经过大量分析，并从大型 Twitter 数据库中获取了大量数据之后，我们会发现我们的逻辑性不如我们想像的那样，而且实际上是可预测的。 -Z 轴指的是“分片”（sharding）-允许大范围缩放的非规范化数据。 QuickBooks 根据公司的属性来拆分客户。 然后，每个分片将与具有类似属性的其他公司共享。 - -### C 轴 - -除了这些方面，我们经常谈论“ C”轴-文化轴，这是我们扩展规模的关键方法。 在 C 轴上对我们的主要增强是（a）度量文化–您无法解决无法观察到的问题（b）通过 devops 模型拥有所有权的文化，以及（c）在我们所做的任何事情中客户支持的思想。 - -### 缩放前端 - -在 200KLOC 以上，QuickBooks onlike 具有非常大的 Javascript 占用空间。 扩展前端的一部分意味着要理解如何确保更改是隔离的并且组件可以重复使用，以至于 3 个 rd 参与者可以直接插入前端，并且 任何遵循规则的人都可以贡献力量。 缩放还意味着在样式上具有统一性，易于坚持。 - -## 公有云之旅 - -Intuit 的一项关键策略是将所有软件资产移至 AWS。 在公共云中，给定共享的基础架构，还需要考虑安全性和隐私性。 在将软件迁移到 AWS 时，我们使用以下一般原则： - -* 必须保护每个端点。 在公共云中，我们不能假设服务之间的链接是安全的端点。 - -* 每个 Intuit 和 AWS 平台服务都必须是可观察的。 这种可观察性是能够分析欺诈和安全性访问的关键。 - -* 提升并移动+分解。 在适当的情况下，我们将分解为服务并迁移到公共云。 对于较大的系统，我们进入 AWS 基础架构并就地分解。 - -* 多区域 DR。 区域中断发生。 我们希望即使在单个地区受到影响时也能够提供服务。 - -* 在本地服务客户。 安全港 和性能都决定了靠近客户的数据存储。 这要求客户必须在本地区域“回国”（例如，在欧洲的 AWS 数据中心外服务的欧盟客户）。 - -* 爆炸半径遏制。 “无共享”方法可确保我们限制爆炸半径。 系统中断应该导致本地事件，而不是全局事件。 - -## 主要课程 - -* 3 轴缩放是关键。 知道哪些轴适用于正确缩放有助于缩放。 - -* 确保可以控制影响。 必须充分理解和测试系统的爆炸半径。 - -* RCA –失败是一位了不起的老师。 浪费失败的教训是可耻的。 架构师负责分析故障并找出根本原因。 - -* 不要低估重新考虑在公共云中保护软件的数量。 - -* Dogfood。 公司工程师使用的服务应与为 3 个 和 参与方开发人员提供的服务相同。 - -* 了解您的 KPI 并能够预测性能曲线的样子–这有助于快速识别出问题所在。 - -* 也可以缩放前端，而不仅仅是后端。 - -嗨，感谢您的帖子，它非常有用。 我想知道为什么您同时使用 ansible 和 Chef，因为我希望一家公司同时使用其中一种？ - -嗨，查理， - -并没有 Ansible 和 Chef 的强烈技术理由。 不同的团队使用了不同的技术。 随着时间的流逝，我们将逐步淘汰其中之一。 - -悉达思 - -您好 Siddharth， - -感谢您花时间描述系统。 由于您将整体拆分为服务，因此如何管理服务之间的安全性和身份验证？ - -嗨， - -好问。 在整体中，通信相对容易-只需进行另一个函数调用即可。 在分布式系统中，难度会增加一些-但技术仍然非常相似。 - -身份验证和安全协议是非常标准的。 Intuit 管理自己的身份系统。 每个请求必须具有身份验证上下文-包括服务器-服务器调用。 这些将很快到期，并分配新的票证。 SSL / TLS 是用于有线加密，客户端-服务器以及服务器-服务器通信的标准问题。 分析/监视查找访问模式中的异常。 - -您如何管理服务之间的安全性和身份验证？ - -据我所知，Intuit 使用 google oauth1.0 进行身份验证，这基本上是基于令牌的身份验证系统。 例如，您有一个使用者密钥和一个使用者密钥，您获得一个请求密钥和请求令牌，然后吐出一个访问令牌和访问密钥。 令牌有效期为 6 个月，不确定令牌何时到期才能访问那些基于 JAVA 的 REST API 和安全标准 SHA2 算法。 我写了一篇关于 SSL 握手的文章。 它应该有助于提供见解。 - -参考： -https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/ - -嗨， -很棒的文章，感谢您的分享，您可以解释一下是否有建立另一个 QuickBooks 或 Zoho Books 的范围？ -谢谢， -Divya， -[Quickbook Developer](http://www.catchexperts.com/quickbook-online-training) \ No newline at end of file +模式将得出结论，就像地球上所有其他生物一样，我们受到重力，季节，夜晚和白天的影响，x 类型的人更有可能鸣叫 x 等。我认为这一实验肯定会证实人类是 习惯的生物。 \ No newline at end of file diff --git a/docs/43.md b/docs/43.md index 6d5afe7..fffcc6b 100644 --- a/docs/43.md +++ b/docs/43.md @@ -1,378 +1,223 @@ -# 从将 Uber 扩展到 2000 名工程师，1000 个服务和 8000 个 Git 存储库获得的经验教训 +# MySpace 如何与 100 万个并发用户一起测试其实时站点 -> 原文： [http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) +> 原文： [http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html](http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html) - +这是 [SOASTA](http://www.soasta.com/) 副总裁 Dan Bartow 的嘉宾帖子，内容是他们如何使用 800 个 EC2 实例与 100 万并发用户共享 MySpace。 我认为这是一个有趣的故事，因为：用户很多，需要花费大量的精力来测试您的实时站点，而并非所有工作都能按预期进行。 我要感谢 Dan 抽出宝贵的时间写和分享这篇文章。 -为了了解 Uber 的成长情况，请看上述视频的前几秒钟。 它将在正确的位置开始。 它来自[，Uber 首席系统架构师和](https://www.linkedin.com/in/mranney) [Voxer](http://www.voxer.com/) 的共同创始人 Matt Ranney 的精彩演讲：[我希望将 Uber 扩展到 1000 个服务之前想知道的事情](https://www.youtube.com/watch?v=kb-m2fasdDY)（[[幻灯片](https://gotocon.com/chicago-2016/presentation/What%20I%20Wish%20I%20Had%20Known%20Before%20Scaling%20Uber%20to%201000%20Services)）。 +![](img/be1ad56cda54486333a6c1aca1ca39cf.png) -它显示了中国一些城市不断增长的，有节奏的，波动的交通网络。 世界各地的城市都在发生这种爆炸性增长的方式。 实际上，Uber 现在已遍布 400 个城市和 70 个国家/地区。 他们有 6000 多名员工，其中 2000 名是工程师。 仅仅一年半的时间，只有 200 名工程师。 这些工程师已经产生了 1000 多种微服务，这些微服务存储在 8000 多个 git 存储库中。 +在 MySpace 音乐先前取得成功的基础上，MySpace 在 2009 年 12 月在新西兰掀起了新的流音乐视频产品浪潮。 这些新功能包括观看音乐视频，搜索艺术家的视频，创建收藏夹列表等等的功能。 在 MySpace 等热门网站上，此类功能的预期负载增加是巨大的，他们希望在启用这些功能之前先进行测试。 -在短时间内疯狂增长 10 倍。 谁经历过？ 不太多。 就像您可能期望的那样，这种独特的，压缩的，快节奏的，高风险的经验必须教会您一些新知识，比以前理解的要深刻。 +如果您管理高流量应用程序背后的基础架构，则不会感到意外。 您想了解自己的断裂点，定义容量阈值，并知道在超过这些阈值时如何应对。 用实际的预期负载水平测试生产基础架构是了解高峰流量到达时事物将如何运行的唯一方法。 -马特不是这个游戏的新手。 他是 Voxer 的共同创始人，Voxer 经历了[的快速增长](http://www.marketwired.com/press-release/walkie-talkie-app-voxer-soars-past-billion-operations-per-day-powered-basho-riak-1603652.htm)，但这是不同的。 您可以在观看视频时告诉您 Matt 试图对他们所取得的成就表示满意。 +对于 MySpace，目标是在其实时站点上测试另外的 100 万并发用户，以强调新的视频功能。 这里的关键词是“并发”。 不到一个小时或一天的时间……网站上同时有 100 万用户同时活动。 应当指出，一百万个虚拟用户只是 MySpace 在高峰期通常在站点上拥有的虚拟用户的一部分。 他们想用测试流量来补充实时流量，以了解新产品对整个基础架构的总体性能影响。 这需要大量的负载生成功能，而这正是云计算发挥作用的地方。 为了进行此测试，MySpace 与 SOASTA 一起使用了云作为负载生成平台。 -马特是一个有思想的人，这是有根据的。 在[最近的一次采访](https://www.infoq.com/articles/podcast-matt-ranney)中，他说： +以下是测试过程中生成的负载的详细信息。 所有数字均与虚拟用户的测试流量有关，不包括实时用户的指标： -> 在 QCon 和其他活动上进行的许多架构讨论使我感到不足够。 和其他人（例如 Google）一样，一切都明白了，但我却没有。 +* 100 万个并发虚拟用户 +* 测试用例分为搜索和观看音乐视频，对视频进行评级，将视频添加到收藏夹以及查看艺术家的频道页面。 +* 每秒 16 吉比特的传输速率 +* 每小时传输 6 TB 的数据 +* 每秒点击次数超过 77,000，不包括实时流量 +* 800 个用于生成负载的 Amazon EC2 大型实例（3200 个云计算核心） -马特（Matt）这次演讲是在大漩涡之外走了一下，试图使自己的经历有意义，并试图弄清一切。 他成功了。 疯狂地。 +**测试环境体系结构** -这部分是智慧的谈话，部分是悔。 马特说：“一路上犯了很多错误，而这些正是从中汲取教训的。 +SOASTA CloudTest™管理对云提供商（在本例中为 Amazon）的调出，并配置服务器以进行测试。 捕获 800 个 EC2 实例的过程用了不到 20 分钟的时间。 我们对 Amazon EC2 API 进行了调用，并以 25 个为一组请求服务器。在这种情况下，团队正在请求具有以下规范的 EC2 Large 实例充当负载生成器和结果收集器： -演讲的脚手架挂在 WIWIK（我希望我知道的）设备上，该设备已成为互联网的模因。 这是他建议给自己幼稚的一年半的幼稚自我的建议，尽管当然，像我们所有人一样，他当然不会听。 +* 7.5 GB 内存 +* 4 个 EC2 计算单元（2 个虚拟 CPU 内核，每个虚拟 CPU 内核具有 2 个 EC2 计算单元） +* 850 GB 实例存储（2×420 GB 加上 10 GB 根分区） +* 64 位平台 +* Fedora Core 8 +* 另外，有 2 个 EC2 Extra-Large 实例充当测试控制器实例和结果数据库，其规格如下： +* 15 GB 内存 +* 8 个 EC2 计算单元（4 个虚拟内核，每个虚拟内核具有 2 个 EC2 计算单元） +* 1,690 GB 实例存储（4×420 GB 加上 10 GB 根分区） +* 64 位平台 +* Fedora Core 8 +* PostgreSQL 数据库 -而且他不会孤单。 很多人批评 Uber（ [HackerNews](https://news.ycombinator.com/item?id=12597232) ， [Reddit](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) ）。 毕竟，这些数字实在是太疯狂了。 两千名工程师？ 八千个存储库？ 一千个服务？ 一定是很严重的错误，不是吗？ +一旦拥有测试所需的所有服务器，便开始对它们进行运行状况检查，以确保它们响应并稳定。 当发现死服务器时，它将丢弃它们，并请求其他服务器来填补空白。 设置基础结构相对容易。 下图（图 1）显示了如何在 EC2 上设置测试云以将大量负载推入 MySpace 的数据中心。 -也许。 令人惊讶的是，马特对整个事情没有判断力。 他的询问方式更多是质疑和搜索，而不是寻找绝对值。 他本人似乎对存储库的数量感到困惑，但是他给出了更多存储库与更少存储库的优缺点，而没有说哪个更好，因为考虑到 Uber 的情况：您如何定义更好？ +![](img/fe16afcae89633adcf761fa1288f9780.png) -优步正在全球范围内展开激烈的战斗，以构建一个能够占领赢家通吃的市场的行星尺度系统。 那就是商业模式。 成为最后一个服务站。 在这种情况下，更好的意思是什么？ +**图 1\.** -赢家通吃意味着您必须快速成长。 您可能会变慢并显得更有条理，但如果变慢，就会迷失方向。 因此，您可以在混乱的边缘保持平衡，并将脚趾或整个身体浸入混乱中，因为这将成为您扩展成为全球主导服务的方式。 这不是一条缓慢的增长之路。 这敲门，采取一切策略。 认为您可以做得更好？ 真？ +测试运行时，成批的负载生成器将其性能测试指标报告回单个分析服务。 每个分析服务都连接 -微服务非常适合 Uber 想要实现的目标。 塞住你的耳朵，但这是康威定律的事情，你会获得如此多的服务，因为这是那么多人被雇用并提高生产力的唯一途径。 +到 PostgreSQL 数据库，以将性能数据存储在聚合存储库中。 这是这种规模的测试可以扩展以生成和存储大量数据的方式的一部分-通过将对数据库的访问限制为仅度量指标聚合器并水平扩展。 -如此多的服务没有技术原因。 没有这么多存储库的技术原因。 这一切都是关于人的。 [老婆婆](https://news.ycombinator.com/item?id=12598893)很好地总结了一下： +**挑战** -> 扩展流量不是问题。 扩大团队规模和产品功能发布率是主要因素。 +由于规模往往会破坏一切，因此在整个测试过程中会遇到许多挑战。 -演讲的一个一致主题是*不错，但存在一些权衡取舍，通常是令人惊讶的权衡，您实际上只是在规模上才能体验到*。 这引出了我从演讲中获得的两个最大想法： +**该测试仅限于使用 800 个 EC2 实例** -* **微服务是一种用 API 协调**代替人类交流的方式。 与人们谈论和处理团队政治相比，团队更容易编写新代码。 它使我想起了我很久以前读过的一本书，不记得这个名字了，人们居住在戴森球体内部，并且因为球体内部有太多空间和如此多的自由能，以至于当任何一个团体与另一个团体发生冲突时 他们可能会分裂并适应新的领域。 这是否更好？ 我不知道，但这确实可以并行完成许多工作，同时又避免了很多人的开销。 -* **纯胡萝卜，不粘**。 关于命令和控制的作用如此广泛，这是一个很深的观点。 您会很想执行政策。 *例如，您应该以这种方式记录*。 如果您不这样做，将会有后果。 那是棍子。 马特说不要那样做。 改用胡萝卜。 每当棍棒冒出来都是不好的。 因此没有任何授权。 您想要处理它的方式是提供非常明显且易于使用的工具，以至于人们不会以其他任何方式使用它。 +SOASTA 是云计算资源的最大消费者之一，通常在多个云提供商之间一次使用数百台服务器来进行这些大规模负载测试。 在测试时，团队要求提供的 EC2 实例数量上限。 可用硬件的限制意味着每个服务器都需要模拟相对大量的用户。 每个负载生成器模拟了 1,300 至 1,500 个用户。 此负载水平约为典型 CloudTest™负载生成器将驱动的负载的 3 倍，这给产品带来了新的压力，工程团队需要一些创造性的工作来解决。 用于减轻负载生成器压力的一些策略包括： -这是您必须真正了解的那些谈话之一，因为除了文本以外，还有很多其他方面的交流。 虽然当然我仍然鼓励您阅读我的演讲掩饰:-) +* 错开了每个虚拟用户的请求，以免每个负载生成器的点击都一次触发 +* 缩减收集的数据，仅包括性能分析所需的内容 -## 统计信息（2016 年 4 月） +## **MySpace 资产的很大一部分由 Akamai 提供，并且该测试反复使 Akamai 基础架构** 的部分服务能力最大化。 -* 优步遍布全球 400 个城市。 +CDN 通常会根据访问者的地理位置从最接近访问者的位置向他们提供内容。 例如，如果您从亚马逊的东海岸可用区生成所有测试流量，那么您很可能只会遇到一个 Akamai 服务点。 -* 70 个国家。 +在负载下，该测试正在向少量 Akamai 数据中心生成大量数据传输和连接流量。 这意味着这些数据中心的负载将超过典型高峰期间可能产生的负载，但是鉴于此功能启动仅针对新西兰流量，因此这不一定是不现实的。 这种压力导致新连接在某些负载水平下被 Akamai 破坏或拒绝，并在测试中产生许多错误。 -* 6000 多名员工 +这是在生产现场产生负载时需要克服的常见障碍。 需要设计大规模生产测试，以考虑到这一点并准确地对整个生产生态系统施加压力。 这意味着从多个地理位置生成负载，以便将流量分散到多个数据中心。 最终，了解地理 POPs 的能力是该测试的重要收获。 -* 2000 名工程师（一年半前有 200 名工程师） +## **由于额外负载的影响，MySpace 必须即时调整其某些服务器的位置，以支持正在测试的功能** -* 1000 个服务（数量近似） +在测试过程中，额外的虚拟用户流量使 MySpace 基础架构中的一些负担沉重。 MySpace 的运营团队能够在几分钟内从其他功能集群中获取未充分利用的服务器，并使用它们为视频站点集群增加容量。 - * 不同服务的数量变化如此之快，以至于很难准确计算生产中的实际服务数量。 许多团队正在建立很多东西。 甚至都不在乎实际的数字。 +也许最令人惊奇的是 MySpace 能够做到这一点。 他们能够实时监控整个基础架构的容量，并在需要时灵活地收缩和扩展。 人们一直在谈论弹性可伸缩性，这在实践中是一件很美的事情。 -* 超过 8000 个 git 回购。 +**经验教训** -## 微服务 +1. 对于高流量网站，在生产中进行测试是准确了解容量和性能的唯一方法。 对于大型应用程序基础结构，如果您仅在实验室中进行测试然后尝试进行推断，那么就会出现太多“看不见的墙”。 +2. 弹性可伸缩性正成为应用程序体系结构中越来越重要的部分。 应该构建应用程序，以便可以独立监视和扩展关键业务流程。 能够相对快速地增加容量将成为来年的关键体系结构主题，而大型企业早就知道了这一点。 Facebook，Ebay，Intuit 和许多其他大型网站都宣扬了这种设计原则。 使事物保持松散耦合具有以前宣传过的许多好处，但是容量和性能正在迅速移到该列表的前面。 +3. 实时监控至关重要。 为了对容量或性能问题做出反应，您需要进行实时监控。 此监视应与您的关键业务流程和功能区域相关联，并且需要尽可能实时。 -* 很高兴将您所有的整体分解成更小的东西。 甚至这个名字听起来也很糟糕。 但是微服务有其不利的一面。 - -* 事情最有可能破裂的时间就是您进行更改的时间。 即使是在 Uber 最忙的时候，周末 Uber 在工程师不进行更改的情况下也是最可靠的。 - -* 每当您进行更改时，都有可能破坏它。 永远不要接触微服务是否有意义？ 也许。 - -* 好 - - * 值得质疑，为什么我们要在微服务上投入如此多的精力？ 这不是偶然的，有很多好的结果。 - - * 微服务允许团队快速组建并独立运行。 人们一直在被添加。 团队需要迅速组建起来，并在可以推断边界的地方开展工作。 - - * 拥有自己的正常运行时间。 您运行您编写的代码。 所有服务团队都在征求他们在生产中运行的服务。 - - * 使用最佳工具进行作业。 但是最好的方式是什么？ 最好写？ 最好跑？ 最好，因为我知道吗？ 最好，因为有图书馆？ 当您深入研究时，最好并不意味着什么。 - -* 明显的成本 - - * 运行大型微服务部署的成本是多少？ - - * 现在，您正在运行分布式系统，这比使用整体系统更难。 - - * 一切都是 RPC。 您必须处理所有这些疯狂的失败模式。 - - * 如果中断怎么办？ 您如何排除故障？ 您如何确定中断在服务链中的何处发生？ 如何确保合适的人得到传呼？ 采取了正确的纠正措施来解决问题？ - - * 这些仍然是显而易见的成本。 - -* 不太明显的费用 - - * 一切都是权衡，即使您没有意识到自己正在做到。 作为所有这些微服务的交换，您可以获得某些东西，但是您也放弃了一些东西。 - - * 通过对所有事物进行超级模块化，我们引入了一些细微而又不明显的问题。 - - * 您可能选择构建新服务，而不是修复已损坏的内容。 在某些时候，始终围绕问题解决和清理旧问题的成本已成为一个因素。 - - * **您发现自己为政治**交易很复杂。 您不必编写笨拙的对话，而充满人类的情感，而是可以编写更多的软件而避免说话。 - - * **您可以保持自己的偏见**。 如果您喜欢 Python 以及与您喜欢的节点打交道的团队，则可以使用自己喜欢的语言来构建新的东西，而不必使用其他代码库。 即使对于组织或整个系统而言，这可能并不是最好的事情，但您仍要继续做自己认为最好的事情。 - -## 拥有多种语言的成本 - -* 史前史：最初，Uber 被 100％外包。 看来这似乎不是技术问题，所以一些公司编写了移动应用程序的第一个版本和后端。 - -* 调度：内部开发时，它是用 Node.js 编写的，现在正在迁移到 Go。 - -* 核心服务：系统的其余部分，最初是用 Python 编写的，现在正在迁移到 Go。 - -* Maps 最终被引入内部，这些团队正在使用 Python 和 Java。 - -* 数据工程团队使用 Python 和 Java 编写代码。 - -* 内部度量系统用 Go 编写。 - -* 您开始注意到有很多语言。 微服务使您可以使用多种语言。 - -* 团队可以用不同的语言编写并且仍然可以相互交流。 它可以工作，但需要付费： - - * 难以共享代码。 - - * 难以在团队之间移动。 在一个平台上积累的知识不会转移到另一平台上。 任何人当然都能学到，但是要付出一定的代价。 - -* **我希望知道的内容**：拥有多种语言会破坏文化。 通过在任何地方都接受微服务，您最终可以扎营。 这里有一个节点营，一个 Go 营，等等。人们围绕部落组织起来是很自然的事，但是要接受到处都有多种语言的策略是有代价的。 - -## RPC 的成本 - -* 团队使用 RPC 相互通信。 - -* 大量的人很快就真正加入了 HTTP 的弱点。 像什么状态代码？ 标头是做什么用的？ 查询字符串中包含什么？ 这是 RESTful 吗？ 这是什么方法 - -* 所有这些事情在执行浏览器编程时看上去确实很酷，但是在进行服务器编程时却变得非常复杂。 - -* 您真正想说的是在那里运行此功能，并告诉我发生了什么。 相反，使用 HTTP / REST 会遇到所有这些细微的解释问题，这一切都非常昂贵。 - -* JSON 很棒，您可以用眼球看一下并阅读它，但是如果没有类型，这是一个疯狂的混乱，但不是马上，问题随后就会出现。 当某人更改某些内容并在下游跳了几步时，他们依赖于对空字符串与 null 的某种微妙解释，或者某种语言对另一种语言的某种类型的强制转换，这会导致巨大的混乱，需要花费很长的时间才能解决。 接口上的类型将解决所有这些问题。 - -* RPC 比过程调用慢。 - -* **我希望知道的内容**：服务器不是浏览器。 - - * 当在数据中心中进行交谈时，将所有内容都视为函数调用而不是 Web 请求，这更加有意义。 当您控制对话的双方时，您并不需要所有多余的浏览器内容。 - -## 储存库 - -* 最好的回购数量是多少？ 他认为最好的是一个，但许多人不同意。 - -* 许多人认为很多回购是最好的。 每个项目可能一个，甚至每个项目多个。 - -* 具有许多存储库是遵循具有许多小型模块的行业趋势。 小型模块易于开源或交换。 - -* 一个仓库很不错，因为您可以进行跨领域更改。 您想要进行更改，可以轻松找到所有需要更改的代码。 浏览代码也很容易。 - -* 有很多不好的地方，因为这会给您的构建系统带来压力。 这会损害您浏览代码的能力。 确保正确完成跨领域更改很痛苦。 - -* 一个不好的原因是，它将变得如此之大，除非您拥有一些疯狂的精心设计的系统，否则您将无法构建或检验您的软件。 如果没有特殊工具，一个仓库可能无法使用。 Google 有一个存储库，但它使用虚拟文件系统，好像您已检出整个存储库。 - -* 超过 8000 个 git 回购。 一个月前有 7000。 - - * 有些人有自己的仓库。 - - * 一些团队使用单独的存储库与服务本身分开跟踪服务配置。 - - * 但是大多数是生产仓库。 - -* 很多回购。 - -## 操作问题 - -* 事情破裂了怎么办？ 大型微服务部署会带来一些令人惊讶的问题。 - -* 如果其他团队无法使用您的服务，而该服务尚未准备好发布，那么其他团队是否可以在您的服务中添加修复程序并将其发布？ - - * 即使您的所有测试都通过了，您拥有的正常运行时间是否也与其他发布您服务的团队兼容？ 自动化是否足够好，团队可以相互发布软件？ - - * 在 Uber，这取决于情况。 有时是的，但通常答案是“否”，团队将只需要阻止此修复程序。 - -* 大而小的团队，每个人都在快速前进，所有功能都超级快地发布，但是有时您必须将整个系统理解为一台大型机器连接在一起的一件事。 当您花费所有时间将其分解为微服务时，这很难。 - - * 这是一个棘手的问题。 希望将更多的时间花在保持上下文关联上。 - - * 应该仍然能够理解整个系统的整体功能。 - -## 性能问题 - -* 鉴于微服务彼此之间的依赖程度，性能肯定会提高。 - -* RPC 昂贵，尤其是当存在多种语言时，如何理解性能的答案完全取决于语言工具，并且工具都是不同的。 - -* 您已经让每个人都使用自己的语言进行编程，现在了解这些语言的性能是一个真正的挑战。 - -* 尝试使用 [火焰图](http://www.brendangregg.com/flamegraphs.html) 使所有语言具有通用的分析格式。 - -* 当您想了解系统的性能时，在试图解决性能问题时，一个很大的摩擦就是工具的差异。 - -* 每个人都想要一个仪表盘，但是如果没有自动生成仪表盘，团队将只把他们认为重要的东西放在仪表盘上，因此当您要追查一个团队的仪表盘时，问题看上去将与另一个团队完全不同。 - -* 每个服务在创建时都应该具有一个标准的仪表板，其中包含相同的有用数据集。 应该能够创建一个完全没有工作的仪表板。 然后，您可以浏览其他团队的服务，并且看起来都一样。 - -* **我希望知道的内容**：不需要良好的表现，但您需要知道自己的立场。 - - * 一个大争论是，您是否应该关心性能。 “过早的优化是万恶之源”的类型思维催生了反对优化的人们非常奇怪的亚文化。 没关系，服务并不那么忙。 我们应该始终针对显影剂速度进行优化。 购买计算机比雇用工程师便宜。 - - * 对此有一定道理。 工程师非常昂贵。 - - * 问题在于，性能要紧要紧。 有一天，您将遇到绩效问题，如果已经建立起一种无关紧要的文化，那么突然之间变得至关重要很困难。 - - * 您希望根据创建的所有内容获得某种性能的 SLA，以便有一个数字。 - -## 扇出问题-跟踪 - -* 扇出会导致很多性能问题。 - -* 想象一个典型的服务，即 99％的时间在 1 毫秒内做出响应。 它在一秒钟内响应的时间为 1％。 还算不错。 用户有 1％的时间会遇到这种情况。 - -* 现在，我们假设服务开始大张旗鼓，开始调用许多其他服务。 响应时间变慢的机会迅速增加。 至少在 1 秒钟内使用 100 个服务和 63％的响应时间（1.0-.99 ^ 100 = 63.4％）。 - -* 分发跟踪是您跟踪扇出问题的方式。 如果无法理解整个体系结构中的请求，将很难跟踪扇出问题。 - - * Uber 正在使用 [OpenTracing](https://github.com/opentracing) 和 [Zipkin](https://github.com/openzipkin/zipkin) 。 - - * 另一种方法是使用日志。 每个日志条目都有一个公共 ID，该 ID 将所有服务组合在一起。 - -* 给出了一个棘手的例子。 顶层对所有相同服务均具有大量扇出。 当您查看服务时，它看起来不错。 每个请求都是快速且一致的。 问题是顶级服务获得了 ID 列表，并正在为每个 ID 调用服务。 即使同时进行，也将花费太长时间。 只需使用批处理命令即可。 如果不进行跟踪，很难找到这个问题。 - -* 另一个示例是进行了数千次服务调用的服务。 尽管每个呼叫都很快，但大量呼叫却使服务变慢。 事实证明，遍历列表并更改属性后，它神奇地变成了数据库请求。 但是数据库团队说，由于每个操作都很快，所以数据库运行良好，但是他们会想知道为什么会有这么多操作。 - -* 跟踪的开销可以更改结果。 跟踪是很多工作。 一种选择是不跟踪所有请求。 跟踪请求的统计显着部分。 Uber 跟踪约 1％的请求。 - -* **我希望知道的内容**：跟踪需要跨语言的上下文传播。 - - * 因为所有这些不同的语言都用于所有这些不同的框架，所以获取请求的上下文（例如请求的用户）是经过身份验证的，是在什么地理围栏内，如果没有放置位置，这将变得非常复杂 将会传播的上下文。 - - * 服务提出的任何依赖请求都必须传播上下文，即使他们可能不理解上下文也是如此。 如果很久以前添加此功能，它将节省大量时间。 - -## 正在记录 - -* 拥有一堆不同的语言，一群团队和许多新人，一半的工程团队已经存在了不到 6 个月，每个人可能都倾向于以完全不同的方式登录。 - -* 任务授权是一个棘手的词，但这就是您真正想要做的事情，它要求一种通用的日志记录方法。 更为可接受的说法是，它提供了如此显而易见且易于使用的工具，人们不会以任何其他方式来获得一致且结构化的日志记录。 - -* 多种语言使得难以记录。 - -* 如果存在问题，日志记录本身可能会使日志记录过多而使这些问题更加严重。 日志中需要背压以在过载时删除日志条目。 希望早些时候已放入系统中。 - -* **我希望知道的内容**：关于日志消息大小的一些概念，以便可以跟踪谁在生成过多的日志数据。 - - * 所有日志发生的事情是它们被某种工具索引，以便人们可以搜索它们并学习事物。 - - * 如果免费记录，则记录的数据量是可变的。 有些人会记录很多数据，使系统不堪重负。 - - * 对于计费系统，当将日志数据发送到群集以建立索引时，可以将帐单发送到服务以进行支付。 - - * 的想法是给开​​发人员以更大的压力，使他们更聪明地记录日志，而不是更难。 - - * Uber 创建了 [uber-go / zap](https://github.com/uber-go/zap) 用于结构化日志记录。 - -## 负载测试 +## 相关文章 -* 想要在将服务投入生产之前进行负载测试，但是无法构建与生产环境一样大的测试环境。 +* [MySpace 体系结构](/blog/2009/2/12/myspace-architecture.html) +* [如何在不进行实际尝试的情况下成功完成容量规划：Flickr 的 John Allspaw 专访他的新书](/blog/2009/6/29/how-to-succeed-at-capacity-planning-without-really-trying-an.html) -* 这也是生成实际测试数据以测试系统所有部分的问题。 +另一篇令人失望的简短文章：/ +这篇文章对于学习和观察真实的云一样有用。 +这本来真是令人赞叹的文章，但事实证明，更多的是 soasta 广告：( -* 解决方案：在非高峰时段对生产进行测试。 +嗯 我也希望有更多细节。 里面没有什么新东西，只是一则广告。 -* 引起很多问题。 +您想要保罗什么细节？ -* 它炸毁所有指标。 +我想知道这项测试的亚马逊账单是多少？ - * 您不希望人们认为负载多于实际负载。 为了解决该问题，它又回到了上下文传播问题。 +虽然可能有点像广告，但我不认为这太过分了。 SOASTA 仅被特别提及了三遍，考虑到它们都执行了测试并撰写了有关测试的文章，这似乎是合理的。 - * 确保所有测试流量请求都具有表示此测试请求的上下文，因此请以不同的方式处理指标。 这必须贯穿整个系统。 +总体而言，我认为这是一篇相当不错的文章，并为我提供了许多以前所没有的见识。 也许是因为我没有参与需要进行云部署测试的大型站点。 如果是的话，我可能会有所不同。 -* **我希望知道的内容**：我们真正想要做的是始终在所有服务中运行负载，因为许多错误仅在流量达到峰值时才会出现。 +根据读者的不同，一篇文章几乎总是细节太少或太多，我认为这篇文章取得了很好的平衡。 - * 希望将系统保持在峰值附近，并随着实际流量的增加而退缩。 +感谢您的撰写。 - * 希望该系统很早以前就已建立，可以处理测试流量并以不同的方式处理它。 +这听起来像是广告，它实际上是一项糟糕的服务。 +强调 Akamai 在美国的基础设施将如何帮助应对来自新西兰的流量猛增？ 这些新西兰人最终将身处 Akamai 的新西兰基础设施中。 -## 故障测试 +另外，如果要在 MySpace 上对后端进行负载测试，而不是 Akamai 提供内容，则根本不需要测试 Akamai 部分。 只需在 MySpace 网络中内部运行测试即可。 -* **我希望知道的内容**：并非每个人都喜欢混沌猴子那样的失败测试，​​尤其是如果您稍后要添加它时。 +最后，哪种产品需要 16 GB 的 RAM 才能同时下载一些 http 请求？ 你在开玩笑吧。 Java 用什么写的？ - * 如果您不喜欢，我们应该做的是对您进行故障测试。 这只是生产的一部分。 您的服务仅需承受随机的杀戮，操作的减慢和干扰。 +这篇文章让人印象深刻。 鉴于单核奔腾 M 笔记本电脑可以轻松使千兆位以太网连接（尤其是传入）饱和，因此没有理由使用 16 台以上的服务器。 从亚马逊那里购买它们特别愚蠢，因为与新西兰的 DSL 客户相比，它们往往连接良好。 如果启动该服务确实产生了如此大的影响，那么您将受到新西兰微薄的互联网连接的自然限制，并且必须与所有其他新西兰人共享。 -## 迁移 +关于先前的投诉，我认为您至少让读者停滞了一点： -* 我们所有的东西都是遗产。 全部都是迁移。 通常，从事存储工作的人们正在做的事情就是从一个旧版迁移到另一个旧版。 +（1）对于仅命中一个 Akamai 数据中心的问题有什么解决方案？ 您是否能够克服该瓶颈并测试其他潜在瓶颈？ -* 有人总是在某处迁移某物。 不管人们在会议上怎么说，这就是每个人都在做的事情。 +我也想知道： -* 旧的东西必须保持工作状态。 业务仍然必须运行。 不再有维护窗口之类的东西。 可接受的停机时间。 +（2）是否遇到任何挑战 -* 随着您成为一家全球企业，没有高峰时间。 总是高峰时间在某个地方。 +-传输速率为每秒 16 吉比特 +-每小时传输 6 TB 数据 -* **我希望知道的内容**：迁移的要求很糟糕。 +进入 Amazon AWS？ 还是仅仅是产生足够多的实例来获得这种传输速率？ - * 没有人希望被告知必须采用某种新系统。 +您能否说明一下为什么选择 PostgreSQL 来存储日志数据？ - * 使某人发生变化是因为组织需要进行变化，而不是提供一个更好的新系统，因此显然您需要接受这一新事物。 +我很确定某些键值存储系统会比常规 SQL 系统更快地占用资源，同时存储日志数据。 - * 纯胡萝卜，不粘。 无论何时出现问题，除非与安全性或合规性有关，否则这是不好的，强迫人们做事可能是可以的。 +尽管它没有描述所有细节，但了解/听到使用 EC2 进行这种负载测试的方法仍然非常有趣。 -## 开源 +谢谢 -* 没有人同意建立/购买权衡。 你什么时候建造？ 你什么时候应该买？ +费利克斯（Felix），即使您的行为像孩子一样在 YouTube 上匿名发动，我还是决定，我会尽力为您解答问题。 他们来了： -* 属于基础架构的任何东西，看起来像是平台的一部分而不是产品的一部分的任何东西，在某个时候都将成为无差别的商品。 亚马逊（或某人）将提供它作为服务。 +>强调 Akamai 在美国的基础设施将如何帮助应对来自新西兰的流量猛增？ 这些新西兰人最终将身处 Akamai 的新西兰基础设施中。 -* 最终，您花了所有时间在做这件事，其他人会以更便宜和更好的方式来做。 +来自 Akamai 的内容只是正在测试的整个基础架构的一部分。 这是在测试设计期间提出的，并被团队接受，因为： -* **我希望知道的内容**：如果人们正在使用某种平台类型的功能，那么听到亚马逊刚刚发布您的服务即服务听起来并不好。 +1）没有其他选择-尚无主要的云播放器在新西兰（但是）拥有与某些较大的播放器一样强大的 API，并且具有一定数量的服务器 +2）大多数 Akamai 的存在都相对 在性能方面具有可重复性，因此，由于我们主要测试的不是 Akamai，因此我们假定来自新西兰其他数据中心的性能也与众不同，因为每个人都愿意接受这种风险。 - * 您仍在尝试合理化为什么应将自己的私人物品用作服务。 +有了 SLA，并且对数据中心进行的压力测试比预期的要高得多，这在逻辑上是可以接受的风险。 - * 事实证明，那些人在这些文本编辑器的另一端。 人们对构建/购买权衡的判断方式存在巨大差异。 +> +>如果要在 MySpace 上对后端进行负载测试，而不是 Akamai 提供的内容，则根本不需要测试 Akamai 部分。 只需在 MySpace 网络中内部运行测试即可。 -## 政治 +如果您希望基础架构的所有部分都能承受预计的负载的 100％的信心，则每个组件都需要进行测试。 我们经常根据客户的要求测试 CDN。 在这种情况下，没有人想到 CDN 会遇到麻烦，但我们遇到了很多麻烦。 即使我们可能一直在强调一种持久性有机污染物，其强度比预期的要高，但我们观察到一个以前没有人知道的能力点。 -* 通过将所有内容分解为小型服务，可以使人们玩政治。 +要记住的一件事是，它不仅仅是从容量角度测试 Akamai。 当本应由 Akamai 提供服务但没有提供服务时，会发生不好的事情，最终回到原始服务器并破坏 MySpace 基础结构。 团队需要首先确保内容全部来自 Akamai。 其次，我们需要确保在 Akamai 缓存刷新等过程中没有负载传递到 MySpace。 -* 每当您做出违反此属性的决定时，就会发生政治事件：公司>团队>自我。 +同样，在内部运行测试不能像在防火墙外部进行测试那样准确地提供性能信息。 - * 您将自己的价值观置于团队之上。 +> +>哪种产品需要 16 gigs RAM 才能同时下载一些 http 请求？ 你在开玩笑吧。 Java 用什么写的？ - * 团队的价值高于公司。 +不值得花时间回答这个问题。 如果听起来读者理解这里发生的一切，就很乐意做出回应；） -* 政治不只是您不喜欢的决定。 +> +>本文颇为令人印象深刻。 鉴于单核奔腾 M 笔记本电脑可以轻松使千兆位以太网连接（尤其是传入）饱和，因此没有理由使用 16 台以上的服务器。 从亚马逊那里购买它们特别愚蠢，因为与新西兰的 DSL 客户相比，它们往往连接良好。 如果启动该服务确实产生了如此大的影响，那么您将受到新西兰微薄的互联网连接的自然限制，并且必须与所有其他新西兰人共享。 -* 通过拥抱高度模块化的快速发展，非常快地雇用人员并尽快发布功能，人们开始倾向于违反此属性。 +在线应用程序的性能测试远不止于饱和。 在下载或流式传输内容时，实际上保持打开状态的打开线程和套接字是您逐个服务器消耗所有容量的地方。 下载内容需要时间，并且在下载或流式传输内容时，您失去了生成负载的能力。 - * 当您重视以较小的个人成就来交付产品时，很难确定对公司有利的优先事项。 令人惊讶的权衡。 +除此之外，对于性能测试，您还不会发出请求以生成负载并将其释放。 您正在记录有关每个用户的大量性能数据。 每次命中所花费的时间，传输的带宽，错误以及类似性质的事情。 -## 权衡取舍 +在 DSL 点上，带宽限制很少在性能测试中完成，因为如果最终用户连接不受应用程序公司的控制，则不会进行限制。 -* 一切都是权衡。 +> +>（1）仅命中一个 Akamai 数据中心的问题的解决方案是什么？ 您是否能够克服该瓶颈并测试其他潜在瓶颈？ +> -* **我希望知道的内容**：如何更好地有意进行这些折衷。 +我们接受了这样的风险，即我们实际上要测试一个 Akamai 的存在点，其强度要高于此次发布的程度。 但是，识别瓶颈是一项关键的学习，并且随着流量的增长，运营团队和他们的头脑现在已经知道了解其阈值，这可能是需要逐步解决的问题。 - * 当事情在没有明确决定的情况下发生时，因为这似乎是事情的发展方向，即使没有明确做出决定，也要考虑做出什么权衡。 +>我也想知道： +> +>（2）在获得 +> +>方面是否存在任何挑战-每 16 吉比特的传输速率 第二 +>-每小时传输 6 TB 的数据 +> +>到 Amazon AWS？ 还是仅仅是产生足够多的实例来获得这种传输速率？ +> -## 相关文章 +我很想告诉您是否有，但完全没有挑战。 只是产生 EC2 实例就给我们带来了其他一切，包括看似开放的数据传输管道和磁盘访问，以及 I / O 都可以正常工作。 实际上，在与亚马逊合作进行了 3 年这些测试之后，我们从未遇到任何带宽或 I / O 问题。 -* [关于 HackerNews](https://news.ycombinator.com/item?id=12697006) +我喜欢这篇文章，感谢您撰写。 -* 关于在 HackerNews 和 [上的视频](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) [的精彩讨论，关于[Reddit]](https://news.ycombinator.com/item?id=12597232) +托德（Todd）-如果您要花时间反驳某项陈述，最好花点时间进行拼写检查以提高信誉 -* [扩展流量高的 Feed 的设计决策](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html) +除了 MySpace 本身之外，其他各方（Akamai 和/或沿途的其他运营商）是否也了解这种“受控 DoS”？ 是否不增加容量来处理流量的突然增加，但至少要知道这是请求的合法流量，而不是某些 DoS 攻击？ -* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) +您可以从 Amazon 获得如此多的实例和资源，这没有问题，因为 Amazon 知道您是谁以及这是一家什么样的公司，因此他们消除了对您帐户的任何限制？ 还是亚马逊真的有这么多的产能供任何支付者使用？ -* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) +该测试花了多长时间？ 您准备了多长时间了？ +您是否想念一些后来才意识到有用的数据？ +您是在看到 MySpace 正在处理负载还是在从头到尾从 0 到 1 磨时增加点击量吗？ -* [Uber 变得与众不同：使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) +对于我的一项工作，我们进行了类似的测试； 一切顺利，直到我们开始生产为止。 即将发布的消息是，我们的某些后端日志记录和报告系统正在执行 DNS 反向查找。 由于我们的测试来自有限的 IP 空间，因此查找并不是全部可见-但是由于数千名用户使用不同的 IP 位置，我们发现这造成了巨大的瓶颈。 值得牢记。 -* [Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理百万个写入](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) +哇，我无法想象必须处理所有的流量以及在“开放”期间可能出现的任何问题。 我已经处理了高流量的网站，但没有像 Myspace 这样的网站。 -* [与 Matt Ranney 缩放 Uber](http://softwareengineeringdaily.com/2015/12/04/engineering-at-uber-with-matt-ranney/) +我从事表演业务，并使用云模拟了 40,000 个虚拟用户。 这篇文章强调了我面临的一些问题-大型数据集，将负载分散到可用区域等。还有一个我还没有解决的问题，那就是 jmeter 无法像浏览器一样进行并行下载。 当下载页面命中的所有资源时，这反映在较大的事务响应时间中。 在澳大利亚和美国西部之间的每次请求中，RTT 为 250 毫秒也会使情况变得更糟。 到目前为止，我不得不在报告中说明这一点，尽管结果表明事务 x 花费了 12 到 15 秒之间的时间，但这实际上相当于 0.5 到 3.5 秒的响应时间，并且总吞吐量并不是瓶颈。 -* [InfoQ 播客：Uber 的首席系统架构师，介绍其架构和快速发展](https://www.infoq.com/articles/podcast-matt-ranney) +SOASTA 加载工具是否可以执行并行下载，您是否考虑了 250 毫秒的 RTT？ -* [分布式 Web 架构：Matt Ranney，Voxer](https://gaming.youtube.com/watch?v=pXT0mF9bMyA) +另一件事-如果同时有 100 万新西兰人同时使用 Myspace，那么那里的街道将空无一人。 -* [Riak at Voxer-Matt Ranney，RICON2012](https://vimeo.com/52827773) +哦，还有一件事。 当然，您可以从一台笔记本电脑运行 1,000 个用户。 您不会达到 1GB /秒的速度。 您的响应时间度量将反映测试硬件（而不是被测系统）中的延迟。 关键在于您的负载生成器是否可以及时处理网卡生成的中断。 -优步遍布 400 多个城市。 因此，请在帖子中更正此问题。 +SeaPerf，为什么您不阅读他的讲话而不是寻找拼写错误？ 获得生活。 没有人需要互联网上的另一位抱怨拼写的笨蛋。 -谢谢 +你好 -这是我一生中读过的最好的经验教训文章之一。 这是一项毫不废话，诚实和实践的知识共享活动。 许多公司正在努力适应不断变化的新技术，例如带有 Docker 的微服务，CI / CD，Paas，Saas 和 Cass。 正如他在视频中正确指出的那样，这始终是一种思维定势/文化的挑战，每个人对编程语言，方法等都有自己的看法。认识到这一事实并引导每个人实现业务需求的共同目标很重要。 +感谢您的文章，这很有趣。 我正在研究这个主题，并且有一些问题。 也许你可以帮忙。 -难以置信！ 从头到尾纯粹基于经验的演讲 +您如何定义我们需要强调的计算机数量。 +例如，如果我在瓶颈所在的位置使用 apache bench，那么我可以同时运行 1000 个用户吗？ +网络，CPU 和 RAM 有一些瓶颈，如何定义它们？ -很棒的文章，有非常有用的信息。 +对于较小的压力测试，您建议使用哪种软件？ （Apache Bench，JMeter，Siege 等），以及如何定义场景？ （使用 Jmeter 代理，处理 apache 访问日志吗？） -完全基于经验非常坦率非常实用。 他吸取的教训是休息的智慧。 \ No newline at end of file +西里尔 \ No newline at end of file diff --git a/docs/44.md b/docs/44.md index c11fea5..262be8f 100644 --- a/docs/44.md +++ b/docs/44.md @@ -1,287 +1,77 @@ -# Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入 +# FarmVille 如何扩展-后续 -> 原文： [http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) +> 原文： [http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html](http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html) -![](img/40038672dfc38e0094e8da51e713355b.png) +![](img/4dfef10759448f17402c25ab64e9e4bb.png) -如果您是 Uber，并且需要存储驾驶员和骑乘者应用程序每 30 秒发送一次的位置数据，该怎么办？ 大量实时数据需要实时使用。 +针对[，FarmVille 如何扩展以每月收获 7500 万玩家的问题](/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html)，一些读者提出了后续问题。 这是卢克对这些问题（以及我的一些问题）的回答。 -Uber 的解决方案是全面的。 他们构建了自己的系统，该系统在 Mesos 之上运行 Cassandra。 Uber 的软件工程师 [Abhishek Verma](https://www.linkedin.com/in/verma7) 在一个很好的演讲中都做了解释： [Cassandra 在多个数据中心的 Mesos 上 Uber](https://www.youtube.com/watch?v=4Ap-1VT2ChU&feature=youtu.be) （ [幻灯片](http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016) ）。 +### 社交网络如何使事情变得容易或困难？ -您也应该这样做吗？ 在听 Abhishek 的演讲时，会想到一个有趣的想法。 +社交游戏的主要有趣方面是，如何获得需要经常访问彼此数据的已连接用户的图表。 这使得整个数据集很难甚至不是很难分区。 -这些天来，开发人员有很多困难的选择。 我们应该全力以赴吗？ 哪一个？ 太贵了吗？ 我们担心锁定吗？ 还是我们应该尝试同时兼顾并打造混合架构？ 还是我们应该自己做所有事情，以免由于未达到 [50％](http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/) 毛利率而被董事会蒙羞？ +### 您尝试避免使用 Facebook 通话的哪些例子，以及它们如何影响游戏玩法？ -Uber 决定建立自己的公司。 或者更确切地说，他们决定将两个功能强大的开源组件融合在一起，从而将自己的系统焊接在一起。 所需要的是一种使 Cassandra 和 Mesos 协同工作的方法，而这正是 Uber 的基础。 +我们可以致电 Facebook 朋友数据，以检索有关您玩游戏的朋友的信息。 通常，我们在游戏底部显示一个朋友梯子，该梯子显示朋友信息，包括姓名和 Facebook 照片。 -对于 Uber 的决定并不那么困难。 他们资金充裕，可以访问创建，维护和更新这类复杂系统所需的顶尖人才和资源。 +### 您能否说说缓存在哪里，缓存采用什么形式，缓存有多少？ 您是否与 Facebook 建立了对等关系，就像您在该带宽上所期望的那样？ -由于 Uber 的目标是使运输在每个地方的每个人都具有 99.99％的可用性，因此在扩展到无限远及更高水平时，希望能够控制您的成本确实很有意义。 +我们使用内存缓存作为我们的缓存技术。 无法评论对等关系。 -但是，当您听演讲时，您会意识到制作此类系统所付出的巨大努力。 这真的是您的普通商店可以做的事情吗？ 不，不是。 如果您是那些希望每个人都在裸露的金属之上构建自己的所有代码的云专家之一，请记住这一点。 +### 禁用功能以响应负载时，对游戏的影响是什么？ -以金钱换时间通常很划算。 通常，以技能交易金钱是绝对必要的。 +用户将看到的是应用程序的某些部分无法正常运行。 我们有效地排序了对游戏而言不太重要的事物，并先将其关闭。 例如，在我们的邻居页面和 Flash 应用程序底部的朋友阶梯中，您可以看到朋友在玩游戏及其游戏统计信息的列表。 在某些情况下，当我们有高负载时，我们会关闭它。 它为我们节省了一些后端工作，并且对用户体验的影响相对较小。 -鉴于 Uber 的可靠性目标，即 10,000 个请求中只有一个可能失败，因此他们需要在多个数据中心中用完。 由于 Cassandra 被证明可以处理巨大的负载并且可以跨数据中心工作，因此作为数据库选择是有道理的。 +### 您如何与 Facebook 集成？ 您是否尝试尽可能远离后端？ 还有与 Facebook 合作的建议？ -如果您想使所有人，任何地方的运输都可靠，则需要有效地利用您的资源。 这就是使用像 Mesos 这样的数据中心操作系统的想法。 通过在同一台计算机上统计复用服务，您需要的计算机数量减少了 30％，从而节省了资金。 之所以选择 Mesos，是因为当时 Mesos 是经证明可与数以万计的计算机集群大小一起工作的唯一产品，这是 Uber 的要求。 优步的工作量很大。 +我们通过 REST API 与 Facebook 集成。 由于我们是 Facebook 上的大型应用程序构建者，因此我们就技术问题进行了大量的来回交流。 -有哪些更有趣的发现？ +### 您的可降解方法非常有趣。 听起来您可以在客户端中玩大部分游戏，而无需长时间与后端对话。 我从农场彼此相对隔离的应用程序的性质出发？ 是否有尝试像其他多人游戏一样将农场聚集在一起？ -* 您可以在容器中运行有状态服务。 Uber 发现在裸机上运行 Cassandra 与在 Mesos 管理的容器中运行 Cassandra 之间几乎没有任何区别，开销为 5-10％。 +是的，拥有交互式客户端的好处之一是我们在服务器延迟和观察到的客户端延迟之间有些隔离。 我们会验证游戏中执行的每个动作； 但是，我们异步执行此操作，并在客户端上将事务排队。 -* 性能良好：平均读取延迟：13 毫秒，写入延迟：25 毫秒，P99 看起来不错。 +### 您使用 MySQL 吗？ 如果使用 SQL，它将如何使用？ -* 对于最大的群集，他们能够支持超过一百万次写入/秒和约 10 万次读取/秒。 +我们使用 MySql。 -* 敏捷性比性能更重要。 通过这种架构，Uber 获得的就是敏捷性。 跨集群创建和运行工作负载非常容易。 +### 您在 LAMP 中使用什么“ P”？ Python 等。 -这是我的演讲要点： +Â我们使用 PHP。 -## 开头 +### 您如何与后端对话？ 是请求响应，XHR，长轮询，Flash XML 套接字还是“ COMET”？ -* 跨不同服务的静态分区计算机。 +我们使用称为 AMF 的标准 HTTP 请求/响应协议。 AMF 事务是从客户端异步发生的，如果服务器看到它认为客户端不应该发送的内容，则会向客户端返回“不同步”消息，告知客户端处于无效状态，并且客户端 重新加载自身。 -* 50 台机器可能专用于 API，50 台机器专用于存储，等等，并且它们没有重叠。 +### 您是否运行 200 个（或其他数量的）节点 Vertica 集群？ -## 即时 +我们不对 FarmVille 执行此操作 -* 希望在 [Mesos](http://mesos.apache.org/) 上运行所有内容，包括诸如 Cassandra 和 Kafka 之类的有状态服务。 +### 您是在云中运行还是拥有专用服务器？ 您使用 EC2 吗？ - * Mesos 是数据中心操作系统，可让您像单一资源池一样针对数据中心进行编程。 +我们确实在云中运行。 这里的主要特征是我们使用商品化的虚拟化硬件。 因此，从我们决定要增加容量到硬件可用的时间，我们大大减少了时间。 - * 当时，事实证明 Mesos 可以在成千上万的计算机上运行，​​这是 Uber 的要求之一，因此这就是为什么他们选择 Mesos。 今天，Kubernetes 可能也可以工作。 +### 请提供服务降级示例吗？ - * Uber 在 MySQL 之上构建了自己的分片数据库，称为 [Schemaless](https://eng.uber.com/schemaless-part-one/) 。 这个想法是 Cassandra 和 Schemaless 将成为 Uber 中的两个数据存储选项。 现有的 Riak 装置将移至 Cassandra。 +FarmVille 内部的一个示例是，页面底部的 Flash 内有一个朋友梯子。 通常，我们向 facebook 查询姓名和个人资料图片，并向我们自己的后端查询游戏统计信息和头像数据。 -* 一台机器可以运行各种服务。 +这是应用程序中参与度很高的部分，但优先级低于进行农业活动的用户。 因此，如果我们的后端出现性能问题，我们可以将其关闭，并且朋友阶梯将仅显示 facebook 名称和个人资料图片。 同样，如果 facebook 出现性能问题，我们可以将其关闭，并且朋友梯子不会显示。 -* 同一台机器上的统计复用服务可能会导致 的机器数量减少 30％ 。 这是 Google 在 Borg 上运行的 [实验](http://research.google.com/pubs/pub43438.html) 的发现。 +结局 -* 例如，如果一项服务使用大量 CPU，并且与使用大量存储或内存的服务非常匹配，那么这两项服务可以有效地在同一服务器上运行。 机器利用率上升。 +我错过了昨天 Amitt Mahajan 在 GDC 上的演讲，我很想知道他说过关于懒惰地写入/发自 Farmfield 的内存缓存池及其网络层请求批处理的内容。 有没有人在谈论这个话题或对此有更多了解？ -* Uber 现在有大约 20 个 Cassandra 集群，并计划在将来有 100 个。 +卢克（Luke）在回答云问题时非常有政治性。 根据 Rightscale 上的这篇文章，Farmville 完全在亚马逊的 EC2 上运行：[前三名社交游戏公司管理云上的急剧增长](http://www.rightscale.com/news_events/press_releases/2010/Top-Three-Social-Gaming-Companies-Manage-Steep-Growth-on-the-Cloud-with-RightScale.php) -* 敏捷性比性能更重要。 您需要能够管理这些集群并以平滑的方式对其执行不同的操作。 +我真的不喜欢采访。 我认为面试官提出了很好的问题，做得很好。 可悲的是，面试官没有付出太多。 -* **为什么在容器中而不是在整个机器上运行 Cassandra？** +哇，那真是令人痛苦的采访。 我同意面试官提出了正确的问题，但是答案是可悲的。 - * 您想存储数百 GB 的数据，但您还希望将其复制到多台计算机上以及跨数据中心。 +“您使用 MySQL 吗？如果您使用 SQL，它将如何使用？” - * 您还希望跨不同群集进行资源隔离和性能隔离。 +“我们使用 MySql。” - * 很难在一个共享群集中获得所有这些。 例如，如果您制作了一个 1000 节点的 Cassandra 群集，它将无法扩展，或者跨不同群集也会产生性能干扰。 +哇，感谢您的惊人见解！！！ -## 量产中 +所有的答案都好像受访者放弃了尽可能少的信息。 -* 在两个数据中心（西海岸和东海岸）中复制约 20 个群集 - -* 最初有 4 个集群，包括中国，但是由于与滴滴合并，这些集群被关闭了。 - -* 跨两个数据中心的 300 台机器 - -* 最大的 2 个集群：每秒超过 100 万次写入和每秒 10 万次读取 - - * 群集之一正在存储驾驶员和骑乘者应用程序每 30 秒发送一次的位置。 - -* 平均读取延迟：13 毫秒，写入延迟：25 毫秒 - -* 通常使用 [LOCAL_QUORUM](https://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html) 一致性级别（表示强一致性） - -## 月背景资料 - -* Mesos 将 CPU，内存和存储从计算机中分离出来。 - -* 您不是在查看单个计算机，而是在查看资源并对其进行编程。 - -* 线性可伸缩性。 可以在数以万计的计算机上运行。 - -* 高度可用。 Zookeeper 用于在可配置数量的副本中进行领导者选举。 - -* 可以启动 Docker 容器或 Mesos 容器。 - -* 可插拔资源隔离。 用于 Linux 的 Cgroups 内存和 CPU 隔离器。 有一个 Posix 隔离器。 不同的操作系统有不同的隔离机制。 - -* 两级调度程序。 来自 Mesos 代理的资源被提供给不同的框架。 框架在这些提议的基础上安排自己的任务。 - -## Apache Cassandra Backgrounder - -* Cassandra 非常适合 Uber 的用例。 - -* 水平可扩展。 随着新节点的添加，读写规模呈线性增长。 - -* 高度可用。 具有可调一致性级别的容错能力。 - -* 低延迟。 在同一数据中心内获得亚毫秒级的延迟。 - -* 操作简单。 这是同质的簇。 没有主人。 集群中没有特殊的节点。 - -* 足够丰富的数据模型。 它具有列，组合键，计数器，二级索引等 - -* 与开源软件的良好集成。 Hadoop，Spark，Hive 都具有与 Cassandra 进行通信的连接器。 - -## 中层+ Uber + Cassandra = dcos-cassandra-service - -* Uber 与 Mesosphere 合作生产了 [mesosphere / dcos-cassandra-service](https://github.com/mesosphere/dcos-cassandra-service) -一种自动化服务，可轻松在 Mesosphere DC /上进行部署和管理 操作系统。 - -![29683333130_0478a29f4f.jpg](img/838bef48b4379bab5211f9b9f159d7c8.png) - -* 顶部是 Web 界面或 Control Plane API。 您指定所需的节点数； 您想要多少个 CPU； 指定 Cassandra 配置； 然后将其提交给 Control Plane API。 - -* 使用 Uber 的部署系统，它在 [Aurora](http://aurora.apache.org/) 之上启动，用于运行无状态服务，用于引导 dcos-cassandra 服务框架。 - -* 在示例 dcos-cassandra-service 框架中有两个与 Mesos 主服务器通信的集群。 Uber 在其系统中使用了五个 Mesos 母版。 Zookeeper 用于领导者选举。 - -* Zookeeper 还用于存储框架元数据：正在运行的任务，Cassandra 配置，集群的运行状况等。 - -* Mesos 代理在群集中的每台计算机上运行。 代理将资源提供给 Mesos 主服务器，主服务器以离散报价分发它们。 报价可以被框架接受或拒绝。 多个 Cassandra 节点可以在同一台计算机上运行。 - -* 使用 Mesos 容器，而不是 Docker。 - - * 覆盖配置中的 5 个端口（storage_port，ssl_storage_port，native_transport_port，rpcs_port，jmx_port），以便可以在同一台计算机上运行多个容器。 - - * 使用永久卷，因此数据存储在沙箱目录外部。 万一 Cassandra 失败，数据仍将保留在持久卷中，并且如果崩溃并重新启动，则将数据提供给同一任务。 - - * 动态预留用于确保资源可用于重新启动失败的任务。 - -* Cassandra 服务操作 - - * Cassandra 有一个 [种子节点](https://www.quora.com/What-is-a-seed-node-in-Apache-Cassandra) 的想法，它为加入集群的新节点引导八卦过程。 创建了自定义 [种子提供程序](https://mesosphere.github.io/cassandra-mesos/docs/configuration-and-state.html) 来启动 Cassandra 节点，该节点允许 Cassandra 节点自动在 Mesos 群集中推出。 - - * 可以使用 REST 请求增加 Cassandra 群集中的节点数。 它将启动其他节点，为其提供种子节点，并引导其他 Cassandra 守护程序。 - - * 可以更改所有 Cassandra 配置参数。 - - * 使用 API​​可以替换死节点。 - - * 需要修复才能跨副本同步数据。 维修在每个节点的主键范围内进行。 这种方法不会影响性能。 - - * 清除将删除不需要的数据。 如果已添加节点，则数据将被移动到新节点，因此需要清除以删除移动的数据。 - - * 可以通过框架配置多数据中心复制。 - -* 多数据中心支持 - - * 在每个数据中心中独立安装 Mesos。 - - * 在每个数据中心中设置框架的独立实例。 - - * 框架互相交谈并定期交换种子。 - - * 这就是 Cassandra 所需要的。 通过引导其他数据中心的种子，节点可以八卦拓扑并找出节点是什么。 - - * 数据中心之间的往返 ping 延迟为 77.8 ms。 - - * P50 的异步复制延迟：44.69 毫秒； P95：46.38ms; P99：47.44 毫秒； - -* 计划程序执行 - - * 调度程序的执行被抽象为计划，阶段和块。 调度计划具有不同的阶段，一个阶段具有多个块。 - - * 调度程序启动时要经过的第一阶段是协调。 它将发送给 Mesos 并确定已经在运行什么。 - - * 有一个部署阶段，检查集群中是否已存在配置中的节点数，并在必要时进行部署。 - - * 块似乎是 Cassandra 节点规范。 - - * 还有其他阶段：备份，还原，清理和修复，具体取决于所命中的 REST 端点。 - -* 集群可以每分钟一个新节点的速率启动。 - - * 希望每个节点的启动时间达到 30 /秒。 - - * 在 Cassandra 中不能同时启动多个节点。 - - * 通常给每个 Mesos 节点 2TB 的磁盘空间和 128GB 的 RAM。 每个容器分配 100GB，每个 Cassandra 进程分配 32GB 堆。 （注意：目前尚不清楚，因此可能有错误的细节） - - * 使用 G1 垃圾收集器代替 CMS，它具有更好的 99.9％延迟（16x）和性能，无需任何调整。 - -## 裸机 vs Mesos 托管群集 - -* 使用容器的性能开销是多少？ 裸机意味着 Cassandra 不在容器中运行。 - -* 读取延迟。 几乎没有什么区别：5-10％的开销。 - - * 在裸机上平均为 0.38 ms，而在 Mesos 上为.44 ms。 - - * 在 P99 上，裸机为 0.91 毫秒，在 Mesos 上，P99 为 0.98 毫秒。 - -* 读取吞吐量。 差别很小。 - -* 写入延迟。 - - * 在裸机上平均为 0.43 ms，而在 Mesos 上为.48 ms。 - - * 在 P99 上，裸机为 1.05 毫秒，在 Mesos 上，P99 为 1.26 毫秒。 - -* 写入吞吐量。 差别很小。 - -## 相关文章 - -* [关于 HackerNews](https://news.ycombinator.com/item?id=12600298) - -* [使用 Borg 在 Google 进行大规模集群管理](http://research.google.com/pubs/pub43438.html) - -* [Google 的三个时代-批处理，仓库，即时](http://highscalability.com/blog/2011/8/29/the-three-ages-of-google-batch-warehouse-instant.html) - -* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) - -* [Google：驯服长时间延迟的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) - -* [Google 从单一数据中心到故障转移，再到本地多宿主体系结构的过渡](http://highscalability.com/blog/2016/2/23/googles-transition-from-single-datacenter-to-failover-to-a-n.html) - -* [Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) - -* [Uber 变得与众不同：使用驾驶员电话作为备份数据中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) - -* [为在现代时代构建可扩展的有状态服务提供依据](http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html) - -* [我也想运行有状态容器](https://techcrunch.com/2015/11/21/i-want-to-run-stateful-containers-too/) - -* [Uber 工程技术堆栈，第一部分：基础](https://eng.uber.com/tech-stack-part-one/) - -* [Uber，Twitter，PayPal 和 Hubspot 使用 Apache Mesos 的 4 种独特方式](https://www.linux.com/news/4-unique-ways-uber-twitter-paypal-and-hubspot-use-apache-mesos) - -链接到代码：https://github.com/mesosphere/dcos-cassandra-service - -顺便说一句，在文章中有一个链接。 - -有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。 - -我认为 ELK 不能跟上步伐。 - -@bob。 Uber 确实使用 ELK 进行记录。 它具有最大的 ELK 日志搜索安装之一。 - -我想知道他们是否正在使用 Mesos 卷进行持久数据存储。 - -是的，我们正在使用持久卷（https://mesos.apache.org/documentation/latest/persistent-volume/）进行数据存储。 - -你好 - -您能否阐明查询的性质？ - -聚合或联接或基于纬度的查询？ - -是否想知道 solr 是否可以根据您的用例进行选择？ - -> >有趣。 我想知道他们如何处理每秒 1M 个事件的日志记录。 - -如今，许多人用来实现此目的的一种模式是使用 kafka 日志记录库，该库挂接到其微服务中，并使用 spark 等将来自 Kafka 的日志消耗到 elasticsearch 中。 我们在一个很小的〜8 节点 ES 集群上每秒处理数十万个事件。 - --SRE @ Orchard 平台 - -您能否分享 DC 之间的延迟时间？ - -Uber 使用 DC / OS 很有意思，但选择使用 Aurora 而非马拉松。 我上一次看极光时（大约 18 到 24 个月前），它的发展程度不及马拉松。 我想知道何时做出决定？ Aurora 文档得到了很大的改进。 - -很棒的帖子！ 使用 Mesos 代替 Hadoop YARN 是否有任何特殊原因？ Mesos 是否更适合您的需求？ - -YARN 只能运行 Hadoop 工作负载 Mesos 允许您运行任何类型的工作负载。 - -谢谢您，先生，非常有信息。 -Mesos 是否可以在没有 Docker 容器的情况下运行以安装 Cassandra？ -我们可以使用 Mesos 默认容器安装 cassandra 吗？ - -很棒的翔实文章。 做得好！ - -怎么可能有 100 万次写入但每秒 10 万次读取？ 支持多于读比写有意义吗？ \ No newline at end of file +是的，阅读本访谈内容不多。 一点都没有。 \ No newline at end of file diff --git a/docs/45.md b/docs/45.md index 3ee3092..9863faa 100644 --- a/docs/45.md +++ b/docs/45.md @@ -1,239 +1,211 @@ -# The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购 +# Justin.tv 的实时视频广播架构 + +> 原文： [http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html) + +![](http://s.justin.tv/jtv_user_pictures/hosted_images/dark-small.png) + +未来是活的。 未来是实时的。 未来是现在。 无论如何，这是炒作。 由于它有做事的习惯，因此炒作正逐渐成为现实。 我们正在看到实时搜索，实时推文，实时位置，实时现实增强，实时螃蟹（新鲜和本地）以及实时事件发布。 所有直播技术中最具挑战性的一项是直播视频广播。 想象一下一个世界，每个人都是实时的广播人和视频流的使用者（< 250 毫秒延迟），所有这些使您可以直接进行对话和交互，而不会感到自己处于时移之中 战争。 实现这一目标所需的资源和工程必须足够。 你是怎样做的？ + +为了找到答案，我与 Justin.tv 创始人兼工程副总裁 Kyle Vogt 进行了交谈。 Justin.tv 当然有这个数字。 据报道，他们每月有 3000 万独立访问者在视频上传游戏中的表现甚至超过了 YouTube，据报道每分钟上传视频的时间比 You​​Tube 的 23 小时多了近 30 小时。我在听了另一位 Justin Kan 的[采访后要求接受采访 同名](http://www.gabrielweinberg.com/blog/2010/03/justin-kan-on-getting-traction.html) [Justin.tv](http://www.justin.tv) 的创始人。 贾斯汀（Justin）谈到实况视频与 YouTube 的批处理视频方法有本质的区别，后者将所有视频存储在磁盘上，然后按需播放。 实时视频无法通过更快地推送视频来制作，它采用了完全不同的架构。 由于 [YouTube 体系结构](http://highscalability.com/youtube-architecture)文章是该网站上最受欢迎的文章，因此我认为人们也可能会喜欢学习视频世界的现场知识。 凯尔（Kyle）投入大量时间和洞察力，对贾斯汀（Justin.tv）如何使所有实时视频魔术发生的事情产生了极大的兴趣，远远超出了通话范围，提供了大量多汁的细节。 任何构建系统的人都可以从他们的业务运作中学习到一些东西。 我非常感谢 Kyle 忍受着我永无止境的努力。 + +随着重点从批处理转移到实时，Justin.tv 正在采取的步骤在整个行业中也正在发生。 我们基本上已经学习了如何创建可伸缩的批处理系统。 实时性需要不同的架构。 例如，LinkedIn 已花费大量精力来构建[实时搜索](http://thenoisychannel.com/2010/01/31/linkedin-search-a-look-beneath-the-hood/)，即使对于复杂的查询，该查询也几乎是即时更新的。 他们通过在内存中对数据进行分区并编写自己的高度专业化的系统来使其工作来实现此目的。 + +Google 也许是实时更改的完美典范。 当 Google 有点笨拙时，他们每个月都会懒惰地更新搜索索引。 这是一个批处理模型，这意味着需要设计用于存储大量数据的基础结构，这需要高吞吐量而不是低延迟。 时代变了。 现在，谷歌大肆宣传[咖啡因](http://www.theregister.co.uk/2009/08/14/google_caffeine_truth)和[不断更新](http://cacm.acm.org/magazines/2010/3/76283-gfs-evolution-on-fast-forward/fulltext)。 他们必须进行许多架构更改，并彻底改革其堆栈，以支持延迟至关重要的面向客户的应用程序（例如 Gmail）。 而且，谷歌将不是唯一必须学习如何处理新实时技术的公司。 + +## 信息来源 + +1. Justin.tv 创始人兼工程副总裁 Kyle Vogt 访谈。 +2. [贾斯汀·坎（Justin Kan）着作加布里埃尔·温伯格（Gabriel Weinberg）的著作](http://www.gabrielweinberg.com/blog/2010/03/justin-kan-on-getting-traction.html) +3. [AWS Kyle Vogt 的启动项目](http://www.slideshare.net/tracylaxdal/justintv-aws-the-startup-project)。 这是 3 年前的 Justin.tv 的体系结构。 +4. [内部实时视频服务 Justin.tv](http://www.building43.com/videos/2010/01/12/inside-live-video-service-justin-tv) 。 Robert Scoble 对 Justin.tv 市场营销副总裁 Evan Solomon 的采访。 + +## 平台 + +1. 两次-自定义 Web 缓存系统。 （http://code.google.com/p/twicecache/） +2. XFS-文件系统。 +3. HAProxy-软件负载平衡。 +4. LVS 堆栈和 ldirectord-高可用性。 +5. Ruby on Rails-应用程序服务器 +6. Nginx-Web 服务器。 +7. PostgreSQL-用于用户和其他元数据的数据库。 +8. MongoDB-用于其内部分析工具。 +9. MemcachedDB-用于处理高写入数据，例如视图计数器。 +10. Syslog-ng-日志记录服务。 +11. RabitMQ-用于作业系统。 +12. 木偶-用于构建服务器。 +13. Git-用于源代码控制。 +14. Wowza-Flash / H.264 视频服务器，以及许多用 Java 编写的定制模块。 +15. Usher-用于播放视频流的自定义业务逻辑服务器。 +16. S3-小图像存储。 + +## 统计资料 + +1. 4 个数据中心遍布全国。 +2. 在任何给定时间，都会有近 2,000 个传入流。 +3. 每天每分钟增加 30 个小时的视频。 +4. 每月有 3000 万独立访问者。 +5. 平均实时带宽约为每秒 45 吉比特。 每日峰值带宽约为 110 Gbps。 最大峰值是 500 Gbps。 +6. 基于商用硬件的大约 200 台视频服务器，每个服务器都可以发送 1Gbps 的视频。 比大多数 CDN 小，但比大多数视频网站大。 +7. 每周可节省约 100TB 的档案存储空间。 +8. 观看者开始失去实时交谈和交互功能之前，完整的视频路径的延迟不得超过 250 毫秒。 + +## 实时视频架构 + +![](img/a01efdd50af991f1296e0a4abee4e706.png) + +1. 为什么直播视频很难？ 似乎您只需要很多带宽，将其全部保留在内存中，将流重新排序，就可以完成了。 简单。 没那么简单。 如果您不能仅通过 YouTube 更快地处理实时视频，是什么使实时视频成为挑战？ + 1. 实时视频不会打 h，这意味着您无法超额订阅带宽。 当 YouTube 从订阅带宽开始时。 他们在 8 个演出管道中有 10 个演出的流量。 那行得通，因为玩家只需要缓冲即可。 使用实时视频，即使您超出网络容量一秒钟，也可以让每个观众同时观看所有视频。 如果您的需求超出容量，它将无法正常工作，每个人都会不断看到缓冲。 拥有网络容量非常重要，他们必须做正确的事情。 因此，他们提出了他们的对等架构。 如果需要，它们还具有比所需可用容量更多的容量。 + 2. 当 CDN 溢出时，它们会优雅地溢出到 CDN。 有时它们确实会用完容量，并且努力地努力使 CDN 溢出。 Usher 处理此逻辑。 一旦容量不足，新的观看者将被发送到 CDN。 + 3. 建筑系统似乎具有 100％的正常运行时间，但能够将机器缓慢地逐步停产以进行维护。 当观众可以迅速注意到任何问题并立即通过聊天与每个人谈论时，这是非常困难的。 使用聊天功能，没有隐藏问题。 用户对服务的期望很高，因此必须妥善处理问题。 他们必须等到每个人都使用完服务器后才能进入维护模式。 旋转速度非常慢。 会话永不中断。 您通常的网站可能会有一些错误，很少有人会注意到。 +2. 当许多人想同时观看同一件事时，他们最大的问题就是控制闪光灯人群。 这是巨大的传入流量。 因此，他们需要创建一种在所有视频服务器和数据中心之间实时调整负载的方法。 该机制就是 Usher。 +3. Usher 是他们创建的自定义软件，用于管理负载均衡，身份验证和其他播放流的业务逻辑。 Usher 会计算要发送每个流的服务器数量，以确保始终保持最佳负载。 这是他们的特殊调味料，也是使他们的系统与众不同的地方。 它基于以下因素实时决定如何将流复制到服务器： + 1. 特定数据中心的负载量。 + 2. 所有服务器的单独负载。 + 3. 延迟优化。 + 4. 流可用的服务器列表。 + 5. 您的 IP 地址，以了解您来自哪个国家。 + 6. 您在其路由数据库中的 IP 地址，以查看他们是否与您的 ISP 对等。 + 7. 请求来自哪个数据中心，他们尝试将您发送到同一数据中心中的视频服务器。 +4. 使用这些指标，Usher 可以优化纯成本，以将您发送到免费的服务器，或者将您发送到最接近要优化其延迟和性能的服务器。 他们有很多拨盘可以转动，并且具有非常精细的控制。 +5. 每个服务器都可以充当边缘服务器（视频在其中流传输到查看器）和原始服务器（视频在其中从广播公司流式传输）。 根据负载，流可能在网络中的一台服务器或每台服务器上可用。 这是一个动态且不断变化的过程。 +6. 服务器之间如何复制流的连接看起来像一棵加权树。 流的数量不断采样。 如果某个流具有很高的新传入查看器速度，则该流将被复制到其他几个服务器。 然后重复该过程，建立树形结构，可能包括网络中的所有服务器。 此过程仅需三秒钟即可执行。 +7. 从命中原始服务器到将其复制到其他服务器以及将其复制到观众时，整个视频流都保留在内存中。 不涉及磁盘路径。 +8. 过去，Flash 尽可能使用 RTMP 协议进行访问。 每个流都有一个独立的会话。 由于该协议，它相当昂贵。 不使用多播或 P2P 技术。 下游 ISP 不支持多播。 他们确实考虑过在内部使用多播在服务器之间复制流，但是由于他们可以控制网络并在内部拥有大量廉价的带宽，因此没有太多好处。 由于它们的算法已经过优化，可以在每台服务器上放置最少数量的流，因此在精细级别上也很难做到。 这比获得的收益要复杂得多。 +9. 通过 HTTP 请求，使用 Usher 来决定使用哪个视频服务器来处理流。 视频服务器相当笨，控制服务拓扑的叠加逻辑由 Usher 管理。 +10. 最初始于 AWS，然后移至 Akamai，然后移至其自己的数据中心。 + 1. 之所以离开 AWS 是因为：1）成本； 2）网络太慢，无法满足他们的需求。 实时视频占用大量带宽，因此拥有快速，可靠，一致，低延迟的网络至关重要。 使用 AWS，您无法控制这些因素。 您的服务器运行在一个共享的网络上，该网络被过度订阅，它们的速度不能超过 300 Mbps。 他们非常喜欢动态扩展和云 API 的功能，但无法解决性能和成本问题。 + 2. 三年前，他们使用以下各种解决方案计算的每位客户成本：CDN $ .135，AWS $ .0074 数据中心$ .0017。 CDN 成本有所下降，但其数据中心成本却大致相同。 +11. 具有多个数据中心的目的不是为了冗余，而应尽可能与所有[主要对等交换](http://en.wikipedia.org/wiki/Peering)（“管理上独立的 Internet 网络的自愿互连，目的是为了在每个客户之间交换流量” 网络”）。 他们选择了该国最好的地理位置，因此可以接触到最多的同行。 + 1. 节约成本。 这意味着它们的大部分流量不会花任何钱，因为它们直接连接到其他网络。 + 2. 性能提升。 它们直接连接到所谓的“眼球”网络。 眼球网络是指网络中有许多有线/ DSL 用户的网络。 与 Justing.tv 主要为最终用户提供流量相比，与“内容”网络（如 CDN，其他网站等）进行对等互连更有意义。 它们距网络仅一跳之遥，这对于性能非常有用。 在大多数情况下，这些安排都是免费的，没有人支付任何钱，您只需挂上电话即可。 +12. 他们有一个骨干网络来获取数据中心之间的视频流。 +13. 查找对等方的选择过程是选择愿意与之对等的人。 很难找到合作伙伴。 +14. 批量购买时，带宽计费非常复杂且不规范。 他们按 90％和 95％的百分比计费，而不是实际使用率。 +15. 虽然没有从磁盘流式传输视频流，但视频已存档到磁盘。 原始服务器是为处理传入流而选择的服务器，它将流记录在本地磁盘上，然后将该记录上载到长期存储中。 + 1. 视频的每一秒都会被记录和存档。 + 2. 存档存储看起来就像 YouTube，只是一堆磁盘。 XFS 用作文件系统。 + 3. 这种体系结构将广播的写入传播到整个服务器。 同时编写数千个流需要大量的工作。 + 4. 默认情况下，流将保留 7 天。 用户可以手动指定可以永久存储的剪辑。 + 5. 视频文件可以轻松地跨磁盘分区。 +16. 他们的操作系统已经过优化，可以应付大量的闪存，因为闪存给系统带来了很大压力。 网络堆栈已调整为每秒处理大量传入连接。 由于它们没有大量的磁盘活动，因此不需要进行其他调整。 +17. 客户端参与负载平衡逻辑，这是他们要求使用自己的播放器的原因之一。 TCP 非常擅长处理几百 kbps 的典型数据速率，因此无需对 TCP 设置进行特殊处理。 +18. 视频服务器的数量似乎很少，因为使用 Usher 可以将每个视频服务器运行到最大容量。 负载平衡确保它们永远不会超出其限制。 负载主要在内存中，因此它们可以以最大容量驱动网络。 +19. 一次从 Rackable 购买整个机架的服务器。 他们只是在所有预接线中滚动它们。 +20. 添加了实时转码功能，可以采用任何格式的流，更改传输层和编解码器，然后以新格式将其流式传输。 有一个代码转换集群可以处理代码转换。 转码会话是通过作业系统安排的，该作业系统在集群中产生转码会话。 如果需求超过其转码服务器场，则它们的所有服务器都可以是转码服务器。 +21. 对于从繁重的协议转向使用 HTTP 流的趋势感到满意，HTTP 流在现有技术的基础上可以很好地扩展。 一个问题是没有重点关注延迟和实时性。 人们忽悠了一下，说它是实时的，如果晚 5 到 30 秒，但是对于成千上万试图实时交谈和互动的人来说，这是不能正常工作的。 延迟不能超过 1/4 秒。 + +## 网络架构 + +![](img/5c831f89d24b37662336b049e84ef886.png) + +1. 高峰请求量是其稳态流量的 10 倍。 他们必须能够处理重大事件。 +2. Ruby on Rails 被用作前端。 +3. 系统中的每个页面都使用其自定义的称为 Twice 的缓存系统进行缓存。 两次充当轻量级反向代理和模板系统的组合。 想法是缓存每个页面，然后使合并每个用户的内容变得容易。 +4. 使用两次，每个进程每秒可以处理 150 个请求，而后端每秒可以处理 10-20 个请求，它们可以服务的网页数量增加了 7 倍至 10 倍。 超过 95％的页面超出了缓存的速度。 +5. 由于所需的处理量很少，因此大多数动态网页浏览均在 5 毫秒内呈现。 +6. Twice 具有插件架构，因此可以支持特定于应用程序的功能，例如： + 1. 添加地理信息。 + 2. 查找两次高速缓存密钥或 MemcacheDB 密钥。 + 3. 自动缓存用户名等数据，而无需触摸应用程序服务器。 +7. 两次量身定制，以适应他们的需求和环境。 如果启动一个新的 Rails 应用程序，一位工程师认为使用 Varnish 可能是一个更好的主意。 +8. Web 流量由一个数据中心提供。 其他数据中心在那里提供视频。 +9. 他们已经添加了对所有内容的监视。 每次点击，页面浏览和操作都会得到衡量，以帮助改善服务。 来自前端，Web 调用或来自应用程序服务器的日志消息将转换为 syslog 消息，并通过 syslog-ng 转发到单个日志主机。 他们扫描数据，将其加载到 MongoDB 中，然后在 MongoDB 上运行查询。 +10. 他们的 API 由与网站相同的应用服务器提供。 它使用相同的缓存引擎，因此可以通过扩展网站来扩展 API。 +11. PostegreSQL 是他们的主要数据库。 具有主控器和一组读取从属器的结构很简单。 +12. 对于他们的网站类型，他们没有太多的写作。 缓存系统处理读取。 +13. 他们发现 PostgreSQL 不能很好地处理大量的少量写入，这确实使它陷入困境。 因此，MemcachedDB 用于处理高写入数据，例如视图计数器。 +14. 他们有一个聊天集群来处理其聊天功能。 如果您转到某个频道，则会被发送到五个不同的聊天服务器。 缩放聊天比缩放视频更容易，因为它是文本并且可以很好地分区。 人们可以分成不同的房间，可以在不同的服务器上使用。 他们也没有与 10 万观看频道的人聊天。 他们所做的是将人员分配到每个 200 人的房间中，以便您可以在较小的组中进行有意义的互动。 这也有助于缩放。 我认为这是一个非常聪明的策略。 +15. AWS 用于存储配置文件图像。 他们没有建立任何可以存储很多小图像的东西，因此使用 S3 更容易。 它非常方便，而且成本也不高，因此没有理由花时间在上面。 如果确实有问题，他们会处理。 它们的图像经常使用，因此非常易于缓存，没有长尾巴问题要处理。 + +## 网络拓扑与设计 + +1. 网络拓扑非常简单且平坦。 每个服务器在机架顶部都有两个 1 gig 卡。 每个机架有多个 10 gig 接口连接到核心路由器。 对于交换机，他们发现了 Dell Power Edge 交换机，它对 L3（TCP / IP）并不是很好，但是对 L2（以太网）则很好。 一整天它将推动每个交换机 20 个演出，而且非常便宜。 核心路由器是 Cisco 6500 系列。 把事情简单化。 他们希望最小化跳数以最小化等待时间，并且还最小化每个数据包的处理量。 Usher 处理所有访问控制和其他逻辑，而不是网络硬件。 +2. 使用多个数据中心来利用对等关系，并能够将流量尽可能移近用户。 +3. 大量的对等和与其他网络的互连。 多个提供程序的供应商，因此他们可以选择最佳路径。 如果他们发现某个网络出现拥塞，则可以选择其他路由。 他们可以查看 IP 地址，查看时间并找出 ISP。 + +## 开发与部署 + +1. Puppet 用于从裸机构建服务器。 他们有大约 20 种不同类型的服务器。 从数据库从站到内存缓存框的任何内容。 有了 Puppet，他们可以将盒子变成想要的东西。 +2. 他们有两个软件团队。 一个是产品团队，另一个是基础架构团队。 团队非常平坦，每个团队大约有七八个人。 每个团队都有一名产品经理。 +3. 他们通常聘请通才，但确实有网络架构和数据库专家。 +4. 使用基于 Web 的部署系统，可以在几分钟之内将任何分支机构推入阶段或生产。 +5. 质量检查必须先签字才能投入生产。 通常需要 5 到 10 分钟。 +6. Git 用于源代码控制。 他们喜欢您可以编写一个分支（20 或 30 行功能），并将其与当前正在生产的其他所有分支合并。 事情是非常独立和模块化的。 您可以轻松地撤回与 Subversion 相适应的某些功能，在该版本中，您必须撤回整个提交，而提交某些非违规代码的任何人都不走运。 +7. 每隔几天，每个人都会尝试合并到 master 分支中，以消除冲突。 +8. 他们发布了许多小功能：每天生产 5 到 15 个部署！ 范围表格 1 行错误修复可用于更大的实验。 +9. 数据库模式升级是手工完成的。 ActiveRecord 迁移的功能强大的版本可在其复制的数据库中工作。 在将变更部署到生产中之前，有许多不同的登台环境在其中进行测试。 +10. 配置文件更改由 Puppet 处理。 +11. 每个功能基本上都是实验。 他们正在跟踪病毒性和对所做的每项重大更改的保留。 这是一个实验，因为他们试图找出哪些更改实际上可以改善他们关注的指标。 + +## 未来 + +他们的目标是增长一个数量级。 为此，他们计划进行以下更改： + +1. 分割他们的视频元数据系统。 元数据负载随流的数量和服务器的数量呈指数增长，因此随着分片的增长，需要扩展以扩展。 正在考虑卡桑德拉。 +2. 分割其 Web 数据库。 +3. 为灾难恢复目的而构建其主数据中心的副本。 + +## 得到教训 + +1. **建立与购买**。 过去，他们在构建自己的产品或购买现成的东西时做出了许多错误的决定。 例如，当他们确实应该购买时，他们首先构建了视频服务器。 软件工程师喜欢构建定制的软件，但是使用开源社区维护的软件有很多好处。 因此，他们提出了一个更好的决策流程： + 1. 这个项目活跃吗？ 保持？ 打补丁？ + 2. 有人在用吗？ 你能问别人如何修改吗？ + 3. 可扩展性很重要。 他们通常需要进行更改。 + 4. 如果我们可以自己构建，可以更快地构建它，获得更好的性能，还是获得我们需要的某些功能？ 这是一个滑坡，因为可以随时使用 feature 参数自行构建它。 现在，与 Usher 一样，他们考虑是否可以在另一个系统的外部和顶部构建功能。 在相对笨拙的视频服务器之上构建 Usher 作为其视频可伸缩性的核心主干，是该策略的一个很好的例子。 +2. **担心您所​​做的事情，而不是别人在做什么**。 他们的目标是拥有最好的系统，最多的运行时间和完善的可伸缩性。 开发该技术以处理数百万个同时广播需要花费 3 年的时间。 +3. **不要外包**。 您学到的东西的价值在于经验。 不在代码或硬件中。 +4. **将所有内容视为实验**。 衡量一切。 拆分测试。 跟踪。 测量。 这很值得。 从头开始。 做好仪器。 例如，他们将＃标签附加到复制的 URL 上，以便告诉您是否共享链接。 他们从没有测量到过度测量的时期。 通过改写广播过程，他们将转换率提高了 700％。 他们希望网站能够快速响应，以使页面加载速度更快，从而更好地提供视频。 从系统中挤出的每毫秒延迟都会带来更多广播公司。 他们希望进行 40 个实验，以使用户成为广播公司。 对于每个实验，他们希望随后查看广播公司的保留率，广播公司的病毒性，转换率，然后做出明智的决定以进行更改。 +5. **最重要的是要了解如何共享您的站点并对其进行优化**。 通过减少共享链接所需的菜单深度，他们能够将共享增加 500％。 +6. **峰的增长速度不及其他峰**快。 提供 10 倍的总视频观看次数，只需要将系统缩放 3 到 4 倍即可。 +7. **使用本地可互换零件**。 使用通用的构建基块和基础结构意味着可以响应动态负载立即重新利用系统。 +8. **确定重要内容并执行**。 网络容量非常重要，从一开始他们就必须做些事情。 +9. **运行系统热**。 利用系统的全部容量。 为什么要把钱放在桌子上？ 构建可以通过适当分配负载来响应负载的系统。 +10. **不要将时间花在无关紧要的**上。 如果它非常方便且成本不高，则没有理由花时间在上面。 对配置文件图像使用 S3 是此策略的一个示例。 +11. **支持用户他们想做的事情，而不是您认为他们应该做的事情**。 Justin.tv 的最终目标似乎是使每个人都成为广播公司。 他们正在尝试通过在用户进行实验时尽可能多地摆脱用户的方式来尽可能简化该过程。 在此过程中，他们发现游戏是一个巨大的用例。 用户喜欢捕获 Xbox 输出并直播并谈论它。 您可能不会想到要纳入业务计划的内容。 +12. **峰值负载**的设计。 如果您只是为稳定状态而设计，那么在出现峰值负载时，您的站点将被压碎。 在现场视频中，这通常是一件大事，如果您搞砸了，很多人都会散布关于您的坏话。 为峰值负载进行设计需要其他技术水平以及在架构上做正确的事情的意愿。 工程问题。 +13. **使网络架构保持简单**。 使用多个数据中心。 使用繁重的对等和网络互连。 +14. **不要害怕将事情分成更多可扩展的块**。 例如，与其在聊天频道上拥有 100,000 个人，不如将他们分成更具社交性和可扩展性的组。 +15. **实时系统无法向用户隐藏任何内容，这可能很难说服用户您的站点可靠**。 用户由于与实时系统保持不断的互动，因此他们会注意到每个问题和每个故障。 你不能躲藏 大家注意。 每个人都可以实时就发生的事情相互交流。 当用户经常遇到问题时，用户很快就会发现您的网站存在问题。 很难说服人们您的站点可靠。 在这种情况下，与用户进行交流变得更加重要。 从头开始建立可靠性，质量，可伸缩性和性能； 并设计尽可能简单且无痛苦的用户体验。 + +## 相关文章 + +1. [YouTube 体系结构](http://highscalability.com/youtube-architecture)。 +2. [热门新趋势：通过廉价的 IP VPN 而非私有线路链接云](http://highscalability.com/blog/2009/6/30/hot-new-trend-linking-clouds-through-cheap-ip-vpns-instead-o.html) +3. [凝视数据中心知识](http://www.datacenterknowledge.com/archives/category/peering/) +4. [Internet 对等知识中心](http://drpeering.net/a/Home.html) -关于对等的非常酷的图表和论文。 +5. [创业时的生活](http://abstractnonsense.com/life-at-a-startup/)，作者 Bill Moorier。 + +托德，很棒的文章。 感谢您的信息。 + +史诗般的帖子。 + +有了对最重要（对我而言）网站之一的惊人见解，您就使这个书呆子感到非常高兴，我很高兴:-)他们提供了出色的服务，其背后的技术令人 jaw 目结舌，但仍然证实了 KISS 的设计 原理。 荣誉！ + +此页面（http://blog.justin.tv/about/）显示了他们的媒体服务器是用 python 编写的，并且他们正在使用 Twisted 聊天服务器。 这仍然准确吗？ + +很棒的帖子！ + +很棒的文章。 谢谢！ + +很棒的文章，谢谢分享。 + +出色的写作。 -> 原文： [http://highscalability.com/blog/2016/9/13/the-dollar-shave-club-architecture-unilever-bought-for-1-bil.html](http://highscalability.com/blog/2016/9/13/the-dollar-shave-club-architecture-unilever-bought-for-1-bil.html) +我很好奇谁管理他们的“ Usher”系统？ 谁可以转动它支持的所有旋钮？ +知道有关基于 Web 的源部署系统的更多详细信息将很有趣。 它是定制的还是一些现有的产品？ +他们有多少个系统管理员？ +他们使用哪种 Linux（？）发行版？ +nginex 是用作反向代理还是常规的直接 http Web 服务器？ +他们对 flash / h264 / html5 视频标签/ ogg theora 有何想法？ + +哦，还有，他们说他们使用 Amazon S3 托管小型图像，是仅使用 S3 还是 S3 + CloudFront？ + +您提到 Jtv 成功的“数字”大多被夸大了，因为大量的“观看者”从未直接访问该站点，而是通过诸如 ATDHE.net 之类的站点进入。 所有这些所谓的查看器永远不会看到任何 Jtv 广告，也不属于 Jtv 聊天的一部分。 相反，他们是虚假的观众，似乎 Jtv 迫切希望增加其数字... + +谢谢你的好帖子.. -![](img/5b7af8042fb8d87998d9de26b181d823.png) +这可能是我读过的有关可扩展性的最佳文章。 贾斯汀真的成了流媒体的圣地。 -*这是 [Jason Bosco](https://www.linkedin.com/in/jasonbosco) ， [Dollar Shave Club [ HTG12 的核心平台&基础架构工程总监，介绍其电子商务技术的基础架构。](https://www.dollarshaveclub.com/)* +有趣的写...有时有点沉重！ 我最基本的观察是广播是关于传输/路由的，而本文在这方面有点过分……似乎主要集中在服务器端的考虑因素和负载平衡上。 当然这些很重要，但是当广播（实时或回放内容）是关键考虑因素时，它们并不是最重要的。 -Dollar Shave Club 拥有 300 万以上的会员，今年的收入将超过 2 亿美元。 尽管大多数人都熟悉该公司的市场营销，但是自成立以来短短几年内的巨大增长主要归功于其 45 名工程师的团队。 - -Dollar Shave Club 工程学的数字： - -## 核心统计信息 - -* 超级碗广告的投放没有停机时间：1 - -* 每月流量带宽：9 TB - -* 通过 Arm 处理的订单：3800 万张订单 - -* 发现的错误总数：4,566 - -* 自动化测试成绩：312,000 - -* 通过语音发送的电子邮件：1.95 亿封电子邮件 - -* 处理并存储在海马中的 Analytics（分析）数据点：5.34 亿 - -* 海马中的数据集大小：1.5TB - -* 当前已部署的应用程序/服务：22 - -* 服务器数量：325 - -## 技术堆栈 - -* 前端框架的 Ember - -* 主要在后端上使用 Ruby on Rails - -* 满足高吞吐量后台处理需求的 Node.js（例如：在语音中） - -* 用于基础结构软件的 Golang - -* 用于基础架构的 Python &数据科学 - -* 用于 1 个内部应用程序的 Elixir - -* 用于测试自动化的 Ruby - -* 适用于本机 iOS 应用程序的 Swift 和 Objective C - -## 基础结构 - -* 完全托管在 AWS 上 - -* Ubuntu & CoreOS - -* 用于配置管理的&地形 - -* 过渡到基于 Docker 的部署 - -* Jenkins 用于部署协调 - -* Nginx &清漆 - -* 快速交付应用程序 - -* 摘要汇总日志 - -* 用于安全监视的 CloudPassage - -* HashiCorp 的保险柜，用于秘密存储&设置 - -## 数据存储 - -* 主要是 MySQL 托管在 RDS 上 - -* 托管在 Elasticache 上的 Memcached 用于缓存 - -* 自托管 Redis 服务器主要用于排队 - -* 有点 Kinesis，用于处理来自尖峰流量的订单 - -* Amazon Redshift 用于数据仓库 - -## 消息传递&排队 - -* Resque 和 Sidekiq 用于异步作业处理&消息传递 - -* 用于消息传递的 RabbitMQ - -* Kafka 用于流处理 - -## 分析&商业智能 - -* 扫雪机&用于网络/移动分析的 Adobe Analytics - -* AWS Elastic MapReduce - -* 将 FlyData 从 MySQL 转换为 ETL 数据到 Redshift - -* 托管 Spark Databricks - -* Looker 作为 BI 前端 - -* 用于报告的近实时数据可用性 - -## 监控 - -* 岗哨哨兵&用于异常跟踪的 Crashlytics - -* 用于自定义应用程序指标的 DataDog &指标聚合 - -* SysDig 用于基础结构度量&监视 - -* 用于应用程序性能监视的 NewRelic - -* Site24x7，用于可用性监视 - -* PagerDuty，用于通话提醒 - -## 质量检查和测试自动化 - -* CircleCI 用于运行单元测试 - -* Jenkins + TestUnit + Selenium + SauceLabs 用于基于浏览器的自动化测试 - -* Jenkins + TestUnit +硒+ SauceLabs 用于大脑自动测试 - -* 用于 API 功能测试的 Jenkins + TestUnit - -* Jenkins + TestUnit + Appium + SauceLabs 用于原生 Android 自动化测试 - -* Jenkins + TestUnit + Appium + SauceLabs 用于本地 iOS 自动化测试 - -* Jenkins + TestUnit + Selenium + SauceLabs +用于 BI 测试自动化的代理服务器 - -* 用于压力，浸泡，负载和性能测试的 SOASTA + Regex 脚本。 - -## 工程工作流程 - -* 跨团队交流的松弛 - -* Trello，用于任务跟踪 - -* 具有自定义插件的 Hubot 作为我们的聊天机器人 - -* Github 作为我们的代码存储库 - -* ReviewNinja 与 Github Status API 集成，用于代码审核 - -* 连续部署-通常每天进行多次部署 - -* 转向持续交付 - -* 用于功能开发的即时沙盒环境 - -* 目前，使用 Jenkins 的单按钮推送部署正在朝着持续交付的方向发展 - -* 运行 docker 容器的游民箱= >为新工程师提供的功能齐全的开发环境，第一天 - -## 架构 - -* 事件驱动的架构 - -* 从单一架构转变为通过公共消息总线进行交互的“中型”服务 - -* CDN 边缘上基于 VCL 的边缘路由，就像其他任何应用程序一样部署。 - -* Web 和移动前端与 API 层进行对话 - -* API 层与服务进行对话，聚合数据并为客户端设置格式 - -* 服务与数据存储和消息总线进行对话 - -* 预定任务作为一项主任务运行，并在 resque / sidekiq 中分解为较小的任务 - -* 技术组件包括用于客户服务（Brain），市场营销自动化平台（Voice），履行系统（Arm），订阅计费系统（Baby Boy）和我们的数据基础结构（Hippocampus）的内部工具。 - -## 小组 - -* 45 位顶尖的企业家和高技能的工程师在加利福尼亚总部玛丽娜·德尔·雷伊工作 - -* 工程师与产品经理，设计师，UX 和利益相关者一起参与称为小分队的跨职能团队，以提供端到端功能。 - -* 团队根据域被垂直划分为前端，后端和质量检查& IT。 - -* 前端团队拥有 DSC.com &内部工具的 Web UI 和我们的 iOS & Android 应用。 - -* 后端团队拥有 DSC.com &内部工具，内部服务（计费和履行），数据平台&基础结构的 Web 后端。 - -* 质量检查团队拥有所有数字产品的测试和自动化基础架构。 - -* IT 团队拥有办公室& Warehouse IT。 - -* 工程师每年参加一次公司赞助的会议。 - -* 工程师可以购买所需数量的书籍/学习资源。 - -* 所有人的站立式办公桌。 目前可提供一张跑步机作为飞行员。 - -* 每周的工程团队午餐。 - -* Tech Belly 每隔一周举行一次活动，工程师们在午餐时间就技术主题进行演讲。 - -* 鼓励工程师尝试最前沿的技术，并通过提案请求（RFC）创建提案。 - -* 鼓励工程师在有意义的地方开源工具和库。 - -* 每位工程师都会获得标准版的 15 英寸 Mac Book Pro，27 英寸 Mac Display 和 24 英寸显示器。 - -* 一台 3D 打印机可用于打印道具和更多 3D 打印机。 - -## 获得的经验教训 - -* 当您要扩展的组件由简单的小型服务组成时，扩展将变得更加容易。 - -* 文档&知识共享对于快速成长的团队至关重要。 - -* 培养良好的测试套件对于快速发展的系统至关重要。 - -* Redis 使用一种近似的 LRU 算法，因此如果您对缓存有明确的 LRU 要求，则不适合使用 - -* 网络性能至关重要，尤其是在移动设备上-每毫秒都会使我们损失收入 - -* 可用性&用户体验对于内部工具也很重要：高效的工具=生产力更高的团队 - -[关于 HackerNews](https://news.ycombinator.com/item?id=12490369) - -您为什么决定自己托管 Redis？ 我假设您将在 ElastiCache 上运行 Redis（使用复制组以提高可用性）。 此外，为什么还要在 Elasticache 上托管 memcached？ - -似乎是一个非常标准的现代堆栈。 很高兴为他们工作！ 真正的问题是，他们向联合利华公司技术堡垒的过渡将是什么样子。 - -我想我的问题是，为什么您需要 45 名工程师才能完成基本上是一个带有订阅选项的小型目录？ - -文档首次出现很重要。 您使用什么基础设施和流程来保持其相关性？ - -为什么这家公司需要运行这么复杂的系统？ 并不是实时地有成千上万个请求的技术公司。 似乎是一种听起来过于酷炫的过度设计的解决方案。 也许他们在做一些我看不到的大而复杂的事情。 所以我很好奇。 \ No newline at end of file +只有 200 台服务器如何处理如此庞大的客户群和极端的流媒体？ 关于哪种硬件有任何详细信息吗？ 本文只讨论对等和带宽，没有具体介绍 Usher 和如何平衡 200 台服务器上的多个流。 \ No newline at end of file diff --git a/docs/46.md b/docs/46.md index 2516d33..49302c0 100644 --- a/docs/46.md +++ b/docs/46.md @@ -1,105 +1,47 @@ -# 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事，以及 Tarantool 与此相关的内容 +# 策略：缓存 404 在服务器时间上节省了洋葱 66％ -> 原文： [http://highscalability.com/blog/2016/8/30/the-cat-and-mouse-story-of-implementing-anti-spam-for-mailru.html](http://highscalability.com/blog/2016/8/30/the-cat-and-mouse-story-of-implementing-anti-spam-for-mailru.html) +> 原文： [http://highscalability.com/blog/2010/3/26/strategy-caching-404s-saved-the-onion-66-on-server-time.html](http://highscalability.com/blog/2010/3/26/strategy-caching-404s-saved-the-onion-66-on-server-time.html) -![](img/1295631a0c5a13e4ec2d6e35538297c0.png) +![](img/cfdc345e67ee6ab77afd7b46784522a3.png) -大家好！ +在 [The Onion Use Django，以及为什么它对我们如此重要](http://www.reddit.com/r/django/comments/bhvhz/the_onion_uses_django_and_why_it_matters_to_us/)一文中，他们提出了许多有趣的观点，说明了他们雄心勃勃的基础架构从 Drupal / PHP 迁移到 Django / Python：这一步并不难， 由于他们之前有移动 AV 的经验，所以花了时间和工作 俱乐部网站； 核心框架 API 的混乱使移动比停留更具吸引力； 支持站点旧版本的结构是一个尚未解决的问题； 内置的 Django 管理员节省了大量工作； 通过“减少专业化或黑客攻击的碎片”，团体开发变得更加容易； 他们使用 IRC 进行分布式开发； 狮身人面像用于全文搜索； nginx 是媒体服务器和反向代理； haproxy 将启动过程设为 5 秒程序； Capistrano 用于部署； 清洁的组件分离使移动更加容易； Git 版本控制； 具有复杂查询集的 ORM 是一个性能问题。 memcached 用于缓存渲染的页面； CDN 每 10 分钟检查一次更新； 视频，文章，图像和 404 页均由 CDN 提供。 -在本文中，我想向您介绍一个为 Mail.Ru Group 的电子邮件服务实现反垃圾邮件系统的故事，并分享我们在此项目中使用 [Tarantool](https://tarantool.org/) 数据库的经验：Tarantool 的任务是什么 ，我们面临的局限性和整合性问题，陷入的陷阱以及我们最终如何得到启示。 +但是最令人惊讶的一点是： -让我从简短的回溯开始。 大约十年前，我们开始为电子邮件服务引入反垃圾邮件。 我们的第一个过滤解决方案是卡巴斯基反垃圾邮件和 RBL（*实时黑洞列表-*是与垃圾邮件发送有关的 IP 地址的实时列表）。 这样可以减少垃圾邮件的发送，但是由于系统的惯性，我们无法足够快地（即实时）抑制垃圾邮件的邮寄。 另一个没有满足的要求是速度：用户应该以最小的延迟接收经过验证的电子邮件，但是集成解决方案的速度还不足以赶上垃圾邮件发送者。 垃圾邮件发件人在发现垃圾邮件未送达时，可以非常快速地更改其行为模型和垃圾邮件内容的外观。 因此，我们无法忍受系统的惯性，而开始开发自己的垃圾邮件过滤器。 +> 最大的性能提升是：缓存 404 并在 404 上将 Cache-Control 标头发送到 CDN。我们多达 66％的服务器时间都花在了从蜘蛛爬取无效的 url 和从野外存在的 url 中提供 404 的服务中 6-10 年前。 [编辑：实施更改后，我们的出站带宽减少了约 66％，Web 服务器群集上的平均负载减少了约 50％]。 +> +> 我们的链接中的一小部分来自旧内容，而我不再知道其网址。 我们重定向了 5 年前的所有内容。 最初在 6 到 10 年前发布的东西可能会被重定向，但是它们都不来自数据库，并且最初都是静态 HTML，在我开始为 The Onion 工作之前就没有维护重定向。 -我们的第二个系统是 MRASD-Mail.Ru 反垃圾邮件守护程序。 实际上，这是一个非常简单的解决方案。 客户的电子邮件到达 [Exim](http://www.exim.org) 邮件服务器，并通过充当主要过滤器的 RBL 到达，然后到达 MRASD，在那里发生了所有不可思议的事情。 反垃圾邮件守护程序将邮件分解为几部分：标头和正文。 然后，它使用基本算法对每个片段进行归一化，例如对字符大小写进行归一化（全部以小写或大写形式），将外观相似的符号转换为特定形式（例如，使用一个符号表示俄语和英语“ O”）等 标准化后，守护程序提取了所谓的“实体”或电子邮件签名。 我们的垃圾邮件过滤器会分析电子邮件的不同部分，并在发现任何可疑内容时将其阻止。 例如，我们可以为“ viagra”一词定义一个签名，所有包含该词的消息都会被阻止。 实体也可以是 URL，图像，附件等。 在反垃圾邮件检查过程中完成的另一件事是为已验证的电子邮件计算指纹。 计算为少数棘手的哈希函数的指纹是邮件的独特特征。 基于计算出的哈希值和收集的哈希统计信息，反垃圾邮件系统可以将邮件过滤为垃圾邮件或让其通过。 当哈希值或实体达到某个频率阈值时，服务器开始阻止所有匹配的电子邮件。 为此，我们维护了统计数据（计数器）来跟踪遇到某个实体的频率，接收者抱怨该实体的频率，并设置了一个实体标志 SPAM / HAM（在与垃圾邮件相关的术语中，“ ham”与“ 垃圾邮件”，表示经过验证的电子邮件不包含垃圾内容。 +> 蜘蛛占我 404 的绝大多数。 他们请求的 URI 根本不在我们的标记中。 我无法修复损坏的蜘蛛，并告诉它不要请求甚至不存在的这些链接，但是我仍然必须服务于它们的 404。 -MRASD 的核心部分是使用 C ++实现的，而其相当多的业务逻辑是使用解释性语言 Lua 来实现的。 正如我已经说过的那样，垃圾邮件发送者是非常有活力的人，他们会很快改变其行为。 我们的目标是尽快对垃圾邮件发送者的每项更改做出响应，这就是为什么我们使用解释性语言实施业务逻辑的原因（借助 Lua，我们不必每次都在所有服务器上重新编译系统并进行更新）。 另一个要求是速度：Lua 中的代码在性能测试中显示出良好的结果。 最后，很容易与 C ++中的代码集成。 +> CDN 未缓存我们的 404 页。 允许对它们进行缓存，可以将原始渗透率大大降低，与未缓存的 404 相比，输出带宽减少了 66％。 -![](img/0e0752752d353aa16839d288763f4911.png) +> Edit: This is not to say that our 404s were not cached at our origin. Our precomputed 404 was cached and served out without a database hit on every connection, however this still invokes the regular expression engine for url pattern matching and taxes the machine's network IO resources. -上面的方案说明了我们的反垃圾邮件过滤器的简化工作流程：电子邮件从发件人发送到我们的邮件服务器； 如果该消息已成功通过主过滤器（1），则它进一步进入 MRASD（2）。 MRASD 将其检查结果返回到邮件服务器（3），并根据这些结果将邮件传递到收件人的“垃圾邮件”文件夹或收件箱中。 +无意开玩笑，讽刺或讽刺。 这些流量大部分来自蜘蛛，它们正在寻找组成页面，因此保留 URL 并不是问题。 问题是减少了这些有毒蜘蛛的影响，并且将 404 页缓存为解毒剂。 即使您像 The Onion 一样已经有十多年没有上网了，但仍然很容易就可以找到很多东西。 -MRASD 允许我们将未过滤的垃圾邮件数量减少十倍。 随着时间的流逝，我们不断改进系统：添加了新的子系统和组件，引入了新的工具。 因此，系统不断发展，变得更加复杂，反垃圾邮件任务也变得更加多样化。 这些变化无助于影响我们的技术堆栈。 这就是本故事的下一部分。 +## 相关文章 -**技术堆栈的演进** +* [文章](http://news.ycombinator.com/item?id=1219133)上的 Hacker News Thread，其中 John Onion 耐心地尝试解释为什么 The Onion 没有惹恼广告收入。 +* [HTTP 404 响应代码](http://en.wikipedia.org/wiki/HTTP_404) +* [Fighting Linkrot](http://www.useit.com/alertbox/980614.html) by **[Jakob Nielsen](http://www.useit.com/jakob/ "Author biography")** -在电子邮件服务时代的曙光中，消息流以及消息内容比今天明显稀缺。 但是工具和计算能力的选择也较差。 从上面描述的 MRASD“父母”模型可以看出，有必要存储各种统计数据。 这些数据的很大一部分是“热”的（即经常使用），这对数据存储系统提出了某些要求。 结果，我们选择了 MySQL 作为“冷”数据的存储系统，但是对于“热”统计数据仍然不确定。 我们分析了所有可能的解决方案（它们的性能和功能适用于“热”数据，但不适用于关键任务数据），最终到达 [Memcached](https://memcached.org/) -那时，此解决方案已经足够稳定。 但是我们在存储“热”和关键数据方面仍然存在问题。 与任何其他缓存解决方案一样，Memcached 也有其局限性，包括不进行复制以及缓存关闭（并刷新）后的长时间预热时间。 我们的进一步搜索将我们带到了[京都内阁](http://fallabs.com/kyotocabinet/)，这是一个非关系键值数据库系统。 +404 占很大比例的原因是因为洋葱是 CDNed：合法的（非 404）请求主要由 CDN 服务。 但是由于 404 被 CDN 缓存，所以 CDN 将请求发送到原始服务器。 因此 404 会在原始服务器上的点击中占不成比例的百分比。 -时间过去了，电子邮件工作量增加了，反垃圾邮件工作量也增加了。 出现了需要存储更多数据的新服务（Hadoop，Hypertable）。 顺便说一句，今天的高峰处理工作量达到每分钟 55 万封电子邮件（如果我们每天计算平均值，则每分钟大约有 35 万封电子邮件），每天要分析的日志文件量超过 10 TB。 让我们回到过去：尽管工作量不断增加，但我们对数据处理（加载，保存）的要求却保持不变。 有一天，我们意识到京都议定书无法管理所需的数据量。 此外，我们需要一种存储系统，它具有针对“热”和关键数据的更广泛功能。 也就是说，是时候到处寻找更好的替代方案了，这些替代方案将更灵活，更易于使用，并具有更高的性能和故障转移功能。 那时，一个名为 Tarantool 的 NoSQL 数据库在我们公司中获得了普及。 Tarantool 是公司内部开发的，完全满足了我们的“ wannas”。 顺便说一句，我最近一直在修改我们的服务，当我遇到最早的 Tarantool 版本之一时[HT HTG0] Tarantool / Silverbox ，我感到自己是一名考古学家。 我们决定尝试一下 Tarantool，因为它的基准测试涵盖了我们所需的数据量（该时期我没有确切的工作量数据），并且也满足了我们对内存使用的要求。 另一个重要因素是项目团队位于隔壁，我们可以使用 JIRA 快速提出功能请求。 我们是决定在他们的项目中尝试使用 Tarantool 的先驱者之一，我认为其他先驱者的积极经验大大鼓舞了我们迈向 Tarantool 的第一步。 +如何阻止其中一些蜘蛛？ 任何人都有一个很好的坏蜘蛛清单。 +我读过一个博客 Bing Spider，它会在短时间内在某些网页上重复查询，这给网站带来了负担。 因此，所有者必须禁止它。 -那就是我们的“ Tarantool 时代”开始的时候。 我们积极地将 Tarantool 引入了我们的反垃圾邮件体系结构。 今天，我们有了基于 Tarantool 的队列，用于存储各种统计数据的高工作量服务：用户信誉，发件人 IP 信誉，用户可信度（“业力”统计信息）等。我们目前的活动是将升级的数据存储系统集成到我们的 实体统计处理器。 您可能想知道为什么我们只针对我们的反垃圾邮件项目专注于一个数据库解决方案，而不考虑迁移到其他存储。 嗯，事实并非如此。 我们也考虑和分析竞争系统，但是暂时，Tarantool 可以很好地处理项目中所需的所有任务和工作负载。 引入新的（未知的，以前未使用的）系统总是有风险的，并且会花费大量时间和资源。 同时，Tarantool 是我们（以及许多其他项目）的知名工具。 我们的开发人员和系统管理员已经了解使用和配置 Tarantool 的所有知识，以及如何充分利用它。 另一个优势是 Tarantool 的开发团队不断改进其产品并提供良好的支持（这些人正在隔壁工作，这很不错:)）。 当我们仍在实施另一个基于 Tarantool 的解决方案时，我们获得了所有必要的帮助和支持（我稍后会告诉您）。 +行动不便的洋葱。.如果那些记忆力很强的爬虫恰好是 googlebot，则您会以 SEO 的形式浪费大量收入。 几年前的旧页等于从 800 磅重的怀抱中走了出来。 大猩猩/蜘蛛/章鱼/大象在房间里。 -接下来，我将为您概述我们的反垃圾邮件项目中使用 Tarantool 的几个系统，这些系统将涉及我们面临的问题。 +“大部分流量来自蜘蛛寻找的组成页面，因此保留 URL 并不是问题。” -**我们使用 Tarantool** 的系统概述 +如果按您的平均水平说超过 50％，那么他们仍然会丢弃高达 25％的流量。 除此之外，爬虫只会抓取其他网站的链接，因此它们也放弃了传入链接的 SEO 优势。 他们写有趣的故事是一件好事。 :-) -**业力** +“行动不便的洋葱。如果那些记忆力很强的爬虫恰好是 googlebot，您会以 SEO 的形式浪费大量收入。几年前的旧书等于从 800 磅重的大抱抱。大猩猩/蜘蛛/章鱼/大象 -在房间里。” +他们不会放弃，只是将压力从服务器到 CDN 来处理这种 404 页。 +因此，在进行此更改之前，当您从服务器请求某个不存在的站点时，它就像： +客户端-> CDN->源服务器，然后再返回 CDN 和客户端。 +现在，当有人请求页面时，CDN 会检查其缓存（如果找不到或不允许从缓存中提供服务），然后请求为该页面提供服务的 Origin Server，如果那是 404，则发送标头 告诉 CDN 缓存该页面。 +因此，下一次该请求将直接从 CDN 的本地缓存中提供。 -**业力**是一个数字值，表示用户的信任度。 它最初是为不需要复杂的从属系统的用户提供的通用“胡萝卜和棍子”系统的基础。 业力是基于从其他用户信誉系统接收到的数据的汇总值。 业力系统背后的想法很简单：每个用户都有其业力-越高，我们对这个用户的信任就越高； 越低，我们在反垃圾邮件检查期间评估他们的电子邮件时就越严格。 例如，如果发件人发送的电子邮件中包含可疑内容，并且发件人的业障评分很高，则此类邮件会打入收件人的收件箱。 较低的业障评级将是反垃圾邮件系统的悲观因素。 这个系统使我想到了老师在学校考试中查阅的一本考勤书。 参加所有班级的学生只会得到几个额外的问题，然后休假，而错过许多班级的学生则必须回答很多问题才能获得高分。 - -![](img/7bf90374f27a6f0f5e8309a6c0d7f616.png) - -用于存储与业力相关的数据的 Tarantool 在单个服务器上工作。 下图说明了每分钟一个这样的实例执行的请求数。 - -![](img/98697072a85fdef53622b857c064baf5.png) - -**RepIP / RepUser** - -**RepIP** 和 **RepUser** （信誉 IP 和信誉用户）是一种高工作负载服务，用于处理与具有特定 IP 以及与发送者（用户）的活动和动作有关的统计信息 与用户在一定时间内使用电子邮件服务的强度有关的统计信息。 该系统使我们知道用户已发送了多少电子邮件，其中有多少已被阅读，以及有多少被标记为垃圾邮件。 该系统的优势在于，它提供了时间轴，而不是用户活动的快照。 为什么这对于行为分析很重要？ 想象一下，您在没有任何沟通手段的情况下已移居国外，所有朋友都留在家里。 然后，几年后，您的小屋里有了网线。 哇！ 您浏览到自己喜欢的社交网络的网站，然后看到朋友的照片-嗯，他已经发生了很大变化……您可以从该照片中获得多少信息？ 我想不是太多。 现在想象一下，您观看了一个视频，该视频显示了您的朋友变迁，结婚等等……-那是一段简短的传记片段。 我敢打赌，在第二种情况下，您会更好地了解朋友的生活。 数据分析也是如此：我们拥有的信息越多，我们就可以更好地评估用户的行为。 我们可以注意到发件人的邮件活动趋势，了解发件人的习惯。 根据这种统计信息，为每个用户和 IP 地址分配“信任等级点”和一个特殊标志。 此标志用于主要过滤器中，该过滤器甚至可以在垃圾邮件到达我们的邮件服务器之前过滤掉多达 70％的垃圾邮件。 这个百分比说明信誉服务的重要性。 这就是为什么此服务需要最大的性能和容错能力的原因。 这就是为什么我们在这里使用 Tarantool 的原因。 - -![](img/51db83a4a247d755fc55d4a15b7e2177.png) - -信誉统计信息存储在两台服务器上，每台服务器有四个 Tarantool 实例。 下图说明了每分钟 RepIP 请求的平均数量。 - -![](img/83d0a0db50b56264fc18f1a63bc54062.png) - -在实施信誉服务时，Tarantool 遇到了许多配置问题。 与我们之前讨论的系统不同，RepIP / RepUser 的数据包更大：这里的平均包大小为 471,97 字节（最大大小为 16 KB）。 从逻辑上讲，数据包包括两个部分：一个小的“基本”部分（标志，汇总统计信息）和一个很大的统计部分（详细的按动作统计信息）。 对整个数据包进行寻址会导致大量的网络使用，因此加载和保存记录会花费更多时间。 许多系统仅需要数据包的基本部分，但是我们如何将其从元组中剥离（“元组”是 Tarantool 的记录术语）？ 这是存储过程很方便的地方。 我们在 Tarantool 的 **init.lua** 文件中添加了所需的函数，并从客户端对其进行了调用（从 Tarantool 1.6 版开始，您可以使用纯 C 语言编写存储过程）。 - -**1.5.20 之前的 Tarantool 版本存在问题** - -说我们从未遇到过 Tarantool 问题是错误的。 是的，我们有一些。 例如，在计划的重新启动后，Tarantool 客户端（超过 500 个）由于超时而无法重新连接。 当出现故障后，下次尝试重新连接的尝试被延迟了一段时间后，我们尝试引入渐进式超时，但这无济于事。 我们发现，问题在于 Tarantool 在其事件循环的每个周期内仅接受一个连接请求，尽管有数百个请求在等待。 我们有两种选择：安装新的 Tarantool 版本（1.5.20 或更高版本）或修改 Tarantool 的配置（禁用 *io_collect_interval* 选项可以解决此问题）。 Tarantool 开发人员很快修复了此错误，因此 Tarantool 1.6 或 1.7 将不会提供它。 - -**RepEntity-实体信誉** - -我们当前正在集成一个新组件，用于存储实体统计信息（URL，图像，附件等）。 **RepEntity** 。 RepEntity 的目的类似于已经讨论的 RepIP / RepUser 的目的：它提供有关实体行为的详细信息，这是我们的反垃圾邮件过滤器的决策标准。 借助 RepEntity 统计信息，我们可以根据电子邮件的实体过滤出垃圾邮件。 例如，邮件可能包含可疑的 URL（例如，其中可能包含垃圾内容或导致[网络钓鱼](https://en.wikipedia.org/wiki/Phishing)网站），而 RepEntity 可以帮助我们更快地注意到并阻止此类邮件。 怎么样？ 我们可以看到该 URL 的动态发送，并且可以检测到其行为的变化，这对于“固定”计数器是不可能的。 - -除了不同的数据包格式外，RepEntity 和 RepIP 系统之间的基本区别是 RepEntity 在我们的服务上产生了明显更高的工作负载（处理和存储的数据量更大，请求数量也更多）。 一封电子邮件最多可以包含一百个实体（最多 10 个 IP 地址），对于大多数这些实体，我们必须加载并保存完整的统计信息包。 值得注意的是，数据包由特殊的聚合器保存，该聚合器首先等待积累足够的统计信息。 因此，所有这些都意味着数据库系统要承担更多的工作量，并且需要准确的设计和实现。 **让我强调一下，由于某些项目限制，对于 RepEntity，我们使用了 Tarantool 1.5（因此，我将继续撰写此版本）。** - -首先，我们估计了存储所有统计信息所需的内存量。 为了更好地说明此任务的重要性，让我带来一些数字：在预期的工作量下，将数据包增加 1 个字节意味着将数据总量增加 1 GB。 如您所见，我们的任务是以最紧凑的方式将数据存储在一个元组中（正如我已经说过的，我们无法将整个数据包存储在一个元组中，因为我们经常要求仅检索一部分数据包数据） 。 要计算要存储在 Tarantool 中的数据量，我们还需要考虑： - -* 存储索引的额外空间 -* 用于在元组中存储数据大小的额外空间（1 个字节） -* 最大元组大小的限制为 1 MB（对于 1.7 版，请参见 [http://tarantool.org/doc/book/box/limitations.html](http://tarantool.org/doc/book/box/limitations.html) ） - -Tarantool 增加了各种请求（读取，插入，删除）的数量，从而产生超时错误。 我们的调查表明，在频繁插入和删除的情况下，Tarantool 启动了一个复杂的树重新平衡过程（我们的所有索引均为 TREE 类型）。 Tarantool 中的树索引具有棘手的自平衡逻辑，仅在满足某些“不平衡”条件时才会启动。 因此，当一棵树“失去足够的平衡”时，Tarantool 启动了重新平衡过程，这使得 Tarantool 变得口吃。 在日志中，我们发现消息*资源暂时不可用（errno：11）*，这些消息在几秒钟后消失了。 但是，尽管发生了这些错误，客户端仍无法获取请求的数据。 Tarantool 团队的同事提出了一个解决方案：尝试使用其他类型的树索引 AVLTREE，该索引在每次插入/删除/更改时都会重新平衡。 实际上，尽管重新平衡呼叫的数量有所增加，但其总成本却更低。 在更新架构并重新启动数据库之后，该问题永远消失了。 - -我们面临的另一个问题是清理过时的记录。 不幸的是，Tarantool（据我所知，对于 1.7 版也是如此）不允许为某个记录定义 TTL（生存时间），而忘记了它，而所有清理活动都委托给了数据库。 好了，您仍然可以自己使用 Lua 和 [box.fiber](http://stable.tarantool.org/doc/mpage/stored-procedures.html#sp-box-fiber) 实现所需的清理逻辑。 从好的方面来说，这提供了更大的灵活性：您可以定义复杂的清除条件，而不仅仅是基于 TTL 的条件。 但是，要正确实现清除逻辑，您需要注意一些细微差别。 我实施的第一根清洁纤维使 Tarantool 的速度非常慢。 事实是，我们可以删除的数据量大大少于记录的总数。 为了减少要删除的记录候选者的数量，我引入了基于所需字段的二级索引。 之后，我实现了一个遍历所有候选对象的光纤（其上次修改的时间戳早于指示的时间戳），检查了其他清除条件（例如，当前是否为记录设置了“正在进行写入”标志），并且 如果满足所有条件，则光纤会删除该记录。 当我在零工作负载下测试逻辑时，一切工作正常。 在低工作量的情况下也很好。 但是，当我将工作量增加到预期水平的一半时，我遇到了问题。 我的请求开始失败，并显示超时错误。 我知道我一定已经溜了。 当我深入研究这个问题时，我意识到我对光纤的工作方式有一个错误的认识。 在我的世界中，光纤是一个独立的线程，对接收和处理客户端请求没有任何影响（上下文切换除外）。 但是不久，我发现我的光纤使用了与请求处理线程相同的事件循环。 这样，我循环遍历大量记录而不删除任何内容，只是阻止了事件循环，因此未处理客户端请求。 为什么提到删除操作？ 您会看到，每次删除一些记录时，都会发生一次 yield 操作，该操作解除了事件循环的阻塞并允许处理下一个事件。 在这一点上，我得出的结论是，如果执行了一些 N 操作（其中 N 是一个经验推导的值，我取 N = 100）而没有产生屈服，则有必要强制屈服（例如，使用 *wrap.sleep（ 0）*）。 要记住的另一件事是，删除记录可能会触发索引更新，因此在遍历记录时我可能会丢失一些要删除的数据。 这是另一个解决方案。 在一个周期中，我可以选择一小部分元素（低于 1000 个）并遍历这些元素，删除所需的元素，并跟踪最后一个未删除的元素。 在下一次迭代中，我将从最后一个未删除的元素中选择另一小部分元素。 - -我们还尝试过实施一种解决方案，该解决方案可以在将来实现平滑的分片，但此尝试失败了：实现的机制开销太大，因此我们暂时放弃了分片。 希望我们可以在较新版本的 Tarantool 中找到重新分片功能。 - -这是一些性能提示。 - -要提高 Tarantool 的性能，您可以禁用* .xlog 文件。 但是请记住，在这种情况下，Tarantool 仅作为高速缓存工作，并具有所有的限制（我的意思是没有复制，重新启动后等待时间很长）。 这里的解决方法是不时制作快照，并在需要时使用它来还原数据。 - -如果一台计算机上有多个 Tarantool 实例，则可以将每个实例“精确定位”到某个 CPU 内核以提高性能。 但是，如果您说 12 个物理内核，那么开始 12 个实例就不好了，因为每个 Tarantool 实例与执行线程一起还具有一个 WAL 线程。 - -所需功能： - -* 分片。 -* 基于集群的方法，可以进行动态集群配置，例如在添加节点或节点出现故障的情况下派上用场，类似于 MongoDB（mongos）和 Redis（redis sentinel）。 -* 可以为记录清除定义 TTL（生存时间）。 - -**的结论** - -Tarantool 是我们反垃圾邮件系统的基石，我们许多重要的高工作量服务都基于此。 现成的[连接器](http://stable.tarantool.org/doc/mpage/connectors.html)使轻松将 Tarantool 与使用不同编程语言实现的组件集成在一起成为可能。 Tarantool 的成功历史悠久：多年来，在我们的反垃圾邮件项目中使用 Tarantool 以来，我们在操作或稳定性方面都没有遇到严重问题。 但是，要充分利用该数据库，您需要考虑一些配置上的细微差别（在这里我们一直在谈论 Tarantool 1.5 版的细微差别）。 - -关于我们未来计划的几句话： - -* 在我们的项目中增加基于 Tarantool 的服务的数量。 -* 迁移到 Tarantool 1.7。 -* 开始使用 Vinyl 引擎，尤其是对于 RepEntity 来说，真正的“热”数据量并不大。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=12397570) - -保存 - -反垃圾邮件系统内部邮件处理的平均延迟是多少？ 是否有关于典型请求分解的任何分析信息？ \ No newline at end of file +泰瑞尔 \ No newline at end of file diff --git a/docs/47.md b/docs/47.md index 4aa0274..d0efc55 100644 --- a/docs/47.md +++ b/docs/47.md @@ -1,348 +1,270 @@ -# Google 如何针对行星级基础设施进行行星级工程设计？ +# Poppen.de 建筑 -> 原文： [http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html](http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html) +> 原文： [http://highscalability.com/blog/2010/4/12/poppende-architecture.html](http://highscalability.com/blog/2010/4/12/poppende-architecture.html) -![](img/9c7095e31a8c5999cdcef74072ddf82a.png) +这是 Alvaro Videla 的来宾，他描述了 [Poppen.de](http://www.poppen.de/) 这个流行的德国约会网站的架构。 该站点非常类似于 NSFW，因此在单击链接之前请多加注意。 我发现最有趣的是，他们如何使用 Nginx，MySQL，CouchDB 和 Erlang，Memcached，RabbitMQ，PHP，Graphite，Red5 和 Tung 等技术，成功地将一些旧代码与一些新代码成功融合。 -Google 如何保持其所有服务正常运行？ 他们似乎从来没有失败过。 如果您想知道我们在 [GCP NEXT 2016](https://cloudplatformonline.com/next2016-schedule.html) 上发表的演讲中的精彩幕后花絮， [Melissa Binde](https://www.linkedin.com/in/mbinde) ，Google Storage SRE 总监： [Google 如何针对行星级基础架构](https://www.youtube.com/watch?v=H4vMcD7zKM0)进行行星级工程。 +## 什么是 Poppen.de？ -梅利莎（Melissa）的讲话很简短，但充满智慧，而且以一种胡说八道的方式表达出来，使您认为服务是否失败梅利莎（Melissa）绝对是您想要的那种人。 +Poppen.de（NSFW）是德国最热门的约会网站，尽管与 Flickr 或 Facebook 这样的巨头相比，它可能是一个很小的网站，但如果您开始遇到一些扩展问题，我们认为这是一个不错的架构。 -哦，什么是 SRE？ 它代表*站点可靠性工程*，但定义更难以理解。 就像您要求道的定义时得到的答案一样。 正如 Google 的本·斯洛斯（Ben Sloss）24x7 副总裁所明确指出的那样，这不仅仅是一个过程，更是一个过程，他将 SRE 定义为： +## 统计资料 -> 当软件工程师承担了过去称为操作的任务时会发生什么。 +* 2.000.000 用户 +* 20.000 个并发用户 +* 每天 300.000 条私人消息 +* 每天 250.000 次登录 +* 我们有一个由 11 个开发人员，2 个设计师和 2 个 sysadmin 组成的项目团队。 -让它在您的头部反弹一会儿。 +## 商业模式 -最重要的是，有一件事很清楚：SRE 是生产的保管人。 SRE 是 google.com 和 GCP 的客户体验的托管人。 +该网站使用免费增值模式，用户可以免费执行以下操作： -对我来说，一些演讲重点： +* 搜索其他用户。 +* 互相写私信。 +* 上传图片和视频。 +* 有朋友 +* 视频聊天。 +* 多得多… -* **点检正常运行时间的破坏性激励与功能**相比。 SRE 试图解决想要推送功能的开发人员与想要通过不推送功能来维持正常运行时间的系统管理员之间的天然紧张关系。 -* **错误预算**。 这就是预期会失败的想法。 这不是一件坏事。 用户无法确定服务的运行时间是 100％还是 99.99％，因此您可能会出错。 这减少了开发人员和运营人员之间的紧张关系。 只要维持错误预算，您就可以推出新功能，而运营方也不会受到指责。 -* **目标是立即恢复服务。 故障排除将在稍后进行。** 这意味着在恢复服务后，您需要大量日志记录和工具来进行调试。 由于某种原因，这使[较早的文章](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html)上的内容闪烁了起来，同样基于 Google SRE 的讲话：*备份无用。 这是您关心的*还原。 -* **没有无聊的分页哲学**。 当页面进入时，应该是一个有趣的新问题。 您不希望无聊的 SRE 处理重复性问题。 这就是机器人的目的。 +如果他们想发送无限制的消息或上传无限制的图片，则可以根据需要为不同类型的成员付费。 视频聊天和网站的其他部分也是如此。 -演讲中其他有趣的话题是：SRE 的组织结构如何？ 如何聘请开发人员担任侧重于生产的角色并使他们满意？ 我们如何保持团队在 Google 内部的价值？ 我们如何帮助我们的团队更好地沟通并解决与数据而非断言或权力夺取的分歧？ +## 工具箱 -让我们继续吧。 以下是 Google 如何针对行星级基础设施进行行星级工程... +### Nginx 的 -## 保持平衡：点检正常运行时间的破坏性动机与功能 +我们所有的网站都通过 Nginx 提供服务。 我们有 2 台 Nginx 前端服务器，在高峰时间每分钟向 www.poppen.de 发送 150.000 个请求。 它们是使用四年的计算机，每个计算机只有一个 CPU 和 3GB RAM。 然后，我们有单独的机器来提供站点图像。 每分钟由 3 个 nginx 服务器处理* .bilder.poppen.de（图像服务器）有 80.000 个请求。 -* 系统管理员会在站点正常运行时获得 Cookie 的正常运行时间。 当网站停滞不前时，我们会吸引访问者，访问者会给我们钱。 +Nginx 让我们做的很酷的事情之一就是从 Memcached 发出很多请求，而无需点击 PHP 机器来获取已经缓存的内容。 因此，例如，用户配置文件是站点中 CPU 占用最大的页面之一。 请求配置文件后，我们会将全部内容缓存在 Memcached 上。 然后 Nginx 服务器将命中 Memcached 并从那里传递内容。 每分钟有 8000 个请求从 Memcached 发送出去。 -* 开发人员会获得功能的 Cookie。 发布一个新功能，访问者来了，他们给了我们钱。 +我们有 3 个 Nginx 服务器正在从本地缓存中传递图像。 用户将他们的图片上传到中央文件服务器。 图片请求将命中 3 台 Nginx 服务器之一。 如果图片不在本地缓存文件系统中，则 Nginx 将从中央服务器下载图片，将其存储在本地缓存中并提供服务。 这使我们可以负载均衡图像分布并减轻主存储机中的负载。 -* 生产冻结，也就是新功能的冻结，通常映射为增加正常运行时间。 +### PHP-FPM -* 开发人员和系统管理员之间存在天生的紧张关系。 开发人员会获得发布功能的 Cookie。 系统管理员会获取 Cookie 以确保正常运行时间。 +该站点在 PHP-FPM 上运行。 我们使用 28 台 PHP 机器，每个机器具有两个 CPU 和 6GB 的内存。 他们每个运行 100 个 PHP-FPM 工作进程。 我们使用启用 APC 的 PHP5.3.x。 PHP 5.3 版本使我们可以减少 30％以上的 CPU 和内存使用率。 -* 因此，系统管理员因阻止新功能发布而获得奖励。 如果开发人员能够解决系统管理员的问题，他们将获得奖励。 +该代码是使用 symfony 1.2 PHP 框架编写的。 一方面，这意味着额外的资源占用，另一方面，它使我们可以加快开发速度，并拥有众所周知的框架，可以使我们轻松地将新开发人员集成到团队中。 这里并不是所有的东西都是“花和玫瑰”。 因此，尽管我们拥有该框架提供的许多优势，但我们还是不得不对其进行大量调整，以使其达到服务于 www.poppen.de 的任务。 -* 开发人员进行他们所谓的 Beta 测试是为了尽快发布功能。 +我们所做的就是使用 XHProf（Facebook 的 PHP 概要分析库）对站点进行概要分析，然后优化瓶颈。 由于该框架易于自定义和配置，因此我们能够缓存大多数昂贵的计算，这些计算给 APC 中的服务器增加了额外的负载。 -* 系统管理员执行他们所谓的启动审核，以减慢新功能。 +### 的 MySQL -* 您的团队将所有的时间都花在彼此抗争上，因此您会增加停机次数，风险，混乱和无政府状态。 +MySQL 是我们的主要 RDBMS。 我们有几台 MySQL 服务器：一台 32GB 的机器，带有 4 个 CPU，用于存储所有与用户有关的信息，例如个人资料，图片元数据等。该机器已有 4 年的历史。 我们计划将其替换为分片群集。 我们仍在设计此系统，以尽量减少对我们的数据访问代码的影响。 我们希望按用户 ID 对数据进行分区，因为网站上的大多数信息都以用户本身为中心，例如图像，视频，消息等。 -* 您想要的是消除异想天开的命令。 请按规则处理，以便团队可以有目标并共同努力。 +我们有 3 台机器在用户论坛的主从配置中工作。 然后有一个服务器群集，用作网站自定义消息系统的存储。 目前，它有超过 2.5 亿条消息。 它们是在主从站主/从站从站系统中配置的 4 台机器。 -* 与 devops 一样，有一种方法可以使开发人员和操作人员一起工作。 问题是，devops 无论走到哪里都有不同的含义。 相反，SRE（站点可靠性工程）定义明确。 +我们还有一个由 4 台计算机组成的 NDB 集群，用于写入大量数据，例如哪个用户访问了哪个其他用户的个人资料的统计信息。 -* **SRE：** **当您要求软件工程师设计和运行操作时会发生什么情况**-Ben Sloss 24x7 VP，Google +我们尝试尽可能避免像瘟疫这样的联接并缓存。 数据结构被高度非规范化。 为此，我们创建了摘要表，以简化搜索。 - * 软件工程师-事实证明，当知道软件的人也运行服务时，服务可以更好地运行。 他们对什么使它打勾有深刻的理解。 +大多数表都是 MyISAM，可提供快速查找。 我们看到越来越多的问题是全表锁。 我们正在转向 XtraDB 存储引擎。 - * 设计和运行-实际上是设计您的生产环境，而不是让它成为意外的事故。 +### 记忆快取 -* 假设有 1000 个 SRE 在 Google 的基础架构上工作：网络，计算，存储等。有多少个 SRE 负责云计算？ +我们大量使用 Memcached。 我们有超过 51 个节点的 45 GB 缓存。 我们将其用于会话存储，视图缓存（如用户配置文件）和函数执行缓存（如查询）等。我们对用户表拥有的大多数按主键进行的查询都缓存在 Memcached 中，然后从那里传递 。 我们拥有一个系统，该系统可在每次修改该表的一条记录时自动使缓存无效。 将来改善缓存失效的一种可能解决方案是使用新的 Redis Hash API 或 MongoDB。 使用这些数据库，我们可以以足够的粒度更新缓存，而无需使其无效。 - * 所有。 +### 兔子 MQ - * google.com 和 GCP（HTG1）的运行之间没有界限。 不需要让云团队和内部团队进行沟通的开销。 他们创造了一种环境，可以帮助所有人协同工作。 +自 2009 年中以来，我们将 RabbitMQ 引入了我们的堆栈。 这是一个易于部署并与我们的系统集成的解决方案。 我们在 LVS 后面运行两个 RabbitMQ 服务器。 在上个月，我们一直在将越来越多的东西移到队列中，这意味着目前 28 台 PHP 前端计算机每天大约发布 50 万个作业。 我们向队列发送日志，电子邮件通知，系统消息，图像上传等等。 -## 技能：SRE 是一个印章团队和圣职 +为了使消息入队，我们使用了 PHP-FPM 提供的最酷的功能之一，即 fastcgi_finish_request（）函数。 这使我们能够以异步方式将消息发送到队列。 在生成必须发送给用户的 HTML 或 JSON 响应后，我们将调用该函数，这意味着用户不必等待我们的 PHP 脚本清理完毕，例如关闭 Memcached 连接，DB 连接等。 同时，所有保存在内存数组中的消息都将发送到 RabbitMQ。 这样，用户也不必等待。 -* 本节的标题是我的描述。 具有技能的 SRE 必须是精英。 在工作方面，他们仅致力于这种几乎准神秘的事物，称为生产。 +我们有两台专用于处理这些消息的机器，目前总共运行 40 个 PHP 进程以消耗作业。 每个 PHP 进程消耗 250 个工作，然后死亡并重新生成。 我们这样做是为了避免 PHP 出现任何形式的垃圾回收问题。 将来，我们可能会增加每个会话消耗的作业数量，以提高性能，因为事实证明重新分配 PHP 进程会占用大量 CPU。 -* SRE 必须比开发人员更熟练，才能完成相同的工作： +该系统使我们可以改善资源管理。 例如，在高峰时间，我们甚至每分钟可以登录 1000 次。 这意味着我们将对 users 表进行 1000 个并发更新，以存储用户的上次登录时间。 因为现在我们使这些查询入队，所以我们可以依次依次运行每个查询。 如果我们需要更高的处理速度，我们可以将更多的使用者添加到队列中，甚至可以将机器加入集群中，而无需修改任何配置或部署任何新代码。 - * 他们需要更大的技能范围。 +### CouchDB - * 所有 SRE 必须通过完整的软件开发人员面试才能被录用。 +为了存储日志，我们在一台计算机上运行 CouchDB。 从那里我们可以按模块/动作查询/分组日志； 事实证明，发现问题出在哪里很有用。 在将 CouchDB 用作日志聚合器之前，我们必须在每台 PHP 机器上登录并拖尾-f，然后从那里尝试找出问题所在。 现在，我们将所有日志中继到队列，然后使用者将它们插入 CouchDB。 这样，我们可以在集中的地方检查问题。 - * 所有 SRE 必须通过一次非抽象的大型系统设计采访。 +### 石墨 -* SRE 必须具有相同的软件技能，这是不同的应用领域。 +我们使用[石墨](http://graphite.wikidot.com/)从网站收集实时信息和统计信息。 从每个模块/动作的请求到 Memcached 命中/未命中，RabbitMQ 状态监视，服务器的 Unix 负载等等。 Graphite 服务器每分钟进行约 4800 次更新操作。 实践证明，该工具对于查看站点中的实际情况非常有用。 它是简单的文本协议，其图形功能使它易于使用，几乎可以即插即用到我们要监视的任何系统。 - * 开发人员专心于产品经理并制作功能。 +我们使用 Graphite 做的一件很酷的事情是监视同时运行的网站的两个版本。 去年一月，我们部署了由新版本的 symfony 框架支持的代码。 这意味着我们可能会遇到性能下降的情况。 我们能够在一半的服务器中运行该站点的一个版本，而新版本则在其他服务器中运行。 然后，在 Graphite 中，我们为每半创建 Unix 负载图，然后进行实时比较。 - * SRE 依赖于生产，以使生产达到最佳状态。 +由于我们发现新版本的 Unix 负载较高，因此我们启动了 XHProf 分析器并比较了这两个版本。 我们使用 APC 存储“标志”，这些标志使我们可以启用/禁用 XHProf，而无需重新部署代码。 我们有一个单独的服务器，在其中发送 XHProf 配置文件，然后从那里汇总它们并进行分析，以找出问题所在。 -* **当将面向开发和面向生产的观点结合在一起时，最终的设计会更强大**。 +### 红色 5 -* 入职流程示例给出了 SRE 带来的一个示例，该过程在将团队的项目置于 SRE 的责任之下时发生。 在评估团队的软件时，他们发现： +我们的网站还向用户提供视频。 我们有两种。 一种是来自用户配置文件的视频，这些视频是用户制作和上传的电影。 此外，我们还有一个视频聊天功能，可让我们的用户互动并分享他们的视频。 在 2009 年中，我们每月向用户流式传输 17TB 的视频。 - * 当达到规模时，它将在生产中失败。 +### 宗宗 - * 开发人员已隐式假定某种呼叫不会失败。 +Tsung 是用 Erlang 编写的分布式基准测试工具。 我们使用它来进行 HTTP 基准测试，并比较我们计划使用的 MySQL 的不同存储引擎，例如新的 XtraDB。 我们有一个工具可以记录到主 MySQL 服务器的流量，并将该流量转换为 Tsung 基准测试会话。 然后，我们重播了这些流量，并通过 Tsung 生成的数千个并发用户访问了实验室中的计算机。 很棒的事情是，我们可以产生更接近实际生产环境中发生情况的测试方案。 - * 他们假设请求的分配是均匀的。 +## 得到教训 - * 他们以为不会受到用户的关注。 +* 虽然面向 Buzz 的开发很酷，但**仍在寻找具有重要社区的工具**。 当有问题需要解决时，或者需要将人员纳入团队时，文档和良好的社区将非常宝贵。 symfony 规定，可以免费获得 5 本以上的官方书籍。 CouchDB 和 RabbitMQ 的开发人员也提供了良好的支持，它们具有活跃的邮件列表，可以及时回答问题。 +* **了解您正在使用什么以及这些系统/库的局限性是**。 我们从 symfony 中学到了很多东西。 可以在哪里进行调整以及可以改进什么。 就 PHP-FPM 而言，我们可以这么说，只是通过阅读文档，我们发现强大的 fastcgi_finish_request（）函数被证明是非常有用的。 另一个例子是 Nginx，Nginx 社区已经解决了一些问题，例如我们对图像存储缓存的解释。 +* **扩展工具**。 如果他们运行良好，则无需在当前堆栈中引入新软件。 我们已经编写了几个 Nginx 模块，这些模块甚至已经被 Nginx 社区测试过。 这样，您可以回馈。 +* **D** **对于无关紧要的**并不保守。 石墨似乎是在生产中运行的一种很酷的工具，但是关于它的报道并不多。 我们只需要尝试一下。 如果它不起作用，我们可以禁用它。 如果我们无法在系统中得到一个很好的 Unix Load 图，谁也不会哭。 今天，甚至我们的产品经理都喜欢它。 +* **测量所有**：Unix 负载，站点使用情况，Memcached 命中率/丢失率，每个模块/动作的请求等。学习解释这些指标。 +* **创建工具，使您可以尽快对问题做出反应**。 如果您必须回滚部署，那么您不想花费一秒钟以上的时间。 +* **创建工具，使您可以实时分析网站的情况**。 在实验室中，大多数测试都给出了乐观的信息，但随后却无法应对生产负荷。 - * 他们假定所有请求的大小均处于平均水平。 +## 未来 - * 他们在两条尾巴上失败了（没有给出解释）。 +* 构建一个新的，更具可伸缩性的消息系统，因为当前版本相当旧，并且并非针对如此大量的消息而设计。 +* 将越来越多的处理任务移至队列系统。 +* 将更多的 Erlang 应用程序添加到我们的系统中。 事实证明，RabbitMQ 对我们和 CouchDB 都适用。 它们是易于安装和部署的系统，从而增加了我们对 Erlang 作为语言/平台的信任。 +* 我们正在寻找 Red5 的替代产品，可能是用 Erlang 编写的 Oneteam Media Server。 目前，当我们使用开源 Erlang 产品时，我们可能会开始使用该语言编写我们自己的应用程序，因为现在我们已经有了使用它的经验。 +* 改进我们的日志可视化工具。 -## 组织：为开发人员提供不让运营工作积聚的理由 +我要感谢 Alvaro Videla 的出色写作。 如果您想共享 fablous 系统的体系结构，请 [与联系我](http://highscalability.com/contact/)，我们将开始。 -* 该系统必须设计为不增加运营工作，因为如果开发人员不从事工作，他们将不会那么在意。 +让我们做数学。 每分钟有 15 万个请求到 www。*，这意味着每秒有 2500 个请求。 +他们有 28 个 PHP 框，每个框有 100 个进程。 这意味着 2800 个 PHP 进程。 +您需要尽可能多的 PHP 进程来处理并发请求（不是每秒）。 这意味着它们的脚本要么花费 1 秒来执行每个脚本，要么它们有很多方法可以执行。 +不管哪种方式，东西都坏了。 -* **SRE** 的开发预算。 如果您的系统的运营开销很大，那么您获得的开发人员就不会那么多，那么您就无法推广那么多的功能。 +我知道有使用 2-4 台服务器使用 PHP 满足此请求数量的网站。 不是 28。 -* SRE 具有完全不同的命令链。 他们有自己的副总裁，与开发副总裁分开。 这赋予了他们权力和权力。 当生产意味着他们需要拒绝时，它允许他们说不。 一堆不是的传呼猴子。 +Quote： +**此系统使我们可以改善资源管理。 例如，在高峰时间，我们甚至每分钟可以登录 1000 次。 这意味着我们将对用户表进行 1000 个并发更新，以存储用户的上次登录时间** -* 当开发人员说他们可以捐赠人数时，SRE 不必接受。 SRE 可以说服务不够重要，请自己继续提供支持。 +不，这并不意味着您有 1000 个并发更新。 这意味着您每秒大约有 16 次登录，这意味着您可能有 10-20 次并发更新。 大多数时候少很多。 -* SRE 是一种稀缺资源。 并非 Google 的每个团队都有 SRE。 云确实可以，但是不是每个其他团队，甚至不是云中的每个小服务，都只是重要的。 +还要注意，它们有 50 个 memcached 节点。 他们必须处理多少台服务器来处理这种中等负载？ 太疯狂了 -## 环境：如何使开发人员在生产团队中保持快乐？ +结论：并不令人印象深刻，我还没有看到任何新见解。 我对他们的代码的效率提出了很多质疑。 -* **至少有 50％的工作需要为项目工作**。 不待命。 不是门票。 不开会。 实际上是在做项目工作。 +您好 Alvaro，感谢您对体系结构的有趣了解。 我提出了两个问题：-如何衡量并发用户（超时？），为什么使用这么小的数据集使用如此多的节点进行内存缓存？ 问候，保罗 -* 如果项目工作量过多，则开发人员会为 SRE 分配更多的人员，或者将额外的工作流转给开发人员团队。 +您可以提供指向 Graphite 的链接吗？ 听起来很有趣，我们已经开始研究这些系统，但是它的含义如此普遍，以至于简单的 Google 都无法提出我认为正确的任何东西。 -* 什么是项目工作？ +可以在 [http://graphite.wikidot.com/](http://graphite.wikidot.com/) 上找到石墨网站。 - * 通过切换基础数据库技术来改善服务的延迟。 +@霜： - * 编写自动化以加速部署。 +-对 poppen.de 的 150.000 请求并不意味着它们全部都到达了 PHP 后端。 - * 跨服务的项目。 Google 作为一项内部服务，可以由其他服务（通常由软件 bot）在内部进行查询，如果可以安全地将计算机停机，可以安全地将机架停机或者将数据中心安全地停机，则可以返回 Google ？ +“我知道使用 2-4 台服务器使用 PHP 满足此请求数量的站点。不是 28 台。” 这取决于他们做什么，他们缓存了什么，可以从请求中缓存多少。 它们显示多少个局部分量？ 网站信息是否完全动态？ 问题列表可以继续。 除此之外，我们将平均负载保持在较低水平，并且我们有足够的服务器来满足计划的增长。 -* SRE 是一支志愿军。 没有草稿。 +除此之外，当您建立网站时，您还必须做出商业决策。 不像您选择有关网站编程理论的最佳书籍。 在我们的例子中，我们使用框架和 ORM。 这使我们发展很快。 您也必须考虑到这一点。 我了解到，在不了解其他公司背后的背景的情况下很难谈论它们。 - * 您可以随时转入另一个 SRE 团队。 +关于对数据库和登录号的并发查询，您是对的，我在编号上犯了一个错误。 我向读者道歉，因为他们提供了误导性的信息。 另一方面，我希望您和该站点的其他读者能够理解使用队列服务器可以完成的工作。 如果您已经知道了这一点，并且不需要向我学习，那么对您会更好。 我希望这对至少一名开发人员有用。 - * 您可以随时转换为 dev。 +50 个 Memcached 节点并不意味着有 50 个专用计算机。 - * Mission Control 是一个程序，开发人员可以在其中试用 SRE 并查看他们是否喜欢它。 +@保罗 p： -* 团队很流畅。 人们来自团队，分享经验，分享观点。 +我们有一个“谁在线”服务器来跟踪在线用户。 它使用超时将其标记为已注销。 -## 预算：您可以支出任意预算的错误预算 +我们使用几个 Memcached 节点，因为根据要缓存的内容，我们有专门的存储桶。 例如，我们有视图缓存，用于缓存模板。 函数缓存，用于将查询缓存到数据库。 然后，一个 Memcached 专门将查询缓存到一个表等。这样，一个 memcached 的使用不会影响其他表。 -* 如果您有 3 个 9 的可用性，目标是不将其提高到 4 个 9，那么您的错误预算为.1％。 +@理查德： -* **如果您想更快地推出功能并使 GCP 变得更好，那就去做吧。 直到用尽错误预算。** +http://graphite.wikidot.com/ -* 如果您希望进行较差的测试，使软件定期出现故障并且必须不断回滚，那么您也可以选择该选项，但是错误预算很快就会用光，并且您将无法启动 。 +嗨，阿尔瓦罗 我想向您介绍一个更好的流服务器： [erlyvideo](http://erlyvideo.org) ，值得测试，在您的情况下它将处理多少用户（对我来说，它可以从一台计算机上支持 1800 个连接）。 -* 错误预算按季度循环。 +如果需要，请写 [[受电子邮件保护]](/cdn-cgi/l/email-protection) 。 -* 有一个逃生阀：三枚银子弹。 +>我们希望按用户 ID 对数据进行分区，因为网站上的大多数信息都以用户本身为中心，例如图像，视频，消息等。 - * 一个开发人员可以说我真的需要推动，请给我一个银弹。 +哼...这很有趣...会不会创建太多分区？ 我对 Mysql 不太熟悉，但是我正在研究的那个 MySQL 建议我们不要创建超过 2000 个分区。 - * SRE 会说“ OK”，但您必须说服 VP 您实际需要推动。 +但是，在用户 ID 上进行分区将意味着几个 100K +分区。 - * 这个仪式听起来很愚蠢，但功能非常强大。 它将控制权交给开发人员。 他们有 3 个灵丹妙药，由他们的副总裁来决定是否合适。 +@Alvaro： -* 错误预算基于每个服务。 因此，如果多个开发团队使用相同的服务，则它们共享相同的预算。 +因此，如果他们甚至不使用 PHP，那么我更正确的是您的脚本太慢，进程太多。 但这不是真正的问题。 - * SRE 不在交战的开发团队中间。 他们必须弄清楚如何花费错误预算。 +我正在谈论的站点具有很多动态内容，但是缓存非常聪明，而且它们不使用任何框架或 ORM 包装器。 +这就是我认为您可能损失 90％的性能的地方，这些东西往往是绝对的性能杀手。 +当然，您可以在开发时间上获得一些优势，但是一旦达到一定的规模，就会希望您没有走这条路。 +为使用更智能查询和缓存的对象编写一些类并不难。 -* 机外。 如果所有其他方法都失败了，并且开发人员和 SRE 确实不同意，则 SRE 可以派遣开发团队。 +您的前端有 2.5k re / s，memcached 可以提供 133 re / s。 这是否意味着您的缓存命中率为 5％？ - * 像和睦的离婚。 +而且请不要使用“每分钟的请求数”，没有人对规模感兴趣。 它主要是“每秒请求数”，突然之间您的数字似乎不再那么大了，因为它只有 60 分之一。 - * 这是至关重要的逃生阀门，因此团队在很长一段时间内都不会出现令人讨厌的分歧。 +@Abhishek： - * 很少见，但确实发生了。 一个示例场景是，如果团队不想在其 ACID 类型项目中使用 Spanner，如果开发团队说他们想建立自己的团队，那么 SRE 团队可以说他们不想为团队提供支持。 去建立自己的数据库，因为这对生产不利。 +他没有说每个用户一个分区，而是说了按用户 ID 划分的分区。 这并没有暗示有关分区大小的任何信息。 每个分区可以是 100 个用户或 100 万个用户。 它仅告诉您使用哪个键来决定将值存储在哪个分区中。 +同样，这与 MySQL 本身无关。 你在做什么？ 还有 2000 个分区？ 是，对.. -* SRE 是 google.com 和 GCP 的生产托管人，SRE 是客户体验的托管人。 +有趣。 +您使用任何类型的虚拟化/云服务还是全部物理硬件？ 任何 CDN？ +什么操作系统/发行版？ -## SRE 支持在频谱上 +阿尔瓦罗 -* 聊天和咨询。 与开发人员聊天。 进行白板会议。 +很棒的帖子。 我认为阅读和查看如何解决许多问题很有趣。 关于石墨也不错的技巧。 -* 协同设计。 与开发人员一起创建设计。 +此致 +尼克拉斯 -* 完全所有权。 完全拥有的服务。 所有容量，所有供应，所有页面。 +嗨，阿尔瓦罗。 您说过您正在使用 memcached 来缓存诸如用户个人资料之类的视图组件。 您能否说明有关如何使这些视图缓存无效的更多详细信息？ -* 页面是保持诚实的一种方式。 它们不是 SRE 的目的。 +我了解您在更改数据时编写了自己的代码来使“数据缓存”无效。 但是对于视图缓存，有很多数据，任何数据更改都将使该视图缓存无效。 你是怎样做的？ - * 负责制作的人应该抓这些页面，因为这样可以使他们的皮肤保持游戏中的外观。 +我的第一感觉：太多的 PHP 服务器。 我认为在这种情况下，Symfony 对于他们来说 PHP 框架太慢了。 从我的经验中得知，Symfony 吃了很多 CPU。 - * 它还有助于使 SRE 的技能，专长和观点保持最新。 +我真的认为他们应该用更具扩展性和轻量级的 PHP 框架取代 Symfony -## 是什么让事情顺利进行？ 文化和过程 +@Max Lapshin -* Google 会进行常规的培训和通话阴影处理。 +感谢您对 Erlyvideo 的提示，几个月前我们也对此进行了调查。 我们尚未决定。 -* Google 也有一个名为：**不幸轮盘**的过程-卷轴游戏。 +@Maxim R - * 一个人是地牢大师，他们有一个受害者，团队轮流尝试猜测发生了什么。 +我们使用 EC2 进行视频传输，其他系统则托管在我们的物理服务器中。 服务器正在运行 SLES10。 - * Google 运行非常复杂的系统。 除了进行培训的人之外，很少有人真正知道发生了什么以及答案是什么。 +@尼尔·H - * 这对新的来电者很有用。 让他们在受控环境中进行测试。 +我们对键进行“命名空间”，因此可以立即使相关的键集失效。 但这取决于网站的哪一部分。 因此，在这里很难解释所有这一切。 参见此处，了解许多常见模式：http://code.google.com/p/memcached/wiki/FAQ - * 一些团队在某些场景中会破坏生产并让新手对其进行修复。 +@pcdinh - * 对退伍军人也有好处。 最好重新整理您的知识，尤其是在使用非常复杂的系统时。 +如果您是 http://twitter.com/pcdinh，那么我可以告诉您，我们不使用 16 核 Dell / HP 之类的计算机。 我们使用具有 8 核的 6G Ram 的旧刀片服务器。 除此之外，我们将这些机器的平均负载保持得非常低。 -## 事件管理 +然后，关于 symfony 或任何 PHP 框架，尽管它们不是比普通的 PHP 代码或更轻量级的框架最快的解决方案，但速度并不是选择框架时唯一考虑的问题。 symfony 拥有强大的支持，强大的社区和大量文档。 这意味着我们可以轻松雇用已经知道我们所使用技术的人员。 那么，如果我们使用超快速的自定义框架，然后编写它的“黑客”离开了公司，会发生什么呢？ 谁来维护他的代码？ 从理论上讲，您关于迁移到另一个框架的建议听起来不错，但是您知道将站点代码移植到另一个框架可能需要花费几个月的时间吗？ 我们还必须支付开发人员的薪水，而在大多数情况下，这些薪水都比其中一台刀片服务器贵。 因此，正如我在之前的回答中所说，公司会做出业务决策，而不仅仅是因为速度快而选择了这种框架。 -* 场景：您正在呼叫 gmail，并且您获得了一张票证，用户可以看到其他用户的电子邮件。 你是做什么？ 关闭 gmail。 +因此，请不要将服务器数量归咎于 symfony，因为虽然 yes 比普通的 PHP 代码重，但这不是我们使用那么多服务器的原因。 如果不是，那为什么要使用 PHP？C 的速度要快得多。 -* **Oncallers 被完全授权采取一切措施来保护用户，保护信息，保护 Google。** 如果这意味着要关闭 gmail 甚至关闭所有 google.com，那么作为 SRE，您的副总裁将为您提供支持，而您的 SVP 将为保护 Google 提供支持。 +Alvaro，我绝不会质疑您的基础架构，因为您比这里的其他任何人都了解它，尤其是其中一些“扶手椅系统架构师”。 :) +但是该语句 -* **目标是立即恢复服务。 故障排除将在稍后进行。** +> 我们还必须支付开发人员的薪水，而在大多数情况下，这些薪水都比其中一台刀片服务器贵。 - * 有二进制状态的记录。 有日志。 +can lead you into a corner. you can throw money at hardware only for so long until your investment start to produce diminishing returns and your infrastructure becomes too unwieldy and then it'll be that much harder to do any meaningful code changes. - * 醒着，开发人员在办公室，所有人都在时，请进行故障排除。 目的是使服务重新启动并运行。 +保持服务器负载“ *非常*低”又有什么意义呢？ 如果服务器在可接受的时间内返回数​​据，负载是多少（故障或严重超载除外）有关系吗？ -## 你该怪谁？ +听起来您所有的服务器都在内存缓存池中。 我很好奇，PHP 服务器具有更大的 APC 缓存大小而不是将其用于内存缓存会更好吗？ -* 当“新开发者”推送代码并破坏 google.com 达三个小时时，您应该对谁负责？ a）新开发者 b）代码审查。 c）缺乏测试（或被忽略）的测试。 d）缺乏针对代码的适当的金丝雀程序。 e）缺乏快速回滚工具。 +@马克西姆 R. - * 除了新开发者以外的所有东西。 **如果新开发人员编写的代码会导致该网站瘫痪，那不是开发人员的错。 这是开发人员和工作人员之间所有关口的错。** +感谢您的见解。 我同意你的看法。 不是说您去硬件上花钱，应该有一个平衡点。 我们也会在可能的情况下尝试改进代码。 e .：每当我们向站点功能添加功能时，我们都会尝试提高性能，重构代码等，因为我们需要在腐烂之前对其进行维护。 我们正在开发一种用于 SQL 查询的轻量级解决方案，根据我们的基准测试，该解决方案将减轻站点的大量负载，因为我们可以删除我们使用的 ORM，这是很沉重的。 我们的网站在不断发展，我们正在像每个人一样从错误中学习。 - * **绝对不允许人为错误传播到人外。** 查看允许部署损坏的代码的过程。 +关于平均负载语句，我说过，因为对于某些评论者来说，我们有 28 台完全过载的计算机。 除此之外，我们拥有这些机器是因为我们正在计划未来的增长，如果一切都按计划进行，那么到将来我们的意思是迫在眉睫。 -## 无罪的岗位形态 +关于 APC 与 Memcache。 我们必须考虑更多。 有时我们讨论的与您刚才所说的相同。 同时，一些经验丰富的 PHP 开发人员告诉我，APC 在拥有大量 RAM 时不能很好地工作。 我没有与此相关的经验可以发表意见。 另外，APC 缓存不共享，如果这也是一个问题，我们必须考虑。 我们也将一些计算缓存到 APC 中。 -* 避免责备文化至关重要。 +阿尔瓦罗 -* 研究表明，大多数事件是人为错误引起的。 +感谢**很棒的文章**！ 我对您的 nginx 和 memcached 有一个问题。 您写道，许多请求甚至都没有达到 PHP，因为 Nginx 从 memcached 获取了缓存的内容-您能再描述一下吗？ 您是否缓存 HTML 页面？ -* **最好通过了解实际发生的事件来解决事件。** 不知道发生了什么的最好方法？ 通过寻找责任人来揭开每一个事件。 +问候， -* 人们真的很擅长隐藏，并确保没有线索，并确保您实际上不知道发生了什么。 试图怪罪只会使您的工作更加困难。 +@阿尔瓦罗 -* 在 Google 谁搞砸了谁写的事后验尸。 这样可以避免命名和遮挡。 使他们有能力纠正错误。 促成失败的每个人都应尽可能诚实地参与进来，并写下您如何陷入困境。 +Erlyvideo 发展非常迅速。 几个月前，您可以看到它的前一代，什么也做不了。 因此，如果您有兴趣，最好通过电子邮件进行交流。 -* 已在全体会议上给予拆除该站点的奖金，因为他们立即拥有该站点，因此他们拥有了该站点。 他们上了 IRC，并将其回滚。 他们说出来并如此迅速地照顾好他们，便获得了奖金。 ++1 感谢您的精彩文章！ -* 无赖并不意味着没有名称和细节。 这意味着我们不会因为事情出错的原因而选择别人。 不应发生诸如断电之类的事情，应予以解雇。 +Alvaro，我认为您应该尝试 Erlyvideo-它在 Erlang 中很烂，而且发展非常迅速。 我认为，erlyvideo 的作者 Max Lapshin（привет，Макс:)可以提供支持并实现所需的所有功能。 -* 深度防御 +Alvaro，您尝试过 Facebook 的 HipHopPHP 编译器吗？ - * 由于策略是纵深防御，因此事后评估模板将操作分为预防，检测和缓解措施。 +> 我发现最有趣的是他们如何成功地将一些旧的和一些新的 - * **我们希望防止中断，我们希望更快地检测到它们，并希望减轻影响。** +不，他们没有成功地将新旧融合在一起。 +poppen.de 以运行缓慢而闻名。 它几乎从来没有真正快过，而且每隔几（6-8）周就会额外减速至少几小时，通常是 1-2 周。 +当前的缓慢周期自大约 6 周开始，至今仍未结束。 poppen.de 的性能给 a * s 带来了痛苦。.远非成功... - * 如果类似的情况再次发生，它将不会传播到很远，持续太久或影响那么多的客户。 +> 我们有 2 个前端 Nginx 服务器 -## 分页的无聊哲学 - -* 团队喜欢看什么样的页面？ 新的和有趣的。 - -* 您知道如何解决的页面很无聊。 您应该创建一个机器人来解决该问题。 - -* Google 发明了许多机器人。 他们不喜欢无聊。 - -* 如果您可以写下修复它的步骤，那么您可能可以编写自动化来修复它。 - -* 不要做机器人可以为您做的事情。 - -* 构建漫游器的结果是，理想情况下，每个页面都是全新的，因此不会感到无聊。 甚至经验丰富的工程师也可能在每次寻呼机关闭时都看到一些新内容。 - -* **这是哲学的根本变化。 如果一切正常，重复的事件很少，则意味着您在调试系统时不会像以前那样沉迷于此。** - -## 需要更强大的调试工具 - -* **如果所有问题都是新问题，则意味着您需要更强大的调试工具来查找问题。** - -* 文本日志不是调试工具。 如果您不知道要查找的内容，则无法在日志文件中查找模式的标准调试无法进行。 使用 GCP 大小的平台，您需要浏览多少个外观才能找到失败的外观？ - -* Google 严重依赖于各种可视化工具来解决不熟悉的问题并尽快恢复服务。 - -* 绘图工具：石墨，InfluxDB + Grafana，OpenTSDB。 - - * 这些和其他提到的工具不是 Google 使用的工具，因此不建议使用，但它们是有用工具的开放源代码示例。 - - * 很高兴看到正在发生的一切。 Google 拥有数十亿亿个流程，因此您需要汇总视图才能理解事物。 - - * **Google 在其二进制文件中放置了很多工具。** 在新情况下，您并不总是知道您要寻找的东西。 - -* 创建一个框架，使开发人员可以轻松地插入监视框架。 - -* 大量存储空间专门用于存储监视数据。 - - * **的想法是，您不想在中断期间进行故障排除。 中断仅与恢复服务有关。** - - * 故障排除是您稍后醒来时要执行的操作。 开发人员经常参与故障排除过程，因为他们对系统有更深入的了解。 - - * 历史数据必须可用，以便故障恢复后可以进行故障排除。 恢复不会导致中断监视数据丢失。 - - * 这种方法可以使停机时间尽可能短，同时可以在以后解决问题。 - -* 事件绘图-对于关联事件非常有用。 - - * 充分利用人类的模式匹配能力，很难编写机器人来做到这一点。 - - * 给出了一个图表示例，其中每行是一个数据中心，列是时间，单元格中的颜色是事件类型。 - - * 这可以帮助您找到不是单个事件的模式，例如导致级联故障的软件推出，或者一起重复出现的错误簇，或者如果您看到延迟尖峰之后立即出现错误尖峰 重复一遍。 这些都将有助于确定问题的根本原因。 - -* 可视化过程跟踪-有时您需要深入到过程级别以识别性能问题。 - - * 开源选项不多：Performance Co-Pilot + vector。 - - * Google 有一个非常复杂的框架，可将示例查询拉入存储并提供完整的跟踪记录。 - - * 可视化工具的优点是很难理解时间戳。 可视化工具使您可以更轻松地折叠，展开和比较事件。 - -* 网络流量和容量 - - * 开源选项：仙人掌，天文台和 Nagios - - * 事实证明，很多存储缓慢的问题实际上是网络问题。 - - * 如果您正在查看存储系统，但无法弄清为什么它对网络的访问速度很慢。 - - * 您需要一个工具来快速查看网络状态。 哪些链接超载？ 您看到多少个包错误？ 链接断开了吗？ - -* 日志文件-当所有其他失败时 - - * 开源：ElasticSearch + Logstash（+ Kibana） - - * 您不想遍历日志文件。 您需要一个具有更多类似查询的 SQL 的系统，以便您可以挖掘日志。 - - * 日志应易于使用且易于理解。 - -## Stackdriver 错误报告 - -* 如果您想看看 SRE 所拥有的那种工具的例子，那么请看 [Google Stackdriver 错误报告](https://cloud.google.com/error-reporting/) 。 - - * 这是他们能够用于服务的内部工具。 - - * 通过分析堆栈跟踪将分组错误并进行重复数据删除 - - * 系统了解所使用的通用框架并相应地对错误进行分组。 - -* 该计划将做更多。 Google 内部拥有广泛的工具，他们希望向云客户提供这些工具。 - -## 相关文章 [ - -* [在 HackerNews](https://news.ycombinator.com/item?id=12116121) 上/ [在 Reddit](https://www.reddit.com/r/programming/comments/4tg31p/how_does_google_do_planetscale_engineering_for_a/) 上 -* 图书：[网站可靠性工程：Google 如何运行生产系统](https://www.amazon.com/Site-Reliability-Engineering-Production-Systems-ebook/dp/B01DCPXKZ6)。 它是由从事实际 SRE 工作的实际 Google SRE 编写的，是作者 500 年综合经验的结果。 -* [大规模计算，或者说 Google 如何扭曲我的大脑](http://matt-welsh.blogspot.com/2010/10/computing-at-scale-or-how-google-has.html) -* [网站可靠性工程师-使 Google 保持 24/7 全天候运行](http://transcriptvids.com/v2/yXI7r0_J29M.html) -* [服务水平和错误预算](https://www.usenix.org/conference/srecon16/program/presentation/jones) -* [SREcon](https://www.usenix.org/conference/srecon16) 。 会议视频[可用](https://www.usenix.org/conference/srecon16/program)。 看起来内容很多。 -* [小组：谁/什么是 SRE？](https://www.usenix.org/conference/srecon16/program/presentation/definition-of-sre-panel) -* [策略：规划停电的 Google 样式](http://highscalability.com/blog/2010/3/5/strategy-planning-for-a-power-outage-google-style.html) -* [Google 如何备份互联网以及 EB 级其他数据](http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html) -* [什么是“网站可靠性工程”？](https://landing.google.com/sre/interview/ben-treynor.html) -* [成为 Google 的网站可靠性工程师（SRE）感觉如何？](https://www.quora.com/What-is-it-like-to-be-a-Site-Reliability-Engineer-SRE-at-Google) -* [我的警惕](https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/preview#)的哲学，作者：Rob Ewaschuk，Google SRE -* [这是 Google 确保（几乎）永不衰败的方式](http://www.wired.com/2016/04/google-ensures-services-almost-never-go/) - -FWIW，Stack Driver 并不是他们能够用于服务的内部工具； 这是 Google 购买的 SaaS 创业公司。 - -https://techcrunch.com/2014/05/07/google-acquires-cloud-monitoring-service-stackdriver/ \ No newline at end of file +Alvaro, are these 2 servers in a master/master setup? Which is the solution to make them highly available/load balanced? Regards \ No newline at end of file diff --git a/docs/48.md b/docs/48.md index 4f9c223..e6ac0f7 100644 --- a/docs/48.md +++ b/docs/48.md @@ -1,241 +1,122 @@ -# Facebook 如何向 80 万同时观看者直播 +# MocoSpace Architecture-一个月有 30 亿个移动页面浏览量 + +> 原文： [http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html](http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html) + +![](img/11ff48d533ea1c680de217f81e0e152a.png) + +这是 [MocoSpace](http://www.mocospace.com/) 的联合创始人&首席技术官 Jamie Hall 的客座帖子，描述了他们的移动社交网络的体系结构。 这是一个及时的体系结构，因为它结合了多个热门趋势：它非常大，具有移动性和社交性。 他们认为对他们的系统特别酷的是：如何针对移动 Web 上的设备/浏览器碎片进行优化； 他们的多层，读/写，本地/分布式缓存系统； 选择 MySQL 之上的 PostgreSQL 作为可扩展的关系数据库。 + +MocoSpace 是一个移动社交网络，每月有 1200 万会员，页面浏览量达 30 亿，这使其成为美国流量最高的移动网站之一。 成员主要通过其手机 Web 浏览器访问该站点，从高端智能手机到低端设备以及 Web 都可以访问。 该网站上的活动包括自定义配置文件，聊天，即时消息，音乐，共享照片&，视频，游戏，电子贺卡和博客。 获利策略的重点是在移动和网站上投放广告，以及虚拟货币系统和少量高级功能升级。 + +## 统计资料 + +1. 每月 30 亿页面浏览量 +2. 仅次于 MySpace，Facebook 和 Google（http://www.groundtruth.com/mobile-is-mobile）的流量最大的 4 个移动网站 +3. 75％的行动网路，25％的网路 +4. 1200 万会员 +5. 每月 600 万唯一身份访问者 +6. 10 万个并发用户 +7. 每月上传 1200 万张照片 +8. 每天收到 200 万封电子邮件，垃圾邮件 90％，每天发送 250 万封 +9. 8 位开发人员，2 位质量检查人员和 1 位系统管理员组成的团队 + +## 平台 + +1. CentOS +红帽 +2. 树脂应用服务器-Java Servlet，JavaServer Pages，Comet +3. PostgreSQL 的 +4. 记忆快取 +5. ActiveMQ 的工作+消息队列，在 Red Hat 集群中以实现高可用性 +6. Squid-静态内容缓存，尝试使用 Varnish 但存在稳定性问题 +7. jQuery + Ajax +8. S3 用于用户照片&视频存储（8 TB），EC2 用于照片处理 +9. F5 BigIP 负载平衡器-粘性会话，所有页面上的 gzip 压缩 +10. Akamai CDN-每天 2 TB，每天有 2.5 亿个请求 +11. 监视-Nagios 发出警报，Zabbix 发出趋势 +12. EMC SAN-通过 RAID（RAID 10）大量磁盘为数据库提供高 IO 性能，用高性能 Fusion-io 固态闪存 ioDrive 代替，成本效益更高 +13. PowerMTA 用于邮件传递，梭子鱼垃圾邮件防火墙 +14. Subversion 源代码控制，Hudson 进行持续集成 +15. FFMPEG 用于移动到 Web 和 Web 到移动视频的转码 +16. 用于浏览器测试用例自动化的硒 +17. 网络层 + 1. 5 个 Dell 1950、2 个双核，16G RAM + 2. 5 个 Dell 6950 / R905、4 个双核，32G RAM +18. 数据库层 + 1. 2 个 Sun Fire X4600 M2 服务器，8 个四核，256G RAM + 2. 2 个 Dell 6950、4 个双核，64G RAM + +## 建筑 + +1. 所有页面都是动态的，具有用户数据和自定义以及许多针对浏览器和设备的优化。 移动设备上的浏览器和设备碎片问题比 Web 上的问题要严重得多。 许多优化，基于浏览器功能的改编，对 CSS / JavaScript 的有限支持，屏幕尺寸等。移动 Web 流量通常通过网络代理（网关）提供，而对 Cookie 的支持较差，因此会话管理和用户标识成为一个挑战。 +2. 一个巨大的挑战是处理移动 Web 上的设备/浏览器碎片-为各种设备功能进行优化（从带触摸屏的 iPhone 到 5 岁摩托罗拉 Razrs 的所有产品），屏幕尺寸，缺乏/不一致的 Web 标准合规性等。 我们将表示层抽象出来，以便我们可以从同一代码库向所有移动设备提供页面，并维护一个大型设备功能数据库（包含诸如屏幕尺寸，支持的文件类型，最大允许的页面尺寸等内容），用于 推动我们网页的生成。 该数据库包含数百种设备和移动浏览器类型的功能详细信息。 +3. 根据用户密钥对数据库进行分片，并具有将用户映射到分片的主查询表。 我们滚动了自己的查询和聚合层，使我们可以跨碎片查询和联接数据，尽管这种方式并不经常使用。 通过分片，我们可以牺牲一些一致性，但是只要您不经营银行就可以。 我们分批离线进行数据一致性检查，目标是最终实现一致性。 大表被分成较小的子表，以提高访问效率，减少了为更新和操作维护活动而锁定表的时间。 用于热备份的日志传送。 +4. 使用了多层缓存系统，数据在应用程序服务器中本地缓存，并通过 Memcached 分发。 进行更新时，我们不仅使缓存无效，然后在再次从数据库中读取后重新填充缓存，而是使用新数据更新 Memcached 并保存另一次数据库访问。 更新缓存时，无效指令会通过消息队列发送到每个应用程序服务器上的本地缓存。 +5. 分布式消息队列用于分布式服务器通信，从用户之间实时发送消息到系统消息（例如本地缓存无效指令），应有尽有。 +6. 专用服务器，用于完全在内存中构建和遍历社交图，用于生成好友推荐等。 +7. 负载平衡器，用于在不影响性能/流量的情况下滚动部署网站的新版本。 +8. 每 2 周发布一次。 较长的发布周期=指数复杂性，更难进行故障排除和回滚。 负责部署和管理生产系统的开发团队（由您构建，管理）。 +9. Kickstart 用于自动从裸机构建服务器。 Puppet 用于将服务器配置为特定的个性，即 Web 服务器，数据库服务器，缓存服务器等，以及将更新的策略推送到正在运行的节点。 + +## 得到教训 + +1. **让您的箱子流汗**。 只要响应时间可以接受，就不要担心系统负载过大。 我们将多达五个应用程序服务器实例包装在一个盒子中，每个实例在不同的端口上运行。 在扩展之前，请先扩展到高端商品硬件。 可以廉价购买二手或翻新的强大 4U 盒子。 +2. **了解您的瓶颈在各个层次中的位置**。 您是否绑定了 CPU 或 IO（磁盘，网络）？ 数据库几乎总是受 IO（磁盘）约束。 一旦数据库无法容纳在 RAM 中，您就会碰壁。 +3. **认真地配置数据库**。 专注于优化数据库。 扩展 Web 层既便宜又容易，而数据库层则又困难又昂贵。 通过执行时间和执行频率，了解系统上最重要的查询。 跟踪和基准化每个版本的主要查询，需要及早发现并解决数据库的性能问题。 我们使用 pgFouine 日志分析器和新的 PostgreSQL pg_stat_statements 实用程序实时生成概要分析快照。 +4. **设计为禁用**。 能够配置和关闭即时发布的任何内容，而无需更改或部署代码。 负载和压力测试很重要，但没有什么比通过逐步分阶段推出的实时生产流量进行测试了。 +5. **仅在绝对必要时才进行同步通信**。 当一个组件或服务发生故障时，不应关闭系统的其他部分。 在后台或作为单独的线程或进程来做您可以做的所有事情，不要让用户等待。 尽可能批量更新数据库。 任何在网络外部发出请求的系统都需要主动监控，超时设置以及故障处理/重试。 例如，我们发现 S3 延迟和故障率可能很高，因此我们将失败的呼叫排队，然后重试。 +6. **考虑在设计期间进行监视，而不是在**之后进行监视。 每个组件都应产生性能，运行状况，吞吐量等数据。 当警报超过阈值时设置警报。 显示所有实例（而不是每个实例）的指标的综合图表对于一目了然地发现问题和趋势特别有帮助，应该每天进行检查-如果不能很好地理解正常的操作行为，则无法识别和应对不正常的情况。 t。 我们尝试了许多监视系统-仙人掌，神经节，Hyperic，Zabbix，Nagios，以及一些定制的解决方案。 无论您使用哪个最重要的东西，都要对它感到舒服，否则您将不会足够使用它。 使用模板等可以轻松监视新包装盒和服务，并在放置它们时迅速进行。 +7. **分布式会话可能会产生很多开销**。 只要有可能就进入无状态状态，但是当您不考虑粘性会话时。 如果服务器发生故障，用户将丢失其状态，可能需要重新登录，但这很少见并且可以接受，具体取决于您需要执行的操作。 +8. **监视并提防 Java** 中的全部/主要垃圾回收事件，该事件最多可以锁定整个 JVM 30 秒。 我们使用并发标记扫描（CMS）垃圾收集器，该垃圾收集器引入了一些额外的系统开销，但能够消除完整的垃圾收集。 +9. 当站点足够大时，无论是站点内部还是外部，通过电子邮件等，它都会吸引垃圾邮件散布者和黑客，而 Captcha 和 IP 监视是不够的。 必须**积极投资于检测和围堵系统**，这是检测可疑用户行为并发出警报和/或尝试自动围堵的内部工具。 +10. **尽可能软删除**。 将数据标记为以后删除，而不是立即删除。 删除的成本可能很高，因此要花几个小时才能排队，此外，如果有人犯了一个错误并删除了他们不应该拥有的东西，那么回滚很容易。 +11. **N + 1 设计**。 不得少于两个。 + +我非常感谢 Jamie 花时间编写此体验报告。 这是对其他人学习的真正有用的贡献。 如果您想共享 fablous 系统的体系结构，请 [与联系我](../../contact/)，我们将开始。 -> 原文： [http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) - -![](img/98c9699f964c1091947cf4dcdf2cd262.png) - -与拥有 核武器的国家相比，很少有公司知道如何建立全球性的分布式服务。 Facebook 是其中一家公司， [Facebook Live](https://www.facebook.com/livemap/) ，Facebook 的 [新](https://live.fb.com/about/) 实时视频 流产品，就是这些服务之一。 - -Facebook CEO [马克·扎克伯格](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)： - -> 我们做出的重大决定是将我们的许多视频工作重点转移到 Live 上，因为这是一种新兴的新格式； 而不是过去五到十年一直在线的那种视频……我们正在进入视频的新黄金时代。 如果您快进五年，人们在 Facebook 上看到并每天分享的大部分内容都是视频，我不会感到惊讶。 - -如果您从事的是广告业务，那么比提供永无止境，始终在扩展且可自由生成的广告就绪内容更好？ 当 Google [开始在呈指数增长的网络上投放广告时，就利用了](http://www.wsj.com/articles/SB108319881076696889) 来进行经济分析。 - -Facebook 的流媒体表演的一个例子是两个人的 45 分钟视频 [用橡皮筋爆炸西瓜](https://www.buzzfeed.com/brendanklinkenberg/this-exploding-watermelon-was-facebook-lives-biggest-hit-to) 。 它达到了超过 80 万同时观看者的顶峰，这些评论者还收集了 30 万以上的评论。 这就是您可以通过拥有 15 亿用户的社交网络产生的病毒规模。 - -作为比较 [1.14 亿](http://www.statista.com/statistics/216526/super-bowl-us-tv-viewership/) 观看了 2015 年超级碗的观众，平均 [观看者有 236 万 实时流中的](http://money.cnn.com/2015/10/26/media/nfl-yahoo-live-stream-results/) 。 Twitch 的 [840,000](http://www.geekwire.com/2015/amazons-twitch-attracts-monster-audience-at-e3-with-21m-viewers-tuning-in-online/) 观众人数在 2015 年 E3 达到顶峰。9 月 16 日的共和党辩论在 [921,000 达到顶峰 ]](http://www.politicususa.com/2015/10/14/debate-watched-democratic-debate.html) 同时直播。 - -因此，Facebook 处于最新状态。 请记住，Facebook 也会同时有大量其他流。 - -一篇有线文章 [引用了](http://www.wired.com/2016/04/facebook-really-really-wants-broadcast-watch-live-video/) Facebook 首席产品官 Chris Cox，他说 Facebook： - -* 有超过**个**现场直播人员。 （[从[12]开始](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video)，现在该项目有 150 多名工程师） - -* 需要能够提供**数百万个同时流**而不会崩溃。 - -* 需要能够在流上支持**数百万同时观看者，以及全球不同设备和服务提供商之间的无缝流。** - -Cox 说：“事实证明这是一个非常困难的基础架构问题。” - -如果我们有一些有关如何解决该基础结构问题的详细信息，这会很有趣吗？ 祸是我们。 但是等等，我们做到了！ - -[Federico Larumbe](https://www.linkedin.com/in/federicolarumbe) 来自 Facebook 的流量小组，该小组致力于为 Facebook 的 CDN 和全球负载平衡系统提供支持的缓存软件，并发表了精彩的演讲： [扩展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) ，他在其中分享了有关 Live 工作方式的一些详细信息。 - -这是我在演讲中的发言。 令人印象深刻 - -## 起源故事 - -* Facebook 是一项新功能，允许人们实时共享视频。 （请注意，这对于 Facebook 来说只是另一个功能）。 - -* 于 2015 年 4 月推出，只有名人才能通过 [提及应用](https://www.facebook.com/about/mentions/) 作为与粉丝互动的媒介使用。 - -* 这是产品改进和协议迭代开始的一年。 - - * 他们以 HTTP 实时流媒体 [HLS](https://en.wikipedia.org/wiki/HTTP_Live_Streaming) 开头。 它受 iPhone 支持，并允许他们使用现有的 CDN 架构。 - - * 同时开始研究 [RTMP](https://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol) （实时消息协议） ，这是一种基于 TCP 的协议。 从手机发送到实时流服务器的是视频流和音频流。 - - * 优点：RTMP 在广播者和观看者之间具有较低的终端等待时间。 在人们相互交流的交互式广播中，这确实有所作为。 然后，降低等待时间并减少几秒钟的延迟，将使体验有所不同。 - - * 劣势：由于它不是基于 HTTP 的，因此需要一个完整的体系结构。 需要开发新的 RTMP 代理以使其扩展。 - - * 还研究了 [MPEG-DASH](https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) （基于 HTTP 的动态自适应流）。 - - * 优势：与 HLS 相比，它的空间效率高 15％。 - - * 优点：它允许自适应比特率。 编码质量可以基于网络吞吐量而变化。 - - * [吹笛者中出压缩解决方案](https://www.crunchbase.com/organization/pied-piper#/entity) ：（开个玩笑） - -* 于 2015 年 12 月在数十个国家/地区推出。 - -![](img/cc9254808fa61d8f01212c2503be1c30.png) - -## 实时视频与众不同，这会引起问题 - -* 前面提到的西瓜视频的流量模式： - - * 最初的上升非常陡峭，在几分钟之内达到了每秒 100 多个请求，并持续增长直到视频结束。 - - * 然后，流量像石头一样下降。 - - * 换句话说：流量非常大。 - - ![](img/20bf250cc8477b6987d45ae83f3d37c1.png) - -* 实时视频与普通视频不同：它会导致**尖峰** **流量模式**。 - - * 实况视频更具吸引力，因此观看**的**比普通视频多 3 倍。 - - * 实时视频出现在新闻源的顶部，因此被观看的可能性更高。 - - * 通知会发送到每个页面的所有粉丝，以便另一组可能会观看视频的人。 - -* 高峰流量会导致缓存系统和负载平衡系统出现问题。 - -* **缓存问题** - - * 很多人可能希望同时观看直播视频。 这是您的经典 [雷电牧群问题](https://en.wikipedia.org/wiki/Thundering_herd_problem) 。 - - * 尖刻的流量模式给缓存系统带来压力。 - - * 视频被分割成一秒钟的文件。 当流量激增时，缓存这些段的服务器可能会过载。 - -* **全局负载平衡问题** - - * Facebook 在全球分布 [个存在点](https://en.wikipedia.org/wiki/Point_of_presence) （PoP）。 Facebook 流量在全球范围内分布。 - - * 挑战在于防止峰值使 PoP 过载。 - -## 大图片架构 - -这就是直播流从一个广播公司到数百万观众的方式。 - -* 广播员在其手机上开始直播视频。 - -* 手机将 RTMP 流发送到实时流服务器。 - -* 实时流服务器解码视频并将代码转换为多个比特率。 - -* 对于每个比特率，将连续生成一秒钟的 MPEG-DASH 段。 - -* 段存储在数据中心缓存中。 - -* 从数据中心缓存段被发送到位于存在点的缓存（PoP 缓存）。 - -* 观看者在观看时会收到一个实时故事。 - -* 他们设备上的播放器开始以每秒 1 个的速率从 PoP 缓存中获取片段。 - -## 它如何缩放？ - -* 数据中心高速缓存和**许多 PoP 高速缓存**之间有一个**乘法点**。 用户访问 PoP 缓存，而不是数据中心，并且全世界分布着许多 PoP 缓存。 - -* 另一个乘数是每个 PoP 中的**。** - - * 在 PoP 中有**两层**：一层 HTTP 代理和一层缓存。 - - * 查看器从 HTTP 代理请求段。 代理检查该段是否在缓存中。 如果在缓存中，则返回该段。 如果不在缓存中，则将对该段的请求发送到数据中心。 - - * 不同的**段存储在不同的缓存**中，从而有助于跨不同的缓存主机进行负载平衡。 - -## 保护数据中心免受雷电袭击 - -* 当所有观众同时请求相同的片段时会发生什么？ - -* 如果该段不在高速缓存中，则将向每个查看器发送一个请求到数据中心。 - -* **请求合并** 。 通过将请求合并添加到 PoP 缓存中，减少了请求数量。 仅第一个请求发送到数据中心。 其他请求将一直保留，直到第一个响应到达并将数据发送给所有查看者为止。 - -* 新的缓存层已添加到代理，以避免 **Hot Server 问题**。 - - * 所有查看器都发送到一个缓存主机，以等待该片段，这可能会使主机过载。 - - * 代理**添加了缓存层**。 实际上，只有第一个对代理的请求才向缓存发出请求。 以下所有请求均直接从代理服务。 - -## PoP 仍然处于危险之中-全局负载平衡正在救援 - -* 因此，保护​​数据中心不受雷电群问题的影响，但 PoP 仍然处于危险之中。 Live 的问题是尖峰非常大，以致 PoP 可能在 PoP 的负载度量达到负载平衡器之前过载。 - -* 每个 PoP 具有数量有限的服务器和连接性。 如何防止峰值导致 PoP 过载？ - -* 名为 Cartographer 的系统将 Internet 子网映射到 PoP。 它测量每个子网和每个 PoP 之间的延迟。 这是延迟测量。 - -* 测量每个 PoP 的负载，并将每个用户发送到具有足够容量的最近 PoP。 代理中有一些计数器可以衡量它们承受的负载量。 这些计数器是汇总的，因此我们知道每个 PoP 的负载。 - -* 现在存在一个优化问题，该问题会考虑容量限制并最大程度地减少延迟。 - -* 使用控制系统时，存在测量延迟和反应延迟。 - -* 他们将负载测量窗口从 1.5 分钟更改为 3 秒，但仍然有 3 秒的窗口。 - -* 解决方案是在实际发生负载之前 **预测负载** 。 - -* 实施了**容量估算器**，将每个 PoP 的先前负载和当前负载外推到未来负载。 - - * 如果负载当前正在增加，预测器如何预测负载将减少？ - - * **三次样条**用于 [插值](https://en.wikipedia.org/wiki/Spline_interpolation) 功能。 - - * 取一阶和二阶导数。 如果速度为正，则负载将增加。 如果加速度为负，则表示速度正在降低，最终将为零并开始降低。 - - * 三次样条比线性插值预测更复杂的交通模式。 - - * **避免振荡** 。 此插值功能还解决了振荡问题。 - - * 测量和反应的延迟意味着对过时的数据做出决策。 插值可减少误差，更准确地进行预测并减少振荡。 因此负载可以更接近目标容量 - - * 当前预测是基于 最近的三个间隔 ，其中每个间隔为 30 秒。 几乎是瞬时负载。 - -## 测试 - -* 您需要能够使 PoP 过载。 - -* 构建了一个负载测试服务，该服务在 PoP 上全局分布，以模拟实时流量。 - -* 能够模拟 10 倍的生产负荷。 - -* 可以模拟一次请求一个片段的查看器。 - -* 该系统有助于揭示和修复容量估计器中的问题，以调整参数，并验证缓存层是否解决了雷电群问题。 - -## 上传可靠性 - -* 实时上传视频具有挑战性。 - -* 以具有 100 至 300 Kbps 可用带宽的上载为例。 - -* 音频需要 64 Kbps 的吞吐量。 - -* 标清视频需要 500 Kbps 的吞吐量。 - -* 手机上的自适应编码用于调整视频+音频的吞吐量不足。 视频的编码比特率根据可用的网络带宽进行调整。 - -* 决定上传比特率的方法是在手机中通过测量 RTMP 连接上的上传字节来完成，并且对最后间隔进行加权平均。 +## 相关文章 -## 未来方向 +* [移动社交网络 MocoSpace 现已拥有 1100 万会员](http://techcrunch.com/2010/03/17/mobile-social-network-mocospace-now-11-million-members-strong/ "Mobile Social Network MocoSpace Now 11 Million Members Strong") +* [MocoSpace 的工作方式](http://computer.howstuffworks.com/internet/social-networking/networks/mocospace.htm) -* 研究一种推送机制，而不是请求拉机制，利用 HTTP / 2 在请求分段之前将其推送到 PoP。 +我想知道 ActiveMQ 工作意味着什么？ -## 相关文章 +很棒的帖子。 这是我们真正了解战 the 的帖子。 +保持良好的工作。 +费利佩 -* [关于 HackerNews](https://news.ycombinator.com/item?id=11987654) +我很好奇为什么 Sun Fire 支持数据库？ -* [扩展 Facebook Live](https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/) +关于第 7 课：粘性会议更好？ 通过将用户锁定到特定服务器，您是否限制了更有效地进行负载平衡的能力？ 你们有 10 台 Web 服务器。 粗略地说，如果您丢失一台服务器，则会损失 10％的容量，并且 10％的当前访问者将丢失会话。 使用无粘性设置，如果您丢失一台服务器，则只会丢失 10％的容量，但不会有用户丢失会话。 从负载平衡设置中删除服务器将更加容易。 -* [为什么 Facebook 和 Mark Zuckerberg 都参与直播视频](https://www.buzzfeed.com/mathonan/why-facebook-and-mark-zuckerberg-went-all-in-on-live-video) +您正在使用 F5 进行哪种负载均衡？ 愚蠢的循环赛吗？ 还是从每个服务器收集更具体的指标并基于此加载？ 您是将客户端连接一直传递到每​​个 Web 服务器，还是将 F5 用作反向代理？ -* [连接世界：Facebook 网络基础架构](http://cs.unc.edu/xcms/wpfiles/50th-symp/Moorthy.pdf) +您在哪里进行 ffmpeg 编码？ 在那些列出的服务器上还是其他地方？ -* [Gamoloco](https://gamoloco.com/) 跟踪 1476093 个频道的实时视频统计信息。 +你们为什么要选择 Zabbix 和 Nagios？ 为什么其他解决方案对您不起作用？ -Google Chrome 浏览器告诉我您的网站已感染恶意软件。 也许是个调皮的广告？ +您在地理上分布吗？ -我很乐意在具有如此高流量的平台上工作。 12 位工程师可以毫无问题地做到这一点。 很少有人可以在应用程序上工作，甚至可以进行额外的数据压缩，而在主平台上则很少。 我什至可以处理 100-200k 观众的实时流，唯一的限制是资金有限；）我还是不明白 150 位工程师在这方面做了什么... 很抱歉，我目前没有客户，流量非常大。 +如果您在某些方面使用 S3 和 EC2，为什么不将其余基础架构移至亚马逊或其他云呢？ -150 名工程师可以同时建立 10 个创业公司！ 没有留下深刻印象。 +即使有所有缓存，你们还是需要 Fusion-io 吗？ -我不知道为什么 Google 网站管理员工具 Dobes 会显示该网站存在我什至无法在该网站上找到的问题，但是却没有说出它是否带有恶意软件。 +这真的是非常有用的帖子。 感谢您分享这一点。 -我不知道 Facebook 工程师的自我来自何处。 毫无疑问，这是一个很难解决的问题，但我认为这与核武器的复杂性不相上下。 +是什么让他们选择了 PostgreSQL 而不是 MySQL？ 使用了什么标准？ +他们使用任何 Java 框架吗？ -Facebook live 的问题都不是新问题。 它们是成熟的技术，许多公司已经多次解决了它们。 +最好的祝福 -规模仍然非常可观，我想你们应该专注于此。 +@Maxim R -我对 MPEG-DASH 感到担心，“它允许自适应比特率。编码质量可以根据网络吞吐量而变化”。 那是优点还是缺点？ 谢谢。 +1.我们不在地理上分布 +2\. F5 是基于会话的负载平衡。 有许多 iRules 导致一些流量直接传递到 Web 服务器，从 F5 缓存提供服务，或从 Squid 缓存提供服务 +3\. ffmpeg 编码在批处理服务器 +上完成。4\. S3 和 EC2 相当 昂贵。 我们可以从戴尔购买一个全新的盒子，然后在几个月内拿回我们的钱，而不是几个大型实例。 由于我们不必处理“嘈杂的邻居” +，因此性能也更可预测。5。显然，使用分布式会话将为我们提供更大的灵活性，但是会带来较大的开销。 使用粘性会话是/有中间立场。 +6.关于 Fusion-IO，所有页面都是动态创建的，因此我们需要很高的 I / O 吞吐量。 随着站点的增长，I / O 要求也随之提高。 -自适应比特率通常被认为是一个优势，因为只要带宽高于最小比特率，流就不会中断。 +您曾想过[哇，这些家伙看起来不错/专业]直到 + `Development team responsible for deploying to and managing production systems "you built it, you manage it"` -顺便说一下，就我所知，MPEG-DASH 与 HLS 本质上相同，都允许自适应比特率。 \ No newline at end of file +部分。 如果我是你，我会在投资者会议上保密。 \ No newline at end of file diff --git a/docs/49.md b/docs/49.md index 1b38925..1a91072 100644 --- a/docs/49.md +++ b/docs/49.md @@ -1,189 +1,286 @@ -# 每天可处理数百万个请求的图像优化技术 +# Sify.com 体系结构-每秒 3900 个请求的门户 -> 原文： [http://highscalability.com/blog/2016/6/15/the-image-optimization-technology-that-serves-millions-of-re.html](http://highscalability.com/blog/2016/6/15/the-image-optimization-technology-that-serves-millions-of-re.html) +> 原文： [http://highscalability.com/blog/2010/5/10/sifycom-architecture-a-portal-at-3900-requests-per-second.html](http://highscalability.com/blog/2010/5/10/sifycom-architecture-a-portal-at-3900-requests-per-second.html) -![](img/53937b855f4361fee420d17dae2e415d.png) +![](img/cfd4275d142a1fcf3dc491330469eee9.png) -本文将介绍 [Kraken.io](https://kraken.io/) 如何构建和扩展每天可处理数百万个请求的图像优化平台，以保持 始终保持高性能，同时保持尽可能低的成本。 在撰写本文时，我们将介绍当前的基础结构，并介绍一些我们学到的有趣的知识，以便将其运用于此处。 +Sify.com 是印度领先的门户网站之一。 Samachar.com 由同一家公司拥有，是印度顶级的内容汇总网站之一，主要针对来自世界各地的非居民印度人。 Sify 的建筑师 Ramki Subramanian 非常慷慨地描述了这两个站点的通用后端。 他们的架构最值得注意的方面之一是 Sify 不使用传统数据库。 他们查询 Solr，然后从分布式文件系统中检索记录。 多年以来，许多人争相使用数据库之上的文件系统。 文件系统可以用于键值查找，但不适用于查询，使用 Solr 是解决该问题的好方法。 他们系统的另一个有趣的方面是使用 Drools 进行智能缓存无效化。 随着我们在多个专业服务中复制越来越多的数据，如何使它们[同步](http://www.youtube.com/results?search_query=in+sync)成为一个难题。 规则引擎是一种聪明的方法。 -### 让我们制作一个图像优化器 +## **平台/工具** -您想开始在 CDN 帐单上省钱，并且通常通过将较少的字节通过网络推送到用户的浏览器来加快网站速度。 很有可能超过 [的流量有 60％](http://httparchive.org/interesting.php) 仅是图像。 +* 的 Linux +* [浅色](http://www.lighttpd.net/) +* PHP5 +* 记忆快取 +* 阿帕奇·索尔（Apache Solr） +* Apache ActiveMQ /骆驼 +* GFS（群集文件系统） +* 德语 +* 雷迪斯 +* 带有 ActiveMQ 的子。 +* 漆 +* 流口水 -使用 ImageMagick（您确实读过 [ImageTragick](https://imagetragick.com/) ，对吗？），您可以使用以下简单命令降低 JPEG 文件的质量： +## 统计资料 -$ convert -quality 70 original.jpg Optimized.jpg +* 每月约有 1.5 亿次网页浏览。 +* 服务 3900 请求/秒。 +* 后端在托管约 30 个 VM 的 4 个刀片上运行。 -$ ls -la +## 建筑 --rw-r--r-- 1 matylla 职员 5897 5 月 16 日 14:24 original.jpg +* 该系统已完全虚拟化。 我们还使用了大多数 VM 功能，例如当一个刀片发生故障或需要重新分配负载时，我们在刀片之间移动 VM。 我们已经对虚拟机进行了模板化，因此我们可以在不到 20 分钟的时间内配置系统。 它目前是手动的，但是在系统的下一版本中，我们计划自动化整个供应，调试，退役，在 VM 周围移动以及自动缩放。 +* 没有数据库 +* 100％无状态 +* RESTful 接口支持：XML，JSON，JS，RSS / Atom +* 写入和读取具有不同的路径。 + * 通过 ActiveMQ / Camel 将写入排队，转换并路由到其他 HTTP 服务。 它用作 ESB（企业服务总线）。 + * 像搜索一样的读取操作是由 Web 服务器直接从 PHP 处理的。 +* Solr 用作索引/搜索引擎。 如果有人要求提供密钥的文件，则会直接将其送出存储空间。 如果有人说“给我所有在 author = Todd 处的文件，”它将打到 Solr，然后存储。 使用 Apache Solr 作为我们的搜索引擎来执行查询，并且我们有相同的分布式设置。 +* 所有文件都存储在群集文件系统（GFS）中。 查询打到 Solr，它返回我们想要的数据。 如果我们需要完整的数据，则在从搜索中获取 ID 后，我们将访问存储。 这种方法使系统完全可以水平扩展，并且对数据库的依赖性为零。 升级到最新版本后，对我们来说效果很好。 我们仅运行 2 个节点进行存储，如果需要，我们可以再添加几个节点。 +* 轻巧的前端 GFS。 Lighty 对于提供静态文件确实非常好。 对于我们拥有的文件类型（主要是小的 XML 和图像），每秒可以随意接收 8000 多个请求。 +* 所有最新的 NoSQL 数据库（如 CouchDB，MongoDB，Cassandra 等）都将替代我们的存储层。 在搜索功能上，它们都不接近 Solr / Lucene。 就查询而言，MongoDB 是最好的，但是``包含''之类的搜索需要使用正则表达式来完成，这对 500 万个文档来说是一场灾难！ 我们相信，目前，基于分布式文件系统的方法比许多用于存储的 NoSQL 数据库系统更具可伸缩性。 --rw-r--r-- 1 matylla 职员 2995 May 16 14:25 Optimized.jpg +## 未来 -恭喜。 通过屠宰 JPEG 的质量，您刚刚将其压缩了约 50％。 图像现在看起来像 Minecraft。 它看起来不是这样-它可以销售您的产品和服务。 理想情况下，Web 上的图像应具有出色的质量，并且不会以过高的质量或 EXIF 元数据的形式出现不必要的膨胀。 +* 用于事件分析（用户点击，实时图表和趋势）的 CouchDB 或 Hadoop 或 Cassandra。 +* 使用 Drools 的智能缓存失效。 数据将通过队列推送，而 Drools 引擎将确定哪些 URL 需要无效。 它将在我们的缓存引擎或 Akamai 中清除它们。 方法是这样的。 查询（URL）到达我们的后端后，我们将记录该查询。 然后，记录的查询将被解析并推送到 Drools 系统中。 如果该输入尚不存在，则系统会将其输入并动态创建规则到系统中。 那是 A 部分。然后，我们的 Content Ingestion 系统将继续将进入 Drools 队列的所有内容推送。 数据输入后，我们将针对内容触发所有规则。 对于每个匹配的规则，生成 URL，然后我们将针对这些 URL 向缓存服务器（Akamai 或 Varnish）发出删除请求。 多数民众赞成在 B 部分。B 部分并不像上面提到的那么简单。 会有很多不同的情况。 例如，我们在查询中支持“ NOW”，大于，小于，NOT 等，这确实会让我们头疼。 + * 我们这样做的主要原因主要有两个，高速缓存命中率极高，并且几乎可以立即更新最终用户。 请记住，过去从未经历过的两个原因！ + * 我认为它将很好并且可以扩展。 Drools 确实擅长解决此类问题。 同样在分析中，我们发现查询在许多天内都是恒定的。 例如，我们每天有将近 40,000 个不同的查询，并且每天都会以几乎相同的模式重复。 对于该查询，只有数据会更改。 因此，我们可以设置多个实例并仅在不同系统中复制规则，这样我们也可以水平扩展它。 +* 同步读取，但是更少的层，更少的 PHP 干预和套接字连接。 +* 使用 Queue / ESB（Mule）进行分布式（写入不同的分片）和异步写入。 +* 使用 Varnish 或 Akamai 进行大量缓存。 +* 杀死 gron 并保持更接近实时的守护进程。 +* 使用 Gearman 进行并行和后台处理，以及用于自动缩放处理的自动附加处理功能。 +* 使用 Kaazing 或 eJabberd 向最终用户和内部系统实时分发内容。 +* Redis 用于缓存内容摘要以确定重复项。 +* 我们正在寻求使整个事情更易于管理，并从 app-admin 内部打开 VM 和进程。 我们研究了 Apache Zookeeper，研究了 VMWare 和 Xen 提供的 RESTful API，并与我们的系统进行了集成。 这将使我们能够进行自动缩放。 +* 我们拥有的最大优势是数据中心的带宽不受限制，因为我们自己就是 ISP。 我正在研究在系统中利用该优势的方法，并了解如何构建可以并行快速处理大量内容的集群。 -现在，您打开自己喜欢的图像编辑软件并开始以 Q 级播放，同时将 JPEG 保存为 Web。 事实证明，您测试的这张特定图片在 Q76 看上去很棒。 您开始以质量设置为 76 保存所有 JPEG。但是请稍等片刻...有些图像即使在 Q80 情况下也看起来很糟糕，而有些图像甚至在 Q60 时也很好。 +## 得到教训 -好的。 您决定以某种方式使其自动化-谁想要手动测试您拥有维护“特权”的数百万张图像的质量。 因此，您创建了一个脚本，该脚本可以生成不同 Q 级别的输入图像的数十个副本。 现在，您需要一个度量标准，该度量标准将告诉您哪个 Q 级适合特定图像。 MSE？ SSIM？ MS-SSIM？ PSNR？ 您如此绝望，甚至开始计算和比较输入图像不同版本的 [感知哈希](https://en.wikipedia.org/wiki/Perceptual_hashing) 。 +* ActiveMQ 多次被证明是灾难性的！ 套接字处理非常差。 从重启开始，我们通常会在不到 5 分钟的时间内达到 TCP 套接字限制。 尽管它声称已在 5.0 和 5.2 中进行了修复，但对我们而言并不起作用。 我们以多种方式尝试使它的寿命更长，至少一天。 我们通过部署带有新版本的旧库来解决问题，并使它的使用时间更长。 毕竟，我们部署了两个 MQ（消息队列），以确保至少对内容进行编辑更新可以正常进行。 + * 后来我们发现问题不仅在于此，而且使用主题也是一个问题。 仅对四个订阅者使用 Topic 会使 MQ 在数小时内挂起。 在大量脱发后，我们取消了整个基于主题的方法，并将它们全部排入队列。 数据进入主队列后，我们将数据推入四个不同的队列。 问题已解决。 当然，在 15 天左右的时间内，它将抛出一些异常或 OOME（内存不足错误），并迫使我们重新启动。 我们只是与它共存。 在下一个版本中，我们将使用 Mule 来处理所有这些问题，并且也将集群同时进行。 我们还试图找到一种方法来按消息顺序摆脱依赖关系，这将使分发变得更容易。 +* 索尔 + * 重新启动。 我们必须非常频繁地重新启动它。 尚不十分清楚原因，但是因为它具有冗余性，所以我们比 MQ 更好。 通过执行查询，我们已达到自动重启的程度，如果没有响应或超时，我们将重启 Solr。 + * 复杂查询。 对于复杂的查询，查询响应时间确实很差。 我们有大约 500 万个文档，并且很多查询的确在不到一秒钟的时间内返回，但是当我们有一个带有几个“ NOT”以及许多字段和条件的查询时，它需要 100 秒钟以上的时间。 我们通过将查询拆分为更简单的查询并将结果合并到 PHP 空间中来解决此问题。 + * 即时的。 我们遇到的另一个严重问题是 Solr 不能实时反映所做的更改。 大约需要 4 分钟到 10 分钟！ 考虑到我们所处的行业和竞争，迟到的新闻 10 分钟使我们变得无关紧要。 看过 Zoie-Solr 插件，但我们的 ID 是字母数字，而 Zoie 不支持。 我们正在寻找自己在 Zoie 中修复的问题。 +* GFS 锁定问题。 对于我们来说，这曾经是一个非常严重的问题。 GFS 将锁定整个群集，这将使我们的存储完全不可访问。 GFS 4.0 出现问题，我们升级到 5.0，从那时起似乎还不错。 +* Lighty 和 PHP 不太融洽。 性能方面都不错，但是 Apache / PHP 更稳定。 由于 PHP_FCGI 进程挂起，Lighty 有时会胡思乱想，CPU 使用率达到 100％。 -有些指标的效果要好于其他指标。 对于某些类型的图像，有些效果很好。 有些非常快，而另一些则需要很长时间才能完成。 您可以通过减少处理每个图像的循环次数来逃脱现实，但是很可能您错过了理想的 Q 级别，并且图像要么重于原来的水平，要么质量下降过高。 +我非常感谢 Ramki 花时间写关于他们的系统如何工作的信息。 希望您能从他们的经验中学到一些有用的东西，这些对您自己的冒险有帮助。 如果您想共享您的优秀系统的架构，请同时向其付费和向后付费，请 [与联系我](../../contact/)，我们将开始。 -那么在白色背景下的商品图片呢？ 您真的想减少对象周围的振铃/晕影。 基于每个图像的自定义色度二次采样设置如何？ 如今，白色背景下的那件红色连衣裙看上去已经被洗掉了。 您已经了解到，剥离 EXIF 元数据将使文件大小变小一点，但是您还移除了 Orientation 标签，现在图像旋转不正确。 +相当有趣的信息！ 谢谢分享！ 每秒 3900 个请求非常棒。 -那只是 JPEG 格式。 对于您的 PNG，您可能想重新压缩 7-Zip 或 Deflate 压缩后的图像，例如 Google 的 [Zopfli](https://github.com/google/zopfli) 。 您启动脚本并观看 CPU 上的风扇开始熔化。 +目标响应时间是多少？ -您可能需要一个可靠的工具，该工具可以优化所有图像，无论格式如何。 [Kraken.io](https://kraken.io/) 是一种这样的工具。 +拉姆基 -### 关于 Kraken.io +Lighty 曾经有内存泄漏。 Nginx 或 Cherokee 可能值得一看。 将 MogileFS 视为 GFS 的替代品-GFS 更像是 POSIX 文件系统的替代品，但是 MogileFS 可能“足够”，并且应该具有更大的可扩展性。 Solr －也许您需要分片搜索引擎，但这可能比它值得的工作更多。 ;-)使用 ActiveMQ，您是否考虑过将一些较轻的排队需求转移到 Redis？ 它具有可用于某些类型排队的原子构造，并且几乎可以肯定会更快。 -Kraken.io 是图像优化和压缩 SaaS 平台，具有其他操作功能，例如图像大小调整。 我们的目标是尽可能自动缩小图像的字节大小，同时保持视觉信息的完整性和始终如一的高质量，从而无需手动检查结果的保真度。 +感谢如此出色的文章！ -### 软件 +杰米 -除了基于 PHP 的 Kraken.io 前端外，几乎我们所有的软件都是在 [节点](https://nodejs.org/en/) 中编写的。 我们大量使用节点流，因为我们的优化管道可以使用二进制数据流。 +精彩的帖子！ 很高兴看到有人实际构建事物而不是遵循流行语。 -当图片首次出现在我们的平台上时，首先会通过“ kraken-identify”过程进行抽签，以可靠地检测出最重要的功能-图像格式（JPEG，PNG，GIF，SVG 等），图像类型（逐行/ 基线 JPEG，动画/静态 GIF 等），以及嵌入的颜色配置文件和 EXIF 元数据的存在。 +这些“ NoSQL”文档存储为您直接的分布式文件系统添加的功能正是使搜索与数据保持同步的能力。 有趣的是，与“愚蠢”的文档存储（文件系统）相比，您实际上为此功能付出了高昂的代价。 在我看来，保持这种状态的关键是在 Solr 搜索和数据之间出现延迟。 您愿意允许多少时间？ -我们只需要读取几个字节，就不需要解压缩整个图像，也不需要将解压缩的数据加载到内存中。 +考虑到这一点，对我来说，将 CouchDB 用作分布式文件系统似乎是个好主意。 我不敢相信它会比您使用的任何工具都要慢。 还有...继续使用 Solr！ 仅在需要同步搜索时才退回到 CouchDB“视图”。 -确定我们刚收到的文件确实是图像后，我们将对其进行进一步处理。 对于某些特定的图像，我们还计算了独特颜色的数量。 唯一色计数是一种直方图类型的操作，它固有的速度很慢，无法对压缩数据进行处理，因此我们仅在非常特定的图像子集上使用它。 +这似乎与“ NoSQL”的智慧几乎相反，但是从您的经验来看，这似乎是一个很好的实用结论。 -然后，图片会通过 HTTP 通过我们的优化管道传递。 这使我们可以将二进制数据（图像本身）与优化设置（作为字段或标头）一起抽取。 与我们的优化集群的 HTTP 连接保持打开状态，直到该过程完成，并且来自集群的 HTTP 响应被流回磁盘（直接流回 GlusterFS 目标位置），因此我们不会经常接触磁盘。 当我们从群集中流回整个响应时，任何优化后的数据都会通过 HTTP 标头传输。 +您是在 4 刀片系统上直接处理 3900 Request / second，还是还包括 Akamai 流量？ +您如何处理负载平衡？ -（可选），如果 API 用户请求，我们可以将优化的资产存储在他或她选择的外部存储中- [S3](https://kraken.io/docs/storage-s3) ， [Azure](https://kraken.io/docs/storage-azure) ， [云文件](https://kraken.io/docs/storage-cloudfiles) 或 [SoftLayer [](https://kraken.io/docs/storage-softlayer) 。 +> “后端在托管约 30 个 VM 的 4 个刀片上运行。” -最后一个任务（用于 API）是终止与 API 客户端的 HTTP 连接，并以优化结果作为响应，例如： +what kind of 'front-end' infrastructure do you have? +What kind of VM are you running? VMWare? Xen? KVM? -{ +听起来好像他们正在将 HP Blade Matrix 与 VMware 一起使用。 -“ file_name”：“ sku126933.jpg”， +“每月有 1.5 亿页面浏览量” +“每秒可处理 3900 请求”。 -“ original_size”：35761， +算一下：3900 * 60 * 60 =每小时请求 14.000.000 +每天 8 小时：每天 14.040.000 * 8 = 112.000.000 +因此，其中一个 上面的值 -“ kraked_size”：10799， +Raghuraman：目标响应时间是多少？ -“ saved_bytes”：22462， +拉姆基：我们不需要在后端系统中执行超过数千个 rp，因为前端系统的许多部分速度都较慢。 毕竟，系统中的薄弱环节定义了最终的要求/秒！ 如果我们可以使前端数量相同，那就太好了！ -“ kraked_url”：“ https://dl.kraken.io/api/3e/db/24/08e20232a13c35fc1a72356537/sku126933.jpg”， +杰米： -“ original_width”：600， +Lighty 曾经有内存泄漏。 Nginx 或 Cherokee 可能值得一看。 -“ original_height”：600， +Ramki：到目前为止，Lighty 对我们的表现一直很好，尽管在某些情况下，lighty 会让我们头疼。 Nginx 是一个不错的选择，我们可以尝试一下。 -“成功”：是 +杰米（Jamie）：将 MogileFS 视为 GFS 的替代品-GFS 更像是 POSIX 文件系统的替代品，但 MogileFS 可能“足够”并且应该具有更大的扩展性。 -} +Ramki：该系统的第一个版本在 MogileFS 中运行，并很快成为我们的大问题。 给我，在数据库中存储文件的元信息是一场灾难。 在短短几周内，数据库记录就接近 150 万。 查询变得非常缓慢...但是我喜欢基于 WebDAV 的方法的想法，因此我们尝试了不使用 MogileFS，但是我们的 LB 当时不支持 HTTP 1.1，因此我们取消了整个想法并将其移至文件系统。 -对立即解析响应正文不感兴趣的用户可以使用我们的 [Webhook 传递系统](https://kraken.io/docs/wait-callback) 。 通过在请求中指定 callback_url，用户将指示 API 应用程序将优化结果 POST 到其自己的端点。 在这种情况下，我们排队一个 Webhook 任务（使用 Redis 作为代理）。 仅用于 Webhook 交付的其他计算机从队列中使用，POST 优化结果并将一些数据保存在 MongoDB 中。 +杰米（Jamie）：索尔（Solr）-也许您需要分片搜索引擎，但这可能比它的价值还多。 ;-) -![](img/475b21b40578cce1b0ca3fb4ad356893.png) +拉姆基：是的，我们已经记了这个。 -在 Kraken.io 帐户中交付了 Webhooks 视图 +杰米：使用 ActiveMQ，您是否考虑过将一些较轻的排队需求转移到 Redis？ 它具有可用于某些类型排队的原子构造，并且几乎可以肯定会更快。 -### 硬件 +Ramki：我们对 ActiveMQ 有点太深了。 它主要执行路由，服务抽象并为我们保证交付。 对于那些，我不会押注 Redis。 希望我回答了你的问题。 -图像优化和重新压缩具有巨大的处理要求。 由于我们一直在努力降低总拥有成本，因此对我们而言，云决不是一个选择。 通过与我们的数据中心签订相当长的合同，我们可以将托管费用减少 30％。 +Tal：这些“ NoSQL”文档存储为您直接的分布式文件系统添加的功能正是使搜索与数据保持同步的能力。 有趣的是，与“愚蠢”的文档存储（文件系统）相比，您实际上为此功能付出了高昂的代价。 在我看来，保持这种状态的关键是在 Solr 搜索和数据之间出现延迟。 您愿意允许多少时间？ -一小会儿，在投资购买自己的硬件之前，我们一直在租用专用机器。 那没有按预期工作。 当时，我们的提供商阻止了 OS 的重新部署，我们不得不采用痛苦而费时的电子邮件通信路径来重新部署系统。 另外，您不知道之前有谁在使用机器，机器的整体运行状况如何，以及内部“确实”安装了哪些组件。 有一天，我们发现，即使所有 API 机器都安装了相同的 CPU，但每台机器都有不同的 CPU 固件，并且 sysbench 的结果因机器而异。 +Ramki：如文章中所述，DFS 用作键值存储。 并且我们已经设置了 MQ 先写入存储然后再写入 Solr。虽然将其推入 Q 使其异步，但数据的移动在 Q 内部是顺序的。这样一来，您将无法获得返回任何不存在的内容的搜索 在存储中。 同样，假设存储节点位于本地附近，则数据会立即反映出来。 希望我回答了你的问题。 -幸运的是，这段时间已经过去很久了，我们在自己的硬件上运行，我们可以根据需要微调所有设置（尝试对租用设备进行 CPU 频率缩放）。 +Tal：考虑到这一点，对我来说，将 CouchDB 用作分布式文件系统似乎是个好主意。 我不敢相信它会比您使用的任何工具都要慢。 还有...继续使用 Solr！ 仅在需要同步搜索时才退回到 CouchDB“视图”。 -所有单插槽计算机（API，Web，负载均衡器，Webhook Delivery）当前正在运行 Xeon E3-1280 v5（Skylake）。 对于完成所有艰苦工作的 Optimization Cluster，我们每台计算机使用 2 个 Xeon E5-2697 v3，具有 128 GB RAM 和 RAID-1 设置中的四个 SSD 硬盘进行镜像。 在启用 HT 的情况下，上述设置使我们可以在每个群集计算机上访问 28 个物理核心和 56 个线程。 +Ramki：我们正在尝试使用 CouchDB 进行分析。 在开发环境中，我们的速度仅为每秒 1000 请求。 有了存储和轻松的设置，我们便可以轻松完成 8000+ reqs / s。 当然，1000 res / s 也是非常好的数字。 -![](img/d41c0aa27e19d2ca09b52376afced93e.png) +Tal：这似乎与“ NoSQL”的智慧几乎相反，但是从您的经验来看，这似乎是一个很好的实用结论。 -我们的优化人员之一（Xeon E5-2697） +Ramki：不确定是否与 NoSQL 相反。 原则上我们离它更近。 例如：没有“ sql” :)，几乎没有架构。 我说这几乎是因为 Solr 迫使我们拥有一些架构，分布式和键值之类的存储。 -英特尔最近为 [E5-2600 产品线](http://ark.intel.com/products/family/91287/Intel-Xeon-Processor-E5-v4-Family#@All) 推出了 v4（Haswell），我们正在对此进行研究，但并不急于将群集升级到 v4 。 +Maxim：您是在 4 刀片系统上直接处理 3900 Request / second，还是还包括 Akamai 流量？ -Kraken.io 的平台占用大量 CPU 和 I / O，对大量文件进行繁重的处理。 为了在 I / O 级别获得更高的性能，我们将在接下来的几个月中为 API，集群和存储计算机推出 PCIe-SSD 驱动器。 +Ramki：这里没有 Akamai。 它是我们所有的后端，不在 akamai 上。 一旦我们有了用于 URL 无效的缓存引擎和规则方法，我们将远远超过 3900 r / s。 我们的开发测试是 8500+ r / s 的清漆。 但是请记住，考虑到延迟，这些数字可能并不完全是我们将从外界得到的数字。 -![](img/03f3c40b55674ebe74d20048d4ee8179.png) +Maxim：您如何处理负载平衡？ -API，存储和优化集群 +拉姆基：这现在可以通过一种弯腰/麻木的方式来解决：)。 我们的资源有限，但是我们需要“无 SPOF”，因此我们在同一个 LB 内针对不同层有点循环。 考虑到 H / W LB 的成本，我们可能不得不采用这种方法。 我们正在寻找 S / W LB 作为替代方案，但我们需要使用刀片来部署它们！ :) -自己的硬件需要一定的价格。 而且这个价格是，即使在高峰时期，您也需要比实际需要的容量多很多。 订购，压力测试和部署新机器最多需要 7 天的时间。 我们提供了一个定制的 AWS 集成，它将为我们提供计算优化的实例并扩展优化集群。 幸运的是，即使我们发现集群计算机上的负载高达 60（每个线程 1.07），我们也从未使用过它。 该解决方案的缺点是，我们不仅必须为 AWS 实例支付额外费用，而且还必须为数据中心与 AWS 之间的额外流量支付额外费用。 +塔尔：您拥有什么样的“前端”基础架构？ -### 供应，发现和软件部署 +Ramki：我们也在这里迁移到基于 VM 的环境。 但是再过几个月，我们将完全使用 VM，并在我们现在构建的系统之上运行。 旧系统将被淘汰。 -我们安装的每台新计算机都由 [工头](http://theforeman.org/) 管理和配置。 我们将所有配置都保留在 [Puppet](https://puppet.com/) 中，因此只需单击几下即可使新机器进入生产就绪状态。 在 Puppet 中维护健康的代码库是另一个需要讨论的主题，尤其是在谈论定制软件包时。 +希望我已经回答了问题。 -通过 [Capistrano](http://capistranorb.com/) 进行软件部署。 因为所有应用程序都是用 Node 编写的，所以几乎所有应用程序都使用类似的配方。 当我们需要查明过去发生的特定部署并将其与 [中的可用数据关联时，与](https://www.serverdensity.com/) [Slack](https://slack.com/) 集成非常有用 ] ServerDensity 或 [ElasticSearch](https://www.elastic.co/) 。 +请确保提出建议。 我希望得到社区的反馈。 -![](img/789f0f90cf2f2ae722c7d6ab9b77ab6e.png) +-拉姆基 -Capistrano 的松弛集成 +嗨， +我研究的一件事是每秒 3900 req。 -### 数据存储 +您的每日网页价值为 1544943（http://www.websiteoutlook.com/www.sify.com）。 -我们在三台独立的机器上使用 [副本](https://docs.mongodb.com/manual/replication/) 设置中的 [MongoDB](https://www.mongodb.com/) 作为我们的主要数据存储。 由于我们的数据集相对较小，并且我们对所有时间序列数据都使用了封顶集合，因此我们从未真正考虑过 DB 分片。 当然，看着三分之二的 DB 机器几乎什么也不做，只是等待 Master 失败，这不是我喜欢的事情，但是当时间到来时（而且会这样），我们会睡得很好。 +因此，假设每位用户 5 次浏览量将带来每天 30 万用户或每小时 12500 位用户或每分钟 208 位用户。 -第二个数据存储是 [前哨](http://redis.io/topics/sentinel) 设置中的 [Redis](http://redis.io/) 出于与上述相同的原因）。 主要用作 Kraken.io 前端上的任务队列和会话管理的消息代理。 +或大约每秒 3 个用户访问服务器。 -### 文件存储 +所以我的问题是 3 个用户每秒可以生成 3900 个请求吗？ -在上一代 Kraken.io 中，我们曾经将优化的资产直接存储在执行优化工作的同一台计算机上。 在将角色（API，Web，处理群集和存储）分离之后，我们发现自己迫切需要可扩展的网络文件系统。 [GlusterFS](http://www.gluster.org/) 易于设置且易于维护。 +RB & GK：如前所述，整篇文章都是关于后端而不是前端。 正如您在我上面的评论中所看到的那样，“如果我们能够使前端数量大约相同，那将是非常棒的事情！” -从应用程序服务器到 GlusterFS 计算机，我们有数百万个图像通过网络传输。 对于我们而言，非常重要的一点是不要经常移动这些文件。 一旦保存在 Gluster 中，图像将停留在该位置，直到其自动删除为止。 +后端不仅会受到前端的攻击。 后端有许多直接 API 调用。 -说到-清理作业。 通过 API 优化的图像会在 1 小时后自动删除，而通过 Web Interface 处理的图像会在我们的系统中保留 12 个小时。 在存储计算机上运行的清除脚本需要首先统计所有目录，并选择 mtime > 1hr（或 mtime > 12hr 的 Web Interface）。 当您拥有数百万个目录时，对其进行简单的统计可能会花费大量时间，并且我们希望清理脚本能够快速运行。 可行的简单补救措施是将具有优化映像的目录放入另外三个级别的两字符目录中。 +因此，以上计算并不能完全转换为后端匹配。 -用作目标目录的原始文件 ID，例如 dd7322caa1a2aeb24109a3c61ba970d4 变为 dd / 73/22 / caa1a2aeb24109a3c61ba970d4 +也就是说，我们已经在开发前端，希望我们能达到接近后端的数字。 -这样，我们最多可以在第一，第二和第三层上遍历 255 个目录。 +如果你们在同一方面确实有一些投入，那就太好了。 -### 负载均衡器 +-ramki -外部和内部负载平衡器都是 [Nginx](http://nginx.org/) -基于 [Keepalived](http://www.keepalived.org/) 。 即使我们的两个外部环境都出现问题，内部的环境也会自动提升自己，也为公共交通服务。 这也有助于我们晚上入睡，并给我们时间用新机器从柏林到法兰克福旅行（飞行 1 小时）。 +工具的传播非常有趣。 您对文件系统复制器有何建议？ 你是怎样做的 ？ +我们在一个城市中拥有 Windows SAN 存储。 我们想将添加和删除的文件实时复制到另一个城市的另一个 Windows 框中。 仅当完全写入文件时，才应复制文件。 -我们在内部计算机上未使用任何 HTTP 服务器。 所有内部流量都从负载均衡器直接反向代理到 Node 应用程序。 要记住的一件事-Nginx 默认使用 HTTP 协议 1.0 作为 HTTP 代理。 将 proxy_http_version 标志设置为 1.1 可以节省很多麻烦，并且通常可以提高性能，尤其是对于长时间运行的保持活动连接。 +杰米：“ Lighty 曾经有内存泄漏。” -### 联网 +过去……过去……一段时间以前……这有什么意义？ +Apache 过去有一些问题，nginx 过去有一些问题。 +软件并不完美，并且会通过更新得到修复。 +我运行了一堆 lightys，它们处理几乎相同数量的静态文件请求（8000 req / s）而不会费力。 +以及 PHP 的一些 Hundret re / s 也没有问题。 -由于我们在上行链路级别（两个独立的 10 Gbps 上行链路）上也很冗余，因此每个机架至少需要两个交换机，每台机器至少需要两个以太网控制器。 随着机架的增长，每台计算机占用交换机上的五个端口（BMC，到控制器 1 的上行链路 A 和 B 和到控制器 2 的上行链路 A 和 B），当前我们在每个机架上运行四个 HP ProCurve 交换机。 +很多人将内存泄漏误认为是 Lighty 缓冲来自后端（例如 PHP）的请求。 因此，如果您通过 Lighty 从 PHP 发送 10MB 数据，它将使用 10MB。 并且它将重新使用此内存以供以后的请求使用。 +为什么这样做？ 好吧，它有助于加快请求的速度，因为您只有数量有限的 PHP 后端，否则这些后端将被速度较慢的客户端占用。 它可以更快地释放 PHP“插槽”。 +我会在任何时候减少使用 RAM 的情况。 +要记住的唯一事情是不要通过 lighty 通过 PHP 发送大文件，这反而是一个坏主意，因为它还有其他一些原因（为此使用 X-sendfile 标头或直接提供它们）。 -![](img/e10c297d02037a8efb5f0a6b9d03bcee.png) +因此，为了做出决定，而不是走“呃，但我听说有人过去有问题..”，而不得不*立即*并针对您的用例来研究它的工作方式。 -Kraken.io Architecture，2016 年 5 月 +我想讲的教训是：使用现在（以及将来当然）可以最好地完成任务的工具。 -### 监视和警报 +我以前曾经在 PHP 中看到过 100％CPU 的情况，这很奇怪，在某些情况下更新 PHP 很有帮助。 不幸的是，PHP 的 FastCGI 接口不如 mod_php 稳定。 但是它工作得很好。 -在上一代 Kraken.io 中，我们使用了 Sensu，Graphite 和 InfluxDB。 由于我们想将全部注意力转移到产品本身，而不是维护和监视监视工具（谁在监视正在监视它们的监视工具？），因此我们需要一种 SaaS 来减轻这种痛苦。 在测试了几项服务之后，我们最终选择了 [ServerDensity](https://www.serverdensity.com/) 作为我们所有机器的主要监视和警报工具，并且到目前为止，它仍然可以正常工作。 +Ramki：感谢您分享您的架构和经验教训，我发现无数据库方法特别有趣和令人耳目一新。 对 NoSQL 想法的深入了解可能不是更好的选择。 荣誉 -![](img/f4965c287ba863ff68f9a572930631d2.png) +没有， -ServerDensity 指标始终显示在我们的办公室中 +我不确定 websiteoutlook 的统计信息，但对于我知道其审计数的几个网站，它们显得有些低（10 倍）。 -作为一项附加措施，我们使用 [Pingdom](https://www.pingdom.com/) 进行正常运行时间和实时用户监视。 我们已经从 Pingdom 看到了一些误报，而解决之道只是增加警报失败所需的检查数量。 +无论如何，每月有 1.5 亿次页面浏览量（是网站外观数字的 3 倍），平均每秒 57 次页面浏览量。 3900 次/秒是每页浏览 68 次（您的 3 个用户（真正是 3.57 个用户）x 5 页/访问 x 不足 3 的因素）。 头版页面有 80 个元素，即使缓存率很高，考虑到高峰期和一个前端请求也会导致多个后端请求，因此乘数似乎并不是很大的乘数。 -### 数据挖掘 +广泛的数字对我来说似乎很合理。 -当我们尝试将支持的技术数量保持在最低限度时，我们使用了外部 ElasticSearch 提供程序。 平均每天，我们会发送 2GB 的日志以进行进一步处理和数据挖掘。 可以这样查询 ES 非常方便： +关于进行综合浏览和请求计算的人员： -“为我提供 800 Kb 以下的 JPEG 文件的优化结果，该文件具有嵌入式 ICC 配置文件，唯一颜色计数大于 10.000，用户 X 在 3 天前进行了无损优化”。 +将网页浏览量视为用户的完整呈现页面是很常见的，这反过来可能转换为针对后端的 1 到 50 个请求，具体取决于呈现页面所需的后端信息源的数量。 -在我们不断努力改进优化堆栈时，我们需要能够立即跟踪我们的部署结果。 在峰值负载下，只需在“优化群集”中进行一些细微调整即可，然后在几分钟内获得有意义的数据。 +您无法对它们进行计算，因为您将对苹果和梨进行计算。 +每月观看次数总计超过 30 天，而 3900 req / s 则是特定时刻的峰值 -### 摘要 +根据视图的数量和使用情况的一些假设，您可以计算出大约并发用户的平均数，该数量永远不会接近峰值时的并发用户数。 -如果您到目前为止做的不错，那将涵盖 Kraken.io 基础结构工程的有趣部分。 我们确信，随着我们的发展和订户数量的增长，我们将继续学习更多，希望您喜欢本文。 +您正在运行哪个 GFS 版本的 GFS1 或 GFS2？ 您将在文件系统中存储多少数据？ +我们曾经将许多数据存储在 GFS（1）中，但是由于可伸缩性问题而远离了它。 -[关于 HackerNews](https://news.ycombinator.com/item?id=11910151) +主要问题是锁定，无法扩展文件系统而没有停机时间以及对复制/冗余的不良/不存在的支持。 从那时起，我们的数据量已经增长到了惊人的水平。 1 PB。 +我也很好奇您用于在以下位置存储 GFS 数据的基本存储硬件：iscsi，光纤，AoE？ -我总是喜欢阅读有关图像优化的文章。 -但是在本文之后，我检查了 kraken.io 网站，以及所有可用的信息... :( +拉蒙 -总体来说不错。 尽管看到整条文章中散布着大量的“流行语”，这似乎是一种绝技。 不过，请欣赏本文的坦率。 +Mohan Radhakrishnan：您对文件系统复制器有何建议？ 你是怎样做的 ？ 我们在一个城市中拥有 Windows SAN 存储。 我们想将添加和删除的文件实时复制到另一个城市的另一个 Windows 框中。 仅当完全写入文件时，才应复制文件。 -对于正在为其 Web 应用程序寻求图像优化服务的人的旁注-现代 CDN 已经将此作为其产品的核心部分。 Instart Logic 特别提供了出色的图像优化服务，您可以利用专有算法利用它来转换图像，调整图像大小并降低图像质量。 +Ramki：我们已经尝试解决这个问题已有相当长的时间了。 到目前为止，我们仅在一个数据中心上运行，并且 GFS 集群安装在局域网中的 2-3 个节点上，因此其他节点可以立即看到每次写入。 鉴于此，我们没有复制问题。 -您可以在构建时压缩和缩小映像，然后可以由您选择的任何 CDN 进行选择。 这个过程已经使用了数十年。 +但是，我们已经在寻找在大约 800 英里之外的印度两个城市中部署应用程序的选项，我们希望使用主动-主动设置。 根据上下文，我们要求存储提供商在两个城市之间进行实时复制。 作为 ISP，我们的延迟相对较小（我认为），大约 40 毫秒。 即使有这种延迟，任何存储提供商都无法做到近乎实时。 有一家公司说我们可以做到，并要求他们证明这一点。 他们部署了箱子，这是灾难性的失败！ 当然，这都是异步复制，同步复制是同时关闭两个站点的最佳方法！ 玩笑！ :)同步锁定源文件系统，同步到另一个站点，其他站点锁定文件系统，写入，确认到源，源站点释放锁定。 在这段时间内，编写文件的客户端正在等待……您猜对了。 -这是我们今天在 [CircleHD](https://circlehd.com "CircleHD") 使用的一些工具 +总结： +-如果您的延迟超过 5 毫秒且实时，则任何存储提供商都无法做到这一点。 即使延迟对您来说较小，也请他们先进行证明。 +-构建您自己的复制系统。 保持异步。 -gifsicle-压缩 GIF 图像 -jpegtran-压缩 JPEG 图像 -optipng-压缩 PNG 图像 -svgo-压缩 SVG 图像 +我们现在正在考虑做的是： -@AgnivaDeSarker：我很好奇您在上一篇文章中有什么资格成为“流行语”？ \ No newline at end of file +我们已经将内容推送到 MQ。 现在，内容也将被推送到其他城市的另一个队列。 这样，几乎可以立即在两个位置复制数据。 然后我们将接受可能会有的轻微延迟。 我认为延迟将少于 5 秒，这比存储提供商建议的 10-15 分钟复制更好。 无论如何，我们必须自己进行测试。 我们拥有的一大优势是，甚至文件的删除也是 XML 请求，因此也要经过 Q。 + +对于较大的二进制文件（视频&图像），我们采用略有不同的方法。 所有这些都写入临时目录，并且守护程序将文件移动到适当的目录。 我认为有 2 个城市时，这不会给我们带来很多头痛。 除了基于 ESB / MTOM 的方法外，别无其他想法，并通过队列推送元数据。 + +Ramon：您正在运行哪个版本的 GFS 或 GFS2？ 您将在文件系统中存储多少数据？ +我们曾经将许多数据存储在 GFS（1）中，但是由于可伸缩性问题而远离了它。 + +主要问题是锁定，无法扩展文件系统而没有停机时间以及对复制/冗余的不良/不存在的支持。 从那时起，我们的数据量已经增长到了惊人的水平。 1 PB。 + +Ramki：我们在 GFS1 上遇到了同样的问题，我们现在在 GFS2 上。 但是，当我们必须在 VM 上运行节点时，仍然存在扩展问题。 支持的虚拟机数量不超过 2 个，添加集群的第 3 个节点有时会挂起。 也许这也是 GFS1 的问题，我们担心被吊死。 您对此有一些了解吗？ 当前数据大小约为 1.5 Tera。 我们尚未将旧内容迁移到新系统。 + +拉蒙：我也想知道您用来在 GFS 数据上存储 iscsi，光纤，AoE 的底层存储硬件吗？ + +Ramki：iSCSI + +希望答案。 + +-ramki + +您还将向用户提供电子邮件。 您是否还保留没有数据库的身份验证记录？ + +另外，你们使用哪个邮件服务器？ + +嗨 Ramki， + +想知道你们是否看过 AWS（http://aws.amazon.com）？ 在它们上运行会简化你们正在做的许多 VM 管理工作吗？ + +它们还提供了负载平衡和自动扩展解决方案（http://aws.amazon.com/autoscaling/）和队列服务（http://aws.amazon.com/sqs/）。 + +嗨，杜沙尔， + +我们查看了 AWS 的其他项目。 我们面临的最大问题是延迟。 我们不能忍受这种延迟。 + +除此之外： +-我们有自己的管道 +-我们在各个城市都有自己的数据中心。 +-我们已经在下文中介绍了许多内容。 + +因此，在我们的案例中，这实际上没有任何意义。 + +-ramki \ No newline at end of file diff --git a/docs/5.md b/docs/5.md index 6892500..3dd6a67 100644 --- a/docs/5.md +++ b/docs/5.md @@ -1,188 +1,93 @@ -# 每天为 1000 亿个事件赋予意义-Teads 的 Analytics（分析）管道 +# GoogleTalk 架构 -> 原文： [http://highscalability.com/blog/2018/4/9/give-meaning-to-100-billion-events-a-day-the-analytics-pipel.html](http://highscalability.com/blog/2018/4/9/give-meaning-to-100-billion-events-a-day-the-analytics-pipel.html) +> 原文： [http://highscalability.com/blog/2007/7/23/googletalk-architecture.html](http://highscalability.com/blog/2007/7/23/googletalk-architecture.html) -*这是 Teads.tv 的软件工程师* *[Alban Perillat-Merceroz](https://www.linkedin.com/in/albanperillatmerceroz/?locale=en_US)* *的来宾帖子。* +Google Talk 是 Google 的即时通讯服务。 有趣的是，IM 消息并不是主要的体系结构挑战，处理用户在场指示将主导设计。 他们还面临着处理小的低延迟消息并与许多其他系统集成的挑战。 他们是如何做到的呢？ -![](img/644055e22dfa3ea31613c9374bdc09b0.png) +网站：http：//www.google.com/talk -在本文中，我们描述了如何将 Kafka，Dataflow 和 BigQuery 一起编排以摄取和转换大量事件。 当添加规模和等待时间约束时，对它们进行协调和重新排序成为一个挑战，这是我们如何解决的。 +## 信息来源 -![](img/c0187dde2e79208a838aefd0599f99fc.png)Teads for Publisher, one of the webapps powered by Analytics +* [GoogleTalk Architecture](http://video.google.com/videoplay?docid=6202268628085731280) -在数字广告中，日常运营会产生许多我们需要跟踪的事件，以便透明地报告广告系列的效果。 这些事件来自： + ## 平台 -* 用户与与浏览器发送的广告的互动。 这些事件称为跟踪事件，可以是标准事件（开始，完成，暂停，继续等），也可以是自定义事件，这些事件来自使用 [Teads Studio](https://teads.tv/studio/) 构建的交互式广告素材。 我们每天大约收到 100 亿个跟踪事件。 -* 来自后端的事件大部分与广告拍卖的详细信息有关（实时出价过程）。 在采样之前，我们每天会产生超过 600 亿个此类事件，并且应当在 2018 年使这一数字增加一倍。 + * 的 Linux* 爪哇* Google Stack* Shard -在文章中，我们将重点放在跟踪事件上，因为它们是我们业务中最关键的路径。 + ## 里面有什么？ -![](img/20a9026ebf5723f0f7b7e98193a0f300.png)Simplified overview of our technical context with the two main event sources + ### 统计资料 -跟踪事件由浏览器通过 HTTP 发送到专用组件，该组件除其他外将它们排入 [Kafka](https://kafka.apache.org/) 主题。 Analytics 是这些事件的使用者之一（更多内容请参见下文）。 + * 支持数百万用户的状态和消息。* 每天在 100 毫秒内处理数十亿个数据包。* IM 与许多其他应用程序不同，因为请求是小的数据包。* 路由和应用逻辑适用于每个数据包的发送方和接收方。* 消息必须按顺序传递。* Architecture extends to new clients and Google services. -我们有一个分析团队，其任务是处理这些事件，其定义如下： + ## 得到教训 -> 我们摄取了越来越多的原木 + * 衡量正确的事情。 + -人们问您要交付多少 IM 或有多少活跃用户。 事实证明这不是正确的工程问题。 + -IM 的难点是，由于增长是非线性的，因此如何向所有连接的用户显示正确的状态：ConnectedUsers * BuddyListSize * OnlineStateChanges + -线性用户的增长可能意味着非常非线性的服务器增长，需要服务 每天有数十亿个状态数据包。 + -拥有大量的朋友，在线人数激增。 IM 的数量不是 + 的大问题。 -> 我们将它们转换为面向业务的数据， + * 实际负载测试 + -实验室测试虽然不错，但告诉您的信息还不够。 + -在实际产品发布之前进行了后端发布。 + -模拟状态请求，并在线和离线运行数周 + 和几个月，即使未返回真实数据也是如此。 它可以解决网络，故障转移等方面的许多 + 问题。 -> 我们为每个观众提供高效且量身定制的服务。 + * 动态重新分片 + -在分片上划分用户数据或加载。 + -Google Talk 后端服务器处理一部分用户的流量。 + -零停机时间轻松更改分片数量。 + -不要跨数据中心分片。 尝试使用户保持本地状态。 + -服务器可以关闭服务器，而备份可以接管。 然后，您可以启动新服务器并自动迁移数据，并且客户端会自动检测并转到新服务器。 -为了完成此任务，我们构建并维护了一组处理工具和管道。 由于公司的有机增长和对新产品的要求，我们经常挑战我们的体系结构。 + * 添加抽象以隐藏系统复杂性 + -不同的系统应该彼此之间几乎一无所知，尤其是当各个小组一起工作时。 + -Gmail 和 Orkut 不知道分片，负载平衡或故障转移，数据中心架构或服务器数量。 可以随时更改，而无需级联整个系统的更改。 + -将这些复杂性抽象到一组在运行时发现的网关。 + -RPC 基础结构应处理重新路由。 -## 为什么我们搬到 BigQuery + * 了解下层库的语义 + -一切都是抽象的，但是您仍然必须对它们如何工作以构建系统有足够的了解。 + -您的 RPC 是否创建到所有或某些服务器的 TCP 连接？ 含义截然不同。 + -磁带库性能是否正常检查？ 这是体系结构的含义，因为您可以使单独的系统独立发生故障。 + -您应该使用哪个内核操作？ IM 需要大量的连接，但几乎没有任何活动。 使用 epoll 与民意测验/选择。 -早在 2016 年，我们的 Analytics（分析）堆栈基于 [lambda 架构](http://lambda-architecture.net/)（Storm，Spark，Cassandra），但我们遇到了几个问题： + * 再次保护操作问题 + -消除服务器活动图中的所有分支。 + -服务器在使用空缓存重新启动时会发生什么？ + -如果流量转移到新的数据中心会怎样？ + -限制级联问题。 从繁忙的服务器返回。 生病时不接受工作。 + -隔离紧急情况。 不要让您的问题感染他人。 + -提取智能重试逻辑策略。 例如，不要坐在 1 毫秒的重试循环中。 -* 数据规模使得不可能将所有数据都存储在单个 Cassandra 表中，这阻止了有效的交叉查询， -* 这是一个复杂的基础架构，具有用于批处理层和速度层的代码重复，从而阻止了我们有效地发布新功能， -* 最后，难以扩展且成本效益不高， + * 任何可扩展系统都是分布式系统 + -为系统的每个组件添加容错功能。 一切都失败了。 + -增加了在不影响服务器的情况下分析活动服务器的功能。 允许持续改进。 + -从服务器收集指标以进行监视。 记录有关系统的所有内容，以便查看因果模式。 + -端到端记录，因此您可以在所有计算机上从头到尾重构整个操作。 -当时我们有几种可能的选择。 首先，我们可以构建一个增强的 lambda，但这只会推迟我们面临的问题。 + * 软件开发策略 + -确保二进制文件既向后又向前兼容，以便您可以让旧客户端使用新代码。 + -建立实验框架以尝试新功能。 + -使工程师可以使用产品机器。 赋予端到端所有权。 这与许多在其数据中心中拥有完全独立的 OP 团队的公司截然不同。 通常，开发人员无法接触生产机器。 -我们考虑了几种有前途的替代方案，例如 [Druid](http://druid.io/druid.html) 和 [BigQuery](https://cloud.google.com/bigquery/) 。 我们最终因其强大的功能而选择迁移到 BigQuery 。 +嗨，您好， -使用 BigQuery，我们能够： +我认识了 yahoo IM 团队的成员，而且开发人员还可以维护生产服务器。 -* 处理原始事件， -* 使用 SQL 作为一种有效的数据处理语言， -* 使用 BigQuery 作为处理引擎， -* 使对日期的解释性访问更容易（与 Spark SQL 或 Hive 相比）， +Google：开发人员还能维护搜索，Gmail 和其他产品的生产服务器吗？ -多亏了 [固定费用计划](https://cloud.google.com/bigquery/pricing#flat_rate_pricing) ，我们密集的使用（在查询和存储方面）具有成本效益。 +BR， +〜A -但是，我们的技术背景对于 BigQuery 而言并不理想。 我们想使用它来存储和转换来自多个 Kafka 主题的所有事件。 我们无法将 Kafka 群集移出 AWS 或使用 [Pub / Sub](https://cloud.google.com/pubsub/docs/overview) （在 GCP 上与 Kafka 托管的等效版本），因为这些群集也由我们托管在 AWS 上的某些广告投放组件使用。 结果，我们不得不应对运行多云基础架构的挑战。 +我从不厌倦研究 IM 协议，但是我一直认为状态包太小（可能只有几个字节），以致它们产生的流量完全少于确切的消息...现在我开始思考 是错误的，将在信息来源中观看该视频。 -今天， BigQuery 是我们的数据仓库系统，在这里我们的跟踪事件与其他数据源保持一致。 +附注：我想知道我是否会停止不断在此网站上找到有趣的帖子……真的很棒！ -## 摄取 - -在处理跟踪事件时，您面临的第一个问题是您必须无序处理，并且延迟未知。 - -事件实际发生的时间（事件时间）与系统观察到事件的时间（处理时间）之间的差为毫秒至几小时。 这些大的延迟并不是那么罕见，当用户在两次浏览会话之间失去连接或激活飞行模式时可能会发生。 - -![](img/63b800ae8b1a8a694796b91f7b588eb0.png)Difference between event time and processing time - -有关流数据处理挑战的更多信息，建议您看一下 Google Cloud Next '17 演讲« [在批处理和流处理之间来回移动](https://www.youtube.com/watch?v=PGTSZvBK8-Y) »，来自 Tyler Akidau （Google 的数据处理技术负责人）和 LoïcJaures（Teads 的联合创始人兼 SVP Technology）。 本文受此演讲启发。 - -## 流媒体的艰难现实 - -[数据流](https://cloud.google.com/dataflow/?hl=en)是一种托管流系统，旨在解决事件的混乱性质，以解决我们面临的挑战。 Dataflow 具有统一的流和批处理编程模型，流是旗舰功能。 - -我们按照 Dataflow 的承诺被出售，并坦率地尝试了流模式。 不幸的是，在将其投入实际生产流量后，我们意外地感到惊讶： BigQuery 的流媒体插入成本。 - -我们是根据压缩数据大小（即通过网络的实际字节数）而不是 BigQuery 的原始数据格式大小来估算的。 幸运的是，现在已记录在中，用于[每种数据类型](https://cloud.google.com/bigquery/pricing#data)。因此您可以进行数学计算。 - -那时，我们低估了这笔额外费用 100 倍，这几乎使我们整个提取流程（Dataflow + BigQuery）的费用增加了一倍。 我们还面临其他限制，例如 [100,000 个事件/秒速率限制](https://cloud.google.com/bigquery/quotas#streaminginserts)，这很危险地接近我们所做的事情。 - -好消息是，有一种方法可以完全避免流插入限制：批量加载到 BigQuery 中。 - -理想情况下，我们希望将数据流以流方式与 BigQuery 以批处理方式一起使用。 那时，Dataflow SDK 中没有没有 BigQuery 批处理接收器用于无限制的数据流。 - -然后，我们考虑开发自己的自定义接收器。 不幸的是，当时无法向无界数据流添加自定义接收器（请参阅 [Dataflow 计划添加对在未来版本](https://cloud.google.com/dataflow/model/custom-io)中写入无界数据的自定义接收器的支持-BeamBeam 现在有可能 是官方的 Dataflow SDK）。 - -我们别无选择，只能将我们的数据流作业切换到批处理模式。 多亏了 Dataflow 的统一模型，仅需几行代码即可。 对我们来说幸运的是，我们能够承受因切换到批处理模式而引入的额外数据处理延迟。 - -展望未来，我们当前的摄取架构基于 [Scio](https://github.com/spotify/scio) ，这是 Spotify 开源的用于数据流的 Scala API。 如前所述，Dataflow 本机支持 Pub / Sub，但 Kafka 集成还不成熟。 我们必须扩展 Scio 以实现偏移量检查点持久性并实现有效的并行性。 - -## 微量批次管道 - -我们得到的架构是一个由 30 分钟的 Dataflow 批处理作业组成的链，这些作业按顺序安排为读取 Kafka 主题并使用加载作业写入 BigQuery。 - -![](img/72b2a0e7c7fe9a786028828e2a6653de.png)Phases of a Dataflow micro batch - -关键之一是找到理想批次持续时间。 我们发现在成本和读取性能（因此延迟）之间具有最佳折衷的最佳选择。 要调整的变量是 Kafka 读取阶段的持续时间。 - -为了获得完整的批处理持续时间，您必须将写入操作添加到 BigQuery 阶段（不成比例，但与读取持续时间紧密相关），并添加一个常数，即引导和关闭持续时间。 - -值得注意的是： - -* 读取阶段太短会降低读取阶段和非读取阶段之间的比率。 在理想的世界中，1：1 的比例意味着您必须能够像写作一样快地阅读。 在上面的示例中，我们有一个 20 分钟的读取阶段，一个 30 分钟的批处理（比率为 3：2）。 这意味着我们必须能够比写入速度快 1.5 倍。 较小的比率意味着需要更大的实例。 -* 太长的读取阶段只会增加事件发生到 BigQuery 可用之间的延迟。 - -## 性能调优 - -数据流作业是按顺序启动的，这是出于简单原因和更容易进行故障管理。 这是我们愿意采取的延迟权衡。 如果作业失败，我们只需返回到最后提交的 Kafka 偏移量即可。 - -我们必须修改 Kafka 群集的拓扑，并增加分区数量，以便能够更快地对邮件进行堆栈。 根据您在数据流中进行的转换，限制因素很可能是处理能力或网络吞吐量。 为了实现高效的并行性，您应始终尝试保持一定数量的 CPU 线程数作为分区数量的除数（推论：最好有很多[数量多的 Kafka 分区 复合数字](https://en.wikipedia.org/wiki/Highly_composite_number)）。 - -在极少的延迟情况下，我们可以使用更长的读取序列来微调作业。 通过使用更大的批次，我们还能够以延迟为代价来赶上延迟。 - -为了处理大多数情况，我们将 Dataflow 的大小设置为能够读取的速度比实际速度快 3 倍。 使用单个 [*n1-highcpu-16*](https://cloud.google.com/compute/docs/machine-types) 实例读取 20 分钟可以释放 60 分钟的邮件。 - -![](img/ad393f69ffa4ca6fa369cd78ede3c676.png)Ingestion latency (minutes) over time - -在我们的用例中，我们以锯齿延迟结束，该锯齿延迟在 3 分钟（Write BQ 阶段的最小持续时间）和 30 分钟（作业的总持续时间）之间振荡。 - -## 转型 - -原始数据不可避免地会庞大，我们有太多事件，无法按原样查询。 我们需要汇总这些原始数据以保持较低的*读取时间*和紧凑的卷。 这是我们在 BigQuery 中的处理方式： - -![](img/b58107688335905bb09021ea2a46af35.png)Architecture overview spanning between AWS and GCP - -与传统的 [ETL 流程](https://en.wikipedia.org/wiki/Extract,_transform,_load)之前的数据*转换*之前，*加载*之前，我们选择先将其（ELT）原始存储 格式。 - -它有两个主要优点： - -* 它使我们能够访问每个原始事件，以进行精细的分析和调试， -* 通过让 BigQuery 使用简单但功能强大的 SQL 方言进行转换，它简化了整个链。 - -我们本来希望直接写入每天分区的*原始事件*表。 我们之所以无法这样做，是因为必须使用特定的目的地（表或分区）定义数据流批处理，并且其中可能包含用于不同分区的数据。 我们通过将每个批次加载到临时表中然后开始对其进行转换来解决此问题。 - -对于这些临时批处理表中的每一个，我们运行一组转换，具体化为输出到其他表的 SQL 查询。 这些转换之一只是将所有数据追加到按天划分的大型原始事件表中。 - -这些转换的另一个是汇总：给定一组维度的数据汇总。 所有这些转换都是幂等的，可以在发生错误或需要数据重新处理的情况下安全地重新运行 。 - -## 汇总 - -直接查询原始事件表对于调试和深度分析非常有用，但是查询这种规模的表不可能获得可接受的性能，更不用说这种操作的[成本](https://cloud.google.com/bigquery/pricing)了。 - -为了让您有个想法，此表仅保留 4 个月，包含 1 万亿个事件，大小接近 250TB 。 - -![](img/de005b063f1b1942402b33713fd45d92.png)Example of a rollup transformation - -在上面的示例中，我们汇总了 3 个维度的事件计数：*小时*，*广告 ID* 和*网站 ID* 。 事件也被透视并转换为列。 该示例显示尺寸缩小了 2.5 倍，而实际情况更接近 70 倍。 - -在 BigQuery 的大规模并行上下文中，查询运行时的影响不大，改进程度取决于所使用的广告位数量。 - -汇总还使我们可以将数据划分为小块：在给定的小时（事件时间的小时，而不是处理时间）中，事件被分组到小表中。 因此，如果您需要查询给定时间的数据，则将查询一个表（< 10M 行，< 10GB）。 - -汇总是一种通用汇总，我们可以在给定大量维度的情况下更高效地查询所有事件。 在其他一些用例中，我们需要专用的数据视图。 他们每个人都可以实施一组特定的转换，以最终得到一个专门的优化表。 - -## 托管服务的限制 - -BigQuery 功能强大，但有其局限性： - -* BigQuery 不允许查询具有[不同架构](https://cloud.google.com/bigquery/docs/querying-wildcard-tables#schema_used_for_query_evaluation)的多个表（即使查询未使用不同的字段）。 当需要添加字段时，我们有一个脚本可以批量更新数百个表。 -* BigQuery [不支持列删除](https://stackoverflow.com/a/45822880)。 没什么大不了的，但无助于偿还技术债务。 -* 查询多个小时：BigQuery [支持表名](https://cloud.google.com/bigquery/docs/querying-wildcard-tables#best_practices)中的通配符，但是性能太差了，我们必须生成查询以 UNION ALL 显式查询每个表。 -* 我们始终需要将这些事件与托管在其他数据库上的数据结合起来（例如，将事件与广告活动的更多信息结合在一起），但是 BigQuery 不支持（目前）。 我们目前必须定期将整个表复制到 BigQuery，以便能够在单个查询中联接数据。 - -## 云间数据传输的乐趣 - -借助 AWS 中 Teads 的广告投放基础设施以及与许多其他组件共享的 Kafka 集群，我们别无选择，只能在 AWS 和 GCP 云之间移动大量数据，这并不容易，而且肯定不会 贱。 我们将 Dataflow 实例（因此是主要 GCP 入口点）放置在离我们 AWS 基础设施尽可能近的位置，幸运的是，AWS 和 GCP 之间的现有链接足够好，因此我们可以简单地使用托管 VPN。 - -尽管我们在运行这些 VPN 时遇到了一些不稳定因素，但是我们还是设法使用一个简单的脚本将其关闭然后重新打开，以进行分类。 我们从来没有遇到足够大的问题来证明专用链接的成本合理。 - -再一次，[成本是您必须密切注意的](https://medium.com/teads-engineering/real-life-aws-cost-optimization-strategy-at-teads-135268b0860f)成本，并且就出口而言，很难在看到账单之前进行评估。 仔细选择压缩数据的方式是降低这些成本的最佳方法之一。 - -## 只有一半 - -![](img/0c863e9acd95a34a7cbf4928a1f49f10.png)Teads’ Analytics big picture - -在 BigQuery 中仅包含所有这些事件还不够。 为了为业务带来价值，必须使用不同的规则和指标对数据进行合并。 此外，BigQuery 并非针对实时用例量身定制。 - -由于并发限制和 3 到 5 秒钟的不可压缩查询延迟（这是其设计的可接受和固有的），因此必须将 BigQuery 与其他工具（服务于仪表板，Web UI 等）组合使用。 - -此任务由我们的 Analytics 服务执行，这是一个 Scala 组件，可利用 BigQuery 生成按需报告（电子表格）和量身定制的数据集市（每天或每小时更新）。 需要此特定服务来处理业务逻辑。 否则很难维护为 SQL 并使用管道转换生成数据集市。 - -我们选择了 AWS [Redshift](https://aws.amazon.com/redshift/) 来存储和服务我们的数据集市。 尽管服务面向用户的应用似乎不是一个显而易见的选择，但是 Redshift 对我们有用，因为我们的并发用户数量有限。 - -同样，使用键/值存储将需要更多的开发工作。 通过保留中间关系数据库，可以简化数据集市的使用。 - -在上有很多话要说，我们如何以规模构建，维护和查询这些数据集市，但这将是另一篇文章的主题。 - -* * * - -如果您喜欢，大规模事件处理和与 Analytics（分析）相关的挑战，请大声疾呼。 我们正在积极[寻找](https://teads.tv/teads-jobs/)，以供工程师构建未来的架构。 \ No newline at end of file +当他们进入市场时，他们要晚于 msn 和 yahoo，但他们必须做很多工作才能将自己推向市场。 +----- +[http://underwaterseaplants.awardspace.com“](海洋植物 +[http://underwaterseaplants.awardspace.com/seagrapes.htm“](海葡萄... [http://underwaterseaplants.awardspace.com/seaweed .htm”](海藻 \ No newline at end of file diff --git a/docs/50.md b/docs/50.md index dcd0cbe..f3d8921 100644 --- a/docs/50.md +++ b/docs/50.md @@ -1,200 +1,152 @@ -# Twitter 如何每秒处理 3,000 张图像 +# 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训 -> 原文： [http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html) +> 原文： [http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html](http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html) -![](img/500a76b4aabec6690f90dc3c55a27a21.png) +![](img/9351627c2ec5806610f7f7f5c93909d3.png) [社交新闻网站](http://en.wikipedia.org/wiki/Steve_Huffman) [Reddit](http://www.reddit.com/) 的共同创始人史蒂夫·霍夫曼做了出色的[演示文稿](http://vimeo.com/10506751)。（[幻灯片](http://www.slideshare.net/carsonified/steve-huffman-lessons-learned-while-at-redditcom)和[文字](http://carsonified.com/blog/dev/steve-huffman-on-lessons-learned-at-reddit/) ），学习他在将 Reddit 建立和发展到每月有 750 万用户，每月有 2.7 亿页面浏览以及 20 多个数据库服务器的过程中吸取的教训。 -今天，Twitter 正在每秒创建并永久保存 3,000 张（200 GB）图像。 更好的是，由于媒体存储政策的改进，2015 年 Twitter 节省了 600 万美元。 +史蒂夫（Steve）说，很多课程确实很明显，因此您可能在演示文稿中找不到很多全新的想法。 但是史蒂夫对他有一种真诚和真诚，这显然是建立在经验基础上的，以至于您不禁要深思一下自己可能会做些什么。 如果史蒂夫不了解这些课程，我敢打赌其他人也不会。 -并非总是如此。 2012 年的 Twitter 主要基于文本。 霍格沃茨没有在墙上挂满所有酷炫的动态图像。 现在是 2016 年，Twitter 已经进入了一个拥有丰富媒体的未来。 Twitter 已经通过开发新的*媒体平台*进行了过渡，该平台可以支持带有预览的照片，多张照片，GIF，藤蔓和嵌入式视频。 +有七个课程，每个课程都有自己的摘要部分：第一课：经常崩溃； 第二课：服务分离； 第 3 课：开放式架构； 第四课：保持无状态； 第 5 课：内存缓存； 第 6 课：存储冗余数据； 第 7 课：脱机工作。 -Twitter 的软件开发工程师 [Henna Kermani](https://www.linkedin.com/in/henna-kermani-27701146) 在 [Mobile @上进行了有趣的演讲，讲述了媒体平台的故事 伦敦规模](https://www.atscalelondon.co.uk/) ： [每秒 3,000 张图像](https://code.facebook.com/posts/1566627733629653/mobile-scale-london-recap/) 。 演讲主要集中在图像管道上，但她说大多数细节也适用于其他形式的媒体。 +到目前为止，其体系结构最令人惊讶的功能是在第六课中，其基本思想是：速度的关键是预先计算所有内容并将其缓存。 他们将预计算[旋钮最多旋转 11](http://en.wikipedia.org/wiki/Up_to_eleven) 。 听起来您在 Reddit 上看到的几乎所有内容都已被预先计算和缓存，无论它们需要创建多少版本。 例如，当有人提交链接时，他们会预先计算所有 15 种不同的排序顺序（热门，新，热门，旧，本周等）以用于列表。 通常，开发人员会害怕走极端，浪费时间。 但是他们认为浪费前期总比拖延慢。 **浪费磁盘和内存比让用户等待**更好。 因此，如果您一直坚持下去，请转到 11，这是一个很好的先例。 -这次演讲中一些最有趣的教训： +## 第一课：经常崩溃 -* **做可能可行的最简单的事情确实会使您陷入困境**。 上载带有图像的 tweet 的简单方法是“全有或全无”操作，是一种锁定形式。 它的伸缩性不好，尤其是在网络较差的情况下，这使得 Twitter 很难添加新功能。 +本课的实质是：**自动重新启动失败的癌性服务**。 -* **解耦**。 通过将媒体上传与推文脱钩，Twitter 能够独立地优化每种途径，并获得了许多运营灵活性。 +在 colo 中运行自己的系统的不利之处在于您需要进行维护。 服务中断后，您必须立即修复，即使在凌晨 2 点。 这是您生活中持续不断的紧张感。 您必须随身携带一台计算机，并且您知道，任何时候只要有人打来电话，那都是您必须解决的另一场灾难。 它毁了你的生活。 -* **移动不处理斑点**。 请勿在系统中传输大量数据。 它占用了带宽，并为每个必须处理数据的服务带来了性能问题。 而是存储数据并使用句柄引用它。 +缓解此问题的一种方法是重新启动过程，该过程已经死亡或变得癌变。 Reddit 使用[监督](http://cr.yp.to/daemontools/supervise.html)自动重启应用程序。 特殊的监视程序会杀死使用过多内存，使用过多 CPU 或无响应的进程。 不必担心，只需重新启动即可启动系统。 当然，您必须阅读日志并找到根本原因，但是在那之前，它会使您保持理智。 -* 移至**分段可恢复上传**导致媒体上传失败率大大降低。 +## 第 2 课：服务分离 -* **实验和研究**。 Twitter 通过研究发现，图像变体（缩略图，小图像，大图像等）的 20 天 TTL（生存时间）是一个最佳选择，在存储和计算之间取得了很好的平衡。 映像在 20 天后被访问的可能性很小，因此可以将其删除，**每天节省近 4TB 的数据存储量**，**几乎减少了一半** **所需的计算服务器数量** ，每年可节省数百万美元。 +本课的实质是：**将过程和数据分组在不同的盒子**上。 -* **按需**。 可以删除旧的图像变体，因为它们可以即时重新创建而不是预先计算。 按需执行服务可提高灵活性，使您对执行任务的方式更加了解，并提供集中控制点。 +在一个盒子上做太多的工作会导致**在作业**之间进行大量上下文切换。 尝试使每个数据库服务器以相同的方式服务于相同类型的数据库。 这意味着您的所有索引都将被缓存，并且不会被调入和调出。 保持所有内容尽可能相似。 不要使用 Python 线程。 他们很慢。 他们将所有内容放在单独的多个流程中。 垃圾邮件，缩略图等服务可查询缓存。 它使您可以轻松地将它们放在不同的计算机上。 您已经解决了流程之间通信的问题。 一旦解决，它就可以保持体系结构整洁，并且易于扩展。 -* **渐进 JPEG** 作为标准图像格式是真正的赢家。 它具有强大的前端和后端支持，并且在速度较慢的网络上表现非常出色。 +## 第 3 课：开放式架构 -Twitter 走向富媒体的未来之旅中发生了许多美好的事情，让我们了解一下他们是如何做到的... +本课程的本质是：**不必担心模式**。 -## 旧方法-2012 年的 Twitter +他们过去经常花费大量时间来担心数据库，以保持一切正常和正常。 **您不必担心数据库**。 当您变大时，架构更新将非常缓慢。 将一列添加到一千万行需要锁定，因此不起作用。 他们使用复制进行备份和扩展。 模式更新和维护复制是一件痛苦的事情。 他们将不得不重新启动复制，并且可能一天没有备份。 部署是一件痛苦的事情，因为您必须协调新软件和新数据库的升级方式。 -### 写入路径 +相反，他们保留了事物表和数据表。 Reddit 中的所有内容都是事物：用户，链接，评论，subreddit，奖项等。事物具有共同的属性，例如上下投票，类型和创建日期。 数据表具有三列：事物 ID，键，值。 每个属性都有一行。 标题，URL，作者，垃圾邮件票等都有一行。当他们添加新功能时，他们不必再担心数据库了。 他们不必为新事物添加新表，也不必担心升级。 更易于开发，部署，维护。 代价是您不能使用很棒的关系功能。 数据库中没有联接，您必须手动执行一致性。 没有联接意味着将数据分发到不同的机器真的很容易。 您不必担心外键正在执行联接或如何拆分数据。 工作得很好。 使用关系数据库的烦恼已经成为过去。 -* 用户在应用程序中撰写推文，并可能在其中附加图像。 +## 第 4 课：保持无状态 - * 客户端将推文发布到整体端点。 该图像将与所有其他推特元数据捆绑在一起上传，并传递到流程中涉及的每个服务。 +目标是让每个应用服务器处理每种类型的请求。 随着他们的成长，他们拥有更多的计算机，因此他们不再依赖于应用内服务器缓存。 他们最初将状态复制到每个应用程序服务器，这浪费了内存。 他们无法使用内存缓存，因为它们保留了大量的细粒度文件，这太慢了。 他们重写使用内存缓存，并且不将任何状态存储在应用服务器中。 如果应用服务器发生故障，则很容易。 为了扩展，您可以添加更多应用服务器。 - * 这个端点是旧设计中很多问题的根源。 +## 第 5 课：内存缓存 -* **问题＃1** ：大量浪费的网络带宽 +本课的实质是：**内存缓存所有内容**。 - * 发推文的创建和媒体上载紧密地结合到一个操作中。 +它们将所有内容存储在内存缓存中：1.数据库数据 2.会话数据 3.呈现的页面 4.记忆（记住以前计算的结果）内部功能 5.限制用户操作，爬网程序的速率 6.存储预先计算的列表/页面 7.全局 锁定。 - * 正在上传，上传完全成功或完全失败。 由于任何原因导致的故障，网络故障，瞬态错误等，都要求整个上载过程从头开始重新启动，包括媒体上载。 上载可以完成 95％，如果失败，则必须重新上载所有内容。 +他们现在在 Memcachedb 中存储的数据比 Postgres 多。 就像记忆快取一样，但是会储存在磁碟上。 非常快。 所有查询均由同一控件生成，并缓存在 memcached 中。 更改密码链接和关联状态被缓存 20 分钟左右。 验证码也一样。 用于他们不想永久存储的链接。 -* **问题 2** ：对于新的较大尺寸的介质，无法很好地扩展 +他们在其框架中内置了备忘录。 计算结果也将被缓存：标准化页面，列表，所有内容。 - * 这种方法无法扩展到视频等大型媒体。 较大的文件会增加失败的可能性，尤其是在新兴市场（如巴西，印度，印度尼西亚）网络缓慢且不可靠的地方，他们确实希望提高推文上传成功率。 +使用 memcache +到期日期对所有内容进行速率限制。 保护您的系统免受攻击的好方法。 没有速率限制子系统，单个恶意用户可能会破坏系统。 不好。 因此，对于用户和爬网程序，他们将很多内容保留在内存缓存中。 如果用户在一秒钟内再次出现，他们将被弹跳。 普通用户的点击速度不太快，因此他们希望引起注意。 Google 搜寻器会以您希望的速度打击您，因此，当速度变慢时，只需提高限速器的速度，即可使系统安静下来而不会伤害用户。 -* **问题 3** ：内部带宽使用效率低下 +Reddit 上的所有内容都是清单：首页，方框中的评论页。 所有这些都预先计算并转储到缓存中。 当您获得列表时，它将从缓存中获取。 每个链接和每个注释可能都存储在 100 个不同的版本中。 例如，具有 30 秒钟旧 2 票的链接是单独呈现和缓存的。 播放 30 秒后会再次呈现。 等等。 HTML 的每个小片段都来自缓存，因此不会浪费 CPU 渲染时间。 当事情变慢时，只需添加更多缓存即可。 - * 连接到 TFE 的端点，即 Twitter 前端，用于处理用户身份验证和路由。 用户被路由到图像服务。 +当弄乱他们脆弱的不一致数据库时，他们使用内存缓存作为全局锁。 为他们工作甚至认为这不是最好的方法。 - * 图像服务与 Variant Generator 对话，后者生成不同大小（例如小，中，大，缩略图）的图像实例。 这些变体存储在 BlobStore 中，BlobStore 是为大型有效负载（如图像和视频）优化的键值存储。 这些图像永远存在。 +## 第 6 课：存储冗余数据 - * 创建和保留推文的过程中还涉及许多其他服务。 因为端点是整体的，将媒体与推文元数据结合在一起，所以该捆绑包也流经所有服务。 如此大的有效负载被传递给了不直接负责处理图像的服务，它们不是媒体管道的一部分，但仍被迫进行优化以处理大型有效负载。 这种方法在内部带宽方面效率很低。 +本课程的实质是：**速度的关键是预先计算所有内容并将其缓存**。 -* **问题 4** ：膨胀的存储空间 +建立慢速网站的方法是拥有一个完全标准化的数据库，按需收集所有内容，然后进行渲染。 它永远需要每个单独的请求。 因此，如果您有可能以几种不同格式显示的数据（例如首页，收件箱或个人资料中的链接），请分别存储所有这些表示形式。 因此，当有人来获取数据时，该数据已经存在。 - * 不再需要几个月和几年前发布的推文中的图像，这些图像将永久存在于 BlobStore 中，从而占用了空间。 即使有时删除推文时，图像也会保留在 BlobStore 中。 没有垃圾收集。 +每个列表都有 15 个不同的排序顺序（本周热门，新，热门，旧）。 当某人提交链接时，他们会重新计算该链接可能影响的所有可能的列表。 前期可能有点浪费，但前期浪费比缓慢要好。 浪费磁盘和内存比让用户等待更好。 -### 读取路径 +## 第 7 课：脱机工作 -* 用户看到一条推文以及与之相关的图像。 图片从何而来？ +本课程的本质是：**在后端上进行最少的工作，并告诉用户您已完成**。 -* 客户端从 CDN 请求图像的变体。 CDN 可能需要询问图像的来源 TFE。 这最终将导致在 BlobStore 中直接查找特定大小的 URL 的图像。 +如果您需要做某事，请在用户不在等您时进行。 放入队列中。 当用户对可更新列表的 Reddit 进行投票时，该用户的 Karma 以及许多其他内容。 因此，一经表决，数据库便会更新以知道发生了表决，然后将作业放入队列中，该作业知道需要更新的 20 件事。 当用户回来时，一切都已经为他们预缓存了。 -* **问题 5** ：不可能引入新的变体 +他们离线进行工作：1.预计算清单 2.提取缩略图 3.检测作弊。 4.删除垃圾邮件 5.计算奖励 6.更新搜索索引。 - * 设计不是很灵活。 添加新的变体，即大小不同的图像，将需要为 BlobStore 中的每个图像回填新的图像大小。 没有随需应变的设施。 +用户正在等待您时，无需执行**这些操作。 例如，随着 Reddit 变得越来越大，现在作弊的动机越来越高，因此当人们投票检测作弊时，他们在后端花费了大量时间。 但是它们确实是在后台运行的，因此不会降低用户体验。 演示文稿中的体系结构图为：![](img/8358e9974e52fb2c996b8842c45df356.png)** - * 缺乏灵活性使 Twitter 很难在客户端上添加新功能。 +蓝色箭头表示当请求进入时发生的情况。假设某人提交了链接或投票，它将转到高速缓存，主数据库和作业队列。 然后他们返回给用户。 然后其余的事件会离线发生，这些由粉红色箭头表示。 诸如 Spam，Precomputer 和 Thumnailer 之类的服务从队列中读取，进行工作并根据需要更新数据库。 关键技术是 RabbitMQ。 -## 新方法-2016 年的 Twitter - -### The Write Path - -#### 将媒体上传与发帖分离。 - -* 上传的内容为头等公民。 创建了一个上传端点，唯一的责任是将原始媒体放入 BlobStore - -* 这在处理上传方式方面提供了很大的灵活性。 - -* 客户端与 TFE 对话，后者与 Image Service 对话，后者将图像放入 BlobStore 中并将数据添加到元数据存储中。 而已。 没有涉及其他隐藏服务。 没有人在处理媒体，没有人在传递媒体。 - -* 从图像服务返回 mediaId（媒体的唯一标识符）。 当客户想要创建推文，DM 或更新其个人资料照片时，mediaId 将用作引用媒体的句柄，而不是提供媒体。 - -* 假设我们要使用刚刚上传的媒体创建一条推文。 流程如下： - - * 客户端点击更新端点，并在发布中传递 mediaId； 它将到达 Twitter 前端； TFE 将路由到适合于所创建实体的服务。 对于推文，它是 TweetyPie。 DM 和配置文件有不同的服务； 所有服务将与图像服务对话； 图像服务器具有处理诸如人脸检测和儿童色情检测之类的功能的后处理队列。 完成此操作后，Image Service 与 ImageBird 对话以获取图像，或与 VideoBird 对话以获取视频； ImageBird 将生成变体； VideoBird 将进行一些转码； 生成的任何媒体都将放入 BlobStore。 - - * 没有媒体通过。 节省了大量浪费的带宽。 - -#### 分段的可恢复上传。 - -* 走进地铁，在 10 分钟后出来，上传过程将从停止的地方恢复。 对用户而言是完全无缝的。 - -* 客户端使用上载 API 初始化上载会话。 后端将为它提供一个 mediaId，该 ID 是整个上传会话中要使用的标识符。 - -* 图像分为多个部分，例如三个部分。 使用 API​​附加分段，每个追加调用给出分段索引，所有附加都针对相同的 mediaId。 上载完成后，上载完成，可以使用媒体了。 - -* 这种方法对于网络故障更具弹性。 每个细分都可以重试。 如果网络由于任何原因而掉线，您可以暂停并取回网络恢复时停在的网段。 - -* 具有巨大收获的简单方法。 对于文件> 50KB，巴西的图像上传失败率下降了 33％，印度为 30％，印度尼西亚为 19％。 - -### The Read Path - -#### 推出了名为 MinaBird 的 CDN 原始服务器。 - -* MinaBird 可以与 ImageBird 和 VideoBird 对话，因此，如果不存在图像大小变体和视频格式变体，则可以即时生成它们。 - -* MinaBird 在处理客户端请求方面更流畅，更动态。 例如，如果有《数字千年版权法案》下架，很容易阻止访问或重新启用对特定媒体的访问。 - -* Twitter 能够即时生成变体和代码转换，因此 Twitter 在存储方面变得更加聪明。 - - * 按需变量生成意味着不需要将所有变量存储在 BlobStore 中。 巨大的胜利。 - - * 原始图像将保留直到删除。 变体仅保留 20 天。 Media Platform 团队针对最佳有效期限进行了大量研究。 所有请求的图像中大约有 50％的时间最多为 15 天左右。 保留比这更旧的图像会导致收益递减。 没人会要求使用较旧的媒体。 15 天后尾巴很长。 - - * 由于没有 TTL（生存时间），没有过期，因此媒体存储每天的存储量每天增长 6TB。 这种按需生成所有变体的惰性方法导致每日存储增长 1.5TB。 20 天的 TTL 使用的存储空间不会比惰性方法多得多，因此在存储空间方面并不会花费太多，但是在计算方面这是一个巨大的胜利。 使用懒惰的方法来计算读取的所有变体将需要每个数据中心使用 150 台 ImageBird 机器，而使用 20 天 TTL 则需要 75 台左右。 因此 20 天的 TTL 是最佳选择，可以在存储和计算之间取得良好的平衡。 +## 相关文章 - * 由于节省存储空间和计算就是节省资金，2015 年 Twitter 通过引入 20 天 TTL 节省了 600 万美元。 +* [关于可扩展性的队列相关文章](http://highscalability.com/blog/category/queue) +* [](http://highscalability.com/blog/category/queue)**[Reddit 于 2010 年 5 月发布的“服务器状态”报告](http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html)** -#### 客户端改进（Android） +对我而言，最有趣的部分是数据库中糟糕的 EAV 解决方案。 不带模式和模式验证的所有内容都作为字符串。 这通常会导致维护和效率方面的一些可怕问题，但这一次它可以正常工作。 可能是因为该模型非常简单，在其他许多情况下却无法正常工作 -* 使用 Google 创建的图像格式 [WebP](https://en.wikipedia.org/wiki/WebP) 进行了为期 6 个月的实验。 +很棒的文章！ 绝对提供了一些非常新的性能思考方式。 - * 图像平均比相应的 PNG 或 JPEG 图像小 25％。 +“但是它们确实是在后台运行的，因此不会降低用户体验” - * 锯增加了用户的参与度，尤其是在新兴市场中，在这些新兴市场中，较小的图像尺寸会降低网络压力。 +“但是他们活着” - * iOS 不支持。 +“现场直播” - * 仅在 Android 4.0+上受支持。 +好文章！ 很好读 - * 缺乏平台支持使 WebP 的支持成本很高。 +对于那些喜欢数学的人来说，每月 2.7 亿的页面浏览量就是每秒 100 个页面浏览量。 绝对不会出现需要 20 台数据库服务器的情况。 -* 渐进 JPEG 是 Twitter 尝试的另一种选择。 它在连续扫描中呈现。 第一次扫描可能是块状的，但是它将通过连续扫描进行完善。 +请谨慎选择您的建议。 互联网上很少有网站像 Reddit 一样频繁出现故障或性能不佳。 - * 更好的性能。 +我总觉得这些家伙在后台做些聪明的事。 感谢您告诉我更多有关我最喜欢的社交书签网站的信息！ - * 易于在后端支持。 +哦，我只是喜欢这种性能知识。 - * 的编码速度比传统 JPEG 慢 60％。 由于编码只会发生一次，而投放会发生多次，因此这不是一个大问题。 +我们在设计架构以及随后像 Reddit 一样更新它们时也遇到了很多麻烦。 但是我必须同意 Simon 的观点，Reddit 的解决方案在许多其他情况下都行不通。 - * 不支持透明度，因此保留了透明的 PNG，但是其他所有内容都在渐进 JPEG 上收敛。 +我同意 Haugeland 先生的观点，即必须拥有 20 台数据库服务器来处理负载似乎太过分了。 通过阅读评论，我看来原始作者未能认识到真正的教训。 这样的设计通常是开发团队不了解如何为底层数据库进行设计和编码的结果。 也许根据预期的使用情况和负载来选择错误的基础数据库。 - * 在客户端， [Facebook 的 Fresco](https://github.com/facebook/fresco) 库提供了支持。 关于壁画有很多很好的话要说。 2G 连接的结果令人印象深刻。 首次扫描 PJPEG 仅需要大约 10kb，因此加载时间不会很长。 本机管道仍在等待加载，什么也没有显示，而 PJPEG 正在显示可识别的图像。 +这个已经过期了。 reddit 迁移到 Cassandra。 - * 在 tweet 详细信息视图中正在进行的负载实验的结果。 p50 加载时间减少了 9％。 p95 加载时间减少了 27％。 故障率降低了 74％。 连接速度较慢的用户确实会获得巨大的成功。 +http://www.reddit.com/r/programming/comments/bcqhi/reddits_now_running_on_cassandra/ -## 相关文章 +记忆快取不见了 -* [关于 HackerNews](https://news.ycombinator.com/item?id=11535418) +哇！ 这是一项很好的工作！ -* [Twitter 用来处理 1.5 亿活跃用户，300K QPS，22 MB / S Firehose 的架构，并在 5 秒内发送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) +换句话说，运行可伸缩网站不该做什么。 我键入此内容时，Reddit 尚未再次打开。 -* [Twitter 如何使用 Redis 进行扩展-105TB RAM，39MM QPS，10,000 多个实例](http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html) +我是 Reddit 的粉丝，我希望它会改变其基础设施以提供更多可用性。 -* [DataSift 架构：每秒 120,000 条推特的实时数据挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) +MySQL（尤其是 MyISAM）给 RDBMSes 起了一个不好的名字。 -“今天，Twitter 正在每秒创建并保留 3,000（200 GB）图像。” +我有一个以 Poststars 为后盾的应用程序，该应用程序以“星型模式”组织，有一个主事件表，我们平均每秒对其进行 200 次 INSERT 插入，例如高峰时为 400 ish，有 24 列，其中大多数是外键 动态增长的查询表，我们在同一秒内结合在一起执行了十二打 INSERT / SELECT。 这些查询表之一具有超过 2.13 亿行。 向该表中添加另一列是即时的，并为应用程序带来了零延迟。 这是因为 Postgres 将列视为元数据。 -与...不同 +在 MySQL 中尝试这样做确实会“自杀”，而且绝对不是一种选择，因为 MySQL 需要重建整个表。 我不确定你们使用的是哪个版本的 Postgres，但是我发现锁定声明令人惊讶。 -“ Twitter 可以创建大约 3,000 张独特的图像，并每秒传输大约 200 GB 的图像。” +如果您热衷于使用 MySQL，那么请尽一切可能不使用 MyISAM 的方法，尝试将所有基于文本的索引和搜索推迟到 Sphinx 之类。 并尽可能保留尽可能多的表。 -请不要更改其含义。 +实际上，“对所有内容进行预先计算”实际上是扩展应用程序的第一条规则。 他们只是把它带到了大多数人无法接受的地方。 -我并不是要批评/挑剔这是什么引人入胜的文章，但是开头段落中的 200GB 数字不是很清楚–每秒 200GB：“每秒可保留 3,000（200 GB）图像” 。 +很棒的帖子！ 我喜欢这种东西。 -除非我缺少任何东西，否则这似乎是不正确的。 对于 3000 张图像，相当于 200GB，它们将需要很大的文件（每个〜68mb），而且每天 6TB 的存储量（无 TTL）将不可用（在 200GB /秒的情况下，它们需要更多 16PB /天，无 TTL）。 +因此，您基本上将简单的键值存储入侵了 MySQL？ 为什么不使用 Cassandra，couchdb，东京暴君，redis？ -我尝试过数学，最合乎逻辑的是：200GB /分钟，这将使我们平均获得 1.3MB /图像，这看起来更准确，但仍然是 281TB /天。 +我想知道 Reddit 使用什么队列解决方案，以及迁移到 Cassandra 后是否仍在使用它（我认为它仍然有用） -如果有人可以弄清楚我是不是愚蠢还是真正的价值应该是很棒的。 +比较 Digg 和 Reddit 的加载时间，我想说 Digg 做得正确，而 Reddit 做错了。 -我认为 200GB 包含必要的复制。 因此，200GB 可能至少是图像原始大小的 3 倍。 +您是否真的复制了本文的编辑内容？ 它充满了尴尬的写作，就像您在演示过程中起草并发布时一样，没有进行编辑。 第 4 课几乎是难以理解的。 -另外，Twitter 可能需要每个图像有多个版本，例如 缩略图，原始图片等。每个都有不同的分辨率。 这就增加了很多存储空间。 +达克，我同意第 4 课不是很好。 我要做的是总结发言者的发言，使其更简短，更直接地适用。 有时我不知道该怎么做，所以我只保留原理图版本。有几条衬里我认为不值得在一个点上阐述，但我还是留了一点 如果您真的有兴趣，可以决定观看视频。 -不管 Twitter 进行多少复制，仍然很难相信一张图像会占用约 66 MB 的空间。 数字/单位在这里肯定是错误的。 +哦，瞧，又一家没有实际客户的网络创业公司，因此他们不必担心数据完整性，而且显然无力聘请知道数据库工作原理的人来决定适当的 RDBMS 设计是否起作用 首先，他们的问题显然不适合于关系模型。 现在他们有 40 台服务器从事 2 台服务器的工作，应该给我们留下深刻的印象吗？ 伙计们，雇用 DBA 比重塑持久性存储便宜得多。 -哦，这应该是“ Twitter 可以创建约 3,000 个唯一图像，每秒传输约 200 GB 图像。” 正如第一个评论试图指出的那样。 原始来源：https://code.facebook.com/posts/1566627733629653/mobile-scale-london-recap/ +开放模式部分使它看起来像是 NoSql 的理想候选者... -没有狗屎夏洛克，这些都是众所周知的技术，对不起，没什么有趣的。 +chris h：只有确实要添加列时，Postgres 中的 no-locking 选项才可用。 如果要更改列的数据类型，或将列移到其他表，会发生什么？ -你好 +ChronicDB 声称将实时模式更改应用于 Postgres。 -好吧，我不认为客户端改进版在 Android 4.0+上受支持会存在任何问题，因为我记得该版本于 2011 年发布。 因此，可能每个人都拥有较年轻的版本。 +@WayneB-digg 也不正确。 他们有 200 台服务器，现在处理的流量少于 reddit。 -这句话的意思很明确：“ Twitter 可以创建大约 3,000 个唯一的图像，并每秒传输大约 200 GB 的图像。” +@John Haugeland：我完全同意你的看法。 这是一篇有关开发团队如何找到经验不足的解决方法的文章。 -“创建大约 3,000 张独特的图像”：如果以 3 种不同的尺寸保存图像，则用户上传了 1,000 张图像。 -“每秒传输大约 200 GB 的图像”：并不是说它们存储 200 GB 的图像。 但是他们传输 200 GB。 这意味着它们每秒可交付 200 GB 的图像。 +这是一篇很有帮助的文章。 感谢您分享所有这些很棒的技巧。 希望他们能对您有所帮助！ -他们是否将图像存储两次？ -图片服务将图片上传到 Blob 存储并返回 mediaId。 -mageBird 将生成变体； VideoBird 将进行一些转码； 生成的任何媒体都将放入 BlobStore。 \ No newline at end of file +Reddit 太慢了……我想他们有一些新的挑战和教训要学习，因为在大多数情况下它似乎无法使用。 \ No newline at end of file diff --git a/docs/51.md b/docs/51.md index 82ab136..f80705e 100644 --- a/docs/51.md +++ b/docs/51.md @@ -1,129 +1,254 @@ -# 我们如何在 Mail.Ru Cloud 中实现视频播放器 +# Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长 + +> 原文： [http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) + +![](img/570f0d0ed652d765e32b52d6ed05e6cd.png)每天有 1000 万玩家，每月超过 5000 万玩家使用 Facebook，MySpace 和 iPhone 等社交平台上的 [Playfish](http://playfish.com) 游戏与朋友进行社交互动。 Playfish 是游戏行业发展最快的细分市场中的早期创新者：[社交游戏](http://radoff.com/blog/2010/05/24/history-social-games/)，这是休闲游戏和社交网络之间的挚爱。 Playfish 还是 Amazon 云的早期采用者，其系统完全在 100 台云服务器上运行。 Playfish 发现自己处于某些热门趋势（可能是 EA 为什么以 [3 亿美元](http://mashable.com/2009/11/09/ea-acquires-playfish-2/)买下它们，并认为 [10 亿美元游戏](http://venturebeat.com/2010/04/20/ea-playfish-president-the-billion-dollar-social-game-is-achievable/)成为可能）的趋势：在社交网络上构建游戏， 在云中构建应用程序，移动游戏，利用数据驱动的设计来不断发展和改进系统，敏捷开发和部署，以及将[出售为商业模型。](http://blogs.forbes.com/velocity/2010/02/23/eas-playfish-big-real-world-sales-in-virtual-goods-game/) + +一家小公司如何实现所有这些目标？ 为了解释这种魔术，我采访了 Playfish 的工程高级总监 Jodi Moran 和 Playfish 的首席建筑师，第一任工程师兼运营总监 Martin Frost。 很多好东西，让我们继续讲究细节。 + +![](img/c91d3416e25166647ae96320f6156952.png) + +网站： [playfish.com](http://playfish.com/) + +## 统计资料 + +1. 每月 5000 万活跃用户 +2. 每天有 1000 万活跃用户 +3. 100 台服务器计算机 +4. 10 款游戏，一直在发布 +5. 已下载，安装和播放了 2 亿个游戏 +6. 服务器与操作人员的比例为 100：1 +7. 4 间工作室中的约 200 名员工和 250 名承包商 + +![](img/1e65da2353b0c34d18ec301ed65e89be.png) + +## 平台 + +1. 客户端上的 Flash +2. 服务器端的 Java +3. 一些 PHP 工具 +4. 亚马逊：EC2，CloudFront，S3，Hadoop /弹性地图简化，Hive，一些 SQS，一些 SimpleDB +5. HAProxy 用于负载平衡 +6. MySQL 用于分片，blob 存储 +7. 码头应用服务器 +8. [YAMI4](http://www.inspirel.com/yami4/) 用于服务传输。 提供点对点连接，低延迟。 + +## 关键力量 + +塑造 Playfish 体系结构的主要力量是什么？ + +1. **游戏是免费（F2P）**。 Playfish 游戏是免费的：它们不需要花钱就可以玩，但仍然需要花钱来运行。 这种模型的结果是不可能简单地将硬件扔到问题上。 成本必须得到控制，因此它们试图精益高效地运行。 与其他游戏机型一起，每月订阅可补贴硬件和产品投资。 [MMO](http://en.wikipedia.org/wiki/Massively_multiplayer_online_game) （大型多人在线游戏），例如，每台服务器可运行数百或数千个用户。 Playfish 的目标是在此数量级以上。 MMO 可提供服务器密集型游戏体验，但它们唯一的方法是每月收取 10 至 50 美元的订阅费，这是一个完全不同的空间。 +2. **游戏是社交游戏**。 Playfish 专注于社交游戏，这意味着您与朋友互动和互动。 实际上，您只能和真正的朋友一起玩，也可以和您的社交游戏一起玩。 游戏并不是真正赢球。 结果是按分数和水平排序的，但是人们会发挥更多的作用来表达自己并炫耀其设计技巧。 这是另一种游戏类型。 例如，在[餐厅城市](http://www.youtube.com/watch?v=a8AyQ7xBAZ0)中，目标不是成为最富有或最好的餐厅，而是拥有最具创意和表现力的餐厅。 较新的游戏甚至不再使用全球排行榜。 较早的游戏使用全球排行榜，每个人都与其他人竞争。 游戏的结构传统上更具挑战性，并且“看我的得分比你的得分还要大”。 现在他们有了一个排行榜，但它只是在您和您的朋友之间。 现在更亲密了。 人们不在乎是否比其他国家的人更好，而在乎是否比朋友的人更好。 +3. **游戏是异步**。 异步游戏是玩家可以在不同时间玩的游戏。 由于您的朋友很少同时在线，因此社交游戏是异步进行的。 你们不必都同时玩。 例如，在类似 MMO 的《魔兽世界》中，玩家同时存在于同一空间中并且可以同时行动，这使得他们对延迟非常敏感并且难以扩展。 Playfish 的游戏有所不同，它们是异步播放的单人或多人游戏。 玩家不会同时出现在同一个游戏空间中，而是在其本地客户端中玩。 与朋友一起玩耍时，您不会受到朋友的阻拦，可以自己进步。 该模型导致各种专业设计的可能性。 异步游戏的例子是熟悉的游戏，如 Scrabble 或 Texas Hold'em，玩家轮流玩。 更具创新性的游戏是 Playfish 的“最大大脑”游戏，该游戏中的朋友不断尝试证明谁更聪明，它使用排行榜显示您的朋友及其分数的图片，因此您始终可以看到谁在领先。 这是异步的，因为每个玩家都独立游戏，但排行榜允许所有玩家检查彼此的进度。 +4. **游戏是休闲游戏**。 异步游戏可以是硬核策略游戏，例如 1950 年代的[外交棋盘游戏](http://en.wikipedia.org/wiki/Diplomacy_(game))。 [社交游戏](http://radoff.com/blog/2010/05/24/history-social-games/)往往是[休闲游戏](http://en.wikipedia.org/wiki/Casual_game)，它们确实很容易玩，只要在短时间内从任何位置单击几下鼠标，就可以玩。 Playfish 通过高产值 3D 图形，易于控制，自定义角色和多人游戏挑战扩展了该模型，从而带来了很高的[用户参与度](http://www.workatplay.com/think/what-user-engagement-anyway-part-1)。 +5. **规模受限于各个社交网络**的规模。 与社交意味着[难以扩展](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html)的其他应用领域相反，对于 Playfish 社交来说，这不仅是一个扩展问题，还是一个扩展解决方案。 Playfish 游戏并不具有全球意义，因为有一百万人不会尝试同时玩同一游戏。 Playfish 游戏是社交性的。 他们与您的朋友一起玩的乐趣更多，而不是艰难和肮脏的比赛。 这样的结果是，个别游戏固有地可扩展，因为它们只涉及很少的玩家。 以一个拥有 5000 万用户的全球排行榜为例。 在单个数据结构上需要大量写入，并且可能需要分片以使其扩展。 由几个参与者组成的社交网络的排行榜更容易实现。 +6. **大量用户**。 积极玩游戏的用户数量众多，这给他们的体系结构带来了压力，要求它们扩展为整个系统。 每个单独的游戏可能都相对容易扩展，但是对于这么多的活动游戏来说，完整的系统并不是那么容易扩展。 +7. **快速增长**。 通过设计，这些游戏具有病毒性，因为它们利用了社交图谱。 它们也很有趣，易于玩耍并有助于维持朋友之间的关系。 所有这些因素都促进了社交游戏的快速发展，这意味着 Playfish 不仅需要应对大量用户，还必须应对持续不断的新用户。 +8. **快速更改**。 游戏市场发展迅速，竞争激烈。 这也是一个非常新的领域，每个人仍在学习什么有效，哪些无效，流失很多。 Playfish 不能等待漫长的采购流程，漫长的设计周期或漫长的发布周期。 他们必须保持敏捷。 +9. **游戏的热门驱动性质**。 很难预测哪些游戏会成功，因此当一款游戏成功起飞时，它必须能够立即扩展。 游戏盛行时，没有时间利用新资源。 为每个游戏的最大预期增长分配资源根本行不通。 他们的游戏太多了，这将需要大量的服务器，而这些服务器很可能将不使用。 +10. **实验性游戏发布**。 游戏可以看作是针对利基市场的实验。 有些实验会比其他实验更成功。 这回到了社交游戏行业非常敏捷的本质。 +11. **多个游戏**。 Playfish 不是一家单一产品公司。 其他公司仅支持一个游戏。 Playfish 必须同时支持和开发多个游戏，并且新游戏总是按计划进行。 这给开发和运营带来很大压力。 +12. **智能客户端**。 Playfish 游戏是用 Flash 编写的，这是一个非常强大的富客户端。 它可以智能地缓存数据，支持本地操作并消除大量服务器负载。 +13. **游戏是应用程序，而不是网站**。 由于智能客户端会删除许多读取，因此大多数数据库活动都是**大量写入**。 典型数据库主机上 60％的负载是写操作，而大多数网站往往读起来很繁琐。 由于游戏是通过网络进行的，因此很容易将它们视为网站，但实际上它们是通过网络交付的应用程序。 +14. **重负载时间延迟**。 Playfish 游戏具有全球用户的意义，因此具有全球性。 由于游戏是在智能客户端中异步进行的，因此游戏等待时间并不重要，这意味着在加载游戏（即 Flash 游戏+资产）时，用户会遇到最明显的等待时间，因此，他们必须尽可能减少这种情况。 +15. **来自用户**的实时反馈。 社交游戏通过网络以数字方式在社交网络上分发，从而完全绕开了通过商店或电信公司的传统分发渠道。 第一次没有中间人控制游戏发行。 任何用户都可以坐在家里，随时随地与他们一起玩。 游戏制作者现在可以以前所未有的方式与观众建立联系。 可以直接与用户群联系，以帮助发展和改进游戏。 用户可以向游戏设计师提供实时反馈，并影响他们玩的游戏的设计。 +16. **社交游戏是服务，而不是盒子**。 传统游戏是在盒子中的架子上购买的，而发行商则控制频道。 他们向同一位 25 岁的硬核游戏玩家销售产品。 社交游戏正在扩展到[新市场](http://venturebeat.com/2010/08/23/one-in-five-americans-plays-games-on-social-networks/)，吸引了从未玩过游戏的人。 作为一项服务的游戏在玩家和游戏背后的创意团队之间建立了非常长的关系。 可以每周发布一次，一起培养游戏，并不断学习玩家的需求。 在拥有多年的开发周期之前，这是不可能的。 +17. **人们已断开连接，正在寻找连接**的方法。 宠物协会是一个虚拟的世界，玩家在这里装饰自己的房屋和朋友的房屋。 在圣诞节前后，他们开始以每个 2 美元的价格出售虚拟圣诞节和装饰品。 他们出售了价值 4000 万美元的虚拟货币。 行为分析的忠实拥护者，他们问用户为什么要这么做？ 归结为与断开联系的人们建立联系。 以前，他们家里会有一棵树，人们会看到树和他们的创造力。 现在人们都断开了连接，因此 3-4 个朋友可以看到真实的圣诞树，而他们所有的朋友都可以看到 Facebook 上的虚拟圣诞树。 在吸引人方面，您的虚拟货币有更大的优势。 推动购买的是对社交表达自我的渴望，虚拟商品是手段，社交网络是新领域。 就像在现实世界中一样，购买虚拟礼物是为了在与朋友互动中获得感知的价值。 +18. **背景模拟**。 像 Restaurant City 这样的游戏开始具有后台模拟组件，即使用户不在网上也可以运行。 这导致游戏以鼓励玩家定期回头的方式发展。 例如，在《餐厅城》中，玩家需要确保为餐厅员工提供食物。 此模拟组件是一个有趣的新负载，必须将其集成到游戏基础结构中。 +19. **需要一次缩放几个不同的维度**。 Playfish 需要扩展以支持更多的用户，更多的游戏，每位用户更多的数据，每位用户更多的访问权限，更多的开发人员和更多的运营人员。 扩展最困难的事情是扩展支持一切的人员。 + +## 关键扩展策略 + +为了应对这些力量，Playfish 遵循了一些关键的扩展策略： + +1. **乐趣**。 为了推动增长，关键的设计指标是创造一款如此有趣的游戏，以至于它会产生强烈的情感，使人们感到他们只需要玩游戏，就必须邀请他们的朋友加入游戏，以获得更多的乐趣。 在朋友的社交网络中分享情感时，情感会最大化。 传统游戏是具有出色声音和图形的沉浸式体验。 Playfish 尝试设计用于社交互动的游戏，通过邀请朋友让您从游戏中受益。 您可以自己玩 Restaurant City，但邀请您的朋友在您的餐厅做饭会更有趣。 通过在游戏中添加朋友，您会逐渐获得更多乐趣。 用户希望与朋友互动以获得更多乐趣的愿望推动了更大的发行量和增长。 +2. **基于微交易的收入模型**。 [微型交易](http://blogcritics.org/gaming/article/microtransactions-in-games/)通常是高交易量，低价值的交易。 为了支付服务费用，Playfish 通过玩家购买游戏内虚拟物品和服务来赚钱。 Playfish 还从广告和[产品展示位置](http://venturebeat.com/2010/04/20/ea-playfish-president-the-billion-dollar-social-game-is-achievable/)中获利。 该策略支持免费游戏模式，同时基于自然游戏收入提供收入。 +3. **云**。 Playfish 从一开始就一直是 100％基于云的，并于 2007 年在 EC2 上发布了他们的第一款测试版游戏。云几乎是我们上一节所介绍的众多力量的完美答案。 我不会谈论云的所有[奇观，但您很容易看到弹性如何帮助解决他们的许多可变需求问题。 如果游戏变得流行，它们可以增加更多资源来处理负载。 无需采购流程。 如果需求下降，他们可以简单地将实例退还给您。 云的 API / IaaS（基础设施即服务）性质可以轻松满足其对敏捷性的需求，保持团队规模的需求以及早期及经常发布的要求。 您可能会认为按使用付费模式的云太昂贵了，我们将在云部分中对此进行更多讨论，但是他们并不这么认为。 他们更加担心无法在快速发展的市场中开发新游戏和改进现有游戏的机会成本。](http://highscalability.com/how-do-you-explain-cloud-computing-your-grandma) +4. **SOA（面向服务的体系结构）**。 他们在 SOA 方面非常重要。 这是他们架构的组织原则以及他们如何构造团队。 每个游戏都被视为单独的服务，并且彼此独立发行。 内部组织成提供 API 的组件的软件，并且这些组件分别进行管理和可伸缩。 +5. **分片**。 Playfish 是一项写重服务。 为了处理写入，Playfish 采用了[分片架构](http://highscalability.com/blog/category/shard)，因为这是扩展写入的唯一真正方法。 +6. **BLOB** 。 没有为用户存储多个记录。 相反，用户数据存储在 MySQL 中的 [BLOB](http://en.wikipedia.org/wiki/Blob_(computing)) （二进制大对象）中，因此可以通过键值方法快速访问它。 +7. **异步**。 在服务器上进行写操作与游戏是异步的。 用户不必等待服务器上的写入完成就可以继续玩游戏。 他们试图尽可能向用户隐藏延迟。 在 MMO 中​​，每一步都必须传达给所有用户，而延迟是关键。 Playfish 游戏并非如此。 +8. **智能客户端**。 通过使用智能 Flash 客户端，Playfish 能够利用客户端计算机上更高的处理能力。 随着他们添加更多用户，他们还增加了更多的计算能力。 他们必须正确平衡服务器端和客户端端的内容。 适当的组合因游戏而异。 智能客户端缓存读取内容，但它也允许游戏在客户端上独立进行，而无需与服务器对话。 +9. **数据驱动的游戏改进**。 Playfish 收集了大量的游戏数据，用于持续改进现有游戏并帮助确定接下来要发明的游戏。 他们正在使用 Amazon 的 Elastic Map Reduce 作为其分析平台。 +10. **敏捷**。 Playfish 的所有思想中的一个共同点是对灵活性的不懈需求，以便能够快速，轻松，高效地应对各种情况。 敏捷性体现在他们对云的选择上，围绕服务进行组织，快速发布周期，保持团队规模小和有能力，并通过数据挖掘和客户反馈不断改进游戏设计。 + +## 基本游戏架构 + +1. 游戏在 Flash 客户端中运行。 +2. 客户端以服务级别 API 的形式将请求发送到 HAProxy 服务器，该服务器在 Amazon 云中运行的 Jetty 应用程序服务器之间负载均衡请求。 +3. 所有后端应用程序均使用 Java 编写，并使用面向服务的体系结构进行组织。 +4. Jetty 服务器都是无状态的，从而简化了部署，升级并提高了可用性。 +5. MySQL 被用作数据层。 数据在 MySQL 服务器之间进行分片，并以 BLOB 格式存储。 +6. Playfish 是 Amazon 云的早期采用者，因此他们无法利用诸如负载平衡之类的 Amazon 后来的开发。 如果他们必须从头开始，他们可能会朝这个方向发展。 +7. 更改被异步推送到服务器。 该系统的设计不是让用户单击按钮，而是将操作发送到服务器以查看发生了什么，而是使系统有权让客户端决定操作是什么，然后由服务器检查该操作是否有效。 处理在客户端。 如果用户和服务之间存在高延迟，则由于异步保存和智能客户端，用户将看不到它。 在一天结束时，用户看到的才是最重要的。 重要的是，当网络中出现故障或等待时间较长时，用户将获得有趣的游戏体验。 +8. Playfish 的前几款游戏是简单的单人游戏，例如《谁拥有最大的大脑》，并具有高分和挑战等功能。 在服务器端不是很复杂，也不是很沉重。 从项目开始到结束，他们只有 5 周的时间。 其中包括对 Facebook API 的学习和编码，对 AWS 的学习和编码，对游戏服务器的编码以及建立生产基础架构。 前三场比赛延续了这种模式：高分和挑战。 这给了他们一些喘息的空间，可以开始建立自己的基础架构。 改变事物的第一款游戏是 2008 年的宠物协会。这是第一款大量使用虚拟物品的游戏。 数据存储从为每个用户存储一些属性（如化身定制和高分）到为每个虚拟项目存储每个用户潜在的数千个项目。 这给系统带来很大压力。 早期，随着服务增长非常迅速，出现了一些大服务问题。 然后他们进行分片，系统变得更加稳定。 但是首先，他们尝试了其他各种技术。 他们尝试一次添加更多的只读副本，例如一次添加 12 个，但这并没有真正起作用。 他们尝试尽最大可能修补系统。 然后他们咬住子弹并放入分片中。 从开始到推出共花了 2 周的时间。 在该游戏中，所有性能问题都消失了。 随着时间的流逝，用户获得了很多虚拟物品，因此行的数量爆炸了。 每个项目都存储在其自己的行中。 即使您将用户划分为旧用户的碎片，即使用户数量保持不变，碎片也会不断增长。 这是转到 BLOB 的原始驱动程序之一。 BLOB 摆脱了导致此类性能问题的多个行。 随着时间的流逝，游戏开始变得越来越复杂。 宠物协会没有任何模拟元素。 然后，他们在 2008 年底推出了“餐厅城市”，该餐厅具有第一个离线模拟元素。 当玩家不在时，您的餐厅继续营业并赚钱。 这带来了挑战，但是在云中添加额外的处理相对简单。 模拟逻辑是在客户端中实现的，服务器将执行诸如检查欺诈的操作。 + +## 面向服务的架构 + +1. Playfish 确实是 SOA 的主要倡导者。 SOA 将数据和功能封装在一起，可以通过分布式系统独立部署。 分布式组件通过称为*服务合同*的 API 进行通信。 +2. 服务确保系统所有部分之间的依赖性是众所周知的，并且尽可能松散耦合。 +3. 支持复杂性管理。 该系统可以组成单独的易于理解的组件。 +4. 组件是独立部署和升级的，这提供了灵活性和敏捷性，并使得扩展开发和运营团队变得更加容易。 +5. 可以独立于其他服务来优化独立服务。 +6. 服务失败时，更容易正常降级。 +7. 每个游戏都被视为一项服务。 UI 和后端是一个包。 他们没有分别发布 UI 和后端。 + +## 云端 + +1. Playfish 从一开始就是 100％基于云的，于 2007 年在 Beta 版 EC2 上发布了他们的第一款游戏。 +2. Cloud 使 Playfish 能够以极低的摩擦力进行创新并尝试新功能和新游戏，这是快速发展的市场的关键。 从他们的多个只读副本系统迁移到分片系统需要 2 个星期，如果没有云的灵活性，这是不可能完成的。 +3. 云使他们能够专注于使他们与众不同的地方，而不是构建和管理服务器。 由于云运营无需专注于机器维护，因此他们可以专注于更高价值的服务，例如跨所有不同服务器和游戏开发自动化。 +4. 现在，在设计应用程序时将容量视为一种商品。 +5. 服务器与操作人员的比例为 100：1。 由于云基础架构，如此高的比率是可能的。 +6. 服务器发生故障，因此必须从头开始计划。 +7. 不可能继续向服务器添加内存，因此您可能必须提前扩展。 +8. 云的关键特征是*灵活性*。 您可以根据需要灵活地进行操作。 当您突然得到大量流量时，您无需感到惊讶。 您不必等待服务器的采购。 +9. 您永远都不知道游戏将以多快的速度起飞。 有时您确实知道，体育游戏发展很快，但其他游戏可能会突然爆炸。 在云中，这不一定是问题。 +10. 从一开始，就从来没有想到它们可以在云中进行扩展。 一切都旨在通过添加更多计算机来扩展。 +11. 他们不能使用所有的 Amazon 服务，因为必须自己滚动。 离开他们所了解的自己的系统会带来不必要的风险。 例如，没有 ELB 和 RDS，因此必须自己构建。 现在切换到那些服务没有任何意义。 +12. Playfish 是云的核心。 他们充分利用了云中的一切。 轻松获取更多容量。 他们根本没有内部服务器。 所有开发机器都在云中。 云使启动新环境变得轻而易举。 例如，要测试分片很容易，只需使用新配置复制所有内容即可。 在数据中心中运行时，这要困难得多。 +13. 考虑到所有因素，**云比裸机更昂贵**。 + 1. 基于带宽和机架空间的单位，裸机可能看起来更便宜，但是如果您查看所获得的所有东西，那将是很多工作。 以高级可用性功能为例。 更改 API 调用，您将获得双数据中心。 在裸机情况下，您无法做到这一点。 仅考虑设置和维护的人员成本。 云看起来确实很昂贵，但是当您获得真正大容量时，中断就开始了。 + 2. 要考虑的主要成本是**机会成本**。 这是最大的优势。 例如，当他们第一次在 Pet Society 中实施分片时，从开始到部署需要 2 周。 用户立即感到高兴。 它们的实现速度取决于能够在生产中激发整个服务器负载以及测试和迁移数据。 如果您有两个月的交货时间，那么您将有两个月不满意的用户。 +14. Playfish 在同一区域内的多个可用区中运行。 服务器相对靠近，这减少了延迟。 它们不会像 MMO 系统那样散布开来。 使用异步写入，客户端中的缓存和 CDN 中的缓存在更高级别上处理延迟。 在服务器上执行游戏操作可能需要 3 秒钟，但是由于它是异步的，因此用户不会注意到。 CDN 有助于减少他们注意到的内容，即资产和游戏的负载。 +15. CloudFront 用于减少负载延迟。 从某种意义上说，Playfish 是全球性的，拥有世界各地的用户。 游戏的加载时间（包括 Flash 代码和游戏资产）是它们最明显的延迟。 CloudFront 可以在分发内容时减少这种延迟。 + +## 数据库系统 + +1. MySQL 被用作存储 BLOB 的分片键值数据库。 +2. 用户跨多个数据库集群进行分片，每个集群都有自己的主副本和只读副本。 + 1. 他们拥有更多副本的好处不多，因为它们写得很重。 几乎所有流量都是写操作。 写入很难缩放。 无法缓存，更多的只读副本无济于事。 + 2. 在较早的体系结构中，他们有一个具有 12 个读取从属设备的主设备，表现不佳。 + 3. 通过分片，他们从一个母版和 12 个只读副本变成了两个母版和两个只读副本，这对读写都有帮助。 +3. 分片意味着索引变小，这意味着它们可以容纳在内存中。 将索引保留在缓存中可确保用户查找不必打到磁盘，可以从 RAM 提供查找。 +4. 通过分片，他们可以控制每个分片中有多少用户，因此，他们可以确保自己不会破坏内存索引缓存并开始访问磁盘。 +5. 他们试图优化用户记录的大小，以便更多用户可以容纳在内存中。 这就是为什么他们去存储 BLOB 而不是使用标准化为行的数据的原因。 现在，每个用户只有一个数据库记录。 +6. 工作从数据库服务器中取出并移到应用程序服务器，这些服务器很容易在云中水平扩展。 +7. 大多数网站都使用诸如内存缓存之类的扩展技术来进行读取缓存，而这些技术对 Playfish 并不那么有用。 使用 Flash 客户端时，将在 memcache 中缓存的大部分内容都将缓存在客户端中。 将其发送到服务器一次并存储。 +8. 分片用于获得更高的写入性能。 + 1. 写操作占 60％的工作量。 通常情况下是 10：1。 他们仍然使用 MySQL 进行数据存储，因为他们对负载等情况下的性能统计非常满意。 + 2. 每个分片都有一个母版，至少在只读副本上。 大多数情况下，只有一个只读副本，但这取决于服务的访问模式。 读取将拆分为读取副本。 对于确实具有更多读取的一些地方，它们具有更多的读取副本。 只读副本还用于远程保留数据作为备份。 +9. Playfish 是由纯粹的必需品驱动的。 他们建立了自己的键值存储，因为必须这样做。 为什么不使用 NoSQL？ 他们正在研究选项，但同时他们有一个可行的解决方案，他们知道它将如何工作。 对 NoSQL 解决方案感兴趣，用于操作端，用于管理多个数据库。 进入运行 NoSQL 的模式并不容易，但这是由其需求驱动的。 +10. 在横向扩展情况下，您必须进行分片之类的操作，此时许多 SQL 功能都将消失。 您必须自己做很多工作。 现在，当您进行大批拆分时，您将无法添加索引。 +11. 使用 NoSQL 时，您将放弃访问模式的灵活性。 关系数据库非常好，因为您可以随时以所需的方式访问数据。 例如，由于他们不能再使用 SQL 来汇总字段，因此它们都可以即时聚合或使用批处理过程进行聚合。 +12. 备份到 S3。 + +## Flash-客户端 + +1. 客户端的 CPU 和资源随用户数量的增加而扩展，因此明智地利用客户端。 将尽可能多的处理推送给客户端。 +2. 更改被异步写回到服务器，这有助于向用户隐藏网络延迟。 +3. 在服务器端检查更改以检测作弊。 +4. Flash 使用服务级别 API 与 Jav​​a 应用程序服务器对话。 +5. 使处理过程更接近客户端可为用户带来更好的体验。 网站使服务器更靠近用户。 Playfish 在客户端上使处理过程更加紧密。 + +## YAMI4-讯息 + +1. 经过长时间的评估，YAMI4 是 Playfish 决定使用的消息传递系统。 它提供点对点连接，低延迟，无单点故障以及异步消息传递，以在多个后端服务中进行事件驱动的处理和并行处理。 +2. 服务经过发现阶段以了解每个端点的位置后，消息将直接在服务之间传输。 这是一种无经纪人的模式。 消息不会集中到集中式服务中，然后再重新分发。 使用此模型，消息传递非常有效，因为没有中间跃点，因此减少了延迟。 他们特别不想让一个单独的组件来处理流量，然后传递消息。 这种方法减少了故障点和延迟。 +3. 被认为是节俭的，但是 YAMI4 因其异步操作而获胜。 Thrift 使用看起来像本地函数调用的 RPC 模型，这使得处理错误，超时等更加困难。YAMI4 是消息传递模型，而不是 RPC 模型。 +4. YAMI4 不处理服务发现方面，而是在发现阶段然后直接与其他服务对话的基础上构建自己的服务。 互联网的运作方式更多。 +5. 作为消息传递系统，消息不会调用对象上的方法。 也没有对象在网络上流动。 对象存在于服务中。 每个服务负责激活，钝化和调度操作。 + +## 处理多个社交网络 + +1. 他们的主要挑战之一是能够支持这么多不同且越来越不同类型的游戏。 +2. 尽可能使用*松耦合*的原理： + 1. 团队拥有的服务使团队结构与体系结构相匹配。 + 2. 服务保持良好定义的接口，以便每个团队可以迭代并部署自己的服务，而不会影响其他团队。 + 3. 当需要更改接口时，将对接口进行版本控制。 他们试图保持向后兼容性，以便其他团队不必推出更改。 +3. 为了促进所有这些，将一套通用的标准应用于所有服务： + 1. 公共服务运输（YAMI4） + 2. 通用操作标准，例如如何配置服务以及它们如何提供监视信息。 +4. 通用标准和松散耦合的结合使开发和运营团队既灵活又高效。 + +## 开发与运营 + +1. 服务彼此独立发布。 +2. 资源按服务分开。 一项服务出现问题不会影响不相关的服务。 +3. 团队是按服务组织的，尽管有一些重叠。 +4. 尽管存在密切的关系，但运营团队与开发团队是分开的。 没有大的交接阶段。 他们不只是在墙上扔一个释放。 操作包括在设计中。 +5. 开发人员不发布代码。 他们将其检入并由操作人员将其捡起。 +6. 团队在部署方面具有很大的灵活性。 大多数游戏每周发布一次。 一切都是迭代的，这意味着代码足以投入使用，但功能不一定完全完成。 每周发布周期对于带有虚拟物品的游戏特别有价值，因为用户喜欢每周都知道有新的令人兴奋的东西。 其他团队可以使用更长的功能块。 这取决于。 这是从事 SOA 的优势之一。 团队可以独立工作。 不需要一个发布周期。 + +## Java-服务器 + +1. Java 支持创建干净的可重用组件。 +2. 有大量的开源库。 +3. Java 是灵活的：它可用于实现 Web 应用程序，流程请求，批处理和事件驱动的系统。 +4. Java 有许多调优选项。 他们做了很多工作来调整垃圾回收以提高性能。 + +## 游戏设计 + +1. 为了使游戏用户享受 Playfish 的乐趣，它将数据驱动的设计与良好的，受人启发的古老游戏设计结合在一起。 数据可用于指导用户制作游戏的许多决策。 他们可以从数据中看到用户最擅长的事情。 这告诉了他们如何使游戏和个人游戏变得更好，以及在设计新游戏时该怎么做。 +2. Playfish 喜欢行为分析。 他们查看人们在游戏中正在做什么，然后问他们为什么。 在支持方面，客户端和服务器具有很大的能力来生成有关用户操作的事件。 然后处理这些事件，以创建有关用户在游戏中所做操作的汇总信息。 他们现在正在使用 EMR / Hadoop / Hive 来通过类似 SQL 的界面访问大量的数据。 在云中使用 EMR 的效果非常好，他们对此非常满意。 大量数据可以粒度形式存储，并且由于所有内容都可以并行工作，因此仍然可以快速找出所需内容，非常适合游戏产生的事件类型数据。 +3. 用户想要什么真是令人惊讶。 他们甚至可能自己都不知道。 人们认为他们想要的与人们实际使用的有所不同。 有时，用户会说他们确实想要一些昂贵的功能，但最终却没有使用它们。 然后是没有人提及但人们一直在使用的功能。 在论坛上发帖的人通常是不喜欢事物的人，因此很容易获得一种非常不平衡的观点，因为他们对游戏充满热情，讨厌任何变化。 数据有助于找出人们真正喜欢的东西。 +4. 游戏设计不能只是数据驱动的，否则游戏将毫无生气。 您必须正确获得数据驱动的平衡。 您不能仅仅按照数据说明的去做。 随您的灵感去增加或增加游戏中的内容，然后使用数据来完善游戏。 +5. 某些功能需要大量的工作来创建，但由于功能太复杂，用户并没有最终完成。 他们设置了渠道，以了解人们是否在完成功能之前就放弃了功能，然后他们就能找出原因。 也许某个功能需要调整或放弃。 参与度是用户对游戏的热爱程度的衡量标准。 然后，他们投资使人们回头的内容，以便生态系统得以发展。 +6. 敏捷+数据+设计=允许快速试用新启发的功能，以查看它们是否有效。 结果是一个有趣的游戏。 +7. 团队分为紧密的小组，这些小组具有完全的创作自由。 所有团队成员都对什么使游戏更有趣发表了意见。 +8. 运行游戏实验是为了寻找合适的位置，以查看合适的位置。 有些会成功，有些会失败。 + +## 得到教训 + +1. **建立一个利用应用程序特殊性质的体系结构。** Playfish 已针对其特定需求量身定制了一种体系结构。 不要尝试构建可以扩展所有内容的通用体系结构。 利用空间的本质，使生活尽可能轻松。 +2. **不用担心第一次正确**。 把东西拿出来，开始学习。 如果他们试图达到 3 年前的现状，那么他们仍然会构建系统。 他们提出了一些根本无法扩展的东西，但他们在 5 周内就解决了。 这是关键。 +3. **不要害怕坚持知道和了解的东西**。 选择您熟悉的东西。 您不需要选择最新和最酷的产品。 充分了解产品并能够预测产品在您的用例中的运作方式具有很多价值。 这样，您将减少很多麻烦。 +4. **首先保持简单，然后在需要时进行扩展**。 利用该提前期来构建您所需的内容。 +5. **碎片和 BLOB** 。 使用分片扩展写操作。 使用 BLOB 将每个用户的记录数减少到一。 这样可以加快对象访问速度，并允许在 RAM 中添加更多对象。 +6. **总是有一个粗略的想法，你将如何扩展**。 不要过早设计功能，但不要创建破坏性的依赖关系。 例如，可以在不进行适当缩放的情况下启动就可以了，拥有在分片后无法使用的功能也不是一件很酷的事情。 +7. **缩放数据比缩放处理**困难。 您在哪里存储数据？ 有多少人需要读写？ 无状态应用程序服务器使添加更多处理变得容易，而数据扩展则困难得多。 +8. **不要过度复杂**。 扩展简单系统更容易。 保持尽可能长的简单性。 这使您可以了解痛点所在，然后可以专门解决这些痛点。 许多人认为他们必须从第一天开始就建造巨大的东西。 例如，如果您不需要多级缓存，则不要放入它，因为您必须支持它。 +9. **使用 SOA 管理复杂性**。 随着新游戏的添加，将代码分成由不同团队管理的不同组件有助于降低系统的整体复杂性，从而使一切易于扩展。 +10. **承担计算的风险**。 Playfish 进入了云环境，但是有一个备份计划，以防万一失败。 这是一种风险，但也有很多好处。 如果亚马逊取消了他们的服务，那么如果他们真的需要，他们可以搬家。 这就是使用“基础架构即服务”的好处。 使用“平台即服务”存在更大的风险，因为您建立了更深的依赖关系。 例如，当 fPlayfish 拥有自己的有效键值数据库时，转移到 NoSQL 产品的风险也太大。 +11. **运营和开发应了解系统如何在生产中工作**。 容易管理吗？ 支持客户容易吗？ 如何配置和监视它？ 开发您需要实现所有这些的东西。 开发人员不能只是在墙上扔代码。 应该没有墙。 +12. **使用数据可以帮助您找到人们真正喜欢的东西。** 用户并不总是知道自己最喜欢什么。 检测您的代码并分析数据以找到有意义的模式，并使用该信息来不断改进系统。 +13. **最难扩展的是人**。 必须使人们的工作变得非常容易。 获得更多的服务器要比获得更多的人容易得多。 + +我要感谢 Playfish 抽出宝贵时间进行了这次翔实而有见地的采访。 如果您希望 HighScalability.com 上具有您的体系结构，请[与我](http://highscalability.com/contact/)联系以开始使用。 + +Playfish 正在寻找人。 有关职业机会，请参见其[职位页面](http://www.playfish.com/?page=jobs)。 从我与几个人的交往中，一个 Playfish，他们似乎把他们的东西放在一起。 值得一看的是，他们有很多空缺职位，他们正在寻找服务器端工程师。 他们希望构建新系统，以使用 EMR / Haddop / Hive 更好地了解用户，并扩展整个系统以添加更多用户和游戏。 + +## 相关文章 -> 原文： [http://highscalability.com/blog/2016/3/28/how-we-implemented-the-video-player-in-mailru-cloud.html](http://highscalability.com/blog/2016/3/28/how-we-implemented-the-video-player-in-mailru-cloud.html) +1. [Playfish 展示了“游戏即服务”如何在云中扩展](http://www.readwriteweb.com/cloud/2010/08/playfish-shows-how-games-as-a-.php) +2. [访谈：Playfish 通过我的帝国在简单的动作中寻找意义](http://www.gamesetwatch.com/2010/08/interview_playfish_on_finding.php) +3. [AWS 案例研究：Playfish](http://aws.amazon.com/solutions/case-studies/playfish/) +4. [EA Playfish 高管吹捧下一代 Facebook 游戏](http://venturebeat.com/2010/05/14/ea-playfish-exec-sebastien-dehalleux-touts-next-generation-facebook-games/) +5. [深入了解：Playfish](http://blog.kissmetrics.com/an-in-depth-look-playfish/) +6. [介绍 Playfish](http://www.slideshare.net/sdehalleux/introducing-playfish) +7. [在社交游戏峰会](http://www.insidesocialgames.com/2008/06/13/lives-notes-from-asynchronous-games-on-social-networks-at-social-gaming-summit/)上直播“社交网络异步游戏”的笔记 +8. 视频： [SGS09：大规模构建社交游戏](http://www.youtube.com/watch?v=dLCSGm_tkfM)。 +9. 视频： [SGS2008：社交网络上的异步游戏](http://www.youtube.com/watch?v=3zIXY1upwTI)。 +10. [异步游戏](http://www.cs.vu.nl/~eliens/media/pattern-asynchronousgames.html)。 +11. [异步多人游戏：Ian Bogost 的休闲多人游戏体验](http://www.bogost.com/writing/asynchronous_multiplay_futures.shtml)的未来。 -![](img/4dc85258b3e084ceb6d7575e6f63baf6.png) +非常有趣的东西-感谢分享！ -我们最近在 [Mail.Ru Cloud](https://cloud.mail.ru/) 中添加了视频流服务。 开发首先考虑将新功能用作通用的“瑞士军刀”，它将播放任何格式的文件并可以在具有可用云的任何设备上工作。 上传到云端的视频内容大体上属于两类之一：“电影/系列”和“用户视频”。 后者是用户使用手机和相机拍摄的视频，就格式和编解码器而言，这些视频用途最为广泛。 由于许多原因，在没有事先进行标准化的情况下在其他最终用户设备上观看这些视频通常是一个问题：缺少必需的编解码器，或者文件太大而无法下载，等等。 +我真的没有这样的句子：“要招募更多的人要比招募更多的人容易得多。” 请解释。 -在本文中，我将详细介绍如何在 Mail.Ru Cloud 中播放视频，以及如何使 Cloud Player“杂食化”并确保对最大数量的最终用户设备的支持 。 +谢谢托德，它非常有用。 -## 存储和缓存：两种方法 +顺便说一句，我喜欢 Playfish 的运作方式： -上传后，许多服务（例如 YouTube，社交网络等）会将用户的视频转换为适当的格式。 视频只有在转换后才能播放。 Mail.Ru Cloud 中使用了另一种方法：**原始文件在播放时会进行转换**。 与某些专门的视频托管网站不同，我们无法更改原始文件。 我们为什么选择此选项？ Mail.Ru Cloud 主要是一种云存储，如果用户在下载文件时发现文件质量下降或文件大小发生了一些变化，他们将感到非常惊讶。 另一方面，我们无法承受**存储所有文件的预先转换后的副本：这将需要太多空间**。 我们还必须做很多额外的工作，因为某些存储的文件将永远不会被监视，甚至一次也不会被监视。 +> 由于您的朋友很少同时在线，因此社交游戏是异步进行的。 -快速转换的另一个优点是：如果我们决定更改转换设置或例如添加其他功能，则无需重新转换旧视频（并非总是如此） 可能，因为原始视频已经消失了）。 在这种情况下，一切都会自动应用。 +如果您认为 Cloud 最好，那显然是因为您尚未大规模使用它。 我们在亚马逊上运行着数百台服务器，而连接问题的数量（即无法到达实例，x 可用区网络问题）和它们具有的 I / O 性能让我们感到“惊讶”； 在过去的六个月中，他们最长可以无问题地停留的时间是 8 天，这意味着我们每周或更少的时间都会因为亚马逊的“超级云”而获得生产“成功”。 +我的建议：使用云来扩展和稳定，然后移开地狱。 干杯。 -## 这个怎么运作 +这是拼写错误的塞巴斯蒂安，谢谢。 -我们正在使用 Apple 创建的 HLS（HTTP 实时流）格式[进行在线视频流。 HLS 的思想是将每个视频文件都切成小片段（称为“媒体片段文件”），这些片段会添加到播放列表中，并为每个片段指定名称和时间（以秒为单位）。 例如，将一个两小时的电影切成十秒钟的片段，作为一系列 720 个媒体片段文件。 根据用户希望从哪一刻开始观看视频，播放器会从传输的播放列表中请求适当的片段。 **HLS** 的好处之一是**用户无需在播放器读取文件头时等待视频开始播放**（等待时间可能会很长） 如果是完整版电影且移动互联网速度较慢）。](https://developer.apple.com/streaming/) +克里斯，那是您的现代时代:-) -这种格式提供的另一个重要可能性是**自适应流**，它允许根据用户的 Internet 速度即时更改质量。 例如，您开始使用 3G 以 360p 观看，但是火车驶入 LTE 区域后，您将继续以 720p 或 1080p 观看。 它在 HLS 中非常简单地实现：播放器会获得“主播放列表”，其中包括针对不同带宽的备用播放列表。 加载片段后，播放器会评估当前速度，并据此决定下一个片段的质量：相同，较低或较高。 我们目前支持 240p，360p，480p，720p 和 1080p。 +很棒的文章 Tood，感谢您提供。 Playfish 在数据库分片方面的经验与我们在快速增长的 dbShards 实现中所发现的完全一样。 如上文所述，由于利用内存来实现数据库平衡，因此我们的社交应用程序以出色的性能运行。 -## 后端 +关于此报价： -， +> 在横向扩展情况下，您必须进行分片之类的操作，此时许多 SQL 功能都将消失。 您必须自己做很多工作。 现在，当您进行大批拆分时，您将无法添加索引。 -[![](img/879db0a8b28049344985b588f867cedc.png) ](https://habrastorage.org/files/1c6/c3e/67d/1c6c3e67dd6c4b0bbe4c2595aeffd099.png) +我们可以轻松支持混合使用典型表和键/值 blob 数据，就像 Playfish 一样。 -Mail.Ru 云服务由**三组服务器**组成。 第一组是**应用程序服务器**，它接受视频流请求：它创建一个 HLS 播放列表并将其发送回去，分发转换后的片段，并设置转换任务。 第二组是具有嵌入式逻辑的**数据库（ [Tarantool](http://tarantool.org/) ），用于存储视频信息并管理转换队列。 第三组**转换器**从 Tarantool 中的队列接收任务，然后将任务完成情况再次记录在数据库中。 收到视频文件片段的请求后，我们首先在我们的一台服务器上检查数据库，以获取转换后的质量要求的即用型片段。 这里有两种情况。** +我想知道其他人怎么想：传统表结构与键/值 Blob 的无缝结合？ 在这两种情况下，我们都可以支持高可用性操作，而无需开发人员的任何努力。 这样，您可以从常规表中获得所有索引/搜索优势，并且它们可以在适当的地方指向 Blob 值（例如，用户个人资料信息）。 -第一种情况：我们确实有一个转换后的片段。 在这种情况下，我们会立即将其寄回。 如果您或其他人最近提出了要求，则该片段将已经存在。 这是第一个缓存级别，适用于所有转换的文件。 值得一提的是，我们还使用了另一种缓存级别，其中经常请求的文件分布在多个服务器上，以避免网络接口过载。 +很棒的文章。 -第二种情况：我们没有转换后的片段。 在这种情况下，将在数据库中创建一个转换任务，我们等待它完成。 正如我们之前所说，它是 Tarantool（一个非常快速的开源 NoSQL 数据库，可让您在 Lua 中编写存储过程），它负责存储视频信息和管理转换队列。 应用程序服务器和数据库之间的通信如下进行。 应用服务器发出一个请求：“我需要 720p 质量的 movie.mp4 文件的第二个片段； 准备等待的时间不超过 4 秒钟”，并且在 4 秒钟之内它将收到有关从何处获取片段的信息或错误消息。 因此，数据库客户端对立即执行任务或通过一系列复杂的操作不感兴趣如何执行任务：它使用非常简单的界面，可以发出请求并接收所请求的内容。 - -我们提供数据库容错能力的方法是**主副本故障转移**。 数据库客户端仅将请求发送到主服务器。 如果当前的主服务器有问题，我们会将其中一个副本标记为主服务器，然后将客户端重定向到新的主服务器。 当客户端继续与主机交互时，这样的主副本切换对客户端是透明的。 - -除了应用程序服务器之外，还有谁可以充当数据库客户端？ 可能是那些准备开始转换片段的转换器服务器，现在需要到源视频文件的参数化 HTTP 链接。 这种转换器和 Tarantool 之间的通信类似于上述应用服务器的接口。 转换程序发出一个请求：“给我一个任务，我准备等待 10 秒钟”，如果任务在这 10 秒钟内出现，则将任务交给正在等待的转换程序之一。 我们在 Tarantool 内部的 Lua 中使用了 IPC 通道，以轻松实现客户端到转换器的任务转发。 通道允许不同请求之间的通信。 这是一些用于转换片段的简化代码： - -``` -function get_part(file_hash, part_number, quality, timeout) - -- Trying to select the requested fragment - local t = v.fragments_space.index.main:select(file_hash, part_number, quality) - - -- If it exists — returning immediately - if t ~= nil then - return t - end - - -- Creating a key to identify the requested fragment, and an ipc channel, then writing it - -- in a table in order to receive a “task completed” notification later - local table_key = msgpack.encode{file_hash, part_number, quality} - local ch = fiber.channel(1) - v.ctable[table_key] = ch - - -- Creating a record about the fragment with the status “want to be converted” - v.fragments_space:insert(file_hash, part_number, quality, STATUS_QUEUED) - - -- If we have idle workers, let’s notify them about the new task - if s.waitch:has_readers() then - s.waitch:put(true, 0) - end - - -- Waiting for task completion for no more than “timeout” seconds - local body = ch:get(timeout) - - if body ~= nil then - if body == false then - -- Couldn’t complete the task — return error - return box.tuple.new{RET_ERROR} - else - -- Task completed, selecting and returning the result - return v.fragments_space.index.main:select{file_hash, part_number, quality} - end - else - -- Timeout error is returned - return box.tuple.new{RET_ERROR} - end -end - -local table_key = msgpack.encode{file_hash, part_number, quality} -v.ctable[table_key]:put(true, 0) -``` - -实际的代码稍微复杂一点：例如，它考虑了在请求时片段处于“正在转换”状态的场景。 由于采用了这种方案，转换器可以立即收到新任务的通知，而客户端也可以立即收到任务的完成的通知。 这非常重要，因为用户看到视频加载微调器的时间越长，他们甚至有可能在视频开始播放之前就离开页面。 - -如下图所示，大多数转化，因此等待时间不会超过几秒钟。 - -![](img/9aa2115022459dd03949867463346deb.png) - -## 转换次数 - -对于**转换**，我们使用的是根据需要修改的 **FFmpeg** 。 我们最初的计划是使用 FFmpeg 内置工具进行 HLS 转换。 但是，我们的用例遇到了问题。 如果您要求 FFmpeg 将 20 秒的文件转换为具有 10 秒的片段的 HLS，则会得到两个文件和一个播放列表，它们可以毫无问题地播放。 但是，如果您要求先转换 0 至 10 秒，然后再转换 10 至 20 秒（启动 FFmpeg 转换器的另一个实例），则从一个文件转换为另一个文件时（大约在 10 秒），您会听到明显的喀哒声。 我们花了几天时间尝试不同的 FFmpeg 设置，但没有成功。 因此，我们必须进入 FFmpeg 并编写一个小补丁。 它需要一个命令行参数来解决“ click”错误，该错误源于对音频和视频轨道进行编码的细微差别。 - -此外，我们还使用了当时尚未包含在 FFmpeg 上游的其他一些可用补丁。 例如，一个[补丁](https://trac.ffmpeg.org/ticket/2513)，用于解决 MOV 文件转换缓慢的已知问题（由 iPhone 制作的视频）。 一个名为“ Aurora” 的**守护程序控制从数据库获取任务并启动 FFmpeg 的过程。 “ Aurora”守护程序以及位于数据库另一端的守护程序都是用 Perl 编写的，并且与 EV 事件循环和各种有用的模块异步工作，例如： [EV-Tarantool](https://github.com/Mons/EV-Tarantool) 和 [Async :: Chain](https://metacpan.org/pod/Async::Chain) 。** - -有趣的是，**没有为 Mail.Ru Cloud 中的新视频流服务**安装额外的服务器：转换（需要大量资源的部分）在特别隔离的环境中在我们的存储上运行。 日志和图形显示，我们的能力所能承受的负载是我们现在所能承受的几倍。 仅供参考：自我们的视频流媒体服务于 2015 年 6 月启动以来，已请求 **500 万以上的独特视频； 每分钟观看 500–600 个唯一文件**。 - -## 前端 - -如今，几乎每个人都拥有智能手机。 或两个。 为您的朋友和家人制作简短的视频没什么大不了的。 这就是为什么我们准备好有人将视频从手机或平板电脑上传到 Mail.Ru Cloud 并立即从其设备中删除视频以释放空间的情况。 如果用户想向他人展示此视频，则只需使用 Mail.Ru Cloud 应用程序将其打开，或在其桌面上的 Cloud Web 版本中启动播放器。 现在可以不在手机上存储所有视频片段，同时始终可以在任何设备上访问它们。 移动互联网上的流式传输比特率降低了，因此，以兆字节为单位的大小也降低了。 - -此外，在移动平台上播放视频时，我们使用 Android 和 iOS 本机库。 这就是为什么视频可以在移动浏览器中“开箱即用”的智能手机和平板电脑上播放的原因：我们无需为使用的格式创建额外的播放器。 与网络版本相似，在台式计算机上，自适应流机制被激活，并且图像质量动态适应当前带宽。 - -我们的播放器与竞争对手的播放器之间的主要区别之一是我们的视频播放器独立于用户的环境。 在大多数情况下，开发人员会创建两个不同的播放器：一个是带有 Flash 界面的播放器，另一个是（具有本地 HLS 支持的浏览器，例如 Safari），一个是完全相同的，但是用 HTML5 实现，随后上传了适当的文件。 接口。 我们只有一名球员。 我们的目标是可以轻松更改界面。 因此，我们的播放器在视频和音频方面看起来都非常相似-所有图标，布局等均以 HTML5 编写。 播放器不依赖于播放视频所使用的技术。 - -我们使用 Flash 绘制视频，但是整个界面都基于 HTML； 因此，我们不会遇到版本同步问题，因为不需要支持特定的 Flash 版本。 一个开放源代码库足以播放 HLS。 我们编写了一个垫片，将 HTML5 视频元素界面转换为 Flash。 这就是为什么我们可以假设我们将始终使用 HTML5 来编写整个界面的原因。 如果浏览器不支持这种格式，我们只需将本地视频元素替换为自己的实现相同界面的元素。 - -如果用户的设备不支持 Flash，则视频将以具有 HLS 支持的 HTML5 播放（到目前为止，仅在 Safari 中实现）。 使用本地工具在 Android 4.2+和 iOS 上播放 HLS。 如果没有支持且没有本机格式，我们将为用户提供文件下载。 - -## *** - -如果您有实现视频播放器的经验，欢迎访问评论部分：我非常想知道如何将视频分成多个片段，如何在存储和缓存之间进行选择，以及面临的其他挑战。 总之，让我们分享我们的经验。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=11375147) - -很棒的文章！ - -很棒的文章。 您能告诉我们更多有关 ffmpeg 补丁以消除音频点击的信息吗？ - -谢谢。 如此棒的文章。 - -因此，转换的视频（频繁和较少）在 ttl 之后会自动删除吗？ -其次，为什么转换器使用 http 协议从存储中获取视频？ 使用套接字不能更快完成吗？ - -您启动了多少个 tarantool 实例？ TT 集群有多大？ - -对于此特定任务，我们只有两个实例-主实例和副本实例。 我们知道，在 Mail.Ru 集团的在线广告系统上，生产中的 Tarantool 集群的最大规模约为 500 个实例。 - -For this specific task we only have two instances - a master and a replica. The maximum knows to us size of a Tarantool cluster at production is around 500 instances at the Mail.Ru Group's online ad system. \ No newline at end of file +他们使用什么 Web 服务器？ \ No newline at end of file diff --git a/docs/52.md b/docs/52.md index 77ad12d..d5816e3 100644 --- a/docs/52.md +++ b/docs/52.md @@ -1,98 +1,12 @@ -# 如今 Etsy 的架构是什么样的？ +# 扩展 BBC iPlayer 的 6 种策略 -> 原文： [http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html](http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html) +> 原文： [http://highscalability.com/blog/2010/9/28/6-strategies-for-scaling-bbc-iplayer.html](http://highscalability.com/blog/2010/9/28/6-strategies-for-scaling-bbc-iplayer.html) -![](img/9e364140091b80d83d988a6634e2f7c6.png) +英国广播公司（BBC）的 iPlayer 网站平均每天有 130 万用户浏览 800 万次页面。 技术架构师 Simon Frost 在[中描述了他们如何扩展站点，将 BBC iPlayer 缩放以处理需求](http://www.bbc.co.uk/blogs/bbcinternet/2010/07/scaling_the_bbc_iplayer_to_han.html)： -*这是 [Christophe Limpalair](https://twitter.com/ScaleYourCode) 的来宾帖子，基于他对 [Jon Cowie](https://twitter.com/jonlives) ，员工运营部所做的[采访](https://scaleyourcode.com/interviews/interview/25)（[视频](https://www.youtube.com/watch?v=3vV4YiqKm1o)） 工程师和 Breaksmith @ Etsy。* - -随着 Etsy 从新平台过渡到稳定且完善的电子商务引擎，Etsy 成为了一个令人着迷的观看和研究平台。 这种转变需要进行很多文化上的改变，但最终结果却是惊人的。 - -如果您还没看过的话，2012 年上有一篇[帖子概述了他们的成长和转变。 但是从那以后发生了什么？ 他们还在创新吗？ 如何制定工程决策，这如何影响他们的工程文化？ 这些是我们与 Etsy 的一名运维工程师，定制厨师的作者 Jon Cowie 在新的播客节目中探讨的问题。](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html) - -## [](#what-does-etsys-architecture-look-like-nowadays)如今 Etsy 的架构是什么样的？ - -自上一次更新可追溯到 2012 年以来（在前面提到的帖子中），他们的体系结构并没有真正改变太多。 尽管这听起来有些无聊，但它概述了一个重要的概念，并为我们提供了对 Etsy 的工程文化的一些见识。 在整篇文章中，我们都会回头介绍这种文化，但这是它们的总体架构： - -Etsy 的生产基础设施全是裸机。 但是，在开发方面，他们可以虚拟化环境。 这为每个开发人员提供了一个代表整个堆栈缩影的虚拟机。 最终，虚拟环境仍在 Etsy 自己的物理硬件上运行。 - -实际的堆栈本身仍然看起来像这样： - -* 的 Linux -* 阿帕奇 -* 的 MySQL -* 的 PHP -* 缓存层 -* F5 负载平衡器 - -它们具有许多具有不同作业的不同缓存层。 他们大量使用 memcached 缓存数据库对象。 - -Etsy 具有面向第三方开发人员的面向公众的 API，并且还具有内部 API。 这些 API 有缓存层，因为有些答案不是短暂的。 例如，如果一个答案生存一个小时或更长时间，他们可能会缓存它。 - -当然，它们也大量缓存图像和静态资产。 - -这里的挑战是缓存失效。 确保您没有向用户提供过时的内容，而是充分利用了缓存以尽可能减少数据库的负载。 另外，请确保您通过将其缓存到更接近最终用户的方式，更快地向用户提供响应。 Etsy 团队还深深地关心着这件事，这在其工程博客 CodeasCraft.com 上的定期性能报告中可以明显看出。 - -尽管总体架构几乎相同，但这并不意味着 Etsy 工程师和 Ops 团队一直坐在那里摆弄他们的拇指。 好吧，也许其中一些有，但是我离题了... - -## [](#so-what-are-their-ops-challenges-do-they-still-have-to-put-out-fires)那么他们的操作挑战是什么？ 他们还必须灭火吗？ - -我们只是看到了它们在成熟可靠的技术方面会如何出错，因此他们不会花费太多时间扑灭火灾。 新问题往往来自引入新系统。 我敢肯定，你们中的许多人以前都读过这篇文章：您介绍了一个新的系统，该系统在纸上可以解决您的所有问题。 除非它对您环境中当前的其他组件具有复杂且“不可能”的反应。 因此，您必须找出导致问题的原因以及解决方法。 - -老实说，如果您从事这一领域，那么您可能会活在当下。 这些有趣的挑战使您抓狂，您真的想弄清楚，以便继续进行下一个挑战。 除非有时花费的时间太长，然后变得很麻烦。 - -大多数公司面临的另一个挑战是试图雇用优秀人才。 您在哪里还能找到优秀的人才？ 如果您正在使用新的“热门功能”，则可能很难找到该人才，而且价格会昂贵得多。 但是，如果您选择像 PHP 这样成熟的东西，它并不是那么困难。 仍然很难，但是不像为 Scala 找到人那样难。 - -到目前为止，已有许多 PHP 工具出现了十年，而语言也是如此。 许多前沿漏洞已被消除。 这意味着更少的难以发现的怪异错误，以及更多的专家可以聘用。 - -## [](#does-that-mean-they-never-change-anything-in-their-architecture)这是否意味着他们从不更改架构中的任何内容？ - -不，绝对不是。 这意味着他们拥有制定使用新技术的决策的明确流程。 - -他们实际上使用一种工具来创建“体系结构评论”，支持者在其中输入支持材料和该思想背后的理论。 然后，一个团队将提出一个他们认为适合 Etsy 当前环境的概念。 - -让我们看一个最近的例子。 他们介绍了 Kafka 用于事件流水线。 为了做到这一点，一个团队提出了一个用例，说明了为什么要使用 Kafka 以及如何解决 Etsy 的实际问题。 然后，他们进行了体系结构审查，高级工程师和所有相关方聚集在一起讨论该提案。 - -它是一种成熟且成熟的技术吗？ - -它会真正解决问题吗？这是解决问题的最佳方法吗？ - -组件将如何与我们的系统反应？ - -谁来支持这个？ - -一旦回答了这些问题，它们便进入实施阶段。 - -在上线之前，它必须经历另一个称为“可操作性审查”的过程，该过程将验证一切是否就绪。 这包括设置适当的监视和警报，为每个待命人员设置适当的程序，等等。 与该实现有关的每个人都必须参与“什么，何时，如何”。 - -另一个重要的考虑因素是：“我们可以通过在已经拥有的工具上构建它来做到这一点吗？” 稍后，我们将详细介绍。 - -这些是在实施建议的技术之前必须回答的问题。 这种彻底的分析可能需要一些时间，但是对于已建立的电子商务平台而言，正常运行时间至关重要。 - -“我们非常重视站点的正常运行时间，可靠性和总体可操作性。” - -## [](#customizing)自定义 - -我们已经看到 Etsy 的文化如何促进稳定。 我们还没有讨论的是它如何鼓励定制现有工具。 - -就像我们刚刚看到的那样，与其实施一个新的工具来解决问题，不如定制一个正在使用的工具，这更有意义。 一个典型的例子是定制 Chef。 乔恩·考伊（Jon Cowie）成为一些有影响力的厨师定制的一部分，例如[刀叉](https://github.com/jonlives/knife-spork)。 这种自定义实际上来自 Etsy 团队试图解决的问题。 当多个开发人员同时对同一 Chef Server 和存储库进行更改时，更改将被覆盖。 Jon 负责这个工具，不仅为一个大型开源社区提供了帮助，而且还解决了 Etsy 的一个关键且局限性的问题。 - -这是激发乔恩（Jon）编写 [Customizing Chef](http://shop.oreilly.com/product/0636920032984.do) 的一部分。 这是他希望自己拥有的书。 - -这也是 Chef 开源文化的一个很好的例子。 乔恩（Jon）强调说，Chef 并非设计为“一刀切”的解决方案。 它旨在为人们提供一个工具包，使我们能够解决自己的自动化问题。 Chef 的想法是，用户是他们自己系统的专家。 虽然它不能告诉您该怎么做，但它为您提供了工具，因此您可以自己做出决定，然后告诉您想要什么。 - -当然，这并不是说定制没有自己的问题。 如果自定义某些内容，则必须“拥有它”。 一旦决定开源该工具或自定义工具，它将变得更加复杂。 实际上，Etsy 在决定开放源代码工具之后就对此产生了疑问。 他们将开放该工具的源代码，但随后工程师将在本地下拉版本，为 Etsy 基础结构对其进行编辑，然后再将其推回主存储库。 许多项目只是没有被更新。 - -他们是如何解决的？ 通过适当的程序。 就像想要在系统中引入新技术一样，如果您想在 Etsy 开放项目的源代码，则需要回答一些有关该项目及其维护方式的问题。 - -它也很多都承认哪些项目不再需要维护了。 他们最终完成了多个项目，并明确表示不再进行更新。 这样一来，他们就可以重新组合并专注于内部实际使用的工具。 - -“因此，我们已经建立的流程更加适合确保我们只开源自己在生产中积极使用的东西。” - -因为归根结底，如果没有人要维护一种工具，那么它可能不会对整个社区有所帮助。 - -## [](#what-about-you)你呢？ - -您的过程和思维方式有何不同？ 您从 Etsy 的方法中学到了什么吗？ 从他们的工程文化和开放源代码实践怎么样？ - -[关于 HackerNews](https://news.ycombinator.com/item?id=11345723) \ No newline at end of file +1. **使用框架**。 框架支持基于组件的开发，这使其便于团队开发，但是会引入必须最小化的延迟。 使用 Zend / PHP 是因为它支持组件且易于招募。 MySQL 用于程序元数据。 CouchDB 用于键值访问，以快速读取/写入以用户为中心的数据。 +2. **在构建架构之前先对其进行验证**。 通过提出其他架构来消除猜测，并创建原型以确定哪个选项最有效。 在性能与易于开发等因素之间取得平衡。 +3. **缓存很多**。 数据会在 memcached 中缓存几秒钟到几分钟。 较短的缓存失效期使用户的数据保持最新，但是即使这些短暂的时期也会在性能上产生巨大差异。 缓存不必花很长时间才能看到好处。 Varnish 用于缓存 HTML 页面。 大多数无效是基于时间或基于动作的（例如，有人添加了新的收藏夹）。 +4. **将页面分为个性化和标准组件**。 创建一个公共主页，以便可以将其与个性化数据分开进行缓存。 这样可以提供更快，更流畅的观看体验。 使用 Ajax 加载个性化元素。 Varnish 的灵活缓存策略用于缓存这些元素。 用户收藏夹列表仅缓存几分钟。 +5. **使用大量服务器**。 使用服务器池可横向扩展。 Web 服务器是无状态的。 页面由两个数据中心提供，以实现高可用性。 +6. **在启动**之前测试站点。 加载测试以在用户看到问题之前跟踪并修复问题。 \ No newline at end of file diff --git a/docs/53.md b/docs/53.md index afec160..4598b84 100644 --- a/docs/53.md +++ b/docs/53.md @@ -1,363 +1,96 @@ -# Jeff Dean 在 Google 进行大规模深度学习 +# Facebook 的新实时消息系统：HBase 每月可存储 135 亿条消息 -> 原文： [http://highscalability.com/blog/2016/3/16/jeff-dean-on-large-scale-deep-learning-at-google.html](http://highscalability.com/blog/2016/3/16/jeff-dean-on-large-scale-deep-learning-at-google.html) +> 原文： [http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html](http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html) - -*If you can’t understand what’s in information then it’s going to be very difficult to organize it.* +![](img/05b2f60819d28aa5d0e59ecb0a2b699e.png) -此引用来自 [Jeff Dean](http://research.google.com/pubs/jeff.html) ，现为 Google 系统基础架构小组的向导，研究员，研究员。 摘自他最近的演讲： [智能计算机系统的大规模深度学习](https://www.youtube.com/watch?v=QSaZGT4-6EY) 。 +您可能已经在某处阅读了 Facebook 推出了一个新的[社交收件箱](http://blog.facebook.com/blog.php?post=452288242130)，该电子邮件集成了电子邮件，IM，SMS，文本消息，Facebook 站点上的消息。 他们每个月总共需要存储 1,350 亿条消息。 他们将所有这些东西存储在哪里？ Facebook 的 Kannan Muthukkaruppan 在[消息的基础技术](http://www.facebook.com/note.php?note_id=454991608919#)： [HBase](http://hbase.apache.org/) 中给出了惊奇的答案。 HBase 击败了 MySQL，Cassandra 等。 -自 [AlphaGo 诉 Lee Se-dol](https://gogameguru.com/tag/deepmind-alphago-lee-sedol/) 以来， [John Henry](https://en.wikipedia.org/wiki/John_Henry_(folklore)) 的现代版本 与 的致命一击 [像蒸汽锤一样，已经笼罩了整个世界，人们普遍对 AI 感到恐惧](https://www.youtube.com/watch?v=j3LVFdWBHVM) [[ 启示录](http://thenextweb.com/insider/2014/03/08/ai-could-kill-all-meet-man-takes-risk-seriously/) ，这似乎是掩盖 Jeff 演讲的绝佳时机。 而且，如果您认为 AlphaGo 现在很好，请等到 beta 达到。 +为什么会有惊喜？ Facebook 创建了 Cassandra，它是专门为收件箱类型的应用程序而构建的，但是他们发现 Cassandra 的最终一致性模型与其新的实时 Messages 产品并不匹配。 Facebook 还拥有广泛的 [MySQL 基础架构](http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html)，但他们发现随着数据集和索引的增大，性能会受到影响。 他们本可以构建自己的，但是他们选择了 HBase。 -Jeff 当然是指 Google 臭名昭著的 [座右铭](https://www.google.com/about/company/) ： *整理世界各地的信息并将其广泛地传播 可访问且有用的* 。 +HBase 是 *[扩展表存储，支持对大量数据](http://www.cloudera.com/blog/2010/06/integrating-hive-and-hbase/)* 的很高级别的行级更新。 消息系统确实需要什么。 HBase 还是建立在 [BigTable](http://en.wikipedia.org/wiki/HBase) 模型上的基于列的键值存储。 它擅长通过键获取行或扫描行范围并进行过滤。 消息系统还需要什么。 但是不支持复杂查询。 通常会向查询工具提供诸如 [Hive](http://wiki.apache.org/hadoop/Hive/HBaseIntegration) 之类的分析工具，该工具是 Facebook 创建的，以理解其多 PB 数据仓库，并且 Hive 基于 Hadoop 的文件系统 HDFS，HBase 也使用该文件系统。 -从历史上看，我们可能会将“组织”与收集，清理，存储，建立索引，报告和搜索数据相关联。 早期 Google 掌握的所有东西。 完成这项任务后，Google 便迎接了下一个挑战。 +Facebook 之所以选择 HBase 是因为他们**监控了其使用情况，并弄清了真正需要的**。 他们需要的是一个可以处理两种数据模式的系统： -现在 **的组织意味着对** 的理解。 +1. 一小段时间数据往往易变 +2. 不断增长的数据集，很少被访问 -我的演讲重点： +说得通。 您会一次阅读收件箱中的最新信息，然后很少再看一次。 这些是如此不同，可能期望使用两个不同的系统，但是显然 HBase 对于两个系统都足够好。 尽管它们确实与 v [各种搜索系统](http://mail-archives.apache.org/mod_mbox/hbase-user/201006.mbox/%3C149150.78881.qm@web50304.mail.re2.yahoo.com%3E)集成在一起，但它们如何处理通用搜索功能尚不清楚，因为这并不是 HBase 的优势。 -* **实际的神经网络由数亿个参数**组成。 Google 的技能在于如何在大型有趣的数据集上构建并快速训练这些庞大的模型，将其应用于实际问题，*和*然后将模型快速部署到各种不同平台（电话）中的生产环境中 ，传感器，云等）。 +他们系统的一些关键方面： -* 神经网络在 90 年代没有兴起的原因是**缺乏计算能力，也缺少大型有趣的数据集**。 您可以在 Google 上看到 Google 对算法自然的热爱，再加上庞大的基础架构和不断扩大的数据集，如何为 AI 掀起**完美的 AI 风暴。** +* HBase： + * 具有比 Cassandra 更简单的一致性模型。 + * 它们的数据模式具有非常好的可伸缩性和性能。 + * 大多数功能满足其需求：自动负载平衡和故障转移，压缩支持，每台服务器多个分片等。 + * HFS 使用的文件系统 HDFS 支持复制，端到端校验和和自动重新平衡。 + * Facebook 的运营团队在使用 HDFS 方面具有丰富的经验，因为 Facebook 是 Hadoop 的大用户，而 Hadoop 使用 HDFS 作为其分布式文件系统。 +* [Haystack](http://www.facebook.com/note.php?note_id=76191543919) 用于存储附件。 +* 从头开始编写了一个自定义应用程序服务器，以服务来自许多不同来源的大量消息流入。 +* 在 [ZooKeeper](http://highscalability.com/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html "http://hadoop.apache.org/zookeeper/") 之上编写了一个用户发现服务。 +* 可以通过以下方式访问基础结构服务：电子邮件帐户验证，朋友关系，隐私决策和传递决策（是否应该通过聊天或 SMS 发送消息？）。 +* 随着他们的小团队以惊人的方式做事，一年内有 15 位工程师发布了 [20 个新的基础架构服务](http://www.theregister.co.uk/2010/11/15/facebooks_largest_ever_engineering_project/)。 +* Facebook 不会在单个数据库平台上实现标准化，他们将使用单独的平台来完成单独的任务。 -* Google 与其他公司之间的关键区别在于，当他们在 2011 年启动 Google Brain 项目时， **并未将他们的研究留在象牙塔** 。 项目团队与 Android，Gmail 和照片等其他团队密切合作，以实际改善这些属性并解决难题。 对于每个公司来说，这都是难得的，也是一个很好的教训。 **通过与您的员工合作进行研究** 。 +我不会想到 Facebook 已经作为 HBase 的重要推动者，已经在 HDFS / Hadoop / Hive 方面拥有丰富的经验。 任何产品都可以与另一个非常受欢迎的产品合作，以期成为生态系统的一部分，这是梦想。 这就是 HBase 实现的。 鉴于 HBase 如何在持久性频谱中占据一席之地-实时，分布式，线性可伸缩，健壮，BigData，开源，键值，面向列-我们应该看到它变得越来越流行，尤其是在 Facebook 的油膏。 -* 这个想法很有效：他们了解到他们可以采用一整套子系统，其中一些子系统可以通过机器学习，并且 **替换为更通用的端到端 终端机器学习资料** 。 通常，当您有很多复杂的子系统时，通常会有很多复杂的代码将它们缝合在一起。 如果您可以用数据和非常简单的算法替换所有内容，那就太好了。 - -* **机器学习只会变得更好，更快。** 。 杰夫的一句话：机器学习社区的发展确实非常快。 人们发表了一篇论文，并且在一周之内，全世界许多研究小组下载了该论文，阅读，进行了剖析，对其进行了理解，对其进行了一些扩展，并在 [上发布了自己的扩展。 arXiv.org](http://arxiv.org/) 。 它与计算机科学的许多其他部分不同，在其他方面，人们将提交论文，六个月后，一个会议将决定是否接受该论文，然后在三个月后的会议中发表。 到那时已经一年了。 将时间从一年缩短到一周，真是太神奇了。 - -* **可以魔术方式组合技术** 。 翻译团队使用计算机视觉编写了可识别取景器中文本的应用程序。 它翻译文本，然后将翻译后的文本叠加在图像本身上。 另一个示例是编写图像标题。 它将图像识别与序列到序列神经网络相结合。 您只能想象将来所有这些模块化组件将如何组合在一起。 - -* **具有令人印象深刻的功能的模型在智能手机** 上足够小。 为了使技术消失，情报必须走到最前沿。 它不能依赖于连接到远程云大脑的网络脐带。 由于 TensorFlow 模型可以在手机上运行，​​因此这可能是可能的。 - -* 如果您不考虑如何使用深度神经网络来解决数据理解问题， **几乎可以肯定是** 。 这条线直接来自谈话，但是在您使用深层神经网络解决了棘手的问题之后，观察到棘手的问题后，事实就很清楚了。 - -Jeff 总是进行精彩的演讲，而这一演讲也不例外。 它简单，有趣，深入并且相对容易理解。 如果您想了解深度学习知识，或者只是想了解 Google 在做什么，那么必须要看的是 。 - -谈话内容不多。 它已经包装好了。 因此，我不确定本文将为您带来多少价值。 因此，如果您只想观看视频，我会理解的。 - -与 Google 对话一样，您会感到我们只被邀请到 Willy Wonka 的巧克力工厂的大厅里。 我们面前是一扇锁着的门，我们没有被邀请进来。那扇门之外的东西一定充满了奇迹。 但是，就连威利旺卡（Willy Wonka）的大厅也很有趣。 - -因此，让我们了解杰夫对未来的看法……这很令人着迷... - -## 理解意味着什么？ - -* 当向人们展示街道场景时，他们可以毫无问题地从场景中挑选文字，了解到一家商店出售纪念品，一家商店的价格确实很低，等等。 直到最近，计算机还无法从图像中提取此信息。 - -![](img/d9c5bdf722db9f4061822228edcff450.png) - -* 如果您真的想从图像中了解物理世界，则计算机需要能够挑选出有趣的信息，阅读并理解它们。 - -* 小型移动设备在当今和将来都主导着计算机交互。 这些设备需要不同类型的接口。 您需要真正能够理解并产生语音。 - -* 进行查询：[待售汽车零件]。 旧的 Google 会匹配第一个结果，因为关键字匹配，但是比较好的匹配是第二个文档。 真正了解查询的含义是深层次而不是肤浅的单词层次，这是构建良好的搜索和语言理解产品所需要的。 - -![](img/0ad48db760cd6b9f0ffb6dacb5986958.png) - -## Google 的深度神经网络简史 - -* [Google Brain 项目](https://en.wikipedia.org/wiki/Google_Brain) 从 2011 年开始，致力于真正推动神经网络技术的发展。 - -* 神经网络已经存在很长时间了。 它们在 60 年代和 70 年代发明，并在 80 年代末和 90 年代初流行，但它们逐渐消失了。 两个问题：1）缺乏训练大型模型所需的计算能力，这意味着无法将神经网络应用于较大的有趣数据集上的较大问题。 2）缺少大量有趣的数据集。 - -* 仅与 Google 的几个产品组合作。 随着时间的流逝，随着小组发布的好消息或解决了以前无法解决的问题的消息，周围的人流连忘返，更多的团队会去帮助他们解决问题。 - -* 一些使用深度学习技术的产品/领域：Android，Apps，药物发现，Gmail，图像理解，地图，自然语言，照片，机器人技术，语音翻译等。 - -* **深度学习可以应用在如此多样化的项目**中的原因是，它们**涉及到适用于不同领域的同一组构建模块**：语音，文本，搜索查询，图像， 视频，标签，实体，单词，音频功能。 您可以输入一种信息，确定要使用的信息，一起收集表示要计算的功能的训练数据集，然后就可以使用了。 - -* 这些模型运作良好，因为 **您以非常原始的数据形式输入** ，您无需手工设计很多有趣的功能， 该模型的强大功能在于它能够通过观察大量示例来自动确定数据集的有趣之处。 - -* 您可以学习通用表示法，可能跨域学习。 例如，“汽车”的含义可能与汽车的图像相同。 - -* 他们已经知道他们可以采用一整套子系统，其中一些子系统可能是机器学习的，因此**替换为更通用的端到端机器学习文章**。 通常，当您有很多复杂的子系统时，通常会有很多复杂的代码将它们缝合在一起。 如果您可以用数据和非常简单的算法替换所有内容，那就太好了。 - -## 什么是深度神经网络？ - -* [神经网络](https://en.wikipedia.org/wiki/Artificial_neural_network) 从数据中学到了非常复杂的功能。 来自一个空间的输入将转换为另一个空间的输出。 - -* 此功能与 x 2 不同，它是一个非常复杂的功能。 例如，当您输入原始像素（例如猫）时，输出将是对象类别。 - -![](img/89ac3f5ffa45828e335ec58c362f89f2.png) - -* 深度学习中的“ **深度**”是指神经网络中的**层数。** - -* 深度的一个不错的特性是该系统由简单且可训练的数学函数 的 **集合组成。** - -* 深度神经网络与许多机器学习风格兼容。 - - * 例如，您有一个输入，即猫的图片，而输出中有人将该图像标记为猫，则称为 [监督学习](https://en.wikipedia.org/wiki/Supervised_learning) 。 您可以为系统提供许多受监管的示例，并且您将学习近似于与在受监管的示例中观察到的功能相似的函数。 - - * 您也可以进行 [无监督训练](https://en.wikipedia.org/wiki/Unsupervised_learning) ，其中仅显示图像，不知道图像中包含什么。 然后，系统可以学习掌握在许多图像中出现的模式。 因此，即使您不知道该怎么称呼图像，它也可以识别出其中所有带有猫的图像都具有共同点。 - - * 还与 [强化学习](https://en.wikipedia.org/wiki/Reinforcement_learning) 等更奇特的技术兼容，这是一种非常重要的技术，已被用作一种 AlphaGo。 - -## 什么是深度学习？ - -* 神经网络模型**宽松地基于我们认为大脑的行为**。 这不是神经元真正工作原理的详细模拟。 这是神经元的简单抽象版本。 ![](img/cdb6dfc91acfa8a69172a2463d25b918.png) - -* 神经元有很多输入。 真实的神经元可以将不同的强度与不同的输入相关联。 人工神经网络尝试学习所有这些边上的权重，这些权重是与不同输入相关的优势。 - -* 真实的神经元会结合其输入和强度，并决定触发或不触发，即尖峰。 - - * 人工神经元不仅发出尖峰，还发出实数值。 这些神经元计算的功能是其输入的加权总和乘以通过某些非线性函数施加的权重。 - - * 通常，当今使用的非线性函数是 [整流线性单元](https://en.wikipedia.org/wiki/Rectifier_(neural_networks)) （最大值（0，x））。 在 90 年代，许多非线性函数是 [更平滑的](https://www.quora.com/What-is-special-about-rectifier-neural-units-used-in-NN-learning) S 型或正弦函数。 它具有不错的特性，即当神经元不触发时提供真实的零，而接近零的值可以在优化系统时为您提供帮助。 - - * 例如，如果神经元作为权重为-0.21、0.3 和 0.7 的三个输入 X1，X1，X3，则计算将为：y = max（0，-.0.21 * x1 + 0.3 * x2 + 0.7 * x3）。 - -* 在确定图像是猫还是狗时，图像将经过一系列图层放置。 一些神经元会根据其输入而激发或不激发。 - ![](img/61db59709a26ec559bff968acd2f37f0.png) - - * 最低层的神经元将看着小块像素。 较高级别的神经元将查看下面的神经元的输出，并决定是否触发。 - - * 该模型将逐步向上移动，例如说它是一只猫。 在这种情况下哪个是错的，那是一条狗（尽管我也以为是猫，还是在篮中的狗？）。 - - * 这是一个错误决策的信号会反馈到系统中，然后该信号将对模型的其余部分进行调整，以使下次查看图像时输出看起来像狗一样。 - - * 这就是神经网络的**目标，** **对整个模型中所有边缘**的权重进行很小的调整 **，以使您更有可能正确理解示例 。 您可以在所有示例中进行汇总，以便正确地使用大多数示例。** - -* 学习算法非常简单。 未完成时： - - * 选择一个随机训练示例“（输入，标签）”。 例如，带有所需输出“ cat”的猫图片。 - - * 在“输入”上运行神经网络，并查看其产生的结果。 - - * 调整边缘的权重以使输出更接近“标签” - -* 如何调整边缘的权重以使输出更接近标签？ - - * [反向传播](http://mattmazur.com/2015/03/17/a-step-by-step-backpropagation-example/) 。 以下是推荐的解释： [计算图上的演算：反向传播](http://colah.github.io/posts/2015-08-Backprop/) 。 - - * 微积分的 [链规则](https://www.khanacademy.org/math/differential-calculus/taking-derivatives/chain-rule/v/chain-rule-introduction) 用于确定当选择的是猫而不是狗时，在神经网络的顶部，您了解如何调整 最顶层的权重使其更可能说狗。 - -![](img/c984e94586f32c795a59ffaf31a30922.png) - -* 您需要使用权重朝箭头方向前进，以使其更有可能说狗。 不要迈出大步，因为它是复杂的不平坦表面。 采取非常小的步骤，使其更有可能在下一次遇到狗。 通过多次迭代并查看示例，结果更有可能成为狗。 - -* 通过链式规则，您可以了解较低层的参数更改将如何影响输出。 这意味着网络中的 **变化可以通过** 一直回荡到输入，从而使整个模型适应并更有可能说狗。 - -* 真正的神经网络是 **，它由数亿个参数组成** ，因此您要在亿维空间中进行调整，并尝试了解其影响 网络的输出。 - -## 神经网络的一些不错的特性 - -* **神经网络可以应用于许多不同类型的问题** （只要您有很多有趣的数据需要理解）。 - - * 文字：英语和其他语言的单词数以万亿计。 有很多对齐的文本，在一个句子的层次上有一种语言的翻译版本和另一种语言的翻译版本。 - - * 视觉数据：数十亿个图像和视频。 - - * 音频：每天数万小时的语音。 - - * 用户活动：有许多不同的应用程序在生成数据。 例如来自搜索引擎的查询或在电子邮件中标记垃圾邮件的人。 您可以学习许多活动并构建智能系统。 - - * 知识图：数十亿标记的关系三倍。 - -* **如果向它们投入更多数据，并使模型更大，则结果往往会更好** 。 - - * 如果您在问题上投入了更多数据而又没有使模型更大，则可以通过学习有关数据集的更显而易见的事实来饱和模型的容量。 - - * **通过增加模型的大小，它不仅可以记住明显的事物**，而且可以记住可能仅在数据集中的一小部分示例中出现的细微模式。 - - * 通过在更多数据上构建更大的模型 **，需要进行更多的计算** 。 Google 一直在努力研究如何扩展计算量以解决这些问题，从而训练更大的模型。 - -## 深度学习对 Google 有何重大影响？ - -### 语音识别 - -* 这是 Google Brain 团队与之合作部署神经网络的第一批团队之一。 他们帮助他们部署了基于神经网络的新声学模型，而不是他们所使用的 [隐藏马尔可夫模型](https://en.wikipedia.org/wiki/Hidden_Markov_model) 。 - -* 声学模型的问题是要从语音的 150 毫秒转到预测在 10 毫秒的中间发出什么声音。 例如，是 ba 还是 ka 声音？ 然后，您将获得这些预测的完整序列，然后将它们与语言模型结合在一起，以了解用户的意见。 - -* 他们的初始模型 **将字识别错误减少了 30％** ，这确实是一个大问题。 从那时起，语音团队一直在研究更复杂的模型和高级网络，以进一步降低错误率。 现在，当您在电话里讲话时，语音识别比三五年前要好得多。 - -### ImageNet 挑战 - -* 大约 6 年前，发布了 [ImageNet](http://image-net.org/) 数据集。 当时大约有 100 万张图像，是计算机视觉的最大数据集之一。 这个庞大的数据集的发布推动了计算机视觉领域的发展。 - - * 将图像放置在大约 1000 个不同类别中，每个类别大约放置 1000 张图像。 - - * 有上千种不同的豹子，小型摩托车等图片。 - - * 一个复杂的因素是并非所有标签都正确。 - -* 目标是推广到新型图像。 您可以说是豹子还是樱桃，换个新图片？ - -* 在使用神经网络进行挑战之前，错误率约为 26％。 2014 年，Google 以 6.66％ 的 错误率赢得了挑战。 2015 年，错误率降至 3.46％。 - -* 这是一个庞大而深入的模型。 每个盒子都像整个神经元层一样在进行卷积运算。 这是本文： [随着卷积的发展而深入](http://www.cs.unc.edu/~wliu/papers/GoogLeNet.pdf) 。 - -![](img/e058ee738257389490f964a4ac3e11e4.png) - -* 人类 Andrej Karpathy 接受了挑战，错误率为 5.1％。 您可以在以下位置了解他的经验： [我在 ImageNet 上与 ConvNet 竞争所学到的东西。](http://karpathy.github.io/2014/09/02/what-i-learned-from-competing-against-a-convnet-on-imagenet/) - -#### 神经网络模型擅长什么？ - -* 该模型在 **方面表现出色，在**方面有很好的区分。 例如，计算机擅长区分狗的品种，而人类则不如。 当人们看到一朵花并说是一朵花时，计算机可以分辨出它是“芙蓉”还是“大丽花”。 -* 这些模型**擅长于概括**。 例如，看起来不相似的不同种类的餐食仍将正确地标记为“餐食”。 -* 当计算机出错时，错误对于原因是明智的。 例如，sl 看起来很像蛇。 - -### Google 相册搜索 - -* 能够查看像素并了解图像中的内容是一种强大的功能。 - -* Google 相册小组实现了无需标记即可搜索照片的功能。 您可以找到雕像，yoda，图纸，水等的图片，而无需为图片加标签。 - -### 街景图像 - -* 在街景图像中，您希望能够阅读所有文字。 这是更精细的视觉任务。 - -* 您需要首先能够找到图像中的文本。 经过训练的模型可以从本质上预测像素的热图，其中像素包含文本，而像素不包含文本。 训练数据是围绕文本片段绘制的多边形。 - -* 因为训练数据包含不同的字符集，所以以多种语言查找文本没有问题。 它适用于大字体和小字体； 靠近摄像机的单词和远离摄像机的单词； 用不同的颜色。 - -* 这是一种相对容易训练的模型。 这是一个卷积网络，它会尝试预测每个像素是否包含文本。 - -### 在 Google 搜索排名中的 RankBrain - -* [RankBrain](http://searchengineland.com/faq-all-about-the-new-google-rankbrain-algorithm-234440) 于 2015 年推出。它是第三重要的搜索排名信号（100 秒）。 有关更多信息，请访问： [Google 将其获利的 Web 搜索移交给 AI 机器](http://www.bloomberg.com/news/articles/2015-10-26/google-turning-its-lucrative-web-search-over-to-ai-machines) 。 - -* 搜索排名有所不同，因为您希望能够理解该模型，并且希望了解其做出某些决定的原因。 - - * 这是搜索排名小组在使用神经网络进行搜索排名时的不安。 当系统出错时，他们想了解为什么这样做。 - - * 创建了调试工具，并在模型中建立了足够的可理解性，以克服该反对意见。 - - * 通常，您不想手动调整参数。 您试图了解模型为什么要进行这种预测，并弄清楚该模型是否与训练数据有关，是否与问题不匹配？ 您可以训练一种数据分布，然后应用到另一种数据分布。 通过搜索查询的分布，您每天的变化都会有所变化。 由于事件的发生，变化总是在发生。 您必须了解自己的分布是否稳定，例如语音识别，人们发出的声音变化不大。 查询和文档内容经常更改，因此您必须确保模型是最新的。 一般而言，我们需要做得更好的工作构建工具，以了解这些神经网络内部发生的事情，找出导致预测的原因。 - -### 序列到序列模型 - -* 可以将世界上的许多问题构想为将一个序列映射到另一个序列。 Google 的 Sutskever，Vinyals 和 Le 撰写了有关该主题的突破性论文： [序列到神经网络的序列学习](http://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks.pdf) 。 - -* 他们特别关注语言翻译，以及将英语翻译成法语的问题。 翻译实际上只是将英语单词序列映射到法语单词序列。 - -* 神经网络非常擅长学习非常复杂的功能，因此该模型将学习将英语映射到法语句子的功能。 - -![](img/5d060f3fdfb3aa393921d2cd2a835ef3.png) - -* 用 EOS（句子结尾）信号一次输入一种语言的句子。 当看到一个 EOS 以另一种语言开始产生相应的句子时，模型被训练。 训练数据是指意义相同的语言句子对。 它只是试图对该功能建模。 - -* 在每个步骤中，它都会在您词汇表中的所有词汇表项上发出概率分布。 在推论时，您需要做一点搜索而不是训练。 如果您必须最大化每个单词的概率，则不一定要获得最可能的句子。 对联合概率进行搜索，直到找到最大可能的句子。 - -* 该系统在公共翻译任务上达到了最新水平。 大多数其他翻译系统都是针对问题子集的一堆手工编码或机器学习的模型，而不是完整的端到端学习系统。 - -* 该模型引起了人们的广泛关注，因为很多问题都可以映射到这种逐序列方法。 - -#### 智能回复 - -* [智能回复](http://googleresearch.blogspot.com/2015/11/computer-respond-to-this-email.html) 是如何在产品中使用逐个序列的示例。 在电话上，您希望能够快速响应电子邮件，并且打字很麻烦。 - - * 他们与 Gmail 团队合作开发了一个系统来预测邮件的可能回复。 - - * 第一步是训练一个小模型，以预测消息是否是可以简短回复的消息。 如果是这样，则会激活一个更大，计算量更大的模型，该模型将消息作为顺序输入，并尝试预测响应字的顺序。 - - * 例如，在一封询问感恩节邀请的电子邮件中，三种预计的回复是： 我们会去的; 抱歉，我们无法做到。 - - * 使用智能回复可以在收件箱应用中生成令人惊讶的回复数量。 - -#### 图片字幕 - -* 生成图像标题时，您要尝试在给定图像像素的情况下使人可能为该图像写上的标题。 - -* 取得已开发的图像模型和已开发的序列到序列模型，并将它们插入在一起。 图像模型用作输入。 不用一次查看一个英语句子，而是查看图像的像素。 - -* 经过训练可以产生字幕。 训练数据集具有由五个不同的人书写的带有五个不同标题的图像。 共写了大约 700,000 个句子，大约 100,000 至 200,000 张图像。 - -* 关于电脑上写道的一个抱着玩具熊的婴儿的照片：关闭一个抱着毛绒玩具的孩子； 一个婴儿在玩具熊旁边睡着了。 - -* 它没有人的理解水平。 错误的结果可能很有趣。 - -### 组合视觉+翻译 - -* 可以组合技术。 翻译团队使用计算机视觉编写了可识别取景器中文本的应用程序。 它翻译文本，然后将翻译后的文本叠加在图像本身上（看起来非常令人印象深刻，大约为 37:29）。 - -* 这些模型足够小，可以在设备 上运行**和** **！** - -## 周转时间及其对研究的影响 - -* 每天训练一张 GPU 卡需要 6 个星期。 - -* Google 真的很希望能够快速完成研究。 这个想法是要快速训练模型，了解哪些方法行之有效，哪些行之有效，并找出下一组要运行的实验。 - -* 模型应在数小时之内（而不是数天或数周）可训练。 它使每个进行此类研究的人都更有效率。 - -## 如何快速训练大型模型 - -### 模型并行 - -* 神经网络具有许多固有的并行性。 +## 相关文章 -* 在计算它们时，所有不同的单个神经元大多彼此独立，尤其是当您具有局部感受野时，其中一个神经元仅接受来自其下方少数神经元的输入。 +* [集成 Hive 和 HBase](http://www.cloudera.com/blog/2010/06/integrating-hive-and-hbase/) ，作者 Carl Steinbach +* [Adob​​e 选择 HBase](http://highscalability.com/blog/2010/3/16/1-billion-reasons-why-adobe-chose-hbase.html) 的十亿个理由 +* [HBase Architecture 101-预写日志](http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead-log.html)来自 Lars George +* [HBase Architecture 101-存储](http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html)和 Lars George +* [具有 Cassandra 和 HBase 的 BigTable 模型](http://horicky.blogspot.com/2010/10/bigtable-model-with-cassandra-and-hbase.html)，作者 Ricky Ho +* [新的 Facebook 聊天功能可使用 Erlang 扩展到 7000 万用户](http://highscalability.com/blog/2008/5/14/new-facebook-chat-feature-scales-to-70-million-users-using-e.html) -* 可以在不同的 GPU 卡上的不同计算机上划分工作。 只有跨越边界的数据才需要通信。 +似乎每个人都在跳 Cassandra 船：Digg，Twitter，现在甚至是 Cassandra 的原始创建者 facebook -![](img/f1b9a2f1c1b9bec8ef93891e680ea08b.png) +它不是仍然使用案例驱动的 Andy 吗？ 当订单很重要时，收件箱的最终一致性可能不是一个很好的匹配，但这是针对其他问题的。 从操作上看，这两者都不是一件容易的事，因此，利用您的 Hadoop 技术具有很大的价值。 -### 数据并行 +HBase 从 0.20.6 开始不稳定。 我认为他们对此进行了很多修补。 希望他们会尽快发布所有这些内部补丁。 -* 您要优化的模型的参数集不应位于集中服务中的一台计算机中，因此您可以拥有许多不同的模型副本，这些副本将协作以优化参数。 +这三个服务都没有停止使用 Andy 的 Cassandra。 Twitter 正在采取缓慢的方法来扩大投资。 Facebook 的投资停滞不前，Digg 看到了一些问题，但仍在继续使用 Cassandra。 每个用例都应单独考虑，但是 FUD 在合理的技术决策中没有位置。 -* 在训练过程中读取不同的随机数据（示例）。 每个副本都将获取模型中的当前参数集，读取一些有关梯度应为多少的数据，找出要对参数进行哪些调整，然后将调整发送回集中的参数服务器集 。 参数服务器将对参数进行调整。 并重复该过程。 +兰迪 -![](img/b50e7431d4f5bc620058b52961182f50.png) +卡桑德拉（Cassandra）正在遭受自己的公关策略。 随着 Facebook，Digg 和 Twitter 使用该系统，它在很大程度上得到了推广。 乍一看，这似乎是一个明智的策略，因为无数行家愚蠢到足以认为，如果某些软件对 Google / Facebook / Twitter 有用，那么对初创公司也将足够。 但是 Cassandra 和 HBase 一样，都是不成熟的软件，因此迟早会遇到麻烦。 怪罪应该提供可扩展性和容错能力的软件基础架构是自然的，尽管不公平。 更糟糕的是，Digg 并未像 Foursquare 或 Google 过去那样发布任何详细的停机后详细信息。 -* 这可以跨许多副本完成。 有时，他们在 500 台不同的机器上使用 500 个模型的副本，以便快速优化参数并处理大量数据。 +但是当您说 Twitter 正在投资 Cassandra 时（主要是用于新产品/服务），您说对了。 顺便说一句，我特别好奇地看到他们基于 Cassandra 的实时分析引擎。 希望他们意识到 Cassandra 还不够成熟，无法支持其现在的工作规模，因此他们正在以较小的规模工作，直到 Cassandra 摆脱了问题/限制（自动负载平衡，压缩，内存不足异常，不良的客户端 api） ，数据损坏，gc 风暴，缺少查询语言等）。 这些问题中的一些已经得到解决，而其他一些问题仍然被推迟。 卡桑德拉问题远远超出了 -* 该过程可以是 **异步** ，其中每个料仓都在其自己的循环中，获取参数，计算梯度并将其发送回去，而无需任何控制或同步 其他的。 不利的一面是，当梯度返回时，参数可能已从计算时移开。 事实证明，对于实际上多达 50 到 100 个副本的多种模型而言，这是可以的。 +当谈到 Digg 时，至少有三名 Cassandra 专家退出公司，因此除非另有说明，否则 Digg 中 Cassandra 的未来似乎是有问题的。 但是无论如何，这家公司注定要失败，所以让它永远走下去。 -* 该进程可以 **同步** 。 一个控制器控制所有副本。 两者似乎都起作用并且具有不同的优点和缺点（未列出）。 +最后，正如您所指出的那样，Cassandra 在 Facebook 内部的投资已经停止，因此自然而然地假设这将是该系统的遗留系统。 如果我理解正确，FB 将 Cassandra 用于 Inbox 搜索，他们将用 Messages 服务取代它，那么那里的 Cassandra 用途是什么？ -演讲的下一部分是关于 TensorFlow 的，我不会在这里讨论。 这篇文章已经太长了。 +不过，我想从现在开始的一年后，我们将更好地了解 Cassandra 在这些公司中的使用情况。 -## Q & A +弗拉基米尔：确实，HBase 0.20.6 的稳定性远不如当前的主干，我们即将发布的主干为 0.90。 Facebook 的所有工作都已经整合到了主干中-他们已经与开源社区合作了几个月。 -* **如果您不是 Google 这样的大公司，并且无法访问大数据集，该怎么办？** 从运作良好的模型开始，该模型在公共数据集上经过训练。 公共数据集通常可用。 然后对更适合您的问题的数据进行培训。 从相似且可公开获得的数据集开始时，您可能只需要为特定问题加上标签的 1,000 或 10,000 个示例。 ImageNet 是此过程工作的一个很好的例子。 +-Todd Lipcon（HBase 提交者） -* **作为工程师，您最大的错误是什么？** 不在 BigTable 中放置分布式事务。 如果要更新多个行，则必须滚动自己的事务协议。 不会输入它是因为它会使系统设计变得复杂。 回想起来，许多团队都希望拥有这种能力，并以不同程度的成功建立自己的团队。 我们应该在核心系统中实现事务。 它在内部也将是有用的。 Spanner 通过添加事务来解决此问题。 +Todd，我们都希望 0.90 会比当前版本更稳定。 -## 相关文章 +非常有趣的是，他们不需要牺牲一致性，而使用了完全一致的系统 HBase。 -* [关于 HackerNews](https://news.ycombinator.com/item?id=11298308) -* Ryan Adams 的 [AlphaGo](http://deepmind.com/alpha-go.html) 的真棒麻瓜可获得的技术解释 [机器学习音乐视频](http://www.thetalkingmachines.com/blog/) [Talking Machines](http://www.thetalkingmachines.com/) 播客的 集。 -* [TensorFlow](https://www.tensorflow.org/) -* [为什么机器学习课程的注册人数激增](http://blogs.nvidia.com/blog/2016/02/24/enrollment-in-machine-learning/) -* [使用深度卷积神经网络](http://arxiv.org/abs/1412.6564) 进行移动评估 -* [捍卫强大的 AI：语法](http://disagreeableme.blogspot.com/2012/11/in-defence-of-strong-ai-semantics-from.html) 的语义 -* [中文会议室参数](http://plato.stanford.edu/entries/chinese-room/) -* [Google：将计算机上的多个工作负荷相乘以提高机器利用率并节省资金](http://highscalability.com/blog/2013/11/13/google-multiplex-multiple-works-loads-on-computers-to-increa.html) -* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) -* [Google DeepMind：它是什么，它如何工作，您应该被吓到吗？](http://www.techworld.com/personal-tech/google-deepmind-what-is-it-how-it-works-should-you-be-scared-3615354/) -* [重塑 Google 帝国的人工大脑内部](http://www.wired.com/2014/07/google_brain/) -* [神经网络揭秘](http://lumiverse.io/series/neural-networks-demystified) -* [神经网络黑客指南](http://karpathy.github.io/neuralnets/) -* [神经网络和深度学习](http://neuralnetworksanddeeplearning.com/) -* [神经网络（常规）](http://colah.github.io/) -* [stephencwelch /神经网络解密](https://github.com/stephencwelch/Neural-Networks-Demystified) -* [加州大学伯克利分校深度学习主题课程](https://github.com/joanbruna/stat212b) -* [机器学习：2014-2015](https://www.cs.ox.ac.uk/people/nando.defreitas/machinelearning/) -* [通过深度强化学习玩 Atari](https://www.cs.toronto.edu/~vmnih/docs/dqn.pdf) -* [通过深度强化学习](https://storage.googleapis.com/deepmind-data/assets/papers/DeepMindNature14236Paper.pdf) 进行人为控制 +曼迪 -您提到了 arxiv.org，但却错过了 [gitxiv.com](http://gitxiv.com) ，这是机器学习中“真正非常快的”开发周期的下一个演变。 在 Gitxiv 上，您可以在 arxiv.org 上找到某些论文的实现。 这是您希望随论文提供的源代码。 大多数实现是由第三方完成的，但越来越多的是高质量的。 +“无数的潮人足够愚蠢” -人类如何更好地以最适合 AI（例如 BrainRank 或其他深度神经网络）消费和理解的形式来构造文本？ +这种毫无意义的谴责对辩论有何帮助？ -“从历史上看，我们可能会将'组织'与收集，清理，存储，建立索引，报告和搜索数据联系在一起。所有 Google 早期掌握的东西。完成这一任务后，Google 便迎接了下一个挑战。 +坦迪 -现在组织意味着理解。” +就这一点而言，这种“毫无意义的抨击”令人大开眼界。 我不知道您在软件行业工作了多长时间，但是*如果您从未见过有人争论“看，Twitter 使用 Ruby on Rails，他们对此很满意，那就让我们使用 现在！”* ，那么您在软件行业的时间还不够长（或者您是一个非常幸运的人）。 -我还没有看过杰夫·迪恩（Jeff Dean）的演讲-但有趣的是，几天前我在 Twitter 上发布了完全相同的内容： +令人惊讶的是，有多少工程师采用**技术，只是因为**“ X”公司（您命名）使用了该技术。 当然，没有人会毫不掩饰地承认这一点，但这是软件业务运作的方式。 仅举几个例子：EJB 被过度炒作，Ruby on Rails 被过度炒作，Linux 被过度炒作，Application Server 被过度炒作，现在轮到 NoSQL 系统了。 -“ IMO Google 的长期目标不仅是“组织世界的信息”，还在于使用#AI 来“理解”它： +**上面引用的许多技术都相当不错，但是要在开放思想和保守主义之间取得一定的平衡就不能落入陷阱（Digg？）。** -https://twitter.com/arunshroff/status/709072187773349889 +随着时间的推移，工程师获得了使用“ A”技术的经验（何时使用，什么时候不使用），赶时髦的人被砍掉了，炒作逐渐消失，一些“ A”系统消失了，而最合适的“ A”系统得以生存并 成长（达尔文主义很棒，不是吗？） -要点：约翰·亨利的故事是我小时候最喜欢的故事之一。 -尽管这场比赛对他来说是致命的，但他还是*击败了*蒸汽锤。 因此，我不确定您想以此类推论来说明什么。 +> 卡桑德拉（Cassandra）正在遭受自己的公关策略。 -总体而言，自工业革命以来，我们就发生了人机冲突，这表明发生了棘轮事件。 永远无法退回的齿轮转动。 约翰·亨利（John Henry）是其中一员。 AlphaGo 不是，但是它来了。 +卡桑德拉有公关策略吗？ -约翰·亨利死了。 那不是赢。 充其量是物理上的胜利。 他悲惨的胜利并没有阻止接下来发生的一切。 机器置换人的肌肉。 +不，我可以这样来命名，但这不是您通常在公司中找到的正式 PR。 **这是一个临时性的口碑广告，是粉丝们在 Twitter，quora 等人身上所做的新闻的无尽回响。“瞧瞧，Twitter 的新实时分析服务得到了 Cassandra 的支持。 是吗？您也应该使用 Cassandra！”** 这个星期几乎快要结束了，但是这个帖子仍然丢失了转发。 :) -好文章。 小重点。 Alpha Go 没有使用强化学习，这很重要。 强化学习是专为单人问题设计的，它在游戏等两人模型中的使用远非直截了当。 最大的问题是，如果自己一个人去，您将探索哪个领域。 因此，Alpha Go 使用（深度）学习来确定要探索的动作，如何评估情况以及何时停止评估，但是总体算法是一种博弈。 重要的是，学习不能解决所有问题，并且有明显的盲点。 其中之一就是结构很多的问题，例如是否有对手试图击败您。 还有其他情况。 \ No newline at end of file +尽管如此，这并不是 Cassandra 社区的错，因为到目前为止，这是由所有 NoSQL 系统以及 Hadoop 员工完成的。 问题是，当**与**软件项目一起使用时。 我怀疑 Twitter / Quora 是宣传软件的最佳渠道（最好的选择：技术会议），但是 Twitter 充满了狂热的粉丝，您必须忍受这一点。 :( \ No newline at end of file diff --git a/docs/54.md b/docs/54.md index 6995a72..de14261 100644 --- a/docs/54.md +++ b/docs/54.md @@ -1,152 +1,119 @@ -# Zapier 如何自动化数十亿个工作流自动化任务的旅程 +# Pinboard.in Architecture-付费玩以保持系统小巧 -> 原文： [http://highscalability.com/blog/2016/2/29/a-journey-through-how-zapier-automates-billions-of-workflow.html](http://highscalability.com/blog/2016/2/29/a-journey-through-how-zapier-automates-billions-of-workflow.html) +> 原文： [http://highscalability.com/blog/2010/12/29/pinboardin-architecture-pay-to-play-to-keep-a-system-small.html](http://highscalability.com/blog/2010/12/29/pinboardin-architecture-pay-to-play-to-keep-a-system-small.html) -*这是[的来宾](http://stackshare.io/zapier/scaling-zapier-to-automate-billions-of-tasks)[转贴了](http://stackshare.io/zapier/scaling-zapier-to-automate-billions-of-tasks) [Bryan Helmig](http://stackshare.io/bryanhelmig) ，是 [Zapier](http://stackshare.io/zapier) 的共同创始人& CTO，他可以轻松地在 Web 之间自动执行任务 应用。* +![](img/9f56768c8255ee971187862f4760c08c.png) -![](img/99150b9925c63916b576766be5cb68de.png) +如何在保持成功的同时保持足够小的系统规模，以使简单的向上扩展策略成为首选架构？ 例如， [StackOverflow](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 可以坚持使用自己喜欢的工具链，因为他们天生就对自己的增长速度抱有刹车：世界上只有这么多的程序员。 如果这对您不起作用，请考虑以下另一种自然制动策略：**收取服务费用**。 [Paul Houle](http://twitter.com/#!/simonstl/statuses/25587487132880897) 很好地总结为：*通过构建小规模盈利的服务来避免扩展问题*。 -[Zapier](http://stackshare.io/zapier) 是一项 Web 服务，可自动执行 500 多个 Web 应用程序之间的数据流，其中包括 MailChimp，Salesforce，GitHub，Trello 等。 +[Pinboard.in 的联合创始人 Maciej Ceglowski 在](http://pinboard.in/)中接受了 Leo Laporte 和 Amber MacArthur 关于他们的[的采访时提出了这一有趣的观点，我之前没有适当考虑过。 HTG3] [受电子邮件保护]](http://twit.tv/natn182) 显示。 -想象一下[建立一个工作流](https://zapier.com/multi-step-zaps/)（或我们称为“ Zap”）的操作，该操作在用户填写您的 Typeform 表单时触发，然后在您的 Google 日历上自动创建事件，发送 Slack 通知并完成以下操作 在 Google 表格电子表格中添加一行。 那是扎皮尔。 即使对于非技术用户来说，构建这样的 Zaps 也非常容易，并且可以无限地自定义。 +插板式纸机是一种精简的，付钱的书签机，可以及时替代快要淘汰的 Delicious。 作为一个自称是反社会书签网站，它*强调社交化*的速度。 Maciej 认为 Pinboard 是个人档案，您可以在其中永久保存所阅读内容的历史记录。 当 Delicious 的灭亡宣布时，如果 Pinboard 曾经是免费站点，那么他们会立即倒闭，但是成为付费站点有助于拉平他们的增长曲线。 -作为首席技术官和联合创始人，我构建了许多原始的核心系统，如今领导工程团队。 我想带您**，了解我们的堆栈**，以及我们如何构建它以及如何在今天继续改进它！ +过去经常与朋友共享链接的书签站点，但 Twitter 大部分已经接管了该角色。 但是，Twitter 只展示您的推特历史的一小部分而臭名昭著。 您真正想要的是一台大型服务器，它从可能在何处添加书签的地方都吸收了书签，而这正是 Pinboard 的作用。 -## 幕后的团队 +对于 Pinboard 来说，有几点特别令我感到震惊： -使 Zapier 滴答作响需要很多时间，因此我们在工程领域有四个不同的团队： +* 它使用基于 MySQL，向上扩展，PHP，Perl 和无框架的传统风格简单体系结构。 +* 它要求支付服务费用以支付费用并保持用户群的可管理性。 +* 它根据用户数量收费以支付费用。 +* 他们缓慢地构建了站点，并希望使其保持小巧，快速，可靠，因为这是一种更好的运行方式。 -* **前端团队**在非常强大的工作流编辑器上工作。 -* **全栈团队**是跨功能的，但专注于工作流引擎。 -* **开发人员小组**保持引擎嗡嗡作响。 -* **平台团队**（可协助质量检查）以及我们开发人员平台的入门合作伙伴。 +**网站**： [Pinboard.in](http://pinboard.in/) -总而言之，这涉及约 15 名工程师（并且还在不断增加！）。 +## 资料来源 -## 架构 +* [技术基础](http://pinboard.in/blog/63/) +* [[受电子邮件保护]](http://twit.tv/natn182) 采访 +* 个人电邮 -**我们的堆栈不会赢得任何新奇奖**-我们正在使用一些非常标准的（但很棒的）工具为 Zapier 提供动力。 更有趣的是我们使用它们来解决特定品牌问题的方式，但让我们将基础知识排除在外： +[](http://pinboard.in/blog/63/) -### 前端 +## 统计资料 -从主干**过渡到 React** 的过程中，我们感到有些困惑。 我们使用 ES6 的 [Babel](http://stackshare.io/babel) 和 [Webpack](http://stackshare.io/webpack) + [Gulp](http://stackshare.io/gulp) 来编译前端。 我们严重依赖 [CodeMirror](http://stackshare.io/codemirror) 来做一些我们需要的更复杂的输入小部件，并使用 [React](http://stackshare.io/react) + [Redux](http://stackshare.io/reduxjs) 为超级用户做很多繁重的工作 -强大的 Zap 编辑器。 +* 1,630 万个书签 +* 5200 万个标签 +* 940 万个网址 +* 989 GB 存档内容 +* 自 2010 年 7 月 8 日以来，累计停机时间不到 1 小时。 -### 后端 +## 平台 -[Python](http://stackshare.io/python) 为我们的大部分后端提供了动力。 [Django](http://stackshare.io/django) 是 HTTP 方面的首选框架。 [Celery](http://stackshare.io/celery) 是我们分布式工作流程引擎的*大型*部分。 大部分常规 API 工作都是通过具有历史意义的 [`requests`](https://github.com/kennethreitz/requests) 库（带有一堆自定义适配器和抽象）完成的。 +* 的 MySQL +* 的 PHP +* 佩尔 +* 的 Ubuntu +* 装甲运兵车 +* 狮身人面像 +* Cron 职位 +* S3 -### 数据 +## 硬件 -[MySQL](http://stackshare.io/mysql) 是我们的主要关系数据存储-您会在 MySQL 内部找到我们的用户，Zaps 等。 [Memcached](http://stackshare.io/memcached) 和 [McRouter](http://stackshare.io/mcrouter) 看起来像是无处不在的缓存层。 其他类型的数据将进入其他更有意义的数据存储中。 例如，在 [Redis](http://stackshare.io/redis) 中发现了用于计费和节流的飞行中任务计数，而 [Elasticsearch](http://stackshare.io/elasticsearch) 存储了 Zaps 的历史活动提要。 对于数据分析，我们喜欢一些 [AWS Redshift](http://stackshare.io/amazon-redshift) 。 +* 机器 1：64 GB，运行数据库主服务器，存储用户档案并运行搜索 +* 机器 2：32 GB，运行故障转移主机，抓取各种外部提要，执行后台任务 +* 机器 3：16 GB，Web 服务器和数据库从属 -### 该平台 +## 建筑 -我们的大多数平台都位于我们相当**的整体式核心 Python 代码库**中，但是有许多有趣的分支提供了专门的功能。 最好的例子可能是我们如何利用 [AWS Lambda](http://stackshare.io/aws-lambda) 运行合作伙伴/用户提供的代码来自定义应用程序行为和 API 通信。 +* 数据库的副本保留在所有三台计算机上。 +* 该网站在 16GB 计算机上运行。 数据库完全适合 RAM，页面加载时间提高了 10 倍或更多。 +* 主-主架构，带有一个额外的读取从属。 所有写入均指向一个 DB，其中包括书签，用户和标签表。 +* 第二个主机运行： + * 汇总计算，例如全局链接计数和每用户统计信息。 + * 使用 mysqldump 的每晚数据库备份。 备份以压缩格式存储到 S3。 +* Perl 脚本运行后台任务： + * 下载外部提要，为启用了存档功能的用户缓存页面，处理传入的电子邮件，生成标签云以及运行备份。 + * 选择 Perl 是因为现有的技能和 CPAN 中可用的大型支持库。 + * 诸如大多数流行书签之类的功能是由通常在每晚运行的 cron 作业生成的，但是当负载过高时将其关闭。 +* PHP 用于生成 HTML 页面： + * 不使用模板引擎。 没有使用框架。 + * APC 用于缓存 PHP 文件。 + * 不使用其他缓存。 +* [Sphinx](http://www.sphinxsearch.com/) 用于搜索引擎和全局标签页。 -### 基础设施 +## 得到教训 -由于 Zapier **在 AWS** 上运行，因此我们触手可及。 [EC2](http://stackshare.io/amazon-ec2) 和 [VPC](http://stackshare.io/amazon-vpc) 是此处的中心，尽管我们会尽可能使用 [RDS](http://stackshare.io/amazon-rds) 以及大量的自动伸缩组，以确保服务器池处于最佳状态。 顶部形状。 [Jenkins](http://stackshare.io/jenkins) ， [Terraform](http://stackshare.io/terraform) ， [Puppet](http://stackshare.io/puppet) 和 [Ansible](http://stackshare.io/ansible) 都是开发团队的日常工具。 为了监视，我们对 [Statsd](http://stackshare.io/statsd) ， [Graylog](http://stackshare.io/graylog) 和 [Sentry](http://stackshare.io/sentry) （他们*很好*）不够满意。 +* **咒语。** Pinboard 的目标是：快速，可靠和简洁。 他们认为这些是可以赢得并留住客户的素质。 当出现问题时，例如大规模增长，他们总是优先考虑，以便保持这些系统质量。 例如，他们的首要任务是防止数据丢失，这决定了更改其服务器体系结构。 因此，从概念上讲，该站点在增长的时期内是令人困惑的……如果站点可以快速可靠地保存链接，则可以。 +* **从开头**开始作为付费网站。 成为付费网站的好处是您不会急于吸引新用户，因此可以保持小规模。 当 Delicious 的灭亡宣布时，如果他们本来可以成为免费站点，那么它们将立即被关闭，但是成为付费站点有助于平稳增长。 +* **根据用户数量收费**。 Pinboard 具有独特的定价方案，旨在比具有免费帐户的服务更好地扩展。 价格基于当前用户数。 随着用户数量的增加，价格也随之上涨。 人们为使用的资源付费。 这与 Amazon 或 Google App Engine 的付款模式相似，但有很大的不同。 这是一次性费用。 每年只需多花$ 25，就可以缓存和搜索所有书签。 +* **使用无聊和淡入淡出的技术。** 这些有助于确保站点永远不会丢失数据并且非常快。 +* **经验法则**：如果您乐于尝试某些事物，那么它可能不属于生产领域。 +* **使切换尽可能简单**。 Pinboard 通过自动导入和导出到 Delicious 并支持 Delicious API 来消除采用异议。 +* **保持小巧** **更有趣**。 当您可以提供个人客户支持并直接与用户互动时，您会拥有更好的时光。 +* **比较基于每 GB RAM 或存储空间的机器成本**。 Pinboard 最初是在 Slicehost 和 Linode 上运行的，但是当以每 GB RAM 或存储的美元成本表示的费用要高得多而又没有任何可抵消的收益时，他们便转向了另一种服务。 +* **在负载**下关闭功能。 例如，如果您需要其他地方的性能，请关闭搜索。 +* **中到大型站点是最昂贵的**。 小型站点的运行成本相对较低，但是在增长曲线的某个时刻，每个新用户的边际成本都会增加。 由于必须将数据拆分到多台计算机上并且必须购买和管理这些计算机，因此成本更高。 有一个扩展成本。 一旦您接触到数百万的用户，它就会再次变得便宜。 从小型站点到中型站点的第一步是痛苦且昂贵的。 +* **在您自己的产品**上做主。 根据您所相信的人，Delicious 在 Yahoo 的不断裁员中受到了伤害，但真正的问题是 Delicious 团队不是决策者。 新功能优先于可靠性，稳定性和创新性。 当命运掌握在他人手中时，您的工作时间或辛苦时间都没有关系。 +* **Small 并不总是有效**。 新用户席卷了[，增加了超过 700 万个书签，超过了服务整个生命周期中收集的书签，并且该网站的流量是正常流量的 100 倍以上。 结果，正常的后台任务（如搜索，归档和轮询外部提要）被暂停。 弹性的策略来处理像这样的尖峰负载并不都是坏事。](http://pinboard.in/blog/156/) +* **查看异常页面加载时间，而不是中值页面加载时间来判断您的服务质量**。 即使大多数页面加载时间都可以接受，页面加载可能需要花费几秒钟的时间才能接受。 +* **使用功能可快速构建**。 Pinboard 快速建立的部分原因是，社交和发现功能因说``去别的地方''而被推迟了。 其他站点将使您可以与朋友共享链接并发现新的有趣内容，但是没有其他站点像个人存档那样运作，这就是 Pinboard 的利基市场。 +* **通过机器**隔离服务。 当 Web 服务器与其他服务共享计算机时，Web 服务器可能会受到打击。 另一个例子是，每天搜索索引器在进行完整索引重建时都会与 MySQL 争夺内存。 -## 一些粗糙的数字 +## 相关文章 -这些数字代表一个大概的最小值，以帮助读者了解 Zapier 体系结构的总体大小和尺寸： +* [Erick Schonfeld 将 Pin 大小的竞争对手 Pinboard](http://techcrunch.com/2010/12/29/delicious-exodus-pinboard/) 做成“美味的出埃及记”。 *该服务最初没有处理大量请求（高峰时每分钟处理数百个请求），但该数目增加了约十倍，达到每分钟 2500 个请求。* +* [关于 Pinboard](http://a.wholelottanothing.org/2010/12/quick-thoughts-on-pinboard.html) 的快速思考，作者：Matt Haughey +* [回到基础：Ditch Delicious，使用 Pinboard](http://techcrunch.com/2009/07/06/back-to-basics-ditch-delicious-use-pinboard/) ，作者：Michael Arrington +* [为什么 Pinboard.in 是我最喜欢的书签服务](http://www.messagingnews.com/onmessage/ben-gross/why-pinboardin-is-my-favorite-bookmarking-service)？ +* [del.icio.us，谢谢：插板，欢迎](http://redmonk.com/sogrady/2010/03/05/del-icio-us-pinboard/)，作者：Stephen O'Grady -* 每天约有超过 800 万个任务自动化 -* 每天超过约 6000 万次 API 调用 -* 每天有超过 1000 万个入站 Webhooks -* 在 [ELB](http://stackshare.io/aws-elastic-load-balancing) 之后运行 HTTP 的〜12 个 c3.2xlarge 框 -* 运行 [Celery](http://stackshare.io/celery) 的大约 100 个 m3.2xlarge 后台工作者（在轮询，挂钩，电子邮件，杂项中分隔） -* 集群中约 3 m3.medium [RabbitMQ](http://stackshare.io/rabbitmq) 节点 -* 〜4 个 r3.2xlarge [Redis](http://stackshare.io/redis) 实例-一个热，两个故障转移，一个备份/映像 -* 〜6 个 c3.xlarge McRouter 实例之后的〜12 m2.xlarge [Memcached](http://stackshare.io/memcached) 实例 -* 〜3 m3.xlarge 无数据 ElasticSearch 实例之后的〜10 m3.xlarge [ElasticSearch](http://stackshare.io/elasticsearch) 实例 -* 〜1 个 c3.2xlarge Graylog 服务器后面的〜6 m3.xlarge ElasticSearch 实例 -* 集群中约 10 个 dc1.large [Redshift](http://stackshare.io/amazon-redshift) 节点 -* 1 个主 db.m2.2xlarge [RDS MySQL](http://stackshare.io/amazon-rds) 实例，带有〜2 个以上的副本，可用于生产读取和分析 -* 少数支持 RDS MySQL 实例（下面有更多详细信息） -* ...以及大量的微服务和杂项专业服务 +为什么我不仅可以创建 Google 电子表格和表单，还可以在浏览器栏中创建该表单的书签。 +您可以随时随地从私人 Google 电子表格中获取个人书签。 -## 改善架构 +您可以轻松地扩展表单/电子表格以在不同选项卡中存储“任务”，“密码”等。 -虽然架构的主要内容保持不变-我们仅执行了几次大规模迁移-但为将产品分为两类进行了大量工作： +我缺少一个细节。 使用了什么网络服务器？ Apache，nginx 或 lighttpd？ -1. 支持重大新产品功能 -2. 为更多用户扩展应用程序 +作为用户已近一年了，可以肯定地说，Pinboard 是一项出色服务的典范，对它的功能极为有用，并且创始人在产品和技术方面都拥有正确的愿景。 -让我们深入研究每个示例，尽可能多地获取细节，而不会陷入困境！ +从扩展的角度来看，如果您知道如何使用 mysql，那么 mysql 可以很好地进行扩展，而在扩展它的那天，流量将足够高，可以雇用聪明的人来专注于扩展部分。 否则，服务固有存在错误。 -#### 大型功能，例如多步 Zaps +这三台服务器支持多少总用户和峰值并发用户？ -当我们在 Startup 周末启动 Zapier（有趣的事实：它首先被称为 Snapier！）时，我们在不到 54 个小时的时间内布置了基本架构（由大量的咖啡和更多的啤酒推动）。 总的来说，这是体面的。 **我们保持设计非常非常简单**，这在当时是正确的选择。 +安迪，您可以在这里尝试：http://techcrunch.com/2010/12/29/delicious-exodus-pinboard/ -除了**之外，*也是*简单**。 具体来说，我们将 Zaps 分为两步：将触发器与一个动作配对，一个句号。 +我不明白：“随着用户数量的增加，价格也随之上升”，这没有任何意义。 +您拥有的用户越多，就越能充分利用基础架构，那么每位用户的成本就会下降，因此您应该能够以相同的功能级别提供更便宜的服务。 您应该利用他们所谓的“规模经济”，并能够提供更好的价格。 -我们很快就意识到了错过的机会，但是过渡将非常复杂。 我们必须实现一个有向树，并支持任意数量的步骤（节点），但要对现有 Zaps（其中已有数十万个）保持 1 对 1 的支持。 我们必须做到这一点，同时还要保留对数百个独立合作伙伴 API 的支持。 - -从数据模型开始，我们在 MySQL 中构建了一个非常简单的有向树结构。 想象一下一个表，其中每行都有一个自引用`parent_id`外键，再加上一个额外的`root_id`外键以简化查询，您几乎就可以了。 我们讨论了切换到适当的图形数据库（例如 neo4j）的决定，但由于我们进行的查询种类简单且遍历较小的孤立图形（大约 2 至 50 个节点），因此决定拒绝这样做。 - -进行此工作的一个关键方面是步骤间的独立性。 每一步都必须消耗一些数据（例如，要读取哪个文件夹或要添加到哪个列表 ID），做一些 API 魔术操作并返回一些数据（例如，创建的新文件或添加到列表的新卡） ，但不知道其在工作流程中的位置。 每个独立的步骤都是愚蠢的。 - -中间是**全知的工作流引擎，该引擎通过将步骤作为任务串在一起来协调独立的 Celery 任务**-一步是由 Zap 的有根树定义的。 这个无所不知的引擎还包含所有其他优点，例如错误&重试处理，报告，日志记录，节流等。 - -即使在获得后端支持之后，我们仍然遇到另一个巨大的问题：**您如何为该对象构建 UI？** - -首先，确保团队中有一些*出色的*设计师和 Javascript 工程师。 然后，您将在嵌套的 Backbone 视图中工作一段时间，然后再进入 React。 :-)认真地说： [React](/react) 是我们正在构建的各种复杂接口的天赐之物。 - -React 的独特之处之一是性能特性对开发人员很友好，但前提是您必须弄清楚数据。 如果您不使用不可变的数据结构，则应使用一些结构共享库来进行所有突变，以及正在开发的深层`Object.freeze()`来捕捉直接尝试突变的地方。 - -构建如此复杂的 UI 面临许多挑战，其中大部分围绕测试和反馈，但要花费大量时间才能从不同的 API 中获取长尾数据，以使其优雅地适合于相同位置。 几乎每种奇怪的数据形状都必须考虑在内。 - -最后，我们的任务是让新编辑器在用户面前进行 alpha 和 beta 测试。 为此，我们同时发布了两个版本的编辑器，并使用功能开关选择了加入用户。在对结果感到满意之前，我们进行了数月的测试和调整，您可以查看 [Multi-Step Zap 发布 页](https://zapier.com/multi-step-zaps/)了解其最终结果。 - -![](img/7faac64c1acccc1743339f5d3bf58370.png) - -## 扩展应用程序 - -如果服务无法正常启动并可靠运行，那将是徒劳的。 因此，我们的大部分注意力集中在支持水平可伸缩性*和*冗余基础结构以确保可用性的应用程序设计上。 - -到目前为止，我们做出的一些更明智的决策是**，使我们对**感到满意的技术倍增，而**遇到瓶颈**时，则会分离出隔离的功能。 关键是**重用完全相同的解决方案，然后将其移动到另一个可以自由漫游 CPU 和 RAM 新鲜牧场的盒子**。 - -例如，在过去一年左右的时间里，我们注意到会话数据耗尽了主数据库的 IO 和存储量。 由于会话数据实际上是具有较弱一致性要求的键/值排列，因此我们对诸如 [Cassandra](http://stackshare.io/cassandra) 或 [Riak](http://stackshare.io/riak) （甚至是 Redis！）之类的方案进行了激烈的辩论，但最终决定站起来 具有单个会话表的 MySQL 实例。 - -作为工程师，我们的本能是找到最适合该工作的工具，但是**作为实际问题**，该工作并不能保证额外的操作复杂性。 我们知道 MySQL，它可以进行简单的键/值存储，我们的应用程序已经支持它。 畅所欲言。 - -此外，仔细设计应用程序可以使水平缩放同样简单。 长期运行的后台任务（例如我们的多步骤 Zaps）不受**轻写模式**的严格一致性要求的约束，因此**使用 MySQL 读操作是微不足道的（而且很安全！）。 仅将**复制为*主要*接触点。 即使我们偶尔在几分钟内得到了可怕的复制品延迟，但 99.9％的 Zaps 并没有改变-并且肯定不会很快改变-因此它们继续嗡嗡作响。 - -另一个好的做法是**假设最坏的**。 从一开始就设计失败。 尽管通常说起来容易做起来难，但如今实际上却很容易做到。 对于初学者：**将自动缩放组与自动替换**一起使用。 一个常见的误解是，ASG 仅用于扩展以适应波动的负载。 **错误！** **ASG + ELB 组合可以成为可靠性的骨干**，它使您可以随意杀死实例，而不必担心，因为它们会迅速被替换。 - -不知何故，我们不断地学习到，系统越简单，您的睡眠就越好。 - -## 日常 - -在本地，我们的工程师享受 [Docker](http://stackshare.io/docker) 提供的功能全面的环境。 `[docker-machine](http://stackshare.io/docker-machine)`和 [`docker-compose`](http://stackshare.io/docker-compose) 一起构成了 MySQL，Memcached，Redis，Elasticsearch 以及所有 Web 和后台工作人员的正确版本。 我们通常建议在本地运行 [`npm`](/npm) 甚至是`runserver`，因为 VirtualBox 会破坏文件监视功能。 - -规范的 [GitHub](http://stackshare.io/github) “拉动请求模型”驱动了我们的大部分工程重点项目，其中记录了日常工作，并在合并之前进行了最终代码审查。 [Hackpad](http://stackshare.io/hackpad) 包含了我们的大部分文档，其中包括大量的入门文档。 - -Zapier 的一大优势是[所有人都支持](https://zapier.com/blog/everyone-on-support/)。 每四到五周，每位工程师都会花费整整一周的支持来帮助调试和解决棘手的客户问题。 这对我们非常重要，因为它为了解客户的痛苦提供了基线（此外，您可能必须处理所运送的错误！）。 - -对于 CI 和部署，我们使用 [Jenkins](http://stackshare.io/jenkins) 对每个 PR 中的每个提交运行测试，并提供公司任何人都可以按下的“一键式部署”。 新工程师在工作的第一周点击部署按钮的情况并不少见！ - -我们在独立的 VPC 中拥有一个**完整的登台环境，以及一些非常适合测试长期拉动请求的独立 Web 框。 金丝雀部署到生产中很常见-完整记录所有错误，由 Graylog 提供。** - -## 你也可以扎皮尔！ - -开发人员可以使用 Zapier 来做一些很棒的事情。 - -除了多步骤 Zaps，我们还启用了将 [Python](https://zapier.com/help/code-python/) 和 [Javascript](https://zapier.com/help/code/) 编写为工作流中的代码步骤的功能。 无需自己托管和运行脚本-我们会处理所有这些。 我们还提供了绑定以调用网络（`requests`和`fetch`），甚至在两次运行之间存储一些状态！ - -我们的用户正在采用代码步骤来构建 [Slack](http://stackshare.io/slack) 机器人（以及游戏！），以替换一次性脚本以及更多其他内容。 我个人使用代码步骤来编写机器人和工具，以将代码&错误度量标准跟踪到电子表格中，转换格式奇怪的数据，并替换*吨* crontabs。 - -或者，如果您具有希望非开发人员能够使用的 API，那么我们也将拥有一个史诗般的[开发人员平台](https://zapier.com/developer/)。 只需定义触发器，搜索和操作，任何用户都可以将您的 API 混合到他们的工作流中，并将您的应用程序与 GitHub，Salesforce，Google Docs 等 500 多种应用程序集成。 - -而且，我们经常在招聘，因此，如果您想帮助我们帮助人们更快地工作并自动执行最繁琐的任务，请关注我们的[工作页面](https://zapier.com/jobs/)！ - -[关于 HackerNews](https://news.ycombinator.com/item?id=11082359) - -链接已断开... - -感谢抓住 Gigi！ - -为什么使用 MySQL？ Postgres 不是它的超集吗？ - -您能否评论一下如何在芹菜上实现编排？ 以我的经验，很难做到这一点，因为很多逻辑是在任务级别定义的，例如，很难在运行时修改任务的行为，因为它的定义是静态的，并且在将模块加载到工作程序时变成静态的。 \ No newline at end of file +这没有商业意义。 \ No newline at end of file diff --git a/docs/55.md b/docs/55.md index 13cd4fc..6f921b7 100644 --- a/docs/55.md +++ b/docs/55.md @@ -1,625 +1,29 @@ -# Egnyte 体系结构：构建和扩展多 PB 分布式系统的经验教训 +# BankSimple 迷你架构-使用下一代工具链 -> 原文： [http://highscalability.com/blog/2016/2/15/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2016/2/15/egnyte-architecture-lessons-learned-in-building-and-scaling.html) +> 原文： [http://highscalability.com/blog/2011/1/6/banksimple-mini-architecture-using-a-next-generation-toolcha.html](http://highscalability.com/blog/2011/1/6/banksimple-mini-architecture-using-a-next-generation-toolcha.html) -![](img/6c80e21424564200e0ef4dac300da8ff.png) +![](img/8a0930329cebce312e044432d002bf09.png) -*这是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的来宾帖子，他是在家工作的建筑师。 他和他的同事们花费大量的工作时间扩展了那里最大的分布式文件系统之一。 他在 [Egnyte](https://www.egnyte.com/) （一家企业文件同步共享和分析启动）中工作，您可以在 [@kpatelwork 与他联系 ]](https://twitter.com/kpatelwork) 。* +I know people are always interested in what others are using to build their systems. [Alex Payne](http://al3x.net/), CTO of the new startup [BankSimple](https://banksimple.com/), gives us a quick hit on their toolchain choices in this [Quora thread](http://www.quora.com/What-languages-and-frameworks-is-BankSimple-built-with/answer/Alex-Payne). BankSimple positions itself as a customer-focused alternative to online banking. You may remember Alex from the [early days of Twitter](http://venturebeat.com/2010/05/17/twitter-alex-payne-bank-simple/). Alex was always helpful to me on Twitter's programmer support list, so I really wish them well. Alex is also a bit of an outside the box thinker, which is reflected in some of their choices: -您的笔记本电脑有一个文件系统，该文件系统被数百个进程使用，它受到磁盘空间的限制，无法弹性扩展存储，如果您运行很少的 I / O 密集型进程或尝试与 100 个其他用户共享它，它会很麻烦。 现在解决这个问题，并将其放大为遍布全球的数百万付费用户使用的文件系统，您将可以通过云霄飞车扩展该系统，以满足每月的增长需求并满足 SLA 要求。 +* JVM 充当这些语言的融合平台： + * **Scala** -是编写对性能敏感的组件的理想选择，这些组件需要语言高级类型系统的安全性和可表达性。 + * **Clojure** -以更动态的语言快速原型化，同时仍提供函数式编程的优点。 + * **JRuby** -提供了许多出色的库和框架来进行前端 Web 开发，例如 Rails 和 Padrino。 +* **前端**：JavaScript 端的 MooTools。 +* **数据存储**：尝试使用 Postgres 9.0 和 Riak。 +* **平台**：Amazon EC2 -**Egnyte 是一家企业文件同步和共享创业公司**，成立于 2007 年，当时 Google 硬盘还没有诞生，而 AWS S3 的成本却很高。 我们唯一的选择是放开袖子，自己建立一个对象存储，S3 和 GCS 的超时成本变得合理，并且由于我们的存储层基于插件体系结构，因此我们现在可以插入任何便宜的存储后端。 我们已经多次重新架构了许多核心组件的架构，在本文中，我将尝试分享当前的架构是什么，我们学到的扩展规模的经验教训以及我们仍需改进的内容。 +您典型的 Web 启动并不使用 Scala，Clojure 和 JRuby。 你应该？ 如果您正在寻找一种尝试去尝试一些不同的东西，也许就是这样。 毕竟，将不同的语言用于不同的目的与将不同的数据库用于不同的目的一样有意义。 -## 平台 +## 相关文章 -* Tomcat +* [节点和小比例缩放与大比例缩放](http://al3x.net/2010/07/27/node.html)，作者：Alex Payne +* [Alex Payne 在 OSCON 2010](http://www.youtube.com/watch?v=0x9k1j9s25A) 上接受了采访。 +* T [他在**雄鹿这里**](http://www.carnegiemellontoday.com/article.asp?aid=977&page=0)停了下来 -* MySQL +哇，这对初创公司来说是不同的技术堆栈，我可以理解 JRuby，但 Scala 和 Clojure 似乎是非常随机的选择。 -* HAProxy +听到更多有关您的启动和将来的可伸缩性的信息，将非常高兴。 -* Nginx - -* Memcached - -* Apache - -* [Elasticsearch](https://www.elastic.co/) - -* Redis - -* RabbitMQ - -* CentOS - -* 人偶 - -* 新遗物 - -* AppDynamics - -* ZooKeeper - -* LDAP - -* Nagios - -* 石墨 - -* 仙人掌 - -* Apache FTP 服务器 - -* OpenTSDB - -* Google BigQuery - -* Google BigTable - -* Google Analytics - -* MixPanel - -* 表格 - -* ReactJS /主干/木偶/ jQuery / npm / nighwatch - -* Rsync - -* [PowerDNS](https://www.powerdns.com/) - -* 服装 - -* 基于 REST API 的 SOA 体系结构。 - -* Java 用于驱动核心文件系统代码 - -* Python 通常用于驱动大多数客户端代码，迁移脚本，内部脚本。 一些 python 代码仍然驻留在服务器上，但是由于我们有更多的 Java 熟悉和扩展经验的服务器开发人员，大多数 python 代码已迁移到 Java。 - -* 原生 Android / iOS 应用 - -* 适用于各种平台的桌面和服务器同步客户端 - -* GCE - -* GCS / S3 / Azure /...。 - -## 统计信息 - -* 3 个主要数据中心，包括欧洲的 1 个（由于安全港规定） - -* 200 多个 Tomcat 服务节点 - -* 由 Tomcat / nginx 提供支持的 300 多个存储节点 - -* 100 多个 MySQL 节点 - -* 50 多个 Elasticsearch 节点 - -* 20 多个 HAProxy 节点 - -* 和许多其他类型的服务节点 - -* 我们服务器和 GCS 中存储了数 PB 的数据 - -* 在 Elasticsearch 中建立索引的数 PB 数据内容 - -* 许多桌面客户端将文件与云同步 - -## 认识您 - -### 您的系统名称是什么，我们在哪里可以找到更多信息？ - -Egnyte 是启动公司的名称，核心系统有很多主要部分，例如 CFS（云文件服务器），EOS（Egnyte 对象存储），事件同步和...。您可以在中找到更多关于这些的内容 [对于技术人员](https://www.egnyte.com/blog/category/for-the-techies/) 部分，在我们的博客中。 - -### 您的系统是干什么的？ - -它推动了成千上万企业的同步和共享需求，而云使它们现有的文件系统可以被 FTP，webdav，移动，公共 api，Web UI 和...等各种端点使用。 - -### 您为什么决定构建此系统？ - -在 2007 年，企业/员工队伍开始变得更加分散，客户正在使用多个设备来访问相同的文件，并且有必要使这种体验尽可能的顺畅 - -### 您的项目经费如何？ - -这是一家自负盈亏的公司，后来我们在过去 8 年中进行了 5 轮募集，筹集了 6250 万美元的 [。](https://www.crunchbase.com/organization/egnyte#/entity) - -### 您的收入模式是什么？ - -我们没有免费用户，但是我们提供 15 天免费试用，之后客户无需支付席位即可付费。 - -### 您如何销售产品？ - -我们从 SEM / SEO 开始，但随着时间的增长，我们通过许多渠道为企业客户争取了诸如社交媒体，Biz 开发，贸易展览，SEM，SEO，入站营销和高联系销售的客户。 - -### 您从事这项工作多久了？ - -它成立于 2007 年，目前已有 8 年的历史。 - -### 您的系统多大？ 尝试感受一下系统的工作量。 - -我们存储数十亿个文件和多个 PB 的数据。 根据 New Relic，我们平均每秒观察到超过 2K 的 api 请求。 由于安全港规定和位置相近，我们将数据存储在 3 个主要数据中心中。 有关更多信息，请参见统计信息部分。 - -### 您的输入/输出带宽使用量是多少？ - -我没有确切的数字，因为它一直在增长，但是客户上个月下载了接近 1 PB 的压缩/未压缩数据。 - -### 您提供多少份文件？ 多少张图片？ 多少数据？ - -我们存储数十亿个文件和多个 PB 的数据。 我们存储各种文件，而我们的前 5 个文件扩展名是 pdf，doc / docx，xl​​s / xlsx，jpeg 和 png。 - -### 免费用户与付费用户的比例是多少？ - -我们所有的用户均为付费用户。 我们提供 15 天的免费试用期，之后将其转换或将其禁用。 - -### 在过去一个月中有多少个帐户处于活动状态？ - -我们所有的客户都是付费帐户，并且每个月几乎所有人都处于活动状态。 我们满足他们文件系统的需求，谁在家不用电？ - -## 您的系统如何设计？ - -### 您的系统的体系结构是什么？ - -我们使用基于 REST 的面向服务的体系结构，它使我们能够独立扩展每个服务。 这也使我们能够将某些后端服务移至公共云中托管。 所有服务都是无状态的，并使用数据库或我们自己的对象存储进行存储。 由于服务众多，因此很难将所有服务都绘制在一张图中。 - -10,000 英尺的 [典型请求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的外观如下 - -![](img/22e68ad1e1e96e52b90aa3482a2446fa.png) - -大约 10000 英尺的 [搜索架构](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下 - -![](img/fd48e5809512b072dec807353c9a0a0a.png) - -### 您的系统面临哪些特定的设计/架构/实施挑战？ - -最大的 架构 挑战包括：- - -1. 节俭地扩展文件存储 - -2. 扩展元数据访问 - -3. 文件与桌面客户端的实时同步 - -### 您是如何应对这些挑战的？ - -1. 对于存储，我们编写了自己的存储，现在我们使用可插拔的存储体系结构来存储到任何公共云，例如 S3，GCS，Azure...。 - -2. 为了扩展元数据，我们移至 Mysql 并开始使用分片。 在某个时候，我们暂时投入了更多的硬件来腾出空间，以便一层一层地剥去鳞屑洋葱。 - -3. 对于实时同步，我们必须更改同步算法，使其更像 Svn，客户端接收增量事件并尝试与云状态进行最终的一致同步。 - -4. 监视，监视和监视。 您无法优化无法衡量的内容。 在某个时刻，我们监控太多，无法专注于所有指标，我们不得不依靠异常检测工具，例如 New Relic，AppDynamics，OpenTSDB 和自定义报告，以使我们能够专注于从绿色变为[...] >黄色->红色。 目的是在客户通知 之前，将它们捕获为黄色， [时捕获它们。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) - -### 您的系统如何发展以应对新的扩展挑战？ - -我们已经多次重新构造了许多层。 我无法在本文中全部说明，但我将尝试列出过去 7 年中核心元数据，存储，搜索层的几次迭代。 - -1. 版本 1：在 Lucene 中搜索文件元数据，通过 NFS 安装在 DRBD Filers 中存储的文件，在 Lucene 中搜索。 阻塞点 ：Lucene 更新不是实时的，必须替换。 - -2. 版本 2：Berkeley db 中的文件元数据，通过 NFS 安装在 DRBD Filers 中的文件，在 lucene 中搜索。 阻塞点 ：我们突破了 NFS 的限制，它在左右两侧都阻塞了，必须用 http 代替。 - -3. Version3：Berkeley db 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 lucene 中搜索。 阻塞点 ：即使分片的 Berkeley DB 在压力下也阻塞，并且数据库崩溃，恢复工作数小时，必须更换它。 - -4. 版本 4：MySQL 中的文件元数据，通过 HTTP 服务的 EOS Filers 中存储的文件，在 lucene 中搜索。 阻塞点 ：公共云开始变得便宜。 - -5. 版本 5：MySQL 中的文件元数据，存储在 EOS / GCS / S3 / Azure 中并通过 HTTP 提供的文件，在 lucene 中进行搜索。 阻塞点 ：搜索开始阻塞，必须更换。 - -6. 版本 6：MySQL 中的文件元数据，通过 HTTP 服务的 EOS / GCS / S3 / Azure 中存储的文件，在 Elasticsearch 中搜索。 这是当前的体系结构，很快，其中一个可能需要另一个轮回：)。 - -### 您是否使用任何特别酷的技术或算法？ - -* 在核心服务之间进行呼叫时，我们使用 [指数退避](https://en.wikipedia.org/wiki/Exponential_backoff) 指数断路器，以避免断路器打雷。 - -* 我们在核心服务节点资源上使用公平分配分配方式来处理传入请求。 标记核心服务节点上的每个传入请求并将其分类为不同的组。 每个组都有专用的容量，如果一个客户每秒发出 1000 个请求，而另一个客户每秒发出 10 个请求，则此系统将确保第二个客户不会遇到嘈杂的邻居问题。 诀窍是，由于散列，两个客户都可能偶然巧合地落在某个节点上的同一组上，但是他们不会在所有节点上都落在同一组上，因此我们将节点名称添加为哈希值。 - -* 带有 SLA 的某些核心服务被隔离在 POD 中，这确保了一个不好的客户不会阻塞整个数据中心。 - -* 我们在桌面同步客户端代码中使用基于事件的同步，因为发生服务器事件时，它们会从服务器推送到客户端，并且客户端会在本地重播它们。 - -### 您做什么工作是与众不同的，人们可以从中学到什么？ - -专注于启动的核心功能，如果您必须构建自定义功能，则可以这样做。 有很多独特的东西，但是存储层，基于事件的同步绝对值得学习，在这里有更多详细信息。 [规范文件系统](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 - -## 您学到了什么？ - -* 您无法优化您无法测量的内容：测量所有可能的结果，然后优化系统中使用率最高为 80％的部分。 - -* 当您身材矮小的时候，请慢慢介绍技术，不要试图从中找到解决当前问题的理想工具。 编码是生命周期中最简单的部分，但是如果您最初拥有太多技术，则其维护（如部署/操作/学习曲线）将非常困难。 当您很大时，您将有足够的脂肪来划分服务，并让每个服务使用其自己的技术并进行维护。 - -* 当您是一家初创公司时，有时您需要快速采取行动，介绍您现在可以做的最好的解决方案，如果发现有牵引力，请加班对其进行重新设计。 - -* 寻找单点故障，并不懈地寻找下来。 付出额外的努力来解决使您彻夜难眠的问题，并尽快从防御模式转变为进攻模式。 - -* 在 SOA 中，如果您的服务受阻，则构建断路器以开始发送 503s。 与其惩罚每个人，不如看看是否可以公平分配资源并仅惩罚滥用用户。 - -* 在服务使用者中添加了自动修复功能，服务可能会阻塞，并且桌面客户端或其他服务之类的消费者可以进行指数补偿以释放服务器压力，并在该服务再次运行时自动修复。 - -* 始终可用：请提供服务级别的断路器和客户提供的断路器。 例如 如果通过 webdav 或 FTP 访问文件系统存在性能问题，并且需要 4 个小时进行修复，那么在这 4 个小时内，您只需在防火墙处杀死 FTP / webdav 并要求客户使用 Web ui 或其他机制即可工作。 同样，如果一个客户造成了异常而使系统窒息，则可以暂时禁用该客户或该客户的服务，并在问题解决后重新启用它。 为此，我们使用功能标志和断路器。 - -* 保持简单：每个月都有新工程师加入，因此目标是从第一周开始就提高他们的生产力，简单的架构可确保轻松上岗。 - -### 您为什么成功？ - -牵引力胜过一切。 当 EFSS 市场刚刚爆发时，我们达到了 [产品/市场适合度](https://www.linkedin.com/pulse/marc-andreessen-product-market-fit-startups-marc-andreessen) 。 具有良好执行力的时机，管理团队的财务纪律导致成功。 许多竞争对手采用了免费增值模式，并筹集了大量资金，但是从第一天开始我们就开始收费，这使我们能够专注于根据市场需求发展解决方案/团队。 专注于付费客户使我们能够交付企业级解决方案，而无需支付免费增值罚金。 - -### 您希望自己做些什么？ - -我希望当我们开始时公共云的成本不会过高。 我也希望我们从第一天开始就使用 SOA，花了一些时间才到达那里，但是现在我们就在那里。 - -### 您不会更改什么？ - -目前，我不会替换 MySQL / EOS，因为它允许我们从防御定位转向进攻定位。 我不能在两年后发表评论，我会有相同的想法，我们可能会更改或扩大其中一些想法。 当您遇到下一个增长突增时，架构会发生变化。 - -## 您应该做多少前期设计？ - -很好的问题。 答案是“取决于”， - -* 如果您要设计诸如核心存储层或核心元数据层之类的东西，那么再多花 2 周的时间对设计就不会造成太大的影响。 当我们在核心元数据层上从 Berkeley DB 迁移到 MySQL 时，我承受着很大的压力，我曾想过要走捷径，当我通过首席技术官运行时，他建议花一些时间并“做正确的事”。 作为回顾，这是一个极好的决定。 - -* 对于公共 API，最好做一个不错的前端设计，因为您没有第二次机会对其进行更改，并且必须将其维护 4-5 年。 - -* 但是，如果您要为内部服务设计一些东西并将其迁移到新架构将不会花费一年，那么我建议您进行非常少的前端设计，并快速构建版本并随着使用量的增加对其进行迭代。 - -## 您如何考虑将来更改架构？ - -* 在一周中进行部署（我们快到了） - -* 将更多公共云用于任何新服务，并将更多服务迁移到公共云。 - -* 将其余的源代码从 svn 移至 git - -* 使当前的开发环境尽可能接近生产环境（可以使用 docker 或…）。 - -* 自动化架构管理 - -* 添加更多性能基准测试 - -* 建立持续的交付渠道，以便我们可以将部署增加为每周或每天，而不是每两周一次。 - -* 通过重新构建从某些增长最快的表中删除联接。 - -* 为 Mysql 分片添加自动平衡器，因此我不必担心偶尔出现的热点。 - -* 将某些脂肪服务分成颗粒状 - -* 使用内存缓存代理 - -## 您的团队如何设置？ - -### 您的团队中有多少人？ - -大约有 100 名工程师（devops / ops / qa / developers /…），其余是销售，市场营销，支持和人力资源。 - -### 他们在哪里？ - -最初是分布相当分散的工程团队，但现在主要吸引人是孟买的 [波兹南](https://en.wikipedia.org/wiki/Pozna%C5%84) 。 一些像我这样的远程员工 和其他一些员工在家工作。 - -### 谁扮演什么角色？ - -这是一个很大的团队，我们有产品经理，UX 团队，开发人员，Scrum 团队，架构师，工程师扮演各种角色。 最初，工程团队很平坦，每个人都会向工程副总裁报告，但现在我们在两者之间增加了一层管理。 - -### 您是否有特定的管理理念？ - -如果您开发某些产品，那么您拥有该产品的生命周期，这意味着您将与 QA，devops 一起确保其测试/部署。 投入生产时，您可以使用各种内部工具（例如 New Relic / Nagios）对其进行监视，如果存在回归，则可以对其进行修复。 - -### 如果您有分散的团队，该如何工作？ - -自治，1-1 交流，黑客马拉松使他们具有挑战性，他们会受到激励。 - -### 您的开发环境是什么？ - -* 适用于服务器团队的 Ubuntu - -* UI 团队使用 Windows / mac 并连接到用于 REST API 服务器的本地 Ubuntu VM 或连接到共享的 QA 实例 - -* Eclipse /想法 - -* 适用于构建的 - -* Maven - -* Git / SVN - -* 詹金斯 - -* ReviewBoard / Sonar - -* JIRA - -* Google 文档 - -* Jabber / Slack / Hangouts / Skype - -### 您的开发过程是什么？ - -我们在服务器团队中使用 Scrum，并且每两周发布一次。 长期功能开发人员/团队在沙盒上工作，完成后通过单元测试/硒/手动 QA 对它进行测试，然后合并到主干以捕获 2 周的发布流程。 我们吃了自己的狗粮，代码在发布前 1 周发布到了 UAT（所有员工使用的 egnyte.egnyte.com），我们发现了自动测试未发现的任何意外情况。 我们每个星期五晚上进行生产部署， [每天监视新文物，并报告任何异常的异常报告](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 。 我们正在将部署更改为即将在一周中完成。 - -### 您有什么可以做的不同还是感到惊讶？ - -许多工程师在家工作，令人惊讶的是，有了自主权，许多远程员工像总部员工一样富有生产力和积极性。 - -## 您使用什么基础架构？ - -### 您使用哪种语言来开发系统？ - -大多数是 Java / Python - -### 您有多少台服务器？ - -最后，我知道我们有 700 多个。 100 多个 MySQL 服务器，50 多个 Elasticsearch，200 多个 tomcat 服务节点，300 多个本地存储节点，20 多个 HAProxy 节点和缓存文件管理器，nginx，python 服务器以及其他各种节点。 - -### 如何将功能分配给服务器？ - -我们使用面向服务的体系结构，并根据服务类型分配服务器。 一些顶级服务是： - -* 元数据 - -* 储存空间 - -* 对象服务 - -* Web UI - -* 索引 - -* EventSync - -* 搜索 - -* 审核 - -* 快照/数据监视器 - -* 内容智能 - -* 实时事件传递 - -* 文本提取 - -* 集成 - -* 缩略图生成 - -* 防病毒软件 - -* 垃圾邮件 - -* 预览版 - -* rsync - -* API 网关 - -* 结算 - -* 支持 - -* 销售 - -* 等等。 - -### 如何配置服务器？ - -大多数服务都是伪造的，并在 VM 上运行，我们仅针对 MySQL，memcached，Metadata 服务器，索引之类的少数事物进行物理运行，但是除了数据库/缓存/存储节点之外，大多数服务都会转换为 VM。 我们使用第三方根据模板来配置服务器，并将其放入数据中心，以供使用。 - -### 您使用什么操作系统？ - -CentOS7 - -### 您使用哪个 Web 服务器？ - -Nginx，Apache。 在一些旧的流程中使用了 Apache，但随着时间的流逝，它将被弃用。 - -### 您使用哪个数据库？ - -MySQL。 我们过去曾使用过其他数据库，例如 Berkeley DB，Lucene，Cassandra，但由于开发人员/操作人员的熟悉程度和可伸缩性，我们将所有数据库都超时迁移到了 MySQL。 有关更多信息，请参见 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 - -### 您是否使用反向代理？ - -是 Nginx 和 HAProxy - -### 您是否并置，使用网格服务，使用托管服务等？ - -我们搭配。 - -### 您的存储策略是什么？ - -我们首先创建自己的服务器，然后在机器中打包尽可能多的硬盘驱动器，我们过去将它们称为 DRBD Filers。 我们这样做是因为 AWS 成本过高。 我们已经评估了 [GlusterFS](https://www.gluster.org/) ，但当时它无法扩展以满足我们的需求，因此我们构建了自己的。 加班 S3 变得便宜了，GCS / Azure 诞生了，我们将存储层设计为可插入的，因此现在客户可以决定要使用哪个存储引擎（例如，Egnyte，S3，GCS，Azure 等）。 - -### 您如何增加产能？ - -我们进行能力计划会议，并根据监控指标中的关键指标并预定一些额外的能力得出了一些指标。 现在，某些服务已启用云服务，我们只需单击一下按钮即可提供更多服务。 - -### 您是否使用存储服务？ - -是 Egnyte，S3，GCS，Azure 和 - -### 您如何处理会话管理？ - -我们多次重写了体系结构，目前 99％的服务是无状态的。 只有服务 Web UI 的服务使用会话，我们在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性会话，但最终我的计划是使它也变得无状态 。 - -### 您的数据库是如何设计的？ 主从？ 碎片？ 其他？ - -我们几乎对所有具有自动故障转移功能的数据库都使用了 Master-Master 复制，但是在一些突变程度很大的数据库上的切换是手动完成的，我们遇到了一些问题，其中由于复制滞后，自动切换会导致应用程序数据不一致，我们 需要重新架构一些核心文件系统逻辑来解决此问题，我们最终将完成此工作。 下面是有关处理数据库升级的问题，详细回答了有关数据库体系结构的更多详细信息。 - -### 您如何处理负载平衡？ - -我们根据客户使用 DNS 访问系统的 IP 进行地理平衡，并在数据中心内使用 HAProxy 将其路由到相应的 POD，并在内部 POD 中再次使用 HAProxy 路由他们 - -### 您使用哪个 Web 框架/ AJAX 库？ - -我们已经多次更改了 UI，这是一直在变化的一件事。 过去我们曾经使用过 ExtJS，YUI，JQuery，而没有使用过。 最新的迭代基于 ReactJS / Backbone / Marionette 。 - -### 您使用哪种实时消息框架？ - -我们使用 [大气](https://github.com/Atmosphere/atmosphere) ，但最终我们将其替换为 NodeJS - -### 您使用哪个分布式作业管理系统？ - -为此，我们使用 RabbitMQ 和基于 Java / python 的消费者服务。 - -### 您的网站是否有标准 API？ 如果是这样，您将如何实施？ - -我们的 API 分为 3 种类型：- - -1. 公共 API： 这是我们向第三方应用程序开发人员和集成团队以及我们的移动应用程序公开的 api。 我们会按照正确的弃用工作流程弃用/升级 api 签名，并且更改始终向后兼容。 我们使用 Mashery 作为网关，API 记录在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) - -2. 适用于我们客户的 API： 此 API 对我们客户而言是内部的，如果我们以外的人使用此 api，则我们不保证向后兼容。 - -3. 服务之间的内部受保护的 API ：这是服务在我们的数据中心内部用于彼此通信的 API，无法从外部防火墙调用。 - -### 您的对象和内容缓存策略是什么？ - -我们存储 PB 的数据，但无法缓存所有数据，但是如果客户在给定的 15 天时间内拥有 5000 万个文件，则他可能只使用其中的 100 万个文件。 我们有基于 tomcat / nginx / local 文件系统的缓存文件管理器节点，它以 LRU 方式运行。 我们可以弹性增加减少缓存文件服务器的数量。 我们最大的问题之一是上传速度，如何从世界任何地方尽可能快地将数据上传到 Egnyte，为此，我们构建了特殊的 Network pops。 [为 Egnyte 客户加速数据访问](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) - -Memcached 用于缓存元数据，我们使用单独的 memcached 池来缓存长期存在的静态数据和文件系统元数据。 核心文件系统元数据非常庞大，不适合当前的内存缓存节点，并且会逐出最近使用的其他类型的数据。 为防止这种情况，我们使用 2 种池，应用程序代码决定在哪里查找哪种数据。 我们允许在文件系统 Memcached 缓存中逐出，并在其他种类的 Memcached 池中争取零逐出。 - -### 您的客户端缓存策略是什么？ - -对于我们的 Web ui，我们使用 PageSpeed 进行资源优化，缓存，并使用 requireJS 和其他各种方式仅下载所需的模块。 我们的 Mobile 和 Desktop 客户端丰富使用本地文件系统作为缓存。 - -### 您使用哪些第三方服务来帮助您构建系统？ - -Google BigQuery，New Relic，AppDynamics，MixPanel，Flurry，Tableau 是我们使用的一些分析服务，但大多数核心组件均由我们构建。 - -## 您如何管理系统？ - -### 如何检查全局可用性并模拟最终用户性能？ - -我们使用不同 AWS 区域中的节点来一致地测试带宽性能。 我们还使用内部 haproxy 报告来绘制客户观察到的上载/下载速度，并主动寻找它们，并使用网络弹出消息和其他策略来加速数据包。 - -![](img/6ffa16c86d1956a9ff0be037d6021022.png) - -### 您如何健康检查服务器和网络？ - -使用 Nagios 监视器和 New Relic 以及一些内部主动异常分析。 有关更多详细信息，请参见此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) - -### 如何绘制网络和服务器统计数据以及趋势图？ - -我们使用石墨，仙人掌，Nagios 和 New Relic，AppDynamics。 - -![](img/d7afc2042d53ba5302472ee5be116c5f.png) - -![](img/293ca1407b4f34397f578ec21c96afd2.png) - -### 您如何测试系统？ - -硒，Junit，鼻子，睡表和手动测试。 - -### 您如何分析效果？ - -New Relic，AppDynamics 用于监视生产 tomcat 节点的性能。 我们使用石墨/ nagios /内部工具和其他工具来监视系统其他部分的性能。 有关此问题的更多详细信息，请参见此博客文章 [分布式系统中的调试性能问题](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) - -### 您如何处理安全性？ - -专用安全团队在每个版本之前都会运行自动化的安全基准测试。 连续自动化笔测试已在生产中运行。 我们还使用漏洞赏金计划并与 Whitehat 测试公司合作。 一些客户使用第三方进行自己的安全性测试。 - -### 您如何处理客户支持？ - -我们有专门的 24X7 分布式客户成功团队，我们使用 Zendesk 和 JIRA - -### 您是否实施网络分析？ - -我们使用 Google Analytics（分析），Mixpanel，Flurry 来衡量功能使用情况 - -### 您是否进行 A / B 测试？ - -是的，我们使用功能标记进行 A / B 测试。 有关更多信息，请参见 [在 Egnyte 使用功能标志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) - -### 您要运行多少个数据中心？ - -3 个主要数据中心，其中一个在欧洲（由于安全港规定） ，网络遍布世界各地。 - -### 您的系统如何部署在数据中心中？ - -Puppet 用于部署大多数新代码。 我们仍在重写架构中最后的几篇文章，这些文章目前都是使用 Shell 脚本部署的。 - -### 您使用哪种防火墙产品？ - -我们混合使用了瞻博网络 SRX 和 Fortigate 防火墙。 - -### 您使用哪个 DNS 服务？ - -PowerDNS - -### 您使用哪些路由器？ - -思科 - -### 您使用哪些开关？ - -Arista - -### 您使用哪个电子邮件系统？ - -我们使用自己的 SMTP 服务器来处理出站电子邮件，对于一些内部工具，我们使用 SendGrid，对于入站电子邮件，我们使用 GMail。 - -### 如何备份和还原系统？ - -对于 MySQL，我们使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，对于 Elasticsearch，该数据被复制 3 次，并且我们还使用 ElasticSearch GCS 备份插件将数据备份到 GCS。 对于客户文件，我们将其复制 3 次。 如果存储 Filer 无法恢复，我们将丢弃它，添加一个新 Filer 并再次复制副本。 对于某些客户，我们还会将其数据复制到他们选择的提供者。 对于使用 S3，Azure 或 GCS 作为可插拔存储层的客户，它将确保复制以防止数据丢失。 - -### 如何进行软件和硬件升级？ - -大多数节点是无状态的，并且有状态组件具有主动-主动故障转移。 通过将节点从池中取出并进行升级并将其放回池中来处理升级。 - -### 您如何处理升级时数据库架构的重大更改？ - -不同的服务使用不同类型的数据库，并且它们以不同的方式升级。 在 10000 英尺处，它们如下图所示： - -![](img/1de3f24a7fc5621b61d6e4e7ca1de358.png) - -1. EOS db 存储对象元数据并且增长非常快，它经过分片，并且我们将继续添加更多此类数据。 - -2. MDB 的增长速度更快，经过了分片，并且我们会继续增加更多。 - -3. DC_central 是 dns 数据库，并且保持相当静态。 我们运行了许多此副本以实现可伸缩性。 - -4. Pod_central 具有快速变异的数据，但每个表的增长量不超过 2000 万行。 我们运行了许多此副本以实现可伸缩性。 - -* 每个数据库架构始终是向前和向后兼容的，即我们绝不会在同一发行版中删除列和代码，我们首先在发行版 1 中部署停止使用该列的代码，而在发行版 2 中两周后，我们删除该列。 - -* 非分片数据库每 2 周更新一次。 它们是存储各种功能驱动表的表。 我们目前正在使用脚本升级它们，但现在已更改为使用 [Sqitch](http://sqitch.org/) - -* 使用自动脚本进行分片 db 新列更改 - -* 分片数据库迁移是一件痛苦的事情，因为我们有 7000 多个分片并且还在不断增长，您无法在 1 小时的升级窗口中完成。 方法是： - - * 实时代码根据需要迁移行。 这意味着迁移可能会持续数年。 - - * 使用功能标记迁移，您同时拥有新旧代码，并且在后台迁移客户，然后翻转标记以将其切换到新代码路径而无需停机，更多的是 [ [此处](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此处](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) - - * 当我们从 lucene 迁移到 ElasticSearch 时，除了重新索引所有内容外，我们别无选择，我们使用 [功能标记](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 进行了检索，大约花了 3 -4 个月完成。 - -* 模式一致性检查器报告可确保升级后所有数据中心中的所有模式均相同。 - -### 您是否有单独的运营团队来管理您的网站？ - -是的，我们有一个专门的 devops 团队和一个 IT / Ops 团队，负责监视和管理系统。 - -## 其他 - -### 您欣赏谁？ - -AWS ：他们的创新步伐令人赞叹。 - -Google ：他们的工具，例如 BigQuery，Analytics（分析）都很棒。 - -Elasticsearch ：其余 api 的简单性和架构很棒。 - -MySQL： 即可。 - -Eclipse / Jenkins ：插件架构很好。 - -### 您是否模仿了其他人的公司/方法？ - -我们是 [http://highscalability.com/](http://highscalability.com/) 的常规读者，许多设计都受到它的启发。 - -* POD 架构的灵感来自 Tumblr 的 Cell 架构，虽然不完全匹配，但是隔离故障的概念是相同的。 - -* 受 Facebook 启发的架构在 12 小时后会在内存缓存和刷新键中产生抖动。 - -* 受 [http://highscalability.com/上一些文章的启发，将](http://highscalability.com/) [指纹添加到每个数据库查询](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) - -我们正在招聘，请在 [职位页面](http://www.egnyte.com/jobs/engineering.html) 中查看我们，然后在 [与我们联系 [电子邮件保护的]](/cdn-cgi/l/email-protection) 。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=11104555) \ No newline at end of file +至少在 IE 中，没有任何链接在其 Beta 网站上起作用。 希望银行应用程序会做得更好;-) \ No newline at end of file diff --git a/docs/56.md b/docs/56.md index 440df88..aca3caf 100644 --- a/docs/56.md +++ b/docs/56.md @@ -1,243 +1,73 @@ -# 如何使用微服务建立财产管理系统集成 +# Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表 -> 原文： [http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html](http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html) +> 原文： [http://highscalability.com/blog/2011/1/10/riaks-bitcask-a-log-structured-hash-table-for-fast-keyvalue.html](http://highscalability.com/blog/2011/1/10/riaks-bitcask-a-log-structured-hash-table-for-fast-keyvalue.html) -![](img/3331efa5e2d1a2cad2f4cfa4f1aeb70f.png) +![](img/a2a15972237545b2b84c06482305506b.png) -*This is a guest post by Rafael Neves, Head of Enterprise Architecture at [ALICE](http://info.aliceapp.com), a NY-based hospitality technology startup. While the domain is **Property Management, it's also a good microservices intro.* 在零散的款待系统世界中，集成是必不可少的。 您的系统将需要与来自不同提供程序的不同系统进行交互，每个提供程序都提供自己的应用程序接口（API）。 不仅如此，而且当您与更多的酒店客户整合时，将需要更多的实例来连接和管理此连接。 物业管理系统（PMS）是任何酒店的核心系统，随着行业变得越来越紧密联系，集成至关重要。 +如果从头开始，您将如何实现键值存储系统？ Basho 使用 [Bitcask](http://downloads.basho.com/papers/bitcask-intro.pdf) （他们的 Riak 的新后端）决定采用的方法是一种有趣的组合，使用 RAM 存储指向值的文件指针的哈希映射和用于高效写入的日志结构文件系统。 在这次出色的 [Changelog 采访](http://thechangelog.com/post/1525527959/episode-0-4-0-riak-revisited-with-andy-gross-mark-philli)中，来自 Basho 的一些人更详细地描述了 Bitcask。 -为了在酒店业提供软件解决方案，您肯定需要与 PMS 提供者建立 2 路集成。 挑战在于大规模建立和管理这些连接，并在多个酒店中使用多个 PMS 实例。 您可以采用几种方法来实现这些集成。 在这里，我提出一种简单的架构设计来构建集成基础，随着您的成长，该基础将增加 ROI。 这种方法是微服务的使用。 +基本的木桶： -## 什么是微服务？ +* 密钥存储在内存中以便快速查找。 所有密钥必须适合 RAM。 +* 写操作仅是追加操作，这意味着写操作严格是顺序执行的，不需要查找。 写是直写的。 每次更新值时，都会附加磁盘上的数据文件，并使用文件指针更新内存中的索引。 +* O（1）随机磁盘搜寻可满足读取查询的需求。 如果所有密钥都适合内存，则延迟是非常可预测的，因为不会在文件中四处寻找。 +* 对于读取，将使用内核中的文件系统缓存，而不是在 Riak 中编写复杂的缓存方案。 +* 旧值将被压缩或“合并”以释放空间。 Bitcask 具有[窗口合并](http://blog.basho.com/2011/01/05/riak-0.14-released/)： *Bitcask 对所有非活动文件执行定期合并，以压缩旧版本存储数据占用的空间。 在某些情况下，这可能会导致进行合并的 Riak 节点上的某些内存和 CPU 峰值。 为此，我们添加了指定 Bitcask 何时执行合并的功能。* +* 通过 Bitcask 上方的[软件层，使用](http://wiki.basho.com/An-Introduction-to-Riak.html)[向量时钟](http://blog.basho.com/2010/01/29/why-vector-clocks-are-easy/)实现获取和设置并发。 +* 值索引的键存在于内存中以及提示文件中的文件系统中。 数据文件合并时生成提示文件。 重新启动时，仅需要为非合并文件重建索引，该文件应占数据的一小部分。 -企业软件设计的思想领导者 Martin Fowler 提供了微服务的全面定义[：](http://martinfowler.com/articles/microservices.html) +Eric Brewer（CAP 定理）通过考虑您是否有能力将所有密钥保存在内存中（这在现代系统中很有可能），使 Bitcask 产生了想法，您可以相对容易地设计和实现存储系统。 [提交日志](http://wiki.apache.org/cassandra/Durability)可用作数据库本身，提供了原子性和持久性。 只需写入一次即可保留数据。 单独写入数据文件，不需要提交日志。 -> 在过去的几年中，出现了“微服务体系结构”一词，用于描述将软件应用程序设计为可独立部署的服务套件的特定方式。 尽管没有对此架构风格的精确定义，但围绕业务能力，自动部署，端点中的智能以及对语言和数据的分散控制，组织周围存在某些共同特征。 +值更新后，首先将其附加到磁盘提交日志中。 然后，将键映射到磁盘指针的内存中哈希表将更新为指向文件和文件中记录的偏移量。 因此，读取仅需要一个文件 I / O。 哈希键可找到文件指针，您只需查找偏移量并读取该值。 对于写入，它只是文件的追加。 很漂亮 在纯内存数据库和虚拟存储层支持的基于磁盘的数据存储之间，这是一个很好的折衷方案。 -本质上，微服务是很小的软件组件，专注于真正做好一件事情。 不必编写一个大型的整体应用程序，而是可以使用微服务将其分解，每个微服务在给定的域中管理一个集中的功能。 +一些潜在的问题： -因此，它们是自治的，彼此独立执行。 因此，对一项服务的更改不应要求对另一项服务的更改。 随着您的成长和进行更改，您无需担心会影响其他微服务。 +* 如果您怀疑密钥的数量将超过 RAM，那么将工作集保留在内存中的体系结构将是一个更好的选择。 +* 它比纯内存数据库要慢。 +* 问题通常在垃圾回收阶段作为资源高峰而出现，同时回收用于删除值的空间。 Bitcask 希望通过将垃圾收集的调度安排到特定时期来降低成本，尽管在拥有国际用户的 24x7 物业中，这可能还不够。 +* 在每次写入时进行同步可能会有些痛苦。 如果将写入缓冲并同步复制到备份节点以提高可用性，则可以提高写入吞吐量。 +* 我不相信操作系统缓存。 操作系统缓存不知道您的访问模式。 自定义缓存可能会带来复杂性，但是很难相信当出现问题时它的性能不会更好或无法调整。 Basho 似乎对这种方法感到满意，但仍然让我感到不安。 如果流量具有均匀分布或类似 pareto 的分布，会发生什么？ 对您的应用进行基准测试！ -微服务是： +## **相关文章** -* 小 -* 专注于 -* 松耦合 -* 高凝聚力 +* [变更日志采访](http://thechangelog.com/post/1525527959/episode-0-4-0-riak-revisited-with-andy-gross-mark-philli)，其中描述了 [Bitcask](http://downloads.basho.com/papers/bitcask-intro.pdf) 。 +* [Bitcask-Justin Sheehy 和 David Smith 编写的用于快速键/值数据的对数结构哈希表](http://downloads.basho.com/papers/bitcask-intro.pdf)，灵感来自 Eric Brewer。 +* [Redis Diskstore](http://groups.google.com/group/redis-db/browse_thread/thread/d444bc786689bde9) 。 这是 Redis 的操作方式。 +* [RethinkDB 内部：缓存体系结构](http://www.rethinkdb.com/blog/2011/01/rethinkdb-internals-the-caching-architecture/#)。 这是 RethingDB 的工作方式。 +* [Bitcask Rocks](http://pl.atyp.us/wordpress/?p=2868) ，作者：Jeff Darcy。 *至少对于这些简单测试而言，Bitcask 的性能与广告中所宣传的相同。 如果不进行调整，则读写操作似乎都在摊销大量操作的查找成本。* +* [克服 I / O 瓶颈：J Ousterhout 的日志结构文件系统](http://www.google.com/url?sa=t&source=web&cd=3&ved=0CCoQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.37.9531%26rep%3Drep1%26type%3Dpdf&ei=n8ckTcS1O46WsgObqPCDAg&usg=AFQjCNFxzphJrEx281Sm9nZuA7iQR1XpBg&sig2=16OP4cTwBPgjjUp1B5Qx4Q)案例 +* [Riak SmartMachine 基准测试：技术细节](http://joyeur.com/2010/10/31/riak-smartmachine-benchmark-the-technical-details/) +* [P O'Neil 的日志结构化合并树（LSM-Tree）](http://www.google.com/url?sa=t&source=web&cd=2&ved=0CB0QFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.44.2782%26rep%3Drep1%26type%3Dpdf&ei=780kTdPyGI7ksQPAvMzNAQ&usg=AFQjCNGGoN9IFTLShcv2HbL0RVQdElfxow&sig2=kO9xiGo1mgbywgsRpPi4Kg) +* [该死的凉爽算法：日志结构化存储](http://blog.notdot.net/2009/12/Damn-Cool-Algorithms-Log-structured-storage)，作者：Nick Johnson +* [HBase Architecture 101-Lars George 的预写日志](http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead-log.html) +* [Cassandra Wiki 耐久性条目](http://wiki.apache.org/cassandra/Durability) +* [Alfred-是 node.js 的快速进程内键值存储。](http://pgte.github.com/alfred/) *Alfred 将数据存储在仅附加文件*中。 +* [Bigtable：结构化数据的分布式存储系统](http://osdi2006.blogspot.com/2006/10/paper-bigtable-distributed-storage.html) -## 为什么微服务功能强大 +“如果您怀疑您将拥有比 RAM 更多的密钥，那么在内存中保留工作集的体系结构将是一个更好的选择。” -微服务架构提供了很多好处。 主要优点包括： +是的，DB / Java（http://www.oracle.com/technetwork/database/berkeleydb/overview/index-093405.html）几乎是开箱即用的，并且与 Bitcask 具有相对相似的整体方法。 这些年来，有很多类似系统的例子，Basho 选择了基础知识，并根据自己的需求构建了一些特定的东西。 可以在 Gray 和 Reuter 的“事务处理：概念和技术”中找到许多理论（例如，扎根于 System R（http://zh.wikipedia.org/wiki/IBM_System_R））。 -### 可扩展性 +“在每次写入时进行同步可能会有些痛苦。如果对写入进行缓冲并且将数据同步复制到备份节点以实现高可用性，则可以提高写入吞吐量。” -* 您的单个系统将与具有不同属性的多个 PMS 实例集成。 从规模上讲，当与 1000 个属性进行集成时，即使它们正在运行来自同一供应商的相同 PMS 系统，您也需要显式管理不同的 1000 个集成。 为了增加复杂性，这些实例可以来自不同的提供程序。 -* 随着您添加许多 PMS 实例和属性，它可以优雅地扩展。 如果您使用的是整体应用程序，则必须将所有内容扩展为一个大块。 在流量高峰期间，可能很难理解性能瓶颈在哪里，而对于微服务而言，透明度要高得多。 -* 当您拥有微服务时，很清楚哪些服务存在性能问题，您可以轻松调整其容量（底层硬件），而不必增加运行正常流量负载的其他服务的容量。 +好吧，如果您真正是同步的并且不想延迟等待写操作的人，则缓冲的好处有限。 实际上，许多系统都会引入延迟，以便可以进行缓冲。 同步复制到备份节点会带来一系列问题，需要适当调整网络堆栈。 您还面临着处理副本丢失的所有麻烦。 我相信，通常 Riak 会在存储层之外处理该问题。 -### 弹性 +“将旧值压缩或“合并”以释放空间。”-有些人可能会说这是 DB 语言中的检查点。 -* 旅馆的 PMS 实例可能已关闭或出现性能问题，这不会影响系统的性能或正常运行时间。 -* 您可以实现任意数量的微服务。 部署的次数越多，容错和对更改的管理就越多。 +“我不相信操作系统缓存。OS 缓存不知道您的访问模式。自定义缓存可能会带来复杂性，但是很难相信它会在出现问题时表现不佳或变得更可调。” -### 技术堆栈独立性 +自定义缓存只能在编写或更新之前知道其开发人员所看到的访问模式。 换一种说法，任何高速缓存的性能仅与到目前为止公开和调整的访问模式集一样好。 随着时间的流逝，操作系统缓存已暴露于许多不同的访问模式，并且在大多数情况下都表现出合理的平衡。 我确定在特定情况下自定义缓存会更好，但是 Riak 工作负载是否足够具体/可预测？ 可能不是现在，也许以后。 -* 您可以具有多个技术堆栈； 每个服务都将拥有最适合的技术堆栈。 您的访客配置文件可能在关系数据库中，而他们的请求可能在 NoSQL 数据库中。 -* 对特定技术栈没有长期的承诺； 毕竟，您可以拥有多个。 +我忘了说了，电池保护的写缓存之类的东西是使磁盘同步更便宜的另一种方法。 -### 添加，更改或终止功能&重构 [ +在[文章](http://www.varnish-cache.org/trac/wiki/ArchitectNotes)中比较了 Squid 和 Varnish 的体系结构，作者声称自定义内存管理会因分页而影响性能。 考虑到这一点，他建议您最好将其留给操作系统。 -* 微服务非常小（通常只有几百行代码）。 -* 由于代码具有内聚性，因此更容易理解：它可以做一件事。 -* 对其所做的更改不会直接影响其他服务。 -* 删除整个微服务更容易，并且不会对整个系统造成风险 +这些论点对这里讨论的情况也无效吗？ -### 部署方式 +@Hugh Redis 开发人员现在正在考虑他先前决定绕过操作系统页面缓存的决定-https://groups.google.com/d/topic/redis-db/1ES8eGaJvek/discussion -* 酒店希望提供卓越的服务。 如果您的系统已关闭或未提供其所有功能（例如，不将来宾登机请求推送到您的 PMS 或从中读取更新），他们将无法交付它。 -* 回滚也更容易。 如果出了问题，回滚一个带有自己数据库的微服务要比回滚一个单个数据库的整个系统要容易。 -* 部署单片应用程序的下一版本时，总是很麻烦：即使您仅添加了一个功能，也必须立即部署整个应用程序。 一起部署所有内容都是有风险的。 ， +去年，我曾提醒他有关那篇不错的 Varnish 文章-请在此处查看评论＃29 http://antirez.com/post/redis-virtual-memory-story.html -请记住，如果仅集成一个 PMS，则微服务是一个过大的杀伤力。 如果要与具有 1000 个不同属性的 1000 个 PMS 实例集成，那么该体系结构的好处就显而易见了。 +好吧，有些人喜欢刻苦学习；-) -## 传统方法：单片应用程序 - -借助传统方法（整体应用程序）开始您的业务并开始新产品是很有意义的，因为它更容易。 目前，您仍在学习有关域以及域如何集成的信息。 - -整体更易于开发和部署，采用整体方法，则更容易回答诸如如何建模预订服务以及如何在访客配置文件微服务中实现访客对帐操作之类的问题。 - -但是，就像您的公司一样，整体式增长非常迅速，并且随着系统的增长，很难扩展： - -添加了新功能，推出了新的代码行，并且当系统变得太大时，它变得难以驯服和理解。 更改系统需要进行严格的回归测试，以确保新功能不会破坏系统的其他部分，因为整体应用程序通常不具有内聚力，也没有松散耦合。 - -故障排除和调试更加困难，因为存在更多具有更多相互依赖性的代码。 更新服务可能需要更改共享的基础结构代码，并且在引入错误时可能导致感染。 庞大的代码库使新手开发人员难以入职和培训。 - -它影响部署：应用程序越大，启动时间就越长。 是的，您可以简单地添加更多服务器并在所有服务器上复制应用程序，但是您仍然只有一个数据库。 不仅如此，系统的某些部分可能会更占用内存，而其他部分则需要大量 CPU。 那么，当您无法分别缩放每个组件时该怎么办？ 您添加更多服务器！ - -这是非常昂贵的。 这样，一旦您对域有了更好的了解，就可能想要开始将系统分解为微服务。 - -## 架构概述 - -现在，我们已经解释了采用微服务架构的长期好处，让我们研究一下如何设计微服务框架的一些细节： - -这里的关键是隔离：集成的系统应该彼此独立运行。 IE：您的核心系统独立于在属性 X 上运行的属性管理系统，并且独立于在属性 Y 上运行的系统。 - -可以通过在核心系统和要与其集成的所有资产管理系统之间引入连接器（中间件）来实现这种隔离。 - -中间件由消息队列和后台工作者组成： - -* 可用于实现的服务示例： - * 消息队列：RabbitMQ，IronMQ 等。 - * 背景工作者：IronWorker，AWS Lambda 等。 - -消息队列提供系统之间的异步通信。 发件人系统（例如您的系统）将消息发布到队列中，并一直位于该队列中，直到后台工作人员（订阅该队列）在以后处理该消息为止。 - -然后，后台工作者负责处理消息（解析其内容），然后管理与 PMS API 的集成。 同样，它将数据保存到中间件数据库中。 - -请记住，后台工作人员可以是像 AWS Lambda 这样的云服务，也可以是内部用 Java 开发的应用程序，也可以是在 Windows 服务中开发的应用程序。 正如我们将在下面详细介绍的那样，微服务的技术堆栈并不重要。 - -请记住，一个消息队列保证 FIFO（先进先出），因此队列中的所有消息都按照它们进入的顺序进行处理。如果您有多个队列，则会将一条消息发布到队列中 可以比发布到队列 Y 的消息更早地处理 X，这在您的设计中应予以考虑。 - -另外，尽管 PMS 可能位于酒店的内部，但您的系统也不一定要位于云中或内部。 - -请记住，此服务控制与预订关联的所有生命周期事件，因此它不仅是 CRUD 包装器。 如果您需要为该预订分配房间，添加陪同客人或什至办理入住手续，您将向该工作人员发送适当的请求。 - -现在让我们根据 Martin 的描述来分析微服务的每个主要特征，以及我们的架构如何实现它们： - -## 1-围绕业务能力的组织 - -每个工作人员都实现了与 PMS 集成的部分逻辑。 您可以将多个工作人员插入到属性中的同一 PMS 实例中，在其他酒店中添加更多连接到同一属性管理系统（同一供应商）的工作人员，还可以在以下位置添加连接到不同属性管理系统（不同供应商）的其他工作人员 其他属性。 - -因此，假设您需要更改与某些 API 方法的交互方式，则只需要将新版本部署到其中一个工作程序，而不会影响其他工作程序。 您可以让一个工人来处理预订，另一个可以来宾。 - -可以在 Linux crontab 中安排一些后台工作程序，以按照给定的时间表重复执行。 其他消息始终在运行，在到达队列时处理消息。 其他后台工作人员也可以回调您的核心系统 API，以插入或更新从 PMS 收集的新信息（即，从 PMS 读取/读取数据并将其加载到您的核心系统中）。 - -在萨姆·纽曼（Sam Newman）撰写的 *Building Microservices* 一书中，他指出“在较小代码库上工作的较小的团队往往生产力更高。”这是通过微服务实现的 - -它不仅可以提高生产率，还可以使团队或个人从一种微服务转移到另一种微服务（代码库的通用共享）。 - -它也可以促进创新，因为长期从事同一项目的个人或团队可能只会提出有限范围的新想法。 而如果您允许您的团队在产品和项目之间切换，他们可能会提出成千上万个新想法。 - -## 2-自动部署 - -微服务需要以自动化方式进行部署。 为什么？ 首先，因为您有很多。 如果必须手动部署它们中的每一个，这将很容易出错并且非常耗时。 这取决于您拥有的微服务数量。 您可以彼此独立地分别释放每个服务。 - -请注意，我的意思是在此处将新版本部署到微服务，而不是分解新的工作程序实例。 您已经在运行工作程序，但是您想部署新版本的代码。 让我们用一个例子说明一下： - -* 假设您必须与 1000 个属性集成，其中 500 个属性使用供应商 1（PMS_1）的 PMS，其中 500 个属性使用供应商 2（PMS_2）的 PMS。 -* 由于无论 PMS 供应商如何，这里的域上下文都非常相似，因此每个 PMS 实例将很可能具有相似数量的工作线程，除非您希望通过添加更多相同类型的工作线程来扩展给定的连接。 简单来说，假设每个 PMS 实例有 5 个工作线程（一个用于保留，一个用于来宾配置文件，等等）。 -* 由于 PMS_1 API 与 PMS_2 API 不同，因此与 PMS_1 集成的保留服务的代码与与 PMS_2 集成的保留服务的代码不同。 -* 在 1000 个属性上，您有 5000 个工人，然后： - * 2500 名 PMS_1 员工 - * 500 名预订工人，每个属性中带有 PMS_1 的一名 - * 500 位访客资料工作人员，每个属性中带有 PMS_1 的一名 - * 500 名 X 工人，每个属性为 PMS_1 的一名工人 - * 500 名 Y 工人，每个属性为 PMS_1 的工人 - * 500 名 Z 工人，每个属性中带有 PMS_1 的工人 - * 2500 名 PMS_2 员工 - * 500 名预订工人，每个属性中带有 PMS_2 的一名 - * 500 位访客资料工作人员，每个属性中带有 PMS_2 的一名 - * 500 名 X 工人，每个属性为 PMS_2 的一名工人 - * 500 名 Y 工人，每个属性为 PMS_2 的工人 - * 500 名 Z 工人，每个资产中带有 PMS_2 的一名工人 -* 假设您对与 PMS_1 集成的 Reservation 服务的代码进行了更改，它已经过测试并且可以发布。 -* 假设您最好有一个源代码存储库，并在每个微服务中内置选择的持续集成工具，这是非常明智的选择，那么您需要将代码部署到 500 个工作程序（与 PMS_1 集成的 500 个保留工作程序）。 - -其次，微服务的目的之一是要具有敏捷性，并且要具有敏捷性，您需要自动化。 这就是持续集成（CI）和持续交付（CD）的神奇之处： - -CI 是一种开发实践，要求开发人员一天几次将代码集成到共享存储库中。 然后，提交触发构建。 如果构建失败，则每个人都会收到警报（原则上会发出偏差警报）。 此处的关键是尽早确定提交问题（即代码问题）。 如果构建成功，则可以将其部署到您的应用程序服务器。 这导致我们实现持续交付： - -连续交付是确保成功构建的工件可以快速部署到生产中的一种做法。 这是通过首先将您的应用程序部署到暂存环境（具有与生产环境相同的特征）来实现的。 只需按“部署”按钮，就可以将应用程序部署到生产环境中。 最好的是，因为它只是一个按钮，所以您无需中断软件工程师的工作。 - -* 可用于实现 CI / CD 的服务示例：Atlassian Bamboo，TeamCity，Jenkins 等。 - -虽然，请不要将持续交付与持续部署混淆。 我不会在这里详细介绍它，但是我留下了 PuppetLabs 的[很棒的文章](https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff)，关于持续交付和持续部署之间的区别。 - -还应注意，微服务的部署比单片应用程序安全得多，这应有助于自动化。 - -## 3-端点的智能 - -后台工作人员封装了如何与 PMS 集成的逻辑。 如果我们需要更改逻辑或 PMS API 已更改，我们只需要在一个地方更改-它不在您的主系统中（将其与对下游 API 的更改隔离开来）。 - -另外，每个 PMS 都有自己的 API，因此您可以隔离与核心系统中的每个 API 进行通信的逻辑。 - -## 4-语言和数据的分散控制 - -每个微服务可以拥有自己的技术堆栈。 让您拥抱技术的异质性。 - -例如：如果我们需要提高特定组件的性能，则可以选择能够实现所需性能的其他技术堆栈。 新服务不依赖于较早的技术定义，而是在适当时利用新的语言或技术。 - -每个工作程序可以使用不同的技术构建：工作程序 1 可以使用 Java 开发，带有 MySQL 数据库以处理来宾配置文件，而工作程序 2 可以使用 C＃开发，具有 NoSQL DB 来处理来宾消息。 记住：他们是独立的。 - -您需要担心它们的集成，即它们之间如何实际通信。 您将实现返回 JSON 的 RESTful API 还是使用 XML 的 SOAP API？ - -现在，让我们更深入地研究中间件。 - -## 中间件 - -中间件提供了系统与要集成的多个属性管理系统之间的隔离。 它由消息队列和后台工作者组成。 - -中间件不应保持状态：两端的系统（即您的系统和 PMS 系统）负责保持有关酒店，访客资料，预订等的状态。中间件只是在两者之间创建映射。 这样做的原因是，您不想引入一个新的组件，该组件也存储可能导致一致性问题的状态：您将在 3 个不同的系统（酒店物业管理系统）中存储相同的实体（例如，预订）。 ，中间件和核心应用程序），并且由于集成中的某些错误，它们可能会有所不同。 在这种情况下，谁持有关于保留真实有效状态的真相？ - -中间件必须提供允许您协调核心系统中的内容与 PMS 中的内容的方法。 因此，如果在核心系统中创建了新请求，但是由于某种原因（实例处于脱机状态，软件错误，网络问题等），则该请求未保存到 PMS 中（例如，向来宾作品集收费） ），中间件应提醒用户该问题并提供重新处理集成的方法。 它必须提供清晰的视图，以显示每个消息在队列中的位置以及每个后台工作人员的状态。 它必须允许您查看给定消息失败及其失败的原因，并提供重试（重新处理）给定消息的机制。 - -您可以在中间件数据库的顶部具有一个缓存层，以便更快地访问常见对象，例如城市代码，信用卡类型等。 一些财产管理系统将此作为具有键-值对的枚举来实现。 可用于提供缓存层的工具示例包括：自托管 Redis，托管 Redis 解决方案（例如 AWS Elasticache），Memcache。 - -## 使用微服务的挑战 - -在构建任何软件时，尤其是在大规模集成系统中，总是存在挑战。 - -纽曼在《构建微服务》一书中提醒我们，“故障成为大规模的统计确定性”，而在实现微服务时（这是整体的）肯定是这种情况。 - -接受一切都会失败（硬盘，网络等）并接受这一事实，很难处理多个独立服务的失败。 - -分布式和异步体系结构难以实现且难以调试。 您需要查看散布在多个实例中的日志，并查看分布式事务性，以了解为什么最终会出现古怪的状态。 如果在同步工作流的中间发生错误，则很难回滚状态。 了解故障发生的位置非常困难，因为工作可能并行进行，并且可能引入了难以管理的竞争条件。 - -确保与微服务的大规模一致性是另一个挑战。 想象一下，您有一个管理来宾个人资料的服务，另一个服务来管理预订。 如果新客人首次在您的酒店预订了预订，则预订微服务将创建新的预订记录，而客人资料微服务将需要创建新的客人资料。 如果访客个人资料存在错误并且未成功创建新的访客个人资料怎么办？ 如果管理不正确，最终将导致一个孤立的预订，该预订未绑定任何访客个人资料。 从规模上讲，这可能很难跟踪和管理。 - -异步分布式体系结构可能会导致其他问题。 让我们想象一下系统发送到事务处理队列的某种类型的请求会使您的工作人员崩溃。 另外，假设您添加了多个工作程序，它们从同一队列中提取消息以加快处理速度。 第一个工作人员从队列中提取消息，然后死亡。 当它死亡时，对请求的锁定将超时，并将原始请求消息放回到队列中。 然后，您的下一个工作人员将从队列中提取相同的消息并获得相同的结果：消息将死亡。 - -另一个挑战是，您将不得不监视不断重新部署的数百种服务。 这将促使需要专用的 DevOps 资源或团队来管理大量服务。 - -由于您有许多通过网络进行的远程呼叫，因此还需要考虑整体系统性能。 众所周知，网络不可靠：数据包可能会延迟，丢失等。此外，系统之间的消息不是实时流动的：您将消息发布到队列中，然后在（ 不久），它将得到处理。 - -最后，使用微服务很难有效地实现版本控制：您最终将更改服务的接口。 您将如何处理？ - -使用每种架构方法都需要权衡。 尽管微服务存在挑战，但是每种方法都存在挑战。 当大规模管理多个 PMS 集成时，使用微服务的好处远远超过成本。 - -**考虑大规模实施的经济性：** - -以下是实现微服务时要考虑的一些比较成本： - -* 大规模部署时，100 个不同的 PMS 集成可能需要 100 个服务器。 -* 使用单片方法，这些服务器始终处于运行状态。 -* 在微服务世界中，微服务在需要时唤醒，在不需要时关闭。 -* 借助 AWS Lambda 或 IronMQ 等云服务，您需要为 CPU 时间而非服务器时间付费。 -* 当采用按需供应系统（如 Amazon Web Services 提供的系统）时，我们可以根据需要对需要的那些组件应用此扩展。 这使我们能够更有效地控制成本。 ， - -因此，随着时间的流逝，微服务在为计算能力付费时会更具成本效益，因为有需求可以使您更紧密地管理成本并最终减少浪费。 很少有一种架构方法可以与几乎立即节省成本紧密相关。 - -那么，从这里去哪里呢？ - -## 拆解整体结构 - -我经常听到的一个常见问题是：“我已经构建了整体应用程序。我是否需要从头开始重新构建它以实现微服务架构？” - -简单的答案是：**否**。 - -长的答案是，您可以将您的整体碎片分开。 它应该是一种渐进的方法，以便您可以了解有关核心功能以及它如何与其他核心功能交互的更多信息。 这对于您了解服务应该是什么以及它们如何相互通信至关重要。 采取“边走边学”的方法，逐步定义系统的哪些部分应成为微服务。 我将在以后的文章中保留有关如何设计和实现此策略的详细信息。 - -我希望这可以解释其好处或使用微服务方法来构建 PMS 集成。 随着您的系统和微服务数量的增长，这种方法将帮助您以更灵活，高效和经济高效的方式进行扩展。 - -## 相关文章 - -* [关于 HackerNews](https://news.ycombinator.com/item?id=11074151) -* [微服务-不是免费的午餐！](http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html) -* [伟大的微服务与 Monolithic Apps Twitter 近战](http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html) -* [来自 Google 和 eBay 的关于建立微服务生态系统的深刻教训](http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html) -* [生产中的微服务-好的，坏的，有效的](http://highscalability.com/blog/2014/10/27/microservices-in-production-the-good-the-bad-the-it-works.html) -* [微服务中最讨厌的七个反模式](http://highscalability.com/blog/2015/8/3/seven-of-the-nastiest-anti-patterns-in-microservices.html) -* [改变一切的融合：数据重力+容器+微服务](http://highscalability.com/blog/2015/3/25/the-convergence-that-changes-everything-data-gravity-contain.html) -* [我们如何构建更好的复杂系统？ 容器，微服务和持续交付。](http://highscalability.com/blog/2015/4/27/how-can-we-build-better-complex-systems-containers-microserv.html) - -诸如此类的技术是使物业管理更加有效和高效的好方法。 我们希望将来能看到更多诸如此类的技术创新。 感谢您分享本文，这是设置此集成的不错的教程。 \ No newline at end of file +与矢量时钟的链接已断开。 正确的链接应该是 http://basho.com/posts/technical/why-vector-clocks-are-easy/ \ No newline at end of file diff --git a/docs/57.md b/docs/57.md index df41cfd..0694698 100644 --- a/docs/57.md +++ b/docs/57.md @@ -1,29 +1,205 @@ -# Tinder：最大的推荐引擎之一如何决定您接下来会看到谁？ +# Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件 -> 原文： [http://highscalability.com/blog/2016/1/27/tinder-how-does-one-of-the-largest-recommendation-engines-de.html](http://highscalability.com/blog/2016/1/27/tinder-how-does-one-of-the-largest-recommendation-engines-de.html) +> 原文： [http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html](http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html) -![](img/2688e3c8765d8fadc182017986ce3866.png) +![](img/26429ee917d000d853d82c835eb1ab89.png) [Mollom](http://mollom.com/) 是每个开发人员在绞尽脑汁寻找可行的软件即服务创业公司时都梦 of 以求的出色的 SaaS 公司之一。 Mollom 与一小部分地理位置分散的开发人员一起以有益的方式运行有用的服务-[垃圾邮件过滤](http://www.youtube.com/watch?v=anwy2MPT5RE)。 Mollom 帮助保护了近 40,000 个网站免受垃圾邮件的侵扰，其中包括[属于我的](http://biztaxtalk.com/)，这是我第一次了解 Mollom 的地方。 为了在 Drupal 网站上停止垃圾邮件的拼命尝试，在该网站上，所有其他形式的 CAPTCHA 都失败了，我在大约 10 分钟内安装了 Mollom，它立即开始工作。 那是我一直在寻找的开箱即用的体验。 -我们已经听到很多关于电影的 Netflix [推荐算法](http://www.wired.com/2013/08/qq_netflix-algorithm/)，[亚马逊](https://www.cs.umd.edu/~samir/498/Amazon-Recommendations.pdf)如何与您匹配的东西，以及 Google 臭名昭著的 [PageRank](https://en.wikipedia.org/wiki/PageRank) 的信息。 Tinder 呢？ 事实证明，Tinder 具有令人惊讶的深思熟虑的推荐系统来匹配人员。 +从 Mollom 开放其数字检查系统开始，他们已经拒绝了超过 3.73 亿封垃圾邮件，在此过程中，他们了解到，惊人的 90％的邮件都是垃圾邮件。 该垃圾邮件洪流仅由两台地理位置分散的计算机处理，这些计算机每秒处理 100 个请求，每个计算机都运行 Java 应用程序服务器和 Cassandra。 因为它们创建了一个非常高效的机器学习系统，所以几乎不需要任何资源。 那不是很酷吗？ 那么，他们怎么做呢？ -[（刷卡）先生，对吗？](https://story.californiasunday.com/sean-rad-tinder) ，在 Tinder 创始人 Sean Rad 上： +为了找出答案，我采访了 Mollom 的联合创始人 Benjamin Schrauwen，以及 Glassfish 和 Java 企业专家 Johan Vos。 证明软件没有国界，Mollom HQ 位于比利时的[H​​TG0] （来自比利时的其他好东西： [Hercule Poirot](http://en.wikipedia.org/wiki/Hercule_Poirot) ，[巧克力](http://www.google.com/images?q=belgian+chocolate)，[华夫饼](http://www.google.com/images?q=belgium+waffles) ）。 -> 根据 Badeen 所说，用户的目标是让他们忘记三秒钟之内被刷过的人。 但是 Tinder 没有。 他们研究成员滑动的对象，匹配对象。 然后他们看“重新激活”。 年轻的用户将消失几周，然后“重新激活”或再次开始刷卡。 年龄较大的用户会花更多时间查看各个个人资料，并且很可能在重新激活之前消失了几个月。 古尔德说，平均活跃用户每天在 Tinder 上花费一个小时。 （拉德说他上瘾了，花了无数小时来刷卡。） +## 统计 -> 邻里模式往往是独特的。 即使是城市中不同街区的人，也会有不同的举止或匹配的可能性较小。 古尔德说：“人们自然在地理上对自己进行分类。” 如果人们旅行，他们的行为就会发生巨大变化。 **“我们了解了一个人的全部知识，”古尔德说，“然后他们去了另一个地方，采取了完全不同的行动**。 古尔德（Goul）负责调整算法，他的头发偏斜一些，衣服比 Rad 和 Badeen 的宽松一些。 也就是说，比赛不是偶然发生的。 Tinder 正在安排您接下来要看的人。 **拥有数十亿个匹配项，因此拥有大量数据**。 Rad 说：“我们可能是世界上最大的推荐引擎之一。” +* 服务于 40,000 个活跃的网站，其中许多是非常大的客户，例如 Sony Music，Warner Brothers，Fox News 和 The Economist。 很多大品牌，有大网站，还有很多评论。 +* 每天查找 1/2 百万封垃圾邮件。 +* 每秒处理 100 个 API 调用。 +* 垃圾邮件检查的延迟很短，大约需要 30-50 毫秒。 最慢的连接将是 500 毫秒。 延迟的第 95 个百分位数是 250 毫秒。 它确实针对速度进行了优化。 +* 垃圾邮件分类效率为 99.95％。 这意味着 Mollom 不会捕获 10,000 个垃圾邮件中的 5 个。 +* [Netlog](http://mollom.com/blog/netlog-using-mollom) 是欧洲的一个社交网站，在其自己的数据中心中拥有自己的 Mollom 设置。 Netlog 每天根据自定义[分类器](http://en.wikipedia.org/wiki/Learning_classifier_system)处理大约 400 万条消息，这些分类器对其数据进行了训练。 -> **首先，古尔德告诉我，该应用程序的统治类别为“匹配 1％，**”，这些人获得了大量的比赛，并且使其他所有人看起来都比较糟糕。 Tinder 决定**改变趋势，减少显示**的配置文件，特别是向不在 1％范围内的用户展示。 现在，显示出很多向右滑动（是）的人逐渐减少的人，而得到了很多向左滑动（否）的人逐渐表明的人越来越多。 “我称之为累进税制-重新分配比赛。 他们并不是真正要重新分配的人，但我们会尽力而为。”古尔德说。 “这样做是正确的。” **该公司将其称为“智能匹配”：通过平衡游戏环境并确保不太可能获得匹配的成员获得一些东西，从而在约会世界中赢得正义。** “人类状况的一部分是斗争。 如果您除了“维多利亚的秘密（Victoria's Secret）”模特外什么都看不到，那就不一定要脱颖而出。” “当我们介绍不适合您的人时，就会突出那些人。 比赛不是偶然发生的。 Tinder 正在安排您接下来要看的人。 +## 平台 -> **他们还更改了不良演员的系统，限制了每天刷卡的次数**。 古尔德说：“我们以前有一群人会向所有人轻扫，然后不回应，所以我们增加了一个限制，以发现未玩游戏的人。” “我很惊讶，但是人们实际上很聪明。 他们发挥自己的才能。 在最初的几天里，这些家伙不断达到极限。 然后，在那之后，他们开始适应。 一旦完成，对话时间就会更长。 +* 两个生产服务器在两个不同的数据中心中运行以进行故障转移。 + * 一台服务器在东海岸，一台在西海岸。 + * 每个服务器是一个 Intel Xeon Quad 核心，2.8 GHz，16 GB RAM，4 个 300 GB 磁盘，RAID 10。 +* [SoftLayer](http://www.softlayer.com/ ) -机器由 SoftLayer 托管。 +* [Cassandra](http://cassandra.apache.org/) -选择 NoSQL 数据库是因为它具有出色的写入性能和跨多个数据中心进行操作的能力。 +* [Glassfish](http://en.wikipedia.org/wiki/GlassFish) -用于 Java EE 平台的开源应用程序服务器。 他们选择了 Glassfish，因为它具有企业级功能，例如复制和故障转移。 +* [Hudson](http://hudson-ci.org/) -可在所有服务器上进行后端的连续测试和部署。 +* Java-Mollom 从一开始就是用 Java 编写的。 +* [Munin](http://munin-monitoring.org/) -用于测量和绘制有关服务器运行状况的指标。 +* [MySQL](http://www.mysql.com/) -JPA（Java Persistence API）用于常规数据集，而 Cassandra 用于大型数据集。 +* [Pingdom](http://www.pingdom.com/) -用于正常运行时间监视。 +* [Zendesk](http://www.zendesk.com/) -用于支持。 +* [Drupal](http://drupal.org/) -用于具有自定义电子商务模块的主网站。 +* [解除混淆](http://unfuddle.com/)-Subversion 托管由其分布式开发团队用于源代码控制。 -> **Gould 和 Badeen 将这些干预视为道德义务**。 Badeen 说：“知道它会对人们产生多大的影响，这很令人恐惧。” “我尝试忽略其中的一些，否则我会发疯。 我们正处于对世界负有社会责任的地步，因为我们具有影响世界的能力。 +## 什么是 Mollom？ -> Gould 回应了这一观点：“听着，建筑师设计的建筑物设定了人们的生活方式。 城市规划人员设置城镇和道路。 作为帮助人们约会的系统的设计者，我们有责任建立这些背景-我们每年都要为这个星球上相当比例的婚姻负责。 这是一种荣誉和责任。 +Mollom 是一项 Web 服务，用于从用户生成的内容中过滤掉各种类型的垃圾邮件：评论，论坛帖子，博客帖子，民意调查，联系表，注册表和密码请求表。 垃圾邮件的确定不仅取决于发布的内容，还取决于张贴者的过去活动和声誉。 Mollom 的[机器学习](http://en.wikipedia.org/wiki/Machine_learning)算法充当您的 24x7 数字主持人，因此您不必这样做。 -[关于 HackerNews](https://news.ycombinator.com/item?id=10981314) +### 如何使用？ -它与高可扩展性有何关系？ +例如，诸如 Drupal 之类的应用程序使用一个模块将 Mollom 集成，该模块将自身安装到内容编辑集成点中，以便在将内容写入数据库之前可以检查其内容是否为垃圾内容。 该过程看起来像： -我当然喜欢技术细节，但是我发现这些与政策相关的见解也很重要。 它比我预期的要更加周到和完善，并且有趣地使用大数据来推动产品在面向目标的方向上使用。 +* 当用户向网站提交评论时，将对后端服务器进行 API 调用。 +* 会对内容进行分析，如果是垃圾内容，则将告知网站阻止该内容，或者如果后端不确定，它将建议该网站显示 [CAPTCHA](http://en.wikipedia.org/wiki/CAPTCHA) ，它们也可以提供该内容。 +* 正确填写验证码后，内容将被接受。 在大多数情况下，人们不会看到验证码，该内容将直接被视为*火腿*，火腿是好内容，*垃圾邮件*是坏内容。 +* 仅在机器学习算法不是 100％确定的情况下才显示 CAPTCHA，因此在大多数情况下不会给人类带来不便。 -因此，他们有社会责任限制每天比赛的次数，但是如果您为服务付费，您仍然可以做到吗？ 他们的道德晴雨表似乎有问题。 \ No newline at end of file +### 仪表板 + +Mollom 的每个帐户都包含一个漂亮的[漂亮的信息中心](http://mollom.com/scorecard)，它向您显示了已接受多少火腿和已拒绝多少垃圾邮件。 在图中看到的垃圾邮件数量确实令人沮丧。 + +### 运作流程 + +**安装。** 对于 Drupal 来说，安装非常容易。 像安装其他模块一样安装它。 在 Mollom 网站上创建一个帐户。 获取一对安全密钥，将这些密钥配置到模块中，然后选择要使用 Mollum 保护的系统部分。 就是这样 + +**每日**。 我定期检查垃圾邮件是否已经通过。 它不是 100％，因此某些垃圾邮件确实可以通过，但很少。 如果垃圾邮件确实通过了，则有一种方法可以告诉 Mollom 该帖子确实是垃圾邮件，应将其删除。 无论如何，这都是您必须要做的，但是在此过程中，您正在帮助培训 Mollom 的机器学习算法，了解什么是垃圾邮件。 + +**允许匿名用户交互**。 有了出色的垃圾邮件检查程序，就有可能建立一个网站，人们可以进行匿名交互，这是许多使用某些类型网站的人真正喜欢的。 一旦您要求注册，参与活动就会减少，并且注册也不会阻止垃圾邮件发送者。 + +### 并非一切都是玫瑰色 + +处理误报是 Mollom 的最大缺点。 垃圾邮件检测是拒绝火腿和接受垃圾邮件之间的困难平衡行为。 Mollom 的机器学习算法似乎运行得很好，但是有时存在一个问题，即好的帖子被拒绝，您会感到恐惧：*您的提交触发了垃圾邮件过滤器，将不被接受*。 目前没有追索权。 对于用户而言，几乎没有什么比让他们的光荣评论被垃圾邮件拒绝更令用户生气的了。 用户只会尝试几次来解决问题，然后他们只会放弃并走开。 + +问题是无法解决此问题。 为了保护机器学习算法不被玩耍，Mollom 不允许您提供一个示例，该示例错误地拒绝了应接受的内容块，尽管他们正在努力在将来添加它。 + +这是一个艰难的决定。 静态 CAPTCHA 系统，即仅要求用户通过测试即可提交内容的系统，一旦将站点定为严重攻击目标就无法正常工作。 用户注册无效。 考虑到一个站点每天可能有成千上万的垃圾邮件，对每个帖子进行审核需要非常高的负担，尤其是对于“爱好”站点。 垃圾邮件完全杀死了一个站点，因此，要平衡激怒某些用户的风险，而不要因为一个被炸毁的站点而最终没有用户。 + +## 商业模式 + +* 让 Mollom 轻松自如的是，它是免费的。 您只需在网站开始每天接受 100 多个火腿消息后付款。 对于小型站点，这可能永远不会发生。 +* 一旦超过免费门槛，便有 Mollom Plus（每天 1 欧元）和 Mollom Premium（3600 欧元/年/站点）的定价层，这似乎很合理。 +* 免费的网站并不会像您期望的那样浪费资源，它们实际上是重要培训数据的来源。 所有使用 Mollom 的网站都在不断将数据反馈给后端分类器。 使用 Mollom 的人越多，通过从用户那里获得的所有反馈进行培训的效果就越好。 没有免费的网站，Mollom 就不会像现在那样准确。 + +## 建筑 + +* Mollom 非常受工程驱动。 主要重点在于使 Mollom 在代码和服务器资源使用上都尽可能高效。 +* 实际上，每个服务器都可以处理所有请求，但是它们具有完整的故障转移。 工作在机器之间分配。 如果其中一个发生故障，则工作移至另一台机器。 + * 他们曾经有 3 台服务器，但是由于它们提高了性能，因此可以将第三台服务器用作登台服务器。 + * 每个服务器每秒可以处理完整的 100 个连接，并且每个连接运行整个管道：全文分析，计算作者的信誉并提供 CAPTCHAS。 +* 真正针对低延迟进行了优化。 由于垃圾邮件检测是内容提交到站点过程的一部分，因此，如果花很长时间，对用户来说真的很烦。 +* 软体动物经历了几个发展阶段： + 1. 最初，一个由两个人组成的小团队在做兼职，负责算法，分类器和他们试图解决的实际业务问题。 为了在后端建立基础架构，他们使用了自己的线程池，连接池，资源管理实现。 他们发现他们花了太多时间来支持所有这些东西并使其扩展。 然后他们切换到 Java 应用程序服务器 Glassfish，因此他们不必担心内存管理，REST 处理，XML 解析和数据库连接池。 + 2. 过去的主要问题是磁盘带宽。 他们需要跟踪 Internet 上所有 IP 地址和所有 URL 的信誉，因此这是一个庞大的数据存储，具有许多随机访问权限。 + 3. 早期，他们使用廉价的虚拟机，而一切都在 MySQL 中进行，但无法扩展。 + 4. 然后，他们将其移至固态磁盘并将所有内容存储在文件中。 固态解决了写问题，但是有一些问题： + 1. 真的很贵。 + 2. 这对安装的文件系统类型非常敏感。 + 3. 写入速度很快，但是遍历数据以清理数据或在数百万个小对象上训练新的分类器仍然非常缓慢。 + 5. 然后他们离开了固态，搬到了卡桑德拉。 +* Cassandra 现在用作写繁重负载的数据库和缓存层： + * 在 [RAID 10](http://www.thegeekstuff.com/2010/08/raid-levels-tutorial/) 磁盘配置（条带化和镜像）上运行，这对于大量读/写非常有用。 + * 卡桑德拉（Cassandra）针对写入进行了优化，而 Mollom 的写入量要大于读取量。 + * 设计为分布在数据中心内部和整个数据中心。 + * 缺点是没有标准的 NoSQL 接口，这使得编写应用程序变得困难。 + * Cassandra 的行缓存使他们不必在系统中添加另一个缓存层，从而消除了大量应用程序代码。 + * Cassandra 具有老化功能，该功能会在一段时间后自动删除数据。 欧洲有严格的隐私法，要求一段时间后删除某些数据。 此功能是一个巨大的胜利。 这是一个非常昂贵的操作，Cassandra 处理它会删除很多应用程序代码。 +* 博客评论通过系统的路径： + * 请求可以来自任何客户端。 客户端跨服务器负载平衡请求。 这部分将在后面说明。 典型的客户端是 Drupal 系统。 请求可以是 XML-RPC 或 REST。 + * 请求由 Glassfish 应用程序服务器处理并遵循典型的应用程序服务器工作流程：请求由 servlet 处理并委托给会话 bean。 + * 付费客户首先得到服务，免费客户可能会遇到更长的延迟。 + * 对该请求进行解析和分析。 稍后再详细介绍。 确定垃圾邮件分数并将其返回给用户。 因此，Mollom 有不同的功能部分：垃圾邮件检查和 CAPTCHA 处理。 CAPTCHA 包括生成，提供和处理响应。 不同的会话 bean 负责 Mollom 功能的各个部分。 + * 分类器完全位于 RAM 中。 一小部分内容被炸裂成数千个可以识别垃圾邮件的小令牌。 这些分类器在 RAM 中具有几百万个令牌。 分类器需要真正快速运行，因此它们必须位于 RAM 中。 + * 卡桑德拉（Cassandra）中保存的是信誉分数，频率，URL 和 IP 地址。 Cassandra 的新行缓存功能现在充当其缓存层。 以前，他们实现了内部缓存，但是已将其删除。 + * 两个数据中心中的两台机器都运行 Cassandra 和 Glassfish 应用程序服务器。 Cassandra 不断在数据中心之间复制数据。 + * 内存中的数据结构不会直接复制。 他们写信给 Cassandra，然后复制。 另一端的缓存超时，因此它将转到 Cassandra 并获取新数据。 最终是一致的。 不一致的窗口很小，但是模型在这么短的时间内不会受到负面影响。 + * 一致性是根据具体情况进行管理的。 对于信誉和 IP 地址，最终的一致性很好。 会话数据（包括 CAPTCHA 会话）保持严格一致，因此当计算机进行故障转移时，它们将正确跟踪。 +* 客户端负载平衡 + * Mollom 使用[客户端负载平衡](http://mollom.com/api/client-side-load-balancing)，该负载平衡基于延迟等进行分配。作为一家初创公司，他们没有钱购买大型负载平衡器。 他们的另一个目标是能够对多个数据中心进行全局负载平衡，这将需要昂贵且复杂的设置。 + * 客户端列表的管理通过 API 进行。 每个客户端都有其可以使用的可用服务器的列表。 + * 每个客户端可以获取要使用的服务器的不同列表。 可以向付费客户提供更近的服务器列表，以减少延迟。 + * 当服务器发生故障时，客户端将尝试列表中的下一个服务器。 + * 客户端负载平衡有助于从旧系统迁移到新的基于 Glassfish 的系统。 将为新用户提供已迁移计算机的地址，而旧用户仍在旧计算机上工作，并且可以通过更新其服务器列表以有序方式进行迁移。 这允许进行测试，以便他们可以测试功能，然后测试伸缩性和性能。 他们查看了响应时间，连接队列中有多少个连接以及队列中将保留多长时间。 他们可以测试如果增加线程池中的线程，更改 JDBC 连接数以及其他配置会发生什么情况。 所有人迁移后，旧服务器将关闭。 过渡期间几乎没有停机时间，这对于高可用性系统至关重要。 当系统关闭时，垃圾邮件正在通过。 + * 客户端方法的缺点是，如果第三方客户端的文字写得不好，就会出现问题。 例如，客户端可以获取服务器列表，并以相反的顺序对其进行迭代，这是错误的。 他们现在与客户开发人员紧密合作，并提供高质量的参考代码示例，以便开发人员可以学习最佳实践。 +* 机器学习 + * Mollom 是一组学习系统。 一个既不考虑用户行为也不考虑起点的 CAPTCHA 解决方案，永远无法达到这种水平的知情保护，并且通常要求用户在每个帖子上都解决 CAPTCHA 问题。 使用 Mollom 的文本分析，仅当 Mollom 不确定帖子时，用户才必须解决验证码。 + * 平均消息长度约为 500 个字符，这被分解为 3,000 个功能。 通过查看 IP 地址或 Open ID 的信誉来确定帖子的混乱状态，可以查看用户 ID，情感，语言，亵渎，特定单词和单词组合，还可以查看文字的写法。 等等。所有这些都是基于分类器的。 一些分类器本质上是统计的，可以自动学习。 一些基于规则的分类器可确保它们永远不会出错。 最终，所有这些测试将决定垃圾邮件得分。 + * 他们从该过程中学习，并实时更新分类器和内部指标。 +* Glassfish 可处理工作计划，并旨在处理多核工作负载。 + * 关键是创建一个尽可能平行的作品设计，并具有尽可能小的锁定窗口。 + * 调整并发 HTTP 连接的数量，以便它们具有适当大小的可用连接池。 + * 每个服务器使用 16 个线程。 + * 大多数调用由无状态会话 Bean 处理，该会话状态可很好地进行并发管理。 + * 他们在池中保留了多个会话 bean，但让 Glassfish 决定池中应包含多少个会话 bean。 在峰值负载下，池中将有更多会话 Bean，因此可以有效地处理请求。 任何给定时刻都可以并行运行 32 个会话 Bean。 + * 所有的分类器实际上都是会话 Bean，它们被不同的线程重用。 + * 每个会话 bean 都有自己的与 Cassandra 的客户端连接，因此它们不会互相阻塞。 + * 当用户不响应 CAPTCHA 时，该会话将被清除，Mollom 得知这可能是垃圾邮件。 + * 每个服务器的每个分类器都有一个实例。 + * 会话清理的锁争用时间很短，其中正在更新分类器。 + * 每 1/2 小时将更新的分类器写回到 Cassandra。 +* 应用整合 + * Mollom 使用开放式 API，可以将其集成到任何系统中。 + * 库：Java，PHP，Ruby 等。 + * 集成解决方案：Drupal，Joomla，Wordpress 和其他内容管理系统。 + * 第三方根据 Mollom 产生的示例代码生成新的绑定。 +* 为了监视服务器的运行状况，他们使用 Munin 进行了持续监视： + * 垃圾回收后堆的大小是多少？ + * 可用连接数是多少？ + * 线程池中可用的线程数是多少？ 确保没有一个线程长时间等待锁。 +* 当您查看他们的体系结构时，Mollom 试图构建一种可以透明地在多个数据中心内工作的体系结构，当它们已经超出单个服务器系统的规模时，它们本身可以向上扩展： + * 客户端负载平衡用于选择和故障转移服务器。 + * Glassfish 群集将用于在应用程序层进行故障转移，并使添加和删除计算机变得容易。 + * Cassandra 将用于跨数据中心管理数据层。 +* Netlog 的 Mollom 安装具有一些有趣的特征。 它比 Mollom.com 主要服务器处理的更多，但是垃圾邮件的分布完全不同，因为他们的人员进行通信是社交网络的一部分。 Netlog 上的垃圾邮件分布为 90％的火腿和 10％的垃圾邮件，而在残酷的博客世界中，这恰恰相反。 有趣的含义是，处理火腿所需的资源较少，因此它们实际上可以在同一服务器上执行更多工作。 +* 他们最初尝试使用虚拟服务器，并考虑使用 Amazon，但是他们发现 IO 是使用共享虚拟服务器的主要瓶颈。 IO 延迟和带宽是真正的问题，因此他们决定扩大规模并使用更大的计算机和更大的磁盘。 + * 令人惊讶的是，它们不受 CPU 限制。 8 个内核中只有两个在计算。 其他人只是在做 IO。 + * Mollom 的流量相当稳定，因此拥有专用服务器更具成本效益。 他们看到亚马逊更多地是一种处理高峰负载的方式。 +* 开发过程 + * 他们是分散的团队。 三个人在比利时，一个在德克萨斯州，波士顿和德国。 + * Scrum 被用作开发过程，他们对此非常满意。 Scrum 会议在下午 2 点通过 Skype 进行。 他们发现随着他们的成长，他们需要更多的过程。 + * 开发人员在本地进行开发，并将代码提交到 Unfuddle 中。 + * Hudson 被用作他们的持续集成环境。 Hudson 使他们从旧系统到新 Glassfish 系统的迁移更加容易，因为必须在部署之前通过测试。 他们并没有浪费太多时间，因为在生产部署之前就发现了问题。 + * 他们有很多测试：单元测试，系统测试，Drupal 测试。 只有当 Hudson 通过了这些测试时，才能部署系统。 + * 仍然可以手动进行部署，以减少潜在的停机时间。 + * 每当他们发现垃圾回收时间出现问题时，这总是归因于其应用程序中的内存泄漏。 万一发生内存泄漏，他们将进行核心转储。 要从 16GB 的计算机分析核心转储不是那么容易，您可能无法在本地计算机上对其进行分析，因此他们要做的是在 Amazon 上租用一个大内存实例来分析转储。 处理堆转储大约需要 2 个小时。 他们比较了两个转储，一个在执行时间 10 小时后，另一个在执行时间 20 小时后。 如果存在重大差异，则可能是由于内存泄漏。 + +## **未来方向** + +* Mollom API 使用 XML-RPC，他们现在正在测试 REST 实现，以使服务更易于使用 Mollom 进行混搭。 +* 现在，他们已经过渡到 Cassandra，在增长需要时，他们可以更轻松地进行横向扩展。 +* 即将发布的企业功能可以将数百个网站作为一个单元进行管理。 通过情绪，垃圾邮件分数或从某些 IP 地址删除所有评论，很容易在一组网站上进行审核。 +* 他们已经进行了有关进入 Twitter 等流数据业务的讨论，但受到欧洲更加严格的隐私政策的限制。 +* 他们将使用 Glassfish 进行实验，以平衡每个数据中心的负载。 +* 如果负载增加 10 倍，则必须添加更多的 Cassandra 节点。 磁盘 IO 是瓶颈。 仅当它们的增长速度必须超过 10 倍时，才需要添加更多的应用程序服务器。 + +## 经验教训 [ + +* ****效率带来幸福。** Mollom 非常重视高性能工程。 他们为 Mollom 极具成本效益而感到自豪。 它可以在一台服务器上处理许多请求，而延迟时间很短，这使客户感到满意，这使他们感到满意，因为他们不必维护大量机器，而且成本很低。 他们从一开始就将其作为优先事项，并选择了正确的技术来实现其目标。 这样一来，他们就可以利用自己赚的钱，在营销，建立用户群以及在 Mollom 之上开发新产品方面进行投资。** +* **广度免费，付出深度**。 机器学习需要大量示例数据才能成功检测到垃圾邮件。 为了获得这些数据，Mollom 为客户提供了免费的服务，他们提供了更好地训练学习算法所需的广泛数据，他们是不断提供情报和反馈的来源。 较大的客户不仅提供收入，而且还可以从免费客户那里学到的数据受益。 该模型似乎是大数据和机器学习所特有的，众所周知，这是一切的未来。 +* **移除非特定领域的障碍物**。 大型系统需要大量基础架构工作。 基础架构的工作通常使工作不再涉及与产品的真正价值产生领域相关的功能（分类器，信誉系统，客户端库）。 Mollom 有意识地尝试通过选择 Cassandra 和 Glassfish 来尽可能地摆脱基础设施业务。 +* **注意客户端代码**。 客户端代码很有吸引力，因为它使用别人的资源而不是您的资源。 问题在于代码编写得不好，这会使您的系统看起来很糟糕。 与客户开发人员紧密合作，并提供高质量的参考代码示例，以便开发人员可以学习最佳实践。 +* **优先考虑付费客户**。 付费客户可以获得更好的服务质量。 它们首先在队列中处理，并且减少了整个系统的延迟。 付费客户可以访问故障转移服务器，而免费客户只能使用一台服务器。 +* **通过让堆栈进行繁重的操作**来减少代码。 在早期，Mollom 代码库比现在大得多。 Cassandra 通过处理复制和行缓存删除了许多复杂的代码，Glassfish 删除了许多应用程序代码，并将处理集群。 随着时间的推移而简化。 +* **最小化锁争用**。 Mollom 花了很多时间来减少 Glassfish 服务器中的锁争用，因为这已成为主要瓶颈。 尽可能少地锁定即可保持完全的并行性。 + +## 相关文章 + +* [Mollom API](http://mollom.com/api) +* [Mollom Drupal 模块](http://drupal.org/project/mollom) +* [Mollom 技术白皮书](http://mollom.com/files/mollom-technical-whitepaper.pdf) +* [Mollom 的 Twitter 帐户](http://twitter.com/#!/mollom) +* [第 072 集-Mollom.com 的 GlassFish 后端，带有 Dries 和 Johan](http://blogs.sun.com/glassfishpodcast/entry/episode_072_mollom_com_s) +* [Mollom 获得了一个新的后端](http://buytaert.net/mollom-gets-a-new-backend) +* [在 Glassfish 上用 Mollom 打击垃圾邮件](http://blogs.lodgon.com/johan/) +* 要了解有关大数据和机器学习的更多信息，请查看 [Strata Conference](http://strataconf.com/strata2011/public/schedule/proceedings) 中的一些资料。 + +好帖子！ + +我想念什么吗？ 100 rps 令人印象深刻吗？ + +托德 + +首先，我是该网站的忠实拥护者，我会定期关注您的帖子。 + +我喜欢这篇文章，但是每秒的请求引起了我的注意。 我很好奇您认为“高吞吐量”服务。 我问是因为我是 Proxomo 的首席软件架构师（http://www.proxomo.com）。 我们的负载测试已在两台服务器（在 Microsoft Azure 上运行）上以每秒超过 500 个请求的速度为 REST 服务提供时钟。 + +谢谢 +Daniel ..... + +丹尼尔，您好，如果您想谈谈您的架构，请给我发电子邮件。 关于您的问题，我认为没有任何特定的阈值定义“高吞吐量服务”。 Mollom 给我留下了深刻的印象，因为它们有一个复杂的机器学习应用程序，可以在一台（大型）机器上运行，它们遵循严格的质量和性能指标，它们是可盈利的，并且它们以正确的方式做事。 有很多人在创建应用程序，不是每个人都是 Google，所以我真的很喜欢这些提供真正价值的更人性化服务的示例。 + +垃圾邮件取决于上下文。 如果我经营一个科技网站，那么政治评论就是垃圾邮件。 如果我经营一个政治网站，那么技术评论就是垃圾邮件。 如果使用“从用户那里获得的所有反馈”对 Mollom 进行培训，如何避免出现问题？ + +如何将其整合到 Drupal 中？？？ \ No newline at end of file diff --git a/docs/58.md b/docs/58.md index f24df5b..026d0d4 100644 --- a/docs/58.md +++ b/docs/58.md @@ -1,97 +1,61 @@ -# 为 David Guetta 建立无限可扩展的在线录制活动 - -> 原文： [http://highscalability.com/blog/2016/1/20/building-an-infinitely-scaleable-online-recording-campaign-f.html](http://highscalability.com/blog/2016/1/20/building-an-infinitely-scaleable-online-recording-campaign-f.html) - -![](img/8d29dd52af7470d0176746037a51e171.png) - -*这是 [Ryan S. Brown](https://twitter.com/ryan_sb)* 最初发布在 [serverlesscode.com](https://serverlesscode.com/post/david-guetta-online-recording-with-lambda/) 上的一次采访*的来宾帖子。 它继续了我们对 Lambda 顶部建筑系统的探索。* - -分页 [David Guetta](https://en.wikipedia.org/wiki/David_Guetta) 粉丝：本周，我们采访了在其最新广告系列背后建立网站的团队。 在网站上，歌迷可以录制自己演唱的单曲“ This One’s For You”，并制作专辑封面。 - -后台**该站点建立在 Lambda，API Gateway 和 CloudFront** 上。 社交广告系列通常会变得很尖刻–当大量媒体报道时，如果您还没有准备好，大量的用户涌入便可以使基础架构开始爬行。 [parall.ax](https://parall.ax/) 的团队之所以选择 Lambda，是因为它没有使用寿命长的服务器，而且他们可以根据亚马逊的需求来分担上下扩展应用程序的所有工作。 - -来自 [parall.ax](https://parall.ax/) 的 James Hall 将会告诉我们他们如何构建一个国际化的应用程序，该应用程序可以在短短六周之内满足任何水平的需求。 - -# 面试 - -## 什么是 [parall.ax](https://parall.ax) ？ 告诉我您的公司（规模，专长等） - -Parallax 是一家数字代理商。 我们提供一系列服务，包括应用程序开发，安全性和设计服务。 我们有 25 名全职员工以及一些外部承包商。 我们专注于提供可大规模扩展的解决方案，尤其专注于体育，广告和快速消费品（FMCG）。 - -## 告诉我一些有关该应用程序的信息，它可以解决什么问题？ - -该应用程序是 David Guetta 的新发行版“ T [他的一生为您](https://www.youtube.com/watch?v=MAQIb2lYFV0)”（这是 2016 年 UEFA EURO 决赛的官方主题曲）的大规模营销活动的一部分。 我们正在邀请粉丝-希望到三月时达到一百万-进入虚拟录音室，并为他们提供与 Guetta 一起唱歌的机会。 不仅他们的声音会出现在最后一首歌中，我们还将用他们的名字和最喜欢的团队创作个性化的专辑插图。 可以在朋友之间共享，从而增加参与度，并允许更多粉丝加入广告系列。 整个网站以十二种语言构建，融合了 DJ 自己的视频内容以及赢得巴黎之旅的机会。 您可以在 [thisonesforyou.com](https://thisonesforyou.com/) 上进行检查。 - -## 除了 Lambda 之外，该应用程序还使用哪些其他技术？ 这包括前端，移动数据库以及任何您可以共享的数据库。 - -![](img/cd0ba5372b9f01f9969fa55640d53dbe.png) *图片来源：Parallax Agency Ltd.* - -在后端，我们使用各种技术来提供完全可伸缩的体系结构。 我们使用[无服务器](http://serverless.com)（以前称为 JAWS）和 CloudFormation 在代码中协调整个平台。 - -请求通过 CloudFront 路由，静态资产缓存在距离请求它们的用户最近的 Edge 位置。 页面首次加载时，所有内容都是完全静态的。 在客户端浏览器中会生成一个 UUID-该 UUID 用于将来的所有 API 请求，并允许我们将页面中的不同操作关联在一起，而不必提供 Cookie。 此值的随机性很重要，因此该库使用计时和加密函数（如果可用）来导出随机种子数据。 - -![](img/b38e059c0a37d515a1464569900bc753.png) *图片来源：Amazon Web Services* - -静态资产的来源是一个简单的 S3 存储桶。 这些通过部署脚本上载。 - -然后，语言检测端点发送回 Accept-Language 标头以及接收请求的国家代码。 这是使用基本的 Lambda 函数。 另一个端点将订户数据添加到 DynamoDB，以及通过 Amazon SES 向他们发送欢迎电子邮件。 为了使录制工作正常进行，我们有一个端点，该端点为以提供的 UUID 命名的路径发行 S3 令牌。 然后，将上传的内容从浏览器直接发布到 S3。 - -Lambda 最有用的应用是图像生成端点。 我们拍摄用户最喜欢的球队标志的图像，覆盖 Guetta 的照片，然后添加他们的名字。 然后将其与 Facebook 和 Twitter 大小的图形一起上传到 S3。 我们还上传了一个静态 HTML 文件，该文件指向此唯一的图形。 这样可以确保当人们共享 URL 时将显示其自定义插图。 为此，我们在页面中使用 Open Graph 图像标签。 - -在前端，我们使用 Brunch 来编译车把模板，编译 SASS，为 CSS 加上前缀以及任何其他构建任务。 - -记录接口本身具有三种实现。 WebRTC 录音机是“ A 级”体验，它使用新的 HTML5 功能直接从麦克风录音。 然后，我们会有一个 Flash 回退来获得相同的体验，这适用于不支持 WebRTC 的桌面浏览器。 最后，我们有一个文件输入，提示用户在手机上进行录制。 - -## 您是否考虑过其他解决方案？ 如果是，还有哪些其他选择？ 如何决定使用 Lambda？ - -是的，一点没错。 我们的常规堆栈是 LAMP，构建在 CloudFront，Elastic Load Balancer 和 EC2 节点之上。 这本来可以扩展，但要像使用基于 Lambda 的体系结构一样快速和简单地扩展，则要困难得多。 我们必须构建一个用于生成图像的排队系统，然后启动专用于根据吞吐量制作这些图像的 EC2 节点。 - -编写简单的 Lambda 函数并让 Amazon 进行所有艰苦的工作似乎是显而易见的选择。 - -## 团队有多大？ 是否有/已经有过 Lambda 的经验，或者他们来自其他专业领域？ - -Parallax 的团队由五人组成。 Tom Faller 是客户经理，负责项目的日常运行。 我是后端开发人员，创建 Lambda 函数并设计云架构。 阿米特·辛格（Amit Singh）主要是前端，但是从事接口和后端 JS 之间的许多粘合部分的工作。 克里斯·米尔斯（Chris Mills）是质量保证和系统部门的负责人，并首先链接到无服务器（以前的 JAWS）项目。 杰米·塞夫顿（Jamie Sefton）是另一位 JS 开发人员，致力于将兼容性后备功能集成到代码库中，包括基于 Flash 和基于输入的录制体验，作为不支持 WebRTC 的设备的后备功能。 我以前有过 Lambda 的经验，但这对其他团队成员来说是新的。 - -## 您花了多长时间开发应用程序？ 它比在其他框架中编写要快吗？ （Express，Rails，无论您的“家庭草皮”是什么） - -我总共要花大约 6 到 7 周的时间，尽管事先进行了大量的研究和原型设计才能得出正确的架构设计。 对于所需的可伸缩性，要使用我们的“家用草皮”确保它具有同等的健壮性，将花费更长的时间。 - -## 您如何部署应用程序？ 您是否正在使用 CI / CD 服务？ - -该应用程序是从 Atlassian Bamboo 部署的。 该代码库位于 Stash 中。 每个分支机构都有自己的部署 URL，一旦构建，该 URL 就会发布到我们公司的聊天室中。 这使我们可以快速测试并确定更改是否可合并。 - -![](img/5177e2e28bb1cbbec46a27665baaf30d.png) *图片来源：Parallax Agency Ltd.* - -## 您有什么监控？ 您有什么要监视但不需要/无法监视的东西吗？ - -对于前端 JS 错误，我们使用 Bugsnag。 对于这种类型的应用程序，这是查看堆栈中是否存在问题的最简单方法。 如果错误峰值大于流量峰值，您就会知道有些问题。 我们通常将 NewRelic 用于后端，但是由于所有后端代码都存在于 Lambda 函数中，因此我们选择使用 CloudWatch。 - -## 在变更投入生产之前，您如何进行测试？ 您有测试/暂存环境吗？ - -是的，绝对是。 推送到 Stash 的每个提交和分支都部署到测试环境。 对于静态资产和前端 JavaScript，它使用 Bamboo，并为每个分支和内部版本号创建一个新文件夹。 对于 lambda 函数，已使用`serverless dash`将其更新到每个环境。 - -## 一路上有什么让您感到惊讶的吗？ 某些任务比您预期的要难还是难？ - -运行 Lambda 的服务器上缺少日文和中文字符的字体，这是可以预料的，但是这并不是我们在开发中计划的。 当操作系统呈现特定字体并且不包含特定字形时，它将回退到系统安装的多语言 Unicode 字体。 这会自动在网络上发生，但是在裸机上的 ImageMagick 内部不会发生。 这意味着我们必须在端点中附带大型 Unicode 字体。 通过仅将非拉丁名称路由到 Unicode 端点，我们减少了此功能对性能的影响。 - -例如， ![](img/249dd8900f5f6134ce3c1e95b92ef84f.png) Helvetica 不包含任何亚洲字形 ![](img/3f89d75ac2597987a5e6caa97f2d2c46.png) - -## 您发现开发过程中有痛点吗？您想如何解决它们？ - -多个分支机构和早期的无服务器（以前的 JAWS）框架存在一些问题。 假设我们要在一个分支中添加一个端点，而在另一个分支中添加另一个端点，则不能将它们都部署到同一环境阶段。 这是我们正在努力解决的问题，我们将寻求为 Serverless 提供一些有用的工具来解决此问题。 - -## 您是否想找到让更多人了解的特别有用的工具或库？ - -我强烈建议您使用几种测试工具。 相机和麦克风在仿真器中的行为有很大不同-有时甚至根本没有仿真！ 这意味着我们必须使用真实的设备进行测试。 我们使用了 [Vanamco 设备实验室](https://www.vanamco.com/devicelab/)以及五个我们认为是很好的传播设备。 我们将其与 Ghostlab 一起使用，这使我们能够在所有设备上打开同一页面，并使它们保持同步。 它包括一个 Web 检查器，用于调整 CSS 并运行调试 JS。 然后，为了增加 Android 覆盖率，我们使用了 [testdroid](http://testdroid.com/) 。 这是一项出色的服务，可让您远程使用真实设备。 打开相机应用程序，您可以在数据中心内看到。 我一直在热切地等待着一个测试机器人工程师，将他的头戳进架子，但是到目前为止，我感到失望！ - -![](img/0fd1ee681f8dc2526e711343f7f73c05.png) * Testdroid 使用 Google Nexus 10* - -# 包起来 - -再次感谢 James Hall 提供有关所有 Lambda 后端的 CI，移动测试和 Unicode 解决方法的内部视图。 要了解有关无服务器应用程序框架的更多信息，请查看其[网站](http://serverless.com)或 [gitter.im 聊天室](https://gitter.im/serverless/serverless)。 - -**披露：**我与 Parallax Agency Ltd.没有关系，但是他们建立了很酷的项目，而这次采访只涉及其中一个。 - -订阅[无服务器代码邮件列表](https://serverlesscode.com/mail/)，以跟上以后的帖子。 如果您有任何建议，问题或意见，请通过 [[受电子邮件保护]](/cdn-cgi/l/email-protection#7b171a16191f1a3b09021a15081955181416) 给我发送电子邮件。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=10955158) \ No newline at end of file +# Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求 + +> 原文： [http://highscalability.com/blog/2011/2/15/wordnik-10-million-api-requests-a-day-on-mongodb-and-scala.html](http://highscalability.com/blog/2011/2/15/wordnik-10-million-api-requests-a-day-on-mongodb-and-scala.html) + +![](img/c71648a7f74b646cf7cc4c270f00b751.png) + +[Wordnik](http://www.wordnik.com/) is an online dictionary and language resource that has both a website and an API component. Their goal is to *show you as much information as possible, as fast as we can find it, for every word in English, and to give you a place where you can make your own opinions about words known.* As cool as that is, what is really cool is the information they share in their [blog](http://blog.wordnik.com/) about their experiences building a web service. They've written an excellent series of articles and presentations you may find useful: + +* [最近使用](http://blog.wordnik.com/what-has-technology-done-for-words-lately) ne 的技术是什么？ + * **最终一致性**。 使用最终一致的模型，他们可以并行工作，*我们会尽可能地统计尽可能多的单词，并在出现滞后时将它们加起来。 计数总是在球场上，我们永远不必停止* .D + * **面向文档的存储**。 字典条目更自然地建模为分层文档，使用该模型可以更快地找到数据，并且更易于开发。 +* [与 MongoDB 合作 12 个月](http://blog.wordnik.com/12-months-with-mongodb) + * 迁移到 MongoDB 的主要驱动因素是性能。 MySQL 不适用于他们。 + * Mongo 平均每小时处理 50 万个请求。 高峰流量是该流量的 4 倍。 + * > Mongo 中有 120 亿个文档，每个节点的存储量约为 3TB + * 可以轻松维持 8k 文档/秒的插入速度，经常达到 50k /秒 + * 一个 Java 客户端可以维持通过后端（千兆位）网络读取到一个 mongod 的 10MB / sec 的速度。 来自同一客户端的四个读取器通过同一管道以每秒 40MB 的速度传输 + * 每种类型的检索都比 MySQL 实现快得多： + * 示例提取时间从 400ms 减少到 60ms + * 字典条目从 20ms 到 1ms + * 文档元数据从 30 毫秒到.1 毫秒 + * 拼写建议从 10 毫秒到 1.2 毫秒 + * Mongo 的内置缓存使他们可以删除 memcached 层并将呼叫速度提高 1-2ms。 +* [从 MySQL 到 MongoDB-迁移到实时应用程序](http://www.slideshare.net/fehguy/migrating-from-mysql-to-mongodb-at-wordnik)作者：Tony Tam + * 他们从 MySQL 迁移到 MongoDB 的经历的解释。 + * Wordnik 存储单词，层次结构数据和用户数据的语料库。 MySQL 设计要复杂得多，并且需要复杂的缓存层才能良好地运行。 使用 MongoDB，系统速度提高了 20 倍。 现在不再需要连接，也不需要缓存层。 整个系统更加简单。 + * Wordnik 主要是一个只读系统，并且性能主要受磁盘速度限制。 + * 他们使用具有 72GB 内存的双四核 2.4GHz 英特尔 CPU。 它们是物理服务器，处于主从模式，并且在 DAS 上使用 5.3TB LUN。 他们发现虚拟服务器没有所需的 IO 性能。 +* [通过 MongoDB 保持亮灯](http://www.slideshare.net/fehguy/mongo-sv-tony-tam)作者：Tony Tam + * 关于他们如何使用和管理 MongoDB 的演示。 +* [Wordnik API](http://blog.wordnik.com/wordnik-api-has-gone-beta) + * 他们已经在 Scala 中重写了 REST API。 Scala 帮助他们删除了很多代码，并在整个 API 中标准化了“特征”。 +* [](http://blog.wordnik.com/wordnik-api-has-gone-beta)[MongoDB 管理工具](http://blog.wordnik.com/mongoutils) + * Wordnik 已经构建了一些工具来管理 MongoDB 的大型部署并已开源。 +* [Wordnik 克服了 Hadoop 的处理瓶颈](http://www.cloudera.com/blog/2011/02/wordnik-bypasses-processing-bottleneck-with-hadoop/) + * 每秒增加 8000 个单词。 + * Map-reduce 作业在 Hadoop 上运行，以减轻 MongoDB 的负担并防止任何阻塞查询。 数据仅是追加数据，因此没有理由使用 MongoDB。 + * 其数据的增量更新存储在平面文件中，该文件定期导入 HDFS。 + +Overall impressions: + +* Wordnik 有一个非常具体的问题要解决，并着手寻找可以帮助他们解决该问题的最佳工具。 他们愿意围绕发现的所有错误进行编码，并弄清楚如何使 MongoDB 最适合他们。 性能要求推动了一切。 +* 在获得性能之后，文档数据模型的自然性似乎是他们最大的胜利。 轻松地对复杂数据进行分层建模并使其表现良好的能力在整个系统中得到了体现。 +* 现在的代码是：更快，更灵活且更小。 +* 他们选择了专门的工具来完成这项工作。 MongoDB 负责运行时数据的文档存储。 Hadoop 负责分析，数据处理，报告和基于时间的聚合。 + +Definitely an experience report worth keeping an eye on. + +据我所知，Wordnik 是一个只读的应用程序，不需要太多的一致性。 如文章中所述，“他们有一个特定的问题”。 NoSQL 迷们，请不要简单地使用它来攻击 MySQL。 :-) + +高峰使用率为 2M req / hr。 + +只需 550 req / sec。 真的不是那么多。 我已经看到 MySQL 的吞吐量要比那高得多。 + +如果他们甚至不能使 MySQL 仅执行 550 req / sec，我敢打赌他们只是设计不好的数据库 + +@John，我们在 mysql 上遇到的问题是大量读取和写入的结合。 结合 550 req / sec + 8k 插入/ sec，方程式将发生巨大变化。 + +我已经说过很多次了，很可能有人已经调整了我们的 mysql 部署来支持这一点。 我们使用 mongodb 轻松地自己完成了此操作，并且在此过程中获得了许多巨大的好处，如博客文章所述。 + +它不是读 500k / s 而不是 500 / s 吗？ \ No newline at end of file diff --git a/docs/59.md b/docs/59.md index 0b4ea46..4b92561 100644 --- a/docs/59.md +++ b/docs/59.md @@ -1,533 +1,60 @@ -# 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南 +# Node.js 成为堆栈的一部分了吗？ SimpleGeo 说是的。 -> 原文： [http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html](http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html) +> 原文： [http://highscalability.com/blog/2011/2/22/is-nodejs-becoming-a-part-of-the-stack-simplegeo-says-yes.html](http://highscalability.com/blog/2011/2/22/is-nodejs-becoming-a-part-of-the-stack-simplegeo-says-yes.html) -![](img/112a6398214f12a2ed4f02148dcfc30f.png) +![](img/1ff747da24156c99060dda1b8dbd71b3.png) -您如何将系统从一个用户扩展到超过 1100 万用户？ [Joel Williams](https://www.linkedin.com/in/joel-williams-70257b7) ，亚马逊网络服务解决方案架构师，就该主题发表了精彩的演讲： [AWS re：Invent 2015 扩展到您的前 1000 万用户](https://www.youtube.com/watch?v=vg5onp8TU6Q&list=PLhr1KZpdzukdRxs_pGJm-qSy5LayL6W_Y)。 +这是对 [SimpleGeo](http://simplegeo.com/) 的基础架构工程师 Wade Simmons 的采访，这项服务使*易于开发人员根据[节点的使用情况轻松创建位置感知应用程序](http://nodejs.org/)*。 js 作为后端服务组件，取代了一次用 Java，Python 或 Ruby 编写的代码。 这些天，Node.js 发现它进入了很多堆栈，我很好奇为什么会这样。 我在编写多个消息传递系统时的经验是，程序员不喜欢异步模型，而像 Node.js 这样的纯异步编程模型（尤其是使用服务器端 Javascript 的异步编程模型）将脱颖而出，这真是令人惊讶。 韦德（Wade）足够慷慨地帮助他们解释在 SimpleGeo 使用 Node.js 的背后原因。 我非常感谢 Wade 抽出宝贵时间接受采访。 他做得非常出色，并为现代 Web 堆栈如何在现实生活的坩埚中发展提供了很多见识。 -如果您是 AWS 的高级用户，那么本演讲不适合您，但是如果您是 AWS 的新手，云的新手或的入门者，那么这是上手的好方法 不断涌现的新功能 Amazon 不断涌现。 +从这里开始对韦德·西蒙斯的采访： -正如您可能期望的那样，由于这是 Amazon 的一次讲话，因此 Amazon 服务始终是解决任何问题的中心。 他们的平台表现令人印象深刻且具有启发性。 通过将各个部分组合在一起，很明显，亚马逊在确定用户需求并确保他们拥有该领域的产品方面做得非常出色。 +从一开始，在 SimpleGeo，我们一直是事件驱动，无阻塞网络服务器的粉丝。 我们的核心 API 服务器是用 Python 编写在 Tornado Web 服务器（ [http://www.tornadoweb.org](http://www.tornadoweb.org) /）之上的。 我们也有使用 Twisted 编写的内部服务器（ [http://twistedmatrix.com/](http://twistedmatrix.com/) ）。 当您的服务器将主要是与 IO 绑定时，事件驱动框架非常有意义，并且我们的许多内部服务基本上都是围绕不同类型的索引和数据库进行包装的。 -一些有趣的外卖： +您可能想知道为什么我们已经在其他人中开发和部署了代码之后，为什么现在要尝试基于事件的不同框架呢？ 答案是我们希望 Node.js 可以避免的其他框架存在一些缺点。 -* 从 SQL 开始，仅在必要时移至 NoSQL。 -* 一致的主题是将组件分离出来。 这使这些组件可以独立扩展和失败。 它适用于拆分层并创建微服务。 -* 仅投资于使您的企业与众不同的任务，不要重蹈覆辙。 -* 可伸缩性和冗余不是两个独立的概念，您通常可以同时进行。 -* 没有提及费用。 这将是演讲的一个很好的补充，因为这是对 AWS 解决方案的主要批评之一。 +### 未设计为异步的语言将阻塞 -## 基础知识 +龙卷风的主要问题是图书馆的支持。 Tornado 提供了一个非阻塞的 HTTP 客户端，但是对其他协议的支持是有限的或不存在的。 这意味着很容易尝试使用大量可用于 Python 的库。 一旦发生这种情况，您将不可避免地开始阻止事件线程，并且到服务器的并发连接将开始彼此阻塞。 这意味着您遇到了两个世界中最糟糕的一个：单线程服务器，没有任何潜在的好处。 -* AWS 在全球 12 个地区中。 +### Twisted 与 Python 的配合不佳 - * 区域是世界上亚马逊具有多个可用区的物理位置。 中有 [地区：北美； 南美洲; 欧洲; 中东; 非洲; 亚太地区。](https://aws.amazon.com/about-aws/global-infrastructure/) +Python 的 Twisted 框架具有更好的库支持，因为已经为其实现了许多协议。 没有我们想要的那样广泛的支持，但是至少它比龙卷风要好得多。 不过，SimpleGeo 上的很多人都不是 Twisted 的粉丝，因为它与 Python 的其余部分无法很好地融合在一起。 例如，方法的命名约定为驼峰式，而不是 python 标准的“带下划线的小写”。 Twisted 的学习曲线也可能更陡峭，因为可以在网上找到更少的示例（尽管确实存在的示例非常好，并且也有一些好书）。 - * 可用区（AZ）通常是单个数据中心，尽管它们可以由多个数据中心构成。 +### 协作多任务模型更易于调试 - * 每个可用区都足够独立，因此它们具有独立的电源和 Internet 连接。 +我们还考虑了协程库，例如 Eventlet（ [http://eventlet.net/](http://eventlet.net/)）。 在 SimpleGeo 中有很多关于协作多任务或协程是否是更好的样式的争论。 决定继续使用 Node.js 的团队喜欢协作方法，因为它使调试并发问题更容易测试。 您确切地知道您的程序将控制权交给其他任务，因此追踪与共享状态有关的问题要容易得多。 - * 可用区之间的唯一连接是低延迟网络。 例如，可用区可以相隔 5 或 15 英里。 网络足够快，您的应用程序就可以像所有可用区都在同一个数据中心中一样工作。 +### 异步浏览器体验正在转移到服务器 - * 每个区域至少有两个可用区。 共有 32 个可用区。 +我认为 Node.js 受到青睐的主要原因之一是人们已经习惯了 JavaScript 的异步编程风格。 即使是主要从事后端工作的程序员也可能会不时地涉足客户端 JavaScript。 JavaScript 并不是完美的语言，但是它的功能却比大多数更好，并且有许多文献记载的方法可以避免它的陷阱。 离开浏览器世界后，不必再担心向后兼容性，美好的事物就会开始闪耀。 - * 使用可用区可以为您的应用程序创建高可用性架构。 +### 主要用作服务之间的胶水 - * 2016 年将至少有 9 个可用区和 4 个地区。 +当前，Node.js 的主要用途是作为 API 的入口点。 我们有许多不同的内部服务器，我们不同的 API 端点需要为每个请求命中一个或多个。 Node.js 服务器进行身份验证，发出并行内部请求，然后将结果合并为请求的输出格式。 该服务器还负责记录统计信息并记录详细的请求信息以供以后解析。 -* AWS 在全球拥有 53 个边缘位置。 +### 易于调试，测试和良好表现 - * 边缘位置由 Amazon 的内容分发网络（CDN）CloudFront 和 Amazon 的托管 DNS 服务器 Route53 使用。 +到目前为止，我们的经验是编写 Node.js 代码非常直观并且易于测试。 生产部署非常稳定，我们还没有出现内存泄漏问题或使用如此年轻的平台（敲敲敲打）会遇到的其他问题。 我们计划在内部将 Node.js 用于我们框架的其他一些“胶合”样式； 主要充当后端和客户端之间的路由器/转换器的组件。 这些是已经或将要用 Tornado / Twisted 用 Pyt​​hon 编写的组件。 Python 在我们的堆栈中仍然有很多用途，但是随着我们对它的适应程度不断提高，Node.js 开始渗透。 - * 边缘位置使用户无论身在何处都可以以极低的延迟访问内容。 +### Node.js 没有计划实现 CPU 密集型服务 -* 构建基块服务 +我们没有计划在 Node.js 中做任何占用大量 CPU 的工作。 我们正在 Cassandra 之上使用 Java 进行数据库层的开发，我们暂时可能会坚持使用它。 我们正在那里而不是在远程网络服务器上实施空间逻辑，因此我们可以在数据旁边进行尽可能多的处理。 我不相信对 v8 中的内存模型有足够的控制权（某些数据结构实际上可能是肿的），无法完成诸如 Node.js 中的数据库这样的密集型操作。 - * AWS 创建了许多服务，这些服务在内部使用多个可用区来实现高可用性和容错能力。 [是其中](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) [提供哪些服务的列表](http://docs.aws.amazon.com/general/latest/gr/rande.html) ，其中 可用。 +### 代码由 SimpleGeo 提供 - * 您可以付费在应用程序中使用这些服务，而不必担心使它们自己高度可用。 +尽管 Node.js 还很年轻，但社区发展非常迅速，在 github 和 npm（Node 包管理器）上可以找到大量的库。 SimpleGeo 喜欢开源，因此当我们发现缺少或缺少的图书馆时，请确保释放所有改进，以便其他人可以使用它们。 - * 可用区内存在的一些服务：CloudFront，Route 53，S3，DynamoDB，弹性负载平衡，EFS，Lambda，SQS，SNS，SES，SWF。 +从我们的工作中创建的一些库示例： - * 即使服务位于单个 AZ 中，也可以使用服务创建高可用的体系结构。 +* [https://github.com/wadey/node-thrift](https://github.com/wadey/node-thrift) +* [https://github.com/wadey/node-microtime](https://github.com/wadey/node-microtime) +* [https://github.com/wadey/decimaljson](https://github.com/wadey/decimaljson) -## 1 个用户 +在 [https://github.com/simplegeo](https://github.com/simplegeo) 上可以找到更多内容。 -* 在这种情况下，您是唯一的用户，并且您要运行一个网站。 +## 相关文章 -* 您的架构将类似于： +* Quora： [SimpleGeo 的 API 平台使用哪种语言编码？](http://www.quora.com/What-language-is-SimpleGeos-API-platform-coded-in/answer/Joe-Stump) +* [HackerNews 线程](http://hackerne.ws/item?id=2251490) - * 在单个实例上运行，可能是 [t2.micro](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html) 类型。 实例类型包括 CPU，内存，存储和网络容量的各种组合，使您可以灵活地为应用程序选择适当的资源组合。 - - * 一个实例将运行整个 [Web 堆栈]( http://whatis.techtarget.com/definition/Web-stack) ，例如：Web 应用程序，数据库，管理等。 - - * 将 Amazon [路由 53](https://aws.amazon.com/route53/) 用作 DNS。 - - * 将单个 [弹性 IP](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) 地址附加到实例。 - - * 运作良好，持续了一段时间。 - -## 垂直缩放 - -* 您需要一个更大的盒子。 最简单的扩展方法是选择更大的实例类型。 例如，也许 [c4.8xlarge](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/c4-instances.html) 或 [m3.2xlarge](https://aws.amazon.com/ec2/instance-types/) 。 - -* 这种方法称为 [垂直缩放](https://en.wikipedia.org/wiki/Scalability) 。 - -* 只需停止实例并选择一种新的实例类型，您就可以以更高的功率运行。 - -* 有多种不同的硬件配置可供选择。 您可以拥有一个带有 244 GB RAM 的系统（即将推出 2TB RAM 类型）。 或一个 40 核。 有高 I / O 实例，高 CPU 实例，高存储实例。 - -* 某些 Amazon 服务随附 [预置 IOPS](http://serverfault.com/questions/580568/amazon-how-do-i-know-if-i-need-provisioned-iops) 选项，以确保性能。 这个想法是，您也许可以为服务使用较小的实例类型，并利用 DynamoDB 之类的 Amazon 服务来提供可扩展的服务，因此您不必这样做。 - -* 垂直扩展存在一个大问题：没有故障转移，也没有冗余。 如果实例出现问题，则您的网站将死亡。 你所有的鸡蛋都放在一个篮子里。 - -* 最终，单个实例只能变得如此之大。 您需要做其他事情。 - -## 用户> 10 - -* 将单个 主机分离为多个主机 - - * 该网站的主机。 - - * 数据库的一台主机。 运行所需的任何数据库，但是您需要进行数据库管理。 - - * 使用单独的主机可以使网站和数据库彼此独立地扩展。 例如，也许您的数据库将需要比网站更大的计算机。 - -* 或者，也可以使用数据库服务代替运行自己的数据库。 - - * 您是数据库管理员吗？ 您真的要担心备份吗？ 高可用性？ 补丁？ 操作系统？ - - * 使用服务的一大优势在于，您只需单击即可设置多个可用区数据库。 您无需担心复制或任何此类事情。 您的数据库将高度可用且可靠。 - -* 您可能会想像到亚马逊有几项完全托​​管的数据库服务可以卖给您： - - * [Amazon RDS](https://aws.amazon.com/rds/) （关系数据库服务）。 有很多选项：Microsoft SQL Server，Oracle，MySQL，PostgreSQL，MariaDB，Amazon Aurora。 - - * [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 。 NoSQL 管理的数据库。 - - * [Amazon Redshift](https://aws.amazon.com/redshift/) 。 PB 级数据仓库系统。 - -* 更多 [Amazon Aurora](https://aws.amazon.com/rds/aurora/) ： - - * 自动存储扩展到 64TB。 您不再需要为数据配置存储。 - - * 最多 15 个读只读副本 - - * 连续（增量）备份到 S3。 - - * 跨 3 个 AZ 进行 6 向复制。 这可以帮助您处理故障。 - - * MySQL 兼容。 - -* 从 SQL 数据库而不是 NoSQL 数据库开始。 - - * 建议从 SQL 数据库开始。 - - * 该技术已建立。 - - * 有很多现有的代码，社区，支持小组，书籍和工具。 - - * 您不会破坏前 1000 万用户的 SQL 数据库。 差远了。 （除非您的数据很大）。 - - * 清晰的模式可扩展。 - -* 您何时需要从 NoSQL 数据库开始？ - - * 如果您需要在第一年存储 5 TB 的>数据，或者您的数据处理工作量非常大。 - - * 您的应用程序具有超低延迟要求。 - - * 您需要非常高的吞吐量。 您需要真正调整在读取和写入中都得到的 IO。 - - * 您没有任何关系数据。 - -## 用户> 100 - -* 将 单独的主机用于 Web 层 。 - -* 将 数据库存储在 Amazon RDS 上。 它照顾一切。 - -* 这就是您要做的。 - -## 用户> 1000 - -* 按照架构，您的应用程序存在可用性问题。 如果您的 Web 服务主机出现故障，则您的网站将关闭。 - -* 因此，您 在另一个可用区 中需要另一个 Web 实例。 可以，因为 AZ 之间的等待时间只有几位毫秒，几乎就像它们彼此相邻一样。 - -* 您还需要一个 从属数据库到在另一个 AZ 中运行的 RDS 。 如果主服务器有问题，您的应用程序将自动切换到从属服务器。 故障转移无需对应用程序进行任何更改，因为您的应用程序始终使用相同的端点。 - -* 弹性负载均衡器（ELB）已添加到配置中，以在两个可用区中的两个 Web 主机实例之间负载均衡用户。 - -* 弹性负载平衡器（ELB）： - - * ELB 是高度可用的托管负载均衡器。 ELB 存在于所有可用区中。 它是您的应用程序的单个 DNS 终结点。 只需将其放在 Route 53 中，它将在您的 Web 主机实例之间实现负载平衡。 - - * ELB 具有运行状况检查，以确保流量不会流向发生故障的主机。 - - * 无需任何操作即可缩放。 如果看到额外的流量，它将在水平和垂直方向上扩展到幕后。 您不必管理它。 随着应用程序规模的扩展，ELB 也随之扩展。 - -## 用户> 10,000s-100,000s - -* 先前的配置在 ELB 后面有 2 个实例，实际上，您可以在 ELB 后面有 1000 个实例。 这是 [水平缩放](https://en.wikipedia.org/wiki/Scalability) 。 - -* 您需要向数据库和 RDS 添加更多只读副本。 这将减轻写主机的负担。 - -* 通过将 通过将一些流量转移到其他地方来减轻 Web 层 服务器的负载，从而考虑性能和效率。 将 Web 应用程序中的静态内容移动到 Amazon S3 和 Amazon CloudFront。 CloudFront 是 Amazon 的 CDN，可将您的数据存储在全球 53 个边缘位置。 - -* Amazon S3 是对象库。 - - * 它与 EBS 不同，它不是连接到 EC2 实例的存储，而是对象存储，而不是块存储。 - - * 这是存储静态内容（如 javascript，css，图像，视频）的好地方。 此类内容无需位于 EC2 实例上。 - - * 高度耐用，可靠性 11 9。 - - * 无限扩展，可根据需要抛出尽可能多的数据。 客户在 S3 中存储多个 PB 的数据。 - - * 支持最大 5TB 的对象。 - - * 支持加密。 您可以使用 Amazon 的加密，您的加密或加密服务。 - -* Amazon CloudFront 缓存了您的内容。 - - * 它在边缘位置缓存内容，以为用户提供尽可能低的延迟访问。 - - * 如果没有 CDN，您的用户将遇到对您的内容的更高延迟访问。 您的服务器在提供内容以及处理 Web 请求时也将承受更高的负载。 - - * 一位客户需要以 60 Gbps 的速度提供内容。 网络层甚至都不知道这是怎么回事，CloudFront 处理了所有事情。 - -* 您还可以通过将会话状态移出 Web 层来减轻负载。 - - * 将会话状态存储在 [ElastiCache](https://aws.amazon.com/elasticache/) 或 DynamoDB 中。 - - * 这种方法还可以设置系统以支持将来的自动缩放。 - -* 您还可以通过将数据从数据库缓存到 ElastiCache 中来减轻负载。 - - * 您的数据库不需要处理所有数据获取。 缓存可以处理很多工作，而数据库则可以处理更重要的流量。 - -* Amazon DynamoDB-托管的 NoSQL 数据库 - - * 您可以配置所需的吞吐量。 您可以提高要支付的读写性能。 - - * 支持快速，可预测的性能。 - - * 完全分布式且具有容错能力。 它存在于多个可用区中。 - - * 这是一个键值存储。 支持 JSON。 - - * 支持最大 400KB 的文档。 - -* Amazon Elasticache-托管的 Memcached 或 Redis - - * 管理内存缓存集群并不能为您带来更多收益，因此让 Amazon 为您做到这一点。 那就是球场。 - - * 将自动为您缩放群集。 这是一种自我修复的基础架构，如果节点发生故障，则会自动启动新节点。 - -* 您还可以通过将动态内容转移到 CloudFront 来减轻负载。 - - * 许多人都知道 CloudFront 可以处理静态内容（例如文件），但也可以处理一些动态内容。 谈话中没有进一步讨论该主题，但这里的 [链接](https://aws.amazon.com/cloudfront/dynamic-content/) 。 - -## [自动缩放](https://aws.amazon.com/autoscaling/) - -* 如果您提供足够的容量来始终处理高峰流量，例如黑色星期五，那是在浪费钱。 将计算能力与需求匹配起来会更好。 这就是 Auto Scaling 的工作，即自动调整计算群集的大小。 - -* 您可以定义池的最小和最大大小。 作为用户，您可以确定集群中最少的实例数和最多的实例数。 - -* [CloudWatch](https://aws.amazon.com/cloudwatch/) 是一项管理服务，已嵌入到所有应用程序中。 - - * CloudWatch 事件驱动扩展。 - - * 您要扩展 CPU 使用率吗？ 您要扩展延迟吗？ 在网络流量上？ - - * 您也可以将自己的自定义指标推送到 CloudWatch。 如果要按特定的应用程序扩展，可以将该指标推送到 CloudWatch，然后告诉 Auto Scaling 您要按该指标扩展。 - -## 用户> 500,000+ - -* 从先前配置中添加的是 [自动缩放组](http://docs.aws.amazon.com/gettingstarted/latest/wah/getting-started-create-as.html) 已添加到 Web 层 。 自动缩放组包括两个 AZ，但可以扩展到 3 个 AZ，最多可以位于同一区域。 实例可以在多个可用区中弹出，不仅是为了实现可伸缩性，还在于可用性。 - -* 该示例在每个可用区中都有 3 个 Web 层实例，但可能是数千个实例。 您可以说您要最少 10 个实例，最多 1000 个实例。 - -* ElastiCache 用于卸载数据库中的流行读取。 - -* DynamoDB 用于卸载会话数据。 - -* 您需要添加监视，指标和日志记录。 - - * 主机级别指标。 查看自动扩展组中的单个 CPU 实例，找出问题所在。 - - * 聚合级别指标。 查看 Elastic Load Balancer 上的指标，以了解整个实例集的性能。 - - * 日志分析。 查看应用程序使用 [CloudWatch](https://aws.amazon.com/about-aws/whats-new/2014/07/10/introducing-amazon-cloudwatch-logs/) 日志告诉您什么。 [CloudTrail](https://aws.amazon.com/cloudtrail/) 可帮助您分析和管理日志。 - - * 外部站点性能。 了解您的客户看到的最终用户。 使用新遗物或 Pingdom 之类的服务。 - -* 您需要知道客户在说什么。 他们的延迟不好吗？ 他们转到您的网页时会收到错误消息吗？ - -* 尽可能从配置中压缩性能。 Auto Scaling 可以提供帮助。 您不希望 CPU 使用率达到 20％的系统。 - -## 自动化 - -* 基础架构越来越大，可以扩展到数千个实例。 我们已经阅读过副本，可以水平缩放，但是我们需要一些自动化来帮助管理所有内容，我们不想管理每个实例。 - -* 自动化工具具有层次结构。 - - * 自己做 ：Amazon EC2，AWS CloudFormation。 - - * 更高级别的服务 ：AWS Elastic Beanstalk，AWS OpsWorks - -* [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) ：自动管理应用程序的基础架构。 这很方便，但没有太多控制权。 - -* [AWS OpsWorks](https://aws.amazon.com/opsworks/) ：一个在其中分层构建应用程序的环境，您可以使用 Chef 食谱来管理应用程序的层。 - - * 还使您能够进行持续集成和部署。 - -* [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ：使用时间最长。 - - * 提供了最大的灵活性，因为它提供了堆栈的模板化视图。 它可以用于构建整个堆栈或仅堆栈的组件。 - - * 如果要更新堆栈，请更新 Cloud Formation 模板，它将仅更新应用程序的这一部分。 - - * 有很多控制权，但不太方便。 - -* [AWS CodeDeploy](https://aws.amazon.com/codedeploy/) ：将代码部署到一组 EC2 实例。 - - * 可以部署到一个或数千个实例。 - - * 代码部署可以指向自动扩展配置，因此代码可以部署到一组实例。 - - * 也可以与 Chef 和 Puppet 结合使用。 - -## 解耦基础架构 - -* 使用 [SOA](https://en.wikipedia.org/wiki/Service-oriented_architecture) / [微服务](http://techblog.netflix.com/2015/02/a-microscope-on-microservices.html) 。 从您的层中取出组件并将它们分开。 创建单独的服务 ，就像将 Web 层与数据库层分开一样。 - -* 然后可以独立扩展各个服务。 这为扩展和高可用性提供了很大的灵活性。 - -* SOA 是 Amazon 构建的架构的关键组成部分。 - -* 松耦合使您自由。 - - * 您可以分别缩放组件和使组件失败。 - - * 如果工作程序节点无法从 SQS 提取工作，这有关系吗？ 不，只是开始另一个。 事情将会失败，让我们建立一个处理失败的架构。 - - * 将所有内容设计为黑匣子。 - - * 解耦交互。 - - * 支持具有内置冗余和可伸缩性的服务，而不是自己构建。 - -## 不要重新发明轮子 - -* 仅投资于使您的业务与众不同的任务。 - -* 亚马逊拥有许多固有的容错服务，因为它们跨越多个可用区。 例如：排队，电子邮件，代码转换，搜索，数据库，监视，指标，日志记录，计算。 您不必自己构建这些。 - -* [SQS](https://aws.amazon.com/sqs/) ：排队服务。 - - * 提供的第一个 Amazon 服务。 - - * 它跨越多个可用区，因此具有容错能力。 - - * 它具有可扩展性，安全性和简单性。 - - * 排队可以通过帮助您在基础结构的不同组件之间传递消息来帮助您的基础结构。 - - * 以 Photo CMS 为例。 收集照片并对其进行处理的系统应该是两个不同的系统。 他们应该能够独立扩展。 它们应该松耦合。 摄取照片并将其放入队列中，工作人员可以将照片从队列中拉出并对其进行处理。 - -* [AWS Lambda](https://aws.amazon.com/lambda/) ：您可以在不配置或管理服务器的情况下运行代码。 - - * 出色的工具，可让您解耦应用程序。 - - * 在 Photo CMS 示例中，Lambda 可以响应 S3 事件，因此，当添加 S3 文件时，将自动触发要处理的 Lambda 函数。 - - * 我们已经取消了 EC2。 它可以为您进行扩展，并且无需管理任何操作系统。 - -## 用户> 1,000,000+ - -* 要达到一百万个以上的用户，则需要满足以上所有条件： - - * 多可用区 - - * 层之间的弹性负载平衡。 不仅在 Web 层上，而且在应用程序层，数据层和您拥有的任何其他层上。 - - * 自动缩放 - - * 面向服务的体系结构 - - * 使用 S3 和 CloudFront 巧妙地服务内容 - - * 将缓存放在数据库前面 - - * 将状态移出 Web 层。 - -* 使用 [Amazon SES](https://aws.amazon.com/ses/) 发送电子邮件。 - -* 使用 CloudWatch 进行监视。 - -## 用户> 10,000,000+ - -* 随着规模的扩大，我们会遇到数据层的问题。 与 [写入主机](https://en.wikipedia.org/wiki/Multi-master_replication) 争用时，您的数据库可能会遇到问题。 。 - -* 您如何解决？ - - * 联盟 - - * 分片 - - * 将某些功能移至其他类型的数据库（NoSQL，图形等） - -* 联合身份验证-基于功能分为多个 DB - - * 例如，创建一个论坛数据库，一个用户数据库，一个产品数据库。 您以前可能将它们放在单个数据库中，现在将它们分发出去。 - - * 不同的数据库可以彼此独立地扩展。 - - * 缺点：您无法进行跨数据库查询； 这会延迟进入下一个分片策略。 - -* 分片-在多个主机之间拆分一个数据集 - - * 在应用层更加复杂，但是对可伸缩性没有实际限制。 - - * 例如，在用户数据库中，用户的⅓可能会发送到一个分片，最后三分之一发送到另一个分片，另一个分片发送到另外三分之一。 - -* 将某些功能移至其他类型的数据库 - - * 开始考虑 NoSQL 数据库。 - - * 如果您的数据不需要排行榜，例如排行榜，快速获取点击流/日志数据，临时数据，热点表，元数据/查找表，则可以考虑将其移至 NoSQL 数据库。 - - * 这意味着它们可以彼此独立缩放。 - -## 用户> 1100 万 - -* 缩放是一个迭代过程。 随着您变得更大，总会有更多您可以做。 - -* 微调您的应用程序。 - -* 更多 SOA 的功能/特性。 - -* 从多可用区转到多区域。 - -* 开始构建自定义解决方案，以解决您以前从未有人做过的特定问题。 如果您需要为十亿客户提供服务，则可能需要定制解决方案。 - -* 深入分析整个堆栈。 - -## 审核中 - -* 使用多可用区基础结构来提高可靠性。 - -* 利用自扩展服务，例如 ELB，S3，SQS，SNS，DynamoDB 等。 - -* 在每个级别构建冗余。 可伸缩性和冗余不是两个独立的概念，您通常可以同时进行。 - -* 从传统的关系 SQL 数据库开始。 - -* 在基础结构内部和外部缓存数据。 - -* 在基础架构中使用自动化工具。 - -* 确保您具有良好的指标/监视/日志记录。 确保您正在查找客户对应用程序的体验。 - -* 将层划分为单独的服务（SOA），以便它们可以彼此独立地扩展和失败。 - -* 准备使用自动缩放功能。 - -* 除非绝对必要，否则不要重新发明轮子，而是使用托管服务而不是自己编写代码。 - -* 如果可行，请转移到 NoSQL。 - -## 延伸阅读 - -* [在 HackerNews](https://news.ycombinator.com/item?id=10885727) 上/ [在 Reddit](https://www.reddit.com/r/sysadmin/comments/40hon7/a_beginners_guide_to_scaling_to_11_million_users/) 上 - -* [http://aws.amazon.com/documentation](http://aws.amazon.com/documentation/) - -* [http://aws.amazon.com/architecture](http://aws.amazon.com/architecture/) - -* [http://aws.amazon.com/start-ups](http://aws.amazon.com/start-ups) - -* [http://aws.amazon.com/free](http://aws.amazon.com/free) - -* 从 2007 年开始： [Amazon Architecture](http://highscalability.com/blog/2007/9/18/amazon-architecture.html) - -不错的文章。 请更正用于启动的链接。 （对 http：//aws.amazon.comstart-ups 的开放应该是 http://aws.amazon.com/start-ups/） - -即使对于可伸缩性专业人员来说，这也是一篇出色的，易于上手的文章。 做得好 - -此设置每月将耗费疯狂的$。 AWS 是一种将 VC 美元间接注入亚马逊银行账户的好方法。 - -如果人们实际上对 TCO / ROI 持认真态度，那么人们就必须停止对价格过高的 VM 的炒作，而回到裸机解决方案。 - -这是非常依赖于应用程序的，但是对于每个级别的用户，可以期望每秒钟的事务/请求范围是多少？ - -@帕特里克 - -是的，但是没有。 - -正是在这个主题上，我们进行了荒谬的成本分析。 实际上，在我们系统运营的每个领域中，AWS 都能为我们节省大量资金。 某些 AWS 服务的成本仅为内部成本的 1/3。 - -每当您看到整个世界都朝着某种趋势发展时，尤其是当该“世界”主要由聪明人和百万富翁（他们真的很喜欢保留/赚钱）组成时，您应该假设其可能不仅仅是“炒作”或 “时尚”。 - -五年前的数字有所不同，但是自那时以来，AWS 已将价格降低了一半或更多。 除非您的计算器坏了，否则我将很难得出任何其他结论。 - -我的经验主要是在 AWS ..上，但是 Google 的云的价格相当，并且我认为其他 IaS 和 PaS 提供商的价格差异可以忽略不计。 - -所以，我的建议是：仔细看..然后跳上马车或开始计划退休 - -AWS CloudFormation 的问题一直是大型 JSON 脚本的笨拙-没有一致的添加注释的方式，笨拙的模块化故事以及没有向后引用。 - -通过使用 yaml 编写模板，然后使用 [YAML Stratus](https://github.com/kikinteractive/yaml-stratus) 转换为所需的 JSON，我们一直在解决此问题。 Yaml 支持注释，向后引用，并且 yaml stratus 添加 yaml 扩展以包括其他具有覆盖的 yaml 脚本以及编译时参数化。 - -@卢克·查弗斯 - -是的，但是你错了。 - -AWS 总是比裸机中的裸机贵，大约是 10 到 100 倍。 部署这样的复杂设置（更糟糕的是，大多数应用程序永远都不需要）时，情况更糟。 - -Modern 的速度非常快，基本的中型服务器每天可以支持数百万个请求，而将高可用性加倍则很便宜。 即使在云中，除非您确实需要，最好还是坚持使用基本 VM 而不是所有托管服务。 - -从您的评论来看，好像是您的计算器坏了，或者您只是在为 AWS 工作。 - -我有点不同意 RDS 观点。 如果您甚至具有基本的 db-administraton 技能，请不要使用 RDS。AmazonsRDS 对数据库使用 EBS 驱动器的速度非常非常慢。一种更好的方法是将实例存储 SSD 驱动器用于您不需要的临时存储物 需要持久化（tempdb，事务日志（如果您知道自己在做什么以及如何在没有日志的情况下还原数据库）等）。 - -除了我的这个小小的评论-很棒的帖子，谢谢 - -你好 - -我已经将 RDS 用于我的应用程序之一，该应用程序处理数百万个实时社交媒体数据。 通过所有优化，我们可以在中等亚马逊实例中使用 mysql mysql 来处理 1 或 2 周的数据。 随着数据量的增长，RDS 是我们关系数据库设计的帮助。 - -事实是，与普通解决方案相比，这是非常昂贵的，但是当您必须处理潜在的大量数据时，则值得花费。 - -哈哈@ colo。 当然，如果您喜欢停机和昂贵的带宽费用，请选择合适的颜色！ - -嘿@Alex：这个[1]说 Amazon RDS 是否支持 SSD？ - -[1] http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html - -真正使我担心的是在 AWS 上进行扩展，这就是为什么喜欢 Cloudways 的原因，因为他们可以按比例缩放服务器规模。 - -非常不错的文章，但我会缓和一个事实，那就是我们应该从 SQL DB 开始，然后将可能的方式切换到 No-SQL。 从 SQL 转换为 No-SQL 可能会非常痛苦（模型转换，业务代码重写，数据迁移等），而且风险很大，您永远也不会做。 - -因此，我建议您采取以下措施：如果您怀疑您的应用程序将支持超过 10 万个用户（并且您的业务肯定是与 No-SQL 兼容的），请直接使用 No-SQL 数据库。 您将能够轻松进行分片，使用 No-SQL 进行开发并不昂贵，并且您的应用程序可以自然扩展，而无需重新定义体系结构。 - -让·马克 - -关于裸机颜色的问题是，您需要考虑所有“成本”。 大多数决定采用裸机的人都严重低估了所需的时间和精力，其中最少的是硬件（但是，假设您使用的是专业质量的服务器硬件，而不是垃圾邮件，那么硬件仍然比您想象的要昂贵得多）。 您当地的回收场）。 特别是，您将需要一个实施团队来进行初始部署，然后*至少*由一名工作人员负责，只负责服务器的维护和维护以及最重要的虚拟化基础架构，每年的费用为 15 万美元以上 仅针对一个人-假设您可以和一个人一起停下来。 然后是数据中心不同区域的机架之间的光纤互连成本（数据中心通常具有电源和网络区域-机架位于不同的 UPS 和路由器上，但​​是如果您想在两个前哨站之间实现 10 GB 的快速互连， 您必须为此支付$$）。 当然，硬件本身的成本-用于互连数据库服务器和计算服务器的 10 吉比特交换机，所需的 10 吉比特卡，以及专业质量好的服务器和企业级 SSD 的价格并不便宜。 我已经为自己的业务工作了一个交叉点，这种交叉点在内部而不是通过亚马逊来进行比较便宜，尽管该交叉点的用户数远远少于 1000 万，但肯定比我们现在花费的更多 在 AWS 服务上。 - -关于 NoSQL，最好将其用于大量非结构化数据，例如日志数据（例如 ElasticSearch），但是现代 SQL 数据库的 ACID 保证在许多方面都非常重要。 与将 SQL 数据库简单地优化和扩展到所需的位置相比，尝试将它们横向入侵 NoSQL 数据库通常会花费更多的时间。 Twitter 使用 MySQL 处理 1.5 亿活跃用户。 已为您的时间表授予 Redis 缓存和一些自定义复制代码，但仍然：MySQL。 - -这是一个很棒的帖子！ 我认为在某些时候提高网站效率可能比服务器规模更有效。 例如，有人说通过使用微缓存和 nginx，他们每天可以在微型 VPS 服务器上处理数百万的网页浏览。 - -但是话又说回来，我从来没有承受过太大的服务器负载，所以我知道什么。 - -非常有用的信息，请不断更新我们，..... - -谢谢。 我是这个领域的初学者。 由于 AWS 昂贵，因此我使用 Linode VPS 进行托管。 这将非常有助于我在上下文中使用。 但是，如果您有关于该/其他廉价服务的经验，请与我们分享，因为 Linode 没有 AWS 提供的一些自动化服务。 - -人们没有解决一些问题，亚马逊可能会更昂贵，但是每当怀疑/涉及欺诈时，他们的确会听取买卖双方的意见，而 ebay 不会这样做。 - -超级清晰，写得很好。 谢谢 \ No newline at end of file +“找到 ITS 方式”。 没有撇号。 \ No newline at end of file diff --git a/docs/6.md b/docs/6.md index 7b28f0f..01fe58f 100644 --- a/docs/6.md +++ b/docs/6.md @@ -1,208 +1,58 @@ -# ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务 +# ThemBid 架构 -> 原文： [http://highscalability.com/blog/2018/4/2/how-ipdata-serves-25m-api-calls-from-10-infinitely-scalable.html](http://highscalability.com/blog/2018/4/2/how-ipdata-serves-25m-api-calls-from-10-infinitely-scalable.html) +> 原文： [http://highscalability.com/blog/2007/7/26/thembid-architecture.html](http://highscalability.com/blog/2007/7/26/thembid-architecture.html) -![](img/935b75bf17fe4d9451cc730fde8b933c.png) +ThemBid 提供了一个市场，需要完成工作的人们可以广播他们的请求，并接受竞争该工作的人们的出价。 与在 HighScalability 上介绍的许多网站不同，ThemBid 的流行程度不及 Paris Hilton。 它不是媒体的宠儿，也不是行业的巨头。 但是我喜欢的是他们有一个策略，可以构建网站的观点，并且足够亲切地分享有关如何构建网站的非常详细的说明。 他们甚至深入研究了所使用的各种软件包的实际安装细节。 看看他们的工作，任何人都可以从中受益。 -*这是 IP 地理位置 API [ipdata](https://ipdata.co/) 的创建者 [Jonathan Kosgei](https://twitter.com/jonathan_trev) 的来宾帖子。* +网站：http：//www.thembid.com/ -我在去年的黑色星期五醒来，收到了来自用户的大量电子邮件，报告来自 [ipdata](https://ipdata.co/) API 的 503 错误。 +## 信息来源 -我们的用户通常会在其网站上的每个页面请求上调用我们的 API，以对用户进行地理位置定位和本地化其内容。 因此，这一特殊故障在一年中最大的销售日直接影响了我们用户的网站。 +* [使用 Ubuntu，Symfony 和 Lighttpd 构建可扩展的 Web 2.0 站点](http://blog.thembid.com/index.php/2007/04/05/build-scalable-web-20-sites-with-ubuntu-symfony-and-lighttpd/) -那天我只失去了一个用户，但差点失去了更多。 + ## 平台 -事件的顺序及其无法解释的性质-cpu，mem 和 i / o 远没有达到容量。 考虑到停机，我们担心扩展规模（如果有的话），这是一个重新考虑现有基础架构的重大呼吁。 + * Linux（Ubuntu）* Symfony* Lighttpd* 的 PHP* 电子加速器* 蚀* 慕宁* AWStats -## 当时的技术堆栈 + ## 里面有什么？ -![](img/b9a6547c2405674e9b11c2e0b6efb9c8.png) + ### 统计资料 -* Japronto Python 框架 -* 雷迪斯 -* AWS EC2 节点 -* AWS 弹性负载平衡器 -* 基于 Route53 延迟的路由 + * 从 2006 年 12 月开始工作，到 2007 年 3 月进行了完整的演示。* 一名开发人员/系统管理员与兼职图形设计师合作。* 启动后针对了数千名用户。 -我已经在几个新的，有希望的 Python 微框架上进行了测试。 + ### 架构 -在使用 [https://github.com/samuelcolvin/aiohttp-vs-sanic-vs-japronto 对基准 3 进行基准测试后，我在[aiohttp]，[sanic]和[japronto]之间进行选择，选择了](https://github.com/samuelcolvin/aiohttp-vs-sanic-vs-japronto) [Japronto](https://medium.freecodecamp.org/million-requests-per-second-with-python-95c137af319) 。 并发现它具有最高的吞吐量。 + * **硬件**。 具有 2GB RAM 的双核服务器* **存储**。 RAID1 上的 2 x 36SCSI 10K RPM。* **数据中心**。 由于过去的积极经验，他们与 Layeredtech 一起使用了托管服务器。* **开发环境**。 Ubuntu 和 Eclipse。* **操作系统**。 他们选择 Ubuntu 的服务器发行版是因为它们是在客户端使用的，并且 Ubuntu 支持“比典型的 IT 部署更简单的安装和更容易的维护”。* **Web 服务器**。 Lighttpd 用于处理静态内容并将动态 PHP 页面请求转发到 FastCGI。* **数据库**。 MySQL 的。 当需要增长时，想法是转向主从配置，它们可能是 MySQL 集群。* **Web 框架**。 之所以选择 PHP 是因为他们知道它，并且 Digg 和 Yahoo 等其他成功的网站也成功地部署了 PHP。 他们选择 Symfony 作为那里的框架，是因为它具有出色的文档和活跃的开发社区。 雅虎也使用 Symfony。 这个决定对他们来说效果很好。* **PHP 缓存**。 eAccelerator 用于编译和缓存 PHP 脚本。* **对象和内容缓存**。 该计划是要缓存很多内容。 对于像他们这样的出价网站，这是有道理的。 许多片段会被反复使用，因此将它们放入内存将加快整个系统的速度，并减轻数据库和 IO 系统的压力。 最初，基于内存的文件系统顶部使用了 SQLite 缓存。 该选择是因为它得到了 Symfony 的支持。 当有 memcached 插件可用时，他们会尝试的。* **客户端缓存**。 Lighttp 的 mod_expire 模块用于防止浏览器不必要地重新下载很少更改的 Javascript，样式表和图像。* **监视**。 Munin 用于监视其资源使用情况。 只需访问“ yoursite.com/status”即可查看发生了什么。* **日志分析**。 AWStats 用于跟踪点击数和请求类型。 此信息可用于确定瓶颈。 -该 API 在 ELB 负载平衡器后面 3 个区域中的 3 个 EC2 节点上运行，并具有基于 Route53 延迟的路由，可将请求路由到距离用户最近的区域，以确保低延迟。 + * **可伸缩性计划**。 + -使用 Munin 告诉何时考虑升级。 当您的增长趋势很快将与资源趋势交叉时，就该采取行动了。 + -将 MySQL 移至单独的服务器。 这样可以释放资源（CPU，磁盘，内存）。 您要在此服务器上运行的内容取决于其功能。 也许在上面运行一个 memcached 服务器。 + -使用 memcached 移至分布式内存缓存。 + -添加 MySQL 主/从配置。 + -如果需要更多的 Web 服务器，我们可以在前端使用 LVS 作为负载均衡器。 -## 选择一个新的技术堆栈 + * **Future Directions** . Work on fault tolerance. -![](img/35012937655fe0f97f769040dd03a479.png) -An Example Weather API using our current stack + ## 得到教训 -大约在这个时候，我开始认真研究将 API 网关与 AWS Lambda 结合使用的原因： + * **使用通用的低成本工具**，只需几个人就可以相当快地创建一个不错的网站。 而且您的系统将强大而强大。 没有偷工减料。 -1. 优惠的价格：API 网关每百万美元约 3.50 美元，AWS Lambda 每百万美元约 0.20 美元。 -2. 无限规模和高吞吐量-API API 网关的帐户限制为每秒 10、000 个请求或每天约 864M 调用。 通过打开支持请求可以解除的限制。 + * **使用系统的反馈**了解需要优化的内容以及何时进行扩展。 -这也使在众多 AWS 区域中拥有端点在经济上可行，从而为全球所有用户提供低延迟。 + * **好的文档和活跃的社区吸引了人们**。 对于人们决定使用什么产品，这些都是非常有吸引力的品质。 当看起来您可能在未来无路可走而无所适从时陷入困境时，很难使用工具链。 如果您使工具变得难以理解，学习，使用和部署，那么它们将变得死气沉沉。 -## 设计多区域 API 网关 API + * **坚持使用熟悉的**。 它可能不是最佳的，也可能不是最佳的，但更重要的是您要开始并取得进步。 您不想延迟发布网站，这样您就可以学习一个完全不同的工具链，这可能会使您的生活变得更轻松，并且在某些未来的计划中。 未来是现在。 -为了使之可行，已经解决了许多架构难题。 + * **使用对他人有用的东西**。 Yahoo 和 Digg 使用 PHP 的事实是一个很好的建议。 当然，PHP 不是构建站点的唯一方法，但它确实降低了风险水平并帮助您在晚上入睡。 这也意味着有一个活跃的社区可以在您遇到问题时为您提供帮助。 -1. 每个区域中的每个 lambda 函数都需要能够在同一区域中的数据库中查找使用情况数据，以最大程度地减少延迟 -2. 我需要找出一种方法来确定每个 IP 地址，引荐来源网址和 API 密钥进行的 API 调用次数。 -3. 一种同步所有区域中的使用情况数据的方法。 例如，如果 Route53 向我们的悉尼端点发送了 10000 个请求，然后决定向其首尔端点发送下一个 50000 个请求（具体取决于那个时间点的网络延迟最小）。 每个 lambda 函数都需要知道用户总共发出了 60 000 个请求才能正确处理速率限制。 -4. 授权-API 网关提供使用计划和 API 密钥生成，并允许您将 API 密钥链接到使用计划。 此外，您无需为用户超出配额的请求付费，而无需支付额外费用。 但是，我无法使用此功能，因为对我来说，提供不注册，不使用信用卡的免费套餐非常重要。 +我希望您能为我的 Wiki 撰写有关整个可伸缩性问题的文章。 我希望使其成为网站，seo，sem 创建 Wiki。 我喜欢这些资源，很可能会将您的许多想法添加到我的网站中。 这篇文章是如此复杂，完美地引导了我。 为了制作更多的访问者，对您的策略进行视频/截屏怎么办？ -通过大量的工作，我能够以创造性的方式解决这些问题。 +本文错过了很多真正的高可伸缩性问题。 -## 在本地访问使用情况数据（针对每个 lambda 函数） +如果站点扩展到 Ebay / Amazon 的规模，此可伸缩性计划是否可行？ 没有。 -显而易见的解决方案是使用 Dynamodb，它在规模和速度上都具有成本效益！ 每月前 200M 个请求免费。 +设计高度可扩展的网站时，您需要一个计划来扩展各个方面。 这包括数据库，内容生成，静态数据和网络。 -Dynamodb 还提供 1-2 ms 的始终较低的读取延迟。 +可伸缩性与您使用的硬件，RDBM 或编程语言/框架无关。 这是关于它们如何彼此交互以及如何摆脱单个瓶颈点。 -![](img/9e083b450183ab840e2ab8eb31c98629.png) - -可以使用 [Dynamodb Accelarator](https://aws.amazon.com/dynamodb/dax/) （DAX）将其加速到微秒范围。 - -> DAX 通过每秒数百万个请求处理大量读取工作负载的响应时间（以微秒为单位），将性能提升到一个新的水平。 - -## 收集所有标识符的使用情况数据 - -下一个挑战是如何实时计算每个 IP 地址，引荐来源网址或 API 密钥发出的请求数。 - -最简单，最直接的方法是在每次调用时更新动态表中的计数。 - -但是，这会在每次调用我们的 API 时引入数据库写操作，从而可能导致显着的延迟。 - -我能够找到一个简单而优雅的解决方案： - -1. 首先，在每个请求上打印包含所有请求标识符的日志（JSON 对象）。 这是 IP 地址，引荐来源网址和 API 密钥（如果存在）。 真是 print（事件） -2. 将 [Cloudwatch 订阅过滤器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html)添加到每个区域中每个 Lambda 函数的 Cloudwatch 日志流中，并将所有日志推送到 Kinesis 流中。 这将使我能够处理中心位置中每个区域的日志事件。 由于可以回放事件，因此我选择了 Kinesis 而不是 SQS（亚马逊的简单队列服务）。 SQS 会在使用者读取事件后立即删除事件。 我希望能够从节点故障和数据丢失中恢复。 -3. 从 Kinesis 流中读取并使用使用情况数据更新 [Local Dynamodb](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html) 实例 -4. 使用 [Dynamodb 跨区域复制库](https://github.com/awslabs/dynamodb-cross-region-library)实时将对我的本地 dynamodb 实例的所有更改实时流式传输到所有区域中的所有表。 - -## 验证请求 - -我通过在注册时将密钥复制到每个区域来处理此问题，因此无论用户点击哪个端点，他们点击的 lambda 函数都可以通过在毫秒内检入本地 Dynamodb 表来验证其密钥。 它还可以存储用户的计划配额，并且可以在一次读取中验证密钥，如果密钥存在，则可以获取计划配额以与使用情况进行比较并确定是否接受或拒绝请求。 - -## 情况如何 - -今天，我们每月提供 2500 万个 API 调用，每天大约提供 100 万个调用。 - -它们中的大多数都在 30 毫秒之内，提供了业界最快的基于 SSL 的 IP 地理位置查找。 - -#### [Hyperping.io](https://hyperping.io/) - -![](img/57c5d04484b1083938ca36b83e89f8c6.png) - -### [我们的状态页面](https://updown.io/ndkd) - -![](img/ca63433ee2cce3eba7361c87bb8080dc.png) - -延迟几乎是开发人员不愿意使用第三方 API 进行 GeoIP 查找的最大原因。 - -但是，我们的低延迟和冗余的全球基础架构正逐渐将大型企业吸引到我们的服务中。 - -## 费用 - -![](img/d349c1a38380cd3fa8195a8783b7bf4c.png) - -## 经验教训 - -1. Cloudwatch 的成本可能出乎意料的高-而不是日志存储-我们只能将 Cloudwatch 日志存储 24 小时。 警报，指标和 cloudwatch 请求确实可以加起来。 -2. 在 API 网关上，由于冷启动次数减少，您获得的请求越少，延迟就越低，因此我发现在我们最繁忙的地区（法兰克福）的延迟低至 17 毫秒，而在悉尼等不那么繁忙的区域则只有 40 毫秒。 -3. Dynamodb 的速度快，花费比您想象的要少（或者不，请参阅 [https://segment.com/blog/the-million-dollar-eng-problem/](https://segment.com/blog/the-million-dollar-eng-problem/) ）。 最初，我认为应该按我提供的 RCU 和 WCU 的数量收费。 但是，计费似乎只是标准用法，因此，如果您提供 1000 个 RCU 和 1000 个 WCU，但仅使用 5 个 RCU 和 WCU，则只需要为使用付费。 Dynamodb 定价的这一方面在刚开始时很难确定。 -4. 增加 lambda RAM 可以使执行时间减半，并使的响应时间更加一致（同时使您的成本增加一倍！） -5. Kinesis 已被证明在高吞吐量下非常可靠。 中继我们的所有日志事件以进行近实时处理。 -6. 本地 Dynamodb 仅受系统资源的限制，这使其非常适合运行表扫描或查询（例如，在生成报告时），否则这些扫描或查询在 AWS 的 Dynamodb 上进行将非常昂贵。 请记住，Local Dynamodb 实际上只是 SQLite 周围的 Dynamo 包装:)。 对于我们的用例来说，它既有用又方便，但对您而言可能并非如此。 - -## 笔记 - -* AWS 去年在 Re：invent 上宣布了 Dynamodb Global 表，该表将所有表（“跨区域”）中的所有写入彼此同步。 我们目前不打算使用此功能，因为它仅在 5 个地区提供。 -* 亚马逊还推出了`REQUEST`类型的自定义授权者。 这可能使您可以通过 IP 地址以及任何标头，查询或路径参数对速率进行限制。 - -[关于 HackerNews](https://news.ycombinator.com/item?id=16745376) - -您的 DynamoDB 成本令人惊讶是因为默认情况下启用了“自动缩放”以读取/写入卷。 只要您的峰值不大，就永远不会看到配置错误... - -我对此声明感到困惑： - ------ -我最初以为我要提供的 RCU 和 WCU 数量付费。 但是，计费似乎只是标准用法，因此，如果您提供 1000 个 RCU 和 1000 个 WCU，但仅使用 5 个 RCU 和 WCU，则只需要为使用付费。 Dynamodb 定价的这一方面在刚开始时很难确定。 ------ - -定价页面（https://aws.amazon.com/dynamodb/pricing/）指出，您需要为您提供的吞吐量付费 - -也许因为仍在免费套餐中而未向您收费？ - -嘿 Cads， - -我完全理解混乱，我也和您一样。 - -但是我很确定我们不在免费领域，因为我们要为 Dynamodb 付费。 - -而且，我们只收取使用费用，并不超出表中的规定。 - -这似乎与亚马逊的定价页面上所说的相反，但这是我在 AWS 账单上看到的。 - -感谢您的有趣文章。 关于本地 DynamoDB，我有一个问题：您在哪里运行此程序？ 作为 EC2 实例？ - -嗨 Tobi， - -谢谢！ 我实际上在 Azure 节点上运行它。 但是，它可以作为实例在 DO 或 EC2 上运行。 - -该图显然是不真诚的。 从来没有太大的区别。 在这种情况下，可能是因为作者只是在测试管道而不是没有管道。 此外，他将 go pro 限制为 1 cpu。 同样，仓库也不再存在。 我把废话统称为“基准”。 - -顺便说一句，Japronto 主要是 C，请检查代码。 - -（我偏向于 Go，但是这不像 node，其他人无法应付自己） - -我记得在中篇文章上有很多类似的评论，请参阅 https://medium.freecodecamp.org/million-requests-per-second-with-python-95c137af319 - -我还能够找到另一个基准，使 japronto 紧随 Rust -https://github.com/tbrand/which_is_the_fastest - -每月 2500 万个请求是每秒 10 个请求... - -每秒高峰请求呢？ - -写得很好的文章。 感谢您分享您的体验。 我对以下部分有疑问： - -“首先，在每个请求上打印一个带有所有请求标识符的日志（JSON 对象）。这是 IP 地址，引荐来源网址和 API 密钥（如果存在的话）。确实是;```print（event）```“ - -只是想知道为什么不将这些消息直接发送给运动机能？ 为什么要先登录？ - -Esko，API 网关可以处理 10k req / s 的峰值 - -Kaivalya，这会为用户带来延迟，打印日志是最便宜的（就延迟而言）和最简单的解决方案。 - -> > SQS 会在使用者读取事件后立即将其删除。 -这是不正确的，一旦您从 SQS 读取了一条消息，直到可见性超时，任何人都看不到它。 您需要确认对 SQS 的读取，以便它可以删除消息。 我们通常要做的是处理消息，然后仅在处理实例发生故障的情况下进行确认，这样我们的消息仍然完好无损。 只需调整可见性超时以确保提供足够的时间即可。 - -很棒的文章。 感谢您与社区分享。 - -嗨，您如何处理每秒 1,000 个 Lambda 呼叫限制？ AWS 的架构师建议我们不要在具有高使用率和高并发性的大多数项目中使用 Lambda-他们说，这仅对中小型项目更好，并且没有您所说的无限规模-我们被告知的一个大问题 当以最大速度运行时，AWS 团队将耗尽 VPC 中所有可用的 IP 地址。 超出 1,000 个限制的呼叫也会被拒绝，您的客户也会出错。 - -为了计算并发执行的次数，我们使用公式： - -每秒事件（或请求）数*功能持续时间 - -如 https://docs.aws.amazon.com/lambda/latest/dg/scaling.html 所记录。 -自这篇文章上线以来，我们平均每天平均有 2M API 调用，大约每秒 12 次。我们的最大 lambda 使用上面公式中的值，调用时间为 20ms； - -12 * 0.020 - -我们得到的并发级别为 0.24。 - -这意味着我们可以在目前的 1000 lambda 调用限制下，每秒处理 50，000 个请求，每天约 43.2 亿个请求。 - -嗨， -单个订户的运动流事件有多个订户吗？ -只是想知道为什么如果所有数据都存储在一个中央（本地）dynamo 数据库实例中，则跨区域 dynamo 数据库进行复制。 - -因此，您为 9 req / s 支付 150 美元？ - -对于许可证密钥检查，您是否考虑过使用 Bloom 或 Cuckoo 过滤器？ 您可以将过滤器保存在内存中，并避免数据库调用。 - -首次使用 ipdata.co 的用户，我们最近切换到了另一个 IP 地理位置提供商。 延迟在过去几个月中增加了很多，并且在全球范围内不一致（请参阅 https://status.ipdata.co/）。 此外，该服务缺少监视仪表板。 - -如果您处于类似情况，我建议尝试 Ipregistry（https://ipregistry.co），其全局端点延迟实在令人难以置信（https://status.ipregistry.co/）！ 我联系了他们的支持，建议在此博客上写一篇文章，因为他们的体系结构可能很有趣。 \ No newline at end of file +本文中的体系结构是有缺陷的，不应用作可伸缩性模型。 \ No newline at end of file diff --git a/docs/60.md b/docs/60.md index 7da84cc..f8e4e36 100644 --- a/docs/60.md +++ b/docs/60.md @@ -1,299 +1,248 @@ -# 无服务器启动-服务器崩溃！ +# 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量 -> 原文： [http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html](http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html) +> 原文： [http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html) -[![teletext.io](img/e44ffec4ff98259588613d9ce8ae51e1.png)](https://teletext.io/ "Teletext.io - content as a service") +![](img/23e609ef6f02f2890c78b7ea6bbc2d1c.png) -*这是来自 [Teletext.io](https://teletext.io/ "Teletext.io") 的 [Marcel Panse](http://www.linkedin.com/in/marcelpanse "Marcel Panse") 和 [Sander Nagtegaal](http://www.linkedin.com/in/centrical "Sander Nagtegaal") 的来宾帖子。* +自从我的第一篇关于 [Stack Overflow Architecture](/blog/2009/8/5/stack-overflow-architecture.html) 的文章以来发生了很多事情。 与上一篇文章的主题相反，该主题引起了人们对 Stack Overflow 致力于扩大规模战略的关注，但在过去的几年中，Stack Overflow 不断发展壮大。 -在早期的 [Peecho 时代](http://www.peecho.com/ "Peecho")中，我们[写了一篇文章](http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html "Peeacho architecture - scalability on a shoestring")，解释了如何使用 [Amazon Web Services](http://aws.amazon.com/ "Amazon Web Services") 构建真正可扩展的架构。 自动缩放，无情的解耦，甚至对未使用的服务器容量进行自动出价，都是我们当时用来操纵的技巧。 现在，是时候将其进一步迈出一步了。 +Stack Overflow 的规模增长了两倍以上，超过 1600 万用户，其页面浏览量几乎翻了六倍，达到每月 9500 万页面浏览量。 -我们想介绍 [Teletext.io](https://teletext.io/ "Teletext.io - content as a service") ，也称为*无服务器启动*-再次完全基于 AWS 构建，但仅利用了 [Amazon API Gateway](https://aws.amazon.com/api-gateway/ "Amazon API Gateway") ， [Lambda](https://aws.amazon.com/lambda/ "AWS Lambda") 函数， [DynamoDb](https://aws.amazon.com/dynamodb/ "AWS DynamoDb") ， [S3](https://aws.amazon.com/s3/ "AWS S3") 和 [Cloudfront](https://aws.amazon.com/cloudfront/ "AWS Cloudfront") 来实现。 +堆栈溢出通过扩展到[堆栈交换网络](http://stackexchange.com/)而得以发展，该网络包括堆栈溢出，服务器故障和超级用户（总共 43 个不同站点）。 进行着很多富有成果的乘法。 -## 约束的美德 +不变的是，Stack Overflow 对他们正在做的事情持开放态度。 这就是促使进行此更新的原因。 最近的一系列帖子讨论了他们如何处理增长问题：[堆栈交换的体系结构以[项目符号]](http://blog.serverfault.com/post/stack-exchanges-architecture-in-bullet-points/) ， [Stack Overflow 的纽约数据中心](http://blog.serverfault.com/2010/10/29/1432571770/)，[为可伸缩性而设计 管理和容错](http://blog.serverfault.com/post/1097492931/)，[堆栈溢出搜索-现在](http://blog.stackoverflow.com/2011/01/stack-overflow-search-now-81-less-crappy/)，[堆栈溢出网络配置](http://blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/)，[减少 81％StackOverflow 是否使用缓存？如果使用缓存，如何使用缓存？](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how) ，[哪些工具和技术构建了堆栈交换网络？](http://meta.stackoverflow.com/questions/10369/which-tools-and-technologies-build-the-stack-exchange-network) 。 -我们喜欢规则。 在我们之前的初创公司 [Peecho](http://www.peecho.com/ "Peecho printing") 中，产品所有者必须为每个想要添加到正在进行的 sprint 中的用户故事支付*五十次俯卧撑*。 现在，在我们目前的公司 [myTomorrows](https://mytomorrows.com/ "myTomorrows - expanding access to drugs in development") 中，我们的*开发人员舞会*颇具传奇色彩：在每日站立时，您只能在跳舞时讲*- 导致有史以来最高效的会议。* +跨时间的一些更明显的差异是： -这种思维方式一直贯穿于我们的产品开发。 乍一看似乎违反直觉，但限制了创造力。 例如，我们所有的徽标设计都是通过技术制图工具 [Omnigraffle](https://www.omnigroup.com/omnigraffle "Omnigraffle") 完成的，因此我们无法使用可怕的*镜头光斑*等。 无论如何-最近，我们发起了另一个计划 [Teletext.io](https://teletext.io/ "Teletext.io") 。 因此，我们需要一个新的限制。 +* **更多**。 更多用户，更多页面视图，更多数据中心，更多站点，更多开发人员，更多操作系统，更多数据库，更多机器。 的数量更多。 +* **Linux** 。 堆栈溢出以其 Windows 堆栈而闻名，现在他们将更多的 Linux 机器用于 HAProxy，Redis，Bacula，Nagios，日志和路由器。 所有支持功能似乎都由 Linux 处理，这需要开发[并行发布过程](http://blog.serverfault.com/post/1097492931/)。 +* **容错**。 现在，堆栈溢出（HTG2）由两个不同 Internet 连接上的两个不同交换机提供服务，它们添加了冗余计算机，并且某些功能已移至另一个数据中心。 +* **NoSQL** 。 Redis 现在用作整个网络的[缓存层](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how)。 之前没有单独的缓存层，所以这是一个很大的变化，就像在 Linux 上使用 NoSQL 数据库一样。 + +不幸的是，我找不到关于我上次遇到的一些未解决问题的报道，例如它们将如何处理这么多不同属性的多租户，但仍然有很多值得学习的地方。 这里汇总了一些不同的来源： + +### 统计资料 + +* 每月 9500 万页面浏览量 +* 每秒 800 个 HTTP 请求 +* 180 个 DNS 请求每秒 +* 每秒 55 兆位 +* 1600 万用户-流量向堆栈溢出的流量在 2010 年增长了 131％，达到每月 1,660 万全球唯一身份用户。 -*在 Teletext.io，我们不允许使用服务器。 连一个都没有。* +### 数据中心 -这是一个不错的选择。 我们将解释原因。 +* 1 个带有 Peak Internet 的机架（或）（托管我们的聊天和数据资源管理器） +* 2 个在纽约拥有对等 1 的机架（托管其余的 Stack Exchange Network） -## 为什么服务器损坏 +### 硬件 -在过去的几年中，Amazon 云已经使我们非常满意能够使用 EC2 服务器实例的自动扩展群集，并在其顶部具有负载平衡器。 这意味着，如果您的一台服务器出现故障，则可以自动启动新服务器。 当出现意外的高峰流量时，也会发生同样的情况。 然后将启动额外的服务器。 +* 10 台 Dell R610 IIS Web 服务器（其中 3 台专用于堆栈溢出）： + * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz 四核，带 8 个线程 + * 16 GB RAM + * Windows Server 2008 R2 -尽管这很酷，但也有缺点。 +* 2 台 Dell R710 数据库服务器： + * 2 个 Intel Xeon 处理器 X5680 @ 3.33 GHz + * 64 GB 内存 + * 8 锭 + * SQL Server 2008 R2 + +* 2 台 Dell R610 HAProxy 服务器： + * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz + * 4 GB 内存 + * Ubuntu 服务器 + +* 2 台 Dell R610 Redis 服务器： + * 2 个 Intel Xeon 处理器 E5640 @ 2.66 GHz + * 16 GB RAM + * CentOS 的 + +* 1 台运行 Bacula 的 Dell R610 Linux 备份服务器： + * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz + * 32 GB 内存 + +* 1 台用于 Nagios 和日志的 Dell R610 Linux 管理服务器： + * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz + * 32 GB 内存 + +* 2 个 Dell R610 VMWare ESXi 域控制器： + * 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz + * 16 GB RAM + +* 2 个 Linux 路由器 +* 5 个 Dell Power Connect 交换机 + +### 开发工具 + +* **C＃**：语言 +* **Visual Studio 2010 Team Suite** ： IDE +* **Microsoft ASP.NET（4.0 版）** ：框架 +* **ASP.NET MVC 3** ： Web 框架 +* **剃刀** ：视图引擎 +* **jQuery 1.4.2** ：浏览器框架： +* **LINQ to SQL，一些原始 SQL** ：数据访问层 +* **水银和窑** ：源代码管理 +* **Beyond Compare 3** ：比较工具 + +### 使用的软件和技术 + +* 堆栈溢出通过 [BizSpark](http://blog.stackoverflow.com/2009/03/stack-overflow-and-bizspark/) 使用 [WISC](http://stackoverflow.com/questions/177901/what-does-wisc-stack-mean) 堆栈 +* **Windows Server 2008 R2 x64** ：操作系统 +* **运行 **Microsoft Windows Server 2008 Enterprise Edition x64** 的 SQL Server 2008 R2** ：数据库 +* Ubuntu 服务器 +* CentOS 的 +* **IIS 7.0** ：Web 服务器 +* **HAProxy** ：用于负载均衡 +* **Redis** ：用作分布式缓存层。 +* **CruiseControl.NET** ：用于构建和自动部署 +* **Lucene.NET** ：进行搜索 +* **Bacula** ：用于备份 +* **Nagios** ：（带有 [n2rrd](http://n2rrd.diglinks.com/cgi-bin/trac.fcgi) 和 drraw 插件）用于监视 +* **Splunk：**用于日志 +* **SQL Monitor：来自 Red Gate 的**-用于 SQL Server 监视 +* **绑定**：用于 DNS +* **[Rovio](http://www.wowwee.com/en/products/tech/telepresence/rovio/rovio)** ：一个小机器人（真正的机器人），允许远程开发人员“虚拟地”访问办公室。 +* **Pingdom** ：外部监视器和警报服务。 + +### 外部钻头 + +开发工具中未包含的代码： + +* 验证码 +* DotNetOpenId +* WMD-现在已开发为开源。 见 github 网络图 +* 美化 +* 谷歌分析 +* 巡航控制.NET +* HAProxy +* 仙人掌 +* 降价锐利 +* 美丽 +* Nginx 的 +* 窑 +* CDN：无，所有静态内容均由 [sstatic.net](http://sstatic.net/) 提供，这是一个快速，无 cookie 的域，用于将静态内容传递给 Stack Exchange 系列网站。 + +### 开发人员和系统管理员 + +* 14 个开发人员 +* 2 个系统管理员 + +### 内容 + +* **许可：**知识共享署名-相同方式共享份额为 2.5 +* **标准：** OpenSearch，Atom +* **主持人：** PEAK Internet + +### 更多架构和经验教训 + +* 使用 HAProxy 而不是 Windows NLB，因为 HAProxy 便宜，简单，免费，可通过 Hyper-V 用作网络上的 512MB VM``设备''。 它也可以在盒子前面使用，因此对它们完全透明，并且更容易作为另一个网络层进行故障排除，而不必与所有 Windows 配置混在一起。 +* 不使用 CDN 是因为，即使像亚马逊这样的“便宜” CDN 相对于捆绑到现有主机计划中的带宽而言也非常昂贵。 根据 Amazon 的 CDN 费率和带宽使用情况，他们每月至少可以支付 1000 美元。 +* 备份到磁盘以进行快速检索，而备份到磁带以进行历史存档。 +* SQL Server 中的全文本搜索集成度很差，有故障，非常不称职，因此他们选择了 Lucene。 +* 人们对峰值 HTTP 请求数据最感兴趣，因为这是他们确保可以处理的需求。 +* 现在，所有属性都在相同的 Stack Exchange 平台上运行。 这意味着堆栈溢出，超级用户，服务器故障，元，WebApp 和元 Web 应用都在同一软件上运行。 +* 有单独的 StackExchange 网站，因为人们有不同的专业知识集，不应跨入不同的主题网站。 [您可以成为世界上最伟大的厨师，但这并不意味着您有资格修理服务器。](http://meta.stackoverflow.com/questions/69422/why-separate-stack-exchange-accounts) +* 他们积极地缓存一切。 +* 通过[输出缓存](http://learn.iis.net/page.aspx/154/walkthrough-iis-70-output-caching/)缓存匿名用户访问（并随后提供给匿名用户）的所有页面。 +* 每个站点都有 3 个不同的缓存：本地，站点，全局。 +* **本地缓存**：只能从 1 个服务器/站点对访问 + * 为了限制网络延迟，他们使用服务器上最近设置/读取的值的本地“ L1”缓存，基本上是 HttpRuntime.Cache。 这会将网络上的高速缓存查找开销减少到 0 字节。 + * 包含用户会话和未决视图计数更新之类的内容。 + * 它完全驻留在内存中，没有网络或数据库访问权限。 +* **网站缓存**：单个网站的任何实例（在任何服务器上）都可以访问 + * 大多数缓存的值都在这里，诸如热门问题 ID 列表和用户接受率之类的例子就是很好的例子 + * 它驻留在 Redis 中（在一个单独的数据库中，纯粹是为了简化调试） + * Redis 是如此之快，以至于缓存查找最慢的部分就是花费的时间在网络上读写字节。 + * 将值压缩后再将其发送到 Redis。 它们具有大量的 CPU，并且大多数数据是字符串，因此它们具有很高的压缩率。 + * 他们的 Redis 计算机上的 CPU 使用率为 0％。 +* **全局缓存**：在所有站点和服务器之间共享 + * 收件箱，API 使用配额和其他一些真正的全局信息都在这里 + * 它位于 Redis 中（在 DB 0 中，同样也便于调试） +* 缓存中的大多数项目会在超时时间（通常为几分钟）后过期，并且永远不会明确删除。 当需要特定的缓存失效时，他们使用 [Redis 消息](http://code.google.com/p/redis/wiki/PublishSubscribe)将删除通知发布到“ L1”缓存。 +* 乔尔·斯波斯基（Joel Spolsky）不是 Microsoft 的忠实拥护者，他没有为 Stack Overflow 做出技术决策，并且认为 Microsoft 授权存在舍入错误。 考虑自己已更正 [Hacker News 评论员](http://news.ycombinator.com/item?id=2284900)。 +* 他们为 IO 系统[选择了](http://blog.serverfault.com/post/our-storage-decision/) RAID 10 阵列，其中 [Intel X25 固态驱动器](http://www.intel.com/design/flash/nand/extreme/index.htm)。 RAID 阵列缓解了对可靠性的任何担忧，并且与 FusionIO 相比，SSD 驱动器的性能确实很好，且价格便宜得多。 +* 他们的 Microsoft 许可的[全船费用](http://news.ycombinator.com/item?id=2285931)约为$ 242K。 由于 Stack Overflow 使用的是 Bizspark，因此他们所支付的价格接近全价，但这是他们所能支付的最高价。 +* [英特尔 NIC 正在取代 Broadcom NIC](http://blog.serverfault.com/post/broadcom-die-mutha/) 及其主要生产服务器。 这解决了他们在连接丢失，数据包丢失和 arp 表损坏时遇到的问题。 -* 首先，即使您没有任何流量或收入，您**仍需要保持最少数量的服务器实例**处于活动状态，以便能够为任何访问者提供服务。 这要花钱。 -* 其次，由于云实例在操作系统之上运行已安装的软件，因此您不仅需要维护自己的代码，还需要**确保服务器软件保持最新**并可以运行。 -* 第三，您**不能以精细的方式**向上或向下扩展，但一次只能一台完整的服务器。 +## 相关文章 -在基于带有微服务的 API 的体系结构中，这意味着小任务的开销很大。 幸运的是，现在有解决此问题的选项。 首先让我们看一下眼前的问题。 +* [此帖子上的黑客新闻主题](http://news.ycombinator.com/item?id=2284900) / [Reddit 主题](http://www.reddit.com/r/programming/comments/fwpik/stackoverflow_scales_using_a_mixture_of_linux_and/) +* [项目符号中的堆栈交换体系结构](http://blog.serverfault.com/post/stack-exchanges-architecture-in-bullet-points/) / [HackerNews 线程](http://news.ycombinator.com/item?id=2207789) +* [Stack Overflow 的纽约数据中心](http://blog.serverfault.com/post/1432571770/)-各种计算机的硬件是什么？ +* [设计用于管理和容错的可伸缩性](http://blog.serverfault.com/post/1097492931/) +* [堆栈溢出博客](http://blog.stackoverflow.com/) +* [堆栈溢出搜索-现在减少了 81％的废话](http://blog.stackoverflow.com/2011/01/stack-overflow-search-now-81-less-crappy/)-Lucene 现在正在未充分利用的集群上运行。 +* [2010 年堆栈状态（您的 CEO 的来信）](http://blog.stackoverflow.com/2011/01/state-of-the-stack-2010-a-message-from-your-ceo/) +* [堆栈溢出网络配置](http://blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/) +* [StackOverflow 是否使用缓存？如果使用缓存，如何使用缓存？](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how) +* [Meta StackOverflow](http://meta.stackoverflow.com/) +* [StackOverflow 如何处理缓存失效？](http://meta.stackoverflow.com/questions/6435/how-does-stackoverflow-handle-cache-invalidation) +* [哪些工具和技术构建了堆栈交换网络？](http://meta.stackoverflow.com/questions/10369/which-tools-and-technologies-build-the-stack-exchange-network) +* [堆栈溢出如何处理垃圾邮件？](http://meta.stackoverflow.com/questions/2765/how-does-stack-overflow-handle-spam) +* [我们的存储决策](http://blog.serverfault.com/post/our-storage-decision/) +* [如何选择“热门”问题？](http://meta.stackoverflow.com/questions/4766/how-are-hot-questions-selected) +* [如何选择“相关”问题？](http://meta.stackoverflow.com/questions/20473/how-are-related-questions-selected) -标题，问题正文和标签。 +* [堆栈溢出和 DVCS](http://blog.stackoverflow.com/2010/04/stack-overflow-and-dvcs/) -堆栈溢出选择 Mercurial 进行源代码控制。 +* [服务器故障聊天室](http://chat.stackexchange.com/rooms/127/the-comms-room) +* [C＃Redis 客户端](https://github.com/ServiceStack/ServiceStack.Redis) +* [Broadcom，Die Mutha](http://blog.serverfault.com/post/broadcom-die-mutha/) -## 抓痒 +他们是否解释了为什么使用 Redis 而不是 Memcached 进行缓存？ 我听说很多人使用 Redis 进行缓存，只是想知道 Redis 做什么，而 Memcached 不会呢？ -我们全新的解决方案源于个人对自定义软件中*内容管理*的不满。 在大多数初创企业中，按钮，仪表板，帮助部分甚至整个网页中的 HTML 文本必须由*程序员*而不是文本编写者来管理和部署。 对于开发人员和编辑人员而言，这确实很烦人。 +如果我没记错的话，Redis 不是分布式数据库，对吗？ 使用 memcached 时，如果我添加新节点，客户端将自动重新分发缓存，以利用额外的容量。 Redis 不会那样做。 那么，为什么要使用 Redis？ -多年来，我们试图找到一种可以正确解决此问题的分布式内容管理服务。 我们失败了。 因此，几个月前，我们受够了，并决定只需要自己构建一些东西。 +> 备份到磁盘以进行快速检索，而备份到磁带以进行历史存档。 -## 计划 +真？ 人们还在这样做吗？ 我知道一些组织在自动化的自动磁带备份上投入了大量资金，但是说真的，一个成立于 2008 年的网站正在备份磁带吗？ -我们计划创建一个非常简单的基于 Java 的服务，该服务可以使用 HTML 的通用数据属性标记元素来注入集中托管的内容。 它应该能够处理本地化和动态插入数据。 最重要的是，它应该为内容编写者提供一种在自己的应用程序中使用嵌入式 WYSIWYG 编辑器随时更改文本的方法。 +为什么有人会在 Linux / Linux 上使用 Windows / asp？ +我真的很惊讶人们仍然在做这样的事情。 -除了一些用户体验警告之外，这里还面临三个技术挑战。 +*为什么有人会在 Linux / Linux 上使用 Windows / asp？ +确实让我感到惊讶的是，人们仍然在做这样的事情。* -1. 由于实时网站依靠它来获取内容，因此这种新的商品服务应该永远不会失败。 曾经 -2. 它应该非常非常快，因此您的访问者甚至不会注意到内容正在加载。 -3. 内容应由 Google 编制索引。 +因为.NET 是目前最好的开发框架之一。 而且用于网络的 linux 便宜，因此结合起来很有意义。 -第三个问题与体系结构本身无关。 可信赖的搜索引擎以神秘的方式运转，因此我们所能做的就是[测试假设](http://www.centrical.com/test/google-json-ld-and-javascript-crawling-and-indexing-test.html "Google crawling an indexing test for javacript insertion and JSON-LD structured data")。 剧透：是的，它有效。 不过，前两个问题的解决方案掌握在您自己手中。 这些都可以通过低成本的巧妙解决方案来解决。 +@约翰 -## 建筑模块 +使用 Redis 或 membase 之类的东西而不是 memcached 的优点之一是可以将缓存持久化到磁盘上，这样可以避免缓存脱机然后重新启动时出现缓存风暴问题。 -让我们深入研究基于 Amazon Web Services 的一些最新功能的系统构建块。 +我猜我们不知道 Redis 框的配置是什么 他们是分片，进行主/从复制等吗？ -### Amazon API 网关 +安迪 -[Amazon API Gateway](https://aws.amazon.com/api-gateway/ "Amazon API Gateway") 是一项托管的 AWS 服务，允许开发人员在 AWS 管理控制台中单击几下即可创建任意规模的 API。 该服务可以触发其他 AWS 服务，包括 Lambda 函数。 +@Joe，如果您知道自己的想法，那么逻辑就很容易：Joel 是 MS Excel 团队的成员，该团队编写了 VBA 和 OLE 自动化。 -### AWS Lambda +@Joe-这是我在该网站上看到的最不明智的评论之一。 -而不是运行云实例，我们使用 [AWS Lambda](https://aws.amazon.com/lambda/ "AWS Lambda") 。 该名称源自希腊字母 lambda（λ），用于表示在函数中绑定变量。 AWS Lambda 使您可以在不维护任何服务器实例的情况下运行代码。 您可能会想到具有单个任务的原子无状态功能，该功能可能会运行有限的时间（当前为一分钟）。 这些功能可以用 Javascript（Node.js），Python 或 Java 编写。 +詹姆斯：备份到磁带意味着脱机/档案备份。 这通常是值得的花费和麻烦，特别是对于大型重要数据集。 一两三周后，我可以告诉您，Gmail 员工非常非常高兴他们备份到磁带上。 如果您的所有副本都在线，则总是存在一个错误或手指滑动同时擦拭它们的可能性。 -如果您上传 Lambda 代码，Amazon 将负责以高可用性运行和扩展代码所需的一切。 Lambda 并行执行。 因此，如果发出一百万个请求，则将执行一百万个 Lambda 函数，而不会损失速度或容量。 据亚马逊称，“扩展功能没有基本限制”。 +从技术上讲，IIS 7.0：Web 服务器不正确，在 Windows Server 2008R2 下，它实际上是 IIS 7.5：Web 服务器。 -最好的是，从开发人员的角度来看，Lambda 函数在不执行时甚至不存在。 它们仅在需要时出现。 而没有上升的事物，也不会下降的事物。 +@Sosh-请放轻松，不要提升自己对 Microsoft 产品的支持。 在最好和最新的开源公司及其社区中运行 MS 产品没有技术上的原因。 实际上，要真正推动这一点，StackOverflow 团队应该在各地使用更多*付费/许可*的 ms 产品来推动其发展。 还有一种观点认为，可以针对工作使用最佳工具组合，因此请参见此处。 答案很简单：StackOverflow 团队了解 MS 产品，Visual Studio，C＃和.NET，因此（对于该团队而言）交付 StackExchange 系列站点是最便宜，最快的。 ^ M -### DynamoDB +他们有明确的绩效目标吗？ 他们如何在负载下监视站点性能？ 对于在 HighScalability.com 上进行介绍的任何网站，这些问题似乎都是重要的问题。 -Lambda 函数将其数据存储在数据存储中。 因为我们的规则说不允许我们使用任何服务器，所以我们不能使用关系数据库服务（RDS）。 相反，我们使用 Amazon 的大型托管数据存储 DynamoDB。 +是的，大多数拥有重要数据的人仍然使用磁带。 另外，它们是 Windows，因为创始人是微软的老家伙！ -[Amazon DynamoDB](https://aws.amazon.com/dynamodb/ "AWS DynamoDb") 是适用于所有规模的所有应用程序的 NoSQL 数据库服务。 它受到完全管理，并支持文档和键值存储模型。 Netflix，AirBnB 和 IMDb 等其他用户已经证明了该服务的可扩展性。 +**[仅使用更好的应用程序，您可以避免软件许可和网络硬件成本。 伺服器：](http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/ "You can avoid software license AND network hhardware costs by just using a better app. server")** -## 建筑 +每秒服务器请求 -我们的系统分为三个部分： +--------------------------------------------- -1. 内容管理 -2. 内容传递 -3. 我们的网站 +G-WAN Web 服务器....... 142,000 -关注点的分离是设计使然。 内容管理 API 或我们自己的网站中的问题绝不会导致客户网站的中断。 因此，内容的交付应完全自主。 +Lighttpd Web 服务器........ 60,000 -### 内容管理 +Nginx Web 服务器............ 57,000 -[![Teletext.io - editing dynamic content with Amazon Gateway API, DynamoDb and Lambda](img/56374d98b147c3272e5c359b88d7a11b.png)](https://teletext.io/help/introduction "Teletext.io - editing dynamic content with Amazon Gateway API, DynamoDb and Lambda") 内容管理部分是编辑者用来编辑 HTML 和文本的部分。 编辑者只能通过连接到 [AWS IAM](https://aws.amazon.com/documentation/iam/ "AWS Identity and Access Management") 的 [AWS Cognito 身份池](https://aws.amazon.com/cognito/ "AWS Cognito")使用他们的 Google 帐户登录，而该池仅使用 Javascript。 为了加载草稿内容，存储编辑并发布结果，将调用 Amazon API Gateway，从而触发 Lambda 函数。 Lambda 函数全部与单个 API 调用有关，并将其数据存储在 DynamoDb 中。 +Varnish 缓存服务器....... 28,000 -如您所见，没有服务器可能崩溃或卡住。 +SQL Server 2008 R2 Standard 或 Enterprise Edition？ -### 内容传送 +“现在他们正在为 HAProxy Redis 使用更多的 Linux 计算机，” -如前所述，我们决定将内容的交付与编辑功能完全脱钩，因此即使灾难来袭，您的应用程序仍能正常工作。 当编辑者决定将新内容发布到他的应用程序的实时版本时，另一位 Lambda 立即将草稿内容作为平面 JSON 文件复制到 [S3](https://aws.amazon.com/s3/ "AWS S3") ，这是亚马逊用于文件的数据存储。 JSON 文件包含元数据和描述内容的 i18n 本地化 HTML 字符串。 +http://redis.io/clients -[![Teletext.io - publishing static content with S3 and Cloudfront](img/5d8a48f0af1040d1d011158a2b3ba6c0.png)](https://teletext.io/help/introduction "Teletext.io - publishing static content with S3 and Cloudfront") 从此处开始，应用程序中的 Teletext.io 脚本可以通过 [Cloudfront](https://aws.amazon.com/cloudfront/ "AWS Cloudfront") CDN 访问这些文件，从而确保高可用性和高性能。 我们添加了一个巧妙的预取算法，以确保在您需要它们之前在浏览器中检索并缓存了最受欢迎的文件，因此无需实际加载内容即可配置下次点击。 - -由于发布的内容的传递不涉及服务器端逻辑，因此它确实非常快速且实用。 - -### 我们的网站 - -[![Teletext.io static single page app in S3 with proper routing for deeplinking](img/b6e69f89bac3357648c378305d5d719d.png)](https://teletext.io/ "Teletext.io static single page app in S3 with proper routing for deeplinking") 但是[我们的网站](https://teletext.io/ "Teletext.io - content management as a service")呢？ 我们选择了一个简单但有效的概念-再次没有服务器。 该网站是使用 [React 框架](https://facebook.github.io/react/ "Facebook React JS")作为单页应用程序，并使用[作为单个静态文件](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html "Static single-page website in S3")部署到 S3 的。 然后，将 Cloudfront 配置为最上方的内容交付机制，从而确保了来自世界各地许多端点的超快速内容交付。 - -同样，此方法基于平面文件传递，因此非常健壮。 - -静态应用使用 HTML5 pushState 和 React Router 进行 URL 处理。 通常，存在一个问题。 如果您访问根以外的特定 URL，则 Web 服务器必须动态呈现与前端动态呈现的相同的路由。 目前这在 S3 中是不可能的。 但是，我们找到了一个技巧，我们想在这里分享。 - -1. 在 S3 中将应用程序配置为[一个静态网站，其根指向主文件。](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html "Static single-page app in S3") -2. 不要添加任何 S3 重定向规则。 甚至不添加自定义错误页面。 -3. 创建一个指向 S3 存储桶的 Cloudfront 发行版。 -4. 在 Cloudfront 中创建一个自定义错误响应，该响应也指向主文件。 确保执行固定的 200 响应。 - -结果是，所有 URL 路径（根目录除外）均在 S3 中导致 404 响应，然后触发缓存的 Cloudfront 自定义错误响应。 最后的答复只是您的单页应用程序。 现在，在浏览器中，您可以根据当前路径处理所有路由。 - -只有一个缺点。 在任何情况下，您都无法返回实际的 404 HTTP 响应代码。 但是，作为回报，您将获得一个超便宜，超可扩展的单页面应用程序。 - -### 实用津贴 - -使用 Lambda 会对您的开发过程产生影响。 不过，支持正在改善。 例如，以前无法对 Lambda 函数进行版本控制。 这导致测试和部署的风险很大。 但是，亚马逊[最近推出了其版本控制系统](http://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html "Versioning AWS Lambda")，现在我们可以使用*可变别名*。 这意味着现在可以具有可以独立更新的同一功能的不同版本，类似于测试环境还是生产环境。 - -## 结果 - -我们的免费增值服务现已向客户开放。 我们吃自己的狗食，所以我们也用它。 在以下 GIF 中，您可以在我们自己的网站上看到正在使用的功能。 - -[![Teletext.io demo: inline content management inside custom software](img/568b471e6fc11b0d3c14c340d9701f35.png)](https://teletext.io/ "Teletext.io - content management as a service") - -但是，系统的真正可扩展性在我们的每月 AWS 账单中显示。 - -### 成本 - -成本完全取决于实际使用情况。 为简单起见，我们将忽略临时免费层，以及我们使用的许多小型服务。 - -* 使用 **Lambda** ，您**只为您消耗的**计算时间付费-当代码未运行时不收费。 还有一个永久的免费套餐。 -* **Amazon API Gateway** 没有**没有最低费用或启动费用**。 您只需为收到的 API 调用和转移的数据量付费。 -* **DynamoDb** 的费用也基于**按使用量付费**，尽管定价有些复杂。 简而言之，它基于存储，读取和写入。 -* 然后是 S3 和 Cloudfront。 基本上，您需要为存储和带宽付费。 - -我们刚刚开始-为了计算成本，我们做了一些假设。 让我们考虑一个相当大的网站作为我们的普通客户。 我们猜测这样的客户端每月使用 1000 个 API 调用（仅用于编辑），因此需要 1GB 的数据输入，并需要大约 10GB 的与流量相关的数据。 永久性存储我们估计为 500MB。 我们预计 Lambda 执行时间不会超过 2 秒。 - -对于几个不同数量的此类客户，我们的每月费用将如下所示（四舍五入，以美元为单位）。 - -| 顾客 | 网关 API | 拉姆达 | DynamoDb | S3 | 云前 | 总 | -| --- | --- | --- | --- | --- | --- | --- | -| 0 | 0 | 0 | 0 | 0.25 | 1.00 | 1.25 | -| 100 | 9.50 | 0 | 3.50 | 1.50 | 85.00 | 99.50 | -| 1000 | 93.50 | 4.00 | 3.50 | 15.00 | 850.00 | 966.00 | -| 10000 | 935.00 | 35.00 | 3.50 | 150.00 | 8050.00 | 9173.50 | -| 100000 | 9350.00 | 410.00 | 3.50 | 1500.00 | 76700.00 | 87963.50 | - -如您所见，**成本主要由 CDN** 决定，而 CDN 在大流量时变得越来越便宜。 API 和关联的 Lambdas 属性所占的比例要小得多。 因此，如果您构建的服务较少依赖 Cloudfront，则可以做得更好。 - -## 关闭服务器 - -凭借对创造力约束的热爱，我们成功启动了无需维护服务器，自动扩展，负载平衡器和操作系统的初创企业。 这不仅是一个具有几乎无限的峰值容量的真正可扩展的解决方案，而且是一个非常便宜的解决方案-尤其是在牵引力出现之前的早期。 - -所以...服务器崩溃了！ - -[在 HackerNews](https://news.ycombinator.com/item?id=10690842) 上/ [在 Reddit](https://www.reddit.com/r/programming/comments/3vwrf4/on_high_scalability_building_a_company_using_only/) 上 - -先生们， - -很棒的帖子。 我喜欢它！ - -请通过类似的方式检查我们的项目：https://github.com/MitocGroup/deep-microservices-todo-app（无服务器 Web 应用程序）和 https://github.com/MitocGroup/deep-framework（无服务器 Web 框架） 。 如果有兴趣，让我们联系（我的电子邮件地址在 Github 上：） - -最好的祝愿， -尤金一世。 - -由于您没有使用大多数/任何 Cloudfront，因此您是否考虑过改用 Cloudflare 之类的设备，无论系统中有多少客户端，您都需要支付固定费率？ 消除了 Cloudfront 扩展成本 - -耶稣哭了。 - -难以置信。 您能为新手指出一些好的教程吗？ - -可怕。 几乎可以追溯到 80 年代。 - -> 如您所见，没有服务器可能崩溃或卡住。 - -是的，Amazon 完全没有服务器在运行。 而且，您的 Cloudfront 成本是可悲的，并且您不懂工程。 F *** ing 硅谷赶时髦的人。 - -我认为您的 Dynamo 定价不正确。 我无法想象拥有 3.5 万美元/月的 10 万客户的存储和吞吐量。 - -而且，CDN 数量是如此之高，甚至不使用它可能也很有意义。 - -您可以花 7.6 万美元从一级提供商那里购买 10PB CDN 流量。 - -感谢您分享您的故事 Marcel 和 Sander，有趣的方法。 - -请调整您的文章标题，因为*非常*令人误解。 您并不是在谈论无服务器设置，而是在谈论摆脱管理自己的服务器的麻烦。 他们将其称为[平台即服务（PAAS）](https://www.wikiwand.com/en/Platform_as_a_service)。 这不是什么新鲜事物，请参阅已建立的解决方案，例如 [Heroku](https://www.heroku.com/home) 和 [Google App Engine](https://cloud.google.com/appengine/) ，仅提及其中两个。 - -顺便说一句，您还没有真正解决您的大胆挑战＃1（“这项新的商品服务永远都不会失败。 您认为他们不受故障影响吗？ （提示：他们几个月前才遇到问题...）。 通过不必自己维护服务器，当然可以减少错误：许多中断是由系统更新和/或人为错误引起的。 - -我一直在考虑采用这种架构，但我担心的一件事是安全性。 您将所有（通常）服务器端逻辑用于身份验证或数据库访问配置在哪里？ 在每个 lambda 函数内部？ 还是作为每个 lambda 函数随后调用的单独的 lambda 函数（看起来可能是多余的）？ - -我正在为我的雇主开发此模式：API 网关-> Lambda-> DynamoDB。 没有要管理的服务器。 甜。 但这是一个相当新的模式，因此某些主题的文档可能参差不齐。 许可有点麻烦。 但是我明白了：与机架，堆叠和管理我们自己的服务器相比，这看起来更便宜，更可靠（我们每年比 AWS 停机更多）。 可伸缩性问题在该模型中消失了：我可以在免费的 AWS 层上构建整个基于微服务的应用程序，而要将该基础架构扩展到具有数百万用户的全球应用程序所需的唯一事情就是：我的信用卡。 - -哇-一篇相当不错的好文章的评论中有很多无知和仇恨。 - -@Jos de Jung-标题不是*很有误导性，它已经死了。 您只是不了解这些单词的含义，也不了解它们的含义（根据您的其他评论）（提示：它比 PaaS 复杂得多）。 标题为“无服务器**启动**”-表示它们作为启动公司不拥有或租赁任何服务器。 它是 100％准确的。 他们还需要购买在 AWS 服务器上运行的计算时间，存储空间，cdn 等。* - -@the_dude-好像您今天忘记服药了... - -Marcel Panse 和 Sander Nagtegaal-感谢出色的文章和灵感。 我将在下一个项目中积极使用此模型。 祝您好运！ - -嗨，EvanZ，很高兴听到您正在考虑这一点，但您需要做一些阅读工作！ AWS 提供了两种内置机制（Cognito，IAM）以及一种可以调用自己的安全提供者的集成模式。 我当前的实现是使用 Cognito。 - -干杯， - -ws - -这荒谬地更加复杂，并且如果没有更多的话甚至容易失败。 亚马逊仍然可能失败，并且由于使用了这么多服务，因此链中任何地方的任何失败都可能导致问题。 - -小型 EC2 实例可以解决所有这些问题。 为了安全起见，请使用 2 进行故障转移。 对于此应用程序，99％的用户仅在读取数据，因此这两个小型实例将永远永久扩展。 您只需在任何基本的 webapp 框架中进行编程并像往常一样进行部署。 - -Digital Ocean 甚至会更便宜，并且有许多 CDN 都比 CloudFront 便宜。 同样，他们绝对不会推出 50TB 的数据，对于高度可压缩的文本内容来说，这是一个荒谬的带宽。 这就像是说他们将为前 100 个新闻站点提供所有文字一样。 - -另外，他们的商业模式糟透了，因为我看不出谁愿意为此付出代价。 通常，需要编辑的文本（例如 CMS 中的文章）已经具有编辑器。 网站上的文本多长时间随机更改一次？ 即使这样，开发人员仅输入新文本并部署多长时间？ - -糟糕的公司，胡扯的工程和无用的博客文章。 - -我一直在使用相同的模式通过 Angular2 在站点上进行构建。 - -我一直想创建一个个人站点来用作博客，并作为共享项目/设计的垃圾场。 除此之外，我真的不想处理后端的建设，维护和付款。 S3 作为污垢很便宜，并且可以保证 5 9s 的正常运行时间（即比我一个人可以管理的更好）。 - -因此，我创建了一个 Angular2 SPA（单页应用程序），配置了 S3 重定向，并将路径重写添加到了角度路由器。 我真的希望我能引起 Angular 开发团队的注意，以便他们可以改进路由器来处理无服务器的边缘情况，包括 html 历史记录重写。 - -使用 grunt 和 s3 插件可以轻松实现自动化。 就像 Je​​kyll 一样，Markdown 将用作所有内容的格式，不同之处在于没有编译步骤。 我创建了一个 Web 组件，可将 markdown 直接转换为 html（即不久将支持 AJAX 请求的内联缓存）。 - -它正在开发中，但可以在[ [](http://dev.evanplaice.com) 中看到开发版本 - -一旦功能完全正常，我计划写一下该过程：使用 Angular2 / ES6 构建网站； 使用 JSPM； 创建一个 ng2 Web 组件。 在此之前，如果您有兴趣，请随时在 GitHub 上查看我的句柄。 - -这是一个好主意 Giggaflop。 有人在 cloudflare 上这样做吗？ 我很好奇可能会出现什么问题以及它是否会起作用。 谢谢。 - -对于那些正在寻找可以为无服务器架构创建最佳实践的演示 Web 应用程序的人，请查看我们的 SansServer 项目（ [https://github.com/bclemenzi/sans-server](https://github.com/bclemenzi/sans-server) ）。 - -该项目利用在 Maven 安装时使用自定义 Java 注释在 AWS 中自动构建和配置的基于 Java 的 Lambda 函数。 还非常关注支持多个开发人员和环境。 - -我创建了一个新框架，以将 JAVA 应用程序部署到 AWS Lambda + API Gateway 基础架构 - -https://github.com/lambadaframework/lambadaframework - -嘿，马塞尔，感谢您对我们所有人（尤其是我）的教育，这些人在服务器方面都愚蠢，现在我知道很多，这一切都感谢您。 继续写作和分享这样的读物:) - -很棒的帖子。 只是一个问题。 您在项目中的哪里存储图像等？ - -“我们的开发人员舞会具有传奇色彩：在每日站立比赛中，您只能在跳舞时讲话，这是有史以来最高效的会议。” - -你一定是在跟我开玩笑。 - -这是有关此博客文章中涉及的主题的全面分步教程。 - -[http://serverless-stack.com](http://serverless-stack.com) - -后端教程包括有关由 Cognito 保护的 Lambda + API Gateway 的章节。 前端教程包括有关在 S3 + CloudFront + SSL + Route53 自定义域上托管的 React SPA 的章节。 本教程详细介绍了如何构建 CRUD 无服务器 API 并将其完全连接到 AWS 上的 React SPA。 API 函数在 ES6 中，并且已通过 Cognito 用户池进行了身份验证。 它还显示了如何在 S3 上托管您的应用程序以及如何使用 CloudFront 和 Route 53 将其提供服务。这是一个端对端教程，显示了实际的无服务器架构。 - -有趣的帖子。 - -我还在一个后端团队中工作，该团队使用无服务器 AWS Lambda 作为我们的 node.js 后端开发工具。 我们发现，无服务器减轻了我们管理服务器部分（操作部分）的负担。 但是，我们注意到，与使用基于 Express JS 的 node.js 服务器的时间相比，我们的开发速度正在下降。 这是因为我们无法启动在我们自己的本地开发计算机中运行的&服务，也无法在其中调试我们的服务。 无服务器 AWS Lambda 上的调试问题对我们来说很繁琐：它要求我们将代码部署到 AWS 上，调用它，然后通过查看一堆 Cloudwatch 的日志流（我们的代码有一堆 console.log 以了解其中发生了什么）。 基于这个事实，我想听听您的想法，当您无法在本地计算机上运行&无服务器调试代码时，如何提高团队开发效率？ - -干杯。 - -也许尝试从命令行测试代码？ 这是我的方法： - -＃！ / usr / bin / env 节点 - -var question_id =（process.argv.length > = 3）？ process.argv [2]：“ test2”; - -var lambda = require（“ ../ index.js”）; - -var AWS = require（'aws-sdk'）; -AWS.config.loadFromPath（“ ./ awscfg.json”）; - -var context = { -functionName：“ testFunction”， -AWS：AWS， -DB：new AWS.DynamoDB（）， -DBCLIENT：new AWS.DynamoDB.DocumentClient（）， -SES ：新的 AWS.SES（） -}; - -var Decision = {[ -questionId：question_id， -评分：“优秀”， -文本：“哇！” -} - -var request = { -方法：“ acceptProAnswer”， -参数：决策， -ID：1 -} - -lambda.handler（请求，上下文，函数（错误，响应）{ -console.log（“ handler：error：” +错误+“ response：” + JSON.stringify（response））; -}） - -精彩的文章。 对于诸如*不比...* 和*并非真正无服务器*可靠的大量评论，我强烈建议您学习这项技术。 这是我们所有人都使用的技术堆栈-只是配置更智能。 构建 H / A 解决方案并消除 SPOF 几乎是微不足道的。 我关心的是性能，但是在 Lamba 工作了几个月后，我感到非常高兴。 - -很高兴看到其他人继续使用这项技术。 它消除了新技术公司的巨大启动障碍 \ No newline at end of file +Windows 上运行的 C＃如何与 Linux 上的 Redis 对话？ \ No newline at end of file diff --git a/docs/61.md b/docs/61.md index 9de8dfc..036fae4 100644 --- a/docs/61.md +++ b/docs/61.md @@ -1,360 +1,181 @@ -# Google 和 eBay 关于构建微服务生态系统的深刻教训 +# Medialets 体系结构-击败艰巨的移动设备数据 -> 原文： [http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html](http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html) - -![](img/a743567657a0afdf4d56885ba6c39304.png) - -当您查看 Google，Twitter，eBay 和 Amazon 的大型系统时，它们的体系结构已演变为类似的东西：**一组多语言微服务**。 - -当您处于多语言微服务最终状态时，会是什么样？ [Randy Shoup](https://www.linkedin.com/in/randyshoup) 曾在 Google 和 eBay 的高层职位上进行过非常有趣的演讲，探讨了这个想法：[大规模服务体系结构：Google 和 eBay 的经验](http://www.infoq.com/presentations/service-arch-scale-google-ebay)。 - -我真正喜欢 Randy 的演讲的是，他如何自我意识地使您沉浸于您可能没有经验的事物的体验中：创建，使用，持久化和保护大型体系结构。 - -在演讲的*服务生态系统*部分中，Randy 问：拥有一个多语言微服务的大规模生态系统看起来像什么？ 在*大规模运营服务*部分中，他问：作为服务提供商，运营这样的服务感觉如何？ 在*建立服务*部分中，他问：当您是服务所有者时，它是什么样的？ 在 *Service Anti-Patterns* 部分中，他问：哪里会出问题？ - -一个非常强大的方法。 - -对我来说，这次演讲的重点是**，**，**激励动机，**，一致主题的想法，这些主题贯穿了整个工作。 尽管从来没有明确地提出将其作为单独的策略，但这是为什么您希望小型团队开发小型清洁服务，内部服务的收费模型如此强大，架构如何在没有架构师的情况下可以发展，清洁设计可以如何发展的背后动机。 从下至上的过程，以及没有中央委员会如何发展标准。 - -我的收获是**动机的故意调整是您如何扩展大型动态组织和大型动态代码库**。 引入适当的激励措施[会使](https://en.wikipedia.org/wiki/Nudge_(book))事情在没有显式控制的情况下发生，几乎就像在删除锁，不共享状态，与消息进行通信并并行化所有内容时，分布式系统中的更多工作一样 。 - -让我们看看现代系统是如何构建大规模系统的。 - -## 多语言微服务是终局游戏 - -* 大型系统最终演变成看起来非常相似的东西： **一组多语言微服务** 。 多种语言意味着微服务可以用多种语言编写。 - -* **eBay** 成立于 1995 年。根据您的计算方式，它们属于其体系结构的第 5 代。 - - * 最初是创始人在 1995 年劳动节周末写的一个整体式 Perl 应用程序。 - - * 然后，它移至一个整体的 C ++应用程序，最终在单个 DLL 中包含了 340 万行代码。 - - * 以前的经验促使人们转向 Java 中分布更分散的分区系统。 - - * 当今的 eBay 具有相当多的 Java，但是一组多语言的微服务。 - -* **Twitter** 的演变非常相似。 根据您的计算方式，它们取决于其体系结构的第三代。 - - * 开始于单片 Ruby on Rails 应用程序。 - - * 在前端转移到 Javascript 和 Rails 的组合，在后端转移了很多 Scala。 - - * 最终，他们已经迁移到我们今天所说的一套多语言微服务。 - -* **Amazon** 遵循类似的路径。 - - * 从单片 C ++应用程序开始。 - - * 然后用 Java 和 Scala 编写的服务。 - - * 最后得到了一组多语言微服务。 - -## 服务生态系统 - -* 拥有多语种微服务的大规模生态系统看起来如何？ - -* 在 eBay 和 Google 上，成百上千的独立服务一起工作。 - - * 现代大型系统以关系图而不是层次结构或层级集合来构成服务。 - - * 服务依赖于许多其他服务，同时又依赖于许多服务。 - - * 较旧的大型系统通常按严格的等级进行组织。 - -### 如何创建服务生态系统？ - -* 这些性能最佳的系统比智能设计更是进化的**产品。 例如，在 Google，从来没有一个集中的自上而下的系统设计。 随着时间的流逝，它以一种非常有机的方式进化和成长。** - -* 变异和自然选择。 当需要解决问题时，会创建新服务，或更经常地从现有服务或产品中提取新服务。 **服务只要被使用**就可以生存，只要它们能够提供价值，否则它们将被弃用。 - -* 这些大型系统**从下至上**发展。 **干净的设计可以是一种紧急特性，而不是自上而下的设计**的产物。 - -* 作为示例，请考虑 Google App Engine 的一些服务分层。 - - * Cloud Datastore（NoSQL 服务）基于 Megastore（地理规模结构化数据库），Megastore 基于 Bigtable（集群级结构化服务）构建，Bigtable 基于 Colossus（下一代集群文件系统）构建 ）（基于 Borg（集群管理基础架构）构建）。 - - * 分层很干净。 每个图层都会添加不属于下方图层的内容。 它不是自上而下设计的产品。 - - * 它是自下而上构建的。 Colossus，首先建立了 Google 文件系统。 几年后，Bigtable 建成了。 几年后，Megastore 建成了。 几年后，云数据库迁移到 Megastore。 - - * 如果没有自上而下的体系结构，则可以将关注点分离得如此美妙。 - -* **这是没有架构师**的体系结构。 Google 的所有人都没有 Architect 的头衔。 技术决策没有中央批准。 大多数技术决策是由各个团队根据自己的目的在本地做出的，而不是全球范围内做出的。 - -* 与 2004 年的 eBay 形成对比。有一个体系结构审查委员会，该委员会必须批准所有大型项目。 - - * 通常，只有在更改项目为时已晚时，他们才参与项目。 - - * 集中批准机构成为瓶颈。 通常，它唯一的影响是在最后一分钟说不。 - -* eBay 处理此问题的更好方法是**在审查委员会中编码聪明有经验的人的知识**，然后将**放入各个团队可以重用的**。 将这些经验编码到一个库或服务中，或者甚至是一组指南，人们可以自己使用它们，而不必在最后一刻才进入流程。 - -### 没有架构师，标准将如何发展？ - -* 没有中央控制的**可能最终以**标准化。 - - * 服务和公共基础架构之间的通信趋向于发生**标准化。** - - * 标准之所以成为标准，是因为它们比替代的更适合**。** - -* 通常标准化的通信部分： - - * **网络协议**。 Google 使用称为 [Stubby](https://www.quora.com/What-functionality-does-Google-have-around-Protocol-Buffers-that-isnt-included-in-the-current-public-release) 的专有协议。 eBay 使用 REST。 - - * **数据格式**。 Google 使用协议缓冲区。 eBay 倾向于使用 JSON。 - - * **接口模式标准**。 Google 使用协议缓冲区。 对于 JSON，有 JSON 模式。 - -* 通常标准化的常见基础设施： - - * 源代码控制。 - - * 配置管理。 - - * 集群管理器。 - - * 监视系统。 - - * 警报系统。 - - * 诊断工具。 - - * 所有这些组件都可能脱离约定。 - -* 在进化环境中，**通过**来实施标准：代码，鼓励，代码审查和代码搜索。 - - * 鼓励最佳实践的最简单方法是通过实际代码。 这与自上而下的审查或前期的设计无关，而是与某人产生的代码可以轻松完成工作有关。 - - * 鼓励是通过**团队提供一个库**来进行的。 - - * 鼓励也是通过您要依赖于支持 X 协议或 Y 协议的服务获得的。 - - * Google 以**闻名，每一行代码**都已签到至少要由另一位程序员检查过的源代码控件**。 这是交流常规做法的好方法。** - - * 除少数例外，Google 的每个工程师都可以**搜索整个代码库**。 当程序员试图弄清楚如何做某事时，这是一个巨大的附加值。 在拥有 1 万名工程师的情况下，您很可能会尝试做某人以前已经做过的事情。 这允许从一个区域开始的**最佳实践通过代码库**传播。 它还允许错误传播。 - -* 为了鼓励通用做法和标准化约定**，做正确的事情**真的很容易，而做错事情的难度会更大。 - -* 各个**服务彼此独立。** - - * Google 没有**来标准化服务内部**。 服务是外面的黑匣子。 - - * 存在约定和通用库，但是没有编程语言要求。 通常使用四种语言：C ++，Go，Java，Python。 许多不同的服务都以各种语言编写。 - - * 框架或持久性机制尚无标准化。 - -* **在成熟的服务生态系统中，我们标准化了图的弧线，而不是节点本身。** 定义一个通用形状，而不是通用实现。 - -### 创建新服务 - -* 新服务的使用已得到证实，便会创建它们。 - -* 通常针对一个特定用例构建了一项功能。 然后发现功能是通用且有用的。 - - * 组成了一个团队，并将服务分解为自己的独立单元。 - - * 仅当一项功能成功并且适合许多不同的用例时，才会发生这种情况。 - -* 这些**体系结构通过实用主义**得以发展。 没有人坐在高处，说应该增加一项服务。 - -* Google 文件系统支持搜索引擎。 分布式文件系统更普遍可用也就不足为奇了。 - -* Bigtable 最初支持搜索引擎，但用途更为广泛。 - -* Megastore 是作为 Google 应用程序的存储机制而建立的，但用途更为广泛。 - -* Google App Engine 本身由一小组工程师启动，他们认识到需要帮助来构建网站。 - -* Gmail 来自内部项目，该项目在内部非常有用，然后被其他人外部化。 - -### 淘汰旧服务 - -* 如果不再使用服务会怎样？ - -* 可以重新利用的技术被重用。 - -* 人们可以被解雇或重新部署到其他团队。 - -* Google Wave 在市场上并不成功，但是其中一些技术最终出现在 Google Apps 中。 例如，多人编辑文档的能力来自 Wave。 - -* 更常见的情况是核心服务要经过多代，而旧代则已弃用。 Google 经常发生这种情况。 变化是如此之大，以至于 Google 内部的每项服务似乎都已被弃用或尚未准备就绪。 - -## 建立服务 - -* 当您是服务所有者时，在多语言微服务的大规模系统中构建服务时会是什么样？ - -* 大型体系结构中性能良好的服务是： - - * **通用**。 它将具有一个简单的定义明确的界面。 - - * **模块化且独立的**。 我们可以称之为微服务。 - - * **不共享持久层**。 稍后再详细介绍。 - -### 服务所有者的目标是什么？ - -* **满足客户的需求** 。 以适当的质量级别提供必要的功能，同时满足协商的性能级别，同时保持稳定性和可靠性，同时不断改进服务。 - -* **以最小的成本和精力满足需求** 。 - - * 该**目标以鼓励**使用通用基础结构**的方式调整激励**。 - - * 每个团队的资源有限，因此要利用经过战斗测试的通用工具，流程，组件和服务符合他们的利益。 - - * 它还可以激发良好的操作行为。 自动构建和部署服务。 - - * 它还鼓励优化资源的有效利用。 - -### 服务所有者的职责是什么？ - -* **生成并运行**。 - - * 团队通常是一个小团队，拥有从设计到开发和部署，一直到退休的服务。 - - * 没有单独的维护或维护工程团队。 - - * 团队可以自由选择自己的技术，方法和工作环境。 - - * 团队应对自己做出的选择负责。 - -* **服务作为有界上下文**。 - - * 团队的**认知负担是有限的**。 - - * 无需了解生态系统中的所有其他服务。 - - * 团队需要深入了解其服务及其所依赖的服务。 - - * 这意味着**团队可以非常小巧和敏捷**。 一个典型的团队是 3-5 人。 （此外，美国海军陆战队 [消防队](https://en.wikipedia.org/wiki/Fireteam) 有四个人。） - - * 较小的团队规模意味着团队内部的通信具有很高的带宽和质量。 - - * 康韦定律对您有利。 通过组织小型团队，您最终将只有几个单独的组件。 - -### 服务之间是什么关系？ - -* 即使您在同一家公司，也可以将服务之间的**关系视为供应商-客户关系**。 - -* 要非常友好和合作，但在关系中要有条理。 - -* 要非常清楚所有权。 - -* 要非常清楚谁对什么负责。 在很大程度上，这与定义一个清晰的界面并进行维护有关。 - -* **激励措施是一致的，因为客户可以选择是否使用服务**。 这鼓励服务由其客户来做。 这是最终构建新服务的方式之一。 - -* 定义 SLA。 由于服务提供商向其客户承诺一定水平的服务，因此客户可以依赖该服务。 - -* **客户团队为服务**付费。 - - * **为服务收费符合经济激励**。 它激励双方在资源使用方面非常高效。 - - * 当事物为**时，我们倾向于不对其进行估价，也不倾向于对其进行优化**。 - - * 例如，一个内部客户免费使用 Google App Engine，他们使用了大量资源。 要求他们提高其资源使用效率不是一个好策略。 退款开始后一周，他们就可以通过一两个简单的更改将其 GAE 资源消耗减少 90％。 - - * 使用 GAE 的团队并不是邪恶的，他们还有其他优先事项，因此没有动力去优化 GAE 的使用。 事实证明，使用更高效的体系结构，它们实际上获得了更好的响应时间。 - - * **收费还激励服务提供商保持较高的质量**，否则内部客户可能会去其他地方。 这直接激励了良好的开发和管理实践。 代码审查就是一个例子。 Google 的大规模构建和测试系统是另一个。 Google 每天都会运行数百万次自动测试。 每次在存储库中接受代码时，都会对所有相关代码进行验收测试，这有助于所有小型团队保持其服务质量。 - - * 退款模型**鼓励进行小幅增量更改**。 较小的更改更容易理解。 同样，代码更改的影响是非线性的。 千行变更的风险比 100 行变更的风险高 10 倍，而风险高出 100 倍。 - -* **保持接口**的完全向后/向前兼容性。 - - * 请勿破坏客户端代码。 - - * 这意味着维护多个接口版本。 在某些讨厌的情况下，这意味着维护多个部署，一个部署用于新版本，其他部署用于旧版本。 - - * 通常由于增量更改较小，因此不会更改接口。 - -* 具有明确的弃用策略。 然后，强烈希望服务提供商将所有客户端从版本 N 移到版本 N + 1。 - -## 大规模运营服务 - -* 作为服务提供商，在多语言微服务的大规模系统中操作服务的感觉如何？ - -* **可预测的性能是一项要求。** - - * 大规模服务**非常容易受到性能变化**的影响。 - - * **性能的可预测性**比平均性能重要得多。 - - * 性能不一致的低延迟实际上根本不是低延迟。 - - * 当客户提供一致的性能时，对它进行编程很容易。 - - * 由于服务使用许多其他服务来执行其工作，因此尾巴延迟主导着性能。 - - * 想象一下，一个服务在中值处有 1 毫秒的延迟，而在 99.999％的位置（万分之一），延迟是一秒。 - - * 拨打一个电话意味着您的时间慢了 0.01％。 - - * 如果您使用的是 5,000 台计算机（就像 Google 的许多大型服务一样），那么您的速度就会降低 50％。 - - * 例如，memcached 的百万分之一问题被追溯到低级数据结构重新分配事件。 随着等待时间的增加，这个罕见的问题浮出水面。 事实证明，像这样的低级细节在大型系统中非常重要。 - -* 深度弹性。 - - * 服务中断更有可能是由于人为错误而不是硬件或软件故障引起的。 - - * 对机器，群集和数据中心的故障具有弹性。 - - * 调用其他服务时进行负载平衡并提供流量控制。 - - * 能够快速回滚更改。 - -* 增量部署。 - - * **使用金丝雀系统**。 不要一次部署到所有计算机。 选择一个系统，将该软件的新版本放在该系统上，然后查看其在新世界中的行为。 - - * 如果**有效，则开始分阶段推出**。 首先是 10％的机器，然后是 20％的机器，以此类推。 - - * 如果在部署中的 50％点发生问题，那么您应该能够回滚。 - - * eBay 使用**功能标志将代码部署与功能部署**分离。 通常，代码是在功能关闭的情况下部署的，然后可以将其打开或关闭。 这样可以确保在启用新功能之前可以正确部署代码。 这也意味着，如果新功能存在错误，性能问题或业务故障，则可以在不部署新代码的情况下关闭该功能。 - -* 您可能会发出太多警报，而您永远不会受到太多监视。 - -## 服务反模式 - -* **大型服务** - - * 一项服务过多。 您想要的是一个非常小的清洁服务生态系统。 - - * 做得太多的服务就是**只是另一个整体**。 难以推理，难以扩展，难以更改，并且还会创建比您想要的更多的上游和下游依赖项。 - -* **共享持久性** - - * 在分层模型中，服务放在应用程序层中，而持久层则作为通用服务提供给应用程序。 - - * 他们在 eBay 上进行了此操作，但**无效**。 它**破坏了服务的封装**。 应用程序可以通过更新数据库将**后门连接到您的服务**中。 最终导致重新引入服务耦合。 共享数据库不允许松散耦合的服务。 - - * 微服务通过小巧，隔离和独立来防止此问题，这是使生态系统保持健康和成长的方式。 +> 原文： [http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html](http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html) + +![](img/b609dec47ec10f6f65a98e5a592cac1e.png) + +移动开发人员面临着巨大的扩展问题：对来自数百万个设备的大量连续遥测数据流进行有用的处理。 这是一个非常好的问题。 这意味着智能手机的销售终于实现了他们的命运：[在销售领域屠宰 PC](http://www.mobiledia.com/news/81680.html) 。 这也意味着移动设备不再只是简单的独立应用程序的容器，它们正成为大型后端系统的主要接口。 + +尽管开发人员现在在客户端进行移动开发，但他们面临的下一个挑战是如何对那些棘手的后端位进行编码。 目前面临同样问题的公司是 [Medialets](http://www.medialets.com/) ，这是一种移动富媒体广告平台。 他们所做的是帮助发布商制作高质量的互动广告，尽管就我们的目的而言，他们的广告内容并不那么有趣。 对于他们的系统，我确实感到非常有趣的是他们如何解决克服移动设备数据泛滥的问题。 + +每天，Medialets 都需要处理数十亿个新对象，这些对象嵌入了数百万兆个原始事件数据流中，而这些数据又是从数百万个移动设备流入的。 所有这些数据必须是：在移动设备上生成的； 通过长时间断开连接而中断的有损连接进行传输； 紧缩 提供给报告系统； 反馈到必须能够在几毫秒内响应请求的控制系统中。 + +这将成为具有移动设备的系统的常见范例。 问题是，如何实现它？ + +现在很有趣。 + +为了帮助我们更多地了解 Medialets 的工作原理，Medialets 服务器平台的工程经理 Joe Stein 很友好地向我介绍了他们在做什么。 Joe 还运行了一个出色的 Hadoop 播客和博客，名为 [All Things Hadoop](http://allthingshadoop.com/) ，请查看。 + +Joe 在这个问题上做了很多工作，并且对如何使用诸如 Hadoop，MySQL，HBase，Cassandra，Ruby，Python 和 Java 之类的工具构建有效的移动数据处理器有一些很棒的想法。 + +## 现场 + +* [http://www.medialets.com](http://www.medialets.com/) -主页。 +* [http://www.medialytics.com](http://www.medialytics.com/) -用于分析来自应用程序事件的见解仪表板。 + +## 什么是 Medialets？ + +Medialets 将富媒体广告投放到 iPhone，iPad 和 Android 等移动设备。 富媒体意味着广告可以是使用 SDK，事件生成和广告功能嵌入的复杂应用程序。 这个想法是，广告可以在平台内运行，而不是 being 脚的 adsense 型广告，它们可以完全互动，同时提供与电视相同的品牌质量，但在移动设备上除外。 应用程序可以让您做一些事情，例如摇动设备或与 Michael Strahan 玩足球比赛。 所有这些活动都会生成必须流回其服务器场以进行处理的数据。 + +除了广告外，他们还为发布商提供非常详细的基于[应用程序的分析](http://www.medialytics.com/)。 + +要查看其广告的示例[，请点击此处](http://www.medialets.com/showcase)。 + +## 统计资料 + +* 每天有 2-3 TB 的新数据（未压缩）。 +* 每天创建数百亿个分析事件。 事件表示有人摇晃，关闭，旋转等应用程序。 +* 200 多个高级应用程序在数以千万计的移动设备（iPhone，iPad 和 Android）上运行。 +* 已经处理了超过 7,000 亿个分析事件。 +* 在典型的 MapReduce 作业中，每秒可以处理超过一百万个事件 +* 通常在 [www.medialytics.com](http://www.medialytics.com/) 中可以从移动设备收到数据 +* 总共约有 100 台服务器。 +* 移动电话正在增长。 智能手机[的销售量首次超过了个人电脑](http://www.mobiledia.com/news/81680.html)的销售量，而 Medialets 的销售量却在增长。 iPhone，iPad 和 Android [设备在 2010 年第四季度增长了近](http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/) 300％。Android 继续增长市场份额，但 iOS 仍占据着高端手机库存的主导地位。 +* 有十几个人在从事工程，主要是在客户端和 Medialytics 上。 基础架构团队为 1-2 人。 + +## 基础设施 + +* 在四核 x 16GB / 1TB 上运行的 Ad Server 实例 +* 16 核心 x 12 GB（含 10TB）的事件跟踪服务器 +* 事件处理，作业执行，日志收集&聚合对每个 16 核 24GB RAM / 6TB 空间进行预处理 +* 日志收集&汇总了预处理和后处理。 Hadoop 群集节点各有 16 个核心 x 12GB RAM（含 2x2TB（JBOD））。 +* [www.medialytics.com](http://www.medialytics.com/) 各种配置都具有 16 个内核，从 12 到 96GB RAM 带有 1-2TB + +## 开源系统&生产工具 + +* 的 Linux +* 灭螺 +* 雄猫 +* 的 MySQL +* 阿帕奇 +* 乘客 +* 收益率 +* 记忆快取 +* 德语 +* Hadoop 的 +* 猪 +* 纳吉奥斯 +* 神经节 +* 走 +* 吉拉 + +## 语言能力 + +* C / C ++-广告服务器 +* Java-数据转换 +* Ruby-很多服务器端 Ruby。 Ruby 可能比 C ++更多，但更多地转向了 Python。 +* Python-许多 MapReduce 正在使用 [Python 流](http://allthingshadoop.com/2010/12/16/simple-hadoop-streaming-tutorial-using-joins-and-keys-with-python/)移入 Python。 +* 阶梯 +* 重击 + +## 建筑 + +* 该系统构建了几年，主要使用定制软件，尽管他们使用 Hadoop 来承担分析方面的繁重任务，并使用 MySQL 作为数据库。 定制软件在开始时就需要扩展，但是随着这些产品的发展，他们现在正在考虑使用更多现成的产品。 +* 该系统是实时的，因为随着数据的滴入，报表中的数据将尽可能快且尽可能真实。 +* 不是基于云的。 它们在物理硬件上运行。 他们无法在云中的多租户环境中完成所需的工作。 具有 16 个核和 TB 级磁盘空间的计算机几乎是不够的。 他们花费大量时间来构建软件，以充分利用硬件，磁盘 IO，CPU，并行处理的优势，并充分利用内存。 +* 他们所做的一切（几乎）都是异步的。 您无需连接到网络即可查看广告或让他们捕获分析。 广告可以在广告系列开始之前几周投放（预定），您也可以乘坐地铁，仍然可以看到广告。 广告期间收集的数据最终会传递到服务器端。 +* 发布者负责构建应用程序，并集成到 Medialets SDK 中。 该 SDK 特别适用于分析和广告。 当他们想要运行分析或在广告位中运行广告时，他们使用 Medialets 的工具。 +* 共有三个基本子系统：广告投放，事件处理和报告。 +* 服务器分为以下几层： + * 前向层： + * 广告投放层-专为运行广告服务器而设计。 + * 跟踪层-处理数据转储和数据加载。 + * 异步处理层： + * Hadoop 集群-在其自己的服务器集上运行。 + * Java 和 Ruby 流程-接收传入的数据，并将数据转换为 Hadoop 可用的形式，以进行不同的聚合。 +* 使事情保持精简和卑鄙，并仅根据需要提供尽可能多的冗余。 + * 硬件是根据软件的功能进行配置的。 并非所有机器都是高端或低端。 系统的不同部分具有不同的硬件需求。 + * 响应广告服务请求时，磁盘 IO 或计算量很少。 有一个 C ++服务在静态内存上进行查找。 因此，广告投放机具有大量内存和低端处理器。 + * 在有数据接收的地方，它们有许多套接字阻塞并写入磁盘，因此它们只需要很少的内存。 + * Hadoop MapReduce 层需要您提供的所有功能。 +* 事件处理流程如下所示： + * 移动设备上的应用程序会生成事件。 有应用程序事件，广告事件和自定义事件。 定制事件可以由应用程序创建为键-值对，它们将在此基础上聚合，而无需定制编码。 + * 跟踪服务器接收事件并将其写入对象的日志文件。 这些文件表示收集事件数据的时间快照，例如 7 分钟。 + * Java 服务器读取这些文件，解压缩它们并通过一系列线程池运行对象，以便将它们转换并与所有必要的元数据合并。 不同的流程将拾取不同的事件类型并对其进行处理。 + * 上一步创建一个新文件，其中该事件在与元数据合并后现在已完成。 该新文件被推送到 HDFS（Hadoop 使用的文件系统）中。 + * MapReduce 在这些 HDFS 文件上运行以对数据进行重复数据删除。 重复数据删除发生后，数据集是干净的。 + * MapReduce 作业生成数据，然后将其导入到分析 UI 可提供给客户的数据库中。 运行数十种不同类型的聚合。 通过 Medialytics 提供了标准指标，可以从广告和应用报告的角度显示应用的运行状况。 它们沿着许多不同的维度进行汇总，例如，按设备和平台进行汇总。 其中一些数据是对广告投放系统的反馈。 +* 数据复制是移动设备和异步系统上的关键设计点。 + * 手机操作系统无法保证应用程序会获得时间来生成事件。 在 OnClose 挂钩中，发布者将运行一些清除逻辑，Medialets 具有一些清除逻辑，然后将事件写入服务器，这需要花费几毫秒的时间来响应，然后本地应用程序必须更新本地数据库。 即使这是一个快速的旅程，您仍处于 15 毫秒的窗口中，在该窗口中，操作系统无法保证所有功能都将执行。 操作系统可能会终止进程或崩溃。 根据失败发生的位置，这将导致重播事件重复。 iPhone 的新后台功能使记帐变得复杂。 如果某个应用程序在后台运行了 30 秒或更短的时间，则仍被认为是同一次运行。 有很多变化。 + * 关机 3 个月的手机仍然可以输入数据。 他们必须能够知道自己是否曾经看过这些数据，如果不经常使用应用程序，这种情况很常见。 + * Hadoop 用于计算指标和聚合，但也用于重复数据删除。 在处理数据时，他们每秒查看超过一百万个事件以对数据进行重复数据删除。 他们每天都会收到 100 亿个事件。 他们必须查看每个事件并确定是否：1）他们之前看过事件； 2）他们是否要在他们正在处理的数据集中再次看到该事件。 使用 MapReduce 可以将数据分散在一堆服务器上，这意味着您直到减少所有重复数据的所有工作后才真正知道。 +* 广告 + * 某些类型的事件数据是实时流回的。 对于另一类数据，必须在创建事件之前打开和关闭事件。 例如，要知道某人一天使用一次应用的次数，必须有一个打开事件和一个相应的关闭事件。 + * 移动世界中的用户确实是独一无二的。 在 Internet 世界中，除非已登录，否则几乎无法量化用户。 电脑被很多人使用，您无法真正确定谁在使用设备。 像电话这样的物理设备通常由一个人使用，因此，基于设备的聚合实质上就是基于用户的聚合。 + * 他们可以收集不同维度的统计数据，例如转化数据。 他们可以告知某人从该操作系统的版本升级到另一版本需要多长时间。 谁是不同类型的人？ 然后，他们可以将其覆盖到他们拥有的不同类型的应用程序中。 + * 广告既可以是品牌广告也可以是直接响应广告，两者混合。 例如，当电影广告被点击而不是去网站时，它可以从设备中调出本地应用程序。 这样您就可以在应用程序中直接购买门票。 具有不同的拦截器并具有创建丰富的用户体验的能力，从而可以通过新方式将交互流货币化。 + * 启动应用程序后，应立即显示广告。 异步用于将数据推送到服务器，但可以同步投放广告。 许多应用程序在打开时都会看到赞助商徽标，并且必须立即提供。 第一个 onload 调用是获取广告的同步调用。 他们的广告投放系统可以在 200 毫秒内以 3％的差异投放广告。 +* 由于它们将数据存储在[压缩序列文件](http://blog.mgm-tp.com/2010/04/hadoop-log-management-part2/)中，因此节省了 70％-80％的存储成本。 + * HDFS 具有序列文件格式。 压缩可以基于行或块进行。 假设您有一个包含 10 个块的序列文件，并且一个块定义为将进入映射器的数据（对于 MapReduce）。 如果压缩是在块级别上，并且有 10 个块，则可以将这 10 个块并行推送到映射器，HDFS 将自动处理所有解压缩和流传输。 + * 可将来自 reducer 的数据存储在序列文件中，例如它是重复数据删除过程的结果，或者可以以未压缩的格式存储，可以将其加载到另一个数据库中。 + * 许多人不压缩数据。 要使用 Hive，必须解压缩数据，以便您可以与之交互。 这取决于您要花多少钱以及您希望在哪里发挥系统效率低下的作用。 + * 将大量数据以未压缩格式存储在磁盘上是一个弊端。 他们有选择地决定使用哪种格式，具体取决于与将数据保留在磁盘上多长时间相比，解压缩阶段是否值得承担这些开销。 +* 工作执行系统 + * 内置 Ruby，然后再提供合适的现成系统。 + * 他们建立了作业处理系统来实施工作流处理。 工作流是一组具有不同任务和步骤并针对不同事件进行操作的作业。 必须以许多不同的方式处理应用程序数据，并且结果必须进入几个不同的系统，一些进入表，有些进入其他报告系统。 所有这些都是自动化和脚本化的。 +* 聚合数据存储在 MySQL 中，供发布者和广告商查看。 它们达到了可以分片的极限。 他们正在研究 MongoDB 和 GridFs（属于 MongoDB）。 + * GridF 看起来可以很好地存储，扩展和提供其媒体文件，这使他们考虑使用 MondoDB 来存储聚合结果集。 + * 他们还在寻找 Cassandra 和 HBase 来存储其汇总结果集。 他们会考虑将相同的基础结构也用于其跟踪和事件捕获服务器，这些服务器目前完全是自定义编写的。 + * Cassandra 看起来很有吸引力，因为它可以跨多个数据中心工作。 他们将使用此功能在同一个 dacenter 中拥有多个集群，并在一个集群中进行写操作，而在另一个集群中进行读操作，因此不同的流量负载不会互相影响。 他们不想混合使用不同类型的流量，因此他们不想在同一台计算机上执行 MapReduce 作业，从 HBase 写入和从 HBase 读取。 + * HBase 是一种有吸引力的选择，因为它们已经将大量数据写入 HDFS，以至于那些文件在 HBase 中可用将令人兴奋。 他们在 fsync 方面存在可靠性方面的担忧，以确保将数据写入磁盘，但是这些担忧已在最近的发行版中得到解决。 HBase 不允许按不同用途对数据进行分区，这对 Cassandra 来说是有吸引力的，因为 Cassandra 支持在群集中具有不同种类的机架。 + * 由于他们已经在使用 HDFS，因此在处理完所有数据后将所有数据移入 Cassandra 并不吸引人，这会使他们的硬盘需求增加一倍。 + * 他们喜欢[协处理器](http://highscalability.com/blog/2010/11/1/hot-trend-move-behavior-to-data-for-a-new-interactive-applic.html)的想法，因此不必在网络上移动数据。 每个作业为 2-3 TB，因此真正实现并行化而无需移动数据非常有吸引力。 + * [TTL 删除在 Cassandra 中的](http://www.quora.com/Which-NoSQL-stores-have-good-support-for-LRU-or-TTL-semantics-in-storage)非常吸引人。 Cassandra 可以轻松处理其写负载，因此可以用来存储传入的事件。 然后，所有工作流程都可以从 Cassandra 中取出移动数据，将其与其他数据库中的元数据合并，以创建完全连接的对象，然后可以将其写入 HBase，然后可以进行 MapReduce 聚合并写入结果 到 MongoDB。 + * 另一种重复数据删除设计是将其全部写入 HBase，然后选择最后一个作为赢家。 一旦这些系统就位，他们将重新考虑一些现有流程，以了解如何利用它们。 + * 为了确定他们是否应该保留现有软件，迁移到另一个数据库还是使用 MySQL，进行了大量的原型尝试。 他们可能最终会使用 MongoDB，Cassandra 和 HBase，他们只是想为正在构建的新产品找到正确的功能组合，并弄清楚它们如何能够继续扩展而不会占用大量开发人员时间。 +* AdServer 用 C ++编写 + * 该层提供了标准的广告投放时间安排功能，因此可以将广告映射到广告位，旋转广告，定位广告等。定位可以基于平台，分辨率，地理位置和其他尺寸。 + * 有一个用于数据库数据的对象缓存，用于制定广告投放决策。 + * 99％的时间缓存足够，而他们有 1％的时间访问数据库。 + * 读取时间只有几微秒，但当必须访问数据库时，读取时间会增加到 200 微秒。 + * 还负责安排广告投放进度，以便可以在应用的整个生命周期内投放广告系列。 例如，如果某个应用每天运行一百万次，而该广告系列获得了一百万次展示，则他们不想在一天内耗尽它。 假设广告客户希望广告系列投放一个月。 广告服务器查看分析数据，然后提出费率请求，以计算应投放的步伐广告。 + * 许多决定都是预先计算的。 人将放置目标，说出应在何处显示添加项。 + * 诸如地理分布之类的决策是动态计算的。 例如，如果您要投放一组广告印象，则需要一些去加拿大，一些去美国。 +* Java 服务器 + * 将元数据与传入的数据集连接起来。以 95％的命中率从缓存中提取元数据。 例如，当他们有一个新的广告上线时，他们将访问数据库。 + * 进入数据库后，他们希望尽可能乐观，并尽可能减少线程的中断，因此在进行非常繁重的读取操作和写入次数很少时，它们使用原子变量和 CAS（比较并设置）。 此开关将性能提高了 15％-20％，因为它们不再阻止写入。 + * 他们对读取的数量进行了基准测试，发现 Mutex 花了很长时间。 信号量最终阻止了作者。 假设有 10 个线程，其中 9 个可以读取，因此没有线程会阻塞，但是第 10 个线程必须写入，它将阻塞所有线程。 与循环执行比较和设置相比，这增加了延迟，并且效果不佳。 这是有可能的，因为它们不断处理 JVM 内某些被阻止的千兆字节数据。 + * 使用[并发备注模式](http://javathink.blogspot.com/2008/09/what-is-memoizer-and-why-should-you.html)创建用于处理缓存请求的线程池。 缓存是一个池，将在需要时加载数据。 负载使用 CAS 来阻止正在发生的实际读取。 + * [SEDA](http://www.eecs.harvard.edu/~mdw/proj/seda/) 用于通过所有不同的转换处理数据。 每个线程池对一块数据执行状态转换，然后将数据转发到另一个线程池以进行下一个转换。 例如，第一步是从磁盘读取数据并将其序列化到对象阵列上。 这些操作对延迟不敏感。 +* 使用 Ruby + * 使用 Ruby 时，必须有效地实现真正的多进程功能。 + * [Rinda](http://en.wikipedia.org/wiki/Rinda_(Ruby_programming_language)) 用于在分支过程之间创建并发。 有时使用数据库进行协调。 + * 这隐藏了解释程序常见的任何内存泄漏问题或绿色线程问题。 +* 监控方式 + * 内部工具和 Nagios 的混合。 + * 与 Ganglia 跨所有不同层级对自己的日志进行大量趋势分析。 + * 他们采取了非常主动的监视方法，并花费了大量的 R & D 努力，因此他们可以在发生问题之前就知道他们有问题。 + * 趋势式饲料进入他们的监测。 如果他们的一台广告服务器在 10 毫秒内停止响应，在一秒钟内响应超过 1 或 2 个请求，则他们需要知道这一点。 + * 如果请求延迟平均要从 200 毫秒增加到 800 毫秒，那么他们想知道。 + * 它们记录了很多日志，因此通过日志进行问题调试。 + +## 得到教训 + +* ****将数据转化为产品**。** Development 知道他们拥有的数据。 该知识可用于帮助产品团队创建新产品以销售给客户。 R & D 与业务之间始终存在很大的差距。 帮助企业与 R & D 的工作保持一致。 让他们了解 Hadoop 的功能，处理数据的速度以及处理数据的速度。 新的转化归因产品就是一个很好的例子。 如果用户看到静态广告，点击它并下载该应用程序，则可能不是导致该转化的唯一原因是静态广告。 例如，如果用户在前一天（或两周前）体验了富媒体广告，则根据发布者可配置的标准，该广告将为转化分配一定的功劳。 只有强大的数据处理基础架构才能实现这种功能。 如果没有 R & D 知道这种功能甚至是可能的，那么就不可能开发出这些新型的高附加值产品并将其出售给客户。 +* **探索新工具**。 这是一个由新工具组成的复杂世界。 所有这些新技术使知道在何处放置功能具有挑战性。 一个功能可以通过很多不同的方式完成，并且根据工具（HBase，Cassandra，MongoDB）的不同而有所不同。 重复数据删除是否仍应在 MapReduce 中完成还是应使用协处理器完成？ 通过支持两个不同的数据库值得将磁盘加倍吗？ 按使用模式对数据进行分区是真的还是获胜，或者所有流量模式都可以在同一系统上工作？ 对您的选项进行原型设计，并考虑您的体系结构如何随每个新工具（单独工作或一起工作）而变化。 +* **主动监视和规划容量**。 将监视数据转变为基础架构规划。 如果您不这样做，那您将只保留消防问题。 建立主动警报和趋势数据，以便即使在成为警告之前，您也可以看到它的到来。 有时您只需要另一个服务器。 更多数据仅意味着更多服务器。 这是做生意的成本。 知道要放置在哪个服务器以使所有不同的数据流正常运行的技巧就在于此。 比较 CPU 和负载的趋势，并真正看一下整个基础架构并基于此基础制定计划，这一点很重要。 +* **从产品运营角度来看数据**。 查看新的应用程序，看看它们与以前已实现的功能有何相似之处，以弄清您如何扩展。 仅仅因为有一个新应用程序并不意味着需要添加新的广告服务器，新的数据节点和新的跟踪服务器。 这取决于。 许多不同的广告会发出少量的广告请求，但发送的数据却非常荒谬。 趋势日志可查看数据中的峰值，并查看延迟与峰值之间的关系。 这告诉您系统的不同部分在何处以及如何扩展。 ## 相关文章 -* 关于 [HackerNews](https://news.ycombinator.com/item?id=10657251) -* 兰迪·舒普[在 Twitter](https://twitter.com/randyshoup) 上 -* [微服务-不是免费的午餐！](http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html) -* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) -* [10 个易趣的星球扩展尺度](http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html)（2009） - -像所有其他文章一样。 这篇文章令人着迷。 -我想知道微服务具体做什么？ Gmail 和 Google Wave 听起来不够小，不能被视为可以由小型团队完成的微服务。 - -很棒的帖子！ 我希望您能详细说明不同的工程团队如何“使用服务付费”。 我完全同意，围绕激励机制组织大型团队要比自上而下的设计优越得多，而让团队付费使用其他团队服务是其中的一部分。 但是实际上，您如何实际跟踪服务的“付款”？ 你真的是说钱吗？ 还是您在指其他？ - --克里斯 - ->定义一个通用形状，而不是通用实现。 - -找出*为什么*被认为是好的，这将更为有用。 我发现本文中的许多建议都缺乏推理。 这使得它们非常无用。 - -信息发布！ 为了回答克里斯的问题，每个拥有很少微服务的产品团队都应该有一个成本中心，可以向其他产品团队收取使用费用。 大多数企业都拥有像 SAP 这样的良好财务系统来跟踪付款。 当为更多新服务提供资金时，这种“按需付费”的模式非常有效。 我希望这回答了你的问题。 +* Joe Stein 的 [AllThingsHadoop Twitter Feed](http://www.twitter.com/allthingshadoop) +* [大规模解决大数据问题](http://www.medialets.com/tackling-big-data-problems-at-scale/) +* 已发布 2010 年第四季度移动人物 [http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/](http://www.medialets.com/medialets-data-spotlight-mobile-rich-media-momentum-q4-2011/) +* [Hadoop，BigData 和 Cassandra 与 Jonathan Ellis 在一起](http://allthingshadoop.com/2010/05/17/hadoop-bigdata-cassandra-a-talk-with-jonathan-ellis/)-HBase 适用于 OLAP，Cassandra 适用于 OLTP +* [Twitter 的计划分析 1000 亿条推文](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) --拉杰什 +真的很棒。 对团队尝试使用可用的批处理工具（如 MapReduce）构建自己的实时分析体系结构所面临的各种挑战的深入了解。 在 Cloudscale，我们 100％专注于提供实时分析平台，该平台不仅是世界上最快的大数据架构，而且可以在具有 10GigE 网络的商品 Amazon 云集群上运行。 现在，在大数据分析领域处于领先地位的公司可以替代 Medialets 英勇采用的“自己动手”方法，并在此具有高度可扩展性。 随着实时分析继续迅速成为主流，本文将成为爆炸性增长的 Web 公司和企业的关注焦点，这些公司正面临着同样艰巨的挑战，并正在寻找工具，技术和方法。 平台来帮助他们。 -所有已知的问题/建议，但仍然是一个很好的谈话，永远不会老。 令人惊讶的是，许多公司没有遵循这些基本原则。 技术演讲的作者很容易理解，值得从事面向服务的体系结构工作的人们阅读一次。 +真好！ 非常详细和有用。 -在 11 月 5 日举行的纽约 Kubernetes 会议上，来自 Google 的一位人士说：“ Gmail 是数百种微服务。” http://www.meetup.com/New-York-Kubernetes-Meetup/events/226173240/ \ No newline at end of file +对于 mysql 替换，我建议您查看 Infobright（www.infobright.com）。 它是一个柱状 mysql 插件引擎，可以很好地替代 mysql（它们也具有开源版本）。 \ No newline at end of file diff --git a/docs/62.md b/docs/62.md index 0a989e7..2d7e2ff 100644 --- a/docs/62.md +++ b/docs/62.md @@ -1,181 +1,192 @@ -# Wistia 如何每小时处理数百万个请求并处理丰富的视频分析 - -> 原文： [http://highscalability.com/blog/2015/11/23/how-wistia-handles-millions-of-requests-per-hour-and-process.html](http://highscalability.com/blog/2015/11/23/how-wistia-handles-millions-of-requests-per-hour-and-process.html) - -*这是来自 [Christophe Limpalair](https://twitter.com/ScaleYourCode) 的来宾[转贴](https://scaleyourcode.com/interviews/interview/18)，他在接受 [Max Schnur](https://twitter.com/maxschnur) 采访时，在 [Wistia [](http://wistia.com/) 。* - -Wistia 是企业视频托管。 他们提供像热图一样的视频分析，并且使您能够添加号召性用语。 我真的很想了解所有不同组件的工作方式以及它们如何流式传输大量视频内容，因此这是本集重点介绍的内容。 - -## Wistia 的堆栈是什么样的？ - -正如您将看到的，Wistia 由不同的部分组成。 以下是支持这些不同部分的一些技术： - -* [HAProxy](http://www.haproxy.org/) -* [Nginx](http://nginx.org/) -* [MySQL](https://www.mysql.com/) （共享） -* [Ruby on Rails](http://rubyonrails.org/) -* [独角兽](http://unicorn.bogomips.org/)和某些服务在 [Puma](http://puma.io/) 上运行 -* [nsq](https://github.com/wistia/nsq-ruby) （他们编写了 Ruby 库） -* [Redis](http://redis.io/) （正在缓存） -* [Sidekiq](http://sidekiq.org/) 用于异步作业 - -## 您的规模是多少？ - -[Wistia](http://wistia.com/) 包含三个主要部分： - -1. Wistia 应用程序（用户登录并与该应用程序互动的“枢纽”） -2. 酒厂（统计处理） -3. 面包店（转码和投放） - -以下是一些统计信息： - -* **每小时加载 150 万个播放器**（加载一个播放器的页面计为一个。两个播放器计为两个，依此类推……） -* **每小时向其 Fastly CDN 发出 1880 万个高峰请求** -* **每小时 740,000 个应用程序请求** -* **每小时转码 12,500 个视频** -* **每小时 150,000 播放** -* **每小时统计 ping 达 800 万次** - -它们在 [Rackspace](http://www.rackspace.com/) 上运行。 - -## 接收视频，对其进行处理然后为它们提供服务会带来什么挑战？ - -1. **They want to balance quality and deliverability**, which has two sides to it: - 1. 原始视频的编码派生 - 2. 知道何时玩哪个衍生品 - - 在这种情况下，衍生产品是视频的不同版本。 具有不同质量的版本很重要，因为它使您可以减小文件的大小。 这些较小的视频文件可以以较少的带宽提供给用户。 否则，他们将不得不不断缓冲。 有足够的带宽？ 大！ 您可以享受更高质量（更大）的文件。 - - 拥有这些不同的版本并知道何时播放哪个版本对于良好的用户体验至关重要。 - -2. **很多 I / O。** 当用户同时上传视频时，最终将不得不在群集之间移动许多繁重的文件。 这里很多事情都会出错。 -3. **波动率。** 请求数量和要处理的视频数量均存在波动。 他们需要能够承受这些变化。 -4. **当然，提供视频也是一个主要挑战。** 幸运的是，CDN 具有不同类型的配置来帮助实现这一目标。 -5. **在客户端，有很多不同的浏览器，设备大小等...** 如果您曾经不得不处理使网站具有响应能力或在较旧的 IE 版本上工作，那么您确切地知道我们 在这里谈论。 - -## 您如何处理视频上传数量的重大变化？ - -他们有被称为 *Primes* 的盒子。 这些 Prime 盒子负责接收用户上传的文件。 - -如果上载开始占用所有可用磁盘空间，则它们可以使用 Chef 食谱启动新的 Prime。 目前，这是一项手动工作，但通常情况下，他们无法达到极限。 他们有很多空间。 - -![](img/73f5f62446151023481c92a8919f5c87.png) - -## 您使用哪种转码系统？ - -转码部分是他们所谓的*面包店*。 - -面包房由我们刚刚看过的 Prime 组成，可以接收和提供文件。 他们也有一群工人。 工作者处理任务并从上传的视频创建派生文件。 - -这部分需要强壮的系统，因为它非常消耗资源。 多强壮 - -我们说的是数百名工人。 每个工人通常一次执行两项任务。 它们都具有 8 GB 的 RAM 和相当强大的 CPU。 - -工人要进行什么样的任务和处理？ 他们主要使用 x264 编码视频，这是一种快速编码方案。 通常可以将视频编码为视频长度的一半或三分之一。 - -视频还必须调整[的大小](http://www.movavi.com/support/how-to/resizing-video.html)，并且它们需要不同的[比特率](http://help.encoding.com/knowledge-base/article/understanding-bitrates-in-video-files/)版本。 - -此外，针对不同设备的编码配置文件也不同，例如 iPhone 的 [HLS](http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-to-Encode-Video-for-HLS-Delivery-95251.aspx) 。 对于同样也是 x264 编码的 Flash 派生，这些编码需要加倍。 - -## 上传视频并对其进行转码的整个过程是什么样的？ - -用户上传视频后，该视频将排队并发送给工作人员进行转码，然后缓慢地转移到 S3。 - -无需立即将视频发送到 S3，而是将其推送到群集中的 Prime，以便客户可以立即提供视频。 然后，在几个小时内，文件被推到 S3 进行永久存储，并从 Prime 清除以腾出空间。 - -## 处理完视频后如何将其提供给客户？ - -当您播放 Wistia 上托管的视频时，您需要请求 embed.wistia.com/video-url，该请求实际上是在播放 CDN（他们使用了几种不同的 CDN。我只是尝试了一下，而我通过了 [Akamai](https://www.akamai.com/) ）。 CDN 可以追溯到 Origin，这就是我们刚刚谈到的 Prime。 - -Primes 通过称为“面包路线”的特殊平衡器运行 HAProxy。 面包路由是位于 Prime 前面并平衡流量的路由层。 - -Wistia 可能将文件本地存储在群集中（这将更快地提供服务），而 Breadroute 足够聪明，可以知道这一点。 如果真是这样，那么 Nginx 将直接从文件系统提供文件。 否则，它们代理 S3。 - -## 您如何分辨要加载的视频质量？ - -这主要是在客户端决定的。 - -Wistia 将在用户点击播放后立即接收有关用户带宽的数据。 在用户甚至没有点击播放之前，Wistia 都会接收有关设备，嵌入视频的大小以及其他启发式方法的数据，以确定该特定请求的最佳资产。 - -仅当用户进入全屏状态时才辩论是否要高清。 当用户第一次单击播放时，这使 Wistia 有机会不中断播放。 - -## 您怎么知道什么时候不加载视频？ 您如何监控呢？ - -他们拥有称为 *pipedream* 的服务，他们在应用程序和嵌入代码中使用该服务来不断地将数据发送回去。 - -如果用户单击播放，则会获得有关其窗口大小，窗口所在位置以及是否缓冲的信息（如果它处于播放状态，但几秒钟后时间没有改变）。 - -视频的一个已知问题是加载时间慢。 Wistia 想知道视频何时加载缓慢，因此他们尝试为此跟踪指标。 不幸的是，他们只知道如果用户实际上在等待负载完成才慢。 如果用户的连接速度确实很慢，他们可能会在此之前离开。 - -这个问题的答案？ 心跳。 如果他们收到心跳，却再也没有收到游戏，那么用户可能会保释。 - -## 您还收集其他哪些分析？ - -他们还为客户收集分析数据。 - -诸如播放，暂停，搜寻，转化（输入电子邮件或点击号召性用语）之类的分析。 其中一些显示在热图中。 他们还将这些热图汇总到显示参与度的图表中，例如人们观看和重看的区域。 - -![](img/09da6a8cd3164a8539ff1ea9e21ed5bc.png) - -## 您如何获得如此详细的数据？ - -播放视频时，他们使用视频跟踪器，该跟踪器是绑定到播放，暂停和搜索的对象。 该跟踪器将事件收集到数据结构中。 每 10 到 20 秒一次，它会回传至 Distillery，该酒厂又找出如何将数据转换为热图。 - -为什么每个人都不这样做？ 我问他，因为我什至没有从 YouTube 获得此类数据。 马克斯说，原因是因为它非常密集。 酿酒厂处理大量的东西，并拥有一个庞大的数据库。 - -![](img/5b080d374f1ec07d3568462b49fa2d75.png) -（ *http://www.cotswoldsdistillery.com/First-Cotswolds-Distillery-Opens* ） - -## 什么是扩展易用性？ - -Wistia 拥有约 60 名员工。 一旦开始扩大客户群，就很难确保继续保持良好的客户支持。 - -它们的最高接触点是播放和嵌入。 这些因素有很多无法控制的因素，因此必须做出选择： - -1. 不要帮助客户 -2. 帮助客户，但需要很多时间 - -这些选择还不够好。 取而代之的是，他们追究导致客户支持问题最多的来源-嵌入式。 - -嵌入经历了多次迭代。 为什么？ 因为他们经常破产。 不管是 WordPress 做一些奇怪的嵌入，还是 Markdown 破坏嵌入，随着时间的推移，Wistia 都遇到了很多问题。 为了解决这个问题，他们最终大大简化了嵌入代码。 - -这些更简单的嵌入代码在客户端遇到的问题更少。 尽管确实在后台增加了更多的复杂性，但是却导致了更少的支持请求。 - -这就是 Max 通过扩展易用性的含义。 使客户更轻松，这样他们就不必经常与客户支持联系。 即使这意味着更多的工程挑战，对他们来说也是值得的。 - -缩放易用性的另一个示例是回放。 Max 确实对实现一种客户端 CDN 负载均衡器感兴趣，该负载均衡器确定了从中提供内容的最低延迟服务器（类似于 Netflix 所做的事情）。 - -## 您现在正在从事哪些项目？ - -Max 计划很快启动的就是他们所说的上载服务器。 这个上载服务器将使他们能够对上载做很多很酷的事情。 - -正如我们所讨论的那样，对于大多数上载服务，您必须等待文件到达服务器，然后才能开始转码并对其进行处理。 - -上传服务器将使上传时可以进行转码。 这意味着客户可以在视频完全上传到系统之前就开始播放他们的视频。 他们还可以获取静止图像并几乎立即嵌入 - -## 结论 - -我必须尝试在此摘要中尽可能多地添加信息，而又不要太长。 这意味着我删去了一些可以真正帮助您的信息。 如果您发现这很有趣，我强烈建议您查看[完整访谈](https://scaleyourcode.com/interviews/interview/18)，因为还有更多隐藏的宝石。 - -您可以观看，阅读甚至收听。 还有一个下载 MP3 的选项，因此您可以聆听自己的工作方式。 当然，该节目也在 [iTunes](https://itunes.apple.com/tt/podcast/scale-your-code-podcast/id987253051?mt=2) 和 [Stitcher](http://www.stitcher.com/podcast/scaleyourcode?refid=stpr) 上进行。 - -Thanks for reading, and please let me know if you have any feedback!- Christophe Limpalair (@ScaleYourCode) - -您好，HS 读者们，我希望您从本集中找到有趣且有用的信息。 在很多（当之无愧的）关注焦点集中在 Netflix 和 YouTube 上的时代，Wistia 感觉就像是一颗隐藏的宝石。 - -我一直在努力改善演出，因此，我敞开双臂欢迎任何反馈。 受访者的建议和一般问题也是如此。 - -谢谢，享受！ - -很棒的帖子... -这些天，每个人都在后端使用 s3，但是为什么他们不使用弹性代码转换器？ - -您好，感谢您的阅读/观看！ - -RE：为什么我们不使用弹性代码转换器。 好吧，如果我们今天要创办一家视频托管公司，我们可能最终会使用诸如弹性代码转换器或 zencoder 之类的服务。 这是因为要获得像大规模构建的那样健壮的系统非常困难，而且这些服务非常好。 - -但是面包店（我们的转码服务）是在弹性转码器或 zencoder 出现之前建立的。 而现在，由于这些年来我们投入了大量工作并实施了自动缩放功能，因此它为我们带来了竞争优势。 也就是说，我们能够快速轻松地实施新的编码方案，并将转码与我们的应用程序体验更加紧密地集成在一起。 例如，我不提一提的服务器允许在仍上传的同时进行转码和回放，这是面包店的特色。 使用任何现有服务都很难做到这一点，但是会极大地改善用户体验。 - -再说一次，我们总是在评估我们的选项，因此，如果有必要将部分或全部转码卸载到另一个服务，我们一定会考虑的。 目前，面包店是秘密武器。 :) - -嗨，好帖子 看起来您正在 Rackspace 上运行，并且存储在 S3 上。 为什么不只在 AWS 和 S3 上运行？ 谢谢！ \ No newline at end of file +# Facebook 的新实时分析系统：HBase 每天处理 200 亿个事件 + +> 原文： [http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html](http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html) + +![](img/dff64aa536c627923d7cfaf30eb1ea94.png) Facebook 再次这样做。 他们建立了另一个系统，能够对大量的实时数据流进行有用的处理。 上次我们看到 Facebook 发布其[新的实时消息系统：HBase 每月存储 135 亿条消息](http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html)。 这次，它是一个实时分析系统，每天处理*超过 200 亿个事件（每秒 200,000 个事件），时延不到 30 秒*。 + +Facebook 工程经理 Alex Himel [解释了他们构建的](http://www.facebook.com/note.php?note_id=10150103900258920)（[[视频](http://www.facebook.com/video/video.php?v=707216889765&oid=9445547199&comments)）以及所需的规模： + +> 在过去的一年中，社交插件已成为数百万网站的重要且不断增长的流量来源。 上周，我们发布了新版本的“网站洞察”，以使网站所有者可以更好地分析人们如何与其内容进行互动，并帮助他们实时优化网站。 为此，我们必须设计一个系统，每天处理 200 亿个事件（每秒 200,000 个事件），而延迟不到 30 秒。 + +亚历克斯在演讲中做得很好。 强烈推荐。 但是让我们更深入地了解发生了什么... + +Facebook 通过通过[社交插件](http://developers.facebook.com/docs/plugins/)的病毒传播，将非 Facebook 网站重新绑定到 Facebook 中，并将 Facebook 网站重新绑定到 Facebook 中，从而实现了这种强大的分析系统的需求，这是 Facebook 出色的计划，旨在实现全球网络统治 非 Facebook 网站。 基本上，人们可以做的任何事情都会被 Facebook 捕获并反馈，而 Facebook 上所做的任何事情都可以显示在您的网站上，从而在两者之间建立更紧密的联系。 + +Facebook 的社交插件是 Roman Empire Management101。您不必征服所有人就可以建立帝国。 您只要控制每个人，使他们意识到自己可以被征服的威胁，同时使他们意识到，哦，与罗马友好可以赚很多钱。 我记得这一策略已经工作了很长时间。 + +毫无疑问，您在网站上看到了社交插件。 社交插件可让您查看朋友喜欢，在网络上的站点上评论或共享的内容。 想法是将社交插件放在网站上，使内容更具吸引力。 您的朋友可以看到您喜欢的东西，而网站可以看到每个人都喜欢的东西。 引人入胜的内容为您带来更多点击，更多喜欢和更多评论。 对于企业或品牌甚至个人而言，内容越具有吸引力，人们看到的内容就越多，新闻源中出现的内容就越多，从而将其吸引到网站的流量也就越大。 + +以前的孤狼网是内容猎人无声无息地跟踪着网站的地方，如今已变成一个迷人的小村庄，每个人都知道您的名字。 这就是社交的力量。 + +例如，此处有关 HighScalability 的帖子现在具有 [Like 按钮](http://developers.facebook.com/docs/reference/plugins/like/)。 TechCrunch 已使用 Facebook 的评论系统移至[。 立即辩论集中在评论系统本身的质量上，但这并不是重点，重点是使 TechCrunch 更深入地投入到 Facebook 的 500+百万用户的生态系统中。 其他插件包括：推荐，活动源，登录，注册，Facepile 和实时流。](http://techcrunch.com/2011/03/01/facebook-rolls-out-overhauled-comments-system-try-them-now-on-techcrunch/) + +除非您能理解所有这些数据，否则它们意义不大，并且还向内容提供商证明了社交插件确实确实使他们的网站更具吸引力。 这就是 Facebook 的[洞察系统](http://www.allfacebook.com/facebook-rolls-out-expanded-insights-for-domains-2011-03)出现的地方。这是一个分析系统，可让您访问所收集的所有多汁数据。 它提供统计信息，例如“赞”按钮分析，“评论”框分析，“热门页面”，“受众特征”和“自然共享”。 + +想象一下，数百万个网站和数十亿个页面以及数百万的人通过这些社交插件不断地流式传输数据。 您如何实时理解所有这些数据？ 这是一个具有挑战性的问题。 + +## 价值主张 + +借助 Insights System，内容生产者可以看到人们喜欢的东西，这将使内容生产者能够产生更多人们喜欢的东西，从而提高网络的内容质量，从而为用户提供更好的 Facebook 体验。 + +## 系统目标 + +* 以非常可靠的方式为人们提供实时计数器，这些计数器涉及许多不同的指标，并解决了数据偏差问题。 +* 提供匿名数据。 您无法弄清这些人是谁。 +* 展示为什么插件很有价值。 您的业​​务从中获得什么价值？ +* 使数据更具可操作性。 帮助用户采取行动，使其内容更具价值。 + * 新的 UI 隐喻。 使用漏斗的想法。 + * 有多少人看到了该插件，有多少人对此采取了行动，以及有多少人转化为访问您网站的流量。 +* 使数据更及时。 + * 他们实时进行。 从 48 小时转向 30 秒。 + * 消除了多个故障点以实现此目标。 + +## 挑战性 + +* **许多事件类型** + * 跟踪 100 多个指标。 + * 插件印象。 + * 喜欢 + * 新闻提要印象 + * 新闻订阅源点击 + * 客层 +* **大量数据** + * 每天 200 亿个事件（每秒 200,000 个事件） +* **数据偏斜-密钥分布不均** + * 喜欢遵循类似幂律分布的方法。 长尾巴很少有人喜欢，但有些资源却得到大量喜欢。 + * 这带来了热区，热键和锁争用的问题。 + +## 实现了一堆不同的原型 + +* **MySQL 数据库计数器** + * 排有一把钥匙和一个柜台。 + * 导致大量数据库活动。 + * 统计信息每天存储在桶中。 每天午夜时分，统计数据都会累积。 + * 当达到过渡期时，这将导致对数据库的大量写入，从而导致大量的锁争用。 + * 尝试通过考虑时区来分散工作。 + * 试图以不同的方式分割事物。 + * 高写入率导致锁争用，很容易使数据库超载，必须不断监视数据库，并且必须重新考虑其分片策略。 + * 解决方案不适合该问题。 +* **内存中计数器** + * 如果您担心 IO 中的瓶颈，则将其全部放入内存中。 + * 没有规模问题。 计数器存储在内存中，因此写入速度快并且计数器易于分片。 + * 由于未说明的原因，感觉到内存中的计数器并不像其他方法那样准确。 甚至只有 1％的失败率也是不可接受的。 Analytics（分析）可以赚钱，所以计数器必须非常准确。 + * 他们没有实现这个系统。 这是一个思想实验，准确性问题导致他们继续前进。 +* **MapReduce** + * 将 Hadoop / Hive 用于先前的解决方案。 + * 灵活。 易于运行。 可以处理大量写入和读取的 IO。 不必知道他们将如何提前查询。 数据可以存储然后查询。 + * 不是实时的。 许多依赖项。 很多失败点。 复杂的系统。 不够可靠，无法达到实时目标。 +* **卡桑德拉** + * 基于可用性和写入率，HBase 似乎是一个更好的解决方案。 + * 写速度是要解决的巨大瓶颈。 + +## 获胜者：HBase + Scribe + Ptail + Puma + +* 在高层次上： + * HBase 在分布式计算机上存储数据。 + * 使用尾部架构，新事件存储在日志文件中，并且尾部有日志。 + * 系统汇总事件并将其写入存储。 + * UI 会拉出数据并将其显示给用户。 +* 数据流 + * 用户在网页上单击“赞”。 + * 向 Facebook 发送 AJAX 请求。 + * 使用 Scribe 将请求写入日志文件。 + * 编写极其精简的日志行。 日志行越紧凑，则可以在内存中存储的越多。 + * 抄写员处理文件翻转之类的问题。 + * Scribe 建立在 Hadoop 建立在同一个 HTFS 文件存储上。 + * 尾巴 + * 使用 Ptail 从日志文件读取数据。 Ptail 是一个内部工具，用于聚合来自多个 Scribe 存储的数据。 它拖尾日志文件并提取数据。 + * Ptail 数据分为三个流，因此最终可以将它们发送到不同数据中心中自己的群集。 + * 插件印象 + * 新闻提要印象 + * 动作（插件+新闻源） + * 彪马 + * 批处理数据可减少热键的影响。 尽管 HBase 每秒可以处理大量写入操作，但它们仍要批处理数据。 热门文章会产生大量的印象和新闻提要印象，这将导致巨大的数据偏斜，从而导致 IO 问题。 批处理越多越好。 + * 批量平均 1.5 秒。 想要批处理更长的时间，但是它们具有太多的 URL，以至于在创建哈希表时它们用尽了内存。 + * 等待上一次刷新完成以开始新批处理，以避免锁争用问题。 + * UI 渲染数据 + * 前端都是用 PHP 编写的。 + * 后端是用 Java 编写的，并且 Thrift 用作消息传递格式，因此 PHP 程序可以查询 Java 服务。 + * 缓存解决方案用于使网页显示更快。 + * 效果因统计信息而异。 计数器可以很快回来。 在域中查找顶级 URL 可能需要更长的时间。 范围从 0.5 到几秒钟。 + * 缓存的数据越长越长，实时性就越差。 + * 在 Memcache 中设置不同的缓存 TTL。 + * MapReduce + * 然后将数据发送到 MapReduce 服务器，以便可以通过 Hive 查询。 + * 这也可以用作备份计划，因为可以从 Hive 恢复数据。 + * 一段时间后，原始日志将被删除。 +* HBase 是分发列存储。 + * Hadoop 的数据库接口。 Facebook 的内部人员在 HBase 上工作。 + * 与关系数据库不同，您不在表之间创建映射。 + * 您不创建索引。 您拥有主行键的唯一索引。 + * 通过行键，您可以拥有数百万个稀疏列的存储。 非常灵活。 您不必指定架构。 您定义列族，可以随时向其中添加键。 + * WAL 预写日志是可伸缩性和可靠性的关键功能，它是应该执行的操作的日志。 + * 根据密钥，数据将分片到区域服务器。 + * 首先写给 WAL。 + * 数据被存入内存。 在某个时间点，或者如果已经积累了足够的数据，则将数据刷新到磁盘。 + * 如果机器出现故障，您可以从 WAL 重新创建数据。 因此，不会永久丢失数据。 + * 结合使用日志和内存存储，它们可以可靠地处理极高的 IO 率。 + * HBase 处理故障检测并自动跨故障路由。 + * 当前，HBase 重新分片是手动完成的。 + * 自动热点检测和重新分片在 HBase 的路线图上，但还没有。 + * 每个星期二，有人查看密钥并决定对分片计划进行哪些更改。 +* **模式** + * 在每个 URL 上存储一堆计数器。 + * 行键是唯一的查找键，是反向域的 MD5 哈希 + * 选择适当的密钥结构有助于扫描和分片。 + * 他们遇到的问题是将数据正确分片到不同的计算机上。 使用 MD5 哈希值可以更容易地说出该范围在此处，该范围在该位置。 + * 对于 URL，它们会执行类似的操作，此外还会在其上添加一个 ID。 Facebook 中的每个 URL 都有一个唯一的 ID，该 ID 用于帮助分片。 + * 使用反向域，例如 *com.facebook /* ，以便将数据聚集在一起。 HBase 确实擅长扫描集群数据，因此，如果他们存储数据以便集群在一起，则它们可以有效地计算整个域的统计信息。 + * 将每行 URL 和每个单元格视为一个计数器，就可以为每个单元格设置不同的 TTL（生存时间）。 因此，如果每小时进行一次计数，则没有必要永久保留每个 URL，因此他们将 TTL 设置为两周。 通常按每个列族设置 TTL。 +* 每个服务器每秒可处理 10,000 次写入。 +* 从日志文件读取数据时，检查点用于防止数据丢失。 + * 裁缝将日志流检查点保存在 HBase 中。 + * 在启动时重播，因此不会丢失数据。 +* 用于检测点击欺诈，但没有内置欺诈检测。 +* **泰勒热点** + * 在分布式系统中，系统的一个部分可能比另一个部分更热。 + * 一个示例是区域服务器可能很热，因为以这种方式定向了更多的密钥。 + * 一个尾巴也可能落后于另一个。 + * 如果一个拖尾落后一个小时，而其他拖尾已经更新，那么您将在 UI 中显示哪些数字？ + * 例如，展示次数比操作要高得多，因此点击率在过去一小时中要高得多。 + * 解决方案是找出最新的拖尾，并在查询指标时使用。 +* **未来方向** + * **热门列表** + * 对于 YouTube 这样的域名，很难找到最喜欢的 URL（最受欢迎的 URL），因为这些 URL 可以快速共享数百万个 URL。 + * 需要更多创新的解决方案来保持内存中的排序并随着数据的变化而保持最新。 + * **不同的用户计数** + * 一个时间窗中**上有多少人喜欢某个 URL。 在 MapReduce 中很容易做到，而在幼稚的计数器解决方案中很难做到。** + * **适用于社交插件**以外的应用程序 + * **移至多个数据中心** + * 当前是单个数据中心，但希望迁移到多个数据中心。 + * 当前的后备计划是使用 MapReduce 系统。 + * 备份系统每晚都会进行测试。 比较针对 Hive 和此新系统的查询，以查看它们是否匹配。 +* **项目** + * 花了大约 5 个月的时间。 + * 首先有两名工程师开始从事该项目。 然后添加了 50％的工程师。 + * 前端有两个 UI 人员​​。 + * 看起来大约有 14 个人从工程，设计，PM 和运营中从事了该产品的工作。 + +当我们查看消息传递系统和此分析系统时，我们注意到两个系统的共同点：大量，HBase，实时。 以可靠，及时的方式处理大量写入负载的挑战是这些问题的共同基础。 Facebook 专注于 HBase，Hadoop，HDFS 生态系统，并指望稍后解决的操作问题。 其他人之所以选择 Cassandra，是因为他们喜欢 Cassandra 的可伸缩性，多数据中心功能以及易于使用的功能，但它并不适合整个分析堆栈。 + +这对您意味着什么？ 即使您不是 Facebook，该体系结构也足够简单，并且由足够多的现成工具组成，甚至可以用于许多小型项目。 + +## 相关文章 + +* [Medialets 体系结构-击败艰巨的移动设备数据洪水](http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html)-分析平台的另一种表现。 +* [Twitter 的计划分析 1000 亿条推文](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) +* [扩展分析解决方案技术讲座（3/2/11）[HQ]](http://www.facebook.com/video/video.php?v=707216889765&oid=9445547199&comments) + +这是一个很棒的文章。 如何在不同的时间范围内进行汇总？ 每个<计数器和时间窗口>对都有单独的单元格吗？ + +好消息是，即使您不是 Facebook 人士，也没有整个工程师团队来构建您的分析平台，您仍然可以使用现有的带有 [OpenTSDB](http://opentsdb.net) 的开源软件来构建类似的平台。 在 StumbleUpon，我们仅使用 20 个节点群集中的 3 个即可轻松地[每秒处理 200,000 个事件](https://issues.apache.org/jira/browse/HBASE-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008872#comment-13008872)，因此，大概您还可以使用更多节点轻松地将其扩展为每天数十亿个事件。 + +当 Facebook 工程师在 6 个月前启动该项目时，Cassandra 没有分布式计数器，该计数器现在已提交到主干中。 Twitter 正在 Facebook 上投入大量资金用于实时分析（请参阅 Rainbird）。 由于计数器写入分散在多个主机上，因此写入速率对于 Cassandra 来说应该不是瓶颈。 对于 HBase，每个计数器仍然受单个区域服务器性能的约束吗？ 两者的性能比较将很有趣。 + +一个简单的问题-如果您拖尾的日志文件可能以不同的速率写入，那么您如何知道从头到尾有多少行？ 尾巴-跟随什么？ 但是，如何将其传送到另一个程序？ + +谢谢 + +HBase 表中的主键不是索引。 由于行以排序顺序存储，因此查找速度很快。 + +这些家伙在做什么只是在计数在线中/事件中的事件.....没什么好说的，这全都取决于一个人可以计数的速度...... +我认为他们也使它变得复杂 只是为了计算这些点击/事件 \ No newline at end of file diff --git a/docs/63.md b/docs/63.md index eb73962..a8c3151 100644 --- a/docs/63.md +++ b/docs/63.md @@ -1,181 +1,174 @@ -# 整个 Netflix 堆栈的 360 度视图 +# Microsoft Stack 是否杀死了 MySpace？ -> 原文： [http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html) +> 原文： [http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html](http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html) -![](img/55739ecaab704c16a4ff8d5b4688b8f9.png) +![](img/b626d590fe361c0078867635d0de14c3.png) -*This is a guest [repost](http://www.scalescale.com/the-stack-behind-netflix-scaling/) by [Chris Ueland](http://twitter.com/ChrisUeland), creator of [Scale Scale](http://scalescale.com/), with a creative high level view of the Netflix stack.* +罗伯特·斯科布尔（Robert Scoble）撰写了一个引人入胜的案例研究， [MySpace 的死亡螺旋：内部人说，这是赌在洛杉矶和微软](http://scobleizer.com/2011/03/24/myspaces-death-spiral-due-to-bets-on-los-angeles-and-microsoft)上的，他在报告中说 MySpace 内部人将微软[丢掉了很棒的社交网络的原因归咎于微软 种族](http://www.intelligentspeculator.net/investment-talking/why-facebook-is-succeeding-where-myspace-has-failed/)到 Facebook。 -> 随着我们对扩展的研究和深入研究，我们将继续涉足 Netflix。 他们的故事很公开。 这篇文章是我们在 Bryan 的帮助下整理而成的。 我们从互联网上收集了信息。 如果您想了解更多信息，我们将在此附上。 否则请尽情享受！ -> -> –克里斯/ ScaleScale / MaxCDN +有没有人知道这是不是真的？ 真实的故事是什么？ -![](img/589a5c2b0693b041db6f53e8a2dd0957.png) +我在想，因为它似乎与我在 2009 年所做的 [MySpace Architecture](http://highscalability.com/blog/2009/2/12/myspace-architecture.html) 帖子不一致，他们似乎对他们的选择感到满意，并提供支持其改进的统计数据。 这很重要的原因是，这是初学者可以借鉴的迷人模型。 成功真正需要什么？ 是人员还是堆栈？ 是组织还是技术？ 是过程还是竞争？ 网站的质量还是用户的喜爱？ 有太多需要考虑和学习的地方。 -## 看看我们对 Netflix 如何扩展感兴趣的观点 +本文中的一些猜想： -Netflix 由马克·兰道夫（Marc Randolph）和里德·黑斯廷斯（Reed Hastings）于 1997 年在加利福尼亚州斯科茨谷市成立，最初拥有 30 名员工，其中 925 名从事按租金付费。如今，Netflix 已成为全球领先的互联网电视网络，在 50 个国家/地区拥有 6900 万订户 每月欣赏超过 100 亿小时的电视节目和电影。 它们非常透明，可以在线发布很多信息。 我们已收集并分享了我们认为最有趣的内容： +1. Myspace 没有编程人才能够扩展网站以与 Facebook 竞争。 +2. 选择微软的体系使其很难聘请能够与 Facebook 竞争的人。 .Net 程序员主要是企业程序员，他们的组织结构并非以启动速度创建大型可扩展网站。 +3. 他们的系统具有““数百个骇客，使其规模扩大到没人想碰”，这损害了他们真正竞争的能力。 +4. 由于 MySpace 的基础架构，他们无法更改其技术以使新功能正常工作或带来新的体验。 +5. 激怒了很多人，鼓舞士气，使招聘变得艰难。 （du） +6. 洛杉矶没有能够产生可扩展社交网络系统的创业人才。 +7. Facebook 选择的 LAMP 堆栈使他们可以更快地招聘并找到知道如何扩展的人。 -![](img/84caa622b10cf4f82b4df5547ffa78a8.png) +评论中的一些非常有趣的观点（来自文章，电子邮件， [Hacker News](http://apps.ycombinator.com/item?id=2369343) ， [Hacker News](http://news.ycombinator.com/item?id=2369271) ）： -## 规模文化 +1. **Nick Kwiatkowski** ：我能够与一些在 MySpace 工作的程序员一起工作，但问题不是引擎（无论是在 ColdFusion 还是.NET 上） ，这是他们选择为其开发人员孕育的环境。 管理层会说“我们现在需要 X 功能才能保持竞争力”。 然后，他们将选择一组开发人员来实现该功能。 最大的问题是他们不允许开发人员进行登台或测试服务器-他们是在第一次尝试时将其部署在生产服务器上的。 有时，这些开发人员只能在很少的时间内获得 5 或 10 个项目的部署。 而这一切都没有变更管理或控制。 也没有版本控制。 MySpace 管理层从不希望回头查看代码或提高代码效率。 他们的解决方案是“更多服务器”。 他们最终雇用了一个唯一的工作就是安装更多服务器的工作人员。 同时，他们让开发人员签入错误代码，并且以惊人的速度累积技术债务。 当时，MySpace 正在运行其应用程序服务器的两个主要版本，而不是建议使用的版本。 微软（HTG8）新亚特兰大市（New Atlanta）问世时，他们跳槽了从本质上出售其技术债务（例如抵押给金融公司的抵押品）的想法，并请其他人来解决他们的问题。 当时的问题是微软没有更新他们的旧代码，他们只是在.NET 上添加了新功能。 这并不能解决他们的问题，而使他们处于仍然需要修复旧内容，同时又要更新新代码的情况。MySpace 的问题是：它们是当您不听并且积累了过多技术债务时的经典示例。 修复旧内容应该是优先事项，并且必须执行诸如变更管理，版本控制，测试和开发服务器等工作。 这就是为什么 Facebook 能够部署几乎没有影响的新更改的原因-他们在让实际用户使用之前对其进行了测试和验证。 +2. **u_fail** ：听起来这一切都是对技术归咎于技术的了解很少甚至根本不了解的商人，而一直以来都是缺乏创新并且高层缺乏决策者。 MySpace 始终像一家娱乐公司一样运作。 +3. **Eric** ：这与技术无关，而与实施技术的人员有关。 +4. **Robert Scoble** ：MySpace 的体系结构使得很难发布新功能和“枢轴”，一旦他们清楚地知道他们正在努力。 +5. MySpace 的核心竞争力依赖于其他人，并且从未在内部扩展过，而且似乎完全无法发挥作用。 +6. **Robert Scoble：**都是关于人才和获得技术帮助的创新。 这些人没有使用微软的系统。 +7. **编码为**：MySpace 在 Microsoft 的堆栈上押注不是问题。 问题在于他们在 Telligent 的社交媒体平台上下注。 MySpace 并未开发自己的平台并向自己拥有和开发的平台添加功能，而是决定让另一家公司的产品为其核心功能集提供创新。 +8. **Hack** ：我记得在某人的页面上浏览了 100 张.gif 文件，并在 25 秒后加载了页面。 Facebook 无疑获得了冠军。 +9. **Marcelo Calbucci** ：这是一个错误的分析。 如果使用 RoR 或 PHP，他们将遭受完全相同的信念。 实际上，一旦 Facebook 改变了社交网络应提供和外观的标准，他们的命运就已经定下来了。 +10. **Sriram Krishnan** ：您对任何堆栈的使用与您所拥有的专业知识成正比。 +11. **S Jain** ：把责任归咎于微软是完全错误的。 我认为这是 MySpace 的一种文化。 我在洛杉矶的一家初创公司工作，在 Myspace 有很多朋友。 我常常会迟到，他们会说向一家大公司求职，为什么迟到了。 +12. **Gregg Le Blanc** ：当 MySpace 在 MIX06 上发表他们为何转用 Microsoft 的主题演讲时，他引用了一个事实，即他们可以在基本上 2/3 的服务器上处理相同的用户负载（246-> 150），将平均 CPU 负载从 85％降低到 27％，以便为 6500 万用户负载的页面提供服务。 因此，我认为这更多地与人员，体系结构和业务计划有关。 他们的战略决策是忘记创新。 那是技术独立的。 +13. Robert Scoble ：马克·扎克伯格（Mark Zuckerberg）表示，要在其他地方建立网络规模的公司要困难得多，因此他从波士顿搬到了硅谷。 +14. **Jebb Dykstra** ：MySpace 在出售给新闻集团的那一刻就迷失了。真正的死亡螺旋就在那一刻开始。 如果像 Richard Rosenblatt 这样的人才留下来，而他们并没有以 670 毫米的价格卖掉自己，那么这些问题中的许多可能就是借口。 +15. **Omar Shahine** ：让我们不要忘记 Twitter 根本无法扩展，并且基本上被破坏了。 它不是建立在 Microsoft 技术之上的，但是他们设法对其进行了修复。 +16. **Sean Scott** ：即使技术和人才匮乏是问题的一部分，而且 MySpace 无法响应 Facebook，最终用户体验还是为此付出了代价。 +17. **DavidNoël**：当他们说这将花费一些点击和页面重载，但会增加用户体验和长期参与度时，NewsCorp 会拒绝，因为担心失去可货币化的指标。 +18. **史蒂夫·史密斯**：MySpace 的代码显然有很多技术上的欠缺，从事物的声音来看，其体系结构是教科书“泥浆大球”。 他们将核心业务押在第三方软件上。 +19. **Scott Stocker** ：愿意为 MySpace 工作的开发人员的可用性是最大的问题。 +20. **琳达·尼古拉**：用户没有因为技术投诉而离开现场，这是因为新来的孩子骑着一辆更加光亮的自行车...缺乏创新，缺乏竞争性， 产品推出有限，高层动荡不安，技术问题，但不要将其归咎于洛杉矶缺乏技术人才 +21. **Dan Bartow** ：阅读本文后的最初印象是，我完全同意 Scoble 所说的有关洛杉矶和人才问题的一切。 MySpace 处于独特的状况，因为它们专注于娱乐行业，主要是音乐行业和相关内容。 由于这种关注，洛杉矶确实是他们所做工作的“理想之地”。 要插入现场并进行艺术家活动，与唱片公司建立联系……还有什么更好的地方？ 如果您是一家金融公司...新英格兰。 娱乐...洛杉矶。 另一方面，它们也是流量最高的网站之一，因此，他们确实需要站在技术的最前沿。 的确，洛杉矶不一定具有像旧金山湾区在尖端网络规模架构方面的工程人才类型。 但是，请认为 MySpace 的问题与其所选择的技术平台选择（微软与其他产品）相比要少得多，而与工程领导力，市场定位和响应时间等有关的更多。我个人对其性能和可伸缩性印象非常深刻 。 他们快速的自动配置和重新配置功能非常出色。 他们能够进行 100 万个并发用户测试，就像没有发生那样，因此非常棒。 我实际上不知道这是微软技术，并且可能永远不会根据他们在其架构中所做的事情来猜测。 作为工程师，您和我俩都知道正确的心态以及强大的领导才能使几乎任何技术都达到最高水平。 PHP 是可扩展性最低，性能最差的语言之一，直到 Facebook 一直将其推向顶峰。 领导。 Microsoft 网站上有很多高流量的站点，所以我认为技术选择不像 Scoble 听起来那么重要，并且基于我在 MySpace 上的工程领导地位，实际上是很糟糕的事情。 人才...当然，洛杉矶不是硅谷，但是相信我，有很多理由选择使用 SoCal。 就我个人而言，我认为 MySpace 的问题一直存在于业务领导地位以及对竞争对手的反应时间较慢。 +22. **Scott Seely** ：MySpace 死亡螺旋上升的原因与技术无关。 是与人类问题有关的一切。 克里斯·德沃尔夫（Chris DeWolfe）和汤姆·安德森（Tom Anderson）离开后，随之而来的是许多重要领导。 此外，许多创意人员（产品经理，开发人员，艺术家等）都看到高管离职，并决定现在是尝试其他方法的好时机。 太多的机构知识留下得太快了，这破坏了 MySpace。 +23. **jdavid** ：MySpace 拥有的是文化债务，并且担心破坏他们的财产。 Facebook 之所以获胜，是因为他们是核心的苏格拉底。 Fox 是一家封闭源代码的公司，因此当我们像 Oauth 和 OpenSocial 小工具服务器这样的开放技术公司工作时，我们必须将其作为封闭源代码软件来进行。 我们没有同行评审。 当您没有 Linkedin，google，bebo 和 twitter 来检查代码时，这真的很难发货和测试。 最重要的是，当这些公司发现错误时，我们必须在.Net 中重新实现该代码。 最重要的是，MySpace 和.Net 是针对强类型化而精心设计的，这些类型与 Java 有点不同。 移植并不需要花费很多时间，所以我们一直这样做，但是您必须考虑一下，您正在与像 Facebook 这样的公司竞争，当时该公司的利润动机为零，并拥有数十亿美元的资金和 地面堆栈。 同时，MySpace 只是在清除冷融合，而我们有真正的旧博客平台，不能仅仅将其删除。 我们还拥有不想激怒用户的管理，因此我们将拥有 2 或 3 个版本的站点，并且我们要求用户升级到新版本。 +24. **jdavid** ：与 Google 的交易失败了，因为这些条款涉及的是浏览量和点击次数。 MySpace 和 Fox 决定以这些条款为目标，以最大限度地提高收入。 结果是 MySpace 几乎为每个用户操作都添加了不必要的页面流。 它摧毁了用户体验并激怒了谷歌。 我们的团队一直在与管理人员开玩笑，说我们将通过 REST API 创建一个 MySpace-Lite 作为辅助项目，并摆脱所有的废话。 我们应该做的。 我们应该创建 MYSPACE-LITE。 与 Google 的交易每年价值 3 亿美元，每年总收入 7.5 亿美元。 MySpace Music 失去了公司的疯狂资金，过去是而且是有缺陷的模型。 我们的团队想创建一个 API，游戏和网站可以访问音乐，并创建开放的播放列表。 我们想将音乐打开，然后进行许可。 有人告诉我们这是不可能的。 +25. **lemmsjid** ：Web 层与可伸缩性几乎没有关系（不要误会我，它与成本有很大关系，只是与可伸缩性没有关系，除非采用诸如数据库连接池这样的更巧妙的方式） 这都是关于数据的。 当 MySpace 达到指数级增长曲线时，几乎没有用于扩展 Web 2.0 stype 公司的解决方案（OSS 或非 OSS）（大量读取，大量写入，大量热数据超过了商品缓存硬件的内存，当时为 32 位） ，并拥有非常昂贵的内存）。 没有 Hadoop，没有 Redis，Memcached 刚刚被释放并且存在现存的问题。 这很有趣，因为今天人们问我：“为什么不使用 Technology X？” 我回答：“好吧，那时还没想到呢：）”。 当时，只有如此规模的地方才出现，例如 Yahoo，Google，EBay，Amazon 等，而且由于它们都在专有堆栈中，因此我们会尽可能多地阅读白皮书，并尽可能多地获得白皮书。 -一起收集信息。 最后，我们编写了一个分布式数据层，消息传递系统等，以处理跨多个数据中心的大量负载。 我们对数据库进行了分区，并编写了一个 etl 层，以将数据从 A 点传送到 B 点，并将索引定位到所需的工作负载。 所有这些都是在每秒数十万次命中的巨大负载下完成的，其中大多数都需要访问多对多数据结构。 我们与之合作的许多初创公司，无论是硅谷还是硅谷，都无法想象将他们的东西扩展到那种负载-许多数据系统供应商在使用它们之前（如果有的话）需要对其东西进行许多修补。 时代已经改变了-现在想象扩展到 MySpace 的初始负载要容易得多（几乎可以接受）。 关键分区数据库层，分布式异步队列，用于聊天会话的大型 64 位服务器等。但是，您要考虑到该系统永远不会脱机-您需要持续 24 小时访问。 当整个系统出现故障时，您将损失大量资金，因为数据库缓存消失了，中间层缓存消失了，等等。这就是操作故事的来历，在此我可以为系统专门介绍其他几段 用于监视，调试和映像服务器。 当然，还有数据故事和 Web 代码故事。 MySpace 是一个非常难以在 Web 端进行进化的平台。 其中一部分是整个站点上用户体验的碎片化，而很大一部分是用户提供的 HTML。 不以微妙或不微妙的方式破坏人们的经历是很难做的。 许多配置文件主题都将图像放置在图像之上，并且 CSS 读取了“ table table table table ...”。 当您不得不处理数百万个 html 变体时，请尝试更改体验。 在这方面，谈到灵活性时，我们挖了自己的坟墓。 不要误会我的意思，系统存在的缺陷多于我所能估计的。 总有事情要做。 但是，作为喜欢在 Microsoft 和 OSS 堆栈上花费时间的人，我可以告诉您问题不是问题在于 MS 技术，也不是缺乏工程技术人才。 我为建立这些系统而工作的人们的素质感到惊讶和谦卑。 +26. n_ar​​e_q 的**：对于在公司工作并关心环顾四周并了解正在发生的事情的任何人来说，MySpace 垮台的原因都是显而易见的-这是灾难性的，缺乏管理和产品的领导力和远见， 瘫痪了政治内斗，以及公司管理层高层普遍缺乏能力。 因此，做出决定的人会不断改变主意和要求。 有许多完整的功能在完成后并没有启动或放弃，因为管理层无法就如何“定位”它们达成共识（它们是很棒的功能）。 高管层一直处于政治内斗状态，这很可能来自狐狸和他们的狗屎行为。 没有人可以在这个级别上判断和奖励能力，这仅仅是关于谁可以更好地掩盖自己的屁股或看起来更好地表现出来。 MySpace 很大，每个人都只想吃一块。 由此产生的问题之一是缺乏对技术的尊重，即更高层次的人都没有将该公司视为技术公司。 他们将其视为娱乐或媒体公司。 这造成了文化上的问题，最终导致不良产品和伪劣实施。 现在，该组织的核心技术部分实际上非常胜任。 在鼎盛时期，MySpace 吸引的流量超过了 Google，那时该网站的规模还算不错。 那不是偶然的，我和那里的一些业内最聪明的人一起工作过。 但是因为技术不是高管的重点，所以这些人受到非技术管理人员的严格控制，因此产品遭受损失。 MySpace 可以（而且仍然）可以扩展任何东西，也就是说，到了达到顶峰时，他们已经遇到了扩展问题，这完全是乱码。 多年来，他们开发了非常成熟的技术堆栈。 没有人知道，因为它是完全专有的。 问题是管理和产品基本上...无能为力，并且缺少适当水平的任何人来照顾和修复它。** +27. **mhewett** ：我不确定这些基于技术的分析是否正确。 当时我有四个少年，他们都从 MySpace 切换到 Facebook，因为 MySpace 的页面上充斥着耀眼的广告。 Facebook 布局更整洁，并且没有广告（当时）。 网站速度没有问题。 +28. **晕眩**：这表明技术和位置的选择不是原因，它们是公司管理层的症状，他们不了解构建简单的 Internet 应用程序（最佳的技术堆栈是什么； 在何处，何时何地聘用开发人员来构建），并保留进行所有技术决策的权限。 与此形成鲜明对比的是，与 Google 等人的 Facebook 相比，在这里设计每个流程（从公司 IT 到生产运营再到人力资源和招聘）时，都必须考虑到工程组织的需求：“想要两个 24”显示器吗？ 没问题。 想要在笔记本电脑上使用 Linux 吗？ 没问题。 想要 ssh 进入生产环境吗？ 没问题。 想参加候选人面试吗？ 没问题。” +29. **sriramk** ：我有来自 MySpace 的一堆朋友，我听到的一个共同主题是，他们认为更好的架构（未连接到堆栈）会让他们更快地发货。 看来您可以忍受的技术债务是有限的。 如果您重写得太快，您会被一家通过大量重写/重新设计工作而杀死其产品的公司取笑。 花了太长时间，像 FB 这样的人很快就发布了功能并跃居您的前面。 +30. **ChuckMcM** ：我认为企业家的见解是“网络”不是“企业”。 微软已经花费了数十亿美元来瞄准“企业”（与 SAP，Oracle，Salesforce 等大型软件公司竞争），其结构和部署与“网络”（大型用户是 Google，Facebook 等）截然不同。 当我在 NetApp 工作时，我们在世界各地都有客户，我们发现**“企业”家伙经常有节奏，例如成长，发现挑战，努力，升级，重复** 。 这个周期是围绕着获取最新版本的“大型播放器”软件，对其进行鉴定，然后使其投入生产，进行一些扩展，确定问题出在哪里，与他们的供应商交谈，等待，获取新版本然后重复来进行的。 周期。 但是“网络”玩家的节奏最好是零星的，并且常常是疯狂的，功能请求，测试，迭代，功能，迭代，测试，海岸，海岸，海岸，功能，功能，功能，测试，海岸等。 他们会立即实现某种原型或测试用例的“网络”基础架构人员，然后迅速提出支持该功能以最大化该功能所需的基础架构功能。 但是有时它们会花费很长时间，几个月，而不会发生任何变化（在基础架构方面，网页，UX 等方面肯定会发生变化，但是服务器和存储资产相同）。 我从中学到的东西是，虽然在运营费用方面拥有其他公司来承担“基础基础架构”的负担真是太好了（但是，如果您不更改该级别的内容，那么您就不需要 Linux 黑客了，所以 节省员工等），这对变更衍生产品施加了硬性限制。 如果您尝试更改的速度快于基础架构的更改速度，结果是您最终会受到限制，并且会积聚技术疤痕组织，随着时间的流逝，这会进一步降低您的移动性。 因此，最重要的是，您将无法继续以比基础架构更快的速度进行枢纽工作，如果您正在围绕基础架构进行变更，那么您的变更能力将因一千次黑客攻击而消失。 如果您发现自己需要思考一下您的基础架构，请听从该警告，并开始规划一个更加敏捷的基础，以便从现在开始工作，而不是当我们在开发一个全新的系统时仍在努力保持旧系统正常运行时。 +31. **phlux** ：确实可以做出一种基础架构选择，即政策，它将为您提供整个公司基础架构生命周期内的最佳可用路径：全面虚拟化 +32. **akshat** ：硅谷的人才也许很棒，但我敢打赌，任何大都会都有足够的优秀开发人员来使任何网络公司成功。 您需要成为一个能够吸引此类人的地方。 +33. **Lukeas14** ：您可以尝试指责 Myspace 的“死亡螺旋式增长”是由于他们的技术堆栈转移到了洛杉矶，但根本原因是他们无法创新。 实际上，2010 年的网站与 2002 年的网站相同。请考虑一下 Facebook 当时发布并重新推出了多少新功能。 曾经有一段时间，许多人喜欢他们自定义设计的个人资料页面。 但是后来他们长大了，而 MySpace 却没有。 -NetFlix 有一个关于文化的著名演讲。 这些概念是关于重新思考人力资源的。 他们的许多人员都集中在此演示文稿的原理上。 这是一些示例幻灯片和演示。 这为文化提供了重要的背景，以了解他们如何扩展软件堆栈以及其工作原理。 +我的一些观察： -![](img/8d605f04aca2955e4e075846c21344e7.png) +* 堆栈不是真正的问题。 那简直太傻了。 查看 Windows，.Net 等，如果使用正确，它们都具有相当的伸缩能力。 Facebook 从 LAMP 开始，但是在此过程中，他们改变了一切，因此很难说他们最终仍在使用 LAMP。 Twitter 与 RoR 经历了类似的阶段。 如果没有改变您要触摸的所有东西来满足您的特定需求，您就无法以如此规模生存。 Facbook 还使用非常小的团队，因此您实际上并不需要大量的人才。 您需要一些才华横溢的人才，这些人才应有正确的愿景，支持和支持，让他们自由解决问题。 +* 问题是为什么技术没有正确使用？ 这些评论指出了许多不同的原因，但最终都归结为人们。 他们被不重视技术的管理团队收购了吗？ 如果可以相信某些开发，发布和设计决策，则可能会出现这种情况。 核心竞争力似乎已经转移给了第三方。 像 SAN 这样的技术被引入来解决问题，而不是直接解决问题。 两者都是致命的。 无论使您获得成功，都必须完全拥有。 也许作为“娱乐”公司而不是技术公司会促进这种方法。 但这又会回到所有权和管理上。 人们似乎忘记了，除非他们是魔术师，否则天赋就不能在直筒夹克中发挥作用。 +* 创新问题很有趣。 我们看到 Facebook，Amazon，Google 和 Apple 等公司不断创新。 这对 MySpace 的命运有多重要？ 为什么创新对他们不重要？ -![](img/1e6dabcae21af4ad40187f8c2abca958.png) +所以发生了什么事？ 更重要的是，公司中的新创业公司和集团如何避免这种命运？ 我们一直都在看。 这让所有参与其中的人感到沮丧。 我们现在不应该过去这种事情吗？ -完整演示文稿在这里[。](http://www.scalescale.com/the-stack-behind-netflix-scaling/#) +## 相关文章 -## 通过 Amazon 支持许多标题 +* [StackOverflow](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 和 [PlentyOfFish](http://highscalability.com/plentyoffish-architecture) 是成功使用 Microsoft 技术的公司的著名示例。 但请注意，他们利用了它，这与将王国的钥匙交给没有与您一致的目标的公司不同。 仅将农场押在您身上。 LAMP 堆栈是独立的组件，易于更换和修改。 当您购买完整的堆叠时，遇到问题时就会陷入困境。 您永远不想被困住。 +* 关于[黑客新闻主题](http://apps.ycombinator.com/item?id=2369343)的好的评论 +* [MySpace 如何测试 100 万个并发用户的实时站点](http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html) -Netflix 的基础设施位于 Amazon EC2 上，来自电影制片厂的数字电影原版存储在 Amazon S3 上。 使用云上的机器，根据视频分辨率和音频质量，每部电影被编码为 50 多种不同版本。 超过 1 PB 的数据存储在 Amazon 上。 这些数据被发送到内容传递网络，以将内容提供给本地 ISP。 +我不知道要捍卫.NET 作为初创企业的可行平台有多少次，我自己的初创企业 [SocialDeal.net](http://www.socialdeal.net) 是建立在.NET 上并由 Azure 托管的。 我已经到了这样的地步：我再也很少和平台迷们一起参加火焰战了，这简直是无利可图，我的时间最好花在其他事情上。 只要我看到 Microsoft 像他们使用 MVC 框架和 Azure 所做的那样继续发展它，我就会对.NET 作为启动平台充满信心。 如果我只是尝试在 RoR 或 Python 中构建 SD 只是为了时髦或者试图解决一些虚构的问题以扩展数百万个用户，我根本就不会启动该站点，因为总的时间投入和架构应用程序意味着 它从未完成过，而从未启动过的应用程序所带来的失败远大于后来尝试扩展的问题。 -Netflix 在后端使用了许多开源软件，包括 Java，MySQL，Gluster，Apache Tomcat，Hive，Chukwa，Cassandra 和 Hadoop。 +我认为您是对的，技术堆栈并不是杀死他们的工程文化的原因。 -[![](img/4d386bb464a1074eac1f4f986835c070.png)](http://2zmzkp23rtmx20a8qi485hmn.wpengine.netdna-cdn.com/wp-content/uploads/2015/11/netflix-architecture.png) +这是我的全部观点。 Myspace 肿。 到处都是垃圾邮件发送者和骗子。 他们允许人们无限使用 HTML 和 Java 来自定义其页面的事实，这意味着没有一致的用户体验，而且某些自定义页面需要花费几分钟才能加载或挂起 Web 浏览器。 然后是 Facebook。 一切都很干净有光泽，并且很容易找到所有的朋友（新老）。 另外，Facebook 提供了与 Myspace 的骗子和垃圾邮件发送者不同的步伐（是的，Facebook 拥有其中的一些功能，但与 Myspace 的体验完全不同）。 -## 支持多种设备 +不要责怪这里的幕后技术（最终用户只要获得想要的用户体验就可以少在乎幕后的东西），也不要责怪洛杉矶。 洛杉矶有很多非常有才华的开发商。 -Netflix 上大量的编解码器和比特率组合意味着“在将相同的标题交付给所有流媒体平台之前，必须对其进行 120 次不同的编码”。 +技术堆栈吸引或排斥工程师。 实际上，这确实很重要，最好的工程师想要使用他们认为是最好的工具。 -尽管 Netflix 使用自适应比特率流技术来调整视频和音频质量以匹配客户的下载速度，但它们还为用户提供了在其网站上选择视频质量的能力。 +我想认为.NET 可以根据我们的经验进行扩展，这只是做对的事情。 我们在 Flash / iOS UI，.NET 服务层以及 MySQL（XtraDB）数据库和 MySQL Cluster 数据库的混合堆栈上运行了成功的世界教育游戏。 它可能没有看到像 Facebook 这样庞大的规模，但是它在不到 4 天的时间里成功处理了将近 10 亿个服务器请求，有 250 万孩子参加了舞会，而我们背后的那些人则设法获得了愉快的体验 我们自己，只有 40％的基础架构得到了利用。 -您可以从提供 Netflix 应用程序的任何与 Internet 相连的设备上立即观看，例如计算机，游戏机，DVD 或蓝光播放器，HDTV，机顶盒，家庭影院系统，电话或平板电脑。 +MySpace 失败，因为用户离开了。 用户（包括我自己）没有离开，因为它运行在 Microsoft 堆栈上。 我们离开是因为所有 MySpace 都对成为一家媒体公司感兴趣。 人们想要一个社交网络，而今天，Facebook 或多或少都是这样。 -它们以不同的比特率支持以下编解码器中的每个标题，以使其在设备和连接上工作。 +MySpace 的问题是系统性的，而不是系统性的。 非专业的开发组织。 政治内斗。 诉讼。 他们从不曾是硅谷公司，而是一家以色情，垃圾邮件和恶意软件而诞生的洛杉矶公司，后来想成为好莱坞公司-他们贪婪地追求浮华与魅力，却拥有烂透了的技术核心。 -* 视频– [VC-1](https://en.wikipedia.org/wiki/VC-1) ， [H.264（AVC）](https://en.wikipedia.org/wiki/H.264)，VC-1， [H.263](https://en.wikipedia.org/wiki/H.263) ， [H.265（HEVC）](https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding) -* 音频– [WMA](https://en.wikipedia.org/wiki/Windows_Media_Audio) ，[杜比数字](https://en.wikipedia.org/wiki/Dolby_Digital)，[杜比数字 Plus](https://en.wikipedia.org/wiki/Dolby_Digital_Plus) ， [AAC](https://en.wikipedia.org/wiki/Advanced_Audio_Coding) 和 [Ogg Vorbis](https://en.wikipedia.org/wiki/Ogg_Vorbis) +Myspace 进行了有毒技术管理。 这是我唯一一次接受采访。 他们为才华横溢而不是因为缺乏才华，而是因为 CTO（缺乏个性）和他的兄弟般的小伙子使周围的环境变得可怕。 在洛杉矶，这里有很多伟大的才华，他们根本不愿意成为“好莱坞”。 -### Netflix Open Connect CDN +我同意新闻集团杀死 MySpace 的想法。 没有互联网的人不应该管理互联网公司。 并不是后端服务器上正在运行的内容，而是当您访问首页时，它们让您头疼的大型恐怖视频广告/横幅广告。 这是设计不足的用户体验。 这是他们基于 Flash 的聊天应用程序从未起作用的事实。 -Netflix Open Connect CDN 是为拥有超过 100,000 个订阅者的大型 ISP 提供的。 一种特殊构建的低功耗高存储密度设备可将 Netflix 内容缓存在 ISP 的数据中心内，以降低互联网传输成本。 该设备运行 FreeBSD 操作系统， nginx 和 Bird Internet 路由守护程序。 +有许多与 Microsoft 堆栈一起工作的人才。 如果您的眼光正确，MS 技术可以使您更快地执行。 -![](img/46e25abc5f6631b9baee6e4c4b6cb016.png) +简单而失败的原因是用户界面被大量吸引。 您需要登录页面，然后是实际页面，并且必须剪切并粘贴 javascript 代码段和 html 代码段等以使其正常工作。 然后，您必须去寻找其他东西来使这个或那个工作。 -NetFlix 巴黎公开赛–图片来源：@dtemkintwitter +然后出现了 facebook，您登录时只有一个简单而简单的用户界面，其中包含一小套有效的工具来查找您的朋友。 然后，facebook 将游戏放入其 API 中，这可以让人们了解在何处以及为什么人们真正使用 facebook。 拿走游戏，您可能会失去一半以上的 facebook 人口。 但是总体的关键部分和前进的关键是一个轻巧的用户界面，它不需要您在网上搜索 javascript 小程序或 html 代码来创建 myspace 页面。 您有在 Facebook 中自定义或唯一的自由吗？ 并非完全不一样，对于 Twitter 一样，是的，您可以添加一个后挡板并用颜色标记一些内容，但总体来说，它锁定在用户刚刚使用的 UI 中。 -在处观看 Open Connect 视频[。](https://www.youtube.com/watch?v=mBCXdaukvcc) +那是主要的区别，干净，易于使用的 UI 与糟糕的 UI 甚至使我成为 Web 开发人员的疯狂尝试。 如果真能说出我的妻子，更不用说我的母亲使用 myspace 了。 Facebook，尽管嘿，单击此信息选项卡，单击铅笔并填写一些内容，然后单击此查找朋友并享受。 -## 缩放算法 +@ fatal.error，各个领域都有出色的工程师.... NET，LAMP，JAVA 等... -在 2009 年，Netflix 举办了一项名为 [Netflix 奖](https://en.wikipedia.org/wiki/Netflix_Prize)的竞赛。 他们打开了一堆匿名数据，并允许团队尝试得出更好的算法。 获胜团队将现有算法提高了 10.06％。 Netflix 打算再获得一个 Netflix 奖，但最终没有这样做，因为 FTC 担心隐私。 +摘自文章：“这就是为什么 Facebook 能够部署几乎没有影响的新更改的原因-他们在让实际用户使用之前对其进行了所有测试和验证。” -Netflix 推荐系统包含许多算法。 生产系统中使用的两个核心算法是受限玻尔兹曼机（RBM）和一种称为 SVD ++的矩阵分解形式。 使用线性混合将这两种算法结合在一起以产生单个更高的准确性估计。 +真？！ 您是否曾经开发过 FB 应用程序？ 您是否曾经听过全球开发人员大喊大叫的声音，是因为 FB 的男孩天才编码员将错误的代码投入了生产，并且破坏了所有人的应用程序？ 您是否曾经需要处理过时，不准确的文档以及不断变化的 API？ 以及如何神奇地实现 oauth。 -受限玻尔兹曼机是经过修改以在协同过滤中工作的神经网络。 每个用户都有一个 RBM，每个节点的输入节点代表该用户已评分的电影。 +那篇文章真是太棒了。 我想我现在要去寻找一个著名的基于 Java 的失败... -SVD ++是 SVD（奇异值分解）的不对称形式，它利用了 RBM 等隐式信息。 它是由 Netflix 竞赛的获胜团队开发的。 +哈哈，我同意 FredTheKAt -Netflix 团队在其工程博客上介绍了[学习个性化主页](http://techblog.netflix.com/2015/04/learning-personalized-homepage.html) +Facebook 在提供良好的开发人员体验方面毫无用处。 -## 开源项目 +然而，尽管应用程序在移动平台上是屈膝的（是的，我曾经使用过），但 Facebook 的抽奖卡是最终用户，可以跟上他们所有的朋友。 如果用户体验始终如一，那将是成功的。 MySpace 失败。 -[https://netflix.github.io/](https://netflix.github.io/) 。 Netflix 有一个很棒的工程博客，最近他们在 Netflix 上发表了一篇名为 [The Evolution of Open Source 的文章。](http://techblog.netflix.com/2015/10/evolution-of-open-source-at-netflix.html) +我确实觉得很有趣，尽管认为自己锁定了 FB 个人资料的人现在已经以某种方式神奇地擦除了第三方在锁定之前（实际上是在他们授予游戏/应用访问权限之后）关于他们的所有数据。 数据却没有真正实现！ 如果人们真的了解 FB 的工作原理，我认为它不会那么受欢迎。 -## 大数据 +除了所有的技术故障（是的，我认为他们的代码很糟糕）之外，MySpace 的主题始终总是令人感到恶心-允许未成年的孩子不受监督地访问网络。 这些孩子（和我的孩子）长大了，获得了一定的品味，并发现 MySpace 俗气。 当年龄较大的孩子转向 Facebook 时，年龄较小的孩子们紧随其后。 -* [Genie](https://github.com/Netflix/genie) -对我们各种数据处理框架（尤其是 Hadoop）的强大，基于 REST 的抽象。 -* [Inviso](https://github.com/Netflix/inviso) -提供有关我们 Hadoop 作业和集群性能的详细见解。 -* [口红](https://github.com/Netflix/lipstick)-以清晰，可视的方式显示 Pig 作业的工作流程。 -* [Aegisthus](https://github.com/Netflix/aegisthus) -启用从 Cassandra 中批量提取数据以进行下游分析处理。 +MySpace 俗气。 孩子们（年龄较大和较小）不再认为 MySpace 很酷-这是有充分理由的。 -## 构建和交付工具 +新闻集团买了一些黏糊糊的东西，现在赔本了。 好。 -* [Nebula](https://nebula-plugins.github.io/) -Netflix 努力共享其内部构建基础结构。 -* [代理程序](https://github.com/Netflix/aminator)-用于创建 EBS AMI 的工具。 -* [Asgard](https://github.com/Netflix/asgard) -用于 Amazon Web Services（AWS）中的应用程序部署和云管理的 Web 界面。 +MySpace 很棒，但是当他们想成为 Facebook 的时候，他们就完全失去了可爱的功能。 这以及对用户的完全不尊重使我停止了回来。 并非所有事情都与竞争相同……要独树一帜，这是我的建议……技术应促进一个目的，而不是目的。 -## 通用运行时服务&库 +由于放弃了其功能集和可用性，MySpace“丢失了”。 -* [Eureka](https://github.com/Netflix/eureka) -Netflix 云平台的服务发现。 -* [Archaius](https://github.com/Netflix/archaius) -分布式配置。 -* [功能区](https://github.com/Netflix/ribbon)-弹性和智能的进程间和服务通信。 -* [Hystrix](https://github.com/Netflix/hystrix) -提供超越单次服务呼叫的可靠性。 在运行时隔离等待时间和容错能力。 -* **[Karyon](https://github.com/Netflix/karyon)** 和 **[控制器](https://github.com/Netflix/governator)-** JVM 容器服务。 -* [Prana](https://github.com/Netflix/prana) sidecar - -* [Zuul](https://github.com/Netflix/zuul) -在云部署的边缘提供动态脚本化代理。 -* [Fenzo](https://github.com/Netflix/Fenzo) -为云本机框架提供高级调度和资源管理。 +如果您无法像 Facebook 一样快增长，那又如何呢？ MySpace 拥有自己的利基市场，并在自己的领域处于领先地位-年轻人的音乐和社交网络。 -## 数据持久性 +此故障与 Microsoft 技术无关。 -* **[EVCache](https://github.com/Netflix/EVCache)** 和 **[炸药](https://github.com/Netflix/dynomite)** **-** 用于大规模使用 Memcached 和 Redis。 -* **[Astyanax](https://github.com/Netflix/astyanax)** 和 **[Dyno](https://github.com/Netflix/dyno)** **-** 客户端库可更好地使用云中的数据存储。 +技术人员不会创新或设计，他们会实施 -## 洞察力，可靠性和性能 +成功的网站是由用户体验驱动的。 Facebook 和 Twitter 是示例。 因为他们真正关心最终用户，所以他们所做的事情可以提供良好的体验。 设计师和建筑师的工作是否能够提供良好的用户体验，而不是“老板”会感到高兴。 -* [Atlas](https://github.com/Netflix/atlas) -时间序列遥测平台 -* [Edda](https://github.com/Netflix/edda) -跟踪云中更改的服务 -* [观众](https://github.com/Netflix/spectator)-Java 应用程序代码与 Atlas 的轻松集成 -* [向量](https://github.com/Netflix/vector)-以最小的开销公开高分辨率的主机级指标。 -* [Ice](https://github.com/Netflix/ice) -揭示了持续的成本和云利用率趋势。 -* [Simian Army](https://github.com/Netflix/SimianArmy) -测试 Netflix 实例是否出现随机故障。 +因此，这是关于文化和人员（主要是关于大老板，他必须关心最终用户），而不是技术。 -## 安全性 +但是，另一方面，最佳用户体验驱动的网站通常不是基于 MSFT，IBM 或 ORACLE 的 COTS 产品构建的。 那也可以说。 -* [Security Monkey](https://github.com/Netflix/security_monkey) -帮助监视和保护基于 AWS 的大型环境。 -* [Scumblr](https://github.com/Netflix/scumblr) -利用整个 Internet 的针对性搜索来发现特定的安全问题以进行调查。 -* [MSL](https://github.com/Netflix/MSL) -一种可扩展且灵活的安全消息传递协议，可解决许多安全通信用例和要求。 -* [Falcor](https://netflix.github.io/falcor/) -通过虚拟 JSON 图将远程数据源表示为单个域模型。 -* [Restify](https://github.com/restify/node-restify) -专门用于 Web 服务 API 的 node.js REST 框架 -* [RxJS](https://github.com/ReactiveX/RxJS) -用于 JavaScript 的反应式编程库 +“技术不是创新或设计，而是实施” -## 参考资料 +@另一个声音：醒来的人..... -1. [关于 HackerNews](https://news.ycombinator.com/item?id=10534219) -2. [https://zh.wikipedia.org/wiki/Netflix](https://en.wikipedia.org/wiki/Netflix) -3. [http://gizmodo.com/this-box-can-hold-an-entire-netflix-1592590450](http://gizmodo.com/this-box-can-hold-an-entire-netflix-1592590450) -4. [http://edition.cnn.com/2014/07/21/showbiz/gallery/netflix-history/](http://edition.cnn.com/2014/07/21/showbiz/gallery/netflix-history/) -5. [http://techblog.netflix.com/2015/01/netflixs-viewing-data-how-we-know-where.html](http://techblog.netflix.com/2015/01/netflixs-viewing-data-how-we-know-where.html) -6. [https://gigaom.com/2013/03/28/3-shades-of-latency-how-netflix-built-a-data-architecture-around-timeliness/](https://gigaom.com/2013/03/28/3-shades-of-latency-how-netflix-built-a-data-architecture-around-timeliness/) -7. [https://gigaom.com/2015/01/27/netflix-is-revamping-its-data-architecture-for-streaming-movies/](https://gigaom.com/2015/01/27/netflix-is-revamping-its-data-architecture-for-streaming-movies/) -8. [http://stackshare.io/netflix/netflix](http://stackshare.io/netflix/netflix) -9. [https://www.quora.com/How-does-the-Netflix-movie-recommendation-algorithm-work](https://www.quora.com/How-does-the-Netflix-movie-recommendation-algorithm-work) -10. [https://netflix.github.io/](https://netflix.github.io/) +说.NET 是 MySpace 失败的原因，就像说 MySQL 是 Facebook 成功的原因。 两种说法都是荒谬的。 -在哪里提到 Spring？ Netflix 的所有 Java 都在 Spring 框架的上下文中。 +没有 1.）任何内幕知识 2.）有很多事实或实质可以支持，但这里有很多观点。 这是一个完全愚蠢的陈述，它既显示了对技术的严重误解，也显示了使业务成功或失败的根本过分简化。 -到目前为止，这还不是一个完整的列表。 不好的文章。 +我向所有神圣的事情祈祷，我自己不必再在.NET 中工作。 这不是我的最爱，严格来说，由于许可证成本，它可能不是小型初创公司的好选择，但这只是纯粹的精英 BS 所说的，仅仅是因为您的技术堆栈是.NET，所以您不是创新者或 与竞争对手相比，您在技术上有残障。 -NetFlix 不使用 Spring，至少他们从未在任何演示文稿或白皮书中提及 Spring。 +如果您足够愚蠢以至于无法让这些话从您的嘴里溜走，我建议您更好地隐藏内心的障碍。 它正在显示，每个人都可以看到。 -我在这里看不到他们使用 Node.JS 吗？ 我记得曾经从他们那里看到幻灯片，谈论他们如何处理 Node.JS 的服务以及如何优化这些服务。 +我在看着你 Scoble。 坚持您所了解的主题。 -有一些使用 Spring 的应用程序，但是 95％以上的 Java 应用程序直接使用 Guice 或通过 Governor 增强。 +不是技术，也不是城市。 是福克斯。 -他们在那里的服务中使用 guice 代替。Governator 是一个很好的 guice 扩展库，尽管将它们标记为已弃用，您仍可以在该库中找到一些硬编码的依赖项。 +被 Fox 收购后，Myspace 的命运得以终结。 购买后，我们的目标是通过各种方式使网站获利，并尝试为可想象的每种广告资源建立少量的垂直市场... myspace 天气 myspace 汽车 myspace 等等。 他们对用户没有真正的构想，方向或价值主张。 -好像他们没有在使用 docker ... +一旦来自 Facebook 的威胁得以实现，缺乏真正领导才能的痛苦就变得显而易见。 他们开始复制并关注 Facebook 所做的事情-反应而不是创新。 游戏结束。 -您在“受限玻尔兹曼机器”中写了“玻尔兹曼”错误。 +这太糟糕了。 一次 MySpace 是年轻人去表达自己并分享音乐品味的地方。 MySpace 应该完全拥有音乐产业。 -@ cmp，restify 是使用 Node 并为其构建的 Web API 框架。 +我将不得不同意 MySp Fox 的购买，但没有做任何其他事情，只是错过了管理其资产的工作，也没有采取任何措施来改善它。 也许他们需要写一些税款。 但是除非您确定自己知道如何使它更好地工作以便可以提高利润，否则您不会购买任何东西。 直到交易完成约 30 天，它的表现都不错。 在[闪光灯](http://www.arcflashstudynow.com)中，您几乎可以看到它开始爆炸。 只是我的想法希望没有人会被他们冒犯。 :)很棒的信息。 -本文是有缺陷的，它没有说明软件公司最重要的事情，即：他们使用哪个需求管理系统，以及它们如何保持需求与代码之间的可处理性？ +在研究（针对单篇论文）关于社交网站的技术含义以及为什么其中一些失败如此之快而另一些却没有这样时，我遇到了这篇文章。 关于它的技术，这种技术是您经常听到的技术，因此这篇文章对我来说是一本好书。 -他们确实使用 Spring Cloud，这是参考 https://2015.event.springone2gx.com/schedule/sessions/spring_cloud_at_netflix.html +但是，如果它们达到 Facebook 的大小会怎样？ 这样可以达到这样的规模吗？ +这是一个有趣的（研究）问题-也许可以解决技术问题，在这种情况下，更大的问题是“如何向 MS 支付许可费？” -我保证：如果像彼得·泰尔这样的投资者走上原来的道路，他们不会给他们钱？ -炸药列在错误的类别下。 当前，它是一个分布式的内存存储。 +MySpace 允许用户在其页面上放置无限数量的应用之后，立即开始令人垂涎。 它导致页面加载和 Web 服务器无法正常运行。 他们通常不会使 CPU 或内存最大化，但会引发无数错误。 每天都会将网络中断带到一个大房间里，以责骂失败者（员工）。 糟透了。 -出色的工作！ -从所有者到 Netflix 的内容交付（关系图上的左箭头）使用 SMPTE 的可互操作主格式（IMF）。 视频使用 JPEG-2000 编码，音频未编码（线性 PCM）。 内容使用 MXF 打包（例如，非常类似于 D-Cinema 的内容）。 -SMPTE 当前正在努力扩展此标准，以支持 HDR +视频：高动态范围（HDR）可提供更多的对比度，宽色域（WCG）可提供更多的颜色，高帧速率（HFR）可以每秒 50 帧或更多。 -来自 Netflix 的 Chris Fetner 提供详细信息的柏林论坛 2015 年会议上的详细信息： -http://www.mesclado.com/smpte-forum-2015-future-proofing-media-production-part-3/ ？lang = en +对于 50％负载的计算机，解决方案是对其进行虚拟化，而不是修复奇怪的创可贴和少量垃圾。 -Netflix 还使用 Groovy 编程语言和 RxJava 进行功能性反应式编程（请参阅 http://de.slideshare.net/InfoQ/functional-reactive-programming-in-the-netflix-api） +Captcha 被收费低廉的印度人团队殴打（没有冒犯的意思），但他们同意不对进一步揭露他的方法的人采取进一步的法律行动。 并不复杂。 因此，在垃圾用户，垃圾邮件发送者和他们可能会塞进的每一个垃圾功能之间走下坡路。 -Netflix 使用 ElasticBox 来管理后台。 他们还在许多地方使用 Docker。 - -Netflix 还运营着一个相当大的 Elasticsearch 集群。 参见 https://www.elastic.co/videos/netflix-using-elasticsearch/和 https://www.elastic.co/elasticon/2015/sf/arrestful-development-how-netflix-uses-elasticsearch-to- 更好地了解 - -Netflix 是 Apache Cassandra 的已知用户。 他们的技术博客对此进行了广泛报道，而 Netflix 对此已经非常公开。 （作为一个旁注，我在同一博客上找不到任何标记 DynamoDB 的帖子）。 - -Netflix 使用 Node.JS。 本文只有 50％正确。 这里的一些内容，我们已经从其他内容切换到了。 我在 Netflix 的工程团队工作。 我们确实使用 Cassandra。 我们还使用 Reactor.JS。 一直在进行变化以适应技术变化。 我们混合使用了 JS 库，并完成了许多自定义工作，例如滑块。 - -netflix 是否使用带有 typescript 的节点，它们如何使用动态类型的 JS 维护大型节点应用程序 - -只需在 github 上的 Netflix 上寻找 Java 技术，他们为 Spring-Cloud 做出了很大贡献。 -另请参阅 OSS：https：//netflix.github.io/ \ No newline at end of file +我的 2 美分。 \ No newline at end of file diff --git a/docs/64.md b/docs/64.md index a0dc967..63084b6 100644 --- a/docs/64.md +++ b/docs/64.md @@ -1,101 +1,171 @@ -# Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售 - -> 原文： [http://highscalability.com/blog/2015/11/2/how-shopify-scales-to-handle-flash-sales-from-kanye-west-and.html](http://highscalability.com/blog/2015/11/2/how-shopify-scales-to-handle-flash-sales-from-kanye-west-and.html) - -![](img/496178f66cd6eb10235644541a56d67d.png) - -*这是[缩放您的代码](https://twitter.com/christophelimp)的创建者 Christophe Limpalair 提出的来宾[重新发布](https://scaleyourcode.com/blog/article/23)。* - -在本文中，我们介绍了 Shopify 使平台具有弹性的方法。 这不仅有趣，而且实用并且可以帮助您开发自己的应用程序。 - -## Shopify 的扩展挑战 - -Shopify 是一个电子商务解决方案，每个月处理大约 3 亿独立访客，但是正如您所看到的，这 3 亿人不会以均匀分布的方式出现。 - -他们的**最大挑战之一是所谓的“闪存销售”** 。 这些快速销售是在非常受欢迎的商店在特定时间销售商品的时候。 - -例如， **Kanye West** 可能会出售新鞋。 结合 **Kim Kardashian** ，仅 Twitter 上的**就有 5000 万人以下**。 - -他们也有在超级碗上做广告的顾客。 因此，他们不知道会有多少流量。 **可能有 200,000 人在 3:00** 出现，并在几个小时内结束特价销售。 - -**Shopify 如何适应这些流量的突然增加？** 即使他们无法在特定销售中很好地扩展规模，也如何确保它不会影响其他商店？ 在简要说明 Shopify 的上下文架构之后，这就是我们将在下一部分中讨论的内容。 - -## Shopify 的架构 - -即使 Shopify **去年移至 Docker** ，他们**仍未脱离 Monolithic 应用程序**。 我问西蒙（Simon）为什么，他告诉我说，他们并不会轻易承担[微服务](http://martinfowler.com/articles/microservices.html "Microservices explanation")的开销。 但是，如果他们决定走这条路，此举使他们在将来可以更轻松地过渡。 - -无论如何，它们的体系结构看起来像这样： - -一个**请求**进入 **Nginx** ，然后进入运行中的**服务器集群 带有 Rails 应用程序**的 Docker。 - -对于**数据层**，他们使用以下方法： - -* 记忆快取 -* 雷迪斯 -* 弹性搜索 -* 的 MySQL -* 卡夫卡 -* 动物园管理员 - -此**的大部分运行在自己的硬件**上。 他们还在 AWS 上运行了**几件事。 - -为了降低成本，Shopify **运行多租户平台**。 这意味着它们在单个服务器上有多个商店-例如，shopA.com 和 shopB.com 是从同一服务器提供服务的。 - -即使迁移到 Docker [并非一帆风顺](https://www.youtube.com/watch?v=Qr0sATj9IVc "Simon Eskildsen on switching to Docker")，他们最终还是从中获得了一些好处： - -迁移到 Docker 使 Shopify 得以运行 **在大约 5 分钟（Docker 之前的 15 分钟）内在数十万行 Ruby 上进行持续集成**，并在 3 个数据中心中将其部署到 300-400 个节点仅需 3 分钟（之前 15 分钟）。 这些是令人印象深刻的变化。** - -## 他们如何处理交通高峰 - -理想情况下，平台可以自行处理峰值。 这还没有完全实现，因此他们在大量销售之前要通过**性能清单**。 - -在 Kanye West 的示例中，他们坐了 2 周，并通过组合平台的关键部分进行了**广泛的被动负载测试和性能优化**。 - -为了运行各种测试，他们使用了称为“弹性矩阵”的工具。 - -![Resiliency Matrix used at Shopify](img/df836800db08262494198fa988c2a99f.png) -（图片来自 [Simon 的会议演讲](https://speakerdeck.com/sirupsen/dockercon-2015-resilient-routing-and-discovery "Simon Eskildsen on Resilient Routing and Discovery and Dockercon 2015")） - -**弹性矩阵**可以帮助确定服务提供时系统发生了什么 下跌降落。 - -说 Redis 失败了，Redis 被用作结帐的组成部分。 您是否将整个站点拆毁并置于维护模式？ 不，您可以退出所有人，仍然允许他们在没有客户帐户的情况下进行结帐。 然后，在 Redis 备份后，将电子邮件地址与客户帐户相关联并填补空白。 - -进入系统列表（如店面，管理仪表板，API 等），然后查看服务中断时会发生什么—系统的其他部分也会受到影响？ 尝试**消除这些依赖关系，您的应用程序弹性将大大提高。** 这就像一条链，您的应用程序的强度仅与最弱的链接一样强。 - -![](img/716fcdec96974486047991f74d3587af.png) - -为了帮助此过程，Shopify 团队**开源了 Toxiproxy 和 Semian** 。 - -[Toxiproxy](https://github.com/Shopify/toxiproxy "Toxiproxy") 会在您选择的任何系统中引入**控制的潜伏期**。 - -![Toxiproxy](img/ae8ce68044fee28650f7401a5458b0f5.png) - -[Semian](https://github.com/Shopify/semian "Semian") 用于验证您没有**单点故障**。 - -![Semian](img/deba378a125528dc13a6b1af404b2c91.png) - -有关弹性的更多信息，请查看 [Simon 的会议演讲](https://speakerdeck.com/sirupsen/dockercon-2015-resilient-routing-and-discovery "Simon Eskildsen on Resilient Routing and Discovery and Dockercon 2015")中的其中之一，他将提供更多详细信息。 超级有趣。 - -在此弹性工作的基础上，Shopify 还能够**超额配置，因为他们拥有自己的硬件**。 对于他们来说这很便宜，但是如果您在云上运行，它可能不会那么便宜。 查看成本与收益的关系，看看是否对您有意义。 - -另一个大挑战是扩展数据存储。 由于 Shopify 处理金融交易，因此其数据库*不能*不同步。 解决方案？ **Shopify 在大约 2 年前对 MySQL** 进行了分片。 他们非常积极地进行分片，并且目标是随着时间的推移增加**和较小的分片**。 - -Simon 继续说**扩展数据库非常困难**-尤其是分片。 它几乎总是应该是不得已的方法。 您可能需要先缓存很多东西。 但是分片的好处是它们有助于隔离事件。 如果一个客户群中发生了一些疯狂的事情，那么整个平台中只有一小部分会受到影响。 - -回到弹性测试，Simon 强调说，大多数**数据库扩展问题已通过许多弹性工作和自动故障转移**得到解决。 - -## 他们计划进行哪些其他改进？ - -展望未来，团队正在研究**相互隔离的**层，它们相互为应用程序提供服务。 他们正在做的另一件事是让**的商店同时用完不同大陆上的多个不同数据中心**。 这对于数据局部性来说非常重要，也可以防止意外事件。 - -杰里米·埃德伯格（Jeremy Edberg）在[的采访](/interviews/interview/11 "Jeremdy")中告诉我，Netflix 也投入了大量资源来防范突发事件。 - -除了这些计划之外，他们还研究**使故障转移变得可以轻松地每天多次执行**。 如果您对它们如何在整个数据中心之间执行故障转移测试感到好奇，请参阅 [Simon 的采访页面](/interviews/interview/14 "Simon Eskildsen interview with ScaleYourCode")。 - -就目前的情况而言，他们无法在不临时取消检出的情况下对整个数据中心进行故障转移。 但是，他们目前正在研究一种解决方案，以解决此问题。 - -## 采取的行动 - -My goal with this article is to give you easily-digestible knowledge you can take action on. What action(s) can you take now? Well, you probably want to avoid sharding, so can you cache more? You may not be able to over-provision due to cost, but what about checking out the resiliency matrix? Even if you don't have the resources to pull this off right now, building one of these matrices or even just thinking about it can be helpful. - -如此高的收益率是您的瓶颈。 没有留下深刻印象 \ No newline at end of file +# Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰 + +> 原文： [http://highscalability.com/blog/2011/5/10/viddler-architecture-7-million-embeds-a-day-and-1500-reqsec.html](http://highscalability.com/blog/2011/5/10/viddler-architecture-7-million-embeds-a-day-and-1500-reqsec.html) + +![](img/1f9466f9ca35249e9a853aee49edfb83.png) Viddler 从事高质量视频即服务业务，该业务面向想要支付固定成本，使用它完成并付诸实施的客户。 与 Blip 和 Ooyala 相似，比 YouTube 更侧重于业务。 他们为成千上万的商业客户提供服务，包括 FailBlog，Engadget 和 Gawker 等高流量网站。 + +Viddler 是一个很好的案例，因为它们是一家小型公司，试图在拥挤的领域中提供具有挑战性的服务。 我们正抓住他们，就像他们从一家以 YouTube 竞争者起步的初创公司过渡到一家规模稍大的公司（专注于为企业客户付费）过渡一样。 + +过渡是 Viddler 的关键词：从免费的 YouTube 克隆过渡到高质量的付费服务。 从效果不佳的一些 Colo 站点过渡到新的更高质量的数据中心。 从典型的启动架构过渡到具有冗余，高可用性和自动化功能的架构。 从大量实验过渡到弄清楚他们想如何做并实现这一目标。 过渡到一种架构，在该架构中，功能使用不同的技术栈在地理上分散的团队中分散，以明确定义角色。 + +换句话说，Viddler 就像其他所有即将成熟的初创公司一样，值得一看。 Viddler 的系统架构师 Todd Troxell 非常友好地接受了我们的采访，并分享了有关 Viddler 架构的详细信息。 它是不同技术，组和流程的有趣组合，但似乎可以正常工作。 之所以行之有效，是因为所有活动部件的背后都是一个主意：让客户满意并给予他们想要的东西，无论如何。 这并不总是很漂亮，但是确实可以取得结果。 + +网站： [Viddler.com](http://viddler.com) + +## 统计资料 + +1. 每天大约有 700 万个嵌入视图。 +2. 每天大约上传 3000 个视频。 +3. 最高 1500 req / sec。 +4. 高峰期约有 130 人按下播放按钮。 +5. 2 月份投放了 1PB 视频 +6. 80T 仓储 +7. 最近 30 天内花在视频编码上的 CPU 时间为 45,160 小时 +8. 整天的使用量相对平稳，谷底和高峰之间只有〜33％的差异，这表明它们在全球范围内得到了大量使用。 [图形](http://farm3.static.flickr.com/2704/5705121724_845db30833_o.png)。 + +## 该平台 + +### 软件 + +1. Debian Linux +2. Rails 2.x-仪表板，根页面，竞赛管理器，各种子功能 +3. PHP-使用我们内部 API 的各种旧式子网站 +4. Python / ffmpeg / mencoder / x264lib-视频转码 +5. Java 1.6 / Spring / Hibernate / ehcache- API 和核心后端 +6. MySQL 5.0-主数据库 +7. Munin，Nagios，接站-监控 +8. Python，Perl 和 ruby-许多*许多*监视器，脚本 +9. Erlang - ftp.viddler.com +10. Apache 2 / mod_jk-后端 Java 应用程序的核心头端 +11. Apache / mod_dav-视频存储 +12. Amazon S3-视频存储 +13. Amazon EC2-上传和编码 +14. KVM-临时环境的虚拟化 +15. Hadoop HDFS-分布式视频源存储 +16. Nginx / Keepalived-所有网络流量的负载均衡器 +17. Wowza-RTMP 视频录制服务器 +18. Mediainfo-报告视频元数据 +19. Yamdi-Flash 视频的元数据注入器 +20. 人偶-配置管理 +21. Git / Github https://github.com/viddler/ +22. Logcheck-日志扫描 +23. 重复性-备份 +24. Trac-错误跟踪 +25. Monit-进程状态监视/重启 +26. iptables-用于防火墙-无需硬件防火墙-还可处理内部网络的 NAT。 +27. maatkit，mtop，xtrabackup-数据库管理和备份 +28. [预引导执行环境](http://en.wikipedia.org/wiki/Preboot_Execution_Environment)-计算机的网络引导。 +29. 考虑将 OpenStack 的 [Swift](http://swift.openstack.org/) 作为替代文件存储。 +30. [FFmpeg](http://www.ffmpeg.org/) -完整的跨平台解决方案，用于记录，转换和流传输音频和视频。 +31. 阿帕奇雄猫 +32. [MEncoder](http://en.wikipedia.org/wiki/MEncoder) -一个免费的命令行视频解码，编码和过滤工具。 +33. [EdgeCast](http://www.edgecast.com/) -CDN + +### 硬件 + +1. 他们的 colo 中总共有 20 多个节点： + 1. 2 个 Nginx 负载平衡器。 + 2. 2 个 Apache 服务器。 + 3. 8 个 Java 服务器运行该 API。 + 4. 2 个 PHP / Rails 服务器运行在前端。 + 5. 3 台 HDFS 服务器 + 6. 1 监控服务器。 + 7. 1 个本地编码服务器。 + 8. 2 个存储服务器。 + 9. 2 个 MySQL 数据库服务器以主从配置运行，计划迁移到 6 个服务器。 + 10. 1 个登台服务器。 +2. Amazon 服务器用于视频编码。 + +## 产品 + +注册一个 Viddler 帐户，他们会将您的视频转换为所需的任何格式，并将其显示在任何设备上。 它们提供了嵌入代码，仪表板和分析。 他们的目标是在一个简单的界面后面解决视频问题，使人们可以购买该服务而忘了它，它可以正常工作并完成您需要做的一切。 作为内容提供商，您可以出售视图并将广告添加到内容中。 他们将所有广告网络作为一种元界面引入 Viddler，以执行不同的广告平台。 + +## 架构 + +[![](img/d73001acfb1f94e8103f4873882c4d06.png)](http://farm3.static.flickr.com/2375/5704553989_0e42783c8f_o.png) + +1. 当前时代 + 1. 他们目前的系统运行在美国西部某个地方的可乐中的裸机上。 他们正在搬到纽约的 Internap。 + 2. 1 gbps 链接将它们连接到 Internet。 CDN 提供视频，并将视频直接加载到 Amazon 中进行处理，因此对于他们的主要站点，他们不需要的网络就更多。 + 3. 该系统由 2 个 Nginix 负载平衡器所控制，一个是主动的，另一个是使用 keepalived 的被动的。 选择 Nginix 是因为它是基于 Linux 的开放源代码，并且可以正常工作。 + 4. EdgeCast 用作分发内容的 CDN。 客户将视频直接上传到 Amazon，然后将视频处理并上传到 CDN。 + 5. Nginx 可以故障转移到两个 Apache 服务器。 Apache 服务器可以故障转移到运行 Tomcat 的后端服务器之一。 + 6. 他们的部分架构在 Amazon 中运行：存储以及它们的上载和编码服务。 + 7. 在 Cassandra 中进行了实验，以存储仪表板位置。 非常可靠，但将来可能会迁移到 MySQL。 + 8. Linode 上的两个图像缩放节点，用于为视频创建任意缩略图。 将来将移至纽约。 +2. Internap 的很快时代 + 1. 该网站最初的想法是免费的视频网站 YouTube，但更好。 然后，他们转向提供更高质量的服务，这表明需要更好，更可靠的基础架构。 + 2. 他们正在迁移到 Internap，因此尚未解决所有问题。 他们先前的数据中心中的一些问题促使此举： + 1. 网络问题，某些 [BGP](http://en.wikipedia.org/wiki/Border_Gateway_Protocol) （边界网关协议）提供程序将停止工作，不会自动进行对等，并且最终将死站点一个小时，并且必须真正推动手动建立数据中心 删除对等体。 + 2. 他们被转租给了一家提供商，后者将他们踢出局，这意味着他们不得不在很少的交货时间内移动两个机架的服务器。 + 3. Internap 以其良好的网络而闻名，它是一种更好的工具，并且更可靠。 + 3. 一个主要目标是在其体系结构中具有**完全冗余**。 将 RTMP 服务器，专用错误记录系统的数量加倍，将监视服务器的数量加倍，将 PHP 和 Rails 服务器分开，添加专用图像缩放服务器，并将编码服务器的数量加倍。 + 4. 另一个主要目标是**完全自动化**。 他们将通过网络对计算机进行启动，以获取操作系统，并从 CVS 配置软件包。 目前，他们的系统不可复制，他们想对此进行更改。 + 5. 试用 HDFS 作为视频的文件存储。 他们将其视频的 10％（约 20TB）存储在 3 个 HDFS 节点上，而且从未停机。 + 6. 当前的目标是使一切移交，整个系统要自动构建，并且在版本控制中，确保雇用了操作人员并制定了时间表。 + 7. 观察到他们与亚马逊的业务相似，因为在视频世界中自己完成所有工作要便宜得多，但随后您必须自己完成所有事情。 + 8. 没有计划使用服务体系结构。 它们具有内部 API 和外部 API。 两者都用于创建站点。 与转换为服务方法相比，要实现更高的奖励功能。 +3. 自动化将改变一切。 + 1. 便携式 VM 将允许他们重现构建环境和实时环境。 目前这些是不可复制的。 每个人都使用不同版本的软件包在自己的操作系统上进行开发。 + 2. 将允许他们在体系结构上进行迭代。 只需下载要运行的新 VM，即可尝试新的存储等。 + 3. 简化向 OpenStack 的过渡。 同时考虑 VMware。 +4. 当您上载到 Viddler 时，端点位于运行 Tomcat 的节点上的 Amazon EC2 上。 + 1. 该文件在本地缓存并发送到 S3。 + 2. 该文件从 S3 下拉以进行编码。 + 3. 编码过程在称为 Viddler Core 的模块中拥有自己的队列。 + 4. 他们将在 colo 站点中运行的代码与在 Amazon 中运行的代码分开。 在 Amazon 中运行的代码不会保持状态。 生成的节点可能会死亡，因为所有状态都保留在 S3 或 Viddler Core 中。 + 5. Python 编码守护程序使工作脱离队列： + 1. 运行 FFmpeg，MEncoder 和其他编码器。 + 2. 关于检查 iPhone 视频是否需要在编码和其他测试之前进行旋转，有很多时髦的东西。 + 3. 每个编码节点都在 Amazon 8 核心实例上运行。 一次运行四种编码。 他们还没有尝试优化它。 + 4. 作业按优先级顺序运行。 有人要立即查看的实时上传内容将在批量处理（例如说在其编码中添加 iPhone 支持）之前得到处理。 + 5. Python 守护程序是运行时间很长的守护程序，它们没有看到任何有关内存碎片的问题或其他问题。 +5. 探索实时转码。 + 1. 在实时编码中，节点实例像多部分表单一样被馈送，通过 FFmpeg 进行流传输，然后再次进行流传输。 这可能是其 CDN 的一部分。 + 2. 这种体系结构的最大优点是无需等待。 客户上传视频后，该视频即会直播。 + 3. 这意味着仅需要存储文件的一种视频格式。 它可以按需转码到 CDN。 这样可以为客户节省大量的存储成本。 +6. 储存费用： + 1. CDN 和存储是他们最大的成本。 存储大约占其成本的 30％。 + 2. 希望他们的视频在所有内容上播放的人的平均情况是四种格式。 HTTP 流将是另一种格式。 因此，存储成本是客户的主要支出。 +7. 团队设置： + 1. 本地程序员在 PHP / Rails 中进行前端操作。 他们正在尝试将所有前端移至该堆栈，尽管其中一些当前在 Java 中。 + 2. 核心 Tomcat / Java / Spring / Hibernate 由波兰的一个团队编写。 Java 团队的目标是实现 API 和后端逻辑。 + 3. 为 PHP / Rails 团队计划有一个单独的数据库，因为它们的移动速度比 Java 团队快得多，并且他们希望尽可能地使团队脱钩，以使其彼此不依赖。 +8. 进行可靠性调查，发现大多数故障是由于： + 1. 网络连接问题。 他们正在迁移到新的数据中心来解决此问题。 + 2. 数据库过载。 要解决此问题： + 1. 该数据库包含约 100 个表。 用户表大约有 100 个参数，其中包括诸如编码首选项之类的信息。 从在 Word Perfect 上托管站点以来，该架构仍然具有旧结构。 + 2. 三倍的数据库容量。 + 3. 使用速度更快且具有更多内存的服务器。 + 4. 使用双主设备设置和 4 个读取从设备。 + 5. 两个读取从站将具有较低的交互式通信查询超时。 + 6. 两个从属将专用于报告，并且查询超时时间较长。 慢速报告查询不会使这种方法使网站瘫痪。 他们的热门查询正在处理具有 1000 万行的表，因此计算热门视频所需的时间比以前要长得多，因为它开始创建临时表。 可能导致系统停机 5 秒钟。 +9. 他们正在研究在自己的 colos 中使用 Squid 运行自己的 CDN。 + 1. 也许使用西海岸和东海岸的科鲁斯在地理上分布同伴。 + 2. 对于他们的客户，他们预计他们在美国需要 4 个站点，在欧洲需要 1 个站点。 + 3. EdgeCast 为他们提供了很多优惠，并为他们提供了有用的功能，例如每个 CNAME 的统计数据，但以盈利为基础，构建自己的 CDN 值得开发。 CDN 成本是其成本结构的重要组成部分，随着时间的流逝，值得一试。 +10. **未来的**：长期目标是看退出 Amazon，在本地运行存储，运行 OpenStack 并运行自己的 CDN 可以节省多少钱。 这将节省 80％的与人无关的运营支出。 根据他们自己的计算，他们可以做到比亚马逊便宜。 + +## 得到教训 + +1. **混搭**。 他们正在使用来自不同提供商的节点的组合。 CDN 处理内容。 Amazon 用于无状态操作，例如编码和存储。 colo 中的节点用于其他所有内容。 在几个不同的位置使用功能可能会有些混乱，但是除非有令人信服的业务原因或易用性更改的原因，否则它们会坚持可行的方法。 将所有东西转移到亚马逊也许是有道理的，但是这也会使他们脱离他们的优先事项，这会带来风险，并且会花费更多。 +2. **注意表增长**。 一旦站点变大，过去需要花费相当长的时间的查询便会突然使其崩溃。 使用报告实例可以从交互式流量中分担报告流量。 而且不要写令人讨厌的查询。 +3. **查看成本**。 平衡成本是他们决策过程的重要组成部分。 他们更喜欢通过新功能实现增长，而不是整合现有功能。 这是一项艰难的平衡行为，但是有意识地将其作为一项战略要务可以帮助每个人都知道自己的发展方向。 从长远来看，他们正在考虑如何在利用自己的 colo 较低成本结构的同时获得云运营模型的好处。 +4. **实验**。 Viddler 喜欢实验。 他们将尝试不同的技术以查看有效的方法，然后在生产中实际使用它们。 这使他们有机会了解新技术是否可以帮助他们降低成本并提供新的客户功能。 +5. **按技术堆栈细分团队，并发布灵活性**。 拥有分散的团队可能是一个问题。 在不同的技术堆栈和根本不同的发布周期上部署分布式团队是一个大问题。 拥有具有强大依赖性和跨职能职责的分布式团队是一个巨大的问题。 如果您必须处于这种情况下，那么迁移到组之间具有较少依赖关系的模型是一个很好的折衷方案。 +6. **从中断中学习**。 对您的网站为何崩溃进行调查，并查看可以解决的主要问题。 似乎很明显，但是还不够。 +7. **将免费用户用作豚鼠**。 免费用户对 SLA 的期望较低，因此他们是新基础设施实验的候选人。 拥有免费套餐对于此目的非常有用，可以在不造成重大损害的情况下试用新功能。 +8. **为顶级托管**支付更多费用。 他们遇到的最大问题是选择好的数据中心。 他们的第一个和第二个数据中心有问题。 作为一家蓬勃发展的创业公司，他们寻找可以找到的最便宜但质量最高的数据中心。 事实证明，数据中心质量很难判断。 他们选择了一家名牌设施，并获得了高昂的价格。 这工作了好几个月，然后开始出现问题。 停电，网络中断，他们最终被迫转移到另一家提供商，因为与他们在一起的一家提供商退出了该设施。 如今，任何时间都无法宕机是不可接受的，对于这样一个小组，冗余站点将是很多努力。 从长远来看，为更高质量的数据中心支付更多费用将降低成本。 +9. **最终重要的是用户看到的内容，而不是体系结构**。 迭代并着重于客户体验之上。 客户服务的价值甚至超过理智或可维护的体系结构。 只构建所需的内容。 如果不运行超级草率的业务，他们就无法启动这家维持 100％员工所有权的公司。 他们现在采用的是在草率阶段学到的知识，并在顶级设施中构建非常灵活的多站点架构。 他们的系统并不是最有效或最漂亮的系统，他们采取的方式是客户需要某种东西，因此他们构建了它。 他们追求客户的需求。 他们选择硬件和构建软件（重点是完成工作）的方式就是建立公司的基础。 +10. **自动化**。 尽管所有试验和解决客户问题的直接方法都很好，但是您仍然需要一个自动化的环境，以便可以复制构建，测试软件并提供一致且稳定的开发环境。 从一开始就自动化。 + +我真的很感谢 Todd Troxell 花时间参加这次采访。 + +记住孩子们，如果您正在寻找工作，Viddler 也在为您寻找[。](http://www.indeed.com/q-Viddler-jobs.html) + +## 相关文章 + +1. [我们可以处理您的交通！](http://blog.viddler.com/cdevroe/traffic/) ，作者 Colin Devroe + +很高兴阅读... +我很想了解您不转用云服务的原因，因为从今天起您需要管理和开发许多不同的技术... 大量的金钱和精力？ \ No newline at end of file diff --git a/docs/65.md b/docs/65.md index 8a2cf39..2626912 100644 --- a/docs/65.md +++ b/docs/65.md @@ -1,39 +1,45 @@ -# 十年 IT 失败的五个教训 +# Facebook：用于扩展数十亿条消息的示例规范架构 -> 原文： [http://highscalability.com/blog/2015/10/28/five-lessons-from-ten-years-of-it-failures.html](http://highscalability.com/blog/2015/10/28/five-lessons-from-ten-years-of-it-failures.html) +> 原文： [http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html](http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html) -![](img/7b85a3888743dc1d181d12abf9d70811.png) +![](img/05b2f60819d28aa5d0e59ecb0a2b699e.png) -IEEE 频谱上有一篇很棒的文章系列，介绍了数十年来 IT 失败带来的[。 这不是您的典型系列，因为有非常酷的交互式图形和图表，这些图形和图表基于从过去的项目失败中收集的数据得出。 它们真的很有趣，我只能想象将它们组合在一起需要花费多少工作。](http://spectrum.ieee.org/static/lessons-from-a-decade-of-it-failures) +可扩展，实时，高可用性服务的体系结构应该是什么样？ 可供开发人员使用的选项太多，但是如果您要寻找通用模板，则该架构由[后端团队的 Facebook](https://www.facebook.com/notes/facebook-engineering/scaling-the-messages-application-back-end/10150148835363920#) [消息](/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html)后端小组负责人 Prashant Malik 描述。 应用后端是一个很好的示例。 -该系列的 [总收入](http://spectrum.ieee.org/riskfactor/computing/it/the-making-of-lessons-from-a-decade-of-it-failures) 为： +尽管 Messages 的任务是每月处理来自电子邮件，IM，SMS，文本消息和 Facebook 消息的 135 亿多条消息，但您可能会认为这是 BigArchitecture 的示例，不适用于较小的站点。 不是这样 这是一个很好的，经过深思熟虑的非云架构示例，展现了任何妈妈都会为之骄傲的许多品质： -> 即使数据有限，我们从中吸取的教训也表明，IT 项目失败和运营问题的发生频率越来越高，后果也越来越大。 这并不奇怪，因为各种形式的 IT 现在已经渗透到全球社会的各个方面。 很容易忘记，Facebook 于 2004 年推出，YouTube 于 2005 年推出，Apple 的 iPhone 于 2007 年推出，或者自 2005 年以来已经发布了三个新版本的 MicrosoftWindows。IT 系统肯定变得越来越复杂和庞大（就捕获的数据而言） ，存储和操作），这不仅意味着它们的开发难度和成本增加，而且维护起来也更加困难。 +1. **分层**-组件独立且隔离。 +2. **服务/ API 驱动的**-每个层都通过定义明确的接口连接，该接口是访问该服务的唯一入口点。 这样可以避免令人讨厌的复杂相互依赖关系。 客户端隐藏在应用程序 API 的后面。 应用程序使用数据访问层。 +3. **分布式**-层透明地分布在计算机集群之间 +4. **单独的应用程序逻辑**-应用程序逻辑封装在提供 API 端点的应用程序服务器中。 应用程序逻辑是根据其他服务实现的。 应用服务器层还隐藏了直写式高速缓存，因为这是写入或检索用户数据的唯一位置，它是高速缓存的理想之地。 +5. **无状态**-状态保存在数据库层，缓存层或其他服务中，而不保存在应用程序中或塞在本地口袋中。 +6. **可伸缩组件服务**-其他本身可伸缩且高度可用的服务用于实现此服务。 消息还使用：Memcache，用户索引服务和 [HayStack](http://haystacksearch.org/) 。 +7. **完整堆栈操作**-开发了工具来管理，监视，识别性能问题并在整个堆栈中上下扩展整个服务。 +8. **蜂窝**-消息具有称为**单元**的机器和服务群集作为其系统的基本构建块。 如果需要更多的机长，则以递增方式添加单元。 一个单元由 [ZooKeeper 控制器](/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html)，应用服务器集群和[元数据存储](https://www.facebook.com/note.php?note_id=454991608919)组成。 单元提供隔离，因为处理请求的存储和应用程序功能独立于其他单元。 单元可能会发生故障，升级并在与其他单元无关的数据中心之间分布。 -以下是具体课程： +质量 1-7 是众所周知的，并且相当广泛地得到认可并以某种形式或另一种形式部署。 *单元*的想法没有得到广泛应用，因为它使抽象级别提高到 *11* 。 -1. [错误地破坏了 IT 系统的巨大作用](http://spectrum.ieee.org/static/the-staggering-impact-of-it-systems-gone-wrong) 。 这里有些可怕的数字，正如文章所指出的那样，这只是冰山一角。 +Salesforce 具有类似的概念，称为[窗格](http://www.salesforce.com/dreamforce/DF09/pdfs/BKSP005_Moldt.pdf) *。* 对于 Salesforce，每个 Pod 包含 50 个节点，Oracle RAC 服务器和 Java 应用程序服务器。 每个吊舱支持成千上万的客户。 我们已经看到其他产品以类似的方式捆绑碎片。 分片将由数据库集群和存储组成，该存储将主从配置或主主配置隐藏到高度可用且可伸缩的单元中。 [Flickr](http://highscalability.com/flickr-architecture) 是此策略的早期且出色的示例。 - * 主题：IT 系统的现代化既困难又昂贵； 将病历数字化既困难又昂贵； 银行依靠不可靠的技术； 即使是短暂的股票交易故障也很昂贵； 即使是短暂的空中故障也很昂贵。 +本文真正有趣的一点是如何处理单元中的群集管理以及如何处理作为一个单元的单元管理。 那是很难正确的部分。 - * 失败是从几个方面衡量的：金钱，受影响的人，浪费的时间。 例如：2000 亿美元的美国陆军未来战斗系统计划终止； 国防部取消可互操作的电子病历系统项目（13 亿美元）； 新伦敦希思罗机场 T5 行李系统崩溃（3200 万美元，10 天，140,000 人）。 +在机器集群中，节点以及因此这些节点上的服务可以随时闪烁并消失。 配置可以随时更改也可以更改吗？ 如何使单元中的所有系统保持协调？ ZooKeeper。 ZooKeeper 用于高可用性，分片，故障转移和服务发现。 易碎机器集群的所有基本功能。 在单元应用程序服务器中，服务器形成一致的哈希环，并且用户在这些服务器之间分片。 -2. [过于复杂，交付不足](http://spectrum.ieee.org/static/overcomplexifying-underdelivering) 。 用一个系统替换多个系统似乎注定要失败。 在提供预期功能的一小部分的同时，几乎都超过了其最初的预算估算。 +跨单元操作如何处理？ 消息具有*发现服务*，它是一种用户 DNS，它位于单元上方，并维护用户到单元的映射。 如果要访问用户数据，则必须先使用该服务找到正确的单元格。 在该单元中，*分布式逻辑客户端*充当发现服务的接口并处理 ZooKeeper 通知。 -3. [失败项目的生命周期](http://spectrum.ieee.org/static/the-life-cycles-of-failed-projects) 。 据我们了解，更多的金钱和更多的时间无法防止项目灾难。 随着时间的流逝，失败变得越来越大，越来越无望。 +[文章](https://www.facebook.com/notes/facebook-engineering/scaling-the-messages-application-back-end/10150148835363920#)写得很好，并且有很多细节。 非常值得一读，特别是如果您试图弄清楚如何构建自己的服务时。 -4. [IT 失败指责游戏](http://spectrum.ieee.org/static/the-it-failure-blame-game) 。 故障报告往往将责任归咎于无法捍卫自己或被解雇的无生命技术。 例如：空中客车（Airbus）责备空中客车 A380 两年延迟的设计软件不兼容 +## 相关文章 [ -5. 失败的纪念碑-即将推出 +* [Facebook 的新实时消息系统：HBase 每月存储 135 亿条消息](/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html) +* [ZooKeeper-可靠，可扩展的分布式协调系统](/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html) +* [Facebook 关于高可伸缩性的文章](http://highscalability.com/blog/category/facebook) +* [Force.com 基础架构内的外观](http://www.salesforce.com/dreamforce/DF09/pdfs/BKSP005_Moldt.pdf) -这是一个系列，您可以花时间去逛逛。 IT 部门虽然经历了许多重大失败，但感觉上却像是陷入了其他人的苦难之中，但是无论如何都要尝试并从中获得乐趣。 我们只是人类。 +您遇到了错误的干草堆：http://planet.admon.org/haystack-new-storage-solution-for-billions-of-photos/ -## 相关文章 +谢谢埃利奥特。 我不确定这是怎么回事，可以肯定我只是复制了他们的网址。 无论如何，现在应该修复它。 -* [“数十年的 IT 失败经验教训”](http://spectrum.ieee.org/riskfactor/computing/it/the-making-of-lessons-from-a-decade-of-it-failures) +我认为 Facebook 意味着另一个干草堆 http://www.facebook.com/note.php?note_id=76191543919。 阅读有关 Facebook Messages 存储基础架构的文章，网址为 http://www.facebook.com/note.php?note_id=454991608919，其中包含正确的 URL。 -* [为什么软件失败](http://spectrum.ieee.org/computing/software/why-software-fails) （2005） - -* [除虫剂](http://spectrum.ieee.org/computing/software/the-exterminators) -一家小型英国公司表明，软件漏洞并非不可避免 - -* [危险因素](http://spectrum.ieee.org/blog/riskfactor) 博客 \ No newline at end of file +我们的意思是：状态保存在数据库层，缓存层或其他服务中，而不是在应用程序中或塞在本地口袋中。 \ No newline at end of file diff --git a/docs/66.md b/docs/66.md index 0c9de15..7847cf9 100644 --- a/docs/66.md +++ b/docs/66.md @@ -1,217 +1,50 @@ -# 细分：使用 Docker，ECS 和 Terraform 重建基础架构 +# Evernote Architecture-每天有 900 万用户和 1.5 亿个请求 -> 原文： [http://highscalability.com/blog/2015/10/19/segment-rebuilding-our-infrastructure-with-docker-ecs-and-te.html](http://highscalability.com/blog/2015/10/19/segment-rebuilding-our-infrastructure-with-docker-ecs-and-te.html) +> 原文： [http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150-million-reques.html](http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150-million-reques.html) -![](img/a939f3fd03c443a26b496a50125abdea.png) +![](img/2b7cd4ef58b70bf0a20de70c8654141f.png) -*这是[段](https://www.linkedin.com/in/calvinfo)的 CTO /联合创始人 [Calvin French-Owen](https://www.linkedin.com/in/calvinfo) 的来宾[重新发布](https://segment.com/blog/rebuilding-our-infrastructure/)。* +[Evernote](http://evernote.com/) 的人们很友好，可以在标题为 [Architectural Digest](http://blog.evernote.com/tech/2011/05/17/architectural-digest/#) 的帖子中写出他们的体系结构概述。 Dave Engberg 描述了他们的网络，分片，用户存储，搜索和其他自定义服务的方法。 -在 Segment 成立之初，我们的基础设施遭到了相当大的破坏。 我们通过 AWS UI 设置了实例，拥有未使用的 AMI 的墓地，并且通过三种不同的方式实现了配置。 +Evernote 是一个很棒的应用程序，部分实现了 [Vannevar Bush](http://en.wikipedia.org/wiki/Vannevar_Bush) 对 [memex](http://en.wikipedia.org/wiki/Memex) 的惊人[视觉](http://commons.nwc.hccs.edu/dylla/2011/02/08/6/)。 维基百科简要地描述了 Evernote 的功能： -随着业务开始腾飞，我们扩大了 eng 团队的规模和体系结构的复杂性。 但是，只有少数知道神秘奥秘的人才能从事生产工作。 我们一直在逐步改进流程，但是我们需要对基础架构进行更深入的检查，以保持快速发展。 +> Evernote 是一套用于记录和存档的软件和服务。 “注释”可以是一段可格式化的文本，完整的网页或网页摘录，照片，语音备忘录或手写的“墨水”注释。 注释也可以具有文件附件。 然后可以将注释分类到文件夹中，进行标记，添加注释，进行编辑，给定注释并进行搜索。 Evernote 支持多种操作系统平台（包括 Android，Mac OS X，iOS，Microsoft Windows 和 WebOS），并且还提供在线同步和备份服务。 -所以几个月前，我们坐下来问自己：*“如果今天设计基础架构设置会是什么样？”* +这里的关键是 Evernote 存储了大量数据，这些数据必须进行搜索，并通过它们的云同步到您使用的任何设备。 -在 10 周的过程中，我们完全重新设计了基础架构。 我们几乎淘汰了每个实例和旧配置，将服务移至可在 Docker 容器中运行，并切换到使用新的 AWS 账户。 +另一个关键是 Evernote 的业务模式和成本结构的影响。 Evernote 以其首席执行官的想法为基础，以[免费增值模式](http://www.fastcompany.com/magazine/147/next-tech-remember-the-money.html)的开创而著称：*获得 100 万人付款的最简单方法是让 10 亿人使用。* Evernote 旨在以 1％的转化率实现盈利。 免费的在线服务将用户限制为每月 60 MB，而高级用户每年需支付 45 美元才能使用 1000 MB /月。 为了盈利，他们大多数会存储大量数据而无需花费大量金钱。 没有太多的额外空间，这说明了其架构的简单实用性。 -我们花了很多时间思考如何制作可审核，简单易用的生产设置，同时仍具有扩展和增长的灵活性。 +这篇文章简短明了，因此一定要详细阅读。 一些要点： -这是我们的解决方案。 +* **控制成本**。 Evernote 在加利福尼亚州圣塔克拉拉的数据中心用完了一对专用机架。 使用云将无法以足够便宜的成本提供足够的处理能力和存储，从而无法使 Evernote 的业务模型正常工作。 由于他们的负载似乎并不尖锐，因此使用他们自己的 colo 站点非常有意义，尤其是考虑到他们如何利用 VM 来提高可靠性。 +* **基于数据**的性质的体系结构。 用户注释彼此独立，这对于 Evernote 在 90 个分片中将其 950 万总用户分片非常实用。 每个分片都是一对两个四核 Intel SuperMicro 盒，它们具有大量 RAM 和采用镜像 RAID 配置的 Seagate Enterprise Drive *完整机箱。 所有存储和 API 处理均由分片处理。 他们发现使用直接连接的存储具有最佳的性价比。 使用具有相同冗余级别的远程存储层将花费更多的成本。 将驱动器添加到服务器并使用 DRDB 复制的开销和成本都很低。* +* **应用冗余**。 每个盒子运行两个虚拟机。 主 VM 运行核心堆栈：Debian + Java 6 + Tomcat + Hibernate + Ehcache +条纹+ GWT + MySQL（用于元数据）+分层本地文件系统（用于文件数据）。 DRDB 用于将主 VM 复制到另一个设备上的辅助 VM。 心跳信号用于故障转移到辅助虚拟机，因为主要虚拟机已死。 一种聪明的方式来使用这些功能强大的机器，并使用更少的资源来构建可靠的系统。 +* **数据可靠性**。 用户数据存储在两个不同物理服务器上的四个不同企业驱动器上。 每晚备份通过专用的 1Gbps 链路将数据复制到辅助数据中心。 +* **快速请求路由**。 用户帐户信息（用户名，MD5 密码和用户分片 ID）存储在内存中的 MySQL 数据库中。 可靠性来自 RAID 镜像，到辅助磁盘的 DRBD 复制以及每夜备份。 这种方法使用户向其数据的路由成为一种简单而快速的内存中查找，同时仍然具有很高的可用性。 +* 一个由 28 个 8 核服务器组成的单独池处理图像以进行搜索，手写识别和其他服务。 这是自定义软件，是功能强大的附加值，其他任何人都无法轻易复制。 +* Puppet 用于配置管理。 +* 使用 Zabbix，Opsview 和 AlertSite 进行监视。 -## 单独的 AWS 账户 +未来的文章有望将重点放在单个子系统上。 我很期待这些，因为您必须欣赏他们为其业务模型创建的系统的优雅性。 一个值得学习的好例子。 -我们没有使用区域或标签来分隔不同的暂存和生产实例，而是切换了完全独立的 AWS 帐户。 我们需要确保我们的配置脚本不会影响我们当前正在运行的服务，并且使用新帐户意味着我们一开始就有空白。 +## 相关文章 [ -![](img/d37692b17ac45e21941737ab00489b4b.png) +* [与 Phil Libin 讨论 EverNote 的新 memex](http://blog.jonudell.net/2008/04/07/a-conversation-with-phil-libin-about-evernotes-new-memex/) ，作者：乔恩·乌德尔（Jon Udell） +* [笔记软件](http://en.wikipedia.org/wiki/Comparison_of_notetaking_software)的比较 +* [Evernote 宣布 Dan Dan 的“闪亮的新 Evernote 网站”](http://www.geardiary.com/2011/03/29/evernote-announces-shiny-new-evernote-web/) -`ops`帐户用作跳转点和集中登录。 组织中的每个人都可以拥有一个 IAM 帐户。 +嗨，托德-感谢您的客气话。 在阅读您的帖子时，我进行了一些小的更正： +-我们的总注册用户略超过 950 万……100k 只是我们在每个分片上输入的数字。 （每月活跃用户超过 3M） +-您错过了以我的名字写的'g'...这可能意味着您是体育迷，因为那个 Dick Enberg 家伙总是把它拼错。 :-) -其他环境具有一组 IAM 角色，可以在它们之间进行切换。 这意味着我们的管理员帐户只有一个登录点，并且只有一个位置可以限制访问。 +无需发布此评论，我只是认为我会通过。 +谢谢， +戴夫 -例如，爱丽丝可能可以访问所有三个环境，但是鲍勃只能访问开发人员（因为他删除了生产负载平衡器）。 但是它们都通过`ops`帐户输入。 +感谢您所做的更正 Dave。 对那个家伙没有太大的爱，我只是很难打字:-) -无需复杂的 IAM 设置来限制访问，我们可以轻松地按环境锁定用户并按*角色将其分组。* 通过界面使用每个帐户就像切换当前活动角色一样简单。 +感谢您的精彩文章！ -![](img/46f7e4c58e8e48711e936e7ff2073cca.png) +只是一个澄清问题； 您写道：“数据可靠性。用户数据存储在两个不同物理服务器上的四个不同企业驱动器上”。 -不必担心暂存盒可能不安全或会更改生产数据库，我们免费获得*真正隔离*。 无需额外配置。 - -能够共享配置代码的另一个好处是，我们的登台环境实际上可以反映产品。 配置上的唯一区别是实例的大小和容器的数量。 - -最后，我们还启用了各个帐户的合并结算。 我们使用相同的发票支付每月帐单，并查看按环境划分的费用的详细分类。 - -## Docker 和 ECS - -设置好帐户后，就可以设计服务的实际运行方式了。 为此，我们转向了 [Docker](https://docker.com/) 和 [EC2 容器服务（ECS）](https://aws.amazon.com/ecs/)。 - -截至今天，我们现在在 Docker 容器中运行我们的大多数服务，包括我们的 API 和数据管道。 容器每秒接收数千个请求，每月处理 500 亿个事件。 - -Docker 最大的单一好处是在一定程度上使团队能够从头开始构建服务。 我们不再需要复杂的配置脚本或 AMI，只需将生产集群交给一个映像即可运行。 不再有状态的实例，我们保证在 staging 和 prod 上运行相同的代码。 - -在将我们的服务配置为在容器中运行之后，我们选择了 ECS 作为调度程序。 - -总体而言，ECS 负责在生产中实际运行我们的容器。 它负责调度服务，将它们放置在单独的主机上，并在连接到 ELB 时重新加载零停机时间。 它甚至可以跨可用区进行调度，以提高可用性。 如果某个容器死亡，ECS 将确保将其重新安排在该群集中的新实例上。 - -切换到 ECS 大大简化了服务的运行，而无需担心新贵作业或预配实例。 就像添加一个 [Dockerfile](https://gist.github.com/calvinfo/c9ffb5c28133be525c62) ，设置任务定义并将其与集群关联一样简单。 - -在我们的设置中，Docker 映像是由 CI 构建的，然后被推送到 Docker Hub。 服务启动时，它将从 Docker Hub 中拉出映像，然后 ECS 在机器之间调度它。 - -![](img/839239df2e64e292508c30592e7895f1.png) - -我们会根据服务集群的关注程度和负载情况对其进行分组（例如，针对 API，CDN，App 等的不同集群）。 具有单独的群集意味着我们可以获得更好的可见性，并且可以决定为每个实例使用不同的实例类型（因为 ECS 没有实例相似性的概念）。 - -每个服务都有一个特定的任务定义，该任务定义指示要运行哪个版本的容器，要运行多少个实例以及要选择哪个集群。 - -在运行期间，服务向 ELB 进行自身注册，并使用运行状况检查来确认容器实际上已准备就绪。 我们在 ELB 上指向本地 Route53 条目，以便服务可以相互通信，并仅通过 DNS 进行引用。 - -![](img/fecec45b30faa825726feb884c929eac.png) - -设置很好，因为我们不需要任何服务发现。 本地 DNS 为我们完成所有簿记工作。 - -ECS 运行所有服务，我们从 ELB 获得免费的 cloudwatch 指标。 这比在启动时向中央机构注册服务要简单得多。 最好的部分是我们不必自己处理国家冲突。 - -## 使用 Terraform 进行模板化 - -Docker 和 ECS 描述了如何运行我们的每个服务的地方， [Terraform](https://terraform.io/) 是将它们结合在一起的粘合剂。 从高层次上讲，它是一组配置脚本，用于创建和更新我们的基础架构。 您可以将其视为类固醇上的 Cloudformation 版本，但这并不能使您感到惊讶。 - -除了运行一组用于维护状态的服务器外，还有一组描述集群的脚本。 配置在本地运行（并在将来通过 CI 运行）并致力于 git，因此我们可以连续记录生产基础架构的实际状况。 - -这是用于设置堡垒节点的 Terraform 模块的示例。 它创建了所有安全组，实例和 AMI，因此我们能够轻松地为将来的环境设置新的跳转点。 - -``` -// Use the Ubuntu AMI -module "ami" { - source = "github.com/terraform-community-modules/tf_aws_ubuntu_ami/ebs" - region = "us-west-2" - distribution = "trusty" - instance_type = "${var.instance_type}" -} - -// Set up a security group to the bastion -resource "aws_security_group" "bastion" { - name = "bastion" - description = "Allows ssh from the world" - vpc_id = "${var.vpc_id}" - - ingress { - from_port = 22 - to_port = 22 - protocol = "tcp" - cidr_blocks = ["0.0.0.0/0"] - } - - egress { - from_port = 0 - to_port = 0 - protocol = "-1" - cidr_blocks = ["0.0.0.0/0"] - } - - tags { - Name = "bastion" - } -} - -// Add our instance description -resource "aws_instance" "bastion" { - ami = "${module.ami.ami_id}" - source_dest_check = false - instance_type = "${var.instance_type}" - subnet_id = "${var.subnet_id}" - key_name = "${var.key_name}" - security_groups = ["${aws_security_group.bastion.id}"] - tags { - Name = "bastion-01" - Environment = "${var.environment}" - } -} - -// Setup our elastic ip -resource "aws_eip" "bastion" { - instance = "${aws_instance.bastion.id}" - vpc = true -} -``` - -我们在阶段和产品中使用相同的模块来设置我们的个人堡垒。 我们唯一需要切换的是 IAM 密钥，我们已经准备就绪。 - -进行更改也很轻松。 Terraform 不会总是拆除整个基础架构，而会在可能的地方进行更新。 - -当我们想将 ELB 耗尽超时更改为 60 秒时，只需执行简单的查找/替换操作即可，然后是`terraform apply`。 而且，两分钟后，我们对所有 ELB 进行了完全更改的生产设置。 - -它具有可复制性，可审核性和自我记录性。 这里没有黑匣子。 - -我们将所有配置都放在了`infrastructure`中央存储库中，因此很容易发现如何设置给定的服务。 - -不过，我们还没有达到圣杯。 我们希望转换更多的 Terraform 配置以利用模块，以便可以合并单个文件并减少共享样板的数量。 - -一路上，我们在`.tfstate`周围发现了一些陷阱，因为 Terraform 始终首先从现有基础架构中读取数据，并抱怨状态是否不同步。 我们最终只是将我们的`.tfstate`提交给了仓库，并在进行了任何更改之后将其推送了，但是我们正在研究 [Atlas](https://atlas.hashicorp.com/) 或通过 CI 来解决该问题。 - -## 移至 Datadog - -至此，我们有了基础架构，配置和隔离。 最后剩下的是度量和监视，以跟踪生产中正在运行的所有内容。 - -在我们的新环境中，我们已将所有指标和监视切换到 [Datadog](https://datadog.com/) ，这是出色的。 - -![](img/eb5840233aa77c22a5f2c0cf35c56775.png) - -我们一直对 Datadog 的 UI，API 以及与 AWS 的完全集成感到非常满意，但是要充分利用该工具，需要进行一些关键的设置。 - -我们要做的第一件事是与 AWS 和 Cloudtrail 集成。 它提供了 10,000 英尺的视图，可了解我们在每个环境中发生的情况。 由于我们正在与 ECS 集成，因此 Datadog feed 会在每次任务定义更新时进行更新，因此最终会免费获得部署通知。 惊人地搜索提要很容易，并且可以轻松地追溯到上一次部署或重新安排服务的时间。 - -接下来，我们确保将 Datadog-agent 作为容器添加到基本 AMI（ [datadog / docker-dd-agent](https://hub.docker.com/r/datadog/docker-dd-agent/) ）。 它不仅从主机（CPU，内存等）收集指标，而且还充当我们 statsd 指标的接收器。 我们的每项服务都会收集有关查询，延迟和错误的自定义指标，以便我们可以在 Datadog 中进行浏览并发出警报。 我们的 go 工具包（即将开源）将自动在代码行中收集 [`pprof`](https://golang.org/pkg/net/http/pprof/) 的输出并将其发送，因此我们可以监视内存和 goroutine。 - -更酷的是，代理可以可视化环境中主机之间的实例利用率，因此我们可以对可能存在问题的实例或群集进行高层概述： - -![](img/55569b1423b47df7ebf2a3074e0bf80b.png) - -此外，我的队友文斯（Vince）为 Datadog 创建了 [Terraform 提供程序，因此我们可以完全针对*实际生产配置*编写警报脚本。 我们的警报将被记录，并与产品中正在运行的警报保持同步。](https://github.com/segmentio/terraform-datadog) - -``` -resource "datadog_monitor_metric" "app.internal_errors" { - name = "App Internal Errors" - message = "App Internal Error Alerts" - - metric = "app.5xx" - time_aggr = "avg" - time_window = "last_5m" - space_aggr = "avg" - operator = ">" - - warning { - threshold = 10 - notify = "@slack-team-infra" - } - - critical { - threshold = 50 - notify = "@slack-team-infra @pagerduty" - } -} -``` - -按照惯例，我们指定两个警报级别：`warning`和`critical`。 `warning`可以让当前在线的任何人知道某些东西看起来可疑，应在任何潜在问题发生之前就将其触发。 `critical`警报是为严重的系统故障而“半夜醒来”的问题保留的。 - -更重要的是，一旦我们过渡到 Terraform 模块并将 Datadog 提供程序添加到我们的服务描述中，那么所有服务最终都会获得*免费*的警报。 数据将直接由我们的内部工具包和 Cloudwatch 指标提供动力。 - -## 让好时光泊坞窗运行 - -一旦我们将所有这些组件准备就绪，就可以开始进行转换了。 - -我们首先在新的生产环境和旧的生产环境之间建立了 [VPC 对等连接](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html)-允许我们对数据库进行集群并在两者之间进行复制。 - -接下来，我们对新环境中的 ELB 进行了预热，以确保它们可以处理负载。 亚马逊不会提供自动调整大小的 ELB，因此我们不得不要求他们提前对其进行调整（或缓慢调整规模）以应对增加的负载。 - -从那里开始，只需要使用加权的 Route53 路由将流量从旧环境稳定地增加到我们的新环境，并不断监视一切都看起来不错。 - -如今，我们的 API 蓬勃发展，每秒处理数千个请求，并且完全在 Docker 容器内运行。 - -但是我们还没有完成。 我们仍在微调我们的服务创建，并减少样板，以便团队中的任何人都可以通过适当的监视和警报轻松构建服务。 而且，由于服务不再与实例相关联，因此我们希望围绕容器的使用改进工具。 - -我们还计划关注这一领域的有前途的技术。 [Convox](https://convox.com/) 团队正在围绕 AWS 基础架构构建出色的工具。 [Kubernetes](http://kubernetes.io/) ，[中层](https://mesosphere.com/)， [Nomad](https://nomadproject.io/) 和 [Fleet](https://github.com/coreos/fleet) 看起来像是不可思议的调度程序，尽管我们喜欢 ECS 的简单性和集成性。 看到它们如何被淘汰将是令人兴奋的，我们将继续关注它们以了解我们可以采用什么。 - -在所有这些业务流程变更之后，我们比以往任何时候都更加坚信将基础架构外包给 AWS。 他们通过将许多核心服务产品化而改变了游戏规则，同时保持了极具竞争力的价格。 它正在创建一种新型的初创公司，可以高效而廉价地生产产品，同时减少维护时间。 而且我们看好将在其生态系统之上构建的工具。 - -Datadog 链接已断开，它显示 SSL 错误。 正确的网址是 https://www.datadoghq.com/ - -我们是一家初创公司，我们正在尝试从头开始设置 evyrthing。 感谢您的帖子。 \ No newline at end of file +您是否在此表示它们将数据存储在具有两个驱动器的一个 VM 上，然后将数据复制到另一台物理计算机上的具有两个驱动器的另一 VM 上（如下面的“应用程序冗余”所述）？ \ No newline at end of file diff --git a/docs/67.md b/docs/67.md index 5dae4cd..9a95285 100644 --- a/docs/67.md +++ b/docs/67.md @@ -1,395 +1,13 @@ -# 为在现代时代构建可扩展的有状态服务提供依据 +# TripAdvisor 的短 -> 原文： [http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html](http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html) +> 原文： [http://highscalability.com/blog/2011/6/14/a-tripadvisor-short.html](http://highscalability.com/blog/2011/6/14/a-tripadvisor-short.html) -![](img/6e13e9978e8b0a2796ba7310ca6b4db0.png) +有时我会收到文章建议，然后没有后续行动。 尽管这些 TripAdvisor 数据点来自 2010 年，但我认为值得分享： -长期以来， [无状态服务](https://en.wikipedia.org/wiki/Service_statelessness_principle) 一直是可扩展性的皇家之路。 几乎所有关于可伸缩性的论文都将无状态声明为构建可伸缩系统的最佳实践认可方法。 无状态架构易于水平扩展，只需要简单的循环负载平衡即可。 +> 我们的网站每天提供超过 1 亿个动态生成的页面浏览量（所有媒体和静态内容均通过 CDN 进行），并且我们使用约 100 台机器（无单点故障）来完成此任务，并由响应超过 2B 的分布式服务体系结构支持 需要一天的时间，以及一个超过 20TB 的数据仓库，用于推动电子邮件活动，搜索引擎营销和常规报告。 我们是 Linux / Java / Apache / Tomcat / Postgres / Lucene 商店，并且已经建立了自己的分布式计算架构。 我们还维护重复的数据中心（一个活动，一个备用），以实现冗余和维护目的。 -什么是不爱的？ 从往返到数据库的延迟可能增加了。 或者，隐藏数据库延迟问题所需的缓存层的复杂性。 甚至是麻烦的一致性问题。 +Too bad, it sounds like it would have been a good article. -但是有状态服务呢？ 是不是通过将功能传递给数据而不是将数据传递给功能来保留身份，是不是更好的方法？ 通常是这样，但是我们对如何构建有状态服务知之甚少。 实际上，进行搜索后，构建状态服务的系统方法几乎没有。 维基百科甚至没有 *有状态服务* 的条目。 +## 相关文章 [ -[Caitie McCaffrey](https://twitter.com/caitie?lang=en) （Twitter 上的可观察性技术负责人）正在通过 [奇怪循环](http://www.thestrangeloop.com/) 会议，关于 [构建可扩展的有状态服务](https://www.youtube.com/watch?v=H0i_bXKwujQ) （ [幻灯片](https://speakerdeck.com/caitiem20/building-scalable-stateful-services) ）。 - -令人耳目一新，因为我从未听说过以 Caitie 谈论构建有状态服务的方式来构建有状态服务。 您会认识到大多数想法-粘滞会话，数据传送范例，功能传送范例，数据局部性，CAP，集群成员资格，八卦协议，一致性哈希，DHT-但她将它们围绕构建有状态服务的主题进行了编织 以最引人注目的方式 - -对我来说，这次谈话的亮点是，当 Caitie 将整个谈话围绕在讨论她使用 Microsoft 的 [奥尔良](http://dotnet.github.io/orleans) 开发 Halo 4 的经历时 Azure 的。 奥尔良的覆盖面不足。 它基于固有的有状态分布式虚拟 Actor 模型； 集群成员资格使用高度可用的八卦协议； 并使用两层一致性哈希加上分布式哈希表的系统进行工作分配。 使用此方法，当节点发生故障，容量增加/收缩或节点变热时，奥尔良可以重新平衡群集。 结果是 Halo 能够在生产环境中运行有状态的奥尔良群集，整个群集的 CPU 利用率为 90-95％。 - -奥尔良并不是唯一涵盖的示例系统。 还使用 Caitie 的状态架构框架分析了 Facebook 的 Scuba 和 Uber 的 Ringpop。 还有一个非常有趣的部分，介绍 Facebook 如何通过将内存生存期与进程生存期脱钩，为大型内存数据库巧妙地实现快速数据库重启。 - -因此，让我们开始学习如何构建有状态服务... - -## 无状态服务是浪费 - -* 无状态服务运行良好。 通过在需要时添加新的无状态服务实例，将规范的真理源存储在数据库中并进行水平扩展非常有效。 - -* 问题在于我们的应用程序确实具有状态，并且我们达到了一个数据库不再削减的极限。 作为回应，我们将分片关系数据库或使用 NoSQL 数据库。 这会放弃强大的一致性，从而导致部分数据库抽象泄漏到服务中。 - -* **数据传送范例** - - * 客户端发出服务请求。 该服务与数据库对话，并且数据库以一些数据答复。 该服务进行一些计算。 答复将发送到客户端。 然后数据从服务中消失。 - - * 下一个请求将负载平衡到另一台计算机，并且整个过程将再次发生。 - -* **对于涉及在一段时间内在会话中运行的健谈客户端的应用程序，将资源反复提取到负载平衡服务**中非常浪费。 示例：游戏，订购产品，您要更新有关自己的信息的任何应用程序。 - -## 有状态服务更易于编程 - -* 注意：有状态服务不是魔术。 如果需要水平可伸缩性，那么无状态服务仍然非常有效。 但是有状态服务确实提供了很多好处。 - -* **数据位置** 。 将请求发送到保存有操作所需数据的计算机的想法。 优点： - - * **低延迟** 。 不必为每个单独的请求访问数据库。 仅当数据内存不足时才需要访问数据库。 网络访问的数量减少了。 - - * **数据密集型应用程序** 。 如果客户需要处理一堆数据，那么所有数据都将可以访问，因此可以快速返回响应。 - -* **功能传送范例** - - * 客户端发出请求或启动会话，一次访问数据库将获取数据，然后数据移入服务。 - - * 处理请求后，数据留在服务上。 客户端下一次发出请求时，请求将路由到同一台计算机，这样它就可以处理内存中已存在的数据。 - - * 避免了额外的数据库访问，从而减少了延迟。 即使数据库关闭，也可以处理该请求。 - -* 有状态性导致**的使用率更高[​​HTG1] **，并且一致性更高** **模型**。** - - * 在我们有不同级别的一致性的 CAP 世界中，某些级别比其他级别更可用。 当存在分区时，CP 系统选择一致性而不是可用性，而 AP 系统选择可用性而不是一致性。 - - * 如果我们要在 AP 下拥有更多高可用性的系统，我们将获得“读取读取”，“单调读取”，“单调写入”。 （ [用于定义](http://www.cs.rice.edu/~druschel/comp413/lectures/replication.html) ） - - * 如果我们有粘性连接，其中单个用户的数据在单台计算机上，那么您可以拥有更强的一致性保证，例如“读取写入”，“流水线随机存取存储器”。 - - * [Werner Vogel 2007](http://www.allthingsdistributed.com/2007/12/eventually_consistent.html) ：是否可以实现读，写，会话和单调一致性，通常取决于客户端对执行服务器的“粘性” 他们的分布式协议。 如果每次都使用同一台服务器，则保证读取和单调读取相对容易。 这使得管理负载平衡和容错的难度稍大一些，但这是一个简单的解决方案。 使用粘性的会话可以使这一点变得明确，并提供客户可以推理的暴露水平。 - - * **粘性连接使客户可以更轻松地推断** 的模型。 不必担心数据被拉到许多不同的计算机中，也不必担心并发性，您只需要让客户端与同一台服务器通信即可，这更容易考虑，并且在对分布式系统进行编程时会大有帮助。 - -## 建立粘性连接 - -* 客户端向服务器集群发出请求，并且该请求始终路由到同一台计算机。 - -* 最简单的方法是 **打开持久的 HTTP 连接** 或 TCP 连接。 - - * 易于实现，因为连接意味着您始终在与同一台机器通信。 - - * 问题：连接断开后，粘性消失了，下一个请求将被负载平衡到另一台服务器。 - - * 问题：负载平衡。 有一个隐含的假设，即所有粘性会话都将持续大约相同的时间，并产生大约相同的负载。 通常情况并非如此。 如果连接过多的单个服务器，连接持续很长时间或者每个连接都要做很多工作，那么很容易使连接过多的单个服务器不堪重负。 - - * **必须实现背压** **，以便服务器在连接不堪重负时断开连接。 这导致客户端重新连接到希望减轻负担的服务器。 您还可以根据自由分配的资源量进行负载均衡，以更公平地分配工作。** - -* **在集群**中实现路由 **更聪明。 客户端可以与群集中的任何服务器通信，该服务器会将客户端路由到包含正确数据的服务器。 需要两个功能：** - - * **群集成员资格** 。 谁在我的集群中？ 我们如何确定可以与哪些机器通信？ - - * **工作分配** 。 负载如何在整个群集中分配？ - -## 集群成员资格 - -* 群集成员资格系统共有三种常规类型：静态，八卦协议，共识系统。 - -### 静态集群成员资格-最简单的方法 - -* 可以从最笨的事情开始，看看它是否满足您的需求。 - -* 最简单的方法是一个配置文件，其中包含集群中节点的所有地址。 配置文件分发到每台计算机。 - -* 易于执行，但操作起来很痛苦。 - -* 对于必须高度可用的服务不是一个很好的选择。 - -* 它不是容错的。 如果机器出现故障，则必须更换它并更新配置。 - -* 很难扩展集群。 要添加计算机，必须重新启动整个集群，以便可以在整个集群之间正确地重新平衡工作。 - -### 动态集群成员资格 - -* 可以从群集中动态添加或删除节点。 - -* 要增加容量或补偿故障，可以将节点添加到群集并立即开始接受负载。 也可以通过删除节点来减少容量。 - -* 处理集群成员资格的两种主要方法：八卦协议和共识系统。 - -### 八卦协议-强调可用性 - -* 八卦协议通过发送消息在整个小组中传播知识。 - -* 消息中提到了他们可以与谁交谈，谁还活着，谁死了。 每台机器都将自己从数据中找出其收集集群中谁的世界视图。 - -* 在稳定状态下，集群中的所有机器将汇聚在一起，以对谁是活着还是死了的世界具有相同的世界观。 - -* 在网络故障，网络分区或添加或删除容量的情况下，群集中的不同计算机可以对群集的谁拥有不同的世界观。 - -* 需要权衡。 您具有高可用性，因为不需要任何协调，每台机器都可以根据自己的世界观进行决策，但是您的代码必须能够处理在故障期间路由到不同节点的不确定性。 - -### 共识系统-强调一致性 - -* 群集中的所有节点将具有完全相同的世界视图。 - -* 共识系统控制集群中每个人的所有权。 当配置更改时，所有节点都基于拥有真实集群成员资格的共识系统更新其世界观。 - -* 问题：如果无法使用共识系统，则节点将无法路由工作，因为它们不知道集群中的成员。 - -* 问题：由于向系统添加了协调，因此速度会变慢。 - -* 如果您需要高可用性，则除非确实有必要，否则应避免使用共识系统。 - -## 工作分配 - -* 工作分配是指如何在整个集群中移动工作。 - -* 有三种类型的工作分配系统：随机放置，一致哈希，分布式哈希表。 - -### 随机放置 - -* 听起来很傻，但是可以有效。 它适用于在集群中分布着大量数据和查询的情况下处理大量数据的情况。 - -* 写入到具有容量的任何计算机。 - -* 读取操作需要查询集群中的每台计算机，以取回数据。 - -* 这不是固定连接，而是有状态服务。 这是构建内存索引和缓存的好方法。 - -### 一致的哈希-确定性放置 - -* 基于哈希（可能是会话 ID 或用户 ID）的确定性的对节点的放置，具体取决于工作负载的划分方式。 - -* 当节点被映射到集群时，请求也被映射到环，然后您继续向前走以找到将要执行请求的节点。 - -* 由于确定性的位置，像 Cassandra 这样的数据库经常使用这种方法。 - -* 问题：热点。 - - * 许多请求最终可能被散列到同一节点，并且该节点被流量所淹没。 或节点速度可能很慢，也许磁盘坏了，甚至正常数量的请求也淹没了它。 - - * 哈希值不一致，因此无法移动工作以降温热点。 - - * 因此，您必须在群集中分配足够的空间，才能以足够的净空运行，以容忍确定性的放置以及无法移动工作这一事实。 - - * 这种额外的容量是额外的成本，即使在正常情况下也必须承担。 - -### 分布式哈希表（DHT）-非确定性放置 - -* 哈希用于在分布式哈希表中查找，以查找应将工作发送到的位置。 DHT 保留对群集中节点的引用。 - -* 这是不确定的，因为没有任何事情迫使工作去到特定的节点。 重新映射客户端很容易，以便在某个节点不可用或温度过高时将其转到其他节点。 - -## 现实世界中的三个示例状态服务 - -### Facebook 的潜水-写作时随机散布 - -* Scuba 是一个快速可扩展的分布式内存数据库，用于代码回归和分析，错误报告，收入以及性能调试。 （ [更多信息](https://research.facebook.com/publications/456106467831449/scuba-diving-into-data-at-facebook/) ） - -* 它必须非常快并且始终可用。 - -* 想法是它使用静态集群成员身份，尽管本文没有明确说明。 - -* Scuba 在写入时使用随机扇出。 读取时查询每台机器。 所有结果均由运行查询的计算机返回并组成，并将结果返回给用户。 - -* 在现实世界中，机器不可用，因此运行查询时会尽力而为。 如果不是所有节点都可用，则查询将返回可用数据的结果以及有关它们处理的数据百分比的统计信息。 用户可以决定结果是否满足足够高的质量阈值。 - -* 没有使用粘性连接，但数据在内存中，因此查找速度非常快。 - -### Uber 的铃声-八卦协议+一致性哈希 - -* Ringpop 是一个 node.js 库，用于实现应用程序层分片。 （ [更多信息](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) ） - -* Uber 有旅行的概念。 要开始旅行，用户订购一辆需要骑手信息和位置信息的汽车，在整个骑行过程中会更新数据，并且必须在旅行结束时处理付款。 - -* 对于这些更新中的每一个，每次都将负载平衡到不同的无状态服务器将是低效率的。 数据将不断保存到数据库中，然后再次拉回。 这会导致大量延迟和数据库上的额外负载。 - -* 该设计实现了路由逻辑，因此可以将对用户的所有请求定向到单个计算机。 - -* 游泳八卦协议用于维护群集成员身份。 这是 AP 群集成员身份协议，因此不能保证始终正确。 选择可用性而不是正确性是因为用户始终可以订购汽车，这一点更为重要。 - -* 一致性哈希用于在整个群集中路由工作。 这具有热节点问题，并且唯一的补救措施是增加更多的容量，即使没有充分利用其他节点。 - -### 微软的奥尔良-八卦协议+一致的哈希+分布式哈希表 - -* Orleans 是用于基于 Actor 模型构建分布式系统的运行时和编程模型。 （ [更多信息](http://research.microsoft.com/en-us/projects/orleans/) ） - -* 奥尔良来自 Extreme Computing Group 的 Microsoft Research。 演示者（Caitie McCaffrey）与该小组合作，在运送 Halo 4 的过程中使 Orleans 产品化。所有 Halo 4 服务主要在 Orleans 上重建。 - -* Actor 是计算的核心单元。 Actor 使用整个集群中的异步消息相互通信。 当 Actor 收到消息时，它可以执行以下一项或多项操作：发送一条或多则消息，更新其内部状态，创建新的 Actor。 - -* 在基于 Actor 模型的集群中，您有一堆正在运行的状态机，因此，如果 Actor 模型在请求之间保持状态不变，则它们固有地是有状态的。 - -* 在 Halo 4 中，他们将部署一台机器集群，而奥尔良则负责其余的工作。 - -* 请求将发送到群集中的任何计算机。 群集将查找 Actor 在群集中的居住位置，并将消息路由到 Actor。 - -* 成千上万的 Actor 在集群中的单台计算机上运行。 - -* 闲话协议用于集群成员身份，以使其具有较高的可用性。 由于 Orleans 是开源的，因此创建了 Zookeeper 实现，这比较慢。 - -* 对于工作分配，奥尔良使用一致哈希+分布式哈希表的组合。 - - * 将对 Actor 的请求发送到集群时，Orleans 运行时将在 Actor ID 上计算一致的哈希。 哈希映射到具有该 ID 的分布式哈希表的计算机。 - - * Actor 的分布式哈希表知道哪台计算机包含指定 ID 的 Actor。 - - * 在咨询了 DHT 之后，请求被路由到适当的机器。 - -* 一致性哈希用于查找 Actor DHT，因此这是确定性操作。 DHT 在群集中的位置不会更改。 而且，由于 DHT 中的数据量很小并且 Actor DHT 分布均匀，因此热点并不是大问题。 - -* 演员正在做的事情不是均匀分布和平衡的。 - -* 奥尔良能够自动重新平衡群集。 在以下情况下，可以更新 DHT 中的条目以指向新机器： - - * 会话终止。 - - * 机器发生故障，因此必须分配新的机器。 - - * 由于没有人在与演员交谈，因此将其从记忆中逐出。 - - * 机器温度过高，因此奥尔良将 Actor 移到容量更大的另一台机器上，这样热机器就不会发生故障。 - -* Orleans 的重新平衡功能是 Orleans 群集可以在整个群集中以 90-95％的 CPU 利用率在生产中运行的核心原因。 能够以不确定的方式移动工作，这意味着您可以使用盒子的所有容量。 - -* 此方法可能不适用于数据库，但对于将状态引入服务非常有用。 - -## 可能出错的地方 - -### 无限数据结构 - -* 在有状态系统中，无限制的数据结构是消亡的好方法。 示例：无限制的队列，无限制的内存结构。 - -* 在无状态服务中，我们无需经常考虑这一点，因为它们可以从此类短暂故障中恢复。 - -* 在有状态服务中，服务可以获取很多请求，因此必须在数据结构上放置明确的界限，否则它们可能会不断增长。 然后，您可能会用完内存，或者您的垃圾收集器可能会使世界停止运转，并且该节点可能看起来已经死了（我还要补充一点，随着数据结构的增长，锁可以保留很长时间）。 - -* 客户不是您的朋友。 客户不会做您想要他们做的事。 机器可能会死于隐性假设，即我们不会用完内存，否则客户端只会发送合理数量的数据。 代码必须保护自己免受客户侵害。 - -### 内存管理 - -* 因为数据会在会话的整个生命周期内（可能是几分钟，几小时甚至几天）保持在内存中，所以内存将进入寿命最长的垃圾回收。 通常，收集该内存的成本更高，尤其是当存在跨代的引用时。 - -* 您必须更加了解内存在有状态服务中的工作方式，并且实际上需要了解垃圾收集器的运行方式。 - -* 或者，您也可以使用非托管代码（例如 C ++）编写所有内容，因此您不必处理垃圾收集器问题。 - -* 奥尔良运行 [.NET CLR](https://en.wikipedia.org/wiki/Common_Language_Runtime) ，这是一个垃圾收集环境，确实遇到了跨代垃圾收集问题。 - - * 通过调整垃圾收集器来处理。 - - * 这也通过实现许多不必要状态的持久化来处理。 您必须对所保留的内容保持谨慎，因为存在相关的成本。 - -### 重载状态 - -* 通常，在无状态服务中，必须为每个请求查询数据库，因此必须调整等待时间以解决与数据库的往返行程。 或者，您可以使用缓存来使其更快。 - -* 在有状态服务中，可以重新加载状态的时间有很多不同：第一次连接，从崩溃中恢复，部署新代码。 - -#### 首次连接 - -* 通常，这是最昂贵的连接，因为该节点上没有数据。 必须将所有数据拉入数据库，以便可以处理请求。 - -* 这可能需要很长时间，因此您要非常小心启动时加载的内容。 您不希望遇到恰好落在第一个连接上的请求带来高延迟。 - -* 在测试中使用 [百分位数](http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html) 。 平均延迟看起来不错，因为您不必每次都往返于数据库。 第一次连接延迟可能会增加，您不想错过。 - -* 在第一个连接上，如果客户端由于对数据库的访问速度较慢而超时，则您将继续尝试从数据库加载，因为您知道客户端将重试。 客户端的下一次访问将很快，因为数据很可能在内存中。 在无状态服务中，您无法进行这种优化。 - -* 例如，在 Halo 中，当游戏开始时，第一个连接有时会超时。 也许用户有很多游戏状态或连接已加载。 因此，他们会继续输入数据，并且在游戏箱重试时请求会成功。 用户不会注意到延迟，特别是考虑到用户正在观看的漂亮动画。 - -#### 从崩溃中恢复 - -* 如果必须从崩溃中恢复后为整个盒子补水，如果您没有懒惰地加载所有 Actor，这可能会很昂贵。 有时您可以摆脱延迟加载，有时则无法。 - -#### 部署新代码 - -* 要部署新代码，您必须拆卸整个包装箱，然后将其重新备份到另一个包装箱中。 如果您没有不确定的展示位置或动态集群成员身份，可能会出现问题。 - -#### [快速数据库从 Facebook 重新启动](https://research.facebook.com/publications/553456231437505/fast-database-restarts-at-facebook/) - -* Facebook 的 Scuba 产品出现重新启动问题，因为它是一个内存数据库，其中存储了许多保留在硬盘上的数据。 - -* 在崩溃或部署中，他们将关闭当前正在运行的计算机，启动新计算机，然后从磁盘读取所有内容。 每台机器要花几个小时。 而且由于他们的 SLA，Facebook 必须对其集群进行缓慢的滚动更新，这最多需要 12 个小时。 - -* 崩溃不会经常发生，因此缓慢的重启并不是一个大问题。 我们希望代码部署经常发生，以便我们可以更快地迭代，尝试新想法，降低风险部署。 - -* Facebook 做出了一个关键的观察，即您可以 **将内存寿命与进程寿命** 分开，尤其是在有状态服务中。 - -* 当 Facebook 想部署新代码，并且知道这是安全的关闭并且内存没有损坏时，他们将：停止接收请求，将数据从当前运行的进程复制到共享内存，关闭旧进程，引入 启动新进程，然后将共享内存中的数据复制回进程内存空间，然后重新启动请求。 - -* 此过程需要几分钟，因此群集重新启动的时间现在是 2 小时而不是 12 小时。 现在，可以比以前更频繁地部署新代码。 - -* Twitter 正在考虑为有状态索引实施此策略，当整个计算机重新启动时，它必须与他们的 Manhattan 数据库通信，这与内存相比确实很慢。 - -## 总结 - -* 集群成员资格和工作分配中有很多工作和思想。 - - * 没有正确的答案。 - - * 她偏向可用一侧，因此更喜欢八卦协议。 - - * 对于工作分配，取决于工作量。 - -* 在现实世界中运行着许多成功的有状态系统。 事实证明，您可以大规模地进行这项工作，因此尽管它是新领域，但并没有太吓人。 - -* **请谨慎** ，因为如果您以前没有做过有状态服务，那么这就是新领域。 经历不同的地方，发生了什么变化，做出的假设，并确保您的假设明确。 - -* **阅读论文**。 不要重新发明自己的协议。 这实际上不是新领域。 自 60 年代和 70 年代以来，人们一直在为此工作。 大部分讨论来自数据库文献。 这些问题已经解决。 您可以根据您的应用程序挑选您关心的内容。 您不必实施整个文件，只需实施所需的文件即可。 - -## 相关文章 - -* [关于黑客新闻](https://news.ycombinator.com/item?id=10378219) - -* [CaitieM.com](http://caitiem.com/) 是 Caitie McCaffrey 的博客。 - -* [应用英雄模式](https://www.youtube.com/watch?v=xDuwrtwYHu8) - -* [晕 4：高需求，低延迟和高可用性](https://www.youtube.com/watch?v=5P4qMBXT4P8) - -* [奥尔良：云计算框架](https://www.youtube.com/watch?v=pkdeXGg7D98) - -* [架构和启动 Halo 4 服务](https://www.youtube.com/watch?v=fJSnM6CWcAs) - -* [重新平衡群集](https://www.google.com/search?q=rebalancing+clusters&oq=rebalancing+clusters&aqs=chrome..69i57.4116j0j7&sourceid=chrome&es_sm=119&ie=UTF-8) - -* [为什么任何人都不能在没有中断的情况下启动在线服务？](http://www.gamesindustry.biz/articles/2013-11-20-why-cant-anyone-launch-an-online-service-without-outages) - -* [#WindowsAzure 经验教训：保持状态](https://alexandrebrisebois.wordpress.com/2014/02/23/windowsazure-lessons-learned-be-stateful/) - -* [使用开源奥尔良框架](http://www.gamasutra.com/blogs/AshkanSaeediMazdeh/20151008/255588/Creating_scalable_backends_for_games_using_open_source_Orleans_framework.php)创建游戏的可扩展后端 - -无状态服务也很容易，以易于理解和预测的方式交易一些额外的资源，以完全消除所有类的问题（例如，升级期间长期存在的会话会发生什么情况）。 - -对我来说，最重要的是，如果您不是*还是*构建下一个 Halo 或 Twitter，则最初说明的构建 12Factor 应用程序的大多数原因仍然适用。 而且我们大多数人不是。 那是一件好事。 - -与服务满足一个请求后，使用缓存保留数据有何不同？ 只是我没有将应用程序服务器保存数据，而是将其保存在部署在一组专用服务器上的分布式缓存中。 如果状态保持在分布式哈希图中，并保持从服务逻辑（服务）到分布式哈希图（缓存）的持久连接，那它将是有状态服务吗？ - -看看 Azure Service Fabric（https://azure.microsoft.com/zh-cn/campaigns/service-fabric/）。 它带来了奥尔良的一些概念，但是包装得更好，并增加了更多的价值（Actor 提供无状态和 Statefull 可靠服务）。 - -实际上，服务结构在哈希算法上有所不同（它们没有 DHT），并且在某些其他方面，请谨慎选择。 - -这种有状态的应用程序架构可以通过多个缓存层架构轻松实现-缓存数据库中的数据，缓存处理后的数据（信息，结果）以及缓存表示数据（json，xml）。 - -> “如果需要高可用性，除非确实需要，否则应避免使用共识系统。” - -她没有那么说。 - -她说，如果您需要一个高可用性系统，那么共识系统是设计动态集群成员资格的最后手段，因为共识系统本身在故障情况下可能不可用。 - -但是她没有提到像 Hashicorp 的 Consul 这样的高可用性共识系统，在该系统中，您有服务器集群来管理该状态。 我希望她对使用此工具构建分布式系统有意见。 - -通过共识系统，我认为她指的是 Raft 或 Paxos 之类的东西，它们试图变得更加一致而不是可用（来自 CAP）。 Consul 使用 SWIM 协议进行动态成员资格，另一方面，该协议可用而不是一致的。 SWIM 允许部分可用性进行操作，而 Raft 或 Paxos 等系统则不允许。 我相信她只是重新开始了 Peter Bailis 所说的，除非您确实需要，否则不要使用 CP 系统。 - -非常感谢您对 Caitie McCaffrey 演示文稿的写作。 这是一个接近完美的成绩单，而且是一个很好的介绍。 没有它，我可能会错过她的演讲。 - -自 2000 年以来，我一直在从事 MMO 游戏服务器的开发。在大部分时间里，这一直是一个很小的利基市场。 像大多数分布式系统一样，MMO 必须扩展。 但是，与大多数其他分布式体系结构不同，MMO 是高度有状态的。 - -直到最近，我还没有从游戏界之外找到许多解决这些问题的例子。 同样，游戏工作室/发行商传统上也不愿意分享他们的“商业秘密”。 结果，当开发人员在工作室之间移动时，对这些概念的了解往往会缓慢扩散。 - -很高兴看到我们在 MMO 空间中使用的一些以这种方式验证的技术。 看到这些想法得到改进和增强也很酷。 持久连接，是的。 背压是必须的吗？ 嗯..很明显，但是我们没有这样做。 当然，可以通过一致的哈希值进行分片。 分布式哈希表？ 哦，希望我们也这样做。 我们会探索这样的想法，但是常常会发现，在没有证据证明别人已经证明自己的价值的情况下，很难为进行这些工作辩护。 - -我很高兴看到该主题在更广泛的背景下获得了一些“合法性”。 很高兴知道我们 MMO 开发人员并不孤单。 :) - -干杯! - -对不起，如果我错过了什么。 但是，这篇演讲并没有说明如果有状态节点死亡将导致的数据丢失。 FB 的共享内存方法是一种方法，但是在这种方法中，我们是在关闭节点之前显式复制数据/但是什么是节点/ VM / PhysicalMachine 突然崩溃。在这种情况下不会丢失数据 ？ - -> 但是，这篇演讲并没有说明如果有状态节点死亡将导致的数据丢失。 - -如果仅将状态保留在内存中，则只会丢失数据。 您真正要做的是主要使用内存，但也可以在外部存储状态，以便您可以恢复。 例如，Akka 具有持久性的“事件源”模型-参与者可以持久/发出代表其内部状态变化的事件； 如果由于故障或重新平衡而需要重新启动 actor，则将回放这些事件，以便 actor 可以恢复其状态。 \ No newline at end of file +* [Mac Slocum 在“数据驱动的站点”](http://radar.oreilly.com/2010/09/a-new-twist-on-data-driven-sit.html) 上的新变化。 *十亿个应用程序数据如何塑造 TripAdvisor 的网站。* \ No newline at end of file diff --git a/docs/68.md b/docs/68.md index 84ddac6..69938a5 100644 --- a/docs/68.md +++ b/docs/68.md @@ -1,57 +1,353 @@ -# Zappos 的网站与 Amazon 集成后冻结了两年 +# TripAdvisor 架构-4,000 万访客，200M 动态页面浏览，30TB 数据 -> 原文： [http://highscalability.com/blog/2015/10/7/zapposs-website-frozen-for-two-years-as-it-integrates-with-a.html](http://highscalability.com/blog/2015/10/7/zapposs-website-frozen-for-two-years-as-it-integrates-with-a.html) +> 原文： [http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html) -![](img/b908cf9bfa36156bb782deeaf588ff49.png) +![](img/f5d73e9a698265918ca5768397e905ed.png) -这是来自 [Roger Hodge](https://twitter.com/rogerdhodge) 在《新共和国》中写的精彩而深刻的文章中的一个有趣的掘金： [Zappos 进行了一项激进的实验，以终止我们所知的办公场所](http://www.newrepublic.com/article/122965/can-billion-dollar-corporation-zappos-be-self-organized)： +*这是 TripAdvisor 工程部副总裁 [Andy Gelfond](http://www.linkedin.com/in/andrewgelfond) 的特邀帖子。 安迪（Andy）在 TripAdvisor 呆了六年半，在早期就写了很多代码，并一直在建立和运营一流的工程和运营团队，该团队负责全球最大的旅游网站。 史诗般的 TripAdvisor 更新：[上有此文章的更新：为什么不在云上运行？ 盛大实验](http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html)。* -> Zappos 的面向客户的网站在过去几年中基本上被冻结，而该公司将其后端系统迁移到 Amazon 的平台上，这是一个多年项目，称为 Supercloud。 +对于 [TripAdvisor](http://en.wikipedia.org/wiki/TripAdvisor) 而言，可扩展性已渗透到我们组织的多个层次上-数据中心，软件体系结构，开发/部署/运营，最重要的是在文化和组织内部。 拥有可扩展的数据中心或可扩展的软件架构是不够的。 设计，编码，测试和部署代码的过程也需要可扩展。 所有这一切都始于招聘，一种文化和一个组织，该组织重视并支持复杂，高度可扩展的消费者网站的分布式，快速，有效的开发和运营。 -Zappos 的一个证明是，他们在冻结的网站上仍然卖得很好，而世界上大多数其他地区都采用了跨多个平台持续部署和不断发展的模型。 +## 截至 6/2011 的统计数据 -亚马逊要求采取此举，否则 Zappos 这样的公司可能会对这种深度整合的隐含对[康韦定律](https://en.wikipedia.org/wiki/Conway%27s_law)敏感。 请记住，据报道 Facebook 正在保持 WhatsApp 和 Instagram [独立](http://techcrunch.com/2014/02/19/facebook-buying-whatsapp-for-16b-in-cash-and-stock-plus-3b-in-rsus/)。 停止世界计划必须意味着某些事情，不幸的是，我没有战略眼光来理解为什么会这样。 有什么想法吗？ +* 每月超过 4000 万的唯一身份访问者（Comscore），2000 万成员，4500 万评论和意见 +* 超过 29 种销售点，20 种语言 +* 我们的移动产品可在 iPhone，iPad，Android，诺基亚，Palm 和 Windows Phone 上使用，每月吸引 1000 万用户 +* 每天超过 200M 个动态页面请求，而所有静态资源（例如 js，css，图像，视频等）都通过 CDN 进行服务 +* 每天执行超过 2.5B 的分布式操作（服务，数据库，内存缓存），以满足页面请求 +* 每天流式传输超过 120GB 的日志文件（压缩） +* Hadoop 上 30 TB 的数据，预计明年初将达到 100 TB-每天修补程序，以“需要今天退出”功能/修复 +* 从来没有计划过停机时间，正常运行时间接近 4 9 +* 在北京单独部署以支持 daodao.com +* 每周发布周期，每天发布“补丁”。 开发周期可以是一天，可以是一周，可以是一个月 +* 超过二十个小型团队（略多于 100 名工程师）一次处理 50 多个同步项目，每周部署 20-30 个项目 +* 团队包括：搜索引擎营销（SEM），搜索引擎优化（SEO），内容管理，客户关系管理（CRM），移动网络，移动应用，社交网络（FB），酒店，餐厅，论坛，旅行清单，视频平台，航班，度假租赁，企业列表，内容分发，API，中国 ，亚太地区，销售和营销活动，数据中心运营，开发运营，分析和仓储，质量检查 -本文提供了有关此举的更多诱人细节： +## 一般建筑 -> 同时，将 Zappos 的整个 IT 基础架构迁移到亚马逊-这意味着要想出一种方法，将一套极为复杂的自定义软件程序移至每年 10 亿美元的电子商务网站上 全新的环境-继续。 **这项工作的难度几乎无法想象。** 想象一下，拿一百万平方钉并试图将其插入一百万个圆孔中，除非您甚至都不知道是否所有的孔都存在，或者孔可能位于何处，并且您必须协商访问这些孔的方式 与数十个不同的敌对软件工程师团队。 该项目已经消耗了 Zappos 的技术部门超过两年的时间，在此期间，Zappos 站点几乎是完全静态的。 这意味着**没有任何改进或创新，并且仅修复了最少的错误**。 -> -> 该项目的项目经理 Barry Van Beek 告诉我，他认为 Supercloud 是历史上最大的电子商务重组。 “以前没有人尝试过如此大规模。” 曾在 Zappos 待了八年的 Van Beek 说 **Supercloud 有大约 20 个不同的团队，包括承包商的 250 至 350 人，与 100 多个不同的 Amazon 团队合作。** 当他们开始时，他们不知道自己正在进入什么。 花了几个月的时间弄清楚了亚马逊方面的可用功能，并且在一年多的时间里，Van Beek 甚至不确定迁移在技术上是否可行。 但是，他说， **Supercloud 是亚马逊规定的目标**，他们别无选择。 所以他们想通了。 他说：“努力的程度几乎是难以理解的。” -> -> Van Beek 告诉我，他相信 Supercloud 可以完成，但他担心该报价造成的中断以及亚马逊方面的不可预见的延误会减缓其进展。 当 Zappos 确实完成迁移时，他希望技术部门能够将其注意力转移到电子商务领域的创新上，以解决诸如尺寸和装配问题之类的挑战。 **如果客户在订购之前更有可能达到理想的状态，则消除退货以及相关的进货和运输成本将提高利润。** +* 开源 Linux，Apache，Tomcat，Java，Postgres，Lucene，Velocity，Memcached，JGroups +* 保持非常简单-易于构建，调试，部署，维护和操作 +* 非常简单的无状态 Web 服务器库，运行简单的 Java 和 Velocity 模板 +* 每个“功能”区域（媒体，成员，评论，旅行清单等）都打包为服务 +* “服务”库-每个服务都是针对总体性能进行优化的高级，面向业务的 API +* 假设事情失败了。 集群中有大量节点（Web 服务器，服务机），或者具有真正的 N + 1 冗余（数据库和数据中心本身） -我同意这个项目是疯狂的，这就是为什么我永远不会建议这样做的原因。 我认为它们可以确定推动成功的关键业务流程（例如大约 50 个），并弄清楚如何使用现有的 Amazon 基础架构来实现它们。 然后进行一次大的丑陋转换。 +## 控制流程 -失去的销售绝不会造成该项目成本的损失。 +* 控制流程非常简单：解析请求 URL，从各种服务中收集内容，然后将其应用于模板。 +* 我们的 URL 结构经过深思熟虑，即使在重新设计网站和重构代码的情况下，也能保持很长一段时间的稳定性。 +* 请求通过负载平衡器路由到 Web 服务器。 请求是在基于 cookie 的“池”（服务器的集合）中随机分配的。 池用于部署管理和 A / B 测试。 请求本质上是无状态的-浏览器 cookie 中存储着“会话”信息。 登录的用户将从数据库中获取其他状态。 +* Java servlet 解析 url 和 cookie 信息并确定所需的内容，从而调用各种服务。 服务 API 定义为 Java 接口，而 Servlet 会发出 0 到十几个服务请求。 服务呼叫通常需要 2 到 15 毫秒。 服务调用通过具有可重试逻辑的软件负载平衡器进行，该逻辑可基于每种方法进行定义。 +* 每个服务都具有针对业务和/或使用模式进行了优化的 API，例如，获取成员的评论或位置的评论。 大多数服务本质上是数据库前面的大型智能缓存，例如，局部 LRU，内存缓存，数据库调用在内存部分树/图中。 Jgroups 有时用于在需要时使缓存保持同步。 大多数服务在不同的共享/物理计算机上运行 4 个实例，有时为服务实例分配自己的计算机。 +* 从服务调用返回的内容集经过处理，并由 Java 代码组织成对象集，这些对象集传递给 Velocity 模板（有点像弱 JSP） +* 有多种逻辑可根据上下文选择不同形式的 Servlet 和/或 Velocity 模板，其中可能包括 POS，语言，功能等。还有用于选择 A / B 和其他代码的不同代码和模板路径的基础结构 测试 +* 我们的 Web 服务器排列在“池”中，以允许进行 A / B 测试并控制部署。 我们的每周发布过程将部署到一个小型池中，并让代码运行几个小时，以确保在部署到所有池之前一切正常 -另一件事让我印象深刻……这与人们一直希望人们在其界面和所处理的功能中*希望*不断变化的信念形成强烈反差。 我从没想过对消费者如此，对 B2B 软件也是如此。 如果我是一个有钱的人，并且负责一家公开 B2C 公司，那么我会仔细研究这个示例-所有未花费的费用都将落在底线。 +## 科技类 --XC +* BigIP 冗余对，Cisco 路由器 +* 64 个无状态 Web 服务器，运行 Java servlet 的 Linux / Apache / Tomcat，每天处理 200M +请求的库 +* 40 台运行约 100 个实例的无状态服务机（约 25 个服务实例），Jetty / Java，每天处理 700M +个请求 +* Postgres，在 6 对（DRDB）机器上运行，每天处理 700M +次查询 +* Memcached，3 个独立的群集，运行在 350GB 以上的 Web 服务器上。 Spy Memcache 客户端的可配置池-异步，NIO 以扩展请求。 进行了优化和其他更改以监视 java 客户端以实现规模和可靠性。 +* Lucene 包含在我们的服务基础结构中，拥有 5000 万个文档，55GB 索引，每天 8M 搜索，每日增量更新，每周一次完全重新生成。 -隐藏引用文字- +* 当没有其他选择时，JGroups 用于服务机之间的状态同步。 +* Hadoop，具有 192TB 原始磁盘存储的 16 个节点群集，192CPU，10GB 网络 +* Java，Python，Ruby，PHP，Perl 等用于工具和支持基础架构 +* 监视-仙人掌，nagios，自定义。 +* 两个数据中心，位于 N + 1 配置中的不同城市，一个以 R / W 模式接收流量，另一个以 R / O 模式同步通信，准备进行 24/7 故障转移，定期按季度交换活动数据 +* 每个数据中心总共约有 125 台计算机，所有标准 Dell 设备 +* 日志记录-120GB（压缩）应用程序日志，apache 访问日志，财务敏感数据的冗余日志记录-流式（记录）和非流式 -这样的项目只会在有钱烧钱的公司发生。 如果他们期望获得回报，我怀疑这种规模是否会平衡这十年。 听起来这似乎是 Bezos 的自我动机，而不是艰难的业务需求。 +## 发展历程 -我想 Zappos 会以与 Tony Hsieh 处理整个公司到 Holacracy 的转换相同的方式对待他们的计算基础架构的转换就不足为奇了，也就是说，这是一个很大的突破。 尽管显然托尼不愿意像在网站上那样“冻结公司”，但他们却想办法。 +* 满载的 Mac 或 Linux 计算机，SVN，Bugzilla，30 英寸显示器 +* 数以百计的虚拟化开发服务器。 每位工程师专用一位，按需提供其他服务 +* 每周部署周期-每个星期一都会发布整个代码库 +* 那些“今天需要离开”的人的每日补丁程序/修复 +* 大约 100 个工程师同时处理 50 多个并发项目，每周部署约 25 个 +* 工程师端到端地工作-设计，代码，测试，监控。 您设计一些东西，然后编写代码。 您编写一些代码，然后进行测试。 +* 工程师跨整个堆栈工作-HTML，CSS，JS，Java，脚本。 如果您不了解某些内容，则可以学习。 +* 发布过程在各个高级工程师和工程经理之间共享和轮换 +* 可用的测试框架多种多样：单元，功能，负载，烟雾，硒，负载和测试实验室。 它是您的代码，选择最适合您的代码。 +* 多种机制可帮助您提供最优质的功能：设计审查，代码审查，部署审查，运营审查 -我建议冻结网站以完成这种转换在很大程度上是想象力的失败。 即使他们现有的系统是单片的“一级”应用程序（就像亚马逊曾经的那样），也没有技术上的理由，他们不应该将其逐段转换到云平台上。 我的意思是，在现有代码中抛出“ if”语句以将某些服务调用的一部分发送到新系统，从而合理地安全地推出“转换后的”后端有多难？ “范贝克（Van Beek）甚至在技术上都不确定迁移是否可能”中出现的明显场面表明，也许他们选错了人。 不是“技术上可行的”吗？ 请。 我们在这里谈论的是在计算机上运行的代码，而不是光速旅行。 +## 文化 -关于您关于 Instagram 的观点，我最近在 Facebook 上进行了大约 1 个小时的演讲，他们概述了将 Instagram 从 AWS 迁移到 Facebook 内部计算基础架构所采取的步骤，该功能远不及 AWS 那样丰富或灵活。 。 显然这不是一件容易的事，他们设法做到了不冻结甚至关闭 Instagram。 +* 与运行两个同时启动的新兴公司相比，TripAdvisor 的工程技术最好，它们都在同一代码库上运行，并且在一个通用的分布式计算环境中运行。 这些团队中的每个团队都有自己的业务目标，每个团队都有能力并对其业务的各个方面负责。 交付项目的唯一障碍是您，因为您应该在各个级别上工作-设计，代码，测试，监视，CSS，JS，Java，SQL，脚本。 +* TripAdvisor 工程是按业务职能组织的-有两个以上的“团队”，每个团队负责直接与他们的业务同行在 SEM，SEO，移动，商务，CRM，内容，社交应用程序，社区，成员资格，销售和营销解决方案上合作 ，中国，亚太地区，商家信息，度假租赁，航班，内容联合供稿等。 我们没有传统的架构师，编码员，质量检查人员 +* 我们的运营团队是一个团队，负责所有其他团队使用的平台：数据中心，软件基础架构，DevOps，仓储。 您可以将 Operations 视为我们的内部“ AWS”，将我们的 24/7 分布式计算基础架构作为服务提供，并且将代码/开发/测试/部署全部整合为一个。 该团队包括两名负责数据中心和软件基础架构的技术运营工程师和两名现场运营工程师。 +* 每个团队的运作方式都最适合其独特的业务和个人需求，我们的流程被形容为“敏捷后/混乱”。 +* 责任文化-您端到端拥有您的项目，并负责设计，编码，测试，监视。 大多数项目是 1-2 位工程师。 +* 记录和测量-大量数据，大量指标 +* 黑客周-每个工程师每年都有一个星期从事他们想要的任何项目。 您可以与其他人一起解决更大的项目 +* 工程交换。 来自不同团队的工程师对将交换几个星期的时间，以传播知识和文化 +* Web 工程程序。 一个新的计划，适用于希望在许多不同的团队中工作几个月的工程师。 +* 夏季星期五-在夏季改变您的星期几并释放星期五的时间 +* 每年的慈善日-整个公司外出并为当地的慈善机构捐款-绘画，园艺等 +* TripAdvisor 慈善基金会。 员工可获得数百万美元的资助，可以向自己所参与的慈善组织申请赠款。 -实际上，Instagram 已迁移到 FB 的基础设施 http://engineering.instagram.com/posts/1086762781352542/migrating-from-aws-to-fb/ +## 关于我们学到的东西，我们如何工作的随机想法 -“这证明了 Zappos 在冻结的网站上仍然能很好地销售产品，而世界上大多数其他地区都采用了跨多个平台的持续部署和不断发展的模型。” +* 可扩展性始于您的文化，即您的雇用方式，雇用对象和设定的期望。 +* 工程师。 雇用聪明，快速，灵活的工程师，他们愿意从事任何类型的工作，并为学习新技术而兴奋。 我们没有“建筑师”-在 TripAdvisor 上，如果您设计某些东西，编写代码，然后对它们进行测试。 不喜欢走出舒适区的工程师，或者觉得某些工作在他们“之下”的工程师将很容易受阻。 +* 雇用从交付有用的事物中获得乐趣的人。 技术是达到目的的手段，而不是最终目的。 +* 您拥有自己的代码及其效果-设计，测试，编码，监控。 如果您弄坏了东西，请修复它。 +* 最好是在两天之内交付 20 个带有 10 个错误的项目，而错过 5 个项目，而不是交付 10 个完全且及时的项目。 +* 鼓励学习和突破极限-在这里工作的每个人在开始的几个月中都会犯许多错误，并且随着时间的推移，偶尔还会犯错。 重要的是您学到了多少，不要一次又一次犯同样的错误。 +* 保持设计简单，并着眼于近期业务需求-不要设计得太远。 例如，随着我们的会员功能从数万个扩展到数百万个到数千万个，我们已经重写了我们的成员功能。 当我们需要的数以万计的时候，我们为数千万的设计本来就很糟糕。 我们更快地交付了每个阶段的问题，并且与每个阶段所学的相比，重写的成本很小。 +* 您可以在垂直扩展数据库方面走得很远，尤其是在最小化联接使用的情况下，尤其是可以将所有内容放入 RAM 的情况下。 +* 仅在必要时才进行分片，并保持简单。 我们最大的单个表具有超过 1B 的行，并且可以轻松垂直扩展，直到我们每天需要更新/插入数千万行，达到写入 IOP 限制。 到那时，我们通过将其拆分为 12 个表在服务级别上进行了分片，并且目前在 2 台计算机上（每台都有 6 个表）运行它。 我们可以轻松地将其扩展到 3、4、6，然后是 12 台机器，而无需更改哈希算法或数据分布，只需复制表即可。 我们没有任何可衡量的性能下降（读取或写入），并且执行此操作的代码很小，易于理解且易于调试。 每天有超过 700M 的数据库操作，因此我们离分拆任何其他表都不远。 +* 尽可能避免加入。 我们的内容类型（成员，媒体，评论等）位于单独的数据库中，有时在共享计算机上，有时在其自己的计算机上。 比执行联接要好得多（执行两个查询（获取具有其成员 ID 的评论集，然后从该 ID 集合中获取所有成员并在应用程序级别将其合并））。 通过将数据存储在不同的数据库中，可以轻松地将每个数据库扩展到一台计算机。 保持内容类型的可伸缩性也更加容易-我们可以以模块化的方式添加新的内容类型，因为每种内容类型都是独立的。 这也与我们的面向服务的方法非常吻合，该服务由数据库支持。 +* 承担单个工程师的端到端责任。 当一个人拥有一切（CSS，JS，Java，SQL，脚本）时，就没有等待，瓶颈，调度冲突，管理开销或“所有权”的分配。 可以采用模块化方式添加更多项目/人员，而不会影响其他所有人。 +* 服务。 拥有一组与业务和使用模式对齐的已知的块状协议（针对有线网络进行了优化）协议，使组装页面变得更加容易，并允许您根据业务需求扩展每个服务。 搜索流量大增？ 添加更多搜索服务器。 还可以使您更仔细地考虑使用模式和业务。 +* 硬件-保持非常简单。 没有花哨的硬件-没有 SAN，没有专用设备（用于网络设备）-我们运行所有戴尔的商品。 假定任何组件都会随时发生故障，并且具有 N + 1 设计或足够的资源来弥补故障。 我们的网络服务器库可以处理大量失败-高达 50％。 数据库为 N + 1，具有重复的热（基于 DRDB）故障转移。 服务在多台计算机上运行多个实例。 负载平衡器和路由器均具有热备用和自动故障转移。 我们在不同城市拥有两个完整的数据中心，一个处于活动 R / W 模式，可处理所有流量，另一个处于最新状态，R / O 模式可随时用于流量。 我们每三个月进行一次“故障转移”，以确保随时准备好“备份”，并为我们的数据中心提供连续/增量的维护。 +* 软件-保持非常，非常，非常简单。 有一些您不想自己写的系统-Apache，Tomcat，Jetty，Lucene，Postgres，memcached，Velocity。 我们自己构建了其他所有内容-分布式服务体系结构，Web 框架等。这并不难做到，您可以理解和控制所有内容。 +* 处理。 越少越好。 您需要使用源代码控制。 您需要成为一个良好的代码公民。 您需要交付有效的代码。 您需要传达您的设计及其工作水平。 “需要”或“需要”没有太多其他内容。 如果您很聪明，则将对设计进行审查，对代码进行审查，并编写测试和适当的监视脚本。 雇用了解您想要这些东西的人，因为它们可以帮助您提供更好的产品，而不是因为它们是“必需品”。 如果您犯了一个错误，并且您会犯错，并且将其修复。 重要的是要找到自己的错误，而不要依靠别人为您找到错误。 +* 设计评论。 邀请所有工程师进行每周设计审查。 如果您有一个项目会影响其他项目（数据库，内存使用，新的 servlet，新的库，重要的东西），那么您应该在设计审查时介绍您的设计并进行讨论。 这不仅是对整个系统提供指导和监督的好方法，而且是每个人互相学习并了解正在发生的事情的好方法。 -我知道人们不敢得出另一个结论：大多数开发组织并没有增加底线，应该受到挑战。 +* * * -有谁知道为什么亚马逊要求这种改变或要求改变什么？ +我非常感谢 Andy Gelfond 对 TripAdivsor 所做的工作提供了非常有用的描述。 好工作。 如此注重细节，不难看出为什么 TripAdvisor 如此有用。 谢谢。 TripAdvisor 正在[招聘](http://www.tripadvisor.com/careers/)。 -我很想知道他们为什么要迁移到亚马逊！ +## 相关文章 -Zappos 在过去几年中失去了我作为客户的机会。 他们的网站在查找产品，评论，订单历史记录等方面不再具有竞争力。（尝试一下-例如，搜索已完全中断。）他们可能失去了大量客户，但由于困难而没有意识到 跟踪此指标。 像我这样的客户由于更好的选择而只是默默地退出使用他们的服务。 +* [黑客新闻主题](http://news.ycombinator.com/item?id=2701936) -他们确实跟踪客户指标，相信我，我曾经是那里的开发人员。 +> Postgres，在 6 对（DRDB）机器上运行，每天处理 700M +次查询 -这个举动并不太令人惊讶，但令人遗憾，这可能是他们在过去几年中大量迁移开发人员的原因。 我是将网站从 perl 更新到 Java 的团队的一部分。 我们真正接触的唯一一件事是基础数据库。 我们最终得到了一个更瘦的应用程序，该应用程序使用了更少的资源。 +是 DRBD（http://en.wikipedia.org/wiki/DRBD），对吗？ -至于关于“添加'if'语句”的评论，那并不涵盖所有内容。 从 perl 到 Java 的迁移需要一些计划和协调。 那里最大的障碍是移动/镜像数据。 如果您每天要处理成千上万的订单，那么确保在迁移过程中获得正确的数据并非易事。 然后，您拥有了现在必须在两种体系结构上都可以使用的支持软件（当时全部由内部编写）。 哦，是的，然后您就有了与库存和订单管理数据进行通信的仓库处理程序，这些数据也必须在这两个系统之间都可以工作。 +> 工程师端到端地工作-设计，代码，测试，监控。 您设计一些东西，然后编写代码。 您编写一些代码，然后进行测试。 +> 工程师跨整个堆栈工作-HTML，CSS，JS，Java，脚本。 如果您不了解某些内容，则可以学习。 +> 交付项目的唯一障碍就是您，因为您应该在所有级别上工作-设计，代码，测试，监视，CSS，JS，Java，SQL，脚本。 -这将是一个很大的挑战。 \ No newline at end of file +don't you end up with dissimilar code all over the place? +are you allowing your dev to design the way your apps interact with end users? don't you know that dev rarely design good user interfaces? +if the same dev is also responsible for supporting their code throughout its lifetime, don't you eventually get into a situation where that dev/team will do nothing but fix bugs in their existing code and don't have enough time to work on new projects? + +DRBD 是正确的，谢谢 Progga + +嗨，mxx， + +我们的系统并不完美-每个团队都需要决定对他们而言重要的事情并做出选择。 是的，有时我们确实会得到重复的代码，但这并没有您想的那么糟糕。 我们依靠工程师来做正确的事，并且我们进行了大量的代码审查。 开发人员在其“生命周期”中并不总是对其代码负责，您对您的项目负责，并且各种各样的人可能会介入并使用您的代码来做事-这有其优点和缺点。 系统对我们来说运作良好，而且最重要的是，可以使人们参与其中-您在整个堆栈中工作，并且您可以进行自己的软件设计和测试。 + +而且，不，开发人员不会执行 UI 或图形设计，这种情况在很多年前在我们的网站上有了足够的 wtf 后就结束了。 “设计”是软件设计。 其他团队负责 UI /图形。 + +安迪 + +1）大概是数据库写操作从 R / W 数据中心复制到 R / O 数据中心（通过 Postgresql 9.0 复制？）如何处理复制滞后？ 例如，如果我提交了酒店评论，它将被写入 R / W 数据中心。 现在，如果我再次访问该酒店的页面，则可能会将我路由到 R / O 数据中心，由于复制滞后，该数据中心可能尚未接受新提交的评论。 在这种情况下，用户可能认为他的评论已丢失。 你如何处理？ + +2）为什么每周都要重新生成 Lucene 索引？ + +谢谢。 + +嗨安迪， + +我们使用 Postgres8.x。 复制是通过一种较旧的查询复制方法（类似于 slony）完成的，多年来，我们已对其进行了升级（例如，通过批量查询以提高性能）。 活动数据中心将复制到另一个数据中心和我们的“本地”办公室数据中心。 有一个滞后-每个人可能要花几分钟才能赶上。 + +但是，数据中心处于 N + 1 配置-只有一个（R / W）正在获得流量。 另一个（R / O）处于活动状态并且可以传输流量，但是 DNS 仅指向活动的一个-因此，我们没有遇到您提到的问题，因为我们有两个数据中心用于可靠性，而不是规模。 + +我们研究了日志和/或流复制（我相信这就是 Postgres 9 所做的），但是它并不像我们想要的那样可靠-数据传输中的损坏会产生重大影响。 使用查询复制（并非如此）以及使用查询复制，我们还可以根据需要手动调整数据（我们需要做几次）。 我们在北京也有一个数据中心，该数据中心的延迟和连接性很差-考虑到它的情况，查询复制对我们来说效果更好。 + +Lucene 索引再生-我们发现，随着时间的推移，增量更新会导致索引碎片化和性能下降，因此我们每周进行一次完整重建，以使其保持“干净”。 另外，索引更改（无论是增量重建还是完全重建）都是在脱机状态下完成的，我们每天重新启动 lucene 以使用新索引-我们永远无法获得“实时”的工作。 我们经营一小堆的 Lucene 包裹式服务，因此没有停机时间。 很有可能有一种更好的方法可以做到这一点-我们尝试了许多方法，并且到目前为止，这种方法效果最好。 + +“每个服务都具有针对业务和/或使用模式进行了优化的 API-例如，获取成员的评论或位置的评论。大多数服务本质上都是数据库前面的大型智能缓存，对于 例如，局部 LRU，memcached，数据库调用在内存局部树/图形中； Jgroups 有时在需要时用于使高速缓存保持同步；大多数服务在不同的共享/物理计算机上运行 4 个实例，有时为服务实例分配自己的计算机。 ” + +和： + +“ +40 台无状态服务银行，运行约 100 个实例的〜25 服务，Jetty / Java，每天处理 700M +个请求 + +在 6 对（DRDB）计算机上运行的 Postgres，每天处理 700M +次查询 +“ + +我有些困惑：服务进行大量缓存，但是每天的请求数似乎与数据库上每天的查询数相匹配。 我猜想也许对数据库的大量查询与这些服务无关？ + +1.您最初是如何进行负载测试并选择 Tomcat 进行此类负载的？ +2.当前如何对整个堆栈进行负载测试？ +3.您具有哪些 CI 设置和单元测试？ +4.您是否使用 JMX 或其他方法监视应用程序事件？是否通过 HTTP 将日志事件传输到浏览器以监视批处理程序的进度。 + +Thanks. + +嗨，您好， + +非常感谢您的出色描述！ +来自 Web 公司，我很惊讶地将 Java 视为后端。 您对选择 Java 作为后端语言的满意程度如何？ 我真的很喜欢它，但是我很难抗拒更多“炒作”语言（如 Ruby，Python，Scala，JS 等）的诱惑。 + +我想成千上万的词，您会基于 Java 再做一次，为什么或为什么不呢？ + +> 您是否允许开发人员设计应用程序与最终用户交互的方式？ 您不知道开发人员很少设计良好的用户界面吗？ +> 如果同一个开发人员还负责在其整个生命周期内支持其代码，那么您最终是否会陷入这种情况，即该开发人员/团队除了修复现有代码中的错误之外什么都不做，没有足够的时间来 在新项目上工作？ + +通常，将向开发人员提供图形设计和产品营销团队的模型。 “这是它的外观”。 工程师的职责通常在发布后一周就结束，因为很明显没有与此相关的直接问题（尤其是性能问题）。 到那时，您便可以开始其他工作了。 哪一个确实可能是错误修复或其他人项目的功能增强。 期望所有工程师都可以使用任何代码库工作。 长期代码拥有权比我在其他地方看到的要少得多。 因此，开发人员最终会看到彼此足够多的代码，而这些代码最终不会因阅读或使用而异样。 + +安迪 + +感谢您的解释。 + +> >我们从未能够获得“实时”的工作。 + +您尝试了哪种类型的实时 Lucene 实现，但无法使其正常工作？ + +Lucene 2.9 添加了 NRT（近实时）。 您使用的是早期版本，还是 Lucene NRT 根本不适合您？ 很想在这里详细了解您的经历。 + +安迪，您提到您的运营团队包括两名技术工程师和两名现场工程师-当然，这不能成为整个团队吗？ 您能否提供更多有关团队规模及其组成的见解？ + +谢谢你写的好。 + +罗伯 + +Andy. + +那真是太棒了。 我的问题之一是，您是否在完全使用开源架构运行 4 9 的正常运行时间基础架构？ 以及如何确保应用程序响应时间达到目​​标。 另外，想知道如何监视基础架构？ + +我将尝试回答尽可能多的问题： + +丹： +服务调用和数据库调用的数目大致相同是巧合，并且数据库调用的数目更多是猜测（我们将 db 调用记录在 Java 代码中），但这是正确的。 我们的许多网页进行多个服务调用，而我们的许多服务进行多个数据库调用，但是每天大约有 1B +内存缓存调用保持了数据库的负载。 由于我们缓存对象而不是查询，因此许多对象可能代表几个数据库调用。 如果我们不使用 memcached，则可能一天会执行 2B +查询。 我一直发现有趣的是，将我们从不同来源收集的所有数字进行关联是多么困难。 + +Mohan： +-当我们开始（11 年前）时，我们使用了标准的 Linux / Apache / Tomcat / Java / Postgres 堆栈。 那时我还没来得及，但我认为决策周围没有太多的结构化流程，我也不认为当时还有许多其他开源选项 +-负载测试是一个有趣的领域。 我们有不同的测试工具和测试，测试实验室，有时我们使用辅助数据中心。 有时我们使用实时数据中心（例如，将 1/2 台 Web 服务器淘汰掉以查看会发生什么）。 负载测试是在我们认为需要的地方进行的，并且说实话，这是一门艺术。 我们了解到的一件事是，即使重放日志文件，也永远无法真正进行负载测试。 我坚信一切都会失败，并确保您有恢复的方法。 +-不熟悉“ CI” +-监视是通过 Nagios，Cacti 和许多自定义脚本来完成的，这些脚本分析我们的日志并显示数据。 我可以按 servlet，日期和小时向下钻取，以获得页面请求的总时间，cpu，数据库，服务调用数据（经过时间和调用次数）。 + +主持人： +-我对 Java 非常满意，尤其是对于服务。 天哪，强大的线程和状态支持对于构建高性能服务至关重要。 我不确定如何实现可共享的进程内缓存以及如何使用其他语言处理线程。 我们的服务机每秒可以处理数千个请求，并且仍以 15％的负载运行。 如果我要再做一遍，我会考虑一些脚本语言用于前端工作（我们在该领域的一些实验并未显示出许多弊端的实际好处），但是对于服务器工作线程却能够保持 状态（共享内存）对于我们的用例至关重要。 + +steveo： +谢谢 SteveO :-) + +Andy： +我们尝试通过 api 逐步更新索引，但存在很多问题。 这是几年前的事，我不记得具体情况。 拥有 NRT 对我们来说很好，但并不关键。 + +Robbo：​​ +我们过去曾为两个数据中心配备一名技术运营工程师，但发现我们需要再增加一名：-) +我们有两个以上的空缺，因为我们计划扩大规模。 + +因此，我们有： +2 位数据中心和我们的开发环境（很多 xen 服务器）的技术运营（数据中心）人员 +2 位负责软件基础架构的“站点运营”工程师。 +发布工程由我们的网站运营工程师和各种技术经理（需要给他们做一些有趣的事情）完成。 +来自各个团队的 10 多位工程师可以访问该网站并提供补丁程序帮助， 发行，软件开发，数据库，数据中心等。 +对于我们的工作方式，重要的是，软件团队从字面上看要是真正的“游戏皮”。 + +“ Dan： +服务调用和数据库调用的数量大致相同是巧合，并且数据库调用的数量更多是猜测（我们将 db 调用记录在 Java 代码中），但这是正确的。许多 我们的网页中有多个服务调用，而我们的许多服务也有多个数据库调用，但每天大约有 1B +内存缓存调用保持了数据库的负载。由于我们缓存对象而非查询，因此许多对象可能代表 几个数据库调用。如果我们不使用 memcached，我们可能一天会进行 2B +查询。我一直发现有趣的是，将我们从不同来源收集的所有数字关联起来是多么困难。” + +谢谢安迪。 + +同意，关联是建立对我们系统的理解的关键挑战。 实际上，我觉得这里总是会有一些近似值，因为数字是由具有不同上下文量的不同层产生的，这是我们用来将事物捆绑在一起的上下文。 即使是简单的东西，例如使用系统时钟来确定时间段内的顺序或相关数据的收集，也是有问题的。 + +另一个挑战是在不影响用户感知性能的情况下捕获信息。 一个人要么避免捕获数据，要么接受其中的某些数据可能丢失。 我倾向于默认使用后者，因为有些信息总比没有好。 + +大话题，值得啤酒讨论！ + +最好， + +Dan. + +克里希纳坎特： + +我们使用多种监视技术，包括用于外部“第三方”监视的 Gomez 以及自定义脚本和工具。 +我们的“ 4 9”并不是统一的衡量标准。 有一些功能对我们的业务很重要（基本站点的建立，商务和评论），这实际上是衡量标准的来源。我们的站点非常复杂，具有许多不同的内容类型和功能。 如果基本站点，商务和评论正在运行，则我认为该站点已“启动”。 更重要的是，我的老板也是如此：-)我不确定其他所有设备的正常运行时间，但是大概是 3 个 9。 + +关于开源与“商业”解决方案-事实是，它们都失败了。 永远不要相信任何组件，尤其是 SAN。 组件声称“完全可靠”的越多，由于最终信任它，您可能会遇到更多麻烦。 设计失败。 + +正常运行时间可以通过多种方式实现： + +三个基本规则：简单性，围绕所有组件均发生故障的事实进行设计，并使软件工程师和管理人员始终承担起运营责任。 + +-我们让事情变得非常简单-商品硬件，以及软件的基础知识（Linus / Apache / Tomcat / Java / Postgres / Lucene / Memcached / jgroups）。 我们仅使用简单的系统/软件，我们了解它们的深入工作原理，经过实践证明，具有良好的运营支持，更重要的是，我们知道疣在哪里，因此我们可以对其进行管理。 +-保持操作尽可能简单和可见（自动），但请确保您可以在任何步骤进行干预。 +-我们的许多工程师都具有丰富的操作知识，可以随时待命，并可以为现场站点及其操作提供帮助。 我们的运维团队非常小，但“虚拟”运维团队非常庞大，其中包括许多经理。 团队中很少有工程师不会感觉到现场的“热度”。 +-假设一切失败。 我们不仅对所有“关键”部分（路由器，负载平衡器，数据库和其他“关键”计算机）进行了加倍（N + 1 配置），而且还可以容忍多台计算机宕机的 Web 服务器和服务库。 而且，整个数据中心在 N + 1 配置中翻了一番。 这不仅为我们节省了一些时间（当 BigIP 出现两次故障时您将不胜感激，并且可以在 5-10 分钟的停机时间内解决这个问题），而且还使我们能够进行认真的机器/网络维护和安全性升级。 + +Hi Andy, + +您的 3 层架构（web- >服务-> db）有多严格？ 是为了保持体系结构简单而实施的，还是为了某些本地的简化/可管理性而尝试减少某些地方的层？ + +开发人员如何工作？ 在本地启动这 25 个服务中的一些服务，本地数据库并针对它们开发 Web 服务器？ + +您说过要对服务进行负载平衡：Web 和服务层如何通信？ （http，RMI 甚至是 Corba？）为什么您决定支持硬件的软件负载平衡？ + +感谢您分享所有这些！ +Stefan + +您好 Stefan， + +好问题- + +我们的三层体系结构未强制执行。 我们希望看到所有来自服务的数据库调用。 不幸的是，由于大多数是遗留原因，而且并非所有主要功能都在服务中，有时我们需要做的一些简单事情不值得将服务组合在一起，因此 Web 服务器确实会进行数据库调用。 当解决变得很重要时，那些“优先拥有项目”可能会被优先考虑。 但是，我们确实有所谓的“ DBR” db 读取数据库。 这些是只读数据库，每天更新一次，并且处于负载平衡配置（我认为我们有 3 个），因为我们已经将所有可写操作移到了服务上。 因此，服务获得了令状，大多数读取得到了，并且有些数据可以直接读取。 + +我们有一些常见的服务和数据库库，因此，如果您仅在 Web 层上工作，那么您所需要的只是前端。 如果您正在使用某项服务，则除了运行 Web 服务器或测试工具外，您所需要的只是运行自己的服务版本-您的个人 ini 文件可以访问并混合并与任何地方的服务匹配。 服务接口的更改需要向后兼容，因此效果很好。 + +如果您需要添加/更改表，则可以对共享数据库之一进行操作，因为这些更改还需要向后兼容。 很少有人需要运行自己的数据库服务器。 对于某些不向后兼容的模式更改的项目，还有其他整个流程可付诸实践，因为现在我们面临着巨大的实时站点部署挑战。 这偶尔发生。 + +服务是 XML / HTTP。 这样做的目的很简单，它使我们能够看到正在发生的事情，并轻松生成测试用例。 但是，恕我直言，一旦您有什么值得编码的地方，XML 就会像二进制格式一样流行。 因此，我们现在通过 xstream 进行序列化（那里有很多优点/缺点）。 服务调用是由 Java 接口定义的，我们有一个代理，它将接受方法调用，并根据配置设置将它们分配给服务器。 设置将重试逻辑确定为方法级别（等待时间长短，一台计算机上多少次退休，多少台计算机重试）。 负载平衡是通过生成 ini 文件设置来完成的-例如，给定的服务通常将映射到 4-8 台计算机，并且不同的 Web 服务器将具有不同的顺序。 如果其中一个不起作用，它将尝试下一个，并在一段时间后重置为原始配置。 + +有点笨拙（它是多年来开发的），存在一些问题，但是非常可靠，并且非常容易通过编辑其配置文件来调整计算机。 我们可以通过旋转一台新的服务机并调整一台 Web 服务器来轻松地在站点上测试服务的新代码。 对于本地开发，这也非常有用。 + +由于历史上的增量开发，我们选择了软件负载平衡方，但是我们的负载平衡需求非常复杂，有时需要以临时方式进行调整，需要开发人员进行修改以供本地使用，并且我们也希望能够 打开登录以提供正在发生的事情的详细信息。 我们已经讨论过将其移至负载均衡器的方法，但是我们不了解如何以数据驱动（ini 文件）的方式进行此操作，如何让每个开发人员都有自己的设置，或允许 Web 服务器调出 任何 HTTP 服务（例如，不在同一网络上）。 对于更改负载均衡器上的代码以及如何正确测试它，也存在极大的恐惧。 + +帖子不错，谢谢您的分享。 + +谢谢，安迪， + +特别是您对负载均衡器的洞察力非常有趣。 我在一个非常相似的网站上工作，但是房地产和德语（仅德语），可能占您页面浏览量的十分之一，而且我们确实有硬件负载平衡器。 结果是，即使开发人员几乎不了解 devop，对于开发人员来说，这个主题也是一个（遥远的）黑匣子，并且是唯一的可操作事情。 + +此外，还有很多与“开发人员因为开发环境没有 Big IP 负载平衡器而无法正确测试”有关的问题，您可能可以避免这种情况。 我只能建议您坚持这个决定。 + +最佳 +Stefan + +设计审查实践似乎非常有趣。 +我同意我们不需要“ powerpoint”架构师，但有些开发人员更有经验。 您如何避免没有大的自我冲突导致拼凑而成的设计？ + +Hi Andy, + +您提到您的内容按内容类型（成员，媒体，评论等）分隔，那么您的 20 种语言呢？ 每种语言都有一个数据库吗？ 也就是说，每种内容类型都有 20 个数据库吗？ 还是每种内容类型只有一个数据库（包括所有语言）？ + +Best, + +马蒂亚斯 + +嗨，Uberto， + +您从事和/或领导的项目的类型取决于您对我们系统的经验和知识-这样，如果您是新手或刚离开学校，则可以拥有自己的小型项目，或者与他人一起工作 一个更大的项目的高级工程师。 随着学习，您将获得“更大”的项目。 + +我以与代码审查相同的方式看待设计审查-您之所以不要这样做，不是因为期望，而是因为您真正地感觉到它们是帮助您交付最佳代码的好方法。 我发现，比较成功的工程师是积极寻求代码和设计审查的工程师。 + +关于自我。 通过明确我们的工作方式，许多信息在面试过程中被过滤掉了-许多“非常高级”的工程师不想编写代码或进行测试，因此他们会转到其他公司。 我发现，当有人被迫在同行面前讨论他们的设计，并且他们需要进行自己的编码和测试时，设计往往会更简单，更实用和更清洁。 + +虽然要求人们回头重新考虑其设计的某些方面在某种程度上很普遍，但很少有真正的分歧。 我只能想一想我实际上必须介入并做出决定的地方-团队总是做出一个令我满意的决定（我可能会以相同的方式做）或我足够自在（也许不是） 我会做的方式，但效果很好，至少 imo :-)。 + +我认为这与两件事有关：一是每个人都真正想做正确的事，人们真正尊重彼此的意见，而我们拥有可借鉴的巨大广度和经验。 + +第二个是我们的“设计”专注于方法/操作，这使事情变得实用。 事实是，您可以使任何语言工作和扩展-Python，Perl，Java，PHP，甚至 Ruby :-)-我们关注的重点是内存使用情况，代码所在的位置（Web 服务器，服务，离线）， 数据已存储（数据库，文本文件，日志文件，内存），通过网络传输的内容，什么样的缓存（本地，本地 LRU，memcached 等），算法复杂性以及数据模式是什么。 我们很少涉及类和类结构或特定的代码。 而且，如果您想引进新技术，则需要同时做功课以及为什么不能使我们当前的技术适合您的用例。 + +是的，我们有时最终会在网站的不同部分出现“不同的设计”。 这并没有您想的那么糟糕，最后，我更喜欢为团队提供方法上的灵活性（在多年来已经确定的某些界限之内），尤其是考虑到团队需要真正感受到其工作的主人翁感。 此外，令人惊讶的是您从不同的方法中学到了什么。 + +嗨 Matlias， + +内容不会按语言划分，但是会按语言和 POS 来源进行标记。 + +Hi Andy, + +谢谢回答。 +我明白了，当您说“避免联接”时，您是在谈论数据库之间的联接，不同内容类型之间的联接，但是显然每个内容类型数据库内部都有很多表（包含所有标记为 POS，语言等）。 也就是说，在不同数据库之间进行联接非常昂贵，如果它们位于不同的计算机上，联接成本甚至更高。 +然后，由于使用的是 DRDB，因此可以在许多位置（也许是？）以多种语言提供内容，就像您所说的那样，它可以使您进行重复的热故障转移，同时可以减少对不同国家/地区的延迟，因为 您的服务器位置。 我对么？ + +Hi Andy, + +关于内容，您是否实施了一些用于更改数据的捕获？ 你能评论一下吗？ 知道您如何处理具有成千上万个项目（酒店，评论等）的内容版本化将非常有趣。 + +Best, + +Matias + +我认为允许进行一些不同的设计和代码复制是一个好主意。 否则，您将获得严格的标准，这将使您的应用程序/代码不再发展。 看到这发生在其他地方，这就是为什么我要说。 一旦规则变得比创造力，实时思考更重要，发展就不再与业务联系在一起。 + +此外，DRY 的难看面孔是强耦合。 国际海事组织的最佳选择总是介于极端之间。 \ No newline at end of file diff --git a/docs/69.md b/docs/69.md index 617953c..1cdcf9f 100644 --- a/docs/69.md +++ b/docs/69.md @@ -1,181 +1,65 @@ -# 在不到五分钟的时间里，Facebook 如何告诉您的朋友您在灾难中很安全 +# ATMCash 利用虚拟化实现安全性-不变性和还原 -> 原文： [http://highscalability.com/blog/2015/9/28/how-facebook-tells-your-friends-youre-safe-in-a-disaster-in.html](http://highscalability.com/blog/2015/9/28/how-facebook-tells-your-friends-youre-safe-in-a-disaster-in.html) +> 原文： [http://highscalability.com/blog/2011/7/11/atmcash-exploits-virtualization-for-security-immutability-an.html](http://highscalability.com/blog/2011/7/11/atmcash-exploits-virtualization-for-security-immutability-an.html) -![](img/85230d9f3f018016ed7b6b3de14d1500.png) +*这是 ATMCash 技术负责人 [Ran Grushkowsky](/cdn-cgi/l/email-protection#6210030c052203160f0103110a4c010d0f) 的来宾帖子。* -*这是文章更新： [Facebook 的安全检查如何进行](http://highscalability.com/blog/2015/11/14/how-facebooks-safety-check-works.html)。* +虚拟化和基于云的系统在业界非常受欢迎。 但是，大多数金融公司偏离了这些解决方案。 在 ATMCash，我们采用虚拟化的原因并非出于可扩展性的通常原因，而是出于通常错过的安全性价值。 -在灾难中，迫切需要立即了解您所爱的人的安全。 在 9/11 期间，我有这种感觉。 我知道在我们地区的下一场野火中，我会有这种感觉。 我生动地记得在 [1989 年洛马普里埃塔地震](https://en.wikipedia.org/wiki/1989_Loma_Prieta_earthquake) 期间的感觉。 +在本文中，我将介绍虚拟化利用中安全性增值的概念，以及为什么人们应该考虑为这些用例部署小型云。 -大多数地震都没有引起注意。 不是这个，每个人都知道。 在计算机实验室中，天花板不再像雪花一样飘落下来之后，我们确信建筑物不会倒塌，所有想法都转向了亲人的安全。 就像其他人必须拥有的一样。 拨打电话几乎是不可能的，因为电话从全国各地涌入湾区，所以所有电话线都很忙。 信息被卡住了。 由于电视显示出持续不断的死亡和破坏，许多无聊的时光被浪费了。 +## 虚拟机如何帮助减轻风险？ -25 年后的今天，我们还能做得更好吗？ +我敢肯定，您中的大多数人都听说过金融行业中最近发生的[黑客攻击。 金融公司一直在不断地进行黑客攻击，因此安全性至关重要。 系统部署中最大的风险之一是堆栈组件之一的损坏。 定期的系统修补程序和维护修复了已知的漏洞利用和问题，但是，有时可能为时已晚，并且该组件已被破坏。 如果系统已经在将补丁程序应用于现有系统的自然环境中遭到破坏，则有时补丁程序可能来得太迟，并且已经注入了特洛伊木马或某种恶意代码（如最近的案例所示） 。 虚拟机提供了一个伟大的隐藏宝藏：**不变性和还原映像**。](http://www.latimes.com/business/la-fi-citibank-hack-20110609,0,2504101.story) -Facebook 可以。 通过名为 [安全检查](https://www.facebook.com/about/safetycheck/) 的产品，该产品在灾难期间将亲朋好友联系在一起。 发生灾难时，“安全检查”会提示该地区的人员指示他们是否还可以。 然后，Facebook 通过告诉他们的朋友们如何做来结束担忧循环。 +## ATMCash 如何将这些功能用于堆栈中的安全性的示例： -[Facebook 工程师经理 Brian Sa](https://www.linkedin.com/pub/brian-sa/2/7a7/a3b) 根据 2011 年日本福岛 [毁灭性地震的经历创建了安全检查](http://www.telegraph.co.uk/news/worldnews/asia/japan/8953574/Japan-earthquake-tsunami-and-Fukushima-nuclear-disaster-2011-review.html) 。 他在@Scale 发表的演讲中讲述了自己的故事，这是他感人至深的故事。 +我们的堆栈包含三个主要组件：前端，后端和数据库。 -地震期间，布莱恩（Brian）在 Facebook 上张贴了一条标语，提供了有用的信息来源，但他被感动找到了一种更好的方式来帮助有需要的人。 那一刻成为安全检查。 +我们的机器正在运行 VMWare vSphere。 我们已经决定为前端组件安装 4gb / ram 64gb / SSD 服务器。 具有 16gb / ram 的更强大的服务器（用于我们的后端组件）以及具有用户 ID 分片和复制功能的专用 MySQL 数据库服务器。 我们的虚拟机正在运行 CentOS 的修改版本。 我们学会了以相对快速的修补周期和易于修改的配置来喜欢 CentOS。 -我对安全检查的第一反应是该死，为什么以前没有人想到这个？ 这是一个强大的主意。 +前端和后端是随每个版本更改的静态组件，而数据库是唯一随时更改的动态组件。 我们利用静态特征来增强我们的安全性，并消除感染后被感染的系统受到修补的风险。 -当我听 [相同视频](https://www.youtube.com/watch?v=ptsCWGZW_P8) 和 [Peter Cottle ]](https://www.linkedin.com/pub/peter-cottle/a/961/387) ，Facebook 的软件工程师，他还谈到了建筑安全检查。 +我们拥有尚未部署的每个系统组件的最新映像，但是会不断对其进行修补和更新以反映最新的安全风险。 然后，我们将对该映像进行任何软件更新，并用新更新和修补的映像替换运行中的映像。 通过安装负载平衡器，我们在整个过程中不会停机。 我们通过关闭一台计算机来逐一替换虚拟机，而负载平衡器将流量引向运行中的计算机，并重复该过程，直到所有虚拟机都被替换为止。 交换图像的过程通常每个过程少于 30 秒。 VMWare vSphere 具有一些强大的功能，这些功能使动态替换映像变得非常容易。 这是一个相对较快的重新部署过程。 -可能只有 Facebook 可以创建安全检查。 此观察与 Brian 在演讲中的主要课程很好地吻合： +## 我们如何使用不变性来提高安全性的示例： -* **以只有您可以** 的方式解决实际问题。 与其走传统路线，不如想想您和您的公司可以扮演的独特角色。 +在 ATMCash，我们的客户服务和呼叫中心在内部进行处理。 我们还将客户的安全和隐私视为最高优先事项。 为了进一步保护客户，我们开发了自己的 CSR（客户服务代表）系统，该系统利用了各种安全级别。 其中之一是虚拟机的不变性功能。 每个 CSR 工作站都在运行一个主 VM 映像的副本，该副本是不变的（无法修改，并且在每次重新引导后将被重置）。 -只有 Facebook 可以创建安全检查，不是因为您可能会想到资源，而是因为 Facebook 允许员工进行诸如安全检查之类的疯狂事情，并且因为只有 Facebook 拥有 15 亿地理分布的用户，而他们之间只有一定程度的分离 4.74 条优势，只有 Facebook 拥有狂热于阅读新闻源的用户。 稍后再详细介绍。 +以这种方式部署工作站可提供至关重要的安全级别，以保护我们的系统免受可能进入工作站的恶意代码的侵害。 如今，病毒和恶意脚本以各种方式传播。 从电子邮件附件到 Word 文档，它们无处不在。 如果您认为制定一项政策来指示员工不要从可移动驱动器中加载个人文档，或者甚至限制对社交网络的 Web 访问将消除这种风险，那么事实证明您是错误的。 您应始终假定恶意脚本会找到通往您工作站的路径，并且您的防病毒软件很可能不会检测到它。 使用每次重新启动都会重新启动的不可变映像，不仅提供了更高的安全性，而且还提供了应用补丁程序和在整个系统范围内更新（仅更新一个映像）的能力。 -实际上，Peter 在 Facebook 的产品开发 Catch-22 中谈到了资源是如何成为问题的。 安全检查小组很小，没有很多资源。 他们必须先构建产品并在没有资源的情况下证明其成功，然后才能获得构建产品的资源。 必须在不花费大量金钱和资源的情况下大规模有效地解决该问题。 +## 为什么 ATMCash 有自己的私有云而不使用现有的基础架构： -通常情况下，约束条件导致了一个明智的解决方案。 一个小的团队无法建立庞大的管道和索引，因此他们编写了一些骇人听闻的 PHP 并有效地大规模完成了这项工作。 +我们得到了很多问题，答案很简单。 我们从事货币业务，我们需要特别注意客户的信息。 这是真的; 部署自己的小型云的成本比利用任何现有基础架构要高得多，但是安全性的附加价值是无价的。 -那么 Facebook 如何建立安全检查？ 这是我对 Brian 和 Peter 的演讲的掩饰： +此外，借助戴尔和其他零件制造商提供的财务计划，如果您将付款分散到各处，则您只需支付云服务的费用即可。 价格比较：使用 Rackspace 拥有 10 台 4gb 和 200gb 上/下的 Linux 服务器，每月将花费$ 1804。 在您自己的微型云上使用戴尔服务器配置可比较的服务器，服务器硬件的费用为每月 105 美元，网络配件的费用为每月 400 美元，VMWare 许可的费用为 600 美元/月，数据中心费用可能有所不同，但大约为 400 美元/月。 -* 您可以将 Facebook 视为这种巨大的原始汤。 数十亿人使用 Facebook，随着时间的流逝，各种行为开始浮出水面，有些趋势在不断蔓延。 +最重要的是，您必须维护设置，并且任何可伸缩性都需要购买和设置更多节点。 $ 1505 /月，之前员工维持固定成本的费用略高，但是，特别是在安全方面所享有的收益不容错过。 - * 一个病毒性的例子是用户如何开始将自己的个人资料图片更新为红色的平等标志，以表示婚姻平等。 +## 发生停机时如何处理对帐问题？ - * 在支持下，Facebook 建立了 Rainbow 覆盖工具，使使用个人资料图片进行交流变得更加容易。 这种做法最早起源于 Facebook。 在发明状态消息之前，用户将更改其个人资料图片以传达其当前的时代精神。 +处理金融交易时，不能选择停机。 因此，虚拟化非常重要，而负载均衡器对于任何虚拟化环境都至关重要。 我们设计的系统具有极高的冗余性。 堆栈的每个部分都被复制并旨在处理停机时间。 我们在本地数据中心级别使用物理负载均衡器设备（也执行 SSL 握手）在 DNS 级别使用负载均衡器。 一旦一个组件发生故障，负载均衡器将自动将流量定向到其克隆节点。 - * 轻松自定义个人资料图片**的采用率提高了 1000 倍**。 +我们使用批处理更新执行大量数据处理，在此我们将重要更新作为增量更新，小的增量更新进行提交，从而无需更新整个数据集。 您只需更新所需的小更改。 例如，提款或大量资金需要立即在整个系统中进行更新以反映余额，但是，交易历史记录的优先级较低。 当在 ATM 级别上发生负载时，请求正在通过我们的系统，以确保交易有效。 -* 这使他们有了 **的概念，使人们在灾难中更容易告诉朋友他们还可以** 。 +交易获得批准后，我们​​将对前端数据库执行增量更新以反映该交易。 然后，我们将触发不同的过程，以警告客户该交易，更新其界面并执行安全性速度检查（检查以确保我们的客户卡的安全性不会被盗）。 - * 在灾难期间，人们会更新状态，说他们还可以。 +当大多数数据作为批处理时，系统将处理关键更新，例如增量更新。 批处理更新的本质是海量数据与增量更新的完整汇总，增量更新仅包含已修改的数据。 为确保整个系统中数据的完整性并允许更快的更新，我们将增量更新用于流水线更新和批处理更新，其中还包括更多对数据完整性检查而言不重要的数据。 迄今为止，由于批量更新不会阻塞系统，因此我们可以安全地使用增量更新来扩展规模，而不会影响系统的稳定性或性能。 - * 这不是让人们知道您还可以的问题的理想解决方案。 +## 总结一下： - * 它不是很结构化。 双向都有问题，告诉人们您没事的方向，而您的朋友得到您没事的信息。 +如果安全性是您业务中不可或缺的一部分，就像 ATMCash 处的业务一样，那么您应该利用虚拟机的附加安全性功能。 您将学习到它所提供的灵活性以及您的版本始终是“无恶意软件”的，让您高枕无忧。 - * 首先，不是所有的朋友都能看到此更新。 +关于公司： [ATMCash.com](http://atmcash.com/) 成立于 2005 年，是全球支付平台和在线汇款服务，服务于 150 多个国家/地区。 使用预付费借记卡代替了传统的基于第三方代理的模型和银行电汇。 没有银行帐户的接收者可以从全球超过 150 万台 ATM 机中提取资金。 [ATMCash.com](http://atmcash.com/) 通过为客户提供更多控制，省心和省钱的方式，改变了人们转移资金和向自由职业者付款的方式。 - * 第二，用户无法获取受灾难影响的所有朋友的名单。 +[](http://payment.atmcash.com/) - * 在灾难状态通知问题上应用更加结构化的思想导致 [安全检查](https://www.facebook.com/about/safetycheck/) 。 +Centos 和 VMWare 的安全性？ 请查看最近十年影响 VMWare 的漏洞列表，并且不要忘记研究 CentOS 开发人员社区的规模和内部流程。 +将结果与其他虚拟化系统和其他 Linux 发行版进行比较。 请。 -* 工作原理： +嘿，巨魔，你为什么不以那种傲慢，模棱两可的态度停下来，并谈谈具体细节。 显示影响 ESXi4.1 的单个报告的未修补 VMWare 漏洞 +与 CentOS / RedHat / Scientific / OEL 相同。 - * 如果您身处灾区，Facebook 会给您发送推送通知，询问您是否还可以。 （关于灾难发生的时间由谁决定什么也没说）。 +非常有趣，谢谢！ - * 轻按“我很安全”按钮表示您很安全。 - - * 通知所有朋友您安全。 - - * 朋友还可以查看受灾影响的所有人员及其生活状况的列表。 - -* 您如何在特定区域中建立受灾难影响的人员群体？ 建立地理索引是显而易见的解决方案，但是它有缺点。 - - * 人们在不断移动，因此索引会过时。 - - * 拥有 15 亿人口的地理索引非常庞大，并且会占用很多他们没有的资源。 请记住，这是一个很小的团队，没有大量资源来尝试实施解决方案。 - - * 该解决方案应该始终在发生事件时才起作用，而不是一直保持活动状态很少使用的数据管道。 这要求能够进行动态 **动态即时** 查询。 - -* 解决方案 **利用社交图的形状及其属性** 。 - - * 如果发生灾难，例如尼泊尔的地震，则在每个新闻提要负载 中都会打开 **安全检查钩。** - - * **人们检查其新闻提要时，挂钩将执行**。 如果检查新闻源的人不在尼泊尔，那么什么也不会发生。 - - * 当尼泊尔某人查看其新闻时，就是发生魔术的时候。 - - * 安全检查 **在社交网络上向所有好友** 狂热。 如果朋友在同一地区，则将发送推送通知，询问他们是否可以。 - - * **该过程保持递归重复** 。 对于在灾区找到的每个朋友，都会派出工作来检查他们的朋友。 通知根据需要发送。 - -* 实际上，该**溶液是** **非常有效的**。 因为该算法能很快地找到人，所以产品体验让人感到实时和即时。 例如，同一房间中的每个人似乎都会同时收到他们的通知。 为什么？ - - * 使用新闻提要会给用户提供**随机抽样，偏向于最活跃的用户** **和最多的朋友**。 并且它过滤掉不活动的用户，这是数十亿行不需要执行的计算。 - - * **图是密集且互连的** 。 [六度凯文·培根](https://en.wikipedia.org/wiki/Six_Degrees_of_Kevin_Bacon) 是错误的，至少在 Facebook 上是这样。 Facebook 的 15 亿用户中，任意两个用户之间的 **平均距离为 4.74 边缘** 。 抱歉，凯文。 拥有 15 亿用户，整个图表可在 5 跳内进行浏览。 通过遵循社交图谱可以有效地联系到大多数人。 - - * 使用社交图谱方法免费提供了 **许多并行性** 。 可以将好友分配给不同的计算机并进行并行处理。 他们的朋友一样，依此类推。 - -* **竞争条件成为问题的解决方案** 对解决方案的分布式性质造成了影响。 - - * 两个不同数据中心中的两台机器的用户与同一个人成为朋友。 这意味着要遍历两个边缘，最终会向同一个人发送两个通知。 - - * 认为这没什么大不了的，但实际上，用户发现在灾难情况下获得多个通知确实压力很大。 用户认为如果他们同时收到两个通知，他们一定会遇到麻烦。 而且，您也不希望与安全相关的项目在灾难中感到车祸。 - - * 数据库用于存储状态，因此只有一台计算机可以检查用户。 问题是当您有多个数据中心时，例如在欧洲一个在美国，一个在美国，则传播延迟使确定用户是否正在处理的时间过长。 - - * 为两层解决方案添加了内存中锁定结构。 检查内存中锁定，如果为用户设置了该位，则该用户的作业将中止。 - -* 最大的产品推出是针对尼泊尔地震。 - - * 在不到 5 分钟的时间内，邀请了 300 万人发表他们的身份。 尼泊尔的人口太多，因此要检查 10 亿行。 - - * **在大约 5 分钟内浏览了 Facebook 用户群的 2 / 3rd** 。 - -* 在构建安全检查的第一个版本时遇到一些问题。 - - * 台式机，移动网络和本机应用程序的碎片化在跨多个平台管理内容，功能和操作方面造成了极大的复杂性。 - - * 想要个性化需要手动编码的内容，该编码缓慢，乏味且容易出错。 - - * 当系统仅在紧急情况下处于开机状态时，很难判断它是否在紧急情况下可以正常工作。 - - * 那么，为了构建一个跨平台但仍然可以本地响应的系统，应该采用哪种客户端-服务器模型？ 如何包含动态内容？ 如何测试系统以确保其可靠性？ - -* 选择让服务器负责文本和图像以及配置信息。 客户端将预取数据，处理实时失效，并本地响应客户端事件。 - -* 实时失效。 - - * 每当您处理预取的数据时，务必指定该数据应何时过期。 例如，如果用户打开该应用程序并上传了一些数据，则他们关闭该应用程序并仅在几天后打开它。 如果上载的数据是选举公告，则如果选举通过，则用户不应看到该公告。 - - * TTL（生存时间）参数告诉客户端在需要刷新数据之前可以使用数据多长时间。 - - * 交互计数指示用户可以与数据交互多少次。 - - * 更多可选的过滤器，例如：remaining_battery_percentage，如果设备电量不足，它将告诉客户端不要向用户显示消息。 - -* 强制执行内容限制 - - * 指定文本中的最大行数不是一个好主意。 字符串翻译成其他语言时，可能会急剧增长。 - - * 不同的平台和设备具有不同的屏幕尺寸，因此一个固定的限制无效。 - - * 因此，请在服务器上定义内容长度限制，并内置一个缓冲区以应对较长的翻译。 - -* 动态内容 - - * 这样可以对安全检查消息进行个性化设置，例如在文本中插入用户名。 - - * 提出了一种语言，例如邮件合并，以指定诸如“危机名称”和“危机 URL”之类的替代词。 - -* 正缓存 - - * 您记得以前符合资格的单位 - - * 安全检查是与用户保持固定通信渠道的设备类型。 对于事件持续时间，没有视图限制。 如果在星期五将其打开，则将持续交付直到星期五将其关闭。 - - * 正向缓存有利于长期运行的单元，因为您无需评估任何单元的资格。 您确实需要检查缓存单元的资格，因为您不想显示它超出预期的时间。 - -* 负缓存 - - * 您记得没有单位合格的地方。 - - * 琥珀色警报是一次性消息。 这种类型的设备的负载曲线确实不同。 例如，如果它是在上午 8:50 开启的，那么在上午 9:00 之前它已经达到峰值投放，然后衰减很快。 一小时内达到了一半的人，三小时内几乎达到了所有目标受众。 - - * 负缓存有利于短期运行的单元，因为在大多数情况下，没有可显示的单元。 负缓存记住了这一事实。 - -* 黑暗发射 - - * 使用实时流量测试了系统，以发现意外问题。 使用了一个标志使它对用户隐藏，因此不会对用户造成影响。 - - * 运行测试 24 小时发现了一些意外问题。 产生社交句子的子系统之一的容量不足。 - -* 终止开关 - - * Facebook 由数百个联锁系统组成。 - - * 有时，在发生灾难性故障的情况下，您需要快速减轻负载。 - - * Kill 开关使您可以完全关闭整个系统。 您还可以杀死特定的应用程序版本或设备。 - -## 相关文章 - -* [上 reddit](https://www.reddit.com/r/tech/comments/3mq29e/how_facebook_tells_your_friends_youre_safe_in_a/) \ No newline at end of file +花旗银行《洛杉矶时报》的故事链接已断开。 他们可能将链接更改为此 http://www.latimes.com/business/la-fi-citigroup-hacking-20110617,0,1445324.story \ No newline at end of file diff --git a/docs/7.md b/docs/7.md index 6db859a..759652d 100644 --- a/docs/7.md +++ b/docs/7.md @@ -1,699 +1,122 @@ -# Netflix：按下 Play 会发生什么？ +# 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构 -> 原文： [http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html](http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html) +> 原文： [http://highscalability.com/blog/2007/7/30/build-an-infinitely-scalable-infrastructure-for-100-using-am.html](http://highscalability.com/blog/2007/7/30/build-an-infinitely-scalable-infrastructure-for-100-using-am.html) -![](img/6a3359436d64c01679e8b1e26e14e3c8.png) +您是否真的可以使用亚马逊的存储，网格和排队服务平台以不到 100 美元的价格创建无限扩展的基础架构？ 看起来如此，至少对于正确的应用而言。 亚马逊将重点介绍了使用核心外部服务来构建下一代网站的“自带滚动式”与“按点连接”方法的未来之战。 他们的论点很强烈。 使用 Amazon 的平台，您可以快速构建基础架构，否则这些基础架构将需要花费很长的时间才能实现，要创造大量的资金，并且需要大量的人来实施和维护。 但是，亚马逊不提供 SLA，因此您可以将皇冠上的宝石与您真正信任吗？ Facebook 最近以一套更全面的服务超越了亚马逊的愿景。 未来的战斗正在进行中。 -本文是我新书[中的一章，就像我 10 岁时一样解释云](https://smile.amazon.com/Explain-Cloud-Like-Im-10-ebook/dp/B0765C4SNR)。 第一版是专门为云新手编写的。 我进行了一些更新并添加了几章— *Netflix：按 Play 时会发生什么？* 和*什么是云计算？-*将其升级到比初学者高几个刻度。 我认为即使是经验丰富的人也可以从中受益。 +网站：http：//aws.amazon.com/ -我还在独立的 Kindle 电子书中创建了本文的某种扩展版本。 您可以在 [Netflix 上找到该电子书：按下 Play 会发生什么？](https://www.amazon.com/Netflix-What-Happens-When-Press-ebook/dp/B079ZKT9G8/) +## 信息来源 -因此，如果您正在寻找关于云的良好介绍或认识某个人，请看一下。 我想你会喜欢的。 我为结果感到非常自豪。 +* [幻灯片：构建高度可扩展的 Web 应用程序](http://www.slideshare.net/iwmw/building-highly-scalable-web-applications)* [播客：技术：亚马逊网络服务](http://www.itconversations.com/shows/detail1728.html)* [亚马逊服务主页](http://aws.amazon.com/)。 -我从几十个有时有些矛盾的资料中整理了这一章。 事实随着时间的流逝而变化，并且取决于谁在讲故事以及他们要针对的受众。 我试图创造尽可能连贯的叙述。 如果有任何错误，我很乐意修复。 请记住，本文不是技术性的深入探讨。 这是一篇大图文章。 例如，我什至没有提到*微服务*这个词：-) + ## 平台 -Netflix 似乎很简单。 按播放，视频就会神奇地出现。 容易吧？ 没那么多。 + * Amazon ECS（电子商务服务）* Amazon S3（简单存储服务）* Amazon SQS（简单排队服务）* Amazon EC2（网格服务）* 亚马逊网络搜索服务* 亚马逊弹性付款服务（Amazon FPS）* REST and SOAP Service Interfaces -![](img/b9d4051f956df6493e0a56c86dec7509.png) + ## 里面有什么？ -鉴于我们在*中的讨论，什么是云计算？ 在*一章中，您可能希望 Netflix 使用 AWS 来提供视频。 在 Netflix 应用程序中按新闻播放，存储在 S3 中的视频将通过 Internet 从 S3 直接流式传输到您的设备。 + ### 为什么要使用外部服务？ -完全明智的方法……以提供更小的服务。 + * Amazon 的服务取代了应用程序堆栈中的盒子，电线和磁盘驱动器。* 亚马逊花了十年时间和超过 10 亿美元开发了世界一流的 Web 服务，每天都有数百万的客户使用。 也许您可以利用自己的网站体验？* 关注客户。 如果 Web 开发不是要提供客户价值，则为 70％。 这是关于建立和管理数据中心的。 您最好将精力花在客户身上，而不是浪费精力。* 更快上市。 缩放很难。 当您专注于增加用户价值时，让其他人担心 + 。* 针对峰值负载进行设计非常昂贵。 因此，将固定成本变成可变成本。 假设您要处理来自 slashdot 或 digg 的高流量，或者您有很高的季节性需求，那么拥有适当的基础结构来处理这些负载是一笔高固定成本。 您可以在其他地方更好地使用这笔钱。 创建一个可以自动和 + 临时扩展资源以应对高峰需求的基础架构是很有意义的。* 高可靠性和可用性。 专用服务可能比您可以创建的服务更可靠。 它说“可能”，因为亚马逊未提供 SLA，因此您将无法获得任何保证。 这个想法是，亚马逊足够便宜且可靠，因此很少有故障是可以接受的。 此外，SLA 通常会在出现问题时退还一些钱，它们 + 并不能真正保证任何事情。* 这是便宜的 CDN。 亚马逊的存储网络可以服务于相对便宜的内容交付网络。 在 [减少您的网站的带宽使用情况](http://www.codinghorror.com/blog/archives/000807.html)中讨论了此选项。 这个想法是，仅经常下载一个简单的 [favicon.ico](http://www.hanselman.com/blog/FavIconicoCanBeABandwidthHog.aspx) + 文件就可以使用很大一部分带宽。 使用$ 3 /月的 S3 将 90％的带宽卸载到外部主机是一个不错的选择。 但是，没有 SLA 的 S3 不能被认为是正确的 CDN。 -但这根本不是 Netflix 的运作方式。 它比您想象的要复杂和有趣得多。 + ### 亚马逊 ECS（电子商务服务） -看看为什么我们来看看 2017 年一些令人印象深刻的 Netflix 统计数据。 + * 该服务公开了 Amazon 的产品数据和电子商务功能： + 有关所有 Amazon.com 产品的详细产品信息，访问产品图像，与产品相关的所有客户评论等。* 亚马逊产品定价过高。* 我发现这项服务令人失望。 如果您想在 Amazon 之上建立商店，这似乎很棒，但是我没有找到将自己的产品添加到商店的方法，因此我认为它通常没有用。 -* Netflix 拥有超过 1.1 亿订户。 -* Netflix 在 200 多个国家/地区运营。 -* Netflix 每季度的收入接近 30 亿美元。 -* Netflix 每季度增加超过 500 万新订户。 -* Netflix 每周播放超过 10 亿小时的视频。 相比之下，YouTube 每天流 10 亿小时的视频，而 Facebook 每天流 1.1 亿小时的视频。 -* Netflix 在 2017 年每天播放 2.5 亿小时的视频。 -* Netflix 占美国峰值互联网流量的 37％以上。 -* Netflix 计划在 2018 年在新内容上花费 70 亿美元。 + ### Amazon S3（简单存储服务） -**我们学到了什么？** + * 该服务将数据存储在 Amazon 的存储网络中。* 每个 GPB 每月$ .15 的存储空间* $ .01（1000 至 10000 个请求）。* 每 GB 数据传输$ .10-$ .17。* 服务是：快速，可靠，可扩展，冗余，分散。* 您可以具有每个对象的 URL。 这意味着您可以直接使用 URL 引用图像或其他文件，因此可以在网页中使用。* 典型用途：CDN 和备份存储。* 存储分配到多个位置，因此您可以进行一定程度的地理分布。 -Netflix 非常庞大。 他们是全球性的，拥有很多成员，播放很多视频，并且有很多钱。 + ### Amazon SQS（简单排队服务） -另一个相关的事实是 Netflix 是基于订阅的。 会员每月支付 Netflix 费用，并可随时取消。 当您按 play 在 Netflix 上放松时，效果会更好。 不高兴的成员退订。 + * 此服务提供用于存储消息的 Internet 规模排队服务。 分布式参与者将工作放在队列中，而将工作从队列中移出。* 每 1000 条邮件$ .10。* 每 GB 数据传输$ .10-$ .18。* 该服务是：可扩展，弹性，可靠，简单，安全。* 典型用途：集中式工作队列。 将作业放在队列中，不同的参与者可以弹出队列的工作并在获得 CPU 时间时对其进行处理。* 截至 2007 年，预期的邮件延迟为 2-10 秒。 这对于许多应用程序来说是可怕的，对于许多其他应用程序来说却并不坏。* 可扩展性的一部分。 有任何数量的生产者和消费者。 您不用担心。* Queues are spread across multiple machines and multiple data centers. -**我们要深入** + ### Amazon EC2（网格服务） -Netflix 是我们讨论过的所有想法的绝妙示例，这就是为什么本章比我们介绍的其他云服务要详细得多的原因。 + * 该服务可在云中提供可调整大小的计算能力。 它旨在使开发人员更容易进行 Web 规模的计算。* 基本上，您可以为 Linux 发行版创建 Xen 映像，然后将其上传到其“弹性计算云”中。 然后，您可以使用 API​​启动任意多个实例。* 典型用途：转码，音频工作，负载测试。* 对服务器的根级别访问以及对计算机的完全控制。* 可以按分钟放大和缩小。* 对于实时处理，一个批评是较慢的 CPU（1.75 Ghz Xeon）。 如果您的应用程序以线性比例编写，那么这可能不会成为问题。* EC2 实例不是持久性的，因此您无法在其中存储数据库。 您有一些本地存储，但是当实例消失时，它就会消失。* 启动和停止图像需要花费几分钟，因此并不是真正需要的图像。* You can add anything you want to an image. If you want a database you can add it in. -深入研究 Netflix 的一个重要原因是，他们可以提供比其他公司更多的信息。 + ### GigaVox 媒体示例网络规模架构 -Netflix 拥有*通信*作为核心[文化价值](https://www.slideshare.net/BarbaraGill3/netflix-culture-deck)。 Netflix 不仅仅符合其标准。 + * 您可以开始了解 Amazon 的服务如何协同工作。 假设您有大量的 MP2，希望将其转码为 MP3。 您将原始媒体存储到 S3 中，将工作请求放入 SQS 中，并使实例在 EC2 中运行以处理队列并执行转码，然后将结果存储回 S3 中。 这正是 GigaVox 所做的。* GigaVox 是一家播客公司。 + -他们获取原始录音并将它们说出来的内容从 MP2 转换为 MP3。 还执行许多其他代码转换。 + -然后，根据制作节目，将这些大块媒体组装在一起成为一种交付格式。 例如，旧的播客可以每晚更新最新的广告。 + -大规模执行此操作将需要大量昂贵的资源。* 使用 Amazon 的服务，GigaVox 可以获得地理上的冗余和故障转移，从而获得相对便宜的 CPU，带宽和存储费用， + 和带宽成本。 您没有盒子或电线。 无需管理数据中心。 而且您可以以较小的固定成本进行增长。* 消息在队列上带有时间戳。 如果消息在队列中等待的时间太长，则它们可以启动更多 EC2 映像。 您可以平衡成本。 您还可以在基于客户的优先级机制中分层。* 他们每个实例都有自己的消息队列，用于命令和控制。* 出于安全原因，他们通过 ftp 将文件上传到实例，而不是通过 S3。* 亚马逊云的所有带宽都是免费的。 这是使服务协同工作的重要业务考虑因素。* 另一组实例和队列负责组合交付的媒体。* 使 GigaVox 以较低的启动成本为客户提供价值。 -实际上，我要感谢 Netflix 如此开放的架构。 多年来，Netflix 就其运作方式进行了数百次演讲，并撰写了数百篇文章。 整个行业对此都更好。 + ## 得到教训 -在 Netflix 上进行大量详细介绍的另一个原因是 Netflix 令人着迷。 我们大多数人曾经一次或一次使用 Netflix。 谁会不喜欢在帘子后面偷看，看看是什么让 Netflix 滴答作响？ + * 建立或购买始终是一个艰难的决定。 如果某项服务无法正常工作，那么您可能会失去客户，并且您无能为力，其他人还会向其他人发送紧急电子邮件。 这是一种可怕的感觉。 但是，如果确实可行，那么您可能会领先于游戏。 如何选择？ 那会告诉:-) -**Netflix 在两个云中运行：AWS 和 Open Connect。** + * 构建虚拟化层，以便您可以在其他提供商可用时切换到该提供商，或者可以用自己的服务替换它。 如果他们厌倦了提供服务或性能下降，这可以减少您对亚马逊的依赖。 -Netflix 如何使会员满意？ 当然有了云。 实际上，Netflix 使用两种不同的云：AWS 和 Open Connect。 + * 作为一家使用 Amazon 服务的初创公司，这并不是什么大风险，因为您已经处于危险境地。 极低的启动成本可以缓解任何风险，而资金始终是初创企业的问题。 -两种云必须无缝协作才能提供无数小时的客户满意视频。 + * 在许多情况下，购买自己的专用服务器可能仍然是更好的方法，因为您可以获得更多的控制权，更低的延迟，并且相同的硬件可用于多种用途。 -**Netflix 的三个部分：客户端，后端，内容交付网络（CDN）。** + * 软件即服务是一个强大而实用的想法。 它改变了您构建软件的方式。 它迫使您围绕界面对软件进行分层。 并且一旦您的软件由接口组成，您将拥有可以轻松更换的松散耦合的组件。 如果您想为客户提供 API，那么您还具有平台 API 的基础。 最高的开发水平将使用您提供给客户的相同 API 来构建服务。 -您可以将 Netflix 分为三部分：客户端，后端和内容交付网络（CDN）。 + * 松散耦合的，基于消息的体系结构与服务接口相结合，使您可以考虑抽象层的多个层次。 您不必费解，这使您可以释放使用大型行为块来构建应用程序的方式。 -*客户端*是用于浏览和播放 Netflix 视频的任何设备上的用户界面。 它可能是 iPhone 上的应用程序，台式计算机上的网站，甚至是智能电视上的应用程序。 Netflix 控制着每个设备的每个客户端。 + * 为异步交互界面设计 UI 带来了一些挑战。 可能需要一段时间才能执行操作，那么您如何与用户交互以进行处理呢？ -在您按下*播放*之前发生的所有事情都发生在*后端*中，该后端在 AWS 中运行。 这包括准备所有新传入的视频以及处理来自所有应用程序，网站，电视和其他设备的请求。 + * 我本能地怀疑亚马逊能否交付。 但是，如果您遇到的问题类型正确，则确实可以使用 Amazon 服务廉价地完成很多工作。 -按下*播放*后发生的所有事情均由 Open Connect 处理。 Open Connect 是 Netflix 的自定义全球内容交付网络（CDN）。 Open Connect 将 Netflix 视频存储在世界各地。 当您按播放时，来自 Open Connect 的视频流将进入您的设备，并由客户端显示。 不用担心 我们稍后再讨论 CDN 的含义。 + ## 也可以看看 -有趣的是，在 Netflix，他们实际上并没有说*在视频*上大受欢迎，而是说*单击标题*上的开始。 每个行业都有自己的术语。 + * [Flickr](http://highscalability.com/flickr-architecture) 和 [YouTube](http://highscalability.com/youtube-architecture) 也处理服务级别 API。 -通过控制所有三个区域（客户端，后端，CDN），Netflix 已实现了完整的垂直整合。 + * [在 Amazon EC2 和 Amazon S3 上运行 Hadoop MapReduce](http://developer.amazonwebservices.com/connect/entry.jspa?externalID=873&categoryID=112) -Netflix 从始至终控制着您的视频观看体验。 这就是为什么当您从世界任何地方单击播放时，它都可以起作用的原因。 您可以在观看时可靠地获取要观看的内容。 +实用计算最终将成为现实且负担得起。 +小公司可以使用 Amazon，Hadoop 和 Hbase 与巨头竞争吗？ 实际上，甚至 Yahoo 最近都宣布了对 Hadoop 的支持：“展望未来，并思考大规模计算的经济如何继续改善，不难想象，在 Hadoop 和基于 Hadoop 的基础架构如此普遍的时代 LAMP（Linux，Apache，MySQL，Perl / PHP / Python）堆栈有助于推动 Web 的先前发展。” -让我们看看 Netflix 如何做到这一点。 +在此处阅读更多信息： [http://innowave.blogspot.com/2007/08/amazon-ec2-s3-hadoop-open-source.html](http://innowave.blogspot.com/2007/08/amazon-ec2-s3-hadoop-open-source.html) -## **在 2008 年，Netflix 开始转向 AWS** +没有“无限扩展”这样的东西。 完美的可伸缩性意味着，如果您将资源增加一倍，则无论从速度，容量还是所测量的任何方面，都将获得双倍的性能。 -Netflix 于 1998 年成立。起初，他们通过美国邮政服务公司租借了 DVD。 但是 Netflix 看到了未来的点播视频流。 +实际上，您拥有无限的资源并不能使您的应用程序无限扩展。 这只是意味着您可以忽略一些可伸缩性问题，例如收益递减。 -Netflix 在 2007 年推出了其点播流媒体服务，该服务使订户可以通过 Netflix 网站在个人计算机上或在各种受支持的平台上的 Netflix 软件（包括智能手机和平板电脑，数字媒体播放器，视频）流式传输电视连续剧和电影。 游戏机和智能电视。 +“在 2006 年 4 月开始的将近 7 个小时中，Amazon 的 S3 存储服务只返回了服务不可用的消息。该事件在 2007 年 1 月再次发生，破坏了 Amazon 99.99％的正常运行时间目标。” -就个人而言，点播视频流是未来，这似乎很明显。 是的。 我曾在几家尝试制作视频点播产品的初创公司工作。 他们失败了。 +（摘自 [http://flud.org/blog/2007/04/26/eradicating-service-outages-once-and-for-all/“](彻底消除服务中断， 它还提出了一种用于*真正*可扩展和不受干扰的系统的替代架构。） -Netflix 成功。 Netflix 的表现肯定不错，但是他们迟到了，这对他们有所帮助。 到 2007 年，互联网已经足够快且便宜，足以支持流视频服务。 以前从未如此。 快速，低成本的移动带宽的增加以及功能强大的移动设备（如智能手机和平板电脑）的推出，使任何人都可以随时随地以流媒体的方式更轻松，更便宜。 时间就是一切。 +单独使用 Amazon 应用程序如何扩展 500GB MySQL 数据库？ -## **Netflix 通过运行自己的数据中心开始** +我知道这不一定是您在这里所说的，但是对于大多数 Web 应用程序而言，扩展意味着更多的 Web /应用程序服务器和更多的数据库功能。 -EC2 只是在 2007 年才开始使用，大约与 Netflix 的流媒体服务启动的时间相同。 Netflix 不可能使用 EC2 来启动。 +我看到在 Amazon 上解决此问题的一种解决方案是每 10 分钟备份一次 MySQL 数据库。 这可能适用于 50mb 的数据库，但适用于 10GB 的数据库，更不用说 50-100GB 的数据库了？ -Netflix 建立了两个彼此相邻的数据中心。 他们经历了我们在前面几章中讨论过的所有问题。 +然后，当您的数据库集群出现故障时，您如何向您的用户解释说，您选择使用 Amazon“无限扩展”的最后几个小时丢失了价值数小时的数据？ -建立数据中心需要大量工作。 订购设备需要很长时间。 安装和使所有设备正常工作需要很长时间。 并且，一旦他们一切正常，它们将耗尽容量，整个过程必须重新开始。 +只是好奇-我会很乐意以某种方式解决这个问题。 -设备的交货期长，迫使 Netflix 采用所谓的*垂直缩放*策略。 Netflix 制作了在大型计算机上运行的大型程序。 这种方法称为构建*整体*。 一个程序可以完成所有工作。 +这仍然是早期技术-仍然太丰富和太慢。 当平均带宽突破 10mb / s，而每次使用的价格又下降了一个数量级时，我们将面临一场真正的革命。 在此之前，这些服务的市场有限。 -问题是，当您像 Netflix 一样快速成长时， 很难使整体可靠。 事实并非如此。 +本地存储是您要查找的选项，现已可用（截至本周）。 然后，您可以将本地副本备份到 s3。 -## **服务中断导致 Netflix 迁移到 AWS** +请记住，您不会为每个备份存储 10GB，而是存储更改增量，因此，实际上增量比您表示的要多得多。 -在 2008 年 8 月的三天内，由于数据库损坏，Netflix 无法运送 DVD。 这是不可接受的。 Netflix 必须做点什么。 +您可以构建按地理位置分布的多集群环境，并且构建涉及轮循（m / m / m-环形拓扑）或 m / s / s 甚至 m / m（ m / s / s 和 m / s / su 形拓扑）。 这些技术还处于起步阶段。 -建立数据中心的经验告诉 Netflix 一个重要的教训-他们不擅长建立数据中心。 +由于缺乏云故障转移，目前唯一不可能的情况是服务故障。 在 Amazon 的情况下，使 SOAP 服务终止并不意味着您的服务（必定）终止，而是意味着您无法按需扩展等，并且您不能进行更改，直到 SOAP 服务恢复为止。 -Netflix 擅长的是向其成员提供视频。 Netflix 宁愿集中精力于更好地提供视频，而不是擅长于构建数据中心。 建立数据中心并不是 Netflix 的竞争优势，而提供视频则是。 +由于 s3 复制，目前针对 Amazon 的现有解决方案可能内置 20-40 秒的延迟（s3 的性能可能会有所不同），但是本地存储可以在本地磁盘上排队，然后从那里进行备份 ，减少问题的影响（即使服务崩溃，本地存储也将保持不变）。 -当时，Netflix 决定迁移到 AWS。 AWS 刚刚成立，因此选择 AWS 是一个大胆的举措。 +希望能有所帮助。 它可以进行架构设计，而这个问题不再是秀场停止。 -Netflix 之所以选择 AWS，是因为它想要一个更可靠的基础架构。 Netflix 希望从其系统中消除任何单点故障。 AWS 提供了高度可靠的数据库，存储和冗余数据中心。 Netflix 想要云计算，因此不再需要构建大型的，不可靠的整体。 Netflix 希望在不构建自己的数据中心的情况下成为全球服务。 这些功能没有一个在其旧的数据中心中可用，甚至永远都不会。 +很明显，您不是财务专家。 当您超越“带宽/存储”比较，进入云计算的总运营成本时，我的分析一直显示高性能站点的总体成本降低了 5-7 倍（这是 Sun Microsystems VS Amazon 上的 A / B ，而且我相信 Sun 是最有效的解决方案，因为它们具有很高的 CPU 密度），而在最坏的情况下，我看到的是 2 比 1 的降低。 -Netflix 选择 AWS 的原因是，它不想做任何*无差别的繁重任务*。 无差别的繁重工作是必须要做的，但并不能为核心业务提供优质视频观看体验带来任何好处。 AWS 为 Netflix 进行了所有不可区分的繁重工作。 这使 Netflix 人专注于提供业务价值。 +第二个问题不受个人开发人员的考虑，但是对于使用基础结构的公司来说，它的主要问题是调配的速度。 云将应用程序的配置从数天，数周或数月转移到数小时，数分钟和数秒。 而且，从本质上讲，它们将为 SaaS 和其他企业技术提供复杂的应用程序（由于成本优势，所谓的“企业云”将兴起）。 -Netflix 花了八年多的时间才能完成从自己的数据中心到 AWS 的迁移过程。 在此期间，Netflix 的流媒体客户数量增长了八倍。 Netflix 现在可以在数十万个 EC2 实例上运行。 +IBM，VMWare，XEN，Microsoft，Google 和 Amazon 知道它还没有为“ Enterprise”做好准备，但是它很快就会成熟。 考虑 Forrester 报告（ [http://tinyurl.com/6s5qyc）](http://tinyurl.com/6s5qyc),)，其中显示： -## **Netflix 在 AWS 中更可靠** +云计算是否已为企业准备就绪？ +“还没有，但是这种破坏性的创新正在迅速成熟” -并不是说 Netflix 从来没有经历过 AWS 停机的情况，但是总的来说，它的服务比以前更加可靠。 - -您再也不会看到这种抱怨了： - -![](img/e27dea3ea51097872f122794c88247ee.png) - -或这个： - -![](img/eb80a1891c5aeb8ed8cc659fcad32d18.png) - -Netflix 之所以如此可靠，是因为他们已采取非常规步骤来确保其服务的可靠性。 - -Netflix 在三个 AWS 区域中运营：一个位于北弗吉尼亚州，一个位于俄勒冈州波特兰市和一个位于爱尔兰都柏林。 在每个区域内，Netflix 在三个不同的可用区中运营。 - -Netflix 表示没有计划在更多地区开展业务。 添加新区域非常昂贵且复杂。 大多数公司在一个地区开展业务，更不用说两个或三个了。 - -具有三个区域的优点是任何一个区域都可能发生故障，而其他区域将介入处理发生故障的区域中的所有成员。 当区域出现故障时，Netflix 将此*撤离*。 - -让我们举个例子。 假设您正在英国伦敦观看新的*纸牌屋*。 因为它距离伦敦最近，所以您的 Netflix 设备很可能已连接到都柏林地区。 - -如果整个都柏林地区失败了怎么办？ 这是否意味着 Netflix 应该停止为您服务？ 当然不是！ - -Netflix 检测到故障后，会将您重定向到弗吉尼亚。 您的设备现在可以与弗吉尼亚州地区通话，而不是都柏林通话。 您甚至可能没有注意到发生了故障。 - -AWS 区域多久发生一次故障？ 每月一次。 嗯，一个地区实际上并不是每个月都会失败。 Netflix 每月进行一次测试。 Netflix 每个月都会故意导致区域故障，以确保其系统可以处理区域级别的故障。 一个区域可以在六分钟内撤离。 - -Netflix 将其称为*全球服务模型*。 任何客户都可以在任何地区以外的地方服务。 这真太了不起了。 而且它不会自动发生。 AWS 无法处理区域故障或为多个区域的客户提供服务。 Netflix 独自完成了所有这些工作。 Netflix 是弄清楚如何使用多个区域创建可靠系统的先驱。 我不知道有其他公司会竭尽所能使他们的服务如此可靠。 - -在这三个地区中的另一个优势是，它使 Netflix 遍及全球。 Netflix 进行了一些测试，发现如果您在世界任何地方使用 Netflix 应用程序，都会从这三个地区之一获得快速服务。 - -## **Netflix 在 AWS 中省钱** - -这可能会让很多人感到惊讶，但是 AWS 比 Netflix 便宜。 每个流视图的云成本最终只是其旧数据中心成本的一小部分。 - -为什么？ 云的弹性。 - -Netflix 可以在需要时添加服务器，并在不需要时将其退还。 Netflix 不必拥有大量额外的计算机，只是为了处理高峰负载而无所事事，而仅在需要时才支付所需的费用。 - -我们在*中讨论的所有内容什么是云计算*？ 章节。 - -## **在按下 Play 之前，AWS 会发生什么？** - -任何不涉及提供视频的内容都将在 AWS 中处理。 - -这包括可伸缩计算，可伸缩存储，业务逻辑，可伸缩分布式数据库，大数据处理和分析，推荐，转码以及数百种其他功能。 - -不用担心，您不需要了解所有这些内容，但是由于您可能会发现它很有趣，因此我将对其进行简要说明。 - -**可扩展计算和可扩展存储。** - -*可伸缩计算*为 EC2，*可伸缩存储*为 S3。 在这里对我们来说没有什么新鲜的。 - -您的 Netflix 设备（iPhone，TV，Xbox，Android 手机，平板电脑等）与 EC2 中运行的 Netflix 服务进行对话。 - -查看可能要观看的视频列表？ 这就是您的 Netflix 设备正在与 EC2 中的计算机联系以获取列表。 - -询问有关视频的更多详细信息？ 这就是您的 Netflix 设备正在与 EC2 中的计算机联系以获取详细信息。 - -就像本书中提到的所有其他云服务一样。 - -**可扩展的分布式数据库。** - -Netflix 将 DynamoDB 和 Cassandra 都用于其分布式数据库。 这些名称对您而言并不意味着什么，它们只是高质量的数据库产品。 - -*数据库*。 数据库存储数据。 您的个人资料信息，帐单信息，您曾经看过的所有电影以及所有此类信息都存储在数据库中。 - -*已分发。* 分布式表示数据库不在一台大型计算机上运行，​​而是在多台计算机上运行。 您的数据将复制到多台计算机，因此，如果一台或什至两台保存数据的计算机发生故障，您的数据将是安全的。 实际上，您的数据已复制到所有三个区域。 这样，如果某个区域发生故障，那么当新区域准备开始使用它时，您的数据就会在那里。 - -*可扩展*。 可伸缩性意味着数据库可以处理您想要放入的尽可能多的数据。 这是分布式数据库的一大优势。 可以根据需要添加更多计算机以处理更多数据。 - -**大数据处理和分析。** - -*大数据*只是意味着有很多数据。 Netflix 收集了大量信息。 Netflix 知道每个人观看时都观看了什么，观看时所处的位置。 Netflix 知道成员观看了哪些视频，但决定不观看。 Netflix 知道每个视频被观看了多少次……还有更多。 - -将所有数据以标准格式放入称为*处理*。 - -理解所有这些数据称为*分析*。 分析数据以回答特定问题。 - -**Netflix 只为您个性化艺术品。** - -这是一个很好的例子，说明 Netflix 如何利用其数据分析功能吸引您观看更多视频。 - -在四处寻找在 Netflix 上观看的内容时，您是否注意到每个视频始终显示一个图像？ 这就是*标头图片*。 - -标题图片旨在吸引您，吸引您选择视频。 这个想法是标题图像越引人注目，您观看视频的可能性就越大。 而且，您观看的视频越多，您退订 Netflix 的可能性就越小。 - -这是*陌生事物*的不同标题图片的示例： - -![](img/bb281d98db0ebb33c7d2e11f52846f41.png) - -了解为每个视频专门选择的显示图像可能会让您感到惊讶。 并非所有人都看到相同的图像。 - -以前每个人都看到相同的标题图像。 运作方式如下。 成员从一组选项中随机显示一张图片，如上面 *Stranger Things* 拼贴中的图片。 Netflix 会在每次观看视频时进行计数，记录选择视频时显示的图片。 - -对于我们的*陌生事物*示例，假设显示了中央的合影时，*陌生事物*被观看了 1,000 次。 对于所有其他图片，每张只被观看了一次。 - -由于组图片是吸引成员观看的最佳方式，因此 Netflix 会使其永远成为 *Stranger Things* 的标题图像。 - -这称为*数据驱动*。 Netflix 以数据驱动公司而闻名。 在这种情况下，将收集数据（在这种情况下为与每张图片关联的视图数），并用于做出最佳决策（选择哪种标题图像）。 - -聪明，但您能想象做得更好吗？ 是的，通过使用更多数据。 这就是未来的主题-通过学习数据来解决问题。 - -你和我可能是截然不同的人。 您是否认为我们受到相同类型的标题图像的激励？ 可能不是。 我们有不同的口味。 我们有不同的偏好。 - -Netflix 也知道这一点。 因此，Netflix 现在可以个性化显示给您的所有图像。 Netflix 会尝试选择与您的视频最相关的艺术品。 他们是如何做到的？ - -请记住，Netflix 记录并统计您在其网站上所做的一切。 他们知道您最喜欢哪种电影，最喜欢哪些演员，等等。 - -假设您的建议之一是电影*善意狩猎*。 Netflix 必须选择标题图像才能显示给您。 目标是显示一张图像，让您了解可能感兴趣的电影。Netflix 应该向您显示哪张图像？ - -如果您喜欢喜剧，Netflix 会向您展示罗宾·威廉姆斯（Robin Williams）的图像。 如果您更喜欢浪漫电影，则 Netflix 会向您显示马特·达蒙（Mat Damon）和米妮·德米妮（Minnie Driver）准备亲吻的图像。 - -![](img/cfb549f0a6707cc5954d71140b5d282e.png) - -通过向罗宾·威廉姆斯（Robin Williams）展示，Netflix 使您知道电影中可能有幽默感，并且因为 Netflix 知道您喜欢喜剧，所以该视频非常适合。 - -Matt Damon 和 Minnie Driver 的图像传达了完全不同的信息。 如果您是喜剧迷并且看到了这张图片，则可以跳过。 - -这就是为什么选择正确的标题图片如此重要的原因。 它发送强烈的个性化信号，指示电影的内容。 - -这是另一个示例*低俗小说*。 - -![](img/d59d96ae3828b0a59384aa94296cbbf1.png) - -如果您看过很多由乌玛·瑟曼（Uma Thurman）主演的电影，那么您很可能会看到乌玛（Uma）的标题图片。 如果您看过很多由约翰·特拉沃尔塔（John Travolta）主演的电影，那么您很可能会看到约翰（John）的标题图片。 - -您能看到选择最佳个性化艺术品如何使您更有可能观看特定视频吗？ - -Netflix 在选择艺术品时会吸引您的兴趣，但 Netflix 也不想骗您。 他们不想显示 clickbait 图片只是为了让您观看您可能不喜欢的视频。 这没有任何动机。 Netflix 不按观看的视频付费。 Netflix 尝试将*的遗憾降到最低。 Netflix 希望您对观看的视频感到满意，因此他们会选择最适合您的标头图像。* - -这只是 Netflix 如何使用数据分析的一个小例子。 Netflix 到处都采用这种策略。 - -**建议。** - -Netflix 通常只会向您显示 40 到 50 个视频选项，但是它们有成千上万个视频可用。 - -Netflix 如何决定？ 使用机器学习。 - -这就是我们刚才讨论的*大数据处理和分析*的一部分。 Netflix 会查看其数据并预测您的需求。 实际上，您在 Netflix 屏幕上看到的所有内容都是使用机器学习专门为您选择的。 - -## **从源媒体到您所观看内容的转码** - -在这里，我们开始过渡到 Netflix 处理视频的方式。 - -Netflix 必须先将视频转换为最适合您的设备的格式，然后才能在您喜欢的所选设备上观看视频。 此过程称为*转码*或*编码*。 - -转码是将视频文件从一种格式转换为另一种格式，以使视频可以在不同平台和设备上观看的过程。 - -Netflix 一次将多达 300,000 个 CPU 的所有视频编码在 AWS 中。 比大多数超级计算机都大！ - -**源媒体的来源。** - -谁向 Netflix 发送视频？ 制作室和工作室。 Netflix 将此视频称为*源媒体*。 新视频将提供给*内容运营团队*进行处理。 - -该视频采用高清格式，大小为 TB 级。 TB 很大。 想象 60 叠像埃菲尔铁塔一样高的纸。 太太了。 - -在您观看视频之前，Netflix 会通过严格的多步骤过程对其进行处理。 - -![](img/8f33c24a44671cd5054d5919397be5d2.png) - -**验证视频。** - -Netflix 要做的第一件事是花费大量时间来验证视频。 它查找可能由先前的代码转换尝试或数据传输问题引起的数字伪像，颜色变化或丢失的帧。 - -如果发现任何问题，视频将被拒绝。 - -**进入媒体管道。** - -验证视频后，将其输入到 Netflix 所谓的*媒体管道*中。 - -*管道*只是一系列步骤，需要经过一系列步骤才能使数据准备就绪，就像工厂的流水线一样。 70 多种不同的软件可帮助您制作每个视频。 - -处理单个多 TB 大小的文件是不切实际的，因此，管道的第一步是将视频分成许多较小的块。 - -然后将视频块通过管道放置，以便可以并行对其进行编码。 并行仅表示在同一时间处理块。 - -让我们用一个例子来说明并行性。 - -![](img/b28fc97bf91bbf4b14de00e2b47f98c5.png) - -假设您有一百只需要洗的脏狗。 一个人一个接一个地洗狗，哪个会更快？ 还是租用一百个洗狗器同时洗一次会更快？ - -显然，同时使用一百只狗狗洗衣机更快。 那是并行性。 这就是 Netflix 在 EC2 中使用如此多服务器的原因。 他们需要大量服务器来并行处理这些巨大的视频文件。 它也可以。 Netflix 表示，可以在短短 30 分钟之内对源媒体文件进行编码并将其推送到 CDN。 - -编码后，将对它们进行验证，以确保没有引入新的问题。 - -然后将这些块组装回一个文件中，并再次进行验证。 - -**结果是一堆文件。** - -编码过程会创建很多文件。 为什么？ Netflix 的最终目标是支持每台联网设备。 - -Netflix 于 2007 年开始在 Microsoft Windows 上流式传输视频。 随着时间的推移，增加了更多设备-Roku，LG，三星蓝光，Apple Mac，Xbox 360，LG DTV，Sony PS3，Nintendo Wii，Apple iPad，Apple iPhone，Apple TV，Android，Kindle Fire 和 Comcast X1。 - -Netflix 总共支持 2200 种不同的设备。 每个设备都具有在该特定设备上看起来最佳的视频格式。 如果您在 iPhone 上观看 Netflix，则会看到一个视频，该视频可为您提供最佳的 iPhone 观看体验。 - -Netflix 将视频的所有不同格式称为*编码配置文件*。 - -Netflix 还创建针对不同网络速度优化的文件。 如果您在快速网络上观看，则观看的视频质量会比在慢速网络上观看时的观看质量更高。 - -也有用于不同音频格式的文件。 音频被编码为不同质量级别和不同语言。 - -也包括字幕文件。 视频可能具有多种不同语言的字幕。 - -每个视频都有很多不同的观看选项。 您看到的内容取决于您的设备，网络质量，Netflix 计划以及您的语言选择。 - -**我们正在讨论多少文件？** - -对于 *The Crown，* Netflix 存储了约 1200 个文件！ - -*陌生人事物*第 2 季有更多文件。 它以 8K 拍摄，有 9 集。 源视频文件有很多太字节的数据。 仅编码一个季节就花费了 190,000 个 CPU 小时。 - -结果？ 9,570 种不同的视频，音频和文本文件！ - -让我们看看 Netflix 如何播放所有视频。 - -## **三种不同的流媒体视频策略** - -Netflix 尝试了自己的小型 CDN 三种不同的视频流策略； 第三方 CDN； 和打开连接。 - -首先定义 CDN。 CDN 是*内容分发网络*。 - -Netflix 的*内容*当然是我们在上一节中讨论的视频文件。 - -*分发*表示视频文件是通过*网络*从中央位置复制的，并存储在世界各地的计算机上。 - -对于 Netflix，存储视频的中心位置是 S3。 - -## **为什么要建立 CDN？** - -CDN 背后的想法很简单：通过在全球范围内传播计算机，使视频尽可能接近用户。 当用户想要观看视频时，请找到带有视频的最近的计算机，然后从那里流式传输到设备。 - -CDN 的最大好处是速度和可靠性。 - -想象一下，您正在伦敦观看视频，并且该视频是从俄勒冈州波特兰市流传输的。 视频流必须通过许多网络，包括海底电缆，因此连接速度慢且不可靠。 - -通过将视频内容尽可能靠近观看者移动，观看体验将尽可能快且可靠。 - -具有存储视频内容的计算机的每个位置称为 PoP 或*存在点*。 每个 PoP 都是提供访问 Internet 的物理位置。 它容纳服务器，路由器和其他电信设备。 稍后我们将详细讨论 PoP。 - -## **第一个 CDN 太小** - -2007 年，当 Netflix 首次推出其新的流媒体服务时，它在 50 个国家/地区拥有 3600 万会员，每月观看超过十亿小时的视频，每秒流式传输数 TB 的内容。 - -为了支持流媒体服务，Netflix 在美国的五个不同位置构建了自己的简单 CDN。 - -当时，Netflix 视频目录足够小，每个位置都包含其所有内容。 - -## **第二个 CDN 太大** - -在 2009 年，Netflix 决定使用第三方 CDN。 大约在这个时候，第三方 CDN 的价格下降了。 - -对于 Netflix，使用第三方 CDN 非常合理。 当您可以使用现有的 CDN 服务立即到达全球时，为什么还要花费所有时间和精力来构建自己的 CDN？ - -Netflix 与 Akamai，Limelight 和 Level 3 等公司签订了合同，提供 CDN 服务。 使用第三方 CDN 没错。 实际上，几乎每个公司都这样做。 例如，NFL 使用 Akamai 直播足球比赛。 - -通过不构建自己的 CDN，Netflix 有更多时间来从事其他更高优先级的项目。 - -Netflix 在开发更智能的客户端上投入了大量时间和精力。 Netflix 创建了适应不断变化的网络条件的算法。 即使面对错误，网络过载和服务器过载，Netflix 仍希望成员始终查看最佳图像。 Netflix 开发的一种技术是切换到另一个视频源（例如另一个 CDN 或另一个服务器），以获得更好的效果。 - -同时，Netflix 还为我们之前提到的所有 AWS 服务投入了大量精力。 Netflix 将 AWS 中的服务称为*控制平面*。 控制平面是一个电信术语，用于标识控制其他所有部分的系统部分。 在你的身体里，你的大脑是控制平面。 它控制着其他一切。 - -然后，Netflix 认为通过开发自己的 CDN 可以做得更好。 - -## **开放式连接正好** - -在 2011 年，Netflix 意识到需要大规模的 CDN 解决方案以最大化网络效率。 视频分发是 Netflix 的核心竞争力，并且可能是巨大的竞争优势。 - -因此，Netflix 开始开发自己的专用 CDN Open Connect。 Open Connect 于 2012 年推出。 - -Open Connect 对于 Netflix 具有很多优势： - -* 不会那么贵。 第三方 CDN 昂贵。 自己做可以节省很多钱。 -* 更好的质量。 通过控制整个视频路径（代码转换，CDN，设备上的客户端），Netflix 认为它可以提供出色的视频观看体验。 -* 更可扩展。 Netflix 的目标是在世界各地提供服务。 快速提供支持，同时提供高质量的视频观看体验，这需要构建自己的系统。 - -第三方 CDN 必须支持用户从世界任何地方访问任何种类的内容。 Netflix 的工作要简单得多。 - -Netflix 确切知道其用户是谁，因为他们必须订阅 Netflix。 Netflix 确切知道需要提供哪些视频。 知道它只需要提供大量视频流，就可以让 Netflix 做出许多其他 CDN 无法做出的明智优化选择。 Netflix 也对会员了解很多。 该公司知道他们喜欢观看哪些视频以及何时观看。 - -有了这种知识，Netflix 就构建了一个非常出色的 CDN。 让我们详细了解 Open Connect 的工作原理。 - -## **开放式连接设备** - -还记得我们怎么说 CDN 的计算机遍布全球吗？ - -Netflix 开发了自己的视频存储计算机系统。 Netflix 称它们为 Open Connect 设备或 OCA。 - -这是在站点中早期安装 OCA 的样子： - -![](img/16f51c928a8c1dfaa02465da7b9a1d58.png) - -上图中有许多 OCA。 OCA 分为多个服务器的群集。 - -每个 OCA 都是一台快速服务器，经过高度优化，可传送大文件，并带有大量用于存储视频的硬盘或闪存驱动器。 - -以下是一台 OCA 服务器的外观： - -![](img/002abec7cdc33524f8bfe96565fe689f.png) - -有几种不同类型的 OCA 用于不同目的。 有大型 OCA 可以存储 Netflix 的整个视频目录。 有较小的 OCA，它们只能存储 Netflix 视频目录的一部分。 小型的 OCA 每天在非高峰时段都通过 Netflix 调用*主动 cachin* g 的过程填充视频。 稍后，我们将详细讨论主动缓存的工作原理。 - -从硬件的角度来看，OCA 没有什么特别的。 它们基于商用 PC 组件，并由各种供应商在定制情况下组装。 如果需要，您可以购买相同的计算机。 - -请注意，所有 Netflix 的计算机都是红色的吗？ Netflix 的计算机经过专门设计以匹配其徽标颜色。 - -从软件角度看，OCA 使用 FreeBSD 操作系统和 NGINX 作为 Web 服务器。 是的，每个 OCA 都有一个 Web 服务器。 使用 NGINX 的视频流。 如果这些名称都没有意义，请放心，我只是为了完整性而将它们包括在内。 - -站点上的 OCA 数量取决于 Netflix 希望站点的可靠性，从该站点传递的 Netflix 流量（带宽）的数量以及站点允许流式传输的流量的百分比。 - -当您按下播放键时，您正在观看附近特定位置来自特定 OCA 的视频流。 - -为了获得最佳的视频观看体验，Netflix 真正想要做的就是将视频缓存在您的房屋中。 但这还不可行。 其次，最好是将迷你 Netflix 尽可能靠近您的房屋放置。 他们是如何做到的？ - -## **Netflix 将 Open Connect Appliances（OCA）放在哪里？** - -Netflix 从全球 1000 多个位置的数千台服务器提供大量视频流量。 看看这张视频投放位置的地图： - -![](img/f05b05fbe69b129c9a82653b9bf65370.png) - -YouTube 和 Amazon 等其他视频服务在其自己的骨干网络上交付视频。 这些公司从字面上构建了自己的全球网络，用于向用户交付视频。 这是非常复杂且非常昂贵的。 - -Netflix 采用了完全不同的方法来构建其 CDN。 - -Netflix 不运营自己的网络； 它也不再运行自己的数据中心。 相反，互联网服务提供商（ISP）同意将 OCA 放入其数据中心。 OCA 是免费提供给 ISP 的，以嵌入其网络。 Netflix 还将 OCA 放置在互联网交换位置（IXP）中或附近。 - -使用这种策略，Netflix 不需要操作自己的数据中心，但是它获得了仅在其他人的数据中心中的常规数据中心的所有好处。 天才！ - -最后两段内容非常密集，因此我们将其分解。 - -**使用 ISP 来构建 CDN。** - -ISP 是您的互联网提供商。 您是从谁那里获得互联网服务的。 它可能是 Verizon，Comcast 或数千种其他服务。 - -这里的要点是 ISP 位于世界各地，并且与客户关系密切。 通过将 OCA 放置在 ISP 数据中心中，Netflix 也遍布全球，并且与客户关系密切。 - -**使用 IXP 构建 CDN。** - -Internet 交换位置是 ISP 和 CDN 在其网络之间交换 Internet 流量的数据中心。 就像参加聚会与您的朋友交换圣诞节礼物一样。 如果每个人都在一个地方，则交换礼物更容易。 如果每个人都在一个地方，则交换网络流量会更容易。 - -IXP 位于世界各地： - -![](img/46644609ddc19a440c5cdc9abd8c40b0.png) - -*TeleGeography 的 Internet 交换图* - -伦敦互联网交易所的外观如下： - -![](img/610a3afc1eed0b08497739c99c9a30cd.png) - -*伦敦互联网交换所（LINX）* - -深入查看那些黄色的光缆，您将在荷兰阿姆斯特丹的 AMS-IX Internet 交换点看到类似的内容： - -![](img/bec41838bb4817de47c185284cec94e7.png) - -*Wikimedia Commons* - -上图中的每条导线将一个网络连接到另一个网络。 这就是不同的网络相互交换流量的方式。 - -IXP 就像高速公路的立交桥，仅使用电线： - -![](img/149f9e40165ba99f24097eb897306995.png) - -*Wikimedia Commons* - -对于 Netflix 而言，这是另一个胜利。 IXP 遍布全球。 因此，通过将其 OCA 放入 IXP 中，Netflix 不必运行自己的数据中心。 - -## **每天都会主动将视频缓存到 OCA** - -Netflix 的所有视频都位于 S3 中。 他们拥有所有这些视频服务计算机，分布在世界各地。 只缺少一件事：视频！ - -Netflix 使用它称为*主动缓存*的过程来有效地将视频复制到 OCA。 - -**什么是缓存？** - -藏匿处是藏有弹药，食物和宝藏的地方，尤其是地下藏身的地方。 - -你知道冬天松鼠会埋坚果吗？ - -![](img/0cf00e4e5c31eec5dbcecf3d6249356f.png) - -他们埋没螺母的每个位置都是*缓存*。 在冬季，任何松鼠都可以找到坚果藏起来并砍掉。 - -北极探险者派小队向前走，沿着他们走的路线储存食物，燃料和其他物资。 后面的较大团队将在每个缓存位置停止并重新供应。 - -松鼠和北极探险家都*活跃*； 他们提前做一些事情，为以后做准备。 - -每个 OCA 都是您最有可能希望观看的视频的视频缓存。 - -**Netflix 通过预测您想要观看的内容来缓存视频。** - -Netflix 在世界任何地方都非常准确地知道其会员喜欢观看什么以及何时观看。 还记得我们曾说过 Netflix 是一家数据驱动公司吗？ - -Netflix 使用其受欢迎程度数据来*预测*成员明天可能希望在每个位置观看的视频。 在此，*位置*表示容纳在 ISP 或 IXP 中的 OCA 集群。 - -Netflix 将预测的视频复制到每个位置的一个或多个 OCA。 这称为*前置*。 视频甚至可以在任何人问到之前放在 OCA 上。 - -这为会员提供了很棒的服务。 他们想要观看的视频已经接近他们，可以进行流式传输了。 - -Netflix 运行所谓的*分层缓存系统。* - -![](img/aae5cd8bf6da74a03477b4761653228e.png) - -我们之前讨论的较小的 OCA 位于 ISP 和 IXP 中。 这些文件太小，无法包含整个 Netflix 视频目录。 其他位置的 OCA 包含 Netflix 大部分视频目录。 尽管如此，其他位置仍具有包含整个 Netflix 目录的大型 OCA。 这些都是从 S3 获得他们的视频。 - -每天晚上，每个 OCA 都会醒来，并向 AWS 的服务询问应包含哪些视频。 AWS 的服务根据我们之前提到的预测向 OCA 发送了应该包含的视频列表。 - -每个 OCA 都负责确保列表中包含所有视频。 如果位于同一位置的 OCA 拥有应有的视频之一，则它将复制本地 OCA 的视频。 否则，将找到并复制带有视频的附近 OCA。 - -由于 Netflix 预测明天会流行什么，因此通常需要一天的时间才能将视频放到 OCA 上。 这意味着可以在安静的非高峰时段复制视频，从而大大减少了 ISP 的带宽使用。 - -Open Connect 中永远不会出现*缓存未命中*的情况。 高速缓存未命中将要求 OCA 提供特定的视频，而 OCA 则说它没有该视频。 高速缓存未命中总是在其他 CDN 上发生，因为您无力将内容复制到任何地方。 由于 Netflix 知道必须缓存的所有视频，因此它始终知道每个视频的确切位置。 如果较小的 OCA 没有视频，则始终可以保证其中一个较大的 OCA 具有视频。 - -Netflix 为什么不将他们的所有视频复制到世界上每个 OCA？ 其视频目录太大，无法在所有位置存储所有内容。 2013 年，Netflix 的视频目录超过 3 PB。 我不知道今天有多大，但我只能假设它很大。 - -这就是为什么 Netflix 开发了一种方法，该方法使用*预测*他们的会员想要观看的数据，选择在每个 OCA 上存储哪些视频。 - -让我们举个例子。 *纸牌屋*是一个非常受欢迎的节目。 应该将其复制到哪些 OCA？ 可能是每个地点，因为全世界的成员都想观看纸牌屋。 - -如果视频不像《纸牌屋》那么受欢迎怎么办？ Netflix 决定应将其复制到哪个位置，以最好地满足附近的会员请求。 - -在一个地点中，像《纸牌屋》这样的热门视频被复制到许多不同的 OCA 中。 视频越受欢迎，它将被复制到更多的服务器。 为什么？ 如果只有一个非常受欢迎的视频的副本，则将视频流传输给成员将使服务器不堪重负。 正如他们所说，许多指针可以使灯工作。 - -将视频仅复制到一个 OCA 时，该视频不会被视为实时视频。 Netflix 希望能够在世界各地同时播放相同的内容。 仅当有足够数量的 OCA，且具有足够的视频副本以适当地提供它时，该视频才被视为直播且可供成员观看。 - -例如，2016 年 *Daredevil* 第 2 季是 Netflix 首次同时在所有国家/地区的所有设备上放映该节目的所有剧集。 - -## **托管 OCA：ISP 中有哪些内容？** - -ISP 为什么会同意将 OCA 群集放入其网络中？ 乍一看，它看起来过于宽大，但是您会很高兴知道它根植于自身利益。 - -要了解原因，我们需要讨论网络的工作方式。 我知道在整本书中我们都说过可以通过互联网访问云服务。 Netflix 并非如此，至少在观看视频时如此。 使用 Netflix App 时，它通过互联网与 AWS 对话。 - -互联网是网络的互连。 您有提供 Internet 服务的 ISP。 我从康卡斯特获得了互联网服务。 那意味着我的房子使用光缆连接到康卡斯特的网络。 Comcast 的网络就是他们的网络； 不是互联网，而是互联网。 - -假设我要进行 Google 搜索，然后在浏览器中输入查询，然后按 Enter。 - -我对 Google 的请求首先通过 Comcast 的网络传输。 Google 不在 Comcast 的网络上。 在某些时候，我的请求必须转到 Google 的网络。 这就是互联网的目的。 - -互联网将 Comcast 的网络连接到 Google 的网络。 这些被称为*路由协议*的事物的行为类似于流量警察，指示网络流量的去向。 - -当我的 Google 查询路由到互联网时，它不再位于 Comcast 的网络上，也不再位于 Google 的网络上。 它位于*互联网主干网*上。 - -互联网由许多选择互操作的私有网络组成。 我们前面介绍的 IXP 是网络相互连接的一种方式。 - -在美国，这是远程光纤网络的地图： - -![](img/764f6ce2c3075b2d60fe480c95a427f9.png) - -*InterTubes：对美国远程光纤基础设施的研究* - -Netflix 对 Open Connect 所做的工作是将其 OCA 群集放置在 ISP 网络内。 这意味着，如果我观看 Netflix 视频，我将与 Comcast 网络中的 OCA 交谈。 我所有的视频流量都在 Comcast 的网络上； 它永远不会上网。 - -扩展视频传输的关键是尽可能接近用户。 执行此操作时，您不会使用 Internet 主干。 在网络的本地部分上满足请求。 - -为什么这是一件好事？ 回想一下，我们说 Netflix 已经消耗了美国 37％以上的互联网流量。 如果 ISP 不合作，Netflix 将使用更多的互联网。 互联网无法处理所有视频流量。 ISP 必须增加更多的网络容量，而这是昂贵的。 - -目前，ISP 网络中最多可提供 Netflix 内容的 100％。 通过减轻 ISP 的互联网拥塞，可以降低成本。 同时，Netflix 会员体验到高质量的观看体验。 网络性能为每个人提高。 - -这是双赢。 - -## **开放连接可靠且具有弹性** - -之前我们讨论了 Netflix 如何通过耗尽三个不同的 AWS 区域来提高其系统的可靠性。 Open Connect 的体系结构实现了相同的目标。 - -可能不是立即显而易见的是，OCA 彼此独立。 OCA 充当自给自足的视频服务群岛。 当其他 OCA 发生故障时，从一个 OCA 流式传输的成员不会受到影响。 - -OCA 失败时会发生什么？ 您使用的 Netflix 客户端会立即切换到另一个 OCA，并恢复流式传输。 - -如果一个地点有太多人使用 OCA，该怎么办？ Netflix 客户端将发现要使用的负载更轻的 OCA。 - -如果成员用来流视频的网络过载了怎么办？ 同样的事情。 Netflix 客户端将在性能更好的网络上找到另一个 OCA。 - -Open Connect 是一个非常可靠且具有弹性的系统。 - -## **Netflix 控制客户端** - -Netflix 可以优雅地处理故障，因为它可以控制运行 Netflix 的每台设备上的客户端。 - -Netflix 自己开发 Android 和 iOS 应用程序，因此您可能希望它们来控制它们。 但是，即使在像 Netflix 这样没有构建客户端的智能电视这样的平台上，Netflix 仍然可以控制它，因为它可以控制*软件开发套件*（SDK）。 - -SDK 是*，一组允许开发应用程序的软件开发工具。* 每个 Netflix 应用都向 AWS 发出请求，并使用 SDK 播放视频。 - -通过控制 SDK，Netflix 可以一致且透明地适应慢速网络，失败的 OCA 以及可能出现的任何其他问题。 - -## **最后：这是您按 Play 时会发生的情况** - -到达这里很漫长。 我们学到了很多。 到目前为止，这是我们学到的知识： - -* Netflix 可以分为三个部分：后端，客户端和 CDN。 -* 来自 Netflix 客户端的所有请求均在 AWS 中处理。 -* 所有视频均来自 Open Connect CDN 中附近的 Open Connect 设备（OCA）。 -* Netflix 在三个 AWS 区域之外运营，通常可以处理任何区域的故障，甚至无需成员注意。 -* Netflix 将新的视频内容转换为多种格式，因此可以根据设备类型，网络质量，地理位置和会员的订阅计划选择最佳格式进行观看。 -* Netflix 每天都会通过 Open Connect，根据他们预测每个位置的会员想要观看的内容在世界各地分发视频。 - -这是 Netflix 如何描述播放过程的图片： - -[ ![](img/a74b8e62b0637c0ce6ea63384200af1b.png) - -现在，让我们完成图片： - -* 您选择要在某些设备上运行的客户端观看的视频。 客户端向在 AWS 中运行的 Netflix 的*回放应用*服务发送*播放*请求，指示您要播放哪个视频。 -* 我们之前没有讨论过，但是在您上演之后发生的大部分事情都与许可有关。 并非世界上每个地方都有观看每个视频的许可证。 Netflix 必须确定您是否具有观看特定视频的有效许可证。 我们不会谈论它是如何工作的-这确实很无聊-但请记住，它一直在发生。 Netflix 开始开发自己的内容的原因之一是避免许可问题。 Netflix 希望同时向全球所有人放映节目。 创建自己的内容是 Netflix 避免担心许可问题的最简单方法。 -* 考虑到所有相关信息，Playback Apps 服务将返回最多十个不同 OCA 服务器的 URL。 这些是您一直在 Web 浏览器中使用的相同 URL。 Netflix 使用您的 IP 地址和来自 ISP 的信息来确定最适合您使用的 OCA 群集。 -* 客户端可以智能地选择要使用的 OCA。 它通过测试与每个 OCA 的网络连接的质量来做到这一点。 它将首先连接到最快，最可靠的 OCA。 客户端会在整个视频流传输过程中继续运行这些测试。 -* 客户端进行调查以找出从 OCA 接收内容的最佳方法。 -* 客户端连接到 OCA，然后开始将视频流式传输到您的设备。 -* 您是否在观看视频时注意到图像质量有所不同？ 有时看起来像是像素化，过了一会儿图像又恢复为高清画质了吗？ 那是因为客户正在适应网络质量。 如果网络质量下降，客户端将降低视频质量以使其匹配。 当质量下降太多时，客户端将切换到另一个 OCA。 - -当您在 Netflix 上按播放时，就会发生这种情况。 谁会想到这么简单的事情，就像观看视频那么复杂？ - -## 相关文章 - -* [在 HackerNews](https://news.ycombinator.com/item?id=15901967) 和[在 HackerNews](https://news.ycombinator.com/item?id=15986753) -* [在 Reddit 上](https://www.reddit.com/r/tech/comments/7j6j99/netflix_what_happens_when_you_press_play/)和[在 Reddit 上](https://www.reddit.com/r/programming/comments/7m1aug/netflix_what_happens_when_you_press_play_high/) - -很好的文章！ - -但是封面选择信息已经过时：https：//medium.com/netflix-techblog/artwork-personalization-c589f074ad76 - -在完成本章后，Netflix 如何粗鲁地改变事情:-) - -看起来是一个很大的变化。 他们不是为所有人选择一张图像，而是对其进行个性化设置。 整 rick - -优秀文章，谢谢 - -感谢您的博客文章，我从开始乞讨到结束 - -我更新了帖子以反映新的标题图像选择信息。 对我而言，最有趣的是选择点击诱饵图像和在给定用户偏好和视频性质的情况下具有实际意义的图像之间的区别。 假设选择正确，该图像将成为快速的个性化滤镜。 - -这是一个非常有趣的阅读。 他们在客户端使用什么技术？ 有什么特别的框架吗？ 有什么特别的方法可以使他们显示 x 个视频而不会导致客户端变慢？ - -很棒的帖子。 感谢您抽出宝贵的时间来撰写本文。 大概念以非常易于理解的格式传达。 - -优秀的职位。 用非常容易理解的单词和有趣的内容进行解释。 - -一个真正的问题-如果 Netflix 占峰值互联网流量的 37％，而 YouTube 的流量是 Netflix 的 7 倍，这是否意味着 YouTube 占峰值互联网流量的 259％？ 不知何故，我看不出数字是如何累加的-真正的问题。 与 YouTube，Facebook 和所有其他大型提供商相比，我之前听说过这个数字为 37％，这个数字似乎始终是> 100％-这意味着有问题。 它是什么？ - -很棒的帖子。 谢谢。 - -不错的文章。 Netfiix 内容交付背后的更详细版本。 - -感谢您的博客，我真的很喜欢阅读它。 - -很棒的文章！ 爱它！ 谢谢 - -就 Netflix 背景发生的事情而言，这只是我还是我还是这篇文章很棒？ -感谢您也分享了服务的发展，我总是给人一种印象，即 AWS 通常比单独托管更昂贵，但我从未真正考虑过正常托管的高峰时间... 您没有其他选择。 - -发送到 Netflix 的源文件通常为千兆字节而不是 TB。 很棒的文章！！！ - -用外行的语言和有趣的方式很好地解释了（考虑到与网络相关的信息通常很无聊）。 甚至连祖父母也可能会理解这篇文章。 -感谢您的努力。 - -一篇写得很好的文章，以这种轻松和交错的流程表达了一个复杂的框架。 - -我把它展示给了我的 CS 新手。 她一直想知道更多有关“云”的知识，这有助于她以相关的方式理解许多基本概念。 - -很酷的文章，但我认为 OCA 必须执行某些类似 AAA 的服务，或者 AWS 服务器必须与 OCA 建立会话以供客户端使用。 即使已加密视频，OCA 也无法立即使用该 URL 为任何人提供服务。 - -“ Netflix 从始至终控制着您的视频观看体验” - -其实并不是。 Netflix 不能通过 ISP 网络控制“最后一英里”上交付内容的质量。 -同时，这篇文章很棒！ 非常感谢。 - -好的帖子，尽管花了太长时间才到达最后的项目符号列表，这毕竟是帖子的本意。 同样，解释性的隐喻充其量也很紧张（洗狗器，松鼠坚果贮藏室，埃菲尔铁塔高度的 50 叠纸）。 - -> Netflix 必须确定您是否具有观看特定视频的有效许可证。 我们不会谈论它是如何工作的，这真的很无聊 - -相反，这听起来很有趣！ 他们使用什么数据源？ 什么是许可区域？ 他们如何处理所有格式重叠的许可证以及来自不同供应商和产品的不兼容许可证的所有奇怪的小巧情况？ - -会，我完全同意你的看法。 在这种情况下，DM 很有趣，但这是我的书中的一章，而这本书是针对云新手的。 对于他们来说，需要更多的解释性材料，我认为 DM 将使您分心。 - -对于问以下问题的人：“真正的问题-Netflix 是否占峰值互联网流量的 37％，而 YouTube 则是 Netflix 最高流量的 7 倍-是否意味着 YouTube 占峰值互联网流量的 259％” - -我的猜测是 avergae youtube 视频的质量不如 netflix。 大量 youtube 播放 480，而大量 netflix 播放 4k - -启发性很好的解释文章-谢谢 - -感谢您的有趣阅读。 广泛的体系结构视角和详细说明之间的完美平衡！ \ No newline at end of file +技术的成熟度是一个问题（安全性，可用性等），但是它将得到解决。 并期待*内部*云计算的兴起，这将改变竞争环境，价格将不可避免地下降，随着解决方案的成熟，对价格敏感度较低且有很多意料之外的麻烦的客户将进入市场。 \ No newline at end of file diff --git a/docs/70.md b/docs/70.md index 940e86d..1dbfe1d 100644 --- a/docs/70.md +++ b/docs/70.md @@ -1,185 +1,69 @@ -# 优步变得非常规：使用司机电话作为备份数据中心 +# Google+是使用您也可以使用的工具构建的：闭包，Java Servlet，JavaScript，BigTable，Colossus，快速周转 -> 原文： [http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) +> 原文： [http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-you-can-use-too-closure-java-ser.html](http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-you-can-use-too-closure-java-ser.html) -![](img/e57ca973ce8db179be6e4c55c317fa95.png) +![](img/efde67061495354a389ef6f96ab526ce.png) -在[中，Uber 如何扩展其实时市场平台](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)，最吸引人的提示之一是 Uber 如何使用驱动程序电话作为外部分布式存储系统进行恢复来处理数据中心故障转移。 +Plaxo 的前首席技术官 Joseph Smarr（解释了我认出他的照片的原因）在[中，我是 Google+团队的技术负责人。 问我什么](http://anyasq.com/79-im-a-technical-lead-on-the-google+-team)，揭示用于构建 Google+的堆栈： -现在我们从 Uber 的 [Nikunj Aggarwal](https://www.linkedin.com/pub/nikunj-aggarwal/20/878/3b4) 和 [Joshua Corbin](https://www.linkedin.com/in/joshuatcorbin) 了解了更多有关该系统的工作原理，他们在 [@Scale](http://www.atscaleconference.com/) 会议上发表了非常有趣的演讲： [。Uber 如何将您的手机用作备份数据中心](https://www.youtube.com/watch?v=0EhTOKcwRok)。 +> 如今，我们的协议栈是 Google 应用程序的标准价格：我们将 Java servlet 用于服务器代码，将 JavaScript 用于 UI 的浏览器端，很大程度上是由（开源）Closure 框架构建的，其中包括 Closure 的 JavaScript 编译器和模板系统 。 我们采取了一些巧妙的技巧：即使使用的是 AJAX 应用程序，我们也使用 HTML5 历史记录 API 来维护漂亮的 URL（对于较旧的浏览器，它采用哈希碎片）； 并且我们经常在服务器端渲染 Closure 模板，以便在加载任何 JavaScript 之前先渲染页面，然后 JavaScript 找到正确的 DOM 节点并挂接事件处理程序等，以使其具有响应能力（因此，如果您在 缓慢的连接，您很快就会点击内容，您可能会注意到它在执行任何操作之前都存在滞后，但幸运的是，大多数人实际上并没有遇到这种情况）。 我们的后端主要建立在 BigTable 和 Colossus / GFS 之上，并且我们使用了许多其他常见的 Google 技术，例如 MapReduce（同样，与许多其他 Google 应用程序一样）。 -Uber 并未使用传统的后端复制方案，在该方案中，数据库在数据中心之间同步状态以实现 [k-safety](https://my.vertica.com/docs/5.0/HTML/Master/10730.htm) 的度量，而 Uber 做了一些不同的事情，他们要做的是将足够的状态存储在驱动程序电话上，以便在数据中心进行故障转移时 发生故障信息不会在故障转移上丢失。 +起初，我读了 Clojure，这真是一个真正的惊喜，但是它是 Closure，这是一套 JavaScript 工具，由[库](http://code.google.com/closure/library/)，[编译器](http://code.google.com/closure/compiler/)和[模板](http://code.google.com/closure/templates/)组成 。 该编译器是用于 JavaScript 的真正编译器，可加快 JavaScript 下载和运行速度。 该库是模块化和跨浏览器的 JavaScript 库。 模板是服务器端模板系统，可帮助您动态构建可重用的 HTML 和 UI 元素。 它都是开源的，因此您也可以使用它。 -为什么选择这种方法？ 传统方法会简单得多。 我认为这是要确保客户始终拥有良好的**客户体验**，并且由于主动出行而丢失行程信息会带来可怕的客户体验。 +虽然您没有可用的 Google 堆栈，但确实有一些开源选项。 [HBase](http://wiki.apache.org/hadoop/Hbase) 替代了 BigTable。 然后是 [Hadoop MapReduce](http://hadoop.apache.org/mapreduce/) 。 [Colossus](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) 是 Google 的[下一代文件系统](http://highscalability.com/blog/2010/9/11/googles-colossus-makes-search-real-time-by-dumping-mapreduce.html)，是 GFS 的替代品。 由于我们对 Colossus 知之甚少，因此很难说出合适的替代品。 有 Hadoop 分布式文件系统 [HDFS](http://hadoop.apache.org/hdfs/) 。 如果您正在寻找一些像基础架构胶之类的云，则可以使用 [OpenStack](http://www.openstack.org/) （它也具有存储系统）。 -通过围绕电话建立他们的同步策略，甚至认为它很复杂且需要大量工作，Uber 能够保留旅行数据并即使在数据中心发生故障时也能提供无缝的客户体验。 使客户满意是至关重要的，尤其是在**接近零转换成本**的市场中。 +Google 可能使用了自定义的 [Java servlet](http://en.wikipedia.org/wiki/Java_Servlet) 容器，但是此处的选择并不重要。 大部分工作将以并行方式产生，并在以 [C ++，Java 或 Python](http://www.quora.com/Which-programming-languages-does-Google-use-internally) 实现的其他服务器上执行。 -因此，目标是即使在数据中心故障转移时也不会丢失行程信息。 使用传统的数据库复制策略，由于与[网络管理系统](http://whatis.techtarget.com/definition/network-management-system)始终必须工作的方式类似的原因，不可能做出此保证。 让我解释。 +尽管几乎没有与 Google 的交流，但 Google+开发团队的响应速度明显加快，可以快速，一致地实现明显的改进。 约瑟夫告诉我们原因：*我们特别强调工程速度/敏捷性-我们尝试每天发布代码更新，同时仍保持质量/稳定性/延迟与您对 google 的期望一样高。 这有助于我们快速行动并快速响应用户反馈。 我们尝试（几乎）每天都进行一次完全推送，有时，如果需要，有时我们也会潜入补丁程序发行版中。 但是有很多人参与其中，这不是“如果所有测试都通过都会自动推动”的情况或类似的情况。* -在网络设备中，状态信息的权威来源是**，例如分组错误，警报，发送和接收的分组等等。 网络管理系统对诸如警报阈值和客户信息之类的配置数据具有权威性。 麻烦的是设备与网络管理系统并不总是保持联系，因此它们不同步，因为它们彼此独立地工作。 这意味着在启动，故障转移和通信重新连接时，所有这些信息都必须使用复杂的舞蹈在两个方向上合并，以确保正确性和一致性。** +对于 Google+最具创新性的功能，即环聊视频会议，GigaOM 在该堆栈上有一篇[不错的文章，该文章基于由技术负责人 Justin Uberti 撰写的](http://gigaom.com/video/google-hangouts-technology/)[宣布 Google+ Hangouts](http://juberti.blogspot.com/2011/06/announcing-google-hangouts.html) 。 与以经济高效的 P2P 模式运行的 Skype 不同，环聊完全由 Google 托管。 这必须花费惊人的金钱。 你自己一个人在这里。 没有人可以取代 Google 童话捐赠的带宽。 -Uber 有同样的问题，只有设备是智能手机，而手机所包含的权威状态是出行信息。 因此，在启动，故障转移和通信重新连接时，必须保留行程信息，因为电话**是行程信息**的权威来源。 +那就是 Google。 再一次，一位前 Google 员工认为[您可以使用 MessagePack，JSON，Hadoop，jQuery 和 MongoDB 更好地完成](http://rethrick.com/#waving-goodbye)。 如果您可以为全球十亿用户群做得更好，那将是另一个完全不同的问题。 -即使失去连接，电话也能准确记录所有行程数据。 因此，您不希望将行程数据从数据中心向下同步到手机，因为这会清除手机上的正确数据。 正确的信息必须来自电话。 - -Uber 还从网络管理系统中吸取了另一招。 他们定期查询电话以测试数据中心中信息的完整性。 - -让我们看看他们是如何做到的... - -## 将电话用作数据中心故障存储的动机 - -* 不久前，发生故障的数据中心将导致客户旅行丢失。 现在已解决。 在数据中心发生故障时，客户可以立即返回旅途，几乎没有明显的停机时间。 - -* 将旅行的请求，提供给驾驶员的旅行，接受的旅行，上车的乘客以及结束旅行的过程称为**状态更改转换**。 只要行程持续，行程交易就持续。 - -* 从行程开始起，便在后端数据中心中创建了行程数据。 似乎每个城市都有一个指定的数据中心。 - -* **数据中心故障的典型解决方案**：将数据从活动数据中心复制到备份数据中心。 很好理解，并且可以很好地工作，具体取决于您的数据库。 缺点： - - * 超出了两个备份数据中心的复杂性。 - - * 数据中心之间的复制滞后。 - - * 它需要数据中心之间的恒定高带宽，特别是如果您的数据库对数据中心复制没有很好的支持，或者您尚未调整业务模型来优化增量。 - - * （一个尚未被谈论的好处，对于 Uber 而言可能并不重要，但对于较小的参与者而言可能是重要的，因为驾驶员电话计划通过不必为数据中心间的带宽支付那么多钱来补贴带宽成本。 ） - -* **具有创造力的应用程序意识的解决方案**：由于与驾驶员电话的持续通信只是将数据保存到驾驶员电话。 优点： - - * 可以故障转移到任何数据中心。 - - * 避免了电话故障转移到错误的数据中心的问题，这将导致丢失所有行程。 - -* 使用驱动程序电话来保存数据中心备份需要复制协议。 - - * 与数据中心通信时，会发生所有状态转换。 例如，有一个 Begin Trip 或 Begin Drive 请求，这是与手机交换状态数据并拥有手机存储数据的绝佳机会。 - - * 在数据中心故障转移上，当电话 ping 新数据中心时，需要从电话中请求行程数据。 停机时间非常短。 （没有有关如何处理数据中心地图的信息）。 - -* 挑战： - - * 并非驾驶员可以访问所有保存的行程信息。 例如，一次旅行有很多关于所有骑手的信息，这些信息不应该被公开。 - - * 必须假设驱动程序手机可能受到攻击，这意味着必须对数据进行防篡改。 因此，所有数据都在手机上进行了加密。 - - * 希望保持复制协议尽可能简单，以便于推理和调试。 - - * 最小化额外带宽。 使用基于电话的方法，可以调整要序列化的数据和保留的增量，以最大程度地减少移动网络上的流量。 - -* 复制协议 - - * 一个简单的键值存储模型用于键操作的获取，设置，删除，列表。 - - * 只能设置一次密钥，以防止意外覆盖和乱码消息问题。 - - * 设置了一次之后，规则版本控制就必须移入密钥空间。 更新存储的行程的过程如下：set（“ trip1，version2”，“ yyu”）; delete（“ trip1，version1”）。 这样做的好处是，如果在设置和删除之间出现故障，将存储两个值，而不存储任何值。 - - * 故障转移解决方案只需通过以下方法在电话和新数据中心之间合并密钥即可：将存储的密钥与驾驶员已知的任何正在进行的行程进行比较； 对于任何丢失的数据，可能会向手机发送一个或多个 *get* 操作。 - -## 他们如何获得系统大规模运行的可靠性 - -### 目标 - -* **确保系统未阻塞，同时仍提供最终的一致性**。 即使系统关闭，系统中的任何后端应用程序也应能够取得进展。 应用程序应该做出的唯一权衡是，将数据存储在手机上可能要花费一些时间。 - -* **能够在数据中心之间移动而不必担心已有的数据**。 需要一种在驱动程序和服务器之间协调数据的方法。 - - * 当故障转移到该数据中心具有活动驱动程序和行程的视图的数据中心时，该数据中心中的任何服务都不知道发生了故障。 - - * 在故障恢复到原始数据中心时，驱动程序和旅行数据过时，这会带来糟糕的客户体验。 - -* **使其可测试**。 数据中心故障很少见，因此通常很难测试。 他们希望能够不断地衡量系统的成功，以便他们可以确信故障转移在发生时将成功。 - -### 流程 - -* 驾驶员进行更新/状态更改，例如，载客。 该更新是对调度服务的请求。 - -* 调度服务更新了行程的行程模型。 该更新将发送到复制服务。 - -* 复制服务将请求排队并返回成功。 - -* 调度服务更新其自己的数据存储并将成功返回给移动客户端。 也可能会返回其他数据，例如，如果是 Uber 泳池旅行，则可能需要接载其他乘客。 - -* 在后台，复制服务对数据进行加密并将其发送到消息服务。 - -* 消息服务维护所有驱动程序的双向通道。 此通道与驱动程序用来与服务进行通信的原始请求通道分开。 这确保了正常的业务运营不会受到备份过程的影响。 - -* Messenger Service 将备份发送到电话。 - -* 这种设计的好处： - - * **应用程序已与复制延迟和故障**隔离。 复制服务将立即返回。 应用程序只需要进行廉价调用（在同一数据中心内）即可复制数据。 - - * **消息服务支持电话的任意查询，而不会影响正常的业务运营**。 可以将电话视为基本键值存储。 - -### 在数据中心之间移动 - -* 第一种方法是**在故障转移**上手动运行脚本，以从数据库中清除旧状态。 由于有人必须这样做，因此该方法具有**手术疼痛**。 由于可以一次或多次在多个城市进行故障转移，因此脚本变得太复杂了。 - -* 回想一下，它们的键值数据库中的键包含行程 ID 和版本号。 版本号曾经是一个递增号。 更改为**修改矢量时钟**。 使用**手机上的矢量时钟数据可以与服务器**上的数据进行比较。 任何因果关系违规都可以被发现并解决。 这解决了进行中的行程的协调问题。 - -* 传统上，已完成的旅行将从手机中删除，因此复制数据不会无限制地增长。 问题在于，当故障恢复到原始数据中心时，该数据中心将具有陈旧的数据，这可能会导致调度异常。 该修复程序在旅途完成时使用了特殊的[墓碑](https://en.wikipedia.org/wiki/Tombstone_(data_store))键。 该版本带有一个标志，指示旅程已完成。 当复制服务看到该标志时，它可以告诉调度服务该行程已完成。 - -* 存储旅行数据非常昂贵，因为它是 JSON 数据的加密大块。 完成的行程需要更少的存储空间。 可以将一个星期的已完成旅行与一个活动旅行存储在同一空间中。 - -### 确保 99.99％的可靠性 - -* 故障转移系统不断进行测试，以建立其正常工作以及故障转移将成功的信心。 - -* 第一种方法是各个城市的**手动故障转移**。 然后通过查看日志来查看还原和调试问题的成功率。 - - * **高手术疼痛**。 每周手动执行此过程无效。 - - * **糟糕的客户体验**。 对于少数未能正确恢复的行程，必须调整票价。 - - * **低覆盖率**。 一次只能测试几个城市，并且由于某些问题仅针对特定城市，这可能是由于具有特定于城市的新功能所致，这些错误将被忽略。 - - * **不知道备份数据中心是否可以处理负载**。 有一个主数据中心和一个备用数据中心。 即使它们的配置相同，您如何知道备份数据中心可以解决雷电群问题，即故障转移时发生的大量请求。 - -* 为了解决这些问题，他们**研究了他们要测试的系统中的关键概念**。 - - * **确保调度服务中的所有突变实际上都存储在电话中**。 例如，司机接客后可能会失去连接，因此复制数据可能不会立即发送到电话。 需要确保最终将数据发送到手机。 - - * **确保可以将存储的数据用于复制**。 例如，是否存在任何加密/解密问题。 在合并备份数据时是否有任何问题？ - - * **确保备份数据中心可以处理负载**。 - -* 为了监视系统的运行状况，诞生了监视服务。 +## 相关文章 - * 服务每小时都会从调度服务中获取所有活动驾驶员和行程的列表。 对于所有驱动程序，消息服务用于获取复制数据。 +* [封闭库](http://code.google.com/closure/library/) / [封闭模板](http://code.google.com/closure/templates/) / [封闭编译器](http://code.google.com/closure/compiler/) +* [VMware 公开了计划成为云操作系统](http://gigaom.com/cloud/vmware-exposes-its-plans-to-be-the-os-for-the-cloud)-另一种基础架构选项。 +* [罗得岛巨像](http://en.wikipedia.org/wiki/Colossus_of_Rhodes)-世界奇观。 +* [Colossus Computer](http://en.wikipedia.org/wiki/Colossus_computer) -英国密码破解者使用的电子计算设备，用于在第二次世界大战期间帮助读取加密的德语消息。 他们使用真空管（热电子阀）进行计算。 +* [巨像：Forbin 项目](http://en.wikipedia.org/wiki/Colossus:_The_Forbin_Project)-一部名为 Colossus 的大型美国防御计算机的科幻电影，引起了人们的注意并决定接管世界。 +* 这篇文章[关于黑客新闻](http://news.ycombinator.com/item?id=2758177) +* 这篇文章[在 Reddit 上](http://www.reddit.com/r/programming/comments/iod09/google_is_built_using_tools_you_can_use_too/) +* [OpenGSE 发布](http://google-opensource.blogspot.com/2009/01/opengse-released.html)-*开放源代码爱好者可能感兴趣的是最近发布的 Open Google Servlet Engine（OpenGSE）。 以前，Google 内的工程师开发了自己的快速，轻量级的 servlet 引擎，我们在 Google 内部将其简称为“ Google Servlet 引擎”或 GSE。* +* 在 Quora 上： *[谷歌的软件基础设施是否已过时？](http://www.quora.com/Google/Is-Googles-software-infrastructure-obsolete)* TLDR：不。 Hector Yee 有一个很好的总结：*与开放源代码变体相比，Google 基础结构要稳定得多，而且文档也要好得多。 他们作为一个整体工作在一起。 在 Google 框架中构建稳定，可大规模扩展的系统要比使用等效的开源工具容易得多。* 另一方面，采用定义的做事方式很容易对大公司施加的限制感到不满。 这两个观点都是正确的。 +* [jQuery vs 闭包](http://news.ycombinator.com/item?id=2758317)上的 nostrademons：基本上每个 Google 产品都使用闭包。 *没有可比性-就网页浏览量，边缘情况和一般现实情况而言，Closure 比其他所有 JS 库都得到更广泛的使用。 我实际上认为他们填补了非常不同的领域。 JQuery 适用于主要是 HTML 但需要通过渐进增强而分层的其他交互功能的网站。 闭包适用于 JavaScript 应用，其中整个客户端基本上都是用 JavaScript 编写的。* +* RyanDScott 在[上解释了为什么 Google 内部没有使用 GWT](http://news.ycombinator.com/item?id=2760822) ：*闭包只是 JavaScript。 无需等待 GWT 团队构建所需的功能，也无需自己构建这些功能。 以我的经验，当我需要使用 GWT 进行最前沿的开发时，我最终为 JavaScript 函数编写了一堆包装程序，这使我想知道为什么我不使用 JavaScript 编写所有内容。 （就像我说的那样，GWT 库非常引人注目，并且在计划大型项目时，Java 对于某些人通常感觉更舒服。）* - * 然后比较数据以查看数据是否符合预期。 这产生了许多良好的健康指标，例如失败的百分比。 +## Related Articles - * 按地区和应用程序版本划分指标对于查明问题有很大帮助。 +* [从 Google+实验中学习：Stowe Boyd 的操作系统，平台，应用](http://www.stoweboyd.com/post/8129714757/learning-from-the-google-experiment-operating-system)。 *但是，我们正在迈向一个世界，在这个世界上，Google +的大多数基本元素将成为下一代 Android 版本的一部分，并且感觉像 Google+上的应用的东西实际上将是在未来的社交网站上运行的应用 操作系统。* -* **影子恢复**用于测试备份数据中心。 +整个“前 Googler 认为您可以做得更好”的事情是如此虚假。 我在其他地方对此进行了评论，但是粗略地浏览一下他的主要批评就可以清楚地看出他对这些技术只有肤浅的知识： - * Monitoring Service 收集的数据被发送到备份数据中心以进行影子恢复。 +“与 MessagePack，JSON 和 Hadoop 相比，协议缓冲区，BigTable 和 MapReduce 都是古老的，吱吱作响的恐龙。与快速而优雅的工具（如 jQuery 和 mongoDB）相比，GWT，Closure 和 MegaStore 之类的新项目速度慢，设计过度，Leviathans” - * **成功率**是通过使用 Dispatch Service 查询和比较来自主数据中心的快照与活动的驱动程序和来自备份数据中心的行程的数量来计算的。 +真？ 实际上，这几乎都不是真的。 协议缓冲区和消息包在大小和效率方面几乎相同，协议缓冲区的文档更好，周围有更强大的社区。 您不一定会知道，如果只是在 MessagePack 网站上做一个表象（无疑是作者所做的），但是如果您实际更深入地使用这些技术，他们的主张是完全虚假的。 JSON 与协议缓冲区？ 好的，比较奇怪，但是首先 Google 到处都使用 J​​SON-他们可能是世界上最大的 JSON 用户。 协议缓冲区也比 JSON 小得多并且快得多。 Hadoop 与 BigTable？ 真的，你要去那里吗？ Hadoop 的整个历史是试图在性能方面赶上 BigTable 并尽可能地复制 BigTable 功能以获得功能之一。 Hadoop 的发展速度很快，但是我所看到的一切都表明 BigTable 的发展速度仍然更快。 - * 还计算了有关备份数据中心如何处理负载的指标。 +它会一直持续下去。 闭包的压缩比 JQuery 好得多。 最新版本的 JQuery 是否更快？ 可能，但这与新的快速，优雅的工具相比，这简直不是“ Leviathan”。 GWT 还执行*浏览器特定的构建*，这是 JQuery 无法触及的，并使它的 JavaScript 变得更小，更快。 MongoDB 当然很酷，但是您真的要把它与 BigTable 相提并论，这是唯一有意义的比较？ 真？ 这甚至不是一条值得走的路。 - * 这种方法可以解决备份数据中心中的任何配置问题。 +无论如何，仅仅因为有人在 Google 工作过并不意味着您应该坚持自己的每一个字。 这也不意味着他们对 Google 的每个项目都有深入的了解。 在那儿找到工作要容易得多。 还存在编写热门文章的问题。 这家伙的文章提出了一些疯狂的主张，旨在做到他们所做的一切：获取链接。 这是总的 BS，你们应该对 High Scalability 有更好的了解。 认真地说，你们这里有一些杀手 articles，但您不应该链接到这样的虚假信息。 -## 相关文章 +请注意，我在这场战斗中没有狗。 我不在 Google 工作，但我直接使用了其中大多数技术，包括通过大量使用 App Engine 间接地使用了 BigTable。 -* [关于 Hacker News 3](https://news.ycombinator.com/item?id=10446835) / [关于 HackerNews](https://news.ycombinator.com/item?id=10253158) / [关于 HackerNews 2](https://news.ycombinator.com/item?id=10271850) / [关于 reddit](https://www.reddit.com/r/programming/comments/3mp4al/uber_goes_unconventional_using_driver_phones_as_a/) -* [数据服务与 Uber 搭便车](https://www.youtube.com/watch?v=Dg76cNaeB4s) +亚当（Adam），很难想象有人在 Google 交付了一个重要的项目，但不值得他们对自己的经验发表意见。 我们必须对此表示不同意见，但是我非常感谢您和您对这两个堆栈的比较，非常有见地，谢谢。 -我在职业生涯中花费了大量时间来构建可在对等数据库上运行的应用程序，因此我看到了这种好处。 文章未涉及的一件事是，在多大程度上使用手机上的本地数据可以对开发人员提高生产力。 +真的很不错，感谢您发布！ -数据字段可以由应用添加，而无需在客户端/服务器/数据库堆栈之间协调架构。 对等同步在开发环境中也很方便，因此您的手机可以“修复”在开发笔记本电脑上运行的数据中心。 这样，您可以从云中的真实数据中心加载数据，重建应用程序，并将其同步到工作台。 +前端没有 GWT 吗？ -一旦接受了点对点数据模型，许多拓扑选择就会成为后期绑定。 数据可以根据需要进行分配。 这带来了各种开发和部署灵活性，例如此处所述的故障转移弹性。 +是的，我已经在自己的 Google+上工作了。 我不会邀请任何人！ 穆哈哈哈... -很好，因此它们不仅是螺丝刀，而且现在也减轻了他们的能源和存储负担。 要走的路，布伯。 +托德（Todd）：作为“最早”出现在前五名站点中的人和作为仍在其市场中处于领先地位的类别站点的唯一启动者，我建议您不要在您从中看到的“前-”观点中投入过多的股票 我认为这些“观点”没有任何值得注意的见解。 *创造*改变游戏规则的技术和从稀薄空气中获得的技术之间的区别很大，而仅仅是在非常引人注目的平台上展示和发布某些东西。 上面对“前 Google 员工”的反驳表明，事实胜过权威，而您现在可能已经发现，并不是每个“老朋友”都是天才 -这种方法不是新方法，也无法解决任何问题。 -如果您的数据中心无法处理故障转移，则不妨锁上办公室的门并扔掉钥匙。 +基于权威的论点，提议不听某人大规模交付了复杂且极富创新性的产品，因为它与公认的权威冲突，这是一种令人愉快的策略。 做得好。 -一旦计划好行程，很明显电话必须具有离线数据，以确保驾驶员到达目的地不会有问题。 这里的假设是数据中心可能会发生故障，但是设备呢？ 到处都是死区，当您输入死区时，您的设备将没有数据，因此如果没有离线数据，您将陷入死水。 +对不起，托德，但由于您已经形成了意见而拒绝接受这样精心撰写的批评/评论，同样令人愉快（使用您的术语）。 从您对亚当评论的回应中，我认为您甚至都没有读过它。 我每天都使用 GWT，将 jQuery 与之比较是可笑的……只是举一个例子。 -与其花时间和精力来想出这种方案，不如研究如何构建坚如磐石的 DC 更好。 +我了解猛烈抨击 Google 会产生网页点击量（IMO，这就是为什么这位前 Googler 的帖子得到博客作者如此广泛的报道），并且批判性地分析优势/劣势始终是一件好事，但请保持客观。 -客户体验的这场革命不仅为客户带来了新的便利，而且被证明是一种成功的商业模式。 例如，Uber 已经从仅在旧金山运营，发展成为全球发展最快的企业之一。 您现在可以在 35 个国家/地区“购物”。 同样地，像 Lyft 这样的竞争对手似乎也通过这种新生的客户体验剧变而朝着世界统治方向发展。 \ No newline at end of file +Sekhar，所以您认为我什至不应该链接到它？ 如果您注意到我在帖子的内容上什么也没说，只是质疑那些技术是否可以扩展。 批评甚至涉及到该职位。 那是你的错吗？ \ No newline at end of file diff --git a/docs/71.md b/docs/71.md index 7fb058a..09a1646 100644 --- a/docs/71.md +++ b/docs/71.md @@ -1,335 +1,157 @@ -# Uber 如何扩展其实时市场平台 +# 新的文物建筑-每天收集 20 亿多个指标 -> 原文： [http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) +> 原文： [http://highscalability.com/blog/2011/7/18/new-relic-architecture-collecting-20-billion-metrics-a-day.html](http://highscalability.com/blog/2011/7/18/new-relic-architecture-collecting-20-billion-metrics-a-day.html) -![](img/40038672dfc38e0094e8da51e713355b.png) +![](img/e9a7fbf44fffff1b84995399759e1ae3.png) -据报道，[优步](https://www.uber.com/)在短短四年中增长了惊人的 [38 倍。 现在，我认为这是第一次，Uber 首席系统架构师](http://www.latimes.com/business/la-fi-0822-uber-revenue-20150822-story.html) [Matt Ranney](https://twitter.com/mranney) 在一个非常有趣且详细的演讲中-[扩展 Uber 的实时市场平台](http://www.infoq.com/presentations/uber-market-platform)- 告诉我们有关 Uber 软件如何工作的很多信息。 +*这是 New Relic 应用性能工程师 [Brian Doll](/cdn-cgi/l/email-protection#0e6c7c676f604e606b797c6b62676d206d6163) 的来宾帖子。* -如果您对 Surge 定价感兴趣，则不在讨论之列。 我们确实了解了 Uber 的调度系统，如何实现地理空间索引，如何扩展系统，如何实现高可用性以及如何处理故障，包括使用驱动程序电话作为外部分布式存储系统来处理数据中心故障的惊人方式。 复苏。 +New Relic 的多租户 SaaS Web 应用程序监视服务持续不断地每秒收集并保存超过 100,000 个指标，同时仍提供 1.5 秒的平均页面加载时间。 我们相信，良好的体系结构和良好的工具可以帮助您处理大量数据，同时仍然提供非常快速的服务。 在这里，我们将向您展示我们如何做到的。 -演讲的整体印象是非常快速的增长之一。 他们做出的许多架构选择都是由于快速发展并试图授权最近组建的团队尽快行动而造成的。 后端已经使用了许多技术，因为他们的主要目标是使团队尽可能快地提高工程速度。 +* 新遗物是应用程序性能管理（APM）即服务 +* 应用内代理检测（字节码检测等） +* 支持 5 种编程语言（Ruby，Java，PHP，.NET，Python） +* 全球监控超过 175,000 个应用程序进程 +* 10,000+客户 -在一个可以理解的混乱（非常成功）的开始之后，Uber 似乎已经学到了很多关于他们的业务以及他们真正需要成功的知识。 他们的早期派遣系统是一个典型的使其工作正常的事情，在更深的层次上假设它仅在移动人员。 现在，Uber 的使命已经发展为可以处理箱子，杂货以及人员，他们的调度系统已经抽象出来，并奠定了非常坚实和智能的架构基础。 +## 统计资料 -尽管马特（Matt）认为他们的体系结构可能有点疯狂，但是在他们的用例中似乎使用了带有八卦协议的一致哈希环的想法。 +* 每天收集超过 20 亿个应用程序指标 +* 每周收集超过 1.7 亿个网页指标 +* 每个“时间片”指标约为 250 个字节 +* 每秒插入 10 万个时间片记录 +* 每天有 70 亿条新数据行 +* 由 9 个分片的 MySQL 服务器处理的数据收集 -很难不为 Matt 对工作的真正热情着迷。 在谈到 DISCO，即他们的调度系统时，他激动地说道，这就像是学校里的旅行推销员问题。 这是很酷的计算机科学。 即使解决方案不是最佳解决方案，但它还是由在容错范围内的可扩展组件构建的，实时，真实的规模实用的旅行推销员。 多么酷啊？ +## 架构概述 -因此，让我们看看 Uber 在内部的工作方式。 这是我对 Matt [演讲](http://www.infoq.com/presentations/uber-market-platform) 的演讲： - -## 统计信息 - -* Uber 地理空间指数的目标是每秒写入一百万次。 阅读的倍数。 - -* 调度系统具有数千个节点。 +* 语言特定的代理（Ruby，Java，PHP..NET，Python）每分钟一次将应用程序指标发送回 New Relic +* “收集器”服务提取应用程序指标并将其保存在正确的 MySQL 分片中 +* 实时用户监控 javascript 代码段针对每个页面浏览将前端性能数据发送到“信标”服务 +* 客户登录 http://rpm.newrelic.com/查看其性能仪表板 +* 我们每天收集的数据量惊人。 最初，每个指标均以全分辨率捕获所有数据。 随着时间的流逝，我们会对数据进行定期处理，从每分钟到每小时，再到每天平均。 对于我们的专业帐户，我们会无限期地存储每日指标数据，因此客户可以看到他们在长期内的改进情况。 +* 我们的数据策略针对读取进行了优化，因为我们的核心应用一直需要按时间序列访问指标数据。 为了使数据保持最佳状态以实现更快的读取速度，更容易在写操作上付出代价，以确保我们的客户可以在一天中的任何时间快速访问其性能数据。 通过将客户分布在多台服务器上，可以对数据库进行分片。 在每个服务器中，每个客户都有单独的表，以使客户数据在磁盘上保持紧密并保持每个表的总行数减少。 +* New Relic 管理用于监视系统的多种警报。 客户可以设置其 APDEX 分数和错误率的阈值。 New Relic 还具有可用性监视功能，因此客户可以在短短 30 秒内收到停机事件的警报。 我们主要发送电子邮件警报，使用我们的 PagerDuty.com 集成向多个客户发送电子邮件，并通过 SMS 集成进行更复杂的通话轮换。 +* 让我们从客户请求一直到 New Relic 堆栈进行一次 Web 交易。 + 1. 最终用户查看 Example.com 上的页面，该页面使用 New Relic 监视其应用程序性能 + 2. 运行 Example.com 的应用程序运行时已安装了 New Relic 代理（适用于 Ruby，Java，PHP，.NET 或 Python） + 3. 为每个事务捕获详细的性能指标，包括每个组件花费的时间，数据库查询，外部 API 调用等 + 4. 这些后端指标在客户的 New Relic 代理中保留最多一分钟，然后将其发送回 New Relic 数据收集服务。 + 5. 同时，嵌入在网页中的是新的 Relic 真实用户监控 JavaScript 代码，该代码可跟踪这种单一客户体验的性能 + 6. 在客户的浏览器中完全呈现页面后，New Relic 信标会收到一个请求，其中提供了有关后端，网络，DOM 处理和页面呈现时间的性能指标。 + 7. 在 Example.com 上工作的工程师登录到 New Relic，并查看了最新的应用程序性能指标以及每位客户的最终用户体验，包括浏览器和地理信息。 ## 平台 -* Node.js - -* Python - -* Java - -* 转到 - -* iOS 和 Android 上的本机应用程序 - -* 微服务 - -* Redis - -* Postgres - -* MySQL - -* [修复](http://basho.com/) - -* Twitter 的 Redis 的 [Twemproxy](https://github.com/twitter/twemproxy) - -* Google 的 [S2 几何库](https://code.google.com/p/s2-geometry-library/) - -* [铃声](https://github.com/uber/ringpop-node) -一致的哈希环 - -* [TChannel](https://github.com/uber/tchannel) -RPC 的网络复用和成帧协议 - -* 节俭 - -## 常规 - -* Uber 是一个运输平台，用于将骑手与驾驶员伙伴联系起来。 - -* 挑战：**将动态需求与动态供应实时匹配**。 在供应方，驾驶员可以自由地做他们想做的任何事情。 在需求方，骑手需要时随时需要运输。 - -* Uber 的 Dispatch 系统是一个实时市场平台，可使用手机将驾驶员与骑手相匹配。 - -* 除夕是 Uber 一年中最繁忙的时间。 - -* 容易忘记该行业取得如此巨大进步的速度。 技术的发展是如此之快，以至于最近令人惊奇的事物很快就消失了。 二十三年前，手机，互联网和 GPS 只是科幻小说，而现在我们几乎没有注意到它。 - -## 体系结构概述 - -* 驱动这一切的是运行本机应用程序的手机上的骑手和驾驶员。 - -* 后端主要为手机流量提供服务。 客户通过移动数据和尽力而为的 Internet 与后端对话。 您能想象 10 年前基于移动数据开展业务吗？ 我们现在可以做这种事情真是太棒了。 没有使用专用网络，没有花哨的 QoS（服务质量），只有开放的 Internet。 - -* 客户连接到与驾驶员和骑手相匹配的调度系统，供需。 - -* Dispatch 几乎完全用 node.js 编写。 - - * 计划将其移至 [io.js](https://iojs.org/en/index.html) ，但是从那时起，io.js 和 node.js [已合并](http://www.infoworld.com/article/2923081/javascript/reunited-io-js-rejoins-with-node-js.html) 。 - - * 您可以使用 javascript 做有趣的分布式系统。 - - * 很难低估**的生产能力，而节点开发人员**非常热情。 他们可以很快完成很多工作。 - -* 整个 Uber 系统似乎非常简单。 为什么您需要所有这些子系统以及所有这些人？ 只要这样，那便是成功的标志。 有很多事情要做，只要看起来很简单，他们就完成了自己的工作。 - -* **地图/ ETA** （预计到达时间）。 为了使 Dispatch 做出明智的选择，必须获取地图和路线信息。 - - * 街道地图和历史旅行时间用于估计当前旅行时间。 - - * 语言在很大程度上取决于要与哪个系统集成。 因此，有 Python，C ++和 Java - -* **服务**。 有大量的业务逻辑服务。 - - * 使用微服务方法。 - - * 主要用 Python 编写。 - -* **数据库**。 使用了许多不同的数据库。 - - * 最古老的系统是用 Postgres 编写的。 - - * Redis 经常使用。 有些落后于 Twemproxy。 有些是自定义群集系统的背后。 - - * MySQL - - * Uber 正在建立自己的分布式列存储，该存储可编排一堆 MySQL 实例。 - - * 某些分派服务在 Riak 中保持状态。 - -* **行程后管道**。 旅行结束后必须进行很多处理。 - - * 收集评分。 - - * 发送电子邮件。 - - * 更新数据库。 - - * 安排付款。 - - * 用 Python 编写。 - -* **金钱**。 Uber 与许多支付系统集成。 - -## 旧派送系统 - -* 最初的 Dispatch 系统的局限性是**开始限制公司**的成长，因此必须进行更改。 - -* 尽管 [Joel Spolsky 说了](http://www.joelonsoftware.com/articles/fog0000000069.html) ，但大部分内容还是重写了整个内容。 其他所有系统都没有被触及，甚至 Dispatch 系统中的某些服务都得以幸存。 - -* 旧系统是为私人交通设计的，它有很多假设： - - * 每辆车一个车手，不适用于 [Uber Pool](https://get.uber.com/cl/uberpool/) 。 - - * 迁移人员的想法已深入到数据模型和接口中。 这限制了向新市场和新产品的转移，例如转移食品和盒子。 - - * 原始版本由城市分片。 这对可伸缩性很有好处，因为每个城市都可以独立运行。 但是，随着越来越多的城市被添加，它变得越来越难以管理。 有些城市很大，有些城市很小。 一些城市的负载高峰很大，而其他城市则没有。 - -* 由于构建速度如此之快，它们没有单点故障，所以它们有多点故障。 +### 网页界面 -## 新派送系统 +* Ruby on Rails +* Nginx 的 +* 的 Linux +* 2 个@ 12 核心 Intel Nehalem CPU 带 48Gb RAM -* 为了解决城市分片问题并支持更多产品的问题，必须将供求的概念推广起来，因此创建了**供应服务和需求服务**。 +### 数据收集器和 Web 信标服务 -* 供应服务跟踪所有供应的功能和状态机。 +* 爪哇 +* 码头上的 Servlet +* 应用指标收集器：每分钟 180k +请求，在 3 毫秒内响应 +* Web 指标信标服务：每分钟 200k +请求，在 0.15 毫秒内响应 +* 使用 Percona 构建的 MySQL 分片 +* 的 Linux +* 9 @ 24 核 Intel Nehalem，带 48GB RAM，SAS 附加 RAID 5 +* 裸机（无虚拟化） - * 要跟踪车辆，有许多属性可以模型化：座椅数量，车辆类型，儿童汽车座椅的存在，轮椅是否可以安装等。 +### 有趣的 MySQL 统计资料： - * 需要跟踪分配。 例如，一辆汽车可能有三个座位，但其中两个就被占用了。 +* New Relic 每小时为每个帐户创建一个数据库表以保存度量标准数据。 +* 该表策略针对读取和写入进行了优化 +* 始终需要在特定的时间窗口内基于特定帐户的一个或多个指标来绘制图表 +* 指标（指标，代理，时间戳）的主键允许来自特定代理的特定指标的数据一起位于磁盘上 +* 随着时间的推移，当创建新表时，这会在 innodb 中创建更多页面拆分，并且 I / O 操作会在一小时内增加 +* 新帐户将以循环方式分配给特定的分片。 由于某些帐户比其他帐户大，因此有时会将分片从分配队列中拉出，以更均匀地分配负载。 +* 由于表中包含如此多的数据，因此无法进行模式迁移。 而是使用“模板”表，从中创建新的时间片表。 新表使用新定义，而最终从系统中清除旧表。 应用程序代码需要注意多个表定义可能一次处于活动状态。 -* 需求服务跟踪需求，订单以及需求的所有方面。 +## 挑战性 - * 如果骑乘者需要汽车安全座椅，则该要求必须与库存相匹配。 +* 数据清除：汇总指标和清除粒度指标数据是一个昂贵且几乎连续的过程 +* 确定哪些指标可以预先汇总 +* 大帐户：一些客户拥有许多应用程序，而另一些客户拥有数量惊人的服务器 +* MySQL 优化和调整，包括操作系统和文件系统 +* I / O 性能：裸机数据库服务器，每个帐户表与大型表的读取性能 +* 负载均衡碎片：大帐户，小帐户，高利用率帐户 - * 如果车手不介意以便宜的价格共享汽车，则必须建模。 +## 得到教训 - * 如果需要移动箱子或运送食物怎么办？ +* New Relic 使用 New Relic 监视自己的服务（临时监视生产） +* 旨在随时提高运营效率和简化操作 +* 保持苗条。 New Relic 拥有约 30 名工程师，为 1 万名客户提供支持 +* 时髦！=可靠：高性能系统有许多重要但无聊的方面，但并不是所有时髦的解决方案都可以解决。 +* 使用合适的技术来完成工作。 New Relic 主要 Web 应用程序始终是 Rails 应用程序。 数据收集层最初是用 Ruby 编写的，但最终被移植到 Java。 导致此更改的主要因素是性能。 该层目前每分钟支持超过 18 万个请求，并在大约 2.5 毫秒内做出响应，并具有足够的扩展空间。 -* 满足所有供求关系的逻辑是称为 DISCO（调度优化）的服务。 - - * 旧系统将仅在当前可用供应量上匹配，这意味着正在等待工作的道路上的汽车。 - - * DISCO 支持对未来进行规划，并在可用信息时加以利用。 例如，修改正在进行的行程中的路线。 - - * **按供应商**的地理位置。 DISCO 需要地理空间索引来根据所有供应的位置和预期的位置来做出决策。 - - * **按需求分配地理位置**。 需求还需要地理索引 - - * 需要更好的路由引擎来利用所有这些信息。 - -### 调度 - -* 当车辆四处行驶时，位置更新将通过供应发送到地理位置。 为了使驾驶员与驾驶员匹配或仅在地图上显示汽车，DISCO 通过供应向地理区域发送请求。 - -* 按供应商的地理位置会制作一个粗糙的首过滤波器，以获取附近符合要求的候选对象。 - -* 然后，将清单和需求发送到路由/ ETA，以计算它们在地理上而不是在道路系统附近的距离的 ETA。 - -* 按 ETA 排序，然后将其发送回供应源，以提供给驾驶员。 - -* 在机场，他们必须模拟虚拟出租车队列。 必须将供应排队，以考虑到货的顺序。 - -### 地理空间索引 - -* 必须具有超级可扩展性。 设计目标是**每秒处理一百万次写入**。 写入速率来自于驱动程序，驱动程序在移动时每 4 秒发送一次更新。 - -* 读取目标是每秒读取的次数多于每秒写入的次数，因为每个打开应用程序的人都在进行读取。 - -* 通过简化假设，旧的地理空间指数非常有效，它仅跟踪可调度的供应。 供应的大部分都在忙于做某事，因此可用供应的子集易于支持。 在少数几个进程中，全局索引存储在内存中。 进行非常幼稚的匹配非常容易。 - -* 在新世界**中，必须跟踪每个状态下的所有供应**。 此外，还必须跟踪其预计路线。 这是更多的数据。 - -* 新服务**在数百个进程**上运行。 - -* 地球是一个球体。 单纯基于经度和纬度很难进行汇总和近似。 因此，Uber 使用 Google S2 库将地球分成了微小的单元。 每个单元都有唯一的单元 ID。 - -* 使用 int64 可以表示地球上每平方厘米。 Uber 会使用 12 级的单元，其大小从 3.31 km（2）到 6.38 km（2），具体取决于您在地球上的哪个位置。 盒子根据它们在球体上的位置而改变形状和大小。 - -* S2 可以提供形状的覆盖范围。 如果要绘制一个以伦敦为中心，半径为 1 公里的圆，S2 可以告诉您需要哪些单元格才能完全覆盖该形状。 - -* 由于每个单元都有一个 ID，因此该 ID 被用作分片密钥。 当从供应中获得位置时，将确定该位置的小区 ID。 使用单元 ID 作为分片键，可以更新耗材的位置。 然后将其发送到几个副本。 - -* 当 DISCO 需要在某个地点附近寻找补给品时，将以骑手所在的位置为中心，计算一个圆的覆盖范围。 使用圆圈区域中的单元 ID，将所有相关的分片联系起来以返回供应数据。 - -* 全部可扩展。 即使效率不如您期望的那样，并且由于扇出相对便宜，所以可以始终通过添加更多节点来扩展写负载。 通过使用副本来缩放读取负载。 如果需要更多的读取容量，则可以增加复制因子。 - -* 一个限制是单元格大小固定为 12 级大小。 将来可能会支持动态单元大小。 需要进行权衡，因为像元大小越小，查询的扇出越大。 - -### 路由 - -* 从地理空间得到答案后，必须对选项进行排名。 - -* 有几个高级目标： - - * **减少额外的驱动**。 驾驶是人们的工作，因此人们渴望提高生产力。 他们获得额外的出行报酬。 理想情况下，驾驶员应连续行驶。 一堆工作会排队等待，他们将为此获得报酬。 - - * **减少等待**。 骑手应等待的时间尽可能短。 - - * **总体 ETA 最低**。 - -* 旧的系统是让需求搜索当前可用的供应，匹配并完成。 它易于实施且易于理解。 对于私人交通来说，它工作得很好。 - -* 仅查看当前的可用性无法做出好的选择。 - -* 的想法是，与正在远处行驶的驾驶员相比，当前正在运送驾驶员的驾驶员可能更适合要求乘车的顾客。 挑选出行驾驶员可以最大程度地减少客户的等待时间，并可以减少远程驾驶员的额外驾驶时间。 - -* 这种尝试展望未来的模型可以更好地处理动态条件。 - - * 例如，如果某个驾驶员在客户附近上线，但已经从较远的地方派遣了另一个驾驶员，则无法更改分配决策。 - - * 另一个示例涉及愿意共享旅程的客户。 通过尝试在非常复杂的场景中预测未来，可以进行更多优化。 - -* 在考虑运送盒子或食物时，所有这些决定变得更加有趣。 在这些情况下，人们通常还有其他事情要做，因此涉及不同的权衡。 - -## 缩放调度 - -* 使用 node.js 构建调度程序。 - -* 他们正在建立有状态服务，因此无状态扩展方法将行不通。 - -* Node 在单个进程中运行，因此必须设计某种方法以在同一台计算机上的多个 CPU 上以及多个计算机上运行 Node。 - -* 有一个关于在 Javascript 中重新实现所有 Erlang 的笑话。 - -* 用于扩展 Node 的解决方案是 *ringpop* ，这是一种具有八卦协议的一致哈希环，实现了可扩展的，容错的应用程序层分片。 - -* 在 CAP 术语中，ringpop 是 **AP 系统**，为了获得可用性而进行交易。 最好说明一些不一致之处，而不是提供停机服务。 最好起床并偶尔出错。 - -* 铃声是每个 Node 进程中都包含的可嵌入模块。 - -* 节点实例在成员资格集周围闲聊。 一旦所有节点都同意谁是谁，他们就可以独立有效地做出查找和转发决策。 - -* 这确实是可扩展的。 添加更多流程，完成更多工作。 它可用于分片数据，或用作分布式锁定系统，或协调 pub / sub 或长轮询套接字的集合点。 - -* 八卦协议基于 [SWIM](https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf) 。 已经进行了一些改进以缩短收敛时间。 - -* 闲聊的成员列表随处可见。 随着添加更多节点，它是可伸缩的。 SWIM 中的“ S”是可扩展的，确实有效。 到目前为止，**已扩展到数千个节点。** - -* SWIM 将健康检查与成员身份更改结合在一起，作为同一协议的一部分。 - -* 在铃声系统中，所有这些 Node 进程都包含铃声模块。 他们八卦当前成员。 - -* 在外部，如果 DISCO 要消耗地理空间，则每个节点都是等效的。 选择一个随机的健康节点。 请求到达的任何地方都负责使用哈希环查找将请求转发到正确的节点。 看起来像： - -![20783449993_8e0e0491df.jpg](img/d016d61f90e0ba24dafb216e10a828bd.png) - -* 使所有这些跃点和对等体互相交谈可能听起来很疯狂，但是它会产生一些非常好的属性，例如可以通过在任何计算机上添加实例来扩展服务。 - -* ringpop 是基于 Uber 自己的称为 *TChannel* 的 RPC 机制构建的。 - - * 这是一个双向请求/响应协议，其灵感来自 Twitter 的 [Finagle](https://twitter.github.io/finagle/) 。 - - * 一个重要的目标是控制许多不同语言的性能。 特别是在 Node 和 Python 中，许多现有的 RPC 机制无法很好地发挥作用。 想要 redis 级性能。 **TChannel 已经比 HTTP** 快 20 倍。 +## 相关文章 - * 想要高性能的转发路径，以便中间人可以非常轻松地做出转发决策，而不必了解完整的有效负载。 +* [如何在仅 9 台服务器上构建具有类似 Twitter 吞吐量的 SaaS 应用程序](http://www.slideshare.net/newrelic/how-to-build-a-saas-app-with-twitterlike-throughput-on-just-9-servers)作者：Lew Cirne - * 希望进行适当的流水线处理，以免出现线头阻塞，请求和响应可以随时沿任一方向发送，并且每个客户端也是一台服务器。 +> >为每个事务捕获详细的性能指标，包括在每个组件中花费的时间，数据库查询，外部 API 调用等 - * 希望引入有效负载校验和和跟踪以及一流的功能。 每个请求遍历系统时都应该是可跟踪的。 +这种仪器的开销是多少？ 就延迟而言？ - * 想要从 HTTP 清除迁移路径。 HTTP 可以非常自然地封装在 TChannel 中。 +感谢您的详细帖子 - * **Uber 退出了 HTTP 和 Json 业务**。 一切都在通过 TChannel 进行节俭。 +几个问题 -* 铃声正在通过基于 TChannel 的持久连接进行所有八卦。 这些相同的持久连接用于扇出或转发应用程序流量。 TChannel 也用于服务之间的通话。 +1.你做后写吗？ 有关的任何细节。 哪种工具/技术 +2.有关“负载平衡分片”的更多详细信息将有所帮助 +3.为什么选择 Java 而不是 Rails ...特定的性能原因。 -## 派送可用性 +谢谢。 -* **可用性很重要**。 优步拥有竞争对手，转换成本非常低。 如果 Uber 暂时倒闭，那笔钱就会流向其他人。 其他产品的粘性更大，客户稍后会再试。 Uber 不一定是这样。 +> 在每个服务器中，每个客户都有单独的表，以使客户数据在磁盘上保持紧密并保持每个表的总行数减少。 -* **使所有内容均可重试**。 如果某些操作无效，则必须重试。 这就是解决故障的方法。 这要求所有请求都是幂等的。 例如，重试发送不能将它们发送两次或对某人的信用卡收取两次费用。 +也许他们不知道文件系统如何工作？ 除非您预分配了该块，否则它将像其他所有文件一样随文件的增长而随机写入磁盘。 他们似乎认为，通过使用“ innodb_file_per_table”选项将其放入自己的表中并不保证文件会在磁盘上聚集。 -* **使所有东西都可以杀死**。 失败是常见的情况。 随机杀死进程不应造成损害。 +@Hrish：“这种检测的开销是多少？就延迟而言？” -* **仅崩溃**。 没有正常关机。 正常关机不是必需的做法。 当意外情况发生时，需要练习。 +我们不断监控仪器的开销，并确保其开销尽可能低。 开销因应用程序而异，但通常在 5％的范围内。 与不了解生产系统的机会成本相比，这种开销显得微不足道。 我已经看到许多公司在使用 New Relic 的短短几天内就大大缩短了他们的响应时间，因此开销远远超过了其本身。 -* **小块**。 为了最大程度地减少失败带来的损失，请将它们分成更小的部分。 可能可以在一个实例中处理全局流量，但是当该流量消失时会发生什么呢？ 如果有一对，但其中一个发生故障，则容量将减少一半。 因此，服务需要分解。 听起来像是技术问题，但更多是文化问题。 拥有一对数据库会更容易。 这是很自然的事情，但是配对不好。 如果您能够自动升级一个并重新启动新的辅助节点，则随机杀死它们是非常危险的。 +@Subhash： +1.您是否在后面写？ 有关的任何细节。 哪种工具/技术 -* **杀死所有东西**。 甚至杀死所有数据库，以确保有可能幸免于此类失败。 这就需要改变使用哪种数据库的决策，他们选择了 Riak 而不是 MySQL。 这也意味着使用铃声而不是 redis。 杀死 redis 实例是一项昂贵的操作，通常，删除它们的规模很大而且代价很高。 +不，我们不做后写。 -* **将其分解为较小的块**。 谈论文化转变。 通常，服务 A 将通过负载平衡器与服务 B 对话。 如果负载均衡器死了怎么办？ 您将如何处理？ 如果您从不走那条路，那您将永远不会知道。 因此，您必须终止负载均衡器。 您如何绕过负载均衡器？ 负载平衡逻辑必须放在服务本身中。 客户需要具有一定的智能才能知道如何解决问题。 这在哲学上类似于 Finagle 的工作方式。 +2.有关“负载平衡分片”的更多详细信息将有所帮助 -* 为了使整个系统扩展并处理背压，已经从一系列的 poppop 节点中创建了一个服务发现和路由系统。 +我们采用经典的分片模式，因为客户指标对他们来说是唯一的，并且我们不需要在各个帐户之间引用指标。 理想情况下，我们希望将负载分配到每个分片上。 在这种情况下，负载既指数据量（在给定时间段内每个分片接收多少数据），也指查询量（那些客户访问其指标的积极程度）。 我们每个帐户允许无限数量的用户，因此某些帐户有许多用户一次访问其性能数据。 我们一起研究这些指标以及诸如 CPU 和内存之类的系统指标，以确定负载在整个分片上的分布情况。 -## 总数据中心故障 +我们以循环方式将新帐户分配给特定的分片。 这听起来非常简单，而且确实如此。 这里的过早优化可能需要付出很大的努力才能进行管理，而带来的好处却很小。 您只是无法确定注册新帐户后的忙碌程度。 我们会不时注意到特定的分片比其他分片更忙。 这可能是由于新帐户非常庞大，或者是由于现有帐户利用率提高。 为了帮助平衡分片，我们只从分配队列中删除该分片，因此暂时不会获得任何新帐户。 由于我们一直在注册新帐户，因此其余的碎片将赶上来，我们将其重新添加。 -* 这种情况很少发生，但是可能会发生意外的级联故障，或者上游网络提供商可能会发生故障。 +我已经与几个为具有类似数据需求的公司在生产中运行分片的人交谈过，看来这种方法相当普遍。 正如他们所说，做最简单的事情就可以了:) -* Uber 维护着一个备份数据中心，并安装了交换机以将所有内容路由到备份数据中心。 +3.为什么选择 Java 而不是 Rails ...特定的性能原因。 -* 问题是进程内旅行的数据可能不在备份数据中心中。 他们不是使用复制数据，而是使用驾驶员电话作为行程数据的来源。 +用于数据收集的服务端点已从 Ruby 移植到 Java。 这些服务非常强大，并且不会经常更改。 他们需要从成千上万个应用程序实例中获取指标数据，并将其放入正确的分片中的正确的数据库表中。 除了耐用性，这些保养的最重要特征是原始速度。 使用当前的 ruby 实现，根本不可能与 Java servlet 竞争速度和效率。 我们的 Real User Monitoring 信标服务（作为 Java Servlet 部署）的响应时间为 0.15 毫秒。 十五分之一毫秒！ 这是每分钟 280k +请求。 -* 发生的情况是调度系统**定期向驱动器电话**发送加密的状态摘要。 现在，假设有一个数据中心故障转移。 下次驾驶员电话向 Dispatch 系统发送位置更新时，Dispatch 系统将检测到该行程不知道，并向州政府索要状态摘要。 然后，派遣系统会根据状态摘要进行自我更新，并且旅行就像没有发生一样继续进行。 +您特别强调数据库服务器是裸机。 这是否意味着其他内容已虚拟化？ +我很惊讶您确实运行自己的服务器。 我一直以为您是那些早期的云采用者之一。 :) -## 不利之处 +您是否在单个数据中心中运行？ 您如何处理高可用性？ -* Uber 解决可扩展性和可用性问题的方法的弊端是潜在的高延迟，因为 Node 进程之间相互转发请求并发送扇出的消息。 +“ [开销]通常在 5％的范围内” -* 在扇出系统中，微小的斑点和毛刺会产生惊人的巨大影响。 系统中的扇出程度越高，发生高延迟请求的机会就越大。 +除非有人指出执行的检测程度和检测到的主要组件的等待时间，即一个非常慢的 Rails 应用程序甚至更慢的数据库访问，否则这毫无意义。 -* 一个好的解决方案是通过跨服务器取消来拥有**备份请求。 这是 TChannel 的一流功能。 将请求与信息一起发送到服务 B（2）的请求一起发送到服务 B（1）。 然后，稍后将请求发送到服务 B（2）。 B（1）完成请求后，将取消 B（2）上的请求。 有了延迟，这意味着在通常情况下 B（2）没有执行任何工作。 但是，如果 B（1）确实失败了，那么 B（2）将处理该请求并以比首先尝试 B（1），发生超时然后再尝试 B（2）更低的延迟返回响应。** +与其他产品的单位成本相比，NewRelic 的速度要慢近 10,000-100,000 倍。 +http://williamlouth.wordpress.com/2011/03/17/which-ruby-vm-consider-monitoring/ -* 请参见 [Google 延迟容忍系统：将不可预测的部分](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) 制成可预测的整体，以获取更多背景知识。 +顺便说一句，我想知道如何将 NewRelic 下面的屏幕截图中的多个 SQL 语句打包成 250 个字节。 +http://williamlouth.wordpress.com/2010/03/02/does-transaction-tracing-scale-analysis/ -## 相关文章 +我认为您还应该指出，考虑到发送之前在 1 分钟的示例窗口中对高级度量聚合进行了批处理，因此所测量的页面数与对服务的入站调用数不同。 -* [关于 HackerNews](https://news.ycombinator.com/item?id=10216019) +如果您打算从事 APM 业务，那么您至少可以尝试对数字的实际含义和关联性进行准确和更加透明的了解。 -* [S2map.com](http://s2map.com/) -请参见 S2 覆盖率和绘制形状 +您是否曾经考虑过使用 Mysql Cluster？ NDB？ 无需分片即可立即获得巨大的读取/写入可扩展性。 -感谢您写这篇文章。 令人着迷的阅读！ +我们一直在使用 Galera 群集来处理 1440K 更新，每分钟有足够的净空。 -很棒的文章，非常有趣，并深入研究@uber 工作中的思想过程。 \ No newline at end of file +顺便说一句，恭喜并感谢您分享非常有用的信息。 \ No newline at end of file diff --git a/docs/72.md b/docs/72.md index 93e3aa0..4c4ffe0 100644 --- a/docs/72.md +++ b/docs/72.md @@ -1,45 +1,116 @@ -# 需要物联网吗？ 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式 +# Peecho Architecture-鞋带上的可扩展性 -> 原文： [http://highscalability.com/blog/2015/9/7/want-iot-heres-how-a-major-us-utility-collects-power-data-fr.html](http://highscalability.com/blog/2015/9/7/want-iot-heres-how-a-major-us-utility-collects-power-data-fr.html) +> 原文： [http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html](http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html) -[![](img/02aacf89ba2865c3d2f393ed9b481f74.png)](https://farm1.staticflickr.com/735/20975791628_7ef7fcd3f3_o.jpg) +*这是 [Marcel Panse](http://www.linkedin.com/in/marcelpanse "Marcel Panse") 和 [Sander Nagtegaal](http://www.linkedin.com/in/centrical "Sander Nagtegaal") 来自 [Peecho](http://www.peecho.com) 的来宾帖子。* -*我偶然发现了 [理查德·法利（HT。 关于](https://www.linkedin.com/in/drfarley) [高级计量基础架构](https://en.wikipedia.org/wiki/Smart_meter) 在加利福尼亚如何工作的说明。 这是真正的物联网领域。 因此，如果没有典型的职位结构，这就是原因。 他慷慨地允许通过一些修改将其重新发布。 当您看到“美国主要公用事业”时，请用最有可能的加利福尼亚电力公司代替它。* +尽管对体系结构的描述很有趣，但是几乎没有解决过初创企业面临的问题。 我们想改变它，所以这是我们的建筑故事。 -旧的机械仪表的轴承会随着时间的流逝而磨损，并产生摩擦力，从而导致读数下降。 这种摩擦将导致模拟仪表的旋转速度慢于其应有的速度，从而导致读数低于实际使用情况-从而产生“自由功率”。 这就像时钟在齿轮磨损之后落后时间。 +## 初创公司介绍 -对于 *美国主要公用事业* 当您的电表由于某种原因而无法读取时，会发生“估计计费”。 [CPUC](http://www.cpuc.ca.gov/PUC/documents/codelawspolicies.htm) 认可的算法几乎总是对消费者有利。 *美国主要公用事业公司* 讨厌必须进行估算的帐单，因为它们几乎总是必须根据算法和 CPUC 规则进行低估。 并非 100％对此表示肯定，但是如果他们低估了这一点，他们就不得不承担成本。 在极少数情况下，他们高估了您的收入（例如，您在错过的假期中正在休假），那么您将在下一个结算周期被“烦恼”。 +![Peecho](img/1bc747dd14e44355e996ab9878848537.png) -*美国主要公用程序* 并未实时显示您的实际使用情况。 对于那些对螺母和螺栓感兴趣的人，以下是 *美国主要公用事业* 的 AMI 系统的工作方式（AMI 是高级计量基础设施的缩写）： +阿姆斯特丹的[公司 Peecho](http://www.peecho.com) 提供打印即服务。 我们可嵌入的*打印按钮*使您可以直接在自己的网站上以专业打印产品的形式出售数字内容，例如相簿，杂志或画布。 也有一个 API。 -* 家用电表每小时测量一次过去一小时的用电量，并将其（加密）存储在电表中。 对于商用电表，每 15 分钟进行一次测量。 +Printcloud 是为打印按钮供电的系统。 它仅存在于云中，在需要时会增长，并在可能时变得更小。 该系统可以接收打印订单，神奇地将棘手的数据转换为可打印的文件，并将订单发送到最接近预期收件人的生产设施。 -* 取决于实际的仪表制造商（ *美国主要公用事业* 使用多个），它可能还会记录其他传感器数据，例如温度和电压。 +为了保护环境，Peecho 的理念是促进全球订购，但仅针对本地生产。 -* 您的电表已连接到网状网络，该网络包括邻居的所有电表以及多个“接入点”，类似于您在家中为 WiFi 网络运行的网络。 通讯是视线，范围约为数百码。 +## 昂贵的东西无法扩展 -* 您的仪表具有全球唯一的 IPv6 地址，该地址是非常大型的 IPv6 网络的一部分。 +我们是一家初创企业，因此在开始之前我们考虑过的最重要的事情就是*资金*-或缺少资金。 尽管我们需要一些强大的火力，但完整的操作系统每月花费不超过几百美元。 -* 接入点通常位于电线杆的顶部，并为相当大的区域提供服务-*美国主要公用事业*在整个北部和中部 Ca 拥有约 2,000 家，为 550 万户家庭和企业提供服务。 +资金问题一直贯穿到我们的技术堆栈中。 我们可以在此处插入一些有关面向对象，代码编译或 MVC 架构的好东西-但最后，我们只需要一个无需花钱的广泛的开发工具包。 因此，我们开发人员社区的计算机科学背景使我们注意到了 Java 平台。 -* 如果您的仪表无法直接连接到接入点，它将通过附近的仪表进行中继。 实际上，大多数仪表至少要经过几跳才能到达接入点，而仪表的传输中很大一部分实际上是在中继相邻流量。 网格非常有弹性，可以根据网络中的故障自动进行重组。 +使用云计算是无用的，因为按需扩展可以消除昂贵的产能过剩。 我们的候选清单包含 [Google App Engine](http://code.google.com/appengine/ "GAE") 和 [Amazon Web Services](http://aws.amazon.com "AWS") 。 这些大分子拥有比我们更多的资源和可扩展性经验。 这就是为什么我们发誓要尽可能多地使用他们的云服务，而不是自己构建东西。 但是，我们需要排队和关系数据存储-退出 Google。 -* 接入点通常通过蜂窝网络（有时是卫星，有时甚至是以太网）连接到主要在西海岸的多个数据中心。 +因此，我们选择使用 SimpleDB，S3，SQS，EC2，RDS，IAM，Route 53 和 Cloudfront 在 Amazon Web Services 之上构建。 它便宜且通常可靠。 可以肯定的是，我们的整个系统在两个 AWS 可用区中同时运行，以确保最大的正常运行时间。 如果我们下去，一半的世界将与我们同在。 -* 数据中心每 4 个小时与您的电表建立连接，并下载自上次下载以来记录的所有电表数据。 这些通信都是加密的。 +## 如果你慢一点，你就无法成长 -* 这一切都非常迅速-在 30 分钟内*，美国主要的* *实用程序*已读取了 550 万米中的 95％以上。 每个仪表的读取时间通常不到一秒钟。 +但是，技术不是万能的。 小公司的可扩展性很大程度上是通过灵活性获得的。 快点 我们尝试使代码保持简单，因此重构很容易。 结果，我们只能负担所需的最低限度的费用，而无需考虑过多的未来需求。 我们可以稍后解决。 -* AMI 系统为计费系统提供数据。 *美国主要公用事业* 每天使用数小时内从电表下载的最新数据，向约 5％的客户发送账单。 使用手动抄表功能，距离 *最近的读数已经过了几天甚至几周，美国的主要公用事业公司* 能够发出账单并取钱。 “现金到现金”时间。 +如果您真的想快一点，那么短迭代很重要。 平均而言，我们大约每周一次将新软件发布到生产环境中。 为了跟上这一步，我们每月组织一次晚餐。 届时将展示演示，每个人都为新内容欢呼和鼓掌。 -您的仪表还有一个电容器，如果您失去市电，它有时间发送“最后一声”消息。 *美国主要公用事业* （通常）知道断电的时间。 通常，这些最后的喘息消息会在 80％的时间内通过>，但它会因区域密度和拓扑结构而异。 成功率部分取决于消息必须中继通过多少个相邻仪表。 当您的电源中断时，通常也对大多数邻居起作用，因此中继链可能会断开。 在停电的边缘，相邻的电表仍然有电，成功会更好。 +有许多负担得起的帮助可帮助您快速入门。 例如，我们根据 [Scrum](http://en.wikipedia.org/wiki/Scrum_(development) "Scrum") 和[测试驱动开发](http://en.wikipedia.org/wiki/Test-driven_development "TDD")进行开发。 我们使用 [Jira](http://www.atlassian.com/software/jira/ "Jira") 和 [Greenhopper](http://www.atlassian.com/software/greenhopper/ "Greenhopper") 进行需求管理，使用 [Bamboo](http://www.atlassian.com/software/bamboo/ "Bamboo") 进行持续集成， [Sonar](http://www.sonarsource.org/ "Sonar") 进行代码质量监控，并使用 [Mercurial](http://mercurial.selenic.com/ "Mercurial") ]进行分布式版本控制。 -许多公用事业公司每 15 分钟测量一次住宅用电量，一些试点项目正在每 15 秒进行一次测量，从而启用了所谓的“负载分解”分析功能，即能够根据其使用情况识别单个设备的使用情况 电源签名，甚至确定何时出现设备问题，例如冰箱压缩机坏了。 您可能会想到，这会生成大量数据，以及一些严重的隐私问题！ +顺便说一下，Atlassian 产品的数量众多，部分是由其*廉价的启动许可证*来解释的-但无论如何它都是好东西。 -## 相关文章 +## 当然可以，但是架构是什么样的？ -* [关于 HackerNews](https://news.ycombinator.com/item?id=10182054) +打印按钮及其签出作为单独的应用程序存在于我们平台的顶部。 关注点的分离是为了最大程度地减少交互点，从而实现高内聚和低耦合。 该应用程序在 EC2 自动扩展组上运行，顶部带有负载均衡器。 它将订单数据存储在 SimpleDB 中，SimpleDB 是一个可能遭受打击的 AWS No-SQL 数据存储。 静态所有内容都通过 Cloudfront CDN 运行，以避免服务器受到攻击。 -很酷。 +![Peecho Printcloud architecture: print button](img/dd654c6a01d7cbd4d8436e8b72e0129d.png) -非常有趣的阅读，谢谢！ \ No newline at end of file +确认付款后，打印按钮结帐会将每个订单提交给 REST API。 我们的高级用户可以从他们的应用访问相同的 API，因此我们只需要维护一个接口即可。 它负载均衡到可以自动扩展的多个节点。 使用关系数据库服务 RDS，订单数据保存在两个可用性区域中。 + +![Peecho Printcloud architecture: order intake](img/38543b1aba00c73000010fb69aa7e050.png) + +现在，这就是魔术发生的地方。 订单接收机将票证写入处理队列。 每当有足够的票证可用时，新的处理机就会唤醒，获取票证并开始处理糟糕的数据。 我们使用通过竞标未使用的 EC2 容量租用的大型[现货实例](http://aws.amazon.com/ec2/spot-instances/ "spot instances")。 完成这些大炮之后，他们将结果存储在 S3 中，然后自杀。 + +![Peecho Printcloud architecture: processing](img/bc047e89220edd051c9659e6a61de5f8.png) + +因此，使用队列指标，随着队列中项目数的变化，我们可以上下调整处理能力的数量。 这样可以节省资金，并为我们为意外中断做好准备。 在您自己执行此操作之前，请记住，每个组件或模块应仅负责特定的功能。 组件或对象不应了解其他组件或对象的内部详细信息。 + +随后，必须通过将生产票证添加到正确的打印设施队列来将订单路由到正确的生产设施。 通过使用我们的 Adobe AIR Printclient 桌面应用程序或直接集成，该工具可以从队列中检索其作业，并从 S3 文件存储中检索产品文件。 由于不涉及服务器，因此该系统实际上是防弹的。 + +![Peecho Printcloud architecture: Printclient](img/b264b8a39efc7cc89452be47d38cac9c.png) + +作为回报，该设施可以通过将消息发布到中央订单状态队列中来更新 Printcloud 中的作业状态。 异步地，我们读取该队列以更新客户的订单。 如果一切顺利，产品将很快发货。 + +一段时间后，产品文件将从 S3 中删除，以节省存储成本-所有人从此过上幸福的生活。 + +## 做数学 + +让我们快速了解我们的每月 AWS 账单。 您应该了解几件事。 + +* 亚马逊为 SimpleDB 和其他服务提供免费套餐。 +* 我们使用欧洲地区集群，该集群比美国集群贵。 +* EC2 实例被保留[一年](http://aws.amazon.com/ec2/reserved-instances/ "reserved EC2 instances")，因此更便宜。 +* 竞价型实例通常是讨价还价的，我们假设连续的工作负载为 50％。 +* 就像并发 EC2 节点的数量一样，所需的带宽在很大程度上取决于传入的订单数量。 + +| 任务 | 服务 | 成本估算 | +| --- | --- | --- | +| 打印按钮 | 多可用区 EC2 小实例 | $ 96 | +| 订单量 | Multi-AZ EC2 small instances | $ 96 | +| 处理中 | EC2 大现货实例 | $ 84 | +| 数据库 | 多可用区 RDS | $ 160 | +| 其余的部分 | Cloudfront，S3，SimpleDB，SQS 等 | $ 50 | + +一个完全弹性的重型系统每月的总收入为 *486 美元*，该系统具有至少 5 台服务器，2 台数据库服务器，No-SQL 数据存储和外部平面文件存储的功能。 + +我们认为还不错。 + +## 我们希望您有便宜的应用 + +Peecho 证明可以在小范围内创建可扩展的体系结构。 我们希望这些信息对您有用，也将帮助您创建出色的应用程序。 当然，最好带有打印按钮。 + +感谢您分享信息。 很好地利用 AWS 平台。 + +一个问题-您如何解决在共享熨斗上获取信用卡号所涉及的 PCI 问题？ 还是该平台当前足够小以至于这还不是认证问题？ 注意：从服务提供商的角度，而不是从最终商家的角度，我对 PCI 更为熟悉，因此这很可能根本不适用于您的情况，这也很有趣：) + +非常酷的写作。 谢谢。 +您是否使用任何其他工具进行管理/缩放（例如，正确缩放或缩放或类似操作），或者一切都在亚马逊上运行了准系统？ + +@Richard：对于这种设置，我猜他们使用的是支付服务提供商，负责支付的整个过程。 例如。 您将一个 transactionid 推给支付提供商，一旦客户确认交易，支付提供商就会触发回调并将该交易标记为成功（例如 Paypal 交易：） + +@Todd：您已经为 Auto-Scaling 组预先配置了现成的 AMI，还是使用诸如 Chef / Puppet / CFengine 之类的配置管理？ + +理查德，我不认识他们，但我从事电子商务，所以我可以回应。 如果您足够小，则可以使用隐藏的聚会进行货币交易，例如 Paypal，银行或类似的提供者。 +在这种情况下，信用卡号仅由该公司查看和保存，并且您仅收到服务器对服务器的消息，通知付款结果。 他们在文章中说“确认付款后”，所以我想是这样。 +我从未尝试过该网站。 + +我猜他们没有存储任何卡信息，它们可能只是重定向到支付网关 URL，就像贝宝那样。 + +这不是 BOA，而是 Peecho（如果他们只知道捷克语的意思，请使用不同的拼写） + +来自：http://www.pcicomplianceguide.org +问：PCI 适用于谁？ +答：PCI 适用于接受，传输或存储任何持卡人数据的所有组织或商家，无论交易规模或交易数量如何。 换句话说，如果该组织的任何客户曾经使用信用卡或借记卡直接向商家付款，则适用 PCI DSS 要求。 + +您是否发现小型实例的网络带宽足以满足 Web 需求？ + +“传输”是大问题。 但是我刚刚找到了一个相对较新的文档（去年年底），在该文档中，亚马逊的 AWS 环境获得了 PCI 一级服务提供商使用的认证。 那真的很酷。 嗯...现在，这篇文章甚至更发人深省。 + +@Todd: You you got preconfigured ready-to-go AMI's for your Auto-Scaling groups or do you use some kind of configuration management like Chef/Puppet/CFengine? \ No newline at end of file diff --git a/docs/73.md b/docs/73.md index 1d32ce7..c8639e1 100644 --- a/docs/73.md +++ b/docs/73.md @@ -1,83 +1,91 @@ -# 构建全球分布式，关键任务应用程序：Trenches 第 2 部分的经验教训 +# 标记式架构-扩展到 1 亿用户，1000 台服务器和 50 亿个页面视图 -> 原文： [http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html) +> 原文： [http://highscalability.com/blog/2011/8/8/tagged-architecture-scaling-to-100-million-users-1000-server.html](http://highscalability.com/blog/2011/8/8/tagged-architecture-scaling-to-100-million-users-1000-server.html) -![](img/0ba113465fbde4f3efaadcbbdac4299c.png) +![](img/f2480e7b24c999cf768852c3e433296f.png) -*这是 [Kris Beevers](https://www.linkedin.com/pub/kris-beevers/4/a5/113) 的创始人和首席执行官， [NSONE](https://nsone.net/) 的来宾帖子的第二部分，下一代智能 DNS 和流量管理平台的提供者。 这是[第 1 部分](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html)。* +*这是 [Johann Schleier-Smith](http://www.crunchbase.com/person/johann-schleier-smith) 和 CTO &联合创始人 Tagged 的嘉宾帖子。* -## 集成和功能测试至关重要 +## 关于 Tagged 如何扩展到 1,000 台服务器的五个快照 -在每一个现代软件开发课程中，单元测试都受到重创。 这是一个好习惯。 无论您是进行测试驱动的开发，还是只是敲出代码，如果没有单元测试，您都无法确保一段代码能够达到预期的效果，除非您仔细进行测试，并确保这些测试随着代码的发展而不断通过 。 +自 2004 年以来，[标记为](http://www.tagged.com/)已从微小的社交实验发展成为最大的社交网络之一，每月向访问与新朋友见面和社交的数百万成员提供 50 亿页。 一次一步，这一演变迫使我们发展自己的体系结构，最终形成了功能强大的平台 [](http://www.stigdb.org) 。 -在分布式应用程序中，即使您拥有世界上最好的单元测试范围，您的系统也会崩溃。 **单元测试还不够**。 +## V1：PHP Webapp，100k 用户，15 台服务器，2004 年 -您需要**测试子系统**之间的交互。 如果特定的配置数据发生变化，该怎么办–对子系统 A 与子系统 B 的通信有何影响？ 如果您更改了消息格式该怎么办–生成和处理这些消息的所有子系统是否继续互相通信？ 在最新代码更改之后，依赖于四个不同后端子系统的结果的特定类型的请求是否仍会导致正确的响应？ +![](img/64da066a69275d19c7b0e540ba12feb8.png) -单元测试不能回答这些问题，而集成测试却可以。 **在集成测试套件**中投入时间和精力，并在开发和部署过程的所有阶段都建立了用于集成测试的过程。 理想情况下，始终在您的生产系统上运行集成测试。 +Tagged 诞生于一个孵化器的快速原型文化中，该孵化器通常每年都会推出两个新概念来寻找大赢家。 LAMP 是这种工作方式的自然选择，当 Java 开发主要面向大型企业的开发，Python 吸引了很少的程序员并且 Perl 带来了错误的排序时，LAMP 强调了灵活性和快速的周转时间。 另外，我们知道 Yahoo 是 PHP 的大力支持者，因此有可能在需要时扩展业务。 -## 没有服务中断维护 +在以前的项目中运行 MySQL 的丰富经验使我对这项技术产生了深恶痛绝的关系。 本着实验的精神，我们为 Tagged 购买了一些入门级 Oracle 许可证，以了解这样做是否更好。 -如果您要构建一个真正的关键任务应用程序，那么您的客户将依靠它来经营自己的业务，那么就没有关闭开关了。 它永远不会停止工作。 您永远不会有服务中断维护。 **即使最复杂的后端体系结构更改也必须毫不夸张地进行**。 +值得注意的是，仍然建立了许多较小的网站，就像原始的“已标记”一样。 简单有其美，无状态 PHP 和有状态 Oracle 之间的双向划分将最棘手的部分集中在单个服务器中，同时易于添加额外的页面呈现计算能力。 -这是您应该**认真思考架构**的原因之一。 数小时的白板可以节省数月的工作量。 +## V2：缓存的 PHP **w** **ebapp，1 百万用户，20 台服务器，2005** -一个例子：在 NSONE，我们很幸运地从一开始就掌握了大部分架构。 **一开始我们没有做对的事情：我们接受平台中的高频数据输入，这会影响我们如何使用复杂的流量管理配置来回答对 DNS 记录的查询。** 数据馈送可以应用于多个 DNS 记录，因此，服务器负载遥测的馈送可以通知与服务器上托管的多个网站有关的流量路由决策。 我们假设您只会将单个数据 Feed 真正连接到一些 DNS 记录。 因此，我们通过将进入系统的数据馈送扩展为多条消息（每个连接的 DNS 记录一条消息）并将其推送到我们的边缘位置，从而节省了一些时间和精力。 我们错误地假设了，一些我们最喜欢的客户将数据源连接到了数千个 DNS 记录！ 我们早期的懒惰使我们不得不内部进行 DoS，我们知道随着我们的不断发展，这种情况只会变得越来越糟。 +![](img/d9df48fa85ed38b2c8a1905bf77a6d6c.png) -问题：我们不能仅仅通过发送更少的控制消息来回溯并解决问题。 我们需要更改数据模型和消息传递模型，以及 4-5 个交互的始终在线系统。 在**初期需要花费 2-3 个小时的额外思考和精力才能变成为期六周的**马拉松：集思广益，深度复杂的重构，大量的正确性测试工作以及一系列精心协调的部署和迁移， 所有人都可以在不中断服务的情况下解决该问题。 +即使在 8 台服务器上，Tagged 的 Web 流量也比我们大多数人所知道的要多。 幸运的是，memcached 具有双重优势，可以删除 90％以上的数据库读取，并确保包含各种信息的社交网站页面可以快速呈现。 -虽然这是极端情况，但**新基础架构或代码的每个部署都必须无缝**：精心计划，滚动重启，持续集成测试。 为客户提供服务后，就不会关闭。 +从一开始，我们的对象缓存就着重于显式缓存更新，而采用了更简单的技术，例如删除无效密钥或基于计时器使过期数据过期。 以更复杂的代码为代价，这大大减少了数据库负载并保持了站点的快速运行，尤其是在涉及到频繁更新的对象时。 -## 极其小心地自动化部署和配置管理 +除了标准的社交网络功能（朋友，个人资料，消息）外，我们的网站还不断增加复杂性，并增加了搜索和社交发现功能。 我的团队说服我使用 Java 来构建搜索，以便我们可以从 Lucene 库中受益。 当我们学会很好地运行它时，我感到宽慰，而我对 JDK 1.0 的早期经验所产生的不情愿也转化为对该平台的热情。 -现代化的 devops 生态系统充斥着用于部署自动化和配置管理的工具：Chef，Puppet，Ansible，SaltStack，Terraform，以及似乎更多的东西。 您所使用的工具并不像您想的那么重要–阅读并确定哪种模型对您有意义。 但是**重要的是您正在使用这些工具**。 即使在公司的早期阶段，即使看起来更快或更容易，也不要手工管理您的配置或部署：您会犯错误，限制扩展能力，并且将很难进行扩展 以中等规模将自动化改造为移动目标。 +## V3：数据库可扩展，1000 万用户，100 台服务器，2006 年 -但！ 注意：强大的力量带来巨大的责任。 **部署自动化工具使您可以像其他任何东西一样**在头脑中射击平台。 +![](img/8514e77842ec44e2846d160f7c19cf5d.png) -使用 Chef 管理所有主机的 iptables 规则？ **一个疲惫的 devops 工程师和一个按钮操作都可以全局禁用您的平台**。 推出一个新功能，您保证您在登台环境中上下左右测试过吗？ 当您遇到现实流量与模拟流量之间的细微差别时，端到端的自动化部署将使您的产品死光。 明智地使用自动化。 +随时都有 1000 万注册用户和数千在线用户，我们迎接了我一直在恐惧的挑战。 我们刚刚筹集了资金，并且正在为增长而努力，但是数据库的容量正在爆炸。 我们争先恐后地发布了一个缓存或 SQL 调优优化，但是我们服务器的 CPU 会一次又一次地趋向 100％。 -我们使用 **Ansible 管理 NSONE 的配置和部署。 这是一个很棒的工具，具有很多怪癖。** 我们可以自动完成所有操作，并且只需按一下按钮就可以将新的 DNS 传递代码推送到我们的所有边缘位置，但是我们绝对不会这样做。 **我们从最低流量到最高流量按设施推出部署设施。 在一个设施内，我们逐台服务器甚至逐个核心部署，在此过程的每一步都运行全面的功能测试套件。** 在我们研究指标时，有时可能会影响性能，有时甚至是数小时或数天，然后才转移到更关键的设施上。 在开始部署之前，我们就签署了全面的代码审查，不仅是针对我们的应用程序代码，还包括我们的 Ansible 手册和配置。 +扩大规模的想法提供了一个快速解决方案，但是多路服务器硬件可能要花费数百万美元，因此我们选择了 Oracle RAC，这使我们可以使用标准网络连接许多商用 Linux 主机来构建一个大数据库。 结合最新 CPU 的优势，Oracle RAC 的容量比我们的第一台数据库服务器增加了 20 倍，这是至关重要的，并使应用程序开发人员可以专注于构建新功能。 -建立适合您的团队和应用程序的流程，但不要忘记，尽管自动化可以使您快速成长，但也可能使您快速死亡。 +当 Tagged 开始通过将来自大型内存数据集的统计数据缝合在一起来提供个性化的人员匹配建议时，Java 进一步进入了环境，这与 PHP 完全不切实际。 -## 进行消防演习 +## V4：数据库分片，5000 万用户，500 台服务器，2007 年 -坏事发生了。 每个科技公司都会使服务器发生故障。 自从我们启动 NSONE **以来，我们已经经历了各种可以想象到的服务器故障**：磁盘故障，NIC 故障，RAM 损坏，内核崩溃，虚拟环境中嘈杂的邻居副作用以及两者之间的一切。 服务器故障很容易发生。 +![](img/ddfb18ca2a28624ee1c4697ce6e14b8b.png) -电源将熄灭。 还记得桑迪飓风吗？ 在 NSONE 目前在曼哈顿下城的办公室的对面，技术人员正在用柴油在桶中爬楼梯，以保持基础设施在线。 +毫无疑问，对数据库进行分片是扩展 Tagged 中最具挑战性，也是最有意义的一集。 通过将用户分散在多个数据库中，我们最终获得了一种设计，该设计可以在所有地方仅通过添加硬件即可进行扩展。 -光纤将被切断。 BGP 将被劫持。 您将获得 DoSed，其复杂程度各不相同：从脚本小子从其父母的地下室发送 64k ICMP 数据包到全面的 DNS 和 NTP 反射放大攻击，每秒可以以数百万或数亿个数据包的速率对您的基础设施进行 DDoS 处理。 +我们在 Tagged 的规则是将每个表划分为 64 个分区，并且除非有非常有说服力的例外理由，否则我们坚持默认设置。 仅将受益于玩家之间高性能保护交易的某些游戏垂直划分在单独的数据库中。 -你会怎么做？ +对现有数据进行分片表示跨数 TB 的复杂转换。 最初，我们一次依靠应用程序代码来替换功能来攻击功能，以替换联接，但最终我们在应用程序的核心遇到了一系列表，这些表对于这种方法过于紧密地联系在一起。 编写迁移软件以生成 SQL，我们使用触发器跟踪源系统上的更改并逐步更新目标，从而导出，转换和重新加载了亿万行，以便最终的同步少于 30 分钟。 -**正确的唯一方法是练习。 在坏事情发生之前进行模拟。** Netflix 的 Chaos Monkey 是一个著名的例子。 您不一定总能直接模拟各种事件，但会尽力模拟响应。 这是确保时机成熟时唯一的方法，您可以保持镇定，使用已安装的工具并在困难的情况下有效地做出反应。 +具有许多数据库意味着具有许多数据库连接。 尤其是当我们添加了更多的“社交发现”功能（例如我们的第一个约会功能“遇见我”）时，分片将淹没 PHP，后者缺少 Oracle 连接池。 为了解决这个问题，我们构建了一个 Java 应用程序，该应用程序公开了一个用于运行查询的 Web 服务，该应用程序还将继续提供非常方便的监视点并允许正常处理数据库故障。 -## 最小化表面积 +## V5：完善和扩展功能，8000 万用户，1,000 台服务器，2010 年 -随着您的应用程序分布范围越来越广，除非采取谨慎的预防措施，否则遭受恶意攻击的表面积将急剧增加。 **锁定您的系统，并最小化暴露给 Internet 的攻击面。** +![](img/95fc1a2a48258c205567527af4f8bfbf.png) -**体系结构中的每个角色应仅将其提供的服务公开给需要访问这些服务的系统集。** 您的面向 Internet 的系统应该向您的用户公开您提供的服务，而别无其他。 在后端，您的系统应尽可能在私有 IP 空间上相互交互，并且在不可行的情况下（例如，跨远程设施进行通信），数据应流经加密通道。 无论是通过 AWS 安全组之类的提供程序工具，通过 iptables 规则的自动管理，使用路由器 ACL 或硬件防火墙，还是其他某种机制，都可以积极使用防火墙。 **首先拒绝，然后按角色允许特定流量。** +我们在这里前进了几年。 解决了关键数据库可伸缩性问题后，我们发现通过添加硬件来支持扩展很简单。 PHP 和 memcached 继续为我们服务，并支持快速的功能开发。 -**切勿允许操作员通过 ssh 等直接访问生产系统。** 人们应该通过高度锁定的堡垒主机进入您的基础架构，并使用多因素身份验证，端口敲门，IP 白名单以及其他相当严苛的安全策略。 确保您的堡垒主机分布在不同的网络和地理位置。 进入其余生产基础架构的操作应仅限于从堡垒主机发起的会话。 +在这段时间里，可伸缩性的考虑转向了减少故障，从而解决了越来越多的易碎部件的威胁。 通过负载平衡器运行状况检查和无响应服务的自动关闭，可以保护 Web 层免于依赖项的问题。 我们还设计了核心组件以提高弹性，例如，如果 memcached 的连接过载，则必须在减轻负担后立即恢复。 -有上百万种策略用于锁定系统。 我已经介绍了一些我们发现有效的做法，但绝非详尽无遗。 阅读并从一开始就考虑安全性：它是体系结构的一部分。 随着系统扩展，不要浪费时间以节省时间。 +Java 发挥了更加重要的作用，部分原因是接受度和专业知识的提高，但挑战也日益增加。 为了与垃圾邮件和其他滥用作斗争，我们的算法利用了大容量共享内存空间以及计算密集型技术。 社交游戏也得益于 Java 的性能和并发控制，但是代价是复杂性高。 我们现在需要比以前管理更多不同的应用程序池。 -## 了解提供商的情况 +## 未来 -几乎每个现代科技公司都在 AWS，DigitalOcean 或其他一些合理的低成本，低障碍的云基础架构提供商上构建其产品的第一个版本。 互联网在 AWS 之前就已经存在，并且基础设施提供商的多样性在过去十年中已经扩大。 +如今，Tagged 每月向其数百万成员提供 50 亿页面浏览量。 由于我们已经实现了可扩展的设计，因此我们可以将大部分精力花在创建更好地为用户服务的功能上。 我们拥有创建可扩展软件的有效工具，但是可以想象会有更好的工具，因此当前的投资重点是软件库，以提高程序员的效率和生产率，而我们即将开发的开源，基于图形的数据库项目 [Stig](http://www.stigdb.org) 适用于大型社交网络，实时服务和云应用程序。 -**大多数公司在扩展规模时都不会急于放弃 AWS。 但是每个公司都应尽可能保留可选性**。 +## 相关文章 -您可能会发现，应用程序中的特定工作负载最好由裸机处理，或者您需要在澳大利亚拥有高吞吐量的 CDN，或者您在没有 AWS 的情况下在市场上拥有关键的一组用户。 花一些时间来熟悉基础架构生态系统的各个方面：IaaS 提供程序，托管，DNS，CDN，监视等等。 在早期考虑架构时，有个想法，可能随着流量的增长和平台的扩展而需要在哪里寻找。 **准备快速移动**。 +* [Johann Schleier-Smith 对 theCube 的采访](http://siliconangle.tv/video/johann-schleier-smith-cto-cofounder-tagged) -在 NSONE，我们运营着一个复杂的全球任播 DNS 交付网络。 在进行原型设计时，AWS 很有意义，但是在启动平台之前，由于网络需求，我们不得不搬到其他地方。 建立一个具有竞争优势的任播 DNS 网络（针对世界一流的可靠性和性能进行调整），很大程度上取决于我们在复杂的托管和运营商环境中的导航能力，推动基础架构和网络提供商支持我们所需的控制深度的能力。 在许多情况下，我们对提供者进行了教育，并帮助他们建立了我们需要利用的功能。 +PHP 和 Oracle 数据库用户（如 Tagged）的经验导致 Oracle Database 11g 的“数据库常驻连接池”功能。 PHP 现在具有可与 Oracle 数据库一起使用的本机连接池，从而使其具有高度可伸缩性，而无需早期先驱者必须实施的中间解决方案。 关于 PHP 和 Oracle DRCP 的白皮书为： [PHP 可伸缩性和高可用性：数据库常驻连接池和快速应用程序通知](http://www.oracle.com/technetwork/topics/php/whatsnew/php-scalability-ha-twp-128842.pdf)。 -**不要忘记：基础架构运营商也是极客，他们经常对新想法和挑战持开放态度。** 了解生态系统并参与其中。 +享受了这种架构的失败，对非 OSS 堆栈可伸缩系统进行了有趣的研究。 -## 总结 +以我的经验，如果您使用 Oracle 的任何东西来尝试“省钱”，您可能犯了一些更深层次的错误。 其中很大一部分可能是出于非操作性原因而不选择 MySQL。 -我经历了很多课程，我们学习了构建和扩展分布式，关键任务系统的经验。 从一开始，您将永远不会把所有事情都做好，但是您可以让自己处于一个良好的位置，以便随着公司的发展而优雅而有效地做出反应。 +从长远来看，Oracle 的主要问题是对其平台的大量锁定。 您将无法轻松地从 Oracle 迁移过来，尤其是当您使用 Java 存储过程之类的更独特（且公平，有用的）功能时。 加上他们对自己的企业级 Linux 的热爱，当您吸引 2 亿或 3 亿用户时，确实会使您的财务困难。 -受众是全球性的。 应用程序交付也紧随其后，任何建立在线资源的新公司都应考虑如何以分布式方式进行架构和扩展，以向其用户提供最高质量的服务，从而最大限度地提高性能，可靠性和安全性。 +另一方面，如果它能正确完成工作，并且您的长期扩展和性能不受影响，那么如果您拥有知道如何使用它的人，那么任何工具都将是不错的选择。 -*如果您错过了这篇文章的第一部分，那么[这是第 1 部分](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html)。* \ No newline at end of file +这很有趣。 节目的王者是 Java，而那个家伙坚持在每张图中都贴上“ PHP”。 那就是您的“架构”。 + +您可能会认为 Oracle 现在已经为您完成了扩展。 考虑到吹牛他们可以在两个 Exadata 系统上运行 Facebook，那么为什么对于带标签的它开箱即用呢？ 还是仅当您立即购买 Exa 东西时才起作用，还是根本不起作用？ 有任何信息/见解吗？ + +PHP 在 Apache 前叉模式下运行，即作为独立进程运行，这在高度可扩展的世界中是相对异常的。 该过程模型意味着 Oracle 的传统基于线程的中间层池解决方案不适用于 PHP。 在 Oracle DB 11g 中引入 Oracle DRCP 连接池之前，被标记为先驱者并实现了其池解决方法，有关链接，请参见我先前的评论。 DRCP 之所以有效，是因为连接池是在数据库服务器上处理的，因此可以在中间层进程和应用程序服务器之间共享该池。 白皮书显示了一个基准，该基准具有由商品服务器上的数据库处理的数以万计的 PHP 连接。 + +JDK 1.0，太慢了。 +但是 JDK 1.6 更好。 +并且您不应该在 1.0 版中想象...看一下 JDK 5 或 6。 \ No newline at end of file diff --git a/docs/74.md b/docs/74.md index b1281e4..fd68762 100644 --- a/docs/74.md +++ b/docs/74.md @@ -1,79 +1,92 @@ -# 构建全球分布式，关键任务应用程序：Trenches 部分的经验教训 1 +# 论文：Akamai 网络-70 个国家/地区的 61,000 台服务器，1,000 个网络 -> 原文： [http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html) +> 原文： [http://highscalability.com/blog/2011/8/18/paper-the-akamai-network-61000-servers-1000-networks-70-coun.html](http://highscalability.com/blog/2011/8/18/paper-the-akamai-network-61000-servers-1000-networks-70-coun.html) -![](img/0ba113465fbde4f3efaadcbbdac4299c.png) +[**更新**](http://news.ycombinator.com/item?id=2900460) ：*截至 2011 年第二季度末， [Akamai 在全球范围内部署了 95,811 台](http://www.quora.com/How-many-servers-does-Akamai-have/answer/Ramakanth-Dorai?__snids__=24359589#comment509067)服务器。* -*这是 [Kris Beevers](https://www.linkedin.com/pub/kris-beevers/4/a5/113) 的创始人和首席执行官， [NSONE](https://nsone.net/) 的来宾帖子的第 1 部分，下一代智能 DNS 和流量管理平台的提供者。 这是[第 2 部分](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html)。* +Akamai 是星星的 CDN。 它声称可以提供所有 Web 流量的 15％到 30％，其主要客户是 Facebook，Twitter，Apple 和美国军方。 从传统上讲，这是非常秘密的事情，我们在本文的后面会窥视一下： [Akamai 网络：高性能互联网应用程序平台](http://www.akamai.com/dl/technical_publications/network_overview_osr.pdf)，作者是 Erik Nygren，Ramesh Sitaraman 和 Jennifer Sun. -每家科技公司都考虑到这一点：随着业务的增长，扩展其应用程序和系统是不可避免的（实际上是令人羡慕的）挑战。 **您如何从一开始就考虑扩展规模，并在不进行过早优化的情况下使公司处于良好的地位？** 在以后咬你之前，有哪些值得考虑的关键挑战？ 当您构建关键任务技术时，这些是基本问题。 在构建分布式基础架构时，无论是可靠性还是性能，或者两者兼而有之，它们都是很难回答的问题。 +Abstract: -部署正确的体系结构和流程将使您的系统和公司能够抵御分布式，高流量应用面临的常见问题。 这使您能够超越扩展限制，管理不可避免的网络和系统故障，保持冷静并实时调试生产问题，并成功地发展公司和产品。 +> Akamai 平台由遍布全球 70 个国家/地区的近 1,000 个网络的 61,000 多台服务器组成，每天提供数千亿次 Internet 交互，帮助数千家企业提高其 Internet 应用程序的性能和可靠性。 在本文中，我们概述了该大型分布式计算平台的组件和功能，并提供了对其架构，设计原理，操作和管理的一些见解。 -## 这是谁？ +通过 Internet 交付应用程序有点像生活在荒野西部，存在一些问题：对等点拥塞，低效的通信协议，低效的路由协议，不可靠的网络，可伸缩性，应用程序局限性以及变更采用的速度缓慢。 CDN 是 White Hat 试图为企业客户消除这些障碍的工具。 他们通过创建作为现有 Internet 上的虚拟网络的交付网络来实现此目的。 本文继续说明了它们如何使用边缘网络和复杂的软件基础架构来实现这一目标。 凭借如此强大的基础平台，Akamai 显然具有类似于 Google 的能力，能够提供其他人望尘莫及的产品。 -我长期以来一直在构建遍布全球的大型应用程序。 在第一次互联网泡沫时期，我坚持了一年的大学课程，并为一个文件共享创业公司建立了后端基础架构，该公司成长为数百万用户-直到 RIAA 的律师们大吃一惊并将我们打包回到宿舍 。 公司倒闭了，但我却迷上了规模。 +详细而清楚地写着，值得一读。 -最近，在 Internap 于 2011 年收购的互联网基础架构提供商 Voxel 上，我建立了许多大型 Web 公司使用的全球互联网基础架构–我们建立了全球分布式公共云，裸机即服务，内容交付 网络等等。 我们学到了很多扩展课程，并且很难学到它们。 - -现在，我们在 NSONE 上建立了下一代智能 DNS 和流量管理平台，该平台今天为 Internet 上一些最大的属性提供服务，其中包括许多本身就是关键任务服务提供商的公司。 这是真正分布在全球的关键任务基础架构，在我们构建和扩展 NSONE 平台时，我们在 Voxel 上学到的经验为我们提供了很好的服务-并一次又一次得到了加强。 - -现在该分享一些我们所学的知识，并且很幸运，也许您可​​以在自己的应用程序中应用这些课程中的一些–而不是艰难地学习它们！ - -## 架构优先 - -编写代码时，总是很想集中精力使其变得紧凑和高效，最大限度地减少内存和 CPU 消耗，最大程度地提高软件的“深度”。 停下来。 - -在现代的，分布广泛的系统中，扩展限制几乎不受系统的垂直“深度”和特定角色内的代码优化（尤其是早期）的驱动。 相反，它们是管理交互系统之间的通信以及体系结构中每个角色的水平可伸缩性。 **不要优化您的代码，请优化您的架构。** - -[微服务](https://en.wikipedia.org/wiki/Microservices) 是个好主意。 它们使应用程序中的独立角色脱钩，并使您能够独立扩展每个角色或层。 **在担心深度之前，计划水平扩展角色。 服务器既便宜又便宜，而且总是越来越便宜。 开发人员时间不是。** 因此，您可以随时进行水平缩放，而仅在找到真正重要的地方时才担心代码优化。 - -在编写一行代码之前，请花时间考虑一下您的体系结构。 绘制图表，考虑通信和数据约束，并制定计划。 - -## 从角色上考虑您的系统 - -微服务架构或多或少意味着您正在构建一个由解耦系统组成的应用程序，每个系统都解决一个特定的问题或扮演特定的角色。 但是值得重复的是，您应该以这种方式考虑您的体系结构。 b 不仅因为它**消除了扩展约束，还因为它影响了您开发代码，部署系统和扩展基础结构的方式**。 - -由相互分离，相互通信的角色组成的应用程序可以作为进程，VM 或容器并置放置在单个服务器上。 这使您可以在本地开发环境，小型登台系统和大型生产基础架构中部署应用程序。 +## 相关文章 -**随着应用程序生产基础架构的发展以及流量和用户的扩展，您可以剥离需要专用系统或系统集群的角色。** 。但是，在您的 MVP 中，您可以将成本降到最低，并且仍然可以通过并置生产角色来进行扩展。 我们在 NSONE 上发布的最早的 alpha 版本托管在 AWS 中的一个单播 t2.small 实例上。 如今，我们具有与开始时基本相同的角色和子系统集（此后又添加了更多的角色和子系统），我们的生产基础架构跨越全球各大洲的数百台服务器和近 30 个不同的生产设施（南极洲除外-抱歉 伙计们）。 随着我们的成长，我们将关键子系统剥离到了它们自己的服务器或群集，并在需要的地方增加了广度和冗余性。 +* [Akamai 技术出版物](http://www.akamai.com/html/perspectives/techpubs.html) +* [扩展 Akamai 网络](http://www.akamai.com/dl/technical_publications/query_osr.pdf)的监视基础结构 +* [当 Akamai 发生故障时，它会带上互联网](http://gigaom.com/broadband/akamai-dns-issue/)，作者：赖安·劳勒（Ryan Lawler） +* [Akamai 技术回顾](http://www.technologyreview.com/tr50/akamai/)简介 +* [Akamai 的算法](http://www.technologyreview.com/web/12183/) +* 关于 CDN 结帐 [StreamingMediaBlog](http://blog.streamingmedia.com/) 的全部内容，作者 Dan Rayburn +* [Akamai 内部以及流媒体视频](http://gigaom.com/video/inside-akamai-and-the-scary-future-of-streaming-video/)的可怕未来，作者：Stacey Higginbotham +* [Microsoft 研究论文测量了 Limelight 和 Akamai 的网络性能](http://blog.streamingmedia.com/the_business_of_online_vi/2008/10/microsoft-resea.html)，作者 Dan Rayburn +* [Akamai：约 380 万条同时进行的奥巴马广播，详细介绍了客户的限制](http://blog.streamingmedia.com/the_business_of_online_vi/2009/01/akamai-and-numbers.html)，作者丹·雷本（Dan Rayburn） -## 跨全球分布式系统的通信非常困难 +高峰还是偷看？ ;） -构建和扩展由子系统组成的应用程序是一回事，这些子系统最初并置在单个服务器上，最终并置在单个数据中心中。 完全解决多数据中心应用交付难题是另一回事。 子系统需要在 LAN 外部进行通信时，该通信的可靠性将大大降低，您不仅需要针对服务器故障，而且还要针对通信故障进行周密的计划。 +迈克尔的嘘声:-)谢谢，修正了。 -Internet 上的连接脆弱且不可预测。 在 NSONE，我们设计架构的前提是我们的边缘 DNS 交付设施将经常失去与核心设施的连接。 在非洲，巴西和印度等困难的市场中，情况尤其如此。 但是我们还需要确保在恢复通信后快速重新收敛。 仔细考虑命令和控制消息传递以及消息排队是关键。 +从丹·斯威尼（Dan Sweeney）： -对于不同的通信模式，以不同的方式考虑设施间通信也很重要。 **如果要将延迟敏感的关键命令和控制消息推送到一个或多个设备，则可能需要查看功能强大的消息队列系统**（例如，我们大量使用 RabbitMQ）。 如果要将非关键遥测回运到仪表板系统，则**可能会考虑减轻重量，但对网络拆分的影响较小**。 如果您要推送需要在所有交付位置之间紧密同步的持久性应用程序数据，则值得一看。 在设施之间移动钻头时，请使用正确的工具完成正确的工作。 +不错的论文，但是..大多数 CDN 提供程序设置中都有主要缺点。 -## 一致性哈希是同步&分片的杀手 tool +CDN 根据来自使用者 DNS 服务器的 DNS 请求来确定将您定向到哪个缓存站点。 在东南亚，ISP 的 DNS 通常做得不好，因此很大一部分消费者将 Google 或 OpenDNS 用作其 DNS 服务器。 使用 Google 或 OpenDNS 的消费者的最终结果是 CDN 不会将他们引导至最佳性能缓存服务器..而是他们的算法“认为”是最好的。 存取时间少于期望的结果。 -是时候考虑水平缩放了。 您有一堆子系统，它们都在本地和整个 Internet 上相互通信。 请求飞入您的系统，需要在可以有效地为它们服务的后端节点之间分配，并且您需要一种最大化“请求位置”的方法。 不能期望您所有具有特定角色的服务器都能满足任何请求，这可能是因为必需的数据不能全部存储在一个盒子中的 RAM 中，或者您需要在服务器之间有效地分条存储。 您如何确定水平层中的哪个节点应处理请求或任务？ +我提供以下示例： -天真的，您可以预先配置请求路由：也许您有一个请求 ID，并且所有以 A-M 开头的请求 ID 都被带到一台服务器，而以 N-Z 开头到另一台服务器。 那可能行得通，但是难以管理和扩展。 您可以将请求 ID 散列到服务器：类似 hash（id）mod N ，其中 N 是要跨越的服务器数量。 在您添加新服务器并且所有请求重新进行条带化，破坏数据或缓存局部性并破坏系统之前，这种方法很有效。 您可以为分布式“协议”实施某种复杂的协商-您的各个子系统和服务器相互通信，以确定哪些请求应该发送到哪里-这是我经常看到的一种方法。 这很复杂，事情会破裂。 +天空宽带 AS23944 +DNS 服务器 114.108.192.30 +DNS 服务器 111.68.59.70 -[一致性哈希](https://en.wikipedia.org/wiki/Consistent_hashing) 是一种强大的方式，使分布式系统无需进行实际通信就可以达成对请求到节点的映射等协议。 它易于实施，并且可以根据您的基础架构进行适当扩展，从而最大程度地减少了在子系统中添加或删除节点时的重新分段。 在具有许多交互角色的复杂体系结构中，策略性地使用一致的哈希来跨节点集对消息和请求进行条带化可能是一个巨大的胜利。 +结果： -在 NSONE，**我们以多种方式在整个堆栈中使用一致的哈希，例如将 DNS 查询路由到特定的 CPU 内核以最大化缓存局部性，在不进行显式通信的情况下协商监视节点的任务，跨层拆分大量数据馈送 聚合节点的数量，还有更多**。 +Sky Broadband 的 DNS 服务器认为 Farmville 的 IP 是： -## 测量并监视所有内容 +203.77.188.253 +203.77.188.254 -这是一条很常见的建议，似乎有些陈词滥调，但它总是值得重复的。 **您没有测量的内容，您无法理解**。 即使您远未遇到严重的扩展挑战，对系统行为及其交互的深入了解对于了解随着增长将面临的扩展约束也至关重要。 +这些 IP 实际上属于使用 AS22822 的名为 +LimeLight 的内容交付网络提供商。 我通过他们的香港缓存区获得了 Farmville。 -不只是收集系统指标。 **对您的应用程序进行检测，以了解数据库响应时间，消息传递延迟，高速缓存命中率，内存碎片，磁盘 I / O，以及可能使您洞悉系统性能的所有内容。** 绘制所有图表，并建立对“名义”行为的基本理解。 如果发生异常情况（例如负载峰值，通信故障，子系统中出现某种异常情况），请回头查看您的指标并了解事件的“特征”。 这将帮助您识别将来异常情况下正在发生的事情（同样重要的是，排除不发生的事情）。 它会帮助您了解新型工作负载或其他流量何时给系统带来了意料之外的压力，因此您可以在子系统发生故障之前适当地调整架构或扩展子系统。 +跟踪路由到 203.77.188.253（203.77.188.253），最大 64 跳，52 字节数据包 +1 192.168.100.1（192.168.100.1）1.974 ms 1.297 ms 1.308 ms +2 230-182.gw.skybroadband.com。 ph（182.18.230.1）10.278 ms 10.871 ms 10.952 ms +3 ge-1-4.mnd1.skybroadband.com.ph（111.68.59.141）36.232 ms 9.665 ms 11.732 ms +4 10ge0-3-0。 sj1.skybroadband.com.ph（114.108.192.137）32.987 ms 26.559 ms +10ge0-3-3.mnd1.skybroadband.com.ph（111.68.59.137）74.772 ms +5 202.78.101.1（202.78.101.1） ）37.318 毫秒 61.957 毫秒 69.786 毫秒 +6 tengige-1-0-0.gw1.rsv.bayan.net.ph（202.78.96.161）72.134 毫秒* 96.092 毫秒 +7 limelight1-10g.hkix.net（ 202.40.161.92）101.310 ms 110.001 ms 114.412 ms +8 cdn-203-77-188-253.hkg.llnw.net（203.77.188.253）100.429 ms 83.039 ms 105.583 ms -在 NSONE，**我们研究了指标。** 始终在显示它们（我们的办公室到处都是显示 NOC 仪表板的监视器）。 当我们看到一些突如其来的东西时，我们会问为什么，并进行更深入的挖掘。 从这种方法中获得的深刻理解意味着我们可以放心地满足 Internet 上最大客户的 DNS 和流量管理需求，因为我们知道我们的平台将如何应对新的流量和工作量。 +更改为 OpenDNS 服务器 208.67.222.222 -**与测量同样重要的是监视**。 这是两个不同的事物：我们进行测量以了解我们系统的行为，并且进行监视以检测该行为中的异常。 在您的成长早期就进行监视和警报：它将帮助您了解重要的异常和无关紧要的异常。 您才刚刚开始，可能会错过一些睡眠。 后来，随着业务的增长，管理系统变得比马拉松跑更像一场马拉松，您将希望减少噪音，着眼于影响服务的异常情况，并对系统进行自动化和重新架构以将其最小化。 +现在，我的机器认为 Farmville 决心解决以下问题： -**从多个有利位置**进行监视-不仅在物理上（多个地理位置和网络），而且在逻辑上。 在 NSONE，我们监视内部遥测中的异常情况，利用 Catchpoint 和 Raintank 等第三方服务进行外部监视，并通常利用各种数据源来观察平台和网络事件。 +208.111.148.6 +208.111.148.7 -同样重要的是，**监视的不仅仅是系统**的“正常性”。 系统提供“优质”服务意味着什么？ 低延迟响应时间？ 高缓存命中率？ 监视那些指标并在它们超出范围时发出警报。 +这是到 208.111.148.6（208.111.148.6）的 LimeLight CDN AS22822 +跟踪路由，最大 64 跳，52 字节数据包 +1 192.168.100.1（192.168.100.1）1.556 ms 1.277 ms 1.232 ms +2 230- 182.gw.skybroadband.com.ph（182.18.230.1）12.541 ms 11.120 ms 11.883 ms +3 114.108.192.153（114.108.192.153）12.625 ms 11.722 ms 11.863 ms +4 114.108.192.133（114.108.192.133） 40.514 毫秒 26.772 毫秒 22.962 毫秒 +5 byt-0027.asianetcom.net（202.147.25.149）30.663 毫秒 50.844 毫秒 28.684 毫秒 +6 po14-0-2.cr1.nrt1.asianetcom.net（202.147.24.222） 80.310 毫秒 77.755 毫秒 76.977 毫秒 -*这是本文的[第 2 部分](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html)。* +7 * po7-0-0.gw1.sjc1.asianetcom.net（202.147.0.34）186.193 毫秒 195.764 毫秒 -## 相关文章 +8 208.178.245.9（208.178.245.9）185.150 ms 182.295 ms 196.486 ms +9 64.214.150.94（64.214.150.94）200.577 ms 185.450 ms 196.004 ms +10 cdn-208-111-148-6.sjc.llnw .net（208.111.148.6）198.069 毫秒 209.952 毫秒 280.367 毫秒 -* [关于黑客新闻](https://news.ycombinator.com/item?id=10147420) +所以我是 -很棒的文章！ 我特别指出，内部遥测和外部监视之间存在差异。 这是我最近与一位近视的领导者失去的论点-他关闭了内部遥测系统以节省几分钱。 但是自那以后，我离开了那家公司，我希望从长远来看，这将使他们停机。 \ No newline at end of file +我回应丹·斯威尼的评论。 +使用基于 DNS 的路由非常简单，不是运行 CDN 的唯一方法。 +我的理解是 Akamai 使用 BGP（边界网关协议）路由，该路由告诉网络将对相同 IP 地址的请求定向到最近的服务器。 因此，可以根据您的 ISP 的位置将单个 IP 路由到不同的位置。 \ No newline at end of file diff --git a/docs/75.md b/docs/75.md index 65c338f..5e788bb 100644 --- a/docs/75.md +++ b/docs/75.md @@ -1,67 +1,129 @@ -# Autodesk 如何在 Mesos 上实施可扩展事件 +# 策略：在 S3 或 GitHub 上运行可扩展，可用且廉价的静态站点 -> 原文： [http://highscalability.com/blog/2015/8/17/how-autodesk-implemented-scalable-eventing-over-mesos.html](http://highscalability.com/blog/2015/8/17/how-autodesk-implemented-scalable-eventing-over-mesos.html) +> 原文： [http://highscalability.com/blog/2011/8/22/strategy-run-a-scalable-available-and-cheap-static-site-on-s.html](http://highscalability.com/blog/2011/8/22/strategy-run-a-scalable-available-and-cheap-static-site-on-s.html) -![](img/8984f7f1f052261aa848f938774e4d89.png) +我曾经从事过的最好的项目之一是创建一个几乎完全静态的大规模网站发布系统。 一支由非常有才华的创意团队组成的庞大团队进行了艺术创作，作者撰写了内容，设计师生成了模板。 所有资产均由数据库控制。 然后，在应用了许多不同的过滤器之后，所有内容都被提取到了一个静态站点，该站点通过 ftp 上传到了数十个 Web 服务器。 效果很好。 可靠，快速，便宜且简单。 更新有些麻烦，因为它需要将大量文件推送到许多服务器，这需要时间，但要有一个可靠的系统。 -*这是 [Autodesk](http://www.autodesk.com/) Cloud 的软件架构师 [Olivier Paugam](https://www.linkedin.com/pub/olivier-paugam/2/214/475) 的来宾帖子。 我真的很喜欢这篇文章，因为它显示了如何将基础架构（Mesos，Kafka，RabbitMQ，Akka，Splunk，Librato，EC2-）组合在一起以解决实际问题。 如今，一个小团队可以完成多少工作，真是令人惊讶。* +A，这个优雅的系统被替换为一个新的基于动态数据库的动态系统。 内容是使用动态语言生成的前端从数据库中提取的。 借助 Amazon 的沃纳·沃格斯（Werner Vogels）的最新系列文章，记载了他利用 S3 的网页服务能力将他的 [All Things Distributed](http://www.allthingsdistributed.com/) 博客转换为静态站点的经验，我很高兴 问：我们又回到静态网站了吗？ -几个月前，我受命提出一个*中央事件系统*，该系统可以使我们的各种后端相互通信。 我们正在谈论活动流后端，渲染，数据转换，BIM，身份，日志报告，分析等。 而且，我们的工程团队也可以轻松地进行交互。 当然，系统的每个部分都应能够*自行扩展。* +提出这个问题很高兴，因为在许多方面，完全静态的站点是内容繁重站点的圣杯。 静态站点是其中文件（html，图像，声音，电影等）位于文件系统中的站点，并且 Web 服务器直接将 URL 转换为文件，然后直接从文件系统读取文件并将其吐出到 浏览器通过 HTTP 请求。 **在此路径中，**不会出错。 没有太多的错误是一种美德。 这意味着您无需担心任何事情。 它将正常工作。 而且它会随着时间的推移继续工作，产生一些误点，并为繁重的站点提供服务，而静态站点则要困难得多。 -我显然没有时间写太多代码，而是选择 [Kafka](http://kafka.apache.org/) 作为我们的存储核心，因为它稳定，广泛使用并且可以正常工作（请注意，我并不一定要使用它，并且可以切换 到别的东西）。 现在，我当然不能直接公开它，而必须使用一些 API 对其进行前端处理。 不用多考虑，我也拒绝让后端管理偏移量的想法，因为它对例如处理故障的方式施加了太多约束。 +这是 Werner 使网站静态的方式： -那我最终得到了什么？ 分为两个单独的层：**首先是处理传入流量的 API 层，然后是托管与 Kafka（例如，实现生产者&消费者）交谈的长期的有状态流处理程序**的后端层。 这两层都可以独立扩展，只需要在它们之间进行一致的路由即可确保客户端继续与同一个后端流处理进行对话。 +* S3-存储文件并为网站提供服务，创建没有服务器的网站。 S3 不是您唯一的选择，但对他而言显然是一个选择。 我们还将讨论更多有关使用 Github 和 Google App Engine 的信息。 +* [Disqus](http://disqus.com/) -以获得评论。 +* 必应-[网站搜索](http://www.orangetreeweb.com/articles/installing-bing-site-search.html)。 Google 希望网站搜索功能每年收费 100 美元。 我记得 Google 免费的时候... +* [DropBox](http://www.google.com/url?sa=t&source=web&cd=1&ved=0CCcQFjAA&url=http%3A%2F%2Fwww.dropbox.com%2F&ei=CfBRTvHINLDUiALTrdiHAQ&usg=AFQjCNGLRmWLy_c8ebbz09BgsukcLpmnwQ&sig2=m9cVWrbTNKXcHuxN6HRXoQ) -用于将网站文件同步到他所在的任何计算机上，以便可以在本地对其进行编辑。 然后，在文件上运行静态站点生成器。 然后将文件复制到 S3，这使它们可以使用 S3 在 Internet 上使用。 +* [Jekyll](http://jekyllrb.com/) -静态网站生成器。 用 Ruby 编写，并使用 [YAML](http://yaml.org/) 进行元数据管理，并使用 [Liquid 模板引擎](http://www.liquidmarkup.org/)处理内容。 +* [s3cmd](http://s3tools.org/s3tools) -将文件推送到 S3。 +* [http://wwwizer.com](http://wwwizer.com) -免费服务，可满足 S3 要求您的网站在域名中包含 www 的要求。 该服务会将一个裸域名重定向到 www.domain，因此一切正常。 [Joseph Barillari](http://jbarillari.blogspot.com/2011/02/why-you-cant-run-your-website-from.html) 对此问题进行了很好的讨论。 -这些层在 **Scala** 中实现了 100％，并使用[播放！ 框架](https://www.playframework.com/)。 他们也严重依赖 **Akka actor 系统**（每个节点通常运行数百个 actor）。 后端层实现了一组自定义的 Kafka 生产者&使用者，并使用一组专用的参与者来管理预读&写缓冲区。 一切都实现为嵌套的有限状态机（我喜欢这个概念）。 分析会转到 **Splunk** ，而指标会转到 **Librato** （*收集的*在容器中运行）。 +描述他的旅程的文章包括： [AWS 的新功能：从 Amazon S3](http://www.allthingsdistributed.com/2011/02/website_amazon_s3.html) 运行您的网站，[最后免费-在 Amazon S3](http://www.allthingsdistributed.com/2011/02/weblog_in_amazon_s3.html) 中运行的完全自我维持的博客，以及[否 服务器必需-Jekyll & Amazon S3](http://www.allthingsdistributed.com/2011/08/Jekyll-amazon-s3.html) 。 -[![1-4](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01bb08323d7f970d-800wi "1-4") ](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01bb08323d7f970d-pi) *发布外观的艺术渲染。* +对我来说，使用 DropBox 是一个聪明的地方。 DropBox 可以使文件跟随您，因此您可以在任何计算机上对其进行编辑。 这也是该方法的缺点。 您需要具有完整工具集的本地计算机，这很麻烦。 具有讽刺意味的是，这就是为什么我更喜欢基于云的方法。 我想从任何支持 Web 的设备（例如 iPhone 或 iPad）上运行博客，我不想弄乱程序。 -那么，如何在两层之间路由？ 只需使用 [RabbitMQ](https://www.rabbitmq.com/) ，它非常耐用&有弹性，就不好笑了。 AMQP 队列是实现此简单“电话切换”模式的好方法。 通过使用将一组固定的后端节点与一个 RabbitMQ 代理相关联的逻辑分片（例如，对每个事务中存在的某些 Cookie 进行哈希处理或类似操作）来进行扩展也是很简单的。 +静态站点是**可伸缩**站点。 Web 服务器或 OS 可以轻松地将受欢迎的页面缓存在内存中，并像肯塔基州德比的薄荷糖一样为它们提供服务。 如果单个服务器不堪重负，则可以轻松地从 CDN 中为静态站点提供服务，也可以将其复制到负载平衡的配置中。 因此，静态站点是**快速**。 如果您在下面使用分布式文件系统，那么甚至可以避免磁盘缓慢成为热点的问题。 -为什么我不对 RabbitMQ 经纪人进行集群？ 好吧，主要是因为我很懒，也因为这并不是必须的。 **在我看来，分摊单个经纪人**中的流量实际上同样有效，而且更易于控制。 与收益相比，要做的额外工作微不足道。 +您可以使用**最喜欢的文本编辑器**编辑内容。 Nice 和**简单**。 -简而言之，给定一些容器拓扑，我们的请求将遵循特定的路径，具体取决于哪个后端节点承载了什么流会话。 **扩展整个过程就像给定您需要的**独立地扩展每个层一样简单。 唯一实际的限制将来自您的虚拟网络适配器以及可以通过多少带宽。 +文件系统倾向于**可靠**。 使用 S3 更可靠，**也便宜。 如果出现故障，您可以使用一个简单的命令重新发布或还原您的站点。 数据库往往会增加内存容量，填满表，查询速度慢以及其他许多烦人的故障模式。 在静态站点中可以跳过的所有操作。 超越简单文件服务的 Web 服务器也可以发挥作用。** -[![1-3](img/e486bfe35f21fad9f18358c59608a8ec.png "1-3") ](http://a6.typepad.com/6a01b7c766c713970b01bb083239de970d-pi) *虚线显​​示了来自给定会话的路径请求将遵循的路径。* +静态站点的问题在于它们是静态的。 一旦互联网完全静止，当然还有眨眼标记和动画 gif。 然后，CGI 改变了这一切，此后网络从未停滞不前。 -现在来了有趣的部分：**我们如何保证可靠的流量并避免拜占庭式故障？** Mucho 说的很简单，只需采用简单的两阶段提交式协议，并将客户端和后端建模为镜像状态机（例如，它们始终保持同步）。 这可以通过具有需要显式确认请求的读写操作来实现。 您尝试阅读某些内容，如果失败了，您可以重试，直到您可以放置​​确认，然后更改后端（例如，向前移动 Kafka 偏移量或安排要发布的事件块）为止。 所以我的客户和后端之间的流量实际上就像是“分配会话”，“读取”，“ ack”，“读取”，“ ack” ...“ dispose”。 +因此，我们要做的是将**所有**动态位外包给服务，并使内容保持静态。 评论可以由 Disqus 之类的服务处理。 搜索可以由 Bing 处理。 广告投放已经是一项服务。 就像按钮一样，都是无用的 javascript 代码。 并且，将**安全性**的担忧（黑客，SQL 注入等）最小化。 这是混搭文化。 -这种系统的巨大优势在于，**可以有效地使操作成为幂等，**加上**可以在状态机**中对所有逻辑进行编码，而无需任何烦人的声明性语句（ *对我自己：我应该提供一个纯粹的功能实现，以保持冷静*。 当然，任何网络故障都将适当地重试。 顺便说一下，您还可以获得自由的控制流和背压。 +而且大多数情况下都有效。 当我不得不将 HighScalability 移出共享托管时，我认真考虑了这种方法。 -因此，整个事情都以 [Apache Thrift](https://thrift.apache.org/) API 的形式公开（目前已通过 HTTPS 进行了压缩，并且计划将其迁移到纯 TCP）。 我拥有 Python，Scala，.NET 和 Ruby 的客户端 SDK，以配合我们在 Autodesk 使用的各种令人眼花 variety 乱的技术。 请注意，Kafka 偏移量由客户端管理（尽管不透明），这使后端更易于控制。 +缺点： -等一下 **如何处理后端节点发生故障的情况？** 多亏了两阶段协议，我们在读取数据时并没有真正遇到问题：客户端反复出现故障，然后使用其当前偏移量重新分配新的流会话。 向 Kafka 写入数据时会担心，因为这是异步的，并且可能会受到下游背压的影响（例如，您的节点发生故障，Kafka 代理也有问题。.urg）。 我为后端节点配备了正常关机功能，它将在等待任何挂起的写操作通过时快速使任何传入请求失败。 最后，我们甚至可以将所有待处理的数据刷新到磁盘（并在以后重新注入）。 +* .htaccess 不能做很多事情。 如果您有很多安全检查和 URL 映射魔术，那么您无法使用 S3 做到这一点。 +* 没有 PHP 或任何其他语言使用 Web 服务器调用的语言引起的动态性。 您当然可以完全自由地创建服务并将其混入您的站点。 Google App Engine 仍然是此类迷你服务层的绝佳平台。 -再说一遍。 **如果部分基础架构爆炸了怎么办？** 。 您与处理您的流会话的实际后端节点之间的任何流量中断都将使您放慢速度，但当然不会受到任何讨厌的影响，这要归功于两阶段协议。 +对我来说最大的缺点是： -哦，我忘记添加了**数据，该数据在登陆 Kafka 日志之前会自动加密**（AES 256）。 没有更多的 la 脚的密钥共享尝试使用香草卡夫卡的生产者和消费者进行相同的操作。 在安全性主题上，我可以添加我们的流会话通过 OAUTH2 进行身份验证，使用按请求的 MD5-HMAC 质询并通过 TLS 向下访问后端群集。 +* **不是多用户**。 这种限制影响了网站的各个方面。 我希望多个人能够向 HighScalability 添加内容。 我想给用户特殊的特权。 我想分配角色。 我想控制某些用户可以看到的内容。 SquareSpace 与其他内容管理系统一样具有此功能。 静态站点生成器生成的站点不具备这些功能。 +* **加入**。 这些工具可让用户与您的网站互动，因此希望他们能坚持更长的时间。 诸如历史上最热门的帖子，文章的阅读次数，最新的帖子列表，标签云等功能。 使用静态生成器更难做到这些。 +* **获利者**。 这些功能可以帮助您赚钱。 它们通常包括参与者，但可以包括诸如电子邮件列表注册，相关内容推荐，白皮书匹配，注册咨询服务，赞助商文本链接等功能。 难以在静态系统上实现。 一个显而易见的解决方案是拥有一个通用的 CMS 元数据服务，所有混搭服务都可以使用该服务，但是这种服务可能不会实现。 -那么，您现在要问的是如何部署所有这些时髦的系统？ 好吧，我们在普通的 [Mesos / Marathon](https://github.com/mesosphere/marathon) 集群（目前不是 [DCOS](https://mesosphere.com/) ）上 100％运行它，但我们可以切换到它，并从它们令人敬畏的仪表板中受益。 此时，群集是**托管在 AWS EC2** 上的，我们基本上将整个事物复用到了少数 c3.2xlarge 实例上（对于给定区域的小型部署，10 至 20 个实例就足够了）。 请注意，我们可以在 [Kubernetes](http://kubernetes.io/) （EC2 或 GCE）上执行完全相同的操作。 +对于构建静态网站，S3 并非唯一的游戏。 Github 也可以用来托管静态网站。 可以通过简单的 git push 生成和更新博客。 这样可以将所需的已安装程序集减少到更易于管理的级别。 现在您甚至不需要 git。 您可以使用文件的网络界面直接编辑文件。 它的工作方式是 Github 每次将更改推送到存储库时都会自动构建您的网站。 此处有更多详细信息： [GitHub Pages](http://pages.github.com/) ，[发布带有 GitHub Pages 和 Jekyll](http://blog.envylabs.com/2009/08/publishing-a-blog-with-github-pages-and-jekyll/) 和 [Github 作为 CDN](http://code.lancepollard.com/posts/github-as-a-cdn/) 的博客。 -[![Stack](img/c29061f835160adb9b54403c955c07d9.png "Stack")](http://a4.typepad.com/6a01b7c766c713970b01b7c78e36d4970b-pi) +Google App Engine 还是静态网站的替代方案。 更多详细信息，请访问： [DryDrop，使用 GAE 和 Github](http://openalexandria.com/2010/08/drydrop-manage-static-web-site-with-gae-and-github/) 管理静态网站。 -*有点提醒我们堆栈的结构。* +现在有些推动将博客移至**社交网络**网站，例如 Google+。 优点是您拥有一个内置的机制来吸引更多的读者，强大的讨论功能，增加参与的可能性，无需花费，设备可用性出色且无需维护。 对于不需要获利的博客，这是一个很好的选择。 尽管我确实担心当您想跳到下一个流行的社交网络时发生的情况，而所有旧内容仅仅是灰尘。 -一切都使用我们的 [Ochopod](https://github.com/autodesk-cloud/ochopod) 技术（自集群容器）进行了部署，该技术也采用开源的方式。 操作减少到绝对最小值。 例如，例如，对 API 层进行适当的构建推送，只需分配一些新容器，等待它们安顿下来然后逐步淘汰旧容器即可。 所有这些都是通过在集群中运行的专用 Jenkins 从属服务器（本身也是 Ochopod 容器）完成的！ +包起来： -我实际上开发了 [Ochothon](https://github.com/autodesk-cloud/ochothon) mini-PaaS，只是为了能够快速开发/运行所有这些容器。 +* 如果您的博客严格讲内容，那么静态网站方法是可伸缩，快速，廉价，灵活和可靠的。 我们现在拥有丰富的工具集，可以使静态网站成为现实。 +* 如果您的博客不在网上，那么请把时间花在社交网络（包括 StackExchage，Quora 等）上而不是博客上。 +* 如果要提高用户参与度或通过其他方式创造性地通过博客获利，则 CMS 是更好的选择。 +* 如果您想在博客上拥有多个用户和内容创建者，那么 CMS 是一个更好的选择。 -[![Screen Shot 2015-05-21 at 9.00.31 AM](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01b8d117b6df970c-800wi "Screen Shot 2015-05-21 at 9.00.31 AM")](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01b8d117b6df970c-pi) +因此，有关创建静态网站的更多链接： -*Ochothon CLI 显示了我的预生产集群之一。* +* [由 Jean-Michel Lacroix 在 CloudFront](http://jmlacroix.com/archives/cloudfront-hosting.html) 上托管静态网站 +* [在 Jean-Michel Lacroix 上在 CloudFront](http://jmlacroix.com/archives/cloudfront-publishing.html) 上发布静态网站 +* [ponyHost-已死的简单 s3 网站](http://ponyho.st/) +* [Hyde](http://ringce.com/hyde) -Hyde 是由 Python 支持的静态网站生成器& Django +* [Nanoc](http://nanoc.stoneship.org/) -是一种 Ruby 网络发布系统，可在您的本地计算机上运行，​​并将以 Markdown，Textile，Haml 等格式编写的文档编译到由简单 HTML 文件组成的静态网站中，随时可以上传到任何网站 网络服务器。 +* [博客工具](http://joshua.schachter.org/2009/12/blogging-tools.html)，作者：joshua schachter +* [仙人掌](https://github.com/koenbok/Cactus)-静态网站生成器。 +* [jekyll vs. hyde-两个静态网站生成器的比较](http://www.reddit.com/r/programming/comments/hcxvc/jekyll_vs_hyde_a_comparison_of_two_static_site/) +* [jekyll-s3]( https://github.com/versapay/jekyll-s3) -将您的 Jekyll 博客推送到 Amazon S3！ -为了让您了解 Ocho- *平台的全部功能，我只想说**，一个人（我）可以管理 2 个区域（包括所有复制基础设施**）的 5 个系统部署 ……还有时间写博客和编写代码！ +嗨，托德，很高兴写出来。 我绝对同意你提到的缺点。 对我来说，这确实是一种锻炼，它使我可以做无服务器工作。 并了解我们可以在 AWS 方面做得更好。 -因此，总体而言，设计和编码整个过程非常有趣，而且它现在已经在生产中运行，成为我们云基础架构的关键任务部分（这是一个不错的奖励）。 让我们知道，如果您想了解更多有关此异国流媒体系统的信息！ +具有静态插件生成器 Jekyll 或 Cactus 的功能完备的多用户 CMS 和 Wordpress 等丰富的插件生态系统仅领先几年。 但是自从我上一篇文章发表以来，人们一直在向我发送其他静态生成器的参考，并且工具的发展也多种多样。 毫无疑问，Jekyll 确实是“像黑客一样博客”，因此具有您所期望的所有粗糙边缘。 例如，一个拥有很多帖子（例如您的帖子）的网站将需要进行认真的组织以使其在 Jekyll 中易于管理。 -## 相关文章 +我确实喜欢这种设置的分散性。 我可以从任何地方写信并更新网站。 鉴于我是唯一的作家，所以自然缺乏并发:-)但是能够在您可能没有本地安装 jekyll 的地方写文章也是我当然也想做的事情。 我喜欢 Ted Kulp 在[《自动化 Jekyll 构建](http://tedkulp.com/2011/05/22/automating-jekyll-builds/)》中所做的工作，他基本上在服务器上有一个进程在监视保管箱文件夹。 当他在其中发布帖子时，网站将重新生成并推送到 S3。 它仍然需要在某个地方的服务器，但是我很确定我可以将其外包给 Heroku，而不必自己运行某些东西。 我只是很开心地看到我可以把它推多远... -* [在 Mesos / Marathon 上部署我们的事件基础架构& Ochothon！](http://cloudengineering.autodesk.com/blog/2015/05/after-a-long-day-of-devops-to-inaugurate-the-latest-ochothon-release-i-though-id-share-quick-what-it-feels-like-deploying-ou.html) -* [Ochopod + Kubernetes = Ochonetes](http://cloudengineering.autodesk.com/blog/2015/05/ochopod_plus_kubernetes.html) -* [有限状态机的返回！](http://cloudengineering.autodesk.com/blog/2015/07/fsm.html) +这就是我对您的文章 Werner 所喜欢的，显然，您可以从整体上解决问题。 一起骑很有趣！ -纸上写的很好，但他们的服务影响了现实生活。 看一下 123D Catch，大多数时候您无法将任何数据上传到云中。 +我做了一点测试，浏览了浏览器历史记录的最后一周，并尝试进行反向工程，以通过静态生成器（比 Werner 的更高级的生成器，可以用我的想象力）来提供多少内容，一旦获得 过去搜索引擎的搜索结果，并排除了我的个人网站（电子邮件，Twitter，Facebook 等），基本上所有页面都可以设置（我编造了这个词，需要简短说明）。 -我有一个基本问题。 您为什么选择使用 RabbitMQ 与 2 层进行黑白通信？ 这与使用 Kafka 进行交流有何不同？ 从理论上讲，Coz 甚至支持在散列上进行分区，并且也很耐用。 +在规模化或系统简化的对话中，几乎从未提及过标准化。 一旦对网站进行了注册，则在提供服务的方式上就根本不同：将 PHP-mysql 堆栈提供的页面与 S3 存储桶或 Akamai 边缘服务器提供的页面进行比较，大约等于 1。 系统资源方面的差异为 10K FOLD（如今，可以通过单核完成 c10K）。 -同样，在使用 kafka 的情况下，更多的是流处理的情况。 请指教.. \ No newline at end of file +身份认证可以应用于很多网页（不仅是博客），但是 AFAIK 并没有很好的食谱（任何人都知道吗？），并且它似乎并不是大多数开发人员常用的工具（或者也许是 只是不够性感而无法获得大量媒体报道）。 + +就我个人而言，我非常乐于将任何和所有功能（出于某种原因）推到尽可能远地远离后端（即数据库）和尽可能远地进入前端（即浏览器）的位置，这是扩展和尊重数据的关键 本地化，因此感谢你们俩提醒人们使用此技术：多动脑筋意味着多用户 CMS 静态生成器就近了，所以我可以更快地得到我的网页：）。 + +Bing 网站搜索小部件已于 2011 年 2 月撤消。 + +http://www.bing.com/community/site_blogs/b/webmaster/archive/2011/04/19/bing-com-siteowner-shut-down-options-for-search-results.aspx + +关于允许用户向 HighScalability 添加/编辑内容的方式：如果将静态站点文件保存在{git，hg，bzr}存储库中，则可以允许用户克隆本地存储库，进行更改然后推送 它们返回给您，您可以在此处查看并推送到 S3。 这样做甚至可能会为您的 Dropbox 节省一些空间，因为您可以在 Dropbox 上保留一个裸{git，hg，bzr}仓库，然后将其推送并拉到本地计算机上。 我对很多代码都这样做，而且即使我没有互联网连接（因此无法推送到 github），我也很喜欢，我可以做一个`git push dropbox master`并知道下一次我 连接后，我的存储库将备份到我的 Dropbox。 + +关于@Jonathon Prior 的声明，我前不久在 HN 上看到了这一点：http://jeffkreeftmeijer.com/2011/introducing-tapir-simple-search-for-static-sites/ + +保罗，那是硬核，但很有趣。 我的第一个念头是那种方法会使人吓跑，但也许不会。 我没有得到我想要的贡献，也许 git 方法会更有吸引力？ + +乔纳森，谢谢你。 当我可以在 Bing 的网站上找到搜索时，我以为是我。 ir 看起来很有趣。 + +在我看来，最好的方法仍然是在需要时静态使用 AJAX。 IOW，以静态方式提供 html / css / javascript 文件，然后让 javascript 为您创建“动态”页面。 由于客户端计算机正在执行 GUI 处理工作，而不是服务器，因此这有助于扩展。 + +当然，仍然需要“动态” REST 端点等。这种分离对于轻松开发基于同一数据源的多个用户界面也非常有用。 + +我猜这完全符合您提到的“混搭”文化。 :) + +这是一篇很棒的文章，强调了主要提供静态内容的优势。 现实情况是，大多数站点只能以最少的动态内容获得成功，而且很多站点实际上还是静态的。 使用 Bricolage 在 www.groupcomplete.com 上发布我们的网站已经取得了巨大的成功。 Bricolage 并不是新手或花哨的东西，但是在将内容与模板分离，将最终结果内容推送到我们的服务器方面做得非常出色，确实消除了担心动态 CMS 是否崩溃或遭受最新安全漏洞的麻烦。 。 + +“ ... Web 服务器或 OS 可以轻松地将流行的页面缓存在内存中，并像肯塔基州德比的薄荷糖一样为它们提供服务...” + +那接近文学。 做得好。 + +有趣的是，大型企业维护的大多数公司网站都依赖这种方法，而大多数企业级 CMS 实际上是“离线”的。 在 IT 运营和安全性方面，这种方法有很多好处。 但是，主要原因是这些 CMS 具有早期 Web 时代的传统，而动态网站是异国情调的。 这样事情就转了一圈了。 + +您是否可以在某个地方使用私人 CMS 来编辑和维护页面文本（必须通过 Jekyll 或所需的任何生成器来维护授予的 CSS）-这样，如果您在 CMS 中编辑了页面，则可以通过以下方式轻松地更新静态网站： 只是从数据库中实时再生？ + +这可能允许 wordpress 安装在您的桌面安装上变为私有-然后将 static 推送到 S3。 两全其美-在 CMS 中易于使用的编辑-快速的网站服务以及消除了互联网使用的数据库调用？ + +准系统 CMS 是生成 CMS 的静态文件。 内置缓存足以满足大多数用途，但是如果您将 nginx 之类的服务器放在前面，并使用一些特殊规则查找缓存文件，则只需提供直接生成的缓存内容，从而完全绕过 PHP。 这样，除了硬件可以提供静态内容的速度有多快之外，您显然对系统性能没有任何限制。 它尚未完全可以用作博客，但将 Barebones CMS 变成一个似乎并不困难。 + +高可扩展性！ 同类中最好的。 + +进入静态站点-博客引擎 MovableType 支持静态发布-http://www.movabletype.org/documentation/administrator/publishing/static-and-dynamic-publishing.html 用于高流量博客。 如果我们通过 javascript 处理动态内容，则静态发布会非常有用。 + +谢谢 + +甚至以慢而着称的 CMS 都会吃掉几乎所有可能的早餐负载，除非您在体系结构上不满意，例如，将 Apache KeepAlive 保留下来。 + +我想看一个像 jekyll 这样的博客生成器，但是像 frontpage 这样的 gui（显然，生成更好的代码） \ No newline at end of file diff --git a/docs/76.md b/docs/76.md index aa4003f..fb62175 100644 --- a/docs/76.md +++ b/docs/76.md @@ -1,288 +1,45 @@ -# Google 如何创造只有他们才能创造的惊人的数据中心网络 +# Pud 是反堆栈-Windows，CFML，Dropbox，Xeround，JungleDisk，ELB -> 原文： [http://highscalability.com/blog/2015/8/10/how-google-invented-an-amazing-datacenter-network-only-they.html](http://highscalability.com/blog/2015/8/10/how-google-invented-an-amazing-datacenter-network-only-they.html) +> 原文： [http://highscalability.com/blog/2011/8/31/pud-is-the-anti-stack-windows-cfml-dropbox-xeround-jungledis.html](http://highscalability.com/blog/2011/8/31/pud-is-the-anti-stack-windows-cfml-dropbox-xeround-jungledis.html) -![](img/03f45e60840ae56bc19c78b74d32e42f.png) +![](img/3df181c2449112fc84fefff148fcc943.png) -最近以自己的骄傲而自豪的 Google [宣布了](http://googlecloudplatform.blogspot.com/2015/06/A-Look-Inside-Googles-Data-Center-Networks.html) ： +[f * ckedcomany.com](http://www.fuckedcompany.com/) （FC）的知名度，点炸弹时代最喜欢的网站以及在我公司成为特色公司之前我一直很喜欢的网站，让我们看看他的后端：[为什么您必须嘲笑我的后端](http://blog.pud.com/post/9582597828/why-must-you-laugh-at-my-back-end)。 对于那些不记得 FC 的历史的人，TechCrunch 发布了[合适的悼词](http://techcrunch.com/2007/03/31/techcrunch-has-acquired-fuckedcompanycom/)： -> 今天在 2015 年开放网络峰会上，我们将首次揭示五代内部网络技术的详细信息。 从十年前我们的第一个内部数据中心网络 Firehose 到最新一代的 Jupiter 网络，我们已经将单个数据中心网络的容量提高了 100 倍以上。 我们当前的产品-Jupiter 织物-可以提供超过 1 PB / sec 的总 对等带宽 。 从角度来看，这样的容量足以使 100,000 台服务器以 10Gb / s 的速度交换信息，足以在不到 1/10 秒的时间内读取国会图书馆的全部扫描内容。 +> [FC]于 2000 年首次上线，在网络泡沫破灭之后，以失败者和陷入困境的公司以其独特而粗糙的风格来记录。 不到一年的时间，它吸引了众多观众，并受到了主流媒体的严重关注。 随着 2004 年创业经济的好转，该网站获得的大部分关注都消失了。 但是，仍然有大量忠实的观众留在网站上，由于其在新闻上的独特倾向，日复一日地回来。 在鼎盛时期，FC 每月有 400 万独立访问者。 -Google 的数据中心网络是使 Google 真正发挥作用的背后的魔力。 但是什么是“双向带宽”，为什么重要呢？ 早在 [不断变化的架构中，我们讨论了双向带宽：新的数据中心网络将使您的代码和数据免费](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) 。 简而言之，双向带宽是指 Google 服务器用来相互通信的网络。 +令人高兴的是，FC 并非实名网站。 顽强的机智犬儒主义统治了一切，看不到一只猫的照片。 当周围都是黑暗时，这真是一种乐趣。 -历史上，数据中心网络的定位是与用户交谈。 假设某网页请求来自浏览器。 该请求将发送到服务器，并通过仅与其他几台服务器（甚至根本没有服务器）进行通信来制作答复，然后将答复发送回客户端。 这种类型的网络称为面向北方/南方的网络。 实施请求几乎不需要内部沟通。 +因此，当我看到 Pud 的帖子时，我很感兴趣地看看他在做什么。 我没有失望。 这是适当的特质： -随着网站和 API 服务的日趋丰富，这一切都发生了变化。 现在，可以进行 [数以千计的](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) 后端请求来创建单个网页。 令人振奋。 这意味着通信已从与用户交谈的主导转变为与数据中心内其他计算机的交谈。 因此，这些被称为东西方网络。 +* **Windows Server 2008** -像 GUI，几乎像 AWS 上的 Linux 一样便宜，可以完成您需要的所有东西 +* **IIS 7** -完成您需要的所有内容 +* **ColdFusion 标记语言**-完成您需要的所有内容 +* **Xeround.com 用于数据库**-看起来很有趣 +* **5 个 EC2 微型实例**-每个服务器每月$ 20。 发现 micro 的性能和 xlarge 实例的性能一样好，所花的钱更少。 另外，您还将获得 5 倍的冗余。 可以在需要时插入弹性酱。 +* **弹性负载平衡**-用于将 5 个微型实例连接在一起。 +* **Dropbox** -更改代码后，所有服务器都使用 Dropbox 进行同步。 更改几乎立即同步到所有框。 不要忘记，[亚马逊的 Werner Vogels](http://highscalability.com/blog/2011/8/22/strategy-run-a-scalable-available-and-cheap-static-site-on-s.html) 也使用了 Dropbox。 巧合还是光彩？ +* **备份**-默认情况下，DropBox 保留异地备份。 JungleDisk 还每天晚上运行并通过电子邮件发送结果。 -向东方/西方主导的通信方式的转变意味着数据中心网络需要不同的 [拓扑结构](https://en.wikipedia.org/wiki/Network_topology) 。 旧的传统 [胖树](https://storagemojo.com/2008/08/24/fat-trees-and-skinny-switches/) 网络设计已经淘汰，需要采取一些新的方法来代替它。 +毫无疑问，Pud 期待着这种反感： -Google 一直处于开发新的丰富服务支持网络设计的最前沿，这主要是因为他们的指导思想是将 [数据中心视为计算机](http://research.google.com/pubs/pub35290.html) 。 一旦您的数据中心成为计算机，您的网络就相当于一台计算机上的 [背板](https://en.wikipedia.org/wiki/Backplane) ，因此它必须尽可能快且可靠，因此远程磁盘 并且可以像访问本地存储一样访问远程存储。 +* 这些应用程序可以自行运行并具有可扩展性。 +* 可以不要酷。 -Google 的工作围绕着三个有计划的攻击计划：使用 [Clos 拓扑结构](https://en.wikipedia.org/wiki/Clos_network) ，使用 [SDN](https://www.youtube.com/watch?v=ED51Ts4o3os) （软件定义网络），并以自己的 Googlish 方式构建自己的自定义设备。 +评论和 [Reddit](http://www.reddit.com/r/programming/comments/jz7p9/why_must_you_laugh_at_my_back_end/) 和 [HackerNews](http://news.ycombinator.com/item?id=2942129) 上的很多人都陶醉于此堆栈的 s 谐之中。 但这真的很烂吗？ -到目前为止，我们对 Google 的网络设计的了解有限。 Google 研究员和 Google 联网技术负责人 [Amin Vahdat](http://research.google.com/pubs/AminVahdat.html) 虽然没有完全访问权限，但在 精彩演讲： [ONS [开放网络峰会] 2015：星期三主题演讲](https://www.youtube.com/watch?v=FaAZAII2x0w) 。 还有一篇论文： [Jupiter Rising：Google 数据中心网络](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf) 的 Clos 拓扑和集中控制的十年。 +* 他知道堆栈。 +* 他得到了它的工作。 +* 它适用于预期的目的。 +* 他有时间去做更重要的事情。 +* 他赚钱。 -为什么要比通常提前发布细节？ 谷歌与亚马逊之间存在真正的竞争，因此他们需要找到引人注目的差异化点。 谷歌希望他们的数据中心网络就是其中之一。 +Pud 的体系结构中显然有一个自然的过程正在起作用，这表明。 它不是使用最佳实践或参考设计来定义的，而是根据需求和能力明确展现出来的。 我在此设置中看到很多 [wabi-sabi](http://en.wikipedia.org/wiki/Wabi-sabi) ：*一种“不完美，无常和不完整”的美。 wabi-sabi 美学的特征包括不对称，粗糙（粗糙或不规则），简单，经济，紧缩，谦虚，亲密和欣赏自然物体和过程的固有完整性。* -那么，是什么让 Google 与众不同？ 整体讯息： +那很烂吗？ 绝对。 为了我。 一千个“假设”很容易想到。 但这有效，这是其真正的艺术。 -* 摩尔定律的终结意味着程序的构建方式正在发生变化。 +附言 -* Google 知道了。 Google 知道如何建立良好的网络并实现适当的数据中心平衡。 +即使这只是一些精心设计的笑话，结论仍然适用。 选择任何堆栈，您可以进行相同的讨论，只是争论不同的观点。 -* 您可以利用 Google 的云平台（与支持 Google 搜索的平台相同）的创新和功能来实现繁荣。 - -* 所以爬上去，网络很好！ - -够了吗？ 也许这不是一个具有广泛吸引力的信息，但它可能会找到有区别的买家的房屋。 - -我的演讲重点： - -* **我们不知道如何构建可提供大量带宽的大型网络**。 Google 说，他们的网络提供了 1 Pb / sec 的总二等分带宽，但事实证明这还远远不够。 为了支持数据中心的大型计算服务器，您需要 5 Pb / sec 的网络。 请记住，今天整个互联网可能接近 200Tb / s。 - -* **在大型群集**上安排作业效率更高。 否则，您会将 CPU 留在一个地方，将内存留在另一个地方。 因此，如果您可以正确地构建系统，那么数据中心规模的计算机将为您带来确定的规模经济。 - -* **Google 利用从服务器和存储世界中汲取的经验教训构建了数据中心网络系统**：横向扩展，逻辑上集中化，使用商品组件，从不管理任何单一组件。 统一管理所有服务器，存储和网络。 - -* **I / O 差距很大**。 阿明说必须解决，如果没有解决，我们将停止创新。 通过分类可以增加存储容量。 机会是像访问本地数据中心一样访问全局数据中心存储。 使用 Flash 和 NVM 会越来越难。 闪存和 NWM 的新层将完全改变编程模型。 注意：很遗憾，他没有扩大这个概念，我非常希望他能这样做。 阿敏，我们可以谈谈吗？ - -在一个好故事中，您所寻找的是扮演核心身份角色的角色。 在这里，我们看到 Google 运作的独特愿景来自其在构建可扩展软件系统方面的丰富经验而有机发展。 也许只有 Google 才能勇于遵循自己的愿景，并建立与公认的智慧完全不同的数据中心网络。 这需要巨大的精力。 这造就了一个好故事。 - -这是我在演讲中毫无希望的不足： - -* 十年来，数百人为这项工作做出了贡献。 - -* 自从大约 30 年前将套接字引入 BSD 以来，分布式编程就面临着同样的挑战。 这将改变。 - -* 随着摩尔定律的结束，我们对计算的思考方式必须改变，而分布式计算的方式将要改变。 - -* 计算的关键部分以及人们如何构建自己的系统都围绕存储。 - -* 我们已经看到，遵循摩尔定律，存储容量有了巨大的增长。 - -* I / O 间隙仍然存在。 处理器与他们需要处理的基础数据之间的距离正在不断增加。 - -* 我们可以认为遍布整个建筑物的磁盘可用于任何服务器。 这是太棒了。 同时，鉴于我们拥有的处理能力，它们正在越来越远地寻找。 - -* 分布式计算环境中的大规模下一代闪存仍未开发。 - -* 在计算的未来意义上，网络将扮演至关重要的角色。 - -* 联网处于拐点。 计算手段将在很大程度上取决于您构建强大网络的能力。 - -* 因此，数据中心网络是关键的区别因素。 - -* Google 建造了建筑规模的计算机。 计算一行一行，存储一行一行。 - -* 多年来，Google 建立了软件基础架构以利用其硬件基础架构： - - * GFS（2002），MapReduce（2004），BigTable（2006），Borg（2006），Pregel（2008），Colossus（2010），FlumeJava（2012），Dremel，Spanner。 - - * 这些努力中的许多已经定义了当今进行分布式计算的含义。 - -* 没有世界一流的网络基础架构，您将无法建立世界一流的分布式计算基础架构。 您如何构建像 GFS 这样的系统来利用 100,000 个磁盘，而没有世界一流的网络将它们整合在一起？ - -* Google 在网络方面的创新： - - * Google Global Cache（2006 年）：如何交付内容，包括来自世界各地的视频和静态内容） - * 守望台（2008） - * Freedome：校园级互连 - * Onix（2010 年 - * BwE（2010） - * B4：Google 的软件定义 WAN，可将全球所有数据中心连接在一起。 它比面向公众的网络更大，并且增长速度更快。 - * Jupiter（2012）：高带宽数据中心规模联网 - * Andromeda（2014）：网络虚拟化。 我们如何利用我们的基础网络基础架构，并将其拆分成单个虚拟机，以至于它们拥有自己的高性能网络？ 我们如何打开 Goog​​le 一直用于其服务（例如负载平衡，DDoS 保护，访问控制列表，VPN，路由等）的相同类型的网络虚拟化，以及如何使这些隔离网络在原始硬件上运行（如果可用） ？ - * QUIC - * gRPC：Google 内部使用的多平台 RPC，负载平衡，应用程序级流控制，取消调用，序列化，开源，HTTP / 2。 构建分布式服务的良好基础。 - -## 数据中心网络 - -* 数据中心网络与传统 Internet 网络不同。 - - * 由单个组织运营，并且已预先计划。 必须发现互联网才能看到它的外观。 您实际上知道网络在数据中心中的外观。 您已经计划好了。 您建立了它。 因此，您可以集中管理它，而不用随便发现它。 由于它是在单一组织的控制下，因此您可以运行的软件可能会大不相同。 它无需与 20 年的历史遗存进行互操作，因此可以针对您的需要对其进行优化。 - - * 吸引人们加入网络的通常是问题的美。 美丽可能意味着这是一个难题。 是否可以将问题定义为更简单，更可扩展且更容易？ - -* Google 需要一个新的网络。 大约十年前，谷歌发现传统的网络架构，包括硬件和软件，**无法满足**的带宽需求以及数据中心中分布式计算基础架构的规模。 - -* 我们可以买吗？ - - * Google 无法以任何价格购买能够满足 Google 分布式系统要求的数据中心网络。 - -* 我们可以运行它吗？ - - * 以箱为中心的部署产生了高**操作复杂性**的成本。 即使 Google 买了他们能买到的最大的数据中心网络，用于操作这些网络的模型还是围绕着具有单独命令行界面的单个盒子。 - - * Google 已经知道如何处理成千上万的服务器，就像它们是一台计算机一样，如何处理成千上万的磁盘，就像它们是一个存储系统一样。 必须像管理一千个交换机一样管理一千个交换机**的想法没有多大意义，而且似乎不必要地困难**。 - -* 我们将构建它。 - - * 受服务器和存储领域的经验启发： **横向扩展** 。 - - * 无需弄清楚如何购买下一个最大的网络或下一个最大的路由器，而是可以像使用服务器和存储一样，通过使用**个附加商品元素**来扩展交换和路由基础结构。 - - * 当出现需要**插入另一个网络元素**以提供更多端口和更多带宽时，为什么不这样做呢？ - -* 允许 Google 建立横向扩展数据中心网络的三个关键原则： - - * **Clos 拓扑结构** 。 这个想法是利用小型商品交换机来构建一个可以无限扩展的无阻塞超大型交换机。 - - * **商业硅** 。 由于 Google 并未建立广域网互联网基础架构，因此他们不需要庞大的路由表或深度缓冲。 这意味着商业硅芯片可以完成在数据中心中构建基于 Clos 的拓扑的工作。 - - * **集中控制** 。 软件代理知道网络的外观，设置路由，并对基础计划中的异常做出反应。 知道网络的形状后，管理网络要比不断尝试发现其外观要容易得多。 如果要更改网络，则可以告诉集中控制软件更改网络。 - -* 数据中心网络的方法也适用于园区网络，将建筑物连接在一起并连接到广域网。 B4 和 Andromeda 受到数据中心网络工作的启发和启发，他们多年来一直在练习构建自己的硬件和集中控制基础结构。 - -* 在过去 6 年中，数据中心带宽增长了 50 倍。 - - * 需要交付给 Google 服务器的带宽超过了摩尔定律。 - - * 这意味着要满足 Google 必须能够扩展的带宽需求，就不可能不断地淘汰旧设备并建立新的网络。 - -* 规模驱动架构。 - - * 当今的典型网络（不一定是 Google）可能具有 10K +交换机，250K +链接，10M +路由规则。 **如此规模的网络处理方式与规模较小的网络**根本不同。 - -* 为什么要建立整个数据中心规模的网络？ - - * 一些最大的数据中心拥有 10 兆瓦和 10 兆瓦的计算基础架构。 - - * 如果您无法大规模调度，则有大量的 **资源搁浅** 。 想象一下需要在共享基础结构上运行的许多不同的作业。 如果必须在一个群集的边界内调度作业，并且您有 101,000 个服务器群集，而您有 110,000 个服务器群集，那么如果可以在 10,000 个服务器群集中任意调度，则效率会好得多。 如果您可以将作业放置在 10,000 台服务器中的任何位置，而不必放在 1,000 台服务器中，那么这个数字就显得非常少。 因此，如果可以构建一个网络以扩展到整个建筑物，那么从计算和磁盘上获得的效率将更高。 这些最终成为主要成本。 该网络可能非常便宜，并且可以成为计算和存储的促成因素。 - - * “资源搁浅”是指将一个 CPU 留在一个地方，而将内存留在另一个地方（ [源](http://jturgasen.github.io/2014/10/26/tech-takeaway-012-cluster-management-at-google/) ）。 - -* 平衡您的数据中心。 - - * 一旦达到建筑物的规模，就必须确保提供足够的带宽。 - - * 不平衡的数据中心缺少**某些资源，这限制了您的价值**。 如果一种资源稀缺，则意味着其他一些资源处于闲置状态，这会增加您的成本。 - - * 通常，在数据中心规模上，最稀缺的资源是网络。 由于我们不知道如何构建可提供大量带宽的大型网络，因此网络配置不足。 - -* 带宽。 阿姆达尔还有另一部法律。 - - * 对于并行计算，每 1 Mhz 计算需要 1 Mbit / sec 的 IO。 - - * 举例来说，仅在您附近的未来数据中心中，计算服务器具有 64 * 2.5 Ghz 内核，然后为了平衡每个服务器大约需要 100 Gb / s 的带宽。 这不是本地 IO。 本地 IO 无关紧要。 您需要访问数据中心范围的 IO。 数据中心可能有 5 万台服务器； 100k + IOPS 的闪存存储，100 毫秒的访问时间，PB 级存储； 将来，其他一些非易失性存储器技术将具有 1M + IOPS，10 微秒的访问时间和 TB 的存储量。 - - * 因此，您将需要 5 Pb / s 的网络和具有相应功能的交换机。 即使超额预订比率为 10：1，这也意味着您将需要 500Tb / s 的数据中心网络来接近平衡。 从角度来看，一个 500Tb / s 的网络比今天的整个 Internet 容量更大（可能接近 200Tb / s）。 - -* 延迟。 为了实现存储基础架构分解的目标，您需要可预测的低延迟。 - - * 磁盘速度很慢，访问延迟为 10 毫秒，因此很容易使它们看起来很本地。 网络比这快。 - - * Flash 和 NVM 困难得多。 - -* 可用性。 您的计算价值很高，需要不断引入新服务器，需要将服务器升级到 1G-> 10G-> 40G-> 100G->？ - - * 无法拆除建筑物以进行升级。 投资太大了。 刷新网络和服务器必须保持不变。 旧的必须与新的一起生活，而不能完全中断很大的容量。 - - * 扩展网络无效。 无法在遍布整个数据中心的网络上进行焦土升级。 - -* Google Cloud Platform 建立在支持 Google 规模，性能和可用性的数据中心网络基础架构上。 这是向公众开放的。 希望下一个出色的服务可以利用此基础结构而无需发明它。 - -* 关键的挑战是在提供隔离的同时打开硬件的原始容量。 - -## 软件定义的网络 - -* 网络是实现下一代计算机体系结构的关键因素。 SDN 将扮演关键角色。 - -* SDN 是关于抽象并管理复杂性的软件 [控制平面](http://sdntutorials.com/difference-between-control-plane-and-data-plane/) 。 这是要超越框框。 这是关于将网络接口更改为标准协议而不是标准协议，而是关于管理复杂性，将其隐藏并可以使 10,000 台交换机看起来像一个的软件控制平面。 - -* 硬件将在那里。 您如何管理它，就像它是一个大实体一样？ 这就是服务器端，存储端和网络端的问题。 - -* Google 开始了，每个人都开始使用四柱集群网络来构建数据中心网络。 网络的大小和带宽由他们可以购买的最大路由器决定。 当需要更多容量时，他们需要使用更大的路由器来构建另一个数据中心网络。 - -* 围绕 Clos 拓扑的方法是使用商用交换芯片，并构建超过 5 代的网络，如下所示： - -## ![](img/f40720a8eb01e83f28000a41bb8fa046.png) - -* 基于 Clos 的分层拓扑结构表示在 Clos 拓扑结构中利用了商户硅片，可在建筑物规模上提供高带宽。 为机架式交换机顶部供电的同一交换机芯片将服务器连接在一起，也为聚合模块供电，这些聚合模块可在一定数量的机架之间提供连接。 相同的硅为将边缘聚合层连接在一起的脊柱层提供动力。 - -* 十年前，总带宽为 2 兆比特/秒。 最新一代的 Jupiter 结构提供 1.3 Pb / s 的带宽。 他们的 Jupiter Superblock 交换机提供 80Tb / s 的带宽，它通过 OpenFlow 托管 SDN 软件堆栈，并受到远程控制。 交换机将利用 Google 已获得的余额为所有数据中心供电。 - -## 网络控制 - -* 早期，Google 面临着如何构建其控制平面的选择。 使用现有的服务提供商相关的 OSPF，ISIS，BGP 等堆栈。或者构建自己的堆栈。 - -* 他们出于多种原因选择构建自己的。 - - * Google 十年前考虑的拓扑需要多路径转发才能起作用。 为了获得所需的带宽，需要在源目标之间建立很多路径。 现有协议不支持多路径。 他们是关于连通性的。 查找从源到目的地的路径，而不是最佳路径，而不是多个路径。 - - * 十年前，还没有高质量的开源堆栈。 - - * 所有协议都是基于广播的，而 Google 希望以此规模运作，他们担心基于广播的协议的可扩展性。 - - * 安装基于广播的协议后，您必须配置每个单独的框以使用它们，而 Google 对此并不满意。 - -* 将这一切与从 Google 学到的新常规知识结合在一起，以大规模构建大规模系统： - - * **逻辑上将** （这并不意味着单个服务器）集中在具有点对点数据平面的分层控制平面的情况下。 看到它一遍又一遍地播放，并且也与数据中心网络一起播放。 - - * **向外扩展** 比向上扩展方便得多。 使用 GFS，MapReduce，BigTable 和 Andromeda 可以看到这种情况。 - - * **集中式配置和管理** 大大简化了系统的所有方面以及部署。 - -## 相关文章 - -* [在 HackerNews](https://news.ycombinator.com/item?id=10037960) 上/ [木星在 HackerNews](https://news.ycombinator.com/item?id=9977414) 上崛起 - -* [Google 在大规模定义软件定义的网络功能虚拟化方面的经验](https://www.youtube.com/watch?v=n4gOZrUwWmc) （Google 视频，2014 年） - -* [直观地了解 Google 在全球网络基础架构中的创新](http://googlecloudplatform.blogspot.com/2015/08/a-visual-look-at-googles-innovation-in.html) - -* [撤消 Google 网络基础架构上的帷幕](http://googleresearch.blogspot.com/2015/08/pulling-back-curtain-on-googles-network.html) - -* [Google 数据中心网络内部的外观](http://googlecloudplatform.blogspot.com/2015/06/A-Look-Inside-Googles-Data-Center-Networks.html) （Google 博客文章 [在 HackerNews](https://news.ycombinator.com/item?id=9734305) 和 [在 Reddit 上](https://www.reddit.com/r/sysadmin/comments/3a7kwc/a_look_inside_googles_data_center_networks/) ） - -* [木星崛起：Google 数据中心网络中 Clos 拓扑和集中控制的十年](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf) （Google 论文，2015 年） - -* [服务提供商网络的 SDN 堆栈](https://www.youtube.com/watch?v=ED51Ts4o3os) （Google 视频，2012 年）。 - -* [Show 222-介绍 OpenClos 项目](http://packetpushers.net/show-222-introducing-openclos-project/) （来自 Packet Pushers 的网络实体） - -* [Google 向其最高机密的数据中心敞开大门](http://www.wired.com/2012/10/ff-inside-google-data-center/) （有线，2012 年） - -* [不断变化的体系结构：新的数据中心网络将使您的代码和数据自由自如](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) （来自 HighScalability） - -* [VL2：可扩展且灵活的数据中心网络](http://research.microsoft.com/apps/pubs/default.aspx?id=80693) （微软提供的文件） - -* [Google On Latency Tolerant Systems：由不可预测的部分组成可预测的整体](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) （来自 HighScalability） - -* [介绍数据中心结构，下一代 Facebook 数据中心网络](https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network) - -* [云系统管理的实践：设计和操作大型分布式系统](http://the-cloud-book.com/) （看起来像一本好书） - -* [十年来 Google 自家的数据中心网络](http://www.theplatform.net/2015/06/19/inside-a-decade-of-google-homegrown-datacenter-networks/) - -* [技术要点 012：Google 的集群管理](http://jturgasen.github.io/2014/10/26/tech-takeaway-012-cluster-management-at-google/) - -* [评估仓库规模计算中的工作包装](http://www.e-wilkes.com/john/papers/2014-IEEECluster-job-packing.pdf) - -* [万亿级计算-事实还是虚构？](http://www.ipdps.org/ipdps2013/SBorkar_IPDPS_May_2013.pdf) - -* [使数据中心的高效率和低延迟实现协调](http://web.stanford.edu/~davidlo/resources/2015.thesis.pdf) - -* [ONS 2015：星期三主题演讲-Mark Russinovich](https://www.youtube.com/watch?v=RffHFIhg5Sc) -微软在网络领域的发展。 - -这是对现代 Web 规模数据中心网络的很好描述。 Clos 面料又是新的了。 - -除了谷歌，其他大公司也在做类似的事情。 例如，Microsoft 正在将 BGP 与 SDN 控制器一起使用。 - -至少可以说，这是进入数据中心工程的激动人心的时刻！ - -去年在英特尔开发人员论坛（IDF 2014）上宣布了“ Fabrics 上的 NVMe”协议。 它应该标准化对低延迟 NVM 设备的远程访问。 - -在您写“今天整个互联网可能接近 200Tb / s”的地方，您的意思可能是 200Pb / s，对吗？ - -一篇关于 CloS 面料的好文章。 - -Google 的体系结构可能适合搜索，但是 Google 的后端存在可靠性问题，只需浏览一下 Google Drive 论坛，所有用户报告丢失的数据即可。 - -非常有趣的细节！ - -亚历山德罗，我回去检查。 他肯定说大约在 19:26 时，Internet 的速度约为每秒 200 兆位，尽管他说很难知道确切的数字。 - -@Alessandro Alinone，那条大约 200Tb / s 的线路也把我甩了！ - -非常好的描述。 \ No newline at end of file +哇，我差点忘了这个网站。 我听说有关该想法的最新观点，http：//www.officeleaks.com \ No newline at end of file diff --git a/docs/77.md b/docs/77.md index 7ea791b..cf8766a 100644 --- a/docs/77.md +++ b/docs/77.md @@ -1,93 +1,34 @@ -# 阿尔及利亚通往全球 API 第 3 部分的愤怒之路 +# 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术 -> 原文： [http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html) +> 原文： [http://highscalability.com/blog/2011/9/26/17-techniques-used-to-scale-turntablefm-and-labmeeting-to-mi.html](http://highscalability.com/blog/2011/9/26/17-techniques-used-to-scale-turntablefm-and-labmeeting-to-mi.html) -![](img/46cc8fc72a878ff2f3c224caacde9f99.png) +![](img/3f78e30a68add9fe1ac9979800d3adf4.png) -我们为开发人员和开发人员回答的最常见问题是关于 [我们的架构](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 以及我们如何实现如此高的可用性。 他们中的一些人对裸机服务器的高可用性持怀疑态度，而另一些人则对我们如何在全球范围内分发数据持怀疑态度。 但是，我更喜欢的问题是“初创企业如何建立这样的基础架构”。 的确，对于一个年轻的公司，我们当前的架构令人印象深刻： +在[如何在一个月内启动并扩展到一百万用户](http://www.jperla.com/blog/post/how-to-launch-in-a-month-scale-to-a-million-users)，[前技术副总裁兼 Turntable.fm 的创始团队 Joseph Perla](http://twitter.com/jperla) 分享了他用来构建和快速扩展的技术 他的创业公司。 该帖子写得很好，必须阅读。 这里是要领： -* 我们的高端专用计算机在全球 13 个地区托管，拥有 25 个数据中心 +1. **保持简单。** 在制作网站或移动应用之前，请构建 API。 保持界面小巧，用途单一。 +2. **正确处理。** 从一开始就内置自动化测试。 创建功能测试，模块级别测试和完全集成测试。 对每个提交运行测试。 存在错误时，无需编写新代码。 +3. **不要隐藏力量。** 使用 [Pebbles](http://www.jperla.com/blog/post/write-bug-free-javascript-with-pebbles) 编写无错误的 Javascript，该库通过在代码中添加一些额外的 HTML 标记来编写 0 个 javascript，从而创建复杂的 AJAX 交互。 +4. **使用过程参数可提供接口的灵活性。** 通过函数而不是参数来支持复杂的场景。 例如，过滤器函数返回布尔值。 +5. **留给客户端。** 保持服务器简单，并将尽可能多的功能移至客户端。 +6. **连续性。** 保持接口稳定。 版本从一开始就是接口。 +7. **保守实现的秘密。** 保持服务实现完全独立，以提供最大的灵活性来处理需求更改，即使这意味着性能会略有下降。 +8. **再次使用一个好主意，而不是一概而论。** 复制和专用化类似代码而不是创建一个更通用的库是可以的。 +9. **通常分别处理正常情况和最坏情况。** 代码应该清楚地显示特殊情况，而不是使用更通用的算法来删除特殊情况。 +10. **如果有疑问，请以固定方式拆分资源。** 服务器应为单一用途。 例如，将数据库索引和搜索索引保留在单独的计算机上。 然后可以独立缩放它们，而不会彼此脚。 +11. **如果可以，请使用静态分析。** 在签入时运行对代码的堆栈分析工具，以查找错误和性能问题。 +12. **从方便的表示形式动态转换为可以快速解释的形式。** 例如，用于 tweet 过滤的 Python 特定于域的语言易于编程，可以直接转换为 python 字节码。 +13. **缓存可解决昂贵的计算问题。** 不言自明，，但请注意缓存失效问题。 +14. **如有疑问，请使用蛮力。** 最好使用简单的算法更快地完成功能，而不是延迟实现聪明的算法。 +15. **尽可能在后台计算。** 在 Web 服务器中做尽可能少的工作，将其排队到后台进程。 +16. **尽可能使用批处理。** 加载单个数据项的速度很慢，请大批量加载它们。 +17. **减少负载以控制需求。** 可以有限制。 选择使您的软件正常工作的限制，而无需经过巨大的努力或更改堆栈。 -* 我们的主从设置会在至少 3 台不同的计算机上复制我们的搜索引擎 +## 相关文章 -* 我们每个月处理超过 60 亿个查询 +* [有关计算机系统设计的提示](http://research.microsoft.com/en-us/um/people/blampson/33-Hints/WebPage.html)，作者：Butler W. Lampson -* 我们每个月接收和处理超过 200 亿次写操作 +如果说基于 JavaScript 构建一个 api，则不确定“将其交给客户端”始终是正确的方法。 +如果该产品在紧凑型市场中，您将考虑使用一个简单的 api 来快速实施，并使用更复杂的服务器端 -就像罗马不是一天建成的，我们的基础架构也不是很好。 本系列文章将探讨我们在构建基础架构时采取的 15 个工具步骤。 我什至将讨论我们的中断和错误，以便您了解我们如何使用它们来改进我们的体系结构。 - -此系列的 [第一篇博客文章](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html) 专注于我们早期的 Beta 版， [第二篇文章](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html) 在服务的前 18 个月，包括我们的首次停机。 在上一篇文章中，我将描述我们如何将“启动”架构转换为能够满足大型上市公司期望的新事物。 - -## 步骤 11：2015 年 2 月 - -### 启动我们的全球同步基础架构 - -在这个月中，我们实现了自 2014 年 4 月以来一直致力于的愿景，即“向全球扩展以更好地为我们的用户服务”。 - -该网络由 12 个不同的位置组成：美国东部（弗吉尼亚州），美国西部（加利福尼亚州），澳大利亚，巴西，加拿大，法国，德国，香港，印度，日本，俄罗斯和新加坡。 最重要的是，我们还启动了“分布式搜索”功能。 使用此功能，只需单击几下，您就可以设置网络中应该自动复制数据的位置。 您将使用与以前相同的 API，查询将自动从最终用户的浏览器或移动应用程序路由到最近的位置。 - -这是减少最终用户延迟并通过全球搜索分布提高我们的高可用性的重要一步。 由于互联网链接的距离和饱和度，从一个位置为国际用户提供服务会导致非常不同的服务质量。 现在，我们为用户提供了解决该问题的方法！ 除了减少延迟之外，这还提高了我们搜索基础架构的高可用性，因为它不再依赖于单个位置。 遍布全球！ - -有些人将我们的 DSN（分布式搜索网络）与 CDN（内容交付网络）进行了比较，但这是非常不同的。 我们不会在每个边缘存储您经常查询的缓存。 我们存储您所有数据的完整副本。 我们可以从边缘位置本身响应任何查询，而不仅仅是最流行的查询。 这意味着，当您选择三个 POP（美国东部，德国，新加坡）时，欧洲的用户将前往德国，亚洲的用户将前往新加坡，美国的用户将前往美国东部。 所有 POP 都将响应查询，而不必与其他边缘进行通信。 这在用户体验和高可用性方面产生了巨大的差异。 - -为了支持此更改，我们更新了 API 客户端中的重试逻辑，以首先定位 [APPID-dsn.algolia.net](http://appid-dsn.algolia.net) 主机名， 使用基于 geoip 的 DNS 将其路由到最近的位置。 如果最接近的主机关闭，则更新 DNS 记录以在不到一分钟的时间内删除该主机，以便返回下一个最接近的主机。 这就是为什么我们在每条记录上使用 1 分钟的低 TTL 的原因。 如果发生故障，如果主机关闭并且 DNS 尚未更新，我们将通过 [APPID-1.algolia.net](http://appid-1.algolia.net) 上的重试将流量重定向到主区域。 ， [APPID-2.algolia.net](http://appid-2.algolia.net) 和 [APPID-3.algolia.net [ 我们的官方 API 客户端中的](http://appid-3.algolia.net) 。 这种方法是我们在高性能和高可用性之间找到的最佳平衡，万一发生故障，我们只会在一分钟内降低性能，但 API 仍可以运行&！ - -## 步骤 12：201 年 3 月 - -### 每个位置的更高可用性 - -分布式搜索网络选项可改变游戏规则，以实现高可用性，但仅适用于搜索用户和国际用户。 为了提高主要区域的高可用性，我们在两个完全独立的提供商中分布了我们的美国集群： - -* 两个不同位置的数据中心（例如：Manassas 中的 COPT-6 & Ashburn 中的 Equinix DC-5：彼此之间 24 英里，延迟为 1ms） - -* 三台不同的计算机-就像以前一样（两台在不同可用性区域中的第一个数据中心，另一台在第二个数据中心中的） - -* 两个不同的自治系统（所以两个完全不同的网络提供商） - -这些更改提高了我们对遇到的某些问题（例如提供商和 AWS 之间的对等链接的饱和）做出反应的能力。 拥有不同的提供商可以使我们选择将流量重新路由到其他提供商。 就提高一个位置的高可用性而言，这是一大进步。 - -## 步骤 13：2015 年 4 月 - -### 随机文件损坏头痛 - -对于我们的制作团队来说，2015 年 4 月是一个黑色的月份。 由于某些 SSD 的 TRIM 实现中存在错误，我们开始观察生产机器上的随机文件损坏。 您可以在 [此博客文章](https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/) 中详细阅读该问题。 我们花了大约一个月的时间来跟踪问题并正确识别。 在这段时间里，我们怀疑一切，从我们自己的软件开始！ 这也是对我们的体系结构的重大考验。 在磁盘上随机破坏文件不是一件容易的事。 通知我们的用户由于磁盘已损坏而需要重新索引其数据也不容易。 幸运的是，我们从未丢失任何客户数据。 - -我们的架构中有两个重要因素使我们能够面对这种情况而不会丢失任何数据： - -* 我们存储了三个数据副本。 在三台计算机上随机破坏相同数据的可能性几乎为零（并且没有发生）。 - -* 更重要的是，我们没有复制索引结果。 相反，我们复制了从用户那里收到的操作，并将其应用于每台计算机。 由于一台受影响的机器无法“污染”另一台机器，因此这种设计使几台机器具有相同损坏的可能性非常低。 - -设计架构时，我们从未考虑过这种情况！ 即使我们试图考虑所有类型的网络和硬件故障，我们也从未想象过内核错误甚至固件错误的后果。 我们的设计要有独立的机器，这是我们能够最小化问题影响的原因。 对于任何需要高可用性的系统，我强烈建议这种独立性。 - -## 步骤 14：2015 年 5 月 - -### 引入了多个 DNS 提供商 - -由于 NSONE 出色的 DNS API，我们决定将其用作 DNS 提供程序。 我们能够配置我们希望如何通过他们的 API 路由每个用户的查询。 我们也非常喜欢他们如何支持 edns-client-subnet，因为这对于提高地理路由的准确性至关重要。 这些功能使 NSONE 成为了出色的提供商，但是我们在架构中仅拥有一个提供商就不会给自己带来风险。 - -面临的挑战是在不损失 NSONE 的所有强大功能的情况下引入第二个 DNS 提供商。 这意味着不能在同一域上拥有两个 DNS 提供程序。 - -我们决定在 API 客户端中使用重试策略来引入第二个 DNS 提供程序。 所有 API 客户端首先尝试与 [APPID-dsn.algolia.net](http://appid-dsn.algolia.net) 联系，如果有任何问题，他们将在其他域，TLD 和 提供者。 我们决定使用 AWS Route 53 作为我们的第二个提供商。 如果有任何问题，API 客户端将在 [APPID-1.algolianet.com](http://appid-1.algolianet.com) ， [APPID- 2.algolianet.com](http://appid-2.algolianet.com) 和 [APPID-3.algolianet.com](http://appid-3.algolianet.com) 定位于主群集的 3 台计算机。 这种方法使我们能够将 NSONE 的所有有趣的地理路由功能保留在 algolia.net 域上，同时引入第二个提供商以在 algolianet.com 域上提供更高的高可用性。 - -## 步骤 15：2015 年 7 月 - -### 每个群集三个完全独立的提供程序 - -您现在可以考虑使用我们开发的基础架构，我们现在完全可以应对任何问题……但是实际情况有所不同。 即使使用由具有多个可用区的 Cloud Provider 托管的服务，您也可能会停机。 我们看到两个主要原因： - -* 链接/路由器开始产生数据包丢失。 我们已经在美国东部和美国西部之间多次看到这种情况，包括大型云提供商的边界 ISP 路由器，尽管他们甚至没有意识到这一点。 - -* 路由泄漏。 这尤其影响了很大一部分 Internet 依赖的大型参与者。 - -现在，我们在美国改进的设置使我们能够构建跨多个数据中心，多个自治系统和多个上游提供商的集群。 就是说，为了接受索引操作，我们需要配置大多数计算机，这意味着三台计算机中的两台。 当使用两个提供程序时，如果我们的一个提供程序出现故障，尽管搜索仍然可用，但我们可能会失去索引服务。 这就是为什么我们决定进一步在三个完全独立的提供商（在相互靠近的位置上依赖于不同上游提供商和自治系统的位置的不同数据中心）中托管群集的原因。 这种设置使我们能够通过超冗余基础架构提供高可用性的搜索和索引。 我们提供所有这些以及相同的易于使用的 API！ - -## 建立高度可用的架构需要时间 - -我希望我们的旅程细节能够启发人心，并提供有关我们的开始方式和今天的状况的有用信息。 如果您是一家初创企业，请不要担心一开始就没有完善的基础架构。 这是意料之中的！ 但是您应该考虑您的体系结构以及如何尽早扩展它。 我什至建议您在 Beta 版之前进行操作！ - -尽早设计**架构是我们的秘密武器**。 一旦市场适应，我们就可以专注于执行。 即使在今天，我们在可伸缩性/可用性方面仍具有一些功能，这些功能在很早之前就已设计并尚未实现。 但是他们肯定会在不久的将来到来的:) - -*以下是该系列的所有三个部分：[第 1 部分](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html)，[第 2 部分](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html)，[第 3 部分](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html)* - -*[关于 HackerNews](https://news.ycombinator.com/item?id=9956097)* \ No newline at end of file +＃8 是最简单但经常被忽略的问题之一。 开发人员通常尝试在模式中寻找任何类型的通用性，以证明将抽象功能集成到单个通用组件中是合理的。 有时这是一个好主意，但有时它只会创建难以管理的代码，并且可能对性能产生负面影响。 做好一件事情，而不是少做一件事情。 \ No newline at end of file diff --git a/docs/78.md b/docs/78.md index ddd1f87..68fbb31 100644 --- a/docs/78.md +++ b/docs/78.md @@ -1,183 +1,105 @@ -# 为社交产品设计后端 - -> 原文： [http://highscalability.com/blog/2015/7/22/architecting-backend-for-a-social-product.html](http://highscalability.com/blog/2015/7/22/architecting-backend-for-a-social-product.html) - -![](img/8fee856c39b9795d6939cfabda5e19da.png) - -旨在帮助您做出关键的体系结构决策，这将使社交应用程序成为真正的下一代社交产品。 提议的更改解决了以下属性： a）可用性 b）可靠性 c）可扩展性 d）扩展的性能和灵活性（非修改） - -## 目标 - -a）确保用户的内容易于发现并且始终可用。 - -b）确保推送的内容不仅在语义上相关，而且从用户的设备角度来看也相关。 - -c）确保生成，推送和分析实时更新。 - -d）着眼于尽可能节省用户的资源。 - -e）无论服务器负载如何，用户的体验都应保持不变。 - -f）确保整体应用程序安全性 - -总而言之，我们要应对一个巨大的挑战，我们必须应对庞大的海量，不断扩大的用户生成内容，不断增加的用户数量以及源源不断的新商品，同时还要确保出色的性能。 考虑到上述挑战，我们必须研究某些会影响整个系统设计的关键体系结构元素。 以下是一些关键决策&分析。 - -### 数据存储 - -数据存储和数据建模是要做出的关键决定之一。 社交产品有望处理多种类型的数据，因此，在为每种类型选择模型和存储之前，我们必须全面分析和理解数据，这一点至关重要。 - -第一步是确定哪些是最频繁查询的数据，哪些不是那么频繁需要的数据（用于分析的存档数据）。 对于期望以较高频率查询的数据，需要将其放置在始终可用的位置，以便更快地读写和水平扩展。 现在，即使我们的用例并未强制使用基于 RDBMS 的系统，我们仍将 MySQL 用于所有用例。 随着数据的增长，我们的读写将成为应用程序性能的瓶颈。 我们应该准备好每秒处理数十亿次查询。 - -让我们对数据进行分类： - -a）主数据或静态形式的数据，例如用户个人资料 - -b）语义数据 - -c）用户生成的内容 - -d）会话数据 - -对于我们来说，要找到对所有这些类型的数据都具有高性能的数据存储确实是很难的。 因此，我们将需要为每个数据库选择特定的数据存储。 - -**静态数据**：对于静态数据，最好选择基于文档的键和值都可查询的存储。 我们可以在这里选择建立良好的基于​​文档的存储，例如 MongoDB。 选择 MongoDB 的最大优点是它在文档级别提供 ACID 属性。 - -它可以轻松地在多个分布式数据中心内和跨多个数据中心进行扩展。 这将使我们能够使用副本集轻松维护冗余，从而解决我们的可用性问题。 - -分片是另一个要考虑的大因素，这对于确保规模&速度至关重要。 幸运的是，MongoDB 支持透明地分片。 - -**关联数据或关系数据（核心数据）**：我们的数据的大部分将在自然界中关联，例如，A 是 B 的朋友，C 是 A 和 B 的朋友。此类数据是高度语义化的数据 最适合建模为图形。 我们应该将这些数据存储在像 Neo4j 这样的图形数据库中。 优势显而易见； 它将使我们能够存储节点的所有连接以及节点本身，从而节省了计算连接数据之间关系的额外步骤。 图形数据模型还将在这里帮助我们捕获关系的属性。 当尝试探索连接的数据时，属性丰富的关系绝对至关重要。 GraphDB 支持 ACID 规则和自动索引。 - -同样，我们在可用性和可伸缩性方面的要求是相同的。 我们可以有成百上千的并发事务全部同时写入数据库以及成千上万的读取。 它应该扩展为每秒处理多个 PB 数据集中的十亿次读取。 - -我们需要一个允许动态缩放读写的系统。 要考虑的另一个因素是分片，这对于扩展我们的系统至关重要。 - -Neo4j 已经设计成可水平扩展，并具有复制功能以保证可用性。 但截至目前，它不支持分片。 选择一个时，我们可能需要更多分析。 其他选项是 FlockDB，AllegroGraph 和 InfiniteGraph。 - -**二进制数据（UGC）**：我们还必须处理与用户相关的大量二进制数据。 考虑到二进制数据的大小，要处理它并不容易。 像上面讨论的那样，我们的系统是一个需求可以在几秒钟之内运行的很高的系统（峰值），规模和可用性是决定存储位置时要考虑的最关键因素。 我们不能在这里依靠文件系统来存储我们的二进制数据。 我们必须考虑可用性和可伸缩性。 文件系统的缓存可能受 CPU 限制，因此使其冗余将需要大量的簿记工作。 相反，我们应该依靠已经可用的系统。 例如，Amazon S3，这是非常受欢迎的对象存储，具有保证的可用性，并且具有弹性。 - -我们也可以考虑使用 Google Cloud Storage 或 Rackspace Cloud Files 等。但是就报价而言，S3 显然是赢家。 - -S3 已经支持数据分区。 它根据高请求率和分区中的键数，通过将数据连续拆分为多个分区，从而水平扩展 S3。 但是重要的是要意识到仅存储内容是不够的，与这些内容相关联的元数据需要可搜索，并且搜索必须足够扩展和足够快。 我们还可以在这里尝试一些新事物，例如从图像自动识别尺寸，基于上下文自动标记等，然后使用它们来驱动图像的键*。 这是一个潜在的 IP 领域。 我们将在索引部分下研究索引需求。 但是现在，让我们仅注意，我们将使用标识符存储内容，该标识符可以在其他地方建立索引。 亚马逊的 S3 似乎最适合这种情况。 - -### 会话数据 - -重要的是认识并理解为什么我们需要考虑会话数据。 会话数据将帮助我们维护用户的状态。 而且这种状态应该以与服务器无关的方式持续，以使我们的部署规模扩大。 这将有助于我们使设计保持足够的灵活性，从而确保会话不会停留在特定的节点或服务器上。 - -我们必须以一种可以重新生成用户实际会话的方式来保存会话信息，如果用户会话终止，我们仍然可以帮助用户从他离开的地方开始。 - -在我们的市场中，连接不那么可靠，并且通常会丢包，这一点尤其重要。 这些数据需要在我们的所有节点上都可用，因此需要可用性和可伸缩性。 首先，我们可以很好地将其保存在我们的 MongoDB 中。 稍后我们可以考虑将其转移到像 REDIS 这样的纯键值存储中。 - -注意：所有推荐和脱机作业都应仅在非服务节点上运行。 - -### 索引编制 - -索引对于我们的系统至关重要。 用户可以搜索任何内容，这是我们的主要用例之一。 为了提高搜索性能，我们必须非常重视索引编制。 这里有两件事要考虑。 首先是创建索引本身，其次是创建索引系统。 - -为了使有意义的可搜索系统，我们必须设计一个实时索引，该索引被倒置并在生成的内容窗口上工作。 首先，我们可以编写一个非常简单的系统，在内容摄取期间，该系统可以负责根据内容生成反向索引。 后来，随着内容摄取负载的增加，我们可以简单地用实时数据处理引擎（例如 Apache Storm）来代替它，这是一个分布式，容错且高度可扩展的系统。 它可以接管索引逻辑的生成。 - -索引系统：Lucene 因其受欢迎程度和速度而成为显而易见的选择。 其性能无与伦比。 我们应该选择 SolrCloud。 它已经支持透明分片，复制，并且具有读写侧容错功能。 - -### 排队&推送通知 - -每次在我们的应用中触发事件时，我们都将被要求以通知的形式将该事件散发给他/她的关注者/朋友。 重要的是，我们的系统不要错过任何这些信号，万一发生故障，恢复这些事件至关重要。 为了做到这一点，我们必须寻找一个排队解决方案。 我们可以使用 ActiveMQ，这是最可靠的排队软件。 它允许群集以实现高可用性，并支持分布式排队。 - -推送通知是另一个要向我们的用户发送通知的区域。 在这里，我们需要寻找规模。 我们应该为数十亿个 nps 的规模做好准备。 这里有很多选项，但也许 pyapns，CommandIQ 和 App Booster 是最受欢迎的选项。 - -我们将需要专门管理一些事务，以确保即使用户的设备处于离线状态，也能确保通知的传递。 我建议我们实现一个基于双指针的系统，该系统维护通知的状态并在后台将其写入磁盘。 因此，每次通知失败时，都会维护其状态并使用状态标志将其添加到重试队列中。 最终，在传递通知时，将其出队。 - -### 缓存策略 - -像我们这样的系统，我们的目标是使其扩展到十亿 rps，因此智能缓存至关重要。 我们的设计将需要逻辑以多层缓存并智能地逐出它们。 让我们从顶级看什么要缓存和在哪里缓存。 - -*应用程序级缓存（内容缓存）* ：为了最大程度地减少缓存未命中并确保缓存始终保持最新的可用数据，我们必须寻找永不过时且始终可用的缓存 数据。 从本质上讲，这意味着在我们所有的一般用例中，我们将不必查询数据库，从而节省了大量资源。 我们还应确保缓存的数据始终采用不需要任何消息传递且可以随时呈现的格式。 实质上，这意味着我们会将在线负载转换为离线负载，从而节省了延迟。 为此，我们必须确保每次将内容提取到系统中时，我们都要做两件事 - -a）以一种在服务阶段不需要任何消息传递的方式对原始内容进行非规范化，然后将其保存到缓存中。 为了安全起见，我们将始终设置一个有效期限，该期限可以足够高。 - -b）原始内容也按原样写入我们的数据存储中。 - -我们非常可以依靠 REDIS 来获得此缓存，这是具有良好故障恢复能力的内存缓存。 它具有高度的可扩展性，较新的版本也允许透明分片。 并且它也支持主从节点配置。 最好的部分是它将使我们能够按原样保留本地数据结构，这使得增量写入非常容易，并且对我们支持内容提要（扇出）至关重要。 - -还要注意的是，我们将需要在大型内容对象上进行大量的读取-修改-写入操作和少量读取操作，以支持实时扇出，并且从速度的角度来看，REDIS 最适合这些操作。 - -*代理缓存 e* ：反向代理级别的缓存也很关键。 它有助于减少服务器的负载，从而保持延迟。 但是，要使代理服务器真正有效地进行缓存，正确设置 HTTP 响应标头至关重要。 有很多选择，但流行的是 nginx 和 ATS。 - -*二级缓存（代码级缓存）* ：这是实体数据的本地存储，以提高应用程序的性能。 通过减少昂贵的数据库调用，使实体数据保持在应用程序本地，它有助于提高性能。 EhCache 是​​该领域的热门选择。 - -*客户端缓存* ：这是实际的设备或浏览器缓存。 所有静态项目应尽可能多地被高速缓存。 如果 API 响应设置了正确的 HTTP 缓存头，则已经缓存了许多与资源相关的项目。 我们应该确保它按预期工作。 除此之外，我们应该使用设备自己的内存或使用 sqlite 来缓存尽可能多的其他内容。 所有昂贵的对象都应缓存。 例如 NSDateFormatter & NSCalendar，它的初始化速度很慢，应尽可能重复使用。 iOS Lot 可以在这里进行调整和使用，但这不在我们的研究范围之内。 - -### 内容压缩 - -考虑到以下事实：我们主要希望用户处理大量图像和视频，而这些图像和视频需要下载大量数据，因此优化下载大小至关重要。 它将为用户节省数据并提高应用程序性能。 - -要考虑的其他方面是我们的网络，我们的用户主要使用 2.5g 或 3g 的非 LTE 网络，其中带宽通常是一个问题，并且连接不可靠。 数据使用成本也很高。 在这种情况下，智能压缩是至关重要的。 - -但是压缩图像和视频并不是那么简单，通常需要更深入的分析。 我们处理的图像和视频可能是无损的，也有损的，这取决于用户的设备质量。 因此，我建议使用多种压缩技术来处理这种情况。 在这种情况下，我们可以尝试帧内压缩和帧间压缩技术。 - -但是总的来说，我们可以为所有压缩需求使用 zpaq 和 fp8。 我们也可以尝试 WebP，这可能对我们的市场有利。 通常，我们将在整个过程中始终使用 GZIP，所有 API 响应都将始终进行 GZIP 处理。 - -### 内容转码 - -考虑到我们将需要处理具有多个 OS 和屏幕分辨率的多个设备，因此我们的内容存储和处理应与设备无关。 但是服务层应根据具体情况而定，并应根据用户的设备功能理解并提供正确的内容。 这使得对我们的图像和视频进行转码至关重要。 - -我们的应用应收集有关内存，编码和屏幕分辨率的设备功能，并将其作为上下文传递给我们的 API。 我们的 API 应该使用此上下文来修改/选择内容版本。 根据收到的设备上下文，我们可以将内容预转码为几个最受请求的版本。 - -对于转码，我们可以使用 FFMPEG，这是最可靠，使用最广泛的框架。 我们可以根据需要修改 FFMPEG。 这也必须在摄取侧完成。 - -### 传输协议 - -考虑到我们的网络场景（非 LTE，不可靠的连接等），至关重要的是要尽可能智能地节省资源并尽可能减少通信量。 我建议对所有 HTTP 请求都使用 OkHttp 客户端，而反过来又使用 SPDY，SPDY 可以很好地抵抗连接失败并透明地恢复。 - -对于我们所有的消息传递需求，我们应该切换到 MQTT，这是一种轻量级的机器到机器连接协议。 - -### 安全 - -保护我们的应用程序确实很重要。 我们的整体体系结构应适应这一重要属性。 在这里，我仅讨论支持安全性所需的体系结构更改，而不会涉及实现性更改。 - -我们必须在架构中添加以下内容： - -1.我们所有的用户数据都必须加密。 MongoDB 和 Neo4j 已经支持存储加密。 根据情况，我们可以决定对关键用户信息进行加密。 必须为所有与数据库相关的调用启用传输加密。 - -2.安全套接字层：到我们的代理服务器的所有呼叫均应进行 SSL 加密。 代理服务器可以充当 SSL 终止点。 - -3.我们所有的 api 端点都应在非默认端口上运行，并且应实现 Oauth 而不失败。 - -4.从 DB 进行的所有读取应始终通过其余端点进行。 - -5.保存密码的配置必须特别处理。 必须对密码进行哈希处理，并且文件应被限制为只有应用程序才能在启动时读取该密码。 这使我们可以通过文件系统权限来控制应用程序身份实例。 只有应用程序用户可以阅读，但不能写，其他任何人都不能阅读。 所有这些配置都可以打包在 keydb 下，并受 pwd 限制。 - -## 组件 - -这是我们架构的组成部分： - -1.负载均衡器：这是一层，它根据确定的策略确定将请求转发到哪个代理服务器。 该层还将通过基于容量重定向流量来帮助我们保证可用性。 - -2.代理服务器：所有来电都必须在此处登陆。 这也是我们的 SSL 终止点。 它根据定义的策略缓存 HTTP 请求。 FE 层：此层运行节点服务器。 - -3.提取引擎：此组件处理所有传入的内容。 它包含与非规范化，代码转换，缓存等有关的策略。将来，如果需要，可以在此处完成所有内容的充实。 - -4\. REST Server：这是与所有 DB 进行对话并生成响应的层。 其访问受 Oauth 保护。 它可能是一个已实现边缘缓存的 tomcat 容器。 - -5.事件处理器：此层处理所有事件，并且主要负责扇出功能。 它读取 ActiveMQ 并使用通知引擎生成通知。 - -6.推荐引擎：此组件通过分析从用户活动中收集到的所有信号来推动推荐。 根据收集到的实际信号，我们可以部署各种基于亲和力的算法。 我们可以在 Apache Mahout 上进行回复，首先它已经提供了各种算法接口 - -系统的逻辑视图： - -![](img/56ca2c72ce745e5aafa4658ffa8905fd.png) - -# 结论 - -这更多是对关键组件的高级分析。 如果需要实施该建议，则不必一 implemented 而就，可以分阶段进行，但是如果我们需要扩展和支持实际用例，则必须遵循我在此处提出的模式。 我没有涉及任何设计领域。 那是在设计阶段，将需要更深入的分析和了解系统的当前状态。 - -[On HackerNews](https://news.ycombinator.com/item?id=9930752) - -谁写的？ 让他们停下来。 当他们说“很幸运，mongodb 音阶”时，我停止阅读（意译） - -写得好。 非常喜欢阅读。 这可能不适用于所有但定义良好的设计替代方案和分析。 爱它。 - -我很喜欢它。 仅需注意一点，ActiveMQ 既好又稳定，但值得探索 Kafka。 我觉得在可伸缩性方面要好得多。 总体来说真的很喜欢你的逻辑。 - -本文概述了针对特定功能（缓存，反向代理，负载平衡，通知等）的推荐软件/应用程序，并在某种程度上说明了选择的原因。 但是我认为，如果将组件抽象出来并且将更多的注意力放在系统的实际体系结构上，将会更有帮助。 例如，我在架构图上看不到任何特定于领域的语言（我无法确定应用程序在做什么），而是一组完成功能的工具。 - -非常丰富。 您是否考虑使用关系数据库而不是使用 mongodb 进行分片？ 还是其他任何数据库才可以进入？ \ No newline at end of file +# StackExchange 体系结构更新-平稳运行，Amazon 4x 更昂贵 + +> 原文： [http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html) + +![](img/5d52bff8ca298ab4abacb8a0ce387401.png) + +我们已经发表了几篇关于 [StackOverlflow Architecture](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 和 [Stack Overflow Architecture Update 的文章-每月浏览量为 9500 万页](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)。 是时候进行另一次更新了。 这次来自播客。 杰夫，乔尔（Jeff，Joel）和客人每星期大约坐在一起交谈。 结果是[播客](http://blog.stackoverflow.com/category/podcasts/)。 在最近的[播客](http://blog.stackoverflow.com/2011/09/se-podcast-17/)中，他们讨论了他们最近的一些体系结构问题，问题和更新。 自从我在休假前写这篇文章以来，他们还发布了新的体系结构更新文章： [The Stack Exchange Architecture – 2011 Edition，Episode 1](http://blog.serverfault.com/post/the-stack-exchange-architecture-2011-edition-episode-1/) 。 + +我的总体印象是他们在一个舒适的地方，添加了新的网站，添加了新的功能，使房屋成为了家。 + +以他们的向上扩展架构而闻名，您可能会期望随着他们的成长，他们会撞墙。 不是这样 他们已经能够通过增加更多的 CPU 和 RAM 来扩展单个服务器的功能。 在某些情况下已添加 SSD。 甚至他们的旗舰产品 StackOverflow 产品都在单个服务器上运行。 已经购买了新机器，但数量很少。 + +因此，StackOverflow 实验表明，即使是规模较大的站点，也都应按比例放大策略。 没错，就像早期的 Facebook 一样，他们的产品自然按照主题分开，但是摩尔定律和质量工程是您的朋友。 他们估计亚马逊将花费他们四倍的钱。 + +这是 StackExchange 所做的： + +* 他们在俄勒冈州有一个机架，在纽约的 Peer1 有两个笼子。 + * 检查电源并不会全部故障转移到单个电源，如果实际发生故障，该电源将发生故障 + * 新建了 10 台服务器 约克。 9 个生产服务器。 1 个质量检查服务器。 + * 堆栈溢出具有大型服务器，SSD 和更多 RAM。 他们在某些计算机上添加了更多的处理器和更多的 RAM，以便可以运行 Lucene + * Oregon 运行数据浏览器并进行聊天。 如果您无法到达纽约，您仍然可以聊天。 堆栈交换博客在俄勒冈运行，所有其他博客在纽约。 + * 机架非常狭窄，尤其是具有大量用于冗余电源和网络连接的电缆。 + * 应该在 Peer1 处购买机架而不是笼子。 那会给更多的空间。 + * 纽约的存在使他们更接近欧洲用户。 + * 保留俄勒冈州的位置，因为它很便宜，而且拥有另一个位置很方便。 +* 考虑具有故障转移模式，以便所有 NY 通信量都可以只读模式故障转移到俄勒冈州。 您不能提出新的问题，但是由于该站点的大部分价值都来自于阅读，因此只读站点具有价值。 + * 他们具有以下只读模式： + * 当他们将 Stack Overflow 移至其自己的数据库服务器时。 + * 当他们从俄勒冈州移居到纽约时。 + * 具有两个站点都可以处理写入的双活体系结构太复杂了。 + * 您不知道与主服务器的连接将关闭多长时间。 找出错误原因可能需要很长时间。 因此，在备份服务器上进入只读模式是正确的事情。 如果您在备用服务器上进入读写模式，那么您将更不愿意返回主服务器，直到您确定它完全死了。 + * 他们在代码中写入数据库的每个地方都实现了只读模式。 +* 运行状况仪表板提供了所有系统的总体状态。 从 SQL 数据库查询。 将所有内容存储在 SQL 中，使构建工具变得更加容易，并且可以针对当前的流量负载进行适当扩展。 + * 三个图形：CPU，内存，网络。 + * 运行大部分网络的 10 台服务器几乎未加载。 一种是峰值 16％。 即使翻了一番，他们也被严重超支。 + * 它们一次没有被过度配置。 + * 服务器已经重新配置了很多。 + * 他们已将 CPU 添加到 Web 层。 他们达到了 60％的峰值，这令人不舒服。 + * 在 Web 层中添加了 SSD，因此它们可以： + * 提高 Lucene 索引速度。 + * 加快启动 Web 层时的启动时间。 + * 固态硬盘在生命周期中处于起步阶段，要轻而易举。 + * SSD 不应使您的计算机运行得更快，因为您应该已经在 RAM 中运行了。 当数据库太大而无法放入 RAM 时，则不适用。 希望您最活跃的数据可以放入 RAM。 +* 使用商业 Orion 网络监视器。 从本质上讲，它是在为时间付费，因为它比 Nagios 更容易设置和使用。 + * 将所有数据保留在 SQL Server 上。 + * SQL 意味着很容易访问和查询。 + * Web 日志也存储在 SQL Server 中。 +* 在 SQL Server 中拥有所有数据的长期趋势。 + * 买了一台重型服务器，只是为了保存所有这些数据并能够执行实时查询。 2 个处理器，大量 RAM。 放入 13TB 的存储空间，这是一年的日志文件。 每天有 20 个演出进入 SQL Server。 + * 之所以提供帮助，是因为他们可以实时告知正在发生的事情。 当他们推出一项新功能时，他们可以知道使用了多少功能，从而告诉他们是否需要保留该功能。 他们可以通过简单的查询来完成此任务，而无需查看日志或访问 Google Analytics（分析）。 + * 他们每天创建 1 张表格来存储统计信息。 + * 他们都知道 SQL，因此可以相对轻松地提出要回答的问题。 +* Redis 服务器 + * 用作 10 个服务器之间的共享状态缓存。 可以跨服务器平衡请求。 他们不想每次都访问数据库，因此它将进入缓存。 + * 仍然是网络热议。 他们将处理粘性 IP，以便请求可以使用 Web 服务器上的内存中缓存。 这样可以消除网络命中的速度，该命中要快得多，可以直接在内存中使用它。 + * 将所有内容都放入缓存时，会遇到网络可伸缩性问题。 这不是一个无限快的管道。 +* 网络启示录 + * [微爆](http://blog.serverfault.com/post/per-second-measurements-dont-cut-it/)出现问题。 在很短的时间内爆发高达千兆位的速度，这使队列充满了。 + * 从未找到根本原因。 + * 改变了网络架构的方式。 所有网络都集中路由。 Web 服务器和数据库/ redis 服务器位于不同的网络上，因此它们摆脱了两侧之间的路由器和防火墙。 + * 他们更改了 NIC 配置。 他们联手进行了故障转移。 他们将配置更改为双活模式，并通过 NIC 负载均衡请求。 他们希望不再使用单个网卡来防止微爆。 + * 导致成本增加的原因是，如果它们从交换机运行了 10 条网络线，因为您按端口付费。 +* 令人惊讶的是，他们的流量混合了 40％的读取和 60％的写入。 +* 他们的观众中有 60％是国际观众。 +* StackExchange 大约有 45 个人。 +* CDN 使您可以处理在多个区域中运行的国际用户的 80％的方式。 + * 拥有 CDN 服务器的大部分静态资源。 + * 两个数据中心中的实时数据太难了。 需要足够的 DBA 24x7 覆盖，并在支持方面进行了大量代码更改。 +* 进入两个数据中心可能需要一个客户端引擎，例如 Facebook。 + * 客户与 10 台服务器进行对话，并说您有什么需要帮助的。 + * 客户端合并数据并显示一些结果。 + * HTML 页面是几个 div。 每个 div 独立出去都会获取页面的该部分。 页面的每个部分可能来自不同的服务器，并且全部集中在客户端。 + * StackExchange 并不是高度定制的，用户可以看到大致相同的站点，因此这并不是一个大赢家。 +* 迁移到亚马逊并不是一个好主意： + * 无法相信亚马逊的故障。 + * 亚马逊的[价格将比](http://meta.stackoverflow.com/questions/73969/what-would-stack-exchanges-yearly-expenses-be-if-it-were-to-be-using-a-third-par/73978#73978)高出 3 倍以上。 亚马逊最初购买硬件后，每月需要花费 17,000 美元，而现在每月需要支付 4,000 美元。 + * 亚马逊拥有 2007 年的旧技术，因此要实现类似的性能，他们将需要比现在更多的服务器。 + * 期望从每台计算机获得 5 年的服务。 较旧的计算机将投入使用或承担较少的任务。 + * 如果去了亚马逊，他们是否需要另一个系统管理员？ 他们可能没有想到。 亚马逊存在许多无法追踪的随机网络延迟问题。 对于高容量服装，并非全都是玫瑰。 + * 对于控制怪胎，这不是最好的模型。 他们想知道网络中正在发生的一切。 他们不断观察性能，调整 NIC 配置等。无法控制所有内容并不适合他们的工作方式。 + * 想要最好的硬件并关心每个小细节。 当您去亚马逊时，您说的是我不在乎。 + * 云是一个冗余的故事。 这就像买一千个汉堡包，而不关心 5 个腐烂的汉堡包。 那不是他们选择的模型。 + * 他们有一个重要的故事，尤其是在数据库方面。 大铁还没死。 摩尔定律还没有死。 您实际上不必花费太多时间来获得功能更强大的服务器。 不断前进。 + * 他们真正担心的唯一事情是，如果数据库中的 RAM 用完了。 他们按主题有单独的数据库，但是 Stack Overflow 太大了，它装满了一台机器，无法分片。 他们可以获得一台具有 256GB RAM 的服务器。 + +StackExchange 令人耳目一新。 他们有意识地尝试通过在[他们的博客](http://blog.serverfault.com/)中发布​​或在其[网站](http://serverfault.com/)之一上提问来公开问题。 也许您的组织可能想效仿他们的榜样？ 这是一种建立意识和信任的好方法。 + +感谢您的出色总结-非常有趣。 + +AWS 上的成本计算不是最新的或完全正确的。 我已经对原始的 SO 问题发布了更新的细分：http://meta.stackoverflow.com/questions/73969/what-would-stack-exchanges-yearly-expenses-be-if-it-were-to-be- 使用三分之一 pa / 110201＃110201 + +因此，一旦 SO 工作集通过 256GB 而又不分割所有内容，则进一步扩展工作是一个有趣的思想实验。 也许您要分解数据库，但要按功能而不是按哈希-这里是全文索引，这里是详细的表决/用户/统计数据，此处显示问题页面所需的计数和文本。 或者，如果有很多鲜为人知的档案数据，则可能在其他地方。 或者，也许您发现站点的一个或两个方面比分片*一切*（投票，统计？）更容易分片，并且减轻了关系母权带来的大量负载/ RAM 压力。 + +Randall，我同意，当数据集太大时，分离数据（而不是分片）是一种更好/更容易的启动方法。 Netflix 不久前就这样做了，这就是为什么他们的网站会因服务故障而正常降级的原因。 + +例如，“评论”可能不会显示在电影页面上，但是您仍然可以流式传输。 + +看到此博客上的“无法相信亚马逊的故障”，真是令人震惊。 + +首先，您是否真的要宣称可以比 AWS 建立更多的冗余和更多的容错能力？ 您了解如何在所有 AWS 数据中心之间进行分配吗？ + +其次，该声明是不真实的，事实是您不能 100％信任任何系统。 你建立宽容。 您是否声称无法在 AWS 上建立容忍度？ 让我们进行讨论。 + +这是另一个更新： +http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/ \ No newline at end of file diff --git a/docs/79.md b/docs/79.md index ad8d75d..8a4f643 100644 --- a/docs/79.md +++ b/docs/79.md @@ -1,121 +1,341 @@ -# 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分 +# DataSift 体系结构：每秒进行 120,000 条推文的实时数据挖掘 -> 原文： [http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html) +> 原文： [http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) -![](img/914d4bdf9db5c148d642dcbfb590ddac.png) +![](img/a850e4e8776a07063949e480bd50d469.png) -我们为开发人员和开发人员回答的最常见问题是关于[我们的体系结构](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html)以及我们如何实现如此高的可用性。 他们中的一些人对裸机服务器的高可用性持怀疑态度，而另一些人则对我们如何在全球范围内分发数据持怀疑态度。 但是，我更喜欢的问题是“初创企业如何建立这样的基础架构”。 的确，对于一个年轻的公司，我们当前的架构令人印象深刻： +我记得 Twitter 首次开放他们的消防水带时的兴奋。 作为 Twitter API 的早期采用者，我可以轻松想象可以对所有这些数据执行的一些很酷的事情。 我还记得在大数据领域，数据是有代价的，而对于像我这样的小鱼来说，代价太高了，我对此感到失望。 这就像第一次学习，不会有 BigData 圣诞老人。 -* 我们的高端专用计算机在全球 13 个地区托管，拥有 25 个数据中心 +尽管有一段时间，我很高兴思考如何处理所有数据。 这是一个令人着迷的问题。 您必须能够可靠地使用它，对其进行规范化，将其与其他数据合并，在其上应用功能，对其进行存储，进行查询，对其进行分发，然后再将其货币化。 大部分都是实时的。 而且，如果您试图创建一个平台，以允许整个 Internet 对防火墙执行相同的操作，则挑战将成倍增加。 -* 我们的主从设置会在至少 3 台不同的计算机上复制我们的搜索引擎 +DataSift 处于创建这样的烟火，数据斩波机器的令人兴奋的位置。 您会看到，DataSift 已从 Twitter 购买了多年的重新组织权，这使他们可以访问完整的 Twitter 消防水带，并能够将其子集转售给其他各方（可能是任何人），但主要目标当然是企业。 [Gnip](http://gnip.com/) 是唯一拥有这些权利的其他公司。 -* 我们每个月处理超过 60 亿个查询 +DataSift 是由 DataSift 的创始人兼首席技术官 Nick Halstead 在 [TweetMeme](http://tweetmeme.com/) 的经验基础上创建的，HTHT 是一种流行的实时 Twitter 新闻聚合器，一次可以处理每天 11 亿的页面浏览量。 TweetMeme 以发明社交信号机制而著称，该机制被称为“ retweet”，带有“ retweet”按钮，这个想法来自更早的名为 [fav.or.it](http://www.webonorme.net/blogging/launched-favorit-nick-halstead.htm) 的创业公司。 想象一下您是否会在*之前的某个时间像在整个虚拟地方贴上*按钮一样。 -* 我们每个月接收和处理超过 200 亿次写操作 +因此，大规模处理 TweetMeme 对 DataSift 的员工来说并不是什么新鲜事，而面临的挑战是将这种经验转变为 Internet 规模的平台，以便其他人也可以做同样的事情。 那是一个多年的冒险之旅。 -就像罗马不是一天建成的，我们的基础架构也不是很好。 本系列文章将探讨我们在构建基础架构时采取的 15 个工具步骤。 我什至将讨论我们的中断和错误，以便您了解我们如何使用它们来改进我们的体系结构。 +DataSift 将自己定位为实时数据挖掘平台。 这里的平台角度确实是带回家的关键信息。 他们正在追求用于处理实时流的真正平台策略。 TweetMeme 虽然取得了成功，但它并不是一家[十亿美元的公司](http://www.youtube.com/watch?v=MowmiwavILM)，但是 BigData 平台可以发展到如此之大，这就是他们前进的方向。 尼克（Nick）的货币报价突出了霓虹灯的逻辑：“按钮上没有钱，数据上有钱。” -该系列的 [第一篇博客文章](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html) 专注于我们 Beta 的早期。 这篇博客文章将重点介绍从 2013 年 9 月到 2014 年 12 月我们服务的前 18 个月，甚至包括我们的首次停机！ +平台游戏背后的部分策略是，通过围绕您的核心价值主张构建巨大的技术护城河，从而成为老牌玩家。 当其他人来敲门时，由于您进入的技术壁垒过高，他们无法越过您的护城河。 这就是 DataSift 试图做的。 护城河上的吊桥更适合使用 Twitter 的 firehose，但真正的强大之处在于他们正在尝试创建的 Google 质量实时数据处理平台基础架构。 -## 步骤 4：2014 年 1 月 +DataSift 的真正创新在于创建一个 Internet 规模的过滤系统，该系统可以快速评估非常大的过滤器（认为 Lady Gaga 的追随者规模），并结合虚拟化带来的经济效益，在这种情况下，拥有更多客户的客户可以分享资源，因此您赚得更多的钱。 -### 部署是高可用性的大风险 +他们如何使所有这些魔术发生？ 让我们来看看... -目前，我们的主要关注之一是确保我们的发展敏捷，同时又不以牺牲稳定性为代价。 因此，我们开发了一个包含 6,000 多个单元测试和 200 多个非回归测试的测试套件，以确保代码更改不会引入新的错误。 不幸的是，这还不够。 通过我们所有测试的一项新功能引入了一个生产错误，该错误导致 [八分钟的索引停机时间](https://blog.algolia.com/postmortem-todays-8min-indexing-downtime/) 。 值得庆幸的是，由于我们的体系结构旨在将搜索查询与索引分开，因此不会影响搜索查询。 +Site: [http://DataSift.com](http://DataSift.com) -此问题帮助我们确定了高可用性设置中的几个问题： +## 信息来源 -* 回滚需要很快，因此我们开发了使用单个命令行执行回滚的功能。 +* 本文末尾列出的文章和视频。 +* 主要来源是对以下人员的采访： [Nick Halstead](http://datasift.com/user/nickhalstead) ，DataSift 的创始人兼 CTO; [DataSift 的首席架构师 Lorenzo Alberton](http://www.alberton.info/) 。 -* 部署脚本需要执行完整性检查，并在出现错误时自动回滚，因此我们将其添加到了部署过程中。 +## 统计资料 -* 我们不应该仅仅因为测试通过 而部署到所有生产集群。 在此问题之后，我们对集群进行了一系列部署。 我们从测试集群开始，然后是社区集群（免费客户），最后是付费用户集群。 +* 您无法获得整个 Twitter 的水火。 如果这样做，每千条推文将收取 10 美分的费用。 每天有 2.5 亿条推文。 每天需要 2 万 5 千美元的许可费用。 +* 936 个 CPU 内核 +* 每台服务器支持 16,000 个数据流 +* 每天处理整个 Twitter Firehose 250+百万条推文。 相比之下，Visa 说，在 2007 年，他们处理了 276.12 亿笔交易，估计在一天中最繁忙的 8 小时内每秒处理 2100 笔交易。 这些都是完整的交易。 +* 当前峰值每秒传递 120,000 条推文（260Mbit 带宽） +* 执行 250+百万次情感分析，延迟不到 100 毫秒 +* 每天通过平台传输 1TB 的增强数据（包括性别，情感等） +* 数据过滤节点最多可以处理 10,000 个唯一流（每秒流过 8000+条推文的峰值） +* 可以实时对 10,000,000 个以上的用户名列表进行数据查找 +* 链接增强每天执行 2700 万个链接解析+查找，以及 15+百万个完整的网页聚合。 +* 30 名员工 +* 4 年的发展 -今天，当要测试一项新功能时，我们的部署有所不同。 我们选择一组集群进行测试，然后使用以下步骤进行部署： +## 平台 [ -1. 部署到所选集合的所有群集中的第一台计算机。 +### 使用的语言 -2. 监视 24 小时，然后部署到所选集中所有群集中的第二台计算机。 +* C ++用于关键性能组件，例如核心过滤引擎（自定义虚拟机） +* 用于站点的 PHP，外部 API 服务器，大多数内部 Web 服务以及定制的高性能作业队列管理器。 +* Java / Scala，用于与 HBase 通信，Map / Reduce 作业以及处理来自 Kafka 的数据 +* Ruby 为我们的厨师食谱 -3. 监视 24 小时，然后部署到所选集中所有群集中的第三台计算机。 +### 资料储存库 -4. 几天后，我们部署到了所有生产集群。 +* SSD 驱动器上的 MySQL（Percona 服务器） +* HBase 集群（当前，约 30 个 hadoop 节点，400TB 存储） +* Memcached（缓存） +* Redis（仍用于某些内部队列，但可能很快将被撤消） -使用这种方法，我们能够在几个小时内检测到几乎不可能通过单元测试发现的错误。 由于我们每月有数十亿的查询，因此这种检测是可能的。 +### 消息队列 -# 第 5 步：2014 年 3 月 +* 0mq（来自最新的 alpha 分支的自定义版本，已进行一些稳定性修复，以使用发布者端过滤），并用于不同的配置中： + * PUB-SUB 用于复制/消息广播； + * PUSH-PULL 用于循环工作负载分配； + * REQ-REP 用于不同组件的运行状况检查。 +* Kafka（LinkedIN 的持久性和分布式消息队列），用于高性能持久性队列。 +* 在这两种情况下，他们都与开发人员合作，并提供错误报告/跟踪/修复/客户端库。 -### 管理大量写操作 +### CI / Deployments -当我们在加拿大/东部和欧洲/西部的集群很好地处理了我们的增长时，我们开始解决一个新问题：延迟。 来自亚洲的集群的延迟太高，无法获得令人满意的性能。 我们决定首先通过在 AWS 中部署计算机来测试市场。 我们不愿意做出选择，因为即使使用 AWS 提供的最佳 CPU（当时的 E5-2680），搜索查询的性能也比 E5-2687W CPU 低 15％！ 我们这样做是为了减少启动实验的时间，但要确保不引入对 AWS 的任何依赖关系。 如果测试成功，这使我们可以轻松地迁移到其他提供商。 在纸上，一切看起来都不错。 当我们发现他们的虚拟化不支持 AVX 指令时，我们遇到了一个问题，这对我们来说是重要的功能。 我们必须生成没有 AVX 指令集的二进制文件（这再次降低了搜索查询的性能）。 +* 每 5 分钟（如果有更改）从 Jenkins 的回购中提取所有代码（无论使用哪种语言），并使用几种 QA 工具自动进行测试和验证。 +* 每个项目都以 RPM 的形式构建和打包，然后移至 dev 软件包仓库。 +* 多个环境（开发，集成，QA，分段，生产）或不同的策略和测试级别。 +* Chef 自动执行部署和管理配置。 -在享受我们最近在新加坡推出的服务时，我们开始收到一些来自欧洲客户的投诉，他们抱怨他们的搜索查询延迟时间增加。 我们很快发现它与大量的索引操作相关联，这很奇怪，因为我们确信索引和搜索 CPU 使用率之间的体系结构划分正常工作。 经过调查，我们发现用于处理写操作的整个集群的分布式一致性的共识算法存在潜在的瓶颈。 当出现瓶颈时，它将阻塞 HTTP 服务器线程。 然后，这将导致搜索查询需要等待线程。 我们是无意中设计造成的！ +### 监控方式 -我们通过在达成共识之前实施队列来解决此问题。 它使我们能够收到大量的写操作，进行批处理，然后将其发送给共识。 共识不再存在于 HTTP 服务器的序列中，因此写操作无法再冻结 HTTP 服务器线程。 在正常操作期间，除了将作业传递给共识以外，队列什么都不做。 在出现峰值的情况下，它允许我们在达成共识之前进行缓冲和批量处理。 进行此更改后，我们没有冻结任何群集。 +* 所有服务都会发出 StatsD 事件，这些事件与其他系统级检查结合在一起，添加到 Zenoss 中并与 Graphite 一起显示。 -## 步骤 6：2014 年 4 月 +## 图片中的建筑 -### 一个数据中心几乎无法实现网络高可用性 +DataSift 为其整体架构创建了一张很棒的图片。 这是一个小版本，要查看完整版本，请在处转到[。](http://farm8.staticflickr.com/7159/6408735793_0fa14eedf6_o.png) -从 2014 年 4 月开始，我们开始收到使用在加拿大/东部使用集群的美国东部客户的投诉。 我们在美国西部的用户没有受到影响。 我们立即怀疑加拿大和美国东部之间存在网络问题，并发现我们的提供商正在报告同一问题。 一场车祸使蒙特利尔和纽约之间的一根含 120 根纤维的管道破裂。 所有的交通都在经过芝加哥的不同路径上进行。 不幸的是，带宽不足以防止数据包丢失。 中断不仅影响了我们的提供商，而且影响了加拿大和美国东部之间的所有流量。 这类事故可能会破坏我们经常忘记的互联网，但仍然可能发生。 那天我们除了帮助每个客户并通知他们当前的情况外，无能为力。 +![](img/aca6888e6964bb61c0b4df68f993db88.png) -就在这一天，我们开始了一场大型基础设施讨论。 我们需要依靠更多的提供商，数据中心和网络提供商来提高高可用性。 更重要的是，我们需要在美国拥有基础设施。 通过从加拿大为美国服务，我们可以削减成本，但高可用性受到了影响。 我们需要真正分布我们的基础架构。 我们不能再在一个提供商上拥有多个可用区！ +* 该图分为两半：左边的所有内容都是数据处理，右边的所有内容都是数据传递。 系统中运行 40 多种服务，其中包括：许可证服务，监视服务，限制服务等。 +* 整个系统有许多不同的扩展挑战，必须几乎同时解决：处理 firehose，低延迟的自然语言处理和推文上的实体提取，低延迟的推文内联增强，低延迟处理非常大的单个过滤器 ，对来自大量客户的大量复杂过滤器进行低延迟评估，链接解析和缓存，并通过保留每天发送的 1TB 数据来保留防火墙的历史记录，从而可以根据 firehose，实时计费，实时身份验证和授权，可让客户了解其流状态的仪表板，将过滤器结果流式传输到数千个客户端，监视每个机器，每个过滤器和每个子系统，负载和性能测试， 网络流量和服务之间的消息传递以低延迟的容错方式。 +* 我们不会涵盖它们所做的每一行或每一行，但我们将重点介绍。 -## 步骤 7：2014 年 7 月 +## 基本思路 -### 首次在两个数据中心中部署 +* **全部的要点**： + * **数据访问**的民主化。 消费者可以自己进行数据处理和分析。 如果他们愿意，一个人应该能够确定哪种早餐谷物得到的推文最多，处理数据，制作图表并将其出售给品牌。 有了一个可能的平台，而如果您必须建立自己的 tweet 处理基础架构，那几乎是不可能的。 + * **作为数据**服务的软件。 将信用卡放入一个小时或几个月的数据中。 Amazon EC2 模型。 收取使用费用。 没有巨大的注册期或费用。 可以是小型或大型播放器。 + * **您确实不需要大数据，需要洞察力**。 现在我们如何处理数据？ 自己创建见解的工具。 数据毫无价值。 数据必须在上下文中使用。 + * 这个想法是**创建一个全新的应用程序**，这是 Twitter API 所无法提供的。 +* [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) （提取，转换，加载）。 可以将 DataSift 视为一种 [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) 样式的系统，将实时数据流作为输入，将应用程序作为输出。 +* **提取** + * 数据是从多个来源读取的，但是目前主要吸引 Twitter 的 firehose 许可访问。 Twitter 是 Twitter 的所有公开推文。 您还可以访问 Digg 和 MySpace 数据。 + * 身份不是在不同的数据源之间建立的，但是它们会规范化所有数据，因此您可以知道用户名的位置，从而可以匹配身份。 +* **转换** + * 数据从防火墙中提取出来并进行标准化。 Twitter 数据具有高度维度，具有 [30 个属性和](http://www.readwriteweb.com/archives/this_is_what_a_tweet_looks_like.php)属性，您可以访问所有这些属性。 这些属性包括地理位置，名称，配置文件数据，推文本身，时间戳，关注者数量，转发数，已验证的用户状态，客户端类型等。 + * 实体提取和自然语言处理应用于推文。 例如，确定语言，并在元数据中提供该结果。 + * 当一条 tweet 进入时，他们必须查询 5 种不同的服务才能用更多数据扩展 tweet。 包括情绪分析，性别检测和 Klout 得分。 + * 解析每个链接并提取内容，以便可以将过滤器应用于内容和链接本身。 + * 他们计划随着时间的流逝增加更多的服务。 + * 在过滤过程发生之前，数据已被详细阐述。 +* **过滤** + * 您无法支付全部费用，因此使用了一种相对简单的声明性语言，称为 [CSDL](http://dev.datasift.com/csdl) ，以过滤掉不需要的 Tweets 并保留您想要的 Tweets。 + * 过滤器如下所示： *interact.content 包含“ apple”，而 interaction.content 包含“ orange”* + * 与过滤器匹配的所有推文形成一个流。 每个流都分配有一个标识符，该标识符看起来像“ 4e8e6772337d0b993391ee6417171b79” + * 随处可见对话流。 流是应用于输入的 CSDL 过滤器的输出。 通过过滤器，您可以创建您感兴趣的事件流。 + * 流标识符包含在规则中，以进一步限定流中应包含哪些推文。 规则以过滤器和其他规则为基础：*规则“ 4e8e6772337d0b993391ee6417171b79”和 language.tag ==“ en”* + * 可扩展筛选是 DataSift 的主要创新。 他们使用编译器在整个集群中高效地调度过滤器。 他们花了 3 年时间开发了可伸缩的规则评估解决方案。 + * 规则由过滤器的[组合组成，可以包含 1000 千个潜在的数百万项。 可以在数百台计算机上计划一次评估数百万条规则。 规则可以重复使用并按层次排序。](http://blog.datasift.com/wp-content/DataSift-Introduction-Webinar-small.pdf) + * 过滤器包括正则表达式，例如，您可以基于配置文件中的文本过滤掉推文。 有许多不同的目标和运算符。 +* **加载** + * 外部应用程序可以通过 REST API，HTTP 流或 Websocket 访问与过滤器匹配的推文。 + * 客户端库适用于：PHP，Ruby，C＃，Java，Node.js。 自己保存编写 HTTP 请求。 + * 您收到的是 JSON 对象，其中包含所有数据的规范化，完全增强格式。 您会在信息流中获取性别，地理位置，兴趣点，国家/地区，作者，推文，关注者数量，Klout 得分等。 每个消息最多有 80 个字段。 +* **应用程序** + * 应用程序通过一种出口策略接收一个详细阐述的 JSON 对象。 DataSift 只是筛分，它不会烘烤。 因此，如果您希望使用默认转换之外的 tweet 来完成某些工作，则必须编写一个应用程序来完成。 + * 不能保证以任何顺序发送推文，也不能保证您看到有史以来发送的所有推文。 应用程序必须在聚合/采样的基础上工作。 +* **结算** + * 计费以称为 **DPU** s 的神奇单位表示-数据处理单位。 每个过滤器都分配有一个 DPU。 每 DPU 每小时收费 20 美分。 您可以运行的最便宜的是 1 个 DPU，一整个月运行一个流将花费 150 美元。 + * 这个想法是，您使用的资源越多，您应该支付的费用就越多。 +* **开发** + * 寄存器。 查看[示例流](http://datasift.com/solutions/prebuiltstreams/)。 + * 学习 [CSDL](http://dev.datasift.com/csdl) 。 写你的过滤器。 + * [在线预览](http://console.datasift.com/)过滤器，以查看获得的结果的质量。 他们不仅返回原始数据。 他们有一个流浏览器，它具有地图视图，词云视图以及显示情感和性别的图表等。 + * 微调。 获得所需的结果，并查看 DPU，看您是否负担得起。 + * 使用您选择的 API 收集数据并对其进行处理。 您如何处理数据取决于您自己。 您可以实时内联处理。 也许显示一些图形。 将其存储在您自己的数据库中以进行后期处理。 + +## 关键思想 + +### 用例 + +考虑到大多数推文在每个人看来都是多么愚蠢，几乎很难想象它们具有共同的价值，因此看看人们可能希望将这些系统用于什么的目的是很清醒的： + +* 广泛的趋势是将数据集合并在一起。 将筒仓数据集整合在一起，以获得更好的见解。 将社交媒体数据与客户数据进行大规模合并，您可以开始看到行为模式与两个数据集之间的见解之间的相关性。 +* 策展，监视，警报。 +* 跟踪：电视节目，政治，天气，感冒等 +* 金融。 查看人们对公司的反应。 +* 每个人买什么？ 在逐月范围内寻找广泛的趋势。 +* 使用 Google 搜索来自世界各地所有星巴克附近拥有 500 多个关注者的文字推文。 +* 减灾。 知道需求在哪里。 +* 将所有百思买的位置放到规则中，这样您就可以在百思买中查看推文，而不必知道使用井号来自百思买的推文。 适用于任何事件或位置。 +* 策划新闻。 查看具有一定数量转推的信息源。 看主题说是否技术。 全部实时，以毫秒为单位。 + +小牛肉通常的混合加上深奥的味道。 如何使用此电源取决于您。 + +### 实时只有远距离的后果 + +DataSift 作为实时过滤系统的性质具有深远的影响。 请记住，它没有内存。 它没有历史。 您没有看到可以在任何方向进行迭代的有序流。 您正在从防火墙上获取实时数据。 这些推文指向过滤器，通过过滤器，然后像夜晚一样消失了。 + +这是一个采样模型。 您无法认为您正在消耗整个流。 任何希望按顺序查看帐户中所有推文的应用程序都将无法正常工作。 面向的应用程序类型是可以准确采样高度针对性的数据的应用程序。 + +例如，如果您想使用 DataSift 将 Twitter 用作消息总线来构建实时控制系统，则它将无法正常工作。 您不能保证可以看到一个帐户中的每个命令，也不能保证这些命令的顺序正确。 -我们发现在单个数据中心中进行部署是不够的。 我们决定从最大的客户之一开始，在两个不同的数据中心（它们之间相距 100 公里以上）部署一台机器。 这两个数据中心使用的是同一提供程序（相同的自治系统），并且已经提供了高可用性级别，比云提供程序的多个可用性区域略高一点。 这是由于两个数据中心位置在网络链接和电源单元方面完全不同。 +您可以解决的问题类型是创建一个过滤器，该过滤器将在 10 秒内提及 100 次“地震”一词时触发。 然后，您可以使用地理位置信息来确定发生地震的位置。 不需要任何鸣叫顺序，也就可以看到每条鸣叫。 这是另一种心态。 -根据我们过去的经验，我们花了这段时间来设计具有下一代 CPU 和 SSD 的硬件的下一版本： +### 仅过滤器具有远距离后果 + +让我感到惊讶的是，DataSift 仅是一个实时过滤引擎（因此名称中带有“ sift”一词）。 合作伙伴应提供更高级别的服务。 -* Xeon E5-1650v2（6 核，12 线程，3.5Ghz-3.9Ghz） +我期望 DataSift 成为一个有状态的细分平台，使人们能够回答“居住在美国的 18-24 岁男性有多少？”之类的问题。 DataSift 不计数，因此它不能具有细分平台的滑动窗口计数功能。 -* 128G RAM +这是因为它是**无状态**的结果。 从技术上讲，DataSift 也无法识别年龄段，这主要是因为 Twitter 具有相当贫乏的个人资料功能。 DataSift 将 Firehose 存储在 HBase / Hadoop 中，以进行离线分析，但这不是实时的。 -* 英特尔 SSD S3500（2x480G）或 S3700（2x400G）。 我们将 intel S3700 用于每天写入量较高的计算机，因为它们更耐用 +因此，您必须将头围绕过滤器模型。 在 DataSifts 的平台上无法执行任何应用程序逻辑。 没有存储过程。 可以通过诸如情感分析之类的增值服务在线增加推文，但这是一个高度结构化和受限的过程，而不是您的应用程序。 而且，如果您期望使用某种管道模型，那么也可以。 流无法通过一系列换能器通过管道进行编织。 + +之所以说 DataSift 是有原因的。 DataSift 是高度复杂且可扩展的过滤器系统。 它过滤掉了 firehose 中的 tweet，以创建针对性强的 tweet 流，供您在单独的应用程序中进行处理。 他们的工作是使数据深入到执行分析所需的 tweet 的横截面。 数据进入并根据规则进行匹配，如果不匹配，则将其丢弃，如果匹配，则将其放入您的存储桶中。 过滤器就像一个手套，只有最值得的通过。 + +仅过滤器模型的驱动程序是： **firehose scale 和低延迟**。 消防水带以很高的速率产生事件。 您将如何构建一个互联网扩展平台，该平台可将应用程序逻辑折叠成潜在的数百万客户？ 您如何做到这一点，并建立一个可以保持低延迟保证的端到端系统？ 你不能 + +你能做什么？ 评估大型过滤器。 快速。 下一节将对此进行更多介绍。 + +### **过滤引擎** + +* **当人们想到过滤器时，他们可能会想到 SQL select 语句，这些语句出于性能原因不建议使用大的“ where”子句。 DataSift 采用相反的方法，它们假定了非常多的过滤条件集，并且使评估具有可扩展性和效率。 他们的目标示例包括监视世界上每个星巴克的所有推文，或将 Lady Gaga 的关注者列表加载到过滤器中。 过滤器中可能有数百万个术语，它们是实时评估的。** +* **如此规模的过滤需要使用其他方法。 他们** 从他们在 TweetMeme 所做的工作开始。 核心过滤器引擎使用 C ++，称为“ Pickle Matrix”。 +* 三年多来，他们已经开发了编译器和自己的虚拟机。 我们不知道他们的技术到底是什么，但可能类似于带有查询重写的[分布式复杂事件处理。](http://www.doc.ic.ac.uk/~migliava/papers/09-debs-next.pdf) +* 编译器采用过滤器并以 Manager 和 Node 服务器为目标群集。 经理的工作是确定规则是否在其他任何地方加载，以及是否可以放置在高度优化的地方，例如靠近运行类似流的其他人。 Node 的工作是在规则上发布推文，获取匹配项列表，然后将匹配项推入管道。 +* 他们具有巧妙的算法来消除工作负载的重复数据，因此可以尽可能多地共享规则。 每个过滤器都不是孤立运行的。 过滤器形成一个共享空间。 如果有一个仅针对 Lady Gaga 引用进行过滤的过滤器，则该过滤器将在每个推特上运行一次，并使用同一过滤器在所有规则之间共享结果。 要完成这项工作，需要非常聪明的编译器和调度算法。 回报是惊人的。 不再持续运行重复的过滤器，它们仅运行一次。 +* 规则可以是分层的，编译器很聪明地尝试将它们放在一起，以便它们共享规则评估。 如果节点已经有一个规则，那么它将吸引使用该规则的过滤器。 该规则仅对节点上的所有筛选器运行一次。 +* 这是一种虚拟化方式。 通过将多个客户的工作负载组合在一起，他们可以利用过滤器中的任何共性。 即使每个操作只运行一次，DataSift 也会为每个操作付费。 例如，如果共享一个正则表达式，则仅运行一次。 它无法始终以这种方式工作，也许节点已加载，因此无法使用其他客户端，因此它必须在另一台计算机上运行。 +* 整个配置在运行时可以动态更改。 他们的调度算法一直在关注监视数据。 如果等待时间超过阈值，则将重新配置系统。 +* 过滤器会立即在内存中处理。 例如，每台服务器可以运行 10,000 个流。 +* 节点具有规则缓存，因此可以共享它们。 +* 编译器支持短路以优化滤波器。 +* 例如，如果一个正则表达式大于整个机器，则它们将自动在节点之间进行负载平衡。 请记住，大型过滤器是预期的标准。 如果要对 Lady Gaga 的所有关注者进行过滤，则过滤器的可伸缩性必须是核心功能。 + * 筛选引擎已分片。 每个分片都接收完整的流水线，并且所有分片都将处理每个``交互''（即``tweet''或``FB status''或``blog post''），整理其结果后再发送到下游。 + * 单个分片中的 N 个节点中的每个节点（都是彼此的副本）以循环方式接收到 1 / N 的软管。 + * 因此，假设有 2 个分片，每个分片 3 个节点，则每个分片上将找到 50％的过滤器。 分片中的每个节点都将接受软管的 1/3（并且上面将有 50％的过滤器）。 它将是该碎片中其他节点的副本。 + * 因此，如果加载了非常重的过滤器，则可以通过将更多的节点添加到重规则加载到的分片中来平衡，从而减少单个节点必须处理的消防水带数量。 + * 到目前为止，还没有单个过滤器对于单个节点来说太沉重，但是他们正在考虑拆分过滤器处理，因此先对子谓词进行大规模处理，然后再对所得的过滤器进行单独处理。 他们已经针对嵌入式规则进行了此操作（例如，给定一个过滤器，例如“让我获取所有包含'apple'AND 匹配规则 XYZ 的推文”，过滤器 XYZ 会分别处理）。 +* 客户需要大力推动创建可重用的公共规则，以鼓励数据流的可重用性。 人们可以按照自己的规则使用任何公共流。 例如，某人可能制作了一个肮脏的单词过滤器来创建流。 您可以使用它来构建该流。 每个人都共享同一流，因此，如果有 1000 个用户使用脏字过滤器，则该过滤器不会得到 1000 次评估。 该过滤器将为每个人进行一次评估，非常高效。 + +### 每个推文的增强管道 + +推文增加了第三方数据集。 使这些扩充具有低延迟是一个主要的痛点。 + +* 当一条 tweet 进入时，他们必须查询 5 种不同的服务才能用更多数据扩展 tweet。 例如，Klout 有 1 亿个 Twitter 个人资料，因此它们在内部针对 Klout 数据库的本地副本执行数据库请求。 他们将数据集带入系统，而不是通过 Internet 进行 API 服务调用。 +* 为了将数据集引入他们的系统，他们需要建立紧密的伙伴关系。 他们的情绪分析引擎已获得许可，快速，可集群化，并且适合于每天处理 5 亿次点击，且延迟低。 +* 每个服务必须具有< 100 毫秒的响应时间。 500 毫秒后，它就会被丢弃。 +* 每 10 条推文中就有 1 条是链接。 这样他们就可以获取内容，并根据您的内容进行过滤。 因此，如果提及某个品牌，则可以根据实际内容进行解析，以找出所有含义。 + +### 没有云为他们 + +* AWS 曾用于生成测试流量，但对于分布式应用程序，他们认为 AWS 太有限了，尤其是在网络中。 当节点连接在一起并且需要彼此通信时，AWS 的表现不佳。 没有足够低的延迟网络。 他们的客户关心延迟。 +* 他们必须注意一些细节，例如如何设置交换机以及如何通过主负载均衡器路由它们。 +* 从 Twitter 了解有关使用自定义数据包大小的信息。 他们正在使用巨型帧。 +* 由于规模的原因，Twitter 可能会在未来细分市场。 +* 他们与 Twitter 的联系是通过 Internet 进行的，没有对等关系。 + +### 平台意味着开放 + +* 首先构建一个 API，然后在该 API 上构建网站。 您可以使用 GUI 制作自己的导入工具，这些工具很酷。 +* 目的是通过让开发人员将 DataSift 嵌入其应用程序来使其不可见。 这是一个平台，该平台的工作是消除处理海量数据的难题。 其他人可以在其他系统中建立桥梁。 DataSift 希望专注于过滤和数据处理。 让其他人提供 GUI 等。 -我们所做的更改主要围绕 CPU。 我们从未在 E5-2687W 上使用 100％的 CPU。 E5-1650v2 是下一代 CPU，并提供了更高的时钟速度。 结果是，与以前的 CPU 相比，我们的服务速度提高了近 15％。 毫秒很重要！ +### 开票 -## 步骤 8：2014 年 9 月 +* 负担得起的实时计费产品不存在，因此它们构建了自己的产品。 面临的挑战是使人们对实时计费解决方案感到满意。 +* 客户是实时计费的。 您可以查看您的仪表板，以了解正在花费什么。 亚马逊和 Google App Engine 的经验表明，这是系统中非常重要且非常棘手的部分。 钱就在这里。 +* 他们使用称为 DPU 的定义单位-数据处理单位进行收费。 您让他们使用的资源越多，过滤器的成本就越高。 +* 每个过滤器都分配有一个 DPU。 +* 每 DPU 每小时收费 20 美分。 10 DPU 过滤器的价格为 2 美元/小时。 +* 您可以运行的最便宜的是 1 个 DPU，一整个月运行一个流将花费 150 美元。 +* 在 1 万个地理位置上进行过滤将非常昂贵。 查找一个正则表达式会很便宜。 +* 正则表达式很便宜，但是时间越长，处理时间就越长，这意味着它们更昂贵。 地理多边形的处理相当复杂。 一长串关键字非常便宜，因为它们使用散列。 词组匹配和近词匹配稍微贵一些。 +* 这样做的想法是，与为不需要的数据支付许可费用相比，过滤尽可能小的数据集要便宜得多。 +* 如果您运行 10,000 个数据流，但最终只占到了 Firehose 的 50％，但是他们不只是出售了 50％的 Firehose，而没有数据处理，因为这与他们的平台无关。 +* 他们希望客户尽可能详细地描述他们想要从过滤器中获取的数据。 +* 由于 Twitter 上有 50 至 50 位男性和女性之间的对等关系，因此，所有男性都将占流水线的 50％或 1.25 亿条推文。 为男性制作的所有推文创建过滤器并不是一件容易的事。 这将是非常昂贵的。 您要做的就是查看用例。 您是银行吗？您是药店吗？要弄清楚您对什么感兴趣。 要尽可能具体。 一些公司每天只会发送一条推文。 每天 2.5 亿条推文中，问题是如何创建过滤器以获取所需的两个或三个。 +* 客户可以设置阈值，以便他们可以决定每天花费多少。 您不想运行会在几秒钟内耗尽预算的流。 +* 为了准确计费，系统具有广泛的监视功能。 仪表板显示整个平台的运行状况。 可以看到系统中任何点之间的流程，每个点之间的延迟。 所有服务器的运行状况，吞吐量，流量变化都可能突出问题。 -### 在美国的存在！ +### 输出侧 -在与数家提供商进行了数月的讨论之后，我们于 2014 年 9 月在美国东部（弗吉尼亚州）和美国西部（加利福尼亚州）与一家新提供商一起启动了该服务。 由于更好的延迟和带宽，第一步是改善我们在美国搜索体验的好方法。 高可用性方面的改进并不大，但是确实有助于我们更灵活地应对加拿大和美国东部之间过去的问题。 我们使用的方法与以前的位置相同：一家提供商内的可用区域不同（不同的网络设备和电源单元）。 +* 真正的痛点是输出端。 您如何将推文从中心位置传递到用户所连接的正确服务器上？ 最终使用 0mq。 使用发布和订阅可以大大减少内部网络流量，延迟和软件复杂性。 他们现在几乎在任何地方都使用它。 非常灵活 为了获得高可用性，它们广播给几个听众。 +* 尝试了几种技术来移动数据。 最初在所有地方都使用 HTTP，但这太慢了，并且具有很高的代码复杂性。 然后他们尝试使用 Redis 作为队列，虽然速度更快，但是无法处理规模。 他们每天通过 0mq 发送数十亿条消息。 +* Node.js 在其前端使用，用于 HTTP 流和 Web 套接字连接的端点。 Node.js 的强大功能令人惊讶，它可以进行网络数据传递。 该层很简单，它只是将数据直接传递，将套接字插入套接字。 他们为 Node 构建了自己的多线程模型。 +* 事件系统的问题是知道您为什么收到事件，以便可以将其分派到正确的处理逻辑。 例如，同一条 Tweet 可以匹配性别规则和脏话规则，并且每种情况下，Tweet 的处理方式必须不同。 DataSift 有几种方法可以使这项工作完成，但是它们具有非常智能的标记功能。 一旦子过滤器匹配，就可以对该事实进行标记并在元数据中传递。 该引擎允许您创建规则的任何层次结构，以便可以将规则结合在一起，然后使用标记来创建类别。 -## 步骤 9：2014 年 10 月 +### 测验 -### 通过厨师进行自动化 +* EC2 用于生成流量。 防火墙为 60 Mbps。 +* 为了测试他们的系统，他们一次要运行相当于 11 台消防车的系统。 1000 个流，每个消防站的 1％将其传送到 1000 个连接。 他们遇到的瓶颈是托管提供商的网络带宽，而不是平台。 -随着我们需要管理的计算机数量的大量增加，我们将管理迁移到了 Chef。 以前，我们使用 Shell 脚本管理计算机，但是与 Chef 进行自动化相比，修复 Heartbleed（OpenSSL 漏洞）等安全问题非常耗时。 +### 将溪流汇入湖中 -Chef 所提供的自动化功能在配置数百台机器时非常有用，但它也有缺点。 迁移到 Chef 几个月后，菜谱中的错字导致某些生产服务器崩溃。 幸运的是，我们能够尽早发现问题。 由于推出了厨师客户的 CRON 工作具有非侵略性，因此对生产没有太大影响。 我们有足够的时间来做出反应并解决问题。 +DataSift 还支持非实时处理。 HBase 中存储了两个主要的推文集合： -我们非常幸运遇到此问题，因为该错误可能会破坏生产。 为了避免再次发生此类问题，我们决定将生产手册分为两个版本： +* 过滤器可以具有侦听器，因此推文直接存储在 HBase 中，允许以后下载数据。 可以安排流的录制，然后稍后浏览/使用它。 +* 录制整个消防水带是一项巨大的技术挑战。 在两个月内，他们将使人们可以在存储在 HBase / Hadoop 中的持久性版本的 firehose 上运行其筛选器。 这个想法是能够对您感兴趣的任何方面进行分析。 扩充所有数据后，每天通过该平台的数据总计将增加 1 TB，因此要存储大量数据。 -* 第一个版本（稳定版）已部署到所有集群的第一台和第二台计算机上 +### 你如何赚钱？ -* 第二个版本（生产版本）已部署在所有集群的第 3 台计算机上 +作为开发人员，我一直对如何使用平台和服务为开发人员（不仅是创造者）赚钱感兴趣。 我的角度是，如果您在通过收取足够的钱来赚钱的服务之上构建服务，是否可以构建有利可图的服务，或者成本太高，或者您是否真的必须将高价值目标定为高 保证金产品证明成本合理？ 换句话说，例如，TweetMeme 可以基于 DataSift 获利吗？ 建立或购买问题始终是一个棘手的问题。 -对我们的菜谱进行任何修改时，我们首先将修改应用于生产版本。 经过几天的测试，我们将修改应用于稳定的食谱版本。 高可用性需要在所有级别上应用！ +* **内部使用**。 如果您是使用 DataSift 来了解自己的产品的企业，那么您所获得的任何价值都可以证明其成本是合理的。 这很简单。 +* **服务**。 DataSift 认为自己可以提供商品化的数据交付，并且其成本只是从 Twitter 获取数据和开发人员所需时间来处理这些数据所需的基础结构成本的一小部分。 据他们估计，要建立一个像 Radian6 这样的社交监控服务，需要在系统上花 3 个月的时间。 您只需要专注于界面。 数据收集和处理部分得到处理。 如果您能找到合适的市场，那将具有很大的价值。 +* [App Store](http://blog.datasift.com/2010/11/02/datasift-app-store/) 。 DataSift 计划为第三个部分开发人员提供一个应用程序商店。 +* **增强服务**。 DataSift 将支付服务费用以作为其扩充渠道的一部分。 该模型是收益分成。 如果有人使用像 Klout 这样的平台，他们将收益分享给他们。 问题是找到可以扩展到 Twitter 级别的合作伙伴。 -## 第 10 步：2014 年 11 月 +## 得到教训 -### DNS 是体系结构中的 SPoF +* **平台和生态系统的力量。** 如果平台策略执行得当，它将成为进入市场的巨大障碍。 它也是观察下一波趋势发展的最高观察站。 这是[创新/杠杆/商品化](http://www.youtube.com/watch?v=Y_F6nFIp_dA)模型。 DataSift 已经拥有 LinkSift 之类的域名，因此这是该大计划的一部分，该计划是使用他们的底层平台来提供更高价值的服务，以他们从平台市场中收集的情报为指导。 +* **按钮没有钱，数据没有钱。** 跟随钱**。** 您现在正在做的事情可能不在钱中，但是它可以指导您找到钱的地方。 +* **质量胜过废话。** 趋势是发布几乎不可行的软件，然后使用用户反馈迭代地对其进行改进。 DataSift 没有走这条路。 他们从一开始就发布了复杂的可扩展产品，其原因有两个：1）他们在 TweetMeme 的经验基础； 2）他们不觉得自己可以从小做起并立即重新构建。 +* **从结构上来说，无国籍状态是一个巨大的胜利。 DataSift 仅是实时的，因此不必在内存中保留很多状态，也不必担心按顺序传递事件而不会丢失甚至不会容忍任何错误。 计时是他们的痛点，可以降低端到端的延迟。 当然，这将状态负担推给了应用程序开发人员。** +* **从别人的错误中学习。** 当 Twitter 从 TweetMeme 许可了转发技术时，他们实际上并没有重用 TweetMeme 的代码。 Twitter 从该代码中学到了知识，并将 TweetMeme 用作咨询服务，这有助于 Twitter 在发布时立即进行转发。 相反，当 DataSift 学习如何处理防火墙时，DataSift 可以从 Twitter 犯下的所有早期错误中吸取教训，因此 DataSift 可以在发布时正确解决。 +* **服务**。 从一开始就很难使用服务进行设计。 他们从一开始就拥有一个体系结构，但是如何连接这些服务，如何使这些服务冗余，如何使这些服务响应故障以及如何在某件事失败的情况下使一切都不会失败-所有这些类型的问题都有 一直是痛点。 将组件划分为服务是解决这些分布式编程问题的关键。 服务还使每个组件都可以独立扩展。 +* **消息系统**。 以 0mq 为核心的消息传递系统将服务联系在一起并实现可靠性。 它的工作非常出色。 比使用 HTTP 好 1000 倍。 他们喜欢不同通信模式（发布-订阅，请求-响应等）的灵活性。 HTTP 在性能和使用它所需的代码量方面都有太多开销。 只需将消息传递到需要处理的代码即可。 它使接口保持异步，解耦和基于队列而不是阻塞。 +* **连接管理**。 实时流的最大瓶颈之一是如何处理连接和断开连接。 他们从 Twitter 中学到了很多东西。 建立连接时，它会触发大量下游活动来激活连接，例如身份验证，验证流请求，确定负载，计费服务，审计跟踪等。每秒能够运行数千个连接/断开连接是一个挑战。 从 PHP 重写为 C ++，并使其成为多线程。 +* **将常用案例折叠到平台**中。 在他们的人员期间，他们喜欢在列表中加载数百万的人员。 就像 Lady Gaga 的所有追随者一样。 指向列表并将其自动下载到规则中。 +* **指标比记录**更重要。 记录中总是会填满您不使用的内容。 能够为超出范围的指标创建警报更加有效。 当指标触发对问题的意识时，您可以查看日志。 +* **遵循 Salesforce 和 Amazon 模型**。 他们是一个按需云平台，它们将在开始的基础上构建层。 因此，DataSift 是引擎，他们将制造其他产品，如 UserSift 和 LinkSift。 +* **易货**。 不必花钱。 通过物物交换引导。 他们获得了赞助。 他们出售了旧域名，以资助购买新域名。 +* **将一种产品的经验转化为另一种**。 TweetMeme 使用基于 RSS 提要的 fav.or.it 基础结构。 这使 TweetMeme 得以快速开发。 同样，构建 TweetMeme 的经验使跳转到 DataSift 变得容易得多。 他们从 TweetMeme 学习了可伸缩性，并建立了一流的工程团队。 +* **一切都至关重要**。 例如，他们在整个网络设备中都遇到帧缓冲区大小的问题。 他们发现，开放 HTTP 流连接比简单的 REST 调用更难扩展，因为它带来了网络中的许多潜在问题。 当他们使用 REST API 时，他们没有看到这些问题。 -随着时间的流逝，我们开始收到越来越多的用户反馈，指出我们的服务间歇性地变慢，尤其是在亚洲。 经过调查，我们发现.io TLD 的使用是造成此问题的原因。 事实证明，.io TLD 的任意播网络的位置少于主要 TLD（.net，.com 和.org）的位置，并且 DNS 服务器超载。 用户有时在 DNS 解析期间会遇到超时。 +从我的采访，阅读和查看十几个其他采访中，我对 DataSift 的思维和努力质量印象深刻。 我不知道它是否当然会成功，或者是否会成功，但是如果我失败了，那是因为缺乏专业精神。 企业家转变为 VC 的 Mark Suster 解释说，他对 DataSift 的投资是[在 Twitter 生态系统](http://www.bothsidesofthetable.com/2011/07/10/why-im-doubling-down-on-the-twitter-ecosystem/)上的投入增加了一倍。 我认为这是错误的观察方式。 DataSift 可以快速轻松地与任何流一起使用。 也许更好的方法是将 DataSift 加倍。 -我们与 CDN 提供程序讨论了此问题，他们都告诉我们最佳实践是使用.net TLD。 我们需要从.io 迁移到.net！ 在准备发布分布式搜索网络时，我们决定迁移到另一个 DNS 提供商。 该新提供商提供了链接域功能，这意味着它们将处理 [algolia.io](http://algolia.io) 和 [algolia 之间的同步。 net](http://algolia.net) ，这样我们就可以轻松地保持向后兼容性。 +## 相关文章 -我们从不同的位置对该迁移进行了广泛的测试，并感到一切正常。 不幸的是，在完成迁移之后，我们发现了一些影响我们某些用户的问题。 您可以在 [此博客文章](https://blog.algolia.com/black-thursday-dns-issue/) 中阅读详细的报告。 DNS 比我们意识到的要复杂得多。 DNS 提供程序有许多不同的行为，我们的测试并未涵盖所有这些行为（例如，首先使用 IPv6 解析，在 TTL 上使用不同行为等） +* [这篇关于黑客新闻](http://news.ycombinator.com/item?id=3292604)的文章 +* [具有查询重写功能的分布式复杂事件处理](http://www.doc.ic.ac.uk/~migliava/papers/09-debs-next.pdf)，作者：Nicholas PoulSchultz-Møller，Matteo Migliavacca，Peter Pietzuch +* [推文可以告诉您什么](http://www.readwriteweb.com/archives/what_a_tweet_can_tell_you.php)，作者：Marshall Kirkpatrick +* [Gnip 和 DataSift 有什么区别？](http://www.quora.com/What-is-the-difference-between-Gnip-and-DataSift) +* [DataSift 链接分辨率]( http://www.youtube.com/watch?v=JAN47Hw6o8w) +* [可扩展性的艺术-管理增长](http://www.alberton.info/talks/show/id/3)，作者：Lorenzo Alberton +* [有关“类固醇轨道：” DataSift]( http://www.youtube.com/watch?v=X7aiKaCi8O8) 的更多详细信息-采访 Robert Scoble +* [DataSift 的定价是否会对初创企业起到威慑作用？](http://www.quora.com/Is-DataSifts-pricing-a-deterrent-for-startups) +* [在 Twitter 提要之上的应用程序的基础架构（带宽）有多昂贵？](http://www.quora.com/How-expensive-is-the-infrastructure-bandwidth-of-an-app-on-top-of-Twitter-feeds) +* [问&答：尼克·霍尔斯特德（Nick Halstead）使用 Datasift](http://www.wired.co.uk/news/archive/2011-10/12/nick-halstead-mining-twitter ) 挖掘 Twitter 的火喉。 +* 要点：[将 Paul S. Watson 的 DataSift Twitter 交互流记录到 Google Fusion Table](https://gist.github.com/1389349) 中 +* [新的 DataSift 首席执行官表示，Twitter 的未来在于数据，而非广告](http://www.themediabriefing.com/article/2011-11-17/the-future-of-twitter-is-in-data-not-advertising-says-new-datasift-ceo) +* [Twitter 是一个信息流，但它也是一个蓄水池](http://gigaom.com/2011/11/17/twitter-is-a-stream-but-its-also-a-reservoir-of-data)，作者：Mathew Ingram +* [DataSift API 演示](http://www.slideshare.net/nickhalstead/datasift-api) +* [Cassandra vs HBase](http://skillsmatter.com/podcast/home/cassandra-hbase) ，作者：尼克·特尔福德（Nick Telford）（DataSift 平台架构师） +* [Twitter 上的 DataSift 开发](https://twitter.com/#!/datasiftdev) +* [第四次 DataSift 网络研讨会视频，“目标”](http://blog.datasift.com/2011/07/28/fourth-datasift-webinar-video-%E2%80%9Ctargets%E2%80%9D/) +* [MediaSift / DataSift（Genesys Guru 的作者）](http://genesysguru.com/blog/blog/2011/05/27/mediasift-datasift/) +* [为什么我在 Twitter 生态系统上加倍关注](http://www.bothsidesofthetable.com/2011/07/10/why-im-doubling-down-on-the-twitter-ecosystem/)，作者：Mark Suster +* [在 Mozilla 音乐节](http://blog.pusher.com/2011/11/3/ways-to-use-pusher-at-the-mozilla-festival)上使用 Pusher 的方法，Phil Leggetter +* [10 个高流量流的 IPTraf 统计信息的视频](http://www.twitvid.com/QQK7M)-这是使用 10 个流进行的测试-一台服务器的吞吐量约为 3Mb / s。 -这个问题也改变了我们识别 SPoF 的想法。 只有一个 DNS 提供程序是 SPoF，由于没有回退，因此迁移非常关键。 我们开始制定一项计划，以删除架构中的任何 SPoF。 +感谢您发布此信息。 他们庞大的过滤框架听起来非常令人印象深刻。 -## 下一个 +谢谢，这是一篇有趣的文章。 我有一些关于数字的查询： -至此，我们已经涵盖了本系列 15 个步骤中的 10 个。 正如您所看到的，我们推出后的头 18 个月并非一帆风顺。 我们经历了几次故障，不得不重新考虑基础架构的几个部分。 这些改进的目的是始终确保我们的基础架构将来几乎不可能面临类似的问题。 +-您说他们每天处理 250+百万条推文，每秒不到 3k。 当有关碧昂斯的婴儿的消息传出时，Twitter 的峰值每秒不到 9000 条。 那么每秒 12 万条推文的峰值来自何处？ -本博客系列的下一部分和最后一部分将重点介绍 DSN（分布式搜索网络），它是我们最引以为傲的功能，并提高了我们的高可用性。 两者都有一个目标：在可靠性和性能方面满足大型上市公司的期望。 +-每 1000 条推文 10c 似乎太糟糕了，这笔费用还包括结果权吗？ 如果是这样，您对完全访问没有转售权的费用有任何想法。 -*以下是该系列的所有三个部分：[第 1 部分](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html)，[第 2 部分](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html)，[第 3 部分](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html)* \ No newline at end of file +谢谢！ + +感谢您使用 0mq 并作出贡献。 有了这些类型的数据流和量度指标，它肯定会得到“真正的”锻炼！ 我想这种压力也会很快消除错误！ + +非常好写托德。 我一直在与 DataSift 一起工作，因为他们在 Alpha 阶段完成了一个我正在为客户准备的项目，该项目很快就要出炉了（几周）。 他们做得很好，这是一个令人印象深刻的平台，可以肯定它具有巨大的潜力。 有一些优点和缺点，但您要指出其中的一些优点（有些却不知道），但总体而言，我很喜欢使用该服务，并且愿意承担这种情况下的早期采用者的风险。 + +干杯， + +肯特郡 + +Thanks it is an interesting article. I have a couple of queries about numbers though: + +- You said that they process 250+ million tweets per day, which works out to be just under 3k per second. Twitter had a peak of just under 9k tweets per second when the news about Beyonce's baby broke. So where does the peak of 120k tweets per second come from? + +- 10c per 1000 tweets seems like an awful lot, does this fee include result rights as well though? If so do you have any ideas about the fees for full access without resale rights. + +Thanks! + +非常感谢您发表这篇深入的文章，非常感谢您描述整个公司的方式，从技术细节到业务建议。 +您是否想在 4 年后写一份跟进报告？ 考虑到他们所面临的所有挑战，看看他们如何扩展其体系结构和/或流目录非常有趣。 + ++ \ No newline at end of file diff --git a/docs/8.md b/docs/8.md index 85f5a31..aa6f683 100644 --- a/docs/8.md +++ b/docs/8.md @@ -1,92 +1,46 @@ -# ButterCMS 体系结构：关键任务 API 每月可处理数百万个请求 +# TypePad 建筑 -> 原文： [http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html](http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html) +> 原文： [http://highscalability.com/blog/2007/8/20/typepad-architecture.html](http://highscalability.com/blog/2007/8/20/typepad-architecture.html) -![](img/73b3493317ddb8421dbc8da23b060ef8.png) +TypePad 被认为是世界上最大的付费博客服务。 在经历了因其快速增长而引起的问题之后，他们最终过渡到了以其姊妹公司 LiveJournal 为模式的架构。 -*这是 [Jake Lumetta](https://twitter.com/jakelumetta) 的来宾帖子， [ButterCMS [](https://buttercms.com/) 。* +网站：http：//www.typepad.com/ -[ButterCMS](https://buttercms.com/) 使开发人员可以在几分钟内将内容管理系统添加到任何网站。 我们的业务要求我们为 API 提供近 100％的正常运行时间，但是在多次中断几乎使我们的业务瘫痪之后，我们开始着迷于消除单点故障。 在这篇文章中，我将讨论如何快速使用 [](https://www.fastly.com/)的边缘云平台和其他策略，以确保我们保持客户网站的正常运行 。 +## 该平台 -ButterCMS 的核心功能是： +* 的 MySQL* 记忆快取* 佩尔* MogileFS* 阿帕奇* Linux -* 内容编辑器的仪表板 + ## 统计资料 -* 一个 [JSON API](https://buttercms.com/docs/api/) ，用于获取内容 + * 从 2005 年开始，TypePad 使用多个网络管道发送 250mbps 的流量，每天的流量为 3TB。 他们每月增长 10-20％。 我找不到更多最新统计数据。 -* [SDK，用于将 ButterCMS](https://github.com/buttercms) 集成到本机代码中 + ## 架构 -## ButterCMS 技术堆栈 + * 原始体系结构： + -运行 Linux，Apache，Postgres，Perl，mod_perl 的单个服务器 + -存储为文件服务器上的 NFS。* 毁灭性的崩溃导致了新的发展方向 + -RAID 控制器发生故障，并在所有 RAID 磁盘上喷射了数据。 + -数据库已损坏，备份也已损坏。 + -他们多余的锉刀患有“裂脑”综合征。* 他们转移到 [LiveJournal Architecture](http://highscalability.com/livejournal-architecture) 类型的体系结构，这并不奇怪，因为 TypePad 和 LiveJounral 都由 Six Apart 拥有。 + -按 ID 分区的复制 MySQL 群集。 + -全局数据库生成全局唯一序列号并将用户映射到分区。 + -其他数据是按角色映射的。* 高度可用的数据库配置： + -使用主-主 MySQL 复制模型。 + -使用[虚拟 IP 地址](http://www.linuxvirtualserver.org/HighAvailability.html)使用 Linux 群集心跳进行故障转移。* MogileFS 用于提供图像。* Perlbal 用作反向代理并负载均衡请求。* 一个称为 TheSchwartz 的可靠的异步作业分配系统用于支持博客，添加注释，将来的发布，缓存失效和发布。* Memcached 用于存储计数，集合，统计信息和重量级数据。* 从旧体系结构到新体系结构的迁移非常棘手： + -所有用户都被迁移而不会中断服务。 + -Postgres 已删除。 + -在迁移期间，从 NFS 和 MogileFS 提供了映像。* 他们的新架构的优点： + -可以轻松添加新机器并调整工作量。 + -更高可用且价格便宜的可伸缩 -ButterCMS 是一个单一的 Django 应用程序，负责营销网站，编辑工具，API 和后台工具，以提供客户支持。 Django 应用程序与 Postgres 数据库一起在 Heroku 上运行。 + ## 得到教训 -我们还利用以下第三方服务： + * 小细节很重要。* 每个错误都是学习经验。* Success requires coordination and cooperation. -* [文件堆栈](https://www.filestack.com/) 用于为其客户提供图像编辑功能 + ## 相关文章 -* [快速](https://www.fastly.com/) 用于外部 API 缓存和交付 + * [LiveJournal 体系结构](http://highscalability.com/livejournal-architecture)。* [Linux 高可用性](http://www.linuxvirtualserver.org/HighAvailability.html)。 -* [Cloudfront](https://aws.amazon.com/cloudfront/) 作为客户资产的 CDN +“ Memcached 用于存储计数，集合，统计信息和重量级数据。” -* 用于 DNS 的 [EasyDNS](https://www.easydns.com/) - -## 停机时间是致命的 - -我们的客户通常会建立在请求/响应生命周期内向 ButterCMS 发出 API 请求以获取页面内容的网站。 这意味着，如果他们对 ButterCMS 的 API 请求失败，则他们的页面可能无法呈现。 如果我们的 API 出现故障，那么客户的网站也会与我们发生故障。 - -这是我们在早期学习的艰辛课程。 不可靠的服务器托管导致频繁的间歇性停机和性能下降，使客户感到沮丧。 糟糕的 DNS 迁移导致 API 停机数小时，从而使数十个客户的网站瘫痪了近半天，并使大量客户质疑他们是否可以继续依赖我们（其中有少数人离开了我们）。 - -在此事件之后，我们意识到确保接近 100％的正常运行时间是一个存在的问题。 未来发生的重大故障可能导致我们失去来之不易的客户，并使我们的业务陷入危机。 - -## 提供全局，快速，弹性的 API - -无法完全避免失败-您只能尽力减少机会。 - -例如，通过运行自己的物理服务器来“控制自己的命运”可以保护您的主机提供商免受崩溃的困扰，但是却使您处于必须处理安全性和可伸缩性的位置，这两者都可以轻松使您崩溃并 很难恢复。 - -对于我们的团队而言，始终保持 API 的正常运行并确保其在全球范围内提供高性能至关重要。 但是作为一家较小的公司，我们知道我们没有足够的资源来提供具有近 100％正常运行时间的全球性，高度可扩展的性能。 因此，我们转向了这样做的人： [快速](https://www.fastly.com/) 。 - -迅速将自己描述为“为全球最受欢迎的企业提供快速，安全和可扩展的数字体验的边缘云平台”。 他们与包括《纽约时报》，BuzzFeed，Pinterest 和 New Relic 等大型客户合作。 我们将 Fast 放在我们的 API 前面作为缓存层，以便所有 API 请求都通过其 CDN 进行处理。 ![](img/23f51f8296408b47a4f28e71b6ffafb1.png) - -当我们的一位客户在 ButterCMS 中更新其网站内容时，我们将使已编辑内容的特定位的 API 密钥无效。 非缓存的请求命中了我们的服务器，但命中率达到了 94％，因为客户网站上的内容相对于获得的访问者数量很少变化。 这意味着，即使我们的数据库或服务器遇到间歇性的中断，我们的 API 仍然可以运行。 我们不希望这样，但是从理论上讲，只要 Fastly 保持正常运行，服务器可能会完全瘫痪几个小时，而且客户的网站也会保持正常运行。 - -Fastly 的全球 CDN 为我们带来了另一个好处。 我们的许多客户都有静态 JavaScript 网站，这些 API 网站的访问者访问者是浏览器而不是服务器。 通过 Fastly 的 CDN 提供 API 响应，意味着我们的客户的网站访问者无论身在何处，都能获得快速的加载时间。 - -## 消除单点故障 - -在 ButterCMS 成立之初，我们处理了两次单独的 DNS 事件，这使我们感到恐惧。 在第一起事件中，我们的 DNS 提供商当时不小心从其系统中“取消”了我们的帐户，导致断电花费了将近 6 个小时才能使我们完全恢复。 我们的第二次事件发生在常规 DNS 编辑导致我们的[不同的] DNS 提供程序发生故障时，并且花费了将近半天的时间来解决。 DNS 事件尤其具有破坏性，因为即使在确定并解决问题后，您也必须等待各种 DNS 服务器和 ISP 清除缓存，然后客户才能看到解决方案（DNS 服务器也倾向于忽略您的 TTL 设置并强加 他们自己的政策）。 - -我们的经验使我们非常专注于消除整个体系结构中的任何单点故障。 - -对于 DNS，我们切换为使用来自不同 DNS 提供商的多个名称服务器。 DNS 提供程序通常允许并鼓励您使用 4-6 个冗余名称服务器（例如 ns1.example.com，ns2.example.com）。 很好：如果一个请求失败，其他请求仍然可以解决。 但是，由于您所有的名称服务器都来自同一家公司，因此您非常相信他们将拥有 100％的正常运行时间。 - -对于我们的应用服务器，我们使用 Heroku 的监控和 [自动缩放](https://blog.heroku.com/heroku-autoscaling) 工具，以确保我们的性能不会因流量高峰（或 如果快速崩溃，我们突然需要将所有请求直接路由到我们的服务器）。 除了使用 Fastly 缓存 API 外，我们还使用 Memcached 在应用程序级别缓存 API。 这为间歇性数据库或服务器故障提供了额外的缓冲层。 - -为防止在 Heroku 或 AWS（Heroku 运行于其上）之间发生极少数情况下的总停机，我们在 Google Cloud 上维护了单独的服务器和数据库实例，可以将其快速故障转移。 - -## 不可避免的是失败 - -不管我们的 API 有多可靠，我们都必须接受 [不可靠的网络](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) ，并且网络肯定会发生故障。 我们所有人在连接 Wi-Fi 时都遇到了麻烦，或者突然打了个电话。 从统计上讲，中断，路由问题和其他间歇性故障在总体上可能是异常的，但始终会始终以某个环境本底速率发生。 - -为克服这种本质上不可靠的环境，我们帮助客户构建在出现故障时将变得可靠的应用程序。 我们的 SDK 提供的功能，例如 [在 API 请求失败时自动重试](https://github.com/ButterCMS/buttercms-csharp/pull/2) 或 [支持，可轻松使用故障转移缓存](https://github.com/ButterCMS/buttercms-ruby#fallback-data-store) ，例如客户端上的 Redis。 - -## 结论 - -没有意识到这一点，我们中的许多人正在将单点故障构建到我们的堆栈中。 在 ButterCMS，我们的成功取决于确保客户的应用程序不会因为我们而出现故障。 为此，我们从后端基础架构中消除了尽可能多的单点故障，并提供了 SDK，可让我们的客户轻松实现其应用程序中的弹性和容错能力。 - -### 关于 ButterCMS - -当您听到“ CMS”或“博客”消息时，您可能会想到 WordPress。 ButterCMS 是一种较新的替代方法，它允许开发团队使用 ButterCMS API 将 CMS 和博客功能添加到他们自己的本机代码库中。 - -ButterCMS 由 [Jake Lumetta](https://twitter.com/jakelumetta) 和 [Abi Noda](https://twitter.com/abi) 发起，因为他们俩都遇到了寻找功能齐全，灵活且未将您绑定到特定 WordPress 的替代品的挑战 像 PHP 这样的编程语言.. - -如今，ButterCMS 为全球数百个网站提供支持，每月帮助处理数百万个请求。 - -你好杰克， - -在本文中，我看到两个语句。 -->快速用于外部 API 缓存和交付 - --> Cloudfront 作为客户资产的 CDN - -是否有特定原因将 Cloud Front 用作客户资产？ 为什么我们不能快速使用 CDN？ \ No newline at end of file +我们在 soulcast.com 上做了类似的事情，我很好奇它们如何将计数推到磁盘/数据库上，以及它们执行的频率。 另外，有人知道“集”是什么意思吗？ \ No newline at end of file diff --git a/docs/80.md b/docs/80.md index 1cbf657..c036483 100644 --- a/docs/80.md +++ b/docs/80.md @@ -1,123 +1,83 @@ -# 阿尔及利亚通往全球 API 的愤怒之路 +# Instagram 架构：1400 万用户，1 TB 的照片，数百个实例，数十种技术 + +> 原文： [http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html) + +![](img/e7b70a6c02b1e7425849dd6d1af801f2.png) + +[Instagram](http://instagr.am/) 是为您的 iPhone 提供的免费照片共享和社交网络服务，已获得[即时成功](http://techcrunch.com/2011/08/03/instagram-150-million/)。 在短短一年内增长到 [1400 万用户](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of)的情况下，他们在 8 月达到了 1.5 亿张照片，同时积累了数 TB 的照片，而他们仅用了 3 个 Instaneers 做到了，所有这些都存储在 Amazon 堆栈中。 + +Instagram 团队已经撰写了可以被视为该时代早期创业公司的典型描述：[推动 Instagram 运转的因素：数百个实例，数十种技术](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of)。 + +Instagram 使用不同技术和策略的模仿。 团队虽小，但经历了快速的增长，摆脱了不断上升的社交和移动浪潮的影响，它使用 SQL 和 NoSQL 的混合体，使用了大量的开源项目，他们选择了基于云的云服务，亚马逊的服务得到了充分利用 可靠性不是通过构建它们自己的，而是通过可用性区域，异步工作计划将组件链接在一起，系统由尽可能多的服务公开，这些服务公开了不需要构建的 API 和外部服务，数据存储在内存中， 在云中，大多数代码都是动态语言，对自定义位进行了编码以将所有内容链接在一起，并且它们运行得很快并且体积很小。 非常现代的建筑。 + +我们只是在这里博士文章，它写得很好并且很切题。 绝对值得一读。 这里是要领： + +* 获得的经验教训：1）保持简单 2）不要重新发明轮子 3）尽可能使用成熟可靠的技术。 +* 3 名工程师。 +* 亚马逊商店。 他们使用许多亚马逊的服务。 仅有 3 位工程师，因此没有时间研究自我托管。 +* 出于各种目的，总共有 100 多个 EC2 实例。 +* Ubuntu Linux 11.04（“ Natty Narwhal”）。 稳定，其他 Ubuntu 版本冻结了。 +* 亚马逊的 Elastic Load Balancer 路由请求，并且 3 个 nginx 实例位于 ELB 的后面。 +* SSL 在 ELB 处终止，这减轻了 nginx 上的 CPU 负载。 +* 亚马逊的 DNS 的 Route53。 +* 高 CPU 超大型计算机上的 25 多个 Django 应用程序服务器。 +* 流量是受 CPU 限制的，而不是受内存限制的，因此，高 CPU 超大型计算机是内存和 CPU 的良好平衡。 +* [Gunicorn](http://gunicorn.org/) 作为其 WSGI 服务器。 Apache 较难配置且占用更多 CPU。 +* [结构](http://fabric.readthedocs.org/en/1.3.3/index.html)用于在所有计算机上并行执行命令。 部署仅需几秒钟。 +* PostgreSQL（用户，照片元数据，标签等）在 12 个四倍超大内存实例上运行。 +* 十二个 PostgreSQL 副本在不同的可用性区域中运行。 +* PostgreSQL 实例使用[流复制](https://github.com/greg2ndQuadrant/repmgr)在主副本设置中运行。 EBS 用于快照，以进行频繁备份。 +* EBS 部署在软件 RAID 配置中。 使用 [mdadm](http://en.wikipedia.org/wiki/Mdadm) 获得不错的 IO。 +* 它们的所有工作集都存储在内存中。 EBS 不支持每秒足够的磁盘搜寻。 +* [Vmtouch](http://hoytech.com/vmtouch/vmtouch.c) （便携式文件系统缓存诊断）用于管理内存中的数据，尤其是当[将](https://gist.github.com/1424540)从一台机器故障转移到另一台机器时，尚无活动内存配置文件。 +* XFS 作为文件系统。 用于在快照时通过冻结和解冻 RAID 阵列来获取一致的快照。 +* [Pgbouncer](http://pgfoundry.org/projects/pgbouncer/) 用于[池连接](http://thebuild.com/blog/)到 PostgreSQL。 +* 几 TB 的照片存储在 Amazon S3 上。 +* 将 Amazon CloudFront 作为 CDN。 +* Redis 支持其主要供稿，活动供稿，会话系统以及[其他服务](http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value-pairs)。 +* Redis 在多个四倍超大内存实例上运行。 有时跨实例进行分片。 +* Redis 在主副本设置中运行。 副本不断地保存到磁盘。 EBS 快照备份数据库转储。 在主数据库上的 DB 上转储太费力了。 +* Apache [Solr]为[地理搜索 API](http://instagram.com/developer/endpoints/media/#get_media_search) 提供了支持。 就像简单的 JSON 接口一样。 +* 6 个用于缓存的 memcached 实例。 使用 pylibmc & libmemcached 连接。 Amazon Elastic Cache 服务再便宜不过了。 +* [Gearman](http://gearman.org/) 用于：将照片异步分享到 Twitter，Facebook 等； 通知实时订户新发布的照片​​； 送纸扇出。 +* 200 名 Python 工作者从 Gearman 任务队列中消耗任务。 +* [Pyapns](https://github.com/samuraisam/pyapns) （Apple 推送通知服务）处理超过十亿个推送通知。 坚如磐石。 +* [Munin](http://munin-monitoring.org/) 可以绘制整个系统的指标图并警告问题。 使用 [Python-Munin](http://samuelks.com/python-munin/) 编写许多自定义插件，以图形化显示，每分钟注册数，每秒发布的照片​​等。 +* [Pingdom](http://pingdom.com/) 用于服务的外部监视。 +* [PagerDuty](http://pagerduty.com/) 用于处理通知和事件。 +* [Sentry](http://pypi.python.org/pypi/django-sentry) 用于 Python 错误报告。 -> 原文： [http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html) - -![](img/f1addf57e7f14a4a7ca0bc885af700ca.png) - -*由 [Algolia](https://www.linkedin.com/in/julienlemoine) 的联合创始人& CTO Julien Lemoine 做客，这是一个开发人员友好的搜索即服务 API。* - -我们为开发人员和开发人员回答的最常见问题是关于 [我们的架构](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 以及我们如何实现如此高的可用性。 他们中的一些人对裸机服务器的高可用性持怀疑态度，而另一些人则对我们如何在全球范围内分发数据持怀疑态度。 但是，我更喜欢的问题是“初创企业如何建立这样的基础架构”。 的确，对于一个年轻的公司，我们当前的架构令人印象深刻： - -* 我们的高端专用计算机在全球 13 个地区托管，拥有 25 个数据中心 - -* 我们的主从设置会在至少 3 台不同的计算机上复制我们的搜索引擎 - -* 我们每个月处理超过 60 亿个查询 - -* 我们每个月接收和处理超过 200 亿次写操作 - -就像罗马不是一天建成的，我们的基础架构也不是很好。 本系列文章将探讨我们在构建基础架构时采取的 15 个工具步骤。 我什至将讨论我们的中断和错误，以便您了解我们如何使用它们来改进我们的体系结构。 - -第一部分将重点介绍我们在 2013 年 3 月至 2013 年 8 月处于测试阶段时构建服务时所采取的前三个步骤。 - -# 云端与裸机之争 - -在深入探讨我们的架构之旅的细节之前，我想谈一谈对其他基础架构产生重大影响的选择。 我们需要决定是否应该使用基于云的基础架构或裸机。 在技​​术讨论中经常讨论的热门话题。 - -对于大多数用例，尤其是在早期阶段，云基础架构是一个很好的解决方案。 它们在提高许多服务的高可用性方面发挥了作用。 在多个可用区（AZ）上运行数据库或在不同 AZ 上运行多个实例的数据库同时将其所有状态存储在多个 AZ 数据库中的解决方案就是一个很好的例子。 这是许多工程师使用的标准设置，几分钟即可轻松部署。 - -裸机基础架构要求您了解并设计一些小细节，以便自己构建高可用性。 这是一种“自己动手”的方法，仅对一小部分用例有意义。 我们经常遇到在单个数据中心中使用裸机部署的情况。 这没有意义，因为它的容错性不如在云提供商上进行快速部署，数据中心是单点故障（SPoF）。 - -对于与硬件相关的企业，裸机硬件仍然是一个有趣的选择，这正是我们的情况。 通过选择裸机基础架构，我们可以购买比云提供商所提供的性能更高的硬件。 除了性能提升之外，成本也要便宜得多。 我们之所以选择此选项，是因为我们充分意识到我们将需要自己构建高可用性！ - -# 早期：2013 年 3 月至 8 月 - -## 步骤 1：2013 年 3 月 - -设计了高可用性，未实现！ - -目前，我们首次运行了搜索即服务 API 的私人 Beta 版。 在这个时候，我们只能衡量我们的表现。 我们尚未开发产品的高可用性部分。 我们对我们的市场遍及全球充满信心，因此我们在加拿大/东部和欧洲/西部两个不同的地方推出了单机，其规格如下： - -* 32G 内存 - -* Xeon E3-1245 v2（4 核，8 线程，3.4Ghz-3.8Ghz） - -* 2 个 Intel RAID 320 系列 120GB 的 Raid-0 - -每台计算机根据其位置托管不同的用户集。 在我们的私人测试版中，性能集中在 100％上，这就是时钟速度是我们做出决定的主要因素的原因（对于同一代 CPU，时钟速度与搜索引擎中搜索查询的速度直接相关）。 从一开始，我们就在一个单独的过程中完成了索引，其级别为 5。 所有搜索查询都是在 nginx 内部直接处理的，我们将其设置为零（进程的良好级别越低，它获得的 CPU 时间就越多）。 此设置使我们能够通过为搜索分配最高的分配 CPU 优先级来有效地处理流量高峰。 与其他引擎使用的方法相比，此方法效果很好。 - -我们感到非常惊讶的是，我们的第一批 Beta 测试人员之一在生产中将其替换为以前的解决方案，因为他们对性能和相关性感到非常满意。 如您所料，我们对此感到非常压力。 由于未实现高可用性，因此我们担心会影响它们的潜在停机时间，并解释说该产品尚未投入生产！ 客户告诉我们，风险与回报对他们来说是可以接受的，因为如果需要，他们可以回滚到以前的提供商。 附带说明，这个故事帮助我们在产品推出之前获得了第一轮资金。 最终成为我们对市场适应性的第一个证明。 更好的是，我们可以称其为“问题解决方案”！ 我们不能感激那个客户：) - -## 第 2 步：2013 年 6 月 - -在我们的体系结构中实现高可用性 - -经过三个月的开发和大量测试（猴子测试方法真的很有趣！），我们在 Beta 中引入了高可用性支持。 您可以在 [体系结构文章](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) 中阅读更多有关它的内容。 这个想法是由三台相同的机器组成的集群，而不是一台机器，其中每台机器都是所有数据的完美副本，并且能够充当主服务器。 这意味着每个人都可以接受来自 API 用户的写入操作。 每个写操作都会触发共识，以确保所有计算机都具有所有作业，并以相同顺序应用它们。 - -我们使用了第一个 Beta 的初步结果来设计新的硬件设置。 我们发现以下内容： - -* 32G 的内存不足，当从多个用户那里接收大索引作业时，索引最多使用 10G，这只能让 22G 缓存磁盘 IO - -* 磁盘空间不足，无法实现高可用性，因为计算机需要在磁盘上保留多个作业才能处理节点故障 - -* 拥有更多的内存，我们需要迁移到 Xeon E5 系列（E3 仅可寻址 32G 的内存）。 由于时钟速度很重要，我们决定选择 Xeon E5 1600 系列，该系列提供了非常好的时钟速度，并且能够比 Xeon E3 拥有更多的内存。 - -通过这些发现，我们的设备演变为三台具有以下规格的机器： - -* 64G 内存 - -* Xeon E5-1650（6 核，12 线程，3.2Ghz 至 3.8Ghz） - -* 2 个 Intel RAID 320 系列 300GB 的 Raid-0 - -至此，我们能够忍受硬件故障！ 但是，我们离提供多个可用区域的云提供商还差得远。 我们所有的机器都在同一个数据中心中，只有一个提供商，而对基础架构一无所知。 - -同时，我们研究了是否应使用硬件或软件来处理机器之间的负载平衡和检测失败。 我们测试了几种方法，发现所有硬件负载平衡器几乎都无法使用多个提供程序。 我们最终在 API 客户端中实施了基本的重试策略。 每个 API 客户端的开发都能够访问三台不同的计算机。 三个不同的 DNS 记录代表每个用户： [USERIDID-1.algolia.io](http://useridid-1.algolia.io) ， [USERID-2.algolia.io](http://userid-2.algolia.io) 和 [USERID-3.algolia.io](http://userid-3.algolia.io) 。 我们的第一个实现是随机选择其中一个记录，然后在失败的情况下重试另一个记录。 - -## 第 3 步：2013 年 8 月 - -正式启动服务 - -在夏季，我们将 API 客户端的数量增加到 10 个（JS，Ruby，Python，PHP，Objective-C，Java，C＃，Node.js ...）。 我们决定避免使用自动代码生成，而是手动开发 API 客户端。 尽管还有更多工作要做，但我们需要确保网络代码对于 HTTPS 保持活动状态，正确使用 TLS，以正确的超时正确实施重试策略等保持良好状态。 - -我们于 2013 年 8 月底在我们的两个位置（欧洲/西方和加拿大/东方）正式启动了该服务。 每个位置包含三个相同主机的群集，它们具有以下规格： - -* 128G RAM - -* E5-2687W（8 核，16 线程，从 3.1Ghz 到 3.8Ghz） - -* 2 个 Intel S3500 系列 300GB Raid-0 - -与以前的配置相比，我们所做的主要更改是增加内存大小并使用更好的 SSD。 基于观察到 SSD 是索引编制过程中的瓶颈，并且内存不足以将所有用户的数据缓存在内存中的发现，完成了这两项更改。 对于 CPU 升级，更大的问题是要确保我们拥有足够的资源。 - -在这一点上，我们要重点关注的下一个大项目是为我们的部署实施可用性区域。 我们需要在不同的网络设备和电源单元上运行三台机器。 希望我们的提供商对他们的基础架构以及机器的分配位置保持透明。 它不是完美的，但是我们能够实现与其他云提供商类似的解决方案。 我们怀疑云提供者所做的事情与我们实施的类似，但尚未找到有关此主题的任何详细文档！ +## 相关文章 -### 下一个 +* [在 Redis 中存储数亿个简单键值对](http://instagram-engineering.tumblr.com/post/12651721845/instagram-engineering-challenge-the-unshredder) +* [简化 EC2 SSH 连接](http://instagram-engineering.tumblr.com/post/11399488246/simplifying-ec2-ssh-connections) +* [在 Instagram 上拆分& ID](http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram) +* [EC2 或 Amazon ElastiCache 上的 Membase 群集？](http://nosql.mypopescu.com/post/13820225002/membase-cluster-on-ec2-or-amazon-elasticache) 来自 Alex Popescu -与大多数其他初创公司一样，我们从粗略的 MVP 开始测试市场。 我们最终不得不做一些认真的工作来开发更加成熟和强大的体系结构。 通过这些最初的几个步骤，我们从 MVP 过渡到可用于生产的 API。 +嘿托德， -到目前为止，我们已经介绍了该博客系列 15 个步骤中的 3 个。 在下一个博客中，您将了解生产的前 18 个月以及我们所面临的所有意外问题，包括首次停机！ +来自 Instagram 的 Mike。 感谢您的撰写。随着我们不断发展的基础架构，高可伸缩性一直是我们的绝佳资源，感谢您编译的所有出色信息！ -*以下是该系列的所有三个部分：[第 1 部分](http://highscalability.com/blog/2015/7/13/algolias-fury-road-to-a-worldwide-api.html)，[第 2 部分](http://highscalability.com/blog/2015/7/20/algolias-fury-road-to-a-worldwide-api-steps-part-2.html)，[第 3 部分](http://highscalability.com/blog/2015/7/27/algolias-fury-road-to-a-worldwide-api-part-3.html)* +迈克，我很高兴。 我真的很感谢你们的开放程度。 好东西。 谢谢。 -## 相关文章 +@Mike（instagram） +我读到您使用 solr 进行地理搜索。 您能解释一下您的解决方案吗？ 您将 solr 3.1 与 geofilt 一起使用还是开发了一些特殊的东西？ -* [关于 HackerNews](https://news.ycombinator.com/item?id=9899794) +这个多少钱？ 只是有一个想法。 -期待其他 12 个步骤：） +亲爱的迈克， -优秀的文章！ 感谢分享。 +您是否掌握有关 Instagram 服务器基本硬件数据的信息？ 我们必须在大学的“信息管理”讲座中找到 CPU，RAM，固定磁盘存储和处理器等数据。 -当您说“ ..所有搜索查询都直接在 Nginx 内部处理..”时，我无法理解。 你能更好地解释吗？ +如果您能帮助我们，我们将非常高兴。 -问候！ +非常感谢！ -@Mauro Herrera：当然，我们处理查询的代码是用 C ++开发的，并且直接作为模块嵌入在 nginx 中。 查询到达后，它会由 nginx 直接处理，而无需与任何其他进程进行通信（唯一的例外是我们的客户在自定义 API 密钥中自定义了速率限制，在这种情况下，我们与存储在 同一台机器）。 -您可以在[我们的体系结构帖子](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html)上获得更多详细信息，它们描述了我们所有的堆栈。 +J，J 和 L -“除了性能提高之外，成本也要便宜得多。” -在人们将大量精力转移到云计算以体现零 CAPEX 和低 OPEX 收益的时代，裸机基础设施如何降低成本？ 你能解释一下吗？ +CDN 需要内容可以公开阅读。 +然后，Instagram 如何处理仅应与少数人共享的图像 -阿尔戈利亚很棒。 在 Stamplay，我们将他们的搜索 API 集成到了开发平台中，因此我们的用户只需单击几下便可以将超快速搜索添加到他们的应用程序中，这比他们自己集成 API 的速度要快。 它对我们用户的应用程序的搜索性能产生了巨大的影响。 +您可以在 S3 上拥有一个私有存储桶项目，尽管直到在 S3 中生成签名密钥，该私有桶项目才可以通过 CDN 路由。 每个被授予权限的用户都可以收到一个签名的密钥。 我不知道这是否是他们具体的做法。 -如果有人想了解 Stamplay 的 Algolia API 集成的工作原理，我们实际上创建了一个非常有用的教程，以演示如何快速设置和运行它：https://blog.stamplay.com/how-to-create-a- 带有 AngularJS 条纹阿尔及利亚和 stamplay 教程的书俱乐部应用程序/ \ No newline at end of file +相关文章中“在 Redis 中存储数亿个简单键/值对”的链接不正确。 它重定向到其他一些中等职位。 实际链接是 https://instagram-engineering.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c \ No newline at end of file diff --git a/docs/81.md b/docs/81.md index 03af153..fb91bd6 100644 --- a/docs/81.md +++ b/docs/81.md @@ -1,147 +1,28 @@ -# Appknox 架构-从 AWS 切换到 Google Cloud +# PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片 -> 原文： [http://highscalability.com/blog/2015/5/25/appknox-architecture-making-the-switch-from-aws-to-the-googl.html](http://highscalability.com/blog/2015/5/25/appknox-architecture-making-the-switch-from-aws-to-the-googl.html) +> 原文： [http://highscalability.com/blog/2011/12/27/plentyoffish-update-6-billion-pageviews-and-32-billion-image.html](http://highscalability.com/blog/2011/12/27/plentyoffish-update-6-billion-pageviews-and-32-billion-image.html) -![](img/2ab3836af16dc4a8c0191aacd62b0e46.png) +![](img/683d302405d99b27394fdf717b1498a9.png) -*这是来自 Appknox 的全栈& DevOps 工程师 [dhilipsiva](http://dhilipsiva.com/) 的来宾帖子。* +Markus 在其 [PlentyOfFish 体系结构](http://highscalability.com/plentyoffish-architecture)上有一个简短的[更新](http://plentyoffish.wordpress.com/2011/12/27/32-billion-images-a-month/)。 令人印象深刻的 11 月统计数据： -[Appknox](https://www.appknox.com/) 帮助检测和修复移动应用程序中的安全漏洞。 保护您的应用程序就像提交商店链接一样简单。 我们上传您的应用程序，扫描安全漏洞，然后报告结果。 +* 提供 60 亿次网页浏览 +* 提供了 320 亿张图片 +* [n 天](http://plentyoffish.wordpress.com/2011/05/16/yay-finally-passed-6-million-loginsday/)中有 600 万次登录 +* IM 服务器可处理约 300 亿次浏览量 +* 11 个网络服务器（其中 5 个可以删除） +* 7 月雇用了第一位 [DBA](http://plentyoffish.wordpress.com/2011/07/30/hiring-my-first-dba/) 。 他们目前只有少数员工[。](http://news.ycombinator.com/item?id=3400649) +* 所有托管/ cdn 费用加起来每月都低于 7 万美元。 -What's notable about our stack: +**课程**：对于原始硬件而言，小型组织，简单架构，仍然是 PlentyOfFish 的丰厚利润。 -* **模块化设计**。 到目前为止，我们已经对模块进行了模块化，因此我们将前端与后端分离了。 这种架构具有许多优点，我们将在后面的文章中讨论。 -* **从 AWS 切换到 Google Cloud** 。 我们使代码在很大程度上与供应商无关，因此我们能够轻松地从 AWS 切换到 Google Cloud。 +## 相关文章 -## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#primary-languages)主要语言 +* [关于 HackerNews](http://news.ycombinator.com/item?id=3400450) +* [每月 Markus Frind 提供 320 亿张图像](http://plentyoffish.wordpress.com/2011/12/27/32-billion-images-a-month/)。 -1. 后端的 Python & Shell -2. 前端的 CoffeeScript 和 LESS +哇，您每个月能得到 7 万美元吗？ 某处有成本细分吗？ -## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#our-stack)我们的堆栈 +代理广告。 -1. Django 的 -2. Postgres（从 MySQL 迁移） -3. 兔子 MQ -4. 芹菜 -5. 雷迪斯 -6. 记忆快取 -7. 漆 -8. Nginx 的 -9. 人的 -10. Google 计算 -11. 谷歌云存储 - -## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#architecture)架构 - -[![Architecture at AppKnox](img/5df684f185c981a66de5905c90b17b2e.png)](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/sourimg/architecture-at-appknox.jpg) - -### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#how-it-works)它是如何工作的？ - -我们的后端架构由 3 个子系统组成：客户端，数据和工作程序。 - -### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#client-subsystem)客户端子系统 - -客户端子系统由两个不同的负载平衡，自动扩展的 App &套接字服务器组成。 这是所有用户交互的地方。 我们非常注意不要在此处进行任何阻塞调用，以确保将延迟降至最低。 - -**App Server** ：每个 App 服务器都是单个计算单元，装有 Nginx 和 Django-gunicorn 服务器，由超级用户管理。 用户请求在此提供。 当用户提交其应用程序的网址时，我们会将其提交给 RabbitMQ `download`队列，并立即让用户知道该网址已提交。 如果上载任何应用程序，将从服务器获取签名的 URL。 浏览器将使用此签名 URL 将数据直接上传到 S3，并在完成后通知应用服务器。 - -**套接字服务器**：每个套接字服务器都是一个装有 Nginx 和一个节点（socket-io）服务器的计算单元。 该服务器使用 Redis 作为其适配器。 是的，当然，这用于实时更新。 - -### 数据子系统 - -#### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#data-subsystem) - -该系统用于数据存储，排队和发布/订阅。 这也负责解耦架构。 - -**数据库群集**：我们使用 Postgres。 不言而喻，它由一个“重写入”母版和几个“重读取”副本组成。 - -**RabbitMQ** ：我们芹菜工人的经纪人。 对于不同的工人，我们有不同的队列。 主要是`download`，`validate`，`upload`，`analyse`，`report`，`mail`和`bot`。 Web 服务器将数据放入队列，芹菜工作者将其拾取并运行。 - -**Redis** ：这充当套接字 io 服务器的适配器。 每当我们想要通知用户任何工作人员的更新时，我们都会将其发布到 Redis，Redis 随后将通过 Socket.IO 通知所有用户。 - -### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#worker-subsystem)工作者子系统 - -这是所有繁重的起重工作完成的地方。 所有工作人员均通过 Redis 从 RabbitMQ 和已发布更新中获取任务给用户。 - -**静态扫描仪**：这是一个自动缩放的计算单元组。 每个单位由 4-5 名芹菜工人组成。 每个芹菜工人一次扫描一个应用程序。 - -**其他任务**：这是一个自动缩放的计算单元组。 每个单位由 4-5 名芹菜工作者组成，他们执行各种任务，例如从商店下载应用程序，生成报告 pdf，上传报告 pdf，发送电子邮件等。 - -**动态扫描**：这是特定于平台的。 每个 Android 动态扫描程序都是一个按需计算实例，该实例具有 android 模拟器（带有 SDK）和一个捕获数据的脚本。 该模拟器显示在浏览器的画布上，供用户进行交互。 每个 iOS 扫描仪都位于托管的 Mac-Mini 服务器场中，该服务器场具有支持 iOS 平台的脚本和模拟器。 - -## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#reasons-for-choosing-the-stack)选择堆栈的原因 - -我们选择 **Python** 是因为我们用于扫描应用程序的主要库位于 python 中。 而且，我们比已知的任何其他语言都更喜欢 python。 - -我们选择 **Django** 是因为它具有模块化功能。 - -**灰烬**-我们认为这是目前最强大的前端框架。 是的，学习曲线比其他任何曲线都陡峭，但是一旦您爬上那座陡峭的山峰，您将绝对喜欢余烬。 这是很自以为是的。 因此，只要您遵守它的约定，就可以减少编写工作。 - -**Postgres** -最初，我们选择 MySQL 是因为它是事实。 在甲骨文收购 Sun Microsystems（MySQL 的母公司）之后，MySQL 陷入停滞。 我想我们都期望如此。 因此，我们确实使用了社区维护的 MariaDB（MySQL 的一个分支）。 后来，我们需要持久键值存储，这是 Postgres 开箱即用的。 它在 Python 中发挥的非常好。 我们使用 UUID 作为主键，这是 Postgres 中的本机数据类型。 另外，`uuis-ossp`模块提供了在数据库级别生成和操作 UUID 的功能，而不是在应用程序级别创建它们的功能，这更加昂贵。 因此我们切换到 Postgres。 - -其余的都是事实。 **RabbitMQ** 用于任务队列。 **Celery** 用于任务管理。 **Redis** 用于发布/订阅。 **Memcached &清漆**用于缓存。 - -## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#things-that-didnt-go-as-expected)事情未按预期进行 - -未能按预期进行的事情之一是**缩放套接字**。 我们最初使用的是 Django-socket.io。 我们意识到这无法扩展到多个服务器。 因此，我们将其编写为单独的节点模块。 我们使用了支持 Redis-adapter 的节点的 socket-io 库。 客户端连接到节点的套接字服务器。 因此，我们现在从 python 代码发布到 Redis。 Node 只会将通知推送给客户端。 可以独立于充当客户端 JSON 端点的应用程序服务器进行扩展。 - -## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#notable-stuff-about-our-stack)关于堆栈的显著资料 - -我们喜欢**模块化设计**。 到目前为止，我们一直在对模块进行模块化，以至于我们将前端与后端分离。 是的，你没有看错。 所有 HTML，CoffeeScript 和 LESS 代码都是独立于后端开发的。 前端开发不需要服务器在运行。 在开发过程中，我们依靠前端设备来获取假数据。 - -我们的**后端命名为** **Sherlock** 。 我们检测移动应用程序中的安全漏洞。 所以这个名字似乎很贴切。 Sherlock 很聪明。 - -我们的**前端称为 Irene** 。 还记得艾琳·阿德勒（Irene Adler）吗？ 她美丽，多彩，并告诉我们用户出了什么问题。 - -我们的**管理员名为 Hudson** 。 还记得哈德森夫人吗？ 夏洛克的女房东？ 考虑到我们应该为可怜的沃森博士扮演什么角色。 也许我们会。 - -因此，Sherlock 不提供任何 HTML / CSS / JS 文件。 我再说一遍，它**不提供任何单个静态文件/ HTML 文件**。 夏洛克和艾琳都是独立开发的。 两者都有单独的部署过程。 两者都有自己的测试用例。 我们将 Sherlock 部署到**计算实例**，并将 Irene 部署到 **Google Cloud Storage** 。 - -这种架构的**优势在于：** - -1. 前端团队可以**独立于后端的**工作，而无需互相踩脚。 -2. 从服务器移除**等繁重的工作，例如在服务器上呈现页面。** -3. 我们可以**开放源代码的前端代码**。 轻松雇用前端人员。 只需要求他们修复存储库中的错误，便可以雇用他们。 毕竟，即使您不开源它，任何人都可以读取前端代码？ - -## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#our-deployment-process)我们的部署流程 - -该代码是从`master`分支自动部署的**。 我们遵循 [Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/) 的 Git 分支模型。 Jenkins build 提交到`develop`分支。 如果成功，我们将进行另一项手动测试，只是要确保将其与`master`分支合并并自动部署。** - -## 最初使用的 AWS。 我们决定使用 Google Cloud 的原因有 3 个。 - -1. 我们喜欢基于**基于项目的方法来管理不同应用程序的资源**。 它使访问基础架构更加实用。 由于我们的“动态扫描”功能的复杂性，它使识别实例更加容易。 -2. 当我们受到打击时，它具有**令人敬畏的文档**，并获得了 Google 工程师的私人 1：1 帮助。 -3. 我们收到了一些**重要的 Google 积分**，这有助于我们在早期阶段削减成本。 - -我始终远离 IaaS 提供商提供的特殊服务。 例如，我们没有使用 Amazon RDS 或 SQS。 配置了我们自己的数据库服务器，RabbitMQ 和 Redis 实例。 这样做的原因是-这些服务相对较慢（且成本较高），并且您的产品依赖于供应商。 我们将所有这些抽象为独立于供应商的。 我们忘了抽象的一件事就是存储。 - -我们直接消耗了 S3。 当我们尝试迁移到 Google Cloud 时，这只是一个小小的选择。 因此，当我们决定迁移到 Google Storage 时，我们对存储层进行了抽象，并遵循了 Google [Storage Migration docs](https://cloud.google.com/storage/docs/migrating) 的要求。 而且一切正常。 现在，无需更改代码即可将代码库托管在 Google Cloud 和 AWS 上。 当然，您将不得不更改配置。 但不是代码。 - -感谢您的来信。 因此，迁移到 Google 云的原因就在于此。 但是，需要对第 1 点进行说明。 - -你说什么意思 - -“我们喜欢基于“项目”的方法来管理不同应用程序的资源。它使访问基础架构更加务实。由于“动态扫描”功能的复杂性，它使识别实例更加容易。” - -谢谢 -anand - -@anand - -你好 这里是“ dhilipsiva”。 - -对于我们的“动态扫描”功能，我们动态创建一个新实例，进行扫描，并在完成扫描后终止它（出于安全原因）。 - -在 AWS 中，您将必须创建一个网络接口并将其分配给应该属于同一 VPN 的实例（在创建实例时）。 使用 AWS 时，我们必须等待设备启动，获取 IP 并在启动后继续启动扫描过程。 - -但是在 Google Cloud 中，无论何时创建实例，该实例都将自动可见，并且对同一 Project 中的其他实例也可以访问[它会自动进行联网]。 而且我们不必检测 IP，我们可以将实例的“名称”用作其他实例的域并进行访问。 IP 不是必需的。 在这种情况下，我们不必等待任何事情。 只需将一些启动脚本放入“动态扫描”实例中，一切便是事件驱动的。 - -不知道这是否能正确解释这一点，但可悲的是，这就是我可以分享的所有信息：P - -您可以寻找 Nginx + lua-resty-redis 而不是 nodejs。 -缩放效果更好且非常轻便 - -嗨，吉里达尔，那是一个非常好的建议。 感谢分享。 一定会调查一下。 - -架构图未完整显示，工作子系统被隐藏了！如果显示完整，将会更好！ \ No newline at end of file +您忘记了：“大量伪造的轮廓捕获了很多鱼”。 \ No newline at end of file diff --git a/docs/82.md b/docs/82.md index 8d3d935..ac7c548 100644 --- a/docs/82.md +++ b/docs/82.md @@ -1,350 +1,140 @@ -# 我们如何扩展 VividCortex 的后端系统 +# Etsy Saga：从筒仓到开心到一个月的浏览量达到数十亿 -> 原文： [http://highscalability.com/blog/2015/3/30/how-we-scale-vividcortexs-backend-systems.html](http://highscalability.com/blog/2015/3/30/how-we-scale-vividcortexs-backend-systems.html) +> 原文： [http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html) -![](img/3bd3303bcbae5781c18559acca255282.png) +![](img/9e364140091b80d83d988a6634e2f7c6.png) -*这是 [Baron Schwartz](https://twitter.com/xaprb) ， [VividCortex](https://vividcortex.com/about-us/) 的创始人& CEO 的来宾帖子，这是专门为当今的大型，多语种持久层设计的首个统一的性能管理工具套件 。* +我们很少听到有关流行网站在其形成时期所获得的颠簸和擦伤的故事。 [Etsy 的高级软件工程师 Ross Snyder](http://ross-snyder.com/) 通过在 [Surge 2011](http://omniti.com/surge/) ：[扩展 Etsy：什么地方出错了，什么地方正确了](http://www.youtube.com/watch?v=eenrfm50mXw)。 -VividCortex 是用于数据库性能管理的云托管 SaaS 平台。 我们的客户安装了代理，以衡量其服务器执行的工作（查询，流程等），并从中频繁地生成度量和事件。 代理将结果数据发送到我们的 API，在此托管我们的分析后端。 后端系统是数据库，内部服务（准微服务）和面向 Web 的 API 的集合。 这些 API 也为我们的 AngularJS 前端应用程序提供了动力。 +罗斯详细而诚实地描述了 Etsy 从 2005 年的原始创业公司到 2007 年为成功而苦苦挣扎的创业公司，再到 2011 年成为普通的手工，超级缩放，ops 驱动的机器。 -我们处理大量数据。 我们高速摄取指标和事件。 我们还执行以交互方式接触大量数据的分析。 我们不是唯一的，我不想暗示我们在事物计划方面给人留下深刻的印象。 我们尚未以“网络规模”运作。 尽管如此，我们的工作负载具有一些相对不寻常的特征，我们已经能够扩展到最大程度，同时在成本和基础架构方面仍然保持相当高的效率。 我的咨询生涯告诉我，建立这样的系统通常对公司来说是一个挑战（对我们来说一直如此）。 我们的故事可能对其他人有用。 因此，我将不必要地详细介绍工作负载的特定部分及其带来的挑战。 +从这个富有启发性的变革故事中可以学到很多东西： -## 我们所做的 +## 起源故事 -VividCortex 是一个复杂的系统，具有很多功能，但是热门查询（以及我们为实现此目的而捕获的数据）很容易成为对我们的后端产生重大影响的最重要的功能。 热门查询是一个查询类别的表，按所选维度从大到小排列，并显示一个综合行，该行显示的类别不符合前 N 个。 +* [Etsy](http://www.etsy.com/) 是手工制品的市场。 他们与买卖双方建立联系，类似于 eBay，他们不处理商品。 +* 开始时间：2005 年 6 月， [3 个人住在一个​​公寓里](http://www.seomoz.org/web2.0/interview/etsy/2006)。 +* 如今：250 名员工，每月浏览量达数十亿。 总共 6 年。 -[![top-queries](img/83a1ff858257bc3a2449da40823c3587.png)](https://camo.githubusercontent.com/2f0d8f8246190511ec9d7a5b99ed48b3d939fdc1/68747470733a2f2f636c6f75642e67697468756275736572636f6e74656e742e636f6d2f6173736574732f3237393837352f363838393234382f38353663663566612d643636302d313165342d383565312d6131393330653962636139662e706e67) +## 2007 年–当时的架构 -屏幕截图（顺便说一下，来自我们自己的工作量）显示了此功能，并精简了其基本功能。 热门查询实际上是我们的应用程序可以实现的一般任务类别的特定示例：您可以对查询，用户，流程，数据库等的度量进行排名，排序，过滤，切片和切块。 您可以同时在一台或多台主机上执行此操作，因此可以获取全局视图，然后向下钻取到特定主机或主机组。 您可以从许多不同的维度中进行选择。 所有这些本质上都采用度量类别，并按维度对其进行排名，保留前 N 个，最后将其余的折叠到所有行中。 +* Ubuntu，PostgreSQL，lighttpd，PHP，Python +* PostgreSQL 存储过程中全部包含业务逻辑。 一次非常常见的体系结构。 +* 前端使用包装在 PHP 中的存储过程调用与数据库进行了交互。 +* 大型中央数据库，具有按功能进行分区。 分区给他们买了一些时间。 +* 网站正常运行时间不是很好，这需要为电子商务网站付费。 +* 定期维护窗口意味着该站点将定期关闭。 +* 大爆炸软件部署通常会导致中断。 -我们还有很多其他的事情要做，但大多数事情在后端实现方面与许多指标和监视系统所做的并没有很大不同。 与“热门查询”相比，这不是一项重大的工程挑战。 +## 2008-失败的 Sprouter 实验 -## 时间序列数据 +* 现阶段仍是一家初创企业，最高人数为 20-30 人。 +* 康威定律：当团队生产产品时，产品最终类似于生产产品的团队。 + * 团队看起来像：开发人员，DBA，运营人员。 开发人员编写代码，DBA 编写存储的 proc，Ops 部署的代码。 一个筒仓组织，团队之间有很多墙。 +* 为了解决其可伸缩性问题，他们创建了中间件层，称为 Sprouter-存储过程路由器。 +* Sprouter 是位于 Web 服务器和数据库之间的 Python 守护程序。 给它一些参数，它调用存储过程，并返回结果。 从理论上讲，它可以进行一些缓存和分片，但是这些功能并未实现。 +* 希望 Sprouter 比数据库更容易扩展，因为围绕存储过程构建的体系结构几乎是不可能的。 +* 已于 08 年秋季准备就绪。自 09 年起弃用，此方法无效。 +* Sprouter 仍然是一个筒仓架构，类似于他们拥有的团队。 + * 由于 DBA 忙于所有数据库工作，这给开发人员带来了很多麻烦，这与时间表的依赖关系很大。 请记住，只有 DBA 才能进行数据库工作。 + * 已弃用 Ops 仍必须处理依赖项。 事实证明，Sprouter 依赖于 Python 的早期版本，这意味着他们无法升级 Python。 因此，有很多运营开销。 + * 由于 Sprouter 缓存了存储过程标识符（在升级期间无效），因此 Made 的部署情况更糟。 部署几乎每次都中断。 + * 没有分片，数据库仍然是单点故障。 -我们的时间序列指标是属于序列的带有时间戳的 float64 值。 该系列由度量标准名称和测量它们的主机标识。 时间戳当前是 UTC 中的 uint32 UNIX 时间戳。 +## 2008 年-大文化转变 -指标名称是点分隔的字符串。 我们从许多来源收集了大量指标，所有指标均以 1 秒为单位。 +* [Chad Dickerson](http://blog.chaddickerson.com/) 被聘为首席技术官，后来成为首席执行官。 他带来了新的文化，以前的文化不再存在于 Etsy。 +* 删除旧文化也被删除： + * 致力于 PostgreSQL 和存储过程。 + * 担心开发人员使用 SQL 编码。 + * 通常，开发人员都不会接触该产品。 + * 不频繁和大型部署是将代码移入生产环境的想法。 + * 美国国立卫生研究院的一般态度。 -* 每个数据库状态指标。 例如，对于 MySQL，这包括来自 SHOW STATUS 的数百个计数器，以及来自其他来源的数百个计数器。 -* 每个 CPU，每个网络设备以及每个块/磁盘设备，内存等的操作系统指标。 -* 操作系统中的进程级别指标，包括每个进程的 CPU，内存，IO，打开的文件句柄，网络套接字等。 +## 2009 年春季-前进的方式：第 1 部分 -但最重要的是，我们嗅探网络流量并解码流行数据库产品的有线协议。 目前，我们提供针对 MySQL 和 PostgreSQL 的 GA 支持，Redis 和 MongoDB 处于 beta 测试阶段，并且还有更多。 我们测量入站查询（或视情况而定的请求/命令/等；因产品而异）和响应延迟时间，并提取各种有用的细节（例如错误等）。 在无法监听网络的情况下，可以使用内置的工具，例如 MySQL 的`PERFORMANCE_SCHEMA`和 PostgreSQL 的`pg_stat_statements`视图。 这使我们能够支持诸如 Amazon RDS 之类的部署方案。 +* DevOps 救援 + * DevOps 是同时也是工程师和 Ops 的 Ops 人员。 + * 筒仓变坏了。 + * 信任，合作，透明和共同承担责任变得良好。 + * 我们在一起。 让我们互相帮助，共同完成任务。 -> 顺便说一句，捕获这些数据本身会带来有趣的问题，并且我们之前已经在博客上进行了介绍（两个示例： [netlink](https://vividcortex.com/blog/2014/09/22/using-netlink-to-optimize-socket-statistics/) 和 [perf 模式](https://vividcortex.com/blog/2014/11/03/mysql-query-performance-statistics-in-the-performance-schema/)）。 在这里，Go 是我们的一大财富。 +* 稳定网站： + * **安装/改进指标并监视**。 + * 尽可能垂直升级数据库。 还是不够，但是买了一些呼吸的空间。 + * 使开发人员生产**访问正在运行的代码**，以便他们可以帮助解决问题。 开发了一个名为 [StatsD](https://github.com/etsy/statsd) 的工具。 虽然并非所有开发人员都扎根于生产机器。 -最明显的挑战可能是我们收集的系列数量之多。 我们通过消化可变部分，然后对抽象查询进行 md5sum，将相似查询分类。 我们对此进行十六进制编码（对此我感到遗憾并为自己负责，这是一个愚蠢的决定），并将结果嵌入到指标名称中，例如 `host.queries.c.1374c6821ead6f47.tput`。 最后一个要素是维度，在这种情况下，是吞吐量（每秒的速率），但是它可能是诸如延迟，错误率，受影响的行数之类的许多东西之一。 此特定度量标准名称中的可变部分是`c`，它表示这是什么类型的操作（查询，准备好的语句执行等）和`1374c6821ead6f47`，它是摘要查询的校验和。 +## 持续部署-前进的方向：第 2 部分 -您可能会猜到，度量标准名称的可变部分可能是高基数的。 我们的一些客户生成了数千万种不同类型的查询，这导致时间序列的组合爆炸式增长。 在最坏的情况下，它是度量标准名称的每个可变部分的叉积，通常包括 2、3、4 或有时更多的可变部分。 +* 添加了**连续部署**。 Etsy 中的任何工程师都可以随时将整个站点部署到生产中。 每天发生 25 次，因为它很容易。 这是**一键部署**。 +* 开发了一个名为 [Deployinator](https://github.com/etsy/deployinator) 的工具。 **Chef** 用于配置管理。 +* 最大的收获是，**小更改集**一直在淘汰，而不是大规模部署。 如果出现问题，他们可以迅速找出问题所在并加以解决。 +* 添加了对代码运行的测试，以在部署之前验证代码是否正常运行。 +* 小组**始终在 **IRC** 上与彼此**进行交谈。 +* **质量检查由开发人员**执行。 在此过程中，没有单独的质量检查小组或阶段。 开发人员负责确保代码可靠。 较小的变更集使此操作变得容易。 +* 在持续不断的部署过程中，数据库架构更改是异常的。 他们每周有一天，即**模式更改日**。 功能标志用于打开和关闭功能，因此它们可以翻转标志，并且架构在适当的位置可以打开标志。 +* A / B 测试方案允许仅为管理员打开功能或将其发布给一定比例的用户。 他们创建一个**功能标记**，提交一堆代码，然后打开该标记，以便只有开发人员才能看到它。 +* 每年的一周内，每个开发人员都在寻求**支持。 他们将在假期前后加倍。 Ops 有自己的轮换方式，因此开发人员和 Ops 总是随时待命。** -我们还生成并存储许多其他数据。 关于查询之类的描述性指标还不够。 我们通过查询事件本身和各种其他事件（例如，为响应系统故障或配置更改而引发的事件）的单个样本来补充这一点。 事实证明，对这些数据进行缩放并不像时间序列度量标准那么困难，这主要是因为这些数据的读取工作负载并不难于扩展。 +## 2009 年春季-Sprouter 之死-前进的方向：第 3 部分 -## 写工作量 +* 使用**对象关系映射器**绕过 Sprouter。 他们写了自己的。 +* 现在（再次），前端 PHP 代码通过 ORM 直接与数据库对话。 +* 使用 ORM 将一些工作转移到了易于扩展的 Web 服务器上。 +* ORM 进行一些前端缓存。 +* ORM 是一个臭名昭著的瓶颈，但还没有解决这个问题，但他们意识到了这一潜力。 -按原始事实存储量，后端的写入工作量中最大的部分是时间序列指标。 查询样本和事件在磁盘上构成了很多数据，但这是因为它比时间序列数据紧凑得多。 许多小数据比中等数量的大数据更难处理。 +## 分片的到来-前进的方向：第 4 部分 -数据库内部和存储引擎的学生将了解，读取优化存储和写入优化存储在某些方面存在冲突。 如果要读取优化的数据，则可能需要在写入时进行额外的工作。 我们绝对需要一些读取优化，您将在后面看到。 +* 在 Sprouter 被中和后，数据库仍然是单点故障。 +* 由于 **Flickr** 的很多人都去了 Etsy，因此他们采用了 Flickr 的[分片方案。](http://highscalability.com/flickr-architecture) +* 基于 **MySQL** 作为简单的数据存储。 **经过 Flickr 的战斗测试**。 +* 将数据库**沿水平方向**缩放到无穷远甚至更大。 +* **主-主**复制用于删除 SPOF。 -写入特性非常简单：数据按时间戳顺序到达，而主要的挑战只是将其持久化以及读取优化所需的放大。 如您所见，我们做了很多事情来回避这一点。 +## 2011 年春季-关闭 Sprouter -我们将 1 秒分辨率的数据存储 3 天。 我们还将下采样分辨率降低到 1 分钟，并保持更长的时间。 两种保留限额均可在客户合同中协商。 在我们自己的系统中，我们保留 10 天的 1 秒分辨率。 +* Sprouter 使用停止所有策略释放。 当人们在基础架构上工作时，功能开发几乎停止了，大型部署在您的面前爆炸了。 +* 为了证明文化是如何发生变化的，有几个人在一边进行 Sprouter 的替换，然后他们**逐渐逐步使用**。 即使他们愿意，他们也不能只专注于 Sprouter。 +* 终于在 2011 年春季，从代码库中删除了 Sprouter。 -## 读取工作量 +## 2011-现在的 Etsy 体系结构 -我们的时间序列指标有两个主要的读取工作负载。 它们揭示了关于数据库的普遍真理之一：许多不同类型的数据通常可以放入数据库中，甚至是专用数据库。 对于完全不同的目的而言，彼此相邻的数据位可能很重要，并且涉及到完全不同的问题的答案。 这是要提防的。 +* CentOS，MySQL，Apache，PHP。 +* **逐步淘汰 PostreSQL** 。 仍然没有完成。 迁移基于每个功能。 +* **Python 不见了**。 他们需要让人们参与进来，以便在 PHP 和 MySQL 上实现标准化。 -工作负载 1（我称为范围读取）是在一个时间范围内以所需的分辨率读取一个或多个单独指定的指标。 一个明显的例子是绘制一个具有单个度量标准的时间序列图：宽 600 像素，上周的数据； 在时间戳 1426964208 和 1427569008 之间以主机 100 的 600 个间隔向我提供来自主机 Y 的度量 X。 原则上，读取路径并不十分复杂：找出数据所在的位置以及适合的分辨率（在这种情况下，可以使用 1 分钟的数据），找到起点，并读取终点直到终点 。 根据需要重新采样并将其流回客户端。 +## 获得的经验教训 -实际上，有很多细微差别，但它们并不能从根本上改变我刚才描述的内容。 细微差别包括多个指标（有时数百个左右），知道什么时间范围已被完全下采样，调整采样参数，同时从许多来源（包括可能会延迟的副本）读取数据范围等等。 这些都不是什么大不了的。 +* **开放和信任**比封闭和恐惧好得多。 +* 如果您聪明地执行**，则可能是错误的**。 如果您打算扩展规模，请不要冒险使用未经测试的前端到数据库交互方法。 Etsy 是一个电子商务网站，他们没有向月球发射火箭。 他们在做什么并没有那么大的争议，但这也不是那么普遍。 +* 在您离开后很长时间，今天做出的架构决策将产生重大影响。 +* 没有漏洞那么深，以至于可靠的缩放策略无法将您排除在外。 +* 没有前进的道路。 没有计划。 在文化转变开始后的几年中，这种情况逐渐发生。 + +尽管 Etsy 并未完全履行其 NIH 承诺，但由于他们自己构建了大多数内容，因此有关团队结构如何决定软件结构的文化/团队观察是一个深刻的问题。 [如上，](http://en.wikipedia.org/wiki/Hermeticism)以下，古人举行了会议。 在实践中如此清晰地看到它是很了不起的。 有趣的是，我们在网络开发团队中看到的全面变革-敏捷，叛乱，小组，独立行动，松散协调，目标驱动-与[第四代战争](http://en.wikipedia.org/wiki/Fourth_generation_warfare)的战斗策略和战术平行 。 我们看到集中化让位于分布式核心。 似乎复杂的不断变化的景观触发了并行的演变。 -只要对数据进行读取优化，范围读取工作负载就没有什么特别困难的了。 即使在很长的时间范围内和多个指标上，它通常也不是大量数据。 我们发现很难快速响应此类读物的大量请求。 稍后我将讨论我们如何确保数据经过读取优化。 - -2 号工作量比较难。 这是热门查询用例，我将其称为批量读取。 看起来是这样的：从时间戳 A 到 B 读取大量未指定的指标，并对它们进行汇总，排序，返回前 N 位，并包含计算通用行所需的数据。 可以通过解释范围读取的方法来获取跟踪数据，例如在前 N 个数据中显示每个结果的迷你图所需的跟踪数据。 “热门查询”工作负载还包括相同的注意事项，例如在可用时使用较粗的粒度，同时读取等等。 - -批量读取工作负载的难点在于，它涉及许多指标-可能达数千万甚至更多。 读取单个指标的速度很快-足够快，我们可以以比客户习惯更快的速度呈现充满图表的页面。 （我们经常收到有关图表运行速度的评论。）但是有数千万个图表？ 即使每公制是微秒，不是，我们已经在谈论数十秒。 我们通过这种批量读取获得的数据也非常大。 这就是当“粪便变得虚构”的时候。 - -还要注意，尽管这些指标受批量读取的影响，但它们也受各个范围读取的影响。 它不是“或”，所以我们无法进行简单的优化，例如将属于类别的度量标准与总是由完全合格的度量标准名称查找的度量标准分开存储。 我们可以复制它们，但这会带来不小的成本。 - -最后，批量读取的一些挑战性特征似乎几乎是偶然的。 例如，包罗万象的行似乎没什么大不了的，但对于用户界面来说，这两者都是至关重要的，在用户界面中，提供有关用户正在分析的应用程序工作负载以及我们的后端的上下文信息至关重要， 它可以代表大量工作。 请注意，在屏幕截图中，我们正在显示 159 个其他查询，这些查询被分组到了 catchall 行中。 这个数字可能高达数百万。 - -## 数据分布特征 - -除了大容量读取工作负载呈现的有趣读取特性外，数据本身还具有一些不寻常的属性，尤其是在值的分布和密度方面。 - -大多数监视系统和时间序列数据库都是为密集指标（例如 CPU 或内存利用率）构建的。 密集度量标准属于可以依靠其存在的事物，并且在度量它时，总会得到一个值。 大多数用于监视数据的用例都隐式地假设所有指标都是密集的。 这说明了 RRDTool，Graphite 的 Whisper 后端等的设计。 - -现代应用程序体系结构已经对这些时间序列数据库提出了重大挑战，因为一切都变得高度动态且短暂。 在目前的极端情况下，我们拥有诸如 Docker 和微服务之类的东西，最终我们将拥有许多像亚马逊的 Lambda 那样运行的系统，其中计算节点本身的存在是非常短暂的。 目前，在这种环境中进行监视的挑战已基本解决。 我认为没有一个流行的时间序列数据库可以处理它。 - -但是在 VividCortex，高度稀疏和动态的数据不是理论上或新兴的用例，而是我们目前的现实。 查询，流程以及我们监控的所有其他各种可变活动，都会生成具有这些特征的监控数据。 如果我们要处理的一件事很不寻常，那很有可能。 （再次，我不主张唯一性，只是不寻常）。 - -这也是一个程度的问题。 在具有这种数据的*中，我们并不是唯一的，但我们受到的打击可能会比看上去相似的其他公司/产品受到更大的打击。 部分原因是大多数从查询角度衡量产品的产品都是从应用程序的角度来看的。 应用程序代码是有限的，并且不是临时性的，这会生成数量有限的不同类型的查询和其他要度量的内容。* - -但是，我们有坐在服务器上的代理，并且正在看到服务器的全部工作负载，而不仅仅是来自已检测应用程序的工作负载。 除非您看到典型服务器从不受监视的来源获得多少工作量，否则这种区别似乎并不重要。 这包括人工活动和其他临时活动，监视系统本身，后端应用程序，cron 作业等。 实际上，仅用于衡量应用程序生成的查询的典型 APM 工具确实存在很多盲点。 - -无论如何，我们系列的大部分内容（即基数）都是稀疏的，有时仅以相隔几天或几周的间隔记录点。 - -因为这构成了系列的大部分，但仅占数据的一小部分，所以任何假设将某个块/页面/范围用于一个系列的系统（假设以后将被填充）都是行不通的。 那里几乎是空白。 - -## 读或写优化？ - -在存储和检索我们一直在讨论的数据类型时，存在着一个巨大的，存在的，生存或死亡的问题来回答：读取优化还是写入优化？ 通过研究折衷，您可以轻松地建立事业。 - -如果对其进行了读取优化，则将面临巨大的写扩展挑战。 如果它是写优化的，将存在读取挑战。 让我们看看为什么。 - -如果我们认为主机和指标是真正一起构成系列 ID 的，那么问题就等同于询问我们要存储按时间戳排序还是按系列排序的数据。 - -对于（概念上）仅追加的不可变存储（例如我们的时间序列数据），我们将按照时间戳顺序对其进行读取（对吗？），乍一看，写优化似乎是理想的选择，因为数据将自动按照时间戳顺序进行存储。 只需在数据末尾附加点： - -``` - v host metric ts value - | 1 a.b.c.d 1426964208 123 - | 1 d.e.f.g 1426964208 87654 - t 2 a.b.c.d 1426964208 19283 - i 2 d.e.f.g 1426964208 183 - m 3 a.b.c.d 1426964208 9876 - e 4 l.m.n.o 1426964208 72736 - | 5 a.b.c.d 1426964208 17364 - | 1 a.b.c.d 1426964209 129 - | 1 d.e.f.g 1426964209 87656 - v 5 q.q.q.q 1426964209 9988 -``` - -问题在于我们想要一起读取的数据没有聚集在一起。 如果要读取主机 1，从给定的时间戳到另一个时间戳的度量`a.b.c.d`，我将遍历*大量*不需要的数据来执行此操作。 利用上面描述的稀疏特性，您可以轻松地计算出，我可能比我关心的多读取了几个数量级的数据。 这是*读扩增。* - -自然，索引是解决此问题的方法。 这就是发明索引的目的。 - -但是索引将复制数据并写入，并为写入引入随机 I / O。 当工作集超出内存时，B 树索引的性能和开销也会大大降低，并且我们的数据比内存大。 诸如 LSM 树之类的新一代索引并不能解决所有这些问题。 无论我们怎么看，我们都不会免费获得读取优化和写入优化。 一定会有一些读取，写入和/或空间放大。 - -鉴于纯写优化存储将无法正常工作，正确权衡的问题至关重要。 如何在不对写入造成严重影响的情况下对数据进行读取优化？ 换句话说，用于读取优化的数据的正确组织是什么？ - -通过在上面的示例中显示时间序列表的架构，我已经部分给出了我们答案的早期版本。 我们以`(host, metric, timestamp)`顺序在数据上定义了集群主键。 因此，这些点按主机和指标分组在一起，并且在其中按时间戳排序。 这样可以在一段时间内针对一组单独识别的系列的范围读取工作量优化数据。 - -但是，此群集对批量读取工作没有任何作用。 对于该工作负载，我们正在一系列时间戳上读取大量数据，并且正如我所提到的，这些系列构成了大多数数据。 因此，最有效的方法可能就是扫描整个范围，并丢弃不需要的数据。 二级索引（时间戳优先）可能是诀窍。 我们走了这条路，事实证明，由于要捕获的指标多种多样，因此此处的数学也不可行。 因为我们捕获了许多不同的批量指标组，但一次只查看一组，所以我们仍在检查少数数据，并且仍将极大地放大读数。 - -在早期，随着我们继续向捕获的数据集中添加越来越多的数据，这个问题变得更加严重。 回想一下，这是我们客户最有价值的用例。 这使其成为非常重要的问题。 我将回到这个问题，稍后再解释我们的解决方案。 现在，我想探索更多我们的架构，并为其他各种有趣的事物设置背景。 - -## 分片和分区 - -正如您所期望的，我们拥有多租户分片存储架构。 分片有助于满足我们的几种需求：写入扩展，读取扩展，数据隔离和租期以及安全性。 - -通常，只能通过分片来实现写缩放。 实际上，这确实是在全局中进行分片的唯一原因。 可以通过“横向扩展”复制来很好地解决读取扩展问题，这可以提供更多的读取容量。 - -数据隔离对我们很重要。 有时，SaaS 供应商会在所有客户中展示诸如实时分析之类的信息。 这种功能意味着一定程度的混合和缺乏隔离，我觉得有些不安。 我们正在努力防止某人获得广泛，不受限制的访问他们不应看到的数据的可能性。 在安全性与便利性之间取得平衡，我们倾向于使针头远离便利性。 （我们还[对敏感数据](https://vividcortex.com/blog/2014/11/11/encrypting-data-in-mysql-with-go/)进行加密，例如在飞行中和静止时的 SQL 端到端示例。[在即将举行的 Percona Live MySQL 会议](https://www.percona.com/live/mysql-conference-2015/sessions/encrypting-data-mysql-go)中，我将对此进行讨论。） - -为此，我们的分片单位是客户的“环境”-考虑分期，生产等。 主机属于一个且只有一个环境，并且所有 API 访问都被隔离到一个环境中。 API 令牌被定义为只能访问一个环境，因此在逻辑级别和物理级别上，每个环境都与所有其他环境隔离。 有时我们谈论按环境和主机进行重新分片，但到目前为止，即使是最大的客户环境也没有问题。 - -分片实际上是分区，我刚刚描述了按环境分区。 由于多种原因，我们还按时间范围划分数据。 一种是使清除过期数据变得容易。 删除数据的成本太高了，在许多系统中，至少要使系统的写入工作量增加一倍，甚至更多。 取消链接文件要好得多。 从本质上讲，它是免费的。 - -按时间分区是我们满足批量读取工作负载需求的方法之一。 按时间进行的分区本质上是一个粗粒度，开销少，时间戳优先的索引。 起初，我们一次分配一天； 现在，我们一次分配一个小时用于 1 秒数据，一天一次分配一个 1 分钟数据。 - -我们最初进行分区的方式是我要承担个人责任的另一个错误。 开始时，我们使用本机 MySQL 分区。 这有一些好处，我认为这些好处将胜过任何缺点： - -* MySQL 本机修剪不包含请求时间戳的分区 -* 分区表隐藏了应用程序代码的复杂性 -* MySQL 5.6 为分区添加了许多不错的功能，例如拉出一个分区并分别对其进行操作，然后将其交换回（EXCHANGE PARTITION）的功能。 - -我还认为，随着 MySQL 5.6 的改进，我们不会遇到早期版本的 MySQL 分区遇到的问题。 我是对的，我们不是。 我们遇到了其他人！ 哎呀。 分区维护作业（删除旧分区并创建新分区以保存将来的数据）将阻止长时间运行的查询，从而导致一切停止，并使服务器无法连接。 模式更改曾遇到类似的问题，在确定大容量读取工作负载无法正常工作并试图修复它时，我们不得不做几次。 模式更改还消耗了大量时间，并且由于元数据锁定等原因，模式更改永远不可能完全熄灭。 这些都是无聊的可预测的事情，只是因为我对它的思考不够深而发生。 - -因此，我们基本上遇到了几次“ ALTER TABLE 死机”和“分区维护死机”，然后从一开始就切换到应该做的事情。 我们为每个时间范围创建了单独的表，并使用表名对架构版本，数据分辨率和时间范围进行了编码。 1 秒数据的架构版本 1 的示例表名称为`observation_1_s_1424444400_1424448000`。 （我们将时间序列指标称为“观测值”，因为命名很困难，而且我当时还没有想到“点”。） - -新的模式版本只是被写入新表中，并且当从所有环境中清除旧数据时，我们最终可以删除旨在处理该模式版本的代码。 我们不再更改。 旧数据将长期存在。 - -这类似于我在 New Relic 上看到的情况，并且我认为此博客上有较早的文章对此进行了讨论（我也曾在 New Relic 进行过咨询），但是我认为分区的改进使其变得不必要。 为我们。 不幸的是，这是成为顾问的缺点之一。 您认为您了解系统方面的知识，但您不了解 jack，因为您只是在系统附近，您自己还没有操作过它。 活到老，学到老。 - -## 紧凑的存储 - -我们的架构看起来并不像我之前显示的那样。 如果考虑以下伪代码之类的模式及其包含的数据，则会发现效率低下： - -``` -observation ( - host number - metric string - ts number - value number - primary key(host, metric, ts) -) -``` - -首先，将有很多主机重复。 接下来，您将获得指标，这些指标也将疯狂地复制。 时间戳也将基本相似。 而且大多数时间序列值都为零。 - -最后，最重要的是，每个点将有一行。 这本质上是行标头的疯狂数目，最后附加了一些小数值。 - -为了解决这个问题并更紧凑地存储我们的数据，我们做了几件事： - -* 我们使用主机 ID 和度量 ID，而不使用诸如主机名和度量名称之类的文本字符串。 -* 我们以向量的形式将值分批处理，因此它不是每秒一行，而是每更长的时间范围（当前是每分钟，但将来可能会改变）一行。 这将分摊行中键的成本，这是我使用多年的技术。 它确实使某些事情不太方便，但是值得这样做，因为它使行数减少了 60 倍。 -* 我们并不总是存储确切的值。 我们使用一种定制的压缩算法，该算法利用了我们看到的时间序列数据的特征。 这进一步减少了我们价值观的存储空间。 某些高动态范围指标有时可能只占误差的一小部分，但没人在乎。 -* 我们存储大多数指标的增量，这些指标通常很小且易于压缩。 没有人会像查询数量一样在乎计数器的实际值。 无论如何，它将重置并重新启动。 人们关心的是这类数据的费率，而不是价值。 我们通过计算时间范围内的增量（例如每秒）来生成速率。 我们将某些类型的数据计算为值和费率，但这只是少数。 -* 我们不存储零。 一个“心跳”度量标准（例如系统时间戳或正常运行时间计数器）足以确定我们是否及时测量了一批值，因此我们可以分辨出零值与缺失值之间的差异。 这有助于逐步改变度量标准，其中有很多。 -* 我们计算各种汇总指标，位图等，并将它们与向量一起存储。 这对于不需要访问每个点的操作很有用，例如批量读取。 它还使我们能够进行诸如下采样之类的事情，而不会犯诸如“平均值”问题之类的愚蠢数学错误。 - -## API 和服务 - -我们的外部和内部 API 主要是基于 HTTPS 的 JSON。 一些内部服务使用协议缓冲区而不是 JSON，但是这些附加的依赖项和模式定义是我们仅在需要时添加的内容，并且在我们认为事情已经解决了足够的时间之后，我们就不会浪费额外的程序员时间来重做我们没有做的事情。 没错。 - -我们最初只有一个整体的 API 流程来处理所有内容。 当然，这仅仅是原型，我们很快就放弃了。 整体式 API 存在许多问题，例如成为单点故障。 - -我想建议一些通用的良好 API 做法； - -* 想一想 API 设计。 不要为自己设计 API，而是为可能想要创建一个假设的应用程序来做与您自己的工作截然不同的人设计 API。 请参阅 [Interagent 指南](https://github.com/interagent/http-api-design)。 -* 分离出您的读写路径。 读取和写入工作负载通常非常不同。 对于我们这样的服务，最重要的是我们不会丢失传入的数据。 长时间运行的繁重请求在某些情况下会轻易导致读取错误影响写入，并因此而丢失数据的情况。 使用单独的进程，甚至可能使用单独的服务器进行读写。 -* 构建 12 要素应用程序。 首先，我不理解或不同意 12 因子原则，尤其是日志记录，守护进程和配置准则。 我已悔改了自己的罪过。 -* 使用“干净”的体系结构，并像洋葱一样分层。 拒绝让内部层的任何事物知道，更不用说与外部事物进行交互。 这意味着内部工作或服务不应与您的公共端点进行交互。 将相同的原理应用于您的代码：代码中的依赖项应仅指向内部，而不能指向外部。 - -随着时间的推移，我们已经转向了一组准微服务的外部 API，其中（通常是很小的）一组相关端点位于单个二进制文件和进程中，但通过读写分开。 我们通过在某些代码库中构建读写路径来重用某些代码，但是通过 a）仅启用一组读写功能的配置和 b）代理规则，仅激活一组。 - -当此类服务成为我们要在内部构建的东西时，我们将进行下推重构，充分利用此 API 的实质并将其作为内部服务提供。 然后，外部服务将其大部分工作委托给该内部服务，我们也可以在内部其他地方使用它。 - -我们还将视情况处理特殊类型的数据和工作负载。 我们有专门用于时间序列数据提取的 API 和内部服务的单独集合，以确保我们可以快速而可靠地持久保存数据，并将写回确认给发送数据的代理或其他 API 客户端。 这些 API 是相当薄的前端：它们将写操作发送到 Kafka，然后完成。 - -然后，Kafka 使用者将数据从 Kafka 中流回并保留下来，大部分存储到 MySQL 中。 还有少量的 Redis。 - -卡夫卡很棒。 我希望它不使用 Zookeeper，并且对分区管理和故障转移有些不满意，但总的来说它是简单而可靠的。 但是，更重要的是它启用和鼓励的架构模式。 如果您还没有研究 [Jay Kreps 的有关基于日志的体系结构](https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)的博客文章，我鼓励您这样做。 尤其是如果您不希望消息队列/总线使您的整体体系结构更加简单明了，则应独立于 Kafka 本身考虑该文章中的想法。 - -我们非常感谢 Kafka 的 Go Sarama 客户。 非常感谢 Shopify 团队和其他人编写它。 没有它，Kafka 对我们来说将不是一个可用的解决方案。 - -通过使用 VividCortex，我们发现并解决了 VividCortex 的许多问题。 我们使用暂存来监视生产。 我强烈推荐这种模式。 生产永远不要自我监控，因为如果出现问题，您将无权访问数据以对其进行诊断。 - -我们还依赖于许多外部服务，包括 GitHub，HipChat，Dyn，Pingdom，CircleCI，VictorOps，BugSnag，还有很多我可能会为遗漏而感到不适。 最重要的两个是 GitHub 和 CircleCI。 我们还有一个几乎完全自动化的测试，构建和部署系统，我们可以通过 Hubot 聊天机器人（chatops）对其进行控制。 它与各种服务交互，包括自定义 Go 内部服务，Jenkins 和 Ansible。 CircleCI 立即对新代码进行了测试-我是否提到了它们的惊人程度-如果通过了，则取决于是否在分支中，将其部署到开发或暂存中。 - -在“穷人的 Heroku”之后，我们创建了一个称为“ Pooroku”的系统，以将每个人的 dev 分支推送到我们 dev 服务器的适当命名的子域。 合并的主人可能会自动将其部署到生产中，具体取决于相关代码的重要性和潜在后果。 如果没有自动部署到生产环境，则快速`/deploy foo to prod`会处理它。 - -所有这一切都发生在我们的聊天频道中，因此每个人都可以准确了解正在发生的事情并学习如何做。 如果您不熟悉 ChatOps 的好处，我建议您在[上写 Owen 的博客文章](https://vividcortex.com/blog/2014/06/02/chatops-at-vividcortex/)。 我们每天使用 Owen 等人构建的出色系统部署代码数十次。 我们还做大量其他事情。 在经历了 ChatOps 和持续交付之前，我不知道自己缺少什么。 - -## 使用围棋 - -我们从一开始就是 Go 用户，我们很自豪以各种方式支持 Go 社区并为 Go 社区做出贡献。 我们所有的外部和内部 API，服务，Kafka 使用者，工作者和其他系统程序都是用 Go 编写的。 这是我们能够扩展到已经达到的点的一个重要原因。 它的效率，对并发的支持，简单明了，出色的标准库以及静态编译的二进制文件，使它通过多种方式实现了梦想。 - -如果不是 Go 语言，那么我们在产品开发方面的距离可能只有一半，所支付的费用是 EC2 账单的五倍，或两者兼而有之。 - -我们在 Go 和数据库上写了[电子书](https://vividcortex.com/resources/building-database-driven-apps-with-go/)。 我们犯了很多错误，而这本书主要是关于我们在此过程中学到的知识。 - -## 硬件 - -我们将整个应用程序托管在 EC2 中。 我们故意使用相对弱的实例，这些实例具有有限的 CPU，RAM 和 EBS 卷，且配置的 IOPS 数量适中。 这在很多方面都是错误的。 面对大多数人关于在 EC2 中运行数据库的建议，这种说法不成立。 值得注意的是，这正是我 5 年前谴责的那种情况。 但是，它运作良好，并且是一门金融学科。 这也是避免短期解决硬件问题并突然意识到我们远远不能扩展以满足严重问题的需求的一种方法。 - -我最近没有看我们正在摄取多少数据（这是那些不方便的跨环境任务之一），但是截至几个月前，我们平均每秒摄取 332,000 个时间序列点，或每天超过 280 亿个 。 那时我们只有三个分片，因此从本质上讲，每台服务器每秒存储大约 100,000 点。 除了执行扇出批量查询时，服务器几乎完全处于空闲状态。 请记住，这是完全 ACID 事务存储，而不是希望与祈祷。 - -我们还在本地和跨区域复制每个分片，以进行读取扩展，故障转移/ DR 和进行备份，因此，我们的基础架构中实际上有 3 台以上的服务器！ - -对于读者来说，将这个数字与与此主题相关的类似博客文章进行比较，以了解我们在原始硬件效率和成本方面的表现如何，可能是一个有趣的练习。 我认为，将我们与其他公司进行比较的要点之一是，您经常可以进行很多优化，并且可以获得 1-2 个数量级的效率，甚至更多。 同时，我的诚实评估是，相对于我们的同龄人，我们既不是超效率的，也不是完全低效率的； 我们有点中间。 - -很好 但是精益运营需要付出一定的代价，您必须全面优化业务，而不仅仅是 EC2 账单。 上市速度是其中的一个重要因素。 - -## 没有银弹 - -在我描述我们的系统（尤其是我们的时间序列后端系统）的很多时候，人们会问：“为什么不只使用 X？” 该建议通常听起来很合理，直到您更深入地了解我们的要求为止。 这不足为奇，因为我们很长时间都不知道我们的要求。 - -我写了的[博客文章中解释了许多要求。 该职位似乎引起了很多人和公司的共鸣。 我认为在问我们为什么不使用特定解决方案之前，有必要先了解我们要解决的一些问题。 （建议卖方在阅读一些愚蠢的解决方案之前，先阅读该文章并进行每节点每秒的运算，以使我们使用的服务器数量是目前的 100,000 倍。）](http://www.xaprb.com/blog/2014/06/08/time-series-database-requirements/) - -我不想表现出防御性，好像我的自我让我不愿意考虑更好的解决方案的可能性。 但是请记住，实际上有数百种可能的解决方案需要考虑和/或评估。 那是不切实际的。 快速淘汰是我的首选策略。 - -人们提出的许多银弹包括 HBase，OpenTSDB，Cassandra 和 Hadoop。 这并不是要批评他们中的任何一个。 结合数学，基准测试和对我们发现的要求的检查，我得出的结论是，其中一些条件较差，一些条件相同，有时甚至更好，但没有一个是即用型的 证明切换的合理性。 - -某些解决方案可能会取得成功，但这样做的代价是要通过大量的缓存和批处理使事情进一步复杂化，换句话说，不是交钥匙的解决方案。 当然，我们不使用 MySQL 作为统包解决方案，但它仍然设置了很高的标准。 同样，保持技术表面积简单和清洁本身也是我们的一大胜利。 - -我的确会继续关注特定的解决方案或组合以及某些数据库中正在出现的工作。 我对 NDB（MySQL Cluster，您从未听说过的最令人难以置信的分布式实时数据库），InfluxDB，Cassandra 和 Spark 尤其感兴趣。 - -否定所有选项的详细信息将花费很长时间，但是作为特定反驳的*样本*，使用 Cassandra（通常用于时间序列数据）将需要传输数百 GB（或更多）的数据 通过网络为我们的一些客户提供服务。 那是因为它尚不支持对数据库本身内的表达式求值。 人们建议的大多数系统通常都存在类似的反对意见。 通常的解释是，当人们将解决方案 X 应用于一个类似的问题并获得成功时，规模的一个维度是他们处境中的 O（1），而这是我们的交叉乘积因子。 许多事情在许多情况下都可以很好地工作，但是当您将一个或三个额外的叉积投入组合时，将变得很困难。 - -有其他公司存在的证据，证明它们对非常大的数据集进行批量读取类型的查询并使其快速。 例如， [Scalyr 在智能暴力数据处理](http://blog.scalyr.com/2014/05/searching-20-gbsec-systems-engineering-before-algorithms/)上有一篇不错的博客文章。 New Relic Analytics（nee Rubicon）使用蛮力。 我的一些顾问还熟悉内部系统，这些内部系统会在非常大的公司内部大规模进行这种分析。 我们已经详细讨论了技术，成本和结果。 - -关于这一点，需要注意几件事。 一是我们已经自己做了很多扇出。 Go 使此操作非常容易。 当我们进行批量读取查询时，大量的计算和存储变得很忙，而且我们的处理效率很高，因此我认为没有很多未开发的潜力。 但是，另一件事是，您可以执行 100％扇出的数量有实际限制。 如果设计使一个庞大的查询停止了除一个用户之外的所有用户的访问，那么您将遇到可伸缩性问题。 这就是至少其中一些系统的工作方式； Scalyr 博客文章很好地解释了这里的一些细微差别和折衷。 最后，大规模扇出自动需要大量数据复制，这加剧了写入扩展问题。 - -最后，尽管有一小段时间我以为使用批量读取查询可能会使用蛮力，但我坚信这不会。 后来，我的一位顾问向我介绍了一位存储专家，他比我更了解硬件的物理功能。 我们在白板上重新进行了数学运算，并找到了类似的答案-要用数千美元的最昂贵的机器以不可思议的成本运行最先进的 PCIe 存储，以足够快地对它进行暴力破解，以满足我们的要求。 正如他所说的那样，“离可行的解决方案还有很多零”。 - -## 批量读取优化的演变 - -通过上述上下文，您可能会看到，我们基本上是在使用 MySQL 而不是简单地将其用作构建为分布式 Go 服务集的大规模时间序列数据库的存储引擎。 我们利用 SUM（）和其他几个函数使计算尽可能地靠近数据并避免网络传输，并且利用了 InnoDB 的聚集索引，这是一个巨大的胜利。 否则，我们将在 MySQL 之外进行很多繁重的工作。 - -希望批量读取的一些挑战现在对您显而易见。 您可能可以做一些数学运算，并弄清楚存储多少数据，拥有多少行等等的粗略数。 但是，批量读取操作的实际实现具有许多重要的细节。 冒着太多的香肠制作方法的风险，我将更深入地研究其中的一些。 - -回顾一下： - -* 可以按多种维度对多种事物进行排名 -* 很多稀疏指标 -* 很多主持人 -* 时间范围大 -* 搭配包包的 Top-N - -早在最初只是原型时，我们的第一个实现在每个地方都存在很大的效率低下的问题。 我们基本上采用了您可以想象的最简单的嵌套循环方法，如下所示： - -1. 查询指标表并找到与所需模式匹配的所有可能指标。 -2. 对于每个主机，每个指标， -3. 获取时间范围内的指标并对其重新采样。 -4. 使用插入排序来保留前 N 个。 -5. 总结剩下的全部内容。 -6. 返回。 - -即使对于较小的数据集，这也需要花费很长时间，并且往往会使内存不足。 我们立即注意到的最大的效率低下之一是，在大多数情况下，步骤 3 不会返回任何数据。 另一个明显的问题是，即使查询非常快，对数据库执行如此多的查询确实非常耗时。 - -下一步是停止执行单指标读取，并在查询中使用指标/主机对的组合，例如`metric IN(...) and host IN(...)`。但是，这些列表非常大。 MySQL 基本上将此类列表的每种组合视为单独的查询，就像在将其推送到数据库中之前所做的一样。 很好，除了用于此类查询的计划过程一次重新计划每个组合而且在 InnoDB 中并不便宜。 我在高性能 MySQL 中写了更多有关此的内容。 这些查询花了很长时间来计划，即使我们是小批量地进行。 同样，由于数据的稀疏性质，大多数组合在任何给定的时间范围内都没有产生任何行。 - -显然，我们需要粗粒度的时间戳优先索引只是为了消除考虑中的查询组合，因此我们没有尝试寻找它们。 我们仍将大部分时间用于寻找不存在的数据。 - -知道这并不是一个真正的大胜利，但是还没有找到更好的方法，所以我们引入了今天内部称为“选择不同”的内容。 针对我们的数据库可能有很多 SELECT DISTINCT 查询，但是这个臭名昭著，以至于用这两个词就足以识别它。 该查询找到了一个时间范围内存在的指标和主机的不同组合。 过了不久，我们才找到解决方案，对此进行了很大的改进，因此我们遭受了如此之久的痛苦，难以接受。 - -要解决此问题，我们需要一种时间序列事实，即“在时间范围 X 内，主机 Z 上的指标 Y 具有值”。 理想情况下，我们可以问“对于时间范围 X 和主机 Z，存在哪些度量标准”的问题。 一种方法是在时间序列指标表上创建二级索引，但这是一种超昂贵的方法。 另一个方法是创建大致的时间段（例如，按小时计算），并针对在该小时内进入我们的 API 的主机/指标的每种组合简单地记录“是”。 即使已设置为真，也要设置为真，这种行为在 MySQL 中是残酷的低效，因为它仍然是事务，它仍然会被记录下来，并且还会执行许多其他工作。 我们添加了 Redis 来处理该索引。 这大大改善了情况，使我们能够更快地制定特定客户的热门查询。 - -我们还向指标表添加了 firstseen / lastseen 列，我们在嵌套循环算法的第 1 步中使用了它来进一步修剪。 我们也将 Redis 用作更新这些列的写缓冲区，因为使用每个传入指标更新这些行将花费太多精力。 - -另一个改进是在重新采样和生成前 N 个和总体的过程中。 我们消除了重采样，只是寻找所需维度的前 N 个最大和。 直接将其推入 MySQL 是简单有效的，查询类似于 - -``` -SELECT host, metric, SUM(val) FROM tbl -WHERE ts BETWEEN x AND y -GROUP BY host, metric -ORDER BY SUM(val) DESC LIMIT N -``` - -我们利用向量的摘要列和其他一些次要的东西来尽可能地改善此问题，但是当我们开始计算每个类别的摘要序列并使用它们来避免产生总包时，取得了巨大的成功。 以前我们需要包包，所以我们可以显示每个系列构成了多少。 这一点很重要，因为没有它，您将不知道是否要优化等其他不重要的东西。 由于总系列只是类别中所有系列的总和，我们可以通过将前 N 个加在一起并从总数中减去它们来消除此步骤。 这消除了对单个系列的绝大多数访问，因为对于大多数客户而言，大多数数据都处于拖尾状态。 - -另一个优化来自观察大多数客户要么查看所有主机上的热门查询，要么仅查看一台或几台主机。 当然，最坏的情况是查看所有这些。 为解决此问题，我们引入了由该系列的所有主机聚合启用的所有主机快速路径。 通过这种优化，Top Queries 对于 1000 个主机的效率几乎与单个主机一样。 （这是读者要弄清楚为什么它效率不高的一种练习。） - -最后，我们消除了与查找与类别模式匹配的指标相关的效率低下的问题，并消除了将系列数据归为一个类别时将其数据聚类的方法。 为此，我们识别并编号了指标的类别，并在“观察”表中添加了类别列作为主键的一部分。 这再次依赖于 InnoDB 的集群主键存储的有效性。 它还使 Redis 成为 MySQL 外部的“存在”索引而过时了，从而消除了整个类别的故障场景和不一致情况。 Redis 很棒，但是更少就是更多。 - -所有这些优化都有很多很多细节，我在掩盖一些细节并引入了不准确性，但是我已经涉及了很多细节，所以我就此止步。 - -所有这些的要点在于，我们现在能够支持跨大量的稀疏指标与大量主机交叉产生的批量读取，以及通过利用数据中的各种模式来优化单个指标的读取 各种汇总指标，数学和 InnoDB 的聚集索引。 - -## 集群主键 - -集群主键是 MySQL + InnoDB 的巨大好处之一。 我[在其他地方](https://vividcortex.com/blog/2014/04/30/why-mysql/)写了关于为什么使用 MySQL 的信息。 - -我们将数据存储在 MySQL 中的方式，使它为数据进行索引以进行读取优化，同时使写入尽可能地高效，其工作方式比我们期望的要好。 它之所以如此出色的原因之一是 InnoDB 是一个非常复杂的存储引擎。 相对于您认为效率更高的许多数据库和存储引擎，您会惊讶于 InnoDB 算法的真正先进程度以及使用它免费获得的收益。 这包括事务日志记录，写优化，检查点和缓冲池管理等。 如果我们必须自己构建这些东西，或者使用诸如新一代 LSM 存储引擎之类的东西，那么我们几乎肯定会遇到诸如可怕的边缘情况，大量的写入停顿以及极其不稳定的性能之类的事情。 我们采用 VividCortex 进行设计的原因之一是[，因此我们可以准确地检测出这类问题](https://support.vividcortex.com/faults/)。 对于 InnoDB 和 MySQL 工程师来说，我们在低端 EC2 实例上获得了出色的性能，这证明了这一点。 - -运作良好的另一个原因是我们分割数据的方式。 这使索引树足够小，以至于当它们的工作集大于内存时，我们不会碰到写悬崖。 其结果与 InnoDB 复杂的刷新算法相结合，是我们的读取优化实际上并没有对我们的写入造成太大的损失。 - -最后，InnoDB 的聚集索引。 如果我们没有使用按索引顺序对数据进行物理聚类的数据库，那么它的工作效率将不那么高。 在 MongoDB 或 Postgres 中可能有多种方法可以做（在 Postgres 中有一些功能，例如部分索引，可以为我们提供更多优化）。 但是，如果没有集群主键，很难想象如何使另一个基础数据库对我们来说像 InnoDB 一样高效。 - -但是，MySQL 和 InnoDB 中的某些功能仍然不尽如人意。 存储引擎接口固有的效率低下，并且存在许多种锁定方式。 对于我们根本不需要的许多 ACID 东西，还有额外的开销； 如果它们能够更好地工作，那么某些事情将使我们受益，例如数据压缩（在 InnoDB 中，这对我们来说不是胜利，但可以实现更好的实现）。 这种低效率的清单很长，我怀疑机会成本是几个数量级。 不过，与我研究过的几乎所有其他广泛使用的数据库技术相比，MySQL / InnoDB 似乎处于良好的状态。 - -## 结论 - -希望您发现这对我们扩展服务规模以满足不断增长的客户群和异常需求是一个有用且有趣的旅程。 +## 相关文章 -我们一直在改进我们的系统。 可以这么说，我们还有很多干粉，但是我们并没有过早地解决我们既看不到开始发生又无法避免的问题。 +* [Etsy 博客](http://codeascraft.etsy.com/) +* [Flickr 架构](http://highscalability.com/flickr-architecture) +* [优化开发人员的幸福感](http://codeascraft.etsy.com/2011/06/06/optimizing-for-developer-happiness/) +* [推送：Facebook，Flickr，Etsy](http://codeascraft.etsy.com/2011/06/01/pushing-facebook-flickr-etsy/) +* [不断变化的战争面孔：进入第四代](http://globalguerrillas.typepad.com/lind/the-changing-face-of-war-into-the-fourth-generation.html) -最后，这不是魔术。 有很多创造力和很多数学，大部分是餐巾纸。 数据受物理学定律的约束，我们可以在很大程度上预测挑战的规模以及解决挑战所应采用的技术的局限性。 更加困难的是预测客户将为产品找到的用例类型，以及由此需要向数据库提出的问题类型。 +我很好奇要了解有关为什么分片 PostgreSQL 在 2011 年不如分片 MySQL 来证明引入第二个数据库系统的理由的更多详细信息吗？ -VividCortex 的出色团队给我留下了深刻的印象，他们每天都在解决棘手的问题，并且看起来很容易。 非常感谢他们，我们的投资者和顾问，许多慷慨的朋友和客户。 +我不知道 PostgreSQL 是否有问题，因为 Flickr 系统是建立在 MySQL 之上的，因此这显然是实现其方案的选择。 -## 相关文章 +Etsy 工程团队还有一个博客，标题为“ Code as Craft”。 += > http://codeascraft.etsy.com -* [关于黑客新闻](https://news.ycombinator.com/item?id=9291237) -* [GopherCon 2014 使用数据库/ SQL 构建数据库应用程序](https://www.youtube.com/watch?v=m879N2rzn2g)，作者：Baron Schwartz -* [男爵 Schwartz：2014 年及以后的 MySQL，SQL，NoSQL 和开源](https://www.youtube.com/watch?v=f1hSvfDIfbo) -* [MySQL 中的时间序列数据](https://www.youtube.com/watch?v=kTD1NuQXr4k) by Baron Schwartz -* [转到数据库/ SQL 教程](http://go-database-sql.org/) -* [VividCortex / dbcontrol](https://github.com/VividCortex/dbcontrol) -Go 的数据库/ sql 程序包的包装，提供了连接池限制 +你好 -HighScalability 很幸运能够担任该职位-Baron 的文章中总结了很多经验。 :) +我想知道 postgres 是否不适用于可扩展性高的网站。 -不能再同意兰德尔了。 男爵是个地狱的家伙。 +谢谢 -运气还不止于此。 如此之多的人选择在 HighScalability 上共享如此高质量的内容，这让我感激不已。 +tan -很棒的文章，内容丰富！ -我有一个问题。 -对于此类数据，TokuDB 似乎是一个很好的解决方案。 是否有不使用它的特定原因，或者只是不考虑使用它？ \ No newline at end of file +有趣的是有人从 python 转向 php。 \ No newline at end of file diff --git a/docs/83.md b/docs/83.md index 8bcebd4..27b49cf 100644 --- a/docs/83.md +++ b/docs/83.md @@ -1,137 +1,72 @@ -# Swiftype 如何以及为何从 EC2 迁移到真实硬件 +# 数据范围项目-6PB 存储，500GBytes / sec 顺序 IO，20M IOPS，130TFlops -> 原文： [http://highscalability.com/blog/2015/3/16/how-and-why-swiftype-moved-from-ec2-to-real-hardware.html](http://highscalability.com/blog/2015/3/16/how-and-why-swiftype-moved-from-ec2-to-real-hardware.html) +> 原文： [http://highscalability.com/blog/2012/2/2/the-data-scope-project-6pb-storage-500gbytessec-sequential-i.html](http://highscalability.com/blog/2012/2/2/the-data-scope-project-6pb-storage-500gbytessec-sequential-i.html) -![](img/bd13f7a734bb8c2326b8a527a50cfa1f.png) +![](img/142377d6ed7c155435afaec71c9789ac.png) -*这是 [Oleksiy Kovyrin](https://twitter.com/kovyrin) 的来宾帖子， [Swiftype](https://swiftype.com/) 。 Swiftype 目前为超过 100,000 个网站提供搜索功能，每月提供超过 10 亿个查询。* +“ **数据无处不在，永远不在单个位置。 无法扩展，无法维护。** ， –Alex Szalay -当 Matt 和 Quin 在 2012 年创立 Swiftype 时，他们选择使用 Amazon Web Services 建立公司的基础架构。 云似乎是最合适的选择，因为它很容易在不管理硬件的情况下添加新服务器，并且没有前期成本。 +尽管伽利略在望远镜揭示的奥秘上进行了生死教义的比赛，但又没有引起另一场革命，显微镜在奥秘之后放弃了奥秘 还没有人知道它所揭示的内容具有颠覆性。 这些新的感知增强工具首次使人类能够窥见外表的面纱。 数百年来，驱动人类发明和发现的崭新视角。 -不幸的是，尽管某些服务（如 Route53 和 S3）最终对我们来说确实非常有用且非常稳定，但使用 EC2 的决定却在我们成立的第一年困扰了团队一些主要问题。 +数据是隐藏的另一种 [](http://highscalability.com/blog/2009/11/16/building-scalable-systems-using-data-as-a-composite-material.html)数据，仅当我们查看不同的比例并调查其底层时才显示自身 模式。 如果宇宙是由信息 真正构成的 [，那么我们正在研究真正的原始事物。 数据需要一个新的眼睛，一个雄心勃勃的项目称为](http://www.scientificamerican.com/article.cfm?id=is-space-digital) [数据范围](https://wiki.pha.jhu.edu/escience_wiimg/7/7f/DataScope.pdf) 旨在成为镜头。 -Swiftype 的客户需要卓越的性能和始终可用的可用性，而我们能否提供这些功能在很大程度上取决于我们基础架构的稳定性和可靠性。 在 Amazon 中，我们**遇到了网络问题，VM 实例挂起，不可预测的性能下降（可能是由于嘈杂的邻居共享我们的硬件**，但没有办法知道）以及许多其他问题。 无论我们遇到什么问题，亚马逊始终有相同的解决方案：通过购买冗余或高端服务向亚马逊支付更多钱。 +详细的 [论文](https://wiki.pha.jhu.edu/escience_wiimg/7/7f/DataScope.pdf) 进一步说明了它的含义： -我们花在解决 EC2 问题上的**时间越多，我们为客户开发新功能**的时间就越少。 我们知道可以使我们的基础架构在云中工作，但是要做的工作，时间和资源远比迁移要大得多。 +> 数据范围是一种新型的科学工具，能够“观察”来自各个科学领域的大量数据，例如天文学，流体力学和生物信息学。 系统将具有超过 6PB 的存储空间，每秒约 500GB 的聚合顺序 IO，约 20M IOPS 和约 130TFlops。 Data-Scope 不是传统的多用户计算集群，而是一种新型仪器，使人们能够使用 100TB 至 1000TB 之间的数据集进行科学研究。 如今，数据密集型科学 计算中存在真空，类似于导致 BeoWulf 集群发展的过程：基于商品组件的廉价而高效的模板，用于学术环境中的数据密集型计算。 拟议的数据范围旨在填补这一空白。 -经过一年的云斗争，**我们决定将 EC2 保留为真正的硬件**。 幸运的是，这不再意味着要购买您自己的服务器并将它们放在机架中。 托管主机提供商有助于物理硬件，虚拟实例和快速配置之间的良好平衡。 鉴于我们以前在托管服务提供商方面的经验，我们决定选择 SoftLayer。 他们出色的服务和基础架构质量，供应速度以及客户支持使其成为我们的最佳选择。 +Nicole Hemsoth 对 Data-Scope 团队负责人 Alexander Szalay 博士的访问非常方便，可以在 [计算的新时代：《 Data 博士》](http://www.datanami.com/datanami/2012-01-23/the_new_era_of_computing:_an_interview_with_dr._data.html) 。 Roberto Zicari 在 [空间物体与 Facebook 好友](http://www.odbms.org/blog/2011/04/objects-in-space-vs-friends-in-facebook/) 中也对 Szalay 博士进行了很好的采访。 -经过一个多月的辛苦工作，准备进行数据中心间迁移，我们能够以零停机时间执行迁移，并且对客户没有负面影响。 **从第一天开始，向真实硬件的迁移就极大地改善了服务的稳定性，为所有关键基础架构组件带来了巨大的（〜2 倍）性能提升，并将每月托管费用降低了约 50％**。 +本文针对其硬件选择和体系结构提供了许多非常具体的建议，因此，请阅读本文以获取更深入的信息。 许多 BigData 操作都具有 Data-Scope 正在解决的相同 IO /规模/存储/处理问题，因此非常值得一看。 以下是一些要点： -本文将解释我们如何计划和实施迁移过程，详细介绍在过渡后我们看到的性能改进，并为年轻的公司提供有关何时执行此操作的见解。 +* 高性能系统的计算能力和 I / O 能力之间的距离越来越大。 随着多核和基于 GPU 的混合系统的规模不断扩大，我们正在讨论明年的许多 Petaflops +* 该系统将传统磁盘驱动器的高 I / O 性能与少量具有高性能 GPGPU 卡和 10G 以太网互连的超高吞吐量 SSD 驱动器集成在一起。 +* 我们需要具有以比今天更大的 I / O 带宽进行读取和写入的能力，并且我们还需要能够以非常高的聚合速率处理传入和传出的数据流。 +* 通过使用直接连接的磁盘，消除了存储系统中的许多系统瓶颈，在磁盘控制器，端口和驱动器之间取得了良好的平衡。 如今，构建便宜的服务器并不难，廉价的商业 SATA 磁盘每台服务器可以流超过 5GBps。 +* GPGPU 非常适合于数据并行 SIMD 处理。 这正是许多数据密集型计算的目的。 将 GPGPU 与快速本地 I / O 并置的构建系统将使我们能够以每秒数 GB 的速度将数据流传输到 GPU 卡，从而充分利用其流处理功能。 +* 在健康的生态系统中，所有事物都是 1 / f 幂定律，[在数据库选项中]我们将看到更大的多样性。 +* 它需要一种整体方法：必须首先将数据带到仪器，然后进行分段，然后再移到同时具有足够的计算能力和足够的存储带宽（450GBps）来执行典型分析的计算节点上， （复杂）分析必须执行。 +* 人们普遍认为索引是有用的，但是对于大规模数据分析而言，我们不需要完整的 ACID，交易带来的负担多于好处。 +* 实验和仿真数据正在快速增长。 数据集的大小遵循幂定律分布，并且在这种分布的两个极端都面临着巨大的挑战。 +* 不同架构组件的性能以不同的速率提高。 + * CPU 性能每 18 个月翻一番 + * 磁盘驱动器的容量正在以类似的速度增加一倍，这比原始 Kryder 定律的预测要慢一些，这是由更高密度的磁盘驱动的。 + * 在过去十年中，磁盘的旋转速度几乎没有变化。 这种差异的结果是，虽然顺序 IO 速度随密度增加，但随机 IO 速度仅发生了适度的变化。 + * 由于磁盘的顺序 IO 和随机 IO 速度之间的差异越来越大，因此只能进行顺序磁盘访问-如果 100TB 的计算问题主要需要随机访问模式，则无法完成。 + * 即使在数据中心，网络速度也无法跟上数据大小翻倍的步伐。 +* PB 级数据，我们无法将数据移动到计算所在的位置，而必须将计算引入数据中。 +* 现有的超级计算机也不太适合进行数据密集型计算。 它们最大程度地延长了 CPU 周期，但缺少大容量存储层的 IO 带宽。 而且，大多数超级计算机缺乏足够的磁盘空间来存储多个月期间的 PB 大小的数据集。 最后，至少在今天，商业云计算平台不是答案。 与购买物理磁盘相比，数据移动和访问费用过高，它们提供的 IO 性能明显较低（〜20MBps），并且提供的磁盘空间数量严重不足（例如，每个 Azure 实例约 10GB）。 +* 硬件设计 + * 数据范围将包含 90 个性能和 12 个存储服务器 + * 数据范围设计背后的驱动目标是，在使用商品组件保持较低购置和维护成本的同时，最大化 TBsize 数据集的流处理吞吐量。 + * 直接在服务器的 PCIe 背板上执行数据的首次传递比将数据从共享的网络文件服务器提供给多个计算服务器的速度要快得多。 + * Data-Scope 的目标是提供大量廉价和快速的存储。 没有满足所有三个条件的磁盘。 为了平衡这三个要求，我们决定将仪器分为两层：性能和存储。 每一层都满足两个标准，而第三层则有所妥协。 + * Performance Server 将具有高速和廉价的 SATA 驱动器，但会影响容量。 + * 存储服务器将具有更大但更便宜的 SATA 磁盘，但吞吐量较低。 存储层的磁盘空间增加了 1.5 倍，以允许数据分段以及往返于性能层的数据复制。 + * 在性能层中，我们将确保可达到的聚合数据吞吐量保持在理论最大值附近，该最大值等于所有磁盘的聚合顺序 IO 速度。 每个磁盘都连接到一个单独的控制器端口，并且我们仅使用 8 端口控制器来避免控制器饱和。 我们将使用新的 LSI 9200 系列磁盘控制器，该控制器提供 6Gbps SATA 端口和非常高的吞吐量 + * 每个性能服务器还将具有四个高速固态磁盘，用作临时存储的中间存储层和用于随机访问模式的缓存。 + * 性能服务器将使用 SuperMicro SC846A 机箱，具有 24 个热交换磁盘托架，四个内部 SSD 和两个基于 GTX480 Fermi 的 NVIDIA 图形卡，每个图形卡具有 500 个 GPU 内核，为浮点运算提供了出色的性价比。 每张卡估计可运行 3 teraflops。 + * 在存储层中，我们将容量最大化，同时保持较低的购置成本。 为此，我们使用带有 SATA 扩展器的背板在尽可能多的磁盘中分摊主板和磁盘控制器，同时仍为每台服务器保留足够的磁盘带宽以进行有效的数据复制和恢复任务。 我们将使用本地连接的磁盘，从而使性能和成本保持合理。 所有磁盘都是可热交换的，从而使更换变得简单。 一个存储节点将由 3 个 SuperMicro SC847 机箱组成，一个包含主板和 36 个磁盘，另外两个包含 45 个磁盘，总共 126 个驱动器，总存储容量为 252TB。 +* 鉴于可移动媒体（磁盘）的改进速度快于网络，因此，sneakernet 将不可避免地成为大型临时还原的低成本解决方案， +* 我们为仪器中的数据设想了三种不同的生命周期类型。 首先是永久性数据，海量数据处理管道以及对超大型数据集的社区分析。 -## 准备交换机 +## 相关文章 -迁移之前，我们在 Amazon EC2 上有大约 40 个实例。 我们每周至少 2-3 次（有时每天）会遇到严重的生产问题（实例中断，网络问题等）。 一旦决定迁移到真正的硬件，我们就知道我们的工作已经完成，因为我们需要在不中断服务的情况下切换数据中心。 准备过程涉及两个主要步骤，每个步骤在下面的单独部分中都有专门的解释： +* [计算的新纪元：《数据博士》专访](http://www.datanami.com/datanami/2012-01-23/the_new_era_of_computing:_an_interview_with_dr._data.html) +* [MRI：数据范围的发展–科学的多 PB 通用数据分析环境](https://wiki.pha.jhu.edu/escience_wiimg/7/7f/DataScope.pdf) +* [GrayWulf：用于数据密集型计算的可伸缩群集体系结构](http://research.microsoft.com/apps/pubs/?id=79429) +* [空间中的对象与 Facebook 中的好友](http://www.odbms.org/blog/2011/04/objects-in-space-vs-friends-in-facebook/) ，作者：Roberto V. Zicari +* [极限数据密集型计算](http://salsahpc.indiana.edu/tutorial/slides/0726/szalay-bigdata-2010.pdf) +* [Alex Szalay 主页](http://www.sdss.jhu.edu/~szalay/) -1. **连接 EC2 和 SoftLayer** 。 首先，我们在 SoftLayer 的数据中心中构建了新基础架构的骨架（最小的服务器子集，能够以开发级的负载运行所有关键的生产服务）。 一旦建立了新的数据中心，我们就会在新旧数据中心之间建立一个 VPN 隧道系统，以确保两个数据中心中组件之间的透明网络连接。 +两个注意事项： -2. **对我们的应用程序**的架构更改。 接下来，我们需要对应用程序进行更改，以使它们既可以在云中也可以在我们的新基础架构上运行。 一旦应用程序可以同时存在于两个数据中心中，我们便建立了一条数据复制管道，以确保云基础架构和 SoftLayer 部署（数据库，搜索索引等）始终保持同步。 +1.由于耐用性极低，因此无法在缓存方案中使用消费者 SSD（Vertex 2）。 企业级 SSD 是这里必不可少的 +2。对于在新项目中将使用哪种类型的文件系统（分布式），请不要多说。 5PB 的存储空间，FS 上没有任何单词。 -### 步骤 1：将 EC2 和 Softlayer 连接 +很棒的文章和有趣的项目！ -为迁移做准备的第一件事之一就是弄清楚如何将 EC2 和 SoftLayer 网络连接在一起。 不幸的是，使用 EC2 的虚拟私有云（VPC）功能将一套 EC2 服务器连接到另一个专用网络的“正确”方法对我们来说不是一种选择，因为如果没有以下方法，我们无法将现有实例集转换为 VPC 停机时间。 经过一番考虑和周密的计划，我们意识到，真正需要能够跨越数据中心边界相互连接的唯一服务器是我们的 MongoDB 节点。 我们可以做的其他所有事情都可以使数据中心本地化（Redis 群集，搜索服务器，应用程序群集等）。 +请注意，“有关 Data-Scope 的详细*文件* ...”中缺少该链接，现在具有：about：blank。 -![diagram_1.png](img/db67558249d985fb5bb46058eabda8ee.png) +否则，一篇很好的文章。 -由于我们需要互连的实例数量相对较少，因此我们实施了一个非常简单的解决方案，事实证明，该解决方案对于我们的需求是稳定且有效的： - -* 每个数据中心中都部署了专用的 OpenVPN 服务器，该服务器将所有客户端流量 NAT NAT 到其专用网络地址。 - -* 每个需要能够连接到另一个数据中心的节点都将在此处建立 VPN 通道并设置本地路由，以将指向另一个 DC 的所有连接正确转发到该隧道。 - -以下功能使我们的配置非常方便： - -* 由于我们没有控制任何一方的网络基础架构，因此我们无法真正迫使任一端的所有服务器通过连接到另一个 DC 的中央路由器来集中其流量。 在我们的解决方案中，每个 VPN 服务器（在某种自动化的帮助下）决定通过隧道路由哪些流量，以确保所有客户端的完整 DC 间连接。 - -* 即使 VPN 隧道崩溃了（令人惊讶的是，这仅在项目的几周内发生了几次），这仅意味着一台服务器失去了与另一 DC 的传出连接（一个节点从 MongoDB 集群中退出，有些 工作服务器将失去与中央 Resque 框的连接，等等）。 那些一次性的连接丢失不会影响我们的基础架构，因为所有重要的基础架构组件的两端都具有冗余服务器。 - -### 步骤 2：对我们的应用程序进行架构更改 - -在准备迁移的几周内，我们必须对基础架构进行许多小的更改，但是对它的每个组成部分都有深刻的了解有助于我们做出适当的决策，从而减少了过渡期间发生灾难的可能性 。 我认为，几乎所有复杂性的基础架构都可以通过足够的时间和工程资源进行迁移，以仔细考虑在应用程序和后端服务之间建立的每个网络连接。 - -![diagram_2.png](img/a6eaf06da9cd2cef1e72de6700d336fa.png) - -以下是我们为确保平稳透明迁移所必须采取的主要步骤： - -* 所有无状态服务（缓存，应用程序集群，Web 层）均独立部署在每一侧。 - -* 对于每个有状态后端服务（数据库，搜索集群，异步队列等），我们都必须考虑是否要（或可以负担得起）将数据复制到另一端，或者是否必须引起数据中心间的延迟 对于所有连接。 一直以来，依靠 VPN 一直是最后的选择，最终我们能够将数据中心之间的流量减少到一些小的复制流（主要是 MongoDB）以及与无法复制的服务的主/主副本的连接 。 - -* 如果可以复制服务，则可以这样做，然后使应用程序服务器始终使用或偏爱该服务的本地副本，而不是转到另一端。 - -* 对于我们无法使用其内部复制功能进行复制的服务（例如我们的搜索后端），我们对应用程序进行了更改，以实现数据中心之间的复制，在此数据中心的每一侧的异步工作人员都将从各自的队列中提取数据， 总是将所有异步作业都写入两个数据中心的队列中。 - -### 步骤 3：翻转开关 - -当双方都准备好为 100％的流量提供服务时，我们通过将 DNS TTL 降低到几秒钟来确保快速的流量变化，为最终的切换做好了准备。 - -最后，我们将流量切换到新的数据中心。 将请求切换到新基础架构，对客户的影响为零。 一旦流向 EC2 的流量耗尽，我们便禁用了旧数据中心，并将所有剩余的连接从旧基础结构转发到了新基础结构。 DNS 更新需要时间，因此在截止时间之后至少一周的时间内，我们的旧服务器上会看到一些剩余流量。 - -### 明显的改进：从 EC2 迁移到实际硬件后的结果 - -**稳定性提高了**。 每周我们要避免 2-3 次严重的故障（大多数故障对于客户而言是不可见的，因为我们尽了最大的努力使系统能够应对故障，但是许多故障会唤醒某人或迫使某人放弃家庭时间） 每月 1-2 次中断，我们可以通过花费工程资源来提高系统对故障的适应性，并减少故障对我们客户可见的可用性产生影响的机会，从而更彻底地处理故障。 - -**性能提高了**。 多亏了 SoftLayer 提供的现代硬件，我们看到了所有后端服务（尤其是 IO 绑定的服务，例如数据库和搜索集群，但也有 CPU 绑定的应用程序服务器）的性能持续提高，更重要的是， 性能更可预测：没有与我们的软件活动无关的突然下降或上升。 这使我们可以开始进行实际容量规划，而不必在所有性能问题上抛出更慢的实例。 - -**成本降低**。 最后，但同样重要的是，对于一家年轻的初创公司而言，我们的基础架构每月成本下降了至少 50％，这使我们能够过度配置某些服务，从而进一步提高性能和稳定性，从而使客户受益匪浅。 - -**供应灵活性提高了，但是供应时间却增加了**。 现在，我们可以精确地指定服务器以满足其工作量（大量磁盘并不意味着我们需要功能强大的 CPU）。 但是，我们无法再通过 API 调用在几分钟内启动新服务器。 SoftLayer 通常可以在 1-2 个小时内将新服务器添加到我们的机队中。 对于某些公司来说，这是一个很大的折衷，但是对于 Swiftype 来说，这是一个很好的选择。 - -## 结论 [ - -自从改用真正的硬件以来，我们有了长足的发展-我们的数据和查询量增长了 20 倍-但我们的 API 性能比以往任何时候都要好。 确切了解服务器的性能将使我们以前所未有的方式规划增长。 - -根据我们的经验，当您需要快速启动新硬件时，云可能是个好主意，但只有在您做出巨大努力（Netflix 级）以在其中生存时，它才能很好地工作。 如果您的目标是从一开始就建立企业，而您又没有多余的工程资源可用于支付“云税”，那么使用真实的硬件可能是一个更好的主意。 - -*如果您对软件和基础架构交叉领域的工程技术充满热情，Swiftype 将聘请高级技术运营工程师。* - -[关于黑客新闻](https://news.ycombinator.com/item?id=9212467) - -[上 reddit](http://www.reddit.com/r/programming/comments/2z9xwp/how_and_why_swiftype_moved_from_ec2_to_real/) - -很棒的文章。 我只需要添加 Google 工程师的一些明智的话即可（我忘了看到它的地方，但一定是演示文稿）：不要期望在距离上同步复制数据。 编码应用程序以解决此问题是更好的方法。 您可能会失去性能，但最终不会出现数据不一致的情况 - -嗨，有趣的文章，您使用的实例类型和操作系统是什么？ 您使用的是原始 AMI 还是其他东西？ - -每当我看到公司何时离开亚马逊并经历成本下降时，我都会大笑和哭泣：)我来自波兰，但是许多国家/地区都有自己的云服务提供商，因此每个人都应该检查他们，然后再寻求更大的参与者。 我为数百个客户和平均值进行了许多计算。 波兰云与亚马逊的成本比较表明，亚马逊的价格比我选择的提供商高 7 到 20 倍。 我知道这些提供商无法扩展到 1000Gbps 或 PB 数据，但是如果人们遇到网络问题和性能下降，他们仍然使用如此糟糕的提供商真是可笑。 - -我为几天的活动做了很多设置，并且它总是像魅力一样发挥作用。 两种设置工作了几个月（一切都按计划进行），我没有遇到任何问题。 - -你们有什么特殊的原因要选择 DigitalLacean 而不是 SoftLayer。 根据 DigitalOcean 网站的性能基准，它们便宜 90％，但性能更好。 - -只是好奇。 - -有趣的帖子，Oleksiy。 我自己广泛使用 EC2 和 Softlayer，得出了不同的结论。 - -Softlayer 的后端网络并不如我所愿稳定。 我曾尝试在其中运行分布式文件系统（例如 glusterfs），但不得不放弃-网络太不可靠了。 尽管值得，但 Ceph 能够更好地应对夜晚的颠簸，但它们仍然存在。 - -上次我检查（最近几个月内）无法从 SL 获得 10G 网络。 它来自 EC2。 此外，如果您自己想要一台服务器，这是相当普遍的常识，您可以在 EC2 上配置哪些实例大小。 - -很高兴到目前为止您的客户服务经验非常好。 物理服务器的问题之一是发生故障，并且在租用服务器时，您会被这些位卡住。 打开故障单，尝试更换驱动器/任何部件，希望支持技术人员能够充分了解并进行处理，而不是尝试进行故障排除并告诉您系统是否正常。 我建议您记住短语“请升级”，并毫不犹豫地使用它。 在云环境中，您将启动一个新实例并恢复工作，让其他人处理硬件问题。 - -也就是说，与 EC2 相比，通过电话从 SL 中找到某人要容易得多。 :) - -您没有提到的一件事是，如果您想在 SL 获得合理的价格，则需要从销售代表处获取报价。 根据我的经验，这通常会大大降低系统的价格。 - -我认为最重要的是，如果您要为云构建应用程序，则需要设计一个解决方案，该解决方案在 Amazon 重新启动您所使用的系统时不会崩溃。 但是，这不是唯一的情况-实例崩溃比服务器崩溃要痛苦得多。 - -很高兴为您解决！ - -众所周知，Netflix 拥有 EC2 上所有最好的服务器。 他们引导 30,000 台计算机并运行性能测试，然后仅保留前 5％的数据并关闭所有其他实例。 但是，请注意，您的开发团队可能经验不足，无法充分利用 EC2。 Netflix 和 Reddit 在 EC2 上运行没有问题。 - -当您谈到降低成本时，你们与 SoftLayer 达成任何特别交易，合同等吗？ 还是仅通过支付公共价格表就可以从 AWS 跳到 SoftLayer？ - -由于 Softlayer 确实是 IBM 的事实，他们可能确实获得了更好的交易。 - -我认为对于 Netflix 和 reddit，他们肯定可以通过联系人访问特殊服务器。 - -我不确定为什么甚至可以与数字海洋进行比较，我们不要忘记 softlayer 托管了 whatsapp。 - -对于如此大的环境，停机率令我感到惊讶。 该基础结构是作为现代临时和自动伸缩堆栈实现的，还是传统堆栈设计？ 我已经管理了 AWS 中成千上万个节点的平台，故障率低得多。 - -没有任何基础设施是完美的。 我想知道该平台在传统环境中的长期故障率，尤其是 MTTR。 此外，在较慢的物理环境中进行创新的机会成本是多少？ - -我们在 EC2 上运行了 14K 实例。 如果仅在 40 个实例上看到 VM 挂起等问题，则不确定部署是否正确。 这种迁移对于小型环境是可行的。 除了 AWS 或自己推出自己的服务以外，没有太多其他用于大规模操作的选项 - -我希望您也杀了您的主要帐户。 :) \ No newline at end of file +帕特里克 \ No newline at end of file diff --git a/docs/84.md b/docs/84.md index 29fe732..bc384ff 100644 --- a/docs/84.md +++ b/docs/84.md @@ -1,402 +1,60 @@ -# AppLovin：通过每天处理 300 亿个请求向全球移动消费者进行营销 - -> 原文： [http://highscalability.com/blog/2015/3/9/applovin-marketing-to-mobile-consumers-worldwide-by-processi.html](http://highscalability.com/blog/2015/3/9/applovin-marketing-to-mobile-consumers-worldwide-by-processi.html) - -![](img/860869409851e105796fdbcb7d6221ce.png) - -*这是来自 [AppLovin](http://www.applovin.com/) 的工程副总裁 [Basil Shikin](https://www.linkedin.com/in/basilshikin) 的来宾帖子，内容涉及其移动营销平台的基础架构。 Uber，迪士尼，Yelp 和 Hotels.com 等主要品牌都使用 AppLovin 的移动营销平台。 每天处理 300 亿个请求，每天处理 60 TB 的数据。* - -AppLovin 的营销平台为想要通过移动设备吸引消费者的品牌提供营销自动化和分析。 该平台使品牌商可以使用实时数据信号在全球十亿移动消费者中做出有效的营销决策。 - -# 核心统计信息 - -* 每天 300 亿个广告请求 - -* 每秒 300,000 个广告请求，最高为每秒 500,000 个广告请求 - -* 5 毫秒平均响应延迟 - -* 每秒 3 百万个事件 - -* 每天处理 60TB 数据 - -* 〜1000 台服务器 - -* 9 个数据中心 - -* 〜40 个报告维度 - -* 每分钟 500,000 个指标数据点 - -* 1 Pb 火花簇 - -* 所有服务器上的峰值磁盘写入速度为 15GB / s - -* 所有服务器上的峰值磁盘读取速度为 9GB / s - -* AppLovin 成立于 2012 年，总部位于帕洛阿尔托，并在旧金山，纽约，伦敦和柏林设有办事处。 - -# 技术堆栈 - -## 第三方服务 - -* [Github](https://github.com/) 用于代码 - -* [Asana](https://asana.com/) 用于项目管理 - -* [HipChat](https://www.hipchat.com/) 用于通信 - -## 数据存储 - -* [Aerospike](http://www.aerospike.com/) 用于用户个人资料存储 - -* [Vertica](http://www.vertica.com/) ，用于汇总统计信息和实时报告 - -* 每秒聚合 350,000 行，并以每秒 34,000 行的速度写入 Vertica - -* 每秒写入 Aerospike 的峰值为 12,000 个用户个人资料 - -* 适用于广告数据的 MySQL - -* [Spark](https://spark.apache.org/) 用于离线处理和深度数据分析 - -* [Redis](http://redis.io/) 用于基本缓存 - -* [节俭](https://thrift.apache.org/) 用于所有数据存储和传输 - -* 每个数据点在 4 个数据中心中复制 - -* 每个服务至少在 2 个数据中心中复制（最多 8 个） - -* 用于长期数据存储和备份的 Amazon Web Services - -## 核心应用和服务 - -* 自定义 C / C ++ Nginx 模块，用于高性能广告投放 - -* 用于数据处理和辅助服务的 Java - -* 用于 UI 的 PHP / Javascript - -* [Jenkins](http://jenkins-ci.org/) 用于持续集成和部署 - -* Zookeeper，用于分布式锁定 - -* 具有高可用性的 HAProxy 和 IPVS - -* Java / C ++静态代码分析的覆盖范围 - -* Checkstyle 和 PMD 用于 PHP 静态代码分析 - -* DC 集中式日志服务器的系统日志 - -* 休眠，用于基于事务的服务 - -## 服务器和资源调配 - -* Ubuntu - -* 用于裸机置备的补鞋匠 - -* 用于配置服务器的厨师 - -* Berkshelf 适用于 Chef 依赖项 - -* 带有 Test Kitchen 的 Docker，用于运行基础结构测试 - -* 软件（ipvs，haproxy）和硬件负载平衡器的组合。 计划逐步摆脱传统的硬件负载平衡器。 - -# 监视堆栈 - -## 服务器监视 - -* 所有服务器的 [Icinga](https://www.icinga.org/) - -* 约 100 个自定义 Nagios 插件，用于深度服务器监视 - -* 每个服务器 550 个各种探针 - -* [石墨](http://graphite.wikidot.com/) 作为数据格式 - -* [Grafana](http://grafana.org/) 用于显示所有图形 - -* [PagerDuty](http://www.pagerduty.com/) 用于问题升级 - -* [冒烟](http://oss.oetiker.ch/smokeping/) 用于网络网格监视 - -## 应用程序监视 - -* [VividCortex](https://vividcortex.com/) 用于 MySQL 监控 - -* 每个服务上的 JSON / health 端点 - -* 跨 DC 数据库一致性监视 - -* 9 个 4K 65 英寸电视，用于显示办公室中的所有图表 - -* 统计偏差监视 - -* 欺诈性用户监视 - -* 第三方系统监视 - -* 部署记录在所有图表中 - -## 智能监控 - -* 具有反馈回路的智能警报系统：可以自省一切的系统可以学到任何东西 - -* 还会监控有关 AppLovin 的第三方统计信息 - -* 警报是跨团队的活动：开发人员，操作人员，业务，数据科学家都参与其中 - -# 体系结构概述 - -## 一般注意事项 - -* 将所有内容存储在 RAM 中 - -* 如果不合适，请将其保存到 SSD - -* L2 缓存级别优化很重要 - -* 使用正确的工具完成正确的工作 - -* 体系结构允许交换任何组件 - -* 仅当替代方案好 10 倍时才升级 - -* 如果没有合适的组件，请编写自己的组件 - -* 复制重要数据至少 3 倍 - -* 确保可以在不破坏数据的情况下重播每条消息 - -* 自动化所有内容 - -* 零拷贝消息传递 - -## 消息处理 - -* 保证消息传递的自定义消息处理系统 - -* 每封邮件进行 3 倍复制 - -* 发送消息=写入磁盘 - -* 任何服务都可能失败，但是没有数据丢失 - -* 消息调度系统将所有组件连接在一起，提供了系统的隔离和可扩展性 - -* 跨 DC 故障容忍度 - -## 广告投放 - -* Nginx 的速度非常快：可以在不到一毫秒的时间内投放广告 - -* 将所有广告投放数据保留在内存中：只读 - -* jemalloc 将速度提高了 30％ - -* 将 Aerospike 用于用户个人资料：不到 1 毫秒即可获取个人资料 - -* 将所有广告投放数据预先计算在一个盒子上，并在所有服务器上分发 - -* 洪流用于在所有服务器之间传播服务数据。 与基于 HTTP 的分发相比，使用 Torrent 导致原始服务器上的网络负载下降 83％。 - -* mmap 用于在 Nginx 进程之间共享广告投放数据 - -* XXHash 是具有低冲突率的最快的哈希函数。 计算校验和的速度比 SHA-1 快 75 倍 - -* 实际流量的 5％进入登台环境 - -* 能够一次运行 3 个 A / B 测试（三个独立测试的流量为 20％/ 20％/ 10％，对照为 50％） - -* A / B 测试结果可在常规报告中查看 - -# 数据仓库 - -* 所有数据都已复制 - -* 运行大多数报告所需的时间不到 2 秒 - -* 聚合是允许快速报告大量数据的关键 - -* 最近 48 小时的非汇总数据通常可以解决大多数问题 - -* 7 天的原始日志通常足以调试 - -* 一些报告必须预先计算 - -* 始终考虑多个数据中心：每个数据点都到达多个位置 - -* S3 中的备份用于灾难性故障 - -* 所有原始数据都存储在 Spark 集群中 - -# 小组 - -## 结构 - -* 70 名全职员工 - -* 15 个开发人员（平台，广告投放，前端，移动） - -* 4 位数据科学家 - -* 5 开发。 行动。 - -* 加利福尼亚帕洛阿尔托的工程师 - -* 加利福尼亚州旧金山市的业务 - -* 在纽约，伦敦和柏林的办事处 - -## 互动 - -* 讨论最多问题的 HipChat - -* Asana，用于基于项目的通信 - -* 所有代码均已审核 - -* 常见的组代码审核 - -* 公司季度郊游 - -* 与首席执行官定期举行市政厅会议 - -* 所有工程师（CTO 初级）都写代码 - -* 面试很难：要价实在难得 - -## 开发周期 - -* 开发人员，业务部门或数据科学团队提出了一个想法 - -* 提案已审核并计划在星期一的会议上执行。 - -* 功能是在分支中实现的； 开发环境用于基本测试 - -* 创建拉取请求 - -* 代码经过审核，并在上进行迭代 - -* 对于大型功能，组代码审核很常见 - -* 该功能已合并到母版 - -* 该功能已部署到下一个版本 - -* 该功能已在 5％的实际流量上进行了测试 - -* 已检查统计信息 - -* 如果功能成功，则将逐步量产 - -* 连续几天监控功能 - -## 避免出现问题 - -* 该系统旨在处理任何组件的故障 - -* 单个组件的故障都不会损害广告投放或数据一致性 - -* 全能监控 - -* 工程师观看并分析关键业务报告 - -* 高质量的代码至关重要 - -* 某些功能在毕业之前需要经过多次代码审查和迭代。 - -* 在以下情况下触发警报： - - * 分期统计数据与生产数据不同 - - * 关键服务出现致命错误 - - * 错误率超过阈值 - - * 检测到任何不规则活动 - -* 数据永不丢失 - -* 大多数日志行都可以轻松解析 - -* 通过设计，回滚任何更改都很容易 - -* 每次失败后：修复，确保将来不会发生相同的事情，并添加监视 - -# 获得的经验教训 - -## 产品开发 - -* 轻松交换任何组件是增长的关键 - -* 故障推动了创新解决方案 - -* 过渡环境必不可少：始终准备放松 5％ - -* A / B 测试必不可少 - -* 监视所有内容 - -* 建立智能警报系统 - -* 工程师应了解业务目标 - -* 商界人士应意识到工程学的局限性 - -* 使构建和持续集成快速。 Jenkins 在 2 台裸机服务器上运行，这些服务器具有 32 个 CPU，128G RAM 和 SSD 驱动器 - -## 基础结构 - -* 监视所有数据点至关重要 - -* 自动化很重要 - -* 每个组件在设计上均应支持 HA - -* 内核优化可将性能提高多达 25％ - -* 流程和 IRQ 平衡又使性能提高了 20％ - -* 省电功能会影响性能 - -* 尽可能使用 SSD - -* 优化时，分析所有内容。 火焰图很棒！ - -[关于黑客新闻](https://news.ycombinator.com/item?id=9171871) - -它们如何在服务器之间平衡请求的负载？ - -@une：我们结合使用了软件（ipvs，haproxy）和硬件负载平衡器。 我们计划逐步摆脱传统的硬件负载平衡器。 - -您多久发布一次新功能到生产环境？ -您能否详细描述代码审查的执行方式，是正式的还是非正式的，重点是什么。 - -嗨，罗勒，非常感谢。 - -我现在对您的“暂存”环境特别感兴趣，因为我们正在以类似的规模开展工作，并想出如何管理这种环境。 - -您能否进一步评论它的“深度”？ 即是否仅复制了您的前端/应用服务器并且“登台”仍共享生产数据库？ 还是您以某种方式拥有一个完全独立的环境，直到数据库和其他后端服务？ - -如果您在暂存中有任何有状态服务，那么如何管理诸如一致性/模式更改/仅部分可用数据之类的问题？ 如果不这样做，您将如何为这些服务进行集成测试/部署-尤其是日志摄取管道之类的事情，这似乎对您的工作至关重要？ - -谢谢！ - -@Wes -我们的发布时间表很忙。 通常每周 2-3 次。 -我们使用 [GitHub Flow](https://guides.github.com/introduction/flow/) 进行代码审查和讨论。 我们致力于以最简单的方式实现该功能。 - -@Paul Banks -我们的暂存环境很深。 我们试图确保每个生产服务都有一个临时的对等设备，可以获取 5-10％的真实数据。 - -我们确实需要共享一些状态以使登台环境变得全面。 某些棘手的问题只能用真实数据才能解决。 -由于登台环境可以运行实验代码，因此我们确保采取适当的措施，以方便分离生产和登台数据。 - -此设置还有助于我们进行监视：在大多数情况下，预期生产和登台环境的行为类似。 偏差可能表明存在潜在问题。 - -您好，能否请您简单说明一下如何处理 40 个基于维度的指标。 我们有一个类似的维度大小系统，我正在尝试使用 hbase 和 redis 在每分钟只有 200 万个指标点的情况下使用很少的服务器。 \ No newline at end of file +# 99designs 的设计-数以千万计的综合浏览量 + +> 原文： [http://highscalability.com/blog/2012/2/6/the-design-of-99designs-a-clean-tens-of-millions-pageviews-a.html](http://highscalability.com/blog/2012/2/6/the-design-of-99designs-a-clean-tens-of-millions-pageviews-a.html) + +![](img/a183daad868477437902751c2609ac97.png) [99designs](http://99designs.com/) 是基于澳大利亚墨尔本的众包设计竞赛市场。 这样的想法是，如果您有需要的设计，就可以创建比赛，而设计师可以通过竞争在预算范围内为您提供最佳设计。 + +如果您是中型商业网站，那么这是一个干净的网站示例架构，可可靠地支持许多用户并在云上提供复杂的工作流。 Lars Yencken 在 99designs 上对[基础架构中的 99designs 背后的体系结构做了很好的书面介绍。 这是他们的架构的亮点：](http://99designs.com/tech-blog/blog/2012/01/30/infrastructure-at-99designs/) + +## 统计资料 + +* 团队有 8 个开发人员，2 个开发运营人员，2 个辅助/设计师 +* 一个月成千上万的独立访客 +* 每月千万浏览量 + +## 叠放 + +* 很大程度上是基于 Amazon 的堆栈 +* 弹性负载平衡器（ELB） +* 漆 +* PHP 与 Apache / mod_php +* S3 +* 使用 Pheanstalk 绑定进行内存队列查询的 Beanstalk +* 亚马逊的 RDS（MySQL） +* 记忆快取 +* MongoDB +* 雷迪斯 +* 右秤/厨师 +* NewRelic，CloudWatch，Statsd + +## 基础设施 + +* 分层体系结构：负载平衡，加速，应用程序，异步任务，存储和瞬时数据。 +* ELB 是可靠的，并且可以处理负载平衡和终止 SSL 连接，以便在 ELB 下方对流量进行不加密。 每个域使用单独的 ELB。 +* Varnish 用于提供基于文件的长尾媒体。 +* Varnish 快速，可配置，具有 DSL，并且具有用于调试实时流量的有用命令行工具。 +* 动态和未缓存的请求是从 PHP 应用程序提供的。 +* 设计存储在 S3 上。 +* S3 延迟很差，因此在每个请求之后都会在本地缓存设计。 +* 可能需要很长时间的请求被异步排队到使用 Beanstalk 实现的内存队列中，该队列轻巧且性能良好。 +* PHP 工作者从队列中读取工作并执行所需的功能。 +* 已计划的作业在适当的时间使用 cron 排队。 +* Amazon 的 RDS 用作数据库，并使用跨多个可用性区域的主-主复制来实现冗余。 +* 滚动 RDS 备份用作灾难发现。 +* 随着负载增加，请求将在读取的从属设备之间实现负载平衡。 +* S3 存储媒体文件和数据文件。 +* 备份到 Rackspace 和 Cloudfiles 以进行灾难恢复。 +* Memcached 在每台服务器上运行，用于缓存查询。 +* MongoDB 中的上限集合用于记录错误和统计信息。 +* Redis 按用户存储有关为用户启用哪些功能的信息。 +* 每个用户配置用于深色启动，软启动和增量功能推出。 +* 亚马逊允许他们不拥有任何硬件，并保持灵活性。 +* 强调使用“软件作为基础结构”精神的自动化。 +* Rightscale 使用 Chef 管理服务器配置。 服务器是一次性的。 +* 使用 NewRelic，CloudWatch，Statsd 实施监视。 两个大的监视屏幕显示站点行为的仪表板。 + +## 得到教训 + +* **测试以按比例缩小**。 高度可变的负载意味着它们大量使用了云的按比例缩减功能，这需要大量测试才能正常工作。 +* **国际客户需要 CDN** 。 他们有很多国际客户，由于他们不在美国东部服务，因此这些客户并不总是能获得优质的体验。 他们正在寻找各种 CDN，以便为国际客户提供更好的服务。 +* **在增长过程中保持稳定性需要测试和自动化。 为了支持频繁发布，他们实施了验收测试和更多的自动化功能。 基于每个用户打开和关闭功能的能力允许针对一部分用户测试新功能。** \ No newline at end of file diff --git a/docs/85.md b/docs/85.md index b09f480..a63d449 100644 --- a/docs/85.md +++ b/docs/85.md @@ -1,251 +1,336 @@ -# 阿尔及利亚分布式搜索网络的体系结构 +# Tumblr Architecture-150 亿页面浏览量一个月，比 Twitter 更难扩展 + +> 原文： [http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) + +![](img/3f4661baa53cbc9eae481b3c2ce15bb3.png) + +Tumblr 每月拥有超过 150 亿的页面浏览量，已成为一个非常流行的博客平台。 用户可能会喜欢 Tumblr 的简单性，美观性，对用户体验的高度关注或友好而参与的社区，但他们喜欢。 + +每月以 30％以上的速度增长并非没有挑战。 其中一些可靠性问题。 它有助于认识到 Tumblr 的运行规模惊人地惊人：每天有 5 亿次页面浏览，每秒约有 4 万个请求的峰值速率，每天约有 3TB 的新数据存储，所有这些都在 1000 多个服务器上运行。 + +成功创业公司的常见模式之一是从创业公司到疯狂成功创业的危险鸿沟。 寻找人员，不断发展的基础架构，为旧的基础架构提供服务，同时处理每月逐月的巨大流量增长（全都只有四名工程师），这意味着您必须对工作内容做出艰难的选择。 这就是 Tumblr 的情况。 现在，拥有 20 名工程师，他们有足够的精力来解决问题并开发一些非常有趣的解决方案。 + +Tumblr 开始时是一种非常典型的大型 LAMP 应用程序。 他们现在的发展方向是朝着围绕 Scala，HBase，Redis，Kafka，Finagle 构建的分布式服务模型以及为仪表板提供动力的有趣的基于单元的体系结构。 现在，我们正在努力解决其 PHP 应用程序中的短期问题，将其撤出并使用服务来正确完成。 + +Tumblr 的主题是大规模过渡。 从 LAMP 堆栈过渡到有点出血的边缘堆栈。 从小型启动团队过渡到配备齐全的现成开发团队，以开发新功能和基础架构。 为了帮助我们理解 Tumblr 的生活方式，Tumblr 的分布式系统工程师，资深的初学者 [Blake Matheny](http://www.linkedin.com/in/bmatheny) 。 布雷克（Blake）对 Tumblr 之家的评价如下： + +网站： [http://www.tumblr.com/](http://www.tumblr.com/) + +## 统计信息 + +* 每天有 5 亿页面浏览量 +* 每月浏览量超过 15B +* 〜20 名工程师 +* 每秒约 40k 请求的峰值速率 +* 每天有 1 TB 以上的数据进入 Hadoop 集群 +* 每天有许多 TB 进入 MySQL / HBase / Redis / Memcache +* 以每月 30％的速度增长 +* 正在生产的〜1000 个硬件节点 +* 每个工程师每月有数十亿的页面访问 +* 帖子每天大约 50GB。 关注者列表每天更新约 2.7TB。 +* 仪表板每秒运行一百万次写入，每秒 50K 读取，并且还在不断增长。 + +## 软件 + +* OS X 用于开发，Linux（CentOS，科学版）投入生产 +* Apache +* PHP，Scala，Ruby +* Redis，HBase，MySQL +* Varnish，HA 代理，nginx， +* Memcache，Gearman，Kafka， Kestrel，Finagle +* 节俭，HTTP +* [Func](http://func.et.redhat.com/) -安全，可编写脚本的远程控制框架和 API +* Git，Capistrano，木偶，詹金斯 + +## 硬件 + +* 500 台 Web 服务器 +* 200 个数据库服务器（其中许多是我们因故障而从备用池中抽出的一部分） + * 47 个池 + * 30 个碎片 +* 30 个内存缓存服务器 +* 22 个 Redis 服务器 +* 15 个清漆服务器 +* 25 个代理节点 +* 8 nginx +* 14 个作业队列服务器（红 est + Gearman） + +## 架构 + +* Tumblr 具有与其他社交网络不同的使用模式。 + * 每天有 50+百万个帖子，平均帖子数达数百人。 拥有数百万关注者的不仅仅是一两个用户。 Tumblr 用户的图表有数百个关注者。 这与任何其他社交网络都不同，这就是使 Tumblr 如此难以扩展的原因。 + * 在用户花费的时间方面排名第二。 内容很吸引人。 它是图片和视频。 帖子没有字节大小。 它们并不都是长格式，但是它们有能力。 人们会写一些值得一读的深入内容，因此人们会呆上几个小时。 + * 用户与其他用户建立连接，因此他们将数百页返回到仪表板以读取内容。 其他社交网络只是您采样的流。 + * 的含义是，鉴于用户数量，用户的平均覆盖范围以及用户的高发布活动，需要处理大量更新。 +* Tumblr 在一个托管站点中运行。 设计在将来会考虑地理分布。 +* 以 Tumblr 为平台的两个组件：公共 [Tumblelogs](http://www.tumblr.com/tagged/tumblelogs) 和 [信息显示板](http://www.tumblr.com/tagged/tumblr+dashboard) + * 公众 Tumblelog 是公众根据博客处理的内容。 易于缓存，因为它不是那么动态。 + * 仪表板类似于 Twitter 时间线。 用户从他们关注的所有用户那里获取实时更新。 + * 与博客的缩放特性非常不同。 缓存并不是那么有用，因为每个请求都是不同的，尤其是对于活跃的关注者而言。 + * 需要实时且一致。 不应显示过时的数据。 而且有很多数据要处理。 帖子每天只有大约 50GB。 关注者列表每天更新 2.7TB。 媒体全部存储在 S3 中。 + * 大多数用户都将 Tumblr 用作消费内容的工具。 每天的 500+百万页面浏览量中，有 70％用于仪表板。 + * 仪表板的可用性非常好。 Tumblelog 表现不佳，因为它们具有难以迁移的旧式基础架构。 与一个小团队一起，他们必须选择并解决扩展问题。 + +### 旧 Tumblr + +* 当公司开始使用 Rackspace 时，它给每个自定义域博客一个 A 记录。 当他们超过 Rackspace 时，太多的用户无法迁移。 这是 2007 年。他们在 Rackspace 上仍具有自定义域。 他们使用 HAProxy 和 Varnish 将 Rackspace 路由回到其 colo 空间。 这样的遗留问题很多。 +* 传统的 LAMP 进展。 + * 历史上是用 PHP 开发的。 几乎每个工程师都使用 PHP 进行编程。 + * 从 Web 服务器，数据库服务器和 PHP 应用程序开始，然后开始发展。 + * 要扩展规模，他们开始使用内存缓存，然后放入前端缓存，然后在缓存之前放入 HAProxy，然后使用 MySQL 分片。 MySQL 分片非常有用。 + * 充分利用单个服务器的方法。 在过去的一年中，他们在 C 语言中开发了一些后端服务： [ID 生成器](http://engineering.tumblr.com/post/10996371189/blake-matheny-id-generation-at-scale) 和 [楼梯](http://engineering.tumblr.com/post/7819252942/staircar-redis-powered-notifications) ，使用 Redis 为仪表板通知供电 +* 仪表板使用分散收集方法。 当用户访问其仪表板时，将显示事件。 将拉出并显示您关注的用户的事件。 这将再扩展 6 个月。 由于数据是按时间排序的分片方案，因此效果不佳。 + +### 新 Tumblr + +* 由于招聘和开发速度原因，已更改为以 JVM 为中心的方法。 +* 目标是将所有内容从 PHP 应用程序移到服务中，并使该应用程序成为确实需要身份验证，表示等的服务的薄层。 +* Scala 和 Finagle 选择 + * 内部，他们有很多具有 Ruby 和 PHP 经验的人，因此 Scala 颇具吸引力。 + * Finagle 是选择 Scala 的重要因素。 它是 Twitter 的图书馆。 它处理大多数分布式问题，例如分布式跟踪，服务发现和服务注册。 您不必实现所有这些东西。 它只是免费提供的。 + * 在 JVM 上，Finagle 提供了所需的所有原语（Thrift，ZooKeeper 等）。 + * Foursquare 和 Twitter 正在使用 Finagle。 Meetup 也正在使用 Scala。 + * 类似于 Thrift 应用程序界面。 它具有非常好的性能。 + * 喜欢 Netty，但是想要退出 Java，因此 Scala 是一个不错的选择。 + * 之所以选择 Finagle，是因为它很酷，并且认识一些人，它不需要很多网络代码就可以工作，并且可以完成分布式系统中所需的所有工作。 + * 未选择 Node.js，因为使用 JVM 基础更容易扩展团队。 Node.js 开发不够完善，无法提供标准和最佳实践以及大量经过测试的代码。 使用 Scala，您可以使用所有 Java 代码。 关于如何以可扩展的方式使用它的知识并不多，它们的目标是 5 毫秒的响应时间，4 个 9s HA，每秒 40K 个请求，还有一些每秒 40 万个请求。 他们可以利用 Java 生态系统中的很多功能。 +* 内部服务正在从基于 C / libevent 的状态转变为基于 Scala / Finagle 的状态。 +* 正在使用更新的非关系数据存储，例如 HBase 和 Redis，但它们的大部分数据当前存储在高度分区的 MySQL 体系结构中。 不使用 HBase 替换 MySQL。 +* HBase 支持数十亿个 URL 以及所有历史数据和分析的 URL 缩写。 一直坚如磐石。 HBase 用于具有较高写入要求的情况，例如替换仪表板每秒写入一百万次。 未部署 HBase 而不是部署 MySQL，因为他们无法与他们所拥有的人押宝 HBase 上的业务，因此他们开始将其用于规模较小，不太关键的项目中以获取经验。 +* MySQL 和时间序列数据分片的问题一直是一个热点。 由于从属服务器上的插入并发性，还遇到了读取复制滞后的问题。 +* 创建了一个公共服务框架。 + * 花了很多时间来预先解决如何管理分布式系统的操作问题。 + * 建造了一种 Rails 脚手架，但用于服务。 模板用于在内部引导服务。 + * 从操作角度来看，所有服务看起来都是相同的。 检查统计信息，监视，启动和停止所有服务的工作方式相同。 + * 工具是围绕 [SBT](https://github.com/harrah/xsbt/wiki) （一种 Scala 生成工具）的构建过程使用的，它使用插件和帮助程序来处理一些常见的活动，例如在其中标记内容 git，发布到存储库等。大多数开发人员不必进入构建系统的胆量。 +* 前端层使用 HAProxy。 Varnish 可能会受到公共博客的欢迎。 40 台机器。 +* 500 个运行 Apache 的 Web 服务器及其 PHP 应用程序。 +* 200 个数据库服务器。 使用许多数据库服务器是出于高可用性的原因。 使用了商品硬件，MTBF 令人惊讶地低。 丢失的硬件比预期的要多得多，因此在发生故障的情况下有许多备用件。 +* 6 个支持 PHP 应用程序的后端服务。 一个团队致力于开发后端服务。 每 2-3 周推出一项新服务。 包括仪表板通知，仪表板二级索引，URL 缩短器和用于处理透明分片的内存缓存代理。 +* 在 [MySQL 分片](http://assets.en.oreilly.com/1/event/74/Massively%20Sharded%20MySQL%20at%20Tumblr%20Presentation.pdf) 中投入了大量时间和精力。 尽管 MongoDB 在纽约（其所在地）很受欢迎，但并未使用。 MySQL 可以很好地扩展。. +* Gearman 是一种工作队列系统，用于长时间的开火和忘却式工作。 +* 可用性是根据覆盖范围衡量的。 用户可以访问自定义域或仪表板吗？ 同样在错误率方面。 +* 历史上最高优先项是固定的。 现在，对故障模式进行了系统地分析和处理。 目的是从用户角度和应用程序角度衡量成功。 如果无法满足要求的一部分，则为 +* 最初，Actor 模型与 Finagle 一起使用，但已被删除。 为了免于失火，使用作业队列。 此外，Twitter 的 [实用程序库](http://twitter.github.com/util/util-core/target/site/doc/main/api/com/twitter/util/package.html) 包含 [期货](http://twitter.github.com/util/util-core/target/site/doc/main/api/com/twitter/util/package.html) 实现和服务 就期货而言。 在需要线程池的情况下，将期货传递到期货池中。 一切都提交给将来的池以异步执行。 +* Scala 鼓励没有共享状态。 Finagle 被认为是正确的，因为它已经在 Twitter 上进行了生产测试。 使用 Scala 或 Finagle 中的构造避免了可变状态。 不再使用长时间运行的状态机。 状态从数据库中拉出，使用，然后写回数据库。 优势在于，开发人员无需担心线程或锁。 +* 22 个 Redis 服务器。 每个服务器有 8-32 个实例，因此生产中使用了 100 个 Redis 实例。 + * 用于仪表板通知的后端存储。 + * 通知就像用户喜欢您的信息一样。 通知会显示在用户的仪表板上，以指示其他用户对其内容执行的操作。 + * 高写入率使 MySQL 不适合使用。 + * 通知是短暂的，因此删除通知不会太可怕，因此 Redis 是此功能的可接受选择。 + * 让他们有机会了解 Redis 并熟悉它的工作原理。 + * Redis 完全没有问题，社区很棒。 + * 为 Redis 创建了一个基于 Scala 期货的界面。 现在，此功能正在迁移到其单元架构中。 + * URL 缩短器使用 Redis 作为第一级缓存，使用 HBase 作为永久存储。 + * 信息中心的二级索引围绕 Redis 构建。 + * 使用由 Finagle 构建的内存缓存代理，Redis 用作 Gearman 的持久层。 + * 从 Memcache 缓慢移至 Redis。 最终希望仅依靠一种缓存服务。 性能与 Memcache 相当。 + +### 内部消防水带 + +* 内部应用程序需要访问活动流。 活动流是有关用户创建/删除帖子，喜欢/取消喜欢帖子等的信息。一个挑战是实时分发如此多的数据。 希望能够在内部进行扩展并且可以可靠地扩展应用程序生态系统。 需要一个中心分发点。 +* 以前，此信息是使用 Scribe / Hadoop 分发的。 服务将登录到 Scribe 中并开始拖尾，然后将该数据通过管道传输到应用程序中。 此模型几乎立即停止了扩展，特别是在人们每秒创建数千个帖子的高峰期。 不想让人们将文件和管道拖到 grep。 +* 创建了一个内部 firehose 作为消息总线。 服务和应用程序通过 Thrift 与 Firehose 对话。 +* LinkedIn 的 Kafka 用于存储邮件。 在内部，消费者使用 HTTP 流从 Firehose 读取数据。 未使用 MySQL 是因为分片实现经常更改，因此使用巨大的数据流来实现它不是一个好主意。 +* firehose 模型非常灵活，与假定数据丢失的 Twitter firehose 不同。 + * 消防水带可以及时退绕。 它保留一周的数据。 在连接时，可以指定开始阅读的时间点。 + * 多个客户端可以连接，并且每个客户端都不会看到重复的数据。 每个客户端都有一个客户端 ID。 卡夫卡支持一个消费者群体的想法。 消费者组中的每个消费者都有自己的消息，不会看到重复的消息。 可以使用相同的使用者 ID 创建多个客户，并且客户不会看到重复的数据。 这样就可以独立并并行地处理数据。 Kafka 使用 ZooKeeper 定期检查消费者阅读的距离。 + +### 仪表板收件箱的单元格设计 + +* 当前用于提供仪表板功能的分散收集模型的跑道非常有限。 它不会持续更长的时间。 + * 解决方案是移至使用类似于 [Facebook 消息](http://www.facebook.com/note.php?note_id=454991608919) 的基于单元的架构实现的收件箱模型。 + * 收件箱与分散收集相反。 用户的仪表板由跟随的用户的帖子和其他用户采取的操作组成，按时间顺序逻辑存储在一起。 + * 解决了分散收集问题，因为它是一个收件箱。 您只需要问收件箱中的内容，就可以节省费用，然后便宜得多。 这将扩展很长时间。 +* 很难重写仪表板。 数据具有分布式性质，但具有交易质量，用户无法部分获得更新。 + * 数据量令人难以置信。 消息必须平均发送给数百个不同的用户，这与 Facebook 面临的问题截然不同。 大日期+高分发率+多个数据中心。 + * 规格为每秒写一百万，每秒读 50K。 数据集大小为 2.7TB 的数据增长，未启用任何复制或压缩。 百万写秒是从 24 字节行键写入的，它指示收件箱中的内容。 + * 在已经流行的必须保持运行的应用程序上执行此操作。 +* 细胞 + * 单元是一个独立的安装，其中包含适用于一系列用户的所有数据。 呈现用户仪表板所需的所有数据都在单元格中。 + * 用户被映射到单元格中。 每个数据中心存在许多单元。 + * 每个单元都有一个 HBase 群集，服务群集和 Redis 缓存群集。 + * 用户被安置在一个单元中，并且所有单元都通过 firehose 更新消耗所有帖子。 + * 每个单元都基于 Finagle，并通过 Thrift 上的 firehose 和服务请求填充 HBase。 + * 用户进入仪表板，用户位于某个特定的单元格内，服务节点通过 HBase 读取其仪表板，并将数据传回。 + * 后台任务从防火墙中消耗掉，以填充表和处理请求。 + * Redis 缓存层用于单元内的帖子。 +* 请求流：用户发布帖子，该帖子被写入 firehose，所有单元格消耗该帖子并将该帖子内容写到帖子数据库中，单元格查找以查看帖子创建者是否有任何关注者 在单元格中，如果是的话，则跟随者收件箱将更新为帖子 ID。 +* 电池设计的优势： + * 大规模规模需要并行化，而并行化要求组件彼此隔离，因此没有相互作用。 单元提供一个并行化单元，可以随着用户群的增长而调整为任意大小。 + * 细胞隔离故障。 一个单元故障不会影响其他单元。 + * 单元可以实现一些不错的功能，例如测试升级，实施滚动升级以及测试软件的不同版本的能力。 +* 容易遗漏的关键思想是： 所有帖子都复制到所有单元格 。 + * 每个单元格都存储所有帖子的单个副本。 每个单元格可以完全满足仪表板渲染请求。 应用程序不要求提供所有帖子 ID，然后要求提供这些 ID 的帖子。 它可以为用户返回仪表板内容。 每个单元都具有完成仪表板请求所需的所有数据，而无需进行任何跨单元通信。 + * 使用了两个 HBase 表：一个存储每个帖子的副本。 与存储该单元内每个用户的每个帖子 ID 的另一个表相比，该数据很小。 第二张表告诉用户仪表板的外观，这意味着他们不必获取用户关注的所有用户。 这也意味着跨客户，他们将知道您是否阅读了帖子，并且在其他设备上查看帖子并不意味着您阅读了相同的内容两次。 使用收件箱模型，状态可以保持在您已阅读的内容上。 + * 帖子太大，因此无法直接放入收件箱。 因此，将 ID 放入收件箱，并将帖子内容仅放入单元格一次。 该模型大大减少了所需的存储空间，同时使返回用户收件箱的按时间顺序的视图变得简单。 缺点是每个单元格包含完整的呼叫记录副本。 令人惊讶的是，帖子比收件箱映射要小。 每天的后期增长是每个单元 50GB，收件箱每天增长 2.7TB。 用户消费超过他们生产的东西。 + * 用户的信息中心不包含帖子的文本，仅包含帖子的 ID，而大部分增长都来自 ID。 + * 随着关注者的更改，设计是安全的，因为所有帖子均已在单元格中。 如果只有关注者帖子存储在一个单元格中，那么随着关注者的更改，该单元格将过时，并且需要某种回填过程。 + * 替代设计是使用单独的帖子群集来存储帖子文本。 这种设计的缺点是，如果群集出现故障，则会影响整个站点。 使用单元设计并向所有单元复制后，将创建一个非常强大的体系结构。 +* 拥有数百万个真正活跃的关注者的用户可以通过根据其访问模型选择性地实现用户供稿来处理（请参见 [Feeding Frenzy](http://highscalability.com/blog/2012/1/17/paper-feeding-frenzy-selectively-materializing-users-event-f.html) ）。 + * 不同的用户具有适当的不同访问模型和分发模型。 两种不同的分发模式：一种用于流行用户，另一种用于其他人。 + * 数据的处理方式取决于用户类型。 来自活跃用户的帖子实际上不会发布，而帖子将有选择地实现。 + * 关注数百万用户的用户与拥有数百万关注者的用户类似。 +* 单元大小难以确定。 单元的大小是故障的影响点。 影响到一个单元的用户数量。 要权衡他们愿意接受的用户体验以及相应的费用。 +* 从 firehose 读取是最大的网络问题。 在一个小区内，网络流量是可管理的。 +* 随着添加更多的细胞，可以将细胞放入一个从火喉读取的细胞组中，然后复制到该组中的所有细胞中。 分层复制方案。 这也将有助于转移到多个数据中心。 + +### 关于在纽约创业 + +* NY 是一个不同的环境。 很多财务和广告。 招聘具有挑战性，因为没有太多的启动经验。 +* 在过去的几年中，NY 致力于帮助初创企业。 纽约大学和哥伦比亚大学推出的计划旨在使学生在初创企业中获得有趣的实习机会，而不仅仅是去华尔街。 彭博市长正在建立一个专注于技术的本地校园。 + +### 团队结构 + +* 团队：基础架构，平台，SRE，产品，网络运营，服务。 +* 基础结构：第 5 层及以下。 IP 地址及以下，DNS，硬件配置。 +* 平台：核心应用程序开发，SQL 分片，服务，Web 操作。 +* SRE：位于服务团队和网络运营团队之间。 在可靠性和可伸缩性方面专注于更迫切的需求。 +* 服务团队：专注于更具战略意义的工作（一个月或两个月）。 +* Web 操作：负责问题检测和响应以及调整。 + +### 软件部署 + +* 从一组 rsync 脚本开始，这些脚本将 PHP 应用程序分布在各处。 一旦计算机数量达到 200，系统就开始出现问题，部署需要很长时间才能完成，并且计算机将处于部署过程的各种状态。 +* 下一阶段使用 Capistrano 将部署过程（开发，登台，生产）构建到其服务堆栈中。 可以在数十台计算机上使用服务，但是通过 SSH 连接后，在部署到数百台计算机上时再次开始出现故障。 +* 现在，所有计算机上都运行一个协调软件。 基于 RedHat 的 Func，这是一种用于向主机发出命令的轻量级 API。 缩放内置于 Func 中。 +* 通过在一组主机上执行 X 来在 Func 上进行构建部署，这避免了 SSH。 假设您要在组 A 上部署软件。主服务器伸向一组节点并运行 deploy 命令。 +* deploy 命令通过 Capistrano 实现。 它可以进行 git checkout 或从存储库中提取。 易于扩展，因为他们正在使用 HTTP。 他们喜欢 Capistrano，因为 Capistrano 支持基于简单目录的版本控制，该版本与他们的 PHP 应用程序很好地兼容。 向版本更新迈进，每个目录包含一个 [SHA](http://book.git-scm.com/1_the_git_object_model.html) ，因此可以轻松检查版本是否正确。 +* Func API 用于报告状态，即这些机器具有这些软件版本。 +* 可以安全地重新启动其所有服务，因为它们会清空连接，然后重新启动。 +* 激活之前，所有功能均在暗模式下运行。 + +### 开发 + +* 从这样的哲学开始：任何人都可以使用他们想要的任何工具，但是随着团队的成长，这种想法不起作用了。 新员工的入职非常困难，因此他们已经在堆栈上进行了标准化，以便他们能与之相处，快速发展团队，更快地解决生产问题并围绕他们开展业务。 +* 流程大致类似于 Scrum。 轻巧。 +* 每个开发人员都有一个预先配置的开发计算机。 它通过 Puppet 获取更新。 +* 开发人员机器可以滚动更改，进行测试，然后将其部署到阶段，然后将其部署到生产中。 +* 开发人员使用 vim 和 Textmate。 +* 测试是通过 PHP 应用程序的代码审查进行的。 +* 在服务方面，他们已经实现了具有提交挂钩，Jenkins 以及持续集成和构建通知的测试基础架构。 -> 原文： [http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html) +### 招聘流程 -![](img/0acb25cc63067792b06b2ee28cf1b8a7.png) +* 面试通常避免数学，困惑和脑筋急转弯。 试着针对候选人实际要做的工作提出问题。 他们聪明吗？ 他们会把事情做好吗？ 但是衡量“完成工作”的难度很难评估。 目标是找到优秀的人才，而不是将人才拒之门外。 +* 专注于编码。 他们会要求提供示例代码。 在电话采访中，他们将使用 Collabedit 编写共享代码。 +* 面试不是对抗性的，他们只是想找到最好的人。 面试期间，候选人可以使用他们的所有工具，例如 Google。 他们的想法是，开发人员在拥有工具时才能发挥最大作用，这就是他们进行采访的方式。 +* 挑战是找到在 Tumblr 的流量水平下具有所需扩展经验的人员。 世界上很少有公司致力于解决他们所面临的问题。 + * 例如，对于一个新的 ID 生成器，他们需要一个 JVM 进程以小于 1ms 的速率生成服务响应，速率为每秒 10K 请求和 500 MB RAM 限制并具有高可用性。 他们发现串行收集器在此特定工作负载下的延迟最小。 在 JVM 调整上花费了很多时间。 +* 在 Tumblr 工程博客上，他们张贴了悼念词，表达对 [Dennis Ritchie](http://engineering.tumblr.com/post/11381547149/derekg-rip-dennis-ritchie-he-gave-us-such) & [[ John McCarthy](http://engineering.tumblr.com/post/11893095969/john-mccarthy-widely-considered-the-father-of) 。 这是一种怪异的文化。 -*[Julien Lemoine](https://www.linkedin.com/in/julienlemoine) 的共同发布者的 CTO [阿尔及利亚 ]](http://www.algolia.com/) ，开发人员友好的搜索即服务 API。* +## 获得的经验教训 -Algolia 于 2012 年作为移动设备的离线搜索引擎 SDK 开始。 目前，我们还不知道在两年内我们将建立一个全球分布式搜索网络。 +* 到处都是自动化。 +* MySQL（加上分片）可扩展，而应用则不能。 +* Redis 很棒。 +* Scala 应用程序表现出色。 +* 当您不确定项目是否可行时，请报废项目。 +* 请勿通过无用的技术手腕来依靠他们的生存来雇用人员。 雇用他们是因为他们适合您的团队并且可以胜任。 +* 选择一个可以帮助您招聘所需人员的堆栈。 +* 建立团队的能力。 +* 阅读论文和博客文章。 像电池体系结构和选择性实现这样的关键设计思想都来自其他地方。 +* 询问您的同龄人。 他们与来自 Facebook，Twitter，LinkedIn 的工程师进行了交流，并交流了经验。 您可能没有权限访问此级别，但可以与某人联系。 +* 韦德，不要涉足技术领域。 他们在尝试将 HBase 和 Redis 投入生产之前，通过在试点项目或损害程度可能有限的角色中使用它们来学习。 -如今，阿尔戈利亚每月在全球 12 个地区提供超过 20 亿个用户生成的查询，我们的平均服务器响应时间为 6.7 毫秒，其中 90％的查询在不到 15 毫秒内得到答复。 我们的搜索不可用率低于 10 -6 ，这表示每月少于 3 秒。 +非常感谢 Blake 的采访。 他对时间很宽容，对解释也很耐心。 如果您想谈谈您的架构配置文件，请 [与我联系](http://highscalability.com/contact/) 。 -离线移动 SDK 面临的挑战是移动性质带来的技术限制。 这些挑战迫使我们在开发算法时会采取不同的思路，因为经典的服务器端方法无法正常工作。 +## 相关文章 -从那时起，我们的产品有了很大的发展。 我们想分享我们在这些算法之上构建和扩展 REST API 的经验。 +* [Tumblr Engineering Blog](http://engineering.tumblr.com/) -包含很多优秀文章 +* [与 Nathan Hamblen 一起使用 Finagle 和 Ostrich 构建网络服务](http://vimeo.com/29763331) -Finagle 很棒 +* [鸵鸟](https://github.com/twitter/ostrich/) -Scala 服务器的统计收集器&报告程序 +* [规模为](http://tumblr.mobocracy.net/post/10984130543/id-generation-at-scale) 的 ID 生成，作者 Blake Matheny +* [Finagle](http://twitter.github.com/finagle/) -JVM 的网络堆栈，可用于构建 Java，Scala 或任何 JVM 托管语言的异步远程过程调用（RPC）客户端和服务器 。 Finagle 提供了一组丰富的独立于协议的工具。 +* [来自 Tumblr 的 Finagle Redis 客户端](https://github.com/twitter/finagle/commit/c30ba58acfc19b96807f72162dcdd913365e2de2) +* [Tumblr。 Evan Elias 撰写的大量分片的 MySQL](http://assets.en.oreilly.com/1/event/74/Massively%20Sharded%20MySQL%20at%20Tumblr%20Presentation.pdf) -关于 MySQL 分片的更好的演示之一 +* [Staircar：由 Redis 驱动的通知](http://engineering.tumblr.com/post/7819252942/staircar-redis-powered-notifications) ，作者：布莱克·马森尼（Blake Matheny） +* [Flickr 架构](http://highscalability.com/flickr-architecture)-谈论 Flickr 的单元架构 -**我们将说明我们如何使用分布式共识来实现全球不同地区的数据的高可用性和同步，以及如何通过任意播 DNS** 将查询路由到最近的位置 。 +是否有关于此基于单元的体系结构的更多信息？ 这些关键字对于 Google 来说是非常通用的... -# 数据大小误解 +如果您还要存储数百万个非法 mp3，也很难扩展。 +查看 ex.fm API 关于 Tumblr 作为侵犯版权的避风港所暴露的内容。 在音乐方面，它们比 megaupload 更糟糕 -在设计架构之前，我们首先必须确定我们需要支持的主要用例。 在考虑我们的扩展需求时尤其如此。 我们必须知道我们的客户是否需要索引千兆字节，太字节或 PB 的数据。 架构会有所不同，具体取决于我们需要处理多少个用例。 +我不知道该体系结构是否有一个标准术语 Andrew。 Salesforce 做类似的事情，例如使用术语 Pod。 Flickr 称之为联合方法。 -当人们想到搜索时，大多数人会想到非常大的用例，例如 Google 的网页索引或 Facebook 的数万亿帖子索引。 如果停下来想一想每天看到的搜索框，则大多数搜索框都不会搜索大型数据集。 **Netflix 搜索约 10,000 种图书，亚马逊在美国的数据库包含约 200,000,000 种产品。 这两种情况下的数据都可以存储在单台机器** **中！** 我们并不是说拥有一台计算机是一个很好的设置，但是要记住所有数据都可以在一台计算机上存储是非常重要的，因为跨计算机同步是复杂性和性能损失的主要来源。 +似乎大多数服务器都包含： -# 高可用性之路 +500 台运行 Apache 及其 PHP 应用程序的 Web 服务器。 -构建 SaaS API 时，高可用性是一个大问题，因为消除所有单点故障（SPOF）极具挑战性。 我们花了数周的时间为我们的服务集体讨论理想的搜索架构，同时牢记我们的产品将面向面向用户的搜索。 +使用 Nginx / PHP-FPM 代替 Apache / mod_php 是否有意义，因为事实证明，这可以显着提高并发请求和服务整个页面的时间？ -## 主从与主从 +您为什么选择 CentOS / Scientific 而不是 RHEL？ -通过将问题暂时限制为存储在单个计算机上的每个索引，我们将高可用性设置简化为托管在不同数据中心的多台计算机。 通过这种设置，我们想到的第一个解决方案是进行主从设置，其中一台主机接收所有索引操作，然后将它们复制到一个或多个从机。 使用这种方法，我们可以轻松地在所有计算机之间负载均衡搜索查询。 +> 最初，Finagle 使用了 Actor 模型，但该模型已被删除。 -这种主从方法的问题在于我们的高可用性仅适用于搜索查询。 所有索引操作都需要转到主服务器。 对于服务公司来说，这种架构风险太大。 要做的只是使主服务器停机，这将发生，并且客户端将开始出现索引错误。 +Anywhere I can read up on the issues they had with this approach? -**我们必须实现主-主架构** **！** 启用主-主设置的关键要素是要在一组机器之间就单个结果达成一致。 我们需要在所有机器之间共享**知识，这些知识在所有情况下**都保持一致，即使机器之间存在网络分离。 +@meh：RHES 会带来什么好处？ 这将是相当标准的安装映像/配置。 任何操作系统问题，重新安装都很简单（为什么要进行故障排除，当您可以使用 PXE + config 管理在< 10m 中重新创建时）。 如此规模的 RHES 似乎是一笔不菲的巨额支出。 -## 引入分布式一致性 +关于 tumblr 内部技术的真棒读物。 感谢您发布文章，这一点非常有用。 -对于搜索引擎，引入此共享知识的最佳方法之一是**将写入操作视为必须按特定顺序应用的唯一操作流**。 当我们有多个操作恰好同时出现时，我们需要为其分配一个序列 ID。 然后，可以使用该 ID 来确保将序列完全相同地应用于所有副本。 +虚拟化呢？ 他们仅使用硬件服务器吗？ -为了分配序列 ID（每个作业后一个数字递增 1），我们需要在机器之间的下一个序列 ID 上具有共享的全局状态。 [ZooKeeper](http://zookeeper.apache.org/) 开源软件是针对集群中分布式知识的实际解决方案，我们最初开始按以下顺序使用 ZooKeeper： +管理所有这些的成本必须是巨大的。 该公司得到了风险投资公司的支持，但我想知道他们为保持运营状况每年亏损多少钱？ -1. 当机器收到作业时，它将使用临时名称将作业复制到所有副本。 +> 是否有关于此基于单元的体系结构的更多信息？ 这些关键字对于 Google 来说是非常通用的... -2. 然后，该机器将获得分布式锁。 +还可以在该网站上查看 Evernote 上的文章； 它们具有类似的“单元”架构。 -3. 读取 ZooKeeper 中的最后一个序列 ID，并发送命令以在所有机器上将临时文件复制为序列 ID + 1。 这等效于两阶段提交。 +马特，感谢您提供有关 Evernote 的提示。 我看了一下这篇文章：http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150million-reques.html，假设它是您本人 在想什么？ -4. 如果我们从计算机（定额）中获得大多数肯定答案，则将序列 ID +1 保存在 Zookeeper 中。 +我真的希望有人可以链接到受访者提到的实际论文。 -5. 然后释放分布式锁。 +关于可伸缩性的噪音太多了，即使在这个级别上，也确实没有那么困难。 -6. 最后，将结果通知发送作业的客户端。 如果有大多数提交，这将是成功的。 +本文所显示的所有内容是，您可以拥有一个真正糟糕的体系结构，并且仍然维持相当大的流量。 -不幸的是，此顺序不正确，因为如果获取锁的机器在步骤 3 和 4 之间崩溃或重新启动，我们可能会以作业在某些机器上提交的状态结束，这需要更复杂的顺序。 +这篇文章说 -ZooKeeper 通过 TCP 连接作为外部服务打包非常困难，并且需要使用较大的超时（默认超时设置为 4 秒，表示两个滴答声，每个滴答声为 2 秒）。 +> MySQL（加上分片）可扩展，而应用则不能。 -因此，无论是硬件还是软件，每个失败事件都将在此超时时间内冻结整个系统。 这似乎是可以接受的，但在我们的案例中，我们想经常在生产中测试故障（例如 Netflix 的 Monkey 测试方法）。 +在多个地方，但是 MySQL 没有分片。 这不是 MySQL 的功能，永远不会。 -## 木筏共识算法 +应用程序在将数据发送到 MySQL 之前先对其进行分区。 这要求应用程序（或应用程序层）完全了解分区并进行管理。 这样，您现在已经删除了 RDBMS 的大多数核心功能（联接，事务，外键完整性）。 这就引出了一个问题，当我们在追求扩展到所需容量的过程中，已经中止了 SQL 的所有基本功能时，为什么要全部使用 SQL。 -大约在我们遇到这些问题的时候， [RAFT 共识算法](https://raftconsensus.github.io/) 已发布。 显然，该算法非常适合我们的用例。 RAFT 的状态机是我们的索引，日志是要执行的索引作业的列表。 我已经知道 PAXOS 协议，但是对它以及所有变体的理解不够深刻，不足以使我自己有信心实施它。 另一方面，RAFT 更清晰。 如果可以完美地满足我们的需求，即使当时没有稳定的开源实现，我也有足够的信心将其实现为我们架构的基础。 +是的，可以使用 MySQL 技术来执行此操作，但是最终您不再像 RDMBS 那样使用它。 它具有您无法使用的所有功能，现在严重依赖于应用程序。 似乎仅仅使用为这种操作而设计的数据库并从头开始扩展会更聪明。 -实现共识算法最困难的部分是确保系统中没有错误。 为了解决这个问题，我选择了一种猴子测试方法，即在重新启动之前使用睡眠方式随机杀死进程。 为了进一步测试，我模拟了通过防火墙的网络掉线和性能下降。 这种测试有助于我们发现许多错误。 一旦我们运行了几天，没有任何问题，我非常有信心实施正确。 +@本·乌雷茨基 -## 在应用程序或文件系统级别复制吗？ +使用 nginx / php-cgi 的性能更高，但是您必须注意： +-您的脚本必须绝对无锁且响应迅速。 一个“较长的”执行时间脚本（但< 1s）可能会阻止一个 CGI 进程，这对于整个服务器来说应该是不完整的。 +-您需要找到一个“完美”的 php 版本，因为一个进程将执行的请求比使用 apache 重新发出的请求要多。 对于某些版本，您可能会感到有些意外。 -我们选择将写操作分配给所有计算机并在本地执行，而不是在文件系统上复制最终结果。 我们做出此选择的原因有两个： +根据我自己的经验，在（nginx）/ fastcgi 上具有良好的可靠性需要花费更多时间。 -* 更快。 索引在所有计算机上并行完成，比复制可能很大的二进制文件要快 +架构...对...根本不起作用的功能呢，例如...搜索！ 还是不存在...像在主题开发人员的情况下清理上传的资源？ -* 它与多个区域兼容。 如果我们在建立索引后复制文件，则需要一个将重写整个索引的过程。 这意味着我们可能要传输大量数据。 如果您需要将数据传输到世界各地（例如纽约到新加坡），则传输的数据量非常低。 +附言 不要误会我的意思-我喜欢 Tumblr 的简单性，但有些事情确实会踩到您的脚趾... -每台机器将以正确的顺序接收所有写操作作业，并独立于其他机器尽快处理它们。 **这意味着确保所有机器处于相同状态，但不必同时处于同一状态** 。 这是因为更改可能不会在同一时间在所有计算机上提交。 +令人印象深刻的是，只有 15 位以上的网页浏览工程师才 20 名。 令人印象深刻。 -## 一致性的妥协 +根据文章 HBASE 的使用： +支持 URL 缩短， +存储历史数据和分析 +仪表板替换 +我希望这意味着，所有博客 URL，博客数据都存储在 HBASE 中。 如果我错了，请纠正我。 -在分布式计算中， [CAP 定理](http://en.wikipedia.org/wiki/CAP_theorem) 指出，分布式计算系统不可能同时提供以下三个功能： +文章还说， +大量数据存储在 MySQL 中。 -* 一致性：所有节点同时看到相同的数据。 +那么 MySQL 是否用于存储在引入 HBASE 之前创建的旧博客？ 如果是这样，服务节点是否将决定在何处加载仪表板？ +如果有人清楚，请解释。 -* 可用性：确保每个请求都收到有关成功还是失败的响应。 +当整个小区停止服务时会发生什么？ 该单元中的用户是否已重新归宿？ 由于所有这些信息都存储在故障节点中，这将如何影响那些用户的收件箱？ -* 分区容限：尽管任意消息丢失或系统部分出现故障，系统仍可继续运行。 +“内部服务正在从基于 C / libevent 的方式转变为基于 Scala / Finagle 的方式” -根据该定理，我们在一致性 上折衷了 **。 我们不保证所有节点都能在同一时间看到完全相同的数据，但是它们都将收到更新。 换句话说，在少数情况下，机器不同步。 实际上，这不是问题，因为当客户执行写操作时，我们将该作业应用于所有主机。** **在第一台机器和最后一台机器上的应用时间之间相距不到一秒钟，因此最终用户通常看不到它。 唯一可能的矛盾是上一次收到的更新是否已经应用，这与我们客户的用例兼容。** +您能描述使用 Scala / Finagle 而不是 C / libevent 的原因吗？ +谢谢！ -# 通用体系结构 +将这样的系统以及支持该系统的业务基础结构整合在一起需要做很多工作。 可能需要花费大量时间进行阅读和编码。 我说，恭喜 Tumblr 和 CEO Karp。 继续做您所做的伟大工作。 :) -## 集群的定义 +本文提到了 Nginx，但没有说明如何使用它。 Varnish 用于缓存，HAProxy 用于 LB，Nginx 呢？ -为了拥有高可用性基础结构，必须在机器之间拥有分布式共识，但是遗憾的是存在很大的缺陷。 **此共识需要机器** **之间进行多次往返，因此每秒可能达成共识的数量与不同机器**之间的延迟直接相关。 他们需要接近才能每秒获得大量共识。 为了能够支持多个区域而不牺牲可能的写入操作的数量，这意味着我们需要有多个集群，每个集群将包含三台充当完美副本的机器。 - -每个区域只有一个集群是达成共识所需的最低要求，但仍远非完美： - -* 我们无法使所有客户都适合一台机器。 - -* 我们拥有的客户越多，每个唯一客户每秒可以执行的写操作数量就越少。 这是因为每秒的最大共识数是固定的。 - -为了解决此问题，我们决定在区域级别应用相同的概念： **每个区域将具有由三个计算机组成的几个群集** 。 一个集群可以容纳一个到几个客户，具体取决于他们拥有的数据大小。 这个概念与虚拟化在物理机上所做的事情很接近。 我们能够将几个客户放在一个集群上，但一个客户可以动态增长并更改其使用情况。 为此，我们需要开发和自动化以下过程： - -* 如果群集中的数据太多或写入操作数量过多，则将其迁移到另一群集。 - -* 如果查询量太大，则将新计算机添加到群集。 - -* 如果数据量太大，则更改分片的数量或将一个客户分散在多个群集中。 - -如果我们拥有这些流程，则不会将客户永久分配给集群。 分配将根据其自身的使用以及集群的使用而变化。 这意味着我们需要一种将客户分配给集群的方法。 - -## 将客户分配给集群 - -管理此分配的标准方法是每个客户拥有一个唯一的 DNS 条目。 这类似于 Amazon Cloudfront 的工作方式。 每个客户都被分配一个格式为 customerID.cloudfront.net 的唯一 DNS 条目，然后可以根据该客户针对不同的计算机集。 - -我们选择了相同的方法。 **为每个客户分配一个唯一的应用程序 ID，该 ID 链接到格式为 APPID.algolia.io 的 DNS 记录**。 该 DNS 记录以特定群集为目标，该群集中的所有计算机都是 DNS 记录的一部分，因此可以通过 DNS 进行负载平衡。 我们还使用运行状况检查机制来检测计算机故障，并将其从 DNS 解析中删除。 - -即使 DNS 记录上的 TTL 值非常低（TTL 是允许客户端保留 DNS 答复的时间），运行状况检查机制仍不足以提供良好的 SLA。 问题在于主机可能会关闭，但用户仍将主机保留在缓存中。 用户将继续向其发送查询，直到缓存过期。 更糟糕的是，因为 TTL 并不是一门精确的科学。 在某些情况下，系统不遵守 TTL。 我们已经看到一些 DNS 服务器将一分钟 TTL 转换为 30 分钟 TTL 的 DNS 记录。 - -为了进一步提高高可用性并避免机器故障影响用户，我们为每个客户生成了另一组 DNS 记录，格式为 APPID-1.algolia.io，APPID-2.algolia.io 和 APPID- 3.algolia.io。 这些 DNS 记录的思想是允许我们的 API 客户端在达到 TCP 连接超时（通常设置为一秒）时重试其他记录。 我们的标准实现是对 DNS 记录列表进行混洗，并按顺序尝试它们。 - -与我们的 API 客户端中精心控制的重试和超时逻辑相结合，这被证明是比使用专门的负载平衡器更好，更便宜的解决方案。 - -后来，我们发现时髦的.IO TLD 并不是性能的理想选择。 与.NET 相比，.IO 的任意播网络中的 DNS 服务器更少，并且那里的服务器已经饱和。 这导致大量超时，从而减慢了名称解析的速度。 此后，我们通过切换到 algolia.net 域解决了这些性能问题，同时通过继续支持 algolia.io 来保持向后兼容性。 - -# 集群的可伸缩性如何？ - -我们选择使用多个集群使我们能够添加更多客户，而不会因为集群之间的隔离而对现有客户造成太大的风险。 但是我们仍然担心需要解决的一个集群的可伸缩性。 - -群集可伸缩性中的第一个限制因素是由于共识而导致的每秒写入操作数。 为了缓解这一因素，我们从共识的角度出发，在 API 中引入了批处理方法，该方法将一组写操作封装在一个操作中。 问题在于，某些客户仍然不分批地执行写操作，这可能会对群集的其他客户的索引速度产生负面影响。 - -为了减少对性能的影响，我们对体系结构进行了两项更改： - -* 我们从共识的角度出发，通过在一个唯一的操作中自动聚合每个客户的所有写操作，从而在共识存在争议时添加了批处理策略。 在实践中，这意味着我们正在重新排列作业的顺序，但不影响操作的语义。 例如，如果有 1,000 个待达成共识的作业，而 990 个来自一个客户，则即使有其他客户的作业交错在一起，我们也会将 990 个写入操作合并为一个。 - -* 我们添加了一个共识调度程序，该调度程序控制每秒为每个应用程序 ID 输入共识的写入操作数。 这避免了一个客户能够使用共识的所有带宽。 - -在实施这些改进之前，**我们通过返回 429 HTTP 状态代码**尝试了限速策略。 很快就很明显，这对于我们的客户来说太痛苦了，以至于不得不等待这种响应并实施重试策略。 如今，我们最大的客户每天在三台计算机的单个群集上执行超过 10 亿次写操作，平均每秒执行 11,500 次操作，突发次数超过 15 万次。 - -第二个问题是找到最佳的硬件设置，并避免可能影响群集可伸缩性的任何潜在瓶颈（例如 CPU 或 I / O）。 从一开始，我们就选择使用自己的裸机服务器，以完全控制我们的服务性能并避免浪费任何资源。 选择正确的硬件被证明是一项艰巨的任务。 - -在 2012 年底，我们从一个小型设置开始，包括：Intel Xeon E3 1245v2、2 个 Intel RAID 320 系列，RAID 0 中的 120GB 和 32GB RAM。 该硬件价格合理，比云平台更强大，使我们能够在欧洲和美国东部启动该服务。 - -此设置使我们能够调整内核的 I / O 调度和虚拟内存，这对于我们利用所有可用的物理资源至关重要。 即使这样，我们很快发现我们的限制是 RAM 和 I / O 的数量。 我们使用了大约 10GB 的 RAM 来建立索引，而仅剩下 20GB 的 RAM 用于缓存用于执行搜索查询的文件。 我们的目标一直是在内存中存储客户索引，以便针对毫秒级的响应时间优化服务。 当前的硬件设置是为 20GB 的索引数据而设计的，该数据太小了。 - -首次设置后，我们尝试了具有单插槽和双插槽 CPU，128GB 和 256GB RAM 以及不同型号/大小的 SSD 的不同硬件机器。 - -我们终于找到了一台包含 Intel Xeon E5 1650v2、128GB RAM 和 2x400GB Intel S3700 SSD 的机器的最佳设置。 SSD 的型号对于耐用性非常重要。 在找到可以在生产中使用多年的正确型号之前，我们烧掉了许多 SSD。 - -最后，我们构建的最终体系结构使我们仅需一个条件即可在所有领域进行良好的扩展：我们需要随时拥有免费资源。 在 2015 年，要处理必须管理裸机服务器的痛苦似乎有些疯狂，但是我们在为客户提供的服务质量和价格方面所获得的收益是值得的。 我们能够提供一个完全打包的搜索引擎，该引擎可以复制到三个不同的位置（在内存索引中），并且在比 AWS 更高的位置上具有出色的性能！ - -# 操作复杂吗？ - -## 限制进程数 - -**每台机器仅包含三个进程** 。 第一个是 Nginx 服务器，其中所有查询解释代码均作为模块嵌入其中。 为了回答查询，我们在内存中映射了索引文件并直接在 nginx worker 中执行查询，而无需与其他进程或机器进行通信。 唯一的例外是，当客户数据不适合一台机器时，这种情况很少发生。 - -第二个过程是 Redis 键/值存储，我们使用它来检查速率和限制以及存储每个应用程序 ID 的实时日志和计数器。 这些计数器用于构建我们的实时信息中心，当您连接到帐户时可以查看。 这对于可视化您的最后一个 API 调用和调试很有用。 - -最后一个过程是构建器。 这是负责处理所有写入操作的过程。 当 nginx 进程接收到写操作时，它将操作转发给构建器以执行共识。 它还负责构建索引，并包含许多监视代码，用于检查我们的服务中的错误，例如崩溃，索引编制缓慢，索引编制错误等。根据问题的严重性，SMS 通过 Twilio 的 API 报告某些错误 而其他则直接报告给 PagerDuty。 每次在生产中检测到新问题且未报告时，我们确保将来添加一个新探针以监视此类错误。 - -## 易于部署 - -**此堆栈的简单性使部署变得容易** 。 在部署任何代码之前，我们应用一堆单元测试和非回归测试。 一旦所有这些测试通过，我们便逐渐部署到集群。 - -我们的部署永远不会影响生产，也不会对最终用户可见。 同时，我们还希望以协商一致的方式产生主机故障，以便检查一切是否按预期进行。 为了实现这两个目标，我们独立部署群集的每台计算机，并应用以下过程： - -1. 获取新的 Nginx 和生成器二进制文件。 - -2. [正常重启 nginx](http://nginx.org/en/docs/control.html#upgrade) Web 服务器，并使用新的二进制文件重新启动 nginx，而不会丢失任何用户查询。 - -3. 杀死构建器并使用新的二进制文件将其启动。 这会触发每台计算机部署 RAFT 失败，从而使我们能够确保故障转移按预期进行。 - -操作系统的简单性是我们体系结构的重要目标。 我们既不希望也不相信部署应该受到体系结构的限制。 - -## 实现良好的全球覆盖范围 - -服务正在变得越来越全球化。 仅在全球一个地区提供搜索查询远非最佳。 例如，在美国东部地区托管搜索将在可用性方面有很大不同，具体取决于用户从何处进行搜索。 对于美国东部用户来说，延迟时间将从几毫秒到亚洲用户的数百毫秒，这还不包括饱和的海外光纤的带宽限制。 - -我们已经看到一些公司在搜索引擎之上使用 CDN 来解决这些问题。 最终，这给我们带来了比价值更大的问题，因为使缓存无效是一场噩梦，并且仅提高了很少一部分频繁执行的查询的速度。 我们很清楚，为了解决这个问题，我们需要将索引复制到不同的区域，并将它们加载到内存中，以便有效地回答用户查询。 - -我们需要的是在现有群集复制之上的 **区域间复制** 。 副本可以存储在一台机器上，因为该副本仅用于搜索查询。 所有写操作仍将转到客户的原始群集。 - -**每个客户都可以选择他们希望拥有的一组数据中心** 作为复制对象，因此特定区域中的复制计算机可以从多个群集中接收数据，并且一个群集可以 将数据发送到多个副本。 - -此架构的实现是基于我们基于共识的操作流建模的。 在达成共识之后，每个集群都将其自己的写操作流转换为每个副本的版本，以确保用无操作作业替换与此副本无关的作业。 然后，此操作流作为一批操作发送到所有副本，以避免尽可能多的延迟。 一次发送作业将导致重复的往返次数过多。 - -在群集上，写操作将保留在计算机上，直到所有复制对其进行确认为止。 - -DSN 的最后一部分是将最终用户直接重定向到最近的位置。 为此，我们以 APPID-dsn.algolia.net 的形式添加了另一个 DNS 记录，该记录负责解决最接近的数据中心的问题。 我们首先使用了 Amazon 的 Route53 DNS 服务，但很快达到了极限。 - -* 基于延迟的路由仅限于 AWS 区域，并且我们有印度，香港，加拿大和俄罗斯等 AWS 未覆盖的位置。 - -* 基于地理位置的路由非常糟糕。 您需要为每个国家/地区指定 DNS 解析度。 这是许多托管 DNS 提供商所采用的经典方法，但是对于我们而言，这将是一个噩梦，无法提供足够的相关性。 例如，我们在美国有几个数据中心。 - -经过大量基准测试和讨论，出于以下几个原因，我们决定使用 [NSOne](http://www.nsone.net) 。 - -* 对我们来说，他们的 Anycast 网络非常出色，并且比 AWS 更好的平衡。 例如，他们在印度和非洲拥有 POP。 - -* 他们的滤波器逻辑非常好。 对于每个客户，我们可以指定与其关联的机器（包括复制机器）列表，并使用地理位置过滤器按距离对它们进行排序。 这样我们就可以保持最好的状态。 - -* 它们支持 EDNS 客户端子网。 这对我们来说很重要，以便更具针对性。 我们使用最终用户的 IP 而不是其 DNS 服务器的 IP 进行解析。 - -在性能方面，我们已经能够在第二级达到全球范围内的全球同步。 您可以在 [Product Hunt 的搜索](http://www.producthunt.com/) （托管在美国东部，美国西部，印度，澳大利亚和欧洲）或 [Hacker News 上进行尝试。 搜索](https://hn.algolia.com/) （托管在美国东部，美国西部，印度和欧洲）。 - -## 结论 - -我们花费了大量时间来构建我们的分布式和可伸缩体系结构，并且遇到了许多不同的问题。 我希望本文能使您更​​好地了解我们如何解决这些问题，并提供有关如何设计自己的服务的有用指南。 - -我看到越来越多的服务目前正面临着与我们类似的问题，全世界的受众都拥有多区域的基础架构，但是却拥有一些全球一致的信息，例如登录名或内容。 为了获得出色的用户体验，如今必须拥有多区域基础架构。 例如，可以使用这种方法来分发在全球范围内一致的只读数据库副本！ - -如果您有任何问题或意见，我将很乐意回答。 - -[在 HackerNews 上](https://news.ycombinator.com/item?id=11185713) - -FWIW，Raft 和 Paxos 之间的主要区别在于，如果在故障转移期间发生写操作，则 Raft 保证数据丢失。 Paxos 直接将写入与主选举过程联系在一起，以使写入不会丢失。 两者还可以在部分网络故障的情况下锁定到位； 根据具体实施情况，Raft 倾向于留在那里并接受数据一段时间。 因此，尽管 Raft 更简单/更轻松，但这是因为它使您能够以非常糟糕的方式破坏 Paxos 明智地处理的事情。 - -这篇文章将来会发表。 可能弄乱了一些提要阅读器。 - -您是否考虑过使用 Kafka 在集群中实现“状态机”复制？ - -我是作者，并回复评论： - -以色列：RAFT 和 Paxos 的保证是相同的：当共识成功时，就可以保证没有数据丢失。 您能否详细说明为什么您认为并非如此？ - -凯恩：由于多个地区的部署，卡夫卡不是一个选择。 我们需要对复制的序列 ID 分配进行更底层的控制 - -您在搜索引擎中使用什么技术？ - -@Jeyendran 如简介中所述，这是我们自己的引擎，以低级 C ++开发，并作为模块嵌入在 nginx 中。 由于以下几个原因，我们不是基于像 lucene / sphinx 这样的开源引擎： --我们处理关联性的方式非常不同，这意味着对现有引擎 -进行了巨大的重构-在即时搜索中具有非常好的性能 用例（键入时进行搜索），我们具有不同的数据结构。 我将尝试写一篇博客文章来解释我们所有的算法/数据结构差异 - -可能是我读过的最好的文章！ - -我很高兴看到其他人考虑了“三个进程”机制，并在 nginx 和其他进程之间使用了 mmap 文件。 和强大的）集群技术。 - -谢谢您的出色工作。 - -您提到过，在使用 RAFT 协议的一致性上存在折衷。 根据我的理解，RAFT 并没有给出分区容限，因为每个状态机都需要互相交谈以复制状态。 因此，这是 CAP 定理的 CA 系统，在这里我们可以最终保持一致。 - -我喜欢你的文章。 感谢分享 ：）） - -嗯，是的，Raft 和 Paxos 都提供了类似的一致性保证。 甚至还有自动的正确性证明：https://github.com/uwplse/verdi/pull/16 - -该帖子说他们使用 Raft 来协调故障转移，并且分别决定损害一致性，而不是他们使用 Raft 损害了的一致性*。 您可以维护有关某些事物（例如，当前哪个节点是主节点）的始终一致的信息，而不能维护其他事物（例如，您正在服务的索引的实际内容）。* - -也许 Raft 不一致的想法来自对 https://aphyr.com/posts/316-jepsen-etcd-and-consul 的误解，（正确地）它说 Raft 的两个广泛使用的实现缺少了使 读取速度较慢，但​​有必要避免以下情况：1）您在分区的少数一方 2）先前的主机太 3）选出新的主机，并且有人在第一秒内向其中写入新数据，或者 因此，4）您在写完之后阅读。 - -两种系统最终都提供了没有异常的模式，这是由于 Raft 的实现不完整所致，而不是 Raft 本身的缺陷。 - -非常感谢您的帖子。 我学到了很多。 \ No newline at end of file +感谢您的发布。 非常全面，连贯，详细。 可以确定的时间是 Verizon 之前的收购。 我想知道老电话公司做了什么来弄乱这个漂亮的沙箱。 另一个奇迹：他们赚钱了吗？ \ No newline at end of file diff --git a/docs/86.md b/docs/86.md index 5b2bc36..2136d75 100644 --- a/docs/86.md +++ b/docs/86.md @@ -1,62 +1,26 @@ -# HappyPancake：建立简单可扩展基金会的回顾 +# Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL -> 原文： [http://highscalability.com/blog/2015/2/23/happypancake-a-retrospective-on-building-a-simple-and-scalab.html](http://highscalability.com/blog/2015/2/23/happypancake-a-retrospective-on-building-a-simple-and-scalab.html) +> 原文： [http://highscalability.com/blog/2012/2/20/berkeley-db-architecture-nosql-before-nosql-was-cool.html](http://highscalability.com/blog/2012/2/20/berkeley-db-architecture-nosql-before-nosql-was-cool.html) -![](img/6501d09f8bcc4bdec007a12721e5b098.png) +![](img/c5609977746e08c737e71118996cd87c.png) -*这是 [Rinat Abdullin](http://abdullin.com/about-me/) 的来宾转发，他曾从事 *[HappyPancake](http://www.happypancake.com/) 和*的工作，这是瑞典最大的免费约会网站。 最初是用 ASP.NET 和 MS SQL 数据库服务器编写的，但最终变得过于复杂和扩展成本很高。 这是近两年来有关该项目发展的一系列引人入胜的文章中的最后一篇。 有关完整列表，请参见本文结尾。* +在文件系统和简单的库包之后，例如 [dbm](http://en.wikipedia.org/wiki/Dbm) ， [Berkeley DB](http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html) 是最初被应用程序广泛用作其核心数据库引擎的豪华嵌入式数据库。 NoSQL 比 NoSQL 还酷。 使复杂的应用程序唱歌的隐藏秘密。 如果您希望免除基于服务器的系统的所有网络开销，那么它仍然是一个不错的选择。 -我们在 HappyPancake 上的项目已于本周完成。 我们为瑞典最大的免费约会网站的下一个版本**（在挪威和芬兰开展业务）提供了一个简单且可扩展的基础。** +[《开源应用程序的体系结构](http://astore.amazon.com/possiboutpos-20/detail/1257638017)》一书中对 Berkeley DB 背后的体系结构进行了大量撰写。 如果您想了解有关数据库如何工作的更多信息，或者如果您正在考虑如何构建自己的数据库，那么它的详细信息，说明和课程将非常丰富。 这是本书中的 [Berkeley DB](http://www.aosabook.org/en/bdb.html) 章节。 它涵盖了以下主题：建筑概述； 访问方法：Btree，Hash，Reno，Queue； 库接口层； 缓冲区管理器：Mpool； 预写日志记录； 锁管理器：锁； 日志管理器：日志； 事务管理器：Txn。 -## 旅程 - -以下是该旅程的简短地图。 它列出了我们为该项目评估的技术和方法。 黄色区域突出显示了进入最终设计的项目。 - -![](img/bea501f4d8228089cf0819c38337c2f7.png) - -## 项目交付 - -**项目可交付成果**包括： - -* 具有主要功能的可部署全栈应用程序。 -* 在软件设计（后端和前端）和一组声明性用例（充当活动文档，系统概述和行为测试套件）中捕获的领域模型。 -* 用于开发和持续集成的已配置环境（docker 容器）。 -* 进一步发展和扩展系统的策略。 -* 用于将现有生产部署迁移到新版本软件的代码。 - -最终的高层**体系结构很容易推断和扩展**。 它就是这样设计的。 - -![](img/89c7299bcde61247cdce911184e02b93.png) - -从逻辑上讲，整个解决方案由后端模块（由 golang 包表示）和 Facebook Flux 体系结构的元素（通过命名约定在命名空间中组合在一起）组成。 - -随着项目规模和复杂性的增长，这种结构有助于维护项目。 - -![](img/9809c2865415feb94c07ab2c1dc903b1.png) - -此设计还有助于扩展部署以处理更高的负载。 - -我们可以通过以下方式**扩展后端**： - -* 将单个模块移至更大的服务器； -* 启动单个模块的多个实例； -* 将单个模块的存储切换到集群解决方案，将其移动到更大的服务器，甚至推送到云。 - -我们可以通过简单地在负载均衡器后面启动新实例来扩展**前端**。 - -![](img/8f6a49f157b87680cb4e15f0a572d639.png) +## 相关文章 -解决方案结构还提供了一种在开发人员之间分配工作的自然方法。 给定已建立的发布语言（API 和事件的合同），我们还可以引入更多开发人员，将他们分配给在单个后端模块或前端命名空间上工作。 +* [伯克利 DB：Margo Seltzer 的回顾性](http://sites.computer.org/debull/a07sept/seltzer.pdf) +* [在维基百科](http://en.wikipedia.org/wiki/Berkeley_DB)上 +* [LevelDB-MapReduce 和 BigTable 作者的快速轻量级键/值数据库。](http://highscalability.com/blog/2011/8/10/leveldb-fast-and-lightweight-keyvalue-database-from-the-auth.html) -## 得到教训 +当然，如果您的方案是非分片的单个 Web 服务器，那么 BerkeleyDB 的速度将惊人地快。 我在 BookMooch.com 上使用 BerkeleyDB 已有 6 年了，对于单个网页来说，现实世界中每秒 200 万次查询的查询速度是很典型的。 这些不是模拟的速度：在锁定，窃听等之后，它是真实的速度。这种速度让我可以使用 BerkeleyDB 代替内存中的数组，然后获得自动持久性（就像 Perl 一样）。 -* 选择正确的技术可以减少开发工作。 -* 在我的下一个项目中，我将尝试着重于分而治之的方法-先隔离一小部分然后进行改进，以限制进行中的工作量。 -* 尽早建立所有利益相关者参与的反馈循环至关重要。 这可以建立信任并有助于避免意外。 +-约翰 -## 相关文章 +首先，让我说“ NoSQL 比 NoSQL 还酷”的名字是 MarkLogic 很久以来提出的（[，我有衬衫来证明它](http://contentmangler.wordpress.com/2012/02/25/marklogic-nosql-before-nosql-was-cool/?preview=true&preview_id=35&preview_nonce=9757b1bfd1)）。 话虽如此，在速度和可伸缩性方面，MarkLogic 是事实上的 XML 数据库。 MarkLogic 不需要水平分片，因为它是为群集和协调数千个节点和 PB 级数据而构建的。 MarkLogic 在一些内容/数据非常复杂的大型公司中安装了设备，并且可以对任何节点或文档执行亚秒级的查询。 我认为伯克利是一个很棒的工具，但充其量只是新颖，我会对企业中谁在使用它以及在什么规模上使用它感兴趣。 成为与 MarkLogic 紧密合作的人。 我知道它可以扩展并解决很多信息问题，无论您拥有 100 GB 还是 100 TB 的内容。 -* [关于黑客新闻](https://news.ycombinator.com/item?id=9101133) -* 完整的 HappyPancake 文章系列。 仅标题即可指示项目之字形随时间变化的方式。 [简介](http://abdullin.com/happypancake/intro/)； [新团队](http://abdullin.com/happypancake/2013-12-17/)； [语言是实现细节](http://abdullin.com/happypancake/2013-12-23/)； [与 Golang 一起前进](http://abdullin.com/happypancake/2014-01-18/)； [从 FoundationDB](http://abdullin.com/happypancake/2014-02-02/) 开始； [逐步发展堆栈并学习 Nanomsg](http://abdullin.com/happypancake/2014-02-08/) ； [设计用于吞吐量和低延迟](http://abdullin.com/happypancake/2014-02-17/)； [容器，虚拟化和集群](http://abdullin.com/happypancake/2014-02-24/)； [基准测试和调整堆栈](http://abdullin.com/happypancake/2014-03-19/)； [计划变更](http://abdullin.com/happypancake/2014-04-07/)； [返回基础](http://abdullin.com/happypancake/2014-04-14/)； [消息传递-社交网站的心脏](http://abdullin.com/happypancake/2014-04-21/)； [事件驱动的一周](http://abdullin.com/happypancake/2014-04-28/)； [反应性原型](http://abdullin.com/happypancake/2014-05-05/)； [战术 DDD](http://abdullin.com/happypancake/2014-05-12/) ； [Emergend Design 面对现实](http://abdullin.com/happypancake/2014-05-24/)； [最小可行产品](http://abdullin.com/happypancake/2014-06-01/)； [Almost Demo](http://abdullin.com/happypancake/2014-06-09/) ; [我们的第一个演示](http://abdullin.com/happypancake/2014-06-13/)； [Scala，模块化设计和 RabbitMQ](http://abdullin.com/happypancake/2014-06-30/) ，[分配工作](http://abdullin.com/happypancake/2014-07-06/)； [更智慧的发展](http://abdullin.com/happypancake/2014-07-21/)； [提供功能和测试](http://abdullin.com/happypancake/2014-07-29/)； [数据，用例和新模块](http://abdullin.com/happypancake/2014-08-02/)； [从假期回来](http://abdullin.com/happypancake/2014-08-16/)； [原生性能](http://abdullin.com/happypancake/2014-08-25/)； [功能，用例，Rendr](http://abdullin.com/happypancake/2014-09-07/) ； [Node.js 入门，Lazojs](http://abdullin.com/happypancake/2014-09-15/) ； [Web 开发的好部分](http://abdullin.com/happypancake/2014-09-23/)； [响应式用户体验](http://abdullin.com/happypancake/2014-09-29/)； [供稿，聊天，在线列表和 CSS](http://abdullin.com/happypancake/2014-10-07/) ； [发送给 ReactJS 和 Facebook Flux](http://abdullin.com/happypancake/2014-10-27/) ； [项目完成](http://abdullin.com/happypancake/2014-11-06/)。 +-加里·维达尔 -喜欢可视化。 您在其中创建了什么软件？ \ No newline at end of file +请查看 Bangdb。 当前，嵌入式版本已在 www.iqlect.com 上发布。 BerkleyDB 和 LevelDB 有一个有趣的性能比较文档。 请在可能的情况下退房。 +谢谢 \ No newline at end of file diff --git a/docs/87.md b/docs/87.md index dddcdee..0c11a7c 100644 --- a/docs/87.md +++ b/docs/87.md @@ -1,61 +1,64 @@ -# 将 Kim Kardashian 扩展到 1 亿个页面 +# Pixable Architecture-每天对 2000 万张照片进行爬网，分析和排名 -> 原文： [http://highscalability.com/blog/2015/2/16/scaling-kim-kardashian-to-100-million-page-views.html](http://highscalability.com/blog/2015/2/16/scaling-kim-kardashian-to-100-million-page-views.html) +> 原文： [http://highscalability.com/blog/2012/2/21/pixable-architecture-crawling-analyzing-and-ranking-20-milli.html](http://highscalability.com/blog/2012/2/21/pixable-architecture-crawling-analyzing-and-ranking-20-milli.html) -![](img/54b0726e5abf8094b9c2fe6b6d888d4b.png) +*这是 Pixable 的 CTO PHD 的 Alberto Lopez Toledo 和 Pixable 的工程副总裁 Julio Viera 的来宾帖子。* -[PAPER](http://www.papermag.com/) 小组估计他们的 [文章](http://www.papermag.com/2014/11/kim_kardashian.php) （NSFW）包含 非常裸露的 [Kim Kardashian](http://en.wikipedia.org/wiki/Kim_Kardashian) 的图片将很快获得超过 1 亿的页面浏览量。 突发性病毒驱动流量的非常定义。 +![](img/c757a58e9a5343904e20bc929f9dc75a.png) [可混合](http://new.pixable.com/)汇总来自您不同社交网络的照片，并找到最佳照片，因此您永远不会错过重要时刻。 这意味着当前每天要处理超过 2000 万张新照片的元数据：对它们以及已经存储在我们数据库中的其他 5+十亿张图像进行爬网，分析，排名和排序。 弄清所有数据都面临挑战，但尤其要强调两个挑战： -与 2013 年相比， [估计为](http://www.cnet.com/news/google-search-scratches-its-brain-500-million-times-a-day/) Google 每天处理超过 5 亿次搜索。 因此，裸露的金·卡戴珊（Kim Kardashian）值得拥有 Google 的五分之一。 奇怪的是，我可以相信。 +1. 如何每天以最有效的方式从 Facebook，Twitter，Instagram 和其他服务访问数百万张照片。 +2. 如何处理，组织，索引和存储与那些照片相关的所有元数据。 -他们如何处理这个交通金矿？ 保罗·福特（Paul Ford）在 [中完整讲述了幕后的故事，《 PAPER Magazine》的网络工程师如何为 Kim Kardashian](https://medium.com/message/how-paper-magazines-web-engineers-scaled-kim-kardashians-back-end-sfw-6367f8d37688) （SFW）扩展后端 。 （顺便说一句，在这个故事中，只有一个双关语是故意制作的，其他都是偶然的）。 +当然，Pixable 的基础架构正在不断变化，但是去年我们学到了一些东西。 因此，我们已经能够构建可扩展的基础架构，以利用当今的工具，语言和云服务，所有这些都在 Amazon Web Services 上运行，其中我们有 80 多个服务器在运行。 本文档简要介绍了这些课程。 -我们可以从经验中学到什么？ 我知道你在想什么 这只是一个静态页面，带有一些静态图片。 这不是一个复杂的问题，例如 [搜索](http://highscalability.com/display/Search?moduleId=4876569&searchQuery=google) 或 [社交网络](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) 。 像样的 CDN 不足以处理这个问题吗？ 您是正确的，但这还不是全部内容： +## 后端架构-一切都会发生 -1. **突发流量**。 有一个非正式的规则，即网站的设计应能处理比一般流量大一个数量级的突发事件。 PAPER 通常在给定的月份中可以处理数十万人，因此在压缩的时间内增加两个数量级的流量无疑是值得担心的事情。 +### 基础架构-喜欢 Amazon EC2 -2. **提前计划** 。 PAPER 并不信任命运，而是知道他们有一个大故事，因此他们联系了他们的 Web 基础架构团队，并给了他们五天的准备时间，以确保该网站能够处理即将来临的观众。 +我们使用 CentOS Linux，使用从 t1.micro 到 m2.2xlarge 的各种实例在 Amazon EC2 上维护所有服务器。 设置服务器后，我们将创建自己的内部 AMI（每种类型的服务器一个）。 我们总是准备好在负载增加时立即部署它们，从而始终保持最低性能标准。 -3. **卡戴珊前堆栈**。 PAPER 在单个实例上运行在单个 AWS 区域（大小未知）中，MySQL 可能是数据库， [可移动类型](https://movabletype.org/) 是 CMS， [龙卷风](http://www.tornadoweb.org/en/stable/) 是 Web 服务器， [Varnish](https://www.varnish-cache.org/) 是缓存。 该设置每月可为 50 万至 100 万的唯一身份访问者提供服务。 +为了补偿这些负载波动，我们开发了自己的自动伸缩技术，该技术可以根据一天中特定时间的当前和历史负载来预测每种类型的服务器数量。 然后，我们启动或终止实例只是为了保持正确的配置水平。 这样，我们就可以通过在不需要服务器时缩减服务器规模来节省资金。 在亚马逊中自动缩放并非易事，因为要考虑许多变量。 -4. **后卡戴珊式堆栈**。 Kardashian 之前的站点已转换为使用预热的负载平衡器，四台前端计算机，共享文件系统和 Amazon 的 CloudFront CDN 的站点。 这是用于处理照片释放的 PAPER 纸叠的 [漂亮图](https://d262ilb51hltx0.cloudfront.net/max/2000/1*NRRjxiTzjIFBK4UlJ3m2ww.jpeg) 。 添加了四台 m3.large 前端计算机，用于托管可移动类型，龙卷风和光油。 然后，在横向扩展的网络附加存储文件系统 [GlusterFS](http://glusterfs) 上构建分布式文件系统层。 将所有媒体复制到运行在 m3.xlarge 上的 Gluster Filesystem Server。 可以根据需要添加更多的存储节点，这就是 Gluster 带来的好处。 前端计算机将 Gluster 用作其虚拟磁盘。 ELB 用于平衡前端计算机之间的流量。 +例如：由于 Amazon 会收取整个小时的费用，因此终止仅运行了半个小时的实例是没有意义的。 此外，亚马逊可能需要 20 多分钟才能启动即时实例。 因此，对于流量的突然激增，我们对按需实例（启动速度更快）进行了一些巧妙的启动调度，然后在接下来的一个小时内将它们替换为现场实例。 这是纯粹的运营研究的结果，其目的是为了以适当的金额获得最佳性能。 可以把它想像成电影《 Moneyball》，但它带有虚拟服务器而不是棒球运动员。 -5. **测试** 。 CDN 将处理静态内容的负载，Varnish 将缓存网站的动态内容，ELB 将分发流量，但网站仍必须处理流量。 [带机枪的蜜蜂](https://github.com/newsapps/beeswithmachineguns) 以每秒 2,000 个请求的速度测试系统。 目标是每秒测试 10,000 个请求，但显然无法使用该工具来达到该速度。 +我们的 Web 服务器当前运行 Apache + PHP 5.3（最近我们一直在微调一些 Web 服务器以运行 nginx + php-fpm，它将很快成为我们的标准配置）。 这些服务器平均分布在 Amazon Elastic Load Balancer 后面的不同可用性区域中，因此我们可以吸收 Amazon 的停机时间和价格波动。 我们的静态内容存储在 Amazon Cloud Front 上，并且我们将 Amazon Route 53 用于 DNS 服务。 是的，确实……我们爱亚马逊。 -6. **应急响应计划** 。 据估计，该系统在第一个小时内可接待 3000 万访客，但已计划如何根据需要启动更多的前端服务器。 该计划没有使用 Chef，Puppet 甚至 Docker，显然所需的命令存储在 Google Docs 文档中。 +### 工作队列-用于抓取照片并对其进行排名，发送通知等的工作 -7. **Instagram 偷走了流量！** 内容创建者通常会输给内容聚合者。 到 PAPER 网站的访问量远远低于预期。 这就说明了一切。 她的 2500 万关注者去了那里，而不是去 PAPER 的网站。” 明智的选择：推出计划的**部分应包括确保您从工作**中获得最大收益的策略。 +实际上，Pixable 的所有处理都是通过异步作业完成的（例如，从 Facebook 抓取来自不同用户的新照片，发送推送通知，计算朋友排名等）。 我们有数十个工作服务器，它们从不同服务的照片中抓取元数据并处理该数据。 这是一个连续的，全天候的过程。 -8. **纸张通过完全正面** 进行报复。 PAPER 通过发布 Kardashian 的全额裸照从 Instagram 收回了主动权。 Instagram 不允许这类图片，因此这次访问量流向了 PAPER。 几天来，访问量激增，有 3000 万独立访问者。 该站点可以毫无问题地处理所有流量。 +不出所料，我们有不同类型的工作：一些优先级高的工作，例如实时用户呼叫，消息收发以及为当前活动用户抓取照片。 优先级较低的作业包括脱机爬网和长时间的数据密集型延迟任务。 尽管我们使用功能强大的 [beantalkd](http://kr.github.com/beanstalkd/) 作为我们的作业队列服务器，但我们在其之上开发了自己的管理框架。 我们将其称为自动驾驶仪，它会自动管理优先级的处理，例如 通过将作业服务器时间用于高优先级作业，并在满足平台范围的某些条件时暂停低优先级作业。 -9. **返回到卡戴珊前堆栈**。 几周后，新堆栈被拆除，旧堆栈又重新运行了该站点。 不完全是自动可伸缩性的先驱者，但是灵活性仍然很高。 +我们开发了非常复杂的规则来处理这些优先级，同时考虑了影响系统性能和影响用户感知速度的指标。 有些是显而易见的，例如作业的平均等待时间或从属服务器的滞后时间（ssshhh，我们从不滞后于从属服务器:-)），而更复杂的指标则是分布式分布式 PHP 同步互斥锁的状态。 环境。 我们会尽力在效率和绩效之间做出公平的权衡。 -10. **您的评论系统可以处理负载吗？** 这种文章将获得很多评论。 不要忘记评论系统的负担。 如果失败，即使网站的其余部分运行正常，您也会看起来很糟糕。 PAPER 使用 Facebook 的评论插件，该插件似乎可以毫无问题地处理 5,100 多个评论。 +### 抓取引擎-在 Facebook，Twitter 等 24/7 上抓取新照片 -11. **估算？** 我感兴趣的故事之一是 PAPER 如何将页面浏览量预测为 1 亿？ 这个估计推动了所有变化。 如果太大，他们会浪费很多钱。 如果它太小，它们将以不止一种方式被压碎。 这种预测的过程是什么？ +我们一直在不断改进抓取技术，这是一种复杂的并行算法，它使用内部开发的互斥锁库来为特定用户同步所有进程。 自推出以来，该算法已帮助我们将 Facebook 的抓取速度提高了至少 5 倍。 现在，我们每天可以轻松获取超过 2000 万张新照片。 考虑到事实上，对 [Facebook API](http://developers.facebook.com/) 的任何大数据查询都可能需要几秒钟的时间，因此这是非常出色的。 我们将在一个辅助文档中更深入地了解我们的抓取引擎。 -本文非常独特，我认为我从未读过类似的文章。 它将许多不同的主题和受众聚集到一个地方，并试图将它们联系在一起……同时保持娱乐性。 如果您是 DevOp，那么这篇文章对您来说就没什么用了。 但是，它在与普通观众打交道方面做得很好，向他们解释了运行网站所需的资源。 或者作为匿名恩人写给我： +### 数据存储-索引照片和元数据 -> 我之所以喜欢它，是因为几乎所有人（包括需要理解有关使用云资源进行扩展的信息的许多非技术人员）都可以阅读它，以了解构建基于 Java 的动机，活动和收益。 云平台，并将其用于可能破坏非云 IT 基础架构的挑战。 一个很好的故事，讲述得足够详细，传达了有关缩放的有用信息。 +自然，我们的数据存储每天都在增长。 目前，我们使用两组服务器将 90％的数据存储在 MySQL 中（其顶部是 memcached 层）。 第一组是 2 主 2 从配置，该配置存储几乎每个系统访问的更规范化的数据，例如用户配置文件信息，全局类别设置和其他系统参数。 -毫无疑问，某些决定值得商,，但总是如此。 保罗·福特（Paul Ford）对这种攻势做出了强烈回应： +第二个服务器组包含手动分片服务器，我们在其中存储与用户照片有关的数据，例如照片 URL。 此元数据已高度反规范化，以至于我们实际上仅以 MySQL 表（NoSQL-in-MySQL）的形式将存储作为 NoSQL 解决方案（如 MongoDB）运行。 因此，您可以猜测其他 10％的数据存储在什么地方，对吗？ 是的，在 MongoDB 中！ 我们将部分存储移至 MongoDB，主要是因为它提供了简单灵活的分片和复制解决方案。 -> 书呆子喜欢做的事情之一就是看着别人的筹码，然后说：“纸牌屋！” 实际上，我完全希望人们链接到本文，并写出诸如“听起来还不错，但他们本应在所有串流中都使用带有 Zastring 扩展名的 Jizzawatt 和 Graunt.ns 的东西。” +### 记录，分析和分析 -## 相关文章 +我们开发了高度灵活的日志记录和性能分析框架，该框架使我们能够以高粒度记录事件-只需一行代码。 每个日志事件均按一组我们稍后查询的标签进行分类（例如，用户 X 的事件或模块 Y 中的调用）。 最重要的是，我们可以动态地分析任何日志记录事件之间的时间，从而使我们能够构建整个系统的实时性能分析。 日志记录和概要分析系统在存储系统上的负担非常重（每秒数千次更新），因此我们开发了两级 MySQL 表（基于内存的快速缓冲区，用作实际数据的泄漏存储区）的混合体 存储），再结合一些分区的 MySQL 表，这些表稍后会异步填充。 这种架构使我们每秒可以处理 15,000 多个日志条目。 我们还拥有自己的事件跟踪系统，其中记录了从登录到共享到单个点击的每个用户操作，以便以后可以使用复杂的查询进行分析。 -* [在 Reddit 上](http://www.reddit.com/r/programming/comments/2w3mis/scaling_kim_kardashian_to_100_million_page_views/) +我们还严重依赖于出色的 [Mixpanel](http://www.mixpanel.com/) 服务，这是一个基于事件的跟踪系统，我们在其中执行大部分高级分析和报告。 -* [策略：通过快速扩展您的网站来缓解流量激增的三种技术](http://highscalability.com/blog/2014/3/19/strategy-three-techniques-to-survive-traffic-surges-by-quick.html) +## 前端-简单的可视化设备 -* [超级碗广告商准备好了流量吗？ 不，它熄灭了](http://highscalability.com/blog/2013/2/6/super-bowl-advertisers-ready-for-the-traffic-nopeits-lights.html) 。 +Pixable 可在多个（前端）设备中运行，最受欢迎的设备是 iPhone 和 iPad。 我们也有加载简单索引页的 Web 和移动 Web 站点，其他所有操作都通过广泛使用 jQuery 和 Ajax 调用在客户端中执行。 我们所有的 Web 前端都将很快运行一个可自动适应移动或桌面屏幕的代码库（尝试一下！ [http://new.pixable.com](http://new.pixable.com/) ）。 这样，我们可以在我们的主站点，Android 设备或 Chrome 浏览器扩展程序上运行相同的代码！ 实际上，我们的 Android 应用是原生应用和我们的移动网络前端的结合。 Android 应用程序使用最少的控件来渲染框架，并仅在其中显示移动 Web 视图。 -* [关于构建有效的高流量 Web 软件的 22 条建议](http://highscalability.com/blog/2013/12/16/22-recommendations-for-building-effective-high-traffic-web-s.html) +听起来有些刺耳，但是我们所有的前端都是“哑巴”。 所有繁重的工作都在后端执行，所有事情都通过我们自己的私有 API 连接。 这使我们能够快速进行开发和部署，而不必更改已安装的用户群。 敏捷，宝贝！ -* [StubHub 架构：全球最大的票务市场背后的惊人复杂性](http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html) +## API-连接我们的前端和后端 -* [使用内存网格](http://highscalability.com/handle-1-billion-events-day-using-memory-grid) 每天处理 10 亿个事件 +API 是使一切保持协同工作的粘合剂。 使用 [Tonic PHP](http://peej.github.com/tonic/) ，我们开发了自己的私有 RESTful API，该 API 公开了我们的后端功能。 另外，我们扩展了 [Tonic](http://peej.github.com/tonic/) ，使其支持内置版本控制。 这样一来，在开发新功能或更改 API 中的响应格式时，我们很容易保持向后兼容性。 我们只配置哪个设备版本支持哪些版本的 API 调用。 无论版本多旧，我们都有不留设备的政策！ -* [技术星期二：我们的技术堆栈](http://imgur.com/blog/2013/06/04/tech-tuesday-our-technology-stack/) +但是 API 并没有做任何实际的工作。 它仅依赖于来自前端的信息，并将其传递给实际的 Pixable 心脏：后端。 -* [在 ELB 前面放上清漆的两个问题](http://www.reddit.com/r/devops/comments/2t8ib2/how_paper_magazines_web_engineers_scaled_their/cnx7n13) \ No newline at end of file +每天排名 2000 万张照片？ 真的很棒 + +值得读。 谢谢你的好文章。 \ No newline at end of file diff --git a/docs/88.md b/docs/88.md index ea75d5a..619733e 100644 --- a/docs/88.md +++ b/docs/88.md @@ -1,356 +1,177 @@ -# Vinted 体系结构：每天部署数百次，以保持繁忙的门户稳定 - -> 原文： [http://highscalability.com/blog/2015/2/9/vinted-architecture-keeping-a-busy-portal-stable-by-deployin.html](http://highscalability.com/blog/2015/2/9/vinted-architecture-keeping-a-busy-portal-stable-by-deployin.html) - -![](img/94c1673242b5990d73da86cff661af23.png) - -*这是 [Vinted](https://www.vinted.com/) 的 [NerijusBendžiūnas](https://www.linkedin.com/profile/view?id=48589106)和 [Tomas Varaneckas](https://twitter.com/spajus) 的来宾帖子。* - -[Vinted](https://www.vinted.com/) 是一个对等市场，用于出售，购买和交换衣服。 它允许成员直接通信，并具有社交网络服务的功能。 - -它始于 2008 年，最初是一个立陶宛女孩的小社区，后来发展成为一个全球性项目，为 8 个不同国家/地区的 700 万用户提供服务，并且这一需求正在不断增长，每天处理超过 2 亿个请求。 - -## 统计资料 - -* 700 万用户，并且还在不断增长 -* 每月 250 万活跃用户 -* 每天 2 亿个请求（浏览量+ API 调用） -* 9.3 亿张照片 -* 80 TB 原始空间用于图像存储 -* 60 TB HDFS 原始空间用于分析数据 -* 70％的流量来自移动应用（API 请求） -* 每位成员每周花费 3 个小时以上的时间 -* 2500 万个上市项目 -* 超过 220 台服务器： - * 47 用于内部工具（vpn，厨师，监视，开发，制图，构建，备份等） - * Hadoop 生态系统 38 - * 34 用于图像处理和存储 - * 独角兽和微服务 30 - * 28 个用于 MySQL 数据库，包括副本 - * 19 用于狮身人面像搜索 - * 10 个用于背景工作 - * 10 用于使用 Nginx 进行负载平衡 - * 卡夫卡 6 - * Redis 4 - * 4 用于电子邮件传递 - -## 技术栈 - -### 第三方服务 - -* [GitHub](https://github.com/) ，用于代码，问题和讨论 -* [NewRelic](http://newrelic.com/) 用于监视应用程序响应时间 -* [CloudFlare](https://www.cloudflare.com/) 用于 DDoS 保护和 DNS -* [Amazon Web Services](http://aws.amazon.com/) （SES，Glacier），用于通知和长期备份 -* [闲暇](https://slack.com/)用于工作对话和“聊天操作” -* [Trello](https://trello.com/) 完成任务 -* [Pingdom](http://pingdom.com/) 用于正常运行时间监控 - -### 核心应用和服务 - -* [Ruby](https://www.ruby-lang.org/) 用于服务，脚本和主应用 -* [主应用程序和内部应用程序的 Rails](http://rubyonrails.org/) -* [独角兽](http://unicorn.bogomips.org/)服务于主应用 -* [Percona MySQL 服务器](http://www.percona.com/software/percona-server/ps-5.6)作为主数据库 -* [Sphinx 搜索](http://sphinxsearch.com/)用于全文搜索并减少 MySQL 的负载（测试 [ElasticSearch](http://www.elasticsearch.org/) ） -* [Capistrano](http://capistranorb.com/) 用于部署 -* [Jenkins](http://jenkins-ci.org/) 用于运行测试，部署和其他各种任务 -* [Memcached](http://memcached.org/) 用于缓存 -* [请求](http://resquework.org/)进行后台作业 -* [Redis](http://redis.io/) 用于 Resque 和 Feed -* [RabbitMQ](http://www.rabbitmq.com/) 用于将消息传递到服务 -* [HAproxy](http://www.haproxy.org/) 提供高可用性和负载平衡 -* [GlusterFS](http://www.gluster.org/) 用于分布式存储 -* [Nginx](http://nginx.org/) 投放 Web 请求 -* [Apache Zookeeper](http://zookeeper.apache.org/) 用于分布式锁定 -* [Flashcache](https://github.com/facebook/flashcache/) 可提高 I / O 吞吐量 - -### 数据仓库堆栈 - -* [Clojure](http://clojure.org/) 用于数据提取服务 -* [Apache Kafka](http://kafka.apache.org/) ，用于存储飞行中的数据 -* [Camus](https://github.com/linkedin/camus) 用于将数据从 Kafka 卸载到 HDFS -* [Apache Hive](https://hive.apache.org/) 作为 SQL-on-Hadoop 解决方案 -* [Cloudera CDH](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh.html) Hadoop 发行版 -* [Cloudera Impala](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html) 作为低延迟 SQL-on-Hadoop 解决方案 -* [Apache Spark](https://spark.apache.org/) 处于实验阶段 -* [Apache Oozie](http://oozie.apache.org/) 作为工作流调度程序（研究替代方案） -* [扩展](https://github.com/twitter/scalding)用于数据转换 -* [Avro](http://avro.apache.org/) 用于数据序列化 -* [Apache Parquet](http://parquet.incubator.apache.org/) 用于数据序列化 - -### 服务器和资源调配 - -* 多为裸金属 -* 多个数据中心 -* [CentOS](http://www.centos.org/) -* [厨师](https://www.chef.io/)用于配置几乎所有内容 -* [Berkshelf](http://berkshelf.com/) ，用于管理 Chef 依赖项 -* [测试厨房](http://kitchen.ci/)，用于在 VM 上运行基础结构测试 -* [Ansible](http://www.ansible.com/) 用于滚动升级 - -### 监控方式 - -* [Nagios](http://www.nagios.org/) 用于常规操作监控 -* [仙人掌](http://www.cacti.net/)用于图形和容量规划 -* [Graylog2](https://www.graylog2.org/) 适用于应用程序日志 -* 用于服务器日志的 [Logstash](http://logstash.net/) -* [Kibana](http://www.elasticsearch.org/overview/kibana/) 用于查询 logstash -* [统计信息](https://github.com/etsy/statsd)，用于从应用程序收集实时指标 -* [石墨](http://graphite.wikidot.com/)，用于存储应用程序中的实时指标 -* [Grafana](http://grafana.org/) 用于创建带有应用指标的精美仪表板 -* [集线器](https://hubot.github.com/)用于基于聊天的监视 - -## 架构概述 - -* 裸机服务器被用作云提供商的更便宜，更强大的替代产品。 -* 在欧洲和美国的 3 个不同数据中心托管服务器。 -* Nginx 前端将 HTTP 请求路由到独角兽工作者并执行 SSL 终止。 -* [Pacemaker](http://clusterlabs.org/) 用于确保 Nginx 服务器的高可用性。 -* 在不同的国家/地区，每个 Vinted 门户网站都有自己单独的部署和资源集。 -* 为了提高机器利用率，属于多个门户的大多数服务可以在单个裸机服务器上彼此并行运行。 主厨配方负责唯一的端口分配和其他分离问题。 -* 通过为每个门户网站使用单独的数据库来避免 MySQL 分片。 -* 在我们最大的门户中，功能性分片已经在发生，距离单个最大表无法容纳在服务器中的点还差几个月。 -* Rails 应用程序中的缓存使用带有 L2 缓存的自定义机制，可以防止主缓存过期时出现峰值。 使用了几种缓存策略： - * 远程（在 memcached 中） - * 本地（在独角兽工作者的记忆中） - * 半本地（在独角兽工作器内存中，当本地缓存到期时回退到 memcached）。 -* 围绕核心 Rails 应用程序构建了几个微服务，它们都有明确的用途，例如发送 iOS 推送通知，存储和提供品牌名称，存储和提供标签。 -* 微服务可以是按端口，按数据中心或全局的。 -* 每个微服务的多个实例正在运行以实现高可用性。 -* Nginx 平衡了基于 HTTP 的微服务。 -* 使用 Redis 实现每个成员的自定义 feed。 -* 使用过滤器（自定义大小，颜色等）时，从 Sphinx 索引而不是 MySQL 加载目录页面。 -* 图像由单独的 Rails 应用处理。 -* 处理后的图像存储在 GlusterFS 中。 -* 第 3 次匹配后会缓存图片，因为前几次匹配通常来自上传者，并且图片可能会旋转。 -* 使用 [twemproxy](https://github.com/twitter/twemproxy) 分割 Memcached 实例。 - -## 球队 - -* 超过 150 名全职员工 -* 30 位开发人员（后端，前端，移动） -* 5 名现场可靠性工程师 -* 立陶宛维尔纽斯的总部 -* 在美国，德国，法国，捷克共和国和波兰设有办事处 - -## 公司的运作方式 - -* 几乎所有信息对所有员工开放 -* 使用 GitHub 进行几乎所有操作（包括讨论公司问题） -* Slack 中的实时讨论 -* 每个人都可以自由参加他们感兴趣的事情 -* 自治队 -* 没有资历等级 -* 跨职能开发团队 -* 没有强制执行的流程，团队可以决定如何管理自己 -* 团队致力于解决高层问题，并决定如何解决它们 -* 每个团队都决定如何，何时何地工作 -* 团队在需要时自行雇用 - -## 开发周期 - -* 开发人员从主人处分支。 -* 更改成为 GitHub 中的请求请求。 -* Jenkins 运行 [Pronto](https://github.com/mmozuras/pronto) 进行静态代码和样式检查，在 pull request 分支上运行所有测试，并使用状态更新 GitHub pull request。 -* 其他开发人员查看更改，添加评论。 -* 拉取请求可能会使用各种修复程序多次更新。 -* 每次更新后，Jenkins 都会运行所有测试。 -* 在与 master 合并之前清理 Git 历史，以保持 master 历史的简洁性。 -* 接受的请求请求将合并到主服务器中。 -* Jenkins 使用所有测试运行主版本，并触发部署作业以推出新版本。 -* 几分钟后，代码到达 master 分支后，将其应用于生产中。 -* 拉取请求通常很小。 -* 每天部署约 300 次。 - -## 避免失败 - -每天部署数百次并不意味着总是必须破坏所有东西，但是保持站点稳定需要一定的纪律。 - -* 如果测试失败，则不会进行部署。 没有方法可以覆盖它，母版必须为绿色才能进行部署。 -* 每天晚上和周末自动部署锁定。 -* 任何人都可以通过 Slack 聊天手动锁定部署。 -* 部署锁定后，可以从 Slack 聊天中手动“强制”部署。 -* 在审查代码时，团队非常挑剔。 质量标准设置得很高。 测试是强制性的。 -* 在 Unicorn 重新加载代码之前，将在生产中进行预热。 它包括对门户网站各个关键部分的若干请求。 -* 在预热期间，如果任何一个请求均未返回 200 OK，则旧代码将保留，并且部署将失败。 -* 有时，测试/预热未发现问题，并且已损坏的代码发布到了生产环境中。 -* 错误将流式传输到 Graylog 服务器。 -* 如果错误率超过阈值，则会触发警报。 -* 错误率警报和失败的构建通知会立即报告给 Slack 聊天。 -* 所有错误都包含额外的元数据：Unicorn worker 主机和 pid，HTTP 请求详细信息，导致问题的代码的 git 修订版，错误回溯。 -* 某些类型的“致命”错误也直接报告给 Slack 聊天。 -* 每个部署日志都包含带有所有更改的 GitHub 差异 URL。 -* 如果生产中出现问题，由于变更集和即时错误反馈的原因，很容易快速查明问题。 -* 部署详细信息会报告给 NewRelic，从而可以轻松解决性能瓶颈的引入。 - -## 减少生产时间 - -快速发布和稳定发布都非常受关注，团队一直在努力使构建和部署时间尽可能短。 - -* 完整的测试套件包含> 7000 个测试，运行时间约为 3 分钟。 -* 不断添加新的测试。 -* Jenkins 在具有 32 个 CPU，128G RAM 和 SSD 驱动器的裸机上运行。 -* Jenkins 将所有测试分成多个块，并并行运行它们，以汇总最终结果。 -* 在没有并行化的情况下，测试将在一台普通计算机上运行 1 个小时以上。 -* 在 Jenkins 中，对于 master 分支中的每次提交，Rails 资产都是预先构建的。 -* 在部署期间，从 jenkins 下载预建资产，并将其上载到所有目标服务器。 -* 将版本上载到目标服务器时使用 BitTorrent。 - -## 运行实时数据库迁移 - -在大多数情况下，即使在高峰时间，我们也可以在不停机的情况下更改生产 MySQL 数据库的结构。 - -* 在任何部署期间都可能发生数据库迁移 -* Percona 工具箱的 pt-online-schema-change 用于在表的副本上运行更改，同时使其与原始副本保持同步，并在更改完成后将副本与原始副本切换 - -# 运作方式 - -## 服务器配置 - -* Chef 用于提供我们基础架构的几乎所有方面。 -* SRE 团队确实会提出对基础结构更改的请求，就像开发团队对代码更改所做的一样。 -* 詹金斯（Jenkins）正在验证所有 Chef 拉取请求，运行交叉依赖关系检查，食品评论等。 -* 团队在 GitHub 上审查了厨师代码的更改。 -* 开发人员可以向 Chef 存储库发出基础结构更改请求请求。 -* 合并拉取请求时，Jenkins 上载更改后的 Chef 食谱并将其应用于生产中。 -* 计划产生 DigitalOcean 小滴以与 Jenkins 一起进行 Chef 厨房测试。 -* Jenkins 本身是使用 Chef 配置的，而不是使用 Web UI。 - -## 监控方式 - -* 仙人掌图服务器端指标 -* Nagios 检查可能出现的所有故障 -* Nagios 健康检查，用于我们的某些应用程序和服务 -* Statsd / Graphite，用于跟踪应用程序指标，例如成员登录，注册，数据库对象创建 -* Grafana 用于漂亮的仪表板 -* 可以使用 Chef 动态描述和创建 Grafana 仪表板 - -## 聊天操作 - -* Hubot 坐在 Slack 中。 -* 松弛房间通过 [hubot-pubsub](https://github.com/spajus/hubot-pubsub) 订阅了各种事件通知。 -* #deploy 会议室显示有关部署的信息，并提供指向 GitHub diff，Jenkins 控制台输出等的链接。在这里，可以使用简单的聊天命令来触发，锁定和解锁部署。 -* ＃deploy-fail 会议室仅显示部署失败。 -* #failboat 会议室显示有关错误率和生产中个别错误的公告。 -* 有多个＃failboat- *房间，其中提供有关 cron 故障，卡住的 resque 作业，nagios 警告，newrelic 警报的信息。 -* 每天两次将 Graylog 错误与 GitHub 进行处理和交叉检查，生成报告并将其提交给开发团队。 -* 如果有人在 GitHub 上提到您，Hubot 会在 Slack 上的私人消息中为您提供该问题的链接。 -* 在 GitHub 中创建问题或请求请求时，提到的团队会在其适当的 Slack 会议室中收到 ping 命令。 -* 可以通过 Hubot 在 Slack 聊天中查询并显示石墨图。 -* 您可以向 Hubo​​t 询问有关基础设施的问题，即有关部署特定服务的机器的问题。 Hubot 查询 Chef 服务器以获取数据。 -* 开发人员将 Hubot 通知用于我们应用中发生的某些事件。 例如，向客户支持聊天室自动通知可能的欺诈案件。 -* Hubot 与 Office [netatmo](https://www.netatmo.com/) 模块集成在一起，可以告诉所有人什么是 CO2，噪声，温度和湿度水平。 - -# 数据仓库堆栈 - -* 我们从两个来源提取数据： - * 网站事件跟踪数据：印象数，点击数等 - * 数据库（MySQL）更改。 -* 大多数事件跟踪数据都从 JavaScript / Android / iOS 前端应用程序发布到 HTTP 端点。 一些事件由我们的核心 Ruby on Rails 应用程序发布到本地 UDP 套接字。 我们选择 UDP 以避免阻塞请求。 -* 有一种服务可以监听 UDP 套接字上的新事件，对它们进行缓冲，并定期在 Kafka 中发出原始事件的主题。 -* 流处理服务使用原始事件主题，验证事件，将它们编码为 Avro 格式，然后发出特定于事件的主题。 -* 我们将事件的 Avro 模式保存在单独的集中式模式注册表服务中。 -* 无效事件被置于单独的 Kafka 主题中，以进行可能的更正。 -* 我们使用 LinkedIn 的 Camus 作业将事件从特定于事件的主题逐步转移到 HDFS。 事件到 Hadoop 的时间通常最多为一个小时。 -* 使用 Hive 和 Impala 进行临时查询和数据分析。 -* 研究基于伸缩的数据处理解决方案。 -* 报告使用我们内部开发的，用 Ruby 编写的类似 OLAP 的报告系统运行。 +# LinkedIn：使用 Databus 创建低延迟更改数据捕获系统 -# 得到教训 +> 原文： [http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html) -## 产品开发 +![](img/0455a7ccb5ea7807b8e9bf566b5ae473.png) -* 投资代码质量。 -* 通过测试涵盖所有内容。 -* 发布小更改。 -* 使用功能开关将未完成的功能部署到生产中。 -* 开发某些东西时，不要保留长时间运行的代码分支。 -* 投资一个快速的发布周期。 -* 首先构建移动产品。 -* 设计 API 从一开始就很好，以后很难更改。 -* 在 RabbitMQ 消息中包含发件人主机名和应用程序名称可以节省生命。 -* 不要猜测或做假设，请进行 [AB](https://github.com/vinted/ab) 测试并检查数据。 -* 如果您打算将 Redis 用于更大的事情，请从一开始就考虑分片。 -* 如果您计划使 Rails 保持最新状态，则切勿使用叉状和稍作修饰的红宝石宝石。 -* 通过社交网络尽可能轻松地共享您的内容。 -* 搜索引擎优化是一项全职工作。 +*这是 LinkedIn 分布式数据系统团队的高级成员 [Siddharth Anand](http://practicalcloudcomputing.com/) 的特邀帖子。* -## 基础设施和运营 +在过去的三年中，我很幸运能够与许多新兴的 NoSQL 产品一起使用，以支持高流量，面向客户的网站的需求。 -* 经常部署以提高系统稳定性。 起初听起来可能违反直觉。 -* 自动化一切。 -* 监视所有可能发生的故障。 -* 网络交换缓冲区很重要。 -* 容量规划很困难。 -* 从一开始就考虑 HA。 -* RabbitMQ 集群不值得付出努力。 -* 测量并绘制所有图形：HTTP 响应时间，Resque 队列大小，模型持久率，Redis 响应时间。 您无法改善无法衡量的东西。 +在 2010 年，我帮助 Netflix 成功 [将其 Web 规模用例从 Oracle 转换为 AWS 的托管数据库服务 SimpleDB](http://highscalability.com/blog/2010/10/22/paper-netflixs-transition-to-high-availability-storage-syste.html) 。 迁移完成后，我们开始了第二次迁移，这次是从 SimpleDB 到 Cassandra 的迁移。 第一次过渡是我们从自己的数据中心迁移到 AWS 的云的关键。 第二个是我们从一个 AWS 区域扩展到多个地理分布区域的关键-今天，Netflix 为两个 AWS 区域提供流量，一个在弗吉尼亚州，另一个在爱尔兰（ [F1](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Footnote_1) ）。 这两个过渡都是成功的，但都涉及集成难题，例如创建数据库复制技术。 -## 数据仓库堆栈 +2011 年 12 月，我加入了 LinkedIn 的分布式数据系统（ DDS ）团队。 DDS 开发了数据基础结构，包括但不限于 NoSQL 数据库和数据复制系统。 LinkedIn 对构建和开放源代码创新项目并不陌生，它正在加倍使用 NoSQL 来加速其业务-DDS 正在开发一个名为 Espresso（ [R1](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Reference_1) ）的新 NoSQL 数据库，这是以后的主题。 -* Hadoop 生态系统中有许多工具。 很难选择合适的。 -* 如果您正在为 Hive 编写用户定义函数（UDF），那么该考虑使用非 SQL 解决方案进行数据转换了。 -* “ Hadoop 应用程序”概念含糊不清。 通常，我们需要手动将应用程序组件粘合在一起。 -* 每个人都编写自己的工作流管理器。 并且有充分的理由。 -* 分布式系统监视非常困难。 异常检测和作图很有帮助。 -* 核心 Hadoop 基础架构（HDFS，YARN）坚如磐石，但较新的工具通常会有细微差别。 -* 卡夫卡很棒。 +观察到两家流量大的网络公司解决了类似的问题之后，我不禁注意到了一系列的创新。 这些问题中有些是困难的，对于每个公司来说，单独解决其问题确实是不幸的。 同时，由于缺乏可靠的开源替代方案，每个公司都不得不解决这些问题。 这显然对一个以快速发展的新兴企业为主导的行业产生了影响，这些行业无法建立 50 人的基础设施开发团队，也无法花数月的时间来构建功能。 -这个网站是关于高可扩展性还是如何浪费服务器？ 您是否真的需要 220 台服务器来服务〜2300req / sec？ +## **更改数据捕获系统** -他了解了其中一些服务器使用情况。 这是 Ruby on Rails，所以这就是原因。 +今天，我想重点介绍一种这样的创新：Change Data Capture 系统 -您能否详细说明“ RabbitMQ 集群不值得付出”？ 您在运行时遇到问题吗？ +关系数据库已经存在很长时间了，已经成为公司所有数据的可靠存储介质。 换句话说，它是公司业务关键数据的真实来源。 通常，数据会从此主要数据存储中提取，转换并存储在辅助数据存储中，例如数据仓库。 该二级存储通常支持推动业务洞察力和方向的数据分析。 在此方案中，这两个存储分别称为 OLTP 存储和 OLAP 存储。 （ [F2](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Footnote_2) ） -@Peter-与其他高可用性站点一样，它们可以使用少于十个服务器来为流量提供服务。 -从文章看来-其余内容涉及（a）收集和分析数据； （b）监督和监督系统； （c）确保高可用性。 -在三个区域中只有 10 台边缘（缓存/ nginx）服务器（由于 HA，30 台独角兽是自然扩展）。 鉴于流量不统一（因此 200M req / day 不能转换为 2300 req / s），这似乎是适中的，因为在任何区域中，请求都只能由几个端点服务器之一来处理。 再次-这就是您在 HA 设置中所期望的-2 个以上的服务器用于任何潜在的传入（请求）请求。 +所有这些已经存在了数十年，那么有什么新东西？ 来自主存储的数据越来越多地用于提供业务决策之外的其他信息。 在 LinkedIn 上，它还提供实时搜索索引，实时网络图索引，缓存一致性，数据库只读副本等。这些都是 LinkedIn 的近实时数据需求的示例。 -我必须同意彼得的观点。 在最近阅读了此处的 Stack Exchange 文章之后，很难不认为此设置会浪费一些资源。 +如果您曾经从事过将数据从主存储转移到辅助存储的工作，那么您无疑会熟悉可用的选项。 -感谢分享。 -您似乎正在使用大量的开源项目。 我对你的决定感到好奇。 团队成员一开始是否已经熟悉大多数技术？ 如果没有，那么在这么多方面加强工作是否有点势不可挡？ +例如，如果您在 OLTP 到 OLAP 的空间中工作，则使用某种 ETL（提取，转换和加载）技术。 这个领域已经看到了围绕工具（，例如，使用 GUI 拖放工具轻松定义转换）和跨供应商集成（，例如从 Oracle 到 Teradata，Aster Data 等）的创新。 .. ）。 该行业通常使用 ETL 进行夜间工作，以使高管可以了解前一天，一周，一个月，一年的业务表现。 -大家好， +如果需要从主数据存储中获取近实时更新流（如下所示）以解决 LinkedIn 的近实时需求，该怎么办？ -Vaidotas，这里的 Vinted 工程师之一。 +![Databus_Use_Cases](img/9d4afc940734b06775db5cf4aa4aeee1.png) -想对服务器数量发表评论。 如果您查看详细信息，将会看到很多服务器专用于分析数据收集。 而且我认为分析数据可能是单独的主题。 +除了昂贵且专有的特定于供应商的产品外，几乎没有其他选择。 -如果您查看运行 Vinted 应用程序所需的服务器及其所有内容，则会看到以下内容： +## **引入数据总线** -34 个用于图像处理和存储（9.3 亿张照片） -30 个用于 Unicorn 和微服务（每天 2 亿个请求） -28 个用于 MySQL 数据库，包括副本 -19 个用于 Sphinx 搜索（2500 万个列出的项 索引） -10，用于可处理的后台作业 -10，用于与 Nginx 进行负载平衡（充当代理和一些缓存，可能会更少，但在我们运营所在的不同国家/地区需要它们）。 -Redis 4 +Databus 是该领域的创新解决方案。 -因此，这就是 135 台运行应用程序基础结构的服务器。 现在请记住，所有内容都必须具有高可用性。 这意味着至少所有内容的 2 倍，即使您目前不需要/不使用它也是如此。 +它具有以下功能： -希望能解释一下服务器数量。 +* Pub-sub 语义 +* 订单内交付保证 +* 源处的提交按事务分组 + * ACID 语义在整个管道中得以保留 +* 支持流分割 + * 然后按分区确定订购保证 +* 像其他消息传递系统一样，为最近发布的消息提供了非常低的延迟消耗 +* 与其他邮件系统不同，它提供任意长的回溯，而不会影响源 +* 高可用性和可靠性 -另外，您的行动小组的规模如何，才能维持这种运营/基础架构？ 仅列出了 SRE。5\. DevOps 工程师，系统管理员和/或 DBA 怎么样？ +## 数据总线如何工作？ -您的 Jenkins 并行化设置似乎很有趣。 你是如何做到的？ 也许不久之后还会有另一篇专门针对此的博客文章？ +数据总线由 3 个重要部分组成： -乔恩，我们有 5 位站点可靠性工程师来维护所有基础架构。 我们执行从服务器引导到数据库管理的所有工作。 我们严重依赖自动化:) +* 继电器 +* 引导程序 +* 客户资料库 -我真正无法理解的是-每天 200 M 的请求如何转换为实际的 Internet 流量？ StackExchange 的请求量为 1.5 亿，在 Alexa 评分中排名第 53，vinted.com 在 38763 上排名较高，但 RPS 较高。 -与 http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html（wix）相同-他们要求 700M 请求/ 一天，但肯定无法将 Alexa 评级与 StackExchange 相比。 +下图显示了 Databus 架构。 数据总线中继将从源数据库（例如 Oracle，MySQL 等... ）（ **步骤 1** ）中拉出最近提交的事务。 中继会将这些数据反序列化为紧凑形式（Avro 等），并将结果存储在循环的内存缓冲区中。 侦听事件的客户端（订户）将拉动最近在线的更改，因为它们出现在中继中（ **步骤 2** ）。 Bootstrap 组件还在监听中继中出现的在线更改。（ **步骤 3** ） -谁能澄清？ +![Databus_Operation](img/d7b71c157addeb8bce27a9854cf6b250.png) -@tao，一开始只有一个开发人员（CEO，联合创始人），而且技术堆栈要小得多。 您的问题的答案是否定的。 +如果订户落在后面，以致其请求的数据不再位于中继的内存缓冲区中，则订户可以请求从过去的时间 T 开始出现的合并增量（ **步骤 4** ）。 这将返回自时间 T 以来发生的所有更改的有效表示。 -当项目开始发展时，出现了一些东西。 我们雇用了更多的开发人员，工程师等。我们选择雇用最聪明的工程师。 之所以使用某些技术是因为他们具有经验，而其他技术则是“试验和错误”（尤其是大数据的东西）。 我们在解决问题的过程中一直在解决它们。 我们仍然有需要解决的问题。 这就是新技术出现的方式。 我相信，一年后，我们可以写一篇关于我们如何做事的文章。 +![Databus_Operation](img/f255cfed148c4910c091f130a49bc609.png) -@lan：RabbitMQ 非常棒，我们正在使用它，但是在分析事件方面，我们遇到了一些限制，因此选择 kafka 作为事件发射。 RabbitMQ 集群的东西很容易破解。 正如文档所述-“ RabbitMQ 群集不能很好地容忍网络分区”，这并不像我们希望的那样罕见。 +如果没有数据集先验知识的新订户要加入聚会，则需要完全引导。 首先，订户的 Databus 客户端库将在过去的某个时间 T 请求一个一致的快照（ **步骤 5** ）。 然后，自该时间 T 起，客户端库将请求合并 Delta（ **步骤 6** ）。 在订阅服务器应用合并增量之后，客户端库将切换为侦听来自中继的联机更改（ **步骤 7** ）。 客户端库帮助订户获得自时间 T 以来的所有更改，时间 T 可以是任意时间点，从而使订户不受更改来源的详细信息的影响。 -@Tim：我们使用 https://github.com/grosser/parallel_tests 的稍加修改版本 +![Databus_Operation](img/69f0bbc5a6594315e3884e18bbad2fe9.png) -@安东：不确定“转换”的含义，但我们为女孩提供了超过 10 Gigs 的流量。 在谈论 Alexa 时，目前我们有 8 个不同的国家，例如，我们的一个国家（http://kleiderkreisel.de）的排名为 7,468，因此没有一个汇总排名。 另一件事是，70％的流量来自移动应用程序，我不确定 Alexa 是否会对此进行计数。 +## **Databus 的自举组件** -希望大家，Vinted 回答了您所有的问题:) \ No newline at end of file +Databus 最具创新性的功能之一是其 Bootstrap 组件。 数据变更捕获系统已经存在了很长时间（，例如 Oracle Streams ）。 但是，当使用者落后时，所有这些系统都会在主数据存储上增加负载。 + +引导一个全新的消费者是另一个问题。 它通常涉及一个非常手动的过程-即在一个临时的 Oracle 实例上恢复前一晚的快照，转换数据并将其传输给使用者，然后应用自快照以来的更改等... + +Databus 的 Bootstrap 组件以无缝，自动化的方式处理上述两个用例。 + +## Databus 的自举组件如何工作？ + +Databus Bootstrap 组件由两种类型的存储组成：日志存储和快照存储。 日志存储服务于合并增量，而快照存储服务于一致的快照。 + +![Databus_Bootstrap](img/45e073fbad31fdbe5e8eba31757bd984.png) + +1. 如前所述，Bootstrap 组件侦听中继中发生的在线更改。 LogWriter 将这些更改附加到日志存储。 +2. 日志应用程序将日志存储中的最新操作应用于快照存储 +3. 如果新订户连接到 Databus，则该订户将从运行在 Bootstrap 组件中的 Bootstrap 服务器进行引导。 +4. 客户端将首先从快照存储中获取一致的快照 +5. 然后，客户端将从日志存储中获得出色的合并增量 +6. 客户端赶上中继的内存缓冲区窗口后，客户端将切换为从中继读取 + +## 数据总线的未来计划 + +Databus 和 Espresso（我们下一个 NoSQL 商店的的工程师，足够说）的团队一直在不懈地努力以支持 Espresso 中的 Databus 复制-Databus 将成为 Espresso 的本机内部复制技术。 此外，一旦团队找到了一些空闲时间，他们将对其进行开源。 + +我们正在寻找在解决棘手问题方面有良好记录的工程师加入我们的 DDS。 如果您有兴趣，可以随时在 [LinkedIn](http://www.linkedin.com/in/siddharthanand) 上 ping 我。 + +## 这对 NoSQL 意味着什么 + +与 Databus 一样酷，它不适用于所有 NoSQL 存储。 当前，许多 NoSQL 技术（尤其是许多 Dynamo 风格的键-值存储）提供的功能集之间存在很大差距。 它们没有提供 Databus 可以提取的时间轴一致的更改流。 + +没有这种支持，将有两个未实现的用例： + +* 支持向现有商业智能基础架构（，即每晚，面向 ETL 的负载）中的出站提要 +* 支持向二级索引（例如搜索，网络图，缓存等）的出站近实时提要... + +最近，对于 Cassandra，Netflix 和 Ooyala 都分别解决了这个问题。 Netflix 发布了一个有关 [Aegisthus](http://techblog.netflix.com/2012/02/aegisthus-bulk-data-pipeline-out-of.html) 的技术博客，该系统将最终一致的数据文件集转换为时间轴一致的流。 该流当前由 Business Intelligence 消耗-它不是实时的，因为它取决于内存刷新间隔。 但是，通过一些调整，它可以接近实时。 我们期待该技术的开源。 + +更重要的是，我们希望 NoSQL 供应商为其产品解决此问题。 + +## 更多资源 + +* [数据基础结构@ LinkedIn](http://www.slideshare.net/r39132/linkedin-data-infrastructure-qcon-london-2012) -QCON London 2012，Sid Anand，LinkedIn 高级会员 +* [数据总线：用于时间线一致的更改数据捕获的系统](http://www.slideshare.net/dtunkelang/databus-a-system-for-timelineconsistent-lowlatency-change-capture) -CIKM 2011，Chavdar Botev，LinkedIn 高级会员 +* LinkedIn 上的 [数据基础结构](http://www-conf.slac.stanford.edu/xldb2011/talks/xldb2011_tue_1005_LinkedIn.pdf)-XLDB 2011，Shirshanka Das，LinkedIn 高级成员 +* [LinkedIn 基础设施](http://qconsf.com/dl/QConSF2007/slides/public/JeanLucVaillant_LinkedIn.pdf) -QCON SF 2007，Jean-Luc Vaillant，LinkedIn 联合创始人兼前首席技术官 + +## 致谢 + +我要感谢构建此系统的工程师们的不懈努力： + +阿迪亚·奥拉德卡（Aditya Auradkar），查夫达尔·博特夫（Chavdar Botev），席尔香卡·达斯（Shirshanka Das），戴夫·德马格（Dave DeMaagd），亚历克斯·费恩伯格（Alex Feinberg），潘宁德拉·甘蒂（Phanindra Ganti），雷·高（Bhaskar Ghosh），基肖尔·戈帕拉克里希纳（Kishore Gopalakrishna），米希尔·甘地（Mihir Gandhi），布伦丹·哈里斯（Broaddan Harris），斯沃洛普·贾加迪什（Swaroop Jagadish），乔尔·科西（Joel Koshy），凯文·克鲁瓦兹（Jay Lua Naga） ，Neha Narkhede，Sasha Pachev，Igor Perisic，Lin Qiao，Tom Quiggle，Jun Rao，Bob Schulman，Abraham Sebastian，Oliver Seeliger，Adam Silberstein，Boris Shkolnik，Chinmay Soman，Subbu Subramaniam，Roshan Sumbaly，Kapil Surlaker，Sajid Topiwala Tran，Balaji Varadarajan，Jemiah Westerman，Zach White，David Zhang，Jason Zhang，Agila Devi，Neil Pinto，Ramana Ramakrishnan，Sai Sundar，Nishant Vyas，Agila Devi，Neil Pinto，Ramana Ramakrishnan，Sai Sundar 和 Nishant Vyas。 + +我还要特别感谢 Bob Schulman，Kapil Surlaker 和 Shirshanka Das 对本文的帮助。 + +## 脚注 + +1. 就快速延迟而言，Netflix 的英国和爱尔兰客户受益于 Netflix 在本地的区域性业务。 如果您不熟悉 AWS 区域，则区域可为最终用户提供地理位置优势。 区域本身由几个数据中心组成，这些数据中心在 AWS 中称为“可用区”。 顾名思义，可用区在托管区域内提供灾难恢复。 对于像网站这样的对延迟敏感的应用程序，跨区域灾难恢复从来都不是一个好主意。 +2. OLTP（在线事务处理）与 OLAP（在线分析处理）：这区分了它们的用途-OLTP 用于主数据服务，OLAP 用于主数据的修改后的副本的分析处理。 + +“ Databus 简介” ...这可用开源吗？ 那将会？ + +我们想开始讨论。 它将很快开源。 人们对此有何看法？ 人们将如何使用它？ 等等... + +我们计划在今年晚些时候开源 Databus。 + +我期待它被开源。 我认为许多人（包括我自己在内）都将使用它从旧版源数据库中将其用于 ETL，在这些旧版源数据库中，架构不太适合加载增量数据集。 那里的商业 CDC 产品（例如 Attunity）使开发人员难以自定义和做出贡献。 我正在研究一种通过对 SQL Server 事务日志进行反向工程来获取 CDC 数据的解决方案，并且很乐意遵循常见的 CDC 抽象。 + +我看到这被用于将交易从关系业务软件数据库中引入并进入多个专用系统-图形数据库，统计平台，HDFS 存储，内存 BI 存储和流数据库-都在同一时间 时间。 我很高兴听到这一消息，因为它是我对商业软件的未来愿景的关键部分。 + +首先，感谢您与我们分享。 + +我对 ETL 方面的理解不够充分，但是我尝试查看 MongoDB 如何适合此方案。 我很可能在这里简化了一些事情，但是请忍受。 :) + +因此，我们都知道有一个常规数据库存储主要数据。 该数据库按顺序发布它的更改，这些更改被捕获并保存在固定大小的缓冲区中，并可供订户使用。 更改的缓冲区定期备份到磁盘上。 打算进行完全同步的新成员可以从备份副本中提取更改。 与订户一起的数据可以被用来导出其他有意义的数据。 + +在我看来，MongoDB 提供了所有这些功能，或者至少提供了构建此类系统的基本基础结构。 + +常规数据库是 MongoDB。 它以 oplog 的形式发布更改-通常是内存映射。 客户端可以打开一个尾部游标到 oplog 集合，并在更改发生时将更改流式传输到数据库中。 客户端可以与作为副本集的一部分安排的辅助 DB 相关联，在该副本集上可以运行 Map-Reduce 或 Aggregation 任务。 辅助服务器之一可以充当“ Bootstrap 服务器”。 （通过执行完全同步，可以从另一个辅助节点启动新的辅助节点）。 特殊辅助节点的操作日志可能类似于“中继”，以避免在主节点上加载。 + +这有道理吗？ MongoDB 是否为此项目进行了评估？ + +任何想法，将不胜感激。 + +OTOH，现在，如果这必须与特定的数据库一起使用，那么每个数据库都将有“ Databus 驱动程序”吗？ 例如，如果必须与 MongoDB 一起使用，则必须有一个 MongoDB 驱动程序，该驱动程序可以理解 MongoDB 发布的 oplog 格式并以通用格式提供给客户端。 + +还是您要发布标准并要求数据库开发人员根据该标准进行更改？ + +再次感谢您。 + +顺便说一句，我也正在等待有关 Espresso 的帖子。 :) + +-婆罗门 + +席德，不错的帖子 在 Yammer，我们正在为近实时搜索做类似的事情。 Databus 看起来更广泛，但是原理相似。 我们正在使用 BDB JE 作为本质上是变更集服务的后备存储。 在更新 ActiveRecord 模型时，Rails 应用程序将更改为变更集服务的信标。 变更集服务为变更建立索引。 另一个服务遍历更改集索引并生成 Lucene 索引。 模型之间存在一些额外的依赖关系，因此，当依赖模型更新时，依赖于该模型的模型将“失效”，因此将其重新索引。 + +我真的很想了解更多信息，并且对开放源代码有所了解。 我们所提供的大部分服务满足了我们的需求，但是绝对可以改善。 + +席德 + +好的帖子，并感谢分享。 我们正在寻求重新发明轮子，以创建与您上面描述的非常相似的东西。 您是否知道何时可以尝试使用这些位？ 我们将非常有兴趣了解更多有关该产品的信息，并看一看开放源代码并在适用的情况下做出贡献。 + +我试图找到有关中继如何将已提交的更改从数据库中拉出的详细信息。 +是否有任何视频或文档对此进行了详细说明？ +据我了解，今天它已在 Oracle 上使用。 该技术是否取决于特定的 Oracle 功能，或者可以在“通用” RDBMS 上实现？ + +Databus Relay 可以从 MS SQL Server（源数据库）中提取事务。 \ No newline at end of file diff --git a/docs/89.md b/docs/89.md index 9015aa4..d65c2ec 100644 --- a/docs/89.md +++ b/docs/89.md @@ -1,202 +1,136 @@ -# AWS 的惊人规模及其对云的未来意味着什么 - -> 原文： [http://highscalability.com/blog/2015/1/12/the-stunning-scale-of-aws-and-what-it-means-for-the-future-o.html](http://highscalability.com/blog/2015/1/12/the-stunning-scale-of-aws-and-what-it-means-for-the-future-o.html) - -![](img/9507f1ccc471853c743c9069de138100.png) - -[James Hamilton](http://www.mvdirona.com/jrh/work/) ，亚马逊副总裁兼杰出工程师，以及[博主](http://perspectives.mvdirona.com/)长期从事有趣的话题，在 [AWS 上进行了热情洋溢的演讲：](https://reinvent.awsevents.com/) [AWS 创新规模](https://www.youtube.com/watch?v=JIQETrFC_SQ) 上的 Invent 2014 。 他显然为他们正在做的工作感到自豪，这表明了。 - -James 分享了有关 AWS 的一些惊人数据： - -* 1 百万活跃客户 -* 所有其他 14 个云提供商的总和是 AWS 总容量的 1/5（2013 年 Gartner 估计） -* 2014 年发布了 449 种新服务和主要功能 -* 作为一家年收入达 7 亿美元的企业（2004 年），AWS 每天都会增加足够的新服务器容量来支持亚马逊的全球所有基础架构。 -* S3 的数据传输同比增长 132％ -* 数据中心的网络容量为 102Tbps。 - -演讲的主题是云是一个不同的世界。 这是一个特殊的环境，允许 AWS 大规模地做伟大的事情，而您做不到的事情，这就是为什么从内部 x86 服务器到公共云的过渡正以惊人的速度发生的原因。 公有云具有如此众多的规模驱动优势，这是无法停止的过渡。 云将以您无法开始与有限资源，通才装备，膨胀的软件堆栈，缓慢的供应链和过时的创新范式匹配的速度，变得越来越可靠，功能更多，价格更低。 - -至少是 PR 消息。 但是您可以说的关于亚马逊的一件事就是他们正在生活。 他们使它成为现实。 因此，一个健康的怀疑是健康的，但推断命运的界限也是明智的。 - -AWS 拥​​有命运决定权的多变之一是资源。 在拥有一百万个客户的情况下，他们有足够的规模来保持扩展和改善的动力。 利润没有被提取出来，金钱被重新投资了。 这也许是规模最重要的优势。 - -但是没有聪明人的钱简直就是浪费。 亚马逊希望您知道他们有聪明人。 我们听说过 Google 和 Facebook 如何建立自己的设备，亚马逊也是如此。 他们构建了自己的网络设备，网络软件，机架，并且与 Intel 合作获得了比市场上更快的处理器版本的处理器。 关键是他们对环境一无所知，并且可以控制一切，因此他们可以制造出更简单的设备来实现自己想要的功能，从而最终变得更便宜，更可靠。 - -完全控制允许将质量指标内置到所有内容中。 指标推动系统各个部分的质量不断提高，这就是为什么在创新步伐加快的情况下，AWS 变得更加可靠的原因。 大量可操作的数据转化为知识是规模的另一个巨大优势。 - -AWS 不能做的另一件事是可用区架构本身。 每个可用区都是其自己的数据中心，一个区域内的可用区非常靠近。 这减少了消息传递延迟，这意味着可以在 AZ 之间同步复制状态，与冗余数据中心相距甚远的典型方法相比，这可以大大提高可用性。 - -这是一次充满信息的演讲，而且……实在太夸张了。 演讲的真正元主题是亚马逊如何有意识地利用规模来获得竞争优势。 对于亚马逊来说，扩展规模不仅是要花的钱，如果您知道如何扩展规模，它就是一种资源。 - -这是詹姆斯·汉密尔顿令人难以置信的谈话的掩饰... - -## 对话中的所有内容都具有规模 - -* 当 AWS 成为年收入 7B 的企业（2004 年）时，每天都会增加足够的新服务器容量来支持 Amazon 的所有全球基础架构。 - -* 一年 365 天，组件制造商必须与服务器和存储制造商联系，服务器和存储制造商必须生产齿轮并将其推入物流渠道，必须将其从物流渠道转移到正确的数据中心 ，它必须到达装货平台，人们必须在那里将机架轮到 DC 中的正确位置，必须有电源，散热，网络连接，必须加载应用堆栈，必须进行测试 ，它必须发布给客户。 - -* S3 使用率：数据传输量同比增长 132％； EC2 使用量：使用量同比增长 99％； AWS 的整体业务：超过一百万的活跃客户。 - -* 所有其他 14 个云提供商的总和是 AWS 总容量的 1/5（Gartner 在 2013 年估计） - -* 拥有超过一百万的客户，这意味着您处于一个丰富的生态系统中。 您可以选择软件供应商，如果您以前遇到过别人可能遇到的问题，则可以更快地完成工作。 - -* 如此高的增长速度意味着亚马逊拥有资源，可以通过增加其提供的服务的广度和深度来继续进行再投资和创新。 - -* 通常，经济效益要好得多时，例如从大型机到 UNIX 服务器，然后从 UNIX 服务器到 x86 服务器，就会发生大的转变。 这些过渡通常需要 10 年以上的时间。 x86 本地迁移到云的不同之处在于它发生的速度。 云迁移的速度是具有很高的经济价值的功能，而且采用的摩擦也很低。 您不需要软件，不需要硬件，就可以做到。 - -## 联网中存在较大的成本问题 - -* 联网是整个行业的红色预警情况。 这是一场完美的风暴。 - -* **问题 1** ：相对于所有其他设备的成本，网络成本正在不断上升。 这是反摩尔定律。 所有其他设备的成本都在下降，随着时间的流逝，网络变得越来越昂贵。 每月相对费用：服务器：57％； 网络设备：8％； 功率分配和冷却：18％； 功率：13％; 其他：4％。 - -* **问题 2** ：在网络变得越来越昂贵的同时，网络与计算的比率也在上升。 部分原因是摩尔定律在服务器上仍在起作用，并且计算密度也在不断提高。 部分原因是，随着计算成本的下降，执行的高级分析数量将增加，并且分析需要占用大量网络资源。 解决使用大量服务器的大问题需要大量的网络。 网络流量已向东西方向移动，而不是传统的 [南北方向](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) 。 - -* 5 年前，Amazon 的解决方案是数据驱动的并且是激进的：**他们根据自己的网络设计**构建。 建立了特殊路由器。 雇用了一个团队来构建协议栈，一直到顶部。 他们自己将所有这些都部署在了网络中。 全球所有服务都在此设备上运行。 - - * **这种策略原来便宜得多**。 仅网络设备的支持合同就花费了数千万美元。 - - * **可用性提高了**。 改进的来源是简单性。 AWS 试图解决的问题比企业齿轮要解决的问题更简单。 企业设备必须遵守许多未使用的复杂规范，只会使系统更加脆弱。 仅实现所需的功能就意味着可以简化系统，从而提高可用性。 任何取胜的方法都是取胜的好方法。 - - * **指标**的聚宝盆。 他们衡量一切。 规则是，如果客户在使用他们的系统时体验不好，他们的指标必须显示出来。 这意味着指标一直在提高，因为客户问题推动了指标的提高。 一旦有了可以准确反映客户体验的指标，就可以设定目标，以使系统变得更好。 每周都会进行改进，以使事情变得更好。 如果代码起步不好，那么随着时间的推移它就会变得更好。 - - * **可测试性**。 他们的装备更好，因为他们进行了更好的测试。 企业级设备很难进行大规模测试。 他们创建了一个耗资 4000 万美元的测试平台，其中包含 8000 台服务器（3 兆瓦）。 但是由于这是云，他们有效地租用了几个月的服务器，因此价格相对便宜。 - -## 从最上层到网络接口卡的逐层网络解释 - -### AWS 全球网络骨干 - -* 全球 11 个 AWS 区域。 根据与客户的接近程度或所需的管辖范围选择要使用的那些。 - -* 专用光纤链路将大多数主要区域互连。 这样可以避免所有容量规划问题（Amazon 可以进行更好的容量规划），对等问题以及在公共链接上发生的缓冲问题。 因此，运行自己的网络速度更快，更可靠，更便宜且延迟更短。 - -### 示例 AWS 区域（美国东部（（弗吉尼亚北部）） - -* 所有区域至少都有两个可用区。 美国东部有五个可用区。 - -* 冗余路径通向运输中心。 - -* 每个区域都有冗余的运输中心。 转运中心将专用链接连接到其他 AWS 区域，将专用链接连接到 AWS Direct Connect 客户，并通过对等和付费转接连接到 Internet。 - -* 如果一个可用区发生故障，所有其他可用区继续工作。 - -* 可用区之间的城域 DWDM 链接 - -* 区域中有 82,864 根纤维束 - -* AZ 间隔小于 2ms，通常间隔小于 1ms。 从等待时间的角度来看，它们在几公里之内非常接近。 相隔足够远以确保安全，相隔足够远以获得良好的延迟。 - -* 可用区之间的峰值流量为 25Tbps - -* AWS 提供可用区，因为： - - * 使用单个加固的数据中心，您将获得的最佳可靠性约为 [99.9％](http://en.wikipedia.org/wiki/High_availability) 。 高可靠性要求在两个数据中心中运行。 传统上，数据中心的多样性来自相距很远的两个数据中心，因为保持数据中心相互靠近的成本效益不高。 这意味着更长的等待时间。 LA 到 NEW 是往返 74ms。 提交给 SSD 的时间为 1 到 2 毫秒。 您不能等待 70 毫秒以上的时间才能提交交易。 这意味着应用程序在本地提交，然后复制到第二个数据中心。 在故障情况下，这种设计会在故障转移期间丢失数据。 尽管真正的故障很少发生，例如建筑物烧毁，但瞬态故障更常​​见，例如负载平衡器问题。 那么，您是否会在 3 分钟内对您的连接进行故障转移？ 不可以，因为数据将丢失，并且需要很长时间才能从其他来源恢复该数据。 因此，您将失去常见事件的可用性。 - - * 可用区间隔为毫秒，因此您可以同时提交两个可用区。 这意味着，如果您进行故障转移，则由于数据复制是同步的，客户将无法得知。 它是不可见的。 很难为该模型编写代码，因此您不会为所有事情做到这一点。 对于某些应用程序，对多可用区故障的担心也可能会阻止您使用多个可用区，但是对于其余应用程序，这是一个非常强大的模型。 成本更高，但是它为 AWS 提供了某些优势。 - -### 示例 AWS 可用区 - -* 可用区始终是完全独立的建筑物中的数据中心。 - -* 亚马逊拥有 28 多个数据中心。 加号表示 AZ 中有更多数据中心，作为扩展 AZ 能力的一种方式。 在可用区中添加了更多数据中心以扩展可用区的容量。 否则，即使您不想这样做，也将不得不将应用程序划分为多个可用区。 - -* 一些可用区具有相当大的数据中心大小。 - -* AZ 中的 DC 间隔小于 1/4 毫秒。 - -### 示例数据中心 - -* AWS 数据中心故意不是巨大的。 单个数据中心的功率为 25-30 兆瓦，具有 50,000-80,000 台服务器 - -* 数据中心规模的回报减少。 随着您构建的规模越来越大，数据中心扩展的优势下降了。 早期的优势是巨大的。 后来的优势很小。 从 2000 机架增加到 2500 机架要好一些。 一个很小的数据中心太昂贵了。 真正的大型数据中心仅比机架中型数据中心贵一点。 - -* 数据中心越大，风险越大。 爆炸半径如果出现问题并破坏了数据中心，则损失太大。 - -* 到数据中心的网络容量为 102Tbps。 - -### 机架示例，服务器& NIC - -* 唯一重要的延迟是连接两端的软件延迟。 发送消息时，两个服务器之间的延迟： - - * 您的应用->来宾操作系统->虚拟机管理程序-> NIC：延迟为毫秒 - - * 通过网卡：延迟为微秒 - - * 光纤上的：等待时间为纳秒 - -* SR-IOV（ [单根 I / O 虚拟化](http://www.redbooks.ibm.com/abstracts/redp5065.html?Open) ）允许 NIC 在硬件网卡中提供虚拟化。 每个来宾都有自己的网卡。 好处是>平均延迟减少 2 倍，>延迟抖动增加 10 倍。 这意味着离群值下降到原来的 1/10。 SR-IOV 现在正在新的实例类型上部署，并且最终将在任何地方使用。 困难的部分不是添加 SR-IOV，而是添加了隔离，计量，DDoS 保护以及容量限制，这使得 SR-IOV 在云环境中很有用。 - -## AWS Custom Server &存储设计 - -* 负面情况的成本不高，因此可以取消昂贵的不需要的保护。 服务器是针对其功能而设计的，而不是针对一般用户。 亚马逊确切地知道服务器将在什么环境中运行，他们会确切地知道何时出现问题，因此可以在设计时减少工程空间。 对于他们来说，服务器故障的代价并不是很大。 它们已经在现场，并且非常擅长更换硬盘等。因此，企业设备中的许多注意事项都是不必要的。 - -* **可以用力推动处理器**。 他们知道散热要求，影响机械设计，他们只是设计好的服务器，因此可以从服务器中获得更多性能。 尽管与英特尔亚马逊的合作关系使处理器的运行速度比在公开市场上购买的处理器要快。 - -* 例如，他们自己的储物架设计。 它重达一吨，宽 19 英寸，可容纳 864 个磁盘驱动器。 对于某些工作负载而言，这是一款出色的改变游戏规则的设计，可帮助他们在某些地区获得更高的价格。 - -## 电源基础架构 - -* 亚马逊已经设计并建造了自己的变电站。 它只节省一点钱，但是他们可以更快地构建它们。 公用事业公司不习惯应对 AWS 的增长速度，因此他们不得不自己建立。 - -* 3 个 100％碳中和地区：美国西部（俄勒冈州），AWS GovCloud（美国），欧盟（法兰克福） - -## 创新的快节奏 - -* 2014 年发布了 449 个新服务和主要功能。2008 年为 24 个，2009 年为 48 个，2010 年为 61 个，2011 年为 82 个，2012 年为 159 个，2013 年为 280 个。 - -* 随着创新步伐的加快，AWS 变得越来越可靠。 他们的目标是向客户提供与实现这种创新速度和高质量相同的工具。 +# 在 30 分钟内进行 7 年的 YouTube 可扩展性课程 + +> 原文： [http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html](http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html) + +![](img/037ab09a00de464dc99a6ba677f01263.png) + +如果您开始建立约会网站，而最终建立了每天处理 40 亿次观看次数的视频共享网站（YouTube），那么您可能会在此过程中学到一些东西。 确实，YouTube 的原始工程师之一 Mike Solomon 确实学到了很多东西，他在 [PyCon](https://us.pycon.org/2012/) ： [在 YouTube 上的可扩展性上做了演讲](http://www.youtube.com/watch?v=G-lGCC4KKok) 。 + +这不是架构驱动的讨论，我们将通过介绍许多盒子相互连接的方式进行介绍。 迈克可以这样讲。 他致力于建立 YouTube 的 Servlet 基础结构，视频索引功能，视频转码系统，全文搜索，CDN 等。 但是，相反，他退后了一步，仔细研究了工作时间，并分享了一些深刻的经验教训，这些经验教训显然是来之不易的。 + +对我来说，要讲的主要内容是使用非常简单的工具完成了**。 尽管许多团队都在转向更复杂的生态系统，但 YouTube 确实做到了简单。 他们主要使用 Python 进行编程，使用 MySQL 作为其数据库，他们一直使用 Apache，甚至对于一个如此庞大的站点来说，新功能都始于非常简单的 Python 程序。 + +这并不意味着 YouTube 不会做酷的事情，而是做的，但是使所有事情协同工作的更多的是哲学或做事方式，而不是技术专长。 是什么使 YouTube 成为世界上最大的网站之一？ 继续阅读并查看...** + +## 统计信息 + +* 每天 40 亿次观看 +* 每分钟上传 60 个小时的视频 +* 350+百万台设备启用了 YouTube +* 2010 年收入翻了一番 +* 视频的数量增加了 9 个数量级，而开发人员的数量仅增加了 2 个数量级。 +* 一百万行 Python 代码 + +## 堆栈 + +* **Python-** YouTube 的大部分代码行仍在 Python 中。 每次观看 YouTube 视频时，您都在执行一堆 Python 代码。 +* **Apache** -当您认为需要摆脱它时，则不需要。 Apache 是​​YouTube 上真正的摇滚明星技术，因为它们保持了简单。 每个请求都通过 Apache。 +* **Linux** -Linux 的好处是总有一种方法可以进入并查看您的系统运行情况。 无论您的应用程序表现多么糟糕，您都可以使用 strace 和 tcpdump 之类的 Linux 工具对其进行查看。 +* **MySQL** -使用很多。 观看视频时，您正在从 MySQL 获取数据。 有时它使用关系数据库或 Blob 存储。 这是关于调整和选择组织数据的方式。 +* [**Vitess**](http://code.google.com/p/vitess/) -YouTube 发布的新项目，用 Go 编写，它是 MySQL 的前端。 它动态地进行了很多优化，它重写查询并充当代理。 目前，它可以处理每个 YouTube 数据库请求。 它基于 RPC。 +* **Zookeeper** -分布式锁定服务器。 用于配置。 真正有趣的技术。 难以正确使用，因此请阅读手册 +* **Wiseguy** -一个 CGI Servlet 容器。 +* **Spitfire** -一个模板系统。 它有一个抽象的语法树，让他们进行转换以使处理更快。 +* **序列化格式** -无论使用哪种格式，它们都非常昂贵。 测量。 不要用泡菜 不是一个好选择。 找到的协议缓冲区很慢。 他们编写了自己的 BSON 实现，比您可以下载的实现快 10-15 倍。 + +## 一般课程 + +* YouTube 的 **Tao** ：选择最简单的解决方案，并附带最实际的保证。 您需要所有这些东西的原因是您需要灵活性来解决问题。 在您指定的那一刻，您就会把自己粉刷成一个角落。 您不会做出这些保证。 尝试做出所有这些保证时，您的问题会自动变得更加复杂。 您不会离开自己。 +* **整个过程就是**的可伸缩性。 可扩展的系统是您所无法企及的。 您没有意识到。 这不是流行语。 这是解决精神问题的一般问题。 +* **大型系统设计的标志**：每个系统都是根据其特定要求量身定制的。 一切都取决于构建的细节。 +* **YouTube 不是异步的**，所有内容都处于阻塞状态。 +* **相信哲学胜于教义**。 简单点。 那是什么意思？ 当您看到它时，您就会知道。 如果执行代码检查会更改数千行代码和许多文件，则可能是一种更简单的方法。 您的第一个演示应该很简单，然后进行迭代。 +* **解决一个问题：一个字-简单**。 寻找最简单的方法来解决问题空间。 有很多复杂的问题，但是第一个解决方案并不需要复杂。 随着时间的流逝，复杂性自然会到来。 +* **许多 YouTube 系统都是从一个 Python 文件**开始的，并在许多年后变成了大型生态系统。 他们所有的原型都是用 Python 编写的，并且存活了惊人的时间。 +* **在设计审查**中： + * 什么是第一个解决方案？ + * 您打算如何迭代？ + * 我们对该数据将如何使用了解多少？ +* **事情随时间而变化**。 YouTube 如何起步与以后发生的事情无关。 YouTube 最初是一个约会网站。 如果他们为此设计，他们将有不同的对话。 保持灵活性。 +* **YouTube CDN** 。 最初是外包出去的。 非常昂贵，所以他们自己做。 如果您有不错的硬件伙计，则可以构建一个不错的视频 CDN。 您建立了一个非常大的机架，将机器插入其中，然后进行 lighttpd 处理，然后覆盖 404 处理程序以查找未找到的视频。 这花了两个星期的时间，而且第一天的服务量为 60 吉比特。 使用非常简单的工具，您可以做很多事情。 +* **您必须测量**。 Vitess 换出了一个协议来进行 HTTP 实现。 即使在 C 语言中，它的速度也很慢。 因此，他们剥离了 HTTP 并使用 python 进行了直接套接字调用，这在全局 CPU 上便宜了 8％。 HTTP 的封装确实非常昂贵。 + +## 可扩展性技术 + +* 这些不是新主意，但令人惊讶的是，一些核心主意如何在许多不同的方面得到应用。 +* **分而治之-可伸缩性技术** + * 这是可伸缩性技术。 一切都是关于划分工作。 确定如何执行它。 从 Web 层开始，适用于许多事物，您拥有许多 Web 服务器，这些 Web 服务器或多或少完全相同且独立，并且可以水平扩展它们。 那是分而治之。 + * 这是数据库分片的关键。 您如何划分内容，并在细分的部分之间进行交流。 这些是您想尽早解决的事情，因为它们会影响您的成长方式。 + * 简单而松散的连接确实很有价值。 + * Python 的动态特性在这里是一个胜利。 不管您的 API 有多糟糕，您都可以存根或修改或修饰自己的方式来解决许多问题。 +* **近似正确性-稍作弊** + * 另一个喜欢的技术。 系统的状态就是它所报告的状态。 如果用户不能告诉系统的一部分是歪斜和不一致的，那不是。 + * 一个真实的例子。 如果您写评论，但有人同时加载该页面，则他们可能会在 300-400 毫秒内没有收到该评论，正在阅读的用户将不在乎。 评论的作者会在意，因此您确保撰写评论的用户会看到它。 所以你有点作弊。 您的系统不必具有全局一致的交易记录。 那将是非常昂贵和过度的。 并非每条评论都是金融交易。 所以知道什么时候可以作弊。 +* **专家旋钮切换** + * 问，您对一致性模型了解多少？ 对于评论的最终一致性是否足够好？ 租电影是不同的。 租房时有钱，所以我们会尽力做到永不丢失。 根据数据需要不同的一致性模型。 +* **抖动-向系统中添加熵** + * 始终是他们小组中的热门词。 如果您的系统没有抖动，那么您会得到 [雷电群](http://highscalability.com/blog/2008/3/14/problem-mobbing-the-least-used-resource-error.html) 。 分布式应用程序实际上是天气系统。 调试它们与确定天气一样具有确定性。 抖动引入了更多的随机性，因为令人惊讶的是，事情趋于堆积。 + * 例如，缓存过期。 对于流行视频，他们会尽其所能地缓存内容。 他们可能会缓存 24 小时的最受欢迎的视频。 如果所有内容一次到期，则每台计算机将同时计算到期时间。 这产生了一个雷电群。 + * 抖动表示您在 18-30 小时之间随机失效。 这样可以防止事情堆积。 他们在各处使用它。 当操作排队并试图破坏自身时，系统倾向于自我同步。 令人着迷的观看。 一台计算机上的磁盘系统运行缓慢，每个人都在等待一个请求，因此所有其他计算机上的所有其他请求突然之间完全同步。 当您有很多机器并且有很多事件时，就会发生这种情况。 每个人实际上都从系统中删除了熵，因此您必须重新添加一些熵。 +* **作弊-知道如何伪造数据** + * 很棒的技术。 最快的函数调用是不会发生的。 当您拥有一个单调递增的计数器（例如电影观看次数或个人资料观看次数）时，您可以在每次更新时进行一次交易。 或者，您可以不时进行一次交易，并随机更新一次，只要交易从奇数变为偶数，人们可能会认为这是真实的。 知道如何伪造数据。 +* **可扩展组件-自己创造运气** + * **您可以查看一个 API 并获得良好的感觉**。 输入是否定义明确？ 你知道你要出去吗？ 其中很多最终都与数据有关。 严格说明每个函数将输出什么数据以及它如何流动，实际上可以帮助您在没有文档的情况下理解应用程序。 您可以分辨出在调用函数之前和之后发生的情况。 + * **在 Python 中，事情倾向于向 RPC** 发展。 代码的结构基于程序员的纪律。 因此要建立良好的约定，当所有其他方法都失败时，就会出现 RPC 隔离墙，以便您了解其中的内容和结果。 + * **您的组件将不完美**。 知道，一个组件可能会持续一个月或六个月。 通过画出这些线条，您正在自己赚一些钱。 当事情发展到南方时，您可以将其换成其他东西。 有时用 python 和 C 重写某些内容，有时则意味着完全摆脱它。 直到您能够观察到，您才知道。 + * **团队中有这么多人，没人知道整个系统**，因此您需要定义组件。 这是视频转码，与视频搜索不同。 您需要定义明确的子组件。 好的软件设计。 这些事情最终导致彼此交谈，因此拥有一个良好的数据规范将很有帮助。 他最大的罪过是 Servlet 层和模板层之间的通信，使之成为字典。 好主意。 应该添加一个 WatchPage 并说一个观看页面有一个视频，一些评论和一些相关视频。 这引起了很多问题，因为字典可以具有数百个属性。 他们并不总是做出正确的选择。 +* **效率-以可扩展性为代价** + * **效率是以可伸缩性** 为代价的。 最有效的方法是用 C 编写并将其塞入一个进程，但这是不可扩展的。 + * **关注宏级别** **，您的组件以及它们如何分解**。 将此做为 RPC 还是以内联方式有意义？ 将其分成一个子包，就可能有一天可能会有所不同。 + * **关注算法** 。 在 Python 中，实现良好算法的工作量很低。 例如，有 bisect 模块，您可以在其中获取列表，做一些有意义的事情，并将其序列化到磁盘上，然后再次读回。 对 C 有罚款，但这很容易。 + * **测量** 。 在 Python 中，测量就像阅读茶叶一样。 Python 中有很多与直觉相反的东西，例如抓斗成本。 他们的大多数应用程序都花时间进行序列化。 对序列化进行概要分析非常取决于您要插入的内容。对 int 进行序列化与对大 blob 进行序列化有很大不同。 +* **Python 的效率-知道不该做什么** + * **有关了解不要做什么的更多信息** 。 您制作事物的动态程度与运行 Python 应用程序的昂贵程度相关。 + * **Dummer 代码更易于 grep 且易于维护** 。 代码越神奇，就越难弄清楚其工作原理。 + * **他们并没有做很多 OO** 。 他们使用很多命名空间。 使用类来组织数据，但很少用于 OO。 + * **您的代码树是什么样的？** 他希望用以下词语来形容它：简单，实用，优雅，正交，可组合。 这是一个理想，现实有点不同。 ## 相关文章 -* 在[黑客新闻](https://news.ycombinator.com/item?id=8875549)上/在 [reddit](http://www.reddit.com/r/programming/comments/2s6nf6/the_stunning_scale_of_aws_and_what_it_means_for/) 上 - -* James Hamilton 的 [博客](http://perspectives.mvdirona.com/) 以及其他 [讨论和幻灯片](http://mvdirona.com/jrh/work/) - -* [深入了解 AWS 的大规模规模](http://www.enterprisetech.com/2014/11/14/rare-peek-massive-scale-aws/) 和 [，有关黑客新闻](https://news.ycombinator.com/item?id=8643248) / [on reddit](http://www.reddit.com/r/programming/comments/2n5p8c/a_rare_peek_into_the_massive_scale_of_aws/) - -* [十亿个数据包生命中的一天](https://www.youtube.com/watch?v=Zd5hsL-JNY4) +* [使用 Python 调整 YouTube 大小](http://www.slideshare.net/didip/super-sizing-youtube-with-python) +* [扩展 Web 的 MySQL 数据库](http://www.percona.com/live/mysql-conference-2012/sessions/scaling-mysql-databases-web) +* [YouTube 架构](http://highscalability.com/youtube-architecture) +* [关于 HackerNews](http://news.ycombinator.com/item?id=3757456) -* [亚马逊如何以及为什么进入云计算业务？](http://www.quora.com/How-and-why-did-Amazon-get-into-the-cloud-computing-business) +不错。 可以使用一些校对方法，因为我不得不在某些语言被弄乱的地方放慢脚步，例如“那些东西你想早点弄清楚，因为它们会影响你的成长方式。” 否则，有趣的阅读使我想给 python 多一点关注。 -轻微错字。 “到数据中心的 10Tbps 网络容量。” 它应显示为“到数据中心的 102Tbps 网络容量”。 参考：https：//www.youtube.com/watch？v = JIQETrFC_SQ（26:40） +嗯，但公平地说，YouTube 使用 lighttpd 吗？ 通过萤火虫：http://i.imgur.com/ClSH4.png -更正，谢谢乔尔 +“ Apache 是​​YouTube 上真正的摇滚明星技术，因为它们使它保持简单。每个请求都通过 Apache 进行。” -还有“每周 365 天零件制造商”-我认为应该是“一年 365 天” ...？ +“您建立了一个非常大的机架，将机器插入其中，然后进行 lighttpd” -已更正，谢谢 Krys。 我读了十遍，每次都错过了。 +如果 Apache 很棒，为什么他们选择 lighttpd 代替呢？ -只是澄清一下，Gartner 的确切报价是：“ AWS 是压倒性的市场领导者，使用的计算能力是其他 14 家提供商的总和的五倍多”，并且在 2013 年。情况可能已经发生变化。 自 2013 年以来，随着 Azure 和 App Engine 的增长， +这是否还意味着“每个请求都通过 Apache”的语句不正确？ -来源： [http://www.theregister.co.uk/2013/08/19/amazon_gartner_magic_quadrant/](http://www.theregister.co.uk/2013/08/19/amazon_gartner_magic_quadrant/) +好文章。 还有一些 UX 良好做法。 -“ spunk”是在池塘的这一侧具有完全不同含义的单词之一。 也许要避免:) +@ Michal，@ Andy：这些语句是在 CDN 的上下文中的，因此您可以假定它们意味着 CDN 将 lighttpd 用于静态内容，而将 Apache 用于其余内容。 -关于“快速创新步伐”的注释很有趣，因为尽管 AWS 每周发布新功能（有时还发布服务），但我们发现所发布的内容缺乏质量。 +前 YouTuber 在这里... -我们不断有大量的公开支持案例，其中发现了我们使用的服务中的错误。 让 AWS 确认问题的存在通常很痛苦，然后要花几周甚至几个月才能解决问题。 有时这些问题似乎很关键，有时很烦人。 +Apache 是​​他们处理动态 Web 请求的方式。 主页，观看页面，用户页面等。在早期，视频流媒体，视频上传者和图像上传者在 Lighthttpd 上运行，因为它能够更好地处理非交互式数据流。 -如果我们不订阅他们的支持产品，我不确定如何获得答案。 +当我两年多前离开时，他们正处于将大多数视频流切换到基于 Google 的基础架构的过程中，因为 Google 基础架构具有对等协议和更高的带宽成本。 在此过程中，他们似乎决定保留旧的视频流，并将其用于静态内容服务（Lighthttpd 做得很好）。 -很多时候，即使我不得不承认该部分是值得商—的，功能似乎也没有经过深思熟虑，这可能是过早发布，经常发布的情况。 +顺便提及，随机更新事物最近已获得专利。 -最重要的是，我宁愿看到不太快速的创新，而将重点放在提供稳定的基础架构服务上。 稳定地说，我并不是在指 EC2 的普遍可用性（我同意这要好得多），而是要提供更多的质量保证和更快的错误修复时间。 +@michal @andy，听起来好像 apache 是​​他们的 Web 服务器，而 lighttpd 驱动了 CDN，因此在外部您会收到 lighttpd 标头，但 apache 确实在做这项工作。 -精彩演讲的精彩文章。 感谢您编写它，它给了我时间慢慢进行所有操作，总的来说，这真是令人印象深刻:) +作为对 YouTube 的致敬，您可以将其制作成 30 分钟的视频吗？ 大声笑 -嘿，您可能希望对本文进行快速的复制编辑，因为其中有很多语言/语法故障，使您分心。 除此之外，还不错的文章。 在公开发布它并从 reddit 之类的站点进行链接之前，只需确保您已经通过了一个不错的复制编辑器。 +您可以同时使用 apache 和 lighttpd 来实现目标。 如果这篇文章更详细地解释每一个 YouTube 服务的内容，那将是很好的。 看起来.ligspd 至少提供了.css 文件，这是其静态内容。 -你能举个乔纳森的例子吗？ 这比一般的批评更有帮助。 文本特意简短且断断续续，以供快速浏览，这是一种样式选择，它不是典型的文章格式，因此为简洁起见，经常会忽略语法。 在我的网站上只有我一个人，所以我成为了自己的副本编辑器，所以有时我会犯错。 +“ YouTube 不是异步的，一切都在阻塞。” 为什么？ 我以为大家都同意，最好的办法就是去医院。 -如今，您自己的专用服务器 8GB RAM 2TB 磁盘的价格每月不到 30 美元，而类似的 Amazon 机器则要贵 6 倍。 除了超成功的创业公司的微不足道的优势（可能需要在一小时内购买 100 台机器）外，没有任何优势。 +也许它可以防止出现错误： +“所有形式的异步 I / O 都会打开应用程序，直至出现潜在的资源冲突和相关的故障。需要仔细的编程（通常使用互斥，信号量等）来防止这种情况。” -这很令人着迷，但我也对许多普通用户的成本效益表示怀疑。 我有客户在亚马逊上花费数万美元，并在亚马逊之上构建服务，这些服务可以复制到机架中拥有的设备成本的十分之一。 这些是有利可图的服务，具有可观但可预测的流量，并且并没有疯狂增长。 甚至那个 Facebook 游戏公司都说他们在亚马逊上发布，但是一旦游戏达到可预测的增长曲线，他们就会转向拥有的便宜基础设施。 现在，您可以在低功耗但完全适合典型 Web 工作负载的商品消费硬件上使用开源资源构建类似 AWS 和 Heroku 的私有功能……甚至还可以获取每个节点都被视为一次性使用的 HA 功能。 如果正确地构建自己的东西，则可以通过这些公共云服务节省大量资金。 +资料来源：http://en.wikipedia.org/wiki/Asynchronous_I/O -> >如果正确构建架构，则可以通过这些公共云服务节省大量资金。 +谈到简单而可靠的工具：Youtube 什么时候切换到 PostgreSQL？ -是的，不是，如果您像迅猛发展一样，并且/或者计算需求出现非常不可预测的高峰和下降，那么除非您想拥有数十台或数百台服务器，否则您可能无法以更低的价格或足够快的速度进行调整 ，未充分利用大量时间，因此您有足够的能力来满足这些需求。 +感谢您的出色总结！ -另一方面，如果您的工作负载处于稳定状态，则只要没有问题，就可以节省一些钱。 只要确保您正在比较苹果之间。 不要将您拥有的 10 个服务器放在一个区域内的数据中心中，与在全球范围内分布在具有独立电源，冗余连接路径的多可用性区域中的 10 台服务器相同，如果架构正确， 可以在几分钟内将容量翻倍，翻倍或翻倍。 \ No newline at end of file +哇，什么是“夏季代号”？ \ No newline at end of file diff --git a/docs/9.md b/docs/9.md index 466f145..7363372 100644 --- a/docs/9.md +++ b/docs/9.md @@ -1,101 +1,116 @@ -# 为何将 Morningstar 迁移到云端：降低 97％的成本 +# 维基媒体架构 -> 原文： [http://highscalability.com/blog/2017/8/14/why-morningstar-moved-to-the-cloud-97-cost-reduction.html](http://highscalability.com/blog/2017/8/14/why-morningstar-moved-to-the-cloud-97-cost-reduction.html) +> 原文： [http://highscalability.com/blog/2007/8/22/wikimedia-architecture.html](http://highscalability.com/blog/2007/8/22/wikimedia-architecture.html) -![](img/8afe9df981fbc1c7bfcea8286c1586d5.png) +Wikimedia 是建立 Wikipedia，Wiktionary 和其他七个 Wiki 矮人的平台。 对于试图扩大巨型网站高度的学生而言，该文档非常有用。 它充满了详细信息和创新思想，这些思想和创新思想已在互联网上一些最常用的网站上得到证明。 -企业不会迁移到云。 如果他们这样做，那就等于承认您的 IT 团队很糟糕。 那是常识。 投资研究提供商晨星（Morningstar）正在迁移到云中，他们正变得越来越有企业精神。 他们并没有让我感到无能，他们只是不想再担心所有低级的 IT 问题。 +网站：http：//wikimedia.org/ -晨星（Morningstar）的 CTO Mitch Shue 在 [AWS Summit Series 2017](https://www.youtube.com/watch?v=vhNvhJGOhSw&ab_channel=AmazonWebServices) 上做了简短的演讲。 它并没有完整的技术细节。 那不是有趣的部分。 演讲更多地是关于他们的动机，他们采取行动的过程以及他们所经历的一些结果。 尽管这更有趣，但我们之前已经听到了很多。 +## 信息来源 -我发现最有趣的是晨星作为金丝雀测试的想法。 如果晨星公司成功，那么该死的公司可能破产，我们将看到呆板的主流企业更多地采用云技术。 这是一个复制猫的世界。 这种先例为其他 CTO 提供了做出相同决定所需的掩护。 +* [Wikimedia 架构](http://www.nedworks.org/~mark/presentations/san/Wikimedia%20architecture.pdf)* http://meta.wikimedia.org/wiki/Wikimedia_servers* 从 Oracle 到 MySQL 博客中*中的[横向扩展与纵向扩展](http://oracle2mysql.wordpress.com/2007/08/22/12/)。 -在整个演讲中，最重要的想法是：迁移到云上可以节省很多成本，但是他们更感兴趣的是“创建无摩擦的开发经验以刺激创新和创造力”。 + ## 平台* * 阿帕奇* 的 Linux* 的 MySQL* 的 PHP* 乌贼* LVS* Lucene 搜索* Memcached 用于分布式对象缓存* Lighttpd Image Server -软件正在吞噬世界。 毫无疑问，晨星展望未来，看到赢家将是那些能够以最快的速度开发最好的软件的人。 他们需要更好地开发软件。 拥有自己的基础架构是技术债务的一种形式。 是时候偿还债务并开始进行真正的创新工作了，而不是苦苦挣扎。 + ## 统计资料 -这是我的谈话内容： + * 800 万篇文章遍布数百个语言项目（英语，荷兰语，...）* 世界排名第十繁忙的网站（来源：Alexa）* 指数级增长：每 4-6 个月访问者/流量/服务器增加一倍* 高峰时间 30000 个 HTTP 请求/秒* 3 Gbit / s 的数据流量* 3 个数据中心：坦帕，阿姆斯特丹，首尔* 350 台服务器，范围在 1x P4 至 2x Xeon 四核之间，内存为 0.5-16 GB* 由〜6 人管理* 3 个大洲的 3 个群集 -## 基础设施 + ## 架构 -* 全球 8 个数据中心 -* 11,318 个应用服务器 -* 7,894 个数据库实例 -* 4PB 存储 + * 地理负载平衡基于客户端解析器的源 IP，将客户端定向到最近的服务器群集。 将 IP 地址静态映射到国家/地区到群集* 使用 Squid 实现的 HTTP 反向代理缓存，按文本分组表示 Wiki 内容，对媒体分组表示图像和大型静态文件。* 当前有 55 个 Squid 服务器，外加 20 个等待设置。* 每个服务器 1,000 个 HTTP 请求/秒，在压力下最多 2500 个* 每个服务器〜100-250 Mbit / s* 每个服务器〜14000-32000 个开放连接* 每个 Squid 服务器最多 40 GB 的磁盘缓存* 每台服务器最多 4 个磁盘（1U 机架服务器）* 8 GB 的内存，Squid 使用的内存的一半* 自使用 CARP 以来，命中率：文本为 85％，媒体为 98％。* PowerDNS 提供地理分布。* 他们在其主要和区域数据中心中构建基于 LVS，CARP Squid，Cache Squid 构建的文本和媒体集群。 在主数据中心中，它们具有媒体存储。* 为了确保提供所有页面的最新版本，将无效请求发送到所有 Squid 缓存。* 一个集中管理的&同步了数百个 Wiki 的软件安装。* MediaWiki 可在多个 CPU 上很好地扩展，因此我们现在购买双四核服务器（每个盒 8 个 CPU 内核）* 与外部存储和 Memcached 任务共享的硬件* Memcached 用于缓存图像元数据，解析器数据，差异，用户和会话以及修订文本。 元数据（例如文章修订历史记录，文章关系（链接，类别等），用户帐户和设置）存储在核心数据库中* 实际修订文本以 blob 形式存储在外部存储中* 静态（上载）文件（例如图像）分别存储在图像服务器上-元数据（大小，类型等）存储在核心数据库和对象缓存中* 每个 Wiki 都有独立的数据库（不是独立的服务器！）* 一个主机，许多复制的从机* 读取操作在从属服务器上实现负载平衡，写入操作转到主服务器* 如果从站尚未更新（滞后），则将主站用于某些读取操作* 外部存储 + -文章文本存储在单独的数据存储群集中，即简单的仅附加 blob 存储。 为大量未使用的数据节省昂贵和繁忙的核心数据库上的空间 + -允许在应用程序服务器上使用备用资源（每个服务器 2x + 250-500 GB） + -当前使用了 3 个 MySQL 主机的复制集群； + 为了更好的可管理性，将来可能会改变 -## 改变的时候了 + ## 得到教训 -* 想象一下在修补，升级，管理和保护 8 个全球数据中心方面所做的工作。 运行非常复杂。 -* 问题不在于他们的 IT 员工。 他们对 IT 感到满意。 -* 想要最大化人才，拥有更少的基础架构并专注于核心业务。 -* 想要简化和减少复杂性。 -* 运行数据中心并不能与它们区分开。 + * 专注于体系结构，而不是操作或非技术性内容。 -## 改变文化 + * 有时，缓存比重新计算或查找 + 数据源要花更多的钱……剖析！ -* 过渡到云需要来自世界各地的 1400 名技术人员的参与。 不容易做到。 -* 来自世界各地的许多半自治团体都有各自的路线图和团队目标。 -* 既定的高级技术目标：最大化人才，拥有更少的基础设施，减少复杂性，提高产品完整性，产品安全性，产品可恢复性，产品可靠性，更好的正常运行时间，更好的监控和更快的事件响应。 -* 选择目标的目的是易于重复，易于理解且不会过期。 -* 不要对自己的文化感到被动。 通过有目的的重复将这些目标融入您的文化：大量会议，博客文章，演示和对话。 -* 迁移到 AWS 支持这些目标。 + * 避免使用昂贵的算法，数据库查询等。 -## 策略：快速行动然后优化 + * 缓存所有昂贵且具有时间参考性的结果。 -* 数据收集团队最初使用提升和转换方法迁移到 AWS。 那使他们迅速进入了云端。 -* 一旦一切正常，他们就开始降低复杂性。 -* 将 SQL Server 替换为 RDS for PostgreSQL。 -* 添加了用于消息传递的 Kinesis，因此他们可以更好地控制工作负载分配。 -* 由于他们的应用程序每天仅运行 2-4 小时，因此他们用 Lambda 函数替换了所有 EC2 实例。 -* 致力于制定按需创建和销毁整个计算机环境的策略。 -* 将他们的数据湖移至 S3。 -* 不断进行迭代以降低复杂性。 + * 关注代码中的热点（概要分析！）。 -## 结果：降低了 97％的成本 + * 通过分开进行缩放： + -读写操作（主/从） + -廉价操作和更频繁操作（查询组）中的昂贵操作 + -小型 Wiki 中的大型，流行 Wiki -* 当然，该项目是经典的 Lambda 用例。 空闲时间这么多，全时 EC2 实例没有多大意义。 -* 但话又说回来，您可以想象整个企业中有许多这样的潜在优化。 + * 改善缓存：参考的时间和空间局部性，并减少每个服务器的数据集大小 -## 未来 + * 文本被压缩，并且仅存储文章之间的修订。 -* 到 2017 年，核心数据 API 将移动数 TB 的数据，每天处理数百万条消息。 -* 到 2018 年，他们将存储超过 2PB 的数据，每天处理超过 20 亿条消息，以支持超过 5 亿美元的产品收入。 -* 到 2020 年将自己的基础设施减少 70％的目标。 -* 悉尼数据中心将于 2018 年关闭。通过迁移非生产环境来缩小深圳的占地面积。 -* 创建了一个卓越的云计算中心，以重新考虑安全性，部署和运营等领域。 -* 将启动再培训计划，以对内部人员的技能进行投资和现代化（不错！）。 -* 成本效率很高，但他们也有兴趣创造一种无摩擦的开发经验以刺激创新和创造力。 他们采取此举似乎是一个重要原因。 + * 简单的看似库调用（例如使用 stat 来检查文件的存在）在加载时可能会花费很长时间。 -## 为什么选择 AWS？ + * 磁盘搜寻 I / O 受限，磁盘心轴越多越好！ -* 谈话的这一部分听起来像是 AWS 新闻稿，毕竟这是一次 AWS 会议，但这是企业 CTO 如何思考问题的一个很好的例子。 -* 喜欢 AWS 的步伐创新，服务呼吸和专业支持。 -* 转向 AWS 并拥有更少的基础架构意味着更多的容量，更多的安全性，更高的可靠性，更多的安心和更多的创新自由。 + * 使用商品硬件的横向扩展不需要使用便宜的硬件。 如今，Wikipedia 的数据库服务器是 16GB 的双核或四核机箱，其中有 6 个 15,000 RPM SCSI 驱动器（采用 RAID 0 设置）。 这恰好是他们拥有的工作集和负载平衡设置的最佳选择。 如果可以的话，他们会使用更小/更便宜的系统，但是 16GB 的空间适合工作集大小，这将驱动其余的规范以匹配具有那么多 RAM 的系统的需求。 类似地，Web 服务器目前是 8 个核心设备，因为它恰好可以很好地用于负载平衡，并通过相对容易的负载平衡提供了良好的 PHP 吞吐量。 -[关于 HackerNews](https://news.ycombinator.com/item?id=15010310) + * 扩大规模是一项艰巨的工作，如果您不是最初设计的，则需要做更多工作。 Wikipedia 的 MediaWiki 最初是为单个主数据库服务器编写的。 然后添加了从属支持。 然后添加了按语言/项目划分。 那时的设计经受住了考验，尽管需要进行更多的改进以解决新的瓶颈。 -上周没有“互联网说可扩展性”一文。 这是故意遗漏的吗？ :) + * 任何想要设计数据库体系结构，以便允许它们廉价地从一台机器升级到网络上排名前十或百位的站点的人，都应该从设计它来处理复制从属设备的过时数据开始， 知道如何为所有读取查询负载均衡给从属服务器，并尽可能设计它以便数据块（用户批次，帐户等等）可以放在不同的服务器上。 从第一天开始，您就可以使用虚拟化来完成此工作，并在小巧的时候证明其架构。 当负载每几个月增加一倍时，这比做起来容易得多！ -通过重写所有基础架构和代码将成本降低 97％，可以 -迁移到 AWS：昂贵，但不到 2020 年在全球范围内维护 1995 年的基础架构 -投入使用，成本降低了 70％以上 +对于那些在有限的预算下处理大量可缓存内容（例如，能够返回有效到期标头的内容）的人来说，我的建议是采用反向代理，如本文所述。 -如果您不能让工程师和开发人员升级/优化软件，请上云；如果您不是一家没有客户的初创公司，请始终保持低价…… +在上周，我们有一个站点获得了 AP，在不到 5 小时的时间内触发了 10 万唯一身份访问者访问单个 IIS 服务器。 它取出了 IIS 服务器。 在适中的 Intel IV 3Ghz 上，将服务器的单个鱿鱼放置在服务器的前端即可处理整个攻击，最大服务器负载为 0.10。 -抱歉，该 zbb。 我本来有最好的意图，但我生日那天不在，只是没有足够的时间来完成它。 我们本周上班。 如果我的老手仍然可以输入:-) +对于任何有兴趣的人来说，实现它都是微不足道的。 -我也错过了星期五的帖子！ +[http://wiki.squid-cache.org/SquidFaq/ReverseProxy](http://wiki.squid-cache.org/SquidFaq/ReverseProxy) -希望你生日快乐。 +有很多服务器。 似乎他们比添加慢速的 php 脚本更好地添加新服务器 -我做了卡尔，谢谢！ +向我展示服务器数量较少的前十名网站。 只有一个。 如果您发现任何东西，我会感到惊讶。 ->如果您不是一家没有客户的初创企业，它总是“低声”。 +我一直对 Wikimedia 架构感到惊讶，他们做得很好。 -这就是为什么我认为这是一个有趣的案例，修剪。 显然，他们有自己的印章，可以按自己的方式办事。 如果他们认为节省的成本不堪重负，他们会坚持并留下来，但事实并非如此。 +这是一个很好的理由，为什么您不想要选择 squid 作为反向代理。 -关于它们的“空闲时间优化”，我一无所获：为什么有人需要 11k 的应用程序服务器和 7k 的数据库服务器来处理“每天仅工作 2-4 小时”的应用程序？ +[http://varnish.projects.linpro.no/wiki/ArchitectNotes](http://varnish.projects.linpro.no/wiki/ArchitectNotes) -我对 Reader 的理解是，这些数字是指他们的整个系统，而空闲时间是指他们最初选择迁移到 AWS 的系统。 +问候， -“用 RDS 替换 PostgreSQL 的 SQL Server”可能节省了 50％的 M $ \ No newline at end of file +斯瑞吉斯 + +Sreejith： + +我不确定在使用持续充满（意味着驱逐不断发生）缓存时，是否证明清漆与鱿鱼一样稳定或快速。 直到最近，清漆才有了驱逐机制。 + +如果您知道这种用法，请分享。 :) + +嗨，有人知道如何扩展 Lucene 吗？ + +他们是否使用在多个盒子之间共享数据的任何文件系统？ + +我认为在这种情况下，成功的重点是地理分布，而不仅仅是缓存或其他。 + +Show me a top-10 website with less servers. Just one. I'd be amazed if you'd find any. + +@以上职位。 +我认为这是不可能的。如果没有至少 3 台服务器，它总是必须经过。 +----- +[http://underwaterseaplants.awardspace.com“](海洋植物 +[http://underwaterseaplants.awardspace.com/seagrapes。 htm“](海葡萄... [http://underwaterseaplants.awardspace.com/seaweed.htm”](海藻 + +不可能 + +更新： + +* [http://www.networkworld.com/news/2009/011309-wikipedia-digital-media.html“]( Wikipedia 为数字媒体的爆炸式发展做好了准备 + +* [http://blogs.sun.com/WebScale/entry/scaling_wikipedia_with_lamp_7“](使用 LAMP 扩展 WikiPedia：每月 70 亿页面浏览量 + +* [http://blogs.sun.com/jonathan/entry/open_storage_wins_at_wikipedia“](开放存储在 Wikipedia 上获胜 + +视频文件的大小正迅速达到数十兆和数百兆字节，而高百万像素相机的普及意味着，即使是小照片也可能占用几兆字节。 Vibber 说，直到 2008 年初，用户生成的百科全书库的主要媒体文件服务器只有 2TB 的总空间。 + +“很长一段时间以来，我们只是没有[处理非常大的媒体文件]的能力，”他说。 + +此后，维基百科已将其主要的中间文件服务器的存储容量从 2TB 扩展到 24TB，现在增加到 48TB，并且最近将文件上传限制从 20MB 提高到了 100MB。 Vibber 说，实际使用的存储量大约为 5TB，但是它将迅速增长。 \ No newline at end of file diff --git a/docs/90.md b/docs/90.md index f63715e..25d14bd 100644 --- a/docs/90.md +++ b/docs/90.md @@ -1,103 +1,111 @@ -# 机器：惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化 +# YouPorn-每天定位 2 亿次观看 + +> 原文： [http://highscalability.com/blog/2012/4/2/youporn-targeting-200-million-views-a-day-and-beyond.html](http://highscalability.com/blog/2012/4/2/youporn-targeting-200-million-views-a-day-and-beyond.html) + +![](img/05b77736b31c0df92d092c23258b4c43.png) + +**更新**：这是演讲的[视频。](http://www.youtube.com/watch?v=RlkCdM_f3p4) + +YouPorn.com 的首席开发人员 [Erick Pickup](https://twitter.com/#!/EricPickupYP) 在 [建立可扩展规模的网站](https://joind.in/6123) 的演讲中介绍了其架构。 HTG8] ConFoo 会议。 如您所料，YouPorn 是一头野兽，每秒流传输三张完整的 DVD 视频，每秒处理 300K 查询，每小时产生多达 15GB 的日志数据。 + +不幸的是，我们只有演讲的幻灯片，因此本文并不像我想的那么技术性，例如在视频处理方面完全不可见，但我们确实得到了一些有趣的细节 。 + +最有趣的方法是，YouPorn 是一个非常传统的 LAMP 堆栈，具有 NoSQL 的功能，因为 Redis 现在在实时数据路径中替换了 MySQL。 简单地让我想起 [YouTube](http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html) 。 + +第二个最有趣的收获是**出色的转换**。 众所周知，永远不要重写，但在 2011 年，YouPorn 重新编写了整个站点，以使用 PHP + Redis，而不是基于 Perl + MySQL 的复杂体系结构。 所有人都认为切换非常顺利。 该站点的速度提高了 10％，他们迁移了 6 年的旧数据，没有停机时间。 + +继续阅读以了解有关 YouPorn 架构的更多信息... + +## 统计信息 + +* 于 2006 年推出，于 2011 年被收购。 +* 2008 年每天 1 亿次页面浏览 +* 30 万个查询/秒 +* 100 Gb / s-每秒流传输 3 张完整 DVD +* 每小时记录 8GB-15GB 数据 + +## 堆栈 + +* 最初用 Perl 编写（具有 DBIx :: Class 后端的 Catalyst 应用程序） +* 现在 [PHP-FPM](http://php-fpm.org/) （FastCGI 流程管理器）-是另一种 PHP FastCGI +* HAProxy +* ActiveMQ +* 清漆 +* Redis +* Nginx +* MySQL +* Syslog-ng +* [Symfony2](http://symfony.com/) -一个 PHP Web 开发框架。 + +## 架构 + +* **大切换** 。 整个站点在 2011 年进行了重写，以使用 PHP 代替复杂的 Perl 架构，并使用 Redis 代替 MySQL 和 ActiveMQ。 + * 定位到 200+百万的每日请求 + * 移动了 6 年的旧数据而没有停机 + * 新网站的速度提高了 10％。 + * 该过程花费了比预期更长的时间： + * 必须决定要使用哪些技术 + * 超出预期的学习曲线 + * 将数据从 MySQL 移动和重组到 Redis + * 人员配备 +* **HAProxy** -提供负载平衡，智能负载分配和运行状况检查 + * 维护两个服务器池：一个具有故障转移到备份主服务器的写池，一个读取池将管理除主服务器之外的服务器。 +* **清漆** -反向代理有助于加快站点速度并减少服务器负载。 还用于缓存管理，边缘包括（ESI）和 Web 服务器上的运行状况检查。 +* **系统记录**-收集页面浏览量数据，并用于查看计数器和相关视频。 +* **Nginx** -高性能 Web 服务器，运行 PHP-FPM，并充当 CSS，图像和 JS 等静态文件的外部 CDN。 +* **Symfony** -快速且功能丰富，带有大量库。 + * 认为 Symfony2 + Redis =快速开发+可扩展网站-一个很好的平衡方程。 + * 喜欢依赖注入。 + * 选择 Web 框架并不意味着要破坏性能，只要您在其前面使用可靠的体系结构即可。 +* **ActiveMQ** -为大型站点设计的消息总线，用于写入 MySQL 和 Redis。 + * 他们发现，对于一个不断变化的站点来说，它太僵化了，所获得的收益不足以维持一个单独的 Java 基础架构。 + * 希望解决问题，因为问题可能更多是开发人员而不是技术人员。 +* **Redis** -一种快速的开源 KV 存储，现在是主要数据源。 + * 实时更新。 + * 已排序的集合用于所有列表 + * [流水线化](http://rediscookbook.org/pipeline_multiple_commands.html) ，用单个原子命令执行多个 Redis 命令，是提高性能的关键 + * 切换后，添加了其他 Redis 节点，这不是因为 Redis 劳累过度，而是因为网卡无法跟上 Redis 的步伐。 + * 所有读取均来自 Redis + * MySQL 用于允许根据需求更改构建新的排序集。 + * [仅附加文件（AOF）[H​​TG2]](http://redis.io/topics/persistence) 格式用于增量备份，并且无 IO 痛苦 + * 考虑将 Redis 用作 Redis 持久性存储之前的临时缓存，以提高性能和减少负载。 +* **MySQL** -支持 Redis 的支持角色 + * 高度规范化，因为它没有直接用于网站。 + * 一些表有 100+百万行。 + * 用于使用新功能填充 Redis 列表 +* 同时使用了 GIT 和 SVN，效果不佳。 +* 在其 CMS 中使用 [教义](http://www.doctrine-project.org/) 。 节省了数周开发时间的强大工具。 -> 原文： [http://highscalability.com/blog/2014/12/15/the-machine-hps-new-memristor-based-datacenter-scale-compute.html](http://highscalability.com/blog/2014/12/15/the-machine-hps-new-memristor-based-datacenter-scale-compute.html) - -> 摩尔定律的终结是过去 50 年来计算机发生的最好的事情。 摩尔定律一直是安慰的专制。 您可以放心，您的筹码会不断进步。 每个人都知道即将发生什么以及何时发生。 整个半导体行业都被迫遵守摩尔定律。 在整个过程中没有新的发明。 只需在跑步机上踩一下，然后执行预期的操作即可。 我们终于摆脱了束缚，进入了自 1940 年代后期以来我们看到的最激动人心的计算时代。 最终，我们处于人们可以发明的阶段，将尝试并尝试这些新事物并找到进入市场的方式。 我们最终将以不同的方式和更聪明的方式做事。 -> -> - [Stanley Williams](http://en.wikipedia.org/wiki/R._Stanley_Williams) （措辞） - -![](img/017f2bcbb550b25f03cd84cdfa8f614b.png) - -惠普一直在开发一种全新的计算机，其名称为*机器*（不是 [这台机器](http://personofinterest.wikia.com/wiki/The_Machine) ）。 该机器可能是惠普历史上最大的 R & D 项目。 这是对硬件和软件的彻底重建。 巨大的努力。 惠普希望在两年内启动并运行其数据中心规模产品的小版本。 - -故事始于大约四年前我们在 [中首次遇到惠普的](http://highscalability.com/blog/2010/5/5/how-will-memristors-change-everything.html) [Stanley Williams](http://en.wikipedia.org/wiki/R._Stanley_Williams) ？ 在忆阻器故事的最新一章中，威廉姆斯先生发表了另一篇令人难以置信的演讲： [机器：用于计算大数据的 HP 忆阻器解决方案 [](https://mediacosmos.rice.edu/app/plugin/embed.aspx?ID=vVUTzFCE006yZu3TF1sXKg&displayTitle=false&startTime=0&autoPlay=false&hideControls=false&showCaptions=false&width=420&height=236&destinationID=URka-_E5-0-e4girH4pDPQ&contentID=vq2oQtAqPkeAqm5F6uSnqA&pageIndex=1&pageSize=10) ，进一步揭示了机器的工作方式。 - -机器的目标是**折叠内存/存储层次结构**。 今天的计算是低能效的。 **消耗了 80％的能量**和大量时间**在硬盘，内存，处理器和多层高速缓存之间移动位**。 客户最终花在电费上的钱比买机器本身要多。 因此，该计算机没有硬盘，DRAM 或闪存。 数据保存在高能效忆阻器，基于离子的非易失性存储器中，数据通过光子网络移动，这是另一种非常省电的技术。 当一小部分信息离开核心时，它就以光脉冲的形式离开。 - -在图形处理基准上，据报道，“机器”基于能效的性能要好 2-3 个数量级，而基于时间的性能要好一个数量级。 这些基准没有详细信息，但这就是要点。 - -**机器首先放置数据** 。 其概念是围绕非易失性存储器构建一个系统，在整个存储器中自由分配处理器。 当您要运行程序时，请 **将程序发送到内存** 附近的处理器，在本地进行计算，然后将结果发送回去。 计算使用了各种各样的异构多核处理器。 与仅移动 TB 或 PB 的数据相比，仅传输程序所需的位和结果可节省大量资金。 - -机器不针对标准 HPC 工作负载。 这不是 LINPACK 破坏者。 HP 试图为客户解决的问题是客户要执行查询并通过搜索大量数据来找出答案。 随着新数据的出现，需要存储大量数据并进行实时分析的问题 - -**为什么构建计算机需要非常不同的体系结构？** 计算机系统无法跟上不断涌入的大量数据。惠普从其客户那里得知，他们需要能够处理越来越多的数据的能力。 **与晶体管的制造速度**相比，收集的位数呈指数增长。 另外，信息收集的增长速度快于硬盘的制造速度。 惠普估计，人们真正想做的事有 250 万亿张 DVD 数据。 全世界从未收集过大量数据，甚至从未查看过。 - -因此，需要一些新的东西。 至少这是惠普的赌注。 尽管很容易对 HP 正在开发的技术感到兴奋，但至少在本世纪末之前，这对您和我来说都不是。 这些将在相当长一段时间内都不是商业产品。 惠普打算将它们用于自己的企业产品，在内部消耗所制造的一切。 我们的想法是，我们还处于技术周期的初期，因此首先要构建高成本的系统，然后随着数量的增长和流程的改进，该技术将可以进行商业部署。 最终，成本将下降到足以出售更小尺寸的产品。 - -有趣的是，HP 本质上是在构建自己的云基础架构，但是他们没有利用商品硬件和软件，而是在构建自己最好的定制硬件和软件。 云通常提供大量的内存，磁盘和 CPU 池，这些池围绕通过快速网络连接的实例类型进行组织。 最近，有一种将这些资源池视为独立于基础实例的方法。 因此，我们看到诸如 [Kubernetes 和 Mesos](https://mesosphere.com/2014/07/10/mesosphere-announces-kubernetes-on-mesos/) 之类的高级调度软件正在成为行业中的更大力量。 惠普必须自己构建所有这些软件，以解决许多相同的问题，以及专用芯片提供的机会。 您可以想象程序员对非常专业的应用程序进行编程以从 The Machine 获得每盎司的性能，但是 HP 更有可能必须创建一个非常复杂的调度系统来优化程序在 The Machine 上的运行方式。 **软件的下一步是一种全息应用程序体系结构的演进，其中功能在时间和空间上都是流动的，并且身份在运行时由二维结构产生。** 日程安排优化是云上正在探索的下一个领域。 - -演讲分为两个主要部分：硬件和软件。 该项目的三分之二是软件，但威廉姆斯先生是硬件专家，所以硬件占了大部分。 硬件部分基于**优化围绕**可用的物理原理的各种功能的思想：**电子计算； 离子存储 光子通信**。 - -这是我对威廉姆斯先生的发言 [讲话](https://mediacosmos.rice.edu/app/plugin/embed.aspx?ID=vVUTzFCE006yZu3TF1sXKg&displayTitle=false&startTime=0&autoPlay=false&hideControls=false&showCaptions=false&width=420&height=236&destinationID=URka-_E5-0-e4girH4pDPQ&contentID=vq2oQtAqPkeAqm5F6uSnqA&pageIndex=1&pageSize=10) 。 像往常一样，面对如此复杂的主题，可能会错过很多东西。 另外，威廉姆斯先生在煎饼周围扔出了很多有趣的主意，因此强烈建议您观看演讲。 但是在那之前，让我们来看看 HP 认为机器将是计算的未来……。 - -## 为什么构建计算机需要不同的体系结构？ - -计算架构在 60 年来从未改变。 [Von Neumann 架构](http://en.wikipedia.org/wiki/Von_Neumann_architecture) 仅打算使用几年，但我们仍在使用它。 数据必须在内存，处理器和硬盘之间来回移动。 **如今，移动数据的过程已完全主导了计算**。 这就是在数据中心中花费大量时间并消耗大量电力的原因。 - -摩尔定律即将终结。 我们已经达到了 14 nm（约 50 个原子）的晶体管。 7 nm 被认为是物理极限。 10 纳米将在两年内准备就绪，而 7 纳米将在 2020 年之前准备就绪。 这将使计算效率提高 10 个数量级，这是人类技术有史以来最大的改进。 - -我们如何看待突破摩尔定律范式？ **围绕可用的**优化物理的各种功能。 50 年来，我们附属于计算机的东西是电子。 那不会改变。 电子是执行计算过程的理想选择。 它们很小，很轻，您施加了电压，移动很快，但是它们的质量足以使它们位于一个很小的空间中，并且相互作用非常强，因此您可以对电子进行逻辑运算。 电子将继续成为引擎的计算部分。 - -**我们将使用离子** 而不是使用电子进行存储。 原因是离子是经典的机械粒子，它们很重，将它们放在某个地方并留在那儿，您可以回到一个世纪后，将离子放在那儿的位置仍然存在。 离子确实是非易失性存储信息的一种方法。 可以将离子放在小盒子中，然后可以将盒子堆叠起来，与电子相比，可以实现高密度，低成本的存储。 - -**数据将使用光子** 移动。 其原因是光子没有质量，因此它们以光速运动。 可以在同一波导中放置许多不同颜色的光，因此可以节省大量空间和能源。 更高的通信带宽和更低的功耗。 - -正在围绕这些功能中的每一个对机器周围的硬件进行优化，以便进行计算，存储和通信。 通过适当地构建它们，存在有利的非线性相互作用。 - -**通过异构多核芯片的扩散，电子将继续成为未来** 的计算引擎。 由于摩尔定律的失败，如今存在多核芯片。 我们之所以拥有多核芯片，是因为一个大而快的芯片的功耗会使其蒸发。 为了解决该问题，将芯片切成小块。 问题是多核更难编程，但是我们开始弄清楚，人们现在认为多核是一件好事。 - -并非所有核心都相同，而是核心将有所不同。 代替在芯片上具有相同的 256 个内核，将针对不同类型的功能优化不同的内核。 - -**挑战是 Dark Silicon** 。 如果同时点亮一个芯片上的所有内核，则**芯片将被蒸发**。 您实际上从未真正使用过芯片上的所有内核。 与 14nm 相比，在 10nm 下，您必须一次使用一半的内核。 如果内核是特定于功能的，则在不使用内核时将它们变暗是有意义的。 专用加速器是可以超级高效地运行一种类型的计算的核心，但是它只能完成一件事。 对于求解晶体结构，如果您有一个可以在一个时钟周期内完成傅立叶变换的专用内核，那将非常有帮助。 - -您不需要庞大的团队来设计处理器。 有些公司出售处理器设计。 您可以只设计几个专门的加速器。 这些设计可以招标。 力量的平衡将转移给设计师，而不是制造商，他们将成为低成本的竞标者。 - -## **忆阻器是离子盒** - -**DRAM 本质上吸收电子并将其放入盒子中** 。 随着盒子的尺寸越来越小，将电子保持在内部的难度越来越大，这意味着 DRAM 必须更频繁地刷新。 可靠地将电子存储在 DRAM 或闪存中变得越来越困难。 - -**解决方案是在存储介质中使用作为带电原子的离子代替电子** 。 原子比电子的行为更好，因为它们的质量大得多。 原子是经典的机械粒子，因此即使在 10nm 的盒子中，原子也很高兴成为粒子。 将离子放入盒子中，在盒子上施加电压，离子将在盒子内移动。 关闭电压，即使在很小的盒子中，离子也将保持原状，甚至持续数百万年。 这是非常稳定的非易失性类型的内存。 - -**可以通过在盒子上施加小电压并测量电阻**来读取离子状态 **。 由于电压不够高，离子不会移动。 盒子的电阻取决于离子在里面的位置。 当离子在盒子中均匀分布时，您会得到一个低电阻，您可以将其称为 1。如果将所有离子推到盒子的一侧，则电阻将非常高，您可以将其称为 0。** - -**离子盒是忆阻器**。 与 DRAM 忆阻器相比，**因子**慢 4 倍，可以通过并行访问来缓和。 忆阻器的功率要求要低得多，因为离子不会泄漏，因此无需刷新。 **的位密度要比**高得多，因为可以将盒子堆叠在一起。 芯片**每位**便宜得多。 基于这些想法，他们多年来一直在制造芯片。 在演讲中，显示的芯片使用了 2.5 年，并使用了 50nm 技术，这意味着当前的迭代要好得多，但是他们无法发表评论。 - -想法是折叠内存/存储层次结构，并消除在系统中所有层之间移动数据的所有开销和时间。 今天的计算问题是能源效率低下。 花费了 80％的能量，并花费了大量时间来获取位，然后将它们从硬盘，内存，处理器，多层高速缓存中移出，然后再向下移出。 大多数操作系统都关心所有这些数据处理的机制。 - -## 使用光子进行通信 - -光子破坏距离。 没有什么比光速快。 - -那么为什么我们不像在电信网络中那样已经在芯片上使用光子学呢？ 互连的成本将是计算机本身成本的一千倍。 **通过机架移动的数据量大于通过北美电信网络**的数据量。 - -**惠普一直在努力降低成本**。 光线是移动数据的一种上乘方式。 它具有高带宽（单根导线中有多个波长），高能效（无能量损失），低延迟（无中继器）和空间高效（节省了引脚数）。 - -他们现在正在使用标准硅工艺在硅晶片上集成光子学。 +## 相关文章 -此技术用于在计算机中创建通信结构。 电脑是一个装有刀片的盒子。 刀片服务器具有忆阻器存储芯片和多核处理器。 插入刀片时，刀片会自动重新配置光子网络，以便一切都能相互通信。 接下来要做的是把盒子拿起来并堆放在一起，形成一个架子。 同样，网络会自动进行自我配置。 接下来是能够组装一个数据中心的机架，然后将它们全部抬起并正确配置。 +* [什么是 Symfony2？ Fabien Potencier 的](http://fabien.potencier.org/article/49/what-is-symfony2) +* [Youporn 堆栈上的超级空缺-每天 300K QPS 和 1 亿页面浏览量](http://highscalability.com/blog/2012/2/16/a-super-short-on-the-youporn-stack-300k-qps-and-100-million.html) +* [在 Reddit 上](http://www.reddit.com/r/programming/comments/rvw6q/youporn_scaling_to_200_million_views_a_day_and/) -![](img/ef7fa9f1d9f2fec0ad587f22ccb7b621.png) +演讲视频将很快到来。 -## 软件-三分之二 +我没有太多内容可以讨论。 我的计划是显示可能的结果，并在以后的讲座/文章中介绍细节。 我正在处理这些。 -到目前为止，所有硬件仅占项目的 1/3。 The Machine 之上必须装有操作系统。 一个操作系统可能需要数十年的开发时间。 **惠普正在开发精简版的 Linux** ，该版本非常快，因为处理掉了数据内部移动的所有逻辑都已被剔除。 他们还创建了**开源社区，以构建操作系统**的本机版本，以及所有最重要的应用程序，例如分析，可视化，艾字节级算法和百万节点管理。 +〜埃里克 -试图缩短从研究，开发到产品生产的时间范围。 大量的工作。 这是一个非常冒险的项目。 规模庞大。 雄心勃勃。 巨大的风险。 +没有批评的意图，我只是想解释为什么为什么可能没有读者想要的那么多细节。 我知道这需要大量工作，并且期待更多细节。 谢谢。 -## 对任何尝试进行全新工作的人来说，都是一个重大警告。 +很棒的文章，很棒的幻灯片。 期待观看视频。 +听到有关 svn / git 项目符号的更多详细信息将很有趣。 -**经验教训**：他们遇到了无法预料的问题。 然后要做很多工作，以确保可以使用标准制造流程来构建其流程。 +Youporn 最初是使用 Perl Catalyst 框架开发的（请参阅 http://www.technewsworld.com/story/70236.html?wlc=1276880514） +Manwin 在 2010 年 4 月收购了 youporn。那时，Youporn 已经是一个 BIG 网站。 -如果您尝试引入真正不同的东西，例如碳纳米管或石墨烯，会发生什么？ 他们使用所有标准材料所面临的挑战是巨大的。 引入异国情调的东西将需要数十年的时间才能真正通过实际的制造过程进行构建。 如果您打算深入研究并大胆地做，则必须**做一些与现有**尽可能接近的事情。 你离那不可能走得太远。 +根据介绍，他们决定将 Perl Catalyst 框架更改为 PHP Symphony 框架的决定并不是为了获得性能，而是为了使新收购方的非 Perl 开发人员获得陡峭的学习曲线。 -## 相关文章 +我似乎认为 MySQL，ActiveMQ-> Redis 更改带来了 10％的性能提升。 即使这似乎不是很大的改进。 -* [忆阻器将如何改变一切？](http://highscalability.com/blog/2010/5/5/how-will-memristors-change-everything.html) +不要怪罪 Perl 具有复杂性和低性能。 :) -* [我们比光而不是电的超高速计算机更近一步](http://www.fastcolabs.com/3039445/were-one-step-closer-to-superfast-computers-that-run-on-light-instead-of-electricity) +我很高兴视频播放完了。 -* Google 押注 [Quantum Computers](https://plus.google.com/+QuantumAILab/posts) +在演示过程中的某些时候，埃里克（Eric）曾将 2 个小错误称为 dns 服务器，网络服务器和内存缓存 Redis。 -* [图灵大教堂](http://www.amazon.com/dp/0375422773) -乔治·戴森 +我想知道的部分，视频搜索如何工作？ Redis 有可能吗？ 还是仍然使用 MySQL 文本搜索？ -* [IT 的新风格](http://www.hipeac.net/system/files/HiPEAC14-faraboschi-pub.pdf) \ No newline at end of file +这一切都在什么硬件上运行？ 它是自托管的吗？ \ No newline at end of file diff --git a/docs/91.md b/docs/91.md index ce6982c..3b86b76 100644 --- a/docs/91.md +++ b/docs/91.md @@ -1,255 +1,131 @@ -# Aeron：我们真的需要另一个消息传递系统吗？ - -> 原文： [http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html](http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html) - -![](img/3172dea1863b98ea825fe6957b36e4bf.png) - -我们真的需要 [另一个](https://www.youtube.com/watch?v=dq4aOaDXIfY) 消息传递系统吗？ 如果它承诺使用创新的设计，以每秒一百万微秒的延迟在机器之间以百万微秒的延迟将数百万条消息以一致的响应时间传递给大量客户端，那么我们可能会做到。 - -这就是 [Aeron](https://github.com/real-logic/Aeron) （凯尔特神 战斗，而不是主持人，尽管告诉搜索引擎），这是 [Todd Montgomery](https://twitter.com/toddlmontgomery) 团队开发的一种新型高性能开源消息传输库， 多播和可靠协议专家，编译器优化专家 [Richard Warburton](http://insightfullogic.com/blog/) 和 [Martin Thompson [](https://twitter.com/mjpt777) ，这是面糊的表演黑帮。 - -声称 Aeron 已经在吞吐量方面击败了最好的产品，并且延迟匹配了最高达 90％的最佳商业产品。 Aeron 可以以每秒 600 万条消息的速度推送 40 字节的小消息，这是非常困难的情况。 - -以下是马丁在 Strangeloop 上对 Aeron 的演讲： [Aeron：开源高性能消息传递](https://www.youtube.com/watch?v=tM4YskS94b0) 。 我将简要介绍他的演讲，并整合到本文末尾列出的信息源中。 - -Martin 和他的团队处于令人羡慕的位置，拥有一个需要像 Aeron 这样的产品的客户，并愿意为其开发提供资金，同时也使其开源。 因此，在 GitHub 上运行 git [Aeron](https://github.com/real-logic/Aeron) 。 请注意，对于 Aeron 来说还处于初期，他们仍处于繁重的优化阶段。 - -世界已经改变，因此端点需要前所未有的扩展。 这就是为什么马丁说我们需要一个新的消息传递系统的原因。 现在是一个多面的世界。 我们拥有多核，多插槽，多云，数十亿用户计算，通讯一直在发生。 大量的消费者定期对要从同一发布者读取的频道进行捣乱，这会导致锁争用，排队效应，从而导致吞吐量下降和延迟高峰。 - -我们需要一个新的消息库来充分利用这个新世界。 [转向微服务](https://groups.google.com/forum/#!topic/mechanical-sympathy/fr7moLcsuiI) 仅增加了需求： - -当我们进入微服务世界时，我们需要从通信中获得非常低且可预测的延迟，否则 [USL](http://www.perfdynamics.com/Manifesto/USLscalability.html) 的一致性部分将会出现 雨火和硫磺在我们的设计上。 - -使用 Aeron 的目标是保持事物的纯正和专注。 到目前为止，我们所做的基准测试表明吞吐量和延迟方面的进步。 十分独特的是，您不必在吞吐量和延迟之间进行选择。 对于其他高端消息传输，这是一个独特的选择。 Aeron 使用的算法可提供最大的吞吐量，同时将直到饱和的等待时间最小化。 - -“许多通讯产品都是瑞士军刀； [说](https://groups.google.com/d/msg/mechanical-sympathy/fr7moLcsuiI/IMvQY_bCQf8J) Martin，这是了解 Aeron 的好方法。 它不是您习惯的全功能消息传递产品，例如 [Kafka](http://kafka.apache.org/) 。 Aeron 不保留消息，不支持有保证的传递，也不支持群集，也不支持主题。 Aeron 不会知道客户端是否崩溃了，也无法从历史记录同步备份或从历史记录初始化新客户端。 - -将 Aeron 置于心理矩阵中的最佳方法可能是将其作为面向消息的 TCP 替代品，并在其上写入更高级别的服务。 Todd Montgomery [扩展了](https://groups.google.com/d/msg/mechanical-sympathy/fr7moLcsuiI/XsKndzoR6ycJ) 的构想： - -Aeron 是 ISO 第 4 层协议，它提供了许多消息传递系统无法提供的功能，也没有提供某些消息传递系统可以提供的功能.... 让我稍微解释一下所有典型的消息传递系统（不仅是 Kafka 和 0MQ）。 - -一种更多考虑 Aeron 适合何处的方法是 TCP，但是可以选择可靠的多播传送。 但是，这在一定程度上是有限的，因为 Aeron 在设计上也具有许多可能的用途，这些用途远远超出了 TCP 的功能范围。 以下是一些要考虑的事项： - -Todd 继续提供更多详细信息，因此请继续阅读文章以了解更多有关该主题的信息。 - -Aeron 的核心是 **复制的消息持久记录** 。 通过非常有意识的设计过程，消息从发布到接收的整个过程都是无等待的，零复制。 这意味着延迟非常好并且非常可预测。 - -总结 Aeron 简而言之。 它是由一支经验丰富的团队创建的，使用了以前许多项目中都得到强化的扎实的设计原则，并得到了并非所有人都拥有的技术支持。 每个方面都经过精心设计，干净，简单，高性能和高度并发。 - -如果说简单与聪明是无法区分的，那么 Aeron 就有很多聪明之处。 让我们看看他们是如何做到的... - -请注意，Martin Thompson 的 [这个话题](https://www.youtube.com/watch?v=tM4YskS94b0) 正在进行中。 我尽了最大的努力来捕捉想法，但是您没有得到的感觉就是它们融合在一起的程度。 马丁在传达这种整体感方面做得很出色，这就是为什么这次演讲值得一看。 - -## 其他 - -* *Todd Montgomery 继续说。*。关于 Aeron 适合何处的一种思考方式是 TCP，但可以选择可靠的多播传递。 但是，这在一定程度上是有限的，因为 Aeron 在设计上也具有许多可能的用途，这些用途远远超出了 TCP 的功能范围。 这里有几件事情要考虑： - - * 及时识别具有完整记录边界的“持久”数据流。 这是{channel，sessionId，channelId，offset，length}元组，它是日志缓冲区策略的核心。 这使得具有任意回放的流的非易失性存储能够掉出……这非常有趣。 这导致以真正机械的同情方式进行数据流的重新连接和持久化。 我对此压力太大了。 实际上，这也为传输协议提供了真正的位置透明性。 即本地订户可以直接从发布者的日志缓冲区中读取，而驱动程序则透明地将数据发送给现成的订户。 到目前为止，我们已经确定了这些内容，但是我认为这也可以应用于处理主动/被动前​​向纠错，轮播，任意重放等的独特方法。 - - * Aeron 没有主题。 它具有单独的非竞争流。 大多数消息传递系统都提供主题空间。 这是一种祝福和诅咒。 通过为 Aeron 故意保留有界的实现方式（但不受设计限制）的流空间，Aeron 允许在顶部构建主题空间（这使 0MQ 和许多其他系统可以利用它）而不会将实现锁定在浪费资源上 对于那些不需要它的用例。 - - * 可靠的单播设计是一种模仿 TCP 的熟悉的防火墙可穿越设计。 但是可靠的多播设计允许发布/订阅语义具有无限可配置的流控制策略。 这不仅提供了普通的消息传递，流传输等各种用例可能性。 - -* 传输媒体已更改。 消息不再只是通过 TCP。 更多的多播正在发生。 Infiniband 正在高性能领域起飞。 [PCI Express](http://en.wikipedia.org/wiki/PCI_Express) 3.0 具有内置的内存模型，因此可以在计算机之间的总线之间传输字节。 这就是许多高性能空间的去向。 - -* 我们需要在同一台机器上的进程和套接字之间进行通信。 随着使用越来越多的内核构建机器，它们实际上成为了一个盒子中的数据中心。 英特尔的新款 [Haswell CPU](http://www.extremetech.com/computing/189518-intels-new-18-core-haswell-xeon-chips-will-try-to-preempt-the-arm-server-onslaught) 每个插槽具有 18 个内核，每个内核具有两个超线程。 在一台计算机上可能同时运行 240 个线程，我们需要一种方法来分工并有效地进行通信。 - -* 用纯 Java 8 编写，并利用了该版本新引入的 lambda 表达式。 - -* 对等而不是代理解决方案，这是它具有如此低的延迟的原因之一。 - -* 使用 UDP 并将很快拥有 SHM IPC 和 Infiniband。 - -* 构建高性能系统的秘诀在于简单性。 复杂性会降低性能。 追求简洁的简洁设计。 - -* 通过提供替代算法提供带有可插拔钩子的自己的流控制。 - -* 不支持群集和存档的消息，尽管将来的项目可能会添加一些此功能。 - -* 可靠的多播传递。 - -* Aeron 本质上将日志缓冲区从一台机器复制到另一台机器。 从功能上来说，缓冲区是持久的，因为存储的记录不会发生突变，也不会持久存储到磁盘。 - -* 提供可靠的交货，但不能保证。 如果订户死亡并超时，则将不会重试消息传递。 可以在 Aeron 之上分层协议以存档已发布的消息，以便订户可以恢复，但这不在基本功能之内。 - -* 不提供交易担保。 因此，要约完成后，当要约返回时，要么被拒绝，要么被放置在共享内存日志缓冲区中，由驱动程序发送。 在流量控制允许的范围内，驱动程序会尽力发送。 但是，Aeron 确实尽力将其提供给订户。 这是一种尽力而为的传递保证，就像 TCP 一样，但是要好一点，因为它可以处理 TCP 无法实现的某些连接故障。 但这并不能保证。 - -* 为了测试捕获完整的等待时间直方图，同时尝试多个线程同时发布从而发生竞争的情况。 还要与许多其他消息传递因素进行比较。 例如 IPC /单播/多播，不同的消息大小等。 - -## 基本操作 - -* 发布者通过一个频道发送消息，供订阅者阅读。 频道内是流向订户的流。 - - * 通道保持消息有序。 信息流彼此独立，因此它们不会相互阻塞。 - - * 检测到损失并以对延迟和吞吐量的最小影响进行处理。 - - * 使用流量控制和背压以免淹没客户。 - - * 拥塞避免和控制处理经过拥塞网络的数据包。 它被认为是高性能领域中的一项可选服务。 当发生拥塞时，需要此服务，但是在等待时间需要尽可能低的情况下，拥塞控制算法会使您减速。 一个示例是 TCP 的 [慢启动](http://en.wikipedia.org/wiki/Slow-start) 问题，因为 TCP 试图避免用流量淹没网络。 - - * 在处理非常大的消息，处理碎片并避免 [行头阻塞](http://en.wikipedia.org/wiki/Head-of-line_blocking) 的同时，在通道中对流进行多路复用和多路分解。 - -* 不是框架，而是图书馆。 这是一种可组合的设计，因此可以在其之上构建其他层。 - -* 设计大约涉及三件事：系统架构，数据结构和协议交互。 - - * 正确构建架构，并使其美观整洁。 - - * 数据结构非常重要。 - - * 如今，人们不再强调良好的协议工作，这是分布式代理进行通信和合作时的基础。 - -## 架构 [ - -* 发布者发布，订阅者订阅。 您可以在两台计算机之间进行双向通信，但是每台计算机都需要分别注册一个发布者和一个订阅者。 一对发布者和订阅者只是一种通信方式。 - -* 通信通过 UDP，UDP 多播，Infiniband，PCI-e 3.0，RDMA 等媒体进行。 - -* 发送者负责通过媒体发送数据，而接收者则通过媒体接收数据。 发送者和接收者是在各自的线程中运行各自工作的独立代理。 现代处理器确实擅长于一遍又一遍地执行相同的操作，因为它们的高速缓存中存储着指令和数据。 - -* 导体是独立的代理，可以完成所有不在 A 和 B 之间发送字节的工作。这包括内部管理和管理员（如用户设置，新出版物的事件，新的订阅以及告诉系统正在发生的事情）。 - -* 发送方和接收方保持非常简单和整洁，因此它们可以使用最佳方法在媒体上的两点之间尽快传输数据。 - -* 在同一进程中没有共享数据结构。 通信正在使用消息传递。 导体使用消息通过非阻塞结构进行通信。 这允许使用干净的单线程代码，该代码可以运行得很快。 避免了并发和使用队列的锁定。 - -* 明确分开的关注点意味着可以选择零件的放置位置。 它们都是独立的代理程序，具有自己的线程，运行自己的代码，具有自己的内部数据结构，这些数据结构不共享，因此它们不需要并发，不需要锁，因此可以实现令人难以置信的执行 快速。 - - * 导体分为为发送者和接收者提供服务所需的内容以及为客户端提供服务所需的内容。 而且由于通讯不使用共享内存，而是在队列中，因此可以将 Conductor 的这些部分拆分为单独的进程。 媒体驱动程序可以处于自己的进程中，客户端可以处于其自己的进程中。 或者，媒体驱动程序可能位于内核中。 或在 FPGA 中。 - -## 数据结构 - -* Java 中的数据结构过于复杂，间接性太多，这意味着性能低下，因此他们构建了自己的映射，IPC 环形缓冲区，IPC 广播缓冲区，ITC 队列，动态数组，日志缓冲区。 - -* 环形缓冲区用于在导体，客户端和驱动程序之间进行通信。 - -* 还需要将事件从驱动程序发送到多个客户端，而不会降低驱动程序的速度，而不考虑客户端的数量，因此广播用于事件。 - -* 许多数据结构在动态变化，例如给定订阅的订阅者数量，发布的发布者数量，这些数据结构必须是动态的且无阻塞的。 日志缓冲区用于将消息从发布移动到订阅。 - -## 永久日志 - -* 消息与标头一起存储在持久日志结构中。 （更多关于日志结构[在此处](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)的介绍）。 - -* 日志已映射到磁盘，但使用内存映射文件保存在内存中。 日志活在文件中，因为文件可跨进程使用。 文件被映射到内存中，从而避免了必须进行系统调用才能进入磁盘的过程。 - -* 不变的数据结构可以安全无锁地读取，因为它们会随着时间增长。 - -* 描述了添加消息的协议和状态机。 添加消息不涉及任何锁。 - - * 首先，将尾部原子地向前移动，以便另一个线程可以在同一时间添加一条消息。 - - * 现在可以添加消息了。 该消息被复制到缓冲区。 - - * 为了表示一条消息已完成，将单个字操作写入消息头中的字段。 - - * 消息标头已完全写入日志，因此向发送方发送消息只需要编写标头和消息的连续字节，无需动态编写，因此将消息发送至发布者非常有效 很多客户。 - -* 日志不仅仅是随时间增长的单个文件。 单一文件设计虽然很常见，但存在很多问题。 因为页面错误会一直发生，并且页面错误非常昂贵，这会增加 VM 压力和页面搅动（这是 [页面错误成本](https://plus.google.com/+LinusTorvalds/posts/YDKRFDwHwr6) 上的 Linus Torvalds） ）。 页面错误并没有变得越来越快，过程也越来越快，因此差距是巨大的（尽管这一直是正确的，为什么页面错误总是要避免的原因）。 - -* 单个文件方法的替代方法是保留三个缓冲区：干净，脏，活动。 活动缓冲区是您正在写入的缓冲区。 肮脏是永恒的历史。 清除是下一个变为活动状态的缓冲区。 导体可以在后台进行清理，因此写入它们不会造成等待时间的损失。 缓冲区在缓存中都很热，因此没有页面缓存正在进行。 另一个线程可以将脏缓冲区存档到另一个数据存储中，以便可以永久保存消息。 - -* 这是免等待时间的实现方式。 假设有两个编写者试图在两个不同的线程中由两个不同的发布者同时将消息 X 和 Y 写入日志，可能是在不同的过程中写入同一驱动程序。 由于驱动程序用尽了进程，因此可以在多个进程之间共享。 Y 赢得比赛以增加尾巴。 然后 X 递增尾部，但是尾部越过缓冲区的末端。 Y 可以使用它分配的空间。 填充记录放置在 Y 的末尾与缓冲区的末尾之间，因此缓冲区始终是连续且完整的。 X 负责旋转到下一个缓冲区，在该缓冲区中它将消息从缓冲区的开头写入新的尾部。 所有这些工作并没有导致线程的任何延迟。 它完全独立发生，没有阻塞操作。 如果某个进程中断，则其他所有线程均不会阻塞。 - -## 发送消息 ， - -* 标头包含版本信息； 旗; 消息类型； 帧长 术语“偏移量”，即到缓冲区的偏移量，这是将其复制到另一端的位置； 会话 ID，流 ID； 条款 ID； 编码的消息。 所需的所有内容都在标头中，因此可以将其直接写入网络。 写入帧长字节后，消息已发送。 - -* 标头设计的有趣含义是，流中的每个字节在整个时间上都有唯一的标识符，这是 streamId，sessionId，termId，termOffset 的复合键。 稍后将使用此功能，以便接收者可以告诉发送者日志的哪个区域被删除，因此发送者可以从该点重新发送。 - -* 使用消息协议在发送方和接收方之间复制日志。 发送方要发送消息时，会向接收方发送设置消息。 接收方发回状态消息。 发送方开始向接收方发送数据。 接收方发送更多状态消息，告诉发送方它还有 X 的剩余空间，因此您可以继续发送。 消息不被确认，NAK 代替。 为了最小化[内爆效应](ftp://www-net.cs.umass.edu/pub/Rubenst98:Proact-TR-98-19.ps.gz)，大多数现代组播协议使用 NAK 代替 ACK。 接收者告诉发送者它还剩下多少空间，这比基于 ack 的方法所需的消息更少。 它为您提供了一种实现流量控制和背压的机制。 - -* 发送方将其作为心跳发送的最后一条消息发送给接收方。 这种方法还可以处理丢弃最后一条消息的情况（请记住，正在使用 UDP）。 - -* 当接收者知道有一条消息被丢弃时，它将向发送者发送一个 NAK，用于查找丢失的术语区域。 在这一点上，请记住，正在复制的是日志，因此接收方可以假定整个日志可用，而不仅仅是很小的窗口大小。 - -* 接收者具有发送者中相同数据结构的副本。 标头和消息被写入日志。 有两个计数器：已完成和高水位标记。 假设已写入消息 1，消息 3 出现在消息 2 之前，因为存在订购问题。 完成的计数器指向消息 1 的末尾。高水位标记指向消息 3 的末尾。消息 2 应该有一个孔。 已完成指向连续的消息流。 如果消息 2 到达完成，则向前移动以指向消息 3 的末尾。 - -* 使用这种方法，您无需保留遗漏邮件的跳过列表或历史记录中有空白的地方。 这些额外的数据结构很复杂，而且速度很慢。 它们导致并发问题和高速缓存未命中。 - -* 日志缓冲区在内存中是完全线性的。 访问它们只需要向前迈进内存，这确实是硬件友好的。 指针追逐在性能上确实很糟糕，因为它们会导致页面错误。 - -* 此表示形式也非常紧凑。 您可以通过记忆尖叫。 - -* 此设计是回到基础的结果。 考虑如何解决丢失，重新排序，保留历史记录，同时保持内存和并发友好的问题。 结果是一个持久的数据结构，其速度比任何现有方法都要快。 [持久数据结构](http://en.wikipedia.org/wiki/Persistent_data_structure) 是一种数据结构，在修改后始终保留其自身的先前版本。 从轨道的功能角度来看，这是一个想法。 学科合作时，有很多东西要学习。 只执行功能性技术或忽略功能性技术是愚蠢的。 - -* 导体始终在完成和高水位线之间寻找间隙。 它将发送 NAK，因此发送方将重新发送日志的该部分。 这是简单且易于调试的。 - -* 要了解消耗了哪些消息，请使用指向字节流中某个位置的计数器。 发布者，发送者，接收者和订阅者都在字节流中保留位置计数器。 这使得监视，应用流量控制和拥塞控制变得容易。 这些计数器在另一个内存映射文件中可用，因此它们可用于单独的监视应用程序。 - -* 协议很难。 您需要注意大规模的自相似行为。 例如，在多播世界中，当出现问题时，您会得到一种称为自相似行为的信息，这种行为会开始发生模式并建立起共振。 因此必须将随机性注入系统。 NAK 必须在将来的某个随机点发送。 这样可以防止订户立即全部锤击源。 - -## 吸取的教训 [ - -* **人们以** n 估算值吸吮。 即使有团队的丰富经验，他们的估计也全都没有了。 估算只是人类不擅长的事情。 - -* **构建分布式系统非常困难** 。 只有不想构建分布式系统的人才有资格构建一个分布式系统，因为他们至少对工作的辛苦程度有所了解。 您只是不能说嘿，让我们创建一个分布式的并发系统。 首先制作一个单线程系统，然后再进行其余工作。 - -* **我们的防御代码比特征代码** 更多。 在分布式系统上，事情可能会大规模出错，并且那些故障需要得到处理。 这并不意味着代码中充满了异常处理程序。 他们知道很多失败案例，但是仍然有很多防御性代码。 - -* **建立分布式系统是对** 的奖励。 看到整个机器网络针对注入的故障进行调整并全部得到纠正是一件很美好的事情。 - -* **从一开始就设计监视和调试** 。 从一开始就让一切可见。 无锁方法的优点之一是，您实际上可以从另一个线程观察状态，这使调试更加容易。 - -* **由于配置** ，我们将 3x-4x 的性能留在桌面上。 程序员和系统管理员的分离是一种反模式。 开发人员不会与没有 root 访问权限的人交谈，而不会与拥有网络访问权限的人交谈。 这意味着系统永远不会配置正确，这会导致大量数据包丢失。 丢失，吞吐量和缓冲区大小都与 密切相关。 我们需要锻炼如何弥合差距，知道参数是什么，以及如何解决它们。 因此 知道您的 OS 网络参数以及如何对其进行调整 。 - -* **Java 的某些部分确实很烂** 。 无符号类型； NIO 系统布满了锁； 很难在沙盒模型中进行堆外工作并获得所需的性能； 字符串编码不应要求复制缓冲区三次； 有些人是成年人，让我们映射和取消映射内存映射文件，并像成年人一样使用套接字。 哈希图周围的垃圾回收问题是痛苦的； 或字节标志会将字节提升为整数，因此您无法将结果分配回一个字节； - -* **Java 的不错部分** 。 工具。 Java 是世界上最糟糕的语言，拥有世界上最好的工具链：IDE，Gradle，HdrHistogram。 Java 的 lambda 和方法句柄非常好。 字节码检测对于调试确实很有用。 例如，Java 8 中的不安全性非常好，这就是计数器无锁递增的方式，并且可以在 CPU 上很好地扩展，并且内存栅栏使构建广播缓冲区成为可能。 优化器很棒。 垃圾回收对于某些类的算法非常有用。 - -* **平均值绝对没有意义** 。 注意百分位数。 - -## 未来 [ - -* 现在功能已完成。 现在进行大量的分析和优化。 - -* 情况看起来很好。 在吞吐量方面已经击败了最好的产品。 可以以每秒 600 万条消息的速度发送 40 字节的小消息，这是非常困难的情况。 时延看起来很棒，那里有最好的商业产品，高达 90％。 除了 90％的百分位数之外，还有很多工作要做，部分是基于算法，​​还有 NIO，选择器和锁。 - -* 接下来是 C ++端口。 - -* Infiniband 和 IPC。 +# Instagram 架构更新：Instagram 有何新功能？ + +> 原文： [http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html) + +![](img/e7b70a6c02b1e7425849dd6d1af801f2.png) + +对 Instagram 的迷恋仍在继续，幸运的是，我们有了一些新的信息流来满足人们的疯狂需求。 因此，请考虑对 [Instagram 架构 Facebook 的收购，以 10 亿美元的价格](http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html) 为基础，主要基于 [扩展 Instagram](http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram) ，Instagram 联合创始人 Mike Krieger 为 AirBnB 技术演讲提供的幻灯片。 本文底部还列出了其他几种信息来源。 + +不幸的是，我们只有一个幻灯片，因此缺少演讲的结缔组织，但它仍然非常有趣，以开发人员出现后我们经常看到的相同的智慧演讲的精神 在战 significant 中花费大量时间后获得空气。 + +如果您希望深入了解技术细节并找到收购 Instagram 的十亿原因，您会感到失望的。 在所有用户和产品之间的关系投入的情感投入中，而不是在如何管理字节方面，可以发现这种魔力。 + +那么 Instagram 有什么新功能？ + +* 一些统计信息： + * Instagram 在不到两年的时间内就达到了 30+百万用户，然后在其 Android 应用程序发布 10 天后猛增至 4000 万用户。 + * Android 发行后，他们在 12 小时内拥有 100 万新用户。 +* Instagram 的使命是交流和分享现实世界。 +* 世界已经改变。 现在有 2 位后端工程师可以将系统扩展到 30+百万用户： + * 最初是两个没有后端经验的人 + * 托管在洛杉矶的一台计算机上，功能不如 MacBook Pro + * 第一天注册 25K，使机器融化，因此他们迁移到了亚马逊 + * 2 位工程师在 2010 年。 + * 2011 年有 3 名工程师 + * 5 位工程师，2012 年，后端 2.5。 这包括 iPhone 和 Android 开发。 + * 稀缺性引起关注。 +* 您最初遇到的大多数扩展问题都不会很吸引人： + * 缩放就像在以 100 mph 的速度行驶时更换汽车上的所有组件。 + * 缺少的 favicon.ico 在 Django 中引起了很多 404 错误 + * memcached -t 4 + * 前叉/后叉 + * 不幸的是，我们没有有关问题所在的详细信息 +* Instagram 哲学： + * 简单 + * 经过优化，可最大程度地减少操作负担 + * 可以检测所有内容 +* 当用户上传带有可选标题和位置的照片时会发生什么？ + * 为用户同步写入媒体数据库。 + * 如果对异步处理进行了地理标记，则将图像发布到 Solr 进行索引。 + * 通过 Redis 中存储的列表传递给关注者。 对于跟随该用户的每个人，媒体 ID 都会被推送到列表中。 在渲染提要时，它们会获取少量 ID，并在内存缓存中查找它们。 +* 扩展数据库： + * Django ORM 和 PostgreSQL + * 选择 Postgres 是因为它具有 PostGIS（PostgreSQL 的空间数据库扩展）。 + * 将数据库移到了自己的计算机上，但是照片不断增长，EC2 中最大的计算机上的内存限制为 68GB + * 下一个策略是垂直分区，将功能转移到自己的服务器上。 Django DB 路由器非常简单，例如，将照片映射到 photodb。 + * 然后，当照片数据库达到 60GB 并且无法再在一台计算机上运行该数据库时，他们开始使用分片。 + * PostgreSQL 可以通过使用 memcached 进行轻度缓存来处理数万个请求。 + * 所有快照均来自从属服务器，从属服务器在拍摄快照之前已停止，然后 XFS 冻结所有驱动器，然后拍摄快照以确保其一致性。 + * 在 EBS 驱动器上使用 Software-RAID 可获得更好的写入吞吐量。 预写日志（WAL）与主数据库位于不同的 RAID 中。 +* 使用了预拆分逻辑分片策略： + * 基于用户 ID 的分片。 + * 分片的问题之一是，分片比机器大。 因此，他们制作了成千上万个逻辑分片，映射到更少的物理节点。 + * 保留逻辑碎片到物理的映射。 + * 当机器装满时，可以将逻辑碎片移动到新机器上以减轻压力。 优点是无需重新分配任何内容。 按间接级别保存。 + * PostgreSQL 的 [模式](http://www.postgresql.org/docs/9.0/static/ddl-schemas.html) 功能非常有帮助，但是我无法从幻灯片中确切地看出来。 + * Membase 使用类似[的方法](http://www.couchbase.com/docs/membase-manual-1.7/membase-architecture.html)。 +* 如下图： + * V1：简单数据库表：（源 ID，目标 ID，状态） + * 需要回答以下问题：我应该关注谁？ 谁跟着我？ 我会遵循 X 吗？ X 跟随我吗？ + * 随着数据库繁忙，他们开始在 Redis 中存储跟随图的并行版本。 这导致一致性问题，这需要引入缓存无效化和许多额外的逻辑。 +* Love Redis 的目标： + * 将复杂的对象缓存到您想做的事中：GET，计数，子范围，成员资格测试 + * 快速插入和快速子集 + * 大小相对有界的数据结构 + * 当 Redis 实例超过 40k req / s 并开始成为瓶颈时，启动另一台计算机，即 SYNCing to master，并向其发送读取查询不到 20 分钟。 +* 监视所有内容。 + * 提出类似问题：系统现在如何？ 这与历史趋势相比如何？ + * [Statsd](http://github.com/etsy/statsd/) -一种网络守护程序，可将数据聚合并汇总为石墨 + * 具有两种统计信息：计数器和计时器。 + * 统计信息可以动态添加 + * 计数器存储着从每秒注册次数到点赞次数的所有内容 + * 计时提要的生成时间，关注用户所需的时间以及任何其他主要操作。 + * 实时允许立即评估系统和代码更改 + * 日志记录调用以较低的采样率插入整个 Web 应用程序，因此不会影响性能。 + * [Dogslow](http://blog.bitbucket.org/2011/05/17/tracking-slow-requests-with-dogslow/) -监视正在运行的进程，如果发现任何花费超过 N 秒的时间，它将快照当前进程并将文件写入磁盘。 + * 找到的响应要花 1.5 秒钟以上的时间才能返回，响应通常卡在 memcached set（）和 get_many（）中。 + * 他们使用 Munin 看到 Redis 正在处理 50k req / s +* node2dm-一个 node.js 服务器，用于向 Android 的 C2DM 服务传递推送通知 + * 由 Instagram 撰写，因为他们找不到其他东西。 + * 处理了超过 500 万个推送通知 + * 它是 [开源](http://github.com/Instagram/node2dm) +* 与出色的顾问团聚。 Instagram 从一个好的堆栈和糟糕的配置开始。 他们最终在两方面都做得很好。 现在，他们几乎没有停机时间，每小时部署几次，而综合测试仅需 5 分钟即可运行。 其中一些来自技能和先验知识，但大部分来自适应性和当顾问（例如，亚当·德安杰洛）提出更好的选择时愿意迅速转换的意愿。 （此摘要来自参加演讲的 [鲜寿](http://news.ycombinator.com/item?id=3832556) ）。 +* 您无法经常使用的工程师解决方案，因为它们已损坏： + * 进行广泛的单元和功能测试 + * 保持干燥-不要重复自己 + * 使用通知和信号拥抱松散耦合。 + * 用 Python 完成大部分工作，并在必要时使用 C 语言 + * 使用频繁的代码检查和拉取请求将事情留在共享的头脑中 +* 可以动态添加的实时统计信息，使您无需等待接收新数据即可进行诊断和交火。 +* 如果可能要考虑读取容量，则理想的是提前提起读取从属设备并使其轮换使用； 但是，如果出现任何新的读取问题，请提前了解如何轮换使用更多读取容量的选择。 +* 通常，后端基础架构中的一个成为瓶颈。 弄清楚实际的实时应用服务器遇到的问题可以帮助解决这个问题。 +* 使用您知道的技术/工具，然后首先尝试使其适应简单的解决方案。 +* 对 Redis 等核心数据存储有多种补充。 +* 尽量不要让两个工具完成相同的工作。 +* 如果需要，知道在哪里卸载负载。 例如，显示较短的提要。 +* 不要重新发明轮子。 例如，如果应用服务器快要死了，请不要编写其他监视系统。 HAProxy 已经执行了此操作，因此请使用它。 +* 专注于让自己拥有更好的东西：快速，美观，照片共享。 使快速零件更快。 我们所有的请求都可以占用 50％的时间吗？ +* 保持敏捷，提醒自己重要的事情。 +* 用户不在乎您编写自己的数据库。 +* 不要将自己的内存数据库作为主要数据库存储的解决方案。 +* 遇到扩展挑战时，您别无选择。 +* 不要过度优化或期望提前知道网站的规模 +* 不要以为会有其他人加入并对此进行照顾。 +* 对于社交创业公司来说，解决扩展方面的挑战很少（如果有的话） +* 仅将经过优化以简化操作的软件添加到堆栈中 +* 玩得开心。 +* Instagram 在理解设计中的心理学力量而非技术方面取得了更多成功。 +* 想法是可抛弃的：如果一个想法行不通，您很快就会转向另一个想法。 +* 关键字是简单性。 +* 时间很重要。 你自己做运气。 +* 社交网络的真正社交部分： + * 出席斯坦福大学，全球最大的风险投资家的注意力将转移到您身上。 + * 在竞争激烈的初创企业中，成功与您所认识的人和所认识的人同样重要。 谈话后，请务必花一些时间来认识您周围的人。 + * 您建立的社交关系与成功直接相关。 企业家有一些偶然性，但是造雨者是企业家需要见面的人，以便建立成功的联系。 （摘自尤因·马里昂·考夫曼基金会资深研究员特德·佐勒）。 ## 相关文章 -* [在 Reddit](http://www.reddit.com/r/programming/comments/2ml0gb/aeron_do_we_really_need_another_messaging_system/) 上/ [在黑客新闻](https://news.ycombinator.com/item?id=8619735)上 - -* [Aeron 高性能开源消息传输](http://gotocon.com/dl/goto-berlin-2014/slides/MartinThompson_AeronTheNextGenerationInOpenSourceHighPerformanceMessaging.pdf) - -* [Martin Ahompson 撰写的“ Aeron：开源高性能消息传递”](https://www.youtube.com/watch?v=tM4YskS94b0) - -* [GitHub 上的 Aeron](https://github.com/real-logic/Aeron) - -* Aeron [协议规范](https://github.com/real-logic/Aeron/wiki/Protocol-Specification) 和 [设计概述](https://github.com/real-logic/Aeron/wiki/Design-Overview) 。 - -* [日志：每位软件工程师应了解的有关实时数据统一抽象的知识](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying) - -* [Google：驯服长时间延迟的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) - -* [伟大的微服务与整体应用 Twitter 近战](http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html) - -* [简单二进制编码](http://mechanical-sympathy.blogspot.com/) - -* [本周要去 Strangeloop 吗？ 您的“必看”清单上有哪些讲座？](https://groups.google.com/forum/#!topic/mechanical-sympathy/fr7moLcsuiI) - -* [Aeron 性能测试](https://groups.google.com/forum/#!topic/mechanical-sympathy/GrEce0gP7RU) - -* [策略：利用处理器亲和力实现高性能和可预测的性能](http://highscalability.com/blog/2012/3/29/strategy-exploit-processor-affinity-for-high-and-predictable.html) - -* [12 种将吞吐量提高 32 倍，将延迟降低 20 倍的方法](http://highscalability.com/blog/2012/5/2/12-ways-to-increase-throughput-by-32x-and-reduce-latency-by.html) - -* [破坏了 4 个现代硬件神话-内存，HDD 和 SSD 真的是随机访问吗？](http://highscalability.com/blog/2013/6/13/busting-4-modern-hardware-myths-are-memory-hdds-and-ssds-rea.html) - -* [对 Apache Kafka 进行基准测试：每秒 200 万次写入（在三台便宜的机器上）](http://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines) - -* [HdrHistogram](https://github.com/HdrHistogram/HdrHistogram) -高动态范围（HDR）直方图。 - -非常感谢您提供大量信息来总结并做得很好，但是声明“发布者和订阅者之间的全双工通信”并不是很准确。 发布者发布，订阅者订阅。 您可以在两台计算机之间进行双向通信，但是每台计算机都需要分别注册一个发布者和一个订阅者。 一对发布者和订阅者只是一种通信方式。 +* [Slidedeck](http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram) -在 Airbnb 技术讲座上，Instagram 的 Mike Krieger 在扩展 Instagram 上 +* [如何扩展 10 亿美元的创业公司：Instagram 联合创始人的指南](http://techcrunch.com/2012/04/12/how-to-scale-a-1-billion-startup-a-guide-from-instagram-co-founder-mike-krieger/) +* [在 HackerNews 上](http://news.ycombinator.com/item?id=3831865) ， [在 HackerNews 上](http://news.ycombinator.com/item?id=3804351) +* [成为 Instagram 成功背后的老路](http://www.nytimes.com/2012/04/14/technology/instagram-founders-were-helped-by-bay-area-connections.html) +* [Instagram 的用户数现在达到 4000 万，在过去 10 天内吸引了 1000 万新用户](http://techcrunch.com/2012/04/13/instagrams-user-count-now-at-40-million-saw-10-million-new-users-in-last-10-days/) +* [在十二小时内使 Instagram 拥有超过一百万的新用户](http://instagram-engineering.tumblr.com/post/20541814340/keeping-instagram-up-with-over-a-million-new-users-in) -另外，当您说“并非所有邮件都被确认”时，我们不会确认数据包。 我们使用 NAK 代替，我的理解是实际上大多数现代多播协议使用 NAK 代替 ACK 来最小化内爆效应。 +> 通过存储在 Redis 中的列表传递给关注者。 对于跟随该用户的每个人，媒体 ID 都会被推送到列表中。 在渲染提要时，它们会获取少量 ID，并在 memcached 中查找它们 -太好了，谢谢理查德的改正！ +我是 Web 技术的新手，很好奇：在服务器上已经设置 Redis 时使用 memcached 有什么意义？ 谢谢。 -“面对面”，认真吗？ +@Oleg：我认为 user_id 可能在存储的 redis 中，并且 memcache 将使整个用户记录+来自主数据存储的联接数据。 -是的，我猜这翻译得不好。 它引用了犹他爵士乐团的约翰·斯托克顿（John Stockton），他是 NBA 历史上最好的球员之一。 因此，这是一个受人尊敬的术语，这就是它的意思。 \ No newline at end of file +知道 Instagram 图片的磁盘平均大小是多少吗？ \ No newline at end of file diff --git a/docs/92.md b/docs/92.md index 496ed06..69a853a 100644 --- a/docs/92.md +++ b/docs/92.md @@ -1,235 +1,131 @@ -# Wix 的 Nifty Architecture 技巧-大规模构建发布平台 +# 搜索技术剖析：blekko 的 NoSQL 数据库 -> 原文： [http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html](http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html) +> 原文： [http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html) -![](img/51ad9a97b669a9cbea8846d65dbba291.png) +![](img/36ab01ea97bfa8e04f1ca36ac0ea0183.png) -[Wix](http://www.wix.com/) 长期运营网站。 作为基于 HTML5 的所见即所得（WYSIWYG）网络发布平台，他们已经创建了超过 5400 万个网站，其中大多数网站每天的网页浏览量不到 100。 因此，传统的缓存策略不适用，但仅需四个 Web 服务器即可处理所有流量。 这需要一些聪明的工作。 +*这是 blekko 的首席技术官 Greg Lindahl 的来宾帖子（[第 2 部分](http://highscalability.com/blog/2012/5/28/the-anatomy-of-search-technology-crawling-using-combinators.html)，[第 3 部分](http://highscalability.com/blog/2012/7/9/data-replication-in-nosql-databases.html)），该网站是垃圾邮件免费搜索引擎，3 月的独立访问者超过 350 万。 Greg Lindahl 是 PathScale 的创始人兼杰出工程师，当时他是 InfiniPath 低延迟 InfiniBand HCA 的架构师，该架构用于构建紧密耦合的超级计算集群。* -[Wix 后端工程负责人 Aviran Mordo](https://twitter.com/aviranm) 在精彩的演讲中描述了他们的解决方案：[规模](http://www.infoq.com/presentations/wix-architecture)的 Wix 体系结构。 他们开发的最佳传统就是专业化。 他们仔细分析了他们的系统，并弄清楚了如何以一些最有趣的方式实现其积极的高可用性和高性能目标。 +想象一下，您已经疯狂到足以考虑构建搜索引擎了。 这是一项艰巨的任务：回答大多数查询所需的最小索引大小是数十亿个网页。 要对数十亿个网页进行爬网和建立索引，就需要一个群集，其中包含几 PB 的可用磁盘（即几千个 1 TB 的磁盘），并且产生的索引大小约为 100 TB。 -Wix 使用**多个数据中心和云**。 我之前从未见过的是它们将数据复制到多个数据中心，Google Compute Engine 和 Amazon。 并且在失败的情况下它们之间具有备用策略。 +快速提供查询结果涉及将大多数索引放在 RAM 或固态（闪存）磁盘上。 如果您可以以 3,000 美元的价格购买具有 100 GB RAM 的服务器，那么这 1,000 台服务器的资本成本为 300 万美元，加上每年服务器托管成本（电源/散热/空间）约为 100 万美元。SSD 替代方案需要 更少的服务器，但是每秒提供更少的查询，因为 SSD 比 RAM 慢得多。 -Wix **不使用交易**。 相反，所有数据都是不可变的，并且它们使用简单的最终一致性策略来完美匹配其用例。 +您可能会认为，亚马逊的 AWS 云将是降低启动搜索引擎成本的好方法。 不是，原因有四个： -Wix **不缓存**（就像在大缓存层中一样）。 取而代之的是，他们非常注意优化渲染路径，以便每个页面的显示时间均不到 100ms。 +1. 爬网和建立索引一直需要大量资源； 您有时无法仅通过租用大多数服务器来省钱。 +2. 亚马逊目前不出租带有 SSD 的服务器。 将索引放入 Amazon 的 RAM 中非常昂贵，并且仅对拥有几％市场份额的搜索引擎有意义。 +3. 亚马逊仅出租有限数量的磁盘 I / O 与内存大小与核心数量的比率。 事实证明，相对于其他所有产品，我们需要大量的磁盘 I / O，这使 Amazon 的成本效益降低。 +4. 在某种集群规模下，一家初创公司具有足够的规模经济优势，可以超过亚马逊的成本+利润率。 在发布时（2010 年 11 月），blekko 拥有 700 台服务器，而我们目前有 1,500 台。 这远远超出了收支平衡点。 -Wix 从一开始就具有单一的体系结构，并有意识地**迁移到了服务体系结构**，该过程使用了一种非常刻意的过程来识别服务，该服务可以帮助任何考虑同一步骤的人。 +## 软件 -这不是您的传统 LAMP 堆栈或本机云。 Wix 有点不同，您可以在这里学到一些东西。 让我们看看他们是如何做到的... +那仅仅是硬件：我们还需要一个软件系统来管理存储以及对集群中 Web 爬网和索引数据的访问。 我们的目标之一是设计一种存储体系结构，当在搜索引擎环境中使用 Web 大小的数据集时，将为程序员带来生产力上的优势。 -## 统计信息 +我们的目标是： -* 54 个以上的网站，每月有 100 万个新网站。 +* 一种将数据存储在类似于数据库表的系统中 +* 同一集群中的实时（查询服务）和批处理（爬网和索引）处理 +* 添加对倒排索引的直接支持的能力，该索引非常适合系统的其余部分 +* 出色的程序员生产力，包括： + * 无缝集成主要实现语言的数据存储和数据结构 + * 抵抗常见的数据库和群集数据库问题，例如热点和死锁/活锁 + * 数据存储区，可实现常规数据库操作（如 BASE 和 CRUD），并有效地实现并协助并行编程结构（如工作队列）。 + * 支持快速完成初始批处理作业结果的周转时间，从而使程序员可以快速发现其批处理作业做错了什么 +* 可扩展到数千个磁盘设备： + * 磁盘故障是将群集扩展到大尺寸时最常见且令人讨厌的问题 + * 面对故障逐渐退化 + * 理想情况下，群集故障 1％只会使处理能力和存储量减少 1％。 例如，在节点上重建 RAID 卷期间，服务器上 RAID 的使用不当会导致吞吐量降低超过 1％。 此外，磁盘故障在大型集群中非常常见，以至于我们希望在准备好一次，一周或一个月后修复多个节点之前就不需要人工干预。 +* 由于可用性的原因，我们希望使用群体算法来实现尽可能多的子系统，而不是使用 Paxos 来选择主节点。 [https://zh.wikipedia.org/wiki/Paxos_algorithm](https://en.wikipedia.org/wiki/Paxos_algorithm) -* 超过 800 TB 的静态数据，每天有 1.5 TB 的新文件 +## 组合器 -* 3 个数据中心+ 2 个云（Google，Amazon） +在传统的数据库系统中，对数据库的更新是在事务中完成的，其中程序锁定数据库的一行或多行，进行一些更改，然后提交或中止整个事务。 大多数 NoSQL 数据库都将事务限制为锁定&来修改单个行，并限制可以在事务内完成的计算类型。 -* 300 台服务器 +在 blekko 的数据存储区中，我们严重依赖于称为合并器的构造在数据库单元级别进行处理。 组合器是对数据库单元进行的原子操作，该操作是关联的，最好是可交换的。 “ Add（n）”是一个简单组合器的示例； 它将 n 加到单元格中的任何数字上。 至关重要的是，它不会将总和返回给调用方。 它只是启动加法。 -* 每天有 7 亿个 HTTP 请求 +如果一堆数据库节点想在数据库的同一单元中加 1，而又不了解该单元的最终值是什么，则可以将这些操作组合到集群中的层次结构中，从而进行最终的磁盘操作 是一个将初始增量之和相加的操作。 -* 共 600 人，R 区& D 共 200 人 +![](img/786fcb4b60e4084b2df67361ef0746a5.png) -* 约有 50 个服务。 +加法是关联和可交换的事实意味着我们（最终）将在此单元格的所有 3 个副本中获得相同的答案。 组合的层次结构意味着与天真的实现相比，事务总数大大减少了，因为天真的实现每个过程都直接与单元的 3 个副本进行对话，而每个加法操作都会导致 3 个立即事务。 -* 需要 4 个公共服务器才能为 4500 万个网站提供服务 +### 日志计数组合器 -## 平台 [ +搜索引擎经常需要计算一组中的唯一项。 示例包括计算网站的链接数，链接到该网站的唯一地理区域的数量以及链接到该网站的唯一的 C 类 IP 网络的数量等等。 尽管我们总是可以运行 MapReduce 作业来获得这些项目的准确计数，但我们希望在任何时间点都知道这些计数。 保持完美的计数将需要保留大量数据，因此我们发明了一种**近似方法**，该方法仅用 16 个字节就可以对多达十亿个事物进行计数，精度为±50％。 -* MySQL +该组合器（我们称为对数计数）以可交换和关联的方式实现-您可以将其中两个的位与进行组合以合并其计数。 它还具有以下属性：如果您多次计数任何字符串，则最多只能更改一次答案。 最后一个属性意味着它是可重新运行的，即如果在数据库中进行了两次相同的事务，则答案不会改变。 -* Google 和亚马逊云 +### TopN 组合器 -* CDN +搜索引擎的另一种常见操作是记住集合中最重要的 N 个项目。 这用于我们不想记住集合中的所有项目以减小尺寸的情况。 例如，我们可能希望经常将最重要的 2500 个传入 URL 的[锚文本]( https://en.wikipedia.org/wiki/Anchor_text)访问到我们曾经抓取过的每个 URL。 -* 厨师 +TopN 组合器可以在适合数据库的单个单元格的有限大小的数组中表示前 N 个 URL： -## 进化 [ +![](img/0ba465d712fdf97b661484e69f880c5b.png) -* 简单的初始整体架构。 从一台应用服务器启动。 这是最简单的入门方法。 进行快速更改并部署。 它使您到达特定的位置。 +随着我们抓取新的网页，可以对 TopN 组合器进行增量更新，并且这些更新的价格不昂贵。 可以在单个磁盘操作中读取它，而无需索引或排序或读取不位于前 N 个位置的 URL 的任何数据。感谢用于决定哪个 URL 最适合 N 的行列，它是可交换的 和关联。 而且它可以重新运行。 - * Tomcat，Hibernate，自定义 Web 框架 +如果我们使用时间作为排名，则可能会有其他技巧。 这使我们能够有效地记住最近的 N 个事物或最早的 N 个事物。 - * 使用的状态登录。 +到目前为止，我们已经在数据库表中将组合器用作单个单元格。 也可以在我们程序中的变量中使用**； 它们的实现将它们存储为字符串，读取值需要调用“ finalize”函数。 例如，此功能将日志计数中的 16 个字节的位字段转换为整数的近似项目数。** - * 忽略了性能和扩展性的任何概念。 +### 元组合器：哈希组合器 -* 快进了两年。 +如果数据库中的一个单元格包含（键，值）对的哈希，则哈希元组合器可用于原子地仅更新一些（键，值）对，其余的保持不变。 这给了我们极大的自由，可以将数据库中的列设置为对程序员有意义的列，而不必为了使原子地进行更改而必须将多余的内容提升为列。 - * 仍然是一台完成所有任务的单片服务器。 +### 减少地图/缩小 - * 在一定规模的开发人员和客户眼中，它们阻碍了他们的发展。 +由于我们用组合器表示数据库表，为什么不使用组合器来改组并减少 MapReduce 作业的输出？ 然后我们可以编写遍历数据库中某个表的 MapJob，然后使用组合器将其输出写回到数据库中。 让我们对网络进行字数统计： - * 功能之间的依存关系问题。 一处的更改导致整个系统的部署。 不相关区域的故障导致整个系统停机。 +> “ / crawl / url”中的 foreach 行 +> +> html 列中的 foreach 单词 +> +> comb_add（“ / wordcount”，word，1） -* 是时候把系统分开了。 +在此伪代码中，我们遍历表/ crawl / url 中的所有 html 文档，对于找到的每个单词，我们在表“ / wordcount”中增加相应的行。 编程人员不再需要考虑改组/减少步骤应以哪种**中间形式**作为输入，或指定减少功能。 - * 采用了一种服务方法，但这并不容易。 您如何将功能分解为服务？ +这种单词计数方法的第二个特点是，上述功能还可以在流上下文中使用**，将新抓取的文档的单词计数添加到表“ / wordcount”中的现有计数。 表示 MapReduce 计算的通常方法不能在流计算中使用相同的代码。** - * 查看了用户在系统中的工作，并确定了三个主要部分：编辑网站，查看由 Wix 创建的网站，提供媒体。 +第三个功能是该 MapJob 的第一个输出在 MapJob 启动后的几分钟后出现在/ wordcount 表中。 大多数 MapReduce 系统直到每个分片完成后才开始随机播放和还原。 具有**快速，部分答案**可使程序员更快地找到其 MapJob 中的错误。 - * 编辑网站包括服务器中数据的数据验证，安全性和身份验证，数据一致性以及许多数据修改请求。 +## 我们是否实现了所有要求？ - * 网站制作完成后，用户将对其进行查看。 观看者比编辑者多 10 倍。 所以现在的问题是： +现在，我们已经在这个本地数据存储上拥有近 3 年的运营经验，现在很高兴回头看看，我们基本上满足了我们预先设定的所有要求。 在本文的初始篇中，我们仅讨论了数据存储的部分功能，但是我们在这里讨论的内容已广为人知。 我们的数据存储区： - * 高可用性。 高可用性是最重要的功能，因为它是用户的业务。 +* 看起来像表格数据库 +* 在同一集群中支持实时和批处理 +* 支持高程序员效率 - * 高性能 +在本系列的下一部分中，我们将更详细地研究 Web 爬网，并使用组合器实现爬网程序。 - * 高流量 +这篇文章中的所有内容看起来都很简单容易。 我希望人们不要错过这里介绍的算法和数据库调用的类型具有可伸缩性。 经验法则（我刚刚完成）是只要您将数据存储区调用的大部分都考虑为可交换的，您做对了，它就会扩展并可以期望。 我敢打赌，该系统不仅可以在水平方向上很好地缩放，而且可以在单台机器上高效地运行，并且在垂直方向上也可以很好地缩放。 这个系统不仅是 BIG-DATA，它还是 EFFICIENT-BIG-DATA，这更重要，因为它的大小:)不错的文章，加上 plus100 也可避免沉迷于流行词的不必要使用:) - * 长尾巴。 有很多网站，但是它们很小。 每个站点每天可能会获得 10 或 100 个页面浏览量。 长长的尾巴使缓存不适合可伸缩性策略。 缓存变得非常低效。 +>快速提供查询结果涉及将大多数索引放在 RAM 或固态（闪存）磁盘上。 - * 媒体服务是下一个重要服务。 包括 HTML，javascript，css，图像。 需要一种在大量请求下为文件提供 800TB 数据的方法。 胜利是静态内容是高度可缓存的。 +仅当查询在查询空间之间均匀分布时，这才是正确的。 在现实生活中，查询空间由一小部分“热”（经常请求）查询和一长串“冷”（很少请求）查询组成。 因此，在从 I / O 绑定存储中服务“冷”查询的同时，可以在 RAM 中仅缓存一小部分索引，这对应于“热”查询。 这可以显着减少索引所需的 RAM 量，同时保持良好的 qps。 - * 新系统**看起来像**，位于三个网段服务下面的网络层：编辑器网段（任何编辑数据的文件），媒体网段（处理静态文件，只读），公共网段（文件的第一位是 已查看，只读）。 +搜索查询往往有一个“长尾巴”，因此专用于仅服务于头部的 ram 会使大多数查询脱离缓存。 我们努力在所有查询的 95/99％上实现目标延迟-我们在办公室的大型状态监视器上具有跟踪此延迟的图形，以及在我们掉线时会唤醒人们的操作警报。 对于主流搜索服务而言，在 50％的查询上实现合理的延迟是不够的。 具有 SLA 的合作伙伴也不会接受该级别的性能。 -## 如何构建服务的准则 [ +日志计数组合器上的准确性是否正确？ 那么，100,000 意味着 50,000 至 150,000 之间的东西？ 如果是这样，我很好奇具有这种准确性的计数将达到什么目的。 另外，我应该首先说这看起来很酷。 是否有计划实施后续文章，还是 Blekko 秘密调味酱过多？ 谢谢。 -* 每个服务都有自己的数据库，只有一个服务可以写入数据库。 +让我们做简单的数学。 100Tb 索引对应于 50 x 2Tb HDD。 每个 HDD 可以执行 100 IOPS（10 毫秒随机搜寻延迟）。 因此 50 个 HDD 可以执行 5K qps。 这意味着该应用程序可以轻松地每秒处理 5K 个“冷”索引查询，每个查询具有 10ms 的延迟，而无需计算从 RAM 执行的数百万个“热”索引查询。 如果将 HDD 替换为 SSD，则“冷”索引查询的性能可以轻松提高到 500K qps 甚至更高。 -* 仅通过服务 API 访问数据库。 这支持将关注点分离并从其他服务隐藏数据模型。 +日志计数示例：计算到 URL 的入站链接数。 在 0 和 1（合格）入站链接之间的差值中大约有与在 128 和 256 之间相同的信号。对于像这样的对数分布上出现的现象，用两个作品的渐进幂中的误差进行近似计数。 -* 出于性能原因，授予其他服务只读访问权限，但只能写入一个服务。 （是的，这与之前所说的相矛盾） +实际上，我们有一个新的组合器，该组合器在我们的系统中大部分已替换为 logcount，称为 adapcount。 您以字节为单位指定要使用的空间量，使用的空间越多，精度越好。 因此，对于 2k，您可以有+/- 5％的值（我忘了细节）。 -* **服务是无状态的**。 这使得水平缩放变得容易。 只需添加更多服务器。 +噢，是的，我完全忘记提及 logcount 有很多朋友，这些朋友更大，更精确。 最不精确的版本用于我们拥有大量统计数据的地方，就像我们为 180 亿个网页所保留的统计数据一样，我们已经看到了链接但尚未抓取。 -* **没有交易**。 除帐单/金融交易外，所有其他服务均不使用交易。 这个想法是通过消除事务开销来提高数据库性能。 这使您考虑如何在不使用数据库事务的情况下将数据建模为具有逻辑事务，避免出现不一致的状态。 +当第一句话包含“无垃圾邮件搜索引擎”时，我差点弯腰阅读。 但是哎呀，我束手无策： +http://blekko.com/ws/site:bigresource.com -* 设计新服务**时，缓存不属于体系结构**。 首先，使服务尽可能地具有性能，然后部署到生产环境，看看其性能，然后，如果存在性能问题，并且您无法优化代码（或其他层），则只能添加缓存。 +这是一个非常有趣的帖子。 您是否会碰巧有更多关于组合器和系统技术细节的文章/白皮书或其他资源？ 听起来很有趣:) -## 编辑器细分 +感谢分享 -* 编辑器服务器必须处理大量文件。 +艺术 -* 在 MySQL 中存储为不可变 JSON 页（每天约 250 万个）的数据。 +听起来像一个有趣的小项目。 -* **MySQL 是一个很棒的键值存储**。 密钥基于文件的哈希函数，因此密钥是不可变的。 通过主键访问 MySQL 非常快速高效。 - -* **可伸缩性与权衡**有关。 我们要进行哪些权衡？ 不想使用 NoSQL，因为它们会牺牲一致性，并且大多数开发人员都不知道该如何处理。 因此，请坚持使用 MySQL。 - -* **活动数据库**。 网站建成后发现，只有 6％的网站仍在更新中。 这样，这些活动站点就可以存储在一个真正快速且存储量相对较小（2TB）的数据库中。 - -* **存档数据库**。 对于不经常访问的站点，所有过时的站点数据都移至相对较慢但具有大量存储空间的另一个数据库中。 三个月后，数据被推送到该数据库，因为访问率低。 （可能会说这是一种隐式缓存策略）。 - -* 为呼吸提供了很大的成长空间。 大型归档数据库的速度很慢，但这没关系，因为数据使用的频率不高。 首次访问时，数据来自存档数据库，但是随后将其移至活动数据库，因此以后的访问速度很快。 - -## 编辑器细分市场的高可用性 - -* 拥有大量数据，很难为所有内容提供高可用性。 因此，**查看关键路径**，对于网站而言，该路径就是网站的内容。 如果小部件出现问题，则大多数网站仍将正常工作。 在保护关键路径上投入了大量资金。 - -* 防止数据库崩溃。 想要快速恢复。 复制数据库并将故障转移到辅助数据库。 - -* **防止数据损坏和数据中毒**。 不必一定是恶意的，一个漏洞足以破坏枪管。 所有数据都是不可变的。 修订存储了所有内容。 如果无法修复损坏，最坏的情况是还原到数据可以正常使用的版本。 - -* 防止不可用。 网站必须一直工作。 这推动了**在不同地理位置和多个云**之间复制数据的投资。 这使得系统非常有弹性。 - - * 在网站编辑会话上单击保存会将 JSON 文件发送到编辑器服务器。 - - * 服务器将页面发送到活动 MySQL 服务器，该服务器已复制到另一个数据中心。 - - * 将页面保存到本地后，将启动一个异步过程，将数据上传到静态网格（即媒体段）。 - - * 将数据上传到静态网格后，系统会将通知发送到在 Google Compute Engine 上运行的存档服务。 存档会转到网格，下载页面，然后将副本存储在 Google 云中。 - - * 然后，通知会发送回编辑器，说明页面已保存到 GCE。 - - * 另一个副本已从 GCE 保存到 Amazon。 - - * 收到最后一条通知，这表示当前数据修订版有三份副本：一份在数据库，静态网格中，以及在 GCE 上。 - - * 当前版本有 3 个副本。 对于旧版本，有两个版本（静态网格，GCE）。 - - * 该过程是自修复的。 如果失败，则下次用户更新其网站时，所有未上传的内容都会重新上传。 - - * 孤立文件被垃圾回收。 - -## 没有数据库事务的数据建模 - -* 不想出现这样的情况，即用户编辑了两个页面，而数据库中只保存了一个页面，这是一种不一致的状态。 - -* 获取所有 JSON 文件，并将它们一个接一个地粘贴在数据库中。 保存所有文件后，将发出另一个保存命令，其中**包含上载到的已保存页面的所有 ID** （这是内容的哈希，是静态服务器上的文件名）的清单。 静态服务器。 - -## 媒体段 [ - -* 存储大量文件。 800TB 的用户媒体文件，每天上传的 3M 文件和 500M 的元数据记录。 - -* 图像被修改。 它们针对不同的设备调整了大小并进行了锐化。 可以插入水印，还可以进行音频格式转换。 - -* 构建了一个最终一致的分布式文件系统，该系统具有多数据中心感知能力，并且可以跨 DC 自动回退。 这是在亚马逊之前。 - -* 难以忍受。 32 台服务器，每 9 个月翻一番。 - -* 计划将内容推送到云以帮助扩展。 - -* **供应商锁定是一个神话**。 全部都是 API。 只需更改实施，您就可以在几周内迁移到不同的云。 - -* **真正使您失望的是数据**。 将 800TB 的数据转移到另一个云上真的很困难。 - -* **当他们将所有数据移至 GCE 时，他们破坏了 Google Compute Engine** 。 他们达到了 Google 云的极限。 经过 Google 的一些更改后，它现在可以使用了。 - -* 文件是不可变的，因此高度可缓存。 - -* 图像请求首先进入 CDN。 如果映像不在 CDN 中，则请求将转到其位于奥斯丁的主数据中心。 如果图片不在 Austin 中，则请求转到 Google Cloud。 如果不在 Google 云中，它将转到坦帕的数据中心。 - -## 公共细分 - -* 解析 URL（其中的 4500 万个），分派到适当的渲染器，然后渲染为 HTML，站点地图 XML 或机械手 TXT 等。 - -* **公共 SLA 是在高峰流量**时，响应时间为< 100ms。 网站必须可用，而且速度也要很快。 记住，不要缓存。 - -* 当用户在编辑页面后单击“发布”时，包含对页面的引用的清单将被推送到“公共”。 路由表也已发布。 - -* **最小化服务中断跳**。 需要 1 个数据库调用才能解析路由。 1 RPC 调用，将请求分派到渲染器。 1 个数据库调用以获取站点清单。 - -* 查找表缓存在内存中，每 5 分钟更新一次。 - -* 数据存储的格式与编辑器使用的格式不同。 **以非规范化格式**存储，已针对主键读取进行了优化。 所需的所有内容都在单个请求中返回。 - -* **最小化业务逻辑**。 数据将被规格化和预先计算。 当您大规模处理每项操作时，每增加一毫秒，这就是 4,500 万次，因此必须证明在公共服务器上发生的每项操作都是合理的。 - -* 页面渲染。 - - * 公用服务器返回的 html 是 **bootstrap html** 。 这是一个包含 JavaScript 导入和 JSON 数据（引用网站清单和动态数据）的外壳。 - - * **渲染已卸载到客户端**。 笔记本电脑和移动设备非常快，可以处理渲染。 - - * 选择 JSON 是因为它易于解析和可压缩。 - - * **更容易修复客户端**上的错误。 只需重新部署新的客户端代码。 在服务器上完成渲染后，将缓存 html，因此，修复错误需要**再次重新渲染数百万**个网站。 - -## 公共段的高可用性 - -* 目标是永远可用，但事情还是会发生。 - -* **在**美好的一天：浏览器发出请求，该请求通过负载平衡器到达数据中心，到达公共服务器，解析路由，到达渲染器，html 返回到 浏览器，然后浏览器运行 javascript。 javascript 会获取所有媒体文件和 JSON 数据，并呈现一个非常漂亮的网站。 然后，浏览器向存档服务发出请求。 存档服务以与浏览器相同的方式重放请求，并将数据存储在缓存中。 - -* 在糟糕的日子**，数据中心丢失**，这确实发生了。 所有不间断电源系统都死了，数据中心关闭了。 DNS 已更改，然后所有请求都转到了辅助数据中心。 - -* 在糟糕的日子**公众失去了**。 当负载均衡器获得一半配置，因此所有公共服务器都消失了时，就会发生这种情况。 或者可以部署一个错误版本，该版本开始返回错误。 如果公共服务器不可用，负载平衡器中的自定义代码通过路由到存档服务以获取缓存的缓存来解决此问题。 这种方法意味着即使 Public 崩溃，客户也不会受到影响，即使当时系统正在响起警报。 - -* 糟糕的一天**，互联网糟透了**。 浏览器发出请求，转到数据中心，转到负载平衡器，获取 html。 现在，JavaScript 代码必须获取所有页面和 JSON 数据。 转到 CDN，转到静态网格并获取所有 JSON 文件以呈现站点。 在这些过程中，Internet 问题可能会阻止文件被返回。 JavaScript 中的代码表示如果您无法到达主要位置，请尝试从存档服务获取它，如果失败，请尝试编辑器数据库。 - -## 吸取的教训 [ - -* **确定您的关键路径和关注点**。 想一想您的产品如何运作。 制定使用方案。 将精力集中在这些方面，因为它们可以带来最大的收益。 - -* **转到多数据中心和多云。** 在关键路径上构建冗余（以提高可用性）。 - -* **对数据进行非规范化并最小化进程外跳数（以提高性能）**。 进行预校正并尽一切可能使网络颤动最小化。 - -* **利用客户端的 CPU 能力**。 这样可以节省服务器数量，并且更容易修复客户端中的错误。 - -* **从小处着手，完成任务，然后找出下一步**的去向。 Wix 做了他们需要做的事情，以使其产品正常工作。 然后，他们有条不紊地迁移到复杂的服务体系结构。 - -* **长尾巴需要其他方法**。 Wix 不会缓存所有东西，而是选择优化渲染路径之外的内容，并将数据保留在活动数据库和存档数据库中。 - -* **变为不可变**。 不变性对体系结构具有深远的影响。 它影响从客户端到后端的所有内容。 这是解决许多问题的理想解决方案。 - -* **供应商锁定是一个神话**。 全部都是 API。 只需更改实施，您就可以在几周内迁移到不同的云。 - -* **真正使您失望的是数据**。 将大量数据转移到不同的云真的很困难。 - -有一个问题：每天的流量如何达到 700 M？ StackExchange 每天有 1.5 亿，而 Alexa 评级更高。 \ No newline at end of file +如果要为职位实施垂直搜索引擎，应该使用哪个数据库？ \ No newline at end of file diff --git a/docs/93.md b/docs/93.md index cb6f78d..bafeaa5 100644 --- a/docs/93.md +++ b/docs/93.md @@ -1,207 +1,70 @@ -# 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。 +# Pinterest 体系结构更新-1800 万访问者，增长 10 倍，拥有 12 名员工，410 TB 数据 -> 原文： [http://highscalability.com/blog/2014/10/13/how-league-of-legends-scaled-chat-to-70-million-players-it-t.html](http://highscalability.com/blog/2014/10/13/how-league-of-legends-scaled-chat-to-70-million-players-it-t.html) +> 原文： [http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) -![](img/e90ef6d617446977b0276db0871cfb81.png) +![](img/824ae269f3bd907a2a05b2053f990ad9.png) -您将如何构建一个聊天服务，每天需要处理 750 万并发玩家，2,700 万每日玩家，每秒 11,000 条消息和每台服务器 10 亿个事件？ +关于 Pinterest 的更新：[自从我们上一篇文章以来，Pinterest 的增长是由亚马逊云可扩展性](http://news.techworld.com/storage/3352613/pinterest-growth-driven-by-amazon-cloud-scalability/)驱动的：[处理 3 百万以上用户](http://highscalability.com/blog/2012/2/16/a-short-on-the-pinterest-stack-for-handling-3-million-users.html)的 Pinterest 堆栈短缺。 -什么会产生这么多的流量？ 当然是游戏。 [英雄联盟](http://leagueoflegends.com) 。 英雄联盟是一款基于团队的游戏，一种多人在线战斗竞技场（ [MOBA](http://en.wikipedia.org/wiki/Multiplayer_online_battle_arena) ），其中两支五人的队伍互相对抗，以控制地图和 实现目标。 +通过 Pinterest，我们看到了一个非常类似于 [Instagram](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html) 的故事。 巨大的增长，大量的用户，大量的数据以及非常少的员工，全部都在云上。 -对于团队而言，成功的沟通至关重要。 我从 [Michal Ptaszek](https://twitter.com/michalptaszek) 中了解到，在关于 [扩展英雄联盟的有趣演讲中，与 7,000 万玩家聊天](https://www.youtube.com/watch?v=_jsMpmWaq7I) （ [幻灯片](http://www.slideshare.net/michalptaszek/strange-loop-presentation) ）在 [Strange Loop 2014](https://thestrangeloop.com/) 会议。 Michal 很好地说明了为什么多人团队游戏需要玩家之间的良好沟通。 想象一下没有打篮球的篮球比赛。 这是行不通的。 因此，这意味着聊天至关重要。 聊天不是“很好”的功能。 +的确，Pinterest 和 Instagram 都没有在[科学技术](http://www.theatlantic.com/business/archive/2012/05/the-golden-age-of-silicon-valley-is-over-and-were-dancing-on-its-grave/257401/)上取得重大进步，但这更多地表明了当今商品环境的便捷力量，而不是硅谷缺乏创新的迹象。 数字如此之大，估值如此之高，我们自然希望某种基本的技术革命成为其增长的基础。 革命更加微妙。 如果您能够执行正确的想法，那么如今实现这样的增长确实很容易。 习惯它。 这是新常态。 -Michal 以一种有趣的方式构建了对话，将以下表达用作模板：使之起作用。 改正它。 快一点。 +这是 Pinterest 今天的样子： -使其工作意味着从 XMPP 开始作为聊天的基础。 WhatsApp 遵循 [相同的策略](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) 。 开箱即用，您将获得可以正常使用和扩展的功能……直到用户数真正增加。 为了使其正确而快速，例如 WhatsApp，《英雄联盟》发现自己自定义了 Erlang VM。 添加许多监视功能和性能优化，以消除破坏大规模性能的瓶颈。 +* S3 中存储了 8000 万个对象，具有 410 TB 的用户数据，是 8 月份的十倍。 EC2 实例增长了 3 倍。 ：S3 约$ 39K，EC2 约$ 30K。 +* 截至去年 12 月，共有 12 名员工。 使用云，站点可以保持巨大的规模，同时保持很小的团队。 *看起来像 [31 名员工](http://pinterest.com/about/team/)，到目前为止*。 +* 为您所用的东西付费可以省钱。 大多数流量发生在下午和晚上，因此它们将夜间的实例数量减少了 40％。 在高峰时段，EC2 每小时花费$ 52，而在非高峰时段的晚上，每小时花费仅为$ 15。 +* Web 层中的 150 个 EC2 实例 +* 90 个实例用于内存中缓存，从而消除了数据库负载 +* 35 个用于内部目的的实例 +* 70 个主数据库，在全球不同地区具有一组并行的备份数据库，以实现冗余 +* 用 Python 和 Django 写 +* 使用分片，当数据库达到容量的 50％时将对其进行拆分，从而易于扩展并提供足够的 IO 容量 +* ELB 用于跨实例进行负载平衡。 ELB API 使您可以轻松地将实例移入和移出生产环境。 +* 历史上发展最快的网站之一。 引用 AWS 使其 3 月份可处理 1800 万访客的情况，与上个月相比增长了 50％，而 IT 基础设施却很少。 +* 云支持简单而低成本的实验。 无需购买新服务器即可测试新服务，并且无需支付大量前期费用。 +* 基于 Hadoop 的 Elastic Map Reduce 用于数据分析，每月仅花费几百美元。 -他们聊天架构中最有趣的部分可能是使用 Riak 的 [CRDT](http://blog.joeljacobson.com/riak-2-0-data-types/) （会聚复制数据类型）来实现 他们没有共享的目标助长了大规模线性水平可伸缩性。 CRDT 仍然很深奥，因此您可能还没有听说过它们，但是如果您可以让它们为您服务，那么它们将是下一件很酷的事情。 这是处理写入的另一种思考方式。 - -让我们了解一下英雄联盟如何构建他们的聊天系统来处理 7000 万玩家... - -## 统计信息 - -* 每月有 6700 万唯一身份玩家（不包括聊天中的其他服务） - -* 每天有 2700 万玩家 - -* 750 万并发玩家 - -* 仅使用 20％到 30％的可用 CPU 和 RAM，每天每台服务器路由 10 亿个事件。 - -* 每秒 11K 条消息 - -* 全世界部署了数百个聊天服务器。 由 3 个人管理。 - -* 99％的正常运行时间。 - -## 平台 - -* [Ejabberd](https://www.ejabberd.im/) （基于 Erlang）XMPP 服务器 - -* 修复 - -* 负载均衡器 - -* 石墨 - -* Zabbix - -* Nagios - -* 詹金斯 - -* 汇合 - -## 聊天 - -* 可以是一对一或群聊。 - -* 聊天充当在线状态服务，并且还维护好友列表。 它知道播放器是在线还是离线。 他们在玩吗？ 他们玩了多久了？ 他们在玩什么冠军？ - -* REST API 提供聊天作为其他 LoL 服务的后端服务。 例如，商店通过聊天来验证友谊。 联赛使用聊天社交图谱将新玩家分组在一起，以便他们可以更频繁地比赛并相互竞争。 - -* 聊天必须以低且稳定的延迟运行。 如果聊天不起作用，游戏体验会下降。 - -* 选择 [XMPP](http://xmpp.org/) 作为协议。 提供消息传递，状态信息，并维护联系人列表。 - -* 由于性能原因和实施新功能，它们必须与核心 XMPP 协议有所不同。 - -* 选择 Ejabberd 作为他们的服务器。 一开始它运作良好。 Erlang 有很多好处。 它的构建考虑了并发性，分发性和可伸缩性。 它支持热代码重载，因此可以在不停止服务的情况下修补错误。 - -* 目标是 [不共享任何体系结构](http://en.wikipedia.org/wiki/Shared_nothing_architecture) 以实现大规模线性水平可伸缩性。 还可以实现更好的错误隔离和可追溯性。 尚不存在，但正在朝着这个目标取得进展。 - -* 拥有数百个聊天服务器，只有几个人可以管理它们，因此服务器必须具有容错能力，这一点很重要。 并非每一次失败都需要人工干预。 - -* 让它崩溃。 不要试图从重大故障中缓慢恢复。 而是从已知状态重新启动。 例如，如果有大量待处理查询积压到数据库中，则数据库将重新启动。 所有新查询都会实时处理，而排队的查询将重新安排进行处理。 - -* 每个物理服务器都运行 Ejabberd 和 Riak。 Riak 用作数据库。 可以根据需要水平添加服务器。 Ejabberd 在集群中运行。 风险服务器也运行在它们自己的群集中。 - -* Riak 服务器使用多数据中心复制将持久性数据导出到辅助 Riak 群集。 像社交图查询一样，昂贵的 ETL 查询在辅助群集上运行，而不会中断主要群集。 备份也会在辅助群集上运行。 - -* 随着时间的流逝，由于必须关注可伸缩性，性能和容错能力，因此大部分 Ejabberd 都被重写。 - - * 重写以符合他们的要求。 例如，在 LoL 友谊仅是双向的，XMPP 允许非对称友谊。 XMPP 友谊的创建需要客户端和服务器之间大约有 16 条消息，这对数据库造成了打击。 新协议是三个消息。 - - * 删除了不必要的代码。 - - * 优化了协议本身。 - - * 写了很多测试以确保没有损坏。 - -* 配置文件代码可消除明显的瓶颈。 - -* 避免共享可变状态，因此它可以在单个服务器上以及在集群环境中线性扩展。 - - * 多用户聊天（MUC）。 每个聊天服务器都可以处理数十万个连接。 对于每个用户连接，都有一个会话过程。 每次用户想要更新其状态或向房间发送消息时，事件都必须转到称为 MUC 路由器的单个进程中。 然后它将消息中继到相关的群聊。 这是一个明显的瓶颈。 解决方案是并行化路由。 现在，在用户会话中查找群组聊天室。 能够使用所有可用的内核。 - - * 每个 Ejabberd 服务器都包含会话表的副本，该表包含用户 ID 和会话之间的映射。 发送消息需要查看用户会话在集群中的位置。 消息已写入会话表。 通过检查会话是否存在，检查存在优先级以及其他一些检查，分布式写操作的数量减少了 96％。 巨大的胜利。 更多的用户可以更快地登录，并且状态更新可以更频繁地发生。 - -* 新增的功能使您可以更好地了解已升级到生产中的代码。 因此，可以在事务上下文中一次在多个服务器上更新代码。 - -* 为了优化服务器，调试功能已添加到 Erlang VM 中。 需要具有查看会话中内存使用情况的能力，以便他们可以更好地优化内存使用率。 - -* 从一开始就设计了数据库可伸缩性。 从 MySQL 开始，但是遇到了多个性能，可靠性和可伸缩性问题。 例如，不可能足够快地更新架构以跟踪代码中所做的更改。 - - * 因此，他们选择了 Riak。 Riak 是分布式，容错的键值存储。 真正的无主，所以没有单点故障。 即使两台服务器故障也不会降低服务质量或丢失数据。 - - * 必须在聊天服务器上花费大量工作来实现最终的一致性。 实现了 Ejabberd [CRDT 库](http://blog.joeljacobson.com/riak-2-0-data-types/) （会聚复制数据类型）。 负责所有写冲突。 尝试将对象收敛到稳定状态。 - - * CRDT 如何工作？ 与其将新玩家直接添加到好友列表中，不如保留对象的操作日志。 日志中有“添加播放器 1”和“添加播放器 2”之类的条目。 下次读取该对象时，将查阅该日志并解决所有冲突。 然后将日志以任何顺序应用于对象，因为顺序无关紧要。 这样，朋友列表就处于一致状态。 想法是在适当的位置更新值，而不是为对象建立一长串的操作日志，并且只要读取对象就应用该操作。 - - * Riak 取得了巨大的成功。 允许线性缩放。 还提供了方案灵活性，因为可以随时更改对象。 - - * 这是一个巨大的思想转变和大量的工作。 它改变了他们测试服务并围绕它构建工具的方式。 - -## 监控 - -* 内置了超过 500 个实时计数器，每分钟收集一次并发布到监视系统（Graphite，Zabbix，Nagios）中。 - -* 计数器具有阈值，在超过阈值时会生成警报。 在玩家注意到任何服务问题之前就可以解决问题。 - -* 例如，最近的客户端更新进入了广播自己存在状态的无限循环。 观察 Graphite，立即可以看出聊天服务器受到了从新客户端版本开始的状态更新的冲击。 - -## 实现功能切换（功能标志） - -* 能够即时打开和关闭新功能，而无需重新启动服务。 - -* 开发新功能时，将通过开/关开关将其包围。 如果某个功能导致问题，则可以将其禁用。 - -* 部分部署。 只能为某些用户启用新代码，或者一定比例的用户可以激活新代码。 这样可以在远低于满载的情况下测试潜在危险功能。 如果新功能有效，则可以为所有人打开。 - -## 快速重新加载代码 - -* Erlang 的一大特色是能够即时热加载新代码。 - -* 在一种情况下，第三方客户（如 pidgin）没有经过良好的测试，结果证明他们发送的事件与官方客户不同。 可以将这些修补程序部署并集成到聊天服务器中，而不必重新启动整个聊天。 这意味着减少了玩家的停机时间。 - -## 正在记录 - -* 记录所有异常情况，例如错误和警告。 - -* 服务器还报告运行状况良好，从而可以查看日志并确定服务器是否正常，因为它正在记录用户，接受新连接，修改好友列表。 - -* 内置进入所选用户会话的调试模式的功能。 如果有可疑用户或实验用户（在生产服务器上进行质量检查），即使聊天服务器上有 100,000 个会话，也只需记录特定的会话即可。 日志记录包括 XML 流量，事件和指标。 这样可以节省大量的日志存储空间。 - -* 通过功能切换，部分部署和选择性日志记录的组合，可以将功能部署到生产服务器，因此只能由几个人进行测试。 可以收集和分析相关日志，而不会受到所有用户的干扰。 - -## 负载测试代码 - -* 每天晚上，自动验证系统都会将所有更改的构建部署到负载测试环境，并运行一系列负载测试。 - -* 在测试过程中监视服务器的运行状况。 指标被提取和分析。 将生成一个 Confluence 页面，其中包含所有指标和测试结果。 将发送电子邮件摘要以及测试结果摘要。 - -* 可以将更改与以前的版本进行比较，因此可以跟踪代码更改对测试的影响，发现灾难或诸如内存使用量减少了 X％之类的更改。 - -## 未来 - -* 从 MySQL 迁移数据。 - -* 希望在游戏外提供聊天功能，以便玩家无需登录游戏即可享受友谊。 - -* 想使用社交图谱来改善体验。 分析玩家之间的联系，并了解其如何影响游戏的乐趣。 - -* 计划将游戏内聊天迁移到游戏外聊天服务器。 - -## 获得的经验教训 - -* **事情将失败**。 您没有完全的控制权。 即使您的代码没有错误，如果 ISP 的路由器死亡并且同时失去 100,000 个播放器，会发生什么情况？ 做好准备 确保您的系统可以一次处理掉一半的玩家。 或者在 20 个聊天服务器中损失 5 个而不会降低性能。 - -* **缩放表面虫** 。 即使一个错误仅发生十亿次，这意味着在英雄联盟的规模下，该错误每天也会发生一次。 随着时间的流逝，甚至不太可能发生的事件。 +## 相关文章 -* **成功的关键是了解系统实际上在做什么** 。 了解您的系统是否处于健康状态或即将崩溃。 +* [关于黑客新闻](http://news.ycombinator.com/item?id=4003863) +* [在 GigaOM 上](http://gigaom.com/cloud/innovation-isnt-dead-it-just-moved-to-the-cloud/) +* [新兴企业正在为 IT 创建新的世界体系](http://highscalability.com/blog/2012/5/7/startups-are-creating-a-new-system-of-the-world-for-it.html) +* [亚马逊的成功秘诀是什么？为什么 EC2 是失控的火车？](http://www.cloudscaling.com/blog/cloud-computing/what-is-amazons-secret-for-success-and-why-is-ec2-a-runaway-train/) -* **制定策略** 。 大声笑有一种横向扩展其聊天服务的策略。 为了支持他们的策略，他们做了一些不同的事情。 他们不仅使用 Riak 购买了 NoSQL，而且改变了利用 CRDT 的方法，以使水平扩展尽可能无缝和强大。 +用于分片的数据库是什么？ 70 大师似乎更高。 他们在 VM 中吗？ 保留 400 + tb 数据需要多少成本？ -* **使它起作用** 。 从某个地方开始发展。 埃贾伯德把他们弄倒了。 从头开始会更容易吗？ 也许可以，但是当他们了解了需求是什么时，他们便能够开发出满足他们需求的系统。 +*“将 AWS 变为可能的站点”* -* **使其可见** 。 添加跟踪，日志记录，警报，监视，图形以及所有这些好东西。 +*引用 -* **使其成为 DevOps** 。 LoL 在软件更新，功能标记，热更新，自动负载测试，高度可配置的日志级别等中添加了事务，以使系统更易于管理。 +我认为您的意思是* cites，而不是“倒数第二个”中的“ Site for AWS”。 -* **减少聊天协议** 。 根据系统需求定制功能。 例如，如果您的系统仅支持双向友谊，那么您就不会采用更为通用和昂贵的协议。 +看到这些东西总是很有趣，410TB 是海量的 S3 数据！ -* **避免共享可变状态** 。 这是一种常见的策略，但是看到共享状态如何在每次扩大规模时引起越来越多的问题总是很有趣的。 +那么，每月$ 31K +的存储空间（这减少了冗余），每月$ 3K 的 EC2 计算能力？ -* **利用您的社交图** 。 聊天服务自然会提供社交图。 该信息可用于改善用户体验和实现新颖的新功能。 +因此，对于 EC2 实例和 410TB 的存储（甚至不试图猜测带宽），他们的亚马逊每月费用约为 6 万美元，而且他们的工资单至少还需要 10 万美元。 据我所知，他们的收入为 0 美元。 这里的模型到底是什么？ -## 相关文章 +EC2 具有非常差的 I / O 性能的最新想法是什么？ 添加更多实例是否可以经济有效地弥补这一不足？ 谢谢。 -* [在 Reddit 上](http://www.reddit.com/r/programming/comments/2j95dv/how_league_of_legends_scaled_chat_to_70_million/) +为了提高 I / O 性能，请创建多个卷并使用软件 RAID 对其进行条带化。 -* [使用 Erlang 的新 Facebook 聊天功能可扩展至 7000 万用户](http://highscalability.com/blog/2008/5/14/new-facebook-chat-feature-scales-to-70-million-users-using-e.html) （2008） +是每月或每年约$ 69K 的存储空间？ -* [HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息](http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html) （使用 XMPP） +@Joe：Pinterest 过去曾尝试过会员链接，因此他们获得的收入微不足道，但似乎[仍在积极地解决它](http://llsocial.com/2012/02/pinterest-adds-disclosure-and-info-from-ceo/)。 -* [Facebook 以 190 亿美元的价格收购了 WhatsApp 架构](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) （使用 XMPP） +>这是 Pinterst 今天的样子： -* [误区：埃里克·布鲁尔（Eric Brewer）论为何银行不使用碱-可用性是收入](http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html) +** Pinterest 的 -* [英雄联盟内部，电子竞技的主要赛事](http://www.nytimes.com/2014/10/12/technology/riot-games-league-of-legends-main-attraction-esports.html) +我们的私有云团队研究了上述配置和价格。 根据我们的经验，私有云基础架构将在大约 20 个月内提供 ROI。 从 Amazon 迁移到私有云时，由于 I / O 和计算能力的提高，我们通常还会看到迁移后实例的 3：1 合并。 -很棒的文章，谢谢！ 一个小小的更正：Riak（还有问题）中的 CRDT 风格是收敛的复制数据类型，而不是您的文章所说的可交换的 +因此，您拆分了数据库，使其达到当前服务器的 50％。 你是什​​么意思？ 记忆还是？ -从某种意义上讲，CRDT 并不是新事物：您的银行分类帐是事件日志，并且在存在所有此类即时网络之前，银行分支机构通常会在一天结束时合并其日志，以获取权威的银行余额。 但是显然，分布式数据库专家并没有永远谈论 CRDT，所以我知道您的意思。 +410TB 中的 90％可能侵犯了版权。 他们绝对无权将全尺寸照片复制到其服务器。 -很酷的文章！ 作为每天使用 Erlang 的人，看到越来越多的知名项目/公司使用它总是很有趣。 感觉就像总是隐藏在 XD 中的那些语言之一 +是 1800 万唯一身份访问者吗？ -想一想游戏的持续发展速度如何，而且除了 DDOS 攻击之外，几乎没有打 h 过，这真是令人惊讶。 \ No newline at end of file +他们现在有 152 名员工，多么增长！ \ No newline at end of file diff --git a/docs/94.md b/docs/94.md index 04fbed4..c782757 100644 --- a/docs/94.md +++ b/docs/94.md @@ -1,126 +1,63 @@ -# Clay.io 如何使用 AWS，Docker，HAProxy 和 Lots 建立其 10 倍架构 +# 搜索技术剖析：使用组合器爬行 -> 原文： [http://highscalability.com/blog/2014/10/6/how-clayio-built-their-10x-architecture-using-aws-docker-hap.html](http://highscalability.com/blog/2014/10/6/how-clayio-built-their-10x-architecture-using-aws-docker-hap.html) +> 原文： [http://highscalability.com/blog/2012/5/28/the-anatomy-of-search-technology-crawling-using-combinators.html](http://highscalability.com/blog/2012/5/28/the-anatomy-of-search-technology-crawling-using-combinators.html) -*这是 [Zoli Kahan](http://insignia.zolmeister.com/#/) 来自 [Clay.io](http://clay.io/) 的[客人转发。](http://zolmeister.com/)* +![](img/36ab01ea97bfa8e04f1ca36ac0ea0183.png) -![](img/cd6b3aa23bad6407251bf52fac9d1a68.png) +*这是垃圾邮件免费搜索引擎 blekko 的首席技术官 Greg Lindahl 撰​​写的系列文章中的第二个来宾帖子（[第 1 部分](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html )，[第 3 部分](http://highscalability.com/blog/2012/7/9/data-replication-in-nosql-databases.html)）。 之前，Greg 是 PathScale 的创始人兼杰出工程师，当时他是 InfiniPath 低延迟 InfiniBand HCA 的架构师，该架构用于构建紧密耦合的超级计算集群。* -这是我的新系列`10x`中的第一篇文章，我在 [Clay.io](http://clay.io/) 中分享我的经验以及如何做事，以与一个小组一起大规模发展。 如果您觉得这些事情有趣，我们正在招聘- [[受电子邮件保护]](/cdn-cgi/l/email-protection) +## 搜寻网路有什么困难？ -## 云端 +Web 搜寻器的存在时间与 Web 差不多，在网络出现之前，就存在用于 gopher 和 ftp 的搜寻器。 您可能会认为 25 年的经验将使您能够解决已解决的问题，但是网络的迅猛发展以及垃圾邮件技术和其他不良内容的新发明不断带来新的挑战。 紧密耦合的并行编程的普遍困难也抬起了头，因为网络已从数百万个页面扩展到数千亿个页面。 -### 云耀斑 +## 现有的开源爬网程序和爬网 -[![CloudFlare](img/7b159cb72a76c78e5442df11e7e0f8dd.png)](https://www.cloudflare.com/) +本文主要讨论 blekko 的搜寻器及其组合器的用法，但是，如果您想对搜寻的困难部分进行更一般的介绍，建议您查看以下内容： -[CloudFlare](https://www.cloudflare.com/) 处理我们所有的 DNS，并充当具有某些其他 DDOS 保护功能的分布式缓存代理。 它还处理 SSL。 +* [信息检索简介](http://nlp.stanford.edu/IR-book/) +* [Apache Nutch](http://nutch.apache.org/) 开源搜寻器 +* 来自 [](http://archive.org/) 的开源抓取工具 [Heritrix](http://crawler.archive.org/) +* [50 亿页](http://archive.org/) [常见爬网](http://commoncrawl.org/) -### Amazon EC2 + VPC + NAT 服务器 +## 定向爬行 -[![Amazon Web Services](img/4d99eeaece9082339db02fb5f4acd2f6.png)](http://aws.amazon.com/) +打算不对整个 Web 进行爬网的爬网程序的最重要功能是仅对最重要的页面进行爬网的能力。 有传言称，谷歌的网络爬虫和索引超过了 1000 亿个网页，而谷歌在 2008 年宣布其“爬虫前沿”（他们在其他网页上看到的所有网址的列表）已经结束。 -我们几乎所有服务器都生活在 Amazon EC2 上，其中大多数是中型或大型实例。 我们还使用 Amazon VPC 将我们的某些服务器托管在外部无法访问的专用网络中。 为了进入这个专用网络，我们有一个 NAT 服务器，它也用作我们的 VPN 端点，在与内部网络配合使用时使用。 （[指南](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html)， [OpenVPN](https://openvpn.net/index.php/open-source/documentation/howto.html) ） +blekko 知道我们只想为仅数十亿个网页的索引编制索引并提供结果。 那只是 Google 抓取边界中网页的一小部分，因此我们需要非常擅长抓取最好的页面，并且只抓取最好的页面。 一种方法是在爬网时计算网页的排名，包括尚未爬网的页面的排名。 -### 亚马逊 S3 +页面的等级取决于传入链接的数量和质量，以及许多其他页面上的度量，例如页面上的文字，与文字数量相比的广告数量等等。 在首次抓取页面之前无法知道页面上的度量值，但是从抓取其他页面开始就可以知道传入的链接。 -我们将 Amazon S3 用作 CDN 后端，该后端托管了我们的所有静态内容。 为此，我们使用一个单独的域：`cdn.wtf`（出于安全和性能方面的考虑）（无 cookie 的域）。 +当然，使用入站链接对网页进行排名是很多互联网垃圾邮件发送者已经精心设计的方法。 这些虚假链接中的一些来自其他垃圾邮件发送者网站，而某些来自具有合理内容的合法网站。 我有一堆关于各种主题的旧的，排名靠前的网页，而且我收到了无穷无尽的“链接交易”电子邮件，这些电子邮件大多是由自动执行链接交易游戏的软件包发送的。 查找和忽略来自合法网站的错误链接要困难得多，而且通常要等到许多链接页面被完全爬网后才能完成。 -### HAProxy +## 组合器 -[HAProxy](http://www.haproxy.org/) 是一种性能卓越的反向代理，可用于将流量路由到我们的不同服务。 由于 Clay.io 的性质及其对平台支持的关注（以及对遗留代码的支持），这项工作并不轻松，我将在以后的文章中详细介绍。 +现在，让我们看看**组合器**（我们在[先前的博客文章](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html)中进行了讨论）如何使这些计算变得更加容易。 -当前，我们在 m3.medium 实例上只有一个 HAProxy 服务器，但是会随着流量的增加而升级。 此外，如有必要，我们可以在前面添加 Amazon ELB 以水平缩放。 +首先，我们想对许多事物进行独特计数：传入链接的地理多样性，传入链接的网络多样性等等。 如果所有传入链接都来自同一个 C 类 IP 网络，那么包含大量传入链接的页面就不会那么有趣。 我们使用**对数计数**组合器来有效地计数这些数量（在时间和空间上-每个计数 16 个字节），而不会在我们爬行和重新爬行 Web 时重复计数任何东西。 使用 logcount 的缺点是计数是近似值。 对于一些重要的数量，我们选择 logcount 的变体，它们需要多达 256 个字节的状态，以便更好地近似精确的答案。 -### 应用服务器-Docker +接下来，我们经常需要操纵到网页的传出和传入链接列表。 在大多数关系数据库中，此数据通常由表中的一系列行表示，并且我们将通过查询链接的目的地等于特定 URL 的所有记录来获取此数据。 这是一项昂贵的操作，并且由于入站链接的数量可能很大（在许多情况下为数百万个），因此我们需要某种方式摆脱该表中次重要（排名较低）的行，以便 保持表格大小合理。 -[![Docker](img/0c5a4e266f51da3a4d7f5aae1cc6abd3.png)](https://www.docker.com/) +**TopN** 组合器解决了这两个问题。 作为一个有限大小的列表，可以通过一次操作读取它，并且它的大小是自动修整的。 作为我们为什么要在抓取时操作此传入网页列表的示例，请考虑以下事实：交易或购买的链接通常具有相同的[锚文本](http://en.wikipedia.org/wiki/Anchor_text)。 通过在爬网页面之前检查传入的锚文本，我们可以完全避免爬网。 索引时间检查可以发现锚文本的相似性，但是为时已晚，要避免浪费资源对其进行爬网。 -[Docker](https://www.docker.com/) 是用于管理 Linux 容器的工具，该工具类似于虚拟机，但开销较小（并且没有隔离和安全保证）。 Docker 的关键在于，无论主机看起来如何，容器内部交付的代码都应运行相同的代码。 +除了 url 级别的信息外，我们还保留爬网程序所学内容的主机级别摘要。 例如，我们有一个 TopN 摘要以及主机到主机链接的数量。 该摘要对于发现具有大量组内链接的主机组很有用。 我们使用此数据来打折这些链接的价值。 -当前，我们通过 Docker 在`app server`上运行大多数计算服务。 可以轻松地复制该服务器以满足弹性需求，并且可以轻松地上下移动服务。 最终，我们希望使用 Kubernetes 之类的工具来管理这些应用服务器。 （请参阅文章底部） +## 所有其他的东西 -### 登台 App Server-Docker +除了我们已经讨论的内容（查找传出链接并计算未爬网页面的等级）外，blekko 的搜寻器还完成了许多其他工作。 如果在网页上找到日期，则搜寻器会立即将要创建索引的页面发送给其他支持 blekko 的/ date 和/ daterange 功能的索引（有关 blekko 的高级功能，请参阅此 -我们的登台环境服务器与我们的应用程序服务器相同，并且运行与生产环境中完全相同的 docker 二进制文件。 这种环境对于防止生产系统不必要的损坏和停机至关重要。 +## 爬行经验 -## 数据 +我们在此过程中吸取了一些教训。 一个重要的教训是，至关重要的是，拥有一个电子邮件地址，网站管理员可以在存在抓取工具问题时可以私下与我们联系。 由于此，我们修复了一些错误。 最令人惊讶的是，网站管理员（和主要的抓取工具）未严格遵守 robots.txt 规范，并期望其 robots.txt 中的空白行无效。 我们还发现，很大一部分网站（包括许多美国政府网站）仅允许一小部分爬虫白名单来爬网其页面。 这些网站很多都是很小的，并且没有明显的联系方式联系他们的网站管理员以要求将其添加到白名单中。 -### 的 MySQL +## 未来发展方向 -[![MySQL](img/526eb85ffee8f9921ad1d216295ced15.png)](http://www.mysql.com/) +将来，我们想在爬网系统中添加一件主要的事情：执行 JavaScript 的能力。 越来越多的网络隐藏在 javascript 之后，尽管网站管理员谨慎地将其内容隐藏在大多数搜索引擎无法看到的地方，但许多网站管理员确实有动机隐藏其分析和广告 ID，以便他们 不那么明显。 -[MySQL](http://www.mysql.com/) 是生产强化的关系 SQL 数据库。 目前，我们的绝大多数数据都位于主从 MySQL 群集中。 我们有一个主服务器和两个从属服务器，它们为我们的用户提供大部分查询。 最终，我们可能不得不移动表或将单个主服务器分片，但希望一段时间不会。 +## 相关文章 -### Logstash +* [关于黑客新闻](http://news.ycombinator.com/item?id=4033983) +* [搜索技术剖析：Blekko 的 NoSQL 数据库](http://highscalability.com/blog/2012/4/25/the-anatomy-of-search-technology-blekkos-nosql-database.html) -[![logstash](img/49b14bb47630fed69c350a87ba95f9aa.png)](http://logstash.net/) +Heritrix 和 Common Crawl 项目的链接周围有些破损。 -[Logstash](http://logstash.net/) 是一种日志聚合工具，具有 Kibana 集成用于分析。 它基本上处理了我们所有的应用程序日志，并为我们提供了在出现问题时检查错误的地方。 它使我们不必通过 SSH 进入计算机来检查日志。 - -### MongoDB - -[![MongoDB](img/844d05fb05599f4bb0cfc0e38f860a89.png)](http://www.mongodb.org/) - -[MongoDB](http://www.mongodb.org/) 是 NoSQL 文档存储数据库。 当前，我们将 mongodb 用于某些开发人员端点以及 A / B 测试框架 [Flak Cannon](https://github.com/claydotio/flak-cannon) 。 - -### 记忆快取 - -[Memcached](http://memcached.org/) 是一个键值存储，主要用于缓存。 在许多方面，它与 Redis 类似。 当前，我们在旧版 Web 应用程序中使用 Memcached 来缓存 MySQL 查询结果。 最终，我们希望将其替换为 Redis。 - -## 开发运维 - -### Ansible - -[![Ansible](img/f3476ebde9aa1381944d20baed0f9259.png)](http://www.ansible.com/home) - -[Ansible](http://www.ansible.com/home) 已成为我们管理服务器的首选工具。 对于大多数开发人员而言，它非常简单，可以快速学习并乐于使用，并且对于自动化通常由运营团队管理的许多流程至关重要。 - -## 其他服务 - -### 的 GitHub - -[GitHub](https://github.com/) -很棒的源代码管理，已经足够了。 - -### 正常运行时间机器人 - -[正常运行时间机器人](https://uptimerobot.com/)是免费的监控服务，我们用于监控我们的健康检查和端点。 如果有任何问题，它将在 5 分钟内通过电子邮件和短信发送给我们。 - -### Drone.io - -[Drone.io](https://drone.io/) 是一项持续集成服务，我们使用该服务为各种项目持续运行我们的测试套件。 它类似于 TravisCI，并且最近发布了一个开源的可自我托管版本。 - -### Docker 注册表 - -我们目前使用官方 [Docker 注册表](https://registry.hub.docker.com/)管理我们的 Docker 容器。 除了 Docker 容器外，它与 GitHub 类似。 - -### 新遗物 - -[New Relic](http://newrelic.com/) 是服务器和应用程序监视服务，我们主要用于监视服务器，以便在计算机磁盘或内存不足时通知我们 - -### 谷歌分析 - -[Google Analytics](http://www.google.com/analytics/) 是我们的主要网站分析跟踪工具。 为了跟踪我们特定于站点的功能，我们使用自定义事件功能。 - -### Google Apps - -[Google Apps](http://www.google.com/enterprise/apps/business/) 为我们的域 clay.io 提供电子邮件，并为我们的组织提供了共享的 Google 云端硬盘设置。 - -### 最后通行证 - -[Last Pass](https://lastpass.com/) 是一种密码管理服务，使我们可以在团队中轻松共享上述所有其他服务的公司凭据。 - -## 未来 - -虽然我们目前对今天的设置感到满意，但我们希望在接下来的几个月中对其进行改进。 最初的基础架构版本缺少一些功能，这些功能并不需要花足够的时间来证明，但是随着我们的扩展，我们最终将需要重新使用它们。 - -[Kubernetes](https://github.com/GoogleCloudPlatform/kubernetes) 希望成为一个令人惊叹的大规模管理 Docker 容器的项目和工具。 我们将密切关注其发展，并希望随着项目的成熟将其投入生产。 - -[Amazon Glacier](http://aws.amazon.com/glacier/) 是我们一直在寻找的用于进行数据库备份的另一项技术，并希望在不久的将来实现。 - -[RethinkDB](http://rethinkdb.com/) 虽然还很不成熟，但却是一个非常有趣的项目。 我们肯定会关注它的进展，并且随着我们离开 MySQL，最终可能会将一些数据移入其中。 - -好奇如果 NewRelic 也可以进行可用性监视，为什么他们使用 Uptime Robot？ -单个 HAProxy 服务器听起来像是发生故障，等待中..：/ - -考虑到 clay.io 的 Alexa 排名超过 100,000，这似乎有点过分设计。 请问您每月在托管上花费多少？ \ No newline at end of file +爬网一章的链接已断开。 这是正确的链接：http://nlp.stanford.edu/IR-book/html/htmledition/web-crawling-and-indexes-1.html（看起来连字符可能在错误的位置）。 \ No newline at end of file diff --git a/docs/95.md b/docs/95.md index 9ce457b..b8f01ec 100644 --- a/docs/95.md +++ b/docs/95.md @@ -1,135 +1,95 @@ -# Instagram 提高了其应用程序的性能。 这是如何做。 +# iDoneThis-从头开始扩展基于电子邮件的应用程序 -> 原文： [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) +> 原文： [http://highscalability.com/blog/2012/6/20/idonethis-scaling-an-email-based-app-from-scratch.html](http://highscalability.com/blog/2012/6/20/idonethis-scaling-an-email-based-app-from-scratch.html) -![](img/e7b70a6c02b1e7425849dd6d1af801f2.png) +![](img/d32057557a700194022c0bb38a729ee5.png) -[平面设计](http://en.wikipedia.org/wiki/Flat_UI_Design)只是另一张漂亮的面孔，还是作为 UI 革命掩盖的巨大性能突破？ 事实证明，扁平化设计是赢得冷战的坚石。 +*这是 [iDoneThis](http://idonethis.com) 的首席技术官 Rodrigo Guzman 的来宾帖子，它使您的公司状态报告可以最轻松地进行。* -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 进行，主题是如何为全球范围内的移动应用程序设计现实，与美国相比，这种手机的速度较慢，屏幕较小，网络速度较慢。 。 +**iDoneThis** 是一个简单的管理应用程序，每天结束时都会通过电子邮件向您的团队发送电子邮件，询问您：“今天您做了什么？” 只需回答几行即可完成。 第二天早上，您团队中的每个人都了解了团队在前一天的成就，以使每个人都参与其中，并开始新的一天。 -为典型的手机而不是高端手机进行设计需要 Instagram 团队深入思考其设计。 泰勒（Tyler）演讲的启示之一是**向平面设计**的转移极大地提高了应用程序的美观性，可用性和实用性，并且极大地提高了性能。 +在我们推出之前，我们在一个周末以最基本的方式构建了 iDoneThis。 不好意思，我们使用 Gmail 收件箱的“密件抄送”字段发送了前几批每日电子邮件。 结果是，从网站存在的第 3 天开始，我们就已经在该网站上吸引了用户。 -这真是一个惊喜。 我只是将平面设计视为思考如何构建漂亮的 UI 的一种方式。 傻我 感谢泰勒（Tyler）如此清晰，有力地解释了平面设计的好处，并使用 Instagram 作为可能的典范。 +从 2011 年 1 月推出以来，我们每天手动发送数百封电子邮件，到每月发送超过 100 万封电子邮件和处理超过 20 万封传入电子邮件。 总共，客户记录了 170 万次完成。 -平面设计是反拟态的，它是数字化本地人，避免了对现实外观的痴迷，采用简单的元素，简单的版式，平面颜色和简单的设计。 +## 统计资料 -使用平面设计，Instagram 可以从冷启动时间缩短 120 毫秒。 它还能够将显示提要屏幕所需的资产数量从 29 个减少到 8 个。 同时，使应用程序更美观，更易用，并更加关注不同手机尺寸的内容。 +* 每天 1 万封入站电子邮件 +* 每天发送 40k 电子邮件，其中大部分发生在美国高峰时段，时间是美国的 6 便士，预计会如期到达。 +* 每秒几个 Web 请求，突发。 Web 服务器大部分闲置。 +* 1GB 的用户内容，5GB 的数据库 +* 为文档建立索引以进行实时搜索 +* 所有这些都使用单个 xlarge EC2 实例处理。 -平面设计如何使这一切成为可能？ +## 叠放 -## 转向平面设计 +* python 几乎所有内容 +* django 用于网络界面 +* apache + mod_wsgi +* PostgreSQL +* 传入的电子邮件由 sendgrid 解析 API 和内部用 python 编写的自定义电子邮件处理器处理 +* coffeescript，骨干，jquery 和 sass +* lucene + solr 用于在码头实例后面搜索运行 -* Instagram 改写了他们的 UI，以专注于 Android 上提供的各种 UI 的更好性能。 +## 电子邮件-从 Gmail 到 SendGrid -* Instagram 于 2012 年在 Android 上发布时，它是由 3 个人在大约 4 个月内建成的。 两名工程师和一名设计师。 Android 版本使用与 iOS 版本相同的设计。 +我们从 Gmail 中的密件抄送开始，因为如果我们从应用程序服务器发送电子邮件，则它们都将被标记为垃圾邮件。 Mailchimp 不允许我们在电子邮件中进行大量更改，因为它是为传统电子邮件营销而构建的。 -* 该设计使用了甜美的渐变色和许多 UI 元素。 +当令人惊讶的是，成百上千的人注册了该服务时，我们使用 [SendGrid](http://sendgrid.com) 在 cronjob 上切换到了自定义脚本（“ sendmail”）。 Sendmail 是我们今天仍然使用的，通过迭代改进来处理出现的错误情况。 -* 向 iOS7 过渡到平面设计，使产品变得更加简单和美观。 没有更多的渐变。 拿出箱子。 没有更多的阴影。 +它曾经每周崩溃一次，现在几乎从未发生过。 为了实现这一目标，sendmail 从简单的 for 循环变为使用数据库来跟踪每封电子邮件的状态，并具有可以优雅地处理不同状态转换的逻辑。 不过，起初让它成为一个简单的 for 循环对我们很有帮助-在观察了所有常见的失败方式之后，设计机械使其可靠的要容易得多。 -* 他们从适应平面设计**的经验中学到了**： +为了处理传入的电子邮件，我们从 200 行脚本（称为“ getmail”）开始，以通过 IMAP 访问 Gmail 收件箱。 该过程不可靠，在引发异常后会使数据库处于不良状态，因此必须由保姆亲自操作。 不仅如此，还要有人从条目中删除不需要的行（签名，回复文本等）。 我们使用标准库构建了一个传入解析器，这使我们的 getmail 过程更加可靠。 800 行 Python 代码非常混乱，这些 Python 代码专用于正确处理编码，部分和启发式方法，从而使不需要的行成为可能。 - * **平面设计是减少**，更快开发代码和更快交付产品的机会。 这对开发人员来说很棒。 +我们从 getmail 迁移到 SendGrid 的传入解析 API，该 API 基本上将传入电子邮件转换为 HTTP POST 请求，因此我们只需要担心编写 Web 应用程序。 我们之所以进行切换是因为由于 Google 的速率限制，getmail 无法足够快地处理传入的电子邮件。 更糟糕的是，getmail 的设计目的不是让它同时运行多个副本，当传入电子邮件的速率太大时，getmail 会开始引发很多问题。 - * **平面设计的性能更高**。 开发人员不仅做得更少，而且手机在显示 UI 方面也做得更少。 +## 扩展流程 -* 使用从 iOS7 平面设计重新设计中学到的新 Android 版本的目标： +可伸缩性是一件有趣的事。 早期，我们面临的主要瓶颈本身不是技术性的，而是开发人员的时间-面对大量电子邮件，这仅仅是我的问题！ 今天基本上也是这样。 这意味着性能和可伸缩性基于代码设计中的简单性，周到的抽象性和敏捷性的原则。 - * **使其平坦，使其更快**。 这不是重写。 导航模式没有改变。 +首先要毫不留情地将功能范围限制到最低限度或将其全部外包。 只有在该功能发布并且我们看到它被使用后，我们才对其进行优化以确保其性能（例如，我们添加了 [Celery](http://celeryproject.org/) 以异步发送通知电子邮件，之后该通知已成为 UX 的重要组成部分） 。 - * **注意屏幕空间**。 重新浏览每个屏幕，并弄清楚如何更好地适应所有屏幕尺寸。 +其次，使代码尽可能简单（写和读）。 这通常涉及牺牲性能。 例如，对于复杂的查询，ORM 并不总是产生最高效的 SQL，但是我们将其搁置一旁，直到该功能投入生产为止。 诚然，这导致了一些尴尬的时刻，但是更多的时候它使我们远离过早的优化，并且我们的代码库相对干净并且易于使用。 - * **变得漂亮**。 这是他们在 Instagram 上所做的一切的基础。 +随着传入和传出电子邮件的数量增加，我们考虑切换到多服务器体系结构。 但是，这开始给我们的连续部署库增加了很多复杂性。 因此，我们没有进行优化，而是购买了一台更大的计算机，并构建了一个负载和性能监视系统。 当前，iDoneThis 在单个 xlarge EC2 实例上运行。 我们可以通过做一些工作来摆脱一些小实例，但我们更愿意为简单起见和开发人员时间进行优化。 -* 总体效果是极大的简化。 进行了哪些更改？ +但是，我们流程中最重要的部分可能是我们拥有非常好的连续部署。 每个开发人员都可以使用一个简短的命令将 git repo 的任何分支部署到生产中，该过程需要几秒钟。 这意味着生产中和我们开发中的产品永远不会有太大差异。 这也意味着我们可以在实时观察发生的情况后快速进行迭代。 - * **将所有内容从 Chrome** 中删除。 拿出所有渐变和光泽按钮。 去勾勒形状而不是图标的渐变按钮。 剩下的是纯色和扁平形状。 希望用户界面淡入背景。 +## 重新构建现代网络 - * **拿出注释图标**，使注释全屏显示，为注释文本留出更多空间。 使内容在屏幕上脱颖而出。 用户界面越少，使用小屏幕的人就有更多的空间阅读文本。 +iDoneThis 的 Web 界面最初是一个非常简单的 Django 项目。 只是一些模型，视图和模板。 随着产品的发展，我们继续采用 Web 应用程序开发的旧范式：所有事情都与页面加载和表单提交有关。 这在一段时间内为我们提供了很好的服务，但是当我们的用户将数据放入我们的系统时，他们需要更好的界面来访问它。 - * **分叉了用于拍照的手机布局**。 在小型电话上，他们使用在屏幕顶部带有动作按钮的设计。 对于较大的屏幕，所有命令都在底部。 +我们慢慢开始堆积 jQuery 意大利面条以及支持它的后端功能。 结果是一团糟。 一种有效，但是很难调试和迭代。 - * **删除了整个应用程序不必要的 UI，以使内容更加集中**。 搜索屏幕上的三层铬减少到两层。 这在小型电话上腾出了很多空间。 由于三星 Galaxy 的按钮纤薄，采用扁平化设计很容易以编程方式进行操作，从而为内容腾出了很多空间。 +同样，选择只引入绝对必要的复杂性，我们使用 CoffeeScript 和 Backbone.js 重新编写了前端，从而产生了更易管理的组织代码。 当我们采取这一步骤时，我们很大程度上将后端留给了自己，仅根据需要添加了对前端新功能的支持。 事实证明这是有问题的。 - * 请注意，演讲中有很多关于不同设计的精美图片，因此非常值得观看之前和之后的图片。 +由于 iDoneThis 主要基于电子邮件，后来又推出了 iPhone 应用程序，因此我们最终获得了三个用于用户数据 I / O 的渠道：电子邮件，Web 和 iPhone 应用程序-每个渠道都有其自己的细微差别。 对我们来说，这使得我们的一些用户交互和流程不能像您在普通网络应用程序上所期望的那样完全正常工作，而 Django 抽象使这种工作变得容易。 例如，当一个用户被邀请加入一个团队时，他开始接收来自我们的电子邮件，并且可以像其他任何人一样回复它们，但是他从未访问过该站点来设置帐户。 -## 为什么要进行平面设计？ +随着我们构建后端以支持所有这些功能，代码变得越来越不规则。 我们尽可能地接受 TDD 来帮助解决这一问题，但更重要的是，我们决定切换到基于 API 的体系结构-我们仍在进行此切换。 -* **使用资产着色**运送更少的资产。 这意味着 APK 的大小较小，这在小型网络上非常有用。 魔术是**资产着色** **（**我以前从未听说过）。 [资产着色](http://blog.danlew.net/2014/08/18/fast-android-asset-theming-with-colorfilter/)表示资产（在这种情况下为图像）可以通过程序进行着色。 例如，可以通过编程方式将灰色的心脏染成红色。 资产着色意味着需要运输的资产更少。 传统上，每种按钮状态（按下，未按下，选择等）都需要单独的图像。通过着色，可以将不同状态的所有图像都不再需要运送了。 仅需要图像，并且可以设置不同的状态。 +看起来，方式是 Django 后端主要由两个组件组成：一个负责提供可由 Backbone.js 和 iPhone 应用程序使用的 json API，以及一组负责提供给前端的简单视图和模板。 代码和 html 占位符。 -* **加载更少的资产**。 这意味着 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％**。 +到目前为止，用这种风格编写的代码比老式的代码要简单得多，并且更易于测试。 但是，弄清进行切换的来龙去脉是一笔相当大的时间投资，因为 django 并不是针对这种范例而设计的。 新代码更简洁的事实使我认为，最终它们在迭代速度方面都将获得回报。 ## 得到教训 -* **可以实现快速的冷启动时间**。 如果他们很快，他们甚至会变得更快。 剖析，修复，迭代。 +* **外包辛勤工作，尽可能外包**。 即使对于基于电子邮件的产品，也要对发送和接收的电子邮件都使用 sendgrid，这就是我们要做的。 当然，在某些时候，内部做这些事情是有意义的，但是对于一家初创公司而言，那一点可能就是 t =无穷大。 +* **性能上的简化**：我们可能会放弃使用较小的 EC2 实例并使用 nginx，但是使用 mod_wsgi 的默认 apache 配置工作得很好，并且更易于自动化。 我们经常做这样的事情：让最简单最容易的事情出现，担心它的性能，然后再进行抛光。 +* 短时间内，我们朝着将组件拆分为在其自己的服务器中运行的方向发展。 这开始造成的麻烦超出其应有的价值，因此，我们最终获得了**单个 EC2 实例**。 + +单个 EC2 实例使我感到恐惧。 当您丢失该实例时会发生什么？ -* **谨慎使用像素**。 查看每个屏幕，查看不需要的内容。 与美国相比，其他国家/地区的用户使用的手机要小得多。 +@布兰登：我认为他们应该有某种备份，并有恢复计划。 +即使您有多个实例，也存在“丢失实例”问题。 归结为拥有可恢复的备份。 -* 移动电话喜欢简单的设计，移动开发人员也喜欢。 这要容易得多，也要快得多。 +很抱歉...一个 5GB 的数据库和每秒几个 Web 请求*这些天*是“高可扩展性”？ 新闻日慢多少？ -## 相关文章 +那么，告诉我，如何运行单个 EC2 实例“可伸缩”？ -* [在 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) +@Hrish：备份将使您得以恢复，但它们并不会采取任何措施来防止服务中断。 -我发现有趣的是，这种平面设计运动是由 Microsoft 与 Windows Phone 一起发起的。 -总是会有更多的高档用户界面（如游戏中），但从总体上看，功能正在取代形式。 我喜欢那个。 +AWS 有时会发生中断，但是它们几乎总是被隔离到一个实例区域中-也就是说，区域故障彼此独立。 如果任何区域发生故障的概率为 p，则由于区域发生故障而导致单个实例设置脱机的概率也为 p。 但是，如果应用程序是从两个区域提供服务的，并且可以在那些区域之一的消失中幸存下来，则应用程序因区域故障而脱机的可能性为 p ^ 2。 通过扩展到第二个可用性区域，可以将故障风险降低一个数量级。 -它以功能为基础，对我有很多帮助。 直到观看了这个出色的演示，我才知道平面设计是什么。 现在，在许多不同的层次上它变得更加有意义。 +使用 Django 应用程序，这应该相当容易。 Web 服务器不应存储状态，因此丢失服务器不会使应用程序脱机。 可以使用 Elastic Load Balancer 来放置 Web 服务器的前端，而 ELB 可以在区域中断中幸存下来。 可以跨区域以镜像配置设置 PostgreSQL，或者可以将 PostgreSQL 换成 MySQL，并为数据库使用多可用区 RDS 实例。 -正如文章所提出的那样，功能必须战胜视觉障碍。 但是作为仍然使用 iOS6.1.3 的匕首，我必须要求您承认，自 iOS7 以来，奇怪而与众不同的选择令人困惑：白色文本的鲜绿色背景，窄字体，细腻的灰色阴影以及总体而言太多了 屏幕上呈鲜亮的白色，而对于发现此效果实际上令人痛苦的用户则无能为力。 而且，即使使用 iOS8.0.2，提供的修改也是如此之小，以至于令人怀疑。 -好吧，渐变对处理程序征税-如果处理器不能比程序员领先一步，就消除渐变。 但是至少要为用户提供背景颜色选项。 给一些真实的对比度控制。 为需要的人提供一些粗细的字体。 -我们生活在一个这样的世界中，所有用户都将以正确的视线来到餐桌上，这一假设和期望越来越普遍。 但这是一个精英主义的假设。 使它精简，使其快速，但不要把我们中的很多人甩在后面。 \ No newline at end of file +对于像我们在 6 月 14 日看到的那样的故障可以恢复的应用程序，差异可能是每月数百美元。 \ No newline at end of file diff --git a/docs/96.md b/docs/96.md index cf35bad..83f14b5 100644 --- a/docs/96.md +++ b/docs/96.md @@ -1,164 +1,163 @@ -# 正确处理事情：通过即时重放查看集中式系统与分散式系统 - -> 原文： [http://highscalability.com/blog/2014/9/15/getting-things-right-a-look-at-centralized-vs-decentralized.html](http://highscalability.com/blog/2014/9/15/getting-things-right-a-look-at-centralized-vs-decentralized.html) - -*三个棒球裁判坐在酒吧周围，谈论他们如何在每个球场上打电话：第一裁判：有些是球，有些是打击，我将它们原样称呼。 第二位裁判：有些是球，有些是罢工，我称它们为“ em”。 第三次裁判：有些是球，有些是罢工，但直到我叫“ em”，它们才算是什么。* - -| ![](img/e9f57dcfbaa4ae4f974182c381d64d9f.png) -AT&T's Global [Network Operations Center](http://www.nj.com/business/index.ssf/2011/08/att_gnoc_earthquake.html) | ![](img/2e0523f20e3b155cee6e86dbdec861dd.png) -MLB 的[即时重播掩体](http://sports.yahoo.com/news/inside-look-at-mlb-s-new-instant-replay-bunker-032951044.html) | ![](img/7d078afdb4b153b2a46d7fdd99d65438.png) -NHL 的[情况室](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/) | - -**更新**：[在 NFL 重放命令中心内](http://mmqb.si.com/2014/11/11/inside-the-nfls-replay-command-center/) - -看一下我们认为主要属于计算机科学领域的概念在其他领域如何发挥作用很有趣。 一个有趣的例子是 [Instant Repla](http://en.wikipedia.org/wiki/Instant_replay) y 如何通过实现重播来反映甚至帮助[塑造](http://www.nfl.com/videos/nfl-network-top-ten/09000d5d811133e8/Top-Ten-Things-that-Changed-the-Game-Instant-replay)体育文化：[去中心化](http://en.wikipedia.org/wiki/Distributed_computing)或[集中化](http://en.wikipedia.org/wiki/Centralized_computing)。 - -有利可图的电视交易为专业体育运动注入了大量资金。 有了这么多钱，体育运动已经从纯粹的娱乐变成了**使事情变得正确**。 打个坏电话的代价太高了，无法让人为因素决定泰坦的命运。 - -正确处理事情也是计算机科学领域的热门话题。 在 CS 中，正确处理语言使用诸如事务，回滚，仲裁，乐观复制，线性化，同步，锁定，最终一致，补偿事务等术语。 - -在体育界为了使事情变得正确，裁判员使用诸如举旗，罚则，规则，裁决立场，重设时钟，向下和距离，取得线，吹哨，确认裁决以及推翻裁决等术语。 - -尽管词汇不同，但意图却是相同的。 正确性。 - -目的并非所有技术和体育都有共同点。 随着技术的发展，我们看到体育运动正在发生变化，以利用技术所提供的新功能。 这些变化应该是软件中任何人都熟悉的。 体育已经从完全分散的司法体制转变为现在我们看到的 [NBA](http://www.si.com/nba/point-forward/2014/05/18/nba-instant-replay-off-site-review-adam-silver) ， [NFL](http://espn.go.com/nfl/story/_/id/10670707/nfl-owners-allow-centralized-system-aid-instant-replay) ， [MLB](http://sports.yahoo.com/news/inside-look-at-mlb-s-new-instant-replay-bunker-032951044.html) 和 [NHL](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/) ， 融合到某种形式的集中式系统上。 - -NHL 是创新者，于 2011 年启动了他们的集中式即时重放系统。它的工作原理类似于...官员坐在位于多伦多的作战室中，该作战室看起来非常类似于曾经建立的每个[网络运营中心](http://en.wikipedia.org/wiki/Network_operations_center)。 所有游戏的视频源都流进了房间。 如果存在争议或明显值得回顾的游戏，则会与多伦多联系，以对正确的电话进行快速回顾和判断。 每个运动都会以自己的方式实现自己的集中式重播系统，但这就是要旨。 - -我们已经看到了完全相同的转变，例如电子邮件之类的联合服务已被 Twitter 和 Facebook 等集中式服务所取代。 事实证明，体育和计算机科学具有更深的相似之处。 那可能是什么？ - -## 发明了即时重播功能，以正确处理事情 - -多年来，正确处理事情一直在发展。 首先，您需要一套规则。 没有规则，就不可能把事情做好。 使用一套适当的规则，游戏可以属于以下几类之一：自引游戏，无引荐游戏或引荐游戏。 - -**无裁判游戏**的示例在 [Outlander 电视节目](http://www.imdb.com/title/tt3006802/)的一集中进行了描绘，该剧集主要设置于 18 世纪。 它有一个很棒的场景，显示正在玩的游戏看起来像是苏格兰风格的曲棍球。 两支球队用大棒子打了一个球。 到目前为止还很熟悉。 然而不久之后，这些棍子就被用作武器，并且球员们到处互相棍打。 它造就了一场血腥的好游戏，但并没有过多地强调正确的事情。 变得...是的。 - -**休闲游戏**是一种玩足球，篮球或其他类型的接力游戏的聚会，它遵循一组规则，但通常都是自参考的。 没有裁判可以打电话。 游戏不是那么重要。 玩家会自称犯规，或者对方会称对方为犯规，但这都是非常非正式的，可能导致激烈的分歧。 - -## 游戏是去中心化且无锁的 - -在游戏发展的这一点上，游戏完全**去中心化**。 游戏彼此完全独立。 可以同时玩任何数量的游戏。 您需要的是足够的玩家和一个玩耍的地方。 - -还要注意，游戏是**无锁**，完全没有任何形式的货币控制。 场上的所有活动并行进行，场上的游戏状态是场上发生的一切。 - -对于无裁判员比赛，事后无法修复违反规则的情况。 对于自引游戏，修复违反规则的能力很有限。 部分原因是休闲游戏的规则不够详尽，部分原因是没有人玩游戏会接受其他玩家的这种判断。 - -## 最终推荐的游戏是一致的 - -这在游戏中发挥了客观的第三方裁判的作用。 或称他们为[裁判](http://en.wikipedia.org/wiki/Referee)。 裁判员可以制定更加详尽的规则集，因为只有专业人士才能了解所有规则并具有运用规则的技能。 - -在游戏中增加独立裁判员也可以使事情变得更加微妙，从某种意义上说，所有值最终都收敛于正确的值，这使得游戏成为[最终保持一致](http://en.wikipedia.org/wiki/Eventual_consistency)。 这是考虑引荐游戏的有趣方式。 - -游戏状态是上述值，可以通过在场上的游戏进行修改，但是可以说，这些更改不是已提交的事务。 裁判员可以使用相当于[补偿交易](http://en.wikipedia.org/wiki/Compensating_transaction)的补偿来弥补可能的违规行为，从而可能改变比赛状态。 - -例如，在 NFL 中，裁判决定球的放置位置，时间，得分，顺序以及通常在球场上发生的所有其他事情。 裁判需要告诉您比赛中实际发生的事情，他们需要确定认可系统中的可见性的东西。 - -思考裁判的另一种方法是，它们充当[寻求原谅编程](http://highscalability.com/blog/2012/3/6/ask-for-forgiveness-programming-or-how-well-program-1000-cor.html)中描述的**读取和修复**机制。 这篇文章展示了我们如何有效地对具有 1000 多个内核的处理器进行编程。 这个想法是让所有这些内核同时，并行运行，然后通过后台任务不断使答案更接近正确性，这些任务负责找出问题所在并进行调整。 - -这听起来不像游戏在肉类世界中的运作方式明显吗？ 在游戏中，每个实体（球员，教练，裁判员，摄像机等）都是网络中连接的核心。 消息是通过手势或无线电信号进行的口头表达。 播放映射到协议。 - -在游戏中，由于实体的动作，状态在核心之间流动。 一些活动直接关联。 有些是间接链接的。 有些是独立的。 - -参加复杂的 NFL 比赛。 放一个球（或者是什么？），有一个拦截（在那里？），然后将球弄乱了（或者是吗？），又有一个忽悠了（或者在那里？），有人捡起球并跑了 在 TD。 最重要的是，该剧在该领域的完全不同的部分上有两个标志。 - -剧中到底发生了什么？ - -为了决定裁判们是否达到法定人数。 在解决冲突会议之后，这可能根本不会花费时间，也可能永远不会消失，裁判将得出结论。 裁判本质上是在阅读他们头脑中的“日志”中的事件，确定顺序，将事件与规则进行比较，确定哪些规则适用，哪些规则优先，然后确定正式发生了什么。 - -一旦确定，新游戏状态即已提交。 将通过补偿交易进行必要的维修。 可能会标出 15 码的罚款。 也许已经宣布了一个转身，球现在属于另一支球队。 裁判可以断定数百种潜在结果。 裁判说的是法律。 - -注意，像软件一样，正确性的代价是增加了延迟。 无裁判系统的延迟时间最短，因为比赛结束后，比赛不会停止，无法解决问题。 有了裁判，潜伏期有了巨大的飞跃。 决定处罚并实施任何更正需要大量时间。 - -裁判说的是真的吗？ 这是一个关于“真相”的深刻问题，我们将完全忽略。 任何球迷当然不会告诉你的。 裁判一直吹牛。 但这没关系。 在游戏中（例如在数据库中），在解决冲突后，合并结果变为新状态。 没有更高的权威。 - -## 视频创建了可以挑战的共享内存日志 - -可是等等。 NFL 已经开发了一种**质询机制**，因此可以在事后查看通话。 教练发出红旗，并且将再次检查最后一次提交的事务，以查看是否犯了错误。 其他运动也有类似的机制。 - -挑战系统是**技术创新**的结果。 录制了游戏之后，就可以记录下来并在以后重播。 视频在时空上扩展并解耦了事件的“日志”。 在太空中，因为可以观看比赛的角度数量仅受摄像机数量的限制。 及时播放，因为可以在慢动作中实时或实时查看播放。 - -有了这个新工具，裁判员可以在几十年前完成几乎无法想象的事情，他们可以在一场比赛结束后再看一眼。 即时重播诞生了！ - -如果裁判在看比赛时发现打错了电话，他们将发出更多命令以纠正引起的任何问题，从而使比赛进入更加正确和一致的状态。 使用**读取修复**并补偿事务以解决问题的一个好例子。 - -重播后更改游戏状态就像 Amazon 出售系统认为可用但实际上缺货的商品一样。 如果您购买了缺货商品，世界会终结吗？ 一点也不。 亚马逊会礼貌地通知您，该产品不再可用，您的订单已撤消。 对于亚马逊而言，获得销售要比每次犯错和改正错误更有利可图。 在比赛结束后，让比赛实时展开在场上也是值得的。 - -通常情况下，裁判员发出的用于解决先前问题的命令本身不可审查。 尽管许多体育运动都有一个上诉程序，联盟办公室可以先看电话然后说是，但裁判员犯了错，但是我们对此无能为力。 有时，极少数情况下，挑战会导致游戏从错误通话的角度重新开始。 - -在抗议之后，旧金山巨人队和芝加哥小熊队之间的最近一场比赛重新开始[。 这场比赛是在小熊队主场进行的，由于场地上的一些设备问题而被称为。 巨人当时正在输球，所以对他们来说这将是巨大的损失。 巨人上诉。 并荣获。 装备问题会给主队带来不当的胜利，这种力量被认为是不公平的。](http://espn.go.com/chicago/mlb/story/_/id/11384538/san-francisco-giants-win-appeal-finish-game-vs-chicago-cubs) - -**正义不是上诉系统**的目标。 玩完游戏后很少能解决问题。 可能会发送道歉信。 也许规则委员会将在明年研究改变规则。 也许可以减少罚款或取消暂停。 亚马逊可能会在您下次购买时给您折扣。 但是通常，一旦响起最后的哨声，便确定了游戏状态，并且游戏交易以成功返回码返回。 - -到目前为止，在运动场上发生的事情与计算机科学中发生的事情之间存在着一些有趣的相似之处。 这是因为在所有引用的系统下都是**通用结构。** 有规则，状态，活动和裁判员，他们解释如何将规则应用于状态活动的结果。 - -数据库只是一大类引用系统的示例。 房屋检查，审判，经过同行审查的学术论文，保险索赔调整，参加比赛的电影-只有在法官说出自己的真实情况时才有意义。 - -请注意，即时重播延迟又增加了。 观看视频要花费很多时间，比没有裁判员系统甚至只有裁判员系统的时间要多得多。 - -## 更多技术意味着更多正确处理事情-集中式系统 - -技术在未来飞跃发展，并拖累了社会。 - -摄像头和视频回放是实现现场即时回放的技术。 形成我认为的联合架构。 每个游戏都是自治的和分散的组织，但是规则和信息在游戏之间共享。 - -自从开始重放以来，我们已经看到了**快速互联网**的发明，功能强大的计算机，甚至还有更多的野外摄像头，以及创建复杂软件的能力。 因此，可以立即发明一种新的即时重放方式。 是的。 这次它使用集中式体系结构。 实际上，NBA，NHL，MLB 和 NFL 都已经转移到集中式即时重播方法，或者正在转移到一种。 - -这个想法很简单。 现在，可以将**的每个游戏**传输到中央运营中心，该中心可以让专门的专家团队观看视频并查看通话。 - -再次注意，集中式即时重放延迟又增加了。 现在，我们必须去中央重放中心进行判断。 我们真的必须认为正确性很重要吗？ - -## 游戏外的读取和修复机制 - -即时重放并不是唯一可用的读取和修复机制。 - -例如，在棒球和橄榄球中，比赛统计之后经常对比赛统计数据进行校正。 并非所有内容都可以在游戏环境中正确列出。 例如，稍微反射一下，一个麻袋可能会变成一个完整的麻袋。 - -场地上发生了很多事情，所以即使裁判员也看不到所有令人讨厌的事情。 这就是为什么存在**精细机制**的原因。 即使未在游戏中要求罚款，也可以在比赛结束后对背景一致性进行罚款。 - -## 深度学习，无人机，传感器和更多摄像头-混合还是闭环？ - -技术的下一次发展可能涉及**先进的机器人**，**深度学习系统**，甚至还有**更多的摄像机**，因为传感器和无人机将覆盖整个领域。 您可以想象有 1000 个摄像机覆盖每个游戏，而 AI 则在每个流中检查是否存在违规行为。 游戏的 AI 可以对违规行为进行投票，并以最高的信心将这些呼叫冒出来，直至引起人们的注意。 人类可能会做出最后决定，也可能不会做出决定。 - -网球中目前使用机器人作为[电子线路裁判](http://en.wikipedia.org/wiki/Electronic_line_judge)。 - -有些机器人可以在棒球中叫[球，对](http://bleacherreport.com/articles/1942413-should-major-league-baseball-ever-bother-with-a-robotic-strike-zone)进行击打，但是由于棒球具有使用裁判员的悠久传统，因此没有被使用。 - -**人类自负**将决定如何使用下一代技术。 如果体育中的人为因素被重视超过正确性，那么可能会发展出一种混合系统，该系统在概念上与现代软件系统有很多共同点。 我们仍然会有人工裁判，机器人会选择他们的位置。 集中的 AI 中介组件将承担大部分繁重的工作，而人工将在适当时提供监督。 毕竟，人类仍然必须感到重要。 - -技术趋于发展。 因此，如果有一点技术增加了系统延迟，并且将精力从分散的架构转移到了集中式架构，那么更多的技术可能会逆转这些发展。 - -一个闭环系统，每个运动场都有自己的摄像头和自己的 AI，其中 AI 可以直接拨打电话，这将创建一个低延迟系统，与无裁判系统相当，并且完全删除了集中式组件。 **每个游戏都会再次变得快速且分散**。 - -无论系统多么复杂，在我们眼中，我们始终会知道真正发生了什么。 - -## 相关文章 - -* [经进一步审核：即时重播的简要历史记录](http://mentalfloss.com/article/26075/upon-further-review-brief-history-instant-replay) - -* [为什么所有体育活动都不使用 NHL 的“控制室”重播审核系统？](http://www.thesportsfanjournal.com/columns/the-rev/all-sports-should-use-the-nhl-control-room-replay-review-system) - -* [对 NFL 重播系统](http://espn.go.com/nfl/story/_/id/10670707/nfl-owners-allow-centralized-system-aid-instant-replay)所做的更改 - -* [特殊报告：在 NHL 的中央视频审核操作中。 它可以在 NFL 中使用吗？ 通过调整，可以确定](http://blogs.canoe.ca/krykslants/nfl/special-report-inside-the-nhls-central-video-review-operation-can-it-work-in-the-nfl-with-tweaks-it-sure-can/) - -* [美国职业棒球大联盟必须求助于 NHL 风格的即时重播系统，以解决问题](http://bleacherreport.com/articles/1634267-mlb-must-turn-to-nhl-style-instant-replay-system-to-fix-umpiring) - -* [球员，裁判员现在比以往更需要重播](http://sports.yahoo.com/news/players--umpires-need-replay-now-more-than-ever.html) - -* [如何结束棒球史诗般的主持人改组：使用即时重播裁判员](http://www.theatlantic.com/entertainment/archive/2013/05/how-to-end-baseballs-epic-officiating-screwups-use-instant-replay-umpires/275726/)-反映组织的结构和文化。 - -* [彼得·加蒙斯（Peter Gammons）：忽略重播的天使埃尔南德斯（Angel Hernandez Blew）打电话了](http://deadspin.com/peter-gammons-angel-hernandez-blew-that-call-after-ign-499913975) - -* [美国职业棒球大联盟（MLB）的胡扯重播技术：曾经获得通话权的奇迹之王](http://deadspin.com/mlbs-crappy-replay-tech-its-a-miracle-umps-ever-get-499041275) - -* [小心您想要的东西](http://www.sportsonearth.com/article/70183162/major-league-baseball-instant-replay-may-be-overwhelming)-想您知道如何观看棒球比赛吗？ 只需等到从每个可能的角度进行其他重放即可。 （美联社） - -* [MLB 2014：棒球的即时重播如何工作？](http://online.wsj.com/news/articles/SB10001424052702304688104579465230759769104) - -* [“在我叫它之前什么都没有！”](http://bill37mccurdy.wordpress.com/2010/08/23/it-aint-nothing-until-i-call-it/) -有关如何通过在球场上让裁判神神拯救棒球的故事。 - -* [要求宽恕编程-或我们将如何编程 1000 个内核](http://highscalability.com/blog/2012/3/6/ask-for-forgiveness-programming-or-how-well-program-1000-cor.html) - -* [您实际上使用 NoSQL 的目的是什么？](http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html) - -多么手淫 \ No newline at end of file +# StubHub 体系结构：全球最大的票务市场背后的惊人复杂性 + +> 原文： [http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html](http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html) + +![](img/4fbc80a9b3d12c301a08338a63eea311.png) + +StubHub 是一个有趣的架构，因为作为门票的做市商，他们所从事的业务与我们通常考虑的业务不同。 + +StubHub 规模惊人，每年以 20％的速度增长，每小时可处理 80 万个复杂页面，每年可售出 500 万张门票，每小时可处理 200 万次 API 调用。 + +票务空间异常复杂。 StubHub 的流量非常棘手。 突发性，围绕不可预测的游戏结果，事件，时间表和季节。 涉及很多钱。 有很多不同的参与者。 涉及许多复杂的业务流程。 StubHub 在业务上有几个互补但又截然不同的部分：它们有一个广告服务器组件，可为 ESPN 等网站提供广告，丰富的交互式 UI 和实时门票市场组件。 + +对我而言，最有趣的是 StubHub 如何将票务，销售点系统，FedEx 交付，买卖双方以及金钱等曾经一度是高接触的实体世界带入数字领域。 他们通过与组织（例如美国职业棒球大联盟）的深度电子集成以及将复杂业务流程移出应用程序空间的生命周期总线来实现这一目标。 + +这是一个很有趣的问题，因为在处理业务构建功能成为首要任务时必须继续处理构建的旧系统，这使问题变得更加复杂。 让我们看看 StubHub 如何使其全部工作... + +## 资源 + +* 查理·芬曼（Charlie Fineman）在 QCon 上的演讲： [StubHub：为全球最大的票务市场](http://www.infoq.com/presentations/StubHub-Designing-for-Scale-and-Innovation-for-the-World-s-Largest-Ticket-Marketplace)设计规模和创新 + +## 商业模式 + +* **StubHub 是用于门票** 的 eBay。 为门票买卖双方提供一个市场。 他们不像 Ticketmaster 。 +* **托管模型用于为卖家** 提供信任和安全。 信用卡记录在 StubHub 上，当确认订单已收到时，才转移款项。 +* **门票不是商品** 。 买家想要特定的门票，而不是看台座位。 数量有限，没有滞票。 卖方不断更新价格和数量以响应市场力量。 这是一个非常活跃的市场。 + +## 统计信息 + +* 每年 500 万订单 +* 200 万个活动列表/门票。 +* 门票围绕 45,000 个赛事进行。 美国职业棒球大联盟的职缺赛季和超级碗是最活跃的时期。 +* 销售额每年以 20％的速度增长。 +* 每小时可处理 600k-800k 复杂页面。 在后期赛季每小时爆破一百万。 +* 在美国 10 到 12 个核心醒着时间的狭窄时段中，流量突发。 例如，季后赛结束后，会有买家为下一场比赛疯狂。 +* 每小时有 200 万来自会员的 API 调用。 +* 24-36 工程师。 +* 这是一项高触感的业务。 交易的支持电话过去是 1-1，但现在好多了。 员工最大的部分是客户服务和后台业务运营支持。 + +## 平台 + +* Java +* 冷融合（旧版） +* ActiveMQ +* [SEDA](http://www.eecs.harvard.edu/~mdw/proj/seda/) （分段事件驱动的体系结构） +* Lucene / Solr +* Jboss +* 内存缓存 +* Infiniband -到 SAN 的快速网络 +* XSL +* Oracle 的高级队列 +* TeamWorks -IBM 工作流构建器 +* Splunk +* Apache HttpClient +* Log4j（使用消息格式） +* 挂毯 + +## 架构 + +* 门票的三种购买来源：Web，销售点系统，批量上传。 批量上传允许将票证单上传到系统中。 +* Manager 层在 Ticket 数据库上方提供了业务对象抽象。 它调解了所有与票证表的对话。 +* 票务表会因买卖双方的活动以及事件周围的自然流量突发性而受到影响。 +* 活跃的市场可能导致移动客户端与系统的当前状态过时，因此买家对旧数据做出反应。 +* 两个数据泵将来自 Tickets 数据库的数据馈送到内部和外部系统：我的帐户，查找和公共馈送。 我的帐户是用户帐户的界面。 查找是一种搜索功能。 Public Feeds 为 ESPN 和 eBay 等网站提供支持。 + * 内部供稿-包含用于仪表板，卖家是谁，销售情况，销售速度，热图等敏感信息，例如帐户信息。它还根据敏感的市场数据供稿主页的某些部分， 例如热门话题，他们不想与公众分享。 + * 外部供稿（LCS）-广告商，例如 ESPN ，都通过此供稿供稿。 广告是通过 IP 地址映射的地理位置。 +* LCS （上市目录服务）： + * 我在这里道歉，幻灯片有些偏离，并且很难使演讲者与演示文稿匹配。 所有错误都是我的。 + * 触发器用于使修改表保持最新状态，以进行数据库中发生的更改。 + * 更改数据捕获作业不断轮询更改，并将消息注入到 ActiveMQ 代理中。 这是路由的第一级，包含 sma ll 有效负载：对象 ID，对象类型和更改日期。 + * 更改数据被路由到主服务器，这是在数据中心之间进行复制的基本机制。 辅助数据中心订阅了这些主题，这就是在数据中心之间复制数据的方式。 + * 进入主数据后，数据将被注入 SEDA 队列中进行处理（稍后会有更多介绍）。 + * 未使用管理器是因为存在许多不使用管理器而直接进入数据库的旧系统，因此数据库是分发增量的常见点。 + * 他们的大多数广告是 Flash，但有些广告使用 HTML 呈现。 + * LCS 提供了购物体验，例如从体育场的交互式图形中选择门票。 Solr 使添加这样的新功能非常容易。 +* SEDA （分段事件驱动的体系结构）在主服务器中使用 + * 主服务器接收 sma ll 更新并弄清楚如何 构建进入内存缓存的内容，以便最终将路由到 Solr 。 + * 使用协议缓存格式将消息缓存在 memcached 中。 + * 消息发送到第二个代理，该代理将消息分散到边缘，即 Lucene / Solr。 + * 消息使用者从代理接收消息。 + * 从数据库加载实体。 + * 确定更新是否有任何级联影响。 因为 Solr 和其他 NoSQL 数据库不进行联接，所以例如，如果更改了乐队名称，则该更改必须传播到 ll 事件。 + * 序列化实体。 将其存储在内存缓存中。 + * 将消息发送到第二个 ActiveMQ 代理，该代理将消息路由到边缘，即 Solr。 + * 通过单独的路由处理代理侦听代理。 这曾经在 Jboss 中，但是 Jboss 会不知所措，他们遇到了饥饿问题，因此将其移出 Jboss。 该侦听器成为系统中用于操作管理的有用阀门。 如果他们需要换出新的 Solr 索引以放入新架构，则可以关闭阀门，让消息在消息代理中备份，然后再次打开阀门，消息将再次开始流动。 从 Solr 故障中恢复，复制索引和更新模式时，这些阀门对其操作稳定性产生了巨大影响。 + * A ll 这些都是阻塞操作，因此使用线程池可以防止数据库连接风暴。 + * SEDA 是一种平滑负载的技术。 从资源管理的角度来看，这对他们是有效的。 想法是将工作分解成足够小的部分，以至于缓慢的工作不会窃取其他用户的线程。 工作是分阶段建模的，每个阶段都有自己的线程池，可作为工作节流阀。 +* Solr + * Solr 提供了一个不错的文档存储和自然语言文本查询功能。 + * 所有搜索都基于 Solr，包括构面。 + * 快速。 查询以 10 毫秒或更短的时间返回。 他们在 SAN 上使用了 Infiniband 网络，发现他们不需要在内存中缓存数据，他们可以通过快速的网络以足够快的速度为 SAN 提供数据服务。 + * 潜力。 灵活的查询语言，可以使用 ll 文本搜索以及 geo -特殊搜索。 + * 支持许多输出格式：XML，Atom， RSS ，CSV， Json 。 使与各种客户端的集成变得更加容易。 + * 高频写入不是很好。 在高频写入下复制似乎集成得不好。 看到成千上万的更改时执行 rsync 不起作用。 您会获得真正过时的数据。 因此，他们必须建立自己的复制机制。 + * 平面数据结构。 仍然几乎是面向行的。 他们希望支持结构更复杂的文档。 +* DCL -双击介绍浏览 + * URL 映射到 ID ：类型 ID，地理位置 ID，渲染类型 ID。 + * DCL （仅是 XSL ）使用类型 ID 和 Geo ID 为 LCS 创建查询。 然后可以一般性地呈现返回的数据。 因此 ll footba ll 小组可以使用 URL 映射 XSL 和 LCS 为他们生成具有完全相同结构的相似页面 ]。 + * 巨大的生产率提高，使添加新功能变得更加容易。 页面中的每个块都是通过 CMS 管理的单个资产。 它们是 XSL 的大块，针对从 LCS 中检索到的上下文文档进行渲染。 + * A RenderChunkByName ca ll 使在 Facebook 等其他服务上呈现事件变得容易。 + * 在后端进行所有这些操作以实现 SEO 目的。 当搜索引擎可以为 Ajax 编制索引时，他们可能不需要这样做。 +* gifs ，样式表等的边缘缓存，但是数据缓存在它们的服务器上。 +* 减少每笔交易的客户互动次数： + * 客户互动是其营业收入的最大消耗。 当情况恶化时，需要与买卖双方共同努力以解决问题。 + * 增加客户自助服务。 顾客想知道什么时候拿到钱和票。 MyAccount 屏幕允许客户在不使用客户服务的情况下检查订单进度。 + * 向卖家公开 API ，以便他们可以将这些功能集成到他们的系统中。 + * IVR -集成的语音识别系统支持客户打电话以查找其帐户状态。 + * 现金流量对供应商很重要，因此他们致力于更快地付款。 + * 与美国职棒大联盟（Major League Baseball）的电子集成，因此他们可以在卖方实际拥有票证之前直接从卖方将票证转让给买方。 即时交付并极大地提高了客户满意度并消除了故障点。 +* 生命周期总线 + * 用于防止硬链接应用程序中的复杂工作流。 签出应用程序不必担心 ll 下游存在的不同业务流程。 您只需要担心已验证的信用卡和订单，而不要担心配送和电子邮件之类的问题。 + * 在处理遗留问题和管理站点更改时很有用。 + * 有关于 ll 主要生命周期事件的主题。 代理在 Oracle 队列中侦听主题。 下订单时，它将进入未确认状态。 侦听器将收听“未经确认”的主题，并通过电子邮件向卖方发送电子邮件以访问该站点并确认订单。 当卖方确认订单后，那里的代理商将从买方的托管账户中提取款项，向买方发送电子邮件，说明卖方已确认并在何处找到机票。 确认票证后，付款便退给了卖方。 + * 所有这些逻辑都与面向网站的最终用户分离。 这些都是后台引擎。 + * TeamWorks 为这些流程建模，发现弱点，监视流程，检查 SLA 并触发操作。 帮助更好地优化后台业务流程。 由于他们每年以 20％的速度增长，因此他们不希望运营团队的年增长率达到 20％。 + * FedEx 是最初的履行方式。 电子实现已添加。 业务流程如下：未确认->自动确认； 已确认->条码重发和付款 PDF； 实现。 您要做的就是编写在相同订单生命周期内生存的代理，以实现新的实现模式。 该逻辑不在应用程序中。 它在代理中，是一个可单独部署和测试的单元。 + * 避免欺诈。 使用相同的生命周期模型来实现，但增加了两个新状态：已购买和已批准。 他们无需进行任何更改即可添加避免欺诈的功能。 他们只需要更改状态机即可。 代理决定将其移至批准状态或未批准状态。 +* 销售点系统集成 + * 使用两个阶段的提交：在外部系统上预订票证，将其标记为 StubHub 中声明的内容，在外部系统上提交购买。 + * 希望对此进行概括，以便其他系统可以在交易中购买门票。 将门票与旅行或酒店购买捆绑在一起。 +* Splunk 和染料 + * 在 StubHub 上最大的投资回报率项目之一。 节省了很多调试时间。 + * 染色-工件被放置在每个请求的 HTTP 标头中。 + * 这些使用 Log4j 记录。 + * 使用 Splunk ，如果订单有问题，您可以使用染料标记查看日志行以向后推 ll ，然后查看 ll 属于请求的呼叫，包括对 LCS 之类的其他服务的二次呼叫。 追溯活动很容易。 + * 确实类似于 Splunk 。 就像日志行的文档存储。 将染料标记和 ID 排序到日志行，就像一系列键值对一样， Splunk 使得查看日志变得非常容易。 他们的仪表板是使用 Splunk 编写的，用于统计信息，例如每分钟的事务，每分钟的失败。 您可以根据需要对数据进行切片和切块。 + * 将 Log4j 与消息格式一起使用，以便它不会创建动态字符串。 + +## 得到教训 + +* **可扩展性是专业化** 。 每个问题空间都有其独特的特征，必须构建任何系统来解决该特定问题。 StubHub 受制于对安全购买体验的需求，票务市场的独特性质，突发流量以及事件多变的局面。 他们的系统必须反映这些要求。 +* **从一开始就使用抽象层** 。 否则，您将无法继续为旧客户提供支持，而超出了您的承受能力。 +* **生产中的烘烤** 。 实施多种解决方案，并在生产中进行审核，以确定哪个版本更好。 StubHub 在生产中测试了两个不同的数据泵版本，以发现哪种版本更合适。 您不想支持多种基础架构。 +* **将工作移出 Jboss** 。 大量请求可能会导致 Jboss 饿死，因此他们将工作移到 Jboss 之外。 +* **通过因果链** 渗滤染料。 检测请求，以便可以在整个堆栈中跟踪请求。 这是一个巨大的投资回报，能够调试整个堆栈中的问题。 +* **优化业务流程。** 系统之间的电子集成。 通过充当卖方，买方和 MLB 之间的协调者，他们能够提高客户满意度并消除交易中的大量可能失败点。 购买了受欢迎的销售点程序，以便他们可以与它集成。 +* **建立在您自己的 API** 上。 他们花费大量时间尝试在自己的 API 上构建自己的应用程序，以便他们可以更好地管理其用户和合作伙伴的体验。 +* **一般定义资产** 。 定义资产以便可以在任何上下文中呈现它们，可以轻松组成不同格式的页面并在其他网站上呈现事件。 +* **从 ROI 透视图** 最大化开发。 寻找可提高开发人员 ROI 的项目。 使用 Solr 对他们来说是一个巨大的胜利。 它易于使用，快速且非常实用，可以立即满足许多类型的查询。 +* **SEDA 适合阻止读取** 。 他们的许多系统都基于阻止读取，因此 SEDA 非常适合该用例。 线程池可防止淹没他们要使用的资源。 +* **在客户端** 上呈现。 对于像体育场馆地图这样非常酷的交互式地图，在客户端上通过 ll 处理 ll 的 UI 交互可节省大量服务器负载。 即使对于具有 10-20K 列表的大型活动，下载整个列表也是一个更好的解决方案。 +* **比重框架**更薄。 沉重的框架易于使用和滥用。 隐藏的复杂性使您很快失去对站点的控制。 示例：Hibernate 和基于组件的框架。 验证和业务逻辑可能会泄漏到表示层中。 做出明智的决定。 了解遗留问题方面的问题。 +* **糟糕的经历是最好的训练** 。 就像没有教给如何正确做事一样。 刚开始 StubHub 的家伙正在通过尽快发布功能来建立业务，但这留下了一笔遗产。 管理遗留物的关键是管理依赖关系。 使用基于代理的 Lifecycle Bus 样式解决方案可帮助他们了解对遗留系统的依赖性。 +* **使用工作流将状态机与应用程序分离。** 不要在应用程序逻辑中嵌入复杂的流。 外部化逻辑，以便业务流程可以更灵活的方式耦合在一起。 这使系统在未来变得无限灵活和适应性强。 +* **避免使用 ETL** 。 它引入了许多您不想处理的依赖项。 有风险。 当您尝试确定财务上依赖的变更对您而言是否很大时，旧式数据模型可以真正占用资源。 +* **不要缩短 CM 和部署**。 当前，对于开发人员来说，这是最大的浪费时间。 非常痛苦 现在投资您的 CM 和部署系统。 +* **投资持续改进** 。 它不是免费提供的。 在项目上运行验尸。 确保问题不再出现。 随着公司的发展，这些东西无法扩展。 立即做出正确的决定，否则将来 ll 需要花费 3 到 5 倍来解决。 +* **在系统** 中建立操作阀。 例如，如果您需要换出新的架构，请使用一个阀门，您可以在其中关闭事件并重新启动它们。 + +该 Java Framework Tapestry 在哪里使用？ + +您是在我们网站上还是其他地方？ + +“当您试图找出变更是否会带来巨大收益时，它们将成为您财务上依赖的系统。” + +句子里有错字，对不对？ 难道不是“当您试图确定变更是否会创建您在财务上依赖的系统时”吗？ 谢谢。 + +爱德华 + +我认为这个家伙在获得我的要点方面做得很好，但是在这种情况下...是的...这很想念...我认为不是错字。 :-)在不返回原始录音版本的情况下，它应该类似于： + +“当您试图确定更改是否会在您所依赖的系统中造成回归时” + +我真的想了解更多有关如何在 HTTP 标头中使用 splunk 和 dye 来跟踪整个堆栈中的每个请求的信息，从调试的角度来看，这是非常有用的功能。 \ No newline at end of file diff --git a/docs/97.md b/docs/97.md index 901d72e..6e5ea78 100644 --- a/docs/97.md +++ b/docs/97.md @@ -1,222 +1,38 @@ -# Twitter 如何使用 Redis 进行扩展-105TB RAM，39MM QPS，10,000 多个实例 +# FictionPress：在网络上发布 600 万本小说 -> 原文： [http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html](http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html) +> 原文： [http://highscalability.com/blog/2012/7/11/fictionpress-publishing-6-million-works-of-fiction-on-the-we.html](http://highscalability.com/blog/2012/7/11/fictionpress-publishing-6-million-works-of-fiction-on-the-we.html) -[姚悦](https://twitter.com/thinkingfish)自 2010 年以来一直在 Twitter 的 Cache 团队工作。 当然，这是关于 Redis 的，但不仅是关于 Redis 的。 +![](img/6f37b298e9264b0bac14f3459012960d.png) -姚明已经在 Twitter 工作了几年。 她看过一些东西。 她看到 Twitter 上缓存服务的增长从仅由一个项目使用到迅速增加到将近 100 个项目。 那就是成千上万台机器，许多集群和数 TB 的 RAM。 +FictionPress 同时经营 FictionPress.com 和 FanFiction.net，拥有超过 600 万种小说作品，来自世界各地的数百万作家/读者以 30 多种语言参加。 -从她的讲话中可以很明显地看出，她来自一个真正的个人经历的地方，并且以一种探索问题的实用方式闪耀出来。 这个话题值得一看。 +**已解决的问题**： -如您所料，Twitter 具有大量缓存。 +* 支持 100+百万行的复杂高效索引。 +* 不管数据大小如何增长，可预测且一致的性能。 +* 快速恢复。 +* 确保大规模的可预测性能 -Timeline Service for one datacenter using Hybrid List: +**挑战**： -* 约 40TB 分配的堆 -* 〜30MM qps -* > 6,000 个实例 +FictionPress 为庞大的用户群提供了许多交互式功能。 其中包括讨论论坛，现场消息传递和用户评论。 FictionPress 决定建立自己的讨论论坛，以满足其严格的安全性和性能要求。 FictionPress 的首席技术官邢力指出，该网站“需要举办成千上万个论坛。 现有的论坛软件无法达到我们的性能和安全目标。” -Use of BTree in one datacenter: +为了确保论坛的实时响应性，FictionPress 需要具有创建和有效维护复杂索引并能够支持数百万个小行的能力。 此外，它需要能够对它们建立索引，并且对资源成本和性能的影响最小。 “使所有这些工作并提供良好的客户体验的唯一方法是，即使行数超过 1 亿，也要保证我们的数据库后端能够提供可预测的稳定性能。” -* 约 65TB 的已分配堆 -* 〜9MM qps -* > 4,000 个实例 +FictionPress 考虑使用 InnoDB，它是 MySQL 的默认存储引擎，但它无法提供可预测的大规模性能。 随着行数的增加，索引变得非常慢，从而导致读写性能下降。 InnoDB 还没有提供多个聚簇索引的性能增强功能。 -稍后，您将了解有关 BTree 和 Hybrid List 的更多信息。 +**解决方案**： -有几点值得注意： +FictionPress 使用 MariaDB 和 TokuDB 管理其讨论论坛，评论和现场消息传递系统。 -* Redis 是一个绝妙的主意，因为它占用服务器上未充分利用的资源并将其转变为有价值的服务。 -* Twitter 对 Redis 进行了专门化，提供了两种完全适合其用例的新数据类型。 因此他们获得了所需的性能，但是将它们锁定在基于旧代码的代码中，因此很难合并到新功能中。 我想知道，为什么要使用 Redis 这样的东西？ 只需使用您自己的数据结构创建时间轴服务即可。 Redis 真的为聚会增添了什么吗？ -* 在网络饱和之前，请使用本地 CPU 功能汇总节点上的大量日志数据。 -* 如果您想要高性能的产品，请将快速路径（即数据路径）与慢速路径（即命令和控制路径）分开， -* Twitter 正在以 Mesos 作为作业调度程序进入容器环境。 这仍然是一种新方法，因此了解它的工作方式很有趣。 一个问题是 Mesos 浪费问题，该问题源于在复杂的运行时世界中指定硬资源使用限制的要求。 -* 中央集群管理器对于使集群保持易于理解的状态非常重要。 -* JVM 慢，C 快。 他们的缓存代理层正在回到 C / C ++。 +FictionPress 在具有专用硬件的 Linux 环境中安装了 TokuDB。 每种配置都有一个主机，其中有多个读取从机。 Li 说：“ TokuDB 的高写入并发性和对多个聚簇索引的支持使我们可以自由地设计和部署性能更好的大规模查询。” 这对于 FictionPress 很重要，因为其环境在不断扩大。 -考虑到这一点，让我们进一步了解 Twitter 上 Redis 的用法： +可预测的性能：“虽然原始性能很重要，但是响应时间的可预测性是我们对系统进行缩放的一个重点”。 “ InnoDB 只能有一个聚簇索引，但是 TokuDB 基本上为您提供了无限数量。 此外，MyISAM 和 InnoDB 都由于我们大小的数据库上的许多索引而变慢。 MyISAM 还由于并发而导致复制滞后。 最后，TokuDB 为我们提供了可预测性，大规模性能以及更灵活的索引编制，而没有其他 MySQL 选项所具有的限制。” -## 为什么要使用 Redis？ +成本：“要获得更高的性能，总可以向问题扔硬件”，李说。 “相反，通过使用 TokuDB，我们提高了可伸缩性，同时节省了额外的服务器硬件的成本，如果 TokuDB 不在图中，则需要额外的服务器硬件。 此外，由于改进了压缩，与 MyISAM 相比，磁盘空间减少了 8 倍。 节省硬件成本使迁移到 TokuDB 成为一个容易的决定。” -* Redis 驱动着 Twitter 最重要的服务时间轴。 时间轴是由 ID 索引的推文索引。 在列表中将推文链接在一起会生成“主页时间轴”。 用户时间轴（由用户已发布的推文组成）只是另一个列表。 +崩溃恢复：FictionPress 最初一直在使用 MyISAM。 Li 表示：“我们需要替换 MyISAM 来处理较小的 BLOB 数据。” “事实上，我们希望尽可能远离 MyISAM，以缩短其长时间的崩溃恢复。 InnoDB 是一种选择，但是 TokuDB 为我们自己的数据集提供了更好的压缩和更小的核心数据和索引数据存储空间。” -* 为什么考虑使用 Redis 而不是 Memcache？ 网络带宽问题和长通用前缀问题。 +热模式更改：“出于性能原因，我们需要大量索引，但也需要快速添加和维护这些索引，” Li 表示。 “ TokuDB 是我发现的唯一提供热模式更改（例如热索引）的 MySQL 解决方案。 热模式更改是一项强大的功能，我们可以使用它来最大程度地减少系统范围内升级期间的停机时间，并缩短我们的应用程序/架构开发周期。” -* 网络带宽问题。 - - * Memcache 在时间表上不如 Redis 正常工作。 问题在于处理扇出。 - - * Twitter 读取和写入**的次数是递增的**，它们很小，但时间表本身却很大。 - - * 生成推文时，需要将其写入所有相关的时间轴。 推文是一小块数据，附加到某些数据结构。 阅读时，最好加载一小部分推文。 向下滚动会加载另一个批次。 - - * 本地时间行可能比较大，这对于观看者一组阅读是合理的。 例如，也许有 3000 个条目。 由于性能原因，应避免访问数据库。 - - * 在大对象（时间轴）上进行增量写入和小型读取的读取-修改-写入周期太昂贵，并且会造成网络瓶颈。 - - * 在每秒 100K +的千兆链接读写中，如果平均对象大小大于 1K，则网络将成为瓶颈。 - -* 长通用前缀问题（确实是两个问题） - - * 灵活的架构方法用于数据格式。 对象具有可能存在或可能不存在的某些属性。 可以为每个单独的属性创建一个单独的键。 这要求针对每个单独的属性发出单独的请求，并且并非所有属性都可以在缓存中。 - - * 随时间推移观察到的度量标准具有相同的名称，每个样本具有不同的时间戳。 如果单独存储每个度量标准，则长公共前缀会被存储很多次。 - - * 为了在两种情况下都更加节省空间，对于指标和灵活的架构，希望有一个分层的密钥空间。 - -* **下的专用缓存群集 利用 CPU** 。 对于简单的情况，内存中的键值存储是 CPU 轻的。 对于较小的键值，一个盒子上 1％的 CPU 时间可以每秒处理超过 1K 个请求。 尽管对于不同的数据结构，结果可能有所不同。 - -* **Redis 是个绝妙的主意** 。 它可以看到服务器可以做什么，但不能做什么。 对于简单的键值存储，服务器端在 Redis 等服务上有很多 CPU 余量。 - -* Redis 于 2010 年在 Twitter 中首次用于时间轴服务。 广告服务中也使用它。 - -* 未使用 Redis 的磁盘功能。 部分原因是因为在 Twitter 内部，缓存和存储服务位于不同的团队中，因此他们使用他们认为最佳的任何机制。 部分原因可能是因为存储团队认为其他服务比 Redis 更适合他们的目标。 - -* Twitter 分叉了 Redis 2.4 并为其添加了一些功能，因此它们停留在 2.4（2.8.14 是最新的稳定版本）上。 更改为：Redis 中的两个数据结构功能； 内部集群管理功能； 内部日志记录和数据洞察力。 - -* 热键是一个问题，因此它们正在构建具有客户端缓存的分层缓存解决方案，该解决方案将自动缓存热键。 - -## 混合列表 - -* 为**增加了可预测的内存性能**，为 Redis 添加了 Hybrid List。 - -* 时间轴是 Tweet ID 的列表，因此是整数列表。 每个 ID 都很小。 - -* Redis 支持两种列表类型：ziplist 和 linklist。 Ziplist 节省空间。 链表是灵活的，但是由于双链表每个键都有两个指针的开销，因此给定 ID 的大小开销非常大。 - -* 为了有效利用内存，仅使用 ziplist。 - -* Redis ziplist 阈值设置为时间轴的最大大小。 永远不要存储比压缩列表中更大的时间轴。 这意味着产品决策（时间轴中可以包含多少条推文）已链接到低级组件（Redis）。 通常不理想。 - -* 添加或删除 ziplist 效率低下，尤其是列表很大时。 从 ziplist 删除使用 memmove 来移动数据，以确保该列表仍然是连续的。 添加到 ziplist 需要内存重新分配调用，以为新条目腾出足够的空间。 - -* 由于时间轴大小，写入操作可能会出现**高延迟。 时间线的大小差异很大。 大多数用户的推文很少，因此他们的用户时间轴很小。 家庭时间表，尤其是那些涉及名人的时间表。 当更新较大的时间线并且高速缓存用完了堆时，这通常是在使用高速缓存时的情况，在有足够的连续 RAM 来处理一个大 ziplist 之前，将淘汰非常大的**小时间线** 。 由于所有这些缓存管理都需要时间，因此写操作可能会具有较高的延迟。** - -* 由于写入被散布到许多时间轴，因此由于内存用于扩展时间轴，因此更有可能陷入**写等待时间陷阱**。 - -* 鉴于写入延迟的高度可变性，**很难为写入操作创建 SLA** 。 - -* 混合列表是 ziplist 的链接列表。 阈值设置为每个 ziplist 可以以字节为单位的大小。 以字节为单位，因为对于**内存有效**而言，它有助于**分配和取消分配相同大小的块**。 当列表经过时，它将溢出到下一个 ziplist 中。 ziplist 直到列表为空时才被回收，这意味着可以通过删除使每个 ziplist 只有一个条目。 实际上，推文并不是经常被删除。 - -* 在“混合列表”之前，一种变通方法是使较大的时间轴更快地过期，这为其他时间轴释放了内存，但是当用户查看其时间轴时，这是昂贵的。 - -## BTree - -* 在 Redis 中添加了 BTree 以支持对层次结构键的范围查询，以返回结果列表。 - -* 在 Redis 中，处理辅助键或字段的方法是哈希映射。 为了对数据进行排序以便执行范围查询，使用了一个排序集。 排序后的订单按双倍得分排序，因此不能使用任意的辅助键或任意的名称进行排序。 由于哈希图使用线性搜索，因此如果有很多辅助键或字段，那就不好了。 - -* BTree 是尝试解决哈希映射和排序集的缺点。 最好让**一个可以完成您想要的内容的数据结构**。 更容易理解和推理。 - -* 借用了 BTree 的 BSD 实现，并将其添加到 Redis 中以创建 BTree。 支持键查找以及范围查询。 具有良好的查找性能。 代码相对简单。 缺点是 **BTree 的内存效率不高**。 由于指针，它具有大量的元数据开销。 - -## 集群管理 - -* 集群出于单一目的使用多个 Redis 实例。 如果数据集大于单个 Redis 实例可以处理的数据量或吞吐量高于单个实例可以处理的数据量，则需要对键空间进行分区，以便可以将数据存储在一组实例中的多个分片中 。 路由选择一个密钥，并弄清楚该密钥的数据在哪个分片上。 - -* 认为集群管理是 Redis 采用率未激增的**首要原因。 当群集可用时，没有理由不**将所有用例迁移到 Redis** 。** - -* Tricky 正确安装 Redis 群集。 人们之所以使用 Redis 是因为作为数据结构服务器的想法是执行频繁的更新。 但是很多 Redis 操作都不是幂等的。 如果出现网络故障，则需要重试，并且数据可能会损坏。 - -* Redis 集群**倾向于使用** **集中管理器** **来规定全局视图**。 对于内存缓存，很多集群都使用基于一致性哈希的客户端方法。 如果数据不一致，那就这样。 为了提供真正好的服务，集群需要一些功能，例如检测哪个分片已关闭，然后重播操作以恢复同步。 经过足够长的时间后，应清除缓存状态。 Redis 中的损坏数据很难检测。 当有一个列表并且缺少一个大块时，很难说出来。 - -* Twitter 多次尝试构建 Redis 集群。 [Twemproxy](https://github.com/twitter/twemproxy) 并未在 Twitter 内部使用，它是为 [Twemcache](https://github.com/twitter/twemcache) 构建的 和 Redis 支持增加了。 另外两个解决方案基于代理样式路由。 其中一项与时间轴服务相关，并不意味着具有普遍性。 第二个是对 Timeline 解决方案的概括，该解决方案提供了群集管理，复制和碎片修复。 - -* **群集中的三个选项**：服务器相互通信以达成群集外观的共识； 使用代理； 或进行客户端集群的客户端集群管理。 - -* 并非采用服务器方法，因为其理念是**使服务器保持简单** **，笨拙且快速**。 - -* 不接受客户端，因为 **更改很难传播** 。 Twitter 中约有 100 个项目使用缓存集群。 要更改客户端中的任何内容，必须将其推送到 100 个客户端，更改可能要花费数年的时间才能传播。 快速迭代意味着几乎不可能将代码放入客户端。 - -* 之所以使用代理样式路由方法和分区，有两个原因。 缓存服务是一种高性能服务。 如果您想要**高性能的产品，请将快速路径（即数据路径）与慢速路径** **（即命令和控制路径**）分开。 如果将群集管理合并到服务器中，则会使作为有状态服务的 Redis 代码变得复杂，每当您想要**修复错误或为群集管理代码提供**升级时，有状态 Redis 服务必须 也需要重新启动，这可能会丢弃大量数据。 群集的滚动重启很痛苦。 - -* 使用代理方法存在一个问题，即在客户端和服务器之间插入了另一个网络跃点。 **分析显示额外的跃点是一个神话**。 至少在他们的生态系统中。 通过 Redis 服务器的等待时间不到 0.5 毫秒。 在 Twitter 上，大多数后端服务都是基于 Java 的，并使用 Finagle 进行对话。 通过 Finagle 路径时，延迟接近 10 毫秒。 因此，额外的跃点并不是问题。 **JVM 内部是问题**。 在 JVM 之外，您几乎可以做任何您想做的事情，除非您当然要通过另一个 JVM。 - -* 代理失败并不重要。 在数据路径上引入代理层还不错。 客户不在乎与之交谈的代理。 如果超时后代理失败，则客户端将转到另一个代理。 在代理级别没有分片操作，它们都是无状态的。 要扩展吞吐量，只需添加更多代理。 权衡是额外的成本。 代理层被分配用于执行转发的资源。 群集管理，分片和查看群集的操作均在代理服务器外部进行。 代理不必彼此同意。 - -* Twitter 的实例具有 **100K 开放连接** ，并且工作正常。 只是有开销要支付。 没有理由关闭连接。 只要保持打开状态，就可以改善延迟。 - -* 缓存集群用作 [后备缓存](http://www.quora.com/Is-Memcached-look-aside-cache) 。 缓存本身不负责数据补充。 客户端负责从存储中获取丢失的密钥，然后将其缓存。 如果某个节点发生故障，则分片将移至另一个节点。 出现故障的计算机恢复运行时将被刷新，因此不会留下任何数据。 所有这些都是由**集群负责人**完成的。 集中观点对于使集群保持易于理解的状态非常重要。 - -* 用 C ++编写的代理进行了实验。 **C ++代理看到** **性能显着提高**（未给出编号）。 代理层将移回 C 和 C ++。 - -## Data Insight - -* 当有电话说缓存系统在大多数情况下都无法正常运行**时，缓存就很好**。 通常，客户端配置错误。 或者他们通过请求太多密钥来滥用缓存系统。 或一遍又一遍地请求相同的密钥，并使服务器或链接饱和。 - -* 当您告诉某人他们正在滥用您的系统**时，他们需要证明**。 哪个键？ 哪个分片不好？ 什么样的流量导致这种行为？ 证明需要可以显示给客户的指标和分析。 - -* SOA 架构不会给您问题隔离或自动调试的便利。 您必须对组成系统的每个组件具有良好的可见性**。** - -* 决定将 Insight 内置到缓存中。 缓存是用 C 语言编写的，并且速度很快，因此可以提供其他组件无法提供的数据。 其他组件无法处理为每个请求提供数据的负担。 - -* **可以记录每个命令**。 缓存可以 100K qps 记录所有内容。 仅记录元数据，不记录值（关于 NSA 的笑话）。 - -* **避免锁定和阻止**。 特别是不要阻止磁盘写入。 - -* 以 100 qps 和每条日志消息 100 字节的速度，每个盒子每秒将记录 10MB 数据。 开箱即用的大量数据。 万一出现问题，将使用 10％的网络带宽。 **在经济上不可行**。 - -* **预计算日志可降低成本** 。 假设它已经知道将要计算什么。 进程读取日志并生成摘要，并定期发送该框视图。 与原始数据相比，该视图很小。 - -* View 数据由 Storm 汇总，存储并在顶部放置一个可视化系统。 您可以获取数据，例如，这是您的前 20 个键； 这是您的点击量的第二个，并且有一个高峰，这表示点击量模式很尖锐； 这是唯一键的数量，这有助于容量规划。 当捕获每个日志时，可以做很多事情。 - -* 洞察力对于运营非常有价值。 如果存在丢包现象，通常可以将其与热键或尖刻的流量行为相关联。 - -## Redis 的愿望清单 - -* 显式内存管理 。 - -* **可部署（Lua）脚本** 。 刚开始谈论。 - -* **多线程** 。 将使群集管理更加容易。 Twitter 有很多“高个子”，其中主机具有 100+ GB 的内存和许多 CPU。 要使用服务器的全部功能，需要在物理机上启动许多 Redis 实例。 使用多线程，将需要启动更少的实例，这更易于管理。 - -## 获得的经验教训 - -* **量表要求可预测性** 。 集群越大，客户越多，您希望服务成为更具可预测性和确定性的对象。 当有一个客户并且有问题时，您可以深入研究问题，并且很有趣。 当您有 70 个客户时，您将无法跟上。 - -* **尾部延迟很重要** 。 当您扇出很多分片时，如果分片缓慢，则整个查询将变慢。 - -* 确定性配置在操作上很重要 。 Twitter 正朝着容器环境迈进。 Mesos 用作作业计划程序。 调度程序满足对 CPU，内存等数量的请求。监视器将杀死超出其资源需求的任何作业。 Redis 在容器环境中引起问题。 Redis 引入了外部碎片，这意味着您将使用更多内存来存储相同数量的数据。 如果您不想被杀死，则必须通过供过于求来弥补。 您必须考虑我的内存碎片率不会超过 5％，但我会多分配 10％作为缓冲空间。 甚至 20％。 或者，我想每台主机将获得 5000 个连接，但以防万一我为 10,000 个连接分配内存。 结果是巨大的浪费潜力。 如今，超低延迟服务在 Mesos 中不能很好地发挥作用，因此这些工作与其他工作是隔离的。 - -* **在运行时了解您的资源使用情况确实很有帮助** 。 在大型集群中，会发生坏事。 您认为自己很安全，但是事情会发生，行为是无法预料的。 如今，大多数服务无法正常降级。 例如，当 RAM 达到 10GB 的限制时，请求将被拒绝，直到有可用的 RAM。 这只会使与所需资源成比例的一小部分流量失败。 很好 垃圾收集问题不是很正常，流量只是掉在地上，这个问题每天都会影响许多公司中的许多团队。 - -* **将计算推入数据** 。 如果查看相对的网络速度，CPU 速度和磁盘速度，那么在进入磁盘之前进行计算并在进入网络之前进行计算是有意义的。 一个示例是在将节点上的日志推送到集中式监视服务之前对其进行汇总。 Redis 中的 LUA 是将计算应用于数据附近的另一种方法。 - -* **LUA 今天尚未在 Redis 中投入生产** 。 按需脚本编写意味着服务提供商无法保证其 SLA。 加载的脚本可以执行任何操作。 哪个服务提供商会愿意冒别人代码的风险承担违反 SLA 的风险？ 部署模型会更好。 它将允许代码审查和基准测试，因此可以正确计算资源使用情况和性能。 - -* **Redis 是下一代高性能流处理平台** 。 它具有 pub-sub 和脚本。 为什么不？ - -## 相关文章 - -* [Google：驯服长时间延迟的尾巴-当更多的机器等于更差的结果时](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) [架构](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) -* [Twitter 用于处理 1.5 亿活跃用户，300K QPS，22 MB / S 的 Firehose，并在 5 秒内发送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) -* [带有碎片的问题-我们可以从 Foursquare 事件中学习到什么？](http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-from-the-foursquare.html) -* [始终记录所有内容](http://highscalability.com/blog/2007/8/30/log-everything-all-the-time.html) -* [低级可伸缩性解决方案-聚合集合](http://highscalability.com/blog/2013/3/6/low-level-scalability-solutions-the-aggregation-collection.html) - -万一 Twitter 上有人读过我：为什么不禁用 EVAL（不是 EVALSHA），重命名 SCRIPT 并使用它来预加载脚本？ 然后，您可以发布您的客户端可以使用的 SHA 目录。 - -“ Redis 是下一代高性能流处理平台。它具有 pub-sub 和脚本功能。为什么不呢？” - -更重要的是，2.8.9 在 PFADD / PFCOUNT / PFMERGE 命令中添加了 HyperLogLog（当然，Twitter 被困在 2.4 中）。 这样就可以在恒定内存中非常精确地近似估计流中唯一键的数量，而不必存储整个数据集。 例如，每天/每周/每月的唯一身份访问者数量。 这使大量分析成为可能，而不必使用像 Hadoop 这样的大数据大炮。 - -@Pierre Chapuis：我认为您的建议会奏效。 我认为这不是最干净的方法，但是：SCRIPT *是一个在线命令，如果我要离线加载（或者至少不通过数据路径完成加载），我会强烈建议这样做。 可能添加了一个配置选项，例如 SCRIPT_LOAD_PATH，以按照您的建议从目录中读取它们。 - -现在，如果我们允许即时重新加载配置（我在当前项目中已经计划过的事情），您甚至可以更新脚本而不会丢失所有数据或阻止流量。 - -MM 被用作百万的缩写吗？ 在技​​术环境中看到它似乎有些奇怪……这不是更多的财务缩写吗？ Just M 对我来说更容易。 - -我喜欢这样的观察：面向服务的体系结构的优点（概括地说）仅与您在服务边界处所做的工作一样好。 她说这是出于监视的目的（SOA 并没有因为服务 A 而神奇地将服务 B 隔离出问题）。 但这似乎同样适用于记录清晰的 API 合同，保持代码库清晰等。我在阐明将应用程序分解为服务方面对我有吸引力的方面时遇到了一些麻烦，而我认为那是缺少的部分-仅仅是 SOA 的概念不能提供大多数价值； 在边界上应用的整套实践可以提供帮助。 - -还发人深省（且合理）：像 Redis 这样的代码库往往不会由委员会维护，您需要进行认真的审查才能阻止糟糕的代码。 （最近阅读了很多 golang 的代码审查/变更列表流，因为它是公开的，有时它是保持语言状态最简单的方法，并且通常给它留下深刻的印象。） - -关于脚本，我想知道如何在包装盒上找到包含数据的脚本，作为具有自己的容器和资源限制的普通 Redis 客户端。 您可以避免带宽限制； 您可以控制资源的使用（也许在分配内核的级别？）； 您不仅可以使用 Lua，还可以使用 Scala 或其他任何方法（尽管如此，但是，GC）。 Redis 的进程内 Lua 脚本可能没有通信成本，而它们会占用宝贵的 RAM 来存储数据，但这是一件容易的事。 - -对于 Twitter 开放源代码混合列表/树，这听起来像是最好的“自私”论据，它最终意味着更快地加入 2.8。 :) - -@姚谢谢您的回答。 我同意选择离线加载（“东京霸王”）会更好。 另外，为 SHA 赋予别名是经常需要的功能，这将大有帮助，并使得可以以向后兼容的方式更新脚本的实现。 - -阅读这篇文章会让我觉得自己生活在一个平行的宇宙中，并且做着非常相似的事情。 - -嗨， -不错的演示。 我曾经遇到的一个问题是-您是否将 ssl 与 redis 一起使用？ \ No newline at end of file +李说：“我写的是关于我自己的，但是是第三人称的。” \ No newline at end of file diff --git a/docs/98.md b/docs/98.md index cce273b..a5ee855 100644 --- a/docs/98.md +++ b/docs/98.md @@ -1,140 +1,93 @@ -# MixRadio 体系结构-兼顾各种服务 +# Cinchcast 体系结构-每天产生 1,500 小时的音频 -> 原文： [http://highscalability.com/blog/2014/8/25/mixradio-architecture-playing-with-an-eclectic-mix-of-servic.html](http://highscalability.com/blog/2014/8/25/mixradio-architecture-playing-with-an-eclectic-mix-of-servic.html) +> 原文： [http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html](http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html) -![](img/b715dfb0071d9887a35ee1ed3a975e2d.png) +![](img/133810bdcaf72132b08eba8a2df17f5d.png) -*这是 [MixRadio](https://twitter.com/sr_gb) 的首席架构师 Steve Robbins 的来宾[重新发布](http://dev.mixrad.io/blog/2014/08/22/MixRadio-Architecture-Overview/)。* +*这是 [Aleksandr Yampolskiy 博士](http://www.twitter.com/ayampolskiy)， [Cinchcast](http://www.cinchcast.com/) 和 [BlogTalkRadio](http://www.blogtalkradio.com/) 的 CTO 的嘉宾帖子，他负责工程，质量检查，TechOps，电话和 产品团队。* -At MixRadio, we offer a free music streaming service that learns from listening habits to deliver people a personalised radio station, at the single touch of a button. MixRadio marries simplicity with an incredible level of personalization, for a mobile-first approach that will help everybody, not just the avid music fan, enjoy and discover new music. It's as easy as turning on the radio, but you're in control - just one touch of Play Me provides people with their own personal radio station.The service also offers hundreds of hand-crafted expert and celebrity mixes categorised by genre and mood for each region. You can also create your own artist mix and mixes can be saved for offline listening during times without signal such as underground travel, as well as reducing data use and costs.Our apps are currently available on Windows Phone, Windows 8, Nokia Asha phones and the web. We’ve spent years evolving a back-end that we’re incredibly proud of, despite being British! Here's an overview of our back-end architecture. +[Cinchcast](http://www.cinchcast.com) 提供的解决方案使公司能够创建，共享，衡量和货币化音频内容，以吸引和吸引对其业务最重要的人们。 我们的技术将会议桥与实时音频流集成在一起，以简化在线事件并增强与会人员的参与度。 Cinchcast 技术还用于为全球最大的音频社交网络 [Blogtalkradio](http://www.blogtalkradio.com) 提供动力。 今天，我们的平台每天制作和分发超过 1500 小时的原始内容。 在本文中，我们描述了为了扩展平台以支持这种数据规模而做出的工程决策。 -# 架构概述 +## 统计信息 -我们有机会在 2009 年重新设计后端。今天，我们的后端核心是 RESTful 服务的集合，其模式称为['微服务'](http://martinfowler.com/articles/microservices.html)。 这些服务的大小，功能，开发语言和数据存储各不相同，但都具有共同的属性，例如公开定义良好的 RESTful API，可独立扩展的功能（包括监视功能），我们将在下面介绍更多功能。 围绕这些核心服务，我们有两个类似的代理服务，它们是通过配置驱动的，以公开用于不同目的的 RESTful 资源的子集。 “内部工具 API”代理内部 API 的工具，以涵盖客户服务，内容管理，发布组合，监控和许多其他情况。 在公开场合，我们通过“外部 API 身份验证层”服务公开了针对客户端应用和第三方开发人员的 RESTful API。 此服务还具有执行适当的权限和授权方案的工作，例如 [OAuth2](http://en.wikipedia.org/wiki/OAuth) 。 +* 每月浏览量超过 5000 万 +* 已创建 50,000 小时的音频内容 +* 15,000,000 个媒体流 +* 175,000,000 次广告展示 +* 每秒 40,000 个并发请求的峰值速率 +* MSSQL，Redis 和 ElasticSearch 群集中每天存储的数据量为 TB /天 +* 由 10 位工程师组成的团队（在 20 位技术人员中）。 +* 大约有 100 个硬件节点正在生产中。 -对于最终用户，我们的 API 服务的应用范围非常广泛。 我们提供 [HTML5 网站](http://www.mixrad.io/)，适用于所有不同类型诺基亚手机的设备应用程序，Windows 8 应用程序，并且我们还向第三方开发人员提供了相同 API 的子集。 我不会在本文中详细介绍我们的应用架构，因为我们团队的内森（Nathan）先前曾写过[。](http://dev.mixrad.io/blog/2014/02/24/Bringing-MixRadio-to-the-new-Nokia-X-family/) +## 数据中心 -下图概述了系统的主要领域，其中驻留了五十多个微服务： +* 生产网站是从布鲁克林的数据中心运行的。 我们喜欢控制自己的命运，而不是将数据委托给云。 +* Amazon EC2 实例主要用于质量检查和登台环境。 -![](img/a64ef4f603f8083cf2ca61e79a344875.png) +## 硬件 -# 使用的技术 +* 大约 50 台 Web 服务器 +* 15 个 MS SQL 数据库服务器 +* 2 个 Redis NOSQL 键值服务器 +* 2 个 NodeJS 服务器 +* 2 个用于弹性搜索集群的服务器 -我们采取务实的方法，即针对开源技术使用正确的工具来完成这项工作。 目前，我们正在积极使用： +### 开发工具 -## 语言能力 +* .NET 4 C＃：ASP.NET 和 MVC3 +* Visual Studio 2010 Team Suite 作为 IDE +* StyleCop，用于加强代码标准的 Res​​harper +* 敏捷开发方法，Scrum 用于大型功能，看板任务板用于较小的任务 +* Jenkins + Nunit 用于测试和持续集成 +* 按需调味–自动化测试用硒 -* [Clojure](http://clojure.org/) 用于我们的微服务。 -* C＃用于我们的设备应用程序和媒体交付服务。 -* HTML5 / CSS / JavaScript 用于我们的网络体验。 +## 使用的软件和技术 -## 存储 +* **Windows Server 2008 R2 x64** ：操作系统 +* **SQL Server 2005** 在 **Microsoft Windows Server 下运行 2008 年** Web 服务器 +* **均衡器负载均衡器** ：用于负载均衡 +* **REDIS** ：用作分布式缓存层并用于消息发布-子队列 +* **NODEJS** **用于实时分析和更新 Studio 仪表板** +* **ElasticSearch** ：用于节目搜索 +* **Sawmill +自定义解析器脚本：** 用于日志分析 -* [MySQL](http://www.mysql.com/) -* [Solr](http://lucene.apache.org/solr/) -* [MongoDB](http://www.mongodb.org/) -* [Redis](http://redis.io/) -* [Elasticsearch](http://www.elasticsearch.org/) -* [ZooKeeper](http://zookeeper.apache.org/) -* [SQLServer](http://www.microsoft.com/sqlserver) +## 监控 -## 基础设施 +* **NewRelic** 用于性能监控 +* **Chartbeat** 对性能对 KPI（转化，页面浏览）的影响 +* **Gomez，WhatsupGold 和 Nagios 提供各种警报功能** +* **SQL Monitor：** 来自 Red Gate-用于 SQL Server 监视 -* [适用于 Linux 微服务的 AWS](https://aws.amazon.com/) 。 -* [Azure](http://azure.microsoft.com/) 用于 Windows 和媒体存储上运行的媒体服务。 -* [GitHub Enterprise](https://enterprise.github.com/) 用于源代码控制。 -* [Packer](http://www.packer.io/) 用于创建机器映像。 -* [人偶](http://puppetlabs.com/)，用于调配和检查机器映像。 +## 我们的方法 -## 监控方式 +* “简短，聪明，消失”：尊重他人的时间。 不要有问题，要有解决方案。 +* 不要去追逐当今的热门技术。 而是“缓解您的主要问题”。 我们采用新技术，但是在业务案例需要时采用新技术。 当您有数百万个用户时，生产中断的需求就会大大降低。 +* 达到“基本”，然后担心“优秀”。 +* 成为“如何团队”而不是“没有团队”。 +* 将安全性纳入软件开发生命周期。 您需要培训开发人员如何编写安全软件，并使之从一开始就成为企业的优先事项。 -* [Nagios](http://www.nagios.org/) -* [石墨](http://graphite.wikidot.com/) -* [Tasseo](https://github.com/obfuscurity/tasseo) -* [塞伦](https://github.com/scobal/seyren) -* [篝火](https://campfirenow.com/) -* [PagerDuty](http://www.pagerduty.com/) -* [主题演讲](http://www.keynote.com/) -* [Logstash](http://logstash.net/) -* [Kibana](http://www.elasticsearch.org/overview/kibana/) +## 架构 -# 建筑原理 +* 所有 Javascript，CSS 和图像都缓存在 CDN 级别。 DNS 指向将请求传递到原始服务器的 CDN。 我们使用 Cotendo 是因为它允许在 CDN 上做出 L7 路由决策。 +* Web 服务器的单独群集用于为常规用户和广告用户提供服务，以 Cookie 区分。 +* 我们正在朝着面向服务的体系结构发展，该体系的关键部分（例如搜索，身份验证，缓存）是以各种语言实现的 RESTFUL 服务。 这些服务还提供了一个缓存层。 +* REDIS NOSQL 键值存储（redis.io）用作数据库调用之前的缓存层。 +* 横向扩展用于在整个 Web 服务器花园中维护会话状态。 但是，我们正在考虑切换到 REDIS。 -为了使 API 与五十多种微服务保持一致，我们制定了有关 URI 结构，分页，排序，大小写，处理语言代码等方面的标准； 但是在开放的文化中，我们通常使用原则而不是硬性规则来获得一致性。 我们的服务应： +![](img/ed592e2401d3b5991b70f1e4330edc7d.png) -* 松散耦合，无状态，并通过 HTTP 提供 JSON 的 RESTful 接口。 -* 单独部署并拥有自己的数据，即其他服务通过 API（而不是数据库连接）访问数据。 这允许单独的规模以及持久性技术和数据结构的更改。 -* 当我们为每个服务使用一个机器实例时，它既不会太大以致于变得笨拙，又不会太小而使其浪费计算资源。 -* 实施用于检查的 Healthcheck API，并负责确定健康状况。 -* 永远不要破坏他们的消费者。 我们很早就同意一个标准，在资源路径中有一个版本号（例如`/1.x/products/12345/`），这样如果需要进行重大更改，则可以并行部署新版本并被上游消费者采用 。 即使我们仍然保留此功能，多年来也不需要使用它。 +## 获得的经验教训 -除了这些内部原则外，对于面向公众的 API，我们还添加了以下内容： +* **无法在 SQL Server 数据库中搜索文本**。 它阻塞了 CPU，所以我们切换到 ElasticSearch（Lucene 派生的）。 +* **Microsoft 的内置会话模块容易出现死锁**，因此我们最终将其替换为 AngiesList 会话模块，并将数据存储到 REDIS。 +* **日志记录是检测问题的关键。** +* **重塑车轮可能是一件好事**。 例如，最初我们使用供应商产品将 JS / CSS 捆绑在一起，这开始导致性能问题。 然后，我们重新编写了捆绑包，并显着提高了我们网站的性能。 +* **并非所有数据都是相关的**，所以数据库并不总是一个好的媒介。 一个很好的类比是“假设您有水顺着管道流下。 管道的顶部较宽，而底部则较窄。” 顶部是 Web 服务器（其中有很多），底部是数据库（很少，并且被阻塞了）。 +* **在开发过程中不使用指标就像试图在高度计不起作用的情况下将飞机降落在风暴中**。 在整个开发过程中，计算指标，例如站点吞吐量，修复 Blocker /关键 bug 的时间，代码覆盖率，并使用它们来衡量性能。 -* API 已针对移动设备进行了优化：我们使用 JSON，因为与低功耗设备上的 XML 相比，它解析所需的内存要少于 XML，并尽可能使用 GZIP 编码响应，最重要的是-如果不需要数据，则不会返回。 最后一点是与 API 一致性的良好平衡。 -* 尽可能使用缓存； API 返回适当的缓存头，以便将内容缓存在最终用户设备和浏览器以及[内容分发网络（CDN）](http://en.wikipedia.org/wiki/Content_delivery_network)上，从而首先使内容更接近我们的消费者。 -* 云中会保留尽可能多的逻辑和数据真实性，以减少应用程序中逻辑的重复并提供一致的体验。 -* 相同的 API 用于所有客户端-网络，移动，桌面和第三方子集。 但是，为了针对不同的屏幕尺寸和要求进行优化，我们使用了一些技巧。 一个明显的例子是“ itemsperpage” querystring 参数，用于调整返回的内容数量。 另一个适用于 RESTful API 设计，其中资源返回隔离的内容。 我们经常将内容分组为所谓的“视图”，以减少所需的请求数量。 +感谢您的有趣帖子。 您如何处理 sql 数据库的复制？ 谢谢！ -使用视图 API 的一个示例是我们应用程序中的艺术家详细信息页面，该页面包含来自许多资源的数据-艺术家传记，图像，推文，演出，并混合了其中的专辑，热门专辑，热门歌曲和类似歌手。 通过将其组合成一个“视图”，应用程序可以一击即获得约 5KB 的数据。 +有趣的 +您模型的“关系”部分是什么？ -# 快速微服务 - -在过去的几年中，我们已经在 [Clojure](http://clojure.org/) 而非 Java 中构建了微服务。 Clojure 是一种动态语言，仍然可以在 Java 虚拟机（JVM）上运行，并且还允许访问 Java 框架。 我们的后端团队出于开发速度和运行时的速度选择使用 Clojure。 Clojure 比 Java 简明得多-例如，这是我们在 Clojure 中重新开发的 Java 服务之一，其代码行数从 44,000 行增加到 4,000 行（包括所有配置，测试和其他工件）。 我们使用 [Leiningen](http://leiningen.org/) 来加快开发速度-Leiningen 提供的一个方面是自定义项目模板，我们有一个名为`cljskel`的模板为我们创建框架服务。 我们打算在以后的帖子中再次使用该模板，但是为了说明使用，我们能够运行以下命令，并具有带有监控 API 的功能性 RESTful 服务： - -``` -lein new cljskel -``` - -如果您对我们如何进入 Clojure 感兴趣，您可能想观看我们两位工程师去年在伦敦所做的演讲。 - -# 数据 - -我们处理的两个最大数据源是我们拥有的 32+百万首曲目的内容元数据（以及相关的艺术家，专辑，混音等）以及来自我们的应用程序的分析数据，例如播放事件，大拇指向上/向下 和导航事件。 - -Catalog 服务（请参见下图）为我们的消费者体验提供内容元数据和搜索功能。 “主目录”服务存储来自各种来源的原始数据，例如记录标签，我们的内部内容团队和互联网资源（例如 Wikipedia）。 配置驱动的数据模型指定了如何合并来源（例如，优先考虑从我们的内容团队得到更正的某些字段，而不是其他来源），哪些字段可搜索以及哪些字段返回给调用者。 我们可以返回不同的字段来满足不同的用例。 例如，我们不需要搜索结果中的专辑曲目列表，但在显示专辑详细信息时确实需要它们。 主目录服务不会直接为用户流量提供服务，而是“搜索和查询” API 是其余后端的接口。 搜索和查询服务基于 [Apache Solr](http://lucene.apache.org/solr/) 构建，“索引后台程序”服务对主目录进行爬网以获取发布到 Solr 搜索索引的更新。 - -[![](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/catalogue.png)](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/catalogue.png) - -收集分析和使用数据对于驱动个性化体验，进行 A / B 测试，CRM，计算业务指标和合同报告至关重要。 随着数据全天不断地从各种应用程序进入后端，许多服务需要同时访问同一数据。 一个例子是用户在曲目上按下了“ thumbs down”按钮，这对于当前播放曲目的混合很重要*和*到用户的整体口味，重复的拇指 下降表示不喜欢艺术家。 为了能够处理我们期望的数据量，去年初我们决定需要一个发布-订阅模型，该模型将： - -* 高可用性，无单点故障。 -* 通过解耦和暂停传入消息的能力为整个系统提供可伸缩性。 -* 与消息格式无关。 -* 写延迟低（即“即发即弃”的语义）。 -* 为订户提供快速吞吐量。 -* 提供简单的发布和订阅 API。 -* 支持多个用户使用相同的数据，每个用户可能具有不同的体系结构，并以不同的速度和时间表运行。 例子是实时处理与批处理聚合或归档。 - -我们从 LinkedIn 选择了 [Apache Kafka](http://kafka.apache.org/documentation.html#introduction) ，因为它非常适合我们的需求。 特别是它是一个持久的消息传递系统，旨在支持许多具有自己状态（例如读取数据的位置）的消费者，而不是假设订户永久存在并以相同速率消费数据。 - -# 监控方式 - -我们针对关键用例的<延迟时间为 0.8 秒，在为期 90 天的滚动期内达到 99.99％的可用性-相当于每月停机 4.3 分钟。 因此，当出现问题时，我们如何知道何时出现问题并迅速做出反应？ 我们具有多层监视功能，可以提醒开发人员和操作工程师。 - -在最低级别上，我们使用 [Nagios](http://www.nagios.org/) 检查虚拟机的基本运行状况，并使用 [PagerDuty](http://www.pagerduty.com/) 来提醒运维工程师。 我们利用每个微服务实现的运行状况检查 API，让 AWS 负载均衡器确定盒子是否需要回收（您可以在此[上一篇文章](http://dev.mixrad.io/blog/2014/05/16/How-we-use-cluppet/)中阅读有关如何配置 AWS 负载均衡器的更多信息）。 [石墨](http://graphite.wikidot.com/)用于收集操作系统级别的指标，例如 CPU 使用率，磁盘空间等。但是，每个微服务也记录自定义指标，这对所涉及的工程师很有帮助。 我们收集的服务指标从低级项目（例如 HTTP 500 错误计数）到高级抽象（激活的订阅数），不计其数。 这是一个石墨仪表板示例： - -[![](img/bc1240be40ba1da5b232e050e5180017.png) ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-graphite.png) - -我们在 Graphite 顶部使用 [Tasseo](https://github.com/obfuscurity/tasseo) 提供漂亮的仪表板数据摘要视图，并使用 [Seyren](https://github.com/scobal/seyren) 根据阈值变化发出警报。 Seyren 由我们的一些工程师创立，并在一篇有关 [2012 年奥巴马连任竞选](http://arstechnica.com/information-technology/2012/11/how-team-obamas-tech-efficiency-left-romney-it-in-dust/)中使用的技术的文章中得到提及。 - -[![](img/6c0a928dace7db3e5f427535cb762426.png) ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-seyren.png) - -在最高级别上，我们使用[主题演讲](http://www.keynote.com/)来监控全球的用例和响应时间： - -[![](img/83227356cbfcd6cf1bd280078debc881.png) ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-keynote.png) - -最后，对于详细的诊断，我们避免了必须通过日志传送连接到特定服务器。 我们使用 [Logstash](http://logstash.net/) 将系统，请求，错误和特定于应用程序的日志收集到中央位置，并与自定义仪表板一起使用 [Kibana](http://www.elasticsearch.org/overview/kibana/) 来跟踪特定的错误或查看趋势。 该示例是几年前我们试图减少应用程序错误噪声时的自定义仪表板： - -[![](img/fb06a3e22974f5a6b53ae1162bcba2ec.png) ](http://dev.mixrad.io/assets/blog/MixRadio-Architecture-Overview/monitoring-errors.png) - -# 持续交付 - -连续交付是一种通过自动化部署和测试以可重复的方式快速发布软件的实践。 从大爆炸发布开始，我们花费了数年的时间来改进我们的流程； 迁移到部署管道，然后使用 AWS 中的 Netflix“红/黑”样式模型迁移到今天的状态。 我们工程团队的 Joe 在 6 月的[伦敦持续交付聚会](http://vimeo.com/100788786)上谈到了这一点。 - -通过查看过去五年中完成的部署次数，可以了解我们的进展情况： - -![](img/c501f46a3ef3035f7bed9683c4ed53b5.png) - -## 相关文章 - -* [MixRadio 历史记录](http://dev.mixrad.io/blog/2014/08/05/MixRadio-History/) \ No newline at end of file +将记录保留在 Disc 阵列中并在 DB 中保留位置不是一个更好的设计。 另外，您也不要在 CDN 服务器上复制脱机内容。 只是好奇 \ No newline at end of file diff --git a/docs/99.md b/docs/99.md index bb0705a..592724b 100644 --- a/docs/99.md +++ b/docs/99.md @@ -1,298 +1,206 @@ -# 使用 HAProxy，PHP，Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构 +# 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容 -> 原文： [http://highscalability.com/blog/2014/8/11/the-easy-way-of-building-a-growing-startup-architecture-usin.html](http://highscalability.com/blog/2014/8/11/the-easy-way-of-building-a-growing-startup-architecture-usin.html) +> 原文： [http://highscalability.com/blog/2012/7/30/prismatic-architecture-using-machine-learning-on-social-netw.html](http://highscalability.com/blog/2012/7/30/prismatic-architecture-using-machine-learning-on-social-netw.html) -![](img/84668570dbc912809cd435a8992b89f2.png) +![](img/70ac891b8ff6179d45189f15eaa4af67.png) -此案例研究是 [Antoni Orfin](http://labs.octivi.com/author/aorfin/) 的来宾帖子， [Octivi](http://octivi.com/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 的联合创始人兼软件架构师。 +*关于 [Prismatic](http://getprismatic.com/) 的体系结构的帖子改编自与 Prismatic 程序员 [Jason Wolfe](http://w01fe.com/berkeley/)* 的电子邮件对话。 + +您今天应该在网上阅读什么？ 任何一个完全现代的人都必须每天解决这个难题，通常使用一些神秘的方法来判断他们的许多供稿中的重要内容：Twitter，RSS，Facebook，Pinterest，G +，电子邮件，Techmeme，以及无数其他信息来源。 + +Prismatic 的 Jason Wolfe 慷慨地同意使用机器学习，社交图谱，BigData，函数式编程和内存实数等性感词来描述其彻底的现代解决方案，以回答“读什么” 及时饲料加工。 结果可能更加隐秘，但是这或类似的事情将是我们如何面对寻找隐藏在无限深的信息池中的有趣主题和故事的挑战。 + +关于 Prismatic，有两点很突出。 他们想让您知道 Prismatic 是由一个由四名计算机科学家组成的小组组成的，其中三名来自斯坦福大学和伯克利分校的非常强大的年轻 PHD。 半危险的方法不会起作用。 他们正在为解决信息过载问题带来大脑力量。 但是这些 PHD 还是程序员，他们从事网站，iOS 编程以及性感的 BigData / ML 后端编程等所有工作。 + +使 Prismatic 作为一种体系结构令我兴奋的一件事是，将来需要一遍又一遍解决的问题是将机器学习实时应用于大量的社会中介信息流 。 保密性使他们无法对自己的机器学习技术说太多话，但是我们的确在幕后高峰。 + +正如您所期望的，他们在做事上有些不同。 他们选择了 Clojure（一种可编译为 Java 字节码的现代 Lisp）作为他们的编程语言。 这个想法是使用函数式编程来构建细粒度，灵活的抽象，这些抽象被组成来表达特定于问题的逻辑。 + +一个功能强大的例子是它们的图形库，他们在各处使用它们。 例如，可以描述计算图以为每个用户创建等效于低延迟，流水线化的 map-reduce 作业集。 另一个示例是使用子图以模块化方式紧凑地描述服务配置。 + +鉴于对功能阐述的关注，他们避免使用诸如 Hadoop 之类的大型框架，而是选择了一个更小，更可靠，更易于调试，更易于扩展且更易于理解的代码库。 + +对 Prismatic 方法的批评是要取得成果需要很长时间的培训。 首先，他们说开始获取优质的内容根本不需要花费很长时间。 其次，我要补充一点，开始使用 Long Sight 考虑这些类型的系统。 基于 ML 的推荐器将从儿童期开始接受培训，并将与您一生保持在一起。 您头脑中的可扩展数字模拟物将同时充当信息守卫和边锋。 + +在 [Tech Crunch 文章](http://techcrunch.com/2012/06/07/in-the-studio-prismatics-bradford-cross-wants-to-reinvent-social-news/)中，Prismatic 创始人 Bradford Cross pithily 将 Prismatic 描述为“围绕复杂的系统构建，该系统可提供大规模，实时，动态的个性化信息重新排名， 很好地将主题分类和归类为本体。” 现在，让我们看看该系统是什么样的... -在文章中，我将向您展示我们基于 HAProxy，PHP，Redis 和 MySQL 开发非常简单的架构的方式，该架构每周无缝处理大约 10 亿个请求。 还应注意进一步扩展该模式和指出不常见模式的可能方法，这些方法特定于该项目。 +## 统计资料 + +* 每天都会从 Twitter，Facebook，Google Reader 和网络上获取并分析成千上万种社交信号，并分析成千上万的新新闻文章，博客文章和其他共享内容。 +* 在用户注册 Prismatic 的几秒钟内，就提取并分析了他们足够的历史活动，以提供非常可靠的主题和发布者建议。 消化了他们的社交网络以寻找似乎分享最相关内容的朋友。 用户在 Prismatic 上进行的每个交互也是一个学习的机会。 +* 在访问家庭供稿后的十分之几秒内，通过将用户兴趣模型与所有这些内容进行匹配，生成了最有趣的故事的供稿。 +* 每周为用户提供数百万的文章展示次数 -## 统计： +## 平台 -* 服务器： +* 托管在 EC2 / Linux 上。 +* 99.9％的后端管道和 API 服务器是用 Clojure 编写的，Clojure 是一种现代 Lisp，可以编译为 Java 字节码。 +* 所有繁重的工作都发生在 JVM 内部。 +* MongoDB +* 的 MySQL +* S3 +* 发电机 +* 专注于构建自定义代码以有效解决特定问题。 - * 3 个应用程序节点 +## 数据存储和 IO - * 2 个 MySQL + 1 个备份 +* 系统不是围绕每个服务在数据库或分布式文件系统之间读取和写入实时数据的典型体系结构，而是围绕数据设计系统。 +* 大多数数据通过后端管道从一项服务流向另一项服务，而没有任何磁盘往返。 +* 在管道的最后，API 机器严重依赖于自定义的内存数据结构，这些数据结构会定期快照到磁盘。 +* 通过使数据尽可能靠近 CPU，大多数 API 请求几乎没有 IO 即可得到服务。 这样可以以非常低的延迟提供提要，从而使 API 机器保持 CPU 绑定，并可以轻松扩展以更轻松地处理更多用户。 +* 使用了许多现成的存储解决方案：MongoDB，MySQL 和 Amazon 的 S3 和 Dynamo。 每一个都经过仔细选择，以匹配要存储的数据的大小，访问模式和其他特征。 + +## 服务 + +* 从较高的层次上看，该体系结构分为大约 10 种不同的服务类型，大致分为 5 种不同的类别：数据摄取-后端； 入职； API-面向客户； 其他服务-面向客户； 批处理和其他服务。 +* 每个服务被设计为执行一种操作，可以以特定方式进行水平扩展，并且通常受到一种或两种特定资源类型（IO，CPU，RAM）的限制。 +* 经济因素偏向于大型机器，因此服务是单身人士，但没有重大瓶颈会阻止水平扩展的预期。 - * 2 个 Redis +## 数据提取-后端 + +* 每天都会创建大量有趣的内容（新闻文章，博客文章，其他网页等），并且 Prismatic 希望尽可能多地了解它。 +* 对于每个内容，必须知道谁在共享它，以及他们在说什么，以便可以在文章旁边显示相关评论，从而可以向用户显示由其朋友或具有相似品味的人共享的内容。 +* 此过程的第一步是摄取和分析内容和社交数据。 采集管道的顶部是轮询器： + * RSS 轮询器在供稿中循环查找新文章 + * Twitter 和 Facebook 轮询器连接到相应的 API，并从用户及其朋友那里获取评论/推文。 + * 这些服务非常简单，并且大多数都是无状态的。 + * 唯一的真实状态和有趣的部分是弄清楚已经看到的内容，并智能地确定接下来要轮询的内容的优先级。 + * 实际上，最困难的问题之一是在每次社交互动流入管道的其余部分之前，先确定其内容是什么。 这很困难，因为人们可能会共享同一篇文章的许多版本（缩短的链接，移动版本和常规版本等）。 +* 从这里，RSS 条目和评论/共享/推文（具有正确规范的 URL）流入障碍，在障碍中确定实际获取和分析的内容。 + * 垃圾邮件和其他垃圾将在稍后的版本中消除，但是最好的伟哥垃圾邮件文章是不会浪费更多的周期的文章。 + * 进行剪切的 URL 传递到获取/分析管道 + * 此阶段的 URL 进入获取/分析管道。 这是许多魔术开始发生的地方。 + * 保留一个 URL 队列，每个 URL 都通过一个“图”运行，该“图”依次详细说明 URL，获取其 HTML，应用机器学习算法提取文章文本，识别最佳图像，提取发布者，并标记适用的标签 主题等等。 + * 为了使这些算法能够快速运行，适合内存并且性能良好，已经进行了大量的工程设计。 处理所有 URL 本身的问题当然令人尴尬地是并行的。 +* 提取阶段的末尾是 doc master，其工作是接收有关它们的精心撰写的文章和社交环境（随着时间的推移不断滴入），进行匹配，将文章（以在线方式）聚集到故事中 集群，确定当前有效的文档集，并管理 API 机器的索引。 + +## 入门-后端 + +* 入职是吸收有关新用户的数据，因此可以在注册该应用后的几秒钟内为他们提供出色的个性化体验。 这有两个主要组成部分： + * 根据用户在 Twitter，Facebook 或 Google 阅读器上的活动，为用户找出建议的主题和发布者， + * 分析用户的社交图谱，以推断出哪些朋友的分享是他们喜欢文章的最有力信号。 +* 这些服务令人尴尬地是并行的，这次是跨用户的。 除了有效的社交图分析的复杂性（Prismatic 不想说太多）之外，关键是如何将这些服务调整为具有非常低的延迟和合理的吞吐量： + * 例如，对于活跃于 Twitter，Facebook 或 Google Reader 的用户，可以在 15 秒或更短的时间内计算出一百多个准确的主题和发布者建议。 这足够快，可以在用户 OAuth 登录后开始计算建议，并且通常在用户完成创建帐户（选择句柄和密码）并进入演练时就可以使用个性化建议。 + * 在这 15 秒内，发生了很多事情： + * 用户最近的帖子可在 Twitter 和 Facebook 上获取，他们喜欢的文章可在 Google Reader 上获取，等等。 这本身可能需要 10 秒钟或更长时间才能完成。 + * 标识用户，她的朋友等共享的多达一千个左右唯一 URL 的集合。 + * 这些流进入获取/分析管道的版本中，在该版本中，所有 URL 都使用上述相同的 ML 堆栈进行提取和详细说明 + * 该分析的结果被汇总，后处理并保存到 DynamoDB 和 S3 +* 此过程的延迟确实很关键，因此这些过程无法串行执行-必须尽可能地进行流水线化和并行化。 +* 吞吐量也很重要，因为该过程非常繁琐，并且在进行大量注册时，需要花费大量精力来降低延迟。 这正是 Prismatic 的流处理和聚合库真正发挥作用的地方，它为每个用户（并行供多个用户）使用接近全容量的低延迟，流水线化的 map-reduce 作业集提供了等效的性能。 机。 -* 应用程序： +## API-面向客户 - * 应用程序每周处理 1,000,000,000 个请求 +* API 机器中包含了 Onboarding 和 Data Ingest 服务。 +* 除了实际的提要生成过程外，不会说太多，只是它是一个复杂且高度优化的过程，该过程具有许多阶段，这些阶段与用户的“指纹”相匹配，并针对索引进行查询，检索，排序和分页生成的提要。 几百毫秒。 +* 从系统角度来看，这里的主要设计目标/挑战是： + * 必须将最新文章编入索引，并且可以用于生成低延迟的提要 + * 该索引非常大（许多 GB），并且必须实时更新，以便用户可以找到重大新闻 + * 用户应在各台计算机之间实现负载平衡，并且响应负载而将新计算机启动（并关闭）相对容易和快速。 + * 产生良好的用户供稿不仅需要索引-我们还需要用户的“指纹”-他们的兴趣，社交关系，他们最近看过的文章等等。 + * 该指纹非常大，并且随着用户查看站点上的内容并与之交互而不断变化。 +* 前几个问题的解决方案涉及 doc-master。 + * doc-master 机器会整理我们当前的文档集，对文档进行预处理，然后每隔几分钟就会将一组准备好的索引文件写入 S3。 + * 当新的 API 机器启动时，它首先读取这些文件并将其转储到内存中，从而为其提供索引的近乎最新的副本。 + * doc-master 还向所有实时 API 机器实时发布用于索引更改（文档/注释添加和删除，故事集群更改等）的命令。 + * 当一台新机器出现时，它会重放最近几分钟的更改历史，以使索引保持最新状态。 + * 机器所需的其他一般状态（非特定于用户的状态）也将从 S3 读取到内存中并定期刷新，或者如果数据较大且访问频率较低，则存储在发电机中。 +* 剩下的问题是如何有效地为用户提供提要，而又不会产生 IO 成本以及在每个请求上获取和更新指纹的延迟。 + * 这里的方法是使用将用户绑定到 API 机器的粘性会话 + * 用户首次登录时，他们的数据都将在过期的刷新回写缓存中全部加载到内存中 + * 在整个用户会话中，此数据保留在内存中，并用于生成其供稿 + * 在整个会话过程中，所有用户操作均通过此同一 API 机器 + * 会话到期或计算机关闭时，每隔几分钟就对指纹中次要部分的更新进行批处理并刷新到冗余存储中 + * 更重要的更新是同步完成的，或者至少使用直接写缓存进行。 +* 在整个会话过程中仅读取一次用户指纹就需要付出很高的 IO 费用，这笔费用会在（通常）相对大量的 Feed 点击，页面，文章点击，共享等用户所获得的费用中摊销，并且 限制此数据的回写次数。 当一台计算机宕机时，数据将被刷新并将用户转移到另一台计算机上-在最坏的情况下，对于某些用户而言，几分钟的非关键数据将会丢失，这对于简单性和可伸缩性的好处是值得的 。 始终可以通过以后的原始事件日志上的批处理作业来弥补此损失。 - * 单个 Symfony2 实例高达 700 req / s（平均工作日-550 req / s） +## 其他服务-面向客户 + +还有其他一些单独的面向客户的服务： + +* 公共提要-对未登录的用户进行主题和发布者提要的智能缓存，根据需要从常规 API 获取它们，并允许对每个提要的多个年龄进行分页。 +* 身份验证-处理帐户创建，登录等。 通常是 SQL 数据库前面的薄层，用于存储需要定期快照和备份的关键用户数据。 +* URL 缩短器 + +## 批处理及其他服务 + +* 机器语言培训，数据归档和事件跟踪/分析的其他服务。 +* MongoDB 用于存储服务器指标和用户分析，主要是因为它支持一个很好的低麻烦的故事，用于发送不同形状的原始事件，维护正确的索引以及保持在线汇总计数。 + +## 图库 + +* 这是一种很好地声明式描述计算图的方法，它发挥了 Clojure 的优势。 图只是 Clojure 映射，其中的键是关键字，而值是关键字函数，这些关键字函数采用由映射中的其他函数计算的值以及外部参数。 +* 它在各处使用。 例如，文档分析管道是一个图形，其中文档的每个详细说明都可能取决于之前的内容（例如，确定文档的主题取决于是否已提取其文本）； 新闻提要生成过程是一个由许多查询和排名步骤组成的图形； 每个生产服务本身就是一个图，其中每个资源（例如数据存储，内存索引，HTTP 处理程序等）都是可以依赖于其他资源的节点。 +* 这样可以轻松地执行以下操作： + * 以模块化方式（例如，使用子图）紧凑地描述服务配置 + * 产生图表，描绘出流程或服务的依赖性 + * 测量诸如文档分析之类的复杂计算中每个节点上发生的计算时间和错误，或诸如 API 之类的复杂服务的每个资源上的活动 + * 在不同的线程（或理论上甚至是机器）上智能地调度此类计算的不同节点 + * 通过使用模拟替换图表中的几个节点（例如伪造存储空间）等，轻松编写我们整个生产服务的测试。 + +## 基于文档和用户的机器学习 + +文档和用户是 Prismatic 应用 ML（机器学习）的两个领域： + +### 文件 ML + +* 给定一个 HTML 文档： + * 了解如何提取页面的主要文本（而不是侧边栏，页脚，注释等），标题，作者，最佳图像等 + * 确定相关功能（例如，文章的主题，主题等） +* 其中大多数任务的设置非常典型。 使用其他机器上的大批作业对模型进行训练，这些机器从 s3 读取数据，将学习到的参数文件保存到 s3，然后在摄取管道中从 s3 读取（并定期刷新）模型。 +* 流出系统的所有数据都可以反馈到该管道中，这有助于了解更多有趣的内容，并随着时间的推移从错误中学习。 +* 从软件工程的角度来看，Prismatic 编写的最有趣的框架之一是“ flop”库，该库实现了最先进的 ML 训练和推理代码，看起来与精美的普通 Clojure 代码非常相似，但是可以编译（使用 宏的魔力）到低级数组操作循环，这些循环与 Java 一样接近金属而无需借助 JNI。 +* 与相应的 Java 相比，该代码可以紧凑和易于阅读，并且执行速度基本相同。 +* 创建[快速运行的故事群集组件](http://blog.getprismatic.com/blog/2012/4/17/clustering-related-stories.html)付出了很多努力。 + +### 用户 ML + +* 猜测用户对社交网络数据感兴趣的内容，并使用应用内的显式信号（+ /删除）完善这些猜测。 +* 使用显式信号的问题很有趣，因为用户输入应该很快反映在其提要中。 如果用户连续从给定的发布者中删除了 5 篇文章，请立即停止向他们展示该发布者的文章，而不是明天。 这意味着没有时间在所有用户上运行另一个批处理作业。解决方案是在线学习：立即根据用户提供给我们的观察结果更新用户模型。 +* 用户交互事件的原始流已保存。 这样可以在以后发生机器故障或类似情况时通过原始数据上的松散写回缓存丢失任何数据，从而在以后的原始事件中重新运行用户感兴趣的 ML。 在线学习中的漂移可以得到纠正，并且可以计算出更准确的模型。 + +## 得到教训 + +* **查找您的故事**。 请仔细考虑整个管道以及流经该管道的所有数据。 使用针对特定问题的解决方案来应对可伸缩性挑战。 每个服务都内置了自己的扩展故事，并且这些服务以一种通信方式进行通信，应该可以轻松地扩展每个组件，而又不会给其他组件带来太多压力。 相反，从围绕 Hadoop 作业构建的系统开始，将所有数据以原始格式存储在分布式数据库/文件系统中，Prismatic 会讲一个不同的故事。 +* **尴尬地发现并行的机会并加以利用**。 +* **在用户等待**的同时并行工作。 例如，入职流程会吸收有关新用户的数据，以便可以在注册该应用后的几秒钟内为他们提供出色的个性化体验。 +* **使用函数式编程**构建细粒度，灵活的抽象。 这些抽象构成为表达特定于问题的逻辑。 +* **避免使用大型，整体式框架**，例如 Hadoop。 这样就产生了一个较小的代码库，在所有条件相同的情况下，它更不容易出错，更易于理解并且更易于扩展。 之所以建立自己的库，仅仅是因为开源代码的许多功能都被锁定在整体框架中，并且在某些问题中断或无法扩展时，不容易重用，扩展或调试。 +* **合适的人对于使这一切都至关重要。 当前的后端团队由三位 CS 博士组成，他们从事从 ML（机器语言）算法到低级系统工程到 Web 和 iPhone 客户端代码的所有工作。** +* **所有代码都尽早投入生产，**通常是通过对使构建和调试生产服务变得简单而有趣的工具进行投资。 +* **保持简单**。 不要为简单的东西承担复杂的库或框架的负担，并且当一个简单得多的解决方案就足够好的时候也不要幻想。 例如，使用简单的基于 HTTP 的消息传递协议，而不是流行的框架之一。 在合理的情况下，乐于为刚刚可用的托管解决方案（例如 S3 或 Dynamo）支付更多费用。 +* **投资构建出色的工具和库**。 例如，Prismatic 的“触发器”库使他们可以在代码的 1/10 中编写与 Java 一样快的数字运算机器学习算法。 “存储”将键值存储的许多不重要的细节抽象掉，从而允许编写用于缓存，批处理和刷新的高级抽象，这些抽象可在各种情况下在各种存储引擎中工作。 “图形”使编写，测试和监视分布式流处理服务变得轻而易举。 +* **仔细考虑每种数据类型**，不要指望找到一种适用于 IO 和存储的千篇一律的解决方案。 + +## 相关文章 - * 平均响应时间-30 毫秒 +* [Prismatic 希望成为数字时代的报纸](http://gigaom.com/2012/05/03/prismatic-wants-to-be-the-newspaper-for-a-digital-age/) +* [棱柱形博客](http://blog.getprismatic.com/) +* [关于 Clojure 的主题演讲](https://github.com/strangeloop/clojurewest2012-slides) +* [棱柱形希望创建一个新类别的社会新闻](http://bits.blogs.nytimes.com/2012/04/03/prismatic-hopes-to-offer-a-new-category-of-social-news/) +* [Prismatic 的布拉德福德·克罗斯（Bradford Cross）在工作室里想重塑社交新闻](http://techcrunch.com/2012/06/07/in-the-studio-prismatics-bradford-cross-wants-to-reinvent-social-news/ ) +* [Prismatic 的软件工程](http://blog.getprismatic.com/blog/2012/4/5/software-engineering-at-prismatic.html) +* [Prismatic 如何处理数据存储和聚合](http://blog.getprismatic.com/blog/2012/4/9/how-prismatic-deals-with-data-storage-and-aggregation.html) +* [DataSift 架构：每秒 120,000 条推文的实时数据挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html ) - * 清漆-超过 12,000 req / s（在压力测试过程中达到） +好看！ -* 数据存储区： +半危险=危险？ 我第一次听到这个词。 - * Redis-160,000,000 条记录，100 GB 数据（我们的主要数据存储！）， +干杯， - * MySQL-300,000,000 条记录-300 GB（第三缓存层） +--rj -## 平台： +罗杰击败了我，但是： -## ![logical architecture.png](img/56cb99c8dcdf79a30dcf13134a25c750.png) +“半危险的方法不会起作用。” 那么好吧，我想什至根本不考虑那些完全危险的方法。 = P -* 监控： +我每天都会使用 getprismatic.com 数周，我必须承认，现在它已成为新闻探索的一部分。 梦幻般的建筑，当我想到它们如何实时带来如此优质的内容时，甚至让我惊讶。 - * 伊辛加 +感谢您对他们的文章进行了详细的高级介绍。 很棒的文章！ - * 已收集 +好读！ :) -* Application: +这都是有点老的学校。 机器学习= 1980。 - * 带有 Keepalived 的 HAProxy - - * 清漆 - - * 带有 Symfony2 框架的 PHP（PHP-FPM） - -* Data store: - - * 具有 HAProxy 负载平衡的 MySQL（主-主） - - * Redis（主从） - -# 背景 - -大约一年前，我们的朋友带着一个苛刻的问题来到我们的办公室。 他们经营着一家快速成长的电子商务初创公司，当时他们想扩展到国际市场。 - -由于它们仍然是一家初创型公司，因此建议的解决方案必须具有成本效益，以免在下一台服务器上用完钱。 旧版系统是使用标准 LAMP 堆栈构建的，他们已经拥有强大的 PHP 开发人员团队。 引入新技术必须很聪明，以免使体系结构过于复杂，并让他们与现有人员进一步维护平台。 - -系统架构必须以可扩展的方式设计，以实现其扩展到下一个市场的计划。 所以我们来检查他们的基础设施... - -![soa-after.png](img/12c817cd917203ed7b1bc8c3efab4761.png) ![soa-before.png](img/164417ce7d2ca4bf693993b632bc38a2.png) - -以前的系统是单片设计的。 在后台有一些单独的基于 PHP 的 Web 应用程序（该创业公司有许多所谓的前端网站）。 他们中的大多数使用单个数据库，他们共享一些处理业务逻辑的通用代码。 - -此类应用程序的进一步维护可能是一场噩梦。 由于必须重复某些代码，因此在一个网站中进行更改将导致业务逻辑不一致-他们始终必须在所有 Web 应用程序中进行相同的更改。 - -从项目管理的角度来看，这也是一个问题-谁负责跨多个代码库分布的那部分代码？ - -根据这些观察，我们的第一步是将核心业务关键功能提取到单独的服务中（这是本文的范围）。 这是**面向服务的体系结构**的模式。 考虑“关注点分离”原则，但要考虑整个系统。 该服务保持一种特定的高级业务功能的逻辑。 举一个真实的例子-服务可以是搜索引擎，销售系统等。 - -前端网站正在通过 **REST API** 与服务进行通信。 响应基于 **JSON** 格式。 我们选择它是为了简单起见，而不是像 SOAP 那样对开发人员来说是苛刻的（没人喜欢解析 XML…;-)） - -提取的服务无法处理身份验证和会话管理之类的事情。 必须在更高层次上处理这些事情。 前端网站对此负责，因为只有他们才能识别其用户。 这样，我们使服务变得更简单-在进一步扩展问题和编写代码方面。 没什么不好的，因为它需要处理不同类型的思考任务。 - -## 好处： - --完全独立的开发团队可以轻松开发单独的子系统（Service）。 开发人员不要互相干扰。 - --**它不处理用户身份验证**和会话，因此这个常见的扩展问题消失了。 - --**业务逻辑保存在一个地方**-跨不同前端网站的功能不再多余。 - --**易于使服务公开访问**。 - -## 缺点： - --**为系统管理员**做的更多工作-服务位于其自己的基础结构中，需要管理员额外注意。 - --**保持向后兼容**-在一年的维护之后，API 方法发生了无数变化。 事实是，它们一定不能破坏向后兼容性，因为这会导致对每个前端网站的代码进行更改-以及一次部署所有网站的繁琐工作……一年之后，所有方法仍与 文档的第一版。 - -# 应用层 - -![physical architecture.PNG](img/03f05424f01e13f6dedef14ccab41d1c.png) - -与请求流一起，第一层是应用程序。 HAProxy 负载平衡器，Varnish 和 Symfony2 Web 应用程序位于此处。 - -来自前端网站的请求首先到达 HAProxy，然后将其分发到应用程序节点。 - -## 应用程序节点配置 - -* Xeon [[受电子邮件保护]](/cdn-cgi/l/email-protection) ，64GB RAM，SATA - -* 漆 - -* 阿帕奇 2 - -* PHP 5.4.X 作为 PHP-FPM 运行，具有 APC 字节码缓存 - -我们有三个这样的应用服务器。 双活模式下的 **N + 1 冗余-“备份”服务器正在积极处理请求。** - -在每个节点上保留**单独的 Varnish 可以降低缓存命中率，但是这样我们在这里没有 SPOF（单点故障）。 我们这样做是为了保持可用性而不是性能（在我们的案例中这不是问题）。** - -已选择 Apache2，因为旧版前端网站服务器也使用了 Apache2。 避免混合使用多种技术，使管理员更易于维护系统。 - -## Symfony2 应用 - -该应用程序本身建立在 Symfony2 之上。 这是一个 PHP 全栈框架，提供了许多有用的组件，可加快开发过程。 由于通常将 REST 服务基于复杂框架的决定对于某人来说听起来很奇怪，所以让我澄清一下背后的原因： - -* **访问 PHP / Symfony 开发人员**-客户的 IT 团队由 PHP 开发人员组成。 引入新技术（例如 Node.js）将导致需要雇用能够进一步维护系统的新开发人员。 - -* **干净的项目结构**-Symfony2 并不强加完整的项目结构，但具有非常明智的默认结构。 向新开发人员介绍该项目很简单，因为他们对代码很熟悉。 - -* **现成的组件**-遵循 DRY 概念...没有人想要重新发明轮子，所以我们没有。 我们广泛使用 Symfony2 控制台组件，它是一个不错的框架，可用于制作 CLI 命令，用于分析应用程序的工具（调试工具栏），记录器等。 - -在选择使用它之前，我们已经对**进行了性能测试**，以确保它能够处理计划的流量。 我们已经开发了概念证明，并对其进行了 JMeter 的测试。 结果令人印象深刻-700 req / s，响应时间高达 50ms。 它使我们确认，可以将这种复杂的框架用于此类项目。 - -## 应用程序配置文件&监视 - -我们正在使用 Symfony2 工具来监视应用程序。 有一个很好的事件探查器组件，我们可以用来收集特定方法的执行时间，尤其是与第三方网络服务进行通信的方法。 这样，我们可以发现潜在的弱点和应用程序中最耗时的部分。 - -详细日志记录也是必须的。 为此，我们使用了 PHP Monolog 库，该库使我们能够创建格式良好的日志行，开发人员和系统管理员完全可以理解。 必须始终记住要添加尽可能多的细节，我们发现越详细越好。 我们使用不同的日志级别： - -* **调试**-即将发生的事情-例如 在调用外部 Web 服务之前请求信息； 刚刚发生的事情-API 调用的响应 - -* **错误**-出了点问题，但请求流没有停止（例如，来自第三方 API 的错误响应）。 - -* **严重**-糟糕…应用程序刚刚崩溃了：-) - -因此，在生产环境中，您可以看到诸如 Error 之类的痕迹，并且在其下-Critical。 在开发/测试环境中，还记录了调试信息。 - -我们还将**日志分为单独的文件**（在 Monolog 库中，它们称为“通道”）。 有一个主日志文件，其中记录了所有应用程序范围内的错误以及来自特定渠道的简短日志。 我们将通道中的详细日志保存在它们各自的文件中。 - -## 可扩展性 - -扩展应用程序平台层并不困难。 HAProxy 的性能**不会长期耗尽**，我们正在考虑的唯一事情就是使它们冗余以避免 SPoF。 - -因此，当前模式只是添加下一个应用程序节点。 - -# 资料层 - -我们正在使用 Redis 和 MySQL 来存储所有数据。 **MySQL** 主要用作**第三层缓存**层，而 **Redis 是我们的主要数据存储区**。 - -## 雷迪斯 - -在设计系统时，我们正在考虑选择合适的数据库来满足计划的需求： - -* 保留大量数据（约 250,000,000 条记录）时不会失去性能 - -* 通常基于特定资源 ID 的简单 GET（无需查找或复杂的 SELECT） - -* 可以在单个请求中检索大量资源以最小化延迟 - -经过调查，我们决定使用 Redis。 - -* 我们执行的所有操作的复杂度为 O（1）或 O（N），其中 N 是要检索的键的数量。 也就是说，键空间的大小不会影响性能。 - -* 我们主要使用 MGET 命令来一次检索> 100 个键。 与在循环中进行多个 GET 相比，这可以省去网络延迟。 - -当前，我们有两台 Redis 服务器以主从复制模式运行。 它们每个都具有以下配置：Xeon [[受电子邮件保护]](/cdn-cgi/l/email-protection) ，128GB，SSD。 内存限制设置为 100 GB ...并且始终被完全消耗:-) - -![](img/cadc56a7a57d3c98a76004e613d0956d.png) - -由于应用程序并没有穷尽单个 Redis 服务器的性能限制，因此从服务器主要用作备份并保持高可用性。 如果主机崩溃，我们可以轻松地切换应用程序以使用从机。 复制在执行某些维护任务或迁移服务器时也很方便-轻松切换服务器。 - -您可能想知道我们的 Redis 一直处于 maxmemory 极限的情况。 大多数键是持久类型的-大约占键空间的 90％。 但是它们的其余部分是纯缓存，我们为其设置了到期 TTL。 现在，密钥空间分为两部分：一部分已设置 TTL（缓存），第二部分未设置（持久数据）。 由于可以设置“ volatile-lru” maxmemory 策略，因此会不断自动删除使用较少的缓存键（只有它们已过期）。 - -这样，我们就可以**仅保留一个既充当主存储又充当典型缓存**的 Redis 实例。 - -使用此模式时，必须始终记住监视“过期”键的数量： - -db.redis1：6379 >信息键空间 - -＃键空间 - -db0：keys = 16XXXXXXX，expires = 11XXXXXX，avg_ttl = 0 - -当您发现该数字危险地接近零时，请开始分片或增加内存;-) - -我们如何监控它？ 有一个 Icinga 支票，用于监视“到期”数是否达到临界点。 我们还收集了 Redis 图，以可视化“丢失键”的比率。 - -![redis-expires.png](img/8225dac1f9e2514be1c9702b51b1b0cf.png) - -一年后，我可以说我们完全加入了 Redis。 从项目一开始，就没有让我们感到失望-没有任何中断或其他问题。 - -## 的 MySQL - -除了 Redis，我们还使用传统的 MySQL 数据库。 罕见的是，我们通常将其用作第三个缓存层。 我们将最近未使用过的 MySQL 对象存储在其中，而将它们存储在 Redis 中会占用过多的内存，因此我们将它们保存在硬盘上。 这里没有什么花哨的技术，但是我们希望将堆栈保持尽可能简单，以便于维护。 - -我们有 2 台使用 Xeon [[受电子邮件保护]](/cdn-cgi/l/email-protection) ，64GB RAM，SSD 的 MySQL 服务器。 它们上有一个本地的异步主-主复制。 另外，我们保留单个从节点仅用于备份。 - -## MySQL 的高可用性 - -正如您在物理体系结构图上看到的那样，在每个 MySQL 框上，HAProxy 也处于保持状态。 与 MySQL 的连接通过 HAProxy 进行。 - -在每台数据库服务器中安装 HAProxy 的模式导致保持堆栈的高可用性，并且无需为负载平衡器添加添加下一个服务器。 - -HAProxy 以主动-被动模式运行（一次仅使用其中之一）。 对它们的可用性的控制是通过保持机制进行的。 在 keepalived 的控制下有一个浮动 IP（VIP）。 它检查主负载均衡器节点的可用性。 发生故障时，第二个（被动）HAProxy 节点将接管 IP。 - -## Scalability - -数据库始终是应用程序中最难的瓶颈。 目前，不需要任何横向扩展操作-到**为止，我们正在通过将 Redis 和 MySQL 移至更大的框来垂直扩展**。 仍有空间，例如 Redis 在具有 128 GB 内存的服务器上运行-可以将其迁移到 256 GB 的节点上。 当然，这种笨重的盒子在快照或仅运行服务器等操作中也有缺点-启动 Redis 服务器将花费更长的时间。 - -放大（垂直）后，横向扩展。 令人高兴的是，我们已经准备好**易于分片的数据**结构： - -Redis 中有 4 种“大量”记录。 可以根据数据类型在 4 台服务器上分片它们。 我们会避免基于散列进行分区，而倾向于**将数据除以记录类型**。 这样，我们仍然可以运行始终在一种类型的键上执行的 MGET。 - -在 MySQL 中，表是以这种方式进行结构化的，从而可以轻松地将其中的某些表迁移到不同的服务器上-也基于记录类型（表）。 - -在无法进一步按数据类型进行分区之后，我们将进行散列处理：-) - -# 得到教训 - -* **不要共享您的数据库**-一次，一个前端网站希望将其会话处理切换为 Redis。 所以他们已经连接到我们的了。 这导致 Redis 缓存空间用尽，并拒绝了我们的应用程序来保存下一个缓存键。 所有缓存已开始仅存储在 MySQL 服务器上，这导致大量的开销。 - -* **制作详细的日志**-在日志行中没有太多信息，您将无法快速调试问题所在。 在一种情况下，由于缺乏单一信息，我们无法找到导致问题的原因，因此不得不等待其他问题的发生（在添加了丢失数据的日志之后）。 - -* **使用复杂的框架并不会自动意味着“降低网站速度”** -有些人感到惊讶的是，使用全栈框架可以每秒处理如此多的请求。 一切都与智能使用您拥有的工具有关–您甚至可以在 Node.js 中使其运行缓慢：-)选择一种提供良好开发环境的技术，没有人愿意为不友好的工具而烦恼（降低 devops 的士气！）。 - -## 谁在应用程序背后 - -该平台由波兰软件公司 [Octivi](http://octivi.com/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 设计。 我们专注于构建注重高性能和可用性的可扩展架构。 我们还要感谢与 IT 部门在客户端方面的大力合作！ - -# 相关文章 - -* [使用 Symfony2](http://labs.octivi.com/handling-1-billion-requests-a-week-with-symfony2/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 一周处理 10 亿个请求-我们整个应用程序的概述 - -* [将其推向极限-满足高性能需求的 Symfony2](http://symfony.com/blog/push-it-to-the-limits-symfony2-for-high-performance-needs) -描述了具有 Symfony2 功能的软件体系结构的详细信息 - -标题是； - -“使用 HAProxy，PHP，Redis 和 MySQL 构建增长的启动体系结构的简便方法，每周可处理 10 亿个请求” - -在文章中描述了 Varnish 的用法。 我认为标题需要更新。 - -为什么只有一台 Haproxy 服务器？ 您正在为应用程序节点使用 N + 1，但是前面只有一个负载均衡器吗？ 如果此关键服务器出现故障，将会发生什么？ - -那么“平均响应时间-30 毫秒”呢？该统计数据是在清漆前面或没有清漆的情况下计算的？ - -马丁 - -谁能回答这些初学者的问题？ - -1）由于 Redis 都在内存中，所以我假设持久保存数据以防两个 Redis 节点都掉下来是 MySQL 的工作吗？ - -2）如果要使该系统更大，更可扩展，是否会引入消息队列？ - -3）您是否具有到两个 Mysql 实例以及将来的分片 Redis 节点的单独数据库连接池？ - -1\. Redis 可以将数据持久保存到磁盘。 它只是不能增长到大于 memory_size -2。如果它需要在请求之外做一些事情而不是 -3.不知道。 - -在“ MySQL 的高可用性”中，我不明白您为什么使用 HAProxy，仅 Keepalived 可以解决问题（主动-被动和热备用）。 有什么原因吗？ - -Kakwa：HAProxy 允许以下几项： -1\. MySQL 处于主动-主动模式，不仅是主动-被动模式（也可以使用 keepalived 和多个浮动 IP） -2\. HAProxy 之后的 MySQL 服务器权重（服务器不支持） （必须具有相同的硬件） -3.使用“ mysql-check”就可以更轻松地切换到维护模式 - -@Al： -1-Redis 提供可配置的将数据推送到磁盘。 因此，如果 Redis 发生故障，那么它将与 MISS 缓存和 MySQL 的工作相同，是的。 -2-我认为是正确的，甚至他们实际上正在使用消息/作业队列，但在本文中未提及 -3-不知道：) - -伟大的 AI 问题！ - -1）不，Redis 可提供存储数据的完全持久性。 您可以在两种模式下进行设置： -RDB-在配置的时间范围内将整个键空间转储到一个文件中 -AOF-将每个“查询”保存到文件中 -我们正在使用 RDB，但是您可以使用两种模式 与此同时。 - -2）当然！ 在 Canhnm 之后，的确，我们在 Redis 之上建立了一些队列，因为它为此类事情提供了专用的数据结构。 我们将消息传递用于最耗时的任务。 - -3）不 - -嗨，这真的很有趣，谢谢！ 但这只是架构的一部分：提供 JSON 响应的后端服务。 应用程序如何处理该数据并将其提供给最终用户？ 是否有 JS 框架或另一个 PHP 应用程序层？ 谢谢！ - -几乎找不到您所有的图像 404 :( - -您正在使用哪个 PHP 的 Redis 扩展在 PHP 网站中实现 [redis 缓存？ 我知道两个扩展：Predis 和 PHPRedis。 以我的经验，在启用了 varnish 和 memcached 的同一台服务器上，事实证明 Predis 真的很容易配置，并且比 PHPRedis 提供更好的性能。](https://www.cloudways.com/blog/redis-cache-with-custom-php/) \ No newline at end of file +您是否考虑过将 Redis 用于内存中的数据结构？ 听起来很合适。 \ No newline at end of file -- GitLab