Stack Overflow 全站架构透视(软件＋硬件清单)

stackoverflow架构解析，其架构既有商业外包服务，也大量采用开源软件，可以全景式展现当代主流架构的风貌。

stackoverflow由jeffatwood和joelspolsky这两个非常著名的blogger在2008年创建。

asofapril2014,stackoverflowhasover4,000,000registeredusers[19]andmorethan10,000,000questions,[20]with10,000,000questionscelebrated[21]inlateaugust2015.basedonthetypeoftagsassignedtoquestions,thetopeightmostdiscussedtopicsonthesiteare:java,javascript,c#,php,android,jquery,pythonandhtml。——wiki

第一篇：总体架构

第二篇：硬件清单

第三篇：部署流程(翻译中)

总体架构stackoverflow可以分解为八个切面：互联网、负载均衡、web层、服务层、缓存、推送、搜索、数据库。

firstrule:everythingisredundant两个数据中心：纽约和科罗拉多，冗余且持续备份。其它所有关键组件都尽可能贯彻冗余原则。

全景视图

物理架构

4台microsoftsqlserver服务器（其中2台使用了新的硬件）

11台iisweb服务器（新的硬件）

2台redis服务器（新的硬件）

3台标签引擎服务器（其中2台使用了新的硬件）

3台elasticsearch服务器（同上）

4台haproxy负载均衡服务器（添加了2台，用于支持cloudflare）

2台网络设备（nexus5596核心+2232tmfabricextender，升级到10gbps带宽）

2台fortinet800c防火墙（取代了cisco5525-xasas）

2台ciscoasr-1001路由器（取代了cisco3945路由器）

2台ciscoasr-1001-x路由器

逻辑架构

逻辑架构theinternets互联网dns服务：外包cloudflare+自建dns其实外包dns服务应该已经可以满足服务，不过出于保险起见，还是有一套自建的dnsserver。

看来trustissues中外一致啊。

loadbalancers负载均衡haproxy1.5.15oncentos7支持tls(ssl)流量。关注haproxy1.7,它即将支持http/2。

引入开源架构之后，就必须持续关注、跟进社区的发展动态。

吃着碗里的，看着锅里的，永远不能停。

webtierweb层iis8.5,asp.netmvc5.2.3,and.net4.6.1servicetier服务层iis,asp.netmvc5.2.3,.net4.6.1,andhttp.syscache缓存redisl1级别：http缓存

l2级别：l1级别缓存失败之后，通过redis获取数据

l1&l2都是无法命中的情况下，会从数据库查询，并更新到缓存和redis。

缓存更新：基于发布／订阅模型，利用这个机制来清除其他服务上的l1缓存，用来保持web服务器上的缓存一致性。另外redis实例的cpu都很低，不到2%，这点很惊人。

push推送开源库：netgrain使用websocket向用户推送实时的更新内容，比如顶部栏中的通知、投票数、新导航数、新的答案和评论。在高峰时刻，大约有50万个并发的websocket连接，这可是一大堆浏览器。

一个有趣的事实：其中一些浏览器已经打开超过18个月了。someoneshouldgocheckifthosedevelopersarestillalive！！

问题：临时端口、负载均衡上的文件句柄耗尽，都是非常有趣的问题，我们稍后会提到它们。

search搜索elasticsearch集群，每个es集群都有3个node什么不用solr？我们需要在整个网络中进行搜索（同时有多个索引），在我们进行决策的时候solr还不支持这种场景。

还没有使用2.x版本的原因，是因为2.x版本中类型（types）有了很大的变化，这意味着想要升级的话我们得重新索引所有内容。

没有足够的时间来制定需求变更和迁移的计划。

database数据库sqlserverourusageofsqlisprettysimple.simpleisfast.

数据库中只有一个存储过程，而且我打算把这个最后残留的存储过程也干掉，换成代码。

监控系统opserver：轻量级监控系统，基于asp.netmvc框架，可监控：servers

sqlclusters/instances

redis

elasticsearch

exceptionlogs

haproxy

数据库cpuverylow

这是关于stackoverflow架构的一系列文章中的第二篇。前一篇：《stackoverflow:架构》（2016版）后一篇：《stackoverflow:我们是如何做部署的》（2016版）

有人对硬件感兴趣吗？好吧，我感兴趣，这篇博客就是关于这个话题，所以，我赢了。如果你不关系硬件，那么可以走开并关闭浏览器了。还在这儿吗？真棒。假如你的网页访问非常非常慢，在这种情况下，你应该考虑采购一些新的硬件。

我曾今反复重申过多次：性能是一个重要组件。特别是当你的代码必须在最快的硬件上运行，硬件的关系则越为重大。正如任何其它的平台，stackoverflow的架构是分层的。硬件对我们来说属于基础层，它有自己的屋子，在很多情况下，对我们来说，它的许多关键组件是不可控的。。。就像运行在别人的服务器。它也伴随着直接和间接的成本。但是，这些不是本篇文章的重点，这方面的对比将于稍后报告。目前来说，我希望能提供一份详细的，关于我们基础设施的清单，用于大家参考和比较。

服务器照片。有时是裸设备。这个网页可以加载得更快，但是我不能自禁。（言归正传）在这个系列报告中我将提供大量数字和规格说明。当我说“我们的sqlservercpu利用率接近5-10%，”好吧，这非常棒。但是，5-10%的什么？这时我们需要一个参考值。这份硬件清单可以回答这些问题，并且座位与其它平台比较的依据，利用率对比如何，容量对比如何，等等。

免责声明：我不是一个人干的。

georgebeech(@gabeech)是我的主要搭档，盘点管控stack使用的硬件。我们小心地规范每一台服务器，以使它符合设计意图。我们不会只管下订单、分派任务。在这个过程中我们也不会自己单独完成；你必须知道将来这些硬件需要运行什么东西，才能做出合适的选择。我们将和开发工程师或者其他的可靠性工程师一道，为运行在盒子上的应用选择最佳方案。我们也关注在整个系统中什么才是最好的。每一台服务器都不是孤岛。如何将它嵌入到总体的架构中去，确实需要好好考量。哪些服务可以全平台共享？数据中心？日志系统？管理更少的事情，或者至少做到更少的差异，这件事本身就具有内在的价值。

当我们盘点硬件的时候，我们列出了很多规则来帮助我们厘清哪些是需要提供的。我还从没有真正写下这些心里面的检查表，简短来说：

这是一个升级或降级的问题吗？（我们购买一个更大的机器，或者一些更小的？

我们需要／希望做到什么程度的冗余?(多少预留空间和故障恢复能力?)

存储:

服务器／应用需要挂在磁盘吗？(我们是否需要spinny操作系统驱动?)

如果是，需要多少？（多大的网络带宽？有多少小文件？是否需要固态硬盘？）

如果是ssd（固态硬盘），是否写负载？（我们讨论intels3500/3700s?p360x?p3700s?)

我们需要多少ssd容量?(是否可以采用同时搭载hdd（机械硬盘）的双轮方案?)

数据是否需要完全缓存？（相比没有电容器的ssd，哪一种更便宜，哪种更合适？）

将来存储是否需要扩展?(我们采用1u/10-bay服务器,或者一个2u/26-bay服务器?)

这是一个数据仓库的场景设定吗？（我们是否考虑3.5’’驱动器？如果是，每个2u主板上是12个还是16个驱动器？）

对于3.5’’的后板来说，存储平衡在在处理器上是否能达到120wtdp的限制?

我们是否需要直接显示磁盘？（控制器是否需要支持pass-through?)

内存:

它需要多少内存？（我们必须买什么？）

它将会使用多少内存？（我们最好买什么？）

我们是否认为它稍后需要更多的内存？（我们应该搭配那种内存频率？）

它是一个内存消耗型应用程序吗？（我们是否想要达到最大主频？）

它是一个高并发的应用程序吗？（一定空间的情况下，我们是否想要通过更多的dimm来分摊内存？）

cpu:

我们希望采用哪种类型的处理器？（我们需要cpu自己供电还是独立电源？）

它是高并发的应用程序吗？（我们希望采用更少、更快的内核？或者，采用数量更多，更慢的内核？）

以下哪种情况？是否存在大量的二级和三级缓存竞争？（为了提高性能，我们是否需要一个巨大的三级缓存？）

应用瓶颈主要是单一内核吗？（我们是否采用最大主频？）

如果是这样的话，同时需要支持多少进程数？（这里我们希望采用哪种引擎？）

网络:

我们是否需要增加10gb网络连接？（此处是否为透传设备，例如一个负载均衡器？）

我们需要怎样的出／入流量均衡策略？（哪个cpu内核负责计算均衡权重？）

冗余:

我们在数据缓存中心是否也需要服务器？

我们是否需要在同等数量的情况下，接受更低的冗余要求？

我们是否需要一个电源线？不。我们不需要。

现在，让我们来看看服务网站的都有哪些硬件，它们位于纽约（newyork）qts数据中心。实际上，它位于新泽西（newjersey)，但是让我们保持这个约定。为什么我们称之为ny数据中心？因为我们不想重命名所有以ny-开头的服务器。（what?!…）我将记录在下面的清单上，丹佛的情况，在规格和冗余级别上略有差别。

hidepictures(incaseyou’reusingthisasahardwarereferencelistlater)

全局选项先说明一些全局配置，在下面每台服务器的介绍里就不重复了：

网络

原作者备注:每个fex到核心拥有80gbps上联带宽，核心通过一个160gbps端口通道与它们连接。由于最近的一些工程，我们位于丹佛数据中心的硬件会更新一些。所有4台路由器的型号是asr-1001-x和双核cisconexus56128p,每个都拥有96sfp+10gbps端口和8qsfp+40gbps端口。这些节省下来的端口，可以用于未来扩展，我们可以为核心绑定4x40gbps链接，替代每个16x10gbps端口的方案，正如我们在纽约做的那样。这些就是纽约的网络设备情况:

这里需要提到的是markhenderson,我们网站的可靠性工程师之一，专程到纽约数据中心为我的这份报告拿到了一些高分辨率的照片。

sqlservers(stackoverflow集群)

web服务器

应用服务器(workers)

原作者备注:ny-service03目前仍然是一台r620,但是现在并没有足够老到以至于需要更换。它会在今年晚些时候升级。

redis服务器(缓存)

elasticsearch服务器(检索)

haproxy服务器(负载均衡器)

原作者备注:这些服务器是不同时期采购的，因此规格上略有差异。并且，2台cloudflare负载均衡器因为安装了memcached,拥有更多内存（我们现在已经不运行该组件）。这些服务，redis,检索,和负载均衡器在stack都是基于1u服务器。这是纽约的情况：

我们还有一些其他的服务器并不直接或间接服务于网站的流量。它们负责处理一些相关业务（例如，域名控制器，少量用于应用验证，跑在虚拟机上），或者一些次要的采购用于监控，日志存储，备份等等。既然已经表示未来会做一系列的报告，我把一切有趣的“后台”服务器也列出来。使我可以将更多的服务器拿出来和你分享，有人不喜欢的吗？

vm服务器(vmware,当前)

在一些场景下，还有几台重要的服务器不是虚拟机。这些系统后台任务，帮助我们通过日志追踪排查问题，存储大量的数据等等。

机器学习服务器(providence)这些服务器99%的时间是空闲的，但是每晚承担了大量的处理工作：刷新providence。它们也可以通过内部数据中心的方式，用来测试基于海量数据的新算法。

译者注：providence，应为项目代号。providence通过分析流量日志，给网站的访问用户打标签(类似“web开发者”或者“使用java技术栈”)。详细可以查阅[https://kevinmontrose.com/2015/01/27/providence-machine-learning-at-stack-exchange/]

机器学习服务器－redis(stillprovidence)这是一个为providence服务的redis数据集。它们通常是一台主用，一台备用，还有一个实例是用于测试，如最新版的ml算法。当它不用做q&a站点时，这些数据会服务于职位招聘的边栏广告。

日志服务器(各种日志）我们的logstash集群(使用elasticsearch存储)，数据来源于，任何地方。我们曾计划将http日志复制一份到这些服务器，但是由于影响性能的问题而没有实现。尽管如此，我们还是将所有的网络设备日志，syslog，windows和linux系统日志存在这里，所以我们能够建立建立一个网络的全局视图，或者快速地排查问题。当告警发生的时候，它也被用作bosun的一个数据源。这个集群总计使用的存储是6x12x4=288tb。

**sqlserver－http日志**在这些服务器，我们将访问负载均衡器的单独http请求，存储到sql数据库(来源于haproxysyslog）。我们只记录少数高级别的请求，类似url，查询，useragent,sql执行时间，redis，等等。在这里的数据，每天将进入一个集群的columnstore索引。我们借助这些数据排查用户的问题，发现僵尸网络，等等。

**sqlserver-开发**我们喜欢尽可能多地模拟生产环境，类似sql匹配，额，至少是它过去常常发生的那样。们一直以来这购买升级生产处理器。我们会将升级这些服务器，采用2u解决方案，在今年晚些升级stackoverflow集群的时候一起做。

这些就是实际服务我们网站的硬件，或者说大家普遍感兴趣的部分。我们当然还有其它服务器，用于后台任务，例如日志记录，监控，备份，等等。如果你对于我们其它系统还有特别感兴趣的地方，请尽管留言提问，我很高兴回答。

这是一周多以前在纽约的全程：

接下来？我做的这一系列工作是希望能让社区了解到最多情况。通过trelloboard,它让部署看起来像是下一个最有趣的话题。预计下一次将让大家了解代码是如何从开发者的机器到生产环境，以及这个过程中解决的所有问题。它将覆盖数据库迁移，滚动构建，ci组件，我们如何建立开发环境，所有要素如何共享信息等。