國人人口基數註定了面向2C架構設計逃不開高效能併發的需求，作為技術負責人（架構師）在這方面的考量是決定應用成功運營的關鍵因素。高效能併發的需求根源在於資料/資料的相關關聯性和集中性，這裡所描述的資源/資料包括但不侷限於:

1. 寬頻資源
2. 靜態資源（圖片、Html、CSS等）
3. 資料庫靜態資料（相對）
4. 資料庫動態資料
5. 應用服務資源

高效能併發架構設計的基本要求：1、對資源/資料合理梳理並分類；2、縱向層面上讓資料/資源提升，在橫向層面上合理分佈，在實際應用中資料/資源提升後仍需要考慮橫向層面上的合理分佈。3、選擇合適的實施技術。

（寫到這裡，忽然聯想到國內教育資源、醫療資源等等，同樣存在相對集中性的特點，如何解決針對這些資源的高效能併發問題，也許兩者之間些許相通之處）

• 寬頻資源（橫向）

高併發在寬頻資源方面直接表現為高流量、高分佈，單節點存在出入口流量限制和路由造成的實際延遲的問題。根據地區特點實施多節點部署是通用的作法，多節點部署還可以實現容災的需求。

這裡特別提及一個名詞“兩地三中心“。“兩地三中心” 的技術架構最早在銀行和金融行業應用實施，但一般都只有一個機房提供服務，其他的災備機房僅同提供服務的生產機房進行資料複製，這種冷備的模式並不適用於網際網路業務。

異地多活在一定程度上可以有效地提高產品和業務應對區域故障的能力，確保出現故障的情況下絕大多數使用者的核心體驗可用。但是不可否認，異地多活的實施成本和代價也是非常高昂的，尤其是面對迭代節奏非常快的網際網路業務，所以異地多活適用於業務模型已經趨於穩定的應用。但即便如此，在實施過程中，也要有針對性地選擇核心和關鍵業務，並不是所有的業務都需要異地多活的部署。

多節點的寬頻流量調配需要熟悉GSLB（Global Server Load Balance）的技術內容。

• 靜態資源（縱向）

靜態資源主要指圖片、html、CSS、Js等，傳統概念這些資源集中由Web伺服器提供。實現靜態資源的提升一般採用如下兩種技術手段：

1. 在WEB伺服器之前，部署反向代理快取伺服器。這裡推薦Nginx+Squid的技術組合，動態資源由Nginx直接轉發到應用伺服器，而靜態資原始檔，如jpg，png，js等轉發到Squid，由Squid負責向Web伺服器訪問。
2. 選擇第三方CDN。第三方CDN擁有完整的CDN網路，其快取伺服器位於網路的邊緣，距使用者僅有"一跳"之遙。同時，代理快取是內容提供商源伺服器的一個透明映象。這樣的架構使得CDN服務提供商能夠代表他們客戶，即內容供應商，向終端使用者提供儘可能好的體驗，而這些使用者是不能容忍請求響應時間有任何延遲的。

• 資料庫靜態資料（縱向）

這類資料相對不變，多數用於檢索，比如首頁的推薦文章列表等，這些資料訪問頻次高，在資料庫前部署快取服務來提升這部分資料，將直接減少對資料庫的穿透訪問。

Redis是作者常用也是推薦的技術實現，其擁有速度快、持久化 、支援多種資料結構、支援多種程式語言 、功能豐富（事務、流水線、釋出/訂閱、訊息佇列）、高可用及分散式等特點。Redis不僅可用於資料庫靜態資料的提升外，還可使用於以下場景：

1、會話快取（最常用）

2、訊息佇列，比如支付

3、活動排行榜或計數

4、釋出、訂閱訊息（訊息通知）

• 資料庫動態資料（橫向）

這部分資料是整個應用的核心所在，除了常規的伺服器效能優化外，基於伺服器的運算能力的天花板限制是造成併發能力不足的根源。實際有效的解決辦法是根據業務和資料特點對資料庫儲存進行優化：

1. 分庫
2. 分表
3. 主從讀寫分離

對於資料業務簡單的應用，確定規則就可以直接實施，原則上無需選擇中介軟體來處理，作者在這方面並沒有實際經驗，噹噹自研的資料庫中間層 Sharding-JDBC建議大家可以拿來研究。

• 應用服務資源（橫向）

簡單應用會把邏輯整合在一個應用中，稍複雜會分應用處理並部署在不同的服務上實現，微服務的提出更加有效地在分散式應用架構上解決了此問題。

微服務推薦Dubbo+Docker，它是阿里巴巴公司開源的一個高效能優秀的服務框架，使得應用可通過高效能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫整合。其主要優點包括：

1、透明化的遠端方法呼叫

2、軟負載均衡及容錯機制

3、服務註冊中心自動註冊 & 配置管理

4、服務介面監控與治理