轉：StackOverflow2016最新架构探秘

轉載：http://www.infoq.com/cn/news/2016/03/Stack-Overflow-architecture-insi?utm_source=tuicool&utm_medium=referral

首先给出一个直观的数据,让大家有个初步的印象。 相比于2013年11月,Stack Overflow在2016年02月统计数据有较大变化,下面给出2016年02月09号一天的数据,如下:

• HTTP请求数209,420,973 (+61,336,090)

• 网页加载次数 66,294,789 (+30,199,477)

• HTTP流量发送有1,240,266,346,053 (+406,273,363,426)字节 (1.24 TB)

• 接收数据总量569,449,470,023 (+282,874,825,991) 字节(569 GB)

• 发送数据总量3,084,303,599,266 (+1,958,311,041,954) 字节 (3.08 TB)

• SQL查询数(HTTP请求)504,816,843 (+170,244,740)

• Redis命中数5,831,683,114 (+5,418,818,063)

• Elastic 查询次数17,158,874 (未计入2013年的数据)

• 标签引擎请求次数3,661,134 (+57,716)

• SQL查询耗时607,073,066 (+48,848,481) 毫秒 (168小时)

• Redis命中耗时10,396,073 (-88,950,843) 毫秒 (2.8 小时)

你很难想象到.NET技术架构能够在每天6100万请求的情况下减少757小时的处理时间(相比于2013年)。这些改善既得益于2015年早期的硬件设备升级,也跟软件的性能优化有极大的关系。

那么最近两年在硬件上有什么变化呢?以下为截止到目前为止的硬件列表:

• 4台数据库服务器(微软SQL Server),其中两台更新硬件配置

• 11台Web服务器(IIS),都已更新硬件配置

• 2台分布式缓存和消息处理服务器(Redis),都已更新硬件配置

• 3台应用服务器(实现了tag引擎功能),其中两台为新硬件配置

• 3台搜索服务器(ElasticSearch),配置同2013年

• 4台负载均衡服务器(HAProxy),其中新增加的两台用于支持CloudFlare的CDN加速服务

• 2台网络交换机(每个都是Cisco Nexus 5596 + Fabric Extenders,并升级网卡10Gbps)2台Fortinet 800C(替代2台Cisco 5525-X ASA防火墙)

• 2台Ciso ASR-1001路由器(替代2台Cisco 3945路由器)

• 2台Ciso ASR-1001-x路由器

为了支撑Stack Overflow运行,那需要做点什么呢?其实跟2013年相比并没有什么显著变化,只是做了前面提到的硬件升级和程序的性能优化。 
现有系统一般都不会完全隔离开来,Stack Overflow也不列外。一图胜千言,下面给出Stack Overflow的整体架构效果图。本篇文章仅给出硬件整理的逻辑架构的亮点,具体的硬件细节部分将在下一篇文章详细介绍。 
图1是机架A(在2015年2月升级的)的实物图片展示。

图1 现在来给出主要系统的逻辑架构图,如图2。

图2

基本规则

首先给出全局的通用规则:

• 万事需要备份

• 所有服务器和网络交换机要至少2 x 10Gbps带宽

• 所有服务器配备两个电源(带有UPS电源备用)

• 所有服务器在机架A和B上互为冗余

• 所有服务器和服务都有异地双活(纽约机房和科罗拉多州机房)

网络服务

首先,用户去Stack Overflow网站浏览就要通过Internet。为了让用户浏览网站的速度更快Stack Overflow采用CloudFlare的CDN加速。这里使用CloudFlare服务是因为它们的CDN服务器遍布全球。 
紧接着,用户的HTTP流量通过四大ISP提供商(Level 3,Zayo,Cogent和Lighttower),经过四台路由器。Stack Overflow通过标准的边界网关协议(BGP)来均衡所有的流量以便用户更有效率的打开网站。Stack Overflow的工程师Nick Craver建议在两个异地数据中心采用一个10 Gbps MPLS,这样在出现突发情况下可以快速的恢复和复制数据。

负载均衡(HAProxy)

负载均衡使用的HAProxy 1.5.15和CentOS 7,并在HAProxy加入安全传输层协议(TLS/SSL)。后续会升级HAProxy到1.6版本来支持HTTP/2。

负载均衡器配备2对10Gbps网络。Stack Overflow通过加内存来有效的解决安全套接层(SSL)问题。缓存安全传输层协议(TLS)会话到内存加以重复使用,这样可以减少对于同一台客户端连接的重复计算,到达提升会话的速度和成本。况且RAM相当便宜,实现了双赢的效果。

负载均衡器的设置是相当的简单。它们监听各路IPs,并进行路由分发。Stack Overflow还做了负载均衡限流和监控HAProxy的日志做到及时报警。

Web层架构(IIS 8.5,ASP.Net MVC 5.2.3,和.Net 4.6.1)

Stack Overflow经过负载均衡层导入流量到9台Web服务器(“primary”服务器),另外两台做网站元数据等环境管理。除meta.stackoverflow.com和meta.stackexchange.com外,Stack Overflow、Careers和Stack Exchange网站业务都在“primary”服务器运行。

在监控平台Opserver上可以看到,Stack Overflow在Web层的分布,见图3

服务层(IIS,ASP.Net MVC 5.2.3, Net 4.6.1和HTTP.SYS)

在整体逻辑架构图上可以清晰的看到,紧挨着Web层的是服务层(部署在Window服务器Windows 2012R2上)。其有两个重要的功能:tag应用服务器(基于http.sys)和API(基于IIS)。为了提升这两个服务做了非常多的冗余,但不超过9倍的冗余。举个列子,从数据库加载所有的网页和对应的tags变化(每n分钟(当前设置为2分钟))是非常耗时的。这里只需要加载三次即可保证安全。Stack Overflow也同时在硬件层做了相关的优化。Tag应用服务是一个比较复杂的topic,这里简单说下,当你访问/questions/tagged/java就使用tag应用服务。还有所有/search和导航也都是用的这些数据服务。

缓存&发布/订阅(Redis)

Stack Overflow在缓存层用Redis,Redis服务器256GB内存,采用master/slave结构部署,尽管每个月16000万的ops,每个实例的CPU使用率也在2%之下。

图5

Redis所在服务器有L1/L2高速缓存,Web服务的HTTP缓存设置在一级缓存L1中,Redis缓存在二级缓存L2。当用户访问在一级缓存L1中未命中后会去二级缓存中的Redis取值,这些值以Protobuf格式存储,并以protobuf-dot-net解析。Redis客户使用的StackExchange.Redis(Stack Overflow内部实现并开源了)。如果web服务在L1和L2两级缓存都未命中,则会直接去原始数据源获取(比如,数据库查询,API回调等),然后并把获取到的结果缓存到本地和Redis中,这时其它服务未命中L1高速缓存便会去二级缓存L2/Redis中获取,节省了调用数据库查询或者API回调的访问时间。

大部分运行的问答网站都有自己的L1/L2高速缓存,通过L1缓存Key前缀、L2/Redis缓存数据库ID。

尽管Redis主要是用来缓存,但也起到一个消费和订阅的功能,Redis可以推送一个消息,然后其他订阅者来订阅消息(包括下游的Redis从库在订阅消息)。

Websockets (NetGain)

Websockets实时的推送消息(比如,顶栏的通知,投票,新的答案和评论)给用户。 
Sockets服务器运行在web层,NetGain是Stack Overflow实现的一个轻量级高性能实时的开源消息中间件。高峰期可达到50万并发的websocket连接。 
下图展示的是一周websocket并发情况:

Search (Elasticsearch)

Stack Overflow的工程师Nick Craver表示搜索层并没有激动人心的部分。在web层采用Elasticsearch 1.4,并内部实现了高性能的StackExchange.Elastic客户端,此部分代码未开源。Stack Overflow使用Elastic来查询相关的问答。

每个数据中心都有一个Elasticsearch集群,包含三个节点,每个都建有自己的索引。三个Elasticsearch集群全部使用SSD存储,192GB内存和双10Gbps网卡。

Stack Overflow使用Elasticsearch代替先前的SQL全排索引,主要因素是:Elasticsearch的扩展性和低成本。

数据库(SQL Server)

SQL Server是Stack Overflow唯一的源数据库,所有Elastic和Redis的数据都来自SQL Server。使用微软的SQL Server监控组件AlwaysOn Availability Groups部署了两个SQL Server集群。每个集群有一个主库,一个数据备份在纽约,另一个数据备份在Colorrado数据中心。所有备份是异步复制。 
第一个集群硬件配置:Dell R720xd服务器,384G内存,4TB SSD存储,双12核CPU;第二个集群硬件配置:Dell R730xd服务器,768G内存,4TB SSD存储,双8核CPU。 
所有数据库过去24小时CPU监控图如图7所示,大部分情况CPU使用率较低,偶尔做下缓存任务时会高些。图中NY-SQL02和04是主库,01和03是备份库。

纵观全文,Stack Overflow整体架构并没有采用那些非常高端的技术,却造就了一个IT界最受欢迎的问答网站之,这是非常不错的。其中每项使用到的技术都进行了深入的研究并开源分享给社区,国内的公司可以从中获得一些启发。