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 的架构、研发、运维等层面的技术选型和经验值得学习和参考。
评论