883
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需要謹慎和專業，把一件技術吃透再運用。用數據說話，沒有任何數據支撐，不要輕易做改版和新功能。要快，避免大團隊，小團隊攻堅，要敏捷但不要照搬敏捷的步驟。
讓團隊更敏捷。讓大家坐在一起，讓團隊成員在團隊之間輪崗，減少會議，減少溝通成本。
不要輕易用新技術。因為業界大多數成熟的公司並不是不斷的用新技術，而是把已有技術用得非常登封造極，新技術也會逐漸變成老技術的。
最後，不想做CTO的架構師不是好程序員。
聚劃算的分享
大對象的存儲方案：大量用戶登陸到聚劃算，聚劃算需要通過IP定位到用戶的城市，像IP庫這種非常大的對象，如果使用Redis存的話會有很高的網絡開銷，所以聚劃算將這些大對象存在本地JVM的內存中,然後在不同的服務器之間通過消息同步大對象裏的數據。
分布式任務係統：通過一個第三方服務器來管理所有的任務，使任務能分別在不同的機器上運行，可以通過鎖來實現，拿到當前任務鎖的機器才能執行當前任務。
緩存擊穿攻擊問題：如果有用戶訪問淘寶不存在的產品id，那麼係統每次都會繞過緩存直接訪問數據庫，解決方案是可以通過在緩存裏標示該商品不存在來防止。在微博裏校長回複說，CDN也有這樣的問題，比如使用404攻擊，通常類似的問題5-20秒的cache就足夠了。
Paypal的分享
Paypal的演講嘉賓一上台先來一支騎馬舞熱熱場，很歡樂。Paypal主要分享CEP。 CEP是複雜事件處理的意思，是數據庫的反方向，從數據庫裏查數據是使用查詢語句拿到結果，而CEP是把數據發到一個地方然後得到結果。
Paypal嘉賓分享的CEP感覺和我以前做的安全日誌分析有點像。安全日誌分析可以基於狀態，統計，行為等手段進行分析。基於狀態機的日誌分析， 比如1號有某帳號不停嚐試登陸的日誌，10號有這個帳號在操作某台機器的日誌，就說明這個ip有可能在攻擊我們的主機，通過多個日誌的組合分析出安全風 險。
組建一支強悍的小團隊
陳皓(@左耳朵耗子)分享的”組建一支強悍的小團隊”和 facebook的精英文化很類似。不過他的分享比較極端，他說在一個團隊裏除了程序員，其他的角色都是不幹活的，比如項目經理、產品經理、配置管理員、 主管等，他的理由是：團隊大、角色多、流程多、會議多、內耗大，而在項目中需求分析，項目管理，質量保證和運帷程序員都能搞定。通過減少角色分工，溝通成 本和內耗自然下降。這樣的團隊對人有一定的要求，敏捷是個很好的方法論，但是必須由人來執行。
去年我們團隊開始嚐試向這樣的精英團隊轉型，QA和前端開發逐漸脫離項目，逐漸轉型為負責公共組建的開發，專業培訓和谘詢。比如前端工程師負責開發每個項目都需要使用的前端框架，QA負責開發增加自動化測試速度的工具並對我們的測試用例進行Review和指導。
這樣的團隊很好但打造難，因為對人要求很高，招人和引導非常重要。
其他的分享
妥協等於尊重，因為別人說的東西裏有值得學習的地方。有好的想法並且能從中盈利才算創新。
文章轉自 並發編程網-ifeve.com
最後更新：2017-05-23 10:32:34