ebay的架构特点

去年的时候，就了解了 ebay 的架构了，只是很多事情没有亲身经历，很难深有体会。离去年的 Qcon 大会快一年了，今年的也快召开了，时光流逝，真是人事变迁，我回深圳也快一年了。今天有空也来班门弄斧一下。

      ebay 是电子商务网站，一个电子事务网站一定要保证交易的完整性，这个和淘宝一样。 ebay 的架构特点：

Partition Everything

     当一个网站刚开始时，可能一天只有几十个人访问，或者几百个，可能一台普通的服务器就足够了， db 和应用统统都可以放在一起，可是随着用户的增加，业务的增加，一台服务器远远不够了，就自 然想增加服务器，系统应该跟随改变。多一台服务器，也就减轻了一台压力。这样就出现了分割业务和分割数据。

     其实要做到恰到好处，也非常不容易， ebay 按照业务功能水平划分应用，水平划分数据库。这个在国内好多网站都是这样做，不足为奇了，不过水平划分功能后，单个功能应用的分割也大有文章可做。怎么划分，很早以前 ebay 的架构文档说到这个事情。

在水平按照业务划分数据库后可以再根据一定的规则划分表数，其中规则有很多，可以按照主要业务生产者为引导进行分割，所有数据跟随生产者一起，至于什么规则可以各抒己见。

Asynchrony Everywhere

     同步应用会带来强耦合，可用性保障差，特别是在用户体验方面极度失败，试想一个网站首页要获取那么多业务信息如果同步的话会流失很大一部份用户，如果再加上网络慢，等到蚊子都睡觉了，人哪里还有时间看，其实分布式系统应该尽量使用异步处理。

     EBay 的应对策略为：事件驱动和 pipeline 、多播消息，涉及的技术为：消息中间件（无序、至少一次到达）、基于 SRM 技术的可靠多播。

 

Automate Everything

     配置信息的动态化，涉及的技术：配置发布 / 订阅机制的实现、机器学习。这个超级牛，不知道国内有多少网站做到了，听说淘宝做到了（呵呵）。

 

Remember Everything Fails

故障检测和回滚

     这个现在很多网站都做，不过 ebay 做地比较牛， ebay 差不多每天有 2TB 的日志，通过监控事件作出有效的判断和预警，淘宝也做得很好。

      eBay 的应对策略为：异常后发消息、接收者获取消息警报、按功能实现降级，保障核心功能的可用性，涉及的技术有：消息中间件、如何实现按功能降级。

 

Embrace Inconsistency

     其实这个有点象我们整天说的 “ 拥抱变化 ” 。在系统中如果事务过多，极大影响性能，特别是分布式事务，如果一味追求一致性会严重性能， ebay 的做法是过程不一致，最终一致。 涉及的技术有：消息中间件、 CAP （ Consistency 一致性； Availability 可用性； Tolerance of network Partition 分区容忍性（可理解为部分节点故障或节点之间连接故障下系统仍可正常工作） ）等

 

Expect (R)evolution

     这里 eBay 讲到的主要是如何更好的应对变化，这包括了功能演变、架构演变， eBay 的应对策略为：灵活的 schema 、可插拔的处理流程以及增量的系统发布，这方面的技术还是相当复杂的， eBay 采用的是：配置化处理流程、系统发布过程支持多版本共存。

 

Dependencies Matter

     这点随着分布式的应用和异步的应用，以及功能的不断增加后，就会变得比较明显， eBay 也是如此。

他们的应对策略：服务拓扑管理、设计上的控制（只允许依赖… ）、客户端承担责任。

说到这点，不得不说下，客户端承担责任这点其实真的很重要，现在很多架构都喜欢放在服务端上解决N 多问题，但很多场合确实有必要放到客户端去做，当然，这也会带来一些问题，例如升级等。