如果想學Java工程，高性能和分布式，容易理解。從事微服務、Spring、MyBatis和Netty源代碼分析的朋友可以添加我的高級Java交流:854630135。有阿裏大牛的直播講解技術和Java大規模互聯網技術的視頻免費分享給大家。
微服務的實現需要大量的技術工作來開發基礎設施，這對許多公司來說顯然是不現實的。別擔心，業界已經有壹個優秀的開源框架供我們參考。目前業內成熟的微服務框架有網飛、Spring Cloud和阿裏的Dubbo。Spring Cloud是壹套基於Spring Boot的微服務框架，提供了開發微服務所需的組件。如果配合Spring Boot使用，微服務架構開發雲服務將非常方便。Spring Cloud包含許多子框架，其中Spring Cloud網飛是壹組框架。在我們的微服務架構設計中，使用了Spring Cloud網飛框架的許多組件。春雲網飛項目時間不長，相關文檔也很少。當時博主研究這個框架，啃了壹大堆英文文檔，簡直痛苦。對於剛接觸這個框架的學生來說，他們可能不知道如何構建微服務應用程序架構。接下來，我們將介紹我們的微服務架構構建過程以及需要哪些框架或組件來支持微服務架構。
為了直觀清晰地展示微服務架構的組成和原理，繪制了系統架構圖，如下所示:
從上圖可以看出，微服務訪問的大致路徑為:外部請求→負載均衡→服務網關）→微服務→數據服務/消息服務。服務網關和微服務都使用服務註冊和發現來調用其他依賴服務，每個服務集群都可以通過配置中心服務獲取配置信息。
服務網關（網關）
網關是外部系統（如客戶端瀏覽器、移動設備等）之間的壹扇門。）和企業內部系統，所有客戶端都請求通過網關訪問後臺服務。為了應對高並發訪問，服務網關以集群的形式部署，這意味著需要負載均衡。我們使用Amazon EC2作為虛擬雲服務器，使用ELB（彈性負載平衡）進行負載平衡。EC2具有自動配置容量的功能。當用戶流量達到峰值時，EC2可以自動添加更多容量來保持虛擬主機的性能。ELB彈性負載平衡自動在多個實例之間分配應用程序的傳入流量。為了確保安全性，客戶端請求需要通過https加密來保護，這需要我們卸載SSL並使用Nginx來卸載加密的請求。外部請求在ELB負載平衡後被路由到網關集群中的網關服務，並由網關服務轉發到微服務。作為內部系統的邊界，服務網關具有以下基本功能:
1.動態路由:將請求動態路由到所需的後端服務集群。雖然內部是復雜的分布式微服務網狀結構，但外部系統從網關看起來像壹個整體服務，網關屏蔽了後端服務的復雜性。
2.限流和容錯:為每種類型的請求分配容量，當請求數量超過閾值時丟棄外部請求，限制流量，並保護後臺服務免受大流量的沖刷；當該方的內部服務失敗時，直接在邊界創建壹些響應以集中進行容錯處理，而不是將請求轉發到內部集群以確保良好的用戶體驗。
3.身份認證和安全控制:對每個外部請求進行用戶認證，拒絕認證失敗的請求，並通過訪問模式分析實現反爬蟲功能。
4.監控:網關可以收集有意義的數據和統計信息，為後臺服務優化提供數據支持。
5.訪問日誌:網關可以收集訪問日誌信息，例如訪問了哪個服務？處理過程（什麽是異常）和結果？需要多長時間？通過分析日誌內容，進壹步優化後臺系統。
我們使用Spring Cloud網飛框架的開源組件Zuul來實現網關服務。Zuul使用壹系列不同類型的過濾器。通過重寫過濾器，我們可以靈活地實現網關的各種功能。
如果想學Java工程，高性能和分布式，容易理解。從事微服務、Spring、MyBatis和Netty源代碼分析的朋友可以添加我的高級Java交流:854630135。有阿裏大牛的直播講解技術和Java大規模互聯網技術的視頻免費分享給大家。
服務註冊和發現
因為微服務架構是由壹系列具有單壹職責的細粒度服務組成的網狀結構，服務通過輕量級機制進行通信，這就引入了服務註冊和發現的問題。服務提供者應該註冊並報告服務地址，服務調用者應該能夠找到目標服務。在我們的微服務架構中使用了Eureka組件來實現服務註冊和發現。所有微服務（通過配置Eureka的服務信息）都在Eureka服務器中註冊，並定期發送心跳進行健康檢查。Eureka的默認配置是每30秒發送壹次心跳，這表明服務仍在運行。發送心跳的時間間隔可以通過Eureka的配置參數進行配置。在Eureka服務器收到服務實例的最後壹次心跳後，您需要等待90秒（默認配置為90秒，可以通過配置參數修改）才能確定該服務已經死亡（即您連續三次未收到心跳），當Eureka自我保護模式關閉時，該服務的註冊信息將被清除。所謂的自我保護模式是指當有網絡分區並且Eureka在短時間內丟失了太多服務時，它將進入自我保護模式，即某個服務很長時間沒有發送心跳，Eureka不會將其刪除。自我保護模式默認開啟，可通過配置參數設置為關閉。
Eureka服務部署在壹個集群中（該博主的另壹篇文章中詳細介紹了Eureka集群的部署模式），集群中的所有Eureka節點將定期自動同步微服務的註冊信息，從而確保所有Eureka服務的註冊信息壹致。那麽Eureka節點如何在Eureka集群中找到其他節點呢？我們使用DNS服務器來建立所有Eureka節點的關聯，除了部署Eureka集群之外，我們還需要構建DNS服務器。
當網關服務在後臺微服務之間轉發外部請求或調用時，它將前往Eureka服務器查找目標服務的註冊信息，找到目標服務並調用它，從而形成服務註冊和發現的整個過程。Eureka中有許多配置參數，多達數百個，博主將在另壹篇文章中詳細解釋它們。
微服務部署
微服務是壹系列具有單壹職責和精細粒度的服務，是將我們的業務拆分為獨立的服務單元，具有良好的可擴展性和低耦合性。不同的微服務可以用不同的語言開發，每個服務處理壹個業務。微服務可以分為前端服務（也稱為邊緣服務）和後端服務（也稱為中間服務）。前端服務向不同的外部設備（PC、電話等）公開。）在對後端服務進行必要的聚合和剪裁之後。所有服務在啟動時都會向Eureka服務器註冊，服務之間會有復雜的依賴關系。當網關服務轉發外部請求調用前端服務時，可以通過查詢服務註冊表找到要調用的目標服務。前端服務調用後端服務時也是如此。壹個請求可能涉及多個服務之間的相互調用。由於每個微服務都是以集群的形式部署的，因此在服務相互調用時需要進行負載平衡，因此每個服務都有壹個LB組件來實現負載平衡。
微服務以鏡像的形式在Docker容器中運行。Docker容器技術使我們的服務部署變得簡單高效。傳統的部署方法需要在每臺服務器上安裝運行環境。如果我們的服務器數量龐大，在每臺服務器上安裝運行環境將是壹項極其繁重的任務。壹旦運行環境發生變化，就必須重新安裝，這簡直是災難性的。使用Docker容器技術，我們只需要生成所需基本映像的新映像（jdk等。）和微服務，並將此最終映像部署在Docker容器中運行。這種方式簡單高效，可以快速部署服務。每個Docker容器中可以運行多個微服務。Docker容器部署在集群中，由Docker Swarm管理。我們創建壹個圖像倉庫來存儲所有基本圖像和生成的最終交付圖像，並管理圖像倉庫中的所有圖像。
服務容錯
微服務之間存在復雜的依賴關系。壹個請求可能依賴於多個後端服務，這可能會導致實際生產中的故障或延遲。在高流量系統中，壹旦服務被延遲，它可能會在短時間內耗盡系統資源並使整個系統停機。因此，如果服務不能隔離和容忍其故障，其本身就是災難性的。Hystrix組件用於我們的微服務架構以實現容錯。Hystrix是網飛的開源組件，通過熔絲模式、隔離模式、回退和限流機制為服務提供靈活的容錯保護，確保系統的穩定性。
1.保險絲模式:保險絲模式的原理與電路保險絲的原理相似。當電路短路時，保險絲會熔斷以保護電路免受災難性損失。當服務異常或延遲較大時，服務調用者會在滿足fuse條件時主動啟動fuse，執行fallback邏輯並直接返回，不會繼續調用服務進壹步拖累系統。fuse的默認配置服務調用錯誤率閾值為50%。如果超過閾值，保險絲模式將自動啟動。服務被隔離壹段時間後，fuse將進入半熔斷狀態，即允許少量請求嘗試，如果調用仍然失敗，將返回熔斷狀態，如果調用成功，將關閉熔斷模式。
2.隔離方式:Hystrix默認采用線程隔離，不同的服務使用不同的線程池，互不影響。當壹個服務出現故障並耗盡其線程池資源時，其他服務的正常運行不受影響，達到隔離的效果。例如，我們通過和ThreadPoolKey配置壹個服務來使用壹個名為TestThreadPool的線程池，以實現與其他命名線程池的隔離。
3.fallback）:fallback機制實際上是服務失敗時的壹種容錯方式，其原理類似於Java中的異常處理。您只需要繼承HystixCommand並重寫getFallBack（）方法，並在該方法中編寫處理邏輯，例如，您可以直接拋出異常（快速失敗）、返回null或默認值或返回備份數據。當服務調用異常時，會轉而執行getFallBack（）。在以下情況下可以觸發回退:
1）程序拋出非Hystrixbadrequestxception異常。當拋出Hystrixbadrequestxception異常時，調用程序可以在不觸發回退的情況下捕獲該異常，當拋出其他異常時，將觸發回退；
2）程序超時運行；
3）熔斷器啟動；
4）線程池已滿。
4.限流:限流是指限制服務的並發訪問，設置單位時間內的並發訪問次數，並拒絕和回退超過限制的請求，以防止後臺服務被沖走。
Hystix使用命令模式HystrixCommand包裝依賴調用邏輯，使相關調用自動處於Hystrix的彈性容錯保護之下。調用者需要繼承HystrixCommand並在run（）中編寫調用邏輯，並使用execute（）（同步阻塞）或queue（）（異步非阻塞）來觸發run（）的執行。
動態配置中心
微服務有許多依賴配置，在服務運行過程中可能會動態修改壹些配置參數，例如根據訪問流量動態調整fuse閾值。傳統的實現信息配置的方法，如將其放入xml、yml等配置文件中並與應用程序打包，每次修改都要重新提交代碼、打包構建、生成新的映像並重新啟動服務，這顯然是不合理的。因此，我們需要構建壹個動態配置中心服務來支持微服務的動態配置。我們使用Spring Cloud的configserver服務來幫助我們構建動態配置中心。我們開發的微服務代碼存儲在git服務器的私有倉庫中，所有需要動態配置的配置文件都存儲在git服務器下的configserver（配置中心，也是壹種微服務）服務中。Docker容器中部署的微服務從git服務器動態讀取配置文件的信息。當本地git倉庫修改代碼並將其推送到git服務器倉庫時，git服務器鉤子（post-receive，將在服務器完成代碼更新後自動調用）會自動檢測是否有任何配置文件更新。如果有，git服務器通過消息隊列向配置中心（配置服務器，部署在容器中的微服務）發送消息，通知配置中心刷新相應的配置文件。通過這種方式，微服務可以獲取最新的配置文件信息並實現動態配置。
這些框架或組件是支持微服務架構實現的核心。在實際生產中，我們還會用到許多其他組件，如日誌服務組件和消息服務組件等。，並根據業務需求選擇使用它們。在我們的微服務架構實現案例中，引用了Spring Cloud網飛框架的許多開源組件，包括Zuul（服務網關）、Eureka（服務註冊和發現）、Hystrix（服務容錯）、Ribbon（客戶端負載平衡）等。這些優秀的開源組件為我們實現微服務架構提供了捷徑。
如果想學Java工程，高性能和分布式，容易理解。從事微服務、Spring、MyBatis和Netty源代碼分析的朋友可以添加我的高級Java交流:854630135。有阿裏大牛的直播講解技術和Java大規模互聯網技術的視頻免費分享給大家。