Stack Overflow通过关注性能,实现单块应用架构的扩展能力

jopen 9年前

 

在New York QCon 2015 大会上,David Fullerton 深入解析了如何使用C#/ MS SQL支撑Stack Overflow网站的单块应用架构,这个网站每月处理40多亿的用户请求。Fullerton 认为,关注性能就可以几乎免费地使网站具备应付高并发的扩展能力;同时,通过减少对外部服务的调用,SOA开销(SOA tax) 得以避免。

FullertonStack Exchange 的工程部副总裁,在演讲开篇就指出尽管Stack Exchange旗下网站使用的技术架构很平庸,但网站使用如此陈旧技术仍能运行良好的方法却很有趣。Stack Exchange 掌控并运营着几个社区类“问答”风格网站,包括广受欢迎的 Stack Overflow 开发者问答门户网。

Stack Exchange团队完全以远程方式协同工作,即便团队成员在同一地点办公,公司也鼓励员工相互之间仅仅使用远程协同的方式,例如使用即时通讯工具和缺陷 跟踪程序。Fullerton 说,正是由于公司保持一种“雇佣聪明员工并不妨碍他们”的心态,从而使系统管理员和全栈工程师组成一个高效团队,共同构建并维持网站平稳运行。

Stack Exchange旗下的网站在设计时都使用了一种升级版单块应用(monolith plus)的架构,几乎所有的应用逻辑都由C#的Web层以及MS SQL数据库实现。这个规则也有一些例外,例如标记相关逻辑已经从单块应用中提取成标记引擎服务,缓存服务则由几台Redis服务器提供,同时 ElasticSearch服务器提供全文搜索功能。

Stack Overflow通过关注性能,实现单块应用架构的扩展能力

开发团队将网站的应用程序部署到两个数据中心,从而增加系统的整体容错能力,纽约机房作为主数据中心,俄勒冈机房作为备援数据中心。开发团队以滚 动部署应用的方式更新整个Web层的服务器,这种部署操作每天都会发生,从白天到晚上。新功能的测试由一组真实用户执行,这些测试用户则是由一系列特性标 记自动选择出来的。

我们首先会在部分网站上尝试(新功能),并观察运行的情况。这种方法对我们很有效。我们网页的特性是在单个页面(问答页]上有很高的读负载,而并不像其他网站的页面有那么多客户化的内容,而且我们有一个比较宽容的用户社区。

Stack Exchange的研发理念是“先用我们熟悉的技能,度量问题,修复慢的地方”。最初的开发人员只了解C#和MS SQL,因此我们今天仍在使用这样的开发堆栈。早期的Web应用程序利用到几个现成的工具:ASP.Net MVC,Linq到SQL的转换,MS SQL全文搜索和内置缓存。Fullerton 表示,在Stack Exchange,由于关注客户体验,并考虑到搜索引擎对于性能好的网站会有正向权重,所以性能是一个重要的功能特性。 Stack Exchange通常都会在实际的负载下测试(不允许任何猜测和假设),开发团队会将性能问题当作务必尽快解决的缺陷。

整个网站架构有很好的并发处理能力。我们每月处理40亿次请求,峰值为每秒3000次,每天有8亿次SQL查询,峰值为每秒8500次。

Fullerton说,随着时间的推移,初始技术栈中的主要部分已被取代:引入Redis以提供缓存,添加ElasticSearch以改善全文 搜索能力,通过使用定制的中间语言生成框架来替代原有的实体层对象映射方式,从而提高SQL访问的效率,同时兼顾扩展性和新功能需求,从原有的单块应用中 抽取出标签相关逻辑,形成独立的标签引擎服务。

工具对于识别和监控性能问题很有帮助,例如 miniprofiler 可以分析用户请求并检测性能瓶颈, Opserver 用于监控, Dapper 可以分解追踪请求。Fullerton表示,对性能的关注会带来很多好处。

你可以通过优化性能而提升扩展能力(几乎免费)。单块应用的扩展能力超出你的想象。

Fullerton的结论是,这种升级版单块应用的架构在Stack Exchange非常成功。尽管这种架构可能显得陈旧无聊,但团队坚持这种方式的过程非常有趣。微服务架构的风格可能在当今很流行,但Fullerton 警告说,过度使用这种模式,就必须承担这种模式固有的各种SOA开销(SOA tax)。

SOA不是唯一的成功之路。我们要知道自己的问题领域,在解决实际问题的过程中,提取服务去解决实际困难,而不是虚幻地想象各种服务。

你可以在QCon New York会议网站上找到更多关于David Fullerton演讲“ Scaling Stack Overflow: Keeping it Vertical by Obsessing Over Performance ” 的信息。

查看英文原文: Scaling the Stack Overflow Monolithic App by Obsessing Over Performance