基于 Kubernetes 的微服務(wù)項(xiàng)目設(shè)計(jì)與實(shí)現(xiàn)

隨著互聯(lián)網(wǎng)的發(fā)展，后端服務(wù)和容器編排技術(shù)的日益成熟，微服務(wù)成為了后端服務(wù)的首選，Kubernetes 也已經(jīng)成為目前容器編排的事實(shí)標(biāo)準(zhǔn), 微服務(wù)擁抱容器時(shí)代已經(jīng)來臨。筆者結(jié)合自己的經(jīng)驗(yàn)，寫了這篇微服務(wù)+ Kubernetes 入門寶典，希望能夠拋磚引玉。能讓大家了解 微服務(wù)和 Kubernetes 如何配合。上卷主要描述 微服務(wù)設(shè)計(jì)，項(xiàng)目實(shí)現(xiàn)，kubernetes 部署，微服務(wù)的部署 高可用和監(jiān)控 這幾個(gè)部分。下卷計(jì)劃討論服務(wù)化網(wǎng)格和數(shù)據(jù)持久化, 有狀態(tài)服務(wù)，operator 這幾部分。本文由我獨(dú)立完成（ppmsn2005#gmail.com）如有任何錯(cuò)誤，是我個(gè)人原因，請直接和我聯(lián)系，謝謝！您可以在 https://github.com/xiaojiaqi/deploy-microservices-to-a-Kubernetes-cluster 找到本文的全文和相關(guān)資料。

本文會從設(shè)計(jì)開始，設(shè)計(jì)一個(gè)簡單的前后端分離的項(xiàng)目，并將它部署在 kubernetes 集群上，期間我們將關(guān)注微服務(wù)和 kubernetes 配合的各個(gè)方面，并且從 系統(tǒng)的可用性，可靠性、強(qiáng)壯性、可擴(kuò)展進(jìn)行討論，最終設(shè)計(jì)一個(gè)可以真正實(shí)用的系統(tǒng)。

整體上我們從4個(gè)章節(jié)描述這個(gè)目標(biāo)，分別是：

第一章：微服務(wù)項(xiàng)目的設(shè)計(jì)

第二章：微服務(wù)項(xiàng)目的具體實(shí)現(xiàn)

第三章：kubernetes的部署

第四章：微服務(wù)高可用部署及驗(yàn)證

微服務(wù)是一種設(shè)計(jì)思想，它并不局限于任何開發(fā)語言，在本例中我們選擇java的spring boot 框架來實(shí)現(xiàn)微服務(wù)。微服務(wù)之間的 RPC 方案也很多，我們這里選擇RESTFUL 這種最常見的方案。為了項(xiàng)目的簡潔，項(xiàng)目也沒有涉及數(shù)據(jù)庫和緩存，配置中心相關(guān)的內(nèi)容。我們主要注重項(xiàng)目的設(shè)計(jì)思想實(shí)踐和項(xiàng)目改進(jìn)。

第一章：微服務(wù)項(xiàng)目的設(shè)計(jì)

1.1 微服務(wù)設(shè)計(jì)的思想

首先我們簡單地回顧一下微服務(wù)，微服務(wù)的定義當(dāng)來自 Martin flowerler https://martinfowler.com/articles/microservices.html 一文，借用大佬的一張圖 描述了微服務(wù)最本質(zhì)的東西。

微服務(wù)把各個(gè)功能拆開了，每個(gè)模塊的功能更加獨(dú)立，也更加單一。每個(gè)模塊都獨(dú)立發(fā)展，可以說做到了功能的高內(nèi)聚，低偶合。

再借一張，這樣數(shù)據(jù)庫也被徹底拆分開了。一個(gè)巨大復(fù)制的單體數(shù)據(jù)庫也按照功能拆成了小的獨(dú)立數(shù)據(jù)庫。

微服務(wù)就是這么簡單嗎？當(dāng)然不是，里面有很多細(xì)節(jié)需要考慮，紙上得來終覺淺,絕知此事要躬行。這次讓我們開始從0開始真正的設(shè)計(jì)整套系統(tǒng)。

1.2 實(shí)踐設(shè)計(jì)和改進(jìn)

現(xiàn)在我們要設(shè)計(jì)一個(gè)最簡單的微服務(wù)架構(gòu)。為了更貼近真實(shí)的業(yè)務(wù)。我們假設(shè)這個(gè)系統(tǒng)是這樣的。

整個(gè)系統(tǒng)的前端是一個(gè)有著前后端分離站點(diǎn)，用戶訪問了www.demo.com 這個(gè)前端站點(diǎn),通過前端頁面發(fā)起請求，www.demo.com 服務(wù)器將請求發(fā)往a.demo.com.  然后a.demo.com 再請求b.demo.com ，b.demo.com 再請求 c.demo.com。c.demo.com 將結(jié)果返回后，不斷返回，最終顯示在前端站點(diǎn)，完成微服務(wù)的全套調(diào)用流程。[ 一般業(yè)務(wù)系統(tǒng) 在前端和微服務(wù)直接還存在一個(gè)網(wǎng)關(guān)部分，網(wǎng)關(guān)一般用于鑒權(quán)，請求分類，監(jiān)控等功能， 這里因?yàn)楸容^簡單，所以省略了這個(gè)部分]

最終我們將這套架構(gòu)將部署在kubernetes 上，開始真正的服務(wù)用戶。

1.3 改進(jìn)項(xiàng)目

從圖一我們可以看到這是一個(gè)非常簡單而單薄的架構(gòu)，存在很多問題，我們需要不斷地解決它們。下面我們開始改進(jìn)項(xiàng)目。

首先，我們要解決節(jié)點(diǎn)的可靠性。在圖一所有的節(jié)點(diǎn)都只有一個(gè)實(shí)例，任何節(jié)點(diǎn)的崩潰都將造成項(xiàng)目無法運(yùn)行，在真正的項(xiàng)目中這是不可接受的。怎么解決呢？當(dāng)然是多個(gè)實(shí)例

1.3.1 加入多實(shí)例及注冊中心

我們將各個(gè)模塊的實(shí)例數(shù)目增加，多個(gè)實(shí)例才能保證整個(gè)系統(tǒng)的可靠性。如果一個(gè)實(shí)例有問題，我們還是可以其他相同的實(shí)例進(jìn)行服務(wù)。

但是多個(gè)實(shí)例又帶來一個(gè)問題，各個(gè)組件之間如何定位呢？如果有10個(gè)b.demo.com 實(shí)例，它的上下游又該如何找到它們呢？解決方案之一是注冊中心。注冊中心解決的是應(yīng)用之間的尋址問題。有了它，上下游之間的應(yīng)用可以相互尋址，并且獲知那些實(shí)例是可用的，應(yīng)用挑選可用的實(shí)例進(jìn)行工作。注冊中心的方案很多，有eureka，zookeeper, console, Nacos 等等，關(guān)于討論各種注冊中心是AP、CP的區(qū)別，優(yōu)劣的文章很多，這篇文章不是一篇微服務(wù)的開發(fā)教程，我們選擇比較常見的eureka為演示的注冊中心。

注：在kubernetes 中部署微服務(wù)，對注冊中心是沒有任何限制的。所以不要被某些文章誤導(dǎo)，按照這篇文章做，你完全可以做到代碼零修改，直接在kubernetes 上運(yùn)行。

1.3.2 監(jiān)控系統(tǒng) Metrics

在完成了注冊中心的功能后，雖然整個(gè)系統(tǒng)可以運(yùn)行了，我們會發(fā)現(xiàn)沒有應(yīng)用監(jiān)控的情況下，我們對系統(tǒng)運(yùn)轉(zhuǎn)狀態(tài)是完全摸黑的，這樣相當(dāng)于盲人騎馬，非常危險(xiǎn)。我們需要知道所有微服務(wù)運(yùn)行的狀態(tài)，必須將各個(gè)微服務(wù)的狀態(tài)監(jiān)控起來，只有這樣才能做到 運(yùn)籌帷幄，決勝千里。

在這里，我們選擇使用Prometheus和Grafana這套監(jiān)控組合。Prometheus + Grafana是一個(gè)比較常見的組合, 基本是現(xiàn)在容器監(jiān)控的標(biāo)準(zhǔn)配置。

在kubernetes 上，我們需要每個(gè)微服務(wù)的實(shí)例里開啟監(jiān)控?cái)?shù)據(jù)到導(dǎo)出功能。同時(shí)利用 Prometheus 的自動發(fā)現(xiàn)功能， 這樣Prometheus 可以將數(shù)據(jù)收集存儲起來。這里的數(shù)據(jù)包括每個(gè)應(yīng)用的各項(xiàng)指標(biāo)比如內(nèi)存大小，200錯(cuò)誤數(shù)目，500錯(cuò)誤數(shù)目, JVM里線程數(shù)量，GC時(shí)間大小。配合granfana的聚合顯示能力，我們可以直觀地對整個(gè)系統(tǒng)有完整把控。在應(yīng)用開發(fā)過程中，我們只需要在代碼里加入一個(gè)類庫就可以實(shí)現(xiàn)信息的導(dǎo)出，不需要專門寫代碼。

1.3.3 日志系統(tǒng) logging

目前已經(jīng)有了監(jiān)控，日志還有存在的必要嗎？當(dāng)然 下面這個(gè)圖就反應(yīng)監(jiān)控的3個(gè)維度。

這3個(gè)維度分別是Mertics Tracing 和logging

Metrics  主要就是指剛才說的監(jiān)控，它主要反應(yīng)的就是一個(gè)聚合的數(shù)據(jù)，比如今天200錯(cuò)誤是多少，QPS是多少？它指的是一段時(shí)間內(nèi)的數(shù)據(jù)聚合。

Logging 就是我們現(xiàn)在討論的日志。的它描述一些離散的（不連續(xù)的）事件。比如各個(gè)系統(tǒng)里的錯(cuò)誤，告警。所以我們需要將日志收集起來。

Tracing 則關(guān)注單次請求中信息。我們關(guān)注請求的質(zhì)量和服務(wù)可行性，是我們優(yōu)化系統(tǒng)，排查問題的工具。

說到了日志，在一個(gè)分布式系統(tǒng)，日志是非常重要的一環(huán)。因?yàn)槲⒎?wù)和容器的緣故，導(dǎo)致日志收集不是這么簡單了。因?yàn)樵趉ubernetes 里 容器的銷毀和重啟都是經(jīng)?？赡艹霈F(xiàn)的，我們需要第一時(shí)間就把日志收集起來。

日志收集的方案有很多，有些方案是在本地啟動一個(gè)收集進(jìn)程，將落地的日志轉(zhuǎn)發(fā)到kakfa組件再轉(zhuǎn)發(fā)日志中心，也有的方案是直接寫到kafka組件直接進(jìn)入日志中心。兩者各有優(yōu)劣。

在這里，我們的方案選擇了后者。我們簡單地利用一個(gè)組件將日志直接打入kafka 組件。這種方案的好處是我們?nèi)罩静辉俾涞兀罩綢O被消除了，日志的存儲也和容器做到了分離。我們再也不用擔(dān)心日志IO對宿主機(jī)造成的系統(tǒng)壓力了。

1.3.4      追蹤系統(tǒng) Tracing

剛才我們討論了監(jiān)控 (Metric)和日志(Logging)，還有一個(gè)維度就是追蹤(Tracing).

隨著微服務(wù)的實(shí)例越來越多，有一個(gè)很現(xiàn)實(shí)的問題出現(xiàn)了，當(dāng)大規(guī)模分布式集群出現(xiàn)了，應(yīng)用構(gòu)建在不同的容器集群里、有可能布在了幾千臺容器里，橫跨多個(gè)不同的數(shù)據(jù)中心。因此，就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問題的工具。這該怎么解決呢？可以看看google的論文 google dapper

Google 的論文描述一種解決辦法，我們一般稱作APM(Application Performance Monitor). 它把一次調(diào)用加入一個(gè)獨(dú)立無二的標(biāo)記，并且在各個(gè)系統(tǒng)里透傳標(biāo)記，從而達(dá)到追蹤整個(gè)消息處理過程的能力。市面上大多數(shù)實(shí)現(xiàn)都是基于這一思想,可選方案的有很多，如 cat pip, zipkin, skywalkin。它們有需要代碼注入的，有無注入的。關(guān)于他們的優(yōu)劣也有很多文章評述。在這里我們選用zipkin 。Zipkin 需要在項(xiàng)目中加入一個(gè)庫，并不需要寫代碼，這對業(yè)務(wù)的入侵做到了很少，非常方便。

1.3.5 流量控制

你認(rèn)為這一切就完了嗎？當(dāng)然不是，微服務(wù)里還有一項(xiàng)非常重要的功能：流量控制，我們還沒有做。

當(dāng)海量的請求來臨的時(shí)候，我們可以用增加容器數(shù)量的辦法來提高我們的服務(wù)能力，但是簡單地添加實(shí)例是很危險(xiǎn)的，因?yàn)檎麄€(gè)系統(tǒng)的服務(wù)能力是被系統(tǒng)短板所限制的，簡單地添加實(shí)例，并不是總能起到提高服務(wù)能力的作用。反而可能引起反作用，最終導(dǎo)致整個(gè)系統(tǒng)的崩潰。

我們對整個(gè)系統(tǒng)的負(fù)載容量是有一個(gè)設(shè)計(jì)的，當(dāng)超出我們設(shè)計(jì)的能力時(shí)，我們需要對多余的請求說No。相應(yīng)的方案分別是熔斷、限流和降級。目前java領(lǐng)域的這方面的hystrix，sentinel 在這方面都做得很好。Sentinel 在阿里接受了考驗(yàn)，并且使用起來也很簡單，所以我們選它?，F(xiàn)在我們在整個(gè)系統(tǒng)里加上一個(gè)流量控中心。這樣一個(gè)基本完整的 可靠的 高可靠的系統(tǒng)就基本完成了。

（在實(shí)際開發(fā)中，其實(shí)還有最關(guān)鍵的配置中心（apollo)，數(shù)據(jù)庫（db）,緩存(redis) 等組件， 服務(wù)化網(wǎng)格， 我們可以把這些組件暫時(shí)放在kubernetes 之外，仍然是可以起到同樣的效果）

好了設(shè)計(jì)部分，先到這里，開始實(shí)現(xiàn)。

第二章：微服務(wù)項(xiàng)目的具體實(shí)現(xiàn)

從 前端向后端開始實(shí)現(xiàn)

2.1 前端站點(diǎn)

前端站點(diǎn)的邏輯很簡單，就是顯示一個(gè)頁面，頁面中有一個(gè)按鍵。當(dāng)你點(diǎn)擊按鍵的時(shí)候，前端頁面發(fā)起ajax請求，訪問前端站點(diǎn)本身的一個(gè)接口，這個(gè)接口被nginx代理，轉(zhuǎn)發(fā)到a.demo.com 微服務(wù)上，a. demo.com 微服務(wù)再將請求轉(zhuǎn)發(fā)到b. demo.com, b. demo.com 再將請求轉(zhuǎn)發(fā)到c. demo.com. 最終將結(jié)果返回給前端。前端站點(diǎn)再將結(jié)果顯示在頁面上。我們通過結(jié)果顯示，就能知道 這次請求通過了那些服務(wù)器，每臺服務(wù)器的服務(wù)運(yùn)行時(shí)間大概是多少。

前端站點(diǎn)代碼 大體如下：

然后看a、b、 c 應(yīng)用部分的java代碼，這就是個(gè)普通的多模塊Maven項(xiàng)目。

項(xiàng)目很簡單，分成了3個(gè)部分，一個(gè)是注冊中心，也就是利用eureka實(shí)現(xiàn)注冊中心服務(wù)，另一個(gè)則是基礎(chǔ)庫項(xiàng)目，大部分功能都在這里實(shí)現(xiàn)，最后則是各個(gè)微服務(wù)項(xiàng)目，微服務(wù)項(xiàng)目只需要簡單調(diào)用基礎(chǔ)庫就能完成。

2.2 注冊中心

注冊中心的代碼非常簡單，只需要加一個(gè)簡單的聲明

這是注冊中心的配置文件，在kubernetes集群里運(yùn)行時(shí)，我們會運(yùn)行3個(gè)節(jié)點(diǎn)組成高可用的注冊中心集群。這時(shí) 這個(gè)配置項(xiàng)需要相應(yīng)的修改。

2.3 基礎(chǔ)庫

在基礎(chǔ)庫項(xiàng)目里，我們將很多的依賴都放在里面，這樣應(yīng)用項(xiàng)目只需要簡單依賴基礎(chǔ)庫就可以，能夠做到統(tǒng)一修改。

同時(shí)我們也可以看到大部分依賴庫只需要加入就可以，并不需編寫代碼就可以工作，這讓開發(fā)工作變得輕松。

對于微服務(wù)的返回結(jié)果，我們做了一些美化格式。這樣可以在檢查結(jié)果時(shí)，比較容易。

簡單的定義了一些返回的結(jié)構(gòu)，可以通過這些結(jié)構(gòu)，微服務(wù)可以把處理時(shí)的時(shí)間戳，線程號，實(shí)例ip這些信息返回出來。

基礎(chǔ)模塊的日志實(shí)現(xiàn)，從github 找的例子簡單地進(jìn)行了修改。（簡單實(shí)現(xiàn)，不要用于生產(chǎn)）這時(shí)我們利用logback.xml 的配置，可以選擇我們是把日志寫入本地磁盤還是直接寫入kafka.

2.4 a.demo.com b.demo.com c.demo.com 應(yīng)用實(shí)現(xiàn)

實(shí)現(xiàn)很簡單，只是簡單地調(diào)用基礎(chǔ)庫就可以了。注意 每個(gè)應(yīng)用需要實(shí)現(xiàn)一個(gè)探活接口 /hs. 這樣kubernetes 系統(tǒng)可以通過這個(gè)接口來探活，獲知你這個(gè)應(yīng)用是不是準(zhǔn)備好了，能不能接入流量。否則 你這個(gè)應(yīng)用可能還在啟動過程中，但是流量已經(jīng)接入了，那么肯定會出問題。

在每個(gè)應(yīng)用的配置里，我們都預(yù)置了各個(gè)配置的項(xiàng)目，在本地運(yùn)行的時(shí)候，我們可以填注入本地的配置，在kubernetes 里 以容器形式進(jìn)行運(yùn)行，我們可以利用yaml來動態(tài)地修改它們，做到2種情況下完全兼容。

第三章：kubernetes的部署

在完成應(yīng)用的編寫后，我們需要安裝kubernetes系統(tǒng)了，如果已經(jīng)有kubernetes 集群的，就可以直接跳過這個(gè)部分了，請看下一章。除了kubernetes 集群以外，你還需要Prometheus and Grafana這樣的監(jiān)控組件。所以這里我推薦一個(gè)牛逼的安裝工具，和所有現(xiàn)有的Kubernetes 安裝工具比，它是最好的，沒有之一。

它的名字是 K8seasy, 它的優(yōu)點(diǎn)在于

1. 可以一鍵安裝整體kubernetes 系統(tǒng)，無需了解任何背景知識

2. 所有的鏡像都已經(jīng)內(nèi)置，不會因?yàn)橄螺d鏡像失敗而導(dǎo)致失敗

3. 安裝支持各種不同版本kubernetes版本

4. 安裝的服務(wù)是二進(jìn)制版本的，非容器版本, 穩(wěn)定高效

5. 支持安裝3節(jié)點(diǎn) 高可用的生產(chǎn)環(huán)境集群

3.1 安裝過程

下載K8seasy，官方主頁 https://github.com/xiaojiaqi/K8seasy_release_page

安裝下載頁：http://dl.K8seasy.com/

將3個(gè)安裝文件都下載下來， 其中 pack.2020.10.02.bin 和installer 都是安裝文件， kubernetes-server-linux-amd64.tar.gz 是kubernetes 的官方軟件包，你可以自己選擇一個(gè)最新的版本。

如果要選擇一個(gè)其他版本的kubernetes

安裝的過程很簡單，2條命令即可，這里我們假設(shè) 需要安裝Kubernetes的網(wǎng)絡(luò)為 192.168.2.0, master 主機(jī)為192.168.2.50

1 創(chuàng)建密鑰

sudo ./installer --genkey -hostlist=192.168.2.1

2 創(chuàng)建集群

sudo ./installer   -kubernetestarfile kubernetes-server-linux-amd64v1.18.2.tar.gz -masterip 192.168.2.50

稍等一會兒 就能看到類似如下輸出

就這么簡單，一個(gè)Kubernetes已經(jīng)裝好了。此時(shí)相關(guān)的所有監(jiān)控已經(jīng)被完全安裝好了。

3. 各項(xiàng)監(jiān)控

以master 節(jié)點(diǎn)為 192.168.2.50 為例子

http://192.168.2.50:10000 可以直接打開dashboard, 對整個(gè)集群有一個(gè)全面了解

打開 http://192.168.2.50:8080  可以直接訪問alertmanager

打開 http://192.168.2.50:8081 你可以直接使用 Grafana (用戶 admin, 密碼admin)

打開 http://192.168.2.50:8082 你可以訪問 Prometheus.

所有的配套都已經(jīng)安裝好了。

4. 多套環(huán)境監(jiān)控

這一切就完了嗎？當(dāng)然不是，為了支持多集群管理，再推薦一個(gè)工具。剛才我們說到直接使用 http://192.168.2.50:1000 這個(gè)頁面可以直接管理整個(gè)集群，但是在公司里如果有多個(gè)集群，該如何管理呢? 別擔(dān)心，K8seasy 已經(jīng)有對應(yīng)的解決方案

仔細(xì)看剛才的安裝好的日志，里面提示你 專門生產(chǎn)了一個(gè) lens.kubeconfig 的配置文件， 并且有一個(gè) 域名和 ip 的對應(yīng)表。這時(shí)候，你只需要 首先在本地Host 文件里加入這個(gè)對應(yīng)

然后去 https://Kuberneteslens.dev/

下載一個(gè)lens的安裝包。安裝lens以后，你只需要將 lens.kubeconfig 導(dǎo)入到lens里

導(dǎo)入完成后，你就可以遠(yuǎn)程管理這個(gè)集群了。這樣有多個(gè)集群，你也可以只用一套lens 進(jìn)行管理了。

Lens的界面優(yōu)美，使用方便，快試試吧。

好了 Kubernetes 的安裝完成了。當(dāng)然了K8seasy 的功能是非常強(qiáng)大的，你可以用 sudo ./installer -h 查看幫助， 也可以使用 sudo ./installer -demo 查看各種場景的安裝幫助。

第四章：微服務(wù)高可用部署及驗(yàn)證

Kubernetes 裝好了，現(xiàn)在開始將微服務(wù)部署上去了。我們剛才的代碼只是Java 源碼，我們還需要將它們編譯成Jar包，然后再打成docker 鏡像才能部署，這部分比較簡單，所以我不演示如何完成了，我將相關(guān)的Dockerfile 和 最終Yaml 都放在Github 里了，在開始開發(fā)時(shí)，我提到將日志寫入Kafka, 所以有2套配置，一套使用了Kafak 一套沒有使用Kafka。請注意區(qū)別，有因?yàn)闆]有Kafka 比較容易實(shí)施，我這里就演示沒有Kafak的版本。這樣所有只要有一臺Linux 就可以保證將整個(gè)流程實(shí)施成功。

4.1  服務(wù)部署上去

依次運(yùn)行每條部署Yaml的命令即可，不需要做其他的操作。

注意，鏡像在Docker-Hub, 可能需要一定時(shí)間能下載。

運(yùn)行后在 Dashboard 查看，你可以看到類似的信息，所有的服務(wù)都已經(jīng)成功運(yùn)行。

查看Dashboard

此時(shí)修改你本地的Hosts

這樣的話，因?yàn)槲覀兊腒ubernetes 是支持 nginx-ingress的，所以你可以直接訪問Master的物理IP來訪問這些服務(wù)，不需要做任何轉(zhuǎn)換。

首先我們可以打開dashboard 從中查到eureka.服務(wù)器的具體ip, 然后訪問eurka 服務(wù)。

查看注冊中心

在頁面中你可以發(fā)現(xiàn)，在Kubernetes集群里，我們啟動了3個(gè)eureka服務(wù)，它們相互注冊，組成了一個(gè)高可用集群。

其次，我們在Grafana 中導(dǎo)入 jvm 的監(jiān)控項(xiàng)目

這樣Grafana可以幫助我們把 各個(gè)Java服務(wù)的具體狀態(tài)做一個(gè)收集，完成我們需要的監(jiān)控。

前端驗(yàn)證

此時(shí) 我們打開 http://www.demo.com 的網(wǎng)頁。

我們可以點(diǎn)擊頁面上的 get 請求按鍵，模擬發(fā)出請求，隨后我們就會發(fā)現(xiàn)頁面里顯示出的信息在不斷變化。

在頁面顯示的內(nèi)容里，我們可以清楚地發(fā)現(xiàn)，我們的消息在不同實(shí)例里處理，如果有一個(gè)實(shí)例出現(xiàn)了故障是不會影響我們現(xiàn)在的業(yè)務(wù)的。

好了開始驗(yàn)證整個(gè)系統(tǒng)。

模擬驗(yàn)證

使用一個(gè)簡單的腳本 模擬每3秒從前端訪問一次后端。

調(diào)用關(guān)系驗(yàn)證

首先打開zipkin  zipkin.demo.com

點(diǎn)擊具體的請求，可以查看到每次請求在內(nèi)部的細(xì)節(jié)。

限流熔斷驗(yàn)證

其次 打開 sentinel 站點(diǎn)，這個(gè)站點(diǎn)可以監(jiān)控，也可以對微服務(wù)進(jìn)行限流，限速，熔斷等操作。（密碼口令都是 sentinel）

進(jìn)入控制臺后，我們可以發(fā)現(xiàn)所有的服務(wù)已經(jīng)自動被發(fā)現(xiàn)，并存在于左邊的菜單。

分別點(diǎn)開 a b c 3個(gè)服務(wù)，可以看到規(guī)律的周期訪問，和我們的腳本的測試速度是一致的。

Sentinel 里面內(nèi)含強(qiáng)大的監(jiān)控，流控 降級等功能，具體的使用，可以慢慢學(xué)習(xí)，相信你一定會受益良多。

應(yīng)用狀態(tài)驗(yàn)證

打開Grafana的監(jiān)控頁，你可以查看所有應(yīng)用的狀態(tài)，包括heap 大小，啟動時(shí)間，錯(cuò)誤數(shù)目 等等。

通過這張圖你可以了解每個(gè)應(yīng)用本身的狀態(tài)，使用了多少內(nèi)存，響應(yīng)的代碼是多少，jvm 使用情況。相信此時(shí) 你已經(jīng)對各個(gè)組件的情況，監(jiān)控都有了一個(gè)全面了解。一個(gè)基于 Kubernetes 的微服務(wù)架構(gòu)已經(jīng)開始工作了。

最后送一張常用的系統(tǒng)架構(gòu)圖，希望大家能通過本文對高可用微服務(wù)如何架設(shè) Kubernetes 上有一個(gè)基本的了解，將本文討論的東西用于實(shí)踐。謝謝！