https://cloud.tencent.com/info/e9695bd18d1c7752b3924bb3ac38cc95.html
【51CTO技術沙龍】10月27日，讓我們共同探索AI場景化應用實作之道 -->
雲架構師負責管理一個組織中的雲計算架構，特别是随着雲技術日益複雜化。雲計算架構涵蓋了與雲計算相關的一切，包括管理雲存儲所需的前端平台、伺服器、存儲、傳遞和網絡。
本文作者從如下幾個方面全面剖析雲架構師的進階攻略：
- 架構的三個次元和六個層面
- 了解雲計算的曆史演進與基本原理
- 開源軟體是進階的利器
- 了解 Linux 基礎知識
- 了解資料中心和網絡基礎知識
- 基于 KVM 了解計算虛拟化
- 基于 Openvswitch 了解網絡虛拟化
- 基于 OpenStack 了解雲平台
- 基于 Mesos 和 Kubernetes 了解容器平台
- 基于 Hadoop 和 Spark 了解大資料平台
- 基于 Lucene 和 ElasticSearch 了解搜尋引擎
- 基于 Spring Cloud 了解微服務
架構的三個次元和六個層面
三個次元
在網際網路時代，要做好一個合格的雲架構師，需要熟悉三大架構。
IT 架構
IT 架構其實就是計算，網絡，存儲。這是雲架構師的基本功，也是最傳統的雲架構師應該首先掌握的部分。
良好設計的 IT 架構，可以降低 CAPEX 和 OPEX，減輕運維的負擔。資料中心，虛拟化，雲平台，容器平台都屬于 IT 架構的範疇。
應用架構
随着應用從傳統應用向網際網路應用轉型，僅僅搞定資源層面的彈性還不夠，常常會出現建立了大批機器，仍然撐不住高并發流量。因而基于微服務的網際網路架構，越來越成為雲架構師所必需的技能。
良好設計的應用架構，可以實作快速疊代和高并發。資料庫，緩存，消息隊列等 PaaS，以及基于 Spring Cloud 和 Dubbo 的微服務架構，都屬于應用架構的範疇。
資料架構
資料成為人工智能時代的核心資産，在做網際網路化轉型的同時，往往進行的也是數字化轉型，并有戰略的進行資料收集，這就需要雲架構師同時有大資料思維。
有意識的建設統一的資料平台，并給予資料進行數字化營運。搜尋引擎，Hadoop，Spark，人工智能都屬于資料架構的範疇。
六個層面
上面的三個次元是從人的角度出發的，如果從系統的角度出發，架構分六個層次。
基礎設施層
在資料中心裡面，會有大量的機架，大量的伺服器，并通過交換機和路由器将伺服器連接配接起來，有的應用例如 Oracle 是需要部署在實體機上的。
為了管理的友善，在實體機之上會部署虛拟化，例如 Vmware，可以将對于實體機複雜的運維簡化為虛拟機靈活的運維。
虛拟化采取的運維方式多是由運維部門統一管理，當一個公司裡面部門非常多的時候，往往要引入良好的租戶管理。
基于 Quota 和 QoS 的資源控制，基于 VPC 的網絡規劃等，實作從運維集中管理到租戶自助使用模式的轉換，托生于公有雲的 OpenStack 在這方面做的是比較好的。
随着應用架構越來越重要，對于标準化傳遞和彈性伸縮的需求越來越大，容器做為軟體傳遞的集裝箱，可以實作基于鏡像的跨環境遷移，Kubernetes 是容器管理平台的事實标準。
資料層
資料層，也即一個應用的中軍大營，如果是傳統應用，可能會使用 Oracle，并使用大量的存儲過程，有大量的表聯合查詢，成本也往往比較高。
但是對于高并發的網際網路應用，需要進行微服務的拆分，資料庫執行個體會比較多，使用開源的 MySQL 是常見的選擇。
大量的存儲過程和聯合查詢往往會使得微服務無法拆分，性能會比較差，因而需要放到應用層去做複雜的業務邏輯，而且資料庫表和索引的設計非常重要。
當并發量比較大的時候，需要實作橫向擴充，就需要基于分布式資料庫，也是需要基于單庫良好的表和索引設計。
對于結構比較靈活的資料，可以使用 MongoDB 資料庫，橫向擴充能力比較好。
對于大量的聯合查詢需求，可以使用 ElasticSearch 之類的搜尋引擎來做，速度快，更加靈活。
中間件層
因為資料庫層往往需要保證資料的不丢失以及一些事務，因而并發性能不可能非常大。
是以我們經常說，資料庫是中軍大營，不能所有的請求都到這裡來，因而需要一層緩存層，用來攔截大部分的熱點請求。
Memcached 适合做簡單的 key-value 存儲，記憶體使用率比較高，而且由于是多核處理，對于比較大的資料，性能較好。
但是缺點也比較明顯，Memcached 嚴格來講沒有叢集機制，橫向擴充完全靠用戶端來實作。
另外 Memcached 無法持久化，一旦挂了資料就都丢失了，如果想實作高可用，也是需要用戶端進行雙寫才可以。
Redis 的資料結構比較豐富，提供持久化的功能，提供成熟的主備同步，故障切換的功能，進而保證了高可用性。
另外微服務拆分以後，有時候處理一個訂單要經過非常多的服務，處理過程會比較慢，這個時候需要使用消息隊列，讓服務之間的調用變成對于消息的訂閱，實作異步處理。
RabbitMQ 和 Kafka 是常用的消息隊列，當事件比較重要的時候，會結合資料庫實作可靠消息隊列。
基礎服務層
有的時候成為中台層，将通用的能力抽象為服務對外提供原子化接口。
這樣上層可以根據業務需求，通過靈活的組合這些原子化接口，靈活的應對業務需求的變化，實作能力的複用，以及資料的統一管理，例如使用者資料，支付資料，不會分散到各個應用中。
另外基礎服務層稱為應用、資料庫和緩存的一個分界線，不應該所有的應用都直接連資料庫，一旦出現分庫分表，資料庫遷移，緩存選型改變等，影響面會非常大，幾乎無法執行。
如果将這些底層的變更攔截在基礎服務層，上層僅僅使用基礎服務層的接口，這樣底層的變化會對上層透明，可以逐漸演進。
業務服務層或者組合服務層
大部分的業務邏輯都是在這個層面實作，業務邏輯比較面向使用者，因而會經常改變，是以需要組合基礎服務的接口進行實作。
在這一層，會經常進行服務的拆分，實作開發獨立，上線獨立，擴容獨立，容災降級獨立。
微服務的拆分不應該是一個運動，而應該是一個遇到耦合痛點的時候，不斷解決，不斷演進的一個過程。
微服務拆分之後，有時候需要通過分布式事務，保證多個操作的原子性，也是在組合服務層來實作的。
使用者接口層
使用者接口層，也即對終端客戶呈現出來的界面和 App，但是卻不僅僅是界面這麼簡單。
這一層有時候稱為接入層。在這一層，動态資源和靜态資源應該分離，靜态資源應該在接入層做緩存，使用 CDN 進行緩存。
也應該 UI 和 API 分離，界面應該通過組合 API 進行資料拼裝。API 會通過統一的 API 網關進行統一的管理和治理。
一方面後端組合服務層的拆分對 APP 是透明的;另一方面當并發量比較大的時候，可以在這一層實作限流和降級。
為了支撐這六個層次，在上圖的左側是一些公共能力：
- 持續內建和持續釋出是保證微服務拆分過程中的快速疊代，以及變更後保證功能不變的，不引入新的 Bug。
- 服務發現和服務治理是微服務之間互相的調用，以及調用過程中出現異常情況下的熔斷，限流，降級政策。
- 大資料和人工智能是通過收集各個層面的資料，例如使用者通路資料，使用者下單資料，客服詢問資料等，結合統一的中台，對資料進行分析，實作智能推薦。
- 監控與 APM 是基礎設施的監控和應用的監控，發現資源層面的問題以及應用調用的問題。
作為一個雲架構師還是很複雜的，千裡之行，始于足下，讓我們慢慢來。
了解雲計算的曆史演進與基本原理
在一頭紮進雲計算的汪洋大海之前，我們應該先有一個全貌的了解，有人說了解一個知識的起點，就是了解它的曆史，也就是知道它是如何一步一步到今天的，這樣如此龐大的一個體系，其實是逐漸加進來的。
這樣的知識體系對我們來說，就不是一個冷冰冰的知識網，而是一個有血有肉的人，我們隻要沿着演進的線索，一步一步摸清楚“它”的脾氣就可以了。
如何把雲計算講的通俗易懂，我本人思考了半天，最終寫下了下面這篇文章：終于有人把雲計算、大資料和人工智能講明白了!在這裡，我把核心的要點在這裡寫一下。
第一：雲計算的本質是實作從資源到架構的全面彈性。
所謂的彈性就是時間靈活性和空間靈活性，也即想什麼時候要就什麼時候要，想要多少就要多少。
資源層面的彈性也即實作計算、網絡、存儲資源的彈性。這個過程經曆了從實體機，到虛拟化，到雲計算的一個演進過程。
架構層面的彈性也即實作通用應用和自有應用的彈性擴充。對于通用的應用，多內建為 PaaS 平台。
對于自己的應用，通過基于腳本的 Puppet、Chef、Ansible 到基于容器鏡像的容器平台 CaaS。
第二：大資料包含資料的收集，資料的傳輸，資料的存儲，資料的處理和分析，資料的檢索和挖掘等幾個過程。
當資料量很小時，很少的幾台機器就能解決。慢慢的，當資料量越來越大，最牛的伺服器都解決不了問題時，怎麼辦呢?
這時就要聚合多台機器的力量，大家齊心協力一起把這個事搞定，衆人拾柴火焰高。
第三：人工智能經曆了基于專家系統的計劃經濟，基于統計的宏觀調控，基于神經網絡的微觀經濟學三個階段。
開源軟體是進階的利器
架構師除了要掌握大的架構和理論之外，指導落地也是必備的技能，所謂既要懂設計模式，也要懂代碼。那從哪裡去學習這些良好的，有借鑒意義的，可以落地的架構實踐呢?
這個世界上還是有很多有情懷的大牛的，尤其是程式員裡面，他們喜歡做一件什麼事情呢?答案是開源。很多軟體都是有閉源就有開源，源就是源代碼。
當某個軟體做的好，所有人都愛用，這個軟體的代碼呢，我封閉起來隻有我公司知道，其他人不知道，如果其他人想用這個軟體，就要付我錢，這就叫閉源。但是世界上總有一些大牛看不慣錢都讓一家賺了去。
大牛們覺得，這個技術你會我也會，你能開發出來，我也能，我開發出來就是不收錢，把代碼拿出來分享給大家，全世界誰用都可以，所有的人都可以享受到好處，這個叫做開源。
非常建議大家了解，深入研究，甚至參與貢獻開源軟體，因為收益匪淺。
第一：通過開源軟體，我們可以了解大牛們的架構原則，設計模式。
其實咱們平時的工作中，是很難碰到大牛的，他可能是你渴望而不可及的公司的員工，甚至在國外，你要想進這種公司，不刷個幾年題目，面試個 N 輪是進不去的。
即便進去了，他可能是公司的高層，每天很忙，不怎麼見得到他，就算當面讨教，時間也不會很長，很難深入交流。
也有的大牛會選擇自主創業，或者是自由職業者，神龍見首不見尾，到了大公司都見不到。
但是感謝網際網路和開源社群，将大牛們拉到了我們身邊，你可以訂閱郵件組，可以加入讨論群，可以看到大牛們的設計，看到很多人的評論，提問，還有大牛的回答，可以看到大牛的設計也不是一蹴而就完美的，看到逐漸演進的過程，等等。
這些都是能夠幫助我們快速提升水準的地方，有的時候，拿到一篇設計，都要查資料看半天，一開始都可能好多的術語都看不懂，沒關系肯下功夫，當你看 blueprints 越來越順暢的時候，你就進步了。
第二：通過開源軟體，我們可以學習到代碼級的落地實踐。
有時候我們能看到很多大牛寫的書和文章，也能看到很多理論的書籍，但是存在一個問題是，理論都懂，但是還是做不好架構。
這是因為沒有看到代碼，所有的理論都是空中樓閣，當你到了具體的代碼設計層面，那些學會的設計模式，無法轉化為你自己的實踐。
好在開源軟體的代碼都是公開的，凝結了大牛的心血，也能夠看到大牛在具體落地時候的取舍，一切那麼真實，看得見，摸得着。
通過代碼進行學習，配合理論知識，更容易獲得第一手的經驗，并且在自己做設計和寫代碼的時候，馬上能夠映射到可以參考的場景，讓我們在做自己的系統的時候，少走彎路。
第三：通過開源軟體，我們可以加入社群，和其他技術人員在同一背景下共同進步。
大牛我們往往不容易接觸到，正面讨論技術問題的時間更是難能可貴，但是沒有關系，開源軟體建構了一個社群，大家可以在一起讨論。
你是怎麼了解的，别人是怎麼了解的，越讨論越交流，越明晰，有時候和比你經驗稍微豐富一點的技術人員交流，可能比直接和大牛對話更加有直接作用。
大牛的話可能讓你消化半天，依然不知所雲，大牛可能覺得很多普通人覺得的難點是顯而易見的，不屑去解釋。
但是社群裡面的技術人員，可能和你一樣慢慢進步過來的，知道哪些點是當年自己困惑的，如果踩過這一個個的坑，他們一點撥，你就會豁然開朗。
而且每個人遇到的具體情況不同，從事的行業不同，客戶的需求不同，因而軟體設計的時候考慮的因素不同。
大牛是牛，但是不一定能夠遇到和你一樣的場景，但是社群裡面，有你的同行業的，背景相近的技術人員，你們可以讨論出符合你們特定場景的解決方案。
第四：通過開源軟體，我們作為個人，比較容易找到工作。
我們面試的時候，常常遇到的問題是，怎麼能夠把在原來工作中自己的貢獻，了解，設計，技術能力展現出來。
其實我發現很多程式員不能很好的做到這一點，是以造成很多人面試很吃虧。
原因之一：背景資訊不對稱。例如原來面臨的業務上很難的問題，面試官由于不了解背景，而且短時間解釋不清楚，輕視候選人的水準。
我也遇到過很多面試官才聽了幾分鐘，就會說，這不挺簡單的，你這樣這樣不就行了，然後徹底否定你們一個團隊忙了三年的事情。
原因之二：很多有能力的程式員不會表達，導緻真正寫代碼的說不明白。可能原來在公司裡面一個績效非常好，一個績效非常差，但是到了面試官那裡就拉平了。
原因之三：新的公司不能确定你在上家公司做的工作，到這一家都能用的。例如你做的工作有 30% 是和具體業務場景相關的，70% 是通用技術，可能下家公司隻會為你的通用技術部分買單。
開源軟體的好處就是，參與的人所掌握的技能都是通的，而且大家在同一個上下文裡面對話，面試官和候選人之間的資訊差比較少。掌握某個開源軟體有多難，不用候選人自己說，大家心裡都有數。
對于很多技術能力強，但是表達能力較弱的極少數人員來講，talk is cheap，show me the code。
代碼呈上去，就能夠表現出實力來了，而且面試官也不需要根據短短的半個小時了解一個人，可以做很多背景調查。
另外由于掌握的技術是通用的，你到下一家公司，馬上就能夠上手，幾乎不需要預熱時間，對于雙方都有好處。
第五：通過開源軟體，我們作為招聘方，比較容易招到相應人員。
如果在創業公司待過的朋友會了解到創業公司招人很難，人員流失很快，而且創業公司往往對于開發進度要求很快，因為大家都在搶時間。
因而開源軟體對于招聘方來講，也是好消息。首先創業公司沒辦法像大公司一樣，弄這麼多的技術大牛，自己完全落地一套自己的體系，使用開源軟體快速搭建一套平台先上線是最好的選擇。
其次使用開源軟體，會使得招聘相對容易，市場上火的開源軟體會有大批的從業者，參與各種論壇和社群，比較容易挖到人。
最後，開源軟體的使用使得新人來了之後沒有預熱時間，來了就上手，保證開發速度。
那如何快速上手一款開源軟體呢?我總結了如下九個步驟：
- 手動安裝起來，一定要手動。
- 使用一下，推薦 XXX in Action 系列。
- 讀文檔，讀所有的官方文檔，記不住，看不懂也要讀下來。
- 了解核心的原理和算法，推薦 XXX the definitive guide 系列。
- 看一本源碼分析的書，會讓你的源碼閱讀之旅事半功倍。
- 開始閱讀核心邏輯源代碼。
- 編譯并 Debug 源代碼。
- 開發一個插件，或者對元件做少量的修改。
- 大量的運維實踐經驗和面向真實場景的定制開發。
- 是以做一個雲架構師，一定不能脫離代碼，反而要不斷的擁抱開源軟體。
了解 Linux 基礎知識
作為一個雲架構師，首要的一點，就是要熟悉 Linux 的基礎知識，基本原理了。
說到作業系統，一般有三個次元：
- 桌面作業系統
- 移動作業系統
- 伺服器作業系統
Stack Overflow Developer Survey 2018 有這樣一個統計，對于開發人員來說，桌面作業系統的排名是 Windows，MacOS，Linux，是以大部分人平時的辦公系統都是 Windows。
當然因為辦公的原因，平時使用 Windows 的比較多，是以在學校裡，很多同學接觸到的作業系統基本上都是 Windows，但是一旦從事計算機行業，就一定要跨過 Linux 這道坎。
根據今年 W3Techs 的統計，對于伺服器端，Unix-Like OS 占到的比例為近 70%。所謂 Unix-Like OS 包括下圖的 Linux，BSD 等一系列。
從這個統計可以看出，随着雲計算的發展，軟體 SaaS 化，服務化，甚至微服務化，大部分的計算都是在服務端做的，因而要成為雲架構師，就必須懂 Linux。
随着移動網際網路的發展，用戶端基本上以 Android 和 iOS 為主，下圖是 Gartner 的統計。
Android 是基于 Linux 核心的。因而用戶端也進入了 Linux 陣營，很多智能終端，智能裝置等開發職位，都需要懂 Linux 的人員。
學習 Linux 主要包含兩部分，一個是怎麼用，一個是怎麼程式設計，背後原理是什麼。
對于怎麼用，上手的話，推薦《鳥哥的 Linux 私房菜》，按着這個手冊，就能夠學會基本的 Linux 的使用，如果再深入一點，推薦《Linux 系統管理技術手冊》，磚頭厚的一本書，是 Linux 運維手邊必備。
對于怎麼程式設計，上手的話，推薦《Unix 環境進階程式設計》，有代碼，有介紹，有原理，如果對核心的原理感興趣，推薦《深入了解 Linux 核心》。
Linux 的架構如下圖：
我們知道，一台實體機上有很多的硬體，最重要的是 CPU，記憶體，硬碟，網絡，但是一個實體機上要跑很多的程式，這些資源應該給誰用呢?當然是大家輪着用，誰也别獨占，誰也别餓死。
為了完成這件事情，作業系統的核心就起到了大管家的作用，将硬體資源配置設定給不同的使用者程式使用，并且在适當的時間将資源拿回來，再配置設定給其他的使用者程序，這個過程稱為排程。
作業系統的功能之一：系統調用
當使用者程式想請求資源的時候，需要調用作業系統的系統調用接口，這是核心和使用者态程式的分界線。
就像你要打車，要通過打車軟體的界面，下發打車指令一樣，這樣打車軟體才會給你排程一輛車。
作業系統的功能之二：程序管理
當一個使用者程序運作的時候，核心為它配置設定的資源，總要有一個資料結構儲存，哪些資源配置設定給了這個程序。配置設定給這個程序的資源往往包括打開的檔案，記憶體空間等。
作業系統的功能之三：記憶體管理
每個程序有獨立的記憶體空間，記憶體空間是程序用來存放資料的，就像一間一間的倉庫。
為了程序使用友善，每個程序記憶體空間，在程序的角度來看都是獨立的，也即都是從 0 号倉庫，1 号倉庫，一直到 N 号倉庫，都是獨享的。
但是從作業系統核心的角度來看，當然不可能獨享，而是大家共享，M 号倉庫隻有一個，你用他就不能用，這就需要一個倉庫排程系統，将使用者程序的倉庫号和實際使用的倉庫号對應起來。
例如程序 1 的 10 号倉庫，對應到真實的倉庫是 110 号，程序 2 的 20 号倉庫，對應到真實的倉庫是 120 号。
作業系統功能之四：檔案系統
對于 Linux 來講，很多東西都是檔案，例如程序号會對應一個檔案，建立一個網絡連接配接也對應一個檔案。檔案系統多種多樣，為了能夠統一适配，有一個虛拟檔案系統的中間層 VFS。
作業系統功能之五：裝置管理
裝置分兩種，一種是塊裝置，一種是字元裝置，例如硬碟就是塊裝置，可以格式化為檔案系統，再如滑鼠和鍵盤的輸入輸出是字元裝置。
作業系統功能之六：網絡管理
對于 Linux 來講，網絡也是基于裝置和檔案系統的，但是由于網絡有自己的協定棧，要遵循 TCP/IP 協定棧标準。
了解資料中心和網絡基礎知識
雲平台當然會部署在資料中心裡面，由于資料中心裡面的硬體裝置也是非常專業的，因而很多地方機房部門和雲計算部門是兩個部門。
但是作為一個雲架構師，需要和機房部門進行溝通，因而需要一定的資料中心知識，在資料中心裡面，最難搞定的是網絡，因而這裡面網絡知識是重中之重。
下面這個圖是一個典型的資料中心圖：
最外層是 Internet Edge，也叫 Edge Router，也叫 Border Router，它提供資料中心與 Internet 的連接配接。
第一層 Core Network，包含很多的 Core Switches：
- Available Zone 同 Edge Router 之間通信。
- Available Zone 之間的通信提供。
- 提供高可用性連接配接 HA。
- 提供 Intrusion Prevention Services。
- 提供 Distributed Denial of Service Attack Analysis and Mitigation。
- 提供 Tier 1 Load Balancer
第二層也即每個 AZ 的最上層，我們稱為 Aggregation Layer。
第三層是 Access Layer，就是一個個機架的伺服器，用接入交換機連接配接在一起。
這是一個典型的三層網絡結構，也即接入層、彙聚層、核心層三層。除了資料中心以外，哪怕是做應用架構，對于網絡的了解也是必須的。
雲架構說到底是分布式架構，既然是分布式，就是去中心化的，因而就需要系統之間通過網絡進行互通，因而網絡是作為大規模系統架構繞不過去的一個坎。
對于網絡的基本原理，推薦書籍《計算機網絡-嚴偉與潘愛民譯》，《計算機網絡：自頂向下方法》。
對于 TCP/IP 協定棧的了解，推薦書籍《TCP/IP 詳解》，《The TCP/IP Guide》。
對于網絡程式設計，推薦書籍《Unix 網絡程式設計》，如果你想了解網絡協定棧的實作，推薦書籍《深入了解 Linux 網絡内幕》 。
基于 KVM 了解計算虛拟化
當實體機搭建完畢之後，接下來就是基于實體機上面搭建虛拟機了。
沒有了解虛拟機的同學，可以在自己的筆記本電腦上用 VirtualBox 或者 Vmware 建立虛拟機，你會發現，很容易就能在實體機的作業系統之内再安裝多個作業系統。
通過這種方式，你可以很友善的在 Windows 辦公系統之内安裝一個 Linux 系統，進而保持 Linux 系統的持續學習。
前面講 Linux 作業系統的時候，說到作業系統，就是整個系統的管家。應用程式要申請資源，都需要通過作業系統的系統調用接口，向作業系統核心申請将 CPU，記憶體，網絡，硬碟等資源配置設定給他。
這時候你會發現，虛拟機也是實體機上的一個普通程序，當虛拟機内部的應用程式申請資源的時候，需要向虛拟機的作業系統請求。
然而虛拟機的作業系統自己本身也沒有權限操作資源，因而又需要像實體機的作業系統申請資源。
這中間要多一次翻譯的工作，完成這件事情的稱為虛拟化軟體。例如上面說的 VirtualBox 和 Vmware 都是虛拟化軟體。
但是多一層翻譯，就多一層性能損耗，如果虛拟機裡面的每一個操作都要翻譯，都不能直接操作硬體，性能就會差很多，簡直沒辦法用，于是就出現了上圖中的硬體輔助虛拟化，也即通過硬體的特殊配置。
例如 VT-x 和 VT-d 等，讓虛拟機裡面的作業系統知道，它不是一個原生的作業系統了，是一個虛拟機的作業系統，不能按照原來的模式操作資源了，而是通過特殊的驅動以硬體輔助的方式抄近道操作實體資源。
剛才說的是桌面虛拟化，也就是在你的筆記本電腦上，在資料中心裡面，也可以使用 Vmware 進行虛拟化，但是價格比較貴，如果規模比較大，會采取開源的虛拟化軟體 qemu-kvm。
對于 qemu-kvm 來說，和上面的原理是一樣的，其中 qemu 的 emu 是 emulator 的意思，也即模拟器，就是翻譯的意思。
KVM 是一個可以使用 CPU 的硬體輔助虛拟化的方式，而網絡和存儲的，需要通過特殊的 virtio 的方式，提供高性能的裝置虛拟化功能。
要了解虛拟化的基本原理，推薦書籍《系統虛拟化——原理與實作》，要了解 KVM，推薦兩本書籍《KVM Virtualization Cookbook》和《Mastering KVM Virtualization》。
另外 KVM 和 qemu 的官方文檔也是必須要看的，還有 Redhat 的官網很多文章非常值得學習。
基于 Openvswitch 了解網絡虛拟化
當虛拟機建立出來了，最主要的訴求就是要能上網，它能通路到網上的資源，如果虛拟機裡面部署一個網站，也希望别人能夠通路到它。
這一方面依賴于 qemu-KVM 的網絡虛拟化，将網絡包從虛拟機裡面傳播到虛拟機外面，這需要實體機核心轉換一把，形成虛拟機内部的網卡和虛拟機外部的虛拟網卡。
另外一方面就是虛拟機的網絡如何能夠連接配接到實體網絡裡面。實體網絡常常稱為 underlay network，虛拟網絡常常稱為 overlay network。
從實體網絡到虛拟網絡稱為網絡虛拟化，能非常好的完成這件事情的是一個叫 Openvswitch 的虛拟交換機軟體。
Openvswitch 會有一個核心驅動，監聽實體網卡，可以将實體網卡上收到的包拿進來。
虛拟機建立出來的外部的虛拟網卡也可以添加到 Openvswitch 上，而 Openvswitch 可以設定各種的網絡包處理政策，将網絡包在虛拟機和實體機之間進行傳遞，進而實作了網絡虛拟化。
對于 Openvswitch，我主要是通過官方文檔進行研究。
基于 OpenStack 了解雲平台
當有了虛拟機，并且虛拟機能夠上網了之後，接下來就是搭建雲平台的時候了。
雲是基于計算，網絡，存儲虛拟化技術的，雲和虛拟化的主要差別在于，管理者的管理模式不同，使用者的使用模式也不同。
虛拟化平台沒有多層次的豐富的租戶管理，沒有靈活 quota 配額的限制，沒有靈活的 QoS 的限制。
多采用虛拟網絡和實體網絡打平的橋接模式，虛拟機直接使用機房網絡，沒有虛拟子網 VPC 的概念，虛拟網絡的管理和隔離不能和租戶隔離完全映射起來。
對于存儲也是，公司采購了統一的存儲，也不能和租戶的隔離完全映射起來。
使用虛拟化平台的特點是，對于這個平台的操作完全由運維部門統一管理，而不能将權限下放給業務部門自己進行操作。
因為一旦允許不同的部門自己操作，大家都用機房網絡，在沒有統一管控的情況下，很容易網段沖突了。
如果業務部門想申請虛拟機，需要通過工單向運維部門提統一的申請。當然這個運維部門很适應這種方式，因為原來實體機就是這樣管理的。
但是公有雲，例如 AWS 就沒辦法這樣，租戶千千萬萬，隻能他們自己操作。
在私有雲裡面，随着服務化甚至微服務化的進行，服務數目越來越多，疊代速度越來越快，業務部門需要更加頻繁的建立和消耗虛拟機，如果還是由運維部統一審批，統一操作，會使得運維部門壓力非常大。
而且還會極大限制了疊代速度，因而要引入租戶管理，運維部靈活配置每個租戶的配額 quota 和 QoS，在這個配額裡面，業務部門随時可以按照自己的需要，建立和删除虛拟機，無需知會運維部門。
每個部門都可以建立自己的虛拟網絡 VPC，不同租戶的 VPC 之前完全隔離。
是以網段可以沖突，每個業務部門自己規劃自己的網絡架構，隻有少數的機器需要被外網或者機房通路的時候，需要少數的機房 IP。
這個也是和租戶映射起來的，可以在配置設定給業務部門機房網 IP 的個數範圍内，自由的使用。這樣每個部門自主操作，疊代速度就能夠加快了。
雲平台中的開源軟體的代表是 OpenStack，建議大家研究 OpenStack 的設計機制，是在雲裡面通用的，了解了 OpenStack，對于公有雲，容器雲，都能發現相似的概念和機制。
通過我們研究 OpenStack，我們會發現很多非常好的雲平台設計模式。
第一：基于 PKI Token 的認證模式
如果我們要實作一個 Restful API，希望有個統一的認證中心的話，Keystone 的三角形工作模式是常用的。
當我們要通路一個資源，通過使用者名密碼或者 AK/SK 登入之後，如果認證通過，接下來對于資源的通路，不應該總帶着使用者名密碼，而是登入的時候形成一個 Token，然後通路資源的時候帶着 Token，服務端通過 Token 去認證中心進行驗證即可。
如果每次驗證都去認證中心，效率比較差，後來就有了 PKI Token，也即 Token 解密出來是一個有詳細租戶資訊的字元串，這樣本地就可以進行認證和鑒權。
第二：基于 Role Based Access Control 的鑒權模式
對于權限控制，我們學會比較通用的 Role Based Access Control 的權限控制模式， 形成“使用者-角色-權限”的授權模型。
在這種模型中，使用者與角色之間，角色與權限之間，一般兩者是多對多的關系，可以非常靈活的控制權限。
第三：基于 Quota 的配額管理
可以通過設定計算，網絡，存儲的 quota，設定某個租戶自己可以自主操作的資源量。
第四：基于預選和優選兩階段的 Scheduler 機制
當需要從一個資源池裡面，選擇一個節點，使用這個節點上的資源的時候，一個通用的 Scheduler 機制是：
首先進行預選，也即通過 Filter，将不滿足條件的過濾掉。
然後進行優選，也即對于過濾後，滿足條件的候選人，通過計算權重，選擇其中最優的。
第五：基于獨立虛拟子網的網絡模式
為了每個租戶可以獨立操作，因而虛拟網絡應該是獨立于實體網絡的，這樣不同的租戶可以進行獨立的網絡規劃而互不影響，也不影響實體網絡，當需要跨租戶通路，或者要通路實體網絡的時候，需要通過路由器。
第六：基于 Copy On Write 的鏡像機制
有時候我們在虛拟機裡面做了一些操作以後，希望能夠把這個時候的鏡像儲存下來，好随時恢複到這個時間點，一個最最簡單的方法就是完全複制一份，但是由于鏡像太大了，這樣效率很差。
因而采取 Copy On Write 的機制，當打鏡像的時刻，并沒有新的存儲消耗，而是當寫入新的東西的時候，将原來的資料找一個地方複制儲存下來，這就是 Copy On Write。
對于 Openstack，有一種鏡像 qcow2 就是采取的這樣的機制。
這樣鏡像就像分層一樣，一層一層的羅列上去。
第七：基于 namespace 和 cgroup 的隔離和 Qos 機制
在 OpenStack 裡面，網絡節點的路由器是由 network namespace 來隔離的。
KVM 的占用的 CPU 和記憶體，使用 Cgroup 來隔離的。
網絡的 QoS 使用 TC 來隔離的。
第八：基于 iptables 的安全機制
有時候，我們希望網絡中的節點之間不能互相通路，作為最簡單的防火牆，iptables 起到了很重要的作用，以後實作 ACL 機制的，都可以考慮使用 iptables。
基于 Mesos 和 Kubernetes 了解容器平台
搭建完畢虛拟化層和雲平台層，接下來就是容器層了。Docker 有幾個核心技術，一個是鏡像，一個是運作時，運作時又分看起來隔離的 namespace 和用起來隔離的 cgroup。
Docker 的鏡像也是一種 Copy On Write 的鏡像格式，下面的層級是隻讀的，所有的寫入都在最上層。
對于運作時，Docker 使用的 namespace 除了 network namespace 外，還有很多，如下表格所示。
Docker 對于 cgroup 的使用是在運作 Docker 的時候，在路徑 /sys/fs/cgroup/cpu/docker/ 下面控制容器運作使用的資源。
可見容器并沒有使用更新的技術，而是一種新型的傳遞方式，也即應用的傳遞應該是一容器鏡像的方式傳遞，容器一旦啟動起來，就不應該進入容器做各種修改，這就是不可改變基礎設施。
由于容器的鏡像不包含作業系統核心，因而小的多，可以進行跨環境的遷移和彈性伸縮。
有了容器之後，接下來就是容器平台的選型，其實 Swarm、Mesos、Kubernetes 各有優勢，也可以在不同的階段，選擇使用不同的容器平台。
基于 Mesos 的 DCOS 更像是一個資料中心管理平台，而非僅僅容器管理平台，它可以相容 Kubernetes 的編排，同時也能跑各種大資料應用。
在容器領域，基于 Kubernetes 的容器編排已經成為事實标準。
當我們深入分析 Kubernetes 管理容器模式的時候，我們也能看到熟悉的面孔。
在 Kubernetes 裡面，租戶之間靠 namespace 進行隔離，這個不是 Docker 的 namespace，而是 Kubernetes 的概念。
API Server 的鑒權，也是基于 Role Based Access Control 模式的。Kubernetes 對于 namespace，也有 Quota 配置，使用 ResourceQuota。
當 Kubernetes 想選擇一個節點運作 pod 的時候，選擇的過程也是通過預選和優選兩個階段：
預選(Filtering)
- PodFitsResources 滿足資源。
- PodSelectorMatches 符合标簽。
- PodFitsHost 符合節點名稱。
優選(Weighting)
- LeastRequestedPriority 資源消耗最小。
- BalancedResourceAllocation 資源使用最均衡。
Kubernetes 規定了以下的網絡模型定義：
- 所有的容器都可以在不使用 NAT 的情況下同别的容器通信。
- 所有的節點都可以在不使用 NAT 的情況下同所有的容器通信。
- 容器的位址和别人看到的位址一樣。
也即容器平台應該有自己的私有子網，常用的有 Flannel、Calico、Openvswitch 都是可以的。
既可以使用 Overlay 的方式，如圖 Flannel：
也可以使用 BGP 的方式，如圖 Calico：
基于 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 都做了的合成一個階段，這樣中間不用落盤，但是到了需要合并的地方，還是需要落盤的。
基于 Lucene 和 ElasticSearch 了解搜尋引擎
當大資料将收集好的資料處理完畢之後，一般會儲存在兩個地方，一個是正向索引，可以用 Hbase，Cassandra 等文檔存儲，一個是反向索引，友善搜尋，就會儲存在基于 Lucene 的 ElasticSearch 裡面。
基于 Spring Cloud 了解微服務
最後到了應用架構，也即微服務。接下來細說微服務架構設計中不得不知的十大要點。
設計要點一：負載均衡 + 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，就復原到上一個版本了。所有的操作在代碼倉庫裡都是可以看到的。
設計要點七：統一配置中心
服務拆分以後，服務的數量非常多，如果所有的配置都以配置檔案的方式放在應用本地的話，非常難以管理。
可以想象當有幾百上千個程序中有一個配置出現了問題，是很難将它找出來的，因而需要有統一的配置中心，來管理所有的配置，進行統一的配置下發。
在微服務中，配置往往分為以下幾類：
一類是幾乎不變的配置，這種配置可以直接打在容器鏡像裡面。
第二類是啟動時就會确定的配置，這種配置往往通過環境變量，在容器啟動的時候傳進去。
第三類就是統一的配置，需要通過配置中心進行下發。例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置檔案中統一配置。
設計要點八：統一日志中心
同樣是程序數目非常多的時候，很難對成千上百個容器，一個一個登入進去檢視日志，是以需要統一的日志中心來收集日志。
為了使收集到的日志容易分析，對于日志的規範，需要有一定的要求，當所有的服務都遵守統一的日志規範的時候，在日志中心就可以對一個交易流程進行統一的追溯。
例如在最後的日志搜尋引擎中，搜尋交易号，就能夠看到在哪個過程出現了錯誤或者異常。
設計要點九：熔斷，限流，降級
服務要有熔斷，限流，降級的能力，當一個服務調用另一個服務，出現逾時的時候，應及時傳回，而非阻塞在那個地方，進而影響其他使用者的交易，可以傳回預設的托底資料。
當一個服務發現被調用的服務，因為過于繁忙，線程池滿，連接配接池滿，或者總是出錯，則應該及時熔斷，防止因為下一個服務的錯誤或繁忙，導緻本服務的不正常，進而逐漸往前傳導，導緻整個應用的雪崩。
當發現整個系統的确負載過高的時候，可以選擇降級某些功能或某些調用，保證最重要的交易流程的通過，以及最重要的資源全部用于保證最核心的流程。
還有一種手段就是限流，當既設定了熔斷政策，又設定了降級政策，通過全鍊路的壓力測試，應該能夠知道整個系統的支撐能力。
因而就需要制定限流政策，保證系統在測試過的支撐能力範圍内進行服務，超出支撐能力範圍的，可拒絕服務。
當你下單的時候，系統彈出對話框說 “系統忙，請重試”，并不代表系統挂了，而是說明系統是正常工作的，隻不過限流政策起到了作用。
設計要點十：全方位的監控
當系統非常複雜的時候，要有統一的監控，主要有兩個方面，一個是是否健康，一個是性能瓶頸在哪裡。
當系統出現異常的時候，監控系統可以配合告警系統，及時地發現，通知，幹預，進而保障系統的順利運作。
當壓力測試的時候，往往會遭遇瓶頸，也需要有全方位的監控來找出瓶頸點，同時能夠保留現場，進而可以追溯和分析，進行全方位的優化。