在HPTS大会上，Randy
Shoup放出的eBay的PPT有所改变，在原有的5个Architectural Lessons上又增加了5个lesson，从这也可以一定程度的看出当访问量、数据量、功能不断上涨后，碰到的技术问题也将继续发展，想必这也是eBay增加5个lessons的原因，eBay在技术方面的发展对很多互联网公司都有一些参考意义，毕竟它已经经历过了国内很多网站目前的阶段甚至是几年后的阶段，在本篇blog中就完整的来看看eBay的这10个lessons、eBay的应对策略以及我个人的一些推测。
1、 Partition Everything
这点是现在各家互联网都使用的招，说白了也很正常，毕竟一个网站通常要提供很多功能，如果都部署在同一台机器上，随着水平伸缩，后端的资源肯定会呈现不够用的现象，这个时候能采用的方法自然是分，分开后自然一台能够支撑的量也会更高，同时后端资源的压力也会减小。
当然，要做到这点其实并不容易，eBay应对的策略为：按功能水平划分应用、按功能水平划分数据库、按其他原则垂直划分表，涉及到的技术有：划分之后应用的交互的解决以及数据访问层（DAL）。
这点基本是现在互联网公司的必备技能。
2、 Asynchrony Everywhere
同步的交互会带来强耦合，可用性方面保障就比较困难了，因此尽可能的采用异步。
在这点上，eBay的应对策略为：事件驱动和pipeline、多播消息，涉及的技术为：消息中间件（无序、至少一次到达）、基于SRM技术的可靠多播。
这点基本也是现在互联网公司的必备技能。
3、 Automate Everything
这点eBay比较强，中国的互联网公司不知道有几家能做到，J，其中有一点和twitter那个PPT提到的差不多，就是配置信息的动态化，这个确实非常重要。
要做到这些方面，会涉及的技术有：配置发布/订阅机制的实现、机器学习。
有些其他强大的东西eBay在这里也没提，例如部署系统。
4、 Remember Everything Fails
这点很多公司都做，但从PPT来看，估计很少有公司能做到eBay这个地步，J，尤其是eBay的优雅降级，twitter公布的PPT中也有类似的内容，国内公司还得努力，呵呵。
eBay的应对策略为：异常后发消息、有相应的消息订阅者接收这些报警信息、按功能实现降级，保障核心功能的可用性，涉及的技术有：消息中间件、如何实现按功能降级。
5、 Embrace Inconsistency
这点对于互联网公司来说非常重要，事务过多，性能就狂降了，尤其是Partition everything后，分布式事务需求产生，就更要注意了，因此eBay的应对策略为最终一致，涉及的技术有：消息中间件、CAP等。
以上5个lesson是很早以前eBay PPT中就一直有的，而以下5点则是第一次出现在eBay的PPT中，从中也可以一窥随着网站的发展带来的技术挑战。
6、 Expect (R)evolution
这里eBay讲到的主要是如何更好的应对变化，这包括了功能演变、架构演变，eBay的应对策略为：灵活的schema、可插拔的处理流程以及增量的系统发布，这方面的技术还是相当复杂的，eBay采用的是：配置化处理流程、系统发布过程支持多版本共存。
这点要做到真的不容易，看来eBay已经碰到了发布必须增量发的问题了。
7、 Dependencies Matter
这点随着Partition
everything和Asynchrony everywhere执行，以及功能的不断增加后，就会变得比较明显，想必eBay也是如此。
他们的应对策略：服务拓扑管理、设计上的控制（只允许依赖…）、客户端承担责任。
说到这点，不得不说下，客户端承担责任这点其实真的很重要，现在很多架构都喜欢放在服务端上解决N多问题，但很多场合确实有必要放到客户端去做，当然，这也会带来一些问题，例如升级等。
8、 Be Authoritative
这点没看明白。
9、 Never Enough Data
看的也不是很明白，我理解下来意思也许是数据肯定是会一直增长的，因此要考虑可伸缩的内存保存以及持久存储产品，英文写的就是large-scale distributed storage。
10、
Custom Infrastructure
同样没看明白，感觉就是要做到充分发挥机器资源，从eBay有SLA来看，莫非是要开始做云计算了，J
总结来说，eBay也是首先解决如何做到基于水平伸缩支撑大访问量、大数据量的问题，然后则是开始步入如何管理以及保障好如此大的应用的关系、可用性等。
ps:
之前那篇《旁观者看eBay技术发展》的blog：http://www.blogjava.net/BlueDavy/archive/2009/07/24/288055.html