- 前述
參加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）等各種技術，都代表了當今網際網路行業的發展趨勢。通過下面幾部分，對各技術點做下梳理。
- 系統優化篇
環境驅動技術，隨著網際網路行業的發展、業務增長、流量增長是不可避免的；當這種量爆發一定程度，系統的瓶頸突出、系統優化隨之產生。
可以藉助商用Jprofiler、YourKit、大眾點評開源CAT及淘寶開源TProfiler等效能監控工具來分析程式碼層的執行狀況，得到物件建立排行和Java程式碼執行次數、執行時間排行、執行Url路由、記憶體使用、cpu消耗等效能指標；從而做出具有針對性的優化。
以淘寶為案例，系統優化大致分三個層面：
- 系統程式碼層面的優化
- 壓縮模板大小
如果能大幅減小模板和HTML的大小，會給吞吐量帶來很大提升。最簡單的減小模板的方法，就是刪除空行和多餘空格、長url壓縮、url別名；重複渲染的資料可以通過前端程式碼去做，這種業務去重也能帶來很好的優化；
- 模板引擎優化
Velocity模板渲染是最大的模組瓶頸，velocity是解釋型語言、執行中還有大量反射，效能較差；淘寶基於velocity開發了語法相容的sketch框架，將Velocity模板編譯成Java類執行，減少了反射呼叫，內部用位元組儲存頁面，節約了從渲染到輸出的兩次編碼轉換。
- class.forname熱點
在大併發時，class.forname會導致執行緒block；可以增加cache代替class.forname。
- 其他
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）讓使用者的請求儘量少的經過java應用伺服器；
2）讓靜態資料放在離使用者最近的地方；
3）讓動態資料儘可能的小；
上圖為淘寶優化後的架構圖，圖中可以看出無論是pc端還是無線端先請求的都是離使用者最近的CDN，通過CDN拿到請求頁的靜態頁面及資源，資料的動態部分通過客戶端傳送請求到伺服器，伺服器先經過統一Cache過濾掉部分的快取動態資料，剩餘的動態資料則通過下層的動態系統去獲取；經過這一動態分離，真正到達應用伺服器的動態資料流量已經很小了。
通過上述的動靜分離，像商品的詳情這一功能，可每天支援30+億的PV，峰值100w+的QPS；
- 讀寫的分層校驗
看上圖這個“雙十一”常用的秒殺搶購頁面，整個頁面是cache使用者瀏覽器，如果強制重新整理整個頁面，也會請求道CDN，而實際有效的動態請求也只是“重新整理搶寶”按鈕；
當到了搶購時間，不是立即點選“秒殺”，而是有一個驗證碼的輸入方式，如上圖所示；這樣做的好處是，既可以防止“自動秒殺器”又可以避免瞬間的併發請求流量峰值。
讀寫資料的分層校驗原則：
1）先做資料的動靜分離；
2）將99%的資料快取在客戶端；
3）將動態請求的讀資料cache在web端；
4）對讀資料不做強一致校驗；
5）對寫資料進行基於時間的合理分片；
6）對寫請求做限流保護；
7）對寫資料進行強一致校驗；
8）先載入主要資料，後非同步載入次要資料；
- 基礎設施優化
1）使用者訪問鏈路
通過分析訪問鏈路請求響應時間，優化縮短中間的管道處理過程；
如pc端最重要的是優化首屏的載入；
而無線端更多的是優化中間的處理管道，由於無線端的網路、硬體複雜性在同等條件下比pc端要慢很多；可將無線端的多次請求合併一個請求，可控制無線端的資料量大小；
通過CDN和統一Cache再輔助一些動態加速技術，提升使用者訪問鏈路的響應；
2）域名的收斂
3）DNS本地cache；
4）SPDY長連；
5）圖片本地cache；
6）合理的預載入機制；
7）使用更快的網路傳輸通道如光纖、更優化的網路拓撲結構；
8）其他的如，軟體的升級、JVM的調優、二方包優化、硬體設施如cpu、記憶體的升級等；
- 系統架構篇
- 淘寶前期技術
隨著公司的發展、業務的暴增，以前認為很好的架構已成為拖累業務發展的絆腳石；如何設計出高可用、高穩定、高擴充套件的系統架構來適應環境的需求呢？還是以淘寶技術作為入口來探討下：
上圖為淘寶早期的技術架構，在當時的環境來說，這個架構也挺好的，分應用、分快取、分資料庫來支撐業務的發展；隨著業務量指數級的增長，無論是資料還是業務系統都在之前的基礎上翻倍；從而也暴露出一些瓶頸問題。
- 瓶頸問題
1）業務系統的數量增長很快，專案團隊協同代價很高；人員更新快、原始碼膨脹；
2）資料孤島；資料庫經常被不明sql查掛，同類資料格式不統一；
3）資料庫能力達到上限，cpu90%以上，連線數不夠用；
4）維護人員多，資料無法共享，資料庫壓力過大，單點系統風險增加；
- 淘寶3.0
面對上述問題，淘寶作出了技術變革，退出了淘寶3.0，架構圖如下：
上圖可以看出，淘寶所做的一些改變：
- 服務化(SOA)
將系統進行專業化分工，組建像使用者中心、交易中心、評價中心這類服務模組；
系統由服務單元組成、資料共享、服務能力開放；
這一改進使業務支撐更敏捷、無資料孤島、有利於資料分析和挖掘；
- 去中心化
如上圖，整個系統及資料庫無單點、系統中所有角色皆可單獨擴縮、故障影響小；
這一改進使應用更穩定、擴充套件性更好；
- 非同步化、最終一致
通過訊息中介軟體使流程非同步化、去鎖、並行，並保證流程最終的一致性；
這一改進使得系統解耦、降低延遲；
組織結構支援，通過服務中心團隊、中介軟體團隊、垂直產品團隊來維護整個架構；
下圖是淘寶所用的一些開源或自研的軟體：
其中像dubbo是阿里開源的分散式服務框架，支援多種rpc協議，噹噹網在其基礎上推出dubbox做了很多功能擴充套件像rest支援等。
- 新興前端篇
- 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字串，然後把它返回給前端。
- React Native
React Native是可以替代H5在Android、IOS上開發跨平臺應用的解決方案；再加上React web，可以實現一套React跨pc端、無線端，真正實現一次開發多處執行。這也是React一經推出，獲得業界廣泛關注的原因。
- 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過程。
- GraphQL
現在主流的呼叫服務方式是RESTful API，然而在實踐中，我們發現RESTful在一些真實生產環境的需求下不是很適用。往往我們需要構建自定義endpoint，而這違背了RESTful的設計理念。舉個例子，我們想要顯示論壇帖子、作者和對應的留言。分別要發出三個不同的請求。第二個請求依賴第一個請求結果返回的user_id，前端需要寫程式碼協調請求之間的依賴。分別發出三個不同請求在移動端這種網路不穩定的環境下效果很不理想。
來自Facebook的GraphQL是目前最接近完美的解決方法。後端工程師只需要定義可以被查詢的Type System，前端工程師就可以使用GraphQL自定義查詢。GraphQL查詢語句只需要形容需要返回的資料形狀，GraphQL伺服器就會返回正確的JSON格式。
- Relay
Relay是Facebook提出的在React上應用GraphQL的方案。React的基礎單位是元件（Component），構建大型應用就是組合和巢狀元件。以元件為單位的設計模式是目前社群裡最認可的，這也是前端世界的趨勢之一。每個元件需要的資料也應該在元件內部定義。Relay讓元件可以自定義其所需要GraphQL資料格式，在元件例項化的時候再去GraphQL伺服器獲取資料。Relay也會自動構建巢狀元件的GraphQL查詢，這樣多個巢狀的元件只需要發一次請求。
- 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只會讓資料操作很累贅。
- Webpack
在React裡，由於需要用到JSX，使用Webpack或Browserify這類工具編譯程式碼已經漸漸成為前端工程師工作流程的一部分。Webpack是一款強大的前端模組管理和打包工具。
- Babel
ECMAScript 6（ES6）規範在今年四月剛敲定，React社群基本全面擁抱ES6。但目前還有很多瀏覽器不支援ES6。使用像Webpack這樣的工具編譯程式碼使得我們可以在開發時使用ES6（或者更新版本），在上線前編譯成ES5。編譯工具中最引人注意的是Babel。前身為ES6to5，Babel是目前社群最火的ES6編譯到ES5的程式碼工具。
- 大資料處理篇
- 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）對於迭代式資料處理效能比較差；
- 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等這些操作都是需要寫磁碟的。
- Storm
- Storm是由BackType開發的實時處理系統，是一個分散式的、容錯的實時計算系統；
- 由Twitter開源。
3）在Storm中，先要設計一個用於實時計算的圖狀結構，我們稱之為拓撲（topology）。這個拓撲將會被提交給叢集，由叢集中的主控節點（master node）分發程式碼，將任務分配給工作節點（worker node）執行。一個拓撲中包括spout和bolt兩種角色，其中spout傳送訊息，負責將資料流以tuple元組的形式傳送出去；而bolt則負責轉換這些資料流，在bolt中可以完成計算、過濾等操作，bolt自身也可以隨機將資料傳送給其他bolt。由spout發射出的tuple是不可變陣列，對應著固定的鍵值對。
- 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訂閱並消費訊息.
- ELKstack
ELKstack 是 Elasticsearch、Logstash、Kibana 三個開源軟體的組合。在實時資料檢索和分析場合，三者通常是配合共用，而且又都先後歸於 Elastic.co 公司名下，故有此簡稱。
ELKstack 具有如下幾個優點：
1）處理方式靈活。Elasticsearch 是實時全文索引，不需要像 storm 那樣預先程式設計才能使用；
配置簡易上手。Elasticsearch 全部採用 JSON 介面，Logstash 是 Ruby DSL 設計，都是目前業界最通用的配置語法設計；
2）檢索效能高效。雖然每次查詢都是實時計算，但是優秀的設計和實現基本可以達到百億級資料查詢的秒級響應；
3）叢集線性擴充套件。不管是 Elasticsearch 叢集還是 Logstash 叢集都是可以線性擴充套件的；
前端操作炫麗。Kibana 介面上，只需要點選滑鼠，就可以完成搜尋、聚合功能，生成炫麗的儀表板。
- 容器與雲端計算篇
- 雲端計算：IaaS，PaaS和SaaS
- IaaS: Infrastructure-as-a-Service（基礎設施即服務）
第一層叫做IaaS，有時候也叫做Hardware-as-a-Service，幾年前如果你想在辦公室或者公司的網站上執行一些企業應用，你需要去買伺服器，或者別的高昂的硬體來控制本地應用，讓你的業務執行起來。
但是現在有IaaS，你可以將硬體外包到別的地方去。IaaS公司會提供場外伺服器，儲存和網路硬體，你可以租用。節省了維護成本和辦公場地，公司可以在任何時候利用這些硬體來執行其應用。
一些大的IaaS公司包括Amazon, Microsoft, VMWare, Rackspace和Red Hat.不過這些公司又都有自己的專長，比如Amazon和微軟給你提供的不只是IaaS，他們還會將其計算能力出租給你來host你的網站。
- PaaS: Platform-as-a-Service（平臺即服務）
第二層就是所謂的PaaS，某些時候也叫做中介軟體。你公司所有的開發都可以在這一層進行，節省了時間和資源。
PaaS公司在網上提供各種開發和分發應用的解決方案，比如虛擬伺服器和作業系統。這節省了你在硬體上的費用，也讓分散的工作室之間的合作變得更加容易。網頁應用管理，應用設計，應用虛擬主機，儲存，安全以及應用開發協作工具等。
一些大的PaaS提供者有Google App Engine,Microsoft Azure，Force.com,Heroku，Engine Yard。最近興起的公司有AppFog, Mendix 和 Standing Cloud；
- 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成為開發者的“新寵”。
- Docker
Docker 是 PaaS 提供商 dotCloud 開源的一個基於 LXC 的高階容器引擎，原始碼託管在 Github 上, 基於go語言並遵從Apache2.0協議開源。Docker自2013年推出以來非常火熱，受到業界的廣泛關注。Docker container和普通的虛擬機器Image相比, 最大的區別是它並不包含作業系統核心.
- Docker特點：
- 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計算框架一個叢集管理器，提供了有效的、跨分散式應用或框架的資源隔離和共享，可以執行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，可以在同一個節點上同時執行。
- Marathon
Marathon是一個mesos框架，能夠支援執行長服務，比如web應用等。是叢集的分散式Init.d，能夠原樣執行任何Linux二進位制釋出版本，如Tomcat Play等等，可以叢集的多程式管理。也是一種私有的Pass，實現服務的發現，為部署提供提供REST API服務，有授權和SSL、配置約束，通過HAProxy實現服務發現和負載平衡。
這樣，我們可以如同一臺Linux主機一樣管理數千臺伺服器，它們的對應原理如下圖，使用Marathon類似Linux主機內的init Systemd等外殼管理，而Mesos則不只包含一個Linux核，可以排程數千臺伺服器的Linux核，實際是一個資料中心的核心：
- 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；
- 總結
通過這次大會的交流學習，不能說掌握了多少專業的細節知識，但絕對是眼界開闊了些；瞭解了業界軟體發展的技術動態，知道了行業公司在軟體開發流程中遇到的問題及解決方案。在面對日新月異的技術發展，我認為有幾個原則需要堅守下：
- 及時瞭解新的技術動態和行業的發展方向；
- 重視開源技術的發展，幾乎影響力很大的技術都來源於開源社群；
- 架構設計，應已簡單實用為目標，環境需求為根本；不要盲從高大上的系統；
- 敢於引進新的技術，沒有最穩定的系統只有不斷改進的系統；