APP系統架構設計初探

一，圖片體驗的優化。

    在手機上顯示圖片，速度是一個很是重要的體驗點，試想，若是您打開一個網站，發現裏面的圖片一直顯示失敗或者是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進行訪問。

  

     .考慮備用域名的方式，即若是一個域名拉取不到，改用備用域名進行訪問，固然若是備用域名也被劫持，那就不行了。

二，優化後臺的架構

     後臺返回越快，前端的體驗就越好，所以，也須要對後臺服務的調用鏈進行梳理，避免循環調用，快慢混雜等問題，基本的原則比較簡單，都是一些設計方面的原則

   一、輕重分離。服務中把訪問量大，須要速度快的服務和訪問量小，但業務邏輯複雜的流程從代碼實現和物理部署上進行完全分離，如用的接入cgi（甚至不一樣的域名），不一樣的後臺server，不一樣的集羣進行隔離。

      若是放在一塊兒，慢的會拖住快的，這就像木桶原理同樣，最終的速度是由最慢的決定的，若是處理很差，可能致使整個服務堵塞不可用。

     二、考慮異步化。異步化相比同步的實現來講稍微複雜一些，或者說須要作的工做可能多些，但異步化的好處也會很是明顯，特別是須要高性能的業務流程。常見的異步化實現策略是藉助mq做爲各個系統的緩衝， 生產者進程或者子系統把消息寫入mq便可當即返回，而消費者進程或者子系統則定時從mq讀取消息繼續處理，而且把處理的結果經過回調通知或者寫入返回mq給到生產者查詢。固然，若是生產者是不關注結果的，那 就更加簡單了，丟到MQ後便可，這裏的問題是整個mq是整個業務流程的關鍵，須要確保服務的高度可用和性能。

3.作好外部依賴的管理。一個業務流程可能每每要調用到外部的系統，而且這些系統可能不是大家團隊維護的，若是該系統是非關鍵路徑還好，若是是關鍵路徑，那麼作好對外部依賴的管理就顯得更加劇要了，那麼如何作好外部依賴的管理呢？

      這裏有幾個小的tips:

     . 對外部調用的服務單獨進行封裝，如設計單獨的proxy去調用外部的服務，這樣的好處是方便集中監控和容災邏輯等處理，在設計上把外部因素進行物理隔離的第一步，後續若是外部系統的協議或者ip地址得發生變化，則能夠只修改該模塊便可 快速修復；

     . 嚴重建議對外部接口進行錯誤和超時的監控，一旦出問題，提早預警並快速解決，這裏是有血的教訓的，某業務和某平臺提供者雙方在糾結是誰的問題上吵得不可開交，不知道是誰的問題，業務說本身沒問題，平臺方說本身的服務也很快，若是 你可以拿出你的監控數據，接口超時設置是 1s, 超時的記錄有n條，時間是ns，錯誤的記錄有m條，主要錯誤類型是xxx，那對快速定位是很是有幫助的。