在網際網路時代，要做好一個合格的雲架構師，需要熟悉三大架構。
第一個是IT架構，其實就是計算，網絡，存儲。這是雲架構師的基本功，也是最傳統的雲架構師應該首先掌握的部分，良好設計的IT架構，可以降低CAPEX和OPEX，減輕運維的負擔。資料中心，虛拟化，雲平台，容器平台都屬于IT架構的範疇。
第二個是應用架構，随着應用從傳統應用向網際網路應用轉型，僅僅搞定資源層面的彈性還不夠，常常會出現建立了大批機器，仍然撐不住高并發流量。因而基于微服務的網際網路架構，越來越成為雲架構師所必需的技能。良好設計的應用架構，可以實作快速疊代和高并發。資料庫，緩存，消息隊列等PaaS，以及基于SpringCloud和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的基礎知識，基本原理了。
說到作業系統，一般有三個次元，一個是桌面作業系統，一個是移動作業系統，一個是伺服器作業系統。
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網絡内幕》
這裡還自我推薦一下本人寫的極客時間專欄《趣談網絡協定》。
極客時間《趣談網絡協定》：小說一樣的網絡協定入門課
其中有個綜合場景，串起來所有的網絡協定。
用雙十一的故事串起碎片的網絡協定（下）
用雙十一的故事串起碎片的網絡協定（中）
用雙十一的故事串起碎片的網絡協定（上）
當實體機搭建完畢之後，接下來就是基于實體機上面搭建虛拟機了。
沒有了解虛拟機的同學，可以在自己的筆記本電腦上用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也有多種方式操作鏡像
當虛拟機建立出來了，最主要的訴求就是要能上網，他能通路到網上的資源，如果虛拟機裡面部署一個網站，也希望别人能夠通路到他。
這一方面依賴于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代碼看網絡包的旅程
當有了虛拟機，并且虛拟機能夠上網了之後，接下來就是搭建雲平台的時候了。
雲是基于計算，網絡，存儲虛拟化技術的，雲和虛拟化的主要差別在于，管理者的管理模式不同，使用者的使用模式也不同。
虛拟化平台沒有多層次的豐富的租戶管理，沒有靈活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，我們會發現很多非常好的雲平台設計模式。
如果我們要實作一個Restful API，希望有個統一的認證中心的話，Keystone的三角形工作模式是常用的。
當我們要通路一個資源，通過使用者名密碼或者AK/SK登入之後，如果認證通過，接下來對于資源的通路，不應該總帶着使用者名密碼，而是登入的時候形成一個Token，然後通路資源的時候帶着Token，服務端通過Token去認證中心進行驗證即可。
如果每次驗證都去認證中心，效率比較差，後來就有了PKI Token，也即Token解密出來是一個有詳細租戶資訊的字元串，這樣本地就可以進行認證和鑒權。
對于權限控制，我們學會比較通用的Role Based Access Control的權限控制模式， 形成“使用者-角色-權限”的授權模型。在這種模型中，使用者與角色之間，角色與權限之間，一般者是多對多的關系，可以非常靈活的控制權限。
可以通過設定計算，網絡，存儲的quota，設定某個租戶自己可以自主操作的資源量。
當需要從一個資源池裡面，選擇一個節點，使用這個節點上的資源的時候，一個通用的Scheduler機制是：
首先進行預選，也即通過Filter，将不滿足條件的過濾掉。
然後進行優選，也即對于過濾後，滿足條件的候選人，通過計算權重，選擇其中最優的。
為了每個租戶可以獨立操作，因而虛拟網絡應該是獨立于實體網絡的，這樣不同的租戶可以進行獨立的網絡規劃而互不影響，也不影響實體網絡，當需要跨租戶通路，或者要通路實體網絡的時候，需要通過路由器。
有時候我們在虛拟機裡面做了一些操作以後，希望能夠把這個時候的鏡像儲存下來，好随時恢複到這個時間點，一個最最簡單的方法就是完全複制一份，但是由于鏡像太大了，這樣效率很差。因而采取Copy on write的機制，當打鏡像的時刻，并沒有新的存儲消耗，而是當寫入新的東西的時候，将原來的資料找一個地方複制儲存下來，這就是Copy on Write。
對于Openstack，有一種鏡像qcow2就是采取的這樣的機制。
這樣鏡像就像分層一樣，一層一層的羅上去。
在OpenStack裡面，網絡節點的路由器是由network namespace來隔離的。
KVM的占用的CPU和記憶體，使用Cgroup來隔離的。
網絡的QoS使用TC來隔離的。
有時候，我們希望網絡中的節點之間不能互相通路，作為最簡單的防火牆，iptables起到了很重要的作用，以後實作ACL機制的，都可以考慮使用iptables。
搭建完畢虛拟化層和雲平台層，接下來就是容器層了。
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 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的爬取方法
當大資料将收集好的資料處理完畢之後，一般會儲存在兩個地方，一個是正向索引，可以用Hbase，Cassandra等文檔存儲，一個是反向索引，友善搜尋，就會儲存在基于Lucene的ElasticSearch裡面。
對于Lucene，在職業生涯的早期，寫過一個《Lucene 原理與代碼分析完整版》有500多頁。
對于搜尋引擎的通用原理，寫了下面的文章。
不是技術也能看懂搜尋引擎
搜尋引擎的設計(1)：詞典的設計
搜尋引擎的設計(2)：倒排表的設計上
搜尋引擎的設計(3)：倒排表的設計下
最後到了應用架構，也即微服務。
接下來細說微服務架構設計中不得不知的十大要點。
在實施微服務的過程中，不免要面臨服務的聚合與拆分。
當後端服務的拆分相對比較頻繁的時候，作為手機 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
最後。
歡迎關注微信公衆号
小弟參加GIAC年度新人評選，馬了這麼多字，能幫忙投個票嗎？請點選連接配接進行投票。
劉超 網易雲技術架構部總監
長期緻力于雲計算開源技術的分享，布道和落地，将網易内部最佳實踐服務客戶與行業。
技術分享：出版《Lucene應用開發解密》，極客時間專欄《趣談網絡協定》，個人公衆号《劉超的通俗雲計算》文章Kubernetes及微服務系列18篇，Mesos系列30篇，KVM系列25篇，Openvswitch系列31篇，OpenStack系列24篇，Hadoop系列10篇。公衆号文章《終于有人把雲計算，大資料，人工智能講明白了》累積10萬+
大會布道：InfoQ架構師峰會明星講師，作為邀請講師在QCon，LC3，SACC，GIAC，CEUC，SoftCon，NJSD等超過10場大型技術峰會分享網易的最佳實踐
行業落地：将網易的容器和微服務産品在銀行，證券，物流，視訊監控，智能制造等多個行業落地。