Java多線程與Socket：實戰微服務框架 ( 簡體 字) |
| 作者：龐永華 | 類別：1. -> 程式設計 -> JAVA -> Java |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 50825
詢問書籍請說出此書號！【缺書】
NT售價： 495 元 |
| 出版日：3/1/2019 |
| 頁數：452 |
| 光碟數：0 |
|
站長推薦：  |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121360350 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：本書適合有一定Java基礎且有志成為架構師的開發人員閱讀。一個優秀的架構師必須要有扎實的編程功底和豐富的理論知識，不光要能完成架構設計，更要有能力將設計轉換為實際的產品。不會寫代碼、紙上談兵的“架構師”設計出來的“架構”是靠不住的。因此，本書將從相關的基礎知識講起，通過剖析一個小巧精練的微服務框架的核心，介紹這些基礎知識是如何在實踐中被靈活、適當地運用的。
本書不是關于微服務的理論書籍，也不是某個微服務框架的使用手冊。微服務涉及的范圍很廣，我們很難在一本書里講清楚微服務的方方面面。
目前相關的主流框架是Spring Cloud和Dubbo。雖然Spring Cloud和Dubbo都很強大，但這個世界上從來沒有最好，只有更好，因此我們永遠不要停下自己創新的腳步。我們依然可以有自己的想法，并勇于嘗試、付諸實踐。事實上Spring Cloud和Dubbo都存在各自的問題和不足。我們通過對它們的學習和研究，站在巨人的肩膀上，吸取它們的優點再加以創新，是完全有可能做到青出于藍而勝于藍的。
在正式開始之前，讓我們先了解一下微服務的發展背景。
面向服務的架構
1996年，Gartner公司首次提出了面向服務的架構（Service-Oriented Architecture，SOA）這一軟件設計思想。其核心理念是將一個個的業務功能包裝成一個個的標準服務，為這些服務定義良好的接口和服務契約，以便在需要的時候可以重用和水平伸縮。通過將這些服務進行組合和編排，可以創建新的業務流程，或者靈活地修改現有流程，以適應不斷變化的業務需求，讓我們的系統功能更豐富、結構更靈活、更易于擴展。同時，讓系統規模能夠根據需要彈性伸縮，最大限度地利用現有資產，提高效率，降低成本。總之，要使我們的系統能更靈活、更快地響應不斷變化的需求。
不過，受到當時計算機水平的限制，面向服務的架構思想在誕生之初，并沒有得到廣泛的關注和發展。隨著軟件系統的規模越來越大、越來越復雜，軟件系統的架構也在不斷地演進，面向服務的架構開始受到人們的關注和認可。目前，大型軟件系統的服務端架構多數都是面向服務的架構，或者正在朝這一架構遷移。
要明確的是，面向服務的架構中的“服務”雖然也包括系統對外提供的服務，但更多的是指系統內部的各個“模塊”或“組件”的“服務化”，以及模塊（服務）之間的相互調用與協同。它是“分布式”與“服務化”兩個技術發展趨勢合流的產物。
分布式系統
所謂的“分布式”是相對于“集中式”的一種應用系統內部組織結構。相對于傳統的集中式系統（單機應用系統和集群式應用系統都屬于集中式系統），分布式系統將原本集中在一個服務端應用中的功能模塊拆分出來，分為多個系統組件或應用，分散部署在多個服務器上，并通過網絡將它們連接起來協同工作。而客戶端系統感覺不到服務端系統內部的這種變化，仍然和原來調用集中式系統一樣。
分布式設計使得原本集中在單個服務器上進行的計算或存儲需求被分散到了多個服務器上，從而降低了我們對單一服務器的性能要求。這樣就讓我們能用相對廉價的PC服務器代替昂貴的傳統服務器，并通過水平擴容的方式繼續提升系統的處理能力。
分布式系統并沒有約定其內部的各個組件或應用之間應采用什么樣的形式來實現彼此通信。早期人們使用DCOM、CORBA等技術實現組件的暴露和遠程訪問。這便是分布式系統的早期形態。但是這些技術比較復雜且十分笨重，只在大型系統和企業級應用中被使用。盡管之后又出現了COM+、RMI、EJB等技術，但仍然比較笨重和難用。
服務化
早期的系統都是相互獨立的。受限于計算機的處理能力，其規模都比較小。比如，財務系統和人力資源管理系統分別是兩個不同的系統。它們可能由不同的軟件廠商，采用不同的開發語言和技術開發，并運行在各式各樣的操作系統和硬件設備上。隨著企業發展的需要，人們試著在兩個系統間建立通信，嘗試讓它們彼此協同。雙方的通信方式和協議由廠商之間彼此協商來制定，開發起來成本很高。各個廠商都試圖制定自己的通信技術標準和協議，并力爭成為業內標準。顯然，如果所有廠商都遵循同一套技術標準和通信協議，就能大大地降低開發成本，讓各個系統彼此更容易地互聯互通。
隨著基于Web的應用的普及，以及XML技術的出現和成熟，出現了基于HTTP、XML的服務暴露與遠程訪問方式，這就是Web Services。但Web Services的協議和實現方式很多，技術標準也多種多樣。企業內部各系統之間的互聯互通仍然比較麻煩。于是，企業服務總線（Enterprise Service Bus，ESB）系統被設計來實現各系統之間的服務接口適配和管理，以便各系統能夠用自己熟悉的技術、標準和規范來相互調用彼此的服務。隨著時間的推移，簡單對象訪問協議（Simple Object Access Protocol，SOAP）、Web服務描述語言（Web Services Description Language，WSDL），以及通用描述、發現與集成服務（Universal Description，Discovery and Integration，UDDI）協議逐漸成為主流的Web Services標準和規范。
后來，隨著互聯網技術的發展，基于HTTP RESTful的輕量級Web Services逐漸取代了基于SOAP的傳統Web Services技術成為主流。由于HTTP RESTful服務暴露和調用開銷比SOAP小很多，且速度更快，這就使得我們可在大型系統內部也大量使用，以作為各子系統之間，尤其是異構子系統之間最佳的通信形式。
面向服務
當我們將系統中的模塊或組件服務化，代替COM+、RMI、EJB等分布式領域的組件通信技術后，系統架構就轉變為面向服務的架構。當然，分布式系統中的很多組件是難以服務化的。不是所有的模塊和組件都適合服務化。比如，有些模塊的調用頻率很高，接口復雜，轉變成服務后，訪問性能可能無法滿足設計要求。又比如，有些模塊與模塊之間的耦合度較高，如果不進行重構來解耦，那么是無法單獨作為服務暴露的。還有些模塊的重用度不高或調用頻率過低，沒有服務化的必要。在對系統進行SOA改造時，一定要分析清楚。
綜上所述，面向服務的架構是分布式架構中的一種。面向服務的架構一定是分布式架構，但分布式架構不一定面向服務。能夠對外提供服務的系統并不一定是面向服務的架構，面向服務架構的系統也不一定對外暴露服務。
什么是微服務
顧名思義，微服務就是指粒度較小的服務。這意味著我們要對現有的分布式系統進行進一步的拆分，將其劃分為更多、更小的服務來進行設計或重構。“微服務”的概念源于2014年3月Martin Fowler所寫的一篇文章Microservices。它擴大了面向服務架構中“服務”的概念。不再局限于系統與系統之間的接口調用，也不局限于某種具體的服務形式。系統中凡是可被復用的功能模塊都可以被“服務化”，轉變為“服務”。這些服務可以對外暴露，也可能僅限于在系統內部使用。這對面向服務架構提出了更高的設計要求。由于服務數量更多、粒度更小，因此管控難度會更大，對性能的要求也更高。
那么，我們為什么要將系統拆分成一個個的微服務呢？
微服務的好處
微服務有如下好處。
1. 方便編排和重用
當我們在開發新功能時，可能需要復用現有的模塊。以往我們需要將可復用的代碼放到jar包中，并在工程中引用。這容易導致依賴關系的復雜和混亂，而且每次都需要重新編譯和打包，也很不方便，更不要說對現有的模塊進行編排和組合了。將這些模塊轉變為服務后，我們只需要調用這些服務，而不需要關心服務的具體實現、依賴和提供者。同時還能夠使用服務編排工具將現有服務編排到新的流程中，組合成為新的服務，或者修改現有的服務流程。
2. 方便開發和調試
每一個微服務專注于單一功能，并通過定義良好的接口來清晰表述它的邊界。服務越小，復雜度越低，開發起來也就越簡單、越快，調試和維護也更方便。這就縮短了服務開發和修改的周期，使程序能更快地迭代。
3. 方便部署與更新
微服務一般隨應用部署。一個系統中有若干可獨立運行的應用，每個應用通常提供了一個或多個微服務。當某個微服務發生變更時，只需編譯和部署相應的應用，而不用重新編譯和部署整個系統。這使得部署發布更加高效，同時也縮小了每次變更和部署的影響范圍，降低了風險。
4. 系統集成更方便
使用不同語言、不同技術棧開發的服務，只要按照統一的協議暴露，比如統一使用HTTP RESTful形式暴露為服務，就可以方便地相互調用和協同。這使得我們能夠將各類系統輕松集成在一起。
5. 提高容錯能力
某一模塊或組件發生故障時，容易導致整個系統變得不可用。比如，某個模塊的內存泄漏可能導致整個應用因內存不足而崩潰。由于微服務架構中的服務粒度很小，且相互隔離，因此即使某個服務出現問題，處理起來也相對容易，影響范圍有限。微服務系統可以通過失敗重試、失敗轉移、服務降級等機制實現容錯處理，避免問題擴大，微服務系統甚至能自動從故障中恢復（自愈）。
6. 方便橫向擴展
當某個服務出現性能瓶頸時，我們只需要增加此服務所屬應用的部署數量，而不用增加整個系統的部署。而且，由于不同的服務對資源的要求不同，我們可以根據實際情況靈活地對服務進行混合部署，以便更合理地分配服務器資源。
RPC與微服務
微服務環境下服務的粒度更細，調用頻率也更高，一般用于系統內部的面向服務架構，而不是直接對外提供服務。在這種場景下，Web Services的跨語言、跨平臺優勢不再那么重要，Web Services的易用性問題和性能問題反而變得突出起來。
隨著Socket、多線程、序列化等技術的發展，涌現出了很多優秀的RPC框架，以代替傳統的RMI等技術。與Web Services偏向對外暴露服務與遠程調用不同，RPC框架專注于細粒度（方法級別）的、系統內部模塊或組件之間的相互調用與協同。由于多數RPC框架采用Socket長連接和二進制協議，因此其性能比基于HTTP協議的Web Services要高幾個數量級。再加上，RPC可以做到對應用的零侵入，因此其在易用性方面也要強得多。
由于RPC在易用性和性能方面優勢明顯，因此在系統內部，使用遠程方法調用（RPC）形式暴露和引用服務要比Web Services更合適。對外暴露和引用服務時（跨系統調用）再采用Web Services的形式。當然，如果對性能要求不高，也可以一律采用HTTP RESTful方式。有些RPC框架，如gRPC、Thrift，支持跨語言調用，也可以被用于跨系統的服務調用，對外提供服務。由于我們總是能輕松地將系統內部的服務以Web Services 形式對外暴露，因此，建議優先考慮內部服務調用的性能和易用性，選用RPC作為微服務的核心和基礎。
微服務框架
在微服務領域，比較流行的幾個關鍵詞是Spring Cloud、Dubbo、Docker、Kubernetes、Service Mesh。其中Spring Cloud是目前最接近完整微服務框架的產品。它是一個基于Java語言的微服務開發框架，面向的是有Spring開發經驗的Java語言開發者。但它真的只是一個“框架”性的東西，還需要集成一系列的第三方組件才能發揮作用。Netflix公司為其開發了一套組件，并成為Spring Cloud的推薦或默認實現。
Dubbo是阿里巴巴開源的分布式服務框架。其本質上是一個高性能二進制RPC框架，致力于提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其功能主要包括高性能NIO通信及多協議集成、服務動態尋址與路由、軟負載均衡與容錯、依賴分析與服務降級等。可以看出Dubbo有著自己的多層架構體系，涵蓋了Spring Cloud中的一部分內容。它雖然算不上一個完整的微服務框架，但卻比較實用，未來可能會支持與Spring Cloud的集成，融入Spring Cloud生態圈。
Docker是一個應用容器引擎，允許我們將要部署的應用和運行時環境打包成一個鏡像文件，部署到Docker容器中。Rocket 是與之類似的另一款應用容器引擎。
Kubernetes是Google開源的一個自動化容器操作平臺，簡稱K8S。它可以編排并自動執行容器（如Docker、Rocket）的部署、復制等操作，隨時擴展或收縮容器規模，并提供容器間的負載均衡，監控容器的狀態，自動升級或替換容器。由此可見，Kubernetes不是面向開發者的平臺，而是面向IT基礎設施運維人員的。
Spring Cloud和Dubbo同屬于PaaS（Platform as a Service，平臺即服務），而Docker和Kubernetes同屬于IaaS（Infrastructure as a Service，基礎設施即服務）。由于微服務平臺中服務的載體是應用，而環境中要部署的應用實例眾多，因此使用Docker和Kubernetes，通過整合Spring Cloud、Docker和Kubernetes，可以構建更加完整和強大的微服務架構程序。
不過，應用的部署并不一定需要Docker這樣的容器，Linux自身就支持進程間的資源隔離。通過一個簡單應用代理服務（Agent）加Shell腳本即可實現應用的部署。本書所介紹的示例微服務系統正是使用了這一方式，效果也很好。使用這種方式可以實現應用的部署、啟停、更新、JVM監控、資源監控等功能，擴展也更方便。
Service Mesh則還是一個比較新的概念。它可將微服務間的調用、限流、熔斷和監控等功能需求提煉為一個通用的中間層基礎服務，甚至下沉到基礎設施層。Spring Cloud、Kubernetes和Istio似乎都正在朝這一方向努力。
本書作為示例所介紹的mac-rpc和Dubbo非常相似，其本質是一個內置服務注冊與發現功能的高性能RPC框架，是微服務系統的核心和基礎。其特點是全異步和高性能，小巧精練，但開放、靈活，可自由定制和擴展。mac-rpc目前已經較為成熟和穩定，其最新版本是1.0.3。它與服務治理系統、流程引擎、自動化部署、消息、緩存等子系統和組件集成，可以構建起完整的微服務系統。讀者若想了解更多關于mac與boar系列的開源項目。 |
內容簡介：本書從實戰角度出發，首先介紹Java多線程、Socket、Spring、動態代理、動態字節碼、序列化等技術在構建分布式微服務框架中的應用。然后介紹一種微服務框架的架構設計與編程實踐，并將這一微服務框架分解為底層Socket通信、服務注冊與發現、服務暴露與引用、遠程方法調用等層面，逐一深入講解。這里重點介紹作者如何活用相關技術一步步地構建微服務框架的基礎RPC框架并分享了相應的性能調優經驗。最后介紹微服務架構中配套的服務治理系統的設計與實現方案，包括服務的設計、配置、管理與監控。 |
目錄：第1章 多線程基礎
1.1 多線程的概念
1.1.1 進程與線程
1.1.2 并發與并行
1.1.3 線程狀態
1.2 Thread線程類
1.2.1 基本用法與思考
1.2.2 常用方法介紹
1.2.3 wait和sleep的區別
1.2.4 sleep和yield的區別
1.3 Runnable接口
1.4 線程池
1.4.1 Executors
1.4.2 ExecutorService
1.4.3 ThreadPoolExecutor
1.4.4 基本用法與思考
1.5 Callable與Future
1.6 線程安全與效率
1.6.1 什么是線程安全
1.6.2 線程同步
1.6.3 饑餓與公平
1.6.4 鎖與死鎖
1.6.5 線程中斷
1.7 編程進階
1.7.1 volatile關鍵字
1.7.2 synchronized關鍵字
1.7.3 wait/notify/notifyAll
1.7.4 CAS操作
1.7.5 atomic包
1.7.6 Lock自旋鎖
1.7.7 Condition條件變量
1.7.8 線程安全容器
1.7.9 ThreadLocal類
1.7.10 CountDownLatch計數器
1.7.11 CyclicBarrier柵欄
1.7.12 Semaphore信號量
1.7.13 fork/join框架
第2章 Socket基礎
2.1 TCP與Socket
2.2 TCP的通信過程
2.2.1 基本過程
2.2.2 建立連接
2.2.3 全雙工異步通信
2.2.4 斷開連接
2.2.5 優雅地斷開
2.2.6 半……連接
2.3 通信方式
2.3.1 長連接與短連接
2.3.2 線程模型
2.3.3 拆包與組包
2.3.4 斷包與粘包
2.3.5 數據包的結構
2.4 BIO
2.4.1 典型編程模型
2.4.2 關鍵API概述
2.4.3 字符流傳輸
2.4.4 字節流傳輸
2.4.5 傳輸多筆數據
2.5 NIO
2.5.1 NIO簡介
2.5.2 Buffer
2.5.3 Channel
2.5.4 Selector
2.5.5 Scatter/Gather
2.5.6 Pipe
2.5.7 內存映像文件
2.5.8 文件傳輸示例
2.5.9 “聊天室”示例
2.6 AIO
2.6.1 AIO簡介
2.6.2 關鍵API概述
2.6.3 示例代碼
第3章 Spring與Spring Cloud
3.1 Spring簡介
3.2 IoC容器
3.2.1 IoC的概念
3.2.2 Spring中的bean
3.2.3 XML配置方式
3.2.4 注解配置方式
3.2.5 用Java類來配置
3.2.6 BeanFactory與FactoryBean
3.2.7 ApplicationContext與ApplicationContextAware
3.2.8 動態注冊bean配置
3.2.9 ApplicationListener與容器事件
3.3 bean的基本配置
3.3.1 scope屬性
3.3.2 parent與abstract
3.3.3 factory-bean與factory-method
3.3.4 bean的初始化與釋放
3.4 依賴注入
3.4.1 setter注入
3.4.2 工廠方式注入
3.4.3 構造器注入
3.4.4 注解注入
3.5 Spring Boot
3.5.1 快速創建工程
3.5.2 編碼與測試
3.5.3 打包部署
3.5.4 輔助開發工具
3.5.5 監控功能
3.6 Spring Cloud
3.6.1 Spring Cloud簡介
3.6.2 架構設計
3.6.3 創建應用
3.6.4 服務的注冊與發現
3.6.5 服務配置
3.6.6 Ribbon負載均衡
3.6.7 Feign服務調用
3.6.8 Hystrix
3.6.9 Zuul服務路由
3.6.10 服務監控
第4章 動態代理
4.1 代理模式
4.2 靜態代理
4.3 類的裝載
4.4 Java反射
4.5 JDK動態代理
4.6 CGLIB動態代理
4.7 Java Compiler API
4.8 Javassist動態代理
第5章 對象序列化
5.1 什么是序列化
5.2 Java序列化
5.2.1 基本用法
5.2.2 關于serialVersionUID
5.2.3 自定義序列化
5.2.4 封裝實現代碼
5.3 Hessian序列化
5.4 Kryo序列化
5.5 FST序列化
5.6 其他序列化組件
5.7 集成與擴展
5.7.1 優雅地集成
5.7.2 使用Java SPI
5.7.3 使用Spring
第6章 框架設計
6.1 總體結構
6.1.1 邏輯架構
6.1.2 框架設計概述
6.1.3 RPC原理
6.1.4 工程結構
6.1.5 依賴的jar包
6.1.6 主要的類
6.2 初始化過程
6.2.1 Spring配置
6.2.2 應用節點的啟動
6.2.3 Web容器的啟動
6.2.4 RpcCore的初始化
6.2.5 RpcContext的初始化
6.3 服務的暴露
6.3.1 服務暴露配置
6.3.2 方法配置與ID
6.3.3 內置的服務方法
6.3.4 服務提供方本地調用器
6.3.5 服務提供方代理生成器
6.3.6 注冊要暴露的服務
6.4 服務的引用
6.4.1 服務引用配置
6.4.2 本地引用工廠類
6.4.3 注冊本地引用工廠
6.4.4 本地引用與方法ID
6.5 服務的注冊與發現
6.5.1 注冊表集合
6.5.2 注冊表的同步
6.5.3 注冊表的解析
6.5.4 提交注冊表
6.5.5 注冊表推送
6.5.6 注冊表檢查
6.6 優雅地停機
6.6.1 停機的過程
6.6.2 停機鉤子
6.6.3 監聽Web容器的關閉
6.6.4 RpcCore的關閉
6.6.5 停機通知的處理
第7章 方法調用
7.1 方法調用類型
7.2 同步調用
7.2.1 同步調用的時序
7.2.2 同步調用的發起
7.2.3 負載均衡
7.2.4 指定服務提供者
7.2.5 失敗轉移
7.2.6 發送調用請求
7.2.7 處理調用請求
7.2.8 處理調用響應
7.3 異步調用
7.3.1 異步調用的時序
7.3.2 異步調用的發起
7.3.3 異步調用的執行
7.3.4 方法調用對象
7.4 同步/異步通知
7.5 異步回調
7.6 廣播調用與廣播通知
7.6.1 廣播示例
7.6.2 廣播代碼
第8章 通信層實現
8.1 Socket通信框架
8.1.1 Netty與Mina
8.1.2 為什么要自己寫
8.1.3 是NIO還是AIO
8.1.4 設計思路
8.1.5 實際結構
8.2 通信協議
8.2.1 傳輸對象
8.2.2 數據包結構
8.2.3 拆包與發送
8.2.4 接收并組包
8.3 連接的建立
8.3.1 工作模型
8.3.2 開始監聽
8.3.3 發起連接
8.3.4 綁定連接
8.3.5 斷線檢測
第9章 性能測試與調優
9.1 性能調優概述
9.1.1 性能指標
9.1.2 性能瓶頸
9.1.3 環境因素
9.2 壓力測試
9.2.1 測試方法
9.2.2 場景設計
9.2.3 測試環境
9.2.4 Dubbo配置
9.2.5 測試程序
9.3 線程池調優
9.3.1 調整線程池的大小
9.3.2 選擇合適的隊列
9.3.3 線程的管理邏輯
9.3.4 選擇拒絕策略
9.4 優化線程同步
9.4.1 減少上下文切換
9.4.2 避免線程濫用
9.4.3 避免過多的鎖
9.4.4 synchronized VS Lock
9.4.5 縮小鎖的范圍和粒度
9.4.6 線程分析工具
9.5 JVM調優
9.5.1 堆與棧
9.5.2 JVM內存的分代
9.5.3 GC分類
9.5.4 GC算法
9.5.5 分代GC
9.5.6 對象的引用
9.5.7 內存大小設置
9.5.8 內存調優工具
9.6 其他優化內容
9.6.1 避免使用反射
9.6.2 對象池
9.6.3 緩沖區隊列
9.6.4 使用直接內存
9.6.5 緩存其他對象
9.6.6 協調與平衡
第10章 服務治理
10.1 服務治理概述
10.1.1 什么是服務治理
10.1.2 服務治理架構
10.1.3 服務治理接口
10.2 服務的定義
10.2.1 服務識別
10.2.2 接口定義
10.2.3 版本管理
10.2.4 協議適配
10.2.5 服務設計
10.2.6 服務的實現
10.2.7 依賴關系管理
10.3 服務的部署
10.3.1 服務的部署方式
10.3.2 自動化部署
10.3.3 服務的熱部署
10.4 注冊與發現
10.4.1 WSDL與UDDI
10.4.2 ZooKeeper的方案
10.4.3 Eureka的方案
10.4.4 Consul的方案
10.4.5 etcd的方案
10.4.6 注冊中心集成方案
10.5 服務的控制
10.5.1 服務狀態
10.5.2 服務控制
10.5.3 服務開關
10.5.4 服務模擬
10.5.5 黑白名單
10.5.6 “踢除”服務提供者
10.6 監控與限流
10.6.1 TPS監控與限流
10.6.2 響應時間的監控
10.6.3 調用鏈的監控
10.6.4 資源監控 |
| 序： |
