Tag Archives: eBay

再谈 eBay 的扩展性最佳实践

很多人都觉得 eBay 在 QCon (北京) 上的技术讲座不错,但对我来说,其实冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多,以后要是开个什么会,你把 Jeff Barr 请来还讲那个销售文档,估计自己都不好意思。

不过,eBay 这次的PPT 总算还是有点更新的。

1)数据分片(Partition Everything)

说是分区(Partition),这里不能简单等同于 Oracle 的分区,理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文:开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是,分片是在数据量的确有规模的时候才适合进行,如果单节点足以应付,那么还是不要冒进。

从分片的模式上,eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑),作为推论,所有会话都是无状态性的。

2)异步处理(Asynchrony Everywhere)

其实对于任何网站来说,过度追求”同步”化设计还是比较糟糕的做法。以用户能观察到的数据为视角进行设计,中间可以最大限度用异步来完成。

eBay 的举例的模式有两个,一个是事件队列(Event Queue),另一个是信息分发(Message Multicast)。前者基本上是个生产者–消费者的模型。后者主要用在搜索的架构上。

eBay_message_multicast.png

注意到图中的消息总线,这才是 eBay 整个架构中的动脉,估计轻易不会批露技术细节

3)自动化(Automate Everything)

这里的自动化举了两个例子,一个是针对运维方面的,另外举了关于机器学习的东西,这是演讲者 Randy Shoup 的强项所在。

eBay 的自动化,在一年前的另一篇文章里可以窥测一点东西。只是这篇文章当初没有被更多人重视,参见:eclipse at eBay。可以看到 eBay 能在自动化方面做得这么好(起码敢出来讲)不是一朝一夕之功。

4)故障检测与回溯(Remember Everything Fails)

更好的失败检测机制: 监控每天超过 2TB 的日志,根据日志中的相关事件得出判断或者预警。这个看起来简单,但实现起来还是需要一点技巧和策略的,重要的是,需要不断根据结果的反馈去改进。

完美回滚: 任何服务都通过服务配置中的标记来识别,无痛回滚。(个人感觉这个非常有难度,尤其是升级的时候)

优雅降级(Graceful Degradation):能够相对容易的对应用标记”Marks down(下线)”

5)拥抱不一致性(Embrace Inconsistency)

举了 CAP 原则,程立将其形象描述为帽子戏法,非常准确。说起一致性,自从 Amazon CTO Werner Vogels的 Eventually Consistent 一出,基本上不需要再废话了,这就是事务处理的九阴真经,大家回家慢慢参详好了。

eBay 也有自己的绝对准则: 绝对没有分布式事务(两阶段提交), 通过状态机与操作顺序最小化不一致性,通过异步事件(消息总线?)达到最终一致性。

EOF

另外小道消息:Amazon CTO Werner Vogels 可能会参加六月份在杭州举办的侠客行大会。

以前的老帖子:eBay 的Scalability最佳实践

病中的 eBay

电子商务巨头 eBay 有恙,病在腠理,不治将恐深。已经好久不写针对竞争对手公司的评论了,但《福布斯》这篇文章真的让人感触良多。

硅谷的 IBM

谁的会议多,谁的效率低下:

公司内部流传着一个笑话,说eBay已经成了”硅谷的IBM”。20年前,IBM的官僚作风最终导致了公司风光不在,而这一比喻正是对eBay当前状况的真实写照。一些现任和前任eBay员工纷纷在采访中抱怨说,eBay总是有开不完的会,公司太看中幻灯片的演示而忽视了真正的创新。他们说,eBay成了 “商业咨询师”的聚集地,但是这些人大都是”纸上谈兵”,根本没有与客户进行深入的接触,而且缺乏技术眼光,行为方式过于保守,而真正工程师却只能在一旁听候指挥。

不吃自己的狗粮

eBay 管理人员不用自己的产品,自然也就无从知道用户的感受:

“eBay的管理人员都很聪明,但是这些聪明人却从来都不用eBay,也没有花费足够的时间来研究他人是如何使用eBay的。”

电子商务公司需要技术高层

除了刚刚加盟前网景公司联合创始人马克-安德森(Marc Andreessen)之外,eBay公司的最高管理层中找不到任何的拥有技术背景的人。

尽管有些问题,但是 eBay 仍然是需要我们仰视。

EOF

Paypal 的 数据仓库管窥

一直以来,Paypal 的技术信息都很封闭的,很少能看到披露后台关于信息架构的东西。

Paypal 当前的数据仓库用的是 NCR Teradata ,32 个节点,50 TB 的数据,耗时三年打造。而整个公司投入在 BI 范围上的资金占据全部 IT 投入的 60%。

之前 Paypal 用的是 Oracle 数据仓库的解决方案,旧的 Oracle 数据仓库环境其实类似生产环境 Schema 数据的镜像。从 Oracle 到 Teradata ,不是简单的迁移,而是完全重构了数据模型,对数据重新清洗并提高数据质量。

因为欧美是依赖信用卡的消费习惯,所以 Paypal 面对的信用卡消费欺诈还是很严重的,一度高达 0.25% 的资损(印象中好像有段时间来自俄罗斯和东欧的欺诈特别多),这可能也是 Paypal 在数据仓库/BI 上投入重金的一个原因(此外还收购Fraud Sciences 公司来减少这方面的风险)。

除了有效提供损益报告,Paypal 的数据仓库还必须即时有效的提供的一个指标叫做 “Funny Mix”,代表信用卡资金交易帐务平衡指标与 ACH(自动化清算所,Automated Clearing House) 帐务平衡。

作为对比 eBay 数据仓库环境每天新进来的数据就有 40TB(和Yahoo! 的DW不相上下),这样的数据量,处理起来的难度还是有一点点的,据说原来技术人员 90% 的时间要花费在数据清洗上,现在也开始用 Teradata 大集中式数据仓库的模式了。

尽管收集 Paypal 的信息非常不容易,但也希望能挖掘出点有意思的东西来。

EOF

BASE — 高可用架构的基石之一

在讨论 eBay 的Scalability最佳实践 的时候,结尾提到了 BASE 机制。现在越来越多的架构师更为关注 BASE 策略 (当然,我不是说 ACID 就不重要了)

BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义:

  • Basically Available –基本可用
  • Soft-state –软状态/柔性事务
  • Eventual Consistency –最终一致性

“Soft state” (SS) 是与 “Hard state”(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, “Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的,这样就清晰多了。

最终一致性, 也是是 ACID 的最终目的。对于 eBay 这样的大架构,是通过强大的消息总线能力来保证的。

对于 eBay 这样的大架构,另请参考 eBay 的 Dan Pritchett 在 最近的技术的散文:BASE: An ACID Alternative,注意其中提到的的事件驱动(Event-Driven)的架构的说法。

相信在今后几年,BASE 将成为一个技术热词。ACID 当然没过时,只是各自需要合适的应用场景而已。随着互联网技术的开放性,更多的时候,一个架构师需要反复的衡量合适的应用场景。

BTW: “ACID” 英文里面有”酸”的意思,而 “BASE” 有”碱”的意思. 酸碱在一起才能中和啊,哈

EOF