摘要：后端好書閱讀與推薦系列文章后端好書閱讀與推薦后端好書閱讀與推薦續后端好書閱讀與推薦續二后端好書閱讀與推薦續三這里依然記錄一下每本書的亮點與自己讀書心得和體會，分享并求拍磚。然后又請求封鎖，當釋放了上的封鎖之后，系統又批準了的請求一直等待。

后端好書閱讀與推薦系列文章：
后端好書閱讀與推薦
后端好書閱讀與推薦（續）
后端好書閱讀與推薦（續二）
后端好書閱讀與推薦（續三）

這里依然記錄一下每本書的亮點與自己讀書心得和體會，分享并求拍磚。

實戰Java高并發程序設計 (豆瓣) https://book.douban.com/subje...

這本書是國產書籍里面質量較高的一本了（很多國產書都是東拼西湊或者敷衍了事），作者從實際出發，結合理論，講的很有邏輯，而且還有很多形象的手繪，和那本Java并發編程實戰相比更新一些，讀起來也更容易一些。

亮點：

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

同步異步，阻塞非阻塞，并行并發，這幾個概念估計很多人都混亂了很久，和作者的觀點稍微有點出入，我這里總結一下：同步異步的區別關鍵在于A對B請求發出后,如果A要等待B的結果那就是同步，如果A直接返回不需要B的結果或者等待B完成后再通知就是異步；阻塞強調的是A請求B過后不能做其它事，只能干等著（自旋或者休眠），非阻塞指的是A在等B的過程中可以做其它事；并行是真正意義的的多個任務同時執行，并發可能是并行，也可能只是多個任務交替執行，但是切換的很快，給我們造成了并行的“假象”，真實的并行只可能出現在多核cpu上

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

并行對于效率的提升主要取決于業務中串行代碼的比例和CPU數量，CPU數量越多，串行化代碼比例越少，那么多線程的優化方式效果越好

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

類可以通過繼承Thread，重寫run方法來實現多線程，但考慮到Java是單繼承的，繼承是一種很寶貴的資源，所以類應該實現Runable接口并重寫run方法，并把自己作為構造參數傳給Thread類來實現多線程，這種做法也符合Effective Java里面提到的工作單元（Runable）與執行機制（Thread）分離的概念

加鎖一定要注意加正確，主要有三種：指定加鎖對象，獲得該對象的鎖才能進入同步區；作用于實例方法，鎖加在當前實例上；作用于靜態方法，鎖加在當前類上。而且要注意多線程的鎖一定要是真正的加在同一個對象上，比如

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

就不正確，因為 Integer 是不變類，在執行++運算的時候 實際上是創建了新類，所以那個同步塊實際上指向了不同的對象，自然不會正確 。事實上這段代碼 在 IDEA 里面他會提示你 synchronized 加在了非final變量上，都可能產生非預期結果。

java 內置的線程池非常強大：newSingleThreadExecutor，newFixedThreadPool，newCachedThreadPool，newScheduledThreadPool等等，其核心都是ThreadPoolExecutor實現的，不過是參數不同。而ThreadPoolExecutor又是可以高度定制的，threadFactory，handler 都可以自定義，實現自己的線程工廠，拒絕策略等。ThreadPoolExecutor可以擴展來實現更豐富的功能，例如監聽所有任務的開始結束時間，避免線程池“吃掉異常”。

作者研究了ConcurrentLinkedQueue的源碼，發現不用鎖而是用CAS來實現多線程安全，代碼復雜度高了很多，但是性能卻高了很多；其實凡事有得必有失，就像Node一樣，異步帶來的性能提升是巨大的，但是代碼的編寫難度也提升了很多。此外作者還分析了java.util.concurrent里面其他的大量的數據結構，如CopyOnWriteArrayList，BlockingQueue，SkipList。這些數據結構都是Java設計者們精心設計的多線程安全數據結構，比傳統的多線程安全數據結構性能提升很多

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

作者總結了一系列多線程相關的設計模式，比如單例模式、不變模式、生產者消費者、介紹了用框架實現的無鎖生產者消費者、future模式實現的異步操作、并行流水線和搜索排序計算等等，這些都是我們業務中常常用到的模式，總結一下，以后運用更加自如

為了體會到本書的點，我寫了一些代碼。另外AKKA部分我沒有看，因為沒有用過，即使看了也體會不到精髓，所以暫時先不了解了。

計算機網絡（第5版） (豆瓣) https://book.douban.com/subje...

這本書當年大二的時候是教材，沒意識到它的珍貴，本科畢業的時候居然拿去賣了，不過后來我又買了回來，好好的讀下來，感覺對整個計算機網絡都有了一個更清晰地概念。當然此書太厚，若非必要，不宜一一細讀，挑些重要的基礎概念（比如TCP/IP）和如今越來越重要的內容（比如CDN）細讀，其余看個大概即可。

亮點：

首先講了計算機網絡的重要性（郵件，電子商務，web，在線娛樂游戲，GPS）以及廣闊前景（IOT的萬物互聯，可穿戴計算機），事實上現在的人早就習慣了網絡的存在，反而不覺得它有那么重要，就像空氣一樣，但是一旦你把它的作用列出來你就會發現，它是如此的重要，試著想想，如果沒有網絡，現代社會怎么運轉？

為了降低網絡設計的復雜性，絕大多數網絡都組織成一個層次棧，每一層都構建于其下一層之上。這種分層的概念在計算機科學中廣泛存在，比如面向對象、ADT、信息隱藏等，其根本思想都是提供服務但是隱藏實現。這種分而治之的思想可被我們借鑒，用來簡化架構，邏輯解耦。比如 nginx 處理請求也是分了不同的階段，Java 里面的 servlet 也是一樣分階段處理的

數據鏈路層只關注幀（frame）從一個節點到另一個節點的傳輸，是點到點的，而網絡層的目的是采用數據報或者虛電路技術將數據包（package）從發送方傳輸至接收方，中間可能要經過很多點，是處理端到端數據傳輸的最底層，但仍然是點到點的（因為它必須關心發送方到接收方的中間節點），而傳輸層是真正的端到端，亦即發送接收方不必關心傳輸過程中有多少個節點，可以認為數據段（segment）是直接從發送方到接收方的。從另一方面來看，一個數據報在傳輸過程中，源/目的IP是不變的（除非NAT），但是源/目的MAC卻是一跳一跳地變化的

擁塞控制和流量控制有很大差異。前者指確保網絡能夠承載所有到達的流量，是一個全局問題；后者指發送方不會持續以超過接收方能力的速率傳輸數據，解決這兩個問題的最佳解法通常都是主機慢下來

網絡層與傳輸層提供的服務有些類似，那么為什么不用一層做完呢？答案就是傳輸層代碼主要運行在用戶主機上，網絡層主要運行在運營商的路由器上，對于網絡層，用戶自己有著真正的控制權，可以通過差錯控制、順序控制、流量控制等方式來獲得比網絡層（盡力而為的服務，無保證）更加可靠的服務；另一個方面，分層也是解耦的思想體現，只要實現了傳輸原語，就不必在乎網絡層的實現（以太網或者WiMAX）

簡單情況下，我發一包，你回一包，但是網絡不佳的情況下，要保證包傳輸到位就必須引入重傳機制，重傳機制一引入就必須考慮如何解決包重復接受的問題，所以限制了包生存周期（跳計數器），然后通過段序號、日時鐘、滑動窗口協議來丟棄已經接受的重復數據包，通過三步握手解決了初始序號獲得的問題。這一個出現問題、解決問題、出現新問題、解決新問題的反復的過程體現了協議設計者們的智慧和不屈不撓的毅力，非常值得我們學習

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

內容分發不同于通信任務，目標主機不重要，重要的是獲取了什么內容，獲取內容的代價。主要有兩個結構，CDN和P2P。CDN采用分發樹結構，擴展性很高，實現原理是DNS重定向；P2P把多臺計算機（對等節點）的資源集中起來，每臺計算機既可以作為服務器向其他計算機提供資源，也可以作為客戶端向其他計算機請求資源

本文最大特點就是故事性強，一環扣一環，引人入勝。

Netty實戰 (豆瓣) https://book.douban.com/subje...

Netty是網絡編程中不可不談的一個大作，也是許多成功的網絡應用的基礎設施，本書就從為什么是Netty，引導我們嘗試使用，并進行了細致的講解，為我們全面的剖析了Netyy這個龐大而精妙的框架，組織得很有條理。

但是要注意，看本書之前或者說學習Netty之前，務必要對Java IO、NIO、AIO以及Reactor和Proactor的概念有一定的了解，不然就是沒學會走先去學跑了。

亮點：

低級別的 API 不僅暴露了高級別直接使用的復雜性，而且引入了過分依賴于這項技術所造成的短板。因此，面向對象有一個基本原則：通過抽象來隱藏背后的復雜性。Netty提供了高層次的抽象來簡化TCP和UDP服務器的編程，但是你仍然可以使用底層地API。(David John Wheeler有一句名言“計算機科學中的任何問題都可以通過加上一層邏輯層來解決”，這個原則在計算機各技術領域被廣泛應用)

一個 Netty 的設計的主要目標是促進“關注點分離”：將你的業務邏輯從網絡基礎設施應用程序中分離

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

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

Netty提出的ByteBuf優于JDK原生的ByteBuffer因為：可以自定義緩沖類型（堆緩沖區，直接緩沖區，復合緩沖區），通過復合緩沖類型實現零拷貝；擴展性好，比如 StringBuilder；不需要調用 flip() 來切換讀/寫模式；讀取和寫入索引分開

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

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

本書中對于異步同步和阻塞非阻塞的觀念有些模糊，請見上面實戰Java高并發程序設計一節我的理解，讀者可以參考一下，自己取舍。事實上，Java的NIO不是異步的，AIO(或者說NIO2.0)才是，Netty基于NIO(嘗試過并拋棄了AIO)，通過自己的封裝，實現了從使用者角度看起來的異步。學習Netty還有一個好地方就是官方文檔。

分布式java應用 (豆瓣) https://book.douban.com/subje...

后端要搞得好，不上分布式肯定是不行的，因為寫個小網站你可以懂點 SSM 或者 Spring Boot 就行了，但是如果要想搭建一個（或者說成為構建過程的一份子）用戶成千上萬甚至百萬、千萬、上億的站點，那就必須要懂分布式了。這本書就可以當做學習分布式的入門書籍。

亮點：

實踐是最好的成長，發表是最好的記憶。這句話的確可以放在電腦上當桌面背景

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

網絡IO分三類。BIO：用戶線程在進行IO操作的時候進行系統調用，阻塞，只有讀到（寫入）了數據才釋放資源；NIO：同步非阻塞IO，用戶線程在發起IO操作之后可以立即返回，只有流可讀（可寫）操作系統才會通知用戶線程進行讀取（寫入），但是用戶線程需要不斷輪詢來請求數據，Linux采用epoll實現；AIO：用戶線程發起請求時，由操作系統來進行讀取（寫入），IO事件就緒的時候，操作系統會通知對應的用戶線程來處理，實現真正的異步IO，Windows下IOCP實現了AIO，Linux只有epoll實現模擬實現的AIO。同時，由于服務器的主力是Linux，所以AIO的用處目前不是特別廣

BIO對應的是一連接一線程，可以引入線程池來優化，但是一個操作系統線程數量終究有限，所以不可能支撐大量連接數；NIO對應的是一請求一線程，只有某個連接有讀寫事件時才為其生成一個線程來處理，只有連接數不多或者連接數多且都請求頻繁時才沒有優勢，但實際情況中，服務器通常會支持大量連接數，但是同時發送請求的連接不會太多，所以NIO應用比價廣泛；AIO對應一個有效請求一個線程，亦即OS處理IO完畢后再生成用戶線程處理，充分調用了OS參與，可以應對連接數多且操作頻繁的場景，如果Linux對AIO的支持更好，這個模型可能會流行起來

SOA亦即面向服務的架構，強調系統之間以標準服務的方式進行交互，各系統可以采用不同的語言、框架來實現，交互則全部采用服務來進行,目前SCA和ESB是主流標準，分別有Tuscany和Mule等常用框架實現

調優的步驟：衡量系統現狀，設定調優目標，尋找性能瓶頸，性能調優，衡量是否達標，反復進行前面三步直至達標。

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

除了上面提到的機房等硬件上的故障，應用軟件本身的故障也是高可用的大敵，所以要注意避免故障，及時發現并處理故障，具體包括：明確使用場景，做到最貼近場景的最簡單系統，或者分階段最簡單系統；設計可容錯系統，fail fast；系統可自我保護，對第三方依賴保持弱依賴，避免連鎖失效；建立分級報警系統和日志記錄與分析系統；注意總結故障分析便于下次快速利用，這也是架構即未來里面提到過的；按照業務拆分子系統......

構建可伸縮的系統關鍵在于水平伸縮，因為垂直伸縮是有限的（一臺機器的性能終究有限），而水平伸縮理論上是無限的（可以添加“無數”臺機器），水平伸縮通常通過SNA(share nothing architecture)實現，亦即應用系統之間不共享狀態，把狀態信息統一放入緩存或數據庫（可以是分布式）。文件系統的水平擴展思想也是類似的

本書可以當做入門書籍，但是書中真正關于分布式的內容似乎少了些，倒是Java基礎知識占據了很大篇幅，感覺有點不對題目，畢竟要看這些知識我可以看Java核心技術，Java并發編程實戰或者深入理解jvm啊，但是也可以用來復習一下，而且有許多實驗數據可供參考，還是可以的。

PS:我之前已經看了Netty了，所以書中關于Mina的部分，時間不夠我就跳著看了，時間夠還是可以了解一下的，兩者對比。

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

讀了上面一本分布式Java，不免對分布式系統想要有一個更全面、更系統的認識，那么這本書就是一本絕佳的書籍。

亮點：

資源共享是構建分布式系統的主要目；并發、缺乏全局時鐘、故障獨立性是其主要特征；處理其構件的異構性、開放性（允許增加或替換組件）、安全性（機密完整可用）、可伸縮性（用戶的負載增加時能正常運行的能力）、故障處理、組件并發性、透明性（分布式的組件對外展示為一個整體）、QoS（在傳輸數據時滿足要求的能力）等是其主要挑戰

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

中間件是一組計算機上的進程或對象，其目的是屏蔽異構性，亦即底層的通訊，交互，連接等復雜又通用的功能以服務的形式提供出來，分布式系統應用在交互時，直接使用中間件提供的高層編程抽象即可，實現了簡潔的分布式系統應用的通信和資源共享的支持

套接字（socket）是通信的抽象，無論是TCP還是UDP的方式，它提供了進程間通信的端點，必須和協議，主機地址（分為目的端與源端），端口（分為目的端與源端）綁定起來

RPC的概念代表著分布式計算的重大突破，使得分布式編程和傳統編程類似，實現了高級的透明性，這種相似性將傳統的過程調用模型擴展到分布式環境中，隱藏了底層分布式環境的重要細節部分，簡化了分布式開發

操作系統的任務是提供一個物理層（處理器，內存，硬盤等）之上的面向問題的抽象，例如給程序員提供文件和套接字而不是磁盤塊和原始網絡訪問。操作系統分為網絡操作系統（具有內置聯網功能，能自主管理自己的資源并網絡透明地訪問其它一些資源但是不能跨節點管理進程，也就是有多個系統映像）和分布式操作系統（用戶不必關心程序運行的地點和資源位置，能透明的將新的進程調度到合理的節點上，有單一的系統映像），后者幾乎沒有普遍應用的案例，因為中間件和網絡操作系統的結合就能很好的滿足用戶需求

最重要的兩種中間件風格：分布式對象（允許面向對象編程模型開發分布式系統，通信實體被表示成對象，通信使用RMI，但也可以使用其他的比如分布式事件）；組件（基于對象方法的自然演化，主要克服其限制：隱式依賴，編程復雜性，缺少關注點分離支持，無部署支持）

面向服務的體系結構（SOA）是一套設計原則，分布式系統用松耦合的服務集開發，服務能被動態發現，能互相通信并通過編排進行協調從而提供更強的服務。可以基于分布式對象或者組件來實現，但實際中主要通過web服務實現，主要是因為web服務內在的松耦合性（比如不管子系統是CORBA還是.NET，只要用web服務暴露接口，就能輕易實現集成）

分布式是一門結合計算機網絡與操作系統等多種門類的交叉學科，所以這本書也包含了許多這些方面的知識，不失為一種復習的方式。

大型網站系統與Java中間件開發實踐 (豆瓣) https://book.douban.com/subje...

上面的分布式Java是一本很基礎的入門書籍，這本書算是一本更加全面和仔細的書籍，把它沒講到的部分都講了一些，而且更注重中間件（支撐大型網站關鍵、必要的技術之一）的講解。

亮點：

分布式系統中的控制節點協調系統之間的協作，可以用：硬件均衡負載設備（昂貴）、軟件方式的透明代理（增加流量、易出現單點失效）、采用名稱服務的直連請求（不易單點失效、流量少）、采用規則服務器的直連調用、采用master+worker的架構

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

大型網站主要用到三類中間件：遠過程調用和對象訪問中間件（解決分布式下應用互相訪問的問題）；消息中間件（解決應用之間消息傳遞、解耦、異步的問題）；數據訪問中間件（解決數據庫訪問共性的問題）；

服務框架帶來的好處：結構上，架構更清晰，底層資源由服務層統一管理，也更利于提高效率；穩定性上，一些散落在多個系統中的代碼變成了服務，由專門的團隊統一維護，可以提高代碼質量，另一方面由于核心穩定，修改發布次數減少，也提高了穩定性

通過消息中間件，業務系統不必知道有多少個其他業務系統需要了解某一項業務，只需要把消息發布給消息中間價，消息中間價負責把消息投遞給相關的其他業務系統，這樣每個業務系統都能專注自己本身的業務，不必維護臃腫的依賴關系，達到解耦和消息異步的目的

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

服務框架，數據訪問層，消息中間價背后的基礎產品就是軟負載和配置中心。軟負載中心的基本職責有兩個：聚合地址信息，將所有方面的地址形成列表供其他方使用；生命周期感知，對服務的上下線自動感知并更新服務地址。軟負載中心管理非持久數據，集中配置管理中心管理持久數據

ESI將頁面分為相對靜態的內容和動態的內容，如果整個頁面在服務端渲染的話，可以將相對靜態的內容進行緩存，而不是每次都全部重新渲染

在解決具體的問題的時候，完全從頭寫代碼還是基于開源代碼去發展一定要慎重思考，如果場景類似那么以比較活躍的開源產品為基礎并根據自己的場景定制會起到事半功倍的效果，如果沒有合適的那就需要從零開始了

京東基礎架構建設之路（全彩） (豆瓣) https://book.douban.com/subje...

本書主要作者是我們學校的一位師兄，前不久來學校辦了個報告，主要講了他在京東的基礎架構經驗，介紹了新的架構從無到有的過程，他們團隊的技術現在一年能為京東省了很多億，這本書里凝聚了他們的技術精華，當然值得我們去了解一下咯，而且當時的QA環節我提了個問題，主辦方就送了這本書，師兄當場親筆簽名，我就更應該把這本書好好研究研究了。

亮點：

跳過虛擬化，直接容器化，結合團隊的OpenStack經驗，選擇OpenStack+Docker的架構，用OpenStack來管理調度Docker容器

建議鏡像和根目錄只保留只讀或者少量讀寫文件，對于頻繁的讀寫或者大量寫的文件盡量用外掛的volume，規范業務對容器的使用行為

MySQL運維自動化包括：自動備份，包括按時間點精準恢復；自動歷史數據轉移，將不再變更的歷史數據定期轉入大容量分布式存儲系統（如HBASE），控制MySQL數據量；自動故障檢測與切換，采用Orchestrator作為管理工具；全面容器化，提升MySQL實例交付效率

在故障檢測和故障切換的方案中，比較容易想到的就是ZooKeeper的臨時節點探測不存活的服務，但是由于需要修改服務端代碼，不便于跨機房部署和連接數過多的問題，京東自己開發了分布式探測系統，為了避免臨時網絡不通導致的誤判，采取多個探測程序部署到機房的不通機架里，對實例進行分布式投票，只要有一個探測存活就判斷為存活的，否則通知故障恢復程序進行主從切換

容器中的數據最原始的是直接使用物理機上的volume來存儲，但是這樣容器數據就和物理機綁定了，無法實現數據的遷移也無法做到超大容量的存儲。京東的ContainerFS就是為容器而生的分布式文件系統，它的每個volume都可以被一個或者多個容器當做本地文件直接使用，容器之間可以共享數據，支持彈性伸縮、線性擴展

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

分布式服務跟蹤系統CallGraph通過核心的調用鏈(依靠全局唯一的ID實現)的概念能追蹤到一次調用的從請求發出到最底層系統的所有環節，便于排查問題，而且具有低侵入性

全鏈路壓測通過全國各個公網節點發來的數據請求來較好地模擬真實用戶操作，同時壓測會有參數標識，進行真實流量與測試流量的隔離，避免污染生產數據

大型互聯網公司的數據中心架構一般都會經歷單機房，同城雙機房，異地災備，最后是異地多活的各個階段。京東目前有三大數據中心，每個中心都能承擔讀寫業務（這就是異地多活），依據GLSB和HTTPDNS和全國網絡質量檢測數據來動態優化用戶到某個具體中心獲得服務，中心之間用專線打通保證數據秒級同步提供低延遲數據最終一致性保障

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

Docker進階與實戰 (豆瓣) https://book.douban.com/subje...

第一本docker書 為我們入門docker提供了很好的途徑，這本書為我們提供了深入了解整個docker技術棧所需要的更多的知識，比如關鍵技術原理，高級技巧如安全、測試、集群管理等等。這兩本書有重疊，但是后者對前者有許多的補充，利于我們更好的使用、更好的理解docker。

亮點：

Docker并沒有傳統虛擬化中的Hypervisor層，使用輕量級虛擬化技術，基于Cgroup和Namespace等內核容器技術，與內核深度融合，性能與物理機非常接近。通信上，Docker不與內核直接通信，而是通過LibContainer。libContainer是真正意義上的容器引擎，通過clone系統調用直接創建容器（一個新的子進程），通過pivot_root進入容器（新的rootfs），通過cgroupfs控制資源，Docker本身更側重處理更上層的業務。

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

虛擬機是硬件級別的虛擬化，利用VT-x、AMD-V等硬件虛擬化技術通過Hypervisor來實現對資源的徹底隔離；容器是操作系統級別的虛擬化，利用內核的Cgroup和Namespace等軟件實現的特性實現來實現進程隔離，Docker容器與主機共享操作系統內核，不同容器可以共享部分資源，因此容器更加輕量級，資源消耗更少，啟動更快。而虛擬機獨占自己的資源，各個虛擬機幾乎完全獨立，不存在共享，消耗更多資源，啟動也慢

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

Docker引入聯合掛載技術（把多個目錄掛載到同一目錄，對外呈現這些目錄的聯合）使得鏡像分層成為可能，使用git式的管理方式使得基礎鏡像的重用成為可能

如果你在尋找一個清晰、簡單、低耦合、無狀態、面向資源的API設計方式，那么RESTFul API就是一種不錯的選擇，它充分利用了HTTP本身的語義，使你的API更易用更具有擴展性，同時優雅的展示你的資源。Docker API 就是一種 RESTFul API

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

在制作鏡像的時候，源碼導入有兩種策略：靜態導入（使用COPY命令直接把代碼放入鏡像）；動態導入（使用VOLUME命令把代碼文件動態掛載到容器）。建議使用兩個dockerfile，一個開發版本（dev）用動態掛載，便于隨時修改代碼，一個發布版本用靜態導入，便于減少依賴、處處運行

作者還講述了怎么參與到docker的開發和維護的過程中，如果我們在使用過程中遇上了問題，去看看源碼和社區也是不錯的，說不定就能解決

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