## 微服務整體框架 - 開發前後臺分離：前臺與後臺之間，通過**Restful**風格介面通訊（HTTP協議） - 內部服務：**Dubbo**（ RPC框架） - 外部服務：**SpringCloud Zuul**（提供Restful API介面）  - 微服務應用開發 ## API Gateway - **API Gateway**:閘道器,統一應用請求介面.API 閘道器在微服務們的最前端,讓 API 閘道器變成由應用所發起的每個請求的入口，簡化客戶端實現和微服務應用程式間的溝通方式。 ##### API Gateway兩種方式: - **單節點API Gateway**  - **BFF (Backends for frontends) Gateway**  ##### API Gateway的作用 - **請求路由，版本控制:** API Gateway 是微服務的入口，可以根據不同的請求路由到不同的服務上. 也可以進行路由的版本控制，這樣即使後服務發生了變化，Gateway 的路徑依然可以不改變 - **使用者登入，許可權認證:** 客戶端在與我們後端服務進行互動之前，由API Gateway先進行登入鑑權操作，這是後端所有的服務都需要有的共有邏輯 - **資料聚合:** 由於不同的客戶端往往需要的資料完全不同，而這些資料又是不同的 service 提供的，可以藉助 Gateway 方便完成來自不同 service 的資料聚合 - **協議轉換：** 在專案實踐中，CS（Client to Server）協議和SS（Server to Server）協議是不一樣的，為了保證資料傳輸的可靠性，CS協議會有鑑權以及加密解密的邏輯，而在內部的SS協議則不需要這些邏輯，因此在 Gateway 我們需要有一個協議轉換的過程 - **熔斷，降級，限流:** 通過API Gateway可以在監測到某個服務發生異常，或者當服務的流量超過服務的承載能力等情況時，可以採取相應的措施. 提高整個系統的容錯性、穩定性 - **負載均衡:** API Gateway知道所有服務例項的地址，可以根據不同服務採取不同的負載均衡策略 - **灰度釋出:** 灰度釋出允許直接只匯入指定量的流量請求到新的版本 ##### API Gateway的架構  - **多閘道器叢集(Backends for frontends):** 針對不同的客戶端，都有相應的閘道器層來接入.功能主要有：使用者登入，鑑權，服務發現註冊，協議轉換，介面版本控制等以及監控，APM呼叫鏈，日誌，流控策略等 - **聚合服務(Merge Service):** 在某些客戶端的需求中，需要從多個服務拉取資料，為了減少客戶端的複雜度，以及加快客戶端的訪問速度，可以加一個聚合層，用來做聚合查詢，在某些介面中可以把多個服務的資料一次性返回給客戶端 - **儀表盤管理端(Dashboard):** Dashboard 提供視覺化的分析平臺，包括服務的管理，監控資料報警配置，日誌查詢，灰度釋出操作，API文件管理等 ## Eureka(服務發現框架) - Eureka是一個基於REST的服務,主要用於定位執行在AWS域中的中間層服務，以達到負載均衡和中間層服務故障轉移的目的. SpringCloud將它整合在其子專案spring-cloud-netflix中，以實現SpringCloud的服務發現功能 ##### Eureka的兩個元件 - **Eureka Server:** Eureka Server提供服務註冊服務，各個節點啟動後，會在Eureka Server中進行註冊，這樣EurekaServer中的服務登錄檔中將會儲存所有可用服務節點的資訊，服務節點的資訊可以在介面中看到. Eureka Server之間通過複製的方式完成資料的同步 - **Eureka Client:** 是一個java客戶端，用於簡化與Eureka Server的互動，客戶端同時也就是一個內建的、使用輪詢(round-robin)負載演算法的負載均衡器 - **Eureka通過心跳檢查、客戶端快取等機制，確保了系統的高可用性、靈活性和可伸縮性** - 在應用啟動後，將會向Eureka Server傳送心跳, 如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，Eureka Server將會從服務登錄檔中把這個服務節點移除。 - Eureka還提供了客戶端快取機制，即使所有的Eureka Server都掛掉，客戶端依然可以利用快取中的資訊消費其他服務的API。Eureka通過心跳檢查、客戶端快取等機制，確保了系統的高可用性、靈活性和可伸縮性 ## RPC框架 ##### RPC定義 - **RPC(Remote Procedure Call Protocol):** 遠端過程呼叫協議,一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議.也就是 ``` 客戶端在不知道呼叫細節的情況下，呼叫存在於遠端計算機上的某個物件，就像呼叫本地應用程式中的物件一樣 ``` - **RPC是協議:** 協議就是一套規範,目前典型的RPC實現包括:Dubbo,Thrift,GRPC,Hetty等.從目前技術的發展趨勢來看,實現了RPC協議的應用工具往往都會附加其他重要功能 - **網路協議和網路IO模型對其透明:** 既然RPC的客戶端認為自己是在呼叫本地物件。那麼傳輸層使用的是TCP/UDP還是HTTP協議，又或者是一些其他的網路協議它就不需要關心了。既然網路協議對其透明，那麼呼叫過程中，使用的是哪一種網路IO模型呼叫者也不需要關心 - **資訊格式對其透明:** 我們知道在本地應用程式中，對於某個物件的呼叫需要傳遞一些引數，並且會返回一個呼叫結果。至於被呼叫的物件內部是如何使用這些引數，並計算出處理結果的，呼叫方是不需要關心的。那麼對於遠端呼叫來說，這些引數會以某種資訊格式傳遞給網路上的另外一臺計算機，這個資訊格式是怎樣構成的，呼叫方是不需要關心的 - **應該有跨語言能力:** 呼叫方實際上也不清楚遠端伺服器的應用程式是使用什麼語言執行的。那麼對於呼叫方來說，無論伺服器方使用的是什麼語言，本次呼叫都應該成功，並且返回值也應該按照呼叫方程式語言所能理解的形式進行描述  ##### RPC主要組成部分  - **Client:** RPC協議的呼叫方.最理想的情況是RPC Client在完全不知道有RPC框架存在的情況下發起對遠端服務的呼叫.但實際情況來說Client或多或少的都需要指定RPC框架的一些細節 - **Server:** 在RPC規範中，這個Server並不是提供RPC伺服器IP,埠監聽的模組。而是**遠端服務方法的具體實現(在JAVA中就是RPC服務介面的具體實現)**.其中的程式碼是最普通的和業務相關的程式碼，甚至其介面實現類本身都不知道將被某一個RPC遠端客戶端呼叫 - **Stub/Proxy:** RPC代理存在於客戶端，因為要實現客戶端對RPC框架“透明”呼叫，那麼客戶端不可能自行去管理訊息格式、不可能自己去管理網路傳輸協議，也不可能自己去判斷呼叫過程是否有異常。這一切工作在客戶端都是交給RPC框架中的“代理”層來處理的 - **Message Protocol:** 一次完整的client-server的互動肯定是攜帶某種兩端都能識別的,共同約定的訊息格式.**RPC的訊息管理層專門對網路傳輸所承載的訊息資訊進行編碼和解碼操作**.目前流行的技術趨勢是不同的RPC實現,為了加強自身框架的效率都有一套(或者幾套)私有的訊息格式 - **Transfer/Network Protocol:** **傳輸協議層負責管理RPC框架所使用的網路協議,網路IO模型.** 傳輸層還需要統一RPC客戶端和RPC服務端所使用的IO模型 - **Selector/Processor:** 存在於RPC服務端，用於伺服器端某一個RPC介面的實現的特性(它並不知道自己是一個將要被RPC提供給第三方系統呼叫的服務).所以在RPC框架中應該有一種 "**負責執行RPC介面實現**" 的角色.包括:**管理RPC介面的註冊,判斷客戶端的請求許可權,控制介面實現類的執行在內** - **IDL:** IDL(介面定義語言)並不是RPC實現中所必須的.但是需要跨語言的RPC框架一定會有IDL部分的存在.這是因為要找到一個**各種語言能夠理解的訊息結構、介面定義的描述形式**.**如果RPC實現沒有考慮跨語言性，那麼IDL部分就不需要包括**,例如JAVA RMI因為就是為了在JAVA語言間進行使用，所以JAVA RMI就沒有相應的IDL 不同的RPC框架實現都有一定設計差異。例如生成Stub的方式不一樣，IDL描述語言不一樣、服務註冊的管理方式不一樣、執行服務實現的方式不一樣、採用的訊息格式封裝不一樣、採用的網路協議不一樣。但是基本的思路都是一樣的，上圖中的所列出的要素也都是具有的 ##### 影響RPC框架效能的因素  - **使用的網路IO模型:** RPC伺服器可以只支援傳統的阻塞式同步IO,也可以做一些改進讓RPC伺服器支援非阻塞式同步IO,或者在伺服器上實現對多路IO模型的支援.這樣的RPC伺服器的效能在高併發狀態下,會有很大的差別.特別是單位處理效能下對記憶體,CPU資源的使用率 - **基於的網路協議:** 一般來說可以選擇讓RPC使用應用層協議,例如HTTP或者HTTP/2協議,或者使用TCP協議.讓RPC框架工作在傳輸層.工作在哪一層網路上會對RPC框架的工作效能產生一定的影響,但是對RPC最終的效能影響並不大.但是至少從各種主流的RPC實現來看,沒有采用UDP協議做為主要的傳輸協議的 - **訊息封裝格式:** 選擇或者定義一種訊息格式的封裝,要考慮的問題包括:**訊息的易讀性,描述單位內容時的訊息體大小,編碼難度,解碼難度,解決半包/粘包問題的難易度.** 當然如果您只是想定義一種RPC專用的訊息格式,那麼訊息的易讀性可能不是最需要考慮的.訊息封裝格式的設計是目前各種RPC框架效能差異的最重要原因,這就是為什麼幾乎所有主流的RPC框架都會設計私有的訊息封裝格式的原因.**dubbo**中訊息體資料包含**dubbo版本號,介面名稱,介面版本,方法名稱,引數型別列表,引數,附加資訊** - **序列化和反序列化(Schema & Data Serialization):** 序列化和反序列化,是物件到二進位制資料的轉換,程式是可以理解物件的,物件一般含有 schema 或者結構,基於這些語義來做特定的業務邏輯處理. ``` 序列化框架一般會關注以下幾點: Encoding format:是human readable(是否能直觀看懂 json)還是binary(二進位制) Schema declaration:也叫作契約宣告,基於IDL,比如 Protocol Buffers/Thrift.還是自描述的,比如 JSON、XML.另外還需要看是否是強型別的 語言平臺的中立性:比如Java的Native Serialization就只能自己玩,而Protocol Buffers可以跨各種語言和平臺 新老契約的相容性:比如IDL加了一個欄位,老資料是否還可以反序列化成。 和壓縮演算法的契合度 :執行benchmark(基準)和實際應用都會結合各種壓縮演算法,例如gzip,snappy 效能 :這是最重要的,序列化,反序列化的時間,序列化後資料的位元組大小是考察重點。 序列化方式非常多,常見的有Protocol Buffers,Avro,Thrift,XML,JSON,MessagePack,Kyro,Hessian,Protostuff,Java Native Serialize,FST ``` - **實現的服務處理管理方式:** 在高併發請求下,如何管理註冊的服務也是一個性能影響點.可以讓RPC的Selector/Processor使用單個執行緒執行服務的具體實現(這意味著上一個客戶端的請求沒有處理完,下一個客戶端的請求就需要等待). 也可以為每一個RPC具體服務的實現開啟一個獨立的執行緒執行(可以一次處理多個請求,但是作業系統對於“可執行的最大執行緒數”是有限制的). 也可以執行緒池來執行RPC具體的服務實現(目前看來，在單個服務節點的情況下,這種方式是比較好的). 還可以通過註冊代理的方式讓多個服務節點來執行具體的RPC服務實現 ##### 工業界的 RPC 框架 - **國內** - **Dubbo:** 來自阿里巴巴[http://dubbo.I/O/](http://dubbo.I/O/) - **Motan:** 新浪微博自用[https://github.com/weibocom/motan ](https://github.com/weibocom/motan) - **Dubbox:** 噹噹基於 dubbo 的[https://github.com/dangdangdotcom/dubbox](https://github.com/dangdangdotcom/dubbox) - **rpcx:** 基於 Golang 的[https://github.com/smallnest/rpcx](https://github.com/smallnest/rpcx) - **國外** - **Thrift from facebook:**[https://thrift.apache.org](https://thrift.apache.org) - **Avro from hadoop:**[https://avro.apache.org](https://avro.apache.org) - **Finagle by twitter:**[https://twitter.github.I/O/finagle](https://twitter.github.I/O/finagle) - **gRPC by Google:**[http://www.grpc.I/O](http://www.grpc.I/O)(Google inside use Stuppy) - **Hessian from cuacho:**[http://hessian.caucho.com](http://hessian.caucho.com) - **Coral Service inside amazon:** not open sourced ##### 如何選擇RPC框架 選擇一個rpc框架會基於多方面的考慮:**框架特性、效能、成熟度、技術支援、社群活躍度等**多個方面.最重要一點,這也是往往很多技術人員進入的誤區, "對於技術，不要為了使用而使用,**用最簡單合適的技術實現解決問題才是正道**" .**架構是服務於業務的,能快速方便的滿足業務需求的架構才是好的架構**.沒有最好的,只有適合自己的 ## Dubbo - Dubbo是一個開源分散式服務框架,阿里巴巴公司開源的一個高效能優秀的服務框架,使得應用可通過高效能的 RPC 實現服務的輸出和輸入功能,可以和Spring框架無縫整合. - Dubbo是一款高效能,輕量級的開源Java RPC框架,它提供了三大核心能力:**面向介面的遠端方法呼叫,智慧容錯和負載均衡,以及服務自動註冊和發現** ##### 核心元件 - **Remoting:** 網路通訊框架，實現了**sync-over-async**和**request-response**訊息機制 - **RPC:** 一個遠端過程呼叫的抽象.支援負載均衡,容災和叢集功能 - **Registry:** 服務目錄框架,用於服務的註冊和服務事件釋出和訂閱 ##### 工作原理  ``` Provider:暴露服務方稱之為“服務提供者” Consumer:呼叫遠端服務方稱之為“服務消費者” Registry:服務註冊與發現的中心目錄服務稱之為“服務註冊中心” Monitor:統計服務的呼叫次數和呼叫時間的日誌服務稱之為“服務監控中心” 連通性： 註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力較小 監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示 服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷 服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷 註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外 註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者 註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表 註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者 健壯性： 監控中心宕掉不影響使用，只是丟失部分取樣資料 資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務 註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺 註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊 服務提供者無狀態，任意一臺宕掉後，不影響使用 服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復 伸縮性： 註冊中心為對等叢集，可動態增加機器部署例項，所有客戶端將自動發現新的註冊中心 服務提供者無狀態，可動態增加機器部署例項，註冊中心將推送新的服務提供者資訊給消費者 ``` ##### Dubbo特性 - **面向介面代理的高效能RPC呼叫:** 提供高效能的基於代理的遠端呼叫能力,服務以介面為粒度,為開發者遮蔽遠端呼叫底層細節 - **智慧負載均衡:** 內建多種負載均衡策略,智慧感知下游節點健康狀況,顯著減少呼叫延遲,提高系統吞吐量 - **服務自動註冊與發現:** 支援多種註冊中心服務,服務例項上下線實時感知 - **高度可擴充套件能力:** 遵循微核心+外掛的設計原則,所有核心能力如**Protocol,Transport,Serialization**被設計為擴充套件點,平等對待內建實現和第三方實現 - **執行期流量排程:** 內建條件,指令碼等路由策略.通過配置不同的路由規則,輕鬆實現灰度釋出,同機房優先等功能 - **視覺化的服務治理與運維:** 提供豐富服務治理,運維工具:隨時查詢服務元資料,服務健康狀態及呼叫統計,實時下發路由策略,調整配置引數 ##### 使用示例    ## Zuul - **Zuul**是netflix開源的一個API Gateway 伺服器, 本質上是一個web servlet應用 -**Zuul**是一個基於JVM路由和服務端的負載均衡器,提供動態路由，監控，彈性，安全等邊緣服務的框架,相當於是裝置和 Netflix 流應用的 Web 網站後端所有請求的前門 ##### Zuul工作原理 - **過濾器機制** - Zuul提供了一個框架，可以對過濾器進行動態的載入，編譯，執行 ``` 1.Zuul的過濾器之間沒有直接的相互通訊，他們之間通過一個RequestContext的靜態類來進行資料傳遞的。RequestContext類中有ThreadLocal變數來記錄每個Request所需要傳遞的資料 2.Zuul的過濾器是由Groovy寫成，這些過濾器檔案被放在Zuul Server上的特定目錄下面，Zuul會定期輪詢這些目錄，修改過的過濾器會動態的載入到Zuul Server中以便過濾請求使用 ``` - **標準過濾器型別:** Zuul大部分功能都是通過過濾器來實現的。Zuul中定義了四種標準過濾器型別，這些過濾器型別對應於請求的典型生命週期 - **PRE:** 在請求被路由之前呼叫,利用這種過濾器實現身份驗證、在叢集中選擇請求的微服務、記錄除錯資訊等 - **ROUTING:** 請求路由到微服務,用於構建傳送給微服務的請求,使用Apache HttpClient或Netfilx Ribbon請求微服務 - **POST:** 在路由到微服務以後執行,用來為響應新增標準的HTTP Header、收集統計資訊和指標、將響應從微服務傳送給客戶端等 - **ERROR:** 在其他階段發生錯誤時執行該過濾器 - **內建的特殊過濾器:** - **StaticResponseFilter:** StaticResponseFilter允許從Zuul本身生成響應，而不是將請求轉發到源 - **SurgicalDebugFilter:** SurgicalDebugFilter允許將特定請求路由到分隔的除錯叢集或主機 - **自定義的過濾器:** 除了預設的過濾器型別，Zuul還允許我們建立自定義的過濾器型別。如STATIC型別的過濾器，直接在Zuul中生成響應，而不將請求轉發到後端的微服務 - **過濾器的生命週期** Zuul請求的生命週期詳細描述了各種型別的過濾器的執行順序  - **過濾器排程過程**  - **動態載入過濾器**  ##### Zuul的作用 Zuul可以通過載入動態過濾機制實現Zuul的功能: - **驗證與安全保障:** 識別面向各類資源的驗證要求並拒絕那些與要求不符的請求 - **審查與監控:** 在邊緣位置追蹤有意義資料及統計結果，得到準確的生產狀態結論 - **動態路由:** 以動態方式根據需要將請求路由至不同後端叢集處 - **壓力測試:** 逐漸增加指向叢集的負載流量，從而計算效能水平 - **負載分配:** 為每一種負載型別分配對應容量，並棄用超出限定值的請求 - **靜態響應處理:** 在邊緣位置直接建立部分響應，從而避免其流入內部叢集 - **多區域彈性:** 跨越AWS區域進行請求路由，旨在實現ELB使用多樣化並保證邊緣位置與使用者儘可能接近 ##### Zuul與應用的整合方式 - **ZuulServlet - 處理請求(排程不同階段的filters，處理異常等)** - 所有的Request都要經過ZuulServlet的處理, - Zuul對request處理邏輯的三個核心的方法: **preRoute(),route(), postRoute()** - ZuulServletZuulServlet交給ZuulRunner去執行。由於ZuulServlet是單例，因此ZuulRunner也僅有一個例項。ZuulRunner直接將執行邏輯交由FilterProcessor處理，FilterProcessor也是單例，其功能就是依據filterType執行filter的處理邏輯 - **FilterProcessor對filter的處理邏輯:** ``` 1.首先根據Type獲取所有輸入該Type的fil