溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章為大家展示了如何在云計算平臺中構建大規模分布式系統，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
如何利用云計算平臺的彈性，結合業務自身特點，設計和構建一個高可用、高伸縮性的后端系統架構。同時會以 QingCloud 平臺上的真實案例為背景，講述從簡單后端系統到大規模分布式系統的演進之路。
很多企業和開發者在開發一款產品時，首要考慮的是產品功能的實現，其后端架構通常都是非常簡單直接的。產品在剛上線初期，由于用戶訪問壓力很小，數據量積累也并不大，在短時間內都會運行良好。
然而如今移動互聯網的普及和成熟，讓一款產品很可能在短時間內聚集大量用戶，面對流量激增、數據量翻番、訪問量指數級攀升等諸多“煩惱”，這本來是一件好事，可是如果后端系統不能及時擴展，勢必會造成響應緩慢，頻繁出錯甚至拒絕服務的情況。
即便沒有上述系統壓力突然增大的“煩惱”，產品在不斷開發升級的過程中，各種功能模塊會變的越來越復雜，如果不能很好的梳理和組織后端架構，系統出錯崩潰、不可使用的風險也會越來越大。
在沒有云計算的時代，物理硬件從采購、上架、插線，到安裝、調試、部署，再到真正投入使用，是一個漫長而耗費人力的過程，往往跟不上系統緊急擴容的節奏。而云服務的出現不僅僅讓我們節約了使用成本，更重要的是可以利用云計算極度彈性的特點，讓企業和開發者根據需求，對系統進行在線快速的擴容。
但僅僅在云服務上快速擴容是不夠的，企業也需要在業務層面，關注各個系統組件的可用性和伸縮性。接下來我來給大家介紹如果利用云計算的優勢，結合企業的業務特點構建穩定可靠的分布式系統。
首先我們從一個最簡單的后端架構開始：
接入層：nginx 業務層：Java application 數據層：MySQL
在云計算環境中，網絡架構的組織非常重要，QingCloud 提供了基礎網絡和 VPC 兩種網絡，他們的區別在官網用戶指南和以前的文章中已經介紹，這里不贅述。推薦企業使用 VPC 來構建自己的網絡，將所有主機和系統資源放置在 VPC 網絡中，指定內網網段（如 192.168.x.x / 172.16.x.x），主機可以通過內網地址進行通信，該地址不會變化。
隨著主機越來越多，IP 地址不易記憶，為了方便主機間相互識別，可以給每臺主機設置內網別名。為方便在控制臺管理，給每個資源打上標簽，按照標簽來組織分類。
接下來我們回到上面那個簡單的后端架構。隨著訪問壓力越來越大，單臺 nginx + Java application 可能不足以應付，你會看到這臺主機的 CPU 越來越忙 ，內存使用越來越多。而且這臺主機一旦故障，整個服務都不可用了。
所以我們首先調整這里的結構，增加多臺 nignx + Java application 同時提供服務，在接入層引入負載均衡器（下文用 LB 這個詞代替），使外網請求首先發到 LB 上。LB 的選擇有很多，比如提供七層負載能力的 nginx 和 HAProxy，也有提供四層負載能力的 LVS，安裝和配置的方法各有不同。
LB 的引入可以分攤請求壓力到后端的多臺業務服務器，并且可通過心跳檢查，自動隔離后端出現故障的服務器，實現業務層的高可用。但這時 LB 本身也會成為一個單點，當出現故障也會導致全局不可用。所以可以使用 Keeplived 服務為 LB 提供一個副本，在一臺出問題的時候可以馬上頂上，部署方法網上有很多資料。
有人會說可以通過 DNS 輪詢到不同的 IP ，實現 LB 的高可用，但事實上這樣不行，因為一旦一臺 LB 掛掉，DNS 還會解析到這個 LB，此時即便馬上修改 DNS，在 DNS 緩存更新之前（通常要很久），服務也是不可用的。
雖然 LB 的原理并不復雜，但是部署配置有很多工作量，而且為了實現 LB 的高可用還要額外做一些事情。QingCloud 從北京3區開始提供了高性能、高可用的 LB 集群服務，可以直接拿來使用。
接下來我們來思考業務層的擴展問題。首先要解決如何快速擴充業務服務器。如果業務服務器的運行環境和程序不會頻繁更新，可以基于已有的業務服務器制作主機映像，當需要擴容時，直接基于映像創建新的主機，掛接到 LB 后端就可以馬上對外服務了。
此時你還可以使用 AutoScaling 功能自動化這一過程，即當到達某種觸發條件，如 LB 并發數、響應延遲達到多少后，自動觸發主機的擴容。當觸發條件不滿足時，可以回收資源。
當然如果你的業務服務器的環境或程序需要頻繁更新，不適合做成固定模版。此時可以自己搭建自動化部署（如 Puppet / Ansible）實現業務自動擴容，這一切操作可以使用 QingCloud 的開放 API 接口，結合你的自動化部署程序完成。
此外你還需要保證業務服務器是無狀態的，因為每次 LB 請求的后端可能不同，不能假設上一次請求和這一次請求落在同一臺業務服務器上。如果服務器需要保存用戶訪問的 session 信息，可將其下放到緩存或數據庫中存儲。
隨著產品功能越來越豐富，你會發現原有單一的業務項目越來越龐大，各種功能邏輯交織在一起，當一個功能出現故障，可以引發全局不可用。此時你需要考慮將單一的業務項目分拆成多個獨立子服務。子服務之間可以基于消息的通信，亦或基于 RPC 的通信方式。
子服務的調用可分為需同步處理和可異步處理兩類。你應該盡量異步化所有不需要馬上返回結果的請求。對于可異步處理的請求，我們通過引入消息隊列，為請求產生的數據做緩沖，請求的接收者（隊列消費者）可根據隊列中任務的數量做水平擴容。消息隊列的選擇有很多，例如 Redis, RabbitMQ, ActiveMQ, Kafka，QingCloud 平臺上目前已經提供分布式、可分區、多副本的消息隊列服務，具有高吞吐量、低延遲等特點，用戶可以方便的集成到自己的系統中。
如今數據分析對于企業越來越至關重要，業務服務器在處理請求的過程中，可以將原始數據通過隊列，源源不斷地導入大數據處理系統，QingCloud 提供完善的大數據分布式處理平臺 Spark 和 Hadoop，用戶可以根據需求方便的創建，使用和擴容。
通過拆分子服務，使得我們有能力在某項子服務發生故障時，盡可能降低對于全局的影響，提高系統整體的可用性。另外，對于處理壓力比較大的子服務，我們還可以進行獨立的水平擴容，方式和前面講到的業務服務器擴容相似，QingCloud 內網 LB 服務也可以在這里發揮作用。
隨著業務的增長，數據層面臨的壓力會越來越大，單機數據庫已經不足以支撐，接下來我們談一下數據層的分布式和擴展技術。
對于大多數的業務場景來說，數據的操作都是讀多寫少，而且讀都集中在少部分的熱點數據上，首先應該引入緩存層來緩解數據庫的讀壓力，如果緩存容量需求比較大，可以構建緩存集群，在上層按照 consistent hashing 算法將數據分散到多個節點，后續需要增加新緩存節點時，只有少部分的數據會失效。
接著引入新的數據庫種類，Redis 已經成為諸多企業的首選標配，因為其支持豐富的數據類型和數據查詢接口，且內存型的數據庫天然具有更高的性能。 你可以講業務中關系性要求不高的數據，從 MySQL 轉移到 Redis 中，尤其是列表類的數據以及計數統計類的數據。給 MySQL 減負的同時提高數據的查詢性能。 單臺 Redis 節點也許不能滿足你對容量的需求，QingCloud 平臺提供了支持多主多從 Redis 3.0 集群服務，一方面可對數據自動分區提高存儲容量，另一方面保證了服務的高可用性。
對于 MySQL 的擴展可以分為幾個步驟來做。首先，增加 MySQL slave 節點，在上層將部分讀請求分發到 slave 節點上去，由于 slave 同步可能有延時，業務應該能容忍短暫的數據不一致現象，舉例，比如你的一個用戶修改了年齡屬性，其他用戶要等一會兒才能看到他的新年齡。
QingCloud MySQL 數據庫支持一主多從的架構，并且已經在多個從節點之上做好了負載均衡，你可以輕易在界面上操作增加新的從節點來為你分擔讀壓力。
即便有 slave 作為數據副本，你也應該定期對你的數據庫進行冷備份，方便當業務出現誤操作時，能夠回滾或恢復到曾經的某個時間點。在 QingCloud 平臺上，備份的過程可以手動執行或者配置為自動任務，在備份過程中對數據庫正常使用沒有影響。
隨著數據的增長，單個數據庫不能承載完整的數據集合，并且寫操作對于單庫的壓力越來越明顯，你應該考慮分庫分表技術。將比較龐大的數據表拆分出來單獨存放，可以給主數據庫騰出來一部分空間，分擔讀寫壓力。拆分的時候，還可以按照功能邏輯，把相關聯的數據表存在一個庫里。
當數據庫單表非常龐大，對讀寫都造成瓶頸時，你需要開始考慮水平分表 sharding，這種擴展方式可以同時解決單表容量過大，讀壓力和寫壓力很大的問題，但帶來的研發和運維難度也會增大，推薦把上述的優化做完以后，最后在有必要的情況下再做。
這里簡略說一下水平分表的要點。首先要從數據表的字段中，選擇一個合理的分區鍵（shard key），這個鍵應該是所有該表查詢條件里，最經常用到的字段，這樣才會使大部分的查詢，能夠提前判斷應該向哪些特定的分區（shard）發送請求，如果查詢條件中不帶shard key，需要遍歷所有的分區，并將結果進行merge。
有了 shard key 還要設計一種分區算法，比如常見的有按照區間，如 user_id in [0, 100] 在 shard 1，user_id in [101, 200] 在 shard2，還比如按照 hash 取模等等。設計分區算法的時候要充分考慮業務特點，多從讀寫操作的角度思考，這么設計能否將壓力和數據均勻分攤到每個 shard 上去。
還需要考慮數據層的擴展如何對上層透明，比如引入分布式數據庫中間件，或者結合業務邏輯把數據庫操作做成一個獨立的子服務，供其它服務調用。如果不做成子服務，至少在業務代碼里有獨立的一層來封裝對數據庫的操作。
除了上述的結構化數據的存取以外，企業還有存儲海量小文件數據（非結構化數據）的需求，單機硬盤、LVM 和 NAS 可以作為臨時方案使用，但都無法同時滿足無限容量、高性能、高安全性、高可用性的多重需要。而自行搭建分布式存儲系統，如 Ceph、GlusterFS、HDFS 適用場景非常有限，且運維和二次開發的成本也非常高。
在 QingCloud 平臺上用戶可以使用 QingStor 對象存儲服務來存儲海量的數據文件，服務本身提供了無限容量、高擴展性、高可用性和高安全性的特性。
講完數據層的擴展技術，最后來談一下多機房部署和異地容災的話題。QingCloud 從北京3區機房開始，通過自營的骨干網光纖和多路環網技術，使得當機房出現網絡故障時對用戶無感知，在基礎設施上保障了高可用性。但是用戶的業務如果能夠多機房部署，可以在分攤訪問負載的同時加速區域訪問，比如加速中國南北方的用戶或者海外用戶的訪問。
若是有三個機房，中間是 QingCloud 北京3區機房，負責主營業務。左邊是 QingCloud 亞太1區機房，主要服務亞太和海外的客戶。這兩個機房都使用了 QingCloud 私有網絡（VPC）部署，通過GRE或IPsec加密隧道在網絡上的互聯互通。右邊是你辦公室的物理機房，IT 人員可以在這個環境下進行開發和辦公。
在業務上實現異地多活時，通常從易到難有三個階段：第一，在備用機房搭建反向代理，用戶請求到備用機房，請求直接被轉向主機房，如果兩機房有專線互聯或延時很小，這樣部署最為簡單。第二，兩個機房同時部署業務服務器和緩存，由于大部分數據請求可以從緩存中讀取，不用進行跨機房訪問。但當緩存失效時，依然要從主機房的數據庫去查詢。第三，兩機房同時部署全套系統，包括接入層、業務層和數據層。數據層依靠數據庫雙主或主從技術進行跨機房同步。
最后總結一下今天的分享。沒有一個所謂經典或完美的架構，只有最適合企業業務的架構，今天分享的是在最通用的業務場景下，系統在接入層、業務層和數據層的常用擴展方法。企業后端架構的演進過程是一個漫長而艱巨的過程，不可能從零開始一蹴而就，就能設計出一個萬般周全的系統，但如果設計之初能更多著眼于未來，就可以為進一步優化留出了余地。
企業首先要清楚當前業務的規模有多大，比如業務的種類，服務QPS，數據的種類和數據量的大小，同時清楚業務和數據的SLA 和性能預期。只有在清楚這些的情況下，才能在規劃的過程中有權衡取舍。
云計算環境下，基礎資源的創建和銷毀都非常迅速，要把更多關注放在業務層面的可擴展能力上，比如業務層要無狀態，數據層要做好索引，做好冷熱區分。無論規模大小，系統的組件不應該有單點故障和單點瓶頸。在規模較小的時候，系統可以不擴展，但是要具備可擴展的能力。
更熱的數據應該被更快的訪問到，決定存取速度的因素主要是距離和介質。從距離來看 本地內存 > 本地硬盤 > 遠端內存 > 遠端硬盤，從介質來看 SSD > SAS > SATA。冷熱數據的比例一般是非常懸殊的，要將熱的數據存放到更近更好的介質上。
每一種存儲系統諸如 MySQL Redis 都有自己的數據持久化策略。
其實無論數據的存儲形式是怎樣的，數據的安全性主要取決于是否有冗余，冗余度是多少，冗余的分布是否是跨物理機，甚至是否跨機房。數據寫入是否真正落盤，以及數據的副本是同步寫入還是異步寫入。
首先考慮緩存的粒度，太粗的粒度會導致失效太頻繁。還要考慮緩存容量，如果單臺節點無法承載足夠的熱點數據，在使用多節點是要注意選擇合適分布策略，比較常有的有一致性hash和hash取模。Redis3.0以上版本提供了集群能力，可以自動對數據分區，并提供高可用能力。
可在數據庫服務之上增加代理中間件，有開源方案也有自己實現，對使用者提供的接口要屏蔽分布式的細節，用戶不用關心容量，性能，分布策略等，仿佛看到的是一臺單機數據庫
交易數據最重要的是不能丟失，性能是次要，曾經很多傳統企業會選擇oracle這樣的商業數據庫，新型企業越來越多愿意采用 MySQL PostgreSQL 等開源實現，但是配置的時候一定是配成最嚴格的同步寫多份成功才返回，并且有日志留存
云計算做為 IT 基礎設施資源，在各行各業都有成功案例，已經不分適合哪類應用。唯一衡量標準就是能否滿足需求，要看是否能取代傳統硬件能夠提供的能力，并且能夠提供傳統硬件以外的能力，例如彈性伸縮，按用量計費，快速啟動銷毀等。
keepalived 主要通過引入虛擬路由冗余（VRRP）來實現高可用，本質上不會對性能造成影響，它是一個獨立的服務，和HAProxy沒有關系。
目前青云的IaaS層在物理機掉電時會觸發災難恢復，另一臺同樣的主機會啟動起來，數據不會丟失，然后再啟動hdfs的服務即可恢復集群使用。Hadoop的自身的HA也會很快提供，這樣就可以自動恢復hdfs服務了。
可以在實例和db之間引入代理中間件，還可以自己實現一個獨立的數據訪問服務，不讓實例直接操作db。
上述內容就是如何在云計算平臺中構建大規模分布式系統，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
