【编者按】这篇博文的作者是Cinchcast和BlogTalkRadio的首席技术官Aleksandr Yampolskiy博士，他在这两个网站负责工程技术、质量保证、技术运营、电话系统和产品等团队。

【51CTO快译】Cinchcast提供的解决方案让其他公司可以制作、共享、度量和销售音频内容，以便覆盖和吸引对本公司来说最重要的人群。我们的技术整合了会议桥和实时音频流，从而简化了网上活动，加强了参与者的互动性。Cinchcast技术还用于支持Blogtalkradio的运行，这是世界上规模最大的音频社交网络。如今，我们的平台每天制作和分发的原创音频内容超过了1500个小时。我们在本文中描述了我们为了扩展平台、支持数量这么庞大的数据所做的技术决策。

统计数据

■每个月的页面浏览量超过5000万

■制作的音频内容长达50000小时

■1500万路媒体流

■1.75亿广告浏览次数

■峰值速度达到每秒40000次并发请求

■每天数TB的数据存储在微软SQL、Redis和ElasticSearch等集群中

■由10名工程师组成的团队（Cinchcast共有20名技术人员）

■生产环境中大约有100个硬件节点

数据中心

■实际网站从位于布鲁克林的数据中心来运行。我们喜欢掌控自己的命运，而不是把数据交给云平台保管。

■亚马逊弹性计算云（EC2）实例主要用于质量保证（QA）环境和试运行（Staging）环境。

硬件

■大概50台Web服务器

■15台微软SQL数据库服务器

■2台Redis NoSQL键值服务器

■2台NodeJS服务器

■2台服务器用于弹性搜索集群

开发工具

■NET 4 C#：ASP.NET和MVC3

■Visual Studio 2010团队套件充当集成开发环境（IDE）

■StyleCop和ReSharper用于执行代码标准

■敏捷开发方法，Scrum用于大的开发任务，看板/任务板则用于比较小的任务

■Jenkins + Nunit用于测试和持续集成

■Sauce On Demand——Selenium用于自动化测试

使用的软件和技术

■Windows Server 2008 R2 64位操作系统

■在微软Windows Server 2008 Web服务器下运行的SQL Server 2005

■Equalizer负载均衡器用于负载均衡

■REDIS用作分布式缓存层，用于消息发布/订阅队列

■NODEJS用于实时分析和更新Studio仪表板

■ElasticSearch用于分布式搜索

■Sawmill+自定义分析器脚本用于日志分析

监控

■NewRelic用于性能监控

■Chartbeat用于分析性能对关键绩效指标（转换率和页面浏览量）的影响

■Gomez、WhatsupGold和Nagios用于各种警报

■来自Red Gate的SQL Monitor 用于监控SQL Server

我们采用的方法

■“简洁、明快、高效，办完事就走人”：尊重别人的时间。不要带着问题来，要带着解决办法来。

■不盲目追求当下的热门技术。而是“化解你的首要问题”。我们是采用新技术，但只是业务需要新技术时才这么做。如果你有数以百万的用户，针对避免工作网站停运的要求就大大提高。

■先做好“基本功”，然后再考虑“干得漂亮”。

■成为“注重解决办法的团队”，而不是“凡事说不的团队”。

■把安全融入到软件开发生命周期中。你需要培训开发人员，教他们如何编写安全的软件，并且一开始就把这列为一项优先工作。

架构

■所有的Javascript、CSS和图片都缓存在内容分发网络（CDN）处。域名服务系统（DNS）指向CDN，再由CDN将请求传递到源服务器。我们之所以使用Cotendo，是因为它允许在CDN做出第七层路由决策。

■使用不同的Web服务器集群，分别为常规用户和广告用户处理各自的请求，由cookie来进行区分。

■我们正在向面向服务的架构迁移；其中，系统的各个关键部分（如搜索、验证和缓存）是由不同语言实现的充分利用REST的服务。这些服务还提供了缓存层。

■Redis NOSQL键值存储区（redis.io）用作数据库调用之前的缓存层。

■Scaleout用于跨Web服务器园（Web server garden）维护会话状态。不过，我们在考虑切换到REDIS上。

汲取的经验教训

■SQL Server数据库中的文本搜索不好用。它经常造成处理器阻塞，于是我们改用ElasticSearch（Lucene衍生版本）。

■微软的内置会话模块容易出现死锁，于是我们最后把它换成了AngiesList会话模块，将数据存储到REDIS。

■日志功能是发现问题的关键。

■重新发明轮子也可以是件好事。比如说，起初我们使用一家厂商的产品，用于将JavaScript/CSS捆绑起来，这开始引起了性能问题。随后，我们自己重新编写了捆绑方法，因而显著改善了我们网站的性能。

■不是所有的数据都是关系型数据，所以数据库并非总是一种很好的媒介。打个恰当的比方是“设想一下水沿管道流动。管道上头很宽，但到了下头变得很窄。”这个上头就是Web服务器（有好多这种服务器），下头就是数据库（数据库没多少，变得阻塞起来。）

■开发过程中不使用度量指标就好比高度计失灵的情况下，试图在暴风雨中让飞机着落。在整个开发过程中，要估算网站吞吐量、修复致命缺陷/严重缺陷的时间和代码覆盖率等度量指标，以此来评估你的性能。

原文链接：http://os.51cto.com/art/201209/357109.htm