一、架構的三個維度和六個層面

1.1、三大架構

在互聯網時代，要做好一個合格的云架構師，需要熟悉三大架構。

第一個是IT架構，其實就是計算，網絡，存儲。這是云架構師的基本功，也是最傳統的云架構師應該首先掌握的部分，良好設計的IT架構，可以降低CAPEX和OPEX，減輕運維的負擔。數據中心，虛擬化，云平臺，容器平臺都屬于IT架構的范疇。

第二個是應用架構，隨著應用從傳統應用向互聯網應用轉型，僅僅搞定資源層面的彈性還不夠，常常會出現創建了大批機器，仍然撐不住高并發流量。因而基于微服務的互聯網架構，越來越成為云架構師所必需的技能。良好設計的應用架構，可以實現快速迭代和高并發。數據庫，緩存，消息隊列等PaaS，以及基于SpringCloud和Dubbo的微服務框架，都屬于應用架構的范疇。

第三個是數據架構，數據成為人工智能時代的核心資產，在做互聯網化轉型的同時，往往進行的也是數字化轉型，并有戰略的進行數據收集，這就需要云架構師同時又大數據思維。有意識的建設統一的數據平臺，并給予數據進行數字化運營。搜索引擎，Hadoop，Spark，人工智能都屬于數據架構的范疇。

1.2、六個層面

上面的三個維度是從人的角度出發的，如果從系統的角度出發，架構分六個層次。

第一個層次是基礎設施層，在數據中心里面，會有大量的機架，大量的服務器，并通過交換機和路由器將服務器連接起來，有的應用例如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系列

三、讀文檔，讀所有的官方文檔，記不住，看不懂也要讀下來

四、了解核心的原理和算法，推薦XXXthe 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協議棧標準。

對于Linux的基礎知識方面，我寫了幾篇文章如下。

圖說Linux進程

圖說Linux進程之二

圖說Linux進程之三

圖解Linux文件系統

圖解Linux系統調用

Linux的虛擬文件系統VFS

圖解Linux的Socket

五、了解數據中心和網絡基礎知識

云平臺當然會部署在數據中心里面，由于數據中心里面的硬件設備也是非常專業的，因而很多地方機房部門和云計算部門是兩個部門，但是作為一個云架構師，需要和機房部門進行溝通，因而需要一定的數據中心知識，在數據中心里面，最難搞定的是網絡，因而這里面網絡知識是重中之重。

下面這個圖是一個典型的數據中心圖。

最外層是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的官網很多文章非常值得學習。

對于虛擬化方面，我寫了以下的文章。

我是虛擬機內核我困惑？！

Qemu，KVM，Virsh傻傻的分不清

裸用KVM創建虛擬機，體驗virtualbox為你做的10件事情

KVM虛擬機鏡像那點兒事，qcow2六大功能，內部快照和外部快照有啥區別？

KVM半虛擬化設備virtio及性能調優最佳實踐

我的虛擬機掛了！怎么把鏡像里面的數據找回來？

不僅Docker有鏡像，KVM也有多種方式操作鏡像

七、基于Openvswitch了解網絡虛擬化

當虛擬機創建出來了，最主要的訴求就是要能上網，他能訪問到網上的資源，如果虛擬機里面部署一個網站，也希望別人能夠訪問到他。

這一方面依賴于qemu-KVM的網絡虛擬化，將網絡包從虛擬機里面傳播到虛擬機外面，這需要物理機內核轉換一把，形成虛擬機內部的網卡和虛擬機外部的虛擬網卡。

另外一方面就是虛擬機的網絡如何能夠連接到物理網絡里面。物理網絡常常稱為underlay network，虛擬網絡常常稱為overlay network，從物理網絡到虛擬網絡稱為網絡虛擬化，能非常好的完成這件事情的是一個叫Openvswitch的虛擬交換機軟件。

Openvswitch會有一個內核驅動，監聽物理網卡，可以將物理網卡上收到的包拿進來。虛擬機創建出來的外部的虛擬網卡也可以添加到Openvswitch上，而Openvswitch可以設定各種的網絡包處理策略，將網絡包在虛擬機和物理機之間進行傳遞，從而實現了網絡虛擬化。

對于Openvswitch，我主要是通過官方文檔進行研究，寫下了這個系列。

Openvswitch的入門篇

通俗說Openvswitch

Openvswitch的操作篇

玩轉Openvwitch第一站：Manager和SSL

玩轉Openvwitch第二站：Bridge和Controller

玩轉Openvwitch第四站：Bridge和Mirror

玩轉Openvwitch第五站：Port和VLAN

玩轉Openvwitch第六站：Port和Bond

玩轉Openvwitch第七站：Port和QoS

玩轉Openvswitch第八站：Interface和Tunnel (下)

玩轉Openvswitch第八站：Interface和Tunnel (上)

玩轉Openvswitch第十站：Flow Table

玩轉Openvswitch之綜合篇

Openvswitch的代碼分析篇

Openvswitch總體架構與代碼結構

從Openvswitch代碼看網絡包的旅程

八、基于OpenStack了解云平臺

當有了虛擬機，并且虛擬機能夠上網了之后，接下來就是搭建云平臺的時候了。

云是基于計算，網絡，存儲虛擬化技術的，云和虛擬化的主要區別在于，管理員的管理模式不同，用戶的使用模式也不同。

虛擬化平臺沒有多層次的豐富的租戶管理，沒有靈活quota配額的限制，沒有靈活的QoS的限制，多采用虛擬網絡和物理網絡打平的橋接模式，虛擬機直接使用機房網絡，沒有虛擬子網VPC的概念，虛擬網絡的管理和隔離不能和租戶隔離完全映射起來。對于存儲也是，公司采購了統一的存儲，也不能和租戶的隔離完全映射起來。

使用虛擬化平臺的特點是，對于這個平臺的操作完全由運維部門統一管理，而不能將權限下放給業務部門自己進行操作。因為一旦允許不同的部門自己操作，大家都用機房網絡，在沒有統一管控的情況下，很容易網段沖突了。如果業務部門向申請虛擬機，需要通過工單向運維部門統一的申請。當然這個運維部門很適應這種方式，因為原來物理機就是這樣管理的。

但是公有云，例如aws就沒辦法這樣，租戶千千萬萬，只能他們自己操作。在私有云里面，隨著服務化甚至微服務化的進行，服務數目越來越多，迭代速度越來越快，業務部門需要更加頻繁的創建和消耗虛擬機，如果還是由運維部統一審批，統一操作，會使得運維部門壓力非常大，而且極大限制了迭代速度，因而要引入 租戶管理，運維部靈活配置每個租戶的配額quota和QoS，在這個配額里面，業務部門隨時可以按照自己的需要，創建和刪除虛擬機，無需知會運維部門。每個部門都可以創建自己的虛擬網絡VPC，不同租戶的VPC之前完全隔離，所以網段可以沖突，每個業務部門自己規劃自己的網絡架構，只有少數的機器需要被外網或者機房訪問的時候，需要少數的機房IP，這個也是和租戶映射起來的，可以分配給業務部門機房網IP的個數范圍內，自由的使用。這樣每個部門自主操作，迭代速度就能夠加快了。

云平臺中的開源軟件的代表是OpenStack，建議大家研究OpenStack的設計機制，是在云里面通用的，了解了OpenStack，對于公有云，容器云，都能發現相似的概念和機制。

沿著OpenStack創建虛擬機的過程，我總結了100個知識點，寫下了下面的文章。

OpenStack虛擬機創建的50個步驟和100個知識點

用OpenStack界面輕松創建虛擬機的你，看得懂虛擬機啟動的這24個參數么？

覺得OpenStack的網絡復雜？其實你家里就有同樣一個網絡

當發現你的OpenStack虛擬機網絡有問題，不妨先試一下這16個步驟

手動用KVM模擬OpenStack Cinder掛載iSCSI卷

不僅Docker會使用Control Group，KVM也會使用Cgroup來控制資源分配

通過我們研究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各有優勢，也可以在不同的階段，選擇使用不同的容器平臺。

Docker, Kubernetes, DCOS 不談信仰談技術

容器平臺選型的十大模式：Docker、DC/OS、K8S誰與當先？

基于Mesos的DCOS更像是一個數據中心管理平臺，而非僅僅容器管理平臺，他可以兼容Kubernetes的編排，同時也能跑各種大數據應用。

DC/OS的基本思想——為什么說他是數據中心操作系統

號稱了解mesos雙層調度的你，先來回答下面這五個問題！

DC/OS的容器功能

DC/OS的網絡功能

DC/OS的存儲功能

DC/OS的服務發現與負載均衡功能

在容器領域，基于Kubernetes的容器編排已經成為事實標準。

基于萬節點Kubernetes支撐大規模云應用實踐

支撐大規模公有云的Kubernetes改進與優化 (1)

支撐大規模公有云的Kubernetes改進與優化 (2)

支撐大規模公有云的Kubernetes改進與優化 (3)

為支撐高并發應用的 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都做了的合成一個階段，這樣中間不用落盤，但是到了需要合并的地方，還是需要落盤的。

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

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

通俗說Spark

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

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

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

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

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

十一、基于Lucene和ElasticSearch了解搜索引擎

當大數據將收集好的數據處理完畢之后，一般會保存在兩個地方，一個是正向索引，可以用Hbase，Cassandra等文檔存儲，一個是反向索引，方便搜索，就會保存在基于Lucene的ElasticSearch里面。

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

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

不是技術也能看懂搜索引擎

搜索引擎的設計(1)：詞典的設計

搜索引擎的設計(2)：倒排表的設計上

搜索引擎的設計(3)：倒排表的設計下

十二、基于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，就回滾到上一個版本了。所有的操作在代碼倉庫里都是可以看到的。

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

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

可以想象當有幾百上千個進程中有一個配置出現了問題，是很難將它找出來的，因而需要有統一的配置中心，來管理所有的配置，進行統一的配置下發。

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

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

第二類是啟動時就會確定的配置，這種配置往往通過環境變量，在容器啟動的時候傳進去。

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

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

同樣是進程數目非常多的時候，很難對成千上百個容器，一個一個登錄進去查看日志，所以需要統一的日志中心來收集日志。

為了使收集到的日志容易分析，對于日志的規范，需要有一定的要求，當所有的服務都遵守統一的日志規范的時候，在日志中心就可以對一個交易流程進行統一的追溯。

例如在最后的日志搜索引擎中，搜索交易號，就能夠看到在哪個過程出現了錯誤或者異常。

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

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

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

當發現整個系統的確負載過高的時候，可以選擇降級某些功能或某些調用，保證最重要的交易流程的通過，以及最重要的資源全部用于保證最核心的流程。

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

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

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

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

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

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

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