【编者按】从表面上看,Bitly是一家主打URL缩短和分享的公司,然而究其根本,Bitly却是一家真正的大数据公司,每月60亿的点击量、6亿的缩短服务、1亿网页的爬取,Bitly可以说从事着典型的大数据BI业务。在HighScalability近日的一篇文章中,其创始人Tod Hoff分享了来自Bitly的分布式系统打造理念。
免费订阅“CSDN云计算”微信公众号,实时掌握第一手云中消息!
CSDN作为国内最专业的云计算服务平台,提供云计算、大数据、虚拟化、数据中心、OpenStack、CloudStack、Hadoop、Spark、机器学习、智能算法等相关云计算观点,云计算技术,云计算平台,云计算实践,云计算产业资讯等服务。
以下为译文
你是不是曾经很好奇bitly如何实现营利了?一个URL缩短工具怎么可能那么难写?Sean O'Connor,作为Bitly首席应用开发人员,在Bacon讨论会的一次发言中给出了关于bilty如何营利的答案。
Sean解释到,写一个可用的网址缩短工具是很容易,但是要写一个大规模的并且高可用的则并不如想象那么容易。Bitly并不是通过将URL缩短作为一个服务来实现营利的,它的赢利来自一款数据分析产品,这个数据分析工具将URL点击数据和他们从网络上爬取的数据做对比,帮助他们的客户找出什么类型用户关注了那些网页。
数据分析产品开始是作为一个爬取web服务器日志的后端服务,这些日志包含了来自注解链接的数据和cookie数据,这些数据包括用户从哪里点击了链接,哪个用户点击了这个链接,链接的内容是什么等等信息。但是所有的链接都回到了网站的域名。这样的话,如果让链接转向你另一个域名,那么第三方可以分析这些数据,这个主意听起来很可怕,但是它也是一种天才的想法。
这个话题并不是针对Bitly的架构,这是一个关于分布式系统和如何使用分布式系统去解决一系列问题的本质探索。或许从他的发言中我最喜欢的是这句:
SOA+队列+异步消息真的非常强大。这种方式分离了组件,使工作并发进行,使故障独立发生,同时,使组件很容易解释这些行为。
我同样非常喜欢他的“为什么事件式消息比命令式消息好”的解释,我之前从未听过类似的说法。Sean从实践出发,如果你尝试从单主机扩展到集群模式,这个演讲值得观看。这里让我们看看Sean如何解释分布式系统。
注意,以下这些只是在发言中被提及的一些技术,并不是一个全面的列表。
1. 高可用的应该就是分布式的,为了获得一定的可用性,就必须实现地理位置多元性。按照定义,如果你在不同的地区有独立的操作系统,它们就必须是分布式的。
2. 创建分布式系统的老方法。建立抽象让你以为事情不是分布式的。
3. 新方法通过接受分布式系统固有的特性来处理问题,将这些抽象为工具提供。重大转变在于你如何看待事情,因为抽象更接近于你构建的现实,你可以做更多有力的权衡取舍并因此更高效的去完成某些事情。
4. 带有一个存储器的4个机器总是比带有4个存储器的1个机器要便宜,这就意味着分布式系统是通往大规模和获取高可用的有效方式。
5. 因为我们从一台机器转向了N台机器,分布式系统的问题就出现了。
6. 有些问题,比如分析数据太大而不能用一台机器来处理,或者至少这么一台机器不在预算内。
这儿没有一个庞大的Bitly应用,只有很多通过网络通信的小服务。
1. 如果只有一两台服务器想知道哪台坏掉了并不难,但是如果有数百台的主机你就需要帮助了。
2. 使用类似Nagios的工具来检查主机状况,检查状态比如“机器是否还在运转”?
3. 运行完整性检查。例如,服务是响应了但是返回的数据被破坏了。
4. 集中化的日志。这个非常重要因为你可以检测跨不同主机之间的故障。如果一个用户造成了所有的错误,那么从一台又一台的机器中检测到错误信息将会非常困难。集中化日志式使检测整体的错误变得更容易,就像所有的错误都来自同一个IP地址。
5. 时间到达正确的人,你如何显示来自工具的信息。
1. 知识就是力量。你知道的关于事情的属性越多,就越容易做出更好的决定使工作变得更高效,效率意味着你可以以更低的成本使系统更大更快。
2. 为抽象漏洞建立解决方案。如果你使用抽象的一层来隐藏分布式的特性,最终必将失败,代码必须发现并处理任何漏洞。
3. 尽可能的放在一个机器里,如果你不需要一个分布式系统那么就不要创建了,要创建它们很复杂并且昂贵。
4. 在面向服务架构中,故障意味着功能受限而不是停机。
5. SOA+队列+异步消息真的非常强大。这种方式分离了组件,使工作并发进行,使故障独立发生,同时,使组件很容易解释这些行为。
6. 当速度和一致性是至关重要的时,使用同步请求。返回给用户错误信息而不是很慢或者错误的答案。
7. 事件式的消息比命令式的消息要更好些。它们使得系统间更好的隔离开,更自然的支持多个消费者。 助保持服务的专注性,而不用担心服务功能之外的事情。
8. 注解而不是过滤。在生产等级适用过滤将疲于应对下游服务关注的链接例子是公共和私有的链接,过滤私有链接意味着对这些私有链接感兴趣的服务无法获得这些它们需要的链接。注解私有或者公共的链接让服务只处理它们关心的事件。
9. 使服务更好的运行,使用back pressure防止服务过载并绕过故障的服务。
10. 如果没有Nagios来检查,就算几乎可以确定损坏了,你都不能知晓。
11. 工具应该对向人们展示信息,使正确的信息在正确的时间到达正确的人。
原文链接: Bitly: Lessons Learned Building A Distributed System That Handles 6 Billion Clicks A Month(翻译/海霞、仲浩 责编/仲浩)
联系客服