云架構師負責管理一個組織中的云計算架構，特別是隨著云技術日益復雜化。云計算架構涵蓋了與云計算相關的一切，包括管理云存儲所需的前端平臺、服務器、存儲、交付和網(wǎng)絡。

[[248138]]

 

本文作者從如下幾個方面全面剖析云架構師的進階攻略：

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

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

三個維度

 

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

IT 架構

IT 架構其實就是計算，網(wǎng)絡，存儲。這是云架構師的基本功，也是最傳統(tǒng)的云架構師應該首先掌握的部分。

良好設計的 IT 架構，可以降低 CAPEX 和 OPEX，減輕運維的負擔。數(shù)據(jù)中心，虛擬化，云平臺，容器平臺都屬于 IT 架構的范疇。

應用架構

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

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

數(shù)據(jù)架構

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

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

六個層面

 

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

基礎設施層

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

為了管理的方便，在物理機之上會部署虛擬化，例如 Vmware，可以將對于物理機復雜的運維簡化為虛擬機靈活的運維。

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

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

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

數(shù)據(jù)層

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

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

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

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

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

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

中間件層

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

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

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

但是缺點也比較明顯，Memcached 嚴格來講沒有集群機制，橫向擴展完全靠客戶端來實現(xiàn)。

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

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

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

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

基礎服務層

有的時候成為中臺層，將通用的能力抽象為服務對外提供原子化接口。

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

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

如果將這些底層的變更攔截在基礎服務層，上層僅僅使用基礎服務層的接口，這樣底層的變化會對上層透明，可以逐步演進。

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

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

在這一層，會經(jīng)常進行服務的拆分，實現(xiàn)開發(fā)獨立，上線獨立，擴容獨立，容災降級獨立。

微服務的拆分不應該是一個運動，而應該是一個遇到耦合痛點的時候，不斷解決，不斷演進的一個過程。

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

用戶接口層

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

這一層有時候稱為接入層。在這一層，動態(tài)資源和靜態(tài)資源應該分離，靜態(tài)資源應該在接入層做緩存，使用 CDN 進行緩存。

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

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

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

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

作為一個云架構師還是很復雜的，千里之行，始于足下，讓我們慢慢來。

了解云計算的歷史演進與基本原理

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

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

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

第一：云計算的本質是實現(xiàn)從資源到架構的全面彈性。

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

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

 

架構層面的彈性也即實現(xiàn)通用應用和自有應用的彈性擴展。對于通用的應用，多集成為 PaaS 平臺。

對于自己的應用，通過基于腳本的 Puppet、Chef、Ansible 到基于容器鏡像的容器平臺 CaaS。

 

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

 

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

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

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

 

開源軟件是進階的利器

架構師除了要掌握大的架構和理論之外，指導落地也是必備的技能，所謂既要懂設計模式，也要懂代碼。那從哪里去學習這些良好的，有借鑒意義的，可以落地的架構實踐呢?

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

當某個軟件做的好，所有人都愛用，這個軟件的代碼呢，我封閉起來只有我公司知道，其他人不知道，如果其他人想用這個軟件，就要付我錢，這就叫閉源。但是世界上總有一些大?？床粦T錢都讓一家賺了去。

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

非常建議大家了解，深入研究，甚至參與貢獻開源軟件，因為收益匪淺。

第一：通過開源軟件，我們可以了解大牛們的架構原則，設計模式。

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

即便進去了，他可能是公司的高層，每天很忙，不怎么見得到他，就算當面討教，時間也不會很長，很難深入交流。

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

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

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

第二：通過開源軟件，我們可以學習到代碼級的落地實踐。

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

這是因為沒有看到代碼，所有的理論都是空中樓閣，當你到了具體的代碼設計層面，那些學會的設計模式，無法轉化為你自己的實踐。

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

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

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

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

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

大牛的話可能讓你消化半天，依然不知所云，大?？赡苡X得很多普通人覺得的難點是顯而易見的，不屑去解釋。

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

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

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

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

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

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

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

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

原因之二：很多有能力的程序員不會表達，導致真正寫代碼的說不明白。可能原來在公司里面一個績效非常好，一個績效非常差，但是到了面試官那里就拉平了。

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

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

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

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

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

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

如果在創(chuàng)業(yè)公司待過的朋友會了解到創(chuàng)業(yè)公司招人很難，人員流失很快，而且創(chuàng)業(yè)公司往往對于開發(fā)進度要求很快，因為大家都在搶時間。

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

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

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

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

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

了解 Linux 基礎知識

作為一個云架構師，首要的一點，就是要熟悉 Linux 的基礎知識，基本原理了。

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

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

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

 

當然因為辦公的原因，平時使用 Windows 的比較多，所以在學校里，很多同學接觸到的操作系統(tǒng)基本上都是 Windows，但是一旦從事計算機行業(yè)，就一定要跨過 Linux 這道坎。

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

 

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

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

 

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

學習 Linux 主要包含兩部分，一個是怎么用，一個是怎么編程，背后原理是什么。

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

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

Linux 的架構如下圖：

 

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

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

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

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

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

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

 

 

 

 

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

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

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

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

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

例如進程 1 的 10 號倉庫，對應到真實的倉庫是 110 號，進程 2 的 20 號倉庫，對應到真實的倉庫是 120 號。

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

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

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

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

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

 

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

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

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

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

下面這個圖是一個典型的數(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

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

第三層是 Access Layer，就是一個個機架的服務器，用接入交換機連接在一起。

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

 

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

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

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

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

基于 KVM 了解計算虛擬化

當物理機搭建完畢之后，接下來就是基于物理機上面搭建虛擬機了。

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

 

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

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

 

對于 Openvswitch，我主要是通過官方文檔進行研究。

基于 OpenStack 了解云平臺

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

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

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

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

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

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

因為一旦允許不同的部門自己操作，大家都用機房網(wǎng)絡，在沒有統(tǒng)一管控的情況下，很容易網(wǎng)段沖突了。

如果業(yè)務部門想申請?zhí)摂M機，需要通過工單向運維部門提統(tǒng)一的申請。當然這個運維部門很適應這種方式，因為原來物理機就是這樣管理的。

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

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

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

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

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

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

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

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

第一：基于 PKI Token 的認證模式

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

當我們要訪問一個資源，通過用戶名密碼或者 AK/SK 登錄之后，如果認證通過，接下來對于資源的訪問，不應該總帶著用戶名密碼，而是登錄的時候形成一個 Token，然后訪問資源的時候帶著 Token，服務端通過 Token 去認證中心進行驗證即可。

 

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

 

 



 

 

第二：基于 Role Based Access Control 的鑒權模式

對于權限控制，我們學會比較通用的 Role Based Access Control 的權限控制模式， 形成“用戶-角色-權限”的授權模型。

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

 

 

 

 

第三：基于 Quota 的配額管理

可以通過設置計算，網(wǎng)絡，存儲的 quota，設置某個租戶自己可以自主操作的資源量。

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

 

當需要從一個資源池里面，選擇一個節(jié)點，使用這個節(jié)點上的資源的時候，一個通用的 Scheduler 機制是：

首先進行預選，也即通過 Filter，將不滿足條件的過濾掉。

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

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

 

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

第六：基于 Copy On Write 的鏡像機制

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

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

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

 

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

第七：基于 namespace 和 cgroup 的隔離和 Qos 機制

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

 

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

 

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

 

第八：基于 iptables 的安全機制

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

 

基于 Mesos 和 Kubernetes 了解容器平臺

搭建完畢虛擬化層和云平臺層，接下來就是容器層了。Docker 有幾個核心技術，一個是鏡像，一個是運行時，運行時又分看起來隔離的 namespace 和用起來隔離的 cgroup。

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

 

對于運行時，Docker 使用的 namespace 除了 network namespace 外，還有很多，如下表格所示。

 

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

可見容器并沒有使用更新的技術，而是一種新型的交付方式，也即應用的交付應該是一容器鏡像的方式交付，容器一旦啟動起來，就不應該進入容器做各種修改，這就是不可改變基礎設施。

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

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

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

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

 

當我們深入分析 Kubernetes 管理容器模式的時候，我們也能看到熟悉的面孔。

在 Kubernetes 里面，租戶之間靠 namespace 進行隔離，這個不是 Docker 的 namespace，而是 Kubernetes 的概念。

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

 

當 Kubernetes 想選擇一個節(jié)點運行 pod 的時候，選擇的過程也是通過預選和優(yōu)選兩個階段：

預選(Filtering)

• PodFitsResources 滿足資源。
• PodSelectorMatches 符合標簽。
• PodFitsHost 符合節(jié)點名稱。

優(yōu)選(Weighting)

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

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

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

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

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

 

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

 

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

對于數(shù)據(jù)架構的部分，其實經(jīng)歷了三個過程，分別是 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 的時候，跑任務的方式只有這一種，為了應對復雜的場景，將任務的調(diào)度和資源的調(diào)度分成兩層。

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

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

 

這里 Yarn 相當于外包公司的老板，所有的員工都是 Worker，都是他的資源，外包公司的老板是不清楚接的每一個項目的。

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

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

 

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

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

基于 Lucene 和 ElasticSearch 了解搜索引擎

 

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

基于 Spring Cloud 了解微服務

最后到了應用架構，也即微服務。接下來細說微服務架構設計中不得不知的十大要點。

 

設計要點一：負載均衡 + API 網(wǎng)關

 

在實施微服務的過程中，不免要面臨服務的聚合與拆分。

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

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

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

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

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

設計要點二：無狀態(tài)化與獨立有狀態(tài)集群

 

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

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

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

• 跨機房隨意地部署，也即遷移性。
• 彈性伸縮，很容易地進行擴容。

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

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

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

設計要點三：數(shù)據(jù)庫的橫向擴展

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

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

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

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

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

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

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

設計要點四：緩存

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

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

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

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

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

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

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

設計要點五：服務拆分與服務發(fā)現(xiàn)

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

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

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

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

我沒改還要我重啟，我沒改還讓我發(fā)布，我沒改還要我開會，都是應該拆分的時機。

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

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

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

設計要點六：服務編排與彈性伸縮

 

 

當服務拆分了，進程就會非常的多，因而需要服務編排來管理服務之間的依賴關系，以及將服務的部署代碼化，也就是我們常說的基礎設施即代碼。

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

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

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

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

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

設計要點七：統(tǒng)一配置中心

 

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

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

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

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

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

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

設計要點八：統(tǒng)一日志中心

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

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

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

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

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

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

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

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

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

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

設計要點十：全方位的監(jiān)控

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

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

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