雲架構師進階攻略
https://mp.weixin.qq.com/s/tHRl5OQHY2mNXqKwACCVWw?utm_source=tuicool&utm_medium=referrallinux
1、架構的三個維度和六個層面程序員
1.一、三大架構web
在互聯網時代，要作好一個合格的雲架構師，須要熟悉三大架構。面試
第一個是IT架構，其實就是計算，網絡，存儲。這是雲架構師的基本功，也是最傳統的雲架構師應該首先掌握的部分，良好設計的IT架構，能夠下降CAPEX和OPEX，減輕運維的負擔。數據中心，虛擬化，雲平臺，容器平臺都屬於IT架構的範疇。算法
第二個是應用架構，隨着應用從傳統應用向互聯網應用轉型，僅僅搞定資源層面的彈性還不夠，經常會出現建立了大批機器，仍然撐不住高併發流量。於是基於微服務的互聯網架構，愈來愈成爲雲架構師所必需的技能。良好設計的應用架構，能夠實現快速迭代和高併發。數據庫，緩存，消息隊列等PaaS，以及基於SpringCloud和Dubbo的微服務框架，都屬於應用架構的範疇。sql
第三個是數據架構，數據成爲人工智能時代的核心資產，在作互聯網化轉型的同時，每每進行的也是數字化轉型，並有戰略的進行數據收集，這就須要雲架構師同時又大數據思惟。有意識的建設統一的數據平臺，並給予數據進行數字化運營。搜索引擎，Hadoop，Spark，人工智能都屬於數據架構的範疇。docker
1.二、六個層面數據庫
上面的三個維度是從人的角度出發的，若是從系統的角度出發，架構分六個層次。編程
第一個層次是基礎設施層，在數據中內心面，會有大量的機架，大量的服務器，並經過交換機和路由器將服務器鏈接起來，有的應用例如Oracle是須要部署在物理機上的。爲了管理的方便，在物理機之上會部署虛擬化，例如Vmware，能夠將對於物理機複雜的運維簡化爲虛擬機靈活的運維。虛擬化採起的運維方式可能是由運維部門統一管理，當一個公司裏面部門很是多的時候，每每要引入良好的租戶管理，基於Quota和QoS的資源控制，基於VPC的網絡規劃等，實現從運維集中管理到租戶自助使用模式的轉換，託生於公有云的OpenStack在這方面作的是比較好的。隨着應用架構愈來愈重要，對於標準化交付和彈性伸縮的需求愈來愈大，容器最爲軟件交付的集裝箱，能夠實現基於鏡像的跨環境遷移，Kubernetes是容器管理平臺的事實標準。windows
第二個層次是數據層，也即一個應用的中軍大營，若是是傳統應用，可能會使用Oracle，並使用大量的存儲過程，有大量的表聯合查詢，成本也每每比較高。可是對於高併發的互聯網應用，須要進行微服務的拆分，數據庫實例會比較多，使用開源的Mysql是常見的選擇，大量的存儲過程和聯合查詢每每會使得微服務沒法拆分，性能會比較差，於是須要放到應用層去作複雜的業務邏輯，數據庫表和索引的設計很是重要。當併發量比較大的時候，須要實現橫向擴展，就須要基於分佈式數據庫，也是須要基於單庫良好的表和索引設計。對於結構比較靈活的數據，能夠使用MongoDB數據庫，橫向擴展能力比較好。對於大量的聯合查詢需求，能夠使用ElasticSearch之類的搜索引擎來作，速度快，更加靈活。
第三個層次是中間件層，由於數據庫層每每須要保證數據的不丟失以及一些事務，於是併發性能不可能很是大，因此咱們常常說，數據庫是中軍大營，不能全部的請求都到這裏來，於是須要一層緩存層，用來攔截大部分的熱點請求。Memcached適合作簡單的key-value存儲，內存使用率比較高，並且因爲是多核處理，對於比較大的數據，性能較好。可是缺點也比較明顯，Memcached嚴格來說沒有集羣機制，橫向擴展徹底靠客戶端來實現。另外Memcached沒法持久化，一旦掛了數據就都丟失了，若是想實現高可用，也是須要客戶端進行雙寫才能夠。Redis的數據結構比較豐富，提供持久化的功能，提供成熟的主備同步，故障切換的功能，從而保證了高可用性。另外微服務拆分之後，有時候處理一個訂單要通過很是多的服務，處理過程會比較慢，這個時候須要使用消息隊列，讓服務之間的調用變成對於消息的訂閱，實現異步處理。RabbitMQ和Kafka是經常使用的消息隊列，當事件比較重要的時候，會結合數據庫實現可靠消息隊列。
第四個層次是基礎服務層，有的時候成爲中颱層，將通用的能力抽象爲服務對外提供原子化接口。這樣上層能夠根據業務需求，經過靈活的組合這些原子化接口，靈活的應對業務需求的變化，實現能力的複用，以及數據的統一管理，例如用戶數據，支付數據，不會分散到各個應用中。另外基礎服務層稱爲應用和數據庫和緩存的一個分界線，不該該全部的應用都直接連數據庫，一旦出現分庫分表，數據庫遷移，緩存選型改變等，影響面會很是大，幾乎沒法執行。若是將這些底層的變動攔截在基礎服務層，上層僅僅使用基礎服務層的接口，這樣底層的變化會對上層透明，能夠逐步演進。
第五個層次是業務服務層，或者組合服務層，大部分的業務邏輯都是在這個層面實現，業務邏輯比較面向用戶，於是會常常改變，因此須要組合基礎服務的接口進行實現。在這一層，會常常進行服務的拆分，實現開發獨立，上線獨立，擴容獨立，容災降級獨立。微服務的拆分不該該是一個運動，而應該是一個遇到耦合痛點的時候，不斷解決，不斷演進的一個過程。微服務拆分以後，有時候須要經過分佈式事務，保證多個操做的原子性，也是在組合服務層來實現的。
第六個層次是用戶接口層，也即對終端客戶呈現出來的界面和APP，可是卻不只僅是界面這麼簡單。這一層有時候稱爲接入層。在這一層，動態資源和靜態資源應該分離，靜態資源應該在接入層作緩存，使用CDN進行緩存。也應該UI和API分離，界面應該經過組合API進行數據拼裝。API會經過統一的API網關進行統一的管理和治理，一方面後端組合服務層的拆分對APP是透明的，一方面當併發量比較大的時候，能夠在這一層實現限流和降級。
爲了支撐這六個層次，在上圖的左側是一些公共能力。
-
持續集成和持續發佈是保證微服務拆分過程當中的快速迭代，以及變動後保證功能不變的，不引入新的Bug。
-
服務發現和服務治理是微服務之間互相的調用，以及調用過程當中出現異常狀況下的熔斷，限流，降級策略。
-
大數據和人工智能是經過收集各個層面的數據，例如用戶訪問數據，用戶下單數據，客服詢問數據等，結合統一的中臺，對數據進行分析，實現智能推薦。
-
監控與APM是基礎設施的監控和應用的監控，發現資源層面的問題以及應用調用的問題。
做爲一個雲架構師仍是很複雜的，千里之行，始於足下，讓咱們慢慢來。
2、瞭解雲計算的歷史演進與基本原理
在一頭扎進雲計算的汪洋大海以前，咱們應該先有一個全貌的瞭解，有人說了解一個知識的起點，就是了解他的歷史，也就是知道他是如何一步一步到今天的，這樣如此龐大的一個體系，實際上是逐步加進來的，這樣的知識體系對咱們來講，就不是一個冷冰冰的知識網，而是一個有血有肉的人，咱們只要沿着演進的線索，一步一步摸清楚他的脾氣就能夠了。
如何把雲計算講的通俗易懂，我本人思考了半天，最終寫下了下面這篇文章。
在這裏，我把核心的要點在這裏寫一下：
第一：雲計算的本質是實現從資源到架構的全面彈性。所謂的彈性就是時間靈活性和空間靈活性，也即想何時要就何時要，想要多少就要多少。
資源層面的彈性也即實現計算、網絡、存儲資源的彈性。這個過程經歷了從物理機，到虛擬化，到雲計算的一個演進過程。
架構層面的彈性也即實現通用應用和自有應用的彈性擴展。對於通用的應用，多集成爲PaaS平臺。對於本身的應用，經過基於腳本的Puppet, Chef, Ansible到基於容器鏡像的容器平臺CaaS。
第二：大數據包含數據的收集，數據的傳輸，數據的存儲，數據的處理和分析，數據的檢索和挖掘等幾個過程。
當數據量很小時，不多的幾臺機器就能解決。慢慢的，當數據量愈來愈大，最牛的服務器都解決不了問題時，怎麼辦呢？這時就要聚合多臺機器的力量，你們齊心合力一塊兒把這個事搞定，衆人拾柴火焰高。
第三：人工智能經歷了基於專家系統的計劃經濟，基於統計的宏觀調控，基於神經網絡的微觀經濟學三個階段。
3、開源軟件是進階的利器
架構師除了要掌握大的架構和理論以外，指導落地也是必備的技能，所謂既要懂設計模式，也要懂代碼。那從哪裏去學習這些良好的，有借鑑意義的，能夠落地的架構實踐呢？
這個世界上仍是有不少有情懷的大牛的，尤爲是程序員裏面，他們喜歡作一件什麼事情呢？開源。不少軟件都是有閉源就有開源，源就是源代碼。當某個軟件作的好，全部人都愛用，這個軟件的代碼呢，我封閉起來只有我公司知道，其餘人不知道，若是其餘人想用這個軟件，就要付我錢，這就叫閉源。可是世界上總有一些大牛看不慣錢都讓一家賺了去。大牛們以爲，這個技術你會我也會，你能開發出來，我也能，我開發出來就是不收錢，把代碼拿出來分享給你們，全世界誰用均可以，全部的人均可以享受到好處，這個叫作開源。
很是建議你們瞭解，深刻研究，甚至參與貢獻開源軟件，由於收益匪淺。
第一：經過開源軟件，咱們能夠了解大牛們的架構原則，設計模式。
其實我們平時的工做中，是很難碰到大牛的，他多是你渴望而不可及的公司的員工，甚至在國外，你要想進這種公司，不刷個幾年題目，面試個N輪是進不去的。即使進去了，他多是公司的高層，天天很忙，不怎麼見獲得他，就算當面討教，時間也不會很長，很難深刻交流。也有的大牛會選擇自主創業，或者是自由職業者，神龍見首不見尾，到了大公司都見不到。
可是感謝互聯網和開源社區，將大牛們拉到了咱們身邊，你能夠訂閱郵件組，能夠加入討論羣，能夠看到大牛們的設計，看到不少人的評論，提問，還有大牛的回答，能夠看到大牛的設計也不是一蹴而就完美的，看到逐漸演進的過程，等等。這些都是可以幫助咱們快速提高水平的地方，有的時候，拿到一篇設計，都要查資料看半天，一開始均可能好多的術語都看不懂，不要緊肯下他，當你看blueprints愈來愈順暢的時候，你就進步了。
第二：經過開源軟件，咱們能夠學習到代碼級的落地實踐。
有時候咱們能看到不少大牛寫的書和文章，也能看到不少理論的書籍，可是存在一個問題是，理論都懂，可是仍是作很差架構。這是由於沒有看到代碼，全部的理論都是空中樓閣，當你到了具體的代碼設計層面，那些學會的設計模式，沒法轉化爲你本身的實踐。
好在開源軟件的代碼都是公開的，凝結了大牛的心血，也可以看到大牛在具體落地時候的取捨，一切那麼真實，看得見，摸得着。經過代碼進行學習，配合理論知識，更容易得到第一手的經驗，而且在本身作設計和寫代碼的時候，立刻可以映射到能夠參考的場景，讓咱們在作本身的系統的時候，少走彎路。
第三：經過開源軟件，咱們能夠加入社區，和其餘技術人員在同一背景下共同進步
大牛咱們每每不容易接觸到，正面討論技術問題的時間更是難能難得，可是沒有關係，開源軟件構建了一個社區，你們能夠在一塊兒討論，你是怎麼理解的，別人是怎麼理解的，越討論越交流，越明晰，有時候和比你經驗稍微豐富一點的技術人員交流，可能比直接和大牛對話更加有直接做用。大牛的話可能讓你消化半天，依然不知所云，大牛可能以爲不少普通人以爲的難點是顯而易見的，不屑去解釋。可是社區裏面的技術人員，可能和你同樣慢慢進步過來的，知道哪些點是當年本身困惑的，若是踩過這一個個的坑，他們一點撥，你就會豁然開朗。
並且每一個人遇到的具體狀況不一樣，從事的行業不一樣，客戶的需求不一樣，於是軟件設計的時候考慮的因素不一樣，大牛是牛，可是不必定可以遇到和你同樣的場景，可是社區裏面，有你的同行業的，背景相近的技術人員，大家能夠討論出符合大家特定場景的解決方案。
第四：經過開源軟件，咱們做爲我的，比較容易找到工做
咱們面試的時候，經常遇到的問題是，怎麼可以把在原來工做中本身的貢獻，理解，設計，技術能力。其實我發現不少程序員不能很好的作的這一點，因此形成不少人面試很吃虧。緣由之一是背景信息不對稱，例如原來面臨的業務上很難的問題，面試官因爲不理解背景，並且短期解釋不清楚，而輕視候選人的水平，我也遇到過不少面試官才聽了幾分鐘，就會說，這不挺簡單的，你這樣這樣不就好了，而後完全否認大家一個團隊忙了三年的事情。緣由之二是不少有能力的程序員不會表達，致使真正寫代碼的說不明白，可能原來在公司裏面一個績效很是好，一個績效很是差，可是到了面試官那裏就拉平了。緣由之三是新的公司不能肯定你在上家公司作的工做，到這一家都能用的，例如你作的工做有30%是和具體業務場景相關的，70%是通用技術，可能下家公司只會爲你的通用技術部分買單。
開源軟件的好處就是，參與的人所掌握的技能都是通的，並且你們在同一個上下文裏面對話，面試官和候選人之間的信息差比較少。掌握某個開源軟件有多難，不用候選人本身說，你們內心都有數。
對於不少技術能力強，可是表達能力較弱的極少數人員來說，talk is cheap, show me the code，代碼呈上去，就可以表現出實力來了，並且面試官也不須要根據短短的半個小時瞭解一我的，能夠作不少背景調查。
另外因爲掌握的技術的通用的，你到下一家公司，立刻就可以上手，幾乎不須要預熱時間，對於雙方都有好處。
第五：經過開源軟件，咱們做爲招聘方，比較容易招到相應人員。
若是在創業公司待過的朋友會了解到創業公司招人很難，人員流失很快，並且創業公司每每對於開發進度要求很快，由於你們都在搶時間。於是開源軟件對於招聘方來說，也是好消息。首先創業公司沒辦法像大公司同樣，弄這麼多的技術大牛，本身徹底落地一套本身的體系，使用開源軟件快速搭建一套平臺先上線是最好的選擇。其次使用開源軟件，會使得招聘相對容易，市場上火的開源軟件會有大批的從業者，參與各類論壇和社區，比較容易挖到人。最後，開源軟件的使用使得新人來了以後沒有預熱時間，來了就上手，保證開發速度。
那如何快速上手一款開源軟件呢？我寫了一篇文章
在這篇文章中，我總結了九個步驟。
-
1、手動安裝起來，必定要手動
-
2、使用一下，推薦XXX in Action系列
-
3、讀文檔，讀全部的官方文檔，記不住，看不懂也要讀下來
-
4、瞭解核心的原理和算法，推薦XXX the definitive guide系列
-
5、看一本源碼分析的書，會讓你的源碼閱讀之旅事半功倍
-
6、開始閱讀核心邏輯源代碼
-
7、編譯並Debug源代碼
-
8、開發一個插件，或者對組件作少許的修改
-
9、大量的運維實踐經驗和麪向真實場景的定製開發
因此作一個雲架構師，必定不能脫離代碼，反而要不斷的擁抱開源軟件。
4、瞭解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的基礎知識方面，我寫了幾篇文章以下。
5、瞭解數據中心和網絡基礎知識
雲平臺固然會部署在數據中內心面，因爲數據中內心面的硬件設備也是很是專業的，於是不少地方機房部門和雲計算部門是兩個部門，可是做爲一個雲架構師，須要和機房部門進行溝通，於是須要必定的數據中心知識，在數據中內心面，最難搞定的是網絡，於是這裏面網絡知識是重中之重。
下面這個圖是一個典型的數據中心圖。
最外層是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網絡內幕》
這裏還自我推薦一下本人寫的極客時間專欄《趣談網絡協議》。
其中有個綜合場景，串起來全部的網絡協議。
6、基於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的官網不少文章很是值得學習。
對於虛擬化方面，我寫了如下的文章。
裸用KVM建立虛擬機，體驗virtualbox爲你作的10件事情
KVM虛擬機鏡像那點兒事，qcow2六大功能，內部快照和外部快照有啥區別？
7、基於Openvswitch瞭解網絡虛擬化
當虛擬機建立出來了，最主要的訴求就是要能上網，他能訪問到網上的資源，若是虛擬機裏面部署一個網站，也但願別人可以訪問到他。
這一方面依賴於qemu-KVM的網絡虛擬化，將網絡包從虛擬機裏面傳播到虛擬機外面，這須要物理機內核轉換一把，造成虛擬機內部的網卡和虛擬機外部的虛擬網卡。
另一方面就是虛擬機的網絡如何可以鏈接到物理網絡裏面。物理網絡經常稱爲underlay network，虛擬網絡經常稱爲overlay network，從物理網絡到虛擬網絡稱爲網絡虛擬化，能很是好的完成這件事情的是一個叫Openvswitch的虛擬交換機軟件。
Openvswitch會有一個內核驅動，監聽物理網卡，能夠將物理網卡上收到的包拿進來。虛擬機建立出來的外部的虛擬網卡也能夠添加到Openvswitch上，而Openvswitch能夠設定各類的網絡包處理策略，將網絡包在虛擬機和物理機之間進行傳遞，從而實現了網絡虛擬化。
對於Openvswitch，我主要是經過官方文檔進行研究，寫下了這個系列。
Openvswitch的入門篇
Openvswitch的操做篇
玩轉Openvwitch第二站：Bridge和Controller
玩轉Openvswitch第八站：Interface和Tunnel (下)
玩轉Openvswitch第八站：Interface和Tunnel (上)
Openvswitch的代碼分析篇
8、基於OpenStack瞭解雲平臺
當有了虛擬機，而且虛擬機可以上網了以後，接下來就是搭建雲平臺的時候了。
雲是基於計算，網絡，存儲虛擬化技術的，雲和虛擬化的主要區別在於，管理員的管理模式不一樣，用戶的使用模式也不一樣。
虛擬化平臺沒有多層次的豐富的租戶管理，沒有靈活quota配額的限制，沒有靈活的QoS的限制，多采用虛擬網絡和物理網絡打平的橋接模式，虛擬機直接使用機房網絡，沒有虛擬子網VPC的概念，虛擬網絡的管理和隔離不能和租戶隔離徹底映射起來。對於存儲也是，公司採購了統一的存儲，也不能和租戶的隔離徹底映射起來。
使用虛擬化平臺的特色是，對於這個平臺的操做徹底由運維部門統一管理，而不能將權限下放給業務部門本身進行操做。由於一旦容許不一樣的部門本身操做，你們都用機房網絡，在沒有統一管控的狀況下，很容易網段衝突了。若是業務部門向申請虛擬機，須要經過工單向運維部門統一的申請。固然這個運維部門很適應這種方式，由於原來物理機就是這樣管理的。
可是公有云，例如aws就沒辦法這樣，租戶千千萬萬，只能他們本身操做。在私有云裏面，隨着服務化甚至微服務化的進行，服務數目愈來愈多，迭代速度愈來愈快，業務部門須要更加頻繁的建立和消耗虛擬機，若是仍是由運維部統一審批，統一操做，會使得運維部門壓力很是大，並且極大限制了迭代速度，於是要引入 租戶管理，運維部靈活配置每一個租戶的配額quota和QoS，在這個配額裏面，業務部門隨時能夠按照本身的須要，建立和刪除虛擬機，無需知會運維部門。每一個部門均可以建立本身的虛擬網絡VPC，不一樣租戶的VPC以前徹底隔離，因此網段能夠衝突，每一個業務部門本身規劃本身的網絡架構，只有少數的機器須要被外網或者機房訪問的時候，須要少數的機房IP，這個也是和租戶映射起來的，能夠分配給業務部門機房網IP的個數範圍內，自由的使用。這樣每一個部門自主操做，迭代速度就可以加快了。
雲平臺中的開源軟件的表明是OpenStack，建議你們研究OpenStack的設計機制，是在雲裏面通用的，瞭解了OpenStack，對於公有云，容器雲，都能發現類似的概念和機制。
沿着OpenStack建立虛擬機的過程，我總結了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。
9、基於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的編排，同時也能跑各類大數據應用。
在容器領域，基於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
10、基於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程序的時候，有不少的方法論，這裏我總結了幾個，供您參考。
11、基於Lucene和ElasticSearch瞭解搜索引擎
當大數據將收集好的數據處理完畢以後，通常會保存在兩個地方，一個是正向索引，能夠用Hbase，Cassandra等文檔存儲，一個是反向索引，方便搜索，就會保存在基於Lucene的ElasticSearch裏面。
對於Lucene，在職業生涯的早期，寫過一個《Lucene 原理與代碼分析完整版》有500多頁。
對於搜索引擎的通用原理，寫了下面的文章。
12、基於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，就回滾到上一個版本了。全部的操做在代碼倉庫裏都是能夠看到的。
設計要點七：統一配置中心
服務拆分之後，服務的數量很是多，若是全部的配置都以配置文件的方式放在應用本地的話，很是難以管理。
能夠想象當有幾百上千個進程中有一個配置出現了問題，是很難將它找出來的，於是須要有統一的配置中心，來管理全部的配置，進行統一的配置下發。
在微服務中，配置每每分爲如下幾類：
-
一類是幾乎不變的配置，這種配置能夠直接打在容器鏡像裏面。
-
第二類是啓動時就會肯定的配置，這種配置每每經過環境變量，在容器啓動的時候傳進去。
-
第三類就是統一的配置，須要經過配置中心進行下發。例如在大促的狀況下，有些功能須要降級，哪些功能能夠降級，哪些功能不能降級，均可以在配置文件中統一配置。
設計要點八：統一日誌中心
一樣是進程數目很是多的時候，很難對成千上百個容器，一個一個登陸進去查看日誌，因此須要統一的日誌中心來收集日誌。
爲了使收集到的日誌容易分析，對於日誌的規範，須要有必定的要求，當全部的服務都遵照統一的日誌規範的時候，在日誌中心就能夠對一個交易流程進行統一的追溯。
例如在最後的日誌搜索引擎中，搜索交易號，就可以看到在哪一個過程出現了錯誤或者異常。
設計要點九：熔斷，限流，降級
服務要有熔斷，限流，降級的能力，當一個服務調用另外一個服務，出現超時的時候，應及時返回，而非阻塞在那個地方，從而影響其餘用戶的交易，能夠返回默認的託底數據。
當一個服務發現被調用的服務，由於過於繁忙，線程池滿，鏈接池滿，或者老是出錯，則應該及時熔斷，防止由於下一個服務的錯誤或繁忙，致使本服務的不正常，從而逐漸往前傳導，致使整個應用的雪崩。
當發現整個系統的確負載太高的時候，能夠選擇降級某些功能或某些調用，保證最重要的交易流程的經過，以及最重要的資源所有用於保證最核心的流程。
還有一種手段就是限流，當既設置了熔斷策略，又設置了降級策略，經過全鏈路的壓力測試，應該可以知道整個系統的支撐能力。
於是就須要制定限流策略，保證系統在測試過的支撐能力範圍內進行服務，超出支撐能力範圍的，可拒絕服務。
當你下單的時候，系統彈出對話框說 「系統忙，請重試」，並不表明系統掛了，而是說明系統是正常工做的，只不過限流策略起到了做用。
設計要點十：全方位的監控
當系統很是複雜的時候，要有統一的監控，主要有兩個方面，一個是是否健康，一個是性能瓶頸在哪裏。
當系統出現異常的時候，監控系統能夠配合告警系統，及時地發現，通知，干預，從而保障系統的順利運行。
當壓力測試的時候，每每會遭遇瓶頸，也須要有全方位的監控來找出瓶頸點，同時可以保留現場，從而能夠追溯和分析，進行全方位的優化。
我會將微服務相關的文章更加細化的寫出來。
有關微服務和容器之間的結合，寫了下面的文章。
最後。
小弟參加GIAC年度新人評選，馬了這麼多字，能幫忙投個票嗎？請點擊原文鏈接。
劉超 網易雲技術架構部總監
長期致力於雲計算開源技術的分享，佈道和落地，將網易內部最佳實踐服務客戶與行業。
技術分享：出版《Lucene應用開發解密》，極客時間專欄《趣談網絡協議》，我的公衆號《劉超的通俗雲計算》文章Kubernetes及微服務系列18篇，Mesos系列30篇，KVM系列25篇，Openvswitch系列31篇，OpenStack系列24篇，Hadoop系列10篇。公衆號文章《終於有人把雲計算，大數據，人工智能講明白了》累積10萬+
大會佈道：InfoQ架構師峯會明星講師，做爲邀請講師在QCon，LC3，SACC，GIAC，CEUC，SoftCon，NJSD等超過10場大型技術峯會分享網易的最佳實踐
行業落地：將網易的容器和微服務產品在銀行，證券，物流，視頻監控，智能製造等多個行業落地。