很多企業和開發者在開發一款產品時，首要考慮的是產品功能的實現，其後端架構通常都是非常簡單直接的。產品在剛上線初期，由於用戶訪問壓力很小，數據量積累也並不大，在短時間內都會運行良好。
然而如今移動網際網路的普及和成熟，讓一款產品很可能在短時間內聚集大量用戶，面對流量激增、數據量翻番、訪問量指數級攀升等諸多「煩惱」，這本來是一件好事，可是如果後端系統不能及時擴展，勢必會造成響應緩慢，頻繁出錯甚至拒絕服務的情況。
即便沒有上述系統壓力突然增大的「煩惱」，產品在不斷開發升級的過程中，各種功能模塊會變的越來越複雜，如果不能很好的梳理和組織後端架構，系統出錯崩潰、不可使用的風險也會越來越大。
在沒有雲計算的時代，物理硬體從採購、上架、插線，到安裝、調試、部署，再到真正投入使用，是一個漫長而耗費人力的過程，往往跟不上系統緊急擴容的節奏。而雲服務的出現不僅僅讓我們節約了使用成本，更重要的是可以利用雲計算極度彈性的特點，讓企業和開發者根據需求，對系統進行在線快速的擴容。
但僅僅在雲服務上快速擴容是不夠的，企業也需要在業務層面，關注各個系統組件的可用性和伸縮性。接下來我來給大家介紹如果利用雲計算的優勢，結合企業的業務特點構建穩定可靠的分布式系統。
首先我們從一個最簡單的後端架構開始：
接入層：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 人員可以在這個環境下進行開發和辦公。
在業務上實現異地多活時，通常從易到難有三個階段：第一，在備用機房搭建反向代理，用戶請求到備用機房，請求直接被轉向主機房，如果兩機房有專線互聯或延時很小，這樣部署最為簡單。第二，兩個機房同時部署業務伺服器和緩存，由於大部分數據請求可以從緩存中讀取，不用進行跨機房訪問。但當緩存失效時，依然要從主機房的資料庫去查詢。第三，兩機房同時部署全套系統，包括接入層、業務層和數據層。數據層依靠資料庫雙主或主從技術進行跨機房同步。
最後總結一下今天的分享。沒有一個所謂經典或完美的架構，只有最適合企業業務的架構，今天分享的是在最通用的業務場景下，系統在接入層、業務層和數據層的常用擴展方法。企業後端架構的演進過程是一個漫長而艱巨的過程，不可能從零開始一蹴而就，就能設計出一個萬般周全的系統，但如果設計之初能更多著眼於未來，就可以為進一步優化留出了餘地。
本文作者系QingCloud 系統工程師王煜
問答：
1、企業客戶，私有雲如何建設不同規模下的分布式系統？
答：企業首先要清楚當前業務的規模有多大，比如業務的種類，服務QPS，數據的種類和數據量的大小，同時清楚業務和數據的SLA 和性能預期。只有在清楚這些的情況下，才能在規劃的過程中有權衡取捨。
雲計算環境下，基礎資源的創建和銷毀都非常迅速，要把更多關注放在業務層面的可擴展能力上，比如業務層要無狀態，數據層要做好索引，做好冷熱區分。無論規模大小，系統的組件不應該有單點故障和單點瓶頸。在規模較小的時候，系統可以不擴展，但是要具備可擴展的能力。
2、冷熱數據管理以及數據持久化是怎麼做的？
答：更熱的數據應該被更快的訪問到，決定存取速度的因素主要是距離和介質。從距離來看 本地內存 > 本地硬碟 > 遠端內存 > 遠端硬碟，從介質來看 SSD > SAS > SATA。冷熱數據的比例一般是非常懸殊的，要將熱的數據存放到更近更好的介質上。
每一種存儲系統諸如 MySQL Redis 都有自己的數據持久化策略。
3、數據大集中平臺的安全性是否比原來點對點接口低？
答：其實無論數據的存儲形式是怎樣的，數據的安全性主要取決於是否有冗餘，冗餘度是多少，冗餘的分布是否是跨物理機，甚至是否跨機房。數據寫入是否真正落盤，以及數據的副本是同步寫入還是異步寫入。
4、構建大型分布式平臺系統，緩存管理用redis來實現，應該注意什麼？
答：首先考慮緩存的粒度，太粗的粒度會導致失效太頻繁。還要考慮緩存容量，如果單臺節點無法承載足夠的熱點數據，在使用多節點是要注意選擇合適分布策略，比較常有的有一致性hash和hash取模。Redis3.0以上版本提供了集群能力，可以自動對數據分區，並提供高可用能力。
5、分布式資料庫、緩存，如何實現資源池化？
答：可在資料庫服務之上增加代理中間件，有開源方案也有自己實現，對使用者提供的接口要屏蔽分布式的細節，用戶不用關心容量，性能，分布策略等，仿佛看到的是一臺單機資料庫
6、雲計算適合哪些類型的應用，衡量標準是什麼？
答：雲計算做為 IT 基礎設施資源，在各行各業都有成功案例，已經不分適合哪類應用。唯一衡量標準就是能否滿足需求，要看是否能取代傳統硬體能夠提供的能力，並且能夠提供傳統硬體以外的能力，例如彈性伸縮，按用量計費，快速啟動銷毀等。