.NET技术+25华服务器怎样支撑世界第54大网站

【编者按】StackOverflow是一个IT技术问答网站,用户可于网站及交给和应问题。当下的StackOverflow已怀有400万个用户,4000万单应答,月PV5.6亿,世界排名第54。然而值得关注之是,支撑他们网站的浑服务器就来25高,并且都保持正大低的资源使用率,这是同一庙会大有效性、负载均衡、缓存、数据库、搜索和便捷代码上之竞技。近日,High
Scalability创始人Todd Hoff根据Marco Cecconi的讲演视频“ The architecture
of
StackOverflow”以及Nick
Craver的博文“ What it takes to run Stack
Overflow”总结了StackOverflow的中标原因。


以下也译文

图片 1

料中,也是意料之外,Stack
Overflow仍然重度使用正在微软的出品。他们以为既然微软的根基设备可以满足急需,又足够好,那么没有啊理由去开根本上之改动。而当用的地方,他们相同采用了Linux。究其从来,一切都是为了性。

其余一个值得关注之地方是,Stack
Overflow仍然使用正在纵向扩展策略,没有使用云。他们用了384GB的内存和2TB的SSD来支持SQL
Servers,如果下AWS的口舌,花费可想而知。没有使用云的其他一个原因是Stack
Overflow认为云会一定水平达之暴跌性能,同时为会见让优化以及排查系统问题多难度。此外,他们的架也并不需要横向扩张。峰值期间是横向扩张的杀手级应用场景,然而他们有着丰富的网调动更去报。该商家仍然坚持着Jeff
Atwood的名言——硬件永远比程序员便宜。

Marco
Ceccon曾涉及,在谈及系统不时,有同一桩业务必须首先做明白——需要解决问题的色。首先,从简单点着手,StackExchange究竟是用来做呀的——首先是有主题,然后围这些主题建立社区,最后就形成了这叫人敬佩之问答网站。

辅助则是规模相关。StackExchange在快增长,需要处理大量之数目传,那么这些都是什么样做到的,特别是仅仅使用了25玉服务器,下面一起追根揭底:

状态

 

  • StackExchange拥有110独站点,以每个月份3及4个之快提高。
  • 400万用户
  • 800万问题
  • 4000万答案
  • 世界排名54号
  • 年年增长100%
  • 月PV 5.6亿万
  • 多数工作日中峰值为2600交3000央每秒,作为一个编程相关网站,一般情况下工作日的求都见面高于周末
  • 25雅服务器
  • SSD中蕴藏了2TB的SQL数据
  • 每个web server都配置了2独320G底SSD,使用RAID 1
  • 每个ElasticSearch主机都安排了300GB的教条硬盘,同时也用了SSD
  • Stack Overflow的朗读写于是40:60
  • DB Server的平分CPU利用率是10%
  • 11个web server,使用IIS
  • 2只负载均衡器,1只活泼,使用HAProxy
  • 4独活泼的数据库节点,使用MS SQL
  • 3华实现了tag engine的应用程序服务器,所有寻还经tag
  • 3大服务器通过ElasticSearch做搜索
  • 2宝使用了Redis的服务器支撑分布式缓存和信
  • 2台Networks(Nexus 5596 + Fabric Extenders)
  • 2 Cisco 5525-X ASAs 
  • 2 Cisco 3945 Routers
  • 关键服务Stack Exchange API的2个单纯念SQL Servers
  • VM用于部署、域控制器、监控、运维数据库等场合

 

平台

 

  • ElasticSearch
  • Redis
  • HAProxy
  • MS SQL
  • Opserver
  • TeamCity
  • Jil——Fast .NET JSON Serializer,建立在Sigil之上
  • Dapper——微型的ORM

 

UI

 

  • UI拥有一个信收件箱,用于新徽章获得、用户发送信息、重大事件发生时的音信接收,使用WebSockets实现,并通过Redis支撑。
  • 搜索箱通过 ElasticSearch 实现,使用了一个REST接口。
  • 因为用户提出问题之效率十分高,因此特别为难显最新问题,每秒都见面生新的题材发出,从而这里要开发一个关怀用户作为模式之算法,只吃用户展示感兴趣的题材。它以了基于Tag的纷繁查询,这也是开独立Tag
    Engine的因。
  • 劳动器端模板用于转移页面。

 

服务器

 

  • 25雅服务器并不曾满,CPU使用率并无赛,单计SO(Stack
    Overflow)只待5台服务器。
  • 数据库服务器资源利用率在10%左右,除下实施备份时。
  • 为何会如此小?因为数据库服务器足足有384GB内存,同时web
    server的CPU利用率为止出10%-15%。
  • 纵向扩展还从未遇到瓶颈。通常状态下,如此流量使用横向扩张大约要100届300令服务器。
  • 简而言之的系。基于.Net,只所以了9独品种,其他系统可能得100个。之所以采用这样少系统是为了追求极限的编译速度,这点用从系统开始经常就是展开统筹,每令服务器的编译时间大概是10秒。
  • 11万行代码,对比流量来说非常少。
  • 运这种极简的不二法门要依据几独由。首先,不欲极多测试,因为Meta.stackoverflow本来就是一个题目及bug讨论社区。其次,Meta.stackoverflow还是一个软件之测试网站,如果用户发现题目的话,往往会提出并授予解决方案。
  • 纽约数据中心下的是Windows 2012,已经往2012
    R2升迁(Oregon已经成功了晋级),Linux系统使用的凡Centos 6.4。

 

SSD

 

  • 默认使用的凡Intel 330(Web层等)
  • Intel 520用来中层写副,比如Elastic Search
  • 数据层使用Intel 710跟S3700
  • 系还要利用了RAID 1和RAID 10(任何4+以上的磁盘都应用RAID
    10)。不畏惧故障发生,即使生育条件中使用了上千块2.5英寸SSD,还未曾碰到过千篇一律块砸的景。每个模型都动了1独以上之零配件,多单磁盘发生故障的状况不以考虑中。
  • ElasticSearch在SSD上表现的雅出色,因为SO
    writes/re-indexes的操作非常频繁。
  • SSD改变了寻的使办法。因为钉之问题,Luncene.net并无可知支持SO的出现负载,因此他们转向了ElasticSearch。在全SSD环境下,并不需要围绕Binary
    Reader建立锁。

 

高可用性

 

  • 异地备份——主数据中心位于纽约,备份数据基本以Oregon。
  • Redis有点儿个自节点,SQL有2单备份,Tag
    Engine有3单节点,elastic有3只节点,冗余一切,并当少数独数据核心又在。
  • Nginx是用于SSL,终止SSL时换使用HAProxy。
  • 并无是核心所有,一些即之数据就会放缓存中
  • 拥有HTTP流量发送只占总流量的77%,还留存Oregon数据核心的备份及一些外的VPN流量。这些流量主要由于SQL和Redis备份产生。

 

数据库

 

  • MS SQL Server
  • Stack Exchange为每个网站都装了数据库,因此Stack
    Overflow有一个、Server Fault有一个,以此类推。
  • 当纽约的预兆数据核心,每个集群通常都运1主和1一味念备份的部署,同时还见面当Oregon数核心也装一个备份。如果是运行的凡Oregon集群,那么零星只在纽约多少主导的备份都见面是就念与联合的。
  • 否另外情节准备的数据库。这里还留存一个“网络范围”的数据库,用于储存登陆凭证和集合数据(大部分凡stackexchange.com用户文件要API)。
  • Careers Stack Overflow、stackexchange.com和Area
    51当都装有好单身的数据库模式。
  • 模式之成形得以提供给有站点的数据库,它们需向下兼容,举个例子,如果急需再行命名一个列,那么将格外麻烦,这里需要进行多单操作:增加一个新列,添加作用于个别只列上之代码,给新列写多少,改变代码让新列有效,移除旧列。
  • 并不需要分片,所有工作经过索引来化解,而且数量体积也未曾那么大。如果发filtered
    indexes需求,那么为什么非重复高效的拓展?常见模式只于DeletionDate =
    Null上做索引,其他则通过为枚举指定项目。每项votes都安装了1单说明,比如同摆放表给post
    votes,1张表给comment
    votes。大部分之页面都可实时渲染,只也匿名用户缓存,因此,不有缓存更新,只有重新查询。
  • Scores是勿规范化的,因此要常查询。它仅含有IDs和dates,post
    votes表格当下盖发生56454478行,使用索引,大部分之查询都足以在数毫秒内就。
  • Tag
    Engine是一点一滴独立的,这就意味着基本作用并无依靠任何外部应用程序。它是一个伟大的内存结构数组结构,专为SO用例优化,并也重负载组合展开事先计算。Tag
    Engine是单简单的windows服务,冗余的运行在多独主机上。CPU使用率基本上保持以2-5%,3个主机专门用于冗余,不负责任何负载。如果拥有主机同时产生故障,网络服务器将把Tag
    Engine加载到内存中持续运作。
  • 关于Dapper无编译器校验查询及民俗ORM的相比。使用编译器有广大补,但每当运作时依旧会存在fundamental
    disconnect问题。同时再次着重的凡,由于生成nasty
    SQL,通常状态尚用去摸索原始代码,而Query
    Hint和parameterization控制相当能力的缺失更叫查询优化转移得复杂。

 

编码

 

  • 流程

 

 

  • 大部分程序员都是远程工作,自己挑选编码地点
  • 编译非常急匆匆
  • 然后运行少量的测试
  • 苟编译成功,代码即转移到支付交付准备服务器
  • 经功能开关隐藏新力量
  • 以平硬件及作任何站点测试运行
  • 下一场换到Meta.stackoverflow测试,每天产生上千只程序员在使用,一个格外好的测试环境
  • 如若通过则达到线,在再度宽泛的社区开展测试

 

 

  • 大方行使静态类和措施,为了还简约与重新好之特性
  • 编码过程非常简单,因为复杂的有些让由包及库里,这些库被开源和保护。.Net
    项目数目特别没有,因为运用了社区共享的片代码。
  • 开发者同时使用2至3单显示器,多单屏幕可一目了然加强生产效率。

 

缓存

 

  • 缓存一切
  • 5个阶段的缓存
  • 1级是网络级缓存,缓存在浏览器、CDN以及代理服务器中。
  • 2级由.Net框架 HttpRuntime.Cache完成,在各级令服务器的内存中。
  • 3级Redis,分布式内存键值存储,在多独支持与一个站点的服务器上同台享缓存项。
  • 4级SQL Server Cache,整个数据库,所有数据还吃撂内存中。
  • 5层SSD。通常只有于SQL Server预热后才生效。
  • 选举个例证,每个援页面还进行了缓存,访问一个页面的代码非常简单:

 

 

  • 采用了静态的道以及相近。从OOP角度来拘禁真蛮糟糕,但是充分急匆匆并有利于简洁编码。
  • 缓存由Redis和Dapper支撑,一个袖珍ORM

 

 

  • 为化解废物收集问题,模板被1单近乎就使用1单副本,被立与封存于缓存中。监测整个,包括GC操。据统计显示,间接层增加GC压力达到了某程度时会见明白的大跌性能。
  • CDN Hit
    。鉴于查询字符串基于文件内容进行哈希,只于来新立时才见面让还取出。每天3000万及5000万Hit,带富约为300GB到600GB。
  • CDN不是用来应针对CPU或I/O负载,而是帮用户还快之获取答案

 

部署

 

  • 每日5次配置,不失立了好之利用。主要因

 

 

  • 得一直的监性能
  • 尽心尽力最小化建立,可以干活才是必不可缺

 

 

  • 出品建立后再行经有力的本子拷贝到各个网页层,每个服务器的步骤是:

 

 

  • 透过POST通知HAProxy下架某台服务器
  • 延迟IIS终结现有请求(大约5秒)
  • 止网站(通过与一个PSSession结束所有下游)
  • Robocopy文件
  • 敞开网站
  • 透过外一个POST做HAProxy Re-enable

 

 

  • 几所有配置都是经过puppet或DSC,升级通常仅是巨大调整RAID阵列并经PXE
    boot安装,这样做很高效。

 

协作

 

  • 团队

 

 

  • SRE (System Reliability Engineering):5人
  • Core Dev(Q&A site)6-7人
  • Core Dev Mobile:6人
  • Careers团队专程负责SO Careers产品开发:7人口

 

 

  • Devops和开发者结合的深严谨
  • 团队内部变化很大
  • 大多数员工远程工作
  • 办公要用以销售,Denver和London除外
  • 任何同样,些许偏于纽约工作者,因为面对面有助于工作交流,但是在线工作影响为并无死
  • 相比可以以跟一个办公办公,他们再偏于心爱产品跟生才气的工程师,他们好死好的权利弊
  • 多丁因为家庭设挑选远程工作,纽约凡科学,但是生并无宽
  • 办公室举办于曼哈顿,那是单人才的家乡。数据主导未能够顶偏,因为时会面波及升级
  • 制作一个强大团队,偏爱极客。早期的微软即汇了大气极客,因此他们征服了合社会风气
  • Stack
    Overflow社区也是单招聘的地方,他们于那么找热爱编码、乐于助人及爱交流之红颜。

 

编写预算

 

  • 预算是种的基本功。钱只有费在也新路起基础设备达到,如此低利用率的 web
    server还是3年前数基本建立时请。

 

测试

 

  • 飞迭代和丢掉
  • 众测试都是揭示队伍完成的。开发有一个等同的SQL服务器,并且运行在相同的Web层,因此性能测试并无会见坏。
  • 怪少的测试。Stack
    Overflow并无进展极端多之单元测试,因为她们下了汪洋底静态代码,还有一个生活跃的社区。
  • 基础设备改变。鉴于有东西都起双份,所以每个旧布都有备份,并使用了一个飞速故障恢复机制。比如,keepalived可以当负载均衡器中很快回退。
  • 相对而言定期维护,他们更愿意乘冗余系统。SQL备份用一个专门的服务器进行测试,只以好再次存储。计划举行每半独月同糟糕的全都数据核心故障恢复,或者采取完全就读之次多少主导。
  • 老是新成效发布还举行单元测试、集成测试盒UI测试,这就是象征可以预知输入的制品效果测试后便见面推送至孵化网站,即meta.stackexchange(原meta.stackoverflow)。

 

监视/日志

 

  • 就着考虑采取http://logstash.net/做日志管理,目前使用了一个专门的服务将syslog
    UDP传输到SQL数据库中。网页遭到也计时添加header,这样尽管可由此HAProxy来捕获并且融合到syslog传输中。
  • Opserver和Realog用于展示测量结果。Realog是一个日志展示系统,由Kyle
    Brandt和Matt Jibson使用Go建立。
  • 日志通过HAProxy负载均衡器借助syslog完成,而非是IIS,因为那个功能比IIS更增长。

 

关于云

 

  • 或者老生常谈,硬件永远比开发者和有效率的代码便宜。基于木桶效应,速度自然受限于某短板,现有的讲服务多还设有容量与总体性限制。
  • 若果打开就采用云来建设SO说不定也会落得现在之品位。但毫无疑问的是,如果上同等的性质,使用云的老本将远超出自建数据核心。

 

性最佳

 

  • StackOverflow是只重度之属性控,主页加载的岁月永远控制以50毫秒内,当下之应时间是28毫秒。
  • 程序员热衷让降低页面加载时间以及加强用户体验。
  • 每个独立的网交都给计时与著录,这种计算可以做明白提升性能需要改的地方。
  • 这样低资源利用率的要因纵然是快速的代码。web
    server的CPU平均利用率在5%暨15%里面,内存以与否15.5 GB,网络传输在20
    Mb/s到40
    Mb/s。SQL服务器的CPU使用率在5%交10%期间,内存以是365GB,网络传输也100
    Mb/s到200
    Mb/s。这得带来3只便宜:给升迁留下十分老的空中;在严重错误发生常方可保障服务可用;在用经常可以快回档。

 

效仿到的学识

1. 何以使用MS产品的同时还利用Redis?什么好用用什么,不要开无必要之网的如何,比如C#每当Windows机器上运行最好,我们使用IIS;Redis在*nix机器上得获充分发挥,我们利用*nix。

2. Overkill即策略。平常的利用率并无可知表示什么,当某些特定的工作发时,比如备份、重建等统统可用资源使用拉满。

3. 稳步的SSD。所有数据库都成立以SSD之上,这样可以获取0延时。

4. 了解你的读写负载。

5. 快快的代码意味着又少之主机。只有新类型上线时才会盖特殊需要增加硬件,通常状态下是加上内存,但以斯之外,高效之代码就意味着0硬件添加。所以常只有谈谈两单问题:为存储增加新的SSD;为新路多硬件。

6. 决不怕定制化。SO在Tag上行使复杂查询,因此特意开发了所要的Tag
Engine。

7. 只做得做的事情。之所以未需测试是因起一个活跃的社区支撑,比如,开发者不用操心出现“Square
Wheel”效应,如果开发者可以打一个重新重轻量级的零部件,那就算代替吧。

8. 尊重硬件知识,比如IL。一些代码用IL而不是C#。聚焦SQL查询计划。使用web
server的内存转储究竟开了几什么。探索,比如为什么一个split会产生2GB的杂质。

9. 切勿官僚作风。总起一对新的家伙是公用的,比如,一个编辑器,新本子的Visual
Studio,降低提升过程被之总体绊脚石。

10. 垃圾堆回收驱动编程。SO在调减污染源回收资金上召开了好多开足马力,跳了类似TDD的行,避免抽象层,使用静态方法。虽然尽,但是的确于往出异常快捷的代码。

11. 速代码的价远远出乎你想象,它可为硬件跑的再快,降低资源使用,切记让代码更便于让程序员理解。

原文链接: StackOverflow Update: 560M Pageviews A Month, 25 Servers,
And It’s All About
Performance(编译/仲浩
审校/魏伟)

正文也CSDN编译整理,未经允许不得转载,如需要转载请联系market#csdn.net(#换成@)

相关文章