雲架構師進階攻略（3）

時間 2019-11-09

標籤架構師進階攻略简体版

原文原文鏈接

此文已由做者劉超受權網易雲社區發佈。html

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。web

10、基於Hadoop和Spark瞭解大數據平臺算法

對於數據架構的部分，其實經歷了三個過程，分別是Hadoop Map-Reduce 1.0，基於Yarn的Map-Reduce 2.0, 還有Spark。數據庫

以下圖是Map-Reduce 1.0的過程。後端

Map-Reduce的過程將一個大任務，split稱爲多個Map Task，分散到多臺機器並行處理，將處理的結果保存到本地，第二個階段，Reduce Task將中間結果拷貝過來，將結果集中處理，取得最終結果。緩存

在Map-Reduce 1.0的時候，跑任務的方式只有這一種，爲了應對複雜的場景，將任務的調度和資源的調度分紅兩層。其中資源的調用由Yarn進行，Yarn無論是Map仍是Reduce，只要向他請求，他就找到空閒的資源分配給他。網絡

每一個任務啓動的時候，專門啓動一個Application Master，管理任務的調度，他是知道Map和Reduce的。這就是Map-Reduce 2.0以下圖。架構

這裏Yarn至關於外包公司的老闆，全部的員工都是worker，都是他的資源，外包公司的老闆是不清楚接的每個項目的。併發

Application Master至關於接的每一個項目的項目經理，他是知道項目的具體狀況的，他在執行項目的時候，若是須要員工幹活，須要向外包公司老闆申請。負載均衡

Yarn是個通用的調度平臺，可以跑Map-Reduce 2，就能跑Spark。

Spark也是建立Spark本身的Application Master，用於調度任務。

Spark之因此比較快，是由於前期規劃作的好，不是像Map-Reduce同樣，每一次分配任務和聚合任務都要寫一次硬盤，而是將任務分紅多個階段，將全部在一個Map都作了的合成一個階段，這樣中間不用落盤，可是到了須要合併的地方，仍是須要落盤的。

對於Hadoop和Spark的基本原理，我寫了下面的文章。

通俗說基於Yarn的Map-Reduce過程

通俗說Spark

真正寫Map-Reduce程序的時候，有不少的方法論，這裏我總結了幾個，供您參考。

大數據方法論之優化Map-Reduce過程

大數據方法論之網頁消重的Map-Reduce算法

大數據方法論之PageRank的Map-Reduce計算

大數據方法論之Nutch基於Map-Reduce的爬取方法

11、基於Lucene和ElasticSearch瞭解搜索引擎

當大數據將收集好的數據處理完畢以後，通常會保存在兩個地方，一個是正向索引，能夠用Hbase，Cassandra等文檔存儲，一個是反向索引，方便搜索，就會保存在基於Lucene的ElasticSearch裏面。

對於Lucene，在職業生涯的早期，寫過一個《Lucene 原理與代碼分析完整版》有500多頁。

對於搜索引擎的通用原理，寫了下面的文章。

12、基於SpringCloud瞭解微服務

最後到了應用架構，也即微服務。

接下來細說微服務架構設計中不得不知的十大要點。

設計要點一：負載均衡 + API 網關

在實施微服務的過程當中，難免要面臨服務的聚合與拆分。

當後端服務的拆分相對比較頻繁的時候，做爲手機 App 來說，每每須要一個統一的入口，將不一樣的請求路由到不一樣的服務，不管後面如何拆分與聚合，對於手機端來說都是透明的。

有了 API 網關之後，簡單的數據聚合能夠在網關層完成，這樣就不用在手機 App 端完成，從而手機 App 耗電量較小，用戶體驗較好。

有了統一的 API 網關，還能夠進行統一的認證和鑑權，儘管服務之間的相互調用比較複雜，接口也會比較多。

API 網關每每只暴露必須的對外接口，而且對接口進行統一的認證和鑑權，使得內部的服務相互訪問的時候，不用再進行認證和鑑權，效率會比較高。

有了統一的 API 網關，能夠在這一層設定必定的策略，進行 A/B 測試，藍綠髮布，預發環境導流等等。

API 網關每每是無狀態的，能夠橫向擴展，從而不會成爲性能瓶頸。

設計要點二：無狀態化與獨立有狀態集羣

影響應用遷移和橫向擴展的重要因素就是應用的狀態。無狀態服務，是要把這個狀態往外移，將 Session 數據，文件數據，結構化數據保存在後端統一的存儲中，從而應用僅僅包含商務邏輯。

狀態是不可避免的，例如 ZooKeeper，DB，Cache 等，把這些全部有狀態的東西收斂在一個很是集中的集羣裏面。

整個業務就分兩部分，一個是無狀態的部分，一個是有狀態的部分。

無狀態的部分能實現兩點：

· 跨機房隨意地部署，也即遷移性。

· 彈性伸縮，很容易地進行擴容。

有狀態的部分，如 ZooKeeper，DB，Cache 有本身的高可用機制，要利用到它們本身高可用的機制來實現這個狀態的集羣。

雖然說無狀態化，可是當前處理的數據，仍是會在內存裏面的，當前的進程掛掉數據，確定也是有一部分丟失的。

爲了實現這一點，服務要有重試的機制，接口要有冪等的機制，經過服務發現機制，從新調用一次後端服務的另外一個實例就能夠了。

設計要點三：數據庫的橫向擴展

數據庫是保存狀態，是最重要的也是最容易出現瓶頸的。有了分佈式數據庫可使數據庫的性能隨着節點增長線性地增長。

分佈式數據庫最最下面是 RDS，是主備的，經過 MySQL 的內核開發能力，咱們可以實現主備切換數據零丟失。

因此數據落在這個 RDS 裏面，是很是放心的，哪怕是掛了一個節點，切換完了之後，你的數據也是不會丟的。

再往上就是橫向怎麼承載大的吞吐量的問題，上面有一個負載均衡 NLB，用 LVS，HAProxy，Keepalived，下面接了一層 Query Server。

Query Server 是能夠根據監控數據進行橫向擴展的，若是出現了故障，能夠隨時進行替換的修復，對於業務層是沒有任何感知的。

另一個就是雙機房的部署，DDB 開發了一個數據運河 NDC 的組件，可使得不一樣的 DDB 之間在不一樣的機房裏面進行同步。

這時候不但在一個數據中內心面是分佈式的，在多個數據中內心面也會有一個相似雙活的一個備份，高可用性有很是好的保證。

設計要點四：緩存

在高併發場景下緩存是很是重要的。要有層次的緩存，使得數據儘可能靠近用戶。數據越靠近用戶能承載的併發量也越大，響應時間越短。

在手機客戶端 App 上就應該有一層緩存，不是全部的數據都每時每刻從後端拿，而是隻拿重要的，關鍵的，時常變化的數據。

尤爲對於靜態數據，能夠過一段時間去取一次，並且也不必到數據中心去取，能夠經過 CDN，將數據緩存在距離客戶端最近的節點上，進行就近下載。

有時候 CDN 裏面沒有，仍是要回到數據中心去下載，稱爲回源，在數據中心的最外層，咱們稱爲接入層，能夠設置一層緩存，將大部分的請求攔截，從而不會對後臺的數據庫形成壓力。

若是是動態數據，仍是須要訪問應用，經過應用中的商務邏輯生成，或者去數據庫讀取，爲了減輕數據庫的壓力，應用可使用本地的緩存，也可使用分佈式緩存。

如 Memcached 或者 Redis，使得大部分請求讀取緩存便可，沒必要訪問數據庫。

固然動態數據還能夠作必定的靜態化，也即降級成靜態數據，從而減小後端的壓力。

設計要點五：服務拆分與服務發現

當系統扛不住，應用變化快的時候，每每要考慮將比較大的服務拆分爲一系列小的服務。

這樣第一個好處就是開發比較獨立，當很是多的人在維護同一個代碼倉庫的時候，每每對代碼的修改就會相互影響。

經常會出現我沒改什麼測試就不經過了，並且代碼提交的時候，常常會出現衝突，須要進行代碼合併，大大下降了開發的效率。

另外一個好處就是上線獨立，物流模塊對接了一家新的快遞公司，須要連同下單一塊兒上線，這是很是不合理的行爲。

我沒改還要我重啓，我沒改還讓我發佈，我沒改還要我開會，都是應該拆分的時機。

再就是高併發時段的擴容，每每只有最關鍵的下單和支付流程是核心，只要將關鍵的交易鏈路進行擴容便可，若是這時候附帶不少其餘的服務，擴容既是不經濟的，也是頗有風險的。

另外的容災和降級，在大促的時候，可能須要犧牲一部分的邊角功能，可是若是全部的代碼耦合在一塊兒，很難將邊角的部分功能進行降級。

固然拆分完畢之後，應用之間的關係就更加複雜了，於是須要服務發現的機制，來管理應用相互的關係，實現自動的修復，自動的關聯，自動的負載均衡，自動的容錯切換。

設計要點六：服務編排與彈性伸縮

當服務拆分了，進程就會很是的多，於是須要服務編排來管理服務之間的依賴關係，以及將服務的部署代碼化，也就是咱們常說的基礎設施即代碼。

這樣對於服務的發佈，更新，回滾，擴容，縮容，均可以經過修改編排文件來實現，從而增長了可追溯性，易管理性，和自動化的能力。

既然編排文件也能夠用代碼倉庫進行管理，就能夠實現一百個服務中，更新其中五個服務，只要修改編排文件中的五個服務的配置就能夠。

當編排文件提交的時候，代碼倉庫自動觸發自動部署升級腳本，從而更新線上的環境。

當發現新的環境有問題時，固然但願將這五個服務原子性地回滾，若是沒有編排文件，須要人工記錄此次升級了哪五個服務。

有了編排文件，只要在代碼倉庫裏面 Revert，就回滾到上一個版本了。全部的操做在代碼倉庫裏都是能夠看到的。

設計要點七：統一配置中心

服務拆分之後，服務的數量很是多，若是全部的配置都以配置文件的方式放在應用本地的話，很是難以管理。

能夠想象當有幾百上千個進程中有一個配置出現了問題，是很難將它找出來的，於是須要有統一的配置中心，來管理全部的配置，進行統一的配置下發。

在微服務中，配置每每分爲如下幾類：

· 一類是幾乎不變的配置，這種配置能夠直接打在容器鏡像裏面。

· 第二類是啓動時就會肯定的配置，這種配置每每經過環境變量，在容器啓動的時候傳進去。

· 第三類就是統一的配置，須要經過配置中心進行下發。例如在大促的狀況下，有些功能須要降級，哪些功能能夠降級，哪些功能不能降級，均可以在配置文件中統一配置。

設計要點八：統一日誌中心

一樣是進程數目很是多的時候，很難對成千上百個容器，一個一個登陸進去查看日誌，因此須要統一的日誌中心來收集日誌。

爲了使收集到的日誌容易分析，對於日誌的規範，須要有必定的要求，當全部的服務都遵照統一的日誌規範的時候，在日誌中心就能夠對一個交易流程進行統一的追溯。

例如在最後的日誌搜索引擎中，搜索交易號，就可以看到在哪一個過程出現了錯誤或者異常。

設計要點九：熔斷，限流，降級

服務要有熔斷，限流，降級的能力，當一個服務調用另外一個服務，出現超時的時候，應及時返回，而非阻塞在那個地方，從而影響其餘用戶的交易，能夠返回默認的託底數據。

當一個服務發現被調用的服務，由於過於繁忙，線程池滿，鏈接池滿，或者老是出錯，則應該及時熔斷，防止由於下一個服務的錯誤或繁忙，致使本服務的不正常，從而逐漸往前傳導，致使整個應用的雪崩。

當發現整個系統的確負載太高的時候，能夠選擇降級某些功能或某些調用，保證最重要的交易流程的經過，以及最重要的資源所有用於保證最核心的流程。

還有一種手段就是限流，當既設置了熔斷策略，又設置了降級策略，經過全鏈路的壓力測試，應該可以知道整個系統的支撐能力。

於是就須要制定限流策略，保證系統在測試過的支撐能力範圍內進行服務，超出支撐能力範圍的，可拒絕服務。

當你下單的時候，系統彈出對話框說「系統忙，請重試」，並不表明系統掛了，而是說明系統是正常工做的，只不過限流策略起到了做用。

設計要點十：全方位的監控

當系統很是複雜的時候，要有統一的監控，主要有兩個方面，一個是是否健康，一個是性能瓶頸在哪裏。

當系統出現異常的時候，監控系統能夠配合告警系統，及時地發現，通知，干預，從而保障系統的順利運行

當壓力測試的時候，每每會遭遇瓶頸，也須要有全方位的監控來找出瓶頸點，同時可以保留現場，從而能夠追溯和分析，進行全方位的優化。

我會將微服務相關的文章更加細化的寫出來。

有關微服務和容器之間的結合，寫了下面的文章。

爲何 kubernetes 自然適合微服務

微服務化不一樣階段 Kubernetes 的不一樣玩法

金融創新業務基於容器雲的微服務化實踐

深刻解讀Service Mesh背後的技術細節

深刻解讀Service Mesh的數據面Envoy

最後。

劉超網易雲技術架構部總監

長期致力於雲計算開源技術的分享，佈道和落地，將網易內部最佳實踐服務客戶與行業。

技術分享：出版《Lucene應用開發解密》，極客時間專欄《趣談網絡協議》，我的公衆號《劉超的通俗雲計算》文章Kubernetes及微服務系列18篇，Mesos系列30篇，KVM系列25篇，Openvswitch系列31篇，OpenStack系列24篇，Hadoop系列10篇。公衆號文章《終於有人把雲計算，大數據，人工智能講明白了》累積10萬+

大會佈道：InfoQ架構師峯會明星講師，做爲邀請講師在QCon，LC3，SACC，GIAC，CEUC，SoftCon，NJSD等超過10場大型技術峯會分享網易的最佳實踐

行業落地：將網易的容器和微服務產品在銀行，證券，物流，視頻監控，智能製造等多個行業落地。

相關閱讀：雲架構師進階攻略（2）

雲架構師進階攻略（1）

網易雲計算基礎服務深度整合了 IaaS 、 PaaS 及容器技術，提供彈性計算、 DevOps 工具鏈及微服務基礎設施等服務，幫助企業解決 IT 、架構及運維等問題，使企業更聚焦於業務，是新一代的雲計算平臺，點擊可免費試用。

相關文章：
【推薦】 iOS 安裝包瘦身（下篇）
【推薦】搜索湊單頁大促顯示延遲方案設計