• 架构设计:解密Stack Overflow 2016最新网站架构设计
  • 浪牛三刀 发表于 2016/3/2 18:37:00 | 分类标签: 架构设计 高性能 网站架构
  • 首先给出一个直观的数据,让大家有个初步的印象。 

    相比于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月升级的)的实物图片展示。
    现在来给出主要系统的逻辑架构图,如图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
    更直观的看下对应的web服务器的图形展示,见图4
    服务层(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%之下。
    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界最受欢迎的问答网站之,这是非常不错的。其中每项使用到的技术都进行了深入的研究并开源分享给社区,国内的公司可以从中获得一些启发。
  • 请您注意

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:浪牛三刀
  • 加入时间:2013/7/12 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 以下内容也很赞哦
分享按钮