雲計算與 Cloud Native | 數人云CEO王璞@KVM分享實錄

今天小數又給你們帶來一篇乾貨滿滿的分享——來自KVM社區線上羣分享的實錄，分享嘉賓是數人云CEO王璞，題目是《雲計算與 Cloud Native》。這是數人云在KVM社區羣分享的第一彈，以後還有數人云CTO肖德時、COO謝樂冰的Docker與Mesos的應用實戰經驗分享，敬請期待！

嘉賓介紹

王璞，數人云創始人兼CEO
美國 George Mason 大學計算機博士。擅長分佈式計算、大規模機器學習、海量數據處理。曾擔任 Google 廣告部門數據平臺構架師，負責管理每秒訪問量全球最高的架構平臺。

分享實錄

雲計算技術源於互聯網公司，如今雲計算已是下一代企業級IT的發展趨勢。雲計算最大的特色是彈性和靈活，幫助企業應對複雜的業務需求。可是基於雲計算的IT構架和上一代的IT構架有很大不一樣，只有雲原生應用（Cloud Native Application）才能充分發揮雲計算彈性和靈活的特性。

目前，微服務是雲原生應用比較主流的一種構架，微服務的理念是用服務來實現功能模塊組件化，把大的業務邏輯拆爲多個很微小的服務，每一個微服務實現一個簡單的功能，微服務之間鬆散耦合。聽從微服務構架的應用具備彈性和靈活的特性，可是在構架上，微服務比傳統應用構架複雜不少。

PaaS平臺的出現幫助開發人員打造雲原生應用，讓開發人員專一於業務開發層面，併爲構架層面保駕護航。然而上一代的PaaS平臺過於複雜和笨重，沒有獲得普遍的應用。基於Docker和Mesos打造的DCOS是下一代輕量級PaaS平臺的典型表明，DCOS極大地下降了PaaS平臺的複雜度，更加方便企業開發人員實現各類業務應用，幫助企業輕鬆打造基於雲計算的軟件基礎設施。

Google如何作雲計算

Google一直是雲計算技術的領導者。我有幸在Google工做，接觸到了Google強大的內部雲計算平臺。Google全部的數據中心加起來有大約數百萬臺服務器，這麼多服務器被Google的分佈式管理平臺Borg統一管理，造成巨大的資源池，支撐了Google龐大的業務體系。Google把全部的服務器分紅了近百個集羣，每一個集羣稱爲一個Cell。每一個Cell由幾萬臺處於同一物理位置的服務器組成，每一個Cell由幾個Borg主節點負責管理其他幾萬臺服務器，被管理的每臺服務器對應一個Borg從節點。

Google的開發人員會向Borg提交任務執行申請，Borg負責把任務運行在一個或多個Cell。Borg運行的任務有優先級，高優先級的任務會搶佔低優先級任務的資源。爲了防止過分搶佔，Borg在管理每一個Cell資源的時候，任務優先級越高，可供分配的總資源越少，反之，任務優先級越低，可供分配的總資源越多，保證低優先級的任務也會獲得很好的執行，而不會總被高優先級任務搶佔。

Google內部雖然沒有強調PaaS、容器、不可變基礎設施（Immutable Infrastructure）以及微服務的概念，可是Google內部到處體現着這些理念。

首先，Google內部的雲計算平臺除了Borg，還有各類軟件基礎設施，好比Google File System、MapReduce、BigTable、Chubby、Stubby、PubSub等等，組成了一個功能無比強大的PaaS。這些軟件基礎設施知足了基於Google內部雲計算平臺開發時碰到的各類需求，使得Google的開發人員在開發時很是方便，能夠專一於業務自己，而沒必要過多考慮可擴展性、容錯性等等複雜的問題，極大地提升了開發效率。這正是PaaS的功能，提升開發效率，下降開發複雜度，保證應用的性能、可靠性等等。

其次，Google內部的業務應用，都是把業務程序和各類依賴庫打包在一塊兒，造成巨大的二進制文件，這樣應用程序在生產環境的服務器上運行的時候，不須要額外的依賴。更進一步，Google內部不一樣應用程序在同一服務器上運行時，是用Cgroup技術進行資源隔離，防止某個程序佔用過多資源。這些其實都是容器的理念，讓應用程序具有了可移植性，並對應用進行資源隔離。

再者，Google內部生產環境服務器，基本上是被Borg自動管理，每臺服務器上只安裝Linux、Borg程序以及必備的監控程序等，開發或運維人員幾乎不會登錄上去作什麼操做。這樣，Google每臺生產環境服務器的狀態都是不可變的，極大地簡化了對服務器的運維管理工做，這正是不可變基礎設施的理念。

另外，Google內部也是按照微服務的方式來組織構架團隊。Google各個大的部門內部，按照不一樣的業務功能劃分出不一樣的小團隊，每一個小團隊負責開發維護一個具體的功能模塊組件，也就是一個「微」服務。不一樣微服務之間經過遠程過程調用（RPC）相互協同依賴，實現了很大規模的業務。好比我以前所在的團隊，是負責Google廣告平臺用戶數據收集的業務，所維護的微服務有數千個應用實例在運行。

雲原生應用與傳統架構

雲計算最大的特色是彈性和靈活，企業採用雲計算技術能夠輕鬆應對複雜的業務需求。通常來講，雲計算分爲三層，IaaS、PaaS和SaaS：IaaS提供資源彈性，PaaS提供應用彈性，SaaS提供服務彈性。目前IaaS和SaaS相對成熟，PaaS相對早期。PaaS最大的做用是幫助企業打造雲原生應用（Cloud Native Application），使得企業的業務應用充分享受雲計算帶來的靈活和彈性。

傳統IT構架最大的問題在於不能知足複雜的業務需求。企業信息化通過多年發展，不少企業的業務已經實現了IT化。每家企業都面臨着激烈的商業競爭，業務的需求每每紛繁複雜，勢必要求IT系統能靈活應對業務的需求，但實際狀況並不是如此，每每是企業業務部門的需求很長時間IT部門才能實現。雲計算的出現，很大程度緩解了企業內部IT跟不上業務發展需求的矛盾。

雲原生應用的優勢體如今具備良好的可擴展性、伸縮性和容錯性：當業務需求發生變化時，雲原生應用能夠作到快速迭代；當業務規模發生變化時，雲原生應用能夠作到彈性伸縮；當IT系統出現軟硬件故障時，雲原生應用有良好的容錯機制，能夠作到讓業務應用不宕機。雲原生應用的這些特性，能極大地幫助企業提高業務能力，在激烈的競爭中佔據優點。互聯網公司的快速發展，已經印證了雲計算技術和雲原生應用相比傳統IT構架的巨大優點。

可是雲原生應用的種種良好特性並非很輕易就能實現的，企業開發人員在開發業務應用的時候，還要考慮將來應用的可擴展性和容錯性，這極大地增長了開發的複雜度。因而PaaS的出現，正是要幫助開發人員下降雲原生應用的開發複雜度，讓開發人員仍是專一於業務應用的開發，爲開發人員屏蔽底層細節。

PaaS每每會制定出一些開發範式，只要企業的開發人員聽從這些範式，那麼開發出的業務應用就能得到雲原生應用的特性。可是以CloudFoundry爲表明的上一代PaaS，因爲規範過於複雜，沒有在企業級獲得很好的應用。下一代輕量級PaaS（Micro PaaS），特別強調輕量的特性，沒有對開發人員制定過多的開發範式，更可能是在軟件設計層面給出指導，極大地下降了使用門檻。好比，輕量級PaaS倡導應用聽從微服務構架設計，就能具備良好的可擴展性；再如，輕量級PaaS倡導應用盡可能聽從無狀態設計，就能得到良好的容錯性。微服務構架和無狀態設計，更可能是軟件設計理念，而不是諸如EJB、RESTful這樣具體的編程規範，下降了開發人員的學習成本，對開發人員更加友好。

微服務和SOA異同點

微服務是眼下很是流行的應用設計框架。如前所述，微服務不是具體的編程規範，而是軟件設計理念。微服務是伴隨互聯網公司業務規模快速擴張進而演化得來的設計模式，Google、Amazon、Netflix這些互聯網巨頭都是微服務的先行者和倡導者。聽從微服務設計，使得互聯網巨頭的業務應用具備良好的可擴展性：一方面保持業務應用快速迭代，同時應用迭代速度沒有隨着業務規模擴展急劇減緩；另外一方面保證業務應用具備彈性伸縮能力，能處理海量業務帶來的巨大負載。

微服務有幾個主要的設計理念：

一、經過服務實現組件化。傳統的IT構架是把全部的業務邏輯用一個大而全的應用來實現，各個功能組件模塊是在一個應用內部。這樣作的後果是模塊之間很容易緊密耦合，隨着應用愈來愈大，失去了可擴展性，一旦要修改業務邏輯，就會牽一髮而動全身，致使應用迭代很是緩慢。微服務使用服務的形式來實現各個功能組件模塊，各個模塊間的依賴經過服務的方式來組織，即一個模塊經過遠程過程調用來依賴另外一個模塊，每一個模塊是一個微服務。這樣作使得模塊之間很容易鬆散耦合，每一個微服務規定好服務的形式，諸如請求的格式以及響應的格式，而後多個微服務組合起來共同實現整個業務邏輯。如圖一所示。

圖一：總體型應用程序與微服務架構應用程序

二、微服務的鬆散耦合構架，使得企業能夠按照業務功能來組織團隊，每一個小團隊負責一個微服務，以下降團隊間的溝通成本。不少企業的研發團隊一般按開發職責劃分，諸如前端開發團隊、中間件開發團隊、數據庫團隊等等。這樣按職責劃分加大了團隊間溝通成本，由於每一個具體的業務需求都有可能涉及先後端，所以多個職能團隊要配合才能實現具體的業務需求，這樣無疑溝通成本很高。按照微服務的方式，團隊是按業務功能來組織劃分，而不是按照開發職責劃分，這樣可讓具體的業務需求落在某個團隊內部，避免涉及多個團隊，從而極大地下降了團隊間的溝通成本。這也符合康威法則：任何組織在設計一套系統（廣義層面的系統）時，其設計成果都會直接體現該組織所使用的溝通結構。如圖二所示。

圖二：康威定律的實際體現

三、企業按照業務功能來組織團隊，每一個團隊負責一個微服務，能夠作到「誰構建，誰運行」，這將極大下降運維複雜度。若是按照傳統的IT方式，開發團隊開發出來的應用交給運維團隊去上線維護，不只週期長，並且運維複雜度高，由於運維團隊畢竟不瞭解業務實現細節，應用出了問題還須要涉及開發和運維兩個團隊來配合。若是按照微服務的方式，每一個團隊開發一個微服務，並負責該微服務的上線運行，不涉及運維團隊，這樣作不只週期短，並且下降運維複雜度，某個微服務出現問題僅涉及所負責的開發團隊。「誰構建，誰運行」還可讓每一個團隊都經歷整個產品的生命週期。採用微服務構架後，運維團隊將更多負責總體業務相關的工做，好比總體業務的資源規劃、穩定性、性能等等。

四、有了微服務，能夠方便地作到離散化數據管理。每一個微服務能夠自行管理各自的數據，包括不一樣業務的數據、不一樣微服務的配置等等，更加切實匹配業務需求。如圖三所示。

圖三：微服務架構的離散數據管理

五、微服務構架使得持續集成和持續交付變得更加便捷。對比傳統IT構架，有了微服務，集成和交付的單元從大而全的總體應用變成了各個微服務。這樣，每一個微服務均可以靈活地集成和交付，下降了集成和交付的複雜度，提升了業務應用迭代的速度，進而提高了企業的業務能力。如圖四所示。

圖四：微服務構架使得持續集成和持續交付變得更加便捷

微服務常常被拿來與十年前就提出的面向服務架構（SOA）進行比較，由於微服務和SOA有類似的主張。SOA實際所指的是利用企業服務總線實現的集成化總體應用程序，企業服務總線一般包含複雜度極高的消息跌幅、編排、轉換以及業務規則應用等機制。準確講，SOA是中間件時代的一種開發範式，微服務是雲計算時代輕量級PaaS的開發範式。

支撐微服務的問題和挑戰

前面提到微服務最大好處是使得應用具備可擴展性，方便靈活應對業務的複雜需求。凡事必有兩面性，微服務提高了應用的可擴展性，可是微服務也有其複雜性的一面。

首先，微服務以服務的形式實現組件化模塊化，不一樣功能模塊組件之間經過服務的形式，即遠程過程調用的方式，來相互通信。這樣一來，模塊或組件間的耦合度下降了，可是通信效率也下降了。畢竟遠程過程調用比共享內存的方式要慢不少。此外，爲了提升應用的容錯性，通常微服務之間的遠程過程調用都儘可能設計爲異步通信的方式。異步通信顯然比同步通信在開發複雜度方面增長很多。

其次，對於按微服務構架設計的應用進行修改迭代的時候，若是要修改的部分僅限於某個或某些微服務組件內部，那就比較容易，不涉及微服務組件間的依賴，好比更改一個微服務內部的業務邏輯、把一個微服務組件分拆爲多個微服務。可是一旦要修改的部分要牽扯到已有微服務組件之間的依賴，那改動起來仍是有必定工做量的，好比遠程過程調用的接口修改，或者更進一步，從新定義兩個或多個微服務之間的業務邊界。若是微服務構架設計的很差，應用迭代的時候頻繁更改微服務間的依賴關係，也就失去了良好的可擴展性。

再者，因爲按照微服務構架設計的應用自然是分佈式應用，勢必在故障排除方面增長了複雜度。分佈式應用的維護對遠程監控的依賴很強，由於分佈式應用會運行在不少臺服務器上，並且會在不一樣服務器上動態調度遷移，一旦發生故障，不可能要求運維人員逐一檢查每臺服務器，必須有統一的監控平臺，實時監控應用的運行狀況，並統一收集日誌用於故障排查。此外，微服務之間若是是異步通信機制，也增長了錯誤檢查的複雜度。

下一代輕量級PaaS：基於Docker+Mesos的DCOS

基於Docker和Mesos打造的Data Center Operating System（DCOS），是下一代輕量級PaaS的表明。以Docker爲表明的容器技術，爲DCOS和企業業務應用之間，定義了清晰的邊界：DCOS提供統一的、標準的容器運行環境，知足容器運行時的各類需求，諸如調度、編排、容錯恢復、彈性伸縮、服務發現、負載均衡、監控報警等等；容器內部封裝企業的業務應用，爲應用提供良好的可移植性。

DCOS的輕量特性主要體如今以下方面：

首先，企業的開發人員不須要了解容器以外的太多細節，使得開發人員能夠專一於開發業務，下降了開發人員的開發複雜度。

其次，DCOS爲雲原生應用提供良好的彈性，包括可擴展性、伸縮性和容錯性。開發人員聽從微服務構架和無狀態設計開發雲原生應用，一方面能夠經過DCOS快速集成和交付上線，加快迭代週期，另外一方面DCOS爲雲原生應用提供很好的彈性伸縮能力，能夠按需使用計算資源，再一方面DCOS使雲原生應用具備很好的容錯能力。

再者，DCOS極大地下降了運維複雜度。DCOS實現了不可變基礎設施，DCOS在每臺服務器上只安裝Linux、Docker、Mesos等DCOS的組件，不包括任何業務應用相關的依賴，再加上DCOS的容錯機制，使得生產系統的運維複雜度大大下降。

總之，雲計算是下一代企業級IT的發展趨勢，雲計算相關技術正在逐漸演化成熟，特別是PaaS領域的技術，正在快速發展。以DCOS爲表明的下一代輕量級PaaS正逐漸爲企業客戶所接受。由於DCOS具備輕量的優勢，只要企業開發人員聽從微服務和無狀態設計開發出雲原生業務應用，DCOS就能保證雲原生應用具備良好的可擴展性、伸縮性和容錯性。這極大地提高了企業IT的靈活性，緩解了IT跟不上業務發展需求的矛盾，幫助企業快速應對業務需求，提高企業業務能力。

精彩問答

QQ羣 | KVM虛擬化1羣

Q1. 雲計算彈性與靈活，更多在應用業務的彈性與靈活、快速上線，然而須要龐大的基礎設施支撐、同時須要虛擬化、容器技術支撐，若沒有這些技術雲計算很難作到彈性、靈活，請問在銀行業務，銀行更可能是的使用 小機 Powervm 雲計算該如何去作呢？

A1. 目前 DCOS 還不支持小型機。雲計算的趨勢是x86化。

Q2. 雲計算解決了應用業務快速上線，彈性與靈活，基礎環境的靈活彈性。我的認爲雲計算須要龐大的基礎設施（Datacenter）環境及高效的設施，基礎環境設施很重要。

A2. 的確是很重要。並且數據中心基礎設施複雜度很高，不該該每一個公司都搞一遍。數據中心必需要有很大規模，才能下降邊際成本。

QQ羣 | KVM虛擬化2羣

Q1. 請問，銀行如何轉型新型IT模式呢，雲計算將如何在銀行領域進行落地呢？我的以爲 IT 市場仍是在銀行領域，1. 銀行有錢 2. IT服務銀行用的最多，最普遍。

A1. 雲計算將幫助金融類客戶減輕IT系統的複雜度，讓客戶的業務應用更輕量、有彈性，靈活應對複雜多變的業務需求。下一代企業級IT確定是要往輕量化方向發展，注重應用的彈性。
金融機構對IT服務有需求，並且有付費意願

Q2. 企業如何去構架一個真正的雲計算數據中心呢？構架成什麼樣才能達到雲計算特性呢？

A2. 雲計算最根本的特性是彈性。雲計算的彈性包括三層：
IaaS 提供資源彈性，PaaS 提供應用彈性，SaaS 提供服務彈性。
包含這三層彈性纔是完整的雲計算彈性。

Q3. 真正的要將雲計算進行落地，從技術角度該如何作呢？要遵循什麼樣的機制去構建雲計算數據中心，或者說怎樣能達到雲計算、靈活、彈性。須要用那些技術作構建呢？

A3. 其實主要是 IaaS 相關技術和 PaaS 相關技術。
IaaS 領域主要的技術就是虛擬化技術，包括虛擬主機、SDN、軟件定義存儲等。
PaaS 領域的技術相對不夠成熟，目前 PaaS 領域最流行的技術就是 Docker，還有對 Docker 管理調度的技術，好比 Mesos、K8s、Swarm 等，以及 Docke r網絡和存儲管理的技術，好比Calico 和 Flocker。

微信羣 | 雲實名技術

Q1. DCOS 是否是在 Docker 之上還作了管理？

A1. 是的，DCOS目前用Mesos管理Docker

Q2. 微服務應該是對一個傳統的應用進行拆分吧？

A2. 確定要拆分。微服務的拆分不只是業務應用實現層面拆分，對開發團隊的組織也要拆分紅小團隊。微服務的拆分不是按照開發職責拆（不是按前端開發、後段開發來拆），而是按照業務職責拆

Q3. 能具體描述下 Mesos 的功能嗎？Mesos 和 Marathon 是否均可以管理 Docker，其差異在哪裏？

A3. Mesos 主要是用於資源管理，Mesos 不直接管理 Docker。Marathon 是基於 Mesos 作任務調度，Marathon 支持管理調度 Docker 任務。

Q4. 咱們如今用 Kubernetes，可是實踐中，碰到了太多問題，想換 Swarm，有什麼好的建議嗎，若是用 Mesos 呢？

A4. K8s 和 Swarm 都比較新，尚未通過很大規模生產系統驗證。Mesos 相對成熟一些，Twitter 用 Mesos 管理上萬臺物理服務器。這些開源技術在易用性方面都有缺陷，畢竟只是技術不是產品。

微信羣 | 《運維前線》

Q1. Docker 如何解決網絡流量隔離的問題？

A1. Docker 目前在網絡方面還很弱，目前沒有很是成熟的方案，Calico 是咱們目前在嘗試的方案

Q2. 把全部的服務拆成微服務以後是否是會給整個系統帶來複雜性？這個微應該微到什麼程度？

A2. 的確微服務會提升系統複雜度，因此微服務很是須要PaaS來簡化系統複雜度。
微服務該多微小，這個沒有通常性標準，要按照業務來定。通常來說，一個微服務最好實現一個單一功能。

Q3. 誰構建，誰運行，那微服務團隊內部懂各類技術的人員都須要存在了，懂開發語言的，懂平臺軟件的，懂運維的，人員的成本是否也上去了呢？

A3. PaaS平臺的做用就是下降開發人員的開發難度，減輕運維工做複雜度。有了PaaS平臺以後，懂平臺軟件的人能夠減小，運維的工做變輕，開發人員能夠專一業務開發而無需考慮不少底層細節。

Q4. 沒有開發能力的運維能上不？

A4. 能夠，運維原本就不要很強的開發能力。PaaS平臺就是要下降運維複雜度。Immutable Infrastructure會極大減輕運維的工做複雜度。

Q5. 單單靠一個paas平臺實現太多，勢必會形成另外的一個極端。

A5. 是的。因此PaaS平臺自己也要輕量化。上一代PaaS沒有流行起來就是由於不夠輕量，不夠靈活。雲計算時代，企業客戶都偏向輕量化的平臺和應用。

Q6. 數人云在docker領域主要作了哪些改進，提供哪些特點功能或者服務？

A6. 數人云對Docker自己沒有什麼改動，就是標準的Docker開源版本。數人云的主要工做在對於Docker的管理調度方面，包括服務發現、負載均衡、灰度發佈、彈性伸縮等等。