data- 校驗 梳理 推送 嚴重 決定 服務端 文章 預警

版權聲明：本文為博主原創文章，未經博主同意不得轉載。 https://blog.csdn.net/tenfyguo/article/details/34107629 一。圖片體驗的優化。

? ? ? ?在手機上顯示圖片。速度是一個非常重要的體驗點。試想，假設您打開一個站點，發現裏面的圖片一直顯示失敗或者是x。略微做得好一點的，可能是一個不消失的loading或者是菊花等等。但無論怎樣，?沒能高速的拉取和展示圖片對用戶體驗是一個極大的挑戰。那麽，手機上的圖片體驗怎樣做呢？這裏筆者有些小總結：

? ? 1，降低圖片的大小。

在失真度和圖片大小中做好折衷，盡量利用工具降低圖片的size。也能夠考慮利用不同的圖片格式。

? ? 2，降低圖片的請求數。能夠考慮把多個圖片利用相似css sprite的方式進行合並，這樣能夠載入一次就可以；
? ? 3。考慮緩存。

對圖片在client進行一定的緩存。設置好緩存時長和更新機制；
? ? 4。考慮使用cdn進行載入圖片，做到就近接入訪問；
? ? 5，解決DSN劫持的問題。在手機業務上的經驗告訴我們，非常可能某些地區，某些運營商把我們的域名封掉或者劫持了，這樣，圖片的域名解釋出來的IP卻不是我們提供圖片服務的IP，而且這樣的情況非常難發現，? 由於，假設運營商通過抽樣隨機劫持，就非常難發現。解決的方法能夠：

?.去掉dns。改成直接訪問IP的方式，但須要解決依據用戶的ip獲取近期圖片服務的ip地址。實現上：這裏cgi在吐出訪問圖片的地址的時候，獲取用戶的來源網關IP。調用IP地址庫推斷來源IP所屬地和運營商，然後下發相應的圖片部署接入IP，?client使用IP直連圖片服務器，高速的訪問資源。

? 問題是，有實現成本，得業務自己去實現相似一個dns解釋的邏輯，特別是圖片放到cdn的話。這樣改造就無法使用cdn帶來的加速服務能力。

??

?.做好dns劫持的監控，實際上圖片dns解釋到的vip list肯定是在我們的一個白名單內，假設不是。則肯定屬於dns劫持。client能夠在某個時候拉取一下我們的vip list，作為監控和推斷是否dns劫持的問題，假設dns的ip地址?不在白名單內。則替換使用白名單內的ip進行訪問。
??

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

? ?6，不用圖片，考慮文本替代方案。

? ?
二。優化後臺的架構
? ? ?後臺返回越快，前端的體驗就越好。因此。也須要對後臺服務的調用鏈進行梳理，避免循環調用，快慢混雜等問題，主要的原則比較簡單，都是一些設計方面的原則
? ?1，輕重分離。服務中把訪問量大，須要速度快的服務和訪問量小，但業務邏輯復雜的流程從代碼實現和物理部署上進行徹底分離，如用的接入cgi（甚至不同的域名），不同的後臺server。不同的集群進行隔離。
? ? ? 假設放在一起，慢的會拖住快的。這就像木桶原理一樣，終於的速度是由最慢的決定的。假設處理不好。可能導致整個服務阻塞不可用。
?
? ?2，評估好業務的訪問流程和路徑設計。區分關鍵路徑和非關鍵路徑，設計上盡量考慮把關鍵路徑轉換為非關鍵路徑，關鍵路徑須要有多級容災的考慮。非關鍵異常須要有監控。
? ?
? ?3。考慮異步化。異步化相比同步的實現來說略微復雜一些。或者說須要做的工作可能多些，但異步化的優點也會非常明顯，特別是須要高性能的業務流程。

常見的異步化實現策略是借助mq作為各個系統的緩沖。?生產者進程或者子系統把消息寫入mq就可以馬上返回。而消費者進程或者子系統則定時從mq讀取消息繼續處理，而且把處理的結果通過回調通知或者寫入返回mq給到生產者查詢。當然。假設生產者是不關註結果的。那?就更加簡單了，丟到mq後就可以。這裏的問題是整個mq是整個業務流程的關鍵。須要確保服務的高度可用和性能。

?
? ?4，一些配置的動態載入，本地化存儲，加上基於版本號的更新機制。筆者也發現過有些業務cgi之所以在較少請求量的時候就出現了較高的負載，終於不得不用很多其它的機器來承擔相應的請求量，定位終於原因是cgi在啟動的時候須要載入?非常多配置的東西，甚至非常多配置並非該cgi須要的，優化思路是：是按需載入。僅僅載入該cgi須要的。提前載入配置到共享內存，同一時候添加版本號號，維護好cgi自身進程的私有版本號和共享內存的版本號，cgi啟動的時候比較版本號號，發現不同。則?真正進行文件的又一次Load到內存。另一種模式是採用配置中心進行推送的模式，實現集中管理。
?
? ?5，做好外部依賴的管理。

一個業務流程可能往往要調用到外部的系統，而且這些系統可能不是你們團隊維護的，假設該系統是非關鍵路徑還好，假設是關鍵路徑，那麽做好對外部依賴的管理就顯得更加重要了，那麽怎樣做好外部依賴的管理呢？
? ? ? 這裏有幾個小的tips:

?. 對外部調用的服務單獨進行封裝。如設計單獨的proxy去調用外部的服務。這樣的優點是方便集中監控和容災邏輯等處理。在設計上把外部因素進行物理隔離的第一步。興許假設外部系統的協議或者ip地址得發生變化。則能夠僅僅改動該模塊就可以?高速修復。

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

?. 考慮能否夠弱化為非關鍵路徑？有些調用可能是否無法弱化為非關鍵路徑的，如登錄態校驗，失敗了僅僅能是業務流程終止，給用戶返回失敗（當然可能存在部分業務緩存session id作為異常的時候的備用，但這個不是非常建議，原因非常easy，可能導致入口?不唯一。甚至造成安全漏洞，這裏須要詳細案例詳細分析）。有些路徑是能夠設計為非關鍵路徑的，如數據上報，

?. 關鍵路徑的多級灰度模式。假設知道某個服務是關鍵路徑，比方在支付前的請求billno_server獲取唯一的訂單號。從業務流程看。這個肯定是一個關鍵路徑，沒有訂單號就無法下單，業務流程運行不下去，但假設每次下單都調用一次billno_server生成?一個訂單號。偶爾的網絡超時或者失敗都是可能的，而對用戶來說，就是此次下單提示大家都非常熟悉得不能熟悉的一句話：“系統繁忙，請稍後再試”。那麽能否夠做得更好呢？或者至少降低這樣的概率呢? 一種思路是每次請求一批billno緩存到本地進程空間， 然後使用的時候先從本地緩存中取，沒有了再去請求；一種是請求失敗的時候，能否夠考慮用本地隨機生成一個，在極端情況下弱化對該關鍵路徑的依賴？

?. 若關鍵路徑的數據唯一來源是本業務，則能夠考慮自建部分熱點數據，一點出現故障，則切換到自建的部分熱點數據，繼續提供服務。

? ?6，考慮到手機client的計算能力比較弱。在設計上是否把計算成本很多其它的往服務端移動，利用強大的服務器端計算能力提升用戶體驗，這一點也是微信架構設計給筆者的一個感受。
? ?
?三，優化鏈接
? ? ?怎樣管理鏈接是一個老生常談的話題了。這裏主要長連接和短連接的問題。

當然另一些什麽連接池等策略。

?
? ? ?弱網絡環境下，建立鏈接的時間非常長。網絡質量測試數據顯示。建立鏈接占用耗時接近1/3，走短鏈接又導致鏈接頻繁，所以考慮將短鏈接改成長鏈接。在碎片時間內反復利用，降低建鏈耗時。此外，還有下面幾個優點：?

? ? ?1，C/S的持續鏈接使得後端能夠主動push重要數據到client，比如實時的通知，新數字提醒等等，能非常好的改善體驗。在短鏈接的情況下，僅僅能依靠client進行定時輪詢。不可避免的使新數據有所延遲。

?

? ? ?2，進一步節省短鏈接過程中的包大小，短鏈接情況下。每次來回請求，都不可避免須要帶上一些公共數據。

長鏈接僅僅用在建鏈接成功後的第一個包中上行這些數據，興許包則能夠省掉這些字段，進一步降低流量；?

? ? ?3，長鏈接還能有效的降低流量限制類手機軟件導致服務不可用的問題。有些流量限制類軟件會接管用戶的全部網絡請求，以達到流量計算和斷流的目的，這樣的本質上就是一種劫持，使用長鏈接+私有加密協議，?能夠使得對方無法準確分析包情況。降低劫持到來的服務不可用情況。

? ? ?4。長鏈接還能夠降低在高並發下對暫時port的依賴，有些使用短鏈接的服務，在高並發下，發現暫時port不可用的問題也能夠通過長鏈接得到緩急。

?
?
? ? ?註意：使用長鏈接的時候，必定有長鏈接過期不可用的情況，因此，業務實現須要埋入重連機制。
?
?四。基於網絡質量的多級服務設計
? ? ?手機的網絡環境比較多樣，如wifi, 3G, 4G 還有2G等，不同的網絡環境的體驗是不同的，對非常好的網絡環境我們就不說了，關鍵討論一下在2G等比較惡劣的情況下的一些思考。

1。不同的網絡環境是否具備多級的服務能力？如針對2g網絡的用戶，顯示的內容更少? 圖片變成文字？一些功能入口不可用？

2，降低網絡協議包的大小。在網速非常慢的情況下，包的大小至關重要。直接影響成功率，能夠考慮更加緊湊的協議（包含不必要的字段不發送）+壓縮算法。這裏有個tips，大家知道cookie的內容都是每次跟在http請求一起發送給到服務器的。?對圖片，js，ccs等建議部署其它域名進行cookie隔離，這樣也能夠降低一定的包大小。

?
?

移動互聯網的架構設計淺談一