雲架構師進階攻略（3）
此文已由作者劉超授權網易雲社群釋出。
歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。
十、基於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的基本原理，我寫了下面的文章。
真正寫Map-Reduce程式的時候，有很多的方法論，這裡我總結了幾個，供您參考。
十一、基於Lucene和ElasticSearch瞭解搜尋引擎
當大資料將收集好的資料處理完畢之後，一般會儲存在兩個地方，一個是正向索引，可以用Hbase，Cassandra等文件儲存，一個是反向索引，方便搜尋，就會儲存在基於Lucene的ElasticSearch裡面。
對於Lucene，在職業生涯的早期，寫過一個《Lucene 原理與程式碼分析完整版》有500多頁。
對於搜尋引擎的通用原理，寫了下面的文章。
十二、基於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，就回滾到上一個版本了。所有的操作在程式碼倉庫裡都是可以看到的。
設計要點七：統一配置中心
服務拆分以後，服務的數量非常多，如果所有的配置都以配置檔案的方式放在應用本地的話，非常難以管理。
可以想象當有幾百上千個程序中有一個配置出現了問題，是很難將它找出來的，因而需要有統一的配置中心，來管理所有的配置，進行統一的配置下發。
在微服務中，配置往往分為以下幾類：
· 一類是幾乎不變的配置，這種配置可以直接打在容器映象裡面。
· 第二類是啟動時就會確定的配置，這種配置往往通過環境變數，在容器啟動的時候傳進去。
· 第三類就是統一的配置，需要通過配置中心進行下發。例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置檔案中統一配置。
設計要點八：統一日誌中心
同樣是程序數目非常多的時候，很難對成千上百個容器，一個一個登入進去檢視日誌，所以需要統一的日誌中心來收集日誌。
為了使收集到的日誌容易分析，對於日誌的規範，需要有一定的要求，當所有的服務都遵守統一的日誌規範的時候，在日誌中心就可以對一個交易流程進行統一的追溯。
例如在最後的日誌搜尋引擎中，搜尋交易號，就能夠看到在哪個過程出現了錯誤或者異常。
設計要點九：熔斷，限流，降級
服務要有熔斷，限流，降級的能力，當一個服務呼叫另一個服務，出現超時的時候，應及時返回，而非阻塞在那個地方，從而影響其他使用者的交易，可以返回預設的託底資料。
當一個服務發現被呼叫的服務，因為過於繁忙，執行緒池滿，連線池滿，或者總是出錯，則應該及時熔斷，防止因為下一個服務的錯誤或繁忙，導致本服務的不正常，從而逐漸往前傳導，導致整個應用的雪崩。
當發現整個系統的確負載過高的時候，可以選擇降級某些功能或某些呼叫，保證最重要的交易流程的通過，以及最重要的資源全部用於保證最核心的流程。
還有一種手段就是限流，當既設定了熔斷策略，又設定了降級策略，通過全鏈路的壓力測試，應該能夠知道整個系統的支撐能力。
因而就需要制定限流策略，保證系統在測試過的支撐能力範圍內進行服務，超出支撐能力範圍的，可拒絕服務。
當你下單的時候，系統彈出對話方塊說 “系統忙，請重試”，並不代表系統掛了，而是說明系統是正常工作的，只不過限流策略起到了作用。
設計要點十：全方位的監控
當系統非常複雜的時候，要有統一的監控，主要有兩個方面，一個是是否健康，一個是效能瓶頸在哪裡。
當系統出現異常的時候，監控系統可以配合告警系統，及時地發現，通知，干預，從而保障系統的順利執行
當壓力測試的時候，往往會遭遇瓶頸，也需要有全方位的監控來找出瓶頸點，同時能夠保留現場，從而可以追溯和分析，進行全方位的優化。
我會將微服務相關的文章更加細化的寫出來。
有關微服務和容器之間的結合，寫了下面的文章。
最後。
劉超 網易雲技術架構部總監
長期致力於雲端計算開源技術的分享，佈道和落地，將網易內部最佳實踐服務客戶與行業。
技術分享：出版《Lucene應用開發解密》，極客時間專欄《趣談網路協議》，個人公眾號《劉超的通俗雲端計算》文章Kubernetes及微服務系列18篇，Mesos系列30篇，KVM系列25篇，Openvswitch系列31篇，OpenStack系列24篇，Hadoop系列10篇。公眾號文章《終於有人把雲端計算，大資料，人工智慧講明白了》累積10萬+
大會佈道：InfoQ架構師峰會明星講師，作為邀請講師在QCon，LC3，SACC，GIAC，CEUC，SoftCon，NJSD等超過10場大型技術峰會分享網易的最佳實踐
行業落地：將網易的容器和微服務產品在銀行，證券，物流，視訊監控，智慧製造等多個行業落地。
相關閱讀：雲架構師進階攻略（2）
網易 雲端計算基礎服務 深度整合了 IaaS 、 PaaS 及容器技術，提供彈性計算、 DevOps 工具鏈及微服務基礎設施等服務，幫助企業解決 IT 、架構及運維等問題，使企業更聚焦於業務，是新一代的雲端計算平臺， 點選可免費試用 。
相關文章：
【推薦】 秋讀|10本熱門圖書（人工智慧、程式設計開發、架構、區塊鏈等）免費送!
【推薦】 Http介面系列：如何提高Http介面用例的資料穩定性