微服務依賴的網路原理是什麼

1. 什麼是微服務架構主流的微服務如何實現

簡單地說，微服務架構就是以業務域或業務功能為邊界，將一個大而全的應用拆分為可以獨立開發，獨立部署，獨立測試，獨立運行的一組小的應用，並且使用輕量級，通用的機制在這組應用間進行通信。
主流的微服務包括：
1、SpringCloud

Spring Cloud , 來自Spring，具有Spring 社區的強大支撐，還有Netflix強大的後盾與技術輸出。Netflix作為一家成功實踐微服務架構的互聯網公司在幾年前就把幾乎整個微服務框架棧開源貢獻給了社區，這些框架開源的整套服務架構套件是Spring Cloud的核心。

- Eureka:服務注冊發現框架；

- Zuul:服務網關；

- Karyon：服務端框架；

- Ribbon：客戶端框架；

- Hystrix：服務容錯組件；

- Archaius：服務配置組件；

- Servo：Metrics組件；

- Blitz4j：日誌組件；

2、Dubbo

Dobbo是一個分布式服務框架，是阿里開放的微服務化治理框架，致力於提高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其核心部分(官網)

- 遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式；

- 集群容錯: 提供基於介面方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持；

- 自動發現: 基於注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo 也是採用全 Spring 配置方式，透明化接入應用，對應用沒有任何 API 侵入，只需用 Spring 載入 Dubbo的配置即可，Dubbo 基於 Spring 的 Schema 擴展進行載入。當然也支持官方不推薦的 API 調用方式。

3、lstio

lstio 作為用於微服務聚合層管理的新銳項目，是Google、IBM、Lyft（海外共享出行公司、Uber勁敵），首個共同聯合開源的項目，提供了統一的連接，安全，管理和監控微服務的方案。

目前首個測試版是針對Kubernetes環境的，社區宣稱在未來幾個月內會為虛擬機和Cloud Foundry 等其他環境增加支持。lstio將 流量管理添加到微服務中，並為增值功能（如安全性、監控、路由、連接管理和策略）創造了基礎。

- HTTP、gRPC 和 TCP 網路流量自動負載均衡；

- 提供了豐富的路由規則，實現細顆粒度的網路流量行為控制；

- 流量加密、服務件認證，以及強身份聲明；

- 全范圍（Fleet-wide）的策略執行；

- 深度遙測和報告。

2. 什麼是微服務

即軟體架構，使用微服務架構可以將一個大型的應用程序按照功能模塊拆分成多個獨立自治的微服務，每個微服務僅僅實現一種功能，具有很明確的邊界。想要了解更多，我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。
希望能給您提供幫助，可以給個大大的贊不。

3. 什麼是微服務

「Mesh App and Service Architecture」作為Gartner2016 十大戰略技術趨勢中之一，裡面大量提到微服務的概念。微服務（Microservices）這個概念不是新概念，很多公司已經在實踐了，例如Google、Netflix、Facebook、Twiter、Alibaba。微服務架構模式（Microservices Architecture Pattern）的目的是將大型的、復雜的、長期運行的應用程序構建為一組相互配合的服務，每個服務都可以很容易得局部改良。

微服務從去年以來一直受到眾多開發者的熱捧，已經看到有許多項目嘗試使用微服務架構，結果很鼓舞人心。然而，在微服務架構帶來可獨立部署、高擴展與伸縮、自由選擇開發語言、高效利用資源、故障隔離等優點，同時也因為服務多帶來分布式事務、服務之間通信、監控、部署等新的問題。

提到微服務架構時，我們常常會做的一件事情，就是會拿來與單體架構進行比較，單體架構存在如下缺點：代碼維護難度大，臃腫的部署，局限的彈性與擴展能力，阻礙團隊與技術革新等等；微服務架構存在如下優點：代碼維護簡化，可獨立部署，高擴展與伸縮，自由選擇開發語言等優點。那麼單體架構真的如此不堪一擊嗎？答案顯然不是這樣，下面我們來看Martin Fowler在其一篇文章裡面給出關系圖：

上面的圖來自 Martin Fowler 的文章，揭示了生產率和復雜度的一個關系。在復雜度較小時採用單體應用（Monolith）的生產率更高，復雜度到了一定規模時，單體應用的生產率開始急劇下降，這時對其進行微服務化的拆分才是合算的。所以說脫離業務場景，空談架構絕對是耍流氓。異常牛逼的架構設計，如果無法在業務場景中落地實施，也只是空談。因此架構需要服務於業務，針對不同的業務場景架構設計也會不同，架構設計不必追求高大上，簡而美的架構，若能滿足業務發展需求，便是好架構。此外，好的架構不完全是設計出來的，隨著業務量、請求量的增長，好的架構是演化而來的。微服務架構之所以得到廣泛認可，源於對於業務多變性的不可預測，微服務架構能夠不斷的自演化，進而快速適應業務變化。但相對於單體架構且經過嚴格定義的大規模開發項目，微服務架構要求大家面對由眾多小型服務所構成的復雜生態系統。

鑒於此，如果長期業務規劃不需要微服務架構或者團隊不具備實施微服務一些基本的條件，不建議各位盲目邁向微服務這一新興架構領域，或者從試點入手，逐步在團隊中推行微服務架構。

4. 簡述Kubernetes網路策略原理

Network Policy的工作原理主要為：policy controller需要實現一個API Listener，監聽用戶設置的Network Policy定義，並將網路訪問規則通過各Node的Agent進行實際設置（Agent則需要通過CNI網路插件實現）。我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。 如果我的回答能夠對您有幫助的話，求給大大的贊。

5. 什麼是微服務架構

微服務是指開發一個單個 小型的但有業務功能的服務,每個服務都有自己的處理和輕量通訊機制,可以部署在單個或多個伺服器上.
微服務也指一種種松耦合的、有一定的有界上下文的面向服務架構.也就是說,如果每個服務都要同時修改,那麼它們就不是微服務,因為它們緊耦合在一起;如果你需要掌握一個服務太多的上下文場景使用條件,那麼它就是一個有上下文邊界的服務,這個定義來自DDD領域驅動設計.

6. 微服務核心組件 Zuul 網關原理剖析

Zuul 網關是具體核心業務服務的看門神，相比具體實現業務的系統服務來說它是一個邊緣服務，主要提供動態路由，監控，彈性，安全性等功能。在分布式的微服務系統中，系統被拆為了多套系統，通過zuul網關來對用戶的請求進行路由，轉發到具體的後台服務系統中。

本 Chat 主要內容如下：

網關是具體核心業務服務的看門神，相比具體實現業務的系統服務來說它是一個邊緣服務，主要提供動態路由，監控，彈性，安全性等功能，下面我們從單體應用到多體應用的演化過程來講解網關的演化歷程。

一般業務系統發展歷程都是基本相似的，從單體應用到多應用，從本地調用到遠程調用。對應單體應用架構模式（如下圖1），由於只需一個應用，所有業務模塊的功能都打包為了一個 War 包進行部署，這樣可以減少機器資源和部署的繁瑣。

圖1 單體應用

在單體應用中，網關模塊是和應用部署到同一個jvm進程裡面的，當外部移動設備或者web站點訪問單體應用的功能時候，請求是先被應用的網關模塊攔截的，網關模塊對請求進行鑒權、限流等動作後在把具體的請求轉發到當前應用對應的模塊進行處理。

隨著業務的發展，網站的流量會越來越大，在單體應用中簡單的通過加機器的方式可以帶來的承受流量沖擊的能力也越來越低，這時候就會考慮根據業務將單體應用拆成若干個功能獨立的應用，單體應用拆為多個應用後，由於不同的應用開發對應的功能，所以多應用開發之間可以獨立開發而不用去理解對方的業務，另外不同的應用模塊只承受對應業務流量的壓力，不會對其他應用模塊造成影響，這時候多體的分布式系統就出現了，如下圖2。

圖2 多體應用

如上圖在多體應用中業務模塊A和B單獨起了個應用，每個應用裡面有自己的網關模塊，如果業務模塊多了，那麼每個應用都有自己的網關模塊，這樣復用性不好，所以可以考慮把網關模塊提起出來，單獨作為一個應用來做服務路由，如下圖3：

如上圖當移動設備發起請求時候是具體發送到網關應用的，經過鑒權後請求會被轉發到具體的後端服務應用上，對應前端移動設備來說他們不在乎也不知道後端伺服器應用是一個還是多個，他們只能感知到網關應用的存在。

Zuul是Netflix開源的一個網關組件，在Netflix內部系統中Zuul被用來作為內部系統的門面，如下圖是Zuul在Netflix內部使用的一個架構圖：

如上圖最上層的移動設備或者網站首先通過aws負載均衡器把請求路由到zuul網關上，zuul網關則負責把請求路由到具體的後端service上。

Zuul開源地址 https://github.com/Netflix/zuul

Zuul網關的核心是一系列的過濾器，這些過濾器可以對請求或者響應結果做一系列過濾，Zuul 提供了一個框架可以支持動態載入，編譯，運行這些過濾器，這些過濾器是使用責任鏈方式順序對請求或者響應結果進行處理的，這些過濾器直接不會直接進行通信，但是通過責任鏈傳遞的RequestContext參數可以共享一些東西。

雖然Zuul 支持任何可以在jvm上跑的語言，但是目前zuul的過濾器只能使用Groovy腳本來編寫。編寫好的過濾器腳本一般放在zuul伺服器的固定目錄，zuul伺服器會開啟一個線程定時去輪詢被修改或者新增的過濾器，然後動態進行編譯，載入到內存，然後等後續有請求進來，新增或者修改後的過濾器就會生效了。

在zuul中過濾器分為四種：

如下圖為zuul1.0的工作原理：

如上圖，當zuul接受到請求後，首先會由前置過濾器進行處理，然後在由路由過濾器具體把請求轉發到後端應用，然後在執行後置過濾器把執行結果寫會到請求方，當上面任何一個類型過濾器執行出錯時候執行該過濾器。

本節作者使用zuul的版本：

...

....

總結：zuul1.0時候當zuul接受到一個請求後會同步執行前置過濾器、路由過濾器、後置過濾器，等執行完畢後在同步把結果返回為調用方，調用方在整個過程中是阻塞的。其實SpringBoot集成的zuul就是自己實現了個前置過濾器做選擇路由，然後自己實現了個路由過濾器根據前置過濾器選擇的路由具體做路由轉發。

Netty作為高性能非同步網路通訊框架，在bbo，rocketmq,sofa等知名開源框架中都有使用，如下圖zuul2.0使用netty server作為網關監聽伺服器監聽客戶端發來的請求，然後把請求轉發到前置過濾器（inbound filters）進行處理，處理完畢後在把請求使用netty client代理到具體的後端伺服器進行處理，處理完畢後在把結果交給後者過濾器（outbound filters）進行處理，然後把處理結果通過nettyServer寫回客戶端。

...
總: 在zuul1.0時候客戶端發起的請求後需要同步等待zuul網關返回，zuul網關這邊對每個請求會分派一個線程來進行處理，這會導致並發請求數量有限。而zuul2.0使用netty作為非同步通訊，可以大大加大並發請求量。

7. Spring Cloud微服務體系的組成

Netflix Eureka是Spring Cloud服務注冊發現的基礎組件
Eureka提供RESTful風格(HTTP協議)的服務注冊與發現
Eureka採用C/S架構,Spring Cloud內置客戶端

啟用應用,訪問 http://localhost:8761

Eureka客戶端開發要點
maven依賴spring-cloud-starter-netflix-eureka-client application.yml
配置eureka.client.service-url.defaultZone
入口類增加@EnableEurekaClient

先啟動注冊中心,在啟動客戶端,訪問 localhost:8761查看eureka注冊中心,看到客戶端注冊

Eureka名詞概念
Register - 服務注冊, 向Eureka進行注冊登記
Renew - 服務續約,30秒/次心跳包健康檢查.90秒未收到剔除服務
Fetch Registries - 獲取服務注冊列表,獲取其他微服務地址
Cancel - 服務下線, 某個微服務通知注冊中心暫停服務
Eviction - 服務剔除,90秒未續約,從服務注冊表進行剔除
Eureka自我保護機制
Eureka在運行期去統計心跳失敗率在15分鍾之內是否低於 85%
如果低於 85%，會將這些實例保護起來，讓這些實例不會被剔除
關閉自我保護:eureka.服務實例.
enable-self-preservation: false
PS: 如非網路特別不穩定,建議關閉

Eureka高可用配置步驟
服務提供者defaultZone指向其他的Eureka
客戶端添加所有Eureka 服務實例 URL

Actuator自動為微服務創建一系列的用於監控的端點
Actuator在SpringBoot自帶，SpringCloud進行擴展
pom.xml依賴spring-boot-starter-actuator

RestTemplate + @LoadBalanced 顯式調用
OpenFeign 隱藏微服務間通信細節

Ribbon是RestTemplate與OpenFeign的通信基礎

Feign是一個開源聲明式WebService客戶端，用於簡化服務通信
Feign採用「介面+註解」方式開發，屏蔽了網路通信的細節
OpenFeign是SpringCloud對Feign的增強，支持Spring MVC註解

1.新建Spring boot Web項目，application name 為 proct-service
在pom.xml中引入依賴

spring-cloud-starter-alibaba-nacos-discovery作用為向Nacos server注冊服務。
spring-cloud-starter-openfeign作用為實現服務調用。
2.修改application.yml配置文件

3.在啟動類上添加@EnableDiscoveryClient、@EnableFeignClients註解

4.編寫OrderClient Interface
註：/api/v1/order/test 會在下面order-service聲明。
OrderClient.java

5.編寫Controller和service
ProctController.java

ProctService.java

1.OpenFeign開啟通信日誌
基於SpringBoot的logback輸出,默認debug級別
設置項：feign.client.config.微服務id.loggerLevel
微服務id：default代表全局默認配置
2.通信日誌輸出格式
NONE: 不輸出任何通信日誌
BASIC: 只包含URL、請求方法、狀態碼、執行時間
HEADERS：在BASIC基礎上，額外包含請求與響應頭
FULL：包含請求與響應內容最完整的信息
3.OpenFeign日誌配置項
LoggerLevel開啟通信日誌
ConnectionTimeout與ReadTimeout
利用httpclient或okhttp發送請求

1.OpenFeign通信組件
OpenFeign基於JDK原生URLConnection提供Http通信
OpenFeign支持Apache HttpClient與Square OkHttp
SpringCloud按條件自動載入應用通信組件
2.應用條件
Maven引入feign-okhttp或者feign-httpclient依賴
設置feign.[httpclient|okhttp].enabled=true

POST方式傳遞對象使用@RequestBody註解描述參數
GET方式將對象轉換為Map後利用@RequestParam註解描述

雪崩效應:服務雪崩效應產生與服務堆積在同一個線程池中，因為所有的請求都是同一個線程池進行處理，這時候如果在高並發情況下，所有的請求全部訪問同一個介面,這時候可能會導致其他服務沒有線程進行接受請求，這就是服務雪崩效應效應。
服務熔斷:熔斷機制目的為了保護服務，在高並發的情況下，如果請求達到一定極限(可以自己設置闊值)如果流量超出了設置閾值，讓後直接拒絕訪問，保護當前服務。使用服務降級方式返回一個友好提示，服務熔斷和服務降級一起使用。

1.Hystrix熔斷器
Hystrix（豪豬）是Netflix開源的熔斷器組件，用於為微服務提供熔斷機制預防雪崩，保護整體微服務架構的健康
2.Hystrix功能
預防微服務由於故障，請求長時間等待導致Web容器線程崩潰
提供故障備選方案，通過回退（fallback)機制提供」服務降級」
提供監控儀表盤,實時監控運行狀態
3.Hystrix 熔斷器工作原理

服務的健康狀況 = 請求失敗數 / 請求總數.
熔斷器開關由關閉到打開的狀態轉換是通過當前服務健康狀況和設定閾值比較決定的.
當熔斷器開關關閉時, 請求被允許通過熔斷器. 如果當前健康狀況高於設定閾值, 開關繼續保持關閉. 如果當前健康狀況低於
設定閾值, 開關則切換為打開狀態.
當熔斷器開關打開時, 請求被禁止通過.
當熔斷器開關處於打開狀態, 經過一段時間後, 熔斷器會自動進入半開狀態, 這時熔斷器只允許一個請求通過. 當該請求調用
成功時, 熔斷器恢復到關閉狀態. 若該請求失敗, 熔斷器繼續保持打開狀態, 接下來的請求被禁止通過.
熔斷器的開關能保證服務調用者在調用異常服務時, 快速返回結果, 避免大量的同步等待. 並且熔斷器能在一段時間後繼續偵測請求執行結果, 提供恢復服務調用的可能.
4.什麼情況下會觸發服務降級
FAILURE: 執行失敗，拋出異常
TIMEOUT:執行超時（默認1秒）
SHORT_CIRCUITED:熔斷器狀態為Open
THREAD_POOL_REJECTED:線程池拒絕
SEMAPHORE_REJECTED:信號量拒絕
5.使用Hystrix步驟
1.引入pom文件依賴

6.OpenFeign與Hystrix整合
OpenFeign中使用Hystrix
OpenFeign內置Hystrix，feign.hystrix.enable開啟即可
feign: hystrix: enabled: true
在@FeignClient增加fallback屬性說明Fallback類
@FeignClient(name="message-service",fallback = MessageServiceFallback.class) public interface MessageService { @GetMapping("/sendsms") public CallbackResult sendSMS(@RequestParam("mobile") String mobile , @RequestParam("message") String message); }
Fallback類要實現相同介面，重寫服務降級業務邏輯
@Component public class MessageServiceFallback implements MessageService { @Override public CallbackResult sendSMS(String mobile, String message) { return new CallbackResult("INVALID_SERVICE","消息服務暫時無法使用，簡訊發送失敗"); } }
7.Hystrix超時設置

8.部署Hystrix Dashboard監控
Hystrix Client依賴hystrix-metrics-event-stream
Hystrix Client注冊HystrixMetricsStreamServlet
監控微服務依賴spring-cloud-starter-netflix-hystrix-dashboard
監控微服務利用@EnableHystrixDashboard開啟儀表盤
9.Hystrix熔斷設置
產生熔斷的條件:
當一個Rolling Window(滑動窗口）的時間內（默認：10秒），最近20次調用請求，請求錯誤率超過50%，則觸發熔斷5秒，期間快速失敗。
TIPS: 如10秒內未累計到20次，則不會觸發熔斷
Hystrix熔斷設置項:

統一訪問出入口,微服務對前台透明
安全、過濾、流控等API管理功能
易於監控、方便管理

Netflix Zuul
Spring Cloud Gateway

Zuul 是Netflix開源的一個API網關, 核心實現是Servlet
Spring Cloud內置Zuul 1.x
Zuul 1.x 核心實現是Servlet，採用同步方式通信
Zuul 2.x 基於Netty Server，提供非同步通信

認證和安全
性能監測
動態路由
負載卸載
靜態資源處理
壓力測試

Spring Cloud Gateway，是Spring「親兒子」
Spring Cloud Gateway旨在為微服務架構提供一種簡單而有效的統一的API路由管理方式
Gateway基於Spring 5.0與Spring WebFlux開發，採用Reactor響應式設計

1.使用三部曲
依賴spring-cloud-starter-netflix-zuul
入口增加 @EnableZuulProxy
application.yml 增加微服務映射
2.微服務映射

Spring Cloud Zuul內置Hystrix
服務降級實現介面：FallbackProvider

1.微服務網關流量控制
微服務網關是應用入口，必須對入口流量進行控制
RateLimit是Spring Cloud Zuul的限流組件
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit
RateLimit採用「令牌桶」演算法實現限流
2.什麼是令牌桶

1.Zuul的執行過程

2.Http請求生命周期

1.需要實現ZuulFilter介面
shouldFilter() - 是否啟用該過濾器
filterOrder() - 設置過濾器執行次序
filterType() - 過濾器類型:pre|routing|post
run() - 過濾邏輯
2.Zuul內置過濾器

3.Zuul+JWT跨域身份驗證

1.Spring Cloud Config
2.攜程 Apollo
3.阿里巴巴Nacos

1.依賴"spring-cloud-starter-config"
2.刪除application.yml,新建bootstrap.yml
3.配置"配置中心"服務地址與環境信息

1、微服務依賴"spring-boot-starter-actuator";
2、動態刷新類上增加@RefreshScope註解
3、通過/actuator/refresh刷新配置

1、通過加入重試機制、提高應用啟動的可靠性;
2、重試觸發條件1:配置中心無法與倉庫正常通信
3、重試觸發條件2:微服務無法配置中心正常通信

8. 微服務架構是什麼

微服務架構是一項在雲中部署應用和服務的新技術。

大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。

微服務架構相關介紹：

微服務可以在「自己的程序」中運行，並通過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。

在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。

如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。

服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。