微服務(wù)整體框架

• 開發(fā)前后臺(tái)分離：前臺(tái)與后臺(tái)之間，通過 Restful 風(fēng)格接口通信（HTTP協(xié)議）
• 內(nèi)部服務(wù)： Dubbo （ RPC框架）
• 外部服務(wù)： SpringCloud Zuul （提供Restful API接口）
   

  

  錦江網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)建站2013年至今到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。
  

• 微服務(wù)應(yīng)用開發(fā)  

API Gateway

• API Gateway :網(wǎng)關(guān),統(tǒng)一應(yīng)用請求接口.API 網(wǎng)關(guān)在微服務(wù)們的最前端,讓 API 網(wǎng)關(guān)變成由應(yīng)用所發(fā)起的每個(gè)請求的入口，簡化客戶端實(shí)現(xiàn)和微服務(wù)應(yīng)用程序間的溝通方式。

API Gateway兩種方式:

• 單節(jié)點(diǎn)API Gateway
   

• BFF (Backends for frontends) Gateway
   

API Gateway的作用

• 請求路由，版本控制: API Gateway 是微服務(wù)的入口，可以根據(jù)不同的請求路由到不同的服務(wù)上. 也可以進(jìn)行路由的版本控制，這樣即使后服務(wù)發(fā)生了變化，Gateway 的路徑依然可以不改變
• 用戶登錄，權(quán)限認(rèn)證: 客戶端在與我們后端服務(wù)進(jìn)行交互之前，由API Gateway先進(jìn)行登錄鑒權(quán)操作，這是后端所有的服務(wù)都需要有的共有邏輯
• 數(shù)據(jù)聚合: 由于不同的客戶端往往需要的數(shù)據(jù)完全不同，而這些數(shù)據(jù)又是不同的 service 提供的，可以借助 Gateway 方便完成來自不同 service 的數(shù)據(jù)聚合
• 協(xié)議轉(zhuǎn)換： 在項(xiàng)目實(shí)踐中，CS（Client to Server）協(xié)議和SS（Server to Server）協(xié)議是不一樣的，為了保證數(shù)據(jù)傳輸?shù)目煽啃?，CS協(xié)議會(huì)有鑒權(quán)以及加密解密的邏輯，而在內(nèi)部的SS協(xié)議則不需要這些邏輯，因此在 Gateway 我們需要有一個(gè)協(xié)議轉(zhuǎn)換的過程
• 熔斷，降級(jí)，限流: 通過API Gateway可以在監(jiān)測到某個(gè)服務(wù)發(fā)生異常，或者當(dāng)服務(wù)的流量超過服務(wù)的承載能力等情況時(shí)，可以采取相應(yīng)的措施. 提高整個(gè)系統(tǒng)的容錯(cuò)性、穩(wěn)定性
• 負(fù)載均衡: API Gateway知道所有服務(wù)實(shí)例的地址，可以根據(jù)不同服務(wù)采取不同的負(fù)載均衡策略
• 灰度發(fā)布: 灰度發(fā)布允許直接只導(dǎo)入指定量的流量請求到新的版本

API Gateway的架構(gòu)

• 多網(wǎng)關(guān)集群(Backends for frontends): 針對不同的客戶端，都有相應(yīng)的網(wǎng)關(guān)層來接入.功能主要有：用戶登錄，鑒權(quán)，服務(wù)發(fā)現(xiàn)注冊，協(xié)議轉(zhuǎn)換，接口版本控制等以及監(jiān)控，APM調(diào)用鏈，日志，流控策略等
• 聚合服務(wù)(Merge Service): 在某些客戶端的需求中，需要從多個(gè)服務(wù)拉取數(shù)據(jù)，為了減少客戶端的復(fù)雜度，以及加快客戶端的訪問速度，可以加一個(gè)聚合層，用來做聚合查詢，在某些接口中可以把多個(gè)服務(wù)的數(shù)據(jù)一次性返回給客戶端
• 儀表盤管理端(Dashboard): Dashboard 提供可視化的分析平臺(tái)，包括服務(wù)的管理，監(jiān)控?cái)?shù)據(jù)報(bào)警配置，日志查詢，灰度發(fā)布操作，API文檔管理等

Eureka(服務(wù)發(fā)現(xiàn)框架)

• Eureka是一個(gè)基于REST的服務(wù),主要用于定位運(yùn)行在AWS域中的中間層服務(wù)，以達(dá)到負(fù)載均衡和中間層服務(wù)故障轉(zhuǎn)移的目的. SpringCloud將它集成在其子項(xiàng)目spring-cloud-netflix中，以實(shí)現(xiàn)SpringCloud的服務(wù)發(fā)現(xiàn)功能

Eureka的兩個(gè)組件

• Eureka Server: Eureka Server提供服務(wù)注冊服務(wù)，各個(gè)節(jié)點(diǎn)啟動(dòng)后，會(huì)在Eureka Server中進(jìn)行注冊，這樣EurekaServer中的服務(wù)注冊表中將會(huì)存儲(chǔ)所有可用服務(wù)節(jié)點(diǎn)的信息，服務(wù)節(jié)點(diǎn)的信息可以在界面中看到. Eureka Server之間通過復(fù)制的方式完成數(shù)據(jù)的同步
• Eureka Client: 是一個(gè)java客戶端，用于簡化與Eureka Server的交互，客戶端同時(shí)也就是一個(gè)內(nèi)置的、使用輪詢(round-robin)負(fù)載算法的負(fù)載均衡器
• Eureka通過心跳檢查、客戶端緩存等機(jī)制，確保了系統(tǒng)的高可用性、靈活性和可伸縮性
  • 在應(yīng)用啟動(dòng)后，將會(huì)向Eureka Server發(fā)送心跳, 如果Eureka Server在多個(gè)心跳周期內(nèi)沒有接收到某個(gè)節(jié)點(diǎn)的心跳，Eureka Server將會(huì)從服務(wù)注冊表中把這個(gè)服務(wù)節(jié)點(diǎn)移除。
  • Eureka還提供了客戶端緩存機(jī)制，即使所有的Eureka Server都掛掉，客戶端依然可以利用緩存中的信息消費(fèi)其他服務(wù)的API。Eureka通過心跳檢查、客戶端緩存等機(jī)制，確保了系統(tǒng)的高可用性、靈活性和可伸縮性

RPC框架

RPC定義

• RPC(Remote Procedure Call Protocol): 遠(yuǎn)程過程調(diào)用協(xié)議,一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議.也就是

客戶端在不知道調(diào)用細(xì)節(jié)的情況下，調(diào)用存在于遠(yuǎn)程計(jì)算機(jī)上的某個(gè)對象，就像調(diào)用本地應(yīng)用程序中的對象一樣

• RPC是協(xié)議: 協(xié)議就是一套規(guī)范,目前典型的RPC實(shí)現(xiàn)包括:Dubbo,Thrift,GRPC,Hetty等.從目前技術(shù)的發(fā)展趨勢來看,實(shí)現(xiàn)了RPC協(xié)議的應(yīng)用工具往往都會(huì)附加其他重要功能
• 網(wǎng)絡(luò)協(xié)議和網(wǎng)絡(luò)IO模型對其透明: 既然RPC的客戶端認(rèn)為自己是在調(diào)用本地對象。那么傳輸層使用的是TCP/UDP還是HTTP協(xié)議，又或者是一些其他的網(wǎng)絡(luò)協(xié)議它就不需要關(guān)心了。既然網(wǎng)絡(luò)協(xié)議對其透明，那么調(diào)用過程中，使用的是哪一種網(wǎng)絡(luò)IO模型調(diào)用者也不需要關(guān)心
• 信息格式對其透明: 我們知道在本地應(yīng)用程序中，對于某個(gè)對象的調(diào)用需要傳遞一些參數(shù)，并且會(huì)返回一個(gè)調(diào)用結(jié)果。至于被調(diào)用的對象內(nèi)部是如何使用這些參數(shù)，并計(jì)算出處理結(jié)果的，調(diào)用方是不需要關(guān)心的。那么對于遠(yuǎn)程調(diào)用來說，這些參數(shù)會(huì)以某種信息格式傳遞給網(wǎng)絡(luò)上的另外一臺(tái)計(jì)算機(jī)，這個(gè)信息格式是怎樣構(gòu)成的，調(diào)用方是不需要關(guān)心的
• 應(yīng)該有跨語言能力: 調(diào)用方實(shí)際上也不清楚遠(yuǎn)程服務(wù)器的應(yīng)用程序是使用什么語言運(yùn)行的。那么對于調(diào)用方來說，無論服務(wù)器方使用的是什么語言，本次調(diào)用都應(yīng)該成功，并且返回值也應(yīng)該按照調(diào)用方程序語言所能理解的形式進(jìn)行描述
   

RPC主要組成部分

• Client: RPC協(xié)議的調(diào)用方.最理想的情況是RPC Client在完全不知道有RPC框架存在的情況下發(fā)起對遠(yuǎn)程服務(wù)的調(diào)用.但實(shí)際情況來說Client或多或少的都需要指定RPC框架的一些細(xì)節(jié)
• Server: 在RPC規(guī)范中，這個(gè)Server并不是提供RPC服務(wù)器IP,端口監(jiān)聽的模塊。而是 遠(yuǎn)程服務(wù)方法的具體實(shí)現(xiàn)(在JAVA中就是RPC服務(wù)接口的具體實(shí)現(xiàn)) .其中的代碼是最普通的和業(yè)務(wù)相關(guān)的代碼，甚至其接口實(shí)現(xiàn)類本身都不知道將被某一個(gè)RPC遠(yuǎn)程客戶端調(diào)用
• Stub/Proxy: RPC代理存在于客戶端，因?yàn)橐獙?shí)現(xiàn)客戶端對RPC框架“透明”調(diào)用，那么客戶端不可能自行去管理消息格式、不可能自己去管理網(wǎng)絡(luò)傳輸協(xié)議，也不可能自己去判斷調(diào)用過程是否有異常。這一切工作在客戶端都是交給RPC框架中的“代理”層來處理的
• Message Protocol: 一次完整的client-server的交互肯定是攜帶某種兩端都能識(shí)別的,共同約定的消息格式. RPC的消息管理層專門對網(wǎng)絡(luò)傳輸所承載的消息信息進(jìn)行編碼和解碼操作 .目前流行的技術(shù)趨勢是不同的RPC實(shí)現(xiàn),為了加強(qiáng)自身框架的效率都有一套(或者幾套)私有的消息格式
• Transfer/Network Protocol: 傳輸協(xié)議層負(fù)責(zé)管理RPC框架所使用的網(wǎng)絡(luò)協(xié)議,網(wǎng)絡(luò)IO模型. 傳輸層還需要統(tǒng)一RPC客戶端和RPC服務(wù)端所使用的IO模型
• Selector/Processor: 存在于RPC服務(wù)端，用于服務(wù)器端某一個(gè)RPC接口的實(shí)現(xiàn)的特性(它并不知道自己是一個(gè)將要被RPC提供給第三方系統(tǒng)調(diào)用的服務(wù)).所以在RPC框架中應(yīng)該有一種 " 負(fù)責(zé)執(zhí)行RPC接口實(shí)現(xiàn) " 的角色.包括: 管理RPC接口的注冊,判斷客戶端的請求權(quán)限,控制接口實(shí)現(xiàn)類的執(zhí)行在內(nèi)
• IDL: IDL(接口定義語言)并不是RPC實(shí)現(xiàn)中所必須的.但是需要跨語言的RPC框架一定會(huì)有IDL部分的存在.這是因?yàn)橐业揭粋€(gè) 各種語言能夠理解的消息結(jié)構(gòu)、接口定義的描述形式 . 如果RPC實(shí)現(xiàn)沒有考慮跨語言性，那么IDL部分就不需要包括 ,例如JAVA RMI因?yàn)榫褪菫榱嗽贘AVA語言間進(jìn)行使用，所以JAVA RMI就沒有相應(yīng)的IDL

不同的RPC框架實(shí)現(xiàn)都有一定設(shè)計(jì)差異。例如生成Stub的方式不一樣，IDL描述語言不一樣、服務(wù)注冊的管理方式不一樣、運(yùn)行服務(wù)實(shí)現(xiàn)的方式不一樣、采用的消息格式封裝不一樣、采用的網(wǎng)絡(luò)協(xié)議不一樣。但是基本的思路都是一樣的，上圖中的所列出的要素也都是具有的

影響RPC框架性能的因素

• 使用的網(wǎng)絡(luò)IO模型: RPC服務(wù)器可以只支持傳統(tǒng)的阻塞式同步IO,也可以做一些改進(jìn)讓RPC服務(wù)器支持非阻塞式同步IO,或者在服務(wù)器上實(shí)現(xiàn)對多路IO模型的支持.這樣的RPC服務(wù)器的性能在高并發(fā)狀態(tài)下,會(huì)有很大的差別.特別是單位處理性能下對內(nèi)存,CPU資源的使用率
• 基于的網(wǎng)絡(luò)協(xié)議: 一般來說可以選擇讓RPC使用應(yīng)用層協(xié)議,例如HTTP或者HTTP/2協(xié)議,或者使用TCP協(xié)議.讓RPC框架工作在傳輸層.工作在哪一層網(wǎng)絡(luò)上會(huì)對RPC框架的工作性能產(chǎn)生一定的影響,但是對RPC最終的性能影響并不大.但是至少從各種主流的RPC實(shí)現(xiàn)來看,沒有采用UDP協(xié)議做為主要的傳輸協(xié)議的
• 消息封裝格式: 選擇或者定義一種消息格式的封裝,要考慮的問題包括: 消息的易讀性,描述單位內(nèi)容時(shí)的消息體大小,編碼難度,解碼難度,解決半包/粘包問題的難易度. 當(dāng)然如果您只是想定義一種RPC專用的消息格式,那么消息的易讀性可能不是最需要考慮的.消息封裝格式的設(shè)計(jì)是目前各種RPC框架性能差異的最重要原因,這就是為什么幾乎所有主流的RPC框架都會(huì)設(shè)計(jì)私有的消息封裝格式的原因. dubbo 中消息體數(shù)據(jù)包含 dubbo版本號(hào),接口名稱,接口版本,方法名稱,參數(shù)類型列表,參數(shù),附加信息
• 序列化和反序列化(Schema & Data Serialization): 序列化和反序列化,是對象到二進(jìn)制數(shù)據(jù)的轉(zhuǎn)換,程序是可以理解對象的,對象一般含有 schema 或者結(jié)構(gòu),基于這些語義來做特定的業(yè)務(wù)邏輯處理.

序列化框架一般會(huì)關(guān)注以下幾點(diǎn):

1. Encoding format:是human readable(是否能直觀看懂 json)還是binary(二進(jìn)制)
2. Schema declaration:也叫作契約聲明,基于IDL,比如 Protocol Buffers/Thrift.還是自描述的,比如 JSON、XML.另外還需要看是否是強(qiáng)類型的
3. 語言平臺(tái)的中立性:比如Java的Native Serialization就只能自己玩,而Protocol Buffers可以跨各種語言和平臺(tái)
4. 新老契約的兼容性:比如IDL加了一個(gè)字段,老數(shù)據(jù)是否還可以反序列化成。
5. 和壓縮算法的契合度 :運(yùn)行benchmark(基準(zhǔn))和實(shí)際應(yīng)用都會(huì)結(jié)合各種壓縮算法,例如gzip,snappy
6. 性能 :這是最重要的,序列化,反序列化的時(shí)間,序列化后數(shù)據(jù)的字節(jié)大小是考察重點(diǎn)。
7. 序列化方式非常多,常見的有Protocol Buffers,Avro,Thrift,XML,JSON,MessagePack,Kyro,Hessian,Protostuff,Java Native Serialize,FST

• 實(shí)現(xiàn)的服務(wù)處理管理方式: 在高并發(fā)請求下,如何管理注冊的服務(wù)也是一個(gè)性能影響點(diǎn).可以讓RPC的Selector/Processor使用單個(gè)線程運(yùn)行服務(wù)的具體實(shí)現(xiàn)(這意味著上一個(gè)客戶端的請求沒有處理完,下一個(gè)客戶端的請求就需要等待). 也可以為每一個(gè)RPC具體服務(wù)的實(shí)現(xiàn)開啟一個(gè)獨(dú)立的線程運(yùn)行(可以一次處理多個(gè)請求,但是操作系統(tǒng)對于“可運(yùn)行的最大線程數(shù)”是有限制的). 也可以線程池來運(yùn)行RPC具體的服務(wù)實(shí)現(xiàn)(目前看來，在單個(gè)服務(wù)節(jié)點(diǎn)的情況下,這種方式是比較好的). 還可以通過注冊代理的方式讓多個(gè)服務(wù)節(jié)點(diǎn)來運(yùn)行具體的RPC服務(wù)實(shí)現(xiàn)

工業(yè)界的 RPC 框架

• 國內(nèi)
  • Dubbo: 來自阿里巴巴 http://dubbo.I/O/
  • Motan: 新浪微博自用 https://github.com/weibocom/motan
  • Dubbox: 當(dāng)當(dāng)基于 dubbo 的 https://github.com/dangdangdotcom/dubbox
  • rpcx: 基于 Golang 的 https://github.com/smallnest/rpcx
• 國外
  • Thrift from facebook: https://thrift.apache.org
  • Avro from hadoop: https://avro.apache.org
  • Finagle by twitter: https://twitter.github.I/O/finagle
  • gRPC by Google: http://www.grpc.I/O (Google inside use Stuppy)
  • Hessian from cuacho: http://hessian.caucho.com
  • Coral Service inside amazon: not open sourced

如何選擇RPC框架

選擇一個(gè)rpc框架會(huì)基于多方面的考慮: 框架特性、性能、成熟度、技術(shù)支持、社區(qū)活躍度等 多個(gè)方面.最重要一點(diǎn),這也是往往很多技術(shù)人員進(jìn)入的誤區(qū), "對于技術(shù)，不要為了使用而使用, 用最簡單合適的技術(shù)實(shí)現(xiàn)解決問題才是正道 " . 架構(gòu)是服務(wù)于業(yè)務(wù)的,能快速方便的滿足業(yè)務(wù)需求的架構(gòu)才是好的架構(gòu) .沒有最好的,只有適合自己的

Dubbo

• Dubbo是一個(gè)開源分布式服務(wù)框架,阿里巴巴公司開源的一個(gè)高性能優(yōu)秀的服務(wù)框架,使得應(yīng)用可通過高性能的 RPC 實(shí)現(xiàn)服務(wù)的輸出和輸入功能,可以和Spring框架無縫集成.
• Dubbo是一款高性能,輕量級(jí)的開源Java RPC框架,它提供了三大核心能力: 面向接口的遠(yuǎn)程方法調(diào)用,智能容錯(cuò)和負(fù)載均衡,以及服務(wù)自動(dòng)注冊和發(fā)現(xiàn)

核心組件

• Remoting: 網(wǎng)絡(luò)通信框架，實(shí)現(xiàn)了 sync-over-async 和 request-response 消息機(jī)制
• RPC: 一個(gè)遠(yuǎn)程過程調(diào)用的抽象.支持負(fù)載均衡,容災(zāi)和集群功能
• Registry: 服務(wù)目錄框架,用于服務(wù)的注冊和服務(wù)事件發(fā)布和訂閱

工作原理

Provider:暴露服務(wù)方稱之為“服務(wù)提供者”

Consumer:調(diào)用遠(yuǎn)程服務(wù)方稱之為“服務(wù)消費(fèi)者”

Registry:服務(wù)注冊與發(fā)現(xiàn)的中心目錄服務(wù)稱之為“服務(wù)注冊中心”

Monitor:統(tǒng)計(jì)服務(wù)的調(diào)用次數(shù)和調(diào)用時(shí)間的日志服務(wù)稱之為“服務(wù)監(jiān)控中心”

連通性：

注冊中心負(fù)責(zé)服務(wù)地址的注冊與查找，相當(dāng)于目錄服務(wù)，服務(wù)提供者和消費(fèi)者只在啟動(dòng)時(shí)與注冊中心交互，注冊中心不轉(zhuǎn)發(fā)請求，壓力較小

監(jiān)控中心負(fù)責(zé)統(tǒng)計(jì)各服務(wù)調(diào)用次數(shù)，調(diào)用時(shí)間等，統(tǒng)計(jì)先在內(nèi)存匯總后每分鐘一次發(fā)送到監(jiān)控中心服務(wù)器，并以報(bào)表展示

服務(wù)提供者向注冊中心注冊其提供的服務(wù)，并匯報(bào)調(diào)用時(shí)間到監(jiān)控中心，此時(shí)間不包含網(wǎng)絡(luò)開銷

服務(wù)消費(fèi)者向注冊中心獲取服務(wù)提供者地址列表，并根據(jù)負(fù)載算法直接調(diào)用提供者，同時(shí)匯報(bào)調(diào)用時(shí)間到監(jiān)控中心，此時(shí)間包含網(wǎng)絡(luò)開銷

注冊中心，服務(wù)提供者，服務(wù)消費(fèi)者三者之間均為長連接，監(jiān)控中心除外

注冊中心通過長連接感知服務(wù)提供者的存在，服務(wù)提供者宕機(jī)，注冊中心將立即推送事件通知消費(fèi)者

注冊中心和監(jiān)控中心全部宕機(jī)，不影響已運(yùn)行的提供者和消費(fèi)者，消費(fèi)者在本地緩存了提供者列表

注冊中心和監(jiān)控中心都是可選的，服務(wù)消費(fèi)者可以直連服務(wù)提供者

健壯性：

監(jiān)控中心宕掉不影響使用，只是丟失部分采樣數(shù)據(jù)

數(shù)據(jù)庫宕掉后，注冊中心仍能通過緩存提供服務(wù)列表查詢，但不能注冊新服務(wù)

注冊中心對等集群，任意一臺(tái)宕掉后，將自動(dòng)切換到另一臺(tái)

注冊中心全部宕掉后，服務(wù)提供者和服務(wù)消費(fèi)者仍能通過本地緩存通訊

服務(wù)提供者無狀態(tài)，任意一臺(tái)宕掉后，不影響使用

服務(wù)提供者全部宕掉后，服務(wù)消費(fèi)者應(yīng)用將無法使用，并無限次重連等待服務(wù)提供者恢復(fù)

伸縮性：

注冊中心為對等集群，可動(dòng)態(tài)增加機(jī)器部署實(shí)例，所有客戶端將自動(dòng)發(fā)現(xiàn)新的注冊中心

服務(wù)提供者無狀態(tài)，可動(dòng)態(tài)增加機(jī)器部署實(shí)例，注冊中心將推送新的服務(wù)提供者信息給消費(fèi)者

Dubbo特性

• 面向接口代理的高性能RPC調(diào)用: 提供高性能的基于代理的遠(yuǎn)程調(diào)用能力,服務(wù)以接口為粒度,為開發(fā)者屏蔽遠(yuǎn)程調(diào)用底層細(xì)節(jié)
• 智能負(fù)載均衡: 內(nèi)置多種負(fù)載均衡策略,智能感知下游節(jié)點(diǎn)健康狀況,顯著減少調(diào)用延遲,提高系統(tǒng)吞吐量
• 服務(wù)自動(dòng)注冊與發(fā)現(xiàn): 支持多種注冊中心服務(wù),服務(wù)實(shí)例上下線實(shí)時(shí)感知
• 高度可擴(kuò)展能力: 遵循微內(nèi)核+插件的設(shè)計(jì)原則,所有核心能力如 Protocol,Transport,Serialization 被設(shè)計(jì)為擴(kuò)展點(diǎn),平等對待內(nèi)置實(shí)現(xiàn)和第三方實(shí)現(xiàn)
• 運(yùn)行期流量調(diào)度: 內(nèi)置條件,腳本等路由策略.通過配置不同的路由規(guī)則,輕松實(shí)現(xiàn)灰度發(fā)布,同機(jī)房優(yōu)先等功能
• 可視化的服務(wù)治理與運(yùn)維: 提供豐富服務(wù)治理,運(yùn)維工具:隨時(shí)查詢服務(wù)元數(shù)據(jù),服務(wù)健康狀態(tài)及調(diào)用統(tǒng)計(jì),實(shí)時(shí)下發(fā)路由策略,調(diào)整配置參數(shù)

使用示例

Zuul

• Zuul是netflix開源的一個(gè)API Gateway 服務(wù)器, 本質(zhì)上是一個(gè)web servlet應(yīng)用

  - Zuul 是一個(gè)基于JVM路由和服務(wù)端的負(fù)載均衡器,提供動(dòng)態(tài)路由，監(jiān)控，彈性，安全等邊緣服務(wù)的框架,相當(dāng)于是設(shè)備和 Netflix 流應(yīng)用的 Web 網(wǎng)站后端所有請求的前門

Zuul工作原理

• 過濾器機(jī)制
  • Zuul提供了一個(gè)框架，可以對過濾器進(jìn)行動(dòng)態(tài)的加載，編譯，運(yùn)行

  1.Zuul的過濾器之間沒有直接的相互通信，他們之間通過一個(gè)RequestContext的靜態(tài)類來進(jìn)行數(shù)據(jù)傳遞的。RequestContext類中有ThreadLocal變量來記錄每個(gè)Request所需要傳遞的數(shù)據(jù)
  2.Zuul的過濾器是由Groovy寫成，這些過濾器文件被放在Zuul Server上的特定目錄下面，Zuul會(huì)定期輪詢這些目錄，修改過的過濾器會(huì)動(dòng)態(tài)的加載到Zuul Server中以便過濾請求使用

  • 標(biāo)準(zhǔn)過濾器類型:
    Zuul大部分功能都是通過過濾器來實(shí)現(xiàn)的。Zuul中定義了四種標(biāo)準(zhǔn)過濾器類型，這些過濾器類型對應(yīng)于請求的典型生命周期
    • PRE: 在請求被路由之前調(diào)用,利用這種過濾器實(shí)現(xiàn)身份驗(yàn)證、在集群中選擇請求的微服務(wù)、記錄調(diào)試信息等
    • ROUTING: 請求路由到微服務(wù),用于構(gòu)建發(fā)送給微服務(wù)的請求,使用Apache HttpClient或Netfilx Ribbon請求微服務(wù)
    • POST: 在路由到微服務(wù)以后執(zhí)行,用來為響應(yīng)添加標(biāo)準(zhǔn)的HTTP Header、收集統(tǒng)計(jì)信息和指標(biāo)、將響應(yīng)從微服務(wù)發(fā)送給客戶端等
    • ERROR: 在其他階段發(fā)生錯(cuò)誤時(shí)執(zhí)行該過濾器
  • 內(nèi)置的特殊過濾器:
    • StaticResponseFilter: StaticResponseFilter允許從Zuul本身生成響應(yīng)，而不是將請求轉(zhuǎn)發(fā)到源
    • SurgicalDebugFilter: SurgicalDebugFilter允許將特定請求路由到分隔的調(diào)試集群或主機(jī)
  • 自定義的過濾器:
    除了默認(rèn)的過濾器類型，Zuul還允許我們創(chuàng)建自定義的過濾器類型。如STATIC類型的過濾器，直接在Zuul中生成響應(yīng)，而不將請求轉(zhuǎn)發(fā)到后端的微服務(wù)

• 過濾器的生命周期
  Zuul請求的生命周期詳細(xì)描述了各種類型的過濾器的執(zhí)行順序

• 過濾器調(diào)度過程
   

• 動(dòng)態(tài)加載過濾器
   

Zuul的作用

Zuul可以通過加載動(dòng)態(tài)過濾機(jī)制實(shí)現(xiàn)Zuul的功能:

• 驗(yàn)證與安全保障: 識(shí)別面向各類資源的驗(yàn)證要求并拒絕那些與要求不符的請求
• 審查與監(jiān)控: 在邊緣位置追蹤有意義數(shù)據(jù)及統(tǒng)計(jì)結(jié)果，得到準(zhǔn)確的生產(chǎn)狀態(tài)結(jié)論
• 動(dòng)態(tài)路由: 以動(dòng)態(tài)方式根據(jù)需要將請求路由至不同后端集群處
• 壓力測試: 逐漸增加指向集群的負(fù)載流量，從而計(jì)算性能水平
• 負(fù)載分配: 為每一種負(fù)載類型分配對應(yīng)容量，并棄用超出限定值的請求
• 靜態(tài)響應(yīng)處理: 在邊緣位置直接建立部分響應(yīng)，從而避免其流入內(nèi)部集群
• 多區(qū)域彈性: 跨越AWS區(qū)域進(jìn)行請求路由，旨在實(shí)現(xiàn)ELB使用多樣化并保證邊緣位置與使用者盡可能接近

Zuul與應(yīng)用的集成方式

• ZuulServlet - 處理請求(調(diào)度不同階段的filters，處理異常等)
  • 所有的Request都要經(jīng)過ZuulServlet的處理,
  • Zuul對request處理邏輯的三個(gè)核心的方法: preRoute(),route(), postRoute()
  • ZuulServletZuulServlet交給ZuulRunner去執(zhí)行。由于ZuulServlet是單例，因此ZuulRunner也僅有一個(gè)實(shí)例。ZuulRunner直接將執(zhí)行邏輯交由FilterProcessor處理，F(xiàn)ilterProcessor也是單例，其功能就是依據(jù)filterType執(zhí)行filter的處理邏輯
  • FilterProcessor對filter的處理邏輯:

    1.首先根據(jù)Type獲取所有輸入該Type的filter:List list
    2.遍歷該list，執(zhí)行每個(gè)filter的處理邏輯:processZuulFilter(ZuulFilter filter)
    3.RequestContext對每個(gè)filter的執(zhí)行狀況進(jìn)行記錄，應(yīng)該留意，此處的執(zhí)行狀態(tài)主要包括其執(zhí)行時(shí)間、以及執(zhí)行成功或者失敗，如果執(zhí)行失敗則對異常封裝后拋出
    4.到目前為止，Zuul框架對每個(gè)filter的執(zhí)行結(jié)果都沒有太多的處理，它沒有把上一filter的執(zhí)行結(jié)果交由下一個(gè)將要執(zhí)行的filter，僅僅是記錄執(zhí)行狀態(tài)，如果執(zhí)行失敗拋出異常并終止執(zhí)行

  • ContextLifeCycleFilter - RequestContext 的生命周期管理:
    • ContextLifecycleFilter的核心功能是為了清除RequestContext;請求上下文RequestContext通過ThreadLocal存儲(chǔ)，需要在請求完成后刪除該對象RequestContext提供了執(zhí)行filter Pipeline所需要的Context，因?yàn)镾ervlet是單例多線程，這就要求RequestContext即要線程安全又要Request安全。context使用ThreadLocal保存，這樣每個(gè)worker線程都有一個(gè)與其綁定的RequestContext，因?yàn)閣orker僅能同時(shí)處理一個(gè)Request，這就保證了Request Context 即是線程安全的由是Request安全的。
  • GuiceFilter - GOOLE-IOC(Guice是Google開發(fā)的一個(gè)輕量級(jí),基于Java5(主要運(yùn)用泛型與注釋特性)的依賴注入框架(IOC).Guice非常小而且快.)
  • StartServer - 初始化 zuul 各個(gè)組件(ioc,插件,filters,數(shù)據(jù)庫等)
  • FilterScriptManagerServlet - uploading/downloading/managing scripts， 實(shí)現(xiàn)熱部署
    Filter源碼文件放在zuul 服務(wù)特定的目錄， zuul server會(huì)定期掃描目錄下的文件的變化，動(dòng)態(tài)的讀取\編譯\運(yùn)行這些filter,如果有Filter文件更新，源文件會(huì)被動(dòng)態(tài)的讀取，編譯加載進(jìn)入服務(wù)，接下來的Request處理就由這些新加入的filter處理

React前端框架

React定義

• React前端框架是Facebook開源的一個(gè)js庫,用于動(dòng)態(tài)構(gòu)建用戶界面.
• React解決的問題:
  • 數(shù)據(jù)綁定的時(shí)候,大量操作真實(shí)dom,性能成本太高
  • 網(wǎng)站的數(shù)據(jù)流向太混亂,不好控制
• React 把用戶界面抽象成一個(gè)個(gè)組件.如按鈕組件 Button,對話框組件 Dialog,日期組件 Calendar.開發(fā)者通過組合這些組件,最終得到功能豐富,可交互的頁面.通過引入 JSX 語法,復(fù)用組件變得非常容易,同時(shí)也能保證組件結(jié)構(gòu)清晰.有了組件這層抽象,React 把代碼和真實(shí)渲染目標(biāo)隔離開來,除了可以在瀏覽器端渲染到 DOM 來開發(fā)網(wǎng)頁外,還能用于開發(fā)原生移動(dòng)應(yīng)用

React核心

虛擬DOM是React的基石,React的核心是 組件 ,React的精髓是 函數(shù)式編程 ,在React中是 單向響應(yīng)的數(shù)據(jù)流

組件的設(shè)計(jì)目的是提高代碼復(fù)用率,降低測試難度和代碼復(fù)雜度:

1. 提高代碼復(fù)用率：組件將數(shù)據(jù)和邏輯封裝，類似面向?qū)ο笾械念?/li>
2. 降低測試難度：組件高內(nèi)聚低耦合，很容易對單個(gè)組件進(jìn)行測試
3. 降低代碼復(fù)雜度：直觀的語法可以極大提高可讀性

React特點(diǎn)

• JSX: JSX 是 JavaScript 語法的擴(kuò)展
• 組件: 通過 React 構(gòu)建組件,使得代碼更加容易得到復(fù)用,能夠很好的應(yīng)用在大項(xiàng)目的開發(fā)中
• 單向響應(yīng)的數(shù)據(jù)流: React 實(shí)現(xiàn)了單向響應(yīng)的數(shù)據(jù)流,從而減少了重復(fù)代碼,這也是它為什么比傳統(tǒng)數(shù)據(jù)綁定更簡單
• Declarative(聲明式編碼): React采用聲明范式,可以輕松描述應(yīng)用(自動(dòng)dom操作)
• Component-Based(組件化編碼)
• Learn Once,Write Anywhere(支持客戶端與服務(wù)器渲染)
• 高效:React通過對DOM的模擬(虛擬dom),最大限度地減少與DOM的交互

1.虛擬(virtual)DOM, 不總是直接操作DOM，減少頁面更新次數(shù)；
2.高效的DOM Diff算法, 最小化頁面重繪；

• 靈活:React可以與已知的庫或框架很好地配合

React的虛擬DOM

• 傳統(tǒng)DOM更新
  真實(shí)頁面對應(yīng)一個(gè) DOM 樹.在傳統(tǒng)頁面的開發(fā)模式中,每次需要更新頁面時(shí),都要手動(dòng)操作 DOM 來進(jìn)行更新

虛擬DOM
DOM操作非常昂貴.我們都知道在前端開發(fā)中,性能消耗最大的就是DOM操作,而且這部分代碼會(huì)讓整體項(xiàng)目的代碼變得難以維護(hù).React把真實(shí)DOM樹轉(zhuǎn)換成JavaScript對象樹,也就是Virtual DOM

• 虛擬DOM定義:
  • 一個(gè)虛擬DOM(元素)是一個(gè)一般的js對象,準(zhǔn)確的說是一個(gè)對象樹(倒立的)
  • 虛擬DOM保存了真實(shí)DOM的層次關(guān)系和一些基本屬性,與真實(shí)DOM一一對應(yīng)
  • 如果只是更新虛擬DOM, 頁面是不會(huì)重繪的
• Virtual DOM算法步驟:
  • 用JS對象樹表示DOM樹的結(jié)構(gòu).然后用這個(gè)樹構(gòu)建一個(gè)真正的DOM樹插入到文檔中
  • 當(dāng)狀態(tài)變更的時(shí)候,重新構(gòu)造一棵新的對象樹.然后用新的樹和舊的樹進(jìn)行比較,記錄兩棵樹差異
  • 把差異應(yīng)用到真實(shí)DOM樹上,視圖就更新了
• 進(jìn)一步理解:
  • Virtual DOM 本質(zhì)上就是在 JS 和 DOM 之間做了一個(gè) 緩存

可以類比CPU和硬盤,既然硬盤這么慢,我們就在它們之間加個(gè)緩存:既然 DOM 這么慢,
我們就在它們JS和DOM之間加個(gè)緩存.CPU(JS)只操作內(nèi)存(Virtual DOM,最后的時(shí)候再
把變更寫入硬盤（DOM）

• React提供了一些API來創(chuàng)建一種特別的一般js對象

 
 
 
 
  
  
  
  
//創(chuàng)建的就是一個(gè)簡單的虛擬DOM對象 
  
  
  
  
var element = React.createElement('h1', {id:'myTitle'}, 'hello'); 
 
 
 

• 虛擬DOM對象最終都會(huì)被React轉(zhuǎn)換為真實(shí)的DOM
• 我們編碼時(shí)基本只需要操作react的虛擬DOM相關(guān)數(shù)據(jù),react會(huì)轉(zhuǎn)換為真實(shí)DOM變化而更新界面
• 創(chuàng)建虛擬DOM的2種方式
  • JSX方式

 
 
 
 
  
  
  
  
//  jsx方式創(chuàng)建虛擬dom元素對象 
  
  
  
  
const vDOM2 = {msg.toLowerCase()} 
 
 
 

還有一種是純JS,一般不使用:

 
 
 
 
  
  
  
  
//  純JS方式 
  
  
  
  
const msg = 'I like you'; 
  
  
  
  
const myId = 'atguigu'; 
  
  
  
  
const vDOM1 = React.createElement('h2',{id:myId},msg); 
 
 
 

• 渲染虛擬DOM(元素)
  • 語法: ReactDOM.render(virtualDOM,containerDOM)
  • 作用: 將虛擬DOM元素渲染到真實(shí)容器DOM中顯示
  • 參數(shù)說明:
    • 參數(shù)一: 純js或jsx創(chuàng)建的虛擬DOM對象
    • 參數(shù)二: 用來包含虛擬DOM元素的真實(shí)dom元素對象(一般是一個(gè)div)

 
 
 
 
  
  
  
  
//  渲染到真實(shí)的頁面中 
  
  
  
  
 ReactDOM.render(vDOM1,document.getElementById('example1')); 
  
  
  
  
 ReactDOM.render(vDOM2,document.getElementById('example2')); 
 
 
 

使用示例:

 
 
 
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
   
  
  
  
A
   
  
  
  
B
   
  
  
  
C