意料之中，也是意料之外，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 万答案

世界排名 50 位

每年增长 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 控制等能力的缺乏更让查询优化变得复杂。

      润壤网络润壤上篇就总结到此，下篇将详细讲述编码、部署、协助、测试等环节，敬请期待！