标签：always 分代 分布 问题 一级缓存 快速 数据库服务 level fabric
这篇文章主要揭秘 Stack Overflow 截止到 2016 年的技术架构。
首先给出一个直观的数据，让大家有个初步的印象。
相比于 2013 年 11 月，Stack Overflow 在 2016 年 02 月统计数据有较大变化，下面给出 2016 年 02 月 09 号一天的数据，如下：
你很难想象到 .NET 技术架构能够在每天 6100 万请求的情况下减少 757 小时的处理时间(相比于 2013 年)。这些改善既得益于2015 年早期的硬件设备升级，也跟软件的性能优化有极大的关系。
那么最近两年在硬件上有什么变化呢？以下为截止到目前为止的硬件列表：
为了支撑 Stack Overflow 运行，那需要做点什么呢？其实跟 2013 年相比并没有什么显著变化，只是做了前面提到的硬件升级和程序的性能优化。
现有系统一般都不会完全隔离开来，Stack Overflow 也不列外。一图胜千言，下面给出 Stack Overflow 的整体架构效果图。本篇文章仅给出硬件整理的逻辑架构的亮点，具体的硬件细节部分将在下一篇文章详细介绍。
图 1 是机架A（在 2015 年 2 月升级的）的实物图片展示。
图1
现在来给出主要系统的逻辑架构图，如图2。
图2
基本规则
首先给出全局的通用规则：
网络服务
首先，用户去 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
图3
更直观的看下对应的 web 服务器的图形展示，见图4
图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% 之下。
图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 并发情况：
图6
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 是备份库。
图7
纵观全文，Stack Overflow 整体架构并没有采用那些非常高端的技术，却造就了一个 IT 界最受欢迎的问答网站之，这是非常不错的。其中每项使用到的技术都进行了深入的研究并开源分享给社区，国内的公司可以从中获得一些启发
标签：always 分代 分布 问题 一级缓存 快速 数据库服务 level fabric
原文地址：http://www.cnblogs.com/anuo/p/6815097.html
