Qcon2012杭州站參會分享
作者：方騰飛 整理：水羽哲
去年參加了QCon杭州2012大會，有一些收穫和大家分享一下。
京東的分享
京東面臨的問題
京東的分享嘉賓何斌提出京東之前面臨的兩個問題：第一個是促銷時需要很多機器，但是平時不需要；第二個是當某一臺客服中毒其他客服主機也會中毒。大家可以先思考下，覺得應該如何解決這兩個問題呢？
京東的解決方案
第一個問題京東採用彈性架構的方式解決。當伺服器的資源利用率超過一定閾值時動態擴充套件虛擬機器。舉一個例子：如在5分鐘內資源使用率達到某個設定的閾值時，就會自動生成幾個虛擬機器，虛擬機器裡會自動部署好相關的應用程式，在自動釋出前有一個TestServer來監測生成的虛擬機器是否可以對外提供服務。雲端儲存和雲端計算是分離的，雲端儲存使用一個磁碟陣列來實現。
第二個問題京東採用桌面雲的方式來解決。首先分配一批虛擬桌面池，然後客服通過許可權登陸虛擬桌面，如果沒有則再分配一批，虛擬桌面和人不是一一對應的，用完後就回到池子裡別人可以繼續申請使用，這樣可以大大節約資源，當一臺機器中病毒後只會影響到子網。
美麗說的技術總監王曦分享了很多幹貨，美麗說的架構演變值得很多創業公司學習。美麗說起步的時候開發了一個瀏覽器外掛，這個外掛顯示使用者瀏覽的商品，外掛裡提供聊天室的功能，好友間可以就購物進行交流，目的是讓女孩子在上班的時候也有購物的感覺。通過這個外掛美麗說發現女人對於購物的分享和交流具有非常大的興趣，所以決定做一個網站。美麗說的發展經歷了不同的階段：
十萬級PV：採用LAMP架構，無memcache，基本SQL搞定。使用爬蟲工具爬商品資訊。
百萬級PV：開始使用Redis。出現大量的寫操作時，會先儲存在Redis裡然後非同步寫回資料庫。
千萬級PV：開始使用服務化。整體架構向SOA服務化轉型，將所有的功能以服務化的方式提供，當某一個功能掛掉的時，其他功能仍然能繼續使用。整個架構分為API層（評論，使用者管理，私信等），平臺服務層（資料庫，佇列，爬蟲等），基礎服務層（cache，Redis和併發代理）。前端和後端徹底分離，前後端可以單獨上線。
美麗說發現穩定性和訪問速度變得更加重要，例如，訪問速度提高10% PV會提高30%。美麗說的微博系統通過Redis來實現，給每個使用者在Redis裡建立一個類似郵箱的儲存模型，當有使用者關注的訊息時，就往使用者的＂郵箱＂投遞，投遞時會採取很多策略，比如先投線上使用者，再投活躍離線使用者，最後投離線不活躍使用者，或不投。
馮大輝說道：
初去丁香園，發現系統做得很爛，經常不能訪問。作為CTO，面臨的第一個問題是選擇，重新做一套？還是基於開源的論壇進行修改？還是基於舊系統修改？
馮大輝最後選擇在舊系統的基礎上進行修改。基於兩點原因，重新做不一定比舊系統做得好，其次業界比較好的開源論壇很難做二次開發。
整個演講所傳達理念是：
CTO需要謹慎和專業，把一件技術吃透再運用。用資料說話，沒有任何資料支撐，不要輕易做改版和新功能。要快，避免大團隊，小團隊攻堅，要敏捷但不要照搬敏捷的步驟。
讓團隊更敏捷。讓大家坐在一起，讓團隊成員在團隊之間輪崗，減少會議，減少溝通成本。
不要輕易用新技術。因為業界大多數成熟的公司並不是不斷的用新技術，而是把已有技術用得非常登封造極，新技術也會逐漸變成老技術的。
最後，不想做CTO的架構師不是好程式設計師。
大物件的儲存方案：大量使用者登陸到聚划算，聚划算需要通過IP定位到使用者的城市，像IP庫這種非常大的物件，如果使用Redis存的話會有很高的網路開銷，所以聚划算將這些大物件存在本地JVM的記憶體中,然後在不同的伺服器之間通過訊息同步大物件裡的資料。
分散式任務系統：通過一個第三方伺服器來管理所有的任務，使任務能分別在不同的機器上執行，可以通過鎖來實現，拿到當前任務鎖的機器才能執行當前任務。
快取擊穿攻擊問題：如果有使用者訪問淘寶不存在的產品id，那麼系統每次都會繞過快取直接訪問資料庫，解決方案是可以通過在快取裡標示該商品不存在來防止。在微博裡校長回覆說，CDN也有這樣的問題，比如使用404攻擊，通常類似的問題5-20秒的cache就足夠了。
Paypal的演講嘉賓一上臺先來一支騎馬舞熱熱場，很歡樂。Paypal主要分享CEP。 CEP是複雜事件處理的意思，是資料庫的反方向，從資料庫裡查資料是使用查詢語句拿到結果，而CEP是把資料發到一個地方然後得到結果。
Paypal嘉賓分享的CEP感覺和我以前做的安全日誌分析有點像。安全日誌分析可以基於狀態，統計，行為等手段進行分析。基於狀態機的日誌分析，比如1號有某帳號不停嘗試登陸的日誌，10號有這個帳號在操作某臺機器的日誌，就說明這個ip有可能在攻擊我們的主機，通過多個日誌的組合分析出安全風險。
陳皓(@左耳朵耗子)分享的”組建一支強悍的小團隊”和facebook的精英文化很類似。不過他的分享比較極端，他說在一個團隊裡除了程式設計師，其他的角色都是不幹活的，比如專案經理、產品經理、配置管理員、主管等，他的理由是：團隊大、角色多、流程多、會議多、內耗大，而在專案中需求分析，專案管理，質量保證和運帷程式設計師都能搞定。通過減少角色分工，溝通成本和內耗自然下降。這樣的團隊對人有一定的要求，敏捷是個很好的方法論，但是必須由人來執行。
去年我們團隊開始嘗試向這樣的精英團隊轉型，QA和前端開發逐漸脫離專案，逐漸轉型為負責公共組建的開發，專業培訓和諮詢。比如前端工程師負責開發每個專案都需要使用的前端框架，QA負責開發增加自動化測試速度的工具並對我們的測試用例進行Review和指導。
這樣的團隊很好但打造難，因為對人要求很高，招人和引導非常重要。
其他的分享
妥協等於尊重，因為別人說的東西里有值得學習的地方。有好的想法並且能從中盈利才算創新。
