Cinchcast如何支持每日发布1500小时的视频内容 BY InfoQ

Dr. Aleksandr Yampolskiy，作为Cinchcast和BlogTalkRadio的首席技术官，在近期的一篇文章中从Cinchcast的软硬件系统、技术选型以及经验教训等方面分享了他们在扩展自己的平台时的一些经历和决策。(Cinchcast公司提供的解决方案让客户能够基于创建、分享音频内容等服务来吸引和联系他们重要的业务干系人。)

整篇文章主要分为如下几部分：

一、统计数据概况

• 浏览量每月超过5000万
• 创建了50000小时的音频内容
• 1500万个流媒体
• 175,000,000次广告展示
• 峰值每秒40000并发请求
• MSSQL、Redis、ElasticSearch集群中存储的数据达到每天数TB，
• 10人工程师团队
• 生产环境大概有100左右的硬件节点

二、数据中心

线上网站是在布鲁克林的数据中心运行，考虑到可控性，生产环境并没有用到云，但QA和Staging 环境则使用了Amazon EC2实例，这一点值得我们参考， 因为测试环境就算不稳定也不会有什么大的风险，而生产环境则不同，大部分公司都愿意把控在自己的运维人员手中。

三、硬件

• 大概有50台Web服务器
• 15台MS SQL数据库服务器
• 2台 Redis的NoSQL的键值服务器
• 2台 NodeJS服务器
• 2台 弹性搜索集群服务器

四、开发工具

• NET 4 C#：ASP.NET和MVC3
• IDE用的是Visual Studio 2010 Team Suite
• 用StyleCop、ReSharper来强化代码标准
• 使用敏捷。其中大的功能用Scrum，小任务则通过看板任务墙管理
• 测试和持续集成使用Jenkins + Nunit
• 自动化测试则是Selenium和Sauce On Demand

五、软件和使用的技术

• Windows Server 2008 R2的64位操作系统
• 基于微软Windows Server 2008 Web服务器下运行的SQL Server 2005
• 负载均衡是EQL(Equalizer load balancers)
• Redis作为分布式缓存层和消息分发队列
• NodeJS 用来进行实时分析和更新仪表盘
• 搜索用得是ElasticSearch，日志分析是通过Sawmill+自定义分析器脚本

六、监测

• NewRelic：性能监控
• 性能对KPI（转换率，页面浏览量）的影响：Chartbeat：
• Gomez，WhatsupGold，Nagios等用来各种预警和报警
• SQL Server monitoring的监控：来自Red Gate的SQL Monitor

七、处事方法论

• 尊重他人的时间。不要带着问题来，要拿出解决办法。
• 不要去追逐当下的热点技术，先实现基本功能，然后再做锦上添花的。务实是最重要的。
• 成为一个“如何做”的团队而不是总是说“不”的团队
• 预先处理总比亡羊补牢要好，把安全植入到软件开发生命周期中，通过培训开发人员如何写出安全的软件并把它从一开始就作为业务优先考虑之处。

八、 架构

• 所有的Javascript, CSS 和图片都缓存在CDN，通过cookie来区分常规用户和广告用户的请求，并分别指向不同的服务器集群。
• 向SOA架构进行迁移，系统中的关键部分，如搜索、认证、缓存都是用不同语言实现的RESTFUL服务。
• Redis NOSQL 的键值存储（redis.io）被用来作为一个数据库调用之前的缓存层。

九、经验教训

• SQL Server数据库中的文本搜索不好用，经常出现CPU阻塞，所以他们切换到ElasticSearch，一个Lucene的衍生工具。
• 微软内置的会话模块容易出现死锁，他们用AngiesList会话模块取代了它，并把数据存储到Redis。
• 日志是发现问题的关键。
• 重新发明轮子，有时候也可以是一件好事。例如，在一个供应商的提供的JS / CSS的产品导致性能问题的时候，他们通过重写显著改善了网站的性能。
• 并不是所有的数据都是关系型的。
• 在开发中不使用指标检测就像在风暴中不参考高度表来降落飞机，因此整个开发过程中，一定要通过网站吞吐量，解决错误的时间、代码覆盖率，等指标来衡量你的效率。 总的来说，对于日PV百万级的网站来说，Cinchcast的架构、研发、运维等层面的技术选型和经验值得学习和参考。