優化滴滴點點

半夜裏展轉反側，將系統優化的滴滴點點記錄成案

 

1.服務粒度儘量的粗粒度化

爲何這麼說？若是開發過程當中 咱們直接設計EDMX模型，以後設計服務，這種自下而上的模式致使系統中不少的服務，服務力度的把控天然不是很好，好比說一個登錄，客戶端須要調用四或五個服務才能完成登陸操做，直接帶來性能問題，還有可能帶來重複性的開發,【建議:服務設計自上而下,契約優先原則，以業務邏輯進行劃分，儘量的粗粒度化，這樣減小服務調用次數，這與減小客戶端Http請求效果是一致的，固然不可能完美的作到粒度的把控,須要在後續開發中補充粒度比較細的部分，或者討論某些服務公開的必要性】

 

2.單臺服務器狀況下圖片、文本等靜態資源的優化

只有單臺服務器的狀況下，保證圖片資源與Web服務在不一樣的域名下，主要是爲了減小在訪問圖片等靜態資源時發送Cookie等沒必要要的信息

再者對圖片進行壓縮或者縮略圖的形式處理，減小帶寬消耗

 

3.Web服務與圖片服務器的分離

這裏強調下爲何有作服務器分離的必要:當主Web請求與圖片請求在一臺機器上時，圖片請求佔用資源多，web請求佔用時間短，但web請求隊列等待時間卻很長,圖片請求嚴重影響Web正常訪問,【建議:圖片與Web服務器分開，固然，圖片服務器部署在輕量級的Web服務器(例如Nginx)更理想,同時添加客戶端緩存、服務端緩存提升響應效率】

 

4.圖片的處理

客戶端上傳圖片時進行壓縮處理，服務器針對圖片作分佈式的存儲，不清楚的可 參見《視頻/圖片集羣化存儲》這裏有實現的思路  請求圖片時也能夠壓縮處理，可是消耗CPU，這裏須要在帶寬等資源與CPU資源之間尋找一個平衡點 (讀者有興趣能夠了解淘寶開源文件系統:TFS 章文蒿博士主導)

 

 

5.關於分佈式事務性能

分佈式系統中最難處理的就是事務這一塊了,soa架構系統中 服務級別的分佈式事務因爲佔用事務鎖時間比較長，大併發量時容易致使死鎖【建議：根據事務的重要性作不一樣的處理，服務不須要事務狀況下使用異步方式處理。須要事務狀況下使用隊列替代分佈式事務(隊列是解決死鎖的經常使用途徑) 隊列執行失敗，只會記錄日誌，不會進行回滾操做。只有重要的事務(通常涉及敏感數據時)再作分佈式事務】

 

 

6.緩存

分佈式緩存除了Memcached,  Memceche使用案例《Memcache+Cookie替代Session解決方案(MVC版)》 也能夠考慮使用MongoDB等非關係型數據庫處理，由於NoSql數據庫併發性能很是好，並且很容易的作到分佈式部署，節點易擴展

 

7.數據庫

硬件層面:由於數據庫對CPU、內存、IO要求都比較高，通常都會作數據庫的集羣，基於同步機制作數據庫的讀寫分離。主庫去掉外鍵、去掉非必要索引，從庫添加索引。

業務層面:在業務設計時，儘可能多考慮後期能進行垂直分庫，水平分庫等

 

代碼層面:

    使用緩存減小查詢次數,

    批量提交數據減小數據庫交互次數

    只取用到列數據 避免select *

    SQL語句的優化

 

    

 

8日誌

系統日誌主要存在併發的問題，尤爲WCF只有一個日誌文件，這時咱們能夠新建異常消息隊列，系統運行時開啓一個監聽,監聽異常消息隊列，將消息隊列中異常信息寫入日誌或者NoSql類型數據庫，固然不止這一種解決方案

 

 

9關於硬件的分配

不一樣服務器不一樣配置要求

數據庫服務器：內存、cpu、磁盤讀寫要求高

應用服務器：內存和CPU要求高

圖片等靜態資源服務器:磁盤、帶寬要求比較高

Web主站點：帶寬、cpu、內存要求高

當硬件不足狀況下合理分配服務，避免資源爭搶

 

總結的比較粗獷,也有一時未想起的方面，此文考慮後續更新