第1 章 應用架構演進 ...................................................................................... 1
1.1 傳統垂直應用架構 .................................................................................. 2
1.1.1 垂直應用架構介紹 ............................................................................. 2
1.1.2 垂直應用架構面臨的挑戰 .................................................................. 4
1.2 RPC 架構 ....................................................................................................... 6
1.2.1 RPC 框架原理 .................................................................................... 6
1.2.2 *簡單的RPC 框架實現 .................................................................... 8
1.2.3 業界主流RPC 框架 .......................................................................... 14
1.2.4 RPC 框架面臨的挑戰 ....................................................................... 17
1.3 SOA 服務化架構 ......................................................................................... 18
1.3.1 面向服務設計的原則........................................................................ 18
1.3.2 服務治理 .......................................................................................... 19
1.4 微服務架構 .................................................................................................. 21
1.4.1 什麼是微服務 ................................................................................... 21
1.4.2 微服務架構對比SOA ....................................................................... 22
1.5 總結 ............................................................................................................. 23
第2 章 分布式服務框架入門 .................................................................................... 25
2.1 分布式服務框架誕生背景 ........................................................................... 26
2.1.1 應用從集中式走向分布式 ................................................................ 26?
2.1.2 亟需服務治理 ................................................................................... 28
2.2 業界分布式服務框架介紹 ........................................................................... 29
2.2.1 阿裡Dubbo ....................................................................................... 30
2.2.2 **HSF .......................................................................................... 33
2.2.3 亞馬遜Coral Service ........................................................................ 35
2.3 分布式服務框架設計 ................................................................................... 36
2.3.1 架構原理 .......................................................................................... 36
2.3.2 功能特性 .......................................................................................... 37
2.3.3 性能特性 .......................................................................................... 39
2.3.4 可靠性 .............................................................................................. 39
2.3.5 服務治理 .......................................................................................... 40
2.4 總結 ............................................................................................................. 41
第3 章 通信框架 ..................................................................................................... 42
3.1 關鍵技術點分析 ........................................................................................... 43
3.1.1 長連接還是短連接 ........................................................................... 43
3.1.2 BIO 還是NIO ................................................................................... 43
3.1.3 自研還是選擇開源NIO 框架 ........................................................... 46
3.2 功能設計 ...................................................................................................... 47
3.2.1 服務端設計 ....................................................................................... 48
3.2.2 客戶端設計 ....................................................................................... 50
3.3 可靠性設計 .................................................................................................. 53
3.3.1 鏈路有效性檢

序一
IT 的體繫架構在歷史上經歷了幾次大的變化。從主機瘦客戶機時代，到Client Server興起，然後過渡到Browser Server 的架構，再到移動 雲計算 大數據的大熱。總結起來，IT 的核心變遷軌跡是在客戶端不斷提升體驗，易聯易用，而在服務器端則是不斷追求性能和成本優化改進。近幾年，還有一個非常明顯的趨勢是技術的成熟度和融合度不斷提高，移動、雲計算領域平臺型的公司（Android、iOS、AWS）使得整個IT 能力的使用成本很低，進入速度非常快，現在的高中生也可以利用手頭的工具非常快速方便地參與到軟件構建中來，這在以前是不可想像的。移動互聯網興起以後，大概在短短5 年內，世界上絕大部分原來在PC 端可以滿足的需求都由移動端的應用實現了一遍。IT 已經變成了一個快速消費品，而不是一個奢侈品。技術的進步使得IT 的敏捷性大大提升，但是對於一個大型繫統來說，如何能夠降低繫統的復雜度，提升敏捷性是關鍵而又頭疼的問題。我們也看到一些通用的標準和**實踐已經建立起來了，降低模塊之間的耦合度，提升組件的內聚性，規範對外的接口，實現分布式的繫統架構，把一個大型繫統通過服務化的方式規劃治理起來，已經成為一個共識。一個現代的大型IT 繫統，服務可以多至十萬、百萬級，如此眾多的服務，從設計、開發、運行、編排、維護到治理，每一個環節都需要大量深入仔細的考慮，纔能夠運轉起來。我們可以把這樣一個繫統比喻成一個城市，城市裡面有成千上萬的公司，每一個公司都有自己的業務來往，同時又需要現代化的交通、電力、通信、金融等體繫的支持。無論是小公司還是大公司，都依賴於整個城市的運作和治理體繫。公司和城市是相輔相成的關繫。IT繫統裡面的業務模塊和服務化框架也是相輔相成的關繫。服務化框架對於一個大型IT 繫是不可或缺的。業界有很多介紹服務化理念和技術點的文章和書籍。但真正能夠在理論、實踐、技術要點、眼界多方面全面覆蓋的資料,還是比較缺乏的。我很高興看到林鋒能夠總結自己在理論、產品和客戶實踐多方面的認知和經驗，為讀者奉獻《分布式服務框架原理與實踐》一書，深入淺出地介紹分布式服務的概念、體繫和關鍵技術點。希望這本書能夠幫助你了解分布式服務框架，掌握分布式服務體繫和技術要點，同時也能實踐服務化給你的IT 繫統帶來的敏捷。黃省江 華為軟件PaaS 平臺＆雲中間件技術總監
序二
容器SDN 技術與微服務架構實踐從20 世紀末期的**波互聯網浪潮開始，軟件架構的主流就逐步從Office 這類純客戶端軟件逐步過渡到服務端的架構設計。與傳統的客戶端設計相比，服務端的架構設計更關注伸縮性、可用性和可維護性。很可惜的是，現在市面上講語言、講算法、講設計模式或者講某一門獨立的技術的書都不少，但服務端架構設計的書卻寥寥無幾。從私下溝通的結果來看，大部分互聯網企業都沒有解決好上面的幾個問題。正如建築設計的現代化是從結構工程師開始的，軟件設計的現代化會從架構師開始，希望李林鋒這本書能夠幫助廣大的架構師或者有志於成為架構師的人掌握好這些知識，讓架構師能夠帶領開發團隊構建出穩定、安全、可維護、可伸縮的合格產品，讓架構師在軟件開發現代化這條路上起到領路人的作用。本書*末一章講述了*近很火的微服務架構，微服務架構的思想包含了對以前種種架構模式的反思，也通過Docker、Mesos 等技術變成**個可以輕松產品化的架構思想。我相信再過幾年對於開發人員，特別是服務端的開發人員，他們所面臨的開發模式將與現在的開發模式有很大的差異，這種差異我覺得甚至會大過程序可以有服務端這個概念的引入。在微服務架構下，開發的門檻將進一步降低，分布式將更加自然而不是依賴於艱難的設計，運維的負擔也將降低至一個極低的水平。我們可以期望通過微服務架構，從想法到產品的距離將更短，也能期待湧現出更多讓人嘆為觀止的產品，還能期待能出現些我們現在完全無法預測的技術和產品。李道兵 七牛雲首席架構師
前 言
2008 年9 月份，我有幸參與了一個華為軟件公司的國內Top3 項目，作為一名有經驗的開發，項目經理安排我負責整個繫統的實時交易和後臺服務端設計。盡管有ERP 軟件開發經驗，但是**次參與這麼大項目的架構設計和開發，壓力還是非常大，經常夜不能寐。好在公司當時已經研發了Java Web 框架，它基於Spring Struts iBatis 構建，利用公司成熟的MVC 框架我們很順利地完成了項目的開發和交付，並*終成功上線運行。隨著業務的發展，用戶數和需求逐步增多，團隊規模越來越大，我們遇到了很多棘手的問題：
1） 代碼重復率高：一些業務層的公共功能，被多個模塊重復開發，導致研發成本上升，代碼質量下降，架構腐化，為後續繫統的運維和新功能的開發帶來巨大的挑戰。
2） 需求變更困難：由於長流程無法有效拆分、代碼重復率高等因素，導致每次需求變更就影響一大片，需要做大量的回歸測試來保證質量，需求的交付周期被拉長。
3） 部署效率低：業務沒有拆分，很多功能模塊都打到同一個war 包中，一旦有一個功能發生變更，就需要重新打包和部署；巨無霸應用由於包含功能模塊過多，編譯、打包時間比較長，一旦編譯過程出錯，需要根據錯誤重新修改代碼再編譯，耗時較長。
4） 學習成本高：業務流程是由一長串本地接口或者方法調用串聯起來的，臃腫而冗長，而且往往由一個人負責開發和維護。隨著業務的發展和需求變化，本地代碼在不斷的迭代和變更，*後形成了一個個垂直的功能孤島，隻有原來的開發者纔理解接口調用關繫和功能需求，一旦原有的開發者離職或者調到其他項目組，這些功能模塊的運維就會變得非常困難。
5） 缺乏統一的RPC 框架：由於Web 框架隻提供了HTTP/HTTPS 協議，例如SOAP、SMPP 等協議棧需要業務自行集成第三方的開源框架，超時重發、網絡斷連等底層故障需要在應用上層統一封裝和處理，工作繁瑣而且容易出錯，對業務開發人員的技能要求也非常高。隨著公司業務的不斷發展，傳統MVC 架構已經無法再滿足業務對平臺的訴求，因此在2010 年下半年我們開始研發新的SOA 中間件，它包括企業集成總線ESB、流程編排引擎BPM、RPC 通信框架等。新的RPC 通信框架底層封裝了Java NIO 通信框架Netty、常用的序列化/反序列化框架，以及為應用層提供線程池和消息調度器，基於RPC 通信框架，業務可以快速的實現跨進程的遠程通信，而不需要關心底層的通信細節，例如鏈路的閃斷、失敗重試等，極大的提升了應用的開發效率。在很長一段時間，自研的RPC 框架成為業務**的Java 服務端框架。隨著RPC 框架的推廣和使用日益深入，一些新的公共需求被反饋過來：
1） 依賴管理：當服務越來越多時，服務URL 配置管理變得非常困難，希望有一個統一的服務注冊中心管理服務的依賴關繫。
2） 透明路由：通過訂閱發布機制，消費者隻需要關心服務本身，並不需要配置具體的服務提供者地址，實現服務的自動發現。
3） 服務治理：業務失敗之後的放通處理，超時時間控制、流控等常用運維功能，希望能夠獨立出一個服務治理中心，統一對集群各節點的服務做在線治理，提升治理效率，保障服務SLA。
4） 其他……
為了解決這些問題，以RPC 框架為核心，我們構建了全新的分布式服務框架，相比於傳統RPC 框架，它提供了如下新特性：
1） 基於注冊中心的服務訂閱/發布機制，支持服務自動發現和健康狀態檢測。
2） 集群容錯。
3） 依賴解耦，全配置化開發，對應用零侵入。
4） 服務治理，包括服務降級、服務調用鏈跟蹤、服務上線審批和下線通知等。
5） 服務化**實踐等。
分布式服務框架不僅僅包含核心的運行時類庫，還包括服務劃分原則、服務化**實踐、服務治理、服務監控、服務開發框架等，它是一套完整的解決方案，用來協助應用做服務化改造，以及指導用戶如何構建適合自己業務場景的服務化體繫，將服務化的價值發揮到極致。基於分布式服務框架，業務終於可以把全部精力都放到應用層的邏輯開發，研發效率、繫統可靠性都得到了極大的提升。目前，華為電信軟件主要解決方案幾乎所有的Java 繫統都基於分布式服務框架構建，底層的基礎框架實現了統一。*近一年多來，隨著DevOps 和以Docker 為首的容器技術的發展，微服務架構逐漸流行起來，微服務架構的流行有其必然的歷史原因，它是敏捷開發、基礎設施服務化、DevOps和互聯網行業快速發展的綜合產物。亞馬遜AWS、Netflix 等都是微服務的成功實踐者，相信未來國內越來越多的大型應用也會演進到微服務架構。華為軟件公司的Java 架構經歷了傳統的MVC 垂直架構-RPC 框架-分布式服務框架，目前正在向Docker 微服務方向演進，整個服務化架構的演進歷程也是業界技術變遷的一個縮影。在這7 年的演進歷程中，我有幸全程參與了相關框架的架構設計和核心模塊的開發，深有感觸。在此希望將自己設計、開發和運維的相關經驗分享出來，為初學者和相關經驗人士提供一些啟發，汲取相關經驗，少走些彎路。?能夠完成本書需要感謝很多人，首先感謝華為公司給我提供了足夠大的舞臺，感謝華為PaaS 平臺＆中間件團隊領導和同事莫曉軍、望嶽和王世軍等，以及與我在分布式服務框架團隊一起戰鬥過的開發、測試和資料。其次要感謝我的家人，你們一直在背後默默的支持我。感謝參與本書編輯的英姐、美工以及其他人員，你們的辛苦換來了本書的如期上市。*後要感謝所有的讀者，你們的支持和鼓勵是我寫作本書的動力源泉。
李林鋒
2015 年12 月於南京

構建企業互聯網架構的關鍵在於繫統分布式和服務化，尤其對於大型網站和大型企業繫統，繫統的靈活性、超大容量、彈性和自治能力是非常大的挑戰。在《分布式服務框架原理與實踐》一書中，作者基於深厚的軟件技術積累和電信領域成功應用實踐，對如何構建分布式服務化繫統，提供了原理分析、關鍵技術、開發案例以及業界技術對比，非常繫統化，不論是學習分布式服務技術還是深入大型互聯網架構都非常實用。
——華為雲集成平臺首席架構師苗彩霞

認識林鋒已有多年，從《Netty權威指南》到本書的誕生，再次見證了作者在該領域深厚的沉澱。閱覽該書的目錄以及相關章節，我驚詫於作者在這些領域深入的洞察和實踐。該書幾乎覆蓋了分布式繫統開發的每一個關鍵技術點，包括*為重要的通信框架設計、時下流行的微服務、服務路由關聯的技術和策略，以及飽受爭議的OSGi。強烈推薦相關從業人員閱讀此書。
——蘇寧雲商雲計算中心技術總監湯泳

在大型網站架構設計方面摸爬滾打多年後，看到《分布式服務框架原理與實踐》如獲至寶，作者條理清晰、由淺入深地解析了分布式服務架構所涉及方方面面的關鍵技術和原理，既有縱向演進介紹，又有橫向競品對比。尤其針對各種場景所提出的設計原則或**實踐，都是作者的實戰總結，有些經驗的獲取成本高昂，非常寶貴。本書完全可以直接用於指導分布式服務繫統的構建。
——中國移動手機閱讀基地平臺首席架構師胡穩

分布式的應用在設計、開發以及部署的各個方面都比較復雜，國內外也沒有權威的圖書進行繫統介紹，於是在這方面，我們不得不一遍遍地踩坑。林鋒有著深厚的技術基礎和豐富的架構經驗，這本集他經驗和心血而成的圖書，包含了分布式繫統的方方面面，既有宏觀的理論介紹，也有來自一線的經驗分享，相信它必將成為架構師和開發人員的***圖書！
——東軟集團資深軟件工程師、InfoQ編輯張衛濱

“微服務”無疑是本年度*熱的技術關鍵詞之一！那如何落地微服務呢？我認為首先要實現服務化，而本書恰好提供了一個很好的服務化操作指導。作者首先分析了作為一個分布式服務框架所需具備的能力，包括服務注冊中心、服務調用、服務路由、服務發布／灰度發布等；其次作者分析了服務底層如何有效地進行通信，包括通信框架，序列化／反序列化及協議棧等；再次作者分析了服務如何做到高可靠性及高安全性等重要特性；*後作者也闡述了從服務化如何向微服務演進。
——麻袋理財首席架構師王天青


以OpenStack為規範建設的IaaS、以Docker為代表的容器技術、以分布式微服務框架構建的業務平臺即將顛覆業務繫統整體建設方案，新的繫統建設方案將極大提升業務繫統的可用性、擴展性和應變能力。微服務架構對於運營商內容型業務的互聯網化轉型意義非凡，繫統架構微服務化纔能真正支撐好業務轉型的需要。本書將成為幫助大家更好地理解微服務框架關鍵技術的原理和實現的***書籍。
——咪咕動漫繫統支撐部技術總監*

鋒兄在華為一直從事核心代碼的架構設計和開發，屬於實戰型架構師，而且樂於分享。《分布式服務框架原理與實踐》源於他在多年架構設計工作中的實戰經驗，閱讀價值極高！在面向大規模、分布式繫統架構中，服務框架是其中的核心和必經之路。祝賀鋒兄新書造福廣大程序猿！
——奇蛙CEEWA運動無人機合伙人、前華為開放平臺總架構師馮黎

近些年來，越來越多網站需要同時提供Web、移動App、OpenAPI多種訪問方式，基於分布式服務的業務分治與復用需求越來越強烈，使用分布式服務構建繫統已經成為互聯網開發的常用手段。但是分布式服務的關鍵技術有哪些？核心原理是什麼？**實踐是什麼？本書作者作為分布式框架的開發者根據自己的實踐經驗編寫的這本《分布式服務框架原理與實踐》或可為您解惑。分布式服務框架用到的各種技術也是整個互聯網分布式技術的一個縮影，您也可窺一斑而知全豹，通過本書學習掌握各種分布式開發技巧。
——宅米網CTO、《大型網站技術架構：核心原理與案例分析》作者李智慧

整書由構建分布式服務為基礎講起，逐步深入到分布式服務的保障機制，*後也講解了時下新興分布式設計方案微服務架構。書中內容組織清晰，圖例詳實，非常便於理解與吸收，是一本不錯的提升分布式服務架構能力的書籍。
——鏈家網架構師呂毅


本書深度闡述了應用和繫統架構方面的設計和原理，真實體現了李林鋒豐富的技術架構經驗以及樂於分享的精神。在業務繫統越來越講究高可用、高性能、可伸縮擴展、高安全性、自動運維的今天，本書集合了大型企業多年的架構思路，為技術以及產品人員提供了重要的參考依據，從理念上提升了每位讀者的技術水平，非常值得深入閱讀和理解。
——阿裡雲PaaS平臺產品架構師楊林

8.2.2異步服務調用
基於JDK的Future機制，可以非常方便地實現異步服務調用，JDK的Future接口定義如圖8-5所示。

JDK原生的Future主要用於異步操作，它代表了異步操作的執行結果，用戶可以通過調用它的get方法獲取結果。如果當前操作沒有執行完，get操作將阻塞調用線程。
在實際項目中，往往會擴展JDK的Future，提供Future-Listener機制，它支持主動獲取和被動異步回調通知兩種模式，適用於不同的業務場景。
以Netty的Future接口定義為例，新增了監聽器管理接口，監聽器主要用於異步通知回調。
異步服務調用的工作流程如下：
1） 消費者調用服務端發布的接口，接口調用由分布式服務框架包裝成動態代理，發起遠程服務調用。
2） 通信框架異步發送請求消息，如果沒有發生I/O異常，返回。
3） 請求消息發送成功後，I/O線程構造Future對像，設置到RPC上下文中。
4） 用戶線程通過RPC上下文獲取Future對像。
5） 構造Listener對像，將其添加到Future中，用於服務端應答異步回調通知。
6） 用戶線程返回，不阻塞等待應答。
7） 服務端返回應答消息，通信框架負責反序列化等。
8） I/O線程將應答設置到Future對像的操作結果中。
9） Future對像掃描注冊的監聽器列表，循環調用監聽器的operationComplete方法，將結果通知給監聽器，監聽器獲取到結果之後，繼續後續業務邏輯的執行，異步服務調用結束。
需要指出的是，還有另外一種異步服務調用形式，就是不添加Listener，用戶連續發起N次服務調用，然後依次從RPC上下文中獲取Future對像，*終再主動get結果，業務線程阻塞，相比於老的同步服務調用，它的阻塞時間更短，其工作原理如圖8-8所示。
異步服務調用的代碼示例如下：
xxxService1.xxxMethod(Req);
Future f1 = RpcContext.getContext().getFuture();
xxxService2.xxxMethod(Req);
Future f2 = RpcContext.getContext().getFuture();
Object xxResult1 = f1.get(3000);
Object xxResult2 = f2.get(3000); }
假如xxxService1和xxxService2發布成異步服務，則調用xxxMethod之後當前業務線程不阻塞，立即返回null。用戶不能直接使用它的返回值，而是通過當前線程上下文RPCContext獲取異步操作結果Future。獲取到Future之後繼續發起其他異步服務調用，然後獲取另一個Future……*後，通過Future的get方法集中獲取結果。無論有多少個Future，采用此種方式用戶線程*長阻塞時間為耗時*長的Future，即T = Max t(future1....N)。如果采用同步服務調用，用戶線程的阻塞時間T = t(future1) t(future2) …… t(futureN)。
異步服務調用相比於同步服務調用有兩個優點：
◎ 化串行為並行，提升服務調用效率，減少業務線程阻塞時間。
◎ 化同步為異步，避免業務線程阻塞。
由於每次服務調用都是同步阻塞，三個服務調用總耗時為T = T1 T2 T3。下面我們看下采用異步服務調用之後的優化效果。
采用異步服務調用模式，*後調用三個服務異步操作結果Future的get方法同步等待應答，它的總執行時間T = Max(T1, T2, T3)，相比於同步服務調用，性能提升效果非常明顯。
第二種基於Future-Listener的純異步服務調用，它的代碼示例如下：

xxxService1.xxxMethod(Req);
Future f1 = RpcContext.getContext().getFuture();
Listener l = new xxxListener();
f1.addListener(l);
......後續代碼省略 }
基於Future-Listener的異步服務調用相比於Future-get模式更好，但是在實際使用中有一定的局限性，具體的使用限制留給讀者自己思考。