前言
分佈式服務框架不只僅包含核心的運行時類庫，還包括服務劃分原則、服務化最佳實踐、服務治理、服務監控、服務開發框架等，它是一套完整的解決方案，用來協助應用作服務化改造，以及指導用戶如何構建適合本身業務場景的服務化體系，將服務化的價值發揮到極致。編程
基於分佈式服務框架，業務終於能夠把所有精力都放到應用層的邏輯開發，研發效率、系統可靠性都獲得了極大的提高。目前，華爲電信軟件主要解決方案几乎全部的Java系統都基於分佈式服務框架構建，底層的基礎框架實現了統一。後端
近年來，隨着DevOps和以Docker爲首的容器技術的發展，微服務架構逐漸流行起來，微服務架構的流行有其必然的歷史緣由，它是敏捷開發、基礎設施服務化、DevOps和互聯網行業快速發展的綜合產物。亞馬遜AWS、Netflix 等都是微服務的成功實踐者，相信將來國內愈來愈多的大型應用也會演進到微服務架構。緩存
華爲軟件公司的Java架構經歷了傳統的MVC垂直架構-RPC框架-分佈式服務框架，目前正在向Docker+微服務方向演進，整個服務化架構的演進歷程也是業界技術變遷的一個縮影。安全
因此說，分佈式服務框架和微服務，都是成爲架構師之路的重要基石，不可或缺的技術，小夥伴們要重視這一起內容的學習。服務器
今天恰好，就給你們準備了這兩塊兒的技術知識，但願你們可以喜歡多多轉發讓更多人受益！網絡
我們將把這兩部分知識從目錄、內容和具體章節逐一介紹，你們要仔細研讀！多線程
首先，給你們介紹的第一起內容是——分佈式服務框架原理實踐
1.目錄
2.主要內容
第1章，應用架構演進架構
隨着業務的發展，應用規模不斷擴大，系統內部的巨無霸應用愈來愈多，常規的垂直應用架構已經沒法應對複雜業務帶來的各類挑戰。經過將業務公共能力抽象成原子服務，對複雜應用進行水平拆分和服務化，實現服務消費者和提供者的解耦。公共能力抽取和複用，能夠有效下降公共模塊重複開發建設的成本。併發
傳統垂直架構改造的核心就是要對應用作服務化改造，服務化改造使用到的核心技術架構就是分佈式服務框架。框架
本章對應用架構的演進歷史進行剖析，使讀者可以更清晰和全面地瞭解應用架構的歷史演進過程以及將來架構的發展方向。
第2章，分佈式服務框架入門
在一個不斷髮展的大型應用中，新的業務需求和功能不斷增長，技術也在不斷演進，不一樣團隊構建的功能子系統採用的技術架構五花八門，子系統之間的開發、部署和運維模式也存在較大差別。若是企業內部沒有統一的服務框架進行技術層面的拉通，開發和運維效率都將受到很大制約。
傳統垂直架構改造的核心就是要對應用進行服務化，服務化改造使用到的核心技術就是分佈式服務框架。
第3章，通訊框架
單機版的本地方法調用變成遠程服務調用以後，一個高性能的通用通訊框架成爲分佈式服務框架必不可少的有機組成部分。
通訊框架涉及到Socket通訊、多線程編程、協議棧等相關知識，這部分在Java 技術堆棧中屬於偏難掌握的部分。本章將對通訊框架的原理和設計重點進行詳細講解，以期你們能夠儘快熟悉通訊框架的設計要點並在實際工做中靈活使用。
第4章，序列化與反序列化
服務提供者和消費者經過網絡進行通訊，對象須要進行序列化和反序列化，常見的序列化和反序列化方式不少，如何選擇是重點也是難點。
第5章，協議棧
不一樣服務在性能上適用不一樣協議進行傳輸。好比對接異構第三方服務時，一般會選擇HTTP/Restful 等公有協議:對於內部不一樣模塊之間的服務調用，每每會選擇性能較高的二進制私有協議。
第6章，服務路由
分佈式服務框架.上線運行時都是集羣組網，這意味着集羣中存在某個服務的多實例部署，消費者如何從服務列表中選擇合適的服務提供者進行調用，這就涉及到服務路由。分佈式服務框架要可以知足用戶靈活的路由需求。
第7章，集羣容錯
集羣服務調用失敗後，服務框架須要可以在底層自動容錯，容錯策略不少，分別適用於不一樣場景。本章將對集羣容錯的功能和設計進行詳細講解。
第8章，服務調用
除了經常使用的同步服務調用以外，分佈式服務框架還須要支持其餘幾種形式的服務調用，本章將對這些調用方式進行詳細講解。
第9章，服務註冊中心
對於服務提供者，它須要發佈服務，因爲應用系統的複雜性，服務的數量、類型不斷膨脹;對於服務消費者，它最關心的是如何獲取到它所須要的服務。對於服務提供方和服務消費方來講，它們還有可能兼具這兩種角色:既須要提供服務，又須要消費服務。
如何有效地管理服務訂閱/發佈,避免硬編碼地址信息是分佈式服務框架須要解決的一個問題。經過將服務統一管理起來， 能夠有效地優化內部應用對服務發佈/使用的流程和管理，服務註冊中心就是專門用來管理服務訂閱/發佈的配置管理節點。
第10章，服務發佈和引用
服務提供者須要支持經過配置、註解、API 調用等方式，把本地接口發佈成遠程服務:對於消費者，能夠經過對等的方式引用遠.程服務提供者，實現服務的發佈和引用。
第11章，服務灰度發佈
灰度發佈是指在黑與白之間，可以平滑過渡的一種發佈方式。
AB test 就是一種灰度發佈方式:讓一部分用戶繼續用A,一部分用戶開始用B;若是用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把全部用戶都遷移到B上面來。灰度發佈能夠保證總體系統的穩定，在初始灰度的時候就能夠發現、調整問題，以保證其影響度。
第12章，參數傳遞
服務消費者和提供者之間進行通訊時，除了接口定義的請求參數，每每還須要攜帶一些額外參數，例如消息提供者的IP地址、消息調用鏈的跟蹤ID等;這些參數不能經過業務接口來進行傳遞，
須要底層的分佈式服務框架支持這種參數傳遞方式。
第13章，服務多版本
服務上線以後，隨着業務的發展須要對功能進行變動，或者修復線上的BUG;服務升級以後，每每須要對服務採用多版本管理。
服務多版本管理是分佈式服務框架的重要特性，它涉及服務的開發、部署、在線升級和服務治理。
第14章，流量控制
當資源成爲瓶頸時，服務框架須要對消費者作限流，啓動流控保護機制。流量控制有多種策略，比較經常使用的有:針對訪問速率的靜態流控、針對資源佔用的動態流控、針對消費者併發鏈接數的鏈接控制和針對並行訪問數的併發控制。
在實踐中，各類流量控制策略須要綜合使用才能起到較好的效果，本章針對分佈式服務框架的流量控制設計原則和實踐進行講解。
第15章，服務降級
大促或者業務高峯時，爲了保證核心服務的SLA,每每須要停掉一些不過重要的業務，例如商品評論、論壇或者粉絲積分等。
另一種場景就是某些服務由於某種緣由不可用，可是流程不能直接失敗，須要本地Mock服務端實現，作流程放通。以圖書閱讀爲例，若是用戶登陸餘額鑑權服務不能正常工做，須要作業務放通，記錄消費話單，容許用戶繼續閱讀，而不是返回失敗。
上述兩種場景，都使用到了分佈式服務框架的一個重要服務治理功能:服務降級。服務降級主要包括容錯降級和屏蔽降級兩種模式，下面咱們就兩種服務降級的策略和設計進行講解。
第16章，服務優先級調度
當系統當前資源很是有限時，爲了保證高優先級的服務可以正常運行，保障服務SLA，須要下降一些非核心服務的調度頻次，釋放部分資源佔用，保障系統的總體運行平穩。
服務優先級的調度策略很是多，對於分佈式服務框架而言，須要可以支持服務發佈時設置優先級策略，並在資源成爲瓶頸時，按照用戶配置的優先級策略調度執行服務。
第17章，服務治理
隨着業務的發展，服務愈來愈多，如何協調線上運行的各個服務，保障服務的SLA，對服務架構和運維人員是一個很大的挑戰。
隨着業務規模的不斷擴大，小服務資源浪費等問題逐漸顯現，須要可以基於服務調用的性能KPI數據進行容量管理，合理分配各個服務的資源佔用，提升機器的利用率。
線上業務發生故障時，須要對故障業務作服務降級、流量控制、流量遷移等，快速恢復業務。
隨着開發團隊的不斷擴大，服務的上線愈來愈隨意，甚至發生功能相同、服務名不一樣的服務同時上線。上線容易下線難，爲了規範服務的上線和下線，在服務發佈前，須要走服務預發佈流程，由架構師或者項目經理對須要上線的服務作發佈審覈，審覈經過的纔可以上線。
爲了知足服務線下管控、保障線上高效運行，須要有一個統一的服務治理框架對服務進行統1、有效管控，保障服務的高效、健康運行。
第18章，分佈式消息跟蹤
隨着業務分佈式架構的發展，系統間的系統調用日趨複雜，以電商的商品購買爲例，前臺界面的購買操做涉及到底層上百次服務調用，涉及到的中間件包括:
◎分佈式服務框架
◎消息隊列 .
◎分佈式緩存
◎分佈式數據訪間中間件
◎分佈式文件存儲系統
◎分佈式日誌採集
◎其.....
若是沒法有效清理後端的分佈式調用和依賴關係，故障定界將會很是困難。利用分佈式消息跟蹤系統能夠有效解決服務化以後系統面臨的運維挑戰，提升運維效率。
第19章，可靠性設計
相對於傳統的本地Java API調用，跨進程的分佈式服務調用面臨的故障風險更高。
1)網絡類故障:鏈路閃斷、讀寫超時等。
2)序列化和反序列化失敗。
3)畸形碼流。
4)服務端流控和擁塞保護致使的服務調用失敗。
5)其餘異常.....
對於應用而言，分佈式服務框架須要具有足夠的健壯性，在平臺底層可以攔截並向上屏蔽故障，業務只須要配置容錯策略，便可實現高可靠性。
第20章，微服務架構
過去十年，SOA ( Service-Oriented Architecture)架構獲得了普遍的應用，如今，隨着雲計算、移動互聯網、Docker 容器等技術的快速發展和應用，「微服務」架構(Micro Service Architecture) 這一全新的架構風格愈來愈受到你們的關注，也有愈來愈多的企業和平臺服務提供商在實踐中嘗試並使用它來解決具體業務問題,微服務架構的流行已經成爲將來技術發展趨勢之一。
第21章，服務化最佳實踐
在服務化以前，業務一般都是本地API調用，本地方法調用性能損耗較小。服務化以後，服務提供者和消費者之間採用遠程網絡通訊，增長了額外的性能損耗，業務調用的時延將增大，同時因爲網絡閃斷等緣由，分佈式調用失敗的風險也增大。若是服務框架沒有足夠的容錯能力，業務失敗率將會大幅提高。
除了性能、可靠性等問題，跨節點的事務一致性問題、分佈式調用帶來的故障定界困難、海量微服務運維成本增長等也是分佈式服務框架必需要解決的難題。本章節咱們將對服務化以後面臨的挑戰進行分析，並給出解決方案和業務最佳實踐。
其次，給你們介紹第二塊兒內容是——微服務設計
1.目錄
2.主要內容
第1章微服務
隨着領域驅動設計、持續交付、按需虛擬化、基礎設施自動化、小型自治團隊、大型集羣系統這些實踐的流行，微服務也應運而生。它並非被髮明出來的，而是從現實世界中總結出來的一種趨勢或模式。可是沒有前面說起的這些概念，微服務也很難出現。在本書接下來的內容中，我會嘗試把這些概念整合起來，從而給出一個涉及如何構建、管理和演化微服務的全景圖。
不少組織發現細粒度的微服務架構能夠幫助他們更快地交付軟件，而且有更多機會嘗試新技術。微服務在技術決策上給了咱們極大的自由度，使咱們可以更快地響應不可避免的變化。
第2章演化式架構師
目前爲止能夠看到，微服務給咱們提供了不少選擇，所以也須要咱們作不少決定。好比應該使用多少種不一樣的技術，不一樣的團隊是否應使用不一樣的編程規範，是應該合併多個服務仍是把一-個服務拆成多個。咱們應該如何作決定呢?這些架構支持在頻繁變換的環境下以更快的節奏進行變化，所以架構師這個角色也須要作相應的改變。本章關於架構師職責的觀點是個人我的看法，但願能對象牙塔中的定義發起最後的攻擊。
第3章如何建模服務
如今你已經知道什麼是微服務了，但願你對它的主要優勢也有所理解。你可能已經火燒眉毛地想要實現它了，對嗎?可是從何作起呢?在本章中，咱們會討論如何肯定服務之間的邊界，以期最大化微服務的好處，避開它的劣勢。可是，首先咱們須要有一個產品做爲討論的載體。
第4章集成
在我看來，集成是微服務相關技術中最重要的一-個。作得好的話，你的微服務能夠保持自治性，你也能夠獨立地修改和發佈它們:但作得很差的話會帶來災難。但願本章可以幫助你在微服務之旅中，避免曾經在SOA中遇到的那些問題。
第5章分解單塊系統
前面幾章討論了什麼是好的服務以及爲何小服務能達到更好的效果，還討論了系統具備可演化性的重要性。但事實上，可能咱們手中已經有了不少代碼庫，而它們無一例外都沒有遵循上述的模式。如何才能按部就班地把-一個單塊系統分解開來呢?
單塊系統的造成非一日之功。開發人員天天都對系統添加新功能和新代碼。一段時間以後，它變成了組織中一個恐怖而巨大的存在，沒人想去修改它。但別擔憂，它並非無可救藥。只要使用了正確的工具，咱們就能夠手刃這個怪獸。
第6章部署
部署一個單塊系統的流程很是簡單。然而在衆多相互依賴的微服務中，部署倒是徹底不一樣的狀況。若是部署的方法不合適，那麼其帶來的複雜程度會讓你很痛苦。本章會講解一些技巧和技術，從而幫助咱們]在細粒度的架構中更好地部署微服務。
我會從持續集成和持續交付提及。這些概念與咱們下面要討論的主題並不相同，但又有所關聯，了 解它們能夠幫助咱們在考慮構建什麼、如何構建以及如何部署時，作出更好的決定。
第7章測試
從我開始接觸編程至今，自動化測試的世界突飛猛進，而且幾乎每月都會出現新的工具和技術，不斷推進這個世界向前發展。不過，如何高效且有效地測試分佈式系統的功能依然是一個挑戰。本章會剖析-下測試細粒度系統面臨的問題和挑戰，並提出- -些解決方案，幫助你們更有信心地發佈新的功能。
測試的覆蓋面很廣，即便只討論自動化測試，也需考慮甚多。使用微服務架構之後，測試的複雜度進-步增長。面對這樣的挑戰，瞭解測試有哪些不一樣的類型，對咱們來講便很是重要了。它能夠幫助咱們實現儘早交付軟件與保持軟件高質量之間的平衡，由於有時魚和熊掌是不可兼得的。
第8章監控
正如我以前所展現的，將系統拆分紅更小的、細粒度的微服務會帶來不少好處。然而，它也增長了生產系統的監控複雜性。在本章中，我將帶你們看看細粒度的系統在系統監控和定位問題上所面臨的挑戰，同時還會介紹一些應對方法，讓魚和熊掌兼得!
設想一下這樣的場景:一個安靜的週五下午，團隊期待着早點開溜去酒吧，開始一個遠離工做的週末。然而，忽然收到一-封郵件:網站工做異常! Twitter 上處處都是關於貴公司網站出問題的消息，而你的老闆在旁邊喋喋不休，一個安靜的週末就這麼沒了。
你須要瞭解的第一件事情是什麼?問題到底出在哪裏?
在單塊應用的世界裏，咱們至少要很是清楚該從哪裏開始調查。網站慢?是單塊應用的問題。網站有 異常?是單塊應用的問題。CPU佔用率100% ?仍是單塊應用的問題。燒焦的氣味?你懂的，單一的故障點會極大地簡化對問題的調查!
如今，讓咱們回到基於微服務的系統。咱們提供給用戶的功能，是由多個小的服務組合而成的，其中一些服務須要集成更多的服務來完成功能。這種方法有不少優勢(這很好，不然這本書豈不是浪費時間? )，但在監控的世界裏，咱們面臨的是一個更爲複雜的問題。
咱們如今有多個服務須要監控，有多個日誌須要篩選，多個地方有可能由於網絡延遲而出現問題。該如何應對呢?咱們得好好梳理一下，不然極可能致使混亂，成爲一團亂麻，而這是週五下午(或在任什麼時候間! )咱們最不想面對的狀況。
這裏的答案很簡單:監控小的服務，而後聚合起來看總體。咱們從最簡單的系統一-個節點，來展現該如何作。
第9章安全
關於大型系統的安全漏洞致使數據暴露給各類危險人物的故事，咱們已經據說了太多。最近的愛德華●斯諾登泄密事件，更加讓咱們意識到公司持有的用戶信息的價值，以及保存在爲客戶構建的系統中的數據的價值。本章將簡要概述設計系統時，在安全方面應該考慮的一些問題。雖然沒法包含安全的方方面面，但會列出一-些主要的選項給你，爲進一步研究提供一個很好的起點。
咱們須要考慮，在數據從一個點到另外一個點的傳輸過程當中，如何保護它們，也須要考慮在其餘狀況下如何進行保護。咱們須要考慮底層操做系統及網絡的安全。有太多須要考慮的點，有太多能夠作的事情!那到底須要多安全呢?咱們如何知道什麼是足夠安全呢?
咱們還須要考慮人的因素。誰在使用咱們的系統，他又會作些什麼?而這又與咱們的服務器如何交互有什麼關係?讓咱們從這裏開始。
第10章康威定律和系統設計
到目前爲止，本書大部分的內容集中在向細粒度架構邁進時所面臨的技術挑戰。但除此以外，咱們也須要考慮組織方面的問題。在這一一章， 咱們將瞭解到忽略公司的組織結構會帶來什麼樣的危險。
咱們的行業還很年輕，它彷佛在不斷地重塑本身。不過，一些關鍵定律仍是經受住了時間的考驗。例如摩爾定律，它表示集成電路上可容納的晶體管數目每兩年會增長一倍。該定律已經被證實準確得驚人(儘管有人預測，這種趨勢已經放緩)。還有一條定律，我發現幾乎廣泛適用，在個人平常工做中也更有用，那就是康威定律。
第11章規模化微服務
當你處理書中的小例子時，一切彷佛都很簡單，但現實世界要複雜得多。當咱們的微服務架構從剛開始的簡單變得複雜後，會發生什麼呢?當咱們不得不處理髮生故障的多個獨立服務，或管理數以百計的服務時，該怎麼辦呢?當微服務的數量比人還多時，有什麼應對的模式嗎?讓咱們一塊兒尋找答案吧!
第12章總結
在前面的章節咱們已經討論了至關多的內容，從微服務的定義到如何劃分它的邊界，從集成技術到安全和監控。咱們甚至還探討了微服務架構下，架構師的角色應該是什麼樣子的。雖然每一個微服務自己很小，可是它對架構的影響卻很廣很大，因此仍是須要學習不少東西。在本章，我會嘗試總結一些貫穿全書的關鍵點。
總結
由於文章內容的限制，小編在這裏就不作過多的介紹了，須要這兩部分完整版實戰技術文檔的小夥伴，能夠轉發關注小編，直接查看下方圖片，掃碼添加或私信小編【技術】來獲取！！
你的過去我來不及參與，可是你的將來我奉陪到底！
持續給你們分享技術知識，但願你們可以喜歡！！