一，圖片體驗的優化。
在手機上顯示圖片，速度是一個非常重要的體驗點，試想，如果您打開一個網站，發現里面的圖片一直顯示失敗或者是x，稍微做得好一點的，可能是一個不消失的loading或者是菊花等等，但不管如何， 沒能快速的拉取和展示圖片對用戶體驗是一個極大的挑戰。那么，手機上的圖片體驗如何做呢？這里筆者有些小總結：
1，減少圖片的大小。在失真度和圖片大小中做好折衷，盡量利用工具減少圖片的size，也可以考慮利用不同的圖片格式。
2，減少圖片的請求數。可以考慮把多個圖片利用類似css sprite的方式進行合並，這樣可以加載一次即可；
3，考慮緩存。對圖片在客戶端進行一定的緩存，設置好緩存時長和更新機制；
4，考慮使用cdn進行加載圖片，做到就近接入訪問；
5，解決DSN劫持的問題。在手機業務上的經驗告訴我們，很可能某些地區，某些運營商把我們的域名封掉或者劫持了，這樣，圖片的域名解釋出來的IP卻不是我們提供圖片服務的IP，並且這種情況很難發現， 因為，如果運營商通過抽樣隨機劫持，就很難發現。
解決辦法有幾個思路：
.去掉dns，改成直接訪問IP的方式，但需要解決根據用戶的ip獲取最近圖片服務的ip地址，實現上：這里cgi在吐出訪問圖片的地址的時候，獲取用戶的來源網關IP，調用IP地址庫判斷來源IP所屬地和運營商，然后下發對應的圖片部署接入IP， 客戶端使用IP直連圖片服務器，快速的訪問資源。問題是，有實現成本，得業務自己去實現類似一個dns解釋的邏輯 ，特別是圖片放到cdn的話，這樣改造就無法使用cdn帶來的加速服務能力。
.做好dns劫持的監控，實際上圖片dns解釋到的vip list肯定是在我們的一個白名單內，如果不是，則肯定屬於dns劫持，客戶端可以在某個時候拉取一下我們的viplist，作為監控和判斷是否dns劫持的問題，如果dns的ip地址 不在白名單內，則替換使用白名單內的ip進行訪問。
.考慮備用域名的方式，即如果一個域名拉取不到，改用備用域名進行訪問，當然如果備用域名也被劫持，那就不行了。
二，優化后台的架構
后台返回越快，前端的體驗就越好，因此，也需要對后台服務的調用鏈進行梳理，避免循環調用，快慢混雜等問題，基本的原則比較簡單，都是一些設計方面的原則
1、輕重分離。服務中把訪問量大，需要速度快的服務和訪問量小，但業務邏輯復雜的流程從代碼實現和物理部署上進行徹底分離，如用的接入cgi（甚至不同的域名），不同的后台server，不同的集群進行隔離。
如果放在一起，慢的會拖住快的，這就像木桶原理一樣，最終的速度是由最慢的決定的，如果處理不好，可能導致整個服務堵塞不可用。
2、考慮異步化。異步化相比同步的實現來說稍微復雜一些，或者說需要做的工作可能多些，但異步化的好處也會非常明顯，特別是需要高性能的業務流程。常見的異步化實現策略是借助mq作為各個系統的緩沖， 生產者進程或者子系統把消息寫入mq即可立即返回，而消費者進程或者子系統則定時從mq讀取消息繼續處理，並且把處理的結果通過回調通知或者寫入返回mq給到生產者查詢。當然，如果生產者是不關注結果的，那 就更加簡單了，丟到MQ后即可，這里的問題是整個mq是整個業務流程的關鍵，需要確保服務的高度可用和性能。
3.做好外部依賴的管理。一個業務流程可能往往要調用到外部的系統，並且這些系統可能不是你們團隊維護的，如果該系統是非關鍵路徑還好，如果是關鍵路徑，那么做好對外部依賴的管理就顯得更加重要了，那么如何做好外部依賴的管理呢？
這里有幾個小的tips:
. 對外部調用的服務單獨進行封裝，如設計單獨的proxy去調用外部的服務，這樣的好處是方便集中監控和容災邏輯等處理，在設計上把外部因素進行物理隔離的第一步，后續如果外部系統的協議或者ip地址得發生變化，則可以只修改該模塊即可 快速修復；
. 嚴重建議對外部接口進行錯誤和超時的監控，一旦出問題，提前預警並快速解決，這里是有血的教訓的，某業務和某平台提供者雙方在糾結是誰的問題上吵得不可開交，不知道是誰的問題，業務說自己沒問題，平台方說自己的服務也很快，如果 你能夠拿出你的監控數據，接口超時設置是 1s, 超時的記錄有n條，時間是ns，錯誤的記錄有m條，主要錯誤類型是xxx，那對快速定位是非常有幫助的。