2015InfoQ軟件大會技術記錄

1. 前述

參加infoq軟件大會，最大的感觸就是，互聯網行業的技術發展突飛猛進；由市場痛點、用戶痛點、開發痛點所驅動的技術變革更是遍地開花、新的技術新的思惟也是層出不窮；大會中頻頻提到的高擴展高可用架構、新興前端(React.js、Flux、GraphQL、Relay、Immutability、Webpack、Babel)、大數據處理(Spark、Hadoop、kafka、Storm、ELK(ElasticSearch\Logstash\Kibana))、雲計算(SaaS、PaaS、IaaS、Openstack)、容器應用（Docker、Mesos、Marathon、kubernetes）等各類技術，都表明了當今互聯網行業的發展趨勢。經過下面幾部分，對各技術點作下梳理。

1. 系統優化篇

環境驅動技術，隨着互聯網行業的發展、業務增加、流量增加是不可避免的；當這種量爆發必定程度，系統的瓶頸突出、系統優化隨之產生。

能夠藉助商用Jprofiler、YourKit、大衆點評開源CAT及淘寶開源TProfiler等性能監控工具來分析代碼層的運行情況，獲得對象建立排行和Java代碼執行次數、執行時間排行、執行Url路由、內存使用、cpu消耗等性能指標；從而作出具備針對性的優化。

以淘寶爲案例，系統優化大體分三個層面：

1. 系統代碼層面的優化
1. 壓縮模板大小

若是能大幅減少模板和HTML的大小，會給吞吐量帶來很大提高。最簡單的減少模板的方法，就是刪除空行和多餘空格、長url壓縮、url別名；重複渲染的數據能夠經過前端代碼去作，這種業務去重也能帶來很好的優化；

1. 模板引擎優化

Velocity模板渲染是最大的模塊瓶頸，velocity是解釋型語言、執行中還有大量反射，性能較差；淘寶基於velocity開發了語法兼容的sketch框架，將Velocity模板編譯成Java類執行，減小了反射調用，內部用字節存儲頁面，節約了從渲染到輸出的兩次編碼轉換。

1. class.forname熱點

在大併發時，class.forname會致使線程block；能夠增長cache代替class.forname。

1. 其餘

1）可以預處理的決不動態生成；

2）儘可能使用簡單類型做爲HashMap的key；

3）Web.xml配置版本信息減小啓動時annotation的掃描時間；

4）Logger建立沒有使用static修飾致使線程阻塞；

5）少用Thread.getStackTrace()；

6）正則運算儘可能cache；

7）Java代碼裏，private修飾符比不修飾或其餘修飾要更快；

8）不可變常量定義加final修飾；

9）StringBuilder代替字符串「+」拼接；

10）優化自定義hasCode()方法和equals()方法；

11）使用原始類型和棧；

1. 架構優化
1. 數據的動靜分離

系統的靜態化是讀系統性能優化的終極必殺器；

靜態化的幾個原則：

1）讓用戶的請求儘可能少的通過java應用服務器；

2）讓靜態數據放在離用戶最近的地方；

3）讓動態數據儘量的小；

上圖爲淘寶優化後的架構圖，圖中能夠看出不管是pc端仍是無線端先請求的都是離用戶最近的CDN，經過CDN拿到請求頁的靜態頁面及資源，數據的動態部分經過客戶端發送請求到服務器，服務器先通過統一Cache過濾掉部分的緩存動態數據，剩餘的動態數據則經過下層的動態系統去獲取；通過這一動態分離，真正到達應用服務器的動態數據流量已經很小了。

經過上述的動靜分離，像商品的詳情這一功能，可天天支持30+億的PV，峯值100w+的QPS；

1. 讀寫的分層校驗

看上圖這個「雙十一」經常使用的秒殺搶購頁面，整個頁面是cache用戶瀏覽器，若是強制刷新整個頁面，也會請求道CDN，而實際有效的動態請求也只是「刷新搶寶」按鈕；

當到了搶購時間，不是當即點擊「秒殺」，而是有一個驗證碼的輸入方式，如上圖所示；這樣作的好處是，既能夠防止「自動秒殺器」又能夠避免瞬間的併發請求流量峯值。

讀寫數據的分層校驗原則：

1）先作數據的動靜分離；

2）將99%的數據緩存在客戶端；

3）將動態請求的讀數據cache在web端；

4）對讀數據不作強一致校驗；

5）對寫數據進行基於時間的合理分片；

6）對寫請求作限流保護；

7）對寫數據進行強一致校驗；

8）先加載主要數據，後異步加載次要數據；

1. 基礎設施優化

1）用戶訪問鏈路

經過分析訪問鏈路請求響應時間，優化縮短中間的管道處理過程；

如pc端最重要的是優化首屏的加載；

而無線端更多的是優化中間的處理管道，因爲無線端的網絡、硬件複雜性在同等條件下比pc端要慢不少；可將無線端的屢次請求合併一個請求，可控制無線端的數據量大小；

經過CDN和統一Cache再輔助一些動態加速技術，提高用戶訪問鏈路的響應；

2）域名的收斂

3）DNS本地cache；

4）SPDY長連；

5）圖片本地cache；

6）合理的預加載機制；

7）使用更快的網絡傳輸通道如光纖、更優化的網絡拓撲結構；

8）其餘的如，軟件的升級、JVM的調優、二方包優化、硬件設施如cpu、內存的升級等；

1. 系統架構篇
1. 淘寶前期技術

隨着公司的發展、業務的暴增，之前認爲很好的架構已成爲拖累業務發展的絆腳石；如何設計出高可用、高穩定、高擴展的系統架構來適應環境的需求呢？仍是以淘寶技術做爲入口來探討下：

上圖爲淘寶早期的技術架構，在當時的環境來講，這個架構也挺好的，分應用、分緩存、分數據庫來支撐業務的發展；隨着業務量指數級的增加，不管是數據仍是業務系統都在以前的基礎上翻倍；從而也暴露出一些瓶頸問題。

1. 瓶頸問題

1）業務系統的數量增加很快，項目團隊協同代價很高；人員更新快、源代碼膨脹；

2）數據孤島；數據庫常常被不明sql查掛，同類數據格式不統一；

3）數據庫能力達到上限，cpu90%以上，鏈接數不夠用；

4）維護人員多，數據沒法共享，數據庫壓力過大，單點系統風險增長；

1. 淘寶3.0

面對上述問題，淘寶做出了技術變革，退出了淘寶3.0，架構圖以下：

上圖能夠看出，淘寶所作的一些改變：

1. 服務化(SOA)

將系統進行專業化分工，組建像用戶中心、交易中心、評價中心這類服務模塊；

系統由服務單元組成、數據共享、服務能力開放；

這一改進使業務支撐更敏捷、無數據孤島、有利於數據分析和挖掘；

1. 去中心化

如上圖，整個系統及數據庫無單點、系統中全部角色皆可單獨擴縮、故障影響小；

這一改進使應用更穩定、擴展性更好；

1. 異步化、最終一致

經過消息中間件使流程異步化、去鎖、並行，並保證流程最終的一致性；

這一改進使得系統解耦、下降延遲；

組織結構支持，經過服務中心團隊、中間件團隊、垂直產品團隊來維護整個架構；

下圖是淘寶所用的一些開源或自研的軟件：

其中像dubbo是阿里開源的分佈式服務框架，支持多種rpc協議，噹噹網在其基礎上推出dubbox作了不少功能擴展像rest支持等。

1. 新興前端篇
1. React.js

React到底是什麼？Facebook把它簡單低調地定義成一個「用來構建UI的JavaScript庫」。可是React所基於的幾個核心概念使它與那些傳統的js庫迥然不一樣。React的一些設計原則:

1） 組件和基於組件的設計流程；

2） 單向數據流動；

3） 虛擬DOM取代物理DOM做爲操做對象；

4） 用JSX語法取代HTML模板，在JavaScript裏聲明式地描述UI。

這幾條簡單的原則放在一塊兒帶來了大量的好處：

1） 前端和後端都可以從React組件渲染頁面，徹底解決了SEO長期困擾JavaScript單頁應用的問題；

2） 咱們能夠簡單直接地寫前端測試而徹底忘掉DOM依賴；

3） 組件的封裝方式和單向數據流動可以極大地簡化前端架構的理解難度。

下圖爲一個簡單的React例子

這段代碼發生在服務器端！是的，一樣的 HelloMessage，咱們不只可讓React在前端渲染到頁面，一樣能夠在後端直接渲染成HTML字符串，而後把它返回給前端。

1. React Native

React Native是能夠替代H5在Android、IOS上開發跨平臺應用的解決方案；再加上React web，能夠實現一套React跨pc端、無線端，真正實現一次開發多處運行。這也是React一經推出，得到業界普遍關注的緣由。

1. Flux

React定義本身爲MVC中的View；對於M和C，Facebook提出了Flux的概念。Flux是一個專門爲React設計的應用程序架構：應用程序由Dispatcher、Store和View組成。Flux的核心是以下圖所示的單向數據流動。

應用程序中的任何一次數據變化都做爲Action發起，通過Dispatcher分發出去，被相關的Store接收到並整合，而後做爲props和state提供給View（React組件）。當用戶在View上作了任何與數據相關的交互，View會發起新的Action，開啓一次新的數據變化週期。這種單向性使Flux在高層次上比傳統MVC架構和以Angular和Knockout爲表明的雙向數據綁定容易理解得多，大大簡化了開發者的思考和Debug過程。

1. GraphQL

如今主流的調用服務方式是RESTful API，然而在實踐中，咱們發現RESTful在一些真實生產環境的需求下不是很適用。每每咱們須要構建自定義endpoint，而這違背了RESTful的設計理念。舉個例子，咱們想要顯示論壇帖子、做者和對應的留言。分別要發出三個不一樣的請求。第二個請求依賴第一個請求結果返回的user_id，前端須要寫代碼協調請求之間的依賴。分別發出三個不一樣請求在移動端這種網絡不穩定的環境下效果很不理想。

來自Facebook的GraphQL是目前最接近完美的解決方法。後端工程師只須要定義能夠被查詢的Type System，前端工程師就可使用GraphQL自定義查詢。GraphQL查詢語句只須要形容須要返回的數據形狀，GraphQL服務器就會返回正確的JSON格式。

1. Relay

Relay是Facebook提出的在React上應用GraphQL的方案。React的基礎單位是組件（Component），構建大型應用就是組合和嵌套組件。以組件爲單位的設計模式是目前社區裏最承認的，這也是前端世界的趨勢之一。每一個組件須要的數據也應該在組件內部定義。Relay讓組件能夠自定義其所須要GraphQL數據格式，在組件實例化的時候再去GraphQL服務器獲取數據。Relay也會自動構建嵌套組件的GraphQL查詢，這樣多個嵌套的組件只須要發一次請求。

1. Immutability

React社區接受了不少函數式編程的想法，其中受Clojure影響很深。對Immutable數據的使用就是來自Clojure社區。當年Om，這個用ClojureScript寫的React wrapper在速度上竟然完虐原生JavaScript版本的React。這讓整個社區都震驚了。其中一個緣由就是ClojureScript使用了Immutable數據。React社區裏也冒出了Immutable.js，這讓JavaScript裏也能使用Immutable數據，完美彌補了JavaScript在負責數據對象比較的先天性不足。Immutable.js也成爲了構建大型React應用的必備。甚至有在討論是否把Immutable.js直接歸入JavaScript語言中。咱們認爲小型應用不會遇到虛擬DOM的性能瓶頸，引入Immutable.js只會讓數據操做很累贅。

1. Webpack

在React裏，因爲須要用到JSX，使用Webpack或Browserify這類工具編譯代碼已經漸漸成爲前端工程師工做流程的一部分。Webpack是一款強大的前端模塊管理和打包工具。

1. Babel

ECMAScript 6（ES6）規範在今年四月剛敲定，React社區基本全面擁抱ES6。但目前還有不少瀏覽器不支持ES6。使用像Webpack這樣的工具編譯代碼使得咱們能夠在開發時使用ES6（或者更新版本），在上線前編譯成ES5。編譯工具中最引人注意的是Babel。前身爲ES6to5，Babel是目前社區最火的ES6編譯到ES5的代碼工具。

1. 大數據處理篇
1. Hadoop

Hadoop是Appach的一個用java語言實現開源軟件框架，實如今大量計算機組成的集羣中對海量數據進行分佈式計算。Hadoop框架中最核心設計就是：HDFS和MapReduce.HDFS提供了海量數據的存儲,MapReduce提供了對數據的計算。

Hadoop的集羣主要由 NameNode,DataNode,Secondary NameNode,JobTracker,TaskTracker組成.以下圖所示:

Hadoop的侷限和不足

1）抽象層次低，須要手工編寫代碼來完成，使用上難以上手。

2）只提供兩個操做，Map和Reduce，表達力欠缺。

3）一個Job只有Map和Reduce兩個階段（Phase），複雜的計算須要大量的Job完成，Job之間的依賴關係是由開發者本身管理的；

4）處理邏輯隱藏在代碼細節中，沒有總體邏輯；

5）中間結果也放在HDFS文件系統中；

6）ReduceTask須要等待全部MapTask都完成後才能夠開始；

7）時延高，只適用Batch數據處理，對於交互式數據處理，實時數據處理的支持不夠；

8）對於迭代式數據處理性能比較差；

1. Spark

針對上述hadoop的缺陷，推出了Spark。

1） Spark 是一種與 Hadoop 類似的開源集羣計算環境，可是二者之間還存在一些不一樣之處，這些有用的不一樣之處使 Spark 在某些工做負載方面表現得更加優越，換句話說，Spark 啓用了內存分佈數據集，除了可以提供交互式查詢外，它還能夠優化迭代工做負載。

2）Hadoop/MapReduce和Spark最適合的都是作離線型的數據分析，但Hadoop特別適合是單次分析的數據量「很大」的情景，而Spark則適用於數據量不是很大的情景。這兒所說的「很大」，是相對於整個集羣中的內存容量而言的，由於Spark是須要將數據HOLD在內存中的。通常的，1TB如下的數據量都不能算很大，而10TB以上的數據量都是算「很大」的。好比說，20個節點的一個集羣（這樣的集羣規模在大數據領域算是很小的了），每一個節點64GB內存（不算很小，但也不能算大），共計1.28TB。讓這樣規模的一個集羣把500GB左右的數據HOLD在內存中仍是很輕鬆的。這時候，用Spark的執行速度都會比Hadoop快，畢竟在MapReduce過程當中，諸如spill等這些操做都是須要寫磁盤的。

1. Storm
1. Storm是由BackType開發的實時處理系統，是一個分佈式的、容錯的實時計算系統；
2. 由Twitter開源。

3）在Storm中，先要設計一個用於實時計算的圖狀結構，咱們稱之爲拓撲（topology）。這個拓撲將會被提交給集羣，由集羣中的主控節點（master node）分發代碼，將任務分配給工做節點（worker node）執行。一個拓撲中包括spout和bolt兩種角色，其中spout發送消息，負責將數據流以tuple元組的形式發送出去；而bolt則負責轉換這些數據流，在bolt中能夠完成計算、過濾等操做，bolt自身也能夠隨機將數據發送給其餘bolt。由spout發射出的tuple是不可變數組，對應着固定的鍵值對。

1. Kafka

Kafka是由LinkedIn開發的一個分佈式的消息系統，使用Scala編寫，它以可水平擴展和高吞吐率而被普遍使用。目前愈來愈多的開源分佈式處理系統如Cloudera、Apache Storm、Spark都支持與Kafka集成.

Kafka主要設計目標以下：

1）以時間複雜度爲O(1)的方式提供消息持久化能力，即便對TB級以上數據也能保證常數時間複雜度的訪問性能。

2）高吞吐率。即便在很是廉價的商用機器上也能作到單機支持每秒100K條以上消息的傳輸。

3）支持Kafka Server間的消息分區，及分佈式消費，同時保證每一個Partition內的消息順序傳輸。

4）同時支持離線數據處理和實時數據處理。

5）Scale out：支持在線水平擴展。

如上圖所示，一個典型的Kafka集羣中包含若干Producer（能夠是web前端產生的Page View，或者是服務器日誌，系統CPU、Memory等），若干broker（Kafka支持水平擴展，通常broker數量越多，集羣吞吐率越高），若干Consumer Group，以及一個Zookeeper集羣。Kafka經過Zookeeper管理集羣配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Producer使用push模式將消息發佈到broker，Consumer使用pull模式從broker訂閱並消費消息.

1. ELKstack

ELKstack 是 Elasticsearch、Logstash、Kibana 三個開源軟件的組合。在實時數據檢索和分析場合，三者一般是配合共用，並且又都前後歸於 Elastic.co 公司名下，故有此簡稱。

ELKstack 具備以下幾個優勢：

1）處理方式靈活。Elasticsearch 是實時全文索引，不須要像 storm 那樣預先編程才能使用；

配置簡易上手。Elasticsearch 所有采用 JSON 接口，Logstash 是 Ruby DSL 設計，都是目前業界最通用的配置語法設計；

2）檢索性能高效。雖然每次查詢都是實時計算，可是優秀的設計和實現基本能夠達到百億級數據查詢的秒級響應；

3）集羣線性擴展。無論是 Elasticsearch 集羣仍是 Logstash 集羣都是能夠線性擴展的；

前端操做炫麗。Kibana 界面上，只須要點擊鼠標，就能夠完成搜索、聚合功能，生成炫麗的儀表板。

1. 容器與雲計算篇
1. 雲計算：IaaS，PaaS和SaaS

1. IaaS: Infrastructure-as-a-Service（基礎設施即服務）

第一層叫作IaaS，有時候也叫作Hardware-as-a-Service，幾年前若是你想在辦公室或者公司的網站上運行一些企業應用，你須要去買服務器，或者別的高昂的硬件來控制本地應用，讓你的業務運行起來。

可是如今有IaaS，你能夠將硬件外包到別的地方去。IaaS公司會提供場外服務器，存儲和網絡硬件，你能夠租用。節省了維護成本和辦公場地，公司能夠在任什麼時候候利用這些硬件來運行其應用。

一些大的IaaS公司包括Amazon, Microsoft, VMWare, Rackspace和Red Hat.不過這些公司又都有本身的專長，好比Amazon和微軟給你提供的不僅是IaaS，他們還會將其計算能力出租給你來host你的網站。

1. PaaS: Platform-as-a-Service（平臺即服務）

第二層就是所謂的PaaS，某些時候也叫作中間件。你公司全部的開發均可以在這一層進行，節省了時間和資源。

PaaS公司在網上提供各類開發和分發應用的解決方案，好比虛擬服務器和操做系統。這節省了你在硬件上的費用，也讓分散的工做室之間的合做變得更加容易。網頁應用管理，應用設計，應用虛擬主機，存儲，安全以及應用開發協做工具等。

一些大的PaaS提供者有Google App Engine,Microsoft Azure，Force.com,Heroku，Engine Yard。最近興起的公司有AppFog, Mendix 和 Standing Cloud；

1. SaaS: Software-as-a-Service（軟件即服務）

第三層也就是所謂SaaS。這一層是和你的生活天天接觸的一層，大可能是經過網頁瀏覽器來接入。任何一個遠程服務器上的應用均可以經過網絡來運行，就是SaaS了。

你消費的服務徹底是從網頁如Netflix, MOG, Google Apps, Box.net, Dropbox或者蘋果的iCloud那裏進入這些分類。儘管這些網頁服務是用做商務和娛樂或者二者都有，但這也算是雲技術的一部分。

一些用做商務的SaaS應用包括Citrix的GoToMeeting，Cisco的WebEx，Salesforce的CRM，ADP，Workday和SuccessFactors。

在當今雲計算環境當中，IaaS是很是主流的，不管是Amazon EC2仍是Linode或者Joyent等，都佔有一席之地，可是隨着Google的App Engine，Salesforce的Force.com仍是微軟的Windows Azure等PaaS平臺的推出，使得PaaS也開始嶄露頭角。由於PaaS模式的高整合率所帶來經濟型使得若是PaaS能解決諸如通用性和支持的應用等方面的挑戰，它將會替代IaaS成爲開發者的「新寵」。

1. Docker

Docker 是 PaaS 提供商 dotCloud 開源的一個基於 LXC 的高級容器引擎，源代碼託管在 Github 上, 基於go語言並聽從Apache2.0協議開源。Docker自2013年推出以來很是火熱，受到業界的普遍關注。Docker container和普通的虛擬機Image相比, 最大的區別是它並不包含操做系統內核.

1. Docker特色：

1. Docker核心技術：

1）隔離性: Linux Namespace(ns)

每一個用戶實例之間相互隔離, 互不影響。 通常的硬件虛擬化方法給出的方法是VM，而LXC給出的方法是container，更細一點講就是kernel namespace。其中pid、net、ipc、mnt、uts、user等namespace將container的進程、網絡、消息、文件系統、UTS("UNIX Time-sharing System")和用戶空間隔離開。

2）可配額/可度量

Control Groups (cgroups)cgroups 實現了對資源的配額和度量。 cgroups 的使用很是簡單，提供相似文件的接口，在 /cgroup目錄下新建一個文件夾便可新建一個group，在此文件夾中新建task文件，並將pid寫入該文件，便可實現對該進程的資源控制。groups能夠限制blkio、cpu、cpuacct、cpuset、devices、freezer、memory、net_cls、ns九大子系統的資源，如下是每一個子系統的詳細說明：

a、blkio 這個子系統設置限制每一個塊設備的輸入輸出控制。例如:磁盤，光盤以及usb等等。

b、cpu 這個子系統使用調度程序爲cgroup任務提供cpu的訪問。

c、cpuacct 產生cgroup任務的cpu資源報告。

d、cpuset 若是是多核心的cpu，這個子系統會爲cgroup任務分配單獨的cpu和內存。devices 容許或拒絕cgroup任務對設備的訪問。

e、freezer 暫停和恢復cgroup任務。

f、memory 設置每一個cgroup的內存限制以及產生內存資源報告。

g、net_cls 標記每一個網絡包以供cgroup方便使用。

h、ns 名稱空間子系統。

3）便攜性: AUFS

AUFS (AnotherUnionFS) 是一種 Union FS, 簡單來講就是支持將不一樣目錄掛載到同一個虛擬文件系統下(unite several directories into a single virtual filesystem)的文件系統, 更進一步的理解, AUFS支持爲每個成員目錄(相似Git Branch)設定readonly、readwrite 和 whiteout-able 權限, 同時 AUFS 裏有一個相似分層的概念, 對 readonly 權限的 branch 能夠邏輯上進行修改(增量地, 不影響 readonly 部分的)。

一般 Union FS 有兩個用途, 一方面能夠實現不借助 LVM、RAID 將多個disk掛到同一個目錄下, 另外一個更經常使用的就是將一個 readonly 的 branch 和一個 writeable 的 branch 聯合在一塊兒，Live CD正是基於此方法能夠容許在 OS image 不變的基礎上容許用戶在其上進行一些寫操做。Docker 在 AUFS 上構建的 container image 也正是如此，接下來咱們從啓動 container 中的 linux 爲例來介紹 docker 對AUFS特性的運用。

典型的啓動Linux運行須要兩個FS: bootfs + rootfs:

bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引導加載kernel, 當boot成功後 kernel 被加載到內存中後 bootfs就被umount了. rootfs (root file system) 包含的就是典型 Linux 系統中的 /dev, /proc,/bin, /etc 等標準目錄和文件。

對於不一樣的linux發行版, bootfs基本是一致的, 但rootfs會有差異, 所以不一樣的發行版能夠公用bootfs 以下圖:

典型的Linux在啓動後，首先將 rootfs 設置爲 readonly, 進行一系列檢查, 而後將其切換爲 "readwrite" 供用戶使用。在Docker中，初始化時也是將 rootfs 以readonly方式加載並檢查，然而接下來利用 union mount 的方式將一個 readwrite 文件系統掛載在 readonly 的rootfs之上，而且容許再次將下層的 FS(file system) 設定爲readonly 而且向上疊加, 這樣一組readonly和一個writeable的結構構成一個container的運行時態, 每個FS被稱做一個FS層。以下圖:

得益於AUFS的特性, 每個對readonly層文件/目錄的修改都只會存在於上層的writeable層中。這樣因爲不存在競爭, 多個container能夠共享readonly的FS層。 因此Docker將readonly的FS層稱做 "image" - 對於container而言整個rootfs都是read-write的，但事實上全部的修改都寫入最上層的writeable層中, image不保存用戶狀態，只用於模板、新建和複製使用。

上層的image依賴下層的image，所以Docker中把下層的image稱做父image，沒有父image的image稱做base image。所以想要從一個image啓動一個container，Docker會先加載這個image和依賴的父images以及base image，用戶的進程運行在writeable的layer中。全部parent image中的數據信息以及 ID、網絡和lxc管理的資源限制等具體container的配置，構成一個Docker概念上的container。以下圖:

4）安全性: AppArmor, SELinux, GRSEC

安全永遠是相對的，這裏有三個方面能夠考慮Docker的安全特性:

由kernel namespaces和cgroups實現的Linux系統固有的安全標準;

Docker Deamon的安全接口;

Linux自己的安全加固解決方案,類如AppArmor, SELinux;

1. Mesos

1）Mesos計算框架一個集羣管理器，提供了有效的、跨分佈式應用或框架的資源隔離和共享，能夠運行Hadoop、MPI、Hypertable、Spark。使用ZooKeeper實現容錯複製，使用Linux Containers來隔離任務，支持多種資源計劃分配。

2）Mesos是如何讓Twitter和Airbnb這樣的公司，經過數據中心資源更高效的管理系統，擴展應用的呢？從一個至關簡單但很優雅的兩級調度架構開始提及。

上圖修改自Apache Mesos網站上的圖片，如圖所示，Mesos實現了兩級調度架構，它能夠管理多種類型的應用程序。第一級調度是Master的守護進程，管理Mesos 集羣中全部節點上運行的Slave守護進程。集羣由物理服務器或虛擬服務器組成，用於運行應用程序的任務，好比Hadoop和MPI做業。第二級調度由被 稱做Framework的「組件」組成。Framework包括調度器（Scheduler）和執行器（Executor）進程，其中每一個節點上都會運行 執行器。Mesos能和不一樣類型的Framework通訊，每種Framework由相應的應用集羣管理。上圖中只展現了Hadoop和MPI兩種類型， 其它類型的應用程序也有相應的Framework。

Mesos Master協調所有的Slave，並肯定每一個節點的可用資源，

聚合計算跨節點的全部可用資源的報告，而後向註冊到Master的Framework（做爲Master的客戶端）發出資源邀約。Framework能夠 根據應用程序的需求，選擇接受或拒絕來自master的資源邀約。一旦接受邀約，Master即協調Framework和Slave，調度參與節點上任 務，並在容器中執行，以使多種類型的任務，好比Hadoop和Cassandra，能夠在同一個節點上同時運行。

1. Marathon

Marathon是一個mesos框架，可以支持運行長服務，好比web應用等。是集羣的分佈式Init.d，可以原樣運行任何Linux二進制發佈版本，如Tomcat Play等等，能夠集羣的多進程管理。也是一種私有的Pass，實現服務的發現，爲部署提供提供REST API服務，有受權和SSL、配置約束，經過HAProxy實現服務發現和負載平衡。

這樣，咱們能夠如同一臺Linux主機同樣管理數千臺服務器，它們的對應原理以下圖，使用Marathon相似Linux主機內的init Systemd等外殼管理，而Mesos則不僅包含一個Linux核，能夠調度數千臺服務器的Linux核，實際是一個數據中心的內核：

1. Kubernetes

Kubernetes是Google開源的容器集羣管理系統，其提供應用部署、維護、 擴展機制等功能，利用Kubernetes能方便地管理跨機器運行容器化的應用，其主要功能以下:

1) 使用Docker對應用程序包裝(package)、實例化(instantiate)、運行(run)。

2) 以集羣的方式運行、管理跨機器的容器。

3) 解決Docker跨機器容器之間的通信問題。

4) Kubernetes的自我修復機制使得容器集羣老是運行在用戶指望的狀態。

當前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平臺，除此以外，也能夠直接運行在物理機上。

Kubernetes主要概念：

1) Pods

Pod是Kubernetes的基本操做單元，把相關的一個或多個容器構成一個Pod，一般Pod裏的容器運行相同的應用。Pod包含的容器運行在同一個Minion(Host)上，看做一個統一管理單元，共享相同的volumes和network namespace/IP和Port空間。

2) Services

Services也是Kubernetes的基本操做單元，是真實應用服務的抽象，每個服務後面都有不少對應的容器來支持，經過Proxy的port和服務selector決定服務請求傳遞給後端提供服務的容器，對外表現爲一個單一訪問接口，外部不須要了解後端如何運行，這給擴展或維護後端帶來很大的好處。

3) Replication Controllers

Replication Controller確保任什麼時候候Kubernetes集羣中有指定數量的pod副本(replicas)在運行， 若是少於指定數量的pod副本(replicas)，Replication Controller會啓動新的Container，反之會殺死多餘的以保證數量不變。Replication Controller使用預先定義的pod模板建立pods，一旦建立成功，pod 模板和建立的pods沒有任何關聯，能夠修改pod 模板而不會對已建立pods有任何影響，也能夠直接更新經過Replication Controller建立的pods。對於利用pod 模板建立的pods，Replication Controller根據label selector來關聯，經過修改pods的label能夠刪除對應的pods。

4) Labels

Labels是用於區分Pod、Service、Replication Controller的key/value鍵值對，Pod、Service、 Replication Controller能夠有多個label，可是每一個label的key只能對應一個value。Labels是Service和Replication Controller運行的基礎，爲了將訪問Service的請求轉發給後端提供服務的多個容器，正是經過標識容器的labels來選擇正確的容器。一樣，Replication Controller也使用labels來管理經過pod 模板建立的一組容器，這樣Replication Controller能夠更加容易，方便地管理多個容器，不管有多少容器。

Kubernetes總體框架圖以下，主要包括kubecfg、Master API Server、Kubelet、Minion(Host)以及Proxy；

1. 總結

經過此次大會的交流學習，不能說掌握了多少專業的細節知識，但絕對是眼界開闊了些；瞭解了業界軟件發展的技術動態，知道了行業公司在軟件開發流程中遇到的問題及解決方案。在面對突飛猛進的技術發展，我認爲有幾個原則須要堅守下：

1. 及時瞭解新的技術動態和行業的發展方向；
2. 重視開源技術的發展，幾乎影響力很大的技術都來源於開源社區；
3. 架構設計，應已簡單實用爲目標，環境需求爲根本；不要盲從高大上的系統；
4. 勇於引進新的技術，沒有最穩定的系統只有不斷改進的系統；