QCon会议笔记-架构案例和实践.docVIP

QCon会议笔记（架构案例实践篇） rouse整理 2009-4-13 有关大容量高并发网站架构，我参加了ebay、淘宝、优酷三家的架构实践演讲，豆瓣网和淘宝的演讲同时举行，鱼掌不可兼得，由于淘宝网属首次介绍架构，而豆瓣以前有了解，且网上资料较多，故没有参加豆瓣网的演讲，事后了解到这次豆瓣网的架构讲的比较细，不能不说是一个遗憾。现分别介绍： 《来自eBay的教训——可扩展站点的最佳实践Randy?Shoup eBay市场架构组的杰出架构师5个架构原则： 1、分割（按功能分离、水平切割、无状态化） 2、异步（事件队列、消息多播） 3、自动化（适应性配置、机器学习---在恰当的时间适当的地方推出合适的内容） 4、关注异常（异常捕捉、回滚、优雅降级、记录所有的错误、当系统出现严重的错误的时发消息出来，可以通过订阅消息来实现错误修正等，有点类似erLang的容错） 5、拥抱非一致性（选择合适的一致性精度--以牺牲不必要的实时一致性换取分布计算、避免分布事务） 在阐述上面五个基本原则时Randy Shoup始终遵循一个原理：对一个数据系统，下面的三个属性永远只有两个可以同时拥有：1、数据在任何时候都是一致的（实时一致性）2、?数据是分开保存的（数据是分散的）3、?系统在某些部分（例如硬件故障）发生错误的时候仍能正常工作（容灾容错）例如，ebay的数据是分散的（因为要做数据分片），系统有容错的需求（因为ebay有很多的服务器，几乎每时每刻都有这台或那台服务器出问题）因此就只能牺牲数据的非必要实时一致性来保证后面两个特性。 由此想到上次产品经理提出的对种子短信进行实时统计的需求，当时经评估建议只做到非实时一致性（最终一致性）：在某用户发送种子短信时，只显示对该种子短信统计的局部一致性，即用户自己操作且能感受到这个变化，其它用户的操作不即使反馈到这个用户的视图中，但在下次登录时，该用户可以感受到全局一致性。这种思想应该是与ebay的架构原则是一致的。作为一个有着大量交易行为的的电子商务网站，ebay不使用分布式事务，对于非分布式的也用的很少，仅仅在拍卖交易这一处使用（这儿要求实时一致性）。后来在淘宝的演讲中，我们得知淘宝也是基本上也不使用事务。 看来英雄所见略同，大型电子商务系统，需要谨慎的使用事务。电子商务系统追求的是最终一致性（eventually consistency）而不是实时一致性（immediately consistency），最终一致性不需要采用数据库的事务的方式来实现，而可以采用类似于现在银行的支付系统的定期对账的方式来实现。ebay认为，就算是银行的金融系统，也是不需要实现实时一致性的。 从三家的的演讲中，可以总结出构建大容量系统的共同的“模式”就是分片和异步。ebay还提到一点就是将一切都自动化（automate everything），其他两家好像都没有提到这点。 《基于Java构建的淘宝》 岳旭强，淘宝网技术专家LAMP架构，交易系统还是在一个开源的项目上改的。最初只用了一台服务器，目前还供奉着。-----典型的开源山寨版网站、两层集中式架构 第二阶段 随着业务发展，首先出现瓶颈的是mysql，那时候的mysql master-slaver架构不成熟，延迟厉害，不能适应业务发展，后来改为oracle。-----高级两层集中式架构 第三阶段 业务继续发展，开发团队逐渐增大，php在并行开发方面表现出劣势，且php面向对象开发不够彻底，缺乏开发工具，也不容易实现长连接，导致oracle的连接过多，就将php改为java。使用java后，应用服务器使用weblogic。----J2EE架构（三层集中式架构） 第四阶段 业务发展迅猛，淘宝的更新类业务操作比重较大，oracle也出现了瓶颈，遂将oracle按功能实现分库分表，架构上同时增加数据透明访问层，实现对应用层的透明访问。 ----三层分布式架构 第五阶段 又局部使用mysql，jboss。---有返璞归真的迹象，可能是开源项目的稳定性和功能得到诸多成功网站的实践和宣传，重获信心。 点评：从淘宝网的架构历程可以看到，每次架构都是由于为了适应业务的发展而作的调整。虽然有被动适应之嫌，但也不能不说每次架构调整都有很强的针对性，且很好的解决了问题。有意思的是淘宝网经历了一个从简单到复杂再到简约的过程。可以看到其受业界技术的思潮影响较大。从建站初期的以快速搭建为目的，即选用了LAMP，后来J2EE炒得很热，淘宝也难独善其身，加入了J2EE的浪潮之中，结果发现EJB等技术的艰涩难驾驭，后来选择了简约之路，构建了自己的轻量级MVC框架，可谓遵循了“核心代码必须自己实现”的原则。到目前，又逐步使用mysql和jboss，是与开源社区活跃和开源项目