資深大牛吐血總結(jié)：如何成為一名合格的云架構(gòu)師?

作者：劉超 2018-10-31 09:32:19

開發(fā)

架構(gòu)

云計(jì)算 云架構(gòu)師負(fù)責(zé)管理一個(gè)組織中的云計(jì)算架構(gòu)，特別是隨著云技術(shù)日益復(fù)雜化。云計(jì)算架構(gòu)涵蓋了與云計(jì)算相關(guān)的一切，包括管理云存儲(chǔ)所需的前端平臺(tái)、服務(wù)器、存儲(chǔ)、交付和網(wǎng)絡(luò)。

創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計(jì)制作、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的墊江網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

 云架構(gòu)師負(fù)責(zé)管理一個(gè)組織中的云計(jì)算架構(gòu)，特別是隨著云技術(shù)日益復(fù)雜化。云計(jì)算架構(gòu)涵蓋了與云計(jì)算相關(guān)的一切，包括管理云存儲(chǔ)所需的前端平臺(tái)、服務(wù)器、存儲(chǔ)、交付和網(wǎng)絡(luò)。

本文作者從如下幾個(gè)方面全面剖析云架構(gòu)師的進(jìn)階攻略：

• 架構(gòu)的三個(gè)維度和六個(gè)層面
• 了解云計(jì)算的歷史演進(jìn)與基本原理
• 開源軟件是進(jìn)階的利器
• 了解 Linux 基礎(chǔ)知識(shí)
• 了解數(shù)據(jù)中心和網(wǎng)絡(luò)基礎(chǔ)知識(shí)
• 基于 KVM 了解計(jì)算虛擬化
• 基于 Openvswitch 了解網(wǎng)絡(luò)虛擬化
• 基于 OpenStack 了解云平臺(tái)
• 基于 Mesos 和 Kubernetes 了解容器平臺(tái)
• 基于 Hadoop 和 Spark 了解大數(shù)據(jù)平臺(tái)
• 基于 Lucene 和 ElasticSearch 了解搜索引擎
• 基于 Spring Cloud 了解微服務(wù)

架構(gòu)的三個(gè)維度和六個(gè)層面

三個(gè)維度

在互聯(lián)網(wǎng)時(shí)代，要做好一個(gè)合格的云架構(gòu)師，需要熟悉三大架構(gòu)。

IT 架構(gòu)

IT 架構(gòu)其實(shí)就是計(jì)算，網(wǎng)絡(luò)，存儲(chǔ)。這是云架構(gòu)師的基本功，也是最傳統(tǒng)的云架構(gòu)師應(yīng)該首先掌握的部分。

良好設(shè)計(jì)的 IT 架構(gòu)，可以降低 CAPEX 和 OPEX，減輕運(yùn)維的負(fù)擔(dān)。數(shù)據(jù)中心，虛擬化，云平臺(tái)，容器平臺(tái)都屬于 IT 架構(gòu)的范疇。

應(yīng)用架構(gòu)

隨著應(yīng)用從傳統(tǒng)應(yīng)用向互聯(lián)網(wǎng)應(yīng)用轉(zhuǎn)型，僅僅搞定資源層面的彈性還不夠，常常會(huì)出現(xiàn)創(chuàng)建了大批機(jī)器，仍然撐不住高并發(fā)流量。因而基于微服務(wù)的互聯(lián)網(wǎng)架構(gòu)，越來越成為云架構(gòu)師所必需的技能。

良好設(shè)計(jì)的應(yīng)用架構(gòu)，可以實(shí)現(xiàn)快速迭代和高并發(fā)。數(shù)據(jù)庫，緩存，消息隊(duì)列等 PaaS，以及基于 Spring Cloud 和 Dubbo 的微服務(wù)框架，都屬于應(yīng)用架構(gòu)的范疇。

數(shù)據(jù)架構(gòu)

數(shù)據(jù)成為人工智能時(shí)代的核心資產(chǎn)，在做互聯(lián)網(wǎng)化轉(zhuǎn)型的同時(shí)，往往進(jìn)行的也是數(shù)字化轉(zhuǎn)型，并有戰(zhàn)略的進(jìn)行數(shù)據(jù)收集，這就需要云架構(gòu)師同時(shí)有大數(shù)據(jù)思維。

有意識(shí)的建設(shè)統(tǒng)一的數(shù)據(jù)平臺(tái)，并給予數(shù)據(jù)進(jìn)行數(shù)字化運(yùn)營。搜索引擎，Hadoop，Spark，人工智能都屬于數(shù)據(jù)架構(gòu)的范疇。

六個(gè)層面

上面的三個(gè)維度是從人的角度出發(fā)的，如果從系統(tǒng)的角度出發(fā)，架構(gòu)分六個(gè)層次。

基礎(chǔ)設(shè)施層

在數(shù)據(jù)中心里面，會(huì)有大量的機(jī)架，大量的服務(wù)器，并通過交換機(jī)和路由器將服務(wù)器連接起來，有的應(yīng)用例如 Oracle 是需要部署在物理機(jī)上的。

為了管理的方便，在物理機(jī)之上會(huì)部署虛擬化，例如 Vmware，可以將對于物理機(jī)復(fù)雜的運(yùn)維簡化為虛擬機(jī)靈活的運(yùn)維。

虛擬化采取的運(yùn)維方式多是由運(yùn)維部門統(tǒng)一管理，當(dāng)一個(gè)公司里面部門非常多的時(shí)候，往往要引入良好的租戶管理。

基于 Quota 和 QoS 的資源控制，基于 VPC 的網(wǎng)絡(luò)規(guī)劃等，實(shí)現(xiàn)從運(yùn)維集中管理到租戶自助使用模式的轉(zhuǎn)換，托生于公有云的 OpenStack 在這方面做的是比較好的。

隨著應(yīng)用架構(gòu)越來越重要，對于標(biāo)準(zhǔn)化交付和彈性伸縮的需求越來越大，容器做為軟件交付的集裝箱，可以實(shí)現(xiàn)基于鏡像的跨環(huán)境遷移，Kubernetes 是容器管理平臺(tái)的事實(shí)標(biāo)準(zhǔn)。

數(shù)據(jù)層

數(shù)據(jù)層，也即一個(gè)應(yīng)用的中軍大營，如果是傳統(tǒng)應(yīng)用，可能會(huì)使用 Oracle，并使用大量的存儲(chǔ)過程，有大量的表聯(lián)合查詢，成本也往往比較高。

但是對于高并發(fā)的互聯(lián)網(wǎng)應(yīng)用，需要進(jìn)行微服務(wù)的拆分，數(shù)據(jù)庫實(shí)例會(huì)比較多，使用開源的 MySQL 是常見的選擇。

大量的存儲(chǔ)過程和聯(lián)合查詢往往會(huì)使得微服務(wù)無法拆分，性能會(huì)比較差，因而需要放到應(yīng)用層去做復(fù)雜的業(yè)務(wù)邏輯，而且數(shù)據(jù)庫表和索引的設(shè)計(jì)非常重要。

當(dāng)并發(fā)量比較大的時(shí)候，需要實(shí)現(xiàn)橫向擴(kuò)展，就需要基于分布式數(shù)據(jù)庫，也是需要基于單庫良好的表和索引設(shè)計(jì)。

對于結(jié)構(gòu)比較靈活的數(shù)據(jù)，可以使用 MongoDB 數(shù)據(jù)庫，橫向擴(kuò)展能力比較好。

對于大量的聯(lián)合查詢需求，可以使用 ElasticSearch 之類的搜索引擎來做，速度快，更加靈活。

中間件層

因?yàn)閿?shù)據(jù)庫層往往需要保證數(shù)據(jù)的不丟失以及一些事務(wù)，因而并發(fā)性能不可能非常大。

所以我們經(jīng)常說，數(shù)據(jù)庫是中軍大營，不能所有的請求都到這里來，因而需要一層緩存層，用來攔截大部分的熱點(diǎn)請求。

Memcached 適合做簡單的 key-value 存儲(chǔ)，內(nèi)存使用率比較高，而且由于是多核處理，對于比較大的數(shù)據(jù)，性能較好。

但是缺點(diǎn)也比較明顯，Memcached 嚴(yán)格來講沒有集群機(jī)制，橫向擴(kuò)展完全靠客戶端來實(shí)現(xiàn)。

另外 Memcached 無法持久化，一旦掛了數(shù)據(jù)就都丟失了，如果想實(shí)現(xiàn)高可用，也是需要客戶端進(jìn)行雙寫才可以。

Redis 的數(shù)據(jù)結(jié)構(gòu)比較豐富，提供持久化的功能，提供成熟的主備同步，故障切換的功能，從而保證了高可用性。

另外微服務(wù)拆分以后，有時(shí)候處理一個(gè)訂單要經(jīng)過非常多的服務(wù)，處理過程會(huì)比較慢，這個(gè)時(shí)候需要使用消息隊(duì)列，讓服務(wù)之間的調(diào)用變成對于消息的訂閱，實(shí)現(xiàn)異步處理。

RabbitMQ 和 Kafka 是常用的消息隊(duì)列，當(dāng)事件比較重要的時(shí)候，會(huì)結(jié)合數(shù)據(jù)庫實(shí)現(xiàn)可靠消息隊(duì)列。

基礎(chǔ)服務(wù)層

有的時(shí)候成為中臺(tái)層，將通用的能力抽象為服務(wù)對外提供原子化接口。

這樣上層可以根據(jù)業(yè)務(wù)需求，通過靈活的組合這些原子化接口，靈活的應(yīng)對業(yè)務(wù)需求的變化，實(shí)現(xiàn)能力的復(fù)用，以及數(shù)據(jù)的統(tǒng)一管理，例如用戶數(shù)據(jù)，支付數(shù)據(jù)，不會(huì)分散到各個(gè)應(yīng)用中。

另外基礎(chǔ)服務(wù)層稱為應(yīng)用、數(shù)據(jù)庫和緩存的一個(gè)分界線，不應(yīng)該所有的應(yīng)用都直接連數(shù)據(jù)庫，一旦出現(xiàn)分庫分表，數(shù)據(jù)庫遷移，緩存選型改變等，影響面會(huì)非常大，幾乎無法執(zhí)行。

如果將這些底層的變更攔截在基礎(chǔ)服務(wù)層，上層僅僅使用基礎(chǔ)服務(wù)層的接口，這樣底層的變化會(huì)對上層透明，可以逐步演進(jìn)。

業(yè)務(wù)服務(wù)層或者組合服務(wù)層

大部分的業(yè)務(wù)邏輯都是在這個(gè)層面實(shí)現(xiàn)，業(yè)務(wù)邏輯比較面向用戶，因而會(huì)經(jīng)常改變，所以需要組合基礎(chǔ)服務(wù)的接口進(jìn)行實(shí)現(xiàn)。

在這一層，會(huì)經(jīng)常進(jìn)行服務(wù)的拆分，實(shí)現(xiàn)開發(fā)獨(dú)立，上線獨(dú)立，擴(kuò)容獨(dú)立，容災(zāi)降級獨(dú)立。

微服務(wù)的拆分不應(yīng)該是一個(gè)運(yùn)動(dòng)，而應(yīng)該是一個(gè)遇到耦合痛點(diǎn)的時(shí)候，不斷解決，不斷演進(jìn)的一個(gè)過程。

微服務(wù)拆分之后，有時(shí)候需要通過分布式事務(wù)，保證多個(gè)操作的原子性，也是在組合服務(wù)層來實(shí)現(xiàn)的。

用戶接口層

用戶接口層，也即對終端客戶呈現(xiàn)出來的界面和 App，但是卻不僅僅是界面這么簡單。

這一層有時(shí)候稱為接入層。在這一層，動(dòng)態(tài)資源和靜態(tài)資源應(yīng)該分離，靜態(tài)資源應(yīng)該在接入層做緩存，使用 CDN 進(jìn)行緩存。

也應(yīng)該 UI 和 API 分離，界面應(yīng)該通過組合 API 進(jìn)行數(shù)據(jù)拼裝。API 會(huì)通過統(tǒng)一的 API 網(wǎng)關(guān)進(jìn)行統(tǒng)一的管理和治理。

一方面后端組合服務(wù)層的拆分對 APP 是透明的;另一方面當(dāng)并發(fā)量比較大的時(shí)候，可以在這一層實(shí)現(xiàn)限流和降級。

為了支撐這六個(gè)層次，在上圖的左側(cè)是一些公共能力：

• 持續(xù)集成和持續(xù)發(fā)布是保證微服務(wù)拆分過程中的快速迭代，以及變更后保證功能不變的，不引入新的 Bug。
• 服務(wù)發(fā)現(xiàn)和服務(wù)治理是微服務(wù)之間互相的調(diào)用，以及調(diào)用過程中出現(xiàn)異常情況下的熔斷，限流，降級策略。
• 大數(shù)據(jù)和人工智能是通過收集各個(gè)層面的數(shù)據(jù)，例如用戶訪問數(shù)據(jù)，用戶下單數(shù)據(jù)，客服詢問數(shù)據(jù)等，結(jié)合統(tǒng)一的中臺(tái)，對數(shù)據(jù)進(jìn)行分析，實(shí)現(xiàn)智能推薦。
• 監(jiān)控與 APM 是基礎(chǔ)設(shè)施的監(jiān)控和應(yīng)用的監(jiān)控，發(fā)現(xiàn)資源層面的問題以及應(yīng)用調(diào)用的問題。

作為一個(gè)云架構(gòu)師還是很復(fù)雜的，千里之行，始于足下，讓我們慢慢來。

了解云計(jì)算的歷史演進(jìn)與基本原理

在一頭扎進(jìn)云計(jì)算的汪洋大海之前，我們應(yīng)該先有一個(gè)全貌的了解，有人說了解一個(gè)知識(shí)的起點(diǎn)，就是了解它的歷史，也就是知道它是如何一步一步到今天的，這樣如此龐大的一個(gè)體系，其實(shí)是逐步加進(jìn)來的。

這樣的知識(shí)體系對我們來說，就不是一個(gè)冷冰冰的知識(shí)網(wǎng)，而是一個(gè)有血有肉的人，我們只要沿著演進(jìn)的線索，一步一步摸清楚“它”的脾氣就可以了。

如何把云計(jì)算講的通俗易懂，我本人思考了半天，最終寫下了下面這篇文章：終于有人把云計(jì)算、大數(shù)據(jù)和人工智能講明白了!在這里，我把核心的要點(diǎn)在這里寫一下。

第一：云計(jì)算的本質(zhì)是實(shí)現(xiàn)從資源到架構(gòu)的全面彈性。

所謂的彈性就是時(shí)間靈活性和空間靈活性，也即想什么時(shí)候要就什么時(shí)候要，想要多少就要多少。

資源層面的彈性也即實(shí)現(xiàn)計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)資源的彈性。這個(gè)過程經(jīng)歷了從物理機(jī)，到虛擬化，到云計(jì)算的一個(gè)演進(jìn)過程。

架構(gòu)層面的彈性也即實(shí)現(xiàn)通用應(yīng)用和自有應(yīng)用的彈性擴(kuò)展。對于通用的應(yīng)用，多集成為 PaaS 平臺(tái)。

對于自己的應(yīng)用，通過基于腳本的 Puppet、Chef、Ansible 到基于容器鏡像的容器平臺(tái) CaaS。

第二：大數(shù)據(jù)包含數(shù)據(jù)的收集，數(shù)據(jù)的傳輸，數(shù)據(jù)的存儲(chǔ)，數(shù)據(jù)的處理和分析，數(shù)據(jù)的檢索和挖掘等幾個(gè)過程。

當(dāng)數(shù)據(jù)量很小時(shí)，很少的幾臺(tái)機(jī)器就能解決。慢慢的，當(dāng)數(shù)據(jù)量越來越大，最牛的服務(wù)器都解決不了問題時(shí)，怎么辦呢?

這時(shí)就要聚合多臺(tái)機(jī)器的力量，大家齊心協(xié)力一起把這個(gè)事搞定，眾人拾柴火焰高。

第三：人工智能經(jīng)歷了基于專家系統(tǒng)的計(jì)劃經(jīng)濟(jì)，基于統(tǒng)計(jì)的宏觀調(diào)控，基于神經(jīng)網(wǎng)絡(luò)的微觀經(jīng)濟(jì)學(xué)三個(gè)階段。

開源軟件是進(jìn)階的利器

架構(gòu)師除了要掌握大的架構(gòu)和理論之外，指導(dǎo)落地也是必備的技能，所謂既要懂設(shè)計(jì)模式，也要懂代碼。那從哪里去學(xué)習(xí)這些良好的，有借鑒意義的，可以落地的架構(gòu)實(shí)踐呢?

這個(gè)世界上還是有很多有情懷的大牛的，尤其是程序員里面，他們喜歡做一件什么事情呢?答案是開源。很多軟件都是有閉源就有開源，源就是源代碼。

當(dāng)某個(gè)軟件做的好，所有人都愛用，這個(gè)軟件的代碼呢，我封閉起來只有我公司知道，其他人不知道，如果其他人想用這個(gè)軟件，就要付我錢，這就叫閉源。但是世界上總有一些大牛看不慣錢都讓一家賺了去。

大牛們覺得，這個(gè)技術(shù)你會(huì)我也會(huì)，你能開發(fā)出來，我也能，我開發(fā)出來就是不收錢，把代碼拿出來分享給大家，全世界誰用都可以，所有的人都可以享受到好處，這個(gè)叫做開源。

非常建議大家了解，深入研究，甚至參與貢獻(xiàn)開源軟件，因?yàn)槭找娣藴\。

第一：通過開源軟件，我們可以了解大牛們的架構(gòu)原則，設(shè)計(jì)模式。

其實(shí)咱們平時(shí)的工作中，是很難碰到大牛的，他可能是你渴望而不可及的公司的員工，甚至在國外，你要想進(jìn)這種公司，不刷個(gè)幾年題目，面試個(gè) N 輪是進(jìn)不去的。

即便進(jìn)去了，他可能是公司的高層，每天很忙，不怎么見得到他，就算當(dāng)面討教，時(shí)間也不會(huì)很長，很難深入交流。

也有的大牛會(huì)選擇自主創(chuàng)業(yè)，或者是自由職業(yè)者，神龍見首不見尾，到了大公司都見不到。

但是感謝互聯(lián)網(wǎng)和開源社區(qū)，將大牛們拉到了我們身邊，你可以訂閱郵件組，可以加入討論群，可以看到大牛們的設(shè)計(jì)，看到很多人的評論，提問，還有大牛的回答，可以看到大牛的設(shè)計(jì)也不是一蹴而就完美的，看到逐漸演進(jìn)的過程，等等。

這些都是能夠幫助我們快速提升水平的地方，有的時(shí)候，拿到一篇設(shè)計(jì)，都要查資料看半天，一開始都可能好多的術(shù)語都看不懂，沒關(guān)系肯下功夫，當(dāng)你看 blueprints 越來越順暢的時(shí)候，你就進(jìn)步了。

第二：通過開源軟件，我們可以學(xué)習(xí)到代碼級的落地實(shí)踐。

有時(shí)候我們能看到很多大牛寫的書和文章，也能看到很多理論的書籍，但是存在一個(gè)問題是，理論都懂，但是還是做不好架構(gòu)。

這是因?yàn)闆]有看到代碼，所有的理論都是空中樓閣，當(dāng)你到了具體的代碼設(shè)計(jì)層面，那些學(xué)會(huì)的設(shè)計(jì)模式，無法轉(zhuǎn)化為你自己的實(shí)踐。

好在開源軟件的代碼都是公開的，凝結(jié)了大牛的心血，也能夠看到大牛在具體落地時(shí)候的取舍，一切那么真實(shí)，看得見，摸得著。

通過代碼進(jìn)行學(xué)習(xí)，配合理論知識(shí)，更容易獲得第一手的經(jīng)驗(yàn)，并且在自己做設(shè)計(jì)和寫代碼的時(shí)候，馬上能夠映射到可以參考的場景，讓我們在做自己的系統(tǒng)的時(shí)候，少走彎路。

第三：通過開源軟件，我們可以加入社區(qū)，和其他技術(shù)人員在同一背景下共同進(jìn)步。

大牛我們往往不容易接觸到，正面討論技術(shù)問題的時(shí)間更是難能可貴，但是沒有關(guān)系，開源軟件構(gòu)建了一個(gè)社區(qū)，大家可以在一起討論。

你是怎么理解的，別人是怎么理解的，越討論越交流，越明晰，有時(shí)候和比你經(jīng)驗(yàn)稍微豐富一點(diǎn)的技術(shù)人員交流，可能比直接和大牛對話更加有直接作用。

大牛的話可能讓你消化半天，依然不知所云，大牛可能覺得很多普通人覺得的難點(diǎn)是顯而易見的，不屑去解釋。

但是社區(qū)里面的技術(shù)人員，可能和你一樣慢慢進(jìn)步過來的，知道哪些點(diǎn)是當(dāng)年自己困惑的，如果踩過這一個(gè)個(gè)的坑，他們一點(diǎn)撥，你就會(huì)豁然開朗。

而且每個(gè)人遇到的具體情況不同，從事的行業(yè)不同，客戶的需求不同，因而軟件設(shè)計(jì)的時(shí)候考慮的因素不同。

大牛是牛，但是不一定能夠遇到和你一樣的場景，但是社區(qū)里面，有你的同行業(yè)的，背景相近的技術(shù)人員，你們可以討論出符合你們特定場景的解決方案。

第四：通過開源軟件，我們作為個(gè)人，比較容易找到工作。

我們面試的時(shí)候，常常遇到的問題是，怎么能夠把在原來工作中自己的貢獻(xiàn)，理解，設(shè)計(jì)，技術(shù)能力展現(xiàn)出來。

其實(shí)我發(fā)現(xiàn)很多程序員不能很好的做到這一點(diǎn)，所以造成很多人面試很吃虧。

原因之一：背景信息不對稱。例如原來面臨的業(yè)務(wù)上很難的問題，面試官由于不理解背景，而且短時(shí)間解釋不清楚，輕視候選人的水平。

我也遇到過很多面試官才聽了幾分鐘，就會(huì)說，這不挺簡單的，你這樣這樣不就行了，然后徹底否定你們一個(gè)團(tuán)隊(duì)忙了三年的事情。

原因之二：很多有能力的程序員不會(huì)表達(dá)，導(dǎo)致真正寫代碼的說不明白?？赡茉瓉碓诠纠锩嬉粋€(gè)績效非常好，一個(gè)績效非常差，但是到了面試官那里就拉平了。

原因之三：新的公司不能確定你在上家公司做的工作，到這一家都能用的。例如你做的工作有 30% 是和具體業(yè)務(wù)場景相關(guān)的，70% 是通用技術(shù)，可能下家公司只會(huì)為你的通用技術(shù)部分買單。

開源軟件的好處就是，參與的人所掌握的技能都是通的，而且大家在同一個(gè)上下文里面對話，面試官和候選人之間的信息差比較少。掌握某個(gè)開源軟件有多難，不用候選人自己說，大家心里都有數(shù)。

對于很多技術(shù)能力強(qiáng)，但是表達(dá)能力較弱的極少數(shù)人員來講，talk is cheap，show me the code。

代碼呈上去，就能夠表現(xiàn)出實(shí)力來了，而且面試官也不需要根據(jù)短短的半個(gè)小時(shí)了解一個(gè)人，可以做很多背景調(diào)查。

另外由于掌握的技術(shù)是通用的，你到下一家公司，馬上就能夠上手，幾乎不需要預(yù)熱時(shí)間，對于雙方都有好處。

第五：通過開源軟件，我們作為招聘方，比較容易招到相應(yīng)人員。

如果在創(chuàng)業(yè)公司待過的朋友會(huì)了解到創(chuàng)業(yè)公司招人很難，人員流失很快，而且創(chuàng)業(yè)公司往往對于開發(fā)進(jìn)度要求很快，因?yàn)榇蠹叶荚趽寱r(shí)間。

因而開源軟件對于招聘方來講，也是好消息。首先創(chuàng)業(yè)公司沒辦法像大公司一樣，弄這么多的技術(shù)大牛，自己完全落地一套自己的體系，使用開源軟件快速搭建一套平臺(tái)先上線是最好的選擇。

其次使用開源軟件，會(huì)使得招聘相對容易，市場上火的開源軟件會(huì)有大批的從業(yè)者，參與各種論壇和社區(qū)，比較容易挖到人。

最后，開源軟件的使用使得新人來了之后沒有預(yù)熱時(shí)間，來了就上手，保證開發(fā)速度。

那如何快速上手一款開源軟件呢?我總結(jié)了如下九個(gè)步驟：

• 手動(dòng)安裝起來，一定要手動(dòng)。
• 使用一下，推薦 XXX in Action 系列。
• 讀文檔，讀所有的官方文檔，記不住，看不懂也要讀下來。
• 了解核心的原理和算法，推薦 XXX the definitive guide 系列。
• 看一本源碼分析的書，會(huì)讓你的源碼閱讀之旅事半功倍。
• 開始閱讀核心邏輯源代碼。
• 編譯并 Debug 源代碼。
• 開發(fā)一個(gè)插件，或者對組件做少量的修改。
• 大量的運(yùn)維實(shí)踐經(jīng)驗(yàn)和面向真實(shí)場景的定制開發(fā)。
• 所以做一個(gè)云架構(gòu)師，一定不能脫離代碼，反而要不斷的擁抱開源軟件。

了解 Linux 基礎(chǔ)知識(shí)

作為一個(gè)云架構(gòu)師，首要的一點(diǎn)，就是要熟悉 Linux 的基礎(chǔ)知識(shí)，基本原理了。

說到操作系統(tǒng)，一般有三個(gè)維度：

• 桌面操作系統(tǒng)
• 移動(dòng)操作系統(tǒng)
• 服務(wù)器操作系統(tǒng)

Stack Overflow Developer Survey 2018 有這樣一個(gè)統(tǒng)計(jì)，對于開發(fā)人員來說，桌面操作系統(tǒng)的排名是 Windows，MacOS，Linux，所以大部分人平時(shí)的辦公系統(tǒng)都是 Windows。

當(dāng)然因?yàn)檗k公的原因，平時(shí)使用 Windows 的比較多，所以在學(xué)校里，很多同學(xué)接觸到的操作系統(tǒng)基本上都是 Windows，但是一旦從事計(jì)算機(jī)行業(yè)，就一定要跨過 Linux 這道坎。

根據(jù)今年 W3Techs 的統(tǒng)計(jì)，對于服務(wù)器端，Unix-Like OS 占到的比例為近 70%。所謂 Unix-Like OS 包括下圖的 Linux，BSD 等一系列。

從這個(gè)統(tǒng)計(jì)可以看出，隨著云計(jì)算的發(fā)展，軟件 SaaS 化，服務(wù)化，甚至微服務(wù)化，大部分的計(jì)算都是在服務(wù)端做的，因而要成為云架構(gòu)師，就必須懂 Linux。

隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，客戶端基本上以 Android 和 iOS 為主，下圖是 Gartner 的統(tǒng)計(jì)。

Android 是基于 Linux 內(nèi)核的。因而客戶端也進(jìn)入了 Linux 陣營，很多智能終端，智能設(shè)備等開發(fā)職位，都需要懂 Linux 的人員。

學(xué)習(xí) Linux 主要包含兩部分，一個(gè)是怎么用，一個(gè)是怎么編程，背后原理是什么。

對于怎么用，上手的話，推薦《鳥哥的 Linux 私房菜》，按著這個(gè)手冊，就能夠?qū)W會(huì)基本的 Linux 的使用，如果再深入一點(diǎn)，推薦《Linux 系統(tǒng)管理技術(shù)手冊》，磚頭厚的一本書，是 Linux 運(yùn)維手邊必備。

對于怎么編程，上手的話，推薦《Unix 環(huán)境高級編程》，有代碼，有介紹，有原理，如果對內(nèi)核的原理感興趣，推薦《深入理解 Linux 內(nèi)核》。

Linux 的架構(gòu)如下圖：

我們知道，一臺(tái)物理機(jī)上有很多的硬件，最重要的是 CPU，內(nèi)存，硬盤，網(wǎng)絡(luò)，但是一個(gè)物理機(jī)上要跑很多的程序，這些資源應(yīng)該給誰用呢?當(dāng)然是大家輪著用，誰也別獨(dú)占，誰也別餓死。

為了完成這件事情，操作系統(tǒng)的內(nèi)核就起到了大管家的作用，將硬件資源分配給不同的用戶程序使用，并且在適當(dāng)?shù)臅r(shí)間將資源拿回來，再分配給其他的用戶進(jìn)程，這個(gè)過程稱為調(diào)度。

操作系統(tǒng)的功能之一：系統(tǒng)調(diào)用

當(dāng)用戶程序想請求資源的時(shí)候，需要調(diào)用操作系統(tǒng)的系統(tǒng)調(diào)用接口，這是內(nèi)核和用戶態(tài)程序的分界線。

就像你要打車，要通過打車軟件的界面，下發(fā)打車指令一樣，這樣打車軟件才會(huì)給你調(diào)度一輛車。

操作系統(tǒng)的功能之二：進(jìn)程管理

當(dāng)一個(gè)用戶進(jìn)程運(yùn)行的時(shí)候，內(nèi)核為它分配的資源，總要有一個(gè)數(shù)據(jù)結(jié)構(gòu)保存，哪些資源分配給了這個(gè)進(jìn)程。分配給這個(gè)進(jìn)程的資源往往包括打開的文件，內(nèi)存空間等。

操作系統(tǒng)的功能之三：內(nèi)存管理

每個(gè)進(jìn)程有獨(dú)立的內(nèi)存空間，內(nèi)存空間是進(jìn)程用來存放數(shù)據(jù)的，就像一間一間的倉庫。

為了進(jìn)程使用方便，每個(gè)進(jìn)程內(nèi)存空間，在進(jìn)程的角度來看都是獨(dú)立的，也即都是從 0 號(hào)倉庫，1 號(hào)倉庫，一直到 N 號(hào)倉庫，都是獨(dú)享的。

但是從操作系統(tǒng)內(nèi)核的角度來看，當(dāng)然不可能獨(dú)享，而是大家共享，M 號(hào)倉庫只有一個(gè)，你用他就不能用，這就需要一個(gè)倉庫調(diào)度系統(tǒng)，將用戶進(jìn)程的倉庫號(hào)和實(shí)際使用的倉庫號(hào)對應(yīng)起來。

例如進(jìn)程 1 的 10 號(hào)倉庫，對應(yīng)到真實(shí)的倉庫是 110 號(hào)，進(jìn)程 2 的 20 號(hào)倉庫，對應(yīng)到真實(shí)的倉庫是 120 號(hào)。

操作系統(tǒng)功能之四：文件系統(tǒng)

對于 Linux 來講，很多東西都是文件，例如進(jìn)程號(hào)會(huì)對應(yīng)一個(gè)文件，建立一個(gè)網(wǎng)絡(luò)連接也對應(yīng)一個(gè)文件。文件系統(tǒng)多種多樣，為了能夠統(tǒng)一適配，有一個(gè)虛擬文件系統(tǒng)的中間層 VFS。

操作系統(tǒng)功能之五：設(shè)備管理

設(shè)備分兩種，一種是塊設(shè)備，一種是字符設(shè)備，例如硬盤就是塊設(shè)備，可以格式化為文件系統(tǒng)，再如鼠標(biāo)和鍵盤的輸入輸出是字符設(shè)備。

操作系統(tǒng)功能之六：網(wǎng)絡(luò)管理

對于 Linux 來講，網(wǎng)絡(luò)也是基于設(shè)備和文件系統(tǒng)的，但是由于網(wǎng)絡(luò)有自己的協(xié)議棧，要遵循 TCP/IP 協(xié)議棧標(biāo)準(zhǔn)。

了解數(shù)據(jù)中心和網(wǎng)絡(luò)基礎(chǔ)知識(shí)

云平臺(tái)當(dāng)然會(huì)部署在數(shù)據(jù)中心里面，由于數(shù)據(jù)中心里面的硬件設(shè)備也是非常專業(yè)的，因而很多地方機(jī)房部門和云計(jì)算部門是兩個(gè)部門。

但是作為一個(gè)云架構(gòu)師，需要和機(jī)房部門進(jìn)行溝通，因而需要一定的數(shù)據(jù)中心知識(shí)，在數(shù)據(jù)中心里面，最難搞定的是網(wǎng)絡(luò)，因而這里面網(wǎng)絡(luò)知識(shí)是重中之重。

下面這個(gè)圖是一個(gè)典型的數(shù)據(jù)中心圖：

最外層是 Internet Edge，也叫 Edge Router，也叫 Border Router，它提供數(shù)據(jù)中心與 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

第二層也即每個(gè) AZ 的最上層，我們稱為 Aggregation Layer。

第三層是 Access Layer，就是一個(gè)個(gè)機(jī)架的服務(wù)器，用接入交換機(jī)連接在一起。

這是一個(gè)典型的三層網(wǎng)絡(luò)結(jié)構(gòu)，也即接入層、匯聚層、核心層三層。除了數(shù)據(jù)中心以外，哪怕是做應(yīng)用架構(gòu)，對于網(wǎng)絡(luò)的了解也是必須的。

云架構(gòu)說到底是分布式架構(gòu)，既然是分布式，就是去中心化的，因而就需要系統(tǒng)之間通過網(wǎng)絡(luò)進(jìn)行互通，因而網(wǎng)絡(luò)是作為大規(guī)模系統(tǒng)架構(gòu)繞不過去的一個(gè)坎。

對于網(wǎng)絡(luò)的基本原理，推薦書籍《計(jì)算機(jī)網(wǎng)絡(luò)-嚴(yán)偉與潘愛民譯》，《計(jì)算機(jī)網(wǎng)絡(luò)：自頂向下方法》。

對于 TCP/IP 協(xié)議棧的了解，推薦書籍《TCP/IP 詳解》，《The TCP/IP Guide》。

對于網(wǎng)絡(luò)程序設(shè)計(jì)，推薦書籍《Unix 網(wǎng)絡(luò)編程》，如果你想了解網(wǎng)絡(luò)協(xié)議棧的實(shí)現(xiàn)，推薦書籍《深入理解 Linux 網(wǎng)絡(luò)內(nèi)幕》 。

基于 KVM 了解計(jì)算虛擬化

當(dāng)物理機(jī)搭建完畢之后，接下來就是基于物理機(jī)上面搭建虛擬機(jī)了。

沒有了解虛擬機(jī)的同學(xué)，可以在自己的筆記本電腦上用 VirtualBox 或者 Vmware 創(chuàng)建虛擬機(jī)，你會(huì)發(fā)現(xiàn)，很容易就能在物理機(jī)的操作系統(tǒng)之內(nèi)再安裝多個(gè)操作系統(tǒng)。

通過這種方式，你可以很方便的在 Windows 辦公系統(tǒng)之內(nèi)安裝一個(gè) Linux 系統(tǒng)，從而保持 Linux 系統(tǒng)的持續(xù)學(xué)習(xí)。

前面講 Linux 操作系統(tǒng)的時(shí)候，說到操作系統(tǒng)，就是整個(gè)系統(tǒng)的管家。應(yīng)用程序要申請資源，都需要通過操作系統(tǒng)的系統(tǒng)調(diào)用接口，向操作系統(tǒng)內(nèi)核申請將 CPU，內(nèi)存，網(wǎng)絡(luò)，硬盤等資源分配給他。

這時(shí)候你會(huì)發(fā)現(xiàn)，虛擬機(jī)也是物理機(jī)上的一個(gè)普通進(jìn)程，當(dāng)虛擬機(jī)內(nèi)部的應(yīng)用程序申請資源的時(shí)候，需要向虛擬機(jī)的操作系統(tǒng)請求。

然而虛擬機(jī)的操作系統(tǒng)自己本身也沒有權(quán)限操作資源，因而又需要像物理機(jī)的操作系統(tǒng)申請資源。

這中間要多一次翻譯的工作，完成這件事情的稱為虛擬化軟件。例如上面說的 VirtualBox 和 Vmware 都是虛擬化軟件。

但是多一層翻譯，就多一層性能損耗，如果虛擬機(jī)里面的每一個(gè)操作都要翻譯，都不能直接操作硬件，性能就會(huì)差很多，簡直沒辦法用，于是就出現(xiàn)了上圖中的硬件輔助虛擬化，也即通過硬件的特殊配置。

例如 VT-x 和 VT-d 等，讓虛擬機(jī)里面的操作系統(tǒng)知道，它不是一個(gè)原生的操作系統(tǒng)了，是一個(gè)虛擬機(jī)的操作系統(tǒng)，不能按照原來的模式操作資源了，而是通過特殊的驅(qū)動(dòng)以硬件輔助的方式抄近道操作物理資源。

剛才說的是桌面虛擬化，也就是在你的筆記本電腦上，在數(shù)據(jù)中心里面，也可以使用 Vmware 進(jìn)行虛擬化，但是價(jià)格比較貴，如果規(guī)模比較大，會(huì)采取開源的虛擬化軟件 qemu-kvm。

對于 qemu-kvm 來說，和上面的原理是一樣的，其中 qemu 的 emu 是 emulator 的意思，也即模擬器，就是翻譯的意思。

KVM 是一個(gè)可以使用 CPU 的硬件輔助虛擬化的方式，而網(wǎng)絡(luò)和存儲(chǔ)的，需要通過特殊的 virtio 的方式，提供高性能的設(shè)備虛擬化功能。

要了解虛擬化的基本原理，推薦書籍《系統(tǒng)虛擬化——原理與實(shí)現(xiàn)》，要了解 KVM，推薦兩本書籍《KVM Virtualization Cookbook》和《Mastering KVM Virtualization》。

另外 KVM 和 qemu 的官方文檔也是必須要看的，還有 Redhat 的官網(wǎng)很多文章非常值得學(xué)習(xí)。

基于 Openvswitch 了解網(wǎng)絡(luò)虛擬化

當(dāng)虛擬機(jī)創(chuàng)建出來了，最主要的訴求就是要能上網(wǎng)，它能訪問到網(wǎng)上的資源，如果虛擬機(jī)里面部署一個(gè)網(wǎng)站，也希望別人能夠訪問到它。

這一方面依賴于 qemu-KVM 的網(wǎng)絡(luò)虛擬化，將網(wǎng)絡(luò)包從虛擬機(jī)里面?zhèn)鞑サ教摂M機(jī)外面，這需要物理機(jī)內(nèi)核轉(zhuǎn)換一把，形成虛擬機(jī)內(nèi)部的網(wǎng)卡和虛擬機(jī)外部的虛擬網(wǎng)卡。

另外一方面就是虛擬機(jī)的網(wǎng)絡(luò)如何能夠連接到物理網(wǎng)絡(luò)里面。物理網(wǎng)絡(luò)常常稱為 underlay network，虛擬網(wǎng)絡(luò)常常稱為 overlay network。

從物理網(wǎng)絡(luò)到虛擬網(wǎng)絡(luò)稱為網(wǎng)絡(luò)虛擬化，能非常好的完成這件事情的是一個(gè)叫 Openvswitch 的虛擬交換機(jī)軟件。

Openvswitch 會(huì)有一個(gè)內(nèi)核驅(qū)動(dòng)，監(jiān)聽物理網(wǎng)卡，可以將物理網(wǎng)卡上收到的包拿進(jìn)來。

虛擬機(jī)創(chuàng)建出來的外部的虛擬網(wǎng)卡也可以添加到 Openvswitch 上，而 Openvswitch 可以設(shè)定各種的網(wǎng)絡(luò)包處理策略，將網(wǎng)絡(luò)包在虛擬機(jī)和物理機(jī)之間進(jìn)行傳遞，從而實(shí)現(xiàn)了網(wǎng)絡(luò)虛擬化。

對于 Openvswitch，我主要是通過官方文檔進(jìn)行研究。

基于 OpenStack 了解云平臺(tái)

當(dāng)有了虛擬機(jī)，并且虛擬機(jī)能夠上網(wǎng)了之后，接下來就是搭建云平臺(tái)的時(shí)候了。

云是基于計(jì)算，網(wǎng)絡(luò)，存儲(chǔ)虛擬化技術(shù)的，云和虛擬化的主要區(qū)別在于，管理員的管理模式不同，用戶的使用模式也不同。

虛擬化平臺(tái)沒有多層次的豐富的租戶管理，沒有靈活 quota 配額的限制，沒有靈活的 QoS 的限制。

多采用虛擬網(wǎng)絡(luò)和物理網(wǎng)絡(luò)打平的橋接模式，虛擬機(jī)直接使用機(jī)房網(wǎng)絡(luò)，沒有虛擬子網(wǎng) VPC 的概念，虛擬網(wǎng)絡(luò)的管理和隔離不能和租戶隔離完全映射起來。

對于存儲(chǔ)也是，公司采購了統(tǒng)一的存儲(chǔ)，也不能和租戶的隔離完全映射起來。

使用虛擬化平臺(tái)的特點(diǎn)是，對于這個(gè)平臺(tái)的操作完全由運(yùn)維部門統(tǒng)一管理，而不能將權(quán)限下放給業(yè)務(wù)部門自己進(jìn)行操作。

因?yàn)橐坏┰试S不同的部門自己操作，大家都用機(jī)房網(wǎng)絡(luò)，在沒有統(tǒng)一管控的情況下，很容易網(wǎng)段沖突了。

如果業(yè)務(wù)部門想申請?zhí)摂M機(jī)，需要通過工單向運(yùn)維部門提統(tǒng)一的申請。當(dāng)然這個(gè)運(yùn)維部門很適應(yīng)這種方式，因?yàn)樵瓉砦锢頇C(jī)就是這樣管理的。

但是公有云，例如 AWS 就沒辦法這樣，租戶千千萬萬，只能他們自己操作。

在私有云里面，隨著服務(wù)化甚至微服務(wù)化的進(jìn)行，服務(wù)數(shù)目越來越多，迭代速度越來越快，業(yè)務(wù)部門需要更加頻繁的創(chuàng)建和消耗虛擬機(jī)，如果還是由運(yùn)維部統(tǒng)一審批，統(tǒng)一操作，會(huì)使得運(yùn)維部門壓力非常大。

而且還會(huì)極大限制了迭代速度，因而要引入租戶管理，運(yùn)維部靈活配置每個(gè)租戶的配額 quota 和 QoS，在這個(gè)配額里面，業(yè)務(wù)部門隨時(shí)可以按照自己的需要，創(chuàng)建和刪除虛擬機(jī)，無需知會(huì)運(yùn)維部門。

每個(gè)部門都可以創(chuàng)建自己的虛擬網(wǎng)絡(luò) VPC，不同租戶的 VPC 之前完全隔離。

所以網(wǎng)段可以沖突，每個(gè)業(yè)務(wù)部門自己規(guī)劃自己的網(wǎng)絡(luò)架構(gòu)，只有少數(shù)的機(jī)器需要被外網(wǎng)或者機(jī)房訪問的時(shí)候，需要少數(shù)的機(jī)房 IP。

這個(gè)也是和租戶映射起來的，可以在分配給業(yè)務(wù)部門機(jī)房網(wǎng) IP 的個(gè)數(shù)范圍內(nèi)，自由的使用。這樣每個(gè)部門自主操作，迭代速度就能夠加快了。

云平臺(tái)中的開源軟件的代表是 OpenStack，建議大家研究 OpenStack 的設(shè)計(jì)機(jī)制，是在云里面通用的，了解了 OpenStack，對于公有云，容器云，都能發(fā)現(xiàn)相似的概念和機(jī)制。

通過我們研究 OpenStack，我們會(huì)發(fā)現(xiàn)很多非常好的云平臺(tái)設(shè)計(jì)模式。

第一：基于 PKI Token 的認(rèn)證模式

如果我們要實(shí)現(xiàn)一個(gè) Restful API，希望有個(gè)統(tǒng)一的認(rèn)證中心的話，Keystone 的三角形工作模式是常用的。

當(dāng)我們要訪問一個(gè)資源，通過用戶名密碼或者 AK/SK 登錄之后，如果認(rèn)證通過，接下來對于資源的訪問，不應(yīng)該總帶著用戶名密碼，而是登錄的時(shí)候形成一個(gè) Token，然后訪問資源的時(shí)候帶著 Token，服務(wù)端通過 Token 去認(rèn)證中心進(jìn)行驗(yàn)證即可。

如果每次驗(yàn)證都去認(rèn)證中心，效率比較差，后來就有了 PKI Token，也即 Token 解密出來是一個(gè)有詳細(xì)租戶信息的字符串，這樣本地就可以進(jìn)行認(rèn)證和鑒權(quán)。

??

第二：基于 Role Based Access Control 的鑒權(quán)模式

對于權(quán)限控制，我們學(xué)會(huì)比較通用的 Role Based Access Control 的權(quán)限控制模式， 形成“用戶-角色-權(quán)限”的授權(quán)模型。

在這種模型中，用戶與角色之間，角色與權(quán)限之間，一般兩者是多對多的關(guān)系，可以非常靈活的控制權(quán)限。

第三：基于 Quota 的配額管理

可以通過設(shè)置計(jì)算，網(wǎng)絡(luò)，存儲(chǔ)的 quota，設(shè)置某個(gè)租戶自己可以自主操作的資源量。

第四：基于預(yù)選和優(yōu)選兩階段的 Scheduler 機(jī)制

當(dāng)需要從一個(gè)資源池里面，選擇一個(gè)節(jié)點(diǎn)，使用這個(gè)節(jié)點(diǎn)上的資源的時(shí)候，一個(gè)通用的 Scheduler 機(jī)制是：

首先進(jìn)行預(yù)選，也即通過 Filter，將不滿足條件的過濾掉。

然后進(jìn)行優(yōu)選，也即對于過濾后，滿足條件的候選人，通過計(jì)算權(quán)重，選擇其中最優(yōu)的。

第五：基于獨(dú)立虛擬子網(wǎng)的網(wǎng)絡(luò)模式

為了每個(gè)租戶可以獨(dú)立操作，因而虛擬網(wǎng)絡(luò)應(yīng)該是獨(dú)立于物理網(wǎng)絡(luò)的，這樣不同的租戶可以進(jìn)行獨(dú)立的網(wǎng)絡(luò)規(guī)劃而互不影響，也不影響物理網(wǎng)絡(luò)，當(dāng)需要跨租戶訪問，或者要訪問物理網(wǎng)絡(luò)的時(shí)候，需要通過路由器。

第六：基于 Copy On Write 的鏡像機(jī)制

有時(shí)候我們在虛擬機(jī)里面做了一些操作以后，希望能夠把這個(gè)時(shí)候的鏡像保存下來，好隨時(shí)恢復(fù)到這個(gè)時(shí)間點(diǎn)，一個(gè)最最簡單的方法就是完全復(fù)制一份，但是由于鏡像太大了，這樣效率很差。

因而采取 Copy On Write 的機(jī)制，當(dāng)打鏡像的時(shí)刻，并沒有新的存儲(chǔ)消耗，而是當(dāng)寫入新的東西的時(shí)候，將原來的數(shù)據(jù)找一個(gè)地方復(fù)制保存下來，這就是 Copy On Write。

對于 Openstack，有一種鏡像 qcow2 就是采取的這樣的機(jī)制。

這樣鏡像就像分層一樣，一層一層的羅列上去。

第七：基于 namespace 和 cgroup 的隔離和 Qos 機(jī)制

在 OpenStack 里面，網(wǎng)絡(luò)節(jié)點(diǎn)的路由器是由 network namespace 來隔離的。

KVM 的占用的 CPU 和內(nèi)存，使用 Cgroup 來隔離的。

網(wǎng)絡(luò)的 QoS 使用 TC 來隔離的。

第八：基于 iptables 的安全機(jī)制

有時(shí)候，我們希望網(wǎng)絡(luò)中的節(jié)點(diǎn)之間不能相互訪問，作為最簡單的防火墻，iptables 起到了很重要的作用，以后實(shí)現(xiàn) ACL 機(jī)制的，都可以考慮使用 iptables。

基于 Mesos 和 Kubernetes 了解容器平臺(tái)

搭建完畢虛擬化層和云平臺(tái)層，接下來就是容器層了。Docker 有幾個(gè)核心技術(shù)，一個(gè)是鏡像，一個(gè)是運(yùn)行時(shí)，運(yùn)行時(shí)又分看起來隔離的 namespace 和用起來隔離的 cgroup。

Docker 的鏡像也是一種 Copy On Write 的鏡像格式，下面的層級是只讀的，所有的寫入都在最上層。

對于運(yùn)行時(shí)，Docker 使用的 namespace 除了 network namespace 外，還有很多，如下表格所示。

Docker 對于 cgroup 的使用是在運(yùn)行 Docker 的時(shí)候，在路徑 /sys/fs/cgroup/cpu/docker/ 下面控制容器運(yùn)行使用的資源。

可見容器并沒有使用更新的技術(shù)，而是一種新型的交付方式，也即應(yīng)用的交付應(yīng)該是一容器鏡像的方式交付，容器一旦啟動(dòng)起來，就不應(yīng)該進(jìn)入容器做各種修改，這就是不可改變基礎(chǔ)設(shè)施。

由于容器的鏡像不包含操作系統(tǒng)內(nèi)核，因而小的多，可以進(jìn)行跨環(huán)境的遷移和彈性伸縮。

有了容器之后，接下來就是容器平臺(tái)的選型，其實(shí) Swarm、Mesos、Kubernetes 各有優(yōu)勢，也可以在不同的階段，選擇使用不同的容器平臺(tái)。

基于 Mesos 的 DCOS 更像是一個(gè)數(shù)據(jù)中心管理平臺(tái)，而非僅僅容器管理平臺(tái)，它可以兼容 Kubernetes 的編排，同時(shí)也能跑各種大數(shù)據(jù)應(yīng)用。

在容器領(lǐng)域，基于 Kubernetes 的容器編排已經(jīng)成為事實(shí)標(biāo)準(zhǔn)。

當(dāng)我們深入分析 Kubernetes 管理容器模式的時(shí)候，我們也能看到熟悉的面孔。

在 Kubernetes 里面，租戶之間靠 namespace 進(jìn)行隔離，這個(gè)不是 Docker 的 namespace，而是 Kubernetes 的概念。

API Server 的鑒權(quán)，也是基于 Role Based Access Control 模式的。Kubernetes 對于 namespace，也有 Quota 配置，使用 ResourceQuota。

當(dāng) Kubernetes 想選擇一個(gè)節(jié)點(diǎn)運(yùn)行 pod 的時(shí)候，選擇的過程也是通過預(yù)選和優(yōu)選兩個(gè)階段：

預(yù)選(Filtering)

• PodFitsResources 滿足資源。
• PodSelectorMatches 符合標(biāo)簽。
• PodFitsHost 符合節(jié)點(diǎn)名稱。

優(yōu)選(Weighting)

• LeastRequestedPriority 資源消耗最小。
• BalancedResourceAllocation 資源使用最均衡。

Kubernetes 規(guī)定了以下的網(wǎng)絡(luò)模型定義：

• 所有的容器都可以在不使用 NAT 的情況下同別的容器通信。
• 所有的節(jié)點(diǎn)都可以在不使用 NAT 的情況下同所有的容器通信。
• 容器的地址和別人看到的地址一樣。

也即容器平臺(tái)應(yīng)該有自己的私有子網(wǎng)，常用的有 Flannel、Calico、Openvswitch 都是可以的。

既可以使用 Overlay 的方式，如圖 Flannel：

也可以使用 BGP 的方式，如圖 Calico：

基于 Hadoop 和 Spark 了解大數(shù)據(jù)平臺(tái)

對于數(shù)據(jù)架構(gòu)的部分，其實(shí)經(jīng)歷了三個(gè)過程，分別是 Hadoop Map-Reduce 1.0，基于 Yarn 的 Map-Reduce 2.0，還有 Spark。

如下圖是 Map-Reduce 1.0 的過程：

Map-Reduce 的過程將一個(gè)大任務(wù)，split 成為多個(gè) Map Task，分散到多臺(tái)機(jī)器并行處理，將處理的結(jié)果保存到本地，第二個(gè)階段，Reduce Task 將中間結(jié)果拷貝過來，將結(jié)果集中處理，取得最終結(jié)果。

在 Map-Reduce 1.0 的時(shí)候，跑任務(wù)的方式只有這一種，為了應(yīng)對復(fù)雜的場景，將任務(wù)的調(diào)度和資源的調(diào)度分成兩層。

其中資源的調(diào)用由 Yarn 進(jìn)行，Yarn 不管是 Map 還是 Reduce，只要向它請求，它就找到空閑的資源分配給它。

每個(gè)任務(wù)啟動(dòng)的時(shí)候，專門啟動(dòng)一個(gè) Application Master，管理任務(wù)的調(diào)度，它是知道 Map 和 Reduce 的。這就是 Map-Reduce 2.0，如下圖：

這里 Yarn 相當(dāng)于外包公司的老板，所有的員工都是 Worker，都是他的資源，外包公司的老板是不清楚接的每一個(gè)項(xiàng)目的。

Application Master 相當(dāng)于接的每個(gè)項(xiàng)目的項(xiàng)目經(jīng)理，他是知道項(xiàng)目的具體情況的，他在執(zhí)行項(xiàng)目的時(shí)候，如果需要員工干活，需要向外包公司老板申請。

Yarn 是個(gè)通用的調(diào)度平臺(tái)，能夠跑 Map-Reduce 2，就能跑 Spark。

Spark 也是創(chuàng)建 Spark 自己的 Application Master，用于調(diào)度任務(wù)。

Spark 之所以比較快，是因?yàn)榍捌谝?guī)劃做的好，不是像 Map-Reduce 一樣，每一次分配任務(wù)和聚合任務(wù)都要寫一次硬盤，而是將任務(wù)分成多個(gè)階段，將所有在一個(gè) Map 都做了的合成一個(gè)階段，這樣中間不用落盤，但是到了需要合并的地方，還是需要落盤的。

基于 Lucene 和 ElasticSearch 了解搜索引擎

當(dāng)大數(shù)據(jù)將收集好的數(shù)據(jù)處理完畢之后，一般會(huì)保存在兩個(gè)地方，一個(gè)是正向索引，可以用 Hbase，Cassandra 等文檔存儲(chǔ)，一個(gè)是反向索引，方便搜索，就會(huì)保存在基于 Lucene 的 ElasticSearch 里面。

基于 Spring Cloud 了解微服務(wù)

最后到了應(yīng)用架構(gòu)，也即微服務(wù)。接下來細(xì)說微服務(wù)架構(gòu)設(shè)計(jì)中不得不知的十大要點(diǎn)。

設(shè)計(jì)要點(diǎn)一：負(fù)載均衡 + API 網(wǎng)關(guān)

在實(shí)施微服務(wù)的過程中，不免要面臨服務(wù)的聚合與拆分。

當(dāng)后端服務(wù)的拆分相對比較頻繁的時(shí)候，作為手機(jī) App 來講，往往需要一個(gè)統(tǒng)一的入口，將不同的請求路由到不同的服務(wù)，無論后面如何拆分與聚合，對于手機(jī)端來講都是透明的。

有了 API 網(wǎng)關(guān)以后，簡單的數(shù)據(jù)聚合可以在網(wǎng)關(guān)層完成，這樣就不用在手機(jī) App 端完成，從而手機(jī) App 耗電量較小，用戶體驗(yàn)較好。

有了統(tǒng)一的 API 網(wǎng)關(guān)，還可以進(jìn)行統(tǒng)一的認(rèn)證和鑒權(quán)，盡管服務(wù)之間的相互調(diào)用比較復(fù)雜，接口也會(huì)比較多。

API 網(wǎng)關(guān)往往只暴露必須的對外接口，并且對接口進(jìn)行統(tǒng)一的認(rèn)證和鑒權(quán)，使得內(nèi)部的服務(wù)相互訪問的時(shí)候，不用再進(jìn)行認(rèn)證和鑒權(quán)，效率會(huì)比較高。

有了統(tǒng)一的 API 網(wǎng)關(guān)，可以在這一層設(shè)定一定的策略，進(jìn)行 A/B 測試，藍(lán)綠發(fā)布，預(yù)發(fā)環(huán)境導(dǎo)流等等。API 網(wǎng)關(guān)往往是無狀態(tài)的，可以橫向擴(kuò)展，從而不會(huì)成為性能瓶頸。

設(shè)計(jì)要點(diǎn)二：無狀態(tài)化與獨(dú)立有狀態(tài)集群

影響應(yīng)用遷移和橫向擴(kuò)展的重要因素就是應(yīng)用的狀態(tài)。無狀態(tài)服務(wù)，是要把這個(gè)狀態(tài)往外移，將 Session 數(shù)據(jù)，文件數(shù)據(jù)，結(jié)構(gòu)化數(shù)據(jù)保存在后端統(tǒng)一的存儲(chǔ)中，從而應(yīng)用僅僅包含商務(wù)邏輯。

狀態(tài)是不可避免的，例如 ZooKeeper，DB，Cache 等，把這些所有有狀態(tài)的東西收斂在一個(gè)非常集中的集群里面。整個(gè)業(yè)務(wù)就分兩部分，一個(gè)是無狀態(tài)的部分，一個(gè)是有狀態(tài)的部分。

無狀態(tài)的部分能實(shí)現(xiàn)兩點(diǎn)：

• 跨機(jī)房隨意地部署，也即遷移性。
• 彈性伸縮，很容易地進(jìn)行擴(kuò)容。

有狀態(tài)的部分，如 ZooKeeper，DB，Cache 有自己的高可用機(jī)制，要利用到它們自己高可用的機(jī)制來實(shí)現(xiàn)這個(gè)狀態(tài)的集群。

雖說無狀態(tài)化，但是當(dāng)前處理的數(shù)據(jù)，還是會(huì)在內(nèi)存里面的，當(dāng)前的進(jìn)程掛掉數(shù)據(jù)，肯定也是有一部分丟失的。

為了實(shí)現(xiàn)這一點(diǎn)，服務(wù)要有重試的機(jī)制，接口要有冪等的機(jī)制，通過服務(wù)發(fā)現(xiàn)機(jī)制，重新調(diào)用一次后端服務(wù)的另一個(gè)實(shí)例就可以了。

設(shè)計(jì)要點(diǎn)三：數(shù)據(jù)庫的橫向擴(kuò)展

數(shù)據(jù)庫是保存狀態(tài)，是最重要的也是最容易出現(xiàn)瓶頸的。有了分布式數(shù)據(jù)庫可以使數(shù)據(jù)庫的性能隨著節(jié)點(diǎn)增加線性地增加。

分布式數(shù)據(jù)庫最最下面是 RDS，是主備的，通過 MySQL 的內(nèi)核開發(fā)能力，我們能夠?qū)崿F(xiàn)主備切換數(shù)據(jù)零丟失。

所以數(shù)據(jù)落在這個(gè) RDS 里面，是非常放心的，哪怕是掛了一個(gè)節(jié)點(diǎn)，切換完了以后，你的數(shù)據(jù)也是不會(huì)丟的。

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

Query Server 是可以根據(jù)監(jiān)控?cái)?shù)據(jù)進(jìn)行橫向擴(kuò)展的，如果出現(xiàn)了故障，可以隨時(shí)進(jìn)行替換的修復(fù)，對于業(yè)務(wù)層是沒有任何感知的。

另外一個(gè)就是雙機(jī)房的部署，DDB 開發(fā)了一個(gè)數(shù)據(jù)運(yùn)河 NDC 的組件，可以使得不同的 DDB 之間在不同的機(jī)房里面進(jìn)行同步。

這時(shí)候不但在一個(gè)數(shù)據(jù)中心里面是分布式的，在多個(gè)數(shù)據(jù)中心里面也會(huì)有一個(gè)類似雙活的一個(gè)備份，高可用性有非常好的保證。

設(shè)計(jì)要點(diǎn)四：緩存

在高并發(fā)場景下緩存是非常重要的。要有層次的緩存，使得數(shù)據(jù)盡量靠近用戶。數(shù)據(jù)越靠近用戶能承載的并發(fā)量也越大，響應(yīng)時(shí)間越短。

在手機(jī)客戶端 App 上就應(yīng)該有一層緩存，不是所有的數(shù)據(jù)都每時(shí)每刻從后端拿，而是只拿重要的，關(guān)鍵的，時(shí)常變化的數(shù)據(jù)。

尤其對于靜態(tài)數(shù)據(jù)，可以過一段時(shí)間去取一次，而且也沒必要到數(shù)據(jù)中心去取，可以通過 CDN，將數(shù)據(jù)緩存在距離客戶端最近的節(jié)點(diǎn)上，進(jìn)行就近下載。

有時(shí)候 CDN 里面沒有，還是要回到數(shù)據(jù)中心去下載，稱為回源，在數(shù)據(jù)中心的最外層，我們稱為接入層，可以設(shè)置一層緩存，將大部分的請求攔截，從而不會(huì)對后臺(tái)的數(shù)據(jù)庫造成壓力。

如果是動(dòng)態(tài)數(shù)據(jù)，還是需要訪問應(yīng)用，通過應(yīng)用中的商務(wù)邏輯生成，或者去數(shù)據(jù)庫讀取，為了減輕數(shù)據(jù)庫的壓力，應(yīng)用可以使用本地的緩存，也可以使用分布式緩存。

如 Memcached 或者 Redis，使得大部分請求讀取緩存即可，不必訪問數(shù)據(jù)庫。

當(dāng)然動(dòng)態(tài)數(shù)據(jù)還可以做一定的靜態(tài)化，也即降級成靜態(tài)數(shù)據(jù)，從而減少后端的壓力。

設(shè)計(jì)要點(diǎn)五：服務(wù)拆分與服務(wù)發(fā)現(xiàn)

當(dāng)系統(tǒng)扛不住，應(yīng)用變化快的時(shí)候，往往要考慮將比較大的服務(wù)拆分為一系列小的服務(wù)。

這樣第一個(gè)好處就是開發(fā)比較獨(dú)立，當(dāng)非常多的人在維護(hù)同一個(gè)代碼倉庫的時(shí)候，往往對代碼的修改就會(huì)相互影響。

常常會(huì)出現(xiàn)我沒改什么測試就不通過了，而且代碼提交的時(shí)候，經(jīng)常會(huì)出現(xiàn)沖突，需要進(jìn)行代碼合并，大大降低了開發(fā)的效率。

另一個(gè)好處就是上線獨(dú)立，物流模塊對接了一家新的快遞公司，需要連同下單一起上線，這是非常不合理的行為。

我沒改還要我重啟，我沒改還讓我發(fā)布，我沒改還要我開會(huì)，都是應(yīng)該拆分的時(shí)機(jī)。

再就是高并發(fā)時(shí)段的擴(kuò)容，往往只有最關(guān)鍵的下單和支付流程是核心，只要將關(guān)鍵的交易鏈路進(jìn)行擴(kuò)容即可，如果這時(shí)候附帶很多其他的服務(wù)，擴(kuò)容既是不經(jīng)濟(jì)的，也是很有風(fēng)險(xiǎn)的。

另外的容災(zāi)和降級，在大促的時(shí)候，可能需要犧牲一部分的邊角功能，但是如果所有的代碼耦合在一起，很難將邊角的部分功能進(jìn)行降級。

當(dāng)然拆分完畢以后，應(yīng)用之間的關(guān)系就更加復(fù)雜了，因而需要服務(wù)發(fā)現(xiàn)的機(jī)制，來管理應(yīng)用相互的關(guān)系，實(shí)現(xiàn)自動(dòng)的修復(fù)，自動(dòng)的關(guān)聯(lián)，自動(dòng)的負(fù)載均衡，自動(dòng)的容錯(cuò)切換。

設(shè)計(jì)要點(diǎn)六：服務(wù)編排與彈性伸縮

當(dāng)服務(wù)拆分了，進(jìn)程就會(huì)非常的多，因而需要服務(wù)編排來管理服務(wù)之間的依賴關(guān)系，以及將服務(wù)的部署代碼化，也就是我們常說的基礎(chǔ)設(shè)施即代碼。

這樣對于服務(wù)的發(fā)布，更新，回滾，擴(kuò)容，縮容，都可以通過修改編排文件來實(shí)現(xiàn)，從而增加了可追溯性，易管理性，和自動(dòng)化的能力。

既然編排文件也可以用代碼倉庫進(jìn)行管理，就可以實(shí)現(xiàn)一百個(gè)服務(wù)中，更新其中五個(gè)服務(wù)，只要修改編排文件中的五個(gè)服務(wù)的配置就可以。

當(dāng)編排文件提交的時(shí)候，代碼倉庫自動(dòng)觸發(fā)自動(dòng)部署升級腳本，從而更新線上的環(huán)境。

當(dāng)發(fā)現(xiàn)新的環(huán)境有問題時(shí)，當(dāng)然希望將這五個(gè)服務(wù)原子性地回滾，如果沒有編排文件，需要人工記錄這次升級了哪五個(gè)服務(wù)。

有了編排文件，只要在代碼倉庫里面 Revert，就回滾到上一個(gè)版本了。所有的操作在代碼倉庫里都是可以看到的。

設(shè)計(jì)要點(diǎn)七：統(tǒng)一配置中心

服務(wù)拆分以后，服務(wù)的數(shù)量非常多，如果所有的配置都以配置文件的方式放在應(yīng)用本地的話，非常難以管理。

可以想象當(dāng)有幾百上千個(gè)進(jìn)程中有一個(gè)配置出現(xiàn)了問題，是很難將它找出來的，因而需要有統(tǒng)一的配置中心，來管理所有的配置，進(jìn)行統(tǒng)一的配置下發(fā)。

在微服務(wù)中，配置往往分為以下幾類：

一類是幾乎不變的配置，這種配置可以直接打在容器鏡像里面。

第二類是啟動(dòng)時(shí)就會(huì)確定的配置，這種配置往往通過環(huán)境變量，在容器啟動(dòng)的時(shí)候傳進(jìn)去。

第三類就是統(tǒng)一的配置，需要通過配置中心進(jìn)行下發(fā)。例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置文件中統(tǒng)一配置。

設(shè)計(jì)要點(diǎn)八：統(tǒng)一日志中心

同樣是進(jìn)程數(shù)目非常多的時(shí)候，很難對成千上百個(gè)容器，一個(gè)一個(gè)登錄進(jìn)去查看日志，所以需要統(tǒng)一的日志中心來收集日志。

為了使收集到的日志容易分析，對于日志的規(guī)范，需要有一定的要求，當(dāng)所有的服務(wù)都遵守統(tǒng)一的日志規(guī)范的時(shí)候，在日志中心就可以對一個(gè)交易流程進(jìn)行統(tǒng)一的追溯。

例如在最后的日志搜索引擎中，搜索交易號(hào)，就能夠看到在哪個(gè)過程出現(xiàn)了錯(cuò)誤或者異常。

設(shè)計(jì)要點(diǎn)九：熔斷，限流，降級

服務(wù)要有熔斷，限流，降級的能力，當(dāng)一個(gè)服務(wù)調(diào)用另一個(gè)服務(wù)，出現(xiàn)超時(shí)的時(shí)候，應(yīng)及時(shí)返回，而非阻塞在那個(gè)地方，從而影響其他用戶的交易，可以返回默認(rèn)的托底數(shù)據(jù)。

當(dāng)一個(gè)服務(wù)發(fā)現(xiàn)被調(diào)用的服務(wù)，因?yàn)檫^于繁忙，線程池滿，連接池滿，或者總是出錯(cuò)，則應(yīng)該及時(shí)熔斷，防止因?yàn)橄乱粋€(gè)服務(wù)的錯(cuò)誤或繁忙，導(dǎo)致本服務(wù)的不正常，從而逐漸往前傳導(dǎo)，導(dǎo)致整個(gè)應(yīng)用的雪崩。

當(dāng)發(fā)現(xiàn)整個(gè)系統(tǒng)的確負(fù)載過高的時(shí)候，可以選擇降級某些功能或某些調(diào)用，保證最重要的交易流程的通過，以及最重要的資源全部用于保證最核心的流程。

還有一種手段就是限流，當(dāng)既設(shè)置了熔斷策略，又設(shè)置了降級策略，通過全鏈路的壓力測試，應(yīng)該能夠知道整個(gè)系統(tǒng)的支撐能力。

因而就需要制定限流策略，保證系統(tǒng)在測試過的支撐能力范圍內(nèi)進(jìn)行服務(wù)，超出支撐能力范圍的，可拒絕服務(wù)。

當(dāng)你下單的時(shí)候，系統(tǒng)彈出對話框說 “系統(tǒng)忙，請重試”，并不代表系統(tǒng)掛了，而是說明系統(tǒng)是正常工作的，只不過限流策略起到了作用。

設(shè)計(jì)要點(diǎn)十：全方位的監(jiān)控

當(dāng)系統(tǒng)非常復(fù)雜的時(shí)候，要有統(tǒng)一的監(jiān)控，主要有兩個(gè)方面，一個(gè)是是否健康，一個(gè)是性能瓶頸在哪里。

當(dāng)系統(tǒng)出現(xiàn)異常的時(shí)候，監(jiān)控系統(tǒng)可以配合告警系統(tǒng)，及時(shí)地發(fā)現(xiàn)，通知，干預(yù)，從而保障系統(tǒng)的順利運(yùn)行。

當(dāng)壓力測試的時(shí)候，往往會(huì)遭遇瓶頸，也需要有全方位的監(jiān)控來找出瓶頸點(diǎn)，同時(shí)能夠保留現(xiàn)場，從而可以追溯和分析，進(jìn)行全方位的優(yōu)化。

文章題目：資深大牛吐血總結(jié)：如何成為一名合格的云架構(gòu)師?
本文網(wǎng)址：http://www.fisionsoft.com.cn/article/dpjpgps.html