從老馬那摳出點東西,由於是個視頻,沒有文檔資料,遂觀後做下總結,以便以後自己遇到優化的時候可以考慮考慮這些方面,下麵我將總結的寫出來,供大家分享,可能有不對的地方希望指出 一.SOA服務的粒度的把控: 建議:服務在設計時應該是自上而下或者在服務開發之前做相應的調整,儘量的保證服務粗粒度化,這樣就能減
從老馬那摳出點東西,由於是個視頻,沒有文檔資料,遂觀後做下總結,以便以後自己遇到優化的時候可以考慮考慮這些方面,下麵我將總結的寫出來,供大家分享,可能有不對的地方希望指出
一.SOA服務的粒度的把控:
建議:服務在設計時應該是自上而下或者在服務開發之前做相應的調整,儘量的保證服務粗粒度化,這樣就能減少前端的調用次數,當然這跟減少頁面的http請求的效果是一致的.另外現在通過UML序列圖的方式也綜合了自上而下的開發方式,為底層業務模型修改完善提供了更好的契機,那麼在開發的時候也可以進一步去討論需要公開的服務,補充上粒度比較細的那一部分.也就是說先把握大局從上到下,然後把握住細節從下而上.
二.介面的定義:
介面是否代表了業務,是否是合適的粒度,是否會有性能問題,別小看介面設計,一旦確定以後很難修改,介面的好壞決定成敗.所以介面的設計很重要.介面設計的好壞也直接影響到了性能問題.
三.圖片伺服器跟web伺服器分離
目前圖片伺服器跟web伺服器在同一臺及其上,圖片的訪問量非常大,而沒有經過壓縮和縮略圖等處理,當然圖片的處理我們後面細說.圖片的請求占用資源比較多,而主web請求占用事件比較端,而在請求隊列中等待的時間卻很長,圖片的請求嚴重影響了web的正常註冊和找回密碼等請求.建議:圖片和web伺服器分開,web站點加一些客戶端緩存,以及服務端緩存等技術,將請求的處理提高一些併發性能,用apachebench測試我們的請求併發處理是4個/s,通過緩存相信能提高至少10倍.
四.關於圖片處理:
建議:前端壓縮和處理圖片,後臺取圖片時根據前端需要生成對應的縮略圖[第一次,後面直接返回]並返回,建議圖片的名字中可以做些文章加入一些元數據等記錄圖片的存放位置,格式,時間,大小,類型等,後面擴展時可以直接通過圖片名訪問對應的key資料庫,獲取到具體路徑[可以參考淘寶的圖片文件系統:tfs],圖片文件傳輸的時候可以做壓縮,但要考慮到壓縮解壓縮需要的cpu資源,在IO(磁碟,帶寬,傳輸能力)和CPU之間有一個平衡的考慮
五.關於分散式事務性能問題的探討
由於在soa架構的系統中,服務級別的分散式事務由於占用事務鎖的事件比較長,併發大的時候很容易導致死鎖.建議:採用非同步隊列的方式解決必須有事務保證的數據操作.分散式事務的替代方式是採用隊列,放到隊列中的東西就認為是一定可以成功的,對於不使用隊列的情況,如果調用失敗了則記錄日誌,不會進行回滾.除非涉及到錢或者非常中的數據的地方纔做分散式事務
六.關於緩存
建議:分散式緩存可以考慮使用Nosql db比如:MongoDB,此Nosql資料庫併發性能非常好,而且可以簡易的進行分散式部署,節點很容易進行擴展,另外當我們對資料庫的操作和查詢都是直接面對的數苦苦,而中間沒有響應的一級二級緩存,導致壓力還是直接給了資料庫,性能的瓶頸最終在資料庫端有所體現
七.關於資料庫
資料庫要求非常高,cpu和記憶體消耗都比較大,另外對IO的讀寫也要求比較高,當前資料庫的分配應該還算可以了.後面我們設計EDMX或者設計業務時,儘量考慮後期能進行的垂直分庫,水平分庫等.另外就是資料庫集群一定要利用起來,不管是發佈,訂閱,鏡像等技術實現讀資料庫間數據同步,一定在平臺級別解決讀寫分離
八.關於日誌
異常時我們才需要日誌,而正常的操作日誌可以通過行為分析等組建進行記錄,而並不需要記錄浪費性能[文件太大,十分占用磁碟的IO和磁碟的空間],而關閉日誌我們又捕捉不到異常,所以日誌這個還是需要我們平臺或者項目進行考慮一個解決方案.
總結
一切都是為了性能,穩定行,可維護性,儘量保證節點保持簡單邏輯,儘量減少同一層節點之間依賴,並實現功能分解,使用非同步進行整合,故障轉移,失效保護.數據方面實現讀寫分離,資料庫分離,功能劃分,緩存,鏡像.最終理想的可伸縮性架構是可以自由增加或替換伺服器,無需去停機維護或做很大的調整.
