人人爱天天做,91美女精品,热久久国产精品视频,中文板真人性操逼,韩国一道本在线,一级片一级片黄色,日本高清色情,亚洲综合777777

作者：風中程序猿

來源：cnblogs.com/fangfuhai/p/7065847.html

基于微服務(wù)架構(gòu)和Docker容器技術(shù)的PaaS云平臺建設(shè)目標是給我們的開發(fā)人員提供一套服務(wù)快速開發(fā)、部署、運維管理、持續(xù)開發(fā)持續(xù)集成的流程。平臺提供基礎(chǔ)設(shè)施、中間件、數(shù)據(jù)服務(wù)、云服務(wù)器等資源，開發(fā)人員只需要開發(fā)業(yè)務(wù)代碼并提交到平臺代碼庫，做一些必要的配置，系統(tǒng)會自動構(gòu)建、部署，實現(xiàn)應(yīng)用的敏捷開發(fā)、快速迭代。在系統(tǒng)架構(gòu)上，PaaS云平臺主要分為微服務(wù)架構(gòu)、Docker容器技術(shù)、DevOps三部分，這篇文章重點介紹微服務(wù)架構(gòu)的實施。

微服務(wù)訪問路徑

實施微服務(wù)需要投入大量的技術(shù)力量來開發(fā)基礎(chǔ)設(shè)施，這對很多公司來說顯然是不現(xiàn)實的，別擔心，業(yè)界已經(jīng)有非常優(yōu)秀的開源框架供我們參考使用。目前業(yè)界比較成熟的微服務(wù)框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套實現(xiàn)微服務(wù)的框架，它提供了開發(fā)微服務(wù)所需的組件，跟Spring Boot一起使用的話開發(fā)微服務(wù)架構(gòu)的云服務(wù)會變的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我們的微服務(wù)架構(gòu)設(shè)計中，就使用了很多Spring Cloud Netflix框架的組件。Spring Cloud Netflix項目的時間還不長，相關(guān)的文檔資料很少，博主當時研究這套框架啃了很多英文文檔，簡直痛苦不堪。對于剛開始接觸這套框架的同學(xué)，要搭建一套微服務(wù)應(yīng)用架構(gòu)，可能會不知道如何下手，接下來介紹我們的微服務(wù)架構(gòu)搭建過程以及需要那些框架或組件來支持微服務(wù)架構(gòu)。

為了直接明了的展示微服務(wù)架構(gòu)的組成及原理，博主畫了一張系統(tǒng)架構(gòu)圖，如下：

從上圖可以看出，微服務(wù)訪問大致路徑為：外部請求 → 負載均衡 → 服務(wù)網(wǎng)關(guān)（GateWay）→ 微服務(wù) → 數(shù)據(jù)服務(wù)/消息服務(wù)。服務(wù)網(wǎng)關(guān)和微服務(wù)都會用到服務(wù)注冊和發(fā)現(xiàn)來調(diào)用依賴的其他服務(wù)，各服務(wù)集群都能通過配置中心服務(wù)來獲得配置信息。

服務(wù)網(wǎng)關(guān)（GateWay）

網(wǎng)關(guān)是外界系統(tǒng)（如：客戶端瀏覽器、移動設(shè)備等）和企業(yè)內(nèi)部系統(tǒng)之間的一道門，所有的客戶端請求通過網(wǎng)關(guān)訪問后臺服務(wù)。為了應(yīng)對高并發(fā)訪問，服務(wù)網(wǎng)關(guān)以集群形式部署，這就意味著需要做負載均衡，我們采用了亞馬遜EC2作為虛擬云服務(wù)器，采用ELB（Elastic Load Balancing）做負載均衡。EC2具有自動配置容量功能，當用戶流量達到尖峰，EC2可以自動增加更多的容量以維持虛擬主機的性能。ELB彈性負載均衡，在多個實例間自動分配應(yīng)用的傳入流量。為了保證安全性，客戶端請求需要使用https加密保護，這就需要我們進行SSL卸載,使用Nginx對加密請求進行卸載處理。外部請求經(jīng)過ELB負載均衡后路由到GateWay集群中的某個GateWay服務(wù)，由GateWay服務(wù)轉(zhuǎn)發(fā)到微服務(wù)。服務(wù)網(wǎng)關(guān)作為內(nèi)部系統(tǒng)的邊界，它有以下基本能力：

在公眾號互聯(lián)網(wǎng)架構(gòu)師回復(fù)“2T”，獲取Java面試題和答案驚喜禮包。

動態(tài)路由：動態(tài)的將請求路由到所需要的后端服務(wù)集群。雖然內(nèi)部是復(fù)雜的分布式微服務(wù)網(wǎng)狀結(jié)構(gòu)，但是外部系統(tǒng)從網(wǎng)關(guān)看就像是一個整體服務(wù)，網(wǎng)關(guān)屏蔽了后端服務(wù)的復(fù)雜性。
限流和容錯：為每種類型的請求分配容量，當請求數(shù)量超過閥值時拋掉外部請求，限制流量，保護后臺服務(wù)不被大流量沖垮；黨內(nèi)部服務(wù)出現(xiàn)故障時直接在邊界創(chuàng)建一些響應(yīng)，集中做容錯處理，而不是將請求轉(zhuǎn)發(fā)到內(nèi)部集群，保證用戶良好的體驗。
身份認證和安全性控制：對每個外部請求進行用戶認證，拒絕沒有通過認證的請求，還能通過訪問模式分析，實現(xiàn)反爬蟲功能。
監(jiān)控：網(wǎng)關(guān)可以收集有意義的數(shù)據(jù)和統(tǒng)計，為后臺服務(wù)優(yōu)化提供數(shù)據(jù)支持。
訪問日志：網(wǎng)關(guān)可以收集訪問日志信息，比如訪問的是哪個服務(wù)？處理過程（出現(xiàn)什么異常）和結(jié)果？花費多少時間？通過分析日志內(nèi)容，對后臺系統(tǒng)做進一步優(yōu)化。

我們采用Spring Cloud Netflix框架的開源組件Zuul來實現(xiàn)網(wǎng)關(guān)服務(wù)。Zuul使用一系列不同類型的過濾器（Filter），通過重寫過濾器，使我們能夠靈活的實現(xiàn)網(wǎng)關(guān)（GateWay）的各種功能。

服務(wù)注冊與發(fā)現(xiàn)

由于微服務(wù)架構(gòu)是由一系列職責單一的細粒度服務(wù)構(gòu)成的網(wǎng)狀結(jié)構(gòu)，服務(wù)之間通過輕量機制進行通信，這就引入了服務(wù)注冊與發(fā)現(xiàn)的問題，服務(wù)的提供方要注冊報告服務(wù)地址，服務(wù)調(diào)用放要能發(fā)現(xiàn)目標服務(wù)。我們的微服務(wù)架構(gòu)中使用了Eureka組件來實現(xiàn)服務(wù)的注冊與發(fā)現(xiàn)。所有的微服務(wù)（通過配置Eureka服務(wù)信息）到Eureka服務(wù)器中進行注冊，并定時發(fā)送心跳進行健康檢查，Eureka默認配置是30秒發(fā)送一次心跳，表明服務(wù)仍然處于存活狀態(tài)，發(fā)送心跳的時間間隔可以通過Eureka的配置參數(shù)自行配置，Eureka服務(wù)器在接收到服務(wù)實例的最后一次心跳后，需要等待90秒（默認配置90秒，可以通過配置參數(shù)進行修改）后，才認定服務(wù)已經(jīng)死亡（即連續(xù)3次沒有接收到心跳），在Eureka自我保護模式關(guān)閉的情況下會清除該服務(wù)的注冊信息。所謂的自我保護模式是指，出現(xiàn)網(wǎng)絡(luò)分區(qū)、Eureka在短時間內(nèi)丟失過多的服務(wù)時，會進入自我保護模式，即一個服務(wù)長時間沒有發(fā)送心跳，Eureka也不會將其刪除。自我保護模式默認為開啟，可以通過配置參數(shù)將其設(shè)置為關(guān)閉狀態(tài)。

Eureka服務(wù)以集群的方式部署，集群內(nèi)的所有Eureka節(jié)點會定時自動同步微服務(wù)的注冊信息，這樣就能保證所有的Eureka服務(wù)注冊信息保持一致。那么在Eureka集群里，Eureka節(jié)點是如何發(fā)現(xiàn)其他節(jié)點的呢？我們通過DNS服務(wù)器來建立所有Eureka節(jié)點的關(guān)聯(lián)，在部署Eureka集群之外還需要搭建DNS服務(wù)器。

當網(wǎng)關(guān)服務(wù)轉(zhuǎn)發(fā)外部請求或者是后臺微服務(wù)之間相互調(diào)用時，會去Eureka服務(wù)器上查找目標服務(wù)的注冊信息，發(fā)現(xiàn)目標服務(wù)并進行調(diào)用，這樣就形成了服務(wù)注冊與發(fā)現(xiàn)的整個流程。Eureka的配置參數(shù)數(shù)量很多，多達上百個，博主會在另外的文章里詳細說明。

微服務(wù)部署

微服務(wù)是一系列職責單一、細粒度的服務(wù)，是將我們的業(yè)務(wù)進行拆分為獨立的服務(wù)單元，伸縮性好，耦合度低，不同的微服務(wù)可以用不同的語言開發(fā)，每一個服務(wù)處理的單一的業(yè)務(wù)。微服務(wù)可以劃分為前端服務(wù)（也叫邊緣服務(wù)）和后端服務(wù)（也叫中間服務(wù)），前端服務(wù)是對后端服務(wù)做必要的聚合和剪裁后暴露給外部不同的設(shè)備（PC、Phone等），所有的服務(wù)啟動時都會到Eureka服務(wù)器進行注冊，服務(wù)之間會有錯綜復(fù)雜的依賴關(guān)系。當網(wǎng)關(guān)服務(wù)轉(zhuǎn)發(fā)外部請求調(diào)用前端服務(wù)時，通過查詢服務(wù)注冊表就可以發(fā)現(xiàn)目標服務(wù)進行調(diào)用，前端服務(wù)調(diào)用后端服務(wù)時也是同樣的道理，一次請求可能涉及到多個服務(wù)之間的相互調(diào)用。由于每個微服務(wù)都是以集群的形式部署，服務(wù)之間相互調(diào)用的時候需要做負載均衡，因此每個服務(wù)中都有一個LB組件用來實現(xiàn)負載均衡。

微服務(wù)以鏡像的形式，運行在Docker容器中。Docker容器技術(shù)讓我們的服務(wù)部署變得簡單、高效。傳統(tǒng)的部署方式，需要在每臺服務(wù)器上安裝運行環(huán)境，如果我們的服務(wù)器數(shù)量龐大，在每臺服務(wù)器上安裝運行環(huán)境將是一項無比繁重的工作，一旦運行環(huán)境發(fā)生改變，就不得不重新安裝，這簡直是災(zāi)難性的。而使用Docker容器技術(shù)，我們只需要將所需的基礎(chǔ)鏡像（JDK等）和微服務(wù)生成一個新的鏡像，將這個最終的鏡像部署在Docker容器中運行，這種方式簡單、高效，能夠快速部署服務(wù)。每個Docker容器中可以運行多個微服務(wù)，Docker容器以集群的方式部署，使用Docker Swarm對這些容器進行管理。我們創(chuàng)建一個鏡像倉庫用來存放所有的基礎(chǔ)鏡像以及生成的最終交付鏡像，在鏡像倉庫中對所有鏡像進行管理。

服務(wù)容錯

微服務(wù)之間存在錯綜復(fù)雜的依賴關(guān)系，一次請求可能會依賴多個后端服務(wù)，在實際生產(chǎn)中這些服務(wù)可能會產(chǎn)生故障或者延遲，在一個高流量的系統(tǒng)中，一旦某個服務(wù)產(chǎn)生延遲，可能會在短時間內(nèi)耗盡系統(tǒng)資源，將整個系統(tǒng)拖垮，因此一個服務(wù)如果不能對其故障進行隔離和容錯，這本身就是災(zāi)難性的。我們的微服務(wù)架構(gòu)中使用了Hystrix組件來進行容錯處理。Hystrix是Netflix的一款開源組件，它通過熔斷模式、隔離模式、回退（fallback）和限流等機制對服務(wù)進行彈性容錯保護，保證系統(tǒng)的穩(wěn)定性。

熔斷模式：熔斷模式原理類似于電路熔斷器，當電路發(fā)生短路時，熔斷器熔斷，保護電路避免遭受災(zāi)難性損失。當服務(wù)異常或者大量延時，滿足熔斷條件時服務(wù)調(diào)用方會主動啟動熔斷，執(zhí)行fallback邏輯直接返回，不會繼續(xù)調(diào)用服務(wù)進一步拖垮系統(tǒng)。熔斷器默認配置服務(wù)調(diào)用錯誤率閥值為50%，超過閥值將自動啟動熔斷模式。服務(wù)隔離一段時間以后，熔斷器會進入半熔斷狀態(tài)，即允許少量請求進行嘗試，如果仍然調(diào)用失敗，則回到熔斷狀態(tài)，如果調(diào)用成功，則關(guān)閉熔斷模式。
隔離模式：Hystrix默認采用線程隔離，不同的服務(wù)使用不同的線程池，彼此之間不受影響，當一個服務(wù)出現(xiàn)故障耗盡它的線程池資源，其他的服務(wù)正常運行不受影響，達到隔離的效果。例如我們通過andThreadPoolKey配置某個服務(wù)使用命名為TestThreadPool的線程池，實現(xiàn)與其他命名的線程池隔離。
回退（fallback）：fallback機制其實是一種服務(wù)故障時的容錯方式，原理類似Java中的異常處理。只需要繼承HystixCommand并重寫getFallBack()方法，在此方法中編寫處理邏輯，比如可以直接拋異常（快速失敗），可以返回空值或缺省值，也可以返回備份數(shù)據(jù)等。當服務(wù)調(diào)用出現(xiàn)異常時，會轉(zhuǎn)向執(zhí)行g(shù)etFallBack()。有以下幾種情況會觸發(fā)fallback：

程序拋出非HystrixBadRequestExcepption異常，當拋出HystrixBadRequestExcepption異常時，調(diào)用程序可以捕獲異常，沒有觸發(fā)fallback，當拋出其他異常時，會觸發(fā)fallback；
程序運行超時；
熔斷啟動；
線程池已滿。

限流：限流是指對服務(wù)的并發(fā)訪問量進行限制，設(shè)置單位時間內(nèi)的并發(fā)數(shù)，超出限制的請求拒絕并fallback，防止后臺服務(wù)被沖垮。

在公眾號互聯(lián)網(wǎng)架構(gòu)師回復(fù)“2T”，獲取驚喜禮包。

Hystix使用命令模式HystrixCommand包裝依賴調(diào)用邏輯，這樣相關(guān)的調(diào)用就自動處于Hystrix的彈性容錯保護之下。調(diào)用程序需要繼承HystrixCommand并將調(diào)用邏輯寫在run()中，使用execute()（同步阻塞）或queue()（異步非阻塞）來觸發(fā)執(zhí)行run()。

動態(tài)配置中心

微服務(wù)有很多依賴配置，某些配置參數(shù)在服務(wù)運行期間可能還要動態(tài)修改，比如：根據(jù)訪問流量動態(tài)調(diào)整熔斷閥值。傳統(tǒng)的實現(xiàn)信息配置的方法，比如放在xml、yml等配置文件中，和應(yīng)用一起打包，每次修改都要重新提交代碼、打包構(gòu)建、生成新的鏡像、重新啟動服務(wù)，效率太低，這樣顯然是不合理的，因此我們需要搭建一個動態(tài)配置中心服務(wù)支持微服務(wù)動態(tài)配置。我們使用Spring Cloud的configserver服務(wù)幫我們實現(xiàn)動態(tài)配置中心的搭建。我們開發(fā)的微服務(wù)代碼都存放在Git服務(wù)器私有倉庫里面，所有需要動態(tài)配置的配置文件存放在Git服務(wù)器下的configserver（配置中心，也是一個微服務(wù)）服務(wù)中，部署到Docker容器中的微服務(wù)從Git服務(wù)器動態(tài)讀取配置文件的信息。當本地Git倉庫修改代碼后push到Git服務(wù)器倉庫，Git服務(wù)端hooks（post-receive，在服務(wù)端完成代碼更新后會自動調(diào)用）自動檢測是否有配置文件更新，如果有，Git服務(wù)端通過消息隊列給配置中心（configserver，一個部署在容器中的微服務(wù)）發(fā)消息，通知配置中心刷新對應(yīng)的配置文件。這樣微服務(wù)就能獲取到最新的配置文件信息，實現(xiàn)動態(tài)配置。

以上這些框架或組件是支撐實施微服務(wù)架構(gòu)的核心，在實際生產(chǎn)中，我們還會用到很多其他的組件，比如日志服務(wù)組件、消息服務(wù)組件等等，根據(jù)業(yè)務(wù)需要自行選擇使用。在我們的微服務(wù)架構(gòu)實施案例中，參考使用了很多Spring Cloud Netflix框架的開源組件，主要包括Zuul（服務(wù)網(wǎng)關(guān)）、Eureka（服務(wù)注冊與發(fā)現(xiàn)）、Hystrix（服務(wù)容錯）、Ribbon（客戶端負載均衡）等。這些優(yōu)秀的開源組件，為我們實施微服務(wù)架構(gòu)提供了捷徑。

以上篇幅主要介紹了微服務(wù)架構(gòu)的基本原理，其中有些比較細節(jié)的東西，比如Eureka的各項參數(shù)配置說明、動態(tài)配置中心搭建過程等，博主會在其他的文章中做出詳細的說明，供大家參考。

PS：如果覺得我的分享不錯，歡迎大家隨手點贊、在看。

大家一起在評論區(qū)聊聊唄~

微服務(wù)架構(gòu)實施原理詳解