摘要：后端好書(shū)閱讀與推薦系列文章后端好書(shū)閱讀與推薦后端好書(shū)閱讀與推薦續(xù)后端好書(shū)閱讀與推薦續(xù)二后端好書(shū)閱讀與推薦續(xù)三這里依然記錄一下每本書(shū)的亮點(diǎn)與自己讀書(shū)心得和體會(huì)，分享并求拍磚。然后又請(qǐng)求封鎖，當(dāng)釋放了上的封鎖之后，系統(tǒng)又批準(zhǔn)了的請(qǐng)求一直等待。

后端好書(shū)閱讀與推薦系列文章：
后端好書(shū)閱讀與推薦
后端好書(shū)閱讀與推薦（續(xù)）
后端好書(shū)閱讀與推薦（續(xù)二）
后端好書(shū)閱讀與推薦（續(xù)三）

這里依然記錄一下每本書(shū)的亮點(diǎn)與自己讀書(shū)心得和體會(huì)，分享并求拍磚。

實(shí)戰(zhàn)Java高并發(fā)程序設(shè)計(jì) (豆瓣) https://book.douban.com/subje...

這本書(shū)是國(guó)產(chǎn)書(shū)籍里面質(zhì)量較高的一本了（很多國(guó)產(chǎn)書(shū)都是東拼西湊或者敷衍了事），作者從實(shí)際出發(fā)，結(jié)合理論，講的很有邏輯，而且還有很多形象的手繪，和那本Java并發(fā)編程實(shí)戰(zhàn)相比更新一些，讀起來(lái)也更容易一些。

亮點(diǎn)：

并行不一定是從性能角度考慮，有的時(shí)候是自然而然的，比如獨(dú)立的任務(wù)分為不同的線程更易于理解

同步異步，阻塞非阻塞，并行并發(fā)，這幾個(gè)概念估計(jì)很多人都混亂了很久，和作者的觀點(diǎn)稍微有點(diǎn)出入，我這里總結(jié)一下：同步異步的區(qū)別關(guān)鍵在于A對(duì)B請(qǐng)求發(fā)出后,如果A要等待B的結(jié)果那就是同步，如果A直接返回不需要B的結(jié)果或者等待B完成后再通知就是異步；阻塞強(qiáng)調(diào)的是A請(qǐng)求B過(guò)后不能做其它事，只能干等著（自旋或者休眠），非阻塞指的是A在等B的過(guò)程中可以做其它事；并行是真正意義的的多個(gè)任務(wù)同時(shí)執(zhí)行，并發(fā)可能是并行，也可能只是多個(gè)任務(wù)交替執(zhí)行，但是切換的很快，給我們?cè)斐闪瞬⑿械摹凹傧蟆?，真?shí)的并行只可能出現(xiàn)在多核cpu上

死鎖：是指兩個(gè)或兩個(gè)以上的或線程在執(zhí)行過(guò)程中，因爭(zhēng)奪資源而互相等待，都阻塞起來(lái)；活鎖：是指線程A可以使用資源，但它讓其他線程先使用資源，線程B也可以使用資源，但它也讓其他線程先使用資源。這樣線程雖然是活躍的，但是啥事也做不了；饑餓：是指如果線程T1占用了資源R，線程T2又請(qǐng)求R，于是T2等待。T3也請(qǐng)求資源R，當(dāng)T1釋放了R上的封鎖后，系統(tǒng)首先批準(zhǔn)了T3的請(qǐng)求，T2仍然等待。然后T4又請(qǐng)求封鎖R，當(dāng)T3釋放了R上的封鎖之后，系統(tǒng)又批準(zhǔn)了T4的請(qǐng)求...T2一直等待。

并行對(duì)于效率的提升主要取決于業(yè)務(wù)中串行代碼的比例和CPU數(shù)量，CPU數(shù)量越多，串行化代碼比例越少，那么多線程的優(yōu)化方式效果越好

JMM關(guān)注原子性（某個(gè)操作不能被中斷），可見(jiàn)性（一個(gè)線程對(duì)某變量的修改對(duì)另一個(gè)線程立馬可見(jiàn)），有序性（CPU為了性能可能指令重排，應(yīng)用happen-before原則，能保證串行語(yǔ)義一致但是不一定保證多線程之間語(yǔ)義也一致）

類可以通過(guò)繼承Thread，重寫(xiě)run方法來(lái)實(shí)現(xiàn)多線程，但考慮到Java是單繼承的，繼承是一種很寶貴的資源，所以類應(yīng)該實(shí)現(xiàn)Runable接口并重寫(xiě)run方法，并把自己作為構(gòu)造參數(shù)傳給Thread類來(lái)實(shí)現(xiàn)多線程，這種做法也符合Effective Java里面提到的工作單元（Runable）與執(zhí)行機(jī)制（Thread）分離的概念

加鎖一定要注意加正確，主要有三種：指定加鎖對(duì)象，獲得該對(duì)象的鎖才能進(jìn)入同步區(qū)；作用于實(shí)例方法，鎖加在當(dāng)前實(shí)例上；作用于靜態(tài)方法，鎖加在當(dāng)前類上。而且要注意多線程的鎖一定要是真正的加在同一個(gè)對(duì)象上，比如

   Integer i;
   synchronized(i){
       i++;
   }

就不正確，因?yàn)?Integer 是不變類，在執(zhí)行++運(yùn)算的時(shí)候 實(shí)際上是創(chuàng)建了新類，所以那個(gè)同步塊實(shí)際上指向了不同的對(duì)象，自然不會(huì)正確 。事實(shí)上這段代碼 在 IDEA 里面他會(huì)提示你 synchronized 加在了非final變量上，都可能產(chǎn)生非預(yù)期結(jié)果。

java 內(nèi)置的線程池非常強(qiáng)大：newSingleThreadExecutor，newFixedThreadPool，newCachedThreadPool，newScheduledThreadPool等等，其核心都是ThreadPoolExecutor實(shí)現(xiàn)的，不過(guò)是參數(shù)不同。而ThreadPoolExecutor又是可以高度定制的，threadFactory，handler 都可以自定義，實(shí)現(xiàn)自己的線程工廠，拒絕策略等。ThreadPoolExecutor可以擴(kuò)展來(lái)實(shí)現(xiàn)更豐富的功能，例如監(jiān)聽(tīng)所有任務(wù)的開(kāi)始結(jié)束時(shí)間，避免線程池“吃掉異?！?。

作者研究了ConcurrentLinkedQueue的源碼，發(fā)現(xiàn)不用鎖而是用CAS來(lái)實(shí)現(xiàn)多線程安全，代碼復(fù)雜度高了很多，但是性能卻高了很多；其實(shí)凡事有得必有失，就像Node一樣，異步帶來(lái)的性能提升是巨大的，但是代碼的編寫(xiě)難度也提升了很多。此外作者還分析了java.util.concurrent里面其他的大量的數(shù)據(jù)結(jié)構(gòu)，如CopyOnWriteArrayList，BlockingQueue，SkipList。這些數(shù)據(jù)結(jié)構(gòu)都是Java設(shè)計(jì)者們精心設(shè)計(jì)的多線程安全數(shù)據(jù)結(jié)構(gòu)，比傳統(tǒng)的多線程安全數(shù)據(jù)結(jié)構(gòu)性能提升很多

提高鎖性能：減小鎖持有時(shí)間，亦即只在必要的時(shí)候加鎖；減小鎖粒度，亦即縮小加鎖范圍，比如ConcurrentHashMap不對(duì)整個(gè)對(duì)象加鎖而是一段；讀寫(xiě)分離鎖（ReentrantReadWriteLock）替換獨(dú)占鎖；讀寫(xiě)鎖的擴(kuò)展，亦即按照功能分離不同功能的鎖，使用多個(gè)ReentrantLock 來(lái)表達(dá)不同條件的鎖，使之不互相影響，LinkedBlockingQueue就采用了這種思想；鎖粗化，如果鎖不停地獲取釋放反而浪費(fèi)資源，所以把所有的鎖整合成一個(gè)鎖來(lái)提高性能，比如虛擬機(jī)就會(huì)實(shí)現(xiàn)這種操作。按我理解，如果鎖里面的操作耗時(shí)，那么就要細(xì)化，給其他線程機(jī)會(huì)，提高吞吐量，反之就應(yīng)該粗化，讓自己早點(diǎn)執(zhí)行完畢。

作者總結(jié)了一系列多線程相關(guān)的設(shè)計(jì)模式，比如單例模式、不變模式、生產(chǎn)者消費(fèi)者、介紹了用框架實(shí)現(xiàn)的無(wú)鎖生產(chǎn)者消費(fèi)者、future模式實(shí)現(xiàn)的異步操作、并行流水線和搜索排序計(jì)算等等，這些都是我們業(yè)務(wù)中常常用到的模式，總結(jié)一下，以后運(yùn)用更加自如

為了體會(huì)到本書(shū)的點(diǎn)，我寫(xiě)了一些代碼。另外AKKA部分我沒(méi)有看，因?yàn)闆](méi)有用過(guò)，即使看了也體會(huì)不到精髓，所以暫時(shí)先不了解了。

計(jì)算機(jī)網(wǎng)絡(luò)（第5版） (豆瓣) https://book.douban.com/subje...

這本書(shū)當(dāng)年大二的時(shí)候是教材，沒(méi)意識(shí)到它的珍貴，本科畢業(yè)的時(shí)候居然拿去賣了，不過(guò)后來(lái)我又買了回來(lái)，好好的讀下來(lái)，感覺(jué)對(duì)整個(gè)計(jì)算機(jī)網(wǎng)絡(luò)都有了一個(gè)更清晰地概念。當(dāng)然此書(shū)太厚，若非必要，不宜一一細(xì)讀，挑些重要的基礎(chǔ)概念（比如TCP/IP）和如今越來(lái)越重要的內(nèi)容（比如CDN）細(xì)讀，其余看個(gè)大概即可。

亮點(diǎn)：

首先講了計(jì)算機(jī)網(wǎng)絡(luò)的重要性（郵件，電子商務(wù)，web，在線娛樂(lè)游戲，GPS）以及廣闊前景（IOT的萬(wàn)物互聯(lián)，可穿戴計(jì)算機(jī)），事實(shí)上現(xiàn)在的人早就習(xí)慣了網(wǎng)絡(luò)的存在，反而不覺(jué)得它有那么重要，就像空氣一樣，但是一旦你把它的作用列出來(lái)你就會(huì)發(fā)現(xiàn)，它是如此的重要，試著想想，如果沒(méi)有網(wǎng)絡(luò)，現(xiàn)代社會(huì)怎么運(yùn)轉(zhuǎn)？

為了降低網(wǎng)絡(luò)設(shè)計(jì)的復(fù)雜性，絕大多數(shù)網(wǎng)絡(luò)都組織成一個(gè)層次棧，每一層都構(gòu)建于其下一層之上。這種分層的概念在計(jì)算機(jī)科學(xué)中廣泛存在，比如面向?qū)ο?、ADT、信息隱藏等，其根本思想都是提供服務(wù)但是隱藏實(shí)現(xiàn)。這種分而治之的思想可被我們借鑒，用來(lái)簡(jiǎn)化架構(gòu)，邏輯解耦。比如 nginx 處理請(qǐng)求也是分了不同的階段，Java 里面的 servlet 也是一樣分階段處理的

數(shù)據(jù)鏈路層只關(guān)注幀（frame）從一個(gè)節(jié)點(diǎn)到另一個(gè)節(jié)點(diǎn)的傳輸，是點(diǎn)到點(diǎn)的，而網(wǎng)絡(luò)層的目的是采用數(shù)據(jù)報(bào)或者虛電路技術(shù)將數(shù)據(jù)包（package）從發(fā)送方傳輸至接收方，中間可能要經(jīng)過(guò)很多點(diǎn)，是處理端到端數(shù)據(jù)傳輸?shù)淖畹讓樱匀皇屈c(diǎn)到點(diǎn)的（因?yàn)樗仨氷P(guān)心發(fā)送方到接收方的中間節(jié)點(diǎn)），而傳輸層是真正的端到端，亦即發(fā)送接收方不必關(guān)心傳輸過(guò)程中有多少個(gè)節(jié)點(diǎn)，可以認(rèn)為數(shù)據(jù)段（segment）是直接從發(fā)送方到接收方的。從另一方面來(lái)看，一個(gè)數(shù)據(jù)報(bào)在傳輸過(guò)程中，源/目的IP是不變的（除非NAT），但是源/目的MAC卻是一跳一跳地變化的

擁塞控制和流量控制有很大差異。前者指確保網(wǎng)絡(luò)能夠承載所有到達(dá)的流量，是一個(gè)全局問(wèn)題；后者指發(fā)送方不會(huì)持續(xù)以超過(guò)接收方能力的速率傳輸數(shù)據(jù)，解決這兩個(gè)問(wèn)題的最佳解法通常都是主機(jī)慢下來(lái)

網(wǎng)絡(luò)層與傳輸層提供的服務(wù)有些類似，那么為什么不用一層做完呢？答案就是傳輸層代碼主要運(yùn)行在用戶主機(jī)上，網(wǎng)絡(luò)層主要運(yùn)行在運(yùn)營(yíng)商的路由器上，對(duì)于網(wǎng)絡(luò)層，用戶自己有著真正的控制權(quán)，可以通過(guò)差錯(cuò)控制、順序控制、流量控制等方式來(lái)獲得比網(wǎng)絡(luò)層（盡力而為的服務(wù)，無(wú)保證）更加可靠的服務(wù)；另一個(gè)方面，分層也是解耦的思想體現(xiàn)，只要實(shí)現(xiàn)了傳輸原語(yǔ)，就不必在乎網(wǎng)絡(luò)層的實(shí)現(xiàn)（以太網(wǎng)或者WiMAX）

簡(jiǎn)單情況下，我發(fā)一包，你回一包，但是網(wǎng)絡(luò)不佳的情況下，要保證包傳輸?shù)轿痪捅仨氁胫貍鳈C(jī)制，重傳機(jī)制一引入就必須考慮如何解決包重復(fù)接受的問(wèn)題，所以限制了包生存周期（跳計(jì)數(shù)器），然后通過(guò)段序號(hào)、日時(shí)鐘、滑動(dòng)窗口協(xié)議來(lái)丟棄已經(jīng)接受的重復(fù)數(shù)據(jù)包，通過(guò)三步握手解決了初始序號(hào)獲得的問(wèn)題。這一個(gè)出現(xiàn)問(wèn)題、解決問(wèn)題、出現(xiàn)新問(wèn)題、解決新問(wèn)題的反復(fù)的過(guò)程體現(xiàn)了協(xié)議設(shè)計(jì)者們的智慧和不屈不撓的毅力，非常值得我們學(xué)習(xí)

由“兩軍對(duì)壘”問(wèn)題引出釋放連接的問(wèn)題，無(wú)論怎么確認(rèn)通信，也無(wú)法百分之百保證對(duì)方收到的消息，兩次、三次、四次握手其實(shí)都是可行的（不一定是無(wú)誤的），事實(shí)上釋放連接的四步揮手完全就是“兩軍對(duì)壘”的一個(gè)折中方案，既保證了準(zhǔn)確率，又避免了帶寬浪費(fèi)。建立連接的三次握手也同樣是一種折中

內(nèi)容分發(fā)不同于通信任務(wù)，目標(biāo)主機(jī)不重要，重要的是獲取了什么內(nèi)容，獲取內(nèi)容的代價(jià)。主要有兩個(gè)結(jié)構(gòu)，CDN和P2P。CDN采用分發(fā)樹(shù)結(jié)構(gòu)，擴(kuò)展性很高，實(shí)現(xiàn)原理是DNS重定向；P2P把多臺(tái)計(jì)算機(jī)（對(duì)等節(jié)點(diǎn)）的資源集中起來(lái)，每臺(tái)計(jì)算機(jī)既可以作為服務(wù)器向其他計(jì)算機(jī)提供資源，也可以作為客戶端向其他計(jì)算機(jī)請(qǐng)求資源

本文最大特點(diǎn)就是故事性強(qiáng)，一環(huán)扣一環(huán)，引人入勝。

Netty實(shí)戰(zhàn) (豆瓣) https://book.douban.com/subje...

Netty是網(wǎng)絡(luò)編程中不可不談的一個(gè)大作，也是許多成功的網(wǎng)絡(luò)應(yīng)用的基礎(chǔ)設(shè)施，本書(shū)就從為什么是Netty，引導(dǎo)我們嘗試使用，并進(jìn)行了細(xì)致的講解，為我們?nèi)娴钠饰隽薔etyy這個(gè)龐大而精妙的框架，組織得很有條理。

但是要注意，看本書(shū)之前或者說(shuō)學(xué)習(xí)Netty之前，務(wù)必要對(duì)Java IO、NIO、AIO以及Reactor和Proactor的概念有一定的了解，不然就是沒(méi)學(xué)會(huì)走先去學(xué)跑了。

亮點(diǎn)：

低級(jí)別的 API 不僅暴露了高級(jí)別直接使用的復(fù)雜性，而且引入了過(guò)分依賴于這項(xiàng)技術(shù)所造成的短板。因此，面向?qū)ο笥幸粋€(gè)基本原則：通過(guò)抽象來(lái)隱藏背后的復(fù)雜性。Netty提供了高層次的抽象來(lái)簡(jiǎn)化TCP和UDP服務(wù)器的編程，但是你仍然可以使用底層地API。(David John Wheeler有一句名言“計(jì)算機(jī)科學(xué)中的任何問(wèn)題都可以通過(guò)加上一層邏輯層來(lái)解決”，這個(gè)原則在計(jì)算機(jī)各技術(shù)領(lǐng)域被廣泛應(yīng)用)

一個(gè) Netty 的設(shè)計(jì)的主要目標(biāo)是促進(jìn)“關(guān)注點(diǎn)分離”：將你的業(yè)務(wù)邏輯從網(wǎng)絡(luò)基礎(chǔ)設(shè)施應(yīng)用程序中分離

Netty組件說(shuō)明：BOOTSTRAP啟動(dòng)應(yīng)用，配置，為應(yīng)用提供一個(gè)容器；Channel是一條通信信道，類似于socket；ChannelHandler是數(shù)據(jù)處理的容器，也是我們要寫(xiě)業(yè)務(wù)邏輯的地方，也是我們通常關(guān)注最多的地方；ChannelPipeline屬于一個(gè)Channel，是ChannelHandler鏈的容器；EventLoop 用于處理 Channel 的 I/O 操作，一個(gè)單一的 EventLoop通常會(huì)處理多個(gè) Channel事件，一個(gè) EventLoopGroup 可以含有多于一個(gè)的 EventLoop；ChannelFuture 的 addListener 方法注冊(cè)了一個(gè) ChannelFutureListener ，當(dāng)操作完成時(shí)，可以被通知（不管成功與否）?？梢?jiàn)，Netty的組件劃分真的很細(xì)致精小，優(yōu)點(diǎn)就是模塊間易于解耦，模塊本身可重用性高，但是也就有點(diǎn)啰嗦，這也是Java本身比較受到詬病的原因，還是那句話，凡事有得必有失嘛，它的優(yōu)點(diǎn)能讓你忍受它的缺點(diǎn)就行了

Transport 使用情景：OIO（即老的，最原始的阻塞IO）-在低連接數(shù)、需要低延遲時(shí)、阻塞時(shí)使用；NIO-在高連接數(shù)時(shí)使用；Local-在同一個(gè)JVM內(nèi)通信時(shí)使用；Embedded-測(cè)試ChannelHandler時(shí)使用

Netty提出的ByteBuf優(yōu)于JDK原生的ByteBuffer因?yàn)椋嚎梢宰远x緩沖類型（堆緩沖區(qū)，直接緩沖區(qū)，復(fù)合緩沖區(qū)），通過(guò)復(fù)合緩沖類型實(shí)現(xiàn)零拷貝；擴(kuò)展性好，比如 StringBuilder；不需要調(diào)用 flip() 來(lái)切換讀/寫(xiě)模式；讀取和寫(xiě)入索引分開(kāi)

直接緩沖區(qū)”是另一個(gè) ByteBuf 模式，允許 JVM 通過(guò)本地方法調(diào)用分配內(nèi)存，優(yōu)點(diǎn)：通過(guò)免去 socket 發(fā)送數(shù)據(jù)之前，JVM 先將數(shù)據(jù)從用戶區(qū)復(fù)制到內(nèi)核區(qū), 提升IO處理速度， 直接緩沖區(qū)的內(nèi)容可以駐留在垃圾回收掃描的堆區(qū)以外；DirectBuffer 在 -XX:MaxDirectMemorySize=xxM大小限制下, 使用 Heap 之外的內(nèi)存, GC對(duì)此”無(wú)能為力”,也就意味著規(guī)避了在高負(fù)載下頻繁的GC過(guò)程對(duì)應(yīng)用線程的中斷影響

Netty 的使用一個(gè)包含 EventLoop 的 EventLoopGroup 為 Channel 的 I/O 和事件服務(wù)。EventLoop 創(chuàng)建并分配方式不同基于傳輸?shù)膶?shí)現(xiàn)。異步實(shí)現(xiàn)使用只有少數(shù) EventLoop(和Threads)共享于 Channel 之間 。這允許最小線程數(shù)服務(wù)多個(gè) Channel,不需要為他們每個(gè)Channel都有一個(gè)專門(mén)的 Thread

本書(shū)中對(duì)于異步同步和阻塞非阻塞的觀念有些模糊，請(qǐng)見(jiàn)上面實(shí)戰(zhàn)Java高并發(fā)程序設(shè)計(jì)一節(jié)我的理解，讀者可以參考一下，自己取舍。事實(shí)上，Java的NIO不是異步的，AIO(或者說(shuō)NIO2.0)才是，Netty基于NIO(嘗試過(guò)并拋棄了AIO)，通過(guò)自己的封裝，實(shí)現(xiàn)了從使用者角度看起來(lái)的異步。學(xué)習(xí)Netty還有一個(gè)好地方就是官方文檔。

分布式j(luò)ava應(yīng)用 (豆瓣) https://book.douban.com/subje...

后端要搞得好，不上分布式肯定是不行的，因?yàn)閷?xiě)個(gè)小網(wǎng)站你可以懂點(diǎn) SSM 或者 Spring Boot 就行了，但是如果要想搭建一個(gè)（或者說(shuō)成為構(gòu)建過(guò)程的一份子）用戶成千上萬(wàn)甚至百萬(wàn)、千萬(wàn)、上億的站點(diǎn)，那就必須要懂分布式了。這本書(shū)就可以當(dāng)做學(xué)習(xí)分布式的入門(mén)書(shū)籍。

亮點(diǎn)：

實(shí)踐是最好的成長(zhǎng)，發(fā)表是最好的記憶。這句話的確可以放在電腦上當(dāng)桌面背景

分布式系統(tǒng)通信底層都依賴于TCP、UDP，但是為了易用性，通常會(huì)使用一些更貼近應(yīng)用層的協(xié)議，書(shū)中提到了原始的jdk通信，以及webservice,Mina,實(shí)際上還有許多，比如RPC、WebService、RMI、JMS（p2p或者發(fā)布訂閱）、JNDI等等

網(wǎng)絡(luò)IO分三類。BIO：用戶線程在進(jìn)行IO操作的時(shí)候進(jìn)行系統(tǒng)調(diào)用，阻塞，只有讀到（寫(xiě)入）了數(shù)據(jù)才釋放資源；NIO：同步非阻塞IO，用戶線程在發(fā)起IO操作之后可以立即返回，只有流可讀（可寫(xiě)）操作系統(tǒng)才會(huì)通知用戶線程進(jìn)行讀?。▽?xiě)入），但是用戶線程需要不斷輪詢來(lái)請(qǐng)求數(shù)據(jù)，Linux采用epoll實(shí)現(xiàn)；AIO：用戶線程發(fā)起請(qǐng)求時(shí)，由操作系統(tǒng)來(lái)進(jìn)行讀?。▽?xiě)入），IO事件就緒的時(shí)候，操作系統(tǒng)會(huì)通知對(duì)應(yīng)的用戶線程來(lái)處理，實(shí)現(xiàn)真正的異步IO，Windows下IOCP實(shí)現(xiàn)了AIO，Linux只有epoll實(shí)現(xiàn)模擬實(shí)現(xiàn)的AIO。同時(shí)，由于服務(wù)器的主力是Linux，所以AIO的用處目前不是特別廣

BIO對(duì)應(yīng)的是一連接一線程，可以引入線程池來(lái)優(yōu)化，但是一個(gè)操作系統(tǒng)線程數(shù)量終究有限，所以不可能支撐大量連接數(shù)；NIO對(duì)應(yīng)的是一請(qǐng)求一線程，只有某個(gè)連接有讀寫(xiě)事件時(shí)才為其生成一個(gè)線程來(lái)處理，只有連接數(shù)不多或者連接數(shù)多且都請(qǐng)求頻繁時(shí)才沒(méi)有優(yōu)勢(shì)，但實(shí)際情況中，服務(wù)器通常會(huì)支持大量連接數(shù)，但是同時(shí)發(fā)送請(qǐng)求的連接不會(huì)太多，所以NIO應(yīng)用比價(jià)廣泛；AIO對(duì)應(yīng)一個(gè)有效請(qǐng)求一個(gè)線程，亦即OS處理IO完畢后再生成用戶線程處理，充分調(diào)用了OS參與，可以應(yīng)對(duì)連接數(shù)多且操作頻繁的場(chǎng)景，如果Linux對(duì)AIO的支持更好，這個(gè)模型可能會(huì)流行起來(lái)

SOA亦即面向服務(wù)的架構(gòu)，強(qiáng)調(diào)系統(tǒng)之間以標(biāo)準(zhǔn)服務(wù)的方式進(jìn)行交互，各系統(tǒng)可以采用不同的語(yǔ)言、框架來(lái)實(shí)現(xiàn)，交互則全部采用服務(wù)來(lái)進(jìn)行,目前SCA和ESB是主流標(biāo)準(zhǔn)，分別有Tuscany和Mule等常用框架實(shí)現(xiàn)

調(diào)優(yōu)的步驟：衡量系統(tǒng)現(xiàn)狀，設(shè)定調(diào)優(yōu)目標(biāo)，尋找性能瓶頸，性能調(diào)優(yōu)，衡量是否達(dá)標(biāo)，反復(fù)進(jìn)行前面三步直至達(dá)標(biāo)。

以前我對(duì)負(fù)載均衡的理解還是停留在引入一個(gè)（群）中間節(jié)點(diǎn)作為調(diào)度者，調(diào)度者（硬件或軟件）接受請(qǐng)求并轉(zhuǎn)發(fā)給實(shí)際應(yīng)用服務(wù)器。這實(shí)際上叫做中心化負(fù)載均衡，書(shū)中提到Gossip實(shí)現(xiàn)了無(wú)中間節(jié)點(diǎn)的軟件負(fù)載均衡實(shí)際上是一種去中心化傳播事件的負(fù)載均衡，去掉中心節(jié)點(diǎn)后請(qǐng)求響應(yīng)直接進(jìn)行加快了速度，而且能避免調(diào)度者單點(diǎn)故障問(wèn)題。最高級(jí)別的負(fù)載均衡是全局負(fù)載均衡，實(shí)現(xiàn)不同地域機(jī)房的負(fù)載均衡，既可以避免單點(diǎn)故障還可以就近響應(yīng)，提高訪問(wèn)速度，實(shí)現(xiàn)高可用，一般由硬件GSLB實(shí)現(xiàn)（在合肥 ping 了一下 qq.com 得到的結(jié)果是深圳的，在天津得到的結(jié)果就是北京的，雖然不一定，但是看得出來(lái)有差別），但是多機(jī)房的一致性很難保證，通常都要用消息中間件來(lái)實(shí)現(xiàn)

除了上面提到的機(jī)房等硬件上的故障，應(yīng)用軟件本身的故障也是高可用的大敵，所以要注意避免故障，及時(shí)發(fā)現(xiàn)并處理故障，具體包括：明確使用場(chǎng)景，做到最貼近場(chǎng)景的最簡(jiǎn)單系統(tǒng)，或者分階段最簡(jiǎn)單系統(tǒng)；設(shè)計(jì)可容錯(cuò)系統(tǒng)，fail fast；系統(tǒng)可自我保護(hù)，對(duì)第三方依賴保持弱依賴，避免連鎖失效；建立分級(jí)報(bào)警系統(tǒng)和日志記錄與分析系統(tǒng)；注意總結(jié)故障分析便于下次快速利用，這也是架構(gòu)即未來(lái)里面提到過(guò)的；按照業(yè)務(wù)拆分子系統(tǒng)......

構(gòu)建可伸縮的系統(tǒng)關(guān)鍵在于水平伸縮，因?yàn)榇怪鄙炜s是有限的（一臺(tái)機(jī)器的性能終究有限），而水平伸縮理論上是無(wú)限的（可以添加“無(wú)數(shù)”臺(tái)機(jī)器），水平伸縮通常通過(guò)SNA(share nothing architecture)實(shí)現(xiàn)，亦即應(yīng)用系統(tǒng)之間不共享狀態(tài)，把狀態(tài)信息統(tǒng)一放入緩存或數(shù)據(jù)庫(kù)（可以是分布式）。文件系統(tǒng)的水平擴(kuò)展思想也是類似的

本書(shū)可以當(dāng)做入門(mén)書(shū)籍，但是書(shū)中真正關(guān)于分布式的內(nèi)容似乎少了些，倒是Java基礎(chǔ)知識(shí)占據(jù)了很大篇幅，感覺(jué)有點(diǎn)不對(duì)題目，畢竟要看這些知識(shí)我可以看Java核心技術(shù)，Java并發(fā)編程實(shí)戰(zhàn)或者深入理解jvm啊，但是也可以用來(lái)復(fù)習(xí)一下，而且有許多實(shí)驗(yàn)數(shù)據(jù)可供參考，還是可以的。

PS:我之前已經(jīng)看了Netty了，所以書(shū)中關(guān)于Mina的部分，時(shí)間不夠我就跳著看了，時(shí)間夠還是可以了解一下的，兩者對(duì)比。

分布式系統(tǒng) 原書(shū)第5版 (豆瓣) https://book.douban.com/subje...

讀了上面一本分布式Java，不免對(duì)分布式系統(tǒng)想要有一個(gè)更全面、更系統(tǒng)的認(rèn)識(shí)，那么這本書(shū)就是一本絕佳的書(shū)籍。

亮點(diǎn)：

資源共享是構(gòu)建分布式系統(tǒng)的主要目；并發(fā)、缺乏全局時(shí)鐘、故障獨(dú)立性是其主要特征；處理其構(gòu)件的異構(gòu)性、開(kāi)放性（允許增加或替換組件）、安全性（機(jī)密完整可用）、可伸縮性（用戶的負(fù)載增加時(shí)能正常運(yùn)行的能力）、故障處理、組件并發(fā)性、透明性（分布式的組件對(duì)外展示為一個(gè)整體）、QoS（在傳輸數(shù)據(jù)時(shí)滿足要求的能力）等是其主要挑戰(zhàn)

無(wú)論是 請(qǐng)求-應(yīng)答（比如http） 還是 RPC 或者 RMI（類似于RPC但是僅限于Java且支持對(duì)象概念），收發(fā)雙發(fā)都是雙向的（直接通信），要想解耦收發(fā)雙方（空間解耦和時(shí)間解耦），那么就得用間接通信：組通信（廣播），發(fā)布訂閱系統(tǒng)，消息隊(duì)列，元組空間（生成通信），分布式共享內(nèi)存等方式

中間件是一組計(jì)算機(jī)上的進(jìn)程或?qū)ο?，其目的是屏蔽異?gòu)性，亦即底層的通訊，交互，連接等復(fù)雜又通用的功能以服務(wù)的形式提供出來(lái)，分布式系統(tǒng)應(yīng)用在交互時(shí)，直接使用中間件提供的高層編程抽象即可，實(shí)現(xiàn)了簡(jiǎn)潔的分布式系統(tǒng)應(yīng)用的通信和資源共享的支持

套接字（socket）是通信的抽象，無(wú)論是TCP還是UDP的方式，它提供了進(jìn)程間通信的端點(diǎn)，必須和協(xié)議，主機(jī)地址（分為目的端與源端），端口（分為目的端與源端）綁定起來(lái)

RPC的概念代表著分布式計(jì)算的重大突破，使得分布式編程和傳統(tǒng)編程類似，實(shí)現(xiàn)了高級(jí)的透明性，這種相似性將傳統(tǒng)的過(guò)程調(diào)用模型擴(kuò)展到分布式環(huán)境中，隱藏了底層分布式環(huán)境的重要細(xì)節(jié)部分，簡(jiǎn)化了分布式開(kāi)發(fā)

操作系統(tǒng)的任務(wù)是提供一個(gè)物理層（處理器，內(nèi)存，硬盤(pán)等）之上的面向問(wèn)題的抽象，例如給程序員提供文件和套接字而不是磁盤(pán)塊和原始網(wǎng)絡(luò)訪問(wèn)。操作系統(tǒng)分為網(wǎng)絡(luò)操作系統(tǒng)（具有內(nèi)置聯(lián)網(wǎng)功能，能自主管理自己的資源并網(wǎng)絡(luò)透明地訪問(wèn)其它一些資源但是不能跨節(jié)點(diǎn)管理進(jìn)程，也就是有多個(gè)系統(tǒng)映像）和分布式操作系統(tǒng)（用戶不必關(guān)心程序運(yùn)行的地點(diǎn)和資源位置，能透明的將新的進(jìn)程調(diào)度到合理的節(jié)點(diǎn)上，有單一的系統(tǒng)映像），后者幾乎沒(méi)有普遍應(yīng)用的案例，因?yàn)橹虚g件和網(wǎng)絡(luò)操作系統(tǒng)的結(jié)合就能很好的滿足用戶需求

最重要的兩種中間件風(fēng)格：分布式對(duì)象（允許面向?qū)ο缶幊棠Ｐ烷_(kāi)發(fā)分布式系統(tǒng)，通信實(shí)體被表示成對(duì)象，通信使用RMI，但也可以使用其他的比如分布式事件）；組件（基于對(duì)象方法的自然演化，主要克服其限制：隱式依賴，編程復(fù)雜性，缺少關(guān)注點(diǎn)分離支持，無(wú)部署支持）

面向服務(wù)的體系結(jié)構(gòu)（SOA）是一套設(shè)計(jì)原則，分布式系統(tǒng)用松耦合的服務(wù)集開(kāi)發(fā)，服務(wù)能被動(dòng)態(tài)發(fā)現(xiàn)，能互相通信并通過(guò)編排進(jìn)行協(xié)調(diào)從而提供更強(qiáng)的服務(wù)?？梢曰诜植际綄?duì)象或者組件來(lái)實(shí)現(xiàn)，但實(shí)際中主要通過(guò)web服務(wù)實(shí)現(xiàn)，主要是因?yàn)閣eb服務(wù)內(nèi)在的松耦合性（比如不管子系統(tǒng)是CORBA還是.NET，只要用web服務(wù)暴露接口，就能輕易實(shí)現(xiàn)集成）

分布式是一門(mén)結(jié)合計(jì)算機(jī)網(wǎng)絡(luò)與操作系統(tǒng)等多種門(mén)類的交叉學(xué)科，所以這本書(shū)也包含了許多這些方面的知識(shí)，不失為一種復(fù)習(xí)的方式。

大型網(wǎng)站系統(tǒng)與Java中間件開(kāi)發(fā)實(shí)踐 (豆瓣) https://book.douban.com/subje...

上面的分布式Java是一本很基礎(chǔ)的入門(mén)書(shū)籍，這本書(shū)算是一本更加全面和仔細(xì)的書(shū)籍，把它沒(méi)講到的部分都講了一些，而且更注重中間件（支撐大型網(wǎng)站關(guān)鍵、必要的技術(shù)之一）的講解。

亮點(diǎn)：

分布式系統(tǒng)中的控制節(jié)點(diǎn)協(xié)調(diào)系統(tǒng)之間的協(xié)作，可以用：硬件均衡負(fù)載設(shè)備（昂貴）、軟件方式的透明代理（增加流量、易出現(xiàn)單點(diǎn)失效）、采用名稱服務(wù)的直連請(qǐng)求（不易單點(diǎn)失效、流量少）、采用規(guī)則服務(wù)器的直連調(diào)用、采用master+worker的架構(gòu)

從一個(gè)最基本、簡(jiǎn)單、部署在單機(jī)上的網(wǎng)站開(kāi)始，數(shù)據(jù)量和訪問(wèn)量慢慢上去了，一步步演進(jìn)：數(shù)據(jù)庫(kù)與應(yīng)用分離到兩臺(tái)服務(wù)器；多應(yīng)用服務(wù)器與單數(shù)據(jù)庫(kù)，涉及到session問(wèn)題（sticky、replication、集中存儲(chǔ)、cookie Based）；數(shù)據(jù)庫(kù)讀寫(xiě)分離、引入搜索引擎、引入數(shù)據(jù)和頁(yè)面緩存；引入分布式存儲(chǔ)系統(tǒng)；數(shù)據(jù)庫(kù)垂直拆分（一個(gè)業(yè)務(wù)的數(shù)據(jù)放到一個(gè)專用數(shù)據(jù)庫(kù)）、水平拆分（單個(gè)表放到兩個(gè)數(shù)據(jù)庫(kù)中）；拆分應(yīng)用，可以根據(jù)業(yè)務(wù)特性把應(yīng)用拆開(kāi)或者走服務(wù)化的路，亦即每個(gè)web系統(tǒng)通過(guò)不同的服務(wù)來(lái)完成特定的業(yè)務(wù)；引入消息中間件來(lái)完成拆分、服務(wù)化等目的

大型網(wǎng)站主要用到三類中間件：遠(yuǎn)過(guò)程調(diào)用和對(duì)象訪問(wèn)中間件（解決分布式下應(yīng)用互相訪問(wèn)的問(wèn)題）；消息中間件（解決應(yīng)用之間消息傳遞、解耦、異步的問(wèn)題）；數(shù)據(jù)訪問(wèn)中間件（解決數(shù)據(jù)庫(kù)訪問(wèn)共性的問(wèn)題）；

服務(wù)框架帶來(lái)的好處：結(jié)構(gòu)上，架構(gòu)更清晰，底層資源由服務(wù)層統(tǒng)一管理，也更利于提高效率；穩(wěn)定性上，一些散落在多個(gè)系統(tǒng)中的代碼變成了服務(wù)，由專門(mén)的團(tuán)隊(duì)統(tǒng)一維護(hù)，可以提高代碼質(zhì)量，另一方面由于核心穩(wěn)定，修改發(fā)布次數(shù)減少，也提高了穩(wěn)定性

通過(guò)消息中間件，業(yè)務(wù)系統(tǒng)不必知道有多少個(gè)其他業(yè)務(wù)系統(tǒng)需要了解某一項(xiàng)業(yè)務(wù)，只需要把消息發(fā)布給消息中間價(jià)，消息中間價(jià)負(fù)責(zé)把消息投遞給相關(guān)的其他業(yè)務(wù)系統(tǒng)，這樣每個(gè)業(yè)務(wù)系統(tǒng)都能專注自己本身的業(yè)務(wù)，不必維護(hù)臃腫的依賴關(guān)系，達(dá)到解耦和消息異步的目的

消息中間件要點(diǎn)：保證業(yè)務(wù)與發(fā)布消息的一致性，一般直接緊挨著寫(xiě)代碼就行，出錯(cuò)概率較小，但是對(duì)于要保證強(qiáng)一致的系統(tǒng)，需要采用類似于TCP三步握手的方式來(lái)保證；解決強(qiáng)依賴關(guān)系，盡量保證中間件的可靠性，最好達(dá)到和業(yè)務(wù)系統(tǒng)本身可靠性相同，從業(yè)務(wù)數(shù)據(jù)上能對(duì)消息進(jìn)行補(bǔ)發(fā)是最徹底的容災(zāi)手段；消息模型對(duì)消息接受的影響，Queue（點(diǎn)對(duì)點(diǎn)）和Topic（發(fā)布/訂閱）都不能完全適應(yīng)集群模式（發(fā)送接收方都是集群，要做到不重不漏、互不干擾），解決方法是結(jié)合兩者使用，集群之間用Topic模型，集群內(nèi)部用Queue模型；做到持久訂閱（除非顯示取消訂閱，否則即使訂閱者宕機(jī)了重啟后也應(yīng)該能收到所有消息）

服務(wù)框架，數(shù)據(jù)訪問(wèn)層，消息中間價(jià)背后的基礎(chǔ)產(chǎn)品就是軟負(fù)載和配置中心。軟負(fù)載中心的基本職責(zé)有兩個(gè)：聚合地址信息，將所有方面的地址形成列表供其他方使用；生命周期感知，對(duì)服務(wù)的上下線自動(dòng)感知并更新服務(wù)地址。軟負(fù)載中心管理非持久數(shù)據(jù)，集中配置管理中心管理持久數(shù)據(jù)

ESI將頁(yè)面分為相對(duì)靜態(tài)的內(nèi)容和動(dòng)態(tài)的內(nèi)容，如果整個(gè)頁(yè)面在服務(wù)端渲染的話，可以將相對(duì)靜態(tài)的內(nèi)容進(jìn)行緩存，而不是每次都全部重新渲染

在解決具體的問(wèn)題的時(shí)候，完全從頭寫(xiě)代碼還是基于開(kāi)源代碼去發(fā)展一定要慎重思考，如果場(chǎng)景類似那么以比較活躍的開(kāi)源產(chǎn)品為基礎(chǔ)并根據(jù)自己的場(chǎng)景定制會(huì)起到事半功倍的效果，如果沒(méi)有合適的那就需要從零開(kāi)始了

京東基礎(chǔ)架構(gòu)建設(shè)之路（全彩） (豆瓣) https://book.douban.com/subje...

本書(shū)主要作者是我們學(xué)校的一位師兄，前不久來(lái)學(xué)校辦了個(gè)報(bào)告，主要講了他在京東的基礎(chǔ)架構(gòu)經(jīng)驗(yàn)，介紹了新的架構(gòu)從無(wú)到有的過(guò)程，他們團(tuán)隊(duì)的技術(shù)現(xiàn)在一年能為京東省了很多億，這本書(shū)里凝聚了他們的技術(shù)精華，當(dāng)然值得我們?nèi)チ私庖幌驴?，而且?dāng)時(shí)的QA環(huán)節(jié)我提了個(gè)問(wèn)題，主辦方就送了這本書(shū)，師兄當(dāng)場(chǎng)親筆簽名，我就更應(yīng)該把這本書(shū)好好研究研究了。

亮點(diǎn)：

跳過(guò)虛擬化，直接容器化，結(jié)合團(tuán)隊(duì)的OpenStack經(jīng)驗(yàn)，選擇OpenStack+Docker的架構(gòu)，用OpenStack來(lái)管理調(diào)度Docker容器

建議鏡像和根目錄只保留只讀或者少量讀寫(xiě)文件，對(duì)于頻繁的讀寫(xiě)或者大量寫(xiě)的文件盡量用外掛的volume，規(guī)范業(yè)務(wù)對(duì)容器的使用行為

MySQL運(yùn)維自動(dòng)化包括：自動(dòng)備份，包括按時(shí)間點(diǎn)精準(zhǔn)恢復(fù)；自動(dòng)歷史數(shù)據(jù)轉(zhuǎn)移，將不再變更的歷史數(shù)據(jù)定期轉(zhuǎn)入大容量分布式存儲(chǔ)系統(tǒng)（如HBASE），控制MySQL數(shù)據(jù)量；自動(dòng)故障檢測(cè)與切換，采用Orchestrator作為管理工具；全面容器化，提升MySQL實(shí)例交付效率

在故障檢測(cè)和故障切換的方案中，比較容易想到的就是ZooKeeper的臨時(shí)節(jié)點(diǎn)探測(cè)不存活的服務(wù)，但是由于需要修改服務(wù)端代碼，不便于跨機(jī)房部署和連接數(shù)過(guò)多的問(wèn)題，京東自己開(kāi)發(fā)了分布式探測(cè)系統(tǒng)，為了避免臨時(shí)網(wǎng)絡(luò)不通導(dǎo)致的誤判，采取多個(gè)探測(cè)程序部署到機(jī)房的不通機(jī)架里，對(duì)實(shí)例進(jìn)行分布式投票，只要有一個(gè)探測(cè)存活就判斷為存活的，否則通知故障恢復(fù)程序進(jìn)行主從切換

容器中的數(shù)據(jù)最原始的是直接使用物理機(jī)上的volume來(lái)存儲(chǔ)，但是這樣容器數(shù)據(jù)就和物理機(jī)綁定了，無(wú)法實(shí)現(xiàn)數(shù)據(jù)的遷移也無(wú)法做到超大容量的存儲(chǔ)。京東的ContainerFS就是為容器而生的分布式文件系統(tǒng)，它的每個(gè)volume都可以被一個(gè)或者多個(gè)容器當(dāng)做本地文件直接使用，容器之間可以共享數(shù)據(jù)，支持彈性伸縮、線性擴(kuò)展

JMQ由于要支撐訂單、支付等要求對(duì)服務(wù)質(zhì)量要求極其嚴(yán)格的業(yè)務(wù)，所以必須保證在整個(gè)機(jī)房都失效的情況下依然能恢復(fù)數(shù)據(jù)，所以采取了一主一從且至少一個(gè)備份的架構(gòu)。主從分布在同一個(gè)數(shù)據(jù)中心，采取同步復(fù)制；備份在另一個(gè)數(shù)據(jù)中心，采取異步復(fù)制

分布式服務(wù)跟蹤系統(tǒng)CallGraph通過(guò)核心的調(diào)用鏈(依靠全局唯一的ID實(shí)現(xiàn))的概念能追蹤到一次調(diào)用的從請(qǐng)求發(fā)出到最底層系統(tǒng)的所有環(huán)節(jié)，便于排查問(wèn)題，而且具有低侵入性

全鏈路壓測(cè)通過(guò)全國(guó)各個(gè)公網(wǎng)節(jié)點(diǎn)發(fā)來(lái)的數(shù)據(jù)請(qǐng)求來(lái)較好地模擬真實(shí)用戶操作，同時(shí)壓測(cè)會(huì)有參數(shù)標(biāo)識(shí)，進(jìn)行真實(shí)流量與測(cè)試流量的隔離，避免污染生產(chǎn)數(shù)據(jù)

大型互聯(lián)網(wǎng)公司的數(shù)據(jù)中心架構(gòu)一般都會(huì)經(jīng)歷單機(jī)房，同城雙機(jī)房，異地災(zāi)備，最后是異地多活的各個(gè)階段。京東目前有三大數(shù)據(jù)中心，每個(gè)中心都能承擔(dān)讀寫(xiě)業(yè)務(wù)（這就是異地多活），依據(jù)GLSB和HTTPDNS和全國(guó)網(wǎng)絡(luò)質(zhì)量檢測(cè)數(shù)據(jù)來(lái)動(dòng)態(tài)優(yōu)化用戶到某個(gè)具體中心獲得服務(wù)，中心之間用專線打通保證數(shù)據(jù)秒級(jí)同步提供低延遲數(shù)據(jù)最終一致性保障

本書(shū)雖然很薄，但是講述的知識(shí)平常我們可能都用不到（不是誰(shuí)都有機(jī)會(huì)接觸這么大的規(guī)模的集群管理），看的時(shí)候要想完全吸收還是有些費(fèi)勁，還得在以后的實(shí)踐中加以琢磨才行。

Docker進(jìn)階與實(shí)戰(zhàn) (豆瓣) https://book.douban.com/subje...

第一本docker書(shū) 為我們?nèi)腴T(mén)docker提供了很好的途徑，這本書(shū)為我們提供了深入了解整個(gè)docker技術(shù)棧所需要的更多的知識(shí)，比如關(guān)鍵技術(shù)原理，高級(jí)技巧如安全、測(cè)試、集群管理等等。這兩本書(shū)有重疊，但是后者對(duì)前者有許多的補(bǔ)充，利于我們更好的使用、更好的理解docker。

亮點(diǎn)：

Docker并沒(méi)有傳統(tǒng)虛擬化中的Hypervisor層，使用輕量級(jí)虛擬化技術(shù)，基于Cgroup和Namespace等內(nèi)核容器技術(shù)，與內(nèi)核深度融合，性能與物理機(jī)非常接近。通信上，Docker不與內(nèi)核直接通信，而是通過(guò)LibContainer。libContainer是真正意義上的容器引擎，通過(guò)clone系統(tǒng)調(diào)用直接創(chuàng)建容器（一個(gè)新的子進(jìn)程），通過(guò)pivot_root進(jìn)入容器（新的rootfs），通過(guò)cgroupfs控制資源，Docker本身更側(cè)重處理更上層的業(yè)務(wù)。

Docker主要工作是在LXC（linuxContainer亦即linux內(nèi)核容器技術(shù)）的基礎(chǔ)上提供了一些更高級(jí)的控制工具，包括：定義鏡像格式，包含所有程序和依賴，使得鏡像可以跨主機(jī)部署，實(shí)現(xiàn)了進(jìn)程沙盒，同時(shí)保證程序及其依賴環(huán)境的一致性；提供自動(dòng)構(gòu)建工具，使得當(dāng)前機(jī)器的配置不會(huì)影響鏡像構(gòu)建過(guò)程；提供了類似git的版本管理功能，支持鏡像版本追蹤、校驗(yàn)、回退等功能；通過(guò)鏡像分層實(shí)現(xiàn)組件重用，減小鏡像大小，加快構(gòu)建速度；工具生態(tài)鏈......

虛擬機(jī)是硬件級(jí)別的虛擬化，利用VT-x、AMD-V等硬件虛擬化技術(shù)通過(guò)Hypervisor來(lái)實(shí)現(xiàn)對(duì)資源的徹底隔離；容器是操作系統(tǒng)級(jí)別的虛擬化，利用內(nèi)核的Cgroup和Namespace等軟件實(shí)現(xiàn)的特性實(shí)現(xiàn)來(lái)實(shí)現(xiàn)進(jìn)程隔離，Docker容器與主機(jī)共享操作系統(tǒng)內(nèi)核，不同容器可以共享部分資源，因此容器更加輕量級(jí)，資源消耗更少，啟動(dòng)更快。而虛擬機(jī)獨(dú)占自己的資源，各個(gè)虛擬機(jī)幾乎完全獨(dú)立，不存在共享，消耗更多資源，啟動(dòng)也慢

容器技術(shù)是一種操作系統(tǒng)級(jí)別的虛擬化技術(shù)（還有硬件虛擬化、半虛擬化等技術(shù)），已經(jīng)集成進(jìn)linux內(nèi)核，是內(nèi)核提供的原生特性，主要包含Namespace（主要做訪問(wèn)隔離，針對(duì)一類資源進(jìn)行抽象，并將其封裝在一起供容器使用）和Cgroup（control group，主要做資源控制，將一組進(jìn)程放進(jìn)一個(gè)控制組，給這個(gè)控制組分配指定可用的資源，其原生接口由cgroupfs提供）。但是光有這兩個(gè)還不夠，還需要rootfs(文件系統(tǒng)隔離)和容器引擎（生命周期控制）

Docker引入聯(lián)合掛載技術(shù)（把多個(gè)目錄掛載到同一目錄，對(duì)外呈現(xiàn)這些目錄的聯(lián)合）使得鏡像分層成為可能，使用git式的管理方式使得基礎(chǔ)鏡像的重用成為可能

如果你在尋找一個(gè)清晰、簡(jiǎn)單、低耦合、無(wú)狀態(tài)、面向資源的API設(shè)計(jì)方式，那么RESTFul API就是一種不錯(cuò)的選擇，它充分利用了HTTP本身的語(yǔ)義，使你的API更易用更具有擴(kuò)展性，同時(shí)優(yōu)雅的展示你的資源。Docker API 就是一種 RESTFul API

Cgroup對(duì)系統(tǒng)資源的限制已經(jīng)比較完善了，但是Namespace的隔離還不算很好，比如procfs的很多接口都沒(méi)隔離，可以通過(guò)procfs可以讀取和修改宿主系統(tǒng)的相關(guān)信息，所以procfs是以只讀方式掛載的，還有syslog也是沒(méi)隔離的。Namespace的隔離不完善，也不太可能完善，這是共享內(nèi)核固有的缺陷。有許多安全策略被用來(lái)保護(hù)系統(tǒng)，比如Cgroup限制、容器運(yùn)行在虛擬機(jī)中、鏡像簽名、日志審計(jì)、監(jiān)控、文件保護(hù)

在制作鏡像的時(shí)候，源碼導(dǎo)入有兩種策略：靜態(tài)導(dǎo)入（使用COPY命令直接把代碼放入鏡像）；動(dòng)態(tài)導(dǎo)入（使用VOLUME命令把代碼文件動(dòng)態(tài)掛載到容器）。建議使用兩個(gè)dockerfile，一個(gè)開(kāi)發(fā)版本（dev）用動(dòng)態(tài)掛載，便于隨時(shí)修改代碼，一個(gè)發(fā)布版本用靜態(tài)導(dǎo)入，便于減少依賴、處處運(yùn)行

作者還講述了怎么參與到docker的開(kāi)發(fā)和維護(hù)的過(guò)程中，如果我們?cè)谑褂眠^(guò)程中遇上了問(wèn)題，去看看源碼和社區(qū)也是不錯(cuò)的，說(shuō)不定就能解決

雖然只過(guò)去了1年多，但是書(shū)中已經(jīng)有內(nèi)容過(guò)時(shí)了，比如不要再安裝 docker.io 或者 docker-engine ，而是使用docker-ce （免費(fèi)版）或者 ee (企業(yè)版)。而且，如今 Docker-Compose、Swarm 已經(jīng)比較成熟了，完全可以用在生產(chǎn)環(huán)境中，當(dāng)然，（超）大規(guī)模的部署最終都得按照自己的業(yè)務(wù)情況來(lái)造輪子，完全依靠開(kāi)源的肯定是不行的，這樣是上面那本書(shū)的作者提到過(guò)的觀點(diǎn)。