这篇文章主要揭秘 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 和导航也都是用的这些数据服务。 缓存 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
