講述分散式架構雲平臺解決方案

分散式架構雲平臺在充分分析IT技術發展趨勢，遵循集中化、標準化、整合化、可靠化和可擴充套件化的設計原則，以價值創造為使命，以規範化、一體化、智慧化的雲平臺為支撐，實現資訊的透明共享、業務的敏捷協同、管控及時、決策科學為設計目標，選擇傳統成熟的J2EE、SOA、應用整合和BI資訊科技和新一代的雲端計算、大資料、移動應用資訊科技相結合的技術路線。

分散式架構雲平臺規劃設計了：

集約化、雲架構動態配置的企業IT基礎設施；

共享化、集中資料儲存管理的企業資料資源服務；

元件化、平臺化、柔性整合的企業應用支撐服務；

標準化、服務化、整合智慧的企業業務應用服務；

一站式、多終端服務的企業資訊展示互動服務等技術層，每層又包括若干成熟穩定的技術元件，各技術層，自下而上，層層支撐，各技術元件鬆散耦合，互聯互通，科學高效，易於擴充套件，減少了資訊孤島，增強了系統的標準化和集約化，最佳化了系統的使用者體驗，提高工作效率。

分散式架構雲平臺技術設計原則

先進性原則

在整體設計和實現上，依託雲端計算、大資料領域的知名開源專案(如Hadoop、Spark、OpenStack等)。由於遵循了業界廣泛認可的事實標準，可以充分借力全球生態圈的資源，推動軟硬體分層解耦，不斷提升相容性。相容多種異構物理裝置，避免廠商繫結。資料層面，支援多種資料來源，包括結構化/非結構化型別的資料處理，資料本身、資料計算也都支援開放共享。優先採用先進成熟的技術元件，搭建穩定並且高效的大資料雲端計算管理平臺，並在平臺基礎上實現大規模的資料採集與分析的相關業務應用。平臺設計以滿足當前的業務功能為主，兼顧考慮未來發展的趨勢。

可靠性原則

可靠性包括整體可靠性、資料可靠性和單一裝置可靠性三個層次。透過大資料雲端計算平臺的分散式計算、儲存架構，從整體系統上提高可靠性，降低系統對單裝置可靠性的要求；平臺設計方面保證基於hadoop和虛擬化的叢集系統平臺的穩定與高效，提供針對現有底層硬體裝置的Hadoop和虛擬化相關技術元件的調優，以及對於整體叢集的配套監控系統的搭建和叢集維護與管理等相關方案；應用設計方面採用明確的應用分層架構，一方面可實現上層資料應用與底層基礎資料的依賴分離，實現應用架構上的解耦；另一方面可提高上層資料的分析效率與降低執行成本。採用相關的容錯技術和故障處理技術，保證資料應用的安全可靠，保證資料分析平臺可用性達到使用要求。

安全保密性

採用統一的使用者認證，統一的使用者、許可權管理和控制、密碼控制等多種安全和保密措施。為保證資訊的安全性，對內部網上的資訊建立符合安全要求的防火牆、入侵檢測、數字證書、防病毒、資料加密技術等，能夠嚴格有效地防止外來非法使用者入侵，能夠避免遭受網路攻擊，防止失密情況的發生，防止非法侵入帶來的損失。

可擴充套件性

應用開發平臺採用模組化建設和擴充套件模式。支援小規模起步，線性擴充套件，以滿足不同場景，不同投資計劃和規模的要求；隨著資料規模的擴大、應用的完善，現在資料平臺能夠在不影響當前使用者正常使用的情況下，靈活、方便地進行叢集擴容。

開放性

雲端計算平臺是在成熟落地的方案上完全自主研發，主要應用開源技術。

大型網站不是設計出來的，而是逐步演化出來的。因為網際網路發展執行有其自己的規律，網際網路歷史已經一再證明“一開始就把網站設計成大型的”這種企圖行不通。另外，演化過程中，需要分清當前哪個點是瓶頸，需要知道哪個點最佳化的優先順序最高。所以，技術架構的演進不一定就是按文章從頭到尾這樣列下來的，要視具體情況來下決定。

從一個小網站說起，一臺伺服器也就足夠了。演進包括如下：

（1）資料伺服器和應用伺服器分離。給應用伺服器配置更好的 CPU，記憶體。而給資料伺服器配置更好更大的硬碟。

（2）使用快取。因為 80% 的業務訪問都集中在 20% 的資料上，如果我們能將這部分資料快取下來，效能一下子就上來了。空資料也要入快取，否則會增加資料庫的壓力。

（3）nosql。NoSql資料庫大量應用於微博系統等事務性不強的系統。如：BigTable、MongoDB

（4）伺服器叢集。需要考慮：負載均衡問題? 負載均衡排程伺服器，如nginx。Session 的管理問題。如何讓上傳檔案這些類似的功能繼續正常？採用檔案伺服器統一管理。

（5）資料庫讀寫分離。訂閱和釋出。實現一個資料訪問模組使上層寫程式碼的人不知道讀寫分離的存在。需要考慮：時延問題。MySQL資料同步是透過binlog日誌。延遲問題透過水平拆分服務來提高效能、多執行緒同步解決。

（6）資料庫拆分。垂直拆分資料庫時，會遇到的問題：跨業務的事務，應用的配置項多了。資料水平拆分會遇到的問題：SQL 的路由問題，需要知道某個 User 在哪個資料庫上。主鍵的策略會有不同。查詢時的效能問題，如分頁問題。

（7）CDN。分散式檔案系統使用 CDN 。將網站的內容釋出到最接近使用者的網路”邊緣”，使使用者可以就近取得所需的內容，解決Internet網路擁塞狀況，提高使用者訪問網站的響應速度。據統計，採用CDN技術，能處理整個網站頁面的 70%～95％的內容訪問量，減輕伺服器的壓力，提升了網站的效能和可擴充套件性。異地部署一般遵循：核心集中，節點分散。如：網宿、睿江、藍訊，將網站內容同步到全國CDN節點，客戶就近訪問CDN伺服器。

（8）分散式拆分。網站的業務日益複雜，建立一個獨立的大型應用來完成這所有的業務變得不實際。從管理角度來，也不方便管理。將系統根據職責進行拆分，同時也能採用大量的廉價機器來支撐著巨大的訪問量和資料量。微服務架構的優勢很明顯：耦合度低、技術選型靈活、釋出更加高效、故障隔離。拆分會碰到很多的挑戰：1、拆成分散式後需要提供一個高效能、穩定的通訊框架，並且需要支援多種不同的通訊和遠端呼叫方式；2、將一個龐大的應用拆分需要耗費很長的時間，需要進行業務的整理和系統依賴關係的控制等；3、如何運維（依賴管理、執行狀況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分散式應用。

（9）大系統小做。將功能複雜較大的系統，化大為小，減少模組耦合，降低關聯性。分成一個個高度自制的小系統，形成高內聚低耦合的格局，每個模組之間不會過分依賴對方，這樣的好處是不會因為任何一個模組而影響全部服務，避免牽一髮動全身的風險，實現真正的灰度服務。

（10）硬體負載均衡。一臺Nginx伺服器的軟負載已經無法承擔巨大的web訪問量了，可以用硬體負載解決F5或應用從邏輯上做一定的分類，然後分散到不同的軟負載叢集中。

分散式關鍵技術

業務方式，以蘇寧易購線上直播購物轉化為例：

（1）前端緩衝請求。

（2）後端採用非同步分拆。

（3）快速拒絕。

（4）流量預載入。

（5）資源隔離。

（6）根據業務場景降低影片質量。

（7）回滾機制會造成業務邏輯複雜，容易出錯，可能會出現漏洞。我們應該提高服務的簡單性、高可用性，減少出錯率。對於極少的錯誤，後續對日誌進行單獨處理即可。