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

[[248138]]

 

本文作者從如下幾個(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)，越來(lái)越成為云架構(gòu)師所必需的技能。

良好設(shè)計(jì)的應(yīng)用架構(gòu)，可以實(shí)現(xiàn)快速迭代和高并發(fā)。數(shù)據(jù)庫(kù)，緩存，消息隊(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)營(yíng)。搜索引擎，Hadoop，Spark，人工智能都屬于數(shù)據(jù)架構(gòu)的范疇。

六個(gè)層面

 

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

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

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

為了管理的方便，在物理機(jī)之上會(huì)部署虛擬化，例如 Vmware，可以將對(duì)于物理機(jī)復(fù)雜的運(yùn)維簡(jiǎ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)越來(lái)越重要，對(duì)于標(biāo)準(zhǔn)化交付和彈性伸縮的需求越來(lái)越大，容器做為軟件交付的集裝箱，可以實(shí)現(xiàn)基于鏡像的跨環(huán)境遷移，Kubernetes 是容器管理平臺(tái)的事實(shí)標(biāo)準(zhǔn)。

數(shù)據(jù)層

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

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

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

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

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

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

中間件層

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

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

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

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

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

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

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

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

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

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

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

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

如果將這些底層的變更攔截在基礎(chǔ)服務(wù)層，上層僅僅使用基礎(chǔ)服務(wù)層的接口，這樣底層的變化會(huì)對(duì)上層透明，可以逐步演進(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)降級(jí)獨(dú)立。

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

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

用戶接口層

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

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

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

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

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

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

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

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

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

這樣的知識(shí)體系對(duì)我們來(lái)說(shuō)，就不是一個(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è)過(guò)程經(jīng)歷了從物理機(jī)，到虛擬化，到云計(jì)算的一個(gè)演進(jìn)過(guò)程。

 

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

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

 

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

 

當(dāng)數(shù)據(jù)量很小時(shí)，很少的幾臺(tái)機(jī)器就能解決。慢慢的，當(dāng)數(shù)據(jù)量越來(lái)越大，最牛的服務(wù)器都解決不了問(wèn)題時(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è)軟件做的好，所有人都愛(ài)用，這個(gè)軟件的代碼呢，我封閉起來(lái)只有我公司知道，其他人不知道，如果其他人想用這個(gè)軟件，就要付我錢，這就叫閉源。但是世界上總有一些大?？床粦T錢都讓一家賺了去。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原因之二：很多有能力的程序員不會(huì)表達(dá)，導(dǎo)致真正寫代碼的說(shuō)不明白?？赡茉瓉?lái)在公司里面一個(gè)績(jī)效非常好，一個(gè)績(jī)效非常差，但是到了面試官那里就拉平了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

根據(jù)今年 W3Techs 的統(tǒng)計(jì)，對(duì)于服務(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 陣營(yíng)，很多智能終端，智能設(shè)備等開發(fā)職位，都需要懂 Linux 的人員。

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

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

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

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

 

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

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

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

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

就像你要打車，要通過(guò)打車軟件的界面，下發(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)程用來(lái)存放數(shù)據(jù)的，就像一間一間的倉(cāng)庫(kù)。

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

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

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

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

對(duì)于 Linux 來(lái)講，很多東西都是文件，例如進(jìn)程號(hào)會(huì)對(duì)應(yīng)一個(gè)文件，建立一個(gè)網(wǎng)絡(luò)連接也對(duì)應(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ò)管理

 

對(duì)于 Linux 來(lái)講，網(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)，對(duì)于網(wǎng)絡(luò)的了解也是必須的。

 

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

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

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

對(duì)于網(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ī)搭建完畢之后，接下來(lái)就是基于物理機(jī)上面搭建虛擬機(jī)了。

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

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

 

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

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

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

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

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

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

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

 

對(duì)于 qemu-kvm 來(lái)說(shuō)，和上面的原理是一樣的，其中 qemu 的 emu 是 emulator 的意思，也即模擬器，就是翻譯的意思。

KVM 是一個(gè)可以使用 CPU 的硬件輔助虛擬化的方式，而網(wǎng)絡(luò)和存儲(chǔ)的，需要通過(guò)特殊的 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)建出來(lái)了，最主要的訴求就是要能上網(wǎng)，它能訪問(wèn)到網(wǎng)上的資源，如果虛擬機(jī)里面部署一個(gè)網(wǎng)站，也希望別人能夠訪問(wèn)到它。

這一方面依賴于 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)來(lái)。

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

 

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

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

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

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

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

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

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

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

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

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

但是公有云，例如 AWS 就沒(méi)辦法這樣，租戶千千萬(wàn)萬(wàn)，只能他們自己操作。

在私有云里面，隨著服務(wù)化甚至微服務(wù)化的進(jìn)行，服務(wù)數(shù)目越來(lái)越多，迭代速度越來(lái)越快，業(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ī)，無(wú)需知會(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ī)房訪問(wèn)的時(shí)候，需要少數(shù)的機(jī)房 IP。

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

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

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

 

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

 

 



 

 

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

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

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

 

 

 

 

第三：基于 Quota 的配額管理

可以通過(guò)設(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ù)選，也即通過(guò) Filter，將不滿足條件的過(guò)濾掉。

然后進(jìn)行優(yōu)選，也即對(duì)于過(guò)濾后，滿足條件的候選人，通過(guò)計(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èn)，或者要訪問(wèn)物理網(wǎng)絡(luò)的時(shí)候，需要通過(guò)路由器。

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

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

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

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

 

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

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

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

 

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

 

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

 

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

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

 

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

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

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

 

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

 

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

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

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

有了容器之后，接下來(lái)就是容器平臺(tái)的選型，其實(shí) Swarm、Mesos、Kubernetes 各有優(yōu)勢(shì)，也可以在不同的階段，選擇使用不同的容器平臺(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 對(duì)于 namespace，也有 Quota 配置，使用 ResourceQuota。

 

當(dāng) Kubernetes 想選擇一個(gè)節(jié)點(diǎn)運(yùn)行 pod 的時(shí)候，選擇的過(guò)程也是通過(guò)預(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)

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

如下圖是 Map-Reduce 1.0 的過(guò)程：

 

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

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

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

每個(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í)候，如果需要員工干活，需要向外包公司老板申請(qǐng)。

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ù)。接下來(lái)細(xì)說(shuō)微服務(wù)架構(gòu)設(shè)計(jì)中不得不知的十大要點(diǎn)。

 

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

 

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

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

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

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

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

 

影響應(yīng)用遷移和橫向擴(kuò)展的重要因素就是應(yīng)用的狀態(tài)。無(wú)狀態(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è)是無(wú)狀態(tài)的部分，一個(gè)是有狀態(tài)的部分。

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

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

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

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

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

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

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

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

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

再往上就是橫向怎么承載大的吞吐量的問(wèn)題，上面有一個(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ù)，對(duì)于業(yè)務(wù)層是沒(méi)有任何感知的。

另外一個(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ā)場(chǎng)景下緩存是非常重要的。要有層次的緩存，使得數(shù)據(jù)盡量靠近用戶。數(shù)據(jù)越靠近用戶能承載的并發(fā)量也越大，響應(yīng)時(shí)間越短。

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

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

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

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

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

當(dāng)然動(dòng)態(tài)數(shù)據(jù)還可以做一定的靜態(tài)化，也即降級(jí)成靜態(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è)代碼倉(cāng)庫(kù)的時(shí)候，往往對(duì)代碼的修改就會(huì)相互影響。

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

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

我沒(méi)改還要我重啟，我沒(méi)改還讓我發(fā)布，我沒(méi)改還要我開會(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)和降級(jí)，在大促的時(shí)候，可能需要犧牲一部分的邊角功能，但是如果所有的代碼耦合在一起，很難將邊角的部分功能進(jìn)行降級(jí)。

當(dāng)然拆分完畢以后，應(yīng)用之間的關(guān)系就更加復(fù)雜了，因而需要服務(wù)發(fā)現(xiàn)的機(jī)制，來(lái)管理應(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ù)編排來(lái)管理服務(wù)之間的依賴關(guān)系，以及將服務(wù)的部署代碼化，也就是我們常說(shuō)的基礎(chǔ)設(shè)施即代碼。

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

服務(wù)要有熔斷，限流，降級(jí)的能力，當(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)檫^(guò)于繁忙，線程池滿，連接池滿，或者總是出錯(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ù)載過(guò)高的時(shí)候，可以選擇降級(jí)某些功能或某些調(diào)用，保證最重要的交易流程的通過(guò)，以及最重要的資源全部用于保證最核心的流程。

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

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

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

設(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)壓力測(cè)試的時(shí)候，往往會(huì)遭遇瓶頸，也需要有全方位的監(jiān)控來(lái)找出瓶頸點(diǎn)，同時(shí)能夠保留現(xiàn)場(chǎng)，從而可以追溯和分析，進(jìn)行全方位的優(yōu)化。