问答社区网络 StackExchange 由 100 多个网站组成，个中包罗了 Alexa 排名第 54 的 StackOverflow。StackExchang 有 400 万用户，每月 5.6 亿 PV，但只用 25 台处事器，而且 CPU 负荷并不高。
它没有利用云计较，因为云计较大概会拖慢速度，更难优化和更难明除系统妨碍。
StackOverflow 仍然利用微软的架构，它很是实际，微软的基本设施能有效事情，又足够便宜，没有令人信服的来由需要做出改变。但这并不暗示它不利用 Linux，它将 Linux 用在有意义的处所。
它的 Windows 处事器运行的操纵系统版本是 Windows 2012 R2，Linux 处事器运行 Centos 6.4。
网站数据库 MS SQL 巨细 2TB，全都储存在 SSD 上，它有 11 台运行 IIS 的 Web 处事器，2 台运行 HAProxy 的负载平衡处事器，2 台运行 Redis 的缓存处事器。
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 的乐成原因。
料想之中，也是料想之外，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 台处事器。