很多人都覺得 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 整個架構中的動脈，估計輕易不會批露技術細節
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 可能會參加六月份在杭州舉辦的俠客行大會。
**：
實踐 Sentinel 擴充套件性設計
sentinel 提供多樣的 spi 介面用於提供擴充套件的能力。使用者可以在用同乙個 sentinel core 的基礎上自行擴充套件介面實現，從而可以方便地給 sentinel 新增自定義的邏輯。為了統一初始化的流程，我們抽象出了initfunc介面代表 sentinel 的一些初始化邏輯，如 ...
NoSql的易擴充套件性
nosql現在很火很時髦，大家言必稱nosql，彷彿關係型資料庫已成陳舊落後的代名詞。但依我看，真正理解nosql的還不多，在實際專案中用過的應該就更少了。我也還不理解，更沒怎麼應用過，所以現在要努力學習。在學習過程中，常看到有吹噓nosql相比較關係型資料庫而言，有乙個優點是 易擴充套件。這怎麼理...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...