【编者按】这篇博文的作者是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
■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服务器（有好多这种服务器），下头就是数据库（数据库没多少，变得阻塞起来。）
■开发过程中不使用度量指标就好比高度计失灵的情况下，试图在暴风雨中让飞机着落。在整个开发过程中，要估算网站吞吐量、修复致命缺陷/严重缺陷的时间和代码覆盖率等度量指标，以此来评估你的性能。
