eBay Architecture(6)–Partition Everything[Application Tier]

授之以鱼不如授之以渔，在分析应用层的时候，还是使用在Partition Everything Overview中提到的相同的原则：

• Functional Segmentation

eBay一共有超过16000个app servers，部署在220个pools里面。有Selling Pools,Search Pools…

为什么不在一个app server里面放进去所有的应用？首先是eBay的应用太大了，一台app server里面根本就放不下，就算放的下，那也不会是一个好主意，下面列了3个原因：

1. Segment functions into separate application pools.
2. Minimizes DB / resource dependencies.
3. Allows for parallel development, deployment, and monitoring.

Operation Team希望把应用按照功能切分开，要不然所有的应用在一起，意味着这台机器依赖于所有的资源，如果切开就好多了，seller pools只依赖于seller的资源，search pools也一样。而第3个原因我们开发者很有感触的，就是很好的功能切分能够帮助并行开发，并行的部署代码，以及监控。

• Horizontal Split

在一个pool中，所有的app server都是无状态的，而且都是一模一样的。这样处理以后，如果我们需要增加处理能力，我们只需要简单的在pool中加入更多的app server就可以了。那如果决定一个pool中的哪个app server来响应某个请求呢，eBay使用标准的Load Balancer来处理，Load Balance是一个硬件设备。周五下午的时候MIT的Xun给我们介绍了Load Balance的功能的特点，以后有时间再写。有了Load Balancer以后，用户请求其实并不关心是哪个app server服务了请求，反正一个pool里面的app server都一样的。

这样有一个很重要的好处，假设我们现在为Search Pool开发了一个新的版本，难道我们把新版本的代码部署到search pools 的时候search pool就不工作了吗？不是的，我们可以先把10%的search app server "take our of traffic"，这个时候还有90%的capacity在服务，然后把新代码部署到这10%的app server上，接着做下一个10%…如此一来，外面的用户基本感觉不到。

1. Within pool, all application servers are created equal.
2. Routing through standard load-balancers.
3. Allows for rolling updates.

因为app server都是stateless的，而且同一个pool里面的app server都是完全一样的。这就意味着在app server中保留session state非常的困难。随之而来的一个推论(Corollary)：

Corollary: No Session State

1. User session flow moves through multiple application pools.
2. Absolutely no session state in application tier.
3. Transient state maintained / referenced by
   • URL
   • Cookie
   • Scratch database

这样的做法在通常并不多见。很多同行是把session state保存在应用层的，或者保存在一个相对独立的tier里面。eBay这样做的一个原因是，eBay把应用按照功能切分成220多个pool，而一个典型的业务流程很可能跨越多个pool，比如：当我访问  www.ebay.com 的时候，我首先到达首页，然后我search，搜到以后我就查看那个物品(view item), 有可能我就竞价了(bid)… 而search/view item/bid都隶属不同的pool，所以没有一个pool可以一路保存整个流程中所有的session state！

但是从业务上来讲，我们必须"记住"这些session state，于是上面第3条提出了解决方案。我们可以把状态放在URL中从一个pool传到另一个pool。另一个常用的方法是把session state放在cookie中，但是这样做有一个限制，这个限制是有HTTP Specification造成的：Cookie的大小不能超过4KB。所以我们可以把这些状态存到DB里面去，比如在Sell Your Item的时候，用户可能要接触好几个页面，在第一个页面的时候可能服务他的是app server01,在第二个页面的时候服务他的就有可能是app server02了，如果app server01 down了，app server02能够很方便的从数据库中拿到session state。

O.K.这里有个问答题-:)

想一想eBay是怎么处理Sign In的？